On 3/6/19 5:39 AM, Rob Herring wrote:
On Tue, Mar 5, 2019 at 8:12 PM Guenter Roeck <linux@xxxxxxxxxxxx> wrote:
On Tue, Feb 12, 2019 at 04:12:24PM -0600, Rob Herring wrote:
On Tue, Feb 12, 2019 at 3:50 PM Stephen Rothwell <sfr@xxxxxxxxxxxxxxxx> wrote:
Hi all,
On Tue, 12 Feb 2019 10:03:09 -0600 Rob Herring <robh+dt@xxxxxxxxxx> wrote:
On Mon, Feb 11, 2019 at 10:47 AM Marc Gonzalez <marc.w.gonzalez@xxxxxxx> wrote:
On 04/02/2019 15:37, Marc Gonzalez wrote:
Cc: stable@xxxxxxxxxxxxxxx # 3.15+
Fixes: 3f0c820664483 ("drivers: of: add initialization code for dynamic reserved memory")
Acked-by: Marek Szyprowski <m.szyprowski@xxxxxxxxxxx>
Acked-by: Prateek Patel <prpatel@xxxxxxxxxx>
Tested-by: Marc Gonzalez <marc.w.gonzalez@xxxxxxx>
Signed-off-by: Mike Rapoport <rppt@xxxxxxxxxxxxx>
---
Resend with DT CCed to reach robh's patch queue
I added CC: stable, Fixes, and Prateek's ack
Trim recipients list to minimize inconvenience
I'm confused over commit 3532b3b554a216f30edb841d29eef48521bdc592 in linux-next
"memblock: drop __memblock_alloc_base()"
It's definitely going to conflict with the proposed patch
over drivers/of/of_reserved_mem.c
Rob, what's the next step then?
Rebase it on top of what's in linux-next and apply it to the tree
which has the above dependency. I'm guessing that is Andrew Morton's
tree.
Yeah, that is in Andrew's "post linux-next" patch series, so if you
rebase it on top of linux-next and then send it to Andrew with some
explanation.
...
Actually, if it is intended for the stable trees, then presumably it is
intended to go to Linus for the current release? In which case, the
patch in Andrew's tree will have to be changed to cope after your patch
appears in Linus' tree (and therefore, linux-next).
At this point in the cycle, I wasn't planning to send this for 5.0.
It's not fixing something introduced in 5.0 and it is a debug feature.
Hi Rob,
this may be a debug feature, but we do test our kernels with it enabled,
and the problem does affect our 4.19 branch (chromeos-4.19). Are you
suggesting that we should backport the fix into our branch and not send
the backport to -stable ?
No, not at all. Just that I wasn't going to add it to the probable
last 5.0-rc and would wait.
However, it's complicated by other memblock changes in 5.1 and not a
trivial backport. One of the versions on the list should be easier to
backport than what's in mainline (or going to be).
We went ahead and applied a backport of an older version of the patch series
to chromeos-4.19. We'll see how well that works, but so far it looks like
it fixes our problem.
Guenter
