Oliver Hartkopp wrote:
> Kurt Van Dijck wrote:
>> The goal of this patch series is to add an external hook function into
>> the CAN netdevice's open/close functions.
>>
>> I think this is much simpler than using netdev notifactions. These new
>> hook functions carry the original device in its argument list.
>> A hook function for platform_device can be as simple as:
>>
>> static const int can_drv_gpio[NUM] = { ... };
>> static int can_drv_enable(struct platform_device *pdev, int enable)
>> {
>> gpio_set_value(can_drv_gpio[pdev->id], enable);
>> return 0;
>> }
>>
>> This kind of 'glue functions' is what make board run, and should not
>> be too complex IMO.
>>
>> I (EIA Electronics) use this to activate/deactivate a GPIO that powers
>> the CAN transceiver (PCA82...).
>
> Hello Kurt,
>
> i assumed the CAN physical layer would come back into the discussion one day.
> So thanks for picking it up.
>
>> Currently, my tests have been limited to activation/deactivation, since
>> only these operations are affected.
>
> The majority of CAN users and CAN hardware developers only know CAN
> transceivers like the 'dumb' 82C251 (www.nxp.com/pip/PCA82C251_3.html)
> HighSpeed CAN transceiver, which allows 1MBit/s Bitrate.
>
> But when we look at the TJA1054 (www.nxp.com/pip/TJA1054_3.html) or TJA1041
> (www.nxp.com/pip/TJA1041_6.html) CAN transceivers, we get in contact with
>
> - fault tolerance, e.g. when one CAN line is shortened to GND
> - transceiver sleep modes (*)
> - start up the systems power supply due to CAN traffic
> - transceiver error notifications
> - reduced possible bitrates, e.g. the TJA1054 allows only 125 kBit/s
> - etc
>
> * = especially to access the transceiver mode bits STB, /EN, /WAKE on a
> TJA1054 or to read the /ERR pin of the TJA1054 need some real gpio pins. And
> theses gpio pins are heavily hardware depended!
>
> So it's not only 'enabling' and 'disabling' the transceiver, there is need to
> control and read the transceiver states and get some properties like
> max_phy_bitrate or something like this.
>
> Does you approach allow these more complex dependencies also?
Of course not. Kurt proposes a SJA1000 specific implementation.
> Or is probably the PHY abstraction layer
>
> linux/Documentation/networking/phy.txt
>
> something, we should take a look at?
>
> As i'm not a 'platform' specialist maybe someone (like you) could give some
> feedback to these requirements.
That would be nice. Currently, there seem to be some real need to switch
on/off the CAN transceivers. First for the AT91 CAN and now for the
SJA1000 and I would just implement a controller specific interface
similar to the AT91 CAN. A more general approach on how to handle CAN
transceivers or other post initialization task should be provided by the
CAN device driver interface (dev.c). It needs more discussion and also a
real use case.
Wolfgang.
Wolfgang.
>
> Regards,
> Oliver
>
> _______________________________________________
> Socketcan-core mailing list
> [email protected]
> https://lists.berlios.de/mailman/listinfo/socketcan-core
>
>
_______________________________________________
Socketcan-core mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/socketcan-core
