All of lore.kernel.org
 help / color / mirror / Atom feed
From: Federico Vaga <federico.vaga@cern.ch>
To: Moritz Fischer <mdf@kernel.org>
Cc: Alan Tull <atull@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: Fri, 17 Aug 2018 09:00:38 +0200	[thread overview]
Message-ID: <2759044.uKe7sI2ItL@pcbe13614> (raw)
In-Reply-To: <20180816220034.GA4431@archbook>

Hi Mortiz,

I'm not 100% into the problem to understand all cases. I'm putting on the 
table the point of view, mainly, of an user. If you say there are problems 
here or there I believe you. At the beginning, you did not say that this 
interface may introduce problems (and I'm interested in those problems since I 
implemented one and we are using it), but that you fear that it becomes the 
default (usually, being a default is a good thing).

Since you and Alan are working on this for a long time, you can read each 
other mind, but I need a more verbose email to understand ^_^'

Of course the interface must be safe, I totally agree. In order to make me 
understand what are the issues, can you list some of them? And expand your 
comment about  MMIO.

(I just did a dummy backport, and implemented that interface. So, I repeat 
myself: I do not have enough experience with this framework to understand all 
consequences, but I'm interested to know what are the risks behind this 
interface)

On Friday, August 17, 2018 12:00:34 AM CEST Moritz Fischer wrote:
> 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





WARNING: multiple messages have this Message-ID (diff)
From: Federico Vaga <federico.vaga@cern.ch>
To: Moritz Fischer <mdf@kernel.org>
Cc: Alan Tull <atull@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: Fri, 17 Aug 2018 09:00:38 +0200	[thread overview]
Message-ID: <2759044.uKe7sI2ItL@pcbe13614> (raw)
In-Reply-To: <20180816220034.GA4431@archbook>

Hi Mortiz,

I'm not 100% into the problem to understand all cases. I'm putting on the 
table the point of view, mainly, of an user. If you say there are problems 
here or there I believe you. At the beginning, you did not say that this 
interface may introduce problems (and I'm interested in those problems since I 
implemented one and we are using it), but that you fear that it becomes the 
default (usually, being a default is a good thing).

Since you and Alan are working on this for a long time, you can read each 
other mind, but I need a more verbose email to understand ^_^'

Of course the interface must be safe, I totally agree. In order to make me 
understand what are the issues, can you list some of them? And expand your 
comment about  MMIO.

(I just did a dummy backport, and implemented that interface. So, I repeat 
myself: I do not have enough experience with this framework to understand all 
consequences, but I'm interested to know what are the risks behind this 
interface)

On Friday, August 17, 2018 12:00:34 AM CEST Moritz Fischer wrote:
> 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-17  7: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
2018-08-17  7:00           ` Federico Vaga [this message]
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=2759044.uKe7sI2ItL@pcbe13614 \
    --to=federico.vaga@cern.ch \
    --cc=appanad@xilinx.com \
    --cc=atull@kernel.org \
    --cc=atull@opensource.altera.com \
    --cc=corbet@lwn.net \
    --cc=dinguyen@kernel.org \
    --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=mdf@kernel.org \
    --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.