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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <17e03db98ea960c58b1c012ee04bcbf6.sboyd@kernel.org>
Date: Thu, 11 Apr 2024 20:00:33 -0700
From: Stephen Boyd <sboyd@...nel.org>
To: Conor Dooley <conor.dooley@...rochip.com>
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

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.