From:   <Kumaravel.Thiagarajan@microchip.com>
To:     <gregkh@linuxfoundation.org>, <michael@walle.cc>
CC:     <Tharunkumar.Pasumarthi@microchip.com>,
        <UNGLinuxDriver@microchip.com>, <arnd@arndb.de>,
        <linux-gpio@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
        <srinivas.kandagatla@linaro.org>
Subject: RE: [PATCH v5 char-misc-next] misc: microchip: pci1xxxx: Add
 OTP/EEPROM driver for the pci1xxxx switch
Thread-Topic: [PATCH v5 char-misc-next] misc: microchip: pci1xxxx: Add
 OTP/EEPROM driver for the pci1xxxx switch
Thread-Index: AQHZPpY5vK269zMPJUW175op5Ze6367OH1cAgAFGAaCAAEoeAIAACswAgAAHKBCAAAiScA==
Date:   Wed, 15 Feb 2023 09:56:46 +0000
Message-ID: <BN8PR11MB3668A1E8541035E257F2C500E9A39@BN8PR11MB3668.namprd11.prod.outlook.com>
References: <20230212035743.231353-1-tharunkumar.pasumarthi@microchip.com>
 <20230214082804.2761756-1-michael@walle.cc>
 <BN8PR11MB36680842890C294566A156C3E9A39@BN8PR11MB3668.namprd11.prod.outlook.com>
 <7276bef47792e489abd093e4bd0044de@walle.cc> <Y+yeyNCA48IbKOKC@kroah.com>
 <BN8PR11MB36680D97C97B4894E321CAD9E9A39@BN8PR11MB3668.namprd11.prod.outlook.com>
In-Reply-To: <BN8PR11MB36680D97C97B4894E321CAD9E9A39@BN8PR11MB3668.namprd11.prod.outlook.com>
Accept-Language: en-IN, en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?LtHoQdwE07XsA9bsEmfL3MWgZp4V14vQ15+Pl+S7kLkJ8YRVbab0wa+j9E5e?=
 =?us-ascii?Q?5TpuFDyi6+/ttCfAQeb96QTFS3E0S1IGLqDLYFJlpDw+5xyXwEEoNz8/K01q?=
 =?us-ascii?Q?IlIcTP28x9GgbG7DjFBcuBZEnDWB8q4NgNNxBmXAQ8VveGxjkxjn3pqYY7vN?=
 =?us-ascii?Q?agavBvgfyQxfuSNwkB3xUhTACOnFaieDHacqkXCUI2uCTqGncNO23w4cbX3w?=
 =?us-ascii?Q?zw/32/a2EnTUZdFWtQ6VIwG5iOezDIlZt5Z3O2sFVXBH4HTyKDcsNO8PQNwf?=
 =?us-ascii?Q?eBf2isOAbSCdegaSmTDmBSgbmb7rVnxeKqifa9DpeevefQMe7LZ538EYY0KX?=
 =?us-ascii?Q?vIkqjSzne5/yWY6JpnTdR+vqXQDjxXr7gObd66ybGtmsx7bINmm8/eKGvWUq?=
 =?us-ascii?Q?y+q3/U3RoegT4Sx9efjBue12zLwk9YlCsF0vJJ0vOnGmqO++CPkC9hn6JCSx?=
 =?us-ascii?Q?JU4imk2dUpanvhvcmyWOJ10WEAPwkWWV64zqpBwQoVLJZoLdIgZbuGKIGy0p?=
 =?us-ascii?Q?AM+5xxWfjDttVvW0ONQgEF7s9cowhG+VgxtbFYzBbRlILCElPeCrRwHzItsB?=
 =?us-ascii?Q?DUjPiJZOq9iIh51bc9iNv/ieAAIFkoOj5mjpWSM1BWCFtp3zv3tayWgUXfcM?=
 =?us-ascii?Q?4FkzBJOtJwSp2bwZVSs+YExVZnVWCfm9LgTbl8dliI6roHMTtUgtcvFurKXO?=
 =?us-ascii?Q?NAC2NY8dc+nj9rRkL8wQiqoxSF5r2aD3BnlmmYhTMWeIsmBJQOOj9T4QeoLU?=
 =?us-ascii?Q?nkc3Z2ee5jB33mV8x1WBgAFeikI/ae1+eBWGeybntHu8dCCxKMI3fV8JCmTB?=
 =?us-ascii?Q?QsPM2SJb/BCZVVWNeVHVU6b7w7K6edq5B11Xyb3R9EukGWLE7eF1Zk8E/pqq?=
 =?us-ascii?Q?TnadTY9r9YadlGfilO4eAIi2WjMKEM95rPQxr+7g2oVR92uG25d94ncvlXjF?=
 =?us-ascii?Q?nLRt6yLJ1+bOb5fEO+IWE2PnlI56mrlzYxQBmrgD1uZXltovPe1HgL+fH6zj?=
 =?us-ascii?Q?wZk3IgWwFWhaPcsK6EiIUVqSBfSSqISxPEYAzrEq4TD+uP1sl161Xddy5Qhv?=
 =?us-ascii?Q?yNkeVhqUhtf895QGSDiu4WOK9lkKAcva6d9vR1Dk1hCnURE7NMGwQv+YBodY?=
 =?us-ascii?Q?3y6em6fnfXbGD6k9st4sIi6Il6myVfOJx3WFCUJJ6qpwkLSU9egybNk8swrJ?=
 =?us-ascii?Q?9E5qPoSt4dhxweXJZdwKhuj053VqR1uqLmZUW9DDIGSc92xnzVouoXdz5Rlu?=
 =?us-ascii?Q?nqxf6qXp0RfXIY6EdfB6LgNzuwUuLgdUpiDvwuldp94so/KWNcbkx/zKsLtv?=
 =?us-ascii?Q?sn/tT3Y/a7v71ADDwf5hi1tjX7dZCo/oWywe6BwKdJOuuWoxaEYlMPgdZBGm?=
 =?us-ascii?Q?GF4i820ZWhWcBXqaJHvNnQkSvW61CzrSxen9fsadd2gB1c2HrZ7sOjNnfkc6?=
 =?us-ascii?Q?cOPIDPbWoyPKn5GmXOMoik7/0vTgr7eNV8Ik+lCFNR219FOEZOL6JkZ3kuni?=
 =?us-ascii?Q?U1TCnQDlUSQ4JGnGxi1MVq1WL9rZI5MiKcoBFach+St5vBNwk3gpz3vgQ5IH?=
 =?us-ascii?Q?ga4I8nIbqOttCj1ibz4oZBjj/xMQNr+Jx6ot1yUP0Y5Q1O70/Jo5vyzSgwhd?=
 =?us-ascii?Q?3SngTtTJO1npXSj8ptkxbNA=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BN8PR11MB3668.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a1d818db-028f-4601-1504-08db0f3af31b
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Feb 2023 09:56:46.3590
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 3f4057f3-b418-4d4e-ba84-d55b4e897d88
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 9XCP8Pa/O0mLa9hGJSRxPJXw0CCRUCqIKwBEy1BlcX9R8y3Fgyg7BMkXmUAI9Qkpcf1dNwGuVvNvGaWr4OZt/xGa5Ja98Qc4A43dDhTujmDjWvvIukad/kPOB06D+Qdt
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR11MB7497
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

> From: Kumaravel Thiagarajan - I21417
> <Kumaravel.Thiagarajan@microchip.com>
> Sent: Wednesday, February 15, 2023 3:18 PM
> To: Greg KH <gregkh@linuxfoundation.org>; Michael Walle=20
> <michael@walle.cc>
> Cc: Tharunkumar Pasumarthi - I67821
> <Tharunkumar.Pasumarthi@microchip.com>; UNGLinuxDriver=20
> <UNGLinuxDriver@microchip.com>; arnd@arndb.de; linux-=20
> gpio@vger.kernel.org; linux-kernel@vger.kernel.org;=20
> srinivas.kandagatla@linaro.org
> Subject: RE: [PATCH v5 char-misc-next] misc: microchip: pci1xxxx: Add=20
> OTP/EEPROM driver for the pci1xxxx switch
>=20
> >
> > On Wed, Feb 15, 2023 at 09:20:10AM +0100, Michael Walle wrote:
> > > Hi,
> > >
> > > > > > Microchip's pci1xxxx is an unmanaged PCIe3.1a switch for=20
> > > > > > consumer, industrial, and automotive applications. This=20
> > > > > > switch integrates OTP and EEPROM to enable customization of=20
> > > > > > the part in the field. This patch provides the OTP/EEPROM=20
> > > > > > driver to support the
> > same.
> > > > >
> > > > > Why isn't this driver using the nvmem subsystem which is=20
> > > > > usually used for OTP and EEPROM?
> > > > Michael, these OTP and EEPROM memories do not have any fixed=20
> > > > location registers which store values (Eg. mac address, config=20
> > > > parameters, etc) at fixed offsets.
> > > > It stores a bunch of records, each of which has some data to be=20
> > > > written into the device's hardware registers at different locations=
.
> > > > These records are directly consumed by the hardware and=20
> > > > interpreted without the involvement of the software.
> > > > Therefore, we don't require any OTP / EEPROM register map to be=20
> > > > input to the OS / driver through device tree or board files.
> > > > I only had to enumerate two separate block devices using the=20
> > > > driver so that the config binary files can be overlayed using=20
> > > > the dd command.
> > > > Since this is not fitting like a conventional nvme device, I=20
> > > > 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=20
> > > board which uses this PCI bridge? There are no kernel users, nor=20
> > > is there a common interface towards user-space. But just some=20
> > > block device (why not a char device?) exposed to userspace. I=20
> > > presume there is a companion userspace application for it? Why do=20
> > > you take the extra step and have a (random) kernel interface, you=20
> > > could also just access the PCI device directly from userspace=20
> > > 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=20
> of device registers to the user space access directly for safety reasons.
> I think hardware registers shall be accessible only through safe and=20
> robust kernel mode components and that the user space shall only be=20
> able to access the device through the kernel mode services.
> I want the user to use the hardware only in those ways designated by=20
> the driver.
> We were using the "busybox devmem" to access the hardware registers=20
> directly and to program the EEPROM / OTP.
> But we understood that it cannot be an end user solution in all cases=20
> and based on some of the operating environments, there can be some=20
> 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 fie=
ld also.

Thank You.

Regards,
Kumar