On Wed, Jul 01, 2015 at 11:33:21AM -0400, Paul Gortmaker wrote: > [Re: [GIT PULL] Introduce builtin_platform_driver for non modules] On > 30/06/2015 (Tue 18:24) Greg KH wrote: > > [...] > > > > > > > The following changes since commit > > > 0f57d86787d8b1076ea8f9cbdddda2a46d534a27: > > > > > > Linux 4.1-rc8 (2015-06-14 15:51:10 -1000) > > > > > > are available in the git repository at: > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux.git > > > tags/module-builtin_driver-v4.1-rc8 > > > > > > for you to fetch changes up to 77459a0feca4ae8757a905fd1791f039479e8e1e: > > > > > > drivers/clk: convert sunxi/clk-mod0.c to use builtin_platform_driver > > > (2015-06-16 14:12:39 -0400) > > > > Was this ever in linux-next? > > It was added to linux-next a month ago, and all the commits and their > baseline have been unchanged for the last two weeks (the date Stephen > indicated) as that was when the last Acks etc stopped trickling in. > > I've also been proactively monitoring linux-next looking for any merge > issues, which is why I sent you the (now mainline) commits fc368ea1ea00c > and 5a6a7cd05c039 -- in both commits I mentioned how we'd like to change > to use this very infrastructure here, once it is present in tree. > > > I saw you post this once, don't recall any real discussion about it. > > I thought the lack of discussion wasn't surprising, given that it was a > mundane and trivial extension of the modular ones to a non-modular use > case, and the ugly alternative is to let everyone open code their own :( > > That said, it was posted with a sensible Cc list and it also did get > wider opportunity for possible discussion if needed, thanks to LWN: > https://lwn.net/Articles/643854/ > > The only other thread of discussion I can think of was where another > subsystem maintainer looped me into the review of a new driver, because > they were looking forward to having this in tree, due to the additional > clarity it would add between modular and non modular code: > https://lkml.kernel.org/r/[email protected] > > > Ideally some subsystem people would ack it... > > Yes a good many of the deployment patches themselves are Ack'd. For the > core macro introduction itself, you were Cc'd on it [and the 0/7 intro]. > > Given my above mentioned commits that you'd read and merged that > mentioned this, I didn't want to burn karma nagging you for an explicit > ack for this one basic commit itself, given how busy you are with > stable, staging, etc. But I did explicitly put you on the Cc for this > pull figuring it would be an opportunity to keep you in the loop and > provide a last chance opportunity for a "No, don't do this because..."
Fair enough, thanks for that, I don't have any objections to this pull request. > If I have to burn karma nagging you about something, I'd rather it be > something more important, like adding this (unrelated) clk_add_alias fix > to staging -- since its absence has been breaking powerpc, s390, parisc, > cris, ... etc. builds in linux-next for quite some time now. :) > > https://lkml.org/lkml/2015/6/25/365 Heh, it's not nagging, I'll queue that up after 4.2-rc1 is out, along with other fixes. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
