linux-kernel - RE: [PATCH v5 char-misc-next] misc: microchip: pci1xxxx: Add OTP/EEPROM driver for the pci1xxxx switch

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: <BN8PR11MB36680842890C294566A156C3E9A39@BN8PR11MB3668.namprd11.prod.outlook.com>
Date:   Wed, 15 Feb 2023 04:37:21 +0000
From:   <Kumaravel.Thiagarajan@...rochip.com>
To:     <michael@...le.cc>, <Tharunkumar.Pasumarthi@...rochip.com>
CC:     <UNGLinuxDriver@...rochip.com>, <arnd@...db.de>,
        <gregkh@...uxfoundation.org>, <linux-gpio@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <srinivas.kandagatla@...aro.org>
Subject: RE: [PATCH v5 char-misc-next] misc: microchip: pci1xxxx: Add
 OTP/EEPROM driver for the pci1xxxx switch

> -----Original Message-----
> From: Michael Walle <michael@...le.cc>
> Sent: Tuesday, February 14, 2023 1:58 PM
> To: Tharunkumar Pasumarthi - I67821
> <Tharunkumar.Pasumarthi@...rochip.com>
> Subject: Re: [PATCH v5 char-misc-next] misc: microchip: pci1xxxx: Add
> OTP/EEPROM driver for the pci1xxxx switch
> 
> > Microchip's pci1xxxx is an unmanaged PCIe3.1a switch for consumer,
> > industrial, and automotive applications. This switch integrates OTP
> > and EEPROM to enable customization of the part in the field. This
> > patch provides the OTP/EEPROM driver to support the same.
> 
> Why isn't this driver using the nvmem subsystem which is usually used for
> OTP and EEPROM?
Michael, these OTP and EEPROM memories do not have any fixed location registers which
store values (Eg. mac address, config parameters, etc) at fixed offsets.
It stores a bunch of records, each of which has some data to be written into the device's
hardware registers at different locations. These records are directly consumed by the hardware
and interpreted without the involvement of the software.
Therefore, we don't require any OTP / EEPROM register map to be input to the OS / driver through
device tree or board files.
I only had to enumerate two separate block devices using the driver so that the config binary files can be 
overlayed using the dd command.
Since this is not fitting like a conventional nvme device, I didn't choose the nvme subsystem.
Please let me know your thoughts / comments if any.

Thank You.

Regards,
Kumar