[GIT,PULL] Allwinner H3/H5 changes for 4.20, bis

Message ID 20181004193630.lbxyiecochf5cdfq@flea
State New
Headers show
Series
  • [GIT,PULL] Allwinner H3/H5 changes for 4.20, bis
Related show

Pull-request

https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git tags/sunxi-h3-h5-for-4.20-bis

Message

Maxime Ripard Oct. 4, 2018, 7:36 p.m.
Hi Arnd, Olof,

Here is a second attempt at the previous PR for the H3 and H5 changes,
hopefully with the right SoB this time. It replaces the previous one.

Thanks!
Maxime

The following changes since commit 5b394b2ddf0347bef56e50c69a58773c94343ff3:

  Linux 4.19-rc1 (2018-08-26 14:11:59 -0700)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git tags/sunxi-h3-h5-for-4.20-bis

for you to fetch changes up to d9492e3e4607e80421f395715def1c257ddf2f8f:

  ARM: dts: sunxi: h3-h5: Add Bananapi M2+ v1.2 device trees (2018-10-04 21:31:50 +0200)

----------------------------------------------------------------
Allwinner H3 and H5 DT additions for 4.20

This is our usual H3/H5 pull request

The most notable changes are:
  - the video decoding / encoding unit is finally enabled on the H3
  - Mali support for the H5
  - New boards: BananaPi M2+ v1.2, Orange Pi Zero Plus 2 H3 support

----------------------------------------------------------------
Chen-Yu Tsai (5):
      arm64: dts: allwinner: h5: Add device node for Mali-450 GPU
      ARM: dts: sun8i: h3: bpi-m2-plus: Fix address for external RGMII Ethernet PHY
      ARM: dts: sun8i: h3: Split out non-SoC-specific parts of Bananapi M2 Plus
      arm64: dts: allwinner: h5: Add device tree for Bananapi M2 Plus H5
      ARM: dts: sunxi: h3-h5: Add Bananapi M2+ v1.2 device trees

Diego Rondini (1):
      ARM: dts: sun8i: Add initial Orangepi Zero Plus 2 H3 support

Emmanuel Vadot (1):
      nvmem: sunxi-sid: add support for H5's SID controller

Paul Kocialkowski (1):
      ARM: dts: sun8i-h3: Add Video Engine and reserved memory nodes

Philipp Rossak (1):
      ARM: dts: sun8i: h3-h5: ir register size should be the whole memory block

 .../bindings/nvmem/allwinner,sunxi-sid.txt         |   1 +
 arch/arm/boot/dts/Makefile                         |   2 +
 .../boot/dts/sun8i-h3-bananapi-m2-plus-v1.2.dts    |  13 ++
 arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts    | 190 +----------------
 arch/arm/boot/dts/sun8i-h3-orangepi-zero-plus2.dts | 140 +++++++++++++
 arch/arm/boot/dts/sun8i-h3.dtsi                    |  25 +++
 arch/arm/boot/dts/sunxi-bananapi-m2-plus-v1.2.dtsi |  31 +++
 arch/arm/boot/dts/sunxi-bananapi-m2-plus.dtsi      | 231 +++++++++++++++++++++
 arch/arm/boot/dts/sunxi-h3-h5.dtsi                 |   2 +-
 arch/arm64/boot/dts/allwinner/Makefile             |   2 +
 .../allwinner/sun50i-h5-bananapi-m2-plus-v1.2.dts  |  11 +
 .../dts/allwinner/sun50i-h5-bananapi-m2-plus.dts   |  11 +
 arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi       |  43 ++++
 13 files changed, 513 insertions(+), 189 deletions(-)
 create mode 100644 arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus-v1.2.dts
 create mode 100644 arch/arm/boot/dts/sun8i-h3-orangepi-zero-plus2.dts
 create mode 100644 arch/arm/boot/dts/sunxi-bananapi-m2-plus-v1.2.dtsi
 create mode 100644 arch/arm/boot/dts/sunxi-bananapi-m2-plus.dtsi
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h5-bananapi-m2-plus-v1.2.dts
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h5-bananapi-m2-plus.dts

Comments

Arnd Bergmann Oct. 5, 2018, 3:43 p.m. | #1
On Thu, Oct 4, 2018 at 9:36 PM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
>
> Hi Arnd, Olof,
>
> Here is a second attempt at the previous PR for the H3 and H5 changes,
> hopefully with the right SoB this time. It replaces the previous one.

Hi Maxime,

I'm not completely sure about this, we generally try not to rebase the
branches, and the previous version is now deep in the git history of the
next/dt branch.

Obviously having a missing signoff is also bad, but I think keeping
the old version of your branch is better in this case. Merging the
new branch on top of next/dt would give us a proper signoff chain on
each patch, but would not remove the patches with the missing
signoff. Instead we'd have lots of duplicate commits, which is probably
worse.

Olof, do you have any other ideas?

       Arnd
Maxime Ripard Oct. 5, 2018, 3:52 p.m. | #2
Hi!

On Fri, Oct 05, 2018 at 05:43:03PM +0200, Arnd Bergmann wrote:
> On Thu, Oct 4, 2018 at 9:36 PM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> >
> > Hi Arnd, Olof,
> >
> > Here is a second attempt at the previous PR for the H3 and H5 changes,
> > hopefully with the right SoB this time. It replaces the previous one.
> 
> I'm not completely sure about this, we generally try not to rebase the
> branches, and the previous version is now deep in the git history of the
> next/dt branch.
> 
> Obviously having a missing signoff is also bad, but I think keeping
> the old version of your branch is better in this case. Merging the
> new branch on top of next/dt would give us a proper signoff chain on
> each patch, but would not remove the patches with the missing
> signoff. Instead we'd have lots of duplicate commits, which is probably
> worse.

I definitely understand that. The issue went since Chen-Yu was the
initial committer, but due to last minute issues in some patches in
that branch, I rebased it to drop those patches and sent it.

So commits carrying Chen-Yu's SoB were now committed by me. I'm not
sure if it makes it better, but anyway... It's up to you, and sorry
for that mess :/

Maxime
Olof Johansson Oct. 5, 2018, 5:33 p.m. | #3
On Fri, Oct 5, 2018 at 8:43 AM Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Thu, Oct 4, 2018 at 9:36 PM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> >
> > Hi Arnd, Olof,
> >
> > Here is a second attempt at the previous PR for the H3 and H5 changes,
> > hopefully with the right SoB this time. It replaces the previous one.
>
> Hi Maxime,
>
> I'm not completely sure about this, we generally try not to rebase the
> branches, and the previous version is now deep in the git history of the
> next/dt branch.
>
> Obviously having a missing signoff is also bad, but I think keeping
> the old version of your branch is better in this case. Merging the
> new branch on top of next/dt would give us a proper signoff chain on
> each patch, but would not remove the patches with the missing
> signoff. Instead we'd have lots of duplicate commits, which is probably
> worse.
>
> Olof, do you have any other ideas?

We now have the history documented on the mailing list, so we can find
the history if needed, and the missing signoff was by one of several
co-maintainers so it's not ideal but also not catastrophic.

We should probably get better at tooling for this instead (a pull
request linter using Stephen's script or somesuch).


-Olof