From: Mike Christie <michaelc@cs.wisc.edu>
To: james.smart@emulex.com
Cc: linux-scsi@vger.kernel.org
Subject: Re: [PATCH 01/07] lpfc 8.3.29: BSG and User interface fixes
Date: Wed, 18 Jan 2012 16:21:55 -0600 [thread overview]
Message-ID: <4F174603.8060104@cs.wisc.edu> (raw)
In-Reply-To: <1326921829.32733.10.camel@ogier>
On 01/18/2012 03:23 PM, James Smart wrote:
> - Create character device to take a reference on the driver (126082)
>
Is this so the driver cannot get unloaded when doing multiple bsg/sysfs
requests? If so having every driver create its own char device seems
wrong. qla2xxx does this too.qla4xxx wants to do it. Every driver has
the problem.
If we do this can we at least have a scsi lib helper function that can
enforce a consistent naming policy for the char devs so userspace apps
do not have to have some crazy look up table for every driver.
Or, is there a better way to support this? Maybe a common sysfs attr on
the host or a bsg request? Something common that works for all drivers
so we do not have to go around to every driver and add char device to them?
> diff -upNr a/drivers/scsi/lpfc/lpfc_init.c b/drivers/scsi/lpfc/lpfc_init.c
> --- a/drivers/scsi/lpfc/lpfc_init.c 2012-01-12 22:43:34.000000000 -0500
> +++ b/drivers/scsi/lpfc/lpfc_init.c 2012-01-18 11:32:20.000000000 -0500
> @@ -32,6 +32,7 @@
> #include <linux/aer.h>
> #include <linux/slab.h>
> #include <linux/firmware.h>
> +#include <linux/miscdevice.h>
>
> #include <scsi/scsi.h>
> #include <scsi/scsi_device.h>
> @@ -10012,6 +10013,36 @@ lpfc_io_resume(struct pci_dev *pdev)
> return;
> }
>
> +/**
> + * lpfc_mgmt_open - method called when 'lpfcmgmt' is opened from userspace
> + * @inode: pointer to the inode representing the lpfcmgmt device
> + * @filep: pointer to the file representing the open lpfcmgmt device
> + *
> + * This routine puts a reference count on the lpfc module whenever the
> + * character device is opened
> + **/
> +static int
> +lpfc_mgmt_open(struct inode *inode, struct file *filep)
> +{
> + try_module_get(THIS_MODULE);
> + return 0;
> +}
> +
> +/**
> + * lpfc_mgmt_release - method called when 'lpfcmgmt' is closed in userspace
> + * @inode: pointer to the inode representing the lpfcmgmt device
> + * @filep: pointer to the file representing the open lpfcmgmt device
> + *
> + * This routine removes a reference count from the lpfc module when the
> + * character device is closed
> + **/
> +static int
> +lpfc_mgmt_release(struct inode *inode, struct file *filep)
> +{
> + module_put(THIS_MODULE);
> + return 0;
> +}
> +
> static struct pci_device_id lpfc_id_table[] = {
> {PCI_VENDOR_ID_EMULEX, PCI_DEVICE_ID_VIPER,
> PCI_ANY_ID, PCI_ANY_ID, },
> @@ -10124,6 +10155,17 @@ static struct pci_driver lpfc_driver = {
> .err_handler = &lpfc_err_handler,
> };
>
> +static const struct file_operations lpfc_mgmt_fop = {
> + .open = lpfc_mgmt_open,
> + .release = lpfc_mgmt_release,
> +};
> +
> +static struct miscdevice lpfc_mgmt_dev = {
> + .minor = MISC_DYNAMIC_MINOR,
> + .name = "lpfcmgmt",
> + .fops = &lpfc_mgmt_fop,
> +};
> +
> /**
> * lpfc_init - lpfc module initialization routine
> *
> @@ -10144,6 +10186,11 @@ lpfc_init(void)
> printk(LPFC_MODULE_DESC "\n");
> printk(LPFC_COPYRIGHT "\n");
>
> + error = misc_register(&lpfc_mgmt_dev);
> + if (error)
> + printk(KERN_ERR "Could not register lpfcmgmt device, "
> + "misc_register returned with status %d", error);
> +
> if (lpfc_enable_npiv) {
> lpfc_transport_functions.vport_create = lpfc_vport_create;
> lpfc_transport_functions.vport_delete = lpfc_vport_delete;
> @@ -10180,6 +10227,7 @@ lpfc_init(void)
> static void __exit
> lpfc_exit(void)
> {
> + misc_deregister(&lpfc_mgmt_dev);
> pci_unregister_driver(&lpfc_driver);
> fc_release_transport(lpfc_transport_template);
> if (lpfc_enable_npiv)
next prev parent reply other threads:[~2012-01-18 22:22 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-18 21:23 [PATCH 01/07] lpfc 8.3.29: BSG and User interface fixes James Smart
2012-01-18 22:21 ` Mike Christie [this message]
2012-01-19 17:33 ` James Smart
2012-01-25 22:34 ` FUJITA Tomonori
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=4F174603.8060104@cs.wisc.edu \
--to=michaelc@cs.wisc.edu \
--cc=james.smart@emulex.com \
--cc=linux-scsi@vger.kernel.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;
as well as URLs for NNTP newsgroup(s).