[PATCH 2/2] dpt_i2o: 64 bit support (take 4)

[PATCH 2/2] dpt_i2o: 64 bit support (take 4)

[Miquel van Smoorenburg]

sysfs code.

# -------

This patch is an update for drivers/scsi/dpt_i2o.c.
It applies to both 2.6.24.4 and 2.6.25

It contains the following changes:

* 64 bit code based on unofficial Adaptec 64 bit driver
* removes scsi_module.c dependency, adds module_init / module_exit
  this is needed because we need to pass the proper device to
  scsi_add_host(), and the scsi_module.c passes NULL. With NULL,
  code like arch/x64/kernel/pci-gart_64.c::need_iommu() crashes
  because the dev pointer it is passed is NULL.
* adds sysfs entry for /sys/class/dpt_i2o/dptiX so that udev
  can create /dev/dptiX dynamically

Obviously there are more cleanups that can be done to this code,
but we need to start somewhere. Patch has been tested heavily on
both 32 and 64 bit x86 platforms.

Signed-off-by: Miquel van Smoorenburg <miquels@cistron.nl>

diff -ruN linux-2.6.25/drivers/scsi/dpt_i2o.c linux-2.6.25-sysfs/drivers/scsi/dpt_i2o.c
--- linux-2.6.25/drivers/scsi/dpt_i2o.c	2008-04-24 22:30:29.000000000 +0200
+++ linux-2.6.25-sysfs/drivers/scsi/dpt_i2o.c	2008-04-24 23:26:08.000000000 +0200
@@ -116,6 +116,8 @@
 static adpt_hba* hba_chain = NULL;
 static int hba_count = 0;
 
+static struct class *adpt_sysfs_class;
+
 #ifdef CONFIG_COMPAT
 static long compat_adpt_ioctl(struct file *, unsigned int, unsigned long);
 #endif
@@ -259,6 +261,10 @@
 		adpt_inquiry(pHba);
 	}
 
+	adpt_sysfs_class = class_create(THIS_MODULE, "dpt_i2o");
+	if (IS_ERR(adpt_sysfs_class))
+		adpt_sysfs_class = NULL;
+
 	for (pHba = hba_chain; pHba; pHba = pHba->next) {
 		if (adpt_scsi_host_alloc(pHba, sht) < 0){
 			adpt_i2o_delete_hba(pHba);
@@ -266,6 +272,11 @@
 		}
 		pHba->initialized = TRUE;
 		pHba->state &= ~DPTI_STATE_RESET;
+		if (adpt_sysfs_class) {
+			class_device_create(adpt_sysfs_class,
+				NULL, MKDEV(DPTI_I2O_MAJOR, pHba->unit),
+				NULL, "dpti%d", pHba->unit);
+		}
 	}
 
 	// Register our control device node
@@ -1220,8 +1231,17 @@
 	pci_dev_put(pHba->pDev);
 	kfree(pHba);
 
-	if(hba_count <= 0)
+	if (adpt_sysfs_class)
+		class_device_destroy(adpt_sysfs_class,
+				MKDEV(DPTI_I2O_MAJOR, pHba->unit));
+
+	if(hba_count <= 0){
 		unregister_chrdev(DPTI_I2O_MAJOR, DPT_DRIVER);   
+		if (adpt_sysfs_class) {
+			class_destroy(adpt_sysfs_class);
+			adpt_sysfs_class = NULL;
+		}
+	}
 }
 
 static struct adpt_device* adpt_find_device(adpt_hba* pHba, u32 chan, u32 id, u32 lun)

Re: [PATCH 2/2] dpt_i2o: 64 bit support (take 4)

[Rolf Eike Beer]

[-- Attachment #1: Type: text/plain, Size: 2323 bytes --]

Miquel van Smoorenburg wrote:
> sysfs code.
>
> # -------
>
> This patch is an update for drivers/scsi/dpt_i2o.c.
> It applies to both 2.6.24.4 and 2.6.25
>
> It contains the following changes:
>
> * 64 bit code based on unofficial Adaptec 64 bit driver
> * removes scsi_module.c dependency, adds module_init / module_exit
>   this is needed because we need to pass the proper device to
>   scsi_add_host(), and the scsi_module.c passes NULL. With NULL,
>   code like arch/x64/kernel/pci-gart_64.c::need_iommu() crashes
>   because the dev pointer it is passed is NULL.
> * adds sysfs entry for /sys/class/dpt_i2o/dptiX so that udev
>   can create /dev/dptiX dynamically
>
> Obviously there are more cleanups that can be done to this code,
> but we need to start somewhere. Patch has been tested heavily on
> both 32 and 64 bit x86 platforms.
>
> Signed-off-by: Miquel van Smoorenburg <miquels@cistron.nl>
>
> diff -ruN linux-2.6.25/drivers/scsi/dpt_i2o.c
> linux-2.6.25-sysfs/drivers/scsi/dpt_i2o.c ---
> linux-2.6.25/drivers/scsi/dpt_i2o.c	2008-04-24 22:30:29.000000000 +0200 +++
> linux-2.6.25-sysfs/drivers/scsi/dpt_i2o.c	2008-04-24 23:26:08.000000000
> +0200 @@ -116,6 +116,8 @@
>  static adpt_hba* hba_chain = NULL;
>  static int hba_count = 0;
>
> +static struct class *adpt_sysfs_class;
> +
>  #ifdef CONFIG_COMPAT
>  static long compat_adpt_ioctl(struct file *, unsigned int, unsigned long);
>  #endif
> @@ -259,6 +261,10 @@
>  		adpt_inquiry(pHba);
>  	}
>
> +	adpt_sysfs_class = class_create(THIS_MODULE, "dpt_i2o");
> +	if (IS_ERR(adpt_sysfs_class))
> +		adpt_sysfs_class = NULL;
> +
>  	for (pHba = hba_chain; pHba; pHba = pHba->next) {
>  		if (adpt_scsi_host_alloc(pHba, sht) < 0){
>  			adpt_i2o_delete_hba(pHba);
> @@ -266,6 +272,11 @@
>  		}
>  		pHba->initialized = TRUE;
>  		pHba->state &= ~DPTI_STATE_RESET;
> +		if (adpt_sysfs_class) {
> +			class_device_create(adpt_sysfs_class,
> +				NULL, MKDEV(DPTI_I2O_MAJOR, pHba->unit),
> +				NULL, "dpti%d", pHba->unit);
> +		}
>  	}
>
>  	// Register our control device node

class_device_create() has a return value that should probably be used for 
something. Also Greg did many work to get rid of that class_device stuff 
AFAIK so it's probably a bad idea to introduce a new one.

Eike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 194 bytes --]

Re: [PATCH 2/2] dpt_i2o: 64 bit support (take 4)

[James Bottomley]

On Thu, 2008-04-24 at 23:35 +0200, Miquel van Smoorenburg wrote:
> sysfs code.
> 
> # -------
> 
> This patch is an update for drivers/scsi/dpt_i2o.c.
> It applies to both 2.6.24.4 and 2.6.25
> 
> It contains the following changes:
> 
> * 64 bit code based on unofficial Adaptec 64 bit driver
> * removes scsi_module.c dependency, adds module_init / module_exit
>   this is needed because we need to pass the proper device to
>   scsi_add_host(), and the scsi_module.c passes NULL. With NULL,
>   code like arch/x64/kernel/pci-gart_64.c::need_iommu() crashes
>   because the dev pointer it is passed is NULL.
> * adds sysfs entry for /sys/class/dpt_i2o/dptiX so that udev
>   can create /dev/dptiX dynamically

The changelog and patch title really needs to reflect only the actual
changes ... (as in only sysfs).

> Obviously there are more cleanups that can be done to this code,
> but we need to start somewhere. Patch has been tested heavily on
> both 32 and 64 bit x86 platforms.
> 
> Signed-off-by: Miquel van Smoorenburg <miquels@cistron.nl>
> 
> diff -ruN linux-2.6.25/drivers/scsi/dpt_i2o.c linux-2.6.25-sysfs/drivers/scsi/dpt_i2o.c
> --- linux-2.6.25/drivers/scsi/dpt_i2o.c	2008-04-24 22:30:29.000000000 +0200
> +++ linux-2.6.25-sysfs/drivers/scsi/dpt_i2o.c	2008-04-24 23:26:08.000000000 +0200
> @@ -116,6 +116,8 @@
>  static adpt_hba* hba_chain = NULL;
>  static int hba_count = 0;
>  
> +static struct class *adpt_sysfs_class;
> +
>  #ifdef CONFIG_COMPAT
>  static long compat_adpt_ioctl(struct file *, unsigned int, unsigned long);
>  #endif
> @@ -259,6 +261,10 @@
>  		adpt_inquiry(pHba);
>  	}
>  
> +	adpt_sysfs_class = class_create(THIS_MODULE, "dpt_i2o");
> +	if (IS_ERR(adpt_sysfs_class))
> +		adpt_sysfs_class = NULL;
> +
>  	for (pHba = hba_chain; pHba; pHba = pHba->next) {
>  		if (adpt_scsi_host_alloc(pHba, sht) < 0){
>  			adpt_i2o_delete_hba(pHba);
> @@ -266,6 +272,11 @@
>  		}
>  		pHba->initialized = TRUE;
>  		pHba->state &= ~DPTI_STATE_RESET;
> +		if (adpt_sysfs_class) {
> +			class_device_create(adpt_sysfs_class,

Unfortunately, Greg and Kay are in the process of nuking the
class_device and all its associated functions.  Now the way it works is
that you use an ordinary struct device, with the class pointer set up
and with the parent pointing to the device that class_device->dev used
to point to.

To see an example of this, you can look at:

commit ee959b00c335d7780136c5abda37809191fe52c3
Author: Tony Jones <tonyj@suse.de>
Date:   Fri Feb 22 00:13:36 2008 +0100

    SCSI: convert struct class_device to struct device

James

Re: [PATCH 2/2] dpt_i2o: 64 bit support (take 4)

[Greg KH]

On Fri, Apr 25, 2008 at 09:48:42AM +0200, Rolf Eike Beer wrote:
> Miquel van Smoorenburg wrote:
> > sysfs code.
> >
> > # -------
> >
> > This patch is an update for drivers/scsi/dpt_i2o.c.
> > It applies to both 2.6.24.4 and 2.6.25
> >
> > It contains the following changes:
> >
> > * 64 bit code based on unofficial Adaptec 64 bit driver
> > * removes scsi_module.c dependency, adds module_init / module_exit
> >   this is needed because we need to pass the proper device to
> >   scsi_add_host(), and the scsi_module.c passes NULL. With NULL,
> >   code like arch/x64/kernel/pci-gart_64.c::need_iommu() crashes
> >   because the dev pointer it is passed is NULL.
> > * adds sysfs entry for /sys/class/dpt_i2o/dptiX so that udev
> >   can create /dev/dptiX dynamically
> >
> > Obviously there are more cleanups that can be done to this code,
> > but we need to start somewhere. Patch has been tested heavily on
> > both 32 and 64 bit x86 platforms.
> >
> > Signed-off-by: Miquel van Smoorenburg <miquels@cistron.nl>
> >
> > diff -ruN linux-2.6.25/drivers/scsi/dpt_i2o.c
> > linux-2.6.25-sysfs/drivers/scsi/dpt_i2o.c ---
> > linux-2.6.25/drivers/scsi/dpt_i2o.c	2008-04-24 22:30:29.000000000 +0200 +++
> > linux-2.6.25-sysfs/drivers/scsi/dpt_i2o.c	2008-04-24 23:26:08.000000000
> > +0200 @@ -116,6 +116,8 @@
> >  static adpt_hba* hba_chain = NULL;
> >  static int hba_count = 0;
> >
> > +static struct class *adpt_sysfs_class;
> > +
> >  #ifdef CONFIG_COMPAT
> >  static long compat_adpt_ioctl(struct file *, unsigned int, unsigned long);
> >  #endif
> > @@ -259,6 +261,10 @@
> >  		adpt_inquiry(pHba);
> >  	}
> >
> > +	adpt_sysfs_class = class_create(THIS_MODULE, "dpt_i2o");
> > +	if (IS_ERR(adpt_sysfs_class))
> > +		adpt_sysfs_class = NULL;
> > +
> >  	for (pHba = hba_chain; pHba; pHba = pHba->next) {
> >  		if (adpt_scsi_host_alloc(pHba, sht) < 0){
> >  			adpt_i2o_delete_hba(pHba);
> > @@ -266,6 +272,11 @@
> >  		}
> >  		pHba->initialized = TRUE;
> >  		pHba->state &= ~DPTI_STATE_RESET;
> > +		if (adpt_sysfs_class) {
> > +			class_device_create(adpt_sysfs_class,
> > +				NULL, MKDEV(DPTI_I2O_MAJOR, pHba->unit),
> > +				NULL, "dpti%d", pHba->unit);
> > +		}
> >  	}
> >
> >  	// Register our control device node
> 
> class_device_create() has a return value that should probably be used for 
> something. Also Greg did many work to get rid of that class_device stuff 
> AFAIK so it's probably a bad idea to introduce a new one.

Yes, just use device_create() instead, it works just the same and as
class_device_create() will be gone in a week or so, it is something that
will work in 2.6.26 :)

thanks,

greg k-h