tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
head: be3ca57cfb777ad820c6659d52e60bbdd36bf5ff
commit: 0548448b719ac78fa18fdbcd03856952ba6cc7dc pinctrl: lochnagar: Add support for the Cirrus Logic Lochnagar
date: 4 years, 7 months ago
config: mips-buildonly-randconfig-r006-20220821 (https://download.01.org/0day-ci/archive/20231107/[email protected]/config)
compiler: mipsel-linux-gcc (GCC) 11.3.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20231107/[email protected]/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 <[email protected]>
| Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/
All errors (new ones prefixed by >>):
>> drivers/pinctrl/cirrus/pinctrl-lochnagar.c:52:53: error: pasting "LOCHNAGAR1_" and "(" does not give a valid preprocessing token
52 | .name = NAME, .type = LN_PTYPE_GPIO, .reg = LOCHNAGAR##REV##_##REG, \
| ^~~~~~~~~
drivers/pinctrl/cirrus/pinctrl-lochnagar.c:67:9: note: in expansion of macro 'LN_PIN_GPIO'
67 | LN_PIN_GPIO(1, ID, NAME, REG, SHIFT, INVERT)
| ^~~~~~~~~~~
drivers/pinctrl/cirrus/pinctrl-lochnagar.c:200:1: note: in expansion of macro 'LN1_PIN_GPIO'
200 | LN1_PIN_GPIO(CDC_RESET, "codec-reset", RST, CDC_RESET, 1);
| ^~~~~~~~~~~~
>> drivers/pinctrl/cirrus/pinctrl-lochnagar.c:52:53: error: implicit declaration of function 'LOCHNAGAR1_'; did you mean 'LOCHNAGAR1_RST'? [-Werror=implicit-function-declaration]
52 | .name = NAME, .type = LN_PTYPE_GPIO, .reg = LOCHNAGAR##REV##_##REG, \
| ^~~~~~~~~
drivers/pinctrl/cirrus/pinctrl-lochnagar.c:67:9: note: in expansion of macro 'LN_PIN_GPIO'
67 | LN_PIN_GPIO(1, ID, NAME, REG, SHIFT, INVERT)
| ^~~~~~~~~~~
drivers/pinctrl/cirrus/pinctrl-lochnagar.c:200:1: note: in expansion of macro 'LN1_PIN_GPIO'
200 | LN1_PIN_GPIO(CDC_RESET, "codec-reset", RST, CDC_RESET, 1);
| ^~~~~~~~~~~~
>> drivers/pinctrl/cirrus/pinctrl-lochnagar.c:52:53: error: initializer element is not constant
52 | .name = NAME, .type = LN_PTYPE_GPIO, .reg = LOCHNAGAR##REV##_##REG, \
| ^~~~~~~~~
drivers/pinctrl/cirrus/pinctrl-lochnagar.c:67:9: note: in expansion of macro 'LN_PIN_GPIO'
67 | LN_PIN_GPIO(1, ID, NAME, REG, SHIFT, INVERT)
| ^~~~~~~~~~~
drivers/pinctrl/cirrus/pinctrl-lochnagar.c:200:1: note: in expansion of macro 'LN1_PIN_GPIO'
200 | LN1_PIN_GPIO(CDC_RESET, "codec-reset", RST, CDC_RESET, 1);
| ^~~~~~~~~~~~
drivers/pinctrl/cirrus/pinctrl-lochnagar.c:52:53: note: (near initialization for 'lochnagar1_CDC_RESET_pin.reg')
52 | .name = NAME, .type = LN_PTYPE_GPIO, .reg = LOCHNAGAR##REV##_##REG, \
| ^~~~~~~~~
drivers/pinctrl/cirrus/pinctrl-lochnagar.c:67:9: note: in expansion of macro 'LN_PIN_GPIO'
67 | LN_PIN_GPIO(1, ID, NAME, REG, SHIFT, INVERT)
| ^~~~~~~~~~~
drivers/pinctrl/cirrus/pinctrl-lochnagar.c:200:1: note: in expansion of macro 'LN1_PIN_GPIO'
200 | LN1_PIN_GPIO(CDC_RESET, "codec-reset", RST, CDC_RESET, 1);
| ^~~~~~~~~~~~
>> drivers/pinctrl/cirrus/pinctrl-lochnagar.c:52:53: error: pasting "LOCHNAGAR1_" and "(" does not give a valid preprocessing token
52 | .name = NAME, .type = LN_PTYPE_GPIO, .reg = LOCHNAGAR##REV##_##REG, \
| ^~~~~~~~~
drivers/pinctrl/cirrus/pinctrl-lochnagar.c:67:9: note: in expansion of macro 'LN_PIN_GPIO'
67 | LN_PIN_GPIO(1, ID, NAME, REG, SHIFT, INVERT)
| ^~~~~~~~~~~
drivers/pinctrl/cirrus/pinctrl-lochnagar.c:201:1: note: in expansion of macro 'LN1_PIN_GPIO'
201 | LN1_PIN_GPIO(DSP_RESET, "dsp-reset", RST, DSP_RESET, 1);
| ^~~~~~~~~~~~
>> drivers/pinctrl/cirrus/pinctrl-lochnagar.c:52:53: error: initializer element is not constant
52 | .name = NAME, .type = LN_PTYPE_GPIO, .reg = LOCHNAGAR##REV##_##REG, \
| ^~~~~~~~~
drivers/pinctrl/cirrus/pinctrl-lochnagar.c:67:9: note: in expansion of macro 'LN_PIN_GPIO'
67 | LN_PIN_GPIO(1, ID, NAME, REG, SHIFT, INVERT)
| ^~~~~~~~~~~
drivers/pinctrl/cirrus/pinctrl-lochnagar.c:201:1: note: in expansion of macro 'LN1_PIN_GPIO'
201 | LN1_PIN_GPIO(DSP_RESET, "dsp-reset", RST, DSP_RESET, 1);
| ^~~~~~~~~~~~
drivers/pinctrl/cirrus/pinctrl-lochnagar.c:52:53: note: (near initialization for 'lochnagar1_DSP_RESET_pin.reg')
52 | .name = NAME, .type = LN_PTYPE_GPIO, .reg = LOCHNAGAR##REV##_##REG, \
| ^~~~~~~~~
drivers/pinctrl/cirrus/pinctrl-lochnagar.c:67:9: note: in expansion of macro 'LN_PIN_GPIO'
67 | LN_PIN_GPIO(1, ID, NAME, REG, SHIFT, INVERT)
| ^~~~~~~~~~~
drivers/pinctrl/cirrus/pinctrl-lochnagar.c:201:1: note: in expansion of macro 'LN1_PIN_GPIO'
201 | LN1_PIN_GPIO(DSP_RESET, "dsp-reset", RST, DSP_RESET, 1);
| ^~~~~~~~~~~~
cc1: some warnings being treated as errors
vim +52 drivers/pinctrl/cirrus/pinctrl-lochnagar.c
49
50 #define LN_PIN_GPIO(REV, ID, NAME, REG, SHIFT, INVERT) \
51 static const struct lochnagar_pin lochnagar##REV##_##ID##_pin = { \
> 52 .name = NAME, .type = LN_PTYPE_GPIO, .reg = LOCHNAGAR##REV##_##REG, \
53 .shift = LOCHNAGAR##REV##_##SHIFT##_SHIFT, .invert = INVERT, \
54 }
55
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
On Tue, Nov 14, 2023 at 02:40:38PM +0100, Linus Walleij wrote:
> On Tue, Nov 7, 2023 at 6:19 AM kernel test robot <[email protected]> wrote:
>
> > >> drivers/pinctrl/cirrus/pinctrl-lochnagar.c:52:53: error: pasting "LOCHNAGAR1_" and "(" does not give a valid preprocessing token
> > 52 | .name = NAME, .type = LN_PTYPE_GPIO, .reg = LOCHNAGAR##REV##_##REG, \
> > | ^~~~~~~~~
> > drivers/pinctrl/cirrus/pinctrl-lochnagar.c:67:9: note: in expansion of macro 'LN_PIN_GPIO'
> > 67 | LN_PIN_GPIO(1, ID, NAME, REG, SHIFT, INVERT)
> > | ^~~~~~~~~~~
>
> I looked a bit at this, can this be due to the fact that the macros use defines
> from include/dt-bindings/...* and that MIPS does not use these includes
> somehow, such as not using the same dtc compiler?
>
> Rob, do you know the story of how MIPS interoperates with <dt-bindings/*>?
>
Is that what is going on here? I though this was the long standing
problem that MIPS has some global define for RST so the macro that
string pastes that in, no longer pastes in the letters RST but some
value instead.
It has somewhat been on my radar to fix at some point, but I have
in general been a little unsure how to proceed. RST feels like
a mega over generic macro name to be exporting, so in some ways
feels like fixing that would be nice. On the other side, renaming
the register on the Lochnagar side would be very easy, although it
would mean the register naming no longer matches all the hardware
documentation which would be kinda lame.
Thanks,
Charles
On Wed, Nov 15, 2023 at 10:37 AM Charles Keepax
<[email protected]> wrote:
> On Tue, Nov 14, 2023 at 02:40:38PM +0100, Linus Walleij wrote:
> > On Tue, Nov 7, 2023 at 6:19 AM kernel test robot <[email protected]> wrote:
> >
> > > >> drivers/pinctrl/cirrus/pinctrl-lochnagar.c:52:53: error: pasting "LOCHNAGAR1_" and "(" does not give a valid preprocessing token
> > > 52 | .name = NAME, .type = LN_PTYPE_GPIO, .reg = LOCHNAGAR##REV##_##REG, \
> > > | ^~~~~~~~~
> > > drivers/pinctrl/cirrus/pinctrl-lochnagar.c:67:9: note: in expansion of macro 'LN_PIN_GPIO'
> > > 67 | LN_PIN_GPIO(1, ID, NAME, REG, SHIFT, INVERT)
> > > | ^~~~~~~~~~~
> >
> > I looked a bit at this, can this be due to the fact that the macros use defines
> > from include/dt-bindings/...* and that MIPS does not use these includes
> > somehow, such as not using the same dtc compiler?
> >
> > Rob, do you know the story of how MIPS interoperates with <dt-bindings/*>?
> >
>
> Is that what is going on here? I though this was the long standing
> problem that MIPS has some global define for RST so the macro that
> string pastes that in, no longer pastes in the letters RST but some
> value instead.
That sounds plausible :D
> It has somewhat been on my radar to fix at some point, but I have
> in general been a little unsure how to proceed. RST feels like
> a mega over generic macro name to be exporting, so in some ways
> feels like fixing that would be nice. On the other side, renaming
> the register on the Lochnagar side would be very easy, although it
> would mean the register naming no longer matches all the hardware
> documentation which would be kinda lame.
If MIPS breaks things like this because of weird defines I would say
it is actually fair to just quirk it in Kconfig with a comment:
# MIPS occupy very generic defines
depends on !MIPS
Yours,
Linus Walleij
On Wed, Nov 15, 2023 at 10:57:29AM +0100, Linus Walleij wrote:
> On Wed, Nov 15, 2023 at 10:37 AM Charles Keepax
> <[email protected]> wrote:
> > On Tue, Nov 14, 2023 at 02:40:38PM +0100, Linus Walleij wrote:
> > > On Tue, Nov 7, 2023 at 6:19 AM kernel test robot <[email protected]> wrote:
> > It has somewhat been on my radar to fix at some point, but I have
> > in general been a little unsure how to proceed. RST feels like
> > a mega over generic macro name to be exporting, so in some ways
> > feels like fixing that would be nice. On the other side, renaming
> > the register on the Lochnagar side would be very easy, although it
> > would mean the register naming no longer matches all the hardware
> > documentation which would be kinda lame.
>
> If MIPS breaks things like this because of weird defines I would say
> it is actually fair to just quirk it in Kconfig with a comment:
>
> # MIPS occupy very generic defines
> depends on !MIPS
>
Hm... hadn't considered that. The driver is pretty unlikely to be
needed on MIPS anytime soon, so might be a reasonable work around
for now. Would you like me to fire in a patch, or you want to?
Thanks,
Charles
On Wed, Nov 15, 2023 at 11:25 AM Charles Keepax
<[email protected]> wrote:
> On Wed, Nov 15, 2023 at 10:57:29AM +0100, Linus Walleij wrote:
> > On Wed, Nov 15, 2023 at 10:37 AM Charles Keepax
> > <[email protected]> wrote:
> > > On Tue, Nov 14, 2023 at 02:40:38PM +0100, Linus Walleij wrote:
> > > > On Tue, Nov 7, 2023 at 6:19 AM kernel test robot <[email protected]> wrote:
> > > It has somewhat been on my radar to fix at some point, but I have
> > > in general been a little unsure how to proceed. RST feels like
> > > a mega over generic macro name to be exporting, so in some ways
> > > feels like fixing that would be nice. On the other side, renaming
> > > the register on the Lochnagar side would be very easy, although it
> > > would mean the register naming no longer matches all the hardware
> > > documentation which would be kinda lame.
> >
> > If MIPS breaks things like this because of weird defines I would say
> > it is actually fair to just quirk it in Kconfig with a comment:
> >
> > # MIPS occupy very generic defines
> > depends on !MIPS
>
> Hm... hadn't considered that. The driver is pretty unlikely to be
> needed on MIPS anytime soon, so might be a reasonable work around
> for now. Would you like me to fire in a patch, or you want to?
Send it and I'll merge it.
I don't see the value in MIPS compile coverage for this driver,
since it already builds fine with e.g. m68k big endian.
Yours,
Linus Walleij