From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-177.mta0.migadu.com (out-177.mta0.migadu.com [91.218.175.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B468414A8B for ; Thu, 12 Mar 2026 00:49:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.177 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773276546; cv=none; b=mHcJuK7ygEG1SoHSYigXBsxFtUOLI88k/SdBfaoodt5/yrkqs+ICo/islmQrmm6VrFdgCVFAJM8CdcMCCmPqZY6/t2l8Yq0SY2Z+Ek2HO4msxC09XBxh+Kqnn6S+yNzdzB9z727Uma0SwYJOYfkkGzl5XSQRaTG5ShRm2BhV14I= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773276546; c=relaxed/simple; bh=jxRiM74xtktJ2UsuXQWMdp4RWyhOuG6IadKGbymRflo=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=MHfavYpxSK2asD477sPx5K6puAkwjVLGDowhC/hvxGCZCm9v6520D0JFiNwzzkmMEX9lpdBq9g4d5gFAlgMR+kS0HT9VtFqWldwT0U6HlsSJv23Mp/BxGUqdNjwbKpot9ayY17L4eoXPjEOjKW2WuWA7+G2BaAT/uk4JRHjQrQw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=packett.cool; spf=pass smtp.mailfrom=packett.cool; dkim=pass (2048-bit key) header.d=packett.cool header.i=@packett.cool header.b=P3w8HCvm; arc=none smtp.client-ip=91.218.175.177 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=packett.cool Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=packett.cool Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=packett.cool header.i=@packett.cool header.b="P3w8HCvm" Message-ID: <4757fd22-fe9f-4228-a0a5-11d9309549ac@packett.cool> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packett.cool; s=key1; t=1773276542; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=S8a5KXG/hMVU/lPDot7HGqxD42gLldyhHtK4z1zxunk=; b=P3w8HCvmZfl123M85LGVf5P8Uj/NhppSQzV3BD+MoSHdzvbwejMXQvIbJup59gNsPw7NWm 8r9SIPbzmr2UZrW2zMP3Nx5h366edQdo16WHaUzNAo6paposEaDOovdn1s3RWXTe+LlV8a bKwofOpnzUdD2a3K6iCF9SitMLKNZTg+eI87q8DAzXbjwkx/tQ6OiDBPHiD/qCujr42Cse JbiO9i+brVjwSiGtG6QQZ6v7t4Vz8cATa/n7knn1/RrK36MrTG3ON4XauzzEe248MD7xC3 skmXh2b28LJ3r21JceHjJXZihJATwvqC+9vGLTgO1rE6JGky7Usy8R1LPa5w/g== Date: Wed, 11 Mar 2026 21:48:55 -0300 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [PATCH v2 2/5] arm64: dts: qcom: Add AYN QCS8550 Common To: webgeek1234@gmail.com, Bjorn Andersson , Konrad Dybcio , Rob Herring , Krzysztof Kozlowski , Conor Dooley Cc: linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Teguh Sobirin References: <20260311-ayn-qcs8550-v2-0-e66986e0f0cb@gmail.com> <20260311-ayn-qcs8550-v2-2-e66986e0f0cb@gmail.com> Content-Language: en-US X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Val Packett In-Reply-To: <20260311-ayn-qcs8550-v2-2-e66986e0f0cb@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT On 3/11/26 2:44 PM, Aaron Kling wrote: > From: Teguh Sobirin > > This adds a base dtb of everything common between the AYN QCS8550 > devices. It is intended to be extended by device specific overlays. > > Signed-off-by: Teguh Sobirin > Co-developed-by: Aaron Kling > Signed-off-by: Aaron Kling > --- > arch/arm64/boot/dts/qcom/Makefile | 1 + > arch/arm64/boot/dts/qcom/qcs8550-ayntec-common.dts | 1777 ++++++++++++++++++++ > 2 files changed, 1778 insertions(+) > […] > +/ { > + model = "AYN QCS8550 Common"; > + compatible = "ayntec,qcs8550-common", "qcom,qcs8550", "qcom,sm8550"; Huh?.. All existing -common files are .dtsi includes without their own model/compatible, and the compile-time "dtbo" support is only used for EL2 where we want to apply the same thing to many many devices without polluting the tree with extra glue files. I don't see why this should be a "common device" with its own compatible string, and not just a dtsi. > […] > +&gpu { > + status = "okay"; > + > + zap-shader { > + firmware-name = "qcom/sm8550/a740_zap.mbn"; > + }; > +}; Please use the &gpu_zap_shader label. And does the generic zap actually just work? > […] > +&i2c0 { > + clock-frequency = <400000>; > + status = "okay"; > +}; > + > +&i2c4 { > + clock-frequency = <400000>; > + status = "okay"; > +}; > + > +&i2c12 { > + clock-frequency = <400000>; > + status = "okay"; > +}; If the individual devices actually use these busses, better to enable them inside of their .dts as well I think? > +&iris { > + status = "okay"; > +}; Works with generic firmware? > […] > +&pcie0 { > + wake-gpios = <&tlmm 96 GPIO_ACTIVE_HIGH>; > + perst-gpios = <&tlmm 94 GPIO_ACTIVE_LOW>; Current binding is to put these inside of the &pcieportN (renaming 'perst' to 'reset' which I just noticed I failed to do for one of my own files :D), see x1e78100-lenovo-thinkpad-t14s.dtsi for an example. > […] Thanks for this work, very cool overall! ~val