From: khalasa@piap.pl (Krzysztof Hałasa)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFT PATCH v2] mtd: ixp4xx: Unrequire CONFIG_MTD_CFI_BE_BYTE_SWAP
Date: Mon, 29 Sep 2014 09:50:08 +0200 [thread overview]
Message-ID: <m3fvfac1cf.fsf@t19.piap.pl> (raw)
In-Reply-To: <1800715024.324263.1411508605796.JavaMail.zimbra@xes-inc.com> (Aaron Sierra's message of "Tue, 23 Sep 2014 16:43:25 -0500 (CDT)")
Aaron Sierra <asierra@xes-inc.com> writes:
> The .swap member of the map_info structure is provided for situations
> where a mapping must always be big or little endian regardless of the
> endianness of the system performing the access.
I like the idea but the patch doesn't work :-(
Without the patch:
IXP4XX-Flash.0: Found 1 x16 devices at 0x0 in 16-bit bank. Manufacturer ID 0x000089 Chip ID 0x008922
Intel/Sharp Extended Query Table at 0x010A
Intel/Sharp Extended Query Table at 0x010A
Intel/Sharp Extended Query Table at 0x010A
Intel/Sharp Extended Query Table at 0x010A
Intel/Sharp Extended Query Table at 0x010A
Using buffer write method
Using auto-unlock on power-up/resume
cfi_cmdset_0001: Erase suspend on write enabled
Searching for RedBoot partition table in IXP4XX-Flash.0 at offset 0x1fe0000
5 RedBoot partitions found on MTD device IXP4XX-Flash.0
With the patch applied:
IXP4XX-Flash.0: Found 1 x16 devices at 0x0 in 16-bit bank. Manufacturer ID 0x000089 Chip ID 0x008922
Intel/Sharp Extended Query Table at 0x010A
Intel/Sharp Extended Query Table at 0x010A
Intel/Sharp Extended Query Table at 0x010A
Intel/Sharp Extended Query Table at 0x010A
Intel/Sharp Extended Query Table at 0x010A
Using buffer write method
Using auto-unlock on power-up/resume
cfi_cmdset_0001: Erase suspend on write enabled
Searching for RedBoot partition table in IXP4XX-Flash.0 at offset 0x1fe0000
No RedBoot partition table detected in IXP4XX-Flash.0
> +++ b/drivers/mtd/maps/ixp4xx.c
> -#ifndef __ARMEB__
> -#ifndef CONFIG_MTD_CFI_BE_BYTE_SWAP
> -# error CONFIG_MTD_CFI_BE_BYTE_SWAP required
> +
> +#ifdef __ARMEB__
> +#define fixup_32(io) (io)
> +#else
> +#define fixup_32(io) (void __iomem *)((unsigned long)(io) ^ 2)
> #endif
>
> static inline u16 flash_read16(void __iomem *addr)
> {
> - return be16_to_cpu(__raw_readw((void __iomem *)((unsigned long)addr ^ 0x2)));
> + return be16_to_cpu(__raw_readw(fixup_32(addr)));
> }
>
> static inline void flash_write16(u16 d, void __iomem *addr)
> {
> - __raw_writew(cpu_to_be16(d), (void __iomem *)((unsigned long)addr ^ 0x2));
> + __raw_writew(cpu_to_be16(d), fixup_32(addr));
> }
The above change seems fine.
> #define BYTE0(h) ((h) & 0xFF)
> #define BYTE1(h) (((h) >> 8) & 0xFF)
>
> -#else
...
> -#define BYTE0(h) (((h) >> 8) & 0xFF)
> -#define BYTE1(h) ((h) & 0xFF)
> -#endif
This is used by ixp4xx_copy_from(). I don't exactly know what is MTD
layer going to do with map.swap = CFI_BIG_ENDIAN, but I think the
natural thing (= big endian on this CPU) is to copy data in big-endian
order, and then maybe (in LE mode) swap it.
In fact, it detects those RedBoot partitions when I use the original BE
BYTE0/BYTE1 macros (this second set, deleted by your patch).
Tested in BE mode only for now, can't give it more time at the moment
but will do soon.
CONFIG_MTD_CFI=y
CONFIG_MTD_CFI_ADV_OPTIONS=y
CONFIG_MTD_CFI_NOSWAP=y
# CONFIG_MTD_CFI_BE_BYTE_SWAP is not set
# CONFIG_MTD_CFI_LE_BYTE_SWAP is not set
CONFIG_MTD_CFI_GEOMETRY=y
CONFIG_MTD_CFI_I1=y
# CONFIG_MTD_CFI_I2 is not set
# CONFIG_MTD_CFI_I4 is not set
# CONFIG_MTD_CFI_I8 is not set
CONFIG_MTD_CFI_INTELEXT=y
# CONFIG_MTD_CFI_AMDSTD is not set
# CONFIG_MTD_CFI_STAA is not set
CONFIG_MTD_CFI_UTIL=y
--
Krzysztof Halasa
Research Institute for Automation and Measurements PIAP
Al. Jerozolimskie 202, 02-486 Warsaw, Poland
next prev parent reply other threads:[~2014-09-29 7:50 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <474471133.324147.1411508523465.JavaMail.zimbra@xes-inc.com>
2014-09-23 21:43 ` [RFT PATCH v2] mtd: ixp4xx: Unrequire CONFIG_MTD_CFI_BE_BYTE_SWAP Aaron Sierra
2014-09-29 7:50 ` Krzysztof Hałasa [this message]
2014-09-29 19:05 ` Aaron Sierra
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=m3fvfac1cf.fsf@t19.piap.pl \
--to=khalasa@piap.pl \
--cc=linux-arm-kernel@lists.infradead.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.