On 10/01/2014 12:57 PM, Roger Quadros wrote: >>> ...if we just have the instance parameter in the syscon phandle, we have >>> to put the mapping into the driver, which makes IMHO no sense, because >>> you have to touch the driver, if there is another SoC with the DCAN core. > > My guess is that TI won't come up with a 3rd variant so we won't have > to touch the driver, but you never know for sure. When I comes to 99% compatible hardware.... I've seen some. >> ... which would be my preferred solution. I think new SoCs should have >> some kind of: >> >> compatible = "commodore,c64ultra", "bosch,d_can"; >> >> in the DT anyhow to allow for SoC specific quirks/adjustments. And >> custom raminit belongs to that IMO (see the ti routine getting more and >> more specific). >> > > Right. For now we need 2 start/stop definations for the existing TI Socs. > > but where to store the raminit start/stop bits? The driver_data currently seems to > contain the CAN type C_CAN vs D_CAN without containing it in a platform_data structure. > > Is it OK to create a new platform_data structure for CAN and put the type and raminit start/stop > bits there? Yes, have a look how it's handled in the flexcan driver. 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 |
Attachment:
signature.asc
Description: OpenPGP digital signature
