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?
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.
Regards,
Oliver
_______________________________________________
Socketcan-core mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/socketcan-core
