linux-kernel - Re: [V3,09/11] remoteproc: qcom: Add Hexagon based multipd rproc driver

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: <c53c8fc5-a898-df1d-4626-696ffd990796@linaro.org>
Date:   Thu, 20 Jul 2023 15:13:38 +0200
From:   Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To:     Manikanta Mylavarapu <quic_mmanikan@...cinc.com>,
        agross@...nel.org, andersson@...nel.org, konrad.dybcio@...aro.org,
        mathieu.poirier@...aro.org, robh+dt@...nel.org,
        krzysztof.kozlowski+dt@...aro.org, conor+dt@...nel.org,
        mturquette@...libre.com, sboyd@...nel.org,
        quic_eberman@...cinc.com, kvalo@...nel.org,
        loic.poulain@...aro.org, linux-arm-msm@...r.kernel.org,
        linux-remoteproc@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-clk@...r.kernel.org
Cc:     quic_srichara@...cinc.com, quic_sjaganat@...cinc.com,
        quic_kathirav@...cinc.com, quic_anusha@...cinc.com
Subject: Re: [V3,09/11] remoteproc: qcom: Add Hexagon based multipd rproc
 driver

On 18/07/2023 14:04, Manikanta Mylavarapu wrote:
> It adds support to bring up remoteproc's on multipd model.
> Pd means protection domain. It's similar to process in Linux.
> Here QDSP6 processor runs each wifi radio functionality on a
> separate process. One process can't access other process
> resources, so this is termed as PD i.e protection domain.

...

> + * User pd boot-info format mentioned below
> + * <Version> <No of elements passing over smem> <Header type> <Header Length>
> + * <Process Id> <Load address> <firmware mem Size>
> + *
> + * Returns 0 on success else negative value on failure.
> + */
> +static int share_upd_bootinfo_to_q6(struct rproc *rproc)
> +{
> +	int ret;
> +	size_t size;
> +	u16 cnt = 0, version;
> +	void *ptr;
> +	struct q6_wcss *wcss = rproc->priv, *upd_wcss;
> +	struct device_node *upd_np;
> +	struct platform_device *upd_pdev;
> +	struct rproc *upd_rproc;
> +	struct userpd_boot_info upd_bootinfo = {0};
> +	const struct firmware *fw;
> +
> +	ret = qcom_smem_alloc(REMOTE_PID, UPD_BOOT_INFO_SMEM_ID,
> +			      UPD_BOOT_INFO_SMEM_SIZE);
> +	if (ret && ret != -EEXIST) {
> +		dev_err(wcss->dev,
> +			"failed to allocate q6 bootinfo smem segment\n");
> +		return ret;
> +	}
> +
> +	ptr = qcom_smem_get(REMOTE_PID, UPD_BOOT_INFO_SMEM_ID, &size);
> +	if (IS_ERR(ptr) || size != UPD_BOOT_INFO_SMEM_SIZE) {
> +		dev_err(wcss->dev,
> +			"Unable to acquire smp2p item(%d) ret:%ld\n",
> +			UPD_BOOT_INFO_SMEM_ID, PTR_ERR(ptr));
> +		return PTR_ERR(ptr);
> +	}
> +
> +	/* print physical address */
> +	dev_info(wcss->dev,
> +		 "smem phyiscal address:0x%lX\n",
> +		 (uintptr_t)qcom_smem_virt_to_phys(ptr));

One more thought. Why do you need it? Even if this is not a kernel or
user-space address, why would like to disclose the memory layout? I
think this is contradictory to the kptr_restrict concept.

> +
> +	/*Version*/



Best regards,
Krzysztof