Re: [PATCH v1 2/6] peci: controller: Add StarFive JHB100 PECI driver

[Changhuang Liang]

Hi, Iwona

> On Fri, 2026-09-18 at 02:30 +0000, Changhuang Liang wrote:
> > Hi, Iwona
> >
> > Thanks for the review.
> >
> > > On Thu, 2026-09-03 at 06:34 -0700, Changhuang Liang wrote:
> > > > Add PECI controller driver for StarFive JHB100 SoC. The driver
> > > > supports PECI protocol communication for CPU thermal management.
> > > >
> > > > For this controller, the special clock and reset operation sequence is:
> > > >   probe: clk_prepare_enable() then reset_control_deassert()
> > > >   remove: clk_disable_unprepare() then reset_control_assert()
> > > >
> > > > Co-developed-by: Mason Huo <mason.huo@xxxxxxxxxxxxxxxx>
> > > > Signed-off-by: Mason Huo <mason.huo@xxxxxxxxxxxxxxxx>
> > > > Signed-off-by: Changhuang Liang
> > > > <changhuang.liang@xxxxxxxxxxxxxxxx>

[...]

> > > > +	peci_hdr =
> FIELD_PREP(STARFIVE_PECI_HDR_TARGET_ADDR_MASK,
> > > addr) |
> > > > +		   FIELD_PREP(STARFIVE_PECI_HDR_WR_LEN_MASK,
> req->tx.len)
> > > >
> > > > +		   FIELD_PREP(STARFIVE_PECI_HDR_RD_LEN_MASK, req-
> > > > >rx.len);
> > > > +	regmap_write(priv->regmap, STARFIVE_PECI_HDR, peci_hdr);
> > > > +
> > > > +	if (req->tx.len) {
> > > > +		/*
> > > > +		 * req->tx.buf[0] always store the command code.
> > > > +		 * Use command code set different configuration.
> > > > +		 */
> > > > +		u8 cmd_nibble = FIELD_GET(GENMASK(3, 0), req->tx.buf[0]);
> > > > +
> > > > +		if (cmd_nibble == STARFIVE_PECI_CMD_WRITE_NIBBLE) {
> > > > +			/*
> > > > +			 * This indicates current command code is write.
> > > > +			 * Only write command should enable has_awfcs.
> > > > +			 */
> > >
> > > Technically, we don't have support for any write commands at this
> > > point in the tree. Are you planning to add the usage for write
> > > commands in the near future?
> >
> > I'm not quite sure either. I previously adapted libpeci based on the
> > current tree, and tested the write commands. So I kept the write
> > commands branch here. I'm not quite sure why libpeci wasn't adapted
> > here—is it because there wasn't time to push this part forward?
> 
> No, we don't want to add a uAPI that exposes raw PECI command access.
> If we need some functionality that could be implemented using PECI, we
> should consider adding a dedicated driver for that and then define uAPI for
> that case (please see hwmon drivers).
> 
> I think it would be better to skip this part for now, and reintroduce it in all
> drivers across tree, when it is needed for write support.

Okay, I'll remove the write support in the next version.

Best Regards,
Changhuang