Re: [RFT][PATCH v1 0/3] ACPI: scan: Defer enumeration of devices with significant dependencies

2020-12-17 Thread Mika Westerberg
Hi Rafael,

On Mon, Dec 14, 2020 at 09:23:47PM +0100, Rafael J. Wysocki wrote:
> Hi,
> 
> This series addresses some enumeration ordering issues by using information
> from _DEP to defer the enumeration of devices that are likely to depend on
> operation region (OpRegion) handlers supplied by the drivers of other
> devices.
> 
> This allows the OpRegion suppliers to be probed and start working before the
> devices depending on them are enumerated.

For the whole series,

Reviewed-by: Mika Westerberg 


[PATCH v3 1/5] clk: JZ4780: Add function for disable the second core.

2020-12-17 Thread Zhou Yanjie
Add "jz4780_core1_disable()" for disable the second core of JZ4780,
prepare for later commits.

Signed-off-by: 周琰杰 (Zhou Yanjie) 
Reviewed-by: Paul Cercueil 
---

Notes:
v1->v2:
Add Paul Cercueil's Reviewed-by.

v2->v3:
No change.

 drivers/clk/ingenic/jz4780-cgu.c | 21 +
 1 file changed, 21 insertions(+)

diff --git a/drivers/clk/ingenic/jz4780-cgu.c b/drivers/clk/ingenic/jz4780-cgu.c
index 0268d23..dcca74e 100644
--- a/drivers/clk/ingenic/jz4780-cgu.c
+++ b/drivers/clk/ingenic/jz4780-cgu.c
@@ -252,8 +252,29 @@ static int jz4780_core1_enable(struct clk_hw *hw)
return 0;
 }
 
+static void jz4780_core1_disable(struct clk_hw *hw)
+{
+   struct ingenic_clk *ingenic_clk = to_ingenic_clk(hw);
+   struct ingenic_cgu *cgu = ingenic_clk->cgu;
+   unsigned long flags;
+   u32 lcr, clkgr1;
+
+   spin_lock_irqsave(&cgu->lock, flags);
+
+   lcr = readl(cgu->base + CGU_REG_LCR);
+   lcr |= LCR_PD_SCPU;
+   writel(lcr, cgu->base + CGU_REG_LCR);
+
+   clkgr1 = readl(cgu->base + CGU_REG_CLKGR1);
+   clkgr1 |= CLKGR1_CORE1;
+   writel(clkgr1, cgu->base + CGU_REG_CLKGR1);
+
+   spin_unlock_irqrestore(&cgu->lock, flags);
+}
+
 static const struct clk_ops jz4780_core1_ops = {
.enable = jz4780_core1_enable,
+   .disable = jz4780_core1_disable,
 };
 
 static const s8 pll_od_encoding[16] = {
-- 
2.7.4



[PATCH v3 3/5] clk: Ingenic: Fix problem of MAC clock in Ingenic X1000 and X1830.

2020-12-17 Thread Zhou Yanjie
X1000 and X1830 have two MAC related clocks, one is MACPHY, which is
controlled by MACCDR register, the other is MAC, which is controlled
by the MAC bit in the CLKGR register (with CLK_AHB2 as the parent).
The original driver mistakenly mixed the two clocks together.

Signed-off-by: 周琰杰 (Zhou Yanjie) 
---

Notes:
v2:
New patch.

v2->v3:
No change.

 drivers/clk/ingenic/x1000-cgu.c | 11 ---
 drivers/clk/ingenic/x1830-cgu.c | 11 ---
 2 files changed, 16 insertions(+), 6 deletions(-)

diff --git a/drivers/clk/ingenic/x1000-cgu.c b/drivers/clk/ingenic/x1000-cgu.c
index 9aa20b5..53e5fe0 100644
--- a/drivers/clk/ingenic/x1000-cgu.c
+++ b/drivers/clk/ingenic/x1000-cgu.c
@@ -296,12 +296,11 @@ static const struct ingenic_cgu_clk_info 
x1000_cgu_clocks[] = {
.gate = { CGU_REG_CLKGR, 31 },
},
 
-   [X1000_CLK_MAC] = {
-   "mac", CGU_CLK_MUX | CGU_CLK_DIV | CGU_CLK_GATE,
+   [X1000_CLK_MACPHY] = {
+   "mac_phy", CGU_CLK_MUX | CGU_CLK_DIV,
.parents = { X1000_CLK_SCLKA, X1000_CLK_MPLL },
.mux = { CGU_REG_MACCDR, 31, 1 },
.div = { CGU_REG_MACCDR, 0, 1, 8, 29, 28, 27 },
-   .gate = { CGU_REG_CLKGR, 25 },
},
 
[X1000_CLK_LCD] = {
@@ -452,6 +451,12 @@ static const struct ingenic_cgu_clk_info 
x1000_cgu_clocks[] = {
.parents = { X1000_CLK_EXCLK, -1, -1, -1 },
.gate = { CGU_REG_CLKGR, 21 },
},
+
+   [X1000_CLK_MAC] = {
+   "mac", CGU_CLK_GATE,
+   .parents = { X1000_CLK_AHB2 },
+   .gate = { CGU_REG_CLKGR, 25 },
+   },
 };
 
 static void __init x1000_cgu_init(struct device_node *np)
diff --git a/drivers/clk/ingenic/x1830-cgu.c b/drivers/clk/ingenic/x1830-cgu.c
index 950aee2..59342bc 100644
--- a/drivers/clk/ingenic/x1830-cgu.c
+++ b/drivers/clk/ingenic/x1830-cgu.c
@@ -270,13 +270,12 @@ static const struct ingenic_cgu_clk_info 
x1830_cgu_clocks[] = {
.gate = { CGU_REG_CLKGR0, 31 },
},
 
-   [X1830_CLK_MAC] = {
-   "mac", CGU_CLK_MUX | CGU_CLK_DIV | CGU_CLK_GATE,
+   [X1830_CLK_MACPHY] = {
+   "mac_phy", CGU_CLK_MUX | CGU_CLK_DIV,
.parents = { X1830_CLK_SCLKA, X1830_CLK_MPLL,
 X1830_CLK_VPLL, X1830_CLK_EPLL },
.mux = { CGU_REG_MACCDR, 30, 2 },
.div = { CGU_REG_MACCDR, 0, 1, 8, 29, 28, 27 },
-   .gate = { CGU_REG_CLKGR1, 4 },
},
 
[X1830_CLK_LCD] = {
@@ -428,6 +427,12 @@ static const struct ingenic_cgu_clk_info 
x1830_cgu_clocks[] = {
.gate = { CGU_REG_CLKGR1, 1 },
},
 
+   [X1830_CLK_MAC] = {
+   "mac", CGU_CLK_GATE,
+   .parents = { X1830_CLK_AHB2 },
+   .gate = { CGU_REG_CLKGR1, 4 },
+   },
+
[X1830_CLK_OST] = {
"ost", CGU_CLK_GATE,
.parents = { X1830_CLK_EXCLK, -1, -1, -1 },
-- 
2.7.4



[PATCH] Modify hardcode to SECCOMP_MODE_FILTER

2020-12-17 Thread Zhuling
From: zhuling 

bpf/seccomp: modify hardcode 2 to SECCOMP_MODE_FILTER

while the hardcode 2 has been define in seccomp_bpf.c, we should use
the definitions(SECCOMP_MODE_FILTER) instead of hardcode 2.

Signed-off-by: zhuling 
---
 samples/bpf/tracex5_user.c | 2 +-
 samples/seccomp/dropper.c  | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/samples/bpf/tracex5_user.c b/samples/bpf/tracex5_user.c
index c17d3fb..417753f 100644
--- a/samples/bpf/tracex5_user.c
+++ b/samples/bpf/tracex5_user.c
@@ -28,7 +28,7 @@ static void install_accept_all_seccomp(void)
.len = (unsigned short)(sizeof(filter)/sizeof(filter[0])),
.filter = filter,
};
-   if (prctl(PR_SET_SECCOMP, 2, &prog))
+   if (prctl(PR_SET_SECCOMP, SECCOMP_MODE_FILTER, &prog))
perror("prctl");
 }

diff --git a/samples/seccomp/dropper.c b/samples/seccomp/dropper.c
index cc0648e..08f8e7f 100644
--- a/samples/seccomp/dropper.c
+++ b/samples/seccomp/dropper.c
@@ -46,7 +46,7 @@ static int install_filter(int nr, int arch, int error)
perror("prctl(NO_NEW_PRIVS)");
return 1;
}
-   if (prctl(PR_SET_SECCOMP, 2, &prog)) {
+   if (prctl(PR_SET_SECCOMP, SECCOMP_MODE_FILTER, &prog)) {
perror("prctl(PR_SET_SECCOMP)");
return 1;
}
--
2.9.5



[PATCH v3 00/15] x86: major paravirt cleanup

2020-12-17 Thread Juergen Gross
This is a major cleanup of the paravirt infrastructure aiming at
eliminating all custom code patching via paravirt patching.

This is achieved by using ALTERNATIVE instead, leading to the ability
to give objtool access to the patched in instructions.

In order to remove most of the 32-bit special handling from pvops the
time related operations are switched to use static_call() instead.

At the end of this series all paravirt patching has to do is to
replace indirect calls with direct ones. In a further step this could
be switched to static_call(), too, but that would require a major
header file disentangling.

Changes in V3:
- added patches 7 and 12
- addressed all comments

Changes in V2:
- added patches 5-12

Juergen Gross (14):
  x86/xen: use specific Xen pv interrupt entry for MCE
  x86/xen: use specific Xen pv interrupt entry for DF
  x86/pv: switch SWAPGS to ALTERNATIVE
  x86/xen: drop USERGS_SYSRET64 paravirt call
  x86: rework arch_local_irq_restore() to not use popf
  x86/paravirt: switch time pvops functions to use static_call()
  x86/alternative: support "not feature" and ALTERNATIVE_TERNARY
  x86: add new features for paravirt patching
  x86/paravirt: remove no longer needed 32-bit pvops cruft
  x86/paravirt: simplify paravirt macros
  x86/paravirt: switch iret pvops to ALTERNATIVE
  x86/paravirt: add new macros PVOP_ALT* supporting pvops in
ALTERNATIVEs
  x86/paravirt: switch functions with custom code to ALTERNATIVE
  x86/paravirt: have only one paravirt patch function

Peter Zijlstra (1):
  objtool: Alternatives vs ORC, the hard way

 arch/x86/Kconfig   |   1 +
 arch/x86/entry/entry_32.S  |   4 +-
 arch/x86/entry/entry_64.S  |  26 ++-
 arch/x86/include/asm/alternative-asm.h |   3 +
 arch/x86/include/asm/alternative.h |   7 +
 arch/x86/include/asm/cpufeatures.h |   2 +
 arch/x86/include/asm/idtentry.h|   6 +
 arch/x86/include/asm/irqflags.h|  51 ++
 arch/x86/include/asm/mshyperv.h|  11 --
 arch/x86/include/asm/paravirt.h| 157 ++
 arch/x86/include/asm/paravirt_time.h   |  38 +
 arch/x86/include/asm/paravirt_types.h  | 220 +
 arch/x86/kernel/Makefile   |   3 +-
 arch/x86/kernel/alternative.c  |  59 ++-
 arch/x86/kernel/asm-offsets.c  |   7 -
 arch/x86/kernel/asm-offsets_64.c   |   3 -
 arch/x86/kernel/cpu/vmware.c   |   5 +-
 arch/x86/kernel/irqflags.S |  11 --
 arch/x86/kernel/kvm.c  |   3 +-
 arch/x86/kernel/kvmclock.c |   3 +-
 arch/x86/kernel/paravirt.c |  83 +++---
 arch/x86/kernel/paravirt_patch.c   | 109 
 arch/x86/kernel/tsc.c  |   3 +-
 arch/x86/xen/enlighten_pv.c|  36 ++--
 arch/x86/xen/irq.c |  23 ---
 arch/x86/xen/time.c|  12 +-
 arch/x86/xen/xen-asm.S |  52 +-
 arch/x86/xen/xen-ops.h |   3 -
 drivers/clocksource/hyperv_timer.c |   5 +-
 drivers/xen/time.c |   3 +-
 kernel/sched/sched.h   |   1 +
 tools/objtool/check.c  | 180 ++--
 tools/objtool/check.h  |   5 +
 tools/objtool/orc_gen.c| 178 +---
 34 files changed, 627 insertions(+), 686 deletions(-)
 create mode 100644 arch/x86/include/asm/paravirt_time.h
 delete mode 100644 arch/x86/kernel/paravirt_patch.c

-- 
2.26.2



[PATCH v3 03/15] x86/pv: switch SWAPGS to ALTERNATIVE

2020-12-17 Thread Juergen Gross
SWAPGS is used only for interrupts coming from user mode or for
returning to user mode. So there is no reason to use the PARAVIRT
framework, as it can easily be replaced by an ALTERNATIVE depending
on X86_FEATURE_XENPV.

There are several instances using the PV-aware SWAPGS macro in paths
which are never executed in a Xen PV guest. Replace those with the
plain swapgs instruction. For SWAPGS_UNSAFE_STACK the same applies.

Signed-off-by: Juergen Gross 
Acked-by: Andy Lutomirski 
Acked-by: Peter Zijlstra (Intel) 
Reviewed-by: Borislav Petkov 
Reviewed-by: Thomas Gleixner 
---
 arch/x86/entry/entry_64.S | 10 +-
 arch/x86/include/asm/irqflags.h   | 20 
 arch/x86/include/asm/paravirt.h   | 20 
 arch/x86/include/asm/paravirt_types.h |  2 --
 arch/x86/kernel/asm-offsets_64.c  |  1 -
 arch/x86/kernel/paravirt.c|  1 -
 arch/x86/kernel/paravirt_patch.c  |  3 ---
 arch/x86/xen/enlighten_pv.c   |  3 ---
 8 files changed, 13 insertions(+), 47 deletions(-)

diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
index cad08703c4ad..a876204a73e0 100644
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -669,7 +669,7 @@ native_irq_return_ldt:
 */
 
pushq   %rdi/* Stash user RDI */
-   SWAPGS  /* to kernel GS */
+   swapgs  /* to kernel GS */
SWITCH_TO_KERNEL_CR3 scratch_reg=%rdi   /* to kernel CR3 */
 
movqPER_CPU_VAR(espfix_waddr), %rdi
@@ -699,7 +699,7 @@ native_irq_return_ldt:
orq PER_CPU_VAR(espfix_stack), %rax
 
SWITCH_TO_USER_CR3_STACK scratch_reg=%rdi
-   SWAPGS  /* to user GS */
+   swapgs  /* to user GS */
popq%rdi/* Restore user RDI */
 
movq%rax, %rsp
@@ -943,7 +943,7 @@ SYM_CODE_START_LOCAL(paranoid_entry)
ret
 
 .Lparanoid_entry_swapgs:
-   SWAPGS
+   swapgs
 
/*
 * The above SAVE_AND_SWITCH_TO_KERNEL_CR3 macro doesn't do an
@@ -1001,7 +1001,7 @@ SYM_CODE_START_LOCAL(paranoid_exit)
jnz restore_regs_and_return_to_kernel
 
/* We are returning to a context with user GSBASE */
-   SWAPGS_UNSAFE_STACK
+   swapgs
jmp restore_regs_and_return_to_kernel
 SYM_CODE_END(paranoid_exit)
 
@@ -1426,7 +1426,7 @@ nmi_no_fsgsbase:
jnz nmi_restore
 
 nmi_swapgs:
-   SWAPGS_UNSAFE_STACK
+   swapgs
 
 nmi_restore:
POP_REGS
diff --git a/arch/x86/include/asm/irqflags.h b/arch/x86/include/asm/irqflags.h
index 2dfc8d380dab..8c86edefa115 100644
--- a/arch/x86/include/asm/irqflags.h
+++ b/arch/x86/include/asm/irqflags.h
@@ -131,18 +131,6 @@ static __always_inline unsigned long 
arch_local_irq_save(void)
 #define SAVE_FLAGS(x)  pushfq; popq %rax
 #endif
 
-#define SWAPGS swapgs
-/*
- * Currently paravirt can't handle swapgs nicely when we
- * don't have a stack we can rely on (such as a user space
- * stack).  So we either find a way around these or just fault
- * and emulate if a guest tries to call swapgs directly.
- *
- * Either way, this is a good way to document that we don't
- * have a reliable stack. x86_64 only.
- */
-#define SWAPGS_UNSAFE_STACKswapgs
-
 #define INTERRUPT_RETURN   jmp native_iret
 #define USERGS_SYSRET64\
swapgs; \
@@ -170,6 +158,14 @@ static __always_inline int arch_irqs_disabled(void)
 
return arch_irqs_disabled_flags(flags);
 }
+#else
+#ifdef CONFIG_X86_64
+#ifdef CONFIG_XEN_PV
+#define SWAPGS ALTERNATIVE "swapgs", "", X86_FEATURE_XENPV
+#else
+#define SWAPGS swapgs
+#endif
+#endif
 #endif /* !__ASSEMBLY__ */
 
 #endif
diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index f8dce11d2bc1..f2ebe109a37e 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -776,26 +776,6 @@ extern void default_banner(void);
 
 #ifdef CONFIG_X86_64
 #ifdef CONFIG_PARAVIRT_XXL
-/*
- * If swapgs is used while the userspace stack is still current,
- * there's no way to call a pvop.  The PV replacement *must* be
- * inlined, or the swapgs instruction must be trapped and emulated.
- */
-#define SWAPGS_UNSAFE_STACK\
-   PARA_SITE(PARA_PATCH(PV_CPU_swapgs), swapgs)
-
-/*
- * Note: swapgs is very special, and in practise is either going to be
- * implemented with a single "swapgs" instruction or something very
- * special.  Either way, we don't need to save any registers for
- * it.
- */
-#define SWAPGS \
-   PARA_SITE(PARA_PATCH(PV_CPU_swapgs),\
- ANNOTATE_RETPOLINE_SAFE;  \
- call

[PATCH v3 02/15] x86/xen: use specific Xen pv interrupt entry for DF

2020-12-17 Thread Juergen Gross
Xen PV guests don't use IST. For double fault interrupts switch to
the same model as NMI.

Correct a typo in a comment while copying it.

Signed-off-by: Juergen Gross 
Acked-by: Peter Zijlstra (Intel) 
Reviewed-by: Thomas Gleixner 
---
V2:
- fix typo (Andy Lutomirski)
---
 arch/x86/include/asm/idtentry.h |  3 +++
 arch/x86/xen/enlighten_pv.c | 10 --
 arch/x86/xen/xen-asm.S  |  2 +-
 3 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/arch/x86/include/asm/idtentry.h b/arch/x86/include/asm/idtentry.h
index 5dd64404715a..3ac84cb702fc 100644
--- a/arch/x86/include/asm/idtentry.h
+++ b/arch/x86/include/asm/idtentry.h
@@ -608,6 +608,9 @@ DECLARE_IDTENTRY_RAW(X86_TRAP_DB,   xenpv_exc_debug);
 
 /* #DF */
 DECLARE_IDTENTRY_DF(X86_TRAP_DF,   exc_double_fault);
+#ifdef CONFIG_XEN_PV
+DECLARE_IDTENTRY_RAW_ERRORCODE(X86_TRAP_DF,xenpv_exc_double_fault);
+#endif
 
 /* #VC */
 #ifdef CONFIG_AMD_MEM_ENCRYPT
diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
index 9f5e44c1f70a..76616024129e 100644
--- a/arch/x86/xen/enlighten_pv.c
+++ b/arch/x86/xen/enlighten_pv.c
@@ -567,10 +567,16 @@ void noist_exc_debug(struct pt_regs *regs);
 
 DEFINE_IDTENTRY_RAW(xenpv_exc_nmi)
 {
-   /* On Xen PV, NMI doesn't use IST.  The C part is the sane as native. */
+   /* On Xen PV, NMI doesn't use IST.  The C part is the same as native. */
exc_nmi(regs);
 }
 
+DEFINE_IDTENTRY_RAW_ERRORCODE(xenpv_exc_double_fault)
+{
+   /* On Xen PV, DF doesn't use IST.  The C part is the same as native. */
+   exc_double_fault(regs, error_code);
+}
+
 DEFINE_IDTENTRY_RAW(xenpv_exc_debug)
 {
/*
@@ -615,7 +621,7 @@ struct trap_array_entry {
 
 static struct trap_array_entry trap_array[] = {
TRAP_ENTRY_REDIR(exc_debug, true  ),
-   TRAP_ENTRY(exc_double_fault,true  ),
+   TRAP_ENTRY_REDIR(exc_double_fault,  true  ),
 #ifdef CONFIG_X86_MCE
TRAP_ENTRY_REDIR(exc_machine_check, true  ),
 #endif
diff --git a/arch/x86/xen/xen-asm.S b/arch/x86/xen/xen-asm.S
index bc2586730a5b..1d054c915046 100644
--- a/arch/x86/xen/xen-asm.S
+++ b/arch/x86/xen/xen-asm.S
@@ -161,7 +161,7 @@ xen_pv_trap asm_exc_overflow
 xen_pv_trap asm_exc_bounds
 xen_pv_trap asm_exc_invalid_op
 xen_pv_trap asm_exc_device_not_available
-xen_pv_trap asm_exc_double_fault
+xen_pv_trap asm_xenpv_exc_double_fault
 xen_pv_trap asm_exc_coproc_segment_overrun
 xen_pv_trap asm_exc_invalid_tss
 xen_pv_trap asm_exc_segment_not_present
-- 
2.26.2



[PATCH v3 01/15] x86/xen: use specific Xen pv interrupt entry for MCE

2020-12-17 Thread Juergen Gross
Xen PV guests don't use IST. For machine check interrupts switch to
the same model as debug interrupts.

Signed-off-by: Juergen Gross 
Acked-by: Peter Zijlstra (Intel) 
Reviewed-by: Thomas Gleixner 
---
 arch/x86/include/asm/idtentry.h |  3 +++
 arch/x86/xen/enlighten_pv.c | 16 +++-
 arch/x86/xen/xen-asm.S  |  2 +-
 3 files changed, 19 insertions(+), 2 deletions(-)

diff --git a/arch/x86/include/asm/idtentry.h b/arch/x86/include/asm/idtentry.h
index 247a60a47331..5dd64404715a 100644
--- a/arch/x86/include/asm/idtentry.h
+++ b/arch/x86/include/asm/idtentry.h
@@ -585,6 +585,9 @@ DECLARE_IDTENTRY_MCE(X86_TRAP_MC,   exc_machine_check);
 #else
 DECLARE_IDTENTRY_RAW(X86_TRAP_MC,  exc_machine_check);
 #endif
+#ifdef CONFIG_XEN_PV
+DECLARE_IDTENTRY_RAW(X86_TRAP_MC,  xenpv_exc_machine_check);
+#endif
 #endif
 
 /* NMI */
diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
index 4409306364dc..9f5e44c1f70a 100644
--- a/arch/x86/xen/enlighten_pv.c
+++ b/arch/x86/xen/enlighten_pv.c
@@ -583,6 +583,20 @@ DEFINE_IDTENTRY_RAW(xenpv_exc_debug)
exc_debug(regs);
 }
 
+#ifdef CONFIG_X86_MCE
+DEFINE_IDTENTRY_RAW(xenpv_exc_machine_check)
+{
+   /*
+* There's no IST on Xen PV, but we still need to dispatch
+* to the correct handler.
+*/
+   if (user_mode(regs))
+   noist_exc_machine_check(regs);
+   else
+   exc_machine_check(regs);
+}
+#endif
+
 struct trap_array_entry {
void (*orig)(void);
void (*xen)(void);
@@ -603,7 +617,7 @@ static struct trap_array_entry trap_array[] = {
TRAP_ENTRY_REDIR(exc_debug, true  ),
TRAP_ENTRY(exc_double_fault,true  ),
 #ifdef CONFIG_X86_MCE
-   TRAP_ENTRY(exc_machine_check,   true  ),
+   TRAP_ENTRY_REDIR(exc_machine_check, true  ),
 #endif
TRAP_ENTRY_REDIR(exc_nmi,   true  ),
TRAP_ENTRY(exc_int3,false ),
diff --git a/arch/x86/xen/xen-asm.S b/arch/x86/xen/xen-asm.S
index 1cb0e84b9161..bc2586730a5b 100644
--- a/arch/x86/xen/xen-asm.S
+++ b/arch/x86/xen/xen-asm.S
@@ -172,7 +172,7 @@ xen_pv_trap asm_exc_spurious_interrupt_bug
 xen_pv_trap asm_exc_coprocessor_error
 xen_pv_trap asm_exc_alignment_check
 #ifdef CONFIG_X86_MCE
-xen_pv_trap asm_exc_machine_check
+xen_pv_trap asm_xenpv_exc_machine_check
 #endif /* CONFIG_X86_MCE */
 xen_pv_trap asm_exc_simd_coprocessor_error
 #ifdef CONFIG_IA32_EMULATION
-- 
2.26.2



[PATCH v3 13/15] x86/paravirt: add new macros PVOP_ALT* supporting pvops in ALTERNATIVEs

2020-12-17 Thread Juergen Gross
Instead of using paravirt patching for custom code sequences add
support for using ALTERNATIVE handling combined with paravirt call
patching.

Signed-off-by: Juergen Gross 
---
V3:
- drop PVOP_ALT_VCALL() macro
---
 arch/x86/include/asm/paravirt_types.h | 49 +++
 1 file changed, 49 insertions(+)

diff --git a/arch/x86/include/asm/paravirt_types.h 
b/arch/x86/include/asm/paravirt_types.h
index 5d6de014d2f6..7e0130781b12 100644
--- a/arch/x86/include/asm/paravirt_types.h
+++ b/arch/x86/include/asm/paravirt_types.h
@@ -477,44 +477,93 @@ int paravirt_disable_iospace(void);
(rettype)(__eax & PVOP_RETMASK(rettype));   \
})
 
+#define PVOP_ALT_CALL(rettype, op, alt, cond, clbr, call_clbr, \
+ extra_clbr, ...)  \
+   ({  \
+   PVOP_CALL_ARGS; \
+   PVOP_TEST_NULL(op); \
+   BUILD_BUG_ON(sizeof(rettype) > sizeof(unsigned long));  \
+   asm volatile(ALTERNATIVE(paravirt_alt(PARAVIRT_CALL),   \
+alt, cond) \
+: call_clbr, ASM_CALL_CONSTRAINT   \
+: paravirt_type(op),   \
+  paravirt_clobber(clbr),  \
+  ##__VA_ARGS__\
+: "memory", "cc" extra_clbr);  \
+   (rettype)(__eax & PVOP_RETMASK(rettype));   \
+   })
+
 #define __PVOP_CALL(rettype, op, ...)  \
PVOP_CALL(rettype, op, CLBR_ANY, PVOP_CALL_CLOBBERS,\
  EXTRA_CLOBBERS, ##__VA_ARGS__)
 
+#define __PVOP_ALT_CALL(rettype, op, alt, cond, ...)   \
+   PVOP_ALT_CALL(rettype, op, alt, cond, CLBR_ANY, \
+ PVOP_CALL_CLOBBERS, EXTRA_CLOBBERS,   \
+ ##__VA_ARGS__)
+
 #define __PVOP_CALLEESAVE(rettype, op, ...)\
PVOP_CALL(rettype, op.func, CLBR_RET_REG,   \
  PVOP_CALLEE_CLOBBERS, , ##__VA_ARGS__)
 
+#define __PVOP_ALT_CALLEESAVE(rettype, op, alt, cond, ...) \
+   PVOP_ALT_CALL(rettype, op.func, alt, cond, CLBR_RET_REG,\
+ PVOP_CALLEE_CLOBBERS, , ##__VA_ARGS__)
+
+
 #define __PVOP_VCALL(op, ...)  \
(void)PVOP_CALL(long, op, CLBR_ANY, PVOP_VCALL_CLOBBERS,\
   VEXTRA_CLOBBERS, ##__VA_ARGS__)
 
+#define __PVOP_ALT_VCALL(op, alt, cond, ...)   \
+   (void)PVOP_ALT_CALL(long, op, alt, cond, CLBR_ANY,  \
+  PVOP_VCALL_CLOBBERS, VEXTRA_CLOBBERS,\
+  ##__VA_ARGS__)
+
 #define __PVOP_VCALLEESAVE(op, ...)\
(void)PVOP_CALL(long, op.func, CLBR_RET_REG,\
  PVOP_VCALLEE_CLOBBERS, , ##__VA_ARGS__)
 
+#define __PVOP_ALT_VCALLEESAVE(op, alt, cond, ...) \
+   (void)PVOP_ALT_CALL(long, op.func, alt, cond, CLBR_RET_REG, \
+  PVOP_VCALLEE_CLOBBERS, , ##__VA_ARGS__)
+
 
 
 #define PVOP_CALL0(rettype, op)
\
__PVOP_CALL(rettype, op)
 #define PVOP_VCALL0(op)
\
__PVOP_VCALL(op)
+#define PVOP_ALT_CALL0(rettype, op, alt, cond) \
+   __PVOP_ALT_CALL(rettype, op, alt, cond)
+#define PVOP_ALT_VCALL0(op, alt, cond) \
+   __PVOP_ALT_VCALL(op, alt, cond)
 
 #define PVOP_CALLEE0(rettype, op)  \
__PVOP_CALLEESAVE(rettype, op)
 #define PVOP_VCALLEE0(op)  \
__PVOP_VCALLEESAVE(op)
+#define PVOP_ALT_CALLEE0(rettype, op, alt, cond)   \
+   __PVOP_ALT_CALLEESAVE(rettype, op, alt, cond)
+#define PVOP_ALT_VCALLEE0(op, alt, cond)   \
+   __PVOP_ALT_VCALLEESAVE(op, alt, cond)
 
 
 #define PVOP_CALL1(rettype, op, arg1)  \
__PVOP_CALL(rettype, op, PVOP_CALL_ARG1(arg1))
 #define PVOP_VCALL1(op, arg1)  \
__PVOP_VCALL(op, PVOP_CALL_ARG1(arg1))
+#define PVOP_ALT_VCALL1(op, arg1, alt, cond)   \
+   __PVOP_ALT_VCALL(op, alt, cond, PVOP_CALL_ARG1(arg1))
 
 #define PVOP_CALLEE1(rettype, op, arg1)
\
__PVOP_CALLEESAVE(rettype, op, PVOP_CALL_ARG1(ar

[PATCH v3 07/15] x86/alternative: support "not feature" and ALTERNATIVE_TERNARY

2020-12-17 Thread Juergen Gross
Instead of only supporting to modify instructions when a specific
feature is set, support doing so for the case a feature is not set.

As today a feature is specified using a 16 bit quantity and the highest
feature number in use is around 600, using a negated feature number for
specifying the inverted case seems to be appropriate.

  ALTERNATIVE "default_instr", "patched_instr", ~FEATURE_NR

will start with "default_instr" and patch that with "patched_instr" in
case FEATURE_NR is not set.

Using that add ALTERNATIVE_TERNARY:

  ALTERNATIVE_TERNARY "default_instr", FEATURE_NR,
  "feature_on_instr", "feature_off_instr"

which will start with "default_instr" and at patch time will, depending
on FEATURE_NR being set or not, patch that with either
"feature_on_instr" or "feature_off_instr".

Signed-off-by: Juergen Gross 
---
V3:
- new patch
---
 arch/x86/include/asm/alternative-asm.h |  3 +++
 arch/x86/include/asm/alternative.h |  7 +++
 arch/x86/kernel/alternative.c  | 17 -
 3 files changed, 22 insertions(+), 5 deletions(-)

diff --git a/arch/x86/include/asm/alternative-asm.h 
b/arch/x86/include/asm/alternative-asm.h
index 464034db299f..b6989995fddf 100644
--- a/arch/x86/include/asm/alternative-asm.h
+++ b/arch/x86/include/asm/alternative-asm.h
@@ -109,6 +109,9 @@
.popsection
 .endm
 
+#define ALTERNATIVE_TERNARY(oldinstr, feature, newinstr1, newinstr2)   \
+   ALTERNATIVE_2 oldinstr, newinstr1, feature, newinstr2, ~(feature)
+
 #endif  /*  __ASSEMBLY__  */
 
 #endif /* _ASM_X86_ALTERNATIVE_ASM_H */
diff --git a/arch/x86/include/asm/alternative.h 
b/arch/x86/include/asm/alternative.h
index 13adca37c99a..a0f8f33609aa 100644
--- a/arch/x86/include/asm/alternative.h
+++ b/arch/x86/include/asm/alternative.h
@@ -59,6 +59,7 @@ struct alt_instr {
s32 instr_offset;   /* original instruction */
s32 repl_offset;/* offset to replacement instruction */
u16 cpuid;  /* cpuid bit set for replacement */
+#define ALT_INSTR_CPUID_INV0x8000  /* patch if ~cpuid bit is NOT set */
u8  instrlen;   /* length of original instruction */
u8  replacementlen; /* length of new instruction */
u8  padlen; /* length of build-time padding */
@@ -175,6 +176,9 @@ static inline int alternatives_text_reserved(void *start, 
void *end)
ALTINSTR_REPLACEMENT(newinstr2, feature2, 2)\
".popsection\n"
 
+#define ALTERNATIVE_TERNARY(oldinstr, feature, newinstr1, newinstr2)   \
+   ALTERNATIVE_2(oldinstr, newinstr1, feature, newinstr2, ~(feature))
+
 #define ALTERNATIVE_3(oldinsn, newinsn1, feat1, newinsn2, feat2, newinsn3, 
feat3) \
OLDINSTR_3(oldinsn, 1, 2, 3)
\
".pushsection .altinstructions,\"a\"\n" 
\
@@ -206,6 +210,9 @@ static inline int alternatives_text_reserved(void *start, 
void *end)
 #define alternative_2(oldinstr, newinstr1, feature1, newinstr2, feature2) \
asm_inline volatile(ALTERNATIVE_2(oldinstr, newinstr1, feature1, 
newinstr2, feature2) ::: "memory")
 
+#define alternative_ternary(oldinstr, feature, newinstr1, newinstr2)   \
+   asm_inline volatile(ALTERNATIVE_TERNARY(oldinstr, feature, newinstr1, 
newinstr2) ::: "memory")
+
 /*
  * Alternative inline assembly with input.
  *
diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c
index 8d778e46725d..0a904fb2678b 100644
--- a/arch/x86/kernel/alternative.c
+++ b/arch/x86/kernel/alternative.c
@@ -388,21 +388,28 @@ void __init_or_module noinline apply_alternatives(struct 
alt_instr *start,
 */
for (a = start; a < end; a++) {
int insn_buff_sz = 0;
+   u16 feature;
+   bool not_feature;
 
instr = (u8 *)&a->instr_offset + a->instr_offset;
replacement = (u8 *)&a->repl_offset + a->repl_offset;
+   feature = a->cpuid;
+   not_feature = feature & ALT_INSTR_CPUID_INV;
+   if (not_feature)
+   feature = ~feature;
BUG_ON(a->instrlen > sizeof(insn_buff));
-   BUG_ON(a->cpuid >= (NCAPINTS + NBUGINTS) * 32);
-   if (!boot_cpu_has(a->cpuid)) {
+   BUG_ON(feature >= (NCAPINTS + NBUGINTS) * 32);
+   if (!!boot_cpu_has(feature) == not_feature) {
if (a->padlen > 1)
optimize_nops(a, instr);
 
continue;
}
 
-   DPRINTK("feat: %d*32+%d, old: (%pS (%px) len: %d), repl: (%px, 
len: %d), pad: %d",
-   a->cpuid >> 5,
-   a->cpuid & 0x1f,
+   DPRINTK("feat: %s%d*32+%d, old: (%pS (%px) len: %d), repl: 
(%px, len: %d), pad: %d",
+   not_feature ? "~" : "",
+   feature >> 5,
+   

[PATCH v3 10/15] x86/paravirt: simplify paravirt macros

2020-12-17 Thread Juergen Gross
The central pvops call macros PVOP_CALL() and PVOP_VCALL() are
looking very similar now.

The main differences are using PVOP_VCALL_ARGS or PVOP_CALL_ARGS, which
are identical, and the return value handling.

So drop PVOP_VCALL_ARGS and instead of PVOP_VCALL() just use
(void)PVOP_CALL(long, ...).

Note that it isn't easily possible to just redefine PVOP_VCALL()
to use PVOP_CALL() instead, as this would require further hiding of
commas in macro parameters.

Signed-off-by: Juergen Gross 
---
V3:
- new patch
---
 arch/x86/include/asm/paravirt_types.h | 25 -
 1 file changed, 4 insertions(+), 21 deletions(-)

diff --git a/arch/x86/include/asm/paravirt_types.h 
b/arch/x86/include/asm/paravirt_types.h
index 42f9eef84131..a9efd4dad820 100644
--- a/arch/x86/include/asm/paravirt_types.h
+++ b/arch/x86/include/asm/paravirt_types.h
@@ -408,11 +408,9 @@ int paravirt_disable_iospace(void);
  * makes sure the incoming and outgoing types are always correct.
  */
 #ifdef CONFIG_X86_32
-#define PVOP_VCALL_ARGS
\
+#define PVOP_CALL_ARGS \
unsigned long __eax = __eax, __edx = __edx, __ecx = __ecx;
 
-#define PVOP_CALL_ARGS PVOP_VCALL_ARGS
-
 #define PVOP_CALL_ARG1(x)  "a" ((unsigned long)(x))
 #define PVOP_CALL_ARG2(x)  "d" ((unsigned long)(x))
 #define PVOP_CALL_ARG3(x)  "c" ((unsigned long)(x))
@@ -428,12 +426,10 @@ int paravirt_disable_iospace(void);
 #define VEXTRA_CLOBBERS
 #else  /* CONFIG_X86_64 */
 /* [re]ax isn't an arg, but the return val */
-#define PVOP_VCALL_ARGS\
+#define PVOP_CALL_ARGS \
unsigned long __edi = __edi, __esi = __esi, \
__edx = __edx, __ecx = __ecx, __eax = __eax;
 
-#define PVOP_CALL_ARGS PVOP_VCALL_ARGS
-
 #define PVOP_CALL_ARG1(x)  "D" ((unsigned long)(x))
 #define PVOP_CALL_ARG2(x)  "S" ((unsigned long)(x))
 #define PVOP_CALL_ARG3(x)  "d" ((unsigned long)(x))
@@ -492,25 +488,12 @@ int paravirt_disable_iospace(void);
PVOP_CALL(rettype, op.func, CLBR_RET_REG,   \
  PVOP_CALLEE_CLOBBERS, , ##__VA_ARGS__)
 
-
-#define PVOP_VCALL(op, clbr, call_clbr, extra_clbr, ...)   \
-   ({  \
-   PVOP_VCALL_ARGS;\
-   PVOP_TEST_NULL(op); \
-   asm volatile(paravirt_alt(PARAVIRT_CALL)\
-: call_clbr, ASM_CALL_CONSTRAINT   \
-: paravirt_type(op),   \
-  paravirt_clobber(clbr),  \
-  ##__VA_ARGS__\
-: "memory", "cc" extra_clbr);  \
-   })
-
 #define __PVOP_VCALL(op, ...)  \
-   PVOP_VCALL(op, CLBR_ANY, PVOP_VCALL_CLOBBERS,   \
+   (void)PVOP_CALL(long, op, CLBR_ANY, PVOP_VCALL_CLOBBERS,\
   VEXTRA_CLOBBERS, ##__VA_ARGS__)
 
 #define __PVOP_VCALLEESAVE(op, ...)\
-   PVOP_VCALL(op.func, CLBR_RET_REG,   \
+   (void)PVOP_CALL(long, op.func, CLBR_RET_REG,\
  PVOP_VCALLEE_CLOBBERS, , ##__VA_ARGS__)
 
 
-- 
2.26.2



[PATCH v3 15/15] x86/paravirt: have only one paravirt patch function

2020-12-17 Thread Juergen Gross
There is no need any longer to have different paravirt patch functions
for native and Xen. Eliminate native_patch() and rename
paravirt_patch_default() to paravirt_patch().

Signed-off-by: Juergen Gross 
---
V3:
- remove paravirt_patch_insns() (kernel test robot)
---
 arch/x86/include/asm/paravirt_types.h | 19 +--
 arch/x86/kernel/Makefile  |  3 +--
 arch/x86/kernel/alternative.c |  2 +-
 arch/x86/kernel/paravirt.c| 20 ++--
 arch/x86/kernel/paravirt_patch.c  | 11 ---
 arch/x86/xen/enlighten_pv.c   |  1 -
 6 files changed, 5 insertions(+), 51 deletions(-)
 delete mode 100644 arch/x86/kernel/paravirt_patch.c

diff --git a/arch/x86/include/asm/paravirt_types.h 
b/arch/x86/include/asm/paravirt_types.h
index f9e77046b61b..5c728eab9cd1 100644
--- a/arch/x86/include/asm/paravirt_types.h
+++ b/arch/x86/include/asm/paravirt_types.h
@@ -73,19 +73,6 @@ struct pv_info {
const char *name;
 };
 
-struct pv_init_ops {
-   /*
-* Patch may replace one of the defined code sequences with
-* arbitrary code, subject to the same register constraints.
-* This generally means the code is not free to clobber any
-* registers other than EAX.  The patch function should return
-* the number of bytes of code generated, as we nop pad the
-* rest in generic code.
-*/
-   unsigned (*patch)(u8 type, void *insn_buff,
- unsigned long addr, unsigned len);
-} __no_randomize_layout;
-
 #ifdef CONFIG_PARAVIRT_XXL
 struct pv_lazy_ops {
/* Set deferred update mode, used for batching operations. */
@@ -281,7 +268,6 @@ struct pv_lock_ops {
  * number for each function using the offset which we use to indicate
  * what to patch. */
 struct paravirt_patch_template {
-   struct pv_init_ops  init;
struct pv_cpu_ops   cpu;
struct pv_irq_ops   irq;
struct pv_mmu_ops   mmu;
@@ -322,10 +308,7 @@ extern void (*paravirt_iret)(void);
 /* Simple instruction patching code. */
 #define NATIVE_LABEL(a,x,b) "\n\t.globl " a #x "_" #b "\n" a #x "_" #b ":\n\t"
 
-unsigned paravirt_patch_default(u8 type, void *insn_buff, unsigned long addr, 
unsigned len);
-unsigned paravirt_patch_insns(void *insn_buff, unsigned len, const char 
*start, const char *end);
-
-unsigned native_patch(u8 type, void *insn_buff, unsigned long addr, unsigned 
len);
+unsigned paravirt_patch(u8 type, void *insn_buff, unsigned long addr, unsigned 
len);
 
 int paravirt_disable_iospace(void);
 
diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index 68608bd892c0..61f52f95670b 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -35,7 +35,6 @@ KASAN_SANITIZE_sev-es.o   
:= n
 KCSAN_SANITIZE := n
 
 OBJECT_FILES_NON_STANDARD_test_nx.o:= y
-OBJECT_FILES_NON_STANDARD_paravirt_patch.o := y
 
 ifdef CONFIG_FRAME_POINTER
 OBJECT_FILES_NON_STANDARD_ftrace_$(BITS).o := y
@@ -122,7 +121,7 @@ obj-$(CONFIG_AMD_NB)+= amd_nb.o
 obj-$(CONFIG_DEBUG_NMI_SELFTEST) += nmi_selftest.o
 
 obj-$(CONFIG_KVM_GUEST)+= kvm.o kvmclock.o
-obj-$(CONFIG_PARAVIRT) += paravirt.o paravirt_patch.o
+obj-$(CONFIG_PARAVIRT) += paravirt.o
 obj-$(CONFIG_PARAVIRT_SPINLOCKS)+= paravirt-spinlocks.o
 obj-$(CONFIG_PARAVIRT_CLOCK)   += pvclock.o
 obj-$(CONFIG_X86_PMEM_LEGACY_DEVICE) += pmem.o
diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c
index abb481808811..1dbd6a934b66 100644
--- a/arch/x86/kernel/alternative.c
+++ b/arch/x86/kernel/alternative.c
@@ -621,7 +621,7 @@ void __init_or_module apply_paravirt(struct 
paravirt_patch_site *start,
BUG_ON(p->len > MAX_PATCH_LEN);
/* prep the buffer with the original instructions */
memcpy(insn_buff, p->instr, p->len);
-   used = pv_ops.init.patch(p->type, insn_buff, (unsigned 
long)p->instr, p->len);
+   used = paravirt_patch(p->type, insn_buff, (unsigned 
long)p->instr, p->len);
 
BUG_ON(used > p->len);
 
diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c
index db6ae7f7c14e..b648eaf640f2 100644
--- a/arch/x86/kernel/paravirt.c
+++ b/arch/x86/kernel/paravirt.c
@@ -99,8 +99,8 @@ void __init native_pv_lock_init(void)
static_branch_disable(&virt_spin_lock_key);
 }
 
-unsigned paravirt_patch_default(u8 type, void *insn_buff,
-   unsigned long addr, unsigned len)
+unsigned int paravirt_patch(u8 type, void *insn_buff, unsigned long addr,
+   unsigned int len)
 {
/*
 * Neat trick to map patch type back to the call within the
@@ -121,19 +121,6 @@ unsigned paravirt_patch_default(u8 type, void *insn_buff,
return ret;
 }
 
-unsigned paravirt_patch_insns(void *insn_buff, unsigned len,
-   

[PATCH v3 12/15] objtool: Alternatives vs ORC, the hard way

2020-12-17 Thread Juergen Gross
From: Peter Zijlstra 

Alternatives pose an interesting problem for unwinders because from
the unwinders PoV we're just executing instructions, it has no idea
the text is modified, nor any way of retrieving what with.

Therefore the stance has been that alternatives must not change stack
state, as encoded by commit: 7117f16bf460 ("objtool: Fix ORC vs
alternatives"). This obviously guarantees that whatever actual
instructions end up in the text, the unwind information is correct.

However, there is one additional source of text patching that isn't
currently visible to objtool: paravirt immediate patching. And it
turns out one of these violates the rule.

As part of cleaning that up, the unfortunate reality is that objtool
now has to deal with alternatives modifying unwind state and validate
the combination is valid and generate ORC data to match.

The problem is that a single instance of unwind information (ORC) must
capture and correctly unwind all alternatives. Since the trivially
correct mandate is out, implement the straight forward brute-force
approach:

 1) generate CFI information for each alternative

 2) unwind every alternative with the merge-sort of the previously
generated CFI information -- O(n^2)

 3) for any possible conflict: yell.

 4) Generate ORC with merge-sort

Specifically for 3 there are two possible classes of conflicts:

 - the merge-sort itself could find conflicting CFI for the same
   offset.

 - the unwind can fail with the merged CFI.

In specific, this allows us to deal with:

Alt1Alt2Alt3

 0x00   CALL *pv_ops.save_flCALL xen_save_flPUSHF
 0x01   POP %RAX
 0x02   NOP
 ...
 0x05   NOP
 ...
 0x07   

The unwind information for offset-0x00 is identical for all 3
alternatives. Similarly offset-0x05 and higher also are identical (and
the same as 0x00). However offset-0x01 has deviating CFI, but that is
only relevant for Alt3, neither of the other alternative instruction
streams will ever hit that offset.

Signed-off-by: Peter Zijlstra (Intel) 
---
V3:
- new patch; there is still an ongoing discussion whether this patch
  couldn't be made simpler, but I'm including it here nevertheless, as
  there is some solution required in objtool for the following patches
  of the series.
Signed-off-by: Juergen Gross 
---
 tools/objtool/check.c   | 180 
 tools/objtool/check.h   |   5 ++
 tools/objtool/orc_gen.c | 178 +--
 3 files changed, 289 insertions(+), 74 deletions(-)

diff --git a/tools/objtool/check.c b/tools/objtool/check.c
index c6ab44543c92..2d70766af857 100644
--- a/tools/objtool/check.c
+++ b/tools/objtool/check.c
@@ -1090,6 +1090,32 @@ static int handle_group_alt(struct objtool_file *file,
return -1;
}
 
+   /*
+* Add the filler NOP, required for alternative CFI.
+*/
+   if (special_alt->group && special_alt->new_len < special_alt->orig_len) 
{
+   struct instruction *nop = malloc(sizeof(*nop));
+   if (!nop) {
+   WARN("malloc failed");
+   return -1;
+   }
+   memset(nop, 0, sizeof(*nop));
+   INIT_LIST_HEAD(&nop->alts);
+   INIT_LIST_HEAD(&nop->stack_ops);
+   init_cfi_state(&nop->cfi);
+
+   nop->sec = last_new_insn->sec;
+   nop->ignore = last_new_insn->ignore;
+   nop->func = last_new_insn->func;
+   nop->alt_group = alt_group;
+   nop->offset = last_new_insn->offset + last_new_insn->len;
+   nop->type = INSN_NOP;
+   nop->len = special_alt->orig_len - special_alt->new_len;
+
+   list_add(&nop->list, &last_new_insn->list);
+   last_new_insn = nop;
+   }
+
if (fake_jump)
list_add(&fake_jump->list, &last_new_insn->list);
 
@@ -2190,18 +2216,12 @@ static int handle_insn_ops(struct instruction *insn, 
struct insn_state *state)
struct stack_op *op;
 
list_for_each_entry(op, &insn->stack_ops, list) {
-   struct cfi_state old_cfi = state->cfi;
int res;
 
res = update_cfi_state(insn, &state->cfi, op);
if (res)
return res;
 
-   if (insn->alt_group && memcmp(&state->cfi, &old_cfi, 
sizeof(struct cfi_state))) {
-   WARN_FUNC("alternative modifies stack", insn->sec, 
insn->offset);
-   return -1;
-   }
-
if (op->dest.type == OP_DEST_PUSHF) {
if (!state->uaccess_stack) {
state->uaccess_stack = 1;
@@ -2399,19 +2419,137 @@ static int validate_return(struct symbol *func, struct 
instruction *insn, stru

[PATCH v3 08/15] x86: add new features for paravirt patching

2020-12-17 Thread Juergen Gross
For being able to switch paravirt patching from special cased custom
code sequences to ALTERNATIVE handling some X86_FEATURE_* are needed
as new features. This enables to have the standard indirect pv call
as the default code and to patch that with the non-Xen custom code
sequence via ALTERNATIVE patching later.

Make sure paravirt patching is performed before alternative patching.

Signed-off-by: Juergen Gross 
---
V3:
- add comment (Boris Petkov)
- no negative features (Boris Petkov)
---
 arch/x86/include/asm/cpufeatures.h |  2 ++
 arch/x86/kernel/alternative.c  | 40 --
 2 files changed, 40 insertions(+), 2 deletions(-)

diff --git a/arch/x86/include/asm/cpufeatures.h 
b/arch/x86/include/asm/cpufeatures.h
index f5ef2d5b9231..1077b675a008 100644
--- a/arch/x86/include/asm/cpufeatures.h
+++ b/arch/x86/include/asm/cpufeatures.h
@@ -237,6 +237,8 @@
 #define X86_FEATURE_VMCALL ( 8*32+18) /* "" Hypervisor supports 
the VMCALL instruction */
 #define X86_FEATURE_VMW_VMMCALL( 8*32+19) /* "" VMware prefers 
VMMCALL hypercall instruction */
 #define X86_FEATURE_SEV_ES ( 8*32+20) /* AMD Secure Encrypted 
Virtualization - Encrypted State */
+#define X86_FEATURE_PVUNLOCK   ( 8*32+21) /* "" PV unlock function */
+#define X86_FEATURE_VCPUPREEMPT( 8*32+22) /* "" PV 
vcpu_is_preempted function */
 
 /* Intel-defined CPU features, CPUID level 0x0007:0 (EBX), word 9 */
 #define X86_FEATURE_FSGSBASE   ( 9*32+ 0) /* RDFSBASE, WRFSBASE, 
RDGSBASE, WRGSBASE instructions*/
diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c
index 0a904fb2678b..abb481808811 100644
--- a/arch/x86/kernel/alternative.c
+++ b/arch/x86/kernel/alternative.c
@@ -600,6 +600,15 @@ int alternatives_text_reserved(void *start, void *end)
 #endif /* CONFIG_SMP */
 
 #ifdef CONFIG_PARAVIRT
+static void __init paravirt_set_cap(void)
+{
+   if (!pv_is_native_spin_unlock())
+   setup_force_cpu_cap(X86_FEATURE_PVUNLOCK);
+
+   if (!pv_is_native_vcpu_is_preempted())
+   setup_force_cpu_cap(X86_FEATURE_VCPUPREEMPT);
+}
+
 void __init_or_module apply_paravirt(struct paravirt_patch_site *start,
 struct paravirt_patch_site *end)
 {
@@ -623,6 +632,8 @@ void __init_or_module apply_paravirt(struct 
paravirt_patch_site *start,
 }
 extern struct paravirt_patch_site __start_parainstructions[],
__stop_parainstructions[];
+#else
+static void __init paravirt_set_cap(void) { }
 #endif /* CONFIG_PARAVIRT */
 
 /*
@@ -730,6 +741,33 @@ void __init alternative_instructions(void)
 * patching.
 */
 
+   /*
+* Paravirt patching and alternative patching can be combined to
+* replace a function call with a short direct code sequence (e.g.
+* by setting a constant return value instead of doing that in an
+* external function).
+* In order to make this work the following sequence is required:
+* 1. set (artificial) features depending on used paravirt
+*functions which can later influence alternative patching
+* 2. apply paravirt patching (generally replacing an indirect
+*function call with a direct one)
+* 3. apply alternative patching (e.g. replacing a direct function
+*call with a custom code sequence)
+* Doing paravirt patching after alternative patching would clobber
+* the optimization of the custom code with a function call again.
+*/
+   paravirt_set_cap();
+
+   /*
+* First patch paravirt functions, such that we overwrite the indirect
+* call with the direct call.
+*/
+   apply_paravirt(__parainstructions, __parainstructions_end);
+
+   /*
+* Then patch alternatives, such that those paravirt calls that are in
+* alternatives can be overwritten by their immediate fragments.
+*/
apply_alternatives(__alt_instructions, __alt_instructions_end);
 
 #ifdef CONFIG_SMP
@@ -748,8 +786,6 @@ void __init alternative_instructions(void)
}
 #endif
 
-   apply_paravirt(__parainstructions, __parainstructions_end);
-
restart_nmi();
alternatives_patched = 1;
 }
-- 
2.26.2



[PATCH v3 04/15] x86/xen: drop USERGS_SYSRET64 paravirt call

2020-12-17 Thread Juergen Gross
USERGS_SYSRET64 is used to return from a syscall via sysret, but
a Xen PV guest will nevertheless use the iret hypercall, as there
is no sysret PV hypercall defined.

So instead of testing all the prerequisites for doing a sysret and
then mangling the stack for Xen PV again for doing an iret just use
the iret exit from the beginning.

This can easily be done via an ALTERNATIVE like it is done for the
sysenter compat case already.

It should be noted that this drops the optimization in Xen for not
restoring a few registers when returning to user mode, but it seems
as if the saved instructions in the kernel more than compensate for
this drop (a kernel build in a Xen PV guest was slightly faster with
this patch applied).

While at it remove the stale sysret32 remnants.

Signed-off-by: Juergen Gross 
---
V3:
- simplify ALTERNATIVE (Boris Petkov)
---
 arch/x86/entry/entry_64.S | 16 +++-
 arch/x86/include/asm/irqflags.h   |  6 --
 arch/x86/include/asm/paravirt.h   |  5 -
 arch/x86/include/asm/paravirt_types.h |  8 
 arch/x86/kernel/asm-offsets_64.c  |  2 --
 arch/x86/kernel/paravirt.c|  5 +
 arch/x86/kernel/paravirt_patch.c  |  4 
 arch/x86/xen/enlighten_pv.c   |  1 -
 arch/x86/xen/xen-asm.S| 20 
 arch/x86/xen/xen-ops.h|  2 --
 10 files changed, 8 insertions(+), 61 deletions(-)

diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
index a876204a73e0..ce0464d630a2 100644
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -46,14 +46,6 @@
 .code64
 .section .entry.text, "ax"
 
-#ifdef CONFIG_PARAVIRT_XXL
-SYM_CODE_START(native_usergs_sysret64)
-   UNWIND_HINT_EMPTY
-   swapgs
-   sysretq
-SYM_CODE_END(native_usergs_sysret64)
-#endif /* CONFIG_PARAVIRT_XXL */
-
 /*
  * 64-bit SYSCALL instruction entry. Up to 6 arguments in registers.
  *
@@ -123,7 +115,12 @@ SYM_INNER_LABEL(entry_SYSCALL_64_after_hwframe, 
SYM_L_GLOBAL)
 * Try to use SYSRET instead of IRET if we're returning to
 * a completely clean 64-bit userspace context.  If we're not,
 * go to the slow exit path.
+* In the Xen PV case we must use iret anyway.
 */
+
+   ALTERNATIVE "", "jmpswapgs_restore_regs_and_return_to_usermode", \
+   X86_FEATURE_XENPV
+
movqRCX(%rsp), %rcx
movqRIP(%rsp), %r11
 
@@ -215,7 +212,8 @@ syscall_return_via_sysret:
 
popq%rdi
popq%rsp
-   USERGS_SYSRET64
+   swapgs
+   sysretq
 SYM_CODE_END(entry_SYSCALL_64)
 
 /*
diff --git a/arch/x86/include/asm/irqflags.h b/arch/x86/include/asm/irqflags.h
index 8c86edefa115..e585a4705b8d 100644
--- a/arch/x86/include/asm/irqflags.h
+++ b/arch/x86/include/asm/irqflags.h
@@ -132,12 +132,6 @@ static __always_inline unsigned long 
arch_local_irq_save(void)
 #endif
 
 #define INTERRUPT_RETURN   jmp native_iret
-#define USERGS_SYSRET64\
-   swapgs; \
-   sysretq;
-#define USERGS_SYSRET32\
-   swapgs; \
-   sysretl
 
 #else
 #define INTERRUPT_RETURN   iret
diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index f2ebe109a37e..dd43b1100a87 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -776,11 +776,6 @@ extern void default_banner(void);
 
 #ifdef CONFIG_X86_64
 #ifdef CONFIG_PARAVIRT_XXL
-#define USERGS_SYSRET64
\
-   PARA_SITE(PARA_PATCH(PV_CPU_usergs_sysret64),   \
- ANNOTATE_RETPOLINE_SAFE;  \
- jmp PARA_INDIRECT(pv_ops+PV_CPU_usergs_sysret64);)
-
 #ifdef CONFIG_DEBUG_ENTRY
 #define SAVE_FLAGS(clobbers)\
PARA_SITE(PARA_PATCH(PV_IRQ_save_fl),   \
diff --git a/arch/x86/include/asm/paravirt_types.h 
b/arch/x86/include/asm/paravirt_types.h
index 130f428b0cc8..0169365f1403 100644
--- a/arch/x86/include/asm/paravirt_types.h
+++ b/arch/x86/include/asm/paravirt_types.h
@@ -156,14 +156,6 @@ struct pv_cpu_ops {
 
u64 (*read_pmc)(int counter);
 
-   /*
-* Switch to usermode gs and return to 64-bit usermode using
-* sysret.  Only used in 64-bit kernels to return to 64-bit
-* processes.  Usermode register state, including %rsp, must
-* already be restored.
-*/
-   void (*usergs_sysret64)(void);
-
/* Normal iret.  Jump to this with the standard iret stack
   frame set up. */
void (*iret)(void);
diff --git a/arch/x86/kernel/asm-offsets_64.c b/arch/x86/kernel/asm-offsets_64.c
index 1354bc30614d..b14533af7676 100644
--- a/arch/x86/kernel/asm-offsets_64.c
+++ b/arch/x86/kernel/asm-offsets_64.c
@@ -13,8 +13,6 @@ int main(voi

[PATCH v3 06/15] x86/paravirt: switch time pvops functions to use static_call()

2020-12-17 Thread Juergen Gross
The time pvops functions are the only ones left which might be
used in 32-bit mode and which return a 64-bit value.

Switch them to use the static_call() mechanism instead of pvops, as
this allows quite some simplification of the pvops implementation.

Due to include hell this requires to split out the time interfaces
into a new header file.

Signed-off-by: Juergen Gross 
---
 arch/x86/Kconfig  |  1 +
 arch/x86/include/asm/mshyperv.h   | 11 
 arch/x86/include/asm/paravirt.h   | 14 --
 arch/x86/include/asm/paravirt_time.h  | 38 +++
 arch/x86/include/asm/paravirt_types.h |  6 -
 arch/x86/kernel/cpu/vmware.c  |  5 ++--
 arch/x86/kernel/kvm.c |  3 ++-
 arch/x86/kernel/kvmclock.c|  3 ++-
 arch/x86/kernel/paravirt.c| 16 ---
 arch/x86/kernel/tsc.c |  3 ++-
 arch/x86/xen/time.c   | 12 -
 drivers/clocksource/hyperv_timer.c|  5 ++--
 drivers/xen/time.c|  3 ++-
 kernel/sched/sched.h  |  1 +
 14 files changed, 71 insertions(+), 50 deletions(-)
 create mode 100644 arch/x86/include/asm/paravirt_time.h

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index a8bd298e45b1..ebabd8bf4064 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -769,6 +769,7 @@ if HYPERVISOR_GUEST
 
 config PARAVIRT
bool "Enable paravirtualization code"
+   depends on HAVE_STATIC_CALL
help
  This changes the kernel so it can modify itself when it is run
  under a hypervisor, potentially improving performance significantly
diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyperv.h
index ffc289992d1b..45942d420626 100644
--- a/arch/x86/include/asm/mshyperv.h
+++ b/arch/x86/include/asm/mshyperv.h
@@ -56,17 +56,6 @@ typedef int (*hyperv_fill_flush_list_func)(
 #define hv_get_raw_timer() rdtsc_ordered()
 #define hv_get_vector() HYPERVISOR_CALLBACK_VECTOR
 
-/*
- * Reference to pv_ops must be inline so objtool
- * detection of noinstr violations can work correctly.
- */
-static __always_inline void hv_setup_sched_clock(void *sched_clock)
-{
-#ifdef CONFIG_PARAVIRT
-   pv_ops.time.sched_clock = sched_clock;
-#endif
-}
-
 void hyperv_vector_handler(struct pt_regs *regs);
 
 static inline void hv_enable_stimer0_percpu_irq(int irq) {}
diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index 4abf110e2243..0785a9686e32 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -17,25 +17,11 @@
 #include 
 #include 
 
-static inline unsigned long long paravirt_sched_clock(void)
-{
-   return PVOP_CALL0(unsigned long long, time.sched_clock);
-}
-
-struct static_key;
-extern struct static_key paravirt_steal_enabled;
-extern struct static_key paravirt_steal_rq_enabled;
-
 __visible void __native_queued_spin_unlock(struct qspinlock *lock);
 bool pv_is_native_spin_unlock(void);
 __visible bool __native_vcpu_is_preempted(long cpu);
 bool pv_is_native_vcpu_is_preempted(void);
 
-static inline u64 paravirt_steal_clock(int cpu)
-{
-   return PVOP_CALL1(u64, time.steal_clock, cpu);
-}
-
 /* The paravirtualized I/O functions */
 static inline void slow_down_io(void)
 {
diff --git a/arch/x86/include/asm/paravirt_time.h 
b/arch/x86/include/asm/paravirt_time.h
new file mode 100644
index ..76cf94b7c899
--- /dev/null
+++ b/arch/x86/include/asm/paravirt_time.h
@@ -0,0 +1,38 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _ASM_X86_PARAVIRT_TIME_H
+#define _ASM_X86_PARAVIRT_TIME_H
+
+/* Time related para-virtualized functions. */
+
+#ifdef CONFIG_PARAVIRT
+
+#include 
+#include 
+#include 
+
+extern struct static_key paravirt_steal_enabled;
+extern struct static_key paravirt_steal_rq_enabled;
+
+u64 dummy_steal_clock(int cpu);
+u64 dummy_sched_clock(void);
+
+DECLARE_STATIC_CALL(pv_steal_clock, dummy_steal_clock);
+DECLARE_STATIC_CALL(pv_sched_clock, dummy_sched_clock);
+
+extern bool paravirt_using_native_sched_clock;
+
+void paravirt_set_sched_clock(u64 (*func)(void));
+
+static inline u64 paravirt_sched_clock(void)
+{
+   return static_call(pv_sched_clock)();
+}
+
+static inline u64 paravirt_steal_clock(int cpu)
+{
+   return static_call(pv_steal_clock)(cpu);
+}
+
+#endif /* CONFIG_PARAVIRT */
+
+#endif /* _ASM_X86_PARAVIRT_TIME_H */
diff --git a/arch/x86/include/asm/paravirt_types.h 
b/arch/x86/include/asm/paravirt_types.h
index de87087d3bde..1fff349e4792 100644
--- a/arch/x86/include/asm/paravirt_types.h
+++ b/arch/x86/include/asm/paravirt_types.h
@@ -95,11 +95,6 @@ struct pv_lazy_ops {
 } __no_randomize_layout;
 #endif
 
-struct pv_time_ops {
-   unsigned long long (*sched_clock)(void);
-   unsigned long long (*steal_clock)(int cpu);
-} __no_randomize_layout;
-
 struct pv_cpu_ops {
/* hooks for various privileged instructions */
void (*io_delay)(void);
@@ -291,7 +286,6 @@ struct pv_lock_ops {
  * 

[PATCH v3 05/15] x86: rework arch_local_irq_restore() to not use popf

2020-12-17 Thread Juergen Gross
"popf" is a rather expensive operation, so don't use it for restoring
irq flags. Instead test whether interrupts are enabled in the flags
parameter and enable interrupts via "sti" in that case.

This results in the restore_fl paravirt op to be no longer needed.

Suggested-by: Andy Lutomirski 
Signed-off-by: Juergen Gross 
---
 arch/x86/include/asm/irqflags.h   | 20 ++-
 arch/x86/include/asm/paravirt.h   |  5 -
 arch/x86/include/asm/paravirt_types.h |  7 ++-
 arch/x86/kernel/irqflags.S| 11 ---
 arch/x86/kernel/paravirt.c|  1 -
 arch/x86/kernel/paravirt_patch.c  |  3 ---
 arch/x86/xen/enlighten_pv.c   |  2 --
 arch/x86/xen/irq.c| 23 --
 arch/x86/xen/xen-asm.S| 28 ---
 arch/x86/xen/xen-ops.h|  1 -
 10 files changed, 8 insertions(+), 93 deletions(-)

diff --git a/arch/x86/include/asm/irqflags.h b/arch/x86/include/asm/irqflags.h
index e585a4705b8d..144d70ea4393 100644
--- a/arch/x86/include/asm/irqflags.h
+++ b/arch/x86/include/asm/irqflags.h
@@ -35,15 +35,6 @@ extern __always_inline unsigned long native_save_fl(void)
return flags;
 }
 
-extern inline void native_restore_fl(unsigned long flags);
-extern inline void native_restore_fl(unsigned long flags)
-{
-   asm volatile("push %0 ; popf"
-: /* no output */
-:"g" (flags)
-:"memory", "cc");
-}
-
 static __always_inline void native_irq_disable(void)
 {
asm volatile("cli": : :"memory");
@@ -79,11 +70,6 @@ static __always_inline unsigned long 
arch_local_save_flags(void)
return native_save_fl();
 }
 
-static __always_inline void arch_local_irq_restore(unsigned long flags)
-{
-   native_restore_fl(flags);
-}
-
 static __always_inline void arch_local_irq_disable(void)
 {
native_irq_disable();
@@ -152,6 +138,12 @@ static __always_inline int arch_irqs_disabled(void)
 
return arch_irqs_disabled_flags(flags);
 }
+
+static __always_inline void arch_local_irq_restore(unsigned long flags)
+{
+   if (!arch_irqs_disabled_flags(flags))
+   arch_local_irq_enable();
+}
 #else
 #ifdef CONFIG_X86_64
 #ifdef CONFIG_XEN_PV
diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index dd43b1100a87..4abf110e2243 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -648,11 +648,6 @@ static inline notrace unsigned long 
arch_local_save_flags(void)
return PVOP_CALLEE0(unsigned long, irq.save_fl);
 }
 
-static inline notrace void arch_local_irq_restore(unsigned long f)
-{
-   PVOP_VCALLEE1(irq.restore_fl, f);
-}
-
 static inline notrace void arch_local_irq_disable(void)
 {
PVOP_VCALLEE0(irq.irq_disable);
diff --git a/arch/x86/include/asm/paravirt_types.h 
b/arch/x86/include/asm/paravirt_types.h
index 0169365f1403..de87087d3bde 100644
--- a/arch/x86/include/asm/paravirt_types.h
+++ b/arch/x86/include/asm/paravirt_types.h
@@ -168,16 +168,13 @@ struct pv_cpu_ops {
 struct pv_irq_ops {
 #ifdef CONFIG_PARAVIRT_XXL
/*
-* Get/set interrupt state.  save_fl and restore_fl are only
-* expected to use X86_EFLAGS_IF; all other bits
-* returned from save_fl are undefined, and may be ignored by
-* restore_fl.
+* Get/set interrupt state.  save_fl is expected to use X86_EFLAGS_IF;
+* all other bits returned from save_fl are undefined.
 *
 * NOTE: These functions callers expect the callee to preserve
 * more registers than the standard C calling convention.
 */
struct paravirt_callee_save save_fl;
-   struct paravirt_callee_save restore_fl;
struct paravirt_callee_save irq_disable;
struct paravirt_callee_save irq_enable;
 
diff --git a/arch/x86/kernel/irqflags.S b/arch/x86/kernel/irqflags.S
index 0db0375235b4..8ef35063964b 100644
--- a/arch/x86/kernel/irqflags.S
+++ b/arch/x86/kernel/irqflags.S
@@ -13,14 +13,3 @@ SYM_FUNC_START(native_save_fl)
ret
 SYM_FUNC_END(native_save_fl)
 EXPORT_SYMBOL(native_save_fl)
-
-/*
- * void native_restore_fl(unsigned long flags)
- * %eax/%rdi: flags
- */
-SYM_FUNC_START(native_restore_fl)
-   push %_ASM_ARG1
-   popf
-   ret
-SYM_FUNC_END(native_restore_fl)
-EXPORT_SYMBOL(native_restore_fl)
diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c
index 18560b71e717..c60222ab8ab9 100644
--- a/arch/x86/kernel/paravirt.c
+++ b/arch/x86/kernel/paravirt.c
@@ -320,7 +320,6 @@ struct paravirt_patch_template pv_ops = {
 
/* Irq ops. */
.irq.save_fl= __PV_IS_CALLEE_SAVE(native_save_fl),
-   .irq.restore_fl = __PV_IS_CALLEE_SAVE(native_restore_fl),
.irq.irq_disable= __PV_IS_CALLEE_SAVE(native_irq_disable),
.irq.irq_enable = __PV_IS_CALLEE_SAVE(native_irq_enable),
.irq.safe_halt  = native

[PATCH v3 14/15] x86/paravirt: switch functions with custom code to ALTERNATIVE

2020-12-17 Thread Juergen Gross
Instead of using paravirt patching for custom code sequences use
ALTERNATIVE for the functions with custom code replacements.

Instead of patching an ud2 instruction for unpopulated vector entries
into the caller site, use a simple function just calling BUG() as a
replacement.

Signed-off-by: Juergen Gross 
---
 arch/x86/include/asm/paravirt.h   | 72 ++
 arch/x86/include/asm/paravirt_types.h |  1 -
 arch/x86/kernel/paravirt.c| 16 ++---
 arch/x86/kernel/paravirt_patch.c  | 88 ---
 4 files changed, 53 insertions(+), 124 deletions(-)

diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index 49a823abc0e1..fc551dcc6458 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -108,7 +108,8 @@ static inline void write_cr0(unsigned long x)
 
 static inline unsigned long read_cr2(void)
 {
-   return PVOP_CALLEE0(unsigned long, mmu.read_cr2);
+   return PVOP_ALT_CALLEE0(unsigned long, mmu.read_cr2,
+   "mov %%cr2, %%rax;", ~X86_FEATURE_XENPV);
 }
 
 static inline void write_cr2(unsigned long x)
@@ -118,12 +119,14 @@ static inline void write_cr2(unsigned long x)
 
 static inline unsigned long __read_cr3(void)
 {
-   return PVOP_CALL0(unsigned long, mmu.read_cr3);
+   return PVOP_ALT_CALL0(unsigned long, mmu.read_cr3,
+ "mov %%cr3, %%rax;", ~X86_FEATURE_XENPV);
 }
 
 static inline void write_cr3(unsigned long x)
 {
-   PVOP_VCALL1(mmu.write_cr3, x);
+   PVOP_ALT_VCALL1(mmu.write_cr3, x,
+   "mov %%rdi, %%cr3", ~X86_FEATURE_XENPV);
 }
 
 static inline void __write_cr4(unsigned long x)
@@ -143,7 +146,7 @@ static inline void halt(void)
 
 static inline void wbinvd(void)
 {
-   PVOP_VCALL0(cpu.wbinvd);
+   PVOP_ALT_VCALL0(cpu.wbinvd, "wbinvd", ~X86_FEATURE_XENPV);
 }
 
 static inline u64 paravirt_read_msr(unsigned msr)
@@ -357,22 +360,28 @@ static inline void paravirt_release_p4d(unsigned long pfn)
 
 static inline pte_t __pte(pteval_t val)
 {
-   return (pte_t) { PVOP_CALLEE1(pteval_t, mmu.make_pte, val) };
+   return (pte_t) { PVOP_ALT_CALLEE1(pteval_t, mmu.make_pte, val,
+ "mov %%rdi, %%rax",
+ ~X86_FEATURE_XENPV) };
 }
 
 static inline pteval_t pte_val(pte_t pte)
 {
-   return PVOP_CALLEE1(pteval_t, mmu.pte_val, pte.pte);
+   return PVOP_ALT_CALLEE1(pteval_t, mmu.pte_val, pte.pte,
+   "mov %%rdi, %%rax", ~X86_FEATURE_XENPV);
 }
 
 static inline pgd_t __pgd(pgdval_t val)
 {
-   return (pgd_t) { PVOP_CALLEE1(pgdval_t, mmu.make_pgd, val) };
+   return (pgd_t) { PVOP_ALT_CALLEE1(pgdval_t, mmu.make_pgd, val,
+ "mov %%rdi, %%rax",
+ ~X86_FEATURE_XENPV) };
 }
 
 static inline pgdval_t pgd_val(pgd_t pgd)
 {
-   return PVOP_CALLEE1(pgdval_t, mmu.pgd_val, pgd.pgd);
+   return PVOP_ALT_CALLEE1(pgdval_t, mmu.pgd_val, pgd.pgd,
+   "mov %%rdi, %%rax", ~X86_FEATURE_XENPV);
 }
 
 #define  __HAVE_ARCH_PTEP_MODIFY_PROT_TRANSACTION
@@ -405,12 +414,15 @@ static inline void set_pmd(pmd_t *pmdp, pmd_t pmd)
 
 static inline pmd_t __pmd(pmdval_t val)
 {
-   return (pmd_t) { PVOP_CALLEE1(pmdval_t, mmu.make_pmd, val) };
+   return (pmd_t) { PVOP_ALT_CALLEE1(pmdval_t, mmu.make_pmd, val,
+ "mov %%rdi, %%rax",
+ ~X86_FEATURE_XENPV) };
 }
 
 static inline pmdval_t pmd_val(pmd_t pmd)
 {
-   return PVOP_CALLEE1(pmdval_t, mmu.pmd_val, pmd.pmd);
+   return PVOP_ALT_CALLEE1(pmdval_t, mmu.pmd_val, pmd.pmd,
+   "mov %%rdi, %%rax", ~X86_FEATURE_XENPV);
 }
 
 static inline void set_pud(pud_t *pudp, pud_t pud)
@@ -422,14 +434,16 @@ static inline pud_t __pud(pudval_t val)
 {
pudval_t ret;
 
-   ret = PVOP_CALLEE1(pudval_t, mmu.make_pud, val);
+   ret = PVOP_ALT_CALLEE1(pudval_t, mmu.make_pud, val,
+  "mov %%rdi, %%rax", ~X86_FEATURE_XENPV);
 
return (pud_t) { ret };
 }
 
 static inline pudval_t pud_val(pud_t pud)
 {
-   return PVOP_CALLEE1(pudval_t, mmu.pud_val, pud.pud);
+   return PVOP_ALT_CALLEE1(pudval_t, mmu.pud_val, pud.pud,
+   "mov %%rdi, %%rax", ~X86_FEATURE_XENPV);
 }
 
 static inline void pud_clear(pud_t *pudp)
@@ -448,14 +462,16 @@ static inline void set_p4d(p4d_t *p4dp, p4d_t p4d)
 
 static inline p4d_t __p4d(p4dval_t val)
 {
-   p4dval_t ret = PVOP_CALLEE1(p4dval_t, mmu.make_p4d, val);
+   p4dval_t ret = PVOP_ALT_CALLEE1(p4dval_t, mmu.make_p4d, val,
+   "mov %%rdi, %%rax", ~X86_FEATURE_XENPV);
 
return (p4d_t) { ret };
 }
 
 static inline p4dval_t p4d_val(p4d_t p4d)
 {
-   return PVOP_CALLEE1(p4dval_t, mmu.p4d_val

[PATCH v3 09/15] x86/paravirt: remove no longer needed 32-bit pvops cruft

2020-12-17 Thread Juergen Gross
PVOP_VCALL4() is only used for Xen PV, while PVOP_CALL4() isn't used
at all. Keep PVOP_CALL4() for 64 bits due to symmetry reasons.

This allows to remove the 32-bit definitions of those macros leading
to a substantial simplification of the paravirt macros, as those were
the only ones needing non-empty "pre" and "post" parameters.

PVOP_CALLEE2() and PVOP_VCALLEE2() are used nowhere, so remove them.

Another no longer needed case is special handling of return types
larger than unsigned long. Replace that with a BUILD_BUG_ON().

DISABLE_INTERRUPTS() is used in 32-bit code only, so it can just be
replaced by cli.

INTERRUPT_RETURN in 32-bit code can be replaced by iret.

ENABLE_INTERRUPTS is used nowhere, so it can be removed.

Signed-off-by: Juergen Gross 
---
 arch/x86/entry/entry_32.S |   4 +-
 arch/x86/include/asm/irqflags.h   |   5 --
 arch/x86/include/asm/paravirt.h   |  35 +---
 arch/x86/include/asm/paravirt_types.h | 112 --
 arch/x86/kernel/asm-offsets.c |   2 -
 5 files changed, 35 insertions(+), 123 deletions(-)

diff --git a/arch/x86/entry/entry_32.S b/arch/x86/entry/entry_32.S
index df8c017e6161..765487e57d6e 100644
--- a/arch/x86/entry/entry_32.S
+++ b/arch/x86/entry/entry_32.S
@@ -430,7 +430,7 @@
 * will soon execute iret and the tracer was already set to
 * the irqstate after the IRET:
 */
-   DISABLE_INTERRUPTS(CLBR_ANY)
+   cli
lss (%esp), %esp/* switch to espfix segment */
 .Lend_\@:
 #endif /* CONFIG_X86_ESPFIX32 */
@@ -1077,7 +1077,7 @@ restore_all_switch_stack:
 * when returning from IPI handler and when returning from
 * scheduler to user-space.
 */
-   INTERRUPT_RETURN
+   iret
 
 .section .fixup, "ax"
 SYM_CODE_START(asm_iret_error)
diff --git a/arch/x86/include/asm/irqflags.h b/arch/x86/include/asm/irqflags.h
index 144d70ea4393..a0efbcd24b86 100644
--- a/arch/x86/include/asm/irqflags.h
+++ b/arch/x86/include/asm/irqflags.h
@@ -109,9 +109,6 @@ static __always_inline unsigned long 
arch_local_irq_save(void)
 }
 #else
 
-#define ENABLE_INTERRUPTS(x)   sti
-#define DISABLE_INTERRUPTS(x)  cli
-
 #ifdef CONFIG_X86_64
 #ifdef CONFIG_DEBUG_ENTRY
 #define SAVE_FLAGS(x)  pushfq; popq %rax
@@ -119,8 +116,6 @@ static __always_inline unsigned long 
arch_local_irq_save(void)
 
 #define INTERRUPT_RETURN   jmp native_iret
 
-#else
-#define INTERRUPT_RETURN   iret
 #endif
 
 #endif /* __ASSEMBLY__ */
diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index 0785a9686e32..1dd30c95505d 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -692,6 +692,7 @@ extern void default_banner(void);
.if ((~(set)) & mask); pop %reg; .endif
 
 #ifdef CONFIG_X86_64
+#ifdef CONFIG_PARAVIRT_XXL
 
 #define PV_SAVE_REGS(set)  \
COND_PUSH(set, CLBR_RAX, rax);  \
@@ -717,46 +718,12 @@ extern void default_banner(void);
 #define PARA_PATCH(off)((off) / 8)
 #define PARA_SITE(ptype, ops)  _PVSITE(ptype, ops, .quad, 8)
 #define PARA_INDIRECT(addr)*addr(%rip)
-#else
-#define PV_SAVE_REGS(set)  \
-   COND_PUSH(set, CLBR_EAX, eax);  \
-   COND_PUSH(set, CLBR_EDI, edi);  \
-   COND_PUSH(set, CLBR_ECX, ecx);  \
-   COND_PUSH(set, CLBR_EDX, edx)
-#define PV_RESTORE_REGS(set)   \
-   COND_POP(set, CLBR_EDX, edx);   \
-   COND_POP(set, CLBR_ECX, ecx);   \
-   COND_POP(set, CLBR_EDI, edi);   \
-   COND_POP(set, CLBR_EAX, eax)
-
-#define PARA_PATCH(off)((off) / 4)
-#define PARA_SITE(ptype, ops)  _PVSITE(ptype, ops, .long, 4)
-#define PARA_INDIRECT(addr)*%cs:addr
-#endif
 
-#ifdef CONFIG_PARAVIRT_XXL
 #define INTERRUPT_RETURN   \
PARA_SITE(PARA_PATCH(PV_CPU_iret),  \
  ANNOTATE_RETPOLINE_SAFE;  \
  jmp PARA_INDIRECT(pv_ops+PV_CPU_iret);)
 
-#define DISABLE_INTERRUPTS(clobbers)   \
-   PARA_SITE(PARA_PATCH(PV_IRQ_irq_disable),   \
- PV_SAVE_REGS(clobbers | CLBR_CALLEE_SAVE);\
- ANNOTATE_RETPOLINE_SAFE;  \
- call PARA_INDIRECT(pv_ops+PV_IRQ_irq_disable);\
- PV_RESTORE_REGS(clobbers | CLBR_CALLEE_SAVE);)
-
-#define ENABLE_INTERRUPTS(clobbers)\
-   PARA_SITE(PARA_PATCH(PV_IRQ_irq_enable),\
- PV_SAVE_REGS(clobbers | CLBR_CALLEE_SAVE);\
- ANNOTATE_RETPOLINE_SAFE;  \
- call PARA_INDIRECT(pv_ops+PV_IRQ_irq_enable); \
- PV_RESTORE_REGS(clobbers 

[PATCH v3 11/15] x86/paravirt: switch iret pvops to ALTERNATIVE

2020-12-17 Thread Juergen Gross
The iret paravirt op is rather special as it is using a jmp instead
of a call instruction. Switch it to ALTERNATIVE.

Signed-off-by: Juergen Gross 
---
V3:
- use ALTERNATIVE_TERNARY
---
 arch/x86/include/asm/paravirt.h   |  6 +++---
 arch/x86/include/asm/paravirt_types.h |  5 +
 arch/x86/kernel/asm-offsets.c |  5 -
 arch/x86/kernel/paravirt.c| 26 ++
 arch/x86/xen/enlighten_pv.c   |  3 +--
 5 files changed, 7 insertions(+), 38 deletions(-)

diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index 1dd30c95505d..49a823abc0e1 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -720,9 +720,9 @@ extern void default_banner(void);
 #define PARA_INDIRECT(addr)*addr(%rip)
 
 #define INTERRUPT_RETURN   \
-   PARA_SITE(PARA_PATCH(PV_CPU_iret),  \
- ANNOTATE_RETPOLINE_SAFE;  \
- jmp PARA_INDIRECT(pv_ops+PV_CPU_iret);)
+   ANNOTATE_RETPOLINE_SAFE;\
+   ALTERNATIVE_TERNARY("jmp *paravirt_iret(%rip);",\
+   X86_FEATURE_XENPV, "jmp xen_iret;", "jmp native_iret;")
 
 #ifdef CONFIG_DEBUG_ENTRY
 #define SAVE_FLAGS(clobbers)\
diff --git a/arch/x86/include/asm/paravirt_types.h 
b/arch/x86/include/asm/paravirt_types.h
index a9efd4dad820..5d6de014d2f6 100644
--- a/arch/x86/include/asm/paravirt_types.h
+++ b/arch/x86/include/asm/paravirt_types.h
@@ -151,10 +151,6 @@ struct pv_cpu_ops {
 
u64 (*read_pmc)(int counter);
 
-   /* Normal iret.  Jump to this with the standard iret stack
-  frame set up. */
-   void (*iret)(void);
-
void (*start_context_switch)(struct task_struct *prev);
void (*end_context_switch)(struct task_struct *next);
 #endif
@@ -294,6 +290,7 @@ struct paravirt_patch_template {
 
 extern struct pv_info pv_info;
 extern struct paravirt_patch_template pv_ops;
+extern void (*paravirt_iret)(void);
 
 #define PARAVIRT_PATCH(x)  \
(offsetof(struct paravirt_patch_template, x) / sizeof(void *))
diff --git a/arch/x86/kernel/asm-offsets.c b/arch/x86/kernel/asm-offsets.c
index 736508004b30..ecd3fd6993d1 100644
--- a/arch/x86/kernel/asm-offsets.c
+++ b/arch/x86/kernel/asm-offsets.c
@@ -61,11 +61,6 @@ static void __used common(void)
OFFSET(IA32_RT_SIGFRAME_sigcontext, rt_sigframe_ia32, uc.uc_mcontext);
 #endif
 
-#ifdef CONFIG_PARAVIRT_XXL
-   BLANK();
-   OFFSET(PV_CPU_iret, paravirt_patch_template, cpu.iret);
-#endif
-
 #ifdef CONFIG_XEN
BLANK();
OFFSET(XEN_vcpu_info_mask, vcpu_info, evtchn_upcall_mask);
diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c
index 9f8aa18aa378..2ab547dd66c3 100644
--- a/arch/x86/kernel/paravirt.c
+++ b/arch/x86/kernel/paravirt.c
@@ -86,25 +86,6 @@ u64 notrace _paravirt_ident_64(u64 x)
 {
return x;
 }
-
-static unsigned paravirt_patch_jmp(void *insn_buff, const void *target,
-  unsigned long addr, unsigned len)
-{
-   struct branch *b = insn_buff;
-   unsigned long delta = (unsigned long)target - (addr+5);
-
-   if (len < 5) {
-#ifdef CONFIG_RETPOLINE
-   WARN_ONCE(1, "Failing to patch indirect JMP in %ps\n", (void 
*)addr);
-#endif
-   return len; /* call too long for patch site */
-   }
-
-   b->opcode = 0xe9;   /* jmp */
-   b->delta = delta;
-
-   return 5;
-}
 #endif
 
 DEFINE_STATIC_KEY_TRUE(virt_spin_lock_key);
@@ -136,9 +117,6 @@ unsigned paravirt_patch_default(u8 type, void *insn_buff,
else if (opfunc == _paravirt_ident_64)
ret = paravirt_patch_ident_64(insn_buff, len);
 
-   else if (type == PARAVIRT_PATCH(cpu.iret))
-   /* If operation requires a jmp, then jmp */
-   ret = paravirt_patch_jmp(insn_buff, opfunc, addr, len);
 #endif
else
/* Otherwise call the function. */
@@ -316,8 +294,6 @@ struct paravirt_patch_template pv_ops = {
 
.cpu.load_sp0   = native_load_sp0,
 
-   .cpu.iret   = native_iret,
-
 #ifdef CONFIG_X86_IOPL_IOPERM
.cpu.invalidate_io_bitmap   = native_tss_invalidate_io_bitmap,
.cpu.update_io_bitmap   = native_tss_update_io_bitmap,
@@ -422,6 +398,8 @@ struct paravirt_patch_template pv_ops = {
 NOKPROBE_SYMBOL(native_get_debugreg);
 NOKPROBE_SYMBOL(native_set_debugreg);
 NOKPROBE_SYMBOL(native_load_idt);
+
+void (*paravirt_iret)(void) = native_iret;
 #endif
 
 EXPORT_SYMBOL(pv_ops);
diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
index 32b295cc2716..4716383c64a9 100644
--- a/arch/x86/xen/enlighten_pv.c
+++ b/arch/x86/xen/enlighten_pv.c
@@ -1057,8 +1057,6 @@ static const struct pv_cpu_ops xen_cpu_ops __initconst =

Re: [PATCH v1 ] ALSA: core: memalloc: add page alignment for iram

2020-12-17 Thread Takashi Iwai
On Thu, 17 Dec 2020 17:15:47 +0100,
Robin Gong wrote:
> 
> Since mmap for userspace is based on page alignment, add page alignment
> for iram alloc from pool, otherwise, some good data located in the same
> page of dmab->area maybe touched wrongly by userspace like pulseaudio.
> 
> Signed-off-by: Robin Gong 

Thanks, applied now with Cc-to-stable.


Takashi


Re: [RFC PATCH v2 4/6] mfd: add BD71827 header

2020-12-17 Thread Vaittinen, Matti

On Wed, 2020-12-16 at 08:53 +, Lee Jones wrote:
> On Fri, 04 Dec 2020, Matti Vaittinen wrote:
> 
> > Add BD71827 driver header. For a record - Header is originally
> > based on work authored by Cong Pham although not much of original
> > work is left now.
> > 
> > Signed-off-by: Matti Vaittinen 
> > ---
> > This patch was not in v1. This brings in some charger registers
> > for the BD71827 charger which is in following patches.
> > 
> >  include/linux/mfd/rohm-bd71827.h | 295
> > +++
> >  1 file changed, 295 insertions(+)
> >  create mode 100644 include/linux/mfd/rohm-bd71827.h
> > 
> > diff --git a/include/linux/mfd/rohm-bd71827.h
> > b/include/linux/mfd/rohm-bd71827.h
> > new file mode 100644
> > index ..0f5a343b10ae
> > --- /dev/null
> > +++ b/include/linux/mfd/rohm-bd71827.h
> > @@ -0,0 +1,295 @@
> > +/* SPDX-License-Identifier: GPL-2.0-or-later */
> > +/*
> > + * Copyright 2016
> 
> Out of date.

...

Thanks for the review Lee! It was unexpected as I didn't add you to CC.
Reason for skipping you is that this was very initial RFC patch set -
intended to collect opinions of adding some fuel-gauge logic in power-
supply. I will for sure clean up the findings (and possibly some other
issues) when I proceed with these charger drivers - and at that point I
will ask for a re-review & add you in CC. But I just wanted to point
out that as the fate/format of this driver depends on how the RFC is
seen by Sebastian & others so getting back to this may take some
time...

BTW - you have nice mail-filters as you caught these pathces, you pick
every mail with MFD in subject(?) 


Best Regards
Matti

--
Matti Vaittinen, Linux device drivers
ROHM Semiconductors, Finland
SWDC
Kiviharjunlenkki 1E
90220 OULU
FINLAND

~~~ "I don't think so," said Rene Descartes. Just then he vanished ~~~

Simon says - in Latin please.
"non cogito me" dixit Rene Descarte, deinde evanescavit

(Thanks for the translation Simon)



Re: linux-next: manual merge of the akpm-current tree with the risc-v tree

2020-12-17 Thread Andy Shevchenko
On Thu, Dec 17, 2020 at 3:28 AM Stephen Rothwell  wrote:
>
> Hi all,
>
> On Mon, 14 Dec 2020 20:21:07 +1100 Stephen Rothwell  
> wrote:
> >
> > Today's linux-next merge of the akpm-current tree got a conflict in:
> >
> >   lib/Makefile
> >
> > between commit:
> >
> >   527701eda5f1 ("lib: Add a generic version of devmem_is_allowed()")
> >
> > from the risc-v tree and commits:
> >
> >   8250e121c672 ("lib/list_kunit: follow new file name convention for KUnit 
> > tests")
> >   17bf776cf09a ("lib/linear_ranges_kunit: follow new file name convention 
> > for KUnit tests")
> >   23fa4e39ee62 ("lib/bits_kunit: follow new file name convention for KUnit 
> > tests")
> >   1987f84faec6 ("lib/cmdline_kunit: add a new test suite for cmdline API")

AFAIU Linus rejected the above patches. I hope kselftest/kunit tree
can pick them up.

> > diff --cc lib/Makefile
> > index bcedd691ef63,dc623561ef9d..
> > --- a/lib/Makefile
> > +++ b/lib/Makefile
> > @@@ -350,8 -350,7 +350,9 @@@ obj-$(CONFIG_PLDMFW) += pldmfw
> >
> >   # KUnit tests
> >   obj-$(CONFIG_BITFIELD_KUNIT) += bitfield_kunit.o
> > - obj-$(CONFIG_LIST_KUNIT_TEST) += list-test.o
> > - obj-$(CONFIG_LINEAR_RANGES_TEST) += test_linear_ranges.o
> > - obj-$(CONFIG_BITS_TEST) += test_bits.o
> > + obj-$(CONFIG_BITS_TEST) += bits_kunit.o
> > + obj-$(CONFIG_CMDLINE_KUNIT_TEST) += cmdline_kunit.o
> > + obj-$(CONFIG_LINEAR_RANGES_TEST) += linear_ranges_kunit.o
> > + obj-$(CONFIG_LIST_KUNIT_TEST) += list_kunit.o
> >  +
> >  +obj-$(CONFIG_GENERIC_LIB_DEVMEM_IS_ALLOWED) += devmem_is_allowed.o
>
> This is now a conflict between the risc-v tree and Linus' tree.

Yeah, and it's slightly different. Perhaps RISC-V tree can handle this
by moving Makefile entry somewhere else in the file.

-- 
With Best Regards,
Andy Shevchenko


RE: [EXT] Re: [PATCH net 1/2] net: mvpp2: Fix GoP port 3 Networking Complex Control configurations

2020-12-17 Thread Stefan Chulski


> -Original Message-
> From: Jakub Kicinski 
> Sent: Thursday, December 17, 2020 2:42 AM
> To: Stefan Chulski 
> Cc: net...@vger.kernel.org; thomas.petazz...@bootlin.com;
> da...@davemloft.net; Nadav Haklai ; Yan Markman
> ; linux-kernel@vger.kernel.org;
> li...@armlinux.org.uk; m...@semihalf.com; and...@lunn.ch;
> rmk+ker...@armlinux.org.uk
> Subject: [EXT] Re: [PATCH net 1/2] net: mvpp2: Fix GoP port 3 Networking
> Complex Control configurations
> 
> External Email
> 
> --
> On Tue, 15 Dec 2020 15:32:12 +0200 stef...@marvell.com wrote:
> > From: Stefan Chulski 
> >
> > During GoP port 2 Networking Complex Control mode of operation
> > configurations, also GoP port 3 mode of operation was wrongly set mode.
> > Patch removes these configurations.
> > GENCONF_CTRL0_PORTX naming also fixed.
> 
> Can we get a Fixes tag?

Reposting with Fixes tag.

Stefan.


[PATCH net v2 1/2] net: mvpp2: Fix GoP port 3 Networking Complex Control configurations

2020-12-17 Thread stefanc
From: Stefan Chulski 

During GoP port 2 Networking Complex Control mode of operation configurations,
also GoP port 3 mode of operation was wrongly set.
Patch removes these configurations.
GENCONF_CTRL0_PORTX naming also fixed.

Fixes: f84bf386f395 ("net: mvpp2: initialize the GoP")
Signed-off-by: Stefan Chulski 
---
 drivers/net/ethernet/marvell/mvpp2/mvpp2.h  | 6 +++---
 drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 8 
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h 
b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
index 6bd7e40..39c4e5c 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
@@ -651,9 +651,9 @@
 #define GENCONF_PORT_CTRL1_EN(p)   BIT(p)
 #define GENCONF_PORT_CTRL1_RESET(p)(BIT(p) << 28)
 #define GENCONF_CTRL0  0x1120
-#define GENCONF_CTRL0_PORT0_RGMII  BIT(0)
-#define GENCONF_CTRL0_PORT1_RGMII_MII  BIT(1)
-#define GENCONF_CTRL0_PORT1_RGMII  BIT(2)
+#define GENCONF_CTRL0_PORT2_RGMII  BIT(0)
+#define GENCONF_CTRL0_PORT3_RGMII_MII  BIT(1)
+#define GENCONF_CTRL0_PORT3_RGMII  BIT(2)
 
 /* Various constants */
 
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c 
b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
index d64dc12..d2b0506 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
@@ -1231,9 +1231,9 @@ static void mvpp22_gop_init_rgmii(struct mvpp2_port *port)
 
regmap_read(priv->sysctrl_base, GENCONF_CTRL0, &val);
if (port->gop_id == 2)
-   val |= GENCONF_CTRL0_PORT0_RGMII | GENCONF_CTRL0_PORT1_RGMII;
+   val |= GENCONF_CTRL0_PORT2_RGMII;
else if (port->gop_id == 3)
-   val |= GENCONF_CTRL0_PORT1_RGMII_MII;
+   val |= GENCONF_CTRL0_PORT3_RGMII_MII;
regmap_write(priv->sysctrl_base, GENCONF_CTRL0, val);
 }
 
@@ -1250,9 +1250,9 @@ static void mvpp22_gop_init_sgmii(struct mvpp2_port *port)
if (port->gop_id > 1) {
regmap_read(priv->sysctrl_base, GENCONF_CTRL0, &val);
if (port->gop_id == 2)
-   val &= ~GENCONF_CTRL0_PORT0_RGMII;
+   val &= ~GENCONF_CTRL0_PORT2_RGMII;
else if (port->gop_id == 3)
-   val &= ~GENCONF_CTRL0_PORT1_RGMII_MII;
+   val &= ~GENCONF_CTRL0_PORT3_RGMII_MII;
regmap_write(priv->sysctrl_base, GENCONF_CTRL0, val);
}
 }
-- 
1.9.1



[PATCH net v2 2/2] net: mvpp2: disable force link UP during port init procedure

2020-12-17 Thread stefanc
From: Stefan Chulski 

Force link UP can be enabled by bootloader during tftpboot
and breaks NFS support.
Force link UP disabled during port init procedure.

Signed-off-by: Stefan Chulski 
---
 drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c 
b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
index d2b0506..0ad3177 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
@@ -5479,7 +5479,7 @@ static int mvpp2_port_init(struct mvpp2_port *port)
struct mvpp2 *priv = port->priv;
struct mvpp2_txq_pcpu *txq_pcpu;
unsigned int thread;
-   int queue, err;
+   int queue, err, val;
 
/* Checks for hardware constraints */
if (port->first_rxq + port->nrxqs >
@@ -5493,6 +5493,18 @@ static int mvpp2_port_init(struct mvpp2_port *port)
mvpp2_egress_disable(port);
mvpp2_port_disable(port);
 
+   if (mvpp2_is_xlg(port->phy_interface)) {
+   val = readl(port->base + MVPP22_XLG_CTRL0_REG);
+   val &= ~MVPP22_XLG_CTRL0_FORCE_LINK_PASS;
+   val |= MVPP22_XLG_CTRL0_FORCE_LINK_DOWN;
+   writel(val, port->base + MVPP22_XLG_CTRL0_REG);
+   } else {
+   val = readl(port->base + MVPP2_GMAC_AUTONEG_CONFIG);
+   val &= ~MVPP2_GMAC_FORCE_LINK_PASS;
+   val |= MVPP2_GMAC_FORCE_LINK_DOWN;
+   writel(val, port->base + MVPP2_GMAC_AUTONEG_CONFIG);
+   }
+
port->tx_time_coal = MVPP2_TXDONE_COAL_USEC;
 
port->txqs = devm_kcalloc(dev, port->ntxqs, sizeof(*port->txqs),
-- 
1.9.1



Re: [PATCH 01/01] Add VID to support native DSD reproduction on FiiO devices.

2020-12-17 Thread Takashi Iwai
On Wed, 16 Dec 2020 19:29:09 +0100,
Amadej Kastelic wrote:
> 
> On Wed, Dec 16, 2020 at 04:38:07PM +0100, Takashi Iwai wrote:
> > On Tue, 15 Dec 2020 19:09:05 +0100,
> > Amadej Kastelic wrote:
> > > 
> > > Message-Id: 
> > > 
> > > Add VID to support native DSD reproduction on FiiO devices.
> > > 
> > > Tested-by: Amadej Kastelic 
> > > Signed-off-by: Emilio Moretti 
> > 
> > Could you give your own sign-off, too?  Each person who submits the
> > patch needs the sign-off.  This is mandatory for merging to the
> > upstream.
> > 
> > 
> > thanks,
> > 
> > Takashi
> 
> Signed-off-by: Amadej Kastelic 

Thanks, the patch was merged now.


Takashi


Re: [PATCH v1 ] ALSA: core: memalloc: add page alignment for iram

2020-12-17 Thread Lars-Peter Clausen

On 12/17/20 5:15 PM, Robin Gong wrote:

Since mmap for userspace is based on page alignment, add page alignment
for iram alloc from pool, otherwise, some good data located in the same
page of dmab->area maybe touched wrongly by userspace like pulseaudio.

I wonder, do we also have to align size to be a multiple of PAGE_SIZE to 
avoid leaking unrelated data?




Re: [PATCH v2] clk: Add hardware-enable column to clk summary

2020-12-17 Thread Stephen Boyd
Quoting Dmitry Osipenko (2020-11-15 12:34:32)
> Add "hardware enable" column to the clk summary in order to show actual
> hardware enable-state of all clocks. The possible states are "Y/N/?",
> where question mark means that state is unknown, i.e. clock isn't a
> mux and clk-driver doesn't support is_enabled() callback for this clock.
> 
> In conjunction with clk_ignore_unused, this tells us what unused clocks
> are left enabled after bootloader. This is also useful a useful aid for
> debugging interactions with firmware which changes clock states without
> notifying kernel.
> 
> Signed-off-by: Dmitry Osipenko 
> ---

Applied to clk-next


[PATCH v2 0/8] Support Runtime PM and host mode by Tegra ChipIdea USB driver

2020-12-17 Thread Dmitry Osipenko
This series implements Runtime PM support for the Tegra ChipIdea USB driver.
It also squashes the older ehci-tegra driver into the ChipIdea driver, hence
the RPM is supported by both UDC and host controllers, secondly this opens
opportunity for implementing OTG support in the future.

Patchset was tested on various Tegra20, Tegra30 and Tegra124 devices.
Thanks to Peter Geis, Matt Merhar, Nicolas Chauvet and Ion Agorria for
helping with the extensive and productive testing!

Changelog:

v2: - Improved comments in the code as it was suggested by Peter Chen and
  Sergei Shtylyov for v1.

- Replaced mdelay() with fsleep() and made ci->hdc to reset to NULL in
  a error code path, like it was suggested by Peter Chen.

- Redirected deprecated USB_EHCI_TEGRA Kconfig entry to USB_CHIPIDEA_TEGRA
  as was suggested by Alan Stern.

- Improved commit message and added ACK from Thierry Reding to the patch
  that removes MODULE_ALIAS.

- Fixed UDC PHY waking up on ASUS TF201 tablet device by utilizing
  additional VBUS sensor. This was reported and tested by Ion Agorria.

- Added t-b from Ion Agorria.

Dmitry Osipenko (7):
  usb: phy: tegra: Add delay after power up
  usb: phy: tegra: Support waking up from a low power mode
  usb: chipidea: tegra: Remove MODULE_ALIAS
  usb: chipidea: tegra: Rename UDC to USB
  usb: chipidea: tegra: Support runtime PM
  usb: host: ehci-tegra: Remove the driver
  ARM: tegra_defconfig: Enable USB_CHIPIDEA and remove USB_EHCI_TEGRA

Peter Geis (1):
  usb: chipidea: tegra: Support host mode

 arch/arm/configs/tegra_defconfig |   3 +-
 drivers/usb/chipidea/Kconfig |   3 +-
 drivers/usb/chipidea/ci_hdrc_tegra.c | 327 +--
 drivers/usb/chipidea/core.c  |  10 +-
 drivers/usb/chipidea/host.c  | 104 -
 drivers/usb/host/Kconfig |   8 +-
 drivers/usb/host/Makefile|   1 -
 drivers/usb/host/ehci-tegra.c| 604 ---
 drivers/usb/phy/phy-tegra-usb.c  |  97 -
 include/linux/usb/chipidea.h |   6 +
 include/linux/usb/tegra_usb_phy.h|   2 +
 11 files changed, 503 insertions(+), 662 deletions(-)
 delete mode 100644 drivers/usb/host/ehci-tegra.c

-- 
2.29.2



[PATCH v2 3/8] usb: chipidea: tegra: Remove MODULE_ALIAS

2020-12-17 Thread Dmitry Osipenko
The OF core adds an alias based on the OF device ID table, which is enough
to have the driver autoloaded. The legacy MODULE_ALIAS macro was relevant
to a pre-OF board files which manually created platform devices, this is
irrelevant to the modern ARM kernels since devices are created by the OF
core. Remove the unnecessary macro in order to keep the driver's code
cleaner.

Tested-by: Matt Merhar 
Tested-by: Nicolas Chauvet 
Tested-by: Peter Geis 
Tested-by: Ion Agorria 
Acked-by: Thierry Reding 
Signed-off-by: Dmitry Osipenko 
---
 drivers/usb/chipidea/ci_hdrc_tegra.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/usb/chipidea/ci_hdrc_tegra.c 
b/drivers/usb/chipidea/ci_hdrc_tegra.c
index 7455df0ede49..10eaaba2a3f0 100644
--- a/drivers/usb/chipidea/ci_hdrc_tegra.c
+++ b/drivers/usb/chipidea/ci_hdrc_tegra.c
@@ -128,5 +128,4 @@ module_platform_driver(tegra_udc_driver);
 
 MODULE_DESCRIPTION("NVIDIA Tegra USB device mode driver");
 MODULE_AUTHOR("Thierry Reding ");
-MODULE_ALIAS("platform:tegra-udc");
 MODULE_LICENSE("GPL v2");
-- 
2.29.2



[PATCH v2 8/8] ARM: tegra_defconfig: Enable USB_CHIPIDEA and remove USB_EHCI_TEGRA

2020-12-17 Thread Dmitry Osipenko
The ehci-tegra driver was superseded by the generic ChipIdea USB driver,
update the tegra's defconfig accordingly.

Signed-off-by: Dmitry Osipenko 
---
 arch/arm/configs/tegra_defconfig | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/configs/tegra_defconfig b/arch/arm/configs/tegra_defconfig
index 74739a52a8ad..ae0709265493 100644
--- a/arch/arm/configs/tegra_defconfig
+++ b/arch/arm/configs/tegra_defconfig
@@ -237,12 +237,13 @@ CONFIG_USB=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_TEGRA=y
 CONFIG_USB_EHCI_HCD=y
-CONFIG_USB_EHCI_TEGRA=y
 CONFIG_USB_ACM=y
 CONFIG_USB_WDM=y
 CONFIG_USB_STORAGE=y
 CONFIG_USB_CHIPIDEA=y
 CONFIG_USB_CHIPIDEA_UDC=y
+CONFIG_USB_CHIPIDEA_HOST=y
+CONFIG_USB_CHIPIDEA_TEGRA=y
 CONFIG_USB_GADGET=y
 CONFIG_MMC=y
 CONFIG_MMC_BLOCK_MINORS=16
-- 
2.29.2



[PATCH v2 1/8] usb: phy: tegra: Add delay after power up

2020-12-17 Thread Dmitry Osipenko
The PHY hardware needs the delay of 2ms after power up, otherwise initial
interrupt may be lost if USB controller is accessed before PHY is settled
down. Previously this issue was masked by implicit delays, but now it pops
up after squashing the older ehci-tegra driver into the ChipIdea driver.

Tested-by: Matt Merhar 
Tested-by: Nicolas Chauvet 
Tested-by: Peter Geis 
Tested-by: Ion Agorria 
Signed-off-by: Dmitry Osipenko 
---
 drivers/usb/phy/phy-tegra-usb.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/usb/phy/phy-tegra-usb.c b/drivers/usb/phy/phy-tegra-usb.c
index 03a333797382..1296524e1bee 100644
--- a/drivers/usb/phy/phy-tegra-usb.c
+++ b/drivers/usb/phy/phy-tegra-usb.c
@@ -784,6 +784,9 @@ static int tegra_usb_phy_power_on(struct tegra_usb_phy *phy)
 
phy->powered_on = true;
 
+   /* Let PHY settle down */
+   usleep_range(2000, 2500);
+
return 0;
 }
 
-- 
2.29.2



Re: [net-next PATCH v2 04/14] net: phy: Introduce fwnode_get_phy_id()

2020-12-17 Thread Andy Shevchenko
On Thu, Dec 17, 2020 at 10:28 AM Calvin Johnson
 wrote:
> On Tue, Dec 15, 2020 at 07:28:10PM +0200, Andy Shevchenko wrote:
> > On Tue, Dec 15, 2020 at 6:44 PM Calvin Johnson
> >  wrote:

...

> > > +   if (sscanf(cp, "ethernet-phy-id%4x.%4x", &upper, &lower) == 2) {

> >*phy_id = ((upper & 0x) << 16) | (lower & 0x);

> > And perhaps GENMASK() ?
>
> Sure. Will rewrite accordingly.

Reading this again I'm now not sure these masks are needed at all.

-- 
With Best Regards,
Andy Shevchenko


[PATCH v2 2/8] usb: phy: tegra: Support waking up from a low power mode

2020-12-17 Thread Dmitry Osipenko
Support programming of waking up from a low power mode by implementing the
generic set_wakeup() callback of the USB PHY API.

Tested-by: Matt Merhar 
Tested-by: Nicolas Chauvet 
Tested-by: Peter Geis 
Tested-by: Ion Agorria 
Signed-off-by: Dmitry Osipenko 
---
 drivers/usb/phy/phy-tegra-usb.c   | 94 +--
 include/linux/usb/tegra_usb_phy.h |  2 +
 2 files changed, 90 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/phy/phy-tegra-usb.c b/drivers/usb/phy/phy-tegra-usb.c
index 1296524e1bee..46a1f61877ad 100644
--- a/drivers/usb/phy/phy-tegra-usb.c
+++ b/drivers/usb/phy/phy-tegra-usb.c
@@ -45,6 +45,7 @@
 #define TEGRA_PORTSC1_RWC_BITS (PORT_CSC | PORT_PEC | PORT_OCC)
 
 #define USB_SUSP_CTRL  0x400
+#define   USB_WAKE_ON_RESUME_ENBIT(2)
 #define   USB_WAKE_ON_CNNT_EN_DEV  BIT(3)
 #define   USB_WAKE_ON_DISCON_EN_DEVBIT(4)
 #define   USB_SUSP_CLR BIT(5)
@@ -56,6 +57,15 @@
 #define   USB_SUSP_SET BIT(14)
 #define   USB_WAKEUP_DEBOUNCE_COUNT(x) (((x) & 0x7) << 16)
 
+#define USB_PHY_VBUS_SENSORS   0x404
+#define   B_SESS_VLD_WAKEUP_EN BIT(6)
+#define   B_VBUS_VLD_WAKEUP_EN BIT(14)
+#define   A_SESS_VLD_WAKEUP_EN BIT(22)
+#define   A_VBUS_VLD_WAKEUP_EN BIT(30)
+
+#define USB_PHY_VBUS_WAKEUP_ID 0x408
+#define   VBUS_WAKEUP_WAKEUP_ENBIT(30)
+
 #define USB1_LEGACY_CTRL   0x410
 #define   USB1_NO_LEGACY_MODE  BIT(0)
 #define   USB1_VBUS_SENSE_CTL_MASK (3 << 1)
@@ -334,6 +344,11 @@ static int utmip_pad_power_on(struct tegra_usb_phy *phy)
writel_relaxed(val, base + UTMIP_BIAS_CFG0);
}
 
+   if (phy->pad_wakeup) {
+   phy->pad_wakeup = false;
+   utmip_pad_count--;
+   }
+
spin_unlock(&utmip_pad_lock);
 
clk_disable_unprepare(phy->pad_clk);
@@ -359,6 +374,17 @@ static int utmip_pad_power_off(struct tegra_usb_phy *phy)
goto ulock;
}
 
+   /*
+* In accordance to TRM, OTG and Bias pad circuits could be turned off
+* to save power if wake is enabled, but the VBUS-change detection
+* method is board-specific and these circuits may need to be enabled
+* to generate wakeup event, hence we will just keep them both enabled.
+*/
+   if (phy->wakeup_enabled) {
+   phy->pad_wakeup = true;
+   utmip_pad_count++;
+   }
+
if (--utmip_pad_count == 0) {
val = readl_relaxed(base + UTMIP_BIAS_CFG0);
val |= UTMIP_OTGPD | UTMIP_BIASPD;
@@ -503,11 +529,24 @@ static int utmi_phy_power_on(struct tegra_usb_phy *phy)
writel_relaxed(val, base + UTMIP_PLL_CFG1);
}
 
+   val = readl_relaxed(base + USB_SUSP_CTRL);
+   val &= ~USB_WAKE_ON_RESUME_EN;
+   writel_relaxed(val, base + USB_SUSP_CTRL);
+
if (phy->mode == USB_DR_MODE_PERIPHERAL) {
val = readl_relaxed(base + USB_SUSP_CTRL);
val &= ~(USB_WAKE_ON_CNNT_EN_DEV | USB_WAKE_ON_DISCON_EN_DEV);
writel_relaxed(val, base + USB_SUSP_CTRL);
 
+   val = readl_relaxed(base + USB_PHY_VBUS_WAKEUP_ID);
+   val &= ~VBUS_WAKEUP_WAKEUP_EN;
+   writel_relaxed(val, base + USB_PHY_VBUS_WAKEUP_ID);
+
+   val = readl_relaxed(base + USB_PHY_VBUS_SENSORS);
+   val &= ~(A_VBUS_VLD_WAKEUP_EN | A_SESS_VLD_WAKEUP_EN);
+   val &= ~(B_VBUS_VLD_WAKEUP_EN | B_SESS_VLD_WAKEUP_EN);
+   writel_relaxed(val, base + USB_PHY_VBUS_SENSORS);
+
val = readl_relaxed(base + UTMIP_BAT_CHRG_CFG0);
val &= ~UTMIP_PD_CHRG;
writel_relaxed(val, base + UTMIP_BAT_CHRG_CFG0);
@@ -605,31 +644,55 @@ static int utmi_phy_power_off(struct tegra_usb_phy *phy)
 
utmi_phy_clk_disable(phy);
 
-   if (phy->mode == USB_DR_MODE_PERIPHERAL) {
-   val = readl_relaxed(base + USB_SUSP_CTRL);
-   val &= ~USB_WAKEUP_DEBOUNCE_COUNT(~0);
-   val |= USB_WAKE_ON_CNNT_EN_DEV | USB_WAKEUP_DEBOUNCE_COUNT(5);
-   writel_relaxed(val, base + USB_SUSP_CTRL);
-   }
+   /* PHY won't resume if reset is asserted */
+   if (phy->wakeup_enabled)
+   goto chrg_cfg0;
 
val = readl_relaxed(base + USB_SUSP_CTRL);
val |= UTMIP_RESET;
writel_relaxed(val, base + USB_SUSP_CTRL);
 
+chrg_cfg0:
val = readl_relaxed(base + UTMIP_BAT_CHRG_CFG0);
val |= UTMIP_PD_CHRG;
writel_relaxed(val, base + UTMIP_BAT_CHRG_CFG0);
 
+   if (phy->wakeup_enabled)
+   goto xcvr_cfg1;
+
val = readl_relaxed(base + UTMIP_XCVR_CFG0);
val |= UTMIP_FORCE_PD_POWERDOWN | UTMIP_FORCE_PD2_POWERDOWN |
   U

[PATCH v2 4/8] usb: chipidea: tegra: Rename UDC to USB

2020-12-17 Thread Dmitry Osipenko
Rename all occurrences in the code from "udc" to "usb" and change the
Kconfig entry in order to show that this driver supports USB modes other
than device-only mode. The follow up patch will add host-mode support and
it will be cleaner to perform the renaming separately, i.e. in this patch.

Tested-by: Matt Merhar 
Tested-by: Nicolas Chauvet 
Tested-by: Peter Geis 
Tested-by: Ion Agorria 
Signed-off-by: Dmitry Osipenko 
---
 drivers/usb/chipidea/Kconfig |  2 +-
 drivers/usb/chipidea/ci_hdrc_tegra.c | 78 ++--
 2 files changed, 40 insertions(+), 40 deletions(-)

diff --git a/drivers/usb/chipidea/Kconfig b/drivers/usb/chipidea/Kconfig
index 8bafcfc6080d..8685ead6ccc7 100644
--- a/drivers/usb/chipidea/Kconfig
+++ b/drivers/usb/chipidea/Kconfig
@@ -53,7 +53,7 @@ config USB_CHIPIDEA_GENERIC
default USB_CHIPIDEA
 
 config USB_CHIPIDEA_TEGRA
-   tristate "Enable Tegra UDC glue driver" if EMBEDDED
+   tristate "Enable Tegra USB glue driver" if EMBEDDED
depends on OF
depends on USB_CHIPIDEA_UDC
default USB_CHIPIDEA
diff --git a/drivers/usb/chipidea/ci_hdrc_tegra.c 
b/drivers/usb/chipidea/ci_hdrc_tegra.c
index 10eaaba2a3f0..d8efa80aa1c2 100644
--- a/drivers/usb/chipidea/ci_hdrc_tegra.c
+++ b/drivers/usb/chipidea/ci_hdrc_tegra.c
@@ -12,7 +12,7 @@
 
 #include "ci.h"
 
-struct tegra_udc {
+struct tegra_usb {
struct ci_hdrc_platform_data data;
struct platform_device *dev;
 
@@ -20,15 +20,15 @@ struct tegra_udc {
struct clk *clk;
 };
 
-struct tegra_udc_soc_info {
+struct tegra_usb_soc_info {
unsigned long flags;
 };
 
-static const struct tegra_udc_soc_info tegra_udc_soc_info = {
+static const struct tegra_usb_soc_info tegra_udc_soc_info = {
.flags = CI_HDRC_REQUIRES_ALIGNED_DMA,
 };
 
-static const struct of_device_id tegra_udc_of_match[] = {
+static const struct of_device_id tegra_usb_of_match[] = {
{
.compatible = "nvidia,tegra20-udc",
.data = &tegra_udc_soc_info,
@@ -45,16 +45,16 @@ static const struct of_device_id tegra_udc_of_match[] = {
/* sentinel */
}
 };
-MODULE_DEVICE_TABLE(of, tegra_udc_of_match);
+MODULE_DEVICE_TABLE(of, tegra_usb_of_match);
 
-static int tegra_udc_probe(struct platform_device *pdev)
+static int tegra_usb_probe(struct platform_device *pdev)
 {
-   const struct tegra_udc_soc_info *soc;
-   struct tegra_udc *udc;
+   const struct tegra_usb_soc_info *soc;
+   struct tegra_usb *usb;
int err;
 
-   udc = devm_kzalloc(&pdev->dev, sizeof(*udc), GFP_KERNEL);
-   if (!udc)
+   usb = devm_kzalloc(&pdev->dev, sizeof(*usb), GFP_KERNEL);
+   if (!usb)
return -ENOMEM;
 
soc = of_device_get_match_data(&pdev->dev);
@@ -63,69 +63,69 @@ static int tegra_udc_probe(struct platform_device *pdev)
return -EINVAL;
}
 
-   udc->phy = devm_usb_get_phy_by_phandle(&pdev->dev, "nvidia,phy", 0);
-   if (IS_ERR(udc->phy)) {
-   err = PTR_ERR(udc->phy);
+   usb->phy = devm_usb_get_phy_by_phandle(&pdev->dev, "nvidia,phy", 0);
+   if (IS_ERR(usb->phy)) {
+   err = PTR_ERR(usb->phy);
dev_err(&pdev->dev, "failed to get PHY: %d\n", err);
return err;
}
 
-   udc->clk = devm_clk_get(&pdev->dev, NULL);
-   if (IS_ERR(udc->clk)) {
-   err = PTR_ERR(udc->clk);
+   usb->clk = devm_clk_get(&pdev->dev, NULL);
+   if (IS_ERR(usb->clk)) {
+   err = PTR_ERR(usb->clk);
dev_err(&pdev->dev, "failed to get clock: %d\n", err);
return err;
}
 
-   err = clk_prepare_enable(udc->clk);
+   err = clk_prepare_enable(usb->clk);
if (err < 0) {
dev_err(&pdev->dev, "failed to enable clock: %d\n", err);
return err;
}
 
/* setup and register ChipIdea HDRC device */
-   udc->data.name = "tegra-udc";
-   udc->data.flags = soc->flags;
-   udc->data.usb_phy = udc->phy;
-   udc->data.capoffset = DEF_CAPOFFSET;
-
-   udc->dev = ci_hdrc_add_device(&pdev->dev, pdev->resource,
- pdev->num_resources, &udc->data);
-   if (IS_ERR(udc->dev)) {
-   err = PTR_ERR(udc->dev);
+   usb->data.name = "tegra-usb";
+   usb->data.flags = soc->flags;
+   usb->data.usb_phy = usb->phy;
+   usb->data.capoffset = DEF_CAPOFFSET;
+
+   usb->dev = ci_hdrc_add_device(&pdev->dev, pdev->resource,
+ pdev->num_resources, &usb->data);
+   if (IS_ERR(usb->dev)) {
+   err = PTR_ERR(usb->dev);
dev_err(&pdev->dev, "failed to add HDRC device: %d\n", err);
goto fail_power_off;
}
 
-   platform_set_drvdata(pdev, udc);
+   platform_set_drvdata(pdev, usb);
 
return 0;
 
 fail_power_off:
-   clk_disable_unprepare(udc->clk);

[PATCH v2 5/8] usb: chipidea: tegra: Support host mode

2020-12-17 Thread Dmitry Osipenko
From: Peter Geis 

Add USB host mode to the Tegra HDRC driver. This allows us to benefit from
support provided by the generic ChipIdea driver instead of duplicating the
effort in a separate ehci-tegra driver.

Tested-by: Matt Merhar 
Tested-by: Nicolas Chauvet 
Tested-by: Ion Agorria 
Signed-off-by: Peter Geis 
Signed-off-by: Dmitry Osipenko 
---
 drivers/usb/chipidea/Kconfig |   1 -
 drivers/usb/chipidea/ci_hdrc_tegra.c | 243 ++-
 drivers/usb/chipidea/core.c  |  10 +-
 drivers/usb/chipidea/host.c  | 104 +++-
 include/linux/usb/chipidea.h |   6 +
 5 files changed, 356 insertions(+), 8 deletions(-)

diff --git a/drivers/usb/chipidea/Kconfig b/drivers/usb/chipidea/Kconfig
index 8685ead6ccc7..661818e8fed6 100644
--- a/drivers/usb/chipidea/Kconfig
+++ b/drivers/usb/chipidea/Kconfig
@@ -55,7 +55,6 @@ config USB_CHIPIDEA_GENERIC
 config USB_CHIPIDEA_TEGRA
tristate "Enable Tegra USB glue driver" if EMBEDDED
depends on OF
-   depends on USB_CHIPIDEA_UDC
default USB_CHIPIDEA
 
 endif
diff --git a/drivers/usb/chipidea/ci_hdrc_tegra.c 
b/drivers/usb/chipidea/ci_hdrc_tegra.c
index d8efa80aa1c2..5fccdeeefc64 100644
--- a/drivers/usb/chipidea/ci_hdrc_tegra.c
+++ b/drivers/usb/chipidea/ci_hdrc_tegra.c
@@ -4,11 +4,18 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
 
+#include 
 #include 
+#include 
+#include 
+#include 
+
+#include "../host/ehci.h"
 
 #include "ci.h"
 
@@ -16,20 +23,47 @@ struct tegra_usb {
struct ci_hdrc_platform_data data;
struct platform_device *dev;
 
+   const struct tegra_usb_soc_info *soc;
struct usb_phy *phy;
struct clk *clk;
+
+   bool needs_double_reset;
 };
 
 struct tegra_usb_soc_info {
unsigned long flags;
+   unsigned int txfifothresh;
+   enum usb_dr_mode dr_mode;
+};
+
+static const struct tegra_usb_soc_info tegra20_ehci_soc_info = {
+   .flags = CI_HDRC_REQUIRES_ALIGNED_DMA |
+CI_HDRC_OVERRIDE_PHY_CONTROL,
+   .dr_mode = USB_DR_MODE_HOST,
+   .txfifothresh = 10,
+};
+
+static const struct tegra_usb_soc_info tegra30_ehci_soc_info = {
+   .flags = CI_HDRC_REQUIRES_ALIGNED_DMA |
+CI_HDRC_OVERRIDE_PHY_CONTROL,
+   .dr_mode = USB_DR_MODE_HOST,
+   .txfifothresh = 16,
 };
 
 static const struct tegra_usb_soc_info tegra_udc_soc_info = {
-   .flags = CI_HDRC_REQUIRES_ALIGNED_DMA,
+   .flags = CI_HDRC_REQUIRES_ALIGNED_DMA |
+CI_HDRC_OVERRIDE_PHY_CONTROL,
+   .dr_mode = USB_DR_MODE_UNKNOWN,
 };
 
 static const struct of_device_id tegra_usb_of_match[] = {
{
+   .compatible = "nvidia,tegra20-ehci",
+   .data = &tegra20_ehci_soc_info,
+   }, {
+   .compatible = "nvidia,tegra30-ehci",
+   .data = &tegra30_ehci_soc_info,
+   }, {
.compatible = "nvidia,tegra20-udc",
.data = &tegra_udc_soc_info,
}, {
@@ -47,6 +81,181 @@ static const struct of_device_id tegra_usb_of_match[] = {
 };
 MODULE_DEVICE_TABLE(of, tegra_usb_of_match);
 
+static int tegra_usb_reset_controller(struct device *dev)
+{
+   struct reset_control *rst, *rst_utmi;
+   struct device_node *phy_np;
+   int err;
+
+   rst = devm_reset_control_get_shared(dev, "usb");
+   if (IS_ERR(rst)) {
+   dev_err(dev, "can't get ehci reset: %pe\n", rst);
+   return PTR_ERR(rst);
+   }
+
+   phy_np = of_parse_phandle(dev->of_node, "nvidia,phy", 0);
+   if (!phy_np)
+   return -ENOENT;
+
+   /*
+* The 1st USB controller contains some UTMI pad registers that are
+* global for all the controllers on the chip. Those registers are
+* also cleared when reset is asserted to the 1st controller.
+*/
+   rst_utmi = of_reset_control_get_shared(phy_np, "utmi-pads");
+   if (IS_ERR(rst_utmi)) {
+   dev_warn(dev, "can't get utmi-pads reset from the PHY\n");
+   dev_warn(dev, "continuing, but please update your DT\n");
+   } else {
+   /*
+* PHY driver performs UTMI-pads reset in a case of a
+* non-legacy DT.
+*/
+   reset_control_put(rst_utmi);
+   }
+
+   of_node_put(phy_np);
+
+   /* reset control is shared, hence initialize it first */
+   err = reset_control_deassert(rst);
+   if (err)
+   return err;
+
+   err = reset_control_assert(rst);
+   if (err)
+   return err;
+
+   udelay(1);
+
+   err = reset_control_deassert(rst);
+   if (err)
+   return err;
+
+   return 0;
+}
+
+static int tegra_usb_notify_event(struct ci_hdrc *ci, unsigned int event)
+{
+   struct tegra_usb *usb = dev_get_drvdata(ci->dev->parent);
+   struct ehci_hcd *ehci;
+
+   switch (event) {
+   case CI_HDRC_CONTROLLER_RESET_EVENT:
+   if

[PATCH v2 7/8] usb: host: ehci-tegra: Remove the driver

2020-12-17 Thread Dmitry Osipenko
The ChipIdea driver now provides USB2 host mode support for NVIDIA Tegra
SoCs. The ehci-tegra driver is obsolete now, remove it and redirect the
older Kconfig entry to the CI driver.

Tested-by: Matt Merhar 
Tested-by: Nicolas Chauvet 
Tested-by: Peter Geis 
Tested-by: Ion Agorria 
Signed-off-by: Dmitry Osipenko 
---
 drivers/usb/host/Kconfig  |   8 +-
 drivers/usb/host/Makefile |   1 -
 drivers/usb/host/ehci-tegra.c | 604 --
 3 files changed, 6 insertions(+), 607 deletions(-)
 delete mode 100644 drivers/usb/host/ehci-tegra.c

diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 31e59309da1f..318315602337 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -269,9 +269,13 @@ config USB_EHCI_HCD_AT91
 config USB_EHCI_TEGRA
tristate "NVIDIA Tegra HCD support"
depends on ARCH_TEGRA
-   select USB_EHCI_ROOT_HUB_TT
-   select USB_TEGRA_PHY
+   select USB_CHIPIDEA
+   select USB_CHIPIDEA_HOST
+   select USB_CHIPIDEA_TEGRA
help
+ This option is deprecated now and the driver was removed, use
+ USB_CHIPIDEA_TEGRA instead.
+
  This driver enables support for the internal USB Host Controllers
  found in NVIDIA Tegra SoCs. The controllers are EHCI compliant.
 
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index c1b08703af10..3e4d298d851f 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -47,7 +47,6 @@ obj-$(CONFIG_USB_EHCI_HCD_SPEAR)  += ehci-spear.o
 obj-$(CONFIG_USB_EHCI_HCD_STI) += ehci-st.o
 obj-$(CONFIG_USB_EHCI_EXYNOS)  += ehci-exynos.o
 obj-$(CONFIG_USB_EHCI_HCD_AT91) += ehci-atmel.o
-obj-$(CONFIG_USB_EHCI_TEGRA)   += ehci-tegra.o
 obj-$(CONFIG_USB_EHCI_BRCMSTB) += ehci-brcm.o
 
 obj-$(CONFIG_USB_OXU210HP_HCD) += oxu210hp-hcd.o
diff --git a/drivers/usb/host/ehci-tegra.c b/drivers/usb/host/ehci-tegra.c
deleted file mode 100644
index 869d9c4de5fc..
--- a/drivers/usb/host/ehci-tegra.c
+++ /dev/null
@@ -1,604 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * EHCI-compliant USB host controller driver for NVIDIA Tegra SoCs
- *
- * Copyright (C) 2010 Google, Inc.
- * Copyright (C) 2009 - 2013 NVIDIA Corporation
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#include "ehci.h"
-
-#define PORT_WAKE_BITS (PORT_WKOC_E|PORT_WKDISC_E|PORT_WKCONN_E)
-
-#define TEGRA_USB_DMA_ALIGN 32
-
-#define DRIVER_DESC "Tegra EHCI driver"
-#define DRV_NAME "tegra-ehci"
-
-static struct hc_driver __read_mostly tegra_ehci_hc_driver;
-
-struct tegra_ehci_soc_config {
-   bool has_hostpc;
-};
-
-struct tegra_ehci_hcd {
-   struct clk *clk;
-   struct reset_control *rst;
-   int port_resuming;
-   bool needs_double_reset;
-};
-
-static int tegra_reset_usb_controller(struct platform_device *pdev)
-{
-   struct device_node *phy_np;
-   struct usb_hcd *hcd = platform_get_drvdata(pdev);
-   struct tegra_ehci_hcd *tegra =
-   (struct tegra_ehci_hcd *)hcd_to_ehci(hcd)->priv;
-   struct reset_control *rst;
-   int err;
-
-   phy_np = of_parse_phandle(pdev->dev.of_node, "nvidia,phy", 0);
-   if (!phy_np)
-   return -ENOENT;
-
-   /*
-* The 1st USB controller contains some UTMI pad registers that are
-* global for all the controllers on the chip. Those registers are
-* also cleared when reset is asserted to the 1st controller.
-*/
-   rst = of_reset_control_get_shared(phy_np, "utmi-pads");
-   if (IS_ERR(rst)) {
-   dev_warn(&pdev->dev,
-"can't get utmi-pads reset from the PHY\n");
-   dev_warn(&pdev->dev,
-"continuing, but please update your DT\n");
-   } else {
-   /*
-* PHY driver performs UTMI-pads reset in a case of
-* non-legacy DT.
-*/
-   reset_control_put(rst);
-   }
-
-   of_node_put(phy_np);
-
-   /* reset control is shared, hence initialize it first */
-   err = reset_control_deassert(tegra->rst);
-   if (err)
-   return err;
-
-   err = reset_control_assert(tegra->rst);
-   if (err)
-   return err;
-
-   udelay(1);
-
-   err = reset_control_deassert(tegra->rst);
-   if (err)
-   return err;
-
-   return 0;
-}
-
-static int tegra_ehci_internal_port_reset(
-   struct ehci_hcd *ehci,
-   u32 __iomem *portsc_reg
-)
-{
-   u32 temp;
-   unsigned long   flags;
-   int retval = 0;
-   int i, tries;
-   u32 saved_usbintr;
-
-   spin_lock_irqsave(&ehci->lock, flags);
-   saved_usbintr = ehci_readl(ehci, &ehci->regs->intr_enable);
-   /* di

Re: [PATCH] media: venus: preserve DRC state across seeks

2020-12-17 Thread Stanimir Varbanov
Hi Alex,


On 12/2/20 7:34 AM, Alexandre Courbot wrote:
> DRC events can happen virtually at anytime, including when we are
> starting a seek. Should this happen, we must make sure to return to the
> DRC state, otherwise the firmware will expect buffers of the new
> resolution whereas userspace will still work with the old one.
> 
> Returning to the DRC state upon resume for seeking makes sure that the
> client will get the DRC event and will reallocate the buffers to fit the
> firmware's expectations.
> 
> Signed-off-by: Alexandre Courbot 
> ---
>  drivers/media/platform/qcom/venus/vdec.c | 11 +--
>  1 file changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/media/platform/qcom/venus/vdec.c 
> b/drivers/media/platform/qcom/venus/vdec.c
> index 8488411204c3..e3d0df7fd765 100644
> --- a/drivers/media/platform/qcom/venus/vdec.c
> +++ b/drivers/media/platform/qcom/venus/vdec.c
> @@ -972,7 +972,10 @@ static int vdec_start_output(struct venus_inst *inst)
>  
>   if (inst->codec_state == VENUS_DEC_STATE_SEEK) {
>   ret = venus_helper_process_initial_out_bufs(inst);
> - inst->codec_state = VENUS_DEC_STATE_DECODING;
> + if (inst->next_buf_last)
> + inst->codec_state = VENUS_DEC_STATE_DRC;
> + else
> + inst->codec_state = VENUS_DEC_STATE_DECODING;
>   goto done;
>   }
>  
> @@ -1077,8 +1080,10 @@ static int vdec_stop_capture(struct venus_inst *inst)
>   ret = hfi_session_flush(inst, HFI_FLUSH_ALL, true);
>   fallthrough;
>   case VENUS_DEC_STATE_DRAIN:
> - vdec_cancel_dst_buffers(inst);
>   inst->codec_state = VENUS_DEC_STATE_STOPPED;
> + fallthrough;
> + case VENUS_DEC_STATE_SEEK:
> + vdec_cancel_dst_buffers(inst);
>   break;
>   case VENUS_DEC_STATE_DRC:
>   WARN_ON(1);
> @@ -1102,6 +1107,7 @@ static int vdec_stop_output(struct venus_inst *inst)
>   case VENUS_DEC_STATE_DECODING:
>   case VENUS_DEC_STATE_DRAIN:
>   case VENUS_DEC_STATE_STOPPED:
> + case VENUS_DEC_STATE_DRC:
>   ret = hfi_session_flush(inst, HFI_FLUSH_ALL, true);
>   inst->codec_state = VENUS_DEC_STATE_SEEK;
>   break;
> @@ -1371,6 +1377,7 @@ static void vdec_event_change(struct venus_inst *inst,
>   dev_dbg(dev, VDBGH "flush output error %d\n", ret);
>   }
>  
> + inst->next_buf_last = true;

Setting next_buf_last unconditionally makes me think can we reuse
inst->reconfig instead?

>   inst->reconfig = true;
>   v4l2_event_queue_fh(&inst->fh, &ev);
>   wake_up(&inst->reconf_wait);
> 

-- 
regards,
Stan


[PATCH v2 6/8] usb: chipidea: tegra: Support runtime PM

2020-12-17 Thread Dmitry Osipenko
Tegra PHY driver now supports waking up controller from a low power mode.
Enable runtime PM in order to put controller into the LPM during idle.

Tested-by: Matt Merhar 
Tested-by: Nicolas Chauvet 
Tested-by: Peter Geis 
Tested-by: Ion Agorria 
Signed-off-by: Dmitry Osipenko 
---
 drivers/usb/chipidea/ci_hdrc_tegra.c | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/chipidea/ci_hdrc_tegra.c 
b/drivers/usb/chipidea/ci_hdrc_tegra.c
index 5fccdeeefc64..655671159511 100644
--- a/drivers/usb/chipidea/ci_hdrc_tegra.c
+++ b/drivers/usb/chipidea/ci_hdrc_tegra.c
@@ -38,21 +38,24 @@ struct tegra_usb_soc_info {
 
 static const struct tegra_usb_soc_info tegra20_ehci_soc_info = {
.flags = CI_HDRC_REQUIRES_ALIGNED_DMA |
-CI_HDRC_OVERRIDE_PHY_CONTROL,
+CI_HDRC_OVERRIDE_PHY_CONTROL |
+CI_HDRC_SUPPORTS_RUNTIME_PM,
.dr_mode = USB_DR_MODE_HOST,
.txfifothresh = 10,
 };
 
 static const struct tegra_usb_soc_info tegra30_ehci_soc_info = {
.flags = CI_HDRC_REQUIRES_ALIGNED_DMA |
-CI_HDRC_OVERRIDE_PHY_CONTROL,
+CI_HDRC_OVERRIDE_PHY_CONTROL |
+CI_HDRC_SUPPORTS_RUNTIME_PM,
.dr_mode = USB_DR_MODE_HOST,
.txfifothresh = 16,
 };
 
 static const struct tegra_usb_soc_info tegra_udc_soc_info = {
.flags = CI_HDRC_REQUIRES_ALIGNED_DMA |
-CI_HDRC_OVERRIDE_PHY_CONTROL,
+CI_HDRC_OVERRIDE_PHY_CONTROL |
+CI_HDRC_SUPPORTS_RUNTIME_PM,
.dr_mode = USB_DR_MODE_UNKNOWN,
 };
 
@@ -323,6 +326,10 @@ static int tegra_usb_probe(struct platform_device *pdev)
usb->data.hub_control = tegra_ehci_hub_control;
usb->data.notify_event = tegra_usb_notify_event;
 
+   /* Tegra PHY driver currently doesn't support LPM for ULPI */
+   if (of_usb_get_phy_mode(pdev->dev.of_node) == 
USBPHY_INTERFACE_MODE_ULPI)
+   usb->data.flags &= ~CI_HDRC_SUPPORTS_RUNTIME_PM;
+
usb->dev = ci_hdrc_add_device(&pdev->dev, pdev->resource,
  pdev->num_resources, &usb->data);
if (IS_ERR(usb->dev)) {
-- 
2.29.2



Re: [PATCH -next] ti/fapll: Delete useless kfree code

2020-12-17 Thread Stephen Boyd
Quoting Zheng Yongjun (2020-12-16 05:05:34)
> The parameter of kfree function is NULL, so kfree code is useless, delete it.

Not always though. Sometimes it is non-NULL and this code avoids a goto.

> 
> Signed-off-by: Zheng Yongjun 
> ---
>  drivers/clk/ti/fapll.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/clk/ti/fapll.c b/drivers/clk/ti/fapll.c
> index 95e36ba64acc..a61d69159e9a 100644
> --- a/drivers/clk/ti/fapll.c
> +++ b/drivers/clk/ti/fapll.c
> @@ -523,7 +523,6 @@ static struct clk * __init ti_fapll_synth_setup(struct 
> fapll_data *fd,
> return clk_register(NULL, &synth->hw);
>  
>  free:
> -   kfree(synth);
> kfree(init);
>  
> return ERR_PTR(-ENOMEM);


Re: [PATCH V2] scsi: ufs-debugfs: Add error counters

2020-12-17 Thread Adrian Hunter
On 16/12/20 10:16 pm, Bean Huo wrote:
> On Wed, 2020-12-16 at 20:51 +0200, Adrian Hunter wrote:
>> ufshcd_variant_hba_exit(hba);
>> ufshcd_setup_vreg(hba, false);
>> ufshcd_suspend_clkscaling(hba);
>> @@ -9436,6 +9441,20 @@ int ufshcd_init(struct ufs_hba *hba, void
>> __iomem *mmio_base, unsigned int irq)
>>  }
>>  EXPORT_SYMBOL_GPL(ufshcd_init);
>>  
>> +static int __init ufshcd_core_init(void)
>> +{
>> +   ufs_debugfs_init();
>> +   return 0;
>> +}
>> +
>> +static void __exit ufshcd_core_exit(void)
>> +{
>> +   ufs_debugfs_exit();
>> +}
> 
> Hi, Adrian

Thanks for looking at the patch.

> 
> The purpose of patch is acceptable, but I don't know why you choose
> using ufshcd_core_* here. 

Do you mean you would like a different function name?  'ufshcd_init' is used
already.  The module is called ufshcd-core, so ufshcd_core_* seems appropriate.

> Also. I don't know if module_init()  is a proper way here.

Can you be more specific?  It is normal to do module initialization in
module_init().

However I do see a problem.  When builtin, initcalls are ordered according
to link order, but the Makefile does not have ufshcd-core at the top i.e.

$ cat drivers/scsi/ufs/Makefile
# SPDX-License-Identifier: GPL-2.0
# UFSHCD makefile
obj-$(CONFIG_SCSI_UFS_DWC_TC_PCI) += tc-dwc-g210-pci.o ufshcd-dwc.o
tc-dwc-g210.o
obj-$(CONFIG_SCSI_UFS_DWC_TC_PLATFORM) += tc-dwc-g210-pltfrm.o ufshcd-dwc.o
tc-dwc-g210.o
obj-$(CONFIG_SCSI_UFS_CDNS_PLATFORM) += cdns-pltfrm.o
obj-$(CONFIG_SCSI_UFS_QCOM) += ufs_qcom.o
ufs_qcom-y += ufs-qcom.o
ufs_qcom-$(CONFIG_SCSI_UFS_CRYPTO) += ufs-qcom-ice.o
obj-$(CONFIG_SCSI_UFS_EXYNOS) += ufs-exynos.o
obj-$(CONFIG_SCSI_UFSHCD) += ufshcd-core.o
ufshcd-core-y   += ufshcd.o ufs-sysfs.o
ufshcd-core-$(CONFIG_DEBUG_FS)  += ufs-debugfs.o
ufshcd-core-$(CONFIG_SCSI_UFS_BSG)  += ufs_bsg.o
ufshcd-core-$(CONFIG_SCSI_UFS_CRYPTO) += ufshcd-crypto.o
obj-$(CONFIG_SCSI_UFSHCD_PCI) += ufshcd-pci.o
obj-$(CONFIG_SCSI_UFSHCD_PLATFORM) += ufshcd-pltfrm.o
obj-$(CONFIG_SCSI_UFS_HISI) += ufs-hisi.o
obj-$(CONFIG_SCSI_UFS_MEDIATEK) += ufs-mediatek.o
obj-$(CONFIG_SCSI_UFS_TI_J721E) += ti-j721e-ufs.o

Should be:

# SPDX-License-Identifier: GPL-2.0
# UFSHCD makefile
# Order here is important. ufshcd-core must initialize first.
ufshcd-core-y   += ufshcd.o ufs-sysfs.o
ufshcd-core-$(CONFIG_DEBUG_FS)  += ufs-debugfs.o
ufshcd-core-$(CONFIG_SCSI_UFS_BSG)  += ufs_bsg.o
ufshcd-core-$(CONFIG_SCSI_UFS_CRYPTO) += ufshcd-crypto.o
obj-$(CONFIG_SCSI_UFS_DWC_TC_PCI) += tc-dwc-g210-pci.o ufshcd-dwc.o
tc-dwc-g210.o
obj-$(CONFIG_SCSI_UFS_DWC_TC_PLATFORM) += tc-dwc-g210-pltfrm.o ufshcd-dwc.o
tc-dwc-g210.o
obj-$(CONFIG_SCSI_UFS_CDNS_PLATFORM) += cdns-pltfrm.o
obj-$(CONFIG_SCSI_UFS_QCOM) += ufs_qcom.o
ufs_qcom-y += ufs-qcom.o
ufs_qcom-$(CONFIG_SCSI_UFS_CRYPTO) += ufs-qcom-ice.o
obj-$(CONFIG_SCSI_UFS_EXYNOS) += ufs-exynos.o
obj-$(CONFIG_SCSI_UFSHCD) += ufshcd-core.o
obj-$(CONFIG_SCSI_UFSHCD_PCI) += ufshcd-pci.o
obj-$(CONFIG_SCSI_UFSHCD_PLATFORM) += ufshcd-pltfrm.o
obj-$(CONFIG_SCSI_UFS_HISI) += ufs-hisi.o
obj-$(CONFIG_SCSI_UFS_MEDIATEK) += ufs-mediatek.o
obj-$(CONFIG_SCSI_UFS_TI_J721E) += ti-j721e-ufs.o

What do you think?

> 
> thanks,
> Bean
> 
>>
>> n
>> +
>> +module_init(ufshcd_core_init);
>> +module_exit(ufshcd_core_exit)
> 



Re: [RESEND PATCH 1/2] clk: axi-clkgen: wrap limits in a struct and keep copy on the state object

2020-12-17 Thread Stephen Boyd
Quoting Alexandru Ardelean (2020-12-02 23:40:36)
> Up until the these limits were global/hard-coded, since they are typically
> limits of the fabric.
> 
> However, since this is an FPGA generated clock, this may run on setups
> where one clock is on a fabric, and another one synthesized on another
> fabric connected via PCIe (or some other inter-connect, and then these
> limits need to be adjusted for each instance of the AXI CLKGEN.
> 
> This change wraps the current constants in 'axi_clkgen_limits' struct and
> the 'axi_clkgen' instance keeps a copy of these limits, which is
> initialized at probe from the default limits.
> 
> The limits are stored on the device-tree OF table, so that we can adjust
> them via the compatible string.
> 
> Signed-off-by: Alexandru Ardelean 
> ---

Applied to clk-next


Re: [PATCH v2] dt-bindings: clock: adi,axi-clkgen: convert old binding to yaml format

2020-12-17 Thread Stephen Boyd
Quoting Alexandru Ardelean (2020-10-13 07:34:20)
> This change converts the old binding for the AXI clkgen driver to a yaml
> format.
> 
> As maintainers, added:
>  - Lars-Peter Clausen  - as original author of driver &
>binding
>  - Michael Hennerich  - as supporter of
>Analog Devices drivers
> 
> Acked-by: Michael Hennerich 
> Acked-by: Lars-Peter Clausen 
> Signed-off-by: Alexandru Ardelean 
> ---

Applied to clk-next


Re: [RESEND PATCH 2/2] clk: axi-clkgen: move the OF table at the bottom of the file

2020-12-17 Thread Stephen Boyd
Quoting Alexandru Ardelean (2020-12-02 23:40:37)
> The change is mostly cosmetic. No functional changes.
> Since the driver now uses of_device_get_match_data() to obtain some driver
> specific info, there is no need to define the OF table before the probe
> function.
> 
> Signed-off-by: Alexandru Ardelean 
> ---

Applied to clk-next


Re: [PATCH v4 3/6] clk: ralink: add clock driver for mt7621 SoC

2020-12-17 Thread Sergio Paracuellos
Hi Stephen,

Thanks for the review.

On Thu, Dec 17, 2020 at 10:09 AM Stephen Boyd  wrote:
>
> Quoting Sergio Paracuellos (2020-11-22 01:55:53)
> > The documentation for this SOC only talks about two
> > registers regarding to the clocks:
> > * SYSC_REG_CPLL_CLKCFG0 - provides some information about
> > boostrapped refclock. PLL and dividers used for CPU and some
> > sort of BUS.
> > * SYSC_REG_CPLL_CLKCFG1 - a banch of gates to enable/disable
> > clocks for all or some ip cores.
> >
> > Looking into driver code, and some openWRT patched there are
> > another frequences which are used in some drivers (uart, sd...).
>
> s/frequences/frequencies/

Ok!

>
> > According to all of this information the clock plan for this
> > SoC is set as follows:
> > - Main top clock "xtal" from where all the rest of the world is
> > derived.
> > - CPU clock "cpu" derived from "xtal" frequencies and a bunch of
> > register reads and predividers.
> > - BUS clock "bus" derived from "cpu" and with (cpu / 4) MHz.
> > - Fixed clocks from "xtal":
> > * "50m": 50 MHz.
> > * "125m": 125 MHz.
> > * "150m": 150 MHz.
> > * "250m": 250 MHz.
> > * "270m": 270 MHz.
> >
> > We also have a buch of gate clocks with their parents:
> >   * "hsdma": "150m"
> >   * "fe": "250m"
> >   * "sp_divtx": "270m"
> >   * "timer": "50m"
> >   * "pcm": "270m"
> >   * "pio": "50m"
> >   * "gdma": "bus"
> >   * "nand": "125m"
> >   * "i2c": "50m"
> >   * "i2s": "270m"
> >   * "spi": "bus"
> >   * "uart1": "50m"
> >   * "uart2": "50m"
> >   * "uart3": "50m"
> >   * "eth": "50m"
> >   * "pcie0": "125m"
> >   * "pcie1": "125m"
> >   * "pcie2": "125m"
> >   * "crypto": "250m"
> >   * "shxc": "50m"
> >
> > With this information the clk driver will provide clock and gates
> > functionality from a a set of hardcoded clocks allowing to define
> > a nice device tree without fixed clocks.
> >
> > Signed-off-by: Sergio Paracuellos 
> > ---
> >  drivers/clk/Kconfig |   1 +
> >  drivers/clk/Makefile|   1 +
> >  drivers/clk/ralink/Kconfig  |  14 +
> >  drivers/clk/ralink/Makefile |   2 +
> >  drivers/clk/ralink/clk-mt7621.c | 435 
> >  5 files changed, 453 insertions(+)
> >  create mode 100644 drivers/clk/ralink/Kconfig
> >  create mode 100644 drivers/clk/ralink/Makefile
> >  create mode 100644 drivers/clk/ralink/clk-mt7621.c
> >
> > diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
> > index c715d4681a0b..5f94c4329033 100644
> > --- a/drivers/clk/Kconfig
> > +++ b/drivers/clk/Kconfig
> > @@ -372,6 +372,7 @@ source "drivers/clk/mediatek/Kconfig"
> >  source "drivers/clk/meson/Kconfig"
> >  source "drivers/clk/mvebu/Kconfig"
> >  source "drivers/clk/qcom/Kconfig"
> > +source "drivers/clk/ralink/Kconfig"
> >  source "drivers/clk/renesas/Kconfig"
> >  source "drivers/clk/rockchip/Kconfig"
> >  source "drivers/clk/samsung/Kconfig"
> > diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
> > index da8fcf147eb1..6578e167b047 100644
> > --- a/drivers/clk/Makefile
> > +++ b/drivers/clk/Makefile
> > @@ -100,6 +100,7 @@ obj-$(CONFIG_COMMON_CLK_NXP)+= nxp/
> >  obj-$(CONFIG_MACH_PISTACHIO)   += pistachio/
> >  obj-$(CONFIG_COMMON_CLK_PXA)   += pxa/
> >  obj-$(CONFIG_COMMON_CLK_QCOM)  += qcom/
> > +obj-y  += ralink/
> >  obj-y  += renesas/
> >  obj-$(CONFIG_ARCH_ROCKCHIP)+= rockchip/
> >  obj-$(CONFIG_COMMON_CLK_SAMSUNG)   += samsung/
>
> Thanks for keeping it sorted!

It was so clean sorted so I just followed the style there.

>
> > diff --git a/drivers/clk/ralink/Kconfig b/drivers/clk/ralink/Kconfig
> > new file mode 100644
> > index ..7e8697327e0c
> > --- /dev/null
> > +++ b/drivers/clk/ralink/Kconfig
> > @@ -0,0 +1,14 @@
> > +# SPDX-License-Identifier: GPL-2.0-only
> > +#
> > +# MediaTek Mt7621 Clock Driver
> > +#
> > +menu "Clock driver for mediatek mt7621 SoC"
>
> Capitalize MediaTek?

Will do.

>
> > +   depends on SOC_MT7621 || COMPILE_TEST
> > +
> > +config CLK_MT7621
> > +   bool "Clock driver for MediaTek MT7621"
>
> Like it is done here.

Yes, both should be properly capitalized.

>
> > +   depends on SOC_MT7621 || COMPILE_TEST
> > +   default SOC_MT7621
> > +   help
> > + This driver supports MediaTek MT7621 basic clocks.
> > +endmenu
> > diff --git a/drivers/clk/ralink/Makefile b/drivers/clk/ralink/Makefile
> > new file mode 100644
> > index ..cf6f9216379d
> > --- /dev/null
> > +++ b/drivers/clk/ralink/Makefile
> > @@ -0,0 +1,2 @@
> > +# SPDX-License-Identifier: GPL-2.0
> > +obj-$(CONFIG_CLK_MT7621) += clk-mt7621.o
> > diff --git a/drivers/clk/ralink/clk-mt7621.c 
> > b/drivers/clk/ralink/clk-mt7621.c
> > new file mode 100644
> > index ..4e929f13fe7c
> > --- /dev/null
> > +++ b/drivers/clk/ralink/clk-mt7621.c
> > @@ -0,0 +1,435 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Mediatek MT76

Re: [RFC PATCH v1 7/7] powerpc/bpf: Implement extended BPF on PPC32

2020-12-17 Thread Christophe Leroy




Le 17/12/2020 à 07:11, Alexei Starovoitov a écrit :

On Wed, Dec 16, 2020 at 10:07:37AM +, Christophe Leroy wrote:

Implement Extended Berkeley Packet Filter on Powerpc 32

Test result with test_bpf module:

test_bpf: Summary: 378 PASSED, 0 FAILED, [354/366 JIT'ed]


nice!


Registers mapping:

[BPF_REG_0] = r11-r12
/* function arguments */
[BPF_REG_1] = r3-r4
[BPF_REG_2] = r5-r6
[BPF_REG_3] = r7-r8
[BPF_REG_4] = r9-r10
[BPF_REG_5] = r21-r22 (Args 9 and 10 come in via the stack)
/* non volatile registers */
[BPF_REG_6] = r23-r24
[BPF_REG_7] = r25-r26
[BPF_REG_8] = r27-r28
[BPF_REG_9] = r29-r30
/* frame pointer aka BPF_REG_10 */
[BPF_REG_FP] = r31
/* eBPF jit internal registers */
[BPF_REG_AX] = r19-r20
[TMP_REG] = r18

As PPC32 doesn't have a redzone in the stack,
use r17 as tail call counter.

r0 is used as temporary register as much as possible. It is referenced
directly in the code in order to avoid misuse of it, because some
instructions interpret it as value 0 instead of register r0
(ex: addi, addis, stw, lwz, ...)

The following operations are not implemented:

case BPF_ALU64 | BPF_DIV | BPF_X: /* dst /= src */
case BPF_ALU64 | BPF_MOD | BPF_X: /* dst %= src */
case BPF_STX | BPF_XADD | BPF_DW: /* *(u64 *)(dst + off) += src 
*/

The following operations are only implemented for power of two constants:

case BPF_ALU64 | BPF_MOD | BPF_K: /* dst %= imm */
case BPF_ALU64 | BPF_DIV | BPF_K: /* dst /= imm */


Those are sensible limitations. MOD and DIV are rare, but XADD is common.
Please consider doing it as a cmpxchg loop in the future.

Also please run test_progs. It will give a lot better coverage than test_bpf.ko



I'm having hard time cross building test_progs:

~/linux-powerpc/tools/testing/selftests/bpf/$ make CROSS_COMPILE=ppc-linux-
...
  GEN 
/home/chr/linux-powerpc/tools/testing/selftests/bpf/tools/build/bpftool/Documentation/bpf-helpers.7

  INSTALL  eBPF_helpers-manpage
  INSTALL  Documentation-man
  GEN  vmlinux.h
/bin/sh: /home/chr/linux-powerpc/tools/testing/selftests/bpf/tools/sbin/bpftool: cannot execute 
binary file

make: *** 
[/home/chr/linux-powerpc/tools/testing/selftests/bpf/tools/include/vmlinux.h] 
Error 126
make: *** Deleting file 
`/home/chr/linux-powerpc/tools/testing/selftests/bpf/tools/include/vmlinux.h'

Looks like it builds bpftool for powerpc and tries to run it on my x86.
How should I proceed ?

Thanks
Christophe


Re: [PATCH v1 ] ALSA: core: memalloc: add page alignment for iram

2020-12-17 Thread Takashi Iwai
On Thu, 17 Dec 2020 10:43:45 +0100,
Lars-Peter Clausen wrote:
> 
> On 12/17/20 5:15 PM, Robin Gong wrote:
> > Since mmap for userspace is based on page alignment, add page alignment
> > for iram alloc from pool, otherwise, some good data located in the same
> > page of dmab->area maybe touched wrongly by userspace like pulseaudio.
> >
> I wonder, do we also have to align size to be a multiple of PAGE_SIZE
> to avoid leaking unrelated data?

Hm, a good question.  Basically the PCM buffer size itself shouldn't
be influenced by that (i.e. no hw-constraint or such is needed), but
the padding should be cleared indeed.  I somehow left those to the
allocator side, but maybe it's safer to clear the whole buffer in
sound/core/memalloc.c commonly.


thanks,

Takashi


Re: [PATCH 1/3] vfs: add new f_op->syncfs vector

2020-12-17 Thread Jan Kara
On Thu 17-12-20 00:49:35, Al Viro wrote:
> [Christoph added to Cc...]
> On Wed, Dec 16, 2020 at 06:31:47PM -0500, Vivek Goyal wrote:
> > Current implementation of __sync_filesystem() ignores the return code
> > from ->sync_fs(). I am not sure why that's the case. There must have
> > been some historical reason for this.
> > 
> > Ignoring ->sync_fs() return code is problematic for overlayfs where
> > it can return error if sync_filesystem() on upper super block failed.
> > That error will simply be lost and sycnfs(overlay_fd), will get
> > success (despite the fact it failed).
> > 
> > If we modify existing implementation, there is a concern that it will
> > lead to user space visible behavior changes and break things. So
> > instead implement a new file_operations->syncfs() call which will
> > be called in syncfs() syscall path. Return code from this new
> > call will be captured. And all the writeback error detection
> > logic can go in there as well. Only filesystems which implement
> > this call get affected by this change. Others continue to fallback
> > to existing mechanism.
> 
> That smells like a massive source of confusion down the road.  I'd just
> looked through the existing instances; many always return 0, but quite
> a few sometimes try to return an error:
> fs/btrfs/super.c:2412:  .sync_fs= btrfs_sync_fs,
> fs/exfat/super.c:204:   .sync_fs= exfat_sync_fs,
> fs/ext4/super.c:1674:   .sync_fs= ext4_sync_fs,
> fs/f2fs/super.c:2480:   .sync_fs= f2fs_sync_fs,
> fs/gfs2/super.c:1600:   .sync_fs= gfs2_sync_fs,
> fs/hfsplus/super.c:368: .sync_fs= hfsplus_sync_fs,
> fs/nilfs2/super.c:689:  .sync_fs= nilfs_sync_fs,
> fs/ocfs2/super.c:139:   .sync_fs= ocfs2_sync_fs,
> fs/overlayfs/super.c:399:   .sync_fs= ovl_sync_fs,
> fs/ubifs/super.c:2052:  .sync_fs   = ubifs_sync_fs,
> is the list of such.  There are 4 method callers:
> dquot_quota_sync(), dquot_disable(), __sync_filesystem() and
> sync_fs_one_sb().  For sync_fs_one_sb() we want to ignore the
> return value; for __sync_filesystem() we almost certainly
> do *not* - it ends with return __sync_blockdev(sb->s_bdev, wait),
> after all.  The question for that one is whether we want
> __sync_blockdev() called even in case of ->sync_fs() reporting
> a failure, and I suspect that it's safer to call it anyway and
> return the first error value we'd got.  No idea about quota
> situation.

WRT quota situation: All the ->sync_fs() calls there are due to cache
coherency reasons (we need to get quota changes to disk, then prune quota
files's page cache, and then userspace can read current quota structures
from the disk). We don't want to fail dquot_disable() just because caches
might be incoherent so ignoring ->sync_fs() return value there is fine.
With dquot_quota_sync() it might make some sense to return the error -
that's just a backend for Q_SYNC quotactl(2). OTOH I'm not sure anybody
really cares - Q_SYNC is rarely used.

Honza
-- 
Jan Kara 
SUSE Labs, CR


Re: [PATCH v2 4/5] amba: Make the remove callback return void

2020-12-17 Thread Linus Walleij
On Mon, Dec 14, 2020 at 9:41 PM Uwe Kleine-König
 wrote:

> Technically there are still some maintainers' ack missing but I'd really
> like to get this series applied.  As I don't want to make people angry
> I'm asking once more for your Acks.

Acked-by: Linus Walleij 

Sorry for taking so long, it's nice work.

Yours,
Linus Walleij


Re: [PATCH v4 2/6] dt: bindings: add mt7621-clk device tree binding documentation

2020-12-17 Thread Sergio Paracuellos
Hi Stephen,

Thanks for the review!

On Thu, Dec 17, 2020 at 9:58 AM Stephen Boyd  wrote:
>
> Quoting Sergio Paracuellos (2020-11-22 01:55:52)
> > Adds device tree binding documentation for clocks in the
> > MT7621 SOC.
> >
> > Signed-off-by: Sergio Paracuellos 
> > ---
> >  .../bindings/clock/mediatek,mt7621-clk.yaml   | 67 +++
> >  1 file changed, 67 insertions(+)
> >  create mode 100644 
> > Documentation/devicetree/bindings/clock/mediatek,mt7621-clk.yaml
> >
>
> Rob?
>
> > diff --git 
> > a/Documentation/devicetree/bindings/clock/mediatek,mt7621-clk.yaml 
> > b/Documentation/devicetree/bindings/clock/mediatek,mt7621-clk.yaml
> > new file mode 100644
> > index ..6aca4c1a4a46
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/clock/mediatek,mt7621-clk.yaml
> > @@ -0,0 +1,67 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/clock/mediatek,mt7621-clk.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: MT7621 Clock Device Tree Bindings
> > +
> > +maintainers:
> > +  - Sergio Paracuellos 
> > +
> > +description: |
> > +  The MT7621 has a PLL controller from where the cpu clock is provided
> > +  as well as derived clocks for the bus and the peripherals. It also
> > +  can gate SoC device clocks.
> > +
> > +  Each clock is assigned an identifier and client nodes use this identifier
> > +  to specify the clock which they consume.
> > +
> > +  All these identifiers could be found in:
> > +  [1]: .
> > +
> > +  The mt7621 clock node should be the child of a syscon node with the
> > +  required property:
> > +
> > +  - compatible: Should be one of the following:
> > +"mediatek,mt7621-sysc", "syscon"
> > +
> > +  Refer to the bindings described in
> > +  Documentation/devicetree/bindings/mfd/syscon.yaml
> > +
> > +properties:
> > +  compatible:
> > +const: mediatek,mt7621-clk
> > +
> > +  "#clock-cells":
> > +description:
> > +  The first cell indicates the clock gate number, see [1] for available
> > +  clocks.
> > +const: 1
> > +
> > +  clock-output-names:
> > +maxItems: 8
> > +
> > +required:
> > +  - compatible
> > +  - '#clock-cells'
> > +  - clock-output-names
>
> Why is clock-output-names required? Hopefully it is not required.

Not really, can be removed from here.

>
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > +  - |
> > +#include 
> > +
> > +sysc: sysc@0 {
>
> syscon@0? I don't think sysc is a standard node name.

Ok, I will change this into syscon@0 in both bindings and device tree file.

>
> > +  compatible = "mediatek,mt7621-sysc", "syscon";
> > +  reg = <0x0 0x100>;
> > +
> > +  pll {
>
> clock-controller? Why can't the parent device be the clk provider and
> have #clock-cells?
>

I don't get your point, sorry. Can you please explain this a bit more
or point to me to an example to understand the real meaning of this?


> > +compatible = "mediatek,mt7621-clk";
> > +#clock-cells = <1>;
> > +clock-output-names = "xtal", "cpu", "bus",
> > + "50m", "125m", "150m",
> > + "250m", "270m";
> > +  };
> > +};

Best regards,
Sergio Paracuellos


Re: WARNING: suspicious RCU usage in modeset_lock

2020-12-17 Thread Daniel Vetter
On Wed, Dec 16, 2020 at 5:16 PM Paul E. McKenney  wrote:
>
> On Wed, Dec 16, 2020 at 10:52:06AM +0100, Daniel Vetter wrote:
> > On Wed, Dec 16, 2020 at 2:14 AM syzbot
> >  wrote:
> > >
> > > Hello,
> > >
> > > syzbot found the following issue on:
> > >
> > > HEAD commit:94801e5c Merge tag 'pinctrl-v5.10-3' of 
> > > git://git.kernel.o..
> > > git tree:   upstream
> > > console output: https://syzkaller.appspot.com/x/log.txt?x=130558c550
> > > kernel config:  https://syzkaller.appspot.com/x/.config?x=ee8a1012a5314210
> > > dashboard link: 
> > > https://syzkaller.appspot.com/bug?extid=972b924c988834e868b2
> > > compiler:   gcc (GCC) 10.1.0-syz 20200507
> > > userspace arch: i386
> > >
> > > Unfortunately, I don't have any reproducer for this issue yet.
> > >
> > > IMPORTANT: if you fix the issue, please add the following tag to the 
> > > commit:
> > > Reported-by: syzbot+972b924c988834e86...@syzkaller.appspotmail.com
> > >
> > > =
> > > WARNING: suspicious RCU usage
> > > 5.10.0-rc7-syzkaller #0 Not tainted
> > > -
> > > kernel/sched/core.c:7270 Illegal context switch in RCU-sched read-side 
> > > critical section!
> > >
> > > other info that might help us debug this:
> > >
> > >
> > > rcu_scheduler_active = 2, debug_locks = 0
> > > 7 locks held by syz-executor.1/9232:
> > >  #0: 8b328c60 (console_lock){+.+.}-{0:0}, at: 
> > > do_fb_ioctl+0x2e4/0x690 drivers/video/fbdev/core/fbmem.c:1106
> > >  #1: 888041bd4078 (&fb_info->lock){+.+.}-{3:3}, at: lock_fb_info 
> > > include/linux/fb.h:636 [inline]
> > >  #1: 888041bd4078 (&fb_info->lock){+.+.}-{3:3}, at: 
> > > do_fb_ioctl+0x2ee/0x690 drivers/video/fbdev/core/fbmem.c:1107
> > >  #2: 888041adca78 (&helper->lock){+.+.}-{3:3}, at: 
> > > drm_fb_helper_pan_display+0xce/0x970 drivers/gpu/drm/drm_fb_helper.c:1448
> > >  #3: 8880159f01b8 (&dev->master_mutex){+.+.}-{3:3}, at: 
> > > drm_master_internal_acquire+0x1d/0x70 drivers/gpu/drm/drm_auth.c:407
> > >  #4: 888041adc898 (&client->modeset_mutex){+.+.}-{3:3}, at: 
> > > drm_client_modeset_commit_locked+0x44/0x580 
> > > drivers/gpu/drm/drm_client_modeset.c:1143
> > >  #5: c90001c07730 (crtc_ww_class_acquire){+.+.}-{0:0}, at: 
> > > drm_client_modeset_commit_atomic+0xb7/0x7c0 
> > > drivers/gpu/drm/drm_client_modeset.c:981
> > >  #6: 888015986108 (crtc_ww_class_mutex){+.+.}-{3:3}, at: 
> > > ww_mutex_lock_slow include/linux/ww_mutex.h:287 [inline]
> > >  #6: 888015986108 (crtc_ww_class_mutex){+.+.}-{3:3}, at: 
> > > modeset_lock+0x31c/0x650 drivers/gpu/drm/drm_modeset_lock.c:260
> >
> > Given that we managed to take all these locks without upsetting anyone
> > the rcu section is very deep down. And looking at the backtrace below
> > I just couldn't find anything.
> >
> > Best I can think of is that an interrupt of some sort leaked an rcu
> > section, and we got shot here. But I'd assume the rcu debugging would
> > catch this? Backtrace of the start of that rcu read side section would
> > be really useful here, but I'm not seeing that in the logs. There's
> > more stuff there, but it's just the usual "everything falls apart"
> > stuff of little value to understanding how we got there.
>
> In my experience, lockdep will indeed complain if an interrupt handler
> returns while in an RCU read-side critical section.
>
> > Adding some rcu people for more insights on what could have gone wrong here.
> > -Daniel
> >
> > > stack backtrace:
> > > CPU: 1 PID: 9232 Comm: syz-executor.1 Not tainted 5.10.0-rc7-syzkaller #0
> > > Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 
> > > rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014
> > > Call Trace:
> > >  __dump_stack lib/dump_stack.c:77 [inline]
> > >  dump_stack+0x107/0x163 lib/dump_stack.c:118
> > >  ___might_sleep+0x25d/0x2b0 kernel/sched/core.c:7270
> > >  __mutex_lock_common kernel/locking/mutex.c:935 [inline]
> > >  __ww_mutex_lock.constprop.0+0xa9/0x2cc0 kernel/locking/mutex.c:
> > >  ww_mutex_lock+0x3d/0x170 kernel/locking/mutex.c:1190
>
> Acquiring a mutex while under the influence of rcu_read_lock() will
> definitely get you this lockdep complaint, and rightfully so.
>
> If you need to acquire a mutex with RCU-like protection, one approach
> is to use SRCU.  But usually this indicates (as you suspected) that
> someone forgot to invoke rcu_read_unlock().
>
> One way to locate this is to enlist the aid of lockdep.  You can do this
> by putting something like this in the callers:
>
> RCU_LOCKDEP_WARN(lock_is_held(&rcu_bh_lock_map) ||
>  lock_is_held(&rcu_lock_map) ||
>  lock_is_held(&rcu_sched_lock_map),
>  "We are in an RCU read-side critical section");
>
> This will get you a lockdep complaint much like the one above if the
> caller is in any sort of RCU read-side critical section.  You can push
> this up the call stack one level at a time or just sprinkle it u

Re: [PATCH RESEND v6 2/4] mfd: Support ROHM BD9576MUF and BD9573MUF

2020-12-17 Thread Vaittinen, Matti
Hi deee Ho Lee,

On Wed, 2020-12-02 at 15:32 +0200, Matti Vaittinen wrote:
> Hello Lee,
> 
> On Wed, 2020-12-02 at 12:57 +, Lee Jones wrote:
> > On Fri, 27 Nov 2020, Vaittinen, Matti wrote:
> > 
> > > Hello Lee,
> > > 
> > > On Fri, 2020-11-27 at 08:32 +, Lee Jones wrote:
> > > > On Mon, 23 Nov 2020, Matti Vaittinen wrote:
> > > > 
> > > > > Add core support for ROHM BD9576MUF and BD9573MUF PMICs which
> > > > > are
> > > > > mainly used to power the R-Car series processors.
> > > > > 
> > > > > Signed-off-by: Matti Vaittinen <
> > > > > matti.vaitti...@fi.rohmeurope.com>
> > > > > ---
> > > > >  drivers/mfd/Kconfig  |  11 
> > > > >  drivers/mfd/Makefile |   1 +
> > > > >  drivers/mfd/rohm-bd9576.c| 108
> > > > > +++
> > > > >  include/linux/mfd/rohm-bd957x.h  |  59 +
> > > > >  include/linux/mfd/rohm-generic.h |   2 +
> > > > >  5 files changed, 181 insertions(+)
> > > > >  create mode 100644 drivers/mfd/rohm-bd9576.c
> > > > >  create mode 100644 include/linux/mfd/rohm-bd957x.h
> > > > 
> > > > Looks like a possible candidate for "simple-mfd-i2c".
> > > > 
> > > > Could you look into that please?
> > > > 
> > > I must admit I didn't know about "simple-mfd-i2c". Good thing to
> > > know
> > > when working with simple devices :) Is this a new thing?
> > 
> > Yes, it's new.
> > 
> > > I am unsure I understand the idea fully. Should users put all the
> > > different regamp configs in this file and just add the device IDs
> > > with
> > > pointer to correct config? (BD9576 and BD9573 need volatile
> > > ranges).
> > > Also, does this mean each sub-device should have own node and own
> > > compatible in DT to get correctly load and probed? I guess this
> > > would
> > > need a buy-in from Rob too then.
> > 
> > You should describe the H/W in DT.
> 
> Yes. And it is described. But I've occasionally received request from
> DT guys to add some properties directly to MFD node and not to add
> own
> sub-node. This is what is done for example with the BD71837/47 clocks
> -
> there is no own node for clk - the clk properties are placed directly
> in MFD node (as was requested by Stephen and Rob back then - I
> originally had own node for clk). I really have no clear view on when
> things warrant for own subnode and when they don't - but as far as I
> can see using simple-mfd-i2c forces one to always have a sub-node /
> device. Even just a empty node with nothing but the compatible even
> if
> device does not need stuff from DT? Anyways, I think this is nice
> addition for simple drivers.
> 
> > > By the way - for uneducated eyes like mine this does not look
> > > like
> > > it
> > > has much to do with MFD as a device - here MFD reminds me of a
> > > simple-
> > > bus on top of I2C.
> > 
> > This is for MFD devices where the parent does little more than
> > create
> > a shared address space for child devices to operate on - like
> > yours.
> > 
> > > Anyways, the BD9576 and BD9573 both have a few interrupts for
> > > OVD/UVD
> > > conditions and I am expecting that I will be asked to provide the
> > > regulator notifiers for those. Reason why I omitted the IRQs for
> > > now is
> > > that the HW is designed to keep the IRQ asserted for whole error
> > > duration so some delayed ack mechanism would be needed. I would
> > > like to
> > > keep the door open for adding IRQs to MFD core.
> > 
> > You mean to add an IRQ Domain?
> 
> Yes. I planned to use regmap-irq and create irq chip in MFD when the
> over / under voltage / temperature - notifications or watchdog IRQs
> are
> needed. 

I am sorry if I have missed your reply. The ROHM email had redirected
almost all patch emails to spam + I am not sure if some mails are
dropping :(

(I am considering moving to gmail - but I'd rather keep all mails in
one system and I can't transfer work mail traffic to gmail... I wonder
how others are managing the mails - which mail system you are using?)

I think this series is now pending the decision how to proceed with MFD
part. If you still want me to start with "simple-mfd-i2c", then I would
appreciate if you pointed me how you would like to see the regmap
configs added. Although I am quite positive this (eventually) ends up
being more than what simple-mfd-i2c is intended for (because at some
point people want to add the use of the interrupts).

Best Regards
Matti Vaittinen


Re: linux-next: manual merge of the akpm-current tree with the risc-v tree

2020-12-17 Thread Stephen Rothwell
Hi Andy,

On Thu, 17 Dec 2020 11:40:51 +0200 Andy Shevchenko  
wrote:
>
> Yeah, and it's slightly different. Perhaps RISC-V tree can handle this
> by moving Makefile entry somewhere else in the file.

Or just let Linus take care of it ...

-- 
Cheers,
Stephen Rothwell


pgprUxnfVtQtO.pgp
Description: OpenPGP digital signature


Re: [PATCH v3 0/9] Xilinx AI engine kernel driver

2020-12-17 Thread Daniel Vetter
On Thu, Dec 17, 2020 at 9:40 AM Jiaying Liang  wrote:
>
>
> On 12/15/20 7:23 AM, Alex Deucher wrote:
> > On Mon, Dec 14, 2020 at 7:24 PM Jiaying Liang  
> > wrote:
> >> On 12/11/20 11:39 AM, Daniel Vetter wrote:
> >>> Hi all
> >>>
> >>> On Fri, Dec 11, 2020 at 8:03 PM Alex Deucher   
> >>> wrote:
>  On Mon, Nov 30, 2020 at 3:25 AM Wendy Liang   
>  wrote:
> > AI engine is the acceleration engine provided by Xilinx. These engines
> > provide high compute density for vector-based algorithms, and flexible
> > custom compute and data movement. It has core tiles for compute and
> > shim tiles to interface the FPGA fabric.
> >
> > You can check the AI engine architecture document for more hardware 
> > details:
> > https://www.xilinx.com/support/documentation/architecture-manuals/am009-versal-ai-engine.pdf
> >
> > This patch series adds a Linux kernel driver to manage the Xilinx AI
> > engine array device and AI engine partitions (groups of AI engine tiles
> > dedicated to an application).
>  Hi Wendy,
> 
>  I think it would be good to provide an overview of how your stack
>  works in general.  That would give reviewers a better handle on how
>  all of this fits together.  I'd suggest including an overview in the
>  cover letter and also in the commit message and/or as a comment in the
>  code in one of the patches.  I'm not really an expert when it comes to
>  FPGAs, but this basically looks like a pretty low level interface to
>  set up the data fabric for a kernel that will run on the soft logic or
>  maybe the microcontroller on the board.  It doesn't have to be super
>  detailed, just a nice flow for how you might use this.  E.g.,
> 
>  Userspace uses ioctls X, Y, Z to configure the data fabric for the
>  FPGA kernel.  The kernels can run on... .  DMA access to system memory
>  for data sets can be allocated using ioctl A.  DMA access is limited
>  by... . The user can then load the FPGA kernel on to one of the
>  engines using ioctl B and finally they can kick off the whole thing
>  using ioctl C.  FPGA kernels are compiled using YYY toolchain and use
>  use the following runtime (link to runtime) to configure the data
>  fabric using ioctls X, Y, Z.
> >>> At least for drm drivers we ideally have that as a .rst file in
> >>> Documentation/. With that you can even do full svg graphs, or just dot
> >>> graphs, of the overall stack if you really want to go overboard :-)
> >>>
>  It would also be good to go over the security implications of the
>  design.  E.g., can the FPGA kernel(s) access the DMA engine directly,
>  or is it limited to just the DMA regions set up by the ioctls?  Also,
>  does the hardware and software design allow for multiple users?  If
>  so, how does that work?
> >>> I've also seen indications that there's some on-chip or on-card
> >>> memory. How that's planned to be used and whether we want to manage
> >>> this (maybe even with something like ttm) would be good to understand.
> >>>
> >>> All excellent questions from Alex, just figured I add some more.
> >>>
> >>> Cheers, Daniel
> >> Hi Alex, Daniel,
> >>
> >> Below is an overview of the driver.
> >>
> >> AI engine kernel driver manages Xilinx AI engine device. An AI engine 
> >> device
> >> contains cores tiles and SHIM tiles. Core tiles are the computation tiles
> >> , the SHIM tiles are the tiles interfacing to external components.
> >>
> >> +++++
> >>  | Core| Core| Core| Core | ...
> >>  ||| ||
> >> +---+
> >>  | Core| Core| Core| Core | ...
> >>  ||| | |
> >> ++++-
> >>  ...
> >> +++-+
> >> | SHIM| SHIM   | SHIM   |SHIM|
> >> | PL| PL   | PL|PL | NOC  |
> >> +---++---++---+-+---+
> >> AXI Streams   |||  ||AXI MM
> >>  ||| ||
> >> Events Singals |||  ||
> >>  ||| ||
> >>  ||| ||
> >> +---+++-+ +--+--+
> >> |   FPGA| |
> >> NOC|
> >> | | |  |
> >> +---+ +--+---+
> >>  |
> >>  |
> >> 

Re: [PATCH v2] mm/mmap: Don't unlock VMAs in remap_file_pages()

2020-12-17 Thread David Hildenbrand
On 16.12.20 21:42, Liam R. Howlett wrote:
> 
> Thank you for looking at this.  I appreciate the scrutiny.
> 
> * David Hildenbrand  [201216 09:58]:
>> On 15.12.20 16:54, Liam R. Howlett wrote:
>>> do_mmap() will unlock the necessary VMAs.  There is also a bug in the
>>> loop which will evaluate as false and not unlock any VMAs anyways.
>>
>> If there is a BUG, do we have a Fixes: tag? Also
> 
> The bug would never show up as it is masked by do_mmap() unlocking the
> necessary range.  Although there is a bug in this code, the code does
> not cause an issue as it won't execute so should I have a Fixes tag?
> The code works and what I've done is remove a chunk of code that never
> runs.
> 

Ok I see. The use of "bug" here is misleading. The unnecessary code is
simply not doing what it promised to do without doing any harm.

>>
>> 1. Can we fix the bug separately first?
> 
> I think it is safer to remove unexecuted code than enable it and then
> remove it.

I agree, as it is not actually a bug.

> 
>> 2. Can we have a better description on what the bug actually is
>> "evaluate as false"? What is the result of the bug?
> 
> The bug is in the for loop test expression that I removed in the patch.
> Here is the long explaination of why the loop has never run.
> 
> 
> Line 2982: if (start + size <= start
> Line 2983:goto out;
> 
> size is positive.
> 
> Line 2992: vma = find_vma(mm, start);
> Look up the first VMA which satisfies start < vm_end
> 
> Line 2997: if (start < vma->vm_start)
> Line 2998:goto out;
> 
> So now vma->vm_start >= start.
> If vma->vm_start > start, then there are no VMAs in that area, otherwise
> it would have been returned by find_vma().
> So we can say that vma->vm_start == start.
> 
> Line 3033: for (tmp = vma; tmp->vm_start >= start + size;
> Line 3034: tmp = tmp->vm_next) {
> This is the for loop with the error in the test expression.
> 
> tmp->vm_start == start which cannot be >= (start + size).
> 
> I believe the intention was to loop through vmas in the range of start
> to (start + size) and unlock them.
> 
> 
> The result of the bug is no VMA is unlocked in this fuction.  But that
> doesn't matter as they are unlocked later in the call chain - which is
> why this code works as intended.
> 

Thanks for clarifying!

> 
>>
>> CCing some people that might know if this is actually a sane change.
>> Skimming over do_mmap(), it's not immediately clear to me that
>> "do_mmap() will unlock the necessary VMAs".
> 
> Ah, yes.  That is understandable.
> 
> do_mmap() L1583 -> mmap_region() L1752 -> munmap_vma_range() ->
> do_munmap() -> __do_munmap() loop at 2891 to unlock the range.
> 
> Would you like me to add this call chain to the changelog?

Yes please, in a simplified form.

I suggest something like the following patch description:

"do_mmap(MAP_FIXED) will already unlock pages via munmap_vma_range(). We
can remove the superfluous manual unlocking in remap_file_pages().

Note that the manual unlocking is even incorrect, as it might miss
unlocking some pages - no harm done.
"

-- 
Thanks,

David / dhildenb



[PATCH 00/14] Add some DRM bridge drivers support for i.MX8qm/qxp SoCs

2020-12-17 Thread Liu Ying
Hi,

This series adds some DRM bridge drivers support for i.MX8qm/qxp SoCs.

The bridges may chain one by one to form display pipes to support
LVDS displays.  The relevant display controller is DPU embedded in
i.MX8qm/qxp SoCs.

The DPU KMS driver can be found at:
https://www.spinics.net/lists/arm-kernel/msg862106.html

This series supports the following display pipes:
1) i.MX8qxp:
prefetch eng -> DPU -> pixel combiner -> pixel link ->
pixel link to DPI(PXL2DPI) -> LVDS display bridge(LDB)

2) i.MX8qm:
prefetch eng -> DPU -> pixel combiner -> pixel link -> LVDS display bridge(LDB)


Patch 1/14 adds LVDS PHY configuration options, which has already been sent
with the following series to add Mixel combo PHY found in i.MX8qxp:
https://www.spinics.net/lists/arm-kernel/msg862560.html

Patch 2/14 and 3/14 add bus formats used by PXL2DPI.

Patch 4/14 ~ 13/14 add drm bridge drivers and dt-bindings support for the 
bridges.

Patch 14/14 updates MAINTAINERS.


I've tested this series with a koe,tx26d202vm0bwa dual link LVDS panel and
a LVDS to HDMI bridge(with a downstream drm bridge driver).


Welcome comments, thanks.

Liu Ying (14):
  phy: Add LVDS configuration options
  media: uapi: Add some RGB bus formats for i.MX8qm/qxp pixel combiner
  media: docs: Add some RGB bus formats for i.MX8qm/qxp pixel combiner
  dt-bindings: display: bridge: Add i.MX8qm/qxp pixel combiner binding
  drm/bridge: imx: Add i.MX8qm/qxp pixel combiner support
  dt-bindings: display: bridge: Add i.MX8qm/qxp display pixel link
binding
  drm/bridge: imx: Add i.MX8qm/qxp display pixel link support
  dt-bindings: display: bridge: Add i.MX8qxp pixel link to DPI binding
  drm/bridge: imx: Add i.MX8qxp pixel link to DPI support
  drm/bridge: imx: Add LDB driver helper support
  dt-bindings: display: bridge: Add i.MX8qm/qxp LVDS display bridge
binding
  drm/bridge: imx: Add LDB support for i.MX8qxp
  drm/bridge: imx: Add LDB support for i.MX8qm
  MAINTAINERS: add maintainer for DRM bridge drivers for i.MX SoCs

 .../bindings/display/bridge/fsl,imx8qxp-ldb.yaml   | 185 +
 .../display/bridge/fsl,imx8qxp-pixel-combiner.yaml | 160 +
 .../display/bridge/fsl,imx8qxp-pixel-link.yaml | 128 
 .../display/bridge/fsl,imx8qxp-pxl2dpi.yaml| 134 
 .../userspace-api/media/v4l/subdev-formats.rst | 156 +
 MAINTAINERS|  10 +
 drivers/gpu/drm/bridge/Kconfig |   2 +
 drivers/gpu/drm/bridge/Makefile|   1 +
 drivers/gpu/drm/bridge/imx/Kconfig |  52 ++
 drivers/gpu/drm/bridge/imx/Makefile|   6 +
 drivers/gpu/drm/bridge/imx/imx-ldb-helper.c| 248 +++
 drivers/gpu/drm/bridge/imx/imx8qm-ldb.c| 589 
 drivers/gpu/drm/bridge/imx/imx8qxp-ldb.c   | 762 +
 .../gpu/drm/bridge/imx/imx8qxp-pixel-combiner.c| 452 
 drivers/gpu/drm/bridge/imx/imx8qxp-pixel-link.c| 411 +++
 drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c   | 494 +
 include/drm/bridge/imx_ldb_helper.h|  98 +++
 include/linux/phy/phy-lvds.h   |  48 ++
 include/linux/phy/phy.h|   4 +
 include/uapi/linux/media-bus-format.h  |   6 +-
 20 files changed, 3945 insertions(+), 1 deletion(-)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-ldb.yaml
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pixel-combiner.yaml
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pixel-link.yaml
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pxl2dpi.yaml
 create mode 100644 drivers/gpu/drm/bridge/imx/Kconfig
 create mode 100644 drivers/gpu/drm/bridge/imx/Makefile
 create mode 100644 drivers/gpu/drm/bridge/imx/imx-ldb-helper.c
 create mode 100644 drivers/gpu/drm/bridge/imx/imx8qm-ldb.c
 create mode 100644 drivers/gpu/drm/bridge/imx/imx8qxp-ldb.c
 create mode 100644 drivers/gpu/drm/bridge/imx/imx8qxp-pixel-combiner.c
 create mode 100644 drivers/gpu/drm/bridge/imx/imx8qxp-pixel-link.c
 create mode 100644 drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c
 create mode 100644 include/drm/bridge/imx_ldb_helper.h
 create mode 100644 include/linux/phy/phy-lvds.h

-- 
2.7.4



[PATCH 02/14] media: uapi: Add some RGB bus formats for i.MX8qm/qxp pixel combiner

2020-12-17 Thread Liu Ying
This patch adds RGB666_1X30_CPADLO, RGB888_1X30_CPADLO, RGB666_1X36_CPADLO
and RGB888_1X36_CPADLO bus formats used by i.MX8qm/qxp pixel combiner.
The RGB pixels with padding low per component are transmitted on a 30-bit
input bus(10-bit per component) from a display controller or a 36-bit
output bus(12-bit per component) to a pixel link.

Signed-off-by: Liu Ying 
---
 include/uapi/linux/media-bus-format.h | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/include/uapi/linux/media-bus-format.h 
b/include/uapi/linux/media-bus-format.h
index 5d905ad..b218282 100644
--- a/include/uapi/linux/media-bus-format.h
+++ b/include/uapi/linux/media-bus-format.h
@@ -34,7 +34,7 @@
 
 #define MEDIA_BUS_FMT_FIXED0x0001
 
-/* RGB - next is   0x101e */
+/* RGB - next is   0x1022 */
 #define MEDIA_BUS_FMT_RGB444_1X12  0x1016
 #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_BE  0x1001
 #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_LE  0x1002
@@ -59,9 +59,13 @@
 #define MEDIA_BUS_FMT_RGB888_3X8_DELTA 0x101d
 #define MEDIA_BUS_FMT_RGB888_1X7X4_SPWG0x1011
 #define MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA   0x1012
+#define MEDIA_BUS_FMT_RGB666_1X30_CPADLO   0x101e
+#define MEDIA_BUS_FMT_RGB888_1X30_CPADLO   0x101f
 #define MEDIA_BUS_FMT_ARGB_1X320x100d
 #define MEDIA_BUS_FMT_RGB888_1X32_PADHI0x100f
 #define MEDIA_BUS_FMT_RGB101010_1X30   0x1018
+#define MEDIA_BUS_FMT_RGB666_1X36_CPADLO   0x1020
+#define MEDIA_BUS_FMT_RGB888_1X36_CPADLO   0x1021
 #define MEDIA_BUS_FMT_RGB121212_1X36   0x1019
 #define MEDIA_BUS_FMT_RGB161616_1X48   0x101a
 
-- 
2.7.4



[PATCH 01/14] phy: Add LVDS configuration options

2020-12-17 Thread Liu Ying
This patch allows LVDS PHYs to be configured through
the generic functions and through a custom structure
added to the generic union.

The parameters added here are based on common LVDS PHY
implementation practices.  The set of parameters
should cover all potential users.

Cc: Kishon Vijay Abraham I 
Cc: Vinod Koul 
Cc: NXP Linux Team 
Signed-off-by: Liu Ying 
---
 include/linux/phy/phy-lvds.h | 48 
 include/linux/phy/phy.h  |  4 
 2 files changed, 52 insertions(+)
 create mode 100644 include/linux/phy/phy-lvds.h

diff --git a/include/linux/phy/phy-lvds.h b/include/linux/phy/phy-lvds.h
new file mode 100644
index ..1b5b9d6
--- /dev/null
+++ b/include/linux/phy/phy-lvds.h
@@ -0,0 +1,48 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright 2020 NXP
+ */
+
+#ifndef __PHY_LVDS_H_
+#define __PHY_LVDS_H_
+
+/**
+ * struct phy_configure_opts_lvds - LVDS configuration set
+ *
+ * This structure is used to represent the configuration state of a
+ * LVDS phy.
+ */
+struct phy_configure_opts_lvds {
+   /**
+* @bits_per_lane_and_dclk_cycle:
+*
+* Number of bits per data lane and differential clock cycle.
+*/
+   unsigned int bits_per_lane_and_dclk_cycle;
+
+   /**
+* @differential_clk_rate:
+*
+* Clock rate, in Hertz, of the LVDS differential clock.
+*/
+   unsigned long differential_clk_rate;
+
+   /**
+* @lanes:
+*
+* Number of active, consecutive, data lanes, starting from
+* lane 0, used for the transmissions.
+*/
+   unsigned int lanes;
+
+   /**
+* @is_slave:
+*
+* Boolean, true if the phy is a slave which works together
+* with a master phy to support dual link transmission,
+* otherwise a regular phy or a master phy.
+*/
+   bool is_slave;
+};
+
+#endif /* __PHY_LVDS_H_ */
diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
index e435bdb..d450b44 100644
--- a/include/linux/phy/phy.h
+++ b/include/linux/phy/phy.h
@@ -17,6 +17,7 @@
 #include 
 
 #include 
+#include 
 #include 
 
 struct phy;
@@ -51,10 +52,13 @@ enum phy_mode {
  * the MIPI_DPHY phy mode.
  * @dp:Configuration set applicable for phys supporting
  * the DisplayPort protocol.
+ * @lvds:  Configuration set applicable for phys supporting
+ * the LVDS phy mode.
  */
 union phy_configure_opts {
struct phy_configure_opts_mipi_dphy mipi_dphy;
struct phy_configure_opts_dpdp;
+   struct phy_configure_opts_lvds  lvds;
 };
 
 /**
-- 
2.7.4



[PATCH 04/14] dt-bindings: display: bridge: Add i.MX8qm/qxp pixel combiner binding

2020-12-17 Thread Liu Ying
This patch adds bindings for i.MX8qm/qxp pixel combiner.

Signed-off-by: Liu Ying 
---
 .../display/bridge/fsl,imx8qxp-pixel-combiner.yaml | 160 +
 1 file changed, 160 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pixel-combiner.yaml

diff --git 
a/Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pixel-combiner.yaml
 
b/Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pixel-combiner.yaml
new file mode 100644
index ..bacacd8
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pixel-combiner.yaml
@@ -0,0 +1,160 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: 
http://devicetree.org/schemas/display/bridge/fsl,imx8qxp-pixel-combiner.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX8qm/qxp Pixel Combiner
+
+maintainers:
+  - Liu Ying 
+
+description: |
+  The Freescale i.MX8qm/qxp Pixel Combiner takes two output streams from a
+  single display controller and manipulates the two streams to support a number
+  of modes(bypass, pixel combine, YUV444 to YUV422, split_RGB) configured as
+  either one screen, two screens, or virtual screens.  The pixel combiner is
+  also responsible for generating some of the control signals for the pixel 
link
+  output channel.
+
+properties:
+  compatible:
+enum:
+  - fsl,imx8qm-pixel-combiner
+  - fsl,imx8qxp-pixel-combiner
+
+  "#address-cells":
+const: 1
+
+  "#size-cells":
+const: 0
+
+  reg:
+maxItems: 1
+
+  clocks:
+maxItems: 1
+
+  clock-names:
+const: apb
+
+  power-domains:
+maxItems: 1
+
+patternProperties:
+  "^channel@[0-1]$":
+type: object
+description: Represents a display stream of pixel combiner.
+
+properties:
+  "#address-cells":
+const: 1
+
+  "#size-cells":
+const: 0
+
+  reg:
+description: The display stream index.
+oneOf:
+  - const: 0
+  - const: 1
+
+  port@0:
+type: object
+description: Input endpoint of the display stream.
+
+properties:
+  reg:
+const: 0
+
+required:
+  - reg
+
+  port@1:
+type: object
+description: Output endpoint of the display stream.
+
+properties:
+  reg:
+const: 1
+
+required:
+  - reg
+
+required:
+  - "#address-cells"
+  - "#size-cells"
+  - reg
+  - port@0
+  - port@1
+
+additionalProperties: false
+
+required:
+  - compatible
+  - "#address-cells"
+  - "#size-cells"
+  - reg
+  - clocks
+  - clock-names
+  - power-domains
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+#include 
+pixel-combiner@5602 {
+compatible = "fsl,imx8qxp-pixel-combiner";
+#address-cells = <1>;
+#size-cells = <0>;
+reg = <0x5602 0x1>;
+clocks = <&dc0_pixel_combiner_lpcg IMX_LPCG_CLK_4>;
+clock-names = "apb";
+power-domains = <&pd IMX_SC_R_DC_0>;
+
+channel@0 {
+#address-cells = <1>;
+#size-cells = <0>;
+reg = <0>;
+
+port@0 {
+reg = <0>;
+
+dc0_pixel_combiner_ch0_dc0_dpu_disp0: endpoint {
+remote-endpoint = <&dc0_dpu_disp0_dc0_pixel_combiner_ch0>;
+};
+};
+
+port@1 {
+reg = <1>;
+
+dc0_pixel_combiner_ch0_dc0_pixel_link0: endpoint {
+remote-endpoint = 
<&dc0_pixel_link0_dc0_pixel_combiner_ch0>;
+};
+};
+};
+
+channel@1 {
+#address-cells = <1>;
+#size-cells = <0>;
+reg = <1>;
+
+port@0 {
+reg = <0>;
+
+dc0_pixel_combiner_ch1_dc0_dpu_disp1: endpoint {
+remote-endpoint = <&dc0_dpu_disp1_dc0_pixel_combiner_ch1>;
+};
+};
+
+port@1 {
+reg = <1>;
+
+dc0_pixel_combiner_ch1_dc0_pixel_link1: endpoint {
+remote-endpoint = 
<&dc0_pixel_link1_dc0_pixel_combiner_ch1>;
+};
+};
+};
+};
-- 
2.7.4



[PATCH 05/14] drm/bridge: imx: Add i.MX8qm/qxp pixel combiner support

2020-12-17 Thread Liu Ying
This patch adds a drm bridge driver for i.MX8qm/qxp pixel combiner.
The pixel combiner takes two output streams from a single display
controller and manipulates the two streams to support a number
of modes(bypass, pixel combine, YUV444 to YUV422, split_RGB) configured
as either one screen, two screens, or virtual screens.  The pixel
combiner is also responsible for generating some of the control signals
for the pixel link output channel.  For now, the driver only supports
the bypass mode.

Signed-off-by: Liu Ying 
---
 drivers/gpu/drm/bridge/Kconfig |   2 +
 drivers/gpu/drm/bridge/Makefile|   1 +
 drivers/gpu/drm/bridge/imx/Kconfig |   8 +
 drivers/gpu/drm/bridge/imx/Makefile|   1 +
 .../gpu/drm/bridge/imx/imx8qxp-pixel-combiner.c| 452 +
 5 files changed, 464 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/imx/Kconfig
 create mode 100644 drivers/gpu/drm/bridge/imx/Makefile
 create mode 100644 drivers/gpu/drm/bridge/imx/imx8qxp-pixel-combiner.c

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index e4110d6c..84944e0 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -256,6 +256,8 @@ source "drivers/gpu/drm/bridge/adv7511/Kconfig"
 
 source "drivers/gpu/drm/bridge/cadence/Kconfig"
 
+source "drivers/gpu/drm/bridge/imx/Kconfig"
+
 source "drivers/gpu/drm/bridge/synopsys/Kconfig"
 
 endmenu
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 86e7acc..bc80cae 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -27,4 +27,5 @@ obj-$(CONFIG_DRM_NWL_MIPI_DSI) += nwl-dsi.o
 
 obj-y += analogix/
 obj-y += cadence/
+obj-y += imx/
 obj-y += synopsys/
diff --git a/drivers/gpu/drm/bridge/imx/Kconfig 
b/drivers/gpu/drm/bridge/imx/Kconfig
new file mode 100644
index ..f1c91b6
--- /dev/null
+++ b/drivers/gpu/drm/bridge/imx/Kconfig
@@ -0,0 +1,8 @@
+config DRM_IMX8QXP_PIXEL_COMBINER
+   tristate "Freescale i.MX8QM/QXP pixel combiner"
+   depends on OF
+   depends on COMMON_CLK
+   select DRM_KMS_HELPER
+   help
+ Choose this to enable pixel combiner found in
+ Freescale i.MX8qm/qxp processors.
diff --git a/drivers/gpu/drm/bridge/imx/Makefile 
b/drivers/gpu/drm/bridge/imx/Makefile
new file mode 100644
index ..7d7c8d6
--- /dev/null
+++ b/drivers/gpu/drm/bridge/imx/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_DRM_IMX8QXP_PIXEL_COMBINER) += imx8qxp-pixel-combiner.o
diff --git a/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-combiner.c 
b/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-combiner.c
new file mode 100644
index ..cd5b1be
--- /dev/null
+++ b/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-combiner.c
@@ -0,0 +1,452 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+/*
+ * Copyright 2020 NXP
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#define PC_CTRL_REG0x0
+#define  PC_COMBINE_ENABLE BIT(0)
+#define  PC_DISP_BYPASS(n) BIT(1 + 21 * (n))
+#define  PC_DISP_HSYNC_POLARITY(n) BIT(2 + 11 * (n))
+#define  PC_DISP_HSYNC_POLARITY_POS(n) DISP_HSYNC_POLARITY(n)
+#define  PC_DISP_VSYNC_POLARITY(n) BIT(3 + 11 * (n))
+#define  PC_DISP_VSYNC_POLARITY_POS(n) DISP_VSYNC_POLARITY(n)
+#define  PC_DISP_DVALID_POLARITY(n)BIT(4 + 11 * (n))
+#define  PC_DISP_DVALID_POLARITY_POS(n)DISP_DVALID_POLARITY(n)
+#define  PC_VSYNC_MASK_ENABLE  BIT(5)
+#define  PC_SKIP_MODE  BIT(6)
+#define  PC_SKIP_NUMBER_MASK   GENMASK(12, 7)
+#define  PC_SKIP_NUMBER(n) FIELD_PREP(PC_SKIP_NUMBER_MASK, (n))
+#define  PC_DISP0_PIX_DATA_FORMAT_MASK GENMASK(18, 16)
+#define  PC_DISP0_PIX_DATA_FORMAT(fmt) \
+   FIELD_PREP(PC_DISP0_PIX_DATA_FORMAT_MASK, (fmt))
+#define  PC_DISP1_PIX_DATA_FORMAT_MASK GENMASK(21, 19)
+#define  PC_DISP1_PIX_DATA_FORMAT(fmt) \
+   FIELD_PREP(PC_DISP1_PIX_DATA_FORMAT_MASK, (fmt))
+
+#define PC_BUF_PARA_REG0x10
+#define  PC_BUF_ACTIVE_DEPTH_MASK  GENMASK(10, 0)
+#define  PC_BUF_ACTIVE_DEPTH(n)
FIELD_PREP(PC_BUF_ACTIVE_DEPTH_MASK, (n))
+
+#define PC_SW_RESET_REG0x20
+#define  PC_SW_RESET_N BIT(0)
+#define  PC_DISP_SW_RESET_N(n) BIT(1 + (n))
+#define  PC_FULL_RESET_N   (PC_SW_RESET_N |\
+PC_DISP_SW_RESET_N(0) |\
+PC_DISP_SW_RESET_N(1))
+
+#define PC_REG_SET 0x4
+#define PC_REG_CLR 0x8
+
+#define DRIVER_NAME"imx8qxp-pixel-combiner"
+
+enum imx8qxp_pc_pix_data_format {
+   RGB,
+   YUV444,
+   YUV422,
+   SPLIT_RGB,
+};
+
+struct imx8qxp_pc_channel {
+   struct drm_b

[PATCH 03/14] media: docs: Add some RGB bus formats for i.MX8qm/qxp pixel combiner

2020-12-17 Thread Liu Ying
This patch adds documentations for RGB666_1X30_CPADLO, RGB888_1X30_CPADLO,
RGB666_1X36_CPADLO and RGB888_1X36_CPADLO bus formats used by i.MX8qm/qxp
pixel combiner.  The RGB pixels with padding low per component are
transmitted on a 30-bit input bus(10-bit per component) from a display
controller or a 36-bit output bus(12-bit per component) to a pixel link.

Signed-off-by: Liu Ying 
---
 .../userspace-api/media/v4l/subdev-formats.rst | 156 +
 1 file changed, 156 insertions(+)

diff --git a/Documentation/userspace-api/media/v4l/subdev-formats.rst 
b/Documentation/userspace-api/media/v4l/subdev-formats.rst
index c9b7bb3..e02b92b 100644
--- a/Documentation/userspace-api/media/v4l/subdev-formats.rst
+++ b/Documentation/userspace-api/media/v4l/subdev-formats.rst
@@ -1488,6 +1488,80 @@ The following tables list existing packed RGB formats.
   - b\ :sub:`2`
   - b\ :sub:`1`
   - b\ :sub:`0`
+* .. _MEDIA-BUS-FMT-RGB666-1X30-CPADLO:
+
+  - MEDIA_BUS_FMT_RGB666_1X30-CPADLO
+  - 0x101e
+  -
+  - 0
+  - 0
+  - r\ :sub:`5`
+  - r\ :sub:`4`
+  - r\ :sub:`3`
+  - r\ :sub:`2`
+  - r\ :sub:`1`
+  - r\ :sub:`0`
+  - 0
+  - 0
+  - 0
+  - 0
+  - g\ :sub:`5`
+  - g\ :sub:`4`
+  - g\ :sub:`3`
+  - g\ :sub:`2`
+  - g\ :sub:`1`
+  - g\ :sub:`0`
+  - 0
+  - 0
+  - 0
+  - 0
+  - b\ :sub:`5`
+  - b\ :sub:`4`
+  - b\ :sub:`3`
+  - b\ :sub:`2`
+  - b\ :sub:`1`
+  - b\ :sub:`0`
+  - 0
+  - 0
+  - 0
+  - 0
+* .. _MEDIA-BUS-FMT-RGB888-1X30-CPADLO:
+
+  - MEDIA_BUS_FMT_RGB888_1X30-CPADLO
+  - 0x101f
+  -
+  - 0
+  - 0
+  - r\ :sub:`7`
+  - r\ :sub:`6`
+  - r\ :sub:`5`
+  - r\ :sub:`4`
+  - r\ :sub:`3`
+  - r\ :sub:`2`
+  - r\ :sub:`1`
+  - r\ :sub:`0`
+  - 0
+  - 0
+  - g\ :sub:`7`
+  - g\ :sub:`6`
+  - g\ :sub:`5`
+  - g\ :sub:`4`
+  - g\ :sub:`3`
+  - g\ :sub:`2`
+  - g\ :sub:`1`
+  - g\ :sub:`0`
+  - 0
+  - 0
+  - b\ :sub:`7`
+  - b\ :sub:`6`
+  - b\ :sub:`5`
+  - b\ :sub:`4`
+  - b\ :sub:`3`
+  - b\ :sub:`2`
+  - b\ :sub:`1`
+  - b\ :sub:`0`
+  - 0
+  - 0
 * .. _MEDIA-BUS-FMT-ARGB888-1X32:
 
   - MEDIA_BUS_FMT_ARGB888_1X32
@@ -1665,6 +1739,88 @@ The following table list existing packed 36bit wide RGB 
formats.
   - 2
   - 1
   - 0
+* .. _MEDIA-BUS-FMT-RGB666-1X36-CPADLO:
+
+  - MEDIA_BUS_FMT_RGB666_1X36_CPADLO
+  - 0x1020
+  -
+  - r\ :sub:`5`
+  - r\ :sub:`4`
+  - r\ :sub:`3`
+  - r\ :sub:`2`
+  - r\ :sub:`1`
+  - r\ :sub:`0`
+  - 0
+  - 0
+  - 0
+  - 0
+  - 0
+  - 0
+  - g\ :sub:`5`
+  - g\ :sub:`4`
+  - g\ :sub:`3`
+  - g\ :sub:`2`
+  - g\ :sub:`1`
+  - g\ :sub:`0`
+  - 0
+  - 0
+  - 0
+  - 0
+  - 0
+  - 0
+  - b\ :sub:`5`
+  - b\ :sub:`4`
+  - b\ :sub:`3`
+  - b\ :sub:`2`
+  - b\ :sub:`1`
+  - b\ :sub:`0`
+  - 0
+  - 0
+  - 0
+  - 0
+  - 0
+  - 0
+* .. _MEDIA-BUS-FMT-RGB888-1X36-CPADLO:
+
+  - MEDIA_BUS_FMT_RGB888_1X36_CPADLO
+  - 0x1021
+  -
+  - r\ :sub:`7`
+  - r\ :sub:`6`
+  - r\ :sub:`5`
+  - r\ :sub:`4`
+  - r\ :sub:`3`
+  - r\ :sub:`2`
+  - r\ :sub:`1`
+  - r\ :sub:`0`
+  - 0
+  - 0
+  - 0
+  - 0
+  - g\ :sub:`7`
+  - g\ :sub:`6`
+  - g\ :sub:`5`
+  - g\ :sub:`4`
+  - g\ :sub:`3`
+  - g\ :sub:`2`
+  - g\ :sub:`1`
+  - g\ :sub:`0`
+  - 0
+  - 0
+  - 0
+  - 0
+  - b\ :sub:`7`
+  - b\ :sub:`6`
+  - b\ :sub:`5`
+  - b\ :sub:`4`
+  - b\ :sub:`3`
+  - b\ :sub:`2`
+  - b\ :sub:`1`
+  - b\ :sub:`0`
+  - 0
+  - 0
+  - 0
+  - 0
 * .. _MEDIA-BUS-FMT-RGB121212-1X36:
 
   - MEDIA_BUS_FMT_RGB121212_1X36
-- 
2.7.4



[PATCH 08/14] dt-bindings: display: bridge: Add i.MX8qxp pixel link to DPI binding

2020-12-17 Thread Liu Ying
This patch adds bindings for i.MX8qxp pixel link to DPI(PXL2DPI).

Signed-off-by: Liu Ying 
---
 .../display/bridge/fsl,imx8qxp-pxl2dpi.yaml| 134 +
 1 file changed, 134 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pxl2dpi.yaml

diff --git 
a/Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pxl2dpi.yaml 
b/Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pxl2dpi.yaml
new file mode 100644
index ..1649622
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pxl2dpi.yaml
@@ -0,0 +1,134 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/fsl,imx8qxp-pxl2dpi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX8qxp Pixel Link to Display Pixel Interface
+
+maintainers:
+  - Liu Ying 
+
+description: |
+  The Freescale i.MX8qxp Pixel Link to Display Pixel Interface(PXL2DPI)
+  interfaces the pixel link 36-bit data output and the DSI controller’s
+  MIPI-DPI 24-bit data input, and inputs of LVDS Display Bridge(LDB) module
+  used in LVDS mode, to remap the pixel color codings between those modules.
+  This module is purely combinatorial.
+
+properties:
+  compatible:
+const: fsl,imx8qxp-pxl2dpi
+
+  power-domains:
+maxItems: 1
+
+  fsl,syscon:
+$ref: /schemas/types.yaml#/definitions/phandle
+description: |
+  A phandle which points to Control and Status Registers(CSR) module.
+
+  fsl,companion-pxl2dpi:
+$ref: /schemas/types.yaml#/definitions/phandle
+description: |
+  A phandle which points to companion PXL2DPI which is used by downstream
+  LVDS Display Bridge(LDB) in split mode.
+
+  ports:
+type: object
+description: |
+  A node containing PXL2DPI input & output port nodes with endpoint
+  definitions as documented in
+  Documentation/devicetree/bindings/media/video-interfaces.txt
+  Documentation/devicetree/bindings/graph.txt
+
+properties:
+  '#address-cells':
+const: 1
+
+  '#size-cells':
+const: 0
+
+  port@0:
+type: object
+description: The PXL2DPI input port node from pixel link.
+
+properties:
+  reg:
+const: 0
+
+required:
+  - reg
+
+  port@1:
+type: object
+description: The PXL2DPI output port node to downstream bridge.
+
+properties:
+  reg:
+const: 1
+
+required:
+  - reg
+
+required:
+  - "#address-cells"
+  - "#size-cells"
+  - port@0
+  - port@1
+
+additionalProperties: false
+
+required:
+  - compatible
+  - power-domains
+  - fsl,syscon
+  - ports
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+pxl2dpi {
+compatible = "fsl,imx8qxp-pxl2dpi";
+power-domains = <&pd IMX_SC_R_MIPI_0>;
+fsl,syscon = <&mipi_lvds_0_csr>;
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@0 {
+#address-cells = <1>;
+#size-cells = <0>;
+reg = <0>;
+
+mipi_lvds_0_pxl2dpi_dc_pixel_link0: endpoint@0 {
+reg = <0>;
+remote-endpoint = <&dc_pixel_link0_mipi_lvds_0_pxl2dpi>;
+};
+
+mipi_lvds_0_pxl2dpi_dc_pixel_link1: endpoint@1 {
+ reg = <1>;
+ remote-endpoint = <&dc_pixel_link1_mipi_lvds_0_pxl2dpi>;
+};
+};
+
+port@1 {
+#address-cells = <1>;
+#size-cells = <0>;
+reg = <1>;
+
+mipi_lvds_0_pxl2dpi_mipi_lvds_0_ldb_ch0: endpoint@0 {
+reg = <0>;
+remote-endpoint = 
<&mipi_lvds_0_ldb_ch0_mipi_lvds_0_pxl2dpi>;
+};
+
+mipi_lvds_0_pxl2dpi_mipi_lvds_0_ldb_ch1: endpoint@1 {
+reg = <1>;
+remote-endpoint = 
<&mipi_lvds_0_ldb_ch1_mipi_lvds_0_pxl2dpi>;
+};
+};
+};
+};
-- 
2.7.4



[PATCH 09/14] drm/bridge: imx: Add i.MX8qxp pixel link to DPI support

2020-12-17 Thread Liu Ying
This patch adds a drm bridge driver for i.MX8qxp pixel link to display
pixel interface(PXL2DPI).  The PXL2DPI interfaces the pixel link 36-bit
data output and the DSI controller’s MIPI-DPI 24-bit data input, and
inputs of LVDS Display Bridge(LDB) module used in LVDS mode, to remap
the pixel color codings between those modules. The PXL2DPI is purely
combinatorial.

Signed-off-by: Liu Ying 
---
 drivers/gpu/drm/bridge/imx/Kconfig   |   8 +
 drivers/gpu/drm/bridge/imx/Makefile  |   1 +
 drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c | 494 +++
 3 files changed, 503 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c

diff --git a/drivers/gpu/drm/bridge/imx/Kconfig 
b/drivers/gpu/drm/bridge/imx/Kconfig
index 4d1f027..1ea1ce7 100644
--- a/drivers/gpu/drm/bridge/imx/Kconfig
+++ b/drivers/gpu/drm/bridge/imx/Kconfig
@@ -14,3 +14,11 @@ config DRM_IMX8QXP_PIXEL_LINK
help
  Choose this to enable display pixel link found in
  Freescale i.MX8qm/qxp processors.
+
+config DRM_IMX8QXP_PIXEL_LINK_TO_DPI
+   tristate "Freescale i.MX8QXP pixel link to display pixel interface"
+   depends on OF
+   select DRM_KMS_HELPER
+   help
+ Choose this to enable pixel link to display pixel interface(PXL2DPI)
+ found in Freescale i.MX8qxp processor.
diff --git a/drivers/gpu/drm/bridge/imx/Makefile 
b/drivers/gpu/drm/bridge/imx/Makefile
index c15469f..e74dd64 100644
--- a/drivers/gpu/drm/bridge/imx/Makefile
+++ b/drivers/gpu/drm/bridge/imx/Makefile
@@ -1,2 +1,3 @@
 obj-$(CONFIG_DRM_IMX8QXP_PIXEL_COMBINER) += imx8qxp-pixel-combiner.o
 obj-$(CONFIG_DRM_IMX8QXP_PIXEL_LINK) += imx8qxp-pixel-link.o
+obj-$(CONFIG_DRM_IMX8QXP_PIXEL_LINK_TO_DPI) += imx8qxp-pxl2dpi.o
diff --git a/drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c 
b/drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c
new file mode 100644
index ..95ed89e
--- /dev/null
+++ b/drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c
@@ -0,0 +1,494 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+/*
+ * Copyright 2020 NXP
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#define PXL2DPI_CTRL   0x40
+#define  CFG1_16BIT0x0
+#define  CFG2_16BIT0x1
+#define  CFG3_16BIT0x2
+#define  CFG1_18BIT0x3
+#define  CFG2_18BIT0x4
+#define  CFG_24BIT 0x5
+
+#define DRIVER_NAME"imx8qxp-pxl2dpi"
+
+struct imx8qxp_pxl2dpi {
+   struct regmap *regmap;
+   struct drm_bridge bridge;
+   struct drm_bridge *next_bridge;
+   struct drm_bridge *companion;
+   struct device *dev;
+   struct imx_sc_ipc *ipc_handle;
+   u32 rsc;
+   u32 in_bus_format;
+   u32 out_bus_format;
+   u32 pl_sel;
+   int id;
+};
+
+#define bridge_to_p2d(b)   container_of(b, struct imx8qxp_pxl2dpi, bridge)
+
+static int imx8qxp_pxl2dpi_bridge_attach(struct drm_bridge *bridge,
+enum drm_bridge_attach_flags flags)
+{
+   struct imx8qxp_pxl2dpi *p2d = bridge->driver_private;
+
+   if (!(flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)) {
+   DRM_DEV_ERROR(p2d->dev,
+ "do not support creating a drm_connector\n");
+   return -EINVAL;
+   }
+
+   if (!bridge->encoder) {
+   DRM_DEV_ERROR(p2d->dev, "missing encoder\n");
+   return -ENODEV;
+   }
+
+   return drm_bridge_attach(bridge->encoder,
+p2d->next_bridge, bridge,
+DRM_BRIDGE_ATTACH_NO_CONNECTOR);
+}
+
+static int
+imx8qxp_pxl2dpi_bridge_atomic_check(struct drm_bridge *bridge,
+   struct drm_bridge_state *bridge_state,
+   struct drm_crtc_state *crtc_state,
+   struct drm_connector_state *conn_state)
+{
+   struct imx8qxp_pxl2dpi *p2d = bridge->driver_private;
+
+   p2d->in_bus_format = bridge_state->input_bus_cfg.format;
+   p2d->out_bus_format = bridge_state->output_bus_cfg.format;
+
+   return 0;
+}
+
+static void
+imx8qxp_pxl2dpi_bridge_mode_set(struct drm_bridge *bridge,
+   const struct drm_display_mode *mode,
+   const struct drm_display_mode *adjusted_mode)
+{
+   struct imx8qxp_pxl2dpi *p2d = bridge->driver_private;
+   struct imx8qxp_pxl2dpi *companion_p2d;
+   int ret;
+
+   ret = pm_runtime_get_sync(p2d->dev);
+   if (ret < 0)
+   DRM_DEV_ERROR(p2d->dev,
+ "failed to get runtime PM sync: %d\n", ret);
+
+   ret = imx_sc_misc_set_control(p2d->ipc_handle, p2d->rsc,
+ IMX_SC_C_PXL_LINK_SEL, p2d->pl_sel);
+   if (ret)
+   DRM_DEV_ERROR(p2d->dev,
+ "failed to set pixel link selection(%u): %d\n",
+ 

[PATCH 07/14] drm/bridge: imx: Add i.MX8qm/qxp display pixel link support

2020-12-17 Thread Liu Ying
This patch adds a drm bridge driver for i.MX8qm/qxp display pixel link.
The pixel link forms a standard asynchronous linkage between
pixel sources(display controller or camera module) and pixel
consumers(imaging or displays).  It consists of two distinct
functions, a pixel transfer function and a control interface.

Signed-off-by: Liu Ying 
---
 drivers/gpu/drm/bridge/imx/Kconfig  |   8 +
 drivers/gpu/drm/bridge/imx/Makefile |   1 +
 drivers/gpu/drm/bridge/imx/imx8qxp-pixel-link.c | 411 
 3 files changed, 420 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/imx/imx8qxp-pixel-link.c

diff --git a/drivers/gpu/drm/bridge/imx/Kconfig 
b/drivers/gpu/drm/bridge/imx/Kconfig
index f1c91b6..4d1f027 100644
--- a/drivers/gpu/drm/bridge/imx/Kconfig
+++ b/drivers/gpu/drm/bridge/imx/Kconfig
@@ -6,3 +6,11 @@ config DRM_IMX8QXP_PIXEL_COMBINER
help
  Choose this to enable pixel combiner found in
  Freescale i.MX8qm/qxp processors.
+
+config DRM_IMX8QXP_PIXEL_LINK
+   tristate "Freescale i.MX8QM/QXP display pixel link"
+   depends on OF
+   select DRM_KMS_HELPER
+   help
+ Choose this to enable display pixel link found in
+ Freescale i.MX8qm/qxp processors.
diff --git a/drivers/gpu/drm/bridge/imx/Makefile 
b/drivers/gpu/drm/bridge/imx/Makefile
index 7d7c8d6..c15469f 100644
--- a/drivers/gpu/drm/bridge/imx/Makefile
+++ b/drivers/gpu/drm/bridge/imx/Makefile
@@ -1 +1,2 @@
 obj-$(CONFIG_DRM_IMX8QXP_PIXEL_COMBINER) += imx8qxp-pixel-combiner.o
+obj-$(CONFIG_DRM_IMX8QXP_PIXEL_LINK) += imx8qxp-pixel-link.o
diff --git a/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-link.c 
b/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-link.c
new file mode 100644
index ..1af7467
--- /dev/null
+++ b/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-link.c
@@ -0,0 +1,411 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+/*
+ * Copyright 2020 NXP
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include 
+
+#define DRIVER_NAME"imx8qxp-display-pixel-link"
+#define PL_MAX_MST_ADDR3
+
+struct imx8qxp_pixel_link {
+   struct drm_bridge bridge;
+   struct drm_bridge *next_bridge;
+   struct device *dev;
+   struct imx_sc_ipc *ipc_handle;
+   int id;
+   int stream_id;
+   int dc_id;
+   u32 sink_rsc;
+   u32 mst_addr;
+   u8 mst_addr_ctrl;
+   u8 mst_en_ctrl;
+   u8 mst_vld_ctrl;
+   u8 sync_ctrl;
+};
+
+#define DEFINE_IMX8QXP_PIXEL_LINK_ENABLE_CTRL(name)\
+static void\
+imx8qxp_pixel_link_enable_##name(struct imx8qxp_pixel_link *pl)
\
+{  \
+   int ret = imx_sc_misc_set_control(pl->ipc_handle, pl->sink_rsc, \
+ pl->name##_ctrl, true);   \
+   if (ret)\
+   DRM_DEV_ERROR(pl->dev,  \
+   "failed to enable DC%d stream%d pixel link "\
+   #name ": %d\n", pl->dc_id, pl->stream_id, ret); \
+}
+
+DEFINE_IMX8QXP_PIXEL_LINK_ENABLE_CTRL(mst_en)
+DEFINE_IMX8QXP_PIXEL_LINK_ENABLE_CTRL(mst_vld)
+DEFINE_IMX8QXP_PIXEL_LINK_ENABLE_CTRL(sync)
+
+#define DEFINE_IMX8QXP_PIXEL_LINK_DISABLE_CTRL(name)   \
+static int \
+imx8qxp_pixel_link_disable_##name(struct imx8qxp_pixel_link *pl)   \
+{  \
+   int ret = imx_sc_misc_set_control(pl->ipc_handle, pl->sink_rsc, \
+ pl->name##_ctrl, false);  \
+   if (ret)\
+   DRM_DEV_ERROR(pl->dev,  \
+   "failed to disable DC%d stream%d pixel link "   \
+   #name ": %d\n", pl->dc_id, pl->stream_id, ret); \
+   \
+   return ret; \
+}
+
+DEFINE_IMX8QXP_PIXEL_LINK_DISABLE_CTRL(mst_en)
+DEFINE_IMX8QXP_PIXEL_LINK_DISABLE_CTRL(mst_vld)
+DEFINE_IMX8QXP_PIXEL_LINK_DISABLE_CTRL(sync)
+
+static void imx8qxp_pixel_link_set_mst_addr(struct imx8qxp_pixel_link *pl)
+{
+   int ret;
+
+   ret = imx_sc_misc_set_control(pl->ipc_handle,
+ pl->sink_rsc, pl->mst_addr_ctrl,
+ pl->mst_addr);
+   if (ret)
+   DRM_DEV_ERROR(pl->dev,
+   "failed to set DC%d stream%d pixel link mst addr(%u): %d\n",
+   pl->dc_id, pl->stream_id, pl->mst_addr, ret);
+}
+
+static int imx8qxp_pixel_link_bridge_attach(struct drm_bridg

[PATCH 10/14] drm/bridge: imx: Add LDB driver helper support

2020-12-17 Thread Liu Ying
This patch adds a helper to support LDB drm bridge drivers for
i.MX SoCs.  Helper functions exported from this driver should
implement common logics for all LDB modules embedded in i.MX SoCs.

Signed-off-by: Liu Ying 
---
 drivers/gpu/drm/bridge/imx/Kconfig  |   8 +
 drivers/gpu/drm/bridge/imx/Makefile |   1 +
 drivers/gpu/drm/bridge/imx/imx-ldb-helper.c | 248 
 include/drm/bridge/imx_ldb_helper.h |  98 +++
 4 files changed, 355 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/imx/imx-ldb-helper.c
 create mode 100644 include/drm/bridge/imx_ldb_helper.h

diff --git a/drivers/gpu/drm/bridge/imx/Kconfig 
b/drivers/gpu/drm/bridge/imx/Kconfig
index 1ea1ce7..23e24fd 100644
--- a/drivers/gpu/drm/bridge/imx/Kconfig
+++ b/drivers/gpu/drm/bridge/imx/Kconfig
@@ -1,3 +1,11 @@
+config DRM_IMX_LVDS_BRIDGE_HELPER
+   tristate "Freescale i.MX LVDS display bridge helper"
+   depends on OF
+   select DRM_PANEL_BRIDGE
+   help
+ Helper to support Freescale i.MX LVDS Display Bridge(LDB).
+ This bridge is embedded in a SoC.
+
 config DRM_IMX8QXP_PIXEL_COMBINER
tristate "Freescale i.MX8QM/QXP pixel combiner"
depends on OF
diff --git a/drivers/gpu/drm/bridge/imx/Makefile 
b/drivers/gpu/drm/bridge/imx/Makefile
index e74dd64..902b703 100644
--- a/drivers/gpu/drm/bridge/imx/Makefile
+++ b/drivers/gpu/drm/bridge/imx/Makefile
@@ -1,3 +1,4 @@
+obj-$(CONFIG_DRM_IMX_LVDS_BRIDGE_HELPER) += imx-ldb-helper.o
 obj-$(CONFIG_DRM_IMX8QXP_PIXEL_COMBINER) += imx8qxp-pixel-combiner.o
 obj-$(CONFIG_DRM_IMX8QXP_PIXEL_LINK) += imx8qxp-pixel-link.o
 obj-$(CONFIG_DRM_IMX8QXP_PIXEL_LINK_TO_DPI) += imx8qxp-pxl2dpi.o
diff --git a/drivers/gpu/drm/bridge/imx/imx-ldb-helper.c 
b/drivers/gpu/drm/bridge/imx/imx-ldb-helper.c
new file mode 100644
index ..ccf06a7
--- /dev/null
+++ b/drivers/gpu/drm/bridge/imx/imx-ldb-helper.c
@@ -0,0 +1,248 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2012 Sascha Hauer, Pengutronix
+ * Copyright 2019,2020 NXP
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+bool ldb_channel_is_single_link(struct ldb_channel *ldb_ch)
+{
+   return ldb_ch->link_type == LDB_CH_SINGLE_LINK;
+}
+EXPORT_SYMBOL_GPL(ldb_channel_is_single_link);
+
+bool ldb_channel_is_split_link(struct ldb_channel *ldb_ch)
+{
+   return ldb_ch->link_type == LDB_CH_DUAL_LINK_EVEN_ODD_PIXELS ||
+  ldb_ch->link_type == LDB_CH_DUAL_LINK_ODD_EVEN_PIXELS;
+}
+EXPORT_SYMBOL_GPL(ldb_channel_is_split_link);
+
+int ldb_bridge_atomic_check_helper(struct drm_bridge *bridge,
+  struct drm_bridge_state *bridge_state,
+  struct drm_crtc_state *crtc_state,
+  struct drm_connector_state *conn_state)
+{
+   struct ldb_channel *ldb_ch = bridge->driver_private;
+
+   ldb_ch->in_bus_format = bridge_state->input_bus_cfg.format;
+   ldb_ch->out_bus_format = bridge_state->output_bus_cfg.format;
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(ldb_bridge_atomic_check_helper);
+
+void ldb_bridge_mode_set_helper(struct drm_bridge *bridge,
+   const struct drm_display_mode *mode,
+   const struct drm_display_mode *adjusted_mode)
+{
+   struct ldb_channel *ldb_ch = bridge->driver_private;
+   struct ldb *ldb = ldb_ch->ldb;
+   bool is_split = ldb_channel_is_split_link(ldb_ch);
+
+   if (is_split)
+   ldb->ldb_ctrl |= LDB_SPLIT_MODE_EN;
+
+   switch (ldb_ch->out_bus_format) {
+   case MEDIA_BUS_FMT_RGB666_1X7X3_SPWG:
+   break;
+   case MEDIA_BUS_FMT_RGB888_1X7X4_SPWG:
+   if (ldb_ch->chno == 0 || is_split)
+   ldb->ldb_ctrl |= LDB_DATA_WIDTH_CH0_24;
+   if (ldb_ch->chno == 1 || is_split)
+   ldb->ldb_ctrl |= LDB_DATA_WIDTH_CH1_24;
+   break;
+   case MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA:
+   if (ldb_ch->chno == 0 || is_split)
+   ldb->ldb_ctrl |= LDB_DATA_WIDTH_CH0_24 |
+LDB_BIT_MAP_CH0_JEIDA;
+   if (ldb_ch->chno == 1 || is_split)
+   ldb->ldb_ctrl |= LDB_DATA_WIDTH_CH1_24 |
+LDB_BIT_MAP_CH1_JEIDA;
+   break;
+   }
+}
+EXPORT_SYMBOL_GPL(ldb_bridge_mode_set_helper);
+
+void ldb_bridge_enable_helper(struct drm_bridge *bridge)
+{
+   struct ldb_channel *ldb_ch = bridge->driver_private;
+   struct ldb *ldb = ldb_ch->ldb;
+
+   /*
+* Platform specific bridge drivers should set ldb_ctrl properly
+* for the enablement, so just write the ctrl_reg here.
+*/
+   regmap_write(ldb->regmap, ldb->ctrl_reg, ldb->ldb_ctrl);
+}
+EXPORT_SYMBOL_GPL(ldb_bridge_enable_helper);
+
+void ldb_bridge_disable_helper(struct drm_bridge *bridg

[PATCH 11/14] dt-bindings: display: bridge: Add i.MX8qm/qxp LVDS display bridge binding

2020-12-17 Thread Liu Ying
This patch adds bindings for i.MX8qm/qxp LVDS display bridge(LDB).

Signed-off-by: Liu Ying 
---
 .../bindings/display/bridge/fsl,imx8qxp-ldb.yaml   | 185 +
 1 file changed, 185 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-ldb.yaml

diff --git 
a/Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-ldb.yaml 
b/Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-ldb.yaml
new file mode 100644
index ..4e5ff6f
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-ldb.yaml
@@ -0,0 +1,185 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/fsl,imx8qxp-ldb.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX8qm/qxp LVDS Display Bridge
+
+maintainers:
+  - Liu Ying 
+
+description: |
+  The Freescale i.MX8qm/qxp LVDS Display Bridge(LDB) has two channels.
+
+  For i.MX8qxp LDB, each channel supports up to 24bpp parallel input color
+  format and can map the input to VESA or JEIDA standards.  The two channels
+  cannot be used simultaneously, that is to say, the user should pick one of
+  them to use.  Two LDB channels from two LDB instances can work together in
+  LDB split mode to support a dual link LVDS display.  The channel indexes
+  have to be different.  Channel0 outputs odd pixels and channel1 outputs
+  even pixels.
+
+  For i.MX8qm LDB, each channel additionally supports up to 30bpp parallel
+  input color format.  The two channels can be used simultaneously, either
+  in dual mode or split mode.  In dual mode, the two channels output identical
+  data.  In split mode, channel0 outputs odd pixels and channel1 outputs even
+  pixels.
+
+properties:
+  compatible:
+enum:
+  - fsl,imx8qm-ldb
+  - fsl,imx8qxp-ldb
+
+  "#address-cells":
+const: 1
+
+  "#size-cells":
+const: 0
+
+  clocks:
+items:
+  - description: pixel clock
+  - description: bypass clock
+
+  clock-names:
+items:
+  - const: pixel
+  - const: bypass
+
+  power-domains:
+maxItems: 1
+
+  fsl,syscon:
+$ref: /schemas/types.yaml#/definitions/phandle
+description: |
+  A phandle which points to Control and Status Registers(CSR) module.
+
+  fsl,companion-ldb:
+$ref: /schemas/types.yaml#/definitions/phandle
+description: |
+  A phandle which points to companion LDB which is used in LDB split mode.
+
+patternProperties:
+  "^channel@[0-1]$":
+type: object
+description: Represents a channel of LDB.
+
+properties:
+  "#address-cells":
+const: 1
+
+  "#size-cells":
+const: 0
+
+  reg:
+description: The channel index.
+enum: [ 0, 1 ]
+
+  phys:
+description: A phandle to the phy module representing the LVDS PHY.
+maxItems: 1
+
+  phy-names:
+const: lvds_phy
+
+  port@0:
+type: object
+description: Input port of the channel.
+
+properties:
+  reg:
+const: 0
+
+required:
+  - reg
+
+  port@1:
+type: object
+description: Output port of the channel.
+
+properties:
+  reg:
+const: 1
+
+required:
+  - reg
+
+required:
+  - "#address-cells"
+  - "#size-cells"
+  - reg
+  - phys
+  - phy-names
+
+additionalProperties: false
+
+required:
+  - compatible
+  - "#address-cells"
+  - "#size-cells"
+  - clocks
+  - clock-names
+  - power-domains
+  - fsl,syscon
+  - channel@0
+  - channel@1
+
+allOf:
+  - if:
+  properties:
+compatible:
+  contains:
+const: fsl,imx8qm-ldb
+then:
+  properties:
+fsl,companion-ldb: false
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+ldb {
+#address-cells = <1>;
+#size-cells = <0>;
+compatible = "fsl,imx8qxp-ldb";
+clocks = <&clk IMX_SC_R_LVDS_0 IMX_SC_PM_CLK_MISC2>,
+ <&clk IMX_SC_R_LVDS_0 IMX_SC_PM_CLK_BYPASS>;
+clock-names = "pixel", "bypass";
+power-domains = <&pd IMX_SC_R_LVDS_0>;
+fsl,syscon = <&mipi_lvds_0_csr>;
+
+channel@0 {
+#address-cells = <1>;
+#size-cells = <0>;
+reg = <0>;
+phys = <&mipi_lvds_0_phy>;
+phy-names = "lvds_phy";
+
+port@0 {
+reg = <0>;
+
+mipi_lvds_0_ldb_ch0_mipi_lvds_0_pxl2dpi: endpoint {
+remote-endpoint = 
<&mipi_lvds_0_pxl2dpi_mipi_lvds_0_ldb_ch0>;
+};
+};
+};
+
+channel@1 {
+#address-cells = <1>;
+#size-cells = <0>;
+reg = <1>;
+phys = <&mipi_lvds_0_phy>;
+phy-names = "lvds_phy";
+
+port@0 {
+reg = <0>;
+
+mipi_lvds_0_ldb_ch1_mipi_lvds_0_pxl2dpi: 

[PATCH 12/14] drm/bridge: imx: Add LDB support for i.MX8qxp

2020-12-17 Thread Liu Ying
This patch adds a drm bridge driver for i.MX8qxp LVDS display bridge(LDB).
The LDB has two channels.  Each of them supports up to 24bpp parallel
input color format and can map the input to VESA or JEIDA standards.
The two channels cannot be used simultaneously, that is to say, the user
should pick one of them to use.  Two LDB channels from two LDB instances
can work together in LDB split mode to support a dual link LVDS display.
The channel indexes have to be different.  Channel0 outputs odd pixels
and channel1 outputs even pixels.  This patch supports the LDB single
mode and split mode.

Signed-off-by: Liu Ying 
---
 drivers/gpu/drm/bridge/imx/Kconfig   |  10 +
 drivers/gpu/drm/bridge/imx/Makefile  |   1 +
 drivers/gpu/drm/bridge/imx/imx8qxp-ldb.c | 762 +++
 3 files changed, 773 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/imx/imx8qxp-ldb.c

diff --git a/drivers/gpu/drm/bridge/imx/Kconfig 
b/drivers/gpu/drm/bridge/imx/Kconfig
index 23e24fd..2a32ad3 100644
--- a/drivers/gpu/drm/bridge/imx/Kconfig
+++ b/drivers/gpu/drm/bridge/imx/Kconfig
@@ -6,6 +6,16 @@ config DRM_IMX_LVDS_BRIDGE_HELPER
  Helper to support Freescale i.MX LVDS Display Bridge(LDB).
  This bridge is embedded in a SoC.
 
+config DRM_IMX8QXP_LDB
+   tristate "Freescale i.MX8QXP LVDS display bridge"
+   depends on DRM_IMX_LVDS_BRIDGE_HELPER
+   depends on OF
+   depends on COMMON_CLK
+   select DRM_KMS_HELPER
+   help
+ Choose this to enable the internal LVDS Display Bridge(LDB) found in
+ Freescale i.MX8qxp processor.
+
 config DRM_IMX8QXP_PIXEL_COMBINER
tristate "Freescale i.MX8QM/QXP pixel combiner"
depends on OF
diff --git a/drivers/gpu/drm/bridge/imx/Makefile 
b/drivers/gpu/drm/bridge/imx/Makefile
index 902b703..13160f0 100644
--- a/drivers/gpu/drm/bridge/imx/Makefile
+++ b/drivers/gpu/drm/bridge/imx/Makefile
@@ -1,4 +1,5 @@
 obj-$(CONFIG_DRM_IMX_LVDS_BRIDGE_HELPER) += imx-ldb-helper.o
+obj-$(CONFIG_DRM_IMX8QXP_LDB) += imx8qxp-ldb.o
 obj-$(CONFIG_DRM_IMX8QXP_PIXEL_COMBINER) += imx8qxp-pixel-combiner.o
 obj-$(CONFIG_DRM_IMX8QXP_PIXEL_LINK) += imx8qxp-pixel-link.o
 obj-$(CONFIG_DRM_IMX8QXP_PIXEL_LINK_TO_DPI) += imx8qxp-pxl2dpi.o
diff --git a/drivers/gpu/drm/bridge/imx/imx8qxp-ldb.c 
b/drivers/gpu/drm/bridge/imx/imx8qxp-ldb.c
new file mode 100644
index ..318615fb
--- /dev/null
+++ b/drivers/gpu/drm/bridge/imx/imx8qxp-ldb.c
@@ -0,0 +1,762 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+/*
+ * Copyright 2020 NXP
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define  LDB_CH_SEL(1 << 28)
+
+#define SS_CTRL0x20
+#define  CH_HSYNC_M(id)BIT(0 + ((id) * 2))
+#define  CH_VSYNC_M(id)BIT(1 + ((id) * 2))
+#define  CH_PHSYNC(id) BIT(0 + ((id) * 2))
+#define  CH_PVSYNC(id) BIT(1 + ((id) * 2))
+
+#define DRIVER_NAME"imx8qxp-ldb"
+
+struct imx8qxp_ldb_channel {
+   struct ldb_channel base;
+   struct phy *phy;
+   unsigned int di_id;
+};
+
+struct imx8qxp_ldb {
+   struct ldb base;
+   struct device *dev;
+   struct imx8qxp_ldb_channel channel[MAX_LDB_CHAN_NUM];
+   struct clk *clk_pixel;
+   struct clk *clk_bypass;
+   struct drm_bridge *companion;
+   int active_chno;
+};
+
+static inline struct imx8qxp_ldb_channel *
+base_to_imx8qxp_ldb_channel(struct ldb_channel *base)
+{
+   return container_of(base, struct imx8qxp_ldb_channel, base);
+}
+
+static inline struct imx8qxp_ldb *base_to_imx8qxp_ldb(struct ldb *base)
+{
+   return container_of(base, struct imx8qxp_ldb, base);
+}
+
+static void imx8qxp_ldb_set_phy_cfg(struct imx8qxp_ldb *imx8qxp_ldb,
+   unsigned long di_clk, bool is_split,
+   struct phy_configure_opts_lvds *phy_cfg)
+{
+   phy_cfg->bits_per_lane_and_dclk_cycle = 7;
+   phy_cfg->lanes = 4;
+
+   if (is_split) {
+   phy_cfg->differential_clk_rate = di_clk / 2;
+   phy_cfg->is_slave = !imx8qxp_ldb->companion;
+   } else {
+   phy_cfg->differential_clk_rate = di_clk;
+   phy_cfg->is_slave = false;
+   }
+}
+
+static int imx8qxp_ldb_bridge_atomic_check(struct drm_bridge *bridge,
+  struct drm_bridge_state *bridge_state,
+  struct drm_crtc_state *crtc_state,
+  struct drm_connector_state *conn_state)
+{
+   struct ldb_channel *ldb_ch = bridge->driver_private;
+   struct ldb *ldb = ldb_ch->ldb;
+   struct imx8qxp_ldb_channel *imx8qxp_ldb_ch =
+   base_to_imx8qxp_ldb_channel(ldb_ch);
+   struct imx8qxp_ldb *imx8qxp_ldb = base_to_imx8qxp_ldb(ldb);
+   struct drm_bridge *

[PATCH 06/14] dt-bindings: display: bridge: Add i.MX8qm/qxp display pixel link binding

2020-12-17 Thread Liu Ying
This patch adds bindings for i.MX8qm/qxp display pixel link.

Signed-off-by: Liu Ying 
---
 .../display/bridge/fsl,imx8qxp-pixel-link.yaml | 128 +
 1 file changed, 128 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pixel-link.yaml

diff --git 
a/Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pixel-link.yaml 
b/Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pixel-link.yaml
new file mode 100644
index ..fd24a0e
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pixel-link.yaml
@@ -0,0 +1,128 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/fsl,imx8qxp-pixel-link.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX8qm/qxp Display Pixel Link
+
+maintainers:
+  - Liu Ying 
+
+description: |
+  The Freescale i.MX8qm/qxp Display Pixel Link(DPL) forms a standard
+  asynchronous linkage between pixel sources(display controller or
+  camera module) and pixel consumers(imaging or displays).
+  It consists of two distinct functions, a pixel transfer function and a
+  control interface.  Multiple pixel channels can exist per one control 
channel.
+  This binding documentation is only for pixel links whose pixel sources are
+  display controllers.
+
+properties:
+  compatible:
+enum:
+  - fsl,imx8qm-dc-pixel-link
+  - fsl,imx8qxp-dc-pixel-link
+
+  ports:
+type: object
+description: |
+  A node containing pixel link input & output port nodes with endpoint
+  definitions as documented in
+  Documentation/devicetree/bindings/media/video-interfaces.txt
+  Documentation/devicetree/bindings/graph.txt
+
+properties:
+  '#address-cells':
+const: 1
+
+  '#size-cells':
+const: 0
+
+  port@0:
+type: object
+description: The pixel link input port node from upstream video source.
+
+properties:
+  reg:
+const: 0
+
+required:
+  - reg
+
+patternProperties:
+  "^port@[1-4]$":
+type: object
+description: The pixel link output port node to downstream bridge.
+
+properties:
+  reg:
+enum: [ 1, 2, 3, 4 ]
+
+required:
+  - reg
+
+required:
+  - "#address-cells"
+  - "#size-cells"
+  - port@0
+
+anyOf:
+  - required:
+  - port@1
+  - required:
+  - port@2
+  - required:
+  - port@3
+  - required:
+  - port@4
+
+additionalProperties: false
+
+required:
+  - compatible
+  - ports
+
+additionalProperties: false
+
+examples:
+  - |
+dc0-pixel-link0 {
+compatible = "fsl,imx8qxp-dc-pixel-link";
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+/* from dc0 pixel combiner channel0 */
+port@0 {
+reg = <0>;
+
+dc0_pixel_link0_dc0_pixel_combiner_ch0: endpoint {
+remote-endpoint = 
<&dc0_pixel_combiner_ch0_dc0_pixel_link0>;
+};
+};
+
+/* to PXL2DPIs in MIPI/LVDS combo subsystems */
+port@1 {
+#address-cells = <1>;
+#size-cells = <0>;
+reg = <1>;
+
+dc0_pixel_link0_mipi_lvds_0_pxl2dpi: endpoint@0 {
+reg = <0>;
+remote-endpoint = <&mipi_lvds_0_pxl2dpi_dc0_pixel_link0>;
+};
+
+dc0_pixel_link0_mipi_lvds_1_pxl2dpi: endpoint@1 {
+reg = <1>;
+remote-endpoint = <&mipi_lvds_1_pxl2dpi_dc0_pixel_link0>;
+};
+};
+
+/* to imaging subsystem */
+port@4 {
+reg = <4>;
+};
+};
+};
-- 
2.7.4



[PATCH 14/14] MAINTAINERS: add maintainer for DRM bridge drivers for i.MX SoCs

2020-12-17 Thread Liu Ying
Add myself as the maintainer of DRM bridge drivers for i.MX SoCs.

Signed-off-by: Liu Ying 
---
 MAINTAINERS | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 7b073c4..4b4e40e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5846,6 +5846,16 @@ F:   Documentation/devicetree/bindings/display/imx/
 F: drivers/gpu/drm/imx/
 F: drivers/gpu/ipu-v3/
 
+DRM DRIVERS FOR FREESCALE IMX BRIDGE
+M: Liu Ying 
+L: dri-de...@lists.freedesktop.org
+S: Maintained
+F: Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-ldb.yaml
+F: 
Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pixel-combiner.yaml
+F: 
Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pixel-link.yaml
+F: 
Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pxl2dpi.yaml
+F: drivers/gpu/drm/bridge/imx/
+
 DRM DRIVERS FOR GMA500 (Poulsbo, Moorestown and derivative chipsets)
 M: Patrik Jakobsson 
 L: dri-de...@lists.freedesktop.org
-- 
2.7.4



[PATCH 13/14] drm/bridge: imx: Add LDB support for i.MX8qm

2020-12-17 Thread Liu Ying
This patch adds a drm bridge driver for i.MX8qm LVDS display bridge(LDB).
The LDB has two channels.  Each of them supports up to 30bpp parallel
input color format and can map the input to VESA or JEIDA standards.
The two channels can be used simultaneously, either in dual mode or
split mode.  In dual mode, the two channels output identical data.
In split mode, channel0 outputs odd pixels and channel1 outputs even
pixels.  This patch supports the LDB single mode and split mode.

Signed-off-by: Liu Ying 
---
 drivers/gpu/drm/bridge/imx/Kconfig  |  10 +
 drivers/gpu/drm/bridge/imx/Makefile |   1 +
 drivers/gpu/drm/bridge/imx/imx8qm-ldb.c | 589 
 3 files changed, 600 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/imx/imx8qm-ldb.c

diff --git a/drivers/gpu/drm/bridge/imx/Kconfig 
b/drivers/gpu/drm/bridge/imx/Kconfig
index 2a32ad3..46981f3 100644
--- a/drivers/gpu/drm/bridge/imx/Kconfig
+++ b/drivers/gpu/drm/bridge/imx/Kconfig
@@ -6,6 +6,16 @@ config DRM_IMX_LVDS_BRIDGE_HELPER
  Helper to support Freescale i.MX LVDS Display Bridge(LDB).
  This bridge is embedded in a SoC.
 
+config DRM_IMX8QM_LDB
+   tristate "Freescale i.MX8QM LVDS display bridge"
+   depends on DRM_IMX_LVDS_BRIDGE_HELPER
+   depends on OF
+   depends on COMMON_CLK
+   select DRM_KMS_HELPER
+   help
+ Choose this to enable the internal LVDS Display Bridge(LDB) found in
+ Freescale i.MX8qm processor.
+
 config DRM_IMX8QXP_LDB
tristate "Freescale i.MX8QXP LVDS display bridge"
depends on DRM_IMX_LVDS_BRIDGE_HELPER
diff --git a/drivers/gpu/drm/bridge/imx/Makefile 
b/drivers/gpu/drm/bridge/imx/Makefile
index 13160f0..a964efc 100644
--- a/drivers/gpu/drm/bridge/imx/Makefile
+++ b/drivers/gpu/drm/bridge/imx/Makefile
@@ -1,4 +1,5 @@
 obj-$(CONFIG_DRM_IMX_LVDS_BRIDGE_HELPER) += imx-ldb-helper.o
+obj-$(CONFIG_DRM_IMX8QM_LDB) += imx8qm-ldb.o
 obj-$(CONFIG_DRM_IMX8QXP_LDB) += imx8qxp-ldb.o
 obj-$(CONFIG_DRM_IMX8QXP_PIXEL_COMBINER) += imx8qxp-pixel-combiner.o
 obj-$(CONFIG_DRM_IMX8QXP_PIXEL_LINK) += imx8qxp-pixel-link.o
diff --git a/drivers/gpu/drm/bridge/imx/imx8qm-ldb.c 
b/drivers/gpu/drm/bridge/imx/imx8qm-ldb.c
new file mode 100644
index ..9860320
--- /dev/null
+++ b/drivers/gpu/drm/bridge/imx/imx8qm-ldb.c
@@ -0,0 +1,589 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+/*
+ * Copyright 2020 NXP
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define  LDB_CH0_10BIT_EN  (1 << 22)
+#define  LDB_CH1_10BIT_EN  (1 << 23)
+#define  LDB_CH0_DATA_WIDTH_24BIT  (1 << 24)
+#define  LDB_CH1_DATA_WIDTH_24BIT  (1 << 26)
+#define  LDB_CH0_DATA_WIDTH_30BIT  (2 << 24)
+#define  LDB_CH1_DATA_WIDTH_30BIT  (2 << 26)
+
+#define SS_CTRL0x20
+#define  CH_HSYNC_M(id)BIT(0 + ((id) * 2))
+#define  CH_VSYNC_M(id)BIT(1 + ((id) * 2))
+#define  CH_PHSYNC(id) BIT(0 + ((id) * 2))
+#define  CH_PVSYNC(id) BIT(1 + ((id) * 2))
+
+#define DRIVER_NAME"imx8qm-ldb"
+
+struct imx8qm_ldb_channel {
+   struct ldb_channel base;
+   struct phy *phy;
+};
+
+struct imx8qm_ldb {
+   struct ldb base;
+   struct device *dev;
+   struct imx8qm_ldb_channel channel[MAX_LDB_CHAN_NUM];
+   struct clk *clk_pixel;
+   struct clk *clk_bypass;
+   int active_chno;
+};
+
+static inline struct imx8qm_ldb_channel *
+base_to_imx8qm_ldb_channel(struct ldb_channel *base)
+{
+   return container_of(base, struct imx8qm_ldb_channel, base);
+}
+
+static inline struct imx8qm_ldb *base_to_imx8qm_ldb(struct ldb *base)
+{
+   return container_of(base, struct imx8qm_ldb, base);
+}
+
+static void imx8qm_ldb_set_phy_cfg(struct imx8qm_ldb *imx8qm_ldb,
+  unsigned long di_clk,
+  bool is_split, bool is_slave,
+  struct phy_configure_opts_lvds *phy_cfg)
+{
+   phy_cfg->bits_per_lane_and_dclk_cycle = 7;
+   phy_cfg->lanes = 4;
+   phy_cfg->differential_clk_rate = is_split ? di_clk / 2 : di_clk;
+   phy_cfg->is_slave = is_slave;
+}
+
+static int imx8qm_ldb_bridge_atomic_check(struct drm_bridge *bridge,
+ struct drm_bridge_state *bridge_state,
+ struct drm_crtc_state *crtc_state,
+ struct drm_connector_state 
*conn_state)
+{
+   struct ldb_channel *ldb_ch = bridge->driver_private;
+   struct ldb *ldb = ldb_ch->ldb;
+   struct imx8qm_ldb_channel *imx8qm_ldb_ch =
+   base_to_imx8qm_ldb_channel(ldb_ch);
+   struct imx8qm_ldb *imx8qm_ldb = base_to_imx8qm_ldb(ldb);
+   struct drm_display_mo

upstream boot error: UBSAN: null-ptr-deref in corrupted

2020-12-17 Thread syzbot
Hello,

syzbot found the following issue on:

HEAD commit:accefff5 Merge tag 'arm-soc-omap-genpd-5.11' of git://git...
git tree:   upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=14567b7f50
kernel config:  https://syzkaller.appspot.com/x/.config?x=1e6efc730c219bd4
dashboard link: https://syzkaller.appspot.com/bug?extid=73d662376f16e2a7336d
compiler:   clang version 11.0.0 (https://github.com/llvm/llvm-project.git 
ca2dcbd030eadbf0aa9b660efe864ff08af6e18b)

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+73d662376f16e2a73...@syzkaller.appspotmail.com

Linux version 5.10.0-syzkaller (syzkaller@syzkaller) (clang version 11.0.0 
(https://github.com/llvm/llvm-project.git 
ca2dcbd030eadbf0aa9b660efe864ff08af6e18b), GNU ld (GNU Binutils for Ubuntu) 
2.26.1) #0 SMP PREEMPT now
Command line: BOOT_IMAGE=/vmlinuz root=/dev/sda1 console=ttyS0 
earlyprintk=serial vsyscall=native oops=panic panic_on_warn=1 
nmi_watchdog=panic panic=86400 net.ifnames=0 
sysctl.kernel.hung_task_all_cpu_backtrace=1
KERNEL supported cpus:
  Intel GenuineIntel
  AMD AuthenticAMD
x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 
'standard' format.
BIOS-provided physical RAM map:
BIOS-e820: [mem 0x-0x0009fbff] usable
BIOS-e820: [mem 0x0009fc00-0x0009] reserved
BIOS-e820: [mem 0x000f-0x000f] reserved
BIOS-e820: [mem 0x0010-0xbfffcfff] usable
BIOS-e820: [mem 0xbfffd000-0xbfff] reserved
BIOS-e820: [mem 0xfffbc000-0x] reserved
BIOS-e820: [mem 0x0001-0x00023fff] usable
printk: bootconsole [earlyser0] enabled
ERROR: earlyprintk= earlyser already used
ERROR: earlyprintk= earlyser already used
ERROR: earlyprintk= earlyser already used
nopcid: PCID feature disabled
Malformed early option 'vsyscall'
Malformed early option 'vsyscall'
NX (Execute Disable) protection: active
SMBIOS 2.4 present.
DMI: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Hypervisor detected: KVM
kvm-clock: Using msrs 4b564d01 and 4b564d00
kvm-clock: cpu 0, msr dde2001, primary cpu clock
kvm-clock: using sched offset of 3478136367 cycles
clocksource: kvm-clock: mask: 0x max_cycles: 0x1cd42e4dffb, 
max_idle_ns: 881590591483 ns
tsc: Detected 2300.000 MHz processor
last_pfn = 0x24 max_arch_pfn = 0x4
x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WP  UC- WT  
last_pfn = 0xbfffd max_arch_pfn = 0x4
found SMP MP-table at [mem 0x000f25a0-0x000f25af]
Using GB pages for direct mapping
ACPI: Early table checksum verification disabled
ACPI: RSDP 0x000F2320 14 (v00 Google)
ACPI: RSDT 0xBFA0 38 (v01 Google GOOGRSDT 0001 GOOG 
0001)
ACPI: FACP 0xB340 F4 (v02 Google GOOGFACP 0001 GOOG 
0001)

UBSAN: null-ptr-deref in drivers/acpi/acpica/tbfadt.c:459:37
member access within null pointer of type 'struct acpi_table_fadt'
CPU: 0 PID: 0 Comm: swapper Not tainted 5.10.0-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 
01/01/2011
Call Trace:

ACPI: DSDT 0xBFFFDA80 0018BA (v01 Google GOOGDSDT 0001 GOOG 
0001)
ACPI: FACS 0xBFFFDA40 40
ACPI: FACS 0xBFFFDA40 40
ACPI: SRAT 0xBE70 C8 (v03 Google GOOGSRAT 0001 GOOG 
0001)
ACPI: APIC 0xBDC0 76 (v05 Google GOOGAPIC 0001 GOOG 
0001)
ACPI: SSDT 0xB440 000980 (v01 Google GOOGSSDT 0001 GOOG 
0001)
ACPI: WAET 0xBE40 28 (v01 Google GOOGWAET 0001 GOOG 
0001)
SRAT: PXM 0 -> APIC 0x00 -> Node 0
SRAT: PXM 0 -> APIC 0x01 -> Node 0
ACPI: SRAT: Node 0 PXM 0 [mem 0x-0x0009]
ACPI: SRAT: Node 0 PXM 0 [mem 0x0010-0xbfff]
ACPI: SRAT: Node 0 PXM 0 [mem 0x1-0x23fff]
NUMA: Node 0 [mem 0x-0x0009] + [mem 0x0010-0xbfff] -> [mem 
0x-0xbfff]
NUMA: Node 0 [mem 0x-0xbfff] + [mem 0x1-0x23fff] -> 
[mem 0x-0x23fff]
Faking node 0 at [mem 0x-0x00013fff] (5120MB)
Faking node 1 at [mem 0x00014000-0x00023fff] (4096MB)
NODE_DATA(0) allocated [mem 0x13fffb000-0x13fff]
NODE_DATA(1) allocated [mem 0x23fff8000-0x23fffcfff]
Zone ranges:
  DMA  [mem 0x1000-0x00ff]
  DMA32[mem 0x0100-0x]
  Normal   [mem 0x0001-0x00023fff]
  Device   empty
Movab

Re: [PATCH v4 2/6] dt: bindings: add mt7621-clk device tree binding documentation

2020-12-17 Thread Sergio Paracuellos
On Thu, Dec 17, 2020 at 11:07 AM Stephen Boyd  wrote:
>
> Quoting Sergio Paracuellos (2020-12-17 02:01:39)
> >
> > On Thu, Dec 17, 2020 at 9:58 AM Stephen Boyd  wrote:
> > >
> > > Quoting Sergio Paracuellos (2020-11-22 01:55:52)
> > >
> > > > diff --git 
> > > > a/Documentation/devicetree/bindings/clock/mediatek,mt7621-clk.yaml 
> > > > b/Documentation/devicetree/bindings/clock/mediatek,mt7621-clk.yaml
> > > > new file mode 100644
> > > > index ..6aca4c1a4a46
> > > > --- /dev/null
> > > > +++ b/Documentation/devicetree/bindings/clock/mediatek,mt7621-clk.yaml
> > >
> > > > +  compatible = "mediatek,mt7621-sysc", "syscon";
> > > > +  reg = <0x0 0x100>;
> > > > +
> > > > +  pll {
> > >
> > > clock-controller? Why can't the parent device be the clk provider and
> > > have #clock-cells?
> > >
> >
> > I don't get your point, sorry. Can you please explain this a bit more
> > or point to me to an example to understand the real meaning of this?
>
> It looks like this is a made up child node of syscon so that a driver
> can probe in the kernel. It would be more DT friendly to create a
> platform device from the parent node's driver, or just register the clks
> with the framework directly in that driver.

We cannot create a platform device because we need clocks available in
'plat_time_init' before setting up the timer for the GIC.
The only way I see to avoid this syscon and having this as a child
node is to use architecture operations in
'arch/mips/include/asm/mach-ralink/ralink_regs.h'
instead of getting a phandle using the regmap is being currently used...


Re: [PATCH] clk: exynos7: Mark aclk_fsys1_200 as critical

2020-12-17 Thread Stephen Boyd
Not sure why this wasn't picked up in the samsung PR. Can you resend?

> diff --git a/drivers/clk/samsung/clk-exynos7.c 
> b/drivers/clk/samsung/clk-exynos7.c
> index c1ff715e960c..1048d83f097b 100644
> --- a/drivers/clk/samsung/clk-exynos7.c
> +++ b/drivers/clk/samsung/clk-exynos7.c
> @@ -538,7 +538,8 @@ static const struct samsung_gate_clock top1_gate_clks[] 
> __initconst = {
> ENABLE_ACLK_TOP13, 28, CLK_SET_RATE_PARENT |
> CLK_IS_CRITICAL, 0),
> GATE(CLK_ACLK_FSYS1_200, "aclk_fsys1_200", "dout_aclk_fsys1_200",
> -   ENABLE_ACLK_TOP13, 24, CLK_SET_RATE_PARENT, 0),
> +   ENABLE_ACLK_TOP13, 24, CLK_SET_RATE_PARENT |
> +   CLK_IS_CRITICAL, 0),
>  

Please put a comment in the code why a clk is critical.


Re: [PATCH v3 0/8] net: macb: add support for sama7g5

2020-12-17 Thread Nicolas Ferre

On 09/12/2020 at 14:03, Claudiu Beznea wrote:

Hi,

This series adds support for SAMA7G5 Ethernet interfaces: one 10/100Mbps
and one 1Gbps interfaces.

Along with it I also included a fix to disable clocks for SiFive FU540-C000
on failure path of fu540_c000_clk_init().

Thank you,
Claudiu Beznea

Changed in v3:
- use clk_bulk_disable_unprepare in patch 3/8
- corrected clang compilation warning in patch 3/8
- revert changes in macb_clk_init() in patch 3/8

Changes in v2:
- introduced patch "net: macb: add function to disable all macb clocks" and
   update patch "net: macb: unprepare clocks in case of failure" accordingly
- collected tags

Claudiu Beznea (8):
   net: macb: add userio bits as platform configuration
   net: macb: add capability to not set the clock rate
   net: macb: add function to disable all macb clocks
   net: macb: unprepare clocks in case of failure
   dt-bindings: add documentation for sama7g5 ethernet interface
   dt-bindings: add documentation for sama7g5 gigabit ethernet interface
   net: macb: add support for sama7g5 gem interface
   net: macb: add support for sama7g5 emac interface


For the whole series:
Acked-by: Nicolas Ferre 

Thanks Claudiu, best regards,
  Nicolas


  Documentation/devicetree/bindings/net/macb.txt |   2 +
  drivers/net/ethernet/cadence/macb.h|  11 ++
  drivers/net/ethernet/cadence/macb_main.c   | 134 ++---
  3 files changed, 111 insertions(+), 36 deletions(-)




--
Nicolas Ferre


Re: [PATCH v1 ] ALSA: core: memalloc: add page alignment for iram

2020-12-17 Thread Takashi Iwai
On Thu, 17 Dec 2020 10:55:42 +0100,
Takashi Iwai wrote:
> 
> On Thu, 17 Dec 2020 10:43:45 +0100,
> Lars-Peter Clausen wrote:
> > 
> > On 12/17/20 5:15 PM, Robin Gong wrote:
> > > Since mmap for userspace is based on page alignment, add page alignment
> > > for iram alloc from pool, otherwise, some good data located in the same
> > > page of dmab->area maybe touched wrongly by userspace like pulseaudio.
> > >
> > I wonder, do we also have to align size to be a multiple of PAGE_SIZE
> > to avoid leaking unrelated data?
> 
> Hm, a good question.  Basically the PCM buffer size itself shouldn't
> be influenced by that (i.e. no hw-constraint or such is needed), but
> the padding should be cleared indeed.  I somehow left those to the
> allocator side, but maybe it's safer to clear the whole buffer in
> sound/core/memalloc.c commonly.

That said, something like below (totally untested).
We might pass the pass-aligned size to dmab->bytes field instead of
keeping the original value, too.


Takashi

---
--- a/sound/core/memalloc.c
+++ b/sound/core/memalloc.c
@@ -126,6 +126,7 @@ static inline gfp_t snd_mem_get_gfp_flags(const struct 
device *dev,
 int snd_dma_alloc_pages(int type, struct device *device, size_t size,
struct snd_dma_buffer *dmab)
 {
+   size_t orig_size = size;
gfp_t gfp;
 
if (WARN_ON(!size))
@@ -133,6 +134,7 @@ int snd_dma_alloc_pages(int type, struct device *device, 
size_t size,
if (WARN_ON(!dmab))
return -ENXIO;
 
+   size = PAGE_ALIGN(size);
dmab->dev.type = type;
dmab->dev.dev = device;
dmab->bytes = 0;
@@ -177,7 +179,8 @@ int snd_dma_alloc_pages(int type, struct device *device, 
size_t size,
}
if (! dmab->area)
return -ENOMEM;
-   dmab->bytes = size;
+   memset(dmab->area, 0, size);
+   dmab->bytes = orig_size;
return 0;
 }
 EXPORT_SYMBOL(snd_dma_alloc_pages);


Re: [PATCH v2 0/6] kernfs: proposed locking and concurrency improvement

2020-12-17 Thread Ian Kent
On Thu, 2020-12-17 at 16:54 +0800, Fox Chen wrote:
> On Thu, Dec 17, 2020 at 12:46 PM Ian Kent  wrote:
> > On Tue, 2020-12-15 at 20:59 +0800, Ian Kent wrote:
> > > On Tue, 2020-12-15 at 16:33 +0800, Fox Chen wrote:
> > > > On Mon, Dec 14, 2020 at 9:30 PM Ian Kent 
> > > > wrote:
> > > > > On Mon, 2020-12-14 at 14:14 +0800, Fox Chen wrote:
> > > > > > On Sun, Dec 13, 2020 at 11:46 AM Ian Kent  > > > > > >
> > > > > > wrote:
> > > > > > > On Fri, 2020-12-11 at 10:17 +0800, Ian Kent wrote:
> > > > > > > > On Fri, 2020-12-11 at 10:01 +0800, Ian Kent wrote:
> > > > > > > > > > For the patches, there is a mutex_lock in kn-
> > > > > > > > > > > attr_mutex,
> > > > > > > > > > as
> > > > > > > > > > Tejun
> > > > > > > > > > mentioned here
> > > > > > > > > > (
> > > > > > > > > > https://lore.kernel.org/lkml/x8fe0cmu+aq1g...@mtj.duckdns.org/
> > > > > > > > > > ),
> > > > > > > > > > maybe a global
> > > > > > > > > > rwsem for kn->iattr will be better??
> > > > > > > > > 
> > > > > > > > > I wasn't sure about that, IIRC a spin lock could be
> > > > > > > > > used
> > > > > > > > > around
> > > > > > > > > the
> > > > > > > > > initial check and checked again at the end which
> > > > > > > > > would
> > > > > > > > > probably
> > > > > > > > > have
> > > > > > > > > been much faster but much less conservative and a bit
> > > > > > > > > more
> > > > > > > > > ugly
> > > > > > > > > so
> > > > > > > > > I just went the conservative path since there was so
> > > > > > > > > much
> > > > > > > > > change
> > > > > > > > > already.
> > > > > > > > 
> > > > > > > > Sorry, I hadn't looked at Tejun's reply yet and TBH
> > > > > > > > didn't
> > > > > > > > remember
> > > > > > > > it.
> > > > > > > > 
> > > > > > > > Based on what Tejun said it sounds like that needs
> > > > > > > > work.
> > > > > > > 
> > > > > > > Those attribute handling patches were meant to allow
> > > > > > > taking
> > > > > > > the
> > > > > > > rw
> > > > > > > sem read lock instead of the write lock for
> > > > > > > kernfs_refresh_inode()
> > > > > > > updates, with the added locking to protect the inode
> > > > > > > attributes
> > > > > > > update since it's called from the VFS both with and
> > > > > > > without
> > > > > > > the
> > > > > > > inode lock.
> > > > > > 
> > > > > > Oh, understood. I was asking also because lock on kn-
> > > > > > > attr_mutex
> > > > > > drags
> > > > > > concurrent performance.
> > > > > > 
> > > > > > > Looking around it looks like kernfs_iattrs() is called
> > > > > > > from
> > > > > > > multiple
> > > > > > > places without a node database lock at all.
> > > > > > > 
> > > > > > > I'm thinking that, to keep my proposed change straight
> > > > > > > forward
> > > > > > > and on topic, I should just leave kernfs_refresh_inode()
> > > > > > > taking
> > > > > > > the node db write lock for now and consider the
> > > > > > > attributes
> > > > > > > handling
> > > > > > > as a separate change. Once that's done we could
> > > > > > > reconsider
> > > > > > > what's
> > > > > > > needed to use the node db read lock in
> > > > > > > kernfs_refresh_inode().
> > > > > > 
> > > > > > You meant taking write lock of kernfs_rwsem for
> > > > > > kernfs_refresh_inode()??
> > > > > > It may be a lot slower in my benchmark, let me test it.
> > > > > 
> > > > > Yes, but make sure the write lock of kernfs_rwsem is being
> > > > > taken
> > > > > not the read lock.
> > > > > 
> > > > > That's a mistake I had initially?
> > > > > 
> > > > > Still, that attributes handling is, I think, sufficient to
> > > > > warrant
> > > > > a separate change since it looks like it might need work, the
> > > > > kernfs
> > > > > node db probably should be kept stable for those attribute
> > > > > updates
> > > > > but equally the existence of an instantiated dentry might
> > > > > mitigate
> > > > > the it.
> > > > > 
> > > > > Some people might just know whether it's ok or not but I
> > > > > would
> > > > > like
> > > > > to check the callers to work out what's going on.
> > > > > 
> > > > > In any case it's academic if GCH isn't willing to consider
> > > > > the
> > > > > series
> > > > > for review and possible merge.
> > > > > 
> > > > Hi Ian
> > > > 
> > > > I removed kn->attr_mutex and changed read lock to write lock
> > > > for
> > > > kernfs_refresh_inode
> > > > 
> > > > down_write(&kernfs_rwsem);
> > > > kernfs_refresh_inode(kn, inode);
> > > > up_write(&kernfs_rwsem);
> > > > 
> > > > 
> > > > Unfortunate, changes in this way make things worse,  my
> > > > benchmark
> > > > runs
> > > > 100% slower than upstream sysfs.  :(
> > > > open+read+close a sysfs file concurrently took 1000us.
> > > > (Currently,
> > > > sysfs with a big mutex kernfs_mutex only takes ~500us
> > > > for one open+read+close operation concurrently)
> > > 
> > > Right, so it does need attention nowish.
> > > 
> > > I'll have a look at it in a while, I really need to get a new
> > > autofs
> > > release out, and there are quite a few changes, and testing 

Re: [RFC PATCH 7/8] crypto: x86/aes-kl - Support AES algorithm using Key Locker instructions

2020-12-17 Thread Ard Biesheuvel
Hello Chang,

On Wed, 16 Dec 2020 at 18:47, Chang S. Bae  wrote:
>
> Key Locker (KL) is Intel's new security feature that protects the AES key
> at the time of data transformation. New AES SIMD instructions -- as a
> successor of Intel's AES-NI -- are provided to encode an AES key and
> reference it for the AES algorithm.
>
> New instructions support 128/256-bit keys. While it is not desirable to
> receive any 192-bit key, AES-NI instructions are taken to serve this size.
>
> New instructions are operational in both 32-/64-bit modes.
>
> Add a set of new macros for the new instructions so that no new binutils
> version is required.
>
> Implemented methods are for a single block as well as ECB, CBC, CTR, and
> XTS modes. The methods are not compatible with other AES implementations as
> accessing an encrypted key instead of the normal AES key.
>
> setkey() call encodes an AES key. User may displace the AES key once
> encoded, as encrypt()/decrypt() methods do not need the key.
>
> Most C code follows the AES-NI implementation. It has higher priority than
> the AES-NI as providing key protection.
>
> Signed-off-by: Chang S. Bae 
> Cc: Herbert Xu 
> Cc: x...@kernel.org
> Cc: linux-cry...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> ---
>  arch/x86/crypto/Makefile   |   3 +
>  arch/x86/crypto/aeskl-intel_asm.S  | 881 +
>  arch/x86/crypto/aeskl-intel_glue.c | 697 +++
>  arch/x86/include/asm/inst.h| 201 +++
>  crypto/Kconfig |  28 +
>  5 files changed, 1810 insertions(+)

We will need to refactor this - cloning the entire driver and just
replacing aes-ni with aes-kl is a maintenance nightmare.

Please refer to the arm64 tree for an example how to combine chaining
mode routines implemented in assembler with different implementations
of the core AES transforms (aes-modes.S is combined with either
aes-ce.S or aes-neon.S to produce two different drivers)

...
> diff --git a/arch/x86/crypto/aeskl-intel_glue.c 
> b/arch/x86/crypto/aeskl-intel_glue.c
> new file mode 100644
> index ..9e3f900ad4af
> --- /dev/null
> +++ b/arch/x86/crypto/aeskl-intel_glue.c
> @@ -0,0 +1,697 @@
...
> +static void aeskl_encrypt(struct crypto_tfm *tfm, u8 *dst, const u8 *src)
> +{
> +   struct crypto_aes_ctx *ctx = aes_ctx(crypto_tfm_ctx(tfm));
> +   int err = 0;
> +
> +   if (!crypto_simd_usable())
> +   return;
> +

It is clear that AES-KL cannot be handled by a fallback algorithm,
given that the key is no longer available. But that doesn't mean that
you can just give up like this.

This basically implies that we cannot expose the cipher interface at
all, and so AES-KL can only be used by callers that use the
asynchronous interface, which rules out 802.11, s/w kTLS, macsec and
kerberos.

This ties in to a related discussion that is going on about when to
allow kernel mode SIMD. I am currently investigating whether we can
change the rules a bit so that crypto_simd_usable() is guaranteed to
be true.





> +   kernel_fpu_begin();
> +   /* 192-bit key not supported, fall back to AES-NI.*/
> +   if (unlikely(ctx->key_length == AES_KEYSIZE_192))
> +   aesni_enc(ctx, dst, src);
> +   else
> +   err = __aeskl_enc1(ctx, dst, src);
> +   kernel_fpu_end();
> +
> +   if (err)
> +   pr_err("aes-kl (encrypt): invalid handle\n");
> +}
> +
> +static void aeskl_decrypt(struct crypto_tfm *tfm, u8 *dst, const u8 *src)
> +{
> +   struct crypto_aes_ctx *ctx = aes_ctx(crypto_tfm_ctx(tfm));
> +   int err = 0;
> +
> +   if (!crypto_simd_usable())
> +   return;
> +
> +   kernel_fpu_begin();
> +   /* 192-bit key not supported, fall back to AES-NI */
> +   if (unlikely(ctx->key_length == AES_KEYSIZE_192))
> +   aesni_dec(ctx, dst, src);
> +   else
> +   err = __aeskl_dec1(ctx, dst, src);
> +   kernel_fpu_end();
> +
> +   if (err)
> +   pr_err("aes-kl (encrypt): invalid handle\n");
> +}
> +
> +static int aeskl_skcipher_setkey(struct crypto_skcipher *tfm, const u8 *key,
> +unsigned int len)
> +{
> +   return aeskl_setkey_common(crypto_skcipher_tfm(tfm),
> +  crypto_skcipher_ctx(tfm), key, len);
> +}
> +
> +static int ecb_encrypt(struct skcipher_request *req)
> +{
> +   struct crypto_skcipher *tfm;
> +   struct crypto_aes_ctx *ctx;
> +   struct skcipher_walk walk;
> +   unsigned int nbytes;
> +   int err;
> +
> +   tfm = crypto_skcipher_reqtfm(req);
> +   ctx = aes_ctx(crypto_skcipher_ctx(tfm));
> +
> +   err = skcipher_walk_virt(&walk, req, true);
> +   if (err)
> +   return err;
> +
> +   while ((nbytes = walk.nbytes)) {
> +   unsigned int len = nbytes & AES_BLOCK_MASK;
> +   const u8 *src = walk.src.virt.addr;
> +   u8 *dst = walk.dst.virt.ad

RE: [PATCH v6] drm/bridge: add it6505 driver

2020-12-17 Thread allen.chen
Hi Mathieu

For google reference design(mt8183+it6505), the maximum 95000kHz is depends on 
mt8183 requirement.

-Original Message-
From: Mathieu Tournier [mailto:mathieutourn...@gmail.com] 
Sent: Thursday, December 17, 2020 2:47 AM
To: Allen Chen (陳柏宇)
Cc: Jau-Chih Tseng (曾昭智); Kenneth Hung (洪家倫); 
laurent.pinch...@ideasonboard.com; a.ha...@samsung.com; airl...@linux.ie; 
dri-de...@lists.freedesktop.org; Hermes Wu (吳佳宏); jernej.skra...@siol.net; 
jitao@mediatek.com; jo...@kwiboo.se; linux-arm-ker...@lists.infradead.org; 
linux-kernel@vger.kernel.org; linux-media...@lists.infradead.org; 
matthias@gmail.com; narmstr...@baylibre.com; pih...@chromium.org; 
yl...@google.com
Subject: Re: [PATCH v6] drm/bridge: add it6505 driver

Hi Allen.

As it6505 is compatible with DisplayPort 1.1a,
Should DPI_PIXEL_CLK_MAX be 165 000 instead of 95 000 khz ?
This would permit 1080p support, as it may be supported.

Mathieu


Re: [PATCH v3] lib: stackdepot: Add support to configure STACK_HASH_SIZE

2020-12-17 Thread Dmitry Vyukov
On Thu, Dec 17, 2020 at 6:42 AM Vijayanand Jitta  wrote:
>
> On 12/16/2020 7:04 PM, Alexander Potapenko wrote:
> >>> To reiterate, I think you don't need a tunable stack_hash_order
> >>> parameter if the only use case is to disable the stack depot.
> >>> Maybe it is enough to just add a boolean flag?
> >>
> >> There are multiple users of stackdepot they might still want to use
> >> stack depot but with a lower memory footprint instead of MAX_SIZE
> >> so, a configurable size might help here ?
> >
> > Can you provide an example of a use case in which the user wants to
> > use the stack depot of a smaller size without disabling it completely,
> > and that size cannot be configured statically?
> > As far as I understand, for the page owner example you gave it's
> > sufficient to provide a switch that can disable the stack depot if
> > page_owner=off.
> >
> There are two use cases here,
>
> 1. We don't want to consume memory when page_owner=off ,boolean flag
> would work here.
>
> 2. We would want to enable page_owner on low ram devices but we don't
> want stack depot to consume 8 MB of memory, so for this case we would
> need a configurable stack_hash_size so that we can still use page_owner
> with lower memory consumption.
>
> So, a configurable stack_hash_size would work for both these use cases,
> we can set it to '0' for first case and set the required size for the
> second case.
>
> >>> Or even go further and disable the stack depot in the same place that
> >>> disables page owner, as the user probably doesn't want to set two
> >>> flags instead of one?
> >>>
> >>
> >> Since, page owner is not the only user of stack depot we can't take that
> >> decision of disabling stack depot if page owner is disabled.
> >
> > Agreed, but if multiple subsystems want to use stackdepot together, it
> > is even harder to estimate the total memory consumption.
> > How likely is it that none of them will need MAX_SIZE?
> >
>  Minchan,
>  This should be fine right ? Do you see any issue with disabling
>  stack depot completely ?

+kasan-dev


Re: [PATCH v4 3/6] clk: ralink: add clock driver for mt7621 SoC

2020-12-17 Thread Sergio Paracuellos
On Thu, Dec 17, 2020 at 11:12 AM Stephen Boyd  wrote:
>
> Quoting Sergio Paracuellos (2020-12-17 01:54:18)
> >
> > On Thu, Dec 17, 2020 at 10:09 AM Stephen Boyd  wrote:
> > >
> > > Quoting Sergio Paracuellos (2020-11-22 01:55:53)
> > > > diff --git a/drivers/clk/ralink/Makefile b/drivers/clk/ralink/Makefile
> > > > new file mode 100644
> > > > index ..cf6f9216379d
> > > > --- /dev/null
> > > > +++ b/drivers/clk/ralink/Makefile
> > > > @@ -0,0 +1,2 @@
> > > > +# SPDX-License-Identifier: GPL-2.0
> > > > +obj-$(CONFIG_CLK_MT7621) += clk-mt7621.o
> > > > diff --git a/drivers/clk/ralink/clk-mt7621.c 
> > > > b/drivers/clk/ralink/clk-mt7621.c
> > > > new file mode 100644
> > > > index ..4e929f13fe7c
> > > > --- /dev/null
> > > > +++ b/drivers/clk/ralink/clk-mt7621.c
> > > > @@ -0,0 +1,435 @@
> > > > +// SPDX-License-Identifier: GPL-2.0
> > > > +/*
> > > > + * Mediatek MT7621 Clock Driver
> > > > + * Author: Sergio Paracuellos 
> > > > + */
> > > > +
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > >
> > > Is it possible to drop this include? Doing so would make this portable
> > > and compilable on more architectures so us cross compilers can check
> > > build stuff and make changes easily.
> >
> > No, this is not possible. This old arch makes some global functions
> > there to properly access different registers in the palmbus. It is not
> > also well documented so it is really difficult to make something
> > better with this.
> > This is needed to use 'rt_memc_r32'
> > (arch/mips/include/asm/mach-ralink/ralink_regs.h) for reading
> > MEMC_REG_CPU_PLL.
> >
> > This is a not documented register and is not in the syscon related
> > part and we need it to derive the clock frequency for the XTAL clock.
>
> Ok.
>
> > > > +static int mt7621_gate_ops_init(struct device_node *np,
> > > > +struct mt7621_gate *sclk)
> > > > +{
> > > > +   struct clk_init_data init = {
> > > > +   .flags = CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED,
> > >
> > > Why ignore unused? Are they CLK_IS_CRITICAL? Can they be enabled at
> > > driver probe instead of here? Or left out of the kernel entirely if they
> > > shouldn't be turned off?
> >
> > Because all the platform drivers are not changed to use this gates yet
> > and all gates are enabled by default (related registers are set to all
> > ones),  kernel disables all the stuff because they are not being
> > referenced, but yes, you are right, I think I can call
> > clk_prepare_enable for all of them at init time and avoid this
> > 'CLK_IGNORE_UNUSED' flag to don't break anything of the current other
> > upstream code.
>
> Does something crash if they're turned off? We have CLK_IS_CRITICAL for
> that. The CLK_IGNORE_UNUSED flag is sort of deprecated now.

Well, as drivers are not getting into account gates and not referenced
real hw bits are disabled by kernel because nobody requested them so
for example my uart gets down and cannot really see anything :). I
think call to 'clk_prepare_enable' should be enough since by default
all of them are setting up in registers, so call that will also
reference them...

>
> > > > +
> > > > +#define CLK_BASE(_name, _parent, _recalc) {
> > > > \
> > > > +   .init = &(struct clk_init_data) {   
> > > > \
> > > > +   .name = _name,  
> > > > \
> > > > +   .ops = &(const struct clk_ops) {
> > > > \
> > > > +   .recalc_rate = _recalc, 
> > > > \
> > > > +   },  
> > > > \
> > > > +   .parent_names = (const char *const[]) { _parent },  
> > > > \
> > >
> > > Please use clk_parent_data instead
> >
> > parent can also be NULL here and num_parents zero, but I will search
> > what do you really mean with this 'clk_parent_data' :).
>
> Heh, 'git grep clk_parent_data -- drivers/clk/' should give some clues.

Thanks, will do!

>
> > > > +free_clk_prov:
> > > > +   kfree(clk_prov);
> > > > +}
> > > > +
> > > > +CLK_OF_DECLARE(mt7621_clk, "mediatek,mt7621-clk", mt7621_clk_init);
> > >
> > > Any reason to use this vs. a platform driver?
> >
> > We need clocks available in 'plat_time_init' before setting up the
> > timer for the GIC, so to maintain all the clock driver in a simple
> > file and using only one device tree node and no separate the gates
> > into another platform driver, I think this is the only way to go, but
> > please correct me if I am wrong.
>
> We can register the few clks like that early with
> CLK_OF_DECLARE_DRIVER() and then have a platform driver register the
> rest of the clks that aren't required early. This lets us hook into the
> driver framework better while still getting those few clks to turn on
> early enough for 

Re: [PATCH v1] HID: make arrays usage and value to be the same

2020-12-17 Thread Jiri Kosina
On Mon, 14 Dec 2020, Will McVicker wrote:

> > The HID subsystem allows an "HID report field" to have a different
> > number of "values" and "usages" when it is allocated. When a field
> > struct is created, the size of the usage array is guaranteed to be at
> > least as large as the values array, but it may be larger. This leads to
> > a potential out-of-bounds write in
> > __hidinput_change_resolution_multipliers() and an out-of-bounds read in
> > hidinput_count_leds().
> > 
> > To fix this, let's make sure that both the usage and value arrays are
> > the same size.
> > 
> > Signed-off-by: Will McVicker 
> > ---
> >  drivers/hid/hid-core.c | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
> > index 56172fe6995c..8a8b2b982f83 100644
> > --- a/drivers/hid/hid-core.c
> > +++ b/drivers/hid/hid-core.c
> > @@ -90,7 +90,7 @@ EXPORT_SYMBOL_GPL(hid_register_report);
> >   * Register a new field for this report.
> >   */
> >  
> > -static struct hid_field *hid_register_field(struct hid_report *report, 
> > unsigned usages, unsigned values)
> > +static struct hid_field *hid_register_field(struct hid_report *report, 
> > unsigned usages)
> >  {
> > struct hid_field *field;
> >  
> > @@ -101,7 +101,7 @@ static struct hid_field *hid_register_field(struct 
> > hid_report *report, unsigned
> >  
> > field = kzalloc((sizeof(struct hid_field) +
> >  usages * sizeof(struct hid_usage) +
> > -values * sizeof(unsigned)), GFP_KERNEL);
> > +usages * sizeof(unsigned)), GFP_KERNEL);
> > if (!field)
> > return NULL;
> >  
> > @@ -300,7 +300,7 @@ static int hid_add_field(struct hid_parser *parser, 
> > unsigned report_type, unsign
> > usages = max_t(unsigned, parser->local.usage_index,
> >  parser->global.report_count);
> >  
> > -   field = hid_register_field(report, usages, parser->global.report_count);
> > +   field = hid_register_field(report, usages);
> > if (!field)
> > return 0;
> >  
> > -- 
> > 2.29.2.576.ga3fc446d84-goog
> > 
> 
> Hi Jiri and Benjamin,
> 
> This is a friendly reminder in case this got lost in your inbox.

Hi Will,

I am planning to merge it once the merge window is over.

-- 
Jiri Kosina
SUSE Labs



Re: [PATCH v3] lib: stackdepot: Add support to configure STACK_HASH_SIZE

2020-12-17 Thread Dmitry Vyukov
On Thu, Dec 10, 2020 at 6:04 AM  wrote:
>
> From: Yogesh Lal 
>
> Add a kernel parameter stack_hash_order to configure STACK_HASH_SIZE.
>
> Aim is to have configurable value for STACK_HASH_SIZE, so that one
> can configure it depending on usecase there by reducing the static
> memory overhead.
>
> One example is of Page Owner, default value of STACK_HASH_SIZE lead
> stack depot to consume 8MB of static memory. Making it configurable
> and use lower value helps to enable features like CONFIG_PAGE_OWNER
> without any significant overhead.
>
> Suggested-by: Minchan Kim 
> Signed-off-by: Yogesh Lal 
> Signed-off-by: Vijayanand Jitta 
> ---
>  lib/stackdepot.c | 31 +++
>  1 file changed, 27 insertions(+), 4 deletions(-)
>
> diff --git a/lib/stackdepot.c b/lib/stackdepot.c
> index 81c69c0..e0eebfd 100644
> --- a/lib/stackdepot.c
> +++ b/lib/stackdepot.c
> @@ -30,6 +30,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #define DEPOT_STACK_BITS (sizeof(depot_stack_handle_t) * 8)
>
> @@ -141,14 +142,36 @@ static struct stack_record *depot_alloc_stack(unsigned 
> long *entries, int size,
> return stack;
>  }
>
> -#define STACK_HASH_ORDER 20
> -#define STACK_HASH_SIZE (1L << STACK_HASH_ORDER)
> +#define MAX_STACK_HASH_ORDER 20
> +#define MAX_STACK_HASH_SIZE (1L << MAX_STACK_HASH_ORDER)
> +#define STACK_HASH_SIZE (1L << stack_hash_order)
>  #define STACK_HASH_MASK (STACK_HASH_SIZE - 1)
>  #define STACK_HASH_SEED 0x9747b28c
>
> -static struct stack_record *stack_table[STACK_HASH_SIZE] = {
> -   [0 ...  STACK_HASH_SIZE - 1] = NULL
> +static unsigned int stack_hash_order = 20;
> +static struct stack_record *stack_table_def[MAX_STACK_HASH_SIZE] __initdata 
> = {
> +   [0 ...  MAX_STACK_HASH_SIZE - 1] = NULL
>  };
> +static struct stack_record **stack_table __refdata = stack_table_def;
> +
> +static int __init setup_stack_hash_order(char *str)
> +{
> +   kstrtouint(str, 0, &stack_hash_order);
> +   if (stack_hash_order > MAX_STACK_HASH_ORDER)
> +   stack_hash_order = MAX_STACK_HASH_ORDER;
> +   return 0;
> +}
> +early_param("stack_hash_order", setup_stack_hash_order);
> +
> +static int __init init_stackdepot(void)
> +{
> +   size_t size = (STACK_HASH_SIZE * sizeof(struct stack_record *));
> +
> +   stack_table = vmalloc(size);
> +   memcpy(stack_table, stack_table_def, size);

Can interrupts happen at this point in time? If yes, they can
use/modify stack_table_def concurrently.

> +   return 0;
> +}
> +early_initcall(init_stackdepot);
>
>  /* Calculate hash for a stack */
>  static inline u32 hash_stack(unsigned long *entries, unsigned int size)
> --
> 2.7.4
> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
> Code Aurora Forum, hosted by The Linux Foundation


Re: [PATCH 1/1] dt-bindings: clock: imx8qxp-lpcg: eliminate yamllint warnings

2020-12-17 Thread Stephen Boyd
Quoting Zhen Lei (2020-12-06 20:55:27)
> Eliminate the following yamllint warnings:
> ./Documentation/devicetree/bindings/clock/imx8qxp-lpcg.yaml
> :32:13:[warning] wrong indentation: expected 14 but found 12 (indentation)
> :35:9: [warning] wrong indentation: expected 10 but found 8 (indentation)
> 
> Signed-off-by: Zhen Lei 
> ---

Reviewed-by: Stephen Boyd 


Re: [PATCH v3] lib: stackdepot: Add support to configure STACK_HASH_SIZE

2020-12-17 Thread Dmitry Vyukov
On Thu, Dec 17, 2020 at 11:25 AM Dmitry Vyukov  wrote:
>
> On Thu, Dec 10, 2020 at 6:04 AM  wrote:
> >
> > From: Yogesh Lal 
> >
> > Add a kernel parameter stack_hash_order to configure STACK_HASH_SIZE.
> >
> > Aim is to have configurable value for STACK_HASH_SIZE, so that one
> > can configure it depending on usecase there by reducing the static
> > memory overhead.
> >
> > One example is of Page Owner, default value of STACK_HASH_SIZE lead
> > stack depot to consume 8MB of static memory. Making it configurable
> > and use lower value helps to enable features like CONFIG_PAGE_OWNER
> > without any significant overhead.
> >
> > Suggested-by: Minchan Kim 
> > Signed-off-by: Yogesh Lal 
> > Signed-off-by: Vijayanand Jitta 
> > ---
> >  lib/stackdepot.c | 31 +++
> >  1 file changed, 27 insertions(+), 4 deletions(-)
> >
> > diff --git a/lib/stackdepot.c b/lib/stackdepot.c
> > index 81c69c0..e0eebfd 100644
> > --- a/lib/stackdepot.c
> > +++ b/lib/stackdepot.c
> > @@ -30,6 +30,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >
> >  #define DEPOT_STACK_BITS (sizeof(depot_stack_handle_t) * 8)
> >
> > @@ -141,14 +142,36 @@ static struct stack_record 
> > *depot_alloc_stack(unsigned long *entries, int size,
> > return stack;
> >  }
> >
> > -#define STACK_HASH_ORDER 20
> > -#define STACK_HASH_SIZE (1L << STACK_HASH_ORDER)
> > +#define MAX_STACK_HASH_ORDER 20
> > +#define MAX_STACK_HASH_SIZE (1L << MAX_STACK_HASH_ORDER)
> > +#define STACK_HASH_SIZE (1L << stack_hash_order)
> >  #define STACK_HASH_MASK (STACK_HASH_SIZE - 1)
> >  #define STACK_HASH_SEED 0x9747b28c
> >
> > -static struct stack_record *stack_table[STACK_HASH_SIZE] = {
> > -   [0 ...  STACK_HASH_SIZE - 1] = NULL
> > +static unsigned int stack_hash_order = 20;
> > +static struct stack_record *stack_table_def[MAX_STACK_HASH_SIZE] 
> > __initdata = {
> > +   [0 ...  MAX_STACK_HASH_SIZE - 1] = NULL
> >  };
> > +static struct stack_record **stack_table __refdata = stack_table_def;
> > +
> > +static int __init setup_stack_hash_order(char *str)
> > +{
> > +   kstrtouint(str, 0, &stack_hash_order);
> > +   if (stack_hash_order > MAX_STACK_HASH_ORDER)

Can interrupts happen here?

> > +   stack_hash_order = MAX_STACK_HASH_ORDER;
> > +   return 0;
> > +}
> > +early_param("stack_hash_order", setup_stack_hash_order);
> > +
> > +static int __init init_stackdepot(void)
> > +{
> > +   size_t size = (STACK_HASH_SIZE * sizeof(struct stack_record *));
> > +
> > +   stack_table = vmalloc(size);
> > +   memcpy(stack_table, stack_table_def, size);
>
> Can interrupts happen at this point in time? If yes, they can
> use/modify stack_table_def concurrently.
>
> > +   return 0;
> > +}
> > +early_initcall(init_stackdepot);
> >
> >  /* Calculate hash for a stack */
> >  static inline u32 hash_stack(unsigned long *entries, unsigned int size)
> > --
> > 2.7.4
> > QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member 
> > of Code Aurora Forum, hosted by The Linux Foundation


Re: [PATCH 1/1] kasan: fix memory leak of kasan quarantine

2020-12-17 Thread Kuan-Ying Lee
On Tue, 2020-12-15 at 19:28 +0800, Kuan-Ying Lee wrote:
> When cpu is going offline, set q->offline as true
> and interrupt happened. The interrupt may call the
> quarantine_put. But quarantine_put do not free the
> the object. The object will cause memory leak.
> 
> Add qlink_free() to free the object.
> 
> Signed-off-by: Kuan-Ying Lee 
> Cc: Andrey Ryabinin 
> Cc: Alexander Potapenko 
> Cc: Dmitry Vyukov 
> Cc: Andrew Morton 
> Cc: Matthias Brugger 
> Cc: [5.10-]
> ---
>  mm/kasan/quarantine.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/mm/kasan/quarantine.c b/mm/kasan/quarantine.c
> index 0e3f8494628f..cac7c617df72 100644
> --- a/mm/kasan/quarantine.c
> +++ b/mm/kasan/quarantine.c
> @@ -191,6 +191,7 @@ void quarantine_put(struct kasan_free_meta *info, struct 
> kmem_cache *cache)
>  
>   q = this_cpu_ptr(&cpu_quarantine);
>   if (q->offline) {
> + qlink_free(&info->quarantine_link, cache);
>   local_irq_restore(flags);
>   return;
>   }

Sorry.

Please ignore this patch.

Thanks.


Re: [PATCH v9 11/11] mm/hugetlb: Optimize the code with the help of the compiler

2020-12-17 Thread Oscar Salvador
On Sun, Dec 13, 2020 at 11:45:34PM +0800, Muchun Song wrote:
>  static inline unsigned int free_vmemmap_pages_per_hpage(struct hstate *h)
>  {
> - return h->nr_free_vmemmap_pages;
> + return h->nr_free_vmemmap_pages && is_power_of_2(sizeof(struct page));

This is wrong as it will return either true or false, but not what we want:

static inline unsigned long free_vmemmap_pages_size_per_hpage(struct 
hstate *h)
{
return (unsigned long)free_vmemmap_pages_per_hpage(h) << 
PAGE_SHIFT;
}

the above will compute to 4096, which is wrong for obvious reasons.

-- 
Oscar Salvador
SUSE L3


Re: [PATCH v4 2/6] dt: bindings: add mt7621-clk device tree binding documentation

2020-12-17 Thread Stephen Boyd
Quoting Sergio Paracuellos (2020-12-17 02:14:10)
> On Thu, Dec 17, 2020 at 11:07 AM Stephen Boyd  wrote:
> >
> > Quoting Sergio Paracuellos (2020-12-17 02:01:39)
> > >
> > > On Thu, Dec 17, 2020 at 9:58 AM Stephen Boyd  wrote:
> > > >
> > > > Quoting Sergio Paracuellos (2020-11-22 01:55:52)
> > > >
> > > > > diff --git 
> > > > > a/Documentation/devicetree/bindings/clock/mediatek,mt7621-clk.yaml 
> > > > > b/Documentation/devicetree/bindings/clock/mediatek,mt7621-clk.yaml
> > > > > new file mode 100644
> > > > > index ..6aca4c1a4a46
> > > > > --- /dev/null
> > > > > +++ b/Documentation/devicetree/bindings/clock/mediatek,mt7621-clk.yaml
> > > >
> > > > > +  compatible = "mediatek,mt7621-sysc", "syscon";
> > > > > +  reg = <0x0 0x100>;
> > > > > +
> > > > > +  pll {
> > > >
> > > > clock-controller? Why can't the parent device be the clk provider and
> > > > have #clock-cells?
> > > >
> > >
> > > I don't get your point, sorry. Can you please explain this a bit more
> > > or point to me to an example to understand the real meaning of this?
> >
> > It looks like this is a made up child node of syscon so that a driver
> > can probe in the kernel. It would be more DT friendly to create a
> > platform device from the parent node's driver, or just register the clks
> > with the framework directly in that driver.
> 
> We cannot create a platform device because we need clocks available in
> 'plat_time_init' before setting up the timer for the GIC.
> The only way I see to avoid this syscon and having this as a child
> node is to use architecture operations in
> 'arch/mips/include/asm/mach-ralink/ralink_regs.h'
> instead of getting a phandle using the regmap is being currently used...

Can that be done with

CLK_OF_DECLARE_DRIVER("mediatek,mt7621-sysc", my_timer_clk_init)

? Is the syscon used anywhere besides by the clk driver?


Re: [PATCH v2 0/4] Add some clocks support for i.MX8qxp DC0/MIPI-LVDS subsystems

2020-12-17 Thread Stephen Boyd
Quoting Liu Ying (2020-12-01 21:33:35)
> This patch set adds some SCU clocks support for i.MX8qxp DC0/MIPI-LVDS
> subsystems.
> 
> With this patch set, some basic clocks for i.MX8qxp LVDS displays can be got
> by drivers.
> 
> v1->v2:
> * Drop LPCG clocks as they can be registered directly in an in-tree new
>   DT binding way.
> * Add DC0 bypass clocks support.
> * Correct the way to register DC0 display clocks.
> * Trivial tweak.

Looks OK to me. I assume Shawn will pick them up.

> 
> Liu Ying (4):
>   clk: imx: clk-imx8qxp: Add SCU clocks support for DC0 PLL clocks
>   clk: imx: clk-imx8qxp: Add SCU clocks support for DC0 bypass clocks
>   clk: imx: clk-imx8qxp: Register DC0 display clocks with imx_clk_scu2()
>   clk: imx: clk-imx8qxp: Add some SCU clocks support for MIPI-LVDS
> subsystems
> 
>  drivers/clk/imx/clk-imx8qxp.c  | 26 --
>  include/dt-bindings/clock/imx8-clock.h |  2 ++
>  2 files changed, 26 insertions(+), 2 deletions(-)
> 
> -- 
> 2.7.4
>


Re: upstream boot error: UBSAN: null-ptr-deref in corrupted

2020-12-17 Thread Dmitry Vyukov
On Thu, Dec 17, 2020 at 11:14 AM syzbot
 wrote:
>
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:accefff5 Merge tag 'arm-soc-omap-genpd-5.11' of git://git...
> git tree:   upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=14567b7f50
> kernel config:  https://syzkaller.appspot.com/x/.config?x=1e6efc730c219bd4
> dashboard link: https://syzkaller.appspot.com/bug?extid=73d662376f16e2a7336d
> compiler:   clang version 11.0.0 
> (https://github.com/llvm/llvm-project.git 
> ca2dcbd030eadbf0aa9b660efe864ff08af6e18b)
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+73d662376f16e2a73...@syzkaller.appspotmail.com

+Kees

Not sure if it's related to UBSAN or not, but we didn't used to get
empty stack traces.
Either way syzbot can't boot the upstream kernel anymore.

> Linux version 5.10.0-syzkaller (syzkaller@syzkaller) (clang version 11.0.0 
> (https://github.com/llvm/llvm-project.git 
> ca2dcbd030eadbf0aa9b660efe864ff08af6e18b), GNU ld (GNU Binutils for Ubuntu) 
> 2.26.1) #0 SMP PREEMPT now
> Command line: BOOT_IMAGE=/vmlinuz root=/dev/sda1 console=ttyS0 
> earlyprintk=serial vsyscall=native oops=panic panic_on_warn=1 
> nmi_watchdog=panic panic=86400 net.ifnames=0 
> sysctl.kernel.hung_task_all_cpu_backtrace=1
> KERNEL supported cpus:
>   Intel GenuineIntel
>   AMD AuthenticAMD
> x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
> x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
> x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
> x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
> x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 
> 'standard' format.
> BIOS-provided physical RAM map:
> BIOS-e820: [mem 0x-0x0009fbff] usable
> BIOS-e820: [mem 0x0009fc00-0x0009] reserved
> BIOS-e820: [mem 0x000f-0x000f] reserved
> BIOS-e820: [mem 0x0010-0xbfffcfff] usable
> BIOS-e820: [mem 0xbfffd000-0xbfff] reserved
> BIOS-e820: [mem 0xfffbc000-0x] reserved
> BIOS-e820: [mem 0x0001-0x00023fff] usable
> printk: bootconsole [earlyser0] enabled
> ERROR: earlyprintk= earlyser already used
> ERROR: earlyprintk= earlyser already used
> ERROR: earlyprintk= earlyser already used
> nopcid: PCID feature disabled
> Malformed early option 'vsyscall'
> Malformed early option 'vsyscall'
> NX (Execute Disable) protection: active
> SMBIOS 2.4 present.
> DMI: Google Google Compute Engine/Google Compute Engine, BIOS Google 
> 01/01/2011
> Hypervisor detected: KVM
> kvm-clock: Using msrs 4b564d01 and 4b564d00
> kvm-clock: cpu 0, msr dde2001, primary cpu clock
> kvm-clock: using sched offset of 3478136367 cycles
> clocksource: kvm-clock: mask: 0x max_cycles: 0x1cd42e4dffb, 
> max_idle_ns: 881590591483 ns
> tsc: Detected 2300.000 MHz processor
> last_pfn = 0x24 max_arch_pfn = 0x4
> x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WP  UC- WT
> last_pfn = 0xbfffd max_arch_pfn = 0x4
> found SMP MP-table at [mem 0x000f25a0-0x000f25af]
> Using GB pages for direct mapping
> ACPI: Early table checksum verification disabled
> ACPI: RSDP 0x000F2320 14 (v00 Google)
> ACPI: RSDT 0xBFA0 38 (v01 Google GOOGRSDT 0001 GOOG 
> 0001)
> ACPI: FACP 0xB340 F4 (v02 Google GOOGFACP 0001 GOOG 
> 0001)
> 
> UBSAN: null-ptr-deref in drivers/acpi/acpica/tbfadt.c:459:37
> member access within null pointer of type 'struct acpi_table_fadt'
> CPU: 0 PID: 0 Comm: swapper Not tainted 5.10.0-syzkaller #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS 
> Google 01/01/2011
> Call Trace:
> 
> ACPI: DSDT 0xBFFFDA80 0018BA (v01 Google GOOGDSDT 0001 GOOG 
> 0001)
> ACPI: FACS 0xBFFFDA40 40
> ACPI: FACS 0xBFFFDA40 40
> ACPI: SRAT 0xBE70 C8 (v03 Google GOOGSRAT 0001 GOOG 
> 0001)
> ACPI: APIC 0xBDC0 76 (v05 Google GOOGAPIC 0001 GOOG 
> 0001)
> ACPI: SSDT 0xB440 000980 (v01 Google GOOGSSDT 0001 GOOG 
> 0001)
> ACPI: WAET 0xBE40 28 (v01 Google GOOGWAET 0001 GOOG 
> 0001)
> SRAT: PXM 0 -> APIC 0x00 -> Node 0
> SRAT: PXM 0 -> APIC 0x01 -> Node 0
> ACPI: SRAT: Node 0 PXM 0 [mem 0x-0x0009]
> ACPI: SRAT: Node 0 PXM 0 [mem 0x0010-0xbfff]
> ACPI: SRAT: Node 0 PXM 0 [mem 0x1-0x23fff]
> NUMA: Node 0 [mem 0x-0x0009] + [mem 0x0010-0xbfff] -> 
> [mem 0x-0xbfff]
> NUMA: Node 0 [mem 0x-0xbfff] + [mem 0x1-0x23fff] -> 
> [mem 0x-0x23fff]
> Faking node 0 at [mem 0x-0x

Re: [PATCH v4 2/6] dt: bindings: add mt7621-clk device tree binding documentation

2020-12-17 Thread Sergio Paracuellos
On Thu, Dec 17, 2020 at 11:32 AM Stephen Boyd  wrote:
>
> Quoting Sergio Paracuellos (2020-12-17 02:14:10)
> > On Thu, Dec 17, 2020 at 11:07 AM Stephen Boyd  wrote:
> > >
> > > Quoting Sergio Paracuellos (2020-12-17 02:01:39)
> > > >
> > > > On Thu, Dec 17, 2020 at 9:58 AM Stephen Boyd  wrote:
> > > > >
> > > > > Quoting Sergio Paracuellos (2020-11-22 01:55:52)
> > > > >
> > > > > > diff --git 
> > > > > > a/Documentation/devicetree/bindings/clock/mediatek,mt7621-clk.yaml 
> > > > > > b/Documentation/devicetree/bindings/clock/mediatek,mt7621-clk.yaml
> > > > > > new file mode 100644
> > > > > > index ..6aca4c1a4a46
> > > > > > --- /dev/null
> > > > > > +++ 
> > > > > > b/Documentation/devicetree/bindings/clock/mediatek,mt7621-clk.yaml
> > > > >
> > > > > > +  compatible = "mediatek,mt7621-sysc", "syscon";
> > > > > > +  reg = <0x0 0x100>;
> > > > > > +
> > > > > > +  pll {
> > > > >
> > > > > clock-controller? Why can't the parent device be the clk provider and
> > > > > have #clock-cells?
> > > > >
> > > >
> > > > I don't get your point, sorry. Can you please explain this a bit more
> > > > or point to me to an example to understand the real meaning of this?
> > >
> > > It looks like this is a made up child node of syscon so that a driver
> > > can probe in the kernel. It would be more DT friendly to create a
> > > platform device from the parent node's driver, or just register the clks
> > > with the framework directly in that driver.
> >
> > We cannot create a platform device because we need clocks available in
> > 'plat_time_init' before setting up the timer for the GIC.
> > The only way I see to avoid this syscon and having this as a child
> > node is to use architecture operations in
> > 'arch/mips/include/asm/mach-ralink/ralink_regs.h'
> > instead of getting a phandle using the regmap is being currently used...
>
> Can that be done with
>
> CLK_OF_DECLARE_DRIVER("mediatek,mt7621-sysc", my_timer_clk_init)
>
> ? Is the syscon used anywhere besides by the clk driver?

Yes, for example all the gates use them to access SYSC_REG_CLKCFG1 in
all of their 'mt7621_gate_ops' and also in all 'recalc_rate' functions
where SYSC_REG_SYSTEM_CONFIG0, is readed.


Re: [PATCH 2/3] x86/resctrl: Update PQR_ASSOC MSR synchronously when moving task to resource group

2020-12-17 Thread Valentin Schneider


On 16/12/20 18:26, Reinette Chatre wrote:
> Hi Valentin,
>> So that's part paranoia and part nonsense from my end - the contents of
>> smp_call() shouldn't matter here.
>>
>> If we distill the code to:
>>
>>tsk->closid = x;
>>
>>if (task_curr(tsk))
>>smp_call(...);
>>
>> It is somewhat far fetched, but AFAICT this can be compiled as:
>>
>>if (task_curr(tsk))
>>tsk->closid = x;
>>smp_call(...);
>>else
>>tsk->closid = x;
>>
>> IOW, there could be a sequence where the closid write is ordered *after*
>> the task_curr() read.
>
> Could you please elaborate why it would be an issue is the closid write
> is ordered after the task_curr() read? task_curr() does not depend on
> the closid.
>

IMO the 'task_curr()' check only makes sense if it happens *after* the
write, the logic being: 'closid/rmid has been written to, does the task now
need interrupting?'

In the above 'else' clause, task_curr() would need to be re-evaluated after
the write: the task wasn't current *before* the write, but nothing
guarantees this still holds *after* the write.

>> With
>>
>>tsk->closid = x;
>>
>>barrier();
>>
>>if (task_curr(tsk))
>>smp_call(...);
>>
>> that explicitely cannot happen.
>>
>
>
> Reinette


Re: [PATCH 02/18] arm64: dts: renesas: beacon kit: Fix choppy Bluetooth Audio

2020-12-17 Thread Geert Uytterhoeven
On Sun, Dec 13, 2020 at 7:38 PM Adam Ford  wrote:
> The Bluetooth chip is capable of operating at 4Mbps, but the
> max-speed setting was on the UART node instead of the Bluetooth
> node, so the chip didn't operate at the correct speed resulting
> in choppy audio.  Fix this by setting the max-speed in the proper
> node.
>
> Fixes: a1d8a344f1ca ("arm64: dts: renesas: Introduce 
> r8a774a1-beacon-rzg2m-kit")
> Signed-off-by: Adam Ford 

Reviewed-by: Geert Uytterhoeven 
i.e. will queue in renesas-devel for v5.12.

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds


Re: [PATCH 03/18] arm64: dts: renesas: beacon kit: Remove unnecessary nodes

2020-12-17 Thread Geert Uytterhoeven
On Sun, Dec 13, 2020 at 7:38 PM Adam Ford  wrote:
> VSPI0 and VSPB are already enabled by default.  There is no need
> to add extra nodes to enable them.  Remove the redundant nodes.
>
> Signed-off-by: Adam Ford 

Reviewed-by: Geert Uytterhoeven 
i.e. will queue in renesas-devel for v5.12.

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds


[PATCH] cpufreq: intel_pstate: Use the latest guaranteed freq during verify

2020-12-17 Thread Srinivas Pandruvada
This change tries to address an issue, when BIOS disabled turbo
but HWP_CAP guaranteed is changed later and user space wants to take
advantage of this increased guaranteed performance.

The HWP_CAP.GUARANTEED value is not a static value. It can be changed
by some out of band agent or during Intel Speed Select performance
level change. The HWP_CAP.MAX still shows max possible performance when
BIOS disabled turbo. So guaranteed can still change as long as this is
same or below HWP_CAP.MAX.

When guaranteed is changed, the sysfs base_frequency attributes shows
the latest guaranteed frequency. This attribute can be used by user
space software to update scaling min/max frequency.

Currently the setpolicy callback already uses the latest HWP_CAP
values when setting HWP_REQ. But the verify callback will still restrict
the user settings to the to old guaranteed value. So if the guaranteed
is increased, user space can't take advantage of it.

To solve this similar to setpolicy callback, read the latest HWP_CAP
values and use it to restrict the maximum setting. This is done by
calling intel_pstate_get_hwp_max(), which already accounts for user
and BIOS turbo disable to get the current max performance.

This issue is side effect of fixing the issue of scaling frequency
limits by the
 'commit eacc9c5a927e ("cpufreq: intel_pstate:
 Fix intel_pstate_get_hwp_max() for turbo disabled")'
The fix resulted in correct setting of reduced scaling frequencies,
but this resulted in capping HWP.REQ to HWP_CAP.GUARANTEED in this case.

Cc: 5.8+  # 5.8+
Signed-off-by: Srinivas Pandruvada 
---
 drivers/cpufreq/intel_pstate.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index 2a4db856222f..7081d1edb22b 100644
--- a/drivers/cpufreq/intel_pstate.c
+++ b/drivers/cpufreq/intel_pstate.c
@@ -2199,6 +2199,12 @@ static void intel_pstate_clear_update_util_hook(unsigned 
int cpu)
 
 static int intel_pstate_get_max_freq(struct cpudata *cpu)
 {
+   if (hwp_active) {
+   int turbo_max, max_state;
+
+   intel_pstate_get_hwp_max(cpu->cpu, &turbo_max, &max_state);
+   return max_state * cpu->pstate.scaling;
+   }
return global.turbo_disabled || global.no_turbo ?
cpu->pstate.max_freq : cpu->pstate.turbo_freq;
 }
-- 
2.29.2



Re: [External] Re: [PATCH v9 11/11] mm/hugetlb: Optimize the code with the help of the compiler

2020-12-17 Thread Muchun Song
On Thu, Dec 17, 2020 at 6:32 PM Oscar Salvador  wrote:
>
> On Sun, Dec 13, 2020 at 11:45:34PM +0800, Muchun Song wrote:
> >  static inline unsigned int free_vmemmap_pages_per_hpage(struct hstate *h)
> >  {
> > - return h->nr_free_vmemmap_pages;
> > + return h->nr_free_vmemmap_pages && is_power_of_2(sizeof(struct page));
>
> This is wrong as it will return either true or false, but not what we want:

Yeah, very thanks for pointing that out.

>
> static inline unsigned long free_vmemmap_pages_size_per_hpage(struct 
> hstate *h)
> {
> return (unsigned long)free_vmemmap_pages_per_hpage(h) << 
> PAGE_SHIFT;
> }
>
> the above will compute to 4096, which is wrong for obvious reasons.

You are right. It is my mistake. Thanks Oscar.

>
> --
> Oscar Salvador
> SUSE L3



-- 
Yours,
Muchun


Re: [PATCH v1 ] ALSA: core: memalloc: add page alignment for iram

2020-12-17 Thread Lars-Peter Clausen

On 12/17/20 11:14 AM, Takashi Iwai wrote:

On Thu, 17 Dec 2020 10:55:42 +0100,
Takashi Iwai wrote:

On Thu, 17 Dec 2020 10:43:45 +0100,
Lars-Peter Clausen wrote:

On 12/17/20 5:15 PM, Robin Gong wrote:

Since mmap for userspace is based on page alignment, add page alignment
for iram alloc from pool, otherwise, some good data located in the same
page of dmab->area maybe touched wrongly by userspace like pulseaudio.


I wonder, do we also have to align size to be a multiple of PAGE_SIZE
to avoid leaking unrelated data?

Hm, a good question.  Basically the PCM buffer size itself shouldn't
be influenced by that (i.e. no hw-constraint or such is needed), but
the padding should be cleared indeed.  I somehow left those to the
allocator side, but maybe it's safer to clear the whole buffer in
sound/core/memalloc.c commonly.

That said, something like below (totally untested).
We might pass the pass-aligned size to dmab->bytes field instead of
keeping the original value, too.


We'd need this for those APIs that also pass the size to the free() 
function. Like dma_free_coherent() and free_pages_exact(), but maybe 
those round up internally as well.


I had a quick look and I could not find any place were the code relies 
on the requested buffer size being stored in dmab->bytes. In fact we 
already reuse the buffer if  there is an allocated buffer that is larger 
than the requested buffer (See snd_pcm_lib_malloc_pages), so this should 
be OK.





Takashi

---
--- a/sound/core/memalloc.c
+++ b/sound/core/memalloc.c
@@ -126,6 +126,7 @@ static inline gfp_t snd_mem_get_gfp_flags(const struct 
device *dev,
  int snd_dma_alloc_pages(int type, struct device *device, size_t size,
struct snd_dma_buffer *dmab)
  {
+   size_t orig_size = size;
gfp_t gfp;
  
  	if (WARN_ON(!size))

@@ -133,6 +134,7 @@ int snd_dma_alloc_pages(int type, struct device *device, 
size_t size,
if (WARN_ON(!dmab))
return -ENXIO;
  
+	size = PAGE_ALIGN(size);

dmab->dev.type = type;
dmab->dev.dev = device;
dmab->bytes = 0;
@@ -177,7 +179,8 @@ int snd_dma_alloc_pages(int type, struct device *device, 
size_t size,
}
if (! dmab->area)
return -ENOMEM;
-   dmab->bytes = size;
+   memset(dmab->area, 0, size);
+   dmab->bytes = orig_size;
return 0;
  }
  EXPORT_SYMBOL(snd_dma_alloc_pages);





Re: New objtool warning..

2020-12-17 Thread Peter Zijlstra
On Wed, Dec 16, 2020 at 02:01:58PM -0600, Josh Poimboeuf wrote:
> So this is kind of tricky, because the unreachable() annotation usually
> means "the previous instruction is a dead end".  Most of the time, the
> next instruction -- the one actually pointed to by the annotation -- is
> actually reachable from another path.

*groan*, this is why I ended up sticking a nop in
instrumentation_begin()/_end().



Re: [patch 3/3] tick: Annotate tick_do_timer_cpu data races

2020-12-17 Thread Peter Zijlstra
On Wed, Dec 16, 2020 at 01:19:31PM -0800, Paul E. McKenney wrote:
> Given that there is no optimization potential, then the main reason to use
> data_race() instead of *_ONCE() is to prevent KCSAN from considering the
> accesses when looking for data races.  But that is mostly for debugging
> accesses, in cases when these accesses are not really part of the
> concurrent algorithm.
> 
> So if I understand the situation correctly, I would be using *ONCE().

Huh, what, why?

The code doesn't need READ_ONCE(), it merely wants to tell kasan that
the race it observes is fine and as to please shut up.

IOW data_race() is accurate and right.


Re: i386: rcu-torture: WARNING: at kernel/rcu/rcutorture.c:1169 rcu_torture_writer [rcutorture]

2020-12-17 Thread Naresh Kamboju
Hi Paul,

Thanks for your inputs.

On Wed, 16 Dec 2020 at 21:33, Paul E. McKenney  wrote:
>
> On Wed, Dec 16, 2020 at 03:40:04PM +0530, Naresh Kamboju wrote:
> > Linux Kernel Functional Testing (LKFT) started running rcu-torture tests on
> > qemu_arm64, qemu_arm qemu_x86_64 and qemu_i386 from our CI build systems.
> >
> > The following warning(s) noticed on qemu_i386 while running rcu-torture test
> > on Linux mainline and Linux -next master branch. Since we do not have 
> > baseline
> > results i can not comment this as regression but when compared with
> > stable-rc 5.4 kernel this warning is new on mainline and next.
>
> The rcutorture testing "stutters", that is, it periodically intentionally
> drops the test load down to zero for a few seconds.  The expectation is
> that with no load, rcutorture will have no trouble finishing any needed
> grace periods within that zero-load period.  If at the end of the stutter
> period, RCU work remains undone, then this warning is emitted.
>
> This warning can be a false positive in the following situations:
>
> 1.  The system on which you are running rcutorture is under
> additional heavy load.

The DUT is running the test - rcutorture - only.

> 2.  You are running multiple guest OSes, each of which is running
> rcutorture, and vCPUs from each of the guest OSes ends up
> sharing a core with a vCPU from one of the other guests.  This
> can cause the zero-load period to not be so unloaded.
>
> 3.  You built rcutorture into your kernel, so that rcutorture starts
> immediately at boot time (CONFIG_RCU_TORTURE_TEST=y).  If your
> boot takes long enough, rcutorture can massively overload the
> single boot CPU, which can in turn result in this warning.

The test was built as a module.
CONFIG_RCU_TORTURE_TEST=m

>
> If you are in situation #1, I suggest disabling stuttering using the
> rcutorture.stutter=0 kernel boot parameter.
>
> If you are in situation #2, I suggest binding the guest-OS vCPUs
> to avoid them sharing cores with each other.
>
> If you are in situation #3, I have patches that I expect to submit
> upstream in the v5.12 merge window that can help.  Hey, they work for me!
> If you would like to test them before then, please let me know.
>
> If something else is going on, please let me know what it is so that
> I can fix it one way or another.

We were running on qemu_i386 today. I have tested on real hardware
and the reported problem has been reproduced.

> This warning has been present for quite some time, but I continually
> make rcutorture more aggressive, and this could well be part of the
> fallout of additional rcutorture aggression.
>
> And either way, thank you for trying out rcutorture!

We are happy to test :)

- Naresh


  1   2   3   4   5   6   7   8   9   10   >