Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <41f8fd92-70e4-def6-0bd1-c764b1445d68@quicinc.com>
Date:   Fri, 25 Feb 2022 11:20:37 +0530
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Thunderbird/91.6.1
Subject: Re: [PATCH v2 02/19] ath11k: Refactor PCI code to support hybrid bus
 devices
Content-Language: en-US
To:     Kalle Valo <kvalo@kernel.org>
CC:     <ath11k@lists.infradead.org>, <linux-wireless@vger.kernel.org>,
        <devicetree@vger.kernel.org>, <robh@kernel.org>
References: <1642337235-8618-1-git-send-email-quic_mpubbise@quicinc.com>
 <1642337235-8618-3-git-send-email-quic_mpubbise@quicinc.com>
 <87ee4sgo7l.fsf@kernel.org>
From:   Manikanta Pubbisetty <quic_mpubbise@quicinc.com>
In-Reply-To: <87ee4sgo7l.fsf@kernel.org>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

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.

Thanks,
Manikanta