From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753270AbcHLOet (ORCPT ); Fri, 12 Aug 2016 10:34:49 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:33859 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753129AbcHLOep (ORCPT ); Fri, 12 Aug 2016 10:34:45 -0400 X-IBM-Helo: d03dlp02.boulder.ibm.com X-IBM-MailFrom: jejb@linux.vnet.ibm.com 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" X-Mailer: Evolution 3.16.5 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16081214-0012-0000-0000-000010628062 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00005582; HX=3.00000240; KW=3.00000007; PH=3.00000004; SC=3.00000181; SDB=6.00743687; UDB=6.00350226; IPR=6.00516225; BA=6.00004660; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00012327; XFM=3.00000011; UTC=2016-08-12 14:34:41 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 16081214-0013-0000-0000-0000447E9AA3 Message-Id: <1471012475.2407.6.camel@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-08-12_06:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1608120154 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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