Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Wed, 5 Jul 2023 17:27:54 -0700
From:   Jakub Kicinski <kuba@kernel.org>
To:     <Ajay.Kathat@microchip.com>
Cc:     <linux-wireless@vger.kernel.org>, <Claudiu.Beznea@microchip.com>,
        <Sripad.Balwadgi@microchip.com>
Subject: Re: [PATCH] wifi: wilc1000: change firmware path from 'atmel' to
 'microchip/wilc'
Message-ID: <20230705172754.61ca21ae@kernel.org>
In-Reply-To: <5500a007-4e52-f8dc-2535-3baa7decfe52@microchip.com>
References: <20230630012136.1330784-1-ajay.kathat@microchip.com>
        <20230705140338.77896d11@kernel.org>
        <5500a007-4e52-f8dc-2535-3baa7decfe52@microchip.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Precedence: bulk

On Thu, 6 Jul 2023 00:12:32 +0000 Ajay.Kathat@microchip.com wrote:
> On 7/5/23 14:03, Jakub Kicinski wrote:
> > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> > 
> > On Fri, 30 Jun 2023 01:22:31 +0000 Ajay.Kathat@microchip.com wrote:  
> >> To inline the linux-firmware path with driver, the firmware path is changed
> >> from 'atmel' to 'microchip/wilc'. This path change will be submitted to
> >> 'linux-firmware' as well.  
> > 
> > How are you going to make this backward compatible?
> > Users aren't required to update linux-firmware and kernel at the same
> > time.  
> 
> Thanks for pointing it out.
> 
> I think, the changes are not fully compatible for upgrading the kernel
> and 'linux-firmware' individually. After the driver changes, the
> 'linux-firmware' upgrade is necessary.
> 
> The kernel and 'linux-firmware' can be upgraded independently, so two
> combinations are possible for the upgrade.
> 
> updated driver : uses modified path(microchip/wilc) to load FW.
> updated 'linux-firmware': FW file is at modified path(microchip/wilc)
> 
> 1. updated driver + old 'linux-firmware' : incompatible

Ah, totally missed that combination.

>   - The updated driver will look for FW file in '/microchip/wilc' path
> which is not present in older 'linux-firmware'. Though the interface
> format is compatible, the driver will fail to load it because the file
> is not present.
> 
> 
> 2. old driver + updated 'linux-firmware': compatible
>   - A link is created from new path to old FW path so the old driver
> should be able to load from linked path.
> 
> In order to address scenario#1, a fallback method that loads the FW from
> the older path(/atmel) can be added in the driver. I think that change
> will make it compatible for scenario#1.
> Please suggest, if there is a generic/recommended approach to handle
> backward compatibility for FW path change.

I'm afraid you need to request from both new and old patch for some
time. Push the change to linux-firmware, but make driver be compatible
with both for maybe three full releases? Then the risk of someone still
having stale linux-firmware goes down quite a bit.

TBH renaming FW paths, much like renaming drivers is usually more risk
than reward.