devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Marc Kleine-Budde <mkl@pengutronix.de>
To: Dong Aisheng <b29396@freescale.com>
Cc: linux-can@vger.kernel.org, wg@grandegger.com,
	socketcan@hartkopp.net, linux-arm-kernel@lists.infradead.org,
	devicetree@vger.kernel.org, mark.rutland@arm.com,
	varkabhadram@gmail.com
Subject: Re: [PATCH v4 2/2] can: m_can: add Bosch M_CAN controller support
Date: Tue, 15 Jul 2014 10:46:32 +0200	[thread overview]
Message-ID: <53C4EA68.5090606@pengutronix.de> (raw)
In-Reply-To: <20140715082637.GA2601@shlinux1.ap.freescale.net>

[-- Attachment #1: Type: text/plain, Size: 4143 bytes --]

On 07/15/2014 10:26 AM, Dong Aisheng wrote:
>>>>> +static void m_can_read_fifo(const struct net_device *dev, struct can_frame *cf,
>>>>> +			    u32 rxfs)
>>>>> +{
>>>>> +	struct m_can_priv *priv = netdev_priv(dev);
>>>>> +	u32 flags, fgi;
>>>>> +
>>>>> +	/* calculate the fifo get index for where to read data */
>>>>> +	fgi = (rxfs & RXFS_FGI_MASK) >> RXFS_FGI_OFF;
>>>>> +	flags = m_can_fifo_read(priv, fgi, 0x0);
>>>>                                            ^^^
>>>>
>>>> Can you introduce an enum for the offsets, please adjust the signature
>>>> of m_can_fifo_read() accordingly.
>>>>
>>>
>>> I wonder enum may not be suitable.
>>> The Rx Buffer and FIFO Element is as follows:
>>>    31 24 23 16 15 8 7 0
>>> R0 ESI XTD RTR ID[28:0]
>>
>> M_CAN_FIFO_ID
>>
>>> R1 ANMF FIDX[6:0] res EDL BRS DLC[3:0] RXTS[15:0]
>>
>> M_CAN_FIFO_DLC
>>
>>> R2 DB3[7:0] DB2[7:0] DB1[7:0] DB0[7:0]
>>> R3 DB7[7:0] DB6[7:0] DB5[7:0] DB4[7:0]
>>
>> M_CAN_FIFO_DATA0
>> M_CAN_FIFO_DATA1
>>
> 
> You mean as follows?
> enum m_can_fifo {
>         M_CAN_FIFO_ID = 0,
>         M_CAN_FIFO_DLC,
= 0x4,
>         M_CAN_FIFO_DATA0,
= 0x8,
>         M_CAN_FIFO_DATA1,
= 0xc,
> };
> 
> static inline u32 m_can_fifo_read(const struct m_can_priv *priv,
>                                   u32 fgi, enum m_can_fifo fifo)
> {
>         return readl(priv->mram_base + priv->mcfg[MRAM_RXF0].off +
>                      fgi * RXF0_ELEMENT_SIZE + fifo * 0x4);
> }

without the * 0x4

> id = m_can_fifo_read(priv, fgi, M_CAN_FIFO_ID);
> 
> The problem is when adding long frames support, it becomes:
> enum m_can_fifo {
>         M_CAN_FIFO_ID = 0,
>         M_CAN_FIFO_DLC,
>         M_CAN_FIFO_DATA0,
>         M_CAN_FIFO_DATA1,
>         ....
>         M_CAN_FIFO_DATA15,
> };

#define M_CAN_FIFO_DATA(n)
	(enum m_can_fifo)(M_CAN_FIFO_DATA_0 + (n) << 2)

> But it's useless because we may not use enum to read fifo data anymore.
> It's not suitable to read fifo one by one:
> m_can_fifo_read(priv, fgi, M_CAN_FIFO_DATA0);
> m_can_fifo_read(priv, fgi, M_CAN_FIFO_DATA1);
> ..
> m_can_fifo_read(priv, fgi, M_CAN_FIFO_DATA15);
> 
> 
> Instead, we may read data according to real dlc value within a for loop like:
> #define M_CAN_FIFO(n)   (n * 0x4)
> id = m_can_fifo_read(priv, fgi, M_CAN_FIFO(0));
> dlc = m_can_fifo_read(priv, fgi, M_CAN_FIFO(1));
> for (i = 0; dlc > 0; dlc -= 0x4, i++) {
>         ....
>         data[i] = m_can_fifo_read(priv, fgi, M_CAN_FIFO(i + 2));
> }

id = m_can_fifo_read(priv, fgi, M_CAN_FIFO_ID);
dlc = m_can_fifo_read(priv, fgi, M_CAN_FIFO_DLC);
for (i = 0; i <= dlc; i++)
	data[i] = m_can_fifo_read(priv, fgi, M_CAN_FIFO_DATA(i));

> So i'm not sure define that enum now is really needed.

[...]

>>>>> +static int m_can_handle_lec_err(struct net_device *dev,
>>>>> +				enum m_can_lec_type lec_type)
>>>>> +{
>>>>> +	struct m_can_priv *priv = netdev_priv(dev);
>>>>> +	struct net_device_stats *stats = &dev->stats;
>>>>> +	struct can_frame *cf;
>>>>> +	struct sk_buff *skb;
>>>>> +
>>>>> +	/* early exit if no lec update */
>>>>> +	if (lec_type == LEC_UNUSED)
>>>>> +		return 0;
>>>>
>>>> I think this is not needed, as checked by the only caller.
>>>
>>> You mean move it to caller as follows?
>>>         /* handle lec errors on the bus */
>>>         if ((psr & LEC_UNUSED) && ((psr & LEC_UNUSED)!= LEC_UNUSED) &&
>>
>> yes - or something like this:
>>
>> static inline bool is_lec(u32 psr)
>> {
>> 	u32 psr &= LEC_UNUSED
>>
>> 	return psr && (psr != LEC_UNUSED)
>> }
>>
>> 	if ((priv->can.ctrlmode & CAN_CTRLMODE_BERR_REPORTING) &&
>> 		is_lec(psr)) {
>> 	}
>>
> 
> 
> Looks fine.
> Maybe is_lec_err(u32 psr) better? :-)

Yes, is_lec() was just a random placeholder :) Descriptive function
names are always preferred.

Marc

-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 242 bytes --]

  reply	other threads:[~2014-07-15  8:46 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-14 11:40 [PATCH v4 1/2] can: m_can: add device tree binding documentation Dong Aisheng
2014-07-14 11:40 ` [PATCH v4 2/2] can: m_can: add Bosch M_CAN controller support Dong Aisheng
2014-07-14 12:13   ` Marc Kleine-Budde
2014-07-15  3:33     ` Dong Aisheng
2014-07-15  7:29       ` Marc Kleine-Budde
2014-07-15  8:26         ` Dong Aisheng
2014-07-15  8:46           ` Marc Kleine-Budde [this message]
2014-07-15  9:07             ` Dong Aisheng
2014-07-15  9:21               ` Marc Kleine-Budde
2014-07-15 10:40                 ` Dong Aisheng
2014-07-14 12:47   ` Varka Bhadram
2014-07-14 13:01     ` Marc Kleine-Budde
2014-07-14 13:15       ` Varka Bhadram
2014-07-15  6:28       ` Dong Aisheng
2014-07-15  6:27     ` Dong Aisheng
2014-07-15  6:56       ` Varka Bhadram
2014-07-15  7:10         ` Marc Kleine-Budde
2014-07-15  7:15           ` Varka Bhadram
2014-07-15  7:14             ` Dong Aisheng
2014-07-15  7:20               ` Varka Bhadram
2014-07-14 11:52 ` [PATCH v4 1/2] can: m_can: add device tree binding documentation Marc Kleine-Budde
2014-07-15  2:26   ` Dong Aisheng

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53C4EA68.5090606@pengutronix.de \
    --to=mkl@pengutronix.de \
    --cc=b29396@freescale.com \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-can@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=socketcan@hartkopp.net \
    --cc=varkabhadram@gmail.com \
    --cc=wg@grandegger.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).