RFC: DRM trivial tree

RFC: DRM trivial tree

[Thierry Reding]

[-- Attachment #1.1: Type: text/plain, Size: 2520 bytes --]

Hi everyone,

Lately I've noticed that a bunch of trivial patches have been posted
across all drivers. We've also encountered situations in the past where
(relatively trivial) subsystem-wide changes have been made but it ended
up being very difficult to get patches merged (often because they had
inter-dependencies and nobody felt responsible for merging them). Often
Dave has been the last resort for this kind of patches. A side-effect
has been that it often takes a lot of time for such patches to get
merged (if at all) and they usually don't end up in linux-next and
therefore see little testing before they are applied.

To remedy that situation I'd like to propose the addition of a tree to
keep track of these kinds of patches. Note that the target here are
trivial patches, such as coding style fixes, fixes for build warnings
or errors, subsystem-wide API changes, etc. It also targets mostly the
drivers that don't have a branch that feeds into linux-next. Patches
against drivers that already feed into linux-next should go through the
corresponding trees. One reasonable exception for this, in my opinion,
are subsystem-wide changes, because applying them via different trees
usually ends up being messy.

I pushed a branch[0] with a set of patches that I've picked up from
patchwork and which seemed to match the above criteria. I've also Cc'ed
a bunch of people (mostly a subset of what get_maintainer.pl reported
for the patches in the branch).

Before going any further with this I'd like to get some feedback on the
idea. Dave, do you think this is a good idea and would you be willing to
give this a try?

Again, I'm not volunteering to be a maintainer for all of the smaller
drivers. The goal here is to make it easier to get cleanup patches into
linux-next, or provide a place where subsystem-wide changes can be
coordinated. Driver maintainers should still review the patches and in
many cases I'd want to wait for Acked-by or Reviewed-by tags before
taking any patches into the trivial tree. Also, while I'll try to
monitor the list as best I can, it will inevitably happen that I'll miss
patches. When that happens, feel free to Cc me if you think the patches
match the above criteria.

For a while now it's also been difficult to find maintainers for drivers
so I'd like to see more entries being added to MAINTAINERS to help
identify the people that need to be involved and hopefully make this
process easier.

Thierry

[0]: http://cgit.freedesktop.org/tegra/linux/log/?h=drm/trivial/for-next

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: RFC: DRM trivial tree

[Dave Airlie]

On 8 October 2015 at 01:15, Thierry Reding <thierry.reding@gmail.com> wrote:
> Hi everyone,
>
> Lately I've noticed that a bunch of trivial patches have been posted
> across all drivers. We've also encountered situations in the past where
> (relatively trivial) subsystem-wide changes have been made but it ended
> up being very difficult to get patches merged (often because they had
> inter-dependencies and nobody felt responsible for merging them). Often
> Dave has been the last resort for this kind of patches. A side-effect
> has been that it often takes a lot of time for such patches to get
> merged (if at all) and they usually don't end up in linux-next and
> therefore see little testing before they are applied.
>
> To remedy that situation I'd like to propose the addition of a tree to
> keep track of these kinds of patches. Note that the target here are
> trivial patches, such as coding style fixes, fixes for build warnings
> or errors, subsystem-wide API changes, etc. It also targets mostly the
> drivers that don't have a branch that feeds into linux-next. Patches
> against drivers that already feed into linux-next should go through the
> corresponding trees. One reasonable exception for this, in my opinion,
> are subsystem-wide changes, because applying them via different trees
> usually ends up being messy.
>
> I pushed a branch[0] with a set of patches that I've picked up from
> patchwork and which seemed to match the above criteria. I've also Cc'ed
> a bunch of people (mostly a subset of what get_maintainer.pl reported
> for the patches in the branch).
>
> Before going any further with this I'd like to get some feedback on the
> idea. Dave, do you think this is a good idea and would you be willing to
> give this a try?

I'm not going to object, I'm not sure trivial covers a lot of these
patches though.

I generally don't go nuts picking up the trivial patches on a weekly basis, as I
don't think they generally need that much attention, a number of the things
in your tree for example are things I've merged into -fixes instead, or I'm
waiting to see if driver maintainers pick them up themselves.

It would be nice if more driver maintainers had trees feeding into drm-next
or sent me drm-next pull requests no matter how small on a more regular basis
esp after -rc2/3.

So I probably wouldn't to a pull req from that tree, but it might be something
I'd cherry-pick from if I remember instead of using patchwork.

At least in theory I'm the last line of maintainer for the non-ARM drivers
(i.e. qxl, mgag200, etc), I don't really want to be last person in line for SoC
drivers as I'm not really knowledgeable enough, and for SoCs I'm pretty
much at the stage where only pull requests from someone who cares will generally
make me merge patches.

but hey lets give this a go and see if it helps, if you have the time!

Dave.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: RFC: DRM trivial tree

[Daniel Vetter]

On Thu, Oct 08, 2015 at 09:04:06AM +1000, Dave Airlie wrote:
> On 8 October 2015 at 01:15, Thierry Reding <thierry.reding@gmail.com> wrote:
> > Hi everyone,
> >
> > Lately I've noticed that a bunch of trivial patches have been posted
> > across all drivers. We've also encountered situations in the past where
> > (relatively trivial) subsystem-wide changes have been made but it ended
> > up being very difficult to get patches merged (often because they had
> > inter-dependencies and nobody felt responsible for merging them). Often
> > Dave has been the last resort for this kind of patches. A side-effect
> > has been that it often takes a lot of time for such patches to get
> > merged (if at all) and they usually don't end up in linux-next and
> > therefore see little testing before they are applied.
> >
> > To remedy that situation I'd like to propose the addition of a tree to
> > keep track of these kinds of patches. Note that the target here are
> > trivial patches, such as coding style fixes, fixes for build warnings
> > or errors, subsystem-wide API changes, etc. It also targets mostly the
> > drivers that don't have a branch that feeds into linux-next. Patches
> > against drivers that already feed into linux-next should go through the
> > corresponding trees. One reasonable exception for this, in my opinion,
> > are subsystem-wide changes, because applying them via different trees
> > usually ends up being messy.
> >
> > I pushed a branch[0] with a set of patches that I've picked up from
> > patchwork and which seemed to match the above criteria. I've also Cc'ed
> > a bunch of people (mostly a subset of what get_maintainer.pl reported
> > for the patches in the branch).
> >
> > Before going any further with this I'd like to get some feedback on the
> > idea. Dave, do you think this is a good idea and would you be willing to
> > give this a try?
> 
> I'm not going to object, I'm not sure trivial covers a lot of these
> patches though.
> 
> I generally don't go nuts picking up the trivial patches on a weekly basis, as I
> don't think they generally need that much attention, a number of the things
> in your tree for example are things I've merged into -fixes instead, or I'm
> waiting to see if driver maintainers pick them up themselves.
> 
> It would be nice if more driver maintainers had trees feeding into drm-next
> or sent me drm-next pull requests no matter how small on a more regular basis
> esp after -rc2/3.
> 
> So I probably wouldn't to a pull req from that tree, but it might be something
> I'd cherry-pick from if I remember instead of using patchwork.
> 
> At least in theory I'm the last line of maintainer for the non-ARM drivers
> (i.e. qxl, mgag200, etc), I don't really want to be last person in line for SoC
> drivers as I'm not really knowledgeable enough, and for SoCs I'm pretty
> much at the stage where only pull requests from someone who cares will generally
> make me merge patches.
> 
> but hey lets give this a go and see if it helps, if you have the time!

I think this tree could be useful as a welcoming ground for new folks who
send in small fixes as their first patch. I think we have a few of those
nowadays (besides the usual tree-wide style police), and I think making
sure that their patches get an "ack, merged it to $branch" quickly would
help a lot in motivating them to dig in more. So not about patches getting
lost, but getting a quick thanks out there. I'm doing that for the core
with drm-misc, but there's definitely a gap with armsoc infrastructure and
random drivers.

So maybe don't call it drm-trivial (since "hey your patch here is trivial"
doesn't sound that awesome) but drm-misc-drivers.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: RFC: DRM trivial tree

[Thierry Reding]

[-- Attachment #1.1: Type: text/plain, Size: 5140 bytes --]

On Thu, Oct 08, 2015 at 09:04:06AM +1000, Dave Airlie wrote:
> On 8 October 2015 at 01:15, Thierry Reding <thierry.reding@gmail.com> wrote:
> > Hi everyone,
> >
> > Lately I've noticed that a bunch of trivial patches have been posted
> > across all drivers. We've also encountered situations in the past where
> > (relatively trivial) subsystem-wide changes have been made but it ended
> > up being very difficult to get patches merged (often because they had
> > inter-dependencies and nobody felt responsible for merging them). Often
> > Dave has been the last resort for this kind of patches. A side-effect
> > has been that it often takes a lot of time for such patches to get
> > merged (if at all) and they usually don't end up in linux-next and
> > therefore see little testing before they are applied.
> >
> > To remedy that situation I'd like to propose the addition of a tree to
> > keep track of these kinds of patches. Note that the target here are
> > trivial patches, such as coding style fixes, fixes for build warnings
> > or errors, subsystem-wide API changes, etc. It also targets mostly the
> > drivers that don't have a branch that feeds into linux-next. Patches
> > against drivers that already feed into linux-next should go through the
> > corresponding trees. One reasonable exception for this, in my opinion,
> > are subsystem-wide changes, because applying them via different trees
> > usually ends up being messy.
> >
> > I pushed a branch[0] with a set of patches that I've picked up from
> > patchwork and which seemed to match the above criteria. I've also Cc'ed
> > a bunch of people (mostly a subset of what get_maintainer.pl reported
> > for the patches in the branch).
> >
> > Before going any further with this I'd like to get some feedback on the
> > idea. Dave, do you think this is a good idea and would you be willing to
> > give this a try?
> 
> I'm not going to object, I'm not sure trivial covers a lot of these
> patches though.
> 
> I generally don't go nuts picking up the trivial patches on a weekly basis, as I
> don't think they generally need that much attention, a number of the things
> in your tree for example are things I've merged into -fixes instead, or I'm
> waiting to see if driver maintainers pick them up themselves.

Determining what's a candidate for the trivial tree is one of the things
that I'm most uncertain about. Given what you say above there's a lot of
potential for conflicts in linux-next if both of us end up picking up
the same patches.

I certainly wouldn't want to step on your toes or make your job any more
difficult. But it seems that such a trivial tree would do just that, so
it doesn't sound like a really helpful addition.

> It would be nice if more driver maintainers had trees feeding into drm-next
> or sent me drm-next pull requests no matter how small on a more regular basis
> esp after -rc2/3.

That I completely second. One of the primary goals of having a trivial
tree is to get patches into linux-next more quickly. This is especially
useful, in my opinion, for things that fix up trivial build warnings or
similar, so that we have a fast way for such patches to get into linux-
next and avoid needless duplication of effort by people trying again
and again to fix warnings in linux-next.

> So I probably wouldn't to a pull req from that tree, but it might be something
> I'd cherry-pick from if I remember instead of using patchwork.
> 
> At least in theory I'm the last line of maintainer for the non-ARM drivers
> (i.e. qxl, mgag200, etc), I don't really want to be last person in line for SoC
> drivers as I'm not really knowledgeable enough, and for SoCs I'm pretty
> much at the stage where only pull requests from someone who cares will generally
> make me merge patches.

The thing that worries me most about this is that it's going to derail
into me becoming a defacto maintainer for unmaintained drivers. That's
not something I'm willing to sign up for because I simply don't have
the time to do it.

I'd like it to be very clear that the existence of such a tree doesn't
exempt maintainers from caring about the patches. I fully agree that we
need more trees properly feeding into linux-next, hence why I proposed
as a first step to add MAINTAINERS entries for drivers that lack one.

The second primary goal is to coordinate subsystem-wide changes. That
could be done without this tree using ad-hoc branches. Granted, it'd
become somewhat more complicated to feed it into linux-next, but one
solution to that would be to take it through an existing tree.

> but hey lets give this a go and see if it helps, if you have the time!

Coordinating which patches go where is probably going to be the most
difficult part. Any suggestions? Perhaps the simplest would be to base
that tree onto drm-fixes and drm-next so that patches can automatically
filter out with a rebase. But that means that it would need to be fairly
often rebased for it to be effective. Maybe just using IRC, email or
even patchwork would be equally effective.

Thierry

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: RFC: DRM trivial tree

[Thierry Reding]

[-- Attachment #1.1: Type: text/plain, Size: 4712 bytes --]

On Thu, Oct 08, 2015 at 09:46:50AM +0200, Daniel Vetter wrote:
> On Thu, Oct 08, 2015 at 09:04:06AM +1000, Dave Airlie wrote:
> > On 8 October 2015 at 01:15, Thierry Reding <thierry.reding@gmail.com> wrote:
> > > Hi everyone,
> > >
> > > Lately I've noticed that a bunch of trivial patches have been posted
> > > across all drivers. We've also encountered situations in the past where
> > > (relatively trivial) subsystem-wide changes have been made but it ended
> > > up being very difficult to get patches merged (often because they had
> > > inter-dependencies and nobody felt responsible for merging them). Often
> > > Dave has been the last resort for this kind of patches. A side-effect
> > > has been that it often takes a lot of time for such patches to get
> > > merged (if at all) and they usually don't end up in linux-next and
> > > therefore see little testing before they are applied.
> > >
> > > To remedy that situation I'd like to propose the addition of a tree to
> > > keep track of these kinds of patches. Note that the target here are
> > > trivial patches, such as coding style fixes, fixes for build warnings
> > > or errors, subsystem-wide API changes, etc. It also targets mostly the
> > > drivers that don't have a branch that feeds into linux-next. Patches
> > > against drivers that already feed into linux-next should go through the
> > > corresponding trees. One reasonable exception for this, in my opinion,
> > > are subsystem-wide changes, because applying them via different trees
> > > usually ends up being messy.
> > >
> > > I pushed a branch[0] with a set of patches that I've picked up from
> > > patchwork and which seemed to match the above criteria. I've also Cc'ed
> > > a bunch of people (mostly a subset of what get_maintainer.pl reported
> > > for the patches in the branch).
> > >
> > > Before going any further with this I'd like to get some feedback on the
> > > idea. Dave, do you think this is a good idea and would you be willing to
> > > give this a try?
> > 
> > I'm not going to object, I'm not sure trivial covers a lot of these
> > patches though.
> > 
> > I generally don't go nuts picking up the trivial patches on a weekly basis, as I
> > don't think they generally need that much attention, a number of the things
> > in your tree for example are things I've merged into -fixes instead, or I'm
> > waiting to see if driver maintainers pick them up themselves.
> > 
> > It would be nice if more driver maintainers had trees feeding into drm-next
> > or sent me drm-next pull requests no matter how small on a more regular basis
> > esp after -rc2/3.
> > 
> > So I probably wouldn't to a pull req from that tree, but it might be something
> > I'd cherry-pick from if I remember instead of using patchwork.
> > 
> > At least in theory I'm the last line of maintainer for the non-ARM drivers
> > (i.e. qxl, mgag200, etc), I don't really want to be last person in line for SoC
> > drivers as I'm not really knowledgeable enough, and for SoCs I'm pretty
> > much at the stage where only pull requests from someone who cares will generally
> > make me merge patches.
> > 
> > but hey lets give this a go and see if it helps, if you have the time!
> 
> I think this tree could be useful as a welcoming ground for new folks who
> send in small fixes as their first patch. I think we have a few of those
> nowadays (besides the usual tree-wide style police), and I think making
> sure that their patches get an "ack, merged it to $branch" quickly would
> help a lot in motivating them to dig in more. So not about patches getting
> lost, but getting a quick thanks out there. I'm doing that for the core
> with drm-misc, but there's definitely a gap with armsoc infrastructure and
> random drivers.
> 
> So maybe don't call it drm-trivial (since "hey your patch here is trivial"
> doesn't sound that awesome) but drm-misc-drivers.

I'm afraid that this is going to encourage people to not properly
maintain their drivers. The reason why I wanted to call it trivial was
because the requirement would have to be that the patches should be
small. I lack the knowledge about most SoC drivers to properly review
patches that go beyond minor things like cleanup.

That said, I guess it would be okay to pick up more complex patches if
they had an Acked-by or Reviewed-by from a maintainer. Then again, if
they already find the time to review patches it probably wouldn't be a
lot more effort to apply them to their own tree.

But that's all really speculation, so perhaps it'd be best to just try
it out and see how it goes. If it isn't useful we can always drop it
again.

Thierry

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: RFC: DRM trivial tree

[Vincent ABRIOU]

On 10/08/2015 10:16 AM, Thierry Reding wrote:
> On Thu, Oct 08, 2015 at 09:46:50AM +0200, Daniel Vetter wrote:
>> On Thu, Oct 08, 2015 at 09:04:06AM +1000, Dave Airlie wrote:
>>> On 8 October 2015 at 01:15, Thierry Reding <thierry.reding@gmail.com> wrote:
>>>> Hi everyone,
>>>>
>>>> Lately I've noticed that a bunch of trivial patches have been posted
>>>> across all drivers. We've also encountered situations in the past where
>>>> (relatively trivial) subsystem-wide changes have been made but it ended
>>>> up being very difficult to get patches merged (often because they had
>>>> inter-dependencies and nobody felt responsible for merging them). Often
>>>> Dave has been the last resort for this kind of patches. A side-effect
>>>> has been that it often takes a lot of time for such patches to get
>>>> merged (if at all) and they usually don't end up in linux-next and
>>>> therefore see little testing before they are applied.
>>>>
>>>> To remedy that situation I'd like to propose the addition of a tree to
>>>> keep track of these kinds of patches. Note that the target here are
>>>> trivial patches, such as coding style fixes, fixes for build warnings
>>>> or errors, subsystem-wide API changes, etc. It also targets mostly the
>>>> drivers that don't have a branch that feeds into linux-next. Patches
>>>> against drivers that already feed into linux-next should go through the
>>>> corresponding trees. One reasonable exception for this, in my opinion,
>>>> are subsystem-wide changes, because applying them via different trees
>>>> usually ends up being messy.
>>>>
>>>> I pushed a branch[0] with a set of patches that I've picked up from
>>>> patchwork and which seemed to match the above criteria. I've also Cc'ed
>>>> a bunch of people (mostly a subset of what get_maintainer.pl reported
>>>> for the patches in the branch).
>>>>
>>>> Before going any further with this I'd like to get some feedback on the
>>>> idea. Dave, do you think this is a good idea and would you be willing to
>>>> give this a try?
>>>
>>> I'm not going to object, I'm not sure trivial covers a lot of these
>>> patches though.
>>>
>>> I generally don't go nuts picking up the trivial patches on a weekly basis, as I
>>> don't think they generally need that much attention, a number of the things
>>> in your tree for example are things I've merged into -fixes instead, or I'm
>>> waiting to see if driver maintainers pick them up themselves.
>>>
>>> It would be nice if more driver maintainers had trees feeding into drm-next
>>> or sent me drm-next pull requests no matter how small on a more regular basis
>>> esp after -rc2/3.
>>>
>>> So I probably wouldn't to a pull req from that tree, but it might be something
>>> I'd cherry-pick from if I remember instead of using patchwork.
>>>
>>> At least in theory I'm the last line of maintainer for the non-ARM drivers
>>> (i.e. qxl, mgag200, etc), I don't really want to be last person in line for SoC
>>> drivers as I'm not really knowledgeable enough, and for SoCs I'm pretty
>>> much at the stage where only pull requests from someone who cares will generally
>>> make me merge patches.
>>>
>>> but hey lets give this a go and see if it helps, if you have the time!
>>
>> I think this tree could be useful as a welcoming ground for new folks who
>> send in small fixes as their first patch. I think we have a few of those
>> nowadays (besides the usual tree-wide style police), and I think making
>> sure that their patches get an "ack, merged it to $branch" quickly would
>> help a lot in motivating them to dig in more. So not about patches getting
>> lost, but getting a quick thanks out there. I'm doing that for the core
>> with drm-misc, but there's definitely a gap with armsoc infrastructure and
>> random drivers.
>>
>> So maybe don't call it drm-trivial (since "hey your patch here is trivial"
>> doesn't sound that awesome) but drm-misc-drivers.
>
> I'm afraid that this is going to encourage people to not properly
> maintain their drivers. The reason why I wanted to call it trivial was
> because the requirement would have to be that the patches should be
> small. I lack the knowledge about most SoC drivers to properly review
> patches that go beyond minor things like cleanup.
>

My young maintainer experience make me ask this question:
How maintainer can deal with some patch set that impacts many other 
drivers?

And I think "drm-trivial" (or whatever the name) branch can answer the 
question.

Indeed, it is dangerous to only pick the patch useful for their own 
driver and make a pull request (coherency is not insure). It will 
definitely lead to merge issue if same patches are in different tree.

I understand the need of such "drm-trivial" but I wonder how patch set 
with impacts on different drivers were manage before this proposal?

Vincent


> That said, I guess it would be okay to pick up more complex patches if
> they had an Acked-by or Reviewed-by from a maintainer. Then again, if
> they already find the time to review patches it probably wouldn't be a
> lot more effort to apply them to their own tree.
>
> But that's all really speculation, so perhaps it'd be best to just try
> it out and see how it goes. If it isn't useful we can always drop it
> again.
>
> Thierry
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: RFC: DRM trivial tree

[Boris Brezillon]

Hi Thierry,

On Wed, 7 Oct 2015 17:15:56 +0200
Thierry Reding <thierry.reding@gmail.com> wrote:

> Hi everyone,
> 
> Lately I've noticed that a bunch of trivial patches have been posted
> across all drivers. We've also encountered situations in the past where
> (relatively trivial) subsystem-wide changes have been made but it ended
> up being very difficult to get patches merged (often because they had
> inter-dependencies and nobody felt responsible for merging them). Often
> Dave has been the last resort for this kind of patches. A side-effect
> has been that it often takes a lot of time for such patches to get
> merged (if at all) and they usually don't end up in linux-next and
> therefore see little testing before they are applied.
> 
> To remedy that situation I'd like to propose the addition of a tree to
> keep track of these kinds of patches. Note that the target here are
> trivial patches, such as coding style fixes, fixes for build warnings
> or errors, subsystem-wide API changes, etc. It also targets mostly the
> drivers that don't have a branch that feeds into linux-next. Patches
> against drivers that already feed into linux-next should go through the
> corresponding trees. One reasonable exception for this, in my opinion,
> are subsystem-wide changes, because applying them via different trees
> usually ends up being messy.
> 
> I pushed a branch[0] with a set of patches that I've picked up from
> patchwork and which seemed to match the above criteria. I've also Cc'ed
> a bunch of people (mostly a subset of what get_maintainer.pl reported
> for the patches in the branch).
> 
> Before going any further with this I'd like to get some feedback on the
> idea. Dave, do you think this is a good idea and would you be willing to
> give this a try?
> 
> Again, I'm not volunteering to be a maintainer for all of the smaller
> drivers. The goal here is to make it easier to get cleanup patches into
> linux-next, or provide a place where subsystem-wide changes can be
> coordinated. Driver maintainers should still review the patches and in
> many cases I'd want to wait for Acked-by or Reviewed-by tags before
> taking any patches into the trivial tree. Also, while I'll try to
> monitor the list as best I can, it will inevitably happen that I'll miss
> patches. When that happens, feel free to Cc me if you think the patches
> match the above criteria.

I'm perfectly fine with that (even if the question was not directly
asked to me :-)), except that in the tree you made, I see one patch [1]
that is directly related to the atmel-hlcdc driver and not a
transversal cleanup patch (though I don't have any problem letting you
take that patch).

> 
> For a while now it's also been difficult to find maintainers for drivers
> so I'd like to see more entries being added to MAINTAINERS to help
> identify the people that need to be involved and hopefully make this
> process easier.

Just sent a patch adding my name for the atmel-hlcdc driver.

Best Regards,

Boris

[1]http://cgit.freedesktop.org/tegra/linux/commit/?h=drm/trivial/for-next&id=52689f943fb46f560a2277c03debfe79110d0d1f

> 
> Thierry
> 
> [0]: http://cgit.freedesktop.org/tegra/linux/log/?h=drm/trivial/for-next



-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel