[PATCH 13/15] gpio: sodaville: use new generic GPIO chip API
Andy Shevchenko
andy.shevchenko at gmail.com
Tue Sep 9 08:25:45 PDT 2025
On Tue, Sep 9, 2025 at 6:15 PM Andy Shevchenko
<andy.shevchenko at gmail.com> wrote:
> On Tue, Sep 9, 2025 at 5:05 PM Bartosz Golaszewski <brgl at bgdev.pl> wrote:
> > On Tue, Sep 9, 2025 at 4:02 PM Andy Shevchenko
> > <andriy.shevchenko at 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 at 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
More information about the linux-riscv
mailing list