Re: [PATCH -next] memory: omap-gpmc: Fix -Wunused-function warnings
On 2020/9/1 14:52, Krzysztof Kozlowski wrote: > On Tue, Sep 01, 2020 at 11:56:42AM +0800, YueHaibing wrote: >> drivers/memory/omap-gpmc.c:987:12: warning: ‘gpmc_cs_remap’ defined but not >> used [-Wunused-function] >> static int gpmc_cs_remap(int cs, u32 base) >> ^ >> drivers/memory/omap-gpmc.c:926:20: warning: ‘gpmc_cs_get_name’ defined but >> not used [-Wunused-function] >> static const char *gpmc_cs_get_name(int cs) >> ^~~~ >> drivers/memory/omap-gpmc.c:919:13: warning: ‘gpmc_cs_set_name’ defined but >> not used [-Wunused-function] >> static void gpmc_cs_set_name(int cs, const char *name) >> ^~~~ >> Make them as __maybe_unused to fix this. > > Hi, > > Do you know what configuration triggers these warnings? What has to be > disabled (e.g. CONFIG_OF)? Such information is useful in the commit > message. Yes, this is triggered by disable CONFIG_OF, I will update the commit log. > > Best regards, > Krzysztof > > . >
[PATCH] net: ipv6: fix __rt6_purge_dflt_routers when forwarding is not set on all ifaces
The problem is exposed when the system has multiple ifaces and
forwarding is enabled on a subset of them, __rt6_purge_dflt_routers will
clean the default route on all the ifaces which is not desired.
This patches fixes that by cleaning only the routes where the iface has
forwarding enabled.
Fixes: 830218c1add1 ("net: ipv6: Fix processing of RAs in presence of VRF")
Cc: David Ahern
Signed-off-by: Brian Vazquez
---
net/ipv6/route.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index 5e7e25e2523a..41181cd489ea 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -4283,6 +4283,7 @@ static void __rt6_purge_dflt_routers(struct net *net,
struct fib6_table *table)
{
struct fib6_info *rt;
+ bool deleted = false;
restart:
rcu_read_lock();
@@ -4291,16 +4292,19 @@ static void __rt6_purge_dflt_routers(struct net *net,
struct inet6_dev *idev = dev ? __in6_dev_get(dev) : NULL;
if (rt->fib6_flags & (RTF_DEFAULT | RTF_ADDRCONF) &&
- (!idev || idev->cnf.accept_ra != 2) &&
+ (!idev || (idev->cnf.forwarding == 1 &&
+ idev->cnf.accept_ra != 2)) &&
fib6_info_hold_safe(rt)) {
rcu_read_unlock();
ip6_del_rt(net, rt, false);
+ deleted = true;
goto restart;
}
}
rcu_read_unlock();
- table->flags &= ~RT6_TABLE_HAS_DFLT_ROUTER;
+ if (deleted)
+ table->flags &= ~RT6_TABLE_HAS_DFLT_ROUTER;
}
void rt6_purge_dflt_routers(struct net *net)
--
2.28.0.402.g5ffc5be6b7-goog
Re: [PATCH v2 00/23] Use asm-generic for mmu_context no-op functions
On Tue, Sep 01, 2020 at 04:17:00PM +1000, Nicholas Piggin wrote: > Excerpts from Mike Rapoport's message of August 30, 2020 8:18 pm: > > On Thu, Aug 27, 2020 at 12:52:26AM +1000, Nicholas Piggin wrote: > >> It would be nice to be able to modify mmu_context functions or add a > >> hook without updating all architectures, many of which will be no-ops. > >> > >> The motivation for this series is a change to lazy mmu handling, but > >> this series stands on its own as a good cleanup whether or not we end > >> up making that change. > > > > I really like this series, I just have some small comments in reply to > > patch 1, otherwise feel free to add > > > > Acked-by: Mike Rapoport > > I can't see your comments in reply to patch 1. Hmm, apparently I forgot to hit "Send"... > Thanks, > Nick > -- Sincerely yours, Mike.
[PATCH v10 0/4] scsi: ufs: Add Host Performance Booster Support
Changelog: v9 -> v10 1. Fix 64-bit division error 2. Fix problems commentted in Bart's review. v8 -> v9 1. Change sysfs initialization. 2. Change reading descriptor during HPB initialization 3. Fix problems commentted in Bart's review. 4. Change base commit from 5.9/scsi-queue to 5.10/scsi-queue. v7 -> v8 Remove wrongly added tags. v6 -> v7 1. Remove UFS feature layer. 2. Cleanup for sparse error. v5 -> v6 Change base commit to b53293fa662e28ae0cdd40828dc641c09f133405 v4 -> v5 Delete unused macro define. v3 -> v4 1. Cleanup. v2 -> v3 1. Add checking input module parameter value. 2. Change base commit from 5.8/scsi-queue to 5.9/scsi-queue. 3. Cleanup for unused variables and label. v1 -> v2 1. Change the full boilerplate text to SPDX style. 2. Adopt dynamic allocation for sub-region data structure. 3. Cleanup. NAND flash memory-based storage devices use Flash Translation Layer (FTL) to translate logical addresses of I/O requests to corresponding flash memory addresses. Mobile storage devices typically have RAM with constrained size, thus lack in memory to keep the whole mapping table. Therefore, mapping tables are partially retrieved from NAND flash on demand, causing random-read performance degradation. To improve random read performance, JESD220-3 (HPB v1.0) proposes HPB (Host Performance Booster) which uses host system memory as a cache for the FTL mapping table. By using HPB, FTL data can be read from host memory faster than from NAND flash memory. The current version only supports the DCM (device control mode). This patch consists of 3 parts to support HPB feature. 1) HPB probe and initialization process 2) READ -> HPB READ using cached map information 3) L2P (logical to physical) map management In the HPB probe and init process, the device information of the UFS is queried. After checking supported features, the data structure for the HPB is initialized according to the device information. A read I/O in the active sub-region where the map is cached is changed to HPB READ by the HPB. The HPB manages the L2P map using information received from the device. For active sub-region, the HPB caches through ufshpb_map request. For the in-active region, the HPB discards the L2P map. When a write I/O occurs in an active sub-region area, associated dirty bitmap checked as dirty for preventing stale read. HPB is shown to have a performance improvement of 58 - 67% for random read workload. [1] This series patches are based on the 5.9/scsi-queue branch. [1]: https://www.usenix.org/conference/hotstorage17/program/presentation/jeong Daejun park (4): scsi: ufs: Add HPB feature related parameters scsi: ufs: Introduce HPB feature scsi: ufs: L2P map management for HPB read scsi: ufs: Prepare HPB read for cached sub-region drivers/scsi/ufs/Kconfig |9 + drivers/scsi/ufs/Makefile |1 + drivers/scsi/ufs/ufs.h| 47 + drivers/scsi/ufs/ufshcd.c | 60 ++ drivers/scsi/ufs/ufshcd.h | 23 +- drivers/scsi/ufs/ufshpb.c | 1845 drivers/scsi/ufs/ufshpb.h | 229 + 7 files changed, 2213 insertions(+), 1 deletion(-) created mode 100644 drivers/scsi/ufs/ufshpb.c created mode 100644 drivers/scsi/ufs/ufshpb.h
Re: [PATCH -next] memory: omap-gpmc: Fix -Wunused-function warnings
On Tue, Sep 01, 2020 at 11:56:42AM +0800, YueHaibing wrote: > drivers/memory/omap-gpmc.c:987:12: warning: ‘gpmc_cs_remap’ defined but not > used [-Wunused-function] > static int gpmc_cs_remap(int cs, u32 base) > ^ > drivers/memory/omap-gpmc.c:926:20: warning: ‘gpmc_cs_get_name’ defined but > not used [-Wunused-function] > static const char *gpmc_cs_get_name(int cs) > ^~~~ > drivers/memory/omap-gpmc.c:919:13: warning: ‘gpmc_cs_set_name’ defined but > not used [-Wunused-function] > static void gpmc_cs_set_name(int cs, const char *name) > ^~~~ > Make them as __maybe_unused to fix this. Hi, Do you know what configuration triggers these warnings? What has to be disabled (e.g. CONFIG_OF)? Such information is useful in the commit message. Best regards, Krzysztof
Re: WARNING: suspicious RCU usage - sdhci-pltfm: SDHCI platform and OF driver helper
+ Re-adding Peter (seems like the original address was wrong) On Tue, 1 Sep 2020 at 08:46, Ulf Hansson wrote: > > + Saravanna, Rafael, Lina > > On Mon, 31 Aug 2020 at 21:44, Paul E. McKenney wrote: > > > > On Mon, Aug 31, 2020 at 12:02:31PM +0530, Naresh Kamboju wrote: > > > While booting linux mainline kernel on arm64 db410c this kernel warning > > > noticed. > > > > > > metadata: > > > git branch: master > > > git repo: > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > > > git commit: f75aef392f869018f78cfedf3c320a6b3fcfda6b > > > git describe: v5.9-rc3 > > > make_kernelversion: 5.9.0-rc3 > > > kernel-config: > > > http://snapshots.linaro.org/openembedded/lkft/lkft/sumo/dragonboard-410c/lkft/linux-mainline/2965/config > > > > > > Boot log, > > > > > > [0.00] Booting Linux on physical CPU 0x00 [0x410fd030] > > > [0.00] Linux version 5.9.0-rc3 (oe-user@oe-host) > > > (aarch64-linaro-linux-gcc (GCC) 7.3.0, GNU ld (GNU Binutils) > > > 2.30.0.20180208) #1 SMP PREEMPT Mon Aug 31 00:23:15 UTC 2020 > > > [0.00] Machine model: Qualcomm Technologies, Inc. APQ 8016 SBC > > > <> > > > [5.299090] sdhci: Secure Digital Host Controller Interface driver > > > [5.299140] sdhci: Copyright(c) Pierre Ossman > > > [5.304313] > > > [5.307771] Synopsys Designware Multimedia Card Interface Driver > > > [5.308588] = > > > [5.308593] WARNING: suspicious RCU usage > > > [5.316628] sdhci-pltfm: SDHCI platform and OF driver helper > > > [5.320052] 5.9.0-rc3 #1 Not tainted > > > [5.320057] - > > > [5.320063] /usr/src/kernel/include/trace/events/lock.h:37 > > > suspicious rcu_dereference_check() usage! > > > [5.320068] > > > [5.320068] other info that might help us debug this: > > > [5.320068] > > > [5.320074] > > > [5.320074] rcu_scheduler_active = 2, debug_locks = 1 > > > [5.320078] RCU used illegally from extended quiescent state! > > > [5.320084] no locks held by swapper/0/0. > > > [5.320089] > > > [5.320089] stack backtrace: > > > [5.320098] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.9.0-rc3 #1 > > > [5.346354] sdhci_msm 7864900.sdhci: Got CD GPIO > > > [5.346446] Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC > > > (DT) > > > [5.346452] Call trace: > > > [5.346463] dump_backtrace+0x0/0x1f8 > > > [5.346471] show_stack+0x2c/0x38 > > > [5.346480] dump_stack+0xec/0x15c > > > [5.346490] lockdep_rcu_suspicious+0xd4/0xf8 > > > [5.346499] lock_acquire+0x3d0/0x440 > > > [5.346510] _raw_spin_lock_irqsave+0x80/0xb0 > > > [5.413118] __pm_runtime_suspend+0x34/0x1d0 > > > [5.417457] psci_enter_domain_idle_state+0x4c/0xb0 > > > [5.421795] cpuidle_enter_state+0xc8/0x610 > > > [5.426392] cpuidle_enter+0x3c/0x50 > > > [5.430561] call_cpuidle+0x44/0x80 > > > [5.434378] do_idle+0x240/0x2a0 > > > > RCU ignores CPUs in the idle loop, which means that you cannot use > > rcu_read_lock() from the idle loop without use of something like > > RCU_NONIDLE(). If this is due to event tracing, you should use the > > _rcuidle() variant of the event trace statement. > > In the runtime suspend path, the runtime PM core calls > device_links_read_lock() - if the device in question has any links to > suppliers (to allow them to be suspended too). > > device_links_read_lock() calls srcu_read_lock(). > > It turns out that the device in question (the CPU device that is > attached to genpd) didn't have any links before - but that seems to > have changed, due to the work done by Saravana (links become created > on a per resource basis, parsed from DT during boot). > > > > > Note also that Peter Zijlstra (CCed) is working to shrink the portion > > of the idle loop that RCU ignores. Not sure that it covers your > > case, but it is worth checking. > > Thanks for letting me know. Let's see what Peter thinks about this then. > > Apologize for my ignorance, but from a cpuidle point of view, what > does it mean using RCU_NONIDLE()? I guess we should avoid RCU_NONIDLE > on bigger code paths? > > I could add RCU_NONIDLE for the calls to pm_runtime_put_sync_suspend() > and pm_runtime_get_sync() in psci_enter_domain_idle_state(). Perhaps > that's the easiest approach, at least to start with. > > Or do you have any other ideas? > > [...] > > Kind regards > Uffe
[PATCH v2] misc: rtsx: add power saving function and bios guide options
From: Ricky Wu
v2:
fixed build WARNING
v1:
Added rts5227 rts5249 rts5260 rts5228 power saving functions,
added BIOS guide MMC funciton and U_d3_en register support and
fixed rts5260 driving parameter
Signed-off-by: Ricky Wu
---
drivers/misc/cardreader/rts5227.c | 115 ++-
drivers/misc/cardreader/rts5228.c | 5 +-
drivers/misc/cardreader/rts5249.c | 146 -
drivers/misc/cardreader/rts5260.c | 33 ---
drivers/misc/cardreader/rtsx_pcr.h | 18
5 files changed, 288 insertions(+), 29 deletions(-)
diff --git a/drivers/misc/cardreader/rts5227.c
b/drivers/misc/cardreader/rts5227.c
index f5f392ddf3d6..314037eff17d 100644
--- a/drivers/misc/cardreader/rts5227.c
+++ b/drivers/misc/cardreader/rts5227.c
@@ -72,6 +72,8 @@ static void rts5227_fetch_vendor_settings(struct rtsx_pcr
*pcr)
pci_read_config_dword(pdev, PCR_SETTING_REG2, ®);
pcr_dbg(pcr, "Cfg 0x%x: 0x%x\n", PCR_SETTING_REG2, reg);
+ if (rtsx_check_mmc_support(reg))
+ pcr->extra_caps |= EXTRA_CAPS_NO_MMC;
pcr->sd30_drive_sel_3v3 = rtsx_reg_to_sd30_drive_sel_3v3(reg);
if (rtsx_reg_check_reverse_socket(reg))
pcr->flags |= PCR_REVERSE_SOCKET;
@@ -84,16 +86,78 @@ static void rts5227_force_power_down(struct rtsx_pcr *pcr,
u8 pm_state)
rtsx_pci_write_register(pcr, AUTOLOAD_CFG_BASE + 2, 0xFF, 0);
rtsx_pci_write_register(pcr, AUTOLOAD_CFG_BASE + 3, 0x01, 0);
- if (pm_state == HOST_ENTER_S3)
- rtsx_pci_write_register(pcr, pcr->reg_pm_ctrl3, 0x10, 0x10);
+ rtsx_pci_write_register(pcr, pcr->reg_pm_ctrl3, 0x10, 0x10);
rtsx_pci_write_register(pcr, FPDCTL, 0x03, 0x03);
}
+static void rts5227_init_from_cfg(struct rtsx_pcr *pcr)
+{
+ struct pci_dev *pdev = pcr->pci;
+ int l1ss;
+ u32 lval;
+ struct rtsx_cr_option *option = &pcr->option;
+
+ l1ss = pci_find_ext_capability(pdev, PCI_EXT_CAP_ID_L1SS);
+ if (!l1ss)
+ return;
+
+ pci_read_config_dword(pdev, l1ss + PCI_L1SS_CTL1, &lval);
+
+ if (CHK_PCI_PID(pcr, 0x522A)) {
+ if (0 == (lval & 0x0F))
+ rtsx_pci_enable_oobs_polling(pcr);
+ else
+ rtsx_pci_disable_oobs_polling(pcr);
+ }
+
+ if (lval & PCI_L1SS_CTL1_ASPM_L1_1)
+ rtsx_set_dev_flag(pcr, ASPM_L1_1_EN);
+ else
+ rtsx_clear_dev_flag(pcr, ASPM_L1_1_EN);
+
+ if (lval & PCI_L1SS_CTL1_ASPM_L1_2)
+ rtsx_set_dev_flag(pcr, ASPM_L1_2_EN);
+ else
+ rtsx_clear_dev_flag(pcr, ASPM_L1_2_EN);
+
+ if (lval & PCI_L1SS_CTL1_PCIPM_L1_1)
+ rtsx_set_dev_flag(pcr, PM_L1_1_EN);
+ else
+ rtsx_clear_dev_flag(pcr, PM_L1_1_EN);
+
+ if (lval & PCI_L1SS_CTL1_PCIPM_L1_2)
+ rtsx_set_dev_flag(pcr, PM_L1_2_EN);
+ else
+ rtsx_clear_dev_flag(pcr, PM_L1_2_EN);
+
+ if (option->ltr_en) {
+ u16 val;
+
+ pcie_capability_read_word(pcr->pci, PCI_EXP_DEVCTL2, &val);
+ if (val & PCI_EXP_DEVCTL2_LTR_EN) {
+ option->ltr_enabled = true;
+ option->ltr_active = true;
+ rtsx_set_ltr_latency(pcr, option->ltr_active_latency);
+ } else {
+ option->ltr_enabled = false;
+ }
+ }
+
+ if (rtsx_check_dev_flag(pcr, ASPM_L1_1_EN | ASPM_L1_2_EN
+ | PM_L1_1_EN | PM_L1_2_EN))
+ option->force_clkreq_0 = false;
+ else
+ option->force_clkreq_0 = true;
+
+}
+
static int rts5227_extra_init_hw(struct rtsx_pcr *pcr)
{
u16 cap;
+ struct rtsx_cr_option *option = &pcr->option;
+ rts5227_init_from_cfg(pcr);
rtsx_pci_init_cmd(pcr);
/* Configure GPIO as output */
@@ -115,9 +179,17 @@ static int rts5227_extra_init_hw(struct rtsx_pcr *pcr)
rts5227_fill_driving(pcr, OUTPUT_3V3);
/* Configure force_clock_req */
if (pcr->flags & PCR_REVERSE_SOCKET)
- rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, PETXCFG, 0xB8, 0xB8);
+ rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, PETXCFG, 0x30, 0x30);
else
- rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, PETXCFG, 0xB8, 0x88);
+ rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, PETXCFG, 0x30, 0x00);
+
+ if (option->force_clkreq_0)
+ rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, PETXCFG,
+ FORCE_CLKREQ_DELINK_MASK, FORCE_CLKREQ_LOW);
+ else
+ rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, PETXCFG,
+ FORCE_CLKREQ_DELINK_MASK, FORCE_CLKREQ_HIGH);
+
rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, pcr->reg_pm_ctrl3, 0x10, 0x00);
return rtsx_pci_send_cmd(pcr, 100);
@@ -373,6 +445,27 @@ static int rts522a_switch_output_voltage(st
Re: [PATCH v2 01/23] asm-generic: add generic MMU versions of mmu context functions
On Thu, Aug 27, 2020 at 12:52:27AM +1000, Nicholas Piggin wrote:
> Many of these are no-ops on many architectures, so extend mmu_context.h
> to cover MMU and NOMMU, and split the NOMMU bits out to nommu_context.h
>
> Cc: Arnd Bergmann
> Cc: linux-a...@vger.kernel.org
> Signed-off-by: Nicholas Piggin
> ---
> arch/microblaze/include/asm/mmu_context.h | 2 +-
> arch/sh/include/asm/mmu_context.h | 2 +-
> include/asm-generic/mmu_context.h | 57 +--
> include/asm-generic/nommu_context.h | 19
> 4 files changed, 64 insertions(+), 16 deletions(-)
> create mode 100644 include/asm-generic/nommu_context.h
>
> diff --git a/arch/microblaze/include/asm/mmu_context.h
> b/arch/microblaze/include/asm/mmu_context.h
> index f74f9da07fdc..34004efb3def 100644
> --- a/arch/microblaze/include/asm/mmu_context.h
> +++ b/arch/microblaze/include/asm/mmu_context.h
> @@ -2,5 +2,5 @@
> #ifdef CONFIG_MMU
> # include
> #else
> -# include
> +# include
> #endif
> diff --git a/arch/sh/include/asm/mmu_context.h
> b/arch/sh/include/asm/mmu_context.h
> index f664e51e8a15..461b1304580b 100644
> --- a/arch/sh/include/asm/mmu_context.h
> +++ b/arch/sh/include/asm/mmu_context.h
> @@ -133,7 +133,7 @@ static inline void switch_mm(struct mm_struct *prev,
> #define set_TTB(pgd) do { } while (0)
> #define get_TTB()(0)
>
> -#include
> +#include
>
> #endif /* CONFIG_MMU */
>
> diff --git a/include/asm-generic/mmu_context.h
> b/include/asm-generic/mmu_context.h
> index 6be9106fb6fb..86cea80a50df 100644
> --- a/include/asm-generic/mmu_context.h
> +++ b/include/asm-generic/mmu_context.h
> @@ -3,44 +3,73 @@
> #define __ASM_GENERIC_MMU_CONTEXT_H
>
> /*
> - * Generic hooks for NOMMU architectures, which do not need to do
> - * anything special here.
> + * Generic hooks to implement no-op functionality.
> */
>
> -#include
> -
> struct task_struct;
> struct mm_struct;
>
> +/*
> + * enter_lazy_tlb - Called when "tsk" is about to enter lazy TLB mode.
> + *
> + * @mm: the currently active mm context which is becoming lazy
> + * @tsk: task which is entering lazy tlb
> + *
> + * tsk->mm will be NULL
> + */
> +#ifndef enter_lazy_tlb
> static inline void enter_lazy_tlb(struct mm_struct *mm,
> struct task_struct *tsk)
> {
> }
> +#endif
>
> +/**
> + * init_new_context - Initialize context of a new mm_struct.
> + * @tsk: task struct for the mm
> + * @mm: the new mm struct
'make *docs' will complain here about missing Return: description
> + */
> +#ifndef init_new_context
> static inline int init_new_context(struct task_struct *tsk,
> struct mm_struct *mm)
> {
> return 0;
> }
> +#endif
Most architectures have non-trivial init_new_context, maybe this
should go into nommu_context.h?
> +/**
> + * destroy_context - Undo init_new_context when the mm is going away
> + * @mm: old mm struct
> + */
> +#ifndef destroy_context
> static inline void destroy_context(struct mm_struct *mm)
> {
> }
> +#endif
>
> -static inline void deactivate_mm(struct task_struct *task,
> - struct mm_struct *mm)
> -{
> -}
> -
> -static inline void switch_mm(struct mm_struct *prev,
> - struct mm_struct *next,
> - struct task_struct *tsk)
> +/**
> + * activate_mm - called after exec switches the current task to a new mm, to
> switch to it
> + * @prev_mm: previous mm of this task
> + * @next_mm: new mm
> + */
> +#ifndef activate_mm
> +static inline void activate_mm(struct mm_struct *prev_mm,
> +struct mm_struct *next_mm)
> {
> + switch_mm(prev_mm, next_mm, current);
> }
> +#endif
>
> -static inline void activate_mm(struct mm_struct *prev_mm,
> -struct mm_struct *next_mm)
> +/**
> + * dectivate_mm - called when an mm is released after exit or exec switches
> away from it
> + * @tsk: the task
> + * @mm: the old mm
> + */
> +#ifndef deactivate_mm
> +static inline void deactivate_mm(struct task_struct *tsk,
> + struct mm_struct *mm)
> {
> }
> +#endif
>
> #endif /* __ASM_GENERIC_MMU_CONTEXT_H */
> diff --git a/include/asm-generic/nommu_context.h
> b/include/asm-generic/nommu_context.h
> new file mode 100644
> index ..4f916f9e16cd
> --- /dev/null
> +++ b/include/asm-generic/nommu_context.h
> @@ -0,0 +1,19 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef __ASM_GENERIC_NOMMU_H
> +#define __ASM_GENERIC_NOMMU_H
> +
> +/*
> + * Generic hooks for NOMMU architectures, which do not need to do
> + * anything special here.
> + */
> +#include
> +
> +static inline void switch_mm(struct mm_struct *prev,
> + struct mm_struct *next,
> + struct task_struct *tsk)
> +{
> +}
> +
> +#include
> +
> +#endif /* __ASM_GENERIC_NOMMU_H */
> --
> 2.23.0
>
>
--
Sincerely yours,
Mike.
Re: [PATCH v2 0/6] dt-bindings: Convert SP804 to Json-schema (and fix users)
On Fri, 28 Aug 2020 16:44:28 +0100 André Przywara wrote: > On 28/08/2020 15:54, Linus Walleij wrote: > > Hi, > > > On Fri, Aug 28, 2020 at 4:20 PM Andre Przywara > > wrote: > > > >> This is the second attempt at converting the SP804 timer binding to yaml. > >> Compared to v1, I forbid additional properties, and included the primecell > >> binding. Also the clock-names property is now listed, although without > >> further requirements on the names. Changelog below. > > > > The series: > > Acked-by: Linus Walleij > > > >> I couldn't test any of those DT files on actual machines, but tried > >> to make the changes in a way that would be transparent to at least the > >> Linux driver. The only other SP804 DT user I could find is FreeBSD, > >> but they seem to use a different binding (no clocks, but a > >> clock-frequency property). > > > > That's annoying. I suppose FreeBSD just made that up and doesn't > > even have a binding document for it? > > I couldn't find bindings at all in their git tree. That's because I don't merge the bindings in the main branch. > I don't think they > treat this very formally, it seems to be more use-case driven. > Their SP804 driver does not know how to handle clock properties, so most > of the DTs (in sys/gnu/dts, so apparently copied from Linux) would not > work really well, because the driver assumes a hardcoded frequency of > 1MHz by default. In addition to sys/gnu/dts we also have sys/dts/ which are our own DTs before we used the Linux ones (a long time ago but some platform weren't converted, they will just die sometime in the futur if nobody takes care of them I guess). > There is only one DT (Annapurna Alpine with Cortex-A15) that provides > this clock-frequency property. The Linux DT does not mention the SP804 > in there at all, interestingly. I'm not familiar with this platform at all, it was done under contract by Semihalf and I'm sure that if something fails and their client starts to complain they will fix it. > > In an ideal world I suppose we should go and fix FreeBSD but I have > > no idea how easy or hard that is. > > It seems to be messy, at least in this case, and I guess unifying DTs > means some work on drivers as well. I wouldn't worry about us on this case, this binding requirements seems to have be done a long time ago before we had any clock framework and if our drivers needs to be updated we will do it when we imports DTS from whatever Linux version this will be merged in. > But AFAIK most of the more modern platforms copy the DTs (and thus > implicitly the bindings) from Linux, so there is probably much less > deviation for many more relevant boards. Yes, I (and others) insist on using the DTs from Linux and not doing any patches to it without sending them to the Linux ML. > Cheers, > Andre Cheers, > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- Emmanuel Vadot
[PATCH v2] misc: rtsx: add power saving function and bios guide options
From: Ricky Wu
v2:
fixed build WARNING
v1:
Added rts5227 rts5249 rts5260 rts5228 power saving functions,
added BIOS guide MMC funciton and U_d3_en register support and
fixed rts5260 driving parameter
Signed-off-by: Ricky Wu
---
drivers/misc/cardreader/rts5227.c | 115 ++-
drivers/misc/cardreader/rts5228.c | 5 +-
drivers/misc/cardreader/rts5249.c | 146 -
drivers/misc/cardreader/rts5260.c | 33 ---
drivers/misc/cardreader/rtsx_pcr.h | 18
5 files changed, 288 insertions(+), 29 deletions(-)
diff --git a/drivers/misc/cardreader/rts5227.c
b/drivers/misc/cardreader/rts5227.c
index f5f392ddf3d6..314037eff17d 100644
--- a/drivers/misc/cardreader/rts5227.c
+++ b/drivers/misc/cardreader/rts5227.c
@@ -72,6 +72,8 @@ static void rts5227_fetch_vendor_settings(struct rtsx_pcr
*pcr)
pci_read_config_dword(pdev, PCR_SETTING_REG2, ®);
pcr_dbg(pcr, "Cfg 0x%x: 0x%x\n", PCR_SETTING_REG2, reg);
+ if (rtsx_check_mmc_support(reg))
+ pcr->extra_caps |= EXTRA_CAPS_NO_MMC;
pcr->sd30_drive_sel_3v3 = rtsx_reg_to_sd30_drive_sel_3v3(reg);
if (rtsx_reg_check_reverse_socket(reg))
pcr->flags |= PCR_REVERSE_SOCKET;
@@ -84,16 +86,78 @@ static void rts5227_force_power_down(struct rtsx_pcr *pcr,
u8 pm_state)
rtsx_pci_write_register(pcr, AUTOLOAD_CFG_BASE + 2, 0xFF, 0);
rtsx_pci_write_register(pcr, AUTOLOAD_CFG_BASE + 3, 0x01, 0);
- if (pm_state == HOST_ENTER_S3)
- rtsx_pci_write_register(pcr, pcr->reg_pm_ctrl3, 0x10, 0x10);
+ rtsx_pci_write_register(pcr, pcr->reg_pm_ctrl3, 0x10, 0x10);
rtsx_pci_write_register(pcr, FPDCTL, 0x03, 0x03);
}
+static void rts5227_init_from_cfg(struct rtsx_pcr *pcr)
+{
+ struct pci_dev *pdev = pcr->pci;
+ int l1ss;
+ u32 lval;
+ struct rtsx_cr_option *option = &pcr->option;
+
+ l1ss = pci_find_ext_capability(pdev, PCI_EXT_CAP_ID_L1SS);
+ if (!l1ss)
+ return;
+
+ pci_read_config_dword(pdev, l1ss + PCI_L1SS_CTL1, &lval);
+
+ if (CHK_PCI_PID(pcr, 0x522A)) {
+ if (0 == (lval & 0x0F))
+ rtsx_pci_enable_oobs_polling(pcr);
+ else
+ rtsx_pci_disable_oobs_polling(pcr);
+ }
+
+ if (lval & PCI_L1SS_CTL1_ASPM_L1_1)
+ rtsx_set_dev_flag(pcr, ASPM_L1_1_EN);
+ else
+ rtsx_clear_dev_flag(pcr, ASPM_L1_1_EN);
+
+ if (lval & PCI_L1SS_CTL1_ASPM_L1_2)
+ rtsx_set_dev_flag(pcr, ASPM_L1_2_EN);
+ else
+ rtsx_clear_dev_flag(pcr, ASPM_L1_2_EN);
+
+ if (lval & PCI_L1SS_CTL1_PCIPM_L1_1)
+ rtsx_set_dev_flag(pcr, PM_L1_1_EN);
+ else
+ rtsx_clear_dev_flag(pcr, PM_L1_1_EN);
+
+ if (lval & PCI_L1SS_CTL1_PCIPM_L1_2)
+ rtsx_set_dev_flag(pcr, PM_L1_2_EN);
+ else
+ rtsx_clear_dev_flag(pcr, PM_L1_2_EN);
+
+ if (option->ltr_en) {
+ u16 val;
+
+ pcie_capability_read_word(pcr->pci, PCI_EXP_DEVCTL2, &val);
+ if (val & PCI_EXP_DEVCTL2_LTR_EN) {
+ option->ltr_enabled = true;
+ option->ltr_active = true;
+ rtsx_set_ltr_latency(pcr, option->ltr_active_latency);
+ } else {
+ option->ltr_enabled = false;
+ }
+ }
+
+ if (rtsx_check_dev_flag(pcr, ASPM_L1_1_EN | ASPM_L1_2_EN
+ | PM_L1_1_EN | PM_L1_2_EN))
+ option->force_clkreq_0 = false;
+ else
+ option->force_clkreq_0 = true;
+
+}
+
static int rts5227_extra_init_hw(struct rtsx_pcr *pcr)
{
u16 cap;
+ struct rtsx_cr_option *option = &pcr->option;
+ rts5227_init_from_cfg(pcr);
rtsx_pci_init_cmd(pcr);
/* Configure GPIO as output */
@@ -115,9 +179,17 @@ static int rts5227_extra_init_hw(struct rtsx_pcr *pcr)
rts5227_fill_driving(pcr, OUTPUT_3V3);
/* Configure force_clock_req */
if (pcr->flags & PCR_REVERSE_SOCKET)
- rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, PETXCFG, 0xB8, 0xB8);
+ rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, PETXCFG, 0x30, 0x30);
else
- rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, PETXCFG, 0xB8, 0x88);
+ rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, PETXCFG, 0x30, 0x00);
+
+ if (option->force_clkreq_0)
+ rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, PETXCFG,
+ FORCE_CLKREQ_DELINK_MASK, FORCE_CLKREQ_LOW);
+ else
+ rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, PETXCFG,
+ FORCE_CLKREQ_DELINK_MASK, FORCE_CLKREQ_HIGH);
+
rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, pcr->reg_pm_ctrl3, 0x10, 0x00);
return rtsx_pci_send_cmd(pcr, 100);
@@ -373,6 +445,27 @@ static int rts522a_switch_output_voltage(st
Re: [PATCH net-next] net: sch_generic: aviod concurrent reset and enqueue op for lockless qdisc
On 8/31/20 5:55 PM, Yunsheng Lin wrote:
> Currently there is concurrent reset and enqueue operation for the
> same lockless qdisc when there is no lock to synchronize the
> q->enqueue() in __dev_xmit_skb() with the qdisc reset operation in
> qdisc_deactivate() called by dev_deactivate_queue(), which may cause
> out-of-bounds access for priv->ring[] in hns3 driver if user has
> requested a smaller queue num when __dev_xmit_skb() still enqueue a
> skb with a larger queue_mapping after the corresponding qdisc is
> reset, and call hns3_nic_net_xmit() with that skb later.
>
> Avoid the above concurrent op by calling synchronize_rcu_tasks()
> after assigning new qdisc to dev_queue->qdisc and before calling
> qdisc_deactivate() to make sure skb with larger queue_mapping
> enqueued to old qdisc will always be reset when qdisc_deactivate()
> is called.
>
We request Fixes: tag for fixes in networking land.
> Signed-off-by: Yunsheng Lin
> ---
> net/sched/sch_generic.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/net/sched/sch_generic.c b/net/sched/sch_generic.c
> index 265a61d..6e42237 100644
> --- a/net/sched/sch_generic.c
> +++ b/net/sched/sch_generic.c
> @@ -1160,8 +1160,13 @@ static void dev_deactivate_queue(struct net_device
> *dev,
>
> qdisc = rtnl_dereference(dev_queue->qdisc);
> if (qdisc) {
> - qdisc_deactivate(qdisc);
> rcu_assign_pointer(dev_queue->qdisc, qdisc_default);
> +
> + /* Make sure lockless qdisc enqueuing is done with the
> + * old qdisc in __dev_xmit_skb().
> + */
> + synchronize_rcu_tasks();
This seems quite wrong, there is not a single use of synchronize_rcu_tasks() in
net/,
we probably do not want this.
I bet that synchronize_net() is appropriate, if not please explain/comment why
we want this instead.
Adding one synchronize_net() per TX queue is a killer for devices with 128 or
256 TX queues.
I would rather find a way of not calling qdisc_reset() from qdisc_deactivate().
This lockless pfifo_fast is a mess really.
[PATCH -next] ACPI: Remove unused inline functions
There is no callers in tree.
Signed-off-by: YueHaibing
---
include/linux/acpi.h | 9 -
1 file changed, 9 deletions(-)
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 17e80e182802..dd9b961628eb 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -979,8 +979,6 @@ int acpi_subsys_runtime_suspend(struct device *dev);
int acpi_subsys_runtime_resume(struct device *dev);
int acpi_dev_pm_attach(struct device *dev, bool power_on);
#else
-static inline int acpi_dev_runtime_suspend(struct device *dev) { return 0; }
-static inline int acpi_dev_runtime_resume(struct device *dev) { return 0; }
static inline int acpi_subsys_runtime_suspend(struct device *dev) { return 0; }
static inline int acpi_subsys_runtime_resume(struct device *dev) { return 0; }
static inline int acpi_dev_pm_attach(struct device *dev, bool power_on)
@@ -1218,13 +1216,6 @@ static inline int acpi_node_prop_get(const struct
fwnode_handle *fwnode,
return -ENXIO;
}
-static inline int acpi_dev_prop_get(const struct acpi_device *adev,
- const char *propname,
- void **valptr)
-{
- return -ENXIO;
-}
-
static inline int acpi_dev_prop_read_single(const struct acpi_device *adev,
const char *propname,
enum dev_prop_type proptype,
--
2.17.1
Re: Lockdep warning caused by "driver core: Fix sleeping in invalid context during device link deletion"
On Mon, Aug 31, 2020 at 11:07 PM Peng Fan wrote:
>
> > Subject: Re: Lockdep warning caused by "driver core: Fix sleeping in invalid
> > context during device link deletion"
> >
> > On Wed, Aug 26, 2020 at 10:17 PM Saravana Kannan
> > wrote:
> > >
> > > On Thu, Aug 20, 2020 at 8:50 PM Dong Aisheng
> > wrote:
> > > >
> > > > Hi ALL,
> > > >
> > > > We met the below WARNING during system suspend on an iMX6Q SDB
> > board
> > > > with the latest linus/master branch (v5.9-rc1+) and next-20200820.
> > > > v5.8 kernel is ok. So i did bisect and finally found it's caused by
> > > > the patch below.
> > > > Reverting it can get rid of the warning, but I wonder if there may
> > > > be other potential issues.
> > > > Any ideas?
> > > >
> > > > Defconfig used is: imx_v6_v7_defconfig
> > > >
> > >
> > > - 8< - Snipped text that was a bit misleading
> > >
> > > >
> > > > Error log:
> > > > # echo mem > /sys/power/state
> > > > [ 39.111865] PM: suspend entry (deep)
> > > > [ 39.148650] Filesystems sync: 0.032 seconds
> > > > [ 39.154034]
> > > > [ 39.155537]
> > ==
> > > > [ 39.161723] WARNING: possible circular locking dependency detected
> > > > [ 39.167911] 5.9.0-rc1-00103-g7eac66d0456f #37 Not tainted
> > > > [ 39.173315] --
> > > > [ 39.179500] sh/647 is trying to acquire lock:
> > > > [ 39.183862] c15a310c (dpm_list_mtx){+.+.}-{3:3}, at:
> > > > dpm_for_each_dev+0x20/0x5c
> > > > [ 39.191200]
> > > > [ 39.191200] but task is already holding lock:
> > > > [ 39.197036] c15a37e4 (fw_lock){+.+.}-{3:3}, at:
> > fw_pm_notify+0x90/0xd4
> > > > [ 39.203582]
> > > > [ 39.203582] which lock already depends on the new lock.
> > > > [ 39.203582]
> > > > [ 39.211763]
> > > > [ 39.211763] the existing dependency chain (in reverse order) is:
> > > > [ 39.219249]
> > > > [ 39.219249] -> #2 (fw_lock){+.+.}-{3:3}:
> > > > [ 39.224673]mutex_lock_nested+0x1c/0x24
> > > > [ 39.229126]firmware_uevent+0x18/0xa0
> > > > [ 39.233411]dev_uevent+0xc4/0x1f8
> > > > [ 39.237343]uevent_show+0x98/0x114
> > > > [ 39.241362]dev_attr_show+0x18/0x48
> > > > [ 39.245472]sysfs_kf_seq_show+0x84/0xec
> > > > [ 39.249927]seq_read+0x138/0x550
> > > > [ 39.253774]vfs_read+0x94/0x164
> > > > [ 39.257529]ksys_read+0x60/0xe8
> > > > [ 39.261288]ret_fast_syscall+0x0/0x28
> > > > [ 39.265564]0xbed7c808
> > > > [ 39.268538]
> > > > [ 39.268538] -> #1 (kn->active#3){}-{0:0}:
> > > > [ 39.274391]kernfs_remove_by_name_ns+0x40/0x94
> > > > [ 39.279450]device_del+0x144/0x3fc
> > >
> > > Rafael/Greg,
> > >
> > > I'm not very familiar with the #0 and #2 calls stacks. But poking
> > > around a bit, they are NOT due to the device-link-device. But the new
> > > stuff is the above two lines that are deleting the device-link-device
> > > (that's used to expose device link details in sysfs) when the device
> > > link is deleted.
> > >
> > > Kicking off a workqueue to break this cycle is easy, but the problem
> > > is that if I queue a work to delete the device, then the sysfs folder
> > > won't get removed immediately. And if the same link is created again
> > > before the work is completed, then there'll be a sysfs name collision
> > > and warning.
> > >
> > > So, I'm kinda stuck here. Open to suggestions. Hoping you'll have
> > > better ideas for breaking the cycle. Or point out how I'm
> > > misunderstanding the cycle here.
> > >
> >
> > Aisheng,
> >
> > Sent out a fix that I think should work.
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.ke
> > rnel.org%2Flkml%2F20200831221007.1506441-1-saravanak%40google.com%
> > 2FT%2F%23u&data=02%7C01%7Cpeng.fan%40nxp.com%7C3254604d7
> > 41b4d1ce73b08d84dfb65af%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0
> > %7C0%7C637345089428077609&sdata=5lh8WO%2BYMh4C1sBn58Fsm
> > XsjqjPj%2B%2FB71%2FENfMGDtTk%3D&reserved=0
> >
> > I wasn't able to reproduce it in my hardware. So, if you can test that patch
> > (and respond to that thread), that'd be great.
>
> I not found your patch in my mailbox, but anyway I tested it.
Sorry I forgot to CC everyone from the original email!
>
> Tested-by: Peng Fan (i.MX7ULP EVK)
Thanks for testing!
-Saravana
Re: WARNING: suspicious RCU usage - sdhci-pltfm: SDHCI platform and OF driver helper
+ Saravanna, Rafael, Lina On Mon, 31 Aug 2020 at 21:44, Paul E. McKenney wrote: > > On Mon, Aug 31, 2020 at 12:02:31PM +0530, Naresh Kamboju wrote: > > While booting linux mainline kernel on arm64 db410c this kernel warning > > noticed. > > > > metadata: > > git branch: master > > git repo: > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > > git commit: f75aef392f869018f78cfedf3c320a6b3fcfda6b > > git describe: v5.9-rc3 > > make_kernelversion: 5.9.0-rc3 > > kernel-config: > > http://snapshots.linaro.org/openembedded/lkft/lkft/sumo/dragonboard-410c/lkft/linux-mainline/2965/config > > > > Boot log, > > > > [0.00] Booting Linux on physical CPU 0x00 [0x410fd030] > > [0.00] Linux version 5.9.0-rc3 (oe-user@oe-host) > > (aarch64-linaro-linux-gcc (GCC) 7.3.0, GNU ld (GNU Binutils) > > 2.30.0.20180208) #1 SMP PREEMPT Mon Aug 31 00:23:15 UTC 2020 > > [0.00] Machine model: Qualcomm Technologies, Inc. APQ 8016 SBC > > <> > > [5.299090] sdhci: Secure Digital Host Controller Interface driver > > [5.299140] sdhci: Copyright(c) Pierre Ossman > > [5.304313] > > [5.307771] Synopsys Designware Multimedia Card Interface Driver > > [5.308588] = > > [5.308593] WARNING: suspicious RCU usage > > [5.316628] sdhci-pltfm: SDHCI platform and OF driver helper > > [5.320052] 5.9.0-rc3 #1 Not tainted > > [5.320057] - > > [5.320063] /usr/src/kernel/include/trace/events/lock.h:37 > > suspicious rcu_dereference_check() usage! > > [5.320068] > > [5.320068] other info that might help us debug this: > > [5.320068] > > [5.320074] > > [5.320074] rcu_scheduler_active = 2, debug_locks = 1 > > [5.320078] RCU used illegally from extended quiescent state! > > [5.320084] no locks held by swapper/0/0. > > [5.320089] > > [5.320089] stack backtrace: > > [5.320098] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.9.0-rc3 #1 > > [5.346354] sdhci_msm 7864900.sdhci: Got CD GPIO > > [5.346446] Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC (DT) > > [5.346452] Call trace: > > [5.346463] dump_backtrace+0x0/0x1f8 > > [5.346471] show_stack+0x2c/0x38 > > [5.346480] dump_stack+0xec/0x15c > > [5.346490] lockdep_rcu_suspicious+0xd4/0xf8 > > [5.346499] lock_acquire+0x3d0/0x440 > > [5.346510] _raw_spin_lock_irqsave+0x80/0xb0 > > [5.413118] __pm_runtime_suspend+0x34/0x1d0 > > [5.417457] psci_enter_domain_idle_state+0x4c/0xb0 > > [5.421795] cpuidle_enter_state+0xc8/0x610 > > [5.426392] cpuidle_enter+0x3c/0x50 > > [5.430561] call_cpuidle+0x44/0x80 > > [5.434378] do_idle+0x240/0x2a0 > > RCU ignores CPUs in the idle loop, which means that you cannot use > rcu_read_lock() from the idle loop without use of something like > RCU_NONIDLE(). If this is due to event tracing, you should use the > _rcuidle() variant of the event trace statement. In the runtime suspend path, the runtime PM core calls device_links_read_lock() - if the device in question has any links to suppliers (to allow them to be suspended too). device_links_read_lock() calls srcu_read_lock(). It turns out that the device in question (the CPU device that is attached to genpd) didn't have any links before - but that seems to have changed, due to the work done by Saravana (links become created on a per resource basis, parsed from DT during boot). > > Note also that Peter Zijlstra (CCed) is working to shrink the portion > of the idle loop that RCU ignores. Not sure that it covers your > case, but it is worth checking. Thanks for letting me know. Let's see what Peter thinks about this then. Apologize for my ignorance, but from a cpuidle point of view, what does it mean using RCU_NONIDLE()? I guess we should avoid RCU_NONIDLE on bigger code paths? I could add RCU_NONIDLE for the calls to pm_runtime_put_sync_suspend() and pm_runtime_get_sync() in psci_enter_domain_idle_state(). Perhaps that's the easiest approach, at least to start with. Or do you have any other ideas? [...] Kind regards Uffe
[PATCH 0/2] prandom_u32: make output less predictable
This is the cleanup of the latest series of prandom_u32 experimentations consisting in using SipHash instead of Tausworthe to produce the randoms used by the network stack. The changes to the files were kept minimal, and the controversial commit that used to take noise from the fast_pool (f227e3ec3b5c) was reverted. Instead, a dedicated "net_rand_noise" per_cpu variable is fed from various sources of activities (networking, scheduling) to perturb the SipHash state using fast, non-trivially predictable data, instead of keeping it fully deterministic. The goal is essentially to make any occasional memory leakage or brute-force attempt useless. The resulting code was verified to be very slightly faster on x86_64 than what is was with the controversial commit above, though this remains barely above measurement noise. It was only build-tested on arm & arm64. George Spelvin (1): random32: make prandom_u32() output unpredictable Willy Tarreau (1): random32: add noise from network and scheduling activity drivers/char/random.c | 1 - include/linux/prandom.h | 55 - kernel/time/timer.c | 9 +- lib/random32.c | 438 net/core/dev.c | 4 + 5 files changed, 326 insertions(+), 181 deletions(-) Cc: George Spelvin Cc: Amit Klein Cc: Eric Dumazet Cc: "Jason A. Donenfeld" Cc: Andy Lutomirski Cc: Kees Cook Cc: Thomas Gleixner Cc: Peter Zijlstra Cc: Linus Torvalds Cc: ty...@mit.edu Cc: Florian Westphal Cc: Marc Plumb Cc: Sedat Dilek -- 2.28.0
[PATCH 1/2] random32: make prandom_u32() output unpredictable
From: George Spelvin
Non-cryptographic PRNGs may have great statistical proprties, but
are usually trivially predictable to someone who knows the algorithm,
given a small sample of their output. An LFSR like prandom_u32() is
particularly simple, even if the sample is widely scattered bits.
It turns out the network stack uses prandom_u32() for some things like
random port numbers which it would prefer are *not* trivially predictable.
Predictability led to a practical DNS spoofing attack. Oops.
This patch replaces the LFSR with a homebrew cryptographic PRNG based
on the SipHash round function, which is in turn seeded with 128 bits
of strong random key. (The authors of SipHash have *not* been consulted
about this abuse of their algorithm.) Speed is prioritized over security;
attacks are rare, while performance is always wanted.
Replacing all callers of prandom_u32() is the quick fix.
Whether to reinstate a weaker PRNG for uses which can tolerate it
is an open question.
Commit f227e3ec3b5c ("random32: update the net random state on interrupt
and activity") was an earlier attempt at a solution. This patch replaces
it.
Reported-by: Amit Klein
Cc: Willy Tarreau
Cc: Eric Dumazet
Cc: "Jason A. Donenfeld"
Cc: Andy Lutomirski
Cc: Kees Cook
Cc: Thomas Gleixner
Cc: Peter Zijlstra
Cc: Linus Torvalds
Cc: ty...@mit.edu
Cc: Florian Westphal
Cc: Marc Plumb
Fixes: f227e3ec3b5c ("random32: update the net random state on interrupt and
activity")
Signed-off-by: George Spelvin
Link: https://lore.kernel.org/netdev/20200808152628.ga27...@sdf.org/
[ willy: partial reversal of f227e3ec3b5c; moved SIPROUND definitions
to prandom.h for later use; merged George's prandom_seed() proposal;
inlined siprand_u32(); replaced the net_rand_state[] array with 4
members to fix a build issue; cosmetic cleanups to make checkpatch
happy ]
Signed-off-by: Willy Tarreau
---
drivers/char/random.c | 1 -
include/linux/prandom.h | 36 +++-
kernel/time/timer.c | 7 -
lib/random32.c | 433
4 files changed, 296 insertions(+), 181 deletions(-)
diff --git a/drivers/char/random.c b/drivers/char/random.c
index d20ba1b104ca..2a41b21623ae 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -1277,7 +1277,6 @@ void add_interrupt_randomness(int irq, int irq_flags)
fast_mix(fast_pool);
add_interrupt_bench(cycles);
- this_cpu_add(net_rand_state.s1, fast_pool->pool[cycles & 3]);
if (unlikely(crng_init == 0)) {
if ((fast_pool->count >= 64) &&
diff --git a/include/linux/prandom.h b/include/linux/prandom.h
index aa16e6468f91..cc1e71334e53 100644
--- a/include/linux/prandom.h
+++ b/include/linux/prandom.h
@@ -16,12 +16,44 @@ void prandom_bytes(void *buf, size_t nbytes);
void prandom_seed(u32 seed);
void prandom_reseed_late(void);
+#if BITS_PER_LONG == 64
+/*
+ * The core SipHash round function. Each line can be executed in
+ * parallel given enough CPU resources.
+ */
+#define PRND_SIPROUND(v0, v1, v2, v3) ( \
+ v0 += v1, v1 = rol64(v1, 13), v2 += v3, v3 = rol64(v3, 16), \
+ v1 ^= v0, v0 = rol64(v0, 32), v3 ^= v2, \
+ v0 += v3, v3 = rol64(v3, 21), v2 += v1, v1 = rol64(v1, 17), \
+ v3 ^= v0, v1 ^= v2, v2 = rol64(v2, 32) \
+)
+
+#define PRND_K0 (0x736f6d6570736575 ^ 0x6c7967656e657261)
+#define PRND_K1 (0x646f72616e646f6d ^ 0x7465646279746573)
+
+#elif BITS_PER_LONG == 32
+/*
+ * On 32-bit machines, we use HSipHash, a reduced-width version of SipHash.
+ * This is weaker, but 32-bit machines are not used for high-traffic
+ * applications, so there is less output for an attacker to analyze.
+ */
+#define PRND_SIPROUND(v0, v1, v2, v3) ( \
+ v0 += v1, v1 = rol32(v1, 5), v2 += v3, v3 = rol32(v3, 8), \
+ v1 ^= v0, v0 = rol32(v0, 16), v3 ^= v2, \
+ v0 += v3, v3 = rol32(v3, 7), v2 += v1, v1 = rol32(v1, 13), \
+ v3 ^= v0, v1 ^= v2, v2 = rol32(v2, 16) \
+)
+#define PRND_K0 0x6c796765
+#define PRND_K1 0x74656462
+
+#else
+#error Unsupported BITS_PER_LONG
+#endif
+
struct rnd_state {
__u32 s1, s2, s3, s4;
};
-DECLARE_PER_CPU(struct rnd_state, net_rand_state);
-
u32 prandom_u32_state(struct rnd_state *state);
void prandom_bytes_state(struct rnd_state *state, void *buf, size_t nbytes);
void prandom_seed_full_state(struct rnd_state __percpu *pcpu_state);
diff --git a/kernel/time/timer.c b/kernel/time/timer.c
index a50364df1054..401fcb9d7388 100644
--- a/kernel/time/timer.c
+++ b/kernel/time/timer.c
@@ -1715,13 +1715,6 @@ void update_process_times(int user_tick)
scheduler_tick();
if (IS_ENABLED(CONFIG_POSIX_TIMERS))
run_posix_cpu_timers();
-
- /* The current CPU might make use of net randoms without receiving IRQs
-* to renew them often enough. Let's update the net_rand_state from a
-* non-constant value that's not affine
[PATCH 2/2] random32: add noise from network and scheduling activity
With the removal of the interrupt perturbations in previous random32
change (random32: make prandom_u32() output unpredictable), the PRNG
has become 100% deterministic again. While SipHash is expected to be
way more robust against brute force than the previous Tausworthe LFSR,
there's still the risk that whoever has even one temporary access to
the PRNG's internal state is able to predict all subsequent draws till
the next reseed (roughly every minute). This may happen through a side
channel attack or any data leak.
This patch restores the spirit of commit f227e3ec3b5c ("random32: update
the net random state on interrupt and activity") in that it will perturb
the internal PRNG's statee using externally collected noise, except that
it will not pick that noise from the random pool's bits nor upon
interrupt, but will rather combine a few elements along the Tx path
that are collectively hard to predict, such as dev, skb and txq
pointers, packet length and jiffies values. These ones are combined
using a single round of SipHash into a single long variable that is
mixed with the net_rand_state upon each invocation.
The operation was inlined because it produces very small and efficient
code, typically 3 xor, 2 add and 2 rol. The performance was measured
to be the same (even very slightly better) than before the switch to
SipHash; on a 6-core 12-thread Core i7-8700k equipped with a 40G NIC
(i40e), the connection rate dropped from 556k/s to 555k/s while the
SYN cookie rate grew from 5.38 Mpps to 5.45 Mpps.
Link: https://lore.kernel.org/netdev/20200808152628.ga27...@sdf.org/
Cc: George Spelvin
Cc: Amit Klein
Cc: Eric Dumazet
Cc: "Jason A. Donenfeld"
Cc: Andy Lutomirski
Cc: Kees Cook
Cc: Thomas Gleixner
Cc: Peter Zijlstra
Cc: Linus Torvalds
Cc: ty...@mit.edu
Cc: Florian Westphal
Cc: Marc Plumb
Tested-by: Sedat Dilek
Signed-off-by: Willy Tarreau
---
include/linux/prandom.h | 19 +++
kernel/time/timer.c | 2 ++
lib/random32.c | 5 +
net/core/dev.c | 4
4 files changed, 30 insertions(+)
diff --git a/include/linux/prandom.h b/include/linux/prandom.h
index cc1e71334e53..aa7de3432e0f 100644
--- a/include/linux/prandom.h
+++ b/include/linux/prandom.h
@@ -16,6 +16,12 @@ void prandom_bytes(void *buf, size_t nbytes);
void prandom_seed(u32 seed);
void prandom_reseed_late(void);
+DECLARE_PER_CPU(unsigned long, net_rand_noise);
+
+#define PRANDOM_ADD_NOISE(a, b, c, d) \
+ prandom_u32_add_noise((unsigned long)(a), (unsigned long)(b), \
+ (unsigned long)(c), (unsigned long)(d))
+
#if BITS_PER_LONG == 64
/*
* The core SipHash round function. Each line can be executed in
@@ -50,6 +56,18 @@ void prandom_reseed_late(void);
#error Unsupported BITS_PER_LONG
#endif
+static inline void prandom_u32_add_noise(unsigned long a, unsigned long b,
+unsigned long c, unsigned long d)
+{
+ /*
+* This is not used cryptographically; it's just
+* a convenient 4-word hash function. (3 xor, 2 add, 2 rol)
+*/
+ a ^= __this_cpu_read(net_rand_noise);
+ PRND_SIPROUND(a, b, c, d);
+ __this_cpu_write(net_rand_noise, d);
+}
+
struct rnd_state {
__u32 s1, s2, s3, s4;
};
@@ -99,6 +117,7 @@ static inline void prandom_seed_state(struct rnd_state
*state, u64 seed)
state->s2 = __seed(i, 8U);
state->s3 = __seed(i, 16U);
state->s4 = __seed(i, 128U);
+ PRANDOM_ADD_NOISE(state, i, 0, 0);
}
/* Pseudo random number generator from numerical recipes. */
diff --git a/kernel/time/timer.c b/kernel/time/timer.c
index 401fcb9d7388..bebcf2fc1226 100644
--- a/kernel/time/timer.c
+++ b/kernel/time/timer.c
@@ -1704,6 +1704,8 @@ void update_process_times(int user_tick)
{
struct task_struct *p = current;
+ PRANDOM_ADD_NOISE(jiffies, user_tick, p, 0);
+
/* Note: this timer irq context must be accounted for as well. */
account_process_tick(p, user_tick);
run_local_timers();
diff --git a/lib/random32.c b/lib/random32.c
index 00fa925a4487..38db382a8cf5 100644
--- a/lib/random32.c
+++ b/lib/random32.c
@@ -324,6 +324,8 @@ struct siprand_state {
};
static DEFINE_PER_CPU(struct siprand_state, net_rand_state) __latent_entropy;
+DEFINE_PER_CPU(unsigned long, net_rand_noise);
+EXPORT_PER_CPU_SYMBOL(net_rand_noise);
/*
* This is the core CPRNG function. As "pseudorandom", this is not used
@@ -347,9 +349,12 @@ static DEFINE_PER_CPU(struct siprand_state,
net_rand_state) __latent_entropy;
static inline u32 siprand_u32(struct siprand_state *s)
{
unsigned long v0 = s->v0, v1 = s->v1, v2 = s->v2, v3 = s->v3;
+ unsigned long n = __this_cpu_read(net_rand_noise);
+ v3 ^= n;
PRND_SIPROUND(v0, v1, v2, v3);
PRND_SIPROUND(v0, v1, v2, v3);
+ v0 ^= n;
s->v0 = v0; s->v1 = v1; s->v2 = v2; s->v3 = v3;
return v1 + v3;
}
diff --git a/net/core/dev.c b/net/c
Re: [PATCH v2 10/23] microblaze: use asm-generic/mmu_context.h for no-op implementations
On 01. 09. 20 8:15, Nicholas Piggin wrote:
> Excerpts from Michal Simek's message of September 1, 2020 12:15 am:
>>
>>
>> On 26. 08. 20 16:52, Nicholas Piggin wrote:
>>> Cc: Michal Simek
>>> Signed-off-by: Nicholas Piggin
>>> ---
>>> arch/microblaze/include/asm/mmu_context_mm.h | 8
>>> arch/microblaze/include/asm/processor.h | 3 ---
>>> 2 files changed, 4 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/arch/microblaze/include/asm/mmu_context_mm.h
>>> b/arch/microblaze/include/asm/mmu_context_mm.h
>>> index a1c7dd48454c..c2c77f708455 100644
>>> --- a/arch/microblaze/include/asm/mmu_context_mm.h
>>> +++ b/arch/microblaze/include/asm/mmu_context_mm.h
>>> @@ -33,10 +33,6 @@
>>> to represent all kernel pages as shared among all contexts.
>>> */
>>>
>>> -static inline void enter_lazy_tlb(struct mm_struct *mm, struct task_struct
>>> *tsk)
>>> -{
>>> -}
>>> -
>>> # define NO_CONTEXT256
>>> # define LAST_CONTEXT 255
>>> # define FIRST_CONTEXT 1
>>> @@ -105,6 +101,7 @@ static inline void get_mmu_context(struct mm_struct *mm)
>>> /*
>>> * We're finished using the context for an address space.
>>> */
>>> +#define destroy_context destroy_context
>>> static inline void destroy_context(struct mm_struct *mm)
>>> {
>>> if (mm->context != NO_CONTEXT) {
>>> @@ -126,6 +123,7 @@ static inline void switch_mm(struct mm_struct *prev,
>>> struct mm_struct *next,
>>> * After we have set current->mm to a new value, this activates
>>> * the context for the new mm so we see the new mappings.
>>> */
>>> +#define activate_mm activate_mm
>>> static inline void activate_mm(struct mm_struct *active_mm,
>>> struct mm_struct *mm)
>>> {
>>> @@ -136,5 +134,7 @@ static inline void activate_mm(struct mm_struct
>>> *active_mm,
>>>
>>> extern void mmu_context_init(void);
>>>
>>> +#include
>>> +
>>> # endif /* __KERNEL__ */
>>> #endif /* _ASM_MICROBLAZE_MMU_CONTEXT_H */
>>> diff --git a/arch/microblaze/include/asm/processor.h
>>> b/arch/microblaze/include/asm/processor.h
>>> index 1ff5a82b76b6..616211871a6e 100644
>>> --- a/arch/microblaze/include/asm/processor.h
>>> +++ b/arch/microblaze/include/asm/processor.h
>>> @@ -122,9 +122,6 @@ unsigned long get_wchan(struct task_struct *p);
>>> # define KSTK_EIP(task) (task_pc(task))
>>> # define KSTK_ESP(task) (task_sp(task))
>>>
>>> -/* FIXME */
>>> -# define deactivate_mm(tsk, mm) do { } while (0)
>>> -
>>> # define STACK_TOPTASK_SIZE
>>> # define STACK_TOP_MAXSTACK_TOP
>>>
>>>
>>
>> I am fine with the patch but I pretty much don't like that commit
>> message is empty and there is only subject.
>> With fixing that you can add my:
>> Acked-by: Michal Simek
>
> Thanks for the review, will do. Any suggestion for a useful commit message?
What about?
Wire asm-generic/mmu_context.h to provide generic empty hooks for arch
code simplification.
Thanks,
Michal
[PATCH] zram: add restriction on dynamic zram device creation
From: zhanglin
Add max_num_devices to limit dynamic zram device creation to prevent
potential OOM
Signed-off-by: zhanglin
---
drivers/block/zram/zram_drv.c | 26 +++---
1 file changed, 19 insertions(+), 7 deletions(-)
diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index 36d49159140f..4f2c4eef5051 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -43,8 +43,9 @@ static DEFINE_MUTEX(zram_index_mutex);
static int zram_major;
static const char *default_compressor = "lzo-rle";
-/* Module params (documentation at end) */
static unsigned int num_devices = 1;
+/* Module params (documentation at end) */
+static unsigned int max_num_devices = 8;
/*
* Pages that compress to sizes equals or greater than this are stored
* uncompressed in memory.
@@ -2013,10 +2014,16 @@ static ssize_t hot_add_show(struct class *class,
struct class_attribute *attr,
char *buf)
{
- int ret;
+ int ret = -ENOSPC;
mutex_lock(&zram_index_mutex);
+ if (num_devices >= max_num_devices) {
+ mutex_unlock(&zram_index_mutex);
+ return ret;
+ }
ret = zram_add();
+ if (ret >= 0)
+ num_devices += 1;
mutex_unlock(&zram_index_mutex);
if (ret < 0)
@@ -2046,8 +2053,10 @@ static ssize_t hot_remove_store(struct class *class,
zram = idr_find(&zram_index_idr, dev_id);
if (zram) {
ret = zram_remove(zram);
- if (!ret)
+ if (!ret) {
idr_remove(&zram_index_idr, dev_id);
+ num_devices -= 1;
+ }
} else {
ret = -ENODEV;
}
@@ -2089,6 +2098,7 @@ static void destroy_devices(void)
static int __init zram_init(void)
{
int ret;
+ unsigned int i;
ret = cpuhp_setup_state_multi(CPUHP_ZCOMP_PREPARE, "block/zram:prepare",
zcomp_cpu_up_prepare, zcomp_cpu_dead);
@@ -2111,13 +2121,15 @@ static int __init zram_init(void)
return -EBUSY;
}
- while (num_devices != 0) {
+ if (num_devices > max_num_devices)
+ num_devices = max_num_devices;
+
+ for (i = 0; i < num_devices; i++) {
mutex_lock(&zram_index_mutex);
ret = zram_add();
mutex_unlock(&zram_index_mutex);
if (ret < 0)
goto out_error;
- num_devices--;
}
return 0;
@@ -2135,8 +2147,8 @@ static void __exit zram_exit(void)
module_init(zram_init);
module_exit(zram_exit);
-module_param(num_devices, uint, 0);
-MODULE_PARM_DESC(num_devices, "Number of pre-created zram devices");
+module_param(max_num_devices, uint, 0);
+MODULE_PARM_DESC(max_num_devices, "Max number of created zram devices");
MODULE_LICENSE("Dual BSD/GPL");
MODULE_AUTHOR("Nitin Gupta ");
--
2.17.1
Re: [RFC v8 00/10] DAMON: Support Physical Memory Address Space Monitoring
On Mon, 31 Aug 2020 12:47:20 +0200 SeongJae Park wrote: > From: SeongJae Park > > Changes from Previous Version > = > > - Add missed 'put_page()' calls > - Support unmapped LRU pages Forgot mentioning the people who suggested the changes, sorry. The first one is suggested by Alkaid, and the second one is suggested by Shakeel Butt. Thanks, SeongJae Park [...]
Re: [PATCH v3 0/6] tracing: export event trace and trace_marker
Hi Mathieu, May I know your comments for this patch set? Thanks, Tingwei On Thu, Aug 13, 2020 at 09:45:46AM +0800, Tingwei Zhang wrote: > Ftrace has ability to export trace packets to other destination. > Currently, only function trace can be exported. This series extends the > support to event trace and trace_maker. STM is one possible destination to > export ftrace. Use separate channel for each CPU to avoid mixing up > packets > from different CPUs together. > > Change from v2: > Change flag definition to BIT(). (Steven) > Add comment in stm_ftrace_write() to clarify it's safe to use > smp_processor_id() here since preempt is disabled. (Steven) > > Change from v1: > All changes are suggested by Steven Rostedt. > User separate flag to control function trace, event trace and trace mark. > Allocate channels according to num_possible_cpu() dynamically. > Move ftrace_exports routines up so all ftrace can use them. > > Tingwei Zhang (6): > stm class: ftrace: change dependency to TRACING > tracing: add flag to control different traces > tracing: add trace_export support for event trace > tracing: add trace_export support for trace_marker > stm class: ftrace: enable supported trace export flag > stm class: ftrace: use different channel accroding to CPU > > drivers/hwtracing/stm/Kconfig | 2 +- > drivers/hwtracing/stm/ftrace.c | 7 +- > include/linux/trace.h | 7 + > kernel/trace/trace.c | 270 ++--- > 4 files changed, 159 insertions(+), 127 deletions(-) > > -- > The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, > a Linux Foundation Collaborative Project >
Re: [PATCH] coresight: cti: write regsiters directly in cti_enable_hw()
On Tue, Sep 01, 2020 at 04:28:19AM +0800, Mathieu Poirier wrote: > On Fri, Aug 28, 2020 at 11:18:18AM +0800, Tingwei Zhang wrote: > > On Fri, Aug 28, 2020 at 02:12:53AM +0800, Mathieu Poirier wrote: > > > Hi Tingwei, > > > > > > On Tue, Aug 18, 2020 at 07:10:57PM +0800, Tingwei Zhang wrote: > > > > Deadlock as below is triggered by one CPU holds drvdata->spinlock > > > > and calls cti_enable_hw(). Smp_call_function_single() is called > > > > in cti_enable_hw() and tries to let another CPU write CTI registers. > > > > That CPU is trying to get drvdata->spinlock in cti_cpu_pm_notify() > > > > and doesn't response to IPI from smp_call_function_single(). > > > > > > > > [ 988.335937] CPU: 6 PID: 10258 Comm: sh Tainted: GWL > > > > 5.8.0-rc6-mainline-16783-gc38daa79b26b-dirty #1 > > > > [ 988.346364] Hardware name: Thundercomm Dragonboard 845c (DT) > > > > [ 988.352073] pstate: 2045 (nzCv daif +PAN -UAO BTYPE=--) > > > > [ 988.357689] pc : smp_call_function_single+0x158/0x1b8 > > > > [ 988.362782] lr : smp_call_function_single+0x124/0x1b8 > > > > ... > > > > [ 988.451638] Call trace: > > > > [ 988.454119] smp_call_function_single+0x158/0x1b8 > > > > [ 988.458866] cti_enable+0xb4/0xf8 [coresight_cti] > > > > [ 988.463618] coresight_control_assoc_ectdev+0x6c/0x128 > [coresight] > > > > [ 988.469855] coresight_enable+0x1f0/0x364 [coresight] > > > > [ 988.474957] enable_source_store+0x5c/0x9c [coresight] > > > > [ 988.480140] dev_attr_store+0x14/0x28 > > > > [ 988.483839] sysfs_kf_write+0x38/0x4c > > > > [ 988.487532] kernfs_fop_write+0x1c0/0x2b0 > > > > [ 988.491585] vfs_write+0xfc/0x300 > > > > [ 988.494931] ksys_write+0x78/0xe0 > > > > [ 988.498283] __arm64_sys_write+0x18/0x20 > > > > [ 988.502240] el0_svc_common+0x98/0x160 > > > > [ 988.506024] do_el0_svc+0x78/0x80 > > > > [ 988.509377] el0_sync_handler+0xd4/0x270 > > > > [ 988.513337] el0_sync+0x164/0x180 > > > > > > > > > > Was this the full log or you did cut some of it? > > > > > > > I cut some CPU registers' value since it's too long and not relevant. > > The Call trace is full. > > > > > > This change write CTI registers directly in cti_enable_hw(). > > > > Config->hw_powered has been checked to be true with spinlock holded. > > > > CTI is powered and can be programmed until spinlock is released. > > > > > > > > > > From your explanation above it seems that cti_enable_hw() was called > from, > > > say > > > CPUy, to enable the CTI associated to CPUx. CTIx's drvdata->spinlock > was > > > taken > > > and smp_call_function_single() called right after. That woke up CPUx > and > > > cti_cpu_pm_notify() was executed on CPUx in interrupt context, trying > to > > > take > > > CTIx's drvdata->spinlock. That hung CPUx and the kernel got angry. > Is my > > > assessment correct? > > > > > > > Most of them is correct. The only difference is CPUx is power on when > > cti_enable_hw() is called. Otherwise it will goto cti_state_unchanged: > > and won't call cti_enable_hw_smp_call(). cti_cpu_pm_notify() is called > > when CPUx tries to suspend instead of resume. > > > > > If so I don't think the fix suggested in this patch will work. The > same > > > condition will happen whenever cti_enable_hw() is called on a CPU to > > > enable a > > > CTI that belongs to another CPU and that cti_cpu_pm_notify() is called > on > > > latter > > > CPU at the same time. > > > > > > > I'm not sure I understand this correctly. Let me clarify it a little > bit. > > It's a deadlock since cti_enable_hw() holds the spinlock and calls > > cti_enable_hw_smp_call() from CPUx to enable CTI associated to CPUy. It > > waits for cti_enable_hw_smp_call() to return. IPI is sent to CPUy while > > CPUy is in cti_cpu_pm_notify() and waits for spinlock. In this patch, > > I remove cti_enable_hw_smp_call() and write CTI CPU directly on CPUx. > > It won't wait for CPUy and release spinlock after program registers of > > CTI. After cti_enable_hw() releases spinlock, cti_cpu_pm_notify() will > > continue to run. Since spinlock is held and config->hw_powered is true, > > we don't need to worry about CPUy power down when we program CTI on > CPUx. > > > > > I think a better solution is to grab the lock in cti_enable_hw() and > check > > > the > > > value of ->ctidev.cpu. If not a global CPU, i.e >= 0, then release > the > > > lock and > > > call smp_call_function_single(). In cti_enable_hw_smp_call() take the > > > lock > > > again and move forward from there. > > > > > > > After cti_enable_hw() releases the lock, it's possible that CPU is > offline > > by user, cti_enable_hw_smp_call() will fail in this case. > > > > > > I took another look at your solution and you are correct, CPUy won't lock > but > rather spin waiting for cti_enable_hw() to finish on CPUx. To make sure > CPUx is > not interrupted while executing cti_enable_hw() I suggest to use > spin_lock_irq(). > > Thanks, > Mathieu > Sure. I've sent v2 according to your comm
Re: [RFC v8 01/10] mm/damon/debugfs: Allow users to set initial monitoring target regions
On Mon, 31 Aug 2020 20:08:44 +0200 Marco Elver wrote:
> On Mon, Aug 31, 2020 at 12:47PM +0200, SeongJae Park wrote:
> [...]
> > diff --git a/mm/damon.c b/mm/damon.c
> > index 7e3c8c82a010..9815d22fc4de 100644
> > --- a/mm/damon.c
> > +++ b/mm/damon.c
> > @@ -2001,6 +2001,147 @@ static ssize_t debugfs_record_write(struct file
> > *file,
> > return ret;
> > }
> >
> > +static ssize_t sprint_init_regions(struct damon_ctx *c, char *buf, ssize_t
> > len)
> > +{
> > + struct damon_target *t;
> > + struct damon_region *r;
> > + int written = 0;
> > + int rc;
> > +
> > + damon_for_each_target(t, c) {
> > + damon_for_each_region(r, t) {
> > + rc = snprintf(&buf[written], len - written,
> > + "%lu %lu %lu\n",
> > + t->id, r->ar.start, r->ar.end);
>
> This most likely will not work as intended, because snprintf() returns
> "[...] the number of characters which would be generated for the given
> input, excluding the trailing null [...]". Would scnprintf() -- which
> returns "[...] the number of characters written into @buf not including
> the trailing '\0' [...]" -- do what you intended?
Ah, you're right! I will use 'scnprintf' instead, not only here but in other
relevant parts.
Thanks,
SeongJae Park
>
> > + if (!rc)
> > + return -ENOMEM;
> > + written += rc;
> > + }
> > + }
> > + return written;
> > +}
> [...]
[PATCH v2] coresight: cti: write regsiters directly in cti_enable_hw()
Deadlock as below is triggered by one CPU holds drvdata->spinlock
and calls cti_enable_hw(). Smp_call_function_single() is called
in cti_enable_hw() and tries to let another CPU write CTI registers.
That CPU is trying to get drvdata->spinlock in cti_cpu_pm_notify()
and doesn't response to IPI from smp_call_function_single().
[ 988.335937] CPU: 6 PID: 10258 Comm: sh Tainted: GWL
5.8.0-rc6-mainline-16783-gc38daa79b26b-dirty #1
[ 988.346364] Hardware name: Thundercomm Dragonboard 845c (DT)
[ 988.352073] pstate: 2045 (nzCv daif +PAN -UAO BTYPE=--)
[ 988.357689] pc : smp_call_function_single+0x158/0x1b8
[ 988.362782] lr : smp_call_function_single+0x124/0x1b8
...
[ 988.451638] Call trace:
[ 988.454119] smp_call_function_single+0x158/0x1b8
[ 988.458866] cti_enable+0xb4/0xf8 [coresight_cti]
[ 988.463618] coresight_control_assoc_ectdev+0x6c/0x128 [coresight]
[ 988.469855] coresight_enable+0x1f0/0x364 [coresight]
[ 988.474957] enable_source_store+0x5c/0x9c [coresight]
[ 988.480140] dev_attr_store+0x14/0x28
[ 988.483839] sysfs_kf_write+0x38/0x4c
[ 988.487532] kernfs_fop_write+0x1c0/0x2b0
[ 988.491585] vfs_write+0xfc/0x300
[ 988.494931] ksys_write+0x78/0xe0
[ 988.498283] __arm64_sys_write+0x18/0x20
[ 988.502240] el0_svc_common+0x98/0x160
[ 988.506024] do_el0_svc+0x78/0x80
[ 988.509377] el0_sync_handler+0xd4/0x270
[ 988.513337] el0_sync+0x164/0x180
This change write CTI registers directly in cti_enable_hw().
Config->hw_powered has been checked to be true with spinlock holded.
CTI is powered and can be programmed until spinlock is released.
Fixes: 6a0953ce7de9 ("coresight: cti: Add CPU idle pm notifer to CTI devices")
Signed-off-by: Tingwei Zhang
---
drivers/hwtracing/coresight/coresight-cti.c | 24 +
1 file changed, 5 insertions(+), 19 deletions(-)
diff --git a/drivers/hwtracing/coresight/coresight-cti.c
b/drivers/hwtracing/coresight/coresight-cti.c
index c4e9cc7034ab..d04181c12a7f 100644
--- a/drivers/hwtracing/coresight/coresight-cti.c
+++ b/drivers/hwtracing/coresight/coresight-cti.c
@@ -86,22 +86,16 @@ void cti_write_all_hw_regs(struct cti_drvdata *drvdata)
CS_LOCK(drvdata->base);
}
-static void cti_enable_hw_smp_call(void *info)
-{
- struct cti_drvdata *drvdata = info;
-
- cti_write_all_hw_regs(drvdata);
-}
-
/* write regs to hardware and enable */
static int cti_enable_hw(struct cti_drvdata *drvdata)
{
struct cti_config *config = &drvdata->config;
struct device *dev = &drvdata->csdev->dev;
int rc = 0;
+ unsigned long flags;
pm_runtime_get_sync(dev->parent);
- spin_lock(&drvdata->spinlock);
+ spin_lock_irqsave(&drvdata->spinlock, flags);
/* no need to do anything if enabled or unpowered*/
if (config->hw_enabled || !config->hw_powered)
@@ -112,19 +106,11 @@ static int cti_enable_hw(struct cti_drvdata *drvdata)
if (rc)
goto cti_err_not_enabled;
- if (drvdata->ctidev.cpu >= 0) {
- rc = smp_call_function_single(drvdata->ctidev.cpu,
- cti_enable_hw_smp_call,
- drvdata, 1);
- if (rc)
- goto cti_err_not_enabled;
- } else {
- cti_write_all_hw_regs(drvdata);
- }
+ cti_write_all_hw_regs(drvdata);
config->hw_enabled = true;
atomic_inc(&drvdata->config.enable_req_count);
- spin_unlock(&drvdata->spinlock);
+ spin_unlock_irqrestore(&drvdata->spinlock, flags);
return rc;
cti_state_unchanged:
@@ -132,7 +118,7 @@ static int cti_enable_hw(struct cti_drvdata *drvdata)
/* cannot enable due to error */
cti_err_not_enabled:
- spin_unlock(&drvdata->spinlock);
+ spin_unlock_irqrestore(&drvdata->spinlock, flags);
pm_runtime_put(dev->parent);
return rc;
}
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH] drm/radeon: Reset ASIC if suspend is not managed by platform firmware
Suspend with s2idle or by the following steps cause screen frozen:
# echo devices > /sys/power/pm_test
# echo freeze > /sys/power/mem
[ 289.625461] [drm:uvd_v1_0_ib_test [radeon]] *ERROR* radeon: fence wait timed
out.
[ 289.625494] [drm:radeon_ib_ring_tests [radeon]] *ERROR* radeon: failed
testing IB on ring 5 (-110).
The issue doesn't happen on traditional S3, probably because firmware or
hardware provides extra power management.
Inspired by Daniel Drake's patch [1] on amdgpu, using a similar approach
can fix the issue.
[1] https://patchwork.freedesktop.org/patch/335839/
Signed-off-by: Kai-Heng Feng
---
drivers/gpu/drm/radeon/radeon_device.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/radeon/radeon_device.c
b/drivers/gpu/drm/radeon/radeon_device.c
index 266e3cbbd09b..df823b9ad79f 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -33,6 +33,7 @@
#include
#include
#include
+#include
#include
#include
@@ -1643,6 +1644,8 @@ int radeon_suspend_kms(struct drm_device *dev, bool
suspend,
rdev->asic->asic_reset(rdev, true);
pci_restore_state(dev->pdev);
} else if (suspend) {
+ if (pm_suspend_no_platform())
+ rdev->asic->asic_reset(rdev, true);
/* Shut down the device */
pci_disable_device(dev->pdev);
pci_set_power_state(dev->pdev, PCI_D3hot);
--
2.17.1
Re: [PATCH v3 3/3] mm/armv6: work around armv6 cmpxchg support issue
seems there are couples archs can not do cmpxchg1
So update the patch here. And it's easy to fix if more arch issue find here.
>From cdf98ae7b5e83bb7210c927d4749f62fee4ed115 Mon Sep 17 00:00:00 2001
From: Alex Shi
Date: Mon, 31 Aug 2020 15:41:20 +0800
Subject: [PATCH v4 3/3] mm/pageblock: work around multiple arch's cmpxchg
support issue
Armv6, sh2, sparc32 and xtensa can not do cmpxchg1, so we have to use
cmpxchg4 on it.
arm-linux-gnueabi-ld: mm/page_alloc.o: in function `set_pfnblock_flags_mask':
(.text+0x32b4): undefined reference to `__bad_cmpxchg'
arm-linux-gnueabi-ld: (.text+0x32e0): undefined reference to `__bad_cmpxchg'
Reported-by: kernel test robot
Signed-off-by: Alex Shi
Cc: Andrew Morton
Cc: Baolin Wang
Cc: Russell King
Cc: linux...@kvack.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
---
include/linux/mmzone.h | 20 +---
mm/page_alloc.c| 24
2 files changed, 29 insertions(+), 15 deletions(-)
diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index be676e659fb7..364b29ed99b3 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -406,6 +406,20 @@ enum zone_type {
#ifndef __GENERATING_BOUNDS_H
+/*
+ * cmpxchg only support 32-bits operands on the following archs ARMv6, SPARC32
+ * sh2, XTENSA.
+ */
+#if defined(CONFIG_CPU_V6) || defined(CONFIG_CPU_SH2) || \
+ defined(CONFIG_SPARC32) || defined(CONFIG_XTENSA)
+
+#define BITS_PER_FLAGS BITS_PER_LONG
+typedef unsigned long pageblockflags_t;
+#else
+#define BITS_PER_FLAGS BITS_PER_BYTE
+typedef unsigned char pageblockflags_t;
+#endif
+
struct zone {
/* Read-mostly fields */
@@ -437,7 +451,7 @@ struct zone {
* Flags for a pageblock_nr_pages block. See pageblock-flags.h.
* In SPARSEMEM, this map is stored in struct mem_section
*/
- unsigned char *pageblock_flags;
+ pageblockflags_t*pageblock_flags;
#endif /* CONFIG_SPARSEMEM */
/* zone_start_pfn == zone_start_paddr >> PAGE_SHIFT */
@@ -1159,7 +1173,7 @@ struct mem_section_usage {
DECLARE_BITMAP(subsection_map, SUBSECTIONS_PER_SECTION);
#endif
/* See declaration of similar field in struct zone */
- unsigned char pageblock_flags[0];
+ pageblockflags_tpageblock_flags[0];
};
void subsection_map_init(unsigned long pfn, unsigned long nr_pages);
@@ -1212,7 +1226,7 @@ struct mem_section {
extern struct mem_section mem_section[NR_SECTION_ROOTS][SECTIONS_PER_ROOT];
#endif
-static inline unsigned char *section_to_usemap(struct mem_section *ms)
+static inline pageblockflags_t *section_to_usemap(struct mem_section *ms)
{
return ms->usage->pageblock_flags;
}
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 60342e764090..9a41c5dc78eb 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -445,7 +445,7 @@ static inline bool defer_init(int nid, unsigned long pfn,
unsigned long end_pfn)
#endif
/* Return a pointer to the bitmap storing bits affecting a block of pages */
-static inline unsigned char *get_pageblock_bitmap(struct page *page,
+static inline pageblockflags_t *get_pageblock_bitmap(struct page *page,
unsigned long pfn)
{
#ifdef CONFIG_SPARSEMEM
@@ -474,24 +474,24 @@ static inline int pfn_to_bitidx(struct page *page,
unsigned long pfn)
* Return: pageblock_bits flags
*/
static __always_inline
-unsigned char __get_pfnblock_flags_mask(struct page *page,
+pageblockflags_t __get_pfnblock_flags_mask(struct page *page,
unsigned long pfn,
unsigned long mask)
{
- unsigned char *bitmap;
+ pageblockflags_t *bitmap;
unsigned long bitidx, byte_bitidx;
- unsigned char byte;
+ pageblockflags_t byte;
bitmap = get_pageblock_bitmap(page, pfn);
bitidx = pfn_to_bitidx(page, pfn);
- byte_bitidx = bitidx / BITS_PER_BYTE;
- bitidx &= (BITS_PER_BYTE-1);
+ byte_bitidx = bitidx / BITS_PER_FLAGS;
+ bitidx &= (BITS_PER_FLAGS - 1);
byte = bitmap[byte_bitidx];
return (byte >> bitidx) & mask;
}
-unsigned char get_pfnblock_flags_mask(struct page *page, unsigned long pfn,
+pageblockflags_t get_pfnblock_flags_mask(struct page *page, unsigned long pfn,
unsigned long mask)
{
return __get_pfnblock_flags_mask(page, pfn, mask);
@@ -513,17 +513,17 @@ void set_pfnblock_flags_mask(struct page *page, unsigned
long flags,
unsigned long pfn,
unsigned long mask)
{
- unsigned char *bitmap;
+ pageblockflags_t *bitmap;
unsigned long bitidx, byte_bitidx;
- unsigned char old_byte, byte;
+ pageblockflags_t old_byte, byte;
- BUILD_BUG_ON(NR_PAGEBLOCK_BITS != BITS_PER_BYTE);
+ BUILD_BUG_ON(
Re: [PATCH 1/6] kprobes: tracing/kprobes: Fix to kill kprobes on initmem after boot
On Tue, 1 Sep 2020 00:25:58 +0800 kernel test robot wrote: > Hi Masami, > > I love your patch! Yet something to improve: > > [auto build test ERROR on tip/perf/core] > [also build test ERROR on trace/for-next lwn/docs-next linus/master v5.9-rc3 > next-20200828] > [If your patch is applied to the wrong git tree, kindly drop us a note. > And when submitting patch, we suggest to use '--base' as documented in > https://git-scm.com/docs/git-format-patch] > > url: > https://github.com/0day-ci/linux/commits/Masami-Hiramatsu/tracing-boot-Add-new-options-for-tracing-specific-period/20200831-204738 > base: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git > 2cb5383b30d47c446ec7d884cd80f93ffcc31817 > config: arc-defconfig (attached as .config) > compiler: arc-elf-gcc (GCC) 9.3.0 > reproduce (this is a W=1 build): > wget > https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O > ~/bin/make.cross > chmod +x ~/bin/make.cross > # save the attached .config to linux build tree > COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross > ARCH=arc > > If you fix the issue, kindly add following tag as appropriate > Reported-by: kernel test robot > > All errors (new ones prefixed by >>): > >arc-elf-ld: init/main.o: in function `kernel_init': > >> main.c:(.ref.text+0xa6): undefined reference to `kprobe_free_init_mem' > >> arc-elf-ld: main.c:(.ref.text+0xa6): undefined reference to > >> `kprobe_free_init_mem' OK, I missed to put the kprobe_free_init_mem() in the code depends on CONFIG_DEBUG_FS. I'll move this out. Thank you, -- Masami Hiramatsu
Re: [PATCH -next] staging: spmi: hisi-spmi-controller: Use proper format in call to dev_err()
Em Tue, 1 Sep 2020 11:57:22 +0800
YueHaibing escreveu:
> The correct format string for a size_t argument should be %zu.
>
> Signed-off-by: YueHaibing
Reviewed-by: Mauro Carvalho Chehab
> ---
> drivers/staging/hikey9xx/hisi-spmi-controller.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/staging/hikey9xx/hisi-spmi-controller.c
> b/drivers/staging/hikey9xx/hisi-spmi-controller.c
> index 66a0b296e06f..34c690da09e3 100644
> --- a/drivers/staging/hikey9xx/hisi-spmi-controller.c
> +++ b/drivers/staging/hikey9xx/hisi-spmi-controller.c
> @@ -121,7 +121,7 @@ static int spmi_read_cmd(struct spmi_controller *ctrl,
>
> if (bc > SPMI_CONTROLLER_MAX_TRANS_BYTES) {
> dev_err(&ctrl->dev,
> - "spmi_controller supports 1..%d bytes per trans,
> but:%ld requested\n",
> + "spmi_controller supports 1..%d bytes per trans,
> but:%zu requested\n",
> SPMI_CONTROLLER_MAX_TRANS_BYTES, bc);
> return -EINVAL;
> }
> @@ -175,7 +175,7 @@ static int spmi_read_cmd(struct spmi_controller *ctrl,
> spin_unlock_irqrestore(&spmi_controller->lock, flags);
> if (rc)
> dev_err(&ctrl->dev,
> - "spmi read wait timeout op:0x%x slave_id:%d
> slave_addr:0x%x bc:%ld\n",
> + "spmi read wait timeout op:0x%x slave_id:%d
> slave_addr:0x%x bc:%zu\n",
> opc, slave_id, slave_addr, bc + 1);
> else
> dev_dbg(&ctrl->dev, "%s: id:%d slave_addr:0x%x, read value:
> %*ph\n",
> @@ -197,7 +197,7 @@ static int spmi_write_cmd(struct spmi_controller *ctrl,
>
> if (bc > SPMI_CONTROLLER_MAX_TRANS_BYTES) {
> dev_err(&ctrl->dev,
> - "spmi_controller supports 1..%d bytes per trans,
> but:%ld requested\n",
> + "spmi_controller supports 1..%d bytes per trans,
> but:%zu requested\n",
> SPMI_CONTROLLER_MAX_TRANS_BYTES, bc);
> return -EINVAL;
> }
> @@ -251,7 +251,7 @@ static int spmi_write_cmd(struct spmi_controller *ctrl,
> spin_unlock_irqrestore(&spmi_controller->lock, flags);
>
> if (rc)
> - dev_err(&ctrl->dev, "spmi write wait timeout op:0x%x
> slave_id:%d slave_addr:0x%x bc:%ld\n",
> + dev_err(&ctrl->dev, "spmi write wait timeout op:0x%x
> slave_id:%d slave_addr:0x%x bc:%zu\n",
> opc, slave_id, slave_addr, bc);
> else
> dev_dbg(&ctrl->dev, "%s: id:%d slave_addr:0x%x, wrote value:
> %*ph\n",
Thanks,
Mauro
Re: [PATCH v2 09/23] m68k: use asm-generic/mmu_context.h for no-op implementations
Excerpts from Geert Uytterhoeven's message of August 27, 2020 7:33 pm:
> On Wed, Aug 26, 2020 at 4:53 PM Nicholas Piggin wrote:
>> Cc: Geert Uytterhoeven
>> Cc: linux-m...@lists.linux-m68k.org
>> Signed-off-by: Nicholas Piggin
>
> With the below fixed:
> Acked-by: Geert Uytterhoeven
>
>> --- a/arch/m68k/include/asm/mmu_context.h
>> +++ b/arch/m68k/include/asm/mmu_context.h
>> @@ -79,19 +76,6 @@ static inline void switch_mm(struct mm_struct *prev,
>> struct mm_struct *next,
>> set_context(tsk->mm->context, next->pgd);
>> }
>>
>> -/*
>> - * After we have set current->mm to a new value, this activates
>> - * the context for the new mm so we see the new mappings.
>> - */
>> -static inline void activate_mm(struct mm_struct *active_mm,
>> - struct mm_struct *mm)
>> -{
>> - get_mmu_context(mm);
>> - set_context(mm->context, mm->pgd);
>> -}
>
> Assumed switch_mm() in [PATCH v2 01/23] is revived with the above body.
I'm not sure what you mean here. We can remove this because it's a copy
of switch_mm above, and that's what the new header defaults to if you
don't provide an active_mm.
Patch 1 should not have changed that, it should only affect the nommu
architectures (and actually didn't touch m68k because it was not using
the asm-generic/mmu_context.h header).
Thanks,
Nick
[PATCH 5/5] drm_dp_cec: add the implementation of MST support
With DP v2.0 errata E5, CEC tunneling can be supported through an MST
topology.
There are some minor differences for CEC tunneling through an MST
topology compared to CEC tunneling to an SST port:
- CEC IRQs are delivered via a sink event notify message
- CEC-related DPCD registers are accessed via remote DPCD reads and
writes.
This results in the MST implementation diverging from the existing SST
implementation:
- sink event notify messages with CEC_IRQ ID set indicate CEC IRQ rather
than ESI1
- setting edid and handling CEC IRQs, which can be triggered from
contexts where locks held preclude HPD handling, are deferred to avoid
remote DPCD access which would block until HPD handling is performed
or a timeout
Register and unregister for all MST connectors, ensuring their
drm_dp_aux_cec struct won't be accessed uninitialized.
Signed-off-by: Sam McNally
---
drivers/gpu/drm/drm_dp_cec.c | 67 +--
drivers/gpu/drm/drm_dp_mst_topology.c | 24 ++
include/drm/drm_dp_helper.h | 4 ++
3 files changed, 90 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_cec.c b/drivers/gpu/drm/drm_dp_cec.c
index 04ab7b88055c..9f6aeaa27f00 100644
--- a/drivers/gpu/drm/drm_dp_cec.c
+++ b/drivers/gpu/drm/drm_dp_cec.c
@@ -249,6 +249,10 @@ void drm_dp_cec_irq(struct drm_dp_aux *aux)
if (!aux->transfer)
return;
+ if (aux->cec.is_mst) {
+ schedule_work(&aux->cec.mst_irq_work);
+ return;
+ }
mutex_lock(&aux->cec.lock);
if (!aux->cec.adap)
goto unlock;
@@ -277,6 +281,24 @@ static bool drm_dp_cec_cap(struct drm_dp_aux *aux, u8
*cec_cap)
return true;
}
+static void drm_dp_cec_mst_irq_work(struct work_struct *work)
+{
+ struct drm_dp_aux *aux = container_of(work, struct drm_dp_aux,
+ cec.mst_irq_work);
+ struct drm_dp_mst_port *port =
+ container_of(aux, struct drm_dp_mst_port, aux);
+
+ port = drm_dp_mst_topology_get_port_validated(port->mgr, port);
+ if (!port)
+ return;
+ mutex_lock(&aux->cec.lock);
+ if (aux->cec.adap)
+ drm_dp_cec_handle_irq(aux);
+
+ mutex_unlock(&aux->cec.lock);
+ drm_dp_mst_topology_put_port(port);
+}
+
/*
* Called if the HPD was low for more than drm_dp_cec_unregister_delay
* seconds. This unregisters the CEC adapter.
@@ -298,7 +320,8 @@ static void drm_dp_cec_unregister_work(struct work_struct
*work)
* were unchanged and just update the CEC physical address. Otherwise
* unregister the old CEC adapter and create a new one.
*/
-void drm_dp_cec_set_edid(struct drm_dp_aux *aux, const struct edid *edid)
+static void drm_dp_cec_handle_set_edid(struct drm_dp_aux *aux,
+ const struct edid *edid)
{
struct drm_connector *connector = aux->cec.connector;
u32 cec_caps = CEC_CAP_DEFAULTS | CEC_CAP_NEEDS_HPD |
@@ -307,10 +330,6 @@ void drm_dp_cec_set_edid(struct drm_dp_aux *aux, const
struct edid *edid)
unsigned int num_las = 1;
u8 cap;
- /* No transfer function was set, so not a DP connector */
- if (!aux->transfer)
- return;
-
#ifndef CONFIG_MEDIA_CEC_RC
/*
* CEC_CAP_RC is part of CEC_CAP_DEFAULTS, but it is stripped by
@@ -321,6 +340,7 @@ void drm_dp_cec_set_edid(struct drm_dp_aux *aux, const
struct edid *edid)
*/
cec_caps &= ~CEC_CAP_RC;
#endif
+ cancel_work_sync(&aux->cec.mst_irq_work);
cancel_delayed_work_sync(&aux->cec.unregister_work);
mutex_lock(&aux->cec.lock);
@@ -375,6 +395,18 @@ void drm_dp_cec_set_edid(struct drm_dp_aux *aux, const
struct edid *edid)
}
mutex_unlock(&aux->cec.lock);
}
+
+void drm_dp_cec_set_edid(struct drm_dp_aux *aux, const struct edid *edid)
+{
+ /* No transfer function was set, so not a DP connector */
+ if (!aux->transfer)
+ return;
+
+ if (aux->cec.is_mst)
+ schedule_work(&aux->cec.mst_set_edid_work);
+ else
+ drm_dp_cec_handle_set_edid(aux, edid);
+}
EXPORT_SYMBOL(drm_dp_cec_set_edid);
/*
@@ -393,6 +425,8 @@ void drm_dp_cec_unset_edid(struct drm_dp_aux *aux)
goto unlock;
cec_phys_addr_invalidate(aux->cec.adap);
+ cancel_work_sync(&aux->cec.mst_irq_work);
+
/*
* We're done if we want to keep the CEC device
* (drm_dp_cec_unregister_delay is >= NEVER_UNREG_DELAY) or if the
@@ -414,6 +448,25 @@ void drm_dp_cec_unset_edid(struct drm_dp_aux *aux)
}
EXPORT_SYMBOL(drm_dp_cec_unset_edid);
+static void drm_dp_cec_mst_set_edid_work(struct work_struct *work)
+{
+ struct drm_dp_aux *aux =
+ container_of(work, struct drm_dp_aux, cec.mst_set_edid_work);
+ struct drm_dp_mst_port *port =
+ container_of(aux, struct drm_dp_mst_port, aux)
Re: [PATCH] Documentation/x86/boot.rst: minor improvement
On 9/1/20 1:35 PM, H. Peter Anvin wrote: > If you are going to fix the language... > > On 2020-08-31 22:25, Cao jin wrote: >> Sorry, I mis-copied 2 addresses. make sure they are CCed. >> >> On 9/1/20 11:41 AM, Cao jin wrote: >>> Typo fix & file name update >>> I did quick search in dict & google, didn't see ident = identity, my omission. >>> Signed-off-by: Cao jin ... >>> @@ -1391,7 +1391,7 @@ In 64-bit boot protocol, the kernel is started by >>> jumping to the >>> >>> At entry, the CPU must be in 64-bit mode with paging enabled. > > (Paging enabled is redundant here.) Yes, 64-bit defaults with paging enabled. Maybe it is a little bit helpful for newbies. > >>> The range with setup_header.init_size from start address of loaded >>> -kernel and zero page and command line buffer get ident mapping; >>> +kernel and zero page and command line buffer get identity mapping; > > The range with setup_header.init_size from start address of the loaded kernel, > the zero page, and the command line buffer get identity-mapped, anda GDT must > be loaded with the descriptors for selectors __BOOT_CS(0x10) and > __BOOT_DS(0x18): both descriptors must be 4G flat segment with __BOOT_CS > having execute/read > permission and __BOOT_DS... > > Also, it might be useful to take a look to see if other data structures, like > setup_data and the initrd also need to be in the identity map. > Thanks for your info. I have indistinct memory that KASLR need them identity mapped. I will take a look. -- Sincerely, Cao jin
[PATCH 4/5] drm_dp_cec: add plumbing in preparation for MST support
From: Hans Verkuil
Signed-off-by: Hans Verkuil
[sa...@chromium.org:
- rebased
- removed polling-related changes
- moved the calls to drm_dp_cec_(un)set_edid() into the next patch
]
Signed-off-by: Sam McNally
---
.../display/amdgpu_dm/amdgpu_dm_mst_types.c | 2 +-
drivers/gpu/drm/drm_dp_cec.c | 22 ++-
drivers/gpu/drm/i915/display/intel_dp.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_connector.c | 2 +-
include/drm/drm_dp_helper.h | 6 +++--
5 files changed, 19 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index 461fa4da0a34..6e7075893ec9 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -419,7 +419,7 @@ void amdgpu_dm_initialize_dp_connector(struct
amdgpu_display_manager *dm,
drm_dp_aux_init(&aconnector->dm_dp_aux.aux);
drm_dp_cec_register_connector(&aconnector->dm_dp_aux.aux,
- &aconnector->base);
+ &aconnector->base, false);
if (aconnector->base.connector_type == DRM_MODE_CONNECTOR_eDP)
return;
diff --git a/drivers/gpu/drm/drm_dp_cec.c b/drivers/gpu/drm/drm_dp_cec.c
index 3ab2609f9ec7..04ab7b88055c 100644
--- a/drivers/gpu/drm/drm_dp_cec.c
+++ b/drivers/gpu/drm/drm_dp_cec.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
/*
* Unfortunately it turns out that we have a chicken-and-egg situation
@@ -338,8 +339,6 @@ void drm_dp_cec_set_edid(struct drm_dp_aux *aux, const
struct edid *edid)
if (aux->cec.adap) {
if (aux->cec.adap->capabilities == cec_caps &&
aux->cec.adap->available_log_addrs == num_las) {
- /* Unchanged, so just set the phys addr */
- cec_s_phys_addr_from_edid(aux->cec.adap, edid);
goto unlock;
}
/*
@@ -364,15 +363,16 @@ void drm_dp_cec_set_edid(struct drm_dp_aux *aux, const
struct edid *edid)
if (cec_register_adapter(aux->cec.adap, connector->dev->dev)) {
cec_delete_adapter(aux->cec.adap);
aux->cec.adap = NULL;
- } else {
- /*
-* Update the phys addr for the new CEC adapter. When called
-* from drm_dp_cec_register_connector() edid == NULL, so in
-* that case the phys addr is just invalidated.
-*/
- cec_s_phys_addr_from_edid(aux->cec.adap, edid);
}
unlock:
+ /*
+* Update the phys addr for the new CEC adapter. When called
+* from drm_dp_cec_register_connector() edid == NULL, so in
+* that case the phys addr is just invalidated.
+*/
+ if (aux->cec.adap && edid) {
+ cec_s_phys_addr_from_edid(aux->cec.adap, edid);
+ }
mutex_unlock(&aux->cec.lock);
}
EXPORT_SYMBOL(drm_dp_cec_set_edid);
@@ -418,6 +418,7 @@ EXPORT_SYMBOL(drm_dp_cec_unset_edid);
* drm_dp_cec_register_connector() - register a new connector
* @aux: DisplayPort AUX channel
* @connector: drm connector
+ * @is_mst: set to true if this is an MST branch
*
* A new connector was registered with associated CEC adapter name and
* CEC adapter parent device. After registering the name and parent
@@ -425,12 +426,13 @@ EXPORT_SYMBOL(drm_dp_cec_unset_edid);
* CEC and to register a CEC adapter if that is the case.
*/
void drm_dp_cec_register_connector(struct drm_dp_aux *aux,
- struct drm_connector *connector)
+ struct drm_connector *connector, bool is_mst)
{
WARN_ON(aux->cec.adap);
if (WARN_ON(!aux->transfer))
return;
aux->cec.connector = connector;
+ aux->cec.is_mst = is_mst;
INIT_DELAYED_WORK(&aux->cec.unregister_work,
drm_dp_cec_unregister_work);
}
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 82b9de274f65..744cb55572f9 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -6261,7 +6261,7 @@ intel_dp_connector_register(struct drm_connector
*connector)
intel_dp->aux.dev = connector->kdev;
ret = drm_dp_aux_register(&intel_dp->aux);
if (!ret)
- drm_dp_cec_register_connector(&intel_dp->aux, connector);
+ drm_dp_cec_register_connector(&intel_dp->aux, connector, false);
return ret;
}
diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c
b/drivers/gpu/drm/nouveau/nouveau_connector.c
index 49dd0cbc332f..671a70e95cd1 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
@@ -1414,7 +1414,7 @@ nouveau_co
[PATCH 2/5] drm_dp_mst_topology: use correct AUX channel
From: Hans Verkuil
For adapters behind an MST hub use the correct AUX channel.
Signed-off-by: Hans Verkuil
[sa...@chromium.org: rebased, removing redundant changes]
Signed-off-by: Sam McNally
---
drivers/gpu/drm/drm_dp_mst_topology.c | 36 +++
1 file changed, 36 insertions(+)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 15b6cc39a754..0d753201adbd 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -2255,6 +2255,9 @@ drm_dp_mst_topology_unlink_port(struct
drm_dp_mst_topology_mgr *mgr,
drm_dp_mst_topology_put_port(port);
}
+static ssize_t
+drm_dp_mst_aux_transfer(struct drm_dp_aux *aux, struct drm_dp_aux_msg *msg);
+
static struct drm_dp_mst_port *
drm_dp_mst_add_port(struct drm_device *dev,
struct drm_dp_mst_topology_mgr *mgr,
@@ -2271,9 +2274,13 @@ drm_dp_mst_add_port(struct drm_device *dev,
port->port_num = port_number;
port->mgr = mgr;
port->aux.name = "DPMST";
+ mutex_init(&port->aux.hw_mutex);
+ mutex_init(&port->aux.cec.lock);
port->aux.dev = dev->dev;
port->aux.is_remote = true;
+ port->aux.transfer = drm_dp_mst_aux_transfer;
+
/* initialize the MST downstream port's AUX crc work queue */
drm_dp_remote_aux_init(&port->aux);
@@ -3503,6 +3510,35 @@ static int drm_dp_send_up_ack_reply(struct
drm_dp_mst_topology_mgr *mgr,
return 0;
}
+static ssize_t
+drm_dp_mst_aux_transfer(struct drm_dp_aux *aux, struct drm_dp_aux_msg *msg)
+{
+ struct drm_dp_mst_port *port =
+ container_of(aux, struct drm_dp_mst_port, aux);
+ int ret;
+
+ switch (msg->request & ~DP_AUX_I2C_MOT) {
+ case DP_AUX_NATIVE_WRITE:
+ case DP_AUX_I2C_WRITE:
+ case DP_AUX_I2C_WRITE_STATUS_UPDATE:
+ ret = drm_dp_send_dpcd_write(port->mgr, port, msg->address,
+msg->size, msg->buffer);
+ break;
+
+ case DP_AUX_NATIVE_READ:
+ case DP_AUX_I2C_READ:
+ ret = drm_dp_send_dpcd_read(port->mgr, port, msg->address,
+ msg->size, msg->buffer);
+ break;
+
+ default:
+ ret = -EINVAL;
+ break;
+ }
+
+ return ret;
+}
+
static int drm_dp_get_vc_payload_bw(u8 dp_link_bw, u8 dp_link_count)
{
if (dp_link_bw == 0 || dp_link_count == 0)
--
2.28.0.402.g5ffc5be6b7-goog
[PATCH 3/5] drm_dp_mst_topology: export two functions
From: Hans Verkuil
These are required for the CEC MST support.
Signed-off-by: Hans Verkuil
Signed-off-by: Sam McNally
---
drivers/gpu/drm/drm_dp_mst_topology.c | 6 ++
include/drm/drm_dp_mst_helper.h | 4
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 0d753201adbd..c783a2a1c114 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -62,8 +62,6 @@ struct drm_dp_pending_up_req {
static bool dump_dp_payload_table(struct drm_dp_mst_topology_mgr *mgr,
char *buf);
-static void drm_dp_mst_topology_put_port(struct drm_dp_mst_port *port);
-
static int drm_dp_dpcd_write_payload(struct drm_dp_mst_topology_mgr *mgr,
int id,
struct drm_dp_payload *payload);
@@ -1864,7 +1862,7 @@ static void drm_dp_mst_topology_get_port(struct
drm_dp_mst_port *port)
* drm_dp_mst_topology_try_get_port()
* drm_dp_mst_topology_get_port()
*/
-static void drm_dp_mst_topology_put_port(struct drm_dp_mst_port *port)
+void drm_dp_mst_topology_put_port(struct drm_dp_mst_port *port)
{
topology_ref_history_lock(port->mgr);
@@ -1935,7 +1933,7 @@ drm_dp_mst_topology_get_port_validated_locked(struct
drm_dp_mst_branch *mstb,
return NULL;
}
-static struct drm_dp_mst_port *
+struct drm_dp_mst_port *
drm_dp_mst_topology_get_port_validated(struct drm_dp_mst_topology_mgr *mgr,
struct drm_dp_mst_port *port)
{
diff --git a/include/drm/drm_dp_mst_helper.h b/include/drm/drm_dp_mst_helper.h
index c7c79e0ced18..d036222e0d64 100644
--- a/include/drm/drm_dp_mst_helper.h
+++ b/include/drm/drm_dp_mst_helper.h
@@ -754,6 +754,10 @@ drm_dp_mst_detect_port(struct drm_connector *connector,
struct drm_dp_mst_topology_mgr *mgr,
struct drm_dp_mst_port *port);
+struct drm_dp_mst_port *drm_dp_mst_topology_get_port_validated
+(struct drm_dp_mst_topology_mgr *mgr, struct drm_dp_mst_port *port);
+void drm_dp_mst_topology_put_port(struct drm_dp_mst_port *port);
+
struct edid *drm_dp_mst_get_edid(struct drm_connector *connector, struct
drm_dp_mst_topology_mgr *mgr, struct drm_dp_mst_port *port);
--
2.28.0.402.g5ffc5be6b7-goog
[PATCH 1/5] dp/dp_mst: Add support for sink event notify messages
Sink event notify messages are used for MST CEC IRQs. Add parsing
support for sink event notify messages in preparation for handling MST
CEC IRQs.
Signed-off-by: Sam McNally
---
drivers/gpu/drm/drm_dp_mst_topology.c | 37 ++-
include/drm/drm_dp_mst_helper.h | 14 ++
2 files changed, 50 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 17dbed0a9800..15b6cc39a754 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -1027,6 +1027,30 @@ static bool
drm_dp_sideband_parse_resource_status_notify(struct drm_dp_sideband_
return false;
}
+static bool drm_dp_sideband_parse_sink_event_notify(
+ struct drm_dp_sideband_msg_rx *raw,
+ struct drm_dp_sideband_msg_req_body *msg)
+{
+ int idx = 1;
+
+ msg->u.sink_event.port_number = (raw->msg[idx] & 0xf0) >> 4;
+ idx++;
+ if (idx > raw->curlen)
+ goto fail_len;
+
+ memcpy(msg->u.sink_event.guid, &raw->msg[idx], 16);
+ idx += 16;
+ if (idx > raw->curlen)
+ goto fail_len;
+
+ msg->u.sink_event.event_id = (raw->msg[idx] << 8) | (raw->msg[idx + 1]);
+ idx++;
+ return true;
+fail_len:
+ DRM_DEBUG_KMS("sink event notify parse length fail %d %d\n", idx,
raw->curlen);
+ return false;
+}
+
static bool drm_dp_sideband_parse_req(struct drm_dp_sideband_msg_rx *raw,
struct drm_dp_sideband_msg_req_body *msg)
{
@@ -1038,6 +1062,8 @@ static bool drm_dp_sideband_parse_req(struct
drm_dp_sideband_msg_rx *raw,
return drm_dp_sideband_parse_connection_status_notify(raw, msg);
case DP_RESOURCE_STATUS_NOTIFY:
return drm_dp_sideband_parse_resource_status_notify(raw, msg);
+ case DP_SINK_EVENT_NOTIFY:
+ return drm_dp_sideband_parse_sink_event_notify(raw, msg);
default:
DRM_ERROR("Got unknown request 0x%02x (%s)\n", msg->req_type,
drm_dp_mst_req_type_str(msg->req_type));
@@ -3875,6 +3901,8 @@ drm_dp_mst_process_up_req(struct drm_dp_mst_topology_mgr
*mgr,
guid = msg->u.conn_stat.guid;
else if (msg->req_type == DP_RESOURCE_STATUS_NOTIFY)
guid = msg->u.resource_stat.guid;
+ else if (msg->req_type == DP_SINK_EVENT_NOTIFY)
+ guid = msg->u.sink_event.guid;
if (guid)
mstb = drm_dp_get_mst_branch_device_by_guid(mgr, guid);
@@ -3948,7 +3976,8 @@ static int drm_dp_mst_handle_up_req(struct
drm_dp_mst_topology_mgr *mgr)
drm_dp_sideband_parse_req(&mgr->up_req_recv, &up_req->msg);
if (up_req->msg.req_type != DP_CONNECTION_STATUS_NOTIFY &&
- up_req->msg.req_type != DP_RESOURCE_STATUS_NOTIFY) {
+ up_req->msg.req_type != DP_RESOURCE_STATUS_NOTIFY &&
+ up_req->msg.req_type != DP_SINK_EVENT_NOTIFY) {
DRM_DEBUG_KMS("Received unknown up req type, ignoring: %x\n",
up_req->msg.req_type);
kfree(up_req);
@@ -3976,6 +4005,12 @@ static int drm_dp_mst_handle_up_req(struct
drm_dp_mst_topology_mgr *mgr)
DRM_DEBUG_KMS("Got RSN: pn: %d avail_pbn %d\n",
res_stat->port_number,
res_stat->available_pbn);
+ } else if (up_req->msg.req_type == DP_SINK_EVENT_NOTIFY) {
+ const struct drm_dp_sink_event_notify *sink_event =
+ &up_req->msg.u.sink_event;
+
+ DRM_DEBUG_KMS("Got SEN: pn: %d event_id %d\n",
+ sink_event->port_number, sink_event->event_id);
}
up_req->hdr = mgr->up_req_recv.initial_hdr;
diff --git a/include/drm/drm_dp_mst_helper.h b/include/drm/drm_dp_mst_helper.h
index 6ae5860d8644..c7c79e0ced18 100644
--- a/include/drm/drm_dp_mst_helper.h
+++ b/include/drm/drm_dp_mst_helper.h
@@ -402,6 +402,19 @@ struct drm_dp_resource_status_notify {
u16 available_pbn;
};
+#define DP_SINK_EVENT_PANEL_REPLAY_ACTIVE_FRAME_CRC_ERROR BIT(0)
+#define DP_SINK_EVENT_PANEL_REPLAY_RFB_STORAGE_ERROR BIT(1)
+#define DP_SINK_EVENT_DSC_RC_BUFFER_UNDER_RUN BIT(2)
+#define DP_SINK_EVENT_DSC_RC_BUFFER_OVERFLOW BIT(3)
+#define DP_SINK_EVENT_DSC_CHUNK_LENGTH_ERROR BIT(4)
+#define DP_SINK_EVENT_CEC_IRQ_EVENTBIT(5)
+
+struct drm_dp_sink_event_notify {
+ u8 port_number;
+ u8 guid[16];
+ u16 event_id;
+};
+
struct drm_dp_query_payload_ack_reply {
u8 port_number;
u16 allocated_pbn;
@@ -413,6 +426,7 @@ struct drm_dp_sideband_msg_req_body {
struct drm_dp_connection_status_notify conn_stat;
struct drm_dp_port_number_req port_num;
Re: [PATCH v3 2/2] iommu/vt-d:Add support for probing ACPI device in RMRR
Hi Felix,
On 8/27/20 6:02 PM, FelixCuioc wrote:
After acpi device in RMRR is detected,it is necessary
to establish a mapping for these devices.
In acpi_device_create_direct_mappings(),create a mapping
for the acpi device in RMRR.
Add a helper to achieve the acpi namespace device can
access the RMRR region.
Are those ACPI devices visible to kernel? If so, any device driver bound
for it?
Best regards,
baolu
Signed-off-by: FelixCuioc
---
drivers/iommu/intel/iommu.c | 29 +
drivers/iommu/iommu.c | 6 ++
include/linux/iommu.h | 3 +++
3 files changed, 38 insertions(+)
diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
index 208a91605288..51d7a5b18f41 100644
--- a/drivers/iommu/intel/iommu.c
+++ b/drivers/iommu/intel/iommu.c
@@ -4799,6 +4799,21 @@ static int __init platform_optin_force_iommu(void)
return 1;
}
+static int acpi_device_create_direct_mappings(struct device *pn_dev, struct device *acpi_device)
+{
+ struct iommu_group *group;
+
+ acpi_device->bus->iommu_ops = &intel_iommu_ops;
+ group = iommu_group_get(pn_dev);
+ if (!group) {
+ pr_warn("ACPI name space devices create direct mappings
wrong!\n");
+ return -EINVAL;
+ }
+ __acpi_device_create_direct_mappings(group, acpi_device);
+
+ return 0;
+}
+
static int __init probe_acpi_namespace_devices(void)
{
struct dmar_drhd_unit *drhd;
@@ -4813,6 +4828,7 @@ static int __init probe_acpi_namespace_devices(void)
struct acpi_device_physical_node *pn;
struct iommu_group *group;
struct acpi_device *adev;
+ struct device *pn_dev = NULL;
if (dev->bus != &acpi_bus_type)
continue;
@@ -4823,6 +4839,7 @@ static int __init probe_acpi_namespace_devices(void)
&adev->physical_node_list, node) {
group = iommu_group_get(pn->dev);
if (group) {
+ pn_dev = pn->dev;
iommu_group_put(group);
continue;
}
@@ -4831,7 +4848,19 @@ static int __init probe_acpi_namespace_devices(void)
ret = iommu_probe_device(pn->dev);
if (ret)
break;
+ pn_dev = pn->dev;
+ }
+ if (!pn_dev) {
+ dev->bus->iommu_ops = &intel_iommu_ops;
+ ret = iommu_probe_device(dev);
+ if (ret) {
+ pr_err("acpi_device probe fail!
ret:%d\n", ret);
+ goto unlock;
+ }
+ goto unlock;
}
+ ret = acpi_device_create_direct_mappings(pn_dev, dev);
+unlock:
mutex_unlock(&adev->physical_node_lock);
if (ret)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 609bd25bf154..4f714a2d5ef7 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -779,6 +779,12 @@ static bool iommu_is_attach_deferred(struct iommu_domain
*domain,
return false;
}
+void __acpi_device_create_direct_mappings(struct iommu_group *group, struct device *acpi_device)
+{
+ iommu_create_device_direct_mappings(group, acpi_device);
+}
+EXPORT_SYMBOL_GPL(__acpi_device_create_direct_mappings);
+
/**
* iommu_group_add_device - add a device to an iommu group
* @group: the group into which to add the device (reference should be held)
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index fee209efb756..9be134775886 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -514,6 +514,9 @@ extern void iommu_domain_window_disable(struct iommu_domain
*domain, u32 wnd_nr)
extern int report_iommu_fault(struct iommu_domain *domain, struct device *dev,
unsigned long iova, int flags);
+extern void __acpi_device_create_direct_mappings(struct iommu_group *group,
+ struct device *acpi_device);
+
static inline void iommu_flush_tlb_all(struct iommu_domain *domain)
{
if (domain->ops->flush_iotlb_all)
Re: [PATCH] x86/platform/intel-mid: Fix build error without CONFIG_ACPI
On 2020/9/1 12:07, Randy Dunlap wrote:
> On 8/31/20 8:58 PM, YueHaibing wrote:
>> arch/x86/pci/intel_mid_pci.c: In function ‘intel_mid_pci_init’:
>> arch/x86/pci/intel_mid_pci.c:303:2: error: implicit declaration of function
>> ‘acpi_noirq_set’; did you mean ‘acpi_irq_get’?
>> [-Werror=implicit-function-declaration]
>> acpi_noirq_set();
>> ^~
>> acpi_irq_get
>>
>> Fixes: a912a7584ec3 ("x86/platform/intel-mid: Move PCI initialization to
>> arch_init()")
>> Signed-off-by: YueHaibing
>
> Bjorn has merged my patch (or so his email says), but apparently it's not
> in linux-next yet.
Thanks for info.
>
>
>> ---
>> arch/x86/pci/intel_mid_pci.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/arch/x86/pci/intel_mid_pci.c b/arch/x86/pci/intel_mid_pci.c
>> index 00c62115f39c..0aaf31917061 100644
>> --- a/arch/x86/pci/intel_mid_pci.c
>> +++ b/arch/x86/pci/intel_mid_pci.c
>> @@ -33,6 +33,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> #define PCIE_CAP_OFFSET 0x100
>>
>>
>
> thanks.
>
Re: [PATCH v2 00/23] Use asm-generic for mmu_context no-op functions
Excerpts from Mike Rapoport's message of August 30, 2020 8:18 pm: > On Thu, Aug 27, 2020 at 12:52:26AM +1000, Nicholas Piggin wrote: >> It would be nice to be able to modify mmu_context functions or add a >> hook without updating all architectures, many of which will be no-ops. >> >> The motivation for this series is a change to lazy mmu handling, but >> this series stands on its own as a good cleanup whether or not we end >> up making that change. > > I really like this series, I just have some small comments in reply to > patch 1, otherwise feel free to add > > Acked-by: Mike Rapoport I can't see your comments in reply to patch 1. Thanks, Nick
Re: [PATCH v2 10/23] microblaze: use asm-generic/mmu_context.h for no-op implementations
Excerpts from Michal Simek's message of September 1, 2020 12:15 am:
>
>
> On 26. 08. 20 16:52, Nicholas Piggin wrote:
>> Cc: Michal Simek
>> Signed-off-by: Nicholas Piggin
>> ---
>> arch/microblaze/include/asm/mmu_context_mm.h | 8
>> arch/microblaze/include/asm/processor.h | 3 ---
>> 2 files changed, 4 insertions(+), 7 deletions(-)
>>
>> diff --git a/arch/microblaze/include/asm/mmu_context_mm.h
>> b/arch/microblaze/include/asm/mmu_context_mm.h
>> index a1c7dd48454c..c2c77f708455 100644
>> --- a/arch/microblaze/include/asm/mmu_context_mm.h
>> +++ b/arch/microblaze/include/asm/mmu_context_mm.h
>> @@ -33,10 +33,6 @@
>> to represent all kernel pages as shared among all contexts.
>> */
>>
>> -static inline void enter_lazy_tlb(struct mm_struct *mm, struct task_struct
>> *tsk)
>> -{
>> -}
>> -
>> # define NO_CONTEXT 256
>> # define LAST_CONTEXT 255
>> # define FIRST_CONTEXT 1
>> @@ -105,6 +101,7 @@ static inline void get_mmu_context(struct mm_struct *mm)
>> /*
>> * We're finished using the context for an address space.
>> */
>> +#define destroy_context destroy_context
>> static inline void destroy_context(struct mm_struct *mm)
>> {
>> if (mm->context != NO_CONTEXT) {
>> @@ -126,6 +123,7 @@ static inline void switch_mm(struct mm_struct *prev,
>> struct mm_struct *next,
>> * After we have set current->mm to a new value, this activates
>> * the context for the new mm so we see the new mappings.
>> */
>> +#define activate_mm activate_mm
>> static inline void activate_mm(struct mm_struct *active_mm,
>> struct mm_struct *mm)
>> {
>> @@ -136,5 +134,7 @@ static inline void activate_mm(struct mm_struct
>> *active_mm,
>>
>> extern void mmu_context_init(void);
>>
>> +#include
>> +
>> # endif /* __KERNEL__ */
>> #endif /* _ASM_MICROBLAZE_MMU_CONTEXT_H */
>> diff --git a/arch/microblaze/include/asm/processor.h
>> b/arch/microblaze/include/asm/processor.h
>> index 1ff5a82b76b6..616211871a6e 100644
>> --- a/arch/microblaze/include/asm/processor.h
>> +++ b/arch/microblaze/include/asm/processor.h
>> @@ -122,9 +122,6 @@ unsigned long get_wchan(struct task_struct *p);
>> # define KSTK_EIP(task)(task_pc(task))
>> # define KSTK_ESP(task)(task_sp(task))
>>
>> -/* FIXME */
>> -# define deactivate_mm(tsk, mm)do { } while (0)
>> -
>> # define STACK_TOP TASK_SIZE
>> # define STACK_TOP_MAX STACK_TOP
>>
>>
>
> I am fine with the patch but I pretty much don't like that commit
> message is empty and there is only subject.
> With fixing that you can add my:
> Acked-by: Michal Simek
Thanks for the review, will do. Any suggestion for a useful commit message?
Thanks,
Nick
Re: fsl_espi errors on v5.7.15
Excerpts from Chris Packham's message of September 1, 2020 11:25 am:
>
> On 1/09/20 12:33 am, Heiner Kallweit wrote:
>> On 30.08.2020 23:59, Chris Packham wrote:
>>> On 31/08/20 9:41 am, Heiner Kallweit wrote:
On 30.08.2020 23:00, Chris Packham wrote:
> On 31/08/20 12:30 am, Nicholas Piggin wrote:
>> Excerpts from Chris Packham's message of August 28, 2020 8:07 am:
>
>
>>> I've also now seen the RX FIFO not empty error on the T2080RDB
>>>
>>> fsl_espi ffe11.spi: Transfer done but SPIE_DON isn't set!
>>> fsl_espi ffe11.spi: Transfer done but SPIE_DON isn't set!
>>> fsl_espi ffe11.spi: Transfer done but SPIE_DON isn't set!
>>> fsl_espi ffe11.spi: Transfer done but SPIE_DON isn't set!
>>> fsl_espi ffe11.spi: Transfer done but rx/tx fifo's aren't empty!
>>> fsl_espi ffe11.spi: SPIE_RXCNT = 1, SPIE_TXCNT = 32
>>>
>>> With my current workaround of emptying the RX FIFO. It seems
>>> survivable. Interestingly it only ever seems to be 1 extra byte in
>>> the
>>> RX FIFO and it seems to be after either a READ_SR or a READ_FSR.
>>>
>>> fsl_espi ffe11.spi: tx 70
>>> fsl_espi ffe11.spi: rx 03
>>> fsl_espi ffe11.spi: Extra RX 00
>>> fsl_espi ffe11.spi: Transfer done but SPIE_DON isn't set!
>>> fsl_espi ffe11.spi: Transfer done but rx/tx fifo's aren't empty!
>>> fsl_espi ffe11.spi: SPIE_RXCNT = 1, SPIE_TXCNT = 32
>>> fsl_espi ffe11.spi: tx 05
>>> fsl_espi ffe11.spi: rx 00
>>> fsl_espi ffe11.spi: Extra RX 03
>>> fsl_espi ffe11.spi: Transfer done but SPIE_DON isn't set!
>>> fsl_espi ffe11.spi: Transfer done but rx/tx fifo's aren't empty!
>>> fsl_espi ffe11.spi: SPIE_RXCNT = 1, SPIE_TXCNT = 32
>>> fsl_espi ffe11.spi: tx 05
>>> fsl_espi ffe11.spi: rx 00
>>> fsl_espi ffe11.spi: Extra RX 03
>>>
>>> From all the Micron SPI-NOR datasheets I've got access to it is
>>> possible to continually read the SR/FSR. But I've no idea why it
>>> happens some times and not others.
>> So I think I've got a reproduction and I think I've bisected the
>> problem
>> to commit 3282a3da25bd ("powerpc/64: Implement soft interrupt replay
>> in
>> C"). My day is just finishing now so I haven't applied too much
>> scrutiny
>> to this result. Given the various rabbit holes I've been down on this
>> issue already I'd take this information with a good degree of
>> skepticism.
>>
> OK, so an easy test should be to re-test with a 5.4 kernel.
> It doesn't have yet the change you're referring to, and the fsl-espi
> driver
> is basically the same as in 5.7 (just two small changes in 5.7).
There's 6cc0c16d82f88 and maybe also other interrupt related patches
around this time that could affect book E, so it's good if that exact
patch is confirmed.
>>> My confirmation is basically that I can induce the issue in a 5.4 kernel
>>> by cherry-picking 3282a3da25bd. I'm also able to "fix" the issue in
>>> 5.9-rc2 by reverting that one commit.
>>>
>>> I both cases it's not exactly a clean cherry-pick/revert so I also
>>> confirmed the bisection result by building at 3282a3da25bd (which sees
>>> the issue) and the commit just before (which does not).
>> Thanks for testing, that confirms it well.
>>
>> [snip patch]
>>
>>> I still saw the issue with this change applied. PPC_IRQ_SOFT_MASK_DEBUG
>>> didn't report anything (either with or without the change above).
>> Okay, it was a bit of a shot in the dark. I still can't see what
>> else has changed.
>>
>> What would cause this, a lost interrupt? A spurious interrupt? Or
>> higher interrupt latency?
>>
>> I don't think the patch should cause significantly worse latency,
>> (it's supposed to be a bit better if anything because it doesn't set
>> up the full interrupt frame). But it's possible.
> My working theory is that the SPI_DON indication is all about the TX
> direction an now that the interrupts are faster we're hitting an error
> because there is still RX activity going on. Heiner disagrees with my
> interpretation of the SPI_DON indication and the fact that it doesn't
> happen every time does throw doubt on it.
>
It's right that the eSPI spec can be interpreted that SPI_DON refers to
TX only. However this wouldn't really make sense, because also for RX
we program the frame length, and therefore want to be notified once the
full frame was received. Also practical experience shows that SPI_DON
is set also after RX-only transfers.
Typical SPI NOR use case is that you write
Re: [PATCH 2/5] input: misc: Add IBM Operation Panel driver
> + switch (event) {
> + case I2C_SLAVE_STOP:
> + command_size = panel->idx;
> + fallthrough;
> + case I2C_SLAVE_WRITE_REQUESTED:
> + panel->idx = 0;
> + break;
> + case I2C_SLAVE_WRITE_RECEIVED:
> + if (panel->idx < sizeof(panel->command))
> + panel->command[panel->idx++] = *val;
> + else
> + dev_dbg(&panel->input->dev, "command truncated\n");
Just double checking: Do you really want to process truncated commands?
Since you detect the state here, you could also choose to reject such
commands?
signature.asc
Description: PGP signature
Re: [PATCH 4/5] ARM: dts: Aspeed: Tacoma: Add IBM Operation Panel I2C device
> > + ibm-panel@62 {
> > + compatible = "ibm,op-panel";
> > + reg = <0x4062>; /* I2C_OWN_SLAVE_ADDRESS */
>
> Other users of SLAVE_ADDRESS have included and
> written the reg as follows:
>
> reg = <(I2C_OWN_SLAVE_ADDRESS | 0x62)>
>
> Which obviously has the same result. I'll leave it up to you.
The latter, please.
signature.asc
Description: PGP signature
Re: [PATCH v3 1/2] iommu/vt-d:Add support for detecting ACPI device in RMRR
Hi Felix,
On 8/27/20 6:02 PM, FelixCuioc wrote:
Some ACPI devices need to issue dma requests to access
the reserved memory area.BIOS uses the device scope type
ACPI_NAMESPACE_DEVICE in RMRR to report these ACPI devices.
This patch add support for detecting ACPI devices in RMRR.
Signed-off-by: FelixCuioc
---
drivers/iommu/intel/dmar.c | 76 +
drivers/iommu/intel/iommu.c | 23 ++-
include/linux/dmar.h| 12 +-
3 files changed, 76 insertions(+), 35 deletions(-)
diff --git a/drivers/iommu/intel/dmar.c b/drivers/iommu/intel/dmar.c
index 93e6345f3414..f6691c36bd3f 100644
--- a/drivers/iommu/intel/dmar.c
+++ b/drivers/iommu/intel/dmar.c
@@ -215,7 +215,7 @@ static bool dmar_match_pci_path(struct dmar_pci_notify_info
*info, int bus,
}
/* Return: > 0 if match found, 0 if no match found, < 0 if error happens */
-int dmar_insert_dev_scope(struct dmar_pci_notify_info *info,
+int dmar_pci_insert_dev_scope(struct dmar_pci_notify_info *info,
void *start, void*end, u16 segment,
struct dmar_dev_scope *devices,
int devices_cnt)
@@ -304,7 +304,7 @@ static int dmar_pci_bus_add_dev(struct dmar_pci_notify_info
*info)
drhd = container_of(dmaru->hdr,
struct acpi_dmar_hardware_unit, header);
- ret = dmar_insert_dev_scope(info, (void *)(drhd + 1),
+ ret = dmar_pci_insert_dev_scope(info, (void *)(drhd + 1),
((void *)drhd) + drhd->header.length,
dmaru->segment,
dmaru->devices, dmaru->devices_cnt);
@@ -697,47 +697,59 @@ dmar_find_matched_drhd_unit(struct pci_dev *dev)
return dmaru;
}
-static void __init dmar_acpi_insert_dev_scope(u8 device_number,
- struct acpi_device *adev)
+/* Return: > 0 if match found, 0 if no match found */
+bool dmar_acpi_insert_dev_scope(u8 device_number,
+ struct acpi_device *adev,
+ void *start, void *end,
+ struct dmar_dev_scope *devices,
+ int devices_cnt)
{
- struct dmar_drhd_unit *dmaru;
- struct acpi_dmar_hardware_unit *drhd;
struct acpi_dmar_device_scope *scope;
struct device *tmp;
int i;
struct acpi_dmar_pci_path *path;
+ for (; start < end; start += scope->length) {
+ scope = start;
+ if (scope->entry_type != ACPI_DMAR_SCOPE_TYPE_NAMESPACE)
+ continue;
+ if (scope->enumeration_id != device_number)
+ continue;
+ path = (void *)(scope + 1);
+ for_each_dev_scope(devices, devices_cnt, i, tmp)
+ if (tmp == NULL) {
+ devices[i].bus = scope->bus;
+ devices[i].devfn = PCI_DEVFN(path->device,
path->function);
+ rcu_assign_pointer(devices[i].dev,
+ get_device(&adev->dev));
+ return true;
+ }
+ WARN_ON(i >= devices_cnt);
+ }
+ return false;
+}
+
+static int dmar_acpi_bus_add_dev(u8 device_number, struct acpi_device *adev)
+{
+ struct dmar_drhd_unit *dmaru;
+ struct acpi_dmar_hardware_unit *drhd;
+ int ret;
+
for_each_drhd_unit(dmaru) {
drhd = container_of(dmaru->hdr,
struct acpi_dmar_hardware_unit,
header);
+ ret = dmar_acpi_insert_dev_scope(device_number, adev, (void
*)(drhd+1),
+ ((void
*)drhd)+drhd->header.length,
+ dmaru->devices,
dmaru->devices_cnt);
+ if (ret)
+ break;
+ }
+ if (ret > 0)
+ ret = dmar_rmrr_add_acpi_dev(device_number, adev);
- for (scope = (void *)(drhd + 1);
-(unsigned long)scope < ((unsigned long)drhd) +
drhd->header.length;
-scope = ((void *)scope) + scope->length) {
- if (scope->entry_type != ACPI_DMAR_SCOPE_TYPE_NAMESPACE)
- continue;
- if (scope->enumeration_id != device_number)
- continue;
+ return ret;
- path = (void *)(scope + 1);
- pr_info("ACPI device \"%s\" under DMAR at %llx as
%02x:%02x.%d\n",
- dev_name(&adev->dev), dmaru->reg_base_addr,
- scope->bus, path->device, path->function);
Please keep such information. People are used to use them as a method to
know the hardwa
RE: Lockdep warning caused by "driver core: Fix sleeping in invalid context during device link deletion"
> Subject: Re: Lockdep warning caused by "driver core: Fix sleeping in invalid
> context during device link deletion"
>
> On Wed, Aug 26, 2020 at 10:17 PM Saravana Kannan
> wrote:
> >
> > On Thu, Aug 20, 2020 at 8:50 PM Dong Aisheng
> wrote:
> > >
> > > Hi ALL,
> > >
> > > We met the below WARNING during system suspend on an iMX6Q SDB
> board
> > > with the latest linus/master branch (v5.9-rc1+) and next-20200820.
> > > v5.8 kernel is ok. So i did bisect and finally found it's caused by
> > > the patch below.
> > > Reverting it can get rid of the warning, but I wonder if there may
> > > be other potential issues.
> > > Any ideas?
> > >
> > > Defconfig used is: imx_v6_v7_defconfig
> > >
> >
> > - 8< - Snipped text that was a bit misleading
> >
> > >
> > > Error log:
> > > # echo mem > /sys/power/state
> > > [ 39.111865] PM: suspend entry (deep)
> > > [ 39.148650] Filesystems sync: 0.032 seconds
> > > [ 39.154034]
> > > [ 39.155537]
> ==
> > > [ 39.161723] WARNING: possible circular locking dependency detected
> > > [ 39.167911] 5.9.0-rc1-00103-g7eac66d0456f #37 Not tainted
> > > [ 39.173315] --
> > > [ 39.179500] sh/647 is trying to acquire lock:
> > > [ 39.183862] c15a310c (dpm_list_mtx){+.+.}-{3:3}, at:
> > > dpm_for_each_dev+0x20/0x5c
> > > [ 39.191200]
> > > [ 39.191200] but task is already holding lock:
> > > [ 39.197036] c15a37e4 (fw_lock){+.+.}-{3:3}, at:
> fw_pm_notify+0x90/0xd4
> > > [ 39.203582]
> > > [ 39.203582] which lock already depends on the new lock.
> > > [ 39.203582]
> > > [ 39.211763]
> > > [ 39.211763] the existing dependency chain (in reverse order) is:
> > > [ 39.219249]
> > > [ 39.219249] -> #2 (fw_lock){+.+.}-{3:3}:
> > > [ 39.224673]mutex_lock_nested+0x1c/0x24
> > > [ 39.229126]firmware_uevent+0x18/0xa0
> > > [ 39.233411]dev_uevent+0xc4/0x1f8
> > > [ 39.237343]uevent_show+0x98/0x114
> > > [ 39.241362]dev_attr_show+0x18/0x48
> > > [ 39.245472]sysfs_kf_seq_show+0x84/0xec
> > > [ 39.249927]seq_read+0x138/0x550
> > > [ 39.253774]vfs_read+0x94/0x164
> > > [ 39.257529]ksys_read+0x60/0xe8
> > > [ 39.261288]ret_fast_syscall+0x0/0x28
> > > [ 39.265564]0xbed7c808
> > > [ 39.268538]
> > > [ 39.268538] -> #1 (kn->active#3){}-{0:0}:
> > > [ 39.274391]kernfs_remove_by_name_ns+0x40/0x94
> > > [ 39.279450]device_del+0x144/0x3fc
> >
> > Rafael/Greg,
> >
> > I'm not very familiar with the #0 and #2 calls stacks. But poking
> > around a bit, they are NOT due to the device-link-device. But the new
> > stuff is the above two lines that are deleting the device-link-device
> > (that's used to expose device link details in sysfs) when the device
> > link is deleted.
> >
> > Kicking off a workqueue to break this cycle is easy, but the problem
> > is that if I queue a work to delete the device, then the sysfs folder
> > won't get removed immediately. And if the same link is created again
> > before the work is completed, then there'll be a sysfs name collision
> > and warning.
> >
> > So, I'm kinda stuck here. Open to suggestions. Hoping you'll have
> > better ideas for breaking the cycle. Or point out how I'm
> > misunderstanding the cycle here.
> >
>
> Aisheng,
>
> Sent out a fix that I think should work.
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.ke
> rnel.org%2Flkml%2F20200831221007.1506441-1-saravanak%40google.com%
> 2FT%2F%23u&data=02%7C01%7Cpeng.fan%40nxp.com%7C3254604d7
> 41b4d1ce73b08d84dfb65af%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0
> %7C0%7C637345089428077609&sdata=5lh8WO%2BYMh4C1sBn58Fsm
> XsjqjPj%2B%2FB71%2FENfMGDtTk%3D&reserved=0
>
> I wasn't able to reproduce it in my hardware. So, if you can test that patch
> (and respond to that thread), that'd be great.
I not found your patch in my mailbox, but anyway I tested it.
Tested-by: Peng Fan (i.MX7ULP EVK)
Regards,
Peng.
>
> -Saravana
Re: [PATCH v6 3/5] perf jevents: Add support for parsing perchip/percore events
On 8/31/20 2:14 PM, Jiri Olsa wrote:
> On Thu, Aug 27, 2020 at 06:39:56PM +0530, Kajol Jain wrote:
>> Initially, every time we want to add new terms like chip, core thread etc,
>> we need to create corrsponding fields in pmu_events and event struct.
>> This patch adds an enum called 'aggr_mode_class' which store all these
>> aggregation like perchip/percore. It also adds new field 'aggr_mode'
>> to capture these terms.
>> Now, if user wants to add any new term, they just need to add it in
>> the enum defined.
>>
>> Signed-off-by: Kajol Jain
>> ---
>> tools/perf/pmu-events/jevents.c| 16
>> tools/perf/pmu-events/pmu-events.h | 6 ++
>> 2 files changed, 22 insertions(+)
>>
>> diff --git a/tools/perf/pmu-events/jevents.c
>> b/tools/perf/pmu-events/jevents.c
>> index b205cd904a4f..f4ad2d403533 100644
>> --- a/tools/perf/pmu-events/jevents.c
>> +++ b/tools/perf/pmu-events/jevents.c
>> @@ -48,6 +48,7 @@
>> #include
>> #include "jsmn.h"
>> #include "json.h"
>> +#include "pmu-events.h"
>>
>> int verbose;
>> char *prog;
>> @@ -60,6 +61,7 @@ struct json_event {
>> char *pmu;
>> char *unit;
>> char *perpkg;
>> +char *aggr_mode;
>> char *metric_expr;
>> char *metric_name;
>> char *metric_group;
>> @@ -74,6 +76,14 @@ struct json_event {
>> (void)(&_min1 == &_min2); \
>> _min1 < _min2 ? _min1 : _min2; })
>> #endif
>
> please add new line in here
>
yes, will add.
>> +enum aggr_mode_class convert(const char *aggr_mode)
>> +{
>> +if (!strcmp(aggr_mode, "PerCore"))
>> +return PerCore;
>> +else if (!strcmp(aggr_mode, "PerChip"))
>> +return PerChip;
>> +return -1;
>
> should we display some warning in here?
Sure can do that.
Thanks,
Kajol Jain
>
> thanks,
> jirka
>
Re: [PATCH v6 2/5] perf/jevents: Add new structure to pass json fields.
On 8/31/20 2:13 PM, Jiri Olsa wrote:
> On Thu, Aug 27, 2020 at 06:39:55PM +0530, Kajol Jain wrote:
>
> SNIP
>
>> -if (!*field)\
>> +#define TRY_FIXUP_FIELD(field) do { if (es->field && !je->field) {\
>> +je->field = strdup(es->field); \
>> +if (!je->field) \
>> return -ENOMEM; \
>> } } while (0)
>>
>> @@ -428,11 +440,7 @@ static void free_arch_std_events(void)
>> }
>> }
>>
>> -static int save_arch_std_events(void *data, char *name, char *event,
>> -char *desc, char *long_desc, char *pmu,
>> -char *unit, char *perpkg, char *metric_expr,
>> -char *metric_name, char *metric_group,
>> -char *deprecated, char *metric_constraint)
>> +static int save_arch_std_events(void *data, struct json_event *je)
>> {
>> struct event_struct *es;
>>
>> @@ -486,17 +494,16 @@ static char *real_event(const char *name, char *event)
>> return NULL;
>>
>> for (i = 0; fixed[i].name; i++)
>> -if (!strcasecmp(name, fixed[i].name))
>> -return (char *)fixed[i].event;
>> +if (!strcasecmp(name, fixed[i].name)) {
>> +strcpy(event, fixed[i].event);
>
> hum what's this strcpy for in here? we're just replacing separated
> variables with struct members, why do you need to copy the event in
> here?
>
Hi Jiri,
Actually, initially when events is not part of 'json_event' structure, we
are not
assigning result of function `real_event` to event field. But as we are not
passing
event filed separately in functions like 'save_arch_std_events', freeing event
memory was giving me issue as we are returning pointer from real_event function
in some cases.
So, that's why I replace it to strcpy to make sure we free je.event memory. Or
should I remove
free(je.event) part?
- err = func(data, name, real_event(name, event), desc, long_desc,
- pmu, unit, perpkg, metric_expr, metric_name,
- metric_group, deprecated, metric_constraint);
+ je.event = real_event(je.name, je.event);
This is the part, I am referring, here we are assigning result of real_event
into je.event field.
Thanks,
Kajol Jain
> thanks,
> jirka
>
[PATCH v1 2/2] scsi: ufs: Support reading UFS's Vcc voltage from device tree
The UFS specifications supports a range of Vcc operating voltage
from 2.4-3.6V depending on the device and manufacturers.
Allows selecting the UFS Vcc voltage level by setting the
UFS's entry vcc-voltage-level in the device tree. If UFS's
vcc-voltage-level setting is not found in the device tree,
use default values provided by the driver.
Signed-off-by: Can Guo
Signed-off-by: Asutosh Das
Signed-off-by: Bao D. Nguyen
---
drivers/scsi/ufs/ufshcd-pltfrm.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/ufs/ufshcd-pltfrm.c b/drivers/scsi/ufs/ufshcd-pltfrm.c
index 3db0af6..48f429c 100644
--- a/drivers/scsi/ufs/ufshcd-pltfrm.c
+++ b/drivers/scsi/ufs/ufshcd-pltfrm.c
@@ -104,10 +104,11 @@ static int ufshcd_parse_clock_info(struct ufs_hba *hba)
static int ufshcd_populate_vreg(struct device *dev, const char *name,
struct ufs_vreg **out_vreg)
{
- int ret = 0;
+ int len, ret = 0;
char prop_name[MAX_PROP_SIZE];
struct ufs_vreg *vreg = NULL;
struct device_node *np = dev->of_node;
+ const __be32 *prop;
if (!np) {
dev_err(dev, "%s: non DT initialization\n", __func__);
@@ -138,8 +139,16 @@ static int ufshcd_populate_vreg(struct device *dev, const
char *name,
vreg->min_uV = UFS_VREG_VCC_1P8_MIN_UV;
vreg->max_uV = UFS_VREG_VCC_1P8_MAX_UV;
} else {
- vreg->min_uV = UFS_VREG_VCC_MIN_UV;
- vreg->max_uV = UFS_VREG_VCC_MAX_UV;
+ prop = of_get_property(np, "vcc-voltage-level", &len);
+ if (!prop || (len != (2 * sizeof(__be32 {
+ dev_warn(dev, "%s vcc-voltage-level
property.\n",
+ prop ? "invalid format" : "no");
+ vreg->min_uV = UFS_VREG_VCC_MIN_UV;
+ vreg->max_uV = UFS_VREG_VCC_MAX_UV;
+ } else {
+ vreg->min_uV = be32_to_cpup(&prop[0]);
+ vreg->max_uV = be32_to_cpup(&prop[1]);
+ }
}
} else if (!strcmp(name, "vccq")) {
vreg->min_uV = UFS_VREG_VCCQ_MIN_UV;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
Re: [PATCH 1/5] dt-bindings: input: Add documentation for IBM Operation Panel
On Thu, 20 Aug 2020 at 16:12, Eddie James wrote:
>
> Document the bindings for the IBM Operation Panel, which provides
> a simple interface to control a server. It has a display and three
> buttons.
> Also update MAINTAINERS for the new file.
>
> Signed-off-by: Eddie James
Acked-by: Joel Stanley
> ---
> .../bindings/input/ibm,op-panel.yaml | 38 +++
> MAINTAINERS | 6 +++
> 2 files changed, 44 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/input/ibm,op-panel.yaml
>
> diff --git a/Documentation/devicetree/bindings/input/ibm,op-panel.yaml
> b/Documentation/devicetree/bindings/input/ibm,op-panel.yaml
> new file mode 100644
> index ..86a32e8f3ef0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/input/ibm,op-panel.yaml
> @@ -0,0 +1,38 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/input/ibm,op-panel.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: IBM Operation Panel
> +
> +maintainers:
> + - Eddie James
> +
> +description: |
> + The IBM Operation Panel provides a simple interface to control the
> connected
> + server. It has a display and three buttons: two directional arrows and one
> + 'Enter' button.
> +
> +properties:
> + compatible:
> +const: ibm,op-panel
> +
> + reg:
> +maxItems: 1
> +
> +required:
> + - compatible
> + - reg
> +
> +examples:
> + - |
> +i2c {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +ibm-op-panel@62 {
> +compatible = "ibm,op-panel";
> +reg = <0x4062>; /* I2C_OWN_SLAVE_ADDRESS */
> +};
> +};
> diff --git a/MAINTAINERS b/MAINTAINERS
> index ac79fdbdf8d0..a9fd08e9cd54 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -8278,6 +8278,12 @@ T: git
> git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux.git
> F: Documentation/ia64/
> F: arch/ia64/
>
> +IBM Operation Panel Input Driver
> +M: Eddie James
> +L: linux-in...@vger.kernel.org
> +S: Maintained
> +F: Documentation/devicetree/bindings/input/ibm,op-panel.yaml
> +
> IBM Power 842 compression accelerator
> M: Haren Myneni
> S: Supported
> --
> 2.26.2
>
[PATCH v1 1/2] scsi: dt-bindings: ufs: Add vcc-voltage-level for UFS
UFS's specifications supports a range of Vcc operating voltage levels. Add documentation for the UFS's Vcc voltage levels setting. Signed-off-by: Can Guo Signed-off-by: Asutosh Das Signed-off-by: Bao D. Nguyen --- Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt index 415ccdd..7257b32 100644 --- a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt +++ b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt @@ -23,6 +23,8 @@ Optional properties: with "phys" attribute, provides phandle to UFS PHY node - vdd-hba-supply: phandle to UFS host controller supply regulator node - vcc-supply: phandle to VCC supply regulator node +- vcc-voltage-level : specifies voltage levels for VCC supply. + Should be specified in pairs (min, max), units uV. - vccq-supply : phandle to VCCQ supply regulator node - vccq2-supply : phandle to VCCQ2 supply regulator node - vcc-supply-1p8: For embedded UFS devices, valid VCC range is 1.7-1.95V -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH 5/5] ARM: dts: Aspeed: Rainier: Add IBM Operation Panel I2C device
On Thu, 20 Aug 2020 at 16:12, Eddie James wrote:
>
> Set I2C bus 7 to multi-master mode and add the panel device that will
> register as a slave.
>
> Signed-off-by: Eddie James
Same comments as for Tacoma.
Reviewed-by: Joel Stanley
> ---
> arch/arm/boot/dts/aspeed-bmc-ibm-rainier.dts | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/arch/arm/boot/dts/aspeed-bmc-ibm-rainier.dts
> b/arch/arm/boot/dts/aspeed-bmc-ibm-rainier.dts
> index b94421f6cbd5..f121f3c26a3a 100644
> --- a/arch/arm/boot/dts/aspeed-bmc-ibm-rainier.dts
> +++ b/arch/arm/boot/dts/aspeed-bmc-ibm-rainier.dts
> @@ -698,6 +698,7 @@ eeprom@53 {
> };
>
> &i2c7 {
> + multi-master;
> status = "okay";
>
> si7021-a20@20 {
> @@ -831,6 +832,11 @@ gpio@15 {
> };
> };
>
> + ibm-panel@62 {
> + compatible = "ibm,op-panel";
> + reg = <0x4062>; /* I2C_OWN_SLAVE_ADDRESS */
> + };
> +
> dps: dps310@76 {
> compatible = "infineon,dps310";
> reg = <0x76>;
> --
> 2.26.2
>
Re: [PATCH 4/5] ARM: dts: Aspeed: Tacoma: Add IBM Operation Panel I2C device
On Thu, 20 Aug 2020 at 16:12, Eddie James wrote:
>
> Set I2C bus 0 to multi-master mode and add the panel device that will
> register as a slave.
>
> Signed-off-by: Eddie James
Reviewed-by: Joel Stanley
> ---
> arch/arm/boot/dts/aspeed-bmc-opp-tacoma.dts | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-tacoma.dts
> b/arch/arm/boot/dts/aspeed-bmc-opp-tacoma.dts
> index 5f4ee67ac787..9cf2e02ae9e2 100644
> --- a/arch/arm/boot/dts/aspeed-bmc-opp-tacoma.dts
> +++ b/arch/arm/boot/dts/aspeed-bmc-opp-tacoma.dts
> @@ -438,7 +438,13 @@ aliases {
> };
>
> &i2c0 {
> + multi-master;
> status = "okay";
> +
> + ibm-panel@62 {
> + compatible = "ibm,op-panel";
> + reg = <0x4062>; /* I2C_OWN_SLAVE_ADDRESS */
Other users of SLAVE_ADDRESS have included and
written the reg as follows:
reg = <(I2C_OWN_SLAVE_ADDRESS | 0x62)>
Which obviously has the same result. I'll leave it up to you.
Cheers,
Joel
> + };
> };
>
> &i2c1 {
> --
> 2.26.2
>
Re: [PATCH v2] opp: Power on (virtual) power domains managed by the OPP core
On 31-08-20, 17:49, Stephan Gerhold wrote: > I appreciate it, thank you! But actually after our discussion regarding > the "manage multiple power domains which might not always need to be on" > use case I would like to explore that a bit further before we decide on > a final solution that complicates changes later. > > The reason I mention this is that after our discussion I have been > (again) staring at the vendor implementation of CPU frequency scaling of > the platform I'm working on (qcom msm8916). Actually there seems to be yet > another power domain that is scaled only for some CPU frequencies within > the clock driver. (The vendor driver implies this is a requirement of > the PLL clock that is used for higher CPU frequencies, but not sure...) > > I don't fully understand how to implement this in mainline yet. I have > started some research on these "voltage requirements" for clocks, and > based on previous discussions [1] and patches [2] it seems like I'm > *not* supposed to add this to the clock driver, but rather as another > required-opp to the CPU OPP table. > > If that is the case, we would pretty much have a situation like you > described, a power domain that should only be scaled for some of the > OPPs (the higher CPU frequencies). > > But first I need to do some more research, and probably discuss how to > handle that power domain separately first. I think it would be easier if > we postpone this patch till then. I don't think anyone else needs this > patch at the moment. Heh, okay, I can keep it out of my tree then :) > [1]: > https://lore.kernel.org/linux-clk/9439bd29e3ccd5424a8e9b464c8c7...@codeaurora.org/ > [2]: > https://lore.kernel.org/linux-pm/20190320094918.20234-1-rna...@codeaurora.org/ > > > Signed-off-by: Stephan Gerhold > > [ Viresh: Rearranged the code to remove extra loop and minor cleanup ] > > FWIW, the reason I put this into an extra loop is that the > dev_pm_domain_attach_by_name() might return -EPROBE_DEFER (or some other > error) for some of the power domains. If you create the device links > before attaching all domains you might unnecessarily turn on+off some of > them. Hmm, but that shouldn't have any significant side affects, right ? And shouldn't result in some other sort of error. It makes the code look more sensible/readable and so I would prefer to keep a single loop if it doesn't make something not-work. > Having it in a separate loop avoids that, because we only start powering > on the power domains when we know that all the power domains are > available. -- viresh
Re: [PATCH] openrisc: Reserve memblock for initrd
On Tue, Sep 01, 2020 at 06:21:01AM +0900, Stafford Horne wrote:
> Recently OpenRISC added support for external initrd images, but I found
> some instability when using larger buildroot initrd images. It turned
> out that I forgot to reserve the memblock space for the initrd image.
>
> This patch fixes the instability issue by reserving memblock space.
>
> Fixes: ff6c923dbec3 ("openrisc: Add support for external initrd images")
> Signed-off-by: Stafford Horne
> ---
> arch/openrisc/kernel/setup.c | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/arch/openrisc/kernel/setup.c b/arch/openrisc/kernel/setup.c
> index b18e775f8be3..2c8aa53cc7ba 100644
> --- a/arch/openrisc/kernel/setup.c
> +++ b/arch/openrisc/kernel/setup.c
> @@ -80,6 +80,15 @@ static void __init setup_memory(void)
>*/
> memblock_reserve(__pa(_stext), _end - _stext);
>
> +#ifdef CONFIG_BLK_DEV_INITRD
> + /* Then reserve the initrd, if any */
> + if (initrd_start && (initrd_end > initrd_start)) {
> + memblock_reserve(ALIGN_DOWN(__pa(initrd_start), PAGE_SIZE),
> + ALIGN(initrd_end, PAGE_SIZE) -
> + ALIGN_DOWN(initrd_start, PAGE_SIZE));
> + }
The core mm takes care of reserving the entrire pages for the memory
reserved with memblock, so it is not necessary to do it here.
> +#endif /* CONFIG_BLK_DEV_INITRD */
> +
> early_init_fdt_reserve_self();
> early_init_fdt_scan_reserved_mem();
>
> --
> 2.26.2
>
--
Sincerely yours,
Mike.
Re: [PATCH 2/5] input: misc: Add IBM Operation Panel driver
On Thu, 20 Aug 2020 at 16:12, Eddie James wrote: > > Add a driver to get the button events from the panel and provide > them to userspace with the input subsystem. The panel is > connected with I2C and controls the bus, so the driver registers > as an I2C slave device. > > Signed-off-by: Eddie James > --- > MAINTAINERS| 1 + > drivers/input/misc/Kconfig | 10 ++ > drivers/input/misc/Makefile| 1 + > drivers/input/misc/ibm-panel.c | 186 + > 4 files changed, 198 insertions(+) > create mode 100644 drivers/input/misc/ibm-panel.c > > diff --git a/MAINTAINERS b/MAINTAINERS > index a9fd08e9cd54..077cc79ad7fd 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -8283,6 +8283,7 @@ M:Eddie James > L: linux-in...@vger.kernel.org > S: Maintained > F: Documentation/devicetree/bindings/input/ibm,op-panel.yaml > +F: drivers/input/misc/ibm-panel.c > > IBM Power 842 compression accelerator > M: Haren Myneni > diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig > index 362e8a01980c..88fb465a18b8 100644 > --- a/drivers/input/misc/Kconfig > +++ b/drivers/input/misc/Kconfig > @@ -708,6 +708,16 @@ config INPUT_ADXL34X_SPI > To compile this driver as a module, choose M here: the > module will be called adxl34x-spi. > > +config INPUT_IBM_PANEL > + tristate "IBM Operation Panel driver" > + depends on I2C_SLAVE || COMPILE_TEST > + help > + Supports the IBM Operation Panel as an input device. The panel is a > + controller attached to the system with some buttons and an LCD > display > + that allows someone with physical access to the system to perform > + various administrative tasks. This driver only supports the part of > + the controller that sends commands to the system. Is this always attached via a service processor/bmc? If so, mention it here so people know there's no point enabling it on a host/distro kernel. I assume you're implementing the protocol correctly. If you have a link to a specification then include that in the file. The code looks okay to me. Reviewed-by: Joel Stanley
Re: [PATCH v6 1/5] perf/jevents: Remove jevents.h file
On 8/31/20 2:31 PM, John Garry wrote:
> On 31/08/2020 09:43, Jiri Olsa wrote:
>> On Thu, Aug 27, 2020 at 06:39:54PM +0530, Kajol Jain wrote:
>>> This patch removes jevents.h file and add its data inside
>>> jevents.c as this file is only included there.
>>>
>>> Signed-off-by: Kajol Jain
>>> ---
>>> tools/perf/pmu-events/jevents.c | 9 -
>>> tools/perf/pmu-events/jevents.h | 23 ---
>>> 2 files changed, 8 insertions(+), 24 deletions(-)
>>> delete mode 100644 tools/perf/pmu-events/jevents.h
>>>
>>> diff --git a/tools/perf/pmu-events/jevents.c
>>> b/tools/perf/pmu-events/jevents.c
>>> index fa86c5f997cc..1c55cc754b5a 100644
>>> --- a/tools/perf/pmu-events/jevents.c
>>> +++ b/tools/perf/pmu-events/jevents.c
>>> @@ -48,11 +48,18 @@
>>> #include
>>> #include "jsmn.h"
>>> #include "json.h"
>>> -#include "jevents.h"
>>> int verbose;
>>> char *prog;
>>> +#ifndef min
>>> +#define min(x, y) ({ \
>>> + typeof(x) _min1 = (x); \
>>> + typeof(y) _min2 = (y); \
>>> + (void)(&_min1 == &_min2); \
>>> + _min1 < _min2 ? _min1 : _min2; })
>>> +#endif
>
> Wondering what is special about this definition of min that it's required?
> Compiled ok for me without it.
Hi John,
You are right, for me also in power it compiled without any issues, but
not sure if somewhere we have dependency,
that's why I didn't remove it.
Thanks,
Kajol Jain
>
>>> +
>>> int eprintf(int level, int var, const char *fmt, ...)
>>> {
>>> diff --git a/tools/perf/pmu-events/jevents.h
>>> b/tools/perf/pmu-events/jevents.h
>>> deleted file mode 100644
>>> index 2afc8304529e..
>>> --- a/tools/perf/pmu-events/jevents.h
>>> +++ /dev/null
>>> @@ -1,23 +0,0 @@
>>> -/* SPDX-License-Identifier: GPL-2.0 */
>>> -#ifndef JEVENTS_H
>>> -#define JEVENTS_H 1
>>> -
>>> -int json_events(const char *fn,
>>> - int (*func)(void *data, char *name, char *event, char *desc,
>>> - char *long_desc,
>>> - char *pmu,
>>> - char *unit, char *perpkg, char *metric_expr,
>>> - char *metric_name, char *metric_group,
>>> - char *deprecated, char *metric_constraint),
>>> - void *data);
>>> -char *get_cpu_str(void);
>>
>> I think you can also remove get_cpu_str from jevents.c
>>
>> thanks,
>> jirka
>>
>> .
>>
>
Re: [PATCH v7 2/3] dt-bindings: phy: intel: Add Keem Bay eMMC PHY bindings
On 01-09-20, 04:58, Wan Mohamad, Wan Ahmad Zainie wrote: > > > @@ -0,0 +1,44 @@ > > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 > > > +--- > > > +$id: "http://devicetree.org/schemas/phy/intel,keembay-emmc- > > phy.yaml#" > > > +$schema: "http://devicetree.org/meta-schemas/core.yaml#"; > > > + > > > +title: Intel Keem Bay eMMC PHY bindings > > > > This seems same as > > Documentation/devicetree/bindings/phy/intel,lgm-emmc-phy.yaml, why > > not add a new compatible in lgm binding, or did I miss a difference? > > AFAIK, LGM make use of syscon node, whilst KMB does not. > And LGM and KMB belongs to different SoC family. So, I prefer them to > be in separate file. > > Having said that, with few changes in wordings in title and description, > I think we can make it generic and can be used across few products. The bindings seems quite similar. We can have two drivers loaded using two compatible but binding description can be made same -- ~Vinod
Re: [PATCH v6 1/5] perf/jevents: Remove jevents.h file
On 8/31/20 2:13 PM, Jiri Olsa wrote:
> On Thu, Aug 27, 2020 at 06:39:54PM +0530, Kajol Jain wrote:
>> This patch removes jevents.h file and add its data inside
>> jevents.c as this file is only included there.
>>
>> Signed-off-by: Kajol Jain
>> ---
>> tools/perf/pmu-events/jevents.c | 9 -
>> tools/perf/pmu-events/jevents.h | 23 ---
>> 2 files changed, 8 insertions(+), 24 deletions(-)
>> delete mode 100644 tools/perf/pmu-events/jevents.h
>>
>> diff --git a/tools/perf/pmu-events/jevents.c
>> b/tools/perf/pmu-events/jevents.c
>> index fa86c5f997cc..1c55cc754b5a 100644
>> --- a/tools/perf/pmu-events/jevents.c
>> +++ b/tools/perf/pmu-events/jevents.c
>> @@ -48,11 +48,18 @@
>> #include
>> #include "jsmn.h"
>> #include "json.h"
>> -#include "jevents.h"
>>
>> int verbose;
>> char *prog;
>>
>> +#ifndef min
>> +#define min(x, y) ({\
>> +typeof(x) _min1 = (x); \
>> +typeof(y) _min2 = (y); \
>> +(void)(&_min1 == &_min2); \
>> +_min1 < _min2 ? _min1 : _min2; })
>> +#endif
>> +
>> int eprintf(int level, int var, const char *fmt, ...)
>> {
>>
>> diff --git a/tools/perf/pmu-events/jevents.h
>> b/tools/perf/pmu-events/jevents.h
>> deleted file mode 100644
>> index 2afc8304529e..
>> --- a/tools/perf/pmu-events/jevents.h
>> +++ /dev/null
>> @@ -1,23 +0,0 @@
>> -/* SPDX-License-Identifier: GPL-2.0 */
>> -#ifndef JEVENTS_H
>> -#define JEVENTS_H 1
>> -
>> -int json_events(const char *fn,
>> -int (*func)(void *data, char *name, char *event, char *desc,
>> -char *long_desc,
>> -char *pmu,
>> -char *unit, char *perpkg, char *metric_expr,
>> -char *metric_name, char *metric_group,
>> -char *deprecated, char *metric_constraint),
>> -void *data);
>> -char *get_cpu_str(void);
>
> I think you can also remove get_cpu_str from jevents.c
Hi Jiri,
Yes, I will check that part.
Thanks,
Kajol Jain
>
> thanks,
> jirka
>
Re: ERROR: "min_low_pfn" undefined!
On 8/31/20 10:41 PM, kernel test robot wrote: > Hi Arnd, > > First bad commit (maybe != root cause): > > tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > master > head: b51594df17d0ce80b9f9f35394a1f42d7ac94472 > commit: 710ec38b0f633ab3e2581f07a73442d809e28ab0 mm: add dummy can_do_mlock() > helper > date: 11 months ago > config: microblaze-randconfig-r031-20200831 (attached as .config) > compiler: microblaze-linux-gcc (GCC) 9.3.0 > reproduce (this is a W=1 build): > wget > https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O > ~/bin/make.cross > chmod +x ~/bin/make.cross > git checkout 710ec38b0f633ab3e2581f07a73442d809e28ab0 > # save the attached .config to linux build tree > COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross > ARCH=microblaze > > If you fix the issue, kindly add following tag as appropriate > Reported-by: kernel test robot > > All errors (new ones prefixed by >>): > >>> ERROR: "min_low_pfn" [drivers/rpmsg/virtio_rpmsg_bus.ko] undefined! >ERROR: "min_low_pfn" [drivers/block/aoe/aoe.ko] undefined! Please test https://lore.kernel.org/lkml/20200829000110.2408-1-rdun...@infradead.org/ -- ~Randy
Re: [PATCH 5/6] Documentation: tracing: Add %return suffix description
On Tue, 1 Sep 2020 07:27:45 +0900 Masami Hiramatsu wrote: > On Mon, 31 Aug 2020 11:50:20 -0700 > Randy Dunlap wrote: > > > On 8/31/20 5:46 AM, Masami Hiramatsu wrote: > > > Add a description of the %return suffix option for kprobe tracer. > > > > > > Signed-off-by: Masami Hiramatsu > > > --- > > > Documentation/trace/kprobetrace.rst |2 ++ > > > 1 file changed, 2 insertions(+) > > > > > > diff --git a/Documentation/trace/kprobetrace.rst > > > b/Documentation/trace/kprobetrace.rst > > > index c1709165c553..d29d1f9e6721 100644 > > > --- a/Documentation/trace/kprobetrace.rst > > > +++ b/Documentation/trace/kprobetrace.rst > > > > Check spacing: > > > > > @@ -37,6 +38,7 @@ Synopsis of kprobe_events > > > based on SYM+offs or MEMADDR. > > > MOD : Module name which has given SYM. > > > SYM[+offs] : Symbol+offset where the probe is inserted. > > > + SYM%return : Return address of the symbol > > > MEMADDR : Address where the probe is inserted. > > > MAXACTIVE : Maximum number of instances of the specified function > > > that > > > can be probed simultaneously, or 0 for the default value > > > > If I remove the '+', the ':' lines up but the SYM does not line up. > > Am I missing something? > > > > @@ -37,6 +38,7 @@ Synopsis of kprobe_events > > based on SYM+offs or MEMADDR. > > MOD : Module name which has given SYM. > > SYM[+offs]: Symbol+offset where the probe is inserted. > > SYM%return : Return address of the symbol > > MEMADDR : Address where the probe is inserted. > > MAXACTIVE : Maximum number of instances of the specified function that > > can be probed simultaneously, or 0 for the default value > > > Shouldn't we use the horizontal tab in .rst ? It seems other lines use a tab to indent, but this line doesn't (VIM converted the tab to spaces.) Thank you, -- Masami Hiramatsu
Re: [PATCH 01/19] drm/msm: remove dangling submitqueue references
On Tue 01 Sep 03:42 UTC 2020, Rob Clark wrote:
> On Mon, Aug 31, 2020 at 7:35 PM Bjorn Andersson
> wrote:
> >
> > On Fri 14 Aug 02:40 UTC 2020, Rob Clark wrote:
> >
> > > From: Rob Clark
> > >
> > > Currently it doesn't matter, since we free the ctx immediately. But
> > > when we start refcnt'ing the ctx, we don't want old dangling list
> > > entries to hang around.
> > >
> > > Signed-off-by: Rob Clark
> > > ---
> > > drivers/gpu/drm/msm/msm_submitqueue.c | 4 +++-
> > > 1 file changed, 3 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/msm/msm_submitqueue.c
> > > b/drivers/gpu/drm/msm/msm_submitqueue.c
> > > index a1d94be7883a..90c9d84e6155 100644
> > > --- a/drivers/gpu/drm/msm/msm_submitqueue.c
> > > +++ b/drivers/gpu/drm/msm/msm_submitqueue.c
> > > @@ -49,8 +49,10 @@ void msm_submitqueue_close(struct msm_file_private
> > > *ctx)
> > >* No lock needed in close and there won't
> > >* be any more user ioctls coming our way
> > >*/
> > > - list_for_each_entry_safe(entry, tmp, &ctx->submitqueues, node)
> > > + list_for_each_entry_safe(entry, tmp, &ctx->submitqueues, node) {
> > > + list_del(&entry->node);
> >
> > If you refcount ctx, what does that do for the entries in the submit
> > queue?
> >
> > "entry" here is kref'ed, but you're popping it off the list regardless
> > of the put ends up freeing the object or not - which afaict would mean
> > leaking the object.
> >
>
> What ends up happening is the submit has reference to submit-queue,
> which has reference to the ctx.. the submitqueue could be alive still
> pending in-flight submits (in a later patch), but dead from the PoV of
> userspace interface.
>
> We aren't relying (or at least aren't in the end, and I *think* I
> didn't miss anything in the middle) relying on ctx->submitqueues list
> to clean anything up in the end, just track what is still a valid
> submitqueue from userspace PoV
>
Looks reasonable, thanks for the explanation.
> BR,
> -R
>
> >
> > On the other hand, with the current implementation an object with higher
> > refcount with adjacent objects of single refcount would end up with
> > dangling pointers after the put. So in itself this change seems like a
> > net gain, but I'm wondering about the plan described in the commit
> > message.
> >
> > Regards,
> > Bjorn
> >
> > > msm_submitqueue_put(entry);
> > > + }
> > > }
> > >
> > > int msm_submitqueue_create(struct drm_device *drm, struct
> > > msm_file_private *ctx,
> > > --
> > > 2.26.2
> > >
ERROR: "min_low_pfn" undefined!
Hi Arnd, First bad commit (maybe != root cause): tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: b51594df17d0ce80b9f9f35394a1f42d7ac94472 commit: 710ec38b0f633ab3e2581f07a73442d809e28ab0 mm: add dummy can_do_mlock() helper date: 11 months ago config: microblaze-randconfig-r031-20200831 (attached as .config) compiler: microblaze-linux-gcc (GCC) 9.3.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross git checkout 710ec38b0f633ab3e2581f07a73442d809e28ab0 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=microblaze If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): >> ERROR: "min_low_pfn" [drivers/rpmsg/virtio_rpmsg_bus.ko] undefined! ERROR: "min_low_pfn" [drivers/block/aoe/aoe.ko] undefined! --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip
Re: [PATCH 01/19] drm/msm: remove dangling submitqueue references
On Fri 14 Aug 02:40 UTC 2020, Rob Clark wrote:
> From: Rob Clark
>
> Currently it doesn't matter, since we free the ctx immediately. But
> when we start refcnt'ing the ctx, we don't want old dangling list
> entries to hang around.
>
> Signed-off-by: Rob Clark
Reviewed-by: Bjorn Andersson
> ---
> drivers/gpu/drm/msm/msm_submitqueue.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/msm/msm_submitqueue.c
> b/drivers/gpu/drm/msm/msm_submitqueue.c
> index a1d94be7883a..90c9d84e6155 100644
> --- a/drivers/gpu/drm/msm/msm_submitqueue.c
> +++ b/drivers/gpu/drm/msm/msm_submitqueue.c
> @@ -49,8 +49,10 @@ void msm_submitqueue_close(struct msm_file_private *ctx)
>* No lock needed in close and there won't
>* be any more user ioctls coming our way
>*/
> - list_for_each_entry_safe(entry, tmp, &ctx->submitqueues, node)
> + list_for_each_entry_safe(entry, tmp, &ctx->submitqueues, node) {
> + list_del(&entry->node);
> msm_submitqueue_put(entry);
> + }
> }
>
> int msm_submitqueue_create(struct drm_device *drm, struct msm_file_private
> *ctx,
> --
> 2.26.2
>
Re: [PATCH v3 1/1] PCI/ERR: Fix reset logic in pcie_do_recovery() call
Hi Bjorn,
On 7/24/20 12:07 PM, sathyanarayanan.kuppusw...@linux.intel.com wrote:
From: Kuppuswamy Sathyanarayanan
Current pcie_do_recovery() implementation has following two issues:
1. Fatal (DPC) error recovery is currently broken for non-hotplug
capable devices. Current fatal error recovery implementation relies
on PCIe hotplug (pciehp) handler for detaching and re-enumerating
the affected devices/drivers. pciehp handler listens for DLLSC state
changes and handles device/driver detachment on DLLSC_LINK_DOWN event
and re-enumeration on DLLSC_LINK_UP event. So when dealing with
non-hotplug capable devices, recovery code does not restore the state
of the affected devices correctly. Correct implementation should
restore the device state and call report_slot_reset() function after
resetting the link to restore the state of the device/driver.
You can find fatal non-hotplug related issues reported in following links:
https://lore.kernel.org/linux-pci/20200527083130.4137-1-zhiqiang@nxp.com/
https://lore.kernel.org/linux-pci/12115.1588207324@famine/
https://lore.kernel.org/linux-pci/0e6f89cd6b9e4a72293cc90fafe93487d7c2d295.158584.git.sathyanarayanan.kuppusw...@linux.intel.com/
2. For non-fatal errors if report_error_detected() or
report_mmio_enabled() functions requests PCI_ERS_RESULT_NEED_RESET then
current pcie_do_recovery() implementation does not do the requested
explicit device reset, instead just calls the report_slot_reset() on all
affected devices. Notifying about the reset via report_slot_reset()
without doing the actual device reset is incorrect.
To fix above issues, use PCI_ERS_RESULT_NEED_RESET as error state after
successful reset_link() operation. This will ensure ->slot_reset() be
called after reset_link() operation for fatal errors. Also call
pci_bus_reset() to do slot/bus reset() before triggering device specific
->slot_reset() callback. Also, using pci_bus_reset() will restore the state
of the devices after performing the reset operation.
Even though using pci_bus_reset() will do redundant reset operation after
->reset_link() for fatal errors, it should should affect the functional
behavior.
Any comment on this patch?
[original patch is from jay.vosbu...@canonical.com]
[original patch link https://lore.kernel.org/linux-pci/12115.1588207324@famine/]
Fixes: 6d2c89441571 ("PCI/ERR: Update error status after reset_link()")
Signed-off-by: Jay Vosburgh
Signed-off-by: Kuppuswamy Sathyanarayanan
---
Changes since v2:
* Changed the subject of patch to "PCI/ERR: Fix reset logic in
pcie_do_recovery() call". v2 patch link is,
https://lore.kernel.org/linux-pci/ce417fbf81a8a46a89535f44b9224ee9fbb55a29.1591307288.git.sathyanarayanan.kuppusw...@linux.intel.com/
* Squashed "PCI/ERR: Add reset support for non fatal errors" patch.
drivers/pci/pcie/err.c | 41 +
1 file changed, 37 insertions(+), 4 deletions(-)
diff --git a/drivers/pci/pcie/err.c b/drivers/pci/pcie/err.c
index 14bb8f54723e..b5eb6ba65be1 100644
--- a/drivers/pci/pcie/err.c
+++ b/drivers/pci/pcie/err.c
@@ -165,8 +165,29 @@ pci_ers_result_t pcie_do_recovery(struct pci_dev *dev,
pci_dbg(dev, "broadcast error_detected message\n");
if (state == pci_channel_io_frozen) {
pci_walk_bus(bus, report_frozen_detected, &status);
+ /*
+* After resetting the link using reset_link() call, the
+* possible value of error status is either
+* PCI_ERS_RESULT_DISCONNECT (failure case) or
+* PCI_ERS_RESULT_NEED_RESET (success case).
+* So ignore the return value of report_error_detected()
+* call for fatal errors.
+*
+* In EDR mode, since AER and DPC Capabilities are owned by
+* firmware, reported_error_detected() will return error
+* status PCI_ERS_RESULT_NO_AER_DRIVER. Continuing
+* pcie_do_recovery() with error status as
+* PCI_ERS_RESULT_NO_AER_DRIVER will report recovery failure
+* irrespective of recovery status. But successful reset_link()
+* call usually recovers all fatal errors. So ignoring the
+* status result of report_error_detected() also helps EDR based
+* error recovery.
+*/
status = reset_link(dev);
- if (status != PCI_ERS_RESULT_RECOVERED) {
+ if (status == PCI_ERS_RESULT_RECOVERED) {
+ status = PCI_ERS_RESULT_NEED_RESET;
+ } else {
+ status = PCI_ERS_RESULT_DISCONNECT;
pci_warn(dev, "link reset failed\n");
goto failed;
}
@@ -182,10 +203,22 @@ pci_ers_result_t pcie_do_recovery(struct pci_dev *dev,
if (status == PCI_ERS_RESULT_NEED_RESET) {
/*
-* TODO: Should ca
Re: [RFC PATCH 1/2] Documentation/admin-guide: README & svga: remove use of "rdev"
On 2020-08-31 22:38, Randy Dunlap wrote: > > --- linux-next-20200828.orig/Documentation/admin-guide/svga.rst > +++ linux-next-20200828/Documentation/admin-guide/svga.rst > @@ -12,7 +12,7 @@ Intro > This small document describes the "Video Mode Selection" feature which > allows the use of various special video modes supported by the video BIOS. > Due > to usage of the BIOS, the selection is limited to boot time (before the > -kernel decompression starts) and works only on 80X86 machines. > +kernel decompression starts) and works only on 32-bit 80X86 machines. > Incorrect. What controls if this is available is whether or not the kernel is booted through BIOS firmware (as opposed to UEFI, kexec, etc.) -hpa
[RFC PATCH 0/2] Documentation/admin-guide: remove use of "rdev"
Remove mention of using "rdev" to set boot device, video mode, or ramdisk information for the booting kernel. FIX patch 1/2 Subject: Cc: Karel Zak Cc: Paul Gortmaker Cc: Jens Axboe Cc: linux-bl...@vger.kernel.org Cc: Alexander Viro Cc: Martin Mares Cc: linux-vi...@atrey.karlin.mff.cuni.cz Cc: "H. Peter Anvin" Cc: Jonathan Corbet Cc: linux-...@vger.kernel.org [RFC PATCH 1/2] Documentation/admin-guide: README & svga: remove use of "rdev" [RFC PATCH 2/2] Documentation/admin-guide: blockdev/ramdisk: remove use of "rdev" Documentation/admin-guide/README.rst|6 - Documentation/admin-guide/blockdev/ramdisk.rst | 70 -- Documentation/admin-guide/kernel-parameters.txt |9 - Documentation/admin-guide/svga.rst |6 - 4 files changed, 33 insertions(+), 58 deletions(-)
[RFC PATCH 1/2] Documentation/admin-guide: README & svga: remove use of "rdev"
"rdev" is considered antiquated, ancient, archaic, obsolete, deprecated
{choose any or all}.
Remove use of "rdev" and "vidmode" (a symlink to rdev) in
admin-guide/README.rst and admin-guide/svga.rst.
"rdev" was removed from util-linux in 2010:
https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/commit/?id=a3e40c14651fccf18e7954f081e601389baefe3f
Signed-off-by: Randy Dunlap
Cc: Karel Zak
Cc: Paul Gortmaker
Cc: Jens Axboe
Cc: linux-bl...@vger.kernel.org
Cc: Alexander Viro
Cc: Martin Mares
Cc: linux-vi...@atrey.karlin.mff.cuni.cz
Cc: "H. Peter Anvin"
Cc: Jonathan Corbet
Cc: linux-...@vger.kernel.org
---
No email address for these:
nCc: Werner Almesberger
nCc: Stephen Tweedie
nCc: Peter MacDonald
Documentation/admin-guide/README.rst |6 +++---
Documentation/admin-guide/svga.rst |6 +++---
2 files changed, 6 insertions(+), 6 deletions(-)
--- linux-next-20200828.orig/Documentation/admin-guide/README.rst
+++ linux-next-20200828/Documentation/admin-guide/README.rst
@@ -322,9 +322,9 @@ Compiling the kernel
reboot, and enjoy!
If you ever need to change the default root device, video mode,
- ramdisk size, etc. in the kernel image, use the ``rdev`` program (or
- alternatively the LILO boot options when appropriate). No need to
- recompile the kernel to change these parameters.
+ etc. in the kernel image, use your bootloader's boot options
+ where appropriate. No need to recompile the kernel to change
+ these parameters.
- Reboot with the new kernel and enjoy.
--- linux-next-20200828.orig/Documentation/admin-guide/svga.rst
+++ linux-next-20200828/Documentation/admin-guide/svga.rst
@@ -12,7 +12,7 @@ Intro
This small document describes the "Video Mode Selection" feature which
allows the use of various special video modes supported by the video BIOS. Due
to usage of the BIOS, the selection is limited to boot time (before the
-kernel decompression starts) and works only on 80X86 machines.
+kernel decompression starts) and works only on 32-bit 80X86 machines.
.. note::
@@ -23,7 +23,7 @@ kernel decompression starts) and works o
The video mode to be used is selected by a kernel parameter which can be
specified in the kernel Makefile (the SVGA_MODE=... line) or by the "vga=..."
-option of LILO (or some other boot loader you use) or by the "vidmode" utility
+option of LILO (or some other boot loader you use) or by the "xrandr" utility
(present in standard Linux utility packages). You can use the following values
of this parameter::
@@ -41,7 +41,7 @@ of this parameter::
better to use absolute mode numbers instead.
0x - Hexadecimal video mode ID (also displayed on the menu, see below
- for exact meaning of the ID). Warning: rdev and LILO don't support
+ for exact meaning of the ID). Warning: LILO doesn't support
hexadecimal numbers -- you have to convert it to decimal manually.
Menu
[RFC PATCH 2/2] Documentation/admin-guide: blockdev/ramdisk: remove use of "rdev"
Remove use of "rdev" from blockdev/ramdisk.rst and update
admin-guide/kernel-parameters.txt.
"rdev" is considered antiquated, ancient, archaic, obsolete, deprecated
{choose any or all}.
"rdev" was removed from util-linux in 2010:
https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/commit/?id=a3e40c14651fccf18e7954f081e601389baefe3f
Signed-off-by: Randy Dunlap
Cc: Karel Zak
Cc: Paul Gortmaker
Cc: Jens Axboe
Cc: linux-bl...@vger.kernel.org
Cc: Alexander Viro
Cc: Martin Mares
Cc: linux-vi...@atrey.karlin.mff.cuni.cz
Cc: "H. Peter Anvin"
Cc: Jonathan Corbet
Cc: linux-...@vger.kernel.org
---
No email address for these:
nCc: Werner Almesberger
nCc: Stephen Tweedie
nCc: Peter MacDonald
Documentation/admin-guide/blockdev/ramdisk.rst | 70 --
Documentation/admin-guide/kernel-parameters.txt |9 -
2 files changed, 27 insertions(+), 52 deletions(-)
--- linux-next-20200828.orig/Documentation/admin-guide/blockdev/ramdisk.rst
+++ linux-next-20200828/Documentation/admin-guide/blockdev/ramdisk.rst
@@ -6,7 +6,7 @@ Using the RAM disk block device with Lin
1) Overview
2) Kernel Command Line Parameters
- 3) Using "rdev -r"
+ 3) Using "rdev"
4) An Example of Creating a Compressed RAM Disk
@@ -59,51 +59,27 @@ default is 4096 (4 MB).
rd_size
See ramdisk_size.
-3) Using "rdev -r"
---
+3) Using "rdev"
+---
-The usage of the word (two bytes) that "rdev -r" sets in the kernel image is
-as follows. The low 11 bits (0 -> 10) specify an offset (in 1 k blocks) of up
-to 2 MB (2^11) of where to find the RAM disk (this used to be the size). Bit
-14 indicates that a RAM disk is to be loaded, and bit 15 indicates whether a
-prompt/wait sequence is to be given before trying to read the RAM disk. Since
-the RAM disk dynamically grows as data is being written into it, a size field
-is not required. Bits 11 to 13 are not currently used and may as well be zero.
-These numbers are no magical secrets, as seen below::
-
- ./arch/x86/kernel/setup.c:#define RAMDISK_IMAGE_START_MASK 0x07FF
- ./arch/x86/kernel/setup.c:#define RAMDISK_PROMPT_FLAG 0x8000
- ./arch/x86/kernel/setup.c:#define RAMDISK_LOAD_FLAG0x4000
-
-Consider a typical two floppy disk setup, where you will have the
-kernel on disk one, and have already put a RAM disk image onto disk #2.
-
-Hence you want to set bits 0 to 13 as 0, meaning that your RAM disk
-starts at an offset of 0 kB from the beginning of the floppy.
-The command line equivalent is: "ramdisk_start=0"
-
-You want bit 14 as one, indicating that a RAM disk is to be loaded.
-The command line equivalent is: "load_ramdisk=1"
-
-You want bit 15 as one, indicating that you want a prompt/keypress
-sequence so that you have a chance to switch floppy disks.
-The command line equivalent is: "prompt_ramdisk=1"
-
-Putting that together gives 2^15 + 2^14 + 0 = 49152 for an rdev word.
-So to create disk one of the set, you would do::
-
- /usr/src/linux# cat arch/x86/boot/zImage > /dev/fd0
- /usr/src/linux# rdev /dev/fd0 /dev/fd0
- /usr/src/linux# rdev -r /dev/fd0 49152
+"rdev" is an obsolete, deprecated, antiquated utility that could be used
+to set the boot device in a Linux kernel image.
-If you make a boot disk that has LILO, then for the above, you would use::
+Instead of using rdev, just place the boot device information on the
+kernel command line and pass it to the kernel from the bootloader.
+
+You can also pass arguments to the kernel by setting FDARGS in
+arch/x86/boot/Makefile and specify in initrd image by setting FDINITRD in
+arch/x86/boot/Makefile.
- append = "ramdisk_start=0 load_ramdisk=1 prompt_ramdisk=1"
+Some of the kernel command line boot options that may apply here are::
-Since the default start = 0 and the default prompt = 1, you could use::
+ ramdisk_start=N
+ ramdisk_size=M
- append = "load_ramdisk=1"
+If you make a boot disk that has LILO, then for the above, you would use::
+ append = "ramdisk_start=N ramdisk_size=M"
4) An Example of Creating a Compressed RAM Disk
---
@@ -151,12 +127,9 @@ f) Put the RAM disk image onto the flopp
dd if=/tmp/ram_image.gz of=/dev/fd0 bs=1k seek=400
-g) Use "rdev" to set the boot device, RAM disk offset, prompt flag, etc.
- For prompt_ramdisk=1, load_ramdisk=1, ramdisk_start=400, one would
- have 2^15 + 2^14 + 400 = 49552::
-
- rdev /dev/fd0 /dev/fd0
- rdev -r /dev/fd0 49552
+g) Make sure that you have already specified the boot information in
+ FDARGS and FDINITRD or that you use a bootloader to pass kernel
+ command line boot options to the kernel.
That is it. You now have your boot/root compressed RAM disk floppy. Some
users may wish to combine steps (d) and (f) by using a pipe.
@@ -167,11 +140,14 @@ users may wish to combine steps (d) and
Changelog:
--
+09-2020 :
Re: [PATCH] Documentation/x86/boot.rst: minor improvement
If you are going to fix the language... On 2020-08-31 22:25, Cao jin wrote: > Sorry, I mis-copied 2 addresses. make sure they are CCed. > > On 9/1/20 11:41 AM, Cao jin wrote: >> Typo fix & file name update >> >> Signed-off-by: Cao jin >> --- >> Documentation/x86/boot.rst | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/Documentation/x86/boot.rst b/Documentation/x86/boot.rst >> index 7fafc7ac00d7..c04afec90486 100644 >> --- a/Documentation/x86/boot.rst >> +++ b/Documentation/x86/boot.rst >> @@ -1379,7 +1379,7 @@ can be calculated as follows:: >> In addition to read/modify/write the setup header of the struct >> boot_params as that of 16-bit boot protocol, the boot loader should >> also fill the additional fields of the struct boot_params as described >> -in zero-page.txt. >> +in zero-page.rst. >> >> After setting up the struct boot_params, the boot loader can load >> 64-bit kernel in the same way as that of 16-bit boot protocol, but >> @@ -1391,7 +1391,7 @@ In 64-bit boot protocol, the kernel is started by >> jumping to the >> >> At entry, the CPU must be in 64-bit mode with paging enabled. (Paging enabled is redundant here.) >> The range with setup_header.init_size from start address of loaded >> -kernel and zero page and command line buffer get ident mapping; >> +kernel and zero page and command line buffer get identity mapping; The range with setup_header.init_size from start address of the loaded kernel, the zero page, and the command line buffer get identity-mapped, anda GDT must be loaded with the descriptors for selectors __BOOT_CS(0x10) and __BOOT_DS(0x18): both descriptors must be 4G flat segment with __BOOT_CS having execute/read permission and __BOOT_DS... Also, it might be useful to take a look to see if other data structures, like setup_data and the initrd also need to be in the identity map. -hpa
Re: [PATCH 19/19] drm/msm: show process names in gem_describe
On Thu 13 Aug 21:41 CDT 2020, Rob Clark wrote:
> From: Rob Clark
>
> In $debugfs/gem we already show any vma(s) associated with an object.
> Also show process names if the vma's address space is a per-process
> address space.
>
Reviewed-by: Bjorn Andersson
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/msm/msm_drv.c | 2 +-
> drivers/gpu/drm/msm/msm_gem.c | 25 +
> drivers/gpu/drm/msm/msm_gem.h | 5 +
> drivers/gpu/drm/msm/msm_gem_vma.c | 1 +
> drivers/gpu/drm/msm/msm_gpu.c | 8 +---
> drivers/gpu/drm/msm/msm_gpu.h | 2 +-
> 6 files changed, 34 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
> index 8e70d220bba8..8d5c4f98c332 100644
> --- a/drivers/gpu/drm/msm/msm_drv.c
> +++ b/drivers/gpu/drm/msm/msm_drv.c
> @@ -597,7 +597,7 @@ static int context_init(struct drm_device *dev, struct
> drm_file *file)
> kref_init(&ctx->ref);
> msm_submitqueue_init(dev, ctx);
>
> - ctx->aspace = msm_gpu_create_private_address_space(priv->gpu);
> + ctx->aspace = msm_gpu_create_private_address_space(priv->gpu, current);
> file->driver_priv = ctx;
>
> return 0;
> diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
> index 3cb7aeb93fd3..76a6c5271e57 100644
> --- a/drivers/gpu/drm/msm/msm_gem.c
> +++ b/drivers/gpu/drm/msm/msm_gem.c
> @@ -842,11 +842,28 @@ void msm_gem_describe(struct drm_gem_object *obj,
> struct seq_file *m)
>
> seq_puts(m, " vmas:");
>
> - list_for_each_entry(vma, &msm_obj->vmas, list)
> - seq_printf(m, " [%s: %08llx,%s,inuse=%d]",
> - vma->aspace != NULL ? vma->aspace->name : NULL,
> - vma->iova, vma->mapped ? "mapped" : "unmapped",
> + list_for_each_entry(vma, &msm_obj->vmas, list) {
> + const char *name, *comm;
> + if (vma->aspace) {
> + struct msm_gem_address_space *aspace =
> vma->aspace;
> + struct task_struct *task =
> + get_pid_task(aspace->pid, PIDTYPE_PID);
> + if (task) {
> + comm = kstrdup(task->comm, GFP_KERNEL);
> + } else {
> + comm = NULL;
> + }
> + name = aspace->name;
> + } else {
> + name = comm = NULL;
> + }
> + seq_printf(m, " [%s%s%s: aspace=%p,
> %08llx,%s,inuse=%d]",
> + name, comm ? ":" : "", comm ? comm : "",
> + vma->aspace, vma->iova,
> + vma->mapped ? "mapped" : "unmapped",
> vma->inuse);
> + kfree(comm);
> + }
>
> seq_puts(m, "\n");
> }
> diff --git a/drivers/gpu/drm/msm/msm_gem.h b/drivers/gpu/drm/msm/msm_gem.h
> index 9c573c4269cb..7b1c7a5f8eef 100644
> --- a/drivers/gpu/drm/msm/msm_gem.h
> +++ b/drivers/gpu/drm/msm/msm_gem.h
> @@ -24,6 +24,11 @@ struct msm_gem_address_space {
> spinlock_t lock; /* Protects drm_mm node allocation/removal */
> struct msm_mmu *mmu;
> struct kref kref;
> +
> + /* For address spaces associated with a specific process, this
> + * will be non-NULL:
> + */
> + struct pid *pid;
> };
>
> struct msm_gem_vma {
> diff --git a/drivers/gpu/drm/msm/msm_gem_vma.c
> b/drivers/gpu/drm/msm/msm_gem_vma.c
> index 29cc1305cf37..80a8a266d68f 100644
> --- a/drivers/gpu/drm/msm/msm_gem_vma.c
> +++ b/drivers/gpu/drm/msm/msm_gem_vma.c
> @@ -17,6 +17,7 @@ msm_gem_address_space_destroy(struct kref *kref)
> drm_mm_takedown(&aspace->mm);
> if (aspace->mmu)
> aspace->mmu->funcs->destroy(aspace->mmu);
> + put_pid(aspace->pid);
> kfree(aspace);
> }
>
> diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
> index 951850804d77..ac8961187a73 100644
> --- a/drivers/gpu/drm/msm/msm_gpu.c
> +++ b/drivers/gpu/drm/msm/msm_gpu.c
> @@ -825,10 +825,9 @@ static int get_clocks(struct platform_device *pdev,
> struct msm_gpu *gpu)
>
> /* Return a new address space for a msm_drm_private instance */
> struct msm_gem_address_space *
> -msm_gpu_create_private_address_space(struct msm_gpu *gpu)
> +msm_gpu_create_private_address_space(struct msm_gpu *gpu, struct task_struct
> *task)
> {
> struct msm_gem_address_space *aspace = NULL;
> -
> if (!gpu)
> return NULL;
>
> @@ -836,8 +835,11 @@ msm_gpu_create_private_address_space(struct msm_gpu *gpu)
>* If the target doesn't support private address spaces then return
>* the global one
>*/
> - if (gpu->funcs->create_priva
Re: [PATCH 04/11] block: Add bio_for_each_thp_segment_all
On Mon, Aug 31, 2020 at 08:48:37PM +0100, Matthew Wilcox wrote:
> static void iomap_read_end_io(struct bio *bio)
> {
> int i, error = blk_status_to_errno(bio->bi_status);
>
> for (i = 0; i < bio->bi_vcnt; i++) {
> struct bio_vec *bvec = &bio->bi_io_vec[i];
This should probably use bio_for_each_bvec_all instead of directly
poking into the bio. I'd also be tempted to move the loop body into
a separate helper, but that's just a slight stylistic preference.
> size_t offset = bvec->bv_offset;
> size_t length = bvec->bv_len;
> struct page *page = bvec->bv_page;
>
> while (length > 0) {
> size_t count = thp_size(page) - offset;
>
> if (count > length)
> count = length;
> iomap_read_page_end_io(page, offset, count, error);
> page += (offset + count) / PAGE_SIZE;
Shouldn't the page_size here be thp_size?
> Maybe I'm missing something important here, but it's significantly
> simpler code -- iomap_read_end_io() goes down from 816 bytes to 560 bytes
> (256 bytes less!) iomap_read_page_end_io is inlined into it both before
> and after.
Yes, that's exactly why I think avoiding bio_for_each_segment_all is
a good idea in general.
> There is some weirdness going on with regards to bv_offset that I don't
> quite understand. In the original bvec_advance:
>
> bv->bv_page = bvec->bv_page + (bvec->bv_offset >> PAGE_SHIFT);
> bv->bv_offset = bvec->bv_offset & ~PAGE_MASK;
>
> which I cargo-culted into bvec_thp_advance as:
>
> bv->bv_page = thp_head(bvec->bv_page +
> (bvec->bv_offset >> PAGE_SHIFT));
> page_size = thp_size(bv->bv_page);
> bv->bv_offset = bvec->bv_offset -
> (bv->bv_page - bvec->bv_page) * PAGE_SIZE;
>
> Is it possible to have a bvec with an offset that is larger than the
> size of bv_page? That doesn't seem like a useful thing to do, but
> if that needs to be supported, then the code up top doesn't do that.
> We maybe gain a little bit by counting length down to 0 instead of
> counting it up to bv_len. I dunno; reading the code over now, it
> doesn't seem like that much of a difference.
Drivers can absolutely see a bv_offset that is larger due to bio
splitting. However the submitting file system should never see one
unless it creates one, which would be stupid.
And yes, eventually bv_page and bv_offset should be replaced with a
phys_addr_t bv_phys;
and life would become simpler in many places (and the bvec would
shrink for most common setups as well).
For now I'd end up with something like:
static void iomap_read_end_bvec(struct page *page, size_t offset,
size_t length, int error)
{
while (length > 0) {
size_t page_size = thp_size(page);
size_t count = min(page_size - offset, length);
iomap_read_page_end_io(page, offset, count, error);
page += (offset + count) / page_size;
length -= count;
offset = 0;
}
}
static void iomap_read_end_io(struct bio *bio)
{
int i, error = blk_status_to_errno(bio->bi_status);
struct bio_vec *bvec;
bio_for_each_bvec_all(bvec, bio, i)
iomap_read_end_bvec(bvec->bv_page, bvec->bv_offset,
bvec->bv_len, error;
bio_put(bio);
}
and maybe even merge iomap_read_page_end_io into iomap_read_end_bvec.
Re: [PATCH 18/19] iommu/arm-smmu: add a way for implementations to influence SCTLR
On Thu 13 Aug 21:41 CDT 2020, Rob Clark wrote:
> From: Rob Clark
>
> For the Adreno GPU's SMMU, we want SCTLR.HUPCF set to ensure that
> pending translations are not terminated on iova fault. Otherwise
> a terminated CP read could hang the GPU by returning invalid
> command-stream data.
>
Reviewed-by: Bjorn Andersson
> Signed-off-by: Rob Clark
> ---
> drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 6 ++
> drivers/iommu/arm/arm-smmu/arm-smmu.c | 3 +++
> drivers/iommu/arm/arm-smmu/arm-smmu.h | 3 +++
> 3 files changed, 12 insertions(+)
>
> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
> b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
> index 5640d9960610..2aa6249050ff 100644
> --- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
> @@ -127,6 +127,12 @@ static int qcom_adreno_smmu_init_context(struct
> arm_smmu_domain *smmu_domain,
> (smmu_domain->cfg.fmt == ARM_SMMU_CTX_FMT_AARCH64))
> pgtbl_cfg->quirks |= IO_PGTABLE_QUIRK_ARM_TTBR1;
>
> + /*
> + * On the GPU device we want to process subsequent transactions after a
> + * fault to keep the GPU from hanging
> + */
> + smmu_domain->cfg.sctlr_set |= ARM_SMMU_SCTLR_HUPCF;
> +
> /*
>* Initialize private interface with GPU:
>*/
> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.c
> b/drivers/iommu/arm/arm-smmu/arm-smmu.c
> index e63a480d7f71..bbec5793faf8 100644
> --- a/drivers/iommu/arm/arm-smmu/arm-smmu.c
> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu.c
> @@ -617,6 +617,9 @@ void arm_smmu_write_context_bank(struct arm_smmu_device
> *smmu, int idx)
> if (IS_ENABLED(CONFIG_CPU_BIG_ENDIAN))
> reg |= ARM_SMMU_SCTLR_E;
>
> + reg |= cfg->sctlr_set;
> + reg &= ~cfg->sctlr_clr;
> +
> arm_smmu_cb_write(smmu, idx, ARM_SMMU_CB_SCTLR, reg);
> }
>
> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.h
> b/drivers/iommu/arm/arm-smmu/arm-smmu.h
> index cd75a33967bb..2df3a70a8a41 100644
> --- a/drivers/iommu/arm/arm-smmu/arm-smmu.h
> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu.h
> @@ -144,6 +144,7 @@ enum arm_smmu_cbar_type {
> #define ARM_SMMU_CB_SCTLR0x0
> #define ARM_SMMU_SCTLR_S1_ASIDPNEBIT(12)
> #define ARM_SMMU_SCTLR_CFCFG BIT(7)
> +#define ARM_SMMU_SCTLR_HUPCF BIT(8)
> #define ARM_SMMU_SCTLR_CFIE BIT(6)
> #define ARM_SMMU_SCTLR_CFRE BIT(5)
> #define ARM_SMMU_SCTLR_E BIT(4)
> @@ -341,6 +342,8 @@ struct arm_smmu_cfg {
> u16 asid;
> u16 vmid;
> };
> + u32 sctlr_set;/* extra bits to set in
> SCTLR */
> + u32 sctlr_clr;/* bits to mask in SCTLR
> */
> enum arm_smmu_cbar_type cbar;
> enum arm_smmu_context_fmt fmt;
> };
> --
> 2.26.2
>
Re: [PATCH] Documentation: kunit: Add naming guidelines
On Tue, Sep 1, 2020 at 7:47 AM Kees Cook wrote: > > On Fri, Aug 28, 2020 at 12:17:05AM +0800, David Gow wrote: > > On Thu, Aug 27, 2020 at 9:14 PM Marco Elver wrote: > > > Just an idea: Maybe the names are also an opportunity to distinguish > > > real _unit_ style tests and then the rarer integration-style tests. I > > > personally prefer using the more generic *-test.c, at least for the > > > integration-style tests I've been working on (KUnit is still incredibly > > > valuable for integration-style tests, because otherwise I'd have to roll > > > my own poor-man's version of KUnit, so thank you!). Using *_kunit.c for > > > such tests is unintuitive, because the word "unit" hints at "unit tests" > > > -- and having descriptive (and not misleading) filenames is still > > > important. So I hope you won't mind if *-test.c are still used where > > > appropriate. > > This is a good point, and I guess not one that has really been examined. > I'm not sure what to think of some of the lib/ tests. test_user_copy > seems to be a "unit" test -- it's validating the function family vs > all kinds of arguments and conditions. But test_overflow is less unit > and more integration, which includes "do all of these allocators end up > acting the same way?" etc > > I'm not really sure what to make of that -- I don't really have a formal > testing background. > I'm not sure we need a super-precise definition here (maybe just because I don't have one), and really just need to work out what distinctions are actually useful. For example, I'm not sure there's any real advantage to treating test_user_copy and test_overflow differently. The KCSAN tests which spawn lots of threads and are both slower and less deterministic seem more obviously different, though. I guess there are two audiences to cater for: 1. Test authors, who may wish to have both unit-style and integration-style tests, and want to distinguish them. They probably have the best idea of where the line should be drawn for their subsystems, and may have some existing style/nomenclature. 2. People running "all tests", who want to broadly understand how the whole suite of tests will behave (e.g., how long they'll take to run, are they possibly nondeterministic, are there weird hardware/software dependencies). This is where some more standardisation probably makes sense. I'm not 100% the file/module name is the best place to make these distinctions (given that it's the Kconfig entries that are at least our current way of finding and running tests). An off-the-wall idea would be to have a flags field in the test suite structure to note things like "large/long-running test" or "nondeterministic", and have either a KUnit option to bypass them, note them in the output, or even something terrifying like parsing it out of a compiled module. > > As Brendan alluded to in the talk, the popularity of KUnit for these > > integration-style tests came as something of a surprise (more due to > > our lack of imagination than anything else, I suspect). It's great > > that it's working, though: I don't think anyone wants the world filled > > with more single-use test "frameworks" than is necessary! > > > > I guess the interesting thing to note is that we've to date not really > > made a distinction between KUnit the framework and the suite of all > > KUnit tests. Maybe having a separate file/module naming scheme could > > be a way of making that distinction, though it'd really only appear > > when loading tests as modules -- there'd be no indication in e.g., > > suite names or test results. The more obvious solution to me (at > > least, based on the current proposal) would be to have "integration" > > or similar be part of the suite name (and hence the filename, so > > _integration_kunit.c or similar), though even I admit that that's much > > uglier. Maybe the idea of having the subsystem/suite distinction be > > represented in the code could pave the way to having different suites > > support different suffixes like that. > > Heh, yeah, let's not call them "_integration_kunit.c" ;) _behavior.c? > _integration.c? > I think we'd really like something that says more strongly that this is a test (which is I suspect one of the reasons why _kunit.c has its detractors: it doesn't have the word "test" in it). The other thing to consider is that if there are multiple tests for the same thing (e.g., a unit test suite and an integration test suite), they'd still need separate, non-conflicting suite names if we wanted them to be able to be present in the same kernel. Maybe the right thing to do is to say that, for now, the _kunit.c naming guideline only applies to "unit-style" tests. > > Do you know of any cases where something has/would have both > > unit-style tests and integration-style tests built with KUnit where > > the distinction needs to be clear? > > This is probably the right question. :) > I had a quick look, and we don't appear to have anything quite like this yet, at least wit
Re: [PATCH 15/19] drm/msm: Add support for private address space instances
On Thu 13 Aug 21:41 CDT 2020, Rob Clark wrote:
> From: Jordan Crouse
>
> Add support for allocating private address space instances. Targets that
> support per-context pagetables should implement their own function to
> allocate private address spaces.
>
> The default will return a pointer to the global address space.
>
Reviewed-by: Bjorn Andersson
> Signed-off-by: Jordan Crouse
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/msm/msm_drv.c | 13 +++--
> drivers/gpu/drm/msm/msm_drv.h | 5 +
> drivers/gpu/drm/msm/msm_gem_vma.c | 9 +
> drivers/gpu/drm/msm/msm_gpu.c | 22 ++
> drivers/gpu/drm/msm/msm_gpu.h | 5 +
> 5 files changed, 48 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
> index 01845a3b8d52..8e70d220bba8 100644
> --- a/drivers/gpu/drm/msm/msm_drv.c
> +++ b/drivers/gpu/drm/msm/msm_drv.c
> @@ -597,7 +597,7 @@ static int context_init(struct drm_device *dev, struct
> drm_file *file)
> kref_init(&ctx->ref);
> msm_submitqueue_init(dev, ctx);
>
> - ctx->aspace = priv->gpu ? priv->gpu->aspace : NULL;
> + ctx->aspace = msm_gpu_create_private_address_space(priv->gpu);
> file->driver_priv = ctx;
>
> return 0;
> @@ -780,18 +780,19 @@ static int msm_ioctl_gem_cpu_fini(struct drm_device
> *dev, void *data,
> }
>
> static int msm_ioctl_gem_info_iova(struct drm_device *dev,
> - struct drm_gem_object *obj, uint64_t *iova)
> + struct drm_file *file, struct drm_gem_object *obj,
> + uint64_t *iova)
> {
> - struct msm_drm_private *priv = dev->dev_private;
> + struct msm_file_private *ctx = file->driver_priv;
>
> - if (!priv->gpu)
> + if (!ctx->aspace)
> return -EINVAL;
>
> /*
>* Don't pin the memory here - just get an address so that userspace can
>* be productive
>*/
> - return msm_gem_get_iova(obj, priv->gpu->aspace, iova);
> + return msm_gem_get_iova(obj, ctx->aspace, iova);
> }
>
> static int msm_ioctl_gem_info(struct drm_device *dev, void *data,
> @@ -830,7 +831,7 @@ static int msm_ioctl_gem_info(struct drm_device *dev,
> void *data,
> args->value = msm_gem_mmap_offset(obj);
> break;
> case MSM_INFO_GET_IOVA:
> - ret = msm_ioctl_gem_info_iova(dev, obj, &args->value);
> + ret = msm_ioctl_gem_info_iova(dev, file, obj, &args->value);
> break;
> case MSM_INFO_SET_NAME:
> /* length check should leave room for terminating null: */
> diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
> index 4561bfb5e745..2ca9c3c03845 100644
> --- a/drivers/gpu/drm/msm/msm_drv.h
> +++ b/drivers/gpu/drm/msm/msm_drv.h
> @@ -249,6 +249,10 @@ int msm_gem_map_vma(struct msm_gem_address_space *aspace,
> void msm_gem_close_vma(struct msm_gem_address_space *aspace,
> struct msm_gem_vma *vma);
>
> +
> +struct msm_gem_address_space *
> +msm_gem_address_space_get(struct msm_gem_address_space *aspace);
> +
> void msm_gem_address_space_put(struct msm_gem_address_space *aspace);
>
> struct msm_gem_address_space *
> @@ -434,6 +438,7 @@ static inline void __msm_file_private_destroy(struct kref
> *kref)
> struct msm_file_private *ctx = container_of(kref,
> struct msm_file_private, ref);
>
> + msm_gem_address_space_put(ctx->aspace);
> kfree(ctx);
> }
>
> diff --git a/drivers/gpu/drm/msm/msm_gem_vma.c
> b/drivers/gpu/drm/msm/msm_gem_vma.c
> index 5f6a11211b64..29cc1305cf37 100644
> --- a/drivers/gpu/drm/msm/msm_gem_vma.c
> +++ b/drivers/gpu/drm/msm/msm_gem_vma.c
> @@ -27,6 +27,15 @@ void msm_gem_address_space_put(struct
> msm_gem_address_space *aspace)
> kref_put(&aspace->kref, msm_gem_address_space_destroy);
> }
>
> +struct msm_gem_address_space *
> +msm_gem_address_space_get(struct msm_gem_address_space *aspace)
> +{
> + if (!IS_ERR_OR_NULL(aspace))
> + kref_get(&aspace->kref);
> +
> + return aspace;
> +}
> +
> /* Actually unmap memory for the vma */
> void msm_gem_purge_vma(struct msm_gem_address_space *aspace,
> struct msm_gem_vma *vma)
> diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
> index e1a3cbe25a0c..951850804d77 100644
> --- a/drivers/gpu/drm/msm/msm_gpu.c
> +++ b/drivers/gpu/drm/msm/msm_gpu.c
> @@ -823,6 +823,28 @@ static int get_clocks(struct platform_device *pdev,
> struct msm_gpu *gpu)
> return 0;
> }
>
> +/* Return a new address space for a msm_drm_private instance */
> +struct msm_gem_address_space *
> +msm_gpu_create_private_address_space(struct msm_gpu *gpu)
> +{
> + struct msm_gem_address_space *aspace = NULL;
> +
> + if (!gpu)
> + return NULL;
> +
> + /*
> + * If the target doesn't support private address spaces then return
> + * the global one
> +
[PATCH v11] Fixup for "powerpc/vdso: Provide __kernel_clock_gettime64() on vdso32"
Signed-off-by: Christophe Leroy --- arch/powerpc/include/asm/vdso/gettimeofday.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/powerpc/include/asm/vdso/gettimeofday.h b/arch/powerpc/include/asm/vdso/gettimeofday.h index 59a609a48b63..8da84722729b 100644 --- a/arch/powerpc/include/asm/vdso/gettimeofday.h +++ b/arch/powerpc/include/asm/vdso/gettimeofday.h @@ -186,6 +186,8 @@ int __c_kernel_clock_getres(clockid_t clock_id, struct __kernel_timespec *res, #else int __c_kernel_clock_gettime(clockid_t clock, struct old_timespec32 *ts, const struct vdso_data *vd); +int __c_kernel_clock_gettime64(clockid_t clock, struct __kernel_timespec *ts, + const struct vdso_data *vd); int __c_kernel_clock_getres(clockid_t clock_id, struct old_timespec32 *res, const struct vdso_data *vd); #endif -- 2.25.0
Re: [PATCH 14/19] drm/msm: Add support to create a local pagetable
On Thu 13 Aug 21:41 CDT 2020, Rob Clark wrote:
> From: Jordan Crouse
>
> Add support to create a io-pgtable for use by targets that support
> per-instance pagetables. In order to support per-instance pagetables the
> GPU SMMU device needs to have the qcom,adreno-smmu compatible string and
> split pagetables enabled.
>
Reviewed-by: Bjorn Andersson
> Signed-off-by: Jordan Crouse
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/msm/msm_gpummu.c | 2 +-
> drivers/gpu/drm/msm/msm_iommu.c | 199 ++-
> drivers/gpu/drm/msm/msm_mmu.h| 16 ++-
> 3 files changed, 214 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/msm_gpummu.c
> b/drivers/gpu/drm/msm/msm_gpummu.c
> index 310a31b05faa..aab121f4beb7 100644
> --- a/drivers/gpu/drm/msm/msm_gpummu.c
> +++ b/drivers/gpu/drm/msm/msm_gpummu.c
> @@ -102,7 +102,7 @@ struct msm_mmu *msm_gpummu_new(struct device *dev, struct
> msm_gpu *gpu)
> }
>
> gpummu->gpu = gpu;
> - msm_mmu_init(&gpummu->base, dev, &funcs);
> + msm_mmu_init(&gpummu->base, dev, &funcs, MSM_MMU_GPUMMU);
>
> return &gpummu->base;
> }
> diff --git a/drivers/gpu/drm/msm/msm_iommu.c b/drivers/gpu/drm/msm/msm_iommu.c
> index 1b6635504069..697cc0a059d6 100644
> --- a/drivers/gpu/drm/msm/msm_iommu.c
> +++ b/drivers/gpu/drm/msm/msm_iommu.c
> @@ -4,15 +4,210 @@
> * Author: Rob Clark
> */
>
> +#include
> +#include
> #include "msm_drv.h"
> #include "msm_mmu.h"
>
> struct msm_iommu {
> struct msm_mmu base;
> struct iommu_domain *domain;
> + atomic_t pagetables;
> };
> +
> #define to_msm_iommu(x) container_of(x, struct msm_iommu, base)
>
> +struct msm_iommu_pagetable {
> + struct msm_mmu base;
> + struct msm_mmu *parent;
> + struct io_pgtable_ops *pgtbl_ops;
> + phys_addr_t ttbr;
> + u32 asid;
> +};
> +static struct msm_iommu_pagetable *to_pagetable(struct msm_mmu *mmu)
> +{
> + return container_of(mmu, struct msm_iommu_pagetable, base);
> +}
> +
> +static int msm_iommu_pagetable_unmap(struct msm_mmu *mmu, u64 iova,
> + size_t size)
> +{
> + struct msm_iommu_pagetable *pagetable = to_pagetable(mmu);
> + struct io_pgtable_ops *ops = pagetable->pgtbl_ops;
> + size_t unmapped = 0;
> +
> + /* Unmap the block one page at a time */
> + while (size) {
> + unmapped += ops->unmap(ops, iova, 4096, NULL);
> + iova += 4096;
> + size -= 4096;
> + }
> +
> + iommu_flush_tlb_all(to_msm_iommu(pagetable->parent)->domain);
> +
> + return (unmapped == size) ? 0 : -EINVAL;
> +}
> +
> +static int msm_iommu_pagetable_map(struct msm_mmu *mmu, u64 iova,
> + struct sg_table *sgt, size_t len, int prot)
> +{
> + struct msm_iommu_pagetable *pagetable = to_pagetable(mmu);
> + struct io_pgtable_ops *ops = pagetable->pgtbl_ops;
> + struct scatterlist *sg;
> + size_t mapped = 0;
> + u64 addr = iova;
> + unsigned int i;
> +
> + for_each_sg(sgt->sgl, sg, sgt->nents, i) {
> + size_t size = sg->length;
> + phys_addr_t phys = sg_phys(sg);
> +
> + /* Map the block one page at a time */
> + while (size) {
> + if (ops->map(ops, addr, phys, 4096, prot, GFP_KERNEL)) {
> + msm_iommu_pagetable_unmap(mmu, iova, mapped);
> + return -EINVAL;
> + }
> +
> + phys += 4096;
> + addr += 4096;
> + size -= 4096;
> + mapped += 4096;
> + }
> + }
> +
> + return 0;
> +}
> +
> +static void msm_iommu_pagetable_destroy(struct msm_mmu *mmu)
> +{
> + struct msm_iommu_pagetable *pagetable = to_pagetable(mmu);
> + struct msm_iommu *iommu = to_msm_iommu(pagetable->parent);
> + struct adreno_smmu_priv *adreno_smmu =
> + dev_get_drvdata(pagetable->parent->dev);
> +
> + /*
> + * If this is the last attached pagetable for the parent,
> + * disable TTBR0 in the arm-smmu driver
> + */
> + if (atomic_dec_return(&iommu->pagetables) == 0)
> + adreno_smmu->set_ttbr0_cfg(adreno_smmu->cookie, NULL);
> +
> + free_io_pgtable_ops(pagetable->pgtbl_ops);
> + kfree(pagetable);
> +}
> +
> +int msm_iommu_pagetable_params(struct msm_mmu *mmu,
> + phys_addr_t *ttbr, int *asid)
> +{
> + struct msm_iommu_pagetable *pagetable;
> +
> + if (mmu->type != MSM_MMU_IOMMU_PAGETABLE)
> + return -EINVAL;
> +
> + pagetable = to_pagetable(mmu);
> +
> + if (ttbr)
> + *ttbr = pagetable->ttbr;
> +
> + if (asid)
> + *asid = pagetable->asid;
> +
> + return 0;
> +}
> +
> +static const struct msm_mmu_funcs pagetable_funcs = {
> + .map = msm_iommu_pagetable_map,
> + .unmap = msm_iommu_pagetable_unmap,
> + .destroy = msm_iommu_pagetable_destroy,
>
Re: [PATCH v2 00/28] The new cgroup slab memory controller
On Fri, Aug 28, 2020 at 12:47:03PM -0400, Pavel Tatashin wrote:
> There appears to be another problem that is related to the
> cgroup_mutex -> mem_hotplug_lock deadlock described above.
>
> In the original deadlock that I described, the workaround is to
> replace crash dump from piping to Linux traditional save to files
> method. However, after trying this workaround, I still observed
> hardware watchdog resets during machine shutdown.
>
> The new problem occurs for the following reason: upon shutdown systemd
> calls a service that hot-removes memory, and if hot-removing fails for
> some reason systemd kills that service after timeout. However, systemd
> is never able to kill the service, and we get hardware reset caused by
> watchdog or a hang during shutdown:
>
> Thread #1: memory hot-remove systemd service
> Loops indefinitely, because if there is something still to be migrated
> this loop never terminates. However, this loop can be terminated via
> signal from systemd after timeout.
> __offline_pages()
> do {
> pfn = scan_movable_pages(pfn, end_pfn);
> # Returns 0, meaning there is nothing available to
> # migrate, no page is PageLRU(page)
> ...
> ret = walk_system_ram_range(start_pfn, end_pfn - start_pfn,
> NULL, check_pages_isolated_cb);
> # Returns -EBUSY, meaning there is at least one PFN that
> # still has to be migrated.
> } while (ret);
>
> Thread #2: ccs killer kthread
>css_killed_work_fn
> cgroup_mutex <- Grab this Mutex
> mem_cgroup_css_offline
>memcg_offline_kmem.part
> memcg_deactivate_kmem_caches
> get_online_mems
> mem_hotplug_lock <- waits for Thread#1 to get read access
>
> Thread #3: systemd
> ksys_read
> vfs_read
>__vfs_read
> seq_read
>proc_single_show
> proc_cgroup_show
>mutex_lock -> wait for cgroup_mutex that is owned by Thread #2
>
> Thus, thread #3 systemd stuck, and unable to deliver timeout interrupt
> to thread #1.
>
> The proper fix for both of the problems is to avoid cgroup_mutex ->
> mem_hotplug_lock ordering that was recently fixed in the mainline but
> still present in all stable branches. Unfortunately, I do not see a
> simple fix in how to remove mem_hotplug_lock from
> memcg_deactivate_kmem_caches without using Roman's series that is too
> big for stable.
We too are seeing this on Power systems when stress-testing memory
hotplug, but with the following call trace (from hung task timer)
instead of Thread #2 above:
__switch_to
__schedule
schedule
percpu_rwsem_wait
__percpu_down_read
get_online_mems
memcg_create_kmem_cache
memcg_kmem_cache_create_func
process_one_work
worker_thread
kthread
ret_from_kernel_thread
While I understand that Roman's new slab controller patchset will fix
this, I also wonder if infinitely looping in the memory unplug path
with mem_hotplug_lock held is the right thing to do? Earlier we had
a few other exit possibilities in this path (like max retries etc)
but those were removed by commits:
72b39cfc4d75: mm, memory_hotplug: do not fail offlining too early
ecde0f3e7f9e: mm, memory_hotplug: remove timeout from __offline_memory
Or, is the user-space test is expected to induce a signal back-off when
unplug doesn't complete within a reasonable amount of time?
Regards,
Bharata.
Re: [PATCH] Documentation/x86/boot.rst: minor improvement
Sorry, I mis-copied 2 addresses. make sure they are CCed. On 9/1/20 11:41 AM, Cao jin wrote: > Typo fix & file name update > > Signed-off-by: Cao jin > --- > Documentation/x86/boot.rst | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/Documentation/x86/boot.rst b/Documentation/x86/boot.rst > index 7fafc7ac00d7..c04afec90486 100644 > --- a/Documentation/x86/boot.rst > +++ b/Documentation/x86/boot.rst > @@ -1379,7 +1379,7 @@ can be calculated as follows:: > In addition to read/modify/write the setup header of the struct > boot_params as that of 16-bit boot protocol, the boot loader should > also fill the additional fields of the struct boot_params as described > -in zero-page.txt. > +in zero-page.rst. > > After setting up the struct boot_params, the boot loader can load > 64-bit kernel in the same way as that of 16-bit boot protocol, but > @@ -1391,7 +1391,7 @@ In 64-bit boot protocol, the kernel is started by > jumping to the > > At entry, the CPU must be in 64-bit mode with paging enabled. > The range with setup_header.init_size from start address of loaded > -kernel and zero page and command line buffer get ident mapping; > +kernel and zero page and command line buffer get identity mapping; > a GDT must be loaded with the descriptors for selectors > __BOOT_CS(0x10) and __BOOT_DS(0x18); both descriptors must be 4G flat > segment; __BOOT_CS must have execute/read permission, and __BOOT_DS > -- Sincerely, Cao jin
Re: [RFC PATCH 00/22] Enhance VHOST to enable SoC-to-SoC communication
Hi, On 28/08/20 4:04 pm, Cornelia Huck wrote: On Thu, 9 Jul 2020 14:26:53 +0800 Jason Wang wrote: [Let me note right at the beginning that I first noted this while listening to Kishon's talk at LPC on Wednesday. I might be very confused about the background here, so let me apologize beforehand for any confusion I might spread.] On 2020/7/8 下午9:13, Kishon Vijay Abraham I wrote: Hi Jason, On 7/8/2020 4:52 PM, Jason Wang wrote: On 2020/7/7 下午10:45, Kishon Vijay Abraham I wrote: Hi Jason, On 7/7/2020 3:17 PM, Jason Wang wrote: On 2020/7/6 下午5:32, Kishon Vijay Abraham I wrote: Hi Jason, On 7/3/2020 12:46 PM, Jason Wang wrote: On 2020/7/2 下午9:35, Kishon Vijay Abraham I wrote: Hi Jason, On 7/2/2020 3:40 PM, Jason Wang wrote: On 2020/7/2 下午5:51, Michael S. Tsirkin wrote: On Thu, Jul 02, 2020 at 01:51:21PM +0530, Kishon Vijay Abraham I wrote: This series enhances Linux Vhost support to enable SoC-to-SoC communication over MMIO. This series enables rpmsg communication between two SoCs using both PCIe RC<->EP and HOST1-NTB-HOST2 1) Modify vhost to use standard Linux driver model 2) Add support in vring to access virtqueue over MMIO 3) Add vhost client driver for rpmsg 4) Add PCIe RC driver (uses virtio) and PCIe EP driver (uses vhost) for rpmsg communication between two SoCs connected to each other 5) Add NTB Virtio driver and NTB Vhost driver for rpmsg communication between two SoCs connected via NTB 6) Add configfs to configure the components UseCase1 : VHOST RPMSG VIRTIO RPMSG + + | | | | | | | | +-v--+ +--v---+ | Linux | | Linux | | Endpoint | | Root Complex | | <-> | | | | | | SOC1 | | SOC2 | ++ +--+ UseCase 2: VHOST RPMSG VIRTIO RPMSG + + | | | | | | | | +--v--+ +--v--+ | | | | | HOST1 | | HOST2 | | | | | +--^--+ +--^--+ | | | | +-+ | +--v--+ +--v--+ | | | | | | | | | EP | | EP | | | | CONTROLLER1 | | CONTROLLER2 | | | | <---> | | | | | | | | | | | | | | | | | SoC With Multiple EP Instances | | | | | | (Configured using NTB Function) | | | | +-+ +-+ | +-+ First of all, to clarify the terminology: Is "vhost rpmsg" acting as what the virtio standard calls the 'device', and "virtio rpmsg" as the 'driver'? Or is the "vhost" part mostly just Right, vhost_rpmsg is 'device' and virtio_rpmsg is 'driver'. virtqueues + the exiting vhost interfaces? It's implemented to provide the full 'device' functionality. Software Layering: The high-level SW layering should look something like below. This series adds support only for RPMSG VHOST, however something similar should be done for net and scsi. With that any vhost device (PCI, NTB, Platform device, user) can use any of the vhost client driver. ++ +---+ ++ +--+ | RPMSG VHOST | | NET VHOST | | SCSI VHOST | | X | +---^+ +-^-+ +-^--+ +^-+ | | | | | | | | | | |
Re: [PATCH 13/19] drm/msm: Set the global virtual address range from the IOMMU domain
On Thu 13 Aug 21:41 CDT 2020, Rob Clark wrote:
> From: Jordan Crouse
>
> Use the aperture settings from the IOMMU domain to set up the virtual
> address range for the GPU. This allows us to transparently deal with
> IOMMU side features (like split pagetables).
>
Reviewed-by: Bjorn Andersson
> Signed-off-by: Jordan Crouse
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/msm/adreno/adreno_gpu.c | 13 +++--
> drivers/gpu/drm/msm/msm_iommu.c | 7 +++
> 2 files changed, 18 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> index 533a34b4cce2..34e6242c1767 100644
> --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> @@ -192,9 +192,18 @@ adreno_iommu_create_address_space(struct msm_gpu *gpu,
> struct iommu_domain *iommu = iommu_domain_alloc(&platform_bus_type);
> struct msm_mmu *mmu = msm_iommu_new(&pdev->dev, iommu);
> struct msm_gem_address_space *aspace;
> + u64 start, size;
>
> - aspace = msm_gem_address_space_create(mmu, "gpu", SZ_16M,
> - 0x - SZ_16M);
> + /*
> + * Use the aperture start or SZ_16M, whichever is greater. This will
> + * ensure that we align with the allocated pagetable range while still
> + * allowing room in the lower 32 bits for GMEM and whatnot
> + */
> + start = max_t(u64, SZ_16M, iommu->geometry.aperture_start);
> + size = iommu->geometry.aperture_end - start + 1;
> +
> + aspace = msm_gem_address_space_create(mmu, "gpu",
> + start & GENMASK(48, 0), size);
>
> if (IS_ERR(aspace) && !IS_ERR(mmu))
> mmu->funcs->destroy(mmu);
> diff --git a/drivers/gpu/drm/msm/msm_iommu.c b/drivers/gpu/drm/msm/msm_iommu.c
> index 3a381a9674c9..1b6635504069 100644
> --- a/drivers/gpu/drm/msm/msm_iommu.c
> +++ b/drivers/gpu/drm/msm/msm_iommu.c
> @@ -36,6 +36,10 @@ static int msm_iommu_map(struct msm_mmu *mmu, uint64_t
> iova,
> struct msm_iommu *iommu = to_msm_iommu(mmu);
> size_t ret;
>
> + /* The arm-smmu driver expects the addresses to be sign extended */
> + if (iova & BIT_ULL(48))
> + iova |= GENMASK_ULL(63, 49);
> +
> ret = iommu_map_sg(iommu->domain, iova, sgt->sgl, sgt->nents, prot);
> WARN_ON(!ret);
>
> @@ -46,6 +50,9 @@ static int msm_iommu_unmap(struct msm_mmu *mmu, uint64_t
> iova, size_t len)
> {
> struct msm_iommu *iommu = to_msm_iommu(mmu);
>
> + if (iova & BIT_ULL(48))
> + iova |= GENMASK_ULL(63, 49);
> +
> iommu_unmap(iommu->domain, iova, len);
>
> return 0;
> --
> 2.26.2
>
Re: [PATCH v4] iomap: fix WARN_ON_ONCE() from unprivileged users
On Mon, Aug 31, 2020 at 02:23:53PM -0400, Qian Cai wrote: > It is trivial to trigger a WARN_ON_ONCE(1) in iomap_dio_actor() by > unprivileged users which would taint the kernel, or worse - panic if > panic_on_warn or panic_on_taint is set. Hence, just convert it to > pr_warn_ratelimited() to let users know their workloads are racing. > Thank Dave Chinner for the initial analysis of the racing reproducers. > > Signed-off-by: Qian Cai Looks good, Reviewed-by: Christoph Hellwig
Re: [PATCH 2/2] mm/migrate: preserve soft dirty in remove_migration_pte()
On Mon, Aug 31, 2020 at 02:22:22PM -0700, Ralph Campbell wrote: > The code to remove a migration PTE and replace it with a device private > PTE was not copying the soft dirty bit from the migration entry. > This could lead to page contents not being marked dirty when faulting > the page back from device private memory. > > Signed-off-by: Ralph Campbell Looks good, Reviewed-by: Christoph Hellwig
Re: [PATCH 1/2] mm/migrate: remove unnecessary is_zone_device_page() check
Looks good: Reviewed-by: Christoph Hellwig
Re: [PATCH v3 09/10] fs/ntfs3: Add NTFS3 in fs/Kconfig and fs/Makefile
Hi Konstantin, Thank you for the patch! Yet something to improve: [auto build test ERROR on linus/master] [also build test ERROR on v5.9-rc3 next-20200828] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/0day-ci/linux/commits/Konstantin-Komarov/NTFS-read-write-driver-GPL-implementation-by-Paragon-Software/20200828-224323 base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 15bc20c6af4ceee97a1f90b43c0e386643c071b4 config: powerpc-allyesconfig (attached as .config) compiler: powerpc64-linux-gcc (GCC) 9.3.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=powerpc If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): >> powerpc64-linux-ld: fs/ntfs3/file.o:(.opd+0x1f8): multiple definition of >> `ntfs_setattr'; fs/ntfs/inode.o:(.opd+0x1b0): first defined here powerpc64-linux-ld: fs/ntfs3/file.o: in function `.ntfs_setattr': >> file.c:(.text.ntfs_setattr+0x0): multiple definition of `.ntfs_setattr'; >> fs/ntfs/inode.o:inode.c:(.text.ntfs_setattr+0x0): first defined here --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip
Re: [RFC PATCH v7 08/23] sched: Add core wide task selection and scheduling.
On Sat, Aug 29, 2020 at 09:47:19AM +0200, pet...@infradead.org wrote:
> On Fri, Aug 28, 2020 at 06:02:25PM -0400, Vineeth Pillai wrote:
> > On 8/28/20 4:51 PM, Peter Zijlstra wrote:
>
> > > So where do things go side-ways?
>
> > During hotplug stress test, we have noticed that while a sibling is in
> > pick_next_task, another sibling can go offline or come online. What
> > we have observed is smt_mask get updated underneath us even if
> > we hold the lock. From reading the code, looks like we don't hold the
> > rq lock when the mask is updated. This extra logic was to take care of that.
>
> Sure, the mask is updated async, but _where_ is the actual problem with
> that?
Hi Peter,
I tried again and came up with the simple patch below which handles all
issues and does not cause any more crashes. I added elaborate commit messages
and code comments enlisting all the issues. Hope it makes sense now. IMHO any
other solutions seems unclear or overhead. The simple solution below Just
Works (Tm) and does not add overhead.
Let me know what you think, thanks.
---8<---
>From 546c5b48f372111589117f51fd79ac1e9493c7e7 Mon Sep 17 00:00:00 2001
From: "Joel Fernandes (Google)"
Date: Tue, 1 Sep 2020 00:56:36 -0400
Subject: [PATCH] sched/core: Hotplug fixes to pick_next_task()
The follow 3 cases need to be handled to avoid crashes in pick_next_task() when
CPUs in a core are going offline or coming online.
1. The stopper task is switching into idle when it is brought down by CPU
hotplug. It is not in the cpu_smt_mask so nothing need be selected for it.
Further, the current code ends up not selecting anything for it, not even idle.
This ends up causing crashes in set_next_task(). Just do the __pick_next_task()
selection which will select the idle task. No need to do core-wide selection as
other siblings will handle it for themselves when they call schedule.
2. The rq->core_pick for a sibling in a core can be NULL if no selection was
made for it because it was either offline or went offline during a sibling's
core-wide selection. In this case, do a core-wide selection. In this case, we
have to completely ignore the checks:
if (rq->core->core_pick_seq == rq->core->core_task_seq &&
rq->core->core_pick_seq != rq->core_sched_seq)
Otherwise, it would again end up crashing like #1.
3. The 'Rescheduling siblings' loop of pick_next_task() is quite fragile. It
calls various functions on rq->core_pick which could very well be NULL because:
An online sibling might have gone offline before a task could be picked for it,
or it might be offline but later happen to come online, but its too late and
nothing was picked for it. Just ignore the siblings for which nothing could be
picked. This avoids any crashes that may occur in this loop that assume
rq->core_pick is not NULL.
Signed-off-by: Joel Fernandes (Google)
---
kernel/sched/core.c | 24 +---
1 file changed, 21 insertions(+), 3 deletions(-)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 717122a3dca1..4966e9f14f39 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -4610,13 +4610,24 @@ pick_next_task(struct rq *rq, struct task_struct *prev,
struct rq_flags *rf)
if (!sched_core_enabled(rq))
return __pick_next_task(rq, prev, rf);
+ cpu = cpu_of(rq);
+
+ /* Stopper task is switching into idle, no need core-wide selection. */
+ if (cpu_is_offline(cpu))
+ return __pick_next_task(rq, prev, rf);
+
/*
* If there were no {en,de}queues since we picked (IOW, the task
* pointers are all still valid), and we haven't scheduled the last
* pick yet, do so now.
+*
+* rq->core_pick can be NULL if no selection was made for a CPU because
+* it was either offline or went offline during a sibling's core-wide
+* selection. In this case, do a core-wide selection.
*/
if (rq->core->core_pick_seq == rq->core->core_task_seq &&
- rq->core->core_pick_seq != rq->core_sched_seq) {
+ rq->core->core_pick_seq != rq->core_sched_seq &&
+ !rq->core_pick) {
WRITE_ONCE(rq->core_sched_seq, rq->core->core_pick_seq);
next = rq->core_pick;
@@ -4629,7 +4640,6 @@ pick_next_task(struct rq *rq, struct task_struct *prev,
struct rq_flags *rf)
put_prev_task_balance(rq, prev, rf);
- cpu = cpu_of(rq);
smt_mask = cpu_smt_mask(cpu);
/*
@@ -4761,7 +4771,15 @@ next_class:;
for_each_cpu(i, smt_mask) {
struct rq *rq_i = cpu_rq(i);
- WARN_ON_ONCE(!rq_i->core_pick);
+ /*
+* An online sibling might have gone offline before a task
+* could be picked for it, or it might be offline but later
+* happen to come online, but its too late and nothing was
+* picked for it. That's Ok - it will pick tasks fo
Re: [PATCH 12/19] drm/msm: Drop context arg to gpu->submit()
On Thu 13 Aug 21:41 CDT 2020, Rob Clark wrote:
> From: Jordan Crouse
>
> Now that we can get the ctx from the submitqueue, the extra arg is
> redundant.
>
Reviewed-by: Bjorn Andersson
> Signed-off-by: Jordan Crouse
> [split out of previous patch to reduce churny noise]
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 12 +---
> drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 5 ++---
> drivers/gpu/drm/msm/adreno/adreno_gpu.c | 5 ++---
> drivers/gpu/drm/msm/adreno/adreno_gpu.h | 3 +--
> drivers/gpu/drm/msm/msm_gem_submit.c| 2 +-
> drivers/gpu/drm/msm/msm_gpu.c | 9 -
> drivers/gpu/drm/msm/msm_gpu.h | 6 ++
> 7 files changed, 17 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> index 9e63a190642c..eff2439ea57b 100644
> --- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> @@ -43,8 +43,7 @@ static void a5xx_flush(struct msm_gpu *gpu, struct
> msm_ringbuffer *ring)
> gpu_write(gpu, REG_A5XX_CP_RB_WPTR, wptr);
> }
>
> -static void a5xx_submit_in_rb(struct msm_gpu *gpu, struct msm_gem_submit
> *submit,
> - struct msm_file_private *ctx)
> +static void a5xx_submit_in_rb(struct msm_gpu *gpu, struct msm_gem_submit
> *submit)
> {
> struct msm_drm_private *priv = gpu->dev->dev_private;
> struct msm_ringbuffer *ring = submit->ring;
> @@ -57,7 +56,7 @@ static void a5xx_submit_in_rb(struct msm_gpu *gpu, struct
> msm_gem_submit *submit
> case MSM_SUBMIT_CMD_IB_TARGET_BUF:
> break;
> case MSM_SUBMIT_CMD_CTX_RESTORE_BUF:
> - if (priv->lastctx == ctx)
> + if (priv->lastctx == submit->queue->ctx)
> break;
> /* fall-thru */
> case MSM_SUBMIT_CMD_BUF:
> @@ -103,8 +102,7 @@ static void a5xx_submit_in_rb(struct msm_gpu *gpu, struct
> msm_gem_submit *submit
> msm_gpu_retire(gpu);
> }
>
> -static void a5xx_submit(struct msm_gpu *gpu, struct msm_gem_submit *submit,
> - struct msm_file_private *ctx)
> +static void a5xx_submit(struct msm_gpu *gpu, struct msm_gem_submit *submit)
> {
> struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
> struct a5xx_gpu *a5xx_gpu = to_a5xx_gpu(adreno_gpu);
> @@ -114,7 +112,7 @@ static void a5xx_submit(struct msm_gpu *gpu, struct
> msm_gem_submit *submit,
>
> if (IS_ENABLED(CONFIG_DRM_MSM_GPU_SUDO) && submit->in_rb) {
> priv->lastctx = NULL;
> - a5xx_submit_in_rb(gpu, submit, ctx);
> + a5xx_submit_in_rb(gpu, submit);
> return;
> }
>
> @@ -148,7 +146,7 @@ static void a5xx_submit(struct msm_gpu *gpu, struct
> msm_gem_submit *submit,
> case MSM_SUBMIT_CMD_IB_TARGET_BUF:
> break;
> case MSM_SUBMIT_CMD_CTX_RESTORE_BUF:
> - if (priv->lastctx == ctx)
> + if (priv->lastctx == submit->queue->ctx)
> break;
> /* fall-thru */
> case MSM_SUBMIT_CMD_BUF:
> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> index c5a3e4d4c007..5eabb0109577 100644
> --- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> @@ -81,8 +81,7 @@ static void get_stats_counter(struct msm_ringbuffer *ring,
> u32 counter,
> OUT_RING(ring, upper_32_bits(iova));
> }
>
> -static void a6xx_submit(struct msm_gpu *gpu, struct msm_gem_submit *submit,
> - struct msm_file_private *ctx)
> +static void a6xx_submit(struct msm_gpu *gpu, struct msm_gem_submit *submit)
> {
> unsigned int index = submit->seqno % MSM_GPU_SUBMIT_STATS_COUNT;
> struct msm_drm_private *priv = gpu->dev->dev_private;
> @@ -115,7 +114,7 @@ static void a6xx_submit(struct msm_gpu *gpu, struct
> msm_gem_submit *submit,
> case MSM_SUBMIT_CMD_IB_TARGET_BUF:
> break;
> case MSM_SUBMIT_CMD_CTX_RESTORE_BUF:
> - if (priv->lastctx == ctx)
> + if (priv->lastctx == submit->queue->ctx)
> break;
> /* fall-thru */
> case MSM_SUBMIT_CMD_BUF:
> diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> index d2dbb6968cba..533a34b4cce2 100644
> --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> @@ -457,8 +457,7 @@ void adreno_recover(struct msm_gpu *gpu)
> }
> }
>
> -void adreno_submit(struct msm_gpu *gpu, struct msm_gem_submit *submit,
> - struct msm_file_private *ctx)
> +void adreno_submit(struct msm_gpu *gpu, struct msm_gem_submit *submit)
> {
> struct adreno_gpu *adreno_gpu = to_adreno_gp
Re: [PATCH 11/19] drm/msm: Add a context pointer to the submitqueue
On Thu 13 Aug 21:41 CDT 2020, Rob Clark wrote:
> From: Jordan Crouse
>
> Each submitqueue is attached to a context. Add a pointer to the
> context to the submitqueue at create time and refcount it so
> that it stays around through the life of the queue.
>
Reviewed-by: Bjorn Andersson
> Co-developed-by: Rob Clark
> Signed-off-by: Jordan Crouse
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/msm/msm_drv.c | 3 ++-
> drivers/gpu/drm/msm/msm_drv.h | 20
> drivers/gpu/drm/msm/msm_gem.h | 1 +
> drivers/gpu/drm/msm/msm_gem_submit.c | 6 +++---
> drivers/gpu/drm/msm/msm_gpu.h | 1 +
> drivers/gpu/drm/msm/msm_submitqueue.c | 3 +++
> 6 files changed, 30 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
> index 7d641c7e3514..01845a3b8d52 100644
> --- a/drivers/gpu/drm/msm/msm_drv.c
> +++ b/drivers/gpu/drm/msm/msm_drv.c
> @@ -594,6 +594,7 @@ static int context_init(struct drm_device *dev, struct
> drm_file *file)
> if (!ctx)
> return -ENOMEM;
>
> + kref_init(&ctx->ref);
> msm_submitqueue_init(dev, ctx);
>
> ctx->aspace = priv->gpu ? priv->gpu->aspace : NULL;
> @@ -615,7 +616,7 @@ static int msm_open(struct drm_device *dev, struct
> drm_file *file)
> static void context_close(struct msm_file_private *ctx)
> {
> msm_submitqueue_close(ctx);
> - kfree(ctx);
> + msm_file_private_put(ctx);
> }
>
> static void msm_postclose(struct drm_device *dev, struct drm_file *file)
> diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
> index af259b0573ea..4561bfb5e745 100644
> --- a/drivers/gpu/drm/msm/msm_drv.h
> +++ b/drivers/gpu/drm/msm/msm_drv.h
> @@ -57,6 +57,7 @@ struct msm_file_private {
> struct list_head submitqueues;
> int queueid;
> struct msm_gem_address_space *aspace;
> + struct kref ref;
> };
>
> enum msm_mdp_plane_property {
> @@ -428,6 +429,25 @@ void msm_submitqueue_close(struct msm_file_private *ctx);
>
> void msm_submitqueue_destroy(struct kref *kref);
>
> +static inline void __msm_file_private_destroy(struct kref *kref)
> +{
> + struct msm_file_private *ctx = container_of(kref,
> + struct msm_file_private, ref);
> +
> + kfree(ctx);
> +}
> +
> +static inline void msm_file_private_put(struct msm_file_private *ctx)
> +{
> + kref_put(&ctx->ref, __msm_file_private_destroy);
> +}
> +
> +static inline struct msm_file_private *msm_file_private_get(
> + struct msm_file_private *ctx)
> +{
> + kref_get(&ctx->ref);
> + return ctx;
> +}
>
> #define DBG(fmt, ...) DRM_DEBUG_DRIVER(fmt"\n", ##__VA_ARGS__)
> #define VERB(fmt, ...) if (0) DRM_DEBUG_DRIVER(fmt"\n", ##__VA_ARGS__)
> diff --git a/drivers/gpu/drm/msm/msm_gem.h b/drivers/gpu/drm/msm/msm_gem.h
> index 972490b14ba5..9c573c4269cb 100644
> --- a/drivers/gpu/drm/msm/msm_gem.h
> +++ b/drivers/gpu/drm/msm/msm_gem.h
> @@ -142,6 +142,7 @@ struct msm_gem_submit {
> bool valid; /* true if no cmdstream patching needed */
> bool in_rb; /* "sudo" mode, copy cmds into RB */
> struct msm_ringbuffer *ring;
> + struct msm_file_private *ctx;
> unsigned int nr_cmds;
> unsigned int nr_bos;
> u32 ident; /* A "identifier" for the submit for logging */
> diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c
> b/drivers/gpu/drm/msm/msm_gem_submit.c
> index 8cb9aa15ff90..1464b04d25d3 100644
> --- a/drivers/gpu/drm/msm/msm_gem_submit.c
> +++ b/drivers/gpu/drm/msm/msm_gem_submit.c
> @@ -27,7 +27,7 @@
> #define BO_PINNED 0x2000
>
> static struct msm_gem_submit *submit_create(struct drm_device *dev,
> - struct msm_gpu *gpu, struct msm_gem_address_space *aspace,
> + struct msm_gpu *gpu,
> struct msm_gpu_submitqueue *queue, uint32_t nr_bos,
> uint32_t nr_cmds)
> {
> @@ -43,7 +43,7 @@ static struct msm_gem_submit *submit_create(struct
> drm_device *dev,
> return NULL;
>
> submit->dev = dev;
> - submit->aspace = aspace;
> + submit->aspace = queue->ctx->aspace;
> submit->gpu = gpu;
> submit->fence = NULL;
> submit->cmd = (void *)&submit->bos[nr_bos];
> @@ -677,7 +677,7 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void
> *data,
> }
> }
>
> - submit = submit_create(dev, gpu, ctx->aspace, queue, args->nr_bos,
> + submit = submit_create(dev, gpu, queue, args->nr_bos,
> args->nr_cmds);
> if (!submit) {
> ret = -ENOMEM;
> diff --git a/drivers/gpu/drm/msm/msm_gpu.h b/drivers/gpu/drm/msm/msm_gpu.h
> index f91b141add75..97c527e98391 100644
> --- a/drivers/gpu/drm/msm/msm_gpu.h
> +++ b/drivers/gpu/drm/msm/msm_gpu.h
> @@ -190,6 +190,7 @@ struct msm_gpu_submitqueue {
> u32 flags;
> u32 prio;
> int faults;
> + struct msm_file_private *ctx;
> struct list_head node;
>
Re: [PATCH 10/19] dt-bindings: arm-smmu: Add compatible string for Adreno GPU SMMU
On Thu 13 Aug 21:41 CDT 2020, Rob Clark wrote: > From: Jordan Crouse > > Every Qcom Adreno GPU has an embedded SMMU for its own use. These > devices depend on unique features such as split pagetables, > different stall/halt requirements and other settings. Identify them > with a compatible string so that they can be identified in the > arm-smmu implementation specific code. > Reviewed-by: Bjorn Andersson > Signed-off-by: Jordan Crouse > Reviewed-by: Rob Herring > Signed-off-by: Rob Clark > --- > Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 4 > 1 file changed, 4 insertions(+) > > diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml > b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml > index 503160a7b9a0..5ec5d0d691f6 100644 > --- a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml > +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml > @@ -40,6 +40,10 @@ properties: >- qcom,sm8150-smmu-500 >- qcom,sm8250-smmu-500 >- const: arm,mmu-500 > + - description: Qcom Adreno GPUs implementing "arm,smmu-v2" > +items: > + - const: qcom,adreno-smmu > + - const: qcom,smmu-v2 >- description: Marvell SoCs implementing "arm,mmu-500" > items: >- const: marvell,ap806-smmu-500 > -- > 2.26.2 >
[PATCH 1/2] usb: serial: option: Fix the lackage for Quectel EG95 LTE modem support
* Add reset-resume callback for resetting USB devices after MCU exits
from suspend/sleep mode.
* Because Quectel EG95 uses USB interface 4 as a USB network device, so
return from option_startup() to prevent being used as a USB serial
device.
Fixes: da6902e5b6db ("USB: serial: option: add Quectel EG95 LTE modem"
Signed-off-by: William Sung
---
drivers/usb/serial/option.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index 89b3192af326..9de8aec47e5e 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -2069,6 +2069,7 @@ static struct usb_serial_driver option_1port_device = {
#ifdef CONFIG_PM
.suspend = usb_wwan_suspend,
.resume= usb_wwan_resume,
+ .reset_resume = usb_wwan_resume,
#endif
};
@@ -2104,6 +2105,11 @@ static int option_probe(struct usb_serial *serial,
if (device_flags & NUMEP2 && iface_desc->bNumEndpoints != 2)
return -ENODEV;
+ /* Quectel EC25 & EC21 & EG91 & EG95 ... interface 4 can be used as USB
network device */
+ if (serial->dev->descriptor.idVendor == cpu_to_le16(0x2c7c) &&
+ serial->interface->cur_altsetting->desc.bInterfaceNumber >= 4)
+ return -ENODEV;
+
/* Store the device flags so we can use them during attach. */
usb_set_serial_data(serial, (void *)device_flags);
--
2.17.1
[PATCH 2/2] usb: serial: usb_wwan: Fix lackage for Quectel EG95 LTE modem support
As required by the USB protocol, add zero packet support for Quectel
EG95 LTE modem module.
Fixes: f815dd5cf48b ("net: usb: qmi_wwan: add support for Quectel EG95
LTE modem"
Signed-off-by: William Sung
---
drivers/usb/serial/usb_wwan.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/serial/usb_wwan.c b/drivers/usb/serial/usb_wwan.c
index 4b9845807bee..75495c939ac6 100644
--- a/drivers/usb/serial/usb_wwan.c
+++ b/drivers/usb/serial/usb_wwan.c
@@ -467,6 +467,7 @@ static struct urb *usb_wwan_setup_urb(struct
usb_serial_port *port,
struct usb_serial *serial = port->serial;
struct usb_wwan_intf_private *intfdata = usb_get_serial_data(serial);
struct urb *urb;
+ struct usb_device_descriptor *desc = &serial->dev->descriptor;
urb = usb_alloc_urb(0, GFP_KERNEL); /* No ISO */
if (!urb)
@@ -476,8 +477,15 @@ static struct urb *usb_wwan_setup_urb(struct
usb_serial_port *port,
usb_sndbulkpipe(serial->dev, endpoint) | dir,
buf, len, callback, ctx);
- if (intfdata->use_zlp && dir == USB_DIR_OUT)
- urb->transfer_flags |= URB_ZERO_PACKET;
+ if (dir == USB_DIR_OUT) {
+ if (intfdata->use_zlp)
+ urb->transfer_flags |= URB_ZERO_PACKET;
+
+ /* Add zero packet support for Quectel EG95 */
+ if (desc->idVendor == cpu_to_le16(0x2C7C) &&
+ desc->idProduct == cpu_to_le16(0x0195))
+ urb->transfer_flags |= URB_ZERO_PACKET;
+ }
return urb;
}
--
2.17.1
Re: [PATCH 09/19] iommu/arm-smmu-qcom: Add implementation for the adreno GPU SMMU
On Thu 13 Aug 21:41 CDT 2020, Rob Clark wrote:
> From: Jordan Crouse
>
> Add a special implementation for the SMMU attached to most Adreno GPU
> target triggered from the qcom,adreno-smmu compatible string.
>
> The new Adreno SMMU implementation will enable split pagetables
> (TTBR1) for the domain attached to the GPU device (SID 0) and
> hard code it context bank 0 so the GPU hardware can implement
> per-instance pagetables.
>
Reviewed-by: Bjorn Andersson
> Co-developed-by: Rob Clark
> Signed-off-by: Jordan Crouse
> Signed-off-by: Rob Clark
> ---
> drivers/iommu/arm/arm-smmu/arm-smmu-impl.c | 3 +
> drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 149 -
> drivers/iommu/arm/arm-smmu/arm-smmu.h | 1 +
> 3 files changed, 151 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c
> b/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c
> index 88f17cc33023..d199b4bff15d 100644
> --- a/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c
> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c
> @@ -223,6 +223,9 @@ struct arm_smmu_device *arm_smmu_impl_init(struct
> arm_smmu_device *smmu)
> of_device_is_compatible(np, "qcom,sm8250-smmu-500"))
> return qcom_smmu_impl_init(smmu);
>
> + if (of_device_is_compatible(smmu->dev->of_node, "qcom,adreno-smmu"))
> + return qcom_adreno_smmu_impl_init(smmu);
> +
> if (of_device_is_compatible(np, "marvell,ap806-smmu-500"))
> smmu->impl = &mrvl_mmu500_impl;
>
> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
> b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
> index be4318044f96..5640d9960610 100644
> --- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
> @@ -3,6 +3,7 @@
> * Copyright (c) 2019, The Linux Foundation. All rights reserved.
> */
>
> +#include
> #include
> #include
>
> @@ -12,6 +13,132 @@ struct qcom_smmu {
> struct arm_smmu_device smmu;
> };
>
> +#define QCOM_ADRENO_SMMU_GPU_SID 0
> +
> +static bool qcom_adreno_smmu_is_gpu_device(struct device *dev)
> +{
> + struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
> + int i;
> +
> + /*
> + * The GPU will always use SID 0 so that is a handy way to uniquely
> + * identify it and configure it for per-instance pagetables
> + */
> + for (i = 0; i < fwspec->num_ids; i++) {
> + u16 sid = FIELD_GET(ARM_SMMU_SMR_ID, fwspec->ids[i]);
> +
> + if (sid == QCOM_ADRENO_SMMU_GPU_SID)
> + return true;
> + }
> +
> + return false;
> +}
> +
> +static const struct io_pgtable_cfg *qcom_adreno_smmu_get_ttbr1_cfg(
> + const void *cookie)
> +{
> + struct arm_smmu_domain *smmu_domain = (void *)cookie;
> + struct io_pgtable *pgtable =
> + io_pgtable_ops_to_pgtable(smmu_domain->pgtbl_ops);
> + return &pgtable->cfg;
> +}
> +
> +/*
> + * Local implementation to configure TTBR0 with the specified pagetable
> config.
> + * The GPU driver will call this to enable TTBR0 when per-instance pagetables
> + * are active
> + */
> +
> +static int qcom_adreno_smmu_set_ttbr0_cfg(const void *cookie,
> + const struct io_pgtable_cfg *pgtbl_cfg)
> +{
> + struct arm_smmu_domain *smmu_domain = (void *)cookie;
> + struct io_pgtable *pgtable =
> io_pgtable_ops_to_pgtable(smmu_domain->pgtbl_ops);
> + struct arm_smmu_cfg *cfg = &smmu_domain->cfg;
> + struct arm_smmu_cb *cb = &smmu_domain->smmu->cbs[cfg->cbndx];
> +
> + /* The domain must have split pagetables already enabled */
> + if (cb->tcr[0] & ARM_SMMU_TCR_EPD1)
> + return -EINVAL;
> +
> + /* If the pagetable config is NULL, disable TTBR0 */
> + if (!pgtbl_cfg) {
> + /* Do nothing if it is already disabled */
> + if ((cb->tcr[0] & ARM_SMMU_TCR_EPD0))
> + return -EINVAL;
> +
> + /* Set TCR to the original configuration */
> + cb->tcr[0] = arm_smmu_lpae_tcr(&pgtable->cfg);
> + cb->ttbr[0] = FIELD_PREP(ARM_SMMU_TTBRn_ASID, cb->cfg->asid);
> + } else {
> + u32 tcr = cb->tcr[0];
> +
> + /* Don't call this again if TTBR0 is already enabled */
> + if (!(cb->tcr[0] & ARM_SMMU_TCR_EPD0))
> + return -EINVAL;
> +
> + tcr |= arm_smmu_lpae_tcr(pgtbl_cfg);
> + tcr &= ~(ARM_SMMU_TCR_EPD0 | ARM_SMMU_TCR_EPD1);
> +
> + cb->tcr[0] = tcr;
> + cb->ttbr[0] = pgtbl_cfg->arm_lpae_s1_cfg.ttbr;
> + cb->ttbr[0] |= FIELD_PREP(ARM_SMMU_TTBRn_ASID, cb->cfg->asid);
> + }
> +
> + arm_smmu_write_context_bank(smmu_domain->smmu, cb->cfg->cbndx);
> +
> + return 0;
> +}
> +
> +static int qcom_adreno_smmu_alloc_context_bank(struct arm_smmu_domain
> *smmu_domain,
> + struct device *dev, int start, int count)
> +{
> + struct arm_smmu_device *smmu = smmu_domain->smm
RE: [PATCH v7 2/3] dt-bindings: phy: intel: Add Keem Bay eMMC PHY bindings
> -Original Message-
> From: Vinod Koul
> Sent: Monday, August 31, 2020 5:10 PM
> To: Wan Mohamad, Wan Ahmad Zainie
>
> Cc: kis...@ti.com; robh...@kernel.org; Shevchenko, Andriy
> ; eswara.k...@linux.intel.com;
> vadivel.muruganx.ramuthe...@linux.intel.com; Raja Subramanian, Lakshmi
> Bai ; linux-
> ker...@vger.kernel.org; devicet...@vger.kernel.org
> Subject: Re: [PATCH v7 2/3] dt-bindings: phy: intel: Add Keem Bay eMMC
> PHY bindings
>
> On 21-08-20, 19:37, Wan Ahmad Zainie wrote:
> > Binding description for Intel Keem Bay eMMC PHY.
> >
> > Signed-off-by: Wan Ahmad Zainie
> >
> > Reviewed-by: Rob Herring
> > ---
> > .../bindings/phy/intel,keembay-emmc-phy.yaml | 44
> > +++
> > 1 file changed, 44 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/phy/intel,keembay-emmc-phy.yaml
> >
> > diff --git
> > a/Documentation/devicetree/bindings/phy/intel,keembay-emmc-
> phy.yaml
> > b/Documentation/devicetree/bindings/phy/intel,keembay-emmc-
> phy.yaml
> > new file mode 100644
> > index ..4cbbd3887c13
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/phy/intel,keembay-emmc-
> phy.yam
> > +++ l
> > @@ -0,0 +1,44 @@
> > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2
> > +---
> > +$id: "http://devicetree.org/schemas/phy/intel,keembay-emmc-
> phy.yaml#"
> > +$schema: "http://devicetree.org/meta-schemas/core.yaml#";
> > +
> > +title: Intel Keem Bay eMMC PHY bindings
>
> This seems same as
> Documentation/devicetree/bindings/phy/intel,lgm-emmc-phy.yaml, why
> not add a new compatible in lgm binding, or did I miss a difference?
AFAIK, LGM make use of syscon node, whilst KMB does not.
And LGM and KMB belongs to different SoC family. So, I prefer them to
be in separate file.
Having said that, with few changes in wordings in title and description,
I think we can make it generic and can be used across few products.
>
> > +
> > +maintainers:
> > + - Wan Ahmad Zainie
> > +
> > +properties:
> > + compatible:
> > +const: intel,keembay-emmc-phy
> > +
> > + reg:
> > +maxItems: 1
> > +
> > + clocks:
> > +maxItems: 1
> > +
> > + clock-names:
> > +items:
> > + - const: emmcclk
> > +
> > + "#phy-cells":
> > +const: 0
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - "#phy-cells"
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > +phy@2029 {
> > + compatible = "intel,keembay-emmc-phy";
> > + reg = <0x2029 0x54>;
> > + clocks = <&emmc>;
> > + clock-names = "emmcclk";
> > + #phy-cells = <0>;
> > +};
> > --
> > 2.17.1
>
> --
> ~Vinod
Re: [PATCH v2 7/7] compiler-gcc: improve version error
On Mon, Aug 31, 2020 at 05:23:26PM -0700, Nick Desaulniers wrote:
> As Kees suggests, do so provides developers with two useful pieces of
> information:
> - The kernel build was attempting to use GCC.
> (Maybe they accidentally poked the wrong configs in a CI.)
> - They need 4.9 or better.
> ("Upgrade to what version?" doesn't need to be dug out of documentation,
>headers, etc.)
>
> Suggested-by: Kees Cook
> Signed-off-by: Nick Desaulniers
Reviewed-by: Nathan Chancellor
It would be nice if there was some easy way to link the documentation
here so that patches like commit 0bddd227f3dc ("Documentation: update
for gcc 4.9 requirement") did not need to happen or be remembered.
> ---
> include/linux/compiler-gcc.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
> index 7a3769040d7d..d1e3c6896b71 100644
> --- a/include/linux/compiler-gcc.h
> +++ b/include/linux/compiler-gcc.h
> @@ -12,7 +12,7 @@
>
> /* https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58145 */
> #if GCC_VERSION < 40900
> -# error Sorry, your compiler is too old - please upgrade it.
> +# error Sorry, your version of GCC is too old - please use 4.9 or newer.
> #endif
>
> /* Optimization barrier */
> --
> 2.28.0.402.g5ffc5be6b7-goog
>
Re: [PATCH v2 6/7] kasan: Remove mentions of unsupported Clang versions
On Mon, Aug 31, 2020 at 05:23:25PM -0700, Nick Desaulniers wrote: > From: Marco Elver > > Since the kernel now requires at least Clang 10.0.1, remove any mention > of old Clang versions and simplify the documentation. > > Reviewed-by: Andrey Konovalov > Signed-off-by: Marco Elver > Signed-off-by: Nick Desaulniers Reviewed-by: Nathan Chancellor > --- > Documentation/dev-tools/kasan.rst | 4 ++-- > lib/Kconfig.kasan | 9 - > 2 files changed, 6 insertions(+), 7 deletions(-) > > diff --git a/Documentation/dev-tools/kasan.rst > b/Documentation/dev-tools/kasan.rst > index 38fd5681fade..4abc84b1798c 100644 > --- a/Documentation/dev-tools/kasan.rst > +++ b/Documentation/dev-tools/kasan.rst > @@ -13,10 +13,10 @@ KASAN uses compile-time instrumentation to insert > validity checks before every > memory access, and therefore requires a compiler version that supports that. > > Generic KASAN is supported in both GCC and Clang. With GCC it requires > version > -8.3.0 or later. With Clang it requires version 7.0.0 or later, but detection > of > +8.3.0 or later. Any supported Clang version is compatible, but detection of > out-of-bounds accesses for global variables is only supported since Clang 11. > > -Tag-based KASAN is only supported in Clang and requires version 7.0.0 or > later. > +Tag-based KASAN is only supported in Clang. > > Currently generic KASAN is supported for the x86_64, arm64, xtensa, s390 and > riscv architectures, and tag-based KASAN is supported only for arm64. > diff --git a/lib/Kconfig.kasan b/lib/Kconfig.kasan > index 047b53dbfd58..033a5bc67ac4 100644 > --- a/lib/Kconfig.kasan > +++ b/lib/Kconfig.kasan > @@ -54,9 +54,9 @@ config KASAN_GENERIC > Enables generic KASAN mode. > > This mode is supported in both GCC and Clang. With GCC it requires > - version 8.3.0 or later. With Clang it requires version 7.0.0 or > - later, but detection of out-of-bounds accesses for global variables > - is supported only since Clang 11. > + version 8.3.0 or later. Any supported Clang version is compatible, > + but detection of out-of-bounds accesses for global variables is > + supported only since Clang 11. > > This mode consumes about 1/8th of available memory at kernel start > and introduces an overhead of ~x1.5 for the rest of the allocations. > @@ -78,8 +78,7 @@ config KASAN_SW_TAGS > Enables software tag-based KASAN mode. > > This mode requires Top Byte Ignore support by the CPU and therefore > - is only supported for arm64. This mode requires Clang version 7.0.0 > - or later. > + is only supported for arm64. This mode requires Clang. > > This mode consumes about 1/16th of available memory at kernel start > and introduces an overhead of ~20% for the rest of the allocations. > -- > 2.28.0.402.g5ffc5be6b7-goog >
Re: [PATCH 07/19] drm/msm: set adreno_smmu as gpu's drvdata
On Thu 13 Aug 21:41 CDT 2020, Rob Clark wrote:
> From: Rob Clark
>
> This will be populated by adreno-smmu, to provide a way for coordinating
> enabling/disabling TTBR0 translation.
>
Reviewed-by: Bjorn Andersson
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/msm/adreno/adreno_device.c | 2 --
> drivers/gpu/drm/msm/msm_gpu.c | 2 +-
> drivers/gpu/drm/msm/msm_gpu.h | 6 +-
> 3 files changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c
> b/drivers/gpu/drm/msm/adreno/adreno_device.c
> index 26664e1b30c0..58e03b20e1c7 100644
> --- a/drivers/gpu/drm/msm/adreno/adreno_device.c
> +++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
> @@ -417,8 +417,6 @@ static int adreno_bind(struct device *dev, struct device
> *master, void *data)
> return PTR_ERR(gpu);
> }
>
> - dev_set_drvdata(dev, gpu);
> -
> return 0;
> }
>
> diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
> index 6aa9e04e52e7..806eb0957280 100644
> --- a/drivers/gpu/drm/msm/msm_gpu.c
> +++ b/drivers/gpu/drm/msm/msm_gpu.c
> @@ -892,7 +892,7 @@ int msm_gpu_init(struct drm_device *drm, struct
> platform_device *pdev,
> gpu->gpu_cx = NULL;
>
> gpu->pdev = pdev;
> - platform_set_drvdata(pdev, gpu);
> + platform_set_drvdata(pdev, &gpu->adreno_smmu);
>
> msm_devfreq_init(gpu);
>
> diff --git a/drivers/gpu/drm/msm/msm_gpu.h b/drivers/gpu/drm/msm/msm_gpu.h
> index 8bda7beaed4b..f91b141add75 100644
> --- a/drivers/gpu/drm/msm/msm_gpu.h
> +++ b/drivers/gpu/drm/msm/msm_gpu.h
> @@ -7,6 +7,7 @@
> #ifndef __MSM_GPU_H__
> #define __MSM_GPU_H__
>
> +#include
> #include
> #include
> #include
> @@ -73,6 +74,8 @@ struct msm_gpu {
> struct platform_device *pdev;
> const struct msm_gpu_funcs *funcs;
>
> + struct adreno_smmu_priv adreno_smmu;
> +
> /* performance counters (hw & sw): */
> spinlock_t perf_lock;
> bool perfcntr_active;
> @@ -143,7 +146,8 @@ struct msm_gpu {
>
> static inline struct msm_gpu *dev_to_gpu(struct device *dev)
> {
> - return dev_get_drvdata(dev);
> + struct adreno_smmu_priv *adreno_smmu = dev_get_drvdata(dev);
> + return container_of(adreno_smmu, struct msm_gpu, adreno_smmu);
> }
>
> /* It turns out that all targets use the same ringbuffer size */
> --
> 2.26.2
>
Re: [PATCH v2 5/7] Partial revert "ARM: 8905/1: Emit __gnu_mcount_nc when using Clang 10.0.0 or newer"
Nit: Partially in commit message? On Mon, Aug 31, 2020 at 05:23:24PM -0700, Nick Desaulniers wrote: > This partially reverts commit b0fe66cf095016e0b238374c10ae366e1f087d11. > > The minimum supported version of clang is now clang 10.0.1. We still > want to pass -meabi=gnu. Thank you for calling this out. > Suggested-by: Nathan Chancellor > Signed-off-by: Nick Desaulniers Reviewed-by: Nathan Chancellor > --- > arch/arm/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index 82c197a248dd..09a7669eea1d 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -83,7 +83,7 @@ config ARM > select HAVE_FAST_GUP if ARM_LPAE > select HAVE_FTRACE_MCOUNT_RECORD if !XIP_KERNEL > select HAVE_FUNCTION_GRAPH_TRACER if !THUMB2_KERNEL && !CC_IS_CLANG > - select HAVE_FUNCTION_TRACER if !XIP_KERNEL && (CC_IS_GCC || > CLANG_VERSION >= 10) > + select HAVE_FUNCTION_TRACER if !XIP_KERNEL > select HAVE_GCC_PLUGINS > select HAVE_HW_BREAKPOINT if PERF_EVENTS && (CPU_V6 || CPU_V6K || > CPU_V7) > select HAVE_IDE if PCI || ISA || PCMCIA > -- > 2.28.0.402.g5ffc5be6b7-goog >
Re: [PATCH v2 4/7] Revert "arm64: vdso: Fix compilation with clang older than 8"
On Mon, Aug 31, 2020 at 05:23:23PM -0700, Nick Desaulniers wrote: > This reverts commit 3acf4be235280f14d838581a750532219d67facc. > > The minimum supported version of clang is clang 10.0.1. > > Suggested-by: Nathan Chancellor > Signed-off-by: Nick Desaulniers Reviewed-by: Nathan Chancellor > --- > arch/arm64/kernel/vdso/Makefile | 7 --- > 1 file changed, 7 deletions(-) > > diff --git a/arch/arm64/kernel/vdso/Makefile b/arch/arm64/kernel/vdso/Makefile > index 45d5cfe46429..04021a93171c 100644 > --- a/arch/arm64/kernel/vdso/Makefile > +++ b/arch/arm64/kernel/vdso/Makefile > @@ -43,13 +43,6 @@ ifneq ($(c-gettimeofday-y),) >CFLAGS_vgettimeofday.o += -include $(c-gettimeofday-y) > endif > > -# Clang versions less than 8 do not support -mcmodel=tiny > -ifeq ($(CONFIG_CC_IS_CLANG), y) > - ifeq ($(shell test $(CONFIG_CLANG_VERSION) -lt 8; echo $$?),0) > -CFLAGS_REMOVE_vgettimeofday.o += -mcmodel=tiny > - endif > -endif > - > # Disable gcov profiling for VDSO code > GCOV_PROFILE := n > > -- > 2.28.0.402.g5ffc5be6b7-goog >
Re: [PATCH v2 3/7] Revert "arm64: bti: Require clang >= 10.0.1 for in-kernel BTI support"
On Mon, Aug 31, 2020 at 05:23:22PM -0700, Nick Desaulniers wrote: > This reverts commit b9249cba25a5dce5de87e5404503a5e11832c2dd. > > The minimum supported version of clang is now 10.0.1. > > Suggested-by: Nathan Chancellor > Signed-off-by: Nick Desaulniers Reviewed-by: Nathan Chancellor > --- > arch/arm64/Kconfig | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig > index 6d232837cbee..2a70b85b1a61 100644 > --- a/arch/arm64/Kconfig > +++ b/arch/arm64/Kconfig > @@ -1630,8 +1630,6 @@ config ARM64_BTI_KERNEL > depends on CC_HAS_BRANCH_PROT_PAC_RET_BTI > # https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94697 > depends on !CC_IS_GCC || GCC_VERSION >= 100100 > - # https://reviews.llvm.org/rGb8ae3fdfa579dbf366b1bb1cbfdbf8c51db7fa55 > - depends on !CC_IS_CLANG || CLANG_VERSION >= 11 > depends on !(CC_IS_CLANG && GCOV_KERNEL) > depends on (!FUNCTION_GRAPH_TRACER || DYNAMIC_FTRACE_WITH_REGS) > help > -- > 2.28.0.402.g5ffc5be6b7-goog >
Re: [PATCH 08/19] iommu/arm-smmu: constify some helpers
On Thu 13 Aug 21:41 CDT 2020, Rob Clark wrote:
> From: Rob Clark
>
> Sprinkle a few `const`s where helpers don't need write access.
>
Reviewed-by: Bjorn Andersson
> Signed-off-by: Rob Clark
> ---
> drivers/iommu/arm/arm-smmu/arm-smmu.h | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.h
> b/drivers/iommu/arm/arm-smmu/arm-smmu.h
> index 59ff3fc5c6c8..27c8fc50 100644
> --- a/drivers/iommu/arm/arm-smmu/arm-smmu.h
> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu.h
> @@ -377,7 +377,7 @@ struct arm_smmu_master_cfg {
> s16 smendx[];
> };
>
> -static inline u32 arm_smmu_lpae_tcr(struct io_pgtable_cfg *cfg)
> +static inline u32 arm_smmu_lpae_tcr(const struct io_pgtable_cfg *cfg)
> {
> u32 tcr = FIELD_PREP(ARM_SMMU_TCR_TG0, cfg->arm_lpae_s1_cfg.tcr.tg) |
> FIELD_PREP(ARM_SMMU_TCR_SH0, cfg->arm_lpae_s1_cfg.tcr.sh) |
> @@ -398,13 +398,13 @@ static inline u32 arm_smmu_lpae_tcr(struct
> io_pgtable_cfg *cfg)
> return tcr;
> }
>
> -static inline u32 arm_smmu_lpae_tcr2(struct io_pgtable_cfg *cfg)
> +static inline u32 arm_smmu_lpae_tcr2(const struct io_pgtable_cfg *cfg)
> {
> return FIELD_PREP(ARM_SMMU_TCR2_PASIZE, cfg->arm_lpae_s1_cfg.tcr.ips) |
> FIELD_PREP(ARM_SMMU_TCR2_SEP, ARM_SMMU_TCR2_SEP_UPSTREAM);
> }
>
> -static inline u32 arm_smmu_lpae_vtcr(struct io_pgtable_cfg *cfg)
> +static inline u32 arm_smmu_lpae_vtcr(const struct io_pgtable_cfg *cfg)
> {
> return ARM_SMMU_VTCR_RES1 |
> FIELD_PREP(ARM_SMMU_VTCR_PS, cfg->arm_lpae_s2_cfg.vtcr.ps) |
> --
> 2.26.2
>
Re: [PATCH v2 2/7] Revert "kbuild: disable clang's default use of -fmerge-all-constants"
On Mon, Aug 31, 2020 at 05:23:21PM -0700, Nick Desaulniers wrote: > This reverts commit 87e0d4f0f37fb0c8c4aeeac46fff5e957738df79. > > This was fixed in clang-6; the minimum supported version of clang in the > kernel is clang-10 (10.0.1). > > Link: https://reviews.llvm.org/rL329300. > Link: https://github.com/ClangBuiltLinux/linux/issues/9 > Suggested-by: Nathan Chancellor > Signed-off-by: Nick Desaulniers Reviewed-by: Nathan Chancellor > --- > Makefile | 9 - > 1 file changed, 9 deletions(-) > > diff --git a/Makefile b/Makefile > index 37739ee53f27..144ac6a073ff 100644 > --- a/Makefile > +++ b/Makefile > @@ -932,15 +932,6 @@ KBUILD_CFLAGS += $(call cc-disable-warning, > maybe-uninitialized) > # disable invalid "can't wrap" optimizations for signed / pointers > KBUILD_CFLAGS+= $(call cc-option,-fno-strict-overflow) > > -# clang sets -fmerge-all-constants by default as optimization, but this > -# is non-conforming behavior for C and in fact breaks the kernel, so we > -# need to disable it here generally. > -KBUILD_CFLAGS+= $(call cc-option,-fno-merge-all-constants) > - > -# for gcc -fno-merge-all-constants disables everything, but it is fine > -# to have actual conforming behavior enabled. > -KBUILD_CFLAGS+= $(call cc-option,-fmerge-constants) > - > # Make sure -fstack-check isn't enabled (like gentoo apparently did) > KBUILD_CFLAGS += $(call cc-option,-fno-stack-check,) > > -- > 2.28.0.402.g5ffc5be6b7-goog >
RE: [PATCH v7 3/3] phy: intel: Add Keem Bay eMMC PHY support
Hi Vinod. Thanks for the review. > -Original Message- > From: Vinod Koul > Sent: Monday, August 31, 2020 5:20 PM > To: Wan Mohamad, Wan Ahmad Zainie > > Cc: kis...@ti.com; robh...@kernel.org; Shevchenko, Andriy > ; eswara.k...@linux.intel.com; > vadivel.muruganx.ramuthe...@linux.intel.com; Raja Subramanian, Lakshmi > Bai ; linux- > ker...@vger.kernel.org; devicet...@vger.kernel.org > Subject: Re: [PATCH v7 3/3] phy: intel: Add Keem Bay eMMC PHY support > > On 21-08-20, 19:37, Wan Ahmad Zainie wrote: > > > +/* From ACS_eMMC51_16nFFC_RO1100_Userguide_v1p0.pdf p17 */ > > +#define FREQSEL_200M_170M 0x0 > > +#define FREQSEL_170M_140M 0x1 > > +#define FREQSEL_140M_110M 0x2 > > +#define FREQSEL_110M_80M 0x3 > > +#define FREQSEL_80M_50M0x4 > > + > > +#define maskval(mask, val) (((val) << (ffs(mask) - 1)) & mask) > > Kernel has a macro do this for you, please use FIELD_PREP instead of I have updated to v8, to remove this macro and use FIELD_PREP. I also add changes based on Andy's comments. > > your own macro > -- > ~Vinod Best regards, Zainie
