On 07/11/13 15:25, Aaron Sierra wrote: >> From: "Martyn Welch" <martyn.welch@xxxxxx> >>> This patch removes the bus parameter since its primary function in >>> practice is to prevent the driver from registering itself with the VME >>> subsystem entirely unless some (any) value is passed via the parameter. >>> >>> The bus module parameter seems to be provided as the basis for >>> supporting multiple VME buses. However, the remainder of the driver is >>> written to support a single VME bus. >>> >>> Furthermore, this driver is registered using vme_register_driver from >>> the VME subsystem, which associates this driver with every bus in the >>> system regardless of values passed via the bus parameter. >>> >> >> The VME framework is designed to work in systems that have multiple VME >> bridges (I have been assured in the past these do exist). The functionality >> to support this is clearly still broken in this driver, however I'm not >> convinced the right thing to do is to remove all traces of it. >> >> Martyn >> > > Martyn, > Assuming the vme_user driver fully supported multiple bridges, would there > be any reason to provide this parameter? I presume that the driver would > register against every VME bus in the system and there would be no need to > restrict it to any particular bus(es). > > I think it would be preferable to provide the code necessary to fully > support multiple bridges (though possibly only tested with a single > bridge). Then, hopefully, anyone encountering issues in a system with > multiple bridges would file bug reports so any remaining kinks can be > ironed out. > > -Aaron > Hi Aaron, The user space interface provided by vme_user ended up as more of a debug mechanism during the development of the VME framework than a recommended mechanism for interfacing with the VME bus, however a number of users have stated they've found it useful for tasks with simple requirements. It currently requests a number of windows on each of the buses it is bound to at probe time, if these windows are required for other purposes (such as VME device drivers implemented using the more extensive in-kernel API) then we end up with a resource conflict. From my perspective, a better option would to be able to dynamically request single windows, possibly through a sysfs interface and dropping any requirement to specify buses at boot. Patches are always welcome ;-) Martyn -- Martyn Welch (Lead Software Engineer) | Registered in England and Wales GE Intelligent Platforms | (3828642) at 100 Barbirolli Square T +44(0)1327322748 | Manchester, M2 3AB E martyn.welch@xxxxxx | VAT:GB 927559189 _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
