On 19/07/12 23:39, Greg Kroah-Hartman wrote: > On Thu, Jul 19, 2012 at 08:08:50PM +0100, Martyn Welch wrote: >> The match function for vme_user is completely wrong. It will blindly bind >> against the first VME slot on each bus (at this point that would be just the >> first bus as the driver can only handle one bus). >> >> The original intention (before some major subsystem changes) was that the >> driver bind against the slot to which the bridge was attached in the VME >> system and to the bus(es) provided via the "bus" module parameter. >> >> To do this cleanly (i.e. without poking arround in the subsystems internal >> stuctures) a functionality has been added to provide access to the bus >> enumeration. > > So does this really solve the problem? How does exporting the function > solve the issue? > The (modified) match function in vme_user does: int cur_bus = vme_bus_get(vdev); int cur_slot = vme_slot_get(vdev); for (i = 0; i < VME_USER_BUS_MAX; i++) if ((cur_bus == bus[i]) && (cur_slot == vdev->num)) It was getting cur_bus that couldn't be done without digging into the vme_bridge structure. I have tested this, it causes the driver to bind to the bus/slot as described in the commit message. Still in two minds about whether we should keep vme_user around. It does seem to have users and there are simple drivers/tasks that could be coded in user space using this. On the other hand, the interface to user space it currently provides isn't idea, neither is the fact that it grabs 4 VME windows when the module is loaded, regardless of whether they ever get used. It was certainly useful during development of the VME subsystem, but my focus is really on the subsystem and kernel space VME drivers. 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/devel