On Mon, Oct 19, 2009 at 11:33:39AM +0200, Wolfgang Grandegger wrote: > Kurt Van Dijck wrote: > > On Fri, Oct 16, 2009 at 07:28:08PM +0200, Wolfgang Grandegger wrote: [...] > >> > >> - I would follow more closely the existing PHY implementation. [...] > > > > summarized, I believe the differences are way bigger than the > > similarities. > > I did not say (or mean) that you should use the PHY interface for CAN > transceiver. I would just follow more closely the PHY framework, like > registering drivers, etc. The PHY drivers are actually drivers for MDIO bus devices. By not adhering the MDIO bus, I need another driver type. not pci, not i2c, I used 'platform' devices & therefore platform_driver. But, if a pci transceiver would exist (this is getting theoretical, but must work), you'd write a pci-driver, that registers a device in the can_transceiver class. I feel no need to create a new bus type and a new driver type, because there is no new bus. All fits in platform devices.
With regard to The specific topic of drivers, drivers belong to devices on _a_ bus. and drivers in turn create devices in a class. This is how I look at it. PS: The above phrase 'I used platform devices' may indicate this was choice, but it is _not_. Such ad-hoc gpio connected devices _are_ platform devices. > > >> - SysFS is not an option. > > I must admit I do not totally understand this argument during the > > bittiming development of yours either. > > please note that my transceiver implementation is 'rather' seperated > > from the net_devices. > > On the other hand, if transceiver control could be implemented via > > netlink too, I would not veto that. > > The netdev people told use to use the netlink interface for the CAN > device configuration and therefore it's unlikely that they will accept a > SysFS interface for the CAN transceivers. But we could try, in principle. configuring CAN transceivers (which I made regular devices) does not necessarily interfere with net_devices. 1 exception, the matching of net_devices. Hmm, not sure yet. > [...] > > > For my system, I still can do with my previous patch, or use my > > transciever drivers from now. The advantage of the latter is that it is > > quite seperated from CAN chip drivers, and gives SYSFS access on how the > > system connected. > > I understand your arguments but I think we need more time to first > understand the requirements and how to implement it thereafter > efficiently. I really appreciate your effort to start working on this topic. As I appreciate your review. > > Quick question: why do we need a SysFS/Netlink interface at all? 1. as for pca82c251, I'd like to verify whether I configured the right gpio & slope resistor -> RO entries. It looks to me like having the PCI vendor & product in the sysfs directory for a pci device. There arent't that many usefull applications for it, but it's so interesting just to have. As the properties are quite const inside the kernel too, their locking does not pose real problems I think. 2. debug: verify that the actual state is right, modifying the net_device mapping, ... No things that are used to build applications :-) So this argument is less striking. > > Wolfgang. > Kurt _______________________________________________ Socketcan-core mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-core
