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:	Wed, 2 Sep 2015 10:34:46 +0200
From:	Thierry Reding <treding@...dia.com>
To:	Yakir Yang <ykk@...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>,
	Mark Yao <mark.yao@...k-chips.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 10:06:36AM +0800, Yakir Yang wrote:
> 在 09/02/2015 05:00 AM, Heiko Stuebner 写道:
> >Am Dienstag, 1. September 2015, 14:01:48 schrieb Yakir Yang:
[...]
> >>diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> >>b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c index 34b78e7..5d7f9b6 100644
> >>--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> >>+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> >>@@ -811,14 +811,41 @@ static const struct drm_plane_funcs vop_plane_funcs =
> >>{
> >>
> >>  int rockchip_drm_crtc_mode_config(struct drm_crtc *crtc,
> >>  				  int connector_type,
> >>-				  int out_mode)
> >>+				  int bpc, int color)
> >>  {
> >>  	struct vop *vop = to_vop(crtc);
> >>-
> >>  	vop->connector_type = connector_type;
> >>  	vop->connector_out_mode = out_mode;
> >this line should probably go away, as the source var "out_mode" does not exist
> >in the function params any more, making the compilation break, and is set
> >below anyway.
> 
> Sorry for the failed, there are must be a problem when I backport those code
> to chrome-3.14 to verify.
> 
> Thanks a lot, I would update next version soon.

*sigh*

I get the feeling that you're going about upstreaming the wrong way. If
you post patches to upstream mailing lists and you expect people to
apply those patches, then your target is the upstream kernel. So you
should be basing all of your work on top of a recent release candidate
directly from Linus or some recent version of linux-next.

Your current approach is already making people waste time trying to
build the patches and fail because you've been testing on something
other than mainline or linux-next.

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.

I realize that the upstream kernel isn't what's going to end up in
products later on, but that doesn't change the fact that you're
submitting code for inclusion in the mainline tree. If you need to
backport code to some ChromeOS tree, then that should be done after
you've verified that things build and run upstream. Doing so makes life
a lot easier for your upstream maintainers, and that in turn makes it
more likely to get your code merged.

Thierry

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