linux-kernel - Re: [PATCH v2] bus: mhi: core: Add unique qrtr node id support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ee9edb7c59a20e5ea2af59de21e815ee@codeaurora.org>
Date:   Fri, 26 Feb 2021 09:31:23 -0800
From:   Bhaumik Bhatt <bbhatt@...eaurora.org>
To:     Gokul Sriram Palanisamy <gokulsri@...eaurora.org>
Cc:     Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>,
        linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org,
        jhugo@...eaurora.org, hemantk@...eaurora.org,
        sricharan@...eaurora.org
Subject: Re: [PATCH v2] bus: mhi: core: Add unique qrtr node id support

On 2021-02-26 06:52 AM, Manivannan Sadhasivam wrote:
> On Fri, Feb 26, 2021 at 04:12:49PM +0530, Gokul Sriram Palanisamy 
> wrote:
>> On platforms with two or more identical mhi
>> devices, qmi service will run with identical
>> qrtr-node-id. Because of this identical ID,
>> host qrtr-lookup cannot register more than one
>> qmi service with identical node ID. Ultimately,
>> only one qmi service will be avilable for the
>> underlying drivers to communicate with.
>> 
>> On QCN9000, it implements a unique qrtr-node-id
>> and qmi instance ID using a unique instance ID
>> written to a debug register from host driver
>> soon after SBL is loaded.
>> 
>> This change generates a unique instance ID from
>> PCIe domain number and bus number, writes to the
>> given debug register just after SBL is loaded so
>> that it is available for FW when the QMI service
>> is spawned.
>> 
>> sample:
>> root@...nWrt:/# qrtr-lookup
>>   Service Version Instance Node  Port
>>        15       1        0    8     1 Test service
>>        69       1        8    8     2 ATH10k WLAN firmware service
>>        15       1        0   24     1 Test service
>>        69       1       24   24     2 ATH10k WLAN firmware service
>> 
>> Here 8 and 24 on column 3 (QMI Instance ID)
>> and 4 (QRTR Node ID) are the node IDs that
>> is unique per mhi device.
>> 
>> Signed-off-by: Gokul Sriram Palanisamy <gokulsri@...eaurora.org>
>> ---
>>  drivers/bus/mhi/core/boot.c | 14 ++++++++++++++
>>  1 file changed, 14 insertions(+)
>> 
>> diff --git a/drivers/bus/mhi/core/boot.c b/drivers/bus/mhi/core/boot.c
>> index c2546bf..5e5dad5 100644
>> --- a/drivers/bus/mhi/core/boot.c
>> +++ b/drivers/bus/mhi/core/boot.c
>> @@ -16,8 +16,12 @@
>>  #include <linux/random.h>
>>  #include <linux/slab.h>
>>  #include <linux/wait.h>
>> +#include <linux/pci.h>
>>  #include "internal.h"
>> 
>> +#define QRTR_INSTANCE_MASK	0x000000FF
>> +#define QRTR_INSTANCE_SHIFT	0
>> +
>>  /* Setup RDDM vector table for RDDM transfer and program RXVEC */
>>  void mhi_rddm_prepare(struct mhi_controller *mhi_cntrl,
>>  		      struct image_info *img_info)
>> @@ -391,6 +395,9 @@ void mhi_fw_load_handler(struct mhi_controller 
>> *mhi_cntrl)
>>  	const struct firmware *firmware = NULL;
>>  	struct image_info *image_info;
>>  	struct device *dev = &mhi_cntrl->mhi_dev->dev;
>> +	struct pci_dev *pci_dev = to_pci_dev(mhi_cntrl->cntrl_dev);
>> +	struct pci_bus *bus = pci_dev->bus;
>> +	uint32_t instance;
>>  	const char *fw_name;
>>  	void *buf;
>>  	dma_addr_t dma_addr;
>> @@ -466,6 +473,13 @@ void mhi_fw_load_handler(struct mhi_controller 
>> *mhi_cntrl)
>>  		return;
>>  	}
>> 
>> +	instance = ((pci_domain_nr(bus) & 0xF) << 4) | (bus->number & 0xF);
>> +	instance &= QRTR_INSTANCE_MASK;
>> +
>> +	mhi_write_reg_field(mhi_cntrl, mhi_cntrl->bhi,
>> +			    BHI_ERRDBG2, QRTR_INSTANCE_MASK,
>> +			    QRTR_INSTANCE_SHIFT, instance);
> 
> You cannot not do this in MHI stack. Why can't you do this in the MHI 
> controller
> specific to QCN9000? And btw, is QCN9000 supported in mainline?
> 
> Thanks,
> Mani
> 
>> +
>>  	write_lock_irq(&mhi_cntrl->pm_lock);
>>  	mhi_cntrl->dev_state = MHI_STATE_RESET;
>>  	write_unlock_irq(&mhi_cntrl->pm_lock);
>> --
>> 2.7.4
>> 

As others have stated, please refrain from adding protocol specific code 
(such as PCIe)
in the MHI core driver. Please have this change in your controller.

If there is access to BHI registers required prior to power up from MHI 
core, it is not
exposed right now. We can talk about how you can  achieve that, so you 
can do this write
in your controller after mhi_prepare_for_power_up().

Thanks,
Bhaumik
---
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora 
Forum,
a Linux Foundation Collaborative Project