arm64: export this_cpu_has_cap
RFC PATCH 1/1 arm64: export this_cpu_has_cap
From: Arnd Bergmann <[email protected]>
It's now used in a coresight driver that can be a loadable module:
ERROR: modpost: "this_cpu_has_cap" [drivers/hwtracing/coresight/coresight-trbe.ko] undefined!
---
Not sure if we actually want this to be exported, this is my local workaround for the randconfig build bot.
--- arch/arm64/kernel/cpufeature.c | 1 + 1 file changed, 1 insertion(+)
arch/arm64/kernel/cpufeature.c +1 -0
@@ -2864,6 +2864,7 @@ bool this_cpu_has_cap(unsigned int n)return false; } +EXPORT_SYMBOL (this_cpu_has_cap);/* * This helper function is used in a narrow window when,
Signature · 1 line
2.29.2
Hi Arnd
Thanks for the fix.
Quoted 7 lines · Arnd Bergmann
From: Arnd Bergmann <[email protected]>
It's now used in a coresight driver that can be a loadable module:
ERROR: modpost: "
this_cpu_has_cap" [drivers/hwtracing/coresight/coresight-trbe.ko] undefined!Fixes 8a1065127d95 ("coresight: trbe: Add infrastructure for Errata handling")
Will, Catalin, Mathieu,
Do you have a preference on how this fix can be pulled in ? This may be safe to go via coresight tree if it is not too late. Otherwise, it could go via the arm64 tree.
Suzuki
Quoted 21 lines
Signed-off-by Arnd Bergmann <[email protected]>---
Not sure if we actually want this to be exported, this is my local workaround for the randconfig build bot.--- arch/arm64/kernel/cpufeature.c | 1 + 1 file changed, 1 insertion(+)arch/arm64/kernel/cpufeature.c +1
-0@@ -2864,6 +2864,7 @@ bool this_cpu_has_cap(unsigned int n)return false; } +EXPORT_SYMBOL (this_cpu_has_cap);/* * This helper function is used in a narrow window when,
Quoted 14 lines · Suzuki K Poulose
Hi Arnd
Thanks for the fix.
Quoted 7 lines · Arnd Bergmann
From: Arnd Bergmann <[email protected]>
It's now used in a coresight driver that can be a loadable module:
ERROR: modpost: "
this_cpu_has_cap" [drivers/hwtracing/coresight/coresight-trbe.ko] undefined!Fixes 8a1065127d95 ("coresight: trbe: Add infrastructure for Errata handling")
Quoted 8 lines
Reviewed-by Suzuki K Poulose <[email protected]>Tested-by Suzuki K Poulose <[email protected]>Will, Catalin, Mathieu,
Do you have a preference on how this fix can be pulled in ? This may be safe to go via coresight tree if it is not too late. Otherwise, it could go via the arm64 tree.
All the same to me. It's in arm64 so I'll let Will and Catalin have the final word.
Quoted 25 lines
Suzuki
Quoted 21 lines
Signed-off-by Arnd Bergmann <[email protected]>---
Not sure if we actually want this to be exported, this is my local workaround for the randconfig build bot.--- arch/arm64/kernel/cpufeature.c | 1 + 1 file changed, 1 insertion(+)arch/arm64/kernel/cpufeature.c +1
-0@@ -2864,6 +2864,7 @@ bool this_cpu_has_cap(unsigned int n)return false; } +EXPORT_SYMBOL (this_cpu_has_cap);/* * This helper function is used in a narrow window when,
Quoted 9 lines · Suzuki K Poulose
Quoted 7 lines · Arnd Bergmann
From: Arnd Bergmann <[email protected]>
It's now used in a coresight driver that can be a loadable module:
ERROR: modpost: "
this_cpu_has_cap" [drivers/hwtracing/coresight/coresight-trbe.ko] undefined!Fixes 8a1065127d95 ("coresight: trbe: Add infrastructure for Errata handling")
Quoted 8 lines
Reviewed-by Suzuki K Poulose <[email protected]>Tested-by Suzuki K Poulose <[email protected]>Will, Catalin, Mathieu,
Do you have a preference on how this fix can be pulled in ? This may be safe to go via coresight tree if it is not too late. Otherwise, it could go via the arm64 tree.
I think Will already closed/tagged the arm64 tree for the upcoming merging window, though he could take it as a fix afterwards.
If it doesn't conflict with the arm64 for-next/core, it's fine by me to go through the coresight tree.
Quoted 8 lines
Quoted 8 lines
Signed-off-by Arnd Bergmann <[email protected]>---
Not sure if we actually want this to be exported, this is my local workaround for the randconfig build bot.--- arch/arm64/kernel/cpufeature.c | 1 + 1 file changed, 1 insertion(+)
Quoted 8 lines
arch/arm64/kernel/cpufeature.c bool this_cpu_has_cap(unsigned int n) · line 2866
Quoted 8 lines
arch/arm64/kernel/cpufeature.c +1
-0@@ -2864,6 +2864,7 @@ bool this_cpu_has_cap(unsigned int n)return false; } +EXPORT_SYMBOL (this_cpu_has_cap);
EXPORT_SYMBOL_GPL? I think this_cpu_has_cap() is a bit more more specialised than cpus_have_const_cap().
With that:
Quoted 45 lines · Catalin Marinas
Quoted 9 lines · Suzuki K Poulose
Quoted 7 lines · Arnd Bergmann
From: Arnd Bergmann <[email protected]>
It's now used in a coresight driver that can be a loadable module:
ERROR: modpost: "
this_cpu_has_cap" [drivers/hwtracing/coresight/coresight-trbe.ko] undefined!Fixes 8a1065127d95 ("coresight: trbe: Add infrastructure for Errata handling")Quoted 8 lines
Reviewed-by Suzuki K Poulose <[email protected]>Tested-by Suzuki K Poulose <[email protected]>Will, Catalin, Mathieu,
Do you have a preference on how this fix can be pulled in ? This may be safe to go via coresight tree if it is not too late. Otherwise, it could go via the arm64 tree.
I think Will already closed/tagged the arm64 tree for the upcoming merging window, though he could take it as a fix afterwards.
If it doesn't conflict with the arm64 for-next/core, it's fine by me to go through the coresight tree.
Quoted 8 lines
Quoted 8 lines
Signed-off-by Arnd Bergmann <[email protected]>---
Not sure if we actually want this to be exported, this is my local workaround for the randconfig build bot.--- arch/arm64/kernel/cpufeature.c | 1 + 1 file changed, 1 insertion(+)Quoted 8 lines
arch/arm64/kernel/cpufeature.c bool this_cpu_has_cap(unsigned int n) · line 2866
Quoted 8 lines
arch/arm64/kernel/cpufeature.c +1
-0@@ -2864,6 +2864,7 @@ bool this_cpu_has_cap(unsigned int n)return false; } +EXPORT_SYMBOL (this_cpu_has_cap);
EXPORT_SYMBOL_GPL? I thinkthis_cpu_has_cap()is a bit more more specialised thancpus_have_const_cap().
Quoted 3 lines
With that:
Acked-by Catalin Marinas <[email protected]>
Yes, at this stage I think it's best for this to go via the Coresight tree. So with the _GPL export:
If that doesn't work for some reason, I can take it next week after the initial arm64 queue has been merged. Please just let me know.
Will
Hi Will
Quoted 50 lines · Will Deacon
Quoted 45 lines · Catalin Marinas
Quoted 9 lines · Suzuki K Poulose
Quoted 7 lines · Arnd Bergmann
From: Arnd Bergmann <[email protected]>
It's now used in a coresight driver that can be a loadable module:
ERROR: modpost: "
this_cpu_has_cap" [drivers/hwtracing/coresight/coresight-trbe.ko] undefined!Fixes 8a1065127d95 ("coresight: trbe: Add infrastructure for Errata handling")Quoted 8 lines
Reviewed-by Suzuki K Poulose <[email protected]>Tested-by Suzuki K Poulose <[email protected]>Will, Catalin, Mathieu,
Do you have a preference on how this fix can be pulled in ? This may be safe to go via coresight tree if it is not too late. Otherwise, it could go via the arm64 tree.
I think Will already closed/tagged the arm64 tree for the upcoming merging window, though he could take it as a fix afterwards.
If it doesn't conflict with the arm64 for-next/core, it's fine by me to go through the coresight tree.
Quoted 8 lines
Quoted 8 lines
Signed-off-by Arnd Bergmann <[email protected]>---
Not sure if we actually want this to be exported, this is my local workaround for the randconfig build bot.--- arch/arm64/kernel/cpufeature.c | 1 + 1 file changed, 1 insertion(+)Quoted 8 lines
arch/arm64/kernel/cpufeature.c bool this_cpu_has_cap(unsigned int n) · line 2866
Quoted 8 lines
arch/arm64/kernel/cpufeature.c +1
-0@@ -2864,6 +2864,7 @@ bool this_cpu_has_cap(unsigned int n)return false; } +EXPORT_SYMBOL (this_cpu_has_cap);
EXPORT_SYMBOL_GPL? I thinkthis_cpu_has_cap()is a bit more more specialised thancpus_have_const_cap().Quoted 3 lines
With that:
Acked-by Catalin Marinas <[email protected]>
Quoted 7 lines
Yes, at this stage I think it's best for this to go via the Coresight tree. So with the
_GPLexport:Acked-by Will Deacon <[email protected]>If that doesn't work for some reason, I can take it next week after the initial arm64 queue has been merged. Please just let me know.
As I understand correctly, this will now need to go via arm64 tree. The CoreSight tree changes are pulled into Greg's tree and the next it will happen is for the next release. Usually the fixes don't end up there during the -rc cycles. So, I believe it is better if this goes via arm64.
Suzuki
_______________________________________________
linux-arm-kernel mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Will Deacon
maintainerQuoted 56 lines · Suzuki K Poulose
Quoted 55 lines · Will Deacon
Quoted 45 lines · Catalin Marinas
Quoted 9 lines · Suzuki K Poulose
Quoted 7 lines · Arnd Bergmann
From: Arnd Bergmann <[email protected]>
It's now used in a coresight driver that can be a loadable module:
ERROR: modpost: "
this_cpu_has_cap" [drivers/hwtracing/coresight/coresight-trbe.ko] undefined!Fixes 8a1065127d95 ("coresight: trbe: Add infrastructure for Errata handling")Quoted 8 lines
Reviewed-by Suzuki K Poulose <[email protected]>Tested-by Suzuki K Poulose <[email protected]>Will, Catalin, Mathieu,
Do you have a preference on how this fix can be pulled in ? This may be safe to go via coresight tree if it is not too late. Otherwise, it could go via the arm64 tree.
I think Will already closed/tagged the arm64 tree for the upcoming merging window, though he could take it as a fix afterwards.
If it doesn't conflict with the arm64 for-next/core, it's fine by me to go through the coresight tree.
Quoted 8 lines
Quoted 8 lines
Signed-off-by Arnd Bergmann <[email protected]>---
Not sure if we actually want this to be exported, this is my local workaround for the randconfig build bot.--- arch/arm64/kernel/cpufeature.c | 1 + 1 file changed, 1 insertion(+)Quoted 8 lines
arch/arm64/kernel/cpufeature.c bool this_cpu_has_cap(unsigned int n) · line 2866
Quoted 8 lines
arch/arm64/kernel/cpufeature.c +1
-0@@ -2864,6 +2864,7 @@ bool this_cpu_has_cap(unsigned int n)return false; } +EXPORT_SYMBOL (this_cpu_has_cap);
EXPORT_SYMBOL_GPL? I thinkthis_cpu_has_cap()is a bit more more specialised thancpus_have_const_cap().Quoted 3 lines
With that:
Acked-by Catalin Marinas <[email protected]>Yes, at this stage I think it's best for this to go via the Coresight tree. So with the
_GPLexport:Acked-by Will Deacon <[email protected]>
Quoted 8 lines
Quoted 2 lines
If that doesn't work for some reason, I can take it next week after the initial arm64 queue has been merged. Please just let me know.
As I understand correctly, this will now need to go via arm64 tree. The CoreSight tree changes are pulled into Greg's tree and the next it will happen is for the next release. Usually the fixes don't end up there during the -rc cycles. So, I believe it is better if this goes via arm64.
Hmm, are you saying that Coresight drivers don't receive fixes outside of the merge window? That sounds sub-optimal...
But in any case, I'm happy to take this as long as it can wait until the second half of the merge window.
Will
_______________________________________________
linux-arm-kernel mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Quoted 60 lines · Will Deacon
Quoted 59 lines · Suzuki K Poulose
Quoted 57 lines · Will Deacon
Quoted 45 lines · Catalin Marinas
Quoted 9 lines · Suzuki K Poulose
Quoted 7 lines · Arnd Bergmann
From: Arnd Bergmann <[email protected]>
It's now used in a coresight driver that can be a loadable module:
ERROR: modpost: "
this_cpu_has_cap" [drivers/hwtracing/coresight/coresight-trbe.ko] undefined!Fixes 8a1065127d95 ("coresight: trbe: Add infrastructure for Errata handling")Quoted 8 lines
Reviewed-by Suzuki K Poulose <[email protected]>Tested-by Suzuki K Poulose <[email protected]>Will, Catalin, Mathieu,
Do you have a preference on how this fix can be pulled in ? This may be safe to go via coresight tree if it is not too late. Otherwise, it could go via the arm64 tree.
I think Will already closed/tagged the arm64 tree for the upcoming merging window, though he could take it as a fix afterwards.
If it doesn't conflict with the arm64 for-next/core, it's fine by me to go through the coresight tree.
Quoted 8 lines
Quoted 8 lines
Signed-off-by Arnd Bergmann <[email protected]>---
Not sure if we actually want this to be exported, this is my local workaround for the randconfig build bot.--- arch/arm64/kernel/cpufeature.c | 1 + 1 file changed, 1 insertion(+)Quoted 8 lines
arch/arm64/kernel/cpufeature.c bool this_cpu_has_cap(unsigned int n) · line 2866
Quoted 8 lines
arch/arm64/kernel/cpufeature.c +1
-0@@ -2864,6 +2864,7 @@ bool this_cpu_has_cap(unsigned int n)return false; } +EXPORT_SYMBOL (this_cpu_has_cap);
EXPORT_SYMBOL_GPL? I thinkthis_cpu_has_cap()is a bit more more specialised thancpus_have_const_cap().Quoted 3 lines
With that:
Acked-by Catalin Marinas <[email protected]>Yes, at this stage I think it's best for this to go via the Coresight tree. So with the
_GPLexport:Acked-by Will Deacon <[email protected]>If that doesn't work for some reason, I can take it next week after the initial arm64 queue has been merged. Please just let me know.
Quoted 8 lines
Quoted 5 lines
As I understand correctly, this will now need to go via arm64 tree. The CoreSight tree changes are pulled into Greg's tree and the next it will happen is for the next release. Usually the fixes don't end up there during the -rc cycles. So, I believe it is better if this goes via arm64.
Hmm, are you saying that Coresight drivers don't receive fixes outside of the merge window? That sounds sub-optimal...
Unfortunately thats how it works today. We should fix this.
Mathieu, Greg,
Do you have any thoughts on how to address this ?
Quoted 3 lines
But in any case, I'm happy to take this as long as it can wait until the second half of the merge window.
Yes, please. Thats the quickest path to merging this patch.
Suzuki
_______________________________________________
linux-arm-kernel mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Quoted 67 lines · Suzuki K Poulose
Quoted 66 lines · Will Deacon
Quoted 64 lines · Suzuki K Poulose
Quoted 50 lines · Will Deacon
Quoted 45 lines · Catalin Marinas
Quoted 9 lines · Suzuki K Poulose
Quoted 7 lines · Arnd Bergmann
From: Arnd Bergmann <[email protected]>
It's now used in a coresight driver that can be a loadable module:
ERROR: modpost: "
this_cpu_has_cap" [drivers/hwtracing/coresight/coresight-trbe.ko] undefined!Fixes 8a1065127d95 ("coresight: trbe: Add infrastructure for Errata handling")Quoted 8 lines
Reviewed-by Suzuki K Poulose <[email protected]>Tested-by Suzuki K Poulose <[email protected]>Will, Catalin, Mathieu,
Do you have a preference on how this fix can be pulled in ? This may be safe to go via coresight tree if it is not too late. Otherwise, it could go via the arm64 tree.
I think Will already closed/tagged the arm64 tree for the upcoming merging window, though he could take it as a fix afterwards.
If it doesn't conflict with the arm64 for-next/core, it's fine by me to go through the coresight tree.
Quoted 8 lines
Quoted 8 lines
Signed-off-by Arnd Bergmann <[email protected]>---
Not sure if we actually want this to be exported, this is my local workaround for the randconfig build bot.--- arch/arm64/kernel/cpufeature.c | 1 + 1 file changed, 1 insertion(+)Quoted 8 lines
arch/arm64/kernel/cpufeature.c bool this_cpu_has_cap(unsigned int n) · line 2866
Quoted 8 lines
arch/arm64/kernel/cpufeature.c +1
-0@@ -2864,6 +2864,7 @@ bool this_cpu_has_cap(unsigned int n)return false; } +EXPORT_SYMBOL (this_cpu_has_cap);
EXPORT_SYMBOL_GPL? I thinkthis_cpu_has_cap()is a bit more more specialised thancpus_have_const_cap().Quoted 3 lines
With that:
Acked-by Catalin Marinas <[email protected]>Quoted 7 lines
Yes, at this stage I think it's best for this to go via the Coresight tree. So with the
_GPLexport:Acked-by Will Deacon <[email protected]>If that doesn't work for some reason, I can take it next week after the initial arm64 queue has been merged. Please just let me know.
As I understand correctly, this will now need to go via arm64 tree. The CoreSight tree changes are pulled into Greg's tree and the next it will happen is for the next release. Usually the fixes don't end up there during the -rc cycles. So, I believe it is better if this goes via arm64.
Quoted 8 lines
Quoted 2 lines
Hmm, are you saying that Coresight drivers don't receive fixes outside of the merge window? That sounds sub-optimal...
Unfortunately thats how it works today. We should fix this.
Mathieu, Greg,
Do you have any thoughts on how to address this ?
What? That's crazy, if there are bugfixes needed of course I would take them during the -rc cycle, that is explicitly what it is there for!
It's up to the maintainer of the subsystem to send me the fixes to get into the -final kernel release, I don't pick them up on my own unless asked to by them.
thanks,
greg k-h
Quoted 72 lines · Greg Kroah-Hartman
Quoted 70 lines · Suzuki K Poulose
Quoted 68 lines · Will Deacon
Quoted 56 lines · Suzuki K Poulose
Quoted 55 lines · Will Deacon
Quoted 45 lines · Catalin Marinas
Quoted 9 lines · Suzuki K Poulose
Quoted 7 lines · Arnd Bergmann
From: Arnd Bergmann <[email protected]>
It's now used in a coresight driver that can be a loadable module:
ERROR: modpost: "
this_cpu_has_cap" [drivers/hwtracing/coresight/coresight-trbe.ko] undefined!Fixes 8a1065127d95 ("coresight: trbe: Add infrastructure for Errata handling")Quoted 8 lines
Reviewed-by Suzuki K Poulose <[email protected]>Tested-by Suzuki K Poulose <[email protected]>Will, Catalin, Mathieu,
Do you have a preference on how this fix can be pulled in ? This may be safe to go via coresight tree if it is not too late. Otherwise, it could go via the arm64 tree.
I think Will already closed/tagged the arm64 tree for the upcoming merging window, though he could take it as a fix afterwards.
If it doesn't conflict with the arm64 for-next/core, it's fine by me to go through the coresight tree.
Quoted 8 lines
Quoted 8 lines
Signed-off-by Arnd Bergmann <[email protected]>---
Not sure if we actually want this to be exported, this is my local workaround for the randconfig build bot.--- arch/arm64/kernel/cpufeature.c | 1 + 1 file changed, 1 insertion(+)Quoted 8 lines
arch/arm64/kernel/cpufeature.c bool this_cpu_has_cap(unsigned int n) · line 2866
Quoted 8 lines
arch/arm64/kernel/cpufeature.c +1
-0@@ -2864,6 +2864,7 @@ bool this_cpu_has_cap(unsigned int n)return false; } +EXPORT_SYMBOL (this_cpu_has_cap);
EXPORT_SYMBOL_GPL? I thinkthis_cpu_has_cap()is a bit more more specialised thancpus_have_const_cap().Quoted 3 lines
With that:
Acked-by Catalin Marinas <[email protected]>Yes, at this stage I think it's best for this to go via the Coresight tree. So with the
_GPLexport:Acked-by Will Deacon <[email protected]>Quoted 8 lines
Quoted 2 lines
If that doesn't work for some reason, I can take it next week after the initial arm64 queue has been merged. Please just let me know.
As I understand correctly, this will now need to go via arm64 tree. The CoreSight tree changes are pulled into Greg's tree and the next it will happen is for the next release. Usually the fixes don't end up there during the -rc cycles. So, I believe it is better if this goes via arm64.
Hmm, are you saying that Coresight drivers don't receive fixes outside of the merge window? That sounds sub-optimal...
Quoted 8 lines
Quoted 5 lines
Unfortunately thats how it works today. We should fix this.
Mathieu, Greg,
Do you have any thoughts on how to address this ?
What? That's crazy, if there are bugfixes needed of course I would take them during the -rc cycle, that is explicitly what it is there for!
I have sent patches to the char-misc tree several times during -rc cycles. As Greg points out, proceeding otherwise would not make sense.
Quoted 5 lines
It's up to the maintainer of the subsystem to send me the fixes to get into the -final kernel release, I don't pick them up on my own unless asked to by them.
I will send a pull request for this when I receive another patch with Catalin's annotation and collected RB tags.
Quoted 3 lines
thanks,
greg k-h
Arnd
Quoted 45 lines · Catalin Marinas
Quoted 9 lines · Suzuki K Poulose
Quoted 7 lines · Arnd Bergmann
From: Arnd Bergmann <[email protected]>
It's now used in a coresight driver that can be a loadable module:
ERROR: modpost: "
this_cpu_has_cap" [drivers/hwtracing/coresight/coresight-trbe.ko] undefined!Fixes 8a1065127d95 ("coresight: trbe: Add infrastructure for Errata handling")Quoted 8 lines
Reviewed-by Suzuki K Poulose <[email protected]>Tested-by Suzuki K Poulose <[email protected]>Will, Catalin, Mathieu,
Do you have a preference on how this fix can be pulled in ? This may be safe to go via coresight tree if it is not too late. Otherwise, it could go via the arm64 tree.
I think Will already closed/tagged the arm64 tree for the upcoming merging window, though he could take it as a fix afterwards.
If it doesn't conflict with the arm64 for-next/core, it's fine by me to go through the coresight tree.
Quoted 8 lines
Quoted 8 lines
Signed-off-by Arnd Bergmann <[email protected]>---
Not sure if we actually want this to be exported, this is my local workaround for the randconfig build bot.--- arch/arm64/kernel/cpufeature.c | 1 + 1 file changed, 1 insertion(+)Quoted 8 lines
arch/arm64/kernel/cpufeature.c bool this_cpu_has_cap(unsigned int n) · line 2866
Quoted 8 lines
arch/arm64/kernel/cpufeature.c +1
-0@@ -2864,6 +2864,7 @@ bool this_cpu_has_cap(unsigned int n)return false; } +EXPORT_SYMBOL (this_cpu_has_cap);
EXPORT_SYMBOL_GPL? I thinkthis_cpu_has_cap()is a bit more more specialised thancpus_have_const_cap().
Quoted 4 lines
With that:
Acked-by Catalin Marinas <[email protected]>
Do you plan to send an updated patch with above ?
Suzuki