Messages in this thread | | | Date | Wed, 1 Jul 2015 11:33:21 -0400 | From | Paul Gortmaker <> | Subject | Re: [GIT PULL] Introduce builtin_platform_driver for non modules |
| |
[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/20150620180435.GG16386@windriver.com
> 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..."
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
Thanks, Paul. --
> > thanks, > > greg k-h
| |