On 08/06/2018 01:57 AM, Geert Uytterhoeven wrote: > On the platform side, there will be a big difference between mostly legacy > SH and new DT-based j-core on the 32-bit bit side, and mostly new DT-based > j-core on the 64-bit side. At $DAYJOB I'm working on a sh7760 board with platform data (the open source release of the linux patches for which looks like it'll miss this merge window but might hit next one; they only want to run everything through the lawyers once so legal clearance waits until we're done fiddling). The device tree people break platform data support because they only test device tree, and then refuse patches to make the existing platform data work again. For example, I have this bookmarked: http://lkml.iu.edu/hypermail/linux/kernel/1807.0/05252.html In case I ever have time to go back and look at it, but I've moved on to other things already. (My current "circle back to poke at it as I have time" is trying to get DMAEngine working for sh7760 with the smc91x.c.) The fix I sent upstream for the LEDs is the fix we're shipping with. It's the simple, obvious, "make it work exactly like it used to work", and they went "nah, we don't want to do that, do something else that will require changing the platform data that worked before our commit". (See longish thread, above. The reply I bookmarked was the polite one.) I'm aware there's a problem regression testing old hardware, which limits conversion of that old hardware to device tree. But the people who _have_ old hardware continue to run old kernels because upgrading to current kernels doesn't _work_. And then when we make it work, our patches to make it work get rejected presumably on the grounds that the device tree people want to make not having already migrated everything to systemd painful. So current kernels won't "just work" for the _next_ person either, and nobody upgrades, and then if somebody tries their hand at converting a board to device tree there's no testers. Or if there are they go "it didn't boot" because of some unrelated regression elsewhere in the code because the kernel they're using (and still maintaining in-house) is years old... This is something like the eighth company I've seen that at. :P Rob
