All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kalle Valo <kvalo@kernel.org>
To: Jeffrey Hugo <quic_jhugo@quicinc.com>
Cc: <mhi@lists.linux.dev>,  <ath11k@lists.infradead.org>,
	 <linux-wireless@vger.kernel.org>
Subject: Re: [PATCH 1/3] mhi: allow MHI client drivers to provide the firmware via a pointer
Date: Thu, 12 Jan 2023 11:19:21 +0200	[thread overview]
Message-ID: <87bkn4ds9y.fsf@kernel.org> (raw)
In-Reply-To: <7d692402-3fc1-3b4c-9697-25e722e94539@quicinc.com> (Jeffrey Hugo's message of "Wed, 11 Jan 2023 08:20:34 -0700")

Jeffrey Hugo <quic_jhugo@quicinc.com> writes:

> On 1/11/2023 2:25 AM, Kalle Valo wrote:
>> From: Kalle Valo <quic_kvalo@quicinc.com>
>>
>> Currently MHI loads the firmware image from the path provided by client
>> devices. ath11k needs to support firmware image embedded along with meta data
>> (named as firmware-2.bin). So allow the client driver to request the firmware
>> file from user space on it's own and provide the firmware image data and size
>> to MHI via a pointer struct mhi_controller::fw_data.
>>
>> This is an optional feature, if fw_data is NULL MHI load the firmware using the
>> name from struct mhi_controller::fw_image string as before.
>>
>> Tested with ath11k and WCN6855 hw2.0.
>>
>> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>

[...]

>> @@ -478,14 +489,14 @@ void mhi_fw_load_handler(struct mhi_controller *mhi_cntrl)
>>   	 */
>>   	if (mhi_cntrl->fbc_download) {
>>   		ret = mhi_alloc_bhie_table(mhi_cntrl, &mhi_cntrl->fbc_image,
>> -					   firmware->size);
>> +					   fw_sz);
>
> Minor nit, but it seems like this could be all on one line.

Will fix in v2.

>> --- a/include/linux/mhi.h
>> +++ b/include/linux/mhi.h
>> @@ -299,6 +299,10 @@ struct mhi_controller_config {
>>    * @iova_start: IOMMU starting address for data (required)
>>    * @iova_stop: IOMMU stop address for data (required)
>>    * @fw_image: Firmware image name for normal booting (optional)
>> + * @fw_data: Firmware image data content for normal booting, used only
>> + *           if fw_image is NULL (optional)
>
> The implementation requires fbc_download to be set, which is not a
> requirement for fw_image.  That is not apparent here.

Ah, I had missed that. Will mention that in v2.

>> @@ -384,6 +388,8 @@ struct mhi_controller {
>>   	dma_addr_t iova_start;
>>   	dma_addr_t iova_stop;
>>   	const char *fw_image;
>> +	const u8 *fw_data;
>> +	size_t fw_sz;
>
> Did you run pahole?  I remember this struct being well packed, and I
> think this will add a compiler hole but I have not actually verified.

I actually haven't used pahole for ages. I will run it and check how
this structure is packed.

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

-- 
ath11k mailing list
ath11k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath11k

WARNING: multiple messages have this Message-ID (diff)
From: Kalle Valo <kvalo@kernel.org>
To: Jeffrey Hugo <quic_jhugo@quicinc.com>
Cc: <mhi@lists.linux.dev>,  <ath11k@lists.infradead.org>,
	 <linux-wireless@vger.kernel.org>
Subject: Re: [PATCH 1/3] mhi: allow MHI client drivers to provide the firmware via a pointer
Date: Thu, 12 Jan 2023 11:19:21 +0200	[thread overview]
Message-ID: <87bkn4ds9y.fsf@kernel.org> (raw)
In-Reply-To: <7d692402-3fc1-3b4c-9697-25e722e94539@quicinc.com> (Jeffrey Hugo's message of "Wed, 11 Jan 2023 08:20:34 -0700")

Jeffrey Hugo <quic_jhugo@quicinc.com> writes:

> On 1/11/2023 2:25 AM, Kalle Valo wrote:
>> From: Kalle Valo <quic_kvalo@quicinc.com>
>>
>> Currently MHI loads the firmware image from the path provided by client
>> devices. ath11k needs to support firmware image embedded along with meta data
>> (named as firmware-2.bin). So allow the client driver to request the firmware
>> file from user space on it's own and provide the firmware image data and size
>> to MHI via a pointer struct mhi_controller::fw_data.
>>
>> This is an optional feature, if fw_data is NULL MHI load the firmware using the
>> name from struct mhi_controller::fw_image string as before.
>>
>> Tested with ath11k and WCN6855 hw2.0.
>>
>> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>

[...]

>> @@ -478,14 +489,14 @@ void mhi_fw_load_handler(struct mhi_controller *mhi_cntrl)
>>   	 */
>>   	if (mhi_cntrl->fbc_download) {
>>   		ret = mhi_alloc_bhie_table(mhi_cntrl, &mhi_cntrl->fbc_image,
>> -					   firmware->size);
>> +					   fw_sz);
>
> Minor nit, but it seems like this could be all on one line.

Will fix in v2.

>> --- a/include/linux/mhi.h
>> +++ b/include/linux/mhi.h
>> @@ -299,6 +299,10 @@ struct mhi_controller_config {
>>    * @iova_start: IOMMU starting address for data (required)
>>    * @iova_stop: IOMMU stop address for data (required)
>>    * @fw_image: Firmware image name for normal booting (optional)
>> + * @fw_data: Firmware image data content for normal booting, used only
>> + *           if fw_image is NULL (optional)
>
> The implementation requires fbc_download to be set, which is not a
> requirement for fw_image.  That is not apparent here.

Ah, I had missed that. Will mention that in v2.

>> @@ -384,6 +388,8 @@ struct mhi_controller {
>>   	dma_addr_t iova_start;
>>   	dma_addr_t iova_stop;
>>   	const char *fw_image;
>> +	const u8 *fw_data;
>> +	size_t fw_sz;
>
> Did you run pahole?  I remember this struct being well packed, and I
> think this will add a compiler hole but I have not actually verified.

I actually haven't used pahole for ages. I will run it and check how
this structure is packed.

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

  reply	other threads:[~2023-01-12  9:19 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-11  9:25 [PATCH 0/3] ath11k: support firmware-2.bin Kalle Valo
2023-01-11  9:25 ` Kalle Valo
2023-01-11  9:25 ` [PATCH 1/3] mhi: allow MHI client drivers to provide the firmware via a pointer Kalle Valo
2023-01-11  9:25   ` Kalle Valo
2023-01-11 15:20   ` Jeffrey Hugo
2023-01-11 15:20     ` Jeffrey Hugo
2023-01-12  9:19     ` Kalle Valo [this message]
2023-01-12  9:19       ` Kalle Valo
2023-03-08 13:20       ` Kalle Valo
2023-03-08 13:20         ` Kalle Valo
2023-03-13 14:04         ` Jeffrey Hugo
2023-03-13 14:04           ` Jeffrey Hugo
2023-01-11  9:25 ` [PATCH 2/3] ath11k: qmi: refactor ath11k_qmi_m3_load() Kalle Valo
2023-01-11  9:25   ` Kalle Valo
2023-01-11  9:25 ` [PATCH 3/3] ath11k: add firmware-2.bin support Kalle Valo
2023-01-11  9:25   ` Kalle Valo

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=87bkn4ds9y.fsf@kernel.org \
    --to=kvalo@kernel.org \
    --cc=ath11k@lists.infradead.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=mhi@lists.linux.dev \
    --cc=quic_jhugo@quicinc.com \
    /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.