On Wed, May 13, 2020 at 12:21:16PM +0100, Mark Brown wrote:

On Wed, May 13, 2020 at 02:04:07PM +0300, Serge Semin wrote:

quoted

On Wed, May 13, 2020 at 11:23:24AM +0100, Mark Brown wrote:

quoted

quoted

The conversion to YAML format should be the very last thing in the patch
series,

quoted

Hm, haven't heard about this requirement. Could you point me out to a doc or
some discussion concerning this for future reference? It's not a first DT
conversion patch I've submitted and non of them were addressed with such
request. I do understand that the order of DT concerning patches can be
important and agree to fix it by updating the original legacy binding first,
then perform a conversion. But placing the conversion in a tail of the series
just seems unnecessary. The patch can be dropped from any place of the series
if for some reason Rob would be late with review.

This is a practical observation based on the fact that there is a huge
backlog of reviews of DT binding conversions and that those conversions
typically go through several review cycles and that not everyone who's
sending patches to the kernel is fully up to speed on processes or has
strong English.  By telling people (including other people who find
instructions on the list) to put the conversion right at the end of the
series I am avoiding any ambiguity or confusion about ordering with
regard to any other patches to the DT, including any new patches that
get added to the series.

quoted

Personally I prefer placing all DT changes in the head of the series, so Rob
wouldn't need to search through the whole patchset looking for the DT-related
patches.

Ideally the YAML conversions would be done entirely separately to other
development rather than as part of a bigger series, they're pretty much
orthogonal anyway.  Sadly there's obvious content collisions with any
new development that adds DT stuff so that's not always the most
practical thing.

Ok. I see your point. I'll move the conversion patch to the tail of the series
after rebasing the patchset on top of the spi/for-next branch. Thanks for
clarification.

-Sergey