On Mon, Feb 15, 2010 at 12:14:58PM -0800, Ira Snyder wrote: > On Mon, 15 Feb 2010 09:54:22 +0100 > Kurt Van Dijck <[email protected]> wrote: > > > On Fri, Feb 12, 2010 at 03:50:53PM -0800, Ira W. Snyder wrote: [...] > > > + > > > + pdata = pdev->dev.platform_data; > > > + pdata->modno = modno; > > > + pdev->id = modno; > > why twice. I'd rather avoid confusion and assign modno only once. > > > > pdata->modno is part of the "platform data" that gets passed to > subdevices. They need to know their MODULbus module number to be able > to make use of the interrupt registers (which are shared between all > MODULbus modules). > > > pdev->id should be independant of the board/module number. Right now, a > > second carrier board is not possible in the system because of this > > assignement to pdev->id. > > Ok. I thought it was safe to make it the same as the MODULbus module > number, but I guess not. I haven't tried the driver with two PCI cards > in the system yet. > > I'll change it to a monotonically increasing integer. and atomically. Perfect! > [...] > > Thanks for the comments. I'll incorporate them in the next version. > > One quick question: in some systems I have, I expect to have 4 CAN > modules present, connected to 4 different sets of devices. Is there a > way to choose a specific CAN device (can0, can1, etc.) independent of > the PCI enumeration order? > > In ethernet devices, you can use the MAC address to assign a static > name to your ethernet devices, but AFAIK, CAN devices don't have MAC > addresses. > > Note that my boards do have a user-changeable hexadecimal switch on > them. You can read it from the PCI BAR on the board. The Janz character > driver uses this switch + slot number to identify interfaces. You can > move the board to different PCI slots and still have your software work. You need udev magic there.
I suppose the MODULbus devices could use some sysfs properties then. These and the carrier board sysfs properties should allow you to identify the CAN device, and you can rename them on that basis. CAN has no intrinsic support for chip identification, so no, you cannot do this on a netdev basis. I would avoid name collisions by not renaming them to canX anymore. > > Thanks, > Ira Kurt _______________________________________________ Socketcan-core mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-core
