[PATCH v3 2/2] cmd: brcm: netXtreme commands

[Marek Behún]

On Tue, 26 Oct 2021 09:02:54 -0700
Roman Bacik <roman.bacik at broadcom.com> wrote:

> On Tue, Oct 26, 2021 at 8:55 AM Marek Behún <kabel at kernel.org> wrote:
> >
> > On Tue, 26 Oct 2021 08:14:28 -0700
> > Roman Bacik <roman.bacik at broadcom.com> wrote:
> >  
> > > Hi Marek,
> > >
> > > We do not want this driver to be automatically probed. It is not needed
> > > all the time and also slows down the boot time. We have stripped down
> > > everything else to bare minimum.
> > > Thanks,
> > >
> > > Roman  
> >
> > Hi Roman,
> >
> > OK, that is reasonable, but not reasonable enough to introduce a new
> > vendor specific command.
> >
> > Still NAK.
> >
> > So you have the bnxt_drv_probe method defined in the driver, but you
> > don't set a pointer to it into the U_BOOT_DRIVER structure, and instead
> > you call this method when "brcm probe" command is called.
> >
> > I think this introduction of another vendor specific command is wrong.
> >
> > If probing takes too much time and should be done only when the device
> > is needed, there are 2 things you could do:
> >
> > - you can create new driver flag saying that the device should be
> >   probeb only when needed, wire necessary code and add this flag to your
> >   driver (this could get very complicated, though)
> > - you can do minimum stuff in probe method, and move the stuff that
> >   takes long time into bnxt_start(), which is called only when network
> >   via this ethernet controller is requested for by U-Boot commands.  
> 
> So renaming bnxt probe/remove to bnxt start/stop will do, right?

No. The whole idea of adding the new "bnxt" command is wrong, because
the command is *vendor specific*. The ethernet controller should work
out of the box with standard U-Boot commands, i.e. it if I use the
  dhcp
command, it should work, without needing to call the "bnxt" command.

> >
> > Also, you're still doing
> >
> > +       if (env_get("ethaddr"))
> > +               secondary = 1;  
> 
> Why can't we access the env variable from our "bnxt start" method? Is
> there a blacklist of env variables one must not access from a driver?

Because the "ethaddr" variable is the MAC address of the 0-th ethernet
controller on the board, which does not have anything to do with yout
broadcom netXtreme controller, unless your broadcom netXtreme
controller is the zero-th ethernet controller on the board.

For example if I connect you controller to the PCIe slot on Turris
Omnia, where there are 3 ethernet controllers already, and their MAC
addresses are stored in
  ethaddr
  eth1addr
  eth2addr
the MAC address of the netXtreme controller would be stored in variable
  eth3addr

So in your UCLASS_ETH driver, you should only look at
  dev_seq(dev)
ethaddr, by using
  eth_env_get/set_enetaddr_by_index("eth", dev_seq(dev), ...);

Marek