* Re: [PATCH v11 3/3] media: platform: mtk-mdp3: add Mediatek MDP3 driver
From: kernel test robot @ 2022-01-05 18:21 UTC (permalink / raw)
To: Moudy Ho, Mauro Carvalho Chehab, Rob Herring, Matthias Brugger,
Hans Verkuil, Jernej Skrabec
Cc: kbuild-all, linux-media, Chun-Kuang Hu, Geert Uytterhoeven,
Rob Landley, Laurent Pinchart
In-Reply-To: <20220105093758.6850-4-moudy.ho@mediatek.com>
Hi Moudy,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on media-tree/master]
[also build test WARNING on robh/for-next v5.16-rc8 next-20220105]
[cannot apply to mbgg-mediatek/for-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url: https://github.com/0day-ci/linux/commits/Moudy-Ho/media-mediatek-support-mdp3-on-mt8183-platform/20220105-173918
base: git://linuxtv.org/media_tree.git master
config: ia64-allyesconfig (https://download.01.org/0day-ci/archive/20220106/202201060241.t95Ra9LM-lkp@intel.com/config)
compiler: ia64-linux-gcc (GCC) 11.2.0
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# https://github.com/0day-ci/linux/commit/696f7ac402f9778a21202f2b889c3c30a6923b3d
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review Moudy-Ho/media-mediatek-support-mdp3-on-mt8183-platform/20220105-173918
git checkout 696f7ac402f9778a21202f2b889c3c30a6923b3d
# save the config file to linux build tree
mkdir build_dir
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.2.0 make.cross O=build_dir ARCH=ia64 SHELL=/bin/bash drivers/media/
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
All warnings (new ones prefixed by >>):
In file included from drivers/media/platform/mtk-mdp3/mtk-mdp3-core.h:14,
from drivers/media/platform/mtk-mdp3/mtk-mdp3-core.c:15:
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:109:41: error: field 'id' has incomplete type
109 | enum mtk_mdp_comp_id id;
| ^~
>> drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:123:59: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
123 | int (*init_comp)(struct mdp_comp_ctx *ctx, struct mmsys_cmdq_cmd *cmd);
| ^~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:124:62: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
124 | int (*config_frame)(struct mdp_comp_ctx *ctx, struct mmsys_cmdq_cmd *cmd,
| ^~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:127:37: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
127 | struct mmsys_cmdq_cmd *cmd, u32 index);
| ^~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:129:39: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
129 | struct mmsys_cmdq_cmd *cmd);
| ^~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:131:38: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
131 | struct mmsys_cmdq_cmd *cmd, u32 index);
| ^~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:132:62: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
132 | int (*post_process)(struct mdp_comp_ctx *ctx, struct mmsys_cmdq_cmd *cmd);
| ^~~~~~~~~~~~~~
In file included from drivers/media/platform/mtk-mdp3/mtk-mdp3-core.c:15:
drivers/media/platform/mtk-mdp3/mtk-mdp3-core.h:43:60: error: 'MDP_PIPE_MAX' undeclared here (not in a function); did you mean 'SCP_IPI_MAX'?
43 | struct mtk_mutex *mdp_mutex[MDP_PIPE_MAX];
| ^~~~~~~~~~~~
| SCP_IPI_MAX
drivers/media/platform/mtk-mdp3/mtk-mdp3-core.h:44:55: error: 'MDP_MAX_COMP_COUNT' undeclared here (not in a function); did you mean 'MDP_MAX_EVENT_COUNT'?
44 | struct mdp_comp *comp[MDP_MAX_COMP_COUNT];
| ^~~~~~~~~~~~~~~~~~
| MDP_MAX_EVENT_COUNT
drivers/media/platform/mtk-mdp3/mtk-mdp3-core.c: In function 'mdp_probe':
drivers/media/platform/mtk-mdp3/mtk-mdp3-core.c:192:37: error: implicit declaration of function 'mtk_mutex_mdp_get'; did you mean 'mtk_mutex_get'? [-Werror=implicit-function-declaration]
192 | mdp->mdp_mutex[i] = mtk_mutex_mdp_get(&mm_pdev->dev, i);
| ^~~~~~~~~~~~~~~~~
| mtk_mutex_get
cc1: some warnings being treated as errors
--
In file included from drivers/media/platform/mtk-mdp3/mtk-mdp3-core.h:14,
from drivers/media/platform/mtk-mdp3/mtk-mdp3-vpu.c:10:
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:109:41: error: field 'id' has incomplete type
109 | enum mtk_mdp_comp_id id;
| ^~
>> drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:123:59: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
123 | int (*init_comp)(struct mdp_comp_ctx *ctx, struct mmsys_cmdq_cmd *cmd);
| ^~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:124:62: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
124 | int (*config_frame)(struct mdp_comp_ctx *ctx, struct mmsys_cmdq_cmd *cmd,
| ^~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:127:37: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
127 | struct mmsys_cmdq_cmd *cmd, u32 index);
| ^~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:129:39: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
129 | struct mmsys_cmdq_cmd *cmd);
| ^~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:131:38: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
131 | struct mmsys_cmdq_cmd *cmd, u32 index);
| ^~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:132:62: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
132 | int (*post_process)(struct mdp_comp_ctx *ctx, struct mmsys_cmdq_cmd *cmd);
| ^~~~~~~~~~~~~~
In file included from drivers/media/platform/mtk-mdp3/mtk-mdp3-vpu.c:10:
drivers/media/platform/mtk-mdp3/mtk-mdp3-core.h:43:60: error: 'MDP_PIPE_MAX' undeclared here (not in a function); did you mean 'SCP_IPI_MAX'?
43 | struct mtk_mutex *mdp_mutex[MDP_PIPE_MAX];
| ^~~~~~~~~~~~
| SCP_IPI_MAX
drivers/media/platform/mtk-mdp3/mtk-mdp3-core.h:44:55: error: 'MDP_MAX_COMP_COUNT' undeclared here (not in a function); did you mean 'MDP_MAX_EVENT_COUNT'?
44 | struct mdp_comp *comp[MDP_MAX_COMP_COUNT];
| ^~~~~~~~~~~~~~~~~~
| MDP_MAX_EVENT_COUNT
--
In file included from drivers/media/platform/mtk-mdp3/mtk-mdp3-core.h:14,
from drivers/media/platform/mtk-mdp3/mtk-mdp3-regs.c:10:
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:109:41: error: field 'id' has incomplete type
109 | enum mtk_mdp_comp_id id;
| ^~
>> drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:123:59: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
123 | int (*init_comp)(struct mdp_comp_ctx *ctx, struct mmsys_cmdq_cmd *cmd);
| ^~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:124:62: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
124 | int (*config_frame)(struct mdp_comp_ctx *ctx, struct mmsys_cmdq_cmd *cmd,
| ^~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:127:37: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
127 | struct mmsys_cmdq_cmd *cmd, u32 index);
| ^~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:129:39: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
129 | struct mmsys_cmdq_cmd *cmd);
| ^~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:131:38: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
131 | struct mmsys_cmdq_cmd *cmd, u32 index);
| ^~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:132:62: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
132 | int (*post_process)(struct mdp_comp_ctx *ctx, struct mmsys_cmdq_cmd *cmd);
| ^~~~~~~~~~~~~~
In file included from drivers/media/platform/mtk-mdp3/mtk-mdp3-regs.c:10:
drivers/media/platform/mtk-mdp3/mtk-mdp3-core.h:43:60: error: 'MDP_PIPE_MAX' undeclared here (not in a function)
43 | struct mtk_mutex *mdp_mutex[MDP_PIPE_MAX];
| ^~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-core.h:44:55: error: 'MDP_MAX_COMP_COUNT' undeclared here (not in a function); did you mean 'MDP_MAX_EVENT_COUNT'?
44 | struct mdp_comp *comp[MDP_MAX_COMP_COUNT];
| ^~~~~~~~~~~~~~~~~~
| MDP_MAX_EVENT_COUNT
--
In file included from drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.c:11:
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:109:41: error: field 'id' has incomplete type
109 | enum mtk_mdp_comp_id id;
| ^~
>> drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:123:59: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
123 | int (*init_comp)(struct mdp_comp_ctx *ctx, struct mmsys_cmdq_cmd *cmd);
| ^~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:124:62: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
124 | int (*config_frame)(struct mdp_comp_ctx *ctx, struct mmsys_cmdq_cmd *cmd,
| ^~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:127:37: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
127 | struct mmsys_cmdq_cmd *cmd, u32 index);
| ^~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:129:39: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
129 | struct mmsys_cmdq_cmd *cmd);
| ^~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:131:38: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
131 | struct mmsys_cmdq_cmd *cmd, u32 index);
| ^~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:132:62: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
132 | int (*post_process)(struct mdp_comp_ctx *ctx, struct mmsys_cmdq_cmd *cmd);
| ^~~~~~~~~~~~~~
In file included from drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.c:12:
drivers/media/platform/mtk-mdp3/mtk-mdp3-core.h:43:60: error: 'MDP_PIPE_MAX' undeclared here (not in a function)
43 | struct mtk_mutex *mdp_mutex[MDP_PIPE_MAX];
| ^~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-core.h:44:55: error: 'MDP_MAX_COMP_COUNT' undeclared here (not in a function); did you mean 'MDP_MAX_EVENT_COUNT'?
44 | struct mdp_comp *comp[MDP_MAX_COMP_COUNT];
| ^~~~~~~~~~~~~~~~~~
| MDP_MAX_EVENT_COUNT
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.c: In function 'get_comp_flag':
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.c:35:38: error: 'MDP_COMP_RDMA0' undeclared (first use in this function)
35 | if (ctx->comp->id == MDP_COMP_RDMA0)
| ^~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.c:35:38: note: each undeclared identifier is reported only once for each function it appears in
In file included from include/linux/bits.h:6,
from include/linux/bitops.h:6,
from include/linux/kernel.h:13,
from include/linux/clk.h:13,
from drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.c:7:
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.c:36:58: error: 'MDP_COMP_RSZ1' undeclared (first use in this function)
36 | return BIT(MDP_COMP_RDMA0) | BIT(MDP_COMP_RSZ1);
| ^~~~~~~~~~~~~
include/vdso/bits.h:7:44: note: in definition of macro 'BIT'
7 | #define BIT(nr) (UL(1) << (nr))
| ^~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.c: At top level:
>> drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.c:41:55: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
41 | static int init_rdma(struct mdp_comp_ctx *ctx, struct mmsys_cmdq_cmd *cmd)
| ^~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.c: In function 'init_rdma':
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.c:48:66: error: 'MDP_COMP_RSZ1' undeclared (first use in this function)
48 | struct mdp_comp *prz1 = ctx->comp->mdp_dev->comp[MDP_COMP_RSZ1];
| ^~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.c:51:38: error: 'MDP_COMP_RDMA0' undeclared (first use in this function)
51 | if (ctx->comp->id == MDP_COMP_RDMA0 && prz1)
| ^~~~~~~~~~~~~~
In file included from drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.c:11:
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:14:34: error: invalid use of undefined type 'struct mmsys_cmdq_cmd'
14 | cmdq_pkt_write_mask((cmd)->pkt, id, \
| ^~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:17:9: note: in expansion of macro 'MM_REG_WRITE_MASK'
17 | MM_REG_WRITE_MASK(cmd, id, base, ofst, val, \
| ^~~~~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.c:52:25: note: in expansion of macro 'MM_REG_WRITE'
52 | MM_REG_WRITE(cmd, subsys_id, prz1->reg_base, PRZ_ENABLE,
| ^~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:14:34: error: invalid use of undefined type 'struct mmsys_cmdq_cmd'
14 | cmdq_pkt_write_mask((cmd)->pkt, id, \
| ^~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:17:9: note: in expansion of macro 'MM_REG_WRITE_MASK'
17 | MM_REG_WRITE_MASK(cmd, id, base, ofst, val, \
| ^~~~~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.c:57:9: note: in expansion of macro 'MM_REG_WRITE'
57 | MM_REG_WRITE(cmd, subsys_id, base, MDP_RDMA_RESET, BIT(0), BIT(0));
| ^~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:34:33: error: invalid use of undefined type 'struct mmsys_cmdq_cmd'
34 | cmdq_pkt_poll_mask((cmd)->pkt, id, \
| ^~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:37:9: note: in expansion of macro 'MM_REG_POLL_MASK'
37 | MM_REG_POLL_MASK((cmd), id, base, ofst, val, \
| ^~~~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.c:58:9: note: in expansion of macro 'MM_REG_POLL'
58 | MM_REG_POLL(cmd, subsys_id, base, MDP_RDMA_MON_STA_1, BIT(8), BIT(8));
| ^~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:14:34: error: invalid use of undefined type 'struct mmsys_cmdq_cmd'
14 | cmdq_pkt_write_mask((cmd)->pkt, id, \
| ^~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:17:9: note: in expansion of macro 'MM_REG_WRITE_MASK'
17 | MM_REG_WRITE_MASK(cmd, id, base, ofst, val, \
| ^~~~~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.c:59:9: note: in expansion of macro 'MM_REG_WRITE'
59 | MM_REG_WRITE(cmd, subsys_id, base, MDP_RDMA_RESET, 0x0, BIT(0));
| ^~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.c: At top level:
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.c:64:37: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
64 | struct mmsys_cmdq_cmd *cmd,
| ^~~~~~~~~~~~~~
In file included from drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.c:11:
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.c: In function 'config_rdma_frame':
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:14:34: error: invalid use of undefined type 'struct mmsys_cmdq_cmd'
14 | cmdq_pkt_write_mask((cmd)->pkt, id, \
| ^~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:17:9: note: in expansion of macro 'MM_REG_WRITE_MASK'
17 | MM_REG_WRITE_MASK(cmd, id, base, ofst, val, \
| ^~~~~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.c:77:25: note: in expansion of macro 'MM_REG_WRITE'
77 | MM_REG_WRITE(cmd, subsys_id, base,
| ^~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:14:34: error: invalid use of undefined type 'struct mmsys_cmdq_cmd'
14 | cmdq_pkt_write_mask((cmd)->pkt, id, \
| ^~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:17:9: note: in expansion of macro 'MM_REG_WRITE_MASK'
17 | MM_REG_WRITE_MASK(cmd, id, base, ofst, val, \
| ^~~~~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.c:80:25: note: in expansion of macro 'MM_REG_WRITE'
80 | MM_REG_WRITE(cmd, subsys_id, base,
| ^~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:14:34: error: invalid use of undefined type 'struct mmsys_cmdq_cmd'
14 | cmdq_pkt_write_mask((cmd)->pkt, id, \
| ^~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:17:9: note: in expansion of macro 'MM_REG_WRITE_MASK'
17 | MM_REG_WRITE_MASK(cmd, id, base, ofst, val, \
| ^~~~~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.c:85:9: note: in expansion of macro 'MM_REG_WRITE'
85 | MM_REG_WRITE(cmd, subsys_id, base, MDP_RDMA_GMCIF_CON,
| ^~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:14:34: error: invalid use of undefined type 'struct mmsys_cmdq_cmd'
14 | cmdq_pkt_write_mask((cmd)->pkt, id, \
| ^~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:17:9: note: in expansion of macro 'MM_REG_WRITE_MASK'
17 | MM_REG_WRITE_MASK(cmd, id, base, ofst, val, \
| ^~~~~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.c:91:9: note: in expansion of macro 'MM_REG_WRITE'
91 | MM_REG_WRITE(cmd, subsys_id, base, MDP_RDMA_SRC_CON, rdma->src_ctrl,
| ^~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:14:34: error: invalid use of undefined type 'struct mmsys_cmdq_cmd'
14 | cmdq_pkt_write_mask((cmd)->pkt, id, \
| ^~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:17:9: note: in expansion of macro 'MM_REG_WRITE_MASK'
17 | MM_REG_WRITE_MASK(cmd, id, base, ofst, val, \
| ^~~~~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.c:97:25: note: in expansion of macro 'MM_REG_WRITE'
97 | MM_REG_WRITE(cmd, subsys_id,
| ^~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:14:34: error: invalid use of undefined type 'struct mmsys_cmdq_cmd'
14 | cmdq_pkt_write_mask((cmd)->pkt, id, \
| ^~
--
In file included from drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.c:9:
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:109:41: error: field 'id' has incomplete type
109 | enum mtk_mdp_comp_id id;
| ^~
>> drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:123:59: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
123 | int (*init_comp)(struct mdp_comp_ctx *ctx, struct mmsys_cmdq_cmd *cmd);
| ^~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:124:62: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
124 | int (*config_frame)(struct mdp_comp_ctx *ctx, struct mmsys_cmdq_cmd *cmd,
| ^~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:127:37: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
127 | struct mmsys_cmdq_cmd *cmd, u32 index);
| ^~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:129:39: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
129 | struct mmsys_cmdq_cmd *cmd);
| ^~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:131:38: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
131 | struct mmsys_cmdq_cmd *cmd, u32 index);
| ^~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:132:62: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
132 | int (*post_process)(struct mdp_comp_ctx *ctx, struct mmsys_cmdq_cmd *cmd);
| ^~~~~~~~~~~~~~
In file included from drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.c:10:
drivers/media/platform/mtk-mdp3/mtk-mdp3-core.h:43:60: error: 'MDP_PIPE_MAX' undeclared here (not in a function)
43 | struct mtk_mutex *mdp_mutex[MDP_PIPE_MAX];
| ^~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-core.h:44:55: error: 'MDP_MAX_COMP_COUNT' undeclared here (not in a function); did you mean 'MDP_MAX_EVENT_COUNT'?
44 | struct mdp_comp *comp[MDP_MAX_COMP_COUNT];
| ^~~~~~~~~~~~~~~~~~
| MDP_MAX_EVENT_COUNT
>> drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.c:47:43: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
47 | struct mmsys_cmdq_cmd *cmd, u32 count)
| ^~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.c: In function 'mdp_path_subfrm_require':
drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.c:62:14: error: 'MDP_COMP_RDMA0' undeclared (first use in this function)
62 | case MDP_COMP_RDMA0:
| ^~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.c:62:14: note: each undeclared identifier is reported only once for each function it appears in
drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.c:63:28: error: 'MDP_PIPE_RDMA0' undeclared (first use in this function)
63 | mutex_id = MDP_PIPE_RDMA0;
| ^~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.c:65:14: error: 'MDP_COMP_ISP_IMGI' undeclared (first use in this function); did you mean 'MDP_COMP_TYPE_IMGI'?
65 | case MDP_COMP_ISP_IMGI:
| ^~~~~~~~~~~~~~~~~
| MDP_COMP_TYPE_IMGI
drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.c:66:28: error: 'MDP_PIPE_IMGI' undeclared (first use in this function)
66 | mutex_id = MDP_PIPE_IMGI;
| ^~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.c:68:14: error: 'MDP_COMP_WPEI' undeclared (first use in this function); did you mean 'MDP_COMP_TYPE_WPEI'?
68 | case MDP_COMP_WPEI:
| ^~~~~~~~~~~~~
| MDP_COMP_TYPE_WPEI
drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.c:69:28: error: 'MDP_PIPE_WPEI' undeclared (first use in this function)
69 | mutex_id = MDP_PIPE_WPEI;
| ^~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.c:71:14: error: 'MDP_COMP_WPEI2' undeclared (first use in this function); did you mean 'MDP_COMP_TYPE_WPEI'?
71 | case MDP_COMP_WPEI2:
| ^~~~~~~~~~~~~~
| MDP_COMP_TYPE_WPEI
drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.c:72:28: error: 'MDP_PIPE_WPEI2' undeclared (first use in this function)
72 | mutex_id = MDP_PIPE_WPEI2;
| ^~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.c:87:22: error: 'MDP_COMP_AAL0' undeclared (first use in this function)
87 | case MDP_COMP_AAL0:
| ^~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.c:88:22: error: 'MDP_COMP_CCORR0' undeclared (first use in this function); did you mean 'MDP_COMP_TYPE_CCORR'?
88 | case MDP_COMP_CCORR0:
| ^~~~~~~~~~~~~~~
| MDP_COMP_TYPE_CCORR
drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.c:89:22: error: 'MDP_COMP_WDMA' undeclared (first use in this function); did you mean 'MDP_COMP_TYPE_WDMA'?
89 | case MDP_COMP_WDMA:
| ^~~~~~~~~~~~~
| MDP_COMP_TYPE_WDMA
drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.c:90:22: error: 'MDP_COMP_WROT0' undeclared (first use in this function)
90 | case MDP_COMP_WROT0:
| ^~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.c:91:22: error: 'MDP_COMP_TDSHP0' undeclared (first use in this function); did you mean 'MDP_COMP_TYPE_HDR'?
91 | case MDP_COMP_TDSHP0:
| ^~~~~~~~~~~~~~~
| MDP_COMP_TYPE_HDR
drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.c:92:22: error: 'MDP_COMP_RSZ1' undeclared (first use in this function)
92 | case MDP_COMP_RSZ1:
| ^~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.c:93:22: error: 'MDP_COMP_RSZ0' undeclared (first use in this function)
93 | case MDP_COMP_RSZ0:
| ^~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.c:95:37: error: implicit declaration of function 'mtk_mutex_get_mdp_mod' [-Werror=implicit-function-declaration]
95 | mutex_bit = mtk_mutex_get_mdp_mod(mutex[mutex_id], id);
| ^~~~~~~~~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.c:104:17: error: implicit declaration of function 'mtk_mutex_add_mod_by_cmdq'; did you mean 'mtk_mutex_add_comp'? [-Werror=implicit-function-declaration]
104 | mtk_mutex_add_mod_by_cmdq(mutex[mutex_id], subfrm->mutex_mod, cmd);
| ^~~~~~~~~~~~~~~~~~~~~~~~~
| mtk_mutex_add_comp
drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.c: At top level:
drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.c:131:39: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
131 | struct mmsys_cmdq_cmd *cmd)
| ^~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.c: In function 'mdp_path_subfrm_run':
drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.c:149:30: error: 'MDP_COMP_RDMA0' undeclared (first use in this function)
149 | case MDP_COMP_RDMA0:
| ^~~~~~~~~~~~~~
In file included from drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.c:9:
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:28:35: error: invalid use of undefined type 'struct mmsys_cmdq_cmd'
28 | cmdq_pkt_clear_event((cmd)->pkt, (cmd)->event[(evt)])
| ^~
drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.c:150:33: note: in expansion of macro 'MM_REG_CLEAR'
150 | MM_REG_CLEAR(cmd, RDMA0_SOF);
| ^~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:28:47: error: invalid use of undefined type 'struct mmsys_cmdq_cmd'
28 | cmdq_pkt_clear_event((cmd)->pkt, (cmd)->event[(evt)])
| ^~
drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.c:150:33: note: in expansion of macro 'MM_REG_CLEAR'
150 | MM_REG_CLEAR(cmd, RDMA0_SOF);
| ^~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.c:152:30: error: 'MDP_COMP_TDSHP0' undeclared (first use in this function); did you mean 'MDP_COMP_TYPE_HDR'?
152 | case MDP_COMP_TDSHP0:
| ^~~~~~~~~~~~~~~
| MDP_COMP_TYPE_HDR
In file included from drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.c:9:
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:28:35: error: invalid use of undefined type 'struct mmsys_cmdq_cmd'
28 | cmdq_pkt_clear_event((cmd)->pkt, (cmd)->event[(evt)])
| ^~
drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.c:153:33: note: in expansion of macro 'MM_REG_CLEAR'
153 | MM_REG_CLEAR(cmd, TDSHP0_SOF);
| ^~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:28:47: error: invalid use of undefined type 'struct mmsys_cmdq_cmd'
28 | cmdq_pkt_clear_event((cmd)->pkt, (cmd)->event[(evt)])
| ^~
drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.c:153:33: note: in expansion of macro 'MM_REG_CLEAR'
153 | MM_REG_CLEAR(cmd, TDSHP0_SOF);
| ^~~~~~~~~~~~
vim +123 drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h
100
101 struct mdp_comp {
102 struct mdp_dev *mdp_dev;
103 void __iomem *regs;
104 phys_addr_t reg_base;
105 u8 subsys_id;
106 struct clk *clks[6];
107 struct device *comp_dev;
108 enum mdp_comp_type type;
> 109 enum mtk_mdp_comp_id id;
110 u32 alias_id;
111 const struct mdp_comp_ops *ops;
112 };
113
114 struct mdp_comp_ctx {
115 struct mdp_comp *comp;
116 const struct img_compparam *param;
117 const struct img_input *input;
118 const struct img_output *outputs[IMG_MAX_HW_OUTPUTS];
119 };
120
121 struct mdp_comp_ops {
122 s64 (*get_comp_flag)(const struct mdp_comp_ctx *ctx);
> 123 int (*init_comp)(struct mdp_comp_ctx *ctx, struct mmsys_cmdq_cmd *cmd);
124 int (*config_frame)(struct mdp_comp_ctx *ctx, struct mmsys_cmdq_cmd *cmd,
125 const struct v4l2_rect *compose);
126 int (*config_subfrm)(struct mdp_comp_ctx *ctx,
127 struct mmsys_cmdq_cmd *cmd, u32 index);
128 int (*wait_comp_event)(struct mdp_comp_ctx *ctx,
129 struct mmsys_cmdq_cmd *cmd);
130 int (*advance_subfrm)(struct mdp_comp_ctx *ctx,
131 struct mmsys_cmdq_cmd *cmd, u32 index);
132 int (*post_process)(struct mdp_comp_ctx *ctx, struct mmsys_cmdq_cmd *cmd);
133 };
134
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* [helgaas-pci:pci/vga2] BUILD SUCCESS 91ca1c7c1e057c0bddffe043c0e74ae9f9ec756e
From: kernel test robot @ 2022-01-05 18:21 UTC (permalink / raw)
To: Bjorn Helgaas; +Cc: linux-pci
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git pci/vga2
branch HEAD: 91ca1c7c1e057c0bddffe043c0e74ae9f9ec756e vgaarb: Use disabled device as last resort
elapsed time: 724m
configs tested: 141
configs skipped: 4
The following configs have been built successfully.
More configs may be tested in the coming days.
gcc tested configs:
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm allmodconfig
i386 randconfig-c001-20220105
mips db1xxx_defconfig
sh apsh4a3a_defconfig
sh microdev_defconfig
arc hsdk_defconfig
powerpc mpc834x_mds_defconfig
arm xcep_defconfig
ia64 zx1_defconfig
sh se7705_defconfig
sh kfr2r09-romimage_defconfig
sh migor_defconfig
xtensa cadence_csp_defconfig
mips rt305x_defconfig
sh defconfig
arc vdk_hs38_defconfig
mips allyesconfig
sh edosk7760_defconfig
arm pleb_defconfig
xtensa alldefconfig
microblaze mmu_defconfig
sh sh7785lcr_32bit_defconfig
arm zeus_defconfig
ia64 defconfig
arm sunxi_defconfig
powerpc tqm8xx_defconfig
powerpc linkstation_defconfig
arm stm32_defconfig
powerpc warp_defconfig
arm lpd270_defconfig
m68k m5475evb_defconfig
m68k apollo_defconfig
m68k allmodconfig
arm rpc_defconfig
sh apsh4ad0a_defconfig
arm shmobile_defconfig
mips fuloong2e_defconfig
arm u8500_defconfig
h8300 defconfig
powerpc allnoconfig
powerpc klondike_defconfig
arm realview_defconfig
powerpc sequoia_defconfig
powerpc makalu_defconfig
arm spear6xx_defconfig
powerpc ppc64_defconfig
powerpc iss476-smp_defconfig
i386 alldefconfig
nds32 defconfig
mips maltasmvp_eva_defconfig
powerpc mpc85xx_cds_defconfig
h8300 allyesconfig
sh sh7770_generic_defconfig
powerpc tqm8555_defconfig
sh shmin_defconfig
arm randconfig-c002-20220105
ia64 allmodconfig
ia64 allyesconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
arc defconfig
sh allmodconfig
parisc defconfig
s390 allmodconfig
s390 defconfig
s390 allyesconfig
parisc allyesconfig
i386 allyesconfig
sparc allyesconfig
sparc defconfig
i386 defconfig
i386 debian-10.3-kselftests
i386 debian-10.3
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
x86_64 randconfig-a005-20220105
x86_64 randconfig-a001-20220105
x86_64 randconfig-a004-20220105
x86_64 randconfig-a006-20220105
x86_64 randconfig-a003-20220105
x86_64 randconfig-a002-20220105
i386 randconfig-a003-20220105
i386 randconfig-a005-20220105
i386 randconfig-a004-20220105
i386 randconfig-a006-20220105
i386 randconfig-a002-20220105
i386 randconfig-a001-20220105
riscv nommu_k210_defconfig
riscv allyesconfig
riscv nommu_virt_defconfig
riscv allnoconfig
riscv defconfig
riscv rv32_defconfig
riscv allmodconfig
x86_64 rhel-8.3-kselftests
um x86_64_defconfig
um i386_defconfig
x86_64 allyesconfig
x86_64 defconfig
x86_64 rhel-8.3
x86_64 rhel-8.3-func
x86_64 kexec
clang tested configs:
powerpc mpc885_ads_defconfig
arm multi_v5_defconfig
riscv rv32_defconfig
powerpc mpc8313_rdb_defconfig
powerpc akebono_defconfig
arm hackkit_defconfig
arm alldefconfig
powerpc lite5200b_defconfig
arm dove_defconfig
mips qi_lb60_defconfig
arm spitz_defconfig
arm s3c2410_defconfig
x86_64 randconfig-a012-20220105
x86_64 randconfig-a015-20220105
x86_64 randconfig-a014-20220105
x86_64 randconfig-a013-20220105
x86_64 randconfig-a011-20220105
x86_64 randconfig-a016-20220105
i386 randconfig-a012-20220105
i386 randconfig-a016-20220105
i386 randconfig-a015-20220105
i386 randconfig-a014-20220105
i386 randconfig-a011-20220105
i386 randconfig-a013-20220105
hexagon randconfig-r041-20220105
hexagon randconfig-r045-20220105
riscv randconfig-r042-20220105
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* Re: [PATCH v2] drm/amdgpu: Unmap MMIO mappings when device is not unplugged
From: Andrey Grodzovsky @ 2022-01-05 18:21 UTC (permalink / raw)
To: Leslie Shi, lijo.lazar, amd-gfx; +Cc: guchun.chen
In-Reply-To: <20220105042344.988200-1-Yuliang.Shi@amd.com>
On 2022-01-04 11:23 p.m., Leslie Shi wrote:
> Patch: 3efb17ae7e92 ("drm/amdgpu: Call amdgpu_device_unmap_mmio() if device
> is unplugged to prevent crash in GPU initialization failure") makes call to
> amdgpu_device_unmap_mmio() conditioned on device unplugged. This patch unmaps
> MMIO mappings even when device is not unplugged.
I don't see the 'call to amdgpu_device_unmap_mmio() conditioned on
device unplugged'
part in this patch
Also, please add 'v2:bla bla bla' part in patch description telling what
was done in v2
Andrey
>
> Signed-off-by: Leslie Shi <Yuliang.Shi@amd.com>
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 11 +++++++++++
> drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 12 ++++++++++++
> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 11 +++++++++++
> 3 files changed, 34 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> index 412f377f80b1..16dc16c860cc 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> @@ -3832,6 +3832,7 @@ int amdgpu_device_init(struct amdgpu_device *adev,
>
> static void amdgpu_device_unmap_mmio(struct amdgpu_device *adev)
> {
> +
> /* Clear all CPU mappings pointing to this device */
> unmap_mapping_range(adev->ddev.anon_inode->i_mapping, 0, 0, 1);
>
> @@ -3912,6 +3913,8 @@ void amdgpu_device_fini_hw(struct amdgpu_device *adev)
>
> void amdgpu_device_fini_sw(struct amdgpu_device *adev)
> {
> + int idx;
> +
> amdgpu_fence_driver_sw_fini(adev);
> amdgpu_device_ip_fini(adev);
> release_firmware(adev->firmware.gpu_info_fw);
> @@ -3936,6 +3939,14 @@ void amdgpu_device_fini_sw(struct amdgpu_device *adev)
> if ((adev->pdev->class >> 8) == PCI_CLASS_DISPLAY_VGA)
> vga_client_register(adev->pdev, NULL, NULL, NULL);
>
> + if (drm_dev_enter(adev_to_drm(adev), &idx)) {
> +
> + iounmap(adev->rmmio);
> + adev->rmmio = NULL;
> + amdgpu_device_doorbell_fini(adev);
> + drm_dev_exit(idx);
> + }
> +
> if (IS_ENABLED(CONFIG_PERF_EVENTS))
> amdgpu_pmu_fini(adev);
> if (adev->mman.discovery_bin)
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> index 156002db24e1..ff9dc377a3a0 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> @@ -33,6 +33,7 @@
> #include <linux/slab.h>
> #include <linux/dma-buf.h>
>
> +#include <drm/drm_drv.h>
> #include <drm/amdgpu_drm.h>
> #include <drm/drm_cache.h>
> #include "amdgpu.h"
> @@ -1061,7 +1062,18 @@ int amdgpu_bo_init(struct amdgpu_device *adev)
> */
> void amdgpu_bo_fini(struct amdgpu_device *adev)
> {
> + int idx;
> +
> amdgpu_ttm_fini(adev);
> +
> + if (drm_dev_enter(adev_to_drm(adev), &idx)) {
> +
> + if (!adev->gmc.xgmi.connected_to_cpu) {
> + arch_phys_wc_del(adev->gmc.vram_mtrr);
> + arch_io_free_memtype_wc(adev->gmc.aper_base, adev->gmc.aper_size);
> + }
> + drm_dev_exit(idx);
> + }
> }
>
> /**
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> index 367abed1d6e6..ea897feeddd2 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> @@ -42,6 +42,7 @@
> #include <linux/dma-buf.h>
> #include <linux/sizes.h>
>
> +#include <drm/drm_drv.h>
> #include <drm/ttm/ttm_bo_api.h>
> #include <drm/ttm/ttm_bo_driver.h>
> #include <drm/ttm/ttm_placement.h>
> @@ -1801,6 +1802,7 @@ int amdgpu_ttm_init(struct amdgpu_device *adev)
> */
> void amdgpu_ttm_fini(struct amdgpu_device *adev)
> {
> + int idx;
> if (!adev->mman.initialized)
> return;
>
> @@ -1815,6 +1817,15 @@ void amdgpu_ttm_fini(struct amdgpu_device *adev)
> NULL, NULL);
> amdgpu_ttm_fw_reserve_vram_fini(adev);
>
> + if (drm_dev_enter(adev_to_drm(adev), &idx)) {
> +
> + if (adev->mman.aper_base_kaddr)
> + iounmap(adev->mman.aper_base_kaddr);
> + adev->mman.aper_base_kaddr = NULL;
> +
> + drm_dev_exit(idx);
> + }
> +
> amdgpu_vram_mgr_fini(adev);
> amdgpu_gtt_mgr_fini(adev);
> amdgpu_preempt_mgr_fini(adev);
^ permalink raw reply
* Re: [PATCH] arm64: Use correct method to calculate nomap region boundaries
From: Catalin Marinas @ 2022-01-05 18:20 UTC (permalink / raw)
To: Huacai Chen, Will Deacon, Arnd Bergmann
Cc: linux-arm-kernel, Huacai Chen, Jiaxun Yang
In-Reply-To: <20211022070646.41923-1-chenhuacai@loongson.cn>
On Fri, 22 Oct 2021 15:06:46 +0800, Huacai Chen wrote:
> Nomap regions are treated as "reserved". When region boundaries are not
> page aligned, we usually increase the "reserved" regions rather than
> decrease them. So, we should use memblock_region_reserved_base_pfn()/
> memblock_region_reserved_end_pfn() instead of memblock_region_memory_
> base_pfn()/memblock_region_memory_base_pfn() to calculate boundaries.
>
>
> [...]
Applied to arm64 (for-next/misc), thanks!
[1/1] arm64: Use correct method to calculate nomap region boundaries
https://git.kernel.org/arm64/c/daa149dd8cd4
--
Catalin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm64: Drop outdated links in comments
From: Catalin Marinas @ 2022-01-05 18:21 UTC (permalink / raw)
To: Joe Perches, Will Deacon, Kees Cook
Cc: linux-kernel, James Morse, Pasha Tatashin, linux-arm-kernel,
Vincenzo Frascino, Fuad Tabba, Russell King
In-Reply-To: <20211215191835.1420010-1-keescook@chromium.org>
On Wed, 15 Dec 2021 11:18:35 -0800, Kees Cook wrote:
> As started by commit 05a5f51ca566 ("Documentation: Replace lkml.org links
> with lore"), an effort was made to replace lkml.org links with lore to
> better use a single source that's more likely to stay available long-term.
> However, it seems these links don't offer much value here, so just
> remove them entirely.
>
>
> [...]
Applied to arm64 (for-next/misc) but without the arch/arm changes.
Please send them separately to Russell's patch system. Thanks!
[1/1] arm64: Drop outdated links in comments
https://git.kernel.org/arm64/c/89d30b11507d
--
Catalin
^ permalink raw reply
* Re: [PATCH v11 3/3] media: platform: mtk-mdp3: add Mediatek MDP3 driver
From: kernel test robot @ 2022-01-05 18:21 UTC (permalink / raw)
To: kbuild-all
In-Reply-To: <20220105093758.6850-4-moudy.ho@mediatek.com>
[-- Attachment #1: Type: text/plain, Size: 37240 bytes --]
Hi Moudy,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on media-tree/master]
[also build test WARNING on robh/for-next v5.16-rc8 next-20220105]
[cannot apply to mbgg-mediatek/for-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url: https://github.com/0day-ci/linux/commits/Moudy-Ho/media-mediatek-support-mdp3-on-mt8183-platform/20220105-173918
base: git://linuxtv.org/media_tree.git master
config: ia64-allyesconfig (https://download.01.org/0day-ci/archive/20220106/202201060241.t95Ra9LM-lkp(a)intel.com/config)
compiler: ia64-linux-gcc (GCC) 11.2.0
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# https://github.com/0day-ci/linux/commit/696f7ac402f9778a21202f2b889c3c30a6923b3d
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review Moudy-Ho/media-mediatek-support-mdp3-on-mt8183-platform/20220105-173918
git checkout 696f7ac402f9778a21202f2b889c3c30a6923b3d
# save the config file to linux build tree
mkdir build_dir
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.2.0 make.cross O=build_dir ARCH=ia64 SHELL=/bin/bash drivers/media/
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
All warnings (new ones prefixed by >>):
In file included from drivers/media/platform/mtk-mdp3/mtk-mdp3-core.h:14,
from drivers/media/platform/mtk-mdp3/mtk-mdp3-core.c:15:
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:109:41: error: field 'id' has incomplete type
109 | enum mtk_mdp_comp_id id;
| ^~
>> drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:123:59: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
123 | int (*init_comp)(struct mdp_comp_ctx *ctx, struct mmsys_cmdq_cmd *cmd);
| ^~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:124:62: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
124 | int (*config_frame)(struct mdp_comp_ctx *ctx, struct mmsys_cmdq_cmd *cmd,
| ^~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:127:37: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
127 | struct mmsys_cmdq_cmd *cmd, u32 index);
| ^~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:129:39: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
129 | struct mmsys_cmdq_cmd *cmd);
| ^~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:131:38: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
131 | struct mmsys_cmdq_cmd *cmd, u32 index);
| ^~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:132:62: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
132 | int (*post_process)(struct mdp_comp_ctx *ctx, struct mmsys_cmdq_cmd *cmd);
| ^~~~~~~~~~~~~~
In file included from drivers/media/platform/mtk-mdp3/mtk-mdp3-core.c:15:
drivers/media/platform/mtk-mdp3/mtk-mdp3-core.h:43:60: error: 'MDP_PIPE_MAX' undeclared here (not in a function); did you mean 'SCP_IPI_MAX'?
43 | struct mtk_mutex *mdp_mutex[MDP_PIPE_MAX];
| ^~~~~~~~~~~~
| SCP_IPI_MAX
drivers/media/platform/mtk-mdp3/mtk-mdp3-core.h:44:55: error: 'MDP_MAX_COMP_COUNT' undeclared here (not in a function); did you mean 'MDP_MAX_EVENT_COUNT'?
44 | struct mdp_comp *comp[MDP_MAX_COMP_COUNT];
| ^~~~~~~~~~~~~~~~~~
| MDP_MAX_EVENT_COUNT
drivers/media/platform/mtk-mdp3/mtk-mdp3-core.c: In function 'mdp_probe':
drivers/media/platform/mtk-mdp3/mtk-mdp3-core.c:192:37: error: implicit declaration of function 'mtk_mutex_mdp_get'; did you mean 'mtk_mutex_get'? [-Werror=implicit-function-declaration]
192 | mdp->mdp_mutex[i] = mtk_mutex_mdp_get(&mm_pdev->dev, i);
| ^~~~~~~~~~~~~~~~~
| mtk_mutex_get
cc1: some warnings being treated as errors
--
In file included from drivers/media/platform/mtk-mdp3/mtk-mdp3-core.h:14,
from drivers/media/platform/mtk-mdp3/mtk-mdp3-vpu.c:10:
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:109:41: error: field 'id' has incomplete type
109 | enum mtk_mdp_comp_id id;
| ^~
>> drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:123:59: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
123 | int (*init_comp)(struct mdp_comp_ctx *ctx, struct mmsys_cmdq_cmd *cmd);
| ^~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:124:62: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
124 | int (*config_frame)(struct mdp_comp_ctx *ctx, struct mmsys_cmdq_cmd *cmd,
| ^~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:127:37: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
127 | struct mmsys_cmdq_cmd *cmd, u32 index);
| ^~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:129:39: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
129 | struct mmsys_cmdq_cmd *cmd);
| ^~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:131:38: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
131 | struct mmsys_cmdq_cmd *cmd, u32 index);
| ^~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:132:62: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
132 | int (*post_process)(struct mdp_comp_ctx *ctx, struct mmsys_cmdq_cmd *cmd);
| ^~~~~~~~~~~~~~
In file included from drivers/media/platform/mtk-mdp3/mtk-mdp3-vpu.c:10:
drivers/media/platform/mtk-mdp3/mtk-mdp3-core.h:43:60: error: 'MDP_PIPE_MAX' undeclared here (not in a function); did you mean 'SCP_IPI_MAX'?
43 | struct mtk_mutex *mdp_mutex[MDP_PIPE_MAX];
| ^~~~~~~~~~~~
| SCP_IPI_MAX
drivers/media/platform/mtk-mdp3/mtk-mdp3-core.h:44:55: error: 'MDP_MAX_COMP_COUNT' undeclared here (not in a function); did you mean 'MDP_MAX_EVENT_COUNT'?
44 | struct mdp_comp *comp[MDP_MAX_COMP_COUNT];
| ^~~~~~~~~~~~~~~~~~
| MDP_MAX_EVENT_COUNT
--
In file included from drivers/media/platform/mtk-mdp3/mtk-mdp3-core.h:14,
from drivers/media/platform/mtk-mdp3/mtk-mdp3-regs.c:10:
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:109:41: error: field 'id' has incomplete type
109 | enum mtk_mdp_comp_id id;
| ^~
>> drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:123:59: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
123 | int (*init_comp)(struct mdp_comp_ctx *ctx, struct mmsys_cmdq_cmd *cmd);
| ^~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:124:62: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
124 | int (*config_frame)(struct mdp_comp_ctx *ctx, struct mmsys_cmdq_cmd *cmd,
| ^~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:127:37: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
127 | struct mmsys_cmdq_cmd *cmd, u32 index);
| ^~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:129:39: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
129 | struct mmsys_cmdq_cmd *cmd);
| ^~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:131:38: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
131 | struct mmsys_cmdq_cmd *cmd, u32 index);
| ^~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:132:62: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
132 | int (*post_process)(struct mdp_comp_ctx *ctx, struct mmsys_cmdq_cmd *cmd);
| ^~~~~~~~~~~~~~
In file included from drivers/media/platform/mtk-mdp3/mtk-mdp3-regs.c:10:
drivers/media/platform/mtk-mdp3/mtk-mdp3-core.h:43:60: error: 'MDP_PIPE_MAX' undeclared here (not in a function)
43 | struct mtk_mutex *mdp_mutex[MDP_PIPE_MAX];
| ^~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-core.h:44:55: error: 'MDP_MAX_COMP_COUNT' undeclared here (not in a function); did you mean 'MDP_MAX_EVENT_COUNT'?
44 | struct mdp_comp *comp[MDP_MAX_COMP_COUNT];
| ^~~~~~~~~~~~~~~~~~
| MDP_MAX_EVENT_COUNT
--
In file included from drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.c:11:
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:109:41: error: field 'id' has incomplete type
109 | enum mtk_mdp_comp_id id;
| ^~
>> drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:123:59: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
123 | int (*init_comp)(struct mdp_comp_ctx *ctx, struct mmsys_cmdq_cmd *cmd);
| ^~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:124:62: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
124 | int (*config_frame)(struct mdp_comp_ctx *ctx, struct mmsys_cmdq_cmd *cmd,
| ^~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:127:37: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
127 | struct mmsys_cmdq_cmd *cmd, u32 index);
| ^~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:129:39: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
129 | struct mmsys_cmdq_cmd *cmd);
| ^~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:131:38: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
131 | struct mmsys_cmdq_cmd *cmd, u32 index);
| ^~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:132:62: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
132 | int (*post_process)(struct mdp_comp_ctx *ctx, struct mmsys_cmdq_cmd *cmd);
| ^~~~~~~~~~~~~~
In file included from drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.c:12:
drivers/media/platform/mtk-mdp3/mtk-mdp3-core.h:43:60: error: 'MDP_PIPE_MAX' undeclared here (not in a function)
43 | struct mtk_mutex *mdp_mutex[MDP_PIPE_MAX];
| ^~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-core.h:44:55: error: 'MDP_MAX_COMP_COUNT' undeclared here (not in a function); did you mean 'MDP_MAX_EVENT_COUNT'?
44 | struct mdp_comp *comp[MDP_MAX_COMP_COUNT];
| ^~~~~~~~~~~~~~~~~~
| MDP_MAX_EVENT_COUNT
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.c: In function 'get_comp_flag':
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.c:35:38: error: 'MDP_COMP_RDMA0' undeclared (first use in this function)
35 | if (ctx->comp->id == MDP_COMP_RDMA0)
| ^~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.c:35:38: note: each undeclared identifier is reported only once for each function it appears in
In file included from include/linux/bits.h:6,
from include/linux/bitops.h:6,
from include/linux/kernel.h:13,
from include/linux/clk.h:13,
from drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.c:7:
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.c:36:58: error: 'MDP_COMP_RSZ1' undeclared (first use in this function)
36 | return BIT(MDP_COMP_RDMA0) | BIT(MDP_COMP_RSZ1);
| ^~~~~~~~~~~~~
include/vdso/bits.h:7:44: note: in definition of macro 'BIT'
7 | #define BIT(nr) (UL(1) << (nr))
| ^~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.c: At top level:
>> drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.c:41:55: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
41 | static int init_rdma(struct mdp_comp_ctx *ctx, struct mmsys_cmdq_cmd *cmd)
| ^~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.c: In function 'init_rdma':
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.c:48:66: error: 'MDP_COMP_RSZ1' undeclared (first use in this function)
48 | struct mdp_comp *prz1 = ctx->comp->mdp_dev->comp[MDP_COMP_RSZ1];
| ^~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.c:51:38: error: 'MDP_COMP_RDMA0' undeclared (first use in this function)
51 | if (ctx->comp->id == MDP_COMP_RDMA0 && prz1)
| ^~~~~~~~~~~~~~
In file included from drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.c:11:
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:14:34: error: invalid use of undefined type 'struct mmsys_cmdq_cmd'
14 | cmdq_pkt_write_mask((cmd)->pkt, id, \
| ^~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:17:9: note: in expansion of macro 'MM_REG_WRITE_MASK'
17 | MM_REG_WRITE_MASK(cmd, id, base, ofst, val, \
| ^~~~~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.c:52:25: note: in expansion of macro 'MM_REG_WRITE'
52 | MM_REG_WRITE(cmd, subsys_id, prz1->reg_base, PRZ_ENABLE,
| ^~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:14:34: error: invalid use of undefined type 'struct mmsys_cmdq_cmd'
14 | cmdq_pkt_write_mask((cmd)->pkt, id, \
| ^~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:17:9: note: in expansion of macro 'MM_REG_WRITE_MASK'
17 | MM_REG_WRITE_MASK(cmd, id, base, ofst, val, \
| ^~~~~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.c:57:9: note: in expansion of macro 'MM_REG_WRITE'
57 | MM_REG_WRITE(cmd, subsys_id, base, MDP_RDMA_RESET, BIT(0), BIT(0));
| ^~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:34:33: error: invalid use of undefined type 'struct mmsys_cmdq_cmd'
34 | cmdq_pkt_poll_mask((cmd)->pkt, id, \
| ^~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:37:9: note: in expansion of macro 'MM_REG_POLL_MASK'
37 | MM_REG_POLL_MASK((cmd), id, base, ofst, val, \
| ^~~~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.c:58:9: note: in expansion of macro 'MM_REG_POLL'
58 | MM_REG_POLL(cmd, subsys_id, base, MDP_RDMA_MON_STA_1, BIT(8), BIT(8));
| ^~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:14:34: error: invalid use of undefined type 'struct mmsys_cmdq_cmd'
14 | cmdq_pkt_write_mask((cmd)->pkt, id, \
| ^~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:17:9: note: in expansion of macro 'MM_REG_WRITE_MASK'
17 | MM_REG_WRITE_MASK(cmd, id, base, ofst, val, \
| ^~~~~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.c:59:9: note: in expansion of macro 'MM_REG_WRITE'
59 | MM_REG_WRITE(cmd, subsys_id, base, MDP_RDMA_RESET, 0x0, BIT(0));
| ^~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.c: At top level:
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.c:64:37: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
64 | struct mmsys_cmdq_cmd *cmd,
| ^~~~~~~~~~~~~~
In file included from drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.c:11:
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.c: In function 'config_rdma_frame':
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:14:34: error: invalid use of undefined type 'struct mmsys_cmdq_cmd'
14 | cmdq_pkt_write_mask((cmd)->pkt, id, \
| ^~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:17:9: note: in expansion of macro 'MM_REG_WRITE_MASK'
17 | MM_REG_WRITE_MASK(cmd, id, base, ofst, val, \
| ^~~~~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.c:77:25: note: in expansion of macro 'MM_REG_WRITE'
77 | MM_REG_WRITE(cmd, subsys_id, base,
| ^~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:14:34: error: invalid use of undefined type 'struct mmsys_cmdq_cmd'
14 | cmdq_pkt_write_mask((cmd)->pkt, id, \
| ^~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:17:9: note: in expansion of macro 'MM_REG_WRITE_MASK'
17 | MM_REG_WRITE_MASK(cmd, id, base, ofst, val, \
| ^~~~~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.c:80:25: note: in expansion of macro 'MM_REG_WRITE'
80 | MM_REG_WRITE(cmd, subsys_id, base,
| ^~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:14:34: error: invalid use of undefined type 'struct mmsys_cmdq_cmd'
14 | cmdq_pkt_write_mask((cmd)->pkt, id, \
| ^~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:17:9: note: in expansion of macro 'MM_REG_WRITE_MASK'
17 | MM_REG_WRITE_MASK(cmd, id, base, ofst, val, \
| ^~~~~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.c:85:9: note: in expansion of macro 'MM_REG_WRITE'
85 | MM_REG_WRITE(cmd, subsys_id, base, MDP_RDMA_GMCIF_CON,
| ^~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:14:34: error: invalid use of undefined type 'struct mmsys_cmdq_cmd'
14 | cmdq_pkt_write_mask((cmd)->pkt, id, \
| ^~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:17:9: note: in expansion of macro 'MM_REG_WRITE_MASK'
17 | MM_REG_WRITE_MASK(cmd, id, base, ofst, val, \
| ^~~~~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.c:91:9: note: in expansion of macro 'MM_REG_WRITE'
91 | MM_REG_WRITE(cmd, subsys_id, base, MDP_RDMA_SRC_CON, rdma->src_ctrl,
| ^~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:14:34: error: invalid use of undefined type 'struct mmsys_cmdq_cmd'
14 | cmdq_pkt_write_mask((cmd)->pkt, id, \
| ^~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:17:9: note: in expansion of macro 'MM_REG_WRITE_MASK'
17 | MM_REG_WRITE_MASK(cmd, id, base, ofst, val, \
| ^~~~~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.c:97:25: note: in expansion of macro 'MM_REG_WRITE'
97 | MM_REG_WRITE(cmd, subsys_id,
| ^~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:14:34: error: invalid use of undefined type 'struct mmsys_cmdq_cmd'
14 | cmdq_pkt_write_mask((cmd)->pkt, id, \
| ^~
--
In file included from drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.c:9:
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:109:41: error: field 'id' has incomplete type
109 | enum mtk_mdp_comp_id id;
| ^~
>> drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:123:59: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
123 | int (*init_comp)(struct mdp_comp_ctx *ctx, struct mmsys_cmdq_cmd *cmd);
| ^~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:124:62: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
124 | int (*config_frame)(struct mdp_comp_ctx *ctx, struct mmsys_cmdq_cmd *cmd,
| ^~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:127:37: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
127 | struct mmsys_cmdq_cmd *cmd, u32 index);
| ^~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:129:39: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
129 | struct mmsys_cmdq_cmd *cmd);
| ^~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:131:38: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
131 | struct mmsys_cmdq_cmd *cmd, u32 index);
| ^~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:132:62: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
132 | int (*post_process)(struct mdp_comp_ctx *ctx, struct mmsys_cmdq_cmd *cmd);
| ^~~~~~~~~~~~~~
In file included from drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.c:10:
drivers/media/platform/mtk-mdp3/mtk-mdp3-core.h:43:60: error: 'MDP_PIPE_MAX' undeclared here (not in a function)
43 | struct mtk_mutex *mdp_mutex[MDP_PIPE_MAX];
| ^~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-core.h:44:55: error: 'MDP_MAX_COMP_COUNT' undeclared here (not in a function); did you mean 'MDP_MAX_EVENT_COUNT'?
44 | struct mdp_comp *comp[MDP_MAX_COMP_COUNT];
| ^~~~~~~~~~~~~~~~~~
| MDP_MAX_EVENT_COUNT
>> drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.c:47:43: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
47 | struct mmsys_cmdq_cmd *cmd, u32 count)
| ^~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.c: In function 'mdp_path_subfrm_require':
drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.c:62:14: error: 'MDP_COMP_RDMA0' undeclared (first use in this function)
62 | case MDP_COMP_RDMA0:
| ^~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.c:62:14: note: each undeclared identifier is reported only once for each function it appears in
drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.c:63:28: error: 'MDP_PIPE_RDMA0' undeclared (first use in this function)
63 | mutex_id = MDP_PIPE_RDMA0;
| ^~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.c:65:14: error: 'MDP_COMP_ISP_IMGI' undeclared (first use in this function); did you mean 'MDP_COMP_TYPE_IMGI'?
65 | case MDP_COMP_ISP_IMGI:
| ^~~~~~~~~~~~~~~~~
| MDP_COMP_TYPE_IMGI
drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.c:66:28: error: 'MDP_PIPE_IMGI' undeclared (first use in this function)
66 | mutex_id = MDP_PIPE_IMGI;
| ^~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.c:68:14: error: 'MDP_COMP_WPEI' undeclared (first use in this function); did you mean 'MDP_COMP_TYPE_WPEI'?
68 | case MDP_COMP_WPEI:
| ^~~~~~~~~~~~~
| MDP_COMP_TYPE_WPEI
drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.c:69:28: error: 'MDP_PIPE_WPEI' undeclared (first use in this function)
69 | mutex_id = MDP_PIPE_WPEI;
| ^~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.c:71:14: error: 'MDP_COMP_WPEI2' undeclared (first use in this function); did you mean 'MDP_COMP_TYPE_WPEI'?
71 | case MDP_COMP_WPEI2:
| ^~~~~~~~~~~~~~
| MDP_COMP_TYPE_WPEI
drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.c:72:28: error: 'MDP_PIPE_WPEI2' undeclared (first use in this function)
72 | mutex_id = MDP_PIPE_WPEI2;
| ^~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.c:87:22: error: 'MDP_COMP_AAL0' undeclared (first use in this function)
87 | case MDP_COMP_AAL0:
| ^~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.c:88:22: error: 'MDP_COMP_CCORR0' undeclared (first use in this function); did you mean 'MDP_COMP_TYPE_CCORR'?
88 | case MDP_COMP_CCORR0:
| ^~~~~~~~~~~~~~~
| MDP_COMP_TYPE_CCORR
drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.c:89:22: error: 'MDP_COMP_WDMA' undeclared (first use in this function); did you mean 'MDP_COMP_TYPE_WDMA'?
89 | case MDP_COMP_WDMA:
| ^~~~~~~~~~~~~
| MDP_COMP_TYPE_WDMA
drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.c:90:22: error: 'MDP_COMP_WROT0' undeclared (first use in this function)
90 | case MDP_COMP_WROT0:
| ^~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.c:91:22: error: 'MDP_COMP_TDSHP0' undeclared (first use in this function); did you mean 'MDP_COMP_TYPE_HDR'?
91 | case MDP_COMP_TDSHP0:
| ^~~~~~~~~~~~~~~
| MDP_COMP_TYPE_HDR
drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.c:92:22: error: 'MDP_COMP_RSZ1' undeclared (first use in this function)
92 | case MDP_COMP_RSZ1:
| ^~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.c:93:22: error: 'MDP_COMP_RSZ0' undeclared (first use in this function)
93 | case MDP_COMP_RSZ0:
| ^~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.c:95:37: error: implicit declaration of function 'mtk_mutex_get_mdp_mod' [-Werror=implicit-function-declaration]
95 | mutex_bit = mtk_mutex_get_mdp_mod(mutex[mutex_id], id);
| ^~~~~~~~~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.c:104:17: error: implicit declaration of function 'mtk_mutex_add_mod_by_cmdq'; did you mean 'mtk_mutex_add_comp'? [-Werror=implicit-function-declaration]
104 | mtk_mutex_add_mod_by_cmdq(mutex[mutex_id], subfrm->mutex_mod, cmd);
| ^~~~~~~~~~~~~~~~~~~~~~~~~
| mtk_mutex_add_comp
drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.c: At top level:
drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.c:131:39: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
131 | struct mmsys_cmdq_cmd *cmd)
| ^~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.c: In function 'mdp_path_subfrm_run':
drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.c:149:30: error: 'MDP_COMP_RDMA0' undeclared (first use in this function)
149 | case MDP_COMP_RDMA0:
| ^~~~~~~~~~~~~~
In file included from drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.c:9:
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:28:35: error: invalid use of undefined type 'struct mmsys_cmdq_cmd'
28 | cmdq_pkt_clear_event((cmd)->pkt, (cmd)->event[(evt)])
| ^~
drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.c:150:33: note: in expansion of macro 'MM_REG_CLEAR'
150 | MM_REG_CLEAR(cmd, RDMA0_SOF);
| ^~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:28:47: error: invalid use of undefined type 'struct mmsys_cmdq_cmd'
28 | cmdq_pkt_clear_event((cmd)->pkt, (cmd)->event[(evt)])
| ^~
drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.c:150:33: note: in expansion of macro 'MM_REG_CLEAR'
150 | MM_REG_CLEAR(cmd, RDMA0_SOF);
| ^~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.c:152:30: error: 'MDP_COMP_TDSHP0' undeclared (first use in this function); did you mean 'MDP_COMP_TYPE_HDR'?
152 | case MDP_COMP_TDSHP0:
| ^~~~~~~~~~~~~~~
| MDP_COMP_TYPE_HDR
In file included from drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.c:9:
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:28:35: error: invalid use of undefined type 'struct mmsys_cmdq_cmd'
28 | cmdq_pkt_clear_event((cmd)->pkt, (cmd)->event[(evt)])
| ^~
drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.c:153:33: note: in expansion of macro 'MM_REG_CLEAR'
153 | MM_REG_CLEAR(cmd, TDSHP0_SOF);
| ^~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:28:47: error: invalid use of undefined type 'struct mmsys_cmdq_cmd'
28 | cmdq_pkt_clear_event((cmd)->pkt, (cmd)->event[(evt)])
| ^~
drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.c:153:33: note: in expansion of macro 'MM_REG_CLEAR'
153 | MM_REG_CLEAR(cmd, TDSHP0_SOF);
| ^~~~~~~~~~~~
vim +123 drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h
100
101 struct mdp_comp {
102 struct mdp_dev *mdp_dev;
103 void __iomem *regs;
104 phys_addr_t reg_base;
105 u8 subsys_id;
106 struct clk *clks[6];
107 struct device *comp_dev;
108 enum mdp_comp_type type;
> 109 enum mtk_mdp_comp_id id;
110 u32 alias_id;
111 const struct mdp_comp_ops *ops;
112 };
113
114 struct mdp_comp_ctx {
115 struct mdp_comp *comp;
116 const struct img_compparam *param;
117 const struct img_input *input;
118 const struct img_output *outputs[IMG_MAX_HW_OUTPUTS];
119 };
120
121 struct mdp_comp_ops {
122 s64 (*get_comp_flag)(const struct mdp_comp_ctx *ctx);
> 123 int (*init_comp)(struct mdp_comp_ctx *ctx, struct mmsys_cmdq_cmd *cmd);
124 int (*config_frame)(struct mdp_comp_ctx *ctx, struct mmsys_cmdq_cmd *cmd,
125 const struct v4l2_rect *compose);
126 int (*config_subfrm)(struct mdp_comp_ctx *ctx,
127 struct mmsys_cmdq_cmd *cmd, u32 index);
128 int (*wait_comp_event)(struct mdp_comp_ctx *ctx,
129 struct mmsys_cmdq_cmd *cmd);
130 int (*advance_subfrm)(struct mdp_comp_ctx *ctx,
131 struct mmsys_cmdq_cmd *cmd, u32 index);
132 int (*post_process)(struct mdp_comp_ctx *ctx, struct mmsys_cmdq_cmd *cmd);
133 };
134
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org
^ permalink raw reply
* AW: [Extern] Re: Problem loading eBPF program on Kernel 4.18 (best with CO:RE): -EINVAL
From: Buchberger, Dennis @ 2022-01-05 18:20 UTC (permalink / raw)
To: Greg KH; +Cc: bpf@vger.kernel.org
In-Reply-To: <YdV2NgMG/EWwJVQn@kroah.com>
>> Hello :)
>>
>> I am currently having a problem and hope you can help me: My goal is to develop a BPF-program (see below) on a development machine and then deploy it to another machine to run it there using BPF CO:RE.
>> But the program does not load; bpf_object__load returns -EINVAL.
>>
>> Development machine:
>> - Ubuntu 20.04 LTS
>> - Linux 5.4.0-90-generic x86_64
>> - Kernel compiled with CONFIG_DEBUG_INFO_BTF=y, so BTF is available under /sys/kernel/btf/vmlinux
>> - clang version: 10.0.0-4ubuntu1
>> - llc version: 10.0.0
>>
>> Target machine:
>> - Ubuntu 18.10
>> - Linux 4.18.0-25-generic x86_64
>
> 4.18 is very old and obsolete and insecure and only supported by the
> vendor you are paying support from. Please upgrade to a more modern
> kernel (4.18 was released way back in 2018), if you wish to get help
> from the kernel community.
>
> Actually, the vendor you are paying for support to stay at this old
> kernel version should be able to provide help to you, why not ask them?
>
> thanks,
>
> greg k-h
Ubuntu 18.04 LTS is still out there and did not reach its end of maintenance; 18.10 is even a bit newer. So yes, it is not up to date, but I would not consider it very old or obsolete.
Actually, I am a student and not paying any vendor I could ask.
BPF CO:RE stands for Compile Once, Run >Everywhere<, so I do wonder why it does not work - it should, no matter wether it is kernel 4.18 or another one, should't it?.
I just get started to eBPF programming and find it difficult to get documentation and examples on how to do it in a not-deprecated way without using bcc, bpftrace or skeletons.
It is quite a simple program, why does it fail getting loaded on 4.18 but not on 5.4?:
SEC("kprobe/")
int trace_func_entry(struct pt_regs *ctx) {
u64 pid_tgid = bpf_get_current_pid_tgid();
u32 pid = pid_tgid;
int arg1;
int arg2;
arg1 = BPF_CORE_READ(ctx, di);
arg2 = PT_REGS_PARM2_CORE(ctx);
__u32 key = 0;
struct stack_trace_t* data;
data = bpf_map_lookup_elem(&stackdata_map, &key);
if (!data)
return 0;
size_t max_len = MAX_STACK_RAWTP * sizeof(__u64);
data->user_stack_size = bpf_get_stack(ctx, data->user_stack, max_len, BPF_F_USER_STACK);
return 0;
}
Thanks for any help
Dennis
^ permalink raw reply
* Re: Questions to create custom distro for TI am335x
From: Jon Mason @ 2022-01-05 18:20 UTC (permalink / raw)
To: Jagade, Nachiket
Cc: Denys Dmytriyenko, meta-arm@lists.yoctoproject.org,
Sridhara Murthy, Vinay, Ankam, Ravindra
In-Reply-To: <BN7PR07MB4644CB07307C600A12570158854A9@BN7PR07MB4644.namprd07.prod.outlook.com>
On Tue, Jan 04, 2022 at 05:35:18AM +0000, Jagade, Nachiket wrote:
> Hello Denys,
>
> Happy new year.
> We are working on TI am335x sitara based platform. You had replied to questions of my colleague long ago.
> We have created custom distro which is a mix of arago and poky. Reason is that when we last checked, arago distro did not had latest version of applications. And when I say application, I refer to open source packages such as python, apparmor etc.
> Also some layers were not available in arago and we had to resolve many dependencies while compiling.
>
> Now we want to make a distro with latest versions of all required packages. So shall we go with 3.4 Honister or with latest dunfell release 3.1.13 ? Our main aim is to have latest versions of packages with less number of vulnerability count. What will you suggest to achieve this?
This is not a Arm specific question. So, your questions are better
asked on openembedded-core@lists.openembedded.org or
yocto@lists.yoctoproject.org (or meta-arago@arago-project.org).
That being said, dunfell is the Yocto Project LTS and there is a
dunfell branch in meta-arago. So, there should be less pain in using
that for your hybrid approach.
Thanks,
Jon
>
>
> Thanks and regards,
> Nachiket
>
>
> -----Original Message-----
> From: Denys Dmytriyenko <denis@denix.org>
> Sent: Wednesday, February 24, 2021 1:35 AM
> To: Ankam, Ravindra <Ravindra.Ankam@Honeywell.com>
> Cc: meta-arm@lists.yoctoproject.org
> Subject: [External] Re: [meta-arm] Error while building the custom image
>
> Hi,
>
> You seem to have a very strange combination of layers and mix of branches!
>
> For example, is this a Poky distro or Arago? Why do you include meta-poky if DISTRO = "arago"?
> Why do you have some layers on "gatesgarth" and some on unstable "master"?
> And finally, Arago distro currently does not fully support master or gatesgarth with the external Arm toolchain, only dunfell.
>
> --
> Denys
>
>
> On Tue, Feb 23, 2021 at 02:47:48PM +0000, Ankam, Ravindra via lists.yoctoproject.org wrote:
> > Hi,
> > Please attached the error logs.
> > Can you please help how to address this issue?
> >
> > Thanks and regards,
> > Ravi
>
>
> > poky/build$ MACHINE=am335x-evm bitbake custom-base-image Loading
> > cache: 100%
> > |####################################################################################################################################| Time: 0:00:00 Loaded 4805 entries from dependency cache.
> > WARNING: No recipes in default available for:
> > /home/airport/ravi/yocto_gatesgarth/poky/meta-arago/meta-arago-distro/recipes-browser/chromium/chromium-ozone-wayland_%.bbappend
> >
> > /home/airport/ravi/yocto_gatesgarth/poky/meta-arago/meta-arago-distro/
> > recipes-graphics/wayland/weston_8.0.0.bbappend
> >
> > /home/airport/ravi/yocto_gatesgarth/poky/meta-arago/meta-arago-distro/
> > recipes-support/opencv/opencv_3.1.bbappend
> > NOTE: Resolving any missing task queue dependencies
> >
> > Build Configuration:
> > BB_VERSION = "1.48.0"
> > BUILD_SYS = "x86_64-linux"
> > NATIVELSBSTRING = "ubuntu-16.04"
> > TARGET_SYS = "arm-linux-gnueabi"
> > MACHINE = "am335x-evm"
> > DISTRO = "arago"
> > DISTRO_VERSION = "2020.09"
> > TUNE_FEATURES = "arm armv7a vfp thumb neon callconvention-hard"
> > TARGET_FPU = "hard"
> > meta
> > meta-poky
> > meta-yocto-bsp
> > meta-custom = "my-yocto-3.2.1:943ef2fad8428f002850e3655a3312e13d0dcb2c"
> > meta-arm
> > meta-arm-toolchain = "gatesgarth:7185d29de9f54d2cb5b2da35b0c3f1e5f381db2c"
> > meta-clang = "master:16f757de2d90594476d2c8feefd3a850c3c24931"
> > meta-ti = "master:fb4726a88cbb5a6311bdb3095b81d314e344a322"
> > meta-arago-distro
> > meta-arago-extras = "master:f90d1bed7e775ac59bf1fcd95e95e9109d0953db"
> > meta-qt5 = "master:23f7a1c8eabaf1beb80cc6214954c0e1751c4cbd"
> > meta-virtualization = "master-next:3389eb0f128b1ef1d1aaf518afdf298a88f89619"
> > meta-networking
> > meta-python
> > meta-perl
> > meta-oe
> > meta-gnome
> > meta-multimedia
> > meta-filesystems = "gatesgarth:cef93b7b00e620d90a610112ee574fa60b691cf8"
> > meta-tpm
> > meta-security
> > meta-security-compliance = "master:16ee7308c9fd48d69b02c5519d2e5edddc560658"
> > meta-selinux = "gatesgarth:36db146d56535318d343dc9138358885356f2172"
> > meta-linaro
> > meta-optee = "master:11091b487e1ad4c6a4adfac34d958a3d9d9ccd17"
> >
> > Initialising tasks: 100%
> > |#####################################################################
> > ##########################################################| Time:
> > 0:00:02 Sstate summary: Wanted 1003 Found 0 Missed 1003 Current 22 (0%
> > match, 2% complete)
> > NOTE: Executing Tasks
> > ERROR: external-arm-toolchain-2019.12-r0 do_install: '_sre.SRE_Match'
> > object is not subscriptable
> > ERROR: Logfile of failure stored in:
> > /home/airport/ravi/yocto_gatesgarth/poky/build/tmp-external-arm-glibc/
> > work/armv7at2hf-neon-linux-gnueabi/external-arm-toolchain/2019.12-r0/t
> > emp/log.do_install.22351
> > Log data follows:
> > | DEBUG: Executing python function extend_recipe_sysroot
> > | NOTE: Direct dependencies are
> > | ['virtual:native:/home/airport/ravi/yocto_gatesgarth/poky/meta/recip
> > | es-devtools/patch/patch_2.7.6.bb:do_populate_sysroot',
> > | 'virtual:native:/home/airport/ravi/yocto_gatesgarth/poky/meta/recipe
> > | s-devtools/rsync/rsync_3.2.3.bb:do_populate_sysroot',
> > | 'virtual:native:/home/airport/ravi/yocto_gatesgarth/poky/meta/recipe
> > | s-extended/xz/xz_5.2.5.bb:do_populate_sysroot',
> > | 'virtual:native:/home/airport/ravi/yocto_gatesgarth/poky/meta/recipe
> > | s-devtools/bison/bison_3.7.2.bb:do_populate_sysroot',
> > | 'virtual:native:/home/airport/ravi/yocto_gatesgarth/poky/meta/recipe
> > | s-devtools/pkgconfig/pkgconfig_git.bb:do_populate_sysroot',
> > | '/home/airport/ravi/yocto_gatesgarth/poky/meta/recipes-devtools/quil
> > | t/quilt-native_0.66.bb:do_populate_sysroot',
> > | 'virtual:native:/home/airport/ravi/yocto_gatesgarth/poky/meta/recipe
> > | s-devtools/pseudo/pseudo_git.bb:do_populate_sysroot']
> > | NOTE: Installed into sysroot: []
> > | NOTE: Skipping as already exists in sysroot: ['patch-native',
> > | 'rsync-native', 'xz-native', 'bison-native', 'pkgconfig-native',
> > | 'quilt-native', 'pseudo-native', 'texinfo-dummy-native',
> > | 'libtool-native', 'gnu-config-native', 'gettext-minimal-native',
> > | 'automake-native', 'flex-native', 'autoconf-native', 'attr-native',
> > | 'acl-native', 'popt-native', 'm4-native']
> > | DEBUG: Python function extend_recipe_sysroot finished
> > | DEBUG: Executing shell function do_install
> > | /home/airport/ravi/yocto_gatesgarth/poky/build/tmp-external-arm-glib
> > | c/work/armv7at2hf-neon-linux-gnueabi/external-arm-toolchain/2019.12-
> > | r0/image/lib/libanl.so.1 is a symlink of
> > | /home/airport/ravi/yocto_gatesgarth/poky/build/tmp-external-arm-glib
> > | c/work/armv7at2hf-neon-linux-gnueabi/external-arm-toolchain/2019.12-
> > | r0/image/lib/libanl-2.30.so, keep it
> > | /home/airport/ravi/yocto_gatesgarth/poky/build/tmp-external-arm-glib
> > | c/work/armv7at2hf-neon-linux-gnueabi/external-arm-toolchain/2019.12-
> > | r0/image/lib/libBrokenLocale.so.1 is a symlink of
> > | /home/airport/ravi/yocto_gatesgarth/poky/build/tmp-external-arm-glib
> > | c/work/armv7at2hf-neon-linux-gnueabi/external-arm-toolchain/2019.12-
> > | r0/image/lib/libBrokenLocale-2.30.so, keep it
> > | /home/airport/ravi/yocto_gatesgarth/poky/build/tmp-external-arm-glib
> > | c/work/armv7at2hf-neon-linux-gnueabi/external-arm-toolchain/2019.12-
> > | r0/image/lib/libc.so.6 is a symlink of
> > | /home/airport/ravi/yocto_gatesgarth/poky/build/tmp-external-arm-glib
> > | c/work/armv7at2hf-neon-linux-gnueabi/external-arm-toolchain/2019.12-
> > | r0/image/lib/libc-2.30.so, keep it
> > | /home/airport/ravi/yocto_gatesgarth/poky/build/tmp-external-arm-glib
> > | c/work/armv7at2hf-neon-linux-gnueabi/external-arm-toolchain/2019.12-
> > | r0/image/lib/libcrypt.so.1 is a symlink of
> > | /home/airport/ravi/yocto_gatesgarth/poky/build/tmp-external-arm-glib
> > | c/work/armv7at2hf-neon-linux-gnueabi/external-arm-toolchain/2019.12-
> > | r0/image/lib/libcrypt-2.30.so, keep it
> > | /home/airport/ravi/yocto_gatesgarth/poky/build/tmp-external-arm-glib
> > | c/work/armv7at2hf-neon-linux-gnueabi/external-arm-toolchain/2019.12-
> > | r0/image/lib/libdl.so.2 is a symlink of
> > | /home/airport/ravi/yocto_gatesgarth/poky/build/tmp-external-arm-glib
> > | c/work/armv7at2hf-neon-linux-gnueabi/external-arm-toolchain/2019.12-
> > | r0/image/lib/libdl-2.30.so, keep it
> > | /home/airport/ravi/yocto_gatesgarth/poky/build/tmp-external-arm-glib
> > | c/work/armv7at2hf-neon-linux-gnueabi/external-arm-toolchain/2019.12-
> > | r0/image/lib/libm.so.6 is a symlink of
> > | /home/airport/ravi/yocto_gatesgarth/poky/build/tmp-external-arm-glib
> > | c/work/armv7at2hf-neon-linux-gnueabi/external-arm-toolchain/2019.12-
> > | r0/image/lib/libm-2.30.so, keep it
> > | /home/airport/ravi/yocto_gatesgarth/poky/build/tmp-external-arm-glib
> > | c/work/armv7at2hf-neon-linux-gnueabi/external-arm-toolchain/2019.12-
> > | r0/image/lib/libnsl.so.1 is a symlink of
> > | /home/airport/ravi/yocto_gatesgarth/poky/build/tmp-external-arm-glib
> > | c/work/armv7at2hf-neon-linux-gnueabi/external-arm-toolchain/2019.12-
> > | r0/image/lib/libnsl-2.30.so, keep it
> > | /home/airport/ravi/yocto_gatesgarth/poky/build/tmp-external-arm-glib
> > | c/work/armv7at2hf-neon-linux-gnueabi/external-arm-toolchain/2019.12-
> > | r0/image/lib/libnss_compat.so.2 is a symlink of
> > | /home/airport/ravi/yocto_gatesgarth/poky/build/tmp-external-arm-glib
> > | c/work/armv7at2hf-neon-linux-gnueabi/external-arm-toolchain/2019.12-
> > | r0/image/lib/libnss_compat-2.30.so, keep it
> > | /home/airport/ravi/yocto_gatesgarth/poky/build/tmp-external-arm-glib
> > | c/work/armv7at2hf-neon-linux-gnueabi/external-arm-toolchain/2019.12-
> > | r0/image/lib/libnss_db.so.2 is a symlink of
> > | /home/airport/ravi/yocto_gatesgarth/poky/build/tmp-external-arm-glib
> > | c/work/armv7at2hf-neon-linux-gnueabi/external-arm-toolchain/2019.12-
> > | r0/image/lib/libnss_db-2.30.so, keep it
> > | /home/airport/ravi/yocto_gatesgarth/poky/build/tmp-external-arm-glib
> > | c/work/armv7at2hf-neon-linux-gnueabi/external-arm-toolchain/2019.12-
> > | r0/image/lib/libnss_dns.so.2 is a symlink of
> > | /home/airport/ravi/yocto_gatesgarth/poky/build/tmp-external-arm-glib
> > | c/work/armv7at2hf-neon-linux-gnueabi/external-arm-toolchain/2019.12-
> > | r0/image/lib/libnss_dns-2.30.so, keep it
> > | /home/airport/ravi/yocto_gatesgarth/poky/build/tmp-external-arm-glib
> > | c/work/armv7at2hf-neon-linux-gnueabi/external-arm-toolchain/2019.12-
> > | r0/image/lib/libnss_files.so.2 is a symlink of
> > | /home/airport/ravi/yocto_gatesgarth/poky/build/tmp-external-arm-glib
> > | c/work/armv7at2hf-neon-linux-gnueabi/external-arm-toolchain/2019.12-
> > | r0/image/lib/libnss_files-2.30.so, keep it
> > | /home/airport/ravi/yocto_gatesgarth/poky/build/tmp-external-arm-glib
> > | c/work/armv7at2hf-neon-linux-gnueabi/external-arm-toolchain/2019.12-
> > | r0/image/lib/libnss_hesiod.so.2 is a symlink of
> > | /home/airport/ravi/yocto_gatesgarth/poky/build/tmp-external-arm-glib
> > | c/work/armv7at2hf-neon-linux-gnueabi/external-arm-toolchain/2019.12-
> > | r0/image/lib/libnss_hesiod-2.30.so, keep it
> > | /home/airport/ravi/yocto_gatesgarth/poky/build/tmp-external-arm-glib
> > | c/work/armv7at2hf-neon-linux-gnueabi/external-arm-toolchain/2019.12-
> > | r0/image/lib/libpthread.so.0 is a symlink of
> > | /home/airport/ravi/yocto_gatesgarth/poky/build/tmp-external-arm-glib
> > | c/work/armv7at2hf-neon-linux-gnueabi/external-arm-toolchain/2019.12-
> > | r0/image/lib/libpthread-2.30.so, keep it
> > | /home/airport/ravi/yocto_gatesgarth/poky/build/tmp-external-arm-glib
> > | c/work/armv7at2hf-neon-linux-gnueabi/external-arm-toolchain/2019.12-
> > | r0/image/lib/libresolv.so.2 is a symlink of
> > | /home/airport/ravi/yocto_gatesgarth/poky/build/tmp-external-arm-glib
> > | c/work/armv7at2hf-neon-linux-gnueabi/external-arm-toolchain/2019.12-
> > | r0/image/lib/libresolv-2.30.so, keep it
> > | /home/airport/ravi/yocto_gatesgarth/poky/build/tmp-external-arm-glib
> > | c/work/armv7at2hf-neon-linux-gnueabi/external-arm-toolchain/2019.12-
> > | r0/image/lib/librt.so.1 is a symlink of
> > | /home/airport/ravi/yocto_gatesgarth/poky/build/tmp-external-arm-glib
> > | c/work/armv7at2hf-neon-linux-gnueabi/external-arm-toolchain/2019.12-
> > | r0/image/lib/librt-2.30.so, keep it
> > | /home/airport/ravi/yocto_gatesgarth/poky/build/tmp-external-arm-glib
> > | c/work/armv7at2hf-neon-linux-gnueabi/external-arm-toolchain/2019.12-
> > | r0/image/lib/libutil.so.1 is a symlink of
> > | /home/airport/ravi/yocto_gatesgarth/poky/build/tmp-external-arm-glib
> > | c/work/armv7at2hf-neon-linux-gnueabi/external-arm-toolchain/2019.12-
> > | r0/image/lib/libutil-2.30.so, keep it
> > | rmdir: failed to remove
> > | '/home/airport/ravi/yocto_gatesgarth/poky/build/tmp-external-arm-gli
> > | bc/work/armv7at2hf-neon-linux-gnueabi/external-arm-toolchain/2019.12
> > | -r0/image/usr/bin': Directory not empty
> > | rmdir: failed to remove
> > | '/home/airport/ravi/yocto_gatesgarth/poky/build/tmp-external-arm-gli
> > | bc/work/armv7at2hf-neon-linux-gnueabi/external-arm-toolchain/2019.12
> > | -r0/image/usr/sbin': Directory not empty
> > | rmdir: failed to remove
> > | '/home/airport/ravi/yocto_gatesgarth/poky/build/tmp-external-arm-gli
> > | bc/work/armv7at2hf-neon-linux-gnueabi/external-arm-toolchain/2019.12
> > | -r0/image/sbin': Directory not empty
> > | NOTE: make -j 3 HOSTCC=gcc HOSTCPP=gcc -E headers_install INSTALL_HDR_PATH=/home/airport/ravi/yocto_gatesgarth/poky/build/tmp-external-arm-glibc/work/armv7at2hf-neon-linux-gnueabi/external-arm-toolchain/2019.12-r0/external-arm-toolchain-2019.12/usr
> > | INSTALL
> > | /home/airport/ravi/yocto_gatesgarth/poky/build/tmp-external-arm-glib
> > | c/work/armv7at2hf-neon-linux-gnueabi/external-arm-toolchain/2019.12-
> > | r0/external-arm-toolchain-2019.12/usr/include
> > | mv: cannot stat
> > | '/home/airport/ravi/yocto_gatesgarth/poky/build/tmp-external-arm-gli
> > | bc/work/armv7at2hf-neon-linux-gnueabi/external-arm-toolchain/2019.12
> > | -r0/image/usr/lib/gcc/arm-none-linux-gnueabihf': No such file or
> > | directory
> > | WARNING: /home/airport/ravi/yocto_gatesgarth/poky/build/tmp-external-arm-glibc/work/armv7at2hf-neon-linux-gnueabi/external-arm-toolchain/2019.12-r0/temp/run.do_install.22351:415 exit 1 from 'mv /home/airport/ravi/yocto_gatesgarth/poky/build/tmp-external-arm-glibc/work/armv7at2hf-neon-linux-gnueabi/external-arm-toolchain/2019.12-r0/image/usr/lib/gcc/arm-none-linux-gnueabihf /home/airport/ravi/yocto_gatesgarth/poky/build/tmp-external-arm-glibc/work/armv7at2hf-neon-linux-gnueabi/external-arm-toolchain/2019.12-r0/image/usr/lib/gcc/arm-linux-gnueabi'
> > | WARNING: Backtrace (BB generated script):
> > | #1: do_install, /home/airport/ravi/yocto_gatesgarth/poky/build/tmp-external-arm-glibc/work/armv7at2hf-neon-linux-gnueabi/external-arm-toolchain/2019.12-r0/temp/run.do_install.22351, line 415
> > | #2: main,
> > | /home/airport/ravi/yocto_gatesgarth/poky/build/tmp-external-arm-glib
> > | c/work/armv7at2hf-neon-linux-gnueabi/external-arm-toolchain/2019.12-
> > | r0/temp/run.do_install.22351, line 415
> > | ERROR: '_sre.SRE_Match' object is not subscriptable
> > ERROR: Task (/home/airport/ravi/yocto_gatesgarth/poky/meta-arm/meta-arm-toolchain/recipes-devtools/external-arm-toolchain/external-arm-toolchain.bb:do_install) failed with exit code '1'
> > NOTE: Tasks Summary: Attempted 242 tasks of which 239 didn't need to be rerun and 1 failed.
> >
> > Summary: 1 task failed:
> >
> > /home/airport/ravi/yocto_gatesgarth/poky/meta-arm/meta-arm-toolchain/r
> > ecipes-devtools/external-arm-toolchain/external-arm-toolchain.bb:do_in
> > stall
> > Summary: There was 1 WARNING message shown.
> > Summary: There was 1 ERROR message shown, returning a non-zero exit code.
>
> >
> > -=-=-=-=-=-=-=-=-=-=-=-
> > Links: You receive all messages sent to this group.
> > View/Reply Online (#1713):
> > https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist
> > s.yoctoproject.org%2Fg%2Fmeta-arm%2Fmessage%2F1713&data=04%7C01%7C
> > Vinay.SridharaMurthy%40Honeywell.com%7Cbb8e0988781b4c3e846408d9ce83da3
> > c%7C96ece5269c7d48b08daf8b93c90a5d18%7C0%7C0%7C637767887969200715%7CUn
> > known%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haW
> > wiLCJXVCI6Mn0%3D%7C3000&sdata=HwaRFNz2%2Fo8OtD83YcwUngCFc17wzpX7Zk
> > P%2BFCkAgA4%3D&reserved=0 Mute This Topic:
> > https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist
> > s.yoctoproject.org%2Fmt%2F80852192%2F3617104&data=04%7C01%7CVinay.
> > SridharaMurthy%40Honeywell.com%7Cbb8e0988781b4c3e846408d9ce83da3c%7C96
> > ece5269c7d48b08daf8b93c90a5d18%7C0%7C0%7C637767887969200715%7CUnknown%
> > 7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJX
> > VCI6Mn0%3D%7C3000&sdata=dITdALtS0RmCy4uvIPjZB6yGDMIC6NOtUq9wkrhjVH
> > E%3D&reserved=0 Group Owner: meta-arm+owner@lists.yoctoproject.org
> > Unsubscribe:
> > https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist
> > s.yoctoproject.org%2Fg%2Fmeta-arm%2Funsub&data=04%7C01%7CVinay.Sri
> > dharaMurthy%40Honeywell.com%7Cbb8e0988781b4c3e846408d9ce83da3c%7C96ece
> > 5269c7d48b08daf8b93c90a5d18%7C0%7C0%7C637767887969200715%7CUnknown%7CT
> > WFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI
> > 6Mn0%3D%7C3000&sdata=oVafEDlK82x6PFJz3kukwvuXECl5JW%2BD0GMwAkKDIZs
> > %3D&reserved=0 [denis@denix.org]
> > -=-=-=-=-=-=-=-=-=-=-=-
> >
>
>
> --
> Regards,
> Denys Dmytriyenko <denis@denix.org>
> PGP: 0x420902729A92C964 - https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdenix.org%2F0x420902729A92C964&data=04%7C01%7CNachiketRahul.Jagade%40Honeywell.com%7Ce49425450ea14bd225ea08d9ce889c5b%7C96ece5269c7d48b08daf8b93c90a5d18%7C0%7C0%7C637767908394296478%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=xDfgVNwA0j8WFflU4TNhfyV5UQ80zobXOQcsVeYjHTI%3D&reserved=0
> Fingerprint: 25FC E4A5 8A72 2F69 1186 6D76 4209 0272 9A92 C964
>
^ permalink raw reply
* Re: [PATCH] Revert "net: usb: r8152: Add MAC passthrough support for more Lenovo Docks"
From: patchwork-bot+netdevbpf @ 2022-01-05 18:20 UTC (permalink / raw)
To: Aaron Ma
Cc: kuba, henning.schild, linux-usb, netdev, linux-kernel, davem,
hayeswang, tiwai
In-Reply-To: <20220105155102.8557-1-aaron.ma@canonical.com>
Hello:
This patch was applied to netdev/net.git (master)
by Jakub Kicinski <kuba@kernel.org>:
On Wed, 5 Jan 2022 23:51:02 +0800 you wrote:
> This reverts commit f77b83b5bbab53d2be339184838b19ed2c62c0a5.
>
> This change breaks multiple usb to ethernet dongles attached on Lenovo
> USB hub.
>
> Signed-off-by: Aaron Ma <aaron.ma@canonical.com>
>
> [...]
Here is the summary with links:
- Revert "net: usb: r8152: Add MAC passthrough support for more Lenovo Docks"
https://git.kernel.org/netdev/net/c/00fcf8c7dd56
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCHv3 4/4] nvme-pci: fix queue_rqs list splitting
From: Christoph Hellwig @ 2022-01-05 18:18 UTC (permalink / raw)
To: Keith Busch; +Cc: linux-nvme, linux-block, axboe, hch, sagi, mgurtovoy
In-Reply-To: <20220105170518.3181469-5-kbusch@kernel.org>
On Wed, Jan 05, 2022 at 09:05:18AM -0800, Keith Busch wrote:
> If command prep fails, current handling will orphan subsequent requests
> in the list. Consider a simple example:
>
> rqlist = [ 1 -> 2 ]
>
> When prep for request '1' fails, it will be appended to the
> 'requeue_list', leaving request '2' disconnected from the original
> rqlist and no longer tracked. Meanwhile, rqlist is still pointing to the
> failed request '1' and will attempt to submit the unprepped command.
>
> Fix this by updating the rqlist accordingly using the request list
> helper functions.
>
> Fixes: d62cbcf62f2f ("nvme: add support for mq_ops->queue_rqs()")
> Signed-off-by: Keith Busch <kbusch@kernel.org>
Looks good,
Reviewed-by: Christoph Hellwig <hch@lst.de>
^ permalink raw reply
* Re: [PATCHv3 3/4] block: introduce rq_list_move
From: Christoph Hellwig @ 2022-01-05 18:18 UTC (permalink / raw)
To: Keith Busch; +Cc: linux-nvme, linux-block, axboe, hch, sagi, mgurtovoy
In-Reply-To: <20220105170518.3181469-4-kbusch@kernel.org>
On Wed, Jan 05, 2022 at 09:05:17AM -0800, Keith Busch wrote:
> When iterating a list, a particular request may need to be moved for
> special handling. Provide a helper function to achieve that so drivers
> don't need to reimplement rqlist manipulation.
>
> Signed-off-by: Keith Busch <kbusch@kernel.org>
Looks good,
Reviewed-by: Christoph Hellwig <hch@lst.de>
^ permalink raw reply
* Re: [PATCHv3 1/4] block: move rq_list macros to blk-mq.h
From: Christoph Hellwig @ 2022-01-05 18:17 UTC (permalink / raw)
To: Keith Busch; +Cc: linux-nvme, linux-block, axboe, hch, sagi, mgurtovoy
In-Reply-To: <20220105170518.3181469-2-kbusch@kernel.org>
On Wed, Jan 05, 2022 at 09:05:15AM -0800, Keith Busch wrote:
> Move the request list macros to the header file that defines that struct
> they operate on.
>
> Signed-off-by: Keith Busch <kbusch@kernel.org>
Looks good,
Reviewed-by: Christoph Hellwig <hch@lst.de>
^ permalink raw reply
* [PATCH v5] ata: pata_of_platform: Use platform_get_irq_optional() to get the interrupt
From: Lad Prabhakar @ 2022-01-05 18:17 UTC (permalink / raw)
To: Damien Le Moal
Cc: Rob Herring, Andy Shevchenko, Prabhakar, Lad Prabhakar, linux-ide,
linux-kernel
platform_get_resource(pdev, IORESOURCE_IRQ, ..) relies on static
allocation of IRQ resources in DT core code, this causes an issue
when using hierarchical interrupt domains using "interrupts" property
in the node as this bypasses the hierarchical setup and messes up the
irq chaining.
In preparation for removal of static setup of IRQ resource from DT core
code use platform_get_irq_optional().
Note the code does not set the IRQ flags as this is handled automatically
for DT.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
---
Hi All,
This patch is part of series [1]. I'll re-visit merging of pata_of_platform
into pata_platform at later point. As my primary focus is removal of static
setup of IRQ resource from DT core code.
[1] https://patchwork.ozlabs.org/project/linux-ide/list/?series=278349
v4->v5
* Set end member of IRQ resource
* Clear irq_res un-conditionally.
Cheers,
Prabhakar
---
drivers/ata/pata_of_platform.c | 15 ++++++++++++---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/ata/pata_of_platform.c b/drivers/ata/pata_of_platform.c
index 35aa158fc976..c3a40b717dcd 100644
--- a/drivers/ata/pata_of_platform.c
+++ b/drivers/ata/pata_of_platform.c
@@ -25,11 +25,12 @@ static int pata_of_platform_probe(struct platform_device *ofdev)
struct device_node *dn = ofdev->dev.of_node;
struct resource io_res;
struct resource ctl_res;
- struct resource *irq_res;
+ struct resource irq_res;
unsigned int reg_shift = 0;
int pio_mode = 0;
int pio_mask;
bool use16bit;
+ int irq;
ret = of_address_to_resource(dn, 0, &io_res);
if (ret) {
@@ -45,7 +46,15 @@ static int pata_of_platform_probe(struct platform_device *ofdev)
return -EINVAL;
}
- irq_res = platform_get_resource(ofdev, IORESOURCE_IRQ, 0);
+ memset(&irq_res, 0, sizeof(irq_res));
+
+ irq = platform_get_irq_optional(ofdev, 0);
+ if (irq < 0 && irq != -ENXIO)
+ return irq;
+ if (irq > 0) {
+ irq_res.start = irq;
+ irq_res.end = irq;
+ }
of_property_read_u32(dn, "reg-shift", ®_shift);
@@ -63,7 +72,7 @@ static int pata_of_platform_probe(struct platform_device *ofdev)
pio_mask = 1 << pio_mode;
pio_mask |= (1 << pio_mode) - 1;
- return __pata_platform_probe(&ofdev->dev, &io_res, &ctl_res, irq_res,
+ return __pata_platform_probe(&ofdev->dev, &io_res, &ctl_res, irq > 0 ? &irq_res : NULL,
reg_shift, pio_mask, &pata_platform_sht,
use16bit);
}
--
2.17.1
^ permalink raw reply related
* [PATCH] firmware: dmi-sysfs: use default_groups in kobj_type
From: Greg Kroah-Hartman @ 2022-01-05 18:17 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman
There are currently 2 ways to create a set of sysfs files for a
kobj_type, through the default_attrs field, and the default_groups
field. Move the firmware dmi-sysfs sysfs code to use default_groups
field which has been the preferred way since aa30f47cf666 ("kobject: Add
support for default attribute groups to kobj_type") so that we can soon
get rid of the obsolete default_attrs field.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/firmware/dmi-sysfs.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/firmware/dmi-sysfs.c b/drivers/firmware/dmi-sysfs.c
index 8b8127fa8955..3a353776bd34 100644
--- a/drivers/firmware/dmi-sysfs.c
+++ b/drivers/firmware/dmi-sysfs.c
@@ -302,12 +302,12 @@ static struct attribute *dmi_sysfs_sel_attrs[] = {
&dmi_sysfs_attr_sel_per_log_type_descriptor_length.attr,
NULL,
};
-
+ATTRIBUTE_GROUPS(dmi_sysfs_sel);
static struct kobj_type dmi_system_event_log_ktype = {
.release = dmi_entry_free,
.sysfs_ops = &dmi_sysfs_specialize_attr_ops,
- .default_attrs = dmi_sysfs_sel_attrs,
+ .default_groups = dmi_sysfs_sel_groups,
};
typedef u8 (*sel_io_reader)(const struct dmi_system_event_log *sel,
@@ -518,6 +518,7 @@ static struct attribute *dmi_sysfs_entry_attrs[] = {
&dmi_sysfs_attr_entry_position.attr,
NULL,
};
+ATTRIBUTE_GROUPS(dmi_sysfs_entry);
static ssize_t dmi_entry_raw_read_helper(struct dmi_sysfs_entry *entry,
const struct dmi_header *dh,
@@ -565,7 +566,7 @@ static void dmi_sysfs_entry_release(struct kobject *kobj)
static struct kobj_type dmi_sysfs_entry_ktype = {
.release = dmi_sysfs_entry_release,
.sysfs_ops = &dmi_sysfs_attr_ops,
- .default_attrs = dmi_sysfs_entry_attrs,
+ .default_groups = dmi_sysfs_entry_groups,
};
static struct kset *dmi_kset;
--
2.34.1
^ permalink raw reply related
* [Weekly meetings] MoM - 5th of January 2021
From: Matthieu Baerts @ 2022-01-05 18:17 UTC (permalink / raw)
To: MPTCP Upstream
Hello everyone,
Last Thursday, we just had our 178th meeting with Mat, Ossama, Kishen
(Intel) and myself (Tessares).
Thanks again for this new good meeting!
Here are the minutes of the meeting:
Accepted patches:
- The list of accepted patches can be seen on PatchWork:
https://patchwork.kernel.org/project/mptcp/list/?state=3
netdev (if mptcp ML is in cc) (by: Davide Caratti, Mat Martineau, Ma
Xinjian):
12698997 selftests: mptcp: Remove the deprecated config NFT_COUNTER
12685803 [net-next,3/3] mptcp: clean up harmless false expressions
12685799 [net-next,2/3] selftests: mptcp: try to set mptcp ulp mode in
differe...
12685801 [net-next,1/3] mptcp: enforce HoL-blocking estimation
12655357 [iproute2-next] mptcp: add support for changing the backup flag
our repo (by: Geliang Tang, Paolo Abeni):
12683809 [mptcp-next] Squash to "selftests: mptcp: add tests for
subflow creat...
12683803 [mptcp-next,2/2] mptcp: reuse __mptcp_make_csum in
validate_data_csum
12683801 [mptcp-next,1/2] mptcp: change the parameter of __mptcp_make_csum
12681411 [mptcp-next] Squash-to: "mptcp: cleanup MPJ subflow list handling"
12678143 [v3,mptcp-next] selftests: mptcp: more stable join tests-cases.
Pending patches:
- The list of pending patches can be seen on PatchWork:
https://patchwork.kernel.org/project/mptcp/list/?state=*
netdev (if mptcp ML is in cc) (by: /):
/
our repo (by: Dmytro Shytyi, Geliang Tang, Jiapeng Chong, Kishen
Maloor, Matthieu Baerts, Paolo Abeni):
12282219: RFC: [RESEND,RFC,2/4] tcp: move selected mptcp helpers to
tcp.h/mptcp.h
12282221: RFC: [RESEND,RFC,4/4] tcp: parse tcp options contained in
reset packets:
- WIP
12282223: RFC: [RESEND,RFC,mptpcp-next] mptcp: add ooo prune support:
- WIP
12282225: RFC: [RESEND,1/5] tcp: make two mptcp helpers available to tcp
stack
12282227: RFC: [RESEND,5/5] mptcp: send fastclose if userspace closes
socket with unread data:
- WIP
12321111: Changes Requested: mptcp: Remove redundant assignment to
remaining:
- TODO
12576993: Changes Requested: [net-next,v1] net: mptcp, Fast Open Mechanism:
- WIP
12674087: RFC: [RFC] mptcp: strict local address ID selection:
- From Paolo, reviewed by Mat
- seems to be the right direction to take, big modification in the
selftests but for the best
- changes requested but the approach seems fine
12682877: Changes Requested: [mptcp-next,01/21] mptcp: do not restrict
subflows with non-kernel PMs
12682875: Changes Requested: [mptcp-next,02/21] mptcp: store remote id
from MP_JOIN SYN/ACK in local ctx
12682881: Changes Requested: [mptcp-next,03/21] mptcp: reflect remote
port (not 0) in ANNOUNCED events
12682883: Changes Requested: [mptcp-next,04/21] mptcp: establish
subflows from either end of connection
12682885: Changes Requested: [mptcp-next,05/21] mptcp: netlink: store
per namespace list of refcounted listen socks
12682889: Changes Requested: [mptcp-next,06/21] mptcp: netlink: store
lsk ref in mptcp_pm_addr_entry
12682887: Changes Requested: [mptcp-next,07/21] mptcp: netlink: process
IPv6 addrs in creating listening sockets
12682893: Changes Requested: [mptcp-next,08/21] mptcp: attempt to add
listening sockets for announced addrs
12682891: Changes Requested: [mptcp-next,09/21] mptcp: allow ADD_ADDR
reissuance by userspace PMs
12682895: Changes Requested: [mptcp-next,10/21] mptcp: handle local
addrs announced by userspace PMs
12682897: Changes Requested: [mptcp-next,11/21] mptcp: read attributes
of addr entries managed by userspace PMs
12682905: Changes Requested: [mptcp-next,12/21] mptcp: netlink: split
mptcp_pm_parse_addr into two functions
12682901: Changes Requested: [mptcp-next,13/21] mptcp: netlink: Add
MPTCP_PM_CMD_ANNOUNCE
12682899: Changes Requested: [mptcp-next,14/21] mptcp: selftests:
support MPTCP_PM_CMD_ANNOUNCE
12682907: Changes Requested: [mptcp-next,15/21] mptcp: netlink: Add
MPTCP_PM_CMD_REMOVE
12682903: Changes Requested: [mptcp-next,16/21] mptcp: selftests:
support MPTCP_PM_CMD_REMOVE
12682915: Changes Requested: [mptcp-next,17/21] mptcp: netlink: allow
userspace-driven subflow establishment
12682909: Changes Requested: [mptcp-next,18/21] mptcp: selftests:
support MPTCP_PM_CMD_SUBFLOW_CREATE
12682911: Changes Requested: [mptcp-next,19/21] mptcp: selftests:
support MPTCP_PM_CMD_SUBFLOW_DESTROY
12682913: Changes Requested: [mptcp-next,20/21] mptcp: selftests:
capture netlink events
12682917: Changes Requested: [mptcp-next,21/21] selftests: mptcp:
functional tests for the userspace PM type:
- From Kishen, reviewed by Paolo and Matth
- some discussions needed:
- is it OK to open additional listening sockets?:
- Or has to be explicitly asked by the userspace?
- Or an option for the in-kernel PM?
- Can be on be default?
- → Might help for the end user experience when using apps
creating TCP sockets
- at the end, if there is already a listening socket (e.g.
listening to all interfaces), nothing new is created
- maybe having a parameter in the ADD_ADDR CMD not to create
a listening socket implicitly might be a good compromised?
- opening connections from the server to the client side:
- "advanced" behaviour with "advanced policy" could be
managed by the userspace PM daemon
- maybe having a dedicated NL CMD? There is already an API
for that (not in the PM)
- at the end, listening socket only created if ADD_ADDR are sent
- these cover new UCs but don't break existing ones:
- maybe best to take a step back and check if it is really
an issue
- probably best to discuss about that ↑ again later when Paolo will
be there and email will be re-read.
- some other minor issues can be fixed easily, Kishen will do that
12703314: New: [RESEND,iproute2-next,1/3] mptcp: add id check for
deleting address
12703315: New: [iproute2-next,2/3] mptcp: add the addr flag fullmesh
12703316: New: [iproute2-next,3/3] mptcp: add the backup flag setting:
- Need review
12703319: Changes Requested: [mptcp-next,1/4] selftests: mptcp: use 'ip
mptcp' in mptcp_join.sh
12703320: Changes Requested: [mptcp-next,2/4] selftests: mptcp: use 'ip
mptcp' in mptcp_sockopt.sh
12703321: Changes Requested: [mptcp-next,3/4] selftests: mptcp: use 'ip
mptcp' in pm_netlink.sh
12703322: Changes Requested: [mptcp-next,4/4] selftests: mptcp: use 'ip
mptcp' in simult_flows.sh:
- on one hand, good to use "ip mptcp":
- more real
- but on the other hand, requiring a recent or a development version
might be an issues:
- some CI might not have the proper tool and would skip the test
- maybe not good to fallback to pm_nl_ctl: we would potentially not
have the same behaviour depending on the host
- one solution is maybe to have dedicated tests using 'ip mptcp'
that we would be skip if 'ip' is not available (or too old version)
- or: a parameter to the Bash scripts to use one or the other tool →
might be good to check for regressions in this tool as well and ask only
our CI to run those?
- note: it looks like no other selftests tool is depending on a
specific IPRoute2 version
12704505: New: [mptcp-next,v8,1/8] Squash to "mptcp: implement fastclose
xmit path"
12704509: New: [mptcp-next,v8,2/8] mptcp: fix opt size when sending DSS
+ MP_FAIL
12704506: New: [mptcp-next,v8,3/8] mptcp: fix a DSS option writing error
12704507: New: [mptcp-next,v8,4/8] mptcp: reduce branching when writing
MP_FAIL option
12704508: New: [mptcp-next,v8,5/8] mptcp: clarify when options can be used
12704510: New: [mptcp-next,v8,6/8] mptcp: allow sending both ADD_ADDR
and RM_ADDR
12704511: New: [mptcp-next,v8,7/8] mptcp: print out reset infos of MP_RST
12704512: New: [mptcp-next,v8,8/8] selftests: mptcp: add mp_fail testcases:
- the Squash-to should unblock the linked series to be sent upstream
- followed by 2 fixes for -net:
- first one should not be an issue as it is possible we were not
sending a DSS+MP_FAIL before (to be checked)
- 2nd might be needed when we want to send a DSS + something
else: MP_PRIO or RM_ADDR → might be important for -net
- maybe easier to send both to -net
- last patch seems to still have issues → blocking MP_FAIL series
Issues on Github:
https://github.com/multipath-tcp/mptcp_net-next/issues/
Recently opened (latest from last week: 250)
252 [syzkaller] WARNING in page_counter_cancel:
- also forwarded to us by Andrew Morton
- Mat has a patch but was not tested by syzbot due to removed
trailing whitespaces making the patch not valid
Bugs (opened, flagged as "bug" and assigned)
245 Packetdrill: Injected ADD_ADDR echo doesn't have the right info
[bug] [packetdrill] @dcaratti
Bugs (opened and flagged as "bug" and not assigned)
252 [syzkaller] WARNING in page_counter_cancel
250 [syzkaller] Use-after-free in subflow_state_change [bug] [syzkaller]:
- could be good to have a patch for -net
- *@Paolo*: did you work on a patch for this?
248 packetdrill: more tests failing due to packets arriving later
than expected [bug] [packetdrill]
225 selftests: join: "remove subflows and signal" is unstable [bug]
[selftests]
203 PM: server: accept subflows [bug]:
- TODO Matt: assign Kishen → done:
- See patches above
181 implement data_fin ack retransmission for subflow in TIME_WAIT
state [bug]
In Progress (opened, new feature and assigned)
234 Packetdrill: Support MPC+DATA+checksum error [enhancement]
[packetdrill] @dcaratti
216 The infinite mapping support [enhancement] @geliangtang:
- See patches above
186 Add netlink command support [enhancement] @mjmartineau:
- TODO Matt: assign Kishen → done:
- See patches above
171 iproute2: support removing ID 0 [enhancement] [iproute2]
@geliangtang:
- See patches above
167 packetdrill: add coverage for RM_ADDR [enhancement] [packetdrill]
@dcaratti
75 BPF: packet scheduler [enhancement] @geliangtang
74 BPF: path manager [enhancement] @geliangtang
For later (opened and not assigned assigned)
246 Netlink PM events: add one attribute about the connection type
(connect/accept) [enhancement]
236 Review supported sockopts list [enhancement]
222 Netlink event API: add SUBFLOW_CREATED event [enhancement]
215 TCP Urgent pointer and MPTCP [enhancement]
213 add MPTCP man page [enhancement]
210 Accept new subflows when the listening socket is closed or bind
to one IP? [enhancement]
208 better handing of ssk memory pressure in the TX path [enhancement]
202 Add sendmsg support for ancillary data [enhancement]
197 more mibs needed [enhancement]
180 Get an update when MPTCP fall back to TCP [enhancement]
177 improve retransmit subflow selection [enhancement]
169 packetdrill: add coverage for ADD_ADDR and MP_JOIN on a different
port [enhancement] [packetdrill]
163 allow ss dumping msk socket in TCP_LISTEN status [enhancement]
150 remove completely workqueue usage [enhancement]
141 avoid acquiring mptcp_data_lock() twice in the receive path
[enhancement]
133 PM: Closing the MPTCP connection when last subflow is not the
initial one and its IP address is removed [enhancement]
128 When the last subflow is closed without DATA_FIN and msk
Established, close msk (after a timeout) [enhancement]
79 allow 'force to MPTCP' mode: BPF [enhancement]
78 notify the application (userspace) when a subflow is
added/removed [enhancement]
77 [gs]etsockopt: forward to new/existing SF [enhancement]
76 [gs]etsockopt per subflow: BPF [enhancement]
61 move msk clone after ctx creation [enhancement]
59 (MP)TFO support [enhancement]
57 After a few attempts of failed MPTCP, directly fallback to TCP
for new connections [enhancement]
48 MP_FASTCLOSE support (send part remaining) [enhancement]
43 [syzkaller] Change syzkaller to exercise MPTCP inet_diag
interface [enhancement] [syzkaller]
41 reduce indirect call usage [enhancement]
24 Revisit layout of struct mptcp_subflow_context [enhancement]
Recently closed (since last meeting)
251 The best way to analyse MPTCPv1 performance? [QUESTION] [question]
242 Unexpected subflow management behaviour, following endpoint add
after subflow failure [bug] @pabeni
235 PM: create new subflow after one got closed [enhancement] @pabeni
158 iproute2: change backup mode (MP_PRIO) for active connections
[enhancement] [iproute2] @dcaratti
FYI: Current Roadmap:
- Bugs: https://github.com/multipath-tcp/mptcp_net-next/projects/2
- Current/Coming merge window (5.17):
https://github.com/multipath-tcp/mptcp_net-next/projects/12
- For later: https://github.com/multipath-tcp/mptcp_net-next/projects/4
Patches to send to netdev:
- net:
- probably best to send:
- mptcp: fix opt size when sending DSS + MP_FAIL
- mptcp: fix a DSS option writing error → but we might need
to change
- But if they are accepted after the last PR from Net maintainer
to Linus would delay stuff.
- So if we don't want to rush to look at the tests, we can also
send to net-next for the future -net (to be check which tree is merged
in which one first?
(net-next is proposed to be merged in Linus tree then -net is
merged with Linus tree and net-next is merged with -net)
- net-next:
- patches from Paolo could go there, fixing issues, see GH
issues/250:
- *@Paolo*: OK for you?
- + checksum fixes probably
- best to skip MP_FAIL series for now as we don't have a stable
selftest yet
- and no need to send Mat's series as it is linked to new
features in the Netlink PM part, not ready yet
Extra tests:
- news about Syzkaller? (Christoph / Mat):
- running the last couple of weeks, didn't find anything related
to MPTCP in the export branch
- issue /252 from syzbot
- news about interop with mptcp.org/other stacks? (Christoph):
- /
- news about Intel's kbuild? (Mat):
- looks like we still have the same issue, probably with RM_ADDR
- packetdrill (Davide):
- /
- Patchew (Davide):
- still applying patches, all good
- CI (Matth):
- KFENCE has been enabled, didn't spot anything so far
Github:
- Kishen has been added in the team: we can assign ticket to him,
quick go!
Next meeting:
- /!\ We are back on Thursday as before
- Next one on Thursday, the 13th of January.
- Usual UTC time: 16:00 UTC (8am PST, 5pm CET, 12am CST)
- Still open to everyone!
- https://annuel2.framapad.org/p/mptcp_upstreaming_20220113
Feel free to comment on these points and propose new ones for the next
meeting!
Talk to you on Thursday next week,
Matt
--
Tessares | Belgium | Hybrid Access Solutions
www.tessares.net
^ permalink raw reply
* Re: [PATCH 5.15 00/72] 5.15.13-rc2 review
From: Jeffrin Jose T @ 2022-01-05 18:15 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, torvalds, akpm, linux, shuah, patches, lkft-triage,
pavel, jonathanh, f.fainelli, stable
In-Reply-To: <YdWxh/OR0dQDeS9E@kroah.com>
On Wed, 2022-01-05 at 15:56 +0100, Greg Kroah-Hartman wrote:
> On Wed, Jan 05, 2022 at 06:32:43PM +0530, Jeffrin Jose T wrote:
> > On Tue, 2022-01-04 at 08:41 +0100, Greg Kroah-Hartman wrote:
> > > This is the start of the stable review cycle for the 5.15.13
> > > release.
> > > There are 72 patches in this series, all will be posted as a
> > > response
> > > to this one. If anyone has any issues with these being applied,
> > > please
> > > let me know.
> > >
> > > Responses should be made by Thu, 06 Jan 2022 07:38:29 +0000.
> > > Anything received after that time might be too late.
> > >
> > > The whole patch series can be found in one patch at:
> > >
> > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.15.13-rc2.gz
> > > or in the git tree and branch at:
> > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linu
> > > x-
> > > stable-rc.git linux-5.15.y
> > > and the diffstat can be found below.
> > >
> > > thanks,
> > >
> > > greg k-h
> > >
> > hello,
> >
> > There was a compilation error....
> >
> > -----------x--------------x------------------x--
> > MODPOST vmlinux.symvers
> > MODINFO modules.builtin.modinfo
> > GEN modules.builtin
> > BTF: .tmp_vmlinux.btf: pahole (pahole) is not available
> > Failed to generate BTF for vmlinux
> > Try to disable CONFIG_DEBUG_INFO_BTF
> > make: *** [Makefile:1183: vmlinux] Error 1
>
> Is this a regression? If so, what commit caused this?
>
> > i did CONFIG_DEBUG_INFO_BTF=n in .config and then compilation was
> > success.
>
> Or you can install pahole, right? That's a requirement for that
> build
> option I think.
>
i installed pahole which is in package "dwarves" in debian after
reading yours and shuah's message
i agree with shuah's answer.
thanks shuah
--
software engineer
rajagiri school of engineering and technology - autonomous
^ permalink raw reply
* Aw: Re: barebox extending boot-scripts
From: Frank Wunderlich @ 2022-01-05 18:13 UTC (permalink / raw)
To: Ahmad Fatoum; +Cc: barebox
In-Reply-To: <65c439c2-d82a-5cc7-133b-aae7df21b610@pengutronix.de>
Hi,
> Gesendet: Mittwoch, 05. Januar 2022 um 17:07 Uhr
> Von: "Ahmad Fatoum" <a.fatoum@pengutronix.de>
> An: "Frank Wunderlich" <frank-w@public-files.de>, barebox@lists.infradead.org
> Betreff: Re: barebox extending boot-scripts
>
> Hi,
>
> On 05.01.22 16:20, Frank Wunderlich wrote:
> > Hi,
> >
> > i'm making my first steps and try to add more boot-scripts (to land in /env/boot)
> >
> > i added a scipt in
> >
> > arch/arm/boards/rockchip-rk3568-evb/defaultenv/mmc-linux
>
> This should be defaultenv/boot/mmc-linux instead.
>
> > and set
> >
> > DEFAULT_ENVIRONMENT_PATH [=arch/arm/boards/rockchip-rk3568-evb/defaultenv]
> >
> > but if i boot the board /env/boot only contains the 2 default scripts
> >
> > barebox@Rockchip RK3568 EVB:/ ls /env/boot/
> > bnet net
>
> Try ls -R /env, you should see mmc-linux at top-level with your
> current setup.
>
> > so maybe the dir/config-option i used is for defining variables only right?
>
> Top level is only meant for directories. There are directories for the different
> stuff, e.g. variables go into /env/nv/
>
> > should this point to an directory or a file?
>
> The config option is meant for use with external build systems, e.g. buildroot
> or PTXdist. For boards in-tree, you can add bbenv-y in the Makefile and call
>
> // assuming directory is called defaultenv-myboard
> defaultenv_append_directory(defaultenv_myboard);
>
> in the board code, see e.g. arch/arm/boards/embest-marsboard for an example.
>
> The reason for avoiding the config option for in-tree boards is that a single barebox
> configuration can build multiple boards in one go:
> extreme case: imx_v7_defconfig, which builds marsboard also builds more than 100 other images.
>
> The config option is global, but by explicitly calling defaultenv_append_directory,
> you can have board-specific environments.
will try this approach, thanks
> > i see this file which looks like the source of it
> >
> > ./defaultenv/defaultenv-2-base/boot/net
> >
> > I've put them there and they appear, but this is not board specific
>
> Ye, you can use this for debugging, but stuff upstreamed there must be generally
> applicable.
>
> > so if i later want to upstream one this is maybe not the right place.
>
> Boot scripts for publicly available evaluation kits are often not good candidates
> for upstreaming, because everybody using the EVKs has different thoughts on how to
> boot. The best way would be to use bootloader spec. It's one or more files you
> place at a known location that describe where your kernel and device tree are and
> what command line arguments to use and barebox can then automatically generate
> boot entries from all available bootloader spec files.
>
> See https://elinux.org/images/9/9d/Barebox-bells-n-whistles.pdf for an example
> of how to set this up. This is what I'd recommend instead of writing your own
> scripts.
>
> > ./defaultenv/defaultenv-2-menu/menu/10-boot-all/net
> >
> > seems to be a menu entry, but have not yet figured out how i can define one to add my scripts too
> >
> > have not found anything for it in the documentation yet
>
> The default boot menu is populated with the boot entries extracted from
> the contents of $global.boot.default.
currently only net is listed there
barebox@Rockchip RK3568 EVB:/ echo $global.boot.default
net
but in /env/boot i have my 2 new scripts
barebox@Rockchip RK3568 EVB:/ ls /env/boot
bnet mmc-linux net tftp-linux
> boot -m will display that menu. It will also include all bootloader spec files.
> If that suffices, you won't need to create your own menu. If you want though,
> check the help text of the menutree command.
needed to add this option, and now it prints only "net" and "back",not my own scripts ;(
do i need my scripts to ./defaultenv/defaultenv-2-menu/menu/10-boot-all/ too?
> To boot into the boot menu, set nv autoboot=menu. "Detect bootsources" will
> list boot sources known to the barebox boot command.
is this stored anywhere so that is persistent on next reboot?
btw. how does saveenv exactly work (which part/filename/offset is used)? sasha told me that device will be enumerated to the current boot device, but where on this device is the env stored?
> See magicvar for a listing of all magic variables, or refer to the documentation.
>
> > btw. is there a way to use ls with wildcard without printing the path?
> >
> > ls /mnt/sd.1/extlinux/
> > Image_5.16 Image_5.16-next.gz Image_5.16.gz
> >
> > ls /mnt/sd.1/extlinux/Image*
> > /mnt/sd.1/extlinux/Image_5.16
> > /mnt/sd.1/extlinux/Image_5.16-next.gz
> > /mnt/sd.1/extlinux/Image_5.16.gz
> >
> > i want to list only files matching Image*, but without path....number of columns does not matter
>
> Yes, cd /mnt/sd.1/extlinux
>
> Cheers,
> Ahmad
mhm, simple ;) can i store the active directory to restore it after script was run (if needed, e.g. on error booting)?
pwd shows current directory, but i cannot put it into an var...the bash approach does not work
barebox@Rockchip RK3568 EVB:/mnt/sd.1/extlinux pwd
/mnt/sd.1/extlinux
barebox@Rockchip RK3568 EVB:/mnt/sd.1/extlinux thisdir=$(pwd)
barebox@Rockchip RK3568 EVB:/mnt/sd.1/extlinux echo $thisdir
$(pwd)
barebox@Rockchip RK3568 EVB:/mnt/sd.1/extlinux
regards Frank
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply
* Re: [PATCH net 1/2] net: bridge: mcast: add and enforce query interval minimum
From: Eric Dumazet @ 2022-01-05 18:14 UTC (permalink / raw)
To: Nikolay Aleksandrov, netdev
Cc: eric.dumazet, stable, herbert, roopa, davem, bridge, kuba
In-Reply-To: <20211227172116.320768-2-nikolay@nvidia.com>
On 12/27/21 09:21, Nikolay Aleksandrov wrote:
> As reported[1] if query interval is set too low and we have multiple
> bridges or even a single bridge with multiple querier vlans configured
> we can crash the machine. Add a 1 second minimum which must be enforced
> by overwriting the value if set lower (i.e. without returning an error) to
> avoid breaking user-space. If that happens a log message is emitted to let
> the administrator know that the interval has been set to the minimum.
> The issue has been present since these intervals could be user-controlled.
>
> [1] https://lore.kernel.org/netdev/e8b9ce41-57b9-b6e2-a46a-ff9c791cf0ba@gmail.com/
>
> Fixes: d902eee43f19 ("bridge: Add multicast count/interval sysfs entries")
> Reported-by: Eric Dumazet <eric.dumazet@gmail.com>
> Signed-off-by: Nikolay Aleksandrov <nikolay@nvidia.com>
> ---
Reviewed-by: Eric Dumazet <edumazet@google.com>
Thanks !
^ permalink raw reply
* Re: [Bridge] [PATCH net 1/2] net: bridge: mcast: add and enforce query interval minimum
From: Eric Dumazet @ 2022-01-05 18:14 UTC (permalink / raw)
To: Nikolay Aleksandrov, netdev
Cc: herbert, eric.dumazet, bridge, stable, roopa, kuba, davem
In-Reply-To: <20211227172116.320768-2-nikolay@nvidia.com>
On 12/27/21 09:21, Nikolay Aleksandrov wrote:
> As reported[1] if query interval is set too low and we have multiple
> bridges or even a single bridge with multiple querier vlans configured
> we can crash the machine. Add a 1 second minimum which must be enforced
> by overwriting the value if set lower (i.e. without returning an error) to
> avoid breaking user-space. If that happens a log message is emitted to let
> the administrator know that the interval has been set to the minimum.
> The issue has been present since these intervals could be user-controlled.
>
> [1] https://lore.kernel.org/netdev/e8b9ce41-57b9-b6e2-a46a-ff9c791cf0ba@gmail.com/
>
> Fixes: d902eee43f19 ("bridge: Add multicast count/interval sysfs entries")
> Reported-by: Eric Dumazet <eric.dumazet@gmail.com>
> Signed-off-by: Nikolay Aleksandrov <nikolay@nvidia.com>
> ---
Reviewed-by: Eric Dumazet <edumazet@google.com>
Thanks !
^ permalink raw reply
* Re: [PATCH] PCI: iproc: Set all 24 bits of PCI class code
From: Pali Rohár @ 2022-01-05 18:13 UTC (permalink / raw)
To: Ray Jui
Cc: Roman Bacik, Lorenzo Pieralisi, Rob Herring,
Krzysztof Wilczyński, Bjorn Helgaas,
bcm-kernel-feedback-list, linux-pci, linux-arm-kernel,
linux-kernel
In-Reply-To: <244e74d9-1b46-2abc-6c2a-c089fa5b68b4@broadcom.com>
Hello!
On Wednesday 05 January 2022 09:51:48 Ray Jui wrote:
> Hi Pali,
>
> On 1/5/2022 1:35 AM, Pali Rohár wrote:
> > Register 0x43c in its low 24 bits contains PCI class code.
> >
> > Update code to set all 24 bits of PCI class code and not only upper 16 bits
> > of PCI class code.
> >
> > Use a new macro PCI_CLASS_BRIDGE_PCI_NORMAL which represents whole 24 bits
> > of normal PCI bridge class.
> >
> > Signed-off-by: Pali Rohár <pali@kernel.org>
> >
> > ---
> > Roman helped me with this change and confirmed that class code is stored
> > really in bits [23:0] of custom register 0x43c (normally class code is
> > stored in bits [31:8] of pci register 0x08).
> >
> > This patch depends on patch which adds PCI_CLASS_BRIDGE_PCI_NORMAL macro:
> > https://lore.kernel.org/linux-pci/20211220145140.31898-1-pali@kernel.org/
> > ---
> > drivers/pci/controller/pcie-iproc.c | 9 ++++-----
> > 1 file changed, 4 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/pci/controller/pcie-iproc.c b/drivers/pci/controller/pcie-iproc.c
> > index 3df4ab209253..2519201b0e51 100644
> > --- a/drivers/pci/controller/pcie-iproc.c
> > +++ b/drivers/pci/controller/pcie-iproc.c
> > @@ -789,14 +789,13 @@ static int iproc_pcie_check_link(struct iproc_pcie *pcie)
> > return -EFAULT;
> > }
> >
> > - /* force class to PCI_CLASS_BRIDGE_PCI (0x0604) */
> > + /* force class to PCI_CLASS_BRIDGE_PCI_NORMAL (0x060400) */
> > #define PCI_BRIDGE_CTRL_REG_OFFSET 0x43c
> > -#define PCI_CLASS_BRIDGE_MASK 0xffff00
> > -#define PCI_CLASS_BRIDGE_SHIFT 8
> > +#define PCI_BRIDGE_CTRL_REG_CLASS_MASK 0xffffff
> > iproc_pci_raw_config_read32(pcie, 0, PCI_BRIDGE_CTRL_REG_OFFSET,
> > 4, &class);
> > - class &= ~PCI_CLASS_BRIDGE_MASK;
> > - class |= (PCI_CLASS_BRIDGE_PCI << PCI_CLASS_BRIDGE_SHIFT);
> > + class &= ~PCI_BRIDGE_CTRL_REG_CLASS_MASK;
> > + class |= PCI_CLASS_BRIDGE_PCI_NORMAL;
> > iproc_pci_raw_config_write32(pcie, 0, PCI_BRIDGE_CTRL_REG_OFFSET,
> > 4, class);
> >
>
> I have two comments:
>
> 1. You do not seem to generate the email list using the
> get_maintainer.pl script, so the two maintainers for Broadcom ARM
> architecture (Ray Jui and Scott Branden) are left out.
Ou, sorry for that! I have generated this patch for U-Boot and Linux
kernel and probably mixed or forgot to include correct recipients for
correct project.
> 2. I suppose 'PCI_CLASS_BRIDGE_PCI_NORMAL' is defined in some common PCI
> header in a separate patch as described in the commit message. Then how
> come these patches are not constructed with a patch series?
Yes, PCI_CLASS_BRIDGE_PCI_NORMAL is a new constant for common pci header
file defined in patch linked in commit message.
https://lore.kernel.org/linux-pci/20211220145140.31898-1-pali@kernel.org/
Originally I included this change in v1 of linked patch in December but
I realized that it does not match standard PCI config space (different
offset 0x43c vs 0x08 and also different shift 0x8 vs 0x0) and probably
there is something either incorrect or really non-standard. So later in
December I dropped iproc_pcie_check_link() change in v2 of the linked
patch where is introduced PCI_CLASS_BRIDGE_PCI_NORMAL and now sent new
change for iproc_pcie_check_link() separately.
Technically, linked patch in commit message is just extracting code into
the common macros without any functional changed. But change in this
iproc_pcie_check_link() has also functional change as now also lower 8
bits of class code are changed. So in my opinion this patch should be
really separate of linked patch.
I hope that Lorenzo and Bjorn take patches in correct order...
> Other than, the change itself is exactly what I sent to Roman and looks
> good to me. Thanks.
>
> Acked-by: Ray Jui <ray.jui@broadcom.com>
Perfect!
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] sh: sq: use default_groups in kobj_type
From: Greg Kroah-Hartman @ 2022-01-05 18:13 UTC (permalink / raw)
To: Rob Landley; +Cc: linux-kernel, Yoshinori Sato, Rich Felker, linux-sh
In-Reply-To: <616fabc9-cf79-4c84-a1cc-6ecede77fa9c@landley.net>
On Wed, Jan 05, 2022 at 12:11:25PM -0600, Rob Landley wrote:
> On 1/5/22 11:52 AM, Greg Kroah-Hartman wrote:
> > On Wed, Jan 05, 2022 at 11:46:28AM -0600, Rob Landley wrote:
> >> On 1/4/22 10:22 AM, Greg Kroah-Hartman wrote:
> >> > There are currently 2 ways to create a set of sysfs files for a
> >> > kobj_type, through the default_attrs field, and the default_groups
> >> > field. Move the sh sq sysfs code to use default_groups field which has
> >> > been the preferred way since aa30f47cf666 ("kobject: Add support for
> >> > default attribute groups to kobj_type") so that we can soon get rid of
> >> > the obsolete default_attrs field.
> >>
> >> Let's see, sh4-specific, depends on CONFIG_SH_STORE_QUEUES... it built but I'm
> >> not finding an "sq" entry under /proc. (Or anything with "mapping" in it...)
> >>
> >> Oh well, probably right? Didn't break anything for me:
> >>
> >> Tested-by: Rob Landley <rob@landley.net>
> >
> > Thanks! Seems to pass 0-day testing as well :)
> >
> > Should I take this in my tree?
>
> Yes please.
Wonderful, will go do that now.
greg k-h
^ permalink raw reply
* Re: [PATCH] PCI: iproc: Set all 24 bits of PCI class code
From: Pali Rohár @ 2022-01-05 18:13 UTC (permalink / raw)
To: Ray Jui
Cc: Roman Bacik, Lorenzo Pieralisi, Rob Herring,
Krzysztof Wilczyński, Bjorn Helgaas,
bcm-kernel-feedback-list, linux-pci, linux-arm-kernel,
linux-kernel
In-Reply-To: <244e74d9-1b46-2abc-6c2a-c089fa5b68b4@broadcom.com>
Hello!
On Wednesday 05 January 2022 09:51:48 Ray Jui wrote:
> Hi Pali,
>
> On 1/5/2022 1:35 AM, Pali Rohár wrote:
> > Register 0x43c in its low 24 bits contains PCI class code.
> >
> > Update code to set all 24 bits of PCI class code and not only upper 16 bits
> > of PCI class code.
> >
> > Use a new macro PCI_CLASS_BRIDGE_PCI_NORMAL which represents whole 24 bits
> > of normal PCI bridge class.
> >
> > Signed-off-by: Pali Rohár <pali@kernel.org>
> >
> > ---
> > Roman helped me with this change and confirmed that class code is stored
> > really in bits [23:0] of custom register 0x43c (normally class code is
> > stored in bits [31:8] of pci register 0x08).
> >
> > This patch depends on patch which adds PCI_CLASS_BRIDGE_PCI_NORMAL macro:
> > https://lore.kernel.org/linux-pci/20211220145140.31898-1-pali@kernel.org/
> > ---
> > drivers/pci/controller/pcie-iproc.c | 9 ++++-----
> > 1 file changed, 4 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/pci/controller/pcie-iproc.c b/drivers/pci/controller/pcie-iproc.c
> > index 3df4ab209253..2519201b0e51 100644
> > --- a/drivers/pci/controller/pcie-iproc.c
> > +++ b/drivers/pci/controller/pcie-iproc.c
> > @@ -789,14 +789,13 @@ static int iproc_pcie_check_link(struct iproc_pcie *pcie)
> > return -EFAULT;
> > }
> >
> > - /* force class to PCI_CLASS_BRIDGE_PCI (0x0604) */
> > + /* force class to PCI_CLASS_BRIDGE_PCI_NORMAL (0x060400) */
> > #define PCI_BRIDGE_CTRL_REG_OFFSET 0x43c
> > -#define PCI_CLASS_BRIDGE_MASK 0xffff00
> > -#define PCI_CLASS_BRIDGE_SHIFT 8
> > +#define PCI_BRIDGE_CTRL_REG_CLASS_MASK 0xffffff
> > iproc_pci_raw_config_read32(pcie, 0, PCI_BRIDGE_CTRL_REG_OFFSET,
> > 4, &class);
> > - class &= ~PCI_CLASS_BRIDGE_MASK;
> > - class |= (PCI_CLASS_BRIDGE_PCI << PCI_CLASS_BRIDGE_SHIFT);
> > + class &= ~PCI_BRIDGE_CTRL_REG_CLASS_MASK;
> > + class |= PCI_CLASS_BRIDGE_PCI_NORMAL;
> > iproc_pci_raw_config_write32(pcie, 0, PCI_BRIDGE_CTRL_REG_OFFSET,
> > 4, class);
> >
>
> I have two comments:
>
> 1. You do not seem to generate the email list using the
> get_maintainer.pl script, so the two maintainers for Broadcom ARM
> architecture (Ray Jui and Scott Branden) are left out.
Ou, sorry for that! I have generated this patch for U-Boot and Linux
kernel and probably mixed or forgot to include correct recipients for
correct project.
> 2. I suppose 'PCI_CLASS_BRIDGE_PCI_NORMAL' is defined in some common PCI
> header in a separate patch as described in the commit message. Then how
> come these patches are not constructed with a patch series?
Yes, PCI_CLASS_BRIDGE_PCI_NORMAL is a new constant for common pci header
file defined in patch linked in commit message.
https://lore.kernel.org/linux-pci/20211220145140.31898-1-pali@kernel.org/
Originally I included this change in v1 of linked patch in December but
I realized that it does not match standard PCI config space (different
offset 0x43c vs 0x08 and also different shift 0x8 vs 0x0) and probably
there is something either incorrect or really non-standard. So later in
December I dropped iproc_pcie_check_link() change in v2 of the linked
patch where is introduced PCI_CLASS_BRIDGE_PCI_NORMAL and now sent new
change for iproc_pcie_check_link() separately.
Technically, linked patch in commit message is just extracting code into
the common macros without any functional changed. But change in this
iproc_pcie_check_link() has also functional change as now also lower 8
bits of class code are changed. So in my opinion this patch should be
really separate of linked patch.
I hope that Lorenzo and Bjorn take patches in correct order...
> Other than, the change itself is exactly what I sent to Roman and looks
> good to me. Thanks.
>
> Acked-by: Ray Jui <ray.jui@broadcom.com>
Perfect!
^ permalink raw reply
* Re: [PATCH v9 02/10] dax: Introduce holder for dax_device
From: Darrick J. Wong @ 2022-01-05 18:12 UTC (permalink / raw)
To: Shiyang Ruan
Cc: linux-kernel, linux-xfs, nvdimm, linux-mm, linux-fsdevel,
dan.j.williams, david, hch, jane.chu
In-Reply-To: <20211226143439.3985960-3-ruansy.fnst@fujitsu.com>
On Sun, Dec 26, 2021 at 10:34:31PM +0800, Shiyang Ruan wrote:
> To easily track filesystem from a pmem device, we introduce a holder for
> dax_device structure, and also its operation. This holder is used to
> remember who is using this dax_device:
> - When it is the backend of a filesystem, the holder will be the
> instance of this filesystem.
> - When this pmem device is one of the targets in a mapped device, the
> holder will be this mapped device. In this case, the mapped device
> has its own dax_device and it will follow the first rule. So that we
> can finally track to the filesystem we needed.
>
> The holder and holder_ops will be set when filesystem is being mounted,
> or an target device is being activated.
>
> Signed-off-by: Shiyang Ruan <ruansy.fnst@fujitsu.com>
> ---
> drivers/dax/super.c | 62 +++++++++++++++++++++++++++++++++++++++++++++
> include/linux/dax.h | 29 +++++++++++++++++++++
> 2 files changed, 91 insertions(+)
>
> diff --git a/drivers/dax/super.c b/drivers/dax/super.c
> index c46f56e33d40..94c51f2ee133 100644
> --- a/drivers/dax/super.c
> +++ b/drivers/dax/super.c
> @@ -20,15 +20,20 @@
> * @inode: core vfs
> * @cdev: optional character interface for "device dax"
> * @private: dax driver private data
> + * @holder_data: holder of a dax_device: could be filesystem or mapped device
> * @flags: state and boolean properties
> + * @ops: operations for dax_device
> + * @holder_ops: operations for the inner holder
> */
> struct dax_device {
> struct inode inode;
> struct cdev cdev;
> void *private;
> struct percpu_rw_semaphore rwsem;
> + void *holder_data;
> unsigned long flags;
> const struct dax_operations *ops;
> + const struct dax_holder_operations *holder_ops;
> };
>
> static dev_t dax_devt;
> @@ -192,6 +197,29 @@ int dax_zero_page_range(struct dax_device *dax_dev, pgoff_t pgoff,
> }
> EXPORT_SYMBOL_GPL(dax_zero_page_range);
>
> +int dax_holder_notify_failure(struct dax_device *dax_dev, u64 off,
> + u64 len, int mf_flags)
> +{
> + int rc;
> +
> + dax_read_lock(dax_dev);
> + if (!dax_alive(dax_dev)) {
> + rc = -ENXIO;
> + goto out;
> + }
> +
> + if (!dax_dev->holder_ops) {
> + rc = -EOPNOTSUPP;
> + goto out;
> + }
> +
> + rc = dax_dev->holder_ops->notify_failure(dax_dev, off, len, mf_flags);
> +out:
> + dax_read_unlock(dax_dev);
> + return rc;
> +}
> +EXPORT_SYMBOL_GPL(dax_holder_notify_failure);
> +
> #ifdef CONFIG_ARCH_HAS_PMEM_API
> void arch_wb_cache_pmem(void *addr, size_t size);
> void dax_flush(struct dax_device *dax_dev, void *addr, size_t size)
> @@ -254,6 +282,10 @@ void kill_dax(struct dax_device *dax_dev)
> return;
> dax_write_lock(dax_dev);
> clear_bit(DAXDEV_ALIVE, &dax_dev->flags);
> +
> + /* clear holder data */
> + dax_dev->holder_ops = NULL;
> + dax_dev->holder_data = NULL;
> dax_write_unlock(dax_dev);
> }
> EXPORT_SYMBOL_GPL(kill_dax);
> @@ -401,6 +433,36 @@ void put_dax(struct dax_device *dax_dev)
> }
> EXPORT_SYMBOL_GPL(put_dax);
>
> +void dax_register_holder(struct dax_device *dax_dev, void *holder,
> + const struct dax_holder_operations *ops)
> +{
> + if (!dax_alive(dax_dev))
> + return;
> +
> + dax_dev->holder_data = holder;
> + dax_dev->holder_ops = ops;
Shouldn't this return an error code if the dax device is dead or if
someone already registered a holder? I'm pretty sure XFS should not
bind to a dax device if someone else already registered for it...
...unless you want to use a notifier chain for failure events so that
there can be multiple consumers of dax failure events?
--D
> +}
> +EXPORT_SYMBOL_GPL(dax_register_holder);
> +
> +void dax_unregister_holder(struct dax_device *dax_dev)
> +{
> + if (!dax_alive(dax_dev))
> + return;
> +
> + dax_dev->holder_data = NULL;
> + dax_dev->holder_ops = NULL;
> +}
> +EXPORT_SYMBOL_GPL(dax_unregister_holder);
> +
> +void *dax_get_holder(struct dax_device *dax_dev)
> +{
> + if (!dax_alive(dax_dev))
> + return NULL;
> +
> + return dax_dev->holder_data;
> +}
> +EXPORT_SYMBOL_GPL(dax_get_holder);
> +
> /**
> * inode_dax: convert a public inode into its dax_dev
> * @inode: An inode with i_cdev pointing to a dax_dev
> diff --git a/include/linux/dax.h b/include/linux/dax.h
> index a146bfb80804..e16a9e0ee857 100644
> --- a/include/linux/dax.h
> +++ b/include/linux/dax.h
> @@ -44,6 +44,22 @@ struct dax_operations {
> #if IS_ENABLED(CONFIG_DAX)
> struct dax_device *alloc_dax(void *private, const struct dax_operations *ops,
> unsigned long flags);
> +struct dax_holder_operations {
> + /*
> + * notify_failure - notify memory failure into inner holder device
> + * @dax_dev: the dax device which contains the holder
> + * @offset: offset on this dax device where memory failure occurs
> + * @len: length of this memory failure event
> + * @flags: action flags for memory failure handler
> + */
> + int (*notify_failure)(struct dax_device *dax_dev, u64 offset,
> + u64 len, int mf_flags);
> +};
> +
> +void dax_register_holder(struct dax_device *dax_dev, void *holder,
> + const struct dax_holder_operations *ops);
> +void dax_unregister_holder(struct dax_device *dax_dev);
> +void *dax_get_holder(struct dax_device *dax_dev);
> void put_dax(struct dax_device *dax_dev);
> void kill_dax(struct dax_device *dax_dev);
> void dax_write_cache(struct dax_device *dax_dev, bool wc);
> @@ -71,6 +87,17 @@ static inline bool daxdev_mapping_supported(struct vm_area_struct *vma,
> return dax_synchronous(dax_dev);
> }
> #else
> +static inline void dax_register_holder(struct dax_device *dax_dev, void *holder,
> + const struct dax_holder_operations *ops)
> +{
> +}
> +static inline void dax_unregister_holder(struct dax_device *dax_dev)
> +{
> +}
> +static inline void *dax_get_holder(struct dax_device *dax_dev)
> +{
> + return NULL;
> +}
> static inline struct dax_device *alloc_dax(void *private,
> const struct dax_operations *ops, unsigned long flags)
> {
> @@ -209,6 +236,8 @@ size_t dax_copy_to_iter(struct dax_device *dax_dev, pgoff_t pgoff, void *addr,
> size_t bytes, struct iov_iter *i);
> int dax_zero_page_range(struct dax_device *dax_dev, pgoff_t pgoff,
> size_t nr_pages);
> +int dax_holder_notify_failure(struct dax_device *dax_dev, u64 off, u64 len,
> + int mf_flags);
> void dax_flush(struct dax_device *dax_dev, void *addr, size_t size);
>
> ssize_t dax_iomap_rw(struct kiocb *iocb, struct iov_iter *iter,
> --
> 2.34.1
>
>
>
^ permalink raw reply
* Re: [RFC v2 4/8] drm/amdgpu: Serialize non TDR gpu recovery with TDRs
From: Andrey Grodzovsky @ 2022-01-05 18:11 UTC (permalink / raw)
To: Christian König, Lazar, Lijo, dri-devel, amd-gfx
Cc: horace.chen, Monk.Liu
In-Reply-To: <9dc55576-19b1-d5e3-f4da-eede4db8b289@amd.com>
On 2022-01-05 7:31 a.m., Christian König wrote:
> Am 05.01.22 um 10:54 schrieb Lazar, Lijo:
>> On 12/23/2021 3:35 AM, Andrey Grodzovsky wrote:
>>> Use reset domain wq also for non TDR gpu recovery trigers
>>> such as sysfs and RAS. We must serialize all possible
>>> GPU recoveries to gurantee no concurrency there.
>>> For TDR call the original recovery function directly since
>>> it's already executed from within the wq. For others just
>>> use a wrapper to qeueue work and wait on it to finish.
>>>
>>> v2: Rename to amdgpu_recover_work_struct
>>>
>>> Signed-off-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
>>> ---
>>> drivers/gpu/drm/amd/amdgpu/amdgpu.h | 2 ++
>>> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 33
>>> +++++++++++++++++++++-
>>> drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 2 +-
>>> 3 files changed, 35 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>>> index b5ff76aae7e0..8e96b9a14452 100644
>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>>> @@ -1296,6 +1296,8 @@ bool amdgpu_device_has_job_running(struct
>>> amdgpu_device *adev);
>>> bool amdgpu_device_should_recover_gpu(struct amdgpu_device *adev);
>>> int amdgpu_device_gpu_recover(struct amdgpu_device *adev,
>>> struct amdgpu_job* job);
>>> +int amdgpu_device_gpu_recover_imp(struct amdgpu_device *adev,
>>> + struct amdgpu_job *job);
>>> void amdgpu_device_pci_config_reset(struct amdgpu_device *adev);
>>> int amdgpu_device_pci_reset(struct amdgpu_device *adev);
>>> bool amdgpu_device_need_post(struct amdgpu_device *adev);
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>>> index 7c063fd37389..258ec3c0b2af 100644
>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>>> @@ -4979,7 +4979,7 @@ static void amdgpu_device_recheck_guilty_jobs(
>>> * Returns 0 for success or an error on failure.
>>> */
>>> -int amdgpu_device_gpu_recover(struct amdgpu_device *adev,
>>> +int amdgpu_device_gpu_recover_imp(struct amdgpu_device *adev,
>>> struct amdgpu_job *job)
>>> {
>>> struct list_head device_list, *device_list_handle = NULL;
>>> @@ -5237,6 +5237,37 @@ int amdgpu_device_gpu_recover(struct
>>> amdgpu_device *adev,
>>> return r;
>>> }
>>> +struct amdgpu_recover_work_struct {
>>> + struct work_struct base;
>>> + struct amdgpu_device *adev;
>>> + struct amdgpu_job *job;
>>> + int ret;
>>> +};
>>> +
>>> +static void amdgpu_device_queue_gpu_recover_work(struct work_struct
>>> *work)
>>> +{
>>> + struct amdgpu_recover_work_struct *recover_work =
>>> container_of(work, struct amdgpu_recover_work_struct, base);
>>> +
>>> + recover_work->ret =
>>> amdgpu_device_gpu_recover_imp(recover_work->adev, recover_work->job);
>>> +}
>>> +/*
>>> + * Serialize gpu recover into reset domain single threaded wq
>>> + */
>>> +int amdgpu_device_gpu_recover(struct amdgpu_device *adev,
>>> + struct amdgpu_job *job)
>>> +{
>>> + struct amdgpu_recover_work_struct work = {.adev = adev, .job =
>>> job};
>>> +
>>> + INIT_WORK(&work.base, amdgpu_device_queue_gpu_recover_work);
>>> +
>>> + if (!queue_work(adev->reset_domain.wq, &work.base))
>>> + return -EAGAIN;
>>> +
>>
>> The decision to schedule a reset is made at this point. Subsequent
>> accesses to hardware may not be reliable. So should the flag in_reset
>> be set here itself rather than waiting for the work to start execution?
>
> No, when we race and lose the VM is completely lost and probably
> restarted by the hypervisor.
>
> And when we race and win we properly set the flag before signaling the
> hypervisor that it can continue with the reset.
>
>> Also, what about having the reset_active or in_reset flag in the
>> reset_domain itself?
>
> Of hand that sounds like a good idea.
What then about the adev->reset_sem semaphore ? Should we also move this
to reset_domain ? Both of the moves have functional
implications only for XGMI case because there will be contention over
accessing those single instance variables from multiple devices
while now each device has it's own copy.
What benefit the centralization into reset_domain gives - is it for
example to prevent one device in a hive trying to access through MMIO
another one's
VRAM (shared FB memory) while the other one goes through reset ?
Andrey
>
> Regards,
> Christian.
>
>>
>> Thanks,
>> Lijo
>>
>>> + flush_work(&work.base);
>>> +
>>> + return work.ret;
>>> +}
>>> +
>>> /**
>>> * amdgpu_device_get_pcie_info - fence pcie info about the PCIE slot
>>> *
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
>>> index bfc47bea23db..38c9fd7b7ad4 100644
>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
>>> @@ -63,7 +63,7 @@ static enum drm_gpu_sched_stat
>>> amdgpu_job_timedout(struct drm_sched_job *s_job)
>>> ti.process_name, ti.tgid, ti.task_name, ti.pid);
>>> if (amdgpu_device_should_recover_gpu(ring->adev)) {
>>> - amdgpu_device_gpu_recover(ring->adev, job);
>>> + amdgpu_device_gpu_recover_imp(ring->adev, job);
>>> } else {
>>> drm_sched_suspend_timeout(&ring->sched);
>>> if (amdgpu_sriov_vf(adev))
>>>
>
^ permalink raw reply
* Re: [RFC v2 4/8] drm/amdgpu: Serialize non TDR gpu recovery with TDRs
From: Andrey Grodzovsky @ 2022-01-05 18:11 UTC (permalink / raw)
To: Christian König, Lazar, Lijo, dri-devel, amd-gfx
Cc: horace.chen, daniel, Monk.Liu
In-Reply-To: <9dc55576-19b1-d5e3-f4da-eede4db8b289@amd.com>
On 2022-01-05 7:31 a.m., Christian König wrote:
> Am 05.01.22 um 10:54 schrieb Lazar, Lijo:
>> On 12/23/2021 3:35 AM, Andrey Grodzovsky wrote:
>>> Use reset domain wq also for non TDR gpu recovery trigers
>>> such as sysfs and RAS. We must serialize all possible
>>> GPU recoveries to gurantee no concurrency there.
>>> For TDR call the original recovery function directly since
>>> it's already executed from within the wq. For others just
>>> use a wrapper to qeueue work and wait on it to finish.
>>>
>>> v2: Rename to amdgpu_recover_work_struct
>>>
>>> Signed-off-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
>>> ---
>>> drivers/gpu/drm/amd/amdgpu/amdgpu.h | 2 ++
>>> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 33
>>> +++++++++++++++++++++-
>>> drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 2 +-
>>> 3 files changed, 35 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>>> index b5ff76aae7e0..8e96b9a14452 100644
>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>>> @@ -1296,6 +1296,8 @@ bool amdgpu_device_has_job_running(struct
>>> amdgpu_device *adev);
>>> bool amdgpu_device_should_recover_gpu(struct amdgpu_device *adev);
>>> int amdgpu_device_gpu_recover(struct amdgpu_device *adev,
>>> struct amdgpu_job* job);
>>> +int amdgpu_device_gpu_recover_imp(struct amdgpu_device *adev,
>>> + struct amdgpu_job *job);
>>> void amdgpu_device_pci_config_reset(struct amdgpu_device *adev);
>>> int amdgpu_device_pci_reset(struct amdgpu_device *adev);
>>> bool amdgpu_device_need_post(struct amdgpu_device *adev);
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>>> index 7c063fd37389..258ec3c0b2af 100644
>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>>> @@ -4979,7 +4979,7 @@ static void amdgpu_device_recheck_guilty_jobs(
>>> * Returns 0 for success or an error on failure.
>>> */
>>> -int amdgpu_device_gpu_recover(struct amdgpu_device *adev,
>>> +int amdgpu_device_gpu_recover_imp(struct amdgpu_device *adev,
>>> struct amdgpu_job *job)
>>> {
>>> struct list_head device_list, *device_list_handle = NULL;
>>> @@ -5237,6 +5237,37 @@ int amdgpu_device_gpu_recover(struct
>>> amdgpu_device *adev,
>>> return r;
>>> }
>>> +struct amdgpu_recover_work_struct {
>>> + struct work_struct base;
>>> + struct amdgpu_device *adev;
>>> + struct amdgpu_job *job;
>>> + int ret;
>>> +};
>>> +
>>> +static void amdgpu_device_queue_gpu_recover_work(struct work_struct
>>> *work)
>>> +{
>>> + struct amdgpu_recover_work_struct *recover_work =
>>> container_of(work, struct amdgpu_recover_work_struct, base);
>>> +
>>> + recover_work->ret =
>>> amdgpu_device_gpu_recover_imp(recover_work->adev, recover_work->job);
>>> +}
>>> +/*
>>> + * Serialize gpu recover into reset domain single threaded wq
>>> + */
>>> +int amdgpu_device_gpu_recover(struct amdgpu_device *adev,
>>> + struct amdgpu_job *job)
>>> +{
>>> + struct amdgpu_recover_work_struct work = {.adev = adev, .job =
>>> job};
>>> +
>>> + INIT_WORK(&work.base, amdgpu_device_queue_gpu_recover_work);
>>> +
>>> + if (!queue_work(adev->reset_domain.wq, &work.base))
>>> + return -EAGAIN;
>>> +
>>
>> The decision to schedule a reset is made at this point. Subsequent
>> accesses to hardware may not be reliable. So should the flag in_reset
>> be set here itself rather than waiting for the work to start execution?
>
> No, when we race and lose the VM is completely lost and probably
> restarted by the hypervisor.
>
> And when we race and win we properly set the flag before signaling the
> hypervisor that it can continue with the reset.
>
>> Also, what about having the reset_active or in_reset flag in the
>> reset_domain itself?
>
> Of hand that sounds like a good idea.
What then about the adev->reset_sem semaphore ? Should we also move this
to reset_domain ? Both of the moves have functional
implications only for XGMI case because there will be contention over
accessing those single instance variables from multiple devices
while now each device has it's own copy.
What benefit the centralization into reset_domain gives - is it for
example to prevent one device in a hive trying to access through MMIO
another one's
VRAM (shared FB memory) while the other one goes through reset ?
Andrey
>
> Regards,
> Christian.
>
>>
>> Thanks,
>> Lijo
>>
>>> + flush_work(&work.base);
>>> +
>>> + return work.ret;
>>> +}
>>> +
>>> /**
>>> * amdgpu_device_get_pcie_info - fence pcie info about the PCIE slot
>>> *
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
>>> index bfc47bea23db..38c9fd7b7ad4 100644
>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
>>> @@ -63,7 +63,7 @@ static enum drm_gpu_sched_stat
>>> amdgpu_job_timedout(struct drm_sched_job *s_job)
>>> ti.process_name, ti.tgid, ti.task_name, ti.pid);
>>> if (amdgpu_device_should_recover_gpu(ring->adev)) {
>>> - amdgpu_device_gpu_recover(ring->adev, job);
>>> + amdgpu_device_gpu_recover_imp(ring->adev, job);
>>> } else {
>>> drm_sched_suspend_timeout(&ring->sched);
>>> if (amdgpu_sriov_vf(adev))
>>>
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.