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 B53E0C38A2D for ; Tue, 25 Oct 2022 19:49:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230245AbiJYTt4 (ORCPT ); Tue, 25 Oct 2022 15:49:56 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42396 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232304AbiJYTtz (ORCPT ); Tue, 25 Oct 2022 15:49:55 -0400 Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [IPv6:2607:f8b0:4864:20::829]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 40D1312D07 for ; Tue, 25 Oct 2022 12:49:50 -0700 (PDT) Received: by mail-qt1-x829.google.com with SMTP id z6so477086qtv.5 for ; Tue, 25 Oct 2022 12:49:50 -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=U41pkWnztK+i9UJZd7s5z8LIiVyrhcfeu311i/JqJM8=; b=ZFG1ze7gQ7pP9QhmCO1qgsX4LR7vZ+Ynt4b8aO3aFFIEKuPT8tgKjsSX7OM/4eTdVC ZxvD1/1lu9Bh8KZbEvVZvL2r5tDCA4CSmu5jx4bgYS7ntOiqdtbM8qflPN6ghUGkyWEs N5YGlO0vt6YEWRI67ygYiusJcCdF85emAit/aspDfJV1xfNtPt+5z/RNHUSdbNqZUaku bUHCqGd/t1nsm1KesFxjIubI7j0YtQKOoIhJqWRVHr3nRisd+ph0qKSgTW8L8UE0RmgR n6wdWL02OktzsVki8tx47w9YfJex8dkas7SD9gG8i9CBq2Dw+NBeyeIe/ApVZIT5HP6v 4JWQ== 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=U41pkWnztK+i9UJZd7s5z8LIiVyrhcfeu311i/JqJM8=; b=Ltu7wJdkJ6XyFy+wQh3pC6jzHBNiLIB536BA9IHVwN+tLnb9CFDPXhWSDfztnW7qmn tEO5mrsbooExUXzZLMl7FW6e//erD2VfUwl9mGiihgVk4E4v32GVfnD5IoOwr5S5lR/l Hr/bDl4FglQdEl4oEdC5NtVzNWm4LCy77PHOFGgPWon8jdPZngiZB+q/vYCSkqLHOeUj jVjg13yXUU2o9M8La67mgOchQNKrS4GbQa1n4qN3dk2mBGS5b9F5b6A0FiEdz0+ZJqZt TA7TFcsMSyLEH73YTwc8RkEwXT3yj3I+a4dW48iwdtHYPf4VdyTVSVXZQ3IR0bnu2+z8 onOw== X-Gm-Message-State: ACrzQf28JMwOnWoIYBUsngYbnNPTpwXVlqKdYM8srODvYhjtY9/tGeUB KY/SYUctMgHfw0ngHAhS2jfQNA== X-Google-Smtp-Source: AMsMyM6+s9yLCfeEgg3kbixXLX/jGhSq3bpEZpjwl3Rb1L5e21mSdwAl7KYOL2J9lqP6sxLZLiBvuw== X-Received: by 2002:ac8:5d93:0:b0:398:3709:945c with SMTP id d19-20020ac85d93000000b003983709945cmr33024036qtx.459.1666727390012; Tue, 25 Oct 2022 12:49:50 -0700 (PDT) Received: from [192.168.1.11] ([64.57.193.93]) by smtp.gmail.com with ESMTPSA id d20-20020ac851d4000000b0035bafecff78sm2023136qtn.74.2022.10.25.12.49.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 25 Oct 2022 12:49:49 -0700 (PDT) Message-ID: <5dc85333-b265-ab10-74db-1ed969630813@linaro.org> Date: Tue, 25 Oct 2022 15:49:48 -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: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On 25/10/2022 15:39, Verdun, Jean-Marie wrote: > Hi Krzysztof, > > 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. > > 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. > > JM > ________________________________ > From: Krzysztof Kozlowski > Sent: Tuesday, October 25, 2022 12:33 PM > To: Hawkins, Nick > Cc: Verdun, Jean-Marie ; 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 > Subject: Re: [PATCH v1 2/5] dt-bindings: soc: hpe: Add hpe,gxp-plreg > > On 25/10/2022 15:26, Hawkins, Nick wrote: >> >>> I don't know exactly what type of devices you represent in that plreg, but in general the fan device would be the respective plreg. The same with other pieces like hwmon, power supply. >> We were primarily representing the registers that translate to the CPLD input/outputs from our platforms as well as handling the interrupts associated with those inputs/outputs. > > So basically each register (or set of registers) is a device? How is it > different than any other multi-functional device? Why do you want to > model it differently? How is it different, I am asking? > >> When you say "would be the respective plreg" do you mean that each device/controller would need to perform the actions plreg does individually? In that case how should we get information for that register/memory region and interrupts from the dts? Could it be something like this: >> >> plreg: plreg@d1000000 { >> compatible = "hpe,gxp-plreg"; >> reg = <0xd1000000 0xFF>; >> interrupts = <26>; >> interrupt-parent = <&vic0>; >> }; >> >> fanctrl: fanctrl@c1000c00 { >> compatible = "hpe,gxp-fan-ctrl"; >> reg = <0xc1000c00 0x200>; >> plreg_handle = <&plreg>; >> }; >> > > No, rather these are one node. > > You insist to represent this all as programmable logic, but why? CPLD, > FPGA, ASIC, dedicated IC - all are just implementations and for us > what's matter are the interfaces, inputs and outputs. And seriously... this is not a chat. Take a bit of time to answer these questions instead of replying immediately with a same response as yesterday. Best regards, Krzysztof