Am Fri, 16 Sep 2011 12:51:31 -0300
schrieb Benjamin Herrenschmidt <b...@kernel.crashing.org>:
>
> > I've done some readings about this problem today, and I think I've got
> > an idea what might be wrong here - seems like a bug in SLOF to me.
> >
> > First, according to the SLOF source code, it seems to me that its
> > intention is to to scan target IDs, not channels (but as I haven't
> > written that part, I am not 100% sure here).
> >
> > Then I compared how Linux and SLOF fill the 64-bit LUN field in the
> > SRP_CMD request structure, and they both fill in the target ID at the
> > same location - but Linux is additionally setting an additional bit in
> > first byte (see the "lun_from_dev" function in ibmvscsi.c of the
> > kernel).
> >
> > Looking at the "SCSI Architecture Model" specification, this additional
> > bit is used to select the "Logical unit addressing method" instead of
> > the "Peripheral device addressing method" that SLOF currently uses - and
> > the "Logical unit addressing method" sounds more reasonable to me when
> > looking at the places where SLOF tries to fill in the target ID.
> >
> > So I suggest that I change SLOF to also use the "Logical unit
> > addressing method" like Linux does, which should result in the fact that
> > SLOF tries to scan the target IDs instead of the channels/bus IDs.
>
> .../...
>
> Note that in addition to that, the PAPR spec specifies only one
> "device" (whatever that means) per vscsi instance.
Really? In that case, I wonder why Linux is using the "Logical unit
addressing format" with target IDs and bus numbers instead of the
"Flat space addressing method" for vscsi ... according to
drivers/scsi/ibmvscsi/ibmvscsi.c :
static inline u16 lun_from_dev(struct scsi_device *dev)
{
return (0x2 << 14) | (dev->id << 8) | (dev->channel << 5) | dev->lun;
}
In case there's really only one device per vscsi instance, shouldn't
that code use addressing method 0x1 instead of 0x2 here?
Thomas
