[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y0/fXL0IHCtgj+mn@hovoldconsulting.com>
Date: Wed, 19 Oct 2022 13:28:28 +0200
From: Johan Hovold <johan@...nel.org>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: linux-kernel@...r.kernel.org, stable@...r.kernel.org,
Johan Hovold <johan+linaro@...nel.org>,
Vinod Koul <vkoul@...nel.org>, Sasha Levin <sashal@...nel.org>
Subject: Re: [PATCH 6.0 523/862] phy: qcom-qmp-pcie: add pcs_misc sanity check
On Wed, Oct 19, 2022 at 12:41:31PM +0200, Greg Kroah-Hartman wrote:
> On Wed, Oct 19, 2022 at 11:15:31AM +0200, Johan Hovold wrote:
> > On Wed, Oct 19, 2022 at 10:30:10AM +0200, Greg Kroah-Hartman wrote:
> > > From: Johan Hovold <johan+linaro@...nel.org>
> > >
> > > [ Upstream commit ecd5507e72ea03659dc2cc3e4393fbf8f4e2e02a ]
> > >
> > > Make sure that the (otherwise) optional pcs_misc IO region has been
> > > provided in case the configuration specifies a corresponding
> > > initialisation table to avoid crashing with malformed device trees.
> > >
> > > Note that the related debug message is now superfluous as the region is
> > > only used when the configuration has a pcs_misc table.
> > >
> > > Fixes: 421c9a0e9731 ("phy: qcom: qmp: Add SDM845 PCIe QMP PHY support")
> > > Signed-off-by: Johan Hovold <johan+linaro@...nel.org>
> > > Link: https://lore.kernel.org/r/20220916102340.11520-2-johan+linaro@kernel.org
> > > Signed-off-by: Vinod Koul <vkoul@...nel.org>
> > > Signed-off-by: Sasha Levin <sashal@...nel.org>
> >
> > This was added to prevent future bugs when adding support for new
> > platforms and did not have a stable tag. Please drop.
>
> Ok, that wasn't obvious at all from the changelog :(
Ah, sorry, I misread my own patch. This one does indeed prevent a crash
with malformed devicetrees as the commit message says.
But whether that needs backporting or nor is a separate question. I'd
say either way is fine.
> I'll go drop this, and the others you marked as "should not be there"
> from the queue, thanks.
Thanks.
> Maybe next time, don't use a Fixes: tag if the commit really doesn't
> "fix" anything in the current kernel...
Sorry about the confusion. The Fixes tag is correct in this case.
Johan
Powered by blists - more mailing lists