[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Zfvs-AHcuH2k9x7w@ryzen>
Date: Thu, 21 Mar 2024 09:16:56 +0100
From: Niklas Cassel <cassel@...nel.org>
To: Frank Li <Frank.li@....com>
Cc: mani@...nel.org, kw@...ux.com, niklas.cassel@....com,
bhelgaas@...gle.com, gustavo.pimentel@...opsys.com,
imx@...ts.linux.dev, jdmason@...zu.us, jingoohan1@...il.com,
linux-kernel@...r.kernel.org, linux-pci@...r.kernel.org,
lpieralisi@...nel.org, robh@...nel.org
Subject: Re: [PATCH v2 1/1] PCI: dwc: Fix index 0 incorrectly being
interpreted as a free ATU slot
On Wed, Mar 20, 2024 at 10:29:42AM -0400, Frank Li wrote:
> On Wed, Mar 20, 2024 at 09:53:14AM +0100, Niklas Cassel wrote:
> > On Wed, Mar 13, 2024 at 12:09:04PM +0100, Niklas Cassel wrote:
> > > On Mon, Mar 04, 2024 at 05:46:16PM -0500, Frank Li wrote:
> > > > dw_pcie_ep_inbound_atu()
> > > > {
> > > > ...
> > > > if (!ep->bar_to_atu[bar])
> > > > free_win = find_first_zero_bit(ep->ib_window_map, pci->num_ib_windows);
> > > > else
> > > > free_win = ep->bar_to_atu[bar];
> > > > ...
> > > > }
> > > >
> > > > The atu index 0 is valid case for atu number. The find_first_zero_bit()
> > > > will return 6 when second time call into this function if atu is 0. Suppose
> > > > it should use branch 'free_win = ep->bar_to_atu[bar]'.
> > > >
> > > > Change 'bar_to_atu' to free_win + 1. Initialize bar_to_atu as 0 to indicate
> > > > it have not allocate atu to the bar.
> > > >
> > > > Reported-by: Niklas Cassel <Niklas.Cassel@....com>
> > > > Closes: https://lore.kernel.org/linux-pci/ZXt2A+Fusfz3luQV@x1-carbon/T/#u
> > > > Fixes: 4284c88fff0e ("PCI: designware-ep: Allow pci_epc_set_bar() update inbound map address")
> > > > Reviewed-by: Niklas Cassel <niklas.cassel@....com>
> > > > Signed-off-by: Frank Li <Frank.Li@....com>
> > > > ---
> > >
> > > Any chance of this fix being picked up?
> >
> > Gentle ping.
>
> Now it is v6.9 merge windows. You'd better ping two weeks after linus
> create v6.9-rc1 tag.
I don't follow this logic.
Two weeks after v6.9-rc1 is v6.9-rc3.
Why wait that long to merge a fix?
The PCI pull request for v6.9-rc1 has already been merged.
Merging new features (to a submaintainer tree) might temporarily be put
on hold in relation to the merge window, but for fixes, it is quite
possible to both queue things (in a submaintainer tree), and to send
accumulated fixes to Linus during the merge window.
I did it myself just a few days ago, and Linus pulled it already:
https://lore.kernel.org/linux-ide/171087658094.21820.15365015832308818327.pr-tracker-bot@kernel.org/T/#t
Kind regards,
Niklas
Powered by blists - more mailing lists