On Tue, 26 Oct 2021 09:40:44 -0700
Roman Bacik <roman.ba...@broadcom.com> wrote:
> On Tue, Oct 26, 2021 at 9:02 AM Roman Bacik <roman.ba...@broadcom.com> wrote:
> >
> > On Tue, Oct 26, 2021 at 8:55 AM Marek Behún <ka...@kernel.org> wrote:
> > >
> > > On Tue, 26 Oct 2021 08:14:28 -0700
> > > Roman Bacik <roman.ba...@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?
> >
> > >
> > > 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?
>
> Marek,
>
> Sometimes we can have two ethernet devices. One is 10/100/1000M rgmii and
> another is chip internal 10/100G bnxt. If rgmii is there as eth0, we
> are incrementing eth number for bnxt:
>
> if (env_get("ethaddr"))
> secondary = 1;
> eth_env_get_enetaddr_by_index("eth",bp->cardnum+secondary,bp->mac_set);
>
> This way the driver can find that rmii has already taken eth0 so it
> will use eth1 instead. Do you have a suggestion to work around this?
> Thanks,
I just replied to your first reply:
Every ethernet controller should use a specific ethNaddr, where
N = dev_seq(dev) of that controller (and if N=0, it is omitted
entirely).
So no magical things such as
bp->cardnum+secondary
instead you use dev_seq(dev), which gives you the correct number, i.e.
for N-th UCLASS_ETH device bound it return the number N.
Marek
