On 06/03/14 14:16, David Herrmann wrote:

Hi Tomi

On Mon, Mar 3, 2014 at 12:22 PM, Tomi Valkeinen [off-list ref] wrote:

quoted

On 03/03/14 13:09, David Herrmann wrote:

quoted

quoted

What do you think, would it be possible to keep the sysfb stuff in
arch/x86, and still be able to do the rest of the stuff here? And then
move the sysfs from arch/x86 to drivers/video later?

I don't think there's any need for that. Linus does conflict
resolution all day long, so a short hint in Dave's pull-request (plus
an example merge) should be enough. Same is true for -next, I think.

True, but, well, the conflict with this one is not a few lines. "git
diff |wc -l" gives 2494 lines for the conflict. It's not really complex
to resolve that one, though, as it's really about copying all the stuff
into its new place.

So I'm not sure if that makes Linus think "this is simple one, 30 secs
and done" or "who the f*** sends me this crap" ;). Especially for two
reasons:

- The fb-reogranization is not very critical, and often clean-ups are
not worth it (although I think this one is good one, of course).
- Conflicting fbdev changes coming from another tree

quoted

And this is really just a mechanical thing, nothing hard to do. But of
course, it's your decision. However, keeping the code in x86 is the
wrong thing to do. As discussed with Ingo, the patch that extends

Yes, I didn't mean keeping the code in x86 for good, but just for one
kernel version to make merging easier.

quoted

x86/sysfb is only provided for easier backporting. The followup patch
immediately removes it again and adds proper video/sysfb. I'd dislike
splitting these just to avoid merge conflicts. I can also maintain a
merge-fixup branch in my tree, if anyone wants that.

You can have a try at merging. If you think it's trivial, maybe it is
and we can just let Linus handle it:

git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git
work/fb-reorder

Ok, I'm fine with delaying this one more merge-window. However, to
make things easier, could you pick up the two fbdev cleanups? These
are:
  fbdev: efifb: add dev->remove() callback
  fbdev: vesafb: add dev->remove() callback

They only add ->remove() callbacks which are never triggered currently
except with my sysfb series. But I'd like to drop both to make the
series smaller.

Yes, I can take them if they work fine without the rest of the patches.

I could also take all the patches up to patch #6 via fbdev tree. Some of
the patches are for arch x86, but they seem to be still about
framebuffers. But maybe that causes conflicts with x86 tree, then =).

Then again, maybe we should just go forward and let Linus handle the
conflict. I'm planning to send the "normal" fbdev changes and the
fbdev-reorg separately (just in case Linus doesn't like the reorg), and
that already causes conflicts, very similar to what this series causes.

So in any case Linus has to handle that conflict, or use a resolution
offered by me. So if fbdev changes and this series are merged in
relatively early phase, I can then send the reorg series a bit later and
offer a conflict resolution that solves the conflicts for both series.

That way this series doesn't get delayed needlessly in the case that
Linus rejects the reorg series.

 Tomi