Hi Marc and Wolfgang, > -----Original Message----- > From: Wolfgang Grandegger [mailto:[email protected]] > Sent: Wednesday, December 22, 2010 1:21 PM > To: Marc Kleine-Budde > Cc: Bhupesh SHARMA; [email protected]; > [email protected] > Subject: Re: [PATCH net-next-2.6 v2 1/1] can: c_can: Added support for > Bosch C_CAN controller > > On 12/22/2010 07:52 AM, Marc Kleine-Budde wrote: > > 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? > > I was thinking about a "bus independent interface" like for the > SJA1000. > A bus sensitive driver would the be in c_can_platform.c. > > >> 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. > > I fully agree. > > >> If you agree I will try to circulate V3 a.s.ap. > > > > go ahead. > > > > Yes, please.
Ok, so I would try to circulate V3 by tomorrow with a sja1000 *like* approach that ensures in-order packet reception as well. Regards, Bhupesh _______________________________________________ Socketcan-core mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-core
