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. >> 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 _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
