From: "Marek Behún" <kabel@kernel.org>
To: Roman Bacik <roman.bacik@broadcom.com>
Cc: Simon Glass <sjg@chromium.org>,
U-Boot Mailing List <u-boot@lists.denx.de>,
Bharat Gooty <bharat.gooty@broadcom.com>,
Aswath Govindraju <a-govindraju@ti.com>,
Bin Meng <bmeng.cn@gmail.com>,
Franck LENORMAND <franck.lenormand@nxp.com>,
Heinrich Schuchardt <xypron.glpk@gmx.de>,
Kory Maincent <kory.maincent@bootlin.com>,
Michal Simek <michal.simek@xilinx.com>,
Patrick Delaunay <patrick.delaunay@foss.st.com>,
Peng Fan <peng.fan@nxp.com>,
Priyanka Jain <priyanka.jain@nxp.com>,
Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com>,
Sean Anderson <sean.anderson@seco.com>
Subject: Re: [PATCH v3 2/2] cmd: brcm: netXtreme commands
Date: Tue, 26 Oct 2021 18:52:06 +0200 [thread overview]
Message-ID: <20211026185206.3ba0709f@thinkpad> (raw)
In-Reply-To: <CAGQAs7zbUZBi1G4ruLk5y2-qTKjrdjEwUHyVP9gs7eSE4nV1Gw@mail.gmail.com>
On Tue, 26 Oct 2021 09:40:44 -0700
Roman Bacik <roman.bacik@broadcom.com> wrote:
> On Tue, Oct 26, 2021 at 9:02 AM Roman Bacik <roman.bacik@broadcom.com> wrote:
> >
> > On Tue, Oct 26, 2021 at 8:55 AM Marek Behún <kabel@kernel.org> wrote:
> > >
> > > On Tue, 26 Oct 2021 08:14:28 -0700
> > > Roman Bacik <roman.bacik@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
next prev parent reply other threads:[~2021-10-26 16:52 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-25 23:44 [PATCH v3 1/2] net: brcm: netXtreme driver Roman Bacik
2021-10-25 23:44 ` [PATCH v3 2/2] cmd: brcm: netXtreme commands Roman Bacik
2021-10-26 13:17 ` Marek Behún
2021-10-26 15:14 ` Roman Bacik
2021-10-26 15:55 ` Marek Behún
2021-10-26 16:02 ` Roman Bacik
2021-10-26 16:40 ` Roman Bacik
2021-10-26 16:52 ` Marek Behún [this message]
2021-10-26 16:59 ` Roman Bacik
2021-10-26 16:49 ` Marek Behún
2021-10-27 15:05 ` Roman Bacik
2021-10-27 15:41 ` Simon Glass
2021-10-27 16:05 ` Roman Bacik
2021-10-27 16:35 ` Marek Behún
2021-10-27 16:47 ` Roman Bacik
2021-10-27 17:02 ` Roman Bacik
2021-10-27 17:39 ` Marek Behún
2021-10-27 17:58 ` Roman Bacik
2021-10-27 18:02 ` Marek Behún
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20211026185206.3ba0709f@thinkpad \
--to=kabel@kernel.org \
--cc=a-govindraju@ti.com \
--cc=bharat.gooty@broadcom.com \
--cc=bmeng.cn@gmail.com \
--cc=franck.lenormand@nxp.com \
--cc=kory.maincent@bootlin.com \
--cc=michal.simek@xilinx.com \
--cc=patrick.delaunay@foss.st.com \
--cc=peng.fan@nxp.com \
--cc=priyanka.jain@nxp.com \
--cc=rayagonda.kokatanur@broadcom.com \
--cc=roman.bacik@broadcom.com \
--cc=sean.anderson@seco.com \
--cc=sjg@chromium.org \
--cc=u-boot@lists.denx.de \
--cc=xypron.glpk@gmx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox