Message ID | 20230424105011.70674-1-n-francis@ti.com |
---|---|
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp2652493vqo; Mon, 24 Apr 2023 03:58:48 -0700 (PDT) X-Google-Smtp-Source: AKy350YYPtDcu0DHlZDvRYK0e0KUP21BkAiSqgha0+zK7dS0rFmvPdHIU/RHPB/b3LgXic0PUqWm X-Received: by 2002:a05:6a21:6da2:b0:f0:b2f2:2020 with SMTP id wl34-20020a056a216da200b000f0b2f22020mr16647831pzb.50.1682333928118; Mon, 24 Apr 2023 03:58:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1682333928; cv=none; d=google.com; s=arc-20160816; b=O8mpNLe7RR2K+oiQZ2PYF3sQfqQOWB0LJJYtPg7lMdwjWMbpqFl3Pdhe8oi95Co3/O Nxegm7gLIeLJRwYCAbEKQiUEa1XbcoDLpy+Kff0/umQ7Vqo9gtvVqEGfqAYTStJdby8E 3jPtRPYwJpPYXHN1v+OKtSDtiPpeijeeH5LvqgqsKpgGuk4o366sRj7kabGDt6wqZvnU m5JuGesiFaPRz4ZThNMMpenkQai9lrtBNmnpmWTk9yHhHSgCOPDz4H9pOkAA9BO1E3wX G75Y7Xbeh2upNxWWJWSVo3lN5y6iRns/mgpjirBjjmL7NiEDogrLbEQd7e2JyArdRzwV LcTA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=nN8VYG0CcZuH7mcRdjGhmPU9mLRfs9U98nGSCM4YgbU=; b=egOGjbfcOk7dLAfYxQ5skL+EzrbBO9VALUbgZ2JEiMKvbJI9QB45Q6RizV+quCXbxt QrJjA7UQlMMrmRE2zwZPqyqI+kB9edkpf6a5qM/BADORi1C+xJj3l0piF01jefokyq42 X31Vo4P++EbHMgfD1ACR/fjLuUlSPkhDkoSmRJ5ehL4Sy8rVrqg+8clwfjS+q/WdmclU RPrYq+KjGgWQOFTSD3VD7j11GOUqa3QKf+Dc3P42VVWTNrewfJFD+6u2BOLjNlfwVHEj jGjjPoKerLZrkkPJkbXwN/iwJRA3Gkc02LFAOlMHSlJh7k6vKnpbN3fXI7Xy0krf315g 5nCQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b=QgCE2jhM; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id 72-20020a63074b000000b0051b71bd43b9si11472334pgh.784.2023.04.24.03.58.33; Mon, 24 Apr 2023 03:58:48 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b=QgCE2jhM; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231442AbjDXKum (ORCPT <rfc822;zxc52fgh@gmail.com> + 99 others); Mon, 24 Apr 2023 06:50:42 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36790 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229522AbjDXKuk (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 24 Apr 2023 06:50:40 -0400 Received: from fllv0015.ext.ti.com (fllv0015.ext.ti.com [198.47.19.141]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id ABD1919A; Mon, 24 Apr 2023 03:50:37 -0700 (PDT) Received: from fllv0035.itg.ti.com ([10.64.41.0]) by fllv0015.ext.ti.com (8.15.2/8.15.2) with ESMTP id 33OAoFBX106953; Mon, 24 Apr 2023 05:50:15 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1682333415; bh=nN8VYG0CcZuH7mcRdjGhmPU9mLRfs9U98nGSCM4YgbU=; h=From:To:CC:Subject:Date; b=QgCE2jhMpdfo5D82LAo0/ubwLs4718mQMtJgPjS+DE6mHUoBbcZzJAH9AOK5VSiwK HHK/EIOcpT+zSEXxH+6y+QIzx1NDDm/LTghBWYFcUUsotYh22JASdsRWktL982mglM LWmhlki3lfGHeQo6xeHiFaue0zOcoET+HXvAjje0= Received: from DFLE100.ent.ti.com (dfle100.ent.ti.com [10.64.6.21]) by fllv0035.itg.ti.com (8.15.2/8.15.2) with ESMTPS id 33OAoFM4039323 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 24 Apr 2023 05:50:15 -0500 Received: from DFLE114.ent.ti.com (10.64.6.35) by DFLE100.ent.ti.com (10.64.6.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2507.16; Mon, 24 Apr 2023 05:50:15 -0500 Received: from lelv0326.itg.ti.com (10.180.67.84) by DFLE114.ent.ti.com (10.64.6.35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2507.16 via Frontend Transport; Mon, 24 Apr 2023 05:50:15 -0500 Received: from ula0497641.dhcp.ti.com (ileaxei01-snat2.itg.ti.com [10.180.69.6]) by lelv0326.itg.ti.com (8.15.2/8.15.2) with ESMTP id 33OAoBPD004376; Mon, 24 Apr 2023 05:50:12 -0500 From: Neha Malcom Francis <n-francis@ti.com> To: <robh+dt@kernel.org>, <krzysztof.kozlowski+dt@linaro.org>, <devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>, <linux-arm-kernel@lists.infradead.org>, <jdelvare@suse.com>, <linux@roeck-us.net>, <linux-hwmon@vger.kernel.org> CC: <n-francis@ti.com>, <nm@ti.com>, <vigneshr@ti.com>, <u-kumar1@ti.com>, <kristo@kernel.org> Subject: [PATCH RESEND v3 0/3] Add support for ESM Date: Mon, 24 Apr 2023 16:20:08 +0530 Message-ID: <20230424105011.70674-1-n-francis@ti.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 X-Spam-Status: No, score=-4.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, SPF_HELO_PASS,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1764051967295853833?= X-GMAIL-MSGID: =?utf-8?q?1764054981183008619?= |
Series | Add support for ESM | |
Message
Neha Malcom Francis
April 24, 2023, 10:50 a.m. UTC
Resending as no major changes, commit subject change only. ESM (Error Signaling Module) is a fundamental IP responsible for handling safety events. The driver currently present in U-Boot is responsible for configuring ESM. This patch series adds dt-binding and nodes for J721E and J7200. This goes towards end goal of having DTB sync with that of U-Boot as well as ensuring completeness of hardware description in devicetree. Neha Malcom Francis (3): dt-bindings: hwmon: esm: Add ESM support for TI K3 devices arm64: dts: ti: k3-j721e: Add ESM support arm64: dts: ti: k3-j7200: Add ESM support .../bindings/hwmon/ti,j721e-esm.yaml | 53 +++++++++++++++++++ arch/arm64/boot/dts/ti/k3-j7200-main.dtsi | 6 +++ arch/arm64/boot/dts/ti/k3-j7200.dtsi | 1 + arch/arm64/boot/dts/ti/k3-j721e.dtsi | 1 + 4 files changed, 61 insertions(+) create mode 100644 Documentation/devicetree/bindings/hwmon/ti,j721e-esm.yaml
Comments
On 24/04/2023 12:50, Neha Malcom Francis wrote: > Resending as no major changes, commit subject change only. That's a new version. Keep changelog - for some reason it disappeared. > Best regards, Krzysztof
On 4/24/23 03:50, Neha Malcom Francis wrote: > Resending as no major changes, commit subject change only. > Maybe you consider changing the subject of the bindings from "misc" to "hwmon" as not being a major change, but it made me aware that you are trying to sneak bindings which in my opinion don't belong there into the hwmon bindings directory. This is not a hardware monitoring device, it doesn't have anything to do with hardware monitoring, and the bindings do not belong into bindings/hwmon/. Maybe you can convince the devicetree maintainers to accept the bindings into the suggested location, but that will be over my objection. Guenter > ESM (Error Signaling Module) is a fundamental IP responsible for > handling safety events. The driver currently present in U-Boot is > responsible for configuring ESM. This patch series adds dt-binding and > nodes for J721E and J7200. This goes towards end goal of having DTB sync > with that of U-Boot as well as ensuring completeness of hardware > description in devicetree. > > Neha Malcom Francis (3): > dt-bindings: hwmon: esm: Add ESM support for TI K3 devices > arm64: dts: ti: k3-j721e: Add ESM support > arm64: dts: ti: k3-j7200: Add ESM support > > .../bindings/hwmon/ti,j721e-esm.yaml | 53 +++++++++++++++++++ > arch/arm64/boot/dts/ti/k3-j7200-main.dtsi | 6 +++ > arch/arm64/boot/dts/ti/k3-j7200.dtsi | 1 + > arch/arm64/boot/dts/ti/k3-j721e.dtsi | 1 + > 4 files changed, 61 insertions(+) > create mode 100644 Documentation/devicetree/bindings/hwmon/ti,j721e-esm.yaml >
Hi Guenter On 24/04/23 20:27, Guenter Roeck wrote: > On 4/24/23 03:50, Neha Malcom Francis wrote: >> Resending as no major changes, commit subject change only. >> > > Maybe you consider changing the subject of the bindings from "misc" > to "hwmon" as not being a major change, but it made me aware that you > are trying to sneak bindings which in my opinion don't belong there > into the hwmon bindings directory. This is not a hardware monitoring > device, it doesn't have anything to do with hardware monitoring, and the > bindings do not belong into bindings/hwmon/. > I understand, it's a thin line across which I pushed ESM into hwmon; my reasoning was ESM also actively looks for signals that it aggregates, and is overall monitoring the device health. But if there was an option, in order of fitting: fault/ > misc/ > hwmon/ Using misc/ was questioned in an earlier review; and fault/ is not yet created and I did not think there were enough instances to back me up on creating a new dt-bindings dir To come to a common solution, let us keep this binding in misc/ along with other fault detection mechanisms existing and take it up as a follow up action to create a fault/ ? > Maybe you can convince the devicetree maintainers to accept the bindings > into the suggested location, but that will be over my objection. > > Guenter > > >> ESM (Error Signaling Module) is a fundamental IP responsible for >> handling safety events. The driver currently present in U-Boot is >> responsible for configuring ESM. This patch series adds dt-binding and >> nodes for J721E and J7200. This goes towards end goal of having DTB sync >> with that of U-Boot as well as ensuring completeness of hardware >> description in devicetree. >> >> Neha Malcom Francis (3): >> dt-bindings: hwmon: esm: Add ESM support for TI K3 devices >> arm64: dts: ti: k3-j721e: Add ESM support >> arm64: dts: ti: k3-j7200: Add ESM support >> >> .../bindings/hwmon/ti,j721e-esm.yaml | 53 +++++++++++++++++++ >> arch/arm64/boot/dts/ti/k3-j7200-main.dtsi | 6 +++ >> arch/arm64/boot/dts/ti/k3-j7200.dtsi | 1 + >> arch/arm64/boot/dts/ti/k3-j721e.dtsi | 1 + >> 4 files changed, 61 insertions(+) >> create mode 100644 >> Documentation/devicetree/bindings/hwmon/ti,j721e-esm.yaml >> >
On 4/25/23 01:49, Neha Malcom Francis wrote: > Hi Guenter > > On 24/04/23 20:27, Guenter Roeck wrote: >> On 4/24/23 03:50, Neha Malcom Francis wrote: >>> Resending as no major changes, commit subject change only. >>> >> >> Maybe you consider changing the subject of the bindings from "misc" >> to "hwmon" as not being a major change, but it made me aware that you >> are trying to sneak bindings which in my opinion don't belong there >> into the hwmon bindings directory. This is not a hardware monitoring >> device, it doesn't have anything to do with hardware monitoring, and the >> bindings do not belong into bindings/hwmon/. >> > > I understand, it's a thin line across which I pushed ESM into hwmon; my reasoning was ESM also actively looks for signals that it aggregates, and is overall monitoring the device health. But if there was an option, in order of fitting: fault/ > misc/ > hwmon/ > That is really a stretch. It doesn't monitor anything. It is a signal routing mechanism. With that logic every transistor would be a hardware monitoring device. Guenter
On 25/04/2023 16:34, Guenter Roeck wrote: > On 4/25/23 01:49, Neha Malcom Francis wrote: >> Hi Guenter >> >> On 24/04/23 20:27, Guenter Roeck wrote: >>> On 4/24/23 03:50, Neha Malcom Francis wrote: >>>> Resending as no major changes, commit subject change only. >>>> >>> >>> Maybe you consider changing the subject of the bindings from "misc" >>> to "hwmon" as not being a major change, but it made me aware that you >>> are trying to sneak bindings which in my opinion don't belong there >>> into the hwmon bindings directory. This is not a hardware monitoring >>> device, it doesn't have anything to do with hardware monitoring, and the >>> bindings do not belong into bindings/hwmon/. >>> >> >> I understand, it's a thin line across which I pushed ESM into hwmon; my reasoning was ESM also actively looks for signals that it aggregates, and is overall monitoring the device health. But if there was an option, in order of fitting: fault/ > misc/ > hwmon/ >> > > That is really a stretch. It doesn't monitor anything. It is a signal > routing mechanism. > > With that logic every transistor would be a hardware monitoring device. Then let's move it to misc/ as I don't have other ideas for the placement. Best regards, Krzysztof