[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240411-euphemism-ended-706f23d4a5ca@wendy>
Date: Thu, 11 Apr 2024 11:29:51 +0100
From: Conor Dooley <conor.dooley@...rochip.com>
To: Stephen Boyd <sboyd@...nel.org>
CC: Sia Jee Heng <jeeheng.sia@...rfivetech.com>, <aou@...s.berkeley.edu>,
<conor@...nel.org>, <emil.renner.berthing@...onical.com>,
<hal.feng@...rfivetech.com>, <kernel@...il.dk>,
<krzysztof.kozlowski+dt@...aro.org>, <mturquette@...libre.com>,
<p.zabel@...gutronix.de>, <palmer@...belt.com>, <paul.walmsley@...ive.com>,
<robh+dt@...nel.org>, <xingyu.wu@...rfivetech.com>,
<linux-riscv@...ts.infradead.org>, <devicetree@...r.kernel.org>,
<linux-kernel@...r.kernel.org>, <linux-clk@...r.kernel.org>,
<leyfoon.tan@...rfivetech.com>
Subject: Re: [RFC v3 00/16] Basic clock and reset support for StarFive JH8100
RISC-V SoC
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. 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.
Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)
Powered by blists - more mailing lists