Message ID | 20240201120332.4811-5-rogerq@kernel.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-48070-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7301:2719:b0:106:209c:c626 with SMTP id hl25csp99644dyb; Thu, 1 Feb 2024 04:06:15 -0800 (PST) X-Google-Smtp-Source: AGHT+IGqbVKuauNFeNaXOcEQ93iOoRZbL2XPn50VnV5RWlHd8nCglLy/dRQy60LGeyFb2KsLvYA9 X-Received: by 2002:a17:902:b701:b0:1d9:1b55:a37 with SMTP id d1-20020a170902b70100b001d91b550a37mr4359454pls.50.1706789175235; Thu, 01 Feb 2024 04:06:15 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1706789175; cv=pass; d=google.com; s=arc-20160816; b=hkYEpGJQ2pCNW+0ONFOk7rSyjtoG2lDkbIIr+yYPGR4p3WIcTlQgL5uWoX/LfWsE3h RQy0HU5B6nu80fv9BuOdUdOvaPTbWNyNQ2qGP0WSVp3J3aMlbHC7LeFWoGc+5h6elakZ LuCGwC770/DL4BldS6ad/gLgR45Tn9Z5oWLg4NDJf1qZQ2o7c2ng1rJObXK8vQdkgaTD IqeT/1FKn06qvAoE9A4EHNO3dfkenodLX0w1j/gzh6iWlsmc10QzjBBguPeD/4wfkE5T VATJLNr+1RgMDtf/IiFIV76p+lIY/XUxlLZZRKXLEz/qmsn5umCW9bGYCf/PhESSj+BR ulcw== 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:references:in-reply-to:message-id :date:subject:cc:to:from:dkim-signature; bh=a4R9aCwEOuhNCo3EuUZfZcRnnjJvgGTUPwvej4QhHcw=; fh=CGMJQTcBkZ1ERBeSV7NvF4RLYV2QEgql6Y5X0P+mbzk=; b=e1tPxvGkupQupGLHlUPR6Wb/4IcDZ+/ccQEE86ioZVI7bPkySt4TAkJL7NvT2ax/YM 5HKc9ShpgCPl91WxPHoGlFQliV+NgT+h6oQS+ZipuwAtsOnnbpfnQPf/aGUDzmF4GxFo IRltdh7sRR+OSrDexsyCSVrBfCGj/CI2Y5YPLfZK1bnk/ih/4dHjEq9N9vOJWFEU1lKL P04RXwvnTThBw1i3abKAYLtS7Mh32bt24KQMgpiOCTExTdTT+xm1uxUW+6mkljjf1O3f SL5OewgPnmWocI3uywWidL+tj1R0Z1rNqC0SzhWR3G9m75mH/vJQ8xyNUq8nPYorC0+r 3BGg==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=RdIwrlDG; arc=pass (i=1 dkim=pass dkdomain=kernel.org); spf=pass (google.com: domain of linux-kernel+bounces-48070-ouuuleilei=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-48070-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org X-Forwarded-Encrypted: i=1; AJvYcCUNv4Szdeq/huIkgdNUrHNBFDIx4f+b4oBFx0X5PO9v24+pbG1PzIFASsiX6obFfQSNxCIDYCIU9Ma/oIrpDFB7bwfJEg== Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [139.178.88.99]) by mx.google.com with ESMTPS id n6-20020a170902e54600b001d8a64238b5si12039821plf.174.2024.02.01.04.06.15 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 01 Feb 2024 04:06:15 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-48070-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=@kernel.org header.s=k20201202 header.b=RdIwrlDG; arc=pass (i=1 dkim=pass dkdomain=kernel.org); spf=pass (google.com: domain of linux-kernel+bounces-48070-ouuuleilei=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-48070-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org 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 0249E29069B for <ouuuleilei@gmail.com>; Thu, 1 Feb 2024 12:06:15 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 8E0C9163AA4; Thu, 1 Feb 2024 12:03:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="RdIwrlDG" Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 DC873161B78; Thu, 1 Feb 2024 12:03:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706789035; cv=none; b=ECeQ5PwNaKasskbnjDPz+lx81oBv3OvnCbE3I3m79FltD5+w0tzQEFAio/Wwvg/9y2rF3xbM6LN4ZL+q4wrd7qiy9D+B3iwUOpnMFgENnbg8lcZC3IzXOkLmkfnvDoSFZlVBf896qASSlpx2iZxUseztdCVI0suR/Blz5hNMFbk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706789035; c=relaxed/simple; bh=QKijxRowyGO0xEY4A0DhY/KjCBbcM53bJ5KIE6470MQ=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=q0/XAgRBI9nAhpb/AO718Db/tgaDJ7NXfeDa+trydEn4HV/xRecuoA956c3cvarqDBhM/kIpJAS0gCrsykfG11aKUgoq9DFYOOBrUxi9xpgnjtDDpfEnfDaOeSVrn5pRbS0cJEd9Z4w5YU3mRfjCArV/XeGZjyFB5B3YFNBnpco= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=RdIwrlDG; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1B0A0C433F1; Thu, 1 Feb 2024 12:03:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1706789035; bh=QKijxRowyGO0xEY4A0DhY/KjCBbcM53bJ5KIE6470MQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=RdIwrlDG2R/idRf95zUqsnK6Ec6+IwG1/0bseLHGuo57Um6qSWBLYt8uELe8vdSgY r/brkqwMb5Qm8WN6U9VvlLMXQPCRSgEUOrSf1vF1UlpSGNU9bqqQ59tc8MbAjKAG2I +AWjC3l/95d9z3Y3lX//OsmvXBc395rWlbZmD0kBxV7hqxWgI2wU5KEgkVimCiExmc 3cuk7G5j4kUV71PtWGvkLp4UCizYlLbLSYPzYB2tI7PSgvcE3jwABMZzw7e0ggl/lC NUeJdrBGPKtzCZ7O3z9elcGK8h7TU2VsfrjFCTLH4kki7tkRhdBuNOYNiHxjU13a+6 3aS5sH3KzsntQ== From: Roger Quadros <rogerq@kernel.org> To: nm@ti.com, vigneshr@ti.com Cc: afd@ti.com, kristo@kernel.org, robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org, conor+dt@kernel.org, srk@ti.com, r-gunasekaran@ti.com, b-liu@ti.com, linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Roger Quadros <rogerq@kernel.org> Subject: [PATCH v3 4/5] dt-bindings: usb/ti,am62-usb.yaml: Add PHY2 register space Date: Thu, 1 Feb 2024 14:03:31 +0200 Message-Id: <20240201120332.4811-5-rogerq@kernel.org> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20240201120332.4811-1-rogerq@kernel.org> References: <20240201120332.4811-1-rogerq@kernel.org> 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: 1789698166193437319 X-GMAIL-MSGID: 1789698166193437319 |
Series |
arm64: dts: ti: am62: Add USB support for k3-am62p
|
|
Commit Message
Roger Quadros
Feb. 1, 2024, 12:03 p.m. UTC
So far this was not required but due to the newly identified
Errata i2409 [1] we need to poke this register space.
[1] https://www.ti.com/lit/er/sprz487d/sprz487d.pdf
Signed-off-by: Roger Quadros <rogerq@kernel.org>
---
Notes:
Changelog:
v3 - new patch
Documentation/devicetree/bindings/usb/ti,am62-usb.yaml | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
Comments
On Thu, Feb 01, 2024 at 02:03:31PM +0200, Roger Quadros wrote: > So far this was not required but due to the newly identified > Errata i2409 [1] we need to poke this register space. > > [1] https://www.ti.com/lit/er/sprz487d/sprz487d.pdf > > Signed-off-by: Roger Quadros <rogerq@kernel.org> Acked-by: Conor Dooley <conor.dooley@microchip.com> > --- > > Notes: > Changelog: > > v3 - new patch > > Documentation/devicetree/bindings/usb/ti,am62-usb.yaml | 7 +++++-- > 1 file changed, 5 insertions(+), 2 deletions(-) > > diff --git a/Documentation/devicetree/bindings/usb/ti,am62-usb.yaml b/Documentation/devicetree/bindings/usb/ti,am62-usb.yaml > index fec5651f5602..c02d9d467d9c 100644 > --- a/Documentation/devicetree/bindings/usb/ti,am62-usb.yaml > +++ b/Documentation/devicetree/bindings/usb/ti,am62-usb.yaml > @@ -14,7 +14,9 @@ properties: > const: ti,am62-usb > > reg: > - maxItems: 1 > + items: > + - description: USB CFG register space > + - description: USB PHY2 register space > > ranges: true > > @@ -82,7 +84,8 @@ examples: > > usbss1: usb@f910000 { > compatible = "ti,am62-usb"; > - reg = <0x00 0x0f910000 0x00 0x800>; > + reg = <0x00 0x0f910000 0x00 0x800>, > + <0x00 0x0f918000 0x00 0x400>; Why the double zeros btw? Cheers, Conor. > clocks = <&k3_clks 162 3>; > clock-names = "ref"; > ti,syscon-phy-pll-refclk = <&wkup_conf 0x4018>; > -- > 2.34.1 >
On Thu, Feb 01, 2024 at 06:15:20PM +0000, Conor Dooley wrote: > On Thu, Feb 01, 2024 at 02:03:31PM +0200, Roger Quadros wrote: > > So far this was not required but due to the newly identified > > Errata i2409 [1] we need to poke this register space. > > > > [1] https://www.ti.com/lit/er/sprz487d/sprz487d.pdf > > > > Signed-off-by: Roger Quadros <rogerq@kernel.org> > > Acked-by: Conor Dooley <conor.dooley@microchip.com> Actually, where is the user for this that actually pokes the register space? You're adding another register region, so I went to check how you were handling that in drivers, but there's no driver patch. > > > --- > > > > Notes: > > Changelog: > > > > v3 - new patch > > > > Documentation/devicetree/bindings/usb/ti,am62-usb.yaml | 7 +++++-- > > 1 file changed, 5 insertions(+), 2 deletions(-) > > > > diff --git a/Documentation/devicetree/bindings/usb/ti,am62-usb.yaml b/Documentation/devicetree/bindings/usb/ti,am62-usb.yaml > > index fec5651f5602..c02d9d467d9c 100644 > > --- a/Documentation/devicetree/bindings/usb/ti,am62-usb.yaml > > +++ b/Documentation/devicetree/bindings/usb/ti,am62-usb.yaml > > @@ -14,7 +14,9 @@ properties: > > const: ti,am62-usb > > > > reg: > > - maxItems: 1 > > + items: > > + - description: USB CFG register space > > + - description: USB PHY2 register space > > > > ranges: true > > > > @@ -82,7 +84,8 @@ examples: > > > > usbss1: usb@f910000 { > > compatible = "ti,am62-usb"; > > - reg = <0x00 0x0f910000 0x00 0x800>; > > + reg = <0x00 0x0f910000 0x00 0x800>, > > + <0x00 0x0f918000 0x00 0x400>; > > Why the double zeros btw? > > Cheers, > Conor. > > > clocks = <&k3_clks 162 3>; > > clock-names = "ref"; > > ti,syscon-phy-pll-refclk = <&wkup_conf 0x4018>; > > -- > > 2.34.1 > >
On Thu, Feb 01, 2024 at 06:18:05PM +0000, Conor Dooley wrote: > On Thu, Feb 01, 2024 at 06:15:20PM +0000, Conor Dooley wrote: > > On Thu, Feb 01, 2024 at 02:03:31PM +0200, Roger Quadros wrote: > > > So far this was not required but due to the newly identified > > > Errata i2409 [1] we need to poke this register space. > > > > > > [1] https://www.ti.com/lit/er/sprz487d/sprz487d.pdf > > > > > > Signed-off-by: Roger Quadros <rogerq@kernel.org> > > > > Acked-by: Conor Dooley <conor.dooley@microchip.com> > > Actually, where is the user for this that actually pokes the register > space? > You're adding another register region, so I went to check how you were > handling that in drivers, but there's no driver patch. See Roger's another patch set 'Add workaround for Errata i2409' posted on 16th. -Bin. > > > > > > > --- > > > > > > Notes: > > > Changelog: > > > > > > v3 - new patch > > > > > > Documentation/devicetree/bindings/usb/ti,am62-usb.yaml | 7 +++++-- > > > 1 file changed, 5 insertions(+), 2 deletions(-) > > > > > > diff --git a/Documentation/devicetree/bindings/usb/ti,am62-usb.yaml b/Documentation/devicetree/bindings/usb/ti,am62-usb.yaml > > > index fec5651f5602..c02d9d467d9c 100644 > > > --- a/Documentation/devicetree/bindings/usb/ti,am62-usb.yaml > > > +++ b/Documentation/devicetree/bindings/usb/ti,am62-usb.yaml > > > @@ -14,7 +14,9 @@ properties: > > > const: ti,am62-usb > > > > > > reg: > > > - maxItems: 1 > > > + items: > > > + - description: USB CFG register space > > > + - description: USB PHY2 register space > > > > > > ranges: true > > > > > > @@ -82,7 +84,8 @@ examples: > > > > > > usbss1: usb@f910000 { > > > compatible = "ti,am62-usb"; > > > - reg = <0x00 0x0f910000 0x00 0x800>; > > > + reg = <0x00 0x0f910000 0x00 0x800>, > > > + <0x00 0x0f918000 0x00 0x400>; > > > > Why the double zeros btw? > > > > Cheers, > > Conor. > > > > > clocks = <&k3_clks 162 3>; > > > clock-names = "ref"; > > > ti,syscon-phy-pll-refclk = <&wkup_conf 0x4018>; > > > -- > > > 2.34.1 > > > > >
On Thu, Feb 01, 2024 at 12:35:22PM -0600, Bin Liu wrote: > On Thu, Feb 01, 2024 at 06:18:05PM +0000, Conor Dooley wrote: > > On Thu, Feb 01, 2024 at 06:15:20PM +0000, Conor Dooley wrote: > > > On Thu, Feb 01, 2024 at 02:03:31PM +0200, Roger Quadros wrote: > > > > So far this was not required but due to the newly identified > > > > Errata i2409 [1] we need to poke this register space. > > > > > > > > [1] https://www.ti.com/lit/er/sprz487d/sprz487d.pdf > > > > > > > > Signed-off-by: Roger Quadros <rogerq@kernel.org> > > > > > > Acked-by: Conor Dooley <conor.dooley@microchip.com> > > > > Actually, where is the user for this that actually pokes the register > > space? > > You're adding another register region, so I went to check how you were > > handling that in drivers, but there's no driver patch. > > See Roger's another patch set 'Add workaround for Errata i2409' posted > on 16th. This patch should be with that series, not with these dts patches. Thanks, Conor.
On 01/02/2024 21:13, Conor Dooley wrote: > On Thu, Feb 01, 2024 at 12:35:22PM -0600, Bin Liu wrote: >> On Thu, Feb 01, 2024 at 06:18:05PM +0000, Conor Dooley wrote: >>> On Thu, Feb 01, 2024 at 06:15:20PM +0000, Conor Dooley wrote: >>>> On Thu, Feb 01, 2024 at 02:03:31PM +0200, Roger Quadros wrote: >>>>> So far this was not required but due to the newly identified >>>>> Errata i2409 [1] we need to poke this register space. >>>>> >>>>> [1] https://www.ti.com/lit/er/sprz487d/sprz487d.pdf >>>>> >>>>> Signed-off-by: Roger Quadros <rogerq@kernel.org> >>>> >>>> Acked-by: Conor Dooley <conor.dooley@microchip.com> >>> >>> Actually, where is the user for this that actually pokes the register >>> space? https://lore.kernel.org/all/20240201121220.5523-5-rogerq@kernel.org/ >>> You're adding another register region, so I went to check how you were >>> handling that in drivers, but there's no driver patch. >> >> See Roger's another patch set 'Add workaround for Errata i2409' posted >> on 16th. > > This patch should be with that series, not with these dts patches. > Why not? There should be no dependency between DTS and driver implementation. As DTS and driver will be merged by separate maintainers I thought it would be easier for maintainers this way.
On Fri, Feb 02, 2024 at 11:36:55AM +0200, Roger Quadros wrote: > > > On 01/02/2024 21:13, Conor Dooley wrote: > > On Thu, Feb 01, 2024 at 12:35:22PM -0600, Bin Liu wrote: > >> On Thu, Feb 01, 2024 at 06:18:05PM +0000, Conor Dooley wrote: > >>> On Thu, Feb 01, 2024 at 06:15:20PM +0000, Conor Dooley wrote: > >>>> On Thu, Feb 01, 2024 at 02:03:31PM +0200, Roger Quadros wrote: > >>>>> So far this was not required but due to the newly identified > >>>>> Errata i2409 [1] we need to poke this register space. > >>>>> > >>>>> [1] https://www.ti.com/lit/er/sprz487d/sprz487d.pdf > >>>>> > >>>>> Signed-off-by: Roger Quadros <rogerq@kernel.org> > >>>> > >>>> Acked-by: Conor Dooley <conor.dooley@microchip.com> > >>> > >>> Actually, where is the user for this that actually pokes the register > >>> space? > > https://lore.kernel.org/all/20240201121220.5523-5-rogerq@kernel.org/ > > >>> You're adding another register region, so I went to check how you were > >>> handling that in drivers, but there's no driver patch. > >> > >> See Roger's another patch set 'Add workaround for Errata i2409' posted > >> on 16th. > > > > This patch should be with that series, not with these dts patches. > > > > Why not? There should be no dependency between DTS and driver implementation. > > As DTS and driver will be merged by separate maintainers I thought it > would be easier for maintainers this way. dts and driver might be merged by different people, but dt-bindings and drivers are merged by the same people. This is a bindings patch, not a dts patch. Look at what get_maintainer says for this file: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (supporter:USB SUBSYSTEM) Rob Herring <robh+dt@kernel.org> (maintainer:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS) Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org> (maintainer:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS) Conor Dooley <conor+dt@kernel.org> (maintainer:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS) Aswath Govindraju <a-govindraju@ti.com> (in file) linux-usb@vger.kernel.org (open list:USB SUBSYSTEM) devicetree@vger.kernel.org (open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS) linux-kernel@vger.kernel.org (open list) Greg and linux-usb are on there, but you have not CCed them. Being with the driver also allows bindings maintainers to check that you don't break backwards compatibility. It also prevents me having to ask for the driver patch, then be given just a subject line that I have to go and look up myself! Thanks, Conor.
On 02/02/2024 11:53, Conor Dooley wrote: > On Fri, Feb 02, 2024 at 11:36:55AM +0200, Roger Quadros wrote: >> >> >> On 01/02/2024 21:13, Conor Dooley wrote: >>> On Thu, Feb 01, 2024 at 12:35:22PM -0600, Bin Liu wrote: >>>> On Thu, Feb 01, 2024 at 06:18:05PM +0000, Conor Dooley wrote: >>>>> On Thu, Feb 01, 2024 at 06:15:20PM +0000, Conor Dooley wrote: >>>>>> On Thu, Feb 01, 2024 at 02:03:31PM +0200, Roger Quadros wrote: >>>>>>> So far this was not required but due to the newly identified >>>>>>> Errata i2409 [1] we need to poke this register space. >>>>>>> >>>>>>> [1] https://www.ti.com/lit/er/sprz487d/sprz487d.pdf >>>>>>> >>>>>>> Signed-off-by: Roger Quadros <rogerq@kernel.org> >>>>>> >>>>>> Acked-by: Conor Dooley <conor.dooley@microchip.com> >>>>> >>>>> Actually, where is the user for this that actually pokes the register >>>>> space? >> >> https://lore.kernel.org/all/20240201121220.5523-5-rogerq@kernel.org/ >> >>>>> You're adding another register region, so I went to check how you were >>>>> handling that in drivers, but there's no driver patch. >>>> >>>> See Roger's another patch set 'Add workaround for Errata i2409' posted >>>> on 16th. >>> >>> This patch should be with that series, not with these dts patches. >>> >> >> Why not? There should be no dependency between DTS and driver implementation. >> >> As DTS and driver will be merged by separate maintainers I thought it >> would be easier for maintainers this way. > > dts and driver might be merged by different people, but dt-bindings and > drivers are merged by the same people. This is a bindings patch, not a If we do that then I get a bunch of dtbs_check warnings dwc3-usb@f900000: reg: [[0, 261095424, 0, 2048], [0, 261128192, 0, 1024]] is too long > dts patch. Look at what get_maintainer says for this file: > Greg Kroah-Hartman <gregkh@linuxfoundation.org> (supporter:USB SUBSYSTEM) > Rob Herring <robh+dt@kernel.org> (maintainer:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS) > Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org> (maintainer:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS) > Conor Dooley <conor+dt@kernel.org> (maintainer:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS) > Aswath Govindraju <a-govindraju@ti.com> (in file) > linux-usb@vger.kernel.org (open list:USB SUBSYSTEM) > devicetree@vger.kernel.org (open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS) > linux-kernel@vger.kernel.org (open list) > Greg and linux-usb are on there, but you have not CCed them. My bad. Will be more careful next time. > > Being with the driver also allows bindings maintainers to check that you > don't break backwards compatibility. It also prevents me having to ask > for the driver patch, then be given just a subject line that I have to > go and look up myself! > Sorry about that. It took a bit longer but I did point you directly to the patch on lore.kernel.org.
On 12:13-20240202, Roger Quadros wrote: [..] > >> > >> As DTS and driver will be merged by separate maintainers I thought it > >> would be easier for maintainers this way. > > > > dts and driver might be merged by different people, but dt-bindings and > > drivers are merged by the same people. This is a bindings patch, not a > > If we do that then I get a bunch of dtbs_check warnings > > dwc3-usb@f900000: reg: [[0, 261095424, 0, 2048], [0, 261128192, 0, 1024]] is too long Just my 2 cents: If the binding (and driver) change was truly backward compatible (which it should be - for example: errata can only be applied if the second property is described), then you want to control that reg property to add minItems? - thatm I think will allow the dts change to come in at the next cycle once the binding has been merged.
On 02/02/2024 14:18, Nishanth Menon wrote: > On 12:13-20240202, Roger Quadros wrote: > [..] >>>> >>>> As DTS and driver will be merged by separate maintainers I thought it >>>> would be easier for maintainers this way. >>> >>> dts and driver might be merged by different people, but dt-bindings and >>> drivers are merged by the same people. This is a bindings patch, not a >> >> If we do that then I get a bunch of dtbs_check warnings >> >> dwc3-usb@f900000: reg: [[0, 261095424, 0, 2048], [0, 261128192, 0, 1024]] is too long > > Just my 2 cents: If the binding (and driver) change was truly backward > compatible (which it should be - for example: errata can only be > applied if the second property is described), then you want to control > that reg property to add minItems? - thatm I think will allow the dts > change to come in at the next cycle once the binding has been merged. > Thanks for the hint. Please drop patches 4 and 5 in case you pick this series. I'll send patch 4 along with the driver series v2. Patch 5, I'll send after the DT binding has been merged.
On 15:59-20240202, Roger Quadros wrote: > > > On 02/02/2024 14:18, Nishanth Menon wrote: > > On 12:13-20240202, Roger Quadros wrote: > > [..] > >>>> > >>>> As DTS and driver will be merged by separate maintainers I thought it > >>>> would be easier for maintainers this way. > >>> > >>> dts and driver might be merged by different people, but dt-bindings and > >>> drivers are merged by the same people. This is a bindings patch, not a > >> > >> If we do that then I get a bunch of dtbs_check warnings > >> > >> dwc3-usb@f900000: reg: [[0, 261095424, 0, 2048], [0, 261128192, 0, 1024]] is too long > > > > Just my 2 cents: If the binding (and driver) change was truly backward > > compatible (which it should be - for example: errata can only be > > applied if the second property is described), then you want to control > > that reg property to add minItems? - thatm I think will allow the dts > > change to come in at the next cycle once the binding has been merged. > > > > Thanks for the hint. > Please drop patches 4 and 5 in case you pick this series. > > I'll send patch 4 along with the driver series v2. > Patch 5, I'll send after the DT binding has been merged. I suggest to resubmit requisite series (with patches +- or what ever) specific to appropriate maintainers (I don't typically like folks sending driver change along with dts change in a single series without indicating to driver maintainer that dts is something they shouldn't be picking) and avoid any confusion ;)
On Fri, Feb 02, 2024 at 12:13:22PM +0200, Roger Quadros wrote: > > > On 02/02/2024 11:53, Conor Dooley wrote: > > On Fri, Feb 02, 2024 at 11:36:55AM +0200, Roger Quadros wrote: > >> > >> > >> On 01/02/2024 21:13, Conor Dooley wrote: > >>> On Thu, Feb 01, 2024 at 12:35:22PM -0600, Bin Liu wrote: > >>>> On Thu, Feb 01, 2024 at 06:18:05PM +0000, Conor Dooley wrote: > >>>>> On Thu, Feb 01, 2024 at 06:15:20PM +0000, Conor Dooley wrote: > >>>>>> On Thu, Feb 01, 2024 at 02:03:31PM +0200, Roger Quadros wrote: > >>>>>>> So far this was not required but due to the newly identified > >>>>>>> Errata i2409 [1] we need to poke this register space. > >>>>>>> > >>>>>>> [1] https://www.ti.com/lit/er/sprz487d/sprz487d.pdf > >>>>>>> > >>>>>>> Signed-off-by: Roger Quadros <rogerq@kernel.org> > >>>>>> > >>>>>> Acked-by: Conor Dooley <conor.dooley@microchip.com> > >>>>> > >>>>> Actually, where is the user for this that actually pokes the register > >>>>> space? > >> > >> https://lore.kernel.org/all/20240201121220.5523-5-rogerq@kernel.org/ > >> > >>>>> You're adding another register region, so I went to check how you were > >>>>> handling that in drivers, but there's no driver patch. > >>>> > >>>> See Roger's another patch set 'Add workaround for Errata i2409' posted > >>>> on 16th. > >>> > >>> This patch should be with that series, not with these dts patches. > >>> > >> > >> Why not? There should be no dependency between DTS and driver implementation. > >> > >> As DTS and driver will be merged by separate maintainers I thought it > >> would be easier for maintainers this way. > > > > dts and driver might be merged by different people, but dt-bindings and > > drivers are merged by the same people. This is a bindings patch, not a > > If we do that then I get a bunch of dtbs_check warnings > > dwc3-usb@f900000: reg: [[0, 261095424, 0, 2048], [0, 261128192, 0, 1024]] is too long I don't know what your platform maintainers view is, but to me it is fine as long as linux-next is clean.
> All AM62 devices have Errata i2409 [1] due to which > USB2 PHY may lock up due to short suspend. > > Workaround involves setting bit 5 and 4 PLL_REG12 > in PHY2 register space after USB controller is brought > out of LPSC reset but before controller initialization. > > Handle this workaround. Tested-by: Andrejs Cainikovs <andrejs.cainikovs@toradex.com> You have requested [1] to check whether this patch fixes issues I observed, and I can confirm it does. [1]: https://lore.kernel.org/all/2629cd30-23aa-4f03-8452-ae13297fd6b6@kernel.org/
diff --git a/Documentation/devicetree/bindings/usb/ti,am62-usb.yaml b/Documentation/devicetree/bindings/usb/ti,am62-usb.yaml index fec5651f5602..c02d9d467d9c 100644 --- a/Documentation/devicetree/bindings/usb/ti,am62-usb.yaml +++ b/Documentation/devicetree/bindings/usb/ti,am62-usb.yaml @@ -14,7 +14,9 @@ properties: const: ti,am62-usb reg: - maxItems: 1 + items: + - description: USB CFG register space + - description: USB PHY2 register space ranges: true @@ -82,7 +84,8 @@ examples: usbss1: usb@f910000 { compatible = "ti,am62-usb"; - reg = <0x00 0x0f910000 0x00 0x800>; + reg = <0x00 0x0f910000 0x00 0x800>, + <0x00 0x0f918000 0x00 0x400>; clocks = <&k3_clks 162 3>; clock-names = "ref"; ti,syscon-phy-pll-refclk = <&wkup_conf 0x4018>;