All of lore.kernel.org
 help / color / mirror / Atom feed
From: Moritz Fischer <mdf@kernel.org>
To: Federico Vaga <federico.vaga@cern.ch>
Cc: Alan Tull <atull@kernel.org>, Moritz Fischer <mdf@kernel.org>,
	Jonathan Corbet <corbet@lwn.net>,
	Randy Dunlap <rdunlap@infradead.org>,
	Dinh Nguyen <dinguyen@kernel.org>,
	Appana Durga Kedareswara Rao <appanad@xilinx.com>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	linux-fpga@vger.kernel.org,
	Linux Doc Mailing List <linux-doc@vger.kernel.org>,
	Alan Tull <atull@opensource.altera.com>,
	Matthew Gerlach <matthew.gerlach@linux.intel.com>
Subject: Re: [PATCH 2/2] fpga: add FPGA manager debugfs
Date: Thu, 16 Aug 2018 15:00:34 -0700	[thread overview]
Message-ID: <20180816220034.GA4431@archbook> (raw)
In-Reply-To: <1841468.1pWPcT6Du7@harkonnen>

Hi Federico,

On Thu, Aug 16, 2018 at 11:21:32PM +0200, Federico Vaga wrote:
> Hi,
> 
> On Thursday, August 16, 2018 10:04:51 PM CEST Alan Tull wrote:
> > On Thu, Aug 16, 2018 at 1:59 PM, Moritz Fischer <mdf@kernel.org> wrote:
> > > Hi Alan,
> > 
> > Hi Moritz,
> > 
> > > comments inline. While I see how this is useful, I have the
> > > suspicion that from the moment this gets merged vendor kernels
> > > will just default to use this ...
> > 
> > Yeah, I have that suspicion as well.  That's probably why I sat on
> > this and didn't upstream it for 2 years.  But on the other hand, I
> > keep hearing of lots of cases of people implementing this
> > independently anyway.  At least if it is debugfs, it makes it clear
> > that it's not intended for production use.
> 
> I'm one of those guys who implemented this independently.

We all have in one way or another ;) Most people on ARM run an out of tree
patch using devicetree overlays these days I hope rather than /dev/mem
and UIO ... or other vender solutions...
> 
> @Mortiz
> I do not see how this can be a bad thing (from what you wrote I guess you 
> prefer another interface). Which interface to use depends on the use case.
> If you have this suspicion it's, I guess, because such interface it is 
> extremely easy to use.

What happens to a kernel driver doing MMIO with devices while you reload
the entire FPGA from userland?
> 
> @Alan
> DebugFS can be a first step, but I would go for a normal device in /dev at 
> some point. I do not see why this should not be used in production

I'm not against having a userland interface to reprogram the FPGA, the 
Intel DFL code is a good example of a sensible one, doing so in a safe
manner.

Ideally we'll get around to have a more generic interface, as we get
time to work on it.

- Moritz

  reply	other threads:[~2018-08-16 22:00 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-15 22:09 [PATCH 1/2] fpga: doc: documentation for FPGA debugfs Alan Tull
2018-08-15 22:09 ` [PATCH 2/2] fpga: add FPGA manager debugfs Alan Tull
2018-08-15 22:34   ` Randy Dunlap
2018-08-16 14:25     ` Alan Tull
2018-08-16 18:59   ` Moritz Fischer
2018-08-16 20:04     ` Alan Tull
2018-08-16 21:21       ` Federico Vaga
2018-08-16 21:21         ` Federico Vaga
2018-08-16 22:00         ` Moritz Fischer [this message]
2018-08-17  7:00           ` Federico Vaga
2018-08-17  7:00             ` Federico Vaga
2018-08-17 13:19             ` Alan Tull
2018-08-17 14:54               ` Federico Vaga
2018-08-17 14:54                 ` Federico Vaga
2018-08-17 15:22               ` Moritz Fischer
2018-08-17 17:44                 ` Federico Vaga
2018-08-17 17:44                   ` Federico Vaga
2019-03-19 10:28   ` Appana Durga Kedareswara Rao
2019-03-19 10:32     ` Appana Durga Kedareswara Rao
2018-08-15 22:22 ` [PATCH 1/2] fpga: doc: documentation for FPGA debugfs Alan Tull

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=20180816220034.GA4431@archbook \
    --to=mdf@kernel.org \
    --cc=appanad@xilinx.com \
    --cc=atull@kernel.org \
    --cc=atull@opensource.altera.com \
    --cc=corbet@lwn.net \
    --cc=dinguyen@kernel.org \
    --cc=federico.vaga@cern.ch \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-fpga@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matthew.gerlach@linux.intel.com \
    --cc=rdunlap@infradead.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.