From: Manikanta Pubbisetty <quic_mpubbise@quicinc.com>
To: Kalle Valo <kvalo@kernel.org>
Cc: <ath11k@lists.infradead.org>, <linux-wireless@vger.kernel.org>,
<devicetree@vger.kernel.org>, <robh@kernel.org>
Subject: Re: [PATCH v2 02/19] ath11k: Refactor PCI code to support hybrid bus devices
Date: Tue, 8 Mar 2022 11:30:51 +0530 [thread overview]
Message-ID: <d7884804-6bc2-058b-c373-8b2005fd2811@quicinc.com> (raw)
In-Reply-To: <41f8fd92-70e4-def6-0bd1-c764b1445d68@quicinc.com>
On 2/25/2022 11:20 AM, Manikanta Pubbisetty wrote:
> On 1/28/2022 3:46 PM, Kalle Valo wrote:
>> Manikanta Pubbisetty <quic_mpubbise@quicinc.com> writes:
>>
>>> Unlike other ATH11K PCIe devices which are enumerated by APSS
>>> processor (Application Processor SubSystem), WCN6750 gets
>>> enumerated by the WPSS Q6 processor (Wireless Processor SubSystem);
>>> In simple terms, though WCN6750 is PCIe device, it is not attached
>>> to the APSS processor, APSS will not know of such a device being
>>> present in the system and therefore WCN6750 will be registered as
>>> a platform device to the kernel core like other supported AHB
>>> devices.
>>>
>>> WCN6750 uses both AHB and PCI APIs for it's operation, it uses
>>> AHB APIs for device probe/boot and PCI APIs for device setup
>>> and register accesses; Because of this nature, it is referred
>>> as a hybrid bus device.
>>>
>>> Refactor PCI code to support hybrid bus devices like WCN6750.
>>>
>>> Tested-on: WCN6750 hw1.0 AHB WLAN.MSL.1.0.1-00573-QCAMSLSWPLZ-1
>>> Tested-on: WCN6855 hw2.0 PCI
>>> WLAN.HSP.1.1-01720.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1
>>> Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.5.0.1-01100-QCAHKSWPL_SILICONZ-1
>>> Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.4.0.1-00192-QCAHKSWPL_SILICONZ-1
>>>
>>> Signed-off-by: Manikanta Pubbisetty <quic_mpubbise@quicinc.com>
>>
>> [...]
>>
>>> --- a/drivers/net/wireless/ath/ath11k/Makefile
>>> +++ b/drivers/net/wireless/ath/ath11k/Makefile
>>> @@ -29,7 +29,7 @@ obj-$(CONFIG_ATH11K_AHB) += ath11k_ahb.o
>>> ath11k_ahb-y += ahb.o
>>> obj-$(CONFIG_ATH11K_PCI) += ath11k_pci.o
>>> -ath11k_pci-y += mhi.o pci.o
>>> +ath11k_pci-y += mhi.o pci.o pci_cmn.o
>>
>> So the end result looks like this:
>>
>> obj-$(CONFIG_ATH11K_AHB) += ath11k_ahb.o
>> ath11k_ahb-y += ahb.o pci_cmn.o
>>
>> obj-$(CONFIG_ATH11K_PCI) += ath11k_pci.o
>> ath11k_pci-y += mhi.o pci.o pci_cmn.o
>>
>> Linking pci_cmn.o to both ath11k_pci.ko and ath11k_ahb.ko looks wrong.
>> Does that even compile if ath11k is linked to the kernel, eg. with
>> allyesconfig?
>>
>
> I did try compiling the kernel with allyesconfig after your comment,
> compilation went through without any hiccups.
>
>> One way to solve is to link pci_cmn.o to ath11k.ko. But for another
>> approach, for a long time I have been thinking about what's the point to
>> have separate ath11k_pci.ko and ath11k_ahb.ko modules?,They are very
>> small anyway compared to ath11k.ko. So my ideais that should we have
>> just one ath11k.ko module, it contains all AHB and PCI code as well, and
>> ath11k_pci.ko and ath11k_ahb.ko would not be created anymore. It would
>> simplify things a bit, especially here.
>>
>> Thoughts?
>>
>
> I see some concerns going with single module combining both AHB and PCI
> modules into ath11k.ko
>
> 1) AHB and PCI drivers make use of completely different kernel
> frameworks, for example AHB driver needs remoteproc APIs for booting and
> require CONFIG_REMOTEPROC to be compiled in to the kernel. Similarly,
> PCI driver needs MHI APIs and also dependent on CONFIG_PCI. Both MHI and
> PCI bus frameworks need to be compiled for PCI to work. If we club all
> of this into single module, I see that unnecessarily additional modules
> will be compiled into the kernel which IMO is not so good idea.
>
>
> 2) Secondly, there is high chance of writing bad code all over the
> driver. For example, there are chances that developers put AHB/PCI
> specific code all over the driver creating a big mess.
> Though this can be avoided with stringent code review, but why to
> give the chance.
>
> Though AHB and PCI drivers are smaller in size, IMHO let AHB and PCI be
> independent drivers, code looks cleaner and properly segregated by
> keeping them as it is today.
>
> Regarding the compilation of PCI common code, shall we move it into
> ath11k.ko? What is your opinion on this.
>
Hi Kalle,
Any thoughts about the idea proposed?
Thanks,
Manikanta
next prev parent reply other threads:[~2022-03-08 6:15 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-16 12:46 [PATCH v2 00/19] add support for WCN6750 Manikanta Pubbisetty
2022-01-16 12:46 ` [PATCH v2 01/19] ath11k: PCI changes to support WCN6750 Manikanta Pubbisetty
2022-01-16 12:46 ` [PATCH v2 02/19] ath11k: Refactor PCI code to support hybrid bus devices Manikanta Pubbisetty
2022-01-28 10:16 ` Kalle Valo
2022-02-25 5:50 ` Manikanta Pubbisetty
2022-03-08 6:00 ` Manikanta Pubbisetty [this message]
2022-01-28 12:13 ` Kalle Valo
2022-02-21 8:04 ` Manikanta Pubbisetty
2022-02-21 9:19 ` Kalle Valo
2022-02-21 10:19 ` Manikanta Pubbisetty
2022-01-16 12:46 ` [PATCH v2 03/19] ath11k: Choose MSI config based on HW revision Manikanta Pubbisetty
2022-01-16 12:47 ` [PATCH v2 04/19] ath11k: Refactor MSI logic Manikanta Pubbisetty
2022-01-16 12:47 ` [PATCH v2 05/19] ath11k: Remove core PCI references from PCI common code Manikanta Pubbisetty
2022-01-28 10:20 ` Kalle Valo
2022-01-28 10:37 ` Kalle Valo
2022-02-21 7:07 ` Manikanta Pubbisetty
2022-02-21 9:21 ` Kalle Valo
2022-02-21 6:55 ` Manikanta Pubbisetty
2022-02-21 9:17 ` Kalle Valo
2022-02-21 10:08 ` Manikanta Pubbisetty
2022-01-16 12:47 ` [PATCH v2 06/19] ath11k: Add HW params for WCN6750 Manikanta Pubbisetty
2022-01-16 12:47 ` [PATCH v2 07/19] ath11k: Add bus " Manikanta Pubbisetty
2022-01-16 12:47 ` [PATCH v2 08/19] ath11k: Add register access logic " Manikanta Pubbisetty
2022-01-16 12:47 ` [PATCH v2 09/19] ath11k: Fetch device information via QMI " Manikanta Pubbisetty
2022-01-16 12:47 ` [PATCH v2 10/19] ath11k: Add QMI changes " Manikanta Pubbisetty
2022-01-28 10:50 ` Kalle Valo
2022-02-21 8:02 ` Manikanta Pubbisetty
2022-01-16 12:47 ` [PATCH v2 11/19] ath11k: HAL changes to support WCN6750 Manikanta Pubbisetty
2022-01-16 12:47 ` [PATCH v2 12/19] ath11k: Datapath " Manikanta Pubbisetty
2022-04-27 5:32 ` Kalle Valo
2022-04-27 5:37 ` Manikanta Pubbisetty
2022-04-27 5:48 ` Kalle Valo
2022-04-27 5:56 ` Manikanta Pubbisetty
2022-04-29 8:56 ` Kalle Valo
2022-01-16 12:47 ` [PATCH v2 13/19] ath11k: Fix RX de-fragmentation issue on WCN6750 Manikanta Pubbisetty
2022-01-16 12:47 ` [PATCH v2 14/19] ath11k: Do not put HW in DBS mode for WCN6750 Manikanta Pubbisetty
2022-01-16 12:47 ` [PATCH v2 15/19] ath11k: WMI changes to support WCN6750 Manikanta Pubbisetty
2022-01-16 12:47 ` [PATCH v2 16/19] ath11k: Update WBM idle ring HP after FW mode on Manikanta Pubbisetty
2022-01-16 12:47 ` [PATCH v2 17/19] ath11k: Add support for WCN6750 device Manikanta Pubbisetty
2022-01-16 12:47 ` [PATCH v2 18/19] ath11k: Add support for targets without trustzone Manikanta Pubbisetty
2022-01-28 10:42 ` Kalle Valo
2022-02-21 8:00 ` Manikanta Pubbisetty
2022-01-16 12:47 ` [PATCH v2 19/19] dt: bindings: net: add bindings of WCN6750 for ath11k Manikanta Pubbisetty
2022-01-28 10:39 ` Kalle Valo
2022-02-21 7:08 ` Manikanta Pubbisetty
2022-02-07 22:13 ` Rob Herring
2022-02-25 11:34 ` Manikanta Pubbisetty
2022-01-28 10:07 ` [PATCH v2 00/19] add support for WCN6750 Kalle Valo
2022-02-21 6:29 ` Manikanta Pubbisetty
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=d7884804-6bc2-058b-c373-8b2005fd2811@quicinc.com \
--to=quic_mpubbise@quicinc.com \
--cc=ath11k@lists.infradead.org \
--cc=devicetree@vger.kernel.org \
--cc=kvalo@kernel.org \
--cc=linux-wireless@vger.kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).