linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Marek Vasut <marex@denx.de>
To: Miquel Raynal <miquel.raynal@bootlin.com>,
	Francesco Dolcini <francesco@dolcini.it>
Cc: Richard Weinberger <richard@nod.at>,
	Vignesh Raghavendra <vigneshr@ti.com>,
	linux-mtd@lists.infradead.org,
	Francesco Dolcini <francesco.dolcini@toradex.com>,
	Shawn Guo <shawnguo@kernel.org>,
	linux-arm-kernel@lists.infradead.org, stable@vger.kernel.org,
	u-boot@lists.denx.de
Subject: Re: [PATCH v1] mtd: parsers: ofpart: Fix parsing when size-cells is 0
Date: Fri, 16 Dec 2022 15:32:28 +0100	[thread overview]
Message-ID: <fb55a784-eda3-8916-1413-581b9436b3f2@denx.de> (raw)
In-Reply-To: <20221216143720.3c8923d8@xps-13>

On 12/16/22 14:37, Miquel Raynal wrote:

Hi,

[...]

>>> What?
>>
>> Let me rephrase, I was not clear enough.
>>
>>> Since when my proposal is breaking boards? My proposal leads to a
>>> situation where:
>>> - If you have a board that has an inconsistent description but worked,
>>>    it will still work.
>>> - If you have a board that has a consistent description and worked, it
>>>    will still work.
>>> - If your have a board that has an inconsistent description and got
>>>    broken *recently* by another change (typically you "fix" the DT in
>>>    Linux to comply with the bindings), then you get a warning that leads
>>>    you on the right path, you then update your bootloader if you can,
>>>    but either way you add your machine compatible to the list of devices
>>>    which need the early fix and your boot is fixed.
>>
>> This implies that we can proactively catch all the affected boards. I do
>> not believe this is reasonable and because of that my comment before
>> about creating regression to the users.
> 
> I really don't understand the reasoning here.
> 
> What I say is: let's fix the boards known to be incorrectly described
> when we break them so they continue working with a broken firmware.

The second part of the message, as far as I understand it, is "ignore 
problems this will cause to users of boards we do not know about, let 
them run into unbootable systems after some linux kernel update, and 
once they suffer through system recovery, make them add compatible 
string to the arch-side workaround".

> What regression could this possibly bring? I don't care about catching
> the 2k boards out there which work but wrongly describe their
> partitions. If they work, they will continue working.

Those boards would start failing once the Linux-side DT size-cells is 
corrected.

Also, this got missed in the previous discussion. If you use only board 
compatible string in arch-side workaround, the workaround would be 
applied even on systems with updated bootloaders, which is likely not 
what we want.

> You and Marek say: let's blindly always change a property in the DT, no
> matter if the board is broken, even if we don't know if this is the
> right thing to do, and apply this to the entire world.

As far as I can tell, if we have partitions in the NAND controller node 
and size-cells=0, then the right thing to do is to override size-cells 
to 1 , because partitions with size-cells=0 make no sense.

If the heuristics here needs to be improved somehow, let's discuss that.

> But with this approach you're not worried about regressions.
> 
> I am sorry it does not stand.

[...]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2022-12-16 14:33 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-02  7:19 [PATCH v1] mtd: parsers: ofpart: Fix parsing when size-cells is 0 Francesco Dolcini
2022-12-02  9:14 ` Miquel Raynal
2022-12-02 10:12   ` Francesco Dolcini
2022-12-02 10:24     ` Francesco Dolcini
2022-12-02 10:53       ` Miquel Raynal
2022-12-02 11:23         ` Francesco Dolcini
2022-12-02 14:05           ` Miquel Raynal
2022-12-02 14:31             ` Marek Vasut
2022-12-02 15:00               ` Miquel Raynal
2022-12-02 15:23                 ` Marek Vasut
2022-12-02 15:49                   ` Miquel Raynal
2022-12-02 16:01                     ` Miquel Raynal
2022-12-02 16:17                     ` Marek Vasut
2022-12-02 16:42                       ` Miquel Raynal
2022-12-02 16:52                         ` Marek Vasut
2022-12-02 16:57                           ` Miquel Raynal
2022-12-02 17:08                             ` Marek Vasut
2022-12-05 11:26                               ` Francesco Dolcini
2022-12-05 13:49                                 ` Miquel Raynal
2022-12-05 16:25                                   ` Marek Vasut
2022-12-15  7:16                                     ` Miquel Raynal
2022-12-15  7:45                                       ` Marek Vasut
2022-12-15  8:04                                         ` Miquel Raynal
2022-12-16  0:36                                           ` Marek Vasut
2022-12-16  7:52                                             ` Francesco Dolcini
2022-12-16  7:45                                       ` Francesco Dolcini
2022-12-16 10:46                                         ` Marek Vasut
2022-12-16 11:01                                           ` Miquel Raynal
2022-12-16 12:37                                             ` Francesco Dolcini
2022-12-16 13:37                                               ` Miquel Raynal
2022-12-16 14:32                                                 ` Marek Vasut [this message]
2022-12-16 15:35                                                   ` Miquel Raynal
2022-12-16 16:30                                                     ` Francesco Dolcini
2023-01-02  9:40                                                       ` Miquel Raynal
2023-01-05 11:33                                                         ` Miquel Raynal
2023-01-05 12:47                                                           ` Francesco Dolcini
2023-01-05 14:51                                                             ` Marek Vasut
2023-01-05 15:03                                                               ` Miquel Raynal
2022-12-02 17:20                         ` Francesco Dolcini
2022-12-05 11:30                           ` Francesco Dolcini
2022-12-05 15:28                             ` Miquel Raynal
2022-12-02 16:45                       ` Francesco Dolcini
2022-12-02 17:05                         ` Miquel Raynal
2022-12-02 15:56               ` Thorsten Leemhuis
2022-12-04 12:50                 ` Marek Vasut
2022-12-04 12:59                   ` Thorsten Leemhuis
2022-12-04 15:50                     ` Marek Vasut
2022-12-02 12:43 ` Greg KH

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=fb55a784-eda3-8916-1413-581b9436b3f2@denx.de \
    --to=marex@denx.de \
    --cc=francesco.dolcini@toradex.com \
    --cc=francesco@dolcini.it \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=miquel.raynal@bootlin.com \
    --cc=richard@nod.at \
    --cc=shawnguo@kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=u-boot@lists.denx.de \
    --cc=vigneshr@ti.com \
    /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;
as well as URLs for NNTP newsgroup(s).