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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.