[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHp75VcwbVh7K=UMgiJ1QpaeB_f_==K4Ewzjt5OwYcOAXqiyUw@mail.gmail.com>
Date: Fri, 29 Oct 2021 15:56:33 +0300
From: Andy Shevchenko <andy.shevchenko@...il.com>
To: Felipe Balbi <balbi@...nel.org>
Cc: Jarrett Schultz <jaschultzms@...il.com>,
Rob Herring <robh+dt@...nel.org>,
Andy Gross <agross@...nel.org>,
Bjorn Andersson <bjorn.andersson@...aro.org>,
Hans de Goede <hdegoede@...hat.com>,
Mark Gross <mgross@...ux.intel.com>,
Maximilian Luz <luzmaximilian@...il.com>,
"linux-arm-msm@...r.kernel.org" <linux-arm-msm@...r.kernel.org>,
"platform-driver-x86@...r.kernel.org"
<platform-driver-x86@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Jarrett Schultz <jaschultz@...rosoft.com>
Subject: Re: [PATCH 2/3] platform: surface: Add surface xbl
On Fri, Oct 29, 2021 at 3:34 PM Felipe Balbi <balbi@...nel.org> wrote:
> Andy Shevchenko <andy.shevchenko@...il.com> writes:
> > On Fri, Oct 29, 2021 at 7:48 AM Felipe Balbi <balbi@...nel.org> wrote:
> >> Andy Shevchenko <andy.shevchenko@...il.com> writes:
...
> >> > Capital L will be better to read and understand the
> >> > abbreviation. Actually usually we do something like this:
> >> >
> >> > Extensible Boot Loader (EBL)
> >>
> >> nah, this is silly Andy. It's just capitalized as eXtensible Boot
> >> Loader, very much akin to eXtensible Host Controller Interface.
> >
> > My point here is to have a full name followed by the abbreviation. and
> > n(O)t in (F)ancy st(Y)le.
>
> too bad my patch removing acronyms from the kernel got rejects :-p
>
> Seriously, this is pretty pointless. You're vouching for something that
> will just cause confusion. Every piece of internal documentation refers
> to xbl and you want this to be renamed to ebl because it looks nicer for
> you. Thanks, but no thanks.
Maybe I was too unclear. I'm not pushing for EBL, I'm pushing for the form os
"Foo bAr BullSh*t (FABS)" vs. "(F)oo b(a)r (B)ull(s)h*t".
If you have x there to be capitalized, do it like "eXtensible Boot
Loader (XBL)". Is it too hard?
...
> >> > +static const struct attribute_group inputs_attr_group = {
> >> > + .attrs = inputs_attrs,
> >> > +};
> >> > +
> >> > +static u8 surface_xbl_readb(void __iomem *base, u32 offset)
> >> > +{
> >> > + return readb(base + offset);
> >> > +}
> >> > +
> >> > +static u16 surface_xbl_readw(void __iomem *base, u32 offset)
> >> > +{
> >> > + return readw(base + offset);
> >> > +}
> >> >
> >> > Either use corresponding io accessors in-line, or make first parameter
> >> > to be sirface_xbl pointer. Otherwise these helpers useless.
> >>
> >> I agree with passing surface_xbl point as first parameter, but calling
> >> the accessors pointless is a bit much. At a minimum, they make it easier
> >> to ftrace the entire driver by simply ftracing surface_xbl_*
> >
> > My point is that the above seems half-baked. It's pointless to have a
> > func(a,b) { return readl(a + b); }. It doesn't add value.
>
> sure it does. echo surface_xbl_* > ftrace_filter_function (or whatever
> the filename was) it reason enough IMHO. Not to mention that these
> little accessors will likely be optimized by the compiler.
readl() will appear in the traces, no? But yeah I also was thinking
about the weakness in your argument that the compiler can silently
inline them anyway.
--
With Best Regards,
Andy Shevchenko
Powered by blists - more mailing lists