Date:	Wed, 1 Jul 2015 08:39:58 -0700
From:	Greg KH <gregkh@...uxfoundation.org>
To:	Paul Gortmaker <paul.gortmaker@...driver.com>
Cc:	torvalds@...ux-foundation.org, linux-kernel@...r.kernel.org,
	sfr@...b.auug.org.au
Subject: Re: [GIT PULL] Introduce builtin_platform_driver for non modules

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/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..."

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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists