On Thu, 2013-10-24 at 14:23 +0200, Thierry Reding wrote: > To me it sounds more like the sensible default would be to continue to > run with PIO support if the optional properties needed for DMA support > are not present. huge leap backward - need to maintain & test two completely different code paths (might as well fork the driver) - we can no longer claim: "upgrade to mainline, you get all new stuff for free" Today I can 'just' upgrade my kernel and get all improvements in networking stack, fs scalability, ... Before DT, hardware support & drivers improvement were part of that package, now we are proposing they won't. > Determining default values for the properties pretty much defeats the > purpose of putting them in the DT in the first place, doesn't it? my point before DT scenario for my hw crypto driver example: - edit socX.h to add the missing #define HW_CRYPTO_INTERRUPT - edit platform data to add IRQ resource - change driver code to use DMA - single bisectable merge - anyone with socX benefits by just upgrading kernel DTS files are sometimes describing SOCs hardware properties that cannot be changed in any way, these values would better be left in soc-foo.h (where they were before). -- Maxime -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
