[PATCH v1] scsi: ufs-mediatek: Fix incorrect time to wait link status
Fix incorrect calculation of "ms" based waiting time in
function ufs_mtk_setup_clocks().
Fixes: 9006e3986f66 ("scsi: ufs-mediatek: Do not gate clocks if auto-hibern8 is
not entered yet")
Signed-off-by: Stanley Chu
---
drivers/scsi/ufs/ufs-mediatek.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/scsi/ufs/ufs-mediatek.c b/drivers/scsi/ufs/ufs-mediatek.c
index 29cd017c1aa0..1755dd6b04ae 100644
--- a/drivers/scsi/ufs/ufs-mediatek.c
+++ b/drivers/scsi/ufs/ufs-mediatek.c
@@ -212,7 +212,7 @@ static int ufs_mtk_wait_link_state(struct ufs_hba *hba, u32
state,
ktime_t timeout, time_checked;
u32 val;
- timeout = ktime_add_us(ktime_get(), ms_to_ktime(max_wait_ms));
+ timeout = ktime_add_ms(ktime_get(), max_wait_ms);
do {
time_checked = ktime_get();
ufshcd_writel(hba, 0x20, REG_UFS_DEBUG_SEL);
--
2.18.0
Re: [PATCH] vdpa/mlx5: Fix erroneous null pointer checks
Acked-by: Eli Cohen
On Thu, Aug 06, 2020 at 08:18:39PM +0100, Alex Dewar wrote:
> In alloc_inout() in net/mlx5_vnet.c, there are a few places where memory
> is allocated to *in and *out, but only the values of in and out are
> null-checked (i.e. there is a missing dereference). Fix this.
>
> Addresses-Coverity: ("CID 1496603: (REVERSE_INULL)")
> Fixes: 1a86b377aa21 ("vdpa/mlx5: Add VDPA driver for supported mlx5 devices")
> Signed-off-by: Alex Dewar
> ---
> drivers/vdpa/mlx5/net/mlx5_vnet.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c
> b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> index 3ec44a4f0e45..bcb6600c2839 100644
> --- a/drivers/vdpa/mlx5/net/mlx5_vnet.c
> +++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> @@ -867,7 +867,7 @@ static void alloc_inout(struct mlx5_vdpa_net *ndev, int
> cmd, void **in, int *inl
> *outlen = MLX5_ST_SZ_BYTES(qp_2rst_out);
> *in = kzalloc(*inlen, GFP_KERNEL);
> *out = kzalloc(*outlen, GFP_KERNEL);
> - if (!in || !out)
> + if (!*in || !*out)
> goto outerr;
>
> MLX5_SET(qp_2rst_in, *in, opcode, cmd);
> @@ -879,7 +879,7 @@ static void alloc_inout(struct mlx5_vdpa_net *ndev, int
> cmd, void **in, int *inl
> *outlen = MLX5_ST_SZ_BYTES(rst2init_qp_out);
> *in = kzalloc(*inlen, GFP_KERNEL);
> *out = kzalloc(MLX5_ST_SZ_BYTES(rst2init_qp_out), GFP_KERNEL);
> - if (!in || !out)
> + if (!*in || !*out)
> goto outerr;
>
> MLX5_SET(rst2init_qp_in, *in, opcode, cmd);
> @@ -896,7 +896,7 @@ static void alloc_inout(struct mlx5_vdpa_net *ndev, int
> cmd, void **in, int *inl
> *outlen = MLX5_ST_SZ_BYTES(init2rtr_qp_out);
> *in = kzalloc(*inlen, GFP_KERNEL);
> *out = kzalloc(MLX5_ST_SZ_BYTES(init2rtr_qp_out), GFP_KERNEL);
> - if (!in || !out)
> + if (!*in || !*out)
> goto outerr;
>
> MLX5_SET(init2rtr_qp_in, *in, opcode, cmd);
> @@ -914,7 +914,7 @@ static void alloc_inout(struct mlx5_vdpa_net *ndev, int
> cmd, void **in, int *inl
> *outlen = MLX5_ST_SZ_BYTES(rtr2rts_qp_out);
> *in = kzalloc(*inlen, GFP_KERNEL);
> *out = kzalloc(MLX5_ST_SZ_BYTES(rtr2rts_qp_out), GFP_KERNEL);
> - if (!in || !out)
> + if (!*in || !*out)
> goto outerr;
>
> MLX5_SET(rtr2rts_qp_in, *in, opcode, cmd);
> --
> 2.28.0
>
Re: [PATCH] vdpa/mlx5: Fix uninitialised variable in core/mr.c
On Thu, Aug 06, 2020 at 07:56:15PM +0100, Alex Dewar wrote:
Acked-by: Eli Cohen
> If the kernel is unable to allocate memory for the variable dmr then
> err will be returned without being set. Set err to -ENOMEM in this
> case.
>
> Fixes: 94abbccdf291 ("vdpa/mlx5: Add shared memory registration code")
> Addresses-Coverity: ("Uninitialized variables")
> Signed-off-by: Alex Dewar
> ---
> drivers/vdpa/mlx5/core/mr.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/vdpa/mlx5/core/mr.c b/drivers/vdpa/mlx5/core/mr.c
> index f5dec0274133..ef1c550f8266 100644
> --- a/drivers/vdpa/mlx5/core/mr.c
> +++ b/drivers/vdpa/mlx5/core/mr.c
> @@ -319,8 +319,10 @@ static int add_direct_chain(struct mlx5_vdpa_dev *mvdev,
> u64 start, u64 size, u8
> while (size) {
> sz = (u32)min_t(u64, MAX_KLM_SIZE, size);
> dmr = kzalloc(sizeof(*dmr), GFP_KERNEL);
> - if (!dmr)
> + if (!dmr) {
> + err = -ENOMEM;
> goto err_alloc;
> + }
>
> dmr->start = st;
> dmr->end = st + sz;
> --
> 2.28.0
>
Re: WARNING: ODEBUG bug in put_device
syzbot has bisected this issue to:
commit 6f8c8f3c31015808100ee54fc471ff5dffdf1734
Author: Bartosz Golaszewski
Date: Thu Aug 8 08:01:44 2019 +
hwmon: pmbus: ucd9000: remove unneeded include
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=1550298a90
start commit: 47ec5303 Merge git://git.kernel.org/pub/scm/linux/kernel/g..
git tree: upstream
final oops: https://syzkaller.appspot.com/x/report.txt?x=1750298a90
console output: https://syzkaller.appspot.com/x/log.txt?x=1350298a90
kernel config: https://syzkaller.appspot.com/x/.config?x=7bb894f55faf8242
dashboard link: https://syzkaller.appspot.com/bug?extid=a9290936c6e87b3dc3c2
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=11b69a5290
Reported-by: syzbot+a9290936c6e87b3dc...@syzkaller.appspotmail.com
Fixes: 6f8c8f3c3101 ("hwmon: pmbus: ucd9000: remove unneeded include")
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
[PATCH v3] scsi: ufs: Fix possible infinite loop in ufshcd_hold
In ufshcd_suspend(), after clk-gating is suspended and link is set
as Hibern8 state, ufshcd_hold() is still possibly invoked before
ufshcd_suspend() returns. For example, MediaTek's suspend vops may
issue UIC commands which would call ufshcd_hold() during the command
issuing flow.
Now if UFSHCD_CAP_HIBERN8_WITH_CLK_GATING capability is enabled,
then ufshcd_hold() may enter infinite loops because there is no
clk-ungating work scheduled or pending. In this case, ufshcd_hold()
shall just bypass, and keep the link as Hibern8 state.
Co-Developed-by: Andy Teng
Reviewed-by: Avri Altman
Signed-off-by: Stanley Chu
---
Changes since v2:
- Rebase to the latest Martin's queue branch
- Add missing Reviewed tag since Avri's letter is not showing up in LKML
and Patchwork
---
drivers/scsi/ufs/ufshcd.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 307622284239..b4f948027b3e 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -1561,6 +1561,7 @@ static void ufshcd_ungate_work(struct work_struct *work)
int ufshcd_hold(struct ufs_hba *hba, bool async)
{
int rc = 0;
+ bool flush_result;
unsigned long flags;
if (!ufshcd_is_clkgating_allowed(hba))
@@ -1592,7 +1593,9 @@ int ufshcd_hold(struct ufs_hba *hba, bool async)
break;
}
spin_unlock_irqrestore(hba->host->host_lock, flags);
- flush_work(>clk_gating.ungate_work);
+ flush_result = flush_work(>clk_gating.ungate_work);
+ if (hba->clk_gating.is_suspended && !flush_result)
+ goto out;
spin_lock_irqsave(hba->host->host_lock, flags);
goto start;
}
--
2.18.0
Re: [PATCH 3/7] dyndbg: select ZPOOL in Kconfig.debug
On 8/7/20 1:09 PM, Jim Cromie wrote: > dyndbg will next need zs_malloc and friends, so add config reqs now, > to avoid touching make-deps late in a patch-set. > > I used select in order not to hide dyndbg inadvertently. > I want to say recommends, since it could be an optional feature. > Whats the best way ? Hi Jim, Can you elaborate on what/why/when it could be an optional feature? > > Signed-off-by: Jim Cromie > --- > lib/Kconfig.debug | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug > index 9ad9210d70a1..a7973063baf0 100644 > --- a/lib/Kconfig.debug > +++ b/lib/Kconfig.debug > @@ -100,6 +100,7 @@ config DYNAMIC_DEBUG > depends on PRINTK > depends on (DEBUG_FS || PROC_FS) > select DYNAMIC_DEBUG_CORE > + select ZPOOL > help > > Compiles debug level messages into the kernel, which would not > -- ~Randy
[PATCH] x86/MCE/AMD, EDAC/mce_amd
From: zhoufeng The edac_mce_amd module calls decode_dram_ecc() on AMD Family17h and later systems. This function is used in amd64_edac_mod to do system-specific decoding for DRAM ECC errors. The function takes a "NodeId" as a parameter. In AMD documentation, NodeId is used to identify a physical die in a system. This can be used to identify a node in the AMD_NB code and also it is used with umc_normaddr_to_sysaddr(). However, the input used for decode_dram_ecc() is currently the NUMA node of a logical CPU. so this will cause the address translation function to fail or report incorrect results. Signed-off-by: zhoufeng --- drivers/edac/mce_amd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/edac/mce_amd.c b/drivers/edac/mce_amd.c index 325aedf46ff2..73c805113322 100644 --- a/drivers/edac/mce_amd.c +++ b/drivers/edac/mce_amd.c @@ -996,7 +996,7 @@ static void decode_smca_error(struct mce *m) } if (bank_type == SMCA_UMC && xec == 0 && decode_dram_ecc) - decode_dram_ecc(cpu_to_node(m->extcpu), m); + decode_dram_ecc(topology_physical_package_id(m->extcpu), m); } static inline void amd_decode_err_code(u16 ec) -- 2.20.1
drivers/video/fbdev/atmel_lcdfb.c:362:20: sparse: sparse: incorrect type in argument 1 (different address spaces)
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 06a81c1c7db9bd5de0bd38cd5acc44bb22b99150 commit: 670d0a4b10704667765f7d18f7592993d02783aa sparse: use identifiers to define address spaces date: 7 weeks ago config: i386-randconfig-s031-20200809 (attached as .config) compiler: gcc-9 (Debian 9.3.0-15) 9.3.0 reproduce: # apt-get install sparse # sparse version: v0.6.2-118-ge1578773-dirty git checkout 670d0a4b10704667765f7d18f7592993d02783aa # save the attached .config to linux build tree make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=i386 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot sparse warnings: (new ones prefixed by >>) drivers/video/fbdev/atmel_lcdfb.c:354:27: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected char [noderef] __iomem *screen_base @@ got void * @@ drivers/video/fbdev/atmel_lcdfb.c:354:27: sparse: expected char [noderef] __iomem *screen_base drivers/video/fbdev/atmel_lcdfb.c:354:27: sparse: got void * >> drivers/video/fbdev/atmel_lcdfb.c:362:20: sparse: sparse: incorrect type in >> argument 1 (different address spaces) @@ expected void *p @@ got >> char [noderef] __iomem *screen_base @@ drivers/video/fbdev/atmel_lcdfb.c:362:20: sparse: expected void *p drivers/video/fbdev/atmel_lcdfb.c:362:20: sparse: got char [noderef] __iomem *screen_base drivers/video/fbdev/atmel_lcdfb.c:333:59: sparse: sparse: incorrect type in argument 3 (different address spaces) @@ expected void *cpu_addr @@ got char [noderef] __iomem *screen_base @@ drivers/video/fbdev/atmel_lcdfb.c:333:59: sparse: expected void *cpu_addr drivers/video/fbdev/atmel_lcdfb.c:333:59: sparse: got char [noderef] __iomem *screen_base drivers/video/fbdev/atmel_lcdfb.c:333:59: sparse: sparse: incorrect type in argument 3 (different address spaces) @@ expected void *cpu_addr @@ got char [noderef] __iomem *screen_base @@ drivers/video/fbdev/atmel_lcdfb.c:333:59: sparse: expected void *cpu_addr drivers/video/fbdev/atmel_lcdfb.c:333:59: sparse: got char [noderef] __iomem *screen_base -- >> drivers/pci/controller/pcie-mediatek.c:403:40: sparse: sparse: incorrect >> type in argument 1 (different address spaces) @@ expected void volatile >> *address @@ got void [noderef] __iomem * @@ drivers/pci/controller/pcie-mediatek.c:403:40: sparse: expected void volatile *address drivers/pci/controller/pcie-mediatek.c:403:40: sparse: got void [noderef] __iomem * drivers/pci/controller/pcie-mediatek.c:526:44: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void volatile *address @@ got void [noderef] __iomem * @@ drivers/pci/controller/pcie-mediatek.c:526:44: sparse: expected void volatile *address drivers/pci/controller/pcie-mediatek.c:526:44: sparse: got void [noderef] __iomem * -- >> drivers/hwspinlock/stm32_hwspinlock.c:30:39: sparse: sparse: incorrect type >> in initializer (different address spaces) @@ expected void [noderef] >> __iomem *lock_addr @@ got void *priv @@ >> drivers/hwspinlock/stm32_hwspinlock.c:30:39: sparse: expected void >> [noderef] __iomem *lock_addr drivers/hwspinlock/stm32_hwspinlock.c:30:39: sparse: got void *priv drivers/hwspinlock/stm32_hwspinlock.c:41:39: sparse: sparse: incorrect type in initializer (different address spaces) @@ expected void [noderef] __iomem *lock_addr @@ got void *priv @@ drivers/hwspinlock/stm32_hwspinlock.c:41:39: sparse: expected void [noderef] __iomem *lock_addr drivers/hwspinlock/stm32_hwspinlock.c:41:39: sparse: got void *priv >> drivers/hwspinlock/stm32_hwspinlock.c:78:39: sparse: sparse: incorrect type >> in assignment (different address spaces) @@ expected void *priv @@ >> got void [noderef] __iomem * @@ drivers/hwspinlock/stm32_hwspinlock.c:78:39: sparse: expected void *priv >> drivers/hwspinlock/stm32_hwspinlock.c:78:39: sparse: got void [noderef] >> __iomem * -- >> drivers/hwspinlock/sirf_hwspinlock.c:35:39: sparse: sparse: incorrect type >> in initializer (different address spaces) @@ expected void [noderef] >> __iomem *lock_addr @@ got void *priv @@ >> drivers/hwspinlock/sirf_hwspinlock.c:35:39: sparse: expected void >> [noderef] __iomem *lock_addr drivers/hwspinlock/sirf_hwspinlock.c:35:39: sparse: got void *priv drivers/hwspinlock/sirf_hwspinlock.c:43:39: sparse: sparse: incorrect type in initializer (different address spaces) @@ expected void [noderef] __iomem *lock_addr @@ got void *priv @@ drivers/hwspinlock/sirf_hwspinlock.c:43:39: sparse: expected void [noderef] __iomem *lock_addr drivers/hwspinlock/sirf_hwspinlock.c:43:39: sparse: got void *priv >>
drivers/gpu/drm/ttm/ttm_bo_util.c:256:17: sparse: sparse: incorrect type in argument 1 (different address spaces)
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 06a81c1c7db9bd5de0bd38cd5acc44bb22b99150 commit: 670d0a4b10704667765f7d18f7592993d02783aa sparse: use identifiers to define address spaces date: 7 weeks ago config: arm-randconfig-s031-20200809 (attached as .config) compiler: arm-linux-gnueabi-gcc (GCC) 9.3.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # apt-get install sparse # sparse version: v0.6.2-118-ge1578773-dirty git checkout 670d0a4b10704667765f7d18f7592993d02783aa # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=arm If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot sparse warnings: (new ones prefixed by >>) drivers/gpu/drm/ttm/ttm_bo_util.c:219:30: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected void *[assigned] addr @@ got void [noderef] __iomem * @@ drivers/gpu/drm/ttm/ttm_bo_util.c:219:30: sparse: expected void *[assigned] addr drivers/gpu/drm/ttm/ttm_bo_util.c:219:30: sparse: got void [noderef] __iomem * drivers/gpu/drm/ttm/ttm_bo_util.c:221:30: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected void *[assigned] addr @@ got void [noderef] __iomem * @@ drivers/gpu/drm/ttm/ttm_bo_util.c:221:30: sparse: expected void *[assigned] addr drivers/gpu/drm/ttm/ttm_bo_util.c:221:30: sparse: got void [noderef] __iomem * drivers/gpu/drm/ttm/ttm_bo_util.c:241:25: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void volatile [noderef] __iomem *iomem_cookie @@ got void *virtual @@ drivers/gpu/drm/ttm/ttm_bo_util.c:241:25: sparse: expected void volatile [noderef] __iomem *iomem_cookie drivers/gpu/drm/ttm/ttm_bo_util.c:241:25: sparse: got void *virtual >> drivers/gpu/drm/ttm/ttm_bo_util.c:256:17: sparse: sparse: incorrect type in >> argument 1 (different address spaces) @@ expected void const [noderef] >> __iomem *addr @@ got unsigned int [usertype] * @@ drivers/gpu/drm/ttm/ttm_bo_util.c:256:17: sparse: expected void const [noderef] __iomem *addr drivers/gpu/drm/ttm/ttm_bo_util.c:256:17: sparse: got unsigned int [usertype] * drivers/gpu/drm/ttm/ttm_bo_util.c:256:17: sparse: sparse: incorrect type in argument 2 (different address spaces) @@ expected void [noderef] __iomem *addr @@ got unsigned int [usertype] * @@ drivers/gpu/drm/ttm/ttm_bo_util.c:256:17: sparse: expected void [noderef] __iomem *addr drivers/gpu/drm/ttm/ttm_bo_util.c:256:17: sparse: got unsigned int [usertype] * drivers/gpu/drm/ttm/ttm_bo_util.c:275:9: sparse: sparse: incorrect type in argument 2 (different address spaces) @@ expected void const volatile [noderef] __iomem *from @@ got void *[assigned] src @@ drivers/gpu/drm/ttm/ttm_bo_util.c:275:9: sparse: expected void const volatile [noderef] __iomem *from drivers/gpu/drm/ttm/ttm_bo_util.c:275:9: sparse: got void *[assigned] src drivers/gpu/drm/ttm/ttm_bo_util.c:297:9: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void volatile [noderef] __iomem *to @@ got void *[assigned] dst @@ drivers/gpu/drm/ttm/ttm_bo_util.c:297:9: sparse: expected void volatile [noderef] __iomem *to drivers/gpu/drm/ttm/ttm_bo_util.c:297:9: sparse: got void *[assigned] dst drivers/gpu/drm/ttm/ttm_bo_util.c:344:17: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void volatile [noderef] __iomem *dst @@ got void *[addressable] new_iomap @@ drivers/gpu/drm/ttm/ttm_bo_util.c:344:17: sparse: expected void volatile [noderef] __iomem *dst drivers/gpu/drm/ttm/ttm_bo_util.c:344:17: sparse: got void *[addressable] new_iomap drivers/gpu/drm/ttm/ttm_bo_util.c:516:38: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected void *virtual @@ got void [noderef] __iomem * @@ drivers/gpu/drm/ttm/ttm_bo_util.c:516:38: sparse: expected void *virtual drivers/gpu/drm/ttm/ttm_bo_util.c:516:38: sparse: got void [noderef] __iomem * drivers/gpu/drm/ttm/ttm_bo_util.c:519:38: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected void *virtual @@ got void [noderef] __iomem * @@ drivers/gpu/drm/ttm/ttm_bo_util.c:519:38: sparse: expected void *virtual drivers/gpu/drm/ttm/ttm_bo_util.c:519:38: sparse: got void [noderef] __iomem * drivers/gpu/drm/ttm/ttm_bo_util.c:608:28: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void volatile [noderef] __iomem
[PATCH net-next v2] hinic: fix strncpy output truncated compile warnings
fix the compile warnings of 'strncpy' output truncated before
terminating nul copying N bytes from a string of the same length
Signed-off-by: Luo bin
Reported-by: kernel test robot
---
V2~V1:
- remove strncpy
V0~V1:
- use the strlen()+1 pattern consistently
.../net/ethernet/huawei/hinic/hinic_devlink.c | 32 +++
.../net/ethernet/huawei/hinic/hinic_hw_dev.h | 2 --
2 files changed, 12 insertions(+), 22 deletions(-)
diff --git a/drivers/net/ethernet/huawei/hinic/hinic_devlink.c
b/drivers/net/ethernet/huawei/hinic/hinic_devlink.c
index c6adc776f3c8..16bda7381ba0 100644
--- a/drivers/net/ethernet/huawei/hinic/hinic_devlink.c
+++ b/drivers/net/ethernet/huawei/hinic/hinic_devlink.c
@@ -334,19 +334,14 @@ void hinic_devlink_unregister(struct hinic_devlink_priv
*priv)
static int chip_fault_show(struct devlink_fmsg *fmsg,
struct hinic_fault_event *event)
{
- char fault_level[FAULT_TYPE_MAX][FAULT_SHOW_STR_LEN + 1] = {
- "fatal", "reset", "flr", "general", "suggestion"};
- char level_str[FAULT_SHOW_STR_LEN + 1] = {0};
- u8 level;
+ const char * const level_str[FAULT_LEVEL_MAX + 1] = {
+ "fatal", "reset", "flr", "general", "suggestion", "Unknown"};
+ u8 fault_level;
int err;
- level = event->event.chip.err_level;
- if (level < FAULT_LEVEL_MAX)
- strncpy(level_str, fault_level[level],
strlen(fault_level[level]));
- else
- strncpy(level_str, "Unknown", strlen("Unknown"));
-
- if (level == FAULT_LEVEL_SERIOUS_FLR) {
+ fault_level = (event->event.chip.err_level < FAULT_LEVEL_MAX) ?
+ event->event.chip.err_level : FAULT_LEVEL_MAX;
+ if (fault_level == FAULT_LEVEL_SERIOUS_FLR) {
err = devlink_fmsg_u32_pair_put(fmsg, "Function level err
func_id",
(u32)event->event.chip.func_id);
if (err)
@@ -361,7 +356,7 @@ static int chip_fault_show(struct devlink_fmsg *fmsg,
if (err)
return err;
- err = devlink_fmsg_string_pair_put(fmsg, "err_level", level_str);
+ err = devlink_fmsg_string_pair_put(fmsg, "err_level",
level_str[fault_level]);
if (err)
return err;
@@ -381,18 +376,15 @@ static int chip_fault_show(struct devlink_fmsg *fmsg,
static int fault_report_show(struct devlink_fmsg *fmsg,
struct hinic_fault_event *event)
{
- char fault_type[FAULT_TYPE_MAX][FAULT_SHOW_STR_LEN + 1] = {
+ const char * const type_str[FAULT_TYPE_MAX + 1] = {
"chip", "ucode", "mem rd timeout", "mem wr timeout",
- "reg rd timeout", "reg wr timeout", "phy fault"};
- char type_str[FAULT_SHOW_STR_LEN + 1] = {0};
+ "reg rd timeout", "reg wr timeout", "phy fault", "Unknown"};
+ u8 fault_type;
int err;
- if (event->type < FAULT_TYPE_MAX)
- strncpy(type_str, fault_type[event->type],
strlen(fault_type[event->type]));
- else
- strncpy(type_str, "Unknown", strlen("Unknown"));
+ fault_type = (event->type < FAULT_TYPE_MAX) ? event->type :
FAULT_TYPE_MAX;
- err = devlink_fmsg_string_pair_put(fmsg, "Fault type", type_str);
+ err = devlink_fmsg_string_pair_put(fmsg, "Fault type",
type_str[fault_type]);
if (err)
return err;
diff --git a/drivers/net/ethernet/huawei/hinic/hinic_hw_dev.h
b/drivers/net/ethernet/huawei/hinic/hinic_hw_dev.h
index dc6e645f2689..701eb81e09a7 100644
--- a/drivers/net/ethernet/huawei/hinic/hinic_hw_dev.h
+++ b/drivers/net/ethernet/huawei/hinic/hinic_hw_dev.h
@@ -504,8 +504,6 @@ enum hinic_fault_type {
FAULT_TYPE_MAX,
};
-#define FAULT_SHOW_STR_LEN 16
-
enum hinic_fault_err_level {
FAULT_LEVEL_FATAL,
FAULT_LEVEL_SERIOUS_RESET,
--
2.17.1
Re: [PATCH net-next v1] hinic: fix strncpy output truncated compile warnings
On 2020/8/8 20:50, David Laight wrote: > From: luobin (L) >> Sent: 08 August 2020 04:37 >> >> On 2020/8/7 17:32, David Laight wrote: >>> From: Luo bin Sent: 07 August 2020 03:09 fix the compile warnings of 'strncpy' output truncated before terminating nul copying N bytes from a string of the same length Signed-off-by: Luo bin Reported-by: kernel test robot --- V0~V1: - use the strlen()+1 pattern consistently drivers/net/ethernet/huawei/hinic/hinic_devlink.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/net/ethernet/huawei/hinic/hinic_devlink.c b/drivers/net/ethernet/huawei/hinic/hinic_devlink.c index c6adc776f3c8..1ec88ebf81d6 100644 --- a/drivers/net/ethernet/huawei/hinic/hinic_devlink.c +++ b/drivers/net/ethernet/huawei/hinic/hinic_devlink.c @@ -342,9 +342,9 @@ static int chip_fault_show(struct devlink_fmsg *fmsg, level = event->event.chip.err_level; if (level < FAULT_LEVEL_MAX) - strncpy(level_str, fault_level[level], strlen(fault_level[level])); + strncpy(level_str, fault_level[level], strlen(fault_level[level]) + 1); >>> >>> Have you even considered what that code is actually doing? >>> >>> David >> >> I'm sorry that I haven't got what you mean and I haven't found any defects >> in that code. Can you >> explain more to me? > > If you can't see it you probably shouldn't be submitting patches > > Consider what happens when the string is long. > > David > > - > Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 > 1PT, UK > Registration No: 1397386 (Wales) > Thanks for your explanation and review. The fault_level[level] is a fixed and NUL-terminated character string in that code and its length is smaller than the dest buffer size so I think using strlen(fault_level[level]) + 1 will not overflow the destination buffer. But using strncpy() on NUL-terminated strings is dangerous indeed and there is totally no need to use it in that code as Kees points out.
drivers/char/tpm/tpm_ibmvtpm.c:130:30: sparse: sparse: cast removes address space '__iomem' of expression
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 06a81c1c7db9bd5de0bd38cd5acc44bb22b99150 commit: 670d0a4b10704667765f7d18f7592993d02783aa sparse: use identifiers to define address spaces date: 7 weeks ago config: powerpc64-randconfig-s032-20200808 (attached as .config) compiler: powerpc64-linux-gcc (GCC) 9.3.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # apt-get install sparse # sparse version: v0.6.2-118-ge1578773-dirty git checkout 670d0a4b10704667765f7d18f7592993d02783aa # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=powerpc64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot sparse warnings: (new ones prefixed by >>) >> drivers/char/tpm/tpm_ibmvtpm.c:130:30: sparse: sparse: cast removes address >> space '__iomem' of expression >> drivers/char/tpm/tpm_ibmvtpm.c:131:23: sparse: sparse: incorrect type in >> argument 1 (different address spaces) @@ expected void * @@ got void >> [noderef] __iomem *rtce_buf @@ drivers/char/tpm/tpm_ibmvtpm.c:131:23: sparse: expected void * >> drivers/char/tpm/tpm_ibmvtpm.c:131:23: sparse: got void [noderef] >> __iomem *rtce_buf drivers/char/tpm/tpm_ibmvtpm.c:234:17: sparse: sparse: cast removes address space '__iomem' of expression >> drivers/char/tpm/tpm_ibmvtpm.c:369:30: sparse: sparse: incorrect type in >> argument 1 (different address spaces) @@ expected void const * @@ >> got void [noderef] __iomem *rtce_buf @@ drivers/char/tpm/tpm_ibmvtpm.c:369:30: sparse: expected void const * drivers/char/tpm/tpm_ibmvtpm.c:369:30: sparse: got void [noderef] __iomem *rtce_buf >> drivers/char/tpm/tpm_ibmvtpm.c:530:43: sparse: sparse: incorrect type in >> assignment (different address spaces) @@ expected void [noderef] __iomem >> *rtce_buf @@ got void * @@ >> drivers/char/tpm/tpm_ibmvtpm.c:530:43: sparse: expected void [noderef] >> __iomem *rtce_buf drivers/char/tpm/tpm_ibmvtpm.c:530:43: sparse: got void * >> drivers/char/tpm/tpm_ibmvtpm.c:537:52: sparse: sparse: incorrect type in >> argument 2 (different address spaces) @@ expected void *ptr @@ got >> void [noderef] __iomem *rtce_buf @@ drivers/char/tpm/tpm_ibmvtpm.c:537:52: sparse: expected void *ptr drivers/char/tpm/tpm_ibmvtpm.c:537:52: sparse: got void [noderef] __iomem *rtce_buf drivers/char/tpm/tpm_ibmvtpm.c:543:46: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void const * @@ got void [noderef] __iomem *rtce_buf @@ drivers/char/tpm/tpm_ibmvtpm.c:543:46: sparse: expected void const * drivers/char/tpm/tpm_ibmvtpm.c:543:46: sparse: got void [noderef] __iomem *rtce_buf -- drivers/vfio/pci/vfio_pci_nvlink2.c: note: in included file (through include/trace/trace_events.h, include/trace/define_trace.h, drivers/vfio/pci/trace.h): include/trace/../../drivers/vfio/pci/trace.h:17:1: sparse: sparse: incorrect type in assignment (different base types) @@ expected int ret @@ got restricted vm_fault_t [usertype] ret @@ include/trace/../../drivers/vfio/pci/trace.h:17:1: sparse: expected int ret include/trace/../../drivers/vfio/pci/trace.h:17:1: sparse: got restricted vm_fault_t [usertype] ret >> drivers/vfio/pci/vfio_pci_nvlink2.c:76:40: sparse: sparse: incorrect type in >> argument 1 (different address spaces) @@ expected void *to @@ got >> void [noderef] __iomem * @@ drivers/vfio/pci/vfio_pci_nvlink2.c:76:40: sparse: expected void *to >> drivers/vfio/pci/vfio_pci_nvlink2.c:76:40: sparse: got void [noderef] >> __iomem * >> drivers/vfio/pci/vfio_pci_nvlink2.c:81:43: sparse: sparse: incorrect type in >> argument 2 (different address spaces) @@ expected void const *from @@ >> got void [noderef] __iomem * @@ drivers/vfio/pci/vfio_pci_nvlink2.c:81:43: sparse: expected void const *from drivers/vfio/pci/vfio_pci_nvlink2.c:81:43: sparse: got void [noderef] __iomem * vim +/__iomem +130 drivers/char/tpm/tpm_ibmvtpm.c 132f7629474424 Ashley Lai2012-08-22 94 132f7629474424 Ashley Lai2012-08-22 95 /** 132f7629474424 Ashley Lai2012-08-22 96 * tpm_ibmvtpm_recv - Receive data after send 93c12f293f8798 Winkler, Tomas2016-11-23 97 * 132f7629474424 Ashley Lai2012-08-22 98 * @chip: tpm chip struct 132f7629474424 Ashley Lai2012-08-22 99 * @buf: buffer to read 93c12f293f8798 Winkler, Tomas2016-11-23 100 * @count:size of
{standard input}:1347: Error: found '(', expected: ')'
Hi Paul,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 06a81c1c7db9bd5de0bd38cd5acc44bb22b99150
commit: 21e3134b3ec09e722cbcda69788f206adc8db1f4 MIPS: barrier: Clean up rmb()
& wmb() definitions
date: 10 months ago
config: mips-randconfig-r005-20200809 (attached as .config)
compiler: mipsel-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 21e3134b3ec09e722cbcda69788f206adc8db1f4
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=mips
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
{standard input}: Assembler messages:
>> {standard input}:1347: Error: found '(', expected: ')'
>> {standard input}:1347: Error: found '(', expected: ')'
>> {standard input}:1347: Error: non-constant expression in ".if" statement
>> {standard input}:1347: Error: junk at end of line, first unrecognized
>> character is `('
{standard input}:1487: Error: found '(', expected: ')'
{standard input}:1487: Error: found '(', expected: ')'
{standard input}:1487: Error: non-constant expression in ".if" statement
{standard input}:1487: Error: junk at end of line, first unrecognized
character is `('
{standard input}:1697: Error: found '(', expected: ')'
{standard input}:1697: Error: found '(', expected: ')'
{standard input}:1697: Error: non-constant expression in ".if" statement
{standard input}:1697: Error: junk at end of line, first unrecognized
character is `('
{standard input}:2633: Error: found '(', expected: ')'
{standard input}:2633: Error: found '(', expected: ')'
{standard input}:2633: Error: non-constant expression in ".if" statement
{standard input}:2633: Error: junk at end of line, first unrecognized
character is `('
{standard input}:2815: Error: found '(', expected: ')'
{standard input}:2815: Error: found '(', expected: ')'
{standard input}:2815: Error: non-constant expression in ".if" statement
{standard input}:2815: Error: junk at end of line, first unrecognized
character is `('
{standard input}:2979: Error: found '(', expected: ')'
{standard input}:2979: Error: found '(', expected: ')'
{standard input}:2979: Error: non-constant expression in ".if" statement
{standard input}:2979: Error: junk at end of line, first unrecognized
character is `('
{standard input}:3178: Error: found '(', expected: ')'
{standard input}:3178: Error: found '(', expected: ')'
{standard input}:3178: Error: non-constant expression in ".if" statement
{standard input}:3178: Error: junk at end of line, first unrecognized
character is `('
{standard input}:3440: Error: found '(', expected: ')'
{standard input}:3440: Error: found '(', expected: ')'
{standard input}:3440: Error: non-constant expression in ".if" statement
{standard input}:3440: Error: junk at end of line, first unrecognized
character is `('
{standard input}:3684: Error: found '(', expected: ')'
{standard input}:3684: Error: found '(', expected: ')'
{standard input}:3684: Error: non-constant expression in ".if" statement
{standard input}:3684: Error: junk at end of line, first unrecognized
character is `('
{standard input}:3878: Error: found '(', expected: ')'
{standard input}:3878: Error: found '(', expected: ')'
{standard input}:3878: Error: non-constant expression in ".if" statement
{standard input}:3878: Error: junk at end of line, first unrecognized
character is `('
{standard input}:4001: Error: found '(', expected: ')'
{standard input}:4001: Error: found '(', expected: ')'
{standard input}:4001: Error: non-constant expression in ".if" statement
{standard input}:4001: Error: junk at end of line, first unrecognized
character is `('
{standard input}:4287: Error: found '(', expected: ')'
{standard input}:4287: Error: found '(', expected: ')'
{standard input}:4287: Error: non-constant expression in ".if" statement
{standard input}:4287: Error: junk at end of line, first unrecognized
character is `('
{standard input}:4360: Error: found '(', expected: ')'
{standard input}:4360: Error: found '(', expected: ')'
{standard input}:4360: Error: non-constant expression in ".if" statement
{standard input}:4360: Error: junk at end of line, first unrecognized
character is `('
{standard input}:4448: Error: found '(', expected: ')'
{standard input}:4448: Error: found '(', expected: ')'
{standard input}:4448: Error: non-constant expression in ".if" statement
{standard input}:4448: Error: junk at end of line, first unrecognized
character is `('
{standard input}:4772: Error: found '(', expected: ')'
{standard
Re: [PATCH net-next v1] hinic: fix strncpy output truncated compile warnings
On 2020/8/8 14:44, Kees Cook wrote:
> On Fri, Aug 07, 2020 at 08:42:43PM -0700, David Miller wrote:
>> From: "luobin (L)"
>> Date: Sat, 8 Aug 2020 11:36:42 +0800
>>
>>> On 2020/8/7 17:32, David Laight wrote:
> diff --git a/drivers/net/ethernet/huawei/hinic/hinic_devlink.c
> b/drivers/net/ethernet/huawei/hinic/hinic_devlink.c
> index c6adc776f3c8..1ec88ebf81d6 100644
> --- a/drivers/net/ethernet/huawei/hinic/hinic_devlink.c
> +++ b/drivers/net/ethernet/huawei/hinic/hinic_devlink.c
> @@ -342,9 +342,9 @@ static int chip_fault_show(struct devlink_fmsg *fmsg,
>
> level = event->event.chip.err_level;
> if (level < FAULT_LEVEL_MAX)
> - strncpy(level_str, fault_level[level],
> strlen(fault_level[level]));
> + strncpy(level_str, fault_level[level],
> strlen(fault_level[level]) + 1);
Have you even considered what that code is actually doing?
>> ...
>>> I'm sorry that I haven't got what you mean and I haven't found any defects
>>> in that code. Can you explain more to me?
>>
>> David is trying to express the same thing I was trying to explain to
>> you, you should use sizeof(level_str) as the third argument because
>> the code is trying to make sure that the destination buffer is not
>> overrun.
>>
>> If you use the strlen() of the source buffer, the strncpy() can still
>> overflow the destination buffer.
>>
>> Now do you understand?
>
> Agh, please never use strncpy() on NUL-terminated strings[1]. (You can
> see this ultimately gets passed down into devlink_fmsg_string_put()
> which expects NUL-terminated strings and does not require trailing
> NUL-padding (which if it did, should still never use strncpy(), but
> rather strscpy_pad()).
>
> But, as David Laight hints, none of this is needed. The entire buffer
> can be avoided (just point into the existing array of strings -- which
> should also be const). Add I see that one of the array sizes is wrong.
> Both use FAULT_TYPE_MAX, but one should be FAULT_LEVEL_MAX. And since
> "Unknown" can just be added to the array, do that and clamp the value
> since it's only used for finding the strings in the array.
>
> I would suggest this (totally untested):
>
> diff --git a/drivers/net/ethernet/huawei/hinic/hinic_devlink.c
> b/drivers/net/ethernet/huawei/hinic/hinic_devlink.c
> index c6adc776f3c8..20bfb05896e5 100644
> --- a/drivers/net/ethernet/huawei/hinic/hinic_devlink.c
> +++ b/drivers/net/ethernet/huawei/hinic/hinic_devlink.c
> @@ -334,18 +334,12 @@ void hinic_devlink_unregister(struct hinic_devlink_priv
> *priv)
> static int chip_fault_show(struct devlink_fmsg *fmsg,
> struct hinic_fault_event *event)
> {
> - char fault_level[FAULT_TYPE_MAX][FAULT_SHOW_STR_LEN + 1] = {
> - "fatal", "reset", "flr", "general", "suggestion"};
> - char level_str[FAULT_SHOW_STR_LEN + 1] = {0};
> - u8 level;
> + const char * const level_str[FAULT_LEVEL_MAX + 1] = {
> + "fatal", "reset", "flr", "general", "suggestion",
> + [FAULT_LEVEL_MAX] = "Unknown"};
> + u8 fault_level;
> int err;
>
> - level = event->event.chip.err_level;
> - if (level < FAULT_LEVEL_MAX)
> - strncpy(level_str, fault_level[level],
> strlen(fault_level[level]));
> - else
> - strncpy(level_str, "Unknown", strlen("Unknown"));
> -
> if (level == FAULT_LEVEL_SERIOUS_FLR) {
> err = devlink_fmsg_u32_pair_put(fmsg, "Function level err
> func_id",
> (u32)event->event.chip.func_id);
> @@ -361,7 +355,8 @@ static int chip_fault_show(struct devlink_fmsg *fmsg,
> if (err)
> return err;
>
> - err = devlink_fmsg_string_pair_put(fmsg, "err_level", level_str);
> + fault_level = clamp(event->event.chip.err_level, FAULT_LEVEL_MAX);
> + err = devlink_fmsg_string_pair_put(fmsg, "err_level",
> fault_str[fault_level]);
> if (err)
> return err;
>
> @@ -381,18 +376,15 @@ static int chip_fault_show(struct devlink_fmsg *fmsg,
> static int fault_report_show(struct devlink_fmsg *fmsg,
>struct hinic_fault_event *event)
> {
> - char fault_type[FAULT_TYPE_MAX][FAULT_SHOW_STR_LEN + 1] = {
> + const char * const type_str[FAULT_TYPE_MAX + 1] = {
> "chip", "ucode", "mem rd timeout", "mem wr timeout",
> - "reg rd timeout", "reg wr timeout", "phy fault"};
> - char type_str[FAULT_SHOW_STR_LEN + 1] = {0};
> + "reg rd timeout", "reg wr timeout", "phy fault",
> + [FAULT_TYPE_MAX] = "Unknown"};
> + u8 fault_type;
> int err;
>
> - if (event->type < FAULT_TYPE_MAX)
> - strncpy(type_str, fault_type[event->type],
> strlen(fault_type[event->type]));
> - else
> - strncpy(type_str, "Unknown", strlen("Unknown"));
> -
> - err = devlink_fmsg_string_pair_put(fmsg, "Fault type", type_str);
> +
Bradly Spengler interview (GRSecurity) (Blatant GPL violators vs GCC and Linux Kernel)
Thought you might be interested: https://www.youtube.com/watch?v=rv3a2tzUTn4 GRSecurity violates both the Linux kernel's copyright and the GCC copyright by forbidding redistribution of the patches (in their Access Agreement): which are non-seperable derivative works of the kernel and (in the case of the GCC plugins) GCC. Yes: threatening consequences if a licensee redistributes is a restraint on the "rights" given by the original copyright owners. Those "plugins" he is talking about as-well as the kernel patch violate the GPLv2. The GPLv2 _FORBIDS_ adding additional clauses not-within the GPL between the derivative-licensee and the down-the-line licensee. Bradly Spengler / OpenSourceSecurity are violating this stipulation, blatantly, in writing. They are also violating the "no additional restrictions" stipulation in the GPLv2. They ARE violating the Linux and the GCC copyright.
Re: [PATCH net-next v1] hinic: fix strncpy output truncated compile warnings
On 2020/8/8 11:42, David Miller wrote: > From: "luobin (L)" > Date: Sat, 8 Aug 2020 11:36:42 +0800 > >> On 2020/8/7 17:32, David Laight wrote: diff --git a/drivers/net/ethernet/huawei/hinic/hinic_devlink.c b/drivers/net/ethernet/huawei/hinic/hinic_devlink.c index c6adc776f3c8..1ec88ebf81d6 100644 --- a/drivers/net/ethernet/huawei/hinic/hinic_devlink.c +++ b/drivers/net/ethernet/huawei/hinic/hinic_devlink.c @@ -342,9 +342,9 @@ static int chip_fault_show(struct devlink_fmsg *fmsg, level = event->event.chip.err_level; if (level < FAULT_LEVEL_MAX) - strncpy(level_str, fault_level[level], strlen(fault_level[level])); + strncpy(level_str, fault_level[level], strlen(fault_level[level]) + 1); >>> >>> Have you even considered what that code is actually doing? > ... >> I'm sorry that I haven't got what you mean and I haven't found any defects >> in that code. Can you explain more to me? > > David is trying to express the same thing I was trying to explain to > you, you should use sizeof(level_str) as the third argument because > the code is trying to make sure that the destination buffer is not > overrun. > > If you use the strlen() of the source buffer, the strncpy() can still > overflow the destination buffer. > > Now do you understand? > . > Thanks for your explanation. I explained that why I didn't use sizeof(level_str) as the third argument in my previous reply e-mail to you. Because using sizeof(level_str) as the third argument will still cause the following compile warning: In function ‘strncpy’, inlined from ‘chip_fault_show’ at drivers/net/ethernet/huawei/hinic/hinic_devlink.c:345:3: ./include/linux/string.h:297:30: warning: ‘__builtin_strncpy’ specified bound 17 equals destination size [-Wstringop-truncation] 297 | #define __underlying_strncpy __builtin_strncpy Now I know that using strncpy() on NUL-terminated strings is deprecated as Kees Cook points out and actually there is no need to use it in my code.
Re: splice: infinite busy loop lockup bug
On Sun, Aug 09, 2020 at 10:31:23AM +0800, Ming Lei wrote:
> On Fri, Aug 07, 2020 at 03:11:48PM +0100, Matthew Wilcox wrote:
> > On Fri, Aug 07, 2020 at 09:41:14PM +0800, Ming Lei wrote:
> > > On Fri, Aug 07, 2020 at 01:38:54PM +0100, Al Viro wrote:
> > > > FWIW, my preference would be to have for_each_bvec() advance past
> > > > zero-length
> > > > segments; I'll need to go through its uses elsewhere in the tree first,
> > > > though
> > > > (after I grab some sleep),
> > >
> > > Usually block layer doesn't allow/support zero bvec, however we can make
> > > for_each_bvec() to support it only.
> > >
> > > Tetsuo, can you try the following patch?
> > >
> > > diff --git a/include/linux/bvec.h b/include/linux/bvec.h
> > > index ac0c7299d5b8..b03c793dd28d 100644
> > > --- a/include/linux/bvec.h
> > > +++ b/include/linux/bvec.h
> > > @@ -117,11 +117,19 @@ static inline bool bvec_iter_advance(const struct
> > > bio_vec *bv,
> > > return true;
> > > }
> > >
> > > +static inline void bvec_iter_skip_zero_vec(const struct bio_vec *bv,
> > > + struct bvec_iter *iter)
> > > +{
> > > + iter->bi_idx++;
> > > + iter->bi_bvec_done = 0;
> > > +}
> > > +
> > > #define for_each_bvec(bvl, bio_vec, iter, start) \
> > > for (iter = (start);\
> > >(iter).bi_size && \
> > > - ((bvl = bvec_iter_bvec((bio_vec), (iter))), 1); \
> > > - bvec_iter_advance((bio_vec), &(iter), (bvl).bv_len))
> > > + ((bvl = bvec_iter_bvec((bio_vec), (iter))), 1); \
> > > + (bvl).bv_len ? bvec_iter_advance((bio_vec), &(iter), (bvl).bv_len) : \
> > > + bvec_iter_skip_zero_vec((bio_vec), &(iter)))
> >
> > Uhm, bvec_iter_advance() already skips over zero length bio_vecs.
> >
> > while (bytes && bytes >= bv[idx].bv_len) {
> > bytes -= bv[idx].bv_len;
> > idx++;
> > }
>
> The issue is that zero (bvl).bv_len passed to bvec_iter_advance(), so
> the iterator can't move on.
>
> And I tried to avoid change to bvec_iter_advance() since this exact
> issue only exists on for_each_bvec, and block layer won't support/allow
> zero-length bvec.
>
> >
> > The problem is when the _first_ bio_vec is zero length.
>
> It can be any zero-length bvec during the iterating.
>
> > Maybe something more
> > like this (which doesn't even compile, but hopefully makes my point):
> >
> > @@ -86,12 +86,24 @@ struct bvec_iter_all {
> > (mp_bvec_iter_page((bvec), (iter)) +\
> > mp_bvec_iter_page_idx((bvec), (iter)))
> >
> > -#define bvec_iter_bvec(bvec, iter) \
> > -((struct bio_vec) {\
> > - .bv_page= bvec_iter_page((bvec), (iter)), \
> > - .bv_len = bvec_iter_len((bvec), (iter)),\
> > - .bv_offset = bvec_iter_offset((bvec), (iter)), \
> > -})
> > +static inline bool bvec_iter_bvec(struct bio_vec *bv, struct bio_vec *bvec,
> > + struct bvec_iter *iter)
> > +{
> > + unsigned int idx = iter->bi_idx;
> > +
> > + if (!iter->bi_size)
> > + return false;
> > +
> > + while (!bv[idx].bv_len)
> > + idx++;
> > + iter->bi_idx = idx;
> > +
> > + bv->bv_page = bvec_iter_page(bvec, *iter);
> > + bv->bv_len = bvec_iter_len(bvec, *iter);
> > + bv->bv_offset = bvec_iter_offset(bvec, *iter);
> > +
> > + return true;
> > +}
> >
> > static inline bool bvec_iter_advance(const struct bio_vec *bv,
> > struct bvec_iter *iter, unsigned bytes)
> > @@ -119,8 +131,7 @@ static inline bool bvec_iter_advance(const struct
> > bio_vec *bv,
> >
> > #define for_each_bvec(bvl, bio_vec, iter, start) \
> > for (iter = (start);\
> > -(iter).bi_size && \
> > - ((bvl = bvec_iter_bvec((bio_vec), (iter))), 1); \
> > +bvec_iter_bvec(&(bvl), (bio_vec), &(iter));\
> > bvec_iter_advance((bio_vec), &(iter), (bvl).bv_len))
> >
> > /* for iterating one bio from start to end */
> >
> > (I find the whole bvec handling a mess of confusing macros and would
> > welcome more of it being inline functions, in general).
>
> The above change may bring more code duplication. Meantime, it can't
> work because (bvl).bv_len isn't taken into account into bvec_iter_bvec(),
> then how can the iterator advance?
oops, looks you change bvec_iter_bvec() only for skipping zero length bvec,
and this way might work(still ->bi_bvec_done isn't reset). However the
change is ugly, cause the iterator is supposed to not be updated in
bvec_iter_bvec(). Also block layer code doesn't require such change.
BTW, I agree on switching to inline if performance isn't affected.
drivers/hwspinlock/stm32_hwspinlock.c:30:39: sparse: got void
Hi Baolin,
First bad commit (maybe != root cause):
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 06a81c1c7db9bd5de0bd38cd5acc44bb22b99150
commit: ffd0bbfb378ecd56eac22bf932ccdbf89ac7f725 hwspinlock: Allow drivers to
be built with COMPILE_TEST
date: 5 months ago
config: i386-randconfig-s031-20200809 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
reproduce:
# apt-get install sparse
# sparse version: v0.6.2-118-ge1578773-dirty
git checkout ffd0bbfb378ecd56eac22bf932ccdbf89ac7f725
# save the attached .config to linux build tree
make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=i386
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
sparse warnings: (new ones prefixed by >>)
drivers/hwspinlock/stm32_hwspinlock.c:30:39: sparse: sparse: incorrect type
in initializer (different address spaces) @@ expected void [noderef]
*lock_addr @@ got void *priv @@
drivers/hwspinlock/stm32_hwspinlock.c:30:39: sparse: expected void
[noderef] *lock_addr
>> drivers/hwspinlock/stm32_hwspinlock.c:30:39: sparse: got void *priv
drivers/hwspinlock/stm32_hwspinlock.c:41:39: sparse: sparse: incorrect type
in initializer (different address spaces) @@ expected void [noderef]
*lock_addr @@ got void *priv @@
drivers/hwspinlock/stm32_hwspinlock.c:41:39: sparse: expected void
[noderef] *lock_addr
drivers/hwspinlock/stm32_hwspinlock.c:41:39: sparse: got void *priv
drivers/hwspinlock/stm32_hwspinlock.c:78:39: sparse: sparse: incorrect type
in assignment (different address spaces) @@ expected void *priv @@ got
void [noderef] * @@
>> drivers/hwspinlock/stm32_hwspinlock.c:78:39: sparse: expected void *priv
drivers/hwspinlock/stm32_hwspinlock.c:78:39: sparse: got void [noderef]
*
--
drivers/hwspinlock/sirf_hwspinlock.c:35:39: sparse: sparse: incorrect type
in initializer (different address spaces) @@ expected void [noderef]
*lock_addr @@ got void *priv @@
drivers/hwspinlock/sirf_hwspinlock.c:35:39: sparse: expected void
[noderef] *lock_addr
>> drivers/hwspinlock/sirf_hwspinlock.c:35:39: sparse: got void *priv
drivers/hwspinlock/sirf_hwspinlock.c:43:39: sparse: sparse: incorrect type
in initializer (different address spaces) @@ expected void [noderef]
*lock_addr @@ got void *priv @@
drivers/hwspinlock/sirf_hwspinlock.c:43:39: sparse: expected void
[noderef] *lock_addr
drivers/hwspinlock/sirf_hwspinlock.c:43:39: sparse: got void *priv
drivers/hwspinlock/sirf_hwspinlock.c:77:30: sparse: sparse: incorrect type
in assignment (different address spaces) @@ expected void *priv @@ got
void [noderef] * @@
>> drivers/hwspinlock/sirf_hwspinlock.c:77:30: sparse: expected void *priv
drivers/hwspinlock/sirf_hwspinlock.c:77:30: sparse: got void [noderef]
*
--
drivers/hwspinlock/sprd_hwspinlock.c:46:34: sparse: sparse: incorrect type
in initializer (different address spaces) @@ expected void [noderef]
*addr @@ got void *priv @@
drivers/hwspinlock/sprd_hwspinlock.c:46:34: sparse: expected void
[noderef] *addr
>> drivers/hwspinlock/sprd_hwspinlock.c:46:34: sparse: got void *priv
drivers/hwspinlock/sprd_hwspinlock.c:64:39: sparse: sparse: incorrect type
in initializer (different address spaces) @@ expected void [noderef]
*lock_addr @@ got void *priv @@
drivers/hwspinlock/sprd_hwspinlock.c:64:39: sparse: expected void
[noderef] *lock_addr
drivers/hwspinlock/sprd_hwspinlock.c:64:39: sparse: got void *priv
drivers/hwspinlock/sprd_hwspinlock.c:131:28: sparse: sparse: incorrect type
in assignment (different address spaces) @@ expected void *priv @@ got
void [noderef] * @@
>> drivers/hwspinlock/sprd_hwspinlock.c:131:28: sparse: expected void *priv
drivers/hwspinlock/sprd_hwspinlock.c:131:28: sparse: got void [noderef]
*
vim +30 drivers/hwspinlock/stm32_hwspinlock.c
f24fcff1d267da Benjamin Gaignard 2018-11-14 27
f24fcff1d267da Benjamin Gaignard 2018-11-14 28 static int
stm32_hwspinlock_trylock(struct hwspinlock *lock)
f24fcff1d267da Benjamin Gaignard 2018-11-14 29 {
f24fcff1d267da Benjamin Gaignard 2018-11-14 @30 void __iomem *lock_addr
= lock->priv;
f24fcff1d267da Benjamin Gaignard 2018-11-14 31 u32 status;
f24fcff1d267da Benjamin Gaignard 2018-11-14 32
f24fcff1d267da Benjamin Gaignard 2018-11-14 33
writel(STM32_MUTEX_LOCK_BIT | STM32_MUTEX_COREID, lock_addr);
f24fcff1d267da Benjamin Gaignard 2018-11-14 34 status =
readl(lock_addr);
f24fcff1d267da Benjamin Gaignard 2018-11-14 35
f24fcff1d267da Benjamin Gaignard 2018-11-14 36 return status ==
(STM32_MUTEX_LOCK_BIT | STM32_MUTEX_COREID);
f24fcff1d267da Benjamin Gaignard 2018-11-14 37 }
f24fcff1d267da Benjamin Gaignard 2018-11-14 38
f24fcff1d267da
Re: Very slow qemu device access
Hello Matthew,
On Fri, Aug 07, 2020 at 06:44:16PM +0100, Matthew Wilcox wrote:
>
> Everything starts going very slowly after this commit:
>
> commit 37f4a24c2469a10a4c16c641671bd766e276cf9f (refs/bisect/bad)
> Author: Ming Lei
> Date: Tue Jun 30 22:03:57 2020 +0800
>
> blk-mq: centralise related handling into blk_mq_get_driver_tag
Yeah, the above is one known bad commit, which is reverted in
4e2f62e566b5 ("Revert "blk-mq: put driver tag when this request is completed")
Finally the fixed patch of 'blk-mq: centralise related handling into
blk_mq_get_driver_tag'
is merged as 568f27006577 ("blk-mq: centralise related handling into
blk_mq_get_driver_tag").
So please test either 4e2f62e566b5 or 568f27006577 and see if there is
such issue.
Thanks,
Ming
Re: [PATCH v3 1/3] scsi: 3w-9xxx: Use flexible array members to avoid struct padding
On Sat, 2020-08-08 at 19:47 -0500, Samuel Holland wrote: > In preparation for removing the "#pragma pack(1)" from the driver, fix > all instances where a trailing array member could be replaced by a > flexible array member. Since a flexible array member has zero size, it > introduces no padding, whether or not the struct is packed. [] > diff --git a/drivers/scsi/3w-9xxx.c b/drivers/scsi/3w-9xxx.c [] > @@ -676,7 +676,7 @@ static long twa_chrdev_ioctl(struct file *file, unsigned > int cmd, unsigned long > data_buffer_length_adjusted = (driver_command.buffer_length + 511) & > ~511; > > /* Now allocate ioctl buf memory */ > - cpu_addr = dma_alloc_coherent(_dev->tw_pci_dev->dev, > data_buffer_length_adjusted+sizeof(TW_Ioctl_Buf_Apache) - 1, _handle, > GFP_KERNEL); > + cpu_addr = dma_alloc_coherent(_dev->tw_pci_dev->dev, > data_buffer_length_adjusted + sizeof(TW_Ioctl_Buf_Apache), _handle, > GFP_KERNEL); Trivia: It's perhaps more sensible to order the arguments with the size of the struct first then the data length so the argument is in the order of the expected content. cpu_addr = dma_alloc_coherent(_dev->tw_pci_dev->dev, sizeof(TW_Ioctl_Buf_Apache) + data_buffer_length_adjusted, _handle, GFP_KERNEL); > @@ -685,7 +685,7 @@ static long twa_chrdev_ioctl(struct file *file, unsigned > int cmd, unsigned long > tw_ioctl = (TW_Ioctl_Buf_Apache *)cpu_addr; > > /* Now copy down the entire ioctl */ > - if (copy_from_user(tw_ioctl, argp, driver_command.buffer_length + > sizeof(TW_Ioctl_Buf_Apache) - 1)) > + if (copy_from_user(tw_ioctl, argp, driver_command.buffer_length + > sizeof(TW_Ioctl_Buf_Apache))) if (copy_from_user(tw_ioctl, argp, sizeof(TW_Ioctl_Buf_Apache) + driver_command.buffer_length)) etc...
[PATCH net] drivers/net/wan/x25_asy: Added needed_headroom and a skb->len check
1. Added a skb->len check
This driver expects upper layers to include a pseudo header of 1 byte
when passing down a skb for transmission. This driver will read this
1-byte header. This patch added a skb->len check before reading the
header to make sure the header exists.
2. Added needed_headroom
When this driver transmits data,
first this driver will remove a pseudo header of 1 byte,
then the lapb module will prepend the LAPB header of 2 or 3 bytes.
So the value of needed_headroom in this driver should be 3 - 1.
Cc: Willem de Bruijn
Cc: Martin Schiller
Signed-off-by: Xie He
---
drivers/net/wan/x25_asy.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/net/wan/x25_asy.c b/drivers/net/wan/x25_asy.c
index 84640a0c13f3..de7984463595 100644
--- a/drivers/net/wan/x25_asy.c
+++ b/drivers/net/wan/x25_asy.c
@@ -307,6 +307,14 @@ static netdev_tx_t x25_asy_xmit(struct sk_buff *skb,
return NETDEV_TX_OK;
}
+ /* There should be a pseudo header of 1 byte added by upper layers.
+* Check to make sure it is there before reading it.
+*/
+ if (skb->len < 1) {
+ kfree_skb(skb);
+ return NETDEV_TX_OK;
+ }
+
switch (skb->data[0]) {
case X25_IFACE_DATA:
break;
@@ -752,6 +760,12 @@ static void x25_asy_setup(struct net_device *dev)
dev->type = ARPHRD_X25;
dev->tx_queue_len = 10;
+ /* When transmitting data:
+* first this driver removes a pseudo header of 1 byte,
+* then the lapb module prepends an LAPB header of at most 3 bytes.
+*/
+ dev->needed_headroom= 3 - 1;
+
/* New-style flags. */
dev->flags = IFF_NOARP;
}
--
2.25.1
Re: [PATCH v3 4/7] x86/paravirt: remove 32-bit support from PARAVIRT_XXL
On 8/7/20 4:38 AM, Juergen Gross wrote:
> @@ -377,10 +373,7 @@ static inline pte_t __pte(pteval_t val)
> {
> pteval_t ret;
>
> - if (sizeof(pteval_t) > sizeof(long))
> - ret = PVOP_CALLEE2(pteval_t, mmu.make_pte, val, (u64)val >> 32);
> - else
> - ret = PVOP_CALLEE1(pteval_t, mmu.make_pte, val);
> + ret = PVOP_CALLEE1(pteval_t, mmu.make_pte, val);
>
> return (pte_t) { .pte = ret };
Can this now simply return (pte_t) ret?
-boris
Re: splice: infinite busy loop lockup bug
On Fri, Aug 07, 2020 at 03:11:48PM +0100, Matthew Wilcox wrote:
> On Fri, Aug 07, 2020 at 09:41:14PM +0800, Ming Lei wrote:
> > On Fri, Aug 07, 2020 at 01:38:54PM +0100, Al Viro wrote:
> > > FWIW, my preference would be to have for_each_bvec() advance past
> > > zero-length
> > > segments; I'll need to go through its uses elsewhere in the tree first,
> > > though
> > > (after I grab some sleep),
> >
> > Usually block layer doesn't allow/support zero bvec, however we can make
> > for_each_bvec() to support it only.
> >
> > Tetsuo, can you try the following patch?
> >
> > diff --git a/include/linux/bvec.h b/include/linux/bvec.h
> > index ac0c7299d5b8..b03c793dd28d 100644
> > --- a/include/linux/bvec.h
> > +++ b/include/linux/bvec.h
> > @@ -117,11 +117,19 @@ static inline bool bvec_iter_advance(const struct
> > bio_vec *bv,
> > return true;
> > }
> >
> > +static inline void bvec_iter_skip_zero_vec(const struct bio_vec *bv,
> > + struct bvec_iter *iter)
> > +{
> > + iter->bi_idx++;
> > + iter->bi_bvec_done = 0;
> > +}
> > +
> > #define for_each_bvec(bvl, bio_vec, iter, start) \
> > for (iter = (start);\
> > (iter).bi_size && \
> > - ((bvl = bvec_iter_bvec((bio_vec), (iter))), 1); \
> > -bvec_iter_advance((bio_vec), &(iter), (bvl).bv_len))
> > + ((bvl = bvec_iter_bvec((bio_vec), (iter))), 1); \
> > + (bvl).bv_len ? bvec_iter_advance((bio_vec), &(iter), (bvl).bv_len) : \
> > + bvec_iter_skip_zero_vec((bio_vec), &(iter)))
>
> Uhm, bvec_iter_advance() already skips over zero length bio_vecs.
>
> while (bytes && bytes >= bv[idx].bv_len) {
> bytes -= bv[idx].bv_len;
> idx++;
> }
The issue is that zero (bvl).bv_len passed to bvec_iter_advance(), so
the iterator can't move on.
And I tried to avoid change to bvec_iter_advance() since this exact
issue only exists on for_each_bvec, and block layer won't support/allow
zero-length bvec.
>
> The problem is when the _first_ bio_vec is zero length.
It can be any zero-length bvec during the iterating.
> Maybe something more
> like this (which doesn't even compile, but hopefully makes my point):
>
> @@ -86,12 +86,24 @@ struct bvec_iter_all {
> (mp_bvec_iter_page((bvec), (iter)) +\
> mp_bvec_iter_page_idx((bvec), (iter)))
>
> -#define bvec_iter_bvec(bvec, iter) \
> -((struct bio_vec) {\
> - .bv_page= bvec_iter_page((bvec), (iter)), \
> - .bv_len = bvec_iter_len((bvec), (iter)),\
> - .bv_offset = bvec_iter_offset((bvec), (iter)), \
> -})
> +static inline bool bvec_iter_bvec(struct bio_vec *bv, struct bio_vec *bvec,
> + struct bvec_iter *iter)
> +{
> + unsigned int idx = iter->bi_idx;
> +
> + if (!iter->bi_size)
> + return false;
> +
> + while (!bv[idx].bv_len)
> + idx++;
> + iter->bi_idx = idx;
> +
> + bv->bv_page = bvec_iter_page(bvec, *iter);
> + bv->bv_len = bvec_iter_len(bvec, *iter);
> + bv->bv_offset = bvec_iter_offset(bvec, *iter);
> +
> + return true;
> +}
>
> static inline bool bvec_iter_advance(const struct bio_vec *bv,
> struct bvec_iter *iter, unsigned bytes)
> @@ -119,8 +131,7 @@ static inline bool bvec_iter_advance(const struct bio_vec
> *bv,
>
> #define for_each_bvec(bvl, bio_vec, iter, start) \
> for (iter = (start);\
> -(iter).bi_size && \
> - ((bvl = bvec_iter_bvec((bio_vec), (iter))), 1); \
> +bvec_iter_bvec(&(bvl), (bio_vec), &(iter));\
> bvec_iter_advance((bio_vec), &(iter), (bvl).bv_len))
>
> /* for iterating one bio from start to end */
>
> (I find the whole bvec handling a mess of confusing macros and would
> welcome more of it being inline functions, in general).
The above change may bring more code duplication. Meantime, it can't
work because (bvl).bv_len isn't taken into account into bvec_iter_bvec(),
then how can the iterator advance?
Thanks,
Ming
Re: [PATCH v3 3/7] x86/xen: drop tests for highmem in pv code
On 8/7/20 4:38 AM, Juergen Gross wrote:
> With support for 32-bit pv guests gone pure pv-code no longer needs to
> test for highmem. Dropping those tests removes the need for flushing
> in some places.
>
> Signed-off-by: Juergen Gross
Reviewed-by: Boris Ostrovsky
with a suggestion
> ---
> arch/x86/xen/enlighten_pv.c | 11 ++-
> arch/x86/xen/mmu_pv.c | 138 ++--
> 2 files changed, 57 insertions(+), 92 deletions(-)
>
> diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
> index 7d90b3da8bb4..9fec952f84f3 100644
> --- a/arch/x86/xen/enlighten_pv.c
> +++ b/arch/x86/xen/enlighten_pv.c
> @@ -347,6 +347,7 @@ static void set_aliased_prot(void *v, pgprot_t prot)
> unsigned long pfn;
> struct page *page;
> unsigned char dummy;
> + void *av;
to rename this to va since you are modifying those lines anyway.
>
> ptep = lookup_address((unsigned long)v, );
> BUG_ON(ptep == NULL);
> @@ -383,14 +384,10 @@ static void set_aliased_prot(void *v, pgprot_t prot)
> if (HYPERVISOR_update_va_mapping((unsigned long)v, pte, 0))
> BUG();
>
> - if (!PageHighMem(page)) {
> - void *av = __va(PFN_PHYS(pfn));
> + av = __va(PFN_PHYS(pfn));
>
[PATCH] arm64: dts: allwinner: Mark timer as stopped in suspend
When possible, system firmware on 64-bit Allwinner platforms disables
OSC24M during system suspend. Since this oscillator is the clock source
for the ARM architectural timer, this causes the timer to stop counting.
Therefore, the ARM architectural timer must not be marked as NONSTOP on
these platforms, or the time will be wrong after system resume.
Adding the arm,no-tick-in-suspend property forces the kernel to ignore
the ARM architectural timer when calculating sleeptime; it falls back to
reading the RTC. Note that this only affects deep suspend, not s2idle.
Signed-off-by: Samuel Holland
---
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 1 +
arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi | 1 +
arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 1 +
3 files changed, 3 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index 8dfbcd144072..5d19cf6f6d4f 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -157,6 +157,7 @@ link_codec: simple-audio-card,codec {
timer {
compatible = "arm,armv8-timer";
allwinner,erratum-unknown1;
+ arm,no-tick-in-suspend;
interrupts = ,
,
,
[PATCH] net/failover: remove redundant fops null check
Remove redundant fops null check
Fixes: 30c8bd5aa8b2c ("net: Introduce generic failover module")
Signed-off-by: Gaurav Singh
---
net/core/failover.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/core/failover.c b/net/core/failover.c
index b5cd3c727285..63213347f51c 100644
--- a/net/core/failover.c
+++ b/net/core/failover.c
@@ -82,7 +82,7 @@ static int failover_slave_register(struct net_device
*slave_dev)
slave_dev->priv_flags |= (IFF_FAILOVER_SLAVE | IFF_LIVE_RENAME_OK);
- if (fops && fops->slave_register &&
+ if (fops->slave_register &&
!fops->slave_register(slave_dev, failover_dev))
return NOTIFY_OK;
--
2.17.1
Re: [PATCH v3 2/7] x86/xen: eliminate xen-asm_64.S
On 8/7/20 4:38 AM, Juergen Gross wrote: > With 32-bit pv-guest support removed xen-asm_64.S can be merged with > xen-asm.S > > Signed-off-by: Juergen Gross Reviewed-by: Boris Ostrovsky except for > diff --git a/arch/x86/xen/xen-asm.S b/arch/x86/xen/xen-asm.S > index c59d077510bf..d1272a63f097 100644 > --- a/arch/x86/xen/xen-asm.S > +++ b/arch/x86/xen/xen-asm.S > @@ -6,12 +6,19 @@ > * operations here; the indirect forms are better handled in C. > */ > > +#include > #include > #include > #include > +#include > +#include > +#include > #include > #include asm/asm.h included twice now.
Re: [PATCH v3 1/7] x86/xen: remove 32-bit Xen PV guest support
On 8/7/20 4:38 AM, Juergen Gross wrote:
>
> void __init xen_reserve_top(void)
> {
> -#ifdef CONFIG_X86_32
> - unsigned long top = HYPERVISOR_VIRT_START;
> - struct xen_platform_parameters pp;
> -
> - if (HYPERVISOR_xen_version(XENVER_platform_parameters, ) == 0)
> - top = pp.virt_start;
> -
> - reserve_top_address(-top);
> -#endif /* CONFIG_X86_32 */
> }
>
We should be able now to get rid of xen_reserve_top() altogether.
Other than that
Reviewed-by: Boris Ostrovsky
-boris
Re: [PATCH for-fixes] MIPS: Loongson64: Do not override watch and ejtag feature
Reviewed-by: Huacai Chen On Sat, Aug 8, 2020 at 8:33 PM Jiaxun Yang wrote: > > Do not override ejtag feature to 0 as Loongson 3A1000+ do have ejtag. > For watch, as KVM emulated CPU doesn't have watch feature, we should > not enable it unconditionally. > > Signed-off-by: Jiaxun Yang > --- > This patch should go into mips-fixes tree as watch feature is blocking > KVM guest boot in some cases. > --- > arch/mips/include/asm/mach-loongson64/cpu-feature-overrides.h | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/arch/mips/include/asm/mach-loongson64/cpu-feature-overrides.h > b/arch/mips/include/asm/mach-loongson64/cpu-feature-overrides.h > index b6e9c99b85a5..eb181224eb4c 100644 > --- a/arch/mips/include/asm/mach-loongson64/cpu-feature-overrides.h > +++ b/arch/mips/include/asm/mach-loongson64/cpu-feature-overrides.h > @@ -26,7 +26,6 @@ > #define cpu_has_counter1 > #define cpu_has_dc_aliases (PAGE_SIZE < 0x4000) > #define cpu_has_divec 0 > -#define cpu_has_ejtag 0 > #define cpu_has_inclusive_pcaches 1 > #define cpu_has_llsc 1 > #define cpu_has_mcheck 0 > @@ -42,7 +41,6 @@ > #define cpu_has_veic 0 > #define cpu_has_vint 0 > #define cpu_has_vtag_icache0 > -#define cpu_has_watch 1 > #define cpu_has_wsbh 1 > #define cpu_has_ic_fills_f_dc 1 > #define cpu_hwrena_impl_bits 0xc000 > -- > 2.28.0.rc1 >
Re: [RESEND v7, PATCH 1/7] dt-bindings: mediatek: add rdma_fifo_size description for mt8183 display
Hi, Yongqiang:
Chun-Kuang Hu 於 2020年8月9日 週日 上午8:56寫道：
>
> Hi, Yongqiang:
>
> Yongqiang Niu 於 2020年8月8日 週六 上午11:04寫道：
> >
> > rdma fifo size may be different even in same SOC, add this
> > property to the corresponding rdma
> >
> > Change-Id: I67635ec7f3f59cf4cbc7737285e5e28ff0ab71c9
>
> Remove change-id.
>
> > Signed-off-by: Yongqiang Niu
> > ---
> > .../devicetree/bindings/display/mediatek/mediatek,disp.txt | 14
> > ++
> > 1 file changed, 14 insertions(+)
> >
> > diff --git
> > a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
> > b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
> > index b91e709..e6bbe32 100644
> > --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
> > +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
> > @@ -66,6 +66,11 @@ Required properties (DMA function blocks):
> >argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
> >for details.
> >
> > +Optional properties (RDMA function blocks):
> > +- mediatek,rdma_fifo_size: rdma fifo size may be different even in same
> > SOC, add this
> > + property to the corresponding rdma
> > + the value is the Max value which defined in hardware data sheet.
> > +
> > Examples:
> >
> > mmsys: clock-controller@1400 {
> > @@ -207,3 +212,12 @@ od@14023000 {
> > power-domains = < MT8173_POWER_DOMAIN_MM>;
> > clocks = < CLK_MM_DISP_OD>;
> > };
> > +
> > +rdma1: rdma@1400c000 {
> > + compatible = "mediatek,mt8183-disp-rdma";
> > + reg = <0 0x1400c000 0 0x1000>;
> > + interrupts = ;
> > + power-domains = < MT8183_POWER_DOMAIN_DISP>;
> > + clocks = < CLK_MM_DISP_RDMA1>;
> > + mediatek,rdma_fifo_size = <2048>;
> > +};
>
> I would like you to show rdma0 as well so that could prove two rdma
> have different fifo size in the same SoC.
Sorry, rdma0 is already define in this file. Just ignore this comment.
Regards,
Chun-Kuang.
>
> Regards,
> Chun-Kuang.
>
> > --
> > 1.8.1.1.dirty
> > ___
> > Linux-mediatek mailing list
> > linux-media...@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-mediatek
include/linux/mm.h:1734:21: sparse: sparse: context imbalance in 'gmap_make_secure' - different lock contexts for basic block
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 06a81c1c7db9bd5de0bd38cd5acc44bb22b99150
commit: 214d9bbcd3a67230b932f6cea83c078ab34d9e70 s390/mm: provide memory
management functions for protected KVM guests
date: 5 months ago
config: s390-randconfig-s032-20200809 (attached as .config)
compiler: s390-linux-gcc (GCC) 9.3.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# apt-get install sparse
# sparse version: v0.6.2-118-ge1578773-dirty
git checkout 214d9bbcd3a67230b932f6cea83c078ab34d9e70
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1
CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=s390
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
sparse warnings: (new ones prefixed by >>)
arch/s390/kernel/uv.c: note: in included file (through
include/linux/memblock.h):
>> include/linux/mm.h:1734:21: sparse: sparse: context imbalance in
>> 'gmap_make_secure' - different lock contexts for basic block
vim +/gmap_make_secure +1734 include/linux/mm.h
d08b3851da41d0e Peter Zijlstra 2006-09-25 1731
25ca1d6c02fe1c6 Namhyung Kim 2010-10-26 1732 extern pte_t
*__get_locked_pte(struct mm_struct *mm, unsigned long addr,
25ca1d6c02fe1c6 Namhyung Kim 2010-10-26 1733
spinlock_t **ptl);
25ca1d6c02fe1c6 Namhyung Kim 2010-10-26 @1734 static inline pte_t
*get_locked_pte(struct mm_struct *mm, unsigned long addr,
25ca1d6c02fe1c6 Namhyung Kim 2010-10-26 1735
spinlock_t **ptl)
25ca1d6c02fe1c6 Namhyung Kim 2010-10-26 1736 {
25ca1d6c02fe1c6 Namhyung Kim 2010-10-26 1737 pte_t *ptep;
25ca1d6c02fe1c6 Namhyung Kim 2010-10-26 1738 __cond_lock(*ptl, ptep
= __get_locked_pte(mm, addr, ptl));
25ca1d6c02fe1c6 Namhyung Kim 2010-10-26 1739 return ptep;
25ca1d6c02fe1c6 Namhyung Kim 2010-10-26 1740 }
c9cfcddfd657354 Linus Torvalds 2005-11-29 1741
:: The code at line 1734 was first introduced by commit
:: 25ca1d6c02fe1c6d90d918867ef670d323725458 mm: wrap get_locked_pte() using
__cond_lock()
:: TO: Namhyung Kim
:: CC: Linus Torvalds
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
drivers/tty/serial/ucc_uart.c:661:9: sparse: sparse: incorrect type in argument 2 (different address spaces)
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 06a81c1c7db9bd5de0bd38cd5acc44bb22b99150 commit: 670d0a4b10704667765f7d18f7592993d02783aa sparse: use identifiers to define address spaces date: 7 weeks ago config: arm64-randconfig-s032-20200809 (attached as .config) compiler: aarch64-linux-gcc (GCC) 9.3.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # apt-get install sparse # sparse version: v0.6.2-118-ge1578773-dirty git checkout 670d0a4b10704667765f7d18f7592993d02783aa # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=arm64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot sparse warnings: (new ones prefixed by >>) drivers/tty/serial/ucc_uart.c:264:21: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void const volatile [noderef] __iomem *addr @@ got restricted __be16 * @@ drivers/tty/serial/ucc_uart.c:264:21: sparse: expected void const volatile [noderef] __iomem *addr drivers/tty/serial/ucc_uart.c:264:21: sparse: got restricted __be16 * drivers/tty/serial/ucc_uart.c:268:21: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void const volatile [noderef] __iomem *addr @@ got restricted __be16 * @@ drivers/tty/serial/ucc_uart.c:268:21: sparse: expected void const volatile [noderef] __iomem *addr drivers/tty/serial/ucc_uart.c:268:21: sparse: got restricted __be16 * drivers/tty/serial/ucc_uart.c:286:6: sparse: sparse: symbol 'qe_uart_set_mctrl' was not declared. Should it be static? drivers/tty/serial/ucc_uart.c:347:17: sparse: sparse: incorrect type in argument 2 (different address spaces) @@ expected void volatile [noderef] __iomem *addr @@ got restricted __be16 * @@ drivers/tty/serial/ucc_uart.c:347:17: sparse: expected void volatile [noderef] __iomem *addr drivers/tty/serial/ucc_uart.c:347:17: sparse: got restricted __be16 * drivers/tty/serial/ucc_uart.c:348:17: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void const volatile [noderef] __iomem *addr @@ got restricted __be16 * @@ drivers/tty/serial/ucc_uart.c:348:17: sparse: expected void const volatile [noderef] __iomem *addr drivers/tty/serial/ucc_uart.c:348:17: sparse: got restricted __be16 * drivers/tty/serial/ucc_uart.c:348:17: sparse: sparse: incorrect type in argument 2 (different address spaces) @@ expected void volatile [noderef] __iomem *addr @@ got restricted __be16 * @@ drivers/tty/serial/ucc_uart.c:348:17: sparse: expected void volatile [noderef] __iomem *addr drivers/tty/serial/ucc_uart.c:348:17: sparse: got restricted __be16 * drivers/tty/serial/ucc_uart.c:350:21: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void const volatile [noderef] __iomem *addr @@ got restricted __be16 * @@ drivers/tty/serial/ucc_uart.c:350:21: sparse: expected void const volatile [noderef] __iomem *addr drivers/tty/serial/ucc_uart.c:350:21: sparse: got restricted __be16 * drivers/tty/serial/ucc_uart.c:369:18: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void const volatile [noderef] __iomem *addr @@ got restricted __be16 * @@ drivers/tty/serial/ucc_uart.c:369:18: sparse: expected void const volatile [noderef] __iomem *addr drivers/tty/serial/ucc_uart.c:369:18: sparse: got restricted __be16 * drivers/tty/serial/ucc_uart.c:382:17: sparse: sparse: incorrect type in argument 2 (different address spaces) @@ expected void volatile [noderef] __iomem *addr @@ got restricted __be16 * @@ drivers/tty/serial/ucc_uart.c:382:17: sparse: expected void volatile [noderef] __iomem *addr drivers/tty/serial/ucc_uart.c:382:17: sparse: got restricted __be16 * drivers/tty/serial/ucc_uart.c:383:17: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void const volatile [noderef] __iomem *addr @@ got restricted __be16 * @@ drivers/tty/serial/ucc_uart.c:383:17: sparse: expected void const volatile [noderef] __iomem *addr drivers/tty/serial/ucc_uart.c:383:17: sparse: got restricted __be16 * drivers/tty/serial/ucc_uart.c:383:17: sparse: sparse: incorrect type in argument 2 (different address spaces) @@ expected void volatile [noderef] __iomem *addr @@ got restricted __be16 * @@ drivers/tty/serial/ucc_uart.c:383:17: sparse: expected void volatile [noderef] __iomem *addr drivers/tty/serial/ucc_uart.c:383:17: sparse: got restricted __be16 *
Re: [RESEND v7, PATCH 1/7] dt-bindings: mediatek: add rdma_fifo_size description for mt8183 display
Hi, Yongqiang:
Yongqiang Niu 於 2020年8月8日 週六 上午11:04寫道：
>
> rdma fifo size may be different even in same SOC, add this
> property to the corresponding rdma
>
> Change-Id: I67635ec7f3f59cf4cbc7737285e5e28ff0ab71c9
Remove change-id.
> Signed-off-by: Yongqiang Niu
> ---
> .../devicetree/bindings/display/mediatek/mediatek,disp.txt | 14
> ++
> 1 file changed, 14 insertions(+)
>
> diff --git
> a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
> b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
> index b91e709..e6bbe32 100644
> --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
> +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
> @@ -66,6 +66,11 @@ Required properties (DMA function blocks):
>argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
>for details.
>
> +Optional properties (RDMA function blocks):
> +- mediatek,rdma_fifo_size: rdma fifo size may be different even in same SOC,
> add this
> + property to the corresponding rdma
> + the value is the Max value which defined in hardware data sheet.
> +
> Examples:
>
> mmsys: clock-controller@1400 {
> @@ -207,3 +212,12 @@ od@14023000 {
> power-domains = < MT8173_POWER_DOMAIN_MM>;
> clocks = < CLK_MM_DISP_OD>;
> };
> +
> +rdma1: rdma@1400c000 {
> + compatible = "mediatek,mt8183-disp-rdma";
> + reg = <0 0x1400c000 0 0x1000>;
> + interrupts = ;
> + power-domains = < MT8183_POWER_DOMAIN_DISP>;
> + clocks = < CLK_MM_DISP_RDMA1>;
> + mediatek,rdma_fifo_size = <2048>;
> +};
I would like you to show rdma0 as well so that could prove two rdma
have different fifo size in the same SoC.
Regards,
Chun-Kuang.
> --
> 1.8.1.1.dirty
> ___
> Linux-mediatek mailing list
> linux-media...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
drivers/gpu/drm/armada/armada_fbdev.c:85:27: sparse: got void Documentation Kbuild Kconfig Makefile certs drivers fs include samples scripts sound tools ptr
Hi Stephen,
First bad commit (maybe != root cause):
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 06a81c1c7db9bd5de0bd38cd5acc44bb22b99150
commit: bbd7ffdbef6888459f301c5889f3b14ada38b913 clk: Allow the common clk
framework to be selectable
date: 3 months ago
config: arm-randconfig-s031-20200809 (attached as .config)
compiler: arm-linux-gnueabi-gcc (GCC) 9.3.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# apt-get install sparse
# sparse version: v0.6.2-118-ge1578773-dirty
git checkout bbd7ffdbef6888459f301c5889f3b14ada38b913
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1
CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=arm
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
sparse warnings: (new ones prefixed by >>)
drivers/gpu/drm/armada/armada_fbdev.c:85:27: sparse: sparse: incorrect type
in assignment (different address spaces) @@ expected char [noderef]
*screen_base @@ got void *[assigned] ptr @@
drivers/gpu/drm/armada/armada_fbdev.c:85:27: sparse: expected char
[noderef] *screen_base
>> drivers/gpu/drm/armada/armada_fbdev.c:85:27: sparse: got void
>> *[assigned] ptr
--
drivers/gpu/drm/armada/armada_gem.c:61:37: sparse: sparse: incorrect type in
argument 1 (different address spaces) @@ expected void volatile [noderef]
*iomem_cookie @@ got void *addr @@
drivers/gpu/drm/armada/armada_gem.c:61:37: sparse: expected void
volatile [noderef] *iomem_cookie
>> drivers/gpu/drm/armada/armada_gem.c:61:37: sparse: got void *addr
drivers/gpu/drm/armada/armada_gem.c:183:28: sparse: sparse: incorrect type
in assignment (different address spaces) @@ expected void *addr @@ got
void [noderef] * @@
>> drivers/gpu/drm/armada/armada_gem.c:183:28: sparse: expected void *addr
drivers/gpu/drm/armada/armada_gem.c:183:28: sparse: got void [noderef]
*
--
>> drivers/gpu/drm/armada/armada_overlay.c:328:24: sparse: sparse: symbol
>> 'armada_overlay_duplicate_state' was not declared. Should it be static?
vim +85 drivers/gpu/drm/armada/armada_fbdev.c
96f60e37dc6609 Russell King2012-08-15 26
3382a6b999415d Russell King2018-07-30 27 static int
armada_fbdev_create(struct drm_fb_helper *fbh,
96f60e37dc6609 Russell King2012-08-15 28 struct
drm_fb_helper_surface_size *sizes)
96f60e37dc6609 Russell King2012-08-15 29 {
96f60e37dc6609 Russell King2012-08-15 30 struct drm_device *dev
= fbh->dev;
96f60e37dc6609 Russell King2012-08-15 31 struct drm_mode_fb_cmd2
mode;
96f60e37dc6609 Russell King2012-08-15 32 struct
armada_framebuffer *dfb;
96f60e37dc6609 Russell King2012-08-15 33 struct
armada_gem_object *obj;
96f60e37dc6609 Russell King2012-08-15 34 struct fb_info *info;
96f60e37dc6609 Russell King2012-08-15 35 int size, ret;
96f60e37dc6609 Russell King2012-08-15 36 void *ptr;
96f60e37dc6609 Russell King2012-08-15 37
96f60e37dc6609 Russell King2012-08-15 38 memset(, 0,
sizeof(mode));
96f60e37dc6609 Russell King2012-08-15 39 mode.width =
sizes->surface_width;
96f60e37dc6609 Russell King2012-08-15 40 mode.height =
sizes->surface_height;
96f60e37dc6609 Russell King2012-08-15 41 mode.pitches[0] =
armada_pitch(mode.width, sizes->surface_bpp);
96f60e37dc6609 Russell King2012-08-15 42 mode.pixel_format =
drm_mode_legacy_fb_format(sizes->surface_bpp,
96f60e37dc6609 Russell King2012-08-15 43
sizes->surface_depth);
96f60e37dc6609 Russell King2012-08-15 44
96f60e37dc6609 Russell King2012-08-15 45 size = mode.pitches[0]
* mode.height;
96f60e37dc6609 Russell King2012-08-15 46 obj =
armada_gem_alloc_private_object(dev, size);
96f60e37dc6609 Russell King2012-08-15 47 if (!obj) {
96f60e37dc6609 Russell King2012-08-15 48
DRM_ERROR("failed to allocate fb memory\n");
96f60e37dc6609 Russell King2012-08-15 49 return -ENOMEM;
96f60e37dc6609 Russell King2012-08-15 50 }
96f60e37dc6609 Russell King2012-08-15 51
96f60e37dc6609 Russell King2012-08-15 52 ret =
armada_gem_linear_back(dev, obj);
96f60e37dc6609 Russell King2012-08-15 53 if (ret) {
4c3cf375bc4042 Haneen Mohammed 2017-09-20 54
drm_gem_object_put_unlocked(>obj);
96f60e37dc6609 Russell King2012-08-15 55 return ret;
96f60e37dc6609 Russell King2012-08-15 56 }
96f60e37dc6609 Russell King2012-08-15 57
96f60e37dc6609 Russell King
Re: [RESEND v7, PATCH 2/7] drm/mediatek: move ddp component define into mtk_mmsys.h
Yongqiang Niu 於 2020年8月8日 週六 上午11:05寫道：
>
> mmsys is the driver which control the routing of these ddp component,
> so the definition of mtk_ddp_comp_id should be placed in mtk-mmsys.h
>
Reviewed-by: Chun-Kuang Hu
> Signed-off-by: Yongqiang Niu
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 34
> +
> drivers/soc/mediatek/mtk-mmsys.c| 4 +---
> include/linux/soc/mediatek/mtk-mmsys.h | 33
> 3 files changed, 35 insertions(+), 36 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> index debe363..161201f 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> @@ -7,6 +7,7 @@
> #define MTK_DRM_DDP_COMP_H
>
> #include
> +#include
>
> struct device;
> struct device_node;
> @@ -35,39 +36,6 @@ enum mtk_ddp_comp_type {
> MTK_DDP_COMP_TYPE_MAX,
> };
>
> -enum mtk_ddp_comp_id {
> - DDP_COMPONENT_AAL0,
> - DDP_COMPONENT_AAL1,
> - DDP_COMPONENT_BLS,
> - DDP_COMPONENT_CCORR,
> - DDP_COMPONENT_COLOR0,
> - DDP_COMPONENT_COLOR1,
> - DDP_COMPONENT_DITHER,
> - DDP_COMPONENT_DPI0,
> - DDP_COMPONENT_DPI1,
> - DDP_COMPONENT_DSI0,
> - DDP_COMPONENT_DSI1,
> - DDP_COMPONENT_DSI2,
> - DDP_COMPONENT_DSI3,
> - DDP_COMPONENT_GAMMA,
> - DDP_COMPONENT_OD0,
> - DDP_COMPONENT_OD1,
> - DDP_COMPONENT_OVL0,
> - DDP_COMPONENT_OVL_2L0,
> - DDP_COMPONENT_OVL_2L1,
> - DDP_COMPONENT_OVL1,
> - DDP_COMPONENT_PWM0,
> - DDP_COMPONENT_PWM1,
> - DDP_COMPONENT_PWM2,
> - DDP_COMPONENT_RDMA0,
> - DDP_COMPONENT_RDMA1,
> - DDP_COMPONENT_RDMA2,
> - DDP_COMPONENT_UFOE,
> - DDP_COMPONENT_WDMA0,
> - DDP_COMPONENT_WDMA1,
> - DDP_COMPONENT_ID_MAX,
> -};
> -
> struct mtk_ddp_comp;
> struct cmdq_pkt;
> struct mtk_ddp_comp_funcs {
> diff --git a/drivers/soc/mediatek/mtk-mmsys.c
> b/drivers/soc/mediatek/mtk-mmsys.c
> index a55f255..36ad66b 100644
> --- a/drivers/soc/mediatek/mtk-mmsys.c
> +++ b/drivers/soc/mediatek/mtk-mmsys.c
> @@ -5,13 +5,11 @@
> */
>
> #include
> +#include
> #include
> #include
> #include
>
> -#include "../../gpu/drm/mediatek/mtk_drm_ddp.h"
> -#include "../../gpu/drm/mediatek/mtk_drm_ddp_comp.h"
> -
> #define DISP_REG_CONFIG_DISP_OVL0_MOUT_EN 0x040
> #define DISP_REG_CONFIG_DISP_OVL1_MOUT_EN 0x044
> #define DISP_REG_CONFIG_DISP_OD_MOUT_EN0x048
> diff --git a/include/linux/soc/mediatek/mtk-mmsys.h
> b/include/linux/soc/mediatek/mtk-mmsys.h
> index 7bab5d9..2228bf6 100644
> --- a/include/linux/soc/mediatek/mtk-mmsys.h
> +++ b/include/linux/soc/mediatek/mtk-mmsys.h
> @@ -9,6 +9,39 @@
> enum mtk_ddp_comp_id;
> struct device;
>
> +enum mtk_ddp_comp_id {
> + DDP_COMPONENT_AAL0,
> + DDP_COMPONENT_AAL1,
> + DDP_COMPONENT_BLS,
> + DDP_COMPONENT_CCORR,
> + DDP_COMPONENT_COLOR0,
> + DDP_COMPONENT_COLOR1,
> + DDP_COMPONENT_DITHER,
> + DDP_COMPONENT_DPI0,
> + DDP_COMPONENT_DPI1,
> + DDP_COMPONENT_DSI0,
> + DDP_COMPONENT_DSI1,
> + DDP_COMPONENT_DSI2,
> + DDP_COMPONENT_DSI3,
> + DDP_COMPONENT_GAMMA,
> + DDP_COMPONENT_OD0,
> + DDP_COMPONENT_OD1,
> + DDP_COMPONENT_OVL0,
> + DDP_COMPONENT_OVL_2L0,
> + DDP_COMPONENT_OVL_2L1,
> + DDP_COMPONENT_OVL1,
> + DDP_COMPONENT_PWM0,
> + DDP_COMPONENT_PWM1,
> + DDP_COMPONENT_PWM2,
> + DDP_COMPONENT_RDMA0,
> + DDP_COMPONENT_RDMA1,
> + DDP_COMPONENT_RDMA2,
> + DDP_COMPONENT_UFOE,
> + DDP_COMPONENT_WDMA0,
> + DDP_COMPONENT_WDMA1,
> + DDP_COMPONENT_ID_MAX,
> +};
> +
> void mtk_mmsys_ddp_connect(struct device *dev,
>enum mtk_ddp_comp_id cur,
>enum mtk_ddp_comp_id next);
> --
> 1.8.1.1.dirty
> ___
> Linux-mediatek mailing list
> linux-media...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
Re: linux-next: build failure after merge of the thunderbolt tree
On Tue, Jun 30, 2020 at 02:33:02PM +0300, Mika Westerberg wrote:
> On Tue, Jun 30, 2020 at 04:03:46PM +1000, Stephen Rothwell wrote:
> > Hi all,
> >
> > After merging the thunderbolt tree, today's linux-next build (powerpc
> > allyesconfig) failed like this:
> >
> >
> > Caused by commit
> >
> > 54509f5005ca ("thunderbolt: Add KUnit tests for path walking")
> >
> > interacting with commit
> >
> > d4cdd146d0db ("kunit: generalize kunit_resource API beyond allocated
> > resources")
> >
> > from the kunit-next tree.
>
> Thanks for reporting and fixing. The fix looks good to me.
Unfortunately, the fix didn't make it into mainline.
Building x86_64:allyesconfig ... failed
--
Error log:
drivers/thunderbolt/test.c: In function '__ida_init':
drivers/thunderbolt/test.c:20:5: error: 'struct kunit_resource' has no member
named 'allocation'
20 | res->allocation = ida;
| ^~
drivers/thunderbolt/test.c: In function '__ida_destroy':
drivers/thunderbolt/test.c:26:23: error: 'struct kunit_resource' has no member
named 'allocation'
26 | struct ida *ida = res->allocation;
| ^~
make[3]: *** [drivers/thunderbolt/test.o] Error 1
Guenter
[PATCH v3 1/3] scsi: 3w-9xxx: Use flexible array members to avoid struct padding
In preparation for removing the "#pragma pack(1)" from the driver, fix
all instances where a trailing array member could be replaced by a
flexible array member. Since a flexible array member has zero size, it
introduces no padding, whether or not the struct is packed.
Signed-off-by: Samuel Holland
---
drivers/scsi/3w-9xxx.c | 12 ++--
drivers/scsi/3w-9xxx.h | 4 ++--
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/scsi/3w-9xxx.c b/drivers/scsi/3w-9xxx.c
index 3337b1e80412..ec7859f071ac 100644
--- a/drivers/scsi/3w-9xxx.c
+++ b/drivers/scsi/3w-9xxx.c
@@ -676,7 +676,7 @@ static long twa_chrdev_ioctl(struct file *file, unsigned
int cmd, unsigned long
data_buffer_length_adjusted = (driver_command.buffer_length + 511) &
~511;
/* Now allocate ioctl buf memory */
- cpu_addr = dma_alloc_coherent(_dev->tw_pci_dev->dev,
data_buffer_length_adjusted+sizeof(TW_Ioctl_Buf_Apache) - 1, _handle,
GFP_KERNEL);
+ cpu_addr = dma_alloc_coherent(_dev->tw_pci_dev->dev,
data_buffer_length_adjusted + sizeof(TW_Ioctl_Buf_Apache), _handle,
GFP_KERNEL);
if (!cpu_addr) {
retval = TW_IOCTL_ERROR_OS_ENOMEM;
goto out2;
@@ -685,7 +685,7 @@ static long twa_chrdev_ioctl(struct file *file, unsigned
int cmd, unsigned long
tw_ioctl = (TW_Ioctl_Buf_Apache *)cpu_addr;
/* Now copy down the entire ioctl */
- if (copy_from_user(tw_ioctl, argp, driver_command.buffer_length +
sizeof(TW_Ioctl_Buf_Apache) - 1))
+ if (copy_from_user(tw_ioctl, argp, driver_command.buffer_length +
sizeof(TW_Ioctl_Buf_Apache)))
goto out3;
/* See which ioctl we are doing */
@@ -867,11 +867,11 @@ static long twa_chrdev_ioctl(struct file *file, unsigned
int cmd, unsigned long
}
/* Now copy the entire response to userspace */
- if (copy_to_user(argp, tw_ioctl, sizeof(TW_Ioctl_Buf_Apache) +
driver_command.buffer_length - 1) == 0)
+ if (copy_to_user(argp, tw_ioctl, sizeof(TW_Ioctl_Buf_Apache) +
driver_command.buffer_length) == 0)
retval = 0;
out3:
/* Now free ioctl buf memory */
- dma_free_coherent(_dev->tw_pci_dev->dev,
data_buffer_length_adjusted+sizeof(TW_Ioctl_Buf_Apache) - 1, cpu_addr,
dma_handle);
+ dma_free_coherent(_dev->tw_pci_dev->dev, data_buffer_length_adjusted
+ sizeof(TW_Ioctl_Buf_Apache), cpu_addr, dma_handle);
out2:
mutex_unlock(_dev->ioctl_lock);
out:
@@ -1392,7 +1392,7 @@ static void twa_load_sgl(TW_Device_Extension *tw_dev,
TW_Command_Full *full_comm
newcommand->request_id__lunl =
cpu_to_le16(TW_REQ_LUN_IN(TW_LUN_OUT(newcommand->request_id__lunl),
request_id));
if (length) {
- newcommand->sg_list[0].address =
TW_CPU_TO_SGL(dma_handle + sizeof(TW_Ioctl_Buf_Apache) - 1);
+ newcommand->sg_list[0].address =
TW_CPU_TO_SGL(dma_handle + sizeof(TW_Ioctl_Buf_Apache));
newcommand->sg_list[0].length = cpu_to_le32(length);
}
newcommand->sgl_entries__lunh =
@@ -1407,7 +1407,7 @@ static void twa_load_sgl(TW_Device_Extension *tw_dev,
TW_Command_Full *full_comm
sgl = (TW_SG_Entry *)((u32
*)oldcommand+oldcommand->size - (sizeof(TW_SG_Entry)/4) + pae);
else
sgl = (TW_SG_Entry *)((u32
*)oldcommand+TW_SGL_OUT(oldcommand->opcode__sgloffset));
- sgl->address = TW_CPU_TO_SGL(dma_handle +
sizeof(TW_Ioctl_Buf_Apache) - 1);
+ sgl->address = TW_CPU_TO_SGL(dma_handle +
sizeof(TW_Ioctl_Buf_Apache));
sgl->length = cpu_to_le32(length);
oldcommand->size += pae;
diff --git a/drivers/scsi/3w-9xxx.h b/drivers/scsi/3w-9xxx.h
index d88cd3499bd5..e65dafda2e3e 100644
--- a/drivers/scsi/3w-9xxx.h
+++ b/drivers/scsi/3w-9xxx.h
@@ -588,7 +588,7 @@ typedef struct TAG_TW_Ioctl_Apache {
TW_Ioctl_Driver_Command driver_command;
char padding[488];
TW_Command_Full firmware_command;
- char data_buffer[1];
+ char data_buffer[];
} TW_Ioctl_Buf_Apache;
/* Lock structure for ioctl get/release lock */
@@ -604,7 +604,7 @@ typedef struct {
unsigned short parameter_id;
unsigned short parameter_size_bytes;
unsigned short actual_parameter_size_bytes;
- unsigned char data[1];
+ unsigned char data[];
} TW_Param_Apache, *PTW_Param_Apache;
/* Response queue */
--
2.26.2
drivers/crypto/sa2ul.c:1349:33: warning: cast from pointer to integer of different size
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 06a81c1c7db9bd5de0bd38cd5acc44bb22b99150
commit: 2dc53d0047458e28ed05b4548844ba78199857bf crypto: sa2ul - add
sha1/sha256/sha512 support
date: 2 weeks ago
config: m68k-randconfig-r002-20200809 (attached as .config)
compiler: m68k-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 2dc53d0047458e28ed05b4548844ba78199857bf
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=m68k
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
In file included from include/linux/err.h:5,
from include/linux/clk.h:12,
from drivers/crypto/sa2ul.c:11:
include/linux/scatterlist.h: In function 'sg_set_buf':
arch/m68k/include/asm/page_no.h:33:50: warning: ordered comparison of
pointer with null pointer [-Wextra]
33 | #define virt_addr_valid(kaddr) (((void *)(kaddr) >= (void
*)PAGE_OFFSET) && \
| ^~
include/linux/compiler.h:78:42: note: in definition of macro 'unlikely'
78 | # define unlikely(x) __builtin_expect(!!(x), 0)
| ^
include/linux/scatterlist.h:143:2: note: in expansion of macro 'BUG_ON'
143 | BUG_ON(!virt_addr_valid(buf));
| ^~
include/linux/scatterlist.h:143:10: note: in expansion of macro
'virt_addr_valid'
143 | BUG_ON(!virt_addr_valid(buf));
| ^~~
In file included from include/linux/device.h:15,
from include/linux/dmaengine.h:8,
from drivers/crypto/sa2ul.c:12:
drivers/crypto/sa2ul.c: In function 'sa_sha_init':
>> drivers/crypto/sa2ul.c:1349:33: warning: cast from pointer to integer of
>> different size [-Wpointer-to-int-cast]
1349 | crypto_ahash_digestsize(tfm), (u64)rctx);
| ^
include/linux/dev_printk.h:123:47: note: in definition of macro 'dev_dbg'
123 | dev_printk(KERN_DEBUG, dev, dev_fmt(fmt), ##__VA_ARGS__); \
| ^~~
vim +1349 drivers/crypto/sa2ul.c
1341
1342 static int sa_sha_init(struct ahash_request *req)
1343 {
1344 struct crypto_ahash *tfm = crypto_ahash_reqtfm(req);
1345 struct sa_sha_req_ctx *rctx = ahash_request_ctx(req);
1346 struct sa_tfm_ctx *ctx = crypto_ahash_ctx(tfm);
1347
1348 dev_dbg(sa_k3_dev, "init: digest size: %d, rctx=%llx\n",
> 1349 crypto_ahash_digestsize(tfm), (u64)rctx);
1350
1351 ahash_request_set_tfm(>fallback_req, ctx->fallback.ahash);
1352 rctx->fallback_req.base.flags =
1353 req->base.flags & CRYPTO_TFM_REQ_MAY_SLEEP;
1354
1355 return crypto_ahash_init(>fallback_req);
1356 }
1357
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
[PATCH v3 2/3] scsi: 3w-9xxx: Reduce scope of structure packing
Currently, all command packet structs used by this driver are packed.
However, only one (TW_SG_Entry) actually needs to be packed, because it
uses 64-bit addresses at 32-bit alignment. To improve the quality of
generated code, stop packing all of the other command packet structs.
This requires adjusting the type of one misaligned "reserved" member.
After this change, pahole reports that only one type had its layout
change: the tw_compat_info member of TW_Device_Extension is now
naturally aligned.
Signed-off-by: Samuel Holland
---
drivers/scsi/3w-9xxx.h | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/scsi/3w-9xxx.h b/drivers/scsi/3w-9xxx.h
index e65dafda2e3e..36b865eca67d 100644
--- a/drivers/scsi/3w-9xxx.h
+++ b/drivers/scsi/3w-9xxx.h
@@ -471,13 +471,17 @@ printk(KERN_WARNING "3w-9xxx: ERROR: (0x%02X:0x%04X):
%s.\n",a,b,c); \
#define TW_PADDING_LENGTH (sizeof(dma_addr_t) > 4 ? 8 : 0)
#define TW_CPU_TO_SGL(x) (sizeof(dma_addr_t) > 4 ? cpu_to_le64(x) :
cpu_to_le32(x))
-#pragma pack(1)
+#if IS_ENABLED(CONFIG_ARCH_DMA_ADDR_T_64BIT)
+typedef u64 twa_addr_t;
+#else
+typedef u32 twa_addr_t;
+#endif
/* Scatter Gather List Entry */
typedef struct TAG_TW_SG_Entry {
- dma_addr_t address;
+ twa_addr_t address;
u32 length;
-} TW_SG_Entry;
+} __packed TW_SG_Entry;
/* Command Packet */
typedef struct TW_Command {
@@ -496,12 +500,12 @@ typedef struct TW_Command {
struct {
u32 lba;
TW_SG_Entry sgl[TW_ESCALADE_MAX_SGL_LENGTH];
- dma_addr_t padding;
+ twa_addr_t padding;
} io;
struct {
TW_SG_Entry sgl[TW_ESCALADE_MAX_SGL_LENGTH];
u32 padding;
- dma_addr_t padding2;
+ twa_addr_t padding2;
} param;
} byte8_offset;
} TW_Command;
@@ -531,7 +535,7 @@ typedef struct TAG_TW_Command_Apache_Header {
unsigned char err_specific_desc[98];
struct {
unsigned char size_header;
- unsigned short reserved;
+ unsigned char reserved[2];
unsigned char size_sense;
} header_desc;
} TW_Command_Apache_Header;
@@ -631,8 +635,6 @@ typedef struct TAG_TW_Compatibility_Info
unsigned short fw_on_ctlr_build;
} TW_Compatibility_Info;
-#pragma pack()
-
typedef struct TAG_TW_Device_Extension {
u32 __iomem *base_addr;
unsigned long *generic_buffer_virt[TW_Q_LENGTH];
--
2.26.2
[PATCH v3 3/3] scsi: 3w-9xxx: Fix endianness issues in command packets
The controller expects all data it sends/receives to be little-endian.
Therefore, the packet struct definitions should use the __le16/32/64
types. Once those are correct, sparse reports several issues with the
driver code, which are fixed here as well.
The main issue observed was at the call to scsi_set_resid, where the
byteswapped parameter would eventually trigger the alignment check at
drivers/scsi/sd.c:2009. At that point, the kernel would continuously
complain about an "Unaligned partial completion", and no further I/O
could occur.
This gets the controller working on big endian powerpc64.
Signed-off-by: Samuel Holland
---
drivers/scsi/3w-9xxx.c | 56 ++---
drivers/scsi/3w-9xxx.h | 111 +
2 files changed, 81 insertions(+), 86 deletions(-)
diff --git a/drivers/scsi/3w-9xxx.c b/drivers/scsi/3w-9xxx.c
index ec7859f071ac..1eefec168a0a 100644
--- a/drivers/scsi/3w-9xxx.c
+++ b/drivers/scsi/3w-9xxx.c
@@ -303,10 +303,10 @@ static int twa_aen_drain_queue(TW_Device_Extension
*tw_dev, int no_check_reset)
/* Initialize sglist */
memset(, 0, sizeof(TW_SG_Entry));
- sglist[0].length = TW_SECTOR_SIZE;
- sglist[0].address = tw_dev->generic_buffer_phys[request_id];
+ sglist[0].length = cpu_to_le32(TW_SECTOR_SIZE);
+ sglist[0].address =
TW_CPU_TO_SGL(tw_dev->generic_buffer_phys[request_id]);
- if (sglist[0].address & TW_ALIGNMENT_9000_SGL) {
+ if (tw_dev->generic_buffer_phys[request_id] & TW_ALIGNMENT_9000_SGL) {
TW_PRINTK(tw_dev->host, TW_DRIVER, 0x1, "Found unaligned
address during AEN drain");
goto out;
}
@@ -440,8 +440,8 @@ static int twa_aen_read_queue(TW_Device_Extension *tw_dev,
int request_id)
/* Initialize sglist */
memset(, 0, sizeof(TW_SG_Entry));
- sglist[0].length = TW_SECTOR_SIZE;
- sglist[0].address = tw_dev->generic_buffer_phys[request_id];
+ sglist[0].length = cpu_to_le32(TW_SECTOR_SIZE);
+ sglist[0].address =
TW_CPU_TO_SGL(tw_dev->generic_buffer_phys[request_id]);
/* Mark internal command */
tw_dev->srb[request_id] = NULL;
@@ -501,9 +501,8 @@ static void twa_aen_sync_time(TW_Device_Extension *tw_dev,
int request_id)
Sunday 12:00AM */
local_time = (ktime_get_real_seconds() - (sys_tz.tz_minuteswest * 60));
div_u64_rem(local_time - (3 * 86400), 604800, );
- schedulertime = cpu_to_le32(schedulertime % 604800);
- memcpy(param->data, , sizeof(u32));
+ memcpy(param->data, &(__le32){cpu_to_le32(schedulertime)},
sizeof(__le32));
/* Mark internal command */
tw_dev->srb[request_id] = NULL;
@@ -1000,19 +999,13 @@ static int twa_fill_sense(TW_Device_Extension *tw_dev,
int request_id, int copy_
if (print_host)
printk(KERN_WARNING "3w-9xxx: scsi%d: ERROR:
(0x%02X:0x%04X): %s:%s.\n",
tw_dev->host->host_no,
- TW_MESSAGE_SOURCE_CONTROLLER_ERROR,
- full_command_packet->header.status_block.error,
- error_str[0] == '\0' ?
- twa_string_lookup(twa_error_table,
-
full_command_packet->header.status_block.error) : error_str,
+ TW_MESSAGE_SOURCE_CONTROLLER_ERROR, error,
+ error_str[0] ? error_str :
twa_string_lookup(twa_error_table, error),
full_command_packet->header.err_specific_desc);
else
printk(KERN_WARNING "3w-9xxx: ERROR: (0x%02X:0x%04X):
%s:%s.\n",
- TW_MESSAGE_SOURCE_CONTROLLER_ERROR,
- full_command_packet->header.status_block.error,
- error_str[0] == '\0' ?
- twa_string_lookup(twa_error_table,
-
full_command_packet->header.status_block.error) : error_str,
+ TW_MESSAGE_SOURCE_CONTROLLER_ERROR, error,
+ error_str[0] ? error_str :
twa_string_lookup(twa_error_table, error),
full_command_packet->header.err_specific_desc);
}
@@ -1129,12 +1122,11 @@ static int twa_initconnection(TW_Device_Extension
*tw_dev, int message_credits,
tw_initconnect->opcode__reserved = TW_OPRES_IN(0,
TW_OP_INIT_CONNECTION);
tw_initconnect->request_id = request_id;
tw_initconnect->message_credits = cpu_to_le16(message_credits);
- tw_initconnect->features = set_features;
/* Turn on 64-bit sgl support if we need to */
- tw_initconnect->features |= sizeof(dma_addr_t) > 4 ? 1 : 0;
+ set_features |= sizeof(dma_addr_t) > 4 ? 1 : 0;
- tw_initconnect->features =
Re: [TEGRA194_CPUFREQ PATCH v6 3/3] cpufreq: Add Tegra194 cpufreq driver
On Wed, Jul 15, 2020 at 07:01:25PM +0530, Sumit Gupta wrote: > Add support for CPU frequency scaling on Tegra194. The frequency > of each core can be adjusted by writing a clock divisor value to > a MSR on the core. The range of valid divisors is queried from > the BPMP. > > Signed-off-by: Mikko Perttunen > Signed-off-by: Sumit Gupta If built as module: ERROR: modpost: "__cpu_logical_map" [drivers/cpufreq/tegra194-cpufreq.ko] undefined! Guenter
Re: [RESEND v7, PATCH 0/7] add drm support for MT8183
Hi, Yongqiang: This series is 'v8', not 'RESEND v7' Yongqiang Niu 於 2020年8月8日 週六 上午10:56寫道： > > This series are based on 5.8-rc1 and provide 7 patch > to support mediatek SOC MT8183 > > Change since v6 > - move ddp component define into mtk_mmsys.h > - add mmsys private data to support different ic path connection > - add mt8183-mmsys.c to support 8183 path connection > - fix reviewed issue in v6 > > Change since v5 > - fix reviewed issue in v5 > base https://patchwork.kernel.org/project/linux-mediatek/list/?series=213219 > > Change since v4 > - fix reviewed issue in v4 > > Change since v3 > - fix reviewed issue in v3 > - fix type error in v3 > - fix conflict with iommu patch > > Change since v2 > - fix reviewed issue in v2 > - add mutex node into dts file > > Changes since v1: > - fix reviewed issue in v1 > - add dts for mt8183 display nodes > - adjust display clock control flow in patch 22 > - add vmap support for mediatek drm in patch 23 > - fix page offset issue for mmap function in patch 24 > - enable allow_fb_modifiers for mediatek drm in patch 25 > > Yongqiang Niu (7): > dt-bindings: mediatek: add rdma_fifo_size description for mt8183 > display > drm/mediatek: move ddp component define into mtk_mmsys.h > mtk-mmsys: add mmsys private data > mtk-mmsys: add mt8183 mmsys support > drm/mediatek: add fifo_size into rdma private data > drm/mediatek: add support for mediatek SOC MT8183 > arm64: dts: add display nodes for mt8183 > > .../bindings/display/mediatek/mediatek,disp.txt| 14 ++ > arch/arm64/boot/dts/mediatek/mt8183.dtsi | 98 > drivers/gpu/drm/mediatek/mtk_disp_ovl.c| 18 ++ > drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 25 +- > drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 47 > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h| 34 +-- > drivers/gpu/drm/mediatek/mtk_drm_drv.c | 43 > drivers/soc/mediatek/Makefile | 1 + > drivers/soc/mediatek/mmsys/Makefile| 3 + > drivers/soc/mediatek/mmsys/mt2701-mmsys.c | 250 +++ > drivers/soc/mediatek/mmsys/mt8183-mmsys.c | 154 > drivers/soc/mediatek/mtk-mmsys.c | 276 > - > include/linux/soc/mediatek/mtk-mmsys.h | 48 > 13 files changed, 749 insertions(+), 262 deletions(-) > create mode 100644 drivers/soc/mediatek/mmsys/Makefile > create mode 100644 drivers/soc/mediatek/mmsys/mt2701-mmsys.c > create mode 100644 drivers/soc/mediatek/mmsys/mt8183-mmsys.c > > -- > 1.8.1.1.dirty > ___ > Linux-mediatek mailing list > linux-media...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-mediatek
Re: [PATCH v8 4/4] scsi: ufs: Prepare HPB read for cached sub-region
On 2020-08-06 02:18, Daejun Park wrote:
> +static inline u32 ufshpb_get_lpn(struct scsi_cmnd *cmnd)
> +{
> + return blk_rq_pos(cmnd->request) >>
> + (ilog2(cmnd->device->sector_size) - 9);
> +}
Please use sectors_to_logical() from drivers/scsi/sd.h instead of open-coding
that function.
> +static inline unsigned int ufshpb_get_len(struct scsi_cmnd *cmnd)
> +{
> + return blk_rq_sectors(cmnd->request) >>
> + (ilog2(cmnd->device->sector_size) - 9);
> +}
Same comment here.
> +/* routine : READ10 -> HPB_READ */
Please expand this comment.
Thanks,
Bart.
Re: [RESEND v7, PATCH 6/7] drm/mediatek: add support for mediatek SOC MT8183
Hi, Yongqiang:
Yongqiang Niu 於 2020年8月8日 週六 上午11:05寫道：
>
> This patch add support for mediatek SOC MT8183
> 1. add ovl private data
> 2. add rdma private data
> 3. add mutes private data
> 4. add main and external path module for crtc create
>
> Signed-off-by: Yongqiang Niu
[snip]
> +
> static const struct of_device_id mtk_disp_ovl_driver_dt_match[] = {
> { .compatible = "mediatek,mt2701-disp-ovl",
> .data = _ovl_driver_data},
> { .compatible = "mediatek,mt8173-disp-ovl",
> .data = _ovl_driver_data},
> + { .compatible = "mediatek,mt8183-disp-ovl",
"mediatek,mt8183-disp-ovl" is not defined in binding document [1]
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt?h=v5.8
> + .data = _ovl_driver_data},
> + { .compatible = "mediatek,mt8183-disp-ovl-2l",
Ditto.
> + .data = _ovl_2l_driver_data},
> {},
> };
[snip]
> +
> static const struct of_device_id mtk_disp_rdma_driver_dt_match[] = {
> { .compatible = "mediatek,mt2701-disp-rdma",
> .data = _rdma_driver_data},
> { .compatible = "mediatek,mt8173-disp-rdma",
> .data = _rdma_driver_data},
> + { .compatible = "mediatek,mt8183-disp-rdma",
Ditto.
> + .data = _rdma_driver_data},
> {},
> };
> MODULE_DEVICE_TABLE(of, mtk_disp_rdma_driver_dt_match);
[snip]
> +
> struct mtk_disp_mutex *mtk_disp_mutex_get(struct device *dev, unsigned int
> id)
> {
> struct mtk_ddp *ddp = dev_get_drvdata(dev);
> @@ -402,6 +447,8 @@ static int mtk_ddp_remove(struct platform_device *pdev)
> .data = _ddp_driver_data},
> { .compatible = "mediatek,mt8173-disp-mutex",
> .data = _ddp_driver_data},
> + { .compatible = "mediatek,mt8183-disp-mutex",
Ditto.
Regards,
Chun-Kuang.
> + .data = _ddp_driver_data},
> {},
> };
> MODULE_DEVICE_TABLE(of, ddp_driver_dt_match);
Re: [PATCH v8 3/4] scsi: ufs: L2P map management for HPB read
On 2020-08-06 02:15, Daejun Park wrote:
> + req->end_io_data = (void *)map_req;
Please leave the (void *) cast out since explicit casts from a non-void
to a void pointer are not necessary in C.
> +static inline struct
> +ufshpb_rsp_field *ufshpb_get_hpb_rsp(struct ufshcd_lrb *lrbp)
> +{
> + return (struct ufshpb_rsp_field *)>ucd_rsp_ptr->sr.sense_data_len;
> +}
Please introduce a union in struct utp_cmd_rsp instead of using casts
to reinterpret a part of a data structure.
> +/* routine : isr (ufs) */
The above comment looks very cryptic. Should it perhaps be expanded?
> +struct ufshpb_active_field {
> + __be16 active_rgn;
> + __be16 active_srgn;
> +} __packed;
Since "__packed" is not necessary for the above data structure, please
remove it. Note: a typical approach in the Linux kernel to verify that
the compiler has not inserted any padding bytes is to add a BUILD_BUG_ON()
statement in an initialization function that verifies the size of ABI data
structures. See also the output of the following command:
git grep -nH 'BUILD_BUG_ON.sizeof.*!='
> +struct ufshpb_rsp_field {
> + __be16 sense_data_len;
> + u8 desc_type;
> + u8 additional_len;
> + u8 hpb_type;
> + u8 reserved;
> + u8 active_rgn_cnt;
> + u8 inactive_rgn_cnt;
> + struct ufshpb_active_field hpb_active_field[2];
> + __be16 hpb_inactive_field[2];
> +} __packed;
I think the above __packed statement should also be left out.
Thanks,
Bart.
Re: [PATCH 1/2] arm: dts: mt7623: move more display-related nodes to mt7623n.dtsi
Hi, Frank: Frank Wunderlich 於 2020年8月8日 週六 下午8:27寫道： > > Hi, > > as i made a mistake in cover-letter, it is not assigned to the series. > > to show its content, i send it here as comment (instead of resending the > whole series): > > based on series from David Woodhouse [1] > i moved more display-nodes out of mt7623.dtsi to new mt7623n.dtsi > and changed last part from my series [2] to add these nodes to this new dtsi > > the depency of dtsi-dtsi-dts is already done for mt7623a, so i guess it's a > good > way to use it for mt7623n too. > > this first set is an RFC if all nodes are in right order and if it is wanted > to move > them out as i have no technical document about mt7623a/n which describes > which parts > are available on both or only on one of them > > added MTK DRM Maintainer CK Hu, Ryder Lee and Sean Wang, maybe they can give > me some advice > how to proceed further here > > [1] https://patchwork.kernel.org/project/linux-mediatek/list/?series=329209 > [2] https://patchwork.kernel.org/patch/11700699/ I would like to put all device in mt7623.dtsi with some device's status is "disabled" and change its status in platform dtsi. I would like to see all device in mt7623.dtsi because of its name. If you move some device to platform dtsi, we would trace all platform dtsi to find out how many device in mt7623. One day a new platform enable different devices, you would reorganize all these platform dtsi? Regards, Chun-Kuang.
Re: [PATCH v2] scsi: 3w-9xxx: Fix endianness issues found by sparse
On 8/5/20 2:17 AM, Arnd Bergmann wrote:
> On Wed, Aug 5, 2020 at 3:44 AM Samuel Holland wrote:
>> On 8/3/20 9:02 AM, Arnd Bergmann wrote:
>>> On Mon, Aug 3, 2020 at 5:42 AM Samuel Holland wrote:
All of the command structures are packed, due to the "#pragma pack(1)"
earlier
in the file. So alignment is not an issue. This dma_addr_t member _is_ the
explicit padding to make sizeof(TW_Command) -
sizeof(TW_Command.byte8_offset.{io,param}.sgl) equal TW_COMMAND_SIZE * 4.
And
indeed the structure is expected to be a different size depending on
sizeof(dma_addr_t).
>>>
>>> Ah, so only the first few members are accessed by hardware and the
>>> last union is only accessed by the OS then? In that case I suppose it is
>>> all fine, but I would also suggest removing the "#pragma packed"
>>> to get somewhat more efficient access on systems that have problems
>>> with misaligned accesses.
>>
>> I don't know what part the hardware accesses; everything I know about the
>> hardware comes from reading the driver.
>
> I see now from your explanation below that this is a hardware-defined
> structure. I was confused by how it can be either 32 or 64 bits wide but
> found the
>
> tw_initconnect->features |= sizeof(dma_addr_t) > 4 ? 1 : 0;
>
> line now that tells the hardware about which format is used.
>
>> The problem with removing the "#pragma pack(1)" is that the structure is
>> inherently misaligned: byte8_offset.io.sgl starts at offset 12, but it may
>> begin
>> with a __le64.
>
> I think a fairly clean way to handle this would be to remove the pragma
> and instead define a local type like
>
> #if IS_ENABLED(CONFIG_ARCH_DMA_ADDR_T_64BIT)
> typedef __le64 twa_address_t __packed;
> #else
> typedef __le32 twa_addr_t;
> #endif
I would be happy to implement this... but __packed only works on enums, structs,
and unions[1]:
In file included from drivers/scsi/3w-9xxx.c:100:
drivers/scsi/3w-9xxx.h:474:1: warning: 'packed' attribute ignored [-Wattributes]
474 | typedef __le64 twa_addr_t __packed;
| ^~~
[1]:
https://gcc.gnu.org/onlinedocs/gcc/Common-Type-Attributes.html#index-packed-type-attribute
> The problem with marking the entire structure as packed, rather than
> just individual members is that you end up with very inefficient bytewise
> access on some architectures (especially those without cache-coherent
> DMA or hardware unaligned access in the CPU), so I would recommend
> avoiding that in portable driver code.
I agree, but I think this is a separate issue from what this patch is fixing. I
would prefer to save this change for a separate patch.
Regards,
Samuel
Re: [PATCH v8 2/4] scsi: ufs: Introduce HPB feature
On 2020-08-06 02:11, Daejun Park wrote:
> This is a patch for the HPB feature.
> This patch adds HPB function calls to UFS core driver.
>
> The mininum size of the memory pool used in the HPB is implemented as a
^^^
minimum?
> Kconfig parameter (SCSI_UFS_HPB_HOST_MEM), so that it can be configurable.
> +config SCSI_UFS_HPB
> + bool "Support UFS Host Performance Booster"
> + depends on SCSI_UFSHCD
> + help
> + A UFS HPB Feature improves random read performance. It caches
^ ^^^
The? feature?
> + L2P map of UFS to host DRAM. The driver uses HPB read command
> + by piggybacking physical page number for bypassing FTL's L2P address
> + translation.
Please explain what L2P and FTL mean. Not everyone is familiar with SSD
internals.
> +config SCSI_UFS_HPB_HOST_MEM
> + int "Host-side cached memory size (KB) for HPB support"
> + default 32
> + depends on SCSI_UFS_HPB
> + help
> + The mininum size of the memory pool used in the HPB module. It can
> + be configurable by the user. If this value is larger than required
> + memory size, kernel resizes cached memory size.
^^^ ^^
reduces?cache size?
Please make this a kernel module parameter instead of a compile-time constant.
> +#ifndef CONFIG_SCSI_UFS_HPB
> +static void ufshpb_resume(struct ufs_hba *hba) {}
> +static void ufshpb_suspend(struct ufs_hba *hba) {}
> +static void ufshpb_reset(struct ufs_hba *hba) {}
> +static void ufshpb_reset_host(struct ufs_hba *hba) {}
> +static void ufshpb_rsp_upiu(struct ufs_hba *hba, struct ufshcd_lrb *lrbp) {}
> +static void ufshpb_prep(struct ufs_hba *hba, struct ufshcd_lrb *lrbp) {}
> +static void ufshpb_remove(struct ufs_hba *hba) {}
> +static void ufshpb_scan_feature(struct ufs_hba *hba) {}
> +#endif
Please move these definitions into ufshpb.h since that is the
recommended Linux kernel coding style.
> diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
> index b2ef18f1b746..904c19796e09 100644
> --- a/drivers/scsi/ufs/ufshcd.h
> +++ b/drivers/scsi/ufs/ufshcd.h
> @@ -47,6 +47,9 @@
> #include "ufs.h"
> #include "ufs_quirks.h"
> #include "ufshci.h"
> +#ifdef CONFIG_SCSI_UFS_HPB
> +#include "ufshpb.h"
> +#endif
Please move #ifdef CONFIG_SCSI_UFS_HPB / #endif into ufshpb.h. From
Documentation/process/4.Coding.rst: "As a general rule, #ifdef use
should be confined to header files whenever possible."
> +struct ufsf_feature_info {
> + atomic_t slave_conf_cnt;
> + wait_queue_head_t sdev_wait;
> +};
Please add a comment above this data structure that explains the role
of this data structure and also what "ufsf" stands for.
> +static int ufshpb_create_sysfs(struct ufs_hba *hba, struct ufshpb_lu *hpb);
I don't think that this forward declaration is necessary so please leave it
out.
> +static inline int ufshpb_is_valid_srgn(struct ufshpb_region *rgn,
> + struct ufshpb_subregion *srgn)
> +{
> + return rgn->rgn_state != HPB_RGN_INACTIVE &&
> + srgn->srgn_state == HPB_SRGN_VALID;
> +}
Please do not declare functions inside .c files inline but instead let
the compiler decide which functions to inline. Modern compilers are really
good at this.
> +static struct kobj_type ufshpb_ktype = {
> + .sysfs_ops = _sysfs_ops,
> + .release = NULL,
> +};
If the release method of a kobj_type is NULL that is a strong sign that
there is something wrong ...
> +static int ufshpb_create_sysfs(struct ufs_hba *hba, struct ufshpb_lu *hpb)
> +{
> + int ret;
> +
> + ufshpb_stat_init(hpb);
> +
> + kobject_init(>kobj, _ktype);
> + mutex_init(>sysfs_lock);
> +
> + ret = kobject_add(>kobj, kobject_get(>dev->kobj),
> + "ufshpb_lu%d", hpb->lun);
> +
> + if (ret)
> + return ret;
> +
> + ret = sysfs_create_group(>kobj, _sysfs_group);
> +
> + if (ret) {
> + dev_err(hba->dev, "ufshpb_lu%d create file error\n", hpb->lun);
> + return ret;
> + }
> +
> + dev_info(hba->dev, "ufshpb_lu%d sysfs adds uevent", hpb->lun);
> + kobject_uevent(>kobj, KOBJ_ADD);
> +
> + return 0;
> +}
Please attach these sysfs attributes to /sys/class/scsi_device/*/device
instead of creating a new kobject. Consider using the following
scsi_host_template member to define LUN sysfs attributes:
/*
* Pointer to the SCSI device attribute groups for this host,
* NULL terminated.
*/
const struct attribute_group **sdev_groups;
> +static void ufshpb_scan_hpb_lu(struct ufs_hba *hba,
> +struct ufshpb_dev_info *hpb_dev_info,
> +u8 *desc_buf)
> +{
> + struct scsi_device *sdev;
> + struct ufshpb_lu *hpb;
> + int find_hpb_lu = 0;
> + int ret;
> +
> + shost_for_each_device(sdev, hba->host) {
> +
[PATCH AUTOSEL 5.8 01/72] ARM: dts: stm32: fix uart nodes ordering in stm32mp15-pinctrl
From: Erwan Le Ray
[ Upstream commit f6b43d89d3b5a31bf4251a26c61e92bf659e74c5 ]
Fix usart and uart nodes ordering. Several usart nodes didn't respect
expecting ordering.
Fixes: 077e0638fc83 ("ARM: dts: stm32: Add alternate pinmux for USART2 pins on
stm32mp15")
Signed-off-by: Erwan Le Ray
Signed-off-by: Alexandre Torgue
Signed-off-by: Sasha Levin
---
arch/arm/boot/dts/stm32mp15-pinctrl.dtsi | 102 +++
1 file changed, 51 insertions(+), 51 deletions(-)
diff --git a/arch/arm/boot/dts/stm32mp15-pinctrl.dtsi
b/arch/arm/boot/dts/stm32mp15-pinctrl.dtsi
index 7eb858732d6d0..b31923a9498b5 100644
--- a/arch/arm/boot/dts/stm32mp15-pinctrl.dtsi
+++ b/arch/arm/boot/dts/stm32mp15-pinctrl.dtsi
@@ -1574,143 +1574,143 @@ pins2 {
};
};
- usart2_pins_a: usart2-0 {
+ uart4_pins_a: uart4-0 {
pins1 {
- pinmux = , /* USART2_TX */
-; /* USART2_RTS */
+ pinmux = ; /* UART4_TX */
bias-disable;
drive-push-pull;
slew-rate = <0>;
};
pins2 {
- pinmux = , /* USART2_RX */
-; /* USART2_CTS_NSS
*/
+ pinmux = ; /* UART4_RX */
bias-disable;
};
};
- usart2_sleep_pins_a: usart2-sleep-0 {
- pins {
- pinmux = , /* USART2_TX */
-, /* USART2_RTS
*/
-, /* USART2_RX */
-; /*
USART2_CTS_NSS */
- };
- };
-
- usart2_pins_b: usart2-1 {
+ uart4_pins_b: uart4-1 {
pins1 {
- pinmux = , /* USART2_TX */
-; /* USART2_RTS */
+ pinmux = ; /* UART4_TX */
bias-disable;
drive-push-pull;
slew-rate = <0>;
};
pins2 {
- pinmux = , /* USART2_RX */
-; /*
USART2_CTS_NSS */
+ pinmux = ; /* UART4_RX */
bias-disable;
};
};
- usart2_sleep_pins_b: usart2-sleep-1 {
- pins {
- pinmux = , /* USART2_TX */
-, /* USART2_RTS
*/
-, /* USART2_RX */
-; /*
USART2_CTS_NSS */
- };
- };
-
- usart3_pins_a: usart3-0 {
+ uart4_pins_c: uart4-2 {
pins1 {
- pinmux = ; /* USART3_TX */
+ pinmux = ; /* UART4_TX */
bias-disable;
drive-push-pull;
slew-rate = <0>;
};
pins2 {
- pinmux = ; /* USART3_RX */
+ pinmux = ; /* UART4_RX */
bias-disable;
};
};
- uart4_pins_a: uart4-0 {
+ uart7_pins_a: uart7-0 {
pins1 {
- pinmux = ; /* UART4_TX */
+ pinmux = ; /* UART4_TX */
bias-disable;
drive-push-pull;
slew-rate = <0>;
};
pins2 {
- pinmux = ; /* UART4_RX */
+ pinmux = , /* UART4_RX */
+, /* UART4_CTS */
+; /* UART4_RTS */
bias-disable;
};
};
- uart4_pins_b: uart4-1 {
+ uart7_pins_b: uart7-1 {
pins1 {
- pinmux = ; /* UART4_TX */
+ pinmux = ; /* UART7_TX */
bias-disable;
drive-push-pull;
slew-rate = <0>;
};
pins2 {
- pinmux = ; /* UART4_RX */
+ pinmux = ; /* UART7_RX */
bias-disable;
};
};
- uart4_pins_c: uart4-2 {
+ uart8_pins_a: uart8-0 {
pins1 {
- pinmux = ; /* UART4_TX */
+ pinmux = ; /* UART8_TX */
bias-disable;
drive-push-pull;
slew-rate = <0>;
};
pins2 {
- pinmux = ; /* UART4_RX */
+ pinmux = ; /* UART8_RX */
bias-disable;
};
};
- uart7_pins_a: uart7-0 {
+ usart2_pins_a: usart2-0 {
pins1 {
- pinmux = ; /*
[PATCH AUTOSEL 5.8 02/72] ARM: dts: stm32: fix uart7_pins_a comments in stm32mp15-pinctrl
From: Erwan Le Ray
[ Upstream commit 391e437eedc0dab0a9f2c26997e68e040ae04ea3 ]
Fix uart7_pins_a comments to indicate UART7 pins instead of UART4 pins.
Fixes: bf4b5f379fed ("ARM: dts: stm32: Add missing pinctrl definitions for
STM32MP157")
Signed-off-by: Erwan Le Ray
Signed-off-by: Alexandre Torgue
Signed-off-by: Sasha Levin
---
arch/arm/boot/dts/stm32mp15-pinctrl.dtsi | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/stm32mp15-pinctrl.dtsi
b/arch/arm/boot/dts/stm32mp15-pinctrl.dtsi
index b31923a9498b5..49132921feeb9 100644
--- a/arch/arm/boot/dts/stm32mp15-pinctrl.dtsi
+++ b/arch/arm/boot/dts/stm32mp15-pinctrl.dtsi
@@ -1615,15 +1615,15 @@ pins2 {
uart7_pins_a: uart7-0 {
pins1 {
- pinmux = ; /* UART4_TX */
+ pinmux = ; /* UART7_TX */
bias-disable;
drive-push-pull;
slew-rate = <0>;
};
pins2 {
- pinmux = , /* UART4_RX */
-, /* UART4_CTS */
-; /* UART4_RTS */
+ pinmux = , /* UART7_RX */
+, /* UART7_CTS */
+; /* UART7_RTS */
bias-disable;
};
};
--
2.25.1
[PATCH AUTOSEL 5.8 20/72] ARM: exynos: MCPM: Restore big.LITTLE cpuidle support
From: Marek Szyprowski
[ Upstream commit ea9dd8f61c8a890843f68e8dc0062ce78365aab8 ]
Call exynos_cpu_power_up(cpunr) unconditionally. This is needed by the
big.LITTLE cpuidle driver and has no side-effects on other code paths.
The additional soft-reset call during little core power up has been added
to properly boot all cores on the Exynos5422-based boards with secure
firmware (like Odroid XU3/XU4 family). This however broke big.LITTLE
CPUidle driver, which worked only on boards without secure firmware (like
Peach-Pit/Pi Chromebooks). Apply the workaround only when board is
running under secure firmware.
Fixes: 833b5794e330 ("ARM: EXYNOS: reset Little cores when cpu is up")
Signed-off-by: Marek Szyprowski
Reviewed-by: Lukasz Luba
Signed-off-by: Krzysztof Kozlowski
Signed-off-by: Sasha Levin
---
arch/arm/mach-exynos/mcpm-exynos.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-exynos/mcpm-exynos.c
b/arch/arm/mach-exynos/mcpm-exynos.c
index 9a681b421ae11..cd861c57d5adf 100644
--- a/arch/arm/mach-exynos/mcpm-exynos.c
+++ b/arch/arm/mach-exynos/mcpm-exynos.c
@@ -26,6 +26,7 @@
#define EXYNOS5420_USE_L2_COMMON_UP_STATE BIT(30)
static void __iomem *ns_sram_base_addr __ro_after_init;
+static bool secure_firmware __ro_after_init;
/*
* The common v7_exit_coherency_flush API could not be used because of the
@@ -58,15 +59,16 @@ static void __iomem *ns_sram_base_addr __ro_after_init;
static int exynos_cpu_powerup(unsigned int cpu, unsigned int cluster)
{
unsigned int cpunr = cpu + (cluster * EXYNOS5420_CPUS_PER_CLUSTER);
+ bool state;
pr_debug("%s: cpu %u cluster %u\n", __func__, cpu, cluster);
if (cpu >= EXYNOS5420_CPUS_PER_CLUSTER ||
cluster >= EXYNOS5420_NR_CLUSTERS)
return -EINVAL;
- if (!exynos_cpu_power_state(cpunr)) {
- exynos_cpu_power_up(cpunr);
-
+ state = exynos_cpu_power_state(cpunr);
+ exynos_cpu_power_up(cpunr);
+ if (!state && secure_firmware) {
/*
* This assumes the cluster number of the big cores(Cortex A15)
* is 0 and the Little cores(Cortex A7) is 1.
@@ -258,6 +260,8 @@ static int __init exynos_mcpm_init(void)
return -ENOMEM;
}
+ secure_firmware = exynos_secure_firmware_available();
+
/*
* To increase the stability of KFC reset we need to program
* the PMU SPARE3 register
--
2.25.1
[PATCH AUTOSEL 5.8 07/72] x86, sched: Bail out of frequency invariance if turbo_freq/base_freq gives 0
From: Giovanni Gherdovich
[ Upstream commit f4291df103315a696f0b8c4f45ca8ae773c17441 ]
Be defensive against the case where the processor reports a base_freq
larger than turbo_freq (the ratio would be zero).
Fixes: 1567c3e3467c ("x86, sched: Add support for frequency invariance")
Signed-off-by: Giovanni Gherdovich
Signed-off-by: Peter Zijlstra (Intel)
Reviewed-by: Rafael J. Wysocki
Link: https://lkml.kernel.org/r/20200531182453.15254-4-ggherdov...@suse.cz
Signed-off-by: Sasha Levin
---
arch/x86/kernel/smpboot.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
index 20e1cea262e4b..518ac6bf752e0 100644
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -1977,6 +1977,7 @@ static bool core_set_max_freq_ratio(u64 *base_freq, u64
*turbo_freq)
static bool intel_set_max_freq_ratio(void)
{
u64 base_freq, turbo_freq;
+ u64 turbo_ratio;
if (slv_set_max_freq_ratio(_freq, _freq))
goto out;
@@ -2010,9 +2011,15 @@ static bool intel_set_max_freq_ratio(void)
return false;
}
- arch_turbo_freq_ratio = div_u64(turbo_freq * SCHED_CAPACITY_SCALE,
- base_freq);
+ turbo_ratio = div_u64(turbo_freq * SCHED_CAPACITY_SCALE, base_freq);
+ if (!turbo_ratio) {
+ pr_debug("Non-zero turbo and base frequencies led to a 0
ratio.\n");
+ return false;
+ }
+
+ arch_turbo_freq_ratio = turbo_ratio;
arch_set_max_freq_ratio(turbo_disabled());
+
return true;
}
--
2.25.1
[PATCH AUTOSEL 5.8 24/72] arm64: dts: exynos: Fix silent hang after boot on Espresso
From: Alim Akhtar
[ Upstream commit b072714bfc0e42c984b8fd6e069f3ca17de8137a ]
Once regulators are disabled after kernel boot, on Espresso board silent
hang observed because of LDO7 being disabled. LDO7 actually provide
power to CPU cores and non-cpu blocks circuitries. Keep this regulator
always-on to fix this hang.
Fixes: 9589f7721e16 ("arm64: dts: Add S2MPS15 PMIC node on exynos7-espresso")
Signed-off-by: Alim Akhtar
Signed-off-by: Krzysztof Kozlowski
Signed-off-by: Sasha Levin
---
arch/arm64/boot/dts/exynos/exynos7-espresso.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
b/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
index 7af288fa9475f..a9412805c1d6a 100644
--- a/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
+++ b/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
@@ -157,6 +157,7 @@ ldo7_reg: LDO7 {
regulator-min-microvolt = <70>;
regulator-max-microvolt = <115>;
regulator-enable-ramp-delay = <125>;
+ regulator-always-on;
};
ldo8_reg: LDO8 {
--
2.25.1
[PATCH AUTOSEL 5.8 19/72] crypto: ccree - fix resource leak on error path
From: Gilad Ben-Yossef
[ Upstream commit 9bc6165d608d676f05d8bf156a2c9923ee38d05b ]
Fix a small resource leak on the error path of cipher processing.
Signed-off-by: Gilad Ben-Yossef
Fixes: 63ee04c8b491e ("crypto: ccree - add skcipher support")
Cc: Markus Elfring
Signed-off-by: Herbert Xu
Signed-off-by: Sasha Levin
---
drivers/crypto/ccree/cc_cipher.c | 30 ++
1 file changed, 18 insertions(+), 12 deletions(-)
diff --git a/drivers/crypto/ccree/cc_cipher.c b/drivers/crypto/ccree/cc_cipher.c
index 872ea3ff1c6ba..f144fe04748b0 100644
--- a/drivers/crypto/ccree/cc_cipher.c
+++ b/drivers/crypto/ccree/cc_cipher.c
@@ -159,7 +159,6 @@ static int cc_cipher_init(struct crypto_tfm *tfm)
skcipher_alg.base);
struct device *dev = drvdata_to_dev(cc_alg->drvdata);
unsigned int max_key_buf_size = cc_alg->skcipher_alg.max_keysize;
- int rc = 0;
dev_dbg(dev, "Initializing context @%p for %s\n", ctx_p,
crypto_tfm_alg_name(tfm));
@@ -171,10 +170,19 @@ static int cc_cipher_init(struct crypto_tfm *tfm)
ctx_p->flow_mode = cc_alg->flow_mode;
ctx_p->drvdata = cc_alg->drvdata;
+ if (ctx_p->cipher_mode == DRV_CIPHER_ESSIV) {
+ /* Alloc hash tfm for essiv */
+ ctx_p->shash_tfm = crypto_alloc_shash("sha256-generic", 0, 0);
+ if (IS_ERR(ctx_p->shash_tfm)) {
+ dev_err(dev, "Error allocating hash tfm for ESSIV.\n");
+ return PTR_ERR(ctx_p->shash_tfm);
+ }
+ }
+
/* Allocate key buffer, cache line aligned */
ctx_p->user.key = kmalloc(max_key_buf_size, GFP_KERNEL);
if (!ctx_p->user.key)
- return -ENOMEM;
+ goto free_shash;
dev_dbg(dev, "Allocated key buffer in context. key=@%p\n",
ctx_p->user.key);
@@ -186,21 +194,19 @@ static int cc_cipher_init(struct crypto_tfm *tfm)
if (dma_mapping_error(dev, ctx_p->user.key_dma_addr)) {
dev_err(dev, "Mapping Key %u B at va=%pK for DMA failed\n",
max_key_buf_size, ctx_p->user.key);
- return -ENOMEM;
+ goto free_key;
}
dev_dbg(dev, "Mapped key %u B at va=%pK to dma=%pad\n",
max_key_buf_size, ctx_p->user.key, _p->user.key_dma_addr);
- if (ctx_p->cipher_mode == DRV_CIPHER_ESSIV) {
- /* Alloc hash tfm for essiv */
- ctx_p->shash_tfm = crypto_alloc_shash("sha256-generic", 0, 0);
- if (IS_ERR(ctx_p->shash_tfm)) {
- dev_err(dev, "Error allocating hash tfm for ESSIV.\n");
- return PTR_ERR(ctx_p->shash_tfm);
- }
- }
+ return 0;
- return rc;
+free_key:
+ kfree(ctx_p->user.key);
+free_shash:
+ crypto_free_shash(ctx_p->shash_tfm);
+
+ return -ENOMEM;
}
static void cc_cipher_exit(struct crypto_tfm *tfm)
--
2.25.1
[PATCH AUTOSEL 5.8 21/72] rcu/tree: Repeat the monitor if any free channel is busy
From: "Uladzislau Rezki (Sony)"
[ Upstream commit 594aa5975b9b5cfe9edaec06170e43b8c0607377 ]
It is possible that one of the channels cannot be detached
because its free channel is busy and previously queued data
has not been processed yet. On the other hand, another
channel can be successfully detached causing the monitor
work to stop.
Prevent that by rescheduling the monitor work if there are
any channels in the pending state after a detach attempt.
Fixes: 34c881745549e ("rcu: Support kfree_bulk() interface in kfree_rcu()")
Acked-by: Joel Fernandes (Google)
Signed-off-by: Uladzislau Rezki (Sony)
Signed-off-by: Paul E. McKenney
Signed-off-by: Sasha Levin
---
kernel/rcu/tree.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index 6c6569e0586c5..1e9e500ff7906 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -3105,7 +3105,7 @@ static void kfree_rcu_work(struct work_struct *work)
static inline bool queue_kfree_rcu_work(struct kfree_rcu_cpu *krcp)
{
struct kfree_rcu_cpu_work *krwp;
- bool queued = false;
+ bool repeat = false;
int i;
lockdep_assert_held(>lock);
@@ -3143,11 +3143,14 @@ static inline bool queue_kfree_rcu_work(struct
kfree_rcu_cpu *krcp)
* been detached following each other, one by one.
*/
queue_rcu_work(system_wq, >rcu_work);
- queued = true;
}
+
+ /* Repeat if any "free" corresponding channel is still busy. */
+ if (krcp->bhead || krcp->head)
+ repeat = true;
}
- return queued;
+ return !repeat;
}
static inline void kfree_rcu_drain_unlock(struct kfree_rcu_cpu *krcp,
--
2.25.1
[PATCH AUTOSEL 5.8 08/72] sched/fair: Fix NOHZ next idle balance
From: Vincent Guittot
[ Upstream commit 3ea2f097b17e13a8280f1f9386c331b326a3dbef ]
With commit:
'b7031a02ec75 ("sched/fair: Add NOHZ_STATS_KICK")'
rebalance_domains of the local cfs_rq happens before others idle cpus have
updated nohz.next_balance and its value is overwritten.
Move the update of nohz.next_balance for other idles cpus before balancing
and updating the next_balance of local cfs_rq.
Also, the nohz.next_balance is now updated only if all idle cpus got a
chance to rebalance their domains and the idle balance has not been aborted
because of new activities on the CPU. In case of need_resched, the idle
load balance will be kick the next jiffie in order to address remaining
ilb.
Fixes: b7031a02ec75 ("sched/fair: Add NOHZ_STATS_KICK")
Reported-by: Peng Liu
Signed-off-by: Vincent Guittot
Signed-off-by: Peter Zijlstra (Intel)
Reviewed-by: Valentin Schneider
Acked-by: Mel Gorman
Link:
https://lkml.kernel.org/r/20200609123748.18636-1-vincent.guit...@linaro.org
Signed-off-by: Sasha Levin
---
kernel/sched/fair.c | 23 ++-
1 file changed, 14 insertions(+), 9 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 04fa8dbcfa4d7..6b3b59cc51d6c 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -10027,7 +10027,12 @@ static void kick_ilb(unsigned int flags)
{
int ilb_cpu;
- nohz.next_balance++;
+ /*
+* Increase nohz.next_balance only when if full ilb is triggered but
+* not if we only update stats.
+*/
+ if (flags & NOHZ_BALANCE_KICK)
+ nohz.next_balance = jiffies+1;
ilb_cpu = find_new_ilb();
@@ -10348,6 +10353,14 @@ static bool _nohz_idle_balance(struct rq *this_rq,
unsigned int flags,
}
}
+ /*
+* next_balance will be updated only when there is a need.
+* When the CPU is attached to null domain for ex, it will not be
+* updated.
+*/
+ if (likely(update_next_balance))
+ nohz.next_balance = next_balance;
+
/* Newly idle CPU doesn't need an update */
if (idle != CPU_NEWLY_IDLE) {
update_blocked_averages(this_cpu);
@@ -10368,14 +10381,6 @@ static bool _nohz_idle_balance(struct rq *this_rq,
unsigned int flags,
if (has_blocked_load)
WRITE_ONCE(nohz.has_blocked, 1);
- /*
-* next_balance will be updated only when there is a need.
-* When the CPU is attached to null domain for ex, it will not be
-* updated.
-*/
- if (likely(update_next_balance))
- nohz.next_balance = next_balance;
-
return ret;
}
--
2.25.1
[PATCH AUTOSEL 5.8 23/72] arm64: dts: sun50i-pinephone: dldo4 must not be >= 1.8V
From: Ondrej Jirman
[ Upstream commit 86be5c789690eb08656b08c072c50a7b02bf41f1 ]
Some outputs from the RTL8723CS are connected to the PL port (BT_WAKE_AP),
which runs at 1.8V. When BT_WAKE_AP is high, the PL pin this signal is
connected to is overdriven, and the whole PL port's voltage rises
somewhat. This results in changing voltage on the R_PWM pin (PL10),
which is the cause for backlight flickering very noticeably when typing
on a Bluetooth keyboard, because backlight intensity is highly sensitive
to the voltage of the R_PWM pin.
Limit the maximum WiFi/BT I/O voltage to 1.8V to avoid overdriving
the PL port pins via BT and WiFi IO port signals. WiFi and BT
functionality is unaffected by this change.
This completely stops the backlight flicker when using bluetooth.
Fixes: 91f480d40942 ("arm64: dts: allwinner: Add initial support for Pine64
PinePhone")
Signed-off-by: Ondrej Jirman
Link: https://lore.kernel.org/r/20200703194842.111845-4-meg...@megous.com
Signed-off-by: Maxime Ripard
Signed-off-by: Sasha Levin
---
arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
index cefda145c3c9d..342733a20c337 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
@@ -279,7 +279,7 @@ _dldo3 {
_dldo4 {
regulator-min-microvolt = <180>;
- regulator-max-microvolt = <330>;
+ regulator-max-microvolt = <180>;
regulator-name = "vcc-wifi-io";
};
--
2.25.1
[PATCH AUTOSEL 5.8 12/72] arm64: dts: rockchip: fix rk3399-puma gmac reset gpio
From: Heiko Stuebner
[ Upstream commit 8a445086f8af0b7b9bd8d1901d6f306bb154f70d ]
The puma gmac node currently uses opposite active-values for the
gmac phy reset pin. The gpio-declaration uses active-high while the
separate snps,reset-active-low property marks the pin as active low.
While on the kernel side this works ok, other DT users may get
confused - as seen with uboot right now.
So bring this in line and make both properties match, similar to the
other Rockchip board.
Fixes: 2c66fc34e945 ("arm64: dts: rockchip: add RK3399-Q7 (Puma) SoM")
Signed-off-by: Heiko Stuebner
Link: https://lore.kernel.org/r/20200603132836.362519-1-he...@sntech.de
Signed-off-by: Sasha Levin
---
arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi
b/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi
index 063f59a420b65..72c06abd27ea7 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi
@@ -157,7 +157,7 @@ {
phy-mode = "rgmii";
pinctrl-names = "default";
pinctrl-0 = <_pins>;
- snps,reset-gpio = < RK_PC0 GPIO_ACTIVE_HIGH>;
+ snps,reset-gpio = < RK_PC0 GPIO_ACTIVE_LOW>;
snps,reset-active-low;
snps,reset-delays-us = <0 1 5>;
tx_delay = <0x10>;
--
2.25.1
[PATCH AUTOSEL 5.8 22/72] firmware: arm_scmi: Fix SCMI genpd domain probing
From: Cristian Marussi
[ Upstream commit e0f1a30cf184821499eeb67daedd7a3f21bbcb0b ]
When, at probe time, an SCMI communication failure inhibits the capacity
to query power domains states, such domains should be skipped.
Registering partially initialized SCMI power domains with genpd will
causes kernel panic.
arm-scmi timed out in resp(caller: scmi_power_state_get+0xa4/0xd0)
scmi-power-domain scmi_dev.2: failed to get state for domain 9
Unable to handle kernel NULL pointer dereference at virtual address
Mem abort info:
ESR = 0x9606
EC = 0x25: DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
Data abort info:
ISV = 0, ISS = 0x0006
CM = 0, WnR = 0
user pgtable: 4k pages, 48-bit VAs, pgdp=0009f3691000
[] pgd=0009f1ca0003, p4d=0009f1ca0003,
pud=0009f35ea003, pmd=
Internal error: Oops: 9606 [#1] PREEMPT SMP
CPU: 2 PID: 381 Comm: bash Not tainted 5.8.0-rc1-00011-gebd118c2cca8 #2
Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development
Platform, BIOS EDK II Jan 3 2020
Internal error: Oops: 9606 [#1] PREEMPT SMP
pstate: 8005 (Nzcv daif -PAN -UAO BTYPE=--)
pc : of_genpd_add_provider_onecell+0x98/0x1f8
lr : of_genpd_add_provider_onecell+0x48/0x1f8
Call trace:
of_genpd_add_provider_onecell+0x98/0x1f8
scmi_pm_domain_probe+0x174/0x1e8
scmi_dev_probe+0x90/0xe0
really_probe+0xe4/0x448
driver_probe_device+0xfc/0x168
device_driver_attach+0x7c/0x88
bind_store+0xe8/0x128
drv_attr_store+0x2c/0x40
sysfs_kf_write+0x4c/0x60
kernfs_fop_write+0x114/0x230
__vfs_write+0x24/0x50
vfs_write+0xbc/0x1e0
ksys_write+0x70/0xf8
__arm64_sys_write+0x24/0x30
el0_svc_common.constprop.3+0x94/0x160
do_el0_svc+0x2c/0x98
el0_sync_handler+0x148/0x1a8
el0_sync+0x158/0x180
Do not register any power domain that failed to be queried with genpd.
Fixes: 898216c97ed2 ("firmware: arm_scmi: add device power domain support using
genpd")
Link: https://lore.kernel.org/r/20200619220330.12217-1-cristian.maru...@arm.com
Signed-off-by: Cristian Marussi
Signed-off-by: Sudeep Holla
Signed-off-by: Sasha Levin
---
drivers/firmware/arm_scmi/scmi_pm_domain.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/firmware/arm_scmi/scmi_pm_domain.c
b/drivers/firmware/arm_scmi/scmi_pm_domain.c
index bafbfe358f97d..9e44479f02842 100644
--- a/drivers/firmware/arm_scmi/scmi_pm_domain.c
+++ b/drivers/firmware/arm_scmi/scmi_pm_domain.c
@@ -85,7 +85,10 @@ static int scmi_pm_domain_probe(struct scmi_device *sdev)
for (i = 0; i < num_domains; i++, scmi_pd++) {
u32 state;
- domains[i] = _pd->genpd;
+ if (handle->power_ops->state_get(handle, i, )) {
+ dev_warn(dev, "failed to get state for domain %d\n", i);
+ continue;
+ }
scmi_pd->domain = i;
scmi_pd->handle = handle;
@@ -94,13 +97,10 @@ static int scmi_pm_domain_probe(struct scmi_device *sdev)
scmi_pd->genpd.power_off = scmi_pd_power_off;
scmi_pd->genpd.power_on = scmi_pd_power_on;
- if (handle->power_ops->state_get(handle, i, )) {
- dev_warn(dev, "failed to get state for domain %d\n", i);
- continue;
- }
-
pm_genpd_init(_pd->genpd, NULL,
state == SCMI_POWER_STATE_GENERIC_OFF);
+
+ domains[i] = _pd->genpd;
}
scmi_pd_data->domains = domains;
--
2.25.1
[PATCH AUTOSEL 5.8 18/72] soc: qcom: rpmh-rsc: Don't use ktime for timeout in write_tcs_reg_sync()
From: Douglas Anderson
[ Upstream commit be24c6a71ecfbd9436ea1f496eb518a53e06368c ]
The write_tcs_reg_sync() may be called after timekeeping is suspended
so it's not OK to use ktime. The readl_poll_timeout_atomic() macro
implicitly uses ktime. This was causing a warning at suspend time.
Change to just loop 100 times with a delay of 1 us between loops.
This may give a timeout of more than 1 second but never less and is
safe even if timekeeping is suspended.
NOTE: I don't have any actual evidence that we need to loop here.
It's possibly that all we really need to do is just read the value
back to ensure that the pipes are cleaned and the looping/comparing is
totally not needed. I never saw the loop being needed in my tests.
However, the loop shouldn't hurt.
Reviewed-by: Stephen Boyd
Reviewed-by: Maulik Shah
Fixes: 91160150aba0 ("soc: qcom: rpmh-rsc: Timeout after 1 second in
write_tcs_reg_sync()")
Reported-by: Maulik Shah
Signed-off-by: Douglas Anderson
Link:
https://lore.kernel.org/r/20200528074530.1.Ib86e5b406fe7d16575ae1bb276d650faa144b63c@changeid
Signed-off-by: Bjorn Andersson
Signed-off-by: Sasha Levin
---
drivers/soc/qcom/rpmh-rsc.c | 18 +-
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/drivers/soc/qcom/rpmh-rsc.c b/drivers/soc/qcom/rpmh-rsc.c
index 076fd27f3081c..906778e2c1fae 100644
--- a/drivers/soc/qcom/rpmh-rsc.c
+++ b/drivers/soc/qcom/rpmh-rsc.c
@@ -175,13 +175,21 @@ static void write_tcs_reg(const struct rsc_drv *drv, int
reg, int tcs_id,
static void write_tcs_reg_sync(const struct rsc_drv *drv, int reg, int tcs_id,
u32 data)
{
- u32 new_data;
+ int i;
writel(data, tcs_reg_addr(drv, reg, tcs_id));
- if (readl_poll_timeout_atomic(tcs_reg_addr(drv, reg, tcs_id), new_data,
- new_data == data, 1, USEC_PER_SEC))
- pr_err("%s: error writing %#x to %d:%#x\n", drv->name,
- data, tcs_id, reg);
+
+ /*
+* Wait until we read back the same value. Use a counter rather than
+* ktime for timeout since this may be called after timekeeping stops.
+*/
+ for (i = 0; i < USEC_PER_SEC; i++) {
+ if (readl(tcs_reg_addr(drv, reg, tcs_id)) == data)
+ return;
+ udelay(1);
+ }
+ pr_err("%s: error writing %#x to %d:%#x\n", drv->name,
+ data, tcs_id, reg);
}
/**
--
2.25.1
[PATCH AUTOSEL 5.8 17/72] blktrace: fix debugfs use after free
From: Luis Chamberlain
[ Upstream commit bad8e64fb19d3a0de5e564d9a7271c31bd684369 ]
On commit 6ac93117ab00 ("blktrace: use existing disk debugfs directory")
merged on v4.12 Omar fixed the original blktrace code for request-based
drivers (multiqueue). This however left in place a possible crash, if you
happen to abuse blktrace while racing to remove / add a device.
We used to use asynchronous removal of the request_queue, and with that
the issue was easier to reproduce. Now that we have reverted to
synchronous removal of the request_queue, the issue is still possible to
reproduce, its however just a bit more difficult.
We essentially run two instances of break-blktrace which add/remove
a loop device, and setup a blktrace and just never tear the blktrace
down. We do this twice in parallel. This is easily reproduced with the
script run_0004.sh from break-blktrace [0].
We can end up with two types of panics each reflecting where we
race, one a failed blktrace setup:
[ 252.426751] debugfs: Directory 'loop0' with parent 'block' already present!
[ 252.432265] BUG: kernel NULL pointer dereference, address: 00a0
[ 252.436592] #PF: supervisor write access in kernel mode
[ 252.439822] #PF: error_code(0x0002) - not-present page
[ 252.442967] PGD 0 P4D 0
[ 252.444656] Oops: 0002 [#1] SMP NOPTI
[ 252.446972] CPU: 10 PID: 1153 Comm: break-blktrace Tainted: GE
5.7.0-rc2-next-20200420+ #164
[ 252.452673] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.13.0-1 04/01/2014
[ 252.456343] RIP: 0010:down_write+0x15/0x40
[ 252.458146] Code: eb ca e8 ae 22 8d ff cc cc cc cc cc cc cc cc cc cc cc cc
cc cc 0f 1f 44 00 00 55 48 89 fd e8 52 db ff ff 31 c0 ba 01 00
00 00 48 0f b1 55 00 75 0f 48 8b 04 25 c0 8b 01 00 48 89
45 08 5d
[ 252.463638] RSP: 0018:a626415abcc8 EFLAGS: 00010246
[ 252.464950] RAX: RBX: 958c25f0f5c0 RCX: ff81
[ 252.466727] RDX: 0001 RSI: ff81 RDI: 00a0
[ 252.468482] RBP: 00a0 R08: R09: 0001
[ 252.470014] R10: R11: 958d1f9227ff R12:
[ 252.471473] R13: 958c25ea5380 R14: 8cce15f1 R15: 00a0
[ 252.473346] FS: 7f2e69dee540() GS:958c2fc8()
knlGS:
[ 252.475225] CS: 0010 DS: ES: CR0: 80050033
[ 252.476267] CR2: 00a0 CR3: 000427d10004 CR4: 00360ee0
[ 252.477526] DR0: DR1: DR2:
[ 252.478776] DR3: DR6: fffe0ff0 DR7: 0400
[ 252.479866] Call Trace:
[ 252.480322] simple_recursive_removal+0x4e/0x2e0
[ 252.481078] ? debugfs_remove+0x60/0x60
[ 252.481725] ? relay_destroy_buf+0x77/0xb0
[ 252.482662] debugfs_remove+0x40/0x60
[ 252.483518] blk_remove_buf_file_callback+0x5/0x10
[ 252.484328] relay_close_buf+0x2e/0x60
[ 252.484930] relay_open+0x1ce/0x2c0
[ 252.485520] do_blk_trace_setup+0x14f/0x2b0
[ 252.486187] __blk_trace_setup+0x54/0xb0
[ 252.486803] blk_trace_ioctl+0x90/0x140
[ 252.487423] ? do_sys_openat2+0x1ab/0x2d0
[ 252.488053] blkdev_ioctl+0x4d/0x260
[ 252.488636] block_ioctl+0x39/0x40
[ 252.489139] ksys_ioctl+0x87/0xc0
[ 252.489675] __x64_sys_ioctl+0x16/0x20
[ 252.490380] do_syscall_64+0x52/0x180
[ 252.491032] entry_SYSCALL_64_after_hwframe+0x44/0xa9
And the other on the device removal:
[ 128.528940] debugfs: Directory 'loop0' with parent 'block' already present!
[ 128.615325] BUG: kernel NULL pointer dereference, address: 00a0
[ 128.619537] #PF: supervisor write access in kernel mode
[ 128.622700] #PF: error_code(0x0002) - not-present page
[ 128.625842] PGD 0 P4D 0
[ 128.627585] Oops: 0002 [#1] SMP NOPTI
[ 128.629871] CPU: 12 PID: 544 Comm: break-blktrace Tainted: GE
5.7.0-rc2-next-20200420+ #164
[ 128.635595] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.13.0-1 04/01/2014
[ 128.640471] RIP: 0010:down_write+0x15/0x40
[ 128.643041] Code: eb ca e8 ae 22 8d ff cc cc cc cc cc cc cc cc cc cc cc cc
cc cc 0f 1f 44 00 00 55 48 89 fd e8 52 db ff ff 31 c0 ba 01 00
00 00 48 0f b1 55 00 75 0f 65 48 8b 04 25 c0 8b 01 00 48 89
45 08 5d
[ 128.650180] RSP: 0018:a9c3c05ebd78 EFLAGS: 00010246
[ 128.651820] RAX: RBX: 8ae9a6370240 RCX: ff81
[ 128.653942] RDX: 0001 RSI: ff81 RDI: 00a0
[ 128.655720] RBP: 00a0 R08: 0002 R09: 8ae9afd2d3d0
[ 128.657400] R10: 0056 R11: R12:
[ 128.659099] R13: R14: 0003 R15: 00a0
[ 128.660500] FS: 7febfd995540() GS:8ae9afd0()
knlGS:
[ 128.662204] CS: 0010 DS: ES: CR0: 80050033
[
[PATCH AUTOSEL 5.8 15/72] arm64: dts: qcom: msm8916: Replace invalid bias-pull-none property
From: Stephan Gerhold
[ Upstream commit 1b6a1a162defe649c5599d661b58ac64bb6f31b6 ]
msm8916-pins.dtsi specifies "bias-pull-none" for most of the audio
pin configurations. This was likely copied from the qcom kernel fork
where the same property was used for these audio pins.
However, "bias-pull-none" actually does not exist at all - not in
mainline and not in downstream. I can only guess that the original
intention was to configure "no pull", i.e. bias-disable.
Change it to that instead.
Fixes: 143bb9ad85b7 ("arm64: dts: qcom: add audio pinctrls")
Cc: Srinivas Kandagatla
Signed-off-by: Stephan Gerhold
Link: https://lore.kernel.org/r/20200605185916.318494-2-step...@gerhold.net
Signed-off-by: Bjorn Andersson
Signed-off-by: Sasha Levin
---
arch/arm64/boot/dts/qcom/msm8916-pins.dtsi | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/msm8916-pins.dtsi
b/arch/arm64/boot/dts/qcom/msm8916-pins.dtsi
index e9c00367f7fd0..5785bf0a807ce 100644
--- a/arch/arm64/boot/dts/qcom/msm8916-pins.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916-pins.dtsi
@@ -556,7 +556,7 @@ pinconf {
pins = "gpio63", "gpio64", "gpio65", "gpio66",
"gpio67", "gpio68";
drive-strength = <8>;
- bias-pull-none;
+ bias-disable;
};
};
cdc_pdm_lines_sus: pdm-lines-off {
@@ -585,7 +585,7 @@ pinconf {
pins = "gpio113", "gpio114", "gpio115",
"gpio116";
drive-strength = <8>;
- bias-pull-none;
+ bias-disable;
};
};
@@ -613,7 +613,7 @@ pinmux {
pinconf {
pins = "gpio110";
drive-strength = <8>;
- bias-pull-none;
+ bias-disable;
};
};
@@ -639,7 +639,7 @@ pinmux {
pinconf {
pins = "gpio116";
drive-strength = <8>;
- bias-pull-none;
+ bias-disable;
};
};
ext_mclk_tlmm_lines_sus: mclk-lines-off {
@@ -667,7 +667,7 @@ pinconf {
pins = "gpio112", "gpio117", "gpio118",
"gpio119";
drive-strength = <8>;
- bias-pull-none;
+ bias-disable;
};
};
ext_sec_tlmm_lines_sus: tlmm-lines-off {
--
2.25.1
[PATCH AUTOSEL 5.8 10/72] arm64: dts: rockchip: fix rk3368-lion gmac reset gpio
From: Heiko Stuebner
[ Upstream commit 2300e6dab473e93181cf76e4fe6671aa3d24c57b ]
The lion gmac node currently uses opposite active-values for the
gmac phy reset pin. The gpio-declaration uses active-high while the
separate snps,reset-active-low property marks the pin as active low.
While on the kernel side this works ok, other DT users may get
confused - as seen with uboot right now.
So bring this in line and make both properties match, similar to the
other Rockchip board.
Fixes: d99a02bcfa81 ("arm64: dts: rockchip: add RK3368-uQ7 (Lion) SoM")
Signed-off-by: Heiko Stuebner
Link: https://lore.kernel.org/r/20200607212909.920575-1-he...@sntech.de
Signed-off-by: Sasha Levin
---
arch/arm64/boot/dts/rockchip/rk3368-lion.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3368-lion.dtsi
b/arch/arm64/boot/dts/rockchip/rk3368-lion.dtsi
index e17311e090826..216aafd90e7f1 100644
--- a/arch/arm64/boot/dts/rockchip/rk3368-lion.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3368-lion.dtsi
@@ -156,7 +156,7 @@ {
pinctrl-0 = <_pins>;
snps,reset-active-low;
snps,reset-delays-us = <0 1 5>;
- snps,reset-gpio = < RK_PB3 GPIO_ACTIVE_HIGH>;
+ snps,reset-gpio = < RK_PB3 GPIO_ACTIVE_LOW>;
tx_delay = <0x10>;
rx_delay = <0x10>;
status = "okay";
--
2.25.1
[PATCH AUTOSEL 5.8 11/72] arm64: dts: rockchip: fix rk3399-puma vcc5v0-host gpio
From: Heiko Stuebner
[ Upstream commit 7a7184f6cfa9279f1a1c10a1845d247d7fad54ff ]
The puma vcc5v0_host regulator node currently uses opposite active-values
for the enable pin. The gpio-declaration uses active-high while the
separate enable-active-low property marks the pin as active low.
While on the kernel side this works ok, other DT users may get
confused - as seen with uboot right now.
So bring this in line and make both properties match, similar to the
gmac fix.
Fixes: 2c66fc34e945 ("arm64: dts: rockchip: add RK3399-Q7 (Puma) SoM")
Signed-off-by: Heiko Stuebner
Link: https://lore.kernel.org/r/20200604091239.424318-1-he...@sntech.de
Signed-off-by: Sasha Levin
---
arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi
b/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi
index 07694b196fdbe..063f59a420b65 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi
@@ -101,7 +101,7 @@ vcc3v3_sys: vcc3v3-sys {
vcc5v0_host: vcc5v0-host-regulator {
compatible = "regulator-fixed";
- gpio = < RK_PA3 GPIO_ACTIVE_HIGH>;
+ gpio = < RK_PA3 GPIO_ACTIVE_LOW>;
enable-active-low;
pinctrl-names = "default";
pinctrl-0 = <_host_en>;
--
2.25.1
[PATCH AUTOSEL 5.8 49/72] arm64: dts: meson: misc fixups for w400 dtsi
From: Christian Hewitt
[ Upstream commit 2fa17dd09533d5d83201be3229a28c1010a8ea3e ]
Current devices using the W400 dtsi show mmc tuning errors:
[12483.917391] mmc0: tuning execution failed: -5
[30535.551221] mmc0: tuning execution failed: -5
[35359.953671] mmc0: tuning execution failed: -5
[35561.875332] mmc0: tuning execution failed: -5
[61733.348709] mmc0: tuning execution failed: -5
Removing "sd-uhs-sdr50" from the SDIO node prevents this. We also add
keep-power-in-suspend to the SDIO node and fix an indentation.
Fixes: 3cb74db9b256 ("arm64: dts: meson: convert ugoos-am6 to common w400 dtsi")
Signed-off-by: Christian Hewitt
Signed-off-by: Kevin Hilman
Link:
https://lore.kernel.org/r/20200721013952.11635-1-christianshew...@gmail.com
Signed-off-by: Sasha Levin
---
arch/arm64/boot/dts/amlogic/meson-g12b-w400.dtsi | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-g12b-w400.dtsi
b/arch/arm64/boot/dts/amlogic/meson-g12b-w400.dtsi
index 98b70d216a6f3..2802ddbb83ac7 100644
--- a/arch/arm64/boot/dts/amlogic/meson-g12b-w400.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-g12b-w400.dtsi
@@ -336,9 +336,11 @@ _emmc_a {
bus-width = <4>;
cap-sd-highspeed;
- sd-uhs-sdr50;
max-frequency = <1>;
+ /* WiFi firmware requires power to be kept while in suspend */
+ keep-power-in-suspend;
+
non-removable;
disable-wp;
@@ -398,7 +400,7 @@ bluetooth {
shutdown-gpios = < GPIOX_17 GPIO_ACTIVE_HIGH>;
max-speed = <200>;
clocks = <>;
- clock-names = "lpo";
+ clock-names = "lpo";
};
};
--
2.25.1
[PATCH AUTOSEL 5.8 33/72] arm64: dts: renesas: Fix SD Card/eMMC interface device node names
From: Yoshihiro Shimoda
[ Upstream commit a6cb262af1e1adfa6287cb43f09021ee42beb21c ]
Fix the device node names as "mmc@".
Fixes: 663386c3e1aa ("arm64: dts: renesas: r8a774a1: Add SDHI nodes")
Fixes: 9b33e3001b67 ("arm64: dts: renesas: Initial r8a774b1 SoC device tree")
Fixes: 77223211f44d ("arm64: dts: renesas: r8a774c0: Add SDHI nodes")
Fixes: d9d67010e0c6 ("arm64: dts: r8a7795: Add SDHI support to dtsi")
Fixes: a513cf1e6457 ("arm64: dts: r8a7796: add SDHI nodes")
Fixes: 111cc9ace2b5 ("arm64: dts: renesas: r8a77961: Add SDHI nodes")
Fixes: f51746ad7d1f ("arm64: dts: renesas: Add Renesas R8A77961 SoC support")
Fixes: df863d6f95f5 ("arm64: dts: renesas: initial R8A77965 SoC device tree")
Fixes: 9aa3558a02f0 ("arm64: dts: renesas: ebisu: Add and enable SDHI device
nodes")
Fixes: 83f18749c2f6 ("arm64: dts: renesas: r8a77995: Add SDHI (MMC) support")
Signed-off-by: Yoshihiro Shimoda
Link:
https://lore.kernel.org/r/1594382634-13714-1-git-send-email-yoshihiro.shimoda...@renesas.com
Signed-off-by: Geert Uytterhoeven
Signed-off-by: Sasha Levin
---
arch/arm64/boot/dts/renesas/r8a774a1.dtsi | 8
arch/arm64/boot/dts/renesas/r8a774b1.dtsi | 8
arch/arm64/boot/dts/renesas/r8a774c0.dtsi | 6 +++---
arch/arm64/boot/dts/renesas/r8a77951.dtsi | 8
arch/arm64/boot/dts/renesas/r8a77960.dtsi | 8
arch/arm64/boot/dts/renesas/r8a77961.dtsi | 8
arch/arm64/boot/dts/renesas/r8a77965.dtsi | 8
arch/arm64/boot/dts/renesas/r8a77990.dtsi | 6 +++---
arch/arm64/boot/dts/renesas/r8a77995.dtsi | 2 +-
9 files changed, 31 insertions(+), 31 deletions(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
b/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
index a603d947970ec..16b059d7fd015 100644
--- a/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
@@ -2250,7 +2250,7 @@ usb2_phy1: usb-phy@ee0a0200 {
status = "disabled";
};
- sdhi0: sd@ee10 {
+ sdhi0: mmc@ee10 {
compatible = "renesas,sdhi-r8a774a1",
"renesas,rcar-gen3-sdhi";
reg = <0 0xee10 0 0x2000>;
@@ -2262,7 +2262,7 @@ sdhi0: sd@ee10 {
status = "disabled";
};
- sdhi1: sd@ee12 {
+ sdhi1: mmc@ee12 {
compatible = "renesas,sdhi-r8a774a1",
"renesas,rcar-gen3-sdhi";
reg = <0 0xee12 0 0x2000>;
@@ -2274,7 +2274,7 @@ sdhi1: sd@ee12 {
status = "disabled";
};
- sdhi2: sd@ee14 {
+ sdhi2: mmc@ee14 {
compatible = "renesas,sdhi-r8a774a1",
"renesas,rcar-gen3-sdhi";
reg = <0 0xee14 0 0x2000>;
@@ -2286,7 +2286,7 @@ sdhi2: sd@ee14 {
status = "disabled";
};
- sdhi3: sd@ee16 {
+ sdhi3: mmc@ee16 {
compatible = "renesas,sdhi-r8a774a1",
"renesas,rcar-gen3-sdhi";
reg = <0 0xee16 0 0x2000>;
diff --git a/arch/arm64/boot/dts/renesas/r8a774b1.dtsi
b/arch/arm64/boot/dts/renesas/r8a774b1.dtsi
index 1e51855c7cd38..6db8b6a4d191b 100644
--- a/arch/arm64/boot/dts/renesas/r8a774b1.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a774b1.dtsi
@@ -2108,7 +2108,7 @@ usb2_phy1: usb-phy@ee0a0200 {
status = "disabled";
};
- sdhi0: sd@ee10 {
+ sdhi0: mmc@ee10 {
compatible = "renesas,sdhi-r8a774b1",
"renesas,rcar-gen3-sdhi";
reg = <0 0xee10 0 0x2000>;
@@ -2120,7 +2120,7 @@ sdhi0: sd@ee10 {
status = "disabled";
};
- sdhi1: sd@ee12 {
+ sdhi1: mmc@ee12 {
compatible = "renesas,sdhi-r8a774b1",
"renesas,rcar-gen3-sdhi";
reg = <0 0xee12 0 0x2000>;
@@ -2132,7 +2132,7 @@ sdhi1: sd@ee12 {
status = "disabled";
};
- sdhi2: sd@ee14 {
+ sdhi2: mmc@ee14 {
compatible = "renesas,sdhi-r8a774b1",
"renesas,rcar-gen3-sdhi";
reg = <0 0xee14 0 0x2000>;
@@ -2144,7 +2144,7 @@ sdhi2: sd@ee14 {
status = "disabled";
};
- sdhi3: sd@ee16 {
+ sdhi3: mmc@ee16 {
compatible = "renesas,sdhi-r8a774b1",
"renesas,rcar-gen3-sdhi";
reg = <0
[PATCH AUTOSEL 5.8 37/72] reset: intel: fix a compile warning about REG_OFFSET redefined
From: Dejin Zheng
[ Upstream commit 308646785e51976dea7e20d29a1842d14bf0b9bd ]
kernel test robot reports a compile warning about REG_OFFSET redefined
in the reset-intel-gw.c after merging commit e44ab4e14d6f4 ("regmap:
Simplify implementation of the regmap_read_poll_timeout() macro"). the
warning is like that:
drivers/reset/reset-intel-gw.c:18:0: warning: "REG_OFFSET" redefined
#define REG_OFFSET GENMASK(31, 16)
In file included from ./arch/arm/mach-ixp4xx/include/mach/hardware.h:30:0,
from ./arch/arm/mach-ixp4xx/include/mach/io.h:15,
from ./arch/arm/include/asm/io.h:198,
from ./include/linux/io.h:13,
from ./include/linux/iopoll.h:14,
from ./include/linux/regmap.h:20,
from drivers/reset/reset-intel-gw.c:12:
./arch/arm/mach-ixp4xx/include/mach/platform.h:25:0: note: this is the location
of the previous definition
#define REG_OFFSET 3
Reported-by: kernel test robot
Fixes: c9aef213e38cde ("reset: intel: Add system reset controller driver")
Signed-off-by: Dejin Zheng
Reviewed-by: Philipp Zabel
Signed-off-by: Philipp Zabel
Signed-off-by: Sasha Levin
---
drivers/reset/reset-intel-gw.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/reset/reset-intel-gw.c b/drivers/reset/reset-intel-gw.c
index 854238444616b..effc177db80af 100644
--- a/drivers/reset/reset-intel-gw.c
+++ b/drivers/reset/reset-intel-gw.c
@@ -15,9 +15,9 @@
#define RCU_RST_STAT 0x0024
#define RCU_RST_REQ0x0048
-#define REG_OFFSET GENMASK(31, 16)
-#define BIT_OFFSET GENMASK(15, 8)
-#define STAT_BIT_OFFSETGENMASK(7, 0)
+#define REG_OFFSET_MASKGENMASK(31, 16)
+#define BIT_OFFSET_MASKGENMASK(15, 8)
+#define STAT_BIT_OFFSET_MASK GENMASK(7, 0)
#define to_reset_data(x) container_of(x, struct intel_reset_data, rcdev)
@@ -51,11 +51,11 @@ static u32 id_to_reg_and_bit_offsets(struct
intel_reset_data *data,
unsigned long id, u32 *rst_req,
u32 *req_bit, u32 *stat_bit)
{
- *rst_req = FIELD_GET(REG_OFFSET, id);
- *req_bit = FIELD_GET(BIT_OFFSET, id);
+ *rst_req = FIELD_GET(REG_OFFSET_MASK, id);
+ *req_bit = FIELD_GET(BIT_OFFSET_MASK, id);
if (data->soc_data->legacy)
- *stat_bit = FIELD_GET(STAT_BIT_OFFSET, id);
+ *stat_bit = FIELD_GET(STAT_BIT_OFFSET_MASK, id);
else
*stat_bit = *req_bit;
@@ -141,14 +141,14 @@ static int intel_reset_xlate(struct reset_controller_dev
*rcdev,
if (spec->args[1] > 31)
return -EINVAL;
- id = FIELD_PREP(REG_OFFSET, spec->args[0]);
- id |= FIELD_PREP(BIT_OFFSET, spec->args[1]);
+ id = FIELD_PREP(REG_OFFSET_MASK, spec->args[0]);
+ id |= FIELD_PREP(BIT_OFFSET_MASK, spec->args[1]);
if (data->soc_data->legacy) {
if (spec->args[2] > 31)
return -EINVAL;
- id |= FIELD_PREP(STAT_BIT_OFFSET, spec->args[2]);
+ id |= FIELD_PREP(STAT_BIT_OFFSET_MASK, spec->args[2]);
}
return id;
@@ -210,11 +210,11 @@ static int intel_reset_probe(struct platform_device *pdev)
if (ret)
return ret;
- data->reboot_id = FIELD_PREP(REG_OFFSET, rb_id[0]);
- data->reboot_id |= FIELD_PREP(BIT_OFFSET, rb_id[1]);
+ data->reboot_id = FIELD_PREP(REG_OFFSET_MASK, rb_id[0]);
+ data->reboot_id |= FIELD_PREP(BIT_OFFSET_MASK, rb_id[1]);
if (data->soc_data->legacy)
- data->reboot_id |= FIELD_PREP(STAT_BIT_OFFSET, rb_id[2]);
+ data->reboot_id |= FIELD_PREP(STAT_BIT_OFFSET_MASK, rb_id[2]);
data->restart_nb.notifier_call =intel_reset_restart_handler;
data->restart_nb.priority = 128;
--
2.25.1
[PATCH AUTOSEL 5.8 45/72] tpm: Require that all digests are present in TCG_PCR_EVENT2 structures
From: Tyler Hicks
[ Upstream commit 7f3d176f5f7e3f0477bf82df0f600fcddcdcc4e4 ]
Require that the TCG_PCR_EVENT2.digests.count value strictly matches the
value of TCG_EfiSpecIdEvent.numberOfAlgorithms in the event field of the
TCG_PCClientPCREvent event log header. Also require that
TCG_EfiSpecIdEvent.numberOfAlgorithms is non-zero.
The TCG PC Client Platform Firmware Profile Specification section 9.1
(Family "2.0", Level 00 Revision 1.04) states:
For each Hash algorithm enumerated in the TCG_PCClientPCREvent entry,
there SHALL be a corresponding digest in all TCG_PCR_EVENT2 structures.
Note: This includes EV_NO_ACTION events which do not extend the PCR.
Section 9.4.5.1 provides this description of
TCG_EfiSpecIdEvent.numberOfAlgorithms:
The number of Hash algorithms in the digestSizes field. This field MUST
be set to a value of 0x01 or greater.
Enforce these restrictions, as required by the above specification, in
order to better identify and ignore invalid sequences of bytes at the
end of an otherwise valid TPM2 event log. Firmware doesn't always have
the means necessary to inform the kernel of the actual event log size so
the kernel's event log parsing code should be stringent when parsing the
event log for resiliency against firmware bugs. This is true, for
example, when firmware passes the event log to the kernel via a reserved
memory region described in device tree.
POWER and some ARM systems use the "linux,sml-base" and "linux,sml-size"
device tree properties to describe the memory region used to pass the
event log from firmware to the kernel. Unfortunately, the
"linux,sml-size" property describes the size of the entire reserved
memory region rather than the size of the event long within the memory
region and the event log format does not include information describing
the size of the event log.
tpm_read_log_of(), in drivers/char/tpm/eventlog/of.c, is where the
"linux,sml-size" property is used. At the end of that function,
log->bios_event_log_end is pointing at the end of the reserved memory
region. That's typically 0x1 bytes offset from "linux,sml-base",
depending on what's defined in the device tree source.
The firmware event log only fills a portion of those 0x1 bytes and
the rest of the memory region should be zeroed out by firmware. Even in
the case of a properly zeroed bytes in the remainder of the memory
region, the only thing allowing the kernel's event log parser to detect
the end of the event log is the following conditional in
__calc_tpm2_event_size():
if (event_type == 0 && event_field->event_size == 0)
size = 0;
If that wasn't there, __calc_tpm2_event_size() would think that a 16
byte sequence of zeroes, following an otherwise valid event log, was
a valid event.
However, problems can occur if a single bit is set in the offset
corresponding to either the TCG_PCR_EVENT2.eventType or
TCG_PCR_EVENT2.eventSize fields, after the last valid event log entry.
This could confuse the parser into thinking that an additional entry is
present in the event log and exposing this invalid entry to userspace in
the /sys/kernel/security/tpm0/binary_bios_measurements file. Such
problems have been seen if firmware does not fully zero the memory
region upon a warm reboot.
This patch significantly raises the bar on how difficult it is for
stale/invalid memory to confuse the kernel's event log parser but
there's still, ultimately, a reliance on firmware to properly initialize
the remainder of the memory region reserved for the event log as the
parser cannot be expected to detect a stale but otherwise properly
formatted firmware event log entry.
Fixes: fd5c78694f3f ("tpm: fix handling of the TPM 2.0 event logs")
Signed-off-by: Tyler Hicks
Reviewed-by: Jarkko Sakkinen
Signed-off-by: Jarkko Sakkinen
Signed-off-by: Sasha Levin
---
include/linux/tpm_eventlog.h | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/include/linux/tpm_eventlog.h b/include/linux/tpm_eventlog.h
index 64356b199e945..739ba9a03ec16 100644
--- a/include/linux/tpm_eventlog.h
+++ b/include/linux/tpm_eventlog.h
@@ -211,9 +211,16 @@ static inline int __calc_tpm2_event_size(struct
tcg_pcr_event2_head *event,
efispecid = (struct tcg_efi_specid_event_head *)event_header->event;
- /* Check if event is malformed. */
+ /*
+* Perform validation of the event in order to identify malformed
+* events. This function may be asked to parse arbitrary byte sequences
+* immediately following a valid event log. The caller expects this
+* function to recognize that the byte sequence is not a valid event
+* and to return an event size of 0.
+*/
if (memcmp(efispecid->signature, TCG_SPECID_SIG,
- sizeof(TCG_SPECID_SIG)) || count > efispecid->num_algs) {
+ sizeof(TCG_SPECID_SIG)) ||
+ !efispecid->num_algs || count != efispecid->num_algs) {
size =
[PATCH AUTOSEL 5.8 42/72] spi: dw-dma: Fix Tx DMA channel working too fast
From: Serge Semin
[ Upstream commit affe93dd5b35bb0e7b0aa0505ae432dd0ac72c3f ]
It turns out having a Rx DMA channel serviced with higher priority than
a Tx DMA channel is not enough to provide a well balanced DMA-based SPI
transfer interface. There might still be moments when the Tx DMA channel
is occasionally handled faster than the Rx DMA channel. That in its turn
will eventually cause the SPI Rx FIFO overflow if SPI bus speed is high
enough to fill the SPI Rx FIFO in before it's cleared by the Rx DMA
channel. That's why having the DMA-based SPI Tx interface too optimized
is the errors prone, so the commit 0b2b66514fc9 ("spi: dw: Use DMA max
burst to set the request thresholds") though being perfectly normal from
the standard functionality point of view implicitly introduced the problem
described above. In order to fix that the Tx DMA activity is intentionally
slowed down by limiting the SPI Tx FIFO depth with a value twice bigger
than the Tx burst length calculated earlier by the
dw_spi_dma_maxburst_init() method.
Fixes: 0b2b66514fc9 ("spi: dw: Use DMA max burst to set the request thresholds")
Signed-off-by: Serge Semin
Reviewed-by: Andy Shevchenko
Cc: Andy Shevchenko
Cc: Alexey Malahov
Cc: Feng Tang
Link:
https://lore.kernel.org/r/20200721203951.2159-1-sergey.se...@baikalelectronics.ru
Signed-off-by: Mark Brown
Signed-off-by: Sasha Levin
---
drivers/spi/spi-dw-dma.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/spi/spi-dw-dma.c b/drivers/spi/spi-dw-dma.c
index 5986c520b1965..bb390ff67d1d8 100644
--- a/drivers/spi/spi-dw-dma.c
+++ b/drivers/spi/spi-dw-dma.c
@@ -372,8 +372,20 @@ static int dw_spi_dma_setup(struct dw_spi *dws, struct
spi_transfer *xfer)
{
u16 imr = 0, dma_ctrl = 0;
+ /*
+* Having a Rx DMA channel serviced with higher priority than a Tx DMA
+* channel might not be enough to provide a well balanced DMA-based
+* SPI transfer interface. There might still be moments when the Tx DMA
+* channel is occasionally handled faster than the Rx DMA channel.
+* That in its turn will eventually cause the SPI Rx FIFO overflow if
+* SPI bus speed is high enough to fill the SPI Rx FIFO in before it's
+* cleared by the Rx DMA channel. In order to fix the problem the Tx
+* DMA activity is intentionally slowed down by limiting the SPI Tx
+* FIFO depth with a value twice bigger than the Tx burst length
+* calculated earlier by the dw_spi_dma_maxburst_init() method.
+*/
dw_writel(dws, DW_SPI_DMARDLR, dws->rxburst - 1);
- dw_writel(dws, DW_SPI_DMATDLR, dws->fifo_len - dws->txburst);
+ dw_writel(dws, DW_SPI_DMATDLR, dws->txburst);
if (xfer->tx_buf)
dma_ctrl |= SPI_DMA_TDMAE;
--
2.25.1
[PATCH AUTOSEL 5.8 43/72] spi: lantiq: fix: Rx overflow error in full duplex mode
From: Dilip Kota
[ Upstream commit 661ccf2b3f1360be50242726f7c26ced6a9e7d52 ]
In full duplex mode, rx overflow error is observed. To overcome the error,
wait until the complete data got received and proceed further.
Fixes: 17f84b793c01 ("spi: lantiq-ssc: add support for Lantiq SSC SPI
controller")
Signed-off-by: Dilip Kota
Link:
https://lore.kernel.org/r/efb650b0faa49a00788c4e0ca8ef7196bdba851d.1594957019.git.eswara.k...@linux.intel.com
Signed-off-by: Mark Brown
Signed-off-by: Sasha Levin
---
drivers/spi/spi-lantiq-ssc.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/spi/spi-lantiq-ssc.c b/drivers/spi/spi-lantiq-ssc.c
index 1fd7ee53d4510..44600fb71c484 100644
--- a/drivers/spi/spi-lantiq-ssc.c
+++ b/drivers/spi/spi-lantiq-ssc.c
@@ -184,6 +184,7 @@ struct lantiq_ssc_spi {
unsigned inttx_fifo_size;
unsigned intrx_fifo_size;
unsigned intbase_cs;
+ unsigned intfdx_tx_level;
};
static u32 lantiq_ssc_readl(const struct lantiq_ssc_spi *spi, u32 reg)
@@ -481,6 +482,7 @@ static void tx_fifo_write(struct lantiq_ssc_spi *spi)
u32 data;
unsigned int tx_free = tx_fifo_free(spi);
+ spi->fdx_tx_level = 0;
while (spi->tx_todo && tx_free) {
switch (spi->bits_per_word) {
case 2 ... 8:
@@ -509,6 +511,7 @@ static void tx_fifo_write(struct lantiq_ssc_spi *spi)
lantiq_ssc_writel(spi, data, LTQ_SPI_TB);
tx_free--;
+ spi->fdx_tx_level++;
}
}
@@ -520,6 +523,13 @@ static void rx_fifo_read_full_duplex(struct lantiq_ssc_spi
*spi)
u32 data;
unsigned int rx_fill = rx_fifo_level(spi);
+ /*
+* Wait until all expected data to be shifted in.
+* Otherwise, rx overrun may occur.
+*/
+ while (rx_fill != spi->fdx_tx_level)
+ rx_fill = rx_fifo_level(spi);
+
while (rx_fill) {
data = lantiq_ssc_readl(spi, LTQ_SPI_RB);
--
2.25.1
[PATCH AUTOSEL 5.8 40/72] ARM: dts: sunxi: bananapi-m2-plus-v1.2: Fix CPU supply voltages
From: Chen-Yu Tsai
[ Upstream commit e4dae01bf08b754de79072441c357737220b873f ]
The Bananapi M2+ uses a GPIO line to change the effective resistance of
the CPU supply regulator's feedback resistor network. The voltages
described in the device tree were given directly by the vendor. This
turns out to be slightly off compared to the real values.
The updated voltages are based on calculations of the feedback resistor
network, and verified down to three decimal places with a multi-meter.
Fixes: 6eeb4180d4b9 ("ARM: dts: sunxi: h3-h5: Add Bananapi M2+ v1.2 device
trees")
Signed-off-by: Chen-Yu Tsai
Signed-off-by: Maxime Ripard
Link: https://lore.kernel.org/r/20200717160053.31191-4-w...@kernel.org
Signed-off-by: Sasha Levin
---
arch/arm/boot/dts/sunxi-bananapi-m2-plus-v1.2.dtsi | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/sunxi-bananapi-m2-plus-v1.2.dtsi
b/arch/arm/boot/dts/sunxi-bananapi-m2-plus-v1.2.dtsi
index a628b5ee72b65..235994a4a2ebb 100644
--- a/arch/arm/boot/dts/sunxi-bananapi-m2-plus-v1.2.dtsi
+++ b/arch/arm/boot/dts/sunxi-bananapi-m2-plus-v1.2.dtsi
@@ -16,12 +16,12 @@ reg_vdd_cpux: vdd-cpux {
regulator-type = "voltage";
regulator-boot-on;
regulator-always-on;
- regulator-min-microvolt = <110>;
- regulator-max-microvolt = <130>;
+ regulator-min-microvolt = <1108475>;
+ regulator-max-microvolt = <1308475>;
regulator-ramp-delay = <50>; /* 4ms */
gpios = <_pio 0 1 GPIO_ACTIVE_HIGH>; /* PL1 */
gpios-states = <0x1>;
- states = <110 0>, <130 1>;
+ states = <1108475 0>, <1308475 1>;
};
};
--
2.25.1
[PATCH AUTOSEL 5.8 38/72] ARM: dts: at91: sama5d3_xplained: change phy-mode
From: Alexandre Belloni
[ Upstream commit 7dbf4bbf1c320d82058878bd44805724d171e1e8 ]
Since commit bcf3440c6dd7 ("net: phy: micrel: add phy-mode support for the
KSZ9031 PHY"), networking is broken on sama5d3 xplained.
The device tree has phy-mode = "rgmii" and this worked before, because
KSZ9031 PHY started with default RGMII internal delays configuration (TX
off, RX on 1.2 ns) and MAC provided TX delay. After above commit, the
KSZ9031 PHY starts handling phy mode properly and disables RX delay, as
result networking is become broken.
Fix it by switching to phy-mode = "rgmii-rxid" to reflect previous
behavior.
Fixes: bcf3440c6dd78bfe ("net: phy: micrel: add phy-mode support for the
KSZ9031 PHY")
Signed-off-by: Alexandre Belloni
Link:
https://lore.kernel.org/r/20200717233644.841080-1-alexandre.bell...@bootlin.com
Signed-off-by: Sasha Levin
---
arch/arm/boot/dts/at91-sama5d3_xplained.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/at91-sama5d3_xplained.dts
b/arch/arm/boot/dts/at91-sama5d3_xplained.dts
index 61f068a7b362a..7abf555cd2fe3 100644
--- a/arch/arm/boot/dts/at91-sama5d3_xplained.dts
+++ b/arch/arm/boot/dts/at91-sama5d3_xplained.dts
@@ -128,7 +128,7 @@ vddana_reg: LDO_REG2 {
};
macb0: ethernet@f0028000 {
- phy-mode = "rgmii";
+ phy-mode = "rgmii-rxid";
#address-cells = <1>;
#size-cells = <0>;
status = "okay";
--
2.25.1
[PATCH AUTOSEL 5.8 32/72] ARM: dts: gose: Fix ports node name for adv7180
From: Niklas Söderlund
[ Upstream commit d344234abde938ae1062edb6c05852b0bafb4a03 ]
When adding the adv7180 device node the ports node was misspelled as
port, fix this.
Fixes: 8cae359049a88b75 ("ARM: dts: gose: add composite video input")
Signed-off-by: Niklas Söderlund
Link:
https://lore.kernel.org/r/20200704155856.3037010-2-niklas.soderlund+rene...@ragnatech.se
Signed-off-by: Geert Uytterhoeven
Signed-off-by: Sasha Levin
---
arch/arm/boot/dts/r8a7793-gose.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/r8a7793-gose.dts
b/arch/arm/boot/dts/r8a7793-gose.dts
index 79baf06019f5a..a378b54867bb4 100644
--- a/arch/arm/boot/dts/r8a7793-gose.dts
+++ b/arch/arm/boot/dts/r8a7793-gose.dts
@@ -336,7 +336,7 @@ composite-in@20 {
reg = <0x20>;
remote = <>;
- port {
+ ports {
#address-cells = <1>;
#size-cells = <0>;
--
2.25.1
[PATCH AUTOSEL 5.8 41/72] ARM: dts: stm32: Fix spi4 pins in stm32mp15-pinctrl
From: Patrick Delaunay
[ Upstream commit 4fe663890ac5b3b099f458b20cce13fe8efec12b ]
Move spi4_pins_a nodes from pinctrl_z to pinctrl as the associated pins
are not in BANK Z.
Fixes: 498a7014989d ("ARM: dts: stm32: Add missing pinctrl entries for
STM32MP15")
Signed-off-by: Patrick Delaunay
Reviewed-by: Manivannan Sadhasivam
Signed-off-by: Alexandre Torgue
Signed-off-by: Sasha Levin
---
arch/arm/boot/dts/stm32mp15-pinctrl.dtsi | 28
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/arch/arm/boot/dts/stm32mp15-pinctrl.dtsi
b/arch/arm/boot/dts/stm32mp15-pinctrl.dtsi
index 49132921feeb9..cc505458da2fd 100644
--- a/arch/arm/boot/dts/stm32mp15-pinctrl.dtsi
+++ b/arch/arm/boot/dts/stm32mp15-pinctrl.dtsi
@@ -1654,6 +1654,20 @@ pins2 {
};
};
+ spi4_pins_a: spi4-0 {
+ pins {
+ pinmux = , /* SPI4_SCK */
+; /* SPI4_MOSI */
+ bias-disable;
+ drive-push-pull;
+ slew-rate = <1>;
+ };
+ pins2 {
+ pinmux = ; /* SPI4_MISO */
+ bias-disable;
+ };
+ };
+
usart2_pins_a: usart2-0 {
pins1 {
pinmux = , /* USART2_TX */
@@ -1776,18 +1790,4 @@ pins2 {
bias-disable;
};
};
-
- spi4_pins_a: spi4-0 {
- pins {
- pinmux = , /* SPI4_SCK */
-; /* SPI4_MOSI */
- bias-disable;
- drive-push-pull;
- slew-rate = <1>;
- };
- pins2 {
- pinmux = ; /* SPI4_MISO */
- bias-disable;
- };
- };
};
--
2.25.1
[PATCH AUTOSEL 5.8 50/72] arm64: dts: meson: fix mmc0 tuning error on Khadas VIM3
From: Christian Hewitt
[ Upstream commit f1bb924e8f5b50752a80fa5b48c43003680a7b64 ]
Similar to other G12B devices using the W400 dtsi, I see reports of mmc0
tuning errors on VIM3 after a few hours uptime:
[12483.917391] mmc0: tuning execution failed: -5
[30535.551221] mmc0: tuning execution failed: -5
[35359.953671] mmc0: tuning execution failed: -5
[35561.875332] mmc0: tuning execution failed: -5
[61733.348709] mmc0: tuning execution failed: -5
I do not see the same on VIM3L, so remove sd-uhs-sdr50 from the common dtsi
to silence the error, then (re)add it to the VIM3L dts.
Fixes: 4f26cc1c96c9 ("arm64: dts: khadas-vim3: move common nodes into
meson-khadas-vim3.dtsi")
Fixes: 700ab8d83927 ("arm64: dts: khadas-vim3: add support for the SM1 based
VIM3L")
Signed-off-by: Christian Hewitt
Signed-off-by: Kevin Hilman
Link:
https://lore.kernel.org/r/20200721015950.11816-1-christianshew...@gmail.com
Signed-off-by: Sasha Levin
---
arch/arm64/boot/dts/amlogic/meson-khadas-vim3.dtsi | 1 -
arch/arm64/boot/dts/amlogic/meson-sm1-khadas-vim3l.dts | 4
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-khadas-vim3.dtsi
b/arch/arm64/boot/dts/amlogic/meson-khadas-vim3.dtsi
index 1ef1e3672b967..ff5ba85b7562e 100644
--- a/arch/arm64/boot/dts/amlogic/meson-khadas-vim3.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-khadas-vim3.dtsi
@@ -270,7 +270,6 @@ _emmc_a {
bus-width = <4>;
cap-sd-highspeed;
- sd-uhs-sdr50;
max-frequency = <1>;
non-removable;
diff --git a/arch/arm64/boot/dts/amlogic/meson-sm1-khadas-vim3l.dts
b/arch/arm64/boot/dts/amlogic/meson-sm1-khadas-vim3l.dts
index dbbf29a0dbf6d..026b21708b078 100644
--- a/arch/arm64/boot/dts/amlogic/meson-sm1-khadas-vim3l.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-sm1-khadas-vim3l.dts
@@ -88,6 +88,10 @@ {
status = "okay";
};
+_emmc_a {
+ sd-uhs-sdr50;
+};
+
{
phys = <_phy0>, <_phy1>;
phy-names = "usb2-phy0", "usb2-phy1";
--
2.25.1
[PATCH AUTOSEL 5.8 28/72] m68k: mac: Don't send IOP message until channel is idle
From: Finn Thain
[ Upstream commit aeb445bf2194d83e12e85bf5c65baaf1f093bd8f ]
In the following sequence of calls, iop_do_send() gets called when the
"send" channel is not in the IOP_MSG_IDLE state:
iop_ism_irq()
iop_handle_send()
(msg->handler)()
iop_send_message()
iop_do_send()
Avoid this by testing the channel state before calling iop_do_send().
When sending, and iop_send_queue is empty, call iop_do_send() because
the channel is idle. If iop_send_queue is not empty, iop_do_send() will
get called later by iop_handle_send().
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Finn Thain
Tested-by: Stan Johnson
Cc: Joshua Thompson
Link:
https://lore.kernel.org/r/6d667c39e53865661fa5a48f16829d18ed8abe54.1590880333.git.fth...@telegraphics.com.au
Signed-off-by: Geert Uytterhoeven
Signed-off-by: Sasha Levin
---
arch/m68k/mac/iop.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/arch/m68k/mac/iop.c b/arch/m68k/mac/iop.c
index d3775afb0f076..754f6478c30d0 100644
--- a/arch/m68k/mac/iop.c
+++ b/arch/m68k/mac/iop.c
@@ -415,7 +415,8 @@ static void iop_handle_send(uint iop_num, uint chan)
msg->status = IOP_MSGSTATUS_UNUSED;
msg = msg->next;
iop_send_queue[iop_num][chan] = msg;
- if (msg) iop_do_send(msg);
+ if (msg && iop_readb(iop, IOP_ADDR_SEND_STATE + chan) == IOP_MSG_IDLE)
+ iop_do_send(msg);
}
/*
@@ -489,16 +490,12 @@ int iop_send_message(uint iop_num, uint chan, void
*privdata,
if (!(q = iop_send_queue[iop_num][chan])) {
iop_send_queue[iop_num][chan] = msg;
+ iop_do_send(msg);
} else {
while (q->next) q = q->next;
q->next = msg;
}
- if (iop_readb(iop_base[iop_num],
- IOP_ADDR_SEND_STATE + chan) == IOP_MSG_IDLE) {
- iop_do_send(msg);
- }
-
return 0;
}
--
2.25.1
[PATCH AUTOSEL 5.8 35/72] ARM: at91: pm: add missing put_device() call in at91_pm_sram_init()
From: yu kuai
[ Upstream commit f87a4f022c44e5b87e842a9f3e644fba87e8385f ]
if of_find_device_by_node() succeed, at91_pm_sram_init() doesn't have
a corresponding put_device(). Thus add a jump target to fix the exception
handling for this function implementation.
Fixes: d2e467905596 ("ARM: at91: pm: use the mmio-sram pool to access SRAM")
Signed-off-by: yu kuai
Signed-off-by: Alexandre Belloni
Link: https://lore.kernel.org/r/20200604123301.3905837-1-yuku...@huawei.com
Signed-off-by: Sasha Levin
---
arch/arm/mach-at91/pm.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
index 074bde64064e4..2aab043441e8f 100644
--- a/arch/arm/mach-at91/pm.c
+++ b/arch/arm/mach-at91/pm.c
@@ -592,13 +592,13 @@ static void __init at91_pm_sram_init(void)
sram_pool = gen_pool_get(>dev, NULL);
if (!sram_pool) {
pr_warn("%s: sram pool unavailable!\n", __func__);
- return;
+ goto out_put_device;
}
sram_base = gen_pool_alloc(sram_pool, at91_pm_suspend_in_sram_sz);
if (!sram_base) {
pr_warn("%s: unable to alloc sram!\n", __func__);
- return;
+ goto out_put_device;
}
sram_pbase = gen_pool_virt_to_phys(sram_pool, sram_base);
@@ -606,12 +606,17 @@ static void __init at91_pm_sram_init(void)
at91_pm_suspend_in_sram_sz, false);
if (!at91_suspend_sram_fn) {
pr_warn("SRAM: Could not map\n");
- return;
+ goto out_put_device;
}
/* Copy the pm suspend handler to SRAM */
at91_suspend_sram_fn = fncpy(at91_suspend_sram_fn,
_pm_suspend_in_sram, at91_pm_suspend_in_sram_sz);
+ return;
+
+out_put_device:
+ put_device(>dev);
+ return;
}
static bool __init at91_is_pm_mode_active(int pm_mode)
--
2.25.1
[PATCH AUTOSEL 5.8 69/72] nvme-multipath: fix logic for non-optimized paths
From: Martin Wilck
[ Upstream commit 3f6e3246db0e6f92e784965d9d0edb8abe6c6b74 ]
Handle the special case where we have exactly one optimized path,
which we should keep using in this case.
Fixes: 75c10e732724 ("nvme-multipath: round-robin I/O policy")
Signed off-by: Martin Wilck
Signed-off-by: Hannes Reinecke
Reviewed-by: Sagi Grimberg
Signed-off-by: Christoph Hellwig
Signed-off-by: Sasha Levin
---
drivers/nvme/host/multipath.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/nvme/host/multipath.c b/drivers/nvme/host/multipath.c
index 66509472fe06a..fe8f7f123fac7 100644
--- a/drivers/nvme/host/multipath.c
+++ b/drivers/nvme/host/multipath.c
@@ -246,6 +246,12 @@ static struct nvme_ns *nvme_round_robin_path(struct
nvme_ns_head *head,
fallback = ns;
}
+ /* No optimized path found, re-check the current path */
+ if (!nvme_path_is_disabled(old) &&
+ old->ana_state == NVME_ANA_OPTIMIZED) {
+ found = old;
+ goto out;
+ }
if (!fallback)
return NULL;
found = fallback;
--
2.25.1
[PATCH AUTOSEL 5.8 65/72] irqchip/irq-bcm7038-l1: Guard uses of cpu_logical_map
From: Florian Fainelli
[ Upstream commit 9808357ff2e5bfe1e0dcafef5e78cc5b617a7078 ]
cpu_logical_map is only defined for CONFIG_SMP builds, when we are in an
UP configuration, the boot CPU is 0.
Fixes: 6468fc18b006 ("irqchip/irq-bcm7038-l1: Add PM support")
Reported-by: kernel test robot
Signed-off-by: Florian Fainelli
Signed-off-by: Marc Zyngier
Link: https://lore.kernel.org/r/20200724184157.29150-1-f.faine...@gmail.com
Signed-off-by: Sasha Levin
---
drivers/irqchip/irq-bcm7038-l1.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/irqchip/irq-bcm7038-l1.c b/drivers/irqchip/irq-bcm7038-l1.c
index fd7c537fb42ac..4127eeab10af1 100644
--- a/drivers/irqchip/irq-bcm7038-l1.c
+++ b/drivers/irqchip/irq-bcm7038-l1.c
@@ -327,7 +327,11 @@ static int bcm7038_l1_suspend(void)
u32 val;
/* Wakeup interrupt should only come from the boot cpu */
+#ifdef CONFIG_SMP
boot_cpu = cpu_logical_map(0);
+#else
+ boot_cpu = 0;
+#endif
list_for_each_entry(intc, _l1_intcs_list, list) {
for (word = 0; word < intc->n_words; word++) {
@@ -347,7 +351,11 @@ static void bcm7038_l1_resume(void)
struct bcm7038_l1_chip *intc;
int boot_cpu, word;
+#ifdef CONFIG_SMP
boot_cpu = cpu_logical_map(0);
+#else
+ boot_cpu = 0;
+#endif
list_for_each_entry(intc, _l1_intcs_list, list) {
for (word = 0; word < intc->n_words; word++) {
--
2.25.1
[PATCH AUTOSEL 5.8 60/72] irqchip/loongson-htvec: Check return value of irq_domain_translate_onecell()
From: Tiezhu Yang
[ Upstream commit dbec37048d27cee36e103e113b5f9b1852bfe997 ]
Check the return value of irq_domain_translate_onecell() due to
it may returns -EINVAL if failed.
Fixes: 818e915fbac5 ("irqchip: Add Loongson HyperTransport Vector support")
Signed-off-by: Tiezhu Yang
Signed-off-by: Marc Zyngier
Link:
https://lore.kernel.org/r/1594087972-21715-5-git-send-email-yangtie...@loongson.cn
Signed-off-by: Sasha Levin
---
drivers/irqchip/irq-loongson-htvec.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/irqchip/irq-loongson-htvec.c
b/drivers/irqchip/irq-loongson-htvec.c
index b36d403383230..720cf96ae90ee 100644
--- a/drivers/irqchip/irq-loongson-htvec.c
+++ b/drivers/irqchip/irq-loongson-htvec.c
@@ -109,11 +109,14 @@ static struct irq_chip htvec_irq_chip = {
static int htvec_domain_alloc(struct irq_domain *domain, unsigned int virq,
unsigned int nr_irqs, void *arg)
{
+ int ret;
unsigned long hwirq;
unsigned int type, i;
struct htvec *priv = domain->host_data;
- irq_domain_translate_onecell(domain, arg, , );
+ ret = irq_domain_translate_onecell(domain, arg, , );
+ if (ret)
+ return ret;
for (i = 0; i < nr_irqs; i++) {
irq_domain_set_info(domain, virq + i, hwirq + i,
_irq_chip,
--
2.25.1
[PATCH AUTOSEL 5.8 63/72] kunit: tool: fix broken default args in unit tests
From: Brendan Higgins
[ Upstream commit 6816fe61bda8c819c368ad2002cd27172ecb79de ]
Commit ddbd60c779b4 ("kunit: use --build_dir=.kunit as default") changed
the default build directory for KUnit tests, but failed to update
associated unit tests for kunit_tool, so update them.
Fixes: ddbd60c779b4 ("kunit: use --build_dir=.kunit as default")
Signed-off-by: Brendan Higgins
Signed-off-by: Shuah Khan
Signed-off-by: Sasha Levin
---
tools/testing/kunit/kunit_tool_test.py | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/tools/testing/kunit/kunit_tool_test.py
b/tools/testing/kunit/kunit_tool_test.py
index f9eeaea94cad1..ee942d80bdd02 100755
--- a/tools/testing/kunit/kunit_tool_test.py
+++ b/tools/testing/kunit/kunit_tool_test.py
@@ -258,14 +258,14 @@ class KUnitMainTest(unittest.TestCase):
def test_build_passes_args_pass(self):
kunit.main(['build'], self.linux_source_mock)
assert self.linux_source_mock.build_reconfig.call_count == 0
-
self.linux_source_mock.build_um_kernel.assert_called_once_with(False, 8, '',
None)
+
self.linux_source_mock.build_um_kernel.assert_called_once_with(False, 8,
'.kunit', None)
assert self.linux_source_mock.run_kernel.call_count == 0
def test_exec_passes_args_pass(self):
kunit.main(['exec'], self.linux_source_mock)
assert self.linux_source_mock.build_reconfig.call_count == 0
assert self.linux_source_mock.run_kernel.call_count == 1
-
self.linux_source_mock.run_kernel.assert_called_once_with(build_dir='',
timeout=300)
+
self.linux_source_mock.run_kernel.assert_called_once_with(build_dir='.kunit',
timeout=300)
self.print_mock.assert_any_call(StrContains('Testing
complete.'))
def test_run_passes_args_pass(self):
@@ -273,7 +273,7 @@ class KUnitMainTest(unittest.TestCase):
assert self.linux_source_mock.build_reconfig.call_count == 1
assert self.linux_source_mock.run_kernel.call_count == 1
self.linux_source_mock.run_kernel.assert_called_once_with(
- build_dir='', timeout=300)
+ build_dir='.kunit', timeout=300)
self.print_mock.assert_any_call(StrContains('Testing
complete.'))
def test_exec_passes_args_fail(self):
@@ -313,7 +313,7 @@ class KUnitMainTest(unittest.TestCase):
def test_exec_timeout(self):
timeout = 3453
kunit.main(['exec', '--timeout', str(timeout)],
self.linux_source_mock)
-
self.linux_source_mock.run_kernel.assert_called_once_with(build_dir='',
timeout=timeout)
+
self.linux_source_mock.run_kernel.assert_called_once_with(build_dir='.kunit',
timeout=timeout)
self.print_mock.assert_any_call(StrContains('Testing
complete.'))
def test_run_timeout(self):
@@ -321,7 +321,7 @@ class KUnitMainTest(unittest.TestCase):
kunit.main(['run', '--timeout', str(timeout)],
self.linux_source_mock)
assert self.linux_source_mock.build_reconfig.call_count == 1
self.linux_source_mock.run_kernel.assert_called_once_with(
- build_dir='', timeout=timeout)
+ build_dir='.kunit', timeout=timeout)
self.print_mock.assert_any_call(StrContains('Testing
complete.'))
def test_run_builddir(self):
--
2.25.1
[PATCH AUTOSEL 5.8 55/72] scripts/selinux/mdp: fix initial SID handling
From: Stephen Smalley
[ Upstream commit 382c2b5d23b4245f1818f69286db334355488dc4 ]
commit e3e0b582c321 ("selinux: remove unused initial SIDs and improve
handling") broke scripts/selinux/mdp since the unused initial SID names
were removed and the corresponding generation of policy initial SID
definitions by mdp was not updated accordingly. Fix it. With latest
upstream checkpolicy it is no longer necessary to include the SID context
definitions for the unused initial SIDs but retain them for compatibility
with older checkpolicy.
Fixes: e3e0b582c321 ("selinux: remove unused initial SIDs and improve handling")
Signed-off-by: Stephen Smalley
Signed-off-by: Paul Moore
Signed-off-by: Sasha Levin
---
scripts/selinux/mdp/mdp.c | 23 ++-
1 file changed, 18 insertions(+), 5 deletions(-)
diff --git a/scripts/selinux/mdp/mdp.c b/scripts/selinux/mdp/mdp.c
index 576d11a60417b..6ceb88eb9b590 100644
--- a/scripts/selinux/mdp/mdp.c
+++ b/scripts/selinux/mdp/mdp.c
@@ -67,8 +67,14 @@ int main(int argc, char *argv[])
initial_sid_to_string_len = sizeof(initial_sid_to_string) / sizeof
(char *);
/* print out the sids */
- for (i = 1; i < initial_sid_to_string_len; i++)
- fprintf(fout, "sid %s\n", initial_sid_to_string[i]);
+ for (i = 1; i < initial_sid_to_string_len; i++) {
+ const char *name = initial_sid_to_string[i];
+
+ if (name)
+ fprintf(fout, "sid %s\n", name);
+ else
+ fprintf(fout, "sid unused%d\n", i);
+ }
fprintf(fout, "\n");
/* print out the class permissions */
@@ -126,9 +132,16 @@ int main(int argc, char *argv[])
#define OBJUSERROLETYPE "user_u:object_r:base_t"
/* default sids */
- for (i = 1; i < initial_sid_to_string_len; i++)
- fprintf(fout, "sid %s " SUBJUSERROLETYPE "%s\n",
- initial_sid_to_string[i], mls ? ":" SYSTEMLOW : "");
+ for (i = 1; i < initial_sid_to_string_len; i++) {
+ const char *name = initial_sid_to_string[i];
+
+ if (name)
+ fprintf(fout, "sid %s ", name);
+ else
+ fprintf(fout, "sid unused%d\n", i);
+ fprintf(fout, SUBJUSERROLETYPE "%s\n",
+ mls ? ":" SYSTEMLOW : "");
+ }
fprintf(fout, "\n");
#define FS_USE(behavior, fstype) \
--
2.25.1
[PATCH AUTOSEL 5.8 58/72] md: raid0/linear: fix dereference before null check on pointer mddev
From: Colin Ian King
[ Upstream commit 9a5a85972c073f720d81a7ebd08bfe278e6e16db ]
Pointer mddev is being dereferenced with a test_bit call before mddev
is being null checked, this may cause a null pointer dereference. Fix
this by moving the null pointer checks to sanity check mddev before
it is dereferenced.
Addresses-Coverity: ("Dereference before null check")
Fixes: 62f7b1989c02 ("md raid0/linear: Mark array as 'broken' and fail BIOs if
a member is gone")
Signed-off-by: Colin Ian King
Reviewed-by: Guilherme G. Piccoli
Signed-off-by: Song Liu
Signed-off-by: Sasha Levin
---
drivers/md/md.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/md/md.c b/drivers/md/md.c
index f567f536b529b..90756450b9588 100644
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -470,17 +470,18 @@ static blk_qc_t md_make_request(struct request_queue *q,
struct bio *bio)
struct mddev *mddev = bio->bi_disk->private_data;
unsigned int sectors;
- if (unlikely(test_bit(MD_BROKEN, >flags)) && (rw == WRITE)) {
+ if (mddev == NULL || mddev->pers == NULL) {
bio_io_error(bio);
return BLK_QC_T_NONE;
}
- blk_queue_split(q, );
-
- if (mddev == NULL || mddev->pers == NULL) {
+ if (unlikely(test_bit(MD_BROKEN, >flags)) && (rw == WRITE)) {
bio_io_error(bio);
return BLK_QC_T_NONE;
}
+
+ blk_queue_split(q, );
+
if (mddev->ro == 1 && unlikely(rw == WRITE)) {
if (bio_sectors(bio) != 0)
bio->bi_status = BLK_STS_IOERR;
--
2.25.1
[PATCH AUTOSEL 5.8 56/72] irqchip/ti-sci-inta: Fix return value about devm_ioremap_resource()
From: Tiezhu Yang
[ Upstream commit 4b127a14cb1385dd355c7673d975258d5d668922 ]
When call function devm_ioremap_resource(), we should use IS_ERR()
to check the return value and return PTR_ERR() if failed.
Fixes: 9f1463b86c13 ("irqchip/ti-sci-inta: Add support for Interrupt Aggregator
driver")
Signed-off-by: Tiezhu Yang
Signed-off-by: Marc Zyngier
Reviewed-by: Grygorii Strashko
Link:
https://lore.kernel.org/r/1591437017-5295-2-git-send-email-yangtie...@loongson.cn
Signed-off-by: Sasha Levin
---
drivers/irqchip/irq-ti-sci-inta.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/irqchip/irq-ti-sci-inta.c
b/drivers/irqchip/irq-ti-sci-inta.c
index 7e3ebf6ed2cd1..be0a35d917962 100644
--- a/drivers/irqchip/irq-ti-sci-inta.c
+++ b/drivers/irqchip/irq-ti-sci-inta.c
@@ -572,7 +572,7 @@ static int ti_sci_inta_irq_domain_probe(struct
platform_device *pdev)
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
inta->base = devm_ioremap_resource(dev, res);
if (IS_ERR(inta->base))
- return -ENODEV;
+ return PTR_ERR(inta->base);
domain = irq_domain_add_linear(dev_of_node(dev),
ti_sci_get_num_resources(inta->vint),
--
2.25.1
[PATCH AUTOSEL 5.8 48/72] io_uring: fix sq array offset calculation
From: Dmitry Vyukov
[ Upstream commit b36200f543ff07a1cb346aa582349141df2c8068 ]
rings_size() sets sq_offset to the total size of the rings (the returned
value which is used for memory allocation). This is wrong: sq array should
be located within the rings, not after them. Set sq_offset to where it
should be.
Fixes: 75b28affdd6a ("io_uring: allocate the two rings together")
Signed-off-by: Dmitry Vyukov
Acked-by: Hristo Venev
Cc: io-ur...@vger.kernel.org
Signed-off-by: Jens Axboe
Signed-off-by: Sasha Levin
---
fs/io_uring.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/fs/io_uring.c b/fs/io_uring.c
index 493e5047e67c9..edb5e9d6ae3a4 100644
--- a/fs/io_uring.c
+++ b/fs/io_uring.c
@@ -7086,6 +7086,9 @@ static unsigned long rings_size(unsigned sq_entries,
unsigned cq_entries,
return SIZE_MAX;
#endif
+ if (sq_offset)
+ *sq_offset = off;
+
sq_array_size = array_size(sizeof(u32), sq_entries);
if (sq_array_size == SIZE_MAX)
return SIZE_MAX;
@@ -7093,9 +7096,6 @@ static unsigned long rings_size(unsigned sq_entries,
unsigned cq_entries,
if (check_add_overflow(off, sq_array_size, ))
return SIZE_MAX;
- if (sq_offset)
- *sq_offset = off;
-
return off;
}
--
2.25.1
[PATCH AUTOSEL 5.8 53/72] ARM: socfpga: PM: add missing put_device() call in socfpga_setup_ocram_self_refresh()
From: Yu Kuai
[ Upstream commit 3ad7b4e8f89d6bcc9887ca701cf2745a6aedb1a0 ]
if of_find_device_by_node() succeed, socfpga_setup_ocram_self_refresh
doesn't have a corresponding put_device(). Thus add a jump target to
fix the exception handling for this function implementation.
Fixes: 44fd8c7d4005 ("ARM: socfpga: support suspend to ram")
Signed-off-by: Yu Kuai
Signed-off-by: Dinh Nguyen
Signed-off-by: Sasha Levin
---
arch/arm/mach-socfpga/pm.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-socfpga/pm.c b/arch/arm/mach-socfpga/pm.c
index 6ed887cf8dc9a..365c0428b21b6 100644
--- a/arch/arm/mach-socfpga/pm.c
+++ b/arch/arm/mach-socfpga/pm.c
@@ -49,14 +49,14 @@ static int socfpga_setup_ocram_self_refresh(void)
if (!ocram_pool) {
pr_warn("%s: ocram pool unavailable!\n", __func__);
ret = -ENODEV;
- goto put_node;
+ goto put_device;
}
ocram_base = gen_pool_alloc(ocram_pool, socfpga_sdram_self_refresh_sz);
if (!ocram_base) {
pr_warn("%s: unable to alloc ocram!\n", __func__);
ret = -ENOMEM;
- goto put_node;
+ goto put_device;
}
ocram_pbase = gen_pool_virt_to_phys(ocram_pool, ocram_base);
@@ -67,7 +67,7 @@ static int socfpga_setup_ocram_self_refresh(void)
if (!suspend_ocram_base) {
pr_warn("%s: __arm_ioremap_exec failed!\n", __func__);
ret = -ENOMEM;
- goto put_node;
+ goto put_device;
}
/* Copy the code that puts DDR in self refresh to ocram */
@@ -81,6 +81,8 @@ static int socfpga_setup_ocram_self_refresh(void)
if (!socfpga_sdram_self_refresh_in_ocram)
ret = -EFAULT;
+put_device:
+ put_device(>dev);
put_node:
of_node_put(np);
--
2.25.1
[PATCH AUTOSEL 5.7 14/58] memory: tegra: Fix an error handling path in tegra186_emc_probe()
From: Christophe JAILLET
[ Upstream commit c3d4eb3bf6ad32466555b31094f33a299444f795 ]
The call to tegra_bpmp_get() must be balanced by a call to
tegra_bpmp_put() in case of error, as already done in the remove
function.
Add an error handling path and corresponding goto.
Fixes: 52d15dd23f0b ("memory: tegra: Support DVFS on Tegra186 and later")
Signed-off-by: Christophe JAILLET
Signed-off-by: Thierry Reding
Signed-off-by: Sasha Levin
---
drivers/memory/tegra/tegra186-emc.c | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/memory/tegra/tegra186-emc.c
b/drivers/memory/tegra/tegra186-emc.c
index 97f26bc77ad41..c900948881d5b 100644
--- a/drivers/memory/tegra/tegra186-emc.c
+++ b/drivers/memory/tegra/tegra186-emc.c
@@ -185,7 +185,7 @@ static int tegra186_emc_probe(struct platform_device *pdev)
if (IS_ERR(emc->clk)) {
err = PTR_ERR(emc->clk);
dev_err(>dev, "failed to get EMC clock: %d\n", err);
- return err;
+ goto put_bpmp;
}
platform_set_drvdata(pdev, emc);
@@ -201,7 +201,7 @@ static int tegra186_emc_probe(struct platform_device *pdev)
err = tegra_bpmp_transfer(emc->bpmp, );
if (err < 0) {
dev_err(>dev, "failed to EMC DVFS pairs: %d\n", err);
- return err;
+ goto put_bpmp;
}
emc->debugfs.min_rate = ULONG_MAX;
@@ -211,8 +211,10 @@ static int tegra186_emc_probe(struct platform_device *pdev)
emc->dvfs = devm_kmalloc_array(>dev, emc->num_dvfs,
sizeof(*emc->dvfs), GFP_KERNEL);
- if (!emc->dvfs)
- return -ENOMEM;
+ if (!emc->dvfs) {
+ err = -ENOMEM;
+ goto put_bpmp;
+ }
dev_dbg(>dev, "%u DVFS pairs:\n", emc->num_dvfs);
@@ -237,7 +239,7 @@ static int tegra186_emc_probe(struct platform_device *pdev)
"failed to set rate range [%lu-%lu] for %pC\n",
emc->debugfs.min_rate, emc->debugfs.max_rate,
emc->clk);
- return err;
+ goto put_bpmp;
}
emc->debugfs.root = debugfs_create_dir("emc", NULL);
@@ -254,6 +256,10 @@ static int tegra186_emc_probe(struct platform_device *pdev)
emc, _emc_debug_max_rate_fops);
return 0;
+
+put_bpmp:
+ tegra_bpmp_put(emc->bpmp);
+ return err;
}
static int tegra186_emc_remove(struct platform_device *pdev)
--
2.25.1
[PATCH AUTOSEL 5.8 62/72] irqchip/loongson-liointc: Fix potential dead lock
From: Tiezhu Yang
[ Upstream commit fa03587cad9bd32aa552377de4f05c50181a35a8 ]
In the function liointc_set_type(), we need to call the function
irq_gc_unlock_irqrestore() before returning.
Fixes: dbb152267908 ("irqchip: Add driver for Loongson I/O Local Interrupt
Controller")
Reported-by: Jianmin Lv
Signed-off-by: Tiezhu Yang
Signed-off-by: Marc Zyngier
Link:
https://lore.kernel.org/r/1594087972-21715-8-git-send-email-yangtie...@loongson.cn
Signed-off-by: Sasha Levin
---
drivers/irqchip/irq-loongson-liointc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/irqchip/irq-loongson-liointc.c
b/drivers/irqchip/irq-loongson-liointc.c
index 63b61474a0cc2..6ef86a334c62d 100644
--- a/drivers/irqchip/irq-loongson-liointc.c
+++ b/drivers/irqchip/irq-loongson-liointc.c
@@ -114,6 +114,7 @@ static int liointc_set_type(struct irq_data *data, unsigned
int type)
liointc_set_bit(gc, LIOINTC_REG_INTC_POL, mask, false);
break;
default:
+ irq_gc_unlock_irqrestore(gc, flags);
return -EINVAL;
}
irq_gc_unlock_irqrestore(gc, flags);
--
2.25.1
[PATCH AUTOSEL 5.7 05/58] x86, sched: Bail out of frequency invariance if turbo_freq/base_freq gives 0
From: Giovanni Gherdovich
[ Upstream commit f4291df103315a696f0b8c4f45ca8ae773c17441 ]
Be defensive against the case where the processor reports a base_freq
larger than turbo_freq (the ratio would be zero).
Fixes: 1567c3e3467c ("x86, sched: Add support for frequency invariance")
Signed-off-by: Giovanni Gherdovich
Signed-off-by: Peter Zijlstra (Intel)
Reviewed-by: Rafael J. Wysocki
Link: https://lkml.kernel.org/r/20200531182453.15254-4-ggherdov...@suse.cz
Signed-off-by: Sasha Levin
---
arch/x86/kernel/smpboot.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
index 3917a2de1580c..e5b2b20a0aeee 100644
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -1974,6 +1974,7 @@ static bool core_set_max_freq_ratio(u64 *base_freq, u64
*turbo_freq)
static bool intel_set_max_freq_ratio(void)
{
u64 base_freq, turbo_freq;
+ u64 turbo_ratio;
if (slv_set_max_freq_ratio(_freq, _freq))
goto out;
@@ -2007,9 +2008,15 @@ static bool intel_set_max_freq_ratio(void)
return false;
}
- arch_turbo_freq_ratio = div_u64(turbo_freq * SCHED_CAPACITY_SCALE,
- base_freq);
+ turbo_ratio = div_u64(turbo_freq * SCHED_CAPACITY_SCALE, base_freq);
+ if (!turbo_ratio) {
+ pr_debug("Non-zero turbo and base frequencies led to a 0
ratio.\n");
+ return false;
+ }
+
+ arch_turbo_freq_ratio = turbo_ratio;
arch_set_max_freq_ratio(turbo_disabled());
+
return true;
}
--
2.25.1
[PATCH AUTOSEL 5.8 70/72] nvme-multipath: do not fall back to __nvme_find_path() for non-optimized paths
From: Hannes Reinecke
[ Upstream commit fbd6a42d8932e172921c7de10468a2e12c34846b ]
When nvme_round_robin_path() finds a valid namespace we should be using it;
falling back to __nvme_find_path() for non-optimized paths will cause the
result from nvme_round_robin_path() to be ignored for non-optimized paths.
Fixes: 75c10e732724 ("nvme-multipath: round-robin I/O policy")
Signed-off-by: Martin Wilck
Signed-off-by: Hannes Reinecke
Reviewed-by: Sagi Grimberg
Signed-off-by: Christoph Hellwig
Signed-off-by: Sasha Levin
---
drivers/nvme/host/multipath.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/nvme/host/multipath.c b/drivers/nvme/host/multipath.c
index fe8f7f123fac7..57d51148e71b6 100644
--- a/drivers/nvme/host/multipath.c
+++ b/drivers/nvme/host/multipath.c
@@ -272,10 +272,13 @@ inline struct nvme_ns *nvme_find_path(struct nvme_ns_head
*head)
struct nvme_ns *ns;
ns = srcu_dereference(head->current_path[node], >srcu);
- if (READ_ONCE(head->subsys->iopolicy) == NVME_IOPOLICY_RR && ns)
- ns = nvme_round_robin_path(head, node, ns);
- if (unlikely(!ns || !nvme_path_is_optimized(ns)))
- ns = __nvme_find_path(head, node);
+ if (unlikely(!ns))
+ return __nvme_find_path(head, node);
+
+ if (READ_ONCE(head->subsys->iopolicy) == NVME_IOPOLICY_RR)
+ return nvme_round_robin_path(head, node, ns);
+ if (unlikely(!nvme_path_is_optimized(ns)))
+ return __nvme_find_path(head, node);
return ns;
}
--
2.25.1
[PATCH AUTOSEL 5.7 10/58] arm64: dts: rockchip: fix rk3399-puma gmac reset gpio
From: Heiko Stuebner
[ Upstream commit 8a445086f8af0b7b9bd8d1901d6f306bb154f70d ]
The puma gmac node currently uses opposite active-values for the
gmac phy reset pin. The gpio-declaration uses active-high while the
separate snps,reset-active-low property marks the pin as active low.
While on the kernel side this works ok, other DT users may get
confused - as seen with uboot right now.
So bring this in line and make both properties match, similar to the
other Rockchip board.
Fixes: 2c66fc34e945 ("arm64: dts: rockchip: add RK3399-Q7 (Puma) SoM")
Signed-off-by: Heiko Stuebner
Link: https://lore.kernel.org/r/20200603132836.362519-1-he...@sntech.de
Signed-off-by: Sasha Levin
---
arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi
b/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi
index 063f59a420b65..72c06abd27ea7 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi
@@ -157,7 +157,7 @@ {
phy-mode = "rgmii";
pinctrl-names = "default";
pinctrl-0 = <_pins>;
- snps,reset-gpio = < RK_PC0 GPIO_ACTIVE_HIGH>;
+ snps,reset-gpio = < RK_PC0 GPIO_ACTIVE_LOW>;
snps,reset-active-low;
snps,reset-delays-us = <0 1 5>;
tx_delay = <0x10>;
--
2.25.1
[PATCH AUTOSEL 5.7 03/58] perf/x86/intel/uncore: Fix oops when counting IMC uncore events on some TGL
From: Kan Liang
[ Upstream commit 2af834f1faab3f1e218fcbcab70a399121620d62 ]
When counting IMC uncore events on some TGL machines, an oops will be
triggered.
[ 393.101262] BUG: unable to handle page fault for address:
b45200e15858
[ 393.101269] #PF: supervisor read access in kernel mode
[ 393.101271] #PF: error_code(0x) - not-present page
Current perf uncore driver still use the IMC MAP SIZE inherited from
SNB, which is 0x6000.
However, the offset of IMC uncore counters is larger than 0x6000,
e.g. 0xd8a0.
Enlarge the IMC MAP SIZE for TGL to 0xe000.
Fixes: fdb64822443e ("perf/x86: Add Intel Tiger Lake uncore support")
Reported-by: Ammy Yi
Signed-off-by: Kan Liang
Signed-off-by: Peter Zijlstra (Intel)
Tested-by: Ammy Yi
Tested-by: Chao Qin
Link:
https://lkml.kernel.org/r/1590679169-61823-1-git-send-email-kan.li...@linux.intel.com
Signed-off-by: Sasha Levin
---
arch/x86/events/intel/uncore_snb.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/x86/events/intel/uncore_snb.c
b/arch/x86/events/intel/uncore_snb.c
index 3de1065eefc44..1038e9f1e3542 100644
--- a/arch/x86/events/intel/uncore_snb.c
+++ b/arch/x86/events/intel/uncore_snb.c
@@ -1085,6 +1085,7 @@ static struct pci_dev *tgl_uncore_get_mc_dev(void)
}
#define TGL_UNCORE_MMIO_IMC_MEM_OFFSET 0x1
+#define TGL_UNCORE_PCI_IMC_MAP_SIZE0xe000
static void tgl_uncore_imc_freerunning_init_box(struct intel_uncore_box *box)
{
@@ -1112,7 +1113,7 @@ static void tgl_uncore_imc_freerunning_init_box(struct
intel_uncore_box *box)
addr |= ((resource_size_t)mch_bar << 32);
#endif
- box->io_addr = ioremap(addr, SNB_UNCORE_PCI_IMC_MAP_SIZE);
+ box->io_addr = ioremap(addr, TGL_UNCORE_PCI_IMC_MAP_SIZE);
}
static struct intel_uncore_ops tgl_uncore_imc_freerunning_ops = {
--
2.25.1
[PATCH AUTOSEL 5.7 09/58] arm64: dts: rockchip: fix rk3399-puma vcc5v0-host gpio
From: Heiko Stuebner
[ Upstream commit 7a7184f6cfa9279f1a1c10a1845d247d7fad54ff ]
The puma vcc5v0_host regulator node currently uses opposite active-values
for the enable pin. The gpio-declaration uses active-high while the
separate enable-active-low property marks the pin as active low.
While on the kernel side this works ok, other DT users may get
confused - as seen with uboot right now.
So bring this in line and make both properties match, similar to the
gmac fix.
Fixes: 2c66fc34e945 ("arm64: dts: rockchip: add RK3399-Q7 (Puma) SoM")
Signed-off-by: Heiko Stuebner
Link: https://lore.kernel.org/r/20200604091239.424318-1-he...@sntech.de
Signed-off-by: Sasha Levin
---
arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi
b/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi
index 07694b196fdbe..063f59a420b65 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi
@@ -101,7 +101,7 @@ vcc3v3_sys: vcc3v3-sys {
vcc5v0_host: vcc5v0-host-regulator {
compatible = "regulator-fixed";
- gpio = < RK_PA3 GPIO_ACTIVE_HIGH>;
+ gpio = < RK_PA3 GPIO_ACTIVE_LOW>;
enable-active-low;
pinctrl-names = "default";
pinctrl-0 = <_host_en>;
--
2.25.1
[PATCH AUTOSEL 5.8 72/72] block: don't do revalidate zones on invalid devices
From: Johannes Thumshirn
[ Upstream commit 1a1206dc4cf02cee4b5cbce583ee4c22368b4c28 ]
When we loose a device for whatever reason while (re)scanning zones, we
trip over a NULL pointer in blk_revalidate_zone_cb, like in the following
log:
sd 0:0:0:0: [sda] 3418095616 4096-byte logical blocks: (14.0 TB/12.7 TiB)
sd 0:0:0:0: [sda] 52156 zones of 65536 logical blocks
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 37 00 00 08
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support
DPO or FUA
sd 0:0:0:0: [sda] REPORT ZONES start lba 1065287680 failed
sd 0:0:0:0: [sda] REPORT ZONES: Result: hostbyte=0x00 driverbyte=0x08
sd 0:0:0:0: [sda] Sense Key : 0xb [current]
sd 0:0:0:0: [sda] ASC=0x0 ASCQ=0x6
sda: failed to revalidate zones
sd 0:0:0:0: [sda] 0 4096-byte logical blocks: (0 B/0 B)
sda: detected capacity change from 14000519643136 to 0
==
BUG: KASAN: null-ptr-deref in blk_revalidate_zone_cb+0x1b7/0x550
Write of size 8 at addr 0010 by task kworker/u4:1/58
CPU: 1 PID: 58 Comm: kworker/u4:1 Not tainted 5.8.0-rc1 #692
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
rel-1.13.0-0-gf21b5a4-rebuilt.opensuse.org 04/01/2014
Workqueue: events_unbound async_run_entry_fn
Call Trace:
dump_stack+0x7d/0xb0
? blk_revalidate_zone_cb+0x1b7/0x550
kasan_report.cold+0x5/0x37
? blk_revalidate_zone_cb+0x1b7/0x550
check_memory_region+0x145/0x1a0
blk_revalidate_zone_cb+0x1b7/0x550
sd_zbc_parse_report+0x1f1/0x370
? blk_req_zone_write_trylock+0x200/0x200
? sectors_to_logical+0x60/0x60
? blk_req_zone_write_trylock+0x200/0x200
? blk_req_zone_write_trylock+0x200/0x200
sd_zbc_report_zones+0x3c4/0x5e0
? sd_dif_config_host+0x500/0x500
blk_revalidate_disk_zones+0x231/0x44d
? _raw_write_lock_irqsave+0xb0/0xb0
? blk_queue_free_zone_bitmaps+0xd0/0xd0
sd_zbc_read_zones+0x8cf/0x11a0
sd_revalidate_disk+0x305c/0x64e0
? __device_add_disk+0x776/0xf20
? read_capacity_16.part.0+0x1080/0x1080
? blk_alloc_devt+0x250/0x250
? create_object.isra.0+0x595/0xa20
? kasan_unpoison_shadow+0x33/0x40
sd_probe+0x8dc/0xcd2
really_probe+0x20e/0xaf0
__driver_attach_async_helper+0x249/0x2d0
async_run_entry_fn+0xbe/0x560
process_one_work+0x764/0x1290
? _raw_read_unlock_irqrestore+0x30/0x30
worker_thread+0x598/0x12f0
? __kthread_parkme+0xc6/0x1b0
? schedule+0xed/0x2c0
? process_one_work+0x1290/0x1290
kthread+0x36b/0x440
? kthread_create_worker_on_cpu+0xa0/0xa0
ret_from_fork+0x22/0x30
==
When the device is already gone we end up with the following scenario:
The device's capacity is 0 and thus the number of zones will be 0 as well. When
allocating the bitmap for the conventional zones, we then trip over a NULL
pointer.
So if we encounter a zoned block device with a 0 capacity, don't dare to
revalidate the zones sizes.
Fixes: 6c6b35491422 ("block: set the zone size in blk_revalidate_disk_zones
atomically")
Signed-off-by: Johannes Thumshirn
Reviewed-by: Damien Le Moal
Signed-off-by: Jens Axboe
Signed-off-by: Sasha Levin
---
block/blk-zoned.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/block/blk-zoned.c b/block/blk-zoned.c
index 23831fa8701d8..480dfff69a00c 100644
--- a/block/blk-zoned.c
+++ b/block/blk-zoned.c
@@ -497,6 +497,9 @@ int blk_revalidate_disk_zones(struct gendisk *disk,
if (WARN_ON_ONCE(!queue_is_mq(q)))
return -EIO;
+ if (!get_capacity(disk))
+ return -EIO;
+
/*
* Ensure that all memory allocations in this context are done as if
* GFP_NOIO was specified.
--
2.25.1
[PATCH AUTOSEL 5.8 71/72] irqchip/loongson-pch-pic: Fix the misused irq flow handler
From: Huacai Chen
[ Upstream commit ac62460c24126eb2442e3653a266ebbf05b004d8 ]
Loongson PCH PIC is a standard level triggered PIC, and it need to clear
interrupt during unmask.
Fixes: ef8c01eb64ca6719da449dab0 ("irqchip: Add Loongson PCH PIC controller")
Signed-off-by: Huacai Chen
Signed-off-by: Marc Zyngier
Tested-by: Jiaxun Yang
Link:
https://lore.kernel.org/r/1596099090-23516-6-git-send-email-che...@lemote.com
Signed-off-by: Sasha Levin
---
drivers/irqchip/irq-loongson-pch-pic.c | 15 ---
1 file changed, 4 insertions(+), 11 deletions(-)
diff --git a/drivers/irqchip/irq-loongson-pch-pic.c
b/drivers/irqchip/irq-loongson-pch-pic.c
index 016f32c4cbe18..9bf6b9a5f7348 100644
--- a/drivers/irqchip/irq-loongson-pch-pic.c
+++ b/drivers/irqchip/irq-loongson-pch-pic.c
@@ -64,15 +64,6 @@ static void pch_pic_bitclr(struct pch_pic *priv, int offset,
int bit)
raw_spin_unlock(>pic_lock);
}
-static void pch_pic_eoi_irq(struct irq_data *d)
-{
- u32 idx = PIC_REG_IDX(d->hwirq);
- struct pch_pic *priv = irq_data_get_irq_chip_data(d);
-
- writel(BIT(PIC_REG_BIT(d->hwirq)),
- priv->base + PCH_PIC_CLR + idx * 4);
-}
-
static void pch_pic_mask_irq(struct irq_data *d)
{
struct pch_pic *priv = irq_data_get_irq_chip_data(d);
@@ -85,6 +76,9 @@ static void pch_pic_unmask_irq(struct irq_data *d)
{
struct pch_pic *priv = irq_data_get_irq_chip_data(d);
+ writel(BIT(PIC_REG_BIT(d->hwirq)),
+ priv->base + PCH_PIC_CLR + PIC_REG_IDX(d->hwirq) * 4);
+
irq_chip_unmask_parent(d);
pch_pic_bitclr(priv, PCH_PIC_MASK, d->hwirq);
}
@@ -124,7 +118,6 @@ static struct irq_chip pch_pic_irq_chip = {
.irq_mask = pch_pic_mask_irq,
.irq_unmask = pch_pic_unmask_irq,
.irq_ack= irq_chip_ack_parent,
- .irq_eoi= pch_pic_eoi_irq,
.irq_set_affinity = irq_chip_set_affinity_parent,
.irq_set_type = pch_pic_set_type,
};
@@ -153,7 +146,7 @@ static int pch_pic_alloc(struct irq_domain *domain,
unsigned int virq,
irq_domain_set_info(domain, virq, hwirq,
_pic_irq_chip, priv,
- handle_fasteoi_ack_irq, NULL, NULL);
+ handle_level_irq, NULL, NULL);
irq_set_probe(virq);
return 0;
--
2.25.1
[PATCH AUTOSEL 5.8 67/72] nvme-tcp: fix controller reset hang during traffic
From: Sagi Grimberg
[ Upstream commit 2875b0aecabe2f081a8432e2bc85b85df0529490 ]
commit fe35ec58f0d3 ("block: update hctx map when use multiple maps")
exposed an issue where we may hang trying to wait for queue freeze
during I/O. We call blk_mq_update_nr_hw_queues which in case of multiple
queue maps (which we have now for default/read/poll) is attempting to
freeze the queue. However we never started queue freeze when starting the
reset, which means that we have inflight pending requests that entered the
queue that we will not complete once the queue is quiesced.
So start a freeze before we quiesce the queue, and unfreeze the queue
after we successfully connected the I/O queues (and make sure to call
blk_mq_update_nr_hw_queues only after we are sure that the queue was
already frozen).
This follows to how the pci driver handles resets.
Fixes: fe35ec58f0d3 ("block: update hctx map when use multiple maps")
Signed-off-by: Sagi Grimberg
Signed-off-by: Christoph Hellwig
Signed-off-by: Sasha Levin
---
drivers/nvme/host/tcp.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/nvme/host/tcp.c b/drivers/nvme/host/tcp.c
index f3a91818167b1..83bb329d4113a 100644
--- a/drivers/nvme/host/tcp.c
+++ b/drivers/nvme/host/tcp.c
@@ -1744,15 +1744,20 @@ static int nvme_tcp_configure_io_queues(struct
nvme_ctrl *ctrl, bool new)
ret = PTR_ERR(ctrl->connect_q);
goto out_free_tag_set;
}
- } else {
- blk_mq_update_nr_hw_queues(ctrl->tagset,
- ctrl->queue_count - 1);
}
ret = nvme_tcp_start_io_queues(ctrl);
if (ret)
goto out_cleanup_connect_q;
+ if (!new) {
+ nvme_start_queues(ctrl);
+ nvme_wait_freeze(ctrl);
+ blk_mq_update_nr_hw_queues(ctrl->tagset,
+ ctrl->queue_count - 1);
+ nvme_unfreeze(ctrl);
+ }
+
return 0;
out_cleanup_connect_q:
@@ -1857,6 +1862,7 @@ static void nvme_tcp_teardown_io_queues(struct nvme_ctrl
*ctrl,
{
if (ctrl->queue_count <= 1)
return;
+ nvme_start_freeze(ctrl);
nvme_stop_queues(ctrl);
nvme_tcp_stop_io_queues(ctrl);
if (ctrl->tagset) {
--
2.25.1
[PATCH AUTOSEL 5.7 04/58] x86, sched: Bail out of frequency invariance if turbo frequency is unknown
From: Giovanni Gherdovich
[ Upstream commit 51beea8862a3095559862df39554f05042e1195b ]
There may be CPUs that support turbo boost but don't declare any turbo
ratio, i.e. their MSR_TURBO_RATIO_LIMIT is all zeroes. In that condition
scale-invariant calculations can't be performed.
Fixes: 1567c3e3467c ("x86, sched: Add support for frequency invariance")
Suggested-by: Ricardo Neri
Signed-off-by: Giovanni Gherdovich
Signed-off-by: Peter Zijlstra (Intel)
Reviewed-by: Rafael J. Wysocki
Tested-by: Ricardo Neri
Link: https://lkml.kernel.org/r/20200531182453.15254-3-ggherdov...@suse.cz
Signed-off-by: Sasha Levin
---
arch/x86/kernel/smpboot.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
index 2f24c334a938b..3917a2de1580c 100644
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -1999,9 +1999,11 @@ static bool intel_set_max_freq_ratio(void)
/*
* Some hypervisors advertise X86_FEATURE_APERFMPERF
* but then fill all MSR's with zeroes.
+* Some CPUs have turbo boost but don't declare any turbo ratio
+* in MSR_TURBO_RATIO_LIMIT.
*/
- if (!base_freq) {
- pr_debug("Couldn't determine cpu base frequency, necessary for
scale-invariant accounting.\n");
+ if (!base_freq || !turbo_freq) {
+ pr_debug("Couldn't determine cpu base or turbo frequency,
necessary for scale-invariant accounting.\n");
return false;
}
--
2.25.1
[PATCH AUTOSEL 5.7 02/58] x86/mce/inject: Fix a wrong assignment of i_mce.status
From: Zhenzhong Duan
[ Upstream commit 5d7f7d1d5e01c22894dee7c9c9266500478dca99 ]
The original code is a nop as i_mce.status is or'ed with part of itself,
fix it.
Fixes: a1300e505297 ("x86/ras/mce_amd_inj: Trigger deferred and thresholding
errors interrupts")
Signed-off-by: Zhenzhong Duan
Signed-off-by: Borislav Petkov
Acked-by: Yazen Ghannam
Link: https://lkml.kernel.org/r/20200611023238.3830-1-zhenzhong.d...@gmail.com
Signed-off-by: Sasha Levin
---
arch/x86/kernel/cpu/mce/inject.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kernel/cpu/mce/inject.c b/arch/x86/kernel/cpu/mce/inject.c
index 3413b41b8d55f..dc28a615e340f 100644
--- a/arch/x86/kernel/cpu/mce/inject.c
+++ b/arch/x86/kernel/cpu/mce/inject.c
@@ -511,7 +511,7 @@ static void do_inject(void)
*/
if (inj_type == DFR_INT_INJ) {
i_mce.status |= MCI_STATUS_DEFERRED;
- i_mce.status |= (i_mce.status & ~MCI_STATUS_UC);
+ i_mce.status &= ~MCI_STATUS_UC;
}
/*
--
2.25.1
[PATCH AUTOSEL 5.7 23/58] crypto: qat - allow xts requests not multiple of block
From: Giovanni Cabiddu
[ Upstream commit 528f776df67c440361b2847b4da400d8754bf030 ]
Allow AES-XTS requests that are not multiple of the block size.
If a request is smaller than the block size, return -EINVAL.
This fixes the following issue reported by the crypto testmgr self-test:
alg: skcipher: qat_aes_xts encryption failed on test vector "random: len=116
klen=64"; expected_error=0, actual_error=-22, cfg="random: inplace may_sleep
use_finup src_divs=[45.85%@+4077, 54.15%@alignmask+18]"
Fixes: 96ee111a659e ("crypto: qat - return error for block...")
Signed-off-by: Giovanni Cabiddu
Signed-off-by: Herbert Xu
Signed-off-by: Sasha Levin
---
drivers/crypto/qat/qat_common/qat_algs.c | 22 --
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/qat/qat_common/qat_algs.c
b/drivers/crypto/qat/qat_common/qat_algs.c
index e14d3dd291f09..1b050391c0c90 100644
--- a/drivers/crypto/qat/qat_common/qat_algs.c
+++ b/drivers/crypto/qat/qat_common/qat_algs.c
@@ -55,6 +55,7 @@
#include
#include
#include
+#include
#include
#include "adf_accel_devices.h"
#include "adf_transport.h"
@@ -1102,6 +1103,14 @@ static int qat_alg_skcipher_blk_encrypt(struct
skcipher_request *req)
return qat_alg_skcipher_encrypt(req);
}
+static int qat_alg_skcipher_xts_encrypt(struct skcipher_request *req)
+{
+ if (req->cryptlen < XTS_BLOCK_SIZE)
+ return -EINVAL;
+
+ return qat_alg_skcipher_encrypt(req);
+}
+
static int qat_alg_skcipher_decrypt(struct skcipher_request *req)
{
struct crypto_skcipher *stfm = crypto_skcipher_reqtfm(req);
@@ -1161,6 +1170,15 @@ static int qat_alg_skcipher_blk_decrypt(struct
skcipher_request *req)
return qat_alg_skcipher_decrypt(req);
}
+
+static int qat_alg_skcipher_xts_decrypt(struct skcipher_request *req)
+{
+ if (req->cryptlen < XTS_BLOCK_SIZE)
+ return -EINVAL;
+
+ return qat_alg_skcipher_decrypt(req);
+}
+
static int qat_alg_aead_init(struct crypto_aead *tfm,
enum icp_qat_hw_auth_algo hash,
const char *hash_name)
@@ -1354,8 +1372,8 @@ static struct skcipher_alg qat_skciphers[] = { {
.init = qat_alg_skcipher_init_tfm,
.exit = qat_alg_skcipher_exit_tfm,
.setkey = qat_alg_skcipher_xts_setkey,
- .decrypt = qat_alg_skcipher_blk_decrypt,
- .encrypt = qat_alg_skcipher_blk_encrypt,
+ .decrypt = qat_alg_skcipher_xts_decrypt,
+ .encrypt = qat_alg_skcipher_xts_encrypt,
.min_keysize = 2 * AES_MIN_KEY_SIZE,
.max_keysize = 2 * AES_MAX_KEY_SIZE,
.ivsize = AES_BLOCK_SIZE,
--
2.25.1
[PATCH AUTOSEL 5.7 20/58] arm64: dts: sun50i-pinephone: dldo4 must not be >= 1.8V
From: Ondrej Jirman
[ Upstream commit 86be5c789690eb08656b08c072c50a7b02bf41f1 ]
Some outputs from the RTL8723CS are connected to the PL port (BT_WAKE_AP),
which runs at 1.8V. When BT_WAKE_AP is high, the PL pin this signal is
connected to is overdriven, and the whole PL port's voltage rises
somewhat. This results in changing voltage on the R_PWM pin (PL10),
which is the cause for backlight flickering very noticeably when typing
on a Bluetooth keyboard, because backlight intensity is highly sensitive
to the voltage of the R_PWM pin.
Limit the maximum WiFi/BT I/O voltage to 1.8V to avoid overdriving
the PL port pins via BT and WiFi IO port signals. WiFi and BT
functionality is unaffected by this change.
This completely stops the backlight flicker when using bluetooth.
Fixes: 91f480d40942 ("arm64: dts: allwinner: Add initial support for Pine64
PinePhone")
Signed-off-by: Ondrej Jirman
Link: https://lore.kernel.org/r/20200703194842.111845-4-meg...@megous.com
Signed-off-by: Maxime Ripard
Signed-off-by: Sasha Levin
---
arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
index cefda145c3c9d..342733a20c337 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
@@ -279,7 +279,7 @@ _dldo3 {
_dldo4 {
regulator-min-microvolt = <180>;
- regulator-max-microvolt = <330>;
+ regulator-max-microvolt = <180>;
regulator-name = "vcc-wifi-io";
};
--
2.25.1
