[PATCH] lpfc: Default fdmi_on to on
Change default behavior for fdmi registration to on. Signed-off-by: Dick Kennedy Signed-off-by: James Smart --- drivers/scsi/lpfc/lpfc_attr.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/scsi/lpfc/lpfc_attr.c b/drivers/scsi/lpfc/lpfc_attr.c index 5a25553415f8..057a60abe664 100644 --- a/drivers/scsi/lpfc/lpfc_attr.c +++ b/drivers/scsi/lpfc/lpfc_attr.c @@ -5122,16 +5122,16 @@ LPFC_ATTR_R(enable_SmartSAN, 0, 0, 1, "Enable SmartSAN functionality"); /* # lpfc_fdmi_on: Controls FDMI support. -# 0 No FDMI support (default) -# 1 Traditional FDMI support +# 0 No FDMI support +# 1 Traditional FDMI support (default) # Traditional FDMI support means the driver will assume FDMI-2 support; # however, if that fails, it will fallback to FDMI-1. # If lpfc_enable_SmartSAN is set to 1, the driver ignores lpfc_fdmi_on. # If lpfc_enable_SmartSAN is set 0, the driver uses the current value of # lpfc_fdmi_on. -# Value range [0,1]. Default value is 0. +# Value range [0,1]. Default value is 1. */ -LPFC_ATTR_R(fdmi_on, 0, 0, 1, "Enable FDMI support"); +LPFC_ATTR_R(fdmi_on, 1, 0, 1, "Enable FDMI support"); /* # Specifies the maximum number of ELS cmds we can have outstanding (for -- 2.13.1
Targeted B2B Companies Emails List
Hi, I just wanted to check if you would be interested in a list of Managed Service Providers (MSPs) and Managed Security Service Providers (MSSPs)? We also have the data intelligence of: • Managed Service Providers (MSP’s) • Managed Security Service Providers (MSSP’s) • IT Decision Makers – 6million across all industry • Business Decision Makers – 10 million across all industry • Value Added Resellers- VARs • Independent Software Vendors- ISVs • System Integrators- SIs • VoIP Service Providers. • Telecommunications Service Providers (TSPs) • Application Service Providers (ASPs) • IT Managed Services Providers (ITMSP) • Storage Service Providers (SSPs) Kindly review and let me know if I can share more information on this. I look forward to hearing from you. Regards, Joyce Marketing Specialist If you don't want to include yourself in our mailing list, please reply back “Leave Out"" in a subject line"
RE: [PATCH v2 1/8] scsi: Add ufs transport class
Hi Bart, > -Original Message- > From: Bart Van Assche > Sent: Friday, August 10, 2018 2:51 AM > To: h...@lst.de; Avri Altman ; linux-scsi@vger.kernel.org; h...@suse.com; > jthumsh...@suse.de; martin.peter...@oracle.com; > j...@linux.vnet.ibm.com > Cc: Vinayak Holikatti ; Avi Shchislowski ; Alex Lemberg ; Stanislav Nijnikov > ; subha...@codeaurora.org > Subject: Re: [PATCH v2 1/8] scsi: Add ufs transport class > > On Thu, 2018-08-09 at 23:32 +, Avri Altman wrote: > > And as I said before, we think that maintaining the flexibility to have > > more-than-one > > bsg device nodes, will be useful serving as a testing and validation > > environment. > > That is a very vague statement. Please clarify. > > > >> "... > > >> In addition to the basic SCSI core objects this transport class > > >> introduces two additional (currently empty) class objects: > > >> “ufs-host” and “ufs-port”. There is only one “ufs-host” in the > > >> system, but can be more-than-one “ufs-ports”. > > >> > > >> ..." > > > > >Since both the ufs-host and ufs-port objects are empty, can both be left > > >out? > > But mustn't I declare those classes for the various components of the scsi > > transport to work? > > Are you perhaps referring to the transport_class_register() calls in SCSI > transport drivers? From what I see in existing SCSI transport drivers the > transport_class_register() function is used to register link, port, host, > vport, rport and other objects. I don't think that a SCSI transport driver > is required to register host and port objects. > > Maybe we should take a step back and discuss first why the new bsg queues > are registered by a transport driver? Since in case of UFS as far as I can > see there is no real need to introduce a transport driver other than for > creating the bsg device nodes, have you considered to add the code for > creating bsg device nodes to the UFS driver instead of in a UFS transport > driver? I think transport drivers were introduced as a way to share code > between multiple SCSI LLDs that use the same transport mechanism. In the > case of UFS there is only one SCSI LLD. Hence I'm wondering whether we > really need an UFS transport driver. > At the moment, the SCSI transport related code could be found at driver/scsi/scsi_transport_* files. What is a point of hiding the UFS transport code inside the UFS driver? Regards. Stanislav
