[PULL] 2nd pull for malidp-next

[Dave Airlie]

On Fri, 3 May 2019 at 22:17, Daniel Vetter <daniel at ffwll.ch> wrote:
>
> On Fri, May 03, 2019 at 10:29:48AM +0100, Liviu Dudau wrote:
> > On Fri, May 03, 2019 at 11:15:23AM +0200, Daniel Vetter wrote:
> > > On Fri, May 3, 2019 at 11:11 AM Liviu Dudau <Liviu.Dudau at arm.com> wrote:
> > > >
> > > > On Fri, May 03, 2019 at 09:54:35AM +1000, Dave Airlie wrote:
> > > > > On Thu, 2 May 2019 at 20:45, Liviu Dudau <Liviu.Dudau at arm.com> wrote:
> > > > > >
> > > > > > Hi DRM maintainers,
> > > > > >
> > > > > > This is the 2nd pull request for the malidp-next. The new patches add
> > > > > > additional support for Arm Mali D71 so that it can now be enabled
> > > > > > correctly and brought up on any SoC that contains the IP. From now on
> > > > > > we will start focusing on adding writeback, scaling and other useful
> > > > > > features to bring the driver to the same level of maturity as mali-dp.
> > > > > >
> > > > > > Please pull,
> > > > > > Liviu
> > > > > >
> > > > > >
> > > > > >
> > > > > > The following changes since commit 7c13e5cc2391950541f41fc9ab0336aae77c7f63:
> > > > > >
> > > > > >   Merge tag 'drm-intel-next-fixes-2019-04-25' of git://anongit.freedesktop.org/drm/drm-intel into drm-next (2019-04-26 11:35:59 +1000)
> > > > > >
> > > > > > are available in the Git repository at:
> > > > > >
> > > > > >   git://linux-arm.org/linux-ld.git for-upstream/mali-dp

So I get commits now, but I also get:

Pulling git://linux-arm.org/linux-ld.git for-upstream/mali-dp ...
>From git://linux-arm.org/linux-ld
 * branch                      for-upstream/mali-dp -> FETCH_HEAD
dim: 09918bb1ff8c ("drm/komeda: Use memset to initialize config_id"):
SHA1 in fixes line not found:
dim:     4cc734cb79a8 ("drm/komeda: Add sysfs attribute: core_id and config_id")
dim: d9fcab4a131d ("drm/komeda: Mark the local functions as static"):
author Signed-off-by missing.
dim: ERROR: issues in commits detected, aborting

Please fix the fixes tag, though since that is all in the one pull
request you should probably squash the fix into the offending commit.

Dave.