linux-kernel - Re: [PATCH v4 09/16] drm: rockchip: add bpc and color mode setting

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] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 3 Sep 2015 10:38:59 +0200
From:	Thierry Reding <treding@...dia.com>
To:	Yakir Yang <ykk@...k-chips.com>, Mark Yao <mark.yao@...k-chips.com>
CC:	Heiko Stuebner <heiko@...ech.de>,
	Jingoo Han <jingoohan1@...il.com>,
	"Inki Dae" <inki.dae@...sung.com>, <joe@...ches.com>,
	Kukjin Kim <kgene@...nel.org>,
	Krzysztof Kozlowski <k.kozlowski@...sung.com>,
	Russell King <rmk+kernel@....linux.org.uk>,
	<djkurtz@...omium.com>, <dianders@...omium.com>,
	<seanpaul@...omium.com>, <ajaynumb@...il.com>,
	Andrzej Hajda <a.hajda@...sung.com>,
	Kyungmin Park <kyungmin.park@...sung.com>,
	David Airlie <airlied@...ux.ie>,
	Gustavo Padovan <gustavo.padovan@...labora.co.uk>,
	Andy Yan <andy.yan@...k-chips.com>,
	"Kumar Gala" <galak@...eaurora.org>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Rob Herring <robh+dt@...nel.org>,
	Pawel Moll <pawel.moll@....com>,
	"Kishon Vijay Abraham I" <kishon@...com>, <architt@...eaurora.org>,
	<robherring2@...il.com>, <dri-devel@...ts.freedesktop.org>,
	<devicetree@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
	<linux-samsung-soc@...r.kernel.org>,
	<linux-rockchip@...ts.infradead.org>,
	<linux-arm-kernel@...t.NULL.NULL>, <s.infradead.org@...L.NULL>,
	Mark Yao <yzq@...k-chips.com>
Subject: Re: [PATCH v4 09/16] drm: rockchip: add bpc and color mode setting

On Wed, Sep 02, 2015 at 06:02:25PM +0800, Yakir Yang wrote:
> 在 2015/9/2 16:34, Thierry Reding 写道:
[...]
> >At the very least your code must compile when applied against a recent
> >upstream tree. I would also expect you to make sure the code works at
> >runtime, though, contrary to build testing, not everybody will be able
> >to verify that you've actually done so. It is ultimately your platform
> >maintainer's (i.e. Heiko's) responsibility to ensure that because they
> >will get to deal with user complaints if people can't run an upstream
> >kernel on the devices.
> 
> Oh, first time to know this rule. So I should work on Heiko's github
> kernel branch at the first time to start send upstream.

It's usually not necessary to rebase on a specific platform tree. Most
platform trees should feed into linux-next anyway, so linux-next would
be the appropriate base in almost all cases.

Note, though, that that's only true if you expect somebody else to merge
your code. The reason is that whoever will end up applying your patches
will likely apply to a tree that feeds into linux-next, and that way you
both end up having roughly the same base.

On the other hand if you are a maintainer yourself you should be keeping
a branch based on the latest -rc1. That's especially important if your
tree feeds into linux-next, because basing on linux-next will break very
horribly that way.

So for this particular case I would expect either Mark or Inki to apply
these patches when they're ready. Their trees should be based on the
latest -rc1. At least the Exynos DRM tree feeds into linux-next, so you
should be fine if you use linux-next as a base.

Mark, have you ever considered having your tree added to linux-next?

I'm beginning to think that we need to make that a requirement for all
DRM drivers so that we can resolve integration issues early on rather
than Dave having to deal with them when he pulls code in.

Thierry

Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)