From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:10166 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753184AbcHLOep (ORCPT ); Fri, 12 Aug 2016 10:34:45 -0400 Received: from pps.filterd (m0098417.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u7CEYf3U011322 for ; Fri, 12 Aug 2016 10:34:44 -0400 Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.153]) by mx0a-001b2d01.pphosted.com with ESMTP id 24rtx4na8y-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Fri, 12 Aug 2016 10:34:44 -0400 Received: from localhost by e35.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 12 Aug 2016 08:34:43 -0600 Subject: Re: [PATCH] SAS: use sas_rphy instead of sas_end_device to obtain address. From: James Bottomley To: Johannes Thumshirn Cc: "Martin K . Petersen" , Hannes Reinecke , Linux SCSI Mailinglist , Linux Kernel Mailinglist , stable@vger.kernel.org, #@suse.de, v4.5+@suse.de Date: Fri, 12 Aug 2016 07:34:35 -0700 In-Reply-To: <20160812131125.n7p47dcf7sinwg54@c203.arch.suse.de> References: <1470902352-96734-1-git-send-email-jthumshirn@suse.de> <1470928175.2334.9.camel@linux.vnet.ibm.com> <20160811164350.vakulxlr4xlsyrxn@c203.arch.suse.de> <1470938407.2334.36.camel@linux.vnet.ibm.com> <20160812100854.4cks5qxsommfwsjk@c203.arch.suse.de> <20160812131125.n7p47dcf7sinwg54@c203.arch.suse.de> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Message-Id: <1471012475.2407.6.camel@linux.vnet.ibm.com> Sender: stable-owner@vger.kernel.org List-ID: 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