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 D6B19C02185 for ; Sat, 18 Jan 2025 15:57:06 +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-Type: List-Subscribe:List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id: In-Reply-To:References:To:From:Subject:Cc:Message-Id:Date:Mime-Version: Reply-To:Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date :Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=uDOdNQT7nwX9raJ2oN+AdPnNkHD9VSpXqKoXo0N+MqM=; b=NdMJes6ucgsRNRieZNSE/X1iwp O7qzQsUDbvSkYSqyUer3U4v5zVN7Y8CB38zVijTh5bI9U8Js2wZuovProM5WnmWHe5kfl1mD2Z2ls BIX1lbLJKOGPkNxfuVKNALXtfcMIqoO+6ajcOqpXqe8m74dEfrgD2LEeQfCvp1zc6FUx7TfMAE9Rr egsziifW5Bpi92Pb6Y8pxYdK4C6hAH5MUuTy6MCZTyctIFFeHKuRID4/IIYaDNmtmv+4GCJgVT9JH ZlZECOUH752jOHzQqIzbP5qyfPVVv20UHD2o/zLXuG6KMlG0wnh4/btF43feSdvLe4qiSYHACa59G 4/FBiDBA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1tZBBz-00000002eAN-0A5M; Sat, 18 Jan 2025 15:56:59 +0000 Received: from out-174.mta0.migadu.com ([91.218.175.174]) by bombadil.infradead.org with esmtps (Exim 4.98 #2 (Red Hat Linux)) id 1tZBAm-00000002e5G-2AuG for linux-rockchip@lists.infradead.org; Sat, 18 Jan 2025 15:55:45 +0000 Mime-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cknow.org; s=key1; t=1737215727; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=3SxSP1pnDMPIAoFIbshAZCGR8/UyRzjoHfDVHXlLyvY=; b=L/1Xm9egYr9PWZJ8WNXlWGe091lYawTGRrX9Re0P+m3/1ksKE/GrGDHERjcoVL0ARhx2rl XYlItLGkfLZcct1JjV6diAzC8kpYoWmXCgLnJCb2julfufpPehrw/30mQK1m6ZiaocLVyf k69cfX6Ad7fp4TRUvlnn6jaaDqkWeBPNin8V4o0wfuA5e5l4ugvYf5dmuLTO+oLeCEOvba yzK6BhUnQ9a6qIzNKwOi9mBYxwTlk63lQ72pB7sjdJEVCfhwmT6gZTzNjiqrV7PhlM38fg dHTy0+Nu5cLuYjhOXMRAyux4PBWlSWuIIf2P1y8MuAK4xi6xhY0p6U9Dd9RM7w== Date: Sat, 18 Jan 2025 16:55:24 +0100 Message-Id: Cc: , , , , , , "Alex Bee" , "Conor Dooley" , "Dragan Simic" , "Johan Jonker" , "Jonas Karlman" , "Krzysztof Kozlowski" , "Rob Herring" , , , Subject: Re: [RFC PATCH v1 4/6] arm64: dts: rockchip: add rk3328 usb3 phy node X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: "Diederik de Haas" To: "Krzysztof Kozlowski" , "Peter Geis" , "Heiko Stuebner" References: <20250115012628.1035928-1-pgwipeout@gmail.com> <20250115012628.1035928-5-pgwipeout@gmail.com> <7c7ce820-8a9b-46df-b143-f77835b7e5a0@kernel.org> In-Reply-To: X-Migadu-Flow: FLOW_OUT X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20250118_075544_694798_3FC6F9E4 X-CRM114-Status: GOOD ( 24.10 ) X-BeenThere: linux-rockchip@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Upstream kernel work for Rockchip platforms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============7780238429014041285==" Sender: "Linux-rockchip" Errors-To: linux-rockchip-bounces+linux-rockchip=archiver.kernel.org@lists.infradead.org --===============7780238429014041285== Content-Type: multipart/signed; boundary=6d73a8a051e9f14d4259504ef5c03823cc0e8aa06a923c553c99f8c21a2d; micalg=pgp-sha256; protocol="application/pgp-signature" --6d73a8a051e9f14d4259504ef5c03823cc0e8aa06a923c553c99f8c21a2d Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 On Sat Jan 18, 2025 at 9:41 AM CET, Krzysztof Kozlowski wrote: > On 16/01/2025 17:53, Diederik de Haas wrote: > > On Thu Jan 16, 2025 at 2:01 PM CET, Krzysztof Kozlowski wrote: > >> On 15/01/2025 02:26, Peter Geis wrote: > >>> diff --git a/arch/arm64/boot/dts/rockchip/rk3328.dtsi b/arch/arm64/bo= ot/dts/rockchip/rk3328.dtsi > >>> index 7d992c3c01ce..181a900d41f9 100644 > >>> --- a/arch/arm64/boot/dts/rockchip/rk3328.dtsi > >>> +++ b/arch/arm64/boot/dts/rockchip/rk3328.dtsi > >>> @@ -903,6 +903,43 @@ u2phy_host: host-port { > >>> }; > >>> }; > >>> =20 > >>> + usb3phy: usb3-phy@ff460000 { > >>> + compatible =3D "rockchip,rk3328-usb3phy"; > >>> + reg =3D <0x0 0xff460000 0x0 0x10000>; > >>> + clocks =3D <&cru SCLK_REF_USB3OTG>, <&cru PCLK_USB3PHY_OTG>, <&cru= PCLK_USB3PHY_PIPE>; > >> > >> Please wrap code according to coding style (checkpatch is not a coding > >> style description, but only a tool), so at 80. > >=20 > > I'm confused: is it 80 or 100? > >=20 > > I always thought it was 80, but then I saw several patches/commits by > > Coding style is clear: it is 80. It also has caveat about code > readability and several maintainers have their own preference. > > > Dragan Simic which deliberately changed code to make use of 100. > > Being fed up with my own confusion, I submitted a PR to=20 > > https://github.com/gregkh/kernel-coding-style/ which got accepted: > > https://github.com/gregkh/kernel-coding-style/commit/5c21f99dc79883bd0e= feba368193180275c9c77a > > That's not kernel. That's Greg... FWIW: what Greg and Linus think/say is relevant to me. > > So now both the vim plugins code and README say 100. > > But as noted in my commit message: > >=20 > > Note that the current upstream 'Linux kernel coding style' does NOT > > mention the 100 char limit, but only mentions the preferred max lengt= h > > of 80. > >=20 > > Or is it 100 for code, but 80 for DeviceTree files and bindings? > > From where did you get 100? Checkpatch, right? Kernel coding style is > clear, there is no discussion, no mentioning 100: > > "The preferred limit on the length of a single line is 80 columns. " > > So to be clear: all DTS, all DT bindings, all code maintained by me and > some maintainers follows above (and further - there is caveat) > instruction from coding style. Some maintainers follow other rules and > that's fine. But indeed, before Greg or Linus (likely) see it, a patch submitter needs to convince the (subsystem) maintainer that it is an improvement. Thanks for the clarification :-) Cheers, Diederik --6d73a8a051e9f14d4259504ef5c03823cc0e8aa06a923c553c99f8c21a2d Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQT1sUPBYsyGmi4usy/XblvOeH7bbgUCZ4vO7gAKCRDXblvOeH7b bhJSAQDzQOoaAvVda2tvd6s9eC9C9EQKEPJB1f7eTLzoCShz1gEAkguNRpCnf6P/ QgF8sA7HBoXoKL5WcCid45Rzf1yYAwk= =NPUv -----END PGP SIGNATURE----- --6d73a8a051e9f14d4259504ef5c03823cc0e8aa06a923c553c99f8c21a2d-- --===============7780238429014041285== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Linux-rockchip mailing list Linux-rockchip@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip --===============7780238429014041285==--