Message ID | 20240119094105.98312-1-angelogioacchino.delregno@collabora.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-30960-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7301:2bc4:b0:101:a8e8:374 with SMTP id hx4csp896511dyb; Fri, 19 Jan 2024 01:41:48 -0800 (PST) X-Google-Smtp-Source: AGHT+IH/ZsgqUOxl2bBn0weh3a1T+DlCTGhQ2jQB/fdnLSlJxe8Gbhxq6bDDp7+HI/4J5yFR4N2x X-Received: by 2002:a17:903:22cf:b0:1d7:24e3:7047 with SMTP id y15-20020a17090322cf00b001d724e37047mr184144plg.135.1705657308464; Fri, 19 Jan 2024 01:41:48 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1705657308; cv=pass; d=google.com; s=arc-20160816; b=W3oD3+y/aKk/GPrcpDuqVlwQvFi/FtvyeMaa6kQNgfoyt0U76dHlz1a8g37FxPDyQH kIS0FgpVFw7r+5e5YzLCaNZKRsb01SN7/CismB1Zi+PiK4jZJz5Zu9FertC1J6F8dbzv UcYNklTsuigOoQaRWZ+F2G2mMkfrzPhcJGr9nxDFv7sWpKrEJaO0/rDPv79G3YaQgVZ3 D23wgvFCnNlj/2FNP/ML6M5+IODbS4K8mcfP6tQ2B9vyYnofmtIkcQTnrE9rYuEn6+gF OL7TahaB4SANUW07mgEjD2TyAHZ4kw25ZJsDW0mrqgUD5NliD5SIuFmMkvGSmjqzvcOT jnAw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:message-id:date:subject:cc:to :from:dkim-signature; bh=wwZKZUjRjs3XCXeM2yTPtJdlhSE2Am3dRvCgFqrlgko=; fh=3DbeS6A7vcTHowuUhqVVSmrEZTARSFLKViMoRhstT5w=; b=gklzPSaKt1mWl4/CrGUvoiROV4hyOr6vum9JgZwXIhWMd66IJc8WJtQjSv2zx7k9Nv gXu1GPO6LCHxXgL+VjpeHrMZ/Gf/gkliOmg4BMV6JVIG4vJNit2Tfjyai3TfUWZqziTq QdgF4CVb5sfuX7NHUuBsOPH2FqsSw3MiUdsjCV2KwCEslk1H1/XD5jodDdUR0TJwFi4B OQZ4xrupIAnoRxTPDvX5AqOl3nmfB0h7L67TER8e1cv9NPTRk9m1wYLdfXIbK/5GrBPE VRad3M9oCmvhOVkTz9Zo3iwl857rBs3oCZ8CsyQY5b9ZplM33GfdOp1nJjbWWyoIIUCy GOHQ== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@collabora.com header.s=mail header.b=4TpAef1m; arc=pass (i=1 spf=pass spfdomain=collabora.com dkim=pass dkdomain=collabora.com dmarc=pass fromdomain=collabora.com); spf=pass (google.com: domain of linux-kernel+bounces-30960-ouuuleilei=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-30960-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=collabora.com Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [139.178.88.99]) by mx.google.com with ESMTPS id t8-20020a170902bc4800b001d6f3a92b6dsi3008895plz.179.2024.01.19.01.41.48 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 19 Jan 2024 01:41:48 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-30960-ouuuleilei=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99; Authentication-Results: mx.google.com; dkim=pass header.i=@collabora.com header.s=mail header.b=4TpAef1m; arc=pass (i=1 spf=pass spfdomain=collabora.com dkim=pass dkdomain=collabora.com dmarc=pass fromdomain=collabora.com); spf=pass (google.com: domain of linux-kernel+bounces-30960-ouuuleilei=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-30960-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=collabora.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id 4E2D8285C30 for <ouuuleilei@gmail.com>; Fri, 19 Jan 2024 09:41:33 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 5F9663C494; Fri, 19 Jan 2024 09:41:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=collabora.com header.i=@collabora.com header.b="4TpAef1m" Received: from madrid.collaboradmins.com (madrid.collaboradmins.com [46.235.227.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4BCEE8F4E; Fri, 19 Jan 2024 09:41:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=46.235.227.194 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1705657272; cv=none; b=ria8YcpI40T19Edc20Ta5Gy71hPUDZP3y3ZFka/UAWYlwvpdzEeKkeQxxRhjhh/SYbq3expPhY93OtHzzU7fXrK1o/JFiPVnkRqe6k1rC5On7E8pBv/e3onxm4D4KfIOpDFU/1kybnht79xxPqZitsRoS7h4A9cA12EkTpsr79s= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1705657272; c=relaxed/simple; bh=0cDiESFvb7qa9miqI4BzCZ+472VCEQGuIk9jkGeCoRw=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=orS3RZ97xnUKvDl5wo5r8Tc4WXciFg0HRmQN4DIyJ5WM54TcTrJmenpqlEKRe5U7j4RT8Vvi/fN6nPI6ZWXkBreToLNded/cPzgBsG+wZ971ZkvruIqKv9N057m+u2V60HCbZsh5rLXvcnZERlQzU6T9fgBmHqpTG4aQyFIqwGI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=collabora.com; spf=pass smtp.mailfrom=collabora.com; dkim=pass (2048-bit key) header.d=collabora.com header.i=@collabora.com header.b=4TpAef1m; arc=none smtp.client-ip=46.235.227.194 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=collabora.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=collabora.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1705657269; bh=0cDiESFvb7qa9miqI4BzCZ+472VCEQGuIk9jkGeCoRw=; h=From:To:Cc:Subject:Date:From; b=4TpAef1mYqd/vXLVqPxRe+vRI+fmsaz79QlIT5ypjuDI09RFBTsEZM6vwSCyZRpfC JW7ULhVzEtdRVphkjqkhLQpFGtHSXq/e5nbCAbCv//33K4hFSZM9ApTPMwguJ6oVRp A3d5MekwJLbfuZ5xzzPG6GreWj980WVOH86OHxtcMw5ADzYrzGROfjVGSFYledLfQv u7BPKoGXRGUmAU94knmOFR6rd/7reWdgPl3jLGkzRcswBjwXNnXZfpKUqpY6OcpUMW Ffq8KkJ6EISw7LxSVAkMnAggqT4Bw8sfgv9ugvw6GY0OHBbClbDKtGcgR4uezKmaVe HRAeHRMDAhWiQ== Received: from IcarusMOD.eternityproject.eu (cola.collaboradmins.com [195.201.22.229]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: kholk11) by madrid.collaboradmins.com (Postfix) with ESMTPSA id 7088D37811F1; Fri, 19 Jan 2024 09:41:08 +0000 (UTC) From: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> To: chunfeng.yun@mediatek.com Cc: gregkh@linuxfoundation.org, robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org, conor+dt@kernel.org, matthias.bgg@gmail.com, angelogioacchino.delregno@collabora.com, linux@roeck-us.net, heikki.krogerus@linux.intel.com, cy_huang@richtek.com, linux-usb@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v2 1/2] dt-bindings: usb: mt6360-tcpc: Drop interrupt-names Date: Fri, 19 Jan 2024 10:41:04 +0100 Message-ID: <20240119094105.98312-1-angelogioacchino.delregno@collabora.com> X-Mailer: git-send-email 2.43.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1788511317596123495 X-GMAIL-MSGID: 1788511317596123495 |
Series |
[v2,1/2] dt-bindings: usb: mt6360-tcpc: Drop interrupt-names
|
|
Commit Message
AngeloGioacchino Del Regno
Jan. 19, 2024, 9:41 a.m. UTC
This IP has only one interrupt, hence interrupt-names is not necessary
to have.
Since there is no user yet, simply remove interrupt-names.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
---
.../devicetree/bindings/usb/mediatek,mt6360-tcpc.yaml | 5 -----
1 file changed, 5 deletions(-)
Comments
On Fri, 19 Jan 2024 10:41:04 +0100, AngeloGioacchino Del Regno wrote: > This IP has only one interrupt, hence interrupt-names is not necessary > to have. > Since there is no user yet, simply remove interrupt-names. > > Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> > --- > .../devicetree/bindings/usb/mediatek,mt6360-tcpc.yaml | 5 ----- > 1 file changed, 5 deletions(-) > My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check' on your patch (DT_CHECKER_FLAGS is new in v5.13): yamllint warnings/errors: dtschema/dtc warnings/errors: /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/usb/mediatek,mt6360-tcpc.example.dtb: mt6360@34: tcpc: 'interrupt-names' is a required property from schema $id: http://devicetree.org/schemas/mfd/mediatek,mt6360.yaml# /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/usb/mediatek,mt6360-tcpc.example.dtb: tcpc: 'interrupt-names' is a required property from schema $id: http://devicetree.org/schemas/usb/mediatek,mt6360-tcpc.yaml# /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/mfd/mediatek,mt6360.example.dtb: pmic@34: tcpc: 'interrupt-names' does not match any of the regexes: 'pinctrl-[0-9]+' from schema $id: http://devicetree.org/schemas/mfd/mediatek,mt6360.yaml# /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/mfd/mediatek,mt6360.example.dtb: tcpc: 'interrupt-names' does not match any of the regexes: 'pinctrl-[0-9]+' from schema $id: http://devicetree.org/schemas/usb/mediatek,mt6360-tcpc.yaml# doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20240119094105.98312-1-angelogioacchino.delregno@collabora.com The base for the series is generally the latest rc1. A different dependency should be noted in *this* patch. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit after running the above command yourself. Note that DT_SCHEMA_FILES can be set to your schema file to speed up checking your schema. However, it must be unset to test all examples with your schema.
On Fri, Jan 19, 2024 at 10:41:04AM +0100, AngeloGioacchino Del Regno wrote: > This IP has only one interrupt, hence interrupt-names is not necessary > to have. > Since there is no user yet, simply remove interrupt-names. I'm a bit confused chief. Patch 2 in this series removes a user of this property from a driver, so can you explain how this statement is true? Maybe I need to drink a few cans of Monster and revisit this patchset? Thanks, Conor. > --- > .../devicetree/bindings/usb/mediatek,mt6360-tcpc.yaml | 5 ----- > 1 file changed, 5 deletions(-) > > diff --git a/Documentation/devicetree/bindings/usb/mediatek,mt6360-tcpc.yaml b/Documentation/devicetree/bindings/usb/mediatek,mt6360-tcpc.yaml > index 053264e60583..339bc9c00ac0 100644 > --- a/Documentation/devicetree/bindings/usb/mediatek,mt6360-tcpc.yaml > +++ b/Documentation/devicetree/bindings/usb/mediatek,mt6360-tcpc.yaml > @@ -22,10 +22,6 @@ properties: > interrupts: > maxItems: 1 > > - interrupt-names: > - items: > - - const: PD_IRQB > - > connector: > type: object > $ref: ../connector/usb-connector.yaml# > @@ -58,7 +54,6 @@ examples: > tcpc { > compatible = "mediatek,mt6360-tcpc"; > interrupts-extended = <&gpio26 3 IRQ_TYPE_LEVEL_LOW>; > - interrupt-names = "PD_IRQB"; > > connector { > compatible = "usb-c-connector"; > -- > 2.43.0 >
Il 19/01/24 17:32, Conor Dooley ha scritto: > On Fri, Jan 19, 2024 at 10:41:04AM +0100, AngeloGioacchino Del Regno wrote: >> This IP has only one interrupt, hence interrupt-names is not necessary >> to have. >> Since there is no user yet, simply remove interrupt-names. > > I'm a bit confused chief. Patch 2 in this series removes a user of this > property from a driver, so can you explain how this statement is true? > > Maybe I need to drink a few cans of Monster and revisit this patchset? > What I mean with "there is no user" is that there's no device tree with any mt6360-tcpc node upstream yet, so there is no meaningful ABI breakage. Different story would be if there was a device tree using this already, in which case, you can make a required property optional but not remove it. Anything wrong?! :-) Cheers, Angelo > Thanks, > Conor. > >> --- >> .../devicetree/bindings/usb/mediatek,mt6360-tcpc.yaml | 5 ----- >> 1 file changed, 5 deletions(-) >> >> diff --git a/Documentation/devicetree/bindings/usb/mediatek,mt6360-tcpc.yaml b/Documentation/devicetree/bindings/usb/mediatek,mt6360-tcpc.yaml >> index 053264e60583..339bc9c00ac0 100644 >> --- a/Documentation/devicetree/bindings/usb/mediatek,mt6360-tcpc.yaml >> +++ b/Documentation/devicetree/bindings/usb/mediatek,mt6360-tcpc.yaml >> @@ -22,10 +22,6 @@ properties: >> interrupts: >> maxItems: 1 >> >> - interrupt-names: >> - items: >> - - const: PD_IRQB >> - >> connector: >> type: object >> $ref: ../connector/usb-connector.yaml# >> @@ -58,7 +54,6 @@ examples: >> tcpc { >> compatible = "mediatek,mt6360-tcpc"; >> interrupts-extended = <&gpio26 3 IRQ_TYPE_LEVEL_LOW>; >> - interrupt-names = "PD_IRQB"; >> >> connector { >> compatible = "usb-c-connector"; >> -- >> 2.43.0 >>
On Mon, Jan 22, 2024 at 11:32:30AM +0100, AngeloGioacchino Del Regno wrote: > Il 19/01/24 17:32, Conor Dooley ha scritto: > > On Fri, Jan 19, 2024 at 10:41:04AM +0100, AngeloGioacchino Del Regno wrote: > > > This IP has only one interrupt, hence interrupt-names is not necessary > > > to have. > > > Since there is no user yet, simply remove interrupt-names. > > > > I'm a bit confused chief. Patch 2 in this series removes a user of this > > property from a driver, so can you explain how this statement is true? > > > > Maybe I need to drink a few cans of Monster and revisit this patchset? > > > > What I mean with "there is no user" is that there's no device tree with any > mt6360-tcpc node upstream yet, so there is no meaningful ABI breakage. > Different story would be if there was a device tree using this already, in > which case, you can make a required property optional but not remove it. Not every devicetree lives within the kernel.. If the driver is using it, I'm not inclined to agree that it should be removed.
On Wed, Jan 24, 2024 at 09:48:23AM +0100, AngeloGioacchino Del Regno wrote: > Il 23/01/24 18:14, Conor Dooley ha scritto: > > On Mon, Jan 22, 2024 at 11:32:30AM +0100, AngeloGioacchino Del Regno wrote: > > > Il 19/01/24 17:32, Conor Dooley ha scritto: > > > > On Fri, Jan 19, 2024 at 10:41:04AM +0100, AngeloGioacchino Del Regno wrote: > > > > > This IP has only one interrupt, hence interrupt-names is not necessary > > > > > to have. > > > > > Since there is no user yet, simply remove interrupt-names. > > > > > > > > I'm a bit confused chief. Patch 2 in this series removes a user of this > > > > property from a driver, so can you explain how this statement is true? > > > > > > > > Maybe I need to drink a few cans of Monster and revisit this patchset? > > > > > > > > > > What I mean with "there is no user" is that there's no device tree with any > > > mt6360-tcpc node upstream yet, so there is no meaningful ABI breakage. > > > Different story would be if there was a device tree using this already, in > > > which case, you can make a required property optional but not remove it. > > > > Not every devicetree lives within the kernel.. If the driver is using > > it, I'm not inclined to agree that it should be removed. > > I get the point, but as far as I remember, it's not the first time that this > kind of change is upstreamed. > > I'm fine with keeping things as they are but, since my intention is to actually > introduce an actual user of this binding upstream, and that actually depends on > if this change is accepted or not (as I have to know whether I can omit adding > the interrupt-names property or not).... > > ....may I ask for more feedback/opinions from Rob and/or Krzk? Sure, I am happy to be overruled if they disagree.
On 24/01/2024 09:48, AngeloGioacchino Del Regno wrote: > Il 23/01/24 18:14, Conor Dooley ha scritto: >> On Mon, Jan 22, 2024 at 11:32:30AM +0100, AngeloGioacchino Del Regno wrote: >>> Il 19/01/24 17:32, Conor Dooley ha scritto: >>>> On Fri, Jan 19, 2024 at 10:41:04AM +0100, AngeloGioacchino Del Regno wrote: >>>>> This IP has only one interrupt, hence interrupt-names is not necessary >>>>> to have. >>>>> Since there is no user yet, simply remove interrupt-names. >>>> >>>> I'm a bit confused chief. Patch 2 in this series removes a user of this >>>> property from a driver, so can you explain how this statement is true? >>>> >>>> Maybe I need to drink a few cans of Monster and revisit this patchset? >>>> >>> >>> What I mean with "there is no user" is that there's no device tree with any >>> mt6360-tcpc node upstream yet, so there is no meaningful ABI breakage. >>> Different story would be if there was a device tree using this already, in >>> which case, you can make a required property optional but not remove it. >> >> Not every devicetree lives within the kernel.. If the driver is using >> it, I'm not inclined to agree that it should be removed. > > I get the point, but as far as I remember, it's not the first time that this > kind of change is upstreamed. > > I'm fine with keeping things as they are but, since my intention is to actually > introduce an actual user of this binding upstream, and that actually depends on > if this change is accepted or not (as I have to know whether I can omit adding > the interrupt-names property or not).... > > ....may I ask for more feedback/opinions from Rob and/or Krzk? Driver is the user and this is an old binding (released!), thus there can be out-of-kernel users already. Minor cleanup is not really a reason to affect ABI. You could deprecate it, though. Driver change is fine. Best regards, Krzysztof
Il 25/01/24 11:32, Krzysztof Kozlowski ha scritto: > On 24/01/2024 09:48, AngeloGioacchino Del Regno wrote: >> Il 23/01/24 18:14, Conor Dooley ha scritto: >>> On Mon, Jan 22, 2024 at 11:32:30AM +0100, AngeloGioacchino Del Regno wrote: >>>> Il 19/01/24 17:32, Conor Dooley ha scritto: >>>>> On Fri, Jan 19, 2024 at 10:41:04AM +0100, AngeloGioacchino Del Regno wrote: >>>>>> This IP has only one interrupt, hence interrupt-names is not necessary >>>>>> to have. >>>>>> Since there is no user yet, simply remove interrupt-names. >>>>> >>>>> I'm a bit confused chief. Patch 2 in this series removes a user of this >>>>> property from a driver, so can you explain how this statement is true? >>>>> >>>>> Maybe I need to drink a few cans of Monster and revisit this patchset? >>>>> >>>> >>>> What I mean with "there is no user" is that there's no device tree with any >>>> mt6360-tcpc node upstream yet, so there is no meaningful ABI breakage. >>>> Different story would be if there was a device tree using this already, in >>>> which case, you can make a required property optional but not remove it. >>> >>> Not every devicetree lives within the kernel.. If the driver is using >>> it, I'm not inclined to agree that it should be removed. >> >> I get the point, but as far as I remember, it's not the first time that this >> kind of change is upstreamed. >> >> I'm fine with keeping things as they are but, since my intention is to actually >> introduce an actual user of this binding upstream, and that actually depends on >> if this change is accepted or not (as I have to know whether I can omit adding >> the interrupt-names property or not).... >> >> ....may I ask for more feedback/opinions from Rob and/or Krzk? > > Driver is the user and this is an old binding (released!), thus there > can be out-of-kernel users already. > > Minor cleanup is not really a reason to affect ABI. You could deprecate > it, though. Driver change is fine. > Thanks for the clarification. If USB maintainers want to take the driver part only without me resending this, I'd appreciate that. The interrupt-names is not a required property in this binding anyway... :-) Thanks again, Angelo
On Thu, Jan 25, 2024 at 12:41:57PM +0100, AngeloGioacchino Del Regno wrote: > Il 25/01/24 11:32, Krzysztof Kozlowski ha scritto: > > On 24/01/2024 09:48, AngeloGioacchino Del Regno wrote: > > > Il 23/01/24 18:14, Conor Dooley ha scritto: > > > > On Mon, Jan 22, 2024 at 11:32:30AM +0100, AngeloGioacchino Del Regno wrote: > > > > > Il 19/01/24 17:32, Conor Dooley ha scritto: > > > > > > On Fri, Jan 19, 2024 at 10:41:04AM +0100, AngeloGioacchino Del Regno wrote: > > > > > > > This IP has only one interrupt, hence interrupt-names is not necessary > > > > > > > to have. > > > > > > > Since there is no user yet, simply remove interrupt-names. > > > > > > > > > > > > I'm a bit confused chief. Patch 2 in this series removes a user of this > > > > > > property from a driver, so can you explain how this statement is true? > > > > > > > > > > > > Maybe I need to drink a few cans of Monster and revisit this patchset? > > > > > > > > > > > > > > > > What I mean with "there is no user" is that there's no device tree with any > > > > > mt6360-tcpc node upstream yet, so there is no meaningful ABI breakage. > > > > > Different story would be if there was a device tree using this already, in > > > > > which case, you can make a required property optional but not remove it. > > > > > > > > Not every devicetree lives within the kernel.. If the driver is using > > > > it, I'm not inclined to agree that it should be removed. > > > > > > I get the point, but as far as I remember, it's not the first time that this > > > kind of change is upstreamed. > > > > > > I'm fine with keeping things as they are but, since my intention is to actually > > > introduce an actual user of this binding upstream, and that actually depends on > > > if this change is accepted or not (as I have to know whether I can omit adding > > > the interrupt-names property or not).... > > > > > > ....may I ask for more feedback/opinions from Rob and/or Krzk? > > > > Driver is the user and this is an old binding (released!), thus there > > can be out-of-kernel users already. > > > > Minor cleanup is not really a reason to affect ABI. You could deprecate > > it, though. Driver change is fine. > > > > Thanks for the clarification. If USB maintainers want to take the driver part only > without me resending this, I'd appreciate that. > > The interrupt-names is not a required property in this binding anyway... :-) Having -names properties that are not required when the base property is always seem so pointless to me, except in cases where they're not required for the case where there's one item but required when there are more than one. Ultimately they're pointless if not required since they can't be relied on. I think dropping it from the driver is required for correctness.
On Thu, Jan 25, 2024 at 04:57:33PM +0000, Conor Dooley wrote: > On Thu, Jan 25, 2024 at 12:41:57PM +0100, AngeloGioacchino Del Regno wrote: > > Il 25/01/24 11:32, Krzysztof Kozlowski ha scritto: > > > On 24/01/2024 09:48, AngeloGioacchino Del Regno wrote: > > > > Il 23/01/24 18:14, Conor Dooley ha scritto: > > > > > On Mon, Jan 22, 2024 at 11:32:30AM +0100, AngeloGioacchino Del Regno wrote: > > > > > > Il 19/01/24 17:32, Conor Dooley ha scritto: > > > > > > > On Fri, Jan 19, 2024 at 10:41:04AM +0100, AngeloGioacchino Del Regno wrote: > > > > > > > > This IP has only one interrupt, hence interrupt-names is not necessary > > > > > > > > to have. > > > > > > > > Since there is no user yet, simply remove interrupt-names. > > > > > > > > > > > > > > I'm a bit confused chief. Patch 2 in this series removes a user of this > > > > > > > property from a driver, so can you explain how this statement is true? > > > > > > > > > > > > > > Maybe I need to drink a few cans of Monster and revisit this patchset? > > > > > > > > > > > > > > > > > > > What I mean with "there is no user" is that there's no device tree with any > > > > > > mt6360-tcpc node upstream yet, so there is no meaningful ABI breakage. > > > > > > Different story would be if there was a device tree using this already, in > > > > > > which case, you can make a required property optional but not remove it. > > > > > > > > > > Not every devicetree lives within the kernel.. If the driver is using > > > > > it, I'm not inclined to agree that it should be removed. > > > > > > > > I get the point, but as far as I remember, it's not the first time that this > > > > kind of change is upstreamed. > > > > > > > > I'm fine with keeping things as they are but, since my intention is to actually > > > > introduce an actual user of this binding upstream, and that actually depends on > > > > if this change is accepted or not (as I have to know whether I can omit adding > > > > the interrupt-names property or not).... > > > > > > > > ....may I ask for more feedback/opinions from Rob and/or Krzk? > > > > > > Driver is the user and this is an old binding (released!), thus there > > > can be out-of-kernel users already. > > > > > > Minor cleanup is not really a reason to affect ABI. You could deprecate > > > it, though. Driver change is fine. > > > > > > > Thanks for the clarification. If USB maintainers want to take the driver part only > > without me resending this, I'd appreciate that. > > > > > The interrupt-names is not a required property in this binding anyway... :-) > > Having -names properties that are not required when the base property is > always seem so pointless to me, except in cases where they're not > required for the case where there's one item but required when there are > more than one. Ultimately they're pointless if not required since they > can't be relied on. I think dropping it from the driver is required for > correctness. Actually, looking at the binding again: | required: | - compatible | - interrupts | - interrupt-names It looks like it is a required property after all!
Il 25/01/24 18:02, Conor Dooley ha scritto: > On Thu, Jan 25, 2024 at 04:57:33PM +0000, Conor Dooley wrote: >> On Thu, Jan 25, 2024 at 12:41:57PM +0100, AngeloGioacchino Del Regno wrote: >>> Il 25/01/24 11:32, Krzysztof Kozlowski ha scritto: >>>> On 24/01/2024 09:48, AngeloGioacchino Del Regno wrote: >>>>> Il 23/01/24 18:14, Conor Dooley ha scritto: >>>>>> On Mon, Jan 22, 2024 at 11:32:30AM +0100, AngeloGioacchino Del Regno wrote: >>>>>>> Il 19/01/24 17:32, Conor Dooley ha scritto: >>>>>>>> On Fri, Jan 19, 2024 at 10:41:04AM +0100, AngeloGioacchino Del Regno wrote: >>>>>>>>> This IP has only one interrupt, hence interrupt-names is not necessary >>>>>>>>> to have. >>>>>>>>> Since there is no user yet, simply remove interrupt-names. >>>>>>>> >>>>>>>> I'm a bit confused chief. Patch 2 in this series removes a user of this >>>>>>>> property from a driver, so can you explain how this statement is true? >>>>>>>> >>>>>>>> Maybe I need to drink a few cans of Monster and revisit this patchset? >>>>>>>> >>>>>>> >>>>>>> What I mean with "there is no user" is that there's no device tree with any >>>>>>> mt6360-tcpc node upstream yet, so there is no meaningful ABI breakage. >>>>>>> Different story would be if there was a device tree using this already, in >>>>>>> which case, you can make a required property optional but not remove it. >>>>>> >>>>>> Not every devicetree lives within the kernel.. If the driver is using >>>>>> it, I'm not inclined to agree that it should be removed. >>>>> >>>>> I get the point, but as far as I remember, it's not the first time that this >>>>> kind of change is upstreamed. >>>>> >>>>> I'm fine with keeping things as they are but, since my intention is to actually >>>>> introduce an actual user of this binding upstream, and that actually depends on >>>>> if this change is accepted or not (as I have to know whether I can omit adding >>>>> the interrupt-names property or not).... >>>>> >>>>> ....may I ask for more feedback/opinions from Rob and/or Krzk? >>>> >>>> Driver is the user and this is an old binding (released!), thus there >>>> can be out-of-kernel users already. >>>> >>>> Minor cleanup is not really a reason to affect ABI. You could deprecate >>>> it, though. Driver change is fine. >>>> >>> >>> Thanks for the clarification. If USB maintainers want to take the driver part only >>> without me resending this, I'd appreciate that. >>> >> >>> The interrupt-names is not a required property in this binding anyway... :-) >> >> Having -names properties that are not required when the base property is >> always seem so pointless to me, except in cases where they're not >> required for the case where there's one item but required when there are >> more than one. Ultimately they're pointless if not required since they >> can't be relied on. I think dropping it from the driver is required for >> correctness. > > Actually, looking at the binding again: > > | required: > | - compatible > | - interrupts > | - interrupt-names > > It looks like it is a required property after all! Apparently my brain's binding had required: - blindness :-P Yeah, I have no idea why I didn't see that, sorry! Cheers, Angelo
diff --git a/Documentation/devicetree/bindings/usb/mediatek,mt6360-tcpc.yaml b/Documentation/devicetree/bindings/usb/mediatek,mt6360-tcpc.yaml index 053264e60583..339bc9c00ac0 100644 --- a/Documentation/devicetree/bindings/usb/mediatek,mt6360-tcpc.yaml +++ b/Documentation/devicetree/bindings/usb/mediatek,mt6360-tcpc.yaml @@ -22,10 +22,6 @@ properties: interrupts: maxItems: 1 - interrupt-names: - items: - - const: PD_IRQB - connector: type: object $ref: ../connector/usb-connector.yaml# @@ -58,7 +54,6 @@ examples: tcpc { compatible = "mediatek,mt6360-tcpc"; interrupts-extended = <&gpio26 3 IRQ_TYPE_LEVEL_LOW>; - interrupt-names = "PD_IRQB"; connector { compatible = "usb-c-connector";