All of lore.kernel.org
 help / color / mirror / Atom feed
From: Artem Bityutskiy <dedekind@infradead.org>
To: Andrey Volkov <avolkov@varma-el.com>
Cc: Andrea Galbusera <andrea.galbusera@teamware.it>,
	linux-mtd@lists.infradead.org, linuxppc-embedded@ozlabs.org
Subject: Re: JFFS2 on Lite5200
Date: Tue, 17 Oct 2006 17:18:44 +0300	[thread overview]
Message-ID: <1161094725.3260.76.camel@sauron> (raw)
In-Reply-To: <4534D8A5.7060206@varma-el.com>

On Tue, 2006-10-17 at 17:20 +0400, Andrey Volkov wrote:
> Andrea, check ml archive, I already sent patch half-year ago
> (http://ozlabs.org/pipermail/linuxppc-embedded/2006-April/022566.html)
> Problem is in alignment/memcpy: JFFS2 code assumed that memory at
> unaligned addresses could be touched, but access to an external MMIO
> on MPC5200 _must_ be aligned (i.e. you could not read u32 from odd address).
> 
> P.S. Artem, I repeat, I sent this patch _HALF_YEAR_AGO_
> how about to fix scan.c?

Just talked to David. Please, find the result of our discussion in my
edition below.

Strictly speaking, JFFS2 *does not* do anything wrong, so it should not
be fixed. Indeed, JFFS2 does have full right to use memcpy() for that.

The question is: does memcpy() make sense for flash adresses at your
board? Is it a valid operation for flash addresses at your board?

If the answer is yes - then please fix memcpy() for your platform.

If no - then please, do not pretend that your flash may be treated as
memory and fix your platform MTD driver. Namely, set point()/unpoint()
to NULL in your mapping driver - JFFS2 should work then.

-- 
Best regards,
Artem Bityutskiy (Битюцкий Артём)

WARNING: multiple messages have this Message-ID (diff)
From: Artem Bityutskiy <dedekind@infradead.org>
To: Andrey Volkov <avolkov@varma-el.com>
Cc: Andrea Galbusera <andrea.galbusera@teamware.it>,
	linux-mtd@lists.infradead.org, linuxppc-embedded@ozlabs.org
Subject: Re: JFFS2 on Lite5200
Date: Tue, 17 Oct 2006 17:18:44 +0300	[thread overview]
Message-ID: <1161094725.3260.76.camel@sauron> (raw)
In-Reply-To: <4534D8A5.7060206@varma-el.com>

On Tue, 2006-10-17 at 17:20 +0400, Andrey Volkov wrote:
> Andrea, check ml archive, I already sent patch half-year ago
> (http://ozlabs.org/pipermail/linuxppc-embedded/2006-April/022566.html)
> Problem is in alignment/memcpy: JFFS2 code assumed that memory at
> unaligned addresses could be touched, but access to an external MMIO
> on MPC5200 _must_ be aligned (i.e. you could not read u32 from odd addres=
s).
>=20
> P.S. Artem, I repeat, I sent this patch _HALF_YEAR_AGO_
> how about to fix scan.c?

Just talked to David. Please, find the result of our discussion in my
edition below.

Strictly speaking, JFFS2 *does not* do anything wrong, so it should not
be fixed. Indeed, JFFS2 does have full right to use memcpy() for that.

The question is: does memcpy() make sense for flash adresses at your
board? Is it a valid operation for flash addresses at your board?

If the answer is yes - then please fix memcpy() for your platform.

If no - then please, do not pretend that your flash may be treated as
memory and fix your platform MTD driver. Namely, set point()/unpoint()
to NULL in your mapping driver - JFFS2 should work then.

--=20
Best regards,
Artem Bityutskiy (=D0=91=D0=B8=D1=82=D1=8E=D1=86=D0=BA=D0=B8=D0=B9 =D0=90=
=D1=80=D1=82=D1=91=D0=BC)

  parent reply	other threads:[~2006-10-17 14:19 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-17 10:33 JFFS2 on Lite5200 Andrea Galbusera
2006-10-17 13:20 ` Andrey Volkov
2006-10-17 13:36   ` Artem Bityutskiy
2006-10-17 13:36     ` Artem Bityutskiy
2006-10-17 13:54     ` Andrey Volkov
2006-10-17 17:37       ` David Woodhouse
2006-10-17 17:37         ` David Woodhouse
2006-10-17 20:16         ` Andrey Volkov
2006-10-17 20:16           ` Andrey Volkov
2006-10-17 14:18   ` Artem Bityutskiy [this message]
2006-10-17 14:18     ` Artem Bityutskiy
2006-10-17 20:37 ` Wolfgang Denk

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=1161094725.3260.76.camel@sauron \
    --to=dedekind@infradead.org \
    --cc=andrea.galbusera@teamware.it \
    --cc=avolkov@varma-el.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=linuxppc-embedded@ozlabs.org \
    /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.