From: Kalle Valo <kvalo@kernel.org>
To: <Ajay.Kathat@microchip.com>
Cc: <kuba@kernel.org>, <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'
Date: Thu, 20 Jul 2023 17:50:15 +0300 [thread overview]
Message-ID: <877cqu4oyg.fsf@kernel.org> (raw)
In-Reply-To: <4aef9340-7b03-43af-f211-c8e45f749e73@microchip.com> (Ajay Kathat's message of "Wed, 19 Jul 2023 16:20:57 +0000")
<Ajay.Kathat@microchip.com> writes:
> On 7/19/23 03:37, Kalle Valo wrote:
>
>> Jakub Kicinski <kuba@kernel.org> 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.
'atmel' is only a name, I wouldn't worry about that too much. For
example we still have drivers/net/wireless/ath even though Atheros is
long gone.
> Alternatively, the new device firmware(e.g wilc3000) can be added to
> '/microchip/wilc' without changing wilc1000 firmware path. Is this
> approach okay.
I haven't seen the actual patches but in principle having a new
directory 'microchip/wilc/ in linux-firmare sounds like a good idea to
me. But better to wait for comments from others for a while before
submitting anything.
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
prev parent reply other threads:[~2023-07-20 14:50 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-30 1:22 [PATCH] wifi: wilc1000: change firmware path from 'atmel' to 'microchip/wilc' Ajay.Kathat
2023-07-05 21:03 ` Jakub Kicinski
2023-07-05 21:04 ` Jakub Kicinski
2023-07-06 0:12 ` Ajay.Kathat
2023-07-06 0:27 ` Jakub Kicinski
2023-07-19 10:37 ` Kalle Valo
2023-07-19 16:20 ` Ajay.Kathat
2023-07-20 14:50 ` Kalle Valo [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=877cqu4oyg.fsf@kernel.org \
--to=kvalo@kernel.org \
--cc=Ajay.Kathat@microchip.com \
--cc=Claudiu.Beznea@microchip.com \
--cc=Sripad.Balwadgi@microchip.com \
--cc=kuba@kernel.org \
--cc=linux-wireless@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.