From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f48.google.com (mail-wm1-f48.google.com [209.85.128.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 53F0C2C21F1 for ; Mon, 20 Oct 2025 18:09:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.48 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1760983775; cv=none; b=b+NFOaeeV1d1wnpTr/NrIqtnujWCLutBDRp9wM+16sT2+zMvaEaxDwsZRobYUHdu2jRRNNaiodRQzLrVMVd5id/DYbCAuzG1Zl/SL8OtDaRKExdNs6AuXrlbOnhwsPxK6Xo6vkqZy7ohD1cPoni1mGVUB5b7fMnvuVz5wIPgCNU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1760983775; c=relaxed/simple; bh=Spo6HloAQdKAcrrCYmr+241UVY+67PAGLn2irZa0EUg=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=PQK1lyDrTqFXv9hnBkB4cJ06p1cBv6cqfYBtEKwWscW9/QPceJGElT1jtH6KbEjPkUmRIQPld1fKMmvfKFi3c07E7jTyHLTe++hOHp6RfTUPoU3XjIuYWEAB0iQFO06WxLm4cQ5/03WhEaotc9hbNNk53GTUNeHuXGIax/5GD4c= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org; spf=pass smtp.mailfrom=linaro.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b=JgI9XzHu; arc=none smtp.client-ip=209.85.128.48 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linaro.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="JgI9XzHu" Received: by mail-wm1-f48.google.com with SMTP id 5b1f17b1804b1-47117f92e32so29774275e9.1 for ; Mon, 20 Oct 2025 11:09:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1760983770; x=1761588570; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:content-language:from :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=7ZdBYEg1NCjQhSeodjmOf4VxyFNAFHDsc711gGKZDrI=; b=JgI9XzHujl2nFNERdazjfyBYzKPvYQX0RZxG1WdzaqSW+M0FJGe9n2FfRphnq8KTKJ bORGp6FQZ/Of0nBJ/X4qAWMV9KApFob1ggqE2WTse+RiT0pebfVmvtmAANALuJSEssoV ABBZANzWSDLqLR8VN6DLP3cDhpZRo/9FDQve5C/Eg5ZLwQb57oWZ7ZWl8MKQ7uG9oP29 t2ktN0V5iVnkVBy9HmE6KW74js0bQFbS+f3ORf8HelWK3XDEF+NdQQCpckV8uNn+EGaD D998Vcs8InVl28EQCCCKrARpbDEGggjKfl3vatPBJCv+JDX11ORSUDzNhv80OUw/mgr9 /edg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1760983770; x=1761588570; h=content-transfer-encoding:in-reply-to:content-language:from :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=7ZdBYEg1NCjQhSeodjmOf4VxyFNAFHDsc711gGKZDrI=; b=vR9lJzytmuo8YXJuNsN8qDMTMacUE/6A50jQWOP94fEiovpAVQ35OO5Wvapm1enX6Q A35sl7OIpRYdVXVwS98x4x+yRAkM2Vam8n2fdTJ1cJS/4ZsR25V6njs1VXifg80uOYsH SepBZaEYMUNmGm+fYUC9aj6/VoApLN9hgzTkThS2064SUazYUjbtR2C6WTbVxlN+hniE zIg//aI54dQWhq4sW7XIBMx/v4tT2jvuHzcOR20jZ8hau2fg8/L0FBteaQRYMJIHVEex qY7L9zIoMduXbq+0nRsHS3IfJNEMq9PBg7KATLBRk8Uqji1Sy1dodYloUob/hFFseG0H yDdA== X-Forwarded-Encrypted: i=1; AJvYcCXZa+L4c4B8mlR2v0eGXSP95WRr7mELEteHRAbqTX2gqYRPxP8VIIIi8drCTVE9UIU86fqHEf/rI3bx@vger.kernel.org X-Gm-Message-State: AOJu0YxAtkGhBlml8jJyPrBLIkAd2RfVpeMXuejxf1x+1HcEYhWjnQIh Wf61OulgPMFKmBI91/2HurMRGQ3e9Gpb3UpZ4AZGZDTlTwny9Iz1KJe3hidNm/tpHJI= X-Gm-Gg: ASbGnctKf1mk4j/eIcJuGfuYpFibBXgY5P4nhTM1UI7YrSP6lM88rKwxKtQN+tCPzuO o+Zskv+sWTUgQDZkKXd8rSHkuu4BsFMymp8r9t/vwqcuJ+ssb63bsOJxoNlKMucx6khmNrdrg1q BQjcMyAazND3gei6+RS19hsMjOr4vS67FnSMV2gNbQ1AGN7RpC0F5sPVk21rSxE6kseFBqgVreQ s+595dX1yggs49U4+VTitpuVZyXL1lqPNGEdqZONSbVKsZagCFzkknPzTlbV0ArSQAiRZ1FUcG2 1KFyO5w9SAa2EOtVGrfwRAzLaIPRTLNFhCzLCpg6u3dtgoWdshfTQHwPf3dt1GbKuS2WP67t7SX XiiWmuIsJJq/n78bhJVwHyFwJJgaeWNxChi1+5BGkkzi3GSsjNnea5uKlr2YrlhCyVnbEtnmZVf H21A/h/tCf64qbL8C3511HTZaIv13nnOlTDb47EuSGu00K1paS2TucyxHBZ7kjhel1 X-Google-Smtp-Source: AGHT+IFNzhmhSoTvu4cZ2Fxsh6eT7ubwrXOKq3S1oS3OV3JiX8/nti6w2bD3gES+I31XuVIOCrVziw== X-Received: by 2002:a05:600c:4e89:b0:45d:dc85:c009 with SMTP id 5b1f17b1804b1-471178a236cmr99126355e9.10.1760983770479; Mon, 20 Oct 2025 11:09:30 -0700 (PDT) Received: from [192.168.0.163] (188-141-3-146.dynamic.upc.ie. [188.141.3.146]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4731c95efb9sm116135695e9.8.2025.10.20.11.09.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 20 Oct 2025 11:09:30 -0700 (PDT) Message-ID: <872988b5-8802-4cdd-b3bd-e1a8c718bb6a@linaro.org> Date: Mon, 20 Oct 2025 19:09:28 +0100 Precedence: bulk X-Mailing-List: devicetree@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/6] dt-bindings: media: camss: Add qcom,kaanapali-camss binding To: Vijay Kumar Tumati , Krzysztof Kozlowski , Loic Poulain Cc: Hangxiang Ma , Jingyi Wang , Robert Foss , Andi Shyti , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Bryan O'Donoghue , Todor Tomov , Vladimir Zapolskiy , Mauro Carvalho Chehab , linux-i2c@vger.kernel.org, linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-media@vger.kernel.org, aiqun.yu@oss.qualcomm.com, tingwei.zhang@oss.qualcomm.com, trilok.soni@oss.qualcomm.com, yijie.yang@oss.qualcomm.com References: <20250924-knp-cam-v1-0-b72d6deea054@oss.qualcomm.com> <20250924-knp-cam-v1-2-b72d6deea054@oss.qualcomm.com> <7140b8a8-1380-4859-84a3-681b3f1ce505@kernel.org> <4fb3c83a-2bef-4b15-b676-73e8e8957452@oss.qualcomm.com> From: Bryan O'Donoghue Content-Language: en-US In-Reply-To: <4fb3c83a-2bef-4b15-b676-73e8e8957452@oss.qualcomm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 20/10/2025 18:37, Vijay Kumar Tumati wrote: > Hi @Bryan, @Krzyszto, just my two cents. I think we should consider > separating CSIPHY, CSID, IFE and IFE Lite into distinct DT nodes. Having > a modular DT structure brings in several advantages, > > 1. Simple to manage with much better readability. > 2. Better control to disable certain HW modules from DT. > 3. Less error prone as we don't need to maintain long lists of clocks > or other resources against their names. Accordingly, easy to review. > 4. No need to maintain resource lists within the CAMSS driver to > identify the resources specific to the HW block. Offers centralized > control for the HW resources. > 5. Allows re use between the platforms when a same version of a subset > of HW modules is carried over to future chip sets. > 6. Is more scalable when we add more functionality to the CAMSS driver. > 7. Finally, it brings in parallel development ability with engineers > (within the local teams) working on different HW modules within > camera subsystem. > > If not for the current patches in the pipeline, if you are comfortable > with this approach, we will try to push the changes for the future chip > sets with the modular bindings, leaving the existing SOC drivers and > bindings untouched (if that's recommended). Please let us know your > thoughts. Thanks. I think the Rockchip breaking up of blocks is structurally nice and how you would do things if you were adding stuff in from scratch. Old Irish Joke: Man in car stops asks local: "How do I get to Tralee" Local scratches head under cap: "Well; I wouldn't start from here" We have existing bindings and one message that has been repeated is that new bindings should follow old bindings of a similar class. There's a good argument to separate out the CSIPHY - because it has distinct power-rails and has a real-world effect for users - in that their PCB. It would really be up to yourselves to justify why it is a whole new binding is required i.e. what benefit does it actually bring, and to show, prove, that existing users of this driver either benefit or don't suffer i.e. doing work for old silicon too, not just the new stuff. If the only objective you have is to facilitate co-existence of a downstream driver with upstream bindings. Anyway there's absolutely no reason to hold up this series or any subsequent series on a hypothetical rewrite unless/until that rewrite gets proposed, reviewed and applied. --- bod