From: Takashi Iwai <tiwai@suse.de>
To: Richard Fitzgerald <rf@opensource.cirrus.com>
Cc: Nick Desaulniers <ndesaulniers@google.com>, <tiwai@suse.com>,
<alsa-devel@alsa-project.org>, <patches@opensource.cirrus.com>,
<linux-kernel@vger.kernel.org>, <llvm@lists.linux.dev>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Daniel Scally <djrscally@gmail.com>,
Heikki Krogerus <heikki.krogerus@linux.intel.com>,
Sakari Ailus <sakari.ailus@linux.intel.com>,
<linux-acpi@vger.kernel.org>
Subject: Re: [PATCH 2/2] ALSA: hda: cirrus_scodec: Add KUnit test
Date: Wed, 20 Sep 2023 10:42:18 +0200 [thread overview]
Message-ID: <87o7hxutg5.wl-tiwai@suse.de> (raw)
In-Reply-To: <9e2291c1-9a6c-ba6b-ea0f-ad130d2596f4@opensource.cirrus.com>
On Wed, 20 Sep 2023 10:27:58 +0200,
Richard Fitzgerald wrote:
>
> On 20/9/23 07:51, Takashi Iwai wrote:
> > On Tue, 19 Sep 2023 22:44:28 +0200,
> > Nick Desaulniers wrote:
> >>
> >> On Mon, Sep 18, 2023 at 10:51:29AM +0100, Richard Fitzgerald wrote:
> > (snip)
> >>> +static void cirrus_scodec_test_set_gpio_ref_arg(struct software_node_ref_args *arg,
> >>> + int gpio_num)
> >>> +{
> >>> + struct software_node_ref_args template =
> >>> + SOFTWARE_NODE_REFERENCE(&cirrus_scodec_test_gpio_swnode, gpio_num, 0);
> >>
> >> I'm observing the following error when building with:
> >>
> >> $ make LLVM=1 -j128 allmodconfig sound/pci/hda/cirrus_scodec_test.o
> >>
> >> sound/pci/hda/cirrus_scodec_test.c:151:60: error: initializer element is not a compile-time constant
> >> 151 | SOFTWARE_NODE_REFERENCE(&cirrus_scodec_test_gpio_swnode, gpio_num, 0);
> >> | ^~~~~~~~
> >> /builds/linux/include/linux/property.h:291:37: note: expanded from macro 'SOFTWARE_NODE_REFERENCE'
> >> 291 | .nargs = ARRAY_SIZE(((u64[]){ 0, ##__VA_ARGS__ })) - 1, \
> >> | ^~~~~~~~~~~
> >> /builds/linux/include/linux/kernel.h:57:75: note: expanded from macro 'ARRAY_SIZE'
> >> 57 | #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + __must_be_array(arr))
> >> | ^~~
> >> /builds/linux/include/linux/compiler.h:228:59: note: expanded from macro '__must_be_array'
> >> 228 | #define __must_be_array(a) BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0]))
> >> | ^
> >> /builds/linux/include/linux/compiler_types.h:366:63: note: expanded from macro '__same_type'
> >> 366 | #define __same_type(a, b) __builtin_types_compatible_p(typeof(a), typeof(b))
> >> | ^
> >> /builds/linux/include/linux/build_bug.h:16:62: note: expanded from macro 'BUILD_BUG_ON_ZERO'
> >> 16 | #define BUILD_BUG_ON_ZERO(e) ((int)(sizeof(struct { int:(-!!(e)); })))
> >> | ^
> >
> > Hm, this looks like some inconsistent handling of the temporary array
> > passed to ARRAY_SIZE() in the SOFTWARE_NODE_REFERENCE macro. LLVM
> > can't treat it if it contains a variable in the given array, while GCC
> > doesn't care.
> >
> > A hackish workaround would be the patch like below, but it's really
> > ugly. Ideally speaking, it should be fixed in linux/properties.h, but
> > I have no idea how to fix there for LLVM.
> >
> > Adding more relevant people to Cc.
> >
> >
> > thanks,
> >
> > Takashi
> >
> > --- a/sound/pci/hda/cirrus_scodec_test.c
> > +++ b/sound/pci/hda/cirrus_scodec_test.c
> > @@ -148,8 +148,9 @@ static void cirrus_scodec_test_set_gpio_ref_arg(struct software_node_ref_args *a
> > int gpio_num)
> > {
> > struct software_node_ref_args template =
> > - SOFTWARE_NODE_REFERENCE(&cirrus_scodec_test_gpio_swnode, gpio_num, 0);
> > + SOFTWARE_NODE_REFERENCE(&cirrus_scodec_test_gpio_swnode, 0, 0);
> > + template.args[0] = gpio_num;
> > *arg = template;
> > }
> >
>
> The tests must generate sw nodes dynamically, not a fixed const struct.
> I wanted to avoid directly accessing the internals of the SW node
> structures. Use only the macros.
>
> I can rewrite this code to open-code the construction of the
> software_node_ref_args. Or I can wait a while in case anyone has a
> suggested fix for the macros.
>
> Its seems reasonable that you should be able to create software nodes
> dynamically. A "real" use of these might need to construct the data from
> some other data that is not known at runtime (for example, where the
> ACPI provides some information but not the necessary info).
Yeah, fixing the macro would be ideal.
An easy and compromise solution would be to factor out the
ARRAY_SIZE() call and allow giving nargs explicitly.
e.g.
--- a/include/linux/property.h
+++ b/include/linux/property.h
@@ -285,13 +285,18 @@ struct software_node_ref_args {
u64 args[NR_FWNODE_REFERENCE_ARGS];
};
-#define SOFTWARE_NODE_REFERENCE(_ref_, ...) \
+#define __SOFTWARE_NODE_REFERENCE(_ref_, _nargs_, ...) \
(const struct software_node_ref_args) { \
.node = _ref_, \
- .nargs = ARRAY_SIZE(((u64[]){ 0, ##__VA_ARGS__ })) - 1, \
+ .nargs = _nargs_, \
.args = { __VA_ARGS__ }, \
}
+#define SOFTWARE_NODE_REFERENCE(_ref_, ...) \
+ __SOFTWARE_NODE_REFERENCE(_ref_,\
+ ARRAY_SIZE(((u64[]){ 0, ##__VA_ARGS__ })) - 1,\
+ ##__VA_ARGS__)
+
/**
* struct property_entry - "Built-in" device property representation.
* @name: Name of the property.
--- a/sound/pci/hda/cirrus_scodec_test.c
+++ b/sound/pci/hda/cirrus_scodec_test.c
@@ -148,7 +148,7 @@ static void cirrus_scodec_test_set_gpio_ref_arg(struct software_node_ref_args *a
int gpio_num)
{
struct software_node_ref_args template =
- SOFTWARE_NODE_REFERENCE(&cirrus_scodec_test_gpio_swnode, gpio_num, 0);
+ __SOFTWARE_NODE_REFERENCE(&cirrus_scodec_test_gpio_swnode, 2, gpio_num, 0);
*arg = template;
}
... though I'm not convinced by this change, either.
Takashi
next prev parent reply other threads:[~2023-09-20 8:43 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-18 9:51 [PATCH 0/2] ALSA: hda: cs35l56: Handle speaker id GPIOs Richard Fitzgerald
2023-09-18 9:51 ` [PATCH 1/2] ALSA: hda: cs35l56: Add support for speaker id Richard Fitzgerald
2023-09-18 9:51 ` [PATCH 2/2] ALSA: hda: cirrus_scodec: Add KUnit test Richard Fitzgerald
2023-09-19 20:44 ` Nick Desaulniers
2023-09-20 6:51 ` Takashi Iwai
2023-09-20 8:27 ` Richard Fitzgerald
2023-09-20 8:42 ` Takashi Iwai [this message]
2023-09-20 15:19 ` Andy Shevchenko
2023-09-18 15:50 ` [PATCH 0/2] ALSA: hda: cs35l56: Handle speaker id GPIOs Takashi Iwai
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87o7hxutg5.wl-tiwai@suse.de \
--to=tiwai@suse.de \
--cc=alsa-devel@alsa-project.org \
--cc=andriy.shevchenko@linux.intel.com \
--cc=djrscally@gmail.com \
--cc=heikki.krogerus@linux.intel.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=llvm@lists.linux.dev \
--cc=ndesaulniers@google.com \
--cc=patches@opensource.cirrus.com \
--cc=rf@opensource.cirrus.com \
--cc=sakari.ailus@linux.intel.com \
--cc=tiwai@suse.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.