Re: [PATCH 2/2] New driver: Xillybus generic interface for FPGA(programmable logic)

From: Eli Billauer
Date: Tue Dec 04 2012 - 05:13:56 EST

On 12/04/2012 05:41 AM, Greg KH wrote:
On Sun, Dec 02, 2012 at 07:26:27PM +0200, Eli Billauer wrote:
On 11/30/2012 06:32 PM, Greg KH wrote:
>>+static struct class *xillybus_class;
>Why not just use the misc interface instead of your own class?
When Xillybus is used, the whole system's mission is usually around
it (e.g. it's a computer doing data acquisition through the Xillybus
pipes). So giving it a high profile makes sense, I believe. Besides,
a dozen of device files are not rare.
It is no problem to create dozens of misc devices. It makes your driver
smaller, contain less code that I have to audit and you have to ensure
you got right, and it removes another user of 'struct class' which we
are trying to get rid of anyway. So please, move to use a misc device.

It has just occurred to me that DYNAMIC_MINORS is 64
(drivers/char/misc.c), so I guess that limits the number of misc
devices that can be generated, at least with dynamically allocated
minors. I previously mentioned "a dozen" as the number of devices,
but I've already run tests with 100+ devices, and I can also think
of a sane application for that.

So if I understood the situation correctly, it looks like using misc
devices will create a limitation which will be reached sooner or

Any suggestion what to do?
Given that I don't really understand how you can have that many device
nodes, because I don't know what they all seem to be needed for, I can't
answer this question.

Again, any hints on the user/kernel api you use/need here? Does it
really have to be device nodes? What's wrong with the simple firmware
interface the kernel provides?

I'm currently writing some documentation which will cover the API and also help reading the code, I hope. It takes some time...

Until it's done, let's look at a usage example: Suppose that the FPGA's application is to receive a high-speed bitstream with time multiplexed data, demultiplex the bitstream into individual channel streams, and send each channel's data to the host. And let's say that there are 64 channels in original bitstream. So the FPGA has now 64 independent sources of data.

For that purpose, the Xillybus IP core (on the FPGA) is configured to create 64 pipes for FPGA to host communication. The names of these pipes (say, "chan00", "chan01", ...) are also stored in the FPGA.

When the driver starts, it queries the FPGA for its Xillybus configuration, and creates 64 device nodes: /dev/xillybus_chan00, /dev/xillybus_chan01, ... /dev/xillybus_chan63.

If the user wants to dump the data in channel 43 into a file, it's just:

$ cat /dev/xillybus_chan43 > mydump.dat

I hope this clarified things a bit.

I can't see how the firmware interface would help here.


greg k-h

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at