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 --]
next prev parent 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).