On Thu, 6 Jul 2023 00:12:32 +0000 Ajay.Kathat@xxxxxxxxxxxxx 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@xxxxxxxxxxxxx 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.
