[PATCH rtems-libbsd] freebsd/cgem: Use SGMII when necessary

[Chris Johns]

On 2/11/2022 8:56 am, Kinsey Moore wrote:
> On Tue, Nov 1, 2022 at 4:14 PM Chris Johns <chrisj at rtems.org
> <mailto:chrisj at rtems.org>> wrote:
>     On 2/11/2022 5:51 am, Kinsey Moore wrote:
>     > Certain hardware configurations will always use SGMII instead of RGMII.
>     > Apply the appropriate flags for the relevant BSPs.
>     > ---
>     >  freebsd/sys/dev/cadence/if_cgem.c | 10 ++++++++++
>     >  1 file changed, 10 insertions(+)
>     >
>     > diff --git a/freebsd/sys/dev/cadence/if_cgem.c
>     b/freebsd/sys/dev/cadence/if_cgem.c
>     > index 3eaaf6b2..9b4cf693 100644
>     > --- a/freebsd/sys/dev/cadence/if_cgem.c
>     > +++ b/freebsd/sys/dev/cadence/if_cgem.c
>     > @@ -1296,6 +1296,16 @@ cgem_config(struct cgem_softc *sc)
>     >               CGEM_NET_CFG_FULL_DUPLEX |
>     >               CGEM_NET_CFG_SPEED100;
>     > 
>     > +#ifdef __rtems__
>     > +#define STRINGIFY(to_str) #to_str
>     > +#define BSP_STR(to_str) STRINGIFY(to_str)
>     > +     /* Configure the PHYs to use SGMII for particular BSPs */
>     > +     if ( 0 == strcmp( BSP_STR(RTEMS_BSP), "xilinx_zynqmp_lp64_cfc400x" ) ) {
>     > +             net_cfg |= CGEM_NET_CFG_SGMII_EN;
>     > +             net_cfg |= CGEM_NET_CFG_PCS_SEL;
>     > +     }
> 
>     This makes it a precedent a cgem device has to be an RTEMS BSP to support SGMII.
>     I do not think that is a good idea.
> 
> I don't particularly like this solution either, but I evaluated a few other
> options (see below).

I also do not like it.

>     Is the simplest solution adding a weak function call asks which mode and the
>     default call returns RGMII?
> 
> The downside to that is that none of the tests can operate as expected on a
> SGMII-attached-PHY system since the application would be overriding the weak
> symbol and the tests wouldn't do that. Another option would be to have a generic
> option in RTEMS that specifies the PHY attachment and can be set in config.ini,
> but that would appear to be dead code since it's not used within RTEMS.

Would FDT solve this problem? Forcing FDT support onto the cgem driver would
break compatibility so it would have to handle a default state. If FDT probes
were tolerant of calls without a valid FDT being loaded it would be better but
our FDT support seems to have no middle ground from what I can see.

> As far as I'm aware, the closest analog in LibBSD would be the buildset
> configuration, but that seems more like a place to define which modules get
> built than a location for configuring hardware.

I think FDT is handling this stuff for other archs and the MRMAC will also
require FDT support.

Chris