> I hope that using "*-internal-delay-ps" for Mac would be the right option.
> Shall i include these changes as we discussed in next revision of the patch?
Yes, that seems sensible. But please limit them to the CPU port. Maybe
return -EINVAL for other ports.
Andrew
On Wed, Aug 11, 2021 at 08:23:04PM +0200, Andrew Lunn wrote:
> > I hope that using "*-internal-delay-ps" for Mac would be the right option.
> > Shall i include these changes as we discussed in next revision of the patch?
>
> Yes, that seems sensible. But please limit them to the CPU port. Maybe
> return -EINVAL for other ports.
Hmm. Don't we want ports that are "MAC like" to behave "MAC like" ?
In other words, shouldn't a DSA port that can be connected to an
external PHY should accept the same properties as a conventional
Ethernet MAC e.g. in a SoC device?
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
On Wed, Aug 11, 2021 at 09:14:14PM +0100, Russell King (Oracle) wrote:
> On Wed, Aug 11, 2021 at 08:23:04PM +0200, Andrew Lunn wrote:
> > > I hope that using "*-internal-delay-ps" for Mac would be the right option.
> > > Shall i include these changes as we discussed in next revision of the patch?
> >
> > Yes, that seems sensible. But please limit them to the CPU port. Maybe
> > return -EINVAL for other ports.
>
> Hmm. Don't we want ports that are "MAC like" to behave "MAC like" ?
> In other words, shouldn't a DSA port that can be connected to an
> external PHY should accept the same properties as a conventional
> Ethernet MAC e.g. in a SoC device?
+1, I thought the whole purpose of the discussion was to stop singling
out the CPU port as being special in any way w.r.t. RGMII delays.
On Wed, Aug 11, 2021 at 11:20:19PM +0300, Vladimir Oltean wrote:
> On Wed, Aug 11, 2021 at 09:14:14PM +0100, Russell King (Oracle) wrote:
> > On Wed, Aug 11, 2021 at 08:23:04PM +0200, Andrew Lunn wrote:
> > > > I hope that using "*-internal-delay-ps" for Mac would be the right option.
> > > > Shall i include these changes as we discussed in next revision of the patch?
> > >
> > > Yes, that seems sensible. But please limit them to the CPU port. Maybe
> > > return -EINVAL for other ports.
> >
> > Hmm. Don't we want ports that are "MAC like" to behave "MAC like" ?
> > In other words, shouldn't a DSA port that can be connected to an
> > external PHY should accept the same properties as a conventional
> > Ethernet MAC e.g. in a SoC device?
>
> +1, I thought the whole purpose of the discussion was to stop singling
> out the CPU port as being special in any way w.r.t. RGMII delays.
Yes, sorry.
What we don't want is it acting upon phy-mode.
Andrew