On Mon, May 12, 2025 at 2:12 AM Saket Kumar Bhaskar wrote:
>
> On linux-next, build for bpf selftest displays an error due to
> mismatch in the expected function signature of bpf_testmod_test_read
> and bpf_testmod_test_write.
>
> Commit 97d06802d10a ("sysfs: constify bin_attribute argument of
>
On Tue, Jun 3, 2025 at 10:50 AM Song Liu wrote:
>
> On Tue, Jun 3, 2025 at 10:33 AM T.J. Mercier wrote:
> >
> > On Mon, May 12, 2025 at 2:12 AM Saket Kumar Bhaskar
> > wrote:
> > >
> > > On linux-next, build for bpf selftest displays an error due to
> > > mismatch in the expected function signa
On Tue, Jun 3, 2025 at 10:33 AM T.J. Mercier wrote:
>
> On Mon, May 12, 2025 at 2:12 AM Saket Kumar Bhaskar
> wrote:
> >
> > On linux-next, build for bpf selftest displays an error due to
> > mismatch in the expected function signature of bpf_testmod_test_read
> > and bpf_testmod_test_write.
> >
On Tue, Jun 3, 2025 at 10:33 AM T.J. Mercier wrote:
>
> On Mon, May 12, 2025 at 2:12 AM Saket Kumar Bhaskar
> wrote:
> >
> > On linux-next, build for bpf selftest displays an error due to
> > mismatch in the expected function signature of bpf_testmod_test_read
> > and bpf_testmod_test_write.
> >
On linux-next, build for bpf selftest displays an error due to
mismatch in the expected function signature of bpf_testmod_test_read
and bpf_testmod_test_write.
Commit 97d06802d10a ("sysfs: constify bin_attribute argument of
bin_attribute::read/write()")
changed the required type for struct bin_at
Hi Saket,
On Mon, 12 May 2025 10:55:59 +0530 Saket Kumar Bhaskar
wrote:
>
> Apologies for missing the Fixes tag. Would you like me to resend the patch
> with the
> Fixes tag included?
Yes, please, but send it to Greg (keeping the ccs) so that he can apply
it to the driver-core tree.
--
Che
On Sat, May 10, 2025 at 11:04:55AM +1000, Stephen Rothwell wrote:
> Hi Alexei,
>
> On Fri, 9 May 2025 10:04:18 -0700 Alexei Starovoitov
> wrote:
> >
> > On Fri, May 9, 2025 at 5:24 AM Saket Kumar Bhaskar
> > wrote:
> > >
> > > On linux-next, build for bpf selftest displays an error due to
> >
On 09/05/25 5:53 pm, Saket Kumar Bhaskar wrote:
On linux-next, build for bpf selftest displays an error due to
mismatch in the expected function signature of bpf_testmod_test_read
and bpf_testmod_test_write.
Commit 97d06802d10a ("sysfs: constify bin_attribute argument of
bin_attribute::read/w
Hi Alexei,
On Fri, 9 May 2025 10:04:18 -0700 Alexei Starovoitov
wrote:
>
> On Fri, May 9, 2025 at 5:24 AM Saket Kumar Bhaskar
> wrote:
> >
> > On linux-next, build for bpf selftest displays an error due to
> > mismatch in the expected function signature of bpf_testmod_test_read
> > and bpf_tes
On Fri, May 9, 2025 at 5:24 AM Saket Kumar Bhaskar wrote:
>
> On linux-next, build for bpf selftest displays an error due to
> mismatch in the expected function signature of bpf_testmod_test_read
> and bpf_testmod_test_write.
>
> Commit 97d06802d10a ("sysfs: constify bin_attribute argument of
> b
On linux-next, build for bpf selftest displays an error due to
mismatch in the expected function signature of bpf_testmod_test_read
and bpf_testmod_test_write.
Commit 97d06802d10a ("sysfs: constify bin_attribute argument of
bin_attribute::read/write()")
changed the required type for struct bin_at
.com
> >
> > scripts/gendwarfksyms/gendwarfksyms.h:6:10: fatal error: dwarf.h: No such
> > file or directory
>
> gendwarfksyms depends on libdw, so on a Debian system, I assume
> libdw-dev would be required to build with CONFIG_GENDWARFKSYMS.
Thanks!
Adding libdw-dev has indeed fixed the build error.
#syz invalid
>
> Sami
>
On Thu, Jan 30, 2025 at 5:20 AM syzbot
wrote:
>
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:a13f6e0f405e Add linux-next specific files for 20250130
> git tree: linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=10221ddf98
> kernel config: ht
Hello,
syzbot found the following issue on:
HEAD commit:a13f6e0f405e Add linux-next specific files for 20250130
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=10221ddf98
kernel config: https://syzkaller.appspot.com/x/.config?x=3445081dab63716c
dashbo
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.
Su
Wasn't this already submitted and commented on?
https://lore.kernel.org/all/20240919111841.20226-1-liaoy...@huawei.com/
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?
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
`__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
1 - 100 of 1880 matches
Mail list logo
