Thread (9 messages) flat view 9 messages, 5 authors, 2011-01-18

[PATCH V2] ST SPEAr: PCIE gadget suppport

From: arnd@arndb.de (Arnd Bergmann)
Date: 2011-01-18 14:51:59
Also in: lkml

On Monday 10 January 2011, pratyush wrote:
quoted
quoted
+/*wait till link is up*/
+# cat sys/devices/platform/pcie-gadget-spear.0/link
+wait till it returns UP.
A blocking sysfs read is not a nice interface. This is probably where
the sysfs abstraction for your hardware stops making sense.
This call is not blocking. User will have to recheck link status till he
finds it UP. He may put some delay between two successive read. I will
modify documentation to be more explicit.
Ok, that is better, although with this interface you could argue that having
a blocking interface (not a sysfs file) would be useful to have.
quoted
The user interface for the interrupts looks to me like it should really
be based around a character device and either read/write/poll or
ioctl and poll. Using an eventfd might be cool here, because  then you
can combine this with other devices by passing the event file to
an interface that operates on eventfd. This would e.g. make it possible
to combine a UIO device generating interrupts with a PCIe gadget
sending the interrupts somewhere else, without leaving kernel
space.
I do not have much idea about eventfd mechanism. But if we decide to
split it in two layers (generic pcie gadget and HW specific) then I
might try to do it in this way.
 
ok.

	Arnd
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help