Hi Adam,
CC Stephen
On Thu, Jul 9, 2020 at 12:00 AM Adam Ford <aford173@xxxxxxxxx> wrote:
> On Wed, Jul 8, 2020 at 4:53 PM Adam Ford <aford173@xxxxxxxxx> wrote:
> > On Mon, Jun 22, 2020 at 8:20 AM Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote:
> > > On Wed, Jun 17, 2020 at 2:05 PM Adam Ford <aford173@xxxxxxxxx> wrote:
> > > > Beacon EmebddedWorks, formerly Logic PD is introducing a new
> > > > SOM and development kit based on the RZ/G2M SoC from Renesas.
> > > >
> > > > The SOM supports eMMC, WiFi and Bluetooth, along with a Cat-M1
> > > > cellular radio.
> > > >
> > > > The Baseboard has Ethernet, USB, HDMI, stereo audio in and out,
> > > > along with a vareity of push buttons and LED's.
> > > > --- /dev/null
> > > > +++ b/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi
> > > > @@ -0,0 +1,733 @@
> > > > +// SPDX-License-Identifier: GPL-2.0
> > > > +/*
> > > > + * Copyright 2020, Compass Electronics Group, LLC
> > > > + */
> > > > +
> > > > +#include <dt-bindings/gpio/gpio.h>
> > > > +#include <dt-bindings/input/input.h>
> > > > +#include <dt-bindings/clk/versaclock.h>
> > >
> > > This depends on "[PATCH V3 2/3] dt: Add additional option bindings for
> > > IDT VersaClock", which hasn't been accepted yet, AFAIK.
>
> Geert,
>
> I forgot to ask. What is the protocol for something when new bindings
> have been accepted in one branch, but another branch where I want to
> reference them hasn't merged with the other branch? I'd really like
> to get this board into the next kernel. I could remove these
> references and the calling functions, but that may cause instability
> due to undefined behaviour of some of the versaclock functions because
> they are not programmed.
As soon as a binding update has been accepted into the maintainer's
for-next branch, I happily accept DTS patches that start using it,
unless doing so would introduce a regression.
In this case, it's not a pure binding update, but also an update to
binding definitions in a header file, thus creating a hard dependency.
Usually this is mitigated by committing the header file change to an
immutable branch, to be shared by driver and DTS, and to be pulled by
all maintainers affected by the dependency.
As Stephen has already applied the binding update to his clk-next
branch, it's too late to go for the immutable branch approach. Hence
the simplest solution would be to postpone your DTS patch to v5.10.
> However, I would rather have the board mostly work if it means getting
> it accepted into the kernel. Beacon hasn't shipped any outside of the
> company yet, so I am not really worried about people seeing problems.
> If the board gets accepted without these, I could apply some 'fixes'
> at a late date to correct the undefined behavior. Let me know what
> the best way to proceed should be, and I'll send a V2 patch.
An alternative would be for me to cherry-pick commit 34662f6e30846ae0
("dt: Add additional option bindings for IDT VersaClock") from the
clk-next branch into renesas-devel, before applying your patch.
While that would help you, it may introduce a merge conflict for
linux-next and for upstream later, as Luca has already posted multiple
patches for idt,versaclock5.txt, to fix typos and do the json-schema
conversion. These may or may not land in v5.9.
Stephen: what do you think?
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
