From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Convert the driver to using the new generic GPIO chip interfaces from
linux/gpio/generic.h.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
---
drivers/gpio/gpio-sodaville.c | 20 ++++++++++++++------
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/drivers/gpio/gpio-sodaville.c b/drivers/gpio/gpio-sodaville.c
index abd13c79ace09db228e975f93c92e727d3864ef8..6bc224d3a561077bf3438a70591e1f313ac834f3 100644
--- a/drivers/gpio/gpio-sodaville.c
+++ b/drivers/gpio/gpio-sodaville.c
@@ -9,6 +9,7 @@
#include <linux/errno.h>
#include <linux/gpio/driver.h>
+#include <linux/gpio/generic.h>
#include <linux/init.h>
#include <linux/interrupt.h>
#include <linux/io.h>
@@ -39,7 +40,7 @@ struct sdv_gpio_chip_data {
void __iomem *gpio_pub_base;
struct irq_domain *id;
struct irq_chip_generic *gc;
- struct gpio_chip chip;
+ struct gpio_generic_chip gen_gc;
};
static int sdv_gpio_pub_set_type(struct irq_data *d, unsigned int type)
@@ -180,6 +181,7 @@ static int sdv_register_irqsupport(struct sdv_gpio_chip_data *sd,
static int sdv_gpio_probe(struct pci_dev *pdev,
const struct pci_device_id *pci_id)
{
+ struct gpio_generic_chip_config config;
struct sdv_gpio_chip_data *sd;
int ret;
u32 mux_val;
@@ -206,15 +208,21 @@ static int sdv_gpio_probe(struct pci_dev *pdev,
if (!ret)
writel(mux_val, sd->gpio_pub_base + GPMUXCTL);
- ret = bgpio_init(&sd->chip, &pdev->dev, 4,
- sd->gpio_pub_base + GPINR, sd->gpio_pub_base + GPOUTR,
- NULL, sd->gpio_pub_base + GPOER, NULL, 0);
+ config = (typeof(config)){
+ .dev = &pdev->dev,
+ .sz = 4,
+ .dat = sd->gpio_pub_base + GPINR,
+ .set = sd->gpio_pub_base + GPOUTR,
+ .dirout = sd->gpio_pub_base + GPOER,
+ };
+
+ ret = gpio_generic_chip_init(&sd->gen_gc, &config);
if (ret)
return ret;
- sd->chip.ngpio = SDV_NUM_PUB_GPIOS;
+ sd->gen_gc.gc.ngpio = SDV_NUM_PUB_GPIOS;
- ret = devm_gpiochip_add_data(&pdev->dev, &sd->chip, sd);
+ ret = devm_gpiochip_add_data(&pdev->dev, &sd->gen_gc.gc, sd);
if (ret < 0) {
dev_err(&pdev->dev, "gpiochip_add() failed.\n");
return ret;
--
2.48.1On Tue, Sep 09, 2025 at 11:15:40AM +0200, Bartosz Golaszewski wrote:
>
> Convert the driver to using the new generic GPIO chip interfaces from
> linux/gpio/generic.h.
...
> + config = (typeof(config)){
This looks unusual. Why can't properly formed compound literal be used as in
many other places in the kernel?
> + .dev = &pdev->dev,
> + .sz = 4,
> + .dat = sd->gpio_pub_base + GPINR,
> + .set = sd->gpio_pub_base + GPOUTR,
> + .dirout = sd->gpio_pub_base + GPOER,
> + };
--
With Best Regards,
Andy Shevchenko
On Tue, Sep 9, 2025 at 1:31 PM Andy Shevchenko
<andriy.shevchenko@intel.com> wrote:
>
> On Tue, Sep 09, 2025 at 11:15:40AM +0200, Bartosz Golaszewski wrote:
> >
> > Convert the driver to using the new generic GPIO chip interfaces from
> > linux/gpio/generic.h.
>
> ...
>
> > + config = (typeof(config)){
>
> This looks unusual. Why can't properly formed compound literal be used as in
> many other places in the kernel?
>
It is correct C and checkpatch doesn't raise any warnings. It's the
same kind of argument as between kmalloc(sizeof(struct foo)) vs
kmalloc(sizeof(f)).
I guess it's personal taste but I like this version better.
Bartosz
> > + .dev = &pdev->dev,
> > + .sz = 4,
> > + .dat = sd->gpio_pub_base + GPINR,
> > + .set = sd->gpio_pub_base + GPOUTR,
> > + .dirout = sd->gpio_pub_base + GPOER,
> > + };
On Tue, Sep 09, 2025 at 01:35:04PM +0200, Bartosz Golaszewski wrote:
> On Tue, Sep 9, 2025 at 1:31 PM Andy Shevchenko
> <andriy.shevchenko@intel.com> wrote:
> > On Tue, Sep 09, 2025 at 11:15:40AM +0200, Bartosz Golaszewski wrote:
...
> > > + config = (typeof(config)){
> >
> > This looks unusual. Why can't properly formed compound literal be used as in
> > many other places in the kernel?
>
> It is correct C
If it compiles, it doesn't mean it's correct C, it might be non-standard.
Have you checked with the standard (note, I read that part in the past,
but I may forgot the details, so I don't know the answer to this)?
> and checkpatch doesn't raise any warnings.
checkpatch is far from being useful in the questions like this.
It false positively complains for for_each*() macros all over
the kernel, for example.
> It's the
> same kind of argument as between kmalloc(sizeof(struct foo)) vs
> kmalloc(sizeof(f)).
Maybe, but it introduces a new style while all other cases use the other,
_established_ style. So we have a precedent and the form the code is written
in is against the de facto usage of the compound literals.
> I guess it's personal taste but I like this version better.
In kernel we also try to be consistent. This add inconsistency. Am I wrong?
> > > + .dev = &pdev->dev,
> > > + .sz = 4,
> > > + .dat = sd->gpio_pub_base + GPINR,
> > > + .set = sd->gpio_pub_base + GPOUTR,
> > > + .dirout = sd->gpio_pub_base + GPOER,
> > > + };
--
With Best Regards,
Andy Shevchenko
On Tue, 9 Sep 2025 15:13:04 +0200, Andy Shevchenko
<andriy.shevchenko@intel.com> said:
> On Tue, Sep 09, 2025 at 01:35:04PM +0200, Bartosz Golaszewski wrote:
>> On Tue, Sep 9, 2025 at 1:31 PM Andy Shevchenko
>> <andriy.shevchenko@intel.com> wrote:
>> > On Tue, Sep 09, 2025 at 11:15:40AM +0200, Bartosz Golaszewski wrote:
>
> ...
>
>> > > + config = (typeof(config)){
>> >
>> > This looks unusual. Why can't properly formed compound literal be used as in
>> > many other places in the kernel?
>>
>> It is correct C
>
> If it compiles, it doesn't mean it's correct C, it might be non-standard.
> Have you checked with the standard (note, I read that part in the past,
> but I may forgot the details, so I don't know the answer to this)?
>
It's a GNU extension alright but it's supported in the kernel as it evaluates
to a simple cast.
>> and checkpatch doesn't raise any warnings.
>
> checkpatch is far from being useful in the questions like this.
> It false positively complains for for_each*() macros all over
> the kernel, for example.
>
>> It's the
>> same kind of argument as between kmalloc(sizeof(struct foo)) vs
>> kmalloc(sizeof(f)).
>
> Maybe, but it introduces a new style while all other cases use the other,
> _established_ style. So we have a precedent and the form the code is written
> in is against the de facto usage of the compound literals.
>
It may not be *very* common but it's hardly new style:
$ git grep -P "\(typeof\(.*\)\) ?\{" | wc
108 529 7315
Bart
>> I guess it's personal taste but I like this version better.
>
> In kernel we also try to be consistent. This add inconsistency. Am I wrong?
>
>> > > + .dev = &pdev->dev,
>> > > + .sz = 4,
>> > > + .dat = sd->gpio_pub_base + GPINR,
>> > > + .set = sd->gpio_pub_base + GPOUTR,
>> > > + .dirout = sd->gpio_pub_base + GPOER,
>> > > + };
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
>
On Tue, Sep 09, 2025 at 08:24:23AM -0500, Bartosz Golaszewski wrote:
> On Tue, 9 Sep 2025 15:13:04 +0200, Andy Shevchenko
> <andriy.shevchenko@intel.com> said:
> > On Tue, Sep 09, 2025 at 01:35:04PM +0200, Bartosz Golaszewski wrote:
> >> On Tue, Sep 9, 2025 at 1:31 PM Andy Shevchenko
> >> <andriy.shevchenko@intel.com> wrote:
> >> > On Tue, Sep 09, 2025 at 11:15:40AM +0200, Bartosz Golaszewski wrote:
...
> >> > > + config = (typeof(config)){
> >> >
> >> > This looks unusual. Why can't properly formed compound literal be used as in
> >> > many other places in the kernel?
> >>
> >> It is correct C
> >
> > If it compiles, it doesn't mean it's correct C, it might be non-standard.
> > Have you checked with the standard (note, I read that part in the past,
> > but I may forgot the details, so I don't know the answer to this)?
>
> It's a GNU extension alright
clang, I suppose, also okay with this?
> but it's supported in the kernel as it evaluates
> to a simple cast.
There is no cast. And that's make a big difference to what the code tries to do.
> >> and checkpatch doesn't raise any warnings.
> >
> > checkpatch is far from being useful in the questions like this.
> > It false positively complains for for_each*() macros all over
> > the kernel, for example.
> >
> >> It's the
> >> same kind of argument as between kmalloc(sizeof(struct foo)) vs
> >> kmalloc(sizeof(f)).
> >
> > Maybe, but it introduces a new style while all other cases use the other,
> > _established_ style. So we have a precedent and the form the code is written
> > in is against the de facto usage of the compound literals.
>
> It may not be *very* common but it's hardly new style:
I think your statement is incorrect see below why.
> $ git grep -P "\(typeof\(.*\)\) ?\{" | wc
> 108 529 7315
Not correct. The correct output will be closer to
$ git grep -l -P "\(typeof\(.*\)\) ?\{" | wc -l
15
And if you looked at the output carefully, you see the bug in the RE you used.
So, even closer will be this one:
$ git grep -l -P "=[[:space:]]+\(typeof\(.*\)\) ?\{" | wc -l
7
2 out of which are related to libeth, effectively makes this 6.
No, this is completely non-standard and unusual thing in the kernel.
> >> I guess it's personal taste but I like this version better.
> >
> > In kernel we also try to be consistent. This add inconsistency. Am I wrong?
> >
> >> > > + .dev = &pdev->dev,
> >> > > + .sz = 4,
> >> > > + .dat = sd->gpio_pub_base + GPINR,
> >> > > + .set = sd->gpio_pub_base + GPOUTR,
> >> > > + .dirout = sd->gpio_pub_base + GPOER,
> >> > > + };
--
With Best Regards,
Andy Shevchenko
On Tue, Sep 09, 2025 at 04:45:31PM +0300, Andy Shevchenko wrote:
> On Tue, Sep 09, 2025 at 08:24:23AM -0500, Bartosz Golaszewski wrote:
> > On Tue, 9 Sep 2025 15:13:04 +0200, Andy Shevchenko
> > <andriy.shevchenko@intel.com> said:
> > > On Tue, Sep 09, 2025 at 01:35:04PM +0200, Bartosz Golaszewski wrote:
> > >> On Tue, Sep 9, 2025 at 1:31 PM Andy Shevchenko
> > >> <andriy.shevchenko@intel.com> wrote:
> > >> > On Tue, Sep 09, 2025 at 11:15:40AM +0200, Bartosz Golaszewski wrote:
...
> > >> > > + config = (typeof(config)){
> > >> >
> > >> > This looks unusual. Why can't properly formed compound literal be used as in
> > >> > many other places in the kernel?
> > >>
> > >> It is correct C
> > >
> > > If it compiles, it doesn't mean it's correct C, it might be non-standard.
> > > Have you checked with the standard (note, I read that part in the past,
> > > but I may forgot the details, so I don't know the answer to this)?
> >
> > It's a GNU extension alright
>
> clang, I suppose, also okay with this?
>
> > but it's supported in the kernel as it evaluates
> > to a simple cast.
>
> There is no cast. And that's make a big difference to what the code tries to do.
>
> > >> and checkpatch doesn't raise any warnings.
> > >
> > > checkpatch is far from being useful in the questions like this.
> > > It false positively complains for for_each*() macros all over
> > > the kernel, for example.
> > >
> > >> It's the
> > >> same kind of argument as between kmalloc(sizeof(struct foo)) vs
> > >> kmalloc(sizeof(f)).
> > >
> > > Maybe, but it introduces a new style while all other cases use the other,
> > > _established_ style. So we have a precedent and the form the code is written
> > > in is against the de facto usage of the compound literals.
> >
> > It may not be *very* common but it's hardly new style:
>
> I think your statement is incorrect see below why.
>
> > $ git grep -P "\(typeof\(.*\)\) ?\{" | wc
> > 108 529 7315
>
> Not correct. The correct output will be closer to
>
> $ git grep -l -P "\(typeof\(.*\)\) ?\{" | wc -l
> 15
>
> And if you looked at the output carefully, you see the bug in the RE you used.
>
> So, even closer will be this one:
>
> $ git grep -l -P "=[[:space:]]+\(typeof\(.*\)\) ?\{" | wc -l
> 7
>
> 2 out of which are related to libeth, effectively makes this 6.
TBH, I think those 6 all made the same mistake, i.e. thinking of the compound
literal as a cast. Which is not!
> No, this is completely non-standard and unusual thing in the kernel.
>
> > >> I guess it's personal taste but I like this version better.
> > >
> > > In kernel we also try to be consistent. This add inconsistency. Am I wrong?
> > >
> > >> > > + .dev = &pdev->dev,
> > >> > > + .sz = 4,
> > >> > > + .dat = sd->gpio_pub_base + GPINR,
> > >> > > + .set = sd->gpio_pub_base + GPOUTR,
> > >> > > + .dirout = sd->gpio_pub_base + GPOER,
> > >> > > + };
--
With Best Regards,
Andy Shevchenko
On Tue, Sep 09, 2025 at 04:47:09PM +0300, Andy Shevchenko wrote:
> On Tue, Sep 09, 2025 at 04:45:31PM +0300, Andy Shevchenko wrote:
> > On Tue, Sep 09, 2025 at 08:24:23AM -0500, Bartosz Golaszewski wrote:
> > > On Tue, 9 Sep 2025 15:13:04 +0200, Andy Shevchenko
> > > <andriy.shevchenko@intel.com> said:
> > > > On Tue, Sep 09, 2025 at 01:35:04PM +0200, Bartosz Golaszewski wrote:
> > > >> On Tue, Sep 9, 2025 at 1:31 PM Andy Shevchenko
> > > >> <andriy.shevchenko@intel.com> wrote:
> > > >> > On Tue, Sep 09, 2025 at 11:15:40AM +0200, Bartosz Golaszewski wrote:
...
> > > >> > > + config = (typeof(config)){
> > > >> >
> > > >> > This looks unusual. Why can't properly formed compound literal be used as in
> > > >> > many other places in the kernel?
> > > >>
> > > >> It is correct C
> > > >
> > > > If it compiles, it doesn't mean it's correct C, it might be non-standard.
> > > > Have you checked with the standard (note, I read that part in the past,
> > > > but I may forgot the details, so I don't know the answer to this)?
> > >
> > > It's a GNU extension alright
> >
> > clang, I suppose, also okay with this?
> >
> > > but it's supported in the kernel as it evaluates
> > > to a simple cast.
> >
> > There is no cast. And that's make a big difference to what the code tries to do.
> >
> > > >> and checkpatch doesn't raise any warnings.
> > > >
> > > > checkpatch is far from being useful in the questions like this.
> > > > It false positively complains for for_each*() macros all over
> > > > the kernel, for example.
> > > >
> > > >> It's the
> > > >> same kind of argument as between kmalloc(sizeof(struct foo)) vs
> > > >> kmalloc(sizeof(f)).
> > > >
> > > > Maybe, but it introduces a new style while all other cases use the other,
> > > > _established_ style. So we have a precedent and the form the code is written
> > > > in is against the de facto usage of the compound literals.
> > >
> > > It may not be *very* common but it's hardly new style:
> >
> > I think your statement is incorrect see below why.
> >
> > > $ git grep -P "\(typeof\(.*\)\) ?\{" | wc
> > > 108 529 7315
> >
> > Not correct. The correct output will be closer to
> >
> > $ git grep -l -P "\(typeof\(.*\)\) ?\{" | wc -l
> > 15
> >
> > And if you looked at the output carefully, you see the bug in the RE you used.
> >
> > So, even closer will be this one:
> >
> > $ git grep -l -P "=[[:space:]]+\(typeof\(.*\)\) ?\{" | wc -l
> > 7
> >
> > 2 out of which are related to libeth, effectively makes this 6.
And for of fullness the picture:
$ git grep -l -P "=[[:space:]]+\(struct [^[:space:]]*\) ?\{" | wc -l
501
So, it's 1:100 ratio.
> TBH, I think those 6 all made the same mistake, i.e. thinking of the compound
> literal as a cast. Which is not!
>
> > No, this is completely non-standard and unusual thing in the kernel.
> >
> > > >> I guess it's personal taste but I like this version better.
> > > >
> > > > In kernel we also try to be consistent. This add inconsistency. Am I wrong?
> > > >
> > > >> > > + .dev = &pdev->dev,
> > > >> > > + .sz = 4,
> > > >> > > + .dat = sd->gpio_pub_base + GPINR,
> > > >> > > + .set = sd->gpio_pub_base + GPOUTR,
> > > >> > > + .dirout = sd->gpio_pub_base + GPOER,
> > > >> > > + };
--
With Best Regards,
Andy Shevchenko
On Tue, Sep 9, 2025 at 3:47 PM Andy Shevchenko <andriy.shevchenko@intel.com> wrote: > > TBH, I think those 6 all made the same mistake, i.e. thinking of the compound > literal as a cast. Which is not! > What do you suggest? And are we not allowed to use C99 features now anyway? Bartosz
On Tue, Sep 09, 2025 at 03:56:41PM +0200, Bartosz Golaszewski wrote:
> On Tue, Sep 9, 2025 at 3:47 PM Andy Shevchenko
> <andriy.shevchenko@intel.com> wrote:
> >
> > TBH, I think those 6 all made the same mistake, i.e. thinking of the compound
> > literal as a cast. Which is not!
>
> What do you suggest?
Write it in less odd way :-)
foo = (struct bar) { ... };
> And are we not allowed to use C99 features now anyway?
It's fine, it's not about the C standard number.
--
With Best Regards,
Andy Shevchenko
On Tue, Sep 9, 2025 at 4:02 PM Andy Shevchenko
<andriy.shevchenko@intel.com> wrote:
>
> On Tue, Sep 09, 2025 at 03:56:41PM +0200, Bartosz Golaszewski wrote:
> > On Tue, Sep 9, 2025 at 3:47 PM Andy Shevchenko
> > <andriy.shevchenko@intel.com> wrote:
> > >
> > > TBH, I think those 6 all made the same mistake, i.e. thinking of the compound
> > > literal as a cast. Which is not!
> >
> > What do you suggest?
>
> Write it in less odd way :-)
>
> foo = (struct bar) { ... };
I don't get your reasoning. typeof() itself is well established in the
kernel and doesn't
foo = (struct bar){ ... };
evaluate to the same thing as
foo = (typeof(foo)){ ... };
? Isn't it still the same compound literal?
Bartosz
>
> > And are we not allowed to use C99 features now anyway?
>
> It's fine, it's not about the C standard number.
>
On Tue, Sep 9, 2025 at 5:05 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> On Tue, Sep 9, 2025 at 4:02 PM Andy Shevchenko
> <andriy.shevchenko@intel.com> wrote:
> > On Tue, Sep 09, 2025 at 03:56:41PM +0200, Bartosz Golaszewski wrote:
> > > On Tue, Sep 9, 2025 at 3:47 PM Andy Shevchenko
> > > <andriy.shevchenko@intel.com> wrote:
...
> > > > TBH, I think those 6 all made the same mistake, i.e. thinking of the compound
> > > > literal as a cast. Which is not!
> > >
> > > What do you suggest?
> >
> > Write it in less odd way :-)
> >
> > foo = (struct bar) { ... };
>
> I don't get your reasoning. typeof() itself is well established in the
> kernel and doesn't
>
> foo = (struct bar){ ... };
>
> evaluate to the same thing as
>
> foo = (typeof(foo)){ ... };
>
> ? Isn't it still the same compound literal?
It makes it so, but typeof() usually is used for casts and not for
compound literals. That's (usage typeof() for compound literals) what
I am against in this case.
> > > And are we not allowed to use C99 features now anyway?
> >
> > It's fine, it's not about the C standard number.
--
With Best Regards,
Andy Shevchenko
On Tue, Sep 9, 2025 at 6:15 PM Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
> On Tue, Sep 9, 2025 at 5:05 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> > On Tue, Sep 9, 2025 at 4:02 PM Andy Shevchenko
> > <andriy.shevchenko@intel.com> wrote:
> > > On Tue, Sep 09, 2025 at 03:56:41PM +0200, Bartosz Golaszewski wrote:
> > > > On Tue, Sep 9, 2025 at 3:47 PM Andy Shevchenko
> > > > <andriy.shevchenko@intel.com> wrote:
...
> > > > > TBH, I think those 6 all made the same mistake, i.e. thinking of the compound
> > > > > literal as a cast. Which is not!
> > > >
> > > > What do you suggest?
> > >
> > > Write it in less odd way :-)
> > >
> > > foo = (struct bar) { ... };
> >
> > I don't get your reasoning. typeof() itself is well established in the
> > kernel and doesn't
> >
> > foo = (struct bar){ ... };
> >
> > evaluate to the same thing as
> >
> > foo = (typeof(foo)){ ... };
> >
> > ? Isn't it still the same compound literal?
>
> It makes it so, but typeof() usually is used for casts and not for
> compound literals. That's (usage typeof() for compound literals) what
> I am against in this case.
FWIW, brief googling showed that nobody (okay, I haven't found yet
reddit/SO/GCC or LLVM documentation) uses typeof() for compound
literals. So, this makes me feel right, that the form of typeof() is
weird and works due to unknown reasons. Any pointers to the
documentation you read about it?
> > > > And are we not allowed to use C99 features now anyway?
> > >
> > > It's fine, it's not about the C standard number.
E.g., https://gcc.gnu.org/onlinedocs/gcc-15.1.0/gcc/Compound-Literals.html
(8.1.0 is the same).
--
With Best Regards,
Andy Shevchenko
On Tue, Sep 9, 2025 at 5:26 PM Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
>
> On Tue, Sep 9, 2025 at 6:15 PM Andy Shevchenko
> <andy.shevchenko@gmail.com> wrote:
> > On Tue, Sep 9, 2025 at 5:05 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> > > On Tue, Sep 9, 2025 at 4:02 PM Andy Shevchenko
> > > <andriy.shevchenko@intel.com> wrote:
> > > > On Tue, Sep 09, 2025 at 03:56:41PM +0200, Bartosz Golaszewski wrote:
> > > > > On Tue, Sep 9, 2025 at 3:47 PM Andy Shevchenko
> > > > > <andriy.shevchenko@intel.com> wrote:
>
> ...
>
> > > > > > TBH, I think those 6 all made the same mistake, i.e. thinking of the compound
> > > > > > literal as a cast. Which is not!
> > > > >
> > > > > What do you suggest?
> > > >
> > > > Write it in less odd way :-)
> > > >
> > > > foo = (struct bar) { ... };
> > >
> > > I don't get your reasoning. typeof() itself is well established in the
> > > kernel and doesn't
> > >
> > > foo = (struct bar){ ... };
> > >
> > > evaluate to the same thing as
> > >
> > > foo = (typeof(foo)){ ... };
> > >
> > > ? Isn't it still the same compound literal?
> >
> > It makes it so, but typeof() usually is used for casts and not for
> > compound literals. That's (usage typeof() for compound literals) what
> > I am against in this case.
>
> FWIW, brief googling showed that nobody (okay, I haven't found yet
> reddit/SO/GCC or LLVM documentation) uses typeof() for compound
> literals. So, this makes me feel right, that the form of typeof() is
> weird and works due to unknown reasons. Any pointers to the
> documentation you read about it?
>
Ok I'll change it. I also need to change it in existing patches that
already landed in next then.
> > > > > And are we not allowed to use C99 features now anyway?
> > > >
> > > > It's fine, it's not about the C standard number.
>
> E.g., https://gcc.gnu.org/onlinedocs/gcc-15.1.0/gcc/Compound-Literals.html
> (8.1.0 is the same).
>
I get it, I understood incorrectly how they work, no need to rub it in. :)
Bart
© 2016 - 2025 Red Hat, Inc.