All of lore.kernel.org
 help / color / mirror / Atom feed
From: Luben Tuikov <luben_tuikov@adaptec.com>
To: James Bottomley <James.Bottomley@SteelEye.com>
Cc: Patrick Mansfield <patmans@us.ibm.com>,
	Douglas Gilbert <dougg@torque.net>,
	Christoph Hellwig <hch@infradead.org>,
	Luben Tuikov <ltuikov@yahoo.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	SCSI Mailing List <linux-scsi@vger.kernel.org>
Subject: Re: [PATCH 2.6.13 5/14] sas-class: sas_discover.c Discover process (end devices)
Date: Tue, 13 Sep 2005 16:23:42 -0400	[thread overview]
Message-ID: <4327354E.7090409@adaptec.com> (raw)
In-Reply-To: <1126639342.4809.53.camel@mulgrave>

On 09/13/05 15:22, James Bottomley wrote:
> On Mon, 2005-09-12 at 11:46 -0700, Patrick Mansfield wrote:
> 
>>Though we still have problems with scsi_report_lun_scan code like:
>>
>>                } else if (lun > sdev->host->max_lun) {
>>
>>max_lun just has to be large, at least greater than 0xc001 (49153), maybe
>>even 0xffffffff, correct?
>>
>>But then some sequential scanning could take a while. Maybe the above
>>check is not needed.
> 
> 
> Try this as a straw horse for doing full u64 luns.

James, this patch is wrong.

A SCSI LUN is not "u64 lun", it has never been and it will
never be.

A SCSI LUN is "u8 LUN[8]" -- it is this from the Application
Layer down to the _transport layer_ (if you cared to look at
_any_ LL transport).

(It is also capitalized since it is an abbreviation.)

To compare/print it, please use, as shown at the top of the
file "sas.h":

(be64_to_cpu(*(__be64 *)(_x)))

where _x is only the "LUN" of the definition above.

If you want to print it, please use "%016llx".

It also appears that you've never compiled your patch on
x86_64.

Alternatively, you can take a look at the SAS Layer.

	Luben

> 
> I've converted all the mid-layer and the ULDs; I ran out of steam at the
> lld's.
> 
> This should work transparently for all luns up to 255 (using
> representation 00b), so I've limited all of our sequential LUN scans to
> 255
> 
> This actually boots ... but I don't have a system with >1 LUN currently.
> 
> James

[cut]

> diff --git a/include/scsi/scsi_device.h b/include/scsi/scsi_device.h
> --- a/include/scsi/scsi_device.h
> +++ b/include/scsi/scsi_device.h
> @@ -66,7 +66,8 @@ struct scsi_device {
>  					   jiffie count on our counter, they
>  					   could all be from the same event. */
>  
> -	unsigned int id, lun, channel;
> +	unsigned int id, channel;
> +	u64 lun;
>  
>  	unsigned int manufacturer;	/* Manufacturer of device, for using 
>  					 * vendor-specific cmd's */
> @@ -179,20 +180,20 @@ static inline struct scsi_target *scsi_t
>  extern struct scsi_device *__scsi_add_device(struct Scsi_Host *,
>  		uint, uint, uint, void *hostdata);
>  extern int scsi_add_device(struct Scsi_Host *host, uint channel,
> -			   uint target, uint lun);
> +			   uint target, u64 lun);
>  extern void scsi_remove_device(struct scsi_device *);
>  extern int scsi_device_cancel(struct scsi_device *, int);
>  
>  extern int scsi_device_get(struct scsi_device *);
>  extern void scsi_device_put(struct scsi_device *);
>  extern struct scsi_device *scsi_device_lookup(struct Scsi_Host *,
> -					      uint, uint, uint);
> +					      uint, uint, u64);
>  extern struct scsi_device *__scsi_device_lookup(struct Scsi_Host *,
> -						uint, uint, uint);
> +						uint, uint, u64);
>  extern struct scsi_device *scsi_device_lookup_by_target(struct scsi_target *,
> -							uint);
> +							u64);
>  extern struct scsi_device *__scsi_device_lookup_by_target(struct scsi_target *,
> -							  uint);
> +							  u64);
>  extern void starget_for_each_device(struct scsi_target *, void *,
>  		     void (*fn)(struct scsi_device *, void *));
>  
> @@ -248,12 +249,13 @@ extern void scsi_device_resume(struct sc
>  extern void scsi_target_quiesce(struct scsi_target *);
>  extern void scsi_target_resume(struct scsi_target *);
>  extern void scsi_scan_target(struct device *parent, unsigned int channel,
> -			     unsigned int id, unsigned int lun, int rescan);
> +			     unsigned int id, u64 lun, int rescan);
>  extern void scsi_target_reap(struct scsi_target *);
>  extern void scsi_target_block(struct device *);
>  extern void scsi_target_unblock(struct device *);
>  extern void scsi_remove_target(struct device *);
> -extern void int_to_scsilun(unsigned int, struct scsi_lun *);
> +extern void int_to_scsilun(u64, struct scsi_lun *);
> +extern u64 scsilun_to_int(struct scsi_lun *);
>  extern const char *scsi_device_state_name(enum scsi_device_state);
>  extern int scsi_is_sdev_device(const struct device *);
>  extern int scsi_is_target_device(const struct device *);
> diff --git a/include/scsi/scsi_host.h b/include/scsi/scsi_host.h
> --- a/include/scsi/scsi_host.h
> +++ b/include/scsi/scsi_host.h
> @@ -494,7 +494,10 @@ struct Scsi_Host {
>  	 * or lun (i.e. 8 for normal systems).
>  	 */
>  	unsigned int max_id;
> -	unsigned int max_lun;
> +	#define SCSI_UNLIMITED_LUNS	(0xffffffffffffffffULL)
> +	/* Any luns beyond 255 *require* report luns to find */
> +	#define SCSI_SCAN_LIMIT_LUNS	256
> +	u64 max_lun;
>  	unsigned int max_channel;
>  
>  	/*
> 
> 
> 


  reply	other threads:[~2005-09-13 20:23 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-09-09 19:40 [PATCH 2.6.13 5/14] sas-class: sas_discover.c Discover process (end devices) Luben Tuikov
2005-09-09 19:59 ` Nish Aravamudan
2005-09-09 20:11   ` Luben Tuikov
2005-09-09 23:25 ` James Bottomley
2005-09-10  2:44   ` Luben Tuikov
2005-09-10  5:39     ` Douglas Gilbert
2005-09-10 16:01     ` James Bottomley
2005-09-12 15:06       ` Luben Tuikov
2005-09-12 16:27         ` Patrick Mansfield
2005-09-12 20:08           ` Luben Tuikov
2005-09-13  9:05           ` Douglas Gilbert
2005-09-13 13:11             ` Luben Tuikov
2005-09-13 22:42             ` Patrick Mansfield
2005-09-14 12:28               ` Luben Tuikov
2005-09-14 17:13                 ` Patrick Mansfield
2005-09-14 17:17                   ` Luben Tuikov
2005-09-14 18:47               ` James Bottomley
2005-09-14 20:20                 ` Luben Tuikov
2005-09-12 17:52         ` James Bottomley
2005-09-12 20:31           ` Luben Tuikov
2005-09-12 21:23             ` James Bottomley
2005-09-13 12:49               ` Luben Tuikov
2005-09-13 15:54                 ` James Bottomley
2005-09-13 20:01                   ` Luben Tuikov
2005-09-11  9:46     ` Christoph Hellwig
2005-09-12  6:17       ` Douglas Gilbert
2005-09-12 14:57         ` James Bottomley
2005-09-12 16:45           ` Patrick Mansfield
2005-09-12 17:21             ` James Bottomley
2005-09-12 18:46               ` Patrick Mansfield
2005-09-13 19:22                 ` James Bottomley
2005-09-13 20:23                   ` Luben Tuikov [this message]
2005-09-13 20:36                     ` Matthew Wilcox
2005-09-13 21:02                       ` Luben Tuikov
2005-09-13 21:37                         ` Stefan Richter
2005-09-13 21:54                           ` Luben Tuikov
2005-09-13 22:25                         ` Patrick Mansfield
2005-09-14  5:22                           ` Sergey Panov
2005-09-14 16:28                             ` Patrick Mansfield
2005-09-14 12:13                           ` Luben Tuikov
2005-09-14  4:57                       ` Sergey Panov
2005-09-14 18:43                         ` James Bottomley
2005-09-14 20:17                           ` Luben Tuikov
2005-09-15  2:04                           ` Sergey Panov
2005-09-12 20:20               ` Luben Tuikov
2005-09-12 20:09             ` Luben Tuikov
2005-09-12 19:39           ` Luben Tuikov
2005-09-12 18:17         ` Luben Tuikov
2005-09-13 10:25         ` Christoph Hellwig
2005-09-13 12:47           ` Douglas Gilbert
2005-09-13 14:58             ` Luben Tuikov
2005-09-12 22:39       ` Luben Tuikov
  -- strict thread matches above, loose matches on Subject: below --
2005-09-12 19:04 James.Smart
2005-09-12 19:04 ` James.Smart
2005-09-12 19:29 ` Patrick Mansfield
2005-09-12 19:53 James.Smart
2005-09-12 19:53 ` James.Smart
2005-09-14  0:58 Ravi Anand
2005-09-14 17:46 Ravi Anand
2005-09-16  7:28 Andreas Herrmann

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=4327354E.7090409@adaptec.com \
    --to=luben_tuikov@adaptec.com \
    --cc=James.Bottomley@SteelEye.com \
    --cc=dougg@torque.net \
    --cc=hch@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=ltuikov@yahoo.com \
    --cc=patmans@us.ibm.com \
    /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.