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:   Wed, 15 Feb 2023 09:56:46 +0000
From:   <Kumaravel.Thiagarajan@...rochip.com>
To:     <gregkh@...uxfoundation.org>, <michael@...le.cc>
CC:     <Tharunkumar.Pasumarthi@...rochip.com>,
        <UNGLinuxDriver@...rochip.com>, <arnd@...db.de>,
        <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

> From: Kumaravel Thiagarajan - I21417
> <Kumaravel.Thiagarajan@...rochip.com>
> Sent: Wednesday, February 15, 2023 3:18 PM
> To: Greg KH <gregkh@...uxfoundation.org>; Michael Walle 
> <michael@...le.cc>
> Cc: Tharunkumar Pasumarthi - I67821
> <Tharunkumar.Pasumarthi@...rochip.com>; UNGLinuxDriver 
> <UNGLinuxDriver@...rochip.com>; arnd@...db.de; 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
> 
> >
> > On Wed, Feb 15, 2023 at 09:20:10AM +0100, Michael Walle wrote:
> > > Hi,
> > >
> > > > > > 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.
> > >
> > > So this is only for provisioning. i.e. during manufacturing a 
> > > board which uses this PCI bridge? There are no kernel users, nor 
> > > is there a common interface towards user-space. But just some 
> > > block device (why not a char device?) exposed to userspace. I 
> > > presume there is a companion userspace application for it? Why do 
> > > you take the extra step and have a (random) kernel interface, you 
> > > could also just access the PCI device directly from userspace 
> > > within your companion application, e.g. through libpci.
> >
> > Yeah, why not just use userspace, I missed that, thanks!
> 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.
> I think hardware registers shall be accessible only through safe and 
> robust kernel mode components and that the user space shall only be 
> able to access the device through the kernel mode services.
> I want the user to use the hardware only in those ways designated by 
> the driver.
> We were using the "busybox devmem" to access the hardware registers 
> directly and to program the EEPROM / OTP.
> But we understood that it cannot be an end user solution in all cases 
> and based on some of the operating environments, there can be some 
> restrictions in opening the direct hardware access to the user space.
> Please let me know your thoughts / comments if any.

I missed one more important point. This driver is targeted not just for the manufacturing environment.
we want to be able to update the OTP / EEPROM when the device is in the field also.

Thank You.

Regards,
Kumar