ld.lld: error: undefined symbol: iosf_mbi_available

ld.lld: error: undefined symbol: iosf_mbi_available

[kernel test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
head:   3e7819886281e077e82006fe4804b0d6b0f5643b
commit: 8d4ba1be3d2257606e04aff412829d8972670750 ASoC: SOF: pci: split PCI into different drivers
date:   3 years, 4 months ago
config: i386-buildonly-randconfig-004-20240716 (https://download.01.org/0day-ci/archive/20240716/202407160704.zpdhJ8da-lkp@intel.com/config)
compiler: clang version 18.1.5 (https://github.com/llvm/llvm-project 617a15a9eac96088ae5e9134248d8236e34b91b1)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240716/202407160704.zpdhJ8da-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202407160704.zpdhJ8da-lkp@intel.com/

All errors (new ones prefixed by >>):

>> ld.lld: error: undefined symbol: iosf_mbi_available
   >>> referenced by byt.c
   >>>               soc/sof/intel/byt.o:(byt_machine_select) in archive sound/built-in.a
--
>> ld.lld: error: undefined symbol: iosf_mbi_read
   >>> referenced by byt.c
   >>>               soc/sof/intel/byt.o:(byt_machine_select) in archive sound/built-in.a

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

Re: ld.lld: error: undefined symbol: iosf_mbi_available

[Pierre-Louis Bossart]

On 7/16/24 01:07, kernel test robot wrote:
> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> head:   3e7819886281e077e82006fe4804b0d6b0f5643b
> commit: 8d4ba1be3d2257606e04aff412829d8972670750 ASoC: SOF: pci: split PCI into different drivers
> date:   3 years, 4 months ago

This doesn't seem to be a problem on the latest code? was it intentional
to report a problem on such an old commit?

> config: i386-buildonly-randconfig-004-20240716 (https://download.01.org/0day-ci/archive/20240716/202407160704.zpdhJ8da-lkp@intel.com/config)
> compiler: clang version 18.1.5 (https://github.com/llvm/llvm-project 617a15a9eac96088ae5e9134248d8236e34b91b1)
> reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240716/202407160704.zpdhJ8da-lkp@intel.com/reproduce)
> 
> If you fix the issue in a separate patch/commit (i.e. not just a new version of
> the same patch/commit), kindly add following tags
> | Reported-by: kernel test robot <lkp@intel.com>
> | Closes: https://lore.kernel.org/oe-kbuild-all/202407160704.zpdhJ8da-lkp@intel.com/
> 
> All errors (new ones prefixed by >>):
> 
>>> ld.lld: error: undefined symbol: iosf_mbi_available
>    >>> referenced by byt.c
>    >>>               soc/sof/intel/byt.o:(byt_machine_select) in archive sound/built-in.a
> --
>>> ld.lld: error: undefined symbol: iosf_mbi_read
>    >>> referenced by byt.c
>    >>>               soc/sof/intel/byt.o:(byt_machine_select) in archive sound/built-in.a
> 

Re: ld.lld: error: undefined symbol: iosf_mbi_available

[Nathan Chancellor]

On Wed, Jul 17, 2024 at 01:43:35PM +0200, Pierre-Louis Bossart wrote:
> 
> 
> On 7/16/24 01:07, kernel test robot wrote:
> > tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> > head:   3e7819886281e077e82006fe4804b0d6b0f5643b
> > commit: 8d4ba1be3d2257606e04aff412829d8972670750 ASoC: SOF: pci: split PCI into different drivers
> > date:   3 years, 4 months ago
> 
> This doesn't seem to be a problem on the latest code? was it intentional
> to report a problem on such an old commit?

It's still reproducible at commit 8b0f0bb27c32 ("Merge tag
'fs_for_v6.11-rc1' of
git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs") for me,
using either LLVM or GCC with the configuration linked below:

  ld.lld: error: undefined symbol: iosf_mbi_available
  >>> referenced by atom.c
  >>>               sound/soc/sof/intel/atom.o:(atom_machine_select) in archive vmlinux.a

  ld.lld: error: undefined symbol: iosf_mbi_read
  >>> referenced by atom.c
  >>>               sound/soc/sof/intel/atom.o:(atom_machine_select) in archive vmlinux.a

  .../gcc/14.1.0/bin/i386-linux-ld: sound/soc/sof/intel/atom.o: in function `atom_machine_select':
  atom.c:(.text+0x1b9): undefined reference to `iosf_mbi_available'
  .../gcc/14.1.0/bin/i386-linux-ld: atom.c:(.text+0x1e3): undefined reference to `iosf_mbi_read'

Cheers,
Nathan

> > config: i386-buildonly-randconfig-004-20240716 (https://download.01.org/0day-ci/archive/20240716/202407160704.zpdhJ8da-lkp@intel.com/config)
> > compiler: clang version 18.1.5 (https://github.com/llvm/llvm-project 617a15a9eac96088ae5e9134248d8236e34b91b1)
> > reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240716/202407160704.zpdhJ8da-lkp@intel.com/reproduce)
> > 
> > If you fix the issue in a separate patch/commit (i.e. not just a new version of
> > the same patch/commit), kindly add following tags
> > | Reported-by: kernel test robot <lkp@intel.com>
> > | Closes: https://lore.kernel.org/oe-kbuild-all/202407160704.zpdhJ8da-lkp@intel.com/
> > 
> > All errors (new ones prefixed by >>):
> > 
> >>> ld.lld: error: undefined symbol: iosf_mbi_available
> >    >>> referenced by byt.c
> >    >>>               soc/sof/intel/byt.o:(byt_machine_select) in archive sound/built-in.a
> > --
> >>> ld.lld: error: undefined symbol: iosf_mbi_read
> >    >>> referenced by byt.c
> >    >>>               soc/sof/intel/byt.o:(byt_machine_select) in archive sound/built-in.a
> > 
> 

Re: ld.lld: error: undefined symbol: iosf_mbi_available

[Takashi Iwai]

On Wed, 17 Jul 2024 22:28:06 +0200,
Nathan Chancellor wrote:
> 
> On Wed, Jul 17, 2024 at 01:43:35PM +0200, Pierre-Louis Bossart wrote:
> > 
> > 
> > On 7/16/24 01:07, kernel test robot wrote:
> > > tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> > > head:   3e7819886281e077e82006fe4804b0d6b0f5643b
> > > commit: 8d4ba1be3d2257606e04aff412829d8972670750 ASoC: SOF: pci: split PCI into different drivers
> > > date:   3 years, 4 months ago
> > 
> > This doesn't seem to be a problem on the latest code? was it intentional
> > to report a problem on such an old commit?
> 
> It's still reproducible at commit 8b0f0bb27c32 ("Merge tag
> 'fs_for_v6.11-rc1' of
> git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs") for me,
> using either LLVM or GCC with the configuration linked below:
> 
>   ld.lld: error: undefined symbol: iosf_mbi_available
>   >>> referenced by atom.c
>   >>>               sound/soc/sof/intel/atom.o:(atom_machine_select) in archive vmlinux.a
> 
>   ld.lld: error: undefined symbol: iosf_mbi_read
>   >>> referenced by atom.c
>   >>>               sound/soc/sof/intel/atom.o:(atom_machine_select) in archive vmlinux.a
> 
>   .../gcc/14.1.0/bin/i386-linux-ld: sound/soc/sof/intel/atom.o: in function `atom_machine_select':
>   atom.c:(.text+0x1b9): undefined reference to `iosf_mbi_available'
>   .../gcc/14.1.0/bin/i386-linux-ld: atom.c:(.text+0x1e3): undefined reference to `iosf_mbi_read'

Yours looks different from the original report, and indeed this must
be a missing fix.

Does the following change cover it?


thanks,

Takashi

--- a/sound/soc/sof/intel/Kconfig
+++ b/sound/soc/sof/intel/Kconfig
@@ -19,6 +19,7 @@ config SND_SOC_SOF_INTEL_ATOM_HIFI_EP
 	tristate
 	select SND_SOC_SOF_INTEL_COMMON
 	select SND_SOC_SOF_INTEL_HIFI_EP_IPC
+	select IOSF_MBI if X86 && PCI
 	help
 	  This option is not user-selectable but automagically handled by
 	  'select' statements at a higher level.
@@ -44,7 +45,6 @@ config SND_SOC_SOF_BAYTRAIL
 	select SND_SOC_SOF_INTEL_COMMON
 	select SND_SOC_SOF_INTEL_ATOM_HIFI_EP
 	select SND_SOC_SOF_ACPI_DEV
-	select IOSF_MBI if X86 && PCI
 	help
 	  This adds support for Sound Open Firmware for Intel(R) platforms
 	  using the Baytrail, Braswell or Cherrytrail processors.

Re: ld.lld: error: undefined symbol: iosf_mbi_available

[Pierre-Louis Bossart]

On 7/18/24 09:26, Takashi Iwai wrote:
> On Wed, 17 Jul 2024 22:28:06 +0200,
> Nathan Chancellor wrote:
>>
>> On Wed, Jul 17, 2024 at 01:43:35PM +0200, Pierre-Louis Bossart wrote:
>>>
>>>
>>> On 7/16/24 01:07, kernel test robot wrote:
>>>> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
>>>> head:   3e7819886281e077e82006fe4804b0d6b0f5643b
>>>> commit: 8d4ba1be3d2257606e04aff412829d8972670750 ASoC: SOF: pci: split PCI into different drivers
>>>> date:   3 years, 4 months ago
>>>
>>> This doesn't seem to be a problem on the latest code? was it intentional
>>> to report a problem on such an old commit?
>>
>> It's still reproducible at commit 8b0f0bb27c32 ("Merge tag
>> 'fs_for_v6.11-rc1' of
>> git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs") for me,
>> using either LLVM or GCC with the configuration linked below:

I can't compile this branch - errors in unrelated parts of the code, but
indeed there's a problem when IOSF_MBI=y and Baytrail is not selected.

>>   ld.lld: error: undefined symbol: iosf_mbi_available
>>   >>> referenced by atom.c
>>   >>>               sound/soc/sof/intel/atom.o:(atom_machine_select) in archive vmlinux.a
>>
>>   ld.lld: error: undefined symbol: iosf_mbi_read
>>   >>> referenced by atom.c
>>   >>>               sound/soc/sof/intel/atom.o:(atom_machine_select) in archive vmlinux.a
>>
>>   .../gcc/14.1.0/bin/i386-linux-ld: sound/soc/sof/intel/atom.o: in function `atom_machine_select':
>>   atom.c:(.text+0x1b9): undefined reference to `iosf_mbi_available'
>>   .../gcc/14.1.0/bin/i386-linux-ld: atom.c:(.text+0x1e3): undefined reference to `iosf_mbi_read'
> 
> Yours looks different from the original report, and indeed this must
> be a missing fix.
> 
> Does the following change cover it?
> 
> 
> thanks,
> 
> Takashi
> 
> --- a/sound/soc/sof/intel/Kconfig
> +++ b/sound/soc/sof/intel/Kconfig
> @@ -19,6 +19,7 @@ config SND_SOC_SOF_INTEL_ATOM_HIFI_EP
>  	tristate
>  	select SND_SOC_SOF_INTEL_COMMON
>  	select SND_SOC_SOF_INTEL_HIFI_EP_IPC
> +	select IOSF_MBI if X86 && PCI
>  	help
>  	  This option is not user-selectable but automagically handled by
>  	  'select' statements at a higher level.
> @@ -44,7 +45,6 @@ config SND_SOC_SOF_BAYTRAIL
>  	select SND_SOC_SOF_INTEL_COMMON
>  	select SND_SOC_SOF_INTEL_ATOM_HIFI_EP
>  	select SND_SOC_SOF_ACPI_DEV
> -	select IOSF_MBI if X86 && PCI
>  	help
>  	  This adds support for Sound Open Firmware for Intel(R) platforms
>  	  using the Baytrail, Braswell or Cherrytrail processors.

I don't think it's the 'right' fix Takashi.

The problem is that we end-up using the iosf_mbi_read() routine by
including the soc-intel-quirks.h header file blindly for all X66
platforms - even when Baytrail is not used.

Adding IOSF support for Tangiger doesn't seem right to me, it's not a
real dependency.

We can be more restrictive and only use the helper for Baytrail, and use
a fallback if Baytrail is not used.

diff --git a/sound/soc/intel/common/soc-intel-quirks.h
b/sound/soc/intel/common/soc-intel-quirks.h
index de4e550c5b34..ae67853f7e2e 100644
--- a/sound/soc/intel/common/soc-intel-quirks.h
+++ b/sound/soc/intel/common/soc-intel-quirks.h
@@ -11,7 +11,9 @@

 #include <linux/platform_data/x86/soc.h>

-#if IS_ENABLED(CONFIG_X86)
+#if IS_ENABLED(CONFIG_X86) && \
+       (IS_ENABLED(CONFIG_SND_SOC_SOF_BAYTRAIL) || \
+        IS_ENABLED(CONFIG_SND_SST_ATOM_HIFI2_PLATFORM_ACPI))

 #include <linux/dmi.h>
 #include <asm/iosf_mbi.h>

also at https://github.com/thesofproject/linux/pull/5114

Re: ld.lld: error: undefined symbol: iosf_mbi_available

[Takashi Iwai]

On Thu, 18 Jul 2024 10:23:40 +0200,
Pierre-Louis Bossart wrote:
> 
> 
> 
> On 7/18/24 09:26, Takashi Iwai wrote:
> > On Wed, 17 Jul 2024 22:28:06 +0200,
> > Nathan Chancellor wrote:
> >>
> >> On Wed, Jul 17, 2024 at 01:43:35PM +0200, Pierre-Louis Bossart wrote:
> >>>
> >>>
> >>> On 7/16/24 01:07, kernel test robot wrote:
> >>>> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> >>>> head:   3e7819886281e077e82006fe4804b0d6b0f5643b
> >>>> commit: 8d4ba1be3d2257606e04aff412829d8972670750 ASoC: SOF: pci: split PCI into different drivers
> >>>> date:   3 years, 4 months ago
> >>>
> >>> This doesn't seem to be a problem on the latest code? was it intentional
> >>> to report a problem on such an old commit?
> >>
> >> It's still reproducible at commit 8b0f0bb27c32 ("Merge tag
> >> 'fs_for_v6.11-rc1' of
> >> git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs") for me,
> >> using either LLVM or GCC with the configuration linked below:
> 
> I can't compile this branch - errors in unrelated parts of the code, but
> indeed there's a problem when IOSF_MBI=y and Baytrail is not selected.
> 
> >>   ld.lld: error: undefined symbol: iosf_mbi_available
> >>   >>> referenced by atom.c
> >>   >>>               sound/soc/sof/intel/atom.o:(atom_machine_select) in archive vmlinux.a
> >>
> >>   ld.lld: error: undefined symbol: iosf_mbi_read
> >>   >>> referenced by atom.c
> >>   >>>               sound/soc/sof/intel/atom.o:(atom_machine_select) in archive vmlinux.a
> >>
> >>   .../gcc/14.1.0/bin/i386-linux-ld: sound/soc/sof/intel/atom.o: in function `atom_machine_select':
> >>   atom.c:(.text+0x1b9): undefined reference to `iosf_mbi_available'
> >>   .../gcc/14.1.0/bin/i386-linux-ld: atom.c:(.text+0x1e3): undefined reference to `iosf_mbi_read'
> > 
> > Yours looks different from the original report, and indeed this must
> > be a missing fix.
> > 
> > Does the following change cover it?
> > 
> > 
> > thanks,
> > 
> > Takashi
> > 
> > --- a/sound/soc/sof/intel/Kconfig
> > +++ b/sound/soc/sof/intel/Kconfig
> > @@ -19,6 +19,7 @@ config SND_SOC_SOF_INTEL_ATOM_HIFI_EP
> >  	tristate
> >  	select SND_SOC_SOF_INTEL_COMMON
> >  	select SND_SOC_SOF_INTEL_HIFI_EP_IPC
> > +	select IOSF_MBI if X86 && PCI
> >  	help
> >  	  This option is not user-selectable but automagically handled by
> >  	  'select' statements at a higher level.
> > @@ -44,7 +45,6 @@ config SND_SOC_SOF_BAYTRAIL
> >  	select SND_SOC_SOF_INTEL_COMMON
> >  	select SND_SOC_SOF_INTEL_ATOM_HIFI_EP
> >  	select SND_SOC_SOF_ACPI_DEV
> > -	select IOSF_MBI if X86 && PCI
> >  	help
> >  	  This adds support for Sound Open Firmware for Intel(R) platforms
> >  	  using the Baytrail, Braswell or Cherrytrail processors.
> 
> I don't think it's the 'right' fix Takashi.
> 
> The problem is that we end-up using the iosf_mbi_read() routine by
> including the soc-intel-quirks.h header file blindly for all X66
> platforms - even when Baytrail is not used.
> 
> Adding IOSF support for Tangiger doesn't seem right to me, it's not a
> real dependency.
> 
> We can be more restrictive and only use the helper for Baytrail, and use
> a fallback if Baytrail is not used.
> 
> diff --git a/sound/soc/intel/common/soc-intel-quirks.h
> b/sound/soc/intel/common/soc-intel-quirks.h
> index de4e550c5b34..ae67853f7e2e 100644
> --- a/sound/soc/intel/common/soc-intel-quirks.h
> +++ b/sound/soc/intel/common/soc-intel-quirks.h
> @@ -11,7 +11,9 @@
> 
>  #include <linux/platform_data/x86/soc.h>
> 
> -#if IS_ENABLED(CONFIG_X86)
> +#if IS_ENABLED(CONFIG_X86) && \
> +       (IS_ENABLED(CONFIG_SND_SOC_SOF_BAYTRAIL) || \
> +        IS_ENABLED(CONFIG_SND_SST_ATOM_HIFI2_PLATFORM_ACPI))
> 
>  #include <linux/dmi.h>
>  #include <asm/iosf_mbi.h>
> 
> also at https://github.com/thesofproject/linux/pull/5114

I'm afraid it's not enough, either.  It's included in
sound/soc/sof/intel/atom.c, and this one can be built-in by selected
from others while CONFIG_SND_SOC_SOF_BAYTRAIL=m.  And, the reverse
selection is done from CONFIG_SND_SOC_SOF_BAYTRAIL -- so
CONFIG_IOSF_MBI can be m as well, and this can lead to the unresolved
symbol from the built-in atom.c.


Takashi

Re: ld.lld: error: undefined symbol: iosf_mbi_available

[Pierre-Louis Bossart]

>>> --- a/sound/soc/sof/intel/Kconfig
>>> +++ b/sound/soc/sof/intel/Kconfig
>>> @@ -19,6 +19,7 @@ config SND_SOC_SOF_INTEL_ATOM_HIFI_EP
>>>  	tristate
>>>  	select SND_SOC_SOF_INTEL_COMMON
>>>  	select SND_SOC_SOF_INTEL_HIFI_EP_IPC
>>> +	select IOSF_MBI if X86 && PCI
>>>  	help
>>>  	  This option is not user-selectable but automagically handled by
>>>  	  'select' statements at a higher level.
>>> @@ -44,7 +45,6 @@ config SND_SOC_SOF_BAYTRAIL
>>>  	select SND_SOC_SOF_INTEL_COMMON
>>>  	select SND_SOC_SOF_INTEL_ATOM_HIFI_EP
>>>  	select SND_SOC_SOF_ACPI_DEV
>>> -	select IOSF_MBI if X86 && PCI
>>>  	help
>>>  	  This adds support for Sound Open Firmware for Intel(R) platforms
>>>  	  using the Baytrail, Braswell or Cherrytrail processors.
>>
>> I don't think it's the 'right' fix Takashi.
>>
>> The problem is that we end-up using the iosf_mbi_read() routine by
>> including the soc-intel-quirks.h header file blindly for all X66
>> platforms - even when Baytrail is not used.
>>
>> Adding IOSF support for Tangiger doesn't seem right to me, it's not a
>> real dependency.
>>
>> We can be more restrictive and only use the helper for Baytrail, and use
>> a fallback if Baytrail is not used.
>>
>> diff --git a/sound/soc/intel/common/soc-intel-quirks.h
>> b/sound/soc/intel/common/soc-intel-quirks.h
>> index de4e550c5b34..ae67853f7e2e 100644
>> --- a/sound/soc/intel/common/soc-intel-quirks.h
>> +++ b/sound/soc/intel/common/soc-intel-quirks.h
>> @@ -11,7 +11,9 @@
>>
>>  #include <linux/platform_data/x86/soc.h>
>>
>> -#if IS_ENABLED(CONFIG_X86)
>> +#if IS_ENABLED(CONFIG_X86) && \
>> +       (IS_ENABLED(CONFIG_SND_SOC_SOF_BAYTRAIL) || \
>> +        IS_ENABLED(CONFIG_SND_SST_ATOM_HIFI2_PLATFORM_ACPI))
>>
>>  #include <linux/dmi.h>
>>  #include <asm/iosf_mbi.h>
>>
>> also at https://github.com/thesofproject/linux/pull/5114
> 
> I'm afraid it's not enough, either.  It's included in
> sound/soc/sof/intel/atom.c, and this one can be built-in by selected
> from others while CONFIG_SND_SOC_SOF_BAYTRAIL=m.  And, the reverse
> selection is done from CONFIG_SND_SOC_SOF_BAYTRAIL -- so
> CONFIG_IOSF_MBI can be m as well, and this can lead to the unresolved
> symbol from the built-in atom.c.

Fair point, I was only looking at the reported failure where Baytrail
was completely disabled.

I am not sure though if it makes sense to split hair in N dimensions.
Building Merrifield as y and Baytrail as m is a corner case that
shouldn't exist at all. And it's only an academic compilation issue, in
practice using 'y' would fail at run-time due to the usual firmware load
dependencies...

Re: ld.lld: error: undefined symbol: iosf_mbi_available

[Takashi Iwai]

On Thu, 18 Jul 2024 11:12:24 +0200,
Pierre-Louis Bossart wrote:
> 
> 
> 
> >>> --- a/sound/soc/sof/intel/Kconfig
> >>> +++ b/sound/soc/sof/intel/Kconfig
> >>> @@ -19,6 +19,7 @@ config SND_SOC_SOF_INTEL_ATOM_HIFI_EP
> >>>  	tristate
> >>>  	select SND_SOC_SOF_INTEL_COMMON
> >>>  	select SND_SOC_SOF_INTEL_HIFI_EP_IPC
> >>> +	select IOSF_MBI if X86 && PCI
> >>>  	help
> >>>  	  This option is not user-selectable but automagically handled by
> >>>  	  'select' statements at a higher level.
> >>> @@ -44,7 +45,6 @@ config SND_SOC_SOF_BAYTRAIL
> >>>  	select SND_SOC_SOF_INTEL_COMMON
> >>>  	select SND_SOC_SOF_INTEL_ATOM_HIFI_EP
> >>>  	select SND_SOC_SOF_ACPI_DEV
> >>> -	select IOSF_MBI if X86 && PCI
> >>>  	help
> >>>  	  This adds support for Sound Open Firmware for Intel(R) platforms
> >>>  	  using the Baytrail, Braswell or Cherrytrail processors.
> >>
> >> I don't think it's the 'right' fix Takashi.
> >>
> >> The problem is that we end-up using the iosf_mbi_read() routine by
> >> including the soc-intel-quirks.h header file blindly for all X66
> >> platforms - even when Baytrail is not used.
> >>
> >> Adding IOSF support for Tangiger doesn't seem right to me, it's not a
> >> real dependency.
> >>
> >> We can be more restrictive and only use the helper for Baytrail, and use
> >> a fallback if Baytrail is not used.
> >>
> >> diff --git a/sound/soc/intel/common/soc-intel-quirks.h
> >> b/sound/soc/intel/common/soc-intel-quirks.h
> >> index de4e550c5b34..ae67853f7e2e 100644
> >> --- a/sound/soc/intel/common/soc-intel-quirks.h
> >> +++ b/sound/soc/intel/common/soc-intel-quirks.h
> >> @@ -11,7 +11,9 @@
> >>
> >>  #include <linux/platform_data/x86/soc.h>
> >>
> >> -#if IS_ENABLED(CONFIG_X86)
> >> +#if IS_ENABLED(CONFIG_X86) && \
> >> +       (IS_ENABLED(CONFIG_SND_SOC_SOF_BAYTRAIL) || \
> >> +        IS_ENABLED(CONFIG_SND_SST_ATOM_HIFI2_PLATFORM_ACPI))
> >>
> >>  #include <linux/dmi.h>
> >>  #include <asm/iosf_mbi.h>
> >>
> >> also at https://github.com/thesofproject/linux/pull/5114
> > 
> > I'm afraid it's not enough, either.  It's included in
> > sound/soc/sof/intel/atom.c, and this one can be built-in by selected
> > from others while CONFIG_SND_SOC_SOF_BAYTRAIL=m.  And, the reverse
> > selection is done from CONFIG_SND_SOC_SOF_BAYTRAIL -- so
> > CONFIG_IOSF_MBI can be m as well, and this can lead to the unresolved
> > symbol from the built-in atom.c.
> 
> Fair point, I was only looking at the reported failure where Baytrail
> was completely disabled.
> 
> I am not sure though if it makes sense to split hair in N dimensions.
> Building Merrifield as y and Baytrail as m is a corner case that
> shouldn't exist at all. And it's only an academic compilation issue, in
> practice using 'y' would fail at run-time due to the usual firmware load
> dependencies...

Surely this kind of bug won't hit anyone in practical use, but it's
only about the randconfig failures.  The original report is in the
same category, after all.

Maybe another (rather easier) workaround would be to use
IS_REACHABLE(), something like below.  This should fix the original
issue and the potential mess-up of kconfig dependencies.


Takashi

--- a/sound/soc/intel/common/soc-intel-quirks.h
+++ b/sound/soc/intel/common/soc-intel-quirks.h
@@ -11,7 +11,7 @@
 
 #include <linux/platform_data/x86/soc.h>
 
-#if IS_ENABLED(CONFIG_X86)
+#if IS_REACHABLE(CONFIG_IOSF_MBI)
 
 #include <linux/dmi.h>
 #include <asm/iosf_mbi.h>

Re: ld.lld: error: undefined symbol: iosf_mbi_available

[Pierre-Louis Bossart]

>>>> diff --git a/sound/soc/intel/common/soc-intel-quirks.h
>>>> b/sound/soc/intel/common/soc-intel-quirks.h
>>>> index de4e550c5b34..ae67853f7e2e 100644
>>>> --- a/sound/soc/intel/common/soc-intel-quirks.h
>>>> +++ b/sound/soc/intel/common/soc-intel-quirks.h
>>>> @@ -11,7 +11,9 @@
>>>>
>>>>  #include <linux/platform_data/x86/soc.h>
>>>>
>>>> -#if IS_ENABLED(CONFIG_X86)
>>>> +#if IS_ENABLED(CONFIG_X86) && \
>>>> +       (IS_ENABLED(CONFIG_SND_SOC_SOF_BAYTRAIL) || \
>>>> +        IS_ENABLED(CONFIG_SND_SST_ATOM_HIFI2_PLATFORM_ACPI))
>>>>
>>>>  #include <linux/dmi.h>
>>>>  #include <asm/iosf_mbi.h>
>>>>
>>>> also at https://github.com/thesofproject/linux/pull/5114
>>>
>>> I'm afraid it's not enough, either.  It's included in
>>> sound/soc/sof/intel/atom.c, and this one can be built-in by selected
>>> from others while CONFIG_SND_SOC_SOF_BAYTRAIL=m.  And, the reverse
>>> selection is done from CONFIG_SND_SOC_SOF_BAYTRAIL -- so
>>> CONFIG_IOSF_MBI can be m as well, and this can lead to the unresolved
>>> symbol from the built-in atom.c.
>>
>> Fair point, I was only looking at the reported failure where Baytrail
>> was completely disabled.
>>
>> I am not sure though if it makes sense to split hair in N dimensions.
>> Building Merrifield as y and Baytrail as m is a corner case that
>> shouldn't exist at all. And it's only an academic compilation issue, in
>> practice using 'y' would fail at run-time due to the usual firmware load
>> dependencies...
> 
> Surely this kind of bug won't hit anyone in practical use, but it's
> only about the randconfig failures.  The original report is in the
> same category, after all.
> 
> Maybe another (rather easier) workaround would be to use
> IS_REACHABLE(), something like below.  This should fix the original
> issue and the potential mess-up of kconfig dependencies.

The simplest solution works for me :-)

Do you want me to send a patch with your Suggested-by: tag or do it
yourself?

> --- a/sound/soc/intel/common/soc-intel-quirks.h
> +++ b/sound/soc/intel/common/soc-intel-quirks.h
> @@ -11,7 +11,7 @@
>  
>  #include <linux/platform_data/x86/soc.h>
>  
> -#if IS_ENABLED(CONFIG_X86)
> +#if IS_REACHABLE(CONFIG_IOSF_MBI)
>  
>  #include <linux/dmi.h>
>  #include <asm/iosf_mbi.h>

Re: ld.lld: error: undefined symbol: iosf_mbi_available

[Takashi Iwai]

On Thu, 18 Jul 2024 17:16:54 +0200,
Pierre-Louis Bossart wrote:
> 
> 
> >>>> diff --git a/sound/soc/intel/common/soc-intel-quirks.h
> >>>> b/sound/soc/intel/common/soc-intel-quirks.h
> >>>> index de4e550c5b34..ae67853f7e2e 100644
> >>>> --- a/sound/soc/intel/common/soc-intel-quirks.h
> >>>> +++ b/sound/soc/intel/common/soc-intel-quirks.h
> >>>> @@ -11,7 +11,9 @@
> >>>>
> >>>>  #include <linux/platform_data/x86/soc.h>
> >>>>
> >>>> -#if IS_ENABLED(CONFIG_X86)
> >>>> +#if IS_ENABLED(CONFIG_X86) && \
> >>>> +       (IS_ENABLED(CONFIG_SND_SOC_SOF_BAYTRAIL) || \
> >>>> +        IS_ENABLED(CONFIG_SND_SST_ATOM_HIFI2_PLATFORM_ACPI))
> >>>>
> >>>>  #include <linux/dmi.h>
> >>>>  #include <asm/iosf_mbi.h>
> >>>>
> >>>> also at https://github.com/thesofproject/linux/pull/5114
> >>>
> >>> I'm afraid it's not enough, either.  It's included in
> >>> sound/soc/sof/intel/atom.c, and this one can be built-in by selected
> >>> from others while CONFIG_SND_SOC_SOF_BAYTRAIL=m.  And, the reverse
> >>> selection is done from CONFIG_SND_SOC_SOF_BAYTRAIL -- so
> >>> CONFIG_IOSF_MBI can be m as well, and this can lead to the unresolved
> >>> symbol from the built-in atom.c.
> >>
> >> Fair point, I was only looking at the reported failure where Baytrail
> >> was completely disabled.
> >>
> >> I am not sure though if it makes sense to split hair in N dimensions.
> >> Building Merrifield as y and Baytrail as m is a corner case that
> >> shouldn't exist at all. And it's only an academic compilation issue, in
> >> practice using 'y' would fail at run-time due to the usual firmware load
> >> dependencies...
> > 
> > Surely this kind of bug won't hit anyone in practical use, but it's
> > only about the randconfig failures.  The original report is in the
> > same category, after all.
> > 
> > Maybe another (rather easier) workaround would be to use
> > IS_REACHABLE(), something like below.  This should fix the original
> > issue and the potential mess-up of kconfig dependencies.
> 
> The simplest solution works for me :-)
> 
> Do you want me to send a patch with your Suggested-by: tag or do it
> yourself?

If you can send from your side, it'd be more appreciated ;)


thanks,

Takashi

> 
> > --- a/sound/soc/intel/common/soc-intel-quirks.h
> > +++ b/sound/soc/intel/common/soc-intel-quirks.h
> > @@ -11,7 +11,7 @@
> >  
> >  #include <linux/platform_data/x86/soc.h>
> >  
> > -#if IS_ENABLED(CONFIG_X86)
> > +#if IS_REACHABLE(CONFIG_IOSF_MBI)
> >  
> >  #include <linux/dmi.h>
> >  #include <asm/iosf_mbi.h>

Re: ld.lld: error: undefined symbol: iosf_mbi_available

[Pierre-Louis Bossart]

On 7/18/24 17:36, Takashi Iwai wrote:
> On Thu, 18 Jul 2024 17:16:54 +0200,
> Pierre-Louis Bossart wrote:
>>
>>
>>>>>> diff --git a/sound/soc/intel/common/soc-intel-quirks.h
>>>>>> b/sound/soc/intel/common/soc-intel-quirks.h
>>>>>> index de4e550c5b34..ae67853f7e2e 100644
>>>>>> --- a/sound/soc/intel/common/soc-intel-quirks.h
>>>>>> +++ b/sound/soc/intel/common/soc-intel-quirks.h
>>>>>> @@ -11,7 +11,9 @@
>>>>>>
>>>>>>  #include <linux/platform_data/x86/soc.h>
>>>>>>
>>>>>> -#if IS_ENABLED(CONFIG_X86)
>>>>>> +#if IS_ENABLED(CONFIG_X86) && \
>>>>>> +       (IS_ENABLED(CONFIG_SND_SOC_SOF_BAYTRAIL) || \
>>>>>> +        IS_ENABLED(CONFIG_SND_SST_ATOM_HIFI2_PLATFORM_ACPI))
>>>>>>
>>>>>>  #include <linux/dmi.h>
>>>>>>  #include <asm/iosf_mbi.h>
>>>>>>
>>>>>> also at https://github.com/thesofproject/linux/pull/5114
>>>>>
>>>>> I'm afraid it's not enough, either.  It's included in
>>>>> sound/soc/sof/intel/atom.c, and this one can be built-in by selected
>>>>> from others while CONFIG_SND_SOC_SOF_BAYTRAIL=m.  And, the reverse
>>>>> selection is done from CONFIG_SND_SOC_SOF_BAYTRAIL -- so
>>>>> CONFIG_IOSF_MBI can be m as well, and this can lead to the unresolved
>>>>> symbol from the built-in atom.c.
>>>>
>>>> Fair point, I was only looking at the reported failure where Baytrail
>>>> was completely disabled.
>>>>
>>>> I am not sure though if it makes sense to split hair in N dimensions.
>>>> Building Merrifield as y and Baytrail as m is a corner case that
>>>> shouldn't exist at all. And it's only an academic compilation issue, in
>>>> practice using 'y' would fail at run-time due to the usual firmware load
>>>> dependencies...
>>>
>>> Surely this kind of bug won't hit anyone in practical use, but it's
>>> only about the randconfig failures.  The original report is in the
>>> same category, after all.
>>>
>>> Maybe another (rather easier) workaround would be to use
>>> IS_REACHABLE(), something like below.  This should fix the original
>>> issue and the potential mess-up of kconfig dependencies.
>>
>> The simplest solution works for me :-)
>>
>> Do you want me to send a patch with your Suggested-by: tag or do it
>> yourself?
> 
> If you can send from your side, it'd be more appreciated ;)

will do, no worries.