All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Maciej W. Rozycki" <macro@orcam.me.uk>
To: "Martin K. Petersen" <martin.petersen@oracle.com>
Cc: Douglas Gilbert <dgilbert@interlog.com>,
	Khalid Aziz <khalid@gonehiking.org>,
	"James E.J. Bottomley" <jejb@linux.ibm.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
Date: Tue, 4 Jan 2022 13:52:47 +0000 (GMT)	[thread overview]
Message-ID: <alpine.DEB.2.21.2201032324230.56863@angie.orcam.me.uk> (raw)
In-Reply-To: <yq1tuek347m.fsf@ca-mkp.ca.oracle.com>

Martin,

> >  So I do have all the reasons to conclude this value has indeed been 
> > arbitrarily chosen, don't I?
> 
> The SAT spec defines the contents of the first part of the page. The
> trailing 512 bytes are defined in the ATA spec.

 I think that would best be reflected in code somehow as lone `64' doesn't 
say anything really.

> > If you insist that the value of 64 stay, then please come up with a
> > suitable macro name to define along with SCSI_VPD_PG_LEN that reflects
> > the meaning of 64 in this context and I'll be happy to update 3/3
> > accordingly, but please explain why the value of 64 is any better than
> > 255 here and the inconsistency with the buffer size justified.
> 
> Can please you try the following patch?

 I have tried it and it's neutral, that is with 1/3 applied the HBA still 
works and with 1/3 removed it still breaks (2/3 and 3/3 obviously don't 
build anymore).  Unsurprisingly, as it's the call to `scsi_get_vpd_page' 
rather than `scsi_get_vpd_buf' that causes an issue here.

 I think the latter function isn't called in my setup, and it's not clear 
to me anymore after so long why I didn't poke at it.  It looks to me like 
the `retry_pg' code there can be gone now with your update in place as it 
duplicates buffer sizing, and with that included it'll be a nice clean-up.

 NB you'll need to adjust drivers/scsi/mpt3sas/mpt3sas_scsih.c accordingly 
if we are to move forward with this change, as it's another user of the 
SCSI_VPD_PG_LEN macro.

 Given what has been said in the discussion so far would you consider 2/3
and 3/3 unnecessary?  In the course of verifying your change I have looked 
through our code again and found that inline magic numbers are there in 
several though not all places where `scsi_get_vpd_page' gets called, so I 
think it would make sense to get rid of them all at once with a single 
self-contained change.

 Thank you for your input and the extra fix.

  Maciej

  reply	other threads:[~2022-01-04 13:52 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-02 23:23 [PATCH v3 0/3] Bring the BusLogic host bus adapter driver up to Y2021 Maciej W. Rozycki
2022-01-02 23:23 ` [PATCH v3 1/3] scsi: Provide for avoiding trailing allocation length with VPD inquiries Maciej W. Rozycki
2022-01-03  8:23   ` Christoph Hellwig
2022-01-04 16:39     ` Khalid Aziz and Shuah Khan
2022-01-04 17:20     ` Maciej W. Rozycki
2022-01-02 23:23 ` [PATCH v3 2/3] scsi: Avoid using reserved length byte " Maciej W. Rozycki
2022-01-02 23:23 ` [PATCH v3 3/3] scsi: Set allocation length to 255 for ATA Information VPD page Maciej W. Rozycki
2022-01-03  4:09   ` Douglas Gilbert
2022-01-03 21:06     ` Maciej W. Rozycki
2022-01-03 21:28       ` Martin K. Petersen
2022-01-04 13:52         ` Maciej W. Rozycki [this message]
2022-01-04 17:57           ` Martin K. Petersen
2022-01-06  4:13             ` Martin K. Petersen
2022-01-06  5:21               ` Damien Le Moal
2022-01-07 14:07                 ` Martin K. Petersen
2022-01-07 10:36               ` Maciej W. Rozycki
2022-01-07 14:03                 ` Martin K. Petersen
2022-01-10 12:00                   ` Maciej W. Rozycki
2022-01-10 15:48                     ` Martin K. Petersen
2022-01-03 21:37     ` Martin K. Petersen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.DEB.2.21.2201032324230.56863@angie.orcam.me.uk \
    --to=macro@orcam.me.uk \
    --cc=dgilbert@interlog.com \
    --cc=hch@lst.de \
    --cc=jejb@linux.ibm.com \
    --cc=khalid@gonehiking.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=nix@esperi.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.