On Mon, 2012-05-14 at 13:46 -0700, Greg Kroah-Hartman wrote: > On Mon, May 14, 2012 at 12:41:26PM +0200, Samuel Iglesias Gonsalvez wrote: > > This patch adds a proper device model to the driver. The carrier boards are > > managed like other ipack device, the way to recognize them is using the > > platform data field from struct device. > > Wait, what? Why would you use the platform data field? Why is that > needed at all? You can specify the "type" of the device, but it seems > that you really want two different things here, busses and devices, > right? So use two different devices and manage them differently, don't > make them the "same but different" by looking at the platform data > field. That's not what the platform data field is for at all, sorry. I don't use platform_data to tell apart the devices from buses. Although they don't have auto-discovery, the buses drivers do the matching. I am not avoiding this step. The "real" bus devices are already registered in PCI, USB, VME, etc, as their interface with the rest of the system is through one of these buses. The problem is to make a relation between a ipack bus device and its driver, if we want it to be a registered device in ipack, as this patch does. Platform_data field is filled with the driver that the device belongs to, facilitating the task. There is a similar example in the VME bus with the devices that don't support auto-discovery, as shown in drivers/staging/vme/vme.c in the vme_bus_match() function. Another option is what you say: use two different devices and manage them differently. It will be needed to add new match/probe functions and do similar stuff due to the lack of auto-discovery at this case. A third option is use bus devices like VME bridges in the vme bus driver, i.e, they are not devices, just an abstraction that provides some functionality to the mezzanine devices. I prefer the first option because it reuses the code of the probe/match functions inside the ipack bus driver and it shows the hierarchy through sysfs as everything is a registered device. What do you think? Sam _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
