[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20200528163335.8f730b5a3ddc8cd9beab367f@suse.de>
Date: Thu, 28 May 2020 16:33:35 +0200
From: Thomas Bogendoerfer <tbogendoerfer@...e.de>
To: Russell King - ARM Linux admin <linux@...linux.org.uk>
Cc: "David S. Miller" <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH net] net: mvpp2: Enable autoneg bypass for
1000BaseX/2500BaseX ports
On Thu, 28 May 2020 14:56:08 +0100
Russell King - ARM Linux admin <linux@...linux.org.uk> wrote:
> On Thu, May 28, 2020 at 03:17:33PM +0200, Thomas Bogendoerfer wrote:
> > On Thu, 28 May 2020 14:07:38 +0100
> > Russell King - ARM Linux admin <linux@...linux.org.uk> wrote:
> >
> > > On Thu, May 28, 2020 at 02:11:21PM +0200, Thomas Bogendoerfer wrote:
> > > > Commit d14e078f23cc ("net: marvell: mvpp2: only reprogram what is necessary
> > > > on mac_config") disabled auto negotiation bypass completely, which breaks
> > > > platforms enabling bypass via firmware (not the best option, but it worked).
> > > > Since 1000BaseX/2500BaseX ports neither negotiate speed nor duplex mode
> > > > we could enable auto negotiation bypass to get back information about link
> > > > state.
> > >
> > > Thanks, but your commit is missing some useful information.
> > >
> > > Which platforms have broken?
> >
> > it's an Ambedded MARS-400
> >
> > > Can you describe the situation where you require this bit to be set?
> >
> > as I have no exact design details I'm just talking about what I can see
> > on that platform. It looks like the switch connecting the internal nodes
> > doesn't run autoneg on the internal links. So the link to the internal
> > nodes will never come up. These links are running 2500BaseX so speed/duplex
> > is clean and by enabling bypass I'll get a proper link state, too.
> >
> > > We should not be enabling bypass mode as a matter of course, it exists
> > > to work around broken setups which do not send the control word.
> >
> > if you call it a broken setup I'm fine, but this doesn't solve the problem,
> > which exists now. What would be your solution ?
>
> What I was after was additional information about the problem, so
> that we can start thinking about how to deal with the AN bypass bit
> in a sensible way.
>
> How is the connection between the switch and network interface
> described? I don't think I see a .dts file in mainline for this
> platform.
below is the dts part for the two network interfaces. The switch to
the outside has two ports, which correlate to the two internal ports.
And the switch propagates the link state of the external ports to
the internal ports.
Thomas.
&cp0_eth1 {
status = "okay";
phy-mode = "2500base-x";
mac-address = [00 00 00 00 00 01];
interrupts = <41 IRQ_TYPE_LEVEL_HIGH>,
<45 IRQ_TYPE_LEVEL_HIGH>,
<49 IRQ_TYPE_LEVEL_HIGH>,
<53 IRQ_TYPE_LEVEL_HIGH>,
<57 IRQ_TYPE_LEVEL_HIGH>,
<61 IRQ_TYPE_LEVEL_HIGH>,
<65 IRQ_TYPE_LEVEL_HIGH>,
<69 IRQ_TYPE_LEVEL_HIGH>,
<73 IRQ_TYPE_LEVEL_HIGH>,
<127 IRQ_TYPE_LEVEL_HIGH>;
interrupt-names = "hif0", "hif1", "hif2",
"hif3", "hif4", "hif5", "hif6", "hif7",
"hif8", "link";
port-id = <2>;
gop-port-id = <3>;
managed = "in-band-status";
};
&cp0_eth2 {
status = "okay";
phy-mode = "2500base-x";
mac-address = [00 00 00 00 00 02];
interrupts = <40 IRQ_TYPE_LEVEL_HIGH>,
<44 IRQ_TYPE_LEVEL_HIGH>,
<48 IRQ_TYPE_LEVEL_HIGH>,
<52 IRQ_TYPE_LEVEL_HIGH>,
<56 IRQ_TYPE_LEVEL_HIGH>,
<60 IRQ_TYPE_LEVEL_HIGH>,
<64 IRQ_TYPE_LEVEL_HIGH>,
<68 IRQ_TYPE_LEVEL_HIGH>,
<72 IRQ_TYPE_LEVEL_HIGH>,
<128 IRQ_TYPE_LEVEL_HIGH>;
interrupt-names = "hif0", "hif1", "hif2",
"hif3", "hif4", "hif5", "hif6", "hif7",
"hif8", "link";
port-id = <1>;
gop-port-id = <2>;
managed = "in-band-status";
};
--
SUSE Software Solutions Germany GmbH
HRB 36809 (AG Nürnberg)
Geschäftsführer: Felix Imendörffer
Powered by blists - more mailing lists