[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACPK8XdLp8Ue0vuGT8ALPDkoFCG-Pb4_fxvDk7kMpm-se_wECg@mail.gmail.com>
Date: Wed, 25 Aug 2021 06:41:16 +0000
From: Joel Stanley <joel@....id.au>
To: "Gabriel L. Somlo" <gsomlo@...il.com>,
Florent Kermarrec <florent@...oy-digital.fr>
Cc: "David S . Miller" <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>,
Rob Herring <robh+dt@...nel.org>,
Karol Gugala <kgugala@...micro.com>,
Mateusz Holenko <mholenko@...micro.com>,
devicetree <devicetree@...r.kernel.org>,
Networking <netdev@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
David Shah <dave@....me>, Stafford Horne <shorne@...il.com>
Subject: Re: [PATCH v2 2/2] net: Add driver for LiteX's LiteEth network interface
On Wed, 25 Aug 2021 at 06:35, Joel Stanley <joel@....id.au> wrote:
>
> On Tue, 24 Aug 2021 at 19:43, Gabriel L. Somlo <gsomlo@...il.com> wrote:
> > > diff --git a/drivers/net/ethernet/litex/Makefile b/drivers/net/ethernet/litex/Makefile
> > > new file mode 100644
> > > index 000000000000..9343b73b8e49
> > > --- /dev/null
> > > +++ b/drivers/net/ethernet/litex/Makefile
> > > +int liteeth_setup_slots(struct liteeth *priv)
> > > +{
> > > + struct device_node *np = priv->dev->of_node;
> > > + int err, depth;
> > > +
> > > + err = of_property_read_u32(np, "rx-fifo-depth", &depth);
> > > + if (err) {
> > > + dev_err(priv->dev, "unable to get rx-fifo-depth\n");
> > > + return err;
> > > + }
> > > + if (depth < LITEETH_BUFFER_SIZE) {
> >
> > If I set depth to be *equal* to LITEETH_BUFFER_SIZE (2048) in DTS,
> > no traffic makes it out of my network interface (linux-on-litex-rocket
> > on an ecpix5 board, see github.com/litex-hub/linux-on-litex-rocket).
> >
> > May I suggest rejecting if (depth / LITEETH_BUFFER_SIZE < 2) instead?
> > When that's enforced, the interface actually works fine for me.
>
> Yes, I was using BUFFER_SIZE as the slot size, which it is not. I'll
> rework it to use the slot size I think.
>
> I spent some time digging through the migen source and I couldn't work
> out where the 1024 length comes from. If anything it should be
> eth_mtu, which is 1530.
>
> Florent, can you clear that up?
Replying to myself, the 0x800 is the slot size. I will fix the maths
so the number of slots is calculated correctly.
Powered by blists - more mailing lists