> Getting the Kconfig for this correct has been a struggle - particularly
> the combination where PTP support is modular. It's rather odd to have
> the Marvell PTP support asked before the Marvell PHY support. I
> couldn't work out any other reasonable way to ensure that we always
> have a valid configuration, without leading to stupidities such as
> having the PTP and Marvell PTP support modular, but non-functional
> because Marvell PHY is built-in.
Hi Russell
How much object code is this adding? All the other PHYs which support
PTP just make it part of the PHY driver, not a standalone module. That
i guess simplifies the conditions.
Looking at DSDT, it lists
case MAD_88E1340S:
case MAD_88E1340:
case MAD_88E1340M:
case MAD_SWG65G :
case MAD_88E151x:
as being MAD_PHY_PTP_TAI_CAPABLE;
and
case MAD_88E1548
case MAD_88E1680:
case MAD_88E1680M:
as MAD_PHY_1STEP_PTP_CAPABLE;
So maybe we can wire this up to a few more PHYs to 'lower' the
overhead a bit?
> It seems that the Marvell PHY PTP is very similar to that found in
> their DSA chips, which suggests maybe we should share the code, but
> different access methods would be required.
That makes the Kconfig even more complex :-(
Andrew
