public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Sudeep Dutt <sudeep.dutt@intel.com>
Cc: Arnd Bergmann <arnd@arndb.de>,
	Rusty Russell <rusty@rustcorp.com.au>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Rob Landley <rob@landley.net>,
	linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org,
	linux-doc@vger.kernel.org, AsiasHeasias@redhat.com,
	Nikhil Rao <nikhil.rao@intel.com>,
	Ashutosh Dixit <ashutosh.dixit@intel.com>,
	Caz Yokoyama <Caz.Yokoyama@intel.com>,
	Dasaratharaman Chandramouli 
	<dasaratharaman.chandramouli@intel.com>,
	Harshavardhan R Kharche <harshavardhan.r.kharche@intel.com>,
	"Yaozu (Eddie) Dong" <eddie.dong@intel.com>,
	Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
Subject: Re: [PATCH v2 1/7] Intel MIC Host Driver for X100 family.
Date: Mon, 12 Aug 2013 16:06:17 -0700	[thread overview]
Message-ID: <20130812230617.GB30952@kroah.com> (raw)
In-Reply-To: <a5214cbe041674f0b5dcd7eb9b581b4d7f923947.1375927849.git.sudeep.dutt@intel.com>

On Wed, Aug 07, 2013 at 08:04:07PM -0700, Sudeep Dutt wrote:
> +/**
> + * struct mic_device -  MIC device information for each card.
> + *
> + * @name: Unique name for this MIC device.
> + * @mmio: MMIO bar information.
> + * @pdev: The PCI device structure.
> + * @family: The MIC family to which this device belongs.
> + * @ops: MIC HW specific operations.
> + * @id: The unique device id for this MIC device.
> + * @stepping: Stepping ID.
> + * @attr_group: Sysfs attribute group.
> + * @sdev: Device for sysfs entries.
> + * @aper: Aperture bar information.
> + */
> +struct mic_device {
> +	char name[20];

The name can be in the struct device (it should be the same, right?)

> +	struct mic_mw mmio;
> +	struct pci_dev *pdev;

Isn't this just the parent of the device?  Do you really need this?

> +	enum mic_hw_family family;
> +	struct mic_hw_ops *ops;
> +	int id;
> +	enum mic_stepping stepping;
> +	struct attribute_group attr_group;

Shouldn't this be a pointer to a list of groups?

> +	struct device *sdev;

Shouldn't this be embedded inside here, instead of a pointer?

> +	struct mic_mw aper;
> +};


> +/**
> + * struct mic_info -  Global information about all MIC devices.
> + *
> + * @next_id: Next available MIC device id.
> + * @mic_class: Class of MIC devices for sysfs accessibility.
> + * @mdev_id: Base device node number.
> + */
> +struct mic_info {
> +	int next_id;

Please use the idr interface, don't roll your own, odds are you got it
wrong, and I don't want to have to debug it :(

> +	struct class *mic_class;

Isn't this a global symbol that you have (or static symbol).  There
should never be more than one "class" around for these devices.

> +	dev_t mdev_id;
> +};
> +
> +/* g_mic - Global information about all MIC devices. */
> +static struct mic_info g_mic;

See, one class :)

> +/**
> + * mic_probe - Device Initialization Routine
> + *
> + * @pdev: PCI device structure
> + * @ent: entry in mic_pci_tbl
> + *
> + * returns 0 on success, < 0 on failure.
> + */
> +static int __init mic_probe(struct pci_dev *pdev,
> +		const struct pci_device_id *ent)
> +{
> +	int rc;
> +	struct mic_device *mdev;
> +	char name[20];
> +
> +	rc = g_mic.next_id++;

No locking, please use the idr interface...

> +
> +	snprintf(name, sizeof(name), "mic%d", rc);
> +	mdev = kzalloc(sizeof(*mdev), GFP_KERNEL);
> +	if (!mdev) {
> +		rc = -ENOMEM;
> +		dev_err(&pdev->dev, "dev kmalloc failed rc %d\n", rc);
> +		goto dec_num_dev;
> +	}
> +	strncpy(mdev->name, name, sizeof(name));
> +	mdev->id = rc;
> +
> +	mic_device_init(mdev, pdev);
> +
> +	rc = pci_enable_device(pdev);
> +	if (rc) {
> +		dev_err(&pdev->dev, "failed to enable pci device.\n");
> +		goto free_device;
> +	}
> +
> +	pci_set_master(pdev);
> +
> +	rc = pci_request_regions(pdev, mic_driver_name);
> +	if (rc) {
> +		dev_err(&pdev->dev, "failed to get pci regions.\n");
> +		goto disable_device;
> +	}
> +
> +	rc = pci_set_dma_mask(pdev, DMA_BIT_MASK(64));
> +	if (rc) {
> +		dev_err(&pdev->dev, "Cannot set DMA mask\n");
> +		goto release_regions;
> +	}
> +
> +	mdev->mmio.pa = pci_resource_start(pdev, mdev->ops->mmio_bar);
> +	mdev->mmio.len = pci_resource_len(pdev, mdev->ops->mmio_bar);
> +	mdev->mmio.va = pci_ioremap_bar(pdev, mdev->ops->mmio_bar);
> +	if (!mdev->mmio.va) {
> +		dev_err(&pdev->dev, "Cannot remap MMIO BAR\n");
> +		rc = -EIO;
> +		goto release_regions;
> +	}
> +
> +	mdev->aper.pa = pci_resource_start(pdev, mdev->ops->aper_bar);
> +	mdev->aper.len = pci_resource_len(pdev, mdev->ops->aper_bar);
> +	mdev->aper.va = ioremap_wc(mdev->aper.pa, mdev->aper.len);
> +	if (!mdev->aper.va) {
> +		dev_err(&pdev->dev, "Cannot remap Aperture BAR\n");
> +		rc = -EIO;
> +		goto unmap_mmio;
> +	}
> +
> +	mdev->ops->init(mdev);
> +
> +	pci_set_drvdata(pdev, mdev);
> +
> +	mdev->sdev = device_create(g_mic.mic_class, &pdev->dev,
> +		MKDEV(MAJOR(g_mic.mdev_id), mdev->id), NULL, "%s", mdev->name);
> +	if (IS_ERR(mdev->sdev)) {
> +		rc = PTR_ERR(mdev->sdev);
> +		dev_err(&pdev->dev, "device_create failed rc %d\n", rc);
> +		goto unmap_aper;
> +	}
> +
> +	rc = sysfs_create_group(&mdev->sdev->kobj, &mdev->attr_group);

We now have a function you should use instead,
device_create_with_groups() that solves the race condition you just
caused here by creating and notifying userspace that the device is
present, _before_ creating the sysfs files for it.



> +	if (rc) {
> +		dev_err(&pdev->dev, "sysfs_create_group failed rc %d\n", rc);
> +		goto destroy_device;
> +	}
> +	dev_info(&pdev->dev, "Probe successful for %s\n", mdev->name);

Useless noise, remove it.

> +	return 0;
> +destroy_device:
> +	device_destroy(g_mic.mic_class, MKDEV(MAJOR(g_mic.mdev_id), mdev->id));
> +unmap_aper:
> +	iounmap(mdev->mmio.va);
> +unmap_mmio:
> +	iounmap(mdev->aper.va);
> +release_regions:
> +	pci_release_regions(pdev);
> +disable_device:
> +	pci_disable_device(pdev);
> +free_device:
> +	kfree(mdev);
> +dec_num_dev:
> +	g_mic.next_id--;
> +	dev_err(&pdev->dev, "Probe failed rc %d\n", rc);
> +	return rc;
> +}
> +
> +/**
> + * mic_remove - Device Removal Routine
> + * mic_remove is called by the PCI subsystem to alert the driver
> + * that it should release a PCI device.
> + *
> + * @pdev: PCI device structure
> + */
> +static void mic_remove(struct pci_dev *pdev)
> +{
> +	struct mic_device *mdev;
> +	int id;
> +
> +	mdev = pci_get_drvdata(pdev);
> +	if (!mdev)
> +		return;
> +
> +	id = mdev->id;
> +
> +	sysfs_remove_group(&mdev->sdev->kobj, &mdev->attr_group);

No need to do this as:

> +	device_destroy(g_mic.mic_class, MKDEV(MAJOR(g_mic.mdev_id), mdev->id));

Will do it for you if you make the changes above.

thanks,

greg k-h

  parent reply	other threads:[~2013-08-12 23:06 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <cover.1375927849.git.sudeep.dutt@intel.com>
     [not found] ` <0c1fb303c3977d4519ff8320d205e08dba697af6.1375927849.git.sudeep.dutt@intel.com>
2013-08-08  6:40   ` [PATCH v2 7/7] Sample Implementation of Intel MIC User Space Daemon Michael S. Tsirkin
2013-08-09 16:47     ` Sudeep Dutt
     [not found] ` <a5214cbe041674f0b5dcd7eb9b581b4d7f923947.1375927849.git.sudeep.dutt@intel.com>
2013-08-12 22:58   ` [PATCH v2 1/7] Intel MIC Host Driver for X100 family Greg Kroah-Hartman
2013-08-12 23:06   ` Greg Kroah-Hartman [this message]
2013-08-14 20:08     ` Sudeep Dutt

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=20130812230617.GB30952@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=AsiasHeasias@redhat.com \
    --cc=Caz.Yokoyama@intel.com \
    --cc=arnd@arndb.de \
    --cc=ashutosh.dixit@intel.com \
    --cc=dasaratharaman.chandramouli@intel.com \
    --cc=eddie.dong@intel.com \
    --cc=harshavardhan.r.kharche@intel.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mst@redhat.com \
    --cc=nikhil.rao@intel.com \
    --cc=peter.p.waskiewicz.jr@intel.com \
    --cc=rob@landley.net \
    --cc=rusty@rustcorp.com.au \
    --cc=sudeep.dutt@intel.com \
    --cc=virtualization@lists.linux-foundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox