Linux kernel staging patches
 help / color / mirror / Atom feed
From: Ayush Singh <ayush@beagleboard.org>
To: Dan Carpenter <dan.carpenter@linaro.org>
Cc: Jason Kridner <jkridner@beagleboard.org>,
	Deepak Khatri <lorforlinux@beagleboard.org>,
	Robert Nelson <robertcnelson@beagleboard.org>,
	Dhruva Gole <d-gole@ti.com>, Viresh Kumar <vireshk@kernel.org>,
	Johan Hovold <johan@kernel.org>, Alex Elder <elder@kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	greybus-dev@lists.linaro.org, linux-staging@lists.linux.dev,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] staging: greybus: fw-download: Fix find firmware req
Date: Wed, 22 Oct 2025 19:22:49 +0530	[thread overview]
Message-ID: <81d8d424-ad21-490a-b071-e1b3b3564e2c@beagleboard.org> (raw)
In-Reply-To: <aPjIJw3ahPxnDE5Q@stanley.mountain>


On 10/22/25 5:33 PM, Dan Carpenter wrote:
> On Wed, Oct 22, 2025 at 12:57:57PM +0530, Ayush Singh wrote:
>> diff --git a/drivers/staging/greybus/fw-download.c b/drivers/staging/greybus/fw-download.c
>> index 9a09bd3af79ba0dcf7efa683f4e86246bcd473a5..06f1be8f3121e29551ea8416d5ee2666339b2fe3 100644
>> --- a/drivers/staging/greybus/fw-download.c
>> +++ b/drivers/staging/greybus/fw-download.c
>> @@ -159,7 +159,7 @@ static int exceeds_release_timeout(struct fw_request *fw_req)
>>   
>>   /* This returns path of the firmware blob on the disk */
>>   static struct fw_request *find_firmware(struct fw_download *fw_download,
>> -					const char *tag)
>> +					const char *tag, const char *format)
>>   {
>>   	struct gb_interface *intf = fw_download->connection->bundle->intf;
>>   	struct fw_request *fw_req;
>> @@ -178,10 +178,17 @@ static struct fw_request *find_firmware(struct fw_download *fw_download,
>>   	}
>>   	fw_req->firmware_id = ret;
>>   
>> -	snprintf(fw_req->name, sizeof(fw_req->name),
>> -		 FW_NAME_PREFIX "%08x_%08x_%08x_%08x_%s.tftf",
>> -		 intf->ddbl1_manufacturer_id, intf->ddbl1_product_id,
>> -		 intf->vendor_id, intf->product_id, tag);
>> +	if (strnlen(format, GB_FIRMWARE_FORMAT_MAX_SIZE) == 0) {
> Change this to:
>
> 	if (format[0] == '\0') {
>
> In the caller, the assumption that format is at least
> GB_FIRMWARE_FORMAT_MAX_SIZE makes sense but in this function it
> doesn't make sense.

Ok, will do in the next version.

>> +		snprintf(fw_req->name, sizeof(fw_req->name),
>> +			 FW_NAME_PREFIX "%08x_%08x_%08x_%08x_%s",
>> +			 intf->ddbl1_manufacturer_id, intf->ddbl1_product_id,
>> +			 intf->vendor_id, intf->product_id, tag);
>> +	} else {
>> +		snprintf(fw_req->name, sizeof(fw_req->name),
>> +			 FW_NAME_PREFIX "%08x_%08x_%08x_%08x_%s.%s",
>> +			 intf->ddbl1_manufacturer_id, intf->ddbl1_product_id,
>> +			 intf->vendor_id, intf->product_id, tag, format);
>> +	}
>>   
>>   	dev_info(fw_download->parent, "Requested firmware package '%s'\n",
>>   		 fw_req->name);
>> @@ -225,7 +232,7 @@ static int fw_download_find_firmware(struct gb_operation *op)
>>   	struct gb_fw_download_find_firmware_request *request;
>>   	struct gb_fw_download_find_firmware_response *response;
>>   	struct fw_request *fw_req;
>> -	const char *tag;
>> +	const char *tag, *format;
>>   
>>   	if (op->request->payload_size != sizeof(*request)) {
>>   		dev_err(fw_download->parent,
> We have changed the sizeof(*request) but we haven't changed
> ->payload_size so how can this ever be true?  Did you test this change?


The request originates in greybus node. The payload size here is 
calculate from the greybus message header. It is not a hard coded value. 
So as long as the node sets it correctly, it will work fine.

I am using the zephyr greybus firmware for my testing [2] using a 
BeaglePlay [3] and BeagleConnect Freedom [4].


[2]: https://github.com/Ayush1325/greybus-for-zephyr/pull/46

[3]: https://www.beagleboard.org/boards/beagleplay

[4]: https://www.beagleboard.org/boards/beagleconnect-freedom


>
> regards,
> dan carpenter
>

  reply	other threads:[~2025-10-22 13:52 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-22  7:27 [PATCH] staging: greybus: fw-download: Fix find firmware req Ayush Singh
2025-10-22 12:03 ` Dan Carpenter
2025-10-22 13:52   ` Ayush Singh [this message]
2025-10-22 14:10     ` Dan Carpenter
2025-10-22 14:26       ` Ayush Singh
2025-10-22 14:53         ` Dan Carpenter
2025-10-23  4:57 ` kernel test robot
2025-10-23 10:04 ` Greg Kroah-Hartman
2025-10-23 11:26   ` Ayush Singh
2025-10-24 16:35   ` Alex Elder

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=81d8d424-ad21-490a-b071-e1b3b3564e2c@beagleboard.org \
    --to=ayush@beagleboard.org \
    --cc=d-gole@ti.com \
    --cc=dan.carpenter@linaro.org \
    --cc=elder@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=greybus-dev@lists.linaro.org \
    --cc=jkridner@beagleboard.org \
    --cc=johan@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-staging@lists.linux.dev \
    --cc=lorforlinux@beagleboard.org \
    --cc=robertcnelson@beagleboard.org \
    --cc=vireshk@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox