linux-gpio.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: <Kumaravel.Thiagarajan@microchip.com>
To: <gregkh@linuxfoundation.org>
Cc: <arnd@arndb.de>, <linux-gpio@vger.kernel.org>, <michael@walle.cc>,
	<srinivas.kandagatla@linaro.org>, <linux-kernel@vger.kernel.org>,
	<UNGLinuxDriver@microchip.com>,
	<Tharunkumar.Pasumarthi@microchip.com>
Subject: Re: [PATCH v5 char-misc-next] misc: microchip: pci1xxxx: Add OTP/EEPROM driver for the pci1xxxx switch
Date: Mon, 20 Feb 2023 09:31:45 +0000	[thread overview]
Message-ID: <e1375c213b496b86df3f61d04003d94390c80240.camel@microchip.com> (raw)
In-Reply-To: <Y+9HOdHGqmPP/Ude@kroah.com>

On Fri, 2023-02-17 at 10:22 +0100, Greg KH wrote:
> 
> On Fri, Feb 17, 2023 at 08:57:32AM +0000,
> Kumaravel.Thiagarajan@microchip.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


  reply	other threads:[~2023-02-20  9:32 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-12  3:57 [PATCH v5 char-misc-next] misc: microchip: pci1xxxx: Add OTP/EEPROM driver for the pci1xxxx switch Tharun Kumar P
2023-02-12  7:09 ` Greg KH
2023-02-12  7:52   ` Tharunkumar.Pasumarthi
2023-02-13 12:00   ` Michael Walle
2023-02-14  6:25     ` Tharunkumar.Pasumarthi
2023-02-12  8:02 ` Christophe JAILLET
2023-02-14  6:37   ` Tharunkumar.Pasumarthi
2023-02-14  6:52     ` Tharunkumar.Pasumarthi
2023-02-14  8:28 ` Michael Walle
2023-02-15  4:37   ` Kumaravel.Thiagarajan
2023-02-15  8:20     ` Michael Walle
2023-02-15  8:58       ` Greg KH
2023-02-15  9:48         ` Kumaravel.Thiagarajan
2023-02-15  9:56           ` Kumaravel.Thiagarajan
2023-02-15 10:15             ` Michael Walle
2023-02-15 11:44             ` Greg KH
2023-02-16 11:39               ` Kumaravel.Thiagarajan
2023-02-16 11:49                 ` Greg KH
2023-02-17  8:57                   ` Kumaravel.Thiagarajan
2023-02-17  9:22                     ` Greg KH
2023-02-20  9:31                       ` Kumaravel.Thiagarajan [this message]
2023-02-20  9:45                         ` Greg KH

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e1375c213b496b86df3f61d04003d94390c80240.camel@microchip.com \
    --to=kumaravel.thiagarajan@microchip.com \
    --cc=Tharunkumar.Pasumarthi@microchip.com \
    --cc=UNGLinuxDriver@microchip.com \
    --cc=arnd@arndb.de \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michael@walle.cc \
    --cc=srinivas.kandagatla@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).