> > > > > 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 presume that utility will need root anyway. IOW, it doesn't make
sense to be used as a normal user.
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.
I don't get that point. It is not something you are doing regularly
or maybe even in a running system. I guess you'll have to do a reboot
anyway after you modified some registers defaults. Anyway, it's still
only for provisioning.
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.
Yes, then just build a tool around libpci as I've mentioned. Who is the
user here? An OEM? An end-user? What would an end-user update within
your PCI bridge?
As a matter of fact, it actually makes it harder for a user because
he will also need this kernel driver (which might be disabled for
whatever reason).
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.
What would be an example of that?
-michael
