Messages in this thread | | | Date | Thu, 9 Jun 2005 13:56:42 -0600 | From | Grant Likely <> | Subject | Re: MPC52xx: sysfs failure on adding new device driver |
| |
I'm moving this thread from the linuxppc-embedded mailing list because it
Greg, I've CC'd you as Kumar suggested that you are the most likely candidate to answer this question. BTW, I've gotten great value from your work on LDD, 3rd ed., so Thanks! :-)
Both the MPC52XX and PowerQuicc microcontroller series of chips have PSC devices that can be programmed to behave as many different devices. (ie. UART, SPI, AC97, Eth, etc). Currently, the generic MPC52xx code (arch/ppc/syslib/mpc52xx_devices.c) sets up a platform_device table that includes all of the PSCs. Each PSC has the name "mpc52xx-psc" and the id is set between 0 and 5.
The assumption had been made that multiple device drivers could be registered with the platform bus and the driver can make the decision on whether or not to pick up the device when its _probe method is called. This assumption is now looking to be wrong.
When I tried to add an "mpc52xx-psc" SPI driver, the device model seemed happy with multiple drivers registered using the same name, but sysfs complained when it tried to create the mpc52xx-psc driver directory (because it was already created by the "mpc52xx-psc" UART driver.).
So, here's the question: In the device model, is there any support for registering multiple drivers for a single type of device? Sylvain made the suggestion that device-driver matching could be performed only upto a special character like '.' so that drivers with different names could bind to the same type of device.
For example, drivers could be named 'mpc52xx-psc.spi' and 'mpc52xx-psc.uart', and both would match a device named 'mpc52xx-psc'.
Another possiblity could be to have the board setup code (ie. arch/ppc/platforms/lite5200.c) modify the platform_device table before it is parsed to change the device name to match the desired driver. The problem with this solution is that it becomes difficult to detach a driver from a device and replace it with another (different function) driver because the device name would need to change after the device is registered (I imagine this could wreck havoc on sysfs)
You can read the whole thread (with example patches) at: http://ozlabs.org/pipermail/linuxppc-embedded/2005-June/018712.html
Cheers, g.
On 6/9/05, Sylvain Munaut <tnt@246tnt.com> wrote: > > Grant Likely wrote: > > I'm working on an MPC52xx SPI device driver using one of the PSC. > > However, when I call driver_register() I get a failure (-17, EEXISTS) > > with a traceback (posted below). > > > > I've tracked it down to failing when trying to create a sysfs entry > > for the driver. It fails because sysfs tries to create a directory > > that already exists (mpc52xx_psc). The directory was already created > > when the psc serial port device driver was registered. > > > >>From what I can tell, I should be able to register more than one > > driver for a particular device name (mpc52xx_psc). > > I always assumed that yes. > But now looking more closely, I'm not sure what I based that assumption > on ... And if not the case that's indeed a problem because that's what's > used to support the different function supported by the PSCs. > > > Otherwise I would > > need to change arch/ppc/syslib/mpc52xx_devices.c to have a different > > name for each psc. > > No you shouldn't have to touch that. The > mpc52xx_match_psc_function(idx, "spi") is there to know which driver > should be used for what PSC and you're using it correctly so it _should_ > work. > > > If I change the sysfs code to ignore the failure > > to create a directory then the driver seems to register fine. > > A "better" quick-fix would be to change the platform_match > (drivers/platform.c) to support "sub-fonctions". For example when using > mpc52xx_psc.spi it only matches what's before the dot (if any) with the > device name. > > That changes the semantic of the driver names for the platform bus > however, making the dot a "special" char. > > > > > Sylvain > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |