On Thursday 08 May 2014 05:38 AM, Paul Walmsley wrote: > Hi Rajendra, > > On Wed, 23 Apr 2014, Rajendra Nayak wrote: > >> The patches fix some opt clock handling in gpio and in >> hwmod. >> >> Rajendra Nayak (2): >> gpio: omap: prepare and unprepare the debounce clock >> ARM: OMAP2+: hwmod: Don't leave the optional clocks in >> clk_prepare()ed state >> >> arch/arm/mach-omap2/omap_hwmod.c | 13 ++----------- >> drivers/gpio/gpio-omap.c | 10 +++++----- >> 2 files changed, 7 insertions(+), 16 deletions(-) > > Can these patches be merged separately? Looks to me that the two options > are either to: > > A. to merge them together, or > > B. to merge patch 1 first, then patch 2 Thats right. > > Or will things break if only patch 1 is merged? Things will break if only patch 2 is merged as gpios clk_enable() request would fail. Merging only patch 1 has no issues. > > > If we merge them together, I'd say the best situation would be to take > them through the OMAP tree, since the changes are all OMAP-specific. In > that case we'll want an ack for the first patch from the GPIO maintainers, > Linus Walleij <linus.walleij@xxxxxxxxxx> and Alexandre Courbot > <gnurou@xxxxxxxxx>. > > Otherwise the path of least resistance would be (B) - you can get patch 1 > merged via the GPIO tree. The GPIO maintainers can then provide a > stable branch for us to base our changes on, or we can wait until the > change reaches Linus. Then we can subsequently merge patch 2 via the > OMAP side. > > Thoughts? I am fine either way. I will check with Linus W. what he prefers. Thanks. regards, Rajendra > > > - Paul > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
