Hi, Andy Shevchenko <andy.shevchenko@xxxxxxxxx> 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? Take a breather Andy, you need it. Winter sure is coming >> >> > +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. In non-debug builds, when tracers are enabled a thunk will be added for runtime patching ;-) (IIRC) -- balbi