On Tue, 26 Oct 2021 09:02:54 -0700 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? 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