From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0b-0031df01.pphosted.com (mx0b-0031df01.pphosted.com [205.220.180.131]) (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 B7D49397AF2 for ; Tue, 26 May 2026 09:46:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=205.220.180.131 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779788772; cv=none; b=ogu2UAjOA4N5jOWvLVoHeEzQDJTPxSin9sqARmfqG+Zf26FoFQBLZDIS7/5Zg4HR+sg50Yb7XbtHdmGSM2xCBC/lzyaTDVYGA/fKsKyicohE5MwdCl7n8cYMPpZLhQhTx+bX6j3bTwSRMK1XUzCv029mElJU5IxFQ53M+8E1viI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779788772; c=relaxed/simple; bh=ZCAvrcBAJIXTnHEvSKz8Yq0JKkscj5TsSoJRyS3heaY=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=PTlGQgBGtm5tCZe1Trck6lIlz6jURNIcNpLwRTFtQfLdxbiOThuiRs/lbfxVOOtWsQhmVx7njQGjB3N9dNl7PMgQG0Sq8Lsat24oo6FFMrJ0cdGMGHc37yldtP5dgCAoAPXzpgJrGcaME6qmBxnG4Cs5liZKVmpnyU6DMQG/8bA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oss.qualcomm.com; spf=pass smtp.mailfrom=oss.qualcomm.com; dkim=pass (2048-bit key) header.d=qualcomm.com header.i=@qualcomm.com header.b=fr1+vbDE; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b=VnBuMI1T; arc=none smtp.client-ip=205.220.180.131 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oss.qualcomm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=oss.qualcomm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=qualcomm.com header.i=@qualcomm.com header.b="fr1+vbDE"; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b="VnBuMI1T" Received: from pps.filterd (m0279871.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 64Q8u73l3658429 for ; Tue, 26 May 2026 09:46:09 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qualcomm.com; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s=qcppdkim1; bh= +tNWCjXxY3vDlbxeyc6dAiioLTzJiUtHmEfK77uv8QU=; b=fr1+vbDENVQY5Zkc AWKEyhljX0yFvxH6I1SvWUMTfp19xN/S0yh+TGoyD9Cl2mMP1B+cxYr4CMbB+3HK i6mgb6GJt0ChQnVW/edYstQ2ZQ/3qEyz7787O7HhTjAw4XPZE3hs5gii8npI7Amv SV4YTLdzF9yQsyRYbZhe8MXQpEJ8I1OBPDETlM0oT+VsBZIO/86gjRfEn9vRxRhD fa7RK+Fn5PB0Yls+1QT2cAgdVoCp2+ET9/qfV+TNX1+bxgF2y68cg7pgqK+nzx0o z9PP/dkyTpf4v2k4Ml/cIFZEvKeM5ltrMipw4x5NALhFjWWhKMw9d8b7GJjlf880 lK0fmQ== Received: from mail-pl1-f197.google.com (mail-pl1-f197.google.com [209.85.214.197]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4ecqynb74w-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Tue, 26 May 2026 09:46:09 +0000 (GMT) Received: by mail-pl1-f197.google.com with SMTP id d9443c01a7336-2ba268cb5e6so109787105ad.1 for ; Tue, 26 May 2026 02:46:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1779788768; x=1780393568; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=+tNWCjXxY3vDlbxeyc6dAiioLTzJiUtHmEfK77uv8QU=; b=VnBuMI1TbZBKQ34ChVJFTVJ581pMrscHMt/ZxDDDtXbNvdk+5dbGI6vVcHo/krt1Lr l6Xo9bnGE5zvJWHOAzMEaUM9fyCGrQaeJxeV70X8y0LsjEDY36lhXnI14EEHu7QBIKkD ypPdArXCTba+KbIIamJ+5M9so4EI3mjhzWntGGE/F5lfszIRuRabmBe4W9NDLgtJV+mf ICHUASGVX9Bb2pYSNhlR223M1LOrjsOnTyeO7IvRliTW0KquZqj/tq5LD7k4Lg37MyFa /SUTerOC80RbmOqA+v1gVaDTWKic2CHqwCqoaRGReMDpb7qaiq9Nda79xIByORjrPOYJ hzFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779788768; x=1780393568; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=+tNWCjXxY3vDlbxeyc6dAiioLTzJiUtHmEfK77uv8QU=; b=KLQs7U65VtZShAldMoijCqPGsmywSmqDtuFlkl1hf9YtXsP4DhcU1TcL6CSYOLl3WB dgHeuyQWGWeczRSY4u+g70EEhNc1ckDH+3DNz1EQl4ODIpBPGp6qf960bqyAFuWKUvoq fMIxwQUY43rk98ZSUadJxBGQfFAX/Sll/m8MT0p+tnXOskPMN3bZeEfD2AJ9ee3HNdBP IBVOU4voY9hHpBoOE05qhoijMFjQkNEg0q1vC+5XFlWTvmcfJpvISLrBa3SqG5cENzrk iAW2vaFUDiQ/msvyGOcWHk2HKlTM/IkLICmfBQKUFCFQkAsSx/YYBwLOswZIoX+PXCX7 drfw== X-Forwarded-Encrypted: i=1; AFNElJ8Iz67gxnTgYMq2F5kBtzGoZ2YZFbcYMQkikz0MuZaaZuv92G3z/nrLRHtG0A8xmKI2fcQkEWSblWa4rz8=@vger.kernel.org X-Gm-Message-State: AOJu0YwxWJYIGwEMzendKXBJHFmNS+Zf3DhkoF+xBkvYfmo6Qo1dvoRM 6uOeJk8FCfq3OVwwKudwG6H8epDLoQqN6HHiNC/pNce5EfhXBQQAmjyr+kBZkCbCj3JQsuuDc4W HXWPmSWgYn1N/X1zZjfRaZCq/ZkwCl+BrdhK9DMooFvKTTQxOU06xQgZCpLAN5b951oE= X-Gm-Gg: Acq92OFuYLo4FxL1wsJUN41xhqBKblR/1RZDEmCAci6EwDf+3SwoDt4GvGN3+oP7zdA fx3KOlRqQi2P+zdmL8OCoHfM1o0thiYh0LYw6Lq5mEYtzTNDkBkzPTQVDrtWyaGTbXh3Hn4ZTNZ 7Y8C+BWEekArxgXYiTeEqQzzZ1HKvWn9nSmWIsNPJYT24eZnCCx9EegRvrAKpTK8irCRvZeYNpy pF/adVuykFUmuNJP8c1z84yfF9KgQIALRsMEL4/TO1anfUotljlStrczNk1cYtNVjHxG4VIH9Ad gCufCMghLINyiRTzYm1vvbNFnT9MShb/j8DhP5GMlMKdO0z6UDxJTwPyD+6Z0Mm6PkydGfOvsa/ 2Yj7/FCCKM6wKCfnZTt/uICzp4XKnM+tm4qoIH2XCqe2vWoQ3HY2Ve33D X-Received: by 2002:a17:903:41c2:b0:2ba:e42a:231e with SMTP id d9443c01a7336-2beb064837dmr200645485ad.37.1779788768349; Tue, 26 May 2026 02:46:08 -0700 (PDT) X-Received: by 2002:a17:903:41c2:b0:2ba:e42a:231e with SMTP id d9443c01a7336-2beb064837dmr200645035ad.37.1779788767805; Tue, 26 May 2026 02:46:07 -0700 (PDT) Received: from [10.219.57.109] ([202.46.23.19]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2beb58b2ebcsm121223885ad.49.2026.05.26.02.45.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 26 May 2026 02:46:07 -0700 (PDT) Message-ID: Date: Tue, 26 May 2026 15:15:55 +0530 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v15 0/3] of: parsing of multi #{iommu,msi}-cells in maps To: Krzysztof Kozlowski Cc: Nipun Gupta , Nikhil Agarwal , Joerg Roedel , Will Deacon , Robin Murphy , Marc Zyngier , Lorenzo Pieralisi , Thomas Gleixner , Saravana Kannan , Richard Zhu , Lucas Stach , =?UTF-8?Q?Krzysztof_Wilczy=C5=84ski?= , Manivannan Sadhasivam , Bjorn Helgaas , Frank Li , Sascha Hauer , Pengutronix Kernel Team , Fabio Estevam , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Dmitry Baryshkov , Konrad Dybcio , Bjorn Andersson , Rob Herring , Conor Dooley , Krzysztof Kozlowski , Prakash Gupta , Vikash Garodia , linux-kernel@vger.kernel.org, iommu@lists.linux.dev, linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, linux-pci@vger.kernel.org, imx@lists.linux.dev, xen-devel@lists.xenproject.org, linux-arm-msm@vger.kernel.org, Charan Teja Kalla References: <20260520-parse_iommu_cells-v15-0-b5f99ad4e7e8@oss.qualcomm.com> <20260526-finicky-crafty-hare-eae27c@quoll> Content-Language: en-US From: Vijayanand Jitta In-Reply-To: <20260526-finicky-crafty-hare-eae27c@quoll> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Authority-Analysis: v=2.4 cv=Wpwb99fv c=1 sm=1 tr=0 ts=6a156be1 cx=c_pps a=cmESyDAEBpBGqyK7t0alAg==:117 a=j4ogTh8yFefVWWEFDRgCtg==:17 a=IkcTkHD0fZMA:10 a=NGcC8JguVDcA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=3WHJM1ZQz_JShphwDgj5:22 a=VwQbUJbxAAAA:8 a=EUspDBNiAAAA:8 a=Jo8nEopC4ZUABtMbiE8A:9 a=QEXdDO2ut3YA:10 a=1OuFwYUASf3TG4hYMiVC:22 X-Proofpoint-GUID: qfmBcM-4VI1Uf1tcokCgu0Blk8ICF_WX X-Proofpoint-ORIG-GUID: qfmBcM-4VI1Uf1tcokCgu0Blk8ICF_WX X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwNTI2MDA4NSBTYWx0ZWRfX0nkH6d1DDDfg ItGJS5IL9m5m+xhwm+j2zdjrw1fjo4LPu8A8u0o7vqY4JxSSeDPhaOqgtOnlPNBUuz4Aho2rFGc Btscci+TZO0lKPFMhtBCx2Bs5VfFKgz1apBLNe5x0pRl7HjTT0yv64hlW/f2oaoMu+oLEef/hUF vXPMwlKgO/JaesvUwiF3hhbkjQKaKu+H7//MdS7uX9G0TfpLMLtz+Oop1o9zWddg7O/yKVpVJzb 31XzNKcxIfIWBfi71j8OM+OaSWIJ1ZfBWldFGZuGM0PMNgrAg6z+ybyrGKoWnuH8xGl4x0g46WS seqDw9e4hH9/+NoBU13peCEKOJl1gLtiW8BD2QKyvby263GeUqDkxKsZBPnBc5mqPQSGvIUe7De sc8wzF684mPGGk3CiNM/tbK5SoAnK1aqc2Ami/3L4hilXywlukFNajGzUOrmLI9LW+IMJir3We9 AOZzZ/w657mFsxs/0zg== X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1143,Hydra:6.1.51,FMLib:17.12.100.49 definitions=2026-05-26_02,2026-05-18_01,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 clxscore=1015 suspectscore=0 impostorscore=0 adultscore=0 lowpriorityscore=0 malwarescore=0 spamscore=0 bulkscore=0 phishscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2605130000 definitions=main-2605260085 On 5/26/2026 11:42 AM, Krzysztof Kozlowski wrote: > On Wed, May 20, 2026 at 01:32:39PM +0530, Vijayanand Jitta wrote: >> So far our parsing of {iommu,msi}-map properties has always blindly >> assumed that the output specifiers will always have exactly 1 cell. >> This typically does happen to be the case, but is not actually enforced >> (and the PCI msi-map binding even explicitly states support for 0 or 1 >> cells) - as a result we've now ended up with dodgy DTs out in the field >> which depend on this behaviour to map a 1-cell specifier for a 2-cell >> provider, despite that being bogus per the bindings themselves. >> >> Since there is some potential use[1] in being able to map at least >> single input IDs to multi-cell output specifiers (and properly support >> 0-cell outputs as well), add support for properly parsing and using the >> target nodes' #cells values, albeit with the unfortunate complication of >> still having to work around expectations of the old behaviour too. >> -- Robin. >> >> Unlike single #{}-cell, it is complex to establish a linear relation >> between input 'id' and output specifier for multi-cell properties, thus >> it is always expected that len never going to be > 1. >> >> These changes have been tested on QEMU for the arm64 architecture. > > So there is no real user for that. That's unconvincing. I would assume > that at least you have real user where you test it. > > If you want to speed up acceptance of your patches, then also I would > prefer to see at least one more user, beside Qualcomm. IOW, show how you > solve other people problems, not only yours. > > Best regards, > Krzysztof > Hi Krzysztof, Thank you for the feedback. The upstream user for the multi-cell iommu-map support is the Lemans platform's VPU device, which requires iommu-map entries targeting a 2-cell IOMMU node. We are currently working on the glymur series [1] and once that is finalized we will post the Lemans patches as well. That said, I think this series can go through independently for the following reasons: 1. Correctness fix: The iommu-map/msi-map bindings have always specified that the output cell count is determined by #iommu-cells/#msi-cells on the target node. The kernel has been silently ignoring this and assuming 1 cell. This patch makes the kernel respect the binding specification. 2. Backward compatibility preserved: The of_check_bad_map() workaround handles existing deployed DTs that target 2-cell IOMMU nodes with 1-cell entries. This series has been tested on the glymur platform [1], which uses iommu-map with 1-cell specifiers, and the existing parsing continues to work correctly. Thanks, Vijay [1] https://lore.kernel.org/all/20260515-glymur-v6-5-f6a99cb43a24@oss.qualcomm.com/