Re: linux-next: manual merge of the akpm-current tree with the powerpc tree
Le 15/04/2021 à 11:58, Stephen Rothwell a écrit :
Hi all,
On Thu, 15 Apr 2021 19:44:17 +1000 Stephen Rothwell
wrote:
Today's linux-next merge of the akpm-current tree got a conflict in:
arch/powerpc/kernel/module.c
between commit:
2ec13df16704 ("powerpc/modules: Load modules closer to kernel text")
from the powerpc tree and commit:
4930ba789f8d ("powerpc/64s/radix: enable huge vmalloc mappings")
from the akpm-current tree.
I fixed it up (I think - see below) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging. You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc arch/powerpc/kernel/module.c
index fab84024650c,cdb2d88c54e7..
--- a/arch/powerpc/kernel/module.c
+++ b/arch/powerpc/kernel/module.c
@@@ -88,29 -88,26 +89,42 @@@ int module_finalize(const Elf_Ehdr *hdr
return 0;
}
- #ifdef MODULES_VADDR
-void *module_alloc(unsigned long size)
+static __always_inline void *
+__module_alloc(unsigned long size, unsigned long start, unsigned long end)
{
- unsigned long start = VMALLOC_START;
- unsigned long end = VMALLOC_END;
-
-#ifdef MODULES_VADDR
- BUILD_BUG_ON(TASK_SIZE > MODULES_VADDR);
- start = MODULES_VADDR;
- end = MODULES_END;
-#endif
-
+ /*
+* Don't do huge page allocations for modules yet until more testing
+* is done. STRICT_MODULE_RWX may require extra work to support this
+* too.
+*/
+
return __vmalloc_node_range(size, 1, start, end, GFP_KERNEL,
- PAGE_KERNEL_EXEC, VM_FLUSH_RESET_PERMS,
NUMA_NO_NODE,
+ PAGE_KERNEL_EXEC,
+ VM_NO_HUGE_VMAP | VM_FLUSH_RESET_PERMS,
+ NUMA_NO_NODE,
__builtin_return_address(0));
}
+
++
+void *module_alloc(unsigned long size)
+{
++ unsigned long start = VMALLOC_START;
++ unsigned long end = VMALLOC_END;
+ unsigned long limit = (unsigned long)_etext - SZ_32M;
+ void *ptr = NULL;
+
++#ifdef MODULES_VADDR
+ BUILD_BUG_ON(TASK_SIZE > MODULES_VADDR);
++ start = MODULES_VADDR;
++ end = MODULES_END;
The #endif should be here.
+
+ /* First try within 32M limit from _etext to avoid branch trampolines */
+ if (MODULES_VADDR < PAGE_OFFSET && MODULES_END > limit)
- ptr = __module_alloc(size, limit, MODULES_END);
++ ptr = __module_alloc(size, limit, end);
+
+ if (!ptr)
- ptr = __module_alloc(size, MODULES_VADDR, MODULES_END);
++#endif
++ ptr = __module_alloc(size, start, end);
+
+ return ptr;
+}
- #endif
Unfortunately, it also needs this:
Before the #endif is too far.
From: Stephen Rothwell
Date: Thu, 15 Apr 2021 19:53:58 +1000
Subject: [PATCH] merge fix up for powerpc merge fix
Signed-off-by: Stephen Rothwell
---
arch/powerpc/kernel/module.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/powerpc/kernel/module.c b/arch/powerpc/kernel/module.c
index d8ab1ad2eb05..c060f99afd4d 100644
--- a/arch/powerpc/kernel/module.c
+++ b/arch/powerpc/kernel/module.c
@@ -110,7 +110,9 @@ void *module_alloc(unsigned long size)
{
unsigned long start = VMALLOC_START;
unsigned long end = VMALLOC_END;
+#ifdef MODULES_VADDR
unsigned long limit = (unsigned long)_etext - SZ_32M;
+#endif
void *ptr = NULL;
#ifdef MODULES_VADDR
[PATCH 0/6] remove DBG_871X_LEVEL macro
This patchset removes DBG_871X_LEVEL macro.
It does a raw printk so replace it with the more
recommended netdev_*() functions.
Removal and replacement is done with the following
semantic patch:
@@
expression list args;
identifier padapter;
identifier func;
symbol _drv_always_, _drv_info_, _drv_warning_;
symbol _drv_err_, _drv_emerg_;
@@
func(..., struct adapter *padapter, ...) {
<...
(
- DBG_871X_LEVEL(_drv_always_, args);
+ netdev_dbg(padapter->pnetdev, args);
|
- DBG_871X_LEVEL(_drv_info_, args);
+ netdev_info(padapter->pnetdev, args);
|
- DBG_871X_LEVEL(_drv_warning_, args);
+ netdev_warn(padapter->pnetdev, args);
|
- DBG_871X_LEVEL(_drv_err_, args);
+ netdev_err(padapter->pnetdev, args);
|
- DBG_871X_LEVEL(_drv_emerg_, args);
+ netdev_emerg(padapter->pnetdev, args);
)
...>
}
@rule@
identifier func, context, padapter;
@@
func(void *context)
{
...
struct adapter *padapter = context;
...
}
@@
expression list args;
identifier rule.padapter;
identifier rule.func, rule.context;
@@
func(void *context)
{
<...
(
- DBG_871X_LEVEL(_drv_always_, args);
+ netdev_dbg(padapter->pnetdev, args);
|
- DBG_871X_LEVEL(_drv_info_, args);
+ netdev_info(padapter->pnetdev, args);
|
- DBG_871X_LEVEL(_drv_warning_, args);
+ netdev_warn(padapter->pnetdev, args);
|
- DBG_871X_LEVEL(_drv_err_, args);
+ netdev_err(padapter->pnetdev, args);
|
- DBG_871X_LEVEL(_drv_emerg_, args);
+ netdev_emerg(padapter->pnetdev, args);
)
...>
}
@@
expression list args;
expression get_dev;
identifier func, dev;
@@
func(...)
{
...
struct net_device *dev = get_dev;
<...
(
- DBG_871X_LEVEL(_drv_always_, args);
+ netdev_dbg(dev, args);
|
- DBG_871X_LEVEL(_drv_info_, args);
+ netdev_info(dev, args);
|
- DBG_871X_LEVEL(_drv_warning_, args);
+ netdev_warn(dev, args);
|
- DBG_871X_LEVEL(_drv_err_, args);
+ netdev_err(dev, args);
|
- DBG_871X_LEVEL(_drv_emerg_, args);
+ netdev_emerg(dev, args);
)
...>
}
@@
expression list args;
identifier func, dev;
@@
func(struct net_device *dev)
{
<...
(
- DBG_871X_LEVEL(_drv_always_, args);
+ netdev_dbg(dev, args);
|
- DBG_871X_LEVEL(_drv_info_, args);
+ netdev_info(dev, args);
|
- DBG_871X_LEVEL(_drv_warning_, args);
+ netdev_warn(dev, args);
|
- DBG_871X_LEVEL(_drv_err_, args);
+ netdev_err(dev, args);
|
- DBG_871X_LEVEL(_drv_emerg_, args);
+ netdev_emerg(dev, args);
)
...>
}
@@
expression list args;
identifier func, dvobj;
@@
func(struct dvobj_priv *dvobj)
{
<...
(
- DBG_871X_LEVEL(_drv_always_, args);
+ netdev_dbg(dvobj->if1->pnetdev, args);
|
- DBG_871X_LEVEL(_drv_info_, args);
+ netdev_info(dvobj->if1->pnetdev, args);
|
- DBG_871X_LEVEL(_drv_warning_, args);
+ netdev_warn(dvobj->if1->pnetdev, args);
|
- DBG_871X_LEVEL(_drv_err_, args);
+ netdev_err(dvobj->if1->pnetdev, args);
|
- DBG_871X_LEVEL(_drv_emerg_, args);
+ netdev_emerg(dvobj->if1->pnetdev, args);
)
...>
}
@@
@@
- DBG_871X_LEVEL(...);
Some code cleaning done as well.
Fabio Aiuto (6):
staging: rtl8723bs: replace DBG_871X_LEVEL logs with netdev_*()
staging: rtl8723bs: fix code indent issue
staging: rtl8723bs: fix indentation in if block
staging: rtl8723bs: split too long line
staging: rtl8723bs: remove unused DBG_871X_LEVEL macro declarations
staging: rtl8723bs: remove empty #ifdef block
drivers/staging/rtl8723bs/core/rtw_cmd.c | 30 +---
drivers/staging/rtl8723bs/core/rtw_io.c | 4 +-
.../staging/rtl8723bs/core/rtw_ioctl_set.c| 10 +--
drivers/staging/rtl8723bs/core/rtw_mlme.c | 3 +-
drivers/staging/rtl8723bs/core/rtw_mlme_ext.c | 72 ---
drivers/staging/rtl8723bs/core/rtw_pwrctrl.c | 9 ++-
drivers/staging/rtl8723bs/core/rtw_security.c | 40 +++
.../staging/rtl8723bs/core/rtw_wlan_util.c| 21 +++---
drivers/staging/rtl8723bs/core/rtw_xmit.c | 2 +-
drivers/staging/rtl8723bs/hal/hal_com.c | 26 ---
.../staging/rtl8723bs/hal/rtl8723b_hal_init.c | 4 +-
.../staging/rtl8723bs/hal/rtl8723bs_xmit.c| 14 ++--
drivers/staging/rtl8723bs/hal/sdio_ops.c | 3 +-
drivers/staging/rtl8723bs/include/rtw_debug.h | 14
.../staging/rtl8723bs/os_dep/ioctl_cfg80211.c | 8 ++-
.../staging/rtl8723bs/os_dep/ioctl_linux.c| 2 +-
drivers/staging/rtl8723bs/os_dep/os_intfs.c | 32 +
drivers/staging/rtl8723bs/os_dep/sdio_intf.c | 15 +---
18 files changed, 181 insertions(+), 128 deletions(-)
--
2.20.1
[PATCH 3/6] staging: rtl8723bs: fix indentation in if block
fix following post-commit hook checkpatch issues:
WARNING: suspect code indent for conditional statements (32, 48)
323: FILE: drivers/staging/rtl8723bs/core/rtw_mlme_ext.c:708:
if (!ret) {
+
netdev_dbg(padapter->pnetdev,
Signed-off-by: Fabio Aiuto
---
drivers/staging/rtl8723bs/core/rtw_mlme_ext.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/rtl8723bs/core/rtw_mlme_ext.c
b/drivers/staging/rtl8723bs/core/rtw_mlme_ext.c
index 775e55ecac25..06544d0652b8 100644
--- a/drivers/staging/rtl8723bs/core/rtw_mlme_ext.c
+++ b/drivers/staging/rtl8723bs/core/rtw_mlme_ext.c
@@ -706,10 +706,10 @@ unsigned int OnBeacon(struct adapter *padapter, union
recv_frame *precv_frame)
if (psta) {
ret = rtw_check_bcn_info(padapter, pframe, len);
if (!ret) {
- netdev_dbg(padapter->pnetdev,
- "ap has changed,
disconnect now\n ");
- receive_disconnect(padapter,
pmlmeinfo->network.MacAddress, 0);
- return _SUCCESS;
+ netdev_dbg(padapter->pnetdev,
+ "ap has changed, disconnect
now\n ");
+ receive_disconnect(padapter,
pmlmeinfo->network.MacAddress, 0);
+ return _SUCCESS;
}
/* update WMM, ERP in the beacon */
/* todo: the timer is used instead of the
number of the beacon received */
--
2.20.1
[PATCH 5/6] staging: rtl8723bs: remove unused DBG_871X_LEVEL macro declarations
remove unused DBG_871X_LEVEL macro declarations.
DBG_871X_LEVEL macro wraps a raw printk call which is not
recommended in a device driver context, prefer using
netdev_*() log functions.
Signed-off-by: Fabio Aiuto
---
drivers/staging/rtl8723bs/include/rtw_debug.h | 14 --
1 file changed, 14 deletions(-)
diff --git a/drivers/staging/rtl8723bs/include/rtw_debug.h
b/drivers/staging/rtl8723bs/include/rtw_debug.h
index 12873c3d801d..23f4cb4711d4 100644
--- a/drivers/staging/rtl8723bs/include/rtw_debug.h
+++ b/drivers/staging/rtl8723bs/include/rtw_debug.h
@@ -131,8 +131,6 @@
#define _MODULE_DEFINE_ _module_efuse_
#endif
-#define DBG_871X_LEVEL(x, ...) do {} while (0)
-
#undef _dbgdump
#ifndef _RTL871X_DEBUG_C_
@@ -146,18 +144,6 @@
#if defined(_dbgdump)
-/* with driver-defined prefix */
-#undef DBG_871X_LEVEL
-#define DBG_871X_LEVEL(level, fmt, arg...) \
- do {\
- if (level <= GlobalDebugLevel) {\
- if (level <= _drv_err_ && level > _drv_always_) \
- _dbgdump(DRIVER_PREFIX"ERROR " fmt, ##arg);\
- else \
- _dbgdump(DRIVER_PREFIX fmt, ##arg);\
- } \
- } while (0)
-
/* without driver-defined prefix */
#undef _DBG_871X_LEVEL
#define _DBG_871X_LEVEL(level, fmt, arg...) \
--
2.20.1
[PATCH 6/6] staging: rtl8723bs: remove empty #ifdef block
remove #ifdef block left empty after DBG_871X_LEVEL
deletion.
Signed-off-by: Fabio Aiuto
---
drivers/staging/rtl8723bs/os_dep/sdio_intf.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/staging/rtl8723bs/os_dep/sdio_intf.c
b/drivers/staging/rtl8723bs/os_dep/sdio_intf.c
index c767651e2134..d2bf444117b8 100644
--- a/drivers/staging/rtl8723bs/os_dep/sdio_intf.c
+++ b/drivers/staging/rtl8723bs/os_dep/sdio_intf.c
@@ -487,10 +487,6 @@ static int __init rtw_drv_entry(void)
{
int ret;
-#ifdef BTCOEXVERSION
-#endif /* BTCOEXVERSION */
-
-
ret = sdio_register_driver(_sdio_driver);
if (ret != 0)
rtw_ndev_notifier_unregister();
--
2.20.1
Re: [PATCH 03/13] Makefile: Generate CLANG_FLAGS even in GCC builds
Hi Nathan, Sorry, with all the other things I ended up not replying to you before going to sleep. On Wed, Apr 14, 2021 at 8:59 PM Nathan Chancellor wrote: > > Shuffling this around will cause this issue (I never saw you CC'd on the > thread). > > https://lore.kernel.org/r/f6218ac526a04fa4d4406f935bcc4eb4a7df65c4.1617917438.git.msucha...@suse.de/ > > Perhaps that patch should be added to this series? Ah, thanks for the pointer! Yeah, I was not aware of that thread. It is good to find these bits though, that's why we are in linux-next after all! :) Cheers, Miguel
Re: [PATCH v6 3/4] serial: 8250_aspeed_vuart: add aspeed,lpc-io-reg and aspeed,lpc-interrupts DT properties
On Mon, Apr 12, 2021 at 7:05 AM Zev Weiss wrote:
>
> These allow describing all the Aspeed VUART attributes currently
> available via sysfs. aspeed,lpc-interrupts provides a replacement for
> the deprecated aspeed,sirq-polarity-sense property.
One nit-pick below.
In any case it's fine.
> Signed-off-by: Zev Weiss
> ---
> drivers/tty/serial/8250/8250_aspeed_vuart.c | 51 -
> 1 file changed, 49 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/tty/serial/8250/8250_aspeed_vuart.c
> b/drivers/tty/serial/8250/8250_aspeed_vuart.c
> index 8433f8dbb186..3c239d98747f 100644
> --- a/drivers/tty/serial/8250/8250_aspeed_vuart.c
> +++ b/drivers/tty/serial/8250/8250_aspeed_vuart.c
> @@ -28,6 +28,10 @@
> #define ASPEED_VUART_ADDRL 0x28
> #define ASPEED_VUART_ADDRH 0x2c
>
> +#define ASPEED_VUART_DEFAULT_LPC_ADDR 0x3f8
> +#define ASPEED_VUART_DEFAULT_SIRQ 4
> +#define ASPEED_VUART_DEFAULT_SIRQ_POLARITY IRQ_TYPE_LEVEL_LOW
> +
> struct aspeed_vuart {
> struct device *dev;
> void __iomem*regs;
> @@ -386,6 +390,18 @@ static void aspeed_vuart_auto_configure_sirq_polarity(
> aspeed_vuart_set_sirq_polarity(vuart, (value & reg_mask) == 0);
> }
>
> +static int aspeed_vuart_map_irq_polarity(u32 dt)
> +{
> + switch (dt) {
> + case IRQ_TYPE_LEVEL_LOW:
> + return 0;
> + case IRQ_TYPE_LEVEL_HIGH:
> + return 1;
> + default:
> + return -EINVAL;
> + }
> +}
> +
> static int aspeed_vuart_probe(struct platform_device *pdev)
> {
> struct of_phandle_args sirq_polarity_sense_args;
> @@ -393,8 +409,8 @@ static int aspeed_vuart_probe(struct platform_device
> *pdev)
> struct aspeed_vuart *vuart;
> struct device_node *np;
> struct resource *res;
> - u32 clk, prop;
> - int rc;
> + u32 clk, prop, sirq[2];
> + int rc, sirq_polarity;
>
> np = pdev->dev.of_node;
>
> @@ -501,6 +517,37 @@ static int aspeed_vuart_probe(struct platform_device
> *pdev)
> of_node_put(sirq_polarity_sense_args.np);
> }
>
> + rc = of_property_read_u32(np, "aspeed,lpc-io-reg", );
> + if (rc < 0)
> + prop = ASPEED_VUART_DEFAULT_LPC_ADDR;
> +
> + rc = aspeed_vuart_set_lpc_address(vuart, prop);
> + if (rc < 0) {
> + dev_err(>dev, "invalid value in aspeed,lpc-io-reg
> property\n");
> + goto err_clk_disable;
> + }
> +
> + rc = of_property_read_u32_array(np, "aspeed,lpc-interrupts", sirq, 2);
> + if (rc < 0) {
> + sirq[0] = ASPEED_VUART_DEFAULT_SIRQ;
> + sirq[1] = ASPEED_VUART_DEFAULT_SIRQ_POLARITY;
> + }
> +
> + rc = aspeed_vuart_set_sirq(vuart, sirq[0]);
> + if (rc < 0) {
> + dev_err(>dev, "invalid sirq number in
> aspeed,lpc-interrupts property\n");
> + goto err_clk_disable;
> + }
> +
> + sirq_polarity = aspeed_vuart_map_irq_polarity(sirq[1]);
> + if (sirq_polarity < 0) {
> + dev_err(>dev, "invalid sirq polarity in
> aspeed,lpc-interrupts property\n");
> + rc = sirq_polarity;
> + goto err_clk_disable;
> + }
Why not to use the same pattern as above, i.e.
rc = aspeed_vuart_map_irq_polarity(sirq[1]);
if (rc < 0) {
dev_err(>dev, "invalid sirq polarity in
aspeed,lpc-interrupts property\n");
goto err_clk_disable;
}
sirq_polarity = rc;
?
> + aspeed_vuart_set_sirq_polarity(vuart, sirq_polarity);
> +
> aspeed_vuart_set_enabled(vuart, true);
> aspeed_vuart_set_host_tx_discard(vuart, true);
> platform_set_drvdata(pdev, vuart);
--
With Best Regards,
Andy Shevchenko
[PATCH v3 24/24] ARM: at91: pm: add sama7g5 shdwc
Add SAMA7G5 SHDWC.
Signed-off-by: Claudiu Beznea
---
arch/arm/mach-at91/pm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
index 24d5fd06d487..d6cfe7c4bb00 100644
--- a/arch/arm/mach-at91/pm.c
+++ b/arch/arm/mach-at91/pm.c
@@ -794,6 +794,7 @@ static int __init at91_pm_backup_init(void)
static const struct of_device_id atmel_shdwc_ids[] = {
{ .compatible = "atmel,sama5d2-shdwc" },
{ .compatible = "microchip,sam9x60-shdwc" },
+ { .compatible = "microchip,sama7g5-shdwc" },
{ /* sentinel. */ }
};
--
2.25.1
Re: [PATCH v6 2/4] leds: Add driver for Qualcomm LPG
Hi, On Wed, 21 Oct 2020 13:12:22 -0700 Bjorn Andersson wrote: > The Light Pulse Generator (LPG) is a PWM-block found in a wide range of > PMICs from Qualcomm. It can operate on fixed parameters or based on a > lookup-table, altering the duty cycle over time - which provides the > means for e.g. hardware assisted transitions of LED brightness. > > Signed-off-by: Bjorn Andersson > --- > > Changes since v5: > - Make sure to not used the state of the last channel in a group to > determine if the current sink should be active for all channels in the > group. - Replacement of unsigned -1 with UINT_MAX > - Work around potential overflow by using larger data types, instead of > separate code paths - Use cpu_to_l16() rather than hand rolling them > - Minor style cleanups > > drivers/leds/Kconfig |9 + > drivers/leds/Makefile|1 + > drivers/leds/leds-qcom-lpg.c | 1190 ++ > 3 files changed, 1200 insertions(+) > create mode 100644 drivers/leds/leds-qcom-lpg.c Works well on the Xiaomi Mi Note 2 (msm8996pro/pmi8996). Tested-by: Yassine Oudjana Regards, Yassine
linux-next: Tree for Apr 15
Hi all, Changes since 20210414: The rdma tree gained a conflict against Linus' tree. The net-next tree gained a conflict against the net tree. The vfio tree gained a conflict against the drm tree. The akpm-current tree gained a conflict against the powerpc tree. Non-merge commits (relative to Linus' tree): 11858 10560 files changed, 579015 insertions(+), 265574 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig and htmldocs. And finally, a simple boot test of the powerpc pseries_le_defconfig kernel in qemu (with and without kvm enabled). Below is a summary of the state of the merge. I am currently merging 338 trees (counting Linus' and 87 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (7f75285ca572 Merge tag 'for-5.12/dm-fixes-3' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm) Merging fixes/fixes (e71ba9452f0b Linux 5.11-rc2) Merging kbuild-current/fixes (bcbcf50f5218 kbuild: fix ld-version.sh to not be affected by locale) Merging arc-current/for-curr (163630b2d95b arc: Fix typos/spellos) Merging arm-current/fixes (30e3b4f256b4 ARM: footbridge: fix PCI interrupt mapping) Merging arm64-fixes/for-next/fixes (738fa58ee132 arm64: kprobes: Restore local irqflag if kprobes is cancelled) Merging arm-soc-fixes/arm/fixes (b9a9786a13ea Merge tag 'omap-for-v5.12/fixes-rc6-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into arm/fixes) Merging drivers-memory-fixes/fixes (a38fd8748464 Linux 5.12-rc2) Merging m68k-current/for-linus (a65a802aadba m68k: Fix virt_addr_valid() W=1 compiler warnings) Merging powerpc-fixes/fixes (791f9e36599d powerpc/vdso: Make sure vdso_wrapper.o is rebuilt everytime vdso.so is rebuilt) Merging s390-fixes/fixes (a994eddb947e s390/entry: save the caller of psw_idle) Merging sparc/master (05a59d79793d Merge git://git.kernel.org:/pub/scm/linux/kernel/git/netdev/net) Merging fscrypt-current/for-stable (d19d8d345eec fscrypt: fix inline encryption not used on new files) Merging net/master (00423969d806 Revert "net: stmmac: re-init rx buffers when mac resume back") Merging bpf/master (afd0be729953 libbpf: Fix potential NULL pointer dereference) Merging ipsec/master (6628ddfec758 net: geneve: check skb is large enough for IPv4/IPv6 header) Merging netfilter/master (ccb39c628558 Merge git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf) Merging ipvs/master (fbea31808ca1 netfilter: conntrack: do not print icmpv6 as unknown via /proc) Merging wireless-drivers/master (65db391dd874 iwlwifi: mvm: fix beacon protection checks) Merging mac80211/master (864db232dc70 net: ipv6: check for validity before dereferencing cfg->fc_nlinfo.nlh) Merging rdma-fixes/for-rc (d434405aaab7 Linux 5.12-rc7) Merging sound-current/for-linus (c8426b2700b5 ALSA: hda/realtek: Fix speaker amp setup on Acer Aspire E1) Merging sound-asoc-fixes/for-linus (2077f5503437 Merge remote-tracking branch 'asoc/for-5.12' into asoc-linus) Merging regmap-fixes/for-linus (78d889705732 Merge remote-tracking branch 'regmap/for-5.12' into regmap-linus) Merging regulator-fixes/for-linus (6068cc31dedd Merge remote-tracking branch 'regulator/for-5.12' into regulator-linus) Merging spi-fixes/for-linus (c730b40940f9 Merge remote-tracking branch 'spi/for-5.12' into spi-linus) Merging pci-current/for-linus (cf673bd0cc97 PCI: switchtec: Fix Spectre v1 vulnerability) Merging driver-core.current/driver-core-linus (d434405aaab7 Linux 5.12-rc7) Merging
[PATCH v3 22/24] ARM: at91: sama7: introduce sama7 SoC family
From: Eugen Hristev
Introduce new family of SoCs, sama7, and first SoC, sama7g5.
Signed-off-by: Eugen Hristev
[claudiu.bez...@microchip.com: keep only the sama7_dt]
Signed-off-by: Claudiu Beznea
---
arch/arm/mach-at91/Makefile | 1 +
arch/arm/mach-at91/sama7.c | 32
2 files changed, 33 insertions(+)
create mode 100644 arch/arm/mach-at91/sama7.c
diff --git a/arch/arm/mach-at91/Makefile b/arch/arm/mach-at91/Makefile
index f565490f1b70..522b680b6446 100644
--- a/arch/arm/mach-at91/Makefile
+++ b/arch/arm/mach-at91/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_SOC_AT91RM9200)+= at91rm9200.o
obj-$(CONFIG_SOC_AT91SAM9) += at91sam9.o
obj-$(CONFIG_SOC_SAM9X60) += sam9x60.o
obj-$(CONFIG_SOC_SAMA5)+= sama5.o
+obj-$(CONFIG_SOC_SAMA7)+= sama7.o
obj-$(CONFIG_SOC_SAMV7)+= samv7.o
# Power Management
diff --git a/arch/arm/mach-at91/sama7.c b/arch/arm/mach-at91/sama7.c
new file mode 100644
index ..19d7bcbc97f1
--- /dev/null
+++ b/arch/arm/mach-at91/sama7.c
@@ -0,0 +1,32 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Setup code for SAMA7
+ *
+ * Copyright (C) 2021 Microchip Technology, Inc. and its subsidiaries
+ *
+ */
+
+#include
+#include
+
+#include
+#include
+
+#include "generic.h"
+
+static void __init sama7_dt_device_init(void)
+{
+ of_platform_default_populate(NULL, NULL, NULL);
+}
+
+static const char *const sama7_dt_board_compat[] __initconst = {
+ "microchip,sama7",
+ NULL
+};
+
+DT_MACHINE_START(sama7_dt, "Microchip SAMA7")
+ /* Maintainer: Microchip */
+ .init_machine = sama7_dt_device_init,
+ .dt_compat = sama7_dt_board_compat,
+MACHINE_END
+
--
2.25.1
[PATCH v3 23/24] ARM: at91: pm: add pm support for SAMA7G5
Add support for SAMA7G5 power management modes: standby, ulp0, ulp1, backup.
Signed-off-by: Claudiu Beznea
---
arch/arm/mach-at91/generic.h | 2 ++
arch/arm/mach-at91/pm.c | 37
arch/arm/mach-at91/sama7.c | 1 +
3 files changed, 40 insertions(+)
diff --git a/arch/arm/mach-at91/generic.h b/arch/arm/mach-at91/generic.h
index 0a4cdcb4985b..0c3960a8b3eb 100644
--- a/arch/arm/mach-at91/generic.h
+++ b/arch/arm/mach-at91/generic.h
@@ -14,12 +14,14 @@ extern void __init at91sam9_pm_init(void);
extern void __init sam9x60_pm_init(void);
extern void __init sama5_pm_init(void);
extern void __init sama5d2_pm_init(void);
+extern void __init sama7_pm_init(void);
#else
static inline void __init at91rm9200_pm_init(void) { }
static inline void __init at91sam9_pm_init(void) { }
static inline void __init sam9x60_pm_init(void) { }
static inline void __init sama5_pm_init(void) { }
static inline void __init sama5d2_pm_init(void) { }
+static inline void __init sama7_pm_init(void) { }
#endif
#endif /* _AT91_GENERIC_H */
diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
index f4e66a7c7d18..24d5fd06d487 100644
--- a/arch/arm/mach-at91/pm.c
+++ b/arch/arm/mach-at91/pm.c
@@ -152,6 +152,17 @@ static const struct of_device_id sam9x60_ws_ids[] = {
{ /* sentinel */ }
};
+static const struct of_device_id sama7g5_ws_ids[] = {
+ { .compatible = "atmel,at91sam9x5-rtc", .data = _info[1] },
+ { .compatible = "microchip,sama7g5-ohci", .data = _info[2] },
+ { .compatible = "usb-ohci", .data = _info[2] },
+ { .compatible = "atmel,at91sam9g45-ehci", .data = _info[2] },
+ { .compatible = "usb-ehci", .data = _info[2] },
+ { .compatible = "microchip,sama7g5-sdhci", .data = _info[3] },
+ { .compatible = "atmel,at91sam9260-rtt",.data = _info[4] },
+ { /* sentinel */ }
+};
+
static int at91_pm_config_ws(unsigned int pm_mode, bool set)
{
const struct wakeup_source_info *wsi;
@@ -1103,6 +1114,32 @@ void __init sama5d2_pm_init(void)
soc_pm.config_pmc_ws = at91_sama5d2_config_pmc_ws;
}
+void __init sama7_pm_init(void)
+{
+ static const int modes[] __initconst = {
+ AT91_PM_STANDBY, AT91_PM_ULP0, AT91_PM_ULP1, AT91_PM_BACKUP,
+ };
+ static const u32 iomaps[] __initconst = {
+ [AT91_PM_ULP0] = AT91_PM_IOMAP(SFRBU),
+ [AT91_PM_ULP1] = AT91_PM_IOMAP(SFRBU) |
+ AT91_PM_IOMAP(SHDWC),
+ [AT91_PM_BACKUP]= AT91_PM_IOMAP(SFRBU) |
+ AT91_PM_IOMAP(SHDWC),
+ };
+
+ if (!IS_ENABLED(CONFIG_SOC_SAMA7))
+ return;
+
+ at91_pm_modes_validate(modes, ARRAY_SIZE(modes));
+
+ at91_dt_ramc(true);
+ at91_pm_modes_init(iomaps, ARRAY_SIZE(iomaps));
+ at91_pm_init(NULL);
+
+ soc_pm.ws_ids = sama7g5_ws_ids;
+ soc_pm.config_pmc_ws = at91_sam9x60_config_pmc_ws;
+}
+
static int __init at91_pm_modes_select(char *str)
{
char *s;
diff --git a/arch/arm/mach-at91/sama7.c b/arch/arm/mach-at91/sama7.c
index 19d7bcbc97f1..bd43733ede18 100644
--- a/arch/arm/mach-at91/sama7.c
+++ b/arch/arm/mach-at91/sama7.c
@@ -17,6 +17,7 @@
static void __init sama7_dt_device_init(void)
{
of_platform_default_populate(NULL, NULL, NULL);
+ sama7_pm_init();
}
static const char *const sama7_dt_board_compat[] __initconst = {
--
2.25.1
Re: [PATCH 07/11] mm/page_alloc: Remove duplicate checks if migratetype should be isolated
On 4/15/21 11:33 AM, Mel Gorman wrote:
> On Wed, Apr 14, 2021 at 07:21:42PM +0200, Vlastimil Babka wrote:
>> On 4/14/21 3:39 PM, Mel Gorman wrote:
>> > Both free_pcppages_bulk() and free_one_page() have very similar
>> > checks about whether a page's migratetype has changed under the
>> > zone lock. Use a common helper.
>> >
>> > Signed-off-by: Mel Gorman
>>
>> Seems like for free_pcppages_bulk() this patch makes it check for each page
>> on
>> the pcplist
>> - zone->nr_isolate_pageblock != 0 instead of local bool (the performance
>> might
>> be the same I guess on modern cpu though)
>> - is_migrate_isolate(migratetype) for a migratetype obtained by
>> get_pcppage_migratetype() which cannot be migrate_isolate so the check is
>> useless.
>>
>> As such it doesn't seem a worthwhile cleanup to me considering all the other
>> microoptimisations?
>>
>
> The patch was a preparation patch for the rest of the series to avoid code
> duplication and to consolidate checks together in one place to determine
> if they are even correct.
>
> Until zone_pcp_disable() came along, it was possible to have isolated PCP
> pages in the lists even though zone->nr_isolate_pageblock could be 0 during
> memory hot-remove so the split in free_pcppages_bulk was not necessarily
> correct at all times.
>
> The remaining problem is alloc_contig_pages, it does not disable
> PCPs so both checks are necessary. If that also disabled PCPs
> then check_migratetype_isolated could be deleted but the cost to
> alloc_contig_pages might be too high.
I see. Well that's unfortunate if checking zone->nr_isolate_pageblock is not
sufficient, as it was supposed to be :(
But I don't think the check_migratetype_isolated() check was helping in such
scenario as it was, anyway.
It's testing this:
+ if (unlikely(has_isolate_pageblock(zone) ||
+ is_migrate_isolate(migratetype))) {
In the context of free_one_page(), the 'migratetype' variable holds a value
that's read from pageblock in one of the callers of free_one_page():
migratetype = get_pcppage_migratetype(page);
and because it's read outside of zone lock, it might be a MIGRATE_ISOLATE even
though after we obtain the zone lock, we might find out it's not anymore. This
is explained in commit ad53f92eb416 ("mm/page_alloc: fix incorrect isolation
behavior by rechecking migratetype") as scenario 1.
However, in the context of free_pcppages_bulk(), the migratetype we are checking
in check_migratetype_isolated() is this one:
int mt = get_pcppage_migratetype(page);
That was the one determined while adding the page to pcplist, and is stored in
the struct page and we know it's not MIGRATE_ISOLATE otherwise the page would
not go to pcplist. But by rechecking this stored value, we would not be finding
the case where the underlying pageblock's migratetype would change to
MIGRATE_ISOLATE, anyway...
> I'll delete this patch for now because it's relatively minor and there
> should be other ways of keeping the code duplication down.
>
[PATCH] extcon: maxim: Fix missing IRQF_ONESHOT as only threaded handler
From: Guangqing Zhu
Coccinelle noticed:
1. drivers/extcon/extcon-max14577.c:699:8-33: ERROR: Threaded IRQ with
no primary handler requested without IRQF_ONESHOT
2. drivers/extcon/extcon-max77693.c:1143:8-33: ERROR: Threaded IRQ with
no primary handler requested without IRQF_ONESHOT
3. drivers/extcon/extcon-max77843.c:907:8-33: ERROR: Threaded IRQ with
no primary handler requested without IRQF_ONESHOT
4. drivers/extcon/extcon-max8997.c:665:8-28: ERROR: Threaded IRQ with
no primary handler requested without IRQF_ONESHOT
Signed-off-by: Guangqing Zhu
---
drivers/extcon/extcon-max14577.c | 2 +-
drivers/extcon/extcon-max77693.c | 2 +-
drivers/extcon/extcon-max77843.c | 3 ++-
drivers/extcon/extcon-max8997.c | 2 +-
4 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/extcon/extcon-max14577.c b/drivers/extcon/extcon-max14577.c
index ace523924e58..af15a9e00ee9 100644
--- a/drivers/extcon/extcon-max14577.c
+++ b/drivers/extcon/extcon-max14577.c
@@ -698,7 +698,7 @@ static int max14577_muic_probe(struct platform_device *pdev)
ret = devm_request_threaded_irq(>dev, virq, NULL,
max14577_muic_irq_handler,
- IRQF_NO_SUSPEND,
+ IRQF_NO_SUSPEND | IRQF_ONESHOT,
muic_irq->name, info);
if (ret) {
dev_err(>dev,
diff --git a/drivers/extcon/extcon-max77693.c b/drivers/extcon/extcon-max77693.c
index 92af97e00828..4494eefce31f 100644
--- a/drivers/extcon/extcon-max77693.c
+++ b/drivers/extcon/extcon-max77693.c
@@ -1142,7 +1142,7 @@ static int max77693_muic_probe(struct platform_device
*pdev)
ret = devm_request_threaded_irq(>dev, virq, NULL,
max77693_muic_irq_handler,
- IRQF_NO_SUSPEND,
+ IRQF_NO_SUSPEND | IRQF_ONESHOT,
muic_irq->name, info);
if (ret) {
dev_err(>dev,
diff --git a/drivers/extcon/extcon-max77843.c b/drivers/extcon/extcon-max77843.c
index 8e6e97ec65a8..9167f99d2979 100644
--- a/drivers/extcon/extcon-max77843.c
+++ b/drivers/extcon/extcon-max77843.c
@@ -905,7 +905,8 @@ static int max77843_muic_probe(struct platform_device *pdev)
muic_irq->virq = virq;
ret = devm_request_threaded_irq(>dev, virq, NULL,
- max77843_muic_irq_handler, IRQF_NO_SUSPEND,
+ max77843_muic_irq_handler,
+ IRQF_NO_SUSPEND | IRQF_ONESHOT,
muic_irq->name, info);
if (ret) {
dev_err(>dev,
diff --git a/drivers/extcon/extcon-max8997.c b/drivers/extcon/extcon-max8997.c
index e1408075ef7d..8b5efbca15e3 100644
--- a/drivers/extcon/extcon-max8997.c
+++ b/drivers/extcon/extcon-max8997.c
@@ -664,7 +664,7 @@ static int max8997_muic_probe(struct platform_device *pdev)
ret = request_threaded_irq(virq, NULL,
max8997_muic_irq_handler,
- IRQF_NO_SUSPEND,
+ IRQF_NO_SUSPEND | IRQF_ONESHOT,
muic_irq->name, info);
if (ret) {
dev_err(>dev,
--
2.17.1
Re: [PATCH 1/1] perf map: Fix error return code in maps__clone()
On Thu, Apr 15, 2021 at 05:27:44PM +0800, Zhen Lei wrote:
> Although 'err' has been initialized to -ENOMEM, but it will be reassigned
> by the "err = unwind__prepare_access(...)" statement in the for loop. So
> that, the value of 'err' is unknown when map__clone() failed.
>
> Reported-by: Hulk Robot
> Signed-off-by: Zhen Lei
Acked-by: Jiri Olsa
thanks,
jirka
> ---
> tools/perf/util/map.c | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/tools/perf/util/map.c b/tools/perf/util/map.c
> index fbc40a2c17d4dca..8af693d9678cefe 100644
> --- a/tools/perf/util/map.c
> +++ b/tools/perf/util/map.c
> @@ -840,15 +840,18 @@ int maps__fixup_overlappings(struct maps *maps, struct
> map *map, FILE *fp)
> int maps__clone(struct thread *thread, struct maps *parent)
> {
> struct maps *maps = thread->maps;
> - int err = -ENOMEM;
> + int err;
> struct map *map;
>
> down_read(>lock);
>
> maps__for_each_entry(parent, map) {
> struct map *new = map__clone(map);
> - if (new == NULL)
> +
> + if (new == NULL) {
> + err = -ENOMEM;
> goto out_unlock;
> + }
>
> err = unwind__prepare_access(maps, new, NULL);
> if (err)
> --
> 2.26.0.106.g9fadedd
>
>
Re: [PATCH] platform/x86: intel_chtdc_ti_pwrbtn: Fix missing IRQF_ONESHOT as only threaded handler
Hi, On 4/15/21 11:14 AM, zhuguangqin...@gmail.com wrote: > From: Guangqing Zhu > > Coccinelle noticed: > drivers/platform/x86/intel_chtdc_ti_pwrbtn.c:59:7-32: ERROR: Threaded IRQ > with no primary handler requested without IRQF_ONESHOT > > Signed-off-by: Guangqing Zhu So I was wondering why this driver worked at all despite the missing flag. The reason that this still works is that the irqchip instantiated by the MFD driver for the CHT TI PMIC is using nested IRQ handling and then the request_irq error for this does not trigger. This is still the right thing to do though. I've tested that the driver still works after this. Thank you for your patch, I've applied this patch to my review-hans branch: https://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86.git/log/?h=review-hans Note it will show up in my review-hans branch once I've pushed my local branch there, which might take a while. Once I've run some tests on this branch the patches there will be added to the platform-drivers-x86/for-next branch and eventually will be included in the pdx86 pull-request to Linus for the next merge-window. Regards, Hans > --- > drivers/platform/x86/intel_chtdc_ti_pwrbtn.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/platform/x86/intel_chtdc_ti_pwrbtn.c > b/drivers/platform/x86/intel_chtdc_ti_pwrbtn.c > index 0df2e82dd249..9606a994af22 100644 > --- a/drivers/platform/x86/intel_chtdc_ti_pwrbtn.c > +++ b/drivers/platform/x86/intel_chtdc_ti_pwrbtn.c > @@ -58,7 +58,7 @@ static int chtdc_ti_pwrbtn_probe(struct platform_device > *pdev) > > err = devm_request_threaded_irq(dev, irq, NULL, > chtdc_ti_pwrbtn_interrupt, > - 0, KBUILD_MODNAME, input); > + IRQF_ONESHOT, KBUILD_MODNAME, input); > if (err) > return err; > >
Re: [PATCH][next] can: etas_es58x: Fix missing null check on netdev pointer
On 15.04.2021 20:42:36, Vincent MAILHOL wrote:
> On Thu. 15 Apr 2021 at 18:04, Marc Kleine-Budde wrote:
> > On 15.04.2021 09:47:23, Colin King wrote:
> > > From: Colin Ian King
> > >
> > > There is an assignment to *netdev that is can potentially be null but the
>^^
> Typo: that is can -> that can
Fixed.
> > > null check is checking netdev and not *netdev as intended. Fix this by
> > > adding in the missing * operator.
> > >
> > > Addresses-Coverity: ("Dereference before null check")
> > > Fixes: 8537257874e9 ("can: etas_es58x: add core support for ETAS ES58X
> > > CAN USB interfaces")
> > > Signed-off-by: Colin Ian King
>
> Acked-by: Vincent Mailhol
Added to the patch.
Tnx,
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Embedded Linux | https://www.pengutronix.de |
Vertretung West/Dortmund | Phone: +49-231-2826-924 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
signature.asc
Description: PGP signature
Re: [PATCH] mmc: sdhci-pci-gli: Enlarge ASPM L1 entry delay of GL975x
On Thu, 15 Apr 2021 at 05:23, Ben Chuang wrote:
>
> GL975x enters ASPM L1 state after a short idle in default.
> Enlarge the idle period to 7.9us for improving the R/W performance.
>
> Signed-off-by: Ben Chuang
Applied for next, thanks!
Kind regards
Uffe
> ---
> drivers/mmc/host/sdhci-pci-gli.c | 32
> 1 file changed, 32 insertions(+)
>
> diff --git a/drivers/mmc/host/sdhci-pci-gli.c
> b/drivers/mmc/host/sdhci-pci-gli.c
> index eb1ebb67e113..592d79082f58 100644
> --- a/drivers/mmc/host/sdhci-pci-gli.c
> +++ b/drivers/mmc/host/sdhci-pci-gli.c
> @@ -22,6 +22,10 @@
> #define GLI_9750_WT_EN_ON0x1
> #define GLI_9750_WT_EN_OFF 0x0
>
> +#define SDHCI_GLI_9750_CFG2 0x848
> +#define SDHCI_GLI_9750_CFG2_L1DLYGENMASK(28, 24)
> +#define GLI_9750_CFG2_L1DLY_VALUE0x1F
> +
> #define SDHCI_GLI_9750_DRIVING 0x860
> #define SDHCI_GLI_9750_DRIVING_1GENMASK(11, 0)
> #define SDHCI_GLI_9750_DRIVING_2GENMASK(27, 26)
> @@ -113,6 +117,10 @@
> #define PCI_GLI_9755_LFCLKGENMASK(14, 12)
> #define PCI_GLI_9755_DMACLK BIT(29)
>
> +#define PCI_GLI_9755_CFG2 0x48
> +#define PCI_GLI_9755_CFG2_L1DLYGENMASK(28, 24)
> +#define GLI_9755_CFG2_L1DLY_VALUE 0x1F
> +
> #define PCI_GLI_9755_PLL0x64
> #define PCI_GLI_9755_PLL_LDIV GENMASK(9, 0)
> #define PCI_GLI_9755_PLL_PDIV GENMASK(14, 12)
> @@ -408,6 +416,22 @@ static void sdhci_gl9750_set_clock(struct sdhci_host
> *host, unsigned int clock)
> sdhci_enable_clk(host, clk);
> }
>
> +static void gl9750_hw_setting(struct sdhci_host *host)
> +{
> + u32 value;
> +
> + gl9750_wt_on(host);
> +
> + value = sdhci_readl(host, SDHCI_GLI_9750_CFG2);
> + value &= ~SDHCI_GLI_9750_CFG2_L1DLY;
> + /* set ASPM L1 entry delay to 7.9us */
> + value |= FIELD_PREP(SDHCI_GLI_9750_CFG2_L1DLY,
> + GLI_9750_CFG2_L1DLY_VALUE);
> + sdhci_writel(host, value, SDHCI_GLI_9750_CFG2);
> +
> + gl9750_wt_off(host);
> +}
> +
> static void gli_pcie_enable_msi(struct sdhci_pci_slot *slot)
> {
> int ret;
> @@ -555,6 +579,13 @@ static void gl9755_hw_setting(struct sdhci_pci_slot
> *slot)
> value &= ~PCI_GLI_9755_SCP_DIS;
> pci_write_config_dword(pdev, PCI_GLI_9755_SerDes, value);
>
> + pci_read_config_dword(pdev, PCI_GLI_9755_CFG2, );
> + value &= ~PCI_GLI_9755_CFG2_L1DLY;
> + /* set ASPM L1 entry delay to 7.9us */
> + value |= FIELD_PREP(PCI_GLI_9755_CFG2_L1DLY,
> + GLI_9755_CFG2_L1DLY_VALUE);
> + pci_write_config_dword(pdev, PCI_GLI_9755_CFG2, value);
> +
> gl9755_wt_off(pdev);
> }
>
> @@ -562,6 +593,7 @@ static int gli_probe_slot_gl9750(struct sdhci_pci_slot
> *slot)
> {
> struct sdhci_host *host = slot->host;
>
> + gl9750_hw_setting(host);
> gli_pcie_enable_msi(slot);
> slot->host->mmc->caps2 |= MMC_CAP2_NO_SDIO;
> sdhci_enable_v4_mode(host);
> --
> 2.30.0
>
Re: [PATCH v1 0/2] Let sanitize not retry in case of timeout/failure
On Wed, 14 Apr 2021 at 23:22, Bean Huo wrote: > > From: Bean Huo > > > Bean Huo (2): > mmc: core: Add a retries parameter to __mmc_switch function > mmc: core: Let sanitize not retry in case of timeout/failure > > drivers/mmc/core/mmc.c | 22 +++--- > drivers/mmc/core/mmc_ops.c | 11 ++- > drivers/mmc/core/mmc_ops.h | 2 +- > 3 files changed, 18 insertions(+), 17 deletions(-) Applied for next, thanks! Kind regards Uffe
Re: [PATCH v2 1/3] mmc: sdhci-s3c: simplify getting of_device_id match data
On Thu, 15 Apr 2021 at 10:44, Krzysztof Kozlowski
wrote:
>
> Use of_device_get_match_data() to make the code slightly smaller and to
> remove the of_device_id table forward declaration.
>
> Signed-off-by: Krzysztof Kozlowski
Applied for next, thanks!
Kind regards
Uffe
>
> ---
>
> Changes since v1:
> 1. Rewrite the commit msg as it is not a NULL pointer dereference.
> ---
> drivers/mmc/host/sdhci-s3c.c | 12 +++-
> 1 file changed, 3 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci-s3c.c b/drivers/mmc/host/sdhci-s3c.c
> index f48a788a9d3d..8e1dca625620 100644
> --- a/drivers/mmc/host/sdhci-s3c.c
> +++ b/drivers/mmc/host/sdhci-s3c.c
> @@ -20,6 +20,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -461,19 +462,12 @@ static int sdhci_s3c_parse_dt(struct device *dev,
> }
> #endif
>
> -#ifdef CONFIG_OF
> -static const struct of_device_id sdhci_s3c_dt_match[];
> -#endif
> -
> static inline struct sdhci_s3c_drv_data *sdhci_s3c_get_driver_data(
> struct platform_device *pdev)
> {
> #ifdef CONFIG_OF
> - if (pdev->dev.of_node) {
> - const struct of_device_id *match;
> - match = of_match_node(sdhci_s3c_dt_match, pdev->dev.of_node);
> - return (struct sdhci_s3c_drv_data *)match->data;
> - }
> + if (pdev->dev.of_node)
> + return (struct sdhci_s3c_drv_data
> *)of_device_get_match_data(>dev);
> #endif
> return (struct sdhci_s3c_drv_data *)
> platform_get_device_id(pdev)->driver_data;
> --
> 2.25.1
>
Re: [PATCH v2 3/3] mmc: sdhci-s3c: constify uses of driver/match data
On Thu, 15 Apr 2021 at 10:44, Krzysztof Kozlowski
wrote:
>
> The driver data (struct sdhci_s3c_drv_data) stored in of_device_id
> table is allocated as const and used only in const-way. Skip
> unnecessary const-away casts and convert all users to work with pointer
> to const. This is both more logical and safer.
>
> Signed-off-by: Krzysztof Kozlowski
>
Applied for next, thanks!
Kind regards
Uffe
> ---
>
> Changes since v1:
> 1. None
> ---
> drivers/mmc/host/sdhci-s3c.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci-s3c.c b/drivers/mmc/host/sdhci-s3c.c
> index a07a8f011741..862f033d235d 100644
> --- a/drivers/mmc/host/sdhci-s3c.c
> +++ b/drivers/mmc/host/sdhci-s3c.c
> @@ -462,21 +462,21 @@ static int sdhci_s3c_parse_dt(struct device *dev,
> }
> #endif
>
> -static inline struct sdhci_s3c_drv_data *sdhci_s3c_get_driver_data(
> +static inline const struct sdhci_s3c_drv_data *sdhci_s3c_get_driver_data(
> struct platform_device *pdev)
> {
> #ifdef CONFIG_OF
> if (pdev->dev.of_node)
> - return (struct sdhci_s3c_drv_data
> *)of_device_get_match_data(>dev);
> + return of_device_get_match_data(>dev);
> #endif
> - return (struct sdhci_s3c_drv_data *)
> + return (const struct sdhci_s3c_drv_data *)
> platform_get_device_id(pdev)->driver_data;
> }
>
> static int sdhci_s3c_probe(struct platform_device *pdev)
> {
> struct s3c_sdhci_platdata *pdata;
> - struct sdhci_s3c_drv_data *drv_data;
> + const struct sdhci_s3c_drv_data *drv_data;
> struct device *dev = >dev;
> struct sdhci_host *host;
> struct sdhci_s3c *sc;
> @@ -761,7 +761,7 @@ static const struct platform_device_id
> sdhci_s3c_driver_ids[] = {
> MODULE_DEVICE_TABLE(platform, sdhci_s3c_driver_ids);
>
> #ifdef CONFIG_OF
> -static struct sdhci_s3c_drv_data exynos4_sdhci_drv_data = {
> +static const struct sdhci_s3c_drv_data exynos4_sdhci_drv_data = {
> .no_divider = true,
> };
>
> --
> 2.25.1
>
Re: [PATCH v2 2/3] mmc: sdhci-s3c: correct kerneldoc of sdhci_s3c_drv_data
On Thu, 15 Apr 2021 at 10:44, Krzysztof Kozlowski
wrote:
>
> Correct the name of sdhci_s3c_drv_data structure in kerneldoc:
>
> drivers/mmc/host/sdhci-s3c.c:143: warning:
> expecting prototype for struct sdhci_s3c_driver_data. Prototype was for
> struct sdhci_s3c_drv_data instead
>
> Signed-off-by: Krzysztof Kozlowski
>
Applied for next, thanks!
Kind regards
Uffe
> ---
>
> Changes since v1:
> 1. None
> ---
> drivers/mmc/host/sdhci-s3c.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/host/sdhci-s3c.c b/drivers/mmc/host/sdhci-s3c.c
> index 8e1dca625620..a07a8f011741 100644
> --- a/drivers/mmc/host/sdhci-s3c.c
> +++ b/drivers/mmc/host/sdhci-s3c.c
> @@ -130,7 +130,7 @@ struct sdhci_s3c {
> };
>
> /**
> - * struct sdhci_s3c_driver_data - S3C SDHCI platform specific driver data
> + * struct sdhci_s3c_drv_data - S3C SDHCI platform specific driver data
> * @sdhci_quirks: sdhci host specific quirks.
> * @no_divider: no or non-standard internal clock divider.
> *
> --
> 2.25.1
>
Re: [PATCH] memstick: r592: remove unused variable
On Wed, 14 Apr 2021 at 04:21, Jiapeng Chong
wrote:
>
> Fix the following clang warning:
>
> drivers/memstick/host/r592.c:363:6: warning: variable ‘len’ set but not
> used [-Wunused-but-set-variable].
>
> Reported-by: Abaci Robot
> Signed-off-by: Jiapeng Chong
Applied for next, thanks!
Kind regards
Uffe
> ---
> drivers/memstick/host/r592.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/memstick/host/r592.c b/drivers/memstick/host/r592.c
> index d2ef463..026fada 100644
> --- a/drivers/memstick/host/r592.c
> +++ b/drivers/memstick/host/r592.c
> @@ -360,12 +360,11 @@ static void r592_write_fifo_pio(struct r592_device *dev,
> static void r592_flush_fifo_write(struct r592_device *dev)
> {
> u8 buffer[4] = { 0 };
> - int len;
>
> if (kfifo_is_empty(>pio_fifo))
> return;
>
> - len = kfifo_out(>pio_fifo, buffer, 4);
> + kfifo_out(>pio_fifo, buffer, 4);
> r592_write_reg_raw_be(dev, R592_FIFO_PIO, *(u32 *)buffer);
> }
>
> --
> 1.8.3.1
>
Re: [PATCH 10/13] dt-bindings: mfd: add vref_ddr-supply to st,stpmic1 yaml
Hi Ahmad On 4/15/21 12:51 PM, Ahmad Fatoum wrote: Hi, On 15.04.21 12:10, Alexandre Torgue wrote: Add vref_ddr-supply to the STPMIC1 regulators supplies pattern list. Signed-off-by: Alexandre Torgue diff --git a/Documentation/devicetree/bindings/mfd/st,stpmic1.yaml b/Documentation/devicetree/bindings/mfd/st,stpmic1.yaml index 305123e74a58..ffc32d209496 100644 --- a/Documentation/devicetree/bindings/mfd/st,stpmic1.yaml +++ b/Documentation/devicetree/bindings/mfd/st,stpmic1.yaml @@ -184,7 +184,7 @@ properties: additionalProperties: false patternProperties: - "^(buck[1-4]|ldo[1-6]|boost|pwr_sw[1-2])-supply$": + "^(buck[1-4]|ldo[1-6]|boost|vref_ddr|pwr_sw[1-2])-supply$": IIRC, vref-ddr was a hack because a change in the regulator core broke the STM32MP1 boards. I believe vref-ddr should be removed altogether instead. It's supplied from BUCK2IN, which is already in the binding, so it's redundant. Correct I forgot this point. We got random crash without this vddr_ref_supply but I don't know if regulator FW has been updated to fix it. If yes, I'll drop this one and remove vddr_ref_supply from DT file. Cheers, Ahmad description: STPMIC1 voltage regulators supplies "^(buck[1-4]|ldo[1-6]|boost|vref_ddr|pwr_sw[1-2])$":
[PATCH v4 2/7] dt-bindings: media: max9286: Define 'maxim,gpio-poc'
Define a new vendor property in the maxim,max9286 binding schema.
The new property allows to declare that the remote camera
power-over-coax is controlled by one of the MAX9286 gpio lines.
As it is currently not possible to establish a regulator as consumer
of the MAX9286 gpio controller for this purpose, the property allows to
declare that the camera power is controlled by the MAX9286 directly.
The property accepts a gpio-index (0 or 1) and one line polarity
flag as defined by dt-bindings/gpio/gpio.h.
Reviewed-by: Laurent Pinchart
Signed-off-by: Jacopo Mondi
---
.../bindings/media/i2c/maxim,max9286.yaml | 71 ++-
1 file changed, 70 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml
b/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml
index 0e7162998b77..e2422241b7d0 100644
--- a/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml
@@ -70,6 +70,28 @@ properties:
a remote serializer whose high-threshold noise immunity is not enabled
is 10 micro volts
+ maxim,gpio-poc:
+$ref: '/schemas/types.yaml#/definitions/uint32-array'
+minItems: 2
+maxItems: 2
+description: |
+ Index of the MAX9286 gpio output line (0 or 1) that controls Power over
+ Coax to the cameras and its associated polarity flag.
+
+ The property accepts an array of two unsigned integers, the first being
+ the gpio line index (0 or 1) and the second being the gpio line polarity
+ flag (GPIO_ACTIVE_HIGH or GPIO_ACTIVE_LOW) as defined in
+ .
+
+ When the remote cameras power is controlled by one of the MAX9286 gpio
+ lines, this property has to be used to specify which line among the two
+ available ones controls the remote camera power enablement.
+
+ When this property is used it is not possible to register a gpio
+ controller as the gpio lines are controlled directly by the MAX9286 and
+ not available for consumers, nor the 'poc-supply' property should be
+ specified.
+
ports:
$ref: /schemas/graph.yaml#/properties/ports
@@ -182,7 +204,20 @@ required:
- reg
- ports
- i2c-mux
- - gpio-controller
+
+# If 'maxim,gpio-poc' is present, then 'poc-supply' and 'gpio-controller'
+# are not allowed.
+if:
+ required:
+- maxim,gpio-poc
+then:
+ allOf:
+- not:
+required:
+ - poc-supply
+- not:
+required:
+ - gpio-controller
additionalProperties: false
@@ -327,4 +362,38 @@ examples:
};
};
};
+
+/*
+* Example of a deserializer that controls the camera Power over Coax
+* through one of its gpio lines.
+*/
+gmsl-deserializer@6c {
+compatible = "maxim,max9286";
+reg = <0x6c>;
+enable-gpios = < 14 GPIO_ACTIVE_HIGH>;
+
+/*
+* The remote camera power is controlled by MAX9286 GPIO line #0.
+* No 'poc-supply' nor 'gpio-controller' are specified.
+*/
+maxim,gpio-poc = <0 GPIO_ACTIVE_LOW>;
+
+/*
+* Do not describe connections as they're the same as in the
previous
+* example.
+*/
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@4 {
+reg = <4>;
+};
+};
+
+i2c-mux {
+#address-cells = <1>;
+#size-cells = <0>;
+};
+};
};
--
2.31.1
Re: [PATCH 09/11] mm/page_alloc: Avoid conflating IRQs disabled with zone->lock
On 4/14/21 3:39 PM, Mel Gorman wrote:
> Historically when freeing pages, free_one_page() assumed that callers
> had IRQs disabled and the zone->lock could be acquired with spin_lock().
> This confuses the scope of what local_lock_irq is protecting and what
> zone->lock is protecting in free_unref_page_list in particular.
>
> This patch uses spin_lock_irqsave() for the zone->lock in
> free_one_page() instead of relying on callers to have disabled
> IRQs. free_unref_page_commit() is changed to only deal with PCP pages
> protected by the local lock. free_unref_page_list() then first frees
> isolated pages to the buddy lists with free_one_page() and frees the rest
> of the pages to the PCP via free_unref_page_commit(). The end result
> is that free_one_page() is no longer depending on side-effects of
> local_lock to be correct.
>
> Note that this may incur a performance penalty while memory hot-remove
> is running but that is not a common operation.
>
> Signed-off-by: Mel Gorman
Acked-by: Vlastimil Babka
A nit below:
> @@ -3294,6 +3295,7 @@ void free_unref_page_list(struct list_head *list)
> struct page *page, *next;
> unsigned long flags, pfn;
> int batch_count = 0;
> + int migratetype;
>
> /* Prepare pages for freeing */
> list_for_each_entry_safe(page, next, list, lru) {
> @@ -3301,15 +3303,28 @@ void free_unref_page_list(struct list_head *list)
> if (!free_unref_page_prepare(page, pfn))
> list_del(>lru);
> set_page_private(page, pfn);
Should probably move this below so we don't set private for pages that then go
through free_one_page()? Doesn't seem to be a bug, just unneccessary.
> +
> + /*
> + * Free isolated pages directly to the allocator, see
> + * comment in free_unref_page.
> + */
> + migratetype = get_pcppage_migratetype(page);
> + if (unlikely(migratetype >= MIGRATE_PCPTYPES)) {
> + if (unlikely(is_migrate_isolate(migratetype))) {
> + free_one_page(page_zone(page), page, pfn, 0,
> + migratetype, FPI_NONE);
> + list_del(>lru);
> + }
> + }
> }
>
> local_lock_irqsave(, flags);
> list_for_each_entry_safe(page, next, list, lru) {
> - unsigned long pfn = page_private(page);
> -
> + pfn = page_private(page);
> set_page_private(page, 0);
> + migratetype = get_pcppage_migratetype(page);
> trace_mm_page_free_batched(page);
> - free_unref_page_commit(page, pfn);
> + free_unref_page_commit(page, pfn, migratetype);
>
> /*
>* Guard against excessive IRQ disabled times when we get
>
[PATCH v4 4/7] arm64: dts: renesas: r8a77970: Add csi40 port@0
Declare port@0 in the csi40 device node and leave it un-connected.
Each board .dts file will connect the port as it requires.
Signed-off-by: Jacopo Mondi
---
arch/arm64/boot/dts/renesas/r8a77970.dtsi | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a77970.dtsi
b/arch/arm64/boot/dts/renesas/r8a77970.dtsi
index 5a5d5649332a..e8f6352c3665 100644
--- a/arch/arm64/boot/dts/renesas/r8a77970.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77970.dtsi
@@ -1106,6 +1106,10 @@ ports {
#address-cells = <1>;
#size-cells = <0>;
+ port@0 {
+ reg = <0>;
+ };
+
port@1 {
#address-cells = <1>;
#size-cells = <0>;
--
2.31.1
[PATCH v4 5/7] arm64: dts: renesas: eagle: Enable MAX9286
From: Kieran Bingham
Enable the MAX9286 GMSL deserializer on the Eagle-V3M board.
Connected cameras should be defined in a device-tree overlay or included
after these definitions.
Reviewed-by: Laurent Pinchart
Signed-off-by: Kieran Bingham
Signed-off-by: Jacopo Mondi
---
.../arm64/boot/dts/renesas/r8a77970-eagle.dts | 106 ++
1 file changed, 106 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
b/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
index 874a7fc2730b..ab35202857f5 100644
--- a/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
+++ b/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
@@ -6,6 +6,8 @@
* Copyright (C) 2017 Cogent Embedded, Inc.
*/
+#include
+
/dts-v1/;
#include "r8a77970.dtsi"
@@ -188,6 +190,11 @@ i2c0_pins: i2c0 {
function = "i2c0";
};
+ i2c3_pins: i2c3 {
+ groups = "i2c3_a";
+ function = "i2c3";
+ };
+
qspi0_pins: qspi0 {
groups = "qspi0_ctrl", "qspi0_data4";
function = "qspi0";
@@ -266,6 +273,105 @@ {
status = "okay";
};
+ {
+ status = "okay";
+
+ ports {
+ port@0 {
+ csi40_in: endpoint {
+ clock-lanes = <0>;
+ data-lanes = <1 2 3 4>;
+ remote-endpoint = <_out0>;
+ };
+ };
+ };
+};
+
+ {
+ pinctrl-0 = <_pins>;
+ pinctrl-names = "default";
+
+ status = "okay";
+ clock-frequency = <40>;
+
+ gmsl: gmsl-deserializer@48 {
+ compatible = "maxim,max9286";
+ reg = <0x48>;
+
+ maxim,gpio-poc = <0 GPIO_ACTIVE_LOW>;
+
+ /* eagle-pca9654-max9286-pwdn */
+ enable-gpios = <_expander 0 GPIO_ACTIVE_HIGH>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ };
+
+ port@1 {
+ reg = <1>;
+ };
+
+ port@2 {
+ reg = <2>;
+ };
+
+ port@3 {
+ reg = <3>;
+ };
+
+ port@4 {
+ reg = <4>;
+ max9286_out0: endpoint {
+ clock-lanes = <0>;
+ data-lanes = <1 2 3 4>;
+ remote-endpoint = <_in>;
+ };
+ };
+ };
+
+ i2c-mux {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ i2c@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ status = "disabled";
+ };
+
+ i2c@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ status = "disabled";
+ };
+
+ i2c@2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <2>;
+
+ status = "disabled";
+ };
+
+ i2c@3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <3>;
+
+ status = "disabled";
+ };
+ };
+ };
+};
+
{
pinctrl-0 = <_pins>;
pinctrl-names = "default";
--
2.31.1
[PATCH v4 1/7] dt-bindings: media: max9286: Re-indent example
The dt-bindings examples are usually indented with 4 spaces.
The maxim,max9286 schema has the example indented with only
2 spaces, re-indent it.
Cosmetic change only.
Signed-off-by: Jacopo Mondi
---
.../bindings/media/i2c/maxim,max9286.yaml | 214 +-
1 file changed, 107 insertions(+), 107 deletions(-)
diff --git a/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml
b/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml
index ee16102fdfe7..0e7162998b77 100644
--- a/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml
@@ -191,140 +191,140 @@ examples:
#include
i2c@e66d8000 {
- #address-cells = <1>;
- #size-cells = <0>;
+#address-cells = <1>;
+#size-cells = <0>;
- reg = <0 0xe66d8000>;
+reg = <0 0xe66d8000>;
- gmsl-deserializer@2c {
-compatible = "maxim,max9286";
-reg = <0x2c>;
-poc-supply = <_poc_12v>;
-enable-gpios = < 13 GPIO_ACTIVE_HIGH>;
+gmsl-deserializer@2c {
+compatible = "maxim,max9286";
+reg = <0x2c>;
+poc-supply = <_poc_12v>;
+enable-gpios = < 13 GPIO_ACTIVE_HIGH>;
-gpio-controller;
-#gpio-cells = <2>;
+gpio-controller;
+#gpio-cells = <2>;
-maxim,reverse-channel-microvolt = <17>;
+maxim,reverse-channel-microvolt = <17>;
-ports {
- #address-cells = <1>;
- #size-cells = <0>;
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
- port@0 {
-reg = <0>;
+port@0 {
+reg = <0>;
-max9286_in0: endpoint {
- remote-endpoint = <_out0>;
-};
- };
-
- port@1 {
-reg = <1>;
-
-max9286_in1: endpoint {
- remote-endpoint = <_out1>;
-};
- };
-
- port@2 {
-reg = <2>;
-
-max9286_in2: endpoint {
- remote-endpoint = <_out2>;
-};
- };
+max9286_in0: endpoint {
+remote-endpoint = <_out0>;
+};
+};
- port@3 {
-reg = <3>;
+port@1 {
+reg = <1>;
-max9286_in3: endpoint {
- remote-endpoint = <_out3>;
-};
- };
+max9286_in1: endpoint {
+remote-endpoint = <_out1>;
+};
+};
- port@4 {
-reg = <4>;
+port@2 {
+reg = <2>;
-max9286_out: endpoint {
- data-lanes = <1 2 3 4>;
- remote-endpoint = <_in>;
-};
- };
-};
+max9286_in2: endpoint {
+remote-endpoint = <_out2>;
+};
+};
-i2c-mux {
- #address-cells = <1>;
- #size-cells = <0>;
+port@3 {
+reg = <3>;
- i2c@0 {
-#address-cells = <1>;
-#size-cells = <0>;
-reg = <0>;
+max9286_in3: endpoint {
+remote-endpoint = <_out3>;
+};
+};
-camera@51 {
- compatible = "imi,rdacm20";
- reg = <0x51>, <0x61>;
+port@4 {
+reg = <4>;
- port {
-rdacm20_out0: endpoint {
- remote-endpoint = <_in0>;
+max9286_out: endpoint {
+data-lanes = <1 2 3 4>;
+remote-endpoint = <_in>;
+};
};
- };
-
};
- };
-
- i2c@1 {
-#address-cells = <1>;
-#size-cells = <0>;
-reg = <1>;
-camera@52 {
- compatible = "imi,rdacm20";
- reg = <0x52>, <0x62>;
+i2c-mux {
+#address-cells = <1>;
+#size-cells = <0>;
- port {
-rdacm20_out1: endpoint {
- remote-endpoint = <_in1>;
-};
- };
-};
- };
+i2c@0 {
+#address-cells = <1>;
+#size-cells = <0>;
+reg = <0>;
- i2c@2 {
-#address-cells = <1>;
-#size-cells = <0>;
-reg = <2>;
+camera@51 {
+compatible = "imi,rdacm20";
+reg = <0x51>, <0x61>;
-camera@53 {
- compatible = "imi,rdacm20";
- reg = <0x53>,
[PATCH v4 3/7] media: i2c: max9286: Use "maxim,gpio-poc" property
The 'maxim,gpio-poc' property is used when the remote camera
power-over-coax is controlled by one of the MAX9286 gpio lines,
to instruct the driver about which line to use and what the line
polarity is.
Add to the max9286 driver support for parsing the newly introduced
property and use it if available in place of the usual supply, as it is
not possible to establish one as consumer of the max9286 gpio
controller.
If the new property is present, no gpio controller is registered and
'poc-supply' is ignored.
In order to maximize code re-use, break out the max9286 gpio handling
function so that they can be used by the gpio controller through the
gpio-consumer API, or directly by the driver code.
Wrap the power up and power down routines to their own function to
be able to use either the gpio line directly or the supply. This will
make it easier to control the remote camera power at run time.
Signed-off-by: Jacopo Mondi
---
drivers/media/i2c/max9286.c | 119
1 file changed, 93 insertions(+), 26 deletions(-)
diff --git a/drivers/media/i2c/max9286.c b/drivers/media/i2c/max9286.c
index 6fd4d59fcc72..a8b37783d2ef 100644
--- a/drivers/media/i2c/max9286.c
+++ b/drivers/media/i2c/max9286.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -165,6 +166,9 @@ struct max9286_priv {
u32 reverse_channel_mv;
+ u32 gpio_poc;
+ u32 gpio_poc_flags;
+
struct v4l2_ctrl_handler ctrls;
struct v4l2_ctrl *pixelrate;
@@ -1022,8 +1026,19 @@ static int max9286_setup(struct max9286_priv *priv)
return 0;
}
-static void max9286_gpio_set(struct gpio_chip *chip,
-unsigned int offset, int value)
+static int max9286_gpio_set(struct max9286_priv *priv, unsigned int offset,
+ int value)
+{
+ int ret = max9286_read(priv, 0x0f);
+ if (ret < 0)
+ return ret;
+
+ ret = value ? (ret & 0x3) | BIT(offset) : (ret & 0x3) & ~BIT(offset);
+ return max9286_write(priv, 0x0f, MAX9286_0X0F_RESERVED | ret);
+}
+
+static void max9286_gpiochip_set(struct gpio_chip *chip,
+unsigned int offset, int value)
{
struct max9286_priv *priv = gpiochip_get_data(chip);
@@ -1035,7 +1050,7 @@ static void max9286_gpio_set(struct gpio_chip *chip,
max9286_write(priv, 0x0f, MAX9286_0X0F_RESERVED | priv->gpio_state);
}
-static int max9286_gpio_get(struct gpio_chip *chip, unsigned int offset)
+static int max9286_gpiochip_get(struct gpio_chip *chip, unsigned int offset)
{
struct max9286_priv *priv = gpiochip_get_data(chip);
@@ -1055,8 +1070,8 @@ static int max9286_register_gpio(struct max9286_priv
*priv)
gpio->of_node = dev->of_node;
gpio->ngpio = 2;
gpio->base = -1;
- gpio->set = max9286_gpio_set;
- gpio->get = max9286_gpio_get;
+ gpio->set = max9286_gpiochip_set;
+ gpio->get = max9286_gpiochip_get;
gpio->can_sleep = true;
/* GPIO values default to high */
@@ -1069,6 +1084,71 @@ static int max9286_register_gpio(struct max9286_priv
*priv)
return ret;
}
+static int max9286_parse_gpios(struct max9286_priv *priv)
+{
+ struct device *dev = >client->dev;
+ u32 gpio_poc[2];
+ int ret;
+
+ /*
+* Parse the "gpio-poc" vendor property. If the camera power is
+* controlled by one of the MAX9286 gpio lines, do not register
+* the gpio controller and ignore 'poc-supply'.
+*/
+ ret = of_property_read_u32_array(dev->of_node,
+"maxim,gpio-poc", gpio_poc, 2);
+ if (!ret) {
+ priv->gpio_poc = gpio_poc[0];
+ priv->gpio_poc_flags = gpio_poc[1];
+ if (priv->gpio_poc > 1 ||
+ (priv->gpio_poc_flags != GPIO_ACTIVE_HIGH &&
+priv->gpio_poc_flags != GPIO_ACTIVE_LOW)) {
+ dev_err(dev, "Invalid 'gpio-poc': (%u %u)\n",
+ priv->gpio_poc, priv->gpio_poc_flags);
+ return -EINVAL;
+ }
+
+ return 0;
+ }
+
+ ret = max9286_register_gpio(priv);
+ if (ret)
+ return ret;
+
+ priv->regulator = devm_regulator_get(dev, "poc");
+ if (IS_ERR(priv->regulator)) {
+ if (PTR_ERR(priv->regulator) != -EPROBE_DEFER)
+ dev_err(dev, "Unable to get PoC regulator (%ld)\n",
+ PTR_ERR(priv->regulator));
+ return PTR_ERR(priv->regulator);
+ }
+
+ return 0;
+}
+
+static int max9286_poc_enable(struct max9286_priv *priv, bool enable)
+{
+ int ret;
+
+ /* If "poc-gpio" is used, toggle the line and do not use regulator. */
+ if (enable)
+ ret = priv->regulator
+ ? regulator_enable(priv->regulator)
+
[PATCH v4 7/7] DNI: arm64: dts: renesas: eagle: Include eagle-gmsl
From: Kieran Bingham
Include the eagle-gmsl.dtsi to enable GMSL camera support on the
Eagle-V3M platform.
Signed-off-by: Kieran Bingham
Signed-off-by: Jacopo Mondi
---
arch/arm64/boot/dts/renesas/r8a77970-eagle.dts | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
b/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
index ab35202857f5..a87d4b7f17c7 100644
--- a/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
+++ b/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
@@ -378,3 +378,11 @@ {
status = "okay";
};
+
+/* FAKRA Overlay */
+#define GMSL_CAMERA_RDACM21
+#define GMSL_CAMERA_0
+#define GMSL_CAMERA_1
+#define GMSL_CAMERA_2
+#define GMSL_CAMERA_3
+#include "eagle-gmsl.dtsi"
--
2.31.1
[PATCH v4 6/7] arm64: dts: renesas: eagle: Add GMSL .dtsi
From: Kieran Bingham
Describe the FAKRA connector available on Eagle board that allows
connecting GMSL camera modules such as IMI RDACM20 and RDACM21.
Signed-off-by: Kieran Bingham
Signed-off-by: Jacopo Mondi
---
arch/arm64/boot/dts/renesas/eagle-gmsl.dtsi | 178
1 file changed, 178 insertions(+)
create mode 100644 arch/arm64/boot/dts/renesas/eagle-gmsl.dtsi
diff --git a/arch/arm64/boot/dts/renesas/eagle-gmsl.dtsi
b/arch/arm64/boot/dts/renesas/eagle-gmsl.dtsi
new file mode 100644
index ..d2e48dc3e820
--- /dev/null
+++ b/arch/arm64/boot/dts/renesas/eagle-gmsl.dtsi
@@ -0,0 +1,178 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Device Tree Source (overlay) for the Eagle V3M GMSL connectors
+ *
+ * Copyright (C) 2017 Ideas on Board
+ * Copyright (C) 2021 Jacopo Mondi
+ *
+ * This overlay allows you to define GMSL cameras connected to the FAKRA
+ * connectors on the Eagle-V3M (or compatible) board.
+ *
+ * The following cameras are currently supported: RDACM20 and RDACM21.
+ *
+ * The board .dts files that include this select which cameras are in use
+ * by specifying the camera model with:
+ *
+ * #define GMSL_CAMERA_RDACM20
+ * or
+ * #define GMSL_CAMERA_RDACM21
+ *
+ * And which cameras are connected to the board by defining:
+ * #define GMSL_CAMERA_0
+ * #define GMSL_CAMERA_1
+ * #define GMSL_CAMERA_2
+ * #define GMSL_CAMERA_3
+ */
+
+#include
+
+/* Validate the board file settings. */
+#if !defined(GMSL_CAMERA_RDACM20) && !defined(GMSL_CAMERA_RDACM21)
+#error "Camera model should be defined by the board file"
+#endif
+
+#if defined(GMSL_CAMERA_RDACM20) && defined(GMSL_CAMERA_RDACM21)
+#error "A single camera model should be selected"
+#endif
+
+#if !defined(GMSL_CAMERA_0) && !defined(GMSL_CAMERA_1) && \
+!defined(GMSL_CAMERA_2) && !defined(GMSL_CAMERA_3)
+#error "At least one camera should be selected"
+#endif
+
+#if defined(GMSL_CAMERA_RDACM20)
+#define GMSL_CAMERA_MODEL "imi,rdacm20"
+#elif defined(GMSL_CAMERA_RDACM21)
+#define GMSL_CAMERA_MODEL "imi,rdacm21"
+#endif
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+
+#if defined(GMSL_CAMERA_RDACM21)
+ maxim,reverse-channel-microvolt = <10>;
+#endif
+
+ ports {
+#ifdef GMSL_CAMERA_0
+ port@0 {
+ max9286_in0: endpoint {
+ remote-endpoint = <_con0>;
+ };
+ };
+#endif
+
+#ifdef GMSL_CAMERA_1
+ port@1 {
+ max9286_in1: endpoint{
+ remote-endpoint = <_con1>;
+ };
+
+ };
+#endif
+
+#ifdef GMSL_CAMERA_2
+ port@2 {
+ max9286_in2: endpoint {
+ remote-endpoint = <_con2>;
+ };
+
+ };
+#endif
+
+#ifdef GMSL_CAMERA_3
+ port@3 {
+ max9286_in3: endpoint {
+ remote-endpoint = <_con3>;
+ };
+
+ };
+#endif
+ };
+
+ i2c-mux {
+#ifdef GMSL_CAMERA_0
+ i2c@0 {
+ status = "okay";
+
+ camera@51 {
+ compatible = GMSL_CAMERA_MODEL;
+ reg = <0x51>, <0x61>;
+
+ port {
+ fakra_con0: endpoint {
+ remote-endpoint =
<_in0>;
+ };
+ };
+ };
+ };
+#endif
+
+#ifdef GMSL_CAMERA_1
+ i2c@1 {
+ status = "okay";
+
+ camera@52 {
+ compatible = GMSL_CAMERA_MODEL;
+ reg = <0x52>, <0x62>;
+
+ port {
+ fakra_con1: endpoint {
+ remote-endpoint =
<_in1>;
+ };
+ };
+ };
+ };
+#endif
+
+#ifdef GMSL_CAMERA_2
+ i2c@2 {
+ status = "okay";
+
+ camera@53 {
+ compatible = GMSL_CAMERA_MODEL;
+ reg = <0x53>, <0x63>;
+
+ port {
+ fakra_con2: endpoint {
+ remote-endpoint =
<_in2>;
+ };
+ };
+ };
+ };
+#endif
+
+#ifdef GMSL_CAMERA_3
+ i2c@3 {
+ status = "okay";
+
+
RE: [PATCH 1/5] xattr: Complete constify ->name member of "struct xattr"
> From: Tetsuo Handa [mailto:penguin-ker...@i-love.sakura.ne.jp]
> Sent: Thursday, April 15, 2021 1:20 PM
> On 2021/04/15 19:04, Roberto Sassu wrote:
> > This patch completes commit 9548906b2bb7 ('xattr: Constify ->name
> member of
> > "struct xattr"'). It fixes the documentation of the inode_init_security
> > hook, by removing the xattr name from the objects that are expected to
> be
> > allocated by LSMs (only the value is allocated). Also, it removes the
> > kfree() of name and setting it to NULL in the reiserfs code.
>
> Good catch, but well, grep does not find any reiserfs_security_free() callers.
> Is reiserfs_security_free() a dead code?
Uhm, I also don't see it.
Thanks
Roberto
HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063
Managing Director: Li Peng, Li Jian, Shi Yanli
Re: [RFC PATCH] USB:XHCI:skip hub registration
On Thu, Apr 15, 2021 at 08:22:38PM +0800, Longfang Liu wrote:
> When the number of ports on the USB hub is 0, skip the registration
> operation of the USB hub.
That's crazy. Why not fix the hardware? How has this hub passed the
USB certification process?
> The current Kunpeng930's XHCI hardware controller is defective. The number
> of ports on its USB3.0 bus controller is 0, and the number of ports on
> the USB2.0 bus controller is 1.
>
> In order to solve this problem that the USB3.0 controller does not have
> a port which causes the registration of the hub to fail, this patch passes
> the defect information by adding flags in the quirks of xhci and usb_hcd,
> and finally skips the registration process of the hub directly according
> to the results of these flags when the hub is initialized.
>
> Signed-off-by: Longfang Liu
> ---
> drivers/usb/core/hub.c | 6 ++
> drivers/usb/host/xhci-pci.c | 4
> drivers/usb/host/xhci.c | 5 +
> drivers/usb/host/xhci.h | 1 +
> include/linux/usb/hcd.h | 1 +
> 5 files changed, 17 insertions(+)
>
> diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
> index b1e14be..2d6869d 100644
> --- a/drivers/usb/core/hub.c
> +++ b/drivers/usb/core/hub.c
> @@ -1769,9 +1769,15 @@ static int hub_probe(struct usb_interface *intf, const
> struct usb_device_id *id)
> struct usb_host_interface *desc;
> struct usb_device *hdev;
> struct usb_hub *hub;
> + struct usb_hcd *hcd;
>
> desc = intf->cur_altsetting;
> hdev = interface_to_usbdev(intf);
> + hcd = bus_to_hcd(hdev->bus);
> + if (hcd->usb3_no_port) {
> + dev_warn(>dev, "USB hub has no port\n");
> + return -ENODEV;
> + }
>
> /*
>* Set default autosuspend delay as 0 to speedup bus suspend,
> diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
> index ef513c2..63b89a4 100644
> --- a/drivers/usb/host/xhci-pci.c
> +++ b/drivers/usb/host/xhci-pci.c
> @@ -281,6 +281,10 @@ static void xhci_pci_quirks(struct device *dev, struct
> xhci_hcd *xhci)
> if (xhci->quirks & XHCI_RESET_ON_RESUME)
> xhci_dbg_trace(xhci, trace_xhci_dbg_quirks,
> "QUIRK: Resetting on resume");
> +
> + if (pdev->vendor == PCI_VENDOR_ID_HUAWEI &&
> + pdev->device == 0xa23c)
> + xhci->quirks |= XHCI_USB3_NOPORT;
Can't we just detect this normally that there are no ports for this
device? Why is the device lying about how many ports it has such that
we have to "override" this?
And again, why not fix this broken hardware?
thanks,
greg k-h
Re: [PATCH v2 7/9] sched,debug: Convert sysctl sched_domains to debugfs
On 15/04/21 11:06, Peter Zijlstra wrote:
> On Tue, Apr 13, 2021 at 03:55:15PM +0100, Valentin Schneider wrote:
>> On 12/04/21 12:14, Peter Zijlstra wrote:
>> > Stop polluting sysctl, move to debugfs for SCHED_DEBUG stuff.
>> >
>> > Signed-off-by: Peter Zijlstra (Intel)
>> > Reviewed-by: Dietmar Eggemann
>>
>> On my Juno (2+4 big.LITTLE), sys/kernel/debug/sched/domains/ is now empty.
>>
>> I think that's because of unregister_sched_domain_sysctl() -
>> debugfs_remove() is recursive, and I do get a case where we rebuild the
>> domains but no CPU has been added or removed (we rebuild the domains when
>> cpufreq kicks in, it's part of the big.LITTLE ponies).
>>
>> Do we actually still need that unregister? From a brief glance it looks
>> like we could throw it out.
>
> Yeah, I can't think of anything either. AFAICT it hasn't done anything
> useful since that cpumask optimization. Consider it gone.
>
> I'll let it soak for another day or so, but then I was planning on
> merging this series.
>
> Updated patch has been in queue.git/sched/debug since yesterday.
>
> ---
> Subject: sched,debug: Convert sysctl sched_domains to debugfs
> From: Peter Zijlstra
> Date: Thu Mar 25 11:31:20 CET 2021
>
> Stop polluting sysctl, move to debugfs for SCHED_DEBUG stuff.
>
> Signed-off-by: Peter Zijlstra (Intel)
> Reviewed-by: Dietmar Eggemann
> ---
> kernel/sched/debug.c| 254
> ++--
> kernel/sched/sched.h|6 -
> kernel/sched/topology.c |6 -
> 3 files changed, 56 insertions(+), 210 deletions(-)
>
> --- a/kernel/sched/debug.c
> +++ b/kernel/sched/debug.c
> @@ -299,6 +299,10 @@ static __init int sched_init_debug(void)
> debugfs_create_file("tunable_scaling", 0644, debugfs_sched, NULL,
> _scaling_fops);
> debugfs_create_u32("migration_cost_ns", 0644, debugfs_sched,
> _sched_migration_cost);
> debugfs_create_u32("nr_migrate", 0644, debugfs_sched,
> _sched_nr_migrate);
> +
> + mutex_lock(_domains_mutex);
> + register_sched_domain_sysctl();
> + mutex_unlock(_domains_mutex);
> #endif
>
> #ifdef CONFIG_NUMA_BALANCING
> @@ -316,229 +320,88 @@ late_initcall(sched_init_debug);
>
> #ifdef CONFIG_SMP
>
> -#ifdef CONFIG_SYSCTL
> -
> -static struct ctl_table sd_ctl_dir[] = {
> - {
> - .procname = "sched_domain",
> - .mode = 0555,
> - },
> - {}
> -};
> -
> -static struct ctl_table sd_ctl_root[] = {
> - {
> - .procname = "kernel",
> - .mode = 0555,
> - .child = sd_ctl_dir,
> - },
> - {}
> -};
> -
> -static struct ctl_table *sd_alloc_ctl_entry(int n)
> -{
> - struct ctl_table *entry =
> - kcalloc(n, sizeof(struct ctl_table), GFP_KERNEL);
> -
> - return entry;
> -}
> -
> -static void sd_free_ctl_entry(struct ctl_table **tablep)
> -{
> - struct ctl_table *entry;
> -
> - /*
> - * In the intermediate directories, both the child directory and
> - * procname are dynamically allocated and could fail but the mode
> - * will always be set. In the lowest directory the names are
> - * static strings and all have proc handlers.
> - */
> - for (entry = *tablep; entry->mode; entry++) {
> - if (entry->child)
> - sd_free_ctl_entry(>child);
> - if (entry->proc_handler == NULL)
> - kfree(entry->procname);
> - }
> -
> - kfree(*tablep);
> - *tablep = NULL;
> -}
> -
> -static void
> -set_table_entry(struct ctl_table *entry,
> - const char *procname, void *data, int maxlen,
> - umode_t mode, proc_handler *proc_handler)
> -{
> - entry->procname = procname;
> - entry->data = data;
> - entry->maxlen = maxlen;
> - entry->mode = mode;
> - entry->proc_handler = proc_handler;
> -}
> +static cpumask_var_t sd_sysctl_cpus;
> +static struct dentry *sd_dentry;
>
> -static int sd_ctl_doflags(struct ctl_table *table, int write,
> - void *buffer, size_t *lenp, loff_t *ppos)
> +static int sd_flags_show(struct seq_file *m, void *v)
> {
> - unsigned long flags = *(unsigned long *)table->data;
> - size_t data_size = 0;
> - size_t len = 0;
> - char *tmp, *buf;
> + unsigned long flags = *(unsigned int *)m->private;
> int idx;
>
> - if (write)
> - return 0;
> -
> - for_each_set_bit(idx, , __SD_FLAG_CNT) {
> - char *name = sd_flag_debug[idx].name;
> -
> - /* Name plus whitespace */
> - data_size += strlen(name) + 1;
> - }
> -
> - if (*ppos > data_size) {
> - *lenp = 0;
> - return 0;
> - }
> -
> - buf = kcalloc(data_size + 1, sizeof(*buf), GFP_KERNEL);
> - if (!buf)
> - return -ENOMEM;
> -
> for_each_set_bit(idx, , __SD_FLAG_CNT) {
> - char *name = sd_flag_debug[idx].name;
> -
> - len +=
[PATCH 5.11 10/23] gpu: host1x: Use different lock classes for each client
From: Mikko Perttunen
[ Upstream commit a24f98176d1efae2c37d3438c57a624d530d9c33 ]
To avoid false lockdep warnings, give each client lock a different
lock class, passed from the initialization site by macro.
Signed-off-by: Mikko Perttunen
Signed-off-by: Thierry Reding
Signed-off-by: Sasha Levin
---
drivers/gpu/host1x/bus.c | 10 ++
include/linux/host1x.h | 9 -
2 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/host1x/bus.c b/drivers/gpu/host1x/bus.c
index 347fb962b6c9..68a766ff0e9d 100644
--- a/drivers/gpu/host1x/bus.c
+++ b/drivers/gpu/host1x/bus.c
@@ -705,8 +705,9 @@ void host1x_driver_unregister(struct host1x_driver *driver)
EXPORT_SYMBOL(host1x_driver_unregister);
/**
- * host1x_client_register() - register a host1x client
+ * __host1x_client_register() - register a host1x client
* @client: host1x client
+ * @key: lock class key for the client-specific mutex
*
* Registers a host1x client with each host1x controller instance. Note that
* each client will only match their parent host1x controller and will only be
@@ -715,13 +716,14 @@ EXPORT_SYMBOL(host1x_driver_unregister);
* device and call host1x_device_init(), which will in turn call each client's
* _client_ops.init implementation.
*/
-int host1x_client_register(struct host1x_client *client)
+int __host1x_client_register(struct host1x_client *client,
+struct lock_class_key *key)
{
struct host1x *host1x;
int err;
INIT_LIST_HEAD(>list);
- mutex_init(>lock);
+ __mutex_init(>lock, "host1x client lock", key);
client->usecount = 0;
mutex_lock(_lock);
@@ -742,7 +744,7 @@ int host1x_client_register(struct host1x_client *client)
return 0;
}
-EXPORT_SYMBOL(host1x_client_register);
+EXPORT_SYMBOL(__host1x_client_register);
/**
* host1x_client_unregister() - unregister a host1x client
diff --git a/include/linux/host1x.h b/include/linux/host1x.h
index ce59a6a6a008..9eb77c87a83b 100644
--- a/include/linux/host1x.h
+++ b/include/linux/host1x.h
@@ -320,7 +320,14 @@ static inline struct host1x_device
*to_host1x_device(struct device *dev)
int host1x_device_init(struct host1x_device *device);
int host1x_device_exit(struct host1x_device *device);
-int host1x_client_register(struct host1x_client *client);
+int __host1x_client_register(struct host1x_client *client,
+struct lock_class_key *key);
+#define host1x_client_register(class) \
+ ({ \
+ static struct lock_class_key __key; \
+ __host1x_client_register(class, &__key); \
+ })
+
int host1x_client_unregister(struct host1x_client *client);
int host1x_client_suspend(struct host1x_client *client);
--
2.30.2
[Qestion] Is preempt_disable/enable needed in non-preemption code path
Hi experts, I am learning rcu mechanism and its codes. When looking at the rcu_blocking_is_gp(), I found there is a pair preemption disable/enable operation in non-preemption code path. And it has been a long time. I can't understand why we need it? Is there some thing I missed? If not, can we remove the unnecessary operation like blow? diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c index da6f5213fb74..c6d95a00715e 100644 --- a/kernel/rcu/tree.c +++ b/kernel/rcu/tree.c @@ -3703,7 +3703,6 @@ static int rcu_blocking_is_gp(void) if (IS_ENABLED(CONFIG_PREEMPTION)) return rcu_scheduler_active == RCU_SCHEDULER_INACTIVE; might_sleep(); /* Check for RCU read-side critical section. */ - preempt_disable(); /* * If the rcu_state.n_online_cpus counter is equal to one, * there is only one CPU, and that CPU sees all prior accesses @@ -3718,7 +3717,6 @@ static int rcu_blocking_is_gp(void) * Those memory barriers are provided by CPU-hotplug code. */ ret = READ_ONCE(rcu_state.n_online_cpus) <= 1; - preempt_enable(); return ret; } Best regards, Yanfei
[PATCH 5.11 03/23] KVM: arm64: Hide system instruction access to Trace registers
From: Suzuki K Poulose
[ Upstream commit 1d676673d665fd2162e7e466dcfbe5373bfdb73e ]
Currently we advertise the ID_AA6DFR0_EL1.TRACEVER for the guest,
when the trace register accesses are trapped (CPTR_EL2.TTA == 1).
So, the guest will get an undefined instruction, if trusts the
ID registers and access one of the trace registers.
Lets be nice to the guest and hide the feature to avoid
unexpected behavior.
Even though this can be done at KVM sysreg emulation layer,
we do this by removing the TRACEVER from the sanitised feature
register field. This is fine as long as the ETM drivers
can handle the individual trace units separately, even
when there are differences among the CPUs.
Cc: Will Deacon
Cc: Catalin Marinas
Cc: Mark Rutland
Signed-off-by: Suzuki K Poulose
Signed-off-by: Marc Zyngier
Link: https://lore.kernel.org/r/20210323120647.454211-2-suzuki.poul...@arm.com
Signed-off-by: Sasha Levin
---
arch/arm64/kernel/cpufeature.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index b1f7bfadab9f..be6014fe5c3e 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -380,7 +380,6 @@ static const struct arm64_ftr_bits ftr_id_aa64dfr0[] = {
* of support.
*/
S_ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_EXACT,
ID_AA64DFR0_PMUVER_SHIFT, 4, 0),
- ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_EXACT,
ID_AA64DFR0_TRACEVER_SHIFT, 4, 0),
ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_EXACT,
ID_AA64DFR0_DEBUGVER_SHIFT, 4, 0x6),
ARM64_FTR_END,
};
--
2.30.2
[PATCH 5.11 00/23] 5.11.15-rc1 review
This is the start of the stable review cycle for the 5.11.15 release. There are 23 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sat, 17 Apr 2021 14:44:01 +. Anything received after that time might be too late. The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.11.15-rc1.gz or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.11.y and the diffstat can be found below. thanks, greg k-h - Pseudo-Shortlog of commits: Greg Kroah-Hartman Linux 5.11.15-rc1 Russell King net: sfp: cope with SFPs that set both LOS normal and LOS inverted Arnaldo Carvalho de Melo perf map: Tighten snprintf() string precision to pass gcc check on some 32-bit arches Florian Westphal netfilter: x_tables: fix compat match/target pad out-of-bound write Pavel Begunkov block: don't ignore REQ_NOWAIT for direct IO Zihao Yu riscv,entry: fix misaligned base for excp_vect_table Jens Axboe io_uring: don't mark S_ISBLK async work as unbounded Damien Le Moal null_blk: fix command timeout completion handling Matthew Wilcox (Oracle) idr test suite: Create anchor before launching throbber Matthew Wilcox (Oracle) idr test suite: Take RCU read lock in idr_find_test_1 Matthew Wilcox (Oracle) radix tree test suite: Register the main thread with the RCU library Yufen Yu block: only update parent bi_status when bio fail Matthew Wilcox (Oracle) radix tree test suite: Fix compilation Matthew Wilcox (Oracle) XArray: Fix splitting to non-zero orders Mikko Perttunen gpu: host1x: Use different lock classes for each client Dmitry Osipenko drm/tegra: dc: Don't set PLL clock to 0Hz Stefan Raspl tools/kvm_stat: Add restart delay Steven Rostedt (VMware) ftrace: Check if pages were allocated before calling free_pages() Bob Peterson gfs2: report "already frozen/thawed" errors Arnd Bergmann drm/imx: imx-ldb: fix out of bounds array access warning Suzuki K Poulose KVM: arm64: Disable guest access to trace filter controls Suzuki K Poulose KVM: arm64: Hide system instruction access to Trace registers Andrew Price gfs2: Flag a withdraw if init_threads() fails Jia-Ju Bai interconnect: core: fix error return code of icc_link_destroy() - Diffstat: Makefile| 4 +-- arch/arm64/include/asm/kvm_arm.h| 1 + arch/arm64/kernel/cpufeature.c | 1 - arch/arm64/kvm/debug.c | 2 ++ arch/riscv/kernel/entry.S | 1 + block/bio.c | 2 +- drivers/block/null_blk/main.c | 26 ++ drivers/block/null_blk/null_blk.h | 1 + drivers/gpu/drm/imx/imx-ldb.c | 10 +++ drivers/gpu/drm/tegra/dc.c | 10 +++ drivers/gpu/host1x/bus.c| 10 --- drivers/interconnect/core.c | 2 ++ drivers/net/phy/sfp.c | 36 +++-- fs/block_dev.c | 4 +++ fs/gfs2/super.c | 14 ++ fs/io_uring.c | 2 +- include/linux/host1x.h | 9 ++- kernel/trace/ftrace.c | 9 --- lib/test_xarray.c | 26 +- lib/xarray.c| 4 +-- net/ipv4/netfilter/arp_tables.c | 2 ++ net/ipv4/netfilter/ip_tables.c | 2 ++ net/ipv6/netfilter/ip6_tables.c | 2 ++ net/netfilter/x_tables.c| 10 ++- tools/kvm/kvm_stat/kvm_stat.service | 1 + tools/perf/util/map.c | 7 +++-- tools/testing/radix-tree/idr-test.c | 10 +-- tools/testing/radix-tree/linux/compiler_types.h | 0 tools/testing/radix-tree/multiorder.c | 2 ++ tools/testing/radix-tree/xarray.c | 2 ++ 30 files changed, 142 insertions(+), 70 deletions(-)
[PATCH 5.11 09/23] drm/tegra: dc: Dont set PLL clock to 0Hz
From: Dmitry Osipenko
[ Upstream commit f8fb97c915954fc6de6513cdf277103b5c6df7b3 ]
RGB output doesn't allow to change parent clock rate of the display and
PCLK rate is set to 0Hz in this case. The tegra_dc_commit_state() shall
not set the display clock to 0Hz since this change propagates to the
parent clock. The DISP clock is defined as a NODIV clock by the tegra-clk
driver and all NODIV clocks use the CLK_SET_RATE_PARENT flag.
This bug stayed unnoticed because by default PLLP is used as the parent
clock for the display controller and PLLP silently skips the erroneous 0Hz
rate changes because it always has active child clocks that don't permit
rate changes. The PLLP isn't acceptable for some devices that we want to
upstream (like Samsung Galaxy Tab and ASUS TF700T) due to a display panel
clock rate requirements that can't be fulfilled by using PLLP and then the
bug pops up in this case since parent clock is set to 0Hz, killing the
display output.
Don't touch DC clock if pclk=0 in order to fix the problem.
Signed-off-by: Dmitry Osipenko
Signed-off-by: Thierry Reding
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/tegra/dc.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index 8eeef5017826..134986dc2783 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -1688,6 +1688,11 @@ static void tegra_dc_commit_state(struct tegra_dc *dc,
dev_err(dc->dev,
"failed to set clock rate to %lu Hz\n",
state->pclk);
+
+ err = clk_set_rate(dc->clk, state->pclk);
+ if (err < 0)
+ dev_err(dc->dev, "failed to set clock %pC to %lu Hz:
%d\n",
+ dc->clk, state->pclk, err);
}
DRM_DEBUG_KMS("rate: %lu, div: %u\n", clk_get_rate(dc->clk),
@@ -1698,11 +1703,6 @@ static void tegra_dc_commit_state(struct tegra_dc *dc,
value = SHIFT_CLK_DIVIDER(state->div) | PIXEL_CLK_DIVIDER_PCD1;
tegra_dc_writel(dc, value, DC_DISP_DISP_CLOCK_CONTROL);
}
-
- err = clk_set_rate(dc->clk, state->pclk);
- if (err < 0)
- dev_err(dc->dev, "failed to set clock %pC to %lu Hz: %d\n",
- dc->clk, state->pclk, err);
}
static void tegra_dc_stop(struct tegra_dc *dc)
--
2.30.2
Re: [PATCH] locking/qrwlock: Fix ordering in queued_write_lock_slowpath
On Thu, Apr 15, 2021 at 02:25:52PM +, Ali Saidi wrote:
> While this code is executed with the wait_lock held, a reader can
> acquire the lock without holding wait_lock. The writer side loops
> checking the value with the atomic_cond_read_acquire(), but only truly
> acquires the lock when the compare-and-exchange is completed
> successfully which isn’t ordered. The other atomic operations from this
> point are release-ordered and thus reads after the lock acquisition can
> be completed before the lock is truly acquired which violates the
> guarantees the lock should be making.
I think it would be worth spelling this out with an example. The issue
appears to be a concurrent reader in interrupt context taking and releasing
the lock in the window where the writer has returned from the
atomic_cond_read_acquire() but has not yet performed the cmpxchg(). Loads
can be speculated during this time, but the A-B-A of the lock word
from _QW_WAITING to (_QW_WAITING | _QR_BIAS) and back to _QW_WAITING allows
the atomic_cmpxchg_relaxed() to succeed. Is that right?
With that in mind, it would probably be a good idea to eyeball the qspinlock
slowpath as well, as that uses both atomic_cond_read_acquire() and
atomic_try_cmpxchg_relaxed().
> Fixes: b519b56e378ee ("locking/qrwlock: Use atomic_cond_read_acquire() when
> spinning in qrwloc")
Typo in the quoted subject ('qrwloc').
> Signed-off-by: Ali Saidi
> Cc: sta...@vger.kernel.org
> ---
> kernel/locking/qrwlock.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/locking/qrwlock.c b/kernel/locking/qrwlock.c
> index 4786dd271b45..10770f6ac4d9 100644
> --- a/kernel/locking/qrwlock.c
> +++ b/kernel/locking/qrwlock.c
> @@ -73,8 +73,8 @@ void queued_write_lock_slowpath(struct qrwlock *lock)
>
> /* When no more readers or writers, set the locked flag */
> do {
> - atomic_cond_read_acquire(>cnts, VAL == _QW_WAITING);
> - } while (atomic_cmpxchg_relaxed(>cnts, _QW_WAITING,
> + atomic_cond_read_relaxed(>cnts, VAL == _QW_WAITING);
> + } while (atomic_cmpxchg_acquire(>cnts, _QW_WAITING,
> _QW_LOCKED) != _QW_WAITING);
Patch looks good, so with an updated message:
Acked-by: Will Deacon
Will
Re: [PATCH] locking/qrwlock: Fix ordering in queued_write_lock_slowpath
On Thu, Apr 15, 2021 at 02:25:52PM +, Ali Saidi wrote:
> While this code is executed with the wait_lock held, a reader can
> acquire the lock without holding wait_lock. The writer side loops
> checking the value with the atomic_cond_read_acquire(), but only truly
> acquires the lock when the compare-and-exchange is completed
> successfully which isn’t ordered. The other atomic operations from this
> point are release-ordered and thus reads after the lock acquisition can
> be completed before the lock is truly acquired which violates the
> guarantees the lock should be making.
Should be per who? We explicitly do not order the lock acquire store.
qspinlock has the exact same issue.
If you look in the git history surrounding spin_is_locked(), you'll find
'lovely' things.
Basically, if you're doing crazy things with spin_is_locked() you get to
keep the pieces.
> Fixes: b519b56e378ee ("locking/qrwlock: Use atomic_cond_read_acquire() when
> spinning in qrwloc")
> Signed-off-by: Ali Saidi
> Cc: sta...@vger.kernel.org
> ---
> kernel/locking/qrwlock.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/locking/qrwlock.c b/kernel/locking/qrwlock.c
> index 4786dd271b45..10770f6ac4d9 100644
> --- a/kernel/locking/qrwlock.c
> +++ b/kernel/locking/qrwlock.c
> @@ -73,8 +73,8 @@ void queued_write_lock_slowpath(struct qrwlock *lock)
>
> /* When no more readers or writers, set the locked flag */
> do {
> - atomic_cond_read_acquire(>cnts, VAL == _QW_WAITING);
> - } while (atomic_cmpxchg_relaxed(>cnts, _QW_WAITING,
> + atomic_cond_read_relaxed(>cnts, VAL == _QW_WAITING);
> + } while (atomic_cmpxchg_acquire(>cnts, _QW_WAITING,
> _QW_LOCKED) != _QW_WAITING);
> unlock:
> arch_spin_unlock(>wait_lock);
This doesn't make sense, there is no such thing as a store-acquire. What
you're doing here is moving the acquire from one load to the next. A
load we know will load the exact same value.
Also see Documentation/atomic_t.txt:
{}_acquire: the R of the RMW (or atomic_read) is an ACQUIRE
If anything this code wants to be written like so.
---
diff --git a/kernel/locking/qrwlock.c b/kernel/locking/qrwlock.c
index 4786dd271b45..22aeccc363ca 100644
--- a/kernel/locking/qrwlock.c
+++ b/kernel/locking/qrwlock.c
@@ -60,6 +60,8 @@ EXPORT_SYMBOL(queued_read_lock_slowpath);
*/
void queued_write_lock_slowpath(struct qrwlock *lock)
{
+ u32 cnt;
+
/* Put the writer into the wait queue */
arch_spin_lock(>wait_lock);
@@ -73,9 +75,8 @@ void queued_write_lock_slowpath(struct qrwlock *lock)
/* When no more readers or writers, set the locked flag */
do {
- atomic_cond_read_acquire(>cnts, VAL == _QW_WAITING);
- } while (atomic_cmpxchg_relaxed(>cnts, _QW_WAITING,
- _QW_LOCKED) != _QW_WAITING);
+ cnt = atomic_cond_read_acquire(>cnts, VAL == _QW_WAITING);
+ } while (!atomic_try_cmpxchg_relaxed(>cnts, , _QW_LOCKED));
unlock:
arch_spin_unlock(>wait_lock);
}
Re: [PATCH 1/1] char: hpet: Remove unused local variable 'm' in hpet_interrupt()
On Thu, Apr 15, 2021 at 10:24:04PM +0800, Zhen Lei wrote:
> Commit 273ef9509b79 ("drivers/char/hpet.c: fix periodic-emulation for
> delayed interrupt") removed the reference to local variable 'm', but
> forgot to remove the definition and assignment of it. Due to
> read_counter() indirectly calls "read barrier", the performance is
> slightly degraded.
>
> Since the following comments give some description based on 'm', so move
> the assignment of 'm' into it.
>
> Fixes: 273ef9509b79 ("drivers/char/hpet.c: fix periodic-emulation for delayed
> interrupt")
> Reported-by: Hulk Robot
> Signed-off-by: Zhen Lei
> ---
> drivers/char/hpet.c | 8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/char/hpet.c b/drivers/char/hpet.c
> index ed3b7dab678dbd1..46950a0cda181a1 100644
> --- a/drivers/char/hpet.c
> +++ b/drivers/char/hpet.c
> @@ -156,14 +156,16 @@ static irqreturn_t hpet_interrupt(int irq, void *data)
>* This has the effect of treating non-periodic like periodic.
>*/
> if ((devp->hd_flags & (HPET_IE | HPET_PERIODIC)) == HPET_IE) {
> - unsigned long m, t, mc, base, k;
> + unsigned long t, mc, base, k;
> struct hpet __iomem *hpet = devp->hd_hpet;
> struct hpets *hpetp = devp->hd_hpets;
>
> t = devp->hd_ireqfreq;
> - m = read_counter(>hd_timer->hpet_compare);
> mc = read_counter(>hpet_mc);
> - /* The time for the next interrupt would logically be t + m,
> + /*
> + * m = read_counter(>hd_timer->hpet_compare);
Why did you comment this out?
And are you sure that yuou are not required to actually read that
counter, even if you do not do anything with the value? Lots of
hardware works in odd ways...
Have you tested and verified that this still works properly?
thanks,
greg k-h
Re: [PATCH] PM / EM: Inefficient OPPs detection
On Thursday 15 Apr 2021 at 14:59:54 (+), Quentin Perret wrote: > On Thursday 15 Apr 2021 at 15:34:53 (+0100), Vincent Donnefort wrote: > > On Thu, Apr 15, 2021 at 01:16:35PM +, Quentin Perret wrote: > > > On Thursday 08 Apr 2021 at 18:10:29 (+0100), Vincent Donnefort wrote: > > > > --- a/kernel/sched/cpufreq_schedutil.c > > > > +++ b/kernel/sched/cpufreq_schedutil.c > > > > @@ -10,6 +10,7 @@ > > > > > > > > #include "sched.h" > > > > > > > > +#include > > > > #include > > > > #include > > > > > > > > @@ -164,6 +165,9 @@ static unsigned int get_next_freq(struct > > > > sugov_policy *sg_policy, > > > > > > > > freq = map_util_freq(util, freq, max); > > > > > > > > + /* Avoid inefficient performance states */ > > > > + freq = em_pd_get_efficient_freq(em_cpu_get(policy->cpu), freq); > > > > > > I remember this was discussed when Douglas sent his patches some time > > > ago, but I still find it sad we index the EM table here but still > > > re-index the cpufreq frequency table later :/ > > > > > > Yes in your case this lookup is very inexpensive, but still. EAS relies > > > on the EM's table matching cpufreq's accurately, so this second lookup > > > still feels rather unnecessary ... > > > > To get only a single lookup, we would need to bring the inefficiency > > knowledge > > directly to the cpufreq framework. But it has its own limitations: > > > > The cpufreq driver can have its own resolve_freq() callback, which means > > that > > not all the drivers would benefit from that feature. > > > > The cpufreq_table can be ordered and accessed in several ways which brings > > many combinations that would need to be supported, ending-up with > > something > > much more intrusive. (We can though decide to limit the feature to the > > low to > > high access that schedutil needs). > > > > As the EM needs schedutil to exist anyway, it seemed to be the right place > > for > > this code. It allows any cpufreq driver to benefit from the feature, > > simplify a > > potential extension for a usage by devfreq devices and as a bonus it > > speeds-up > > energy computing, allowing a more complex Energy Model. > > I was thinking of something a bit simpler. cpufreq_driver_resolve_freq > appears to be used only from schedutil (why is it even then?), so we why is it even *exported* then ... > could just pull it into cpufreq_schedutil.c and just plain skip the call > to cpufreq_frequency_table_target if the target freq has been indexed in > the EM table -- it should already be matching a real OPP. > > Thoughts? > Quentin
[PATCH 5.11 07/23] ftrace: Check if pages were allocated before calling free_pages()
From: Steven Rostedt (VMware)
[ Upstream commit 59300b36f85f254260c81d9dd09195fa49eb0f98 ]
It is possible that on error pg->size can be zero when getting its order,
which would return a -1 value. It is dangerous to pass in an order of -1
to free_pages(). Check if order is greater than or equal to zero before
calling free_pages().
Link: https://lore.kernel.org/lkml/20210330093916.43269...@gandalf.local.home/
Reported-by: Abaci Robot
Signed-off-by: Steven Rostedt (VMware)
Signed-off-by: Sasha Levin
---
kernel/trace/ftrace.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index b7e29db127fa..3ba52d4e1314 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -3231,7 +3231,8 @@ ftrace_allocate_pages(unsigned long num_to_init)
pg = start_pg;
while (pg) {
order = get_count_order(pg->size / ENTRIES_PER_PAGE);
- free_pages((unsigned long)pg->records, order);
+ if (order >= 0)
+ free_pages((unsigned long)pg->records, order);
start_pg = pg->next;
kfree(pg);
pg = start_pg;
@@ -6451,7 +6452,8 @@ void ftrace_release_mod(struct module *mod)
clear_mod_from_hashes(pg);
order = get_count_order(pg->size / ENTRIES_PER_PAGE);
- free_pages((unsigned long)pg->records, order);
+ if (order >= 0)
+ free_pages((unsigned long)pg->records, order);
tmp_page = pg->next;
kfree(pg);
ftrace_number_of_pages -= 1 << order;
@@ -6811,7 +6813,8 @@ void ftrace_free_mem(struct module *mod, void *start_ptr,
void *end_ptr)
if (!pg->index) {
*last_pg = pg->next;
order = get_count_order(pg->size / ENTRIES_PER_PAGE);
- free_pages((unsigned long)pg->records, order);
+ if (order >= 0)
+ free_pages((unsigned long)pg->records, order);
ftrace_number_of_pages -= 1 << order;
ftrace_number_of_groups--;
kfree(pg);
--
2.30.2
Re: [PATCH 00/13] tty.h cleanups
On Thu, Apr 15, 2021 at 04:14:33PM +0200, Johan Hovold wrote: > On Thu, Apr 15, 2021 at 10:21:54AM +0200, Greg Kroah-Hartman wrote: > > On Fri, Apr 09, 2021 at 09:32:45AM +0200, Johan Hovold wrote: > > > On Thu, Apr 08, 2021 at 08:01:08PM +0200, Greg Kroah-Hartman wrote: > > > > On Thu, Apr 08, 2021 at 04:25:22PM +0200, Johan Hovold wrote: > > > > > On Thu, Apr 08, 2021 at 02:51:21PM +0200, Greg Kroah-Hartman wrote: > > > > > > Turns out there is a lot of tty-internal stuff in > > > > > > include/linux/tty.h > > > > > > that do not belong there. Create a internal-to-the-tty-layer .h > > > > > > file > > > > > > for these types of things and move function prototypes to it > > > > > > instead of > > > > > > being in the system-wide header file. > > > > > > > > > > > > Along the way clean up the use of some old tty-only debugging > > > > > > macros and > > > > > > use the in-kernel dev_*() calls instead. > > > > > > > > > > I'm afraid that's not a good idea since not all ttys have a > > > > > corresponding class device. Notable exception include pseudo terminals > > > > > and serdev. > > > > > > > > > > While dev_printk() can handle a NULL device argument without crashing, > > > > > we'll actually lose log information by removing the tty printk > > > > > helpers. > > > > > > > > I think the same info will be printed here as before, just some NULL > > > > information at the beginning, right? And the benifits overall (for real > > > > tty devices), should outweigh the few devices that do not have this > > > > information. > > > > > > No, you'll only be losing information (tty driver and tty name). Here's > > > a pty example, where the first line in each pair use dev_info() and the > > > second tty_info(): > > > > > > [ 10.235331] (NULL device *): tty_get_device > > > [ 10.235441] ptm ptm0: tty_get_device > > > > > > [ 10.235586] (NULL device *): tty_get_device > > > [ 10.235674] pts pts0: tty_get_device > > > > > > and similar for serdev, which is becoming more and more common. > > > > Ok, good point, I'll go apply only the first 2 patches in this series > > (moving the macros out of tty.h and removing the unused one) and then > > will redo this set of patches again. > > Perhaps no harm in leaving the tty_info() on in there for consistency. > We have users of the _ratelimited() flavour of it (even if there's no > dependency). I dropped it, no need to keep around unused macros :) > > I think a better tty_msg() macro is warrented so that we can provide > > dev_*() output if we have a device, otherwise fall back to the old > > style to preserve functionality. > > Possibly, but the dev_printk() for the tty class devices wouldn't > provide any more info than what's already there (i.e. driver name + tty > name). > > (And associating ttys with other devices and drivers (e.g. a serdev > client and its driver) might not be what we want since you lose the > connection to the underlying tty driver.) Yeah, I messed with this for a bit today and I think I'm just going to give up and leave it as-is for now... thanks, greg k-h
[PATCH 5.10 07/25] ftrace: Check if pages were allocated before calling free_pages()
From: Steven Rostedt (VMware)
[ Upstream commit 59300b36f85f254260c81d9dd09195fa49eb0f98 ]
It is possible that on error pg->size can be zero when getting its order,
which would return a -1 value. It is dangerous to pass in an order of -1
to free_pages(). Check if order is greater than or equal to zero before
calling free_pages().
Link: https://lore.kernel.org/lkml/20210330093916.43269...@gandalf.local.home/
Reported-by: Abaci Robot
Signed-off-by: Steven Rostedt (VMware)
Signed-off-by: Sasha Levin
---
kernel/trace/ftrace.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index 82041bbf8fc2..b1983c2aeb53 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -3230,7 +3230,8 @@ ftrace_allocate_pages(unsigned long num_to_init)
pg = start_pg;
while (pg) {
order = get_count_order(pg->size / ENTRIES_PER_PAGE);
- free_pages((unsigned long)pg->records, order);
+ if (order >= 0)
+ free_pages((unsigned long)pg->records, order);
start_pg = pg->next;
kfree(pg);
pg = start_pg;
@@ -6452,7 +6453,8 @@ void ftrace_release_mod(struct module *mod)
clear_mod_from_hashes(pg);
order = get_count_order(pg->size / ENTRIES_PER_PAGE);
- free_pages((unsigned long)pg->records, order);
+ if (order >= 0)
+ free_pages((unsigned long)pg->records, order);
tmp_page = pg->next;
kfree(pg);
ftrace_number_of_pages -= 1 << order;
@@ -6812,7 +6814,8 @@ void ftrace_free_mem(struct module *mod, void *start_ptr,
void *end_ptr)
if (!pg->index) {
*last_pg = pg->next;
order = get_count_order(pg->size / ENTRIES_PER_PAGE);
- free_pages((unsigned long)pg->records, order);
+ if (order >= 0)
+ free_pages((unsigned long)pg->records, order);
ftrace_number_of_pages -= 1 << order;
ftrace_number_of_groups--;
kfree(pg);
--
2.30.2
[PATCH 5.11 12/23] radix tree test suite: Fix compilation
From: Matthew Wilcox (Oracle) [ Upstream commit 7487de534dcbe143e6f41da751dd3ffcf93b00ee ] Commit 4bba4c4bb09a added tools/include/linux/compiler_types.h which includes linux/compiler-gcc.h. Unfortunately, we had our own (empty) compiler_types.h which overrode the one added by that commit, and so we lost the definition of __must_be_array(). Removing our empty compiler_types.h fixes the problem and reduces our divergence from the rest of the tools. Signed-off-by: Matthew Wilcox (Oracle) Signed-off-by: Sasha Levin --- tools/testing/radix-tree/linux/compiler_types.h | 0 1 file changed, 0 insertions(+), 0 deletions(-) delete mode 100644 tools/testing/radix-tree/linux/compiler_types.h diff --git a/tools/testing/radix-tree/linux/compiler_types.h b/tools/testing/radix-tree/linux/compiler_types.h deleted file mode 100644 index e69de29bb2d1.. -- 2.30.2
[PATCH 5.11 13/23] block: only update parent bi_status when bio fail
From: Yufen Yu
[ Upstream commit 3edf5346e4f2ce2fa0c94651a90a8dda169565ee ]
For multiple split bios, if one of the bio is fail, the whole
should return error to application. But we found there is a race
between bio_integrity_verify_fn and bio complete, which return
io success to application after one of the bio fail. The race as
following:
split bio(READ) kworker
nvme_complete_rq
blk_update_request //split error=0
bio_endio
bio_integrity_endio
queue_work(kintegrityd_wq, >bip_work);
bio_integrity_verify_fn
bio_endio //split bio
__bio_chain_endio
if (!parent->bi_status)
nvme_irq
blk_update_request //parent error=7
req_bio_endio
bio->bi_status = 7 //parent bio
parent->bi_status = 0
parent->bi_end_io() // return bi_status=0
The bio has been split as two: split and parent. When split
bio completed, it depends on kworker to do endio, while
bio_integrity_verify_fn have been interrupted by parent bio
complete irq handler. Then, parent bio->bi_status which have
been set in irq handler will overwrite by kworker.
In fact, even without the above race, we also need to conside
the concurrency beteen mulitple split bio complete and update
the same parent bi_status. Normally, multiple split bios will
be issued to the same hctx and complete from the same irq
vector. But if we have updated queue map between multiple split
bios, these bios may complete on different hw queue and different
irq vector. Then the concurrency update parent bi_status may
cause the final status error.
Suggested-by: Keith Busch
Signed-off-by: Yufen Yu
Reviewed-by: Ming Lei
Link: https://lore.kernel.org/r/20210331115359.1125679-1-yuyu...@huawei.com
Signed-off-by: Jens Axboe
Signed-off-by: Sasha Levin
---
block/bio.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/block/bio.c b/block/bio.c
index 1f2cc1fbe283..3209d865828a 100644
--- a/block/bio.c
+++ b/block/bio.c
@@ -313,7 +313,7 @@ static struct bio *__bio_chain_endio(struct bio *bio)
{
struct bio *parent = bio->bi_private;
- if (!parent->bi_status)
+ if (bio->bi_status && !parent->bi_status)
parent->bi_status = bio->bi_status;
bio_put(bio);
return parent;
--
2.30.2
[PATCH 5.10 06/25] gfs2: report "already frozen/thawed" errors
From: Bob Peterson
[ Upstream commit ff132c5f93c06bd4432bbab5c369e468653bdec4 ]
Before this patch, gfs2's freeze function failed to report an error
when the target file system was already frozen as it should (and as
generic vfs function freeze_super does. Similarly, gfs2's thaw function
failed to report an error when trying to thaw a file system that is not
frozen, as vfs function thaw_super does. The errors were checked, but
it always returned a 0 return code.
This patch adds the missing error return codes to gfs2 freeze and thaw.
Signed-off-by: Bob Peterson
Signed-off-by: Andreas Gruenbacher
Signed-off-by: Sasha Levin
---
fs/gfs2/super.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/fs/gfs2/super.c b/fs/gfs2/super.c
index 0581612dd91e..077dc8c035a8 100644
--- a/fs/gfs2/super.c
+++ b/fs/gfs2/super.c
@@ -769,11 +769,13 @@ void gfs2_freeze_func(struct work_struct *work)
static int gfs2_freeze(struct super_block *sb)
{
struct gfs2_sbd *sdp = sb->s_fs_info;
- int error = 0;
+ int error;
mutex_lock(>sd_freeze_mutex);
- if (atomic_read(>sd_freeze_state) != SFS_UNFROZEN)
+ if (atomic_read(>sd_freeze_state) != SFS_UNFROZEN) {
+ error = -EBUSY;
goto out;
+ }
for (;;) {
if (gfs2_withdrawn(sdp)) {
@@ -814,10 +816,10 @@ static int gfs2_unfreeze(struct super_block *sb)
struct gfs2_sbd *sdp = sb->s_fs_info;
mutex_lock(>sd_freeze_mutex);
-if (atomic_read(>sd_freeze_state) != SFS_FROZEN ||
+ if (atomic_read(>sd_freeze_state) != SFS_FROZEN ||
!gfs2_holder_initialized(>sd_freeze_gh)) {
mutex_unlock(>sd_freeze_mutex);
-return 0;
+ return -EINVAL;
}
gfs2_freeze_unlock(>sd_freeze_gh);
--
2.30.2
[PATCH 5.11 14/23] radix tree test suite: Register the main thread with the RCU library
From: Matthew Wilcox (Oracle)
[ Upstream commit 1bb4bd266cf39fd2fa711f2d265c558b92df1119 ]
Several test runners register individual worker threads with the
RCU library, but neglect to register the main thread, which can lead
to objects being freed while the main thread is in what appears to be
an RCU critical section.
Reported-by: Chris von Recklinghausen
Signed-off-by: Matthew Wilcox (Oracle)
Signed-off-by: Sasha Levin
---
tools/testing/radix-tree/idr-test.c | 2 ++
tools/testing/radix-tree/multiorder.c | 2 ++
tools/testing/radix-tree/xarray.c | 2 ++
3 files changed, 6 insertions(+)
diff --git a/tools/testing/radix-tree/idr-test.c
b/tools/testing/radix-tree/idr-test.c
index 3b796dd5e577..44ceff95a9b3 100644
--- a/tools/testing/radix-tree/idr-test.c
+++ b/tools/testing/radix-tree/idr-test.c
@@ -577,6 +577,7 @@ void ida_tests(void)
int __weak main(void)
{
+ rcu_register_thread();
radix_tree_init();
idr_checks();
ida_tests();
@@ -584,5 +585,6 @@ int __weak main(void)
rcu_barrier();
if (nr_allocated)
printf("nr_allocated = %d\n", nr_allocated);
+ rcu_unregister_thread();
return 0;
}
diff --git a/tools/testing/radix-tree/multiorder.c
b/tools/testing/radix-tree/multiorder.c
index 9eae0fb5a67d..e00520cc6349 100644
--- a/tools/testing/radix-tree/multiorder.c
+++ b/tools/testing/radix-tree/multiorder.c
@@ -224,7 +224,9 @@ void multiorder_checks(void)
int __weak main(void)
{
+ rcu_register_thread();
radix_tree_init();
multiorder_checks();
+ rcu_unregister_thread();
return 0;
}
diff --git a/tools/testing/radix-tree/xarray.c
b/tools/testing/radix-tree/xarray.c
index e61e43efe463..f20e12cbbfd4 100644
--- a/tools/testing/radix-tree/xarray.c
+++ b/tools/testing/radix-tree/xarray.c
@@ -25,11 +25,13 @@ void xarray_tests(void)
int __weak main(void)
{
+ rcu_register_thread();
radix_tree_init();
xarray_tests();
radix_tree_cpu_dead(1);
rcu_barrier();
if (nr_allocated)
printf("nr_allocated = %d\n", nr_allocated);
+ rcu_unregister_thread();
return 0;
}
--
2.30.2
[PATCH 5.11 15/23] idr test suite: Take RCU read lock in idr_find_test_1
From: Matthew Wilcox (Oracle)
[ Upstream commit 703586410da69eb40062e64d413ca33bd735917a ]
When run on a single CPU, this test would frequently access already-freed
memory. Due to timing, this bug never showed up on multi-CPU tests.
Reported-by: Chris von Recklinghausen
Signed-off-by: Matthew Wilcox (Oracle)
Signed-off-by: Sasha Levin
---
tools/testing/radix-tree/idr-test.c | 4
1 file changed, 4 insertions(+)
diff --git a/tools/testing/radix-tree/idr-test.c
b/tools/testing/radix-tree/idr-test.c
index 44ceff95a9b3..4a9b451b7ba0 100644
--- a/tools/testing/radix-tree/idr-test.c
+++ b/tools/testing/radix-tree/idr-test.c
@@ -306,11 +306,15 @@ void idr_find_test_1(int anchor_id, int throbber_id)
BUG_ON(idr_alloc(_idr, xa_mk_value(anchor_id), anchor_id,
anchor_id + 1, GFP_KERNEL) != anchor_id);
+ rcu_read_lock();
do {
int id = 0;
void *entry = idr_get_next(_idr, );
+ rcu_read_unlock();
BUG_ON(entry != xa_mk_value(id));
+ rcu_read_lock();
} while (time(NULL) < start + 11);
+ rcu_read_unlock();
pthread_join(throbber, NULL);
--
2.30.2
[PATCH 5.11 01/23] interconnect: core: fix error return code of icc_link_destroy()
From: Jia-Ju Bai [ Upstream commit 715ea61532e731c62392221238906704e63d75b6 ] When krealloc() fails and new is NULL, no error return code of icc_link_destroy() is assigned. To fix this bug, ret is assigned with -ENOMEM hen new is NULL. Reported-by: TOTE Robot Signed-off-by: Jia-Ju Bai Link: https://lore.kernel.org/r/20210306132857.17020-1-baijiaju1...@gmail.com Signed-off-by: Georgi Djakov Signed-off-by: Sasha Levin --- drivers/interconnect/core.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/interconnect/core.c b/drivers/interconnect/core.c index 5ad519c9f239..8a1e70e00876 100644 --- a/drivers/interconnect/core.c +++ b/drivers/interconnect/core.c @@ -942,6 +942,8 @@ int icc_link_destroy(struct icc_node *src, struct icc_node *dst) GFP_KERNEL); if (new) src->links = new; + else + ret = -ENOMEM; out: mutex_unlock(_lock); -- 2.30.2
[PATCH 5.11 11/23] XArray: Fix splitting to non-zero orders
From: Matthew Wilcox (Oracle)
[ Upstream commit 3012110d71f41410932924e1d188f9eb57f1f824 ]
Splitting an order-4 entry into order-2 entries would leave the array
containing pointers to 40008000c000 instead of .
This is a one-character fix, but enhance the test suite to check this
case.
Reported-by: Zi Yan
Signed-off-by: Matthew Wilcox (Oracle)
Signed-off-by: Sasha Levin
---
lib/test_xarray.c | 26 ++
lib/xarray.c | 4 ++--
2 files changed, 16 insertions(+), 14 deletions(-)
diff --git a/lib/test_xarray.c b/lib/test_xarray.c
index 8294f43f4981..8b1c318189ce 100644
--- a/lib/test_xarray.c
+++ b/lib/test_xarray.c
@@ -1530,24 +1530,24 @@ static noinline void check_store_range(struct xarray
*xa)
#ifdef CONFIG_XARRAY_MULTI
static void check_split_1(struct xarray *xa, unsigned long index,
- unsigned int order)
+ unsigned int order, unsigned int new_order)
{
- XA_STATE(xas, xa, index);
- void *entry;
- unsigned int i = 0;
+ XA_STATE_ORDER(xas, xa, index, new_order);
+ unsigned int i;
xa_store_order(xa, index, order, xa, GFP_KERNEL);
xas_split_alloc(, xa, order, GFP_KERNEL);
xas_lock();
xas_split(, xa, order);
+ for (i = 0; i < (1 << order); i += (1 << new_order))
+ __xa_store(xa, index + i, xa_mk_index(index + i), 0);
xas_unlock();
- xa_for_each(xa, index, entry) {
- XA_BUG_ON(xa, entry != xa);
- i++;
+ for (i = 0; i < (1 << order); i++) {
+ unsigned int val = index + (i & ~((1 << new_order) - 1));
+ XA_BUG_ON(xa, xa_load(xa, index + i) != xa_mk_index(val));
}
- XA_BUG_ON(xa, i != 1 << order);
xa_set_mark(xa, index, XA_MARK_0);
XA_BUG_ON(xa, !xa_get_mark(xa, index, XA_MARK_0));
@@ -1557,14 +1557,16 @@ static void check_split_1(struct xarray *xa, unsigned
long index,
static noinline void check_split(struct xarray *xa)
{
- unsigned int order;
+ unsigned int order, new_order;
XA_BUG_ON(xa, !xa_empty(xa));
for (order = 1; order < 2 * XA_CHUNK_SHIFT; order++) {
- check_split_1(xa, 0, order);
- check_split_1(xa, 1UL << order, order);
- check_split_1(xa, 3UL << order, order);
+ for (new_order = 0; new_order < order; new_order++) {
+ check_split_1(xa, 0, order, new_order);
+ check_split_1(xa, 1UL << order, order, new_order);
+ check_split_1(xa, 3UL << order, order, new_order);
+ }
}
}
#else
diff --git a/lib/xarray.c b/lib/xarray.c
index 5fa51614802a..ed775dee1074 100644
--- a/lib/xarray.c
+++ b/lib/xarray.c
@@ -1011,7 +1011,7 @@ void xas_split_alloc(struct xa_state *xas, void *entry,
unsigned int order,
do {
unsigned int i;
- void *sibling;
+ void *sibling = NULL;
struct xa_node *node;
node = kmem_cache_alloc(radix_tree_node_cachep, gfp);
@@ -1021,7 +1021,7 @@ void xas_split_alloc(struct xa_state *xas, void *entry,
unsigned int order,
for (i = 0; i < XA_CHUNK_SIZE; i++) {
if ((i & mask) == 0) {
RCU_INIT_POINTER(node->slots[i], entry);
- sibling = xa_mk_sibling(0);
+ sibling = xa_mk_sibling(i);
} else {
RCU_INIT_POINTER(node->slots[i], sibling);
}
--
2.30.2
[PATCH 5.10 08/25] tools/kvm_stat: Add restart delay
From: Stefan Raspl [ Upstream commit 75f94ecbd0dfd2ac4e671f165f5ae864b7301422 ] If this service is enabled and the system rebooted, Systemd's initial attempt to start this unit file may fail in case the kvm module is not loaded. Since we did not specify a delay for the retries, Systemd restarts with a minimum delay a number of times before giving up and disabling the service. Which means a subsequent kvm module load will have kvm running without monitoring. Adding a delay to fix this. Signed-off-by: Stefan Raspl Message-Id: <20210325122949.1433271-1-ra...@linux.ibm.com> Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin --- tools/kvm/kvm_stat/kvm_stat.service | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/kvm/kvm_stat/kvm_stat.service b/tools/kvm/kvm_stat/kvm_stat.service index 71aabaffe779..8f13b843d5b4 100644 --- a/tools/kvm/kvm_stat/kvm_stat.service +++ b/tools/kvm/kvm_stat/kvm_stat.service @@ -9,6 +9,7 @@ Type=simple ExecStart=/usr/bin/kvm_stat -dtcz -s 10 -L /var/log/kvm_stat.csv ExecReload=/bin/kill -HUP $MAINPID Restart=always +RestartSec=60s SyslogIdentifier=kvm_stat SyslogLevel=debug -- 2.30.2
[PATCH 5.11 18/23] io_uring: dont mark S_ISBLK async work as unbounded
From: Jens Axboe
[ Upstream commit 4b982bd0f383db9132e892c0c5144117359a6289 ]
S_ISBLK is marked as unbounded work for async preparation, because it
doesn't match S_ISREG. That is incorrect, as any read/write to a block
device is also a bounded operation. Fix it up and ensure that S_ISBLK
isn't marked unbounded.
Signed-off-by: Jens Axboe
Signed-off-by: Sasha Levin
---
fs/io_uring.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/io_uring.c b/fs/io_uring.c
index b1b3154c8d50..95b4a89dad4e 100644
--- a/fs/io_uring.c
+++ b/fs/io_uring.c
@@ -1546,7 +1546,7 @@ static void io_prep_async_work(struct io_kiocb *req)
if (req->flags & REQ_F_ISREG) {
if (def->hash_reg_file || (ctx->flags & IORING_SETUP_IOPOLL))
io_wq_hash_work(>work, file_inode(req->file));
- } else {
+ } else if (!req->file || !S_ISBLK(file_inode(req->file)->i_mode)) {
if (def->unbound_nonreg_file)
req->work.flags |= IO_WQ_WORK_UNBOUND;
}
--
2.30.2
[PATCH 5.11 17/23] null_blk: fix command timeout completion handling
From: Damien Le Moal
[ Upstream commit de3510e52b0a398261271455562458003b8eea62 ]
Memory backed or zoned null block devices may generate actual request
timeout errors due to the submission path being blocked on memory
allocation or zone locking. Unlike fake timeouts or injected timeouts,
the request submission path will call blk_mq_complete_request() or
blk_mq_end_request() for these real timeout errors, causing a double
completion and use after free situation as the block layer timeout
handler executes blk_mq_rq_timed_out() and __blk_mq_free_request() in
blk_mq_check_expired(). This problem often triggers a NULL pointer
dereference such as:
BUG: kernel NULL pointer dereference, address: 0050
RIP: 0010:blk_mq_sched_mark_restart_hctx+0x5/0x20
...
Call Trace:
dd_finish_request+0x56/0x80
blk_mq_free_request+0x37/0x130
null_handle_cmd+0xbf/0x250 [null_blk]
? null_queue_rq+0x67/0xd0 [null_blk]
blk_mq_dispatch_rq_list+0x122/0x850
__blk_mq_do_dispatch_sched+0xbb/0x2c0
__blk_mq_sched_dispatch_requests+0x13d/0x190
blk_mq_sched_dispatch_requests+0x30/0x60
__blk_mq_run_hw_queue+0x49/0x90
process_one_work+0x26c/0x580
worker_thread+0x55/0x3c0
? process_one_work+0x580/0x580
kthread+0x134/0x150
? kthread_create_worker_on_cpu+0x70/0x70
ret_from_fork+0x1f/0x30
This problem very often triggers when running the full btrfs xfstests
on a memory-backed zoned null block device in a VM with limited amount
of memory.
Avoid this by executing blk_mq_complete_request() in null_timeout_rq()
only for commands that are marked for a fake timeout completion using
the fake_timeout boolean in struct null_cmd. For timeout errors injected
through debugfs, the timeout handler will execute
blk_mq_complete_request()i as before. This is safe as the submission
path does not execute complete requests in this case.
In null_timeout_rq(), also make sure to set the command error field to
BLK_STS_TIMEOUT and to propagate this error through to the request
completion.
Reported-by: Johannes Thumshirn
Signed-off-by: Damien Le Moal
Tested-by: Johannes Thumshirn
Reviewed-by: Johannes Thumshirn
Link: https://lore.kernel.org/r/20210331225244.126426-1-damien.lem...@wdc.com
Signed-off-by: Jens Axboe
Signed-off-by: Sasha Levin
---
drivers/block/null_blk/main.c | 26 +-
drivers/block/null_blk/null_blk.h | 1 +
2 files changed, 22 insertions(+), 5 deletions(-)
diff --git a/drivers/block/null_blk/main.c b/drivers/block/null_blk/main.c
index 5357c3a4a36f..4f6af7a5921e 100644
--- a/drivers/block/null_blk/main.c
+++ b/drivers/block/null_blk/main.c
@@ -1369,10 +1369,13 @@ static blk_status_t null_handle_cmd(struct nullb_cmd
*cmd, sector_t sector,
}
if (dev->zoned)
- cmd->error = null_process_zoned_cmd(cmd, op,
- sector, nr_sectors);
+ sts = null_process_zoned_cmd(cmd, op, sector, nr_sectors);
else
- cmd->error = null_process_cmd(cmd, op, sector, nr_sectors);
+ sts = null_process_cmd(cmd, op, sector, nr_sectors);
+
+ /* Do not overwrite errors (e.g. timeout errors) */
+ if (cmd->error == BLK_STS_OK)
+ cmd->error = sts;
out:
nullb_complete_cmd(cmd);
@@ -1451,8 +1454,20 @@ static bool should_requeue_request(struct request *rq)
static enum blk_eh_timer_return null_timeout_rq(struct request *rq, bool res)
{
+ struct nullb_cmd *cmd = blk_mq_rq_to_pdu(rq);
+
pr_info("rq %p timed out\n", rq);
- blk_mq_complete_request(rq);
+
+ /*
+* If the device is marked as blocking (i.e. memory backed or zoned
+* device), the submission path may be blocked waiting for resources
+* and cause real timeouts. For these real timeouts, the submission
+* path will complete the request using blk_mq_complete_request().
+* Only fake timeouts need to execute blk_mq_complete_request() here.
+*/
+ cmd->error = BLK_STS_TIMEOUT;
+ if (cmd->fake_timeout)
+ blk_mq_complete_request(rq);
return BLK_EH_DONE;
}
@@ -1473,6 +1488,7 @@ static blk_status_t null_queue_rq(struct blk_mq_hw_ctx
*hctx,
cmd->rq = bd->rq;
cmd->error = BLK_STS_OK;
cmd->nq = nq;
+ cmd->fake_timeout = should_timeout_request(bd->rq);
blk_mq_start_request(bd->rq);
@@ -1489,7 +1505,7 @@ static blk_status_t null_queue_rq(struct blk_mq_hw_ctx
*hctx,
return BLK_STS_OK;
}
}
- if (should_timeout_request(bd->rq))
+ if (cmd->fake_timeout)
return BLK_STS_OK;
return null_handle_cmd(cmd, sector, nr_sectors, req_op(bd->rq));
diff --git a/drivers/block/null_blk/null_blk.h
b/drivers/block/null_blk/null_blk.h
index 83504f3cc9d6..4876d5adb12d 100644
--- a/drivers/block/null_blk/null_blk.h
+++ b/drivers/block/null_blk/null_blk.h
@@ -22,6 +22,7 @@ struct nullb_cmd {
[PATCH 5.11 02/23] gfs2: Flag a withdraw if init_threads() fails
From: Andrew Price
[ Upstream commit 62dd0f98a0e5668424270b47a0c2e973795faba7 ]
Interrupting mount with ^C quickly enough can cause the kthread_run()
calls in gfs2's init_threads() to fail and the error path leads to a
deadlock on the s_umount rwsem. The abridged chain of events is:
[mount path]
get_tree_bdev()
sget_fc()
alloc_super()
down_write_nested(>s_umount, SINGLE_DEPTH_NESTING); [acquired]
gfs2_fill_super()
gfs2_make_fs_rw()
init_threads()
kthread_run()
( Interrupted )
[Error path]
gfs2_gl_hash_clear()
flush_workqueue(glock_workqueue)
wait_for_completion()
[workqueue context]
glock_work_func()
run_queue()
do_xmote()
freeze_go_sync()
freeze_super()
down_write(>s_umount) [deadlock]
In freeze_go_sync() there is a gfs2_withdrawn() check that we can use to
make sure freeze_super() is not called in the error path, so add a
gfs2_withdraw_delayed() call when init_threads() fails.
Ref: https://bugzilla.kernel.org/show_bug.cgi?id=212231
Reported-by: Alexander Aring
Signed-off-by: Andrew Price
Signed-off-by: Andreas Gruenbacher
Signed-off-by: Sasha Levin
---
fs/gfs2/super.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/fs/gfs2/super.c b/fs/gfs2/super.c
index 754ea2a137b4..34ca312457a6 100644
--- a/fs/gfs2/super.c
+++ b/fs/gfs2/super.c
@@ -169,8 +169,10 @@ int gfs2_make_fs_rw(struct gfs2_sbd *sdp)
int error;
error = init_threads(sdp);
- if (error)
+ if (error) {
+ gfs2_withdraw_delayed(sdp);
return error;
+ }
j_gl->gl_ops->go_inval(j_gl, DIO_METADATA);
if (gfs2_withdrawn(sdp)) {
--
2.30.2
[PATCH 5.11 20/23] block: dont ignore REQ_NOWAIT for direct IO
From: Pavel Begunkov [ Upstream commit f8b78caf21d5bc3fcfc40c18898f9d52ed1451a5 ] If IOCB_NOWAIT is set on submission, then that needs to get propagated to REQ_NOWAIT on the block side. Otherwise we completely lose this information, and any issuer of IOCB_NOWAIT IO will potentially end up blocking on eg request allocation on the storage side. Signed-off-by: Pavel Begunkov Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin --- fs/block_dev.c | 4 1 file changed, 4 insertions(+) diff --git a/fs/block_dev.c b/fs/block_dev.c index 85500e2400cf..b988f78ad4b7 100644 --- a/fs/block_dev.c +++ b/fs/block_dev.c @@ -276,6 +276,8 @@ __blkdev_direct_IO_simple(struct kiocb *iocb, struct iov_iter *iter, bio.bi_opf = dio_bio_write_op(iocb); task_io_account_write(ret); } + if (iocb->ki_flags & IOCB_NOWAIT) + bio.bi_opf |= REQ_NOWAIT; if (iocb->ki_flags & IOCB_HIPRI) bio_set_polled(, iocb); @@ -429,6 +431,8 @@ __blkdev_direct_IO(struct kiocb *iocb, struct iov_iter *iter, int nr_pages) bio->bi_opf = dio_bio_write_op(iocb); task_io_account_write(bio->bi_iter.bi_size); } + if (iocb->ki_flags & IOCB_NOWAIT) + bio->bi_opf |= REQ_NOWAIT; dio->size += bio->bi_iter.bi_size; pos += bio->bi_iter.bi_size; -- 2.30.2
[PATCH 5.11 19/23] riscv,entry: fix misaligned base for excp_vect_table
From: Zihao Yu [ Upstream commit ac8d0b901f0033b783156ab2dc1a0e73ec42409b ] In RV64, the size of each entry in excp_vect_table is 8 bytes. If the base of the table is not 8-byte aligned, loading an entry in the table will raise a misaligned exception. Although such exception will be handled by opensbi/bbl, this still causes performance degradation. Signed-off-by: Zihao Yu Reviewed-by: Anup Patel Signed-off-by: Palmer Dabbelt Signed-off-by: Sasha Levin --- arch/riscv/kernel/entry.S | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/riscv/kernel/entry.S b/arch/riscv/kernel/entry.S index 744f3209c48d..76274a4a1d8e 100644 --- a/arch/riscv/kernel/entry.S +++ b/arch/riscv/kernel/entry.S @@ -447,6 +447,7 @@ ENDPROC(__switch_to) #endif .section ".rodata" + .align LGREG /* Exception vector table */ ENTRY(excp_vect_table) RISCV_PTR do_trap_insn_misaligned -- 2.30.2
[PATCH 5.11 22/23] perf map: Tighten snprintf() string precision to pass gcc check on some 32-bit arches
From: Arnaldo Carvalho de Melo
commit 77d02bd00cea9f1a87afe58113fa75b983d6c23a upstream.
Noticed on a debian:experimental mips and mipsel cross build build
environment:
perfbuilder@ec265a086e9b:~$ mips-linux-gnu-gcc --version | head -1
mips-linux-gnu-gcc (Debian 10.2.1-3) 10.2.1 20201224
perfbuilder@ec265a086e9b:~$
CC /tmp/build/perf/util/map.o
util/map.c: In function 'map__new':
util/map.c:109:5: error: '%s' directive output may be truncated writing
between 1 and 2147483645 bytes into a region of size 4096
[-Werror=format-truncation=]
109 |"%s/platforms/%s/arch-%s/usr/lib/%s",
| ^~
In file included from /usr/mips-linux-gnu/include/stdio.h:867,
from util/symbol.h:11,
from util/map.c:2:
/usr/mips-linux-gnu/include/bits/stdio2.h:67:10: note:
'__builtin___snprintf_chk' output 32 or more bytes (assuming 4294967321) into a
destination of size 4096
67 | return __builtin___snprintf_chk (__s, __n, __USE_FORTIFY_LEVEL - 1,
| ^~~~
68 |__bos (__s), __fmt, __va_arg_pack ());
|~
cc1: all warnings being treated as errors
Since we have the lenghts for what lands in that place, use it to give
the compiler more info and make it happy.
Signed-off-by: Arnaldo Carvalho de Melo
Cc: Anders Roxell
Signed-off-by: Greg Kroah-Hartman
---
tools/perf/util/map.c |7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
--- a/tools/perf/util/map.c
+++ b/tools/perf/util/map.c
@@ -77,8 +77,7 @@ static inline bool replace_android_lib(c
if (strstarts(filename, "/system/lib/")) {
char *ndk, *app;
const char *arch;
- size_t ndk_length;
- size_t app_length;
+ int ndk_length, app_length;
ndk = getenv("NDK_ROOT");
app = getenv("APP_PLATFORM");
@@ -106,8 +105,8 @@ static inline bool replace_android_lib(c
if (new_length > PATH_MAX)
return false;
snprintf(newfilename, new_length,
- "%s/platforms/%s/arch-%s/usr/lib/%s",
- ndk, app, arch, libname);
+ "%.*s/platforms/%.*s/arch-%s/usr/lib/%s",
+ ndk_length, ndk, app_length, app, arch, libname);
return true;
}
[PATCH 5.11 21/23] netfilter: x_tables: fix compat match/target pad out-of-bound write
From: Florian Westphal
commit b29c457a6511435960115c0f548c4360d5f4801d upstream.
xt_compat_match/target_from_user doesn't check that zeroing the area
to start of next rule won't write past end of allocated ruleset blob.
Remove this code and zero the entire blob beforehand.
Reported-by: syzbot+cfc0247ac173f597a...@syzkaller.appspotmail.com
Reported-by: Andy Nguyen
Fixes: 9fa492cdc160c ("[NETFILTER]: x_tables: simplify compat API")
Signed-off-by: Florian Westphal
Signed-off-by: Pablo Neira Ayuso
Signed-off-by: Greg Kroah-Hartman
---
net/ipv4/netfilter/arp_tables.c |2 ++
net/ipv4/netfilter/ip_tables.c |2 ++
net/ipv6/netfilter/ip6_tables.c |2 ++
net/netfilter/x_tables.c| 10 ++
4 files changed, 8 insertions(+), 8 deletions(-)
--- a/net/ipv4/netfilter/arp_tables.c
+++ b/net/ipv4/netfilter/arp_tables.c
@@ -1193,6 +1193,8 @@ static int translate_compat_table(struct
if (!newinfo)
goto out_unlock;
+ memset(newinfo->entries, 0, size);
+
newinfo->number = compatr->num_entries;
for (i = 0; i < NF_ARP_NUMHOOKS; i++) {
newinfo->hook_entry[i] = compatr->hook_entry[i];
--- a/net/ipv4/netfilter/ip_tables.c
+++ b/net/ipv4/netfilter/ip_tables.c
@@ -1428,6 +1428,8 @@ translate_compat_table(struct net *net,
if (!newinfo)
goto out_unlock;
+ memset(newinfo->entries, 0, size);
+
newinfo->number = compatr->num_entries;
for (i = 0; i < NF_INET_NUMHOOKS; i++) {
newinfo->hook_entry[i] = compatr->hook_entry[i];
--- a/net/ipv6/netfilter/ip6_tables.c
+++ b/net/ipv6/netfilter/ip6_tables.c
@@ -1443,6 +1443,8 @@ translate_compat_table(struct net *net,
if (!newinfo)
goto out_unlock;
+ memset(newinfo->entries, 0, size);
+
newinfo->number = compatr->num_entries;
for (i = 0; i < NF_INET_NUMHOOKS; i++) {
newinfo->hook_entry[i] = compatr->hook_entry[i];
--- a/net/netfilter/x_tables.c
+++ b/net/netfilter/x_tables.c
@@ -733,7 +733,7 @@ void xt_compat_match_from_user(struct xt
{
const struct xt_match *match = m->u.kernel.match;
struct compat_xt_entry_match *cm = (struct compat_xt_entry_match *)m;
- int pad, off = xt_compat_match_offset(match);
+ int off = xt_compat_match_offset(match);
u_int16_t msize = cm->u.user.match_size;
char name[sizeof(m->u.user.name)];
@@ -743,9 +743,6 @@ void xt_compat_match_from_user(struct xt
match->compat_from_user(m->data, cm->data);
else
memcpy(m->data, cm->data, msize - sizeof(*cm));
- pad = XT_ALIGN(match->matchsize) - match->matchsize;
- if (pad > 0)
- memset(m->data + match->matchsize, 0, pad);
msize += off;
m->u.user.match_size = msize;
@@ -1116,7 +1113,7 @@ void xt_compat_target_from_user(struct x
{
const struct xt_target *target = t->u.kernel.target;
struct compat_xt_entry_target *ct = (struct compat_xt_entry_target *)t;
- int pad, off = xt_compat_target_offset(target);
+ int off = xt_compat_target_offset(target);
u_int16_t tsize = ct->u.user.target_size;
char name[sizeof(t->u.user.name)];
@@ -1126,9 +1123,6 @@ void xt_compat_target_from_user(struct x
target->compat_from_user(t->data, ct->data);
else
memcpy(t->data, ct->data, tsize - sizeof(*ct));
- pad = XT_ALIGN(target->targetsize) - target->targetsize;
- if (pad > 0)
- memset(t->data + target->targetsize, 0, pad);
tsize += off;
t->u.user.target_size = tsize;
[PATCH 5.11 16/23] idr test suite: Create anchor before launching throbber
From: Matthew Wilcox (Oracle)
[ Upstream commit 094ffbd1d8eaa27ed426feb8530cb1456348b018 ]
The throbber could race with creation of the anchor entry and cause the
IDR to have zero entries in it, which would cause the test to fail.
Signed-off-by: Matthew Wilcox (Oracle)
Signed-off-by: Sasha Levin
---
tools/testing/radix-tree/idr-test.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/testing/radix-tree/idr-test.c
b/tools/testing/radix-tree/idr-test.c
index 4a9b451b7ba0..6ce7460f3c7a 100644
--- a/tools/testing/radix-tree/idr-test.c
+++ b/tools/testing/radix-tree/idr-test.c
@@ -301,11 +301,11 @@ void idr_find_test_1(int anchor_id, int throbber_id)
pthread_t throbber;
time_t start = time(NULL);
- pthread_create(, NULL, idr_throbber, _id);
-
BUG_ON(idr_alloc(_idr, xa_mk_value(anchor_id), anchor_id,
anchor_id + 1, GFP_KERNEL) != anchor_id);
+ pthread_create(, NULL, idr_throbber, _id);
+
rcu_read_lock();
do {
int id = 0;
--
2.30.2
[PATCH 5.11 23/23] net: sfp: cope with SFPs that set both LOS normal and LOS inverted
From: Russell King
commit 624407d2cf14ff58e53bf4b2af9595c4f21d606e upstream.
The SFP MSA defines two option bits in byte 65 to indicate how the
Rx_LOS signal on SFP pin 8 behaves:
bit 2 - Loss of Signal implemented, signal inverted from standard
definition in SFP MSA (often called "Signal Detect").
bit 1 - Loss of Signal implemented, signal as defined in SFP MSA
(often called "Rx_LOS").
Clearly, setting both bits results in a meaningless situation: it would
mean that LOS is implemented in both the normal sense (1 = signal loss)
and inverted sense (0 = signal loss).
Unfortunately, there are modules out there which set both bits, which
will be initially interpret as "inverted" sense, and then, if the LOS
signal changes state, we will toggle between LINK_UP and WAIT_LOS
states.
Change our LOS handling to give well defined behaviour: only interpret
these bits as meaningful if exactly one is set, otherwise treat it as
if LOS is not implemented.
Signed-off-by: Russell King
Reviewed-by: Andrew Lunn
Link: https://lore.kernel.org/r/e1kyyqa-0004ir...@rmk-pc.armlinux.org.uk
Signed-off-by: Jakub Kicinski
Cc: Pali Rohár
Signed-off-by: Greg Kroah-Hartman
---
drivers/net/phy/sfp.c | 36 ++--
1 file changed, 22 insertions(+), 14 deletions(-)
--- a/drivers/net/phy/sfp.c
+++ b/drivers/net/phy/sfp.c
@@ -1501,15 +1501,19 @@ static void sfp_sm_link_down(struct sfp
static void sfp_sm_link_check_los(struct sfp *sfp)
{
- unsigned int los = sfp->state & SFP_F_LOS;
+ const __be16 los_inverted = cpu_to_be16(SFP_OPTIONS_LOS_INVERTED);
+ const __be16 los_normal = cpu_to_be16(SFP_OPTIONS_LOS_NORMAL);
+ __be16 los_options = sfp->id.ext.options & (los_inverted | los_normal);
+ bool los = false;
/* If neither SFP_OPTIONS_LOS_INVERTED nor SFP_OPTIONS_LOS_NORMAL
-* are set, we assume that no LOS signal is available.
+* are set, we assume that no LOS signal is available. If both are
+* set, we assume LOS is not implemented (and is meaningless.)
*/
- if (sfp->id.ext.options & cpu_to_be16(SFP_OPTIONS_LOS_INVERTED))
- los ^= SFP_F_LOS;
- else if (!(sfp->id.ext.options & cpu_to_be16(SFP_OPTIONS_LOS_NORMAL)))
- los = 0;
+ if (los_options == los_inverted)
+ los = !(sfp->state & SFP_F_LOS);
+ else if (los_options == los_normal)
+ los = !!(sfp->state & SFP_F_LOS);
if (los)
sfp_sm_next(sfp, SFP_S_WAIT_LOS, 0);
@@ -1519,18 +1523,22 @@ static void sfp_sm_link_check_los(struct
static bool sfp_los_event_active(struct sfp *sfp, unsigned int event)
{
- return (sfp->id.ext.options & cpu_to_be16(SFP_OPTIONS_LOS_INVERTED) &&
- event == SFP_E_LOS_LOW) ||
- (sfp->id.ext.options & cpu_to_be16(SFP_OPTIONS_LOS_NORMAL) &&
- event == SFP_E_LOS_HIGH);
+ const __be16 los_inverted = cpu_to_be16(SFP_OPTIONS_LOS_INVERTED);
+ const __be16 los_normal = cpu_to_be16(SFP_OPTIONS_LOS_NORMAL);
+ __be16 los_options = sfp->id.ext.options & (los_inverted | los_normal);
+
+ return (los_options == los_inverted && event == SFP_E_LOS_LOW) ||
+ (los_options == los_normal && event == SFP_E_LOS_HIGH);
}
static bool sfp_los_event_inactive(struct sfp *sfp, unsigned int event)
{
- return (sfp->id.ext.options & cpu_to_be16(SFP_OPTIONS_LOS_INVERTED) &&
- event == SFP_E_LOS_HIGH) ||
- (sfp->id.ext.options & cpu_to_be16(SFP_OPTIONS_LOS_NORMAL) &&
- event == SFP_E_LOS_LOW);
+ const __be16 los_inverted = cpu_to_be16(SFP_OPTIONS_LOS_INVERTED);
+ const __be16 los_normal = cpu_to_be16(SFP_OPTIONS_LOS_NORMAL);
+ __be16 los_options = sfp->id.ext.options & (los_inverted | los_normal);
+
+ return (los_options == los_inverted && event == SFP_E_LOS_HIGH) ||
+ (los_options == los_normal && event == SFP_E_LOS_LOW);
}
static void sfp_sm_fault(struct sfp *sfp, unsigned int next_state, bool warn)
[PATCH 5.11 06/23] gfs2: report "already frozen/thawed" errors
From: Bob Peterson
[ Upstream commit ff132c5f93c06bd4432bbab5c369e468653bdec4 ]
Before this patch, gfs2's freeze function failed to report an error
when the target file system was already frozen as it should (and as
generic vfs function freeze_super does. Similarly, gfs2's thaw function
failed to report an error when trying to thaw a file system that is not
frozen, as vfs function thaw_super does. The errors were checked, but
it always returned a 0 return code.
This patch adds the missing error return codes to gfs2 freeze and thaw.
Signed-off-by: Bob Peterson
Signed-off-by: Andreas Gruenbacher
Signed-off-by: Sasha Levin
---
fs/gfs2/super.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/fs/gfs2/super.c b/fs/gfs2/super.c
index 34ca312457a6..223ebd6b1b8d 100644
--- a/fs/gfs2/super.c
+++ b/fs/gfs2/super.c
@@ -767,11 +767,13 @@ void gfs2_freeze_func(struct work_struct *work)
static int gfs2_freeze(struct super_block *sb)
{
struct gfs2_sbd *sdp = sb->s_fs_info;
- int error = 0;
+ int error;
mutex_lock(>sd_freeze_mutex);
- if (atomic_read(>sd_freeze_state) != SFS_UNFROZEN)
+ if (atomic_read(>sd_freeze_state) != SFS_UNFROZEN) {
+ error = -EBUSY;
goto out;
+ }
for (;;) {
if (gfs2_withdrawn(sdp)) {
@@ -812,10 +814,10 @@ static int gfs2_unfreeze(struct super_block *sb)
struct gfs2_sbd *sdp = sb->s_fs_info;
mutex_lock(>sd_freeze_mutex);
-if (atomic_read(>sd_freeze_state) != SFS_FROZEN ||
+ if (atomic_read(>sd_freeze_state) != SFS_FROZEN ||
!gfs2_holder_initialized(>sd_freeze_gh)) {
mutex_unlock(>sd_freeze_mutex);
-return 0;
+ return -EINVAL;
}
gfs2_freeze_unlock(>sd_freeze_gh);
--
2.30.2
[PATCH 5.11 05/23] drm/imx: imx-ldb: fix out of bounds array access warning
From: Arnd Bergmann
[ Upstream commit 33ce7f2f95cabb5834cf0906308a5cb6103976da ]
When CONFIG_OF is disabled, building with 'make W=1' produces warnings
about out of bounds array access:
drivers/gpu/drm/imx/imx-ldb.c: In function 'imx_ldb_set_clock.constprop':
drivers/gpu/drm/imx/imx-ldb.c:186:8: error: array subscript -22 is below array
bounds of 'struct clk *[4]' [-Werror=array-bounds]
Add an error check before the index is used, which helps with the
warning, as well as any possible other error condition that may be
triggered at runtime.
The warning could be fixed by adding a Kconfig depedency on CONFIG_OF,
but Liu Ying points out that the driver may hit the out-of-bounds
problem at runtime anyway.
Signed-off-by: Arnd Bergmann
Reviewed-by: Liu Ying
Signed-off-by: Philipp Zabel
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/imx/imx-ldb.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/imx/imx-ldb.c b/drivers/gpu/drm/imx/imx-ldb.c
index 41e2978cb1eb..75036aaa0c63 100644
--- a/drivers/gpu/drm/imx/imx-ldb.c
+++ b/drivers/gpu/drm/imx/imx-ldb.c
@@ -190,6 +190,11 @@ static void imx_ldb_encoder_enable(struct drm_encoder
*encoder)
int dual = ldb->ldb_ctrl & LDB_SPLIT_MODE_EN;
int mux = drm_of_encoder_active_port_id(imx_ldb_ch->child, encoder);
+ if (mux < 0 || mux >= ARRAY_SIZE(ldb->clk_sel)) {
+ dev_warn(ldb->dev, "%s: invalid mux %d\n", __func__, mux);
+ return;
+ }
+
drm_panel_prepare(imx_ldb_ch->panel);
if (dual) {
@@ -248,6 +253,11 @@ imx_ldb_encoder_atomic_mode_set(struct drm_encoder
*encoder,
int mux = drm_of_encoder_active_port_id(imx_ldb_ch->child, encoder);
u32 bus_format = imx_ldb_ch->bus_format;
+ if (mux < 0 || mux >= ARRAY_SIZE(ldb->clk_sel)) {
+ dev_warn(ldb->dev, "%s: invalid mux %d\n", __func__, mux);
+ return;
+ }
+
if (mode->clock > 17) {
dev_warn(ldb->dev,
"%s: mode exceeds 170 MHz pixel clock\n", __func__);
--
2.30.2
[PATCH 5.11 08/23] tools/kvm_stat: Add restart delay
From: Stefan Raspl [ Upstream commit 75f94ecbd0dfd2ac4e671f165f5ae864b7301422 ] If this service is enabled and the system rebooted, Systemd's initial attempt to start this unit file may fail in case the kvm module is not loaded. Since we did not specify a delay for the retries, Systemd restarts with a minimum delay a number of times before giving up and disabling the service. Which means a subsequent kvm module load will have kvm running without monitoring. Adding a delay to fix this. Signed-off-by: Stefan Raspl Message-Id: <20210325122949.1433271-1-ra...@linux.ibm.com> Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin --- tools/kvm/kvm_stat/kvm_stat.service | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/kvm/kvm_stat/kvm_stat.service b/tools/kvm/kvm_stat/kvm_stat.service index 71aabaffe779..8f13b843d5b4 100644 --- a/tools/kvm/kvm_stat/kvm_stat.service +++ b/tools/kvm/kvm_stat/kvm_stat.service @@ -9,6 +9,7 @@ Type=simple ExecStart=/usr/bin/kvm_stat -dtcz -s 10 -L /var/log/kvm_stat.csv ExecReload=/bin/kill -HUP $MAINPID Restart=always +RestartSec=60s SyslogIdentifier=kvm_stat SyslogLevel=debug -- 2.30.2
[PATCH 5.11 04/23] KVM: arm64: Disable guest access to trace filter controls
From: Suzuki K Poulose [ Upstream commit a354a64d91eec3e0f8ef0eed575b480fd75b999c ] Disable guest access to the Trace Filter control registers. We do not advertise the Trace filter feature to the guest (ID_AA64DFR0_EL1: TRACE_FILT is cleared) already, but the guest can still access the TRFCR_EL1 unless we trap it. This will also make sure that the guest cannot fiddle with the filtering controls set by a nvhe host. Cc: Marc Zyngier Cc: Will Deacon Cc: Mark Rutland Cc: Catalin Marinas Signed-off-by: Suzuki K Poulose Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/20210323120647.454211-3-suzuki.poul...@arm.com Signed-off-by: Sasha Levin --- arch/arm64/include/asm/kvm_arm.h | 1 + arch/arm64/kvm/debug.c | 2 ++ 2 files changed, 3 insertions(+) diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h index 4e90c2debf70..94d4025acc0b 100644 --- a/arch/arm64/include/asm/kvm_arm.h +++ b/arch/arm64/include/asm/kvm_arm.h @@ -278,6 +278,7 @@ #define CPTR_EL2_DEFAULT CPTR_EL2_RES1 /* Hyp Debug Configuration Register bits */ +#define MDCR_EL2_TTRF (1 << 19) #define MDCR_EL2_TPMS (1 << 14) #define MDCR_EL2_E2PB_MASK (UL(0x3)) #define MDCR_EL2_E2PB_SHIFT(UL(12)) diff --git a/arch/arm64/kvm/debug.c b/arch/arm64/kvm/debug.c index 7a7e425616b5..dbc890511631 100644 --- a/arch/arm64/kvm/debug.c +++ b/arch/arm64/kvm/debug.c @@ -89,6 +89,7 @@ void kvm_arm_reset_debug_ptr(struct kvm_vcpu *vcpu) * - Debug ROM Address (MDCR_EL2_TDRA) * - OS related registers (MDCR_EL2_TDOSA) * - Statistical profiler (MDCR_EL2_TPMS/MDCR_EL2_E2PB) + * - Self-hosted Trace Filter controls (MDCR_EL2_TTRF) * * Additionally, KVM only traps guest accesses to the debug registers if * the guest is not actively using them (see the KVM_ARM64_DEBUG_DIRTY @@ -112,6 +113,7 @@ void kvm_arm_setup_debug(struct kvm_vcpu *vcpu) vcpu->arch.mdcr_el2 = __this_cpu_read(mdcr_el2) & MDCR_EL2_HPMN_MASK; vcpu->arch.mdcr_el2 |= (MDCR_EL2_TPM | MDCR_EL2_TPMS | + MDCR_EL2_TTRF | MDCR_EL2_TPMCR | MDCR_EL2_TDRA | MDCR_EL2_TDOSA); -- 2.30.2
[PATCH 0/2] MCAN: Add support for implementing transceiver as a phy
The following series of patches add support for implementing the transceiver as a phy of m_can_platform driver. TCAN1042 has a standby signal that needs to be pulled high for sending/receiving messages[1]. TCAN1043 has a enable signal along with standby signal that needs to be pulled up for sending/receiving messages[2], and other combinations of the two lines can be used to put the transceiver in different states to reduce power consumption. On boards like the AM654-idk and J721e-evm these signals are controlled using gpios. These gpios are set in phy driver, and the transceiver can be put in different states using phy API. The phy driver is added in the series [3]. [1] - https://www.ti.com/lit/ds/symlink/tcan1042h.pdf [2] - https://www.ti.com/lit/ds/symlink/tcan1043-q1.pdf [3] - https://lore.kernel.org/patchwork/project/lkml/list/?series=495365 Faiz Abbas (2): dt-bindings: net: can: Document transceiver implementation as phy can: m_can: Add support for transceiver as phy .../devicetree/bindings/net/can/bosch,m_can.yaml| 3 +++ drivers/net/can/m_can/m_can.c | 10 ++ drivers/net/can/m_can/m_can.h | 2 ++ drivers/net/can/m_can/m_can_platform.c | 13 + 4 files changed, 28 insertions(+) -- 2.17.1
Re: [PATCH] PM / EM: Inefficient OPPs detection
On Thursday 15 Apr 2021 at 15:12:08 (+0100), Vincent Donnefort wrote:
> On Thu, Apr 15, 2021 at 01:12:05PM +, Quentin Perret wrote:
> > Hi Vincent,
> >
> > On Thursday 08 Apr 2021 at 18:10:29 (+0100), Vincent Donnefort wrote:
> > > Some SoCs, such as the sd855 have OPPs within the same performance domain,
> > > whose cost is higher than others with a higher frequency. Even though
> > > those OPPs are interesting from a cooling perspective, it makes no sense
> > > to use them when the device can run at full capacity. Those OPPs handicap
> > > the performance domain, when choosing the most energy-efficient CPU and
> > > are wasting energy. They are inefficient.
> > >
> > > Hence, add support for such OPPs to the Energy Model, which creates for
> > > each OPP a performance state. The Energy Model can now be read using the
> > > regular table, which contains all performance states available, or using
> > > an efficient table, where inefficient performance states (and by
> > > extension, inefficient OPPs) have been removed.
> > >
> > > Currently, the efficient table is used in two paths. Schedutil, and
> > > find_energy_efficient_cpu(). We have to modify both paths in the same
> > > patch so they stay synchronized. The thermal framework still relies on
> > > the original table and hence, DevFreq devices won't create the efficient
> > > table.
> > >
> > > As used in the hot-path, the efficient table is a lookup table, generated
> > > dynamically when the perf domain is created. The complexity of searching
> > > a performance state is hence changed from O(n) to O(1). This also
> > > speeds-up em_cpu_energy() even if no inefficient OPPs have been found.
> >
> > Interesting. Do you have measurements showing the benefits on wake-up
> > duration? I remember doing so by hacking the wake-up path to force tasks
> > into feec()/compute_energy() even when overutilized, and then running
> > hackbench. Maybe something like that would work for you?
>
> I'll give a try and see if I get improved numbers.
>
> >
> > Just want to make sure we actually need all that complexity -- while
> > it's good to reduce the asymptotic complexity, we're looking at a rather
> > small problem (max 30 OPPs or so I expect?), so other effects may be
> > dominating. Simply skipping inefficient OPPs could be implemented in a
> > much simpler way I think.
>
> I could indeed just skip the perf state if marked as ineffective. But the idea
> was to avoid bringing another for loop in this hot-path.
Right, though it would just extend a little bit the existing loop, so
the overhead is unlikely to be noticeable.
> Also, not covered by this patch but probably we could get rid of the EM
> complexity limit as the table resolution is way faster with this change.
Probably yeah. I was considering removing it since eb92692b2544
("sched/fair: Speed-up energy-aware wake-ups") but ended up keeping it
as it's entirely untested on large systems. But maybe we can reconsider.
Thanks,
Quentin
[PATCH 1/2] dt-bindings: net: can: Document transceiver implementation as phy
From: Faiz Abbas Some transceivers need a configuration step (for example, pulling the standby or enable lines) for them to start sending messages. The transceiver can be implemented as a phy with the configuration done in the phy driver. The bit rate limitation can the be obtained by the driver using the phy node. Document the above implementation in the bosch mcan bindings Signed-off-by: Faiz Abbas Signed-off-by: Aswath Govindraju --- Documentation/devicetree/bindings/net/can/bosch,m_can.yaml | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml b/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml index 798fa5fb7bb2..25f74db46bae 100644 --- a/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml +++ b/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml @@ -109,6 +109,9 @@ properties: can-transceiver: $ref: can-transceiver.yaml# + phys: +maxItems: 1 + required: - compatible - reg -- 2.17.1
Re: [PATCH v3] PCI: dwc: move dw_pcie_msi_init() to dw_pcie_setup_rc()
On Thu, 25 Mar 2021 15:26:04 +0800, Jisheng Zhang wrote: > If the host which makes use of IP's integrated MSI Receiver losts > power during suspend, we need to reinit the RC and MSI Receiver in > resume. But after we move dw_pcie_msi_init() into the core, we have no > API to do so. Usually the dwc users need to call dw_pcie_setup_rc() to > reinit the RC, we can solve this problem by moving dw_pcie_msi_init() > to dw_pcie_setup_rc(). Applied to pci/dwc, thanks! [1/1] PCI: dwc: Move dw_pcie_msi_init() to dw_pcie_setup_rc() https://git.kernel.org/lpieralisi/pci/c/fe08db2835 Thanks, Lorenzo
Re: [PATCH] arm64: dts: marvell: armada-37xx: Set linux,pci-domain to zero
On Thu, Apr 15, 2021 at 3:45 AM Marek Behun wrote:
>
> On Thu, 15 Apr 2021 10:36:40 +0200
> Pali Rohár wrote:
>
> > On Tuesday 13 April 2021 13:17:29 Rob Herring wrote:
> > > On Mon, Apr 12, 2021 at 7:41 AM Pali Rohár wrote:
> > > >
> > > > Since commit 526a76991b7b ("PCI: aardvark: Implement driver 'remove'
> > > > function and allow to build it as module") PCIe controller driver for
> > > > Armada 37xx can be dynamically loaded and unloaded at runtime. Also
> > > > driver
> > > > allows dynamic binding and unbinding of PCIe controller device.
> > > >
> > > > Kernel PCI subsystem assigns by default dynamically allocated PCI domain
> > > > number (starting from zero) for this PCIe controller every time when
> > > > device
> > > > is bound. So PCI domain changes after every unbind / bind operation.
> > >
> > > PCI host bridges as a module are relatively new, so seems likely a bug to
> > > me.
> >
> > Why a bug? It is there since 5.10 and it is working.
I mean historically, the PCI subsystem didn't even support host
bridges as a module. They weren't even proper drivers and it was all
arch specific code. Most of the host bridge drivers are still built-in
only. This seems like a small detail that was easily overlooked.
unbind is not a well tested path.
> > > > Alternative way for assigning PCI domain number is to use static
> > > > allocated
> > > > numbers defined in Device Tree. This option has requirement that every
> > > > PCI
> > > > controller in system must have defined PCI bus number in Device Tree.
> > >
> > > That seems entirely pointless from a DT point of view with a single PCI
> > > bridge.
> >
> > If domain id is not specified in DT then kernel uses counter and assigns
> > counter++. So it is not pointless if we want to have stable domain id.
>
> What Rob is trying to say is that
> - the bug is that kernel assigns counter++
> - device-tree should not be used to fix problems with how kernel does
> things
> - if a device has only one PCIe controller, it is pointless to define
> it's pci-domain. If there were multiple controllers, then it would
> make sense, but there is only one
Yes. I think what we want here is a domain bitmap rather than a
counter and we assign the lowest free bit. That could also allow for
handling a mixture of fixed domain numbers and dynamically assigned
ones.
You could create scenarios where the numbers change on you, but it
wouldn't be any different than say plugging in USB serial adapters.
You get the same ttyUSBx device when you re-attach unless there's been
other ttyUSBx devices attached/detached.
Rob
[PATCH 2/2] can: m_can: Add support for transceiver as phy
From: Faiz Abbas
Add support for implementing transceiver node as phy. The max_bitrate is
obtained by getting a phy attribute.
Signed-off-by: Faiz Abbas
Signed-off-by: Aswath Govindraju
---
drivers/net/can/m_can/m_can.c | 10 ++
drivers/net/can/m_can/m_can.h | 2 ++
drivers/net/can/m_can/m_can_platform.c | 13 +
3 files changed, 25 insertions(+)
diff --git a/drivers/net/can/m_can/m_can.c b/drivers/net/can/m_can/m_can.c
index 34073cd077e4..7d31250446c2 100644
--- a/drivers/net/can/m_can/m_can.c
+++ b/drivers/net/can/m_can/m_can.c
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#include "m_can.h"
@@ -1514,6 +1515,7 @@ static void m_can_stop(struct net_device *dev)
static int m_can_close(struct net_device *dev)
{
struct m_can_classdev *cdev = netdev_priv(dev);
+ int err;
netif_stop_queue(dev);
@@ -1536,6 +1538,10 @@ static int m_can_close(struct net_device *dev)
close_candev(dev);
can_led_event(dev, CAN_LED_EVENT_STOP);
+ err = phy_power_off(cdev->transceiver);
+ if (err)
+ return err;
+
return 0;
}
@@ -1720,6 +1726,10 @@ static int m_can_open(struct net_device *dev)
struct m_can_classdev *cdev = netdev_priv(dev);
int err;
+ err = phy_power_on(cdev->transceiver);
+ if (err)
+ return err;
+
err = m_can_clk_start(cdev);
if (err)
return err;
diff --git a/drivers/net/can/m_can/m_can.h b/drivers/net/can/m_can/m_can.h
index ace071c3e58c..38cad068abad 100644
--- a/drivers/net/can/m_can/m_can.h
+++ b/drivers/net/can/m_can/m_can.h
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
/* m_can lec values */
enum m_can_lec_type {
@@ -82,6 +83,7 @@ struct m_can_classdev {
struct workqueue_struct *tx_wq;
struct work_struct tx_work;
struct sk_buff *tx_skb;
+ struct phy *transceiver;
struct can_bittiming_const *bit_timing;
struct can_bittiming_const *data_timing;
diff --git a/drivers/net/can/m_can/m_can_platform.c
b/drivers/net/can/m_can/m_can_platform.c
index 599de0e08cd7..006e13ee7cd7 100644
--- a/drivers/net/can/m_can/m_can_platform.c
+++ b/drivers/net/can/m_can/m_can_platform.c
@@ -6,6 +6,7 @@
// Copyright (C) 2018-19 Texas Instruments Incorporated - http://www.ti.com/
#include
+#include
#include "m_can.h"
@@ -67,6 +68,7 @@ static int m_can_plat_probe(struct platform_device *pdev)
struct resource *res;
void __iomem *addr;
void __iomem *mram_addr;
+ struct phy *transceiver;
int irq, ret = 0;
mcan_class = m_can_class_allocate_dev(>dev,
@@ -101,6 +103,16 @@ static int m_can_plat_probe(struct platform_device *pdev)
goto probe_fail;
}
+ transceiver = devm_of_phy_optional_get_by_index(>dev,
pdev->dev.of_node, 0);
+ if (IS_ERR(transceiver)) {
+ ret = PTR_ERR(transceiver);
+ dev_err(>dev, "error while getting phy, err=%d\n", ret);
+ return ret;
+ }
+
+ if (transceiver)
+ priv->cdev.can.bitrate_max = transceiver->attrs.max_link_rate;
+
priv->base = addr;
priv->mram_base = mram_addr;
@@ -108,6 +120,7 @@ static int m_can_plat_probe(struct platform_device *pdev)
mcan_class->pm_clock_support = 1;
mcan_class->can.clock.freq = clk_get_rate(mcan_class->cclk);
mcan_class->dev = >dev;
+ mcan_class->transceiver = transceiver;
mcan_class->ops = _can_plat_ops;
--
2.17.1
Re: [PATCH 5.10 12/25] radix tree test suite: Fix compilation
On Thu, Apr 15, 2021 at 04:48:06PM +0200, Greg Kroah-Hartman wrote: > From: Matthew Wilcox (Oracle) > > [ Upstream commit 7487de534dcbe143e6f41da751dd3ffcf93b00ee ] > > Commit 4bba4c4bb09a added tools/include/linux/compiler_types.h which > includes linux/compiler-gcc.h. Unfortunately, we had our own (empty) > compiler_types.h which overrode the one added by that commit, and > so we lost the definition of __must_be_array(). Removing our empty > compiler_types.h fixes the problem and reduces our divergence from the > rest of the tools. I don't see 4bba4c4bb09a backported to 5.10.y, so I think this will break compilation of the radix tree test suite. The corresponding commit for 5.11.y is good, since 5.11.y includes 4bba4c4bb09a.
Re: [PATCH v10 03/33] counter: 104-quad-8: Remove pointless comment
On Fri, Mar 19, 2021 at 08:00:22PM +0900, William Breathitt Gray wrote: > It is obvious that devm_counter_register() is used to register a Counter > device, so a comment stating such is pointless here. > > Cc: Syed Nayyar Waris > Signed-off-by: William Breathitt Gray > --- > drivers/counter/104-quad-8.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/counter/104-quad-8.c b/drivers/counter/104-quad-8.c > index 9691f8612be8..4bb9abffae48 100644 > --- a/drivers/counter/104-quad-8.c > +++ b/drivers/counter/104-quad-8.c > @@ -1082,7 +1082,6 @@ static int quad8_probe(struct device *dev, unsigned int > id) > /* Enable all counters */ > outb(QUAD8_CHAN_OP_ENABLE_COUNTERS, base[id] + QUAD8_REG_CHAN_OP); > > - /* Register Counter device */ > return devm_counter_register(dev, >counter); > } > > -- > 2.30.2 > Acked-by: Syed Nayyar Waris
[PATCH 5.10 00/25] 5.10.31-rc1 review
This is the start of the stable review cycle for the 5.10.31 release. There are 25 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sat, 17 Apr 2021 14:44:01 +. Anything received after that time might be too late. The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.31-rc1.gz or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.10.y and the diffstat can be found below. thanks, greg k-h - Pseudo-Shortlog of commits: Greg Kroah-Hartman Linux 5.10.31-rc1 Juergen Gross xen/events: fix setting irq affinity Russell King net: sfp: cope with SFPs that set both LOS normal and LOS inverted Russell King net: sfp: relax bitrate-derived mode check Arnaldo Carvalho de Melo perf map: Tighten snprintf() string precision to pass gcc check on some 32-bit arches Florian Westphal netfilter: x_tables: fix compat match/target pad out-of-bound write Pavel Begunkov block: don't ignore REQ_NOWAIT for direct IO Zihao Yu riscv,entry: fix misaligned base for excp_vect_table Jens Axboe io_uring: don't mark S_ISBLK async work as unbounded Damien Le Moal null_blk: fix command timeout completion handling Matthew Wilcox (Oracle) idr test suite: Create anchor before launching throbber Matthew Wilcox (Oracle) idr test suite: Take RCU read lock in idr_find_test_1 Matthew Wilcox (Oracle) radix tree test suite: Register the main thread with the RCU library Yufen Yu block: only update parent bi_status when bio fail Matthew Wilcox (Oracle) radix tree test suite: Fix compilation Matthew Wilcox (Oracle) XArray: Fix splitting to non-zero orders Mikko Perttunen gpu: host1x: Use different lock classes for each client Dmitry Osipenko drm/tegra: dc: Don't set PLL clock to 0Hz Stefan Raspl tools/kvm_stat: Add restart delay Steven Rostedt (VMware) ftrace: Check if pages were allocated before calling free_pages() Bob Peterson gfs2: report "already frozen/thawed" errors Arnd Bergmann drm/imx: imx-ldb: fix out of bounds array access warning Suzuki K Poulose KVM: arm64: Disable guest access to trace filter controls Suzuki K Poulose KVM: arm64: Hide system instruction access to Trace registers Andrew Price gfs2: Flag a withdraw if init_threads() fails Jia-Ju Bai interconnect: core: fix error return code of icc_link_destroy() - Diffstat: Makefile| 4 +-- arch/arm64/include/asm/kvm_arm.h| 1 + arch/arm64/kernel/cpufeature.c | 1 - arch/arm64/kvm/debug.c | 2 ++ arch/riscv/kernel/entry.S | 1 + block/bio.c | 2 +- drivers/block/null_blk.h| 1 + drivers/block/null_blk_main.c | 26 ++ drivers/gpu/drm/imx/imx-ldb.c | 10 +++ drivers/gpu/drm/tegra/dc.c | 10 +++ drivers/gpu/host1x/bus.c| 10 --- drivers/interconnect/core.c | 2 ++ drivers/net/phy/sfp-bus.c | 11 drivers/net/phy/sfp.c | 36 +++-- drivers/xen/events/events_base.c| 4 +-- fs/block_dev.c | 4 +++ fs/gfs2/super.c | 14 ++ fs/io_uring.c | 2 +- include/linux/host1x.h | 9 ++- kernel/trace/ftrace.c | 9 --- lib/test_xarray.c | 26 +- lib/xarray.c| 4 +-- net/ipv4/netfilter/arp_tables.c | 2 ++ net/ipv4/netfilter/ip_tables.c | 2 ++ net/ipv6/netfilter/ip6_tables.c | 2 ++ net/netfilter/x_tables.c| 10 ++- tools/kvm/kvm_stat/kvm_stat.service | 1 + tools/perf/util/map.c | 7 +++-- tools/testing/radix-tree/idr-test.c | 10 +-- tools/testing/radix-tree/linux/compiler_types.h | 0 tools/testing/radix-tree/multiorder.c | 2 ++ tools/testing/radix-tree/xarray.c | 2 ++ 32 files changed, 149 insertions(+), 78 deletions(-)
[PATCH 5.10 09/25] drm/tegra: dc: Dont set PLL clock to 0Hz
From: Dmitry Osipenko
[ Upstream commit f8fb97c915954fc6de6513cdf277103b5c6df7b3 ]
RGB output doesn't allow to change parent clock rate of the display and
PCLK rate is set to 0Hz in this case. The tegra_dc_commit_state() shall
not set the display clock to 0Hz since this change propagates to the
parent clock. The DISP clock is defined as a NODIV clock by the tegra-clk
driver and all NODIV clocks use the CLK_SET_RATE_PARENT flag.
This bug stayed unnoticed because by default PLLP is used as the parent
clock for the display controller and PLLP silently skips the erroneous 0Hz
rate changes because it always has active child clocks that don't permit
rate changes. The PLLP isn't acceptable for some devices that we want to
upstream (like Samsung Galaxy Tab and ASUS TF700T) due to a display panel
clock rate requirements that can't be fulfilled by using PLLP and then the
bug pops up in this case since parent clock is set to 0Hz, killing the
display output.
Don't touch DC clock if pclk=0 in order to fix the problem.
Signed-off-by: Dmitry Osipenko
Signed-off-by: Thierry Reding
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/tegra/dc.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index 3a244ef7f30f..3aa9a7406085 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -1688,6 +1688,11 @@ static void tegra_dc_commit_state(struct tegra_dc *dc,
dev_err(dc->dev,
"failed to set clock rate to %lu Hz\n",
state->pclk);
+
+ err = clk_set_rate(dc->clk, state->pclk);
+ if (err < 0)
+ dev_err(dc->dev, "failed to set clock %pC to %lu Hz:
%d\n",
+ dc->clk, state->pclk, err);
}
DRM_DEBUG_KMS("rate: %lu, div: %u\n", clk_get_rate(dc->clk),
@@ -1698,11 +1703,6 @@ static void tegra_dc_commit_state(struct tegra_dc *dc,
value = SHIFT_CLK_DIVIDER(state->div) | PIXEL_CLK_DIVIDER_PCD1;
tegra_dc_writel(dc, value, DC_DISP_DISP_CLOCK_CONTROL);
}
-
- err = clk_set_rate(dc->clk, state->pclk);
- if (err < 0)
- dev_err(dc->dev, "failed to set clock %pC to %lu Hz: %d\n",
- dc->clk, state->pclk, err);
}
static void tegra_dc_stop(struct tegra_dc *dc)
--
2.30.2
Re: [PATCH] locking/qrwlock: Fix ordering in queued_write_lock_slowpath
On 4/15/21 10:25 AM, Ali Saidi wrote:
While this code is executed with the wait_lock held, a reader can
acquire the lock without holding wait_lock. The writer side loops
checking the value with the atomic_cond_read_acquire(), but only truly
acquires the lock when the compare-and-exchange is completed
successfully which isn’t ordered. The other atomic operations from this
point are release-ordered and thus reads after the lock acquisition can
be completed before the lock is truly acquired which violates the
guarantees the lock should be making.
Fixes: b519b56e378ee ("locking/qrwlock: Use atomic_cond_read_acquire() when spinning
in qrwloc")
Signed-off-by: Ali Saidi
Cc: sta...@vger.kernel.org
---
kernel/locking/qrwlock.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/locking/qrwlock.c b/kernel/locking/qrwlock.c
index 4786dd271b45..10770f6ac4d9 100644
--- a/kernel/locking/qrwlock.c
+++ b/kernel/locking/qrwlock.c
@@ -73,8 +73,8 @@ void queued_write_lock_slowpath(struct qrwlock *lock)
/* When no more readers or writers, set the locked flag */
do {
- atomic_cond_read_acquire(>cnts, VAL == _QW_WAITING);
- } while (atomic_cmpxchg_relaxed(>cnts, _QW_WAITING,
+ atomic_cond_read_relaxed(>cnts, VAL == _QW_WAITING);
+ } while (atomic_cmpxchg_acquire(>cnts, _QW_WAITING,
_QW_LOCKED) != _QW_WAITING);
unlock:
arch_spin_unlock(>wait_lock);
I think the original code isn't wrong. The read_acquire provides the
acquire barrier for cmpxchg. Because of conditional dependency, the
wait_lock unlock won't happen until the cmpxchg succeeds. Without doing
a read_acquire, there may be a higher likelihood that the cmpxchg may fail.
Anyway, I will let Will or Peter chime in on this as I am not as
proficient as them on this topic.
Cheers,
Longman
Re: [PATCH v10 04/33] counter: 104-quad-8: Return error when invalid mode during ceiling_write
On Fri, Mar 19, 2021 at 08:00:23PM +0900, William Breathitt Gray wrote:
> The 104-QUAD-8 only has two count modes where a ceiling value makes
> sense: Range Limit and Modulo-N. Outside of these two modes, setting a
> ceiling value is an invalid operation -- so let's report it as such by
> returning -EINVAL.
>
> Fixes: fc069262261c ("counter: 104-quad-8: Add lock guards - generic
> interface")
> Cc: Syed Nayyar Waris
> Signed-off-by: William Breathitt Gray
> ---
> drivers/counter/104-quad-8.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/counter/104-quad-8.c b/drivers/counter/104-quad-8.c
> index 4bb9abffae48..233a3acc1377 100644
> --- a/drivers/counter/104-quad-8.c
> +++ b/drivers/counter/104-quad-8.c
> @@ -714,13 +714,14 @@ static ssize_t quad8_count_ceiling_write(struct
> counter_device *counter,
> switch (priv->count_mode[count->id]) {
> case 1:
> case 3:
> + mutex_unlock(>lock);
> quad8_preset_register_set(priv, count->id, ceiling);
> - break;
> + return len;
> }
>
> mutex_unlock(>lock);
>
> - return len;
> + return -EINVAL;
> }
>
> static ssize_t quad8_count_preset_enable_read(struct counter_device *counter,
> --
> 2.30.2
>
Acked-by: Syed Nayyar Waris
Re: [PATCH 0/2] MCAN: Add support for implementing transceiver as a phy
Hi all, On 15/04/21 8:36 pm, Aswath Govindraju wrote: > The following series of patches add support for implementing the > transceiver as a phy of m_can_platform driver. > > TCAN1042 has a standby signal that needs to be pulled high for > sending/receiving messages[1]. TCAN1043 has a enable signal along with > standby signal that needs to be pulled up for sending/receiving > messages[2], and other combinations of the two lines can be used to put the > transceiver in different states to reduce power consumption. On boards > like the AM654-idk and J721e-evm these signals are controlled using gpios. > > These gpios are set in phy driver, and the transceiver can be put in > different states using phy API. The phy driver is added in the series [3]. > > [1] - https://www.ti.com/lit/ds/symlink/tcan1042h.pdf > [2] - https://www.ti.com/lit/ds/symlink/tcan1043-q1.pdf > [3] - https://lore.kernel.org/patchwork/project/lkml/list/?series=495365 > Please ignore this series. I will post a respin using devm_phy_get_optional instead of devm_of_phy_get_optional_by_index() based on the comments below[1]. Sorry for the noise. [1] - https://lore.kernel.org/patchwork/patch/1413931/ Thanks, Aswath > Faiz Abbas (2): > dt-bindings: net: can: Document transceiver implementation as phy > can: m_can: Add support for transceiver as phy > > .../devicetree/bindings/net/can/bosch,m_can.yaml| 3 +++ > drivers/net/can/m_can/m_can.c | 10 ++ > drivers/net/can/m_can/m_can.h | 2 ++ > drivers/net/can/m_can/m_can_platform.c | 13 + > 4 files changed, 28 insertions(+) >
Re: [PATCH 11/11] mm/page_alloc: Embed per_cpu_pages locking within the per-cpu structure
On Thu, Apr 15, 2021 at 04:53:46PM +0200, Vlastimil Babka wrote: > On 4/14/21 3:39 PM, Mel Gorman wrote: > > struct per_cpu_pages is protected by the pagesets lock but it can be > > embedded within struct per_cpu_pages at a minor cost. This is possible > > because per-cpu lookups are based on offsets. Paraphrasing an explanation > > from Peter Ziljstra > > > > The whole thing relies on: > > > > _cpu_ptr(msblk->stream, cpu)->lock == > > per_cpu_ptr(>stream->lock, cpu) > > > > Which is true because the lhs: > > > > (local_lock_t *)((zone->per_cpu_pages + per_cpu_offset(cpu)) + > > offsetof(struct per_cpu_pages, lock)) > > > > and the rhs: > > > > (local_lock_t *)((zone->per_cpu_pages + offsetof(struct per_cpu_pages, > > lock)) + per_cpu_offset(cpu)) > > > > are identical, because addition is associative. > > > > More details are included in mmzone.h. This embedding is not completely > > free for three reasons. > > > > 1. As local_lock does not return a per-cpu structure, the PCP has to > >be looked up twice -- first to acquire the lock and again to get the > >PCP pointer. > > > > 2. For PREEMPT_RT and CONFIG_DEBUG_LOCK_ALLOC, local_lock is potentially > >a spinlock or has lock-specific tracking. In both cases, it becomes > >necessary to release/acquire different locks when freeing a list of > >pages in free_unref_page_list. > > Looks like this pattern could benefit from a local_lock API helper that would > do > the right thing? It probably couldn't optimize much the CONFIG_PREEMPT_RT case > which would need to be unlock/lock in any case, but CONFIG_DEBUG_LOCK_ALLOC > could perhaps just keep the IRQ's disabled and just note the change of what's > acquired? > A helper could potentially be used but right now, there is only one call-site that needs this type of care so it may be overkill. A helper was proposed that can lookup and lock a per-cpu structure which is generally useful but does not suit the case where different locks need to be acquired. > > 3. For most kernel configurations, local_lock_t is empty and no storage is > >required. By embedding the lock, the memory consumption on PREEMPT_RT > >and CONFIG_DEBUG_LOCK_ALLOC is higher. > > But I wonder, is there really a benefit to this increased complexity? Before > the > patch we had "pagesets" - a local_lock that protects all zones' pcplists. Now > each zone's pcplists have own local_lock. On !PREEMPT_RT we will never take > the > locks of multiple zones from the same CPU in parallel, because we use > local_lock_irqsave(). Can that parallelism happen on PREEMPT_RT, because that > could perhaps justify the change? > I don't think PREEMPT_RT gets additional parallelism because it's still a per-cpu structure that is being protected. The difference is whether we are protecting the CPU-N index for all per_cpu_pages or just one. The patch exists because it was asked why the lock was not embedded within the structure it's protecting. I initially thought that was unsafe and I was wrong as explained in the changelog. But now that I find it *can* be done but it's a bit ugly so I put it at the end of the series so it can be dropped if necessary. -- Mel Gorman SUSE Labs
[PATCH] drm/tegra: Fix shift overflow in tegra_shared_plane_atomic_update
Clang warns:
drivers/gpu/drm/tegra/hub.c:513:11: warning: shift count >= width of
type [-Wshift-count-overflow]
base |= BIT(39);
^~~
BIT is unsigned long, which is 32-bit on ARCH=arm, hence the overflow
warning. Switch to BIT_ULL, which is 64-bit and will not overflow.
Fixes: 7b6f846785f4 ("drm/tegra: Support sector layout on Tegra194")
Link: https://github.com/ClangBuiltLinux/linux/issues/1351
Signed-off-by: Nathan Chancellor
---
drivers/gpu/drm/tegra/hub.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tegra/hub.c b/drivers/gpu/drm/tegra/hub.c
index 79bff8b48271..bfae8a02f55b 100644
--- a/drivers/gpu/drm/tegra/hub.c
+++ b/drivers/gpu/drm/tegra/hub.c
@@ -510,7 +510,7 @@ static void tegra_shared_plane_atomic_update(struct
drm_plane *plane,
* dGPU sector layout.
*/
if (tegra_plane_state->tiling.sector_layout ==
TEGRA_BO_SECTOR_LAYOUT_GPU)
- base |= BIT(39);
+ base |= BIT_ULL(39);
#endif
tegra_plane_writel(p, tegra_plane_state->format, DC_WIN_COLOR_DEPTH);
base-commit: 0265531f0897f890da3f9c2958707af099c7d974
--
2.31.1.272.g89b43f80a5
Re: [PATCH] PM / EM: Inefficient OPPs detection
Hi Quentin, On 4/15/21 4:20 PM, Quentin Perret wrote: On Thursday 15 Apr 2021 at 16:14:46 (+0100), Vincent Donnefort wrote: On Thu, Apr 15, 2021 at 02:59:54PM +, Quentin Perret wrote: On Thursday 15 Apr 2021 at 15:34:53 (+0100), Vincent Donnefort wrote: On Thu, Apr 15, 2021 at 01:16:35PM +, Quentin Perret wrote: On Thursday 08 Apr 2021 at 18:10:29 (+0100), Vincent Donnefort wrote: --- a/kernel/sched/cpufreq_schedutil.c +++ b/kernel/sched/cpufreq_schedutil.c @@ -10,6 +10,7 @@ #include "sched.h" +#include #include #include @@ -164,6 +165,9 @@ static unsigned int get_next_freq(struct sugov_policy *sg_policy, freq = map_util_freq(util, freq, max); + /* Avoid inefficient performance states */ + freq = em_pd_get_efficient_freq(em_cpu_get(policy->cpu), freq); I remember this was discussed when Douglas sent his patches some time ago, but I still find it sad we index the EM table here but still re-index the cpufreq frequency table later :/ Yes in your case this lookup is very inexpensive, but still. EAS relies on the EM's table matching cpufreq's accurately, so this second lookup still feels rather unnecessary ... To get only a single lookup, we would need to bring the inefficiency knowledge directly to the cpufreq framework. But it has its own limitations: The cpufreq driver can have its own resolve_freq() callback, which means that not all the drivers would benefit from that feature. The cpufreq_table can be ordered and accessed in several ways which brings many combinations that would need to be supported, ending-up with something much more intrusive. (We can though decide to limit the feature to the low to high access that schedutil needs). As the EM needs schedutil to exist anyway, it seemed to be the right place for this code. It allows any cpufreq driver to benefit from the feature, simplify a potential extension for a usage by devfreq devices and as a bonus it speeds-up energy computing, allowing a more complex Energy Model. I was thinking of something a bit simpler. cpufreq_driver_resolve_freq appears to be used only from schedutil (why is it even then?), so we could just pull it into cpufreq_schedutil.c and just plain skip the call to cpufreq_frequency_table_target if the target freq has been indexed in the EM table -- it should already be matching a real OPP. Thoughts? Quentin Can try that for a V2. That means em_pd_get_efficient_freq() would have to know about policy clamping (but I don't think that's an issue) Indeed, and I think we can even see this as an improvement as EAS will now see policy clamps as well in compute_energy(). Are you sure that the 'policy' can be accessed from compute_energy()? It can be from schedutil freq switch path, but I'm not use about our feec().. For me this cpufreq_driver_resolve_freq sounds a bit out of this patch subject. Regards, Lukasz
Re: [PATCH RFC 01/22] asm-generic/hyperv: add HV_STATUS_ACCESS_DENIED definition
Wei Liu writes: > On Tue, Apr 13, 2021 at 02:26:09PM +0200, Vitaly Kuznetsov wrote: >> From TLFSv6.0b, this status means: "The caller did not possess sufficient >> access rights to perform the requested operation." >> >> Signed-off-by: Vitaly Kuznetsov > > This can be applied to hyperv-next right away. Let me know what you > think. > In case there's no immediate need for this constant outside of KVM, I'd suggest you just give Paolo your 'Acked-by' so I can carry the patch in the series for the time being. This will eliminate the need to track dependencies between hyperv-next and kvm-next. Thanks! -- Vitaly
[PATCH v2 2/2] can: m_can: Add support for transceiver as phy
From: Faiz Abbas
Add support for implementing transceiver node as phy. The max_bitrate is
obtained by getting a phy attribute.
Signed-off-by: Faiz Abbas
Signed-off-by: Aswath Govindraju
---
drivers/net/can/m_can/m_can.c | 10 ++
drivers/net/can/m_can/m_can.h | 2 ++
drivers/net/can/m_can/m_can_platform.c | 13 +
3 files changed, 25 insertions(+)
diff --git a/drivers/net/can/m_can/m_can.c b/drivers/net/can/m_can/m_can.c
index 34073cd077e4..7d31250446c2 100644
--- a/drivers/net/can/m_can/m_can.c
+++ b/drivers/net/can/m_can/m_can.c
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#include "m_can.h"
@@ -1514,6 +1515,7 @@ static void m_can_stop(struct net_device *dev)
static int m_can_close(struct net_device *dev)
{
struct m_can_classdev *cdev = netdev_priv(dev);
+ int err;
netif_stop_queue(dev);
@@ -1536,6 +1538,10 @@ static int m_can_close(struct net_device *dev)
close_candev(dev);
can_led_event(dev, CAN_LED_EVENT_STOP);
+ err = phy_power_off(cdev->transceiver);
+ if (err)
+ return err;
+
return 0;
}
@@ -1720,6 +1726,10 @@ static int m_can_open(struct net_device *dev)
struct m_can_classdev *cdev = netdev_priv(dev);
int err;
+ err = phy_power_on(cdev->transceiver);
+ if (err)
+ return err;
+
err = m_can_clk_start(cdev);
if (err)
return err;
diff --git a/drivers/net/can/m_can/m_can.h b/drivers/net/can/m_can/m_can.h
index ace071c3e58c..38cad068abad 100644
--- a/drivers/net/can/m_can/m_can.h
+++ b/drivers/net/can/m_can/m_can.h
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
/* m_can lec values */
enum m_can_lec_type {
@@ -82,6 +83,7 @@ struct m_can_classdev {
struct workqueue_struct *tx_wq;
struct work_struct tx_work;
struct sk_buff *tx_skb;
+ struct phy *transceiver;
struct can_bittiming_const *bit_timing;
struct can_bittiming_const *data_timing;
diff --git a/drivers/net/can/m_can/m_can_platform.c
b/drivers/net/can/m_can/m_can_platform.c
index 599de0e08cd7..82d4f1a15dd7 100644
--- a/drivers/net/can/m_can/m_can_platform.c
+++ b/drivers/net/can/m_can/m_can_platform.c
@@ -6,6 +6,7 @@
// Copyright (C) 2018-19 Texas Instruments Incorporated - http://www.ti.com/
#include
+#include
#include "m_can.h"
@@ -67,6 +68,7 @@ static int m_can_plat_probe(struct platform_device *pdev)
struct resource *res;
void __iomem *addr;
void __iomem *mram_addr;
+ struct phy *transceiver;
int irq, ret = 0;
mcan_class = m_can_class_allocate_dev(>dev,
@@ -101,6 +103,16 @@ static int m_can_plat_probe(struct platform_device *pdev)
goto probe_fail;
}
+ transceiver = devm_phy_optional_get(>dev, NULL);
+ if (IS_ERR(transceiver)) {
+ ret = PTR_ERR(transceiver);
+ dev_err(>dev, "error while getting phy, err=%d\n", ret);
+ return ret;
+ }
+
+ if (transceiver)
+ priv->cdev.can.bitrate_max = transceiver->attrs.max_link_rate;
+
priv->base = addr;
priv->mram_base = mram_addr;
@@ -108,6 +120,7 @@ static int m_can_plat_probe(struct platform_device *pdev)
mcan_class->pm_clock_support = 1;
mcan_class->can.clock.freq = clk_get_rate(mcan_class->cclk);
mcan_class->dev = >dev;
+ mcan_class->transceiver = transceiver;
mcan_class->ops = _can_plat_ops;
--
2.17.1
[PATCH v2 1/2] dt-bindings: net: can: Document transceiver implementation as phy
From: Faiz Abbas Some transceivers need a configuration step (for example, pulling the standby or enable lines) for them to start sending messages. The transceiver can be implemented as a phy with the configuration done in the phy driver. The bit rate limitation can the be obtained by the driver using the phy node. Document the above implementation in the bosch mcan bindings Signed-off-by: Faiz Abbas Signed-off-by: Aswath Govindraju --- Documentation/devicetree/bindings/net/can/bosch,m_can.yaml | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml b/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml index 798fa5fb7bb2..25f74db46bae 100644 --- a/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml +++ b/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml @@ -109,6 +109,9 @@ properties: can-transceiver: $ref: can-transceiver.yaml# + phys: +maxItems: 1 + required: - compatible - reg -- 2.17.1
[PATCH v2 0/2] MCAN: Add support for implementing transceiver as a phy
The following series of patches add support for implementing the transceiver as a phy of m_can_platform driver. TCAN1042 has a standby signal that needs to be pulled high for sending/receiving messages[1]. TCAN1043 has a enable signal along with standby signal that needs to be pulled up for sending/receiving messages[2], and other combinations of the two lines can be used to put the transceiver in different states to reduce power consumption. On boards like the AM654-idk and J721e-evm these signals are controlled using gpios. These gpios are set in phy driver, and the transceiver can be put in different states using phy API. The phy driver is added in the series [3]. This patch series is dependent on [4]. Changes since v1: - Used the API devm_phy_get_optional() instead of devm_of_phy_get_optional_by_index() [1] - https://www.ti.com/lit/ds/symlink/tcan1042h.pdf [2] - https://www.ti.com/lit/ds/symlink/tcan1043-q1.pdf [3] - https://lore.kernel.org/patchwork/project/lkml/list/?series=495365 [4] - https://lore.kernel.org/patchwork/patch/1413286/ Faiz Abbas (2): dt-bindings: net: can: Document transceiver implementation as phy can: m_can: Add support for transceiver as phy .../devicetree/bindings/net/can/bosch,m_can.yaml| 3 +++ drivers/net/can/m_can/m_can.c | 10 ++ drivers/net/can/m_can/m_can.h | 2 ++ drivers/net/can/m_can/m_can_platform.c | 13 + 4 files changed, 28 insertions(+) -- 2.17.1
Re: [PATCH v2 2/2] asm-generic/io.h: Silence -Wnull-pointer-arithmetic warning on PCI_IOBASE
Hi Niklas, I love your patch! Yet something to improve: [auto build test ERROR on soc/for-next] [also build test ERROR on sparc/master asm-generic/master sparc-next/master v5.12-rc7 next-20210415] [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/Niklas-Schnelle/asm-generic-io-h-Silence-Wnull-pointer-arithmetic-warning-on-PCI_IOBASE/20210415-203919 base: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git for-next config: nds32-allnoconfig (attached as .config) compiler: nds32le-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 # https://github.com/0day-ci/linux/commit/f0394115b166f960f12fc7bc48362d0d19f67883 git remote add linux-review https://github.com/0day-ci/linux git fetch --no-tags linux-review Niklas-Schnelle/asm-generic-io-h-Silence-Wnull-pointer-arithmetic-warning-on-PCI_IOBASE/20210415-203919 git checkout f0394115b166f960f12fc7bc48362d0d19f67883 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross W=1 ARCH=nds32 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): In file included from arch/nds32/include/asm/io.h:82, from arch/nds32/kernel/vdso/gettimeofday.c:7: include/asm-generic/io.h: In function 'ioport_map': >> include/asm-generic/io.h:1071:44: error: 'PCI_IOBASE' undeclared (first use >> in this function) 1071 | return (port > MMIO_UPPER_LIMIT) ? NULL : PCI_IOBASE + port; |^~ include/asm-generic/io.h:1071:44: note: each undeclared identifier is reported only once for each function it appears in include/asm-generic/io.h: In function '__pci_ioport_unmap': include/asm-generic/io.h:1076:32: error: 'PCI_IOBASE' undeclared (first use in this function) 1076 | uintptr_t start = (uintptr_t) PCI_IOBASE; |^~ arch/nds32/kernel/vdso/gettimeofday.c: At top level: arch/nds32/kernel/vdso/gettimeofday.c:158:13: warning: no previous prototype for '__vdso_clock_gettime' [-Wmissing-prototypes] 158 | notrace int __vdso_clock_gettime(clockid_t clkid, struct __kernel_old_timespec *ts) | ^~~~ arch/nds32/kernel/vdso/gettimeofday.c:206:13: warning: no previous prototype for '__vdso_clock_getres' [-Wmissing-prototypes] 206 | notrace int __vdso_clock_getres(clockid_t clk_id, struct __kernel_old_timespec *res) | ^~~ arch/nds32/kernel/vdso/gettimeofday.c:246:13: warning: no previous prototype for '__vdso_gettimeofday' [-Wmissing-prototypes] 246 | notrace int __vdso_gettimeofday(struct __kernel_old_timeval *tv, struct timezone *tz) | ^~~ -- :1511:2: warning: #warning syscall clone3 not implemented [-Wcpp] In file included from arch/nds32/include/asm/io.h:82, from arch/nds32/kernel/vdso/gettimeofday.c:7: include/asm-generic/io.h: In function 'ioport_map': >> include/asm-generic/io.h:1071:44: error: 'PCI_IOBASE' undeclared (first use >> in this function) 1071 | return (port > MMIO_UPPER_LIMIT) ? NULL : PCI_IOBASE + port; |^~ include/asm-generic/io.h:1071:44: note: each undeclared identifier is reported only once for each function it appears in include/asm-generic/io.h: In function '__pci_ioport_unmap': include/asm-generic/io.h:1076:32: error: 'PCI_IOBASE' undeclared (first use in this function) 1076 | uintptr_t start = (uintptr_t) PCI_IOBASE; |^~ arch/nds32/kernel/vdso/gettimeofday.c: At top level: arch/nds32/kernel/vdso/gettimeofday.c:158:13: warning: no previous prototype for '__vdso_clock_gettime' [-Wmissing-prototypes] 158 | notrace int __vdso_clock_gettime(clockid_t clkid, struct __kernel_old_timespec *ts) | ^~~~ arch/nds32/kernel/vdso/gettimeofday.c:206:13: warning: no previous prototype for '__vdso_clock_getres' [-Wmissing-prototypes] 206 | notrace int __vdso_clock_getres(clockid_t clk_id, struct __kernel_old_timespec *res) | ^~~ arch/nds32/kernel/vdso/gettimeofday.c:246:13: warning: no previous prototype for '__vdso_gettimeofday' [-Wmissing-prototypes] 246 | notrace int __vdso_gettimeofday(struct __kernel_old_timeval *tv, struct timezone *tz) | ^~~
[PROBLEM] a data race between tcp_set_default_congestion_control() and tcp_set_congestion_control()
Hi, We found a data race between tcp_set_default_congestion_control() and tcp_set_congestion_control() in linux-5.12-rc3. In general, when tcp_set_congestion_control() is reading ca->flags with a lock grabbed, tcp_set_default_congestion_control() may be updating ca->flags at the same time, as shown below. When the writer and reader are running parallel, tcp_set_congestion_control()’s control flow might be non-deterministic, either returning a -EPERM or calling tcp_reinit_congestion_control(). We also notice in tcp_set_allowed_congestion_control(), the write to ca->flags is protected by tcp_cong_list_lock, so we want to point it out in case the data race is unexpected. Thread 1Thread 2 //tcp_set_default_congestion_control() //tcp_set_congestion_control() // lock_sock() grabbed if (!((ca->flags & TCP_CONG_NON_RESTRICTED) || cap_net_admin)) err = -EPERM; else if (!bpf_try_module_get(ca, ca->owner)) err = -EBUSY; else tcp_reinit_congestion_control(sk, ca); ca->flags |= TCP_CONG_NON_RESTRICTED; Thanks, Sishuai
[GIT PULL] ACPI fix for v5.12-rc8
Hi Linus, Please pull from the tag git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \ acpi-5.12-rc8 with top-most commit 6998a8800d73116187aad542391ce3b2dd0f9e30 ACPI: x86: Call acpi_boot_table_init() after acpi_table_upgrade() on top of commit d434405aaab7d0ebc516b68a8fc4100922d7f5ef Linux 5.12-rc7 to receive an ACPI fix for 5.12-rc8. This restores the initrd-based ACPI table override functionality broken by one of the recent fixes. Thanks! --- Rafael J. Wysocki (1): ACPI: x86: Call acpi_boot_table_init() after acpi_table_upgrade() --- arch/x86/kernel/setup.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-)
[PATCH v13 03/12] KVM: SVM: Add KVM_SEV_SEND_FINISH command
From: Brijesh Singh
The command is used to finailize the encryption context created with
KVM_SEV_SEND_START command.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: Paolo Bonzini
Cc: Joerg Roedel
Cc: Borislav Petkov
Cc: Tom Lendacky
Cc: x...@kernel.org
Cc: k...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Reviewed-by: Steve Rutherford
Signed-off-by: Brijesh Singh
Signed-off-by: Ashish Kalra
---
.../virt/kvm/amd-memory-encryption.rst| 8 +++
arch/x86/kvm/svm/sev.c| 23 +++
2 files changed, 31 insertions(+)
diff --git a/Documentation/virt/kvm/amd-memory-encryption.rst
b/Documentation/virt/kvm/amd-memory-encryption.rst
index 3c5456e0268a..26c4e6c83f62 100644
--- a/Documentation/virt/kvm/amd-memory-encryption.rst
+++ b/Documentation/virt/kvm/amd-memory-encryption.rst
@@ -335,6 +335,14 @@ Returns: 0 on success, -negative on error
__u32 trans_len;
};
+12. KVM_SEV_SEND_FINISH
+
+
+After completion of the migration flow, the KVM_SEV_SEND_FINISH command can be
+issued by the hypervisor to delete the encryption context.
+
+Returns: 0 on success, -negative on error
+
References
==
diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
index 30527285a39a..92325d9527ce 100644
--- a/arch/x86/kvm/svm/sev.c
+++ b/arch/x86/kvm/svm/sev.c
@@ -1350,6 +1350,26 @@ static int sev_send_update_data(struct kvm *kvm, struct
kvm_sev_cmd *argp)
return ret;
}
+static int sev_send_finish(struct kvm *kvm, struct kvm_sev_cmd *argp)
+{
+ struct kvm_sev_info *sev = _kvm_svm(kvm)->sev_info;
+ struct sev_data_send_finish *data;
+ int ret;
+
+ if (!sev_guest(kvm))
+ return -ENOTTY;
+
+ data = kzalloc(sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ data->handle = sev->handle;
+ ret = sev_issue_cmd(kvm, SEV_CMD_SEND_FINISH, data, >error);
+
+ kfree(data);
+ return ret;
+}
+
int svm_mem_enc_op(struct kvm *kvm, void __user *argp)
{
struct kvm_sev_cmd sev_cmd;
@@ -1409,6 +1429,9 @@ int svm_mem_enc_op(struct kvm *kvm, void __user *argp)
case KVM_SEV_SEND_UPDATE_DATA:
r = sev_send_update_data(kvm, _cmd);
break;
+ case KVM_SEV_SEND_FINISH:
+ r = sev_send_finish(kvm, _cmd);
+ break;
default:
r = -EINVAL;
goto out;
--
2.17.1
[PATCH v13 04/12] KVM: SVM: Add support for KVM_SEV_RECEIVE_START command
From: Brijesh Singh
The command is used to create the encryption context for an incoming
SEV guest. The encryption context can be later used by the hypervisor
to import the incoming data into the SEV guest memory space.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: Paolo Bonzini
Cc: Joerg Roedel
Cc: Borislav Petkov
Cc: Tom Lendacky
Cc: x...@kernel.org
Cc: k...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Reviewed-by: Steve Rutherford
Signed-off-by: Brijesh Singh
Signed-off-by: Ashish Kalra
---
.../virt/kvm/amd-memory-encryption.rst| 29 +++
arch/x86/kvm/svm/sev.c| 81 +++
include/uapi/linux/kvm.h | 9 +++
3 files changed, 119 insertions(+)
diff --git a/Documentation/virt/kvm/amd-memory-encryption.rst
b/Documentation/virt/kvm/amd-memory-encryption.rst
index 26c4e6c83f62..c86c1ded8dd8 100644
--- a/Documentation/virt/kvm/amd-memory-encryption.rst
+++ b/Documentation/virt/kvm/amd-memory-encryption.rst
@@ -343,6 +343,35 @@ issued by the hypervisor to delete the encryption context.
Returns: 0 on success, -negative on error
+13. KVM_SEV_RECEIVE_START
+
+
+The KVM_SEV_RECEIVE_START command is used for creating the memory encryption
+context for an incoming SEV guest. To create the encryption context, the user
must
+provide a guest policy, the platform public Diffie-Hellman (PDH) key and
session
+information.
+
+Parameters: struct kvm_sev_receive_start (in/out)
+
+Returns: 0 on success, -negative on error
+
+::
+
+struct kvm_sev_receive_start {
+__u32 handle; /* if zero then firmware creates a new
handle */
+__u32 policy; /* guest's policy */
+
+__u64 pdh_uaddr;/* userspace address pointing to the
PDH key */
+__u32 pdh_len;
+
+__u64 session_uaddr;/* userspace address which points to
the guest session information */
+__u32 session_len;
+};
+
+On success, the 'handle' field contains a new handle and on error, a negative
value.
+
+For more details, see SEV spec Section 6.12.
+
References
==
diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
index 92325d9527ce..e530c2b34b5e 100644
--- a/arch/x86/kvm/svm/sev.c
+++ b/arch/x86/kvm/svm/sev.c
@@ -1370,6 +1370,84 @@ static int sev_send_finish(struct kvm *kvm, struct
kvm_sev_cmd *argp)
return ret;
}
+static int sev_receive_start(struct kvm *kvm, struct kvm_sev_cmd *argp)
+{
+ struct kvm_sev_info *sev = _kvm_svm(kvm)->sev_info;
+ struct sev_data_receive_start *start;
+ struct kvm_sev_receive_start params;
+ int *error = >error;
+ void *session_data;
+ void *pdh_data;
+ int ret;
+
+ if (!sev_guest(kvm))
+ return -ENOTTY;
+
+ /* Get parameter from the userspace */
+ if (copy_from_user(, (void __user *)(uintptr_t)argp->data,
+ sizeof(struct kvm_sev_receive_start)))
+ return -EFAULT;
+
+ /* some sanity checks */
+ if (!params.pdh_uaddr || !params.pdh_len ||
+ !params.session_uaddr || !params.session_len)
+ return -EINVAL;
+
+ pdh_data = psp_copy_user_blob(params.pdh_uaddr, params.pdh_len);
+ if (IS_ERR(pdh_data))
+ return PTR_ERR(pdh_data);
+
+ session_data = psp_copy_user_blob(params.session_uaddr,
+ params.session_len);
+ if (IS_ERR(session_data)) {
+ ret = PTR_ERR(session_data);
+ goto e_free_pdh;
+ }
+
+ ret = -ENOMEM;
+ start = kzalloc(sizeof(*start), GFP_KERNEL);
+ if (!start)
+ goto e_free_session;
+
+ start->handle = params.handle;
+ start->policy = params.policy;
+ start->pdh_cert_address = __psp_pa(pdh_data);
+ start->pdh_cert_len = params.pdh_len;
+ start->session_address = __psp_pa(session_data);
+ start->session_len = params.session_len;
+
+ /* create memory encryption context */
+ ret = __sev_issue_cmd(argp->sev_fd, SEV_CMD_RECEIVE_START, start,
+ error);
+ if (ret)
+ goto e_free;
+
+ /* Bind ASID to this guest */
+ ret = sev_bind_asid(kvm, start->handle, error);
+ if (ret)
+ goto e_free;
+
+ params.handle = start->handle;
+ if (copy_to_user((void __user *)(uintptr_t)argp->data,
+, sizeof(struct kvm_sev_receive_start))) {
+ ret = -EFAULT;
+ sev_unbind_asid(kvm, start->handle);
+ goto e_free;
+ }
+
+ sev->handle = start->handle;
+ sev->fd = argp->sev_fd;
+
+e_free:
+ kfree(start);
+e_free_session:
+ kfree(session_data);
+e_free_pdh:
+ kfree(pdh_data);
+
+ return ret;
+}
+
int svm_mem_enc_op(struct kvm *kvm, void __user *argp)
{
Re: [PATCH] locking/qrwlock: Fix ordering in queued_write_lock_slowpath
On Thu, Apr 15, 2021 at 04:28:21PM +0100, Will Deacon wrote:
> On Thu, Apr 15, 2021 at 05:03:58PM +0200, Peter Zijlstra wrote:
> > @@ -73,9 +75,8 @@ void queued_write_lock_slowpath(struct qrwlock *lock)
> >
> > /* When no more readers or writers, set the locked flag */
> > do {
> > - atomic_cond_read_acquire(>cnts, VAL == _QW_WAITING);
> > - } while (atomic_cmpxchg_relaxed(>cnts, _QW_WAITING,
> > - _QW_LOCKED) != _QW_WAITING);
> > + cnt = atomic_cond_read_acquire(>cnts, VAL == _QW_WAITING);
>
> I think the issue is that >here< a concurrent reader in interrupt context
> can take the lock and release it again, but we could speculate reads from
> the critical section up over the later release and up before the control
> dependency here...
OK, so that was totally not clear from the original changelog.
> > + } while (!atomic_try_cmpxchg_relaxed(>cnts, , _QW_LOCKED));
>
> ... and then this cmpxchg() will succeed, so our speculated stale reads
> could be used.
>
> *HOWEVER*
>
> Speculating a read should be fine in the face of a concurrent _reader_,
> so for this to be an issue it implies that the reader is also doing some
> (atomic?) updates.
So we're having something like:
CPU0CPU1
queue_write_lock_slowpath()
atomic_cond_read_acquire() == _QW_WAITING
queued_read_lock_slowpath()
atomic_cond_read_acquire()
return;
,--> (before X's store)
|X = y;
|
|queued_read_unlock()
| (void)atomic_sub_return_release()
|
| atomic_cmpxchg_relaxed(.old = _QW_WAITING)
|
`-- r = X;
Which as Will said is a cmpxchg ABA, however for it to be ABA, we have
to observe that unlock-store, and won't we then also have to observe the
whole critical section?
Ah, the issue is yet another load inside our own (CPU0)'s critical
section. which isn't ordered against the cmpxchg_relaxed() and can be
issued before.
So yes, then making the cmpxchg an acquire, will force all our own loads
to happen later.
[PATCH v13 11/12] EFI: Introduce the new AMD Memory Encryption GUID.
From: Ashish Kalra
Introduce a new AMD Memory Encryption GUID which is currently
used for defining a new UEFI environment variable which indicates
UEFI/OVMF support for the SEV live migration feature. This variable
is setup when UEFI/OVMF detects host/hypervisor support for SEV
live migration and later this variable is read by the kernel using
EFI runtime services to verify if OVMF supports the live migration
feature.
Signed-off-by: Ashish Kalra
Reviewed-by: Steve Rutherford
---
include/linux/efi.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux/efi.h b/include/linux/efi.h
index 6b5d36babfcc..6f364ace82cb 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -362,6 +362,7 @@ void efi_native_runtime_setup(void);
/* OEM GUIDs */
#define DELLEMC_EFI_RCI2_TABLE_GUIDEFI_GUID(0x2d9f28a2, 0xa886,
0x456a, 0x97, 0xa8, 0xf1, 0x1e, 0xf2, 0x4f, 0xf4, 0x55)
+#define MEM_ENCRYPT_GUID EFI_GUID(0x0cf29b71, 0x9e51,
0x433a, 0xa3, 0xb7, 0x81, 0xf3, 0xab, 0x16, 0xb8, 0x75)
typedef struct {
efi_guid_t guid;
--
2.17.1
[PATCH v13 10/12] KVM: x86: Introduce new KVM_FEATURE_SEV_LIVE_MIGRATION feature & Custom MSR.
From: Ashish Kalra
Add new KVM_FEATURE_SEV_LIVE_MIGRATION feature for guest to check
for host-side support for SEV live migration. Also add a new custom
MSR_KVM_SEV_LIVE_MIGRATION for guest to enable the SEV live migration
feature.
MSR is handled by userspace using MSR filters.
Signed-off-by: Ashish Kalra
Reviewed-by: Steve Rutherford
---
Documentation/virt/kvm/cpuid.rst | 5 +
Documentation/virt/kvm/msr.rst | 12
arch/x86/include/uapi/asm/kvm_para.h | 4
arch/x86/kvm/cpuid.c | 3 ++-
4 files changed, 23 insertions(+), 1 deletion(-)
diff --git a/Documentation/virt/kvm/cpuid.rst b/Documentation/virt/kvm/cpuid.rst
index cf62162d4be2..0bdb6cdb12d3 100644
--- a/Documentation/virt/kvm/cpuid.rst
+++ b/Documentation/virt/kvm/cpuid.rst
@@ -96,6 +96,11 @@ KVM_FEATURE_MSI_EXT_DEST_ID15 guest checks
this feature bit
before using extended
destination
ID bits in MSI address bits
11-5.
+KVM_FEATURE_SEV_LIVE_MIGRATION 16 guest checks this feature bit
before
+ using the page encryption state
+ hypercall to notify the page
state
+ change
+
KVM_FEATURE_CLOCKSOURCE_STABLE_BIT 24 host will warn if no guest-side
per-cpu warps are expected in
kvmclock
diff --git a/Documentation/virt/kvm/msr.rst b/Documentation/virt/kvm/msr.rst
index e37a14c323d2..020245d16087 100644
--- a/Documentation/virt/kvm/msr.rst
+++ b/Documentation/virt/kvm/msr.rst
@@ -376,3 +376,15 @@ data:
write '1' to bit 0 of the MSR, this causes the host to re-scan its queue
and check if there are more notifications pending. The MSR is available
if KVM_FEATURE_ASYNC_PF_INT is present in CPUID.
+
+MSR_KVM_SEV_LIVE_MIGRATION:
+0x4b564d08
+
+ Control SEV Live Migration features.
+
+data:
+Bit 0 enables (1) or disables (0) host-side SEV Live Migration feature,
+in other words, this is guest->host communication that it's properly
+handling the shared pages list.
+
+All other bits are reserved.
diff --git a/arch/x86/include/uapi/asm/kvm_para.h
b/arch/x86/include/uapi/asm/kvm_para.h
index 950afebfba88..f6bfa138874f 100644
--- a/arch/x86/include/uapi/asm/kvm_para.h
+++ b/arch/x86/include/uapi/asm/kvm_para.h
@@ -33,6 +33,7 @@
#define KVM_FEATURE_PV_SCHED_YIELD 13
#define KVM_FEATURE_ASYNC_PF_INT 14
#define KVM_FEATURE_MSI_EXT_DEST_ID15
+#define KVM_FEATURE_SEV_LIVE_MIGRATION 16
#define KVM_HINTS_REALTIME 0
@@ -54,6 +55,7 @@
#define MSR_KVM_POLL_CONTROL 0x4b564d05
#define MSR_KVM_ASYNC_PF_INT 0x4b564d06
#define MSR_KVM_ASYNC_PF_ACK 0x4b564d07
+#define MSR_KVM_SEV_LIVE_MIGRATION 0x4b564d08
struct kvm_steal_time {
__u64 steal;
@@ -136,4 +138,6 @@ struct kvm_vcpu_pv_apf_data {
#define KVM_PV_EOI_ENABLED KVM_PV_EOI_MASK
#define KVM_PV_EOI_DISABLED 0x0
+#define KVM_SEV_LIVE_MIGRATION_ENABLED BIT_ULL(0)
+
#endif /* _UAPI_ASM_X86_KVM_PARA_H */
diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
index 6bd2f8b830e4..4e2e69a692aa 100644
--- a/arch/x86/kvm/cpuid.c
+++ b/arch/x86/kvm/cpuid.c
@@ -812,7 +812,8 @@ static inline int __do_cpuid_func(struct kvm_cpuid_array
*array, u32 function)
(1 << KVM_FEATURE_PV_SEND_IPI) |
(1 << KVM_FEATURE_POLL_CONTROL) |
(1 << KVM_FEATURE_PV_SCHED_YIELD) |
-(1 << KVM_FEATURE_ASYNC_PF_INT);
+(1 << KVM_FEATURE_ASYNC_PF_INT) |
+(1 << KVM_FEATURE_SEV_LIVE_MIGRATION);
if (sched_info_on())
entry->eax |= (1 << KVM_FEATURE_STEAL_TIME);
--
2.17.1
Re: [PATCH] virtio_blk: Add support for lifetime feature
On Wed, Apr 14, 2021 at 09:44:35AM +0100, Stefan Hajnoczi wrote: > On Mon, Apr 12, 2021 at 10:42:17AM +0100, Christoph Hellwig wrote: > > A note to the virtio committee: eMMC is the worst of all the currently > > active storage standards by a large margin. It defines very strange > > ad-hoc interfaces that expose very specific internals and often provides > > very poor abstractions. It would be great it you could reach out to the > > wider storage community before taking bad ideas from the eMMC standard > > and putting it into virtio. > > As Michael mentioned, there is still time to change the virtio-blk spec > since this feature hasn't been released yet. > > Why exactly is exposing eMMC-style lifetime information problematic? > > Can you and Enrico discuss the use case to figure out an alternative > interface? Mostly because it exposed a very awkward encoding that is not actually documented in any publically available spec. If you want to incorporate a more open definition doing something like the NVMe 'Endurance Estimate' and 'Percentage Used' fields. But the most important thing is to fully document the semantics in the virtio document instead of refercing a closed standard.
[PATCH v13 12/12] x86/kvm: Add guest support for detecting and enabling SEV Live Migration feature.
From: Ashish Kalra
The guest support for detecting and enabling SEV Live migration
feature uses the following logic :
- kvm_init_plaform() invokes check_kvm_sev_migration() which
checks if its booted under the EFI
- If not EFI,
i) check for the KVM_FEATURE_CPUID
ii) if CPUID reports that migration is supported, issue a wrmsrl()
to enable the SEV live migration support
- If EFI,
i) check for the KVM_FEATURE_CPUID
ii) If CPUID reports that migration is supported, read the UEFI variable
which
indicates OVMF support for live migration
iii) the variable indicates live migration is supported, issue a wrmsrl()
to
enable the SEV live migration support
The EFI live migration check is done using a late_initcall() callback.
Also, ensure that _bss_decrypted section is marked as decrypted in the
shared pages list.
Also adds kexec support for SEV Live Migration.
Reset the host's shared pages list related to kernel
specific page encryption status settings before we load a
new kernel by kexec. We cannot reset the complete
shared pages list here as we need to retain the
UEFI/OVMF firmware specific settings.
The host's shared pages list is maintained for the
guest to keep track of all unencrypted guest memory regions,
therefore we need to explicitly mark all shared pages as
encrypted again before rebooting into the new guest kernel.
Signed-off-by: Ashish Kalra
---
arch/x86/include/asm/mem_encrypt.h | 8
arch/x86/kernel/kvm.c | 55 +
arch/x86/mm/mem_encrypt.c | 64 ++
3 files changed, 127 insertions(+)
diff --git a/arch/x86/include/asm/mem_encrypt.h
b/arch/x86/include/asm/mem_encrypt.h
index 31c4df123aa0..19b77f3a62dc 100644
--- a/arch/x86/include/asm/mem_encrypt.h
+++ b/arch/x86/include/asm/mem_encrypt.h
@@ -21,6 +21,7 @@
extern u64 sme_me_mask;
extern u64 sev_status;
extern bool sev_enabled;
+extern bool sev_live_migration_enabled;
void sme_encrypt_execute(unsigned long encrypted_kernel_vaddr,
unsigned long decrypted_kernel_vaddr,
@@ -44,8 +45,11 @@ void __init sme_enable(struct boot_params *bp);
int __init early_set_memory_decrypted(unsigned long vaddr, unsigned long size);
int __init early_set_memory_encrypted(unsigned long vaddr, unsigned long size);
+void __init early_set_mem_enc_dec_hypercall(unsigned long vaddr, int npages,
+ bool enc);
void __init mem_encrypt_free_decrypted_mem(void);
+void __init check_kvm_sev_migration(void);
/* Architecture __weak replacement functions */
void __init mem_encrypt_init(void);
@@ -60,6 +64,7 @@ bool sev_es_active(void);
#else /* !CONFIG_AMD_MEM_ENCRYPT */
#define sme_me_mask0ULL
+#define sev_live_migration_enabled false
static inline void __init sme_early_encrypt(resource_size_t paddr,
unsigned long size) { }
@@ -84,8 +89,11 @@ static inline int __init
early_set_memory_decrypted(unsigned long vaddr, unsigned long size) { return
0; }
static inline int __init
early_set_memory_encrypted(unsigned long vaddr, unsigned long size) { return
0; }
+static inline void __init
+early_set_mem_enc_dec_hypercall(unsigned long vaddr, int npages, bool enc) {}
static inline void mem_encrypt_free_decrypted_mem(void) { }
+static inline void check_kvm_sev_migration(void) { }
#define __bss_decrypted
diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
index 78bb0fae3982..94ef16d263a7 100644
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -429,6 +430,59 @@ static inline void __set_percpu_decrypted(void *ptr,
unsigned long size)
early_set_memory_decrypted((unsigned long) ptr, size);
}
+static int __init setup_kvm_sev_migration(void)
+{
+ efi_char16_t efi_sev_live_migration_enabled[] =
L"SevLiveMigrationEnabled";
+ efi_guid_t efi_variable_guid = MEM_ENCRYPT_GUID;
+ efi_status_t status;
+ unsigned long size;
+ bool enabled;
+
+ /*
+* check_kvm_sev_migration() invoked via kvm_init_platform() before
+* this callback would have setup the indicator that live migration
+* feature is supported/enabled.
+*/
+ if (!sev_live_migration_enabled)
+ return 0;
+
+ if (!efi_enabled(EFI_BOOT))
+ return 0;
+
+ if (!efi_enabled(EFI_RUNTIME_SERVICES)) {
+ pr_info("%s : EFI runtime services are not enabled\n",
__func__);
+ return 0;
+ }
+
+ size = sizeof(enabled);
+
+ /* Get variable contents into buffer */
+ status = efi.get_variable(efi_sev_live_migration_enabled,
+ _variable_guid, NULL, , );
+
+ if (status == EFI_NOT_FOUND) {
+ pr_info("%s : EFI live migration variable
Re: [RFC PATCH 0/3] Separate BE DAI HW constraints from FE ones
On Wed, Apr 14, 2021 at 02:58:10PM +, codrin.ciubota...@microchip.com wrote: > How about using a different API for ASoC only, since that's the place of > DPCM. Only drivers that do not involve DSPs would have to to be changed > to call the new snd_pcm_hw_rule_add() variant. > Another solution would be to have a different snd_soc_pcm_runtime for BE > interfaces (with a new hw_constraints member of course). What do you think? I'm really not convinced we want to continue to pile stuff on top of DPCM, it is just fundamentally not up to modelling what modern systems are able to do - it's already making things more fragile than they should be and more special cases seems like it's going to end up making that worse. That said I've not seen the code but... signature.asc Description: PGP signature
Re: [PATCH] security: commoncap: clean up kernel-doc comments
On Sun, 11 Apr 2021, Randy Dunlap wrote: > Fix kernel-doc notation in commoncap.c. > > Use correct (matching) function name in comments as in code. > Use correct function argument names in kernel-doc comments. > Use kernel-doc's "Return:" format for function return values. > > Fixes these kernel-doc warnings: > > ../security/commoncap.c:1206: warning: expecting prototype for > cap_task_ioprio(). Prototype was for cap_task_setioprio() instead > ../security/commoncap.c:1219: warning: expecting prototype for > cap_task_ioprio(). Prototype was for cap_task_setnice() instead > > Signed-off-by: Randy Dunlap > Cc: Serge Hallyn > Cc: James Morris > Cc: linux-security-mod...@vger.kernel.org Applied to git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git fixes-v5.12 -- James Morris
