linux-kernel - Re: [PATCH 00/11] SimpleDRM & Sysfb

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CANq1E4TmACNwyANaUsWufJL1ne4pk4Gv+g4y7b6xeO=Po-SN9g@mail.gmail.com>
Date:	Thu, 6 Mar 2014 13:16:34 +0100
From:	David Herrmann <dh.herrmann@...il.com>
To:	Tomi Valkeinen <tomi.valkeinen@...com>
Cc:	"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
	Ingo Molnar <mingo@...nel.org>,
	"linux-fbdev@...r.kernel.org" <linux-fbdev@...r.kernel.org>,
	Dave Airlie <airlied@...il.com>,
	Daniel Vetter <daniel.vetter@...ll.ch>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Tom Gundersen <teg@...m.no>
Subject: Re: [PATCH 00/11] SimpleDRM & Sysfb

Hi Tomi

On Mon, Mar 3, 2014 at 12:22 PM, Tomi Valkeinen <tomi.valkeinen@...com> wrote:
> On 03/03/14 13:09, David Herrmann wrote:
>
>>> 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
>
>> 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.
>
>> 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.

Thanks
David
--
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/