Re: [PATCH] selftests/vdso: Add linux/sched.h to fix CLONE_NEWTIME build error
On 10/2/24 16:51, Jason A. Donenfeld wrote: Wasn't this already submitted and commented on? https://lore.kernel.org/all/20240919111841.20226-1-liaoy...@huawei.com/ Thank you Jason. Yes we reviewed this - I asked Yu Liao to send me v2 since the define is coming in from pthread.h indirectly. Suraj, Thank for finding and fixing the problem. However Yu Liao sent in patch for this before you did. We will take that patch. thanks, -- Shuah
Re: [PATCH] selftests/vdso: Add linux/sched.h to fix CLONE_NEWTIME build error
Wasn't this already submitted and commented on? https://lore.kernel.org/all/20240919111841.20226-1-liaoy...@huawei.com/
Re: [PATCH] selftests/vdso: Add linux/sched.h to fix CLONE_NEWTIME build error
On 10/2/24 09:28, SurajSonawane2415 wrote: Fix build error in vdso_test_getrandom.c due to missing CLONE_NEWTIME. Include linux/sched.h to define CLONE_NEWTIME. Ensure successful compilation by resolving the missing header issue. Did you run "make headers" before building this test? It builds just fine for me on my system. + Adding Jason Donenfeld Signed-off-by: SurajSonawane2415 --- tools/testing/selftests/vDSO/vdso_test_getrandom.c | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/testing/selftests/vDSO/vdso_test_getrandom.c b/tools/testing/selftests/vDSO/vdso_test_getrandom.c index 72a1d9b43..3f2a4dbf8 100644 --- a/tools/testing/selftests/vDSO/vdso_test_getrandom.c +++ b/tools/testing/selftests/vDSO/vdso_test_getrandom.c @@ -22,6 +22,7 @@ #include #include #include +#include #include "../kselftest.h" #include "parse_vdso.h" thanks, -- Shuah
[PATCH] selftests/vdso: Add linux/sched.h to fix CLONE_NEWTIME build error
Fix build error in vdso_test_getrandom.c due to missing CLONE_NEWTIME. Include linux/sched.h to define CLONE_NEWTIME. Ensure successful compilation by resolving the missing header issue. Signed-off-by: SurajSonawane2415 --- tools/testing/selftests/vDSO/vdso_test_getrandom.c | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/testing/selftests/vDSO/vdso_test_getrandom.c b/tools/testing/selftests/vDSO/vdso_test_getrandom.c index 72a1d9b43..3f2a4dbf8 100644 --- a/tools/testing/selftests/vDSO/vdso_test_getrandom.c +++ b/tools/testing/selftests/vDSO/vdso_test_getrandom.c @@ -22,6 +22,7 @@ #include #include #include +#include #include "../kselftest.h" #include "parse_vdso.h" -- 2.34.1
Re: [PATCH] ieee802154: Fix build error
Hello Jinjie. On Mon, 09 Sep 2024 21:17:40 +0800, Jinjie Ruan wrote: > If REGMAP_SPI is m and IEEE802154_MCR20A is y, > > mcr20a.c:(.text+0x3ed6c5b): undefined reference to > `__devm_regmap_init_spi' > ld: mcr20a.c:(.text+0x3ed6cb5): undefined reference to > `__devm_regmap_init_spi' > > Select REGMAP_SPI for IEEE802154_MCR20A to fix it. > > [...] Applied, thanks! [1/1] ieee802154: Fix build error commit: addf89774e48c992316449ffab4f29c2309ebefb Best regards, Stefan Schmidt
[PATCH] ieee802154: Fix build error
If REGMAP_SPI is m and IEEE802154_MCR20A is y,
mcr20a.c:(.text+0x3ed6c5b): undefined reference to
`__devm_regmap_init_spi'
ld: mcr20a.c:(.text+0x3ed6cb5): undefined reference to
`__devm_regmap_init_spi'
Select REGMAP_SPI for IEEE802154_MCR20A to fix it.
Fixes: 8c6ad9cc5157 ("ieee802154: Add NXP MCR20A IEEE 802.15.4 transceiver
driver")
Signed-off-by: Jinjie Ruan
---
drivers/net/ieee802154/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ieee802154/Kconfig b/drivers/net/ieee802154/Kconfig
index 95da876c5613..1075e24b11de 100644
--- a/drivers/net/ieee802154/Kconfig
+++ b/drivers/net/ieee802154/Kconfig
@@ -101,6 +101,7 @@ config IEEE802154_CA8210_DEBUGFS
config IEEE802154_MCR20A
tristate "MCR20A transceiver driver"
+ select REGMAP_SPI
depends on IEEE802154_DRIVERS && MAC802154
depends on SPI
help
--
2.34.1
[PATCH] tracing/kprobes: Fix build error when find_module() is not available
From: Masami Hiramatsu (Google)
The kernel test robot reported that the find_module() is not available
if CONFIG_MODULES=n.
Fix this error by hiding find_modules() in #ifdef CONFIG_MODULES with
related rcu locks as try_module_get_by_name().
Reported-by: kernel test robot
Closes:
https://lore.kernel.org/oe-kbuild-all/202407070744.rclkn8sq-...@intel.com/
Closes:
https://lore.kernel.org/oe-kbuild-all/202407070917.vvucblas-...@intel.com/
Signed-off-by: Masami Hiramatsu (Google)
---
kernel/trace/trace_kprobe.c | 25 +++--
1 file changed, 19 insertions(+), 6 deletions(-)
diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c
index 4cee3442bcce..61a6da808203 100644
--- a/kernel/trace/trace_kprobe.c
+++ b/kernel/trace/trace_kprobe.c
@@ -794,6 +794,24 @@ static int validate_module_probe_symbol(const char
*modname, const char *symbol)
return 0;
}
+#ifdef CONFIG_MODULES
+/* Return NULL if the module is not loaded or under unloading. */
+static struct module *try_module_get_by_name(const char *name)
+{
+ struct module *mod;
+
+ rcu_read_lock_sched();
+ mod = find_module(name);
+ if (mod && !try_module_get(mod))
+ mod = NULL;
+ rcu_read_unlock_sched();
+
+ return mod;
+}
+#else
+#define try_module_get_by_name(name) (NULL)
+#endif
+
static int validate_probe_symbol(char *symbol)
{
struct module *mod = NULL;
@@ -805,12 +823,7 @@ static int validate_probe_symbol(char *symbol)
modname = symbol;
symbol = p + 1;
*p = '\0';
- /* Return 0 (defer) if the module does not exist yet. */
- rcu_read_lock_sched();
- mod = find_module(modname);
- if (mod && !try_module_get(mod))
- mod = NULL;
- rcu_read_unlock_sched();
+ mod = try_module_get_by_name(modname);
if (!mod)
goto out;
}
[PATCH] tracing/kprobes: Fix build error when find_module() is not available
From: Masami Hiramatsu (Google)
The kernel test robot reported that the find_module() is not available
if CONFIG_MODULES=n.
Fix this error by hiding find_modules() in #ifdef CONFIG_MODULES with
related rcu locks as try_module_get_by_name().
Reported-by: kernel test robot
Closes:
https://lore.kernel.org/oe-kbuild-all/202407070744.rclkn8sq-...@intel.com/
Closes:
https://lore.kernel.org/oe-kbuild-all/202407070917.vvucblas-...@intel.com/
Signed-off-by: Masami Hiramatsu (Google)
---
kernel/trace/trace_kprobe.c | 25 +++--
1 file changed, 19 insertions(+), 6 deletions(-)
diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c
index 4cee3442bcce..61a6da808203 100644
--- a/kernel/trace/trace_kprobe.c
+++ b/kernel/trace/trace_kprobe.c
@@ -794,6 +794,24 @@ static int validate_module_probe_symbol(const char
*modname, const char *symbol)
return 0;
}
+#ifdef CONFIG_MODULES
+/* Return NULL if the module is not loaded or under unloading. */
+static struct module *try_module_get_by_name(const char *name)
+{
+ struct module *mod;
+
+ rcu_read_lock_sched();
+ mod = find_module(name);
+ if (mod && !try_module_get(mod))
+ mod = NULL;
+ rcu_read_unlock_sched();
+
+ return mod;
+}
+#else
+#define try_module_get_by_name(name) (NULL)
+#endif
+
static int validate_probe_symbol(char *symbol)
{
struct module *mod = NULL;
@@ -805,12 +823,7 @@ static int validate_probe_symbol(char *symbol)
modname = symbol;
symbol = p + 1;
*p = '\0';
- /* Return 0 (defer) if the module does not exist yet. */
- rcu_read_lock_sched();
- mod = find_module(modname);
- if (mod && !try_module_get(mod))
- mod = NULL;
- rcu_read_unlock_sched();
+ mod = try_module_get_by_name(modname);
if (!mod)
goto out;
}
[PATCH AUTOSEL 5.4 10/14] csky: change a Kconfig symbol name to fix e1000 build error
From: Randy Dunlap [ Upstream commit d199161653d612b8fb96ac51bfd5b2d2782ecef3 ] e1000's #define of CONFIG_RAM_BASE conflicts with a Kconfig symbol in arch/csky/Kconfig. The symbol in e1000 has been around longer, so change arch/csky/ to use DRAM_BASE instead of RAM_BASE to remove the conflict. (although e1000 is also a 2-line change) Link: https://lkml.kernel.org/r/20210411055335.7111-1-rdun...@infradead.org Signed-off-by: Randy Dunlap Reported-by: kernel test robot Acked-by: Guo Ren Cc: Jesse Brandeburg Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin --- arch/csky/Kconfig| 2 +- arch/csky/include/asm/page.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/csky/Kconfig b/arch/csky/Kconfig index 48b2e1b59119..4f48a2f0513b 100644 --- a/arch/csky/Kconfig +++ b/arch/csky/Kconfig @@ -220,7 +220,7 @@ config FORCE_MAX_ZONEORDER int "Maximum zone order" default "11" -config RAM_BASE +config DRAM_BASE hex "DRAM start addr (the same with memory-section in dts)" default 0x0 diff --git a/arch/csky/include/asm/page.h b/arch/csky/include/asm/page.h index 9738eacefdc7..62bb307459ca 100644 --- a/arch/csky/include/asm/page.h +++ b/arch/csky/include/asm/page.h @@ -28,7 +28,7 @@ #define SSEG_SIZE 0x2000 #define LOWMEM_LIMIT (SSEG_SIZE * 2) -#define PHYS_OFFSET_OFFSET (CONFIG_RAM_BASE & (SSEG_SIZE - 1)) +#define PHYS_OFFSET_OFFSET (CONFIG_DRAM_BASE & (SSEG_SIZE - 1)) #ifndef __ASSEMBLY__ -- 2.30.2
[PATCH AUTOSEL 5.10 17/21] csky: change a Kconfig symbol name to fix e1000 build error
From: Randy Dunlap [ Upstream commit d199161653d612b8fb96ac51bfd5b2d2782ecef3 ] e1000's #define of CONFIG_RAM_BASE conflicts with a Kconfig symbol in arch/csky/Kconfig. The symbol in e1000 has been around longer, so change arch/csky/ to use DRAM_BASE instead of RAM_BASE to remove the conflict. (although e1000 is also a 2-line change) Link: https://lkml.kernel.org/r/20210411055335.7111-1-rdun...@infradead.org Signed-off-by: Randy Dunlap Reported-by: kernel test robot Acked-by: Guo Ren Cc: Jesse Brandeburg Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin --- arch/csky/Kconfig| 2 +- arch/csky/include/asm/page.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/csky/Kconfig b/arch/csky/Kconfig index 268fad5f51cf..7bf0a617e94c 100644 --- a/arch/csky/Kconfig +++ b/arch/csky/Kconfig @@ -292,7 +292,7 @@ config FORCE_MAX_ZONEORDER int "Maximum zone order" default "11" -config RAM_BASE +config DRAM_BASE hex "DRAM start addr (the same with memory-section in dts)" default 0x0 diff --git a/arch/csky/include/asm/page.h b/arch/csky/include/asm/page.h index 9b98bf31d57c..16878240ef9a 100644 --- a/arch/csky/include/asm/page.h +++ b/arch/csky/include/asm/page.h @@ -28,7 +28,7 @@ #define SSEG_SIZE 0x2000 #define LOWMEM_LIMIT (SSEG_SIZE * 2) -#define PHYS_OFFSET_OFFSET (CONFIG_RAM_BASE & (SSEG_SIZE - 1)) +#define PHYS_OFFSET_OFFSET (CONFIG_DRAM_BASE & (SSEG_SIZE - 1)) #ifndef __ASSEMBLY__ -- 2.30.2
[PATCH AUTOSEL 5.11 19/23] csky: change a Kconfig symbol name to fix e1000 build error
From: Randy Dunlap [ Upstream commit d199161653d612b8fb96ac51bfd5b2d2782ecef3 ] e1000's #define of CONFIG_RAM_BASE conflicts with a Kconfig symbol in arch/csky/Kconfig. The symbol in e1000 has been around longer, so change arch/csky/ to use DRAM_BASE instead of RAM_BASE to remove the conflict. (although e1000 is also a 2-line change) Link: https://lkml.kernel.org/r/20210411055335.7111-1-rdun...@infradead.org Signed-off-by: Randy Dunlap Reported-by: kernel test robot Acked-by: Guo Ren Cc: Jesse Brandeburg Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin --- arch/csky/Kconfig| 2 +- arch/csky/include/asm/page.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/csky/Kconfig b/arch/csky/Kconfig index 89dd2fcf38fa..3b16d081b4d7 100644 --- a/arch/csky/Kconfig +++ b/arch/csky/Kconfig @@ -292,7 +292,7 @@ config FORCE_MAX_ZONEORDER int "Maximum zone order" default "11" -config RAM_BASE +config DRAM_BASE hex "DRAM start addr (the same with memory-section in dts)" default 0x0 diff --git a/arch/csky/include/asm/page.h b/arch/csky/include/asm/page.h index 9b98bf31d57c..16878240ef9a 100644 --- a/arch/csky/include/asm/page.h +++ b/arch/csky/include/asm/page.h @@ -28,7 +28,7 @@ #define SSEG_SIZE 0x2000 #define LOWMEM_LIMIT (SSEG_SIZE * 2) -#define PHYS_OFFSET_OFFSET (CONFIG_RAM_BASE & (SSEG_SIZE - 1)) +#define PHYS_OFFSET_OFFSET (CONFIG_DRAM_BASE & (SSEG_SIZE - 1)) #ifndef __ASSEMBLY__ -- 2.30.2
Re: linux-next: Tree for Apr 16 (IMA appraise causing build error)
Hi, On 4/16/21 1:25 PM, Nayna wrote: > > On 4/16/21 2:53 PM, Randy Dunlap wrote: >> On 4/16/21 4:36 AM, Stephen Rothwell wrote: >>> Hi all, >>> >>> Changes since 20210415: >>> >> I noticed this build error message (on an i386 build): >> >> ../certs/Makefile:52: *** Could not determine digest type to use from kernel >> config. Stop. >> >> and when I was checking on why it happened, I noticed that >> # CONFIG_MODULES is not set >> >> and hence >> ifndef CONFIG_MODULE_SIG_HASH >> $(error Could not determine digest type to use from kernel config) >> endif >> >> CONFIG_MODULE_SIG_HASH is not set/enabled/defined. >> >> However, the .config file does have >> CONFIG_IMA_APPRAISE=y >> # CONFIG_IMA_ARCH_POLICY is not set >> # CONFIG_IMA_APPRAISE_BUILD_POLICY is not set >> CONFIG_IMA_APPRAISE_BOOTPARAM=y >> CONFIG_IMA_APPRAISE_MODSIG=y >> >> as well as >> CONFIG_MODULE_SIG_FORMAT=y >> >> due to a "select" by IMA_APPRAISE_MODSIG. >> (although I see that MODULE_SIG_FORMAT does not depend on MODULES) >> >> >> Is there anything that you can do (or recommend) to prevent >> the build error? >> >> >> >> BTW, it looks like this: >> config IMA_APPRAISE_REQUIRE_MODULE_SIGS >> bool "Appraise kernel modules signatures" >> depends on IMA_APPRAISE_BUILD_POLICY >> >> could also depend on MODULES. >> >> >> >> Full i386 randconfig file is attached. > > > With the new patchset "ima: kernel build support for loading the kernel > module signing key", there shouldn't be a difference when generating the > config file between MODULE_SIG and IMA_APPRAISE_MODSIG. Both prompt for the > hash algorithm. That patchset appears to be included in today's linux-next 2021-04-16. > Can you please explain how you generate randconfig? Do you use make xconfig? with the 'make randconfig' command. -- ~Randy
Re: linux-next: Tree for Apr 16 (IMA appraise causing build error)
On 4/16/21 2:53 PM, Randy Dunlap wrote: On 4/16/21 4:36 AM, Stephen Rothwell wrote: Hi all, Changes since 20210415: I noticed this build error message (on an i386 build): ../certs/Makefile:52: *** Could not determine digest type to use from kernel config. Stop. and when I was checking on why it happened, I noticed that # CONFIG_MODULES is not set and hence ifndef CONFIG_MODULE_SIG_HASH $(error Could not determine digest type to use from kernel config) endif CONFIG_MODULE_SIG_HASH is not set/enabled/defined. However, the .config file does have CONFIG_IMA_APPRAISE=y # CONFIG_IMA_ARCH_POLICY is not set # CONFIG_IMA_APPRAISE_BUILD_POLICY is not set CONFIG_IMA_APPRAISE_BOOTPARAM=y CONFIG_IMA_APPRAISE_MODSIG=y as well as CONFIG_MODULE_SIG_FORMAT=y due to a "select" by IMA_APPRAISE_MODSIG. (although I see that MODULE_SIG_FORMAT does not depend on MODULES) Is there anything that you can do (or recommend) to prevent the build error? BTW, it looks like this: config IMA_APPRAISE_REQUIRE_MODULE_SIGS bool "Appraise kernel modules signatures" depends on IMA_APPRAISE_BUILD_POLICY could also depend on MODULES. Full i386 randconfig file is attached. With the new patchset "ima: kernel build support for loading the kernel module signing key", there shouldn't be a difference when generating the config file between MODULE_SIG and IMA_APPRAISE_MODSIG. Both prompt for the hash algorithm. Can you please explain how you generate randconfig? Do you use make xconfig? Thanks & Regards, - Nayna
Re: linux-next: Tree for Apr 16 (IMA appraise causing build error)
On 4/16/21 4:36 AM, Stephen Rothwell wrote: > Hi all, > > Changes since 20210415: > I noticed this build error message (on an i386 build): ../certs/Makefile:52: *** Could not determine digest type to use from kernel config. Stop. and when I was checking on why it happened, I noticed that # CONFIG_MODULES is not set and hence ifndef CONFIG_MODULE_SIG_HASH $(error Could not determine digest type to use from kernel config) endif CONFIG_MODULE_SIG_HASH is not set/enabled/defined. However, the .config file does have CONFIG_IMA_APPRAISE=y # CONFIG_IMA_ARCH_POLICY is not set # CONFIG_IMA_APPRAISE_BUILD_POLICY is not set CONFIG_IMA_APPRAISE_BOOTPARAM=y CONFIG_IMA_APPRAISE_MODSIG=y as well as CONFIG_MODULE_SIG_FORMAT=y due to a "select" by IMA_APPRAISE_MODSIG. (although I see that MODULE_SIG_FORMAT does not depend on MODULES) Is there anything that you can do (or recommend) to prevent the build error? BTW, it looks like this: config IMA_APPRAISE_REQUIRE_MODULE_SIGS bool "Appraise kernel modules signatures" depends on IMA_APPRAISE_BUILD_POLICY could also depend on MODULES. Full i386 randconfig file is attached. thanks. -- ~Randy Reported-by: Randy Dunlap config-r8835.gz Description: application/gzip
Re: [PATCH 1/1] iommu/vt-d: Fix build error of pasid_enable_wpe() with !X86
On Sun, Apr 11, 2021 at 02:23:12PM +0800, Lu Baolu wrote: > drivers/iommu/intel/pasid.c | 2 ++ > 1 file changed, 2 insertions(+) Applied, thanks.
Re: [syzbot] linux-next build error (12)
On Mon, Mar 29, 2021 at 2:53 PM syzbot wrote: > > Hello, > > syzbot found the following issue on: > > HEAD commit:9d49ed9c Add linux-next specific files for 20210329 > git tree: linux-next > console output: https://syzkaller.appspot.com/x/log.txt?x=159b39aad0 > kernel config: https://syzkaller.appspot.com/x/.config?x=b55345a2d39e7782 > dashboard link: https://syzkaller.appspot.com/bug?extid=78983c59ee6ab57e6fcb > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > Reported-by: syzbot+78983c59ee6ab57e6...@syzkaller.appspotmail.com > > failed to run ["make" "-j" "64" "ARCH=x86_64" "bzImage"]: exit status 2 #syz fix: bpf: tcp: Limit calling some tcp cc functions to CONFIG_DYNAMIC_FTRACE
Re: [PATCH 1/1] iommu/vt-d: Fix build error of pasid_enable_wpe() with !X86
On 4/10/21 11:23 PM, Lu Baolu wrote:
> Commit f68c7f539b6e9 ("iommu/vt-d: Enable write protect for supervisor
> SVM") added pasid_enable_wpe() which hit below compile error with !X86.
>
> ../drivers/iommu/intel/pasid.c: In function 'pasid_enable_wpe':
> ../drivers/iommu/intel/pasid.c:554:22: error: implicit declaration of
> function 'read_cr0' [-Werror=implicit-function-declaration]
> 554 | unsigned long cr0 = read_cr0();
> | ^~~~
> In file included from ../include/linux/build_bug.h:5,
> from ../include/linux/bits.h:22,
> from ../include/linux/bitops.h:6,
> from ../drivers/iommu/intel/pasid.c:12:
> ../drivers/iommu/intel/pasid.c:557:23: error: 'X86_CR0_WP' undeclared (first
> use in this function)
> 557 | if (unlikely(!(cr0 & X86_CR0_WP))) {
> | ^~
> ../include/linux/compiler.h:78:42: note: in definition of macro 'unlikely'
>78 | # define unlikely(x) __builtin_expect(!!(x), 0)
> | ^
> ../drivers/iommu/intel/pasid.c:557:23: note: each undeclared identifier is
> reported only once for each function it appears in
> 557 | if (unlikely(!(cr0 & X86_CR0_WP))) {
> | ^~
> ../include/linux/compiler.h:78:42: note: in definition of macro 'unlikely'
>78 | # define unlikely(x) __builtin_expect(!!(x), 0)
> |
>
> Add the missing dependency.
>
> Cc: Sanjay Kumar
> Cc: Jacob Pan
> Cc: Randy Dunlap
> Reported-by: kernel test robot
> Reported-by: Randy Dunlap
> Fixes: f68c7f539b6e9 ("iommu/vt-d: Enable write protect for supervisor SVM")
> Signed-off-by: Lu Baolu
Acked-by: Randy Dunlap # build-tested
Thanks.
> ---
> drivers/iommu/intel/pasid.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/iommu/intel/pasid.c b/drivers/iommu/intel/pasid.c
> index 477b2e1d303c..72646bafc52f 100644
> --- a/drivers/iommu/intel/pasid.c
> +++ b/drivers/iommu/intel/pasid.c
> @@ -551,6 +551,7 @@ static void pasid_flush_caches(struct intel_iommu *iommu,
>
> static inline int pasid_enable_wpe(struct pasid_entry *pte)
> {
> +#ifdef CONFIG_X86
> unsigned long cr0 = read_cr0();
>
> /* CR0.WP is normally set but just to be sure */
> @@ -558,6 +559,7 @@ static inline int pasid_enable_wpe(struct pasid_entry
> *pte)
> pr_err_ratelimited("No CPU write protect!\n");
> return -EINVAL;
> }
> +#endif
> pasid_set_wpe(pte);
>
> return 0;
>
--
~Randy
[PATCH 1/1] iommu/vt-d: Fix build error of pasid_enable_wpe() with !X86
Commit f68c7f539b6e9 ("iommu/vt-d: Enable write protect for supervisor
SVM") added pasid_enable_wpe() which hit below compile error with !X86.
../drivers/iommu/intel/pasid.c: In function 'pasid_enable_wpe':
../drivers/iommu/intel/pasid.c:554:22: error: implicit declaration of function
'read_cr0' [-Werror=implicit-function-declaration]
554 | unsigned long cr0 = read_cr0();
| ^~~~
In file included from ../include/linux/build_bug.h:5,
from ../include/linux/bits.h:22,
from ../include/linux/bitops.h:6,
from ../drivers/iommu/intel/pasid.c:12:
../drivers/iommu/intel/pasid.c:557:23: error: 'X86_CR0_WP' undeclared (first
use in this function)
557 | if (unlikely(!(cr0 & X86_CR0_WP))) {
| ^~
../include/linux/compiler.h:78:42: note: in definition of macro 'unlikely'
78 | # define unlikely(x) __builtin_expect(!!(x), 0)
| ^
../drivers/iommu/intel/pasid.c:557:23: note: each undeclared identifier is
reported only once for each function it appears in
557 | if (unlikely(!(cr0 & X86_CR0_WP))) {
| ^~
../include/linux/compiler.h:78:42: note: in definition of macro 'unlikely'
78 | # define unlikely(x) __builtin_expect(!!(x), 0)
|
Add the missing dependency.
Cc: Sanjay Kumar
Cc: Jacob Pan
Cc: Randy Dunlap
Reported-by: kernel test robot
Reported-by: Randy Dunlap
Fixes: f68c7f539b6e9 ("iommu/vt-d: Enable write protect for supervisor SVM")
Signed-off-by: Lu Baolu
---
drivers/iommu/intel/pasid.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/iommu/intel/pasid.c b/drivers/iommu/intel/pasid.c
index 477b2e1d303c..72646bafc52f 100644
--- a/drivers/iommu/intel/pasid.c
+++ b/drivers/iommu/intel/pasid.c
@@ -551,6 +551,7 @@ static void pasid_flush_caches(struct intel_iommu *iommu,
static inline int pasid_enable_wpe(struct pasid_entry *pte)
{
+#ifdef CONFIG_X86
unsigned long cr0 = read_cr0();
/* CR0.WP is normally set but just to be sure */
@@ -558,6 +559,7 @@ static inline int pasid_enable_wpe(struct pasid_entry *pte)
pr_err_ratelimited("No CPU write protect!\n");
return -EINVAL;
}
+#endif
pasid_set_wpe(pte);
return 0;
--
2.25.1
[PATCH RESEND] csky: change a Kconfig symbol name to fix e1000 build error
e1000's #define of CONFIG_RAM_BASE conflicts with a Kconfig symbol in arch/csky/Kconfig. The symbol in e1000 has been around longer, so change arch/csky/ to use DRAM_BASE instead of RAM_BASE to remove the conflict. (although e1000 is also a 2-line change) Now build-tested. Signed-off-by: Randy Dunlap Reported-by: kernel test robot Cc: Andrew Morton Cc: Jesse Brandeburg Cc: Tony Nguyen Cc: intel-wired-...@lists.osuosl.org Cc: Guo Ren Cc: Guo Ren Cc: linux-c...@vger.kernel.org Acked-by: Guo Ren --- Andrew, please merge. v2: Add Acked-by: Guo Ren Has now been build-tested. IMO "CONFIG_" namespace should belong to Kconfig files, not individual drivers, but e1000 isn't the only driver that uses CONFIG_ symbols. arch/csky/Kconfig|2 +- arch/csky/include/asm/page.h |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) --- linux-next-20210409.orig/arch/csky/include/asm/page.h +++ linux-next-20210409/arch/csky/include/asm/page.h @@ -28,7 +28,7 @@ #define SSEG_SIZE 0x2000 #define LOWMEM_LIMIT (SSEG_SIZE * 2) -#define PHYS_OFFSET_OFFSET (CONFIG_RAM_BASE & (SSEG_SIZE - 1)) +#define PHYS_OFFSET_OFFSET (CONFIG_DRAM_BASE & (SSEG_SIZE - 1)) #ifndef __ASSEMBLY__ --- linux-next-20210409.orig/arch/csky/Kconfig +++ linux-next-20210409/arch/csky/Kconfig @@ -314,7 +314,7 @@ config FORCE_MAX_ZONEORDER int "Maximum zone order" default "11" -config RAM_BASE +config DRAM_BASE hex "DRAM start addr (the same with memory-section in dts)" default 0x0
Re: [PATCH -next] ARM: spear: Fix build error with CONFIG_ARCH_SPEAR3XX
在 2021/4/9 12:03, Viresh Kumar 写道:
On 09-04-21, 09:55, Chen Lifu wrote:
commit 77f983a9df42 ("spi: pl022: Use GPIOs looked up by the core")
deleted 'struct pl022_ssp_controller' member 'num_chipselect'.
We get build error when CONFIG_ARCH_SPEAR3XX is set:
arch/arm/mach-spear/spear3xx.c:42:3: error: 'struct pl022_ssp_controller' has
no member named 'num_chipselect'
42 | .num_chipselect = 2,
| ^~
arch/arm/mach-spear/spear3xx.c:42:20: warning: initialization of 'void *' from
'int' makes pointer from integer without a cast [-Wint-conversion]
42 | .num_chipselect = 2,
|^
Fix the issue by deleting the initialization of 'num_chipselect'
in spear3xx.c.
Fixes: 77f983a9df42 ("spi: pl022: Use GPIOs looked up by the core")
Reported-by: Hulk Robot
Signed-off-by: Chen Lifu
---
arch/arm/mach-spear/spear3xx.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/arch/arm/mach-spear/spear3xx.c b/arch/arm/mach-spear/spear3xx.c
index 8537fcffe5a8..f83321d5e353 100644
--- a/arch/arm/mach-spear/spear3xx.c
+++ b/arch/arm/mach-spear/spear3xx.c
@@ -30,16 +30,6 @@ struct pl022_ssp_controller pl022_plat_data = {
.dma_filter = pl08x_filter_id,
.dma_tx_param = "ssp0_tx",
.dma_rx_param = "ssp0_rx",
- /*
-* This is number of spi devices that can be connected to spi. There are
-* two type of chipselects on which slave devices can work. One is chip
-* select provided by spi masters other is controlled through external
-* gpio's. We can't use chipselect provided from spi master (because as
-* soon as FIFO becomes empty, CS is disabled and transfer ends). So
-* this number now depends on number of gpios available for spi. each
-* slave on each master requires a separate gpio pin.
-*/
- .num_chipselect = 2,
};
A patch is already applied by Mark to fix this issue.
Thanks.
---
Chen Lifu
Re: [PATCH -next] ARM: spear: Fix build error with CONFIG_ARCH_SPEAR3XX
On 09-04-21, 09:55, Chen Lifu wrote:
> commit 77f983a9df42 ("spi: pl022: Use GPIOs looked up by the core")
> deleted 'struct pl022_ssp_controller' member 'num_chipselect'.
> We get build error when CONFIG_ARCH_SPEAR3XX is set:
> arch/arm/mach-spear/spear3xx.c:42:3: error: 'struct pl022_ssp_controller' has
> no member named 'num_chipselect'
>42 | .num_chipselect = 2,
> | ^~
> arch/arm/mach-spear/spear3xx.c:42:20: warning: initialization of 'void *'
> from 'int' makes pointer from integer without a cast [-Wint-conversion]
>42 | .num_chipselect = 2,
> |^
>
> Fix the issue by deleting the initialization of 'num_chipselect'
> in spear3xx.c.
>
> Fixes: 77f983a9df42 ("spi: pl022: Use GPIOs looked up by the core")
> Reported-by: Hulk Robot
> Signed-off-by: Chen Lifu
> ---
> arch/arm/mach-spear/spear3xx.c | 10 --
> 1 file changed, 10 deletions(-)
>
> diff --git a/arch/arm/mach-spear/spear3xx.c b/arch/arm/mach-spear/spear3xx.c
> index 8537fcffe5a8..f83321d5e353 100644
> --- a/arch/arm/mach-spear/spear3xx.c
> +++ b/arch/arm/mach-spear/spear3xx.c
> @@ -30,16 +30,6 @@ struct pl022_ssp_controller pl022_plat_data = {
> .dma_filter = pl08x_filter_id,
> .dma_tx_param = "ssp0_tx",
> .dma_rx_param = "ssp0_rx",
> - /*
> - * This is number of spi devices that can be connected to spi. There are
> - * two type of chipselects on which slave devices can work. One is chip
> - * select provided by spi masters other is controlled through external
> - * gpio's. We can't use chipselect provided from spi master (because as
> - * soon as FIFO becomes empty, CS is disabled and transfer ends). So
> - * this number now depends on number of gpios available for spi. each
> - * slave on each master requires a separate gpio pin.
> - */
> - .num_chipselect = 2,
> };
A patch is already applied by Mark to fix this issue.
--
viresh
[PATCH -next] ARM: spear: Fix build error with CONFIG_ARCH_SPEAR3XX
commit 77f983a9df42 ("spi: pl022: Use GPIOs looked up by the core")
deleted 'struct pl022_ssp_controller' member 'num_chipselect'.
We get build error when CONFIG_ARCH_SPEAR3XX is set:
arch/arm/mach-spear/spear3xx.c:42:3: error: 'struct pl022_ssp_controller' has
no member named 'num_chipselect'
42 | .num_chipselect = 2,
| ^~
arch/arm/mach-spear/spear3xx.c:42:20: warning: initialization of 'void *' from
'int' makes pointer from integer without a cast [-Wint-conversion]
42 | .num_chipselect = 2,
|^
Fix the issue by deleting the initialization of 'num_chipselect'
in spear3xx.c.
Fixes: 77f983a9df42 ("spi: pl022: Use GPIOs looked up by the core")
Reported-by: Hulk Robot
Signed-off-by: Chen Lifu
---
arch/arm/mach-spear/spear3xx.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/arch/arm/mach-spear/spear3xx.c b/arch/arm/mach-spear/spear3xx.c
index 8537fcffe5a8..f83321d5e353 100644
--- a/arch/arm/mach-spear/spear3xx.c
+++ b/arch/arm/mach-spear/spear3xx.c
@@ -30,16 +30,6 @@ struct pl022_ssp_controller pl022_plat_data = {
.dma_filter = pl08x_filter_id,
.dma_tx_param = "ssp0_tx",
.dma_rx_param = "ssp0_rx",
- /*
-* This is number of spi devices that can be connected to spi. There are
-* two type of chipselects on which slave devices can work. One is chip
-* select provided by spi masters other is controlled through external
-* gpio's. We can't use chipselect provided from spi master (because as
-* soon as FIFO becomes empty, CS is disabled and transfer ends). So
-* this number now depends on number of gpios available for spi. each
-* slave on each master requires a separate gpio pin.
-*/
- .num_chipselect = 2,
};
/* dmac device registration */
Re: [PATCH] tee: optee: fix build error caused by recent optee tracepoints feature
Hi Jens, Am Di., 6. Apr. 2021 um 14:30 Uhr schrieb Jens Wiklander : > > Hi Heiko, > > [+Arnd] > > On Tue, Apr 6, 2021 at 12:38 PM Heiko Thiery wrote: > > > > Hi Jens, > > > > Am Di., 30. März 2021 um 10:26 Uhr schrieb Jens Wiklander > > : > > > > > > On Thu, Mar 25, 2021 at 12:06:01PM +0800, Jisheng Zhang wrote: > > > > If build kernel without "O=dir", below error will be seen: > > > > > > > > In file included from drivers/tee/optee/optee_trace.h:67, > > > > from drivers/tee/optee/call.c:18: > > > > ./include/trace/define_trace.h:95:42: fatal error: ./optee_trace.h: No > > > > such file or directory > > > >95 | #include TRACE_INCLUDE(TRACE_INCLUDE_FILE) > > > > | ^ > > > > compilation terminated. > > > > > > > > Fix it by adding below line to Makefile: > > > > CFLAGS_call.o := -I$(src) > > > > > > > > Tested with and without "O=dir", both can build successfully. > > > > > > > > Reported-by: Guenter Roeck > > > > Suggested-by: Steven Rostedt > > > > Signed-off-by: Jisheng Zhang > > > > > > I've picked up this. > > > > For what tree did you pick this? I still see this build failure on the > > latest next tree (next-20210401). > > The next tree hasn't been updated since 1th of April so it's not > unexpected. The fix is supposed to be on its way to > https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git/log/?h=arm/drivers > , I can't see it there yet though. Ah I see. Now it has been landed in the actual next tree. Thank you, Heiko
Re: [PATCH] tee: optee: fix build error caused by recent optee tracepoints feature
Hi Heiko, [+Arnd] On Tue, Apr 6, 2021 at 12:38 PM Heiko Thiery wrote: > > Hi Jens, > > Am Di., 30. März 2021 um 10:26 Uhr schrieb Jens Wiklander > : > > > > On Thu, Mar 25, 2021 at 12:06:01PM +0800, Jisheng Zhang wrote: > > > If build kernel without "O=dir", below error will be seen: > > > > > > In file included from drivers/tee/optee/optee_trace.h:67, > > > from drivers/tee/optee/call.c:18: > > > ./include/trace/define_trace.h:95:42: fatal error: ./optee_trace.h: No > > > such file or directory > > >95 | #include TRACE_INCLUDE(TRACE_INCLUDE_FILE) > > > | ^ > > > compilation terminated. > > > > > > Fix it by adding below line to Makefile: > > > CFLAGS_call.o := -I$(src) > > > > > > Tested with and without "O=dir", both can build successfully. > > > > > > Reported-by: Guenter Roeck > > > Suggested-by: Steven Rostedt > > > Signed-off-by: Jisheng Zhang > > > > I've picked up this. > > For what tree did you pick this? I still see this build failure on the > latest next tree (next-20210401). The next tree hasn't been updated since 1th of April so it's not unexpected. The fix is supposed to be on its way to https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git/log/?h=arm/drivers , I can't see it there yet though. Cheers, Jens
Re: [PATCH] tee: optee: fix build error caused by recent optee tracepoints feature
Hi Jens, Am Di., 30. März 2021 um 10:26 Uhr schrieb Jens Wiklander : > > On Thu, Mar 25, 2021 at 12:06:01PM +0800, Jisheng Zhang wrote: > > If build kernel without "O=dir", below error will be seen: > > > > In file included from drivers/tee/optee/optee_trace.h:67, > > from drivers/tee/optee/call.c:18: > > ./include/trace/define_trace.h:95:42: fatal error: ./optee_trace.h: No such > > file or directory > >95 | #include TRACE_INCLUDE(TRACE_INCLUDE_FILE) > > | ^ > > compilation terminated. > > > > Fix it by adding below line to Makefile: > > CFLAGS_call.o := -I$(src) > > > > Tested with and without "O=dir", both can build successfully. > > > > Reported-by: Guenter Roeck > > Suggested-by: Steven Rostedt > > Signed-off-by: Jisheng Zhang > > I've picked up this. For what tree did you pick this? I still see this build failure on the latest next tree (next-20210401). > > Thanks, > Jens Thank you, Heiko
Re: [PATCH] tee: optee: fix build error caused by recent optee tracepoints feature
On Thu, Mar 25, 2021 at 12:06:01PM +0800, Jisheng Zhang wrote: > If build kernel without "O=dir", below error will be seen: > > In file included from drivers/tee/optee/optee_trace.h:67, > from drivers/tee/optee/call.c:18: > ./include/trace/define_trace.h:95:42: fatal error: ./optee_trace.h: No such > file or directory >95 | #include TRACE_INCLUDE(TRACE_INCLUDE_FILE) > | ^ > compilation terminated. > > Fix it by adding below line to Makefile: > CFLAGS_call.o := -I$(src) > > Tested with and without "O=dir", both can build successfully. > > Reported-by: Guenter Roeck > Suggested-by: Steven Rostedt > Signed-off-by: Jisheng Zhang I've picked up this. Thanks, Jens
Re: [PATCH] tee: optee: fix build error caused by recent optee tracepoints feature
> If build kernel without "O=dir", below error will be seen:
>
> In file included from drivers/tee/optee/optee_trace.h:67,
> from drivers/tee/optee/call.c:18:
> ./include/trace/define_trace.h:95:42: fatal error: ./optee_trace.h: No such
> file or directory
>95 | #include TRACE_INCLUDE(TRACE_INCLUDE_FILE)
> | ^
> compilation terminated.
>
> Fix it by adding below line to Makefile:
> CFLAGS_call.o := -I$(src)
>
> Tested with and without "O=dir", both can build successfully.
>
> Reported-by: Guenter Roeck
> Suggested-by: Steven Rostedt
> Signed-off-by: Jisheng Zhang
Fixes: 0101947dbcc3 ("tee: optee: add invoke_fn tracepoints")
Tested-by: Heiko Thiery
> ---
> drivers/tee/optee/Makefile | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/tee/optee/Makefile b/drivers/tee/optee/Makefile
> index 56263ae3b1d7..3aa33ea9e6a6 100644
> --- a/drivers/tee/optee/Makefile
> +++ b/drivers/tee/optee/Makefile
> @@ -6,3 +6,6 @@ optee-objs += rpc.o
> optee-objs += supp.o
> optee-objs += shm_pool.o
> optee-objs += device.o
> +
> +# for tracing framework to find optee_trace.h
> +CFLAGS_call.o := -I$(src)
> --
> 2.31.0
>
Thank you.
--
Heiko
[syzbot] linux-next build error (12)
Hello, syzbot found the following issue on: HEAD commit:9d49ed9c Add linux-next specific files for 20210329 git tree: linux-next console output: https://syzkaller.appspot.com/x/log.txt?x=159b39aad0 kernel config: https://syzkaller.appspot.com/x/.config?x=b55345a2d39e7782 dashboard link: https://syzkaller.appspot.com/bug?extid=78983c59ee6ab57e6fcb IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+78983c59ee6ab57e6...@syzkaller.appspotmail.com failed to run ["make" "-j" "64" "ARCH=x86_64" "bzImage"]: exit status 2 --- This report is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this issue. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
Re: [PATCH bpf-next] bpf: tcp: Remove comma which is causing build error
On Sun, Mar 28, 2021 at 5:05 AM Atul Gopinathan
wrote:
>
> Currently, building the bpf-next source with the CONFIG_BPF_SYSCALL
> enabled is causing a compilation error:
>
> "net/ipv4/bpf_tcp_ca.c:209:28: error: expected identifier or '(' before
> ',' token"
>
> Fix this by removing an unnecessary comma.
>
> Reported-by: syzbot+0b74d8ec3bf0cc4e4...@syzkaller.appspotmail.com
> Fixes: e78aea8b2170 ("bpf: tcp: Put some tcp cong functions in allowlist for
> bpf-tcp-cc")
> Signed-off-by: Atul Gopinathan
Thanks for the quick fix. Applied.
[PATCH bpf-next] bpf: tcp: Remove comma which is causing build error
Currently, building the bpf-next source with the CONFIG_BPF_SYSCALL
enabled is causing a compilation error:
"net/ipv4/bpf_tcp_ca.c:209:28: error: expected identifier or '(' before
',' token"
Fix this by removing an unnecessary comma.
Reported-by: syzbot+0b74d8ec3bf0cc4e4...@syzkaller.appspotmail.com
Fixes: e78aea8b2170 ("bpf: tcp: Put some tcp cong functions in allowlist for
bpf-tcp-cc")
Signed-off-by: Atul Gopinathan
---
net/ipv4/bpf_tcp_ca.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv4/bpf_tcp_ca.c b/net/ipv4/bpf_tcp_ca.c
index 40520b77a307..12777d444d0f 100644
--- a/net/ipv4/bpf_tcp_ca.c
+++ b/net/ipv4/bpf_tcp_ca.c
@@ -202,15 +202,15 @@ BTF_ID(func, dctcp_cwnd_undo)
BTF_ID(func, dctcp_state)
#endif
#if IS_BUILTIN(CONFIG_TCP_CONG_BBR)
BTF_ID(func, bbr_init)
BTF_ID(func, bbr_main)
BTF_ID(func, bbr_sndbuf_expand)
BTF_ID(func, bbr_undo_cwnd)
-BTF_ID(func, bbr_cwnd_even),
+BTF_ID(func, bbr_cwnd_even)
BTF_ID(func, bbr_ssthresh)
BTF_ID(func, bbr_min_tso_segs)
BTF_ID(func, bbr_set_state)
#endif
BTF_SET_END(bpf_tcp_ca_kfunc_ids)
static bool bpf_tcp_ca_check_kfunc_call(u32 kfunc_btf_id)
--
2.25.1
[syzbot] bpf-next build error (3)
Hello,
syzbot found the following issue on:
HEAD commit:fddbf4b6 Merge branch 'bpf: Support calling kernel function'
git tree: bpf-next
console output: https://syzkaller.appspot.com/x/log.txt?x=11e7a362d0
kernel config: https://syzkaller.appspot.com/x/.config?x=7eff0f22b8563a5f
dashboard link: https://syzkaller.appspot.com/bug?extid=0b74d8ec3bf0cc4e4209
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+0b74d8ec3bf0cc4e4...@syzkaller.appspotmail.com
net/ipv4/bpf_tcp_ca.c:209:28: error: expected identifier or '(' before ',' token
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkal...@googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
[PATCH 2/2] power: supply: Fix build error when CONFIG_POWER_SUPPLY is not enabled.
The build error happens when CONFIG_POWER_SUPPLY is not enabled.
h8300-linux-ld: drivers/usb/dwc3/gadget.o: in function `.L59':
>> gadget.c:(.text+0x655): undefined reference to `power_supply_set_property'
Fixes: 99288de36020 ("usb: dwc3: add an alternate path in vbus_draw callback")
Reported-by: kernel test robot
Signed-off-by: Ray Chi
---
include/linux/power_supply.h | 7 +++
1 file changed, 7 insertions(+)
diff --git a/include/linux/power_supply.h b/include/linux/power_supply.h
index 81a55e974feb..b495b4374cd0 100644
--- a/include/linux/power_supply.h
+++ b/include/linux/power_supply.h
@@ -426,9 +426,16 @@ static inline int power_supply_is_system_supplied(void) {
return -ENOSYS; }
extern int power_supply_get_property(struct power_supply *psy,
enum power_supply_property psp,
union power_supply_propval *val);
+#if IS_ENABLED(CONFIG_POWER_SUPPLY)
extern int power_supply_set_property(struct power_supply *psy,
enum power_supply_property psp,
const union power_supply_propval *val);
+#else
+static inline int power_supply_set_property(struct power_supply *psy,
+ enum power_supply_property psp,
+ const union power_supply_propval *val)
+{ return 0; }
+#endif
extern int power_supply_property_is_writeable(struct power_supply *psy,
enum power_supply_property psp);
extern void power_supply_external_power_changed(struct power_supply *psy);
--
2.31.0.291.g576ba9dcdaf-goog
Re: [PATCH] tee: optee: fix build error caused by recent optee tracepoints feature
On Thu, Mar 25, 2021 at 12:06:01PM +0800, Jisheng Zhang wrote: > If build kernel without "O=dir", below error will be seen: > > In file included from drivers/tee/optee/optee_trace.h:67, > from drivers/tee/optee/call.c:18: > ./include/trace/define_trace.h:95:42: fatal error: ./optee_trace.h: No such > file or directory >95 | #include TRACE_INCLUDE(TRACE_INCLUDE_FILE) > | ^ > compilation terminated. > > Fix it by adding below line to Makefile: > CFLAGS_call.o := -I$(src) > > Tested with and without "O=dir", both can build successfully. > > Reported-by: Guenter Roeck > Suggested-by: Steven Rostedt > Signed-off-by: Jisheng Zhang Tested-by: Guenter Roeck > --- > drivers/tee/optee/Makefile | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/tee/optee/Makefile b/drivers/tee/optee/Makefile > index 56263ae3b1d7..3aa33ea9e6a6 100644 > --- a/drivers/tee/optee/Makefile > +++ b/drivers/tee/optee/Makefile > @@ -6,3 +6,6 @@ optee-objs += rpc.o > optee-objs += supp.o > optee-objs += shm_pool.o > optee-objs += device.o > + > +# for tracing framework to find optee_trace.h > +CFLAGS_call.o := -I$(src) > -- > 2.31.0 >
[PATCH] tee: optee: fix build error caused by recent optee tracepoints feature
If build kernel without "O=dir", below error will be seen: In file included from drivers/tee/optee/optee_trace.h:67, from drivers/tee/optee/call.c:18: ./include/trace/define_trace.h:95:42: fatal error: ./optee_trace.h: No such file or directory 95 | #include TRACE_INCLUDE(TRACE_INCLUDE_FILE) | ^ compilation terminated. Fix it by adding below line to Makefile: CFLAGS_call.o := -I$(src) Tested with and without "O=dir", both can build successfully. Reported-by: Guenter Roeck Suggested-by: Steven Rostedt Signed-off-by: Jisheng Zhang --- drivers/tee/optee/Makefile | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/tee/optee/Makefile b/drivers/tee/optee/Makefile index 56263ae3b1d7..3aa33ea9e6a6 100644 --- a/drivers/tee/optee/Makefile +++ b/drivers/tee/optee/Makefile @@ -6,3 +6,6 @@ optee-objs += rpc.o optee-objs += supp.o optee-objs += shm_pool.o optee-objs += device.o + +# for tracing framework to find optee_trace.h +CFLAGS_call.o := -I$(src) -- 2.31.0
Re: [PATCH] usb: dwc3: fix build error when POWER_SUPPLY is not enabled
Hi Greg,
I will upload fixes for power supply usage in dwc3 and dt-binding
documentation for the new device tree this week.
Thanks,
Ray
On Tue, Mar 23, 2021 at 9:47 PM Greg KH wrote:
>
> On Fri, Mar 12, 2021 at 09:57:56PM +0800, Ray Chi wrote:
> > Hi Sebastian,
> >
> > Sorry for the late reply.
> >
> > On Wed, Mar 10, 2021 at 2:58 AM Sebastian Reichel wrote:
> > >
> > > Hi,
> > >
> > > On Mon, Mar 08, 2021 at 09:31:46PM +0800, Ray Chi wrote:
> > > > Fix build error when CONFIG_POWER_SUPPLY is not enabled.
> > > >
> > > > The build error occurs in mips (cavium_octeon_defconfig).
> > > >
> > > > mips-linux-gnu-ld: drivers/usb/dwc3/core.o: in function `dwc3_remove':
> > > > drivers/usb/dwc3/core.c:1657: undefined reference to `power_supply_put'
> > > > mips-linux-gnu-ld: drivers/usb/dwc3/core.o: in function
> > > > `dwc3_get_properties':
> > > > drivers/usb/dwc3/core.c:1270: undefined reference to
> > > > `power_supply_get_by_name'
> > > > mips-linux-gnu-ld: drivers/usb/dwc3/core.o: in function `dwc3_probe':
> > > > drivers/usb/dwc3/core.c:1632: undefined reference to `power_supply_put'
> > > >
> > > > Fixes: 59fa3def35de ("usb: dwc3: add a power supply for current
> > > > control")
> > > > Reported-by: Naresh Kamboju
> > > > Signed-off-by: Ray Chi
> > > > ---
> > >
> > > While I'm fine with merging this after fixing up the subject, the
> > > original patch for dwc3 [0] looks completly incorrect to me.
> > >
> > > First of all it uses wrong scale (power-supply uses uA, not mA),
> > > so you are charging 1000x slower than expected. Then the patchset
> > > introduces a new DT property to get the power-supply device, but
> > > does not update the DT binding documentation and does not Cc the
> > > DT binding maintainer.
> >
> > Yes, it should use uA and send this information, and I will update a
> > patch to fix it and add the DT binding documentation.
>
> So should I revert what we currently have in my usb-next tree, or do
> you have a fix for this?
>
> thanks,
>
> greg k-h
Re: [PATCH] usb: dwc3: fix build error when POWER_SUPPLY is not enabled
On Fri, Mar 12, 2021 at 09:57:56PM +0800, Ray Chi wrote:
> Hi Sebastian,
>
> Sorry for the late reply.
>
> On Wed, Mar 10, 2021 at 2:58 AM Sebastian Reichel wrote:
> >
> > Hi,
> >
> > On Mon, Mar 08, 2021 at 09:31:46PM +0800, Ray Chi wrote:
> > > Fix build error when CONFIG_POWER_SUPPLY is not enabled.
> > >
> > > The build error occurs in mips (cavium_octeon_defconfig).
> > >
> > > mips-linux-gnu-ld: drivers/usb/dwc3/core.o: in function `dwc3_remove':
> > > drivers/usb/dwc3/core.c:1657: undefined reference to `power_supply_put'
> > > mips-linux-gnu-ld: drivers/usb/dwc3/core.o: in function
> > > `dwc3_get_properties':
> > > drivers/usb/dwc3/core.c:1270: undefined reference to
> > > `power_supply_get_by_name'
> > > mips-linux-gnu-ld: drivers/usb/dwc3/core.o: in function `dwc3_probe':
> > > drivers/usb/dwc3/core.c:1632: undefined reference to `power_supply_put'
> > >
> > > Fixes: 59fa3def35de ("usb: dwc3: add a power supply for current control")
> > > Reported-by: Naresh Kamboju
> > > Signed-off-by: Ray Chi
> > > ---
> >
> > While I'm fine with merging this after fixing up the subject, the
> > original patch for dwc3 [0] looks completly incorrect to me.
> >
> > First of all it uses wrong scale (power-supply uses uA, not mA),
> > so you are charging 1000x slower than expected. Then the patchset
> > introduces a new DT property to get the power-supply device, but
> > does not update the DT binding documentation and does not Cc the
> > DT binding maintainer.
>
> Yes, it should use uA and send this information, and I will update a
> patch to fix it and add the DT binding documentation.
So should I revert what we currently have in my usb-next tree, or do
you have a fix for this?
thanks,
greg k-h
[PATCH V2 1/6] PM / devfreq: fix build error when DEVFREQ_GOV_PASSIVE enabled
drivers/devfreq/devfreq.c: In function ‘devfreq_transitions_show’:
drivers/devfreq/devfreq.c:2188:25: error: ‘struct devfreq’ has no member named
‘governor_name’; did you mean ‘governor’?
2188 | if (!strncmp(devfreq->governor_name,
| ^
| governor
Fixes: 5cc75e9252e9 ("PM / devfreq: Add devfreq_transitions debugfs file")
Signed-off-by: Dong Aisheng
---
drivers/devfreq/devfreq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
index d625b268adf2..107badfc6b2b 100644
--- a/drivers/devfreq/devfreq.c
+++ b/drivers/devfreq/devfreq.c
@@ -2185,7 +2185,7 @@ static int devfreq_transitions_show(struct seq_file *s,
void *data)
continue;
#if IS_ENABLED(CONFIG_DEVFREQ_GOV_PASSIVE)
- if (!strncmp(devfreq->governor_name,
+ if (!strncmp(devfreq->governor->name,
DEVFREQ_GOV_PASSIVE, DEVFREQ_NAME_LEN)) {
struct devfreq_passive_data *data = devfreq->data;
--
2.25.1
Re: [PATCH] KEYS: trusted: tee: fix build error due to missing include
Hi Jarkko, On 17.03.21 22:57, Jarkko Sakkinen wrote: > On Wed, Mar 17, 2021 at 03:29:05PM +0100, Ahmad Fatoum wrote: >> MODULE_DEVICE_TABLE is defined in , which is not >> included. Add the include to fix the build error its lack caused. >> >> Cc: Sumit Garg >> Signed-off-by: Ahmad Fatoum > > Hi, I appreciate your work, thanks for taking action, but unfortunately > I already incorporated this fix to the original patch. Nothing unfortunate about this! :) Cheers, Ahmad > > /Jarkko > -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
Re: [PATCH] KEYS: trusted: tee: fix build error due to missing include
On Wed, Mar 17, 2021 at 03:29:05PM +0100, Ahmad Fatoum wrote: > MODULE_DEVICE_TABLE is defined in , which is not > included. Add the include to fix the build error its lack caused. > > Cc: Sumit Garg > Signed-off-by: Ahmad Fatoum Hi, I appreciate your work, thanks for taking action, but unfortunately I already incorporated this fix to the original patch. /Jarkko
[PATCH] KEYS: trusted: tee: fix build error due to missing include
MODULE_DEVICE_TABLE is defined in , which is not included. Add the include to fix the build error its lack caused. Cc: Sumit Garg Signed-off-by: Ahmad Fatoum --- security/keys/trusted-keys/trusted_tee.c | 1 + 1 file changed, 1 insertion(+) diff --git a/security/keys/trusted-keys/trusted_tee.c b/security/keys/trusted-keys/trusted_tee.c index 62983d98a252..2ce66c199e1d 100644 --- a/security/keys/trusted-keys/trusted_tee.c +++ b/security/keys/trusted-keys/trusted_tee.c @@ -8,6 +8,7 @@ #include #include +#include #include #include #include -- 2.29.2
[PATCH 5.11 078/306] tools/resolve_btfids: Fix build error with older host toolchains
From: Greg Kroah-Hartman
From: Kun-Chuan Hsieh
commit 41462c6e730ca0e63f5fed5a517052385d980c54 upstream.
Older libelf.h and glibc elf.h might not yet define the ELF compression
types.
Checking and defining SHF_COMPRESSED fix the build error when compiling
with older toolchains. Also, the tool resolve_btfids is compiled with host
toolchain. The host toolchain is more likely to be older than the cross
compile toolchain.
Fixes: 51f6463aacfb ("tools/resolve_btfids: Fix sections with wrong alignment")
Signed-off-by: Kun-Chuan Hsieh
Signed-off-by: Daniel Borkmann
Acked-by: Jiri Olsa
Link: https://lore.kernel.org/bpf/20210224052752.5284-1-jetswa...@gmail.com
Signed-off-by: Greg Kroah-Hartman
---
tools/bpf/resolve_btfids/main.c |5 +
1 file changed, 5 insertions(+)
--- a/tools/bpf/resolve_btfids/main.c
+++ b/tools/bpf/resolve_btfids/main.c
@@ -260,6 +260,11 @@ static struct btf_id *add_symbol(struct
return btf_id__add(root, id, false);
}
+/* Older libelf.h and glibc elf.h might not yet define the ELF compression
types. */
+#ifndef SHF_COMPRESSED
+#define SHF_COMPRESSED (1 << 11) /* Section with compressed data. */
+#endif
+
/*
* The data of compressed section should be aligned to 4
* (for 32bit) or 8 (for 64 bit) bytes. The binutils ld
[PATCH 5.10 064/290] tools/resolve_btfids: Fix build error with older host toolchains
From: Greg Kroah-Hartman
From: Kun-Chuan Hsieh
commit 41462c6e730ca0e63f5fed5a517052385d980c54 upstream.
Older libelf.h and glibc elf.h might not yet define the ELF compression
types.
Checking and defining SHF_COMPRESSED fix the build error when compiling
with older toolchains. Also, the tool resolve_btfids is compiled with host
toolchain. The host toolchain is more likely to be older than the cross
compile toolchain.
Fixes: 51f6463aacfb ("tools/resolve_btfids: Fix sections with wrong alignment")
Signed-off-by: Kun-Chuan Hsieh
Signed-off-by: Daniel Borkmann
Acked-by: Jiri Olsa
Link: https://lore.kernel.org/bpf/20210224052752.5284-1-jetswa...@gmail.com
Signed-off-by: Greg Kroah-Hartman
---
tools/bpf/resolve_btfids/main.c |5 +
1 file changed, 5 insertions(+)
--- a/tools/bpf/resolve_btfids/main.c
+++ b/tools/bpf/resolve_btfids/main.c
@@ -258,6 +258,11 @@ static struct btf_id *add_symbol(struct
return btf_id__add(root, id, false);
}
+/* Older libelf.h and glibc elf.h might not yet define the ELF compression
types. */
+#ifndef SHF_COMPRESSED
+#define SHF_COMPRESSED (1 << 11) /* Section with compressed data. */
+#endif
+
/*
* The data of compressed section should be aligned to 4
* (for 32bit) or 8 (for 64 bit) bytes. The binutils ld
Re: [PATCH] usb: dwc3: fix build error when POWER_SUPPLY is not enabled
Hi, On Mon, Mar 15, 2021 at 6:35 AM Sebastian Reichel wrote: > > Hi, > > On Fri, Mar 12, 2021 at 09:57:56PM +0800, Ray Chi wrote: > > > While I'm fine with merging this after fixing up the subject, the > > > original patch for dwc3 [0] looks completly incorrect to me. > > > > > > First of all it uses wrong scale (power-supply uses uA, not mA), > > > so you are charging 1000x slower than expected. Then the patchset > > > introduces a new DT property to get the power-supply device, but > > > does not update the DT binding documentation and does not Cc the > > > DT binding maintainer. > > > > Yes, it should use uA and send this information, and I will update a > > patch to fix it and add the DT binding documentation. > > Considering your programming is off by a factor 1000 I wonder how > this patchset has been tested. Since our corresponding charging driver also uses mA as the unit, I don't find this problem. > > > > Next the property itself looks not very > > > smart to me. Usually one would use a device reference, not the > > > Linux device name. > > > > > > Finally all existing devices solve this by registering a usb > > > notifier from the charger, so why are you going the other way > > > around? This is going to break once you want to use one of the > > > existing chargers with dwc3. > > > > Only the USB controller will know USB state/speed so that I think > > it is better to send this information from the USB side. For > > example: For USB high speed, charging current should be limited to > > 500 mA in configured state. For USB super speed, charging current > > should be limited to 900 mA in configured state. > > usb_register_notifier registers a callback to receive information > from the USB subsystem. Then power-supply drivers can query specific > info, e.g. call usb_phy_get_charger_current(). This is already being > done by some power-supply drivers, so using one of those > power-supply charger drivers in combination with dwc3 will now result > in potentially racy behaviour as far as I can see. Since these functions are defined in driver/usb/phy/phy.c, only the devices which support usb_phy can use them. If the device supports generic PHY drivers, it needs an additional way to provide the information. BTW, when there are two or more ways to provide the information, I think it is fine to return the result directly if one of the ways is executed successfully. > > > > I suggest to drop/revert the whole patchset. > > -- Sebastian
Re: [PATCH] usb: dwc3: fix build error when POWER_SUPPLY is not enabled
Hi, On Fri, Mar 12, 2021 at 09:57:56PM +0800, Ray Chi wrote: > > While I'm fine with merging this after fixing up the subject, the > > original patch for dwc3 [0] looks completly incorrect to me. > > > > First of all it uses wrong scale (power-supply uses uA, not mA), > > so you are charging 1000x slower than expected. Then the patchset > > introduces a new DT property to get the power-supply device, but > > does not update the DT binding documentation and does not Cc the > > DT binding maintainer. > > Yes, it should use uA and send this information, and I will update a > patch to fix it and add the DT binding documentation. Considering your programming is off by a factor 1000 I wonder how this patchset has been tested. > > Next the property itself looks not very > > smart to me. Usually one would use a device reference, not the > > Linux device name. > > > > Finally all existing devices solve this by registering a usb > > notifier from the charger, so why are you going the other way > > around? This is going to break once you want to use one of the > > existing chargers with dwc3. > > Only the USB controller will know USB state/speed so that I think > it is better to send this information from the USB side. For > example: For USB high speed, charging current should be limited to > 500 mA in configured state. For USB super speed, charging current > should be limited to 900 mA in configured state. usb_register_notifier registers a callback to receive information from the USB subsystem. Then power-supply drivers can query specific info, e.g. call usb_phy_get_charger_current(). This is already being done by some power-supply drivers, so using one of those power-supply charger drivers in combination with dwc3 will now result in potentially racy behaviour as far as I can see. > > I suggest to drop/revert the whole patchset. -- Sebastian signature.asc Description: PGP signature
Re: [PATCH] usb: dwc3: fix build error when POWER_SUPPLY is not enabled
Hi Sebastian,
Sorry for the late reply.
On Wed, Mar 10, 2021 at 2:58 AM Sebastian Reichel wrote:
>
> Hi,
>
> On Mon, Mar 08, 2021 at 09:31:46PM +0800, Ray Chi wrote:
> > Fix build error when CONFIG_POWER_SUPPLY is not enabled.
> >
> > The build error occurs in mips (cavium_octeon_defconfig).
> >
> > mips-linux-gnu-ld: drivers/usb/dwc3/core.o: in function `dwc3_remove':
> > drivers/usb/dwc3/core.c:1657: undefined reference to `power_supply_put'
> > mips-linux-gnu-ld: drivers/usb/dwc3/core.o: in function
> > `dwc3_get_properties':
> > drivers/usb/dwc3/core.c:1270: undefined reference to
> > `power_supply_get_by_name'
> > mips-linux-gnu-ld: drivers/usb/dwc3/core.o: in function `dwc3_probe':
> > drivers/usb/dwc3/core.c:1632: undefined reference to `power_supply_put'
> >
> > Fixes: 59fa3def35de ("usb: dwc3: add a power supply for current control")
> > Reported-by: Naresh Kamboju
> > Signed-off-by: Ray Chi
> > ---
>
> While I'm fine with merging this after fixing up the subject, the
> original patch for dwc3 [0] looks completly incorrect to me.
>
> First of all it uses wrong scale (power-supply uses uA, not mA),
> so you are charging 1000x slower than expected. Then the patchset
> introduces a new DT property to get the power-supply device, but
> does not update the DT binding documentation and does not Cc the
> DT binding maintainer.
Yes, it should use uA and send this information, and I will update a
patch to fix it and add the DT binding documentation.
> Next the property itself looks not very
> smart to me. Usually one would use a device reference, not the
> Linux device name.
>
> Finally all existing devices solve this by registering a usb
> notifier from the charger, so why are you going the other way
> around? This is going to break once you want to use one of the
> existing chargers with dwc3.
Only the USB controller will know USB state/speed so that I think it is
better to send this information from the USB side.
For example:
For USB high speed, charging current should be limited to 500 mA in
configured state.
For USB super speed, charging current should be limited to 900 mA in
configured state.
>
> I suggest to drop/revert the whole patchset.
>
> [0]
> https://lore.kernel.org/linux-usb/20210222115149.3606776-1-ray...@google.com/
>
> -- Sebastian
>
> > include/linux/power_supply.h | 6 ++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/include/linux/power_supply.h b/include/linux/power_supply.h
> > index 81a55e974feb..6e776be5bfa0 100644
> > --- a/include/linux/power_supply.h
> > +++ b/include/linux/power_supply.h
> > @@ -381,8 +381,14 @@ struct power_supply_battery_info {
> > extern struct atomic_notifier_head power_supply_notifier;
> > extern int power_supply_reg_notifier(struct notifier_block *nb);
> > extern void power_supply_unreg_notifier(struct notifier_block *nb);
> > +#if IS_ENABLED(CONFIG_POWER_SUPPLY)
> > extern struct power_supply *power_supply_get_by_name(const char *name);
> > extern void power_supply_put(struct power_supply *psy);
> > +#else
> > +static inline void power_supply_put(struct power_supply *psy) {}
> > +static inline struct power_supply *power_supply_get_by_name(const char
> > *name)
> > +{ return NULL; }
> > +#endif
> > #ifdef CONFIG_OF
> > extern struct power_supply *power_supply_get_by_phandle(struct device_node
> > *np,
> > const char *property);
> > --
> > 2.30.1.766.gb4fecdf3b7-goog
> >
Re: [PATCH 1/1] drm/amdkfd: fix build error with AMD_IOMMU_V2=m
On Tue, Mar 9, 2021 at 7:34 PM Christian König wrote: > Am 09.03.21 um 18:59 schrieb Alex Deucher: > > There has been quite some effort for this already for generic PASID > interface etc.. But it looks like that effort is stalled by now. > > Anyway at least I'm perfectly fine to have the IOMMUv2 || !IOMMUv2 > dependency on the core amdgpu driver for x86. > > That should solve the build problem at hand quite nicely. Right, that sounds better than the IS_REACHABLE() hack, and would fix the immediate build regression until the driver is changed to use the proper IOMMU interfaces. Arnd
Re: [PATCH v2 1/1] drm/amdkfd: fix build error with AMD_IOMMU_V2=m
Am 10.03.21 um 23:13 schrieb Felix Kuehling:
On 2021-03-09 11:50 a.m., Felix Kuehling wrote:
Using 'imply AMD_IOMMU_V2' does not guarantee that the driver can link
against the exported functions. If the GPU driver is built-in but the
IOMMU driver is a loadable module, the kfd_iommu.c file is indeed
built but does not work:
x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function
`kfd_iommu_bind_process_to_device':
kfd_iommu.c:(.text+0x516): undefined reference to `amd_iommu_bind_pasid'
x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function
`kfd_iommu_unbind_process':
kfd_iommu.c:(.text+0x691): undefined reference to
`amd_iommu_unbind_pasid'
x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function
`kfd_iommu_suspend':
kfd_iommu.c:(.text+0x966): undefined reference to
`amd_iommu_set_invalidate_ctx_cb'
x86_64-linux-ld: kfd_iommu.c:(.text+0x97f): undefined reference to
`amd_iommu_set_invalid_ppr_cb'
x86_64-linux-ld: kfd_iommu.c:(.text+0x9a4): undefined reference to
`amd_iommu_free_device'
x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function
`kfd_iommu_resume':
kfd_iommu.c:(.text+0xa9a): undefined reference to
`amd_iommu_init_device'
x86_64-linux-ld: kfd_iommu.c:(.text+0xadc): undefined reference to
`amd_iommu_set_invalidate_ctx_cb'
x86_64-linux-ld: kfd_iommu.c:(.text+0xaff): undefined reference to
`amd_iommu_set_invalid_ppr_cb'
x86_64-linux-ld: kfd_iommu.c:(.text+0xc72): undefined reference to
`amd_iommu_bind_pasid'
x86_64-linux-ld: kfd_iommu.c:(.text+0xe08): undefined reference to
`amd_iommu_set_invalidate_ctx_cb'
x86_64-linux-ld: kfd_iommu.c:(.text+0xe26): undefined reference to
`amd_iommu_set_invalid_ppr_cb'
x86_64-linux-ld: kfd_iommu.c:(.text+0xe42): undefined reference to
`amd_iommu_free_device'
Use IS_REACHABLE to only build IOMMU-V2 support if the amd_iommu symbols
are reachable by the amdkfd driver. Output a warning if they are not,
because that may not be what the user was expecting.
Fixes: 64d1c3a43a6f ("drm/amdkfd: Centralize IOMMUv2 code and make it
conditional")
Reported-by: Arnd Bergmann
Signed-off-by: Felix Kuehling
Ping. Can I get an R-b for this patch.
Reviewed-by: Christian König
Thanks,
Felix
---
drivers/gpu/drm/amd/amdkfd/kfd_iommu.c | 6 ++
drivers/gpu/drm/amd/amdkfd/kfd_iommu.h | 9 +++--
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_iommu.c
b/drivers/gpu/drm/amd/amdkfd/kfd_iommu.c
index 66bbca61e3ef..9318936aa805 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_iommu.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_iommu.c
@@ -20,6 +20,10 @@
* OTHER DEALINGS IN THE SOFTWARE.
*/
+#include
+
+#if IS_REACHABLE(CONFIG_AMD_IOMMU_V2)
+
#include
#include
#include
@@ -355,3 +359,5 @@ int kfd_iommu_add_perf_counters(struct
kfd_topology_device *kdev)
return 0;
}
+
+#endif
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_iommu.h
b/drivers/gpu/drm/amd/amdkfd/kfd_iommu.h
index dd23d9fdf6a8..afd420b01a0c 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_iommu.h
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_iommu.h
@@ -23,7 +23,9 @@
#ifndef __KFD_IOMMU_H__
#define __KFD_IOMMU_H__
-#if defined(CONFIG_AMD_IOMMU_V2_MODULE) ||
defined(CONFIG_AMD_IOMMU_V2)
+#include
+
+#if IS_REACHABLE(CONFIG_AMD_IOMMU_V2)
#define KFD_SUPPORT_IOMMU_V2
@@ -46,6 +48,9 @@ static inline int kfd_iommu_check_device(struct
kfd_dev *kfd)
}
static inline int kfd_iommu_device_init(struct kfd_dev *kfd)
{
+#if IS_MODULE(CONFIG_AMD_IOMMU_V2)
+ WARN_ONCE(1, "iommu_v2 module is not usable by built-in KFD");
+#endif
return 0;
}
@@ -73,6 +78,6 @@ static inline int
kfd_iommu_add_perf_counters(struct kfd_topology_device *kdev)
return 0;
}
-#endif /* defined(CONFIG_AMD_IOMMU_V2) */
+#endif /* IS_REACHABLE(CONFIG_AMD_IOMMU_V2) */
#endif /* __KFD_IOMMU_H__ */
Re: [PATCH v2 1/1] drm/amdkfd: fix build error with AMD_IOMMU_V2=m
On 2021-03-09 11:50 a.m., Felix Kuehling wrote:
Using 'imply AMD_IOMMU_V2' does not guarantee that the driver can link
against the exported functions. If the GPU driver is built-in but the
IOMMU driver is a loadable module, the kfd_iommu.c file is indeed
built but does not work:
x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function
`kfd_iommu_bind_process_to_device':
kfd_iommu.c:(.text+0x516): undefined reference to `amd_iommu_bind_pasid'
x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function
`kfd_iommu_unbind_process':
kfd_iommu.c:(.text+0x691): undefined reference to `amd_iommu_unbind_pasid'
x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function
`kfd_iommu_suspend':
kfd_iommu.c:(.text+0x966): undefined reference to
`amd_iommu_set_invalidate_ctx_cb'
x86_64-linux-ld: kfd_iommu.c:(.text+0x97f): undefined reference to
`amd_iommu_set_invalid_ppr_cb'
x86_64-linux-ld: kfd_iommu.c:(.text+0x9a4): undefined reference to
`amd_iommu_free_device'
x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function
`kfd_iommu_resume':
kfd_iommu.c:(.text+0xa9a): undefined reference to `amd_iommu_init_device'
x86_64-linux-ld: kfd_iommu.c:(.text+0xadc): undefined reference to
`amd_iommu_set_invalidate_ctx_cb'
x86_64-linux-ld: kfd_iommu.c:(.text+0xaff): undefined reference to
`amd_iommu_set_invalid_ppr_cb'
x86_64-linux-ld: kfd_iommu.c:(.text+0xc72): undefined reference to
`amd_iommu_bind_pasid'
x86_64-linux-ld: kfd_iommu.c:(.text+0xe08): undefined reference to
`amd_iommu_set_invalidate_ctx_cb'
x86_64-linux-ld: kfd_iommu.c:(.text+0xe26): undefined reference to
`amd_iommu_set_invalid_ppr_cb'
x86_64-linux-ld: kfd_iommu.c:(.text+0xe42): undefined reference to
`amd_iommu_free_device'
Use IS_REACHABLE to only build IOMMU-V2 support if the amd_iommu symbols
are reachable by the amdkfd driver. Output a warning if they are not,
because that may not be what the user was expecting.
Fixes: 64d1c3a43a6f ("drm/amdkfd: Centralize IOMMUv2 code and make it
conditional")
Reported-by: Arnd Bergmann
Signed-off-by: Felix Kuehling
Ping. Can I get an R-b for this patch.
Thanks,
Felix
---
drivers/gpu/drm/amd/amdkfd/kfd_iommu.c | 6 ++
drivers/gpu/drm/amd/amdkfd/kfd_iommu.h | 9 +++--
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_iommu.c
b/drivers/gpu/drm/amd/amdkfd/kfd_iommu.c
index 66bbca61e3ef..9318936aa805 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_iommu.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_iommu.c
@@ -20,6 +20,10 @@
* OTHER DEALINGS IN THE SOFTWARE.
*/
+#include
+
+#if IS_REACHABLE(CONFIG_AMD_IOMMU_V2)
+
#include
#include
#include
@@ -355,3 +359,5 @@ int kfd_iommu_add_perf_counters(struct kfd_topology_device
*kdev)
return 0;
}
+
+#endif
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_iommu.h
b/drivers/gpu/drm/amd/amdkfd/kfd_iommu.h
index dd23d9fdf6a8..afd420b01a0c 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_iommu.h
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_iommu.h
@@ -23,7 +23,9 @@
#ifndef __KFD_IOMMU_H__
#define __KFD_IOMMU_H__
-#if defined(CONFIG_AMD_IOMMU_V2_MODULE) || defined(CONFIG_AMD_IOMMU_V2)
+#include
+
+#if IS_REACHABLE(CONFIG_AMD_IOMMU_V2)
#define KFD_SUPPORT_IOMMU_V2
@@ -46,6 +48,9 @@ static inline int kfd_iommu_check_device(struct kfd_dev *kfd)
}
static inline int kfd_iommu_device_init(struct kfd_dev *kfd)
{
+#if IS_MODULE(CONFIG_AMD_IOMMU_V2)
+ WARN_ONCE(1, "iommu_v2 module is not usable by built-in KFD");
+#endif
return 0;
}
@@ -73,6 +78,6 @@ static inline int kfd_iommu_add_perf_counters(struct kfd_topology_device *kdev)
return 0;
}
-#endif /* defined(CONFIG_AMD_IOMMU_V2) */
+#endif /* IS_REACHABLE(CONFIG_AMD_IOMMU_V2) */
#endif /* __KFD_IOMMU_H__ */
[PATCH 4.9 03/11] usbip: tools: fix build error for multiple definition
From: Greg Kroah-Hartman
From: Antonio Borneo
commit d5efc2e6b98fe661dbd8dd0d5d5bfb961728e57a upstream.
With GCC 10, building usbip triggers error for multiple definition
of 'udev_context', in:
- libsrc/vhci_driver.c:18 and
- libsrc/usbip_host_common.c:27.
Declare as extern the definition in libsrc/usbip_host_common.c.
Signed-off-by: Antonio Borneo
Acked-by: Shuah Khan
Link:
https://lore.kernel.org/r/20200618000844.1048309-1-borneo.anto...@gmail.com
Cc: Petr Štetiar
Signed-off-by: Greg Kroah-Hartman
---
tools/usb/usbip/libsrc/usbip_host_common.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/tools/usb/usbip/libsrc/usbip_host_common.c
+++ b/tools/usb/usbip/libsrc/usbip_host_common.c
@@ -35,7 +35,7 @@
#include "list.h"
#include "sysfs_utils.h"
-struct udev *udev_context;
+extern struct udev *udev_context;
static int32_t read_attr_usbip_status(struct usbip_usb_device *udev)
{
[PATCH 4.14 04/20] usbip: tools: fix build error for multiple definition
From: Greg Kroah-Hartman
From: Antonio Borneo
commit d5efc2e6b98fe661dbd8dd0d5d5bfb961728e57a upstream.
With GCC 10, building usbip triggers error for multiple definition
of 'udev_context', in:
- libsrc/vhci_driver.c:18 and
- libsrc/usbip_host_common.c:27.
Declare as extern the definition in libsrc/usbip_host_common.c.
Signed-off-by: Antonio Borneo
Acked-by: Shuah Khan
Link:
https://lore.kernel.org/r/20200618000844.1048309-1-borneo.anto...@gmail.com
Cc: Petr Štetiar
Signed-off-by: Greg Kroah-Hartman
---
tools/usb/usbip/libsrc/usbip_host_common.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/tools/usb/usbip/libsrc/usbip_host_common.c
+++ b/tools/usb/usbip/libsrc/usbip_host_common.c
@@ -35,7 +35,7 @@
#include "list.h"
#include "sysfs_utils.h"
-struct udev *udev_context;
+extern struct udev *udev_context;
static int32_t read_attr_usbip_status(struct usbip_usb_device *udev)
{
[PATCH 4.19 09/39] usbip: tools: fix build error for multiple definition
From: Greg Kroah-Hartman
From: Antonio Borneo
commit d5efc2e6b98fe661dbd8dd0d5d5bfb961728e57a upstream.
With GCC 10, building usbip triggers error for multiple definition
of 'udev_context', in:
- libsrc/vhci_driver.c:18 and
- libsrc/usbip_host_common.c:27.
Declare as extern the definition in libsrc/usbip_host_common.c.
Signed-off-by: Antonio Borneo
Acked-by: Shuah Khan
Link:
https://lore.kernel.org/r/20200618000844.1048309-1-borneo.anto...@gmail.com
Cc: Petr Štetiar
Signed-off-by: Greg Kroah-Hartman
---
tools/usb/usbip/libsrc/usbip_host_common.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/tools/usb/usbip/libsrc/usbip_host_common.c
+++ b/tools/usb/usbip/libsrc/usbip_host_common.c
@@ -35,7 +35,7 @@
#include "list.h"
#include "sysfs_utils.h"
-struct udev *udev_context;
+extern struct udev *udev_context;
static int32_t read_attr_usbip_status(struct usbip_usb_device *udev)
{
Re: [PATCH] usb: dwc3: fix build error when POWER_SUPPLY is not enabled
Hi,
On Mon, Mar 08, 2021 at 09:31:46PM +0800, Ray Chi wrote:
> Fix build error when CONFIG_POWER_SUPPLY is not enabled.
>
> The build error occurs in mips (cavium_octeon_defconfig).
>
> mips-linux-gnu-ld: drivers/usb/dwc3/core.o: in function `dwc3_remove':
> drivers/usb/dwc3/core.c:1657: undefined reference to `power_supply_put'
> mips-linux-gnu-ld: drivers/usb/dwc3/core.o: in function `dwc3_get_properties':
> drivers/usb/dwc3/core.c:1270: undefined reference to
> `power_supply_get_by_name'
> mips-linux-gnu-ld: drivers/usb/dwc3/core.o: in function `dwc3_probe':
> drivers/usb/dwc3/core.c:1632: undefined reference to `power_supply_put'
>
> Fixes: 59fa3def35de ("usb: dwc3: add a power supply for current control")
> Reported-by: Naresh Kamboju
> Signed-off-by: Ray Chi
> ---
While I'm fine with merging this after fixing up the subject, the
original patch for dwc3 [0] looks completly incorrect to me.
First of all it uses wrong scale (power-supply uses uA, not mA),
so you are charging 1000x slower than expected. Then the patchset
introduces a new DT property to get the power-supply device, but
does not update the DT binding documentation and does not Cc the
DT binding maintainer. Next the property itself looks not very
smart to me. Usually one would use a device reference, not the
Linux device name.
Finally all existing devices solve this by registering a usb
notifier from the charger, so why are you going the other way
around? This is going to break once you want to use one of the
existing chargers with dwc3.
I suggest to drop/revert the whole patchset.
[0]
https://lore.kernel.org/linux-usb/20210222115149.3606776-1-ray...@google.com/
-- Sebastian
> include/linux/power_supply.h | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/include/linux/power_supply.h b/include/linux/power_supply.h
> index 81a55e974feb..6e776be5bfa0 100644
> --- a/include/linux/power_supply.h
> +++ b/include/linux/power_supply.h
> @@ -381,8 +381,14 @@ struct power_supply_battery_info {
> extern struct atomic_notifier_head power_supply_notifier;
> extern int power_supply_reg_notifier(struct notifier_block *nb);
> extern void power_supply_unreg_notifier(struct notifier_block *nb);
> +#if IS_ENABLED(CONFIG_POWER_SUPPLY)
> extern struct power_supply *power_supply_get_by_name(const char *name);
> extern void power_supply_put(struct power_supply *psy);
> +#else
> +static inline void power_supply_put(struct power_supply *psy) {}
> +static inline struct power_supply *power_supply_get_by_name(const char *name)
> +{ return NULL; }
> +#endif
> #ifdef CONFIG_OF
> extern struct power_supply *power_supply_get_by_phandle(struct device_node
> *np,
> const char *property);
> --
> 2.30.1.766.gb4fecdf3b7-goog
>
signature.asc
Description: PGP signature
Re: [PATCH 1/1] drm/amdkfd: fix build error with AMD_IOMMU_V2=m
Am 09.03.21 um 18:59 schrieb Alex Deucher: On Tue, Mar 9, 2021 at 12:55 PM Jean-Philippe Brucker wrote: Hi Felix, On Tue, Mar 09, 2021 at 11:30:19AM -0500, Felix Kuehling wrote: I think the proper fix would be to not rely on custom hooks into a particular IOMMU driver, but to instead ensure that the amdgpu driver can do everything it needs through the regular linux/iommu.h interfaces. I realize this is more work, but I wonder if you've tried that, and why it didn't work out. As far as I know this hasn't been tried. I see that intel-iommu has its own SVM thing, which seems to be similar to what our IOMMUv2 does. I guess we'd have to abstract that into a common API. The common API was added in 26b25a2b98e4 and implemented by the Intel driver in 064a57d7ddfc. To support it an IOMMU driver implements new IOMMU ops: .dev_has_feat() .dev_feat_enabled() .dev_enable_feat() .dev_disable_feat() .sva_bind() .sva_unbind() .sva_get_pasid() And a device driver calls iommu_dev_enable_feature(IOMMU_DEV_FEAT_SVA) followed by iommu_sva_bind_device(). If I remember correctly the biggest obstacle for KFD is the PASID allocation, done by the GPU driver instead of the IOMMU driver, but there may be others. IIRC, we tried to make the original IOMMUv2 functionality generic but other vendors were not interested at the time, so it ended up being AMD specific and since nothing else was using the pasid allocations we put them in the GPU driver. I guess if this is generic now, it could be moved to a common API and taken out of the driver. There has been quite some effort for this already for generic PASID interface etc.. But it looks like that effort is stalled by now. Anyway at least I'm perfectly fine to have the IOMMUv2 || !IOMMUv2 dependency on the core amdgpu driver for x86. That should solve the build problem at hand quite nicely. Regards, Christian. Alex
Re: [PATCH 1/1] drm/amdkfd: fix build error with AMD_IOMMU_V2=m
On Tue, Mar 9, 2021 at 12:55 PM Jean-Philippe Brucker wrote: > > Hi Felix, > > On Tue, Mar 09, 2021 at 11:30:19AM -0500, Felix Kuehling wrote: > > > I think the proper fix would be to not rely on custom hooks into a > > > particular > > > IOMMU driver, but to instead ensure that the amdgpu driver can do > > > everything > > > it needs through the regular linux/iommu.h interfaces. I realize this > > > is more work, > > > but I wonder if you've tried that, and why it didn't work out. > > > > As far as I know this hasn't been tried. I see that intel-iommu has its > > own SVM thing, which seems to be similar to what our IOMMUv2 does. I > > guess we'd have to abstract that into a common API. > > The common API was added in 26b25a2b98e4 and implemented by the Intel > driver in 064a57d7ddfc. To support it an IOMMU driver implements new IOMMU > ops: > .dev_has_feat() > .dev_feat_enabled() > .dev_enable_feat() > .dev_disable_feat() > .sva_bind() > .sva_unbind() > .sva_get_pasid() > > And a device driver calls iommu_dev_enable_feature(IOMMU_DEV_FEAT_SVA) > followed by iommu_sva_bind_device(). > > If I remember correctly the biggest obstacle for KFD is the PASID > allocation, done by the GPU driver instead of the IOMMU driver, but there > may be others. IIRC, we tried to make the original IOMMUv2 functionality generic but other vendors were not interested at the time, so it ended up being AMD specific and since nothing else was using the pasid allocations we put them in the GPU driver. I guess if this is generic now, it could be moved to a common API and taken out of the driver. Alex
Re: [PATCH 1/1] drm/amdkfd: fix build error with AMD_IOMMU_V2=m
Hi Felix, On Tue, Mar 09, 2021 at 11:30:19AM -0500, Felix Kuehling wrote: > > I think the proper fix would be to not rely on custom hooks into a > > particular > > IOMMU driver, but to instead ensure that the amdgpu driver can do everything > > it needs through the regular linux/iommu.h interfaces. I realize this > > is more work, > > but I wonder if you've tried that, and why it didn't work out. > > As far as I know this hasn't been tried. I see that intel-iommu has its > own SVM thing, which seems to be similar to what our IOMMUv2 does. I > guess we'd have to abstract that into a common API. The common API was added in 26b25a2b98e4 and implemented by the Intel driver in 064a57d7ddfc. To support it an IOMMU driver implements new IOMMU ops: .dev_has_feat() .dev_feat_enabled() .dev_enable_feat() .dev_disable_feat() .sva_bind() .sva_unbind() .sva_get_pasid() And a device driver calls iommu_dev_enable_feature(IOMMU_DEV_FEAT_SVA) followed by iommu_sva_bind_device(). If I remember correctly the biggest obstacle for KFD is the PASID allocation, done by the GPU driver instead of the IOMMU driver, but there may be others. Thanks, Jean
[PATCH v2 1/1] drm/amdkfd: fix build error with AMD_IOMMU_V2=m
Using 'imply AMD_IOMMU_V2' does not guarantee that the driver can link
against the exported functions. If the GPU driver is built-in but the
IOMMU driver is a loadable module, the kfd_iommu.c file is indeed
built but does not work:
x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function
`kfd_iommu_bind_process_to_device':
kfd_iommu.c:(.text+0x516): undefined reference to `amd_iommu_bind_pasid'
x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function
`kfd_iommu_unbind_process':
kfd_iommu.c:(.text+0x691): undefined reference to `amd_iommu_unbind_pasid'
x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function
`kfd_iommu_suspend':
kfd_iommu.c:(.text+0x966): undefined reference to
`amd_iommu_set_invalidate_ctx_cb'
x86_64-linux-ld: kfd_iommu.c:(.text+0x97f): undefined reference to
`amd_iommu_set_invalid_ppr_cb'
x86_64-linux-ld: kfd_iommu.c:(.text+0x9a4): undefined reference to
`amd_iommu_free_device'
x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function
`kfd_iommu_resume':
kfd_iommu.c:(.text+0xa9a): undefined reference to `amd_iommu_init_device'
x86_64-linux-ld: kfd_iommu.c:(.text+0xadc): undefined reference to
`amd_iommu_set_invalidate_ctx_cb'
x86_64-linux-ld: kfd_iommu.c:(.text+0xaff): undefined reference to
`amd_iommu_set_invalid_ppr_cb'
x86_64-linux-ld: kfd_iommu.c:(.text+0xc72): undefined reference to
`amd_iommu_bind_pasid'
x86_64-linux-ld: kfd_iommu.c:(.text+0xe08): undefined reference to
`amd_iommu_set_invalidate_ctx_cb'
x86_64-linux-ld: kfd_iommu.c:(.text+0xe26): undefined reference to
`amd_iommu_set_invalid_ppr_cb'
x86_64-linux-ld: kfd_iommu.c:(.text+0xe42): undefined reference to
`amd_iommu_free_device'
Use IS_REACHABLE to only build IOMMU-V2 support if the amd_iommu symbols
are reachable by the amdkfd driver. Output a warning if they are not,
because that may not be what the user was expecting.
Fixes: 64d1c3a43a6f ("drm/amdkfd: Centralize IOMMUv2 code and make it
conditional")
Reported-by: Arnd Bergmann
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdkfd/kfd_iommu.c | 6 ++
drivers/gpu/drm/amd/amdkfd/kfd_iommu.h | 9 +++--
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_iommu.c
b/drivers/gpu/drm/amd/amdkfd/kfd_iommu.c
index 66bbca61e3ef..9318936aa805 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_iommu.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_iommu.c
@@ -20,6 +20,10 @@
* OTHER DEALINGS IN THE SOFTWARE.
*/
+#include
+
+#if IS_REACHABLE(CONFIG_AMD_IOMMU_V2)
+
#include
#include
#include
@@ -355,3 +359,5 @@ int kfd_iommu_add_perf_counters(struct kfd_topology_device
*kdev)
return 0;
}
+
+#endif
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_iommu.h
b/drivers/gpu/drm/amd/amdkfd/kfd_iommu.h
index dd23d9fdf6a8..afd420b01a0c 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_iommu.h
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_iommu.h
@@ -23,7 +23,9 @@
#ifndef __KFD_IOMMU_H__
#define __KFD_IOMMU_H__
-#if defined(CONFIG_AMD_IOMMU_V2_MODULE) || defined(CONFIG_AMD_IOMMU_V2)
+#include
+
+#if IS_REACHABLE(CONFIG_AMD_IOMMU_V2)
#define KFD_SUPPORT_IOMMU_V2
@@ -46,6 +48,9 @@ static inline int kfd_iommu_check_device(struct kfd_dev *kfd)
}
static inline int kfd_iommu_device_init(struct kfd_dev *kfd)
{
+#if IS_MODULE(CONFIG_AMD_IOMMU_V2)
+ WARN_ONCE(1, "iommu_v2 module is not usable by built-in KFD");
+#endif
return 0;
}
@@ -73,6 +78,6 @@ static inline int kfd_iommu_add_perf_counters(struct
kfd_topology_device *kdev)
return 0;
}
-#endif /* defined(CONFIG_AMD_IOMMU_V2) */
+#endif /* IS_REACHABLE(CONFIG_AMD_IOMMU_V2) */
#endif /* __KFD_IOMMU_H__ */
--
2.30.0
Re: [PATCH 1/1] drm/amdkfd: fix build error with AMD_IOMMU_V2=m
Am 2021-03-09 um 3:58 a.m. schrieb Arnd Bergmann: > On Tue, Mar 9, 2021 at 4:23 AM Felix Kuehling wrote: >> Using 'imply AMD_IOMMU_V2' does not guarantee that the driver can link >> against the exported functions. If the GPU driver is built-in but the >> IOMMU driver is a loadable module, the kfd_iommu.c file is indeed >> built but does not work: >> >> x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function >> `kfd_iommu_bind_process_to_device': >> kfd_iommu.c:(.text+0x516): undefined reference to `amd_iommu_bind_pasid' >> x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function >> `kfd_iommu_unbind_process': >> kfd_iommu.c:(.text+0x691): undefined reference to `amd_iommu_unbind_pasid' >> x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function >> `kfd_iommu_suspend': >> kfd_iommu.c:(.text+0x966): undefined reference to >> `amd_iommu_set_invalidate_ctx_cb' >> x86_64-linux-ld: kfd_iommu.c:(.text+0x97f): undefined reference to >> `amd_iommu_set_invalid_ppr_cb' >> x86_64-linux-ld: kfd_iommu.c:(.text+0x9a4): undefined reference to >> `amd_iommu_free_device' >> x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function >> `kfd_iommu_resume': >> kfd_iommu.c:(.text+0xa9a): undefined reference to `amd_iommu_init_device' >> x86_64-linux-ld: kfd_iommu.c:(.text+0xadc): undefined reference to >> `amd_iommu_set_invalidate_ctx_cb' >> x86_64-linux-ld: kfd_iommu.c:(.text+0xaff): undefined reference to >> `amd_iommu_set_invalid_ppr_cb' >> x86_64-linux-ld: kfd_iommu.c:(.text+0xc72): undefined reference to >> `amd_iommu_bind_pasid' >> x86_64-linux-ld: kfd_iommu.c:(.text+0xe08): undefined reference to >> `amd_iommu_set_invalidate_ctx_cb' >> x86_64-linux-ld: kfd_iommu.c:(.text+0xe26): undefined reference to >> `amd_iommu_set_invalid_ppr_cb' >> x86_64-linux-ld: kfd_iommu.c:(.text+0xe42): undefined reference to >> `amd_iommu_free_device' >> >> Use IS_REACHABLE to only build IOMMU-V2 support if the amd_iommu symbols >> are reachable by the amdkfd driver. Output a warning if they are not, >> because that may not be what the user was expecting. > This would fix the compile-time failure, but it still fails my CI > because you introduce > a compile-time warning. Can you change it into a runtime warning instead? Sure. > > Neither type of warning is likely to actually reach the person trying > to debug the > problem, so you still end up with machines that don't do what they should, > but I can live with the runtime warning as long as the build doesn't break. OK. > > I think the proper fix would be to not rely on custom hooks into a particular > IOMMU driver, but to instead ensure that the amdgpu driver can do everything > it needs through the regular linux/iommu.h interfaces. I realize this > is more work, > but I wonder if you've tried that, and why it didn't work out. As far as I know this hasn't been tried. I see that intel-iommu has its own SVM thing, which seems to be similar to what our IOMMUv2 does. I guess we'd have to abstract that into a common API. Regards, Felix > >Arnd
Re: [PATCH 1/1] drm/amdkfd: fix build error with AMD_IOMMU_V2=m
On Tue, Mar 9, 2021 at 4:23 AM Felix Kuehling wrote: > > Using 'imply AMD_IOMMU_V2' does not guarantee that the driver can link > against the exported functions. If the GPU driver is built-in but the > IOMMU driver is a loadable module, the kfd_iommu.c file is indeed > built but does not work: > > x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function > `kfd_iommu_bind_process_to_device': > kfd_iommu.c:(.text+0x516): undefined reference to `amd_iommu_bind_pasid' > x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function > `kfd_iommu_unbind_process': > kfd_iommu.c:(.text+0x691): undefined reference to `amd_iommu_unbind_pasid' > x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function > `kfd_iommu_suspend': > kfd_iommu.c:(.text+0x966): undefined reference to > `amd_iommu_set_invalidate_ctx_cb' > x86_64-linux-ld: kfd_iommu.c:(.text+0x97f): undefined reference to > `amd_iommu_set_invalid_ppr_cb' > x86_64-linux-ld: kfd_iommu.c:(.text+0x9a4): undefined reference to > `amd_iommu_free_device' > x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function > `kfd_iommu_resume': > kfd_iommu.c:(.text+0xa9a): undefined reference to `amd_iommu_init_device' > x86_64-linux-ld: kfd_iommu.c:(.text+0xadc): undefined reference to > `amd_iommu_set_invalidate_ctx_cb' > x86_64-linux-ld: kfd_iommu.c:(.text+0xaff): undefined reference to > `amd_iommu_set_invalid_ppr_cb' > x86_64-linux-ld: kfd_iommu.c:(.text+0xc72): undefined reference to > `amd_iommu_bind_pasid' > x86_64-linux-ld: kfd_iommu.c:(.text+0xe08): undefined reference to > `amd_iommu_set_invalidate_ctx_cb' > x86_64-linux-ld: kfd_iommu.c:(.text+0xe26): undefined reference to > `amd_iommu_set_invalid_ppr_cb' > x86_64-linux-ld: kfd_iommu.c:(.text+0xe42): undefined reference to > `amd_iommu_free_device' > > Use IS_REACHABLE to only build IOMMU-V2 support if the amd_iommu symbols > are reachable by the amdkfd driver. Output a warning if they are not, > because that may not be what the user was expecting. This would fix the compile-time failure, but it still fails my CI because you introduce a compile-time warning. Can you change it into a runtime warning instead? Neither type of warning is likely to actually reach the person trying to debug the problem, so you still end up with machines that don't do what they should, but I can live with the runtime warning as long as the build doesn't break. I think the proper fix would be to not rely on custom hooks into a particular IOMMU driver, but to instead ensure that the amdgpu driver can do everything it needs through the regular linux/iommu.h interfaces. I realize this is more work, but I wonder if you've tried that, and why it didn't work out. Arnd
[PATCH 1/1] drm/amdkfd: fix build error with AMD_IOMMU_V2=m
Using 'imply AMD_IOMMU_V2' does not guarantee that the driver can link
against the exported functions. If the GPU driver is built-in but the
IOMMU driver is a loadable module, the kfd_iommu.c file is indeed
built but does not work:
x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function
`kfd_iommu_bind_process_to_device':
kfd_iommu.c:(.text+0x516): undefined reference to `amd_iommu_bind_pasid'
x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function
`kfd_iommu_unbind_process':
kfd_iommu.c:(.text+0x691): undefined reference to `amd_iommu_unbind_pasid'
x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function
`kfd_iommu_suspend':
kfd_iommu.c:(.text+0x966): undefined reference to
`amd_iommu_set_invalidate_ctx_cb'
x86_64-linux-ld: kfd_iommu.c:(.text+0x97f): undefined reference to
`amd_iommu_set_invalid_ppr_cb'
x86_64-linux-ld: kfd_iommu.c:(.text+0x9a4): undefined reference to
`amd_iommu_free_device'
x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function
`kfd_iommu_resume':
kfd_iommu.c:(.text+0xa9a): undefined reference to `amd_iommu_init_device'
x86_64-linux-ld: kfd_iommu.c:(.text+0xadc): undefined reference to
`amd_iommu_set_invalidate_ctx_cb'
x86_64-linux-ld: kfd_iommu.c:(.text+0xaff): undefined reference to
`amd_iommu_set_invalid_ppr_cb'
x86_64-linux-ld: kfd_iommu.c:(.text+0xc72): undefined reference to
`amd_iommu_bind_pasid'
x86_64-linux-ld: kfd_iommu.c:(.text+0xe08): undefined reference to
`amd_iommu_set_invalidate_ctx_cb'
x86_64-linux-ld: kfd_iommu.c:(.text+0xe26): undefined reference to
`amd_iommu_set_invalid_ppr_cb'
x86_64-linux-ld: kfd_iommu.c:(.text+0xe42): undefined reference to
`amd_iommu_free_device'
Use IS_REACHABLE to only build IOMMU-V2 support if the amd_iommu symbols
are reachable by the amdkfd driver. Output a warning if they are not,
because that may not be what the user was expecting.
Fixes: 64d1c3a43a6f ("drm/amdkfd: Centralize IOMMUv2 code and make it
conditional")
Reported-by: Arnd Bergmann
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdkfd/kfd_iommu.c | 10 ++
drivers/gpu/drm/amd/amdkfd/kfd_iommu.h | 6 --
2 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_iommu.c
b/drivers/gpu/drm/amd/amdkfd/kfd_iommu.c
index 66bbca61e3ef..7199eb833f66 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_iommu.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_iommu.c
@@ -20,6 +20,10 @@
* OTHER DEALINGS IN THE SOFTWARE.
*/
+#include
+
+#if IS_REACHABLE(CONFIG_AMD_IOMMU_V2)
+
#include
#include
#include
@@ -355,3 +359,9 @@ int kfd_iommu_add_perf_counters(struct kfd_topology_device
*kdev)
return 0;
}
+
+#else
+
+#warning "Moldular IOMMU-V2 is not usable by built-in KFD"
+
+#endif
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_iommu.h
b/drivers/gpu/drm/amd/amdkfd/kfd_iommu.h
index dd23d9fdf6a8..b25365fc2c4e 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_iommu.h
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_iommu.h
@@ -23,7 +23,9 @@
#ifndef __KFD_IOMMU_H__
#define __KFD_IOMMU_H__
-#if defined(CONFIG_AMD_IOMMU_V2_MODULE) || defined(CONFIG_AMD_IOMMU_V2)
+#include
+
+#if IS_REACHABLE(CONFIG_AMD_IOMMU_V2)
#define KFD_SUPPORT_IOMMU_V2
@@ -73,6 +75,6 @@ static inline int kfd_iommu_add_perf_counters(struct
kfd_topology_device *kdev)
return 0;
}
-#endif /* defined(CONFIG_AMD_IOMMU_V2) */
+#endif /* IS_REACHABLE(CONFIG_AMD_IOMMU_V2) */
#endif /* __KFD_IOMMU_H__ */
--
2.30.0
Re: [PATCH] [variant b] drm/amdkfd: fix build error with missing AMD_IOMMU_V2
Am 2021-03-08 um 3:45 p.m. schrieb Arnd Bergmann:
> From: Arnd Bergmann
>
> Using 'imply AMD_IOMMU_V2' does not guarantee that the driver can link
> against the exported functions. If the GPU driver is built-in but the
> IOMMU driver is a loadable module, the kfd_iommu.c file is indeed
> built but does not work:
>
> x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function
> `kfd_iommu_bind_process_to_device':
> kfd_iommu.c:(.text+0x516): undefined reference to `amd_iommu_bind_pasid'
> x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function
> `kfd_iommu_unbind_process':
> kfd_iommu.c:(.text+0x691): undefined reference to `amd_iommu_unbind_pasid'
> x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function
> `kfd_iommu_suspend':
> kfd_iommu.c:(.text+0x966): undefined reference to
> `amd_iommu_set_invalidate_ctx_cb'
> x86_64-linux-ld: kfd_iommu.c:(.text+0x97f): undefined reference to
> `amd_iommu_set_invalid_ppr_cb'
> x86_64-linux-ld: kfd_iommu.c:(.text+0x9a4): undefined reference to
> `amd_iommu_free_device'
> x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function
> `kfd_iommu_resume':
> kfd_iommu.c:(.text+0xa9a): undefined reference to `amd_iommu_init_device'
> x86_64-linux-ld: kfd_iommu.c:(.text+0xadc): undefined reference to
> `amd_iommu_set_invalidate_ctx_cb'
> x86_64-linux-ld: kfd_iommu.c:(.text+0xaff): undefined reference to
> `amd_iommu_set_invalid_ppr_cb'
> x86_64-linux-ld: kfd_iommu.c:(.text+0xc72): undefined reference to
> `amd_iommu_bind_pasid'
> x86_64-linux-ld: kfd_iommu.c:(.text+0xe08): undefined reference to
> `amd_iommu_set_invalidate_ctx_cb'
> x86_64-linux-ld: kfd_iommu.c:(.text+0xe26): undefined reference to
> `amd_iommu_set_invalid_ppr_cb'
> x86_64-linux-ld: kfd_iommu.c:(.text+0xe42): undefined reference to
> `amd_iommu_free_device'
>
> Change the 'imply' to a weak dependency that still allows compiling
> in all other configurations but disallows the configuration that
> causes a link failure.
I don't like this solution. It hides the HSA_AMD option in menuconfig
and it's not intuitively obvious to someone configuring a kernel why
it's not available. They may not even notice that it's missing and then
wonder later, why KFD functionality is missing in their kernel.
What I'm trying to achieve is, that KFD can be compiled without
AMD-IOMMU-V2 support in this case. I just tested my version using
IS_REACHABLE. I'll reply with that patch in a moment.
Regards,
Felix
>
> Fixes: 64d1c3a43a6f ("drm/amdkfd: Centralize IOMMUv2 code and make it
> conditional")
> Signed-off-by: Arnd Bergmann
> ---
> drivers/gpu/drm/amd/amdkfd/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdkfd/Kconfig
> b/drivers/gpu/drm/amd/amdkfd/Kconfig
> index f02c938f75da..d01dba2af3bb 100644
> --- a/drivers/gpu/drm/amd/amdkfd/Kconfig
> +++ b/drivers/gpu/drm/amd/amdkfd/Kconfig
> @@ -6,7 +6,7 @@
> config HSA_AMD
> bool "HSA kernel driver for AMD GPU devices"
> depends on DRM_AMDGPU && (X86_64 || ARM64 || PPC64)
> - imply AMD_IOMMU_V2 if X86_64
> + depends on AMD_IOMMU_V2=y || DRM_AMDGPU=m
> select HMM_MIRROR
> select MMU_NOTIFIER
> select DRM_AMDGPU_USERPTR
[PATCH] [variant b] drm/amdkfd: fix build error with missing AMD_IOMMU_V2
From: Arnd Bergmann
Using 'imply AMD_IOMMU_V2' does not guarantee that the driver can link
against the exported functions. If the GPU driver is built-in but the
IOMMU driver is a loadable module, the kfd_iommu.c file is indeed
built but does not work:
x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function
`kfd_iommu_bind_process_to_device':
kfd_iommu.c:(.text+0x516): undefined reference to `amd_iommu_bind_pasid'
x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function
`kfd_iommu_unbind_process':
kfd_iommu.c:(.text+0x691): undefined reference to `amd_iommu_unbind_pasid'
x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function
`kfd_iommu_suspend':
kfd_iommu.c:(.text+0x966): undefined reference to
`amd_iommu_set_invalidate_ctx_cb'
x86_64-linux-ld: kfd_iommu.c:(.text+0x97f): undefined reference to
`amd_iommu_set_invalid_ppr_cb'
x86_64-linux-ld: kfd_iommu.c:(.text+0x9a4): undefined reference to
`amd_iommu_free_device'
x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function
`kfd_iommu_resume':
kfd_iommu.c:(.text+0xa9a): undefined reference to `amd_iommu_init_device'
x86_64-linux-ld: kfd_iommu.c:(.text+0xadc): undefined reference to
`amd_iommu_set_invalidate_ctx_cb'
x86_64-linux-ld: kfd_iommu.c:(.text+0xaff): undefined reference to
`amd_iommu_set_invalid_ppr_cb'
x86_64-linux-ld: kfd_iommu.c:(.text+0xc72): undefined reference to
`amd_iommu_bind_pasid'
x86_64-linux-ld: kfd_iommu.c:(.text+0xe08): undefined reference to
`amd_iommu_set_invalidate_ctx_cb'
x86_64-linux-ld: kfd_iommu.c:(.text+0xe26): undefined reference to
`amd_iommu_set_invalid_ppr_cb'
x86_64-linux-ld: kfd_iommu.c:(.text+0xe42): undefined reference to
`amd_iommu_free_device'
Change the 'imply' to a weak dependency that still allows compiling
in all other configurations but disallows the configuration that
causes a link failure.
Fixes: 64d1c3a43a6f ("drm/amdkfd: Centralize IOMMUv2 code and make it
conditional")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/amd/amdkfd/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/Kconfig
b/drivers/gpu/drm/amd/amdkfd/Kconfig
index f02c938f75da..d01dba2af3bb 100644
--- a/drivers/gpu/drm/amd/amdkfd/Kconfig
+++ b/drivers/gpu/drm/amd/amdkfd/Kconfig
@@ -6,7 +6,7 @@
config HSA_AMD
bool "HSA kernel driver for AMD GPU devices"
depends on DRM_AMDGPU && (X86_64 || ARM64 || PPC64)
- imply AMD_IOMMU_V2 if X86_64
+ depends on AMD_IOMMU_V2=y || DRM_AMDGPU=m
select HMM_MIRROR
select MMU_NOTIFIER
select DRM_AMDGPU_USERPTR
--
2.29.2
Re: [PATCH] drm/amdkfd: fix build error with missing AMD_IOMMU_V2
On Mon, Mar 8, 2021 at 9:12 PM Christian König wrote: > Am 08.03.21 um 21:02 schrieb Felix Kuehling: > > Am 2021-03-08 um 2:33 p.m. schrieb Arnd Bergmann: > > I don't want to create a hard dependency on AMD_IOMMU_V2 if I can avoid > > it, because it is only really needed for a small number of AMD APUs, and > > even there it is now optional for more recent ones. > > > > Is there a better way to avoid build failures without creating a hard > > dependency? > > What you need is the same trick we used for AGP on radeon/nouveau: > > depends on AMD_IOMMU_V2 || !AMD_IOMMU_V2 > > This way when AMD_IOMMU_V2 is build as a module DRM_AMDGPU will be build > as a module as well. When it is disabled completely we don't care. Note that this trick only works if you put it into the DRM_AMDGPU Kconfig option itself, since that decides if the driver is built-in or a loadable module. If HSA_AMD is disabled, that dependency is not really necessary. The version I suggested -- adding "depends on AMD_IOMMU_V2=y || DRM_AMDGPU=m" to the HSA_AMD option -- might be slightly nicer since it lets you still build a kernel with DRM_AMDGPU=y and AMD_IOMMU_V2=m, but without the HSA_AMD. I can send a patch with either of those two options to replace my original patch. > >The documentation in > > Documentation/kbuild/kconfig-language.rst suggests using if > > (IS_REACHABLE(CONFIG_AMD_IOMMU_V2)) to guard those problematic function > > calls. I think more generally, we could guard all of kfd_iommu.c with > > > > #if IS_REACHABLE(CONFIG_AMD_IOMMU_V2) > > > > And use the same condition to define the stubs in kfd_iommu.h. This would fix the compile-time error, but it's also the one I'd least recommend out of all the options, because that causes the driver to silently not work as expected. This seems even worse than failing the build. Arnd
Re: [PATCH] drm/amdkfd: fix build error with missing AMD_IOMMU_V2
Am 08.03.21 um 21:02 schrieb Felix Kuehling: Am 2021-03-08 um 2:33 p.m. schrieb Arnd Bergmann: On Mon, Mar 8, 2021 at 8:11 PM Felix Kuehling wrote: Am 2021-03-08 um 2:05 p.m. schrieb Arnd Bergmann: On Mon, Mar 8, 2021 at 5:24 PM Felix Kuehling wrote: The driver build should work without IOMMUv2. In amdkfd/Makefile, we have this condition: ifneq ($(CONFIG_AMD_IOMMU_V2),) AMDKFD_FILES += $(AMDKFD_PATH)/kfd_iommu.o endif In amdkfd/kfd_iommu.h we define inline stubs of the functions that are causing your link-failures if IOMMU_V2 is not enabled: #if defined(CONFIG_AMD_IOMMU_V2_MODULE) || defined(CONFIG_AMD_IOMMU_V2) ... function declarations ... #else ... stubs ... #endif Right, that is the problem I tried to explain in my patch description. Should we just drop the 'imply' then and add a proper dependency like this? depends on DRM_AMDGPU && (X86_64 || ARM64 || PPC64) depends on AMD_IOMMU_V2=y || DRM_AMDGPU=m I can send a v2 after some testing if you prefer this version. No. My point is, there should not be a hard dependency. The build should work without CONFIG_AMD_IOMMU_V2. I don't understand why it's not working for you. It looks like you're building kfd_iommu.o, which should not be happening when AMD_IOMMU_V2 is not enabled. The condition in amdkfd/Makefile should make sure that kfd_iommu.o doesn't get built with your kernel config. Again, as I explained in the changelog text, AMD_IOMMU_V2 configured as a loadable module, while AMDGPU is configured as built-in. I'm sorry, I didn't read it carefully. And I thought "imply" was meant to fix exactly this kind of issue. I don't want to create a hard dependency on AMD_IOMMU_V2 if I can avoid it, because it is only really needed for a small number of AMD APUs, and even there it is now optional for more recent ones. Is there a better way to avoid build failures without creating a hard dependency? What you need is the same trick we used for AGP on radeon/nouveau: depends on AMD_IOMMU_V2 || !AMD_IOMMU_V2 This way when AMD_IOMMU_V2 is build as a module DRM_AMDGPU will be build as a module as well. When it is disabled completely we don't care. Regards, Christian. The documentation in Documentation/kbuild/kconfig-language.rst suggests using if (IS_REACHABLE(CONFIG_AMD_IOMMU_V2)) to guard those problematic function calls. I think more generally, we could guard all of kfd_iommu.c with #if IS_REACHABLE(CONFIG_AMD_IOMMU_V2) And use the same condition to define the stubs in kfd_iommu.h. Regards, Felix The causes a link failure for the vmlinux file, because the linker cannot resolve addresses of loadable modules at compile time -- they have not been loaded yet. Arnd ___ dri-devel mailing list dri-de...@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ amd-gfx mailing list amd-...@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amdkfd: fix build error with missing AMD_IOMMU_V2
Am 2021-03-08 um 2:33 p.m. schrieb Arnd Bergmann: > On Mon, Mar 8, 2021 at 8:11 PM Felix Kuehling wrote: >> Am 2021-03-08 um 2:05 p.m. schrieb Arnd Bergmann: >>> On Mon, Mar 8, 2021 at 5:24 PM Felix Kuehling >>> wrote: The driver build should work without IOMMUv2. In amdkfd/Makefile, we have this condition: ifneq ($(CONFIG_AMD_IOMMU_V2),) AMDKFD_FILES += $(AMDKFD_PATH)/kfd_iommu.o endif In amdkfd/kfd_iommu.h we define inline stubs of the functions that are causing your link-failures if IOMMU_V2 is not enabled: #if defined(CONFIG_AMD_IOMMU_V2_MODULE) || defined(CONFIG_AMD_IOMMU_V2) ... function declarations ... #else ... stubs ... #endif >>> Right, that is the problem I tried to explain in my patch description. >>> >>> Should we just drop the 'imply' then and add a proper dependency like this? >>> >>> depends on DRM_AMDGPU && (X86_64 || ARM64 || PPC64) >>> depends on AMD_IOMMU_V2=y || DRM_AMDGPU=m >>> >>> I can send a v2 after some testing if you prefer this version. >> No. My point is, there should not be a hard dependency. The build should >> work without CONFIG_AMD_IOMMU_V2. I don't understand why it's not >> working for you. It looks like you're building kfd_iommu.o, which should >> not be happening when AMD_IOMMU_V2 is not enabled. The condition in >> amdkfd/Makefile should make sure that kfd_iommu.o doesn't get built with >> your kernel config. > Again, as I explained in the changelog text, AMD_IOMMU_V2 configured as > a loadable module, while AMDGPU is configured as built-in. I'm sorry, I didn't read it carefully. And I thought "imply" was meant to fix exactly this kind of issue. I don't want to create a hard dependency on AMD_IOMMU_V2 if I can avoid it, because it is only really needed for a small number of AMD APUs, and even there it is now optional for more recent ones. Is there a better way to avoid build failures without creating a hard dependency? The documentation in Documentation/kbuild/kconfig-language.rst suggests using if (IS_REACHABLE(CONFIG_AMD_IOMMU_V2)) to guard those problematic function calls. I think more generally, we could guard all of kfd_iommu.c with #if IS_REACHABLE(CONFIG_AMD_IOMMU_V2) And use the same condition to define the stubs in kfd_iommu.h. Regards, Felix > > The causes a link failure for the vmlinux file, because the linker cannot > resolve addresses of loadable modules at compile time -- they have > not been loaded yet. > > Arnd > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amdkfd: fix build error with missing AMD_IOMMU_V2
On Mon, Mar 8, 2021 at 8:11 PM Felix Kuehling wrote: > > Am 2021-03-08 um 2:05 p.m. schrieb Arnd Bergmann: > > On Mon, Mar 8, 2021 at 5:24 PM Felix Kuehling > > wrote: > >> The driver build should work without IOMMUv2. In amdkfd/Makefile, we > >> have this condition: > >> > >> ifneq ($(CONFIG_AMD_IOMMU_V2),) > >> AMDKFD_FILES += $(AMDKFD_PATH)/kfd_iommu.o > >> endif > >> > >> In amdkfd/kfd_iommu.h we define inline stubs of the functions that are > >> causing your link-failures if IOMMU_V2 is not enabled: > >> > >> #if defined(CONFIG_AMD_IOMMU_V2_MODULE) || defined(CONFIG_AMD_IOMMU_V2) > >> ... function declarations ... > >> #else > >> ... stubs ... > >> #endif > > Right, that is the problem I tried to explain in my patch description. > > > > Should we just drop the 'imply' then and add a proper dependency like this? > > > > depends on DRM_AMDGPU && (X86_64 || ARM64 || PPC64) > > depends on AMD_IOMMU_V2=y || DRM_AMDGPU=m > > > > I can send a v2 after some testing if you prefer this version. > > No. My point is, there should not be a hard dependency. The build should > work without CONFIG_AMD_IOMMU_V2. I don't understand why it's not > working for you. It looks like you're building kfd_iommu.o, which should > not be happening when AMD_IOMMU_V2 is not enabled. The condition in > amdkfd/Makefile should make sure that kfd_iommu.o doesn't get built with > your kernel config. Again, as I explained in the changelog text, AMD_IOMMU_V2 configured as a loadable module, while AMDGPU is configured as built-in. The causes a link failure for the vmlinux file, because the linker cannot resolve addresses of loadable modules at compile time -- they have not been loaded yet. Arnd
Re: [PATCH] drm/amdkfd: fix build error with missing AMD_IOMMU_V2
Am 2021-03-08 um 2:05 p.m. schrieb Arnd Bergmann: > On Mon, Mar 8, 2021 at 5:24 PM Felix Kuehling wrote: >> The driver build should work without IOMMUv2. In amdkfd/Makefile, we >> have this condition: >> >> ifneq ($(CONFIG_AMD_IOMMU_V2),) >> AMDKFD_FILES += $(AMDKFD_PATH)/kfd_iommu.o >> endif >> >> In amdkfd/kfd_iommu.h we define inline stubs of the functions that are >> causing your link-failures if IOMMU_V2 is not enabled: >> >> #if defined(CONFIG_AMD_IOMMU_V2_MODULE) || defined(CONFIG_AMD_IOMMU_V2) >> ... function declarations ... >> #else >> ... stubs ... >> #endif > Right, that is the problem I tried to explain in my patch description. > > Should we just drop the 'imply' then and add a proper dependency like this? > > depends on DRM_AMDGPU && (X86_64 || ARM64 || PPC64) > depends on AMD_IOMMU_V2=y || DRM_AMDGPU=m > > I can send a v2 after some testing if you prefer this version. No. My point is, there should not be a hard dependency. The build should work without CONFIG_AMD_IOMMU_V2. I don't understand why it's not working for you. It looks like you're building kfd_iommu.o, which should not be happening when AMD_IOMMU_V2 is not enabled. The condition in amdkfd/Makefile should make sure that kfd_iommu.o doesn't get built with your kernel config. Regards, Felix > > Arnd
Re: [PATCH] drm/amdkfd: fix build error with missing AMD_IOMMU_V2
On Mon, Mar 8, 2021 at 5:24 PM Felix Kuehling wrote: > > The driver build should work without IOMMUv2. In amdkfd/Makefile, we > have this condition: > > ifneq ($(CONFIG_AMD_IOMMU_V2),) > AMDKFD_FILES += $(AMDKFD_PATH)/kfd_iommu.o > endif > > In amdkfd/kfd_iommu.h we define inline stubs of the functions that are > causing your link-failures if IOMMU_V2 is not enabled: > > #if defined(CONFIG_AMD_IOMMU_V2_MODULE) || defined(CONFIG_AMD_IOMMU_V2) > ... function declarations ... > #else > ... stubs ... > #endif Right, that is the problem I tried to explain in my patch description. Should we just drop the 'imply' then and add a proper dependency like this? depends on DRM_AMDGPU && (X86_64 || ARM64 || PPC64) depends on AMD_IOMMU_V2=y || DRM_AMDGPU=m I can send a v2 after some testing if you prefer this version. Arnd
Re: [PATCH] drm/amdkfd: fix build error with missing AMD_IOMMU_V2
The driver build should work without IOMMUv2. In amdkfd/Makefile, we
have this condition:
ifneq ($(CONFIG_AMD_IOMMU_V2),)
AMDKFD_FILES += $(AMDKFD_PATH)/kfd_iommu.o
endif
In amdkfd/kfd_iommu.h we define inline stubs of the functions that are
causing your link-failures if IOMMU_V2 is not enabled:
#if defined(CONFIG_AMD_IOMMU_V2_MODULE) || defined(CONFIG_AMD_IOMMU_V2)
... function declarations ...
#else
... stubs ...
#endif
Regards,
Felix
Am 2021-03-08 um 10:33 a.m. schrieb Arnd Bergmann:
> From: Arnd Bergmann
>
> Using 'imply AMD_IOMMU_V2' does not guarantee that the driver can link
> against the exported functions. If the GPU driver is built-in but the
> IOMMU driver is a loadable module, the kfd_iommu.c file is indeed
> built but does not work:
>
> x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function
> `kfd_iommu_bind_process_to_device':
> kfd_iommu.c:(.text+0x516): undefined reference to `amd_iommu_bind_pasid'
> x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function
> `kfd_iommu_unbind_process':
> kfd_iommu.c:(.text+0x691): undefined reference to `amd_iommu_unbind_pasid'
> x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function
> `kfd_iommu_suspend':
> kfd_iommu.c:(.text+0x966): undefined reference to
> `amd_iommu_set_invalidate_ctx_cb'
> x86_64-linux-ld: kfd_iommu.c:(.text+0x97f): undefined reference to
> `amd_iommu_set_invalid_ppr_cb'
> x86_64-linux-ld: kfd_iommu.c:(.text+0x9a4): undefined reference to
> `amd_iommu_free_device'
> x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function
> `kfd_iommu_resume':
> kfd_iommu.c:(.text+0xa9a): undefined reference to `amd_iommu_init_device'
> x86_64-linux-ld: kfd_iommu.c:(.text+0xadc): undefined reference to
> `amd_iommu_set_invalidate_ctx_cb'
> x86_64-linux-ld: kfd_iommu.c:(.text+0xaff): undefined reference to
> `amd_iommu_set_invalid_ppr_cb'
> x86_64-linux-ld: kfd_iommu.c:(.text+0xc72): undefined reference to
> `amd_iommu_bind_pasid'
> x86_64-linux-ld: kfd_iommu.c:(.text+0xe08): undefined reference to
> `amd_iommu_set_invalidate_ctx_cb'
> x86_64-linux-ld: kfd_iommu.c:(.text+0xe26): undefined reference to
> `amd_iommu_set_invalid_ppr_cb'
> x86_64-linux-ld: kfd_iommu.c:(.text+0xe42): undefined reference to
> `amd_iommu_free_device'
>
> Use a stronger 'select' instead.
>
> Fixes: 64d1c3a43a6f ("drm/amdkfd: Centralize IOMMUv2 code and make it
> conditional")
> Signed-off-by: Arnd Bergmann
> ---
> drivers/gpu/drm/amd/amdkfd/Kconfig | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdkfd/Kconfig
> b/drivers/gpu/drm/amd/amdkfd/Kconfig
> index f02c938f75da..91f85dfb7ba6 100644
> --- a/drivers/gpu/drm/amd/amdkfd/Kconfig
> +++ b/drivers/gpu/drm/amd/amdkfd/Kconfig
> @@ -5,8 +5,9 @@
>
> config HSA_AMD
> bool "HSA kernel driver for AMD GPU devices"
> - depends on DRM_AMDGPU && (X86_64 || ARM64 || PPC64)
> - imply AMD_IOMMU_V2 if X86_64
> + depends on DRM_AMDGPU && ((X86_64 && IOMMU_SUPPORT && ACPI) || ARM64 ||
> PPC64)
> + select AMD_IOMMU if X86_64
> + select AMD_IOMMU_V2 if X86_64
> select HMM_MIRROR
> select MMU_NOTIFIER
> select DRM_AMDGPU_USERPTR
[PATCH] drm/amdkfd: fix build error with missing AMD_IOMMU_V2
From: Arnd Bergmann
Using 'imply AMD_IOMMU_V2' does not guarantee that the driver can link
against the exported functions. If the GPU driver is built-in but the
IOMMU driver is a loadable module, the kfd_iommu.c file is indeed
built but does not work:
x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function
`kfd_iommu_bind_process_to_device':
kfd_iommu.c:(.text+0x516): undefined reference to `amd_iommu_bind_pasid'
x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function
`kfd_iommu_unbind_process':
kfd_iommu.c:(.text+0x691): undefined reference to `amd_iommu_unbind_pasid'
x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function
`kfd_iommu_suspend':
kfd_iommu.c:(.text+0x966): undefined reference to
`amd_iommu_set_invalidate_ctx_cb'
x86_64-linux-ld: kfd_iommu.c:(.text+0x97f): undefined reference to
`amd_iommu_set_invalid_ppr_cb'
x86_64-linux-ld: kfd_iommu.c:(.text+0x9a4): undefined reference to
`amd_iommu_free_device'
x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function
`kfd_iommu_resume':
kfd_iommu.c:(.text+0xa9a): undefined reference to `amd_iommu_init_device'
x86_64-linux-ld: kfd_iommu.c:(.text+0xadc): undefined reference to
`amd_iommu_set_invalidate_ctx_cb'
x86_64-linux-ld: kfd_iommu.c:(.text+0xaff): undefined reference to
`amd_iommu_set_invalid_ppr_cb'
x86_64-linux-ld: kfd_iommu.c:(.text+0xc72): undefined reference to
`amd_iommu_bind_pasid'
x86_64-linux-ld: kfd_iommu.c:(.text+0xe08): undefined reference to
`amd_iommu_set_invalidate_ctx_cb'
x86_64-linux-ld: kfd_iommu.c:(.text+0xe26): undefined reference to
`amd_iommu_set_invalid_ppr_cb'
x86_64-linux-ld: kfd_iommu.c:(.text+0xe42): undefined reference to
`amd_iommu_free_device'
Use a stronger 'select' instead.
Fixes: 64d1c3a43a6f ("drm/amdkfd: Centralize IOMMUv2 code and make it
conditional")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/amd/amdkfd/Kconfig | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/Kconfig
b/drivers/gpu/drm/amd/amdkfd/Kconfig
index f02c938f75da..91f85dfb7ba6 100644
--- a/drivers/gpu/drm/amd/amdkfd/Kconfig
+++ b/drivers/gpu/drm/amd/amdkfd/Kconfig
@@ -5,8 +5,9 @@
config HSA_AMD
bool "HSA kernel driver for AMD GPU devices"
- depends on DRM_AMDGPU && (X86_64 || ARM64 || PPC64)
- imply AMD_IOMMU_V2 if X86_64
+ depends on DRM_AMDGPU && ((X86_64 && IOMMU_SUPPORT && ACPI) || ARM64 ||
PPC64)
+ select AMD_IOMMU if X86_64
+ select AMD_IOMMU_V2 if X86_64
select HMM_MIRROR
select MMU_NOTIFIER
select DRM_AMDGPU_USERPTR
--
2.29.2
[PATCH] usb: dwc3: fix build error when POWER_SUPPLY is not enabled
Fix build error when CONFIG_POWER_SUPPLY is not enabled.
The build error occurs in mips (cavium_octeon_defconfig).
mips-linux-gnu-ld: drivers/usb/dwc3/core.o: in function `dwc3_remove':
drivers/usb/dwc3/core.c:1657: undefined reference to `power_supply_put'
mips-linux-gnu-ld: drivers/usb/dwc3/core.o: in function `dwc3_get_properties':
drivers/usb/dwc3/core.c:1270: undefined reference to `power_supply_get_by_name'
mips-linux-gnu-ld: drivers/usb/dwc3/core.o: in function `dwc3_probe':
drivers/usb/dwc3/core.c:1632: undefined reference to `power_supply_put'
Fixes: 59fa3def35de ("usb: dwc3: add a power supply for current control")
Reported-by: Naresh Kamboju
Signed-off-by: Ray Chi
---
include/linux/power_supply.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/include/linux/power_supply.h b/include/linux/power_supply.h
index 81a55e974feb..6e776be5bfa0 100644
--- a/include/linux/power_supply.h
+++ b/include/linux/power_supply.h
@@ -381,8 +381,14 @@ struct power_supply_battery_info {
extern struct atomic_notifier_head power_supply_notifier;
extern int power_supply_reg_notifier(struct notifier_block *nb);
extern void power_supply_unreg_notifier(struct notifier_block *nb);
+#if IS_ENABLED(CONFIG_POWER_SUPPLY)
extern struct power_supply *power_supply_get_by_name(const char *name);
extern void power_supply_put(struct power_supply *psy);
+#else
+static inline void power_supply_put(struct power_supply *psy) {}
+static inline struct power_supply *power_supply_get_by_name(const char *name)
+{ return NULL; }
+#endif
#ifdef CONFIG_OF
extern struct power_supply *power_supply_get_by_phandle(struct device_node *np,
const char *property);
--
2.30.1.766.gb4fecdf3b7-goog
[PATCH 5.4 15/22] usbip: tools: fix build error for multiple definition
From: Antonio Borneo
commit d5efc2e6b98fe661dbd8dd0d5d5bfb961728e57a upstream.
With GCC 10, building usbip triggers error for multiple definition
of 'udev_context', in:
- libsrc/vhci_driver.c:18 and
- libsrc/usbip_host_common.c:27.
Declare as extern the definition in libsrc/usbip_host_common.c.
Signed-off-by: Antonio Borneo
Acked-by: Shuah Khan
Link:
https://lore.kernel.org/r/20200618000844.1048309-1-borneo.anto...@gmail.com
Cc: Petr Štetiar
Signed-off-by: Greg Kroah-Hartman
---
tools/usb/usbip/libsrc/usbip_host_common.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/tools/usb/usbip/libsrc/usbip_host_common.c
+++ b/tools/usb/usbip/libsrc/usbip_host_common.c
@@ -23,7 +23,7 @@
#include "list.h"
#include "sysfs_utils.h"
-struct udev *udev_context;
+extern struct udev *udev_context;
static int32_t read_attr_usbip_status(struct usbip_usb_device *udev)
{
[PATCH 5.11 712/775] powerpc/32: Preserve cr1 in exception prolog stack check to fix build error
From: Christophe Leroy
commit 3642eb21256a317ac14e9ed560242c6d20cf06d9 upstream.
THREAD_ALIGN_SHIFT = THREAD_SHIFT + 1 = PAGE_SHIFT + 1
Maximum PAGE_SHIFT is 18 for 256k pages so
THREAD_ALIGN_SHIFT is 19 at the maximum.
No need to clobber cr1, it can be preserved when moving r1
into CR when we check stack overflow.
This reduces the number of instructions in Machine Check Exception
prolog and fixes a build failure reported by the kernel test robot
on v5.10 stable when building with RTAS + VMAP_STACK + KVM. That
build failure is due to too many instructions in the prolog hence
not fitting between 0x200 and 0x300. Allthough the problem doesn't
show up in mainline, it is still worth the change.
Fixes: 98bf2d3f4970 ("powerpc/32s: Fix RTAS machine check with VMAP stack")
Cc: sta...@vger.kernel.org
Reported-by: kernel test robot
Signed-off-by: Christophe Leroy
Signed-off-by: Michael Ellerman
Link:
https://lore.kernel.org/r/5ae4d545e3ac58e133d2599e0deb88843cb494fc.1612768623.git.christophe.le...@csgroup.eu
Signed-off-by: Greg Kroah-Hartman
---
arch/powerpc/kernel/head_32.h|2 +-
arch/powerpc/kernel/head_book3s_32.S |6 --
2 files changed, 1 insertion(+), 7 deletions(-)
--- a/arch/powerpc/kernel/head_32.h
+++ b/arch/powerpc/kernel/head_32.h
@@ -47,7 +47,7 @@
lwz r1,TASK_STACK-THREAD(r1)
addir1, r1, THREAD_SIZE - INT_FRAME_SIZE
1:
- mtcrf 0x7f, r1
+ mtcrf 0x3f, r1
bt 32 - THREAD_ALIGN_SHIFT, stack_overflow
#else
subir11, r1, INT_FRAME_SIZE /* use r1 if kernel */
--- a/arch/powerpc/kernel/head_book3s_32.S
+++ b/arch/powerpc/kernel/head_book3s_32.S
@@ -278,12 +278,6 @@ MachineCheck:
7: EXCEPTION_PROLOG_2
addir3,r1,STACK_FRAME_OVERHEAD
#ifdef CONFIG_PPC_CHRP
-#ifdef CONFIG_VMAP_STACK
- mfspr r4, SPRN_SPRG_THREAD
- tovirt(r4, r4)
- lwz r4, RTAS_SP(r4)
- cmpwi cr1, r4, 0
-#endif
beq cr1, machine_check_tramp
twi 31, 0, 0
#else
[PATCH 5.11 626/775] ASoC: siu: Fix build error by a wrong const prefix
From: Takashi Iwai
commit ae07f5c7c5e9ebca5b9d6471bb4b99a9da5c6d88 upstream.
A const prefix was put wrongly in the middle at the code refactoring
commit 932eaf7c7904 ("ASoC: sh: siu_pcm: remove snd_pcm_ops"), which
leads to a build error as:
sound/soc/sh/siu_pcm.c:546:8: error: expected '{' before 'const'
Also, another inconsistency is that the declaration of siu_component
misses the const prefix.
This patch corrects both failures.
Fixes: 932eaf7c7904 ("ASoC: sh: siu_pcm: remove snd_pcm_ops")
Cc:
Signed-off-by: Takashi Iwai
Link: https://lore.kernel.org/r/20210126154702.3974-1-ti...@suse.de
Signed-off-by: Mark Brown
Signed-off-by: Greg Kroah-Hartman
---
sound/soc/sh/siu.h |2 +-
sound/soc/sh/siu_pcm.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
--- a/sound/soc/sh/siu.h
+++ b/sound/soc/sh/siu.h
@@ -169,7 +169,7 @@ static inline u32 siu_read32(u32 __iomem
#define SIU_BRGBSEL(0x108 / sizeof(u32))
#define SIU_BRRB (0x10c / sizeof(u32))
-extern struct snd_soc_component_driver siu_component;
+extern const struct snd_soc_component_driver siu_component;
extern struct siu_info *siu_i2s_data;
int siu_init_port(int port, struct siu_port **port_info, struct snd_card
*card);
--- a/sound/soc/sh/siu_pcm.c
+++ b/sound/soc/sh/siu_pcm.c
@@ -543,7 +543,7 @@ static void siu_pcm_free(struct snd_soc_
dev_dbg(pcm->card->dev, "%s\n", __func__);
}
-struct const snd_soc_component_driver siu_component = {
+const struct snd_soc_component_driver siu_component = {
.name = DRV_NAME,
.open = siu_pcm_open,
.close = siu_pcm_close,
[PATCH 5.11 395/775] powerpc: Fix build error in paravirt.h
From: Michal Suchanek
[ Upstream commit 9899a56f1eca964cd0de21008a9fa1523a571231 ]
./arch/powerpc/include/asm/paravirt.h:83:44: error: implicit declaration
of function 'smp_processor_id'; did you mean 'raw_smp_processor_id'?
smp_processor_id is defined in linux/smp.h but it is not included.
The build error happens only when the patch is applied to 5.3 kernel but
it only works by chance in mainline.
Fixes: ca3f969dcb11 ("powerpc/paravirt: Use is_kvm_guest() in
vcpu_is_preempted()")
Signed-off-by: Michal Suchanek
Signed-off-by: Michael Ellerman
Link: https://lore.kernel.org/r/20210120132838.15589-1-msucha...@suse.de
Signed-off-by: Sasha Levin
---
arch/powerpc/include/asm/paravirt.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/include/asm/paravirt.h
b/arch/powerpc/include/asm/paravirt.h
index edc08f04aef77..5d1726bb28e79 100644
--- a/arch/powerpc/include/asm/paravirt.h
+++ b/arch/powerpc/include/asm/paravirt.h
@@ -10,6 +10,7 @@
#endif
#ifdef CONFIG_PPC_SPLPAR
+#include
#include
#include
--
2.27.0
[PATCH 5.10 607/663] powerpc/32: Preserve cr1 in exception prolog stack check to fix build error
From: Christophe Leroy
commit 3642eb21256a317ac14e9ed560242c6d20cf06d9 upstream.
THREAD_ALIGN_SHIFT = THREAD_SHIFT + 1 = PAGE_SHIFT + 1
Maximum PAGE_SHIFT is 18 for 256k pages so
THREAD_ALIGN_SHIFT is 19 at the maximum.
No need to clobber cr1, it can be preserved when moving r1
into CR when we check stack overflow.
This reduces the number of instructions in Machine Check Exception
prolog and fixes a build failure reported by the kernel test robot
on v5.10 stable when building with RTAS + VMAP_STACK + KVM. That
build failure is due to too many instructions in the prolog hence
not fitting between 0x200 and 0x300. Allthough the problem doesn't
show up in mainline, it is still worth the change.
Fixes: 98bf2d3f4970 ("powerpc/32s: Fix RTAS machine check with VMAP stack")
Cc: sta...@vger.kernel.org
Reported-by: kernel test robot
Signed-off-by: Christophe Leroy
Signed-off-by: Michael Ellerman
Link:
https://lore.kernel.org/r/5ae4d545e3ac58e133d2599e0deb88843cb494fc.1612768623.git.christophe.le...@csgroup.eu
Signed-off-by: Greg Kroah-Hartman
---
arch/powerpc/kernel/head_32.h|2 +-
arch/powerpc/kernel/head_book3s_32.S |6 --
2 files changed, 1 insertion(+), 7 deletions(-)
--- a/arch/powerpc/kernel/head_32.h
+++ b/arch/powerpc/kernel/head_32.h
@@ -56,7 +56,7 @@
1:
tophys_novmstack r11, r11
#ifdef CONFIG_VMAP_STACK
- mtcrf 0x7f, r1
+ mtcrf 0x3f, r1
bt 32 - THREAD_ALIGN_SHIFT, stack_overflow
#endif
.endm
--- a/arch/powerpc/kernel/head_book3s_32.S
+++ b/arch/powerpc/kernel/head_book3s_32.S
@@ -280,12 +280,6 @@ MachineCheck:
7: EXCEPTION_PROLOG_2
addir3,r1,STACK_FRAME_OVERHEAD
#ifdef CONFIG_PPC_CHRP
-#ifdef CONFIG_VMAP_STACK
- mfspr r4, SPRN_SPRG_THREAD
- tovirt(r4, r4)
- lwz r4, RTAS_SP(r4)
- cmpwi cr1, r4, 0
-#endif
beq cr1, machine_check_tramp
twi 31, 0, 0
#else
[PATCH 5.10 523/663] ASoC: siu: Fix build error by a wrong const prefix
From: Takashi Iwai
commit ae07f5c7c5e9ebca5b9d6471bb4b99a9da5c6d88 upstream.
A const prefix was put wrongly in the middle at the code refactoring
commit 932eaf7c7904 ("ASoC: sh: siu_pcm: remove snd_pcm_ops"), which
leads to a build error as:
sound/soc/sh/siu_pcm.c:546:8: error: expected '{' before 'const'
Also, another inconsistency is that the declaration of siu_component
misses the const prefix.
This patch corrects both failures.
Fixes: 932eaf7c7904 ("ASoC: sh: siu_pcm: remove snd_pcm_ops")
Cc:
Signed-off-by: Takashi Iwai
Link: https://lore.kernel.org/r/20210126154702.3974-1-ti...@suse.de
Signed-off-by: Mark Brown
Signed-off-by: Greg Kroah-Hartman
---
sound/soc/sh/siu.h |2 +-
sound/soc/sh/siu_pcm.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
--- a/sound/soc/sh/siu.h
+++ b/sound/soc/sh/siu.h
@@ -169,7 +169,7 @@ static inline u32 siu_read32(u32 __iomem
#define SIU_BRGBSEL(0x108 / sizeof(u32))
#define SIU_BRRB (0x10c / sizeof(u32))
-extern struct snd_soc_component_driver siu_component;
+extern const struct snd_soc_component_driver siu_component;
extern struct siu_info *siu_i2s_data;
int siu_init_port(int port, struct siu_port **port_info, struct snd_card
*card);
--- a/sound/soc/sh/siu_pcm.c
+++ b/sound/soc/sh/siu_pcm.c
@@ -543,7 +543,7 @@ static void siu_pcm_free(struct snd_soc_
dev_dbg(pcm->card->dev, "%s\n", __func__);
}
-struct const snd_soc_component_driver siu_component = {
+const struct snd_soc_component_driver siu_component = {
.name = DRV_NAME,
.open = siu_pcm_open,
.close = siu_pcm_close,
Re: [PATCH for 5.10] powerpc/32: Preserve cr1 in exception prolog stack check to fix build error
On Tue, Feb 23, 2021 at 03:39:20PM +0100, Christophe Leroy wrote:
>
>
> Le 15/02/2021 à 15:30, Greg KH a écrit :
> > On Fri, Feb 12, 2021 at 08:57:14AM +, Christophe Leroy wrote:
> > > This is backport of 3642eb21256a ("powerpc/32: Preserve cr1 in
> > > exception prolog stack check to fix build error") for kernel 5.10
> > >
> > > It fixes the build failure on v5.10 reported by kernel test robot
> > > and by David Michael.
> > >
> > > This fix is not in Linux tree yet, it is in next branch in powerpc tree.
> >
> > Then there's nothing I can do about it until that happens :(
> >
>
> It now is in Linus' tree, see
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3642eb21256a317ac14e9ed560242c6d20cf06d9
Now queued up, thanks.
greg k-h
Re: [PATCH RESEND v2 1/2] cpu/hotplug: Fix build error of using {add,remove}_cpu() with !CONFIG_SMP
On 02/21/21 21:43, shuo.a@intel.com wrote:
> From: Shuo Liu
>
> 279dcf693ac7 ("virt: acrn: Introduce an interface for Service VM to
> control vCPU") introduced {add,remove}_cpu() usage and it hit below
> error with !CONFIG_SMP:
>
> ../drivers/virt/acrn/hsm.c: In function ‘remove_cpu_store’:
> ../drivers/virt/acrn/hsm.c:389:3: error: implicit declaration of function
> ‘remove_cpu’; [-Werror=implicit-function-declaration]
>remove_cpu(cpu);
>
> ../drivers/virt/acrn/hsm.c:402:2: error: implicit declaration of function
> ‘add_cpu’; [-Werror=implicit-function-declaration]
>add_cpu(cpu);
>
> Add add_cpu() function prototypes with !CONFIG_SMP and remove_cpu() with
> !CONFIG_HOTPLUG_CPU for such usage.
>
> Fixes: 279dcf693ac7 ("virt: acrn: Introduce an interface for Service VM to
> control vCPU")
> Reported-by: Randy Dunlap
> Signed-off-by: Shuo Liu
> Acked-by: Randy Dunlap # build-tested
> Cc: Stephen Rothwell
> Cc: Thomas Gleixner
> Cc: Greg Kroah-Hartman
> Cc: Qais Yousef
> ---
Reviewed-by: Qais Yousef
Thanks!
--
Qais Yousef
> include/linux/cpu.h | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/include/linux/cpu.h b/include/linux/cpu.h
> index 3aaa0687e8df..94a578a96202 100644
> --- a/include/linux/cpu.h
> +++ b/include/linux/cpu.h
> @@ -108,6 +108,8 @@ static inline void cpu_maps_update_done(void)
> {
> }
>
> +static inline int add_cpu(unsigned int cpu) { return 0;}
> +
> #endif /* CONFIG_SMP */
> extern struct bus_type cpu_subsys;
>
> @@ -137,6 +139,7 @@ static inline int cpus_read_trylock(void) { return true;
> }
> static inline void lockdep_assert_cpus_held(void) { }
> static inline void cpu_hotplug_disable(void) { }
> static inline void cpu_hotplug_enable(void) { }
> +static inline int remove_cpu(unsigned int cpu) { return -EPERM; }
> static inline void smp_shutdown_nonboot_cpus(unsigned int primary_cpu) { }
> #endif /* !CONFIG_HOTPLUG_CPU */
>
>
> base-commit: abaf6f60176f1ae9d946d63e4db63164600b7b1a
> --
> 2.28.0
>
Re: [PATCH for 5.10] powerpc/32: Preserve cr1 in exception prolog stack check to fix build error
Le 15/02/2021 à 15:30, Greg KH a écrit :
On Fri, Feb 12, 2021 at 08:57:14AM +, Christophe Leroy wrote:
This is backport of 3642eb21256a ("powerpc/32: Preserve cr1 in
exception prolog stack check to fix build error") for kernel 5.10
It fixes the build failure on v5.10 reported by kernel test robot
and by David Michael.
This fix is not in Linux tree yet, it is in next branch in powerpc tree.
Then there's nothing I can do about it until that happens :(
It now is in Linus' tree, see
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3642eb21256a317ac14e9ed560242c6d20cf06d9
Thanks
Christophe
[PATCH RESEND v2 1/2] cpu/hotplug: Fix build error of using {add,remove}_cpu() with !CONFIG_SMP
From: Shuo Liu
279dcf693ac7 ("virt: acrn: Introduce an interface for Service VM to
control vCPU") introduced {add,remove}_cpu() usage and it hit below
error with !CONFIG_SMP:
../drivers/virt/acrn/hsm.c: In function ‘remove_cpu_store’:
../drivers/virt/acrn/hsm.c:389:3: error: implicit declaration of function
‘remove_cpu’; [-Werror=implicit-function-declaration]
remove_cpu(cpu);
../drivers/virt/acrn/hsm.c:402:2: error: implicit declaration of function
‘add_cpu’; [-Werror=implicit-function-declaration]
add_cpu(cpu);
Add add_cpu() function prototypes with !CONFIG_SMP and remove_cpu() with
!CONFIG_HOTPLUG_CPU for such usage.
Fixes: 279dcf693ac7 ("virt: acrn: Introduce an interface for Service VM to
control vCPU")
Reported-by: Randy Dunlap
Signed-off-by: Shuo Liu
Acked-by: Randy Dunlap # build-tested
Cc: Stephen Rothwell
Cc: Thomas Gleixner
Cc: Greg Kroah-Hartman
Cc: Qais Yousef
---
include/linux/cpu.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/include/linux/cpu.h b/include/linux/cpu.h
index 3aaa0687e8df..94a578a96202 100644
--- a/include/linux/cpu.h
+++ b/include/linux/cpu.h
@@ -108,6 +108,8 @@ static inline void cpu_maps_update_done(void)
{
}
+static inline int add_cpu(unsigned int cpu) { return 0;}
+
#endif /* CONFIG_SMP */
extern struct bus_type cpu_subsys;
@@ -137,6 +139,7 @@ static inline int cpus_read_trylock(void) { return true; }
static inline void lockdep_assert_cpus_held(void) { }
static inline void cpu_hotplug_disable(void) { }
static inline void cpu_hotplug_enable(void) { }
+static inline int remove_cpu(unsigned int cpu) { return -EPERM; }
static inline void smp_shutdown_nonboot_cpus(unsigned int primary_cpu) { }
#endif /* !CONFIG_HOTPLUG_CPU */
base-commit: abaf6f60176f1ae9d946d63e4db63164600b7b1a
--
2.28.0
Re: [PATCH v5] perf tools: Fix arm64 build error with gcc-11
Em Thu, Feb 18, 2021 at 09:26:17AM +, John Garry escreveu: > On 18/02/2021 03:12, Jianlin Lv wrote: > > gcc version: 11.0.0 20210208 (experimental) (GCC) > > > > Following build error on arm64: > > > > ... > > In function ‘printf’, > > inlined from ‘regs_dump__printf’ at util/session.c:1141:3, > > inlined from ‘regs__printf’ at util/session.c:1169:2: > > /usr/include/aarch64-linux-gnu/bits/stdio2.h:107:10: \ > >error: ‘%-5s’ directive argument is null [-Werror=format-overflow=] > > > > 107 | return __printf_chk (__USE_FORTIFY_LEVEL - 1, __fmt, \ > > __va_arg_pack ()); > > > > .. > > In function ‘fprintf’, > >inlined from ‘perf_sample__fprintf_regs.isra’ at \ > > builtin-script.c:622:14: > > /usr/include/aarch64-linux-gnu/bits/stdio2.h:100:10: \ > > error: ‘%5s’ directive argument is null [-Werror=format-overflow=] > >100 | return __fprintf_chk (__stream, __USE_FORTIFY_LEVEL - 1, __fmt, > >101 | __va_arg_pack ()); > > > > cc1: all warnings being treated as errors > > ... > > > > This patch fixes Wformat-overflow warnings. Add helper function to > > convert NULL to "unknown". > > > > Signed-off-by: Jianlin Lv > > thanks > Reviewed-by: John Garry Thanks, applied. - Arnaldo
Re: [PATCH v5] perf tools: Fix arm64 build error with gcc-11
On 18/02/2021 03:12, Jianlin Lv wrote: gcc version: 11.0.0 20210208 (experimental) (GCC) Following build error on arm64: ... In function ‘printf’, inlined from ‘regs_dump__printf’ at util/session.c:1141:3, inlined from ‘regs__printf’ at util/session.c:1169:2: /usr/include/aarch64-linux-gnu/bits/stdio2.h:107:10: \ error: ‘%-5s’ directive argument is null [-Werror=format-overflow=] 107 | return __printf_chk (__USE_FORTIFY_LEVEL - 1, __fmt, \ __va_arg_pack ()); .. In function ‘fprintf’, inlined from ‘perf_sample__fprintf_regs.isra’ at \ builtin-script.c:622:14: /usr/include/aarch64-linux-gnu/bits/stdio2.h:100:10: \ error: ‘%5s’ directive argument is null [-Werror=format-overflow=] 100 | return __fprintf_chk (__stream, __USE_FORTIFY_LEVEL - 1, __fmt, 101 | __va_arg_pack ()); cc1: all warnings being treated as errors ... This patch fixes Wformat-overflow warnings. Add helper function to convert NULL to "unknown". Signed-off-by: Jianlin Lv thanks Reviewed-by: John Garry
[PATCH v5] perf tools: Fix arm64 build error with gcc-11
gcc version: 11.0.0 20210208 (experimental) (GCC)
Following build error on arm64:
...
In function ‘printf’,
inlined from ‘regs_dump__printf’ at util/session.c:1141:3,
inlined from ‘regs__printf’ at util/session.c:1169:2:
/usr/include/aarch64-linux-gnu/bits/stdio2.h:107:10: \
error: ‘%-5s’ directive argument is null [-Werror=format-overflow=]
107 | return __printf_chk (__USE_FORTIFY_LEVEL - 1, __fmt, \
__va_arg_pack ());
..
In function ‘fprintf’,
inlined from ‘perf_sample__fprintf_regs.isra’ at \
builtin-script.c:622:14:
/usr/include/aarch64-linux-gnu/bits/stdio2.h:100:10: \
error: ‘%5s’ directive argument is null [-Werror=format-overflow=]
100 | return __fprintf_chk (__stream, __USE_FORTIFY_LEVEL - 1, __fmt,
101 | __va_arg_pack ());
cc1: all warnings being treated as errors
...
This patch fixes Wformat-overflow warnings. Add helper function to
convert NULL to "unknown".
Signed-off-by: Jianlin Lv
---
v2: Add ternary operator to avoid similar errors in other arch.
v3: Declared reg_name in inner block.
v4: Add helper function: perf_reg_name_str, update changelog.
v5: Correct function names to follow common naming conventions.
---
tools/perf/arch/arm/include/perf_regs.h | 2 +-
tools/perf/arch/arm64/include/perf_regs.h | 2 +-
tools/perf/arch/csky/include/perf_regs.h| 2 +-
tools/perf/arch/powerpc/include/perf_regs.h | 2 +-
tools/perf/arch/riscv/include/perf_regs.h | 2 +-
tools/perf/arch/s390/include/perf_regs.h| 2 +-
tools/perf/arch/x86/include/perf_regs.h | 2 +-
tools/perf/util/perf_regs.h | 7 +++
8 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/tools/perf/arch/arm/include/perf_regs.h
b/tools/perf/arch/arm/include/perf_regs.h
index ed20e0253e25..4085419283d0 100644
--- a/tools/perf/arch/arm/include/perf_regs.h
+++ b/tools/perf/arch/arm/include/perf_regs.h
@@ -15,7 +15,7 @@ void perf_regs_load(u64 *regs);
#define PERF_REG_IPPERF_REG_ARM_PC
#define PERF_REG_SPPERF_REG_ARM_SP
-static inline const char *perf_reg_name(int id)
+static inline const char *__perf_reg_name(int id)
{
switch (id) {
case PERF_REG_ARM_R0:
diff --git a/tools/perf/arch/arm64/include/perf_regs.h
b/tools/perf/arch/arm64/include/perf_regs.h
index baaa5e64a3fb..fa3e07459f76 100644
--- a/tools/perf/arch/arm64/include/perf_regs.h
+++ b/tools/perf/arch/arm64/include/perf_regs.h
@@ -15,7 +15,7 @@ void perf_regs_load(u64 *regs);
#define PERF_REG_IPPERF_REG_ARM64_PC
#define PERF_REG_SPPERF_REG_ARM64_SP
-static inline const char *perf_reg_name(int id)
+static inline const char *__perf_reg_name(int id)
{
switch (id) {
case PERF_REG_ARM64_X0:
diff --git a/tools/perf/arch/csky/include/perf_regs.h
b/tools/perf/arch/csky/include/perf_regs.h
index 8f336ea1161a..25ac3bdcb9d1 100644
--- a/tools/perf/arch/csky/include/perf_regs.h
+++ b/tools/perf/arch/csky/include/perf_regs.h
@@ -15,7 +15,7 @@
#define PERF_REG_IPPERF_REG_CSKY_PC
#define PERF_REG_SPPERF_REG_CSKY_SP
-static inline const char *perf_reg_name(int id)
+static inline const char *__perf_reg_name(int id)
{
switch (id) {
case PERF_REG_CSKY_A0:
diff --git a/tools/perf/arch/powerpc/include/perf_regs.h
b/tools/perf/arch/powerpc/include/perf_regs.h
index 63f3ac91049f..004bed228693 100644
--- a/tools/perf/arch/powerpc/include/perf_regs.h
+++ b/tools/perf/arch/powerpc/include/perf_regs.h
@@ -73,7 +73,7 @@ static const char *reg_names[] = {
[PERF_REG_POWERPC_SIER3] = "sier3",
};
-static inline const char *perf_reg_name(int id)
+static inline const char *__perf_reg_name(int id)
{
return reg_names[id];
}
diff --git a/tools/perf/arch/riscv/include/perf_regs.h
b/tools/perf/arch/riscv/include/perf_regs.h
index 7a8bcde7a2b1..6b02a767c918 100644
--- a/tools/perf/arch/riscv/include/perf_regs.h
+++ b/tools/perf/arch/riscv/include/perf_regs.h
@@ -19,7 +19,7 @@
#define PERF_REG_IPPERF_REG_RISCV_PC
#define PERF_REG_SPPERF_REG_RISCV_SP
-static inline const char *perf_reg_name(int id)
+static inline const char *__perf_reg_name(int id)
{
switch (id) {
case PERF_REG_RISCV_PC:
diff --git a/tools/perf/arch/s390/include/perf_regs.h
b/tools/perf/arch/s390/include/perf_regs.h
index bcfbaed78cc2..ce3031526623 100644
--- a/tools/perf/arch/s390/include/perf_regs.h
+++ b/tools/perf/arch/s390/include/perf_regs.h
@@ -14,7 +14,7 @@ void perf_regs_load(u64 *regs);
#define PERF_REG_IP PERF_REG_S390_PC
#define PERF_REG_SP PERF_REG_S390_R15
-static inline const char *perf_reg_name(int id)
+static inline const char *__perf_reg_name(int id)
{
switch (id) {
case PERF_REG_S390_R0:
diff --git a/tools/perf/arch/x86/include/perf_regs.h
b/tools/perf/arch/x86/include/perf_regs.h
index b7321337d100..cddc4cdc0d9b 100644
--- a/tools/perf/arch/x86/include/perf_regs.h
+++ b/tools/perf/arch/x86/include/perf_regs.h
@@
Re: [PATCH v4] perf tools: Fix arm64 build error with gcc-11
Em Wed, Feb 17, 2021 at 07:58:30PM +0800, Jianlin Lv escreveu:
> gcc version: 11.0.0 20210208 (experimental) (GCC)
>
> Following build error on arm64:
>
> ...
> In function ‘printf’,
> inlined from ‘regs_dump__printf’ at util/session.c:1141:3,
> inlined from ‘regs__printf’ at util/session.c:1169:2:
> /usr/include/aarch64-linux-gnu/bits/stdio2.h:107:10: \
> error: ‘%-5s’ directive argument is null [-Werror=format-overflow=]
>
> 107 | return __printf_chk (__USE_FORTIFY_LEVEL - 1, __fmt, \
> __va_arg_pack ());
>
> ..
> In function ‘fprintf’,
> inlined from ‘perf_sample__fprintf_regs.isra’ at \
> builtin-script.c:622:14:
> /usr/include/aarch64-linux-gnu/bits/stdio2.h:100:10: \
> error: ‘%5s’ directive argument is null [-Werror=format-overflow=]
> 100 | return __fprintf_chk (__stream, __USE_FORTIFY_LEVEL - 1, __fmt,
> 101 | __va_arg_pack ());
>
> cc1: all warnings being treated as errors
> ...
>
> This patch fixes Wformat-overflow warnings. Add helper function to
> convert NULL to "unknown".
I think this is the right approach, but since both return a string, it
is strange that only one of them have its _str() at the end, what we
usually do in such cases is to have:
const char *__perf_reg_name(int id)
{
return NULL if id unknown;
}
And:
static inline const char *perf_reg_name(int id)
{
const char *name = __perf_reg_name(id);
return name ?: "unknown";
}
Ok?
- Arnaldo
> Signed-off-by: Jianlin Lv
> ---
> v2: Add ternary operator to avoid similar errors in other arch.
> v3: Declared reg_name in inner block.
> v4: Add helper function: perf_reg_name_str, update changelog.
> ---
> tools/perf/builtin-script.c | 2 +-
> tools/perf/util/perf_regs.h | 11 ++-
> .../perf/util/scripting-engines/trace-event-python.c | 2 +-
> tools/perf/util/session.c | 2 +-
> 4 files changed, 13 insertions(+), 4 deletions(-)
>
> diff --git a/tools/perf/builtin-script.c b/tools/perf/builtin-script.c
> index 42dad4a0f8cf..35cddca2c7a7 100644
> --- a/tools/perf/builtin-script.c
> +++ b/tools/perf/builtin-script.c
> @@ -643,7 +643,7 @@ static int perf_sample__fprintf_regs(struct regs_dump
> *regs, uint64_t mask,
>
> for_each_set_bit(r, (unsigned long *) &mask, sizeof(mask) * 8) {
> u64 val = regs->regs[i++];
> - printed += fprintf(fp, "%5s:0x%"PRIx64" ", perf_reg_name(r),
> val);
> + printed += fprintf(fp, "%5s:0x%"PRIx64" ",
> perf_reg_name_str(r), val);
> }
>
> return printed;
> diff --git a/tools/perf/util/perf_regs.h b/tools/perf/util/perf_regs.h
> index a45499126184..e4a0a6f5408e 100644
> --- a/tools/perf/util/perf_regs.h
> +++ b/tools/perf/util/perf_regs.h
> @@ -33,13 +33,22 @@ extern const struct sample_reg sample_reg_masks[];
>
> int perf_reg_value(u64 *valp, struct regs_dump *regs, int id);
>
> +static inline const char *perf_reg_name_str(int id)
> +{
> + const char *str = perf_reg_name(id);
> +
> + if (!str)
> + return "unknown";
> + return str;
> +}
> +
> #else
> #define PERF_REGS_MASK 0
> #define PERF_REGS_MAX0
>
> #define DWARF_MINIMAL_REGS PERF_REGS_MASK
>
> -static inline const char *perf_reg_name(int id __maybe_unused)
> +static inline const char *perf_reg_name_str(int id __maybe_unused)
> {
> return "unknown";
> }
> diff --git a/tools/perf/util/scripting-engines/trace-event-python.c
> b/tools/perf/util/scripting-engines/trace-event-python.c
> index c83c2c6564e0..361307026485 100644
> --- a/tools/perf/util/scripting-engines/trace-event-python.c
> +++ b/tools/perf/util/scripting-engines/trace-event-python.c
> @@ -702,7 +702,7 @@ static int regs_map(struct regs_dump *regs, uint64_t
> mask, char *bf, int size)
>
> printed += scnprintf(bf + printed, size - printed,
>"%5s:0x%" PRIx64 " ",
> - perf_reg_name(r), val);
> + perf_reg_name_str(r), val);
> }
>
> return printed;
> diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c
> index 25adbcce0281..0737d3e7e698 100644
> --- a/tools/perf/util/session.c
> +++ b/tools/perf/util/session.c
> @@ -1140,7 +1140,7 @@ static void regs_dump__printf(u64 mask, u64 *regs)
> u64 val = regs[i++];
>
> printf(" %-5s 0x%016" PRIx64 "\n",
> -perf_reg_name(rid), val);
> +perf_reg_name_str(rid), val);
> }
> }
>
> --
> 2.25.1
>
--
- Arnaldo
[PATCH v4] perf tools: Fix arm64 build error with gcc-11
gcc version: 11.0.0 20210208 (experimental) (GCC)
Following build error on arm64:
...
In function ‘printf’,
inlined from ‘regs_dump__printf’ at util/session.c:1141:3,
inlined from ‘regs__printf’ at util/session.c:1169:2:
/usr/include/aarch64-linux-gnu/bits/stdio2.h:107:10: \
error: ‘%-5s’ directive argument is null [-Werror=format-overflow=]
107 | return __printf_chk (__USE_FORTIFY_LEVEL - 1, __fmt, \
__va_arg_pack ());
..
In function ‘fprintf’,
inlined from ‘perf_sample__fprintf_regs.isra’ at \
builtin-script.c:622:14:
/usr/include/aarch64-linux-gnu/bits/stdio2.h:100:10: \
error: ‘%5s’ directive argument is null [-Werror=format-overflow=]
100 | return __fprintf_chk (__stream, __USE_FORTIFY_LEVEL - 1, __fmt,
101 | __va_arg_pack ());
cc1: all warnings being treated as errors
...
This patch fixes Wformat-overflow warnings. Add helper function to
convert NULL to "unknown".
Signed-off-by: Jianlin Lv
---
v2: Add ternary operator to avoid similar errors in other arch.
v3: Declared reg_name in inner block.
v4: Add helper function: perf_reg_name_str, update changelog.
---
tools/perf/builtin-script.c | 2 +-
tools/perf/util/perf_regs.h | 11 ++-
.../perf/util/scripting-engines/trace-event-python.c | 2 +-
tools/perf/util/session.c | 2 +-
4 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/tools/perf/builtin-script.c b/tools/perf/builtin-script.c
index 42dad4a0f8cf..35cddca2c7a7 100644
--- a/tools/perf/builtin-script.c
+++ b/tools/perf/builtin-script.c
@@ -643,7 +643,7 @@ static int perf_sample__fprintf_regs(struct regs_dump
*regs, uint64_t mask,
for_each_set_bit(r, (unsigned long *) &mask, sizeof(mask) * 8) {
u64 val = regs->regs[i++];
- printed += fprintf(fp, "%5s:0x%"PRIx64" ", perf_reg_name(r),
val);
+ printed += fprintf(fp, "%5s:0x%"PRIx64" ",
perf_reg_name_str(r), val);
}
return printed;
diff --git a/tools/perf/util/perf_regs.h b/tools/perf/util/perf_regs.h
index a45499126184..e4a0a6f5408e 100644
--- a/tools/perf/util/perf_regs.h
+++ b/tools/perf/util/perf_regs.h
@@ -33,13 +33,22 @@ extern const struct sample_reg sample_reg_masks[];
int perf_reg_value(u64 *valp, struct regs_dump *regs, int id);
+static inline const char *perf_reg_name_str(int id)
+{
+ const char *str = perf_reg_name(id);
+
+ if (!str)
+ return "unknown";
+ return str;
+}
+
#else
#define PERF_REGS_MASK 0
#define PERF_REGS_MAX 0
#define DWARF_MINIMAL_REGS PERF_REGS_MASK
-static inline const char *perf_reg_name(int id __maybe_unused)
+static inline const char *perf_reg_name_str(int id __maybe_unused)
{
return "unknown";
}
diff --git a/tools/perf/util/scripting-engines/trace-event-python.c
b/tools/perf/util/scripting-engines/trace-event-python.c
index c83c2c6564e0..361307026485 100644
--- a/tools/perf/util/scripting-engines/trace-event-python.c
+++ b/tools/perf/util/scripting-engines/trace-event-python.c
@@ -702,7 +702,7 @@ static int regs_map(struct regs_dump *regs, uint64_t mask,
char *bf, int size)
printed += scnprintf(bf + printed, size - printed,
"%5s:0x%" PRIx64 " ",
-perf_reg_name(r), val);
+perf_reg_name_str(r), val);
}
return printed;
diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c
index 25adbcce0281..0737d3e7e698 100644
--- a/tools/perf/util/session.c
+++ b/tools/perf/util/session.c
@@ -1140,7 +1140,7 @@ static void regs_dump__printf(u64 mask, u64 *regs)
u64 val = regs[i++];
printf(" %-5s 0x%016" PRIx64 "\n",
- perf_reg_name(rid), val);
+ perf_reg_name_str(rid), val);
}
}
--
2.25.1
Re: [PATCH v3] perf tools: Fix arm64 build error with gcc-11
---
tools/perf/builtin-script.c| 4 +++-
tools/perf/util/scripting-engines/trace-event-python.c | 3 ++-
tools/perf/util/session.c | 3 ++-
3 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/tools/perf/builtin-script.c b/tools/perf/builtin-script.c
index 42dad4a0f8cf..0d52dc45b1c7 100644
--- a/tools/perf/builtin-script.c
+++ b/tools/perf/builtin-script.c
@@ -643,7 +643,9 @@ static int perf_sample__fprintf_regs(struct regs_dump
*regs, uint64_t mask,
for_each_set_bit(r, (unsigned long *) &mask, sizeof(mask) * 8) {
u64 val = regs->regs[i++];
- printed += fprintf(fp, "%5s:0x%"PRIx64" ", perf_reg_name(r),
val);
+ const char *reg_name = perf_reg_name(r);
+
+ printed += fprintf(fp, "%5s:0x%"PRIx64" ", reg_name ?:
"unknown", val);
}
return printed;
diff --git a/tools/perf/util/scripting-engines/trace-event-python.c
b/tools/perf/util/scripting-engines/trace-event-python.c
index c83c2c6564e0..768bdd4240f4 100644
--- a/tools/perf/util/scripting-engines/trace-event-python.c
+++ b/tools/perf/util/scripting-engines/trace-event-python.c
@@ -699,10 +699,11 @@ static int regs_map(struct regs_dump *regs, uint64_t
mask, char *bf, int size)
for_each_set_bit(r, (unsigned long *) &mask, sizeof(mask) * 8) {
u64 val = regs->regs[i++];
+ const char *reg_name = perf_reg_name(r);
printed += scnprintf(bf + printed, size - printed,
"%5s:0x%" PRIx64 " ",
-perf_reg_name(r), val);
+reg_name ?: "unknown", val);
what I was trying to suggest previously was to add a small helper
function for this, like:
--- >8
diff --git a/tools/perf/util/perf_regs.h b/tools/perf/util/perf_regs.h
index a45499126184..2663daf4122c 100644
--- a/tools/perf/util/perf_regs.h
+++ b/tools/perf/util/perf_regs.h
@@ -28,18 +28,25 @@ uint64_t arch__user_reg_mask(void);
extern const struct sample_reg sample_reg_masks[];
#include
#define DWARF_MINIMAL_REGS ((1ULL << PERF_REG_IP) | (1ULL << PERF_REG_SP))
int perf_reg_value(u64 *valp, struct regs_dump *regs, int id);
+static inline const char *perf_reg_name_str(int id)
+{
+ const char *str = perf_reg_name(id);
+ if (!str)
+ return "unknown";
+ return str;
+}
+
#else
#define PERF_REGS_MASK 0
#define PERF_REGS_MAX 0
#define DWARF_MINIMAL_REGS PERF_REGS_MASK
-static inline const char *perf_reg_name(int id __maybe_unused)
+static inline const char *perf_reg_name_str(int id __maybe_unused)
{
return "unknown";
}
8<
So if someone were to make a change to use perf_reg_name() directly
later and do not compile with gcc-11, then they may break the build.
Hence the helper.
No big deal, though.
}
return printed;
diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c
index 25adbcce0281..2b40f1c431a3 100644
--- a/tools/perf/util/session.c
+++ b/tools/perf/util/session.c
@@ -1138,9 +1138,10 @@ static void regs_dump__printf(u64 mask, u64 *regs)
for_each_set_bit(rid, (unsigned long *) &mask, sizeof(mask) * 8) {
u64 val = regs[i++];
+ const char *reg_name = perf_reg_name(rid);
printf(" %-5s 0x%016" PRIx64 "\n",
- perf_reg_name(rid), val);
+ reg_name ?: "unknown", val);
}
}
--
2.25.1
.
[PATCH 5.10 051/104] ath9k: fix build error with LEDS_CLASS=m
From: Arnd Bergmann
[ Upstream commit b64acb28da8394485f0762e657470c9fc33aca4d ]
When CONFIG_ATH9K is built-in but LED support is in a loadable
module, both ath9k drivers fails to link:
x86_64-linux-ld: drivers/net/wireless/ath/ath9k/gpio.o: in function
`ath_deinit_leds':
gpio.c:(.text+0x36): undefined reference to `led_classdev_unregister'
x86_64-linux-ld: drivers/net/wireless/ath/ath9k/gpio.o: in function
`ath_init_leds':
gpio.c:(.text+0x179): undefined reference to `led_classdev_register_ext'
The problem is that the 'imply' keyword does not enforce any dependency
but is only a weak hint to Kconfig to enable another symbol from a
defconfig file.
Change imply to a 'depends on LEDS_CLASS' that prevents the incorrect
configuration but still allows building the driver without LED support.
The 'select MAC80211_LEDS' is now ensures that the LED support is
actually used if it is present, and the added Kconfig dependency
on MAC80211_LEDS ensures that it cannot be enabled manually when it
has no effect.
Fixes: 197f466e93f5 ("ath9k_htc: Do not select MAC80211_LEDS by default")
Signed-off-by: Arnd Bergmann
Acked-by: Johannes Berg
Signed-off-by: Kalle Valo
Link: https://lore.kernel.org/r/20210125113654.2408057-1-a...@kernel.org
Signed-off-by: Sasha Levin
---
drivers/net/wireless/ath/ath9k/Kconfig | 8 ++--
net/mac80211/Kconfig | 2 +-
2 files changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/Kconfig
b/drivers/net/wireless/ath/ath9k/Kconfig
index a84bb9b6573f8..e150d82eddb6c 100644
--- a/drivers/net/wireless/ath/ath9k/Kconfig
+++ b/drivers/net/wireless/ath/ath9k/Kconfig
@@ -21,11 +21,9 @@ config ATH9K_BTCOEX_SUPPORT
config ATH9K
tristate "Atheros 802.11n wireless cards support"
depends on MAC80211 && HAS_DMA
+ select MAC80211_LEDS if LEDS_CLASS=y || LEDS_CLASS=MAC80211
select ATH9K_HW
select ATH9K_COMMON
- imply NEW_LEDS
- imply LEDS_CLASS
- imply MAC80211_LEDS
help
This module adds support for wireless adapters based on
Atheros IEEE 802.11n AR5008, AR9001 and AR9002 family
@@ -176,11 +174,9 @@ config ATH9K_PCI_NO_EEPROM
config ATH9K_HTC
tristate "Atheros HTC based wireless cards support"
depends on USB && MAC80211
+ select MAC80211_LEDS if LEDS_CLASS=y || LEDS_CLASS=MAC80211
select ATH9K_HW
select ATH9K_COMMON
- imply NEW_LEDS
- imply LEDS_CLASS
- imply MAC80211_LEDS
help
Support for Atheros HTC based cards.
Chipsets supported: AR9271
diff --git a/net/mac80211/Kconfig b/net/mac80211/Kconfig
index cd9a9bd242bab..51ec8256b7fa9 100644
--- a/net/mac80211/Kconfig
+++ b/net/mac80211/Kconfig
@@ -69,7 +69,7 @@ config MAC80211_MESH
config MAC80211_LEDS
bool "Enable LED triggers"
depends on MAC80211
- depends on LEDS_CLASS
+ depends on LEDS_CLASS=y || LEDS_CLASS=MAC80211
select LEDS_TRIGGERS
help
This option enables a few LED triggers for different
--
2.27.0
Re: [PATCH for 5.10] powerpc/32: Preserve cr1 in exception prolog stack check to fix build error
On Fri, Feb 12, 2021 at 08:57:14AM +, Christophe Leroy wrote:
> This is backport of 3642eb21256a ("powerpc/32: Preserve cr1 in
> exception prolog stack check to fix build error") for kernel 5.10
>
> It fixes the build failure on v5.10 reported by kernel test robot
> and by David Michael.
>
> This fix is not in Linux tree yet, it is in next branch in powerpc tree.
Then there's nothing I can do about it until that happens :(
Re: [PATCH v3] perf tools: Fix arm64 build error with gcc-11
On Sat, Feb 13, 2021 at 01:05:16PM +0800, Jianlin Lv wrote:
> gcc version: 11.0.0 20210208 (experimental) (GCC)
>
> Following build error on arm64:
>
> ...
> In function ‘printf’,
> inlined from ‘regs_dump__printf’ at util/session.c:1141:3,
> inlined from ‘regs__printf’ at util/session.c:1169:2:
> /usr/include/aarch64-linux-gnu/bits/stdio2.h:107:10: \
> error: ‘%-5s’ directive argument is null [-Werror=format-overflow=]
>
> 107 | return __printf_chk (__USE_FORTIFY_LEVEL - 1, __fmt, \
> __va_arg_pack ());
>
> ..
> In function ‘fprintf’,
> inlined from ‘perf_sample__fprintf_regs.isra’ at \
> builtin-script.c:622:14:
> /usr/include/aarch64-linux-gnu/bits/stdio2.h:100:10: \
> error: ‘%5s’ directive argument is null [-Werror=format-overflow=]
> 100 | return __fprintf_chk (__stream, __USE_FORTIFY_LEVEL - 1, __fmt,
> 101 | __va_arg_pack ());
>
> cc1: all warnings being treated as errors
> ...
>
> This patch fixes Wformat-overflow warnings. Add ternary operator,
> The statement evaluates to "Unknown" if reg_name==NULL is met.
>
> Signed-off-by: Jianlin Lv
Acked-by: Jiri Olsa
thanks,
jirka
> ---
> v2: Add ternary operator to avoid similar errors in other arch.
> v3: Declared reg_name in inner block.
> ---
> tools/perf/builtin-script.c| 4 +++-
> tools/perf/util/scripting-engines/trace-event-python.c | 3 ++-
> tools/perf/util/session.c | 3 ++-
> 3 files changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/tools/perf/builtin-script.c b/tools/perf/builtin-script.c
> index 42dad4a0f8cf..0d52dc45b1c7 100644
> --- a/tools/perf/builtin-script.c
> +++ b/tools/perf/builtin-script.c
> @@ -643,7 +643,9 @@ static int perf_sample__fprintf_regs(struct regs_dump
> *regs, uint64_t mask,
>
> for_each_set_bit(r, (unsigned long *) &mask, sizeof(mask) * 8) {
> u64 val = regs->regs[i++];
> - printed += fprintf(fp, "%5s:0x%"PRIx64" ", perf_reg_name(r),
> val);
> + const char *reg_name = perf_reg_name(r);
> +
> + printed += fprintf(fp, "%5s:0x%"PRIx64" ", reg_name ?:
> "unknown", val);
> }
>
> return printed;
> diff --git a/tools/perf/util/scripting-engines/trace-event-python.c
> b/tools/perf/util/scripting-engines/trace-event-python.c
> index c83c2c6564e0..768bdd4240f4 100644
> --- a/tools/perf/util/scripting-engines/trace-event-python.c
> +++ b/tools/perf/util/scripting-engines/trace-event-python.c
> @@ -699,10 +699,11 @@ static int regs_map(struct regs_dump *regs, uint64_t
> mask, char *bf, int size)
>
> for_each_set_bit(r, (unsigned long *) &mask, sizeof(mask) * 8) {
> u64 val = regs->regs[i++];
> + const char *reg_name = perf_reg_name(r);
>
> printed += scnprintf(bf + printed, size - printed,
>"%5s:0x%" PRIx64 " ",
> - perf_reg_name(r), val);
> + reg_name ?: "unknown", val);
> }
>
> return printed;
> diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c
> index 25adbcce0281..2b40f1c431a3 100644
> --- a/tools/perf/util/session.c
> +++ b/tools/perf/util/session.c
> @@ -1138,9 +1138,10 @@ static void regs_dump__printf(u64 mask, u64 *regs)
>
> for_each_set_bit(rid, (unsigned long *) &mask, sizeof(mask) * 8) {
> u64 val = regs[i++];
> + const char *reg_name = perf_reg_name(rid);
>
> printf(" %-5s 0x%016" PRIx64 "\n",
> -perf_reg_name(rid), val);
> +reg_name ?: "unknown", val);
> }
> }
>
> --
> 2.25.1
>
[PATCH v3] perf tools: Fix arm64 build error with gcc-11
gcc version: 11.0.0 20210208 (experimental) (GCC)
Following build error on arm64:
...
In function ‘printf’,
inlined from ‘regs_dump__printf’ at util/session.c:1141:3,
inlined from ‘regs__printf’ at util/session.c:1169:2:
/usr/include/aarch64-linux-gnu/bits/stdio2.h:107:10: \
error: ‘%-5s’ directive argument is null [-Werror=format-overflow=]
107 | return __printf_chk (__USE_FORTIFY_LEVEL - 1, __fmt, \
__va_arg_pack ());
..
In function ‘fprintf’,
inlined from ‘perf_sample__fprintf_regs.isra’ at \
builtin-script.c:622:14:
/usr/include/aarch64-linux-gnu/bits/stdio2.h:100:10: \
error: ‘%5s’ directive argument is null [-Werror=format-overflow=]
100 | return __fprintf_chk (__stream, __USE_FORTIFY_LEVEL - 1, __fmt,
101 | __va_arg_pack ());
cc1: all warnings being treated as errors
...
This patch fixes Wformat-overflow warnings. Add ternary operator,
The statement evaluates to "Unknown" if reg_name==NULL is met.
Signed-off-by: Jianlin Lv
---
v2: Add ternary operator to avoid similar errors in other arch.
v3: Declared reg_name in inner block.
---
tools/perf/builtin-script.c| 4 +++-
tools/perf/util/scripting-engines/trace-event-python.c | 3 ++-
tools/perf/util/session.c | 3 ++-
3 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/tools/perf/builtin-script.c b/tools/perf/builtin-script.c
index 42dad4a0f8cf..0d52dc45b1c7 100644
--- a/tools/perf/builtin-script.c
+++ b/tools/perf/builtin-script.c
@@ -643,7 +643,9 @@ static int perf_sample__fprintf_regs(struct regs_dump
*regs, uint64_t mask,
for_each_set_bit(r, (unsigned long *) &mask, sizeof(mask) * 8) {
u64 val = regs->regs[i++];
- printed += fprintf(fp, "%5s:0x%"PRIx64" ", perf_reg_name(r),
val);
+ const char *reg_name = perf_reg_name(r);
+
+ printed += fprintf(fp, "%5s:0x%"PRIx64" ", reg_name ?:
"unknown", val);
}
return printed;
diff --git a/tools/perf/util/scripting-engines/trace-event-python.c
b/tools/perf/util/scripting-engines/trace-event-python.c
index c83c2c6564e0..768bdd4240f4 100644
--- a/tools/perf/util/scripting-engines/trace-event-python.c
+++ b/tools/perf/util/scripting-engines/trace-event-python.c
@@ -699,10 +699,11 @@ static int regs_map(struct regs_dump *regs, uint64_t
mask, char *bf, int size)
for_each_set_bit(r, (unsigned long *) &mask, sizeof(mask) * 8) {
u64 val = regs->regs[i++];
+ const char *reg_name = perf_reg_name(r);
printed += scnprintf(bf + printed, size - printed,
"%5s:0x%" PRIx64 " ",
-perf_reg_name(r), val);
+reg_name ?: "unknown", val);
}
return printed;
diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c
index 25adbcce0281..2b40f1c431a3 100644
--- a/tools/perf/util/session.c
+++ b/tools/perf/util/session.c
@@ -1138,9 +1138,10 @@ static void regs_dump__printf(u64 mask, u64 *regs)
for_each_set_bit(rid, (unsigned long *) &mask, sizeof(mask) * 8) {
u64 val = regs[i++];
+ const char *reg_name = perf_reg_name(rid);
printf(" %-5s 0x%016" PRIx64 "\n",
- perf_reg_name(rid), val);
+ reg_name ?: "unknown", val);
}
}
--
2.25.1
Re: [PATCH v2 1/2] cpu/hotplug: Fix build error of using {add,remove}_cpu() with !CONFIG_SMP
On 2/12/21 8:55 AM, shuo.a@intel.com wrote:
> From: Shuo Liu
>
> 279dcf693ac7 ("virt: acrn: Introduce an interface for Service VM to
> control vCPU") introduced {add,remove}_cpu() usage and it hit below
> error with !CONFIG_SMP:
>
> ../drivers/virt/acrn/hsm.c: In function ‘remove_cpu_store’:
> ../drivers/virt/acrn/hsm.c:389:3: error: implicit declaration of function
> ‘remove_cpu’; [-Werror=implicit-function-declaration]
>remove_cpu(cpu);
>
> ../drivers/virt/acrn/hsm.c:402:2: error: implicit declaration of function
> ‘add_cpu’; [-Werror=implicit-function-declaration]
>add_cpu(cpu);
>
> Add add_cpu() function prototypes with !CONFIG_SMP and remove_cpu() with
> !CONFIG_HOTPLUG_CPU for such usage.
>
> Fixes: 279dcf693ac7 ("virt: acrn: Introduce an interface for Service VM to
> control vCPU")
> Reported-by: Randy Dunlap
> Signed-off-by: Shuo Liu
> ---
> I followed Greg's idea that add {add,remove}_cpu() functions prototypes.
> The v2 solution is different from the v1, so i removed Randy's Acked-by.
> Randy, please help have a look on v2.
>
> v2:
> - Drop the #ifdef in .c solution. Add {add,remove}_cpu() prototypes.
> (Suggested by Greg)
>
> include/linux/cpu.h | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/include/linux/cpu.h b/include/linux/cpu.h
> index 3aaa0687e8df..94a578a96202 100644
> --- a/include/linux/cpu.h
> +++ b/include/linux/cpu.h
> @@ -108,6 +108,8 @@ static inline void cpu_maps_update_done(void)
> {
> }
>
> +static inline int add_cpu(unsigned int cpu) { return 0;}
> +
> #endif /* CONFIG_SMP */
> extern struct bus_type cpu_subsys;
>
> @@ -137,6 +139,7 @@ static inline int cpus_read_trylock(void) { return true;
> }
> static inline void lockdep_assert_cpus_held(void) { }
> static inline void cpu_hotplug_disable(void) { }
> static inline void cpu_hotplug_enable(void) { }
> +static inline int remove_cpu(unsigned int cpu) { return -EPERM; }
I would have done: return 0;
Anyway:
Acked-by: Randy Dunlap # build-tested
> static inline void smp_shutdown_nonboot_cpus(unsigned int primary_cpu) { }
> #endif /* !CONFIG_HOTPLUG_CPU */
thanks.
--
~Randy
[PATCH v2 1/2] cpu/hotplug: Fix build error of using {add,remove}_cpu() with !CONFIG_SMP
From: Shuo Liu
279dcf693ac7 ("virt: acrn: Introduce an interface for Service VM to
control vCPU") introduced {add,remove}_cpu() usage and it hit below
error with !CONFIG_SMP:
../drivers/virt/acrn/hsm.c: In function ‘remove_cpu_store’:
../drivers/virt/acrn/hsm.c:389:3: error: implicit declaration of function
‘remove_cpu’; [-Werror=implicit-function-declaration]
remove_cpu(cpu);
../drivers/virt/acrn/hsm.c:402:2: error: implicit declaration of function
‘add_cpu’; [-Werror=implicit-function-declaration]
add_cpu(cpu);
Add add_cpu() function prototypes with !CONFIG_SMP and remove_cpu() with
!CONFIG_HOTPLUG_CPU for such usage.
Fixes: 279dcf693ac7 ("virt: acrn: Introduce an interface for Service VM to
control vCPU")
Reported-by: Randy Dunlap
Signed-off-by: Shuo Liu
---
I followed Greg's idea that add {add,remove}_cpu() functions prototypes.
The v2 solution is different from the v1, so i removed Randy's Acked-by.
Randy, please help have a look on v2.
v2:
- Drop the #ifdef in .c solution. Add {add,remove}_cpu() prototypes.
(Suggested by Greg)
include/linux/cpu.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/include/linux/cpu.h b/include/linux/cpu.h
index 3aaa0687e8df..94a578a96202 100644
--- a/include/linux/cpu.h
+++ b/include/linux/cpu.h
@@ -108,6 +108,8 @@ static inline void cpu_maps_update_done(void)
{
}
+static inline int add_cpu(unsigned int cpu) { return 0;}
+
#endif /* CONFIG_SMP */
extern struct bus_type cpu_subsys;
@@ -137,6 +139,7 @@ static inline int cpus_read_trylock(void) { return true; }
static inline void lockdep_assert_cpus_held(void) { }
static inline void cpu_hotplug_disable(void) { }
static inline void cpu_hotplug_enable(void) { }
+static inline int remove_cpu(unsigned int cpu) { return -EPERM; }
static inline void smp_shutdown_nonboot_cpus(unsigned int primary_cpu) { }
#endif /* !CONFIG_HOTPLUG_CPU */
base-commit: 671176b0016c80b3943cb5387312c886aba3308d
--
2.28.0
Re: [PATCH] virt: acrn: Fix vCPU removing code build error
On Fri 12.Feb'21 at 12:02:18 +0100, Greg Kroah-Hartman wrote:
On Fri, Feb 12, 2021 at 06:58:53PM +0800, Shuo A Liu wrote:
Hi Greg,
On Fri 12.Feb'21 at 8:52:33 +0100, Greg Kroah-Hartman wrote:
> On Fri, Feb 12, 2021 at 12:57:24PM +0800, shuo.a@intel.com wrote:
> > From: Shuo Liu
> >
> > vCPU removing code depends on CONFIG_HOTPLUG_CPU as it uses remove_cpu()
> > and add_cpu(). Make the vCPU removing interface building with
> > CONFIG_HOTPLUG_CPU.
> >
> > ../drivers/virt/acrn/hsm.c: In function ‘remove_cpu_store’:
> > ../drivers/virt/acrn/hsm.c:389:3: error: implicit declaration of function
‘remove_cpu’; [-Werror=implicit-function-declaration]
> >remove_cpu(cpu);
> >
> > ../drivers/virt/acrn/hsm.c:402:2: error: implicit declaration of function
‘add_cpu’; [-Werror=implicit-function-declaration]
> >add_cpu(cpu);
> >
> > Fixes: 279dcf693ac7 ("virt: acrn: Introduce an interface for Service VM to
control vCPU")
> > Reported-by: Randy Dunlap
> > Acked-by: Randy Dunlap # build-tested
> > Signed-off-by: Shuo Liu
> > ---
> > drivers/virt/acrn/hsm.c | 4
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/drivers/virt/acrn/hsm.c b/drivers/virt/acrn/hsm.c
> > index 1f6b7c54a1a4..e340788aacdf 100644
> > --- a/drivers/virt/acrn/hsm.c
> > +++ b/drivers/virt/acrn/hsm.c
> > @@ -372,6 +372,7 @@ static int acrn_dev_release(struct inode *inode, struct
file *filp)
> > return 0;
> > }
> >
> > +#ifdef CONFIG_HOTPLUG_CPU
> > static ssize_t remove_cpu_store(struct device *dev,
> > struct device_attribute *attr,
> > const char *buf, size_t count)
> > @@ -403,9 +404,12 @@ static ssize_t remove_cpu_store(struct device *dev,
> > return ret;
> > }
> > static DEVICE_ATTR_WO(remove_cpu);
> > +#endif
> >
> > static struct attribute *acrn_attrs[] = {
> > +#ifdef CONFIG_HOTPLUG_CPU
> > &dev_attr_remove_cpu.attr,
> > +#endif
> > NULL
> > };
> >
> >
>
> Shouldn't the real solution for this be that remove_cpu() and add_cpu()
> have function prototypes for when this is not enabled in the kernel
> build?
Something like this in linux/cpu.h?
diff --git a/include/linux/cpu.h b/include/linux/cpu.h
index 3aaa0687e8df..94a578a96202 100644
--- a/include/linux/cpu.h
+++ b/include/linux/cpu.h
@@ -108,6 +108,8 @@ static inline void cpu_maps_update_done(void)
{
}
+static inline int add_cpu(unsigned int cpu) { return 0;}
+
#endif /* CONFIG_SMP */
extern struct bus_type cpu_subsys;
@@ -137,6 +139,7 @@ static inline int cpus_read_trylock(void) { return
true; }
static inline void lockdep_assert_cpus_held(void) { }
static inline void cpu_hotplug_disable(void) { }
static inline void cpu_hotplug_enable(void) { }
+static inline int remove_cpu(unsigned int cpu) { return -EPERM; }
static inline void smp_shutdown_nonboot_cpus(unsigned int primary_cpu)
{ }
#endif /* !CONFIG_HOTPLUG_CPU */
>
> Putting #ifdef in .c files like this is not a good idea at all.
>
> Then, at runtime, you can determine if you need to create this sysfs
> file or not, as you do not want to expose it to userspace if the kernel
> can not handle it, right?
Right. I don't want to expose the sysfs to userspace if the kernel built
w/o CONFIG_HOTPLUG_CPU. But how to implement that if #ifdef is not used?
misc_register() creates sysfs with .groups (acrn_attr_groups)
unconditionally, then userspace can see the interface even it doesn't
work.
Use the is_visible() callback for your attribute group.
Thanks for the guide, is_visible() is good. Seems good i can provide the
callback with
return IS_ENABLED(CONFIG_HOTPLUG_CPU);
Will update in v2.
Thanks
shuo
Re: [PATCH] virt: acrn: Fix vCPU removing code build error
On Fri, Feb 12, 2021 at 06:58:53PM +0800, Shuo A Liu wrote:
> Hi Greg,
>
> On Fri 12.Feb'21 at 8:52:33 +0100, Greg Kroah-Hartman wrote:
> > On Fri, Feb 12, 2021 at 12:57:24PM +0800, shuo.a@intel.com wrote:
> > > From: Shuo Liu
> > >
> > > vCPU removing code depends on CONFIG_HOTPLUG_CPU as it uses remove_cpu()
> > > and add_cpu(). Make the vCPU removing interface building with
> > > CONFIG_HOTPLUG_CPU.
> > >
> > > ../drivers/virt/acrn/hsm.c: In function ‘remove_cpu_store’:
> > > ../drivers/virt/acrn/hsm.c:389:3: error: implicit declaration of function
> > > ‘remove_cpu’; [-Werror=implicit-function-declaration]
> > >remove_cpu(cpu);
> > >
> > > ../drivers/virt/acrn/hsm.c:402:2: error: implicit declaration of function
> > > ‘add_cpu’; [-Werror=implicit-function-declaration]
> > >add_cpu(cpu);
> > >
> > > Fixes: 279dcf693ac7 ("virt: acrn: Introduce an interface for Service VM
> > > to control vCPU")
> > > Reported-by: Randy Dunlap
> > > Acked-by: Randy Dunlap # build-tested
> > > Signed-off-by: Shuo Liu
> > > ---
> > > drivers/virt/acrn/hsm.c | 4
> > > 1 file changed, 4 insertions(+)
> > >
> > > diff --git a/drivers/virt/acrn/hsm.c b/drivers/virt/acrn/hsm.c
> > > index 1f6b7c54a1a4..e340788aacdf 100644
> > > --- a/drivers/virt/acrn/hsm.c
> > > +++ b/drivers/virt/acrn/hsm.c
> > > @@ -372,6 +372,7 @@ static int acrn_dev_release(struct inode *inode,
> > > struct file *filp)
> > > return 0;
> > > }
> > >
> > > +#ifdef CONFIG_HOTPLUG_CPU
> > > static ssize_t remove_cpu_store(struct device *dev,
> > > struct device_attribute *attr,
> > > const char *buf, size_t count)
> > > @@ -403,9 +404,12 @@ static ssize_t remove_cpu_store(struct device *dev,
> > > return ret;
> > > }
> > > static DEVICE_ATTR_WO(remove_cpu);
> > > +#endif
> > >
> > > static struct attribute *acrn_attrs[] = {
> > > +#ifdef CONFIG_HOTPLUG_CPU
> > > &dev_attr_remove_cpu.attr,
> > > +#endif
> > > NULL
> > > };
> > >
> > >
> >
> > Shouldn't the real solution for this be that remove_cpu() and add_cpu()
> > have function prototypes for when this is not enabled in the kernel
> > build?
>
> Something like this in linux/cpu.h?
>
> diff --git a/include/linux/cpu.h b/include/linux/cpu.h
> index 3aaa0687e8df..94a578a96202 100644
> --- a/include/linux/cpu.h
> +++ b/include/linux/cpu.h
> @@ -108,6 +108,8 @@ static inline void cpu_maps_update_done(void)
> {
> }
>
> +static inline int add_cpu(unsigned int cpu) { return 0;}
> +
> #endif /* CONFIG_SMP */
> extern struct bus_type cpu_subsys;
>
> @@ -137,6 +139,7 @@ static inline int cpus_read_trylock(void) { return
> true; }
> static inline void lockdep_assert_cpus_held(void) { }
> static inline void cpu_hotplug_disable(void) { }
> static inline void cpu_hotplug_enable(void) { }
> +static inline int remove_cpu(unsigned int cpu) { return -EPERM; }
> static inline void smp_shutdown_nonboot_cpus(unsigned int primary_cpu)
> { }
> #endif /* !CONFIG_HOTPLUG_CPU */
>
>
> >
> > Putting #ifdef in .c files like this is not a good idea at all.
> >
> > Then, at runtime, you can determine if you need to create this sysfs
> > file or not, as you do not want to expose it to userspace if the kernel
> > can not handle it, right?
>
> Right. I don't want to expose the sysfs to userspace if the kernel built
> w/o CONFIG_HOTPLUG_CPU. But how to implement that if #ifdef is not used?
> misc_register() creates sysfs with .groups (acrn_attr_groups)
> unconditionally, then userspace can see the interface even it doesn't
> work.
Use the is_visible() callback for your attribute group.
thanks,
greg k-h
Re: [PATCH] virt: acrn: Fix vCPU removing code build error
Hi Greg,
On Fri 12.Feb'21 at 8:52:33 +0100, Greg Kroah-Hartman wrote:
On Fri, Feb 12, 2021 at 12:57:24PM +0800, shuo.a@intel.com wrote:
From: Shuo Liu
vCPU removing code depends on CONFIG_HOTPLUG_CPU as it uses remove_cpu()
and add_cpu(). Make the vCPU removing interface building with
CONFIG_HOTPLUG_CPU.
../drivers/virt/acrn/hsm.c: In function ‘remove_cpu_store’:
../drivers/virt/acrn/hsm.c:389:3: error: implicit declaration of function
‘remove_cpu’; [-Werror=implicit-function-declaration]
remove_cpu(cpu);
../drivers/virt/acrn/hsm.c:402:2: error: implicit declaration of function
‘add_cpu’; [-Werror=implicit-function-declaration]
add_cpu(cpu);
Fixes: 279dcf693ac7 ("virt: acrn: Introduce an interface for Service VM to control
vCPU")
Reported-by: Randy Dunlap
Acked-by: Randy Dunlap # build-tested
Signed-off-by: Shuo Liu
---
drivers/virt/acrn/hsm.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/virt/acrn/hsm.c b/drivers/virt/acrn/hsm.c
index 1f6b7c54a1a4..e340788aacdf 100644
--- a/drivers/virt/acrn/hsm.c
+++ b/drivers/virt/acrn/hsm.c
@@ -372,6 +372,7 @@ static int acrn_dev_release(struct inode *inode, struct
file *filp)
return 0;
}
+#ifdef CONFIG_HOTPLUG_CPU
static ssize_t remove_cpu_store(struct device *dev,
struct device_attribute *attr,
const char *buf, size_t count)
@@ -403,9 +404,12 @@ static ssize_t remove_cpu_store(struct device *dev,
return ret;
}
static DEVICE_ATTR_WO(remove_cpu);
+#endif
static struct attribute *acrn_attrs[] = {
+#ifdef CONFIG_HOTPLUG_CPU
&dev_attr_remove_cpu.attr,
+#endif
NULL
};
Shouldn't the real solution for this be that remove_cpu() and add_cpu()
have function prototypes for when this is not enabled in the kernel
build?
Something like this in linux/cpu.h?
diff --git a/include/linux/cpu.h b/include/linux/cpu.h
index 3aaa0687e8df..94a578a96202 100644
--- a/include/linux/cpu.h
+++ b/include/linux/cpu.h
@@ -108,6 +108,8 @@ static inline void cpu_maps_update_done(void)
{
}
+static inline int add_cpu(unsigned int cpu) { return 0;}
+
#endif /* CONFIG_SMP */
extern struct bus_type cpu_subsys;
@@ -137,6 +139,7 @@ static inline int cpus_read_trylock(void) { return
true; }
static inline void lockdep_assert_cpus_held(void) { }
static inline void cpu_hotplug_disable(void) { }
static inline void cpu_hotplug_enable(void) { }
+static inline int remove_cpu(unsigned int cpu) { return -EPERM; }
static inline void smp_shutdown_nonboot_cpus(unsigned int primary_cpu)
{ }
#endif /* !CONFIG_HOTPLUG_CPU */
Putting #ifdef in .c files like this is not a good idea at all.
Then, at runtime, you can determine if you need to create this sysfs
file or not, as you do not want to expose it to userspace if the kernel
can not handle it, right?
Right. I don't want to expose the sysfs to userspace if the kernel built
w/o CONFIG_HOTPLUG_CPU. But how to implement that if #ifdef is not used?
misc_register() creates sysfs with .groups (acrn_attr_groups)
unconditionally, then userspace can see the interface even it doesn't
work.
Thanks
shuo
[PATCH for 5.10] powerpc/32: Preserve cr1 in exception prolog stack check to fix build error
This is backport of 3642eb21256a ("powerpc/32: Preserve cr1 in
exception prolog stack check to fix build error") for kernel 5.10
It fixes the build failure on v5.10 reported by kernel test robot
and by David Michael.
This fix is not in Linux tree yet, it is in next branch in powerpc tree.
(cherry picked from commit 3642eb21256a317ac14e9ed560242c6d20cf06d9)
THREAD_ALIGN_SHIFT = THREAD_SHIFT + 1 = PAGE_SHIFT + 1
Maximum PAGE_SHIFT is 18 for 256k pages so
THREAD_ALIGN_SHIFT is 19 at the maximum.
No need to clobber cr1, it can be preserved when moving r1
into CR when we check stack overflow.
This reduces the number of instructions in Machine Check Exception
prolog and fixes a build failure reported by the kernel test robot
on v5.10 stable when building with RTAS + VMAP_STACK + KVM. That
build failure is due to too many instructions in the prolog hence
not fitting between 0x200 and 0x300. Allthough the problem doesn't
show up in mainline, it is still worth the change.
Fixes: 98bf2d3f4970 ("powerpc/32s: Fix RTAS machine check with VMAP stack")
Cc: sta...@vger.kernel.org
Reported-by: kernel test robot
Signed-off-by: Christophe Leroy
Signed-off-by: Michael Ellerman
Link:
https://lore.kernel.org/r/5ae4d545e3ac58e133d2599e0deb88843cb494fc.1612768623.git.christophe.le...@csgroup.eu
---
arch/powerpc/kernel/head_32.h| 2 +-
arch/powerpc/kernel/head_book3s_32.S | 6 --
2 files changed, 1 insertion(+), 7 deletions(-)
diff --git a/arch/powerpc/kernel/head_32.h b/arch/powerpc/kernel/head_32.h
index c88e66adecb5..fef0b34a77c9 100644
--- a/arch/powerpc/kernel/head_32.h
+++ b/arch/powerpc/kernel/head_32.h
@@ -56,7 +56,7 @@
1:
tophys_novmstack r11, r11
#ifdef CONFIG_VMAP_STACK
- mtcrf 0x7f, r1
+ mtcrf 0x3f, r1
bt 32 - THREAD_ALIGN_SHIFT, stack_overflow
#endif
.endm
diff --git a/arch/powerpc/kernel/head_book3s_32.S
b/arch/powerpc/kernel/head_book3s_32.S
index d66da35f2e8d..2729d8fa6e77 100644
--- a/arch/powerpc/kernel/head_book3s_32.S
+++ b/arch/powerpc/kernel/head_book3s_32.S
@@ -280,12 +280,6 @@ MachineCheck:
7: EXCEPTION_PROLOG_2
addir3,r1,STACK_FRAME_OVERHEAD
#ifdef CONFIG_PPC_CHRP
-#ifdef CONFIG_VMAP_STACK
- mfspr r4, SPRN_SPRG_THREAD
- tovirt(r4, r4)
- lwz r4, RTAS_SP(r4)
- cmpwi cr1, r4, 0
-#endif
beq cr1, machine_check_tramp
twi 31, 0, 0
#else
--
2.25.0
Re: [PATCH] virt: acrn: Fix vCPU removing code build error
On Fri, Feb 12, 2021 at 12:57:24PM +0800, shuo.a@intel.com wrote:
> From: Shuo Liu
>
> vCPU removing code depends on CONFIG_HOTPLUG_CPU as it uses remove_cpu()
> and add_cpu(). Make the vCPU removing interface building with
> CONFIG_HOTPLUG_CPU.
>
> ../drivers/virt/acrn/hsm.c: In function ‘remove_cpu_store’:
> ../drivers/virt/acrn/hsm.c:389:3: error: implicit declaration of function
> ‘remove_cpu’; [-Werror=implicit-function-declaration]
>remove_cpu(cpu);
>
> ../drivers/virt/acrn/hsm.c:402:2: error: implicit declaration of function
> ‘add_cpu’; [-Werror=implicit-function-declaration]
>add_cpu(cpu);
>
> Fixes: 279dcf693ac7 ("virt: acrn: Introduce an interface for Service VM to
> control vCPU")
> Reported-by: Randy Dunlap
> Acked-by: Randy Dunlap # build-tested
> Signed-off-by: Shuo Liu
> ---
> drivers/virt/acrn/hsm.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/virt/acrn/hsm.c b/drivers/virt/acrn/hsm.c
> index 1f6b7c54a1a4..e340788aacdf 100644
> --- a/drivers/virt/acrn/hsm.c
> +++ b/drivers/virt/acrn/hsm.c
> @@ -372,6 +372,7 @@ static int acrn_dev_release(struct inode *inode, struct
> file *filp)
> return 0;
> }
>
> +#ifdef CONFIG_HOTPLUG_CPU
> static ssize_t remove_cpu_store(struct device *dev,
> struct device_attribute *attr,
> const char *buf, size_t count)
> @@ -403,9 +404,12 @@ static ssize_t remove_cpu_store(struct device *dev,
> return ret;
> }
> static DEVICE_ATTR_WO(remove_cpu);
> +#endif
>
> static struct attribute *acrn_attrs[] = {
> +#ifdef CONFIG_HOTPLUG_CPU
> &dev_attr_remove_cpu.attr,
> +#endif
> NULL
> };
>
>
Shouldn't the real solution for this be that remove_cpu() and add_cpu()
have function prototypes for when this is not enabled in the kernel
build?
Putting #ifdef in .c files like this is not a good idea at all.
Then, at runtime, you can determine if you need to create this sysfs
file or not, as you do not want to expose it to userspace if the kernel
can not handle it, right?
thanks,
greg k-h
[PATCH] virt: acrn: Fix vCPU removing code build error
From: Shuo Liu
vCPU removing code depends on CONFIG_HOTPLUG_CPU as it uses remove_cpu()
and add_cpu(). Make the vCPU removing interface building with
CONFIG_HOTPLUG_CPU.
../drivers/virt/acrn/hsm.c: In function ‘remove_cpu_store’:
../drivers/virt/acrn/hsm.c:389:3: error: implicit declaration of function
‘remove_cpu’; [-Werror=implicit-function-declaration]
remove_cpu(cpu);
../drivers/virt/acrn/hsm.c:402:2: error: implicit declaration of function
‘add_cpu’; [-Werror=implicit-function-declaration]
add_cpu(cpu);
Fixes: 279dcf693ac7 ("virt: acrn: Introduce an interface for Service VM to
control vCPU")
Reported-by: Randy Dunlap
Acked-by: Randy Dunlap # build-tested
Signed-off-by: Shuo Liu
---
drivers/virt/acrn/hsm.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/virt/acrn/hsm.c b/drivers/virt/acrn/hsm.c
index 1f6b7c54a1a4..e340788aacdf 100644
--- a/drivers/virt/acrn/hsm.c
+++ b/drivers/virt/acrn/hsm.c
@@ -372,6 +372,7 @@ static int acrn_dev_release(struct inode *inode, struct
file *filp)
return 0;
}
+#ifdef CONFIG_HOTPLUG_CPU
static ssize_t remove_cpu_store(struct device *dev,
struct device_attribute *attr,
const char *buf, size_t count)
@@ -403,9 +404,12 @@ static ssize_t remove_cpu_store(struct device *dev,
return ret;
}
static DEVICE_ATTR_WO(remove_cpu);
+#endif
static struct attribute *acrn_attrs[] = {
+#ifdef CONFIG_HOTPLUG_CPU
&dev_attr_remove_cpu.attr,
+#endif
NULL
};
base-commit: 671176b0016c80b3943cb5387312c886aba3308d
--
2.28.0
Re: [PATCH] powerpc/32: Preserve cr1 in exception prolog stack check to fix build error
On Mon, 8 Feb 2021 07:17:40 + (UTC), Christophe Leroy wrote: > THREAD_ALIGN_SHIFT = THREAD_SHIFT + 1 = PAGE_SHIFT + 1 > Maximum PAGE_SHIFT is 18 for 256k pages so > THREAD_ALIGN_SHIFT is 19 at the maximum. > > No need to clobber cr1, it can be preserved when moving r1 > into CR when we check stack overflow. > > [...] Applied to powerpc/next. [1/1] powerpc/32: Preserve cr1 in exception prolog stack check to fix build error https://git.kernel.org/powerpc/c/3642eb21256a317ac14e9ed560242c6d20cf06d9 cheers
RE: [PATCH v2] perf tools: Fix arm64 build error with gcc-11
...
> > @@ -691,6 +691,7 @@ static int regs_map(struct regs_dump *regs, uint64_t
> > mask, char *bf, int size)
> > {
> > unsigned int i = 0, r;
> > int printed = 0;
> > + const char *reg_name;
> >
> > bf[0] = 0;
> >
> > @@ -700,9 +701,10 @@ static int regs_map(struct regs_dump *regs, uint64_t
> > mask, char *bf, int size)
> > for_each_set_bit(r, (unsigned long *) &mask, sizeof(mask) * 8) {
>
> a good practice is to limit scope of variables as much as possible, so
> reg_name could be declared here
I'd go for either function scope or a very small inner block
(like this one).
Otherwise it gets very difficult for the average human (or other
intelligent being) to locate the definition.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT,
UK
Registration No: 1397386 (Wales)
