Re: [PATCH 1/4] can: dev: Add support for limiting configured bitrate
Hi Kurt,
On 07/26/2017 03:04 PM, Kurt Van Dijck wrote:
> Hi,
>
> I know my response is late ...
>
>> Hi Oliver
>> On 07/20/2017 02:43 AM, Oliver Hartkopp wrote:
>>> Hi Franklin,
>>>
>>> On 07/20/2017 01:36 AM, Franklin S Cooper Jr wrote:
>>>
+#ifdef CONFIG_OF
+void of_transceiver_is_fixed(struct net_device *dev)
+{
>>>
>>> (..)
>>>
+}
+EXPORT_SYMBOL(of_transceiver_is_fixed);
+#endif
>>>
>>> I'm not sure about the naming here.
>>>
>>> As this is a CAN transceiver related option it should be named accordingly:
>
> I contest the the name too:
> 1) the can transceiver isn't fixed at all, it limited to the higher
> bitrates.
Its "possible" that this subnode may have additional properties beyond
bitrates in the future. But your right as of now it is specifically
addressing max bit rates. The naming of this function and subnode is
based on "fixed-link". So "fixed" is just implying that certain
properties can't be changed.
>
> 2) of_can_transceiver_is_fixed suggests to test if a transceiver is
> fixed, it does not suggest to load some properties from the device tree.
> of_can_load_transceiver looks way more clear to me.
I address this partially in my rev 2 that I've already sent. I'm now
using of_can_transceiver_fixed. The fact its of_ already implies it is
loading properties from device tree. So I don't think
of_can_load_transceiver really makes things clearer.
>
> That's my opinion.
> The important things, like the contents of the functions, look good.
You mind throwing your two cents in the thread for my latest patch?
Specifically the conversation regarding naming the properties. A couple
of people prefer to not use "arbitration" in one of the property names.
Currently I believe there are two options on property names that can be
used and I'm open to a majority vote on which one to go with.
>
> Kind regards,
> Kurt Van Dijck
>
Re: [PATCH 1/4] can: dev: Add support for limiting configured bitrate
Hi,
I know my response is late ...
> Hi Oliver
> On 07/20/2017 02:43 AM, Oliver Hartkopp wrote:
> > Hi Franklin,
> >
> > On 07/20/2017 01:36 AM, Franklin S Cooper Jr wrote:
> >
> >> +#ifdef CONFIG_OF
> >> +void of_transceiver_is_fixed(struct net_device *dev)
> >> +{
> >
> > (..)
> >
> >> +}
> >> +EXPORT_SYMBOL(of_transceiver_is_fixed);
> >> +#endif
> >
> > I'm not sure about the naming here.
> >
> > As this is a CAN transceiver related option it should be named accordingly:
I contest the the name too:
1) the can transceiver isn't fixed at all, it limited to the higher
bitrates.
2) of_can_transceiver_is_fixed suggests to test if a transceiver is
fixed, it does not suggest to load some properties from the device tree.
of_can_load_transceiver looks way more clear to me.
That's my opinion.
The important things, like the contents of the functions, look good.
Kind regards,
Kurt Van Dijck
Re: [PATCH 1/4] can: dev: Add support for limiting configured bitrate
On 07/20/2017 04:52 AM, Sergei Shtylyov wrote:
> 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
>> ---
>> 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...
Ok I see what you mean since I'm not actually returning anything. I'll
go with of_can_transceiver_fixed based on your comment also Oliver's
suggestion.
>Also, I think 'struct net_device *' variables are typically called
> 'ndev'.
All other functions within this file uses struct net_device *dev. So I'm
just following the style currently used.
>
>> +{
>> +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...
Thanks for catching this. Will fix.
>
>> +
>> +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...
Will fix.
>
> [...]
>
> MBR, Sergei
Re: [PATCH 1/4] can: dev: Add support for limiting configured bitrate
Hi Oliver
On 07/20/2017 02:43 AM, Oliver Hartkopp wrote:
> Hi Franklin,
>
> On 07/20/2017 01:36 AM, Franklin S Cooper Jr wrote:
>
>> +#ifdef CONFIG_OF
>> +void of_transceiver_is_fixed(struct net_device *dev)
>> +{
>
> (..)
>
>> +}
>> +EXPORT_SYMBOL(of_transceiver_is_fixed);
>> +#endif
>
> I'm not sure about the naming here.
>
> As this is a CAN transceiver related option it should be named accordingly:
>
> E.g.
>
> can_transceiver_is_fixed
> of_can_transceiver_is_fixed
> ...
>
> Especially as it is defined in include/linux/can/dev.h
Thanks for the feedback. I'll go with of_can_transceiver_is_fixed
>
> Regards,
> Oliver
>
>
Re: [PATCH 1/4] can: dev: Add support for limiting configured bitrate
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
---
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
Re: [PATCH 1/4] can: dev: Add support for limiting configured bitrate
Hi Franklin,
On 07/20/2017 01:36 AM, Franklin S Cooper Jr wrote:
+#ifdef CONFIG_OF
+void of_transceiver_is_fixed(struct net_device *dev)
+{
(..)
+}
+EXPORT_SYMBOL(of_transceiver_is_fixed);
+#endif
I'm not sure about the naming here.
As this is a CAN transceiver related option it should be named accordingly:
E.g.
can_transceiver_is_fixed
of_can_transceiver_is_fixed
...
Especially as it is defined in include/linux/can/dev.h
Regards,
Oliver
