On 12/22/2010 04:36 AM, Bhupesh SHARMA wrote: > Hi Wolfgang, > >> Hi Bhupesh, >> >> On 12/21/2010 05:48 AM, Bhupesh SHARMA wrote: >>> Hi Wolfgang, >> ... >>>> In the meantime I compared the CAN chapter of the PCH manual with >> the >>>> C_CAN manual. The paragraphs I checked are *identical*. This makes >>>> clear, that the "pch_can" is a clone of the C_CAN CAN controller, >> with >>>> a few extensions, though. Therefore it would make sense, to >> implement a >>>> bus sensitive interface like for the SJA1000 allowing to handle both >>>> CAN >>>> controllers with one driver sooner than later. Therefore, could you >>>> please implement: >>>> >>>> drivers/net/can/c_can/c_can.c >>>> /c_can_platform.c >>>> >>>> Then an interface to the PCI based PCH CAN controller could be added >>>> easily, e.g. as "pch_pci.c". You already had something similar in >> your >>>> RFC version of the patch, IIRC. >>> >>> This was the approach I initially proposed in my RFC V1 patch :) >>> But unfortunately we could not agree to it. >> >> I know. But at that time I was not aware of any other bus used for the >> C_CAN controller. >> >>> So, please let me reiterate what I understood and what was present >>> in RFC version of the patch. Please add your comments/views: >>> >>> - drivers/net/can/c_can/c_can.c (similar on lines of >> sja1000.c) >>> i.e. a)no *probe* / *remove* functions here, >>> b)register read/write implemented here. >>> >>> - drivers/net/can/c_can/c_can_platform.c (similar on lines of >> sja1000_platform.c) >>> i.e. *probe* / *remove* implemented here, >> >> Yes, that's what I'm thinking about. >> >>> Marc and Tomoya can also add their suggestions so that I can finalize >> V3 a.s.a.p. >> >> That would be nice, indeed. Also have a look to Tomoya's PCH driver, >> which also looks very good in the meantime. > > I am having a look at Tomoya's PCH driver, but as I mentioned in > RFC V1 patch, I would rather like to have a bus sensitive `c_can` driver
What do you mean by a "bus sensitive" driver? > on top of which we can have the platform driver `c_can_platform` which > essentially caters to the details of registers mapping/arch differences. > Any other functionality like USB/PCI should be present in a separate file > like `usb_c_can.c` or `pci_c_can.c` Sounds like the sja1000 approach, which is a good choice. > If you agree I will try to circulate V3 a.s.ap. go ahead. regards, Marc -- Pengutronix e.K. | Marc Kleine-Budde | Industrial Linux Solutions | Phone: +49-231-2826-924 | Vertretung West/Dortmund | Fax: +49-5121-206917-5555 | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Socketcan-core mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-core
