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 6E459C38A2D for ; Tue, 25 Oct 2022 19:50:54 +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=54ldOSZIcWkKqjhhB3uE9suXTe4OPJPVu+6i217guk4=; b=4gadh8ckw2xDyM FZf0snT4DfHXUcoTNAqdF7CICEElVn83NXCGYFIqCmhuIAxOSu0go9u9yyD4ie07mWmfhO/WiYzkd 8o8xjPqvsH7fGIhfUP1P47ypaRac75tjevUzglgVwl8y02u1ykghAnhSRbqG9jWsHOzVuq9/s0cqa aoAGUliepRbBLd0P29H7aWexII154KzLIp2/iua4R5ahdxPCM6W3txJ7oB6jbLCync5UGHjA/Wx8o rKiax2RQAn0GGNRHyHrxC2+eIA10+mkhTjKtRngD4RprVLNx+ergoUkMg08i1PeHBsNQcGEqJKVgi yZ+1tu3bRqsIieixi/PQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1onPvw-0070QQ-1B; Tue, 25 Oct 2022 19:49:56 +0000 Received: from mail-qt1-x834.google.com ([2607:f8b0:4864:20::834]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1onPvt-0070P6-Af for linux-arm-kernel@lists.infradead.org; Tue, 25 Oct 2022 19:49:54 +0000 Received: by mail-qt1-x834.google.com with SMTP id hh9so8329176qtb.13 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=VZPeeU185+7XHljLK49UhgXEsulZ3Va6yqGT7SbH2NmOFJ66SeU8+3M2qESZOfa3qn hEq5wZ2euc18AZ1/omHr0KQIPSYB9MdJWSIilGErzEt2t/WyZa1IWGKCm4ganbqIVle6 A/JFj96BVDH0BMX69iC1PClL4cclC6oAm5D6kxWsttXf33cVdkSQbQaD8RXAXV/Tx3Cr yGRcWOBM/33doGPwWR1tiGCxYE94/gXdasBIzPd55fu15a0Odm3bDe11Uz+ALUQv3WWr 4TZIG+fKZIyHw1Itfi96MjiiCqxsySZtuBvSvmxB9iCeqXyVHyBBgBLNBuKRFWG7TXRB CdSQ== X-Gm-Message-State: ACrzQf0rc3pKrhu8DB0CW43Nee/Cmr9YFguM+pqYq+9CBjRBD0QlXSVZ P/zu+f/LW0lLkI/+IgqjFDNgSQ== 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: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221025_124953_406855_C1118F93 X-CRM114-Status: GOOD ( 27.75 ) 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, > > 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel