linux-kernel - Re: [PATCH v2 2/3] misc: fastrpc: Add support for new DSP IOVA formatting

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: <ac42d5cc-1db9-4e81-8613-ca1ac9cff9d2@app.fastmail.com>
Date: Wed, 15 Oct 2025 09:09:57 +0200
From: "Arnd Bergmann" <arnd@...db.de>
To: "Kumari Pallavi" <kumari.pallavi@....qualcomm.com>,
 kpallavi@....qualcomm.com, "Srinivas Kandagatla" <srini@...nel.org>,
 "Amol Maheshwari" <amahesh@....qualcomm.com>,
 "Greg Kroah-Hartman" <gregkh@...uxfoundation.org>
Cc: quic_bkumar@...cinc.com, ekansh.gupta@....qualcomm.com,
 linux-kernel@...r.kernel.org, quic_chennak@...cinc.com,
 dri-devel@...ts.freedesktop.org, linux-arm-msm@...r.kernel.org,
 "Jingyi Wang" <jingyi.wang@....qualcomm.com>, aiqun.yu@....qualcomm.com,
 ktadakam@....qualcomm.com
Subject: Re: [PATCH v2 2/3] misc: fastrpc: Add support for new DSP IOVA formatting

On Wed, Oct 15, 2025, at 06:57, Kumari Pallavi wrote:

> @@ -2291,6 +2319,22 @@ static int fastrpc_rpmsg_probe(struct 
> rpmsg_device *rpdev)
>  	const char *domain;
>  	bool secure_dsp;
>  	unsigned int vmids[FASTRPC_MAX_VMIDS];
> +	struct device_node *root;
> +	const struct of_device_id *match;
> +	const struct fastrpc_soc_data *soc_data = NULL;
> +
> +	root = of_find_node_by_path("/");
> +	if (!root)
> +		return -ENODEV;
> +
> +	match = of_match_node(qcom_soc_match_table, root);
> +	of_node_put(root);
> +	if (!match || !match->data) {
> +		 soc_data = &default_soc_data;
> +		 dev_dbg(rdev, "no compatible SoC found at root node\n");
> +	} else {
> +		 soc_data = match->data;
> +	}
> 

Matching on the type of the root node is not great, as this
is both a layering violation and does not scale if you need
to do the same thing for future chip generations.

Normally this should be matched on the device compatible
string itself, or possibly based on one of its properties.

If this fails because there are already dtb files in the
open that have to keep getting supported and there is no
identifier in the fastrpc device itself, you can use
soc_device_match() as a last resort to match on the the
soc.

    Arnd