linux-kernel - Re: [RFC PATCH] fpga: Introduce new fpga subsystem

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20130930171256.GA28898@obsidianresearch.com>
Date:	Mon, 30 Sep 2013 11:12:56 -0600
From:	Jason Gunthorpe <jgunthorpe@...idianresearch.com>
To:	Michal Simek <monstr@...str.eu>
Cc:	Jason Cooper <jason@...edaemon.net>,
	Michal Simek <michal.simek@...inx.com>,
	linux-kernel@...r.kernel.org, Alan Tull <atull@...era.com>,
	Pavel Machek <pavel@....cz>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Dinh Nguyen <dinguyen@...era.com>,
	Philip Balister <philip@...ister.org>,
	Alessandro Rubini <rubini@...dd.com>,
	Mauro Carvalho Chehab <m.chehab@...sung.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Cesar Eduardo Barros <cesarb@...arb.net>,
	Joe Perches <joe@...ches.com>,
	"David S. Miller" <davem@...emloft.net>,
	Stephen Warren <swarren@...dia.com>,
	Arnd Bergmann <arnd@...db.de>,
	David Brown <davidb@...eaurora.org>,
	Dom Cobley <popcornmix@...il.com>
Subject: Re: [RFC PATCH] fpga: Introduce new fpga subsystem

On Fri, Sep 27, 2013 at 03:31:53PM +0200, Michal Simek wrote:

> I expect that you are detecting/specifying in the driver which
> fpga is connected and you also need to know size of this device.
> Then your driver allocate buffer with this size in the kernel
> and streming data to this buffer. When this is done you are
> using another sysfs files to control device programming.

No, it just streams:

static ssize_t fpga_config_write(struct file *filp,struct kobject *kobj,
                                 struct bin_attribute *attr,
                                 char *buf, loff_t off, size_t len)
{
        struct device *dev = container_of(kobj, struct device, kobj);
        struct platform_device *pdev = to_platform_device(dev);
        struct fpga_priv *priv = platform_get_drvdata(pdev);
        uint8_t *cur = buf;
        size_t total = len;
        unsigned int bit;

        for (; len != 0; len--, cur++) {
                gpio_set_value(priv->gpio[GPIO_CCLK],0);

                for (bit = 0; bit != 8; bit++)
                        gpio_set_value(priv->data_gpio[bit],
                                       (*cur & (1<<bit)) != 0);

                gpio_set_value(priv->gpio[GPIO_CCLK],1);

                if (gpio_get_value(priv->gpio[GPIO_INIT_B]) == 0)
                        return -EIO;
        }
        return total;
}

static struct bin_attribute dev_attr_config_data = {
        .attr = {
                .name = "config_data",
                .mode = 0600,
        },
        .size = 0,
        .write = fpga_config_write,
};

User space does as many writes as necessary to send the entire
bitstream, the sysfs layer chunks things into PAGE_SIZE blocks, so it
acts much like a socket with O_NONBLOCK set.

We are controlling the other related GPIOs from userspace, but for
your purposes I would pair the data sysfs file with a control sysfs
file much like request firwmare does.

Here is a suggestion.
- Two files fpga_config_state, fpga_config_data
- fpga_config_state is a one value text string values are like
   initializing, clearing, programming, operating, error_clear_failed,
   error_bistream_crc
- Userspace writes to fpga_config_state which causes the kernel FSM
  to move to that state. The normal progression would be initializing,
  clearing, programming and finally operating
- The kernel can move to an error_* state if it detects a problem
- The programming state data from fpga_config_data to the
  configuration bus and userspace writes 'operating' once the stream
  is done to perform the post-configuration actions.

Jason
--
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/