From: Johan Hovold <johan@kernel.org>
To: Sasha Levin <sashal@kernel.org>
Cc: linux-kernel@vger.kernel.org, stable@vger.kernel.org,
Konrad Dybcio <konrad.dybcio@linaro.org>,
Bjorn Andersson <andersson@kernel.org>,
agross@kernel.org, robh+dt@kernel.org,
krzysztof.kozlowski+dt@linaro.org, conor+dt@kernel.org,
linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org
Subject: Re: [PATCH AUTOSEL 6.5 30/36] arm64: dts: qcom: sc8280xp-x13s: Add camera activity LED
Date: Tue, 19 Sep 2023 18:00:15 +0200 [thread overview]
Message-ID: <ZQnFj6g4pbwMz69C@hovoldconsulting.com> (raw)
In-Reply-To: <ZQnA4o7G4A3YC-pe@hovoldconsulting.com>
On Tue, Sep 19, 2023 at 05:40:18PM +0200, Johan Hovold wrote:
> On Tue, Sep 19, 2023 at 11:09:54AM -0400, Sasha Levin wrote:
> > On Tue, Sep 19, 2023 at 03:28:24PM +0200, Johan Hovold wrote:
> > >On Tue, Sep 19, 2023 at 09:06:54AM -0400, Sasha Levin wrote:
> > >> On Tue, Sep 19, 2023 at 08:15:04AM +0200, Johan Hovold wrote:
>
> > >> >Call it what you will, but please drop it. Otherwise by that logic you'd
> > >> >need to backport all devicetree patches (as well as most driver changes)
> > >> >since they ultimately aim at enabling hardware.
> > >>
> > >> Not all, only ones that re-use existing kernel driver but enable it for
> > >> new hardware (i.e. adding a new pci-id/usb-id/dts entries).
> > >
> > >Again, that's basically all our device-tree patches. And that can break
> > >in all sorts of ways. So again, please drop. This does not belong in
> > >stable.
> >
> > This is part of the criteria we use to select patches, yes? If you have
> > an objection around this particular patch then please let me know, or if
> > you have an objection around hardware enablement patches in stable then
> > we can have a bigger discussion around that one.
> >
> > However, just dropping this one for no particular reasonisn't the right
> > approach: we've been using this selection criteria for quite a few years
> > now.
>
> This patch makes zero sense to backport. It's a place holder for a
> camera led that we may one day need. No one marked it for stable, no
> one wants it in stable, no one needs it in stable, yet you repeatedly
> refuse to drop it and keep wasting my time.
>
> Backports, and especially your autosel ones, always come with a risk.
> And here there is ZERO upsides to that. Next time the feature you try to
> retroactively enable may not be as trivial and could cause real
> regressions.
>
> We're on our knees dealing with development and review of stuff that
> people do want and need. And you keep pushing silly things like and
> spamming us with backports that no one asked for. I'm just baffled.
You also seem to have made up new stable kernel rules as adding device
tree nodes clearly doesn't fit the description in
stable-kernel-rules.rst:
It must either fix a real bug that bothers people or just add a
device ID.
(This used to say "New device IDs and quirks are also accepted.")
Johan
next prev parent reply other threads:[~2023-09-19 16:00 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20230908192848.3462476-1-sashal@kernel.org>
2023-09-08 19:28 ` [PATCH AUTOSEL 6.5 05/36] arm64: dts: qcom: sm6125-pdx201: correct ramoops pmsg-size Sasha Levin
2023-09-08 19:28 ` [PATCH AUTOSEL 6.5 06/36] arm64: dts: qcom: sm6125-sprout: " Sasha Levin
2023-09-08 19:28 ` [PATCH AUTOSEL 6.5 07/36] arm64: dts: qcom: sm6350: " Sasha Levin
2023-09-08 19:28 ` [PATCH AUTOSEL 6.5 08/36] arm64: dts: qcom: sm8150-kumano: " Sasha Levin
2023-09-08 19:28 ` [PATCH AUTOSEL 6.5 09/36] arm64: dts: qcom: sm8250-edo: " Sasha Levin
2023-09-08 19:28 ` [PATCH AUTOSEL 6.5 24/36] drm/msm/adreno: Use quirk identify hw_apriv Sasha Levin
2023-09-08 19:28 ` [PATCH AUTOSEL 6.5 25/36] drm/msm/adreno: Use quirk to identify cached-coherent support Sasha Levin
2023-09-08 19:28 ` [PATCH AUTOSEL 6.5 30/36] arm64: dts: qcom: sc8280xp-x13s: Add camera activity LED Sasha Levin
2023-09-11 6:33 ` Johan Hovold
2023-09-18 21:41 ` Sasha Levin
2023-09-19 6:15 ` Johan Hovold
2023-09-19 13:06 ` Sasha Levin
2023-09-19 13:28 ` Johan Hovold
2023-09-19 15:09 ` Sasha Levin
2023-09-19 15:40 ` Johan Hovold
2023-09-19 16:00 ` Johan Hovold [this message]
2023-09-20 4:53 ` Thorsten Leemhuis
2023-09-20 7:06 ` Johan Hovold
2023-09-20 7:16 ` Krzysztof Kozlowski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZQnFj6g4pbwMz69C@hovoldconsulting.com \
--to=johan@kernel.org \
--cc=agross@kernel.org \
--cc=andersson@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=konrad.dybcio@linaro.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=robh+dt@kernel.org \
--cc=sashal@kernel.org \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox