[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5959b123-09e3-474b-9ab0-68d71cfdd9a2@sirena.org.uk>
Date: Tue, 11 Jul 2023 15:14:54 +0100
From: Mark Brown <broonie@...nel.org>
To: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc: Cristian Ciocaltea <cristian.ciocaltea@...labora.com>,
Yang Yingliang <yangyingliang@...wei.com>,
Amit Kumar Mahapatra via Alsa-devel <alsa-devel@...a-project.org>,
Neil Armstrong <neil.armstrong@...aro.org>,
Tharun Kumar P <tharunkumar.pasumarthi@...rochip.com>,
Vijaya Krishna Nivarthi <quic_vnivarth@...cinc.com>,
Uwe Kleine-König <u.kleine-koenig@...gutronix.de>,
linux-spi@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org,
linux-amlogic@...ts.infradead.org,
linux-mediatek@...ts.infradead.org, linux-arm-msm@...r.kernel.org,
linux-rockchip@...ts.infradead.org, linux-riscv@...ts.infradead.org,
linux-stm32@...md-mailman.stormreply.com,
linux-trace-kernel@...r.kernel.org, netdev@...r.kernel.org,
Sanjay R Mehta <sanju.mehta@....com>,
Radu Pirea <radu_nicolae.pirea@....ro>,
Nicolas Ferre <nicolas.ferre@...rochip.com>,
Alexandre Belloni <alexandre.belloni@...tlin.com>,
Claudiu Beznea <claudiu.beznea@...rochip.com>,
Tudor Ambarus <tudor.ambarus@...aro.org>,
Serge Semin <fancer.lancer@...il.com>,
Shawn Guo <shawnguo@...nel.org>,
Sascha Hauer <s.hauer@...gutronix.de>,
Pengutronix Kernel Team <kernel@...gutronix.de>,
Fabio Estevam <festevam@...il.com>,
NXP Linux Team <linux-imx@....com>,
Kevin Hilman <khilman@...libre.com>,
Jerome Brunet <jbrunet@...libre.com>,
Martin Blumenstingl <martin.blumenstingl@...glemail.com>,
Matthias Brugger <matthias.bgg@...il.com>,
AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>,
Andy Gross <agross@...nel.org>,
Bjorn Andersson <andersson@...nel.org>,
Konrad Dybcio <konrad.dybcio@...aro.org>,
Heiko Stuebner <heiko@...ech.de>,
Palmer Dabbelt <palmer@...belt.com>,
Paul Walmsley <paul.walmsley@...ive.com>,
Orson Zhai <orsonzhai@...il.com>,
Baolin Wang <baolin.wang@...ux.alibaba.com>,
Chunyan Zhang <zhang.lyra@...il.com>,
Alain Volmat <alain.volmat@...s.st.com>,
Maxime Coquelin <mcoquelin.stm32@...il.com>,
Alexandre Torgue <alexandre.torgue@...s.st.com>,
Max Filippov <jcmvbkbc@...il.com>,
Steven Rostedt <rostedt@...dmis.org>,
Masami Hiramatsu <mhiramat@...nel.org>,
Richard Cochran <richardcochran@...il.com>
Subject: Re: [PATCH v2 04/15] spi: Replace open coded
spi_controller_xfer_timeout()
On Tue, Jul 11, 2023 at 02:01:13PM +0300, Andy Shevchenko wrote:
> On Mon, Jul 10, 2023 at 06:30:32PM +0100, Mark Brown wrote:
> > On Mon, Jul 10, 2023 at 06:49:21PM +0300, Andy Shevchenko wrote:
> > > + * Assume speed to be 100 kHz if it's not defined at the time of invocation.
> > You didn't mention this bit in the changelog, and I'm not 100% convinced
> > it was the best idea in the first place. It's going to result in some
> > very big timeouts if it goes off, and we really should be doing
> > validation much earlier in the process.
> Okay, let's drop this change.
Like I say we *should* be fine with the refactoring without this, or at
least if it's an issue we should improve the validation.
> > > + u32 speed_hz = xfer->speed_hz ?: 100000;
> > Not only the ternery operator, but the version without the second
> > argument for extra clarity!
> Elvis can be interpreted as "A _or_ B (if A is false/0)".
> Some pieces related to SPI use Elvis already IIRC.
I understand what it means, I just don't find it's adding clarity most
of the times it's used (there's a few places where it is useful like
pasting in strings in formats). There are some examples that I'd
complain about in the code, most of them predating me working on SPI too
much, but I'm not a fan.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists