All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ben Hutchings <bhutchings@solarflare.com>
To: Po-Yu Chuang <ratbert.chuang@gmail.com>
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	Po-Yu Chuang <ratbert@faraday-tech.com>
Subject: Re: [PATCH] net: add Faraday FTMAC100 10/100 Ethernet driver
Date: Thu, 13 Jan 2011 14:03:07 +0000	[thread overview]
Message-ID: <1294927387.3044.76.camel@localhost> (raw)
In-Reply-To: <1294919372-1904-1-git-send-email-ratbert.chuang@gmail.com>

On Thu, 2011-01-13 at 19:49 +0800, Po-Yu Chuang wrote:
> From: Po-Yu Chuang <ratbert@faraday-tech.com>
> 
> FTMAC100 Ethernet Media Access Controller supports 10/100 Mbps and
> MII.  This driver has been working on some ARM/NDS32 SoC including
> Faraday A320 and Andes AG101.
[...]
> diff --git a/drivers/net/ftmac100.c b/drivers/net/ftmac100.c
> new file mode 100644
> index 0000000..97d1f8d
> --- /dev/null
> +++ b/drivers/net/ftmac100.c
[...]
> +#include "ftmac100.h"
> +
> +#define USE_NAPI

All new network drivers should use NAPI only, so please remove the
definition of USE_NAPI and change the conditional code to use NAPI
always.

[...]
> +	struct napi_struct	napi;
> +#endif
> +
> +	struct net_device_stats	stats;

There is a net_device_stats structure in the net_device structure; you
should normally use that instead of adding another one.

[...]
> +static int ftmac100_reset(struct ftmac100 *priv)
> +{
> +	struct device *dev = &priv->netdev->dev;
> +	unsigned long flags;
> +	int i;
> +
> +	/* NOTE: reset clears all registers */
> +
> +	spin_lock_irqsave(&priv->hw_lock, flags);
> +	iowrite32(FTMAC100_MACCR_SW_RST, priv->base + FTMAC100_OFFSET_MACCR);
> +	spin_unlock_irqrestore(&priv->hw_lock, flags);
> +
> +	for (i = 0; i < 5; i++) {
> +		int maccr;
> +
> +		spin_lock_irqsave(&priv->hw_lock, flags);
> +		maccr = ioread32(priv->base + FTMAC100_OFFSET_MACCR);
> +		spin_unlock_irqrestore(&priv->hw_lock, flags);
> +		if (!(maccr & FTMAC100_MACCR_SW_RST)) {
> +			/*
> +			 * FTMAC100_MACCR_SW_RST cleared does not indicate
> +			 * that hardware reset completed (what the f*ck).
> +			 * We still need to wait for a while.
> +			 */
> +			usleep_range(500, 1000);

Sleeping here means this must be running in process context.  But you
used spin_lock_irqsave() above which implies you're not sure what the
context is.  One of these must be wrong.

I wonder whether hw_lock is even needed; you seem to acquire and release
it around each PIO (read or write).  This should be unnecessary since
each PIO is atomic.

[...]
> +static int ftmac100_rx_packet(struct ftmac100 *priv, int *processed)
> +{
> +	struct net_device *netdev = priv->netdev;
> +	struct device *dev = &netdev->dev;
> +	unsigned long flags;
> +	struct ftmac100_rxdes *rxdes;
> +	struct sk_buff *skb;
> +	int length;
> +	int copied = 0;
> +	int done = 0;
> +
> +	spin_lock_irqsave(&priv->rx_lock, flags);
> +	rxdes = ftmac100_rx_locate_first_segment(priv);
> +	spin_unlock_irqrestore(&priv->rx_lock, flags);
> +	if (!rxdes)
> +		return 0;
> +
> +	if (unlikely(ftmac100_rx_packet_error(priv, rxdes))) {
> +		spin_lock_irqsave(&priv->rx_lock, flags);
> +		ftmac100_rx_drop_packet(priv);
> +		spin_unlock_irqrestore(&priv->rx_lock, flags);

I think you can also get rid of rx_lock; it's only used in the RX data
path which is already serialised by NAPI.

[...]
> +	netif_rx(skb);
> +#endif
> +
> +	netdev->last_rx = jiffies;

Don't set last_rx; the networking core takes care of it now.

> +	priv->stats.rx_packets++;
> +	priv->stats.rx_bytes += skb->len;

This should be done earlier, so that these stats include packets that
are dropped for any reason.

[...]
> +static int ftmac100_xmit(struct ftmac100 *priv, struct sk_buff *skb,
> +		dma_addr_t map)
> +{
[...]
> +	ftmac100_txdma_start_polling(priv);
> +	spin_unlock_irqrestore(&priv->hw_lock, flags);
> +	netdev->trans_start = jiffies;

Don't set trans_start; the networking core takes care of it now.

[...]
> +static int ftmac100_alloc_buffers(struct ftmac100 *priv)
> +{
> +	int i;
> +
> +	priv->descs = dma_alloc_coherent(priv->dev,
> +		sizeof(struct ftmac100_descs), &priv->descs_dma_addr,
> +		GFP_KERNEL | GFP_DMA);

On x86, GFP_DMA means the memory must be within the ISA DMA range
(< 16 MB).  I don't know quite what it means on ARM but it may not be
what you want.

[...]
> +/******************************************************************************
> + * interrupt handler
> + *****************************************************************************/
> +static irqreturn_t ftmac100_interrupt(int irq, void *dev_id)
> +{
> +	struct net_device *netdev = dev_id;
> +	struct device *dev = &netdev->dev;
> +	struct ftmac100 *priv = netdev_priv(netdev);
> +	unsigned long flags;
> +	unsigned int status;
> +	unsigned int imr;
> +
> +	spin_lock_irqsave(&priv->hw_lock, flags);
> +	status = ioread32(priv->base + FTMAC100_OFFSET_ISR);
> +	imr = ioread32(priv->base + FTMAC100_OFFSET_IMR);
> +	spin_unlock_irqrestore(&priv->hw_lock, flags);
> +
> +	status &= imr;
> +	if (status & (FTMAC100_INT_RPKT_FINISH | FTMAC100_INT_NORXBUF)) {
> +		/*
> +		 * FTMAC100_INT_RPKT_FINISH:
> +		 *	RX DMA has received packets into RX buffer successfully
> +		 *
> +		 * FTMAC100_INT_NORXBUF:
> +		 *	RX buffer unavailable
> +		 */
> +#ifdef USE_NAPI
> +		/* Disable interrupts for polling */
> +		ftmac100_disable_rxint(priv);
> +
> +		napi_schedule(&priv->napi);
> +#else
> +		int rx = 0;
> +
> +		while (ftmac100_rx_packet(priv, &rx))
> +			;
> +#endif
> +	}
> +
> +	if (status & FTMAC100_INT_NORXBUF) {
> +		/* RX buffer unavailable */
> +		if (printk_ratelimit())
> +			dev_info(dev, "INT_NORXBUF\n");
> +
> +		priv->stats.rx_over_errors++;
> +	}
> +
> +	if (status & (FTMAC100_INT_XPKT_OK | FTMAC100_INT_XPKT_LOST)) {
> +		/*
> +		 * FTMAC100_INT_XPKT_OK:
> +		 *	 packet transmitted to ethernet successfully
> +		 *
> +		 * FTMAC100_INT_XPKT_LOST:
> +		 *	packet transmitted to ethernet lost due to late
> +		 *	collision or excessive collision
> +		 */
> +		ftmac100_tx_complete(priv);
> +	}

TX completions should also be handled through NAPI if possible.

[...]
> +static int ftmac100_open(struct net_device *netdev)
> +{
> +	struct device *dev = &netdev->dev;
> +	struct ftmac100 *priv = netdev_priv(netdev);
> +	int err;
> +
> +	err = ftmac100_alloc_buffers(priv);
> +	if (err) {
> +		dev_err(dev, "failed to allocate buffers\n");
> +		goto err_alloc;
> +	}
> +
> +	err = request_irq(priv->irq, ftmac100_interrupt, 0, netdev->name,
> +		netdev);
> +	if (err) {
> +		dev_err(dev, "failed to request irq %d\n", priv->irq);
> +		goto err_irq;
> +	}
> +
> +	priv->rx_pointer = 0;
> +	priv->tx_clean_pointer = 0;
> +	priv->tx_pointer = 0;
> +	spin_lock_init(&priv->hw_lock);
> +	spin_lock_init(&priv->rx_lock);
> +	spin_lock_init(&priv->tx_lock);

These locks should be initialised in your probe function.

[...]
> +/******************************************************************************
> + * struct platform_driver functions
> + *****************************************************************************/
> +static int ftmac100_remove(struct platform_device *pdev)
> +{
> +	struct net_device *netdev;
> +	struct ftmac100 *priv;
> +
> +	netdev = platform_get_drvdata(pdev);
> +	if (netdev == NULL)
> +		return 0;
> +
> +	platform_set_drvdata(pdev, NULL);
> +
> +	priv = netdev_priv(netdev);
> +
> +	unregister_netdev(netdev);
[...]

There should be a netif_napi_del() before this.

A general comment: please use netdev_err(), netdev_info() etc. for
logging.  This ensures that both the platform device address and the
network device name appears in the log messages.

Ben.

-- 
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.


  reply	other threads:[~2011-01-13 14:03 UTC|newest]

Thread overview: 74+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-13 11:49 [PATCH] net: add Faraday FTMAC100 10/100 Ethernet driver Po-Yu Chuang
2011-01-13 14:03 ` Ben Hutchings [this message]
2011-01-14  5:37   ` Po-Yu Chuang
2011-01-13 14:22 ` Eric Dumazet
2011-01-13 16:29   ` Andres Salomon
2011-01-14  6:44     ` Po-Yu Chuang
2011-01-14  6:56   ` Po-Yu Chuang
2011-01-13 15:39 ` Joe Perches
2011-01-14  6:35   ` Po-Yu Chuang
     [not found] ` <1294959948.4114.189.camel@Joe-Laptop>
2011-01-14  6:49   ` Po-Yu Chuang
2011-01-17  9:21 ` [PATCH v2] " Po-Yu Chuang
2011-01-17 17:19   ` Joe Perches
2011-01-19  9:40     ` Po-Yu Chuang
2011-01-19 12:46       ` Ben Hutchings
2011-01-19 16:41       ` Joe Perches
2011-01-20  5:30         ` Po-Yu Chuang
2011-01-20  8:46           ` Joe Perches
2011-01-17 17:29   ` Eric Dumazet
2011-01-17 18:58     ` Ben Hutchings
2011-01-17 20:39       ` Eric Dumazet
2011-01-17 18:21   ` Eric Dumazet
2011-01-18  3:08     ` Po-Yu Chuang
2011-01-19  9:20     ` Po-Yu Chuang
2011-01-20 15:30   ` [PATCH v3] " Po-Yu Chuang
2011-01-20 15:35     ` Eric Dumazet
2011-01-20 15:43       ` Po-Yu Chuang
2011-01-20 15:41     ` Eric Dumazet
2011-01-20 15:54       ` Po-Yu Chuang
2011-01-20 17:56     ` Joe Perches
2011-01-21  3:35       ` Po-Yu Chuang
2011-01-20 19:00     ` Joe Perches
2011-01-21  5:03       ` Po-Yu Chuang
     [not found]         ` <1295592411.6795.10.camel@Joe-Laptop>
2011-01-21  7:06           ` Po-Yu Chuang
2011-01-20 19:01     ` Michał Mirosław
2011-01-21  3:37       ` Po-Yu Chuang
2011-01-21  7:55     ` [PATCH v4] " Po-Yu Chuang
2011-01-21  9:08       ` Eric Dumazet
2011-01-24  8:07         ` Po-Yu Chuang
2011-01-21 12:26       ` Michał Mirosław
2011-01-24  8:26         ` Po-Yu Chuang
2011-01-24 20:22           ` Michał Mirosław
2011-01-25  2:46             ` Po-Yu Chuang
2011-02-01  3:56               ` Po-Yu Chuang
2011-02-01  4:35                 ` David Miller
2011-02-24  7:27                   ` Po-Yu Chuang
2011-02-24  7:51                     ` David Miller
2011-02-24  8:07                       ` Po-Yu Chuang
2011-02-24  8:22                         ` Eric Dumazet
2011-02-24  9:29                           ` [PATCH ref0] " Po-Yu Chuang
2011-02-24 17:39                             ` Eric Dumazet
2011-02-24 17:48                               ` Eric Dumazet
2011-02-25  2:32                                 ` Po-Yu Chuang
2011-02-25  9:45                                   ` Po-Yu Chuang
2011-02-25 10:52                                     ` Eric Dumazet
2011-02-25 18:34                                       ` David Miller
2011-02-25 18:45                                         ` Eric Dumazet
2011-02-25 18:47                                           ` Eric Dumazet
2011-03-01  5:45                                             ` Po-Yu Chuang
2011-03-01  5:53                                               ` Eric Dumazet
2011-02-25  9:57                             ` [PATCH v6] " Po-Yu Chuang
2011-02-25 11:40                               ` Eric Dumazet
2011-03-01  5:20                                 ` Po-Yu Chuang
2011-03-01  5:26                                   ` Eric Dumazet
2011-03-01  5:45                                   ` Eric Dumazet
2011-03-01  5:51                                     ` Po-Yu Chuang
2011-03-01  5:54                                       ` Eric Dumazet
2011-03-01  5:59                                       ` Eric Dumazet
2011-03-01  6:48                               ` [PATCH] " Po-Yu Chuang
2011-03-01  7:27                                 ` Eric Dumazet
2011-03-03 20:19                                   ` David Miller
2011-02-24 18:43                         ` [PATCH v4] " David Miller
2011-01-24 12:39       ` [PATCH v5] " Po-Yu Chuang
2011-01-24 15:07         ` Eric Dumazet
2011-01-25  2:46           ` Po-Yu Chuang

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=1294927387.3044.76.camel@localhost \
    --to=bhutchings@solarflare.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=ratbert.chuang@gmail.com \
    --cc=ratbert@faraday-tech.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 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.