Thread (2 messages) flat view 2 messages, 2 authors, 2017-01-06

[PATCH 1/6] ARM: dts: am335x-phycore-som: Update NAND partition table

From: briannorris@chromium.org (Brian Norris)
Date: 2017-01-06 18:20:53
Also in: linux-devicetree, linux-omap

On Fri, Jan 06, 2017 at 08:14:22AM -0800, Tony Lindgren wrote:
* Adam Ford [off-list ref] [170106 08:06]:
quoted
On Fri, Jan 6, 2017 at 10:02 AM, Tony Lindgren [off-list ref] wrote:
quoted
* Teresa Remmet [off-list ref] [170106 01:28]:
quoted
Am Donnerstag, den 05.01.2017, 09:56 -0800 schrieb Brian Norris:
quoted
On Thu, Jan 05, 2017 at 09:18:45AM -0800, Tony Lindgren wrote:
quoted
I'm suggesting we leave the kernel nodes empty and let u-boot
populate them, so maybe you guys can discuss this on the related
lists.
That's an option. I've worked with platforms that did something like
this, and that's really one of the only ways you can handle putting
partition information in the device tree. You're really hamstringing
yourself when you put all the partition information in the device
tree.
And it's just dumb once that gets codified in the kernel source tree.
In our case the bootloader does pass the partition table to the kernel.
So it gets overwritten anyway. This was just more for backup,
if someone uses a different bootloader. But I'm fine with removing the
nand partition table completely from the kernel device tree.
Same with the SPI nor partition table.
Ah, well if these are essentially just a backup, then why do they need
changed at all? To be more precise about my "dumb" statement: it seems
unwise to assume that all systems using a particular board will have the
same partition layout. So *relying* on the in-kernel DTS(I) files to
have a universal partition layout would likely cause problems.

I don't have much problem with keeping a sample layout there as a
backup, if you find it useful. But it seems like it will be hard to
argue that you can ever change it in the future.

Anyway, the ofpart mechanism is there, and it's fine to use it, but it's
up to you to understand the implications and manage the backwards
compatibility problems :)
quoted
quoted
quoted
I will send patches for this.
OK thanks! Also thank you Brian for your comments.
Tony - I tested leaving the partition info as-is with the updates from
the bootloader and it works.  Would you prefer that I match Brian and
remove the partition table completely, or should I just leave my board
alone?

I am good either way.
OK. How about let's remove the partitions from kernel for v4.11 as
clean-up then for cases where the bootloader might change them?
I don't have much stake in this but...if there were any systems using
the backup layout (i.e., the in-kernel partition layout), wouldn't that
break them? Is there a problem with just leaving them alone?

Brian
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help