from:"Wolfgang Grandegger"




Am 08.03.19 um 18:52 schrieb Dan Murphy:
> On 3/8/19 11:40 AM, Wolfgang Grandegger wrote:
>> Hello Dan,
>>
>> Am 08.03.19 um 18:25 schrieb Dan Murphy:
>>> On 3/8/19 11:08 AM, Wolfgang Grandegger wrote:
>>>> Hello,
>>>>
>>>> Am 08.03.19 um 16:48 schrieb Dan Murphy:
>>>>> Wolfgang
>>>>>
>>>>> On 3/8/19 8:41 AM, Wolfgang Grandegger wrote:
>>>>>> Hello Dan,
>>>>>>
>>>>>> thinking more about it...
>>>>>>
>>>>>> Am 08.03.19 um 14:29 schrieb Wolfgang Grandegger:
>>>>>>> Hello Dan,
>>>>>>>
>>>>>>> Am 08.03.19 um 13:44 schrieb Dan Murphy:
>>>>>>>> Wolfgang
>>>>>>>>
>>>>>>>> On 3/8/19 4:10 AM, Wolfgang Grandegger wrote:
>>>>>>>>> Hallo Dan,
>>>>>>>>>
>>>>>>>>> Am 05.03.19 um 16:52 schrieb Dan Murphy:
>>>>>>>>>> Create a m_can platform framework that peripherial
>>>>>>>>>> devices can register to and use common code and register sets.
>>>>>>>>>> The peripherial devices may provide read/write and configuration
>>>>>>>>>> support of the IP.
>>>>>>>>>>
>>>>>>>>>> Signed-off-by: Dan Murphy 
>>>>>>>>>> ---
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> v7 - Fixed remaining new checkpatch issues, removed CSR setting, 
>>>>>>>>>> fixed tx hard
>>>>>>>>>> start function to return tx_busy, and renamed device callbacks - 
>>>>>>>>>> https://lore.kernel.org/patchwork/patch/1047220/
>>>>>>>>>>
>>>>>>>>>> v6 - Squashed platform patch to this patch for bissectablity, fixed 
>>>>>>>>>> coding style
>>>>>>>>>> issues, updated Kconfig help, placed mcan reg offsets back into c 
>>>>>>>>>> file, renamed
>>>>>>>>>> priv->skb to priv->tx_skb and cleared perp interrupts at ISR start -
>>>>>>>>>> Patch 1 comments - https://lore.kernel.org/patchwork/patch/1042446/
>>>>>>>>>> Patch 2 comments - https://lore.kernel.org/patchwork/patch/1042442/
>>>>>>>>>>
>>>>>>>>>>  drivers/net/can/m_can/Kconfig  |  13 +-
>>>>>>>>>>  drivers/net/can/m_can/Makefile |   1 +
>>>>>>>>>>  drivers/net/can/m_can/m_can.c  | 700 
>>>>>>>>>> +
>>>>>>>>>>  drivers/net/can/m_can/m_can.h  | 110 
>>>>>>>>>>  drivers/net/can/m_can/m_can_platform.c | 202 +++
>>>>>>>>>>  5 files changed, 682 insertions(+), 344 deletions(-)
>>>>>>>>>>  create mode 100644 drivers/net/can/m_can/m_can.h
>>>>>>>>>>  create mode 100644 drivers/net/can/m_can/m_can_platform.c
>>>>>>>>>>
>>>>>>>>>> diff --git a/drivers/net/can/m_can/Kconfig 
>>>>>>>>>> b/drivers/net/can/m_can/Kconfig
>>>>>>>>>> index 04f20dd39007..f7119fd72df4 100644
>>>>>>>>>> --- a/drivers/net/can/m_can/Kconfig
>>>>>>>>>> +++ b/drivers/net/can/m_can/Kconfig
>>>>>>>>>> @@ -1,5 +1,14 @@
>>>>>>>>>>  config CAN_M_CAN
>>>>>>>>>> +tristate "Bosch M_CAN support"
>>>>>>>>>> +---help---
>>>>>>>>>> +  Say Y here if you want support for Bosch M_CAN controller 
>>>>>>>>>> framework.
>>>>>>>>>> +  This is common support for devices that embed the Bosch M_CAN 
>>>>>>>>>> IP.
>>>>>>>>>> +
>>>>>>>>>> +config CAN_M_CAN_PLATFORM
>>>>>>>>>> +tristate "Bosch M_CAN support for io-mapped devices"
>>>>>>>>>>  depends on HAS_IOMEM
>>>>>>>>>> -tristate "Bosch M

Re: [PATCH v7 1/4] can: m_can: Create a m_can platform framework

Hello Dan,

Am 08.03.19 um 18:25 schrieb Dan Murphy:
> On 3/8/19 11:08 AM, Wolfgang Grandegger wrote:
>> Hello,
>>
>> Am 08.03.19 um 16:48 schrieb Dan Murphy:
>>> Wolfgang
>>>
>>> On 3/8/19 8:41 AM, Wolfgang Grandegger wrote:
>>>> Hello Dan,
>>>>
>>>> thinking more about it...
>>>>
>>>> Am 08.03.19 um 14:29 schrieb Wolfgang Grandegger:
>>>>> Hello Dan,
>>>>>
>>>>> Am 08.03.19 um 13:44 schrieb Dan Murphy:
>>>>>> Wolfgang
>>>>>>
>>>>>> On 3/8/19 4:10 AM, Wolfgang Grandegger wrote:
>>>>>>> Hallo Dan,
>>>>>>>
>>>>>>> Am 05.03.19 um 16:52 schrieb Dan Murphy:
>>>>>>>> Create a m_can platform framework that peripherial
>>>>>>>> devices can register to and use common code and register sets.
>>>>>>>> The peripherial devices may provide read/write and configuration
>>>>>>>> support of the IP.
>>>>>>>>
>>>>>>>> Signed-off-by: Dan Murphy 
>>>>>>>> ---
>>>>>>>>
>>>>>>>>
>>>>>>>> v7 - Fixed remaining new checkpatch issues, removed CSR setting, fixed 
>>>>>>>> tx hard
>>>>>>>> start function to return tx_busy, and renamed device callbacks - 
>>>>>>>> https://lore.kernel.org/patchwork/patch/1047220/
>>>>>>>>
>>>>>>>> v6 - Squashed platform patch to this patch for bissectablity, fixed 
>>>>>>>> coding style
>>>>>>>> issues, updated Kconfig help, placed mcan reg offsets back into c 
>>>>>>>> file, renamed
>>>>>>>> priv->skb to priv->tx_skb and cleared perp interrupts at ISR start -
>>>>>>>> Patch 1 comments - https://lore.kernel.org/patchwork/patch/1042446/
>>>>>>>> Patch 2 comments - https://lore.kernel.org/patchwork/patch/1042442/
>>>>>>>>
>>>>>>>>  drivers/net/can/m_can/Kconfig  |  13 +-
>>>>>>>>  drivers/net/can/m_can/Makefile |   1 +
>>>>>>>>  drivers/net/can/m_can/m_can.c  | 700 +
>>>>>>>>  drivers/net/can/m_can/m_can.h  | 110 
>>>>>>>>  drivers/net/can/m_can/m_can_platform.c | 202 +++
>>>>>>>>  5 files changed, 682 insertions(+), 344 deletions(-)
>>>>>>>>  create mode 100644 drivers/net/can/m_can/m_can.h
>>>>>>>>  create mode 100644 drivers/net/can/m_can/m_can_platform.c
>>>>>>>>
>>>>>>>> diff --git a/drivers/net/can/m_can/Kconfig 
>>>>>>>> b/drivers/net/can/m_can/Kconfig
>>>>>>>> index 04f20dd39007..f7119fd72df4 100644
>>>>>>>> --- a/drivers/net/can/m_can/Kconfig
>>>>>>>> +++ b/drivers/net/can/m_can/Kconfig
>>>>>>>> @@ -1,5 +1,14 @@
>>>>>>>>  config CAN_M_CAN
>>>>>>>> +  tristate "Bosch M_CAN support"
>>>>>>>> +  ---help---
>>>>>>>> +Say Y here if you want support for Bosch M_CAN controller 
>>>>>>>> framework.
>>>>>>>> +This is common support for devices that embed the Bosch M_CAN 
>>>>>>>> IP.
>>>>>>>> +
>>>>>>>> +config CAN_M_CAN_PLATFORM
>>>>>>>> +  tristate "Bosch M_CAN support for io-mapped devices"
>>>>>>>>depends on HAS_IOMEM
>>>>>>>> -  tristate "Bosch M_CAN devices"
>>>>>>>> +  depends on CAN_M_CAN
>>>>>>>>---help---
>>>>>>>> -Say Y here if you want to support for Bosch M_CAN controller.
>>>>>>>> +Say Y here if you want support for IO Mapped Bosch M_CAN 
>>>>>>>> controller.
>>>>>>>> +This support is for devices that have the Bosch M_CAN 
>>>>>>>> controller
>>>>>>>> +IP embedded into the device and the IP is IO Mapped to the 
>>>>>>>> processor.
>>>>>>>> di

Re: [PATCH v7 1/4] can: m_can: Create a m_can platform framework

Hello,

Am 08.03.19 um 16:48 schrieb Dan Murphy:
> Wolfgang
> 
> On 3/8/19 8:41 AM, Wolfgang Grandegger wrote:
>> Hello Dan,
>>
>> thinking more about it...
>>
>> Am 08.03.19 um 14:29 schrieb Wolfgang Grandegger:
>>> Hello Dan,
>>>
>>> Am 08.03.19 um 13:44 schrieb Dan Murphy:
>>>> Wolfgang
>>>>
>>>> On 3/8/19 4:10 AM, Wolfgang Grandegger wrote:
>>>>> Hallo Dan,
>>>>>
>>>>> Am 05.03.19 um 16:52 schrieb Dan Murphy:
>>>>>> Create a m_can platform framework that peripherial
>>>>>> devices can register to and use common code and register sets.
>>>>>> The peripherial devices may provide read/write and configuration
>>>>>> support of the IP.
>>>>>>
>>>>>> Signed-off-by: Dan Murphy 
>>>>>> ---
>>>>>>
>>>>>>
>>>>>> v7 - Fixed remaining new checkpatch issues, removed CSR setting, fixed 
>>>>>> tx hard
>>>>>> start function to return tx_busy, and renamed device callbacks - 
>>>>>> https://lore.kernel.org/patchwork/patch/1047220/
>>>>>>
>>>>>> v6 - Squashed platform patch to this patch for bissectablity, fixed 
>>>>>> coding style
>>>>>> issues, updated Kconfig help, placed mcan reg offsets back into c file, 
>>>>>> renamed
>>>>>> priv->skb to priv->tx_skb and cleared perp interrupts at ISR start -
>>>>>> Patch 1 comments - https://lore.kernel.org/patchwork/patch/1042446/
>>>>>> Patch 2 comments - https://lore.kernel.org/patchwork/patch/1042442/
>>>>>>
>>>>>>  drivers/net/can/m_can/Kconfig  |  13 +-
>>>>>>  drivers/net/can/m_can/Makefile |   1 +
>>>>>>  drivers/net/can/m_can/m_can.c  | 700 +
>>>>>>  drivers/net/can/m_can/m_can.h  | 110 
>>>>>>  drivers/net/can/m_can/m_can_platform.c | 202 +++
>>>>>>  5 files changed, 682 insertions(+), 344 deletions(-)
>>>>>>  create mode 100644 drivers/net/can/m_can/m_can.h
>>>>>>  create mode 100644 drivers/net/can/m_can/m_can_platform.c
>>>>>>
>>>>>> diff --git a/drivers/net/can/m_can/Kconfig 
>>>>>> b/drivers/net/can/m_can/Kconfig
>>>>>> index 04f20dd39007..f7119fd72df4 100644
>>>>>> --- a/drivers/net/can/m_can/Kconfig
>>>>>> +++ b/drivers/net/can/m_can/Kconfig
>>>>>> @@ -1,5 +1,14 @@
>>>>>>  config CAN_M_CAN
>>>>>> +tristate "Bosch M_CAN support"
>>>>>> +---help---
>>>>>> +  Say Y here if you want support for Bosch M_CAN controller 
>>>>>> framework.
>>>>>> +  This is common support for devices that embed the Bosch M_CAN 
>>>>>> IP.
>>>>>> +
>>>>>> +config CAN_M_CAN_PLATFORM
>>>>>> +tristate "Bosch M_CAN support for io-mapped devices"
>>>>>>  depends on HAS_IOMEM
>>>>>> -tristate "Bosch M_CAN devices"
>>>>>> +depends on CAN_M_CAN
>>>>>>  ---help---
>>>>>> -  Say Y here if you want to support for Bosch M_CAN controller.
>>>>>> +  Say Y here if you want support for IO Mapped Bosch M_CAN 
>>>>>> controller.
>>>>>> +  This support is for devices that have the Bosch M_CAN 
>>>>>> controller
>>>>>> +  IP embedded into the device and the IP is IO Mapped to the 
>>>>>> processor.
>>>>>> diff --git a/drivers/net/can/m_can/Makefile 
>>>>>> b/drivers/net/can/m_can/Makefile
>>>>>> index 8bbd7f24f5be..057bbcdb3c74 100644
>>>>>> --- a/drivers/net/can/m_can/Makefile
>>>>>> +++ b/drivers/net/can/m_can/Makefile
>>>>>> @@ -3,3 +3,4 @@
>>>>>>  #
>>>>>>  
>>>>>>  obj-$(CONFIG_CAN_M_CAN) += m_can.o
>>>>>> +obj-$(CONFIG_CAN_M_CAN_PLATFORM) += m_can_platform.o
>>>>>> diff --git a/drivers/net/can/m_can/m_can.c 
>>>>>> b/drivers/net/can/m_can/m_can.c
>>>>>> index 9b449400376b..a60278d94126 100644
>

Re: [PATCH v7 1/4] can: m_can: Create a m_can platform framework

Hello Dan,

thinking more about it...

Am 08.03.19 um 14:29 schrieb Wolfgang Grandegger:
> Hello Dan,
> 
> Am 08.03.19 um 13:44 schrieb Dan Murphy:
>> Wolfgang
>>
>> On 3/8/19 4:10 AM, Wolfgang Grandegger wrote:
>>> Hallo Dan,
>>>
>>> Am 05.03.19 um 16:52 schrieb Dan Murphy:
>>>> Create a m_can platform framework that peripherial
>>>> devices can register to and use common code and register sets.
>>>> The peripherial devices may provide read/write and configuration
>>>> support of the IP.
>>>>
>>>> Signed-off-by: Dan Murphy 
>>>> ---
>>>>
>>>>
>>>> v7 - Fixed remaining new checkpatch issues, removed CSR setting, fixed tx 
>>>> hard
>>>> start function to return tx_busy, and renamed device callbacks - 
>>>> https://lore.kernel.org/patchwork/patch/1047220/
>>>>
>>>> v6 - Squashed platform patch to this patch for bissectablity, fixed coding 
>>>> style
>>>> issues, updated Kconfig help, placed mcan reg offsets back into c file, 
>>>> renamed
>>>> priv->skb to priv->tx_skb and cleared perp interrupts at ISR start -
>>>> Patch 1 comments - https://lore.kernel.org/patchwork/patch/1042446/
>>>> Patch 2 comments - https://lore.kernel.org/patchwork/patch/1042442/
>>>>
>>>>  drivers/net/can/m_can/Kconfig  |  13 +-
>>>>  drivers/net/can/m_can/Makefile |   1 +
>>>>  drivers/net/can/m_can/m_can.c  | 700 +
>>>>  drivers/net/can/m_can/m_can.h  | 110 
>>>>  drivers/net/can/m_can/m_can_platform.c | 202 +++
>>>>  5 files changed, 682 insertions(+), 344 deletions(-)
>>>>  create mode 100644 drivers/net/can/m_can/m_can.h
>>>>  create mode 100644 drivers/net/can/m_can/m_can_platform.c
>>>>
>>>> diff --git a/drivers/net/can/m_can/Kconfig b/drivers/net/can/m_can/Kconfig
>>>> index 04f20dd39007..f7119fd72df4 100644
>>>> --- a/drivers/net/can/m_can/Kconfig
>>>> +++ b/drivers/net/can/m_can/Kconfig
>>>> @@ -1,5 +1,14 @@
>>>>  config CAN_M_CAN
>>>> +  tristate "Bosch M_CAN support"
>>>> +  ---help---
>>>> +Say Y here if you want support for Bosch M_CAN controller framework.
>>>> +This is common support for devices that embed the Bosch M_CAN IP.
>>>> +
>>>> +config CAN_M_CAN_PLATFORM
>>>> +  tristate "Bosch M_CAN support for io-mapped devices"
>>>>depends on HAS_IOMEM
>>>> -  tristate "Bosch M_CAN devices"
>>>> +  depends on CAN_M_CAN
>>>>---help---
>>>> -Say Y here if you want to support for Bosch M_CAN controller.
>>>> +Say Y here if you want support for IO Mapped Bosch M_CAN controller.
>>>> +This support is for devices that have the Bosch M_CAN controller
>>>> +IP embedded into the device and the IP is IO Mapped to the processor.
>>>> diff --git a/drivers/net/can/m_can/Makefile 
>>>> b/drivers/net/can/m_can/Makefile
>>>> index 8bbd7f24f5be..057bbcdb3c74 100644
>>>> --- a/drivers/net/can/m_can/Makefile
>>>> +++ b/drivers/net/can/m_can/Makefile
>>>> @@ -3,3 +3,4 @@
>>>>  #
>>>>  
>>>>  obj-$(CONFIG_CAN_M_CAN) += m_can.o
>>>> +obj-$(CONFIG_CAN_M_CAN_PLATFORM) += m_can_platform.o
>>>> diff --git a/drivers/net/can/m_can/m_can.c b/drivers/net/can/m_can/m_can.c
>>>> index 9b449400376b..a60278d94126 100644
>>>> --- a/drivers/net/can/m_can/m_can.c
>>>> +++ b/drivers/net/can/m_can/m_can.c
>>>
>>> ... snip...
>>>
>>>> +static netdev_tx_t m_can_start_xmit(struct sk_buff *skb,
>>>> +  struct net_device *dev)
>>>> +{
>>>> +  struct m_can_priv *priv = netdev_priv(dev);
>>>> +
>>>> +  if (can_dropped_invalid_skb(dev, skb))
>>>> +  return NETDEV_TX_OK;
>>>> +
>>>> +  if (priv->is_peripherial) {
>>>> +  if (priv->tx_skb) {
>>>> +  netdev_err(dev, "hard_xmit called while tx busy\n");
>>>> +  return NETDEV_TX_BUSY;
>>>> +  }
>>>
>>> The problem with that approach is, that the upper layer will try to
>>> resubmit the current "skb" but not the previous "tx_skb". And t

Re: [PATCH v7 1/4] can: m_can: Create a m_can platform framework

Hello Dan,

Am 08.03.19 um 13:44 schrieb Dan Murphy:
> Wolfgang
> 
> On 3/8/19 4:10 AM, Wolfgang Grandegger wrote:
>> Hallo Dan,
>>
>> Am 05.03.19 um 16:52 schrieb Dan Murphy:
>>> Create a m_can platform framework that peripherial
>>> devices can register to and use common code and register sets.
>>> The peripherial devices may provide read/write and configuration
>>> support of the IP.
>>>
>>> Signed-off-by: Dan Murphy 
>>> ---
>>>
>>>
>>> v7 - Fixed remaining new checkpatch issues, removed CSR setting, fixed tx 
>>> hard
>>> start function to return tx_busy, and renamed device callbacks - 
>>> https://lore.kernel.org/patchwork/patch/1047220/
>>>
>>> v6 - Squashed platform patch to this patch for bissectablity, fixed coding 
>>> style
>>> issues, updated Kconfig help, placed mcan reg offsets back into c file, 
>>> renamed
>>> priv->skb to priv->tx_skb and cleared perp interrupts at ISR start -
>>> Patch 1 comments - https://lore.kernel.org/patchwork/patch/1042446/
>>> Patch 2 comments - https://lore.kernel.org/patchwork/patch/1042442/
>>>
>>>  drivers/net/can/m_can/Kconfig  |  13 +-
>>>  drivers/net/can/m_can/Makefile |   1 +
>>>  drivers/net/can/m_can/m_can.c  | 700 +
>>>  drivers/net/can/m_can/m_can.h  | 110 
>>>  drivers/net/can/m_can/m_can_platform.c | 202 +++
>>>  5 files changed, 682 insertions(+), 344 deletions(-)
>>>  create mode 100644 drivers/net/can/m_can/m_can.h
>>>  create mode 100644 drivers/net/can/m_can/m_can_platform.c
>>>
>>> diff --git a/drivers/net/can/m_can/Kconfig b/drivers/net/can/m_can/Kconfig
>>> index 04f20dd39007..f7119fd72df4 100644
>>> --- a/drivers/net/can/m_can/Kconfig
>>> +++ b/drivers/net/can/m_can/Kconfig
>>> @@ -1,5 +1,14 @@
>>>  config CAN_M_CAN
>>> +   tristate "Bosch M_CAN support"
>>> +   ---help---
>>> + Say Y here if you want support for Bosch M_CAN controller framework.
>>> + This is common support for devices that embed the Bosch M_CAN IP.
>>> +
>>> +config CAN_M_CAN_PLATFORM
>>> +   tristate "Bosch M_CAN support for io-mapped devices"
>>> depends on HAS_IOMEM
>>> -   tristate "Bosch M_CAN devices"
>>> +   depends on CAN_M_CAN
>>> ---help---
>>> - Say Y here if you want to support for Bosch M_CAN controller.
>>> + Say Y here if you want support for IO Mapped Bosch M_CAN controller.
>>> + This support is for devices that have the Bosch M_CAN controller
>>> + IP embedded into the device and the IP is IO Mapped to the processor.
>>> diff --git a/drivers/net/can/m_can/Makefile b/drivers/net/can/m_can/Makefile
>>> index 8bbd7f24f5be..057bbcdb3c74 100644
>>> --- a/drivers/net/can/m_can/Makefile
>>> +++ b/drivers/net/can/m_can/Makefile
>>> @@ -3,3 +3,4 @@
>>>  #
>>>  
>>>  obj-$(CONFIG_CAN_M_CAN) += m_can.o
>>> +obj-$(CONFIG_CAN_M_CAN_PLATFORM) += m_can_platform.o
>>> diff --git a/drivers/net/can/m_can/m_can.c b/drivers/net/can/m_can/m_can.c
>>> index 9b449400376b..a60278d94126 100644
>>> --- a/drivers/net/can/m_can/m_can.c
>>> +++ b/drivers/net/can/m_can/m_can.c
>>
>> ... snip...
>>
>>> +static netdev_tx_t m_can_start_xmit(struct sk_buff *skb,
>>> +   struct net_device *dev)
>>> +{
>>> +   struct m_can_priv *priv = netdev_priv(dev);
>>> +
>>> +   if (can_dropped_invalid_skb(dev, skb))
>>> +   return NETDEV_TX_OK;
>>> +
>>> +   if (priv->is_peripherial) {
>>> +   if (priv->tx_skb) {
>>> +   netdev_err(dev, "hard_xmit called while tx busy\n");
>>> +   return NETDEV_TX_BUSY;
>>> +   }
>>
>> The problem with that approach is, that the upper layer will try to
>> resubmit the current "skb" but not the previous "tx_skb". And the
>> previous "tx_skb" has not been freed yet. I would just drop and free the
>> skb and return NETDEV_TX_OK in m_can_tx_handler() for peripheral devices
>> (like can_dropped_invalid_skb() does).
>>
> 
> OK.
> 
> So would this also be a bug in the hi3110 and mcp251x drivers (line 521) as 
> well because besides checking tx_length
> this is how these drivers are written.

This is different. W

Re: [PATCH v7 2/4] can: m_can: Rename m_can_priv to m_can_classdev




Am 05.03.19 um 16:52 schrieb Dan Murphy:
> Rename the common m_can_priv class structure to
> m_can_classdev as this is more descriptive.
> 
> Signed-off-by: Dan Murphy 
> ---
> 
> v7 - Fixed remaining checkpatch issues, renamed priv to cdev - 
> https://lore.kernel.org/patchwork/patch/1047219/
> 
> v6 - No changes only rebase changes possibly can squash into the first patch 
> - 
> https://lore.kernel.org/patchwork/patch/1042444/
> 
>  drivers/net/can/m_can/m_can.c  | 524 -
>  drivers/net/can/m_can/m_can.h  |  28 +-
>  drivers/net/can/m_can/m_can_platform.c |  16 +-
>  3 files changed, 284 insertions(+), 284 deletions(-)

...snip...

> diff --git a/drivers/net/can/m_can/m_can.h b/drivers/net/can/m_can/m_can.h
> index b60f27dd9f33..1299cc747194 100644
> --- a/drivers/net/can/m_can/m_can.h
> +++ b/drivers/net/can/m_can/m_can.h
> @@ -57,19 +57,19 @@ struct mram_cfg {
>   u8  num;
>  };
>  
> -struct m_can_priv;
> +struct m_can_classdev;
>  struct m_can_ops {
>   /* Device specific call backs */
> - int (*clear_interrupts)(struct m_can_priv *m_can_class);
> - u32 (*read_reg)(struct m_can_priv *m_can_class, int reg);
> - int (*write_reg)(struct m_can_priv *m_can_class, int reg, int val);
> - u32 (*read_fifo)(struct m_can_priv *m_can_class, int addr_offset);
> - int (*write_fifo)(struct m_can_priv *m_can_class, int addr_offset,
> + int (*clear_interrupts)(struct m_can_classdev *m_can_class);
> + u32 (*read_reg)(struct m_can_classdev *m_can_class, int reg);
> + int (*write_reg)(struct m_can_classdev *m_can_class, int reg, int val);
> + u32 (*read_fifo)(struct m_can_classdev *m_can_class, int addr_offset);
> + int (*write_fifo)(struct m_can_classdev *m_can_class, int addr_offset,

Could you please replace the variable name "m_can_class" with "cdev"
here and below and in "c_can_platform.c " and "tcan4x5x.c" as well.

Thanks,

Wolfgang.

Re: [PATCH v7 1/4] can: m_can: Create a m_can platform framework

Hallo Dan,

Am 05.03.19 um 16:52 schrieb Dan Murphy:
> Create a m_can platform framework that peripherial
> devices can register to and use common code and register sets.
> The peripherial devices may provide read/write and configuration
> support of the IP.
> 
> Signed-off-by: Dan Murphy 
> ---
> 
> 
> v7 - Fixed remaining new checkpatch issues, removed CSR setting, fixed tx hard
> start function to return tx_busy, and renamed device callbacks - 
> https://lore.kernel.org/patchwork/patch/1047220/
> 
> v6 - Squashed platform patch to this patch for bissectablity, fixed coding 
> style
> issues, updated Kconfig help, placed mcan reg offsets back into c file, 
> renamed
> priv->skb to priv->tx_skb and cleared perp interrupts at ISR start -
> Patch 1 comments - https://lore.kernel.org/patchwork/patch/1042446/
> Patch 2 comments - https://lore.kernel.org/patchwork/patch/1042442/
> 
>  drivers/net/can/m_can/Kconfig  |  13 +-
>  drivers/net/can/m_can/Makefile |   1 +
>  drivers/net/can/m_can/m_can.c  | 700 +
>  drivers/net/can/m_can/m_can.h  | 110 
>  drivers/net/can/m_can/m_can_platform.c | 202 +++
>  5 files changed, 682 insertions(+), 344 deletions(-)
>  create mode 100644 drivers/net/can/m_can/m_can.h
>  create mode 100644 drivers/net/can/m_can/m_can_platform.c
> 
> diff --git a/drivers/net/can/m_can/Kconfig b/drivers/net/can/m_can/Kconfig
> index 04f20dd39007..f7119fd72df4 100644
> --- a/drivers/net/can/m_can/Kconfig
> +++ b/drivers/net/can/m_can/Kconfig
> @@ -1,5 +1,14 @@
>  config CAN_M_CAN
> + tristate "Bosch M_CAN support"
> + ---help---
> +   Say Y here if you want support for Bosch M_CAN controller framework.
> +   This is common support for devices that embed the Bosch M_CAN IP.
> +
> +config CAN_M_CAN_PLATFORM
> + tristate "Bosch M_CAN support for io-mapped devices"
>   depends on HAS_IOMEM
> - tristate "Bosch M_CAN devices"
> + depends on CAN_M_CAN
>   ---help---
> -   Say Y here if you want to support for Bosch M_CAN controller.
> +   Say Y here if you want support for IO Mapped Bosch M_CAN controller.
> +   This support is for devices that have the Bosch M_CAN controller
> +   IP embedded into the device and the IP is IO Mapped to the processor.
> diff --git a/drivers/net/can/m_can/Makefile b/drivers/net/can/m_can/Makefile
> index 8bbd7f24f5be..057bbcdb3c74 100644
> --- a/drivers/net/can/m_can/Makefile
> +++ b/drivers/net/can/m_can/Makefile
> @@ -3,3 +3,4 @@
>  #
>  
>  obj-$(CONFIG_CAN_M_CAN) += m_can.o
> +obj-$(CONFIG_CAN_M_CAN_PLATFORM) += m_can_platform.o
> diff --git a/drivers/net/can/m_can/m_can.c b/drivers/net/can/m_can/m_can.c
> index 9b449400376b..a60278d94126 100644
> --- a/drivers/net/can/m_can/m_can.c
> +++ b/drivers/net/can/m_can/m_can.c

... snip...

> +static netdev_tx_t m_can_start_xmit(struct sk_buff *skb,
> + struct net_device *dev)
> +{
> + struct m_can_priv *priv = netdev_priv(dev);
> +
> + if (can_dropped_invalid_skb(dev, skb))
> + return NETDEV_TX_OK;
> +
> + if (priv->is_peripherial) {
> + if (priv->tx_skb) {
> + netdev_err(dev, "hard_xmit called while tx busy\n");
> + return NETDEV_TX_BUSY;
> + }

The problem with that approach is, that the upper layer will try to
resubmit the current "skb" but not the previous "tx_skb". And the
previous "tx_skb" has not been freed yet. I would just drop and free the
skb and return NETDEV_TX_OK in m_can_tx_handler() for peripheral devices
(like can_dropped_invalid_skb() does).

> +
> + priv->tx_skb = skb;
> + netif_stop_queue(priv->net);
> + queue_work(priv->tx_wq, >tx_work);
> + } else {
> + priv->tx_skb = skb;
> + return m_can_tx_handler(priv);
>   }
>  
>   return NETDEV_TX_OK;
>  }

Wolfgang.

Re: [PATCH v6 4/4] can: tcan4x5x: Add tcan4x5x driver to the kernel

Hello Dan,

Am 04.03.19 um 20:07 schrieb Dan Murphy:
> Wolfgang
> 
> On 3/4/19 12:29 PM, Wolfgang Grandegger wrote:
>> Hello Dan,
>>
>> Am 01.03.19 um 19:50 schrieb Dan Murphy:
>>> Add the TCAN4x5x SPI CAN driver.  This device uses the
>>> Bosch MCAN IP core along with a SPI interface map.
>>> Register to the MCAN common core code to manage the MCAN IP.
>>>
>>> This device has a special method to indicate a write/read
>>> operation on the data payload.
>>>
>>> Signed-off-by: Dan Murphy 
>>> ---
>>>
>>> v6 - Updated Kconfig help and added REGMAP_SPI dependency, fixed coding 
>>> style issues,
>>> removed setting GPIO high in wake routine, change -EIO to return ret in 
>>> init and
>>> setup functions - https://lore.kernel.org/patchwork/patch/1042443/
>>>
>>>  drivers/net/can/m_can/Kconfig|   9 +
>>>  drivers/net/can/m_can/Makefile   |   1 +
>>>  drivers/net/can/m_can/tcan4x5x.c | 529 +++
>>>  3 files changed, 539 insertions(+)
>>>  create mode 100644 drivers/net/can/m_can/tcan4x5x.c
>>>
>>> diff --git a/drivers/net/can/m_can/Kconfig b/drivers/net/can/m_can/Kconfig
>>> index f7119fd72df4..cf4f32765efa 100644
>>> --- a/drivers/net/can/m_can/Kconfig
>>> +++ b/drivers/net/can/m_can/Kconfig
>>> @@ -12,3 +12,12 @@ config CAN_M_CAN_PLATFORM
>>>   Say Y here if you want support for IO Mapped Bosch M_CAN controller.
>>>   This support is for devices that have the Bosch M_CAN controller
>>>   IP embedded into the device and the IP is IO Mapped to the processor.
>>> +
>>> +config CAN_M_CAN_TCAN4X5X
>>> +   depends on CAN_M_CAN
>>> +   depends on REGMAP_SPI
>>> +   tristate "TCAN4X5X M_CAN device"
>>> +   ---help---
>>> + Say Y here if you want support for Texas Instruments TCAN4x5x
>>> + M_CAN controller.  This device is a peripherial device that uses the
>>> + SPI bus for communication.
>>> diff --git a/drivers/net/can/m_can/Makefile b/drivers/net/can/m_can/Makefile
>>> index 057bbcdb3c74..e77f0eccff97 100644
>>> --- a/drivers/net/can/m_can/Makefile
>>> +++ b/drivers/net/can/m_can/Makefile
>>> @@ -4,3 +4,4 @@
>>>  
>>>  obj-$(CONFIG_CAN_M_CAN) += m_can.o
>>>  obj-$(CONFIG_CAN_M_CAN_PLATFORM) += m_can_platform.o
>>> +obj-$(CONFIG_CAN_M_CAN_TCAN4X5X) += tcan4x5x.o
>>> diff --git a/drivers/net/can/m_can/tcan4x5x.c 
>>> b/drivers/net/can/m_can/tcan4x5x.c
>>> new file mode 100644
>>> index ..a91b976bb522
>>> --- /dev/null
>>> +++ b/drivers/net/can/m_can/tcan4x5x.c
>>> @@ -0,0 +1,529 @@
>>> +// SPDX-License-Identifier: GPL-2.0
>>> +// SPI to CAN driver for the Texas Instruments TCAN4x5x
>>> +// Copyright (C) 2018-19 Texas Instruments Incorporated - 
>>> http://www.ti.com/
>>> +
>>> +#include 
>>> +#include 
>>> +
>>> +#include 
>>> +#include 
>>> +
>>> +#include "m_can.h"
>>> +
>>> +#define DEVICE_NAME "tcan4x5x"
>>> +#define TCAN4X5X_EXT_CLK_DEF   4000
>>> +
>>> +#define TCAN4X5X_DEV_ID0   0x00
>>> +#define TCAN4X5X_DEV_ID1   0x04
>>> +#define TCAN4X5X_REV   0x08
>>> +#define TCAN4X5X_STATUS0x0C
>>> +#define TCAN4X5X_ERROR_STATUS  0x10
>>> +#define TCAN4X5X_CONTROL   0x14
>>> +
>>> +#define TCAN4X5X_CONFIG0x800
>>> +#define TCAN4X5X_TS_PRESCALE   0x804
>>> +#define TCAN4X5X_TEST_REG  0x808
>>> +#define TCAN4X5X_INT_FLAGS 0x820
>>> +#define TCAN4X5X_MCAN_INT_REG  0x824
>>> +#define TCAN4X5X_INT_EN0x830
>>> +
>>> +/* Interrupt bits */
>>> +#define TCAN4X5X_CANBUSTERMOPEN_INT_EN BIT(30)
>>> +#define TCAN4X5X_CANHCANL_INT_EN   BIT(29)
>>> +#define TCAN4X5X_CANHBAT_INT_ENBIT(28)
>>> +#define TCAN4X5X_CANLGND_INT_ENBIT(27)
>>> +#define TCAN4X5X_CANBUSOPEN_INT_EN BIT(26)
>>> +#define TCAN4X5X_CANBUSGND_INT_EN  BIT(25)
>>> +#define TCAN4X5X_CANBUSBAT_INT_EN  BIT(24)
>>> +#define TCAN4X5X_UVSUP_INT_EN  BIT(22)
>>> +#define TCAN4X5X_UVIO_INT_EN   BIT(21)
>>> +#define TCAN4X5X_TSD_INT_ENBIT(19)
>>> +#define TCAN4X5X_ECCERR_INT_EN BIT(16)
>>> +#define TCAN4X5X_CANINT_INT_EN BIT(15)
&

Re: [PATCH v6 4/4] can: tcan4x5x: Add tcan4x5x driver to the kernel

Hello Dan,

Am 01.03.19 um 19:50 schrieb Dan Murphy:
> Add the TCAN4x5x SPI CAN driver.  This device uses the
> Bosch MCAN IP core along with a SPI interface map.
> Register to the MCAN common core code to manage the MCAN IP.
> 
> This device has a special method to indicate a write/read
> operation on the data payload.
> 
> Signed-off-by: Dan Murphy 
> ---
> 
> v6 - Updated Kconfig help and added REGMAP_SPI dependency, fixed coding style 
> issues,
> removed setting GPIO high in wake routine, change -EIO to return ret in init 
> and
> setup functions - https://lore.kernel.org/patchwork/patch/1042443/
> 
>  drivers/net/can/m_can/Kconfig|   9 +
>  drivers/net/can/m_can/Makefile   |   1 +
>  drivers/net/can/m_can/tcan4x5x.c | 529 +++
>  3 files changed, 539 insertions(+)
>  create mode 100644 drivers/net/can/m_can/tcan4x5x.c
> 
> diff --git a/drivers/net/can/m_can/Kconfig b/drivers/net/can/m_can/Kconfig
> index f7119fd72df4..cf4f32765efa 100644
> --- a/drivers/net/can/m_can/Kconfig
> +++ b/drivers/net/can/m_can/Kconfig
> @@ -12,3 +12,12 @@ config CAN_M_CAN_PLATFORM
> Say Y here if you want support for IO Mapped Bosch M_CAN controller.
> This support is for devices that have the Bosch M_CAN controller
> IP embedded into the device and the IP is IO Mapped to the processor.
> +
> +config CAN_M_CAN_TCAN4X5X
> + depends on CAN_M_CAN
> + depends on REGMAP_SPI
> + tristate "TCAN4X5X M_CAN device"
> + ---help---
> +   Say Y here if you want support for Texas Instruments TCAN4x5x
> +   M_CAN controller.  This device is a peripherial device that uses the
> +   SPI bus for communication.
> diff --git a/drivers/net/can/m_can/Makefile b/drivers/net/can/m_can/Makefile
> index 057bbcdb3c74..e77f0eccff97 100644
> --- a/drivers/net/can/m_can/Makefile
> +++ b/drivers/net/can/m_can/Makefile
> @@ -4,3 +4,4 @@
>  
>  obj-$(CONFIG_CAN_M_CAN) += m_can.o
>  obj-$(CONFIG_CAN_M_CAN_PLATFORM) += m_can_platform.o
> +obj-$(CONFIG_CAN_M_CAN_TCAN4X5X) += tcan4x5x.o
> diff --git a/drivers/net/can/m_can/tcan4x5x.c 
> b/drivers/net/can/m_can/tcan4x5x.c
> new file mode 100644
> index ..a91b976bb522
> --- /dev/null
> +++ b/drivers/net/can/m_can/tcan4x5x.c
> @@ -0,0 +1,529 @@
> +// SPDX-License-Identifier: GPL-2.0
> +// SPI to CAN driver for the Texas Instruments TCAN4x5x
> +// Copyright (C) 2018-19 Texas Instruments Incorporated - http://www.ti.com/
> +
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +
> +#include "m_can.h"
> +
> +#define DEVICE_NAME "tcan4x5x"
> +#define TCAN4X5X_EXT_CLK_DEF 4000
> +
> +#define TCAN4X5X_DEV_ID0 0x00
> +#define TCAN4X5X_DEV_ID1 0x04
> +#define TCAN4X5X_REV 0x08
> +#define TCAN4X5X_STATUS  0x0C
> +#define TCAN4X5X_ERROR_STATUS0x10
> +#define TCAN4X5X_CONTROL 0x14
> +
> +#define TCAN4X5X_CONFIG  0x800
> +#define TCAN4X5X_TS_PRESCALE 0x804
> +#define TCAN4X5X_TEST_REG0x808
> +#define TCAN4X5X_INT_FLAGS   0x820
> +#define TCAN4X5X_MCAN_INT_REG0x824
> +#define TCAN4X5X_INT_EN  0x830
> +
> +/* Interrupt bits */
> +#define TCAN4X5X_CANBUSTERMOPEN_INT_EN   BIT(30)
> +#define TCAN4X5X_CANHCANL_INT_EN BIT(29)
> +#define TCAN4X5X_CANHBAT_INT_EN  BIT(28)
> +#define TCAN4X5X_CANLGND_INT_EN  BIT(27)
> +#define TCAN4X5X_CANBUSOPEN_INT_EN   BIT(26)
> +#define TCAN4X5X_CANBUSGND_INT_ENBIT(25)
> +#define TCAN4X5X_CANBUSBAT_INT_ENBIT(24)
> +#define TCAN4X5X_UVSUP_INT_ENBIT(22)
> +#define TCAN4X5X_UVIO_INT_EN BIT(21)
> +#define TCAN4X5X_TSD_INT_EN  BIT(19)
> +#define TCAN4X5X_ECCERR_INT_EN   BIT(16)
> +#define TCAN4X5X_CANINT_INT_EN   BIT(15)
> +#define TCAN4X5X_LWU_INT_EN  BIT(14)
> +#define TCAN4X5X_CANSLNT_INT_EN  BIT(10)
> +#define TCAN4X5X_CANDOM_INT_EN   BIT(8)
> +#define TCAN4X5X_CANBUS_ERR_INT_EN   BIT(5)
> +#define TCAN4X5X_BUS_FAULT   BIT(4)
> +#define TCAN4X5X_MCAN_INTBIT(1)
> +#define TCAN4X5X_ENABLE_TCAN_INT (TCAN4X5X_MCAN_INT | \
> + TCAN4X5X_BUS_FAULT | \
> + TCAN4X5X_CANBUS_ERR_INT_EN | \
> + TCAN4X5X_CANINT_INT_EN)
> +
> +/* MCAN Interrupt bits */
> +#define TCAN4X5X_MCAN_IR_ARA BIT(29)
> +#define TCAN4X5X_MCAN_IR_PED BIT(28)
> +#define TCAN4X5X_MCAN_IR_PEA BIT(27)
> +#define TCAN4X5X_MCAN_IR_WD  BIT(26)
> +#define TCAN4X5X_MCAN_IR_BO  BIT(25)
> +#define TCAN4X5X_MCAN_IR_EW  BIT(24)
> +#define TCAN4X5X_MCAN_IR_EP  BIT(23)
> +#define TCAN4X5X_MCAN_IR_ELO BIT(22)
> +#define TCAN4X5X_MCAN_IR_BEU BIT(21)
> +#define TCAN4X5X_MCAN_IR_BEC BIT(20)
> +#define TCAN4X5X_MCAN_IR_DRX BIT(19)
> +#define TCAN4X5X_MCAN_IR_TOO BIT(18)
> +#define TCAN4X5X_MCAN_IR_MRAFBIT(17)
>

Re: [PATCH v6 2/4] can: m_can: Rename m_can_priv to m_can_classdev




Am 04.03.19 um 19:14 schrieb Dan Murphy:
> Wolfgang
> 
> On 3/4/19 11:31 AM, Wolfgang Grandegger wrote:
>> Hello,
>>
>> there are still "LTL" after renaming m_can_priv to m_can_classdev.
>>
> 
> Yes I know but some of those become unreadable if I break them apart.
> 
> But if you want me to break them I can do it.
> 
> For instance
>   struct m_can_plat_priv *priv = (struct m_can_plat_priv 
> *)m_can_class->device_data;
> 
> will become
> 
>   struct m_can_plat_priv *priv =
>   (struct m_can_plat_priv 
> *)m_can_class->device_data;

Perfect! See also my comment below.

> 
>> Am 01.03.19 um 19:50 schrieb Dan Murphy:
>>> Rename the common m_can_priv class structure to
>>> m_can_classdev as this is more descriptive.
>>
>> If you change the struct name, I think you should also change the
>> variable name to something more meaning full e.g.:
>>
>>   struct m_can_classdev *cdev
>>
>> instead of
>>
>>   struct m_can_classdev *priv
>>
>>
> 
> Ack.  This change will grow this patch as s/priv/cdev is used 250x

That's the price for changing the name. As we have it in a separate
patch, it should be OK.

Ideally, also m_can_platform.c and tcan4x5x.c should then use that name
for "struct m_can_classdev".

Wolfgang.

Re: [PATCH v6 1/4] can: m_can: Create a m_can platform framework




Am 04.03.19 um 18:22 schrieb Dan Murphy:
> Wolfgang
> 
> On 3/4/19 10:56 AM, Wolfgang Grandegger wrote:
>> Hello Dan,
>>
>> the series already looks quite good. I still realized a few (minor)
>> issues while browsing the patch/code...
>>
> 
> Thanks for the review.  It is getting there.
> 
>> Am 01.03.19 um 19:50 schrieb Dan Murphy:
>>> Create a m_can platform framework that peripherial
>>> devices can register to and use common code and register sets.
>>> The peripherial devices may provide read/write and configuration
>>> support of the IP.
>>>
>>> Signed-off-by: Dan Murphy 
>>> ---
>>>
>>> v6 - Squashed platform patch to this patch for bissectablity, fixed coding 
>>> style
>>> issues, updated Kconfig help, placed mcan reg offsets back into c file, 
>>> renamed
>>> priv->skb to priv->tx_skb and cleared perp interrupts at ISR start -
>>> Patch 1 comments - https://lore.kernel.org/patchwork/patch/1042446/
>>> Patch 2 comments - https://lore.kernel.org/patchwork/patch/1042442/
>>>
>>>  drivers/net/can/m_can/Kconfig  |  13 +-
>>>  drivers/net/can/m_can/Makefile |   1 +
>>>  drivers/net/can/m_can/m_can.c  | 702 +
>>>  drivers/net/can/m_can/m_can.h  | 110 
>>>  drivers/net/can/m_can/m_can_platform.c | 198 +++
>>>  5 files changed, 681 insertions(+), 343 deletions(-)
>>>  create mode 100644 drivers/net/can/m_can/m_can.h
>>>  create mode 100644 drivers/net/can/m_can/m_can_platform.c
>>>
>>> diff --git a/drivers/net/can/m_can/Kconfig b/drivers/net/can/m_can/Kconfig
>>> index 04f20dd39007..f7119fd72df4 100644
>>> --- a/drivers/net/can/m_can/Kconfig
>>> +++ b/drivers/net/can/m_can/Kconfig
>>> @@ -1,5 +1,14 @@
>>>  config CAN_M_CAN
>>> +   tristate "Bosch M_CAN support"
>>> +   ---help---
>>> + Say Y here if you want support for Bosch M_CAN controller framework.
>>> + This is common support for devices that embed the Bosch M_CAN IP.
>>> +
>>> +config CAN_M_CAN_PLATFORM
>>> +   tristate "Bosch M_CAN support for io-mapped devices"
>>> depends on HAS_IOMEM
>>> -   tristate "Bosch M_CAN devices"
>>> +   depends on CAN_M_CAN
>>> ---help---
>>> - Say Y here if you want to support for Bosch M_CAN controller.
>>> + Say Y here if you want support for IO Mapped Bosch M_CAN controller.
>>> + This support is for devices that have the Bosch M_CAN controller
>>> + IP embedded into the device and the IP is IO Mapped to the processor.
>>> diff --git a/drivers/net/can/m_can/Makefile b/drivers/net/can/m_can/Makefile
>>> index 8bbd7f24f5be..057bbcdb3c74 100644
>>> --- a/drivers/net/can/m_can/Makefile
>>> +++ b/drivers/net/can/m_can/Makefile
>>> @@ -3,3 +3,4 @@
>>>  #
>>>  
>>>  obj-$(CONFIG_CAN_M_CAN) += m_can.o
>>> +obj-$(CONFIG_CAN_M_CAN_PLATFORM) += m_can_platform.o
>>> diff --git a/drivers/net/can/m_can/m_can.c b/drivers/net/can/m_can/m_can.c
>>> index 9b449400376b..b37d0886f9cb 100644
>>> --- a/drivers/net/can/m_can/m_can.c
>>> +++ b/drivers/net/can/m_can/m_can.c

...snip...

>>> @@ -1451,7 +1459,7 @@ static netdev_tx_t m_can_start_xmit(struct sk_buff 
>>> *skb,
>>> netif_stop_queue(dev);
>>> netdev_warn(dev,
>>> "TX queue active although FIFO is full.");
>>> -   return NETDEV_TX_BUSY;
>>> +   return;
>>
>> m_can_start_xmit() doesn't return NETDEV_TX_BUSY but NETDEV_TX_OK and
>> the queue is stopped! Also the skb is not freed! The code states 
>> "/* This shouldn't happen */" but then it just prints a warning. Did
>> you see that message?
>>
> 
> No I have not seen this warning but I will re-check to be sure.

If we don't return NETDEV_TX_BUSY but NETDEV_TX_OK, we must handle it
differently.

...snip...

>>> +struct m_can_priv;
>>> +struct m_can_ops {
>>> +   /* Device specific call backs */
>>> +   int (*clr_dev_interrupts)(struct m_can_priv *m_can_class);
>>
>> Why not just "clear_interrupt"... to be consistant with the names below.
> 
> I wanted to be clear in the M_CAN code that these are device interrupts and 
> not M_CAN interrupts.
> 
> I can change it to clear_interrupt if you think it makes more sense.

Well, li

Re: [PATCH v6 2/4] can: m_can: Rename m_can_priv to m_can_classdev

Hello,

there are still "LTL" after renaming m_can_priv to m_can_classdev.

Am 01.03.19 um 19:50 schrieb Dan Murphy:
> Rename the common m_can_priv class structure to
> m_can_classdev as this is more descriptive.

If you change the struct name, I think you should also change the
variable name to something more meaning full e.g.:

  struct m_can_classdev *cdev

instead of

  struct m_can_classdev *priv


... snip ...

Wolfgang.

Re: [PATCH v6 1/4] can: m_can: Create a m_can platform framework

Hello Dan,

the series already looks quite good. I still realized a few (minor)
issues while browsing the patch/code...

Am 01.03.19 um 19:50 schrieb Dan Murphy:
> Create a m_can platform framework that peripherial
> devices can register to and use common code and register sets.
> The peripherial devices may provide read/write and configuration
> support of the IP.
> 
> Signed-off-by: Dan Murphy 
> ---
> 
> v6 - Squashed platform patch to this patch for bissectablity, fixed coding 
> style
> issues, updated Kconfig help, placed mcan reg offsets back into c file, 
> renamed
> priv->skb to priv->tx_skb and cleared perp interrupts at ISR start -
> Patch 1 comments - https://lore.kernel.org/patchwork/patch/1042446/
> Patch 2 comments - https://lore.kernel.org/patchwork/patch/1042442/
> 
>  drivers/net/can/m_can/Kconfig  |  13 +-
>  drivers/net/can/m_can/Makefile |   1 +
>  drivers/net/can/m_can/m_can.c  | 702 +
>  drivers/net/can/m_can/m_can.h  | 110 
>  drivers/net/can/m_can/m_can_platform.c | 198 +++
>  5 files changed, 681 insertions(+), 343 deletions(-)
>  create mode 100644 drivers/net/can/m_can/m_can.h
>  create mode 100644 drivers/net/can/m_can/m_can_platform.c
> 
> diff --git a/drivers/net/can/m_can/Kconfig b/drivers/net/can/m_can/Kconfig
> index 04f20dd39007..f7119fd72df4 100644
> --- a/drivers/net/can/m_can/Kconfig
> +++ b/drivers/net/can/m_can/Kconfig
> @@ -1,5 +1,14 @@
>  config CAN_M_CAN
> + tristate "Bosch M_CAN support"
> + ---help---
> +   Say Y here if you want support for Bosch M_CAN controller framework.
> +   This is common support for devices that embed the Bosch M_CAN IP.
> +
> +config CAN_M_CAN_PLATFORM
> + tristate "Bosch M_CAN support for io-mapped devices"
>   depends on HAS_IOMEM
> - tristate "Bosch M_CAN devices"
> + depends on CAN_M_CAN
>   ---help---
> -   Say Y here if you want to support for Bosch M_CAN controller.
> +   Say Y here if you want support for IO Mapped Bosch M_CAN controller.
> +   This support is for devices that have the Bosch M_CAN controller
> +   IP embedded into the device and the IP is IO Mapped to the processor.
> diff --git a/drivers/net/can/m_can/Makefile b/drivers/net/can/m_can/Makefile
> index 8bbd7f24f5be..057bbcdb3c74 100644
> --- a/drivers/net/can/m_can/Makefile
> +++ b/drivers/net/can/m_can/Makefile
> @@ -3,3 +3,4 @@
>  #
>  
>  obj-$(CONFIG_CAN_M_CAN) += m_can.o
> +obj-$(CONFIG_CAN_M_CAN_PLATFORM) += m_can_platform.o
> diff --git a/drivers/net/can/m_can/m_can.c b/drivers/net/can/m_can/m_can.c
> index 9b449400376b..b37d0886f9cb 100644
> --- a/drivers/net/can/m_can/m_can.c
> +++ b/drivers/net/can/m_can/m_can.c
> @@ -1,20 +1,14 @@
> -/*
> - * CAN bus driver for Bosch M_CAN controller
> - *
> - * Copyright (C) 2014 Freescale Semiconductor, Inc.
> - *   Dong Aisheng 
> - *
> - * Bosch M_CAN user manual can be obtained from:
> +// SPDX-License-Identifier: GPL-2.0
> +// CAN bus driver for Bosch M_CAN controller
> +// Copyright (C) 2014 Freescale Semiconductor, Inc.
> +//  Dong Aisheng 
> +// Copyright (C) 2018-19 Texas Instruments Incorporated - http://www.ti.com/
> +
> +/* Bosch M_CAN user manual can be obtained from:
>   * http://www.bosch-semiconductors.de/media/pdf_1/ipmodules_1/m_can/
>   * mcan_users_manual_v302.pdf
> - *
> - * This file is licensed under the terms of the GNU General Public
> - * License version 2. This program is licensed "as is" without any
> - * warranty of any kind, whether express or implied.
>   */
>  
> -#include 
> -#include 
>  #include 
>  #include 
>  #include 
> @@ -28,11 +22,7 @@
>  #include 
>  #include 
>  
> -/* napi related */
> -#define M_CAN_NAPI_WEIGHT64
> -
> -/* message ram configuration data length */
> -#define MRAM_CFG_LEN 8
> +#include "m_can.h"
>  
>  /* registers definition */
>  enum m_can_reg {
> @@ -86,28 +76,11 @@ enum m_can_reg {
>   M_CAN_TXEFA = 0xf8,
>  };
>  
> -/* m_can lec values */
> -enum m_can_lec_type {
> - LEC_NO_ERROR = 0,
> - LEC_STUFF_ERROR,
> - LEC_FORM_ERROR,
> - LEC_ACK_ERROR,
> - LEC_BIT1_ERROR,
> - LEC_BIT0_ERROR,
> - LEC_CRC_ERROR,
> - LEC_UNUSED,
> -};
> +/* napi related */
> +#define M_CAN_NAPI_WEIGHT64
>  
> -enum m_can_mram_cfg {
> - MRAM_SIDF = 0,
> - MRAM_XIDF,
> - MRAM_RXF0,
> - MRAM_RXF1,
> - MRAM_RXB,
> - MRAM_TXE,
> - MRAM_TXB,
> - MRAM_CFG_NUM,
> -};
> +/* message ram configuration data length */
> +#define MRAM_CFG_LEN 8
>  
>  /* Core Release Register (CREL) */
>  #define CREL_REL_SHIFT   28
> @@ -343,77 +316,83 @@ enum m_can_mram_cfg {
>  #define TX_BUF_MM_MASK   (0xff << TX_BUF_MM_SHIFT)
>  
>  /* Tx event FIFO Element */
> -/* E1 */

I also don't understand what "E1" means... we should keep taht line anyway!

>  #define TX_EVENT_MM_SHIFTTX_BUF_MM_SHIFT
>  #define TX_EVENT_MM_MASK (0xff << TX_EVENT_MM_SHIFT)
>  
> -/* address offset and

Re: [PATCH v5 1/5] can: m_can: Create a m_can platform framework



Am 14.02.19 um 19:27 schrieb Dan Murphy:
> Create a m_can platform framework that peripherial
> devices can register to and use common code and register sets.
> The peripherial devices may provide read/write and configuration> support of 
> the IP.
> 
> Signed-off-by: Dan Murphy 
> ---
> 
> v5 - Created ops struct, renamed header to m_can.h, updated license and 
> copyright
> added MODULE_AUTHOR and removed unneeded changes - 
> https://lore.kernel.org/patchwork/patch/1033094/
> 
>  drivers/net/can/m_can/m_can.h  | 159 
>  drivers/net/can/m_can/m_can_platform.c | 198 +
>  2 files changed, 357 insertions(+)
>  create mode 100644 drivers/net/can/m_can/m_can.h
>  create mode 100644 drivers/net/can/m_can/m_can_platform.c
> 
> diff --git a/drivers/net/can/m_can/m_can.h b/drivers/net/can/m_can/m_can.h
> new file mode 100644
> index ..36b1b833d41b
> --- /dev/null
> +++ b/drivers/net/can/m_can/m_can.h
> @@ -0,0 +1,159 @@
> +// SPDX-License-Identifier: GPL-2.0
> +// Copyright (C) 2018 Texas Instruments Incorporated - http://www.ti.com/
> +
> +#ifndef _CAN_M_CAN_H_
> +#define _CAN_M_CAN_H_
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* m_can lec values */
> +enum m_can_lec_type {
> + LEC_NO_ERROR = 0,
> + LEC_STUFF_ERROR,
> + LEC_FORM_ERROR,
> + LEC_ACK_ERROR,
> + LEC_BIT1_ERROR,
> + LEC_BIT0_ERROR,
> + LEC_CRC_ERROR,
> + LEC_UNUSED,
> +};
> +
> +enum m_can_mram_cfg {
> + MRAM_SIDF = 0,
> + MRAM_XIDF,
> + MRAM_RXF0,
> + MRAM_RXF1,
> + MRAM_RXB,
> + MRAM_TXE,
> + MRAM_TXB,
> + MRAM_CFG_NUM,
> +};
> +
> +/* registers definition */
> +enum m_can_reg {
> + M_CAN_CREL  = 0x0,
> + M_CAN_ENDN  = 0x4,
> + M_CAN_CUST  = 0x8,
> + M_CAN_DBTP  = 0xc,
> + M_CAN_TEST  = 0x10,
> + M_CAN_RWD   = 0x14,
> + M_CAN_CCCR  = 0x18,
> + M_CAN_NBTP  = 0x1c,
> + M_CAN_TSCC  = 0x20,
> + M_CAN_TSCV  = 0x24,
> + M_CAN_TOCC  = 0x28,
> + M_CAN_TOCV  = 0x2c,
> + M_CAN_ECR   = 0x40,
> + M_CAN_PSR   = 0x44,
> +/* TDCR Register only available for version >=3.1.x */
> + M_CAN_TDCR  = 0x48,
> + M_CAN_IR= 0x50,
> + M_CAN_IE= 0x54,
> + M_CAN_ILS   = 0x58,
> + M_CAN_ILE   = 0x5c,
> + M_CAN_GFC   = 0x80,
> + M_CAN_SIDFC = 0x84,
> + M_CAN_XIDFC = 0x88,
> + M_CAN_XIDAM = 0x90,
> + M_CAN_HPMS  = 0x94,
> + M_CAN_NDAT1 = 0x98,
> + M_CAN_NDAT2 = 0x9c,
> + M_CAN_RXF0C = 0xa0,
> + M_CAN_RXF0S = 0xa4,
> + M_CAN_RXF0A = 0xa8,
> + M_CAN_RXBC  = 0xac,
> + M_CAN_RXF1C = 0xb0,
> + M_CAN_RXF1S = 0xb4,
> + M_CAN_RXF1A = 0xb8,
> + M_CAN_RXESC = 0xbc,
> + M_CAN_TXBC  = 0xc0,
> + M_CAN_TXFQS = 0xc4,
> + M_CAN_TXESC = 0xc8,
> + M_CAN_TXBRP = 0xcc,
> + M_CAN_TXBAR = 0xd0,
> + M_CAN_TXBCR = 0xd4,
> + M_CAN_TXBTO = 0xd8,
> + M_CAN_TXBCF = 0xdc,
> + M_CAN_TXBTIE= 0xe0,
> + M_CAN_TXBCIE= 0xe4,
> + M_CAN_TXEFC = 0xf0,
> + M_CAN_TXEFS = 0xf4,
> + M_CAN_TXEFA = 0xf8,
> +};

You moved the register offsets here but not the register flags and
masks. Why?

> +/* address offset and element number for each FIFO/Buffer in the Message RAM 
> */
> +struct mram_cfg {
> + u16 off;
> + u8  num;
> +};
> +
> +struct m_can_priv;
> +struct m_can_ops {
> + /* Device specific call backs */
> + int (*clr_dev_interrupts) (struct m_can_priv *m_can_class);
> + u32 (*read_reg) (struct m_can_priv *m_can_class, int reg);
> + int (*write_reg) (struct m_can_priv *m_can_class, int reg, int val);
> + u32 (*read_fifo) (struct m_can_priv *m_can_class, int addr_offset);
> + int (*write_fifo) (struct m_can_priv *m_can_class, int addr_offset, int 
> val);
> + int (*device_init) (struct m_can_priv *m_can_class);
> +};
> +
> +struct m_can_priv {
> + struct can_priv can;
> + struct napi_struct napi;
> + struct net_device *net;
> + struct device *dev;
> + struct clk *hclk;
> + struct clk *cclk;
> +
> + struct workqueue_struct *wq;
> + struct work_struct tx_work;
> + struct sk_buff *skb;
> +
> + struct can_bittiming_const *bit_timing;
> + struct can_bittiming_const *data_timing;
> +
> + struct m_can_ops *ops;
> +
> + void *device_data;
> +
> + int version;
> + int freq;
> + u32 irqstatus;
> +
> + int pm_clock_support;
> + bool is_peripherial;
> +
> + struct mram_cfg mcfg[MRAM_CFG_NUM];
> +};
> +
> +struct m_can_priv *m_can_class_allocate_dev(struct device *dev);
> +int

Re: [PATCH v5 5/5] can: tcan4x5x: Add tcan4x5x driver to the kernel



Am 28.02.19 um 19:03 schrieb Dan Murphy:
> 
> Wolfgang
> 
> On 2/28/19 11:50 AM, Wolfgang Grandegger wrote:
>>
>>
>> Am 14.02.19 um 19:27 schrieb Dan Murphy:
>>> Add the TCAN4x5x SPI CAN driver.  This device
>>> uses the Bosch MCAN IP core along with a SPI
>>> interface map.  Leverage the MCAN common core
>>> code to manage the MCAN IP.
>>>
>>> This device has a special method to indicate a
>>> write/read operation on the data payload.
>>
>> Please expand the text to approx. 72 lines.>>
> 
> 72 lines or characters?

Characters, of course!

>>> Signed-off-by: Dan Murphy 
>>> ---
>>>
>>> v5 - Changes to accomodate previous patches for functionality - 
>>> https://lore.kernel.org/patchwork/patch/1033096/
>>>
>>>  drivers/net/can/m_can/Kconfig|   6 +
>>>  drivers/net/can/m_can/Makefile   |   1 +
>>>  drivers/net/can/m_can/tcan4x5x.c | 531 +++
>>>  3 files changed, 538 insertions(+)
>>>  create mode 100644 drivers/net/can/m_can/tcan4x5x.c
>>>
>>> diff --git a/drivers/net/can/m_can/Kconfig b/drivers/net/can/m_can/Kconfig
>>> index 66e31022a5fa..6c0ab4703fb7 100644
>>> --- a/drivers/net/can/m_can/Kconfig
>>> +++ b/drivers/net/can/m_can/Kconfig
>>> @@ -9,3 +9,9 @@ config CAN_M_CAN_PLATFORM
>>> depends on CAN_M_CAN
>>> ---help---
>>>   Say Y here if you want to support for Bosch M_CAN controller.
>>> +
>>> +config CAN_M_CAN_TCAN4X5X
>>> +   depends on CAN_M_CAN
>>> +   tristate "TCAN4X5X M_CAN device"
>>> +   ---help---
>>> + Say Y here if you want to support for TI M_CAN controller.
>>
>> Could yo please be a bit more verbose here.
> 
> ACK
> 
>>
>>> diff --git a/drivers/net/can/m_can/Makefile b/drivers/net/can/m_can/Makefile
>>> index 057bbcdb3c74..e77f0eccff97 100644
>>> --- a/drivers/net/can/m_can/Makefile
>>> +++ b/drivers/net/can/m_can/Makefile
>>> @@ -4,3 +4,4 @@
>>>  
>>>  obj-$(CONFIG_CAN_M_CAN) += m_can.o
>>>  obj-$(CONFIG_CAN_M_CAN_PLATFORM) += m_can_platform.o
>>> +obj-$(CONFIG_CAN_M_CAN_TCAN4X5X) += tcan4x5x.o
>>> diff --git a/drivers/net/can/m_can/tcan4x5x.c 
>>> b/drivers/net/can/m_can/tcan4x5x.c
>>> new file mode 100644
>>> index ..606cd1925009
>>> --- /dev/null
>>> +++ b/drivers/net/can/m_can/tcan4x5x.c
>>> @@ -0,0 +1,531 @@
>>> +// SPDX-License-Identifier: GPL-2.0
>>> +// SPI to CAN driver for the Texas Instruments TCAN4x5x
>>> +// Copyright (C) 2018-19 Texas Instruments Incorporated - 
>>> http://www.ti.com/
>>> +
>>> +#include 
>>> +#include 
>>> +
>>> +#include 
>>> +#include 
>>> +
>>> +#include "m_can.h"
>>> +
>>> +#define DEVICE_NAME "tcan4x5x"
>>> +#define TCAN4X5X_EXT_CLK_DEF   4000
>>> +
>>> +#define TCAN4X5X_DEV_ID0   0x00
>>> +#define TCAN4X5X_DEV_ID1   0x04
>>> +#define TCAN4X5X_REV   0x08
>>> +#define TCAN4X5X_STATUS0x0C
>>> +#define TCAN4X5X_ERROR_STATUS  0x10
>>> +#define TCAN4X5X_CONTROL   0x14
>>> +
>>> +#define TCAN4X5X_CONFIG0x800
>>> +#define TCAN4X5X_TS_PRESCALE   0x804
>>> +#define TCAN4X5X_TEST_REG  0x808
>>> +#define TCAN4X5X_INT_FLAGS 0x820
>>> +#define TCAN4X5X_MCAN_INT_REG  0x824
>>> +#define TCAN4X5X_INT_EN0x830
>>> +
>>> +
>>> +/* Interrupt bits */
>>> +#define TCAN4X5X_CANBUSTERMOPEN_INT_EN BIT(30)
>>> +#define TCAN4X5X_CANHCANL_INT_EN   BIT(29)
>>> +#define TCAN4X5X_CANHBAT_INT_ENBIT(28)
>>> +#define TCAN4X5X_CANLGND_INT_ENBIT(27)
>>> +#define TCAN4X5X_CANBUSOPEN_INT_EN BIT(26)
>>> +#define TCAN4X5X_CANBUSGND_INT_EN  BIT(25)
>>> +#define TCAN4X5X_CANBUSBAT_INT_EN  BIT(24)
>>> +#define TCAN4X5X_UVSUP_INT_EN  BIT(22)
>>> +#define TCAN4X5X_UVIO_INT_EN   BIT(21)
>>> +#define TCAN4X5X_TSD_INT_ENBIT(19)
>>> +#define TCAN4X5X_ECCERR_INT_EN BIT(16)
>>> +#define TCAN4X5X_CANINT_INT_EN BIT(15)
>>> +#define TCAN4X5X_LWU_INT_ENBIT(14)
>>> +#define TCAN4X5X_CANSLNT_INT_ENBIT(10)
>>> +#define TCAN4X5X_CANDOM_INT_EN BIT(8)
>>> +#define TCAN4X5X_CANBU

Re: [PATCH v5 2/5] can: m_can: Migrate the m_can code to use the framework

Hello Dan,

Am 28.02.19 um 18:57 schrieb Dan Murphy:
> Wolfgang
> 
> On 2/28/19 11:33 AM, Wolfgang Grandegger wrote:
>> Am 14.02.19 um 19:27 schrieb Dan Murphy:
>>> Migrate the m_can code to use the m_can_platform framework
>>> code.
>>>
>>> Signed-off-by: Dan Murphy 
>>> ---
>>>
>>> v5 - Updated copyright, change m_can_classdev to m_can_priv, removed extra
>>> KCONFIG flag - https://lore.kernel.org/patchwork/patch/1033095/
>>>
>>>  drivers/net/can/m_can/Kconfig  |   8 +-
>>>  drivers/net/can/m_can/Makefile |   1 +
>>>  drivers/net/can/m_can/m_can.c  | 745 -
>>>  3 files changed, 367 insertions(+), 387 deletions(-)
>>>
>>> diff --git a/drivers/net/can/m_can/Kconfig b/drivers/net/can/m_can/Kconfig
>>> index 04f20dd39007..66e31022a5fa 100644
>>> --- a/drivers/net/can/m_can/Kconfig
>>> +++ b/drivers/net/can/m_can/Kconfig
>>> @@ -1,5 +1,11 @@
>>>  config CAN_M_CAN
>>> +   tristate "Bosch M_CAN support"
>>> +   ---help---
>>> + Say Y here if you want to support for Bosch M_CAN controller.
>>
>> Typo?
>>
> 
> Maybe like you pointed out to update the help.

I was just not sure if it's correct English... but you know better!

> 
>>> +
>>> +config CAN_M_CAN_PLATFORM
>>> +   tristate "Bosch M_CAN support for io-mapped devices"
>>> depends on HAS_IOMEM
>>> -   tristate "Bosch M_CAN devices"
>>> +   depends on CAN_M_CAN
>>> ---help---
>>>   Say Y here if you want to support for Bosch M_CAN controller.
>>
>> Please update the help.
> 
> Ack
>>
>>> diff --git a/drivers/net/can/m_can/Makefile b/drivers/net/can/m_can/Makefile
>>> index 8bbd7f24f5be..057bbcdb3c74 100644
>>> --- a/drivers/net/can/m_can/Makefile
>>> +++ b/drivers/net/can/m_can/Makefile
>>> @@ -3,3 +3,4 @@
>>>  #
>>>  
>>>  obj-$(CONFIG_CAN_M_CAN) += m_can.o
>>> +obj-$(CONFIG_CAN_M_CAN_PLATFORM) += m_can_platform.o
>>> diff --git a/drivers/net/can/m_can/m_can.c b/drivers/net/can/m_can/m_can.c
>>> index 9b449400376b..2ceccb870557 100644
>>> --- a/drivers/net/can/m_can/m_can.c
>>> +++ b/drivers/net/can/m_can/m_can.c
... snip ...
>>> @@ -924,6 +885,9 @@ static irqreturn_t m_can_isr(int irq, void *dev_id)
>>> }
>>> }
>>>  
>>> +   if (priv->ops->clr_dev_interrupts)
>>> +   priv->ops->clr_dev_interrupts(priv);
>>
>> post_irq _handler?
>>
> 
> I can clear them on entry as well

OK!

...snip...

>>> -   niso_timeout = readl_poll_timeout((priv->base + M_CAN_CCCR), cccr_poll,
>>> - (cccr_poll == cccr_reg), 0, 10);
>>> +   for (i = 0; i <= 10; i++) {
>>> +   cccr_poll = m_can_read(priv, M_CAN_CCCR);
>>> +   if (cccr_poll == cccr_reg)
>>> +   niso_timeout = 0;
>>> +   }
>>
>> There is no break and delay in the loop? What was the reason why you
>> can't use readl_poll_timeout()?
>>
> 
> OK a break if NISO is supported then and probably could add a 1us delay 
> original code on
> line 1232 had no delay but timeout at 10us.
> 
> readl_poll_timeout is for iomapped devices.  How would this work for 
> peripherial devices?

Well, it takes much more time to read the register via SPI... maybe using

if (priv->is_peripherial) ...

to handle the different timings would make sense here.

>>>  
>>> /* Clear NISO */
>>> cccr_reg &= ~(CCCR_NISO);
>>> @@ -1242,107 +1210,95 @@ static bool m_can_niso_supported(const struct 
>>> m_can_priv *priv)
>>> return !niso_timeout;
>>>  }
... snip...

>>> -static netdev_tx_t m_can_start_xmit(struct sk_buff *skb,
>>> -   struct net_device *dev)
>>> +static void m_can_tx_handler(struct m_can_priv *priv)
>>>  {
>>> -   struct m_can_priv *priv = netdev_priv(dev);
>>> -   struct canfd_frame *cf = (struct canfd_frame *)skb->data;
>>> +   struct canfd_frame *cf = (struct canfd_frame *)priv->skb->data;
>>> +   struct net_device *dev = priv->net;
>>> +   struct sk_buff *skb = priv->skb;
>>
>> Maybe "tx_skb" is a clearer member name..
> 
> Again this was named skb to minimize deltas from original code.

I mean "priv->tx_skb"!

> skb was passed into the start_xmit function and used throughout the function.
> 
> Since there was little delta in this function I opt'd to keep the names as is.
> 

Wolfgang.

Re: [PATCH v5 5/5] can: tcan4x5x: Add tcan4x5x driver to the kernel




Am 14.02.19 um 19:27 schrieb Dan Murphy:
> Add the TCAN4x5x SPI CAN driver.  This device
> uses the Bosch MCAN IP core along with a SPI
> interface map.  Leverage the MCAN common core
> code to manage the MCAN IP.
> 
> This device has a special method to indicate a
> write/read operation on the data payload.

Please expand the text to approx. 72 lines.

> Signed-off-by: Dan Murphy 
> ---
> 
> v5 - Changes to accomodate previous patches for functionality - 
> https://lore.kernel.org/patchwork/patch/1033096/
> 
>  drivers/net/can/m_can/Kconfig|   6 +
>  drivers/net/can/m_can/Makefile   |   1 +
>  drivers/net/can/m_can/tcan4x5x.c | 531 +++
>  3 files changed, 538 insertions(+)
>  create mode 100644 drivers/net/can/m_can/tcan4x5x.c
> 
> diff --git a/drivers/net/can/m_can/Kconfig b/drivers/net/can/m_can/Kconfig
> index 66e31022a5fa..6c0ab4703fb7 100644
> --- a/drivers/net/can/m_can/Kconfig
> +++ b/drivers/net/can/m_can/Kconfig
> @@ -9,3 +9,9 @@ config CAN_M_CAN_PLATFORM
>   depends on CAN_M_CAN
>   ---help---
> Say Y here if you want to support for Bosch M_CAN controller.
> +
> +config CAN_M_CAN_TCAN4X5X
> + depends on CAN_M_CAN
> + tristate "TCAN4X5X M_CAN device"
> + ---help---
> +   Say Y here if you want to support for TI M_CAN controller.

Could yo please be a bit more verbose here.

> diff --git a/drivers/net/can/m_can/Makefile b/drivers/net/can/m_can/Makefile
> index 057bbcdb3c74..e77f0eccff97 100644
> --- a/drivers/net/can/m_can/Makefile
> +++ b/drivers/net/can/m_can/Makefile
> @@ -4,3 +4,4 @@
>  
>  obj-$(CONFIG_CAN_M_CAN) += m_can.o
>  obj-$(CONFIG_CAN_M_CAN_PLATFORM) += m_can_platform.o
> +obj-$(CONFIG_CAN_M_CAN_TCAN4X5X) += tcan4x5x.o
> diff --git a/drivers/net/can/m_can/tcan4x5x.c 
> b/drivers/net/can/m_can/tcan4x5x.c
> new file mode 100644
> index ..606cd1925009
> --- /dev/null
> +++ b/drivers/net/can/m_can/tcan4x5x.c
> @@ -0,0 +1,531 @@
> +// SPDX-License-Identifier: GPL-2.0
> +// SPI to CAN driver for the Texas Instruments TCAN4x5x
> +// Copyright (C) 2018-19 Texas Instruments Incorporated - http://www.ti.com/
> +
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +
> +#include "m_can.h"
> +
> +#define DEVICE_NAME "tcan4x5x"
> +#define TCAN4X5X_EXT_CLK_DEF 4000
> +
> +#define TCAN4X5X_DEV_ID0 0x00
> +#define TCAN4X5X_DEV_ID1 0x04
> +#define TCAN4X5X_REV 0x08
> +#define TCAN4X5X_STATUS  0x0C
> +#define TCAN4X5X_ERROR_STATUS0x10
> +#define TCAN4X5X_CONTROL 0x14
> +
> +#define TCAN4X5X_CONFIG  0x800
> +#define TCAN4X5X_TS_PRESCALE 0x804
> +#define TCAN4X5X_TEST_REG0x808
> +#define TCAN4X5X_INT_FLAGS   0x820
> +#define TCAN4X5X_MCAN_INT_REG0x824
> +#define TCAN4X5X_INT_EN  0x830
> +
> +
> +/* Interrupt bits */
> +#define TCAN4X5X_CANBUSTERMOPEN_INT_EN   BIT(30)
> +#define TCAN4X5X_CANHCANL_INT_EN BIT(29)
> +#define TCAN4X5X_CANHBAT_INT_EN  BIT(28)
> +#define TCAN4X5X_CANLGND_INT_EN  BIT(27)
> +#define TCAN4X5X_CANBUSOPEN_INT_EN   BIT(26)
> +#define TCAN4X5X_CANBUSGND_INT_ENBIT(25)
> +#define TCAN4X5X_CANBUSBAT_INT_ENBIT(24)
> +#define TCAN4X5X_UVSUP_INT_ENBIT(22)
> +#define TCAN4X5X_UVIO_INT_EN BIT(21)
> +#define TCAN4X5X_TSD_INT_EN  BIT(19)
> +#define TCAN4X5X_ECCERR_INT_EN   BIT(16)
> +#define TCAN4X5X_CANINT_INT_EN   BIT(15)
> +#define TCAN4X5X_LWU_INT_EN  BIT(14)
> +#define TCAN4X5X_CANSLNT_INT_EN  BIT(10)
> +#define TCAN4X5X_CANDOM_INT_EN   BIT(8)
> +#define TCAN4X5X_CANBUS_ERR_INT_EN   BIT(5)
> +#define TCAN4X5X_BUS_FAULT   BIT(4)
> +#define TCAN4X5X_MCAN_INTBIT(1)
> +#define TCAN4X5X_ENABLE_TCAN_INT (TCAN4X5X_MCAN_INT | \
> + TCAN4X5X_BUS_FAULT | \
> + TCAN4X5X_CANBUS_ERR_INT_EN | \
> + TCAN4X5X_CANINT_INT_EN)
> +
> +/* MCAN Interrupt bits */
> +#define TCAN4X5X_MCAN_IR_ARA BIT(29)
> +#define TCAN4X5X_MCAN_IR_PED BIT(28)
> +#define TCAN4X5X_MCAN_IR_PEA BIT(27)
> +#define TCAN4X5X_MCAN_IR_WD  BIT(26)
> +#define TCAN4X5X_MCAN_IR_BO  BIT(25)
> +#define TCAN4X5X_MCAN_IR_EW  BIT(24)
> +#define TCAN4X5X_MCAN_IR_EP  BIT(23)
> +#define TCAN4X5X_MCAN_IR_ELO BIT(22)
> +#define TCAN4X5X_MCAN_IR_BEU BIT(21)
> +#define TCAN4X5X_MCAN_IR_BEC BIT(20)
> +#define TCAN4X5X_MCAN_IR_DRX BIT(19)
> +#define TCAN4X5X_MCAN_IR_TOO BIT(18)
> +#define TCAN4X5X_MCAN_IR_MRAFBIT(17)
> +#define TCAN4X5X_MCAN_IR_TSW BIT(16)
> +#define TCAN4X5X_MCAN_IR_TEFLBIT(15)
> +#define TCAN4X5X_MCAN_IR_TEFFBIT(14)
> +#define TCAN4X5X_MCAN_IR_TEFWBIT(13)
> +#define TCAN4X5X_MCAN_IR_TEFNBIT(12)
> +#define TCAN4X5X_MCAN_IR_TFE

Re: [PATCH v5 2/5] can: m_can: Migrate the m_can code to use the framework

Am 14.02.19 um 19:27 schrieb Dan Murphy:
> Migrate the m_can code to use the m_can_platform framework
> code.
> 
> Signed-off-by: Dan Murphy 
> ---
> 
> v5 - Updated copyright, change m_can_classdev to m_can_priv, removed extra
> KCONFIG flag - https://lore.kernel.org/patchwork/patch/1033095/
> 
>  drivers/net/can/m_can/Kconfig  |   8 +-
>  drivers/net/can/m_can/Makefile |   1 +
>  drivers/net/can/m_can/m_can.c  | 745 -
>  3 files changed, 367 insertions(+), 387 deletions(-)
> 
> diff --git a/drivers/net/can/m_can/Kconfig b/drivers/net/can/m_can/Kconfig
> index 04f20dd39007..66e31022a5fa 100644
> --- a/drivers/net/can/m_can/Kconfig
> +++ b/drivers/net/can/m_can/Kconfig
> @@ -1,5 +1,11 @@
>  config CAN_M_CAN
> + tristate "Bosch M_CAN support"
> + ---help---
> +   Say Y here if you want to support for Bosch M_CAN controller.

Typo?

> +
> +config CAN_M_CAN_PLATFORM
> + tristate "Bosch M_CAN support for io-mapped devices"
>   depends on HAS_IOMEM
> - tristate "Bosch M_CAN devices"
> + depends on CAN_M_CAN
>   ---help---
> Say Y here if you want to support for Bosch M_CAN controller.

Please update the help.

> diff --git a/drivers/net/can/m_can/Makefile b/drivers/net/can/m_can/Makefile
> index 8bbd7f24f5be..057bbcdb3c74 100644
> --- a/drivers/net/can/m_can/Makefile
> +++ b/drivers/net/can/m_can/Makefile
> @@ -3,3 +3,4 @@
>  #
>  
>  obj-$(CONFIG_CAN_M_CAN) += m_can.o
> +obj-$(CONFIG_CAN_M_CAN_PLATFORM) += m_can_platform.o
> diff --git a/drivers/net/can/m_can/m_can.c b/drivers/net/can/m_can/m_can.c
> index 9b449400376b..2ceccb870557 100644
> --- a/drivers/net/can/m_can/m_can.c
> +++ b/drivers/net/can/m_can/m_can.c
> @@ -1,20 +1,16 @@
> +// SPDX-License-Identifier: GPL-2.0
> +// CAN bus driver for Bosch M_CAN controller
> +// Copyright (C) 2014 Freescale Semiconductor, Inc.
> +//  Dong Aisheng 
> +// Copyright (C) 2018-19 Texas Instruments Incorporated - http://www.ti.com/
> +
>  /*
> - * CAN bus driver for Bosch M_CAN controller
> - *
> - * Copyright (C) 2014 Freescale Semiconductor, Inc.
> - *   Dong Aisheng 
> - *
>   * Bosch M_CAN user manual can be obtained from:
>   * http://www.bosch-semiconductors.de/media/pdf_1/ipmodules_1/m_can/
>   * mcan_users_manual_v302.pdf
>   *
> - * This file is licensed under the terms of the GNU General Public
> - * License version 2. This program is licensed "as is" without any
> - * warranty of any kind, whether express or implied.
>   */
>  
> -#include 
> -#include 
>  #include 
>  #include 
>  #include 
> @@ -28,87 +24,14 @@
>  #include 
>  #include 
>  
> +#include "m_can.h"
> +
>  /* napi related */
>  #define M_CAN_NAPI_WEIGHT64
>  
>  /* message ram configuration data length */
>  #define MRAM_CFG_LEN 8
>  
> -/* registers definition */
> -enum m_can_reg {
> - M_CAN_CREL  = 0x0,
> - M_CAN_ENDN  = 0x4,
> - M_CAN_CUST  = 0x8,
> - M_CAN_DBTP  = 0xc,
> - M_CAN_TEST  = 0x10,
> - M_CAN_RWD   = 0x14,
> - M_CAN_CCCR  = 0x18,
> - M_CAN_NBTP  = 0x1c,
> - M_CAN_TSCC  = 0x20,
> - M_CAN_TSCV  = 0x24,
> - M_CAN_TOCC  = 0x28,
> - M_CAN_TOCV  = 0x2c,
> - M_CAN_ECR   = 0x40,
> - M_CAN_PSR   = 0x44,
> -/* TDCR Register only available for version >=3.1.x */
> - M_CAN_TDCR  = 0x48,
> - M_CAN_IR= 0x50,
> - M_CAN_IE= 0x54,
> - M_CAN_ILS   = 0x58,
> - M_CAN_ILE   = 0x5c,
> - M_CAN_GFC   = 0x80,
> - M_CAN_SIDFC = 0x84,
> - M_CAN_XIDFC = 0x88,
> - M_CAN_XIDAM = 0x90,
> - M_CAN_HPMS  = 0x94,
> - M_CAN_NDAT1 = 0x98,
> - M_CAN_NDAT2 = 0x9c,
> - M_CAN_RXF0C = 0xa0,
> - M_CAN_RXF0S = 0xa4,
> - M_CAN_RXF0A = 0xa8,
> - M_CAN_RXBC  = 0xac,
> - M_CAN_RXF1C = 0xb0,
> - M_CAN_RXF1S = 0xb4,
> - M_CAN_RXF1A = 0xb8,
> - M_CAN_RXESC = 0xbc,
> - M_CAN_TXBC  = 0xc0,
> - M_CAN_TXFQS = 0xc4,
> - M_CAN_TXESC = 0xc8,
> - M_CAN_TXBRP = 0xcc,
> - M_CAN_TXBAR = 0xd0,
> - M_CAN_TXBCR = 0xd4,
> - M_CAN_TXBTO = 0xd8,
> - M_CAN_TXBCF = 0xdc,
> - M_CAN_TXBTIE= 0xe0,
> - M_CAN_TXBCIE= 0xe4,
> - M_CAN_TXEFC = 0xf0,
> - M_CAN_TXEFS = 0xf4,
> - M_CAN_TXEFA = 0xf8,
> -};
> -
> -/* m_can lec values */
> -enum m_can_lec_type {
> - LEC_NO_ERROR = 0,
> - LEC_STUFF_ERROR,
> - LEC_FORM_ERROR,
> - LEC_ACK_ERROR,
> - LEC_BIT1_ERROR,
> - LEC_BIT0_ERROR,
> - LEC_CRC_ERROR,
> - LEC_UNUSED,
> -};
> -
> -enum m_can_mram_cfg {
> - MRAM_SIDF = 0,
> - MRAM_XIDF,
> - MRAM_RXF0,
> - MRAM_RXF1,
> - MRAM_RXB,
> - MRAM_TXE,
> - MRAM_TXB,
> - MRAM_CFG_NUM,
> -};
> -
>  /* Core Release Register (CREL) */
>  #define CREL_REL_SHIFT   28
>  #define CREL_REL_MASK(0xF << CREL_REL_SHIFT)
> @@ -343,77

Re: [PATCH v5 0/5] M_CAN Framework re-write

Hello,

Am 14.02.19 um 19:27 schrieb Dan Murphy:
> Hello
> 
> OK I did not give up on this patch series just got a little preoccupied with
> some other kernel work.  But here is the update per the comments.
> 
> It should be understood I broke these out for reviewability.
> For instance the first patch does not compile on its own as including this
> patch should not change the current functionality and it pulls all the 
> io-mapped
> code from the m_can base file to a platfrom file.

For git bisection, the code must compile!

> The next patch "Migrate the m_can code to use the framework"
> is the change to the kernel for the io-mapped conversion from a flat file to 
> use
> the framework.  Finally the rename patch just renames the m_can_priv to 
> m_can_classdev.  I broke this change out specifically for readability of the
> migration patch per comments on the code.
> 
> AFAIC the first 3 patches can all be squashed into a single patch.  Or the
> first 2 patches in the series can be re-arranged but then m_can functionality 
> is
> affected in the migration patch.

For the reason above, I would squash patch 1 and 2.

> 
> Again the first 3 patches here are all just for readability and review 
> purposes.>
> Dan
> 
> Dan Murphy (5):
>   can: m_can: Create a m_can platform framework
>   can: m_can: Migrate the m_can code to use the framework
>   can: m_can: Rename m_can_priv to m_can_classdev
>   dt-bindings: can: tcan4x5x: Add DT bindings for TCAN4x5X driver
>   can: tcan4x5x: Add tcan4x5x driver to the kernel
> 
>  .../devicetree/bindings/net/can/tcan4x5x.txt  |  37 +
>  drivers/net/can/m_can/Kconfig |  14 +-
>  drivers/net/can/m_can/Makefile|   2 +
>  drivers/net/can/m_can/m_can.c | 788 +-
>  drivers/net/can/m_can/m_can.h | 159 
>  drivers/net/can/m_can/m_can_platform.c| 198 +
>  drivers/net/can/m_can/tcan4x5x.c  | 531 
>  7 files changed, 1320 insertions(+), 409 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/net/can/tcan4x5x.txt
>  create mode 100644 drivers/net/can/m_can/m_can.h
>  create mode 100644 drivers/net/can/m_can/m_can_platform.c
>  create mode 100644 drivers/net/can/m_can/tcan4x5x.c

There are plenty of coding-style errors, e.g. white-space, indention,
line too long, etc. Please use "checkpatch" to find and fix.

Wolfgang.

Re: [PATCH v5 0/5] M_CAN Framework re-write

2019-02-24 Thread Wolfgang Grandegger

Hello Dan,

Am 22.02.19 um 18:05 schrieb Dan Murphy:
> Wolfgang
> 
> On 2/22/19 6:50 AM, Dan Murphy wrote:
>> Wolfgang
>>
>> On 2/22/19 3:38 AM, Wolfgang Grandegger wrote:
>>> Hello Dan,
>>>
>>> what kernel version is that patch series for. I have problems to apply it!
>>>
>>
>> It is based off of Master
>>
>> commit 2137397c92aec3713fa10be3c9b830f9a1674e60 (linux_master/master)
>>
>> And I successfully rebased on top of
>>
>> commit 8a61716ff2ab23eddd1f7a05a075a374e4d0c3d4 (linux_master/master)
>> Merge tag 'ceph-for-5.0-rc8' of git://github.com/ceph/ceph-client
>>
> 
> I just pulled these patches and they applied fine to the top commit of linux 
> master
> 
> Do I need to rebase on top of a for-next branch for you?

No, I can apply the series now as well.

Wolfgang,

Re: [PATCH v5 0/5] M_CAN Framework re-write

2019-02-22 Thread Wolfgang Grandegger

Hello Dan,

what kernel version is that patch series for. I have problems to apply it!

Wolfgang.

Am 21.02.19 um 17:41 schrieb Wolfgang Grandegger:
> Hello Dan,
> 
> I will have a closer look end of this week!
> 
> Wolfgang.
> 
> Am 21.02.19 um 17:24 schrieb Dan Murphy:
>> Bump
>>
>> On 2/14/19 12:27 PM, Dan Murphy wrote:
>>> Hello
>>>
>>> OK I did not give up on this patch series just got a little preoccupied with
>>> some other kernel work.  But here is the update per the comments.
>>>
>>> It should be understood I broke these out for reviewability.
>>> For instance the first patch does not compile on its own as including this
>>> patch should not change the current functionality and it pulls all the 
>>> io-mapped
>>> code from the m_can base file to a platfrom file.
>>>
>>> The next patch "Migrate the m_can code to use the framework"
>>> is the change to the kernel for the io-mapped conversion from a flat file 
>>> to use
>>> the framework.  Finally the rename patch just renames the m_can_priv to 
>>> m_can_classdev.  I broke this change out specifically for readability of the
>>> migration patch per comments on the code.
>>>
>>> AFAIC the first 3 patches can all be squashed into a single patch.  Or the
>>> first 2 patches in the series can be re-arranged but then m_can 
>>> functionality is
>>> affected in the migration patch.
>>>
>>> Again the first 3 patches here are all just for readability and review 
>>> purposes.
>>>
>>> Dan
>>>
>>> Dan Murphy (5):
>>>   can: m_can: Create a m_can platform framework
>>>   can: m_can: Migrate the m_can code to use the framework
>>>   can: m_can: Rename m_can_priv to m_can_classdev
>>>   dt-bindings: can: tcan4x5x: Add DT bindings for TCAN4x5X driver
>>>   can: tcan4x5x: Add tcan4x5x driver to the kernel
>>>
>>>  .../devicetree/bindings/net/can/tcan4x5x.txt  |  37 +
>>>  drivers/net/can/m_can/Kconfig |  14 +-
>>>  drivers/net/can/m_can/Makefile|   2 +
>>>  drivers/net/can/m_can/m_can.c | 788 +-
>>>  drivers/net/can/m_can/m_can.h | 159 
>>>  drivers/net/can/m_can/m_can_platform.c| 198 +
>>>  drivers/net/can/m_can/tcan4x5x.c  | 531 
>>>  7 files changed, 1320 insertions(+), 409 deletions(-)
>>>  create mode 100644 Documentation/devicetree/bindings/net/can/tcan4x5x.txt
>>>  create mode 100644 drivers/net/can/m_can/m_can.h
>>>  create mode 100644 drivers/net/can/m_can/m_can_platform.c
>>>  create mode 100644 drivers/net/can/m_can/tcan4x5x.c
>>>
>>
>>

Re: [PATCH v5 0/5] M_CAN Framework re-write

2019-02-21 Thread Wolfgang Grandegger

Hello Dan,

I will have a closer look end of this week!

Wolfgang.

Am 21.02.19 um 17:24 schrieb Dan Murphy:
> Bump
> 
> On 2/14/19 12:27 PM, Dan Murphy wrote:
>> Hello
>>
>> OK I did not give up on this patch series just got a little preoccupied with
>> some other kernel work.  But here is the update per the comments.
>>
>> It should be understood I broke these out for reviewability.
>> For instance the first patch does not compile on its own as including this
>> patch should not change the current functionality and it pulls all the 
>> io-mapped
>> code from the m_can base file to a platfrom file.
>>
>> The next patch "Migrate the m_can code to use the framework"
>> is the change to the kernel for the io-mapped conversion from a flat file to 
>> use
>> the framework.  Finally the rename patch just renames the m_can_priv to 
>> m_can_classdev.  I broke this change out specifically for readability of the
>> migration patch per comments on the code.
>>
>> AFAIC the first 3 patches can all be squashed into a single patch.  Or the
>> first 2 patches in the series can be re-arranged but then m_can 
>> functionality is
>> affected in the migration patch.
>>
>> Again the first 3 patches here are all just for readability and review 
>> purposes.
>>
>> Dan
>>
>> Dan Murphy (5):
>>   can: m_can: Create a m_can platform framework
>>   can: m_can: Migrate the m_can code to use the framework
>>   can: m_can: Rename m_can_priv to m_can_classdev
>>   dt-bindings: can: tcan4x5x: Add DT bindings for TCAN4x5X driver
>>   can: tcan4x5x: Add tcan4x5x driver to the kernel
>>
>>  .../devicetree/bindings/net/can/tcan4x5x.txt  |  37 +
>>  drivers/net/can/m_can/Kconfig |  14 +-
>>  drivers/net/can/m_can/Makefile|   2 +
>>  drivers/net/can/m_can/m_can.c | 788 +-
>>  drivers/net/can/m_can/m_can.h | 159 
>>  drivers/net/can/m_can/m_can_platform.c| 198 +
>>  drivers/net/can/m_can/tcan4x5x.c  | 531 
>>  7 files changed, 1320 insertions(+), 409 deletions(-)
>>  create mode 100644 Documentation/devicetree/bindings/net/can/tcan4x5x.txt
>>  create mode 100644 drivers/net/can/m_can/m_can.h
>>  create mode 100644 drivers/net/can/m_can/m_can_platform.c
>>  create mode 100644 drivers/net/can/m_can/tcan4x5x.c
>>
> 
>

Re: [PATCH v4 1/4] can: m_can: Create a m_can platform framework

Hello Dan,

Am 22.01.19 um 14:04 schrieb Dan Murphy:
> Wolfgang
> 
> Thanks for the review
> 
> On 1/22/19 2:16 AM, Wolfgang Grandegger wrote:
>> Hello Dan,
>>
>> looks already quite good...
>>
>> Am 17.01.19 um 21:05 schrieb Dan Murphy:
>>> Create a m_can platform framework that peripherial
>>> devices can register to and use common code and register sets.
>>> The peripherial devices may provide read/write and configuration
>>> support of the IP.
>>>
>>> Signed-off-by: Dan Murphy 
>>> ---
>>>  drivers/net/can/m_can/m_can.c  |   6 +
>>>  drivers/net/can/m_can/m_can_platform.c | 209 +
>>>  drivers/net/can/m_can/m_can_platform.h | 163 +++
>>>  3 files changed, 378 insertions(+)
>>>  create mode 100644 drivers/net/can/m_can/m_can_platform.c
>>>  create mode 100644 drivers/net/can/m_can/m_can_platform.h
>>>
>>> diff --git a/drivers/net/can/m_can/m_can.c b/drivers/net/can/m_can/m_can.c
>>> index 9b449400376b..f817b28582e9 100644
>>> --- a/drivers/net/can/m_can/m_can.c
>>> +++ b/drivers/net/can/m_can/m_can.c
>>> @@ -414,6 +414,9 @@ static inline void m_can_config_endisable(const struct 
>>> m_can_priv *priv,
>>> u32 timeout = 10;
>>> u32 val = 0;
>>>  
>>> +   if (cccr & CCCR_CSR)
>>> +   cccr &= ~CCCR_CSR;
>>> +
>>
>> This is an unrelated change/fix. Should go somewhere else.
>>
> 
> I thought I pulled this and the change below out of of this patchset.
> 
>>> if (enable) {
>>> /* enable m_can configuration */
>>> m_can_write(priv, M_CAN_CCCR, cccr | CCCR_INIT);
>>> @@ -1155,6 +1158,9 @@ static void m_can_chip_config(struct net_device *dev)
>>> m_can_set_bittiming(dev);
>>>  
>>> m_can_config_endisable(priv, false);
>>> +
>>> +   if (priv->device_init)
>>> +   priv->device_init(priv);
>>>  }
>>>  
>>>  static void m_can_start(struct net_device *dev)
>>> diff --git a/drivers/net/can/m_can/m_can_platform.c 
>>> b/drivers/net/can/m_can/m_can_platform.c
>>> new file mode 100644
>>> index ..03172911323a
>>> --- /dev/null
>>> +++ b/drivers/net/can/m_can/m_can_platform.c
>>> @@ -0,0 +1,209 @@
>>> +/*
>>> + * CAN bus driver for Bosch M_CAN controller
>>> + *
>>> + * Copyright (C) 2014 Freescale Semiconductor, Inc.
>>> + * Dong Aisheng 
>>> + *
>>> + * Bosch M_CAN user manual can be obtained from:
>>> + * http://www.bosch-semiconductors.de/media/pdf_1/ipmodules_1/m_can/
>>> + * mcan_users_manual_v302.pdf
>>> + *
>>> + * This file is licensed under the terms of the GNU General Public
>>> + * License version 2. This program is licensed "as is" without any
>>> + * warranty of any kind, whether express or implied.
>>> + */
>>> +
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +
>>> +#include "m_can_platform.h"
>>> +
>>> +struct m_can_plat_priv {
>>> +   void __iomem *base;
>>> +   void __iomem *mram_base;
>>> +};
>>> +
>>> +static u32 iomap_read_reg(struct m_can_classdev *m_can_class, int reg)
>>> +{
>>> +   struct m_can_plat_priv *priv = (struct m_can_plat_priv 
>>> *)m_can_class->device_data;
>>> +
>>> +   return readl(priv->base + reg);
>>> +}
>>> +
>>> +static u32 iomap_read_fifo(struct m_can_classdev *m_can_class, int 
>>> addr_offset)
>>
>> Why not just "offset".
>>
> 
> I can change the name
> 
>>> +{
>>> +   struct m_can_plat_priv *priv = (struct m_can_plat_priv 
>>> *)m_can_class->device_data;
>>> +
>>> +   return readl(priv->mram_base + addr_offset);
>>> +}
>>> +
>>> +static int iomap_write_reg(struct m_can_classdev *m_can_class, int reg, 
>>> int val)
>>> +{
>>> +   struct m_can_plat_priv *priv = (struct m_can_plat_priv 
>>> *)m_can_class->device_data;
>>> +
>>> +   writel(val, priv->base + reg);
>>> +
>>> +   return 0;
>>> +}
>>> +
>>> +static int iomap_write_fifo(s

Re: [PATCH v4 2/4] can: m_can: Migrate the m_can code to use the framework

Hello Dan,

Am 22.01.19 um 14:37 schrieb Dan Murphy:
> Wolfgang
> 
> On 1/22/19 3:35 AM, Wolfgang Grandegger wrote:
>> Hello,
>>
>> Am 17.01.19 um 21:05 schrieb Dan Murphy:
>>> Migrate the m_can code to use the m_can_platform framework
>>> code.
>>>
>>> Signed-off-by: Dan Murphy 
>>> ---
>>>  drivers/net/can/m_can/Kconfig  |  12 +
>>>  drivers/net/can/m_can/Makefile |   4 +-
>>>  drivers/net/can/m_can/m_can.c  | 764 -
>>>  drivers/net/can/m_can/m_can_platform.h |   2 +-
>>>  4 files changed, 374 insertions(+), 408 deletions(-)
>>>
>>> diff --git a/drivers/net/can/m_can/Kconfig b/drivers/net/can/m_can/Kconfig
>>> index 04f20dd39007..b1a9358b7660 100644
>>> --- a/drivers/net/can/m_can/Kconfig
>>> +++ b/drivers/net/can/m_can/Kconfig
>>> @@ -1,5 +1,17 @@
>>>  config CAN_M_CAN
>>> +   tristate "Bosch M_CAN support"
>>> +   ---help---
>>> + Say Y here if you want to support for Bosch M_CAN controller.
>>> +
>>> +config CAN_M_CAN_CORE
>>> +   depends on CAN_M_CAN
>>> +   tristate "Bosch M_CAN Core support"
>>> +   ---help---
>>> + Say Y here if you want to support for Bosch M_CAN controller.
>>
>> Do you need that extra config? I think "CAN_M_CAN" is just fine.
>>
> 
> OK I can remove the CORE.  That should be built if CAN_M_CAN is selected then
> 
>>> +config CAN_M_CAN_PLATFORM
>>> depends on HAS_IOMEM
>>> +   depends on CAN_M_CAN_CORE
>>> tristate "Bosch M_CAN devices"
>>> ---help---
>>>   Say Y here if you want to support for Bosch M_CAN controller.
>>> diff --git a/drivers/net/can/m_can/Makefile b/drivers/net/can/m_can/Makefile
>>> index 8bbd7f24f5be..04f36947ac3b 100644
>>> --- a/drivers/net/can/m_can/Makefile
>>> +++ b/drivers/net/can/m_can/Makefile
>>> @@ -2,4 +2,6 @@
>>>  #  Makefile for the Bosch M_CAN controller driver.
>>>  #
>>>  
>>> -obj-$(CONFIG_CAN_M_CAN) += m_can.o
>>> +obj-$(CONFIG_CAN_M_CAN_CORE) += m_can.o
>>> +obj-$(CONFIG_CAN_M_CAN_PLATFORM) += m_can_platform.o
>>> +obj-$(CONFIG_CAN_M_CAN_TCAN4X5X) += tcan4x5x.o
>>
>> This file is provided in a sub-sequent patched! The code *must* compile
>> for every single patch applied for bisect'ing. Looking to your first
>> patch, I just realize that this is also not the case!
>>
>> I think it makes sense to squash patch 1 and 2.
>>
> 
> Well.  Patch 1 should compile on its own I will check that.
> 
> Squashing patch 1 and patch 2 made the review even more impossible.
> So I made patch 1 to create the io-mapped code (which probably will not 
> compile when enabled) and then
> patch 2 was the changes to the CORE to stitch in the io-mapped code.

Patch 1 just changes two small locations of "m_can.c". It does not use
the new interface or even include "m_can_platform.h". Patch 2 is
well readable, especially the common code. It would be even better if
"struct can_priv" would be kept and all the functions in the original
order. That's why I suggested to do so.

> Patch 4 was the addition of the peripherial.
> 
> I did this because there was a comment from the RFCs I sent in that there was 
> to much change to review for a single patch
> conversion.  I can squash patch 1 and patch 2 after we finish the review 
> process prior to merging it into the tree.
> 
> That was also the comment I received from an internal review.

Sorry, if I confused you! My concern was about the common code in m_can.c.

>>> diff --git a/drivers/net/can/m_can/m_can.c b/drivers/net/can/m_can/m_can.c
>>> index f817b28582e9..6da0ae26138e 100644
>>> --- a/drivers/net/can/m_can/m_can.c
>>> +++ b/drivers/net/can/m_can/m_can.c
>>> @@ -28,87 +28,14 @@
>>>  #include 
>>>  #include 
>>>  
>>> +#include "m_can_platform.h"
>>> +
>>>  /* napi related */
>>>  #define M_CAN_NAPI_WEIGHT  64
>>>  
>>>  /* message ram configuration data length */
>>>  #define MRAM_CFG_LEN   8
>>>  
>>> -/* registers definition */
>>> -enum m_can_reg {
>>> -   M_CAN_CREL  = 0x0,
>>> -   M_CAN_ENDN  = 0x4,
>>> -   M_CAN_CUST  = 0x8,
>>> -   M_CAN_DBTP  = 0xc,
>>> -   M_CAN_TEST  = 0x10,
>>> -   M_CAN_RWD   = 0x14,
>>> -   M_CAN_CCCR  = 0x18,
>>> -   M_CAN_NBTP  = 0x1c,
>>

Re: [PATCH v4 4/4] can: tcan4x5x: Add tcan4x5x driver to the kernel

Hello,

Am 17.01.19 um 21:06 schrieb Dan Murphy:
> Add the TCAN4x5x SPI CAN driver.  This device
> uses the Bosch MCAN IP core along with a SPI
> interface map.  Leverage the MCAN common core
> code to manage the MCAN IP.
> 
> This device has a special method to indicate a
> write/read operation on the data payload.
> 
> Signed-off-by: Dan Murphy 
> ---
>  drivers/net/can/m_can/Kconfig|   6 +
>  drivers/net/can/m_can/tcan4x5x.c | 529 +++
>  2 files changed, 535 insertions(+)
>  create mode 100644 drivers/net/can/m_can/tcan4x5x.c
> 
> diff --git a/drivers/net/can/m_can/Kconfig b/drivers/net/can/m_can/Kconfig
> index b1a9358b7660..b38959b3b8f1 100644
> --- a/drivers/net/can/m_can/Kconfig
> +++ b/drivers/net/can/m_can/Kconfig
> @@ -15,3 +15,9 @@ config CAN_M_CAN_PLATFORM
>   tristate "Bosch M_CAN devices"
>   ---help---
> Say Y here if you want to support for Bosch M_CAN controller.
> +
> +config CAN_M_CAN_TCAN4X5X
> + depends on CAN_M_CAN
> + tristate "TCAN4X5X M_CAN device"
> + ---help---
> +   Say Y here if you want to support for TI M_CAN controller.
> diff --git a/drivers/net/can/m_can/tcan4x5x.c 
> b/drivers/net/can/m_can/tcan4x5x.c
> new file mode 100644
> index ..3cd6cd5052b6
> --- /dev/null
> +++ b/drivers/net/can/m_can/tcan4x5x.c
> @@ -0,0 +1,529 @@
> +// SPDX-License-Identifier: GPL-2.0
> +// SPI to CAN driver for the Texas Instruments TCAN4x5x
> +// Copyright (C) 2018-19 Texas Instruments Incorporated - http://www.ti.com/
> +
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +
> +#include "m_can_platform.h"
> +
> +#define DEVICE_NAME "tcan4x5x"
> +#define TCAN4X5X_EXT_CLK_DEF 4000
> +
> +#define TCAN4X5X_DEV_ID0 0x00
> +#define TCAN4X5X_DEV_ID1 0x04
> +#define TCAN4X5X_REV 0x08
> +#define TCAN4X5X_STATUS  0x0C
> +#define TCAN4X5X_ERROR_STATUS0x10
> +#define TCAN4X5X_CONTROL 0x14
> +
> +#define TCAN4X5X_CONFIG  0x800
> +#define TCAN4X5X_TS_PRESCALE 0x804
> +#define TCAN4X5X_TEST_REG0x808
> +#define TCAN4X5X_INT_FLAGS   0x820
> +#define TCAN4X5X_MCAN_INT_REG0x824
> +#define TCAN4X5X_INT_EN  0x830
> +
> +
> +/* Interrupt bits */
> +#define TCAN4X5X_CANBUSTERMOPEN_INT_EN   BIT(30)
> +#define TCAN4X5X_CANHCANL_INT_EN BIT(29)
> +#define TCAN4X5X_CANHBAT_INT_EN  BIT(28)
> +#define TCAN4X5X_CANLGND_INT_EN  BIT(27)
> +#define TCAN4X5X_CANBUSOPEN_INT_EN   BIT(26)
> +#define TCAN4X5X_CANBUSGND_INT_ENBIT(25)
> +#define TCAN4X5X_CANBUSBAT_INT_ENBIT(24)
> +#define TCAN4X5X_UVSUP_INT_ENBIT(22)
> +#define TCAN4X5X_UVIO_INT_EN BIT(21)
> +#define TCAN4X5X_TSD_INT_EN  BIT(19)
> +#define TCAN4X5X_ECCERR_INT_EN   BIT(16)
> +#define TCAN4X5X_CANINT_INT_EN   BIT(15)
> +#define TCAN4X5X_LWU_INT_EN  BIT(14)
> +#define TCAN4X5X_CANSLNT_INT_EN  BIT(10)
> +#define TCAN4X5X_CANDOM_INT_EN   BIT(8)
> +#define TCAN4X5X_CANBUS_ERR_INT_EN   BIT(5)
> +#define TCAN4X5X_BUS_FAULT   BIT(4)
> +#define TCAN4X5X_MCAN_INTBIT(1)
> +#define TCAN4X5X_ENABLE_TCAN_INT (TCAN4X5X_MCAN_INT | \
> + TCAN4X5X_BUS_FAULT | \
> + TCAN4X5X_CANBUS_ERR_INT_EN | \
> + TCAN4X5X_CANINT_INT_EN)
> +
> +/* MCAN Interrupt bits */
> +#define TCAN4X5X_MCAN_IR_ARA BIT(29)
> +#define TCAN4X5X_MCAN_IR_PED BIT(28)
> +#define TCAN4X5X_MCAN_IR_PEA BIT(27)
> +#define TCAN4X5X_MCAN_IR_WD  BIT(26)
> +#define TCAN4X5X_MCAN_IR_BO  BIT(25)
> +#define TCAN4X5X_MCAN_IR_EW  BIT(24)
> +#define TCAN4X5X_MCAN_IR_EP  BIT(23)
> +#define TCAN4X5X_MCAN_IR_ELO BIT(22)
> +#define TCAN4X5X_MCAN_IR_BEU BIT(21)
> +#define TCAN4X5X_MCAN_IR_BEC BIT(20)
> +#define TCAN4X5X_MCAN_IR_DRX BIT(19)
> +#define TCAN4X5X_MCAN_IR_TOO BIT(18)
> +#define TCAN4X5X_MCAN_IR_MRAFBIT(17)
> +#define TCAN4X5X_MCAN_IR_TSW BIT(16)
> +#define TCAN4X5X_MCAN_IR_TEFLBIT(15)
> +#define TCAN4X5X_MCAN_IR_TEFFBIT(14)
> +#define TCAN4X5X_MCAN_IR_TEFWBIT(13)
> +#define TCAN4X5X_MCAN_IR_TEFNBIT(12)
> +#define TCAN4X5X_MCAN_IR_TFE BIT(11)
> +#define TCAN4X5X_MCAN_IR_TCF BIT(10)
> +#define TCAN4X5X_MCAN_IR_TC  BIT(9)
> +#define TCAN4X5X_MCAN_IR_HPM BIT(8)
> +#define TCAN4X5X_MCAN_IR_RF1LBIT(7)
> +#define TCAN4X5X_MCAN_IR_RF1FBIT(6)
> +#define TCAN4X5X_MCAN_IR_RF1WBIT(5)
> +#define TCAN4X5X_MCAN_IR_RF1NBIT(4)
> +#define TCAN4X5X_MCAN_IR_RF0LBIT(3)
> +#define TCAN4X5X_MCAN_IR_RF0FBIT(2)
> +#define TCAN4X5X_MCAN_IR_RF0WBIT(1)
> +#define TCAN4X5X_MCAN_IR_RF0NBIT(0)

These bits

Re: [PATCH v4 2/4] can: m_can: Migrate the m_can code to use the framework

Hello,

Am 17.01.19 um 21:05 schrieb Dan Murphy:
> Migrate the m_can code to use the m_can_platform framework
> code.
> 
> Signed-off-by: Dan Murphy 
> ---
>  drivers/net/can/m_can/Kconfig  |  12 +
>  drivers/net/can/m_can/Makefile |   4 +-
>  drivers/net/can/m_can/m_can.c  | 764 -
>  drivers/net/can/m_can/m_can_platform.h |   2 +-
>  4 files changed, 374 insertions(+), 408 deletions(-)
> 
> diff --git a/drivers/net/can/m_can/Kconfig b/drivers/net/can/m_can/Kconfig
> index 04f20dd39007..b1a9358b7660 100644
> --- a/drivers/net/can/m_can/Kconfig
> +++ b/drivers/net/can/m_can/Kconfig
> @@ -1,5 +1,17 @@
>  config CAN_M_CAN
> + tristate "Bosch M_CAN support"
> + ---help---
> +   Say Y here if you want to support for Bosch M_CAN controller.
> +
> +config CAN_M_CAN_CORE
> + depends on CAN_M_CAN
> + tristate "Bosch M_CAN Core support"
> + ---help---
> +   Say Y here if you want to support for Bosch M_CAN controller.

Do you need that extra config? I think "CAN_M_CAN" is just fine.

> +config CAN_M_CAN_PLATFORM
>   depends on HAS_IOMEM
> + depends on CAN_M_CAN_CORE
>   tristate "Bosch M_CAN devices"
>   ---help---
> Say Y here if you want to support for Bosch M_CAN controller.
> diff --git a/drivers/net/can/m_can/Makefile b/drivers/net/can/m_can/Makefile
> index 8bbd7f24f5be..04f36947ac3b 100644
> --- a/drivers/net/can/m_can/Makefile
> +++ b/drivers/net/can/m_can/Makefile
> @@ -2,4 +2,6 @@
>  #  Makefile for the Bosch M_CAN controller driver.
>  #
>  
> -obj-$(CONFIG_CAN_M_CAN) += m_can.o
> +obj-$(CONFIG_CAN_M_CAN_CORE) += m_can.o
> +obj-$(CONFIG_CAN_M_CAN_PLATFORM) += m_can_platform.o
> +obj-$(CONFIG_CAN_M_CAN_TCAN4X5X) += tcan4x5x.o

This file is provided in a sub-sequent patched! The code *must* compile
for every single patch applied for bisect'ing. Looking to your first
patch, I just realize that this is also not the case!

I think it makes sense to squash patch 1 and 2.

> diff --git a/drivers/net/can/m_can/m_can.c b/drivers/net/can/m_can/m_can.c
> index f817b28582e9..6da0ae26138e 100644
> --- a/drivers/net/can/m_can/m_can.c
> +++ b/drivers/net/can/m_can/m_can.c
> @@ -28,87 +28,14 @@
>  #include 
>  #include 
>  
> +#include "m_can_platform.h"
> +
>  /* napi related */
>  #define M_CAN_NAPI_WEIGHT64
>  
>  /* message ram configuration data length */
>  #define MRAM_CFG_LEN 8
>  
> -/* registers definition */
> -enum m_can_reg {
> - M_CAN_CREL  = 0x0,
> - M_CAN_ENDN  = 0x4,
> - M_CAN_CUST  = 0x8,
> - M_CAN_DBTP  = 0xc,
> - M_CAN_TEST  = 0x10,
> - M_CAN_RWD   = 0x14,
> - M_CAN_CCCR  = 0x18,
> - M_CAN_NBTP  = 0x1c,
> - M_CAN_TSCC  = 0x20,
> - M_CAN_TSCV  = 0x24,
> - M_CAN_TOCC  = 0x28,
> - M_CAN_TOCV  = 0x2c,
> - M_CAN_ECR   = 0x40,
> - M_CAN_PSR   = 0x44,
> -/* TDCR Register only available for version >=3.1.x */
> - M_CAN_TDCR  = 0x48,
> - M_CAN_IR= 0x50,
> - M_CAN_IE= 0x54,
> - M_CAN_ILS   = 0x58,
> - M_CAN_ILE   = 0x5c,
> - M_CAN_GFC   = 0x80,
> - M_CAN_SIDFC = 0x84,
> - M_CAN_XIDFC = 0x88,
> - M_CAN_XIDAM = 0x90,
> - M_CAN_HPMS  = 0x94,
> - M_CAN_NDAT1 = 0x98,
> - M_CAN_NDAT2 = 0x9c,
> - M_CAN_RXF0C = 0xa0,
> - M_CAN_RXF0S = 0xa4,
> - M_CAN_RXF0A = 0xa8,
> - M_CAN_RXBC  = 0xac,
> - M_CAN_RXF1C = 0xb0,
> - M_CAN_RXF1S = 0xb4,
> - M_CAN_RXF1A = 0xb8,
> - M_CAN_RXESC = 0xbc,
> - M_CAN_TXBC  = 0xc0,
> - M_CAN_TXFQS = 0xc4,
> - M_CAN_TXESC = 0xc8,
> - M_CAN_TXBRP = 0xcc,
> - M_CAN_TXBAR = 0xd0,
> - M_CAN_TXBCR = 0xd4,
> - M_CAN_TXBTO = 0xd8,
> - M_CAN_TXBCF = 0xdc,
> - M_CAN_TXBTIE= 0xe0,
> - M_CAN_TXBCIE= 0xe4,
> - M_CAN_TXEFC = 0xf0,
> - M_CAN_TXEFS = 0xf4,
> - M_CAN_TXEFA = 0xf8,
> -};
> -
> -/* m_can lec values */
> -enum m_can_lec_type {
> - LEC_NO_ERROR = 0,
> - LEC_STUFF_ERROR,
> - LEC_FORM_ERROR,
> - LEC_ACK_ERROR,
> - LEC_BIT1_ERROR,
> - LEC_BIT0_ERROR,
> - LEC_CRC_ERROR,
> - LEC_UNUSED,
> -};
> -
> -enum m_can_mram_cfg {
> - MRAM_SIDF = 0,
> - MRAM_XIDF,
> - MRAM_RXF0,
> - MRAM_RXF1,
> - MRAM_RXB,
> - MRAM_TXE,
> - MRAM_TXB,
> - MRAM_CFG_NUM,
> -};

Patch 1 should have already done that!

>  /* Core Release Register (CREL) */
>  #define CREL_REL_SHIFT   28
>  #define CREL_REL_MASK(0xF << CREL_REL_SHIFT)
> @@ -343,72 +270,81 @@ enum m_can_mram_cfg {
>  #define TX_BUF_MM_MASK   (0xff << TX_BUF_MM_SHIFT)
>  
>  /* Tx event FIFO Element */
> -/* E1 */
>  #define TX_EVENT_MM_SHIFTTX_BUF_MM_SHIFT
>  #define TX_EVENT_MM_MASK (0xff << TX_EVENT_MM_SHIFT)
>  
> -/* address offset and element number for each FIFO/Buffer in

Re: [PATCH v4 1/4] can: m_can: Create a m_can platform framework

Hello Dan,

looks already quite good...

Am 17.01.19 um 21:05 schrieb Dan Murphy:
> Create a m_can platform framework that peripherial
> devices can register to and use common code and register sets.
> The peripherial devices may provide read/write and configuration
> support of the IP.
> 
> Signed-off-by: Dan Murphy 
> ---
>  drivers/net/can/m_can/m_can.c  |   6 +
>  drivers/net/can/m_can/m_can_platform.c | 209 +
>  drivers/net/can/m_can/m_can_platform.h | 163 +++
>  3 files changed, 378 insertions(+)
>  create mode 100644 drivers/net/can/m_can/m_can_platform.c
>  create mode 100644 drivers/net/can/m_can/m_can_platform.h
> 
> diff --git a/drivers/net/can/m_can/m_can.c b/drivers/net/can/m_can/m_can.c
> index 9b449400376b..f817b28582e9 100644
> --- a/drivers/net/can/m_can/m_can.c
> +++ b/drivers/net/can/m_can/m_can.c
> @@ -414,6 +414,9 @@ static inline void m_can_config_endisable(const struct 
> m_can_priv *priv,
>   u32 timeout = 10;
>   u32 val = 0;
>  
> + if (cccr & CCCR_CSR)
> + cccr &= ~CCCR_CSR;
> +

This is an unrelated change/fix. Should go somewhere else.

>   if (enable) {
>   /* enable m_can configuration */
>   m_can_write(priv, M_CAN_CCCR, cccr | CCCR_INIT);
> @@ -1155,6 +1158,9 @@ static void m_can_chip_config(struct net_device *dev)
>   m_can_set_bittiming(dev);
>  
>   m_can_config_endisable(priv, false);
> +
> + if (priv->device_init)
> + priv->device_init(priv);
>  }
>  
>  static void m_can_start(struct net_device *dev)
> diff --git a/drivers/net/can/m_can/m_can_platform.c 
> b/drivers/net/can/m_can/m_can_platform.c
> new file mode 100644
> index ..03172911323a
> --- /dev/null
> +++ b/drivers/net/can/m_can/m_can_platform.c
> @@ -0,0 +1,209 @@
> +/*
> + * CAN bus driver for Bosch M_CAN controller
> + *
> + * Copyright (C) 2014 Freescale Semiconductor, Inc.
> + *   Dong Aisheng 
> + *
> + * Bosch M_CAN user manual can be obtained from:
> + * http://www.bosch-semiconductors.de/media/pdf_1/ipmodules_1/m_can/
> + * mcan_users_manual_v302.pdf
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "m_can_platform.h"
> +
> +struct m_can_plat_priv {
> + void __iomem *base;
> + void __iomem *mram_base;
> +};
> +
> +static u32 iomap_read_reg(struct m_can_classdev *m_can_class, int reg)
> +{
> + struct m_can_plat_priv *priv = (struct m_can_plat_priv 
> *)m_can_class->device_data;
> +
> + return readl(priv->base + reg);
> +}
> +
> +static u32 iomap_read_fifo(struct m_can_classdev *m_can_class, int 
> addr_offset)

Why not just "offset".

> +{
> + struct m_can_plat_priv *priv = (struct m_can_plat_priv 
> *)m_can_class->device_data;
> +
> + return readl(priv->mram_base + addr_offset);
> +}
> +
> +static int iomap_write_reg(struct m_can_classdev *m_can_class, int reg, int 
> val)
> +{
> + struct m_can_plat_priv *priv = (struct m_can_plat_priv 
> *)m_can_class->device_data;
> +
> + writel(val, priv->base + reg);
> +
> + return 0;
> +}
> +
> +static int iomap_write_fifo(struct m_can_classdev *m_can_class, int 
> addr_offset, int val)
> +{
> + struct m_can_plat_priv *priv = (struct m_can_plat_priv 
> *)m_can_class->device_data;
> +
> + writel(val, priv->base + addr_offset);
> +
> + return 0;
> +}
> +
> +static int m_can_plat_probe(struct platform_device *pdev)
> +{
> + struct m_can_classdev *mcan_class;
> + struct m_can_plat_priv *priv;
> + struct resource *res;
> + void __iomem *addr;
> + void __iomem *mram_addr;
> + int irq, ret = 0;
> +
> + mcan_class = m_can_core_allocate_dev(>dev);
> + priv = devm_kzalloc(>dev, sizeof(*priv), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
> +
> + mcan_class->device_data = priv;
> +
> + m_can_core_get_clocks(mcan_class);
> +
> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "m_can");
> + addr = devm_ioremap_resource(>dev, res);
> + irq = platform_get_irq_byname(pdev, "int0");
> + if (IS_ERR(addr) || irq < 0) {
> + ret = -EINVAL;
> + goto failed_ret;
> + }
> +
> + /* message ram could be shared */
> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "message_ram");
> + if (!res) {
> + ret = -ENODEV;
> + goto failed_ret;
> + }
> +
> + mram_addr = devm_ioremap(>dev, res->start, resource_size(res));
> + if (!mram_addr) {
> + ret = -ENOMEM;
> + goto failed_ret;
> + }
> +
> + priv->base = addr;
> + priv->mram_base = mram_addr;
> +
> + mcan_class->net->irq = irq;
> +

Re: [PATCH v4 1/4] can: m_can: Create a m_can platform framework

2019-01-17 Thread Wolfgang Grandegger

Hello Dan,

Am 17.01.19 um 21:08 schrieb Dan Murphy:
> Wolfgang
> 
> On 1/17/19 2:05 PM, Dan Murphy wrote:
>> Create a m_can platform framework that peripherial
>> devices can register to and use common code and register sets.
>> The peripherial devices may provide read/write and configuration
>> support of the IP.
>>
>> Signed-off-by: Dan Murphy 
>> ---
>>  drivers/net/can/m_can/m_can.c  |   6 +
>>  drivers/net/can/m_can/m_can_platform.c | 209 +
>>  drivers/net/can/m_can/m_can_platform.h | 163 +++
>>  3 files changed, 378 insertions(+)
>>  create mode 100644 drivers/net/can/m_can/m_can_platform.c
>>  create mode 100644 drivers/net/can/m_can/m_can_platform.h
>>

... snip ...

> This patch set is working for the TCAN and at least boots on io-mapped 
> devices.
> We have a couple of customers who are looking at using this implementation 
> and we would like to
> start moving this patch set along in the review.
> 
> I did not put a change log in here as there have been no comments for the 
> last 3 patch sets I sent.
> 
> This v4 squashes a few bugs I found during testing across all the files.

OK, after a very busy week I will try to find time for the review...
finally.

Thanks,

Wolfgang.

Re: [RFC PATCH 1/3] can: m_can: Create m_can core to leverage common code

2019-01-11 Thread Wolfgang Grandegger

Hello Dan,

Am 10.01.19 um 13:53 schrieb Dan Murphy:
> Wolfgang
> 
> On 1/10/19 1:44 AM, Wolfgang Grandegger wrote:
>> Hello Dan,
>>
>> sorry for my late response on that topic...
>>
>> Am 09.01.19 um 21:58 schrieb Dan Murphy:
>>> Wolfgang
>>>
>>> On 11/3/18 5:45 AM, Wolfgang Grandegger wrote:
>>>> Hello Dan,
>>>>
>>>> Am 31.10.2018 um 21:15 schrieb Dan Murphy:
>>>>> Wolfgang
>>>>>
>>>>> Thanks for the review
>>>>>
>>>>> On 10/27/2018 09:19 AM, Wolfgang Grandegger wrote:
>>>>>> Hello Dan,
>>>>>>
>>>>>> for the RFC, could you please just do the necessary changes to the
>>>>>> existing code. We can discuss about better names, etc. later. For
>>>>>> the review if the common code I quickly did:
>>>>>>
>>>>>>   mv m_can.c m_can_platform.c
>>>>>>   mv m_can_core.c m_can.c
>>>>>>
>>>>>> The file names are similar to what we have for the C_CAN driver.
>>>>>>
>>>>>>   s/classdev/priv/
>>>>>>   variable name s/m_can_dev/priv/
>>>>>>
>>>>>> Then your patch 1/3 looks as shown below. I'm going to comment on that
>>>>>> one. The comments start with "***"
>>>>>>
>>>>>
>>>>> So you would like me to align the names with the c_can driver?
>>>>
>>>> That would be the obvious choice.
>>>>> 
>>>>>>
>>>>>> *** I didn't review the rest of the patch for now.
>>>>>>
>>>>>
>>>>> snipped the code to reply to the comment.
>>>>>
>>>>>> Looking to the generic code, you didn't really change the way
>>>>>> the driver is accessing the registers. Also the interrupt handling
>>>>>> and rx polling is as it was before. Does that work properly using
>>>>>> the SPI interface of the TCAN4x5x?
>>>>>
>>>>> I don't want to change any of that yet.  Maybe my cover letter was not 
>>>>> clear
>>>>> or did not go through.
>>>>>
>>>>> But the intention was just to break out the functionality to create a 
>>>>> MCAN framework
>>>>> that can be used by devices that contain the Bosch MCAN core and provider 
>>>>> their own protocal to access
>>>>> the registers in the device.
>>>>>
>>>>> I don't want to do any functional changes at this time on the IP code 
>>>>> itself until we have a framework.
>>>>> There should be no regression in the io mapped code.
>>>>>
>>>>> I did comment on the interrupt handling and asked if a threaded work 
>>>>> queue would affect CAN timing.
>>>>> For the original TCAN driver this was the way it was implemented.
>>>>
>>>> Do threaded interrupts with RX polling make sense? I think we need a
>>>> common interface allowing to select hard-irqs+napi or threaded-irqs.
>>>>
>>>
>>> I have been working on this code for about a month now and I am *not happy* 
>>> with the amount of change that needs
>>> to be done to make the m_can a framework.
>>>
>>> I can tx/rx frames from another CAN device to the TCAN part but I have not 
>>> even touched the iomapped code.
>>>
>>> The challenging part is that the m_can code that is currently available 
>>> does not have to worry about atomic context because
>>> there is no peripheral waiting.  Since the TCAN is a peripheral device we 
>>> need to take into about the hard waits in IRQ context
>>> as well as the atomic context.  Doing this creates many deltas in the base 
>>> code that may break iomapped devices.  I have had to 
>>> add the thread_irqs and now I am in the midst of the issue you brought up 
>>> with napi.  I would have to schedule a queue for perp devices
>>> and leave the non-threaded iomapped irq.
>>>
>>> At this point I think it may be wise to leave the m_can code alone as it is 
>>> working and stable and just work on the TCAN driver as
>>> a standalone driver.  A framework would be nice but I think it would 
>>> destablize the m_can driver which is embedded in many SoC's and
>>> we cannot possibly test everyone of them.
>>
>> Unfortunately, I do not have m_can hardware at hand.
>>
>>> What are your thoughts?
>>
>> What we need is a common set of functions doing tx, rx, error and state
>> handling. This will requires substantial changes to the existing
>> io-mapped m_can driver, of course. I still believe it's worth the
>> effort, but I agree that it's difficult for you to re-write and test the
>> existing m_can driver.
> 
> OK I will keep working on it.  What you are describing is what I have done.
> I have abstracted the register reads and writes away and I am in the process
> of abstracting away the device specific initialization.

Would be nice if you could show your current implementation...

>>
>> What about implementing such a set of common functions plus the SPI
>> specific part for your TCAN device. What do you/others think?
> 
> As stated above this is what I have.  But the m_can driver was written for 
> io-mapped that has no delays
> so we need to take into about peripheral wait time in IRQ and atomic context.
> 
> This is where the issues are stemming from mainly in the atomic context.

... to understand a bit better what you exactly mean. Or does the last
patch you sent already highlight them.

Wolfgang.

Re: [RFC PATCH 1/3] can: m_can: Create m_can core to leverage common code

2019-01-09 Thread Wolfgang Grandegger

Hello Dan,

sorry for my late response on that topic...

Am 09.01.19 um 21:58 schrieb Dan Murphy:
> Wolfgang
> 
> On 11/3/18 5:45 AM, Wolfgang Grandegger wrote:
>> Hello Dan,
>>
>> Am 31.10.2018 um 21:15 schrieb Dan Murphy:
>>> Wolfgang
>>>
>>> Thanks for the review
>>>
>>> On 10/27/2018 09:19 AM, Wolfgang Grandegger wrote:
>>>> Hello Dan,
>>>>
>>>> for the RFC, could you please just do the necessary changes to the
>>>> existing code. We can discuss about better names, etc. later. For
>>>> the review if the common code I quickly did:
>>>>
>>>>   mv m_can.c m_can_platform.c
>>>>   mv m_can_core.c m_can.c
>>>>
>>>> The file names are similar to what we have for the C_CAN driver.
>>>>
>>>>   s/classdev/priv/
>>>>   variable name s/m_can_dev/priv/
>>>>
>>>> Then your patch 1/3 looks as shown below. I'm going to comment on that
>>>> one. The comments start with "***"
>>>>
>>>
>>> So you would like me to align the names with the c_can driver?
>>
>> That would be the obvious choice.
>>> 
>>>>
>>>> *** I didn't review the rest of the patch for now.
>>>>
>>>
>>> snipped the code to reply to the comment.
>>>
>>>> Looking to the generic code, you didn't really change the way
>>>> the driver is accessing the registers. Also the interrupt handling
>>>> and rx polling is as it was before. Does that work properly using
>>>> the SPI interface of the TCAN4x5x?
>>>
>>> I don't want to change any of that yet.  Maybe my cover letter was not clear
>>> or did not go through.
>>>
>>> But the intention was just to break out the functionality to create a MCAN 
>>> framework
>>> that can be used by devices that contain the Bosch MCAN core and provider 
>>> their own protocal to access
>>> the registers in the device.
>>>
>>> I don't want to do any functional changes at this time on the IP code 
>>> itself until we have a framework.
>>> There should be no regression in the io mapped code.
>>>
>>> I did comment on the interrupt handling and asked if a threaded work queue 
>>> would affect CAN timing.
>>> For the original TCAN driver this was the way it was implemented.
>>
>> Do threaded interrupts with RX polling make sense? I think we need a
>> common interface allowing to select hard-irqs+napi or threaded-irqs.
>>
> 
> I have been working on this code for about a month now and I am *not happy* 
> with the amount of change that needs
> to be done to make the m_can a framework.
> 
> I can tx/rx frames from another CAN device to the TCAN part but I have not 
> even touched the iomapped code.
> 
> The challenging part is that the m_can code that is currently available does 
> not have to worry about atomic context because
> there is no peripheral waiting.  Since the TCAN is a peripheral device we 
> need to take into about the hard waits in IRQ context
> as well as the atomic context.  Doing this creates many deltas in the base 
> code that may break iomapped devices.  I have had to 
> add the thread_irqs and now I am in the midst of the issue you brought up 
> with napi.  I would have to schedule a queue for perp devices
> and leave the non-threaded iomapped irq.
> 
> At this point I think it may be wise to leave the m_can code alone as it is 
> working and stable and just work on the TCAN driver as
> a standalone driver.  A framework would be nice but I think it would 
> destablize the m_can driver which is embedded in many SoC's and
> we cannot possibly test everyone of them.

Unfortunately, I do not have m_can hardware at hand.

> What are your thoughts?

What we need is a common set of functions doing tx, rx, error and state
handling. This will requires substantial changes to the existing
io-mapped m_can driver, of course. I still believe it's worth the
effort, but I agree that it's difficult for you to re-write and test the
existing m_can driver.

What about implementing such a set of common functions plus the SPI
specific part for your TCAN device. What do you/others think?

Wolfgang.

Re: [PATCH v4 1/1] can: ucan: add driver for Theobroma Systems UCAN devices

2018-04-08 Thread Wolfgang Grandegger

; +}
> +
> +/* Callback on reception of a can frame via the IN endpoint
> + *
> + * This function allocates an skb and transferres it to the Linux
> + * network stack
> + */
> +static void ucan_rx_can_msg(struct ucan_priv *up, struct ucan_message_in *m)
> +{
> + int len;
> + canid_t canid;
> + struct can_frame *cf;
> + struct sk_buff *skb;
> + struct net_device_stats *stats = >netdev->stats;
> +
> + /* get the contents of the length field */
> + len = le16_to_cpu(m->len);
> +
> + /* check sanity */
> + if (len < UCAN_IN_HDR_SIZE + sizeof(m->msg.can_msg.id)) {
> + netdev_warn(up->netdev, "invalid input message len: %d\n", len);
> + return;
> + }
> +
> + /* handle error frames */
> + canid = le32_to_cpu(m->msg.can_msg.id);
> + if (canid & CAN_ERR_FLAG) {
> + bool busstate_changed = ucan_handle_error_frame(up, m, canid);
> +
> + /* if berr-reporting is off only state changes get through */
> + if (!(up->can.ctrlmode & CAN_CTRLMODE_BERR_REPORTING) &&
> + !busstate_changed)
> + return;
> + } else {
> + canid_t canid_mask;
> + /* compute the mask for canid */
> + canid_mask = CAN_RTR_FLAG;
> + if (canid & CAN_EFF_FLAG)
> + canid_mask |= CAN_EFF_MASK | CAN_EFF_FLAG;
> + else
> + canid_mask |= CAN_SFF_MASK;
> +
> + if (canid & ~canid_mask)
> + netdev_warn(up->netdev,
> +     "masking unexpected set bits in canid 
> (canid %x, mask %x)",

Line too long... there are a few more lines exceeding 80 chars.

> + canid, canid_mask);
> +
> + canid &= canid_mask;
> + }
> +
> + /* allocate skb */
> + skb = alloc_can_skb(up->netdev, );
> + if (!skb)
> + return;
> +
> + /* fill the can frame */
> + cf->can_id = canid;
> +
> + /* compute DLC taking RTR_FLAG into account */
> + cf->can_dlc = ucan_get_can_dlc(>msg.can_msg, len);
> +
> + /* copy the payload of non RTR frames */
> + if (!(cf->can_id & CAN_RTR_FLAG) || (cf->can_id & CAN_ERR_FLAG))
> + memcpy(cf->data, m->msg.can_msg.data, cf->can_dlc);
> +
> + /* don't count error frames as real packets */
> + stats->rx_packets++;
> + stats->rx_bytes += cf->can_dlc;
> +
> + /* pass it to Linux */
> + netif_rx(skb);
> +}

[...snip...]

You may also want to replace

it (ret)
goto err;

with

return ret;

in "ucan_open()" and  "ucan_probe()".

You can then add my:

  Acked-by: Wolfgang Grandegger <w...@grandegger.com>

Thanks for your contribution!

Wolfgang.

Re: [PATCH v4 1/1] can: ucan: add driver for Theobroma Systems UCAN devices

2018-04-08 Thread Wolfgang Grandegger

n skb and transferres it to the Linux
> + * network stack
> + */
> +static void ucan_rx_can_msg(struct ucan_priv *up, struct ucan_message_in *m)
> +{
> + int len;
> + canid_t canid;
> + struct can_frame *cf;
> + struct sk_buff *skb;
> + struct net_device_stats *stats = >netdev->stats;
> +
> + /* get the contents of the length field */
> + len = le16_to_cpu(m->len);
> +
> + /* check sanity */
> + if (len < UCAN_IN_HDR_SIZE + sizeof(m->msg.can_msg.id)) {
> + netdev_warn(up->netdev, "invalid input message len: %d\n", len);
> + return;
> + }
> +
> + /* handle error frames */
> + canid = le32_to_cpu(m->msg.can_msg.id);
> + if (canid & CAN_ERR_FLAG) {
> + bool busstate_changed = ucan_handle_error_frame(up, m, canid);
> +
> + /* if berr-reporting is off only state changes get through */
> + if (!(up->can.ctrlmode & CAN_CTRLMODE_BERR_REPORTING) &&
> + !busstate_changed)
> + return;
> + } else {
> + canid_t canid_mask;
> + /* compute the mask for canid */
> + canid_mask = CAN_RTR_FLAG;
> + if (canid & CAN_EFF_FLAG)
> + canid_mask |= CAN_EFF_MASK | CAN_EFF_FLAG;
> + else
> + canid_mask |= CAN_SFF_MASK;
> +
> + if (canid & ~canid_mask)
> + netdev_warn(up->netdev,
> +     "masking unexpected set bits in canid 
> (canid %x, mask %x)",

Line too long... there are a few more lines exceeding 80 chars.

> + canid, canid_mask);
> +
> + canid &= canid_mask;
> + }
> +
> + /* allocate skb */
> + skb = alloc_can_skb(up->netdev, );
> + if (!skb)
> + return;
> +
> + /* fill the can frame */
> + cf->can_id = canid;
> +
> + /* compute DLC taking RTR_FLAG into account */
> + cf->can_dlc = ucan_get_can_dlc(>msg.can_msg, len);
> +
> + /* copy the payload of non RTR frames */
> + if (!(cf->can_id & CAN_RTR_FLAG) || (cf->can_id & CAN_ERR_FLAG))
> + memcpy(cf->data, m->msg.can_msg.data, cf->can_dlc);
> +
> + /* don't count error frames as real packets */
> + stats->rx_packets++;
> + stats->rx_bytes += cf->can_dlc;
> +
> + /* pass it to Linux */
> + netif_rx(skb);
> +}

[...snip...]

You may also want to replace

it (ret)
goto err;

with

return ret;

in "ucan_open()" and  "ucan_probe()".

You can then add my:

  Acked-by: Wolfgang Grandegger 

Thanks for your contribution!

Wolfgang.

Re: [PATCH v3 0/1] can: ucan: add driver for Theobroma Systems UCAN devices



Am 23.03.2018 um 10:40 schrieb Jakob Unterwurzacher:
> On 23.03.18 09:32, Wolfgang Grandegger wrote:
>>> * add __func__ to all errors and warnings, and to info where it made
>>> sense
>>
>> The final output messages in the driver should especially be useful for
>> the end user... and not the developer! This is also true for the
>> function names. You already use more "__func__" than all other CAN
>> drivers together. Just my opinion!
> 
> The idea was to make it clear which driver printed the message. In my
> opinion, this is a problem:
> 
>> drivers/net/can/usb$ git grep "No memory left for USB buffer"
>> ems_usb.c:  netdev_err(netdev, "No memory left for
>> USB buffer\n");
>> ems_usb.c:  netdev_err(netdev, "No memory left for USB
>> buffer\n");
>> esd_usb2.c:  "No memory left for USB
>> buffer\n");
>> esd_usb2.c: netdev_err(netdev, "No memory left for USB
>> buffer\n");
>> gs_usb.c:   netdev_err(netdev, "No memory left for USB
>> buffer\n");
>> gs_usb.c:  "No memory left for
>> USB buffer\n");
>> kvaser_usb.c:    "No memory left for USB
>> buffer\n");
>> mcba_usb.c: netdev_err(netdev, "No memory left for
>> USB buffer\n");
>> usb_8dev.c: netdev_err(netdev, "No memory left for USB
>> buffer\n");
>> usb_8dev.c: netdev_err(netdev, "No memory left for
>> USB buffer\n");

> But I'm open to other suggestions (use a fixed "ucan: " prefix?) or to
> drop it entirely if you think it is not worth it.

But there is already a device prefix, e.g.:

  peak_usb 1-6:1.0: PEAK-System PCAN-USB adapter hwrev 28 serial  (1 
channel)
  peak_usb 1-6:1.0 can0: attached to PCAN-USB channel 0 (device 255)
  

No need to add another one!

Wolfgang.

Re: [PATCH v3 0/1] can: ucan: add driver for Theobroma Systems UCAN devices



Am 23.03.2018 um 10:40 schrieb Jakob Unterwurzacher:
> On 23.03.18 09:32, Wolfgang Grandegger wrote:
>>> * add __func__ to all errors and warnings, and to info where it made
>>> sense
>>
>> The final output messages in the driver should especially be useful for
>> the end user... and not the developer! This is also true for the
>> function names. You already use more "__func__" than all other CAN
>> drivers together. Just my opinion!
> 
> The idea was to make it clear which driver printed the message. In my
> opinion, this is a problem:
> 
>> drivers/net/can/usb$ git grep "No memory left for USB buffer"
>> ems_usb.c:  netdev_err(netdev, "No memory left for
>> USB buffer\n");
>> ems_usb.c:  netdev_err(netdev, "No memory left for USB
>> buffer\n");
>> esd_usb2.c:  "No memory left for USB
>> buffer\n");
>> esd_usb2.c: netdev_err(netdev, "No memory left for USB
>> buffer\n");
>> gs_usb.c:   netdev_err(netdev, "No memory left for USB
>> buffer\n");
>> gs_usb.c:  "No memory left for
>> USB buffer\n");
>> kvaser_usb.c:    "No memory left for USB
>> buffer\n");
>> mcba_usb.c: netdev_err(netdev, "No memory left for
>> USB buffer\n");
>> usb_8dev.c: netdev_err(netdev, "No memory left for USB
>> buffer\n");
>> usb_8dev.c: netdev_err(netdev, "No memory left for
>> USB buffer\n");

> But I'm open to other suggestions (use a fixed "ucan: " prefix?) or to
> drop it entirely if you think it is not worth it.

But there is already a device prefix, e.g.:

  peak_usb 1-6:1.0: PEAK-System PCAN-USB adapter hwrev 28 serial  (1 
channel)
  peak_usb 1-6:1.0 can0: attached to PCAN-USB channel 0 (device 255)
  

No need to add another one!

Wolfgang.

Re: [PATCH v3 1/1] can: ucan: add driver for Theobroma Systems UCAN devices


Am 22.03.2018 um 14:53 schrieb Jakob Unterwurzacher:
> The UCAN driver supports the microcontroller-based USB/CAN
> adapters from Theobroma Systems. There are two form-factors
> that run essentially the same firmware:
> 
> * Seal: standalone USB stick ( https://www.theobroma-systems.com/seal )
> 
> * Mule: integrated on the PCB of various System-on-Modules from
>   Theobroma Systems like the A31-µQ7 and the RK3399-Q7
>   ( https://www.theobroma-systems.com/rk3399-q7 )
> 
> The USB wire protocol has been designed to be as generic and
> hardware-indendent as possible in the hope of being useful for
> implementation on other microcontrollers.
> 
> Signed-off-by: Martin Elshuber 
> Signed-off-by: Jakob Unterwurzacher 
> 
> Signed-off-by: Philipp Tomsich 
> ---
>  Documentation/networking/can_ucan_protocol.rst |  315 +
>  Documentation/networking/index.rst |1 +
>  drivers/net/can/usb/Kconfig|   10 +
>  drivers/net/can/usb/Makefile   |1 +
>  drivers/net/can/usb/ucan.c | 1628 
> 
>  5 files changed, 1955 insertions(+)
>  create mode 100644 Documentation/networking/can_ucan_protocol.rst
>  create mode 100644 drivers/net/can/usb/ucan.c

> 

[...snip...]

> diff --git a/drivers/net/can/usb/ucan.c b/drivers/net/can/usb/ucan.c
> new file mode 100644
> index ..5a98ef5d95da
> --- /dev/null
> +++ b/drivers/net/can/usb/ucan.c

[...snip...]

> +static void ucan_rx_can_msg(struct ucan_priv *up, struct ucan_message_in *m)
> +{
> + int len;
> + canid_t canid, canid_mask;
> + struct can_frame *cf;
> + struct sk_buff *skb;
> + struct net_device_stats *stats = >netdev->stats;
> +
> + /* get the contents of the length field */
> + len = le16_to_cpu(m->len);
> +
> + /* check sanity */
> + if (len < UCAN_IN_HDR_SIZE + sizeof(m->msg.can_msg.id)) {
> + dev_warn(>udev->dev,
> +  "%s: invalid input message len: %d\n", __func__, len);
> + return;
> + }
> +
> + /* handle error frames */
> + canid = le32_to_cpu(m->msg.can_msg.id);
> + if (canid & CAN_ERR_FLAG) {
> + bool busstate_changed = ucan_handle_error_frame(up, m, canid);
> + /* if berr-reporting is off only state changes get through */
> + if (!(up->can.ctrlmode & CAN_CTRLMODE_BERR_REPORTING) &&
> + !busstate_changed)
> + return;
> + }
> +
> + /* allocate skb */
> + skb = alloc_can_skb(up->netdev, );
> + if (!skb)
> + return;
> +
> + /* compute the mask for canid */
> + canid_mask = CAN_RTR_FLAG | CAN_ERR_FLAG;
> + if (canid & CAN_EFF_FLAG)
> + canid_mask |= CAN_EFF_MASK | CAN_EFF_FLAG;
> + else
> + canid_mask |= CAN_SFF_MASK;

You do not want that for error frames... or have I missed something?

> + /* fill the can frame */
> + cf->can_id = canid & canid_mask;
> +
> + /* compute DLC taking RTR_FLAG into account */
> + cf->can_dlc = ucan_get_can_dlc(>msg.can_msg, len);
> +
> + /* copy the payload of non RTR frames */
> + if (!(cf->can_id & CAN_RTR_FLAG))
> + memcpy(cf->data, m->msg.can_msg.data, cf->can_dlc);

Ditto.

> + /* don't count error frames as real packets */
> + stats->rx_packets++;
> + stats->rx_bytes += cf->can_dlc;
> +
> + /* pass it to Linux */
> + netif_rx(skb);
> +}
> +
> +/* callback indicating completed transmission */
> +static void ucan_tx_complete_msg(struct ucan_priv *up,
> +  struct ucan_message_in *m)
> +{
> + u16 count, i;
> + u8 echo_index, dlc;
> + u16 len = le16_to_cpu(m->len);
> +
> + struct ucan_urb_context *context;
> +
> + if (len < UCAN_IN_HDR_SIZE || (len % 2 != 0)) {
> + dev_err(>udev->dev,
> + "%s: invalid tx complete length\n",
> + __func__);
> + return;
> + }
> +
> + count = (len - UCAN_IN_HDR_SIZE) / 2;
> + for (i = 0; i < count; i++) {
> + /* we did not submit such echo ids */
> + echo_index = m->msg.can_tx_complete_msg[i].echo_index;
> + if (echo_index >= up->device_info.tx_fifo) {
> + up->netdev->stats.tx_errors++;
> + dev_err(>udev->dev,
> + "%s: device answered with invalid echo_index\n",
> + __func__);
> + continue;
> + }
> +
> + /* gather information from the context */
> + context = >context_array[echo_index];
> + dlc = READ_ONCE(context->dlc);
> +
> + /* Release context and restart queue if necessary.
> +  * Also check if the context was allocated
> +  */
> +

Re: [PATCH v3 1/1] can: ucan: add driver for Theobroma Systems UCAN devices


Am 22.03.2018 um 14:53 schrieb Jakob Unterwurzacher:
> The UCAN driver supports the microcontroller-based USB/CAN
> adapters from Theobroma Systems. There are two form-factors
> that run essentially the same firmware:
> 
> * Seal: standalone USB stick ( https://www.theobroma-systems.com/seal )
> 
> * Mule: integrated on the PCB of various System-on-Modules from
>   Theobroma Systems like the A31-µQ7 and the RK3399-Q7
>   ( https://www.theobroma-systems.com/rk3399-q7 )
> 
> The USB wire protocol has been designed to be as generic and
> hardware-indendent as possible in the hope of being useful for
> implementation on other microcontrollers.
> 
> Signed-off-by: Martin Elshuber 
> Signed-off-by: Jakob Unterwurzacher 
> 
> Signed-off-by: Philipp Tomsich 
> ---
>  Documentation/networking/can_ucan_protocol.rst |  315 +
>  Documentation/networking/index.rst |1 +
>  drivers/net/can/usb/Kconfig|   10 +
>  drivers/net/can/usb/Makefile   |1 +
>  drivers/net/can/usb/ucan.c | 1628 
> 
>  5 files changed, 1955 insertions(+)
>  create mode 100644 Documentation/networking/can_ucan_protocol.rst
>  create mode 100644 drivers/net/can/usb/ucan.c

> 

[...snip...]

> diff --git a/drivers/net/can/usb/ucan.c b/drivers/net/can/usb/ucan.c
> new file mode 100644
> index ..5a98ef5d95da
> --- /dev/null
> +++ b/drivers/net/can/usb/ucan.c

[...snip...]

> +static void ucan_rx_can_msg(struct ucan_priv *up, struct ucan_message_in *m)
> +{
> + int len;
> + canid_t canid, canid_mask;
> + struct can_frame *cf;
> + struct sk_buff *skb;
> + struct net_device_stats *stats = >netdev->stats;
> +
> + /* get the contents of the length field */
> + len = le16_to_cpu(m->len);
> +
> + /* check sanity */
> + if (len < UCAN_IN_HDR_SIZE + sizeof(m->msg.can_msg.id)) {
> + dev_warn(>udev->dev,
> +  "%s: invalid input message len: %d\n", __func__, len);
> + return;
> + }
> +
> + /* handle error frames */
> + canid = le32_to_cpu(m->msg.can_msg.id);
> + if (canid & CAN_ERR_FLAG) {
> + bool busstate_changed = ucan_handle_error_frame(up, m, canid);
> + /* if berr-reporting is off only state changes get through */
> + if (!(up->can.ctrlmode & CAN_CTRLMODE_BERR_REPORTING) &&
> + !busstate_changed)
> + return;
> + }
> +
> + /* allocate skb */
> + skb = alloc_can_skb(up->netdev, );
> + if (!skb)
> + return;
> +
> + /* compute the mask for canid */
> + canid_mask = CAN_RTR_FLAG | CAN_ERR_FLAG;
> + if (canid & CAN_EFF_FLAG)
> + canid_mask |= CAN_EFF_MASK | CAN_EFF_FLAG;
> + else
> + canid_mask |= CAN_SFF_MASK;

You do not want that for error frames... or have I missed something?

> + /* fill the can frame */
> + cf->can_id = canid & canid_mask;
> +
> + /* compute DLC taking RTR_FLAG into account */
> + cf->can_dlc = ucan_get_can_dlc(>msg.can_msg, len);
> +
> + /* copy the payload of non RTR frames */
> + if (!(cf->can_id & CAN_RTR_FLAG))
> + memcpy(cf->data, m->msg.can_msg.data, cf->can_dlc);

Ditto.

> + /* don't count error frames as real packets */
> + stats->rx_packets++;
> + stats->rx_bytes += cf->can_dlc;
> +
> + /* pass it to Linux */
> + netif_rx(skb);
> +}
> +
> +/* callback indicating completed transmission */
> +static void ucan_tx_complete_msg(struct ucan_priv *up,
> +  struct ucan_message_in *m)
> +{
> + u16 count, i;
> + u8 echo_index, dlc;
> + u16 len = le16_to_cpu(m->len);
> +
> + struct ucan_urb_context *context;
> +
> + if (len < UCAN_IN_HDR_SIZE || (len % 2 != 0)) {
> + dev_err(>udev->dev,
> + "%s: invalid tx complete length\n",
> + __func__);
> + return;
> + }
> +
> + count = (len - UCAN_IN_HDR_SIZE) / 2;
> + for (i = 0; i < count; i++) {
> + /* we did not submit such echo ids */
> + echo_index = m->msg.can_tx_complete_msg[i].echo_index;
> + if (echo_index >= up->device_info.tx_fifo) {
> + up->netdev->stats.tx_errors++;
> + dev_err(>udev->dev,
> + "%s: device answered with invalid echo_index\n",
> + __func__);
> + continue;
> + }
> +
> + /* gather information from the context */
> + context = >context_array[echo_index];
> + dlc = READ_ONCE(context->dlc);
> +
> + /* Release context and restart queue if necessary.
> +  * Also check if the context was allocated
> +  */
> + if (ucan_release_context(up, context))
> + continue;
> +
> + if

Re: [PATCH v3 0/1] can: ucan: add driver for Theobroma Systems UCAN devices

Hello Jacob,

Am 22.03.2018 um 14:53 schrieb Jakob Unterwurzacher:
> This is v3 of the Theobroma Systems CAN/USB adapter driver
> upstreaming effort.
> 
> Featured v2 -> v3 changes:
> * count error frames as data packets
> * use canid_t for all can ids
> * use BIT(x) instead of (1 << x)
> * use __le16 / __le32 for little-endian fields
> * add spinlock around context allocation (fixes a possible race)
> * fix comment style
> * use WARN_ON return value
> * fix state logic bug that did not allow return to ERROR_ACTIVE
> * drop echo_index from context_array (not needed)
> * rename "tx_contexts" -> "context_array" to prevent confusion
> * add __func__ to all errors and warnings, and to info where it made sense

The final output messages in the driver should especially be useful for
the end user... and not the developer! This is also true for the
function names. You already use more "__func__" than all other CAN
drivers together. Just my opinion!

> 
> Jakob Unterwurzacher (1):
>   can: ucan: add driver for Theobroma Systems UCAN devices
> 
>  Documentation/networking/can_ucan_protocol.rst |  315 +
>  Documentation/networking/index.rst |1 +
>  drivers/net/can/usb/Kconfig|   10 +
>  drivers/net/can/usb/Makefile   |1 +
>  drivers/net/can/usb/ucan.c | 1628 
> 
>  5 files changed, 1955 insertions(+)
>  create mode 100644 Documentation/networking/can_ucan_protocol.rst
>  create mode 100644 drivers/net/can/usb/ucan.c

Wolfgang.

Re: [PATCH v3 0/1] can: ucan: add driver for Theobroma Systems UCAN devices

Hello Jacob,

Am 22.03.2018 um 14:53 schrieb Jakob Unterwurzacher:
> This is v3 of the Theobroma Systems CAN/USB adapter driver
> upstreaming effort.
> 
> Featured v2 -> v3 changes:
> * count error frames as data packets
> * use canid_t for all can ids
> * use BIT(x) instead of (1 << x)
> * use __le16 / __le32 for little-endian fields
> * add spinlock around context allocation (fixes a possible race)
> * fix comment style
> * use WARN_ON return value
> * fix state logic bug that did not allow return to ERROR_ACTIVE
> * drop echo_index from context_array (not needed)
> * rename "tx_contexts" -> "context_array" to prevent confusion
> * add __func__ to all errors and warnings, and to info where it made sense

The final output messages in the driver should especially be useful for
the end user... and not the developer! This is also true for the
function names. You already use more "__func__" than all other CAN
drivers together. Just my opinion!

> 
> Jakob Unterwurzacher (1):
>   can: ucan: add driver for Theobroma Systems UCAN devices
> 
>  Documentation/networking/can_ucan_protocol.rst |  315 +
>  Documentation/networking/index.rst |1 +
>  drivers/net/can/usb/Kconfig|   10 +
>  drivers/net/can/usb/Makefile   |1 +
>  drivers/net/can/usb/ucan.c | 1628 
> 
>  5 files changed, 1955 insertions(+)
>  create mode 100644 Documentation/networking/can_ucan_protocol.rst
>  create mode 100644 drivers/net/can/usb/ucan.c

Wolfgang.

Re: [PATCH v2 1/1] can: ucan: add driver for Theobroma Systems UCAN devices

2018-03-15 Thread Wolfgang Grandegger




Am 14.03.2018 um 20:07 schrieb Jakob Unterwurzacher:

On 14.03.18 11:04, Wolfgang Grandegger wrote:
 (000.000443)  can0  2034   [8]  00 0C 00 00 00 00 78 00   
ERRORFRAME

    controller-problem{rx-error-warning,tx-error-warning}
    transceiver-status
    no-acknowledgement-on-tx
    error-counter-tx-rx{{120}{0}}
 (000.000444)  can0  2034   [8]  00 3C 00 00 00 00 80 00   
ERRORFRAME

controller-problem{rx-error-warning,tx-error-warning,rx-error-passive,tx-error-passive} 



Just,

   controller-problem{rx-error-passive,tx-error-passive} [...]

Back to error active is missing!?


That was indeed missing. We have fixed the missing back-to-error-active 
in our firmware.


Also, we no longer send the controller status in every error frame, but 
only on state changes (see below) which seems to be how other drivers 
are handling things.


Good, it would also be useful, if berr-reporting could be enabled by the 
firmware. This avoids a lot of traffic and load, especially if no cable 
is connected.


Wolfgang.

Re: [PATCH v2 1/1] can: ucan: add driver for Theobroma Systems UCAN devices

2018-03-15 Thread Wolfgang Grandegger




Am 14.03.2018 um 20:07 schrieb Jakob Unterwurzacher:

On 14.03.18 11:04, Wolfgang Grandegger wrote:
 (000.000443)  can0  2034   [8]  00 0C 00 00 00 00 78 00   
ERRORFRAME

    controller-problem{rx-error-warning,tx-error-warning}
    transceiver-status
    no-acknowledgement-on-tx
    error-counter-tx-rx{{120}{0}}
 (000.000444)  can0  2034   [8]  00 3C 00 00 00 00 80 00   
ERRORFRAME

controller-problem{rx-error-warning,tx-error-warning,rx-error-passive,tx-error-passive} 



Just,

   controller-problem{rx-error-passive,tx-error-passive} [...]

Back to error active is missing!?


That was indeed missing. We have fixed the missing back-to-error-active 
in our firmware.


Also, we no longer send the controller status in every error frame, but 
only on state changes (see below) which seems to be how other drivers 
are handling things.


Good, it would also be useful, if berr-reporting could be enabled by the 
firmware. This avoids a lot of traffic and load, especially if no cable 
is connected.


Wolfgang.

Re: [PATCH v2 1/1] can: ucan: add driver for Theobroma Systems UCAN devices

Hello Jakob,

Am 14.03.2018 um 10:48 schrieb Jakob Unterwurzacher:
> On 14.03.18 10:25, Wolfgang Grandegger wrote:
>>> Counting the state changes is one thing but you should also generate 
>>> error messages for them.
>>
>> The usual test here is:
>>
>> $ candump -td -e any,0:0,#
>>
>> should report proper state changes, if you send messages with
>>
>> 1. no cable connected
>> 2. CAN high and low short-circuited
>>
>> Also downwards if the hardware error is gone and you continue to send 
>> messages.
> Yes, we do, the hardware does it. Testcases:
> 
> (1) no cable connected
> 
>> root@rk3399-q7:~# candump -td -e any,0:0,# | head -n 1000
>>  (000.00)  can0  178   [0]
>>  (000.000410)  can0  2030   [8]  00 00 00 00 00 00 08 00   ERRORFRAME
>> transceiver-status
>> no-acknowledgement-on-tx
>> error-counter-tx-rx{{8}{0}}
>>  (000.000445)  can0  2030   [8]  00 00 00 00 00 00 10 00   ERRORFRAME
>> transceiver-status
>> no-acknowledgement-on-tx
>> error-counter-tx-rx{{16}{0}}
>>  (000.000425)  can0  2030   [8]  00 00 00 00 00 00 18 00   ERRORFRAME
>> transceiver-status
>> no-acknowledgement-on-tx
>> error-counter-tx-rx{{24}{0}}
>>  (000.000451)  can0  2030   [8]  00 00 00 00 00 00 20 00   ERRORFRAME
>> transceiver-status
>> no-acknowledgement-on-tx
>> error-counter-tx-rx{{32}{0}}
>>  (000.000429)  can0  2030   [8]  00 00 00 00 00 00 28 00   ERRORFRAME
>> transceiver-status
>> no-acknowledgement-on-tx
>> error-counter-tx-rx{{40}{0}}
>>  (000.000448)  can0  2030   [8]  00 00 00 00 00 00 30 00   ERRORFRAME
>> transceiver-status
>> no-acknowledgement-on-tx
>> error-counter-tx-rx{{48}{0}}
>>  (000.000433)  can0  2030   [8]  00 00 00 00 00 00 38 00   ERRORFRAME
>> transceiver-status
>> no-acknowledgement-on-tx
>> error-counter-tx-rx{{56}{0}}
>>  (000.000437)  can0  2030   [8]  00 00 00 00 00 00 40 00   ERRORFRAME
>> transceiver-status
>> no-acknowledgement-on-tx
>> error-counter-tx-rx{{64}{0}}
>>  (000.000443)  can0  2030   [8]  00 00 00 00 00 00 48 00   ERRORFRAME
>> transceiver-status
>> no-acknowledgement-on-tx
>> error-counter-tx-rx{{72}{0}}
>>  (000.000437)  can0  2030   [8]  00 00 00 00 00 00 50 00   ERRORFRAME
>> transceiver-status
>> no-acknowledgement-on-tx
>> error-counter-tx-rx{{80}{0}}
>>  (000.000498)  can0  2030   [8]  00 00 00 00 00 00 58 00   ERRORFRAME
>> transceiver-status
>> no-acknowledgement-on-tx
>> error-counter-tx-rx{{88}{0}}
>>  (000.000394)  can0  2034   [8]  00 0C 00 00 00 00 60 00   ERRORFRAME
>> controller-problem{rx-error-warning,tx-error-warning}
>> transceiver-status
>> no-acknowledgement-on-tx
>> error-counter-tx-rx{{96}{0}}
>>  (000.000433)  can0  2034   [8]  00 0C 00 00 00 00 68 00   ERRORFRAME
>> controller-problem{rx-error-warning,tx-error-warning}
>> transceiver-status
>> no-acknowledgement-on-tx
>> error-counter-tx-rx{{104}{0}}
>>  (000.000437)  can0  2034   [8]  00 0C 00 00 00 00 70 00   ERRORFRAME
>> controller-problem{rx-error-warning,tx-error-warning}
>> transceiver-status
>> no-acknowledgement-on-tx
>> error-counter-tx-rx{{112}{0}}
>>  (000.000443)  can0  2034   [8]  00 0C 00 00 00 00 78 00   ERRORFRAME
>> controller-problem{rx-error-warning,tx-error-warning}
>> transceiver-status
>> no-acknowledgement-on-tx
>> error-counter-tx-rx{{120}{0}}
>>  (000.000444)  can0  2034   [8]  00 3C 00 00 00 00 80 00   ERRORFRAME
>> 
>> controller-problem{rx-error-warning,tx-error-warning,rx-error-passive,tx-error-passive}
>>  

Just,

   controller-problem{rx-error-passive,tx-error-passive} 

>>
>> transceiver-status
>> no-acknowledgement-on-tx
>> error-counter-tx-rx{{128}{0}}
>>  (000.000495)  can0  2024   [8]  00 3C 00 00 00 00 80 00   ERRORFRAME
>> 
>> controller-problem{rx-error-warning,tx-error-warning,rx-error-passive,tx-error-passive}
>>  
>>
>> no-acknowledgement-on-tx
>> error-counter-tx-rx{{128}{0}}
> 
> Repeats ad infinitum...

Good! And without "berr-reporting" just the state changes should show up.

> 
> 
> (1b) cable gets connected:
> 
>>  (000.000883)  can0  2034   [8]  00 3C 00 00 00 00 80 00   ERRORFRAME
>> 
>> controller-problem{rx-error-warning,tx-error-warning,rx-error-passive,tx-error-passive}
>>  
>>
>> transceiver-status
>> no-acknowledgement-on-tx
>> error-counter-tx-rx{{128}{0}}
>>  (000.000996)  can0  2004   [8]  00 0C 00 00 00 00 7F 00   ERRORFRAME
>> controller-problem{rx-error-warning,tx-error-warning}
>> error-counter-tx-rx{{127}{0}}

Back to error active is missing!? Have a look to:

https://elixir.bootlin.com/linux/latest/source/drivers/net/can/dev.c#L364

Wolfgang.

Re: [PATCH v2 1/1] can: ucan: add driver for Theobroma Systems UCAN devices

Hello Jakob,

Am 14.03.2018 um 10:48 schrieb Jakob Unterwurzacher:
> On 14.03.18 10:25, Wolfgang Grandegger wrote:
>>> Counting the state changes is one thing but you should also generate 
>>> error messages for them.
>>
>> The usual test here is:
>>
>> $ candump -td -e any,0:0,#
>>
>> should report proper state changes, if you send messages with
>>
>> 1. no cable connected
>> 2. CAN high and low short-circuited
>>
>> Also downwards if the hardware error is gone and you continue to send 
>> messages.
> Yes, we do, the hardware does it. Testcases:
> 
> (1) no cable connected
> 
>> root@rk3399-q7:~# candump -td -e any,0:0,# | head -n 1000
>>  (000.00)  can0  178   [0]
>>  (000.000410)  can0  2030   [8]  00 00 00 00 00 00 08 00   ERRORFRAME
>> transceiver-status
>> no-acknowledgement-on-tx
>> error-counter-tx-rx{{8}{0}}
>>  (000.000445)  can0  2030   [8]  00 00 00 00 00 00 10 00   ERRORFRAME
>> transceiver-status
>> no-acknowledgement-on-tx
>> error-counter-tx-rx{{16}{0}}
>>  (000.000425)  can0  2030   [8]  00 00 00 00 00 00 18 00   ERRORFRAME
>> transceiver-status
>> no-acknowledgement-on-tx
>> error-counter-tx-rx{{24}{0}}
>>  (000.000451)  can0  2030   [8]  00 00 00 00 00 00 20 00   ERRORFRAME
>> transceiver-status
>> no-acknowledgement-on-tx
>> error-counter-tx-rx{{32}{0}}
>>  (000.000429)  can0  2030   [8]  00 00 00 00 00 00 28 00   ERRORFRAME
>> transceiver-status
>> no-acknowledgement-on-tx
>> error-counter-tx-rx{{40}{0}}
>>  (000.000448)  can0  2030   [8]  00 00 00 00 00 00 30 00   ERRORFRAME
>> transceiver-status
>> no-acknowledgement-on-tx
>> error-counter-tx-rx{{48}{0}}
>>  (000.000433)  can0  2030   [8]  00 00 00 00 00 00 38 00   ERRORFRAME
>> transceiver-status
>> no-acknowledgement-on-tx
>> error-counter-tx-rx{{56}{0}}
>>  (000.000437)  can0  2030   [8]  00 00 00 00 00 00 40 00   ERRORFRAME
>> transceiver-status
>> no-acknowledgement-on-tx
>> error-counter-tx-rx{{64}{0}}
>>  (000.000443)  can0  2030   [8]  00 00 00 00 00 00 48 00   ERRORFRAME
>> transceiver-status
>> no-acknowledgement-on-tx
>> error-counter-tx-rx{{72}{0}}
>>  (000.000437)  can0  2030   [8]  00 00 00 00 00 00 50 00   ERRORFRAME
>> transceiver-status
>> no-acknowledgement-on-tx
>> error-counter-tx-rx{{80}{0}}
>>  (000.000498)  can0  2030   [8]  00 00 00 00 00 00 58 00   ERRORFRAME
>> transceiver-status
>> no-acknowledgement-on-tx
>> error-counter-tx-rx{{88}{0}}
>>  (000.000394)  can0  2034   [8]  00 0C 00 00 00 00 60 00   ERRORFRAME
>> controller-problem{rx-error-warning,tx-error-warning}
>> transceiver-status
>> no-acknowledgement-on-tx
>> error-counter-tx-rx{{96}{0}}
>>  (000.000433)  can0  2034   [8]  00 0C 00 00 00 00 68 00   ERRORFRAME
>> controller-problem{rx-error-warning,tx-error-warning}
>> transceiver-status
>> no-acknowledgement-on-tx
>> error-counter-tx-rx{{104}{0}}
>>  (000.000437)  can0  2034   [8]  00 0C 00 00 00 00 70 00   ERRORFRAME
>> controller-problem{rx-error-warning,tx-error-warning}
>> transceiver-status
>> no-acknowledgement-on-tx
>> error-counter-tx-rx{{112}{0}}
>>  (000.000443)  can0  2034   [8]  00 0C 00 00 00 00 78 00   ERRORFRAME
>> controller-problem{rx-error-warning,tx-error-warning}
>> transceiver-status
>> no-acknowledgement-on-tx
>> error-counter-tx-rx{{120}{0}}
>>  (000.000444)  can0  2034   [8]  00 3C 00 00 00 00 80 00   ERRORFRAME
>> 
>> controller-problem{rx-error-warning,tx-error-warning,rx-error-passive,tx-error-passive}
>>  

Just,

   controller-problem{rx-error-passive,tx-error-passive} 

>>
>> transceiver-status
>> no-acknowledgement-on-tx
>> error-counter-tx-rx{{128}{0}}
>>  (000.000495)  can0  2024   [8]  00 3C 00 00 00 00 80 00   ERRORFRAME
>> 
>> controller-problem{rx-error-warning,tx-error-warning,rx-error-passive,tx-error-passive}
>>  
>>
>> no-acknowledgement-on-tx
>> error-counter-tx-rx{{128}{0}}
> 
> Repeats ad infinitum...

Good! And without "berr-reporting" just the state changes should show up.

> 
> 
> (1b) cable gets connected:
> 
>>  (000.000883)  can0  2034   [8]  00 3C 00 00 00 00 80 00   ERRORFRAME
>> 
>> controller-problem{rx-error-warning,tx-error-warning,rx-error-passive,tx-error-passive}
>>  
>>
>> transceiver-status
>> no-acknowledgement-on-tx
>> error-counter-tx-rx{{128}{0}}
>>  (000.000996)  can0  2004   [8]  00 0C 00 00 00 00 7F 00   ERRORFRAME
>> controller-problem{rx-error-warning,tx-error-warning}
>> error-counter-tx-rx{{127}{0}}

Back to error active is missing!? Have a look to:

https://elixir.bootlin.com/linux/latest/source/drivers/net/can/dev.c#L364

Wolfgang.

Re: rx_packets/bytes stats for error frames




Am 14.03.2018 um 10:36 schrieb Marc Kleine-Budde:

On 03/14/2018 10:09 AM, Jakob Unterwurzacher wrote:

On 14.03.18 08:51, Marc Kleine-Budde wrote:

+   memcpy(cf->data, m->msg.can_msg.data, cf->can_dlc);
+
+   /* don't count error frames as real packets */
+   if (!(canid & CAN_ERR_FLAG)) {
+   stats->rx_packets++;
+   stats->rx_bytes += cf->can_dlc;
+   }

Please count them, too.


We do count them, as errors!

This is what happens when you transmit a single CAN frame with nothing
connected: "TX errors" shoots up but "RX packets" stays zero.


This is handled not consistent in the existing CAN drivers. In flexcan
all and c_can (all but rx overflow) are counted as rx_packets and
rx_bytes. (I haven't looked at the other drivers.)

I tend to count the error frames as ordinary frames.


+1, I think we should count the packets and bytes delivered to the 
network layer.


Wolfgang.

Re: rx_packets/bytes stats for error frames




Am 14.03.2018 um 10:36 schrieb Marc Kleine-Budde:

On 03/14/2018 10:09 AM, Jakob Unterwurzacher wrote:

On 14.03.18 08:51, Marc Kleine-Budde wrote:

+   memcpy(cf->data, m->msg.can_msg.data, cf->can_dlc);
+
+   /* don't count error frames as real packets */
+   if (!(canid & CAN_ERR_FLAG)) {
+   stats->rx_packets++;
+   stats->rx_bytes += cf->can_dlc;
+   }

Please count them, too.


We do count them, as errors!

This is what happens when you transmit a single CAN frame with nothing
connected: "TX errors" shoots up but "RX packets" stays zero.


This is handled not consistent in the existing CAN drivers. In flexcan
all and c_can (all but rx overflow) are counted as rx_packets and
rx_bytes. (I haven't looked at the other drivers.)

I tend to count the error frames as ordinary frames.


+1, I think we should count the packets and bytes delivered to the 
network layer.


Wolfgang.

Re: [PATCH v2 1/1] can: ucan: add driver for Theobroma Systems UCAN devices




Am 14.03.2018 um 10:17 schrieb Wolfgang Grandegger:



Am 14.03.2018 um 10:14 schrieb Jakob Unterwurzacher:

On 14.03.18 10:11, Wolfgang Grandegger wrote:

+    /* handle error frames */
+    canid = le32_to_cpu(m->msg.can_msg.id);
+    if (canid & CAN_ERR_FLAG) {
+    ucan_handle_error_frame(up, m, canid);
+    /* drop frame if berr-reporting is off */
+    if (!(up->can.ctrlmode & CAN_CTRLMODE_BERR_REPORTING))
+    return;
+    }


You still do not generate error messages for state changes, IIUC.


The hardware generates error frames on state changes - is that what 
you mean?


In our testing, the state shows up (and updates) correctly in

 ip -details -statistics link show can0


Counting the state changes is one thing but you should also generate 
error messages for them.


The usual test here is:

$ candump -td -e any,0:0,#

should report proper state changes, if you send messages with

1. no cable connected
2. CAN high and low short-circuited

Also downwards if the hardware error is gone and you continue to send 
messages.


Wolfgang.

Re: [PATCH v2 1/1] can: ucan: add driver for Theobroma Systems UCAN devices




Am 14.03.2018 um 10:17 schrieb Wolfgang Grandegger:



Am 14.03.2018 um 10:14 schrieb Jakob Unterwurzacher:

On 14.03.18 10:11, Wolfgang Grandegger wrote:

+    /* handle error frames */
+    canid = le32_to_cpu(m->msg.can_msg.id);
+    if (canid & CAN_ERR_FLAG) {
+    ucan_handle_error_frame(up, m, canid);
+    /* drop frame if berr-reporting is off */
+    if (!(up->can.ctrlmode & CAN_CTRLMODE_BERR_REPORTING))
+    return;
+    }


You still do not generate error messages for state changes, IIUC.


The hardware generates error frames on state changes - is that what 
you mean?


In our testing, the state shows up (and updates) correctly in

 ip -details -statistics link show can0


Counting the state changes is one thing but you should also generate 
error messages for them.


The usual test here is:

$ candump -td -e any,0:0,#

should report proper state changes, if you send messages with

1. no cable connected
2. CAN high and low short-circuited

Also downwards if the hardware error is gone and you continue to send 
messages.


Wolfgang.

Re: [PATCH v2 1/1] can: ucan: add driver for Theobroma Systems UCAN devices


Hello,

Am 13.03.2018 um 18:35 schrieb Jakob Unterwurzacher:

The UCAN driver supports the microcontroller-based USB/CAN
adapters from Theobroma Systems. There are two form-factors
that run essentially the same firmware:

* Seal: standalone USB stick ( https://www.theobroma-systems.com/seal )

* Mule: integrated on the PCB of various System-on-Modules from
   Theobroma Systems like the A31-µQ7 and the RK3399-Q7
   ( https://www.theobroma-systems.com/rk3399-q7 )

The USB wire protocol has been designed to be as generic and
hardware-indendent as possible in the hope of being useful for
implementation on other microcontrollers.

Signed-off-by: Martin Elshuber 
Signed-off-by: Jakob Unterwurzacher 
Signed-off-by: Philipp Tomsich 
---
  Documentation/networking/can_ucan_protocol.rst |  315 +
  Documentation/networking/index.rst |1 +
  drivers/net/can/usb/Kconfig|   10 +
  drivers/net/can/usb/Makefile   |1 +
  drivers/net/can/usb/ucan.c | 1587 
  5 files changed, 1914 insertions(+)
  create mode 100644 Documentation/networking/can_ucan_protocol.rst
  create mode 100644 drivers/net/can/usb/ucan.c

diff --git a/Documentation/networking/can_ucan_protocol.rst 
b/Documentation/networking/can_ucan_protocol.rst
new file mode 100644
index ..d859b36200b4
--- /dev/null
+++ b/Documentation/networking/can_ucan_protocol.rst
@@ -0,0 +1,315 @@
+=
+The UCAN Protocol
+=
+
+UCAN is the protocol used by the microcontroller-based USB-CAN
+adapter that is integrated on System-on-Modules from Theobroma Systems
+and that is also available as a standalone USB stick.
+
+The UCAN protocol has been designed to be hardware-independent.
+It is modeled closely after how Linux represents CAN devices
+internally. All multi-byte integers are encoded as Little Endian.
+
+All structures mentioned in this document are defined in
+``drivers/net/can/usb/ucan.c``.
+
+USB Endpoints
+=
+
+UCAN devices use three USB endpoints:
+
+CONTROL endpoint
+  The driver sends device management commands on this endpoint
+
+IN endpoint
+  The device sends CAN data frames and CAN error frames
+
+OUT endpoint
+  The driver sends CAN data frames on the out endpoint
+
+
+CONTROL Messages
+
+
+UCAN devices are configured using vendor requests on the control pipe.
+
+To support multiple CAN interfaces in a single USB device all
+configuration commands target the corresponding interface in the USB
+descriptor.
+
+The driver uses ``ucan_ctrl_command_in/out`` and
+``ucan_device_request_in`` to deliver commands to the device.
+
+Setup Packet
+
+
+=  =
+``bmRequestType``  Direction | Vendor | (Interface or Device)
+``bRequest``   Command Number
+``wValue`` Subcommand Number (16 Bit) or 0 if not used
+``wIndex`` USB Interface Index (0 for device commands)
+``wLength``* Host to Device - Number of bytes to transmit
+   * Device to Host - Maximum Number of bytes to
+ receive. If the device send less. Commom ZLP
+ semantics are used.
+=  =
+
+Error Handling
+--
+
+The device indicates failed control commands by stalling the
+pipe.
+
+Device Commands
+---
+
+UCAN_DEVICE_GET_FW_STRING
+~
+
+*Dev2Host; optional*
+
+Request the device firmware string.
+
+
+Interface Commands
+--
+
+UCAN_COMMAND_START
+~~
+
+*Host2Dev; mandatory*
+
+Bring the CAN interface up.
+
+Payload Format
+  ``ucan_ctl_payload_t.cmd_start``
+
+  
+mode  or mask of ``UCAN_MODE_*``
+  
+
+UCAN_COMMAND_STOP
+~~
+
+*Host2Dev; mandatory*
+
+Stop the CAN interface
+
+Payload Format
+  *empty*
+
+UCAN_COMMAND_RESET
+~~
+
+*Host2Dev; mandatory*
+
+Reset the CAN controller (including error counters)
+
+Payload Format
+  *empty*
+
+UCAN_COMMAND_GET
+
+
+*Host2Dev; mandatory*
+
+Get Information from the Device
+
+Subcommands
+^^^
+
+UCAN_COMMAND_GET_INFO
+  Request the device information structure ``ucan_ctl_payload_t.device_info``.
+
+  See the ``device_info`` field for details, and
+  ``uapi/linux/can/netlink.h`` for an explanation of the
+  ``can_bittiming fields``.
+
+  Payload Format
+``ucan_ctl_payload_t.device_info``
+
+UCAN_COMMAND_GET_PROTOCOL_VERSION
+
+  Request the device protocol version
+  ``ucan_ctl_payload_t.protocol_version``. The current protocol version is 3.
+
+  Payload Format
+``ucan_ctl_payload_t.protocol_version``
+
+.. note:: Devices that do not implement this command use

Re: [PATCH v2 1/1] can: ucan: add driver for Theobroma Systems UCAN devices


Hello,

Am 13.03.2018 um 18:35 schrieb Jakob Unterwurzacher:

The UCAN driver supports the microcontroller-based USB/CAN
adapters from Theobroma Systems. There are two form-factors
that run essentially the same firmware:

* Seal: standalone USB stick ( https://www.theobroma-systems.com/seal )

* Mule: integrated on the PCB of various System-on-Modules from
   Theobroma Systems like the A31-µQ7 and the RK3399-Q7
   ( https://www.theobroma-systems.com/rk3399-q7 )

The USB wire protocol has been designed to be as generic and
hardware-indendent as possible in the hope of being useful for
implementation on other microcontrollers.

Signed-off-by: Martin Elshuber 
Signed-off-by: Jakob Unterwurzacher 
Signed-off-by: Philipp Tomsich 
---
  Documentation/networking/can_ucan_protocol.rst |  315 +
  Documentation/networking/index.rst |1 +
  drivers/net/can/usb/Kconfig|   10 +
  drivers/net/can/usb/Makefile   |1 +
  drivers/net/can/usb/ucan.c | 1587 
  5 files changed, 1914 insertions(+)
  create mode 100644 Documentation/networking/can_ucan_protocol.rst
  create mode 100644 drivers/net/can/usb/ucan.c

diff --git a/Documentation/networking/can_ucan_protocol.rst 
b/Documentation/networking/can_ucan_protocol.rst
new file mode 100644
index ..d859b36200b4
--- /dev/null
+++ b/Documentation/networking/can_ucan_protocol.rst
@@ -0,0 +1,315 @@
+=
+The UCAN Protocol
+=
+
+UCAN is the protocol used by the microcontroller-based USB-CAN
+adapter that is integrated on System-on-Modules from Theobroma Systems
+and that is also available as a standalone USB stick.
+
+The UCAN protocol has been designed to be hardware-independent.
+It is modeled closely after how Linux represents CAN devices
+internally. All multi-byte integers are encoded as Little Endian.
+
+All structures mentioned in this document are defined in
+``drivers/net/can/usb/ucan.c``.
+
+USB Endpoints
+=
+
+UCAN devices use three USB endpoints:
+
+CONTROL endpoint
+  The driver sends device management commands on this endpoint
+
+IN endpoint
+  The device sends CAN data frames and CAN error frames
+
+OUT endpoint
+  The driver sends CAN data frames on the out endpoint
+
+
+CONTROL Messages
+
+
+UCAN devices are configured using vendor requests on the control pipe.
+
+To support multiple CAN interfaces in a single USB device all
+configuration commands target the corresponding interface in the USB
+descriptor.
+
+The driver uses ``ucan_ctrl_command_in/out`` and
+``ucan_device_request_in`` to deliver commands to the device.
+
+Setup Packet
+
+
+=  =
+``bmRequestType``  Direction | Vendor | (Interface or Device)
+``bRequest``   Command Number
+``wValue`` Subcommand Number (16 Bit) or 0 if not used
+``wIndex`` USB Interface Index (0 for device commands)
+``wLength``* Host to Device - Number of bytes to transmit
+   * Device to Host - Maximum Number of bytes to
+ receive. If the device send less. Commom ZLP
+ semantics are used.
+=  =
+
+Error Handling
+--
+
+The device indicates failed control commands by stalling the
+pipe.
+
+Device Commands
+---
+
+UCAN_DEVICE_GET_FW_STRING
+~
+
+*Dev2Host; optional*
+
+Request the device firmware string.
+
+
+Interface Commands
+--
+
+UCAN_COMMAND_START
+~~
+
+*Host2Dev; mandatory*
+
+Bring the CAN interface up.
+
+Payload Format
+  ``ucan_ctl_payload_t.cmd_start``
+
+  
+mode  or mask of ``UCAN_MODE_*``
+  
+
+UCAN_COMMAND_STOP
+~~
+
+*Host2Dev; mandatory*
+
+Stop the CAN interface
+
+Payload Format
+  *empty*
+
+UCAN_COMMAND_RESET
+~~
+
+*Host2Dev; mandatory*
+
+Reset the CAN controller (including error counters)
+
+Payload Format
+  *empty*
+
+UCAN_COMMAND_GET
+
+
+*Host2Dev; mandatory*
+
+Get Information from the Device
+
+Subcommands
+^^^
+
+UCAN_COMMAND_GET_INFO
+  Request the device information structure ``ucan_ctl_payload_t.device_info``.
+
+  See the ``device_info`` field for details, and
+  ``uapi/linux/can/netlink.h`` for an explanation of the
+  ``can_bittiming fields``.
+
+  Payload Format
+``ucan_ctl_payload_t.device_info``
+
+UCAN_COMMAND_GET_PROTOCOL_VERSION
+
+  Request the device protocol version
+  ``ucan_ctl_payload_t.protocol_version``. The current protocol version is 3.
+
+  Payload Format
+``ucan_ctl_payload_t.protocol_version``
+
+.. note:: Devices that do not implement this command use the old
+  protocol version 1
+
+UCAN_COMMAND_SET_BITTIMING
+~~
+
+*Host2Dev; mandatory*
+

Re: [PATCH v2 1/1] can: ucan: add driver for Theobroma Systems UCAN devices




Am 14.03.2018 um 10:14 schrieb Jakob Unterwurzacher:

On 14.03.18 10:11, Wolfgang Grandegger wrote:

+    /* handle error frames */
+    canid = le32_to_cpu(m->msg.can_msg.id);
+    if (canid & CAN_ERR_FLAG) {
+    ucan_handle_error_frame(up, m, canid);
+    /* drop frame if berr-reporting is off */
+    if (!(up->can.ctrlmode & CAN_CTRLMODE_BERR_REPORTING))
+    return;
+    }


You still do not generate error messages for state changes, IIUC.


The hardware generates error frames on state changes - is that what you 
mean?


In our testing, the state shows up (and updates) correctly in

 ip -details -statistics link show can0


Counting the state changes is one thing but you should also generate 
error messages for them.


Wolfgang.

Re: [PATCH v2 1/1] can: ucan: add driver for Theobroma Systems UCAN devices




Am 14.03.2018 um 10:14 schrieb Jakob Unterwurzacher:

On 14.03.18 10:11, Wolfgang Grandegger wrote:

+    /* handle error frames */
+    canid = le32_to_cpu(m->msg.can_msg.id);
+    if (canid & CAN_ERR_FLAG) {
+    ucan_handle_error_frame(up, m, canid);
+    /* drop frame if berr-reporting is off */
+    if (!(up->can.ctrlmode & CAN_CTRLMODE_BERR_REPORTING))
+    return;
+    }


You still do not generate error messages for state changes, IIUC.


The hardware generates error frames on state changes - is that what you 
mean?


In our testing, the state shows up (and updates) correctly in

 ip -details -statistics link show can0


Counting the state changes is one thing but you should also generate 
error messages for them.


Wolfgang.

Re: [PATCH v4 2/2] can: spi: hi311x: Add Holt HI-311x CAN driver

2017-03-20 Thread Wolfgang Grandegger


Hello Akshay,

Am 20.03.2017 um 16:14 schrieb Akshay Bhat:

Hi Wolfgang,

On 03/19/2017 12:17 PM, Wolfgang Grandegger wrote:

Hello Akshay,

I still see some improvements...

Am 17.03.2017 um 22:10 schrieb Akshay Bhat:

This patch adds support for the Holt HI-311x CAN controller. The HI311x
CAN controller is capable of transmitting and receiving standard data
frames, extended data frames and remote frames. The HI311x interfaces
with the host over SPI.

Datasheet: www.holtic.com/documents/371-hi-3110_v-rev-jpdf.do

Signed-off-by: Akshay Bhat <nod...@gmail.com>
---

v3 -> v4:
Address comments from Wolfgang Grandegger:
- Add support for CAN warning state reporting
- Add support for reporting tx/rx error counts in bus error messages
- Keep bus error interrupts enabled to detect CAN state changes
- Fix bug in restart code after BUSOFF state
- Clean up error handling code

 drivers/net/can/spi/Kconfig  |6 +
 drivers/net/can/spi/Makefile |1 +
 drivers/net/can/spi/hi311x.c | 1072
++
 3 files changed, 1079 insertions(+)
 create mode 100644 drivers/net/can/spi/hi311x.c

diff --git a/drivers/net/can/spi/Kconfig b/drivers/net/can/spi/Kconfig
index 148cae5..8f2e0dd 100644
--- a/drivers/net/can/spi/Kconfig
+++ b/drivers/net/can/spi/Kconfig
@@ -1,6 +1,12 @@
 menu "CAN SPI interfaces"
 depends on SPI

+config CAN_HI311X
+tristate "Holt HI311x SPI CAN controllers"
+depends on CAN_DEV && SPI && HAS_DMA
+---help---
+  Driver for the Holt HI311x SPI CAN controllers.
+
 config CAN_MCP251X
 tristate "Microchip MCP251x SPI CAN controllers"
 depends on HAS_DMA
diff --git a/drivers/net/can/spi/Makefile b/drivers/net/can/spi/Makefile
index 0e86040..f59fa37 100644
--- a/drivers/net/can/spi/Makefile
+++ b/drivers/net/can/spi/Makefile
@@ -3,4 +3,5 @@
 #


+obj-$(CONFIG_CAN_HI311X)+= hi311x.o
 obj-$(CONFIG_CAN_MCP251X)+= mcp251x.o
diff --git a/drivers/net/can/spi/hi311x.c b/drivers/net/can/spi/hi311x.c
new file mode 100644
index 000..2a3d794
--- /dev/null
+++ b/drivers/net/can/spi/hi311x.c
@@ -0,0 +1,1072 @@
+/* CAN bus driver for Holt HI3110 CAN Controller with SPI Interface
+ *
+ * Copyright(C) Timesys Corporation 2016
+ *
+ * Based on Microchip 251x CAN Controller (mcp251x) Linux kernel driver
+ * Copyright 2009 Christian Pellegrin EVOL S.r.l.
+ * Copyright 2007 Raymarine UK, Ltd. All Rights Reserved.
+ * Copyright 2006 Arcom Control Systems Ltd.
+ *
+ * Based on CAN bus driver for the CCAN controller written by
+ * - Sascha Hauer, Marc Kleine-Budde, Pengutronix
+ * - Simon Kallweit, intefo AG
+ * Copyright 2007
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */


... snip...


+
+static irqreturn_t hi3110_can_ist(int irq, void *dev_id)
+{
+struct hi3110_priv *priv = dev_id;
+struct spi_device *spi = priv->spi;
+struct net_device *net = priv->net;
+
+mutex_lock(>hi3110_lock);
+
+while (!priv->force_quit) {
+enum can_state new_state;
+u8 intf, eflag, statf;
+
+while (!(HI3110_STAT_RXFMTY &
+   (statf = hi3110_read(spi, HI3110_READ_STATF {
+hi3110_hw_rx(spi);
+}
+
+intf = hi3110_read(spi, HI3110_READ_INTF);


I think HI3110_READ_ERR is only valid if HI3110_INT_BUSERR is set!
Therefore:

if ((intf & HI3110_INT_BUSERR) {

It saves reading one SPI register in the message processing path. Please
check if back-to-error-active still comes.



The top 3 bits of HI3110_READ_ERR (BUSOFF, TXERRP, RXERRP) are valid
even if HI3110_INT_BUSERR is not set.


I'm confused! If you disable BUSERR interrupts, you do not get the 
status bits any longer, you said. But the manual says: "Bits 4:0 in the 
ERR register can be read to determine the source of the error.", which 
excludes the above bits... but obviously the controller does it that way.


Sorry for the noise,

Wolfgang.

Re: [PATCH v4 2/2] can: spi: hi311x: Add Holt HI-311x CAN driver

2017-03-20 Thread Wolfgang Grandegger


Hello Akshay,

Am 20.03.2017 um 16:14 schrieb Akshay Bhat:

Hi Wolfgang,

On 03/19/2017 12:17 PM, Wolfgang Grandegger wrote:

Hello Akshay,

I still see some improvements...

Am 17.03.2017 um 22:10 schrieb Akshay Bhat:

This patch adds support for the Holt HI-311x CAN controller. The HI311x
CAN controller is capable of transmitting and receiving standard data
frames, extended data frames and remote frames. The HI311x interfaces
with the host over SPI.

Datasheet: www.holtic.com/documents/371-hi-3110_v-rev-jpdf.do

Signed-off-by: Akshay Bhat 
---

v3 -> v4:
Address comments from Wolfgang Grandegger:
- Add support for CAN warning state reporting
- Add support for reporting tx/rx error counts in bus error messages
- Keep bus error interrupts enabled to detect CAN state changes
- Fix bug in restart code after BUSOFF state
- Clean up error handling code

 drivers/net/can/spi/Kconfig  |6 +
 drivers/net/can/spi/Makefile |1 +
 drivers/net/can/spi/hi311x.c | 1072
++
 3 files changed, 1079 insertions(+)
 create mode 100644 drivers/net/can/spi/hi311x.c

diff --git a/drivers/net/can/spi/Kconfig b/drivers/net/can/spi/Kconfig
index 148cae5..8f2e0dd 100644
--- a/drivers/net/can/spi/Kconfig
+++ b/drivers/net/can/spi/Kconfig
@@ -1,6 +1,12 @@
 menu "CAN SPI interfaces"
 depends on SPI

+config CAN_HI311X
+tristate "Holt HI311x SPI CAN controllers"
+depends on CAN_DEV && SPI && HAS_DMA
+---help---
+  Driver for the Holt HI311x SPI CAN controllers.
+
 config CAN_MCP251X
 tristate "Microchip MCP251x SPI CAN controllers"
 depends on HAS_DMA
diff --git a/drivers/net/can/spi/Makefile b/drivers/net/can/spi/Makefile
index 0e86040..f59fa37 100644
--- a/drivers/net/can/spi/Makefile
+++ b/drivers/net/can/spi/Makefile
@@ -3,4 +3,5 @@
 #


+obj-$(CONFIG_CAN_HI311X)+= hi311x.o
 obj-$(CONFIG_CAN_MCP251X)+= mcp251x.o
diff --git a/drivers/net/can/spi/hi311x.c b/drivers/net/can/spi/hi311x.c
new file mode 100644
index 000..2a3d794
--- /dev/null
+++ b/drivers/net/can/spi/hi311x.c
@@ -0,0 +1,1072 @@
+/* CAN bus driver for Holt HI3110 CAN Controller with SPI Interface
+ *
+ * Copyright(C) Timesys Corporation 2016
+ *
+ * Based on Microchip 251x CAN Controller (mcp251x) Linux kernel driver
+ * Copyright 2009 Christian Pellegrin EVOL S.r.l.
+ * Copyright 2007 Raymarine UK, Ltd. All Rights Reserved.
+ * Copyright 2006 Arcom Control Systems Ltd.
+ *
+ * Based on CAN bus driver for the CCAN controller written by
+ * - Sascha Hauer, Marc Kleine-Budde, Pengutronix
+ * - Simon Kallweit, intefo AG
+ * Copyright 2007
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */


... snip...


+
+static irqreturn_t hi3110_can_ist(int irq, void *dev_id)
+{
+struct hi3110_priv *priv = dev_id;
+struct spi_device *spi = priv->spi;
+struct net_device *net = priv->net;
+
+mutex_lock(>hi3110_lock);
+
+while (!priv->force_quit) {
+enum can_state new_state;
+u8 intf, eflag, statf;
+
+while (!(HI3110_STAT_RXFMTY &
+   (statf = hi3110_read(spi, HI3110_READ_STATF {
+hi3110_hw_rx(spi);
+}
+
+intf = hi3110_read(spi, HI3110_READ_INTF);


I think HI3110_READ_ERR is only valid if HI3110_INT_BUSERR is set!
Therefore:

if ((intf & HI3110_INT_BUSERR) {

It saves reading one SPI register in the message processing path. Please
check if back-to-error-active still comes.



The top 3 bits of HI3110_READ_ERR (BUSOFF, TXERRP, RXERRP) are valid
even if HI3110_INT_BUSERR is not set.


I'm confused! If you disable BUSERR interrupts, you do not get the 
status bits any longer, you said. But the manual says: "Bits 4:0 in the 
ERR register can be read to determine the source of the error.", which 
excludes the above bits... but obviously the controller does it that way.


Sorry for the noise,

Wolfgang.

Re: [PATCH v4 2/2] can: spi: hi311x: Add Holt HI-311x CAN driver

2017-03-19 Thread Wolfgang Grandegger


Hello Akshay,

I still see some improvements...

Am 17.03.2017 um 22:10 schrieb Akshay Bhat:

This patch adds support for the Holt HI-311x CAN controller. The HI311x
CAN controller is capable of transmitting and receiving standard data
frames, extended data frames and remote frames. The HI311x interfaces
with the host over SPI.

Datasheet: www.holtic.com/documents/371-hi-3110_v-rev-jpdf.do

Signed-off-by: Akshay Bhat <nod...@gmail.com>
---

v3 -> v4:
Address comments from Wolfgang Grandegger:
- Add support for CAN warning state reporting
- Add support for reporting tx/rx error counts in bus error messages
- Keep bus error interrupts enabled to detect CAN state changes
- Fix bug in restart code after BUSOFF state
- Clean up error handling code

 drivers/net/can/spi/Kconfig  |6 +
 drivers/net/can/spi/Makefile |1 +
 drivers/net/can/spi/hi311x.c | 1072 ++
 3 files changed, 1079 insertions(+)
 create mode 100644 drivers/net/can/spi/hi311x.c

diff --git a/drivers/net/can/spi/Kconfig b/drivers/net/can/spi/Kconfig
index 148cae5..8f2e0dd 100644
--- a/drivers/net/can/spi/Kconfig
+++ b/drivers/net/can/spi/Kconfig
@@ -1,6 +1,12 @@
 menu "CAN SPI interfaces"
depends on SPI

+config CAN_HI311X
+   tristate "Holt HI311x SPI CAN controllers"
+   depends on CAN_DEV && SPI && HAS_DMA
+   ---help---
+ Driver for the Holt HI311x SPI CAN controllers.
+
 config CAN_MCP251X
tristate "Microchip MCP251x SPI CAN controllers"
depends on HAS_DMA
diff --git a/drivers/net/can/spi/Makefile b/drivers/net/can/spi/Makefile
index 0e86040..f59fa37 100644
--- a/drivers/net/can/spi/Makefile
+++ b/drivers/net/can/spi/Makefile
@@ -3,4 +3,5 @@
 #


+obj-$(CONFIG_CAN_HI311X)   += hi311x.o
 obj-$(CONFIG_CAN_MCP251X)  += mcp251x.o
diff --git a/drivers/net/can/spi/hi311x.c b/drivers/net/can/spi/hi311x.c
new file mode 100644
index 000..2a3d794
--- /dev/null
+++ b/drivers/net/can/spi/hi311x.c
@@ -0,0 +1,1072 @@
+/* CAN bus driver for Holt HI3110 CAN Controller with SPI Interface
+ *
+ * Copyright(C) Timesys Corporation 2016
+ *
+ * Based on Microchip 251x CAN Controller (mcp251x) Linux kernel driver
+ * Copyright 2009 Christian Pellegrin EVOL S.r.l.
+ * Copyright 2007 Raymarine UK, Ltd. All Rights Reserved.
+ * Copyright 2006 Arcom Control Systems Ltd.
+ *
+ * Based on CAN bus driver for the CCAN controller written by
+ * - Sascha Hauer, Marc Kleine-Budde, Pengutronix
+ * - Simon Kallweit, intefo AG
+ * Copyright 2007
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */


... snip...


+
+static irqreturn_t hi3110_can_ist(int irq, void *dev_id)
+{
+   struct hi3110_priv *priv = dev_id;
+   struct spi_device *spi = priv->spi;
+   struct net_device *net = priv->net;
+
+   mutex_lock(>hi3110_lock);
+
+   while (!priv->force_quit) {
+   enum can_state new_state;
+   u8 intf, eflag, statf;
+
+   while (!(HI3110_STAT_RXFMTY &
+  (statf = hi3110_read(spi, HI3110_READ_STATF {
+   hi3110_hw_rx(spi);
+   }
+
+   intf = hi3110_read(spi, HI3110_READ_INTF);


I think HI3110_READ_ERR is only valid if HI3110_INT_BUSERR is set! 
Therefore:


if ((intf & HI3110_INT_BUSERR) {

It saves reading one SPI register in the message processing path. Please 
check if back-to-error-active still comes.



+   eflag = hi3110_read(spi, HI3110_READ_ERR);
+   /* Update can state */
+   if (eflag & HI3110_ERR_BUSOFF)
+   new_state = CAN_STATE_BUS_OFF;
+   else if (eflag & HI3110_ERR_PASSIVE_MASK)
+   new_state = CAN_STATE_ERROR_PASSIVE;
+   else if (statf & HI3110_STAT_ERRW)
+   new_state = CAN_STATE_ERROR_WARNING;
+   else
+   new_state = CAN_STATE_ERROR_ACTIVE;
+
+   if (new_state != priv->can.state) {
+   struct can_frame *cf;
+   struct sk_buff *skb;
+   enum can_state rx_state, tx_state;
+   u8 rxerr, txerr;
+
+   skb = alloc_can_err_skb(net, );
+   if (!skb)
+   break;
+
+   txerr = hi3110_read(spi, HI3110_READ_TEC);
+   rxerr = hi3110_read(spi, HI3110_READ_REC);
+   cf->data[6] = txerr;
+   cf->data[7] = rxerr;
+   tx_state = txerr >= rxerr ? new_state : 0;
+   rx_state = txerr <= rxerr ? new_state : 0;
+   can_change_state(net, cf,

Re: [PATCH v4 2/2] can: spi: hi311x: Add Holt HI-311x CAN driver

2017-03-19 Thread Wolfgang Grandegger


Hello Akshay,

I still see some improvements...

Am 17.03.2017 um 22:10 schrieb Akshay Bhat:

This patch adds support for the Holt HI-311x CAN controller. The HI311x
CAN controller is capable of transmitting and receiving standard data
frames, extended data frames and remote frames. The HI311x interfaces
with the host over SPI.

Datasheet: www.holtic.com/documents/371-hi-3110_v-rev-jpdf.do

Signed-off-by: Akshay Bhat 
---

v3 -> v4:
Address comments from Wolfgang Grandegger:
- Add support for CAN warning state reporting
- Add support for reporting tx/rx error counts in bus error messages
- Keep bus error interrupts enabled to detect CAN state changes
- Fix bug in restart code after BUSOFF state
- Clean up error handling code

 drivers/net/can/spi/Kconfig  |6 +
 drivers/net/can/spi/Makefile |1 +
 drivers/net/can/spi/hi311x.c | 1072 ++
 3 files changed, 1079 insertions(+)
 create mode 100644 drivers/net/can/spi/hi311x.c

diff --git a/drivers/net/can/spi/Kconfig b/drivers/net/can/spi/Kconfig
index 148cae5..8f2e0dd 100644
--- a/drivers/net/can/spi/Kconfig
+++ b/drivers/net/can/spi/Kconfig
@@ -1,6 +1,12 @@
 menu "CAN SPI interfaces"
depends on SPI

+config CAN_HI311X
+   tristate "Holt HI311x SPI CAN controllers"
+   depends on CAN_DEV && SPI && HAS_DMA
+   ---help---
+ Driver for the Holt HI311x SPI CAN controllers.
+
 config CAN_MCP251X
tristate "Microchip MCP251x SPI CAN controllers"
depends on HAS_DMA
diff --git a/drivers/net/can/spi/Makefile b/drivers/net/can/spi/Makefile
index 0e86040..f59fa37 100644
--- a/drivers/net/can/spi/Makefile
+++ b/drivers/net/can/spi/Makefile
@@ -3,4 +3,5 @@
 #


+obj-$(CONFIG_CAN_HI311X)   += hi311x.o
 obj-$(CONFIG_CAN_MCP251X)  += mcp251x.o
diff --git a/drivers/net/can/spi/hi311x.c b/drivers/net/can/spi/hi311x.c
new file mode 100644
index 000..2a3d794
--- /dev/null
+++ b/drivers/net/can/spi/hi311x.c
@@ -0,0 +1,1072 @@
+/* CAN bus driver for Holt HI3110 CAN Controller with SPI Interface
+ *
+ * Copyright(C) Timesys Corporation 2016
+ *
+ * Based on Microchip 251x CAN Controller (mcp251x) Linux kernel driver
+ * Copyright 2009 Christian Pellegrin EVOL S.r.l.
+ * Copyright 2007 Raymarine UK, Ltd. All Rights Reserved.
+ * Copyright 2006 Arcom Control Systems Ltd.
+ *
+ * Based on CAN bus driver for the CCAN controller written by
+ * - Sascha Hauer, Marc Kleine-Budde, Pengutronix
+ * - Simon Kallweit, intefo AG
+ * Copyright 2007
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */


... snip...


+
+static irqreturn_t hi3110_can_ist(int irq, void *dev_id)
+{
+   struct hi3110_priv *priv = dev_id;
+   struct spi_device *spi = priv->spi;
+   struct net_device *net = priv->net;
+
+   mutex_lock(>hi3110_lock);
+
+   while (!priv->force_quit) {
+   enum can_state new_state;
+   u8 intf, eflag, statf;
+
+   while (!(HI3110_STAT_RXFMTY &
+  (statf = hi3110_read(spi, HI3110_READ_STATF {
+   hi3110_hw_rx(spi);
+   }
+
+   intf = hi3110_read(spi, HI3110_READ_INTF);


I think HI3110_READ_ERR is only valid if HI3110_INT_BUSERR is set! 
Therefore:


if ((intf & HI3110_INT_BUSERR) {

It saves reading one SPI register in the message processing path. Please 
check if back-to-error-active still comes.



+   eflag = hi3110_read(spi, HI3110_READ_ERR);
+   /* Update can state */
+   if (eflag & HI3110_ERR_BUSOFF)
+   new_state = CAN_STATE_BUS_OFF;
+   else if (eflag & HI3110_ERR_PASSIVE_MASK)
+   new_state = CAN_STATE_ERROR_PASSIVE;
+   else if (statf & HI3110_STAT_ERRW)
+   new_state = CAN_STATE_ERROR_WARNING;
+   else
+   new_state = CAN_STATE_ERROR_ACTIVE;
+
+   if (new_state != priv->can.state) {
+   struct can_frame *cf;
+   struct sk_buff *skb;
+   enum can_state rx_state, tx_state;
+   u8 rxerr, txerr;
+
+   skb = alloc_can_err_skb(net, );
+   if (!skb)
+   break;
+
+   txerr = hi3110_read(spi, HI3110_READ_TEC);
+   rxerr = hi3110_read(spi, HI3110_READ_REC);
+   cf->data[6] = txerr;
+   cf->data[7] = rxerr;
+   tx_state = txerr >= rxerr ? new_state : 0;
+   rx_state = txerr <= rxerr ? new_state : 0;
+   can_change_state(net, cf, tx_state, rx_state);
+

Re: [PATCH v2 2/2] can: spi: hi311x: Add Holt HI-311x CAN driver

2017-03-18 Thread Wolfgang Grandegger


Hello Akshay,

Am 17.03.2017 um 19:28 schrieb Akshay Bhat:

Hi Wolfgang,

On 03/17/2017 01:04 PM, Wolfgang Grandegger wrote:


Hm, that's unusual. Cable disconnected and then send a message:

$ grep /proc/interrupts; sleep 10; /proc/interrupts

should make things clear. But maybe it's a clever chip and it does stop
sending error messages if the error counter does not change any more.
After bus-off, the chip is quiet, of course. Should have a closer look
to the CAN standard.



The interrupt count does not increment after device reaches
tx-error-passive (with cable disconnected).

# while true; do grep -i hi3110 /proc/interrupts; sleep 10; done &
[1] 793
#
111:  0  0  gpio-mxc  12 Edge  hi3110
# candump -t d -e any,0:0,#FFF &
[2] 798
# cansend can0 123#
#
 (000.00)  can0  2004   [8]  00 08 00 00 00 00 60 00   ERRORFRAME
controller-problem{tx-error-warning}
error-counter-tx-rx{{96}{0}}
 (000.002122)  can0  2004   [8]  00 20 00 00 00 00 80 00   ERRORFRAME
controller-problem{tx-error-passive}
error-counter-tx-rx{{128}{0}}
111: 10  0  gpio-mxc  12 Edge  hi3110
111: 10  0  gpio-mxc  12 Edge  hi3110
111: 10  0  gpio-mxc  12 Edge  hi3110


OK, then there is no good reason connecting the STAT interrupt pin.

Wolfgang.

Re: [PATCH v2 2/2] can: spi: hi311x: Add Holt HI-311x CAN driver

2017-03-18 Thread Wolfgang Grandegger


Hello Akshay,

Am 17.03.2017 um 19:28 schrieb Akshay Bhat:

Hi Wolfgang,

On 03/17/2017 01:04 PM, Wolfgang Grandegger wrote:


Hm, that's unusual. Cable disconnected and then send a message:

$ grep /proc/interrupts; sleep 10; /proc/interrupts

should make things clear. But maybe it's a clever chip and it does stop
sending error messages if the error counter does not change any more.
After bus-off, the chip is quiet, of course. Should have a closer look
to the CAN standard.



The interrupt count does not increment after device reaches
tx-error-passive (with cable disconnected).

# while true; do grep -i hi3110 /proc/interrupts; sleep 10; done &
[1] 793
#
111:  0  0  gpio-mxc  12 Edge  hi3110
# candump -t d -e any,0:0,#FFF &
[2] 798
# cansend can0 123#
#
 (000.00)  can0  2004   [8]  00 08 00 00 00 00 60 00   ERRORFRAME
controller-problem{tx-error-warning}
error-counter-tx-rx{{96}{0}}
 (000.002122)  can0  2004   [8]  00 20 00 00 00 00 80 00   ERRORFRAME
controller-problem{tx-error-passive}
error-counter-tx-rx{{128}{0}}
111: 10  0  gpio-mxc  12 Edge  hi3110
111: 10  0  gpio-mxc  12 Edge  hi3110
111: 10  0  gpio-mxc  12 Edge  hi3110


OK, then there is no good reason connecting the STAT interrupt pin.

Wolfgang.

Re: [PATCH v2 2/2] can: spi: hi311x: Add Holt HI-311x CAN driver


Hi Akshay,

Am 17.03.2017 um 17:00 schrieb Akshay Bhat:

Hi Wolfgang,

On 03/17/2017 03:39 AM, Wolfgang Grandegger wrote:

Hello Akshay,

Am 16.03.2017 um 23:29 schrieb Akshay Bhat:

Hi Wolfgang,

On 03/16/2017 04:02 PM, Wolfgang Grandegger wrote:


Looks much better now! There are message for state changes to error
warning and passive. Just the following message is not correct:

 (000.200824)  can0  2004   [8]  00 40 00 00 00 00 5F 19
ERRORFRAME
controller-problem{}
error-counter-tx-rx{{95}{25}}

Sorry, forgot to mention... the function can_change_state() [1]
should be used for that purpose, if possible. It fixes the issue
above as well.



The updated driver (the one used to create the above log) is using
can_change_state() function. data[1] 40 corresponds to
CAN_ERR_CRTL_ACTIVE, so looks correct? Could it be that the can-utils I
am using is old and not reporting state change?


Hm, yes. The raw data looks correct. You could download and build a
recent version from "https://github.com/linux-can/can-utils; to check.
It could also be a bug.



Turned out to be a old version of can-utils. Using the above git tree
reports the flag.

 (000.200308)  can0  2004   [8]  00 40 00 00 00 00 5F 00   ERRORFRAME
controller-problem{back-to-error-active}
error-counter-tx-rx{{95}{0}}


Enabling BUSOFF/ERRP/ERRW bits in STATFE did not generate any interrupts
on the INT pin. Should we make it a requirement that both INT and STAT
pins need to be connected in hardware for the driver to do the error
reporting?


As I said, it's the better solution, especially if interrupt flooding
does harm. How does your system behave when bus errors come in due to no
cable connected?



I did not see any issues on the system with the cable disconnected. In
my particular setup with the cable disconnected the system goes to
tx-error-passive and does not get any further interrupts until a state
change occurs.


Hm, that's unusual. Cable disconnected and then send a message:

$ grep /proc/interrupts; sleep 10; /proc/interrupts

should make things clear. But maybe it's a clever chip and it does stop 
sending error messages if the error counter does not change any more. 
After bus-off, the chip is quiet, of course. Should have a closer look 
to the CAN standard.



So far using NAPI was mandatory. There is the problem of out-of-order
message reception if handled in the isr on multi processor systems.
Marc, what is the current policy?



Since this is a SPI based CAN, I am wary for any additional latencies
NAPI might introduce. The RX handling is being done at the very
beginning of the ISR for this reason.

Can we go ahead with the existing implementation and re-visit this at a
later time?


Likely yes, as Marc has already reviewed the driver once.

BTW: what system board/processor are you using?


Thanks again for all your help in reviewing/improving the driver :)


You are welcome!

Wolfgang.

Re: [PATCH v2 2/2] can: spi: hi311x: Add Holt HI-311x CAN driver


Hi Akshay,

Am 17.03.2017 um 17:00 schrieb Akshay Bhat:

Hi Wolfgang,

On 03/17/2017 03:39 AM, Wolfgang Grandegger wrote:

Hello Akshay,

Am 16.03.2017 um 23:29 schrieb Akshay Bhat:

Hi Wolfgang,

On 03/16/2017 04:02 PM, Wolfgang Grandegger wrote:


Looks much better now! There are message for state changes to error
warning and passive. Just the following message is not correct:

 (000.200824)  can0  2004   [8]  00 40 00 00 00 00 5F 19
ERRORFRAME
controller-problem{}
error-counter-tx-rx{{95}{25}}

Sorry, forgot to mention... the function can_change_state() [1]
should be used for that purpose, if possible. It fixes the issue
above as well.



The updated driver (the one used to create the above log) is using
can_change_state() function. data[1] 40 corresponds to
CAN_ERR_CRTL_ACTIVE, so looks correct? Could it be that the can-utils I
am using is old and not reporting state change?


Hm, yes. The raw data looks correct. You could download and build a
recent version from "https://github.com/linux-can/can-utils; to check.
It could also be a bug.



Turned out to be a old version of can-utils. Using the above git tree
reports the flag.

 (000.200308)  can0  2004   [8]  00 40 00 00 00 00 5F 00   ERRORFRAME
controller-problem{back-to-error-active}
error-counter-tx-rx{{95}{0}}


Enabling BUSOFF/ERRP/ERRW bits in STATFE did not generate any interrupts
on the INT pin. Should we make it a requirement that both INT and STAT
pins need to be connected in hardware for the driver to do the error
reporting?


As I said, it's the better solution, especially if interrupt flooding
does harm. How does your system behave when bus errors come in due to no
cable connected?



I did not see any issues on the system with the cable disconnected. In
my particular setup with the cable disconnected the system goes to
tx-error-passive and does not get any further interrupts until a state
change occurs.


Hm, that's unusual. Cable disconnected and then send a message:

$ grep /proc/interrupts; sleep 10; /proc/interrupts

should make things clear. But maybe it's a clever chip and it does stop 
sending error messages if the error counter does not change any more. 
After bus-off, the chip is quiet, of course. Should have a closer look 
to the CAN standard.



So far using NAPI was mandatory. There is the problem of out-of-order
message reception if handled in the isr on multi processor systems.
Marc, what is the current policy?



Since this is a SPI based CAN, I am wary for any additional latencies
NAPI might introduce. The RX handling is being done at the very
beginning of the ISR for this reason.

Can we go ahead with the existing implementation and re-visit this at a
later time?


Likely yes, as Marc has already reviewed the driver once.

BTW: what system board/processor are you using?


Thanks again for all your help in reviewing/improving the driver :)


You are welcome!

Wolfgang.

Re: [PATCH v2 2/2] can: spi: hi311x: Add Holt HI-311x CAN driver


Hello Akshay,

Am 17.03.2017 um 08:39 schrieb Wolfgang Grandegger:

Hello Akshay,

Am 16.03.2017 um 23:29 schrieb Akshay Bhat:

Hi Wolfgang,

On 03/16/2017 04:02 PM, Wolfgang Grandegger wrote:


Looks much better now! There are message for state changes to error
warning and passive. Just the following message is not correct:

 (000.200824)  can0  2004   [8]  00 40 00 00 00 00 5F 19
ERRORFRAME
controller-problem{}
error-counter-tx-rx{{95}{25}}

Sorry, forgot to mention... the function can_change_state() [1]
should be used for that purpose, if possible. It fixes the issue
above as well.



The updated driver (the one used to create the above log) is using
can_change_state() function. data[1] 40 corresponds to
CAN_ERR_CRTL_ACTIVE, so looks correct? Could it be that the can-utils I
am using is old and not reporting state change?


Hm, yes. The raw data looks correct. You could download and build a
recent version from "https://github.com/linux-can/can-utils; to check.
It could also be a bug.


Support for that flags has been added in December 2014.

Wolfgang-

Re: [PATCH v2 2/2] can: spi: hi311x: Add Holt HI-311x CAN driver


Hello Akshay,

Am 17.03.2017 um 08:39 schrieb Wolfgang Grandegger:

Hello Akshay,

Am 16.03.2017 um 23:29 schrieb Akshay Bhat:

Hi Wolfgang,

On 03/16/2017 04:02 PM, Wolfgang Grandegger wrote:


Looks much better now! There are message for state changes to error
warning and passive. Just the following message is not correct:

 (000.200824)  can0  2004   [8]  00 40 00 00 00 00 5F 19
ERRORFRAME
controller-problem{}
error-counter-tx-rx{{95}{25}}

Sorry, forgot to mention... the function can_change_state() [1]
should be used for that purpose, if possible. It fixes the issue
above as well.



The updated driver (the one used to create the above log) is using
can_change_state() function. data[1] 40 corresponds to
CAN_ERR_CRTL_ACTIVE, so looks correct? Could it be that the can-utils I
am using is old and not reporting state change?


Hm, yes. The raw data looks correct. You could download and build a
recent version from "https://github.com/linux-can/can-utils; to check.
It could also be a bug.


Support for that flags has been added in December 2014.

Wolfgang-

Re: [PATCH v2 2/2] can: spi: hi311x: Add Holt HI-311x CAN driver


Hello Akshay,

Am 16.03.2017 um 23:29 schrieb Akshay Bhat:

Hi Wolfgang,

On 03/16/2017 04:02 PM, Wolfgang Grandegger wrote:


Looks much better now! There are message for state changes to error
warning and passive. Just the following message is not correct:

 (000.200824)  can0  2004   [8]  00 40 00 00 00 00 5F 19   ERRORFRAME
controller-problem{}
error-counter-tx-rx{{95}{25}}

Sorry, forgot to mention... the function can_change_state() [1]
should be used for that purpose, if possible. It fixes the issue
above as well.



The updated driver (the one used to create the above log) is using
can_change_state() function. data[1] 40 corresponds to
CAN_ERR_CRTL_ACTIVE, so looks correct? Could it be that the can-utils I
am using is old and not reporting state change?


Hm, yes. The raw data looks correct. You could download and build a 
recent version from "https://github.com/linux-can/can-utils; to check. 
It could also be a bug.



Tentative v4 driver for reference:
http://pastebin.com/4xFVL1Sj


berr-reporting off case:
http://pastebin.com/fUn3j7qU


Ditto.

I just had another look to the manual and there is this undocumented
STATFE register at offset 0x1E. It's mentioned in some other parts of
the doc as interrupt enable register for STATF events. I would assume
the same bit layout than STATF. If you set bit 2 (BUSOFF), 3 (ERRP)
and 4 (ERRW), you may get interrupts. It's worth a try, I think. If
it works, it's the much better solution.



The HI-311x has a INT pin and a STAT pin. The hardware I have has only
the INT pin connected to the processor. If the STAT pin was also
connected, then like you mentioned it could be a much better solution to
use STAT for state changes.


OK, I understand.


Enabling BUSOFF/ERRP/ERRW bits in STATFE did not generate any interrupts
on the INT pin. Should we make it a requirement that both INT and STAT
pins need to be connected in hardware for the driver to do the error
reporting?


As I said, it's the better solution, especially if interrupt flooding 
does harm. How does your system behave when bus errors come in due to no 
cable connected?


So far using NAPI was mandatory. There is the problem of out-of-order 
message reception if handled in the isr on multi processor systems. 
Marc, what is the current policy?


Wolfgang.

Re: [PATCH v2 2/2] can: spi: hi311x: Add Holt HI-311x CAN driver


Hello Akshay,

Am 16.03.2017 um 23:29 schrieb Akshay Bhat:

Hi Wolfgang,

On 03/16/2017 04:02 PM, Wolfgang Grandegger wrote:


Looks much better now! There are message for state changes to error
warning and passive. Just the following message is not correct:

 (000.200824)  can0  2004   [8]  00 40 00 00 00 00 5F 19   ERRORFRAME
controller-problem{}
error-counter-tx-rx{{95}{25}}

Sorry, forgot to mention... the function can_change_state() [1]
should be used for that purpose, if possible. It fixes the issue
above as well.



The updated driver (the one used to create the above log) is using
can_change_state() function. data[1] 40 corresponds to
CAN_ERR_CRTL_ACTIVE, so looks correct? Could it be that the can-utils I
am using is old and not reporting state change?


Hm, yes. The raw data looks correct. You could download and build a 
recent version from "https://github.com/linux-can/can-utils; to check. 
It could also be a bug.



Tentative v4 driver for reference:
http://pastebin.com/4xFVL1Sj


berr-reporting off case:
http://pastebin.com/fUn3j7qU


Ditto.

I just had another look to the manual and there is this undocumented
STATFE register at offset 0x1E. It's mentioned in some other parts of
the doc as interrupt enable register for STATF events. I would assume
the same bit layout than STATF. If you set bit 2 (BUSOFF), 3 (ERRP)
and 4 (ERRW), you may get interrupts. It's worth a try, I think. If
it works, it's the much better solution.



The HI-311x has a INT pin and a STAT pin. The hardware I have has only
the INT pin connected to the processor. If the STAT pin was also
connected, then like you mentioned it could be a much better solution to
use STAT for state changes.


OK, I understand.


Enabling BUSOFF/ERRP/ERRW bits in STATFE did not generate any interrupts
on the INT pin. Should we make it a requirement that both INT and STAT
pins need to be connected in hardware for the driver to do the error
reporting?


As I said, it's the better solution, especially if interrupt flooding 
does harm. How does your system behave when bus errors come in due to no 
cable connected?


So far using NAPI was mandatory. There is the problem of out-of-order 
message reception if handled in the isr on multi processor systems. 
Marc, what is the current policy?


Wolfgang.

Re: [PATCH v2 2/2] can: spi: hi311x: Add Holt HI-311x CAN driver

2017-03-16 Thread Wolfgang Grandegger

Hello Akshay,

Am 16.03.2017 um 18:06 schrieb Akshay Bhat:
> Hi Wolfgang,
> 
> On 03/15/2017 05:42 AM, Wolfgang Grandegger wrote:
>> Hello Akshay,
>>
> ..snip..
>>>
>>> So here is my plan:
>>> - Have the bus error interrupt always enabled
>>> - If berr-reporting off, then have the isr checks/reports state changes
>>
>> Error state change messages should always be there. These are the
>> important one.
>>
>>> - if berr-reporting on, then have the isr checks/reports bus errors
>>> and state changes (Does it make sense packing the error message, if
>>> the ISR finds both bus and state changes?)
>>
>> If berr-reporting is off, simply do not create an error message for bus
>> errors, and only if the state changed. If it's "on" create an additional
>> bus error message.
>>
>> http://lxr.free-electrons.com/source/drivers/net/can/flexcan.c#L334
>>
>>
> 
> I have fixed the driver to handle the error reporting. Also thanks for
> your tip for generating bus-off by setting the host device at a
> different CAN bit rate! Below are logs with the updated driver. Let me
> know if you have any concerns, if not I will submit the v4 patch.
> 
> berr-reporting on case:
> http://pastebin.com/qDRLERmW

Looks much better now! There are message for state changes to error
warning and passive. Just the following message is not correct:

 (000.200824)  can0  2004   [8]  00 40 00 00 00 00 5F 19   ERRORFRAME
controller-problem{}
error-counter-tx-rx{{95}{25}}

Sorry, forgot to mention... the function can_change_state() [1]
should be used for that purpose, if possible. It fixes the issue
above as well.

> berr-reporting off case:
> http://pastebin.com/fUn3j7qU

Ditto.

I just had another look to the manual and there is this undocumented
STATFE register at offset 0x1E. It's mentioned in some other parts of
the doc as interrupt enable register for STATF events. I would assume
the same bit layout than STATF. If you set bit 2 (BUSOFF), 3 (ERRP)
and 4 (ERRW), you may get interrupts. It's worth a try, I think. If
it works, it's the much better solution.

Wolfgang.

[1] http://lxr.free-electrons.com/ident?i=can_change_state

Wolfgang.

Re: [PATCH v2 2/2] can: spi: hi311x: Add Holt HI-311x CAN driver

2017-03-16 Thread Wolfgang Grandegger

Hello Akshay,

Am 16.03.2017 um 18:06 schrieb Akshay Bhat:
> Hi Wolfgang,
> 
> On 03/15/2017 05:42 AM, Wolfgang Grandegger wrote:
>> Hello Akshay,
>>
> ..snip..
>>>
>>> So here is my plan:
>>> - Have the bus error interrupt always enabled
>>> - If berr-reporting off, then have the isr checks/reports state changes
>>
>> Error state change messages should always be there. These are the
>> important one.
>>
>>> - if berr-reporting on, then have the isr checks/reports bus errors
>>> and state changes (Does it make sense packing the error message, if
>>> the ISR finds both bus and state changes?)
>>
>> If berr-reporting is off, simply do not create an error message for bus
>> errors, and only if the state changed. If it's "on" create an additional
>> bus error message.
>>
>> http://lxr.free-electrons.com/source/drivers/net/can/flexcan.c#L334
>>
>>
> 
> I have fixed the driver to handle the error reporting. Also thanks for
> your tip for generating bus-off by setting the host device at a
> different CAN bit rate! Below are logs with the updated driver. Let me
> know if you have any concerns, if not I will submit the v4 patch.
> 
> berr-reporting on case:
> http://pastebin.com/qDRLERmW

Looks much better now! There are message for state changes to error
warning and passive. Just the following message is not correct:

 (000.200824)  can0  2004   [8]  00 40 00 00 00 00 5F 19   ERRORFRAME
controller-problem{}
error-counter-tx-rx{{95}{25}}

Sorry, forgot to mention... the function can_change_state() [1]
should be used for that purpose, if possible. It fixes the issue
above as well.

> berr-reporting off case:
> http://pastebin.com/fUn3j7qU

Ditto.

I just had another look to the manual and there is this undocumented
STATFE register at offset 0x1E. It's mentioned in some other parts of
the doc as interrupt enable register for STATF events. I would assume
the same bit layout than STATF. If you set bit 2 (BUSOFF), 3 (ERRP)
and 4 (ERRW), you may get interrupts. It's worth a try, I think. If
it works, it's the much better solution.

Wolfgang.

[1] http://lxr.free-electrons.com/ident?i=can_change_state

Wolfgang.

Re: [PATCH v2 2/2] can: spi: hi311x: Add Holt HI-311x CAN driver


Hello Akshay,

Am 15.03.2017 um 05:44 schrieb Akshay Bhat:

Hi Wolfgang,

On Tue, Mar 14, 2017 at 2:08 PM, Wolfgang Grandegger <w...@grandegger.com> 
wrote:
...snip

/disconnect cable
  can0  2088   [8]  00 00 00 19 00 00 28 00   ERRORFRAME
protocol-violation{{}{acknowledge-slot}}
bus-error
error-counter-tx-rx{{40}{0}}
  can0  2088   [8]  00 00 00 19 00 00 58 00   ERRORFRAME
protocol-violation{{}{acknowledge-slot}}
bus-error
error-counter-tx-rx{{88}{0}}
  can0  2088   [8]  00 00 00 19 00 00 80 00   ERRORFRAME
protocol-violation{{}{acknowledge-slot}}
bus-error
error-counter-tx-rx{{128}{0}}



TX error warning is missing.



This support was missing in the driver, added in V4 patch.


  can0  208C   [8]  00 20 00 19 00 00 80 00   ERRORFRAME
controller-problem{tx-error-passive}
protocol-violation{{}{acknowledge-slot}}
bus-error
error-counter-tx-rx{{128}{0}}



Here "tx-error-passiv" is packed with a bus error. What I'm looking for are
state change messages similar to:

   can0  2204  [8] 00 08 00 00 00 00 60 00   ERRORFRAME
controller-problem{tx-error-warning}
state-change{tx-error-warning}
error-counter-tx-rx{{96}{0}}
   can0  2204  [8] 00 30 00 00 00 00 80 00   ERRORFRAME
controller-problem{tx-error-passive}
state-change{tx-error-passive}
error-counter-tx-rx{{128}{0}

They should always come, even with "berr-reporting off".



HI-3110 has only 1 bus error interrupt. There is no dedicated state
change interrupts like other controllers.


I have little hope! Some revision of the flexcan controller have the 
same problem




So here is my plan:
- Have the bus error interrupt always enabled
- If berr-reporting off, then have the isr checks/reports state changes


Error state change messages should always be there. These are the 
important one.



- if berr-reporting on, then have the isr checks/reports bus errors
and state changes (Does it make sense packing the error message, if
the ISR finds both bus and state changes?)


If berr-reporting is off, simply do not create an error message for bus 
errors, and only if the state changed. If it's "on" create an additional 
bus error message.


http://lxr.free-electrons.com/source/drivers/net/can/flexcan.c#L334



write: No buffer space available
root@imx6qrom5420b1:~# ip -s -d link show can0
4: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN
mode DEFAULT group default qlen 10
link/can  promiscuity 0
can  state ERROR-PASSIVE (berr-counter tx 128 rx 0)
restart-ms 0
  bitrate 100 sample-point 0.750
  tq 62 prop-seg 5 phase-seg1 6 phase-seg2 4 sjw 1
  hi3110: tseg1 2..16 tseg2 2..8 sjw 1..4 brp 1..64 brp-inc 1
  clock 1600
  re-started bus-errors arbit-lost error-warn error-pass bus-off
  0  6  0  1  1  0



The error warning and passive counter increased , though. Also the bus error
should come in at a rather hight rate. Looking to the code, maybe
you need to test STATF to check for state changes (and not ERR).



Apologize, just realized In the above case some error packets were
lost, because I forgot to set the CPU frequency to max. Will resend
the log.

..snip...


After some more messages there should be also:

can0  2200  [8] 00 40 00 00 00 00 5F 00   ERRORFRAME
state-change{back-to-error-active}
error-counter-tx-rx{{95}{0}}

For each message sent, the error counter decreases by 8.



The HI-3110 controller decrements the error counter by 1 for every message sent.
The error count increments by 8 when there is an error.


Seems OK according to:

http://electronics.stackexchange.com/questions/220596/can-error-counters-behaviour





root@imx6qrom5420b1:~# ip -s -d link show can0
4: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN
mode DEFAULT group default qlen 10
link/can  promiscuity 0
can state ERROR-ACTIVE (berr-counter tx 117 rx 0) restart-ms 0
  bitrate 100 sample-point 0.750
  tq 62 prop-seg 5 phase-seg1 6 phase-seg2 4 sjw 1
  hi3110: tseg1 2..16 tseg2 2..8 sjw 1..4 brp 1..64 brp-inc 1
  clock 1600
  re-started bus-errors arbit-lost error-warn error-pass bus-off
  0  1  0  0  0  0



Strange, some counters got lost.



This was a bug introduced when adding berr-reporting, have fixed in v4 patch.



I have not been able to check the bus-off condition by (short-circuiting
CAN low and high). The tec error count remains at 128 when I short the
CAN low and high pins and the status never goes BUSOFF.



You also need to send a message and the short-circuit should be at the
connector of the sending host. What tranceiver is used? Do you know?



ADM3054 transceiv

Re: [PATCH v2 2/2] can: spi: hi311x: Add Holt HI-311x CAN driver


Hello Akshay,

Am 15.03.2017 um 05:44 schrieb Akshay Bhat:

Hi Wolfgang,

On Tue, Mar 14, 2017 at 2:08 PM, Wolfgang Grandegger  
wrote:
...snip

/disconnect cable
  can0  2088   [8]  00 00 00 19 00 00 28 00   ERRORFRAME
protocol-violation{{}{acknowledge-slot}}
bus-error
error-counter-tx-rx{{40}{0}}
  can0  2088   [8]  00 00 00 19 00 00 58 00   ERRORFRAME
protocol-violation{{}{acknowledge-slot}}
bus-error
error-counter-tx-rx{{88}{0}}
  can0  2088   [8]  00 00 00 19 00 00 80 00   ERRORFRAME
protocol-violation{{}{acknowledge-slot}}
bus-error
error-counter-tx-rx{{128}{0}}



TX error warning is missing.



This support was missing in the driver, added in V4 patch.


  can0  208C   [8]  00 20 00 19 00 00 80 00   ERRORFRAME
controller-problem{tx-error-passive}
protocol-violation{{}{acknowledge-slot}}
bus-error
error-counter-tx-rx{{128}{0}}



Here "tx-error-passiv" is packed with a bus error. What I'm looking for are
state change messages similar to:

   can0  2204  [8] 00 08 00 00 00 00 60 00   ERRORFRAME
controller-problem{tx-error-warning}
state-change{tx-error-warning}
error-counter-tx-rx{{96}{0}}
   can0  2204  [8] 00 30 00 00 00 00 80 00   ERRORFRAME
controller-problem{tx-error-passive}
state-change{tx-error-passive}
error-counter-tx-rx{{128}{0}

They should always come, even with "berr-reporting off".



HI-3110 has only 1 bus error interrupt. There is no dedicated state
change interrupts like other controllers.


I have little hope! Some revision of the flexcan controller have the 
same problem




So here is my plan:
- Have the bus error interrupt always enabled
- If berr-reporting off, then have the isr checks/reports state changes


Error state change messages should always be there. These are the 
important one.



- if berr-reporting on, then have the isr checks/reports bus errors
and state changes (Does it make sense packing the error message, if
the ISR finds both bus and state changes?)


If berr-reporting is off, simply do not create an error message for bus 
errors, and only if the state changed. If it's "on" create an additional 
bus error message.


http://lxr.free-electrons.com/source/drivers/net/can/flexcan.c#L334



write: No buffer space available
root@imx6qrom5420b1:~# ip -s -d link show can0
4: can0:  mtu 16 qdisc pfifo_fast state UNKNOWN
mode DEFAULT group default qlen 10
link/can  promiscuity 0
can  state ERROR-PASSIVE (berr-counter tx 128 rx 0)
restart-ms 0
  bitrate 100 sample-point 0.750
  tq 62 prop-seg 5 phase-seg1 6 phase-seg2 4 sjw 1
  hi3110: tseg1 2..16 tseg2 2..8 sjw 1..4 brp 1..64 brp-inc 1
  clock 1600
  re-started bus-errors arbit-lost error-warn error-pass bus-off
  0  6  0  1  1  0



The error warning and passive counter increased , though. Also the bus error
should come in at a rather hight rate. Looking to the code, maybe
you need to test STATF to check for state changes (and not ERR).



Apologize, just realized In the above case some error packets were
lost, because I forgot to set the CPU frequency to max. Will resend
the log.

..snip...


After some more messages there should be also:

can0  2200  [8] 00 40 00 00 00 00 5F 00   ERRORFRAME
state-change{back-to-error-active}
error-counter-tx-rx{{95}{0}}

For each message sent, the error counter decreases by 8.



The HI-3110 controller decrements the error counter by 1 for every message sent.
The error count increments by 8 when there is an error.


Seems OK according to:

http://electronics.stackexchange.com/questions/220596/can-error-counters-behaviour





root@imx6qrom5420b1:~# ip -s -d link show can0
4: can0:  mtu 16 qdisc pfifo_fast state UNKNOWN
mode DEFAULT group default qlen 10
link/can  promiscuity 0
can state ERROR-ACTIVE (berr-counter tx 117 rx 0) restart-ms 0
  bitrate 100 sample-point 0.750
  tq 62 prop-seg 5 phase-seg1 6 phase-seg2 4 sjw 1
  hi3110: tseg1 2..16 tseg2 2..8 sjw 1..4 brp 1..64 brp-inc 1
  clock 1600
  re-started bus-errors arbit-lost error-warn error-pass bus-off
  0  1  0  0  0  0



Strange, some counters got lost.



This was a bug introduced when adding berr-reporting, have fixed in v4 patch.



I have not been able to check the bus-off condition by (short-circuiting
CAN low and high). The tec error count remains at 128 when I short the
CAN low and high pins and the status never goes BUSOFF.



You also need to send a message and the short-circuit should be at the
connector of the sending host. What tranceiver is used? Do you know?



ADM3054 transceiver is used with HI-3111. I connected the
HI-3111/ADM3054 board to kvaser leaf and ran "ca

Re: [PATCH v2 2/2] can: spi: hi311x: Add Holt HI-311x CAN driver


Hello Akshay,

Am 15.03.2017 um 05:44 schrieb Akshay Bhat:

Hi Wolfgang,

On Tue, Mar 14, 2017 at 2:08 PM, Wolfgang Grandegger <w...@grandegger.com> 
wrote:
...snip

/disconnect cable
  can0  2088   [8]  00 00 00 19 00 00 28 00   ERRORFRAME
protocol-violation{{}{acknowledge-slot}}
bus-error
error-counter-tx-rx{{40}{0}}
  can0  2088   [8]  00 00 00 19 00 00 58 00   ERRORFRAME
protocol-violation{{}{acknowledge-slot}}
bus-error
error-counter-tx-rx{{88}{0}}
  can0  2088   [8]  00 00 00 19 00 00 80 00   ERRORFRAME
protocol-violation{{}{acknowledge-slot}}
bus-error
error-counter-tx-rx{{128}{0}}



TX error warning is missing.



This support was missing in the driver, added in V4 patch.


  can0  208C   [8]  00 20 00 19 00 00 80 00   ERRORFRAME
controller-problem{tx-error-passive}
protocol-violation{{}{acknowledge-slot}}
bus-error
error-counter-tx-rx{{128}{0}}



Here "tx-error-passiv" is packed with a bus error. What I'm looking for are
state change messages similar to:

   can0  2204  [8] 00 08 00 00 00 00 60 00   ERRORFRAME
controller-problem{tx-error-warning}
state-change{tx-error-warning}
error-counter-tx-rx{{96}{0}}
   can0  2204  [8] 00 30 00 00 00 00 80 00   ERRORFRAME
controller-problem{tx-error-passive}
state-change{tx-error-passive}
error-counter-tx-rx{{128}{0}

They should always come, even with "berr-reporting off".



HI-3110 has only 1 bus error interrupt. There is no dedicated state
change interrupts like other controllers.


To double check: Could you please read INTF, ERR and STATF at the 
beginning of the ISR and print it out (using dev_dbg and fiends). Then 
run a test with no cable connected and bus error reporting off.


Wolfgang.

Re: [PATCH v2 2/2] can: spi: hi311x: Add Holt HI-311x CAN driver


Hello Akshay,

Am 15.03.2017 um 05:44 schrieb Akshay Bhat:

Hi Wolfgang,

On Tue, Mar 14, 2017 at 2:08 PM, Wolfgang Grandegger  
wrote:
...snip

/disconnect cable
  can0  2088   [8]  00 00 00 19 00 00 28 00   ERRORFRAME
protocol-violation{{}{acknowledge-slot}}
bus-error
error-counter-tx-rx{{40}{0}}
  can0  2088   [8]  00 00 00 19 00 00 58 00   ERRORFRAME
protocol-violation{{}{acknowledge-slot}}
bus-error
error-counter-tx-rx{{88}{0}}
  can0  2088   [8]  00 00 00 19 00 00 80 00   ERRORFRAME
protocol-violation{{}{acknowledge-slot}}
bus-error
error-counter-tx-rx{{128}{0}}



TX error warning is missing.



This support was missing in the driver, added in V4 patch.


  can0  208C   [8]  00 20 00 19 00 00 80 00   ERRORFRAME
controller-problem{tx-error-passive}
protocol-violation{{}{acknowledge-slot}}
bus-error
error-counter-tx-rx{{128}{0}}



Here "tx-error-passiv" is packed with a bus error. What I'm looking for are
state change messages similar to:

   can0  2204  [8] 00 08 00 00 00 00 60 00   ERRORFRAME
controller-problem{tx-error-warning}
state-change{tx-error-warning}
error-counter-tx-rx{{96}{0}}
   can0  2204  [8] 00 30 00 00 00 00 80 00   ERRORFRAME
controller-problem{tx-error-passive}
state-change{tx-error-passive}
error-counter-tx-rx{{128}{0}

They should always come, even with "berr-reporting off".



HI-3110 has only 1 bus error interrupt. There is no dedicated state
change interrupts like other controllers.


To double check: Could you please read INTF, ERR and STATF at the 
beginning of the ISR and print it out (using dev_dbg and fiends). Then 
run a test with no cable connected and bus error reporting off.


Wolfgang.

Re: [PATCH v2 2/2] can: spi: hi311x: Add Holt HI-311x CAN driver


Am 14.03.2017 um 19:08 schrieb Wolfgang Grandegger:

Hello Akshay,

Am 14.03.2017 um 17:20 schrieb Akshay Bhat:


Hi Wolfgang,

On 03/14/2017 08:11 AM, Wolfgang Grandegger wrote:

... snip ...

A few other things to check:

Run "cangen" and monitor the message with "candump -e
any,0:0,#FFF".
Then 1) disconnect the cable or 2) short-circuit CAN low and high
at the
connector. You should see error messages. After reconnection or
removing
the short-circuit (and bus-off recovery) the state should go back to
"active".



With the above sequence, candump reports "ERRORFRAME" with
protocol-violation{{}{acknowledge-slot}}, bus-error. On re-connecting
the cable the can state goes back to ACTIVE and I see the messages that
were in the queue being sent.


Do you get the ACK error also with berr-reporting off? Would be nice if
you could show a candump log here.



Below is a log for disconnecting and re-connecting CAN cable scenario:
(Note this is on a 4.1.18 kernel with RT patch)

root@imx6qrom5420b1:~# ip link set can0 up type can bitrate 100
berr-reporting on
root@imx6qrom5420b1:~# candump -e any,0:0,#FFF &


Please add "-td" ...


[1] 768
root@imx6qrom5420b1:~# cangen can0


and "-i" here.


  can0  21C   [8]  35 98 C0 7A 95 03 E6 2A
  can0  6E6   [1]  F2
  can0  5C7   [2]  42 50
  can0  57C   [8]  83 7A E4 0C 03 8B 90 45
  can0  55C   [8]  B9 74 87 52 D8 F4 64 04
  can0  014   [8]  28 CB 96 57 3B 80 67 4F
  can0  6AF   [1]  35
  can0  51E   [8]  B6 C8 6C 1D 3A 87 ED 2E
  can0  527   [8]  D0 8A D3 59 0E 34 40 78
  can0  30C   [2]  6A 12
  can0  145   [8]  CB 6E FF 55 C1 BE C3 22
  can0  5A5   [8]  C4 49 54 68 02 63 F9 35
  can0  0BA   [8]  DA 57 5E 3A CE 88 20 1C
  can0  516   [2]  09 09
  can0  743   [8]  7C 4D 25 47 61 4C 56 3D
  can0  31D   [2]  9C D3
  can0  71E   [8]  53 7C 97 2A 2A F2 9F 56
  can0  52E   [8]  FE DA 2D 51 73 96 DF 79
/disconnect cable
  can0  2088   [8]  00 00 00 19 00 00 28 00   ERRORFRAME
protocol-violation{{}{acknowledge-slot}}
bus-error
error-counter-tx-rx{{40}{0}}
  can0  2088   [8]  00 00 00 19 00 00 58 00   ERRORFRAME
protocol-violation{{}{acknowledge-slot}}
bus-error
error-counter-tx-rx{{88}{0}}
  can0  2088   [8]  00 00 00 19 00 00 80 00   ERRORFRAME
protocol-violation{{}{acknowledge-slot}}
bus-error
error-counter-tx-rx{{128}{0}}


TX error warning is missing.


  can0  208C   [8]  00 20 00 19 00 00 80 00   ERRORFRAME
controller-problem{tx-error-passive}
protocol-violation{{}{acknowledge-slot}}
bus-error
error-counter-tx-rx{{128}{0}}


Here "tx-error-passiv" is packed with a bus error. What I'm looking for
are state change messages similar to:

   can0  2204  [8] 00 08 00 00 00 00 60 00   ERRORFRAME
controller-problem{tx-error-warning}
state-change{tx-error-warning}
error-counter-tx-rx{{96}{0}}
   can0  2204  [8] 00 30 00 00 00 00 80 00   ERRORFRAME
controller-problem{tx-error-passive}
state-change{tx-error-passive}
error-counter-tx-rx{{128}{0}

They should always come, even with "berr-reporting off".


write: No buffer space available
root@imx6qrom5420b1:~# ip -s -d link show can0
4: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN
mode DEFAULT group default qlen 10
link/can  promiscuity 0
can  state ERROR-PASSIVE (berr-counter tx 128 rx 0)
restart-ms 0
  bitrate 100 sample-point 0.750
  tq 62 prop-seg 5 phase-seg1 6 phase-seg2 4 sjw 1
  hi3110: tseg1 2..16 tseg2 2..8 sjw 1..4 brp 1..64 brp-inc 1
  clock 1600
  re-started bus-errors arbit-lost error-warn error-pass bus-off
  0  6  0  1  1  0


The error warning and passive counter increased , though. Also the bus
error should come in at a rather hight rate. Looking to the code, maybe
you need to test STATF to check for state changes (and not ERR).


Likely the ERR bits are only valid if the BUSERR bit in INTF is set.


RX: bytes  packets  errors  dropped overrun mcast
0  06   0   0   0
TX: bytes  packets  errors  dropped carrier collsns
10618   0   0   0   0
root@imx6qrom5420b1:~#
/re-connect cable
  can0  169   [8]  35 55 A3 1C 0F 47 2E 5B
  can0  318   [8]  11 AA 27 11 D2 1B CE 34
  can0  577   [8]  A0 A4 EE 50 8D A2 E1 3E
  can0  4ED   [8]  52 96 17 7E 31 FC 7D 7C
  can0  2E7   [8]  92 48 D4 39 05 1E 9F 50
  can0  200   [8]  4A 66 F6 02 1E 71 8E 26
  can0  29A   [8]  49 63 2E 7D C9 77 85 7A
  can0  15A   [7]  3C 0E 65 74 C3 62 80
  can0  011   [1]  D2
  can0  26B   [3]  FC D6 68
  can0  5CE   [8]  6F 02 B5 14 BC 7A D7 02

root@imx6qrom5420b1:~# ip -s -d link show can0
4: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN
mode DEFAULT group default qlen 10
link/can  promiscuity 0
can  state ERROR-ACT

Re: [PATCH v2 2/2] can: spi: hi311x: Add Holt HI-311x CAN driver


Am 14.03.2017 um 19:08 schrieb Wolfgang Grandegger:

Hello Akshay,

Am 14.03.2017 um 17:20 schrieb Akshay Bhat:


Hi Wolfgang,

On 03/14/2017 08:11 AM, Wolfgang Grandegger wrote:

... snip ...

A few other things to check:

Run "cangen" and monitor the message with "candump -e
any,0:0,#FFF".
Then 1) disconnect the cable or 2) short-circuit CAN low and high
at the
connector. You should see error messages. After reconnection or
removing
the short-circuit (and bus-off recovery) the state should go back to
"active".



With the above sequence, candump reports "ERRORFRAME" with
protocol-violation{{}{acknowledge-slot}}, bus-error. On re-connecting
the cable the can state goes back to ACTIVE and I see the messages that
were in the queue being sent.


Do you get the ACK error also with berr-reporting off? Would be nice if
you could show a candump log here.



Below is a log for disconnecting and re-connecting CAN cable scenario:
(Note this is on a 4.1.18 kernel with RT patch)

root@imx6qrom5420b1:~# ip link set can0 up type can bitrate 100
berr-reporting on
root@imx6qrom5420b1:~# candump -e any,0:0,#FFF &


Please add "-td" ...


[1] 768
root@imx6qrom5420b1:~# cangen can0


and "-i" here.


  can0  21C   [8]  35 98 C0 7A 95 03 E6 2A
  can0  6E6   [1]  F2
  can0  5C7   [2]  42 50
  can0  57C   [8]  83 7A E4 0C 03 8B 90 45
  can0  55C   [8]  B9 74 87 52 D8 F4 64 04
  can0  014   [8]  28 CB 96 57 3B 80 67 4F
  can0  6AF   [1]  35
  can0  51E   [8]  B6 C8 6C 1D 3A 87 ED 2E
  can0  527   [8]  D0 8A D3 59 0E 34 40 78
  can0  30C   [2]  6A 12
  can0  145   [8]  CB 6E FF 55 C1 BE C3 22
  can0  5A5   [8]  C4 49 54 68 02 63 F9 35
  can0  0BA   [8]  DA 57 5E 3A CE 88 20 1C
  can0  516   [2]  09 09
  can0  743   [8]  7C 4D 25 47 61 4C 56 3D
  can0  31D   [2]  9C D3
  can0  71E   [8]  53 7C 97 2A 2A F2 9F 56
  can0  52E   [8]  FE DA 2D 51 73 96 DF 79
/disconnect cable
  can0  2088   [8]  00 00 00 19 00 00 28 00   ERRORFRAME
protocol-violation{{}{acknowledge-slot}}
bus-error
error-counter-tx-rx{{40}{0}}
  can0  2088   [8]  00 00 00 19 00 00 58 00   ERRORFRAME
protocol-violation{{}{acknowledge-slot}}
bus-error
error-counter-tx-rx{{88}{0}}
  can0  2088   [8]  00 00 00 19 00 00 80 00   ERRORFRAME
protocol-violation{{}{acknowledge-slot}}
bus-error
error-counter-tx-rx{{128}{0}}


TX error warning is missing.


  can0  208C   [8]  00 20 00 19 00 00 80 00   ERRORFRAME
controller-problem{tx-error-passive}
protocol-violation{{}{acknowledge-slot}}
bus-error
error-counter-tx-rx{{128}{0}}


Here "tx-error-passiv" is packed with a bus error. What I'm looking for
are state change messages similar to:

   can0  2204  [8] 00 08 00 00 00 00 60 00   ERRORFRAME
controller-problem{tx-error-warning}
state-change{tx-error-warning}
error-counter-tx-rx{{96}{0}}
   can0  2204  [8] 00 30 00 00 00 00 80 00   ERRORFRAME
controller-problem{tx-error-passive}
state-change{tx-error-passive}
error-counter-tx-rx{{128}{0}

They should always come, even with "berr-reporting off".


write: No buffer space available
root@imx6qrom5420b1:~# ip -s -d link show can0
4: can0:  mtu 16 qdisc pfifo_fast state UNKNOWN
mode DEFAULT group default qlen 10
link/can  promiscuity 0
can  state ERROR-PASSIVE (berr-counter tx 128 rx 0)
restart-ms 0
  bitrate 100 sample-point 0.750
  tq 62 prop-seg 5 phase-seg1 6 phase-seg2 4 sjw 1
  hi3110: tseg1 2..16 tseg2 2..8 sjw 1..4 brp 1..64 brp-inc 1
  clock 1600
  re-started bus-errors arbit-lost error-warn error-pass bus-off
  0  6  0  1  1  0


The error warning and passive counter increased , though. Also the bus
error should come in at a rather hight rate. Looking to the code, maybe
you need to test STATF to check for state changes (and not ERR).


Likely the ERR bits are only valid if the BUSERR bit in INTF is set.


RX: bytes  packets  errors  dropped overrun mcast
0  06   0   0   0
TX: bytes  packets  errors  dropped carrier collsns
10618   0   0   0   0
root@imx6qrom5420b1:~#
/re-connect cable
  can0  169   [8]  35 55 A3 1C 0F 47 2E 5B
  can0  318   [8]  11 AA 27 11 D2 1B CE 34
  can0  577   [8]  A0 A4 EE 50 8D A2 E1 3E
  can0  4ED   [8]  52 96 17 7E 31 FC 7D 7C
  can0  2E7   [8]  92 48 D4 39 05 1E 9F 50
  can0  200   [8]  4A 66 F6 02 1E 71 8E 26
  can0  29A   [8]  49 63 2E 7D C9 77 85 7A
  can0  15A   [7]  3C 0E 65 74 C3 62 80
  can0  011   [1]  D2
  can0  26B   [3]  FC D6 68
  can0  5CE   [8]  6F 02 B5 14 BC 7A D7 02

root@imx6qrom5420b1:~# ip -s -d link show can0
4: can0:  mtu 16 qdisc pfifo_fast state UNKNOWN
mode DEFAULT group default qlen 10
link/can  promiscuity 0
can  state ERROR-ACTIVE (berr-counter tx 117 rx 0)
restart-ms 0
  bitra

Re: [PATCH v2 2/2] can: spi: hi311x: Add Holt HI-311x CAN driver


Hello Akshay,

Am 14.03.2017 um 17:20 schrieb Akshay Bhat:


Hi Wolfgang,

On 03/14/2017 08:11 AM, Wolfgang Grandegger wrote:

... snip ...

A few other things to check:

Run "cangen" and monitor the message with "candump -e any,0:0,#FFF".
Then 1) disconnect the cable or 2) short-circuit CAN low and high at the
connector. You should see error messages. After reconnection or removing
the short-circuit (and bus-off recovery) the state should go back to
"active".



With the above sequence, candump reports "ERRORFRAME" with
protocol-violation{{}{acknowledge-slot}}, bus-error. On re-connecting
the cable the can state goes back to ACTIVE and I see the messages that
were in the queue being sent.


Do you get the ACK error also with berr-reporting off? Would be nice if
you could show a candump log here.



Below is a log for disconnecting and re-connecting CAN cable scenario:
(Note this is on a 4.1.18 kernel with RT patch)

root@imx6qrom5420b1:~# ip link set can0 up type can bitrate 100
berr-reporting on
root@imx6qrom5420b1:~# candump -e any,0:0,#FFF &


Please add "-td" ...


[1] 768
root@imx6qrom5420b1:~# cangen can0


and "-i" here.


  can0  21C   [8]  35 98 C0 7A 95 03 E6 2A
  can0  6E6   [1]  F2
  can0  5C7   [2]  42 50
  can0  57C   [8]  83 7A E4 0C 03 8B 90 45
  can0  55C   [8]  B9 74 87 52 D8 F4 64 04
  can0  014   [8]  28 CB 96 57 3B 80 67 4F
  can0  6AF   [1]  35
  can0  51E   [8]  B6 C8 6C 1D 3A 87 ED 2E
  can0  527   [8]  D0 8A D3 59 0E 34 40 78
  can0  30C   [2]  6A 12
  can0  145   [8]  CB 6E FF 55 C1 BE C3 22
  can0  5A5   [8]  C4 49 54 68 02 63 F9 35
  can0  0BA   [8]  DA 57 5E 3A CE 88 20 1C
  can0  516   [2]  09 09
  can0  743   [8]  7C 4D 25 47 61 4C 56 3D
  can0  31D   [2]  9C D3
  can0  71E   [8]  53 7C 97 2A 2A F2 9F 56
  can0  52E   [8]  FE DA 2D 51 73 96 DF 79
/disconnect cable
  can0  2088   [8]  00 00 00 19 00 00 28 00   ERRORFRAME
protocol-violation{{}{acknowledge-slot}}
bus-error
error-counter-tx-rx{{40}{0}}
  can0  2088   [8]  00 00 00 19 00 00 58 00   ERRORFRAME
protocol-violation{{}{acknowledge-slot}}
bus-error
error-counter-tx-rx{{88}{0}}
  can0  2088   [8]  00 00 00 19 00 00 80 00   ERRORFRAME
protocol-violation{{}{acknowledge-slot}}
bus-error
error-counter-tx-rx{{128}{0}}


TX error warning is missing.


  can0  208C   [8]  00 20 00 19 00 00 80 00   ERRORFRAME
controller-problem{tx-error-passive}
protocol-violation{{}{acknowledge-slot}}
bus-error
error-counter-tx-rx{{128}{0}}


Here "tx-error-passiv" is packed with a bus error. What I'm looking for 
are state change messages similar to:


   can0  2204  [8] 00 08 00 00 00 00 60 00   ERRORFRAME
controller-problem{tx-error-warning}
state-change{tx-error-warning}
error-counter-tx-rx{{96}{0}}
   can0  2204  [8] 00 30 00 00 00 00 80 00   ERRORFRAME
controller-problem{tx-error-passive}
state-change{tx-error-passive}
error-counter-tx-rx{{128}{0}

They should always come, even with "berr-reporting off".


write: No buffer space available
root@imx6qrom5420b1:~# ip -s -d link show can0
4: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN
mode DEFAULT group default qlen 10
link/can  promiscuity 0
can  state ERROR-PASSIVE (berr-counter tx 128 rx 0)
restart-ms 0
  bitrate 100 sample-point 0.750
  tq 62 prop-seg 5 phase-seg1 6 phase-seg2 4 sjw 1
  hi3110: tseg1 2..16 tseg2 2..8 sjw 1..4 brp 1..64 brp-inc 1
  clock 1600
  re-started bus-errors arbit-lost error-warn error-pass bus-off
  0  6  0  1  1  0


The error warning and passive counter increased , though. Also the bus 
error should come in at a rather hight rate. Looking to the code, maybe

you need to test STATF to check for state changes (and not ERR).


RX: bytes  packets  errors  dropped overrun mcast
0  06   0   0   0
TX: bytes  packets  errors  dropped carrier collsns
10618   0   0   0   0
root@imx6qrom5420b1:~#
/re-connect cable
  can0  169   [8]  35 55 A3 1C 0F 47 2E 5B
  can0  318   [8]  11 AA 27 11 D2 1B CE 34
  can0  577   [8]  A0 A4 EE 50 8D A2 E1 3E
  can0  4ED   [8]  52 96 17 7E 31 FC 7D 7C
  can0  2E7   [8]  92 48 D4 39 05 1E 9F 50
  can0  200   [8]  4A 66 F6 02 1E 71 8E 26
  can0  29A   [8]  49 63 2E 7D C9 77 85 7A
  can0  15A   [7]  3C 0E 65 74 C3 62 80
  can0  011   [1]  D2
  can0  26B   [3]  FC D6 68
  can0  5CE   [8]  6F 02 B5 14 BC 7A D7 02

root@imx6qrom5420b1:~# ip -s -d link show can0
4: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN
mode DEFAULT group default qlen 10
link/can  promiscuity 0
can  state ERROR-ACTIVE (berr-counter tx 117 rx 0)
restart-ms 0

Re: [PATCH v2 2/2] can: spi: hi311x: Add Holt HI-311x CAN driver


Hello Akshay,

Am 14.03.2017 um 17:20 schrieb Akshay Bhat:


Hi Wolfgang,

On 03/14/2017 08:11 AM, Wolfgang Grandegger wrote:

... snip ...

A few other things to check:

Run "cangen" and monitor the message with "candump -e any,0:0,#FFF".
Then 1) disconnect the cable or 2) short-circuit CAN low and high at the
connector. You should see error messages. After reconnection or removing
the short-circuit (and bus-off recovery) the state should go back to
"active".



With the above sequence, candump reports "ERRORFRAME" with
protocol-violation{{}{acknowledge-slot}}, bus-error. On re-connecting
the cable the can state goes back to ACTIVE and I see the messages that
were in the queue being sent.


Do you get the ACK error also with berr-reporting off? Would be nice if
you could show a candump log here.



Below is a log for disconnecting and re-connecting CAN cable scenario:
(Note this is on a 4.1.18 kernel with RT patch)

root@imx6qrom5420b1:~# ip link set can0 up type can bitrate 100
berr-reporting on
root@imx6qrom5420b1:~# candump -e any,0:0,#FFF &


Please add "-td" ...


[1] 768
root@imx6qrom5420b1:~# cangen can0


and "-i" here.


  can0  21C   [8]  35 98 C0 7A 95 03 E6 2A
  can0  6E6   [1]  F2
  can0  5C7   [2]  42 50
  can0  57C   [8]  83 7A E4 0C 03 8B 90 45
  can0  55C   [8]  B9 74 87 52 D8 F4 64 04
  can0  014   [8]  28 CB 96 57 3B 80 67 4F
  can0  6AF   [1]  35
  can0  51E   [8]  B6 C8 6C 1D 3A 87 ED 2E
  can0  527   [8]  D0 8A D3 59 0E 34 40 78
  can0  30C   [2]  6A 12
  can0  145   [8]  CB 6E FF 55 C1 BE C3 22
  can0  5A5   [8]  C4 49 54 68 02 63 F9 35
  can0  0BA   [8]  DA 57 5E 3A CE 88 20 1C
  can0  516   [2]  09 09
  can0  743   [8]  7C 4D 25 47 61 4C 56 3D
  can0  31D   [2]  9C D3
  can0  71E   [8]  53 7C 97 2A 2A F2 9F 56
  can0  52E   [8]  FE DA 2D 51 73 96 DF 79
/disconnect cable
  can0  2088   [8]  00 00 00 19 00 00 28 00   ERRORFRAME
protocol-violation{{}{acknowledge-slot}}
bus-error
error-counter-tx-rx{{40}{0}}
  can0  2088   [8]  00 00 00 19 00 00 58 00   ERRORFRAME
protocol-violation{{}{acknowledge-slot}}
bus-error
error-counter-tx-rx{{88}{0}}
  can0  2088   [8]  00 00 00 19 00 00 80 00   ERRORFRAME
protocol-violation{{}{acknowledge-slot}}
bus-error
error-counter-tx-rx{{128}{0}}


TX error warning is missing.


  can0  208C   [8]  00 20 00 19 00 00 80 00   ERRORFRAME
controller-problem{tx-error-passive}
protocol-violation{{}{acknowledge-slot}}
bus-error
error-counter-tx-rx{{128}{0}}


Here "tx-error-passiv" is packed with a bus error. What I'm looking for 
are state change messages similar to:


   can0  2204  [8] 00 08 00 00 00 00 60 00   ERRORFRAME
controller-problem{tx-error-warning}
state-change{tx-error-warning}
error-counter-tx-rx{{96}{0}}
   can0  2204  [8] 00 30 00 00 00 00 80 00   ERRORFRAME
controller-problem{tx-error-passive}
state-change{tx-error-passive}
error-counter-tx-rx{{128}{0}

They should always come, even with "berr-reporting off".


write: No buffer space available
root@imx6qrom5420b1:~# ip -s -d link show can0
4: can0:  mtu 16 qdisc pfifo_fast state UNKNOWN
mode DEFAULT group default qlen 10
link/can  promiscuity 0
can  state ERROR-PASSIVE (berr-counter tx 128 rx 0)
restart-ms 0
  bitrate 100 sample-point 0.750
  tq 62 prop-seg 5 phase-seg1 6 phase-seg2 4 sjw 1
  hi3110: tseg1 2..16 tseg2 2..8 sjw 1..4 brp 1..64 brp-inc 1
  clock 1600
  re-started bus-errors arbit-lost error-warn error-pass bus-off
  0  6  0  1  1  0


The error warning and passive counter increased , though. Also the bus 
error should come in at a rather hight rate. Looking to the code, maybe

you need to test STATF to check for state changes (and not ERR).


RX: bytes  packets  errors  dropped overrun mcast
0  06   0   0   0
TX: bytes  packets  errors  dropped carrier collsns
10618   0   0   0   0
root@imx6qrom5420b1:~#
/re-connect cable
  can0  169   [8]  35 55 A3 1C 0F 47 2E 5B
  can0  318   [8]  11 AA 27 11 D2 1B CE 34
  can0  577   [8]  A0 A4 EE 50 8D A2 E1 3E
  can0  4ED   [8]  52 96 17 7E 31 FC 7D 7C
  can0  2E7   [8]  92 48 D4 39 05 1E 9F 50
  can0  200   [8]  4A 66 F6 02 1E 71 8E 26
  can0  29A   [8]  49 63 2E 7D C9 77 85 7A
  can0  15A   [7]  3C 0E 65 74 C3 62 80
  can0  011   [1]  D2
  can0  26B   [3]  FC D6 68
  can0  5CE   [8]  6F 02 B5 14 BC 7A D7 02

root@imx6qrom5420b1:~# ip -s -d link show can0
4: can0:  mtu 16 qdisc pfifo_fast state UNKNOWN
mode DEFAULT group default qlen 10
link/can  promiscuity 0
can  state ERROR-ACTIVE (berr-counter tx 117 rx 0)
restart-ms 0
  bitrate 100 sample-point 0.750
  tq 62 pro

Re: [PATCH v2 2/2] can: spi: hi311x: Add Holt HI-311x CAN driver


Hallo Akshay,

Am 13.03.2017 um 16:38 schrieb Akshay Bhat:

Hi Wolfgang,

On 03/09/2017 12:36 PM, Wolfgang Grandegger wrote:

Hello,

doing a quick review... I realized a few issues...

Am 17.01.2017 um 20:22 schrieb Akshay Bhat:

... snip ...

A few other things to check:

Run "cangen" and monitor the message with "candump -e any,0:0,#FFF".
Then 1) disconnect the cable or 2) short-circuit CAN low and high at the
connector. You should see error messages. After reconnection or removing
the short-circuit (and bus-off recovery) the state should go back to
"active".



With the above sequence, candump reports "ERRORFRAME" with
protocol-violation{{}{acknowledge-slot}}, bus-error. On re-connecting
the cable the can state goes back to ACTIVE and I see the messages that
were in the queue being sent.


Do you get the ACK error also with berr-reporting off? Would be nice if 
you could show a candump log here.


Also, any error message should show the bus error counts in data[7,8]:

http://lxr.free-electrons.com/source/drivers/net/can/sja1000/sja1000.c#L408

And please check bus-off as well (short-circuiting CAN low and high).

Wolfgang.

Re: [PATCH v2 2/2] can: spi: hi311x: Add Holt HI-311x CAN driver


Hallo Akshay,

Am 13.03.2017 um 16:38 schrieb Akshay Bhat:

Hi Wolfgang,

On 03/09/2017 12:36 PM, Wolfgang Grandegger wrote:

Hello,

doing a quick review... I realized a few issues...

Am 17.01.2017 um 20:22 schrieb Akshay Bhat:

... snip ...

A few other things to check:

Run "cangen" and monitor the message with "candump -e any,0:0,#FFF".
Then 1) disconnect the cable or 2) short-circuit CAN low and high at the
connector. You should see error messages. After reconnection or removing
the short-circuit (and bus-off recovery) the state should go back to
"active".



With the above sequence, candump reports "ERRORFRAME" with
protocol-violation{{}{acknowledge-slot}}, bus-error. On re-connecting
the cable the can state goes back to ACTIVE and I see the messages that
were in the queue being sent.


Do you get the ACK error also with berr-reporting off? Would be nice if 
you could show a candump log here.


Also, any error message should show the bus error counts in data[7,8]:

http://lxr.free-electrons.com/source/drivers/net/can/sja1000/sja1000.c#L408

And please check bus-off as well (short-circuiting CAN low and high).

Wolfgang.

Re: [PATCH v2 2/2] can: spi: hi311x: Add Holt HI-311x CAN driver


Hello,

doing a quick review... I realized a few issues...

Am 17.01.2017 um 20:22 schrieb Akshay Bhat:

This patch adds support for the Holt HI-311x CAN controller. The HI311x
CAN controller is capable of transmitting and receiving standard data
frames, extended data frames and remote frames. The HI311x interfaces
with the host over SPI.

Datasheet: www.holtic.com/documents/371-hi-3110_v-rev-jpdf.do

Signed-off-by: Akshay Bhat 
---

v1 -> v2:
Address comments from Marc Kleine-Budde:
- use u8 instead of uint8_t
- alphabetically sort Makefile and Kconfig
- copy over copyright information from mcp251x
- use single space after each marco
- add missing HI3110_ namespace in defines
- remove magic number for IDE & SRR bits
- simplify logic to populate extended CAN ID
- remove unused parameters in hi3110_setup function
- remove redundant frame->can_dlc length check
- simplify error handling in hi3110_open function
Address comments from Julia Lawall:
- remove unnecessary semicolon after while loop in hi3110_can_ist

 drivers/net/can/spi/Kconfig  |6 +
 drivers/net/can/spi/Makefile |1 +
 drivers/net/can/spi/hi311x.c | 1069 ++
 3 files changed, 1076 insertions(+)
 create mode 100644 drivers/net/can/spi/hi311x.c

diff --git a/drivers/net/can/spi/Kconfig b/drivers/net/can/spi/Kconfig
index 148cae5..8f2e0dd 100644
--- a/drivers/net/can/spi/Kconfig
+++ b/drivers/net/can/spi/Kconfig
@@ -1,6 +1,12 @@
 menu "CAN SPI interfaces"
depends on SPI

+config CAN_HI311X
+   tristate "Holt HI311x SPI CAN controllers"
+   depends on CAN_DEV && SPI && HAS_DMA
+   ---help---
+ Driver for the Holt HI311x SPI CAN controllers.
+
 config CAN_MCP251X
tristate "Microchip MCP251x SPI CAN controllers"
depends on HAS_DMA
diff --git a/drivers/net/can/spi/Makefile b/drivers/net/can/spi/Makefile
index 0e86040..f59fa37 100644
--- a/drivers/net/can/spi/Makefile
+++ b/drivers/net/can/spi/Makefile
@@ -3,4 +3,5 @@
 #


+obj-$(CONFIG_CAN_HI311X)   += hi311x.o
 obj-$(CONFIG_CAN_MCP251X)  += mcp251x.o
diff --git a/drivers/net/can/spi/hi311x.c b/drivers/net/can/spi/hi311x.c
new file mode 100644
index 000..cccfe2d
--- /dev/null
+++ b/drivers/net/can/spi/hi311x.c
@@ -0,0 +1,1069 @@
+/* CAN bus driver for Holt HI3110 CAN Controller with SPI Interface
+ *
+ * Copyright(C) Timesys Corporation 2016
+ *
+ * Based on Microchip 251x CAN Controller (mcp251x) Linux kernel driver
+ * Copyright 2009 Christian Pellegrin EVOL S.r.l.
+ * Copyright 2007 Raymarine UK, Ltd. All Rights Reserved.
+ * Copyright 2006 Arcom Control Systems Ltd.
+ *
+ * Based on CAN bus driver for the CCAN controller written by
+ * - Sascha Hauer, Marc Kleine-Budde, Pengutronix
+ * - Simon Kallweit, intefo AG
+ * Copyright 2007
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define HI3110_MASTER_RESET 0x56
+#define HI3110_READ_CTRL0 0xD2
+#define HI3110_READ_CTRL1 0xD4
+#define HI3110_READ_STATF 0xE2
+#define HI3110_WRITE_CTRL0 0x14
+#define HI3110_WRITE_CTRL1 0x16
+#define HI3110_WRITE_INTE 0x1C
+#define HI3110_WRITE_BTR0 0x18
+#define HI3110_WRITE_BTR1 0x1A
+#define HI3110_READ_BTR0 0xD6
+#define HI3110_READ_BTR1 0xD8
+#define HI3110_READ_INTF 0xDE
+#define HI3110_READ_ERR 0xDC
+#define HI3110_READ_FIFO_WOTIME 0x48
+#define HI3110_WRITE_FIFO 0x12
+#define HI3110_READ_MESSTAT 0xDA
+#define HI3110_READ_TEC 0xEC
+
+#define HI3110_CTRL0_MODE_MASK (7 << 5)
+#define HI3110_CTRL0_NORMAL_MODE (0 << 5)
+#define HI3110_CTRL0_LOOPBACK_MODE (1 << 5)
+#define HI3110_CTRL0_MONITOR_MODE (2 << 5)
+#define HI3110_CTRL0_SLEEP_MODE (3 << 5)
+#define HI3110_CTRL0_INIT_MODE (4 << 5)
+
+#define HI3110_CTRL1_TXEN BIT(7)
+
+#define HI3110_INT_RXTMP BIT(7)
+#define HI3110_INT_RXFIFO BIT(6)
+#define HI3110_INT_TXCPLT BIT(5)
+#define HI3110_INT_BUSERR BIT(4)
+#define HI3110_INT_MCHG BIT(3)
+#define HI3110_INT_WAKEUP BIT(2)
+#define HI3110_INT_F1MESS BIT(1)
+#define HI3110_INT_F0MESS BIT(0)
+
+#define HI3110_ERR_BUSOFF BIT(7)
+#define HI3110_ERR_TXERRP BIT(6)
+#define HI3110_ERR_RXERRP BIT(5)
+#define HI3110_ERR_BITERR BIT(4)
+#define HI3110_ERR_FRMERR BIT(3)
+#define HI3110_ERR_CRCERR BIT(2)
+#define HI3110_ERR_ACKERR BIT(1)
+#define HI3110_ERR_STUFERR BIT(0)
+#define HI3110_ERR_PROTOCOL_MASK (0x1F)
+
+#define HI3110_STAT_RXFMTY BIT(1)
+
+#define HI3110_BTR0_SJW_SHIFT 6
+#define HI3110_BTR0_BRP_SHIFT 0
+
+#define HI3110_BTR1_SAMP_3PERBIT (1 << 7)
+#define HI3110_BTR1_SAMP_1PERBIT (0 << 7)
+#define HI3110_BTR1_TSEG2_SHIFT 4
+#define HI3110_BTR1_TSEG1_SHIFT 0
+
+#define HI3110_FIFO_WOTIME_TAG_OFF 0
+#define

Re: [PATCH v2 2/2] can: spi: hi311x: Add Holt HI-311x CAN driver


Hello,

doing a quick review... I realized a few issues...

Am 17.01.2017 um 20:22 schrieb Akshay Bhat:

This patch adds support for the Holt HI-311x CAN controller. The HI311x
CAN controller is capable of transmitting and receiving standard data
frames, extended data frames and remote frames. The HI311x interfaces
with the host over SPI.

Datasheet: www.holtic.com/documents/371-hi-3110_v-rev-jpdf.do

Signed-off-by: Akshay Bhat 
---

v1 -> v2:
Address comments from Marc Kleine-Budde:
- use u8 instead of uint8_t
- alphabetically sort Makefile and Kconfig
- copy over copyright information from mcp251x
- use single space after each marco
- add missing HI3110_ namespace in defines
- remove magic number for IDE & SRR bits
- simplify logic to populate extended CAN ID
- remove unused parameters in hi3110_setup function
- remove redundant frame->can_dlc length check
- simplify error handling in hi3110_open function
Address comments from Julia Lawall:
- remove unnecessary semicolon after while loop in hi3110_can_ist

 drivers/net/can/spi/Kconfig  |6 +
 drivers/net/can/spi/Makefile |1 +
 drivers/net/can/spi/hi311x.c | 1069 ++
 3 files changed, 1076 insertions(+)
 create mode 100644 drivers/net/can/spi/hi311x.c

diff --git a/drivers/net/can/spi/Kconfig b/drivers/net/can/spi/Kconfig
index 148cae5..8f2e0dd 100644
--- a/drivers/net/can/spi/Kconfig
+++ b/drivers/net/can/spi/Kconfig
@@ -1,6 +1,12 @@
 menu "CAN SPI interfaces"
depends on SPI

+config CAN_HI311X
+   tristate "Holt HI311x SPI CAN controllers"
+   depends on CAN_DEV && SPI && HAS_DMA
+   ---help---
+ Driver for the Holt HI311x SPI CAN controllers.
+
 config CAN_MCP251X
tristate "Microchip MCP251x SPI CAN controllers"
depends on HAS_DMA
diff --git a/drivers/net/can/spi/Makefile b/drivers/net/can/spi/Makefile
index 0e86040..f59fa37 100644
--- a/drivers/net/can/spi/Makefile
+++ b/drivers/net/can/spi/Makefile
@@ -3,4 +3,5 @@
 #


+obj-$(CONFIG_CAN_HI311X)   += hi311x.o
 obj-$(CONFIG_CAN_MCP251X)  += mcp251x.o
diff --git a/drivers/net/can/spi/hi311x.c b/drivers/net/can/spi/hi311x.c
new file mode 100644
index 000..cccfe2d
--- /dev/null
+++ b/drivers/net/can/spi/hi311x.c
@@ -0,0 +1,1069 @@
+/* CAN bus driver for Holt HI3110 CAN Controller with SPI Interface
+ *
+ * Copyright(C) Timesys Corporation 2016
+ *
+ * Based on Microchip 251x CAN Controller (mcp251x) Linux kernel driver
+ * Copyright 2009 Christian Pellegrin EVOL S.r.l.
+ * Copyright 2007 Raymarine UK, Ltd. All Rights Reserved.
+ * Copyright 2006 Arcom Control Systems Ltd.
+ *
+ * Based on CAN bus driver for the CCAN controller written by
+ * - Sascha Hauer, Marc Kleine-Budde, Pengutronix
+ * - Simon Kallweit, intefo AG
+ * Copyright 2007
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define HI3110_MASTER_RESET 0x56
+#define HI3110_READ_CTRL0 0xD2
+#define HI3110_READ_CTRL1 0xD4
+#define HI3110_READ_STATF 0xE2
+#define HI3110_WRITE_CTRL0 0x14
+#define HI3110_WRITE_CTRL1 0x16
+#define HI3110_WRITE_INTE 0x1C
+#define HI3110_WRITE_BTR0 0x18
+#define HI3110_WRITE_BTR1 0x1A
+#define HI3110_READ_BTR0 0xD6
+#define HI3110_READ_BTR1 0xD8
+#define HI3110_READ_INTF 0xDE
+#define HI3110_READ_ERR 0xDC
+#define HI3110_READ_FIFO_WOTIME 0x48
+#define HI3110_WRITE_FIFO 0x12
+#define HI3110_READ_MESSTAT 0xDA
+#define HI3110_READ_TEC 0xEC
+
+#define HI3110_CTRL0_MODE_MASK (7 << 5)
+#define HI3110_CTRL0_NORMAL_MODE (0 << 5)
+#define HI3110_CTRL0_LOOPBACK_MODE (1 << 5)
+#define HI3110_CTRL0_MONITOR_MODE (2 << 5)
+#define HI3110_CTRL0_SLEEP_MODE (3 << 5)
+#define HI3110_CTRL0_INIT_MODE (4 << 5)
+
+#define HI3110_CTRL1_TXEN BIT(7)
+
+#define HI3110_INT_RXTMP BIT(7)
+#define HI3110_INT_RXFIFO BIT(6)
+#define HI3110_INT_TXCPLT BIT(5)
+#define HI3110_INT_BUSERR BIT(4)
+#define HI3110_INT_MCHG BIT(3)
+#define HI3110_INT_WAKEUP BIT(2)
+#define HI3110_INT_F1MESS BIT(1)
+#define HI3110_INT_F0MESS BIT(0)
+
+#define HI3110_ERR_BUSOFF BIT(7)
+#define HI3110_ERR_TXERRP BIT(6)
+#define HI3110_ERR_RXERRP BIT(5)
+#define HI3110_ERR_BITERR BIT(4)
+#define HI3110_ERR_FRMERR BIT(3)
+#define HI3110_ERR_CRCERR BIT(2)
+#define HI3110_ERR_ACKERR BIT(1)
+#define HI3110_ERR_STUFERR BIT(0)
+#define HI3110_ERR_PROTOCOL_MASK (0x1F)
+
+#define HI3110_STAT_RXFMTY BIT(1)
+
+#define HI3110_BTR0_SJW_SHIFT 6
+#define HI3110_BTR0_BRP_SHIFT 0
+
+#define HI3110_BTR1_SAMP_3PERBIT (1 << 7)
+#define HI3110_BTR1_SAMP_1PERBIT (0 << 7)
+#define HI3110_BTR1_TSEG2_SHIFT 4
+#define HI3110_BTR1_TSEG1_SHIFT 0
+
+#define HI3110_FIFO_WOTIME_TAG_OFF 0
+#define HI3110_FIFO_WOTIME_ID_OFF 1

Re: [PATCH v2 2/2] can: spi: hi311x: Add Holt HI-311x CAN driver


Hello Akshay,

Am 09.03.2017 um 13:34 schrieb Akshay Bhat:



On 03/09/2017 04:59 AM, Wolfgang Grandegger wrote:

Hello Akshay,

unfortunately there are not many CAN controllers for the SPI bus. I just
know the MPC251x, which behaves badly (message losses) under Linux,
especially at hight bit-rates due to insufficient RX buffering. What is
your experience with that driver for the HI-311x?



Hi Wolfgang,

Good question. I have not worked with MPC251x but the HI-311x performs
much better because HI-3110 features:
8 message FIFO (as opposed to 2 buffers on MPC2510)
20 MHz SPI interface (as opposed to 2.5 MHz on MPC2510)

As for the real world test results:

With RT patch applied to the kernel running on a i.MX6 Dual processor
(worst case interrupt latency of 50us as reported by cyclictest), there
are ZERO packet drops.
Tested with Kvaser Leaf sending 100 burst messages (back to back) every
40ms at a 1M CAN bit rate. 10 million messages were sent by the Kvaser
leaf and received successfully by the HI-311x driver.


This corresponds to a bus load of approx. 50%, I think?


Even without the RT patch, I was able to get the packet drop to zero but
this was by moving the CAN/SPI IRQ threads to CPU1 instead of CPU0.


Vanilla Linux is more critical here due to higher latencies. With 2500 
Messages per sec the RX FIFO (8 Messages) fills up within 3.2 ms... and 
in a burst even quicker. That's already heavy load.


Wolfgang.

Re: [PATCH v2 2/2] can: spi: hi311x: Add Holt HI-311x CAN driver


Hello Akshay,

Am 09.03.2017 um 13:34 schrieb Akshay Bhat:



On 03/09/2017 04:59 AM, Wolfgang Grandegger wrote:

Hello Akshay,

unfortunately there are not many CAN controllers for the SPI bus. I just
know the MPC251x, which behaves badly (message losses) under Linux,
especially at hight bit-rates due to insufficient RX buffering. What is
your experience with that driver for the HI-311x?



Hi Wolfgang,

Good question. I have not worked with MPC251x but the HI-311x performs
much better because HI-3110 features:
8 message FIFO (as opposed to 2 buffers on MPC2510)
20 MHz SPI interface (as opposed to 2.5 MHz on MPC2510)

As for the real world test results:

With RT patch applied to the kernel running on a i.MX6 Dual processor
(worst case interrupt latency of 50us as reported by cyclictest), there
are ZERO packet drops.
Tested with Kvaser Leaf sending 100 burst messages (back to back) every
40ms at a 1M CAN bit rate. 10 million messages were sent by the Kvaser
leaf and received successfully by the HI-311x driver.


This corresponds to a bus load of approx. 50%, I think?


Even without the RT patch, I was able to get the packet drop to zero but
this was by moving the CAN/SPI IRQ threads to CPU1 instead of CPU0.


Vanilla Linux is more critical here due to higher latencies. With 2500 
Messages per sec the RX FIFO (8 Messages) fills up within 3.2 ms... and 
in a burst even quicker. That's already heavy load.


Wolfgang.

Re: [PATCH v2 2/2] can: spi: hi311x: Add Holt HI-311x CAN driver


Hello Akshay,

unfortunately there are not many CAN controllers for the SPI bus. I just 
know the MPC251x, which behaves badly (message losses) under Linux, 
especially at hight bit-rates due to insufficient RX buffering. What is 
your experience with that driver for the HI-311x?


Thanks,

Wolfgang.

Am 07.03.2017 um 16:31 schrieb Akshay Bhat:



On 01/17/2017 02:22 PM, Akshay Bhat wrote:

This patch adds support for the Holt HI-311x CAN controller. The HI311x
CAN controller is capable of transmitting and receiving standard data
frames, extended data frames and remote frames. The HI311x interfaces
with the host over SPI.

Datasheet: www.holtic.com/documents/371-hi-3110_v-rev-jpdf.do

Signed-off-by: Akshay Bhat 
---




Hi Marc,

Wanted to check if this patch can be included in the next kernel release
(4.12).

Thanks,
Akshay
--
To unsubscribe from this list: send the line "unsubscribe linux-can" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 2/2] can: spi: hi311x: Add Holt HI-311x CAN driver


Hello Akshay,

unfortunately there are not many CAN controllers for the SPI bus. I just 
know the MPC251x, which behaves badly (message losses) under Linux, 
especially at hight bit-rates due to insufficient RX buffering. What is 
your experience with that driver for the HI-311x?


Thanks,

Wolfgang.

Am 07.03.2017 um 16:31 schrieb Akshay Bhat:



On 01/17/2017 02:22 PM, Akshay Bhat wrote:

This patch adds support for the Holt HI-311x CAN controller. The HI311x
CAN controller is capable of transmitting and receiving standard data
frames, extended data frames and remote frames. The HI311x interfaces
with the host over SPI.

Datasheet: www.holtic.com/documents/371-hi-3110_v-rev-jpdf.do

Signed-off-by: Akshay Bhat 
---




Hi Marc,

Wanted to check if this patch can be included in the next kernel release
(4.12).

Thanks,
Akshay
--
To unsubscribe from this list: send the line "unsubscribe linux-can" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RESEND] net: can: Introduce MEN 16Z192-00 CAN controller driver

2016-08-09 Thread Wolfgang Grandegger


Am 09.08.2016 um 08:10 schrieb Andreas Werner:

On Mon, Aug 08, 2016 at 04:35:34PM +0200, Wolfgang Grandegger wrote:

Am 08.08.2016 um 16:05 schrieb Andreas Werner:

On Mon, Aug 08, 2016 at 02:28:39PM +0200, Wolfgang Grandegger wrote:


---snip---


+
+   ndev = alloc_candev(sizeof(struct men_z192), 1);


You specify here one echo_skb but it's not used anywhere. Local loopback
seems not to be implemented.



Agree with you, will set it to "0".


No, the local loopback is mandetory!



Hm ok, but if i check alloc_candev() in drivers/net/can/dev.c
it is not mandatory. In the Documentation/networking/can.txt
there is also a "should" and a fallback mechnism if the driver
does not support the local loopback.


Well, s/driver/hardware/ ! Local loopback is the preferred mechanism.



Sure...


I'm currently ok with this fallback mechanism.

Anyway I am not sure that the driver can handle the echo skb correctly.
If i understand it correctly, the can_get_echo_skb() is normally called
on a "TX done IRQ" to get the skb and loop it back.
I do not have such a "TX done IRQ" and have not implemented implemented
and added the local looback.


What does "MEN_Z192_TFLG_TXIF" signal?



It is not a "TX Done" IRQ, it is the tx buffer level IRQ.
The IRQ is triggered when the number of available tx buffer entries is as
configured with txlvl. (after the buffer was full)

Example:
txlvl = 0
tx buffer has 255 entries.

-> The IRQ is triggered as soon as 1 frame got transmitted (254 entries).

---

txlvl = 254
tx buffer has 255 entries.

-> The IRQ is triggered as soon as the buffer has one entry and it got 
transmitted



May be I can put and get the echo skb within the xmit function?
Does this make sense?


It only makes sense if the driver knows when one or more transfers are done.



Then i do not think that I can use the txlvl IRQ in this case and need to use
the fallback mechanism.



You could store "MEN_Z192_TX_BUF_CNT(readl(>rx_tx_sts))" in the 
start_xmit function and check again in the isr function to find out how 
much transfers have been transmitted in the meantime. Does it make sense?


Wolfgang.

Re: [PATCH RESEND] net: can: Introduce MEN 16Z192-00 CAN controller driver

2016-08-09 Thread Wolfgang Grandegger


Am 09.08.2016 um 08:10 schrieb Andreas Werner:

On Mon, Aug 08, 2016 at 04:35:34PM +0200, Wolfgang Grandegger wrote:

Am 08.08.2016 um 16:05 schrieb Andreas Werner:

On Mon, Aug 08, 2016 at 02:28:39PM +0200, Wolfgang Grandegger wrote:


---snip---


+
+   ndev = alloc_candev(sizeof(struct men_z192), 1);


You specify here one echo_skb but it's not used anywhere. Local loopback
seems not to be implemented.



Agree with you, will set it to "0".


No, the local loopback is mandetory!



Hm ok, but if i check alloc_candev() in drivers/net/can/dev.c
it is not mandatory. In the Documentation/networking/can.txt
there is also a "should" and a fallback mechnism if the driver
does not support the local loopback.


Well, s/driver/hardware/ ! Local loopback is the preferred mechanism.



Sure...


I'm currently ok with this fallback mechanism.

Anyway I am not sure that the driver can handle the echo skb correctly.
If i understand it correctly, the can_get_echo_skb() is normally called
on a "TX done IRQ" to get the skb and loop it back.
I do not have such a "TX done IRQ" and have not implemented implemented
and added the local looback.


What does "MEN_Z192_TFLG_TXIF" signal?



It is not a "TX Done" IRQ, it is the tx buffer level IRQ.
The IRQ is triggered when the number of available tx buffer entries is as
configured with txlvl. (after the buffer was full)

Example:
txlvl = 0
tx buffer has 255 entries.

-> The IRQ is triggered as soon as 1 frame got transmitted (254 entries).

---

txlvl = 254
tx buffer has 255 entries.

-> The IRQ is triggered as soon as the buffer has one entry and it got 
transmitted



May be I can put and get the echo skb within the xmit function?
Does this make sense?


It only makes sense if the driver knows when one or more transfers are done.



Then i do not think that I can use the txlvl IRQ in this case and need to use
the fallback mechanism.



You could store "MEN_Z192_TX_BUF_CNT(readl(>rx_tx_sts))" in the 
start_xmit function and check again in the isr function to find out how 
much transfers have been transmitted in the meantime. Does it make sense?


Wolfgang.

Re: [PATCH RESEND] net: can: Introduce MEN 16Z192-00 CAN controller driver


Am 08.08.2016 um 16:05 schrieb Andreas Werner:

On Mon, Aug 08, 2016 at 02:28:39PM +0200, Wolfgang Grandegger wrote:

Hello,

Am 08.08.2016 um 13:39 schrieb Andreas Werner:

On Mon, Aug 08, 2016 at 11:27:25AM +0200, Wolfgang Grandegger wrote:

Hello Andreas,

a first quick review

Am 26.07.2016 um 11:16 schrieb Andreas Werner:

This CAN Controller is found on MEN Chameleon FPGAs.

The driver/device supports the CAN2.0 specification.
There are 255 RX and 255 Tx buffer within the IP. The
pointer for the buffer are handled by HW to make the
access from within the driver as simple as possible.

The driver also supports parameters to configure the
buffer level interrupt for RX/TX as well as a RX timeout
interrupt.

With this configuration options, the driver/device
provides flexibility for different types of usecases.

Signed-off-by: Andreas Werner <andreas.wer...@men.de>
---
drivers/net/can/Kconfig|  10 +
drivers/net/can/Makefile   |   1 +
drivers/net/can/men_z192_can.c | 989 +
3 files changed, 1000 insertions(+)
create mode 100644 drivers/net/can/men_z192_can.c


---snip---


+/* Buffer level control values */
+#define MEN_Z192_MIN_BUF_LVL   0
+#define MEN_Z192_MAX_BUF_LVL   254
+#define MEN_Z192_RX_BUF_LVL_DEF5
+#define MEN_Z192_TX_BUF_LVL_DEF5
+#define MEN_Z192_RX_TOUT_MIN   0
+#define MEN_Z192_RX_TOUT_MAX   65535
+#define MEN_Z192_RX_TOUT_DEF   1000
+
+static int txlvl = MEN_Z192_TX_BUF_LVL_DEF;
+module_param(txlvl, int, S_IRUGO);
+MODULE_PARM_DESC(txlvl, "TX IRQ trigger level (in frames) 0-254, default="
+__MODULE_STRING(MEN_Z192_TX_BUF_LVL_DEF) ")");
+
+static int rxlvl = MEN_Z192_RX_BUF_LVL_DEF;
+module_param(rxlvl, int, S_IRUGO);
+MODULE_PARM_DESC(rxlvl, "RX IRQ trigger level (in frames) 0-254, default="
+__MODULE_STRING(MEN_Z192_RX_BUF_LVL_DEF) ")");
+


What impact does the level have on the latency? Could you please add some
comments.


It has a impact on the latency.
rxlvl = 0 -> if one frame got received, a IRQ will be generated
rxlvl = 254 -> if 255 frames got received, a IRQ will be generated


Well, what's your usecase for rxlvl > 0? For me it's not obvious what it can
be good for. The application usually wants the message as soon as possible.
Anyway, the default should be *0*. For RX and TX.



The HW provides such feature and the driver should be able to control it.
It was developed to control the IRQ load (like NAPI) by defining a level of the 
buffer
when the IRQ got asserted.

I aggree with you to set the default to "0" which is the main usecase.


+static int rx_timeout = MEN_Z192_RX_TOUT_DEF;
+module_param(rx_timeout, int, S_IRUGO);
+MODULE_PARM_DESC(rx_timeout, "RX IRQ timeout (in 100usec steps), default="
+__MODULE_STRING(MEN_Z192_RX_TOUT_DEF) ")");


Ditto. What is "rx_timeout" good for.



The rx timeout is used im combination with the rxlvl to assert the
if the buffer level is not reached within this timeout.


What event will the application receive in case of a timeout.



Its just to control the time when the RX IRQ will be asserted if the buffer
level is not reached.
Imagine if the rx_timeout is not existing and the rxlvl is set to 50 and
only 30 packets are received. The RX IRQ will be never asserted.

By defining the rx_timeout, we can control the time when the RX IRQ is asserted
if the buffer level is not reached.

The application does not receive any special signal, its just the RX IRQ.


Now I got it. After timeout an interrupt will be trigger regardless of 
the thresholds. The default settings should result in minimum latencies.



Both, the timeout and the level are used to give the user as much
control over the latency and the IRQ handling as possible.
With this two options, the driver can be configured for different
use cases.

I will add this as the comment to make it more clear.


Even a bit more would be appreciated.



Sure...



---snip---


+static int men_z192_read_frame(struct net_device *ndev, unsigned int frame_nr)
+{
+   struct net_device_stats *stats = >stats;
+   struct men_z192 *priv = netdev_priv(ndev);
+   struct men_z192_cf_buf __iomem *cf_buf;
+   struct can_frame *cf;
+   struct sk_buff *skb;
+   u32 cf_offset;
+   u32 length;
+   u32 data;
+   u32 id;
+
+   skb = alloc_can_skb(ndev, );
+   if (unlikely(!skb)) {
+   stats->rx_dropped++;
+   return 0;
+   }
+
+   cf_offset = sizeof(struct men_z192_cf_buf) * frame_nr;
+
+   cf_buf = priv->dev_base + MEN_Z192_RX_BUF_START + cf_offset;
+   length = readl(_buf->length) & MEN_Z192_CFBUF_LEN;
+   id = readl(_buf->can_id);
+
+   if (id & MEN_Z192_CFBUF_IDE) {
+   /* Extended frame */
+   cf->can_id = (id & MEN_Z192_CFBUF_ID1) >> 3;
+

Re: [PATCH RESEND] net: can: Introduce MEN 16Z192-00 CAN controller driver


Am 08.08.2016 um 16:05 schrieb Andreas Werner:

On Mon, Aug 08, 2016 at 02:28:39PM +0200, Wolfgang Grandegger wrote:

Hello,

Am 08.08.2016 um 13:39 schrieb Andreas Werner:

On Mon, Aug 08, 2016 at 11:27:25AM +0200, Wolfgang Grandegger wrote:

Hello Andreas,

a first quick review

Am 26.07.2016 um 11:16 schrieb Andreas Werner:

This CAN Controller is found on MEN Chameleon FPGAs.

The driver/device supports the CAN2.0 specification.
There are 255 RX and 255 Tx buffer within the IP. The
pointer for the buffer are handled by HW to make the
access from within the driver as simple as possible.

The driver also supports parameters to configure the
buffer level interrupt for RX/TX as well as a RX timeout
interrupt.

With this configuration options, the driver/device
provides flexibility for different types of usecases.

Signed-off-by: Andreas Werner 
---
drivers/net/can/Kconfig|  10 +
drivers/net/can/Makefile   |   1 +
drivers/net/can/men_z192_can.c | 989 +
3 files changed, 1000 insertions(+)
create mode 100644 drivers/net/can/men_z192_can.c


---snip---


+/* Buffer level control values */
+#define MEN_Z192_MIN_BUF_LVL   0
+#define MEN_Z192_MAX_BUF_LVL   254
+#define MEN_Z192_RX_BUF_LVL_DEF5
+#define MEN_Z192_TX_BUF_LVL_DEF5
+#define MEN_Z192_RX_TOUT_MIN   0
+#define MEN_Z192_RX_TOUT_MAX   65535
+#define MEN_Z192_RX_TOUT_DEF   1000
+
+static int txlvl = MEN_Z192_TX_BUF_LVL_DEF;
+module_param(txlvl, int, S_IRUGO);
+MODULE_PARM_DESC(txlvl, "TX IRQ trigger level (in frames) 0-254, default="
+__MODULE_STRING(MEN_Z192_TX_BUF_LVL_DEF) ")");
+
+static int rxlvl = MEN_Z192_RX_BUF_LVL_DEF;
+module_param(rxlvl, int, S_IRUGO);
+MODULE_PARM_DESC(rxlvl, "RX IRQ trigger level (in frames) 0-254, default="
+__MODULE_STRING(MEN_Z192_RX_BUF_LVL_DEF) ")");
+


What impact does the level have on the latency? Could you please add some
comments.


It has a impact on the latency.
rxlvl = 0 -> if one frame got received, a IRQ will be generated
rxlvl = 254 -> if 255 frames got received, a IRQ will be generated


Well, what's your usecase for rxlvl > 0? For me it's not obvious what it can
be good for. The application usually wants the message as soon as possible.
Anyway, the default should be *0*. For RX and TX.



The HW provides such feature and the driver should be able to control it.
It was developed to control the IRQ load (like NAPI) by defining a level of the 
buffer
when the IRQ got asserted.

I aggree with you to set the default to "0" which is the main usecase.


+static int rx_timeout = MEN_Z192_RX_TOUT_DEF;
+module_param(rx_timeout, int, S_IRUGO);
+MODULE_PARM_DESC(rx_timeout, "RX IRQ timeout (in 100usec steps), default="
+__MODULE_STRING(MEN_Z192_RX_TOUT_DEF) ")");


Ditto. What is "rx_timeout" good for.



The rx timeout is used im combination with the rxlvl to assert the
if the buffer level is not reached within this timeout.


What event will the application receive in case of a timeout.



Its just to control the time when the RX IRQ will be asserted if the buffer
level is not reached.
Imagine if the rx_timeout is not existing and the rxlvl is set to 50 and
only 30 packets are received. The RX IRQ will be never asserted.

By defining the rx_timeout, we can control the time when the RX IRQ is asserted
if the buffer level is not reached.

The application does not receive any special signal, its just the RX IRQ.


Now I got it. After timeout an interrupt will be trigger regardless of 
the thresholds. The default settings should result in minimum latencies.



Both, the timeout and the level are used to give the user as much
control over the latency and the IRQ handling as possible.
With this two options, the driver can be configured for different
use cases.

I will add this as the comment to make it more clear.


Even a bit more would be appreciated.



Sure...



---snip---


+static int men_z192_read_frame(struct net_device *ndev, unsigned int frame_nr)
+{
+   struct net_device_stats *stats = >stats;
+   struct men_z192 *priv = netdev_priv(ndev);
+   struct men_z192_cf_buf __iomem *cf_buf;
+   struct can_frame *cf;
+   struct sk_buff *skb;
+   u32 cf_offset;
+   u32 length;
+   u32 data;
+   u32 id;
+
+   skb = alloc_can_skb(ndev, );
+   if (unlikely(!skb)) {
+   stats->rx_dropped++;
+   return 0;
+   }
+
+   cf_offset = sizeof(struct men_z192_cf_buf) * frame_nr;
+
+   cf_buf = priv->dev_base + MEN_Z192_RX_BUF_START + cf_offset;
+   length = readl(_buf->length) & MEN_Z192_CFBUF_LEN;
+   id = readl(_buf->can_id);
+
+   if (id & MEN_Z192_CFBUF_IDE) {
+   /* Extended frame */
+   cf->can_id = (id & MEN_Z192_CFBUF_ID1) >> 3;
+   cf->can_id |= (id

Re: [PATCH RESEND] net: can: Introduce MEN 16Z192-00 CAN controller driver


Hello,

Am 08.08.2016 um 13:39 schrieb Andreas Werner:

On Mon, Aug 08, 2016 at 11:27:25AM +0200, Wolfgang Grandegger wrote:

Hello Andreas,

a first quick review

Am 26.07.2016 um 11:16 schrieb Andreas Werner:

This CAN Controller is found on MEN Chameleon FPGAs.

The driver/device supports the CAN2.0 specification.
There are 255 RX and 255 Tx buffer within the IP. The
pointer for the buffer are handled by HW to make the
access from within the driver as simple as possible.

The driver also supports parameters to configure the
buffer level interrupt for RX/TX as well as a RX timeout
interrupt.

With this configuration options, the driver/device
provides flexibility for different types of usecases.

Signed-off-by: Andreas Werner <andreas.wer...@men.de>
---
drivers/net/can/Kconfig|  10 +
drivers/net/can/Makefile   |   1 +
drivers/net/can/men_z192_can.c | 989 +
3 files changed, 1000 insertions(+)
create mode 100644 drivers/net/can/men_z192_can.c


---snip---


+/* Buffer level control values */
+#define MEN_Z192_MIN_BUF_LVL   0
+#define MEN_Z192_MAX_BUF_LVL   254
+#define MEN_Z192_RX_BUF_LVL_DEF5
+#define MEN_Z192_TX_BUF_LVL_DEF5
+#define MEN_Z192_RX_TOUT_MIN   0
+#define MEN_Z192_RX_TOUT_MAX   65535
+#define MEN_Z192_RX_TOUT_DEF   1000
+
+static int txlvl = MEN_Z192_TX_BUF_LVL_DEF;
+module_param(txlvl, int, S_IRUGO);
+MODULE_PARM_DESC(txlvl, "TX IRQ trigger level (in frames) 0-254, default="
+__MODULE_STRING(MEN_Z192_TX_BUF_LVL_DEF) ")");
+
+static int rxlvl = MEN_Z192_RX_BUF_LVL_DEF;
+module_param(rxlvl, int, S_IRUGO);
+MODULE_PARM_DESC(rxlvl, "RX IRQ trigger level (in frames) 0-254, default="
+__MODULE_STRING(MEN_Z192_RX_BUF_LVL_DEF) ")");
+


What impact does the level have on the latency? Could you please add some
comments.


It has a impact on the latency.
rxlvl = 0 -> if one frame got received, a IRQ will be generated
rxlvl = 254 -> if 255 frames got received, a IRQ will be generated


Well, what's your usecase for rxlvl > 0? For me it's not obvious what it 
can be good for. The application usually wants the message as soon as 
possible. Anyway, the default should be *0*. For RX and TX.



+static int rx_timeout = MEN_Z192_RX_TOUT_DEF;
+module_param(rx_timeout, int, S_IRUGO);
+MODULE_PARM_DESC(rx_timeout, "RX IRQ timeout (in 100usec steps), default="
+__MODULE_STRING(MEN_Z192_RX_TOUT_DEF) ")");


Ditto. What is "rx_timeout" good for.



The rx timeout is used im combination with the rxlvl to assert the
if the buffer level is not reached within this timeout.


What event will the application receive in case of a timeout.


Both, the timeout and the level are used to give the user as much
control over the latency and the IRQ handling as possible.
With this two options, the driver can be configured for different
use cases.

>

I will add this as the comment to make it more clear.


Even a bit more would be appreciated.


---snip---


+static int men_z192_read_frame(struct net_device *ndev, unsigned int frame_nr)
+{
+   struct net_device_stats *stats = >stats;
+   struct men_z192 *priv = netdev_priv(ndev);
+   struct men_z192_cf_buf __iomem *cf_buf;
+   struct can_frame *cf;
+   struct sk_buff *skb;
+   u32 cf_offset;
+   u32 length;
+   u32 data;
+   u32 id;
+
+   skb = alloc_can_skb(ndev, );
+   if (unlikely(!skb)) {
+   stats->rx_dropped++;
+   return 0;
+   }
+
+   cf_offset = sizeof(struct men_z192_cf_buf) * frame_nr;
+
+   cf_buf = priv->dev_base + MEN_Z192_RX_BUF_START + cf_offset;
+   length = readl(_buf->length) & MEN_Z192_CFBUF_LEN;
+   id = readl(_buf->can_id);
+
+   if (id & MEN_Z192_CFBUF_IDE) {
+   /* Extended frame */
+   cf->can_id = (id & MEN_Z192_CFBUF_ID1) >> 3;
+   cf->can_id |= (id & MEN_Z192_CFBUF_ID2) >>
+   MEN_Z192_CFBUF_ID2_SHIFT;
+
+   cf->can_id |= CAN_EFF_FLAG;
+
+   if (id & MEN_Z192_CFBUF_E_RTR)
+   cf->can_id |= CAN_RTR_FLAG;
+   } else {
+   /* Standard frame */
+   cf->can_id = (id & MEN_Z192_CFBUF_ID1) >>
+   MEN_Z192_CFBUF_ID1_SHIFT;
+
+   if (id & MEN_Z192_CFBUF_S_RTR)
+   cf->can_id |= CAN_RTR_FLAG;
+   }
+
+   cf->can_dlc = get_can_dlc(length);
+
+   /* remote transmission request frame
+* contains no data field even if the
+* data length is set to a value > 0
+*/
+   if (!(cf->can_id & CAN_RTR_FLAG)) {
+   if (cf->can_dlc > 0) {
+   data = readl(_buf->data[0]);
+

Re: [PATCH RESEND] net: can: Introduce MEN 16Z192-00 CAN controller driver


Hello,

Am 08.08.2016 um 13:39 schrieb Andreas Werner:

On Mon, Aug 08, 2016 at 11:27:25AM +0200, Wolfgang Grandegger wrote:

Hello Andreas,

a first quick review

Am 26.07.2016 um 11:16 schrieb Andreas Werner:

This CAN Controller is found on MEN Chameleon FPGAs.

The driver/device supports the CAN2.0 specification.
There are 255 RX and 255 Tx buffer within the IP. The
pointer for the buffer are handled by HW to make the
access from within the driver as simple as possible.

The driver also supports parameters to configure the
buffer level interrupt for RX/TX as well as a RX timeout
interrupt.

With this configuration options, the driver/device
provides flexibility for different types of usecases.

Signed-off-by: Andreas Werner 
---
drivers/net/can/Kconfig|  10 +
drivers/net/can/Makefile   |   1 +
drivers/net/can/men_z192_can.c | 989 +
3 files changed, 1000 insertions(+)
create mode 100644 drivers/net/can/men_z192_can.c


---snip---


+/* Buffer level control values */
+#define MEN_Z192_MIN_BUF_LVL   0
+#define MEN_Z192_MAX_BUF_LVL   254
+#define MEN_Z192_RX_BUF_LVL_DEF5
+#define MEN_Z192_TX_BUF_LVL_DEF5
+#define MEN_Z192_RX_TOUT_MIN   0
+#define MEN_Z192_RX_TOUT_MAX   65535
+#define MEN_Z192_RX_TOUT_DEF   1000
+
+static int txlvl = MEN_Z192_TX_BUF_LVL_DEF;
+module_param(txlvl, int, S_IRUGO);
+MODULE_PARM_DESC(txlvl, "TX IRQ trigger level (in frames) 0-254, default="
+__MODULE_STRING(MEN_Z192_TX_BUF_LVL_DEF) ")");
+
+static int rxlvl = MEN_Z192_RX_BUF_LVL_DEF;
+module_param(rxlvl, int, S_IRUGO);
+MODULE_PARM_DESC(rxlvl, "RX IRQ trigger level (in frames) 0-254, default="
+__MODULE_STRING(MEN_Z192_RX_BUF_LVL_DEF) ")");
+


What impact does the level have on the latency? Could you please add some
comments.


It has a impact on the latency.
rxlvl = 0 -> if one frame got received, a IRQ will be generated
rxlvl = 254 -> if 255 frames got received, a IRQ will be generated


Well, what's your usecase for rxlvl > 0? For me it's not obvious what it 
can be good for. The application usually wants the message as soon as 
possible. Anyway, the default should be *0*. For RX and TX.



+static int rx_timeout = MEN_Z192_RX_TOUT_DEF;
+module_param(rx_timeout, int, S_IRUGO);
+MODULE_PARM_DESC(rx_timeout, "RX IRQ timeout (in 100usec steps), default="
+__MODULE_STRING(MEN_Z192_RX_TOUT_DEF) ")");


Ditto. What is "rx_timeout" good for.



The rx timeout is used im combination with the rxlvl to assert the
if the buffer level is not reached within this timeout.


What event will the application receive in case of a timeout.


Both, the timeout and the level are used to give the user as much
control over the latency and the IRQ handling as possible.
With this two options, the driver can be configured for different
use cases.

>

I will add this as the comment to make it more clear.


Even a bit more would be appreciated.


---snip---


+static int men_z192_read_frame(struct net_device *ndev, unsigned int frame_nr)
+{
+   struct net_device_stats *stats = >stats;
+   struct men_z192 *priv = netdev_priv(ndev);
+   struct men_z192_cf_buf __iomem *cf_buf;
+   struct can_frame *cf;
+   struct sk_buff *skb;
+   u32 cf_offset;
+   u32 length;
+   u32 data;
+   u32 id;
+
+   skb = alloc_can_skb(ndev, );
+   if (unlikely(!skb)) {
+   stats->rx_dropped++;
+   return 0;
+   }
+
+   cf_offset = sizeof(struct men_z192_cf_buf) * frame_nr;
+
+   cf_buf = priv->dev_base + MEN_Z192_RX_BUF_START + cf_offset;
+   length = readl(_buf->length) & MEN_Z192_CFBUF_LEN;
+   id = readl(_buf->can_id);
+
+   if (id & MEN_Z192_CFBUF_IDE) {
+   /* Extended frame */
+   cf->can_id = (id & MEN_Z192_CFBUF_ID1) >> 3;
+   cf->can_id |= (id & MEN_Z192_CFBUF_ID2) >>
+   MEN_Z192_CFBUF_ID2_SHIFT;
+
+   cf->can_id |= CAN_EFF_FLAG;
+
+   if (id & MEN_Z192_CFBUF_E_RTR)
+   cf->can_id |= CAN_RTR_FLAG;
+   } else {
+   /* Standard frame */
+   cf->can_id = (id & MEN_Z192_CFBUF_ID1) >>
+   MEN_Z192_CFBUF_ID1_SHIFT;
+
+   if (id & MEN_Z192_CFBUF_S_RTR)
+   cf->can_id |= CAN_RTR_FLAG;
+   }
+
+   cf->can_dlc = get_can_dlc(length);
+
+   /* remote transmission request frame
+* contains no data field even if the
+* data length is set to a value > 0
+*/
+   if (!(cf->can_id & CAN_RTR_FLAG)) {
+   if (cf->can_dlc > 0) {
+   data = readl(_buf->data[0]);
+   *(__be32 *)cf->data = cpu_to_be32(data);


Do yo

Re: [PATCH RESEND] net: can: Introduce MEN 16Z192-00 CAN controller driver


Hello Andreas,

a first quick review

Am 26.07.2016 um 11:16 schrieb Andreas Werner:

This CAN Controller is found on MEN Chameleon FPGAs.

The driver/device supports the CAN2.0 specification.
There are 255 RX and 255 Tx buffer within the IP. The
pointer for the buffer are handled by HW to make the
access from within the driver as simple as possible.

The driver also supports parameters to configure the
buffer level interrupt for RX/TX as well as a RX timeout
interrupt.

With this configuration options, the driver/device
provides flexibility for different types of usecases.

Signed-off-by: Andreas Werner 
---
 drivers/net/can/Kconfig|  10 +
 drivers/net/can/Makefile   |   1 +
 drivers/net/can/men_z192_can.c | 989 +
 3 files changed, 1000 insertions(+)
 create mode 100644 drivers/net/can/men_z192_can.c

diff --git a/drivers/net/can/Kconfig b/drivers/net/can/Kconfig
index 0d40aef..0fa0387 100644
--- a/drivers/net/can/Kconfig
+++ b/drivers/net/can/Kconfig
@@ -104,6 +104,16 @@ config CAN_JANZ_ICAN3
  This driver can also be built as a module. If so, the module will be
  called janz-ican3.ko.

+config CAN_MEN_Z192
+   tristate "MEN 16Z192-00 CAN Controller"
+   depends on MCB
+   ---help---
+ Driver for MEN 16Z192-00 CAN Controller IP-Core, which
+ is connected to the MEN Chameleon Bus.
+
+ This driver can also be built as a module. If so, the module will be
+ called men_z192_can.ko.
+
 config CAN_RCAR
tristate "Renesas R-Car CAN controller"
depends on ARCH_RENESAS || ARM
diff --git a/drivers/net/can/Makefile b/drivers/net/can/Makefile
index e3db0c8..eb206b3 100644
--- a/drivers/net/can/Makefile
+++ b/drivers/net/can/Makefile
@@ -22,6 +22,7 @@ obj-$(CONFIG_CAN_FLEXCAN) += flexcan.o
 obj-$(CONFIG_CAN_GRCAN)+= grcan.o
 obj-$(CONFIG_CAN_IFI_CANFD)+= ifi_canfd/
 obj-$(CONFIG_CAN_JANZ_ICAN3)   += janz-ican3.o
+obj-$(CONFIG_CAN_MEN_Z192) += men_z192_can.o
 obj-$(CONFIG_CAN_MSCAN)+= mscan/
 obj-$(CONFIG_CAN_M_CAN)+= m_can/
 obj-$(CONFIG_CAN_RCAR) += rcar_can.o
diff --git a/drivers/net/can/men_z192_can.c b/drivers/net/can/men_z192_can.c
new file mode 100644
index 000..b39ffee
--- /dev/null
+++ b/drivers/net/can/men_z192_can.c
@@ -0,0 +1,989 @@
+/*
+ * MEN 16Z192 CAN Controller driver
+ *
+ * Copyright (C) 2016 MEN Mikroelektronik GmbH (www.men.de)
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; version 2 of the License.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DRV_NAME   "z192_can"
+
+#define MEN_Z192_NAPI_WEIGHT   64
+#define MEN_Z192_MODE_TOUT_US  40
+
+/* CTL/BTR Register Bits */
+#define MEN_Z192_CTL0_INITRQ   BIT(0)
+#define MEN_Z192_CTL0_SLPRQBIT(1)
+#define MEN_Z192_CTL1_INITAK   BIT(8)
+#define MEN_Z192_CTL1_SLPAKBIT(9)
+#define MEN_Z192_CTL1_LISTEN   BIT(12)
+#define MEN_Z192_CTL1_LOOPBBIT(13)
+#define MEN_Z192_CTL1_CANE BIT(15)
+#define MEN_Z192_BTR0_BRP(x)   (((x) & 0x3f) << 16)
+#define MEN_Z192_BTR0_SJW(x)   (((x) & 0x03) << 22)
+#define MEN_Z192_BTR1_TSEG1(x) (((x) & 0x0f) << 24)
+#define MEN_Z192_BTR1_TSEG2(x) (((x) & 0x07) << 28)
+#define MEN_Z192_BTR1_SAMP BIT(31)
+
+/* IER Interrupt Enable Register bits */
+#define MEN_Z192_RXIE  BIT(0)
+#define MEN_Z192_OVRIE BIT(1)
+#define MEN_Z192_CSCIE BIT(6)
+#define MEN_Z192_TOUTE BIT(7)
+#define MEN_Z192_TXIE  BIT(16)
+#define MEN_Z192_ERRIE BIT(17)
+
+#define MEN_Z192_IRQ_ALL   \
+   (MEN_Z192_RXIE | MEN_Z192_OVRIE |   \
+MEN_Z192_CSCIE | MEN_Z192_TOUTE |  \
+MEN_Z192_TXIE)
+
+#define MEN_Z192_IRQ_NAPI  (MEN_Z192_RXIE | MEN_Z192_TOUTE)
+
+/* RX_TX_STAT RX/TX Status status register bits */
+#define MEN_Z192_RX_BUF_CNT(x) ((x) & 0xff)
+#define MEN_Z192_TX_BUF_CNT(x) (((x) & 0xff00) >> 8)
+#defineMEN_Z192_RFLG_RXIF  BIT(16)
+#defineMEN_Z192_RFLG_OVRF  BIT(17)
+#defineMEN_Z192_RFLG_TSTATEGENMASK(19, 18)
+#defineMEN_Z192_RFLG_RSTATEGENMASK(21, 20)
+#defineMEN_Z192_RFLG_CSCIF BIT(22)
+#defineMEN_Z192_RFLG_TOUTF BIT(23)
+#define MEN_Z192_TFLG_TXIF BIT(24)
+
+#define MEN_Z192_GET_TSTATE(x) (((x) & MEN_Z192_RFLG_TSTATE) >> 18)
+#define MEN_Z192_GET_RSTATE(x) (((x) & MEN_Z192_RFLG_RSTATE) >> 20)
+
+#define MEN_Z192_IRQ_FLAGS_ALL \
+   (MEN_Z192_RFLG_RXIF | MEN_Z192_RFLG_OVRF |  \
+MEN_Z192_RFLG_TSTATE | MEN_Z192_RFLG_RSTATE |  \
+MEN_Z192_RFLG_CSCIF | MEN_Z192_RFLG_TOUTF |\
+MEN_Z192_TFLG_TXIF)
+
+/*

Re: [PATCH RESEND] net: can: Introduce MEN 16Z192-00 CAN controller driver


Hello Andreas,

a first quick review

Am 26.07.2016 um 11:16 schrieb Andreas Werner:

This CAN Controller is found on MEN Chameleon FPGAs.

The driver/device supports the CAN2.0 specification.
There are 255 RX and 255 Tx buffer within the IP. The
pointer for the buffer are handled by HW to make the
access from within the driver as simple as possible.

The driver also supports parameters to configure the
buffer level interrupt for RX/TX as well as a RX timeout
interrupt.

With this configuration options, the driver/device
provides flexibility for different types of usecases.

Signed-off-by: Andreas Werner 
---
 drivers/net/can/Kconfig|  10 +
 drivers/net/can/Makefile   |   1 +
 drivers/net/can/men_z192_can.c | 989 +
 3 files changed, 1000 insertions(+)
 create mode 100644 drivers/net/can/men_z192_can.c

diff --git a/drivers/net/can/Kconfig b/drivers/net/can/Kconfig
index 0d40aef..0fa0387 100644
--- a/drivers/net/can/Kconfig
+++ b/drivers/net/can/Kconfig
@@ -104,6 +104,16 @@ config CAN_JANZ_ICAN3
  This driver can also be built as a module. If so, the module will be
  called janz-ican3.ko.

+config CAN_MEN_Z192
+   tristate "MEN 16Z192-00 CAN Controller"
+   depends on MCB
+   ---help---
+ Driver for MEN 16Z192-00 CAN Controller IP-Core, which
+ is connected to the MEN Chameleon Bus.
+
+ This driver can also be built as a module. If so, the module will be
+ called men_z192_can.ko.
+
 config CAN_RCAR
tristate "Renesas R-Car CAN controller"
depends on ARCH_RENESAS || ARM
diff --git a/drivers/net/can/Makefile b/drivers/net/can/Makefile
index e3db0c8..eb206b3 100644
--- a/drivers/net/can/Makefile
+++ b/drivers/net/can/Makefile
@@ -22,6 +22,7 @@ obj-$(CONFIG_CAN_FLEXCAN) += flexcan.o
 obj-$(CONFIG_CAN_GRCAN)+= grcan.o
 obj-$(CONFIG_CAN_IFI_CANFD)+= ifi_canfd/
 obj-$(CONFIG_CAN_JANZ_ICAN3)   += janz-ican3.o
+obj-$(CONFIG_CAN_MEN_Z192) += men_z192_can.o
 obj-$(CONFIG_CAN_MSCAN)+= mscan/
 obj-$(CONFIG_CAN_M_CAN)+= m_can/
 obj-$(CONFIG_CAN_RCAR) += rcar_can.o
diff --git a/drivers/net/can/men_z192_can.c b/drivers/net/can/men_z192_can.c
new file mode 100644
index 000..b39ffee
--- /dev/null
+++ b/drivers/net/can/men_z192_can.c
@@ -0,0 +1,989 @@
+/*
+ * MEN 16Z192 CAN Controller driver
+ *
+ * Copyright (C) 2016 MEN Mikroelektronik GmbH (www.men.de)
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; version 2 of the License.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DRV_NAME   "z192_can"
+
+#define MEN_Z192_NAPI_WEIGHT   64
+#define MEN_Z192_MODE_TOUT_US  40
+
+/* CTL/BTR Register Bits */
+#define MEN_Z192_CTL0_INITRQ   BIT(0)
+#define MEN_Z192_CTL0_SLPRQBIT(1)
+#define MEN_Z192_CTL1_INITAK   BIT(8)
+#define MEN_Z192_CTL1_SLPAKBIT(9)
+#define MEN_Z192_CTL1_LISTEN   BIT(12)
+#define MEN_Z192_CTL1_LOOPBBIT(13)
+#define MEN_Z192_CTL1_CANE BIT(15)
+#define MEN_Z192_BTR0_BRP(x)   (((x) & 0x3f) << 16)
+#define MEN_Z192_BTR0_SJW(x)   (((x) & 0x03) << 22)
+#define MEN_Z192_BTR1_TSEG1(x) (((x) & 0x0f) << 24)
+#define MEN_Z192_BTR1_TSEG2(x) (((x) & 0x07) << 28)
+#define MEN_Z192_BTR1_SAMP BIT(31)
+
+/* IER Interrupt Enable Register bits */
+#define MEN_Z192_RXIE  BIT(0)
+#define MEN_Z192_OVRIE BIT(1)
+#define MEN_Z192_CSCIE BIT(6)
+#define MEN_Z192_TOUTE BIT(7)
+#define MEN_Z192_TXIE  BIT(16)
+#define MEN_Z192_ERRIE BIT(17)
+
+#define MEN_Z192_IRQ_ALL   \
+   (MEN_Z192_RXIE | MEN_Z192_OVRIE |   \
+MEN_Z192_CSCIE | MEN_Z192_TOUTE |  \
+MEN_Z192_TXIE)
+
+#define MEN_Z192_IRQ_NAPI  (MEN_Z192_RXIE | MEN_Z192_TOUTE)
+
+/* RX_TX_STAT RX/TX Status status register bits */
+#define MEN_Z192_RX_BUF_CNT(x) ((x) & 0xff)
+#define MEN_Z192_TX_BUF_CNT(x) (((x) & 0xff00) >> 8)
+#defineMEN_Z192_RFLG_RXIF  BIT(16)
+#defineMEN_Z192_RFLG_OVRF  BIT(17)
+#defineMEN_Z192_RFLG_TSTATEGENMASK(19, 18)
+#defineMEN_Z192_RFLG_RSTATEGENMASK(21, 20)
+#defineMEN_Z192_RFLG_CSCIF BIT(22)
+#defineMEN_Z192_RFLG_TOUTF BIT(23)
+#define MEN_Z192_TFLG_TXIF BIT(24)
+
+#define MEN_Z192_GET_TSTATE(x) (((x) & MEN_Z192_RFLG_TSTATE) >> 18)
+#define MEN_Z192_GET_RSTATE(x) (((x) & MEN_Z192_RFLG_RSTATE) >> 20)
+
+#define MEN_Z192_IRQ_FLAGS_ALL \
+   (MEN_Z192_RFLG_RXIF | MEN_Z192_RFLG_OVRF |  \
+MEN_Z192_RFLG_TSTATE | MEN_Z192_RFLG_RSTATE |  \
+MEN_Z192_RFLG_CSCIF | MEN_Z192_RFLG_TOUTF |\
+MEN_Z192_TFLG_TXIF)
+
+/* RX/TX Error counter

Re: [PATCH v5 2/5] can: kvaser_usb: Consolidate and unify state change handling

On Wed, 21 Jan 2015 10:36:47 -0500, "Ahmed S. Darwish"
 wrote:
> On Wed, Jan 21, 2015 at 03:00:15PM +, Andri Yngvason wrote:
>> Quoting Ahmed S. Darwish (2015-01-21 14:43:23)
>> > Hi!
> 
> ...
> 
>> > <-- Unplug the cable -->
>> > 
>> >  (000.009106)  can0  2080   [8]  00 00 00 00 00 00 08 00  
>> >  ERRORFRAME
>> > bus-error
>> > error-counter-tx-rx{{8}{0}}
>> >  (000.001872)  can0  2080   [8]  00 00 00 00 00 00 10 00  

For a bus-errors I would also expcect some more information in the
data[2..3] fields. But these are always zero.

>> >  ERRORFRAME
>> > bus-error
>> > error-counter-tx-rx{{16}{0}}
>> [...]
>> > error-counter-tx-rx{{80}{0}}
>> >  (000.001910)  can0  2080   [8]  00 00 00 00 00 00 58 00  
>> >  ERRORFRAME
>> > bus-error
>> > error-counter-tx-rx{{88}{0}}
>> >  (000.001753)  can0  2084   [8]  00 08 00 00 00 00 60 00  
>> >  ERRORFRAME
>> > controller-problem{tx-error-warning}
>> Good.
>> > bus-error
>> > error-counter-tx-rx{{96}{0}}
> 
> Nice.
> 
>> >  (000.001720)  can0  2080   [8]  00 00 00 00 00 00 68 00  
>> >  ERRORFRAME
>> > bus-error
>> > error-counter-tx-rx{{104}{0}}
>> >  (000.001876)  can0  2080   [8]  00 00 00 00 00 00 70 00  
>> >  ERRORFRAME
>> > bus-error
>> > error-counter-tx-rx{{112}{0}}
>> >  (000.001749)  can0  2080   [8]  00 00 00 00 00 00 78 00  
>> >  ERRORFRAME
>> > bus-error
>> > error-counter-tx-rx{{120}{0}}
>> >  (000.001771)  can0  2084   [8]  00 20 00 00 00 00 80 00  
>> >  ERRORFRAME
>> > controller-problem{tx-error-passive}
>> Also good.
>> > bus-error
>> > error-counter-tx-rx{{128}{0}}
> 
> Also nice :-)
> 
>> >  (000.001868)  can0  2080   [8]  00 00 00 00 00 00 80 00  
>> >  ERRORFRAME
>> > bus-error
>> > error-counter-tx-rx{{128}{0}}
>> >  (000.001982)  can0  2080   [8]  00 00 00 00 00 00 80 00  
>> >  ERRORFRAME
>> > bus-error
>> > error-counter-tx-rx{{128}{0}}
>> > 
>> > (( Then a continous flood, exactly similar to the above packet,
>> > appears.
>> >Unfortunately this flooding is a firmware problem. ))
>> > 
>> > <-- Replug the cable, after a good amount of time -->
>> >
>> Where are the reverse state transitions?
>> > 
> 
> Hmmm...
> 
> [ ... ]
>> 
>> Reverse state transitions are missing from the logs. See comments
above.
>> 
> 
> When the device is on the _receiving_ end, and I unplug the CAN cable
after
> introducing some noise to the level of reaching WARNING or PASSIVE, I
> receive a BUS_ERROR event with the rxerr count reset back to 0 or 1. In
> that case, the driver correctly transitions back the state to
ERROR_ACTIVE
> and candump produces something similar to:
> 
> (000.000362)  can0  208C   [8]  00 40 40 00 00 00 00 01  
> ERRORFRAME
> controller-problem{}
> protocol-violation{{back-to-error-active}{}}
> bus-error
> error-counter-tx-rx{{0}{1}}
> 
> which is, AFAIK, the correct behaviour from the driver side.
> 
> Meanwhile, when the device is on the _sending_ end and I re-plug the CAN
> cable again. Sometimes I receive events with txerr reset to 0 or 1, and
> the driver correctly reverts back to ERROR_ACTIVE in that case. But on
> another times like the quoted case above, I don't receive any events
> resetting txerr back -- only data packets on the bus.

Well, the firmware seems to report *only* bus-errors via
CMD_CAN_ERROR_EVENT
messages, also carrying the new state, but no CMD_CHIP_STATE_EVENT just
for
the state changes.

> So, What can the driver do given the above?

Little if the notification does not come.

Wolfgang.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v5 2/5] can: kvaser_usb: Consolidate and unify state change handling

On Wed, 21 Jan 2015 10:33:19 +, Andri Yngvason
 wrote:
> Quoting Ahmed S. Darwish (2015-01-20 21:45:37)
>> From: Ahmed S. Darwish 
>> 
>> Replace most of the can interface's state and error counters
>> handling with the new can-dev can_change_state() mechanism.
>> 
>> Suggested-by: Andri Yngvason 
>> Signed-off-by: Ahmed S. Darwish 
>> ---
>>  drivers/net/can/usb/kvaser_usb.c | 114
>>  +++
>>  1 file changed, 55 insertions(+), 59 deletions(-)
>> 
>> diff --git a/drivers/net/can/usb/kvaser_usb.c
>> b/drivers/net/can/usb/kvaser_usb.c
>> index 971c5f9..0386d3f 100644
>> --- a/drivers/net/can/usb/kvaser_usb.c
>> +++ b/drivers/net/can/usb/kvaser_usb.c

...
> 
> Looks good.

Would be nice to see some "candump" traces as well. Ahmed, could you
please generate such traces doing:

1. Execute in a session:
   # candump -t d -e any,0:0,#

2. Execute in another session:
   # cangen -g 10 -D i can0

3. Disconnect the CAN cable

4. After a while reconnect the CAN cable

5. Stop candump and save the trace.

and to test bus-off:

1. Execute in a session:
   # candump -t d -e any,0:0,#

2. Execute in another session:
   # cangen -g 10 -D i can0

3. Short-circuit the CAN low and high wires of the CAN cable

4. After a while remove the short-circuit.

5. Stop candump and save the trace.

Thanks,

Wolfgang.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v5 2/5] can: kvaser_usb: Consolidate and unify state change handling

On Wed, 21 Jan 2015 10:36:47 -0500, Ahmed S. Darwish
darwish...@gmail.com wrote:
 On Wed, Jan 21, 2015 at 03:00:15PM +, Andri Yngvason wrote:
 Quoting Ahmed S. Darwish (2015-01-21 14:43:23)
  Hi!
 
 ...
 
  -- Unplug the cable --
  
   (000.009106)  can0  2080   [8]  00 00 00 00 00 00 08 00  
   ERRORFRAME
  bus-error
  error-counter-tx-rx{{8}{0}}
   (000.001872)  can0  2080   [8]  00 00 00 00 00 00 10 00  

For a bus-errors I would also expcect some more information in the
data[2..3] fields. But these are always zero.

   ERRORFRAME
  bus-error
  error-counter-tx-rx{{16}{0}}
 [...]
  error-counter-tx-rx{{80}{0}}
   (000.001910)  can0  2080   [8]  00 00 00 00 00 00 58 00  
   ERRORFRAME
  bus-error
  error-counter-tx-rx{{88}{0}}
   (000.001753)  can0  2084   [8]  00 08 00 00 00 00 60 00  
   ERRORFRAME
  controller-problem{tx-error-warning}
 Good.
  bus-error
  error-counter-tx-rx{{96}{0}}
 
 Nice.
 
   (000.001720)  can0  2080   [8]  00 00 00 00 00 00 68 00  
   ERRORFRAME
  bus-error
  error-counter-tx-rx{{104}{0}}
   (000.001876)  can0  2080   [8]  00 00 00 00 00 00 70 00  
   ERRORFRAME
  bus-error
  error-counter-tx-rx{{112}{0}}
   (000.001749)  can0  2080   [8]  00 00 00 00 00 00 78 00  
   ERRORFRAME
  bus-error
  error-counter-tx-rx{{120}{0}}
   (000.001771)  can0  2084   [8]  00 20 00 00 00 00 80 00  
   ERRORFRAME
  controller-problem{tx-error-passive}
 Also good.
  bus-error
  error-counter-tx-rx{{128}{0}}
 
 Also nice :-)
 
   (000.001868)  can0  2080   [8]  00 00 00 00 00 00 80 00  
   ERRORFRAME
  bus-error
  error-counter-tx-rx{{128}{0}}
   (000.001982)  can0  2080   [8]  00 00 00 00 00 00 80 00  
   ERRORFRAME
  bus-error
  error-counter-tx-rx{{128}{0}}
  
  (( Then a continous flood, exactly similar to the above packet,
  appears.
 Unfortunately this flooding is a firmware problem. ))
  
  -- Replug the cable, after a good amount of time --
 
 Where are the reverse state transitions?
  
 
 Hmmm...
 
 [ ... ]
 
 Reverse state transitions are missing from the logs. See comments
above.
 
 
 When the device is on the _receiving_ end, and I unplug the CAN cable
after
 introducing some noise to the level of reaching WARNING or PASSIVE, I
 receive a BUS_ERROR event with the rxerr count reset back to 0 or 1. In
 that case, the driver correctly transitions back the state to
ERROR_ACTIVE
 and candump produces something similar to:
 
 (000.000362)  can0  208C   [8]  00 40 40 00 00 00 00 01  
 ERRORFRAME
 controller-problem{}
 protocol-violation{{back-to-error-active}{}}
 bus-error
 error-counter-tx-rx{{0}{1}}
 
 which is, AFAIK, the correct behaviour from the driver side.
 
 Meanwhile, when the device is on the _sending_ end and I re-plug the CAN
 cable again. Sometimes I receive events with txerr reset to 0 or 1, and
 the driver correctly reverts back to ERROR_ACTIVE in that case. But on
 another times like the quoted case above, I don't receive any events
 resetting txerr back -- only data packets on the bus.

Well, the firmware seems to report *only* bus-errors via
CMD_CAN_ERROR_EVENT
messages, also carrying the new state, but no CMD_CHIP_STATE_EVENT just
for
the state changes.

 So, What can the driver do given the above?

Little if the notification does not come.

Wolfgang.

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v5 2/5] can: kvaser_usb: Consolidate and unify state change handling

On Wed, 21 Jan 2015 10:33:19 +, Andri Yngvason
andri.yngva...@marel.com wrote:
 Quoting Ahmed S. Darwish (2015-01-20 21:45:37)
 From: Ahmed S. Darwish ahmed.darw...@valeo.com
 
 Replace most of the can interface's state and error counters
 handling with the new can-dev can_change_state() mechanism.
 
 Suggested-by: Andri Yngvason andri.yngva...@marel.com
 Signed-off-by: Ahmed S. Darwish ahmed.darw...@valeo.com
 ---
  drivers/net/can/usb/kvaser_usb.c | 114
  +++
  1 file changed, 55 insertions(+), 59 deletions(-)
 
 diff --git a/drivers/net/can/usb/kvaser_usb.c
 b/drivers/net/can/usb/kvaser_usb.c
 index 971c5f9..0386d3f 100644
 --- a/drivers/net/can/usb/kvaser_usb.c
 +++ b/drivers/net/can/usb/kvaser_usb.c

...
 
 Looks good.

Would be nice to see some candump traces as well. Ahmed, could you
please generate such traces doing:

1. Execute in a session:
   # candump -t d -e any,0:0,#

2. Execute in another session:
   # cangen -g 10 -D i can0

3. Disconnect the CAN cable

4. After a while reconnect the CAN cable

5. Stop candump and save the trace.

and to test bus-off:

1. Execute in a session:
   # candump -t d -e any,0:0,#

2. Execute in another session:
   # cangen -g 10 -D i can0

3. Short-circuit the CAN low and high wires of the CAN cable

4. After a while remove the short-circuit.

5. Stop candump and save the trace.

Thanks,

Wolfgang.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: FlexCAN on i.MX28 interrupt flooding retrying send

On 03/07/2014 02:36 PM, Stanislav Meduna wrote:
> On 07.03.2014 09:46, Marc Kleine-Budde wrote:
> 
>> Adding the linux-can mailinglist to Cc.
> 
> I am not subscribed so maybe that's why the original mail
> did not get through - I did Cc: linux-...@vger.kernel.org
> 
>> Your kernel is missing the patch:
>>
>> e358784 can: flexcan: fix mx28 detection by rearanging OF match table
>>
>> With this patch the CAN core properly detected as an mx28, so that bus
>> errors stay disabled (unless you enable them). If you need bus errors to
>> detect not connected CAN busses, you need another patchset berr_limit,
>> which is not yet mainline. I can repost it here, if you need it.
> 
> Ah ok.
> 
> Thank you, this probably points me to the right direction - I'll try
> to implement this behaviour in my kernel (unfortunately
> I cannot move to more recent one at the moment).

The following hack should fix the problem:

diff --git a/drivers/net/can/flexcan.c b/drivers/net/can/flexcan.c
index eb4014a..a6be018 100644
--- a/drivers/net/can/flexcan.c
+++ b/drivers/net/can/flexcan.c
@@ -727,7 +727,16 @@ static int flexcan_chip_start(struct net_device *dev)
reg_ctrl = flexcan_read(>ctrl);
reg_ctrl &= ~FLEXCAN_CTRL_TSYN;
reg_ctrl |= FLEXCAN_CTRL_BOFF_REC | FLEXCAN_CTRL_LBUF |
-   FLEXCAN_CTRL_ERR_STATE | FLEXCAN_CTRL_ERR_MSK;
+   FLEXCAN_CTRL_ERR_STATE;
+
+   /*
+* Quick and dirty hack to enable the "error interrupt"
+* (FLEXCAN_CTRL_ERR_MSK) for the i.MX8. Warning: this
+* does not work on most other Flexcan cores. There, we
+* then don't get any error warning or passive interrupts.
+*/
+   if (priv->can.ctrlmode & CAN_CTRLMODE_BERR_REPORTING)
+   reg_ctrl |= FLEXCAN_CTRL_ERR_MSK;
 
/* save for later use */
priv->reg_ctrl_default = reg_ctrl;

Anyway, you should check if there are other important improvement and
fixes a pending.

Wolfgang.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: FlexCAN on i.MX28 interrupt flooding retrying send

On 03/07/2014 09:16 AM, Marc Kleine-Budde wrote:
> Adding the linux-can mailinglist to Cc.
> 
> Marc
> 
> On 03/07/2014 09:08 AM, Stanislav Meduna wrote:
>> Hi,
>>
>> I am using a FlexCAN CAN controller on a Freescale i.MX28 platform [1].
>> If a packet is being sent when the bus is disconnected, I am getting
>> an interrupt flooed that basically kills the machine.
>>
>> This is _not_ the same problem as [2] - my kernel already has
>> the fix.
>>
>> The first interrupt comes with ESR 0x00028652, i.e.
>>
>> TXWRN_INT
>> BIT1_ERR
>> STF_ERR
>> TX_WRN
>> TXRX
>> FLT_CONF error passive
>> ERR_INT
>>
>> The next ones come the same without the acked TXWRN_INT.
>> Reading the ESR again immediately after acking gives
>> 0x0250, i.e.
>>
>> TX_WRN
>> TXRX
>> FLT_CONF error passive
>>
>> so everything ackable has actually been acked.
>>
>> I think that the problem is that the FlexCAN tries to retransmit
>> the frame indefinitely. Each retry senses the bus in the invalid
>> state (BIT1_ERR) and immediately fires a new ERR_INT. To verify
>> this I aborted the transmitted frame in the error state in the
>> interrupt handler
>>
>> #define FLEXCAN_ESR_ERR_TRANSMIT \
>>  (FLEXCAN_ESR_BIT1_ERR | FLEXCAN_ESR_BIT0_ERR | FLEXCAN_ESR_ACK_ERR)
>>
>> if (reg_esr & FLEXCAN_ESR_ERR_TRANSMIT) {
>>
>>  /* In case of a transmission error the packet is retried and
>>   * if the error persists, we will get another interrupt right
>>   * away. Abort the transmission - a lost packet is better than
>>   * an irq storm.
>>   */
>>  if(printk_ratelimit())
>>  netdev_err(dev, "Aborted transmission, ESR %08x\n", reg_esr);
>>
>>  can_get_echo_skb(dev, 0);
>>  flexcan_write(FLEXCAN_MB_CNT_CODE(0x4),
>>  >cantxfg[FLEXCAN_TX_BUF_ID].can_ctrl);
>>  netif_wake_queue(dev);
>> }
>>
>> and the problem disappeared as expected. However, the correct
>> way is probably to retry during some reasonable (configurable?)
>> time interval.
>>
>> What puzzles me is that I did not found any other instance
>> of this problem in the relevant mailing lists, only the original [2].
>>
>> I am using the 3.4.77 kernel with the realtime patches, but the
>> code in the latest mainline looks the same in this respect.
>> Maybe the realtime patches change some bevaviour, but I don't
>> think they affect the core problem. I am not really an expert
>> in the network devices, NAPI etc - maybe in that case the error
>> interrupt should be disabled and re-enabled only if the
>> error condition goes away? - I don't know...
>>
>> Please Cc: me when answering to the list.
>>
>> [1] 
>> http://www.tq-group.com/en/products/product-details/prod/embedded-modul-tqma28/extb/Main/productdetail/
>> [2] https://gitorious.org/linux-can/wg-linux-can-next/commit/8ad94fa

If bus-error reporting is enabled, you will get an interrupt for each
TX retry. That's normal behavior. But for the i.MX28 it should not be
enabled:

  $ cat flexcan.c
  ...
/*
 * enable the "error interrupt" (FLEXCAN_CTRL_ERR_MSK),
 * on most Flexcan cores, too. Otherwise we don't get
 * any error warning or passive interrupts.
 */
if (priv->devtype_data->features & FLEXCAN_HAS_BROKEN_ERR_STATE ||
priv->can.ctrlmode & CAN_CTRLMODE_BERR_REPORTING)
reg_ctrl |= FLEXCAN_CTRL_ERR_MSK;

Maybe there is something wrong with you platform code or DTS file. What
kernel are you using and how is the DTS can node defined in your DTS file?

Wolfgang.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: FlexCAN on i.MX28 interrupt flooding retrying send

On 03/07/2014 09:16 AM, Marc Kleine-Budde wrote:
Adding the linux-can mailinglist to Cc.

Marc

On 03/07/2014 09:08 AM, Stanislav Meduna wrote:
Hi,

I am using a FlexCAN CAN controller on a Freescale i.MX28 platform [1].
If a packet is being sent when the bus is disconnected, I am getting
an interrupt flooed that basically kills the machine.

This is _not_ the same problem as [2] - my kernel already has
the fix.

The first interrupt comes with ESR 0x00028652, i.e.

TXWRN_INT
BIT1_ERR
STF_ERR
TX_WRN
TXRX
FLT_CONF error passive
ERR_INT

The next ones come the same without the acked TXWRN_INT.
Reading the ESR again immediately after acking gives
0x0250, i.e.

TX_WRN
TXRX
FLT_CONF error passive

so everything ackable has actually been acked.

I think that the problem is that the FlexCAN tries to retransmit
the frame indefinitely. Each retry senses the bus in the invalid
state (BIT1_ERR) and immediately fires a new ERR_INT. To verify
this I aborted the transmitted frame in the error state in the
interrupt handler

#define FLEXCAN_ESR_ERR_TRANSMIT \
(FLEXCAN_ESR_BIT1_ERR | FLEXCAN_ESR_BIT0_ERR | FLEXCAN_ESR_ACK_ERR)

if (reg_esr FLEXCAN_ESR_ERR_TRANSMIT) {

/* In case of a transmission error the packet is retried and
* if the error persists, we will get another interrupt right
* away. Abort the transmission - a lost packet is better than
* an irq storm.
*/
if(printk_ratelimit())
netdev_err(dev, Aborted transmission, ESR %08x\n, reg_esr);

can_get_echo_skb(dev, 0);
flexcan_write(FLEXCAN_MB_CNT_CODE(0x4),
regs-cantxfg[FLEXCAN_TX_BUF_ID].can_ctrl);
netif_wake_queue(dev);
}

and the problem disappeared as expected. However, the correct
way is probably to retry during some reasonable (configurable?)
time interval.

What puzzles me is that I did not found any other instance
of this problem in the relevant mailing lists, only the original [2].

I am using the 3.4.77 kernel with the realtime patches, but the
code in the latest mainline looks the same in this respect.
Maybe the realtime patches change some bevaviour, but I don't
think they affect the core problem. I am not really an expert
in the network devices, NAPI etc - maybe in that case the error
interrupt should be disabled and re-enabled only if the
error condition goes away? - I don't know...

Please Cc: me when answering to the list.

[1]
http://www.tq-group.com/en/products/product-details/prod/embedded-modul-tqma28/extb/Main/productdetail/
[2] https://gitorious.org/linux-can/wg-linux-can-next/commit/8ad94fa

If bus-error reporting is enabled, you will get an interrupt for each
TX retry. That's normal behavior. But for the i.MX28 it should not be
enabled:

$ cat flexcan.c
...
/*
* enable the error interrupt (FLEXCAN_CTRL_ERR_MSK),
* on most Flexcan cores, too. Otherwise we don't get
* any error warning or passive interrupts.
*/
if (priv-devtype_data-features FLEXCAN_HAS_BROKEN_ERR_STATE ||
priv-can.ctrlmode CAN_CTRLMODE_BERR_REPORTING)
reg_ctrl |= FLEXCAN_CTRL_ERR_MSK;

Maybe there is something wrong with you platform code or DTS file. What
kernel are you using and how is the DTS can node defined in your DTS file?

Wolfgang.

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Re: FlexCAN on i.MX28 interrupt flooding retrying send