From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3291CC76195 for ; Mon, 27 Mar 2023 16:05:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232630AbjC0QFv (ORCPT ); Mon, 27 Mar 2023 12:05:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40796 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230289AbjC0QFt (ORCPT ); Mon, 27 Mar 2023 12:05:49 -0400 Received: from mout-p-101.mailbox.org (mout-p-101.mailbox.org [80.241.56.151]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 74A53FD; Mon, 27 Mar 2023 09:05:45 -0700 (PDT) Received: from smtp1.mailbox.org (smtp1.mailbox.org [IPv6:2001:67c:2050:b231:465::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-101.mailbox.org (Postfix) with ESMTPS id 4Pld2P5b4fz9sm8; Mon, 27 Mar 2023 18:05:33 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dylanvanassche.be; s=MBO0001; t=1679933141; 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=FZXOuRUfihj3J9liLR8d+gKth5ezGtydGcMxJlFjyCM=; b=cfDNI7VWXRQ6vU0D3q4ei08NGh4lldtz5DdIpgqImxxGRRxVkiQInPQWyl7EiHW+T+tdAA k5Z3Qx0QU6AwtxyJ1U+3majbVMynW6k1+hMyNMF/zhgKCay3lUDEZXqJY/BpVM+gxDVsNd f38ffcKjUnQvhhhye7RNjk5mNGZszdF7jLw+T6d9dO5cBeSSBP6QRAGhVu4bxmdxgCkSVZ Yp00HHhjjB3nACHYoh/OM2Dz03xosOa9Gf7QfLOYMn+iNs0iPDYGpKnleJa4rtHZXcmLlH TAEGYKkF0owzA5aukQ9GwoYvQz6RxnCh9CbCm3QxTeHWikoiwQQkCubRx3SWXg== Message-ID: Subject: Re: [PATCH 1/2] dt-bindings: misc: qcom,fastrpc: add qcom,assign-all-memory property From: Dylan Van Assche To: Krzysztof Kozlowski , Srinivas Kandagatla , Amol Maheshwari , Andy Gross , Bjorn Andersson , Rob Herring , Krzysztof Kozlowski Cc: Dmitry Baryshkov , Konrad Dybcio , Arnd Bergmann , Greg Kroah-Hartman , linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, ~postmarketos/upstreaming@lists.sr.ht, phone-devel@vger.kernel.org Date: Mon, 27 Mar 2023 18:05:24 +0200 In-Reply-To: References: <20230325134410.21092-1-me@dylanvanassche.be> <20230325134410.21092-2-me@dylanvanassche.be> <883c3c48-c6e5-556d-431f-e92592b9106a@linaro.org> <44904ffc-83d4-1137-3479-737a81b31d16@linaro.org> <1f3fb4bd5387c8d69a6eb068fb773b9273081c13.camel@dylanvanassche.be> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Rspamd-Queue-Id: 4Pld2P5b4fz9sm8 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Dmitry & Krzysztof, On Mon, 2023-03-27 at 16:36 +0200, Krzysztof Kozlowski wrote: > On 27/03/2023 16:26, Dylan Van Assche wrote: > > > Bindings are not for driver behavior. > > >=20 > > > > Downstream does guard > > > > this with a property 'restrict-access' as well, see [1] for a > > > > random > > > > SDM845 downstream kernel. On SDM845, this property is not > > > > present, > > > > thus > > > > the IF block runs. On SDM670, this property is present, then > > > > the IF > > > > block is skipped. That's why I opt for this property to have > > > > this > > > > behaviour conditionally. I'm not sure how to explain it better > > > > though. > > >=20 > > > Still you described driver... Please come with something more > > > hardware > > > related. > >=20 > > So just updating the description is enough then? > >=20 > > As this is all reverse engineered, I have no access to the > > documentation of FastRPC, so best effort: > >=20 > > """ > > Mark allocated memory region accessible to remote processor. > > This memory region is used by remote processor to communicate > > when no dedicated Fastrpc context bank hardware is available=C2=A0 > > for remote processor. >=20 > This description does not explain here anything. The memory region is > already accessible without this property. >=20 > You described the desired Linux feature or behavior, not the actual > hardware. The bindings are about the latter, so instead you need to > rephrase the property and its description to match actual hardware > capabilities/features/configuration etc. >=20 > Remember that any arguments to downstream are not really good > arguments. > Their design choices and bindings are usually totally not acceptable. > They simply embed whatever driver needs in DT - policies, system > configuration, driver behavior... >=20 > Also, Dmitry made here good point. >=20 >=20 I agree, downstream is not doing great on being upstreamable. Thanks Dmitry, your explanation makes it pretty clear what I should figure out. This helps a lot! As far as I know, this assignment is only skipped when the sensors are not on the SLPI but on the ADSP e.g. SDM670, thus mid range SoCs. So reading these comments, this looks more like 'driver behavior' which should not end up in bindings as mentioned above. As I now understand the problem with this property, I will rework it for v2 and drop it. This is only done for the SLPI so by guarding it with a domain ID check we should be able to avoid the property in the bindings. Thanks for the feedback & patience! I really learned a lot! Kind regards, Dylan Van Assche >=20 > Best regards, > Krzysztof >=20