From: Michael Walle <michael@walle.cc>
To: Guenter Roeck <linux@roeck-us.net>
Cc: linux-mtd@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
Miquel Raynal <miquel.raynal@bootlin.com>,
Richard Weinberger <richard@nod.at>,
Vignesh Raghavendra <vigneshr@ti.com>,
Rob Herring <robh+dt@kernel.org>,
Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Subject: Re: [PATCH v2 5/5] mtd: core: add OTP nvmem provider support
Date: Fri, 02 Jul 2021 00:10:24 +0200 [thread overview]
Message-ID: <f48661d2d54b37db395fb73af8b52359@walle.cc> (raw)
In-Reply-To: <20210701213420.GA1131789@roeck-us.net>
Hi Guenter,
Am 2021-07-01 23:34, schrieb Guenter Roeck:
> Hi,
>
> On Sat, Apr 24, 2021 at 01:06:08PM +0200, Michael Walle wrote:
>> Flash OTP regions can already be read via user space. Some boards have
>> their serial number or MAC addresses stored in the OTP regions. Add
>> support for them being a (read-only) nvmem provider.
>>
>> The API to read the OTP data is already in place. It distinguishes
>> between factory and user OTP, thus there are up to two different
>> providers.
>>
>> Signed-off-by: Michael Walle <michael@walle.cc>
>
> This patch causes a boot failure with one of my qemu tests.
> With the patch in place, the flash fails to instantiate.
>
> [ 1.156578] Creating 3 MTD partitions on "physmap-flash":
> [ 1.157192] 0x000000000000-0x000000040000 : "U-Boot Bootloader"
> [ 1.184632] 0x000000040000-0x000000060000 : "U-Boot Environment"
> [ 1.201767] 0x000000060000-0x000000800000 : "Flash"
> [ 1.222320] Deleting MTD partitions on "physmap-flash":
> [ 1.222744] Deleting U-Boot Bootloader MTD partition
> [ 1.303597] Deleting U-Boot Environment MTD partition
> [ 1.368751] Deleting Flash MTD partition
> [ 1.430619] physmap-flash: probe of physmap-flash failed with error
> -61
>
> -61 is -ENODATA.
>
> Other boot tests with different flash chips can still boot.
> Reverting this patch (as well as the follow-up patches) fixes
> the problem.
>
> I do not know if this is a problem with qemu or a problem with the
> patch, but, as I mentioned, other flash chips do still instantiate.
>
> Do you have an idea what to look for when I try to track down the
> problem ?
I'd start by looking at the return code of mtd_otp_size() because that
should be the only function which communicates with the flash at probe
time.
Can you share how to reproduce that problem? Like the qemu commandline
and involved images?
-michael
next prev parent reply other threads:[~2021-07-01 22:10 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-24 11:06 [PATCH v2 0/5] mtd: core: OTP nvmem provider support Michael Walle
2021-04-24 11:06 ` [PATCH v2 1/5] nvmem: core: allow specifying of_node Michael Walle
2021-05-10 10:44 ` Miquel Raynal
2021-04-24 11:06 ` [PATCH v2 2/5] dt-bindings: mtd: add YAML schema for the generic MTD bindings Michael Walle
2021-05-10 10:44 ` Miquel Raynal
2021-05-17 15:12 ` Rob Herring
2021-05-17 17:21 ` Michael Walle
2021-04-24 11:06 ` [PATCH v2 3/5] dt-bindings: mtd: add OTP bindings Michael Walle
2021-05-03 17:12 ` Rob Herring
2021-05-10 10:44 ` Miquel Raynal
2021-04-24 11:06 ` [PATCH v2 4/5] dt-bindings: mtd: spi-nor: add otp property Michael Walle
2021-05-03 17:12 ` Rob Herring
2021-05-10 10:44 ` Miquel Raynal
2021-04-24 11:06 ` [PATCH v2 5/5] mtd: core: add OTP nvmem provider support Michael Walle
2021-05-10 10:43 ` Miquel Raynal
2021-05-18 18:55 ` [PATCH] mtd: core: Fix freeing of otp_info buffer Jon Hunter
2021-05-18 20:02 ` Michael Walle
2021-05-26 9:03 ` Miquel Raynal
2021-07-01 21:34 ` [PATCH v2 5/5] mtd: core: add OTP nvmem provider support Guenter Roeck
2021-07-01 22:10 ` Michael Walle [this message]
2021-07-02 1:55 ` Guenter Roeck
2021-07-02 9:33 ` Michael Walle
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=f48661d2d54b37db395fb73af8b52359@walle.cc \
--to=michael@walle.cc \
--cc=devicetree@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=linux@roeck-us.net \
--cc=miquel.raynal@bootlin.com \
--cc=richard@nod.at \
--cc=robh+dt@kernel.org \
--cc=srinivas.kandagatla@linaro.org \
--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).