[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20180102.135836.317444223426222615.davem@davemloft.net>
Date: Tue, 02 Jan 2018 13:58:36 -0500 (EST)
From: David Miller <davem@...emloft.net>
To: Tomer.Tayar@...ium.com
Cc: netdev@...r.kernel.org, linux-rdma@...r.kernel.org,
linux-scsi@...r.kernel.org
Subject: Re: [PATCH v4 net-next 0/4] qed*: Advance to FW 8.33.1.0
From: Tomer Tayar <Tomer.Tayar@...ium.com>
Date: Wed, 27 Dec 2017 19:30:04 +0200
> This series advances all qed* drivers to use firmware 8.33.1.0 which brings
> new capabilities and initial support of new HW. The changes are mostly in
> qed, and include changes in the FW interface files, as well as updating the
> FW initialization and debug collection code. The protocol drivers have
> minor functional changes for this firmware.
>
> Patch 1 Rearranges and refactors the FW interface files in preparation of
> the new FW (no functional change).
> Patch 2 Prepares the code for support of new HW (no functional change).
> Patch 3 Actual utilization of the new FW.
> Patch 4 Advances drivers' version.
>
> v3->v4:
> Fix a compilation issue which was reported by krobot (dependency on CRC8).
>
> v2->v3:
> Resend the series with a fixed title in the cover letter.
>
> v1->v2:
> - Break the previous single patch into several patches.
> - Fix compilation issues which were reported by krobot.
I'm going to apply this, however....
These firmware update changes are rediculously invasive.
Backporting patches through these updates will be a giant task if not
impossible for anyone who tries to do something like this.
Who reviewed these changes outside of Cavium to look for clerical
and typographical errors? I be nobody did. I personally scanned
them for about 20 minutes.
Therefore, it is my judgment that the way firmware support updates are
done in the QED driver is detrimental to it's long term
maintainability.
Thank you.
Powered by blists - more mailing lists