[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y8gW0msz0KwkpQaA@smile.fi.intel.com>
Date: Wed, 18 Jan 2023 17:57:06 +0200
From: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To: Marijn Suijten <marijn.suijten@...ainline.org>
Cc: Jonathan Cameron <Jonathan.Cameron@...wei.com>,
Nuno Sá <nuno.sa@...log.com>,
linux-arm-msm@...r.kernel.org, linux-iio@...r.kernel.org,
linux-kernel@...r.kernel.org, Andy Gross <agross@...nel.org>,
Bjorn Andersson <andersson@...nel.org>,
Konrad Dybcio <konrad.dybcio@...aro.org>,
Jonathan Cameron <jic23@...nel.org>,
Lars-Peter Clausen <lars@...afoo.de>
Subject: Re: [PATCH v2 1/1] iio: adc: qcom-spmi-adc5: Fix the channel name
On Wed, Jan 18, 2023 at 04:21:21PM +0100, Marijn Suijten wrote:
> On 2023-01-18 16:29:24, Andy Shevchenko wrote:
...
> > The devm_kstrdup(fwnode_get_name()) is an open coded variant of the above.
> > I don't think we need to open code and produce NIH even a single API. And
> > no, there is no magic behind that. At least from the fwnode point of view.
> >
> > You may very well say that > 1500 instances of "%pOF" is a magic...
>
> Forgive me for not having a clear definition of "open coding" in mind
> (showing a different way of implementing something, compared to the
> "status quo" that I was not yet aware of?), nor knowing what NIH is
> supposed to mean in this context.
"open coding" means to have a copy of the function of macro that is already
implemented and available (even if it's private to some driver or module,
we always can move it to the generic module and header).
NIH: Not Invented Here.
> We're in bike-shedding territory
> anyway, guess I should just bookmark the page that details all the many
> `%` format strings available.
True :-)
...
> > > I find the latter clearer as it doesn't require the reader to figure out
> > > that name - name cancels itself out. Alternatively we can write
> > > strchrnul(name, '@')[0].
> >
> > I don't like to have Pythonisms in the C code, really.
> >
> > P.S. I guess this little patch already emptied my bandwidth, so I leave
> > any further discussion to you and IIO maintainers. Thank you for the
> > review!
>
> Just soaking up kernel coding standards here :)
Right.
--
With Best Regards,
Andy Shevchenko
Powered by blists - more mailing lists