netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Roland Dreier <rdreier@cisco.com>
To: Scott Feldman <scofeldm@cisco.com>
Cc: netdev@vger.kernel.org
Subject: Re: [RFC][PATCH 2/3] enic: add main file with module infrastructure, etc
Date: Mon, 25 Aug 2008 16:06:39 -0700	[thread overview]
Message-ID: <adaej4clmo0.fsf@cisco.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0808251123240.3972@palito_client100.nuovasystems.com> (Scott Feldman's message of "Mon, 25 Aug 2008 11:27:02 -0700 (PDT)")

General comment -- probably a good idea to run everything through
checkpatch.pl (catches a few trivial whitespace problems) and also
sparse with endianness checking (build with "make C=2
CF=-D__CHECK_ENDIAN__ SUBDIRS=drivers/net/enic") and look at all the
warnings you get.

 > +	{ PCI_DEVICE(PCI_VENDOR_ID_CISCO, PCI_DEVICE_ID_CISCO_ENIC) },

PCI_VDEVICE() makes this look slightly nicer.

 > +	netdev->features |= NETIF_F_LLTX;

LLTX is kind of deprecated for new drivers.  Would be nice to avoid this.

 > +	case VNIC_DEV_INTR_MODE_INTX:
 > +	case VNIC_DEV_INTR_MODE_MSI:
 > +		free_irq(enic->pdev->irq, netdev);
 > +		break;
 > +	case VNIC_DEV_INTR_MODE_MSIX:

Do you really need both MSI and MSI-X support?  Systems where MSI works
but MSI-X doesn't a pretty rare, and having both leads to a more complex
driver with one code path (MSI) that rarely gets tested.  I removed MSI
support from drivers/infiniband/hw/mthca at the beginning of the year
afer deprecating it for a while, and I've never heard anyone even
mention it, let alone complain.

 > +	mod_timer(&enic->notify_timer, jiffies + ENIC_NOTIFY_TIMER_PERIOD);

Would probably be nice to use round_jiffies() or a deferrable timer here
to avoid unnecessary wakeups.

 > +	pba = vnic_intr_legacy_pba(enic->legacy_pba);

enic->legacy_pba is just u32 * but vnic_intr_legacy_pba expects an
__iomem pointer.

 > +	if (skb->protocol == ntohs(ETH_P_IP)) {
 > +	} else if (skb->protocol == ntohs(ETH_P_IPV6)) {

trivial but you're converting from host to network order, so you should
use htons() not ntohs().

 > +	unsigned int vlan_tag = 0;
 > +	int vlan_tag_insert = 0;
 > +
 > +	if (enic->vlan_group && vlan_tx_tag_present(skb)) {
 > +		/* VLAN tag from trunking driver */
 > +		vlan_tag_insert = 1;
 > +		vlan_tag = cpu_to_le16(vlan_tx_tag_get(skb));
 > +	}

vlan_tag is declared as a plain int but you assign the result of
cpu_to_le16() to it.  This leads to a sparse warning if you build with
endianness checking on.

 > +	/* check if ip header and tcp header are complete */
 > +	if (iph->tot_len < ip_len + tcp_hdrlen(skb))
 > +		return -1;

Heh, looks like you copied and pasted a bad example from another driver
before I fixed it (in 3ff2cd23, "ehea: Access iph->tot_len with correct
endianness," where I was prescient enough in the changelog to say "this
... avoids having a bad example in the tree.").  iph->tot_len is stored
in network order so you should use ntohs(iph->tot_len).

 > +	u16 q_number, completed_index, bytes_written, vlan, checksum, len;
 > +	len = le16_to_cpu(bytes_written);
 > +			skb->csum = htons(checksum);
 > +					le16_to_cpu(vlan), cq_desc);

bytes_written is declared as u16 but then byte-swapped.  Creates a
sparse warning.  Similar for checksum, vlan.

 > +void enic_del_station_addr(struct enic *enic)
 > +{
 > +	vnic_dev_del_addr(enic->vdev, enic->mac_addr);
 > +}
 > 
 > +int enic_set_rss_key(struct enic *enic, dma_addr_t key_pa, u64 len)
 > +{
 > +	u64 a0 = (u64)key_pa, a1 = len;
 > +	int wait = 1000;
 > +
 > +	return vnic_dev_cmd(enic->vdev, CMD_RSS_KEY, &a0, &a1, wait);
 > +}
 > +
 > +int enic_set_rss_cpu(struct enic *enic, dma_addr_t cpu_pa, u64 len)
 > +{
 > +	u64 a0 = (u64)cpu_pa, a1 = len;
 > +	int wait = 1000;
 > +
 > +	return vnic_dev_cmd(enic->vdev, CMD_RSS_CPU, &a0, &a1, wait);
 > +}

I can't find anywhere any of these functions are actually used.


  reply	other threads:[~2008-08-25 23:06 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-25 18:27 [RFC][PATCH 2/3] enic: add main file with module infrastructure, etc Scott Feldman
2008-08-25 23:06 ` Roland Dreier [this message]
2008-08-27  4:03   ` Scott Feldman
2008-08-27  4:15     ` Roland Dreier

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=adaej4clmo0.fsf@cisco.com \
    --to=rdreier@cisco.com \
    --cc=netdev@vger.kernel.org \
    --cc=scofeldm@cisco.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).