To:     Douglas Gilbert <dgilbert@interlog.com>
Cc:     "Maciej W. Rozycki" <macro@orcam.me.uk>,
        Khalid Aziz <khalid@gonehiking.org>,
        "James E.J. Bottomley" <jejb@linux.ibm.com>,
        "Martin K. Petersen" <martin.petersen@oracle.com>,
        Christoph Hellwig <hch@lst.de>, Nix <nix@esperi.org.uk>,
        linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 3/3] scsi: Set allocation length to 255 for ATA
 Information VPD page
From:   "Martin K. Petersen" <martin.petersen@oracle.com>
Organization: Oracle Corporation
Message-ID: <yq1o84s33w7.fsf@ca-mkp.ca.oracle.com>
References: <alpine.DEB.2.21.2201020010540.56863@angie.orcam.me.uk>
        <alpine.DEB.2.21.2201020030130.56863@angie.orcam.me.uk>
        <d9eaa1f8-7abb-645b-d624-5069205c6983@interlog.com>
Date:   Mon, 03 Jan 2022 16:37:46 -0500
In-Reply-To: <d9eaa1f8-7abb-645b-d624-5069205c6983@interlog.com> (Douglas
        Gilbert's message of "Sun, 2 Jan 2022 23:09:24 -0500")
Content-Type: text/plain
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?mBg+iXGt/vSYm7YXn6363ffMABNsP9RvM+B+4ogWMGhGx+d0xXvpplC1aett?=
 =?us-ascii?Q?bohpLWkj6s+RPjl9UXQ8HbYnW+hLOOIOhD2iMsZBIeHiYDRLH5kpJK8kD/XB?=
 =?us-ascii?Q?Pqgi0EWSTv1C6mGuXP4lUgKwmxivqonfM62iXQI0sdBsCuHdrxYCaG4sgqmU?=
 =?us-ascii?Q?z0BZeuzTyJh1hxvTPpTP2PW1r30ED8oR2O1xIxjKDN1omlzeGdN/KXmVqxxZ?=
 =?us-ascii?Q?Nehd2sfQPdiS1/gUxwg6SA9IjmyvyQ3Y0qUjl24SJ4WAKNCu9qNKXSBKFjq8?=
 =?us-ascii?Q?ZtXt7MGTV2Aky75Z4wuaZicPXQY/TCjG2SXGTVl2viQp9+Rlt3PhxGe+1JfK?=
 =?us-ascii?Q?5d9j5llQ/pRjBaFvB+yJNAVkQaYMSkqCpGv4a+NfFFHRNA+zrpmXSsYFMV8k?=
 =?us-ascii?Q?gFPBcSZJjEOaUvCBQrMh21ajnu9uw2bvWRcjl2Dw80oaYdnB5nRJhJbggyem?=
 =?us-ascii?Q?kfF+umI12+iwEJhR+lcTb7j6nR69cM33KJ9MYMPaRBEsmiVCysLYkfUghjJ8?=
 =?us-ascii?Q?WXjiT9DYSXnjH2mX94Fnlo1BPvgjSrJt4MGsWKjku+1/EK+oiE52TWxzHmAI?=
 =?us-ascii?Q?7vdiLEjdeyQ/OJwGYpnqU32NVbZq002m4C+EGpQq3+BhUPWauypv+oiqtcBA?=
 =?us-ascii?Q?jVG0pN6UhfgUos/gdgnXhbl4Ge8wFcFzu80xGcLIFTKDzFOYBxT7XjSQAMy5?=
 =?us-ascii?Q?KuCp5qShADmSib6wMqAHAHyhUAP6soyASi1LIoO25HwYubE428gLwhE7rLHs?=
 =?us-ascii?Q?ugnezTQhUpFVY1AhvVCo0G5aYb7amIsOUPKCgZZA+Yew05dTzqXvTZRiLQBB?=
 =?us-ascii?Q?NCaBkAyYaaz5/iB+ec/ZUtElHLrJD/vOKuHyQVapCLnu/7SUUWviPI5Ho167?=
 =?us-ascii?Q?Q8Vu7zgIAa17taSbzvzpGmbY2v9xXsw00BRyPgWnTB7L3tGTrOsA/ISrMCXS?=
 =?us-ascii?Q?qBHEAT4nUe1DLC1G+oKWBqMtQCmbMifvCqfymnp+DSYl6rXP9ZTvAM15IVVc?=
 =?us-ascii?Q?t5VyjQsKUpJBzYrqS33BMuS/fEH88QpPV+9NrNygTsdUTIngmHmpWO8QobGJ?=
 =?us-ascii?Q?YuhDqUd6cNnvAZhMj6n/m2Y4qF3qPNVOxwQ1hTnMOl1qvGwtBWj5x55uc0JT?=
 =?us-ascii?Q?IcwjF0602R6cGgwVaEfEFkHsHxhlgm3Zd8WkX5CrLYXT9B6D9/KRLDONXjIG?=
 =?us-ascii?Q?VutsV3a0A1A45WoAQCRiqqnbC65KsJ7SccTL3nEfTn5Sp/IFjQVolNmp0b7D?=
 =?us-ascii?Q?C7ll7eBtmc47YygmV89ubMAMaIWOUBG0mPsdGT1aO1CpYz1DO34O0gjdvzi/?=
 =?us-ascii?Q?CIyDTEawgBrsF+e3jLpOnjI18tlLj52AhMPD/BEQeAPq2NOKUEK9eqNy2j2n?=
 =?us-ascii?Q?0nniS740Hd7ijxiGvaEZSDONqCFVl+tYZ9h5cRNAraGerwkqZm6IFJqTHb5k?=
 =?us-ascii?Q?96TV5G/cnFCH38xnU41oRX+vnHraV59ojJAVj3p94AWElppPuZVhwKG0MgJR?=
 =?us-ascii?Q?OFDrs5krFGglbbE0kD0g6D9BYdKOAAw6K6856SSmDddWwXLPWsmKelyLJ14q?=
 =?us-ascii?Q?6aTVhrcJkgw0x5xvc0At8BN2CfFjWIaqDaCghBc5B0Wegxd3mF/NqkF3lGCE?=
 =?us-ascii?Q?+H2AGxjrmTs3NldZ6xcw8V4qzYqDF+FxkmzRZc9tz15H7OeV8UMNvjtxpYAb?=
 =?us-ascii?Q?jhqTRw=3D=3D?=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 1d448a7a-64f8-4d3b-f24f-08d9cf014912
X-MS-Exchange-CrossTenant-AuthSource: PH0PR10MB4759.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Jan 2022 21:37:47.9237
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: SCh4Xkc0LdGQVoT8x4wLgy5tODZ2PvPksmgZkEAZ4vsJx+sQLe7mGnd5NbraAyP8Bk8a/nKqdioygYknxyLgK7+8vN5QRWgyW+itAVvK+Uo=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR10MB4469
X-Proofpoint-Virus-Version: vendor=nai engine=6300 definitions=10216 signatures=668683
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 mlxscore=0 bulkscore=0
 spamscore=0 adultscore=0 phishscore=0 mlxlogscore=999 suspectscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2110150000
 definitions=main-2201030147
X-Proofpoint-ORIG-GUID: 7G1htgEEc4OVVXqhEiovV4cpqsUGbDPu
X-Proofpoint-GUID: 7G1htgEEc4OVVXqhEiovV4cpqsUGbDPu
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


Doug,

> sd_read_write_same() seems a strange name for a function given that
> it is checking on WRITE SAME support. How about s/read/report/ ?

It was chosen to be consistent with all the other sd_read_$VPD()
functions. sd_read_cache_type(), sd_read_block_limits(), etc.

> And calling scsi_report_opcode() on INQUIRY seems a weird time waster
> (it actually checks if the SCSI version is < SPC-3 or does the check
> on a _mandatory_ command).

The call to validate INQUIRY is really to check whether REPORT SUPPORTED
OPERATION CODES command is supported.

> And for modern disks scsi_report_opcode() is called 5 times. Why not
> call the REPORT SUPPORTED OPERATION CODES command once and cache its
> result? It would save 4 commands in every disk setup (or
> revalidation).

I have some patches that clean up discovery and start using cached
VPDs. I hadn't thought of caching the RSOC output. Will look into that.

I held this series back since I was concerned about them clashing with
Christoph's recent revalidate changes. I'll get them sent out shortly.

-- 
Martin K. Petersen	Oracle Linux Engineering