* [linux-next:master 2890/4758] ld.lld: error: undefined symbol: phys_to_target_node
@ 2020-09-03 5:49 kernel test robot
2020-09-03 12:31 ` Joao Martins
0 siblings, 1 reply; 5+ messages in thread
From: kernel test robot @ 2020-09-03 5:49 UTC (permalink / raw)
To: Dan Williams
Cc: kbuild-all, clang-built-linux, Joao Martins, Andrew Morton,
Linux Memory Management List
[-- Attachment #1: Type: text/plain, Size: 1381 bytes --]
tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
head: 4442749a203151a319a5bb8d0b983b84253a6931
commit: bd295a352cfa24e5110a53f978edb48b7c21ff8f [2890/4758] ACPI: HMAT: attach a device for each soft-reserved range
config: x86_64-randconfig-a002-20200902 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project 224d8153b53b16cf535ea1a55afdfe1ec5b1374f)
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# install x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
git checkout bd295a352cfa24e5110a53f978edb48b7c21ff8f
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
>> ld.lld: error: undefined symbol: phys_to_target_node
>>> referenced by device.c:84 (drivers/dax/hmem/device.c:84)
>>> dax/hmem/device.o:(hmem_register_one) in archive drivers/built-in.a
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 29623 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [linux-next:master 2890/4758] ld.lld: error: undefined symbol: phys_to_target_node
2020-09-03 5:49 [linux-next:master 2890/4758] ld.lld: error: undefined symbol: phys_to_target_node kernel test robot
@ 2020-09-03 12:31 ` Joao Martins
2020-09-05 21:24 ` Randy Dunlap
0 siblings, 1 reply; 5+ messages in thread
From: Joao Martins @ 2020-09-03 12:31 UTC (permalink / raw)
To: Andrew Morton, Vishal Verma
Cc: kernel test robot, Dan Williams, kbuild-all, clang-built-linux,
Linux Memory Management List
On 9/3/20 6:49 AM, kernel test robot wrote:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
> head: 4442749a203151a319a5bb8d0b983b84253a6931
> commit: bd295a352cfa24e5110a53f978edb48b7c21ff8f [2890/4758] ACPI: HMAT: attach a device for each soft-reserved range
> config: x86_64-randconfig-a002-20200902 (attached as .config)
> compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project 224d8153b53b16cf535ea1a55afdfe1ec5b1374f)
> reproduce (this is a W=1 build):
> wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # install x86_64 cross compiling tool for clang build
> # apt-get install binutils-x86-64-linux-gnu
> git checkout bd295a352cfa24e5110a53f978edb48b7c21ff8f
> # save the attached .config to linux build tree
> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64
>
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot <lkp@intel.com>
>
> All errors (new ones prefixed by >>):
>
>>> ld.lld: error: undefined symbol: phys_to_target_node
> >>> referenced by device.c:84 (drivers/dax/hmem/device.c:84)
> >>> dax/hmem/device.o:(hmem_register_one) in archive drivers/built-in.a
>
This would require the proposed fix below the scissors mark.
I had reported this failure before, but it needed an adjustment so I'm re-sending it.
--------------------------->8----------------------------
From 622c1297b7d76a319b07a29192fe9bfe5c2b6b7c Mon Sep 17 00:00:00 2001
From: Joao Martins <joao.m.martins@oracle.com>
Date: Tue, 1 Sep 2020 08:06:35 -0400
Subject: [PATCH] device-dax: Require NUMA_KEEP_MEMINFO for
phys_to_target_node()
phys_to_target_node() and memory_add_physaddr_to_nid() are only defined
with both CONFIG_NUMA=y and CONFIG_MEMORY_HOTPLUG=y. Oherwise we see:
drivers/dax/hmem/device.o: in function `hmem_register_one':
drivers/dax/hmem/device.c:85: undefined reference to `phys_to_target_node'
lkp also reports such build failures:
ld.lld: error: undefined symbol: phys_to_target_node
X86 is a special case in which both can be defined without depending on
MEMORY_HOTPLUG=y. The other case is powerpc (for
memory_add_physaddr_to_nid) but like ARM64 dependencies, the
arch-specific override requires CONFIG_NUMA and CONFIG_MEMORY_HOTPLUG.
In all cases this ends up depending on CONFIG_NUMA_KEEP_MEMINFO to
signal the presence of phys_to_target_node() which is what
CONFIG_DEV_DAX_HMEM_DEVICES should depend on. Additionally, the X86
arch-override is not selected unless X86_PMEM_LEGACY=y. So on
CONFIG_DEV_DAX_HMEM we select CONFIG_NUMA_KEEP_INFO ourselves if both
NUMA and X86 are set.
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Joao Martins <joao.m.martins@oracle.com>
---
drivers/dax/Kconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/dax/Kconfig b/drivers/dax/Kconfig
index a66dff78f298..567428e10b7b 100644
--- a/drivers/dax/Kconfig
+++ b/drivers/dax/Kconfig
@@ -35,6 +35,7 @@ config DEV_DAX_PMEM
config DEV_DAX_HMEM
tristate "HMEM DAX: direct access to 'specific purpose' memory"
depends on EFI_SOFT_RESERVE
+ select NUMA_KEEP_MEMINFO if (NUMA && X86)
default DEV_DAX
help
EFI 2.8 platforms, and others, may advertise 'specific purpose'
@@ -49,6 +50,7 @@ config DEV_DAX_HMEM
Say M if unsure.
config DEV_DAX_HMEM_DEVICES
+ depends on NUMA_KEEP_MEMINFO # for phys_to_target_node()
depends on DEV_DAX_HMEM && DAX=y
def_bool y
--
2.17.1
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [linux-next:master 2890/4758] ld.lld: error: undefined symbol: phys_to_target_node
2020-09-03 12:31 ` Joao Martins
@ 2020-09-05 21:24 ` Randy Dunlap
2020-09-05 21:58 ` Randy Dunlap
0 siblings, 1 reply; 5+ messages in thread
From: Randy Dunlap @ 2020-09-05 21:24 UTC (permalink / raw)
To: Joao Martins, Andrew Morton, Vishal Verma
Cc: kernel test robot, Dan Williams, kbuild-all, clang-built-linux,
Linux Memory Management List, Matt Fleming
On 9/3/20 5:31 AM, Joao Martins wrote:
> On 9/3/20 6:49 AM, kernel test robot wrote:
>> tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
>> head: 4442749a203151a319a5bb8d0b983b84253a6931
>> commit: bd295a352cfa24e5110a53f978edb48b7c21ff8f [2890/4758] ACPI: HMAT: attach a device for each soft-reserved range
>> config: x86_64-randconfig-a002-20200902 (attached as .config)
>> compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project 224d8153b53b16cf535ea1a55afdfe1ec5b1374f)
>> reproduce (this is a W=1 build):
>> wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
>> chmod +x ~/bin/make.cross
>> # install x86_64 cross compiling tool for clang build
>> # apt-get install binutils-x86-64-linux-gnu
>> git checkout bd295a352cfa24e5110a53f978edb48b7c21ff8f
>> # save the attached .config to linux build tree
>> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64
>>
>> If you fix the issue, kindly add following tag as appropriate
>> Reported-by: kernel test robot <lkp@intel.com>
>>
>> All errors (new ones prefixed by >>):
>>
>>>> ld.lld: error: undefined symbol: phys_to_target_node
>> >>> referenced by device.c:84 (drivers/dax/hmem/device.c:84)
>> >>> dax/hmem/device.o:(hmem_register_one) in archive drivers/built-in.a
>>
> This would require the proposed fix below the scissors mark.
>
> I had reported this failure before, but it needed an adjustment so I'm re-sending it.
>
> --------------------------->8----------------------------
>
> From 622c1297b7d76a319b07a29192fe9bfe5c2b6b7c Mon Sep 17 00:00:00 2001
> From: Joao Martins <joao.m.martins@oracle.com>
> Date: Tue, 1 Sep 2020 08:06:35 -0400
> Subject: [PATCH] device-dax: Require NUMA_KEEP_MEMINFO for
> phys_to_target_node()
>
> phys_to_target_node() and memory_add_physaddr_to_nid() are only defined
> with both CONFIG_NUMA=y and CONFIG_MEMORY_HOTPLUG=y. Oherwise we see:
>
> drivers/dax/hmem/device.o: in function `hmem_register_one':
> drivers/dax/hmem/device.c:85: undefined reference to `phys_to_target_node'
>
> lkp also reports such build failures:
>
> ld.lld: error: undefined symbol: phys_to_target_node
>
> X86 is a special case in which both can be defined without depending on
> MEMORY_HOTPLUG=y. The other case is powerpc (for
> memory_add_physaddr_to_nid) but like ARM64 dependencies, the
> arch-specific override requires CONFIG_NUMA and CONFIG_MEMORY_HOTPLUG.
>
> In all cases this ends up depending on CONFIG_NUMA_KEEP_MEMINFO to
> signal the presence of phys_to_target_node() which is what
> CONFIG_DEV_DAX_HMEM_DEVICES should depend on. Additionally, the X86
> arch-override is not selected unless X86_PMEM_LEGACY=y. So on
> CONFIG_DEV_DAX_HMEM we select CONFIG_NUMA_KEEP_INFO ourselves if both
> NUMA and X86 are set.
>
> Reported-by: kernel test robot <lkp@intel.com>
> Signed-off-by: Joao Martins <joao.m.martins@oracle.com>
> ---
> drivers/dax/Kconfig | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/dax/Kconfig b/drivers/dax/Kconfig
> index a66dff78f298..567428e10b7b 100644
> --- a/drivers/dax/Kconfig
> +++ b/drivers/dax/Kconfig
> @@ -35,6 +35,7 @@ config DEV_DAX_PMEM
> config DEV_DAX_HMEM
> tristate "HMEM DAX: direct access to 'specific purpose' memory"
> depends on EFI_SOFT_RESERVE
> + select NUMA_KEEP_MEMINFO if (NUMA && X86)
> default DEV_DAX
> help
> EFI 2.8 platforms, and others, may advertise 'specific purpose'
> @@ -49,6 +50,7 @@ config DEV_DAX_HMEM
> Say M if unsure.
>
> config DEV_DAX_HMEM_DEVICES
> + depends on NUMA_KEEP_MEMINFO # for phys_to_target_node()
> depends on DEV_DAX_HMEM && DAX=y
> def_bool y
>
Hi,
There is also this patch from Matt Fleming from last year that I have
successfully tested (built) on ppc64 and arch/sh/, where build errors were reported.
https://lore.kernel.org/lkml/20191223164220.GA14394@codeblueprint.co.uk/
but Matt doesn't seem to be replying to any emails about this patch...
--
~Randy
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [linux-next:master 2890/4758] ld.lld: error: undefined symbol: phys_to_target_node
2020-09-05 21:24 ` Randy Dunlap
@ 2020-09-05 21:58 ` Randy Dunlap
2020-09-06 2:58 ` Randy Dunlap
0 siblings, 1 reply; 5+ messages in thread
From: Randy Dunlap @ 2020-09-05 21:58 UTC (permalink / raw)
To: Joao Martins, Andrew Morton, Vishal Verma
Cc: kernel test robot, Dan Williams, kbuild-all, clang-built-linux,
Linux Memory Management List, Matt Fleming
On 9/5/20 2:24 PM, Randy Dunlap wrote:
> On 9/3/20 5:31 AM, Joao Martins wrote:
>> On 9/3/20 6:49 AM, kernel test robot wrote:
>>> tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
>>> head: 4442749a203151a319a5bb8d0b983b84253a6931
>>> commit: bd295a352cfa24e5110a53f978edb48b7c21ff8f [2890/4758] ACPI: HMAT: attach a device for each soft-reserved range
>>> config: x86_64-randconfig-a002-20200902 (attached as .config)
>>> compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project 224d8153b53b16cf535ea1a55afdfe1ec5b1374f)
>>> reproduce (this is a W=1 build):
>>> wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
>>> chmod +x ~/bin/make.cross
>>> # install x86_64 cross compiling tool for clang build
>>> # apt-get install binutils-x86-64-linux-gnu
>>> git checkout bd295a352cfa24e5110a53f978edb48b7c21ff8f
>>> # save the attached .config to linux build tree
>>> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64
>>>
>>> If you fix the issue, kindly add following tag as appropriate
>>> Reported-by: kernel test robot <lkp@intel.com>
>>>
>>> All errors (new ones prefixed by >>):
>>>
>>>>> ld.lld: error: undefined symbol: phys_to_target_node
>>> >>> referenced by device.c:84 (drivers/dax/hmem/device.c:84)
>>> >>> dax/hmem/device.o:(hmem_register_one) in archive drivers/built-in.a
>>>
>> This would require the proposed fix below the scissors mark.
>>
>> I had reported this failure before, but it needed an adjustment so I'm re-sending it.
>>
>> --------------------------->8----------------------------
>>
>> From 622c1297b7d76a319b07a29192fe9bfe5c2b6b7c Mon Sep 17 00:00:00 2001
>> From: Joao Martins <joao.m.martins@oracle.com>
>> Date: Tue, 1 Sep 2020 08:06:35 -0400
>> Subject: [PATCH] device-dax: Require NUMA_KEEP_MEMINFO for
>> phys_to_target_node()
>>
>> phys_to_target_node() and memory_add_physaddr_to_nid() are only defined
>> with both CONFIG_NUMA=y and CONFIG_MEMORY_HOTPLUG=y. Oherwise we see:
>>
>> drivers/dax/hmem/device.o: in function `hmem_register_one':
>> drivers/dax/hmem/device.c:85: undefined reference to `phys_to_target_node'
>>
>> lkp also reports such build failures:
>>
>> ld.lld: error: undefined symbol: phys_to_target_node
>>
>> X86 is a special case in which both can be defined without depending on
>> MEMORY_HOTPLUG=y. The other case is powerpc (for
>> memory_add_physaddr_to_nid) but like ARM64 dependencies, the
>> arch-specific override requires CONFIG_NUMA and CONFIG_MEMORY_HOTPLUG.
>>
>> In all cases this ends up depending on CONFIG_NUMA_KEEP_MEMINFO to
>> signal the presence of phys_to_target_node() which is what
>> CONFIG_DEV_DAX_HMEM_DEVICES should depend on. Additionally, the X86
>> arch-override is not selected unless X86_PMEM_LEGACY=y. So on
>> CONFIG_DEV_DAX_HMEM we select CONFIG_NUMA_KEEP_INFO ourselves if both
>> NUMA and X86 are set.
>>
>> Reported-by: kernel test robot <lkp@intel.com>
>> Signed-off-by: Joao Martins <joao.m.martins@oracle.com>
>> ---
>> drivers/dax/Kconfig | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/dax/Kconfig b/drivers/dax/Kconfig
>> index a66dff78f298..567428e10b7b 100644
>> --- a/drivers/dax/Kconfig
>> +++ b/drivers/dax/Kconfig
>> @@ -35,6 +35,7 @@ config DEV_DAX_PMEM
>> config DEV_DAX_HMEM
>> tristate "HMEM DAX: direct access to 'specific purpose' memory"
>> depends on EFI_SOFT_RESERVE
>> + select NUMA_KEEP_MEMINFO if (NUMA && X86)
>> default DEV_DAX
>> help
>> EFI 2.8 platforms, and others, may advertise 'specific purpose'
>> @@ -49,6 +50,7 @@ config DEV_DAX_HMEM
>> Say M if unsure.
>>
>> config DEV_DAX_HMEM_DEVICES
>> + depends on NUMA_KEEP_MEMINFO # for phys_to_target_node()
>> depends on DEV_DAX_HMEM && DAX=y
>> def_bool y
>>
>
> Hi,
>
> There is also this patch from Matt Fleming from last year that I have
> successfully tested (built) on ppc64 and arch/sh/, where build errors were reported.
>
> https://lore.kernel.org/lkml/20191223164220.GA14394@codeblueprint.co.uk/
>
> but Matt doesn't seem to be replying to any emails about this patch...
>
OK, Matt's patch doesn't fix this x86_64 dax + hmem build error, so
apparently Joao's patch is needed.
--
~Randy
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [linux-next:master 2890/4758] ld.lld: error: undefined symbol: phys_to_target_node
2020-09-05 21:58 ` Randy Dunlap
@ 2020-09-06 2:58 ` Randy Dunlap
0 siblings, 0 replies; 5+ messages in thread
From: Randy Dunlap @ 2020-09-06 2:58 UTC (permalink / raw)
To: Joao Martins, Andrew Morton, Vishal Verma
Cc: kernel test robot, Dan Williams, kbuild-all, clang-built-linux,
Linux Memory Management List, Matt Fleming
On 9/5/20 2:58 PM, Randy Dunlap wrote:
> On 9/5/20 2:24 PM, Randy Dunlap wrote:
>> On 9/3/20 5:31 AM, Joao Martins wrote:
>>> On 9/3/20 6:49 AM, kernel test robot wrote:
>>>> tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
>>>> head: 4442749a203151a319a5bb8d0b983b84253a6931
>>>> commit: bd295a352cfa24e5110a53f978edb48b7c21ff8f [2890/4758] ACPI: HMAT: attach a device for each soft-reserved range
>>>> config: x86_64-randconfig-a002-20200902 (attached as .config)
>>>> compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project 224d8153b53b16cf535ea1a55afdfe1ec5b1374f)
>>>> reproduce (this is a W=1 build):
>>>> wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
>>>> chmod +x ~/bin/make.cross
>>>> # install x86_64 cross compiling tool for clang build
>>>> # apt-get install binutils-x86-64-linux-gnu
>>>> git checkout bd295a352cfa24e5110a53f978edb48b7c21ff8f
>>>> # save the attached .config to linux build tree
>>>> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64
>>>>
>>>> If you fix the issue, kindly add following tag as appropriate
>>>> Reported-by: kernel test robot <lkp@intel.com>
>>>>
>>>> All errors (new ones prefixed by >>):
>>>>
>>>>>> ld.lld: error: undefined symbol: phys_to_target_node
>>>> >>> referenced by device.c:84 (drivers/dax/hmem/device.c:84)
>>>> >>> dax/hmem/device.o:(hmem_register_one) in archive drivers/built-in.a
>>>>
>>> This would require the proposed fix below the scissors mark.
>>>
>>> I had reported this failure before, but it needed an adjustment so I'm re-sending it.
>>>
>>> --------------------------->8----------------------------
>>>
>>> From 622c1297b7d76a319b07a29192fe9bfe5c2b6b7c Mon Sep 17 00:00:00 2001
>>> From: Joao Martins <joao.m.martins@oracle.com>
>>> Date: Tue, 1 Sep 2020 08:06:35 -0400
>>> Subject: [PATCH] device-dax: Require NUMA_KEEP_MEMINFO for
>>> phys_to_target_node()
>>>
>>> phys_to_target_node() and memory_add_physaddr_to_nid() are only defined
>>> with both CONFIG_NUMA=y and CONFIG_MEMORY_HOTPLUG=y. Oherwise we see:
>>>
>>> drivers/dax/hmem/device.o: in function `hmem_register_one':
>>> drivers/dax/hmem/device.c:85: undefined reference to `phys_to_target_node'
>>>
>>> lkp also reports such build failures:
>>>
>>> ld.lld: error: undefined symbol: phys_to_target_node
>>>
>>> X86 is a special case in which both can be defined without depending on
>>> MEMORY_HOTPLUG=y. The other case is powerpc (for
>>> memory_add_physaddr_to_nid) but like ARM64 dependencies, the
>>> arch-specific override requires CONFIG_NUMA and CONFIG_MEMORY_HOTPLUG.
>>>
>>> In all cases this ends up depending on CONFIG_NUMA_KEEP_MEMINFO to
>>> signal the presence of phys_to_target_node() which is what
>>> CONFIG_DEV_DAX_HMEM_DEVICES should depend on. Additionally, the X86
>>> arch-override is not selected unless X86_PMEM_LEGACY=y. So on
>>> CONFIG_DEV_DAX_HMEM we select CONFIG_NUMA_KEEP_INFO ourselves if both
>>> NUMA and X86 are set.
>>>
>>> Reported-by: kernel test robot <lkp@intel.com>
>>> Signed-off-by: Joao Martins <joao.m.martins@oracle.com>
>>> ---
>>> drivers/dax/Kconfig | 2 ++
>>> 1 file changed, 2 insertions(+)
>>>
>>> diff --git a/drivers/dax/Kconfig b/drivers/dax/Kconfig
>>> index a66dff78f298..567428e10b7b 100644
>>> --- a/drivers/dax/Kconfig
>>> +++ b/drivers/dax/Kconfig
>>> @@ -35,6 +35,7 @@ config DEV_DAX_PMEM
>>> config DEV_DAX_HMEM
>>> tristate "HMEM DAX: direct access to 'specific purpose' memory"
>>> depends on EFI_SOFT_RESERVE
>>> + select NUMA_KEEP_MEMINFO if (NUMA && X86)
>>> default DEV_DAX
>>> help
>>> EFI 2.8 platforms, and others, may advertise 'specific purpose'
>>> @@ -49,6 +50,7 @@ config DEV_DAX_HMEM
>>> Say M if unsure.
>>>
>>> config DEV_DAX_HMEM_DEVICES
>>> + depends on NUMA_KEEP_MEMINFO # for phys_to_target_node()
>>> depends on DEV_DAX_HMEM && DAX=y
>>> def_bool y
>>>
>>
>> Hi,
>>
>> There is also this patch from Matt Fleming from last year that I have
>> successfully tested (built) on ppc64 and arch/sh/, where build errors were reported.
>>
>> https://lore.kernel.org/lkml/20191223164220.GA14394@codeblueprint.co.uk/
>>
>> but Matt doesn't seem to be replying to any emails about this patch...
>>
>
> OK, Matt's patch doesn't fix this x86_64 dax + hmem build error, so
> apparently Joao's patch is needed.
>
OTOH, Joao's patch doesn't fix the ppc64 and arch/sh/ build errors.
I'd prefer to see one patch to fix all of these build errors...
--
~Randy
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2020-09-06 2:58 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-09-03 5:49 [linux-next:master 2890/4758] ld.lld: error: undefined symbol: phys_to_target_node kernel test robot
2020-09-03 12:31 ` Joao Martins
2020-09-05 21:24 ` Randy Dunlap
2020-09-05 21:58 ` Randy Dunlap
2020-09-06 2:58 ` Randy Dunlap
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).