[RFC v3 00/16] Basic clock and reset support for StarFive JH8100 RISC-V SoC

[Stephen Boyd]

Quoting Conor Dooley (2024-04-11 03:29:51)
> On Thu, Apr 11, 2024 at 12:40:09AM -0700, Stephen Boyd wrote:
> > Quoting Sia Jee Heng (2024-01-10 05:31:12)
> > > This patch series enabled basic clock & reset support for StarFive
> > > JH8100 SoC.
> > > 
> > > This patch series depends on the Initial device tree support for
> > > StarFive JH8100 SoC patch series which can be found at [1].
> > > 
> > > As it is recommended to refrain from merging fundamental patches like
> > > Device Tree, Clock & Reset, and PINCTRL tested on FPGA/Emulator, into the
> > > RISC-V Mainline, this patch series has been renamed to "RFC" patches. Yet,
> > > thanks to the reviewers who have reviewed the patches at [2]. The changes
> > > are captured below.
> > 
> > I don't think that's what should be happening. Instead, clk patches
> > should be sent to clk maintainers, reset patches to reset maintainers,
> > pinctrl patches to pinctrl maintainers, etc. The DTS can be sent later
> > when it's no longer an FPGA/Emulator? Right now I'm ignoring this series
> > because it's tagged as an RFC.
> 
> Since this comes back to something I said, what I didn't want to happen
> was a bunch of pinctrl/clock/reset dt-binding headers that getting merged
> (and therefore exported to other projects) and then have those change
> later on when the chip was taped out.

Ah ok.

> I don't really care if the drivers
> themselves get merged. If the JH8100 is being taped out soon (or already
> has been internally) and there's unlikely to be any changes, there's not
> really a reason to block the binding headers any more.
> 

The binding headers are sometimes required for the drivers, so the
driver can't be merged then.