Re: [PATCH 1/4] can: dev: Add support for limiting configured bitrate

From: Sergei Shtylyov
Date: Thu Jul 20 2017 - 05:52:25 EST


Hello!

On 7/20/2017 2:36 AM, Franklin S Cooper Jr wrote:

Various CAN or CAN-FD IP may be able to run at a faster rate than
what the transceiver the CAN node is connected to. This can lead to
unexpected errors. However, CAN transceivers typically have fixed
limitations and provide no means to discover these limitations at
runtime. Therefore, add support for a fixed-transceiver node that
can be reused by other CAN peripheral drivers to determine for both
CAN and CAN-FD what the max bitrate that can be used. If the user
tries to configure CAN to pass these maximum bitrates it will throw
an error.

Signed-off-by: Franklin S Cooper Jr <fcooper@xxxxxx>
---
drivers/net/can/dev.c | 48 ++++++++++++++++++++++++++++++++++++++++++++++++
include/linux/can/dev.h | 5 +++++
2 files changed, 53 insertions(+)

diff --git a/drivers/net/can/dev.c b/drivers/net/can/dev.c
index 365a8cc..fbab87d 100644
--- a/drivers/net/can/dev.c
+++ b/drivers/net/can/dev.c
[...]
@@ -814,6 +830,38 @@ int open_candev(struct net_device *dev)
}
EXPORT_SYMBOL_GPL(open_candev);
+#ifdef CONFIG_OF
+void of_transceiver_is_fixed(struct net_device *dev)

Strange name for a *void* function...
Also, I think 'struct net_device *' variables are typically called 'ndev'.

+{
+ struct device_node *dn;
+ struct can_priv *priv = netdev_priv(dev);
+ u32 max_frequency;
+ struct device_node *np;
+
+ np = dev->dev.parent->of_node;
+
+ /* New binding */
+ dn = of_get_child_by_name(np, "fixed-transceiver");
+ if (!dn)
+ return;
+
+ of_property_read_u32(dn, "max-arbitration-speed", &max_frequency);

In case this function fails, 'max_frequency' will have no value -- you'd better initialize it...

+
+ if (max_frequency > 0)
+ priv->max_trans_arbitration_speed = max_frequency;
+ else
+ priv->max_trans_arbitration_speed = -1;
+
+ of_property_read_u32(dn, "max-data-speed", &max_frequency);

Again, when that function fails, the variable will keep the value from the previous call...

[...]

MBR, Sergei