[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <c99fea84-5234-b7c6-b768-418d42b2f7be@gmail.com>
Date: Tue, 9 May 2017 16:28:07 -0700
From: Florian Fainelli <f.fainelli@...il.com>
To: Eric Anholt <eric@...olt.net>, dri-devel@...ts.freedesktop.org,
bcm-kernel-feedback-list@...adcom.com, Ray Jui <rjui@...adcom.com>,
Scott Branden <sbranden@...adcom.com>,
Jon Mason <jonmason@...adcom.com>
Cc: linux-kernel@...r.kernel.org, mircea.carausu@...adcom.com
Subject: Re: [PATCH v2] drm/vc4: Enable selection in Kconfig on any 32-bit BCM
platform.
On 05/09/2017 04:16 PM, Eric Anholt wrote:
> Florian Fainelli <f.fainelli@...il.com> writes:
>
>> On 05/09/2017 11:15 AM, Eric Anholt wrote:
>>> With the Cygnus port, we needed to add at least "|| ARCH_BCM_CYGNUS"
>>> to let the module get built on a cygnus-only kernel. However, I
>>> anticipate having a port for Kona soon, so just present the module on
>>> all of BCM.
>>>
>>> v2: Keep allowing selection with ARCH_BCM2835, since ARCH_BCM doesn't
>>> exist on arm64.
>>
>> Nit: the patch changelog usually goes after the "---" line so it gets
>> stripped with git am. Not necessary to resubmit just because of that.
>
> Behavior on that front differs between subsystems. DRM is one where the
> changelog is generally retained.
Once the patch lands in git, it's sort of interesting to know its
history and the context surrounding this acceptance, but there is
already so much context being lost already (like where are all other
patches from the same patch series for instance?) that I wonder if we
should not add more to it (like links to past iterations and so on).
Thanks for explaining how DRM works in that regard, though.
--
Florian
Powered by blists - more mailing lists