Re: [PATCH] wifi: wilc1000: change firmware path from 'atmel' to 'microchip/wilc'

[Jakub Kicinski <kuba@kernel.org>]

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.