`__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
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 ("ie
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.k
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.k
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.
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.
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.
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):
>
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 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
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.
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:
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
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'
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 Du
在 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/
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/
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&#x
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, Jish
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:
> > >
> > >
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
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: ./opte
> 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 TRAC
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
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
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
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
das
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 c
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: ./opte
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(TRAC
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
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:
> > >
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,
| ^
|
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
>
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 tak
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
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
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
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
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
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
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 |
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 ind
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:
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
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
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
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':
> drive
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 t
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
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 interface
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 functi
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_
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:
>
>
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 functi
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
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/
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
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 IOM
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
>>>
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_AM
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
>>
>
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 func
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:
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/
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: driver
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.
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
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
t 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
L
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
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
t; 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 br
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’:
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
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
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’,
> >
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
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
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 fro
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
---
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/too
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):
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
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 fro
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
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’:
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
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
> >
> > vC
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
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
CO
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 po
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 ‘r
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 f
o 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
...
> > @@ -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 *reg
linux.intel.com;
> jo...@redhat.com; namhy...@kernel.org; irog...@google.com;
> agerstm...@redhat.com; kan.li...@linux.intel.com;
> adrian.hun...@intel.com
> Cc: linux-kernel@vger.kernel.org
> Subject: Re: [PATCH v2] perf tools: Fix arm64 build error with gcc-11
>
> On 10/02/202
On 10/02/2021 03:24, 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
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
linux.intel.com;
> jo...@redhat.com; namhy...@kernel.org; linux-arm-
> ker...@lists.infradead.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] perf tools: Fix arm64 build error with gcc-11
>
> Hi Jianlin,
>
> On Tue, Feb 09, 2021 at 07:33:57PM +0800, Jianlin
1 - 100 of 1862 matches
Mail list logo
