Message ID | 20230623113009.2512206-6-abel.vesa@linaro.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:994d:0:b0:3d9:f83d:47d9 with SMTP id k13csp5701082vqr; Fri, 23 Jun 2023 04:32:42 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ7HGkUolvZ9mt++lIX06okyAF3p+ezj31KlXQOSg3OX2G42AUU7qRSvslczk6JUfkly2KC+ X-Received: by 2002:a17:902:d2c2:b0:1b6:9551:e2b8 with SMTP id n2-20020a170902d2c200b001b69551e2b8mr10175208plc.34.1687519962253; Fri, 23 Jun 2023 04:32:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1687519962; cv=none; d=google.com; s=arc-20160816; b=qAKJU2ewBktiCxbFx+pMZDIE6HQXT5BEo+eD8A2eLaXSx7KcIGbJAAthdn0D7DbZNM JvUDU3W/ltzU0yMa+keJb0w1WyHSWoasFPFyMdyDxmS1jam09e5TX40UfEAOOM89W6AO TLcBpGdFn4k/s8JMD1QHcRUQLjV2ryt4+pkfBNYC8W8IbcKsx6Df+XefM9J6IZ/5pHjQ 9sT4ZjPXl84pfRVDx0A72q9rTwwYn0XftWNRrTlge1X2tKFPTBdUIOSp9vrAk4GGktvm a0xheLLo8uEgR2wPJCH03opJcRdfoMqylMpbv2uNBURQNNSQp6YC7Rs6a2toRRsrNpcx tYZQ== 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 :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=pNvuq6mkva9AEwJO9JM3pF+J3bkYwlLNxD1WUPaScDY=; b=FyggZurxqY7ag9/o1rITNqkejEFPuaWqOVZK/c96EfNt8zUxsK3nSlJXkT5ogcVdgE mTFJpk/ZcY+SDgBLnyl/jLW97iwIwQDwNKesLgSiBSNq/mNZ1lJ99hxjC6aEIdGTCyRD ofz/cwkbr5jW4YKEYj8c1DERTV7WGJSuiflYYI8uiLePyOu4rtElooBr7YlUmp2Dwfs9 x3XfVAV7esBbbZylNXrMN6UnXvayX31LxEjSDTlN+d3tXWS9LYpkAd6dv4ODjstuynzT mDRyHYwjIZUNUf4Sdpn+Z+c89HdWKewXwHlgUooBADw95BKty5Qz4hhFqZfyj5t3KiEx RnZw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=JyzgYeYG; 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 y5-20020a17090322c500b001b67b4f719asi9611899plg.438.2023.06.23.04.32.28; Fri, 23 Jun 2023 04:32:42 -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=JyzgYeYG; 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 S231856AbjFWLa7 (ORCPT <rfc822;maxin.john@gmail.com> + 99 others); Fri, 23 Jun 2023 07:30:59 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59898 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231567AbjFWLa3 (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 23 Jun 2023 07:30:29 -0400 Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [IPv6:2a00:1450:4864:20::629]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 26A132710 for <linux-kernel@vger.kernel.org>; Fri, 23 Jun 2023 04:30:24 -0700 (PDT) Received: by mail-ej1-x629.google.com with SMTP id a640c23a62f3a-9887ebe16d0so56653566b.2 for <linux-kernel@vger.kernel.org>; Fri, 23 Jun 2023 04:30:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1687519822; x=1690111822; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=pNvuq6mkva9AEwJO9JM3pF+J3bkYwlLNxD1WUPaScDY=; b=JyzgYeYGNAXiEO38g990qGezFImnyLJ1NctOgLVYfhN+FMGZDp/HilrsHhxCJZpjmH nCBpKvS9F3ZF6idUmrS193Ui/0nlt4M/2OjUtXfjlrFTNme1BnHY+fNqcOBS1GCz2xd/ 6r6vV2lrrZcKuUVc+ICPmjrckuoU/WU8rhpu/vKVuddYUfh5v+Me19Phemob4mtUZJLA 3wL6DR1hhWkmjp4/FcAhlVzMaYOPpGXPCD0AjAiZd/+Re1FkBordvtJxNB6+82ipo97d TyfbwGNG9OPG6+2g0D1tQxKccI+juogcvLHXNjgMIkuw+N1mVN82BRcNM9c3pMgQOHKA 4i1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687519822; x=1690111822; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=pNvuq6mkva9AEwJO9JM3pF+J3bkYwlLNxD1WUPaScDY=; b=mFGRjkdZfaPjy52PCMJuPgLLfv+LHS08AF8INEUHaOvYVt/04M5R6neGOG+3XwZ5vc KtzsfyQ85ORWKsDXX7ZFokJfFi6UJeJ6q/XV+C5v2+7RrFIDk5EhkJnMLMmHEAJT51Dd zuxMJWltRPautxjbrEwyVoEriZik/Y9aM752mQV30yG90RPbxjhgCgVh5vkTw56GBZV/ wfmjBtyi5ZvtzqDC4Rpw7ZF7Cb28l8uHh2qbyPm0oMuKa2ztcUqhZiUZE2KuNcS4TGD8 3nMMsbaHjx0uBdYSVgQDe8glYWS7ZgdvfCnxOgo+Ggl14LbZASOoJa8o4Qw9XW7bpjZh QTsQ== X-Gm-Message-State: AC+VfDyxMUriQWGgNKO8EzJLtnyL0kEeA35SzOeIwJ4Bfc8CXGonK0kG 9AOG+UK2lRIKxOoNlV7lkL2/WA== X-Received: by 2002:a17:907:a421:b0:987:5761:285f with SMTP id sg33-20020a170907a42100b009875761285fmr15875704ejc.42.1687519822320; Fri, 23 Jun 2023 04:30:22 -0700 (PDT) Received: from hackbox.lan ([62.231.110.100]) by smtp.gmail.com with ESMTPSA id z17-20020a1709063ad100b009821ce1ea33sm5908033ejd.7.2023.06.23.04.30.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 23 Jun 2023 04:30:21 -0700 (PDT) From: Abel Vesa <abel.vesa@linaro.org> To: Manivannan Sadhasivam <mani@kernel.org>, Andy Gross <agross@kernel.org>, Bjorn Andersson <andersson@kernel.org>, Konrad Dybcio <konrad.dybcio@linaro.org>, Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Conor Dooley <conor+dt@kernel.org>, "Martin K . Petersen" <martin.petersen@oracle.com>, Alim Akhtar <alim.akhtar@samsung.com>, Avri Altman <avri.altman@wdc.com>, Bart Van Assche <bvanassche@acm.org> Cc: linux-arm-msm@vger.kernel.org, linux-scsi@vger.kernel.org, devicetree@vger.kernel.org, Linux Kernel Mailing List <linux-kernel@vger.kernel.org> Subject: [PATCH 5/5] scsi: dt-bindings: ufs: qcom: Fix warning for sdm845 by adding reg-names Date: Fri, 23 Jun 2023 14:30:09 +0300 Message-Id: <20230623113009.2512206-6-abel.vesa@linaro.org> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230623113009.2512206-1-abel.vesa@linaro.org> References: <20230623113009.2512206-1-abel.vesa@linaro.org> 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_NONE, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=unavailable 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?1769492932155273682?= X-GMAIL-MSGID: =?utf-8?q?1769492932155273682?= |
Series |
scsi: dt-bindings: ufs: qcom: Some fixes to clear all dtbs_check warnings
|
|
Commit Message
Abel Vesa
June 23, 2023, 11:30 a.m. UTC
There is a warning on dtbs check for sdm845, amongst other platforms,
about the reg-names being unevaluated. Fix that by adding reg-names to
the clocks and reg properties check for such platforms.
Fixes: 462c5c0aa798 ("dt-bindings: ufs: qcom,ufs: convert to dtschema")
Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
---
Documentation/devicetree/bindings/ufs/qcom,ufs.yaml | 4 ++++
1 file changed, 4 insertions(+)
Comments
On 23/06/2023 13:30, Abel Vesa wrote: > There is a warning on dtbs check for sdm845, amongst other platforms, > about the reg-names being unevaluated. Fix that by adding reg-names to > the clocks and reg properties check for such platforms. > > Fixes: 462c5c0aa798 ("dt-bindings: ufs: qcom,ufs: convert to dtschema") > Signed-off-by: Abel Vesa <abel.vesa@linaro.org> > --- > Documentation/devicetree/bindings/ufs/qcom,ufs.yaml | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml b/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml > index 0209713d1f88..894b57117314 100644 > --- a/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml > +++ b/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml > @@ -166,6 +166,10 @@ allOf: > reg: > minItems: 2 > maxItems: 2 > + reg-names: > + items: > + - const: std > + - const: ice reg-names looks like a new property, so it should be defined in top-level and just constrained per-variant. Also there was similar approach: https://lore.kernel.org/all/20221209-dt-binding-ufs-v2-2-dc7a04699579@fairphone.com/ but I guess no resends and it can be superseded. Best regards, Krzysztof
On Fri Jun 23, 2023 at 2:31 PM CEST, Krzysztof Kozlowski wrote: > On 23/06/2023 13:30, Abel Vesa wrote: > > There is a warning on dtbs check for sdm845, amongst other platforms, > > about the reg-names being unevaluated. Fix that by adding reg-names to > > the clocks and reg properties check for such platforms. > > > > Fixes: 462c5c0aa798 ("dt-bindings: ufs: qcom,ufs: convert to dtschema") > > Signed-off-by: Abel Vesa <abel.vesa@linaro.org> > > --- > > Documentation/devicetree/bindings/ufs/qcom,ufs.yaml | 4 ++++ > > 1 file changed, 4 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml b/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml > > index 0209713d1f88..894b57117314 100644 > > --- a/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml > > +++ b/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml > > @@ -166,6 +166,10 @@ allOf: > > reg: > > minItems: 2 > > maxItems: 2 > > + reg-names: > > + items: > > + - const: std > > + - const: ice > > reg-names looks like a new property, so it should be defined in > top-level and just constrained per-variant. > > Also there was similar approach: > https://lore.kernel.org/all/20221209-dt-binding-ufs-v2-2-dc7a04699579@fairphone.com/ > > but I guess no resends and it can be superseded. Right, the patches got reviews but was never applied... I really need to find a strategy to keep track of sent patches until they're applied with my work mailbox, it's not the first time that a patch has gotten forgotten. With my private mailbox I just have a different folder for patches that have been sent which I archive once they're applied, but with work GMail I don't see how I can easily replicate this since it's also not grouping threads properly. Also patch 4/5 in this series has an equivalent from me: https://lore.kernel.org/all/20221209-dt-binding-ufs-v2-3-dc7a04699579@fairphone.com/ ^ this might also be preferable since I guess it doesn't break dt_binding_check? Regards Luca > > Best regards, > Krzysztof
On Fri, Jun 23, 2023 at 02:38:04PM +0200, Luca Weiss wrote: > On Fri Jun 23, 2023 at 2:31 PM CEST, Krzysztof Kozlowski wrote: > > On 23/06/2023 13:30, Abel Vesa wrote: > > > There is a warning on dtbs check for sdm845, amongst other platforms, > > > about the reg-names being unevaluated. Fix that by adding reg-names to > > > the clocks and reg properties check for such platforms. > > > > > > Fixes: 462c5c0aa798 ("dt-bindings: ufs: qcom,ufs: convert to dtschema") > > > Signed-off-by: Abel Vesa <abel.vesa@linaro.org> > > > --- > > > Documentation/devicetree/bindings/ufs/qcom,ufs.yaml | 4 ++++ > > > 1 file changed, 4 insertions(+) > > > > > > diff --git a/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml b/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml > > > index 0209713d1f88..894b57117314 100644 > > > --- a/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml > > > +++ b/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml > > > @@ -166,6 +166,10 @@ allOf: > > > reg: > > > minItems: 2 > > > maxItems: 2 > > > + reg-names: > > > + items: > > > + - const: std > > > + - const: ice > > > > reg-names looks like a new property, so it should be defined in > > top-level and just constrained per-variant. > > > > Also there was similar approach: > > https://lore.kernel.org/all/20221209-dt-binding-ufs-v2-2-dc7a04699579@fairphone.com/ > > > > but I guess no resends and it can be superseded. > > Right, the patches got reviews but was never applied... I really need to > find a strategy to keep track of sent patches until they're applied with > my work mailbox, it's not the first time that a patch has gotten > forgotten. There was an error reported on the above series. Why would it be applied? That said, I'm not sure SCSI maintainers consistently apply DT only patch series. > With my private mailbox I just have a different folder for patches that > have been sent which I archive once they're applied, but with work GMail > I don't see how I can easily replicate this since it's also not grouping > threads properly. Yeah, GMail sucks for that. I use 'lei' to get all my patches and replies to them (though its caching will miss replies). Then I delete them from the mbox when they are applied or otherwise finished. lei updates won't re-add them to the mbox. Rob
On 23/06/2023 23:17, Rob Herring wrote: >> With my private mailbox I just have a different folder for patches that >> have been sent which I archive once they're applied, but with work GMail >> I don't see how I can easily replicate this since it's also not grouping >> threads properly. > > Yeah, GMail sucks for that. I use 'lei' to get all my patches and > replies to them (though its caching will miss replies). Then I delete > them from the mbox when they are applied or otherwise finished. lei > updates won't re-add them to the mbox. That's interesting approach. What's your lei search query for getting your patches? "f:rob" would get all your threads you participated in. Best regards, Krzysztof
On Fri, 2023-06-23 at 14:38 +0200, Luca Weiss wrote: > With my private mailbox I just have a different folder for patches > that have been sent which I archive once they're applied, but with > work GMail I don't see how I can easily replicate this since it's > also not grouping threads properly. I have something similar, but instead of multiple folders, I use imap labels to achieve the same thing (and then evolution search folders to sort out the labels). I believe GMail has some primitive labelling system that actually works (unlike exchange), so you might be able to get a scheme like that to work. For my mobile phone, which doesn't have the sophisticated search folders evolution does, I use dovecot virtual folders to achieve the same effect. I'm afraid I don't think GMail has any equivalent of this. James
Hi Rob, On Fri Jun 23, 2023 at 11:17 PM CEST, Rob Herring wrote: > On Fri, Jun 23, 2023 at 02:38:04PM +0200, Luca Weiss wrote: > > On Fri Jun 23, 2023 at 2:31 PM CEST, Krzysztof Kozlowski wrote: > > > On 23/06/2023 13:30, Abel Vesa wrote: > > > > There is a warning on dtbs check for sdm845, amongst other platforms, > > > > about the reg-names being unevaluated. Fix that by adding reg-names to > > > > the clocks and reg properties check for such platforms. > > > > > > > > Fixes: 462c5c0aa798 ("dt-bindings: ufs: qcom,ufs: convert to dtschema") > > > > Signed-off-by: Abel Vesa <abel.vesa@linaro.org> > > > > --- > > > > Documentation/devicetree/bindings/ufs/qcom,ufs.yaml | 4 ++++ > > > > 1 file changed, 4 insertions(+) > > > > > > > > diff --git a/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml b/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml > > > > index 0209713d1f88..894b57117314 100644 > > > > --- a/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml > > > > +++ b/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml > > > > @@ -166,6 +166,10 @@ allOf: > > > > reg: > > > > minItems: 2 > > > > maxItems: 2 > > > > + reg-names: > > > > + items: > > > > + - const: std > > > > + - const: ice > > > > > > reg-names looks like a new property, so it should be defined in > > > top-level and just constrained per-variant. > > > > > > Also there was similar approach: > > > https://lore.kernel.org/all/20221209-dt-binding-ufs-v2-2-dc7a04699579@fairphone.com/ > > > > > > but I guess no resends and it can be superseded. > > > > Right, the patches got reviews but was never applied... I really need to > > find a strategy to keep track of sent patches until they're applied with > > my work mailbox, it's not the first time that a patch has gotten > > forgotten. > > There was an error reported on the above series. Why would it be > applied? The error report at [0] complains about reg-names but I'm quite sure that patch 2/3 resolves this error. Does your bot only apply one patch at a time and run the check or apply all of them and then run it? It's been a while but I'm fairly sure I ran all of the checks before sending since I also documented some other patches in the cover letter there. [0] https://lore.kernel.org/all/167241769341.1925758.17856681634949446114.robh@kernel.org/ > > That said, I'm not sure SCSI maintainers consistently apply DT only > patch series. > > > With my private mailbox I just have a different folder for patches that > > have been sent which I archive once they're applied, but with work GMail > > I don't see how I can easily replicate this since it's also not grouping > > threads properly. > > Yeah, GMail sucks for that. I use 'lei' to get all my patches and > replies to them (though its caching will miss replies). Then I delete > them from the mbox when they are applied or otherwise finished. lei > updates won't re-add them to the mbox. I'll try to figure something out with GMail.. Perhaps just adding a label "not yet applied" which I manually remove once it's applied would be sufficient. Regards Luca > > Rob
On 26/06/2023 08:38, Luca Weiss wrote: >>>> but I guess no resends and it can be superseded. >>> >>> Right, the patches got reviews but was never applied... I really need to >>> find a strategy to keep track of sent patches until they're applied with >>> my work mailbox, it's not the first time that a patch has gotten >>> forgotten. >> >> There was an error reported on the above series. Why would it be >> applied? > > The error report at [0] complains about reg-names but I'm quite sure > that patch 2/3 resolves this error. Does your bot only apply one patch > at a time and run the check or apply all of them and then run it? It's > been a while but I'm fairly sure I ran all of the checks before sending > since I also documented some other patches in the cover letter there. You did it in cover letter, not in the patch, so there is no dependency for bots recorded. > > [0] https://lore.kernel.org/all/167241769341.1925758.17856681634949446114.robh@kernel.org/ Your patch 2/3 could not beĀ applied to any tree. 3/3 applied but without previous one caused warnings. Best regards, Krzysztof
On Mon Jun 26, 2023 at 9:41 AM CEST, Krzysztof Kozlowski wrote: > On 26/06/2023 08:38, Luca Weiss wrote: > >>>> but I guess no resends and it can be superseded. > >>> > >>> Right, the patches got reviews but was never applied... I really need to > >>> find a strategy to keep track of sent patches until they're applied with > >>> my work mailbox, it's not the first time that a patch has gotten > >>> forgotten. > >> > >> There was an error reported on the above series. Why would it be > >> applied? > > > > The error report at [0] complains about reg-names but I'm quite sure > > that patch 2/3 resolves this error. Does your bot only apply one patch > > at a time and run the check or apply all of them and then run it? It's > > been a while but I'm fairly sure I ran all of the checks before sending > > since I also documented some other patches in the cover letter there. > > You did it in cover letter, not in the patch, so there is no dependency > for bots recorded. I'm not aware how to put extra comments into a patch in a series with b4, at least last time I checked I don't think it was possible? But I also thought the cover letter was exactly there for giving some background of the series and documenting any dependencies on other patches. > > > > > [0] https://lore.kernel.org/all/167241769341.1925758.17856681634949446114.robh@kernel.org/ > > Your patch 2/3 could not beĀ applied to any tree. 3/3 applied but without > previous one caused warnings. Anyways, just resent the series as v4, maybe this time it can get picked up... Should have enough reviews by now :) Regards Luca > > > > > Best regards, > Krzysztof
On Sat, Jun 24, 2023 at 09:49:12AM +0200, Krzysztof Kozlowski wrote: > On 23/06/2023 23:17, Rob Herring wrote: > >> With my private mailbox I just have a different folder for patches that > >> have been sent which I archive once they're applied, but with work GMail > >> I don't see how I can easily replicate this since it's also not grouping > >> threads properly. > > > > Yeah, GMail sucks for that. I use 'lei' to get all my patches and > > replies to them (though its caching will miss replies). Then I delete > > them from the mbox when they are applied or otherwise finished. lei > > updates won't re-add them to the mbox. > > That's interesting approach. What's your lei search query for getting > your patches? "f:rob" would get all your threads you participated in. This is what I have: q = (dfn:drivers OR dfn:sound OR dfn:tools OR dfn:kernel OR \ dfn:arch OR dfn:Documentation OR dfn:include OR dfn:scripts) AND \ f:robh@kernel.org AND rt:3.month.ago.. Really, I'd like a 'is a patch' flag or 'dfn:*' or 'dfn:/' here, but I didn't convince the lei maintainer such a thing is needed. Sigh. Also, you have to disable lei's caching with the --remote-fudge-time option because it will miss replies to the matching query. Also reported and not fixed... Rob
On Mon, Jun 26, 2023 at 10:19:09AM +0200, Luca Weiss wrote: > On Mon Jun 26, 2023 at 9:41 AM CEST, Krzysztof Kozlowski wrote: > > On 26/06/2023 08:38, Luca Weiss wrote: > > >>>> but I guess no resends and it can be superseded. > > >>> > > >>> Right, the patches got reviews but was never applied... I really need to > > >>> find a strategy to keep track of sent patches until they're applied with > > >>> my work mailbox, it's not the first time that a patch has gotten > > >>> forgotten. > > >> > > >> There was an error reported on the above series. Why would it be > > >> applied? > > > > > > The error report at [0] complains about reg-names but I'm quite sure > > > that patch 2/3 resolves this error. Does your bot only apply one patch > > > at a time and run the check or apply all of them and then run it? It's > > > been a while but I'm fairly sure I ran all of the checks before sending > > > since I also documented some other patches in the cover letter there. > > > > You did it in cover letter, not in the patch, so there is no dependency > > for bots recorded. > > I'm not aware how to put extra comments into a patch in a series with > b4, at least last time I checked I don't think it was possible? But I > also thought the cover letter was exactly there for giving some > background of the series and documenting any dependencies on other > patches. I just put a '---' line and comments after that in the commit messages. That works fine unless your git branch is going upstream directly (i.e. via a pull request). Even when I apply my own patches, I get them from lore and apply so the comments are dropped. Rob
On Tue Jun 27, 2023 at 5:18 PM CEST, Rob Herring wrote: > On Mon, Jun 26, 2023 at 10:19:09AM +0200, Luca Weiss wrote: > > On Mon Jun 26, 2023 at 9:41 AM CEST, Krzysztof Kozlowski wrote: > > > On 26/06/2023 08:38, Luca Weiss wrote: > > > >>>> but I guess no resends and it can be superseded. > > > >>> > > > >>> Right, the patches got reviews but was never applied... I really need to > > > >>> find a strategy to keep track of sent patches until they're applied with > > > >>> my work mailbox, it's not the first time that a patch has gotten > > > >>> forgotten. > > > >> > > > >> There was an error reported on the above series. Why would it be > > > >> applied? > > > > > > > > The error report at [0] complains about reg-names but I'm quite sure > > > > that patch 2/3 resolves this error. Does your bot only apply one patch > > > > at a time and run the check or apply all of them and then run it? It's > > > > been a while but I'm fairly sure I ran all of the checks before sending > > > > since I also documented some other patches in the cover letter there. > > > > > > You did it in cover letter, not in the patch, so there is no dependency > > > for bots recorded. > > > > I'm not aware how to put extra comments into a patch in a series with > > b4, at least last time I checked I don't think it was possible? But I > > also thought the cover letter was exactly there for giving some > > background of the series and documenting any dependencies on other > > patches. > > I just put a '---' line and comments after that in the commit messages. > That works fine unless your git branch is going upstream directly (i.e. > via a pull request). Even when I apply my own patches, I get them from > lore and apply so the comments are dropped. Ah, didn't know this was possible/supported. In the past with git send-email directly I'd edit the patch file and add some text under the "---" manually but wasn't aware you can put it directly in the commit message. But I guess if it produces the same output either way it makes sense. I won't have a problem with pull requests since I'm just a normal patch submitter ;) Thanks for the advice! Regards Luca > > Rob
diff --git a/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml b/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml index 0209713d1f88..894b57117314 100644 --- a/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml +++ b/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml @@ -166,6 +166,10 @@ allOf: reg: minItems: 2 maxItems: 2 + reg-names: + items: + - const: std + - const: ice - if: properties: