linux-kernel - Re: [PATCH 02/15] nvmem: microchip-otpc: rework to access packets based on tag

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHp75VffH+tpqP3J+x-ybiwe2O6Mqm6PkaxTrVBgByMpS4Q26w@mail.gmail.com>
Date: Mon, 4 Aug 2025 15:05:42 +0200
From: Andy Shevchenko <andy.shevchenko@...il.com>
To: Varshini Rajendran <varshini.rajendran@...rochip.com>
Cc: eugen.hristev@...aro.org, jic23@...nel.org, dlechner@...libre.com, 
	nuno.sa@...log.com, andy@...nel.org, robh@...nel.org, krzk+dt@...nel.org, 
	conor+dt@...nel.org, nicolas.ferre@...rochip.com, 
	alexandre.belloni@...tlin.com, claudiu.beznea@...on.dev, srini@...nel.org, 
	linux-iio@...r.kernel.org, devicetree@...r.kernel.org, 
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 02/15] nvmem: microchip-otpc: rework to access packets
 based on tag

On Mon, Aug 4, 2025 at 12:03 PM Varshini Rajendran
<varshini.rajendran@...rochip.com> wrote:
>
> Rework the driver to change the packet access technique based on the TAG
> instead of the currently in use "id".
>
> Since there is no way of knowing the OTP memory mapping in advance or the
> changes it can go through with time, the id based approach is not reliable.
> Accessing the packets based on the associated tags is a fail-proof
> approach. This method is aided by adding a table of contents to store the
> payload information which makes it easier to traverse through the OTP
> memory and read the data of the intended packet. The stride of the nvmem
> device is adjusted to 1 to support the TAG being treated as an offset.
> The only reliable way to recognize a packet without being aware of the
> flashed contents of the OTP memory is the TAG of the packet.

...

> +struct mchp_otpc_payload_info {
> +       u32 id;
> +       u32 packet_offset;
> +       u32 payload_length;
> +       u32 packet_type;
> +       u32 packet_tag;

Just wondering if these are okay to be in CPU endianess, i.o.w. is
this part of the protocol to HW, or is it simply Linux driver holding
values?

> +};

...

> +/**
> + * mchp_otpc_read() - Read the OTP packets and fill the buffer based on the TAG
> + *                   of the packet treated as the offset.
> + * @priv: Pointer to device structure.
> + * @off: offset of the OTP packet to be read. In this case, the TAG of the
> + *      corresponding packet.
> + * @val: Pointer to data buffer
> + * @bytes: length of the buffer
> + *
> + * A value of zero will be returned on success, a negative errno will be
> + * returned in error cases.

kernel-doc validator is not happy: Missing Return section.

>   */

...

> -       packet = mchp_otpc_id_to_packet(otpc, off / 4);
> +

Seems like a stray change (adding a blank line).

> +       packet = mchp_otpc_tag_to_packet(otpc, off);
>         if (!packet)
>                 return -EINVAL;

...

> +       writel_relaxed(0UL, otpc->base + MCHP_OTPC_AR);

Does UL give any value  / make any sense here?

...

> +       if (size == 0) {
> +               dev_err(otpc->dev, "Cannot access OTP memory !\n");
> +               if (!emul_enable)
> +                       dev_err(otpc->dev, "Boot packet not configured & Emulation mode not enabled !\n");

Stray space before the exclamation mark in both messages.

> +       }

-- 
With Best Regards,
Andy Shevchenko