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  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 15 Oct 2014 12:02:47 +0200
From:	Steffen Trumtrar <>
To:	atull <>
Cc:	Dinh Nguyen <>,
	Philipp Zabel <>,,,,,
Subject: Re: [PATCH] reset: socfpga: use arch_initcall for early


On Tue, Oct 14, 2014 at 01:45:29PM -0500, atull wrote:
> The FPGA bridge driver that I submitted last year handled the following
> things:
>  * The bridges might have been brought out of reset in the bootloader. Some
>    of the bridges have write-only registers (!) so this information had to
>    be passed in DT

Regmap has infrastructure to handle this.

>  * fpga2sdram bridge widths configured in DT

This should hold true for all bridges but the LWHPS.

>  * Supports enabling the following Altera fpga bridges:
>    * fpga2sdram
>    * fpga2hps
>    * hps2fpga
>    * lwhps2fpga
>  * interface in sysfs for each bridge to be put in reset/taken out of reset
>    * Enable (take out of reset):
>      $ echo 1 > /sys/class/fpga-bridge/fpga2hps/enable
>    * Disable (hold in reset):
>      $ echo 0 > /sys/class/fpga-bridge/fpga2hps/enable
>    * Check enable/disable status (checks for all bits set):
>      $ cat /sys/class/fpga-bridge/fpga2hps/enable
>        (will print '0' or '1')

I don't like that. The proper solution should be unloading/loading the
module for the bridge. On a reset the driver has to completely reset its state.

> Now that I'm enabling programming the FPGA from DT overlays, I also want
> to support DT control of the bridges at the proper time.  So that would
> support the use case where adding a DT overlay would:
>  1. program the FPGA
>  2. bring the appropriate bridges out of reset
>  3. modprobe the driver
> Deleting the DT overlay would undo these steps in reverse order.
> I submitted it on 10/8/2013 (I copied you on it), but I don't see it on
>  Probably because I submitted it from a gmail email address and
> that sometimes doesn't play well with lkml.  I'm planning on resubmitting
> when we have it better integrated with the reset subsystem.  If you can
> give me an early idea of how this fits in with your needs, that would be
> great.

I actually remember seeing that driver. The problem with the approach is,
that the bridges are not some IP that you just turn on/off.
The bridges are the busses that connect the FPGA to the SoC. So the driver
and the DT has to accommodate for that.
So, for the (LW)HPS that means we have a bus master driver, that has to

	- check if FPGA manager is enabled in DT
	  - EPROBE_DEFER if FPGA manager isn't loaded
	- check if FPGA is programmed
	  - EPROBE_DEFER otherwise
	- probe subnodes of bridge DT node

	- remove all drivers/devices previously probed by the bridge
	  - put bridge in reset (maybe the remove call should always do that ?)
	- program FPGA with (different) bitstream
	- (update the DT)

I haven't had time to really look at the overlay stuff, but I guess it will then
	- probe bridge drivers with 'status = "okay"' which will probe subdevices

Question is: who will remove the bridge driver? Do the DT overlays do that kind
of stuff?

With the FPGA2HPS(SDRAM) bridges it gets a little difficult I guess.
Who is the master on the FPGA2HPS bridge? Depends on your FPGA config.

Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 |  |
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
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists