From: Bartosz Golaszewski <brgl@bgdev.pl>
To: Florian Fainelli <f.fainelli@gmail.com>
Cc: Rob Herring <robh+dt@kernel.org>,
"David S . Miller" <davem@davemloft.net>,
Matthias Brugger <matthias.bgg@gmail.com>,
John Crispin <john@phrozen.org>,
Sean Wang <sean.wang@mediatek.com>,
Mark Lee <Mark-MC.Lee@mediatek.com>,
Jakub Kicinski <kuba@kernel.org>, Arnd Bergmann <arnd@arndb.de>,
Fabien Parent <fparent@baylibre.com>,
Heiner Kallweit <hkallweit1@gmail.com>,
Edwin Peer <edwin.peer@broadcom.com>,
devicetree <devicetree@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
netdev <netdev@vger.kernel.org>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
linux-mediatek@lists.infradead.org,
Stephane Le Provost <stephane.leprovost@mediatek.com>,
Pedro Tsai <pedro.tsai@mediatek.com>,
Andrew Perepech <andrew.perepech@mediatek.com>,
Bartosz Golaszewski <bgolaszewski@baylibre.com>
Subject: Re: [PATCH v2 09/14] net: ethernet: mtk-eth-mac: new driver
Date: Tue, 12 May 2020 08:35:21 +0200 [thread overview]
Message-ID: <CAMRc=MeAMHs3jYh5KpbO5pAqO_cTmc71US_aVAFqRpNBnEYVMg@mail.gmail.com> (raw)
In-Reply-To: <dab80587-a196-e0ab-ae97-f8e5cc4a71d4@gmail.com>
pon., 11 maj 2020 o 21:24 Florian Fainelli <f.fainelli@gmail.com> napisał(a):
>
>
>
> On 5/11/2020 8:07 AM, Bartosz Golaszewski wrote:
> > From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> >
> > This adds the driver for the MediaTek Ethernet MAC used on the MT8* SoC
> > family. For now we only support full-duplex.
> >
> > Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> > ---
>
> [snip]
>
> > +static int mtk_mac_ring_pop_tail(struct mtk_mac_ring *ring,
> > + struct mtk_mac_ring_desc_data *desc_data)
> > +{
> > + struct mtk_mac_ring_desc *desc = &ring->descs[ring->tail];
> > + unsigned int status;
> > +
> > + /* Let the device release the descriptor. */
> > + dma_rmb();
> > + status = desc->status;
> > +
> > + if (!(status & MTK_MAC_DESC_BIT_COWN))
> > + return -1;
> > +
> > + desc_data->len = status & MTK_MAC_DESC_MSK_LEN;
> > + desc_data->flags = status & ~MTK_MAC_DESC_MSK_LEN;
> > + desc_data->dma_addr = desc->data_ptr;
> > + desc_data->skb = ring->skbs[ring->tail];
> > +
> > + desc->data_ptr = 0;
> > + desc->status = MTK_MAC_DESC_BIT_COWN;
> > + if (status & MTK_MAC_DESC_BIT_EOR)
> > + desc->status |= MTK_MAC_DESC_BIT_EOR;
>
> Don't you need a dma_wmb() for the device to observe the new descriptor
> here?
>
HW has released the descriptor (set the COWN bit) and I just clear all
other bits here really. Yeah, I guess it won't hurt to make sure.
> [snip]
>
> > +static void mtk_mac_dma_unmap_tx(struct mtk_mac_priv *priv,
> > + struct mtk_mac_ring_desc_data *desc_data)
> > +{
> > + struct device *dev = mtk_mac_get_dev(priv);
> > +
> > + return dma_unmap_single(dev, desc_data->dma_addr,
> > + desc_data->len, DMA_TO_DEVICE);
>
> If you stored a pointer to the sk_buff you transmitted, then you would
> need an expensive read to the descriptor to determine the address and
> length, and you would also not be at the mercy of the HW putting
> incorrect values there.
>
You mean store the mapped addresses? Yeah I can do that but I'll still
need to read the descriptor memory to verify it was released by HW.
> sp
> > +static void mtk_mac_dma_init(struct mtk_mac_priv *priv)
> > +{
> > + struct mtk_mac_ring_desc *desc;
> > + unsigned int val;
> > + int i;
> > +
> > + priv->descs_base = (struct mtk_mac_ring_desc *)priv->ring_base;
> > +
> > + for (i = 0; i < MTK_MAC_NUM_DESCS_TOTAL; i++) {
> > + desc = &priv->descs_base[i];
> > +
> > + memset(desc, 0, sizeof(*desc));
> > + desc->status = MTK_MAC_DESC_BIT_COWN;
> > + if ((i == MTK_MAC_NUM_TX_DESCS - 1) ||
> > + (i == MTK_MAC_NUM_DESCS_TOTAL - 1))
> > + desc->status |= MTK_MAC_DESC_BIT_EOR;
> > + }
> > +
> > + mtk_mac_ring_init(&priv->tx_ring, priv->descs_base, 0);
> > + mtk_mac_ring_init(&priv->rx_ring,
> > + priv->descs_base + MTK_MAC_NUM_TX_DESCS,
> > + MTK_MAC_NUM_RX_DESCS);
> > +
> > + /* Set DMA pointers. */
> > + val = (unsigned int)priv->dma_addr;
>
> You would probably add a WARN_ON() or something that catches the upper
> 32-bits of the dma_addr being set, see my comment about the DMA mask
> setting.
>
Can it still happen if I check the return value of dma_set_mask_and_coherent()?
> [snip]
>
> > +static void mtk_mac_tx_complete_all(struct mtk_mac_priv *priv)
> > +{
> > + struct net_device *ndev = priv_to_netdev(priv);
> > + struct mtk_mac_ring *ring = &priv->tx_ring;
> > + int ret;
> > +
> > + for (;;) {
> > + mtk_mac_lock(priv);
> > +
> > + if (!mtk_mac_ring_descs_available(ring)) {
> > + mtk_mac_unlock(priv);
> > + break;
> > + }
> > +
> > + ret = mtk_mac_tx_complete_one(priv);
> > + if (ret) {
> > + mtk_mac_unlock(priv);
> > + break;
> > + }
> > +
> > + if (netif_queue_stopped(ndev))
> > + netif_wake_queue(ndev);
> > +
> > + mtk_mac_unlock(priv);
> > + }
>
> Where do you increment the net_device statistics to indicate the bytes
> and packets transmitted?
>
I don't. I use the counters provided by HW for that.
> [snip]
>
> > + mtk_mac_set_mode_rmii(priv);
> > +
> > + dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32));
>
> Your code assumes that DMA addresses are not going to be >= 4GB so you
> should be checking this function's return code and abort here otherwise
> your driver will fail in surprisingly difficult ways to debug.
Sure, thanks.
Bart
next prev parent reply other threads:[~2020-05-12 6:35 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-11 15:07 [PATCH v2 00/14] mediatek: add support for MediaTek Ethernet MAC Bartosz Golaszewski
2020-05-11 15:07 ` [PATCH v2 01/14] dt-bindings: arm: add a binding document for MediaTek PERICFG controller Bartosz Golaszewski
2020-05-19 18:28 ` Rob Herring
2020-05-20 9:19 ` Bartosz Golaszewski
2020-05-11 15:07 ` [PATCH v2 02/14] dt-bindings: net: add a binding document for MediaTek Ethernet MAC Bartosz Golaszewski
2020-05-11 15:07 ` [PATCH v2 03/14] net: ethernet: mediatek: rename Kconfig prompt Bartosz Golaszewski
2020-05-11 15:07 ` [PATCH v2 04/14] net: ethernet: mediatek: remove unnecessary spaces from Makefile Bartosz Golaszewski
2020-05-11 15:07 ` [PATCH v2 05/14] net: core: provide priv_to_netdev() Bartosz Golaszewski
2020-05-11 16:39 ` Andrew Lunn
2020-05-11 20:41 ` David Miller
2020-05-12 6:04 ` Bartosz Golaszewski
2020-05-12 19:30 ` David Miller
2020-05-11 15:07 ` [PATCH v2 06/14] net: move devres helpers into a separate source file Bartosz Golaszewski
2020-05-11 15:07 ` [PATCH v2 07/14] net: devres: define a separate devres structure for devm_alloc_etherdev() Bartosz Golaszewski
2020-05-11 15:07 ` [PATCH v2 08/14] net: devres: provide devm_register_netdev() Bartosz Golaszewski
2020-05-11 15:07 ` [PATCH v2 09/14] net: ethernet: mtk-eth-mac: new driver Bartosz Golaszewski
2020-05-11 19:24 ` Florian Fainelli
2020-05-12 6:35 ` Bartosz Golaszewski [this message]
2020-05-11 15:07 ` [PATCH v2 10/14] ARM64: dts: mediatek: add pericfg syscon to mt8516.dtsi Bartosz Golaszewski
2020-05-11 15:07 ` [PATCH v2 11/14] ARM64: dts: mediatek: add the ethernet node " Bartosz Golaszewski
2020-05-11 15:07 ` [PATCH v2 12/14] ARM64: dts: mediatek: add an alias for ethernet0 for pumpkin boards Bartosz Golaszewski
2020-05-11 15:07 ` [PATCH v2 13/14] ARM64: dts: mediatek: add ethernet pins " Bartosz Golaszewski
2020-05-11 15:07 ` [PATCH v2 14/14] ARM64: dts: mediatek: enable ethernet on " Bartosz Golaszewski
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='CAMRc=MeAMHs3jYh5KpbO5pAqO_cTmc71US_aVAFqRpNBnEYVMg@mail.gmail.com' \
--to=brgl@bgdev.pl \
--cc=Mark-MC.Lee@mediatek.com \
--cc=andrew.perepech@mediatek.com \
--cc=arnd@arndb.de \
--cc=bgolaszewski@baylibre.com \
--cc=davem@davemloft.net \
--cc=devicetree@vger.kernel.org \
--cc=edwin.peer@broadcom.com \
--cc=f.fainelli@gmail.com \
--cc=fparent@baylibre.com \
--cc=hkallweit1@gmail.com \
--cc=john@phrozen.org \
--cc=kuba@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=matthias.bgg@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=pedro.tsai@mediatek.com \
--cc=robh+dt@kernel.org \
--cc=sean.wang@mediatek.com \
--cc=stephane.leprovost@mediatek.com \
/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;
as well as URLs for NNTP newsgroup(s).