linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Brian Norris <computersforpeace@gmail.com>
To: Michal Suchanek <hramrach@gmail.com>
Cc: Rob Herring <robh+dt@kernel.org>, Pawel Moll <pawel.moll@arm.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Ian Campbell <ijc+devicetree@hellion.org.uk>,
	Kumar Gala <galak@codeaurora.org>,
	David Woodhouse <dwmw2@infradead.org>,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-mtd@lists.infradead.org
Subject: Re: [PATCH v3 4/5] mtd: ofpart: document the lock flag.
Date: Sun, 11 Oct 2015 13:04:12 -0700	[thread overview]
Message-ID: <20151011200412.GF3696@localhost> (raw)
In-Reply-To: <83fbf31ad895446837f8e01f77a1ff7c63d62251.1439911625.git.hramrach@gmail.com>

On Tue, Aug 18, 2015 at 03:34:08PM -0000, Michal Suchanek wrote:
> The lock flag of ofpart is undocumented. Add to binding doc.

Good catch. There are a lot of small corners of very old code that never
really got reviewed properly, I expect...

(And the flag looks very odd. Why exactly is it in the partitions?)

And now that I'm looking further...does this flag even *do* anything?
AFAICT, it doesn't set the master device flags -- only the partition
flags. But MTD drivers currently never see the partition flags -- they
only see the master struct mtd_info. I think the only way anyone could
observe the effect of this flag is to read the MTD flags from sysfs. And
that's pretty useless.

If my understanding is correct, then I'd rather completely remove the
code that "handles" this flag, rather than codify it in the docs.

> Signed-off-by: Michal Suchanek <hramrach@gmail.com>
> ---
>  Documentation/devicetree/bindings/mtd/partition.txt | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/Documentation/devicetree/bindings/mtd/partition.txt b/Documentation/devicetree/bindings/mtd/partition.txt
> index 8c2aff7..7fa9c08 100644
> --- a/Documentation/devicetree/bindings/mtd/partition.txt
> +++ b/Documentation/devicetree/bindings/mtd/partition.txt
> @@ -29,6 +29,7 @@ Optional properties:
>    partition should only be mounted read-only. This is usually used for flash
>    partitions containing early-boot firmware images or data which should not be
>    clobbered.
> +- lock : Clear always locked after reset flag

This seems more like a SW description. I've reworded slightly locally.

Is my above analysis sensible? If so, I'll patch this to kill the DT
parsing code for "lock" entirely. If I'm wrong, then I can push this
patch. Let me know what you think.

Brian

P.S. IIUC, then most of the 'mask_flags' stuff for partitioned devices
really does nothing. These flags don't seem to ever be checked. Ugh.

  parent reply	other threads:[~2015-10-11 20:04 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <cover.1439911625.git.hramrach@gmail.com>
     [not found] ` <5b636f504e32c9fe83df22694656075f4f45c710.1439911625.git.hramrach@gmail.com>
2015-10-11 20:00   ` [PATCH v3 1/5] mtd: mtdpart: add debug prints to partition parser Brian Norris
     [not found] ` <97366073dfe93b478f24e2fc30ca818326906e0a.1439911625.git.hramrach@gmail.com>
2015-10-11 20:03   ` [PATCH v3 2/5] mtd: mtdpart: Do not fail mtd probe when parsing partitions fails Brian Norris
2015-10-27  1:44     ` Brian Norris
     [not found] ` <e47db0c8eeaeb11353bcb2f4dcd138e813c3ecd7.1439911625.git.hramrach@gmail.com>
2015-10-11 20:04   ` [PATCH v3 3/5] mtd: ofpart: update devicetree binding specification Brian Norris
2015-10-27  2:01     ` Brian Norris
2015-10-27  4:35     ` Rob Herring
2015-10-27 22:50       ` Brian Norris
2015-10-28  0:45         ` Rob Herring
     [not found] ` <83fbf31ad895446837f8e01f77a1ff7c63d62251.1439911625.git.hramrach@gmail.com>
2015-10-11 20:04   ` Brian Norris [this message]
2015-10-27  1:47     ` [PATCH v3 4/5] mtd: ofpart: document the lock flag Brian Norris
     [not found] ` <78e45e51c94899f92ec5d189846c5dd5cf9d8f7a.1439911625.git.hramrach@gmail.com>
2015-10-31  0:21   ` [PATCH v3 5/5] mtd: ofpart: move ofpart partitions to a dedicated dt node Brian Norris

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=20151011200412.GF3696@localhost \
    --to=computersforpeace@gmail.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dwmw2@infradead.org \
    --cc=galak@codeaurora.org \
    --cc=hramrach@gmail.com \
    --cc=ijc+devicetree@hellion.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=mark.rutland@arm.com \
    --cc=pawel.moll@arm.com \
    --cc=robh+dt@kernel.org \
    /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).