Message ID | 20240110133128.286657-1-jeeheng.sia@starfivetech.com (mailing list archive) |
---|---|
Headers | show |
Series | Basic clock and reset support for StarFive JH8100 RISC-V SoC | expand |
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.
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.
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.