linux-kernel - Re: [GIT PULL] Raspberry Pi KMS driver

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CAPM=9txRtojpn5kdYfA1q-+ga1po+cj4aiGsBuMb=5OuftDJVg@mail.gmail.com>
Date:	Fri, 23 Oct 2015 07:59:56 +1000
From:	Dave Airlie <airlied@...il.com>
To:	Rob Herring <robh@...nel.org>, Eric Anholt <eric@...olt.net>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	dri-devel <dri-devel@...ts.freedesktop.org>
Subject: Re: [GIT PULL] Raspberry Pi KMS driver

On 23 October 2015 at 05:58, Daniel Vetter <daniel@...ll.ch> wrote:
> On Thu, Oct 22, 2015 at 12:40:23PM -0500, Rob Herring wrote:
>> On Wed, Oct 21, 2015 at 4:53 AM, Eric Anholt <eric@...olt.net> wrote:
>> > Dave suggested it was time to just send a pull request on the driver, so
>> > here goes:
>>
>> Why is that when the binding is still under discussion[1]? Even the
>> agreed changes never got reposted.
>
> Bit a longer story, so here we go: I don't really like drivers/staging
> since it's a cage where drivers get forgotten about, and even if there is
> activity it's completely separate from all the other drm drivers. Which
> doesn't help with collaboration, which is the entire point really of
> upstreaming.
>
> Otoh I really like how drivers/staging allows not-quite-ready drivers to
> get in and get more visibility. So for drm I think the right approach is
> to just merge drivers which are reasonable close to good enough, and fix
> up anything erregrious once merged. This might be special for drm, since
> gpus change ridiculously fast, resulting in anyone contributing for more
> than 2-3 years to be constantly busy cleaning up past code that turned out
> a mistake in light of todays hardware. I think that means overall drm has
> a lower bar to entry and much higher acceptance for crap. And there's lots
> of it. Could very well be that most of the drm subsystem should be in
> drivers/staging by everyone else's standard.
>
> For this specific case here of the rpi driver the only ongoing thing was
> the dt binding discussion, and it didn't look like it would reach closure
> anytime soon. On top of that this driver is for rpi specifically (vc5 will
> require a completely new driver for a bunch of reasons), and on those
> boards the boot loader will never ship a dt file, it will always come from
> the kernel. Which means it's really just an internal interface and there's
> zero concerns about compatibility.

Yes besides the binding everything was ready, the drm API was more likely
to go stale and cause regressions/problems than fixing up what is at least
in this case going to be an in-tree interface, since there are thousands
of these boards in existance. I'm also travelling next week and I'd rather
not be pulling trees into drm-next too much.

The dt discussion can still go on, and we can merge the changes, before,
during after the merge window.

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