From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3C438EB64DA for ; Thu, 6 Jul 2023 00:28:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232076AbjGFA2J (ORCPT ); Wed, 5 Jul 2023 20:28:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59024 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232490AbjGFA15 (ORCPT ); Wed, 5 Jul 2023 20:27:57 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 215D219A9 for ; Wed, 5 Jul 2023 17:27:57 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id B2B466178D for ; Thu, 6 Jul 2023 00:27:56 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id F1EB1C433C7; Thu, 6 Jul 2023 00:27:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1688603276; bh=pZ5zZNzHJxKbBKdaV7Vr4F3wsYvwnSGwvWeGRxOZPkY=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=aGh1x3K9aIKST/DLmHOfUb55pCEE2+W0uSYlxyXRxbgi6aeAFL/bgDvpytdFgxUpj YOz5fh9cwi8CJFXt40VW4Gr9oyAdMxfio2mbSGHKHJPkUzVc4Gu6wuRFIfuv6rXJ+I eoG7WGPtoCXq6OmEiS5wGxy0KvBZLejcCxD5Wpn6mngCf/pouvUIaz8xPqN9+Cte2C H+4wkyYMpYhRLlqBFWCSZ5mzqrfa1h2NqYne0H5Rnrpz36ku/PrJHN7GvLhIpLzT6k ajmss3gB4yD9SL31NufqTyCieSt+Cr23zPvmTd3zpIgSOCIgUBSjZMNFDpXQHjHssa FAGbdBafJQZ+w== Date: Wed, 5 Jul 2023 17:27:54 -0700 From: Jakub Kicinski To: Cc: , , 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 List-ID: X-Mailing-List: linux-wireless@vger.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.