From: "Bryan O'Sullivan" <bos@pathscale.com>
To: Greg KH <greg@kroah.com>
Cc: linux-kernel@vger.kernel.org, openib-general@openib.org
Subject: Re: [PATCH 8 of 20] ipath - core driver, part 1 of 4
Date: Fri, 30 Dec 2005 15:47:07 -0800 [thread overview]
Message-ID: <1135986427.13318.79.camel@serpentine.pathscale.com> (raw)
In-Reply-To: <20051230083928.GD7438@kroah.com>
On Fri, 2005-12-30 at 00:39 -0800, Greg KH wrote:
> > +void ipath_chip_done(void)
> > +{
> > +}
> > +
> > +void ipath_chip_cleanup(struct ipath_devdata * dd)
> > +{
> > +}
>
> What are these two empty functions for?
They're just as dead as they look.
> > +static ssize_t show_status_str(struct device *dev,
> how big can this "status string" be?
Just a few dozen bytes.
> If it's even getting close to
> PAGE_SIZE, this doesn't need to be a sysfs attribute, but you should
> break it up into its individual pieces.
Do you think that's still warranted, given this?
> > +static ssize_t show_unit(struct device *dev,
> Don't you mean -ENODEV?
Yes, thanks.
> > + snprintf(buf, PAGE_SIZE, "%u\n", dd->ipath_unit);
> > + return strlen(buf);
>
> return the snprintf() call instead of calling strlen() all the time
> please.
OK.
> > +const struct pci_device_id infinipath_pci_tbl[] = {
> > + {
> > + PCI_VENDOR_ID_PATHSCALE, PCI_DEVICE_ID_PATHSCALE_INFINIPATH_HT,
> > + PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
>
> PCI_DEVICE() instead?
OK.
> > + {0,}
>
> {},
> is all that is needed here.
OK.
> > + .driver.owner = THIS_MODULE,
>
> This line is not needed, you can remove it.
OK.
> {} not needed here.
OK.
> > +#if defined (pgprot_writecombine) && defined(_PAGE_MA_WC)
> > + printk("Remapping pages WC\n");
>
> No KERN_ level?
That should just become a debug statement.
> > + /*
> > + * set these up before registering the interrupt handler, just
> > + * in case
> > + */
> > + devdata[dev].pcidev = pdev;
> > + pci_set_drvdata(pdev, &(devdata[dev]));
>
> It's not a "just in case" type thing, you have to do this before you
> register that interrupt handler, as you can be instantly called here.
OK, I'll remove the misleading comment.
> Are you sure everything else is set up properly here before calling that
> function?
I believe so. I'll double check.
> > + device_create_file(&(pdev->dev), &dev_attr_status);
> > + device_create_file(&(pdev->dev), &dev_attr_status_str);
> > + device_create_file(&(pdev->dev), &dev_attr_lid);
> > + device_create_file(&(pdev->dev), &dev_attr_mlid);
> > + device_create_file(&(pdev->dev), &dev_attr_guid);
> > + device_create_file(&(pdev->dev), &dev_attr_nguid);
> > + device_create_file(&(pdev->dev), &dev_attr_serial);
> > + device_create_file(&(pdev->dev), &dev_attr_unit);
>
> Why not use an attribute array? Makes for proper error handling if one
> of those calls does not work...
OK, thanks.
> > + /*
> > + * We used to cleanup here, with pci_release_regions, etc. but that
> > + * can cause other problems if we want to run diags, etc., so instead
> > + * defer that until driver unload.
> > + */
>
> So memory leaks are acceptable?
That clearly needs a bit of attention.
> > +fail: /* after we've done at least some of the pci setup */
> > + if (ret == -EPERM) /* disabled device, don't want module load error;
> > + * just want to carry status through to this point */
> > + ret = 0;
>
> Module load error does not happen no matter what kind of return value
> you send back from this function. So the comment is wrong, and the fact
> that you failed initializing the device is also wrong, please don't do
> this.
OK.
Thanks for the extensive comments,
<b
next prev parent reply other threads:[~2005-12-30 23:47 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-12-29 0:31 [PATCH 0 of 20] [RFC] ipath - PathScale InfiniPath driver Bryan O'Sullivan
2005-12-29 0:31 ` [PATCH 1 of 20] Introduce __memcpy_toio32 Bryan O'Sullivan
2005-12-29 0:31 ` [PATCH 2 of 20] memcpy32 for x86_64 Bryan O'Sullivan
2005-12-29 0:31 ` [PATCH 3 of 20] Add memcpy_toio32 to each arch Bryan O'Sullivan
2005-12-29 0:31 ` [PATCH 4 of 20] Define BITS_PER_BYTE Bryan O'Sullivan
2005-12-29 0:31 ` [PATCH 5 of 20] ipath - driver core header files Bryan O'Sullivan
2005-12-29 8:18 ` Pekka Enberg
2005-12-29 14:15 ` Bryan O'Sullivan
2005-12-29 0:31 ` [PATCH 6 of 20] ipath - driver debugging headers Bryan O'Sullivan
2005-12-29 8:22 ` Pekka Enberg
2005-12-29 0:31 ` [PATCH 7 of 20] ipath - MMIO copy routines Bryan O'Sullivan
2005-12-29 0:31 ` [PATCH 8 of 20] ipath - core driver, part 1 of 4 Bryan O'Sullivan
2005-12-30 8:39 ` Greg KH
2005-12-30 23:47 ` Bryan O'Sullivan [this message]
2005-12-31 0:12 ` Greg KH
2005-12-29 0:31 ` [PATCH 9 of 20] ipath - core driver, part 2 " Bryan O'Sullivan
2005-12-29 0:31 ` [PATCH 10 of 20] ipath - core driver, part 3 " Bryan O'Sullivan
2005-12-30 18:46 ` Linus Torvalds
2005-12-30 23:50 ` Bryan O'Sullivan
2005-12-31 8:36 ` Arjan van de Ven
2005-12-29 0:31 ` [PATCH 11 of 20] ipath - core driver, part 4 " Bryan O'Sullivan
2005-12-29 2:19 ` [openib-general] " Roland Dreier
2005-12-29 14:21 ` Bryan O'Sullivan
2005-12-30 8:12 ` Greg KH
2005-12-30 23:17 ` Bryan O'Sullivan
2005-12-31 0:08 ` Greg KH
2005-12-29 0:31 ` [PATCH 12 of 20] ipath - misc driver support code Bryan O'Sullivan
2005-12-30 8:25 ` Greg KH
2005-12-30 23:10 ` Bryan O'Sullivan
2005-12-31 0:13 ` Greg KH
2005-12-30 18:15 ` Arjan van de Ven
2005-12-29 0:31 ` [PATCH 13 of 20] ipath - routines used by upper layer driver code Bryan O'Sullivan
2005-12-29 0:31 ` [PATCH 14 of 20] ipath - infiniband verbs header Bryan O'Sullivan
2005-12-29 8:21 ` Pekka Enberg
2005-12-29 14:22 ` Bryan O'Sullivan
2005-12-29 0:31 ` [PATCH 15 of 20] ipath - infiniband verbs support, part 1 of 3 Bryan O'Sullivan
2005-12-29 0:31 ` [PATCH 16 of 20] path - infiniband verbs support, part 2 " Bryan O'Sullivan
2005-12-29 0:31 ` [PATCH 17 of 20] ipath - infiniband verbs support, part 3 " Bryan O'Sullivan
2005-12-29 19:24 ` Pekka Enberg
2005-12-30 3:19 ` Bryan O'Sullivan
2005-12-29 0:31 ` [PATCH 18 of 20] ipath - infiniband management datagram support Bryan O'Sullivan
2005-12-29 0:31 ` [PATCH 19 of 20] ipath - kbuild infrastructure Bryan O'Sullivan
2005-12-29 0:31 ` [PATCH 20 of 20] ipath - integrate driver into infiniband " Bryan O'Sullivan
2005-12-29 19:01 ` [PATCH 0 of 20] [RFC] ipath - PathScale InfiniPath driver Horst von Brand
2005-12-29 19:26 ` Lee Revell
2005-12-31 5:36 ` Jan Engelhardt
2006-01-02 16:05 ` Horst von Brand
2006-01-02 16:22 ` Christoph Hellwig
2005-12-30 3:17 ` Bryan O'Sullivan
2005-12-30 8:00 ` Greg KH
2005-12-30 23:11 ` Bryan O'Sullivan
2005-12-31 0:10 ` Greg KH
2005-12-31 1:40 ` Bryan O'Sullivan
2006-01-02 20:35 ` Eric W. Biederman
2006-01-02 22:22 ` Bryan O'Sullivan
2006-01-04 21:26 ` Roland Dreier
2006-01-05 15:28 ` Bryan O'Sullivan
2006-01-03 17:27 ` Greg KH
2006-01-03 20:54 ` Bryan O'Sullivan
2006-01-03 20:57 ` Arjan van de Ven
2006-01-03 21:24 ` Bryan O'Sullivan
2006-01-03 21:26 ` Arjan van de Ven
2006-01-04 3:33 ` Bryan O'Sullivan
2006-01-04 21:28 ` [openib-general] " Roland Dreier
2006-01-05 15:31 ` Bryan O'Sullivan
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=1135986427.13318.79.camel@serpentine.pathscale.com \
--to=bos@pathscale.com \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=openib-general@openib.org \
/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.