On Monday 10 January 2011, pratyush wrote: > >> +/*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. > > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
