On Wed, Jun 04, 2014 at 04:57:07PM +0530, Sumit Semwal wrote: > Hi Greg, > > > On 30 May 2014 21:38, Greg Kroah-Hartman <gre...@linuxfoundation.org> wrote: > > On Fri, May 30, 2014 at 10:15:05AM +0200, Thierry Reding wrote: > >> On Wed, May 28, 2014 at 01:51:45PM -0700, Greg Kroah-Hartman wrote: > >> > On Wed, May 28, 2014 at 04:26:32PM +0200, Thierry Reding wrote: > >> > > From: Thierry Reding <tred...@nvidia.com> > >> > > > >> > > Commit febdbfe8a91c (arch: Prepare for smp_mb__{before,after}_atomic()) > >> > > deprecated the smp_mb__{before,after}_{atomic,clear}_{dec,inc,bit}*() > >> > > functions in favour of the unified smp_mb__{before,after}_atomic(). > >> > > > >> > > Signed-off-by: Thierry Reding <tred...@nvidia.com> > >> > > --- > >> > > drivers/base/fence.c | 4 ++-- > >> > > >> > Where does this file come from? I've not seen it before, and it's not > >> > in my tree. > >> > >> I think it came in through Sumit's tree and it's only in linux-next I > >> believe. > > > > Odd, linux-next is for merging things in Linus's next release. > > > > And as I have never seen this code that will end up being my > > responsibility to maintain, it seems strange that it will be merged in > > the next kernel development cycle. > > > > What broke down here with our review process that required something to > > be merged without at least a cc: to me? > > This is a new file added by Maarten's patches [1], that got reviewed > on dri-devel and other mailing lists. Since it was quite closely > associated with dma-buf, I figured I should take it through the > dma-buf tree. > > I am sorry I didn't notice that you weren't CC'ed on these patches - > Sincere apologies, since I should've noticed that during the patch > review process - I would take part of the blame here as well :( > > I do realize now that atleast on my part, I should've asked you before > taking it through the dma-buf tree - I will make sure things like this > don't happen again through me. > > May I request you to help us handle this - would it help if we add > Maarten as the maintainer for this file? Any other suggestions?
Perhaps something like the following would help? diff --git a/MAINTAINERS b/MAINTAINERS index fb39c9c3f0c1..d582f54adec8 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2867,7 +2867,9 @@ L: linux-me...@vger.kernel.org L: dri-de...@lists.freedesktop.org L: linaro-mm-...@lists.linaro.org F: drivers/base/dma-buf* +F: drivers/base/fence.c F: include/linux/dma-buf* +F: include/linux/fence.h F: Documentation/dma-buf-sharing.txt T: git git://git.linaro.org/people/sumitsemwal/linux-dma-buf.git @@ -2936,6 +2938,8 @@ T: git git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git S: Supported F: Documentation/kobject.txt F: drivers/base/ +X: drivers/base/dma-buf* +X: drivers/base/fence.c F: fs/sysfs/ F: fs/debugfs/ F: include/linux/kobj* That removes Greg from the list generated by get_maintainer.pl for anything that touches the DMA-BUF files. Thinking about it, perhaps moving DMA-BUF into its own subdirectory would be an option too, to make the separation more obvious. That is, if that's something that Greg wants. Thierry
pgpf60Csg2OJY.pgp
Description: PGP signature