On Wed, Nov 13, 2013 at 7:19 AM, Magnus Damm <magnus.d...@gmail.com> wrote: > On Wed, Nov 13, 2013 at 4:59 AM, Linus Walleij <linus.wall...@linaro.org> > wrote: >> On Thu, Nov 7, 2013 at 12:47 AM, Magnus Damm <magnus.d...@gmail.com> wrote: >> >> Is it so that arch/sh is more soft on this for example...? >> Can some arch maintainer like SH/Paul ACK this approach? >> >> Read: SH is not moving to device tree...? > > From what I can tell this GPIO block is not used with SH, so I don't > think SH is related, but regarding DT on SH, do you know when it was > decided that other architectures also were supposed to move DT?
I don't think these is any such decision, I'm just asking. I know that we only want to see DT on new archs and old hairy board code should be ridded using DT ... So I just want to know what the situation is like wrt Super-H. >>> Tested with yet-to-be-posted platform device and DT devices on >>> r7s72100 and Genmai using LEDs, DIP switches and I2C bitbang. >> >> Do you think the maintainers will merge the platform >> device approach? > > I would not assume so. But the goal with these patches is not > upstream, instead they basically serve as a stop-gap solution between > now and when I get OK that the DT bits in this GPIO driver looks fine. > If they are going to be merged or not is a different question IMO. Um so as an upstream maintainer I don't really know what to do at this point :-) But a DT-only driver is uncontroversial so I'd merge that. > I'll ditch the platform data interface and post a V2. Okay that sounds good... Thanks, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
