[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20120504.024216.1730395431103337434.davem@davemloft.net>
Date: Fri, 04 May 2012 02:42:16 -0400 (EDT)
From: David Miller <davem@...emloft.net>
To: cmetcalf@...era.com
Cc: arnd@...db.de, linux-kernel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH v4] tilegx network driver: initial support
From: Chris Metcalf <cmetcalf@...era.com>
Date: Thu, 3 May 2012 12:41:56 -0400
> +/* First, "tile_net_init_module()" initializes each network cpu to
> + * handle incoming packets, and initializes all the network devices.
> + *
> + * Then, "ifconfig DEVICE up" calls "tile_net_open()", which will
> + * turn on packet processing, if needed.
> + *
> + * If "ifconfig DEVICE down" is called, it uses "tile_net_stop()" to
> + * stop egress, and possibly turn off packet processing.
> + *
> + * We start out with the ingress IRQ enabled on each CPU. When it
> + * fires, it is automatically disabled, and we call "napi_schedule()".
> + * This will cause "tile_net_poll()" to be called, which will pull
> + * packets from the netio queue, filtering them out, or passing them
> + * to "netif_receive_skb()". If our budget is exhausted, we will
> + * return, knowing we will be called again later. Otherwise, we
> + * reenable the ingress IRQ, and call "napi_complete()".
This is not the place where you document how the generic networking
brings devices up and down, and what driver methods are called during
those actions.
Imagine if every driver writer decided to do this.
> +#define TILE_NET_MAX_COMPS 64
> +
> +
Please get rid of all of these more-than-one empty line sequences.
> +#define ROUND_UP(n, align) (((n) + (align) - 1) & -(align))
This is ALIGN() from linux/kernel.h, please us it.
At this rate I anticipate at least 20 rounds of review, this driver
still needs quite a bit of work.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists