On 7/19/23 03:37, Kalle Valo wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe > > Jakub Kicinski <kuba@xxxxxxxxxx> writes: > >>> 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. > > I would say at least minimum of two years, preferably more to make it > possible to upgrade kernel on LTS distro releases. > >> TBH renaming FW paths, much like renaming drivers is usually more risk >> than reward. > > I agree, it's just extra work without no actually benefit. Maybe an > exception here is iwlwifi, that should be fixed as that clutters the top > level firmware directory with dozens of files: > Definitely, this change will not have any functionality improvements. It will just help to organize the wilc firmware directory structure. Currently, only wilc1000 firmwares are present in linux-firmware but the work to support wilc3000 and wilc's next-gen device is in progress. The existing wilc driver will be extended and the new firmware files needs to be added to linux-firmware. After this change, the all firmware's can organized under same root directory since adding a new device firmware's under 'atmel' folder may not make sense. Alternatively, the new device firmware(e.g wilc3000) can be added to '/microchip/wilc' without changing wilc1000 firmware path. Is this approach okay. Regards, Ajay
