linux-kernel - Re: [PATCH v2 2/3] ARM: dts: socfpga: fpga bridges bindings docs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20141025144229.GR10262@pengutronix.de>
Date:	Sat, 25 Oct 2014 16:42:29 +0200
From:	Steffen Trumtrar <s.trumtrar@...gutronix.de>
To:	Pantelis Antoniou <pantelis.antoniou@...sulko.com>
Cc:	atull@...nsource.altera.com, jgunthorpe@...idianresearch.com,
	hpa@...or.com, Michal Simek <monstr@...str.eu>,
	michal.simek@...inx.com, rdunlap@...radead.org,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	devicetree@...r.kernel.org, robh+dt@...nel.org,
	Grant Likely <grant.likely@...aro.org>, iws@...o.caltech.edu,
	linux-doc@...r.kernel.org, pavel@...x.de, broonie@...nel.org,
	philip@...ister.org, rubini@...dd.com, jason@...edaemon.net,
	kyle.teske@...com, nico@...aro.org, balbi@...com,
	m.chehab@...sung.com, davidb@...eaurora.org, rob@...dley.net,
	davem@...emloft.net, cesarb@...arb.net, sameo@...ux.intel.com,
	akpm@...ux-foundation.org, linus.walleij@...aro.org,
	mgerlach@...nsource.altera.com, delicious.quinoa@...il.com,
	dinguyen@...nsource.altera.com, yvanderv@...nsource.altera.com
Subject: Re: [PATCH v2 2/3] ARM: dts: socfpga: fpga bridges bindings docs

Hi Pantelis!

On Fri, Oct 24, 2014 at 12:20:53PM +0300, Pantelis Antoniou wrote:
> Hi Stefan, Allan,
> 
> Sorry, haven’t had a chance to review all this yet; will do so in the weekend.
> Just wanted to pop in and comment on a few things.
> 
> > On Oct 24, 2014, at 10:00 AM, Steffen Trumtrar <s.trumtrar@...gutronix.de> wrote:
> > 
> > Hi!
> > 
> > On Thu, Oct 23, 2014 at 06:51:06PM -0500, atull@...nsource.altera.com wrote:
> >> From: Alan Tull <atull@...nsource.altera.com>
> > 
> > (...)
> > 
> >> diff --git a/Documentation/devicetree/bindings/fpga/altera-hps2fpga-bridge.txt b/Documentation/devicetree/bindings/fpga/altera-hps2fpga-bridge.txt
> >> new file mode 100644
> >> index 0000000..bc24a2e
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/fpga/altera-hps2fpga-bridge.txt
> >> @@ -0,0 +1,53 @@
> >> +Altera FPGA/HPS Bridge Driver
> >> +
> >> +This driver manages a bridge between a FPGA and a host processor system (HPS).
> >> +User space can enable or disable the bridge by writing a "1" or a "0",
> >> +respectively, to its enable file under bridge's entry in
> >> +/sys/class/fpga-bridge.  Typically, one disables the bridges before
> >> +reprogramming the FPGA.  Once the FPGA is reprogrammed, the bridges are
> >> +reenabled.
> >> +
> > 
> > NAK.
> > 
> > This is all linux specific and doesn't belong here.
> > 
> 
> We know. The DT spec hasn’t been updated for a while, and this is going to be
> part of what we want to do with the restarting of the ePAPR spec process.
>

As we don't have a new spec yet, I go with the current state of the art.
And I don't see how "file under ... /sys/class/fpga-bridge" fits the
current spec.

> So absolutes like “DT is a hardware description only" might be too strong statements, that
> do not work in practice anymore.
> 
> There’s no such thing as pure hardware devices lately - there is always a configuration
> component; some of it OS specific, some of it not.
> 

If it really is necessary, I'm not against it, don't get me wrong.
But in the grand scheme I wouldn't say that this fits my experience.
There are some devices that need configuration and often when it is
done in the DT, it is just a shortcut or not thought through.
And can be also introspected dynamically. With some discussion on the
list these bindings often change.

Regarding OS specifics: already there, e.g. console setup in the chosen node.
And other things I saw are ethernet aliases just for u-boot. Not a problem
of the spec, just a problem of u-boot and unneccessary "configuration".
Just to fix a bad bootloader. barebox can handle this without any
such stuff. Maybe we should integrate the DT "overlays" barebox uses into
the in-kernel DTs as well...but does it really help/interest someone who
decides to use u-boot where barebox stores its environment? I guess not.

> We have to be engaged in the process and figure out how to update the spec for what is
> now the state of the art in the industry.
> 

Again, not against that if it is necessary. For example your overlay stuff might
be a good update to the spec. Would be better if it is official instead of a "hack".
I want that for SoCFPGA.

But having looked at one or two vendor kernels+DTs, the state of the art in the
industry is: using DT wrong. (And doing HW wrong, which makes some updates to the
ePAPR necessary ;-))

Regards,
Steffen

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/