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.
next prev parent 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).