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]

Date:   Mon, 20 Feb 2023 09:31:45 +0000
From:   <Kumaravel.Thiagarajan@...rochip.com>
To:     <gregkh@...uxfoundation.org>
CC:     <arnd@...db.de>, <linux-gpio@...r.kernel.org>, <michael@...le.cc>,
        <srinivas.kandagatla@...aro.org>, <linux-kernel@...r.kernel.org>,
        <UNGLinuxDriver@...rochip.com>,
        <Tharunkumar.Pasumarthi@...rochip.com>
Subject: Re: [PATCH v5 char-misc-next] misc: microchip: pci1xxxx: Add
 OTP/EEPROM driver for the pci1xxxx switch

On Fri, 2023-02-17 at 10:22 +0100, Greg KH wrote:
> 
> On Fri, Feb 17, 2023 at 08:57:32AM +0000,
> Kumaravel.Thiagarajan@...rochip.com wrote:
> > On Thu, 2023-02-16 at 12:49 +0100, Greg KH wrote:
> > > > > > > Greg & Michael, I do not want to expose the entire or
> > > > > > > even
> > > > > > > partial
> > > > > > > set of device registers to the user space access directly
> > > > > > > for
> > > > > > > safety
> > > > > reasons.
> > > > > 
> > > > > But that's all exposed here through this block device, right?
> > > > The block device created by this driver does not expose the
> > > > device
> > > > registers to the user space applications.
> > > 
> > > What is it exposing?
> > The device's OTP and EEPROM are not directly mapped into the
> > processor's address space using PCIe's BAR registers.
> 
> Ok, that was not obvious and is a lot of the confusion here.
Oh ok, I am sorry if I was not clear.
> 
> > There is a OTP controller and EEPROM controller in the device and
> > the
> > registers of these controllers are mapped into the processor's
> > address
> > space along with other registers using the BAR registers.
> > OTP/EEPROM driver maps these registers into kernel's virtual space
> > using devm_ioremap and accomplishes the reads and writes by
> > accessing
> > these registers. To the user side, the driver shows two separate
> > disks
> > (one for OTP and one for EEPROM) and both of them could be
> > programmed
> > using the "linux dd" command with "oflag=direct" option.
> > The driver handles the IO requests that originate out of the dd
> > command
> > and this way we would not need a separate user space program also.
> 
> I do not recommend using a block interface for this at all.  Why not
> the
> "normal" EEPROM interface that the kernel has today (i.e. a binary
> sysfs
> file)?  That way you can mmap it and edit locations how ever you
> want.
Greg, I have one question about the sysfs interface. If OTP and EEPROM
are enumerated as two sysfs files of 8KB each, will that start
occupying the RAM permamently or is the swapping in and out of the RAM
handled automatically by the kernel based on the user trying to access
it.

Thank You.

Regards,
Kumar