All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Kleine-Budde <mkl@pengutronix.de>
To: "Lothar Waßmann" <LW@KARO-electronics.de>
Cc: Matt Sealey <neko@bakuhatsu.net>,
	Russell King - ARM Linux <linux@arm.linux.org.uk>,
	"linux-can@vger.kernel.org" <linux-can@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: imprecise external abort using the flexcan driver on i.MX6Q
Date: Mon, 30 Sep 2013 13:39:25 +0200	[thread overview]
Message-ID: <524962ED.9000605@pengutronix.de> (raw)
In-Reply-To: <21065.25189.119250.773885@ipc1.ka-ro>

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

On 09/30/2013 01:37 PM, Lothar Waßmann wrote:
> Hi,
> 
> Marc Kleine-Budde writes:
>> On 09/30/2013 01:06 PM, Lothar Waßmann wrote:
>>> Hi,
>>>
>>> Marc Kleine-Budde writes:
>>>> On 09/27/2013 07:24 PM, Matt Sealey wrote:
>>>>> Marc - I don't think FLEXCAN has changed layout at all in these areas.
>>>>> The hardware always worked this way..
>>>>
>>>> All flexcan cores support the RX FIFO, the mx6 supports an additional
>>>> mode for different acceptance filters.
>>>>
>>>>> The only difference here  is that the i.MX53 is doing something weird
>>>>> on the bus. The i.MX6Q is giving the absolutely correct BRESP for the
>>>>> transfer to the peripheral (in effect, a "go away, this is my data"
>>>>> failure, which the CPU turns into an imprecise abort since it no idea
>>>>> which transaction it committed aeons ago caused it).
>>>>>
>>>>> Writes to 0x90 to 0xDF while MCR[FEN] is set *should* cause a data
>>>>> abort.. because it's not even a read-only region, it *should* be
>>>>> totally inaccessible to the CPU.
>>>>>
>>>>> The question I have is, when MCR[FEN] is set on i.MX53, does reading
>>>>> from those reserved registers give anything but 0's or garbage? I'm
>>>>> curious, that's all, it doesn't really matter ;)
>>>>
>>>> The driver only read from message buffer 0, and uses buffer 8 for tx.
>>>> The others are not accessed, unless in that chip start routine. We don't
>>>> need this loop, it comes from the original driver. I think no one has
>>>> ever noticed that bug, because all other CPUs have not complained.
>>>>
>>>> The driver without the loop is working on mx6 and Lothar is testing it
>>>> on mx53.
>>>>
>>> I can confirm, that the driver still works on i.MX53 as before the
>>> patch.
>>> Is someone going to prepare a patch, or should I do it, as I was the
>>> one who first brought up this issue?
>>
>> I have a patch ready, it's basically what I send you. Can I add your
>> Tested-by?
>>
> Yes, of course.

Tnx,
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: 259 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: mkl@pengutronix.de (Marc Kleine-Budde)
To: linux-arm-kernel@lists.infradead.org
Subject: imprecise external abort using the flexcan driver on i.MX6Q
Date: Mon, 30 Sep 2013 13:39:25 +0200	[thread overview]
Message-ID: <524962ED.9000605@pengutronix.de> (raw)
In-Reply-To: <21065.25189.119250.773885@ipc1.ka-ro>

On 09/30/2013 01:37 PM, Lothar Wa?mann wrote:
> Hi,
> 
> Marc Kleine-Budde writes:
>> On 09/30/2013 01:06 PM, Lothar Wa?mann wrote:
>>> Hi,
>>>
>>> Marc Kleine-Budde writes:
>>>> On 09/27/2013 07:24 PM, Matt Sealey wrote:
>>>>> Marc - I don't think FLEXCAN has changed layout at all in these areas.
>>>>> The hardware always worked this way..
>>>>
>>>> All flexcan cores support the RX FIFO, the mx6 supports an additional
>>>> mode for different acceptance filters.
>>>>
>>>>> The only difference here  is that the i.MX53 is doing something weird
>>>>> on the bus. The i.MX6Q is giving the absolutely correct BRESP for the
>>>>> transfer to the peripheral (in effect, a "go away, this is my data"
>>>>> failure, which the CPU turns into an imprecise abort since it no idea
>>>>> which transaction it committed aeons ago caused it).
>>>>>
>>>>> Writes to 0x90 to 0xDF while MCR[FEN] is set *should* cause a data
>>>>> abort.. because it's not even a read-only region, it *should* be
>>>>> totally inaccessible to the CPU.
>>>>>
>>>>> The question I have is, when MCR[FEN] is set on i.MX53, does reading
>>>>> from those reserved registers give anything but 0's or garbage? I'm
>>>>> curious, that's all, it doesn't really matter ;)
>>>>
>>>> The driver only read from message buffer 0, and uses buffer 8 for tx.
>>>> The others are not accessed, unless in that chip start routine. We don't
>>>> need this loop, it comes from the original driver. I think no one has
>>>> ever noticed that bug, because all other CPUs have not complained.
>>>>
>>>> The driver without the loop is working on mx6 and Lothar is testing it
>>>> on mx53.
>>>>
>>> I can confirm, that the driver still works on i.MX53 as before the
>>> patch.
>>> Is someone going to prepare a patch, or should I do it, as I was the
>>> one who first brought up this issue?
>>
>> I have a patch ready, it's basically what I send you. Can I add your
>> Tested-by?
>>
> Yes, of course.

Tnx,
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   |

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 259 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130930/6d1fb191/attachment-0001.sig>

  reply	other threads:[~2013-09-30 11:39 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-26 14:01 imprecise external abort using the flexcan driver on i.MX6Q =?utf-8?Q?Lothar_Wa=C3=9Fmann?=
2013-09-26 15:22 ` Fabio Estevam
2013-09-26 15:26   ` Fabio Estevam
2013-09-27 14:32   ` Lothar Waßmann
2013-09-27 14:35     ` Marc Kleine-Budde
2013-09-26 15:42 ` Marc Kleine-Budde
2013-09-26 15:42   ` Marc Kleine-Budde
2013-09-26 15:54   ` Russell King - ARM Linux
2013-09-26 15:54     ` Russell King - ARM Linux
2013-09-26 16:24     ` Santosh Shilimkar
2013-09-26 16:24       ` Santosh Shilimkar
2013-09-27  9:23       ` Lothar Waßmann
2013-09-27  9:23         ` Lothar Waßmann
2013-09-27  9:43         ` Marc Kleine-Budde
2013-09-27  9:43           ` Marc Kleine-Budde
2013-09-27 10:04           ` Lothar Waßmann
2013-09-27 10:04             ` Lothar Waßmann
2013-09-27 10:14             ` Marc Kleine-Budde
2013-09-27 10:14               ` Marc Kleine-Budde
2013-09-27 10:43               ` Lothar Waßmann
2013-09-27 10:43                 ` Lothar Waßmann
2013-09-26 19:04     ` Matt Sealey
2013-09-26 19:04       ` Matt Sealey
2013-09-27  9:41       ` Lothar Waßmann
2013-09-27  9:41         ` Lothar Waßmann
2013-09-27 17:24         ` Matt Sealey
2013-09-27 17:24           ` Matt Sealey
2013-09-27 19:55           ` Marc Kleine-Budde
2013-09-27 19:55             ` Marc Kleine-Budde
2013-09-30 11:06             ` Lothar Waßmann
2013-09-30 11:06               ` Lothar Waßmann
2013-09-30 11:19               ` Marc Kleine-Budde
2013-09-30 11:19                 ` Marc Kleine-Budde
2013-09-30 11:37                 ` Lothar Waßmann
2013-09-30 11:37                   ` Lothar Waßmann
2013-09-30 11:39                   ` Marc Kleine-Budde [this message]
2013-09-30 11:39                     ` Marc Kleine-Budde
2013-09-27  8:59   ` Lothar Waßmann
2013-09-27  8:59     ` Lothar Waßmann

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=524962ED.9000605@pengutronix.de \
    --to=mkl@pengutronix.de \
    --cc=LW@KARO-electronics.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-can@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=neko@bakuhatsu.net \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.