All of lore.kernel.org
 help / color / mirror / Atom feed
From: Simon Horman <horms@kernel.org>
To: Lorenzo Bianconi <lorenzo@kernel.org>
Cc: Andrew Lunn <andrew+netdev@lunn.ch>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>,
	netdev@vger.kernel.org, devicetree@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-mediatek@lists.infradead.org
Subject: Re: [PATCH net-next v3 2/3] net: airoha: npu: Add airoha_npu_soc_data struct
Date: Tue, 14 Oct 2025 14:46:09 +0100	[thread overview]
Message-ID: <20251014134609.GA3239414@horms.kernel.org> (raw)
In-Reply-To: <aO4WmeuoAcZLFSBo@lore-desk>

On Tue, Oct 14, 2025 at 11:23:37AM +0200, Lorenzo Bianconi wrote:
> > On Mon, Oct 13, 2025 at 03:58:50PM +0200, Lorenzo Bianconi wrote:
> > 
> > ...
> > 
> > > @@ -182,49 +192,53 @@ static int airoha_npu_send_msg(struct airoha_npu *npu, int func_id,
> > >  	return ret;
> > >  }
> > >  
> > > -static int airoha_npu_run_firmware(struct device *dev, void __iomem *base,
> > > -				   struct resource *res)
> > > +static int airoha_npu_load_firmware(struct device *dev, void __iomem *addr,
> > > +				    const struct airoha_npu_fw *fw_info)
> > >  {
> > >  	const struct firmware *fw;
> > > -	void __iomem *addr;
> > >  	int ret;
> > >  
> > > -	ret = request_firmware(&fw, NPU_EN7581_FIRMWARE_RV32, dev);
> > > +	ret = request_firmware(&fw, fw_info->name, dev);
> > >  	if (ret)
> > >  		return ret == -ENOENT ? -EPROBE_DEFER : ret;
> > >  
> > > -	if (fw->size > NPU_EN7581_FIRMWARE_RV32_MAX_SIZE) {
> > > +	if (fw->size > fw_info->max_size) {
> > >  		dev_err(dev, "%s: fw size too overlimit (%zu)\n",
> > > -			NPU_EN7581_FIRMWARE_RV32, fw->size);
> > > +			fw_info->name, fw->size);
> > >  		ret = -E2BIG;
> > >  		goto out;
> > >  	}
> > >  
> > > -	addr = devm_ioremap_resource(dev, res);
> > > -	if (IS_ERR(addr)) {
> > > -		ret = PTR_ERR(addr);
> > > -		goto out;
> > > -	}
> > > -
> > >  	memcpy_toio(addr, fw->data, fw->size);
> > > +out:
> > >  	release_firmware(fw);
> > >  
> > > -	ret = request_firmware(&fw, NPU_EN7581_FIRMWARE_DATA, dev);
> > > -	if (ret)
> > > -		return ret == -ENOENT ? -EPROBE_DEFER : ret;
> > > +	return ret;
> > > +}
> > >  
> > > -	if (fw->size > NPU_EN7581_FIRMWARE_DATA_MAX_SIZE) {
> > > -		dev_err(dev, "%s: fw size too overlimit (%zu)\n",
> > > -			NPU_EN7581_FIRMWARE_DATA, fw->size);
> > > -		ret = -E2BIG;
> > > -		goto out;
> > > -	}
> > > +static int airoha_npu_run_firmware(struct device *dev, void __iomem *base,
> > > +				   struct resource *res)
> > > +{
> > > +	const struct airoha_npu_soc_data *soc;
> > > +	void __iomem *addr;
> > > +	int ret;
> > >  
> > > -	memcpy_toio(base + REG_NPU_LOCAL_SRAM, fw->data, fw->size);
> > > -out:
> > > -	release_firmware(fw);
> > > +	soc = of_device_get_match_data(dev);
> > > +	if (!soc)
> > > +		return -EINVAL;
> > >  
> > > -	return ret;
> > > +	addr = devm_ioremap_resource(dev, res);
> > > +	if (IS_ERR(addr))
> > > +		return PTR_ERR(addr);
> > > +
> > > +	/* Load rv32 npu firmware */
> > > +	ret = airoha_npu_load_firmware(dev, addr, &soc->fw_rv32);
> > > +	if (ret)
> > > +		return ret;
> > > +
> > > +	/* Load data npu firmware */
> > > +	return airoha_npu_load_firmware(dev, base + REG_NPU_LOCAL_SRAM,
> > > +					&soc->fw_data);
> > 
> > Hi Lorenzo,
> 
> Hi Simon,
> 
> > 
> > There are two calls to airoha_npu_load_firmware() above.
> > And, internally, airoha_npu_load_firmware() will call release_firmware()
> > if an error is encountered.
> > 
> > But should release_firmware() be called for the firmware requested
> > by the first call to airoha_npu_load_firmware() if the second call fails?
> > Such clean-up seems to have been the case prior to this patch.
> 
> release_firmware() is intended to release the resources allocated by the
> corresponding call to request_firmware() in airoha_npu_load_firmware().
> According to my understanding we always run release_firmware() in
> airoha_npu_load_firmware() before returning to the caller. Even before this
> patch we run release_firmware() on the 'first' firmware image before requesting
> the second one. Am I missing something?
> 
> > 
> > Also, not strictly related. Should release_firmware() be called (twice)
> > when the driver is removed?
> 
> For the above reasons, it is not important to call release_firmware() removing
> the module. Agree?

Thanks, agreed.

For some reason I missed that release_firmware() is called in
airoha_npu_load_firmware() regardless of error - I thought it was only
in error paths for some reason.

So I agree that the firmware is always released by the time
airoha_npu_load_firmware() is returned. As thus there is never
a need to release it afterwards.

Reviewed-by: Simon Horman <horms@kernel.org>




  reply	other threads:[~2025-10-14 13:46 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-13 13:58 [PATCH net-next v3 0/3] net: airoha: npu: Introduce support for Airoha 7583 NPU Lorenzo Bianconi
2025-10-13 13:58 ` [PATCH net-next v3 1/3] dt-bindings: net: airoha: npu: Add AN7583 support Lorenzo Bianconi
2025-10-13 13:58 ` [PATCH net-next v3 2/3] net: airoha: npu: Add airoha_npu_soc_data struct Lorenzo Bianconi
2025-10-14  8:34   ` Simon Horman
2025-10-14  9:23     ` Lorenzo Bianconi
2025-10-14 13:46       ` Simon Horman [this message]
2025-10-14 13:52         ` Lorenzo Bianconi
2025-10-13 13:58 ` [PATCH net-next v3 3/3] net: airoha: npu: Add 7583 SoC support Lorenzo Bianconi
2025-10-14  8:35   ` Simon Horman
2025-10-16  1:00 ` [PATCH net-next v3 0/3] net: airoha: npu: Introduce support for Airoha 7583 NPU patchwork-bot+netdevbpf

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=20251014134609.GA3239414@horms.kernel.org \
    --to=horms@kernel.org \
    --cc=andrew+netdev@lunn.ch \
    --cc=conor+dt@kernel.org \
    --cc=davem@davemloft.net \
    --cc=devicetree@vger.kernel.org \
    --cc=edumazet@google.com \
    --cc=krzk+dt@kernel.org \
    --cc=kuba@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=lorenzo@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=robh@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.