Anton Vorontsov wrote:

Well, I'm indeed removing [further] support for the par_io nodes,
overwriting it with gpio nodes. That way we'll stop new use cases of
these nodes.

I have no problem with replacing par_io nodes with gpio nodes.

Eventually I plan to adjust the existing code/device trees accordingly.
If you think that code should be adjusted at the same time as
documentation, I'm fine with it as well. I'll just add new documentation
instead of replacing the old.

Yes, please.

quoted

You can't just delete the par_io documentation without updating the code and
planning for feature removal.  Almost all of the existing code out there for QE
boards expects a par_io node, and the device trees still have them.

Yup, exactly. Old device tree still use them, but don't we want to get
rid of this? If so, we should remove documentation, or someone will
use it for the new device trees. ;-)

It should still be documented, but marked as deprecated.  The documentation can
be removed only when all the DTS files *and* the code are scrubbed of those
kinds of nodes.  And you can't remove backwards compatibility for those from the
code until at least the next major revision of the kernel.

Look at function of_get_mac_address() for an example.  "mac-address" was removed
mid last year, but we still support them.  Try to isolate the code that support
the newer gpio nodes and the  older par_io nodes into one function, and it'll be
easier to deal with.

-- 
Timur Tabi
Linux kernel developer at Freescale