Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
To:     "Maciej W. Rozycki" <macro@orcam.me.uk>
Cc:     Ondrej Zary <linux@zary.sk>,
        "James E.J. Bottomley" <jejb@linux.ibm.com>,
        "Martin K. Petersen" <martin.petersen@oracle.com>,
        Christoph Hellwig <hch@lst.de>, linux-scsi@vger.kernel.org,
        linux-kernel@vger.kernel.org
References: <alpine.DEB.2.21.2104141244520.44318@angie.orcam.me.uk>
 <a099f7f8-9601-fd1c-03a4-93587e7276e6@gonehiking.org>
 <alpine.DEB.2.21.2104162157360.44318@angie.orcam.me.uk>
 <202104182221.21533.linux@zary.sk>
 <e3fe98a2-c480-e9bf-67b3-7f51b87975bd@gonehiking.org>
 <alpine.DEB.2.21.2104191747010.44318@angie.orcam.me.uk>
 <d7dc08a6-92be-e524-1f11-cd9f7326a0fd@gonehiking.org>
 <alpine.DEB.2.21.2104200456100.44318@angie.orcam.me.uk>
 <b23c0a0e-d95b-b941-1cc2-1a8bcf44401a@gonehiking.org>
 <alpine.DEB.2.21.2104221808170.44318@angie.orcam.me.uk>
From:   Khalid Aziz <khalid@gonehiking.org>
Subject: Re: [PATCH 0/5] Bring the BusLogic host bus adapter driver up to
 Y2021
Message-ID: <0a4d979b-e3f8-959d-fb9a-3a0fcea42141@gonehiking.org>
Date:   Thu, 22 Apr 2021 12:07:07 -0600
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.7.1
MIME-Version: 1.0
In-Reply-To: <alpine.DEB.2.21.2104221808170.44318@angie.orcam.me.uk>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Precedence: bulk

On 4/22/21 10:27 AM, Maciej W. Rozycki wrote:
> On Wed, 21 Apr 2021, Khalid Aziz wrote:
> 
>>>  Verifying actual ISA operations (third-party DMA, etc.) cannot be made 
>>> this way, but as I understand the issue there is merely with passing data 
>>> structures around and that may not require too much attention beyond 
>>> getting things syntactically correct, which I gather someone forgot to do 
>>> with a change made a while ago.  So that should be doable as well.
>>
>> In theory this sounds reasonable, but without being able to test with a
>> real hardware I would be concerned about making this change.
> 
>  Sometimes you have little choice really and that would be less disruptive 
> than dropping support altogether.  Even if there's a small issue somewhere 
> it's easier to fix by a competent developer who actually gets the hands on 
> a piece of hardware than bringing back old code that has been removed and 
> consequently not updated according to internal API evolution, etc.

We are talking about removing support for BT-445S with firmware version
older than 3.37. That is a very specific case. To continue support for
this very specific case, we have to add new code to use local bounce
buffer and we have no hardware to verify this new code. This will be new
code whether we add it now or later after we find someone even has this
very old card with old firmware. I would prefer to remove support for
now and add new code to add support for firmware version older than 3.37
back only if there is a need later. For now anyone who is using a
BT-445S and has updated firmware on their card will not see a change.

--
Khalid