devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).