[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201123191057.GR6322@sirena.org.uk>
Date: Mon, 23 Nov 2020 19:10:57 +0000
From: Mark Brown <broonie@...nel.org>
To: Cristian Marussi <cristian.marussi@....com>
Cc: linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
devicetree@...r.kernel.org, sudeep.holla@....com,
lukasz.luba@....com, james.quinlan@...adcom.com,
Jonathan.Cameron@...wei.com, robh@...nel.org,
satyakim@....qualcomm.com, etienne.carriere@...aro.org,
f.fainelli@...il.com, vincent.guittot@...aro.org,
souvik.chakravarty@....com
Subject: Re: [PATCH v6 5/5] regulator: add SCMI driver
On Mon, Nov 23, 2020 at 06:49:56PM +0000, Cristian Marussi wrote:
> On Mon, Nov 23, 2020 at 05:49:41PM +0000, Mark Brown wrote:
> > On Thu, Nov 19, 2020 at 07:10:51PM +0000, Cristian Marussi wrote:
> > > + rinfo->num_doms = num_doms;
> > > + /*
> > Several places like this with missing blank lines.
> What do you mean ? a blank before the comment ?
> Sorry but checkpatch --strict does not complain, I was not aware of
> this styling. I'll do (if you confirm that's what you want)
Yes, a blank line between separate semantic blocks. This is normal
coding style for the kernel, while checkpatch being a very simple script
can't detect it it's surprising that this seems surprising to you.
> How do you prefer these changes (and the DT one) ?
> All as followup patches in a V7 series on top of
> sudeep/for-next/scmi-voltage ?
Incremental patches on top of what's applied.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists