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: <d7884804-6bc2-058b-c373-8b2005fd2811@quicinc.com>
Date:   Tue, 8 Mar 2022 11:30:51 +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
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>
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>
 <41f8fd92-70e4-def6-0bd1-c764b1445d68@quicinc.com>
In-Reply-To: <41f8fd92-70e4-def6-0bd1-c764b1445d68@quicinc.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk

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