[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b4f3bbb10b9e21b439e52c0f941809ca6f567bca.camel@wdc.com>
Date: Fri, 6 Jul 2018 17:01:00 +0000
From: Bart Van Assche <Bart.VanAssche@....com>
To: "jthumshirn@...e.de" <jthumshirn@...e.de>
CC: "linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"RaghavaAditya.Renukunta@...rosemi.com"
<RaghavaAditya.Renukunta@...rosemi.com>,
"david.carroll@...rosemi.com" <david.carroll@...rosemi.com>,
"martin.petersen@...cle.com" <martin.petersen@...cle.com>
Subject: Re: [PATCH 1/4] scsi: aacraid: remove AAC_STAT_GOOD define
On Fri, 2018-07-06 at 10:04 +0200, Johannes Thumshirn wrote:
> On Thu, Jul 05, 2018 at 05:24:23PM +0000, Bart Van Assche wrote:
> > On Thu, 2018-07-05 at 13:01 +0200, Johannes Thumshirn wrote:
> > > if (((aac_cache & 6) == 6) && dev->cache_protected) {
> > > - scsicmd->result = AAC_STAT_GOOD;
> > > + scsicmd->result = DID_OK << 16 | COMMAND_COMPLETE << 8 |
> > > + SAM_STAT_GOOD;
> >
> > Does AAC_STAT_GOOD really have to be expanded in full multiple times?
> > Have you considered to replace AAC_STAT_GOOD by the numerical constant
> > 0 instead?
>
> This won't work anymore once we start splitting ->result into 4
> unrelated enums. That's why I prefer this way.
That explanation does not make sense to me. There is plenty of code in
the upstream kernel that assigns zero to .result, so you will have to
deal with that pattern anyway.
Bart.
Powered by blists - more mailing lists