[U-Boot] Rework the network stack

[Joe Hershberger]

On Mon, Mar 23, 2015 at 3:04 PM, Simon Glass <sjg at chromium.org> wrote:
>
> Hi,
>
> On 23 March 2015 at 13:55, Jörg Krause <joerg.krause at embedded.rocks>
wrote:
> >
> > Joe, Simon,
> >
> > On Mo, 2015-03-23 at 10:46 -0600, Simon Glass wrote:
> > > Hi Jörg,
> > >
> > > On 22 March 2015 at 14:37, Jörg Krause <joerg.krause at embedded.rocks>
wrote:
> > > > Hi Joe,

8<--snip

> > > > I had a look at the patches and the code base is not entirely the
same.
> > > > But maybe we should just stick to the crucial points of the new
network
> > > > stack:
> > > >
> > > > 1) A network device gets initialized when it becomes the current
one and
> > > > gets brought down when it's not used anymore or prior booting to
Linux
> > > > so the connection remains active all the time.

I think that's a reasonable goal.

> > > > My thoughts about this one:
> > > > Bringing the device down can be done in eth_unregister().
Initializing
> > > > for the current device can be done in eth_current_changed(). What I
like
> > > > even better is to make eth_current_changed() the sole place for
calling
> > > > init() and halt(). It would have to be extend to take at least two
> > > > parameters, eth_current and new_current. If eth_current is null just
> > > > bring up the new device, if new_current is null just bring down the
> > > > current device.

This would fit into the driver model implementation differently. I'm not
sure we care to change it in the old Ethernet support. All the more reason
to upgrade to the DM implementation.

> > > > 2) Replace the NetLoop by a connection list where each protocol
uses a
> > > > connection to send and receive packets.

I wonder if that is more complex than needed. It is the case that the only
concurrent operations we need is NetConsole and one other operation. ARP is
already handled in sequence and should not need to be considered concurrent
(even though it could be). Perhaps we can find a way to allow NetConsole to
operate outside of the typical "packet handler'.

> > > > This induce to port all protocols to use the new network, of cause.

It would be nice to not need to change all protocols.

> > > > In my opinion it would be also good to do some clean ups and
> > > > restructuring of code. Put more functions into net-utils, is there a
> > > > need for eth_init and so on.

I certainly agree that there are more clean-ups to be done. I don't agree
that they should be connected to this change. The more meaningless renames
we have in the series the harder it is to see and grok the substantive
changes. This is very apparent in Sascha's patch series. It would be much
easier to read / port if not clouded by essentially unrelated refactoring.

> > > Joe has done a lot of work to move U-Boot's network stack over to
> > > driver model. This is now at u-boot-dm/next waiting for the merge
> > > window to open.
> > >
> > > The connection list idea does not sound like a hugely complex change.
> > > Are you thinking of trying it out?

Let's try to start simpler. We can refactor further if needed.

> > I have just noticed today the big series of u-boot-dm patches of Joe. I
> > will try it out. But before I will start I want to discuss the concept.
> > What do you think about my thoughts about bringing up and down a network
> > device?

I think it can be done when probed. In fact I'm not sure there's a reason
more than one cannot be started at a time. We can certainly have more than
one probed at a time. We just need to remove them before booting to
Linux. eth_pre_remove() already calls eth_get_ops(dev)->stop(dev).

> Joe is the expert here.
>
> With driver model the actual bring-up should be automatic (i.e. it is
> probed as soon as it is used).

As long as we move the call to eth_get_ops(current)->start(current); to the
probe function, then this is true.

> Regards,
> Simon