On Fri, 2016-08-12 at 15:11 +0200, Johannes Thumshirn wrote:
> On Fri, Aug 12, 2016 at 12:08:54PM +0200, Johannes Thumshirn wrote:
> > Ok, we can't use the rphy because of wide-ports. We can't fix it to
> > an end device either, as this makes some peoples systems
> > unbootable. Now let's find a third option satisfying the needs of
> > SAS wide-ports and my customers (and others running 4.5+ with a SAS
> > enclosure).
> >
> > I'm digging...
>
>
> To answer myself, Hannes suggested doing it like this:
>
> diff --git a/drivers/scsi/ses.c b/drivers/scsi/ses.c
> index 53ef1cb6..1d82053 100644
> --- a/drivers/scsi/ses.c
> +++ b/drivers/scsi/ses.c
> @@ -587,7 +587,7 @@ static void ses_match_to_enclosure(struct
> enclosure_device *edev,
>
> ses_enclosure_data_process(edev, to_scsi_device(edev
> ->edev.parent), 0);
>
> - if (is_sas_attached(sdev))
> + if (scsi_is_sas_rphy(&sdev->sdev_gendev))
> efd.addr = sas_get_address(sdev);
>
> if (efd.addr) {
>
>
> The reasoning behind this is, we only read the address if we have an
> actual sas_rphy.
>
> Would this be OK for you?
Could you please debug the why? first before we start throwing patches
around. is_sas_attached(sdev) returns true if the sdev is the child of
a SAS controller. What is this thing you've found that has a sdev
attached to a SAS controller but isn't and end device?
if is_sas_attached() passes but scsi_is_sas_rphy() doesn't you've got a
device that is the child of a SAS host which has an rphy but which
isn't an expander or end device. That's pretty much the end of the
list of things which can lie at the end of rphys since we lump the SATA
possibilities in with end devices.
James
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html