Re: [PATCH 3/4] scsi: use 64-bit value for 'max_luns'
On 02/19/2013 05:33 PM, James Bottomley wrote: On Tue, 2013-02-19 at 10:30 -0600, Michael Christie wrote: On Feb 19, 2013, at 2:18 AM, Hannes Reinecke wrote: diff --git a/drivers/scsi/cxgbi/libcxgbi.c b/drivers/scsi/cxgbi/libcxgbi.c index b44c1cf..95105c0 100644 --- a/drivers/scsi/cxgbi/libcxgbi.c +++ b/drivers/scsi/cxgbi/libcxgbi.c @@ -245,7 +245,7 @@ void cxgbi_hbas_remove(struct cxgbi_device *cdev) } EXPORT_SYMBOL_GPL(cxgbi_hbas_remove); -int cxgbi_hbas_add(struct cxgbi_device *cdev, unsigned int max_lun, +int cxgbi_hbas_add(struct cxgbi_device *cdev, uint64_t max_lun, unsigned int max_id, struct scsi_host_template *sht, struct scsi_transport_template *stt) { diff --git a/drivers/scsi/cxgbi/libcxgbi.h b/drivers/scsi/cxgbi/libcxgbi.h index 80fa99b..d3b27f8 100644 --- a/drivers/scsi/cxgbi/libcxgbi.h +++ b/drivers/scsi/cxgbi/libcxgbi.h @@ -692,7 +692,7 @@ struct cxgbi_device *cxgbi_device_register(unsigned int, unsigned int); void cxgbi_device_unregister(struct cxgbi_device *); void cxgbi_device_unregister_all(unsigned int flag); struct cxgbi_device *cxgbi_device_find_by_lldev(void *); -int cxgbi_hbas_add(struct cxgbi_device *, unsigned int, unsigned int, +int cxgbi_hbas_add(struct cxgbi_device *, uint64_t, unsigned int, struct scsi_host_template *, struct scsi_transport_template *); void cxgbi_hbas_remove(struct cxgbi_device *); diff --git a/drivers/scsi/dc395x.c b/drivers/scsi/dc395x.c index dfe90ce..9acdb9c 100644 Could it be possible to use u64, so it matches the rest of the driver coding style? The rest of the driver uses the u* definitions instead f the uint*_t ones. In general we should use u64 for kernel internal stuff (which this is). uint64_t is supposed to be reserved for user interfaces. Ok. Will fix it up with the next series. Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] scsi: use 64-bit value for 'max_luns'
On Tue, 2013-02-19 at 10:30 -0600, Michael Christie wrote: > On Feb 19, 2013, at 2:18 AM, Hannes Reinecke wrote: > > > diff --git a/drivers/scsi/cxgbi/libcxgbi.c b/drivers/scsi/cxgbi/libcxgbi.c > > index b44c1cf..95105c0 100644 > > --- a/drivers/scsi/cxgbi/libcxgbi.c > > +++ b/drivers/scsi/cxgbi/libcxgbi.c > > @@ -245,7 +245,7 @@ void cxgbi_hbas_remove(struct cxgbi_device *cdev) > > } > > EXPORT_SYMBOL_GPL(cxgbi_hbas_remove); > > > > -int cxgbi_hbas_add(struct cxgbi_device *cdev, unsigned int max_lun, > > +int cxgbi_hbas_add(struct cxgbi_device *cdev, uint64_t max_lun, > > unsigned int max_id, struct scsi_host_template *sht, > > struct scsi_transport_template *stt) > > { > > diff --git a/drivers/scsi/cxgbi/libcxgbi.h b/drivers/scsi/cxgbi/libcxgbi.h > > index 80fa99b..d3b27f8 100644 > > --- a/drivers/scsi/cxgbi/libcxgbi.h > > +++ b/drivers/scsi/cxgbi/libcxgbi.h > > @@ -692,7 +692,7 @@ struct cxgbi_device *cxgbi_device_register(unsigned > > int, unsigned int); > > void cxgbi_device_unregister(struct cxgbi_device *); > > void cxgbi_device_unregister_all(unsigned int flag); > > struct cxgbi_device *cxgbi_device_find_by_lldev(void *); > > -int cxgbi_hbas_add(struct cxgbi_device *, unsigned int, unsigned int, > > +int cxgbi_hbas_add(struct cxgbi_device *, uint64_t, unsigned int, > > struct scsi_host_template *, > > struct scsi_transport_template *); > > void cxgbi_hbas_remove(struct cxgbi_device *); > > diff --git a/drivers/scsi/dc395x.c b/drivers/scsi/dc395x.c > > index dfe90ce..9acdb9c 100644 > > > Could it be possible to use u64, so it matches the rest of the driver > coding style? The rest of the driver uses the u* definitions instead f > the uint*_t ones. In general we should use u64 for kernel internal stuff (which this is). uint64_t is supposed to be reserved for user interfaces. James -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] scsi: use 64-bit value for 'max_luns'
On Feb 19, 2013, at 2:18 AM, Hannes Reinecke wrote: > diff --git a/drivers/scsi/cxgbi/libcxgbi.c b/drivers/scsi/cxgbi/libcxgbi.c > index b44c1cf..95105c0 100644 > --- a/drivers/scsi/cxgbi/libcxgbi.c > +++ b/drivers/scsi/cxgbi/libcxgbi.c > @@ -245,7 +245,7 @@ void cxgbi_hbas_remove(struct cxgbi_device *cdev) > } > EXPORT_SYMBOL_GPL(cxgbi_hbas_remove); > > -int cxgbi_hbas_add(struct cxgbi_device *cdev, unsigned int max_lun, > +int cxgbi_hbas_add(struct cxgbi_device *cdev, uint64_t max_lun, > unsigned int max_id, struct scsi_host_template *sht, > struct scsi_transport_template *stt) > { > diff --git a/drivers/scsi/cxgbi/libcxgbi.h b/drivers/scsi/cxgbi/libcxgbi.h > index 80fa99b..d3b27f8 100644 > --- a/drivers/scsi/cxgbi/libcxgbi.h > +++ b/drivers/scsi/cxgbi/libcxgbi.h > @@ -692,7 +692,7 @@ struct cxgbi_device *cxgbi_device_register(unsigned int, > unsigned int); > void cxgbi_device_unregister(struct cxgbi_device *); > void cxgbi_device_unregister_all(unsigned int flag); > struct cxgbi_device *cxgbi_device_find_by_lldev(void *); > -int cxgbi_hbas_add(struct cxgbi_device *, unsigned int, unsigned int, > +int cxgbi_hbas_add(struct cxgbi_device *, uint64_t, unsigned int, > struct scsi_host_template *, > struct scsi_transport_template *); > void cxgbi_hbas_remove(struct cxgbi_device *); > diff --git a/drivers/scsi/dc395x.c b/drivers/scsi/dc395x.c > index dfe90ce..9acdb9c 100644 Could it be possible to use u64, so it matches the rest of the driver coding style? The rest of the driver uses the u* definitions instead f the uint*_t ones. I think it could just be edited when the patch is merged instead of having to send a whole new patchset. We can also just fix it up later of the patches get merged as is.-- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html