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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id C7BC7C38A2D for ; Tue, 25 Oct 2022 19:49:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:From:References:Cc:To: Subject:MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=ZPBGX96EacT7KMzO77thdZUTOUN7I6B0n14GHdEVrrk=; b=Uc8IpJvauy0f5n VE+H861667P6Idi6nyxQBA0TE6MlGEvzWiQUBCurJ4g/31lC0e1dvJItbGNpzrOidK7IU2vLtQZNw JVP4/YrqJEVRL4LFlpOzEt/TI83MrsLAlxGKFFh2mM3NO+BJs/cBZKeqsUsU6MnY+JPHzYpxTVwHH zGCrkPiXfmNLz3wYl42VnH3ne0ov0fLonZc8K5hGlfawL2CWJ37AhmA7+iKElvxFmd1Bz8uE+p2o/ dOfYCxRq3sf+SUF4OVcgMGsfcYXJAh+/dVZm22SZETJWybwqHWc2OFxspXAEFm6O68ObZ1zbaAVAx zafXMbIKEVNETL4LMt7Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1onPum-0070Ga-R5; Tue, 25 Oct 2022 19:48:45 +0000 Received: from mail-qk1-x72a.google.com ([2607:f8b0:4864:20::72a]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1onPuk-0070Fb-35 for linux-arm-kernel@lists.infradead.org; Tue, 25 Oct 2022 19:48:43 +0000 Received: by mail-qk1-x72a.google.com with SMTP id z17so6274850qkj.8 for ; Tue, 25 Oct 2022 12:48:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=nsy/E/McG6wphxcYFdjdUMTRPfbaeJ0Z5p5LSzNi/vo=; b=RdjgjIJid3w2NovUK1hSPAckw+AekRfr7Gt2LGMF6fw7aTtpYrGBc6556Xfz8BtVK/ x8jJevoDOug7BDK+/EnIVxGOg4VKRv73vLTrDrXNio3XcQnVD1vBh9z3wZcbdLr2/34M xqR8XEfTHRaVz9QDTqC6pLb+tnlGfMVaWPPlOPRe6jGGsMwYugutKD4KfzWY9yS0289S RDcVpSSJI0TF+n0WAjBdLnIdat6To60QJ/fiGURxkOOlIRiLpuqhLNfzCHPIBV8SQpzN gSgXV6JSQ5Kb0WF3He8HLNhj1UngD3XRxD9TZAOiEEnYIFW0J7X8gzv2dvKJhxRd3Lpy GnUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=nsy/E/McG6wphxcYFdjdUMTRPfbaeJ0Z5p5LSzNi/vo=; b=m6lGPtAR2zMFyrNmtvPAONQDwQLsTdx6VzKalX2AHhs/6CCWtdxidFjPczbVaACQRd aHGmVHRGqnxa8t9xxQZgPqbB9cRiE91RkOPGCQ70hWwLdoV56sGiYgVIxRS4iFgKsjT9 RF7zpZ6iusyz0QaCSBjjSCoUGFeaePHUdbBqC/v6mw9RGDhqk5n0tl9VSphCBzNfjp6X LEZgEfXHWgRODTgKjU3WUsE08hM6L89qS6iSvP6RWdRXFTBjNWye8JZU7QmpCyh6aFWk 1z/uX9jDn0bFWoVJbhGyDPpxfv5USsJn5PF1fOyjWHiawdO0ika3aFVXMwG3WIUtFElB tV6A== X-Gm-Message-State: ACrzQf2otOtKFBdAQEad9BAY1LeiwP9XHzf+iZ7+tn8UXIoJch2GnCIe ZbRtc+IEOywygrKcfVpq0PG3aQ== X-Google-Smtp-Source: AMsMyM55rJIV7dZ7ouZTeJWWZDxaDM/Si4uJAf9nILmG79CPEQ3hsU6mnX5fDPVAYwYI+dbMCE1aMg== X-Received: by 2002:a05:620a:2618:b0:6ea:908:120e with SMTP id z24-20020a05620a261800b006ea0908120emr27840879qko.645.1666727318586; Tue, 25 Oct 2022 12:48:38 -0700 (PDT) Received: from [192.168.1.11] ([64.57.193.93]) by smtp.gmail.com with ESMTPSA id t30-20020a37ea1e000000b006ec771d8f89sm2515328qkj.112.2022.10.25.12.48.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 25 Oct 2022 12:48:37 -0700 (PDT) Message-ID: <8a4048d4-2675-96ed-89f1-db77084d18ba@linaro.org> Date: Tue, 25 Oct 2022 15:48:35 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.0 Subject: Re: [PATCH v1 2/5] dt-bindings: soc: hpe: Add hpe,gxp-plreg Content-Language: en-US To: "Verdun, Jean-Marie" , "Hawkins, Nick" Cc: "krzysztof.kozlowski+dt@linaro.org" , "linux@armlinux.org.uk" , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , Rob Herring References: <20221011185525.94210-1-nick.hawkins@hpe.com> <20221011185525.94210-3-nick.hawkins@hpe.com> <820095a2-3722-5c3a-77fb-5a6b6b44e1c3@linaro.org> <7c9e943a-4806-6339-cee1-9156e7792111@linaro.org> <0b6dd763-365d-6f35-59cb-18c599b73d3a@linaro.org> From: Krzysztof Kozlowski In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221025_124842_167469_88E5633A X-CRM114-Status: GOOD ( 18.44 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 25/10/2022 15:39, Verdun, Jean-Marie wrote: > Hi Krzysztof, > Use mailing list style of replying. I can bear the lack of wrapping (one huge sentence), but top-post is a no. > I think what we try to do is to introduce an abstraction layer between the interfaces and the drivers, as our CPLD interfaces are platform dependents. I mean the Power On control could be at address 0x09 on one platform or 0x119 on another one. We would like to find a way to avoid to have to change the driver code, but just feeding the driver with relevant datas, which could be into a platform dependent include file or through the proposed solution that Nick is promoting. I think this was already said. Repeating it, with very similar words will not help us... Let me be then clear: I care little about your goal of abstracting some driver code. I care about proper Devicetree bindings and proper representation of hardware in Devicetree sources. Looks like you want to hack around Devicetree to match your needs. This does not work. I gave you the proposed solution based on my feeling and limited understanding of what you have there. If this does not work for you, then life - you need to find other solution. > > If the CPLD memory address space was consistent between platform and generation that would be great but unfortunately that is not the case that is why we try to break down the dependency into the driver code and retrieve the data from another place. I don't see how this argument is relevant to my questions. I did not propose anything which would require some "memory address space consistency". Best regards, Krzysztof _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel