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: AQHZPpY5vK269zMPJUW175op5Ze6367OH1cAgAFGAaCAAEoeAIAACswAgAAHKBA=
Date:   Wed, 15 Feb 2023 09:48:12 +0000
Message-ID: <BN8PR11MB36680D97C97B4894E321CAD9E9A39@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>
In-Reply-To: <Y+yeyNCA48IbKOKC@kroah.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?1idWJnl85zOSahWaudNIrN1wtMcXnuY3s7ixQSxIsUh9P4IJT0eovgRVAERr?=
 =?us-ascii?Q?wtPOICkFCEewWa1DQdbMnm5PSu6ZeGcZ8CjDE+1SkXTmm0Hd5tbEp03k5/xE?=
 =?us-ascii?Q?3sUj3q/6yT5lZfvTl27XyyL/ac+ruwJKY6nSFbsxiuAQGHrX2wZ6lHQg7Qr2?=
 =?us-ascii?Q?3Z1pia4t235F/H6XgIfhEFdu0qcKFadANa02KkNNCV+MZK+tu54qDHpItWKs?=
 =?us-ascii?Q?/X+k9cgiOy5j32Dnq+hpaUvhdeNqv4cgzP5LX6JnbKn0SQnolYVjjzECtyJS?=
 =?us-ascii?Q?NTc5Wh7Gk82iDQMSVOf+/nH0YFMRj6gnHb8HU9ywCtBc/dGWvT1ZyFuXqSWY?=
 =?us-ascii?Q?CPA7nNiTCC5i1C8H05LcvYA7abpKZbMVQHLNjurV4mHhgjLIXDoWX0Y6lj6l?=
 =?us-ascii?Q?cJUZEsxIx9aF8mkCVvtfaVY3KK/PnyQgGpKRTKQWpYNDFoiR5iy9C4NzEFhS?=
 =?us-ascii?Q?boVdBKg1KHMdc/OMnKJ9ew1HSl5I3rDLJo3e3sqzelf9fG/OUxZK8g9c+rQg?=
 =?us-ascii?Q?B+oFp84fwawaRt4SElQzqygiXBQ11CMSNMva8mmA60IxEkTo01y0jAQQT/5k?=
 =?us-ascii?Q?DfE5Hqs34BBRaaluHQ/3XVPp4veH5/Jzzmgh3Q2noNalgSEK+HMSqFN5QIZ+?=
 =?us-ascii?Q?IH4YfSB5cjsHQxHTLMSXjwc74g18kwhC1Bsu7TNSTFLMwxkLmHYPRFuavDXZ?=
 =?us-ascii?Q?Z4qOkD5caMzulwoeDQYblIqeHbNnKV0FRfIcBqH/f/Mp9Wmnzr9u4/JweMUe?=
 =?us-ascii?Q?kitDEqjvtNpP4HGic0ZaoRIqp7LDnWAXTReruNmemFrRLLr7nJl7SZebs77Z?=
 =?us-ascii?Q?atLOMeR6F37RbS7DGFGQZR2PMxS7AOwhfL3Gm+h6K7YcyI93e7l7MIDnT7bm?=
 =?us-ascii?Q?EDbTKJ6gpXuYPqa7V1OAnwtO9lTeSti/JUL59rbkPwQUkJzU2mFZaLBPViFr?=
 =?us-ascii?Q?LvlIR4hVaCgztNyimX6Qw9H3G2zxA3eHWvjouSV26Rny0otYlvmc2BzcwntY?=
 =?us-ascii?Q?RvP5L2iX6dVKRS6/rqlLhWuQT+9lF/xnNxLE27Win4RauyhOc+niDTLTaVCP?=
 =?us-ascii?Q?lQa3VdslFyaIQMoue/eY1uJ+2qktm3Tboqmw6R5bCTUg8XWfaO8wkPim8a5F?=
 =?us-ascii?Q?gRgF21XslbfrkZCP+KSJfIRXnPPm04ZX+ycIzSAVajbgs0hCLZm6dPwSKP4h?=
 =?us-ascii?Q?QJvm9G+KqdLrB3Z9SILiApVJHUY/Qt9c7AXiTZgK4D6HAWhBbS/0aFjWUuwp?=
 =?us-ascii?Q?vtJDxe85+z9dWtozPRtECRwJWbs1dXE78IXr1PBoqugDF71JRo0rXMKc+Fd0?=
 =?us-ascii?Q?PwXGPsYsDRj3Z/Bvp7Mqdkl2mx/XfetJetqtxKCaiMviaU+B3gobUbgB6up8?=
 =?us-ascii?Q?Hoyzotorb848G68/iSWhx1eAUZOWVlnng9Mia5Ia+yrXLYgLWU1siNkwWcwp?=
 =?us-ascii?Q?FpkLEe7s358CrOBhBVJOR006u72TQ2PnHQaUNjujiYQow5x9eovVSkU3Qnps?=
 =?us-ascii?Q?wyeELMAnKlTd3sqAr0+ezLs/UlVts95qtJBirxTZ+mHcgKHbAv/RUle6+5bV?=
 =?us-ascii?Q?mGpSY548+yAKKYCy/6IbicBS1nEEf19MpsJtEMGjtcdtw4h64l6fALDxqnRs?=
 =?us-ascii?Q?WxPX3gOS0SQULJtpQKl2FFU=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: 2dc54145-9152-4bc5-5ed4-08db0f39c0c9
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Feb 2023 09:48:12.4875
 (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: faK4C+vk/Wok2duq/pjDZxJZ21o89xDEIfiQbc2INDuvC72WXCHTOARJ09PnI2vttdAWgrAIgaP64M8gvu/LCC1+xXACHLor7FNapY2vS7A7zamSWJC/SLjlyE6MUBm8
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR11MB7497
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

> From: Greg KH <gregkh@linuxfoundation.org>
> Sent: Wednesday, February 15, 2023 2:29 PM
> To: Michael Walle <michael@walle.cc>
> Cc: Kumaravel Thiagarajan - I21417
> <Kumaravel.Thiagarajan@microchip.com>; 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
> EXTERNAL EMAIL: Do not click links or open attachments unless you know=20
> the content is safe
>=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 switch=20
> > > > > integrates OTP and EEPROM to enable customization of the part=20
> > > > > in the field. This patch provides the OTP/EEPROM driver to=20
> > > > > support the
> same.
> > > >
> > > > Why isn't this driver using the nvmem subsystem which is usually=20
> > > > 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 the=20
> > > 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 board=20
> > which uses this PCI bridge? There are no kernel users, nor is there=20
> > a common interface towards user-space. But just some block device=20
> > (why not a char device?) exposed to userspace. I presume there is a=20
> > companion userspace application for it? Why do you take the extra=20
> > step and have a (random) kernel interface, you could also just=20
> > access the PCI device directly from userspace within your companion=20
> > application, e.g. through libpci.
>=20
> 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 d=
evice
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 de=
vice
through the kernel mode services.
I want the user to use the hardware only in those ways designated by the dr=
iver.
We were using the "busybox devmem" to access the hardware registers directl=
y and to program the EEPROM / OTP.
But we understood that it cannot be an end user solution in all cases and b=
ased 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.

Thank You.

Regards,
Kumar