Message ID | 20230712084131.127982-1-krzysztof.kozlowski@linaro.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:a6b2:0:b0:3e4:2afc:c1 with SMTP id c18csp1014943vqm; Wed, 12 Jul 2023 02:11:20 -0700 (PDT) X-Google-Smtp-Source: APBJJlHqj+6/YHaqaxs8oVjSGdtljAf1wVjLyDFrDcGYzppm0Jk65Yxao4QohsVDw0xOSjYvS1OR X-Received: by 2002:a17:906:20d8:b0:993:eef2:5d5d with SMTP id c24-20020a17090620d800b00993eef25d5dmr16282908ejc.27.1689153080154; Wed, 12 Jul 2023 02:11:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1689153080; cv=none; d=google.com; s=arc-20160816; b=KaIfOmhK+PaOsV2m7DhvdFyrbbPVIzrlUFGvhQeYhoV1dFVMj/xR898G/dTgbHimCm 0zUQpcUdA/tFOj7M65KvcTIAJCUUXZcQp9QuHBX5UKMo9/BTVd+PG7lbQ6rHTwaVsI1f z39kj94zSzLc2N0pqrkKD6vrkVFtsgJ530qqxrygyKm0viwCrdmoPZrTcuuQesNCfHIU d31WgPJ0PlDSyRr66yyQAX8WKLdCKLpvCppI4RbFHJYRmoymE+TBMpMDfVFSROTbmknX AlsoUZRecAf3PBn5e3toOYJPoQ4Zf70X0sN1evZbsLVXBffMp5ZfDwPUvxvaqj+RoEeT Ysfw== 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=X/8q7gkdwr/BrCDqoyz31fyjMWdFi221FyF4qfS1iTk=; fh=tXpM574TAO9LjSnRldM8EVTLFfI7tKQCQZpjzZEcNlQ=; b=VOdAnadaYiQq0U9O2cbc/0znHdvWJ4AtdIqy/wqHf1XYGw405uBc6CzzZh41LbfID9 F2pZ6VwnEJcaO3Yo+om2clx64Vw+iNJwwDPbg+eh/L8WBdFjBpdIERectY7rQQ614Yml epF7szshHUBJu2x9xrTmlKk2lO/Qstn7iNzBpBvt0Bk9WuyAKmxdMyumTO5omXQWSqP3 Jbr7DEyReUuXZKhVxj0yo0aHQ3C+RevpqLc0BfESyFOau1GMy9LaSUZK90s6mUZbxXhj wn1PHnUNG+mtwNlQZRQZ7s8x5Q4GPKljLlYLve2ON3nfmf0gHNEFjbtew64iz6oe2U7D yH7A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=WbQEEHw+; 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=NONE sp=NONE dis=NONE) header.from=linaro.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id lw15-20020a170906bccf00b009938cb10849si4149380ejb.111.2023.07.12.02.10.55; Wed, 12 Jul 2023 02:11:20 -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=@linaro.org header.s=google header.b=WbQEEHw+; 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=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232759AbjGLIlr (ORCPT <rfc822;gnulinuxfreebsd@gmail.com> + 99 others); Wed, 12 Jul 2023 04:41:47 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38688 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232417AbjGLIlo (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 12 Jul 2023 04:41:44 -0400 Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CA7E6BE for <linux-kernel@vger.kernel.org>; Wed, 12 Jul 2023 01:41:42 -0700 (PDT) Received: by mail-ed1-x52a.google.com with SMTP id 4fb4d7f45d1cf-51e590a8ab5so4115782a12.2 for <linux-kernel@vger.kernel.org>; Wed, 12 Jul 2023 01:41:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1689151301; x=1691743301; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=X/8q7gkdwr/BrCDqoyz31fyjMWdFi221FyF4qfS1iTk=; b=WbQEEHw+wTXjlvAlkmvcyKPPQ1lFW+/pcjio/9fWKTrKT4J+I7npAXXOzgvTDO5/Se bbswC8PyDEE1c5cwp4tAkSpw49h252SBQZ5K6ESU3geiRRvptJhyYfgvkYS7wMeeGH1G YmnOX4RqZQ66xtwoaVHGLb67pXGwU1bRcV+FaS0/7Ee9Kx4pYkcFTlukt79+nDqptWTt XCcIh+GklixeqHI2n9vg3GThJWhqeAD6zykBUFx5ffOJ3zfMujRyqA/uZg1VToWe/RtF 8SMWd2CjWYlZ93l/ljmZl33n0kNO0foY6tFk7NDGG19wuX+fFD0+ypjA/rGAknuHjkVZ tmbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689151301; x=1691743301; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=X/8q7gkdwr/BrCDqoyz31fyjMWdFi221FyF4qfS1iTk=; b=TG++kmcDdzUF5ntjJueSduQVqRAm102/AxTX+6ijqjHiWcrINAXkETBv7wbkJ1s0b/ aLqqZ+xcQZoR8fb2arw32GrFohL8V3ciqfZW6myuxIyeYvoiGrW9h9s2n8TOH7Sju6FS NxY5RsiEo2241IoG+h0nI3GqRwq1H56JSab4zLK8seTai2QkpztK/bRgY3UR/iYTDU6J tiSMIA4V7yuyQhKxj/LoWgTe9Zo86W0KVMab5ncrexVMp92tjKpbmN8odSgMvf82i5E5 S+S5ytmArdx6wIMo1UdVu2ETusgYGNCMYTeRGe8YIHERbjRFqTbvPoj7KdFVRUnkPtWg bsPA== X-Gm-Message-State: ABy/qLbDjaayc6aYl368FaFhGiWTpYgBbbBHG6Mo2+hmmPd9+WNUv2og mepI531N+tSZKSRyWujXrN9G9Q== X-Received: by 2002:a17:906:f6cb:b0:98e:4c96:6e1f with SMTP id jo11-20020a170906f6cb00b0098e4c966e1fmr17968958ejb.69.1689151301084; Wed, 12 Jul 2023 01:41:41 -0700 (PDT) Received: from krzk-bin.. ([178.197.223.104]) by smtp.gmail.com with ESMTPSA id t14-20020a17090616ce00b0094e7d196aa4sm2216496ejd.160.2023.07.12.01.41.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 12 Jul 2023 01:41:40 -0700 (PDT) From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> To: Arnd Bergmann <arnd@arndb.de>, Olof Johansson <olof@lixom.net>, soc@kernel.org, Jonathan Corbet <corbet@lwn.net>, linux-arm-kernel@lists.infradead.org, workflows@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org Cc: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>, Conor Dooley <conor.dooley@microchip.com> Subject: [PATCH] Documentation/process: maintainer-soc: document dtbs_check requirement for Samsung Date: Wed, 12 Jul 2023 10:41:31 +0200 Message-Id: <20230712084131.127982-1-krzysztof.kozlowski@linaro.org> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_BLOCKED, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED 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: INBOX X-GMAIL-THRID: 1771205379827970940 X-GMAIL-MSGID: 1771205379827970940 |
Series |
Documentation/process: maintainer-soc: document dtbs_check requirement for Samsung
|
|
Commit Message
Krzysztof Kozlowski
July 12, 2023, 8:41 a.m. UTC
Samsung ARM/ARM64 SoCs (except legacy S5PV210) are also expected not to
bring any new dtbs_check warnings. In fact this have been already
enforced and tested since few release.
Cc: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
Not sure where to document this. Creating new maintainer profile for
Samsung SoC would be an overkill. OTOH, more SoCs might want to grow
this list, so this also scales poor.
---
Documentation/process/maintainer-soc.rst | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Comments
On Wed, Jul 12, 2023 at 10:41:31AM +0200, Krzysztof Kozlowski wrote: > Samsung ARM/ARM64 SoCs (except legacy S5PV210) are also expected not to > bring any new dtbs_check warnings. In fact this have been already > enforced and tested since few release. > > Cc: Conor Dooley <conor.dooley@microchip.com> > Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> > > --- > Not sure where to document this. Creating new maintainer profile for > Samsung SoC would be an overkill. OTOH, more SoCs might want to grow > this list, so this also scales poor. To me, this portion of the document was "information to the submaintainer", which would be you, not information to the contributors to the platform. Adding the comment about Samsung SoC seems aimed at contributors? I added the bit about W=1 on RISC-V since there are multiple sub-maintainers there. > --- > Documentation/process/maintainer-soc.rst | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/Documentation/process/maintainer-soc.rst b/Documentation/process/maintainer-soc.rst > index 49f08289d62c..12637530d68f 100644 > --- a/Documentation/process/maintainer-soc.rst > +++ b/Documentation/process/maintainer-soc.rst > @@ -133,8 +133,8 @@ with the dt-bindings that describe the ABI. Please read the section > more information on the validation of devicetrees. > > For new platforms, or additions to existing ones, ``make dtbs_check`` should not > -add any new warnings. For RISC-V, as it has the advantage of being a newer > -architecture, ``make dtbs_check W=1`` is required to not add any new warnings. > +add any new warnings. For RISC-V and Samsung SoC, ``make dtbs_check W=1`` is > +required to not add any new warnings. > If in any doubt about a devicetree change, reach out to the devicetree > maintainers. > > -- > 2.34.1 >
On 12/07/2023 11:48, Conor Dooley wrote: > On Wed, Jul 12, 2023 at 10:41:31AM +0200, Krzysztof Kozlowski wrote: >> Samsung ARM/ARM64 SoCs (except legacy S5PV210) are also expected not to >> bring any new dtbs_check warnings. In fact this have been already >> enforced and tested since few release. >> >> Cc: Conor Dooley <conor.dooley@microchip.com> >> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> >> >> --- > >> Not sure where to document this. Creating new maintainer profile for >> Samsung SoC would be an overkill. OTOH, more SoCs might want to grow >> this list, so this also scales poor. > > To me, this portion of the document was "information to the > submaintainer", which would be you, not information to the contributors > to the platform. Adding the comment about Samsung SoC seems aimed at > contributors? Yes, I want to document it for contributors, so they won't be surprised. Any hints where to store it? I could put it in the "About" tab of my kernel.org repo, but no one checks this for contribution guidelines. Best regards, Krzysztof
On Wed, Jul 12, 2023 at 01:46:20PM +0200, Krzysztof Kozlowski wrote: > On 12/07/2023 11:48, Conor Dooley wrote: > > On Wed, Jul 12, 2023 at 10:41:31AM +0200, Krzysztof Kozlowski wrote: > >> Samsung ARM/ARM64 SoCs (except legacy S5PV210) are also expected not to > >> bring any new dtbs_check warnings. In fact this have been already > >> enforced and tested since few release. > >> > >> Cc: Conor Dooley <conor.dooley@microchip.com> > >> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> > >> > >> --- > > > >> Not sure where to document this. Creating new maintainer profile for > >> Samsung SoC would be an overkill. OTOH, more SoCs might want to grow > >> this list, so this also scales poor. > > > > To me, this portion of the document was "information to the > > submaintainer", which would be you, not information to the contributors > > to the platform. Adding the comment about Samsung SoC seems aimed at > > contributors? > > Yes, I want to document it for contributors, so they won't be surprised. > Any hints where to store it? I could put it in the "About" tab of my > kernel.org repo, but no one checks this for contribution guidelines. I've not got a better suggestion for where to put this, but under something labelled as "Information for (new) Submaintainers" isn't where I would be looking as a contributor. Is adding to the generic DT documentation that dtbs_check should not add any new warnings at W=1 too extreme? writing-schema.rst has the instructions about how to run dtbs_check while writing dt-binding patches, but we don't seem to have any docs about running dtbs_check for dts/dtsi changes.
On 12/07/2023 14:34, Conor Dooley wrote: > On Wed, Jul 12, 2023 at 01:46:20PM +0200, Krzysztof Kozlowski wrote: >> On 12/07/2023 11:48, Conor Dooley wrote: >>> On Wed, Jul 12, 2023 at 10:41:31AM +0200, Krzysztof Kozlowski wrote: >>>> Samsung ARM/ARM64 SoCs (except legacy S5PV210) are also expected not to >>>> bring any new dtbs_check warnings. In fact this have been already >>>> enforced and tested since few release. >>>> >>>> Cc: Conor Dooley <conor.dooley@microchip.com> >>>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> >>>> >>>> --- >>> >>>> Not sure where to document this. Creating new maintainer profile for >>>> Samsung SoC would be an overkill. OTOH, more SoCs might want to grow >>>> this list, so this also scales poor. >>> >>> To me, this portion of the document was "information to the >>> submaintainer", which would be you, not information to the contributors >>> to the platform. Adding the comment about Samsung SoC seems aimed at >>> contributors? >> >> Yes, I want to document it for contributors, so they won't be surprised. >> Any hints where to store it? I could put it in the "About" tab of my >> kernel.org repo, but no one checks this for contribution guidelines. > > I've not got a better suggestion for where to put this, but under > something labelled as "Information for (new) Submaintainers" isn't > where I would be looking as a contributor. Yeah, true. > Is adding to the generic DT documentation that dtbs_check should not add > any new warnings at W=1 too extreme? It is to extreme. Several sub-arch maintainers might prioritize features than DT schema compliance. I would say it is their choice, even if I don't agree with it. > writing-schema.rst has the instructions about how to run dtbs_check while > writing dt-binding patches, but we don't seem to have any docs about > running dtbs_check for dts/dtsi changes. Maybe I will add generic maintainer-sub-arch-soc profile doc which then can be linked by multiple soc subsystems. Best regards, Krzysztof
diff --git a/Documentation/process/maintainer-soc.rst b/Documentation/process/maintainer-soc.rst index 49f08289d62c..12637530d68f 100644 --- a/Documentation/process/maintainer-soc.rst +++ b/Documentation/process/maintainer-soc.rst @@ -133,8 +133,8 @@ with the dt-bindings that describe the ABI. Please read the section more information on the validation of devicetrees. For new platforms, or additions to existing ones, ``make dtbs_check`` should not -add any new warnings. For RISC-V, as it has the advantage of being a newer -architecture, ``make dtbs_check W=1`` is required to not add any new warnings. +add any new warnings. For RISC-V and Samsung SoC, ``make dtbs_check W=1`` is +required to not add any new warnings. If in any doubt about a devicetree change, reach out to the devicetree maintainers.