DSA driver kernel extension for dsa mv88e6190 switch

DSA driver kernel extension for dsa mv88e6190 switch

[Zoran Stojsavljevic]

Hello Community,

We have interesting problem to solve using our HW platform. And I hope
somebody has the similar example, and some patches, which need to be
applied to the kernel (directory .../drivers/net/dsa/) to make this
application to work.

We have the configuration problem with the Marvell 88E6190 switch.
What the our problem is... Is the switch is NOT configured with the
EEPROM (24C512), which does not exist on the board. It is put in
autoconfig by HW straps (NOCPU mode). Once the MDIO command, issued to
probe the switch and read the make of it, the switch jumps out of the
autoconfig mode. There are some commands issued from the DSA to
configure the switch (to apply to switch TXC and RXC RGMII delays -
RGMII-ID mode), but this is not enough to make it work properly.

Once the configuration is not properly applied (NOT configured via
EEPROM 24C512). We have problems when the Linux booting phase comes to
LIBPHY. Since switch should be transparent to the PHYs at that time,
but my best guess, it is not!

Once LIBPHY starts writing to the switch (since MDIO commands are not
reaching PHYs), switch blocks. Exists from auto config mode and
refuses to respond (my best guess). So no ping possible on the
MV88E61890 MACs and through after Linux boots.

If we physically cut the MDIO line and put the switch in autoconfig
mode, then switch stays in autoconfig mode (by HW straps), but then it
is impossible to do RGMII TxC and RxC clock skew, since i.MX6 has the
silicon bug which does NOT allow this skew to be applied to i.MX6 (1.5
ns skew MUST be applied to the both clocks). If this done from the
DSA, (having MDIO fully in effect), the switch goes out of autoconfig
and does not finish the proper config.

I have here three questions, I hope there are some educated suggestions?

[1] Does this, what I wrote here, sound resonable (Google has very
little on it)?

[2] Does this problem with MV88E6190 switch could be solved
introducing some MV88E6190 configuration via RGMII mode in U-Boot
(setting the switch in U-boot and letting kernel do what it does, at
the end everything works seamlessly)?

[3] Does anybody have pointer to some similar patches for the DSA
driver addendum (NO U-boot involved), how to properly deal with this
problem and fully configure the switch from Linux DSA driver (chip.c
as switch config, and port.c files)??

Any advice is appreciated!

Thank you in advance,
Zoran
_______

Re: DSA driver kernel extension for dsa mv88e6190 switch

[Andrew Lunn]

> We have the configuration problem with the Marvell 88E6190 switch.
> What the our problem is... Is the switch is NOT configured with the
> EEPROM (24C512), which does not exist on the board.

That is pretty normal. If there is a EEPROM, i generally recommend it
is left empty. We want Linux to configure the switch, and if it finds
it already partially configured, things can get confused.

> It is put in autoconfig by HW straps (NOCPU mode).

So dumb switch mode. All ports are switched between each other.

> Once the MDIO command, issued to
> probe the switch and read the make of it, the switch jumps out of the
> autoconfig mode.

Correct. Dumb switch mode is dangerous. There is no STP, etc.
Depending on what you have in device tree, the ports are either
configured down, or separated.

> There are some commands issued from the DSA to
> configure the switch (to apply to switch TXC and RXC RGMII delays -
> RGMII-ID mode), but this is not enough to make it work properly.

Define 'work properly'. How are you configuring the interfaces?  Do
you remember to bring the master interface up? Are you adding the
interfaces to a bridge?

   Andrew

Re: DSA driver kernel extension for dsa mv88e6190 switch

[Zoran Stojsavljevic]

Hello Andrew,

I would like to thank you for the reply.

I do not know if this is the right place to post such the questions,
but my best guess is: yes.

Since till now I did not make any success to make (using DSA driver)
make mv88e6190 single switch to work with any kernel.org. :-(

I did ugly workaround as kernel dsa patch, which allowed me to
introduce TXC and RXC clock skews between I.MX6 and mv88e6190 (MAC to
MAC layer over rgmii).

And, yes, switch is working in dummy state (as you correctly described
it), passing traffic everywhere (flooding).

i.MX6 has a silicon bug, which does not allow skew configuration on
its side. PCB is out of consideration, so this ugly patch makes switch
to apply these two delays.Then, in dummy state, everything works.
_______

My DTS mv88e6190 configuration, which I adopted for the custom board I
am working on, could be seen here:
https://pastebin.com/xpXQYNRX

But on another note... I am wondering if I am setting correct kernel
configuration for it?!

Here is the part of the configuration I made while going through maze
of posts from google search results:

      Switch (and switch-ish) device support @ Networking
support->Networking options
      Distributed Switch Architecture @ Networking support->Networking options
      Tag driver for Marvell switches using DSA headers @ Networking
support->Networking options->Distributed Switch Architecture
      Tag driver for Marvell switches using EtherType DSA headers @
Networking support->Networking options->Distributed Switch
Architecture
      Marvell 88E6xxx Ethernet switch fabric support @ Device
Drivers->Network device support->Distributed Switch Architecture
drivers
      Switch Global 2 Registers support @ Device Drivers->Network
device support->Distributed Switch Architecture drivers->Marvell
88E6xxx Ethernet switch fabric support
      Freescale devices @ Device Drivers->Network device
support->Ethernet driver support
      FEC ethernet controller (of ColdFire and some i.MX CPUs) @
Device Drivers->Network device support->Ethernet driver
support->Freescale devices
      Marvell devices @ Device Drivers->Network device
support->Ethernet driver support
      Marvell MDIO interface support @ Device Drivers->Network device
support->Ethernet driver support->Marvell devices
      MDIO Bus/PHY emulation with fixed speed/link PHYs @ Device
Drivers->Network device support->PHY Device support and infrastructure

(Do we need Marvell PHYs option as =y ? I do not think so - should be:
is not set)

What possibly I made wrong here (this does not work - I could not get
through the switch, and seems that MDIO works (from the logic
analyzer), but addresses some 0x1B/0x1C ports, which should NOT be
addressed, according to the the DTS configuration shown)?

Thank you,
Zoran
_______

On Thu, Sep 26, 2019 at 1:10 AM Andrew Lunn <andrew@lunn.ch> wrote:
>
> > We have the configuration problem with the Marvell 88E6190 switch.
> > What the our problem is... Is the switch is NOT configured with the
> > EEPROM (24C512), which does not exist on the board.
>
> That is pretty normal. If there is a EEPROM, i generally recommend it
> is left empty. We want Linux to configure the switch, and if it finds
> it already partially configured, things can get confused.
>
> > It is put in autoconfig by HW straps (NOCPU mode).
>
> So dumb switch mode. All ports are switched between each other.
>
> > Once the MDIO command, issued to
> > probe the switch and read the make of it, the switch jumps out of the
> > autoconfig mode.
>
> Correct. Dumb switch mode is dangerous. There is no STP, etc.
> Depending on what you have in device tree, the ports are either
> configured down, or separated.
>
> > There are some commands issued from the DSA to
> > configure the switch (to apply to switch TXC and RXC RGMII delays -
> > RGMII-ID mode), but this is not enough to make it work properly.
>
> Define 'work properly'. How are you configuring the interfaces?  Do
> you remember to bring the master interface up? Are you adding the
> interfaces to a bridge?
>
>    Andrew

Re: DSA driver kernel extension for dsa mv88e6190 switch

[Andrew Lunn]

On Thu, Sep 26, 2019 at 03:23:48PM +0200, Zoran Stojsavljevic wrote:
> Hello Andrew,
> 
> I would like to thank you for the reply.
> 
> I do not know if this is the right place to post such the questions,
> but my best guess is: yes.
> 
> Since till now I did not make any success to make (using DSA driver)
> make mv88e6190 single switch to work with any kernel.org. :-(
> 
> I did ugly workaround as kernel dsa patch, which allowed me to
> introduce TXC and RXC clock skews between I.MX6 and mv88e6190 (MAC to
> MAC layer over rgmii).

You should not need any kernel patches for switch side RGMII
delays. rgmii-id in the DT for the switch CPU port should be enough.
Some of the vf610-zii platforms use it.

> My DTS mv88e6190 configuration, which I adopted for the custom board I
> am working on, could be seen here:
> https://pastebin.com/xpXQYNRX

So you have the FEC using rgmii-id. Which you say does not work?  So
why not use plain rgmii. What you have in port@0 looks correct.

gpios = <&gpio1 29 GPIO_ACTIVE_HIGH>; is wrong. It probably should be
reset-gpios. The rest looks O.K.

 
> But on another note... I am wondering if I am setting correct kernel
> configuration for it?!
> 
> Here is the part of the configuration I made while going through maze
> of posts from google search results:
> 
>       Switch (and switch-ish) device support @ Networking
> support->Networking options
>       Distributed Switch Architecture @ Networking support->Networking options
>       Tag driver for Marvell switches using DSA headers @ Networking
> support->Networking options->Distributed Switch Architecture
>       Tag driver for Marvell switches using EtherType DSA headers @
> Networking support->Networking options->Distributed Switch
> Architecture
>       Marvell 88E6xxx Ethernet switch fabric support @ Device
> Drivers->Network device support->Distributed Switch Architecture
> drivers
>       Switch Global 2 Registers support @ Device Drivers->Network
> device support->Distributed Switch Architecture drivers->Marvell
> 88E6xxx Ethernet switch fabric support
>       Freescale devices @ Device Drivers->Network device
> support->Ethernet driver support
>       FEC ethernet controller (of ColdFire and some i.MX CPUs) @
> Device Drivers->Network device support->Ethernet driver
> support->Freescale devices
>       Marvell devices @ Device Drivers->Network device
> support->Ethernet driver support
>       Marvell MDIO interface support @ Device Drivers->Network device
> support->Ethernet driver support->Marvell devices
>       MDIO Bus/PHY emulation with fixed speed/link PHYs @ Device
> Drivers->Network device support->PHY Device support and infrastructure
> 
> (Do we need Marvell PHYs option as =y ? I do not think so - should be:
> is not set)

Yes you do. The PHYs inside the switch are Marvell.
 
> What possibly I made wrong here (this does not work - I could not get
> through the switch, and seems that MDIO works (from the logic
> analyzer), but addresses some 0x1B/0x1C ports, which should NOT be
> addressed, according to the the DTS configuration shown)?

0x1b is global1, and 0x1c is global2. These are registers shared by
all ports.

Please show me the configuration steps you are doing? How are you
configuring the FEC and the switch interfaces?

    Andrew

Re: DSA driver kernel extension for dsa mv88e6190 switch

[Zoran Stojsavljevic]

Hello Andrew,

> You should not need any kernel patches for switch side RGMII
> delays. rgmii-id in the DT for the switch CPU port should be enough.
> Some of the vf610-zii platforms use it.

It should, but it does NOT work. IT is clearly stated in port.c, in f-n:
static int mv88e6xxx_port_set_rgmii_delay(struct mv88e6xxx_chip *chip, int port,
                                          phy_interface_t mode)

The logic analyser shows MDIO write to register 0x01, which is 0x6003.
Seems the correct value.

But, at the very end, ethtool shows that this clock skew is NOT
inserted. I see on RX side CRC errors. Every ethernet frame while
pinging.

I see another interesting fact, the dmesg, which you could see here:
https://pastebin.com/igXS6eXe

[    1.182273] DEBUG INFO! <- addr: 0x00 reg: 0x03 val: 0x1901
[    1.187888] mv88e6085 2188000.ethernet-1:00: switch 0x1900
detected: Marvell 88E6190, revision 1
[    1.219804] random: fast init done
[    1.225334] libphy: mv88e6xxx SMI: probed
[    1.232709] fec 2188000.ethernet eth0: registered PHC device 0

[    1.547946] DEBUG INFO! <- addr: 0x00 reg: 0x03 val: 0x1901
[    1.553542] mv88e6085 2188000.ethernet-1:00: switch 0x1900
detected: Marvell 88E6190, revision 1
[    1.555432]  mmcblk1: p1
[    1.598106] libphy: mv88e6xxx SMI: probed
[    1.740362] DSA: tree 0 setup

There are two distinct accesses while driver configures the switch. Why???

I was not able to explain this to me... Or find explanation using google?!

> gpios = <&gpio1 29 GPIO_ACTIVE_HIGH>; is wrong. It probably
> should be reset-gpios. The rest looks O.K.

I will follow the advise, but I do not think this is an obstacle.

> Please show me the configuration steps you are doing? How are you
> configuring the FEC and the switch interfaces?

Forgive me for my ignorance, but I have no idea what you have asked me for?

Did you ask me to attach .config file? If not, could you, please,
explain to me more concrete, what did you ask for? Some example would
be perfect!

Thank you,
Zoran
_______

On Thu, Sep 26, 2019 at 3:39 PM Andrew Lunn <andrew@lunn.ch> wrote:
>
> On Thu, Sep 26, 2019 at 03:23:48PM +0200, Zoran Stojsavljevic wrote:
> > Hello Andrew,
> >
> > I would like to thank you for the reply.
> >
> > I do not know if this is the right place to post such the questions,
> > but my best guess is: yes.
> >
> > Since till now I did not make any success to make (using DSA driver)
> > make mv88e6190 single switch to work with any kernel.org. :-(
> >
> > I did ugly workaround as kernel dsa patch, which allowed me to
> > introduce TXC and RXC clock skews between I.MX6 and mv88e6190 (MAC to
> > MAC layer over rgmii).
>
> You should not need any kernel patches for switch side RGMII
> delays. rgmii-id in the DT for the switch CPU port should be enough.
> Some of the vf610-zii platforms use it.
>
> > My DTS mv88e6190 configuration, which I adopted for the custom board I
> > am working on, could be seen here:
> > https://pastebin.com/xpXQYNRX
>
> So you have the FEC using rgmii-id. Which you say does not work?  So
> why not use plain rgmii. What you have in port@0 looks correct.
>
> gpios = <&gpio1 29 GPIO_ACTIVE_HIGH>; is wrong. It probably should be
> reset-gpios. The rest looks O.K.
>
>
> > But on another note... I am wondering if I am setting correct kernel
> > configuration for it?!
> >
> > Here is the part of the configuration I made while going through maze
> > of posts from google search results:
> >
> >       Switch (and switch-ish) device support @ Networking
> > support->Networking options
> >       Distributed Switch Architecture @ Networking support->Networking options
> >       Tag driver for Marvell switches using DSA headers @ Networking
> > support->Networking options->Distributed Switch Architecture
> >       Tag driver for Marvell switches using EtherType DSA headers @
> > Networking support->Networking options->Distributed Switch
> > Architecture
> >       Marvell 88E6xxx Ethernet switch fabric support @ Device
> > Drivers->Network device support->Distributed Switch Architecture
> > drivers
> >       Switch Global 2 Registers support @ Device Drivers->Network
> > device support->Distributed Switch Architecture drivers->Marvell
> > 88E6xxx Ethernet switch fabric support
> >       Freescale devices @ Device Drivers->Network device
> > support->Ethernet driver support
> >       FEC ethernet controller (of ColdFire and some i.MX CPUs) @
> > Device Drivers->Network device support->Ethernet driver
> > support->Freescale devices
> >       Marvell devices @ Device Drivers->Network device
> > support->Ethernet driver support
> >       Marvell MDIO interface support @ Device Drivers->Network device
> > support->Ethernet driver support->Marvell devices
> >       MDIO Bus/PHY emulation with fixed speed/link PHYs @ Device
> > Drivers->Network device support->PHY Device support and infrastructure
> >
> > (Do we need Marvell PHYs option as =y ? I do not think so - should be:
> > is not set)
>
> Yes you do. The PHYs inside the switch are Marvell.
>
> > What possibly I made wrong here (this does not work - I could not get
> > through the switch, and seems that MDIO works (from the logic
> > analyzer), but addresses some 0x1B/0x1C ports, which should NOT be
> > addressed, according to the the DTS configuration shown)?
>
> 0x1b is global1, and 0x1c is global2. These are registers shared by
> all ports.
>
> Please show me the configuration steps you are doing? How are you
> configuring the FEC and the switch interfaces?
>
>     Andrew

Re: DSA driver kernel extension for dsa mv88e6190 switch

[Andrew Lunn]

On Sat, Sep 28, 2019 at 01:00:43AM +0200, Zoran Stojsavljevic wrote:
> Hello Andrew,
> 
> > You should not need any kernel patches for switch side RGMII
> > delays. rgmii-id in the DT for the switch CPU port should be enough.
> > Some of the vf610-zii platforms use it.
> 
> It should, but it does NOT work. IT is clearly stated in port.c, in f-n:
> static int mv88e6xxx_port_set_rgmii_delay(struct mv88e6xxx_chip *chip, int port,
>                                           phy_interface_t mode)
> 
> The logic analyser shows MDIO write to register 0x01, which is 0x6003.
> Seems the correct value.
> 
> But, at the very end, ethtool shows that this clock skew is NOT
> inserted.

How do you see this with ethtool?

> I see on RX side CRC errors. Every ethernet frame while
> pinging.

But TX works? Maybe the FEC is doing some sort of delay, even if it
has a hardware bug.
 
> I see another interesting fact, the dmesg, which you could see here:
> https://pastebin.com/igXS6eXe
> 
> [    1.182273] DEBUG INFO! <- addr: 0x00 reg: 0x03 val: 0x1901
> [    1.187888] mv88e6085 2188000.ethernet-1:00: switch 0x1900
> detected: Marvell 88E6190, revision 1
> [    1.219804] random: fast init done
> [    1.225334] libphy: mv88e6xxx SMI: probed
> [    1.232709] fec 2188000.ethernet eth0: registered PHC device 0
> 
> [    1.547946] DEBUG INFO! <- addr: 0x00 reg: 0x03 val: 0x1901
> [    1.553542] mv88e6085 2188000.ethernet-1:00: switch 0x1900
> detected: Marvell 88E6190, revision 1
> [    1.555432]  mmcblk1: p1
> [    1.598106] libphy: mv88e6xxx SMI: probed
> [    1.740362] DSA: tree 0 setup
> 
> There are two distinct accesses while driver configures the switch. Why???

This happens when the driver is missing a resource during probe.  It
returns the error -EPROBE_DEFER, and the linux driver core will try
the probe again later. Probably the second time all the resources it
needs will be present and the probe will be successful.

I will probably have a some patches during the next kernel merge cycle
to make this a bit more efficient.

> I was not able to explain this to me... Or find explanation using google?!
> 
> > gpios = <&gpio1 29 GPIO_ACTIVE_HIGH>; is wrong. It probably
> > should be reset-gpios. The rest looks O.K.
> 
> I will follow the advise, but I do not think this is an obstacle.

No, it is not an obstacle, but it is still wrong.

> 
> > Please show me the configuration steps you are doing? How are you
> > configuring the FEC and the switch interfaces?
> 
> Forgive me for my ignorance, but I have no idea what you have asked me for?

ip link set eth0 up
ip link set lan0 up
ip link set lan1 up
ip link name br0 type bridge
ip link set br0 up
ip link lan0 master br0
ip link lan1 master br0

   Andrew

Re: DSA driver kernel extension for dsa mv88e6190 switch

[Zoran Stojsavljevic]

Hello Andrew,

I see dead people... Really i do! After your reply.

> This happens when the driver is missing a resource during probe.  It
> returns the error -EPROBE_DEFER, and the linux driver core will try
> the probe again later. Probably the second time all the resources it
> needs will be present and the probe will be successful.

Thank you for the explanation. It helps to understand better the logs.

> I will probably have a some patches during the next kernel merge cycle
> to make this a bit more efficient.

I am very interested on these patches. Please, keep me in the loop! Please.

> No, it is not an obstacle, but it is still wrong.

It is. Agree. This (DTS for the custom board) I'll fix Monday. It is Sunday...

> ip link set eth0 up
> ip link set lan0 up
> ip link set lan1 up
> ip link name br0 type bridge
> ip link set br0 up
> ip link lan0 master br0
> ip link lan1 master br0

Crucifix! I totally forgot to configure interfaces!!! This is why I do
NOT see pings, since rgmii management port 0 does NOT have phy
attached!!!

The whole thing MUST be configured as link layer (bridge), to work
properly on MAC/PHY layers. About STP (routing), this is not mandatory
now.

I am dumb old dog... Sorry, even dumber! I admit... Happens! :-(

I wrote my (very first) public GIST about that. Please, could you
review it, and point to the any logical bugs in there?
https://gist.github.com/ZoranStojsavljevic/423b96e2ca3bd581f7ce417cb410c465

Thank you many many times,
Zoran
_______

On Sat, Sep 28, 2019 at 5:21 PM Andrew Lunn <andrew@lunn.ch> wrote:
>
> On Sat, Sep 28, 2019 at 01:00:43AM +0200, Zoran Stojsavljevic wrote:
> > Hello Andrew,
> >
> > > You should not need any kernel patches for switch side RGMII
> > > delays. rgmii-id in the DT for the switch CPU port should be enough.
> > > Some of the vf610-zii platforms use it.
> >
> > It should, but it does NOT work. IT is clearly stated in port.c, in f-n:
> > static int mv88e6xxx_port_set_rgmii_delay(struct mv88e6xxx_chip *chip, int port,
> >                                           phy_interface_t mode)
> >
> > The logic analyser shows MDIO write to register 0x01, which is 0x6003.
> > Seems the correct value.
> >
> > But, at the very end, ethtool shows that this clock skew is NOT
> > inserted.
>
> How do you see this with ethtool?
>
> > I see on RX side CRC errors. Every ethernet frame while
> > pinging.
>
> But TX works? Maybe the FEC is doing some sort of delay, even if it
> has a hardware bug.
>
> > I see another interesting fact, the dmesg, which you could see here:
> > https://pastebin.com/igXS6eXe
> >
> > [    1.182273] DEBUG INFO! <- addr: 0x00 reg: 0x03 val: 0x1901
> > [    1.187888] mv88e6085 2188000.ethernet-1:00: switch 0x1900
> > detected: Marvell 88E6190, revision 1
> > [    1.219804] random: fast init done
> > [    1.225334] libphy: mv88e6xxx SMI: probed
> > [    1.232709] fec 2188000.ethernet eth0: registered PHC device 0
> >
> > [    1.547946] DEBUG INFO! <- addr: 0x00 reg: 0x03 val: 0x1901
> > [    1.553542] mv88e6085 2188000.ethernet-1:00: switch 0x1900
> > detected: Marvell 88E6190, revision 1
> > [    1.555432]  mmcblk1: p1
> > [    1.598106] libphy: mv88e6xxx SMI: probed
> > [    1.740362] DSA: tree 0 setup
> >
> > There are two distinct accesses while driver configures the switch. Why???
>
> This happens when the driver is missing a resource during probe.  It
> returns the error -EPROBE_DEFER, and the linux driver core will try
> the probe again later. Probably the second time all the resources it
> needs will be present and the probe will be successful.
>
> I will probably have a some patches during the next kernel merge cycle
> to make this a bit more efficient.
>
> > I was not able to explain this to me... Or find explanation using google?!
> >
> > > gpios = <&gpio1 29 GPIO_ACTIVE_HIGH>; is wrong. It probably
> > > should be reset-gpios. The rest looks O.K.
> >
> > I will follow the advise, but I do not think this is an obstacle.
>
> No, it is not an obstacle, but it is still wrong.
>
> >
> > > Please show me the configuration steps you are doing? How are you
> > > configuring the FEC and the switch interfaces?
> >
> > Forgive me for my ignorance, but I have no idea what you have asked me for?
>
> ip link set eth0 up
> ip link set lan0 up
> ip link set lan1 up
> ip link name br0 type bridge
> ip link set br0 up
> ip link lan0 master br0
> ip link lan1 master br0
>
>    Andrew

Re: DSA driver kernel extension for dsa mv88e6190 switch

[Andrew Lunn]

> I wrote my (very first) public GIST about that. Please, could you
> review it, and point to the any logical bugs in there?
> https://gist.github.com/ZoranStojsavljevic/423b96e2ca3bd581f7ce417cb410c465

The very last line is wrong.

ifconfig eth0 192.168.1.4 up

You should put the IP address on the bridge, not the master device
eth0.

ip addr add 192.168.1.4/24 dev br0

FYI: ifconfig has been deprecated for maybe a decade?

   Andrew

Re: DSA driver kernel extension for dsa mv88e6190 switch

[Zoran Stojsavljevic]

> The very last line is wrong.
> ifconfig eth0 192.168.1.4 up

Typo. It was fixed after few hours I created the gist.

> You should put the IP address on the bridge, not the master
> device eth0.
> ip addr add 192.168.1.4/24 dev br0

Noted. Thank you.

> FYI: ifconfig has been deprecated for maybe a decade?

I am an old dog, and old dogs could not be tough to new tricks. ;-)

This is why I always install on Debian additional net-tools package.

I guess, time to move to modern ip command.
_______

Please, please, keep me in the loop about DSA patches.

Many many thanks for advises/emails,
Zoran
_______


On Mon, Sep 30, 2019 at 3:44 AM Andrew Lunn <andrew@lunn.ch> wrote:
>
> > I wrote my (very first) public GIST about that. Please, could you
> > review it, and point to the any logical bugs in there?
> > https://gist.github.com/ZoranStojsavljevic/423b96e2ca3bd581f7ce417cb410c465
>
> The very last line is wrong.
>
> ifconfig eth0 192.168.1.4 up
>
> You should put the IP address on the bridge, not the master device
> eth0.
>
> ip addr add 192.168.1.4/24 dev br0
>
> FYI: ifconfig has been deprecated for maybe a decade?
>
>    Andrew