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
Subject: Re: [PATCH v2 1/1] can: m_can: add Bosch M_CAN controller support
Date: Tue, 08 Jul 2014 12:41:41 +0200 [thread overview]
Message-ID: <53BBCAE5.7040404@pengutronix.de> (raw)
In-Reply-To: <20140708103009.GA21754@shlinux1.ap.freescale.net>
[-- Attachment #1: Type: text/plain, Size: 3004 bytes --]
On 07/08/2014 12:30 PM, Dong Aisheng wrote:
>> Regarding the mram and the offsets:
>>
>>> fifo_addr = priv->mram_base + priv->rxf0_off + fgi * RXF0_ELEMENT_SIZE;
>>> fifo_addr = priv->mram_base + priv->mram_off + priv->txb_off;
>>
>> Why is rxf0_off used without the mram_off and txb_off with the mram_off?
>> Can you please test your driver with a mram offset != in your DT.
>>
>> If I understand the code in m_can_of_parse_mram() correctly the
>> individual *_off are already offsets to the *mram_base, so mram_off
>> should not be used within the driver.
>
> Good catch!
> You're right! I aslo found this recently!
> txb_off already includes the mram_off so should not plus mram_off again.
> The former test did not find it because it's still not exceed the 16K ram
> size for m_can0. But m_can1 has such issue.
>
>> I even think mram_off should be removed from the priv.
>
> Right, i also think so.
>
> It is used for debug information formerly that we need mram_off
> to calculate each element address in the fifo.
>
> By removing mram_off, i'm going to change the debug information to:
> dev_dbg(&pdev->dev, "mram_base %p sidf 0x%x %d xidf 0x%x %d rxf0 %x %d rxf1 %x %d rxb %x %d txe %x %d txb %x %d\n",
> priv->mram_base, priv->sidf_off, priv->sidf_elems,
> priv->xidf_off, priv->xidf_elems, priv->rxf0_off,
> priv->rxf0_elems, priv->rxf1_off, priv->rxf1_elems,
> priv->rxb_off, priv->rxb_elems, priv->txe_off,
> priv->txe_elems, priv->txb_off, priv->txb_elems);
>
> The annoying thing is the line has to be a much bigger one to avoid
> checkpatch warning of "WARNING: quoted string split across lines".
>
> What's your suggestion for such issue?
> Keeping the big line or split into two lines and leave checkpatch warning there?
The idea behind the warning is, that you can grep for error messages
better, as normal grep wouldn't find an error string which spans two
lines. So make it a long line.
>> Do the *_off and *_elems fit into a u8 or u16? If
>> so it makes sense to convert the priv accordingly.
>>
>
> Yes, *_off fit into u16 since MRAM has a maximum of 4352 words(17K).
> And *_elems fit into u8 since the max number is 128.
> I will change them accordingly.
>
>> What about putting the offset and the number of elements into a struct
>> and make use an array for rxf{0,1}?
>>
>
> You mean something like below?
> struct mram_cfg {
> u16 off;
> u8 elements;
> };
>
> struct m_can_priv {
> ........
>
> struct mram_cfg sidf;
> struct mram_cfg xidf;
> struct mram_cfg rxf0;
> struct mram_cfg rxf1;
struct mram_cfg rxf[2];
> ......
> struct mram_cfg txb;
> };
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-08 10:41 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-04 11:53 [PATCH v2 1/1] can: m_can: add Bosch M_CAN controller support Dong Aisheng
2014-07-04 12:21 ` Marc Kleine-Budde
2014-07-07 7:10 ` Dong Aisheng
2014-07-07 10:24 ` Marc Kleine-Budde
2014-07-08 10:30 ` Dong Aisheng
2014-07-08 10:41 ` Marc Kleine-Budde [this message]
2014-07-08 11:08 ` Dong Aisheng
2014-07-08 11:20 ` Marc Kleine-Budde
2014-07-08 11:18 ` Dong Aisheng
2014-07-04 12:53 ` Varka Bhadram
2014-07-08 10:33 ` 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=53BBCAE5.7040404@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=socketcan@hartkopp.net \
--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).