Re: [PATCH net-next v10 03/11] phy: rockchip: naneng-combphy: add SGMII MAC selection for RK3568

[Vinod Koul <vkoul@kernel.org>]

On 06-10-26, 05:15, Coia Prant wrote:
> Jakub Kicinski <kuba@kernel.org> 于2026年10月6日周二 04:59写道：
> >
> > On Wed, 23 Sep 2026 04:03:27 +0800 Coia Prant wrote:
> > > On RK3568, the SGMII interface can be routed to either GMAC0 or
> > > GMAC1 via the GRF register pipe_sgmii_mac_sel.
> > >
> > > Add support for this selection by introducing
> > > the "rockchip,sgmii-mac-sel" DT property.
> > >
> > > From the RK3568 TRM (Part1, Page 229), the PIPE_GRF_XPCS_CON0
> > > bit 1 (pipe_sgmii_mac_sel) is defined as:
> > >
> > >     0: SGMII routed to GMAC0
> > >     1: SGMII routed to GMAC1
> > >
> > > The hardware reset value is 1 (GMAC1). If the property is set to 0,
> > > the driver routes SGMII to GMAC0; if set to 1 (or omitted), it
> > > remains at GMAC1.
> > >
> > > This is necessary for boards such as the Ariaboard Photonicat, which
> > > uses the SGMII interface connected to GMAC0.
> > >
> > > Out-of-range values are rejected by dtschema, so the driver does not
> > > duplicate the range check.
> >
> > While looking thru the patches again I noticed this is changing generic
> > PHY. Maybe you can send it separately to Vinod? I don't see a hard
> > dependency? The code can "converge" during the merge window for the
> > whole thing to work.
> 
> Hi Jakub,
> 
> Thanks for the suggestion. I looked at this again, and I think the
> dependency is a bit more involved than it might seem.
> 
> The PHY patch (03/11) adds the driver support for
> "rockchip,sgmii-mac-sel", which is documented by the PHY binding (02/11).
> The DTS patch (10/11) then uses this property. If I send 03/11 separately
> to Vinod and keep 10/11 in net-next, dtbs_check will flag the DTS property
> as undocumented until the PHY binding lands in mainline. That would break
> DTS validation for the net-next series.

Typical order is that binding and driver goes thru subsystem (in this
case phy tree) and dts thru the soc tree.

I can review and pick these if you would like
> 
> Also, splitting into separate series means each has to queue and get
> reviewed independently, which I'm worried might not all make the merge
> window in time.
> 
> So unless you strongly prefer splitting, I'd rather keep the whole series
> together in net-next. If that works, would it be possible to coordinate an
> Ack from Vinod for the PHY part? Or if you still think it should go
> separately, I can do that too, but I wanted to flag the dependency and
> timing first.
> 
> Thanks,
> Coia

-- 
~Vinod