Select Git revision
Search by author
- Any Author
- authors
-
Angus Ainslie
angus.ainslie
-
Eric Kuzmenko
eric.kuzmenko
-
Evangelos Ribeiro Tzaras
evangelos.tzaras
-
Francois Techene
francois.techene
-
Guido Gunther
guido.gunther
-
JC Staudt
jcstaudt
-
Jonathon Hall
jonathon.hall
-
Julian Sparber
julian.sparber
-
Martin Kepplinger
martin.kepplinger
-
Mohammed Sadiq
mohammed.sadiq
-
Richard Kolla
richard.kolla
-
Sam Hewitt sam.hewitt
-
Sebastian Krzyszkowiak
sebastian.krzyszkowiak
- Dec 11, 2020
-
-
Miquel Raynal authored
Originally, commit d7157ff4 ("mtd: rawnand: Use the ECC framework user input parsing bits") kind of broke the logic around the initialization of several ECC engines. Unfortunately, the fix (which indeed moved the ECC initialization to the right place) did not take into account the fact that a different ECC algorithm could have been used thanks to a DT property, considering the "Hamming" algorithm entry a configuration while it was only a default. Add the necessary logic to be sure Hamming keeps being only a default. Fixes: d525914b ("mtd: rawnand: xway: Move the ECC initialization to ->attach_chip()") Signed-off-by:
-
Miquel Raynal authored
Originally, commit d7157ff4 ("mtd: rawnand: Use the ECC framework user input parsing bits") kind of broke the logic around the initialization of several ECC engines. Unfortunately, the fix (which indeed moved the ECC initialization to the right place) did not take into account the fact that a different ECC algorithm could have been used thanks to a DT property, considering the "Hamming" algorithm entry a configuration while it was only a default. Add the necessary logic to be sure Hamming keeps being only a default. Fixes: b36bf0a0 ("mtd: rawnand: socrates: Move the ECC initialization to ->attach_chip()") Signed-off-by:
-
Miquel Raynal authored
Originally, commit d7157ff4 ("mtd: rawnand: Use the ECC framework user input parsing bits") kind of broke the logic around the initialization of several ECC engines. Unfortunately, the fix (which indeed moved the ECC initialization to the right place) did not take into account the fact that a different ECC algorithm could have been used thanks to a DT property, considering the "Hamming" algorithm entry a configuration while it was only a default. Add the necessary logic to be sure Hamming keeps being only a default. Fixes: 612e048e ("mtd: rawnand: plat_nand: Move the ECC initialization to ->attach_chip()") Signed-off-by:
-
Miquel Raynal authored
Originally, commit d7157ff4 ("mtd: rawnand: Use the ECC framework user input parsing bits") kind of broke the logic around the initialization of several ECC engines. Unfortunately, the fix (which indeed moved the ECC initialization to the right place) did not take into account the fact that a different ECC algorithm could have been used thanks to a DT property, considering the "Hamming" algorithm entry a configuration while it was only a default. Add the necessary logic to be sure Hamming keeps being only a default. Fixes: 8fc6f1f0 ("mtd: rawnand: pasemi: Move the ECC initialization to ->attach_chip()") Signed-off-by:
-
Miquel Raynal authored
Originally, commit d7157ff4 ("mtd: rawnand: Use the ECC framework user input parsing bits") kind of broke the logic around the initialization of several ECC engines. Unfortunately, the fix (which indeed moved the ECC initialization to the right place) did not take into account the fact that a different ECC algorithm could have been used thanks to a DT property, considering the "Hamming" algorithm entry a configuration while it was only a default. Add the necessary logic to be sure Hamming keeps being only a default. Reported-by:
-
Miquel Raynal authored
Originally, commit d7157ff4 ("mtd: rawnand: Use the ECC framework user input parsing bits") kind of broke the logic around the initialization of several ECC engines. Unfortunately, the fix (which indeed moved the ECC initialization to the right place) did not take into account the fact that a different ECC algorithm could have been used thanks to a DT property, considering the "Hamming" algorithm entry a configuration while it was only a default. Add the necessary logic to be sure Hamming keeps being only a default. Fixes: 6dd09f77 ("mtd: rawnand: mpc5121: Move the ECC initialization to ->attach_chip()") Signed-off-by:
-
Miquel Raynal authored
Originally, commit d7157ff4 ("mtd: rawnand: Use the ECC framework user input parsing bits") kind of broke the logic around the initialization of several ECC engines. Unfortunately, the fix (which indeed moved the ECC initialization to the right place) did not take into account the fact that a different ECC algorithm could have been used thanks to a DT property, considering the "Hamming" algorithm entry a configuration while it was only a default. Add the necessary logic to be sure Hamming keeps being only a default. Fixes: f6341f64 ("mtd: rawnand: gpio: Move the ECC initialization to ->attach_chip()") Signed-off-by:
-
Miquel Raynal authored
Originally, commit d7157ff4 ("mtd: rawnand: Use the ECC framework user input parsing bits") kind of broke the logic around the initialization of several ECC engines. Unfortunately, the fix (which indeed moved the ECC initialization to the right place) did not take into account the fact that a different ECC algorithm could have been used thanks to a DT property, considering the "Hamming" algorithm entry a configuration while it was only a default. Add the necessary logic to be sure Hamming keeps being only a default. Fixes: dbffc8cc ("mtd: rawnand: au1550: Move the ECC initialization to ->attach_chip()") Signed-off-by:
-
Miquel Raynal authored
Originally, commit d7157ff4 ("mtd: rawnand: Use the ECC framework user input parsing bits") kind of broke the logic around the initialization of several ECC engines. Unfortunately, the fix (which indeed moved the ECC initialization to the right place) did not take into account the fact that a different ECC algorithm could have been used thanks to a DT property, considering the "Hamming" algorithm entry a configuration while it was only a default. Add the necessary logic to be sure Hamming keeps being only a default. Fixes: 59d93473 ("mtd: rawnand: ams-delta: Move the ECC initialization to ->attach_chip()") Signed-off-by:
-
- Nov 20, 2020
-
-
Miquel Raynal authored
The probe function is only supposed to initialize the controller hardware but not the ECC engine. Indeed, we don't know anything about the NAND chip(s) at this stage. Let's move the logic initializing the ECC engine, even pretty simple, to the ->attach_chip() hook which gets called during nand_scan() routine, after the NAND chip discovery. As the previously mentioned logic is supposed to parse the DT for us, it is likely that the chip->ecc.* entries be overwritten. So let's avoid this by moving these lines to ->attach_chip(). Fixes: d7157ff4 ("mtd: rawnand: Use the ECC framework user input parsing bits") Signed-off-by:
-
Miquel Raynal authored
The probe function is only supposed to initialize the controller hardware but not the ECC engine. Indeed, we don't know anything about the NAND chip(s) at this stage. Let's move the logic initializing the ECC engine, even pretty simple, to the ->attach_chip() hook which gets called during nand_scan() routine, after the NAND chip discovery. As the previously mentioned logic is supposed to parse the DT for us, it is likely that the chip->ecc.* entries be overwritten. So let's avoid this by moving these lines to ->attach_chip(). Fixes: d7157ff4 ("mtd: rawnand: Use the ECC framework user input parsing bits") Signed-off-by:
-
Miquel Raynal authored
The probe function is only supposed to initialize the controller hardware but not the ECC engine. Indeed, we don't know anything about the NAND chip(s) at this stage. Let's move the logic initializing the ECC engine, even pretty simple, to the ->attach_chip() hook which gets called during nand_scan() routine, after the NAND chip discovery. As the previously mentioned logic is supposed to parse the DT for us, it is likely that the chip->ecc.* entries be overwritten. So let's avoid this by moving these lines to ->attach_chip(). Fixes: d7157ff4 ("mtd: rawnand: Use the ECC framework user input parsing bits") Signed-off-by:
-
- Nov 19, 2020
-
-
Miquel Raynal authored
The probe function is only supposed to initialize the controller hardware but not the ECC engine. Indeed, we don't know anything about the NAND chip(s) at this stage. Let's move the logic initializing the ECC engine, even pretty simple, to the ->attach_chip() hook which gets called during nand_scan() routine, after the NAND chip discovery. As the previously mentioned logic is supposed to parse the DT for us, it is likely that the chip->ecc.* entries be overwritten. So let's avoid this by moving these lines to ->attach_chip(). Fixes: d7157ff4 ("mtd: rawnand: Use the ECC framework user input parsing bits") Signed-off-by:
-
Miquel Raynal authored
The probe function is only supposed to initialize the controller hardware but not the ECC engine. Indeed, we don't know anything about the NAND chip(s) at this stage. Let's move the logic initializing the ECC engine, even pretty simple, to the ->attach_chip() hook which gets called during nand_scan() routine, after the NAND chip discovery. As the previously mentioned logic is supposed to parse the DT for us, it is likely that the chip->ecc.* entries be overwritten. So let's avoid this by moving these lines to ->attach_chip(). Fixes: d7157ff4 ("mtd: rawnand: Use the ECC framework user input parsing bits") Signed-off-by:
-
Miquel Raynal authored
The probe function is only supposed to initialize the controller hardware but not the ECC engine. Indeed, we don't know anything about the NAND chip(s) at this stage. Let's move the logic initializing the ECC engine, even pretty simple, to the ->attach_chip() hook which gets called during nand_scan() routine, after the NAND chip discovery. As the previously mentioned logic is supposed to parse the DT for us, it is likely that the chip->ecc.* entries be overwritten. So let's avoid this by moving these lines to ->attach_chip(). Fixes: d7157ff4 ("mtd: rawnand: Use the ECC framework user input parsing bits") Signed-off-by:
-
Miquel Raynal authored
The probe function is only supposed to initialize the controller hardware but not the ECC engine. Indeed, we don't know anything about the NAND chip(s) at this stage. Let's move the logic initializing the ECC engine, even pretty simple, to the ->attach_chip() hook which gets called during nand_scan() routine, after the NAND chip discovery. As the previously mentioned logic is supposed to parse the DT for us, it is likely that the chip->ecc.* entries be overwritten. So let's avoid this by moving these lines to ->attach_chip(). Fixes: d7157ff4 ("mtd: rawnand: Use the ECC framework user input parsing bits") Signed-off-by:
-
Miquel Raynal authored
The probe function is only supposed to initialize the controller hardware but not the ECC engine. Indeed, we don't know anything about the NAND chip(s) at this stage. Let's move the logic initializing the ECC engine, even pretty simple, to the ->attach_chip() hook which gets called during nand_scan() routine, after the NAND chip discovery. As the previously mentioned logic is supposed to parse the DT for us, it is likely that the chip->ecc.* entries be overwritten. So let's avoid this by moving these lines to ->attach_chip(). Fixes: d7157ff4 ("mtd: rawnand: Use the ECC framework user input parsing bits") Signed-off-by:
-
Miquel Raynal authored
The probe function is only supposed to initialize the controller hardware but not the ECC engine. Indeed, we don't know anything about the NAND chip(s) at this stage. Let's move the logic initializing the ECC engine, even pretty simple, to the ->attach_chip() hook which gets called during nand_scan() routine, after the NAND chip discovery. As the previously mentioned logic is supposed to parse the DT for us, it is likely that the chip->ecc.* entries be overwritten. So let's avoid this by moving these lines to ->attach_chip(). Fixes: d7157ff4 ("mtd: rawnand: Use the ECC framework user input parsing bits") Signed-off-by:
-
Miquel Raynal authored
The probe function is only supposed to initialize the controller hardware but not the ECC engine. Indeed, we don't know anything about the NAND chip(s) at this stage. Let's move the logic initializing the ECC engine, even pretty simple, to the ->attach_chip() hook which gets called during nand_scan() routine, after the NAND chip discovery. As the previously mentioned logic is supposed to parse the DT for us, it is likely that the chip->ecc.* entries be overwritten. So let's avoid this by moving these lines to ->attach_chip(). Fixes: d7157ff4 ("mtd: rawnand: Use the ECC framework user input parsing bits") Signed-off-by:
-
Miquel Raynal authored
The probe function is only supposed to initialize the controller hardware but not the ECC engine. Indeed, we don't know anything about the NAND chip(s) at this stage. Let's move the logic initializing the ECC engine, even pretty simple, to the ->attach_chip() hook which gets called during nand_scan() routine, after the NAND chip discovery. As the previously mentioned logic is supposed to parse the DT for us, it is likely that the chip->ecc.* entries be overwritten. So let's avoid this by moving these lines to ->attach_chip(). Fixes: d7157ff4 ("mtd: rawnand: Use the ECC framework user input parsing bits") Signed-off-by:
-
Miquel Raynal authored
The probe function is only supposed to initialize the controller hardware but not the ECC engine. Indeed, we don't know anything about the NAND chip(s) at this stage. Let's move the logic initializing the ECC engine, even pretty simple, to the ->attach_chip() hook which gets called during nand_scan() routine, after the NAND chip discovery. As the previously mentioned logic is supposed to parse the DT for us, it is likely that the chip->ecc.* entries be overwritten. So let's avoid this by moving these lines to ->attach_chip(). Fixes: d7157ff4 ("mtd: rawnand: Use the ECC framework user input parsing bits") Signed-off-by:
-
Miquel Raynal authored
The probe function is only supposed to initialize the controller hardware but not the ECC engine. Indeed, we don't know anything about the NAND chip(s) at this stage. Let's move the logic initializing the ECC engine, even pretty simple, to the ->attach_chip() hook which gets called during nand_scan() routine, after the NAND chip discovery. As the previously mentioned logic is supposed to parse the DT for us, it is likely that the chip->ecc.* entries be overwritten. So let's avoid this by moving these lines to ->attach_chip(). Fixes: d7157ff4 ("mtd: rawnand: Use the ECC framework user input parsing bits") Signed-off-by:
-
Miquel Raynal authored
The probe function is only supposed to initialize the controller hardware but not the ECC engine. Indeed, we don't know anything about the NAND chip(s) at this stage. Let's move the logic initializing the ECC engine, even pretty simple, to the ->attach_chip() hook which gets called during nand_scan() routine, after the NAND chip discovery. As the previously mentioned logic is supposed to parse the DT for us, it is likely that the chip->ecc.* entries be overwritten. So let's avoid this by moving these lines to ->attach_chip(). Fixes: d7157ff4 ("mtd: rawnand: Use the ECC framework user input parsing bits") Signed-off-by:
-
Miquel Raynal authored
The probe function is only supposed to initialize the controller hardware but not the ECC engine. Indeed, we don't know anything about the NAND chip(s) at this stage. Let's move the logic initializing the ECC engine, even pretty simple, to the ->attach_chip() hook which gets called during nand_scan() routine, after the NAND chip discovery. As the previously mentioned logic is supposed to parse the DT for us, it is likely that the chip->ecc.* entries be overwritten. So let's avoid this by moving these lines to ->attach_chip(). Fixes: d7157ff4 ("mtd: rawnand: Use the ECC framework user input parsing bits") Signed-off-by:
-
Miquel Raynal authored
The probe function is only supposed to initialize the controller hardware but not the ECC engine. Indeed, we don't know anything about the NAND chip(s) at this stage. Let's move the logic initializing the ECC engine, even pretty simple, to the ->attach_chip() hook which gets called during nand_scan() routine, after the NAND chip discovery. As the previously mentioned logic is supposed to parse the DT for us, it is likely that the chip->ecc.* entries be overwritten. So let's avoid this by moving these lines to ->attach_chip(). Fixes: d7157ff4 ("mtd: rawnand: Use the ECC framework user input parsing bits") Signed-off-by:
-
Miquel Raynal authored
The probe function is only supposed to initialize the controller hardware but not the ECC engine. Indeed, we don't know anything about the NAND chip(s) at this stage. Let's move the logic initializing the ECC engine, even pretty simple, to the ->attach_chip() hook which gets called during nand_scan() routine, after the NAND chip discovery. As the previously mentioned logic is supposed to parse the DT for us, it is likely that the chip->ecc.* entries be overwritten. So let's avoid this by moving these lines to ->attach_chip(). Fixes: d7157ff4 ("mtd: rawnand: Use the ECC framework user input parsing bits") Signed-off-by:
-
Miquel Raynal authored
The probe function is only supposed to initialize the controller hardware but not the ECC engine. Indeed, we don't know anything about the NAND chip(s) at this stage. Let's move the logic initializing the ECC engine, even pretty simple, to the ->attach_chip() hook which gets called during nand_scan() routine, after the NAND chip discovery. As the previously mentioned logic is supposed to parse the DT for us, it is likely that the chip->ecc.* entries be overwritten. So let's avoid this by moving these lines to ->attach_chip(), a NAND controller hook. Fixes: d7157ff4 ("mtd: rawnand: Use the ECC framework user input parsing bits") Signed-off-by:
-
Miquel Raynal authored
The probe function is only supposed to initialize the controller hardware but not the ECC engine. Indeed, we don't know anything about the NAND chip(s) at this stage. Let's move the logic initializing the ECC engine, even pretty simple, to the ->attach_chip() hook which gets called during nand_scan() routine, after the NAND chip discovery. As the previously mentioned logic is supposed to parse the DT for us, it is likely that the chip->ecc.* entries be overwritten. So let's avoid this by moving these lines to ->attach_chip(), a NAND controller hook. Fixes: d7157ff4 ("mtd: rawnand: Use the ECC framework user input parsing bits") Reported-by:
-
- Oct 30, 2020
-
-
Christophe Kerello authored
Since commit d7157ff4 ("mtd: rawnand: Use the ECC framework user input parsing bits"), ECC are broken in FMC2 driver in case of nand-ecc-step-size and nand-ecc-strength are not set in the device tree. To avoid this issue, the default settings are now set in stm32_fmc2_nfc_attach_chip function. Signed-off-by:
-
- Oct 28, 2020
-
-
Bert Vermeulen authored
If a flash chip has more than 16MB capacity but its BFPT reports BFPT_DWORD1_ADDRESS_BYTES_3_OR_4, the spi-nor framework defaults to 3. The check in spi_nor_set_addr_width() doesn't catch it because addr_width did get set. This fixes that check. Fixes: f9acd7fa ("mtd: spi-nor: sfdp: default to addr_width of 3 for configurable widths") Signed-off-by:
-
Alexander Sverdlin authored
spi_nor_parse_sfdp() modifies the passed structure so that it points to itself (params.erase_map.regions to params.erase_map.uniform_region). This makes it impossible to copy the local struct anywhere else. Therefore only use memcpy() in backup-restore scenario. The bug may show up like below: BUG: unable to handle page fault for address: ffffc90000b377f8 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 4 PID: 3500 Comm: flashcp Tainted: G O 5.4.53-... #1 ... RIP: 0010:spi_nor_erase+0x8e/0x5c0 Code: 64 24 18 89 db 4d 8b b5 d0 04 00 00 4c 89 64 24 18 4c 89 64 24 20 eb 12 a8 10 0f 85 59 02 00 00 49 83 c6 10 0f 84 4f 02 00 00 <49> 8b 06 48 89 c2 48 83 e2 c0 48 89 d1 49 03 4e 08 48 39 cb 73 d8 RSP: 0018:ffffc9000217fc48 EFLAGS: 00010206 RAX: 0000000000740000 RBX: 0000000000000000 RCX: 0000000000740000 RDX: ffff8884550c9980 RSI: ffff88844f9c0bc0 RDI: ffff88844ede7bb8 RBP: 0000000000740000 R08: ffffffff815bfbe0 R09: ffff88844f9c0bc0 R10: 0000000000000000 R11: 0000000000000000 R12: ffffc9000217fc60 R13: ffff88844ede7818 R14: ffffc90000b377f8 R15: 0000000000000000 FS: 00007f4699780500(0000) GS:ffff88846ff00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffc90000b377f8 CR3: 00000004538ee000 CR4: 0000000000340fe0 Call Trace: part_erase+0x27/0x50 mtdchar_ioctl+0x831/0xba0 ? filemap_map_pages+0x186/0x3d0 ? do_filp_open+0xad/0x110 ? _copy_to_user+0x22/0x30 ? cp_new_stat+0x150/0x180 mtdchar_unlocked_ioctl+0x2a/0x40 do_vfs_ioctl+0xa0/0x630 ? __do_sys_newfstat+0x3c/0x60 ksys_ioctl+0x70/0x80 __x64_sys_ioctl+0x16/0x20 do_syscall_64+0x6a/0x200 ? prepare_exit_to_usermode+0x50/0xd0 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7f46996b6817 Cc: stable@vger.kernel.org Fixes: c4687217 ("mtd: spi-nor: Move erase_map to 'struct spi_nor_flash_parameter'") Co-developed-by:
-
- Oct 26, 2020
-
-
Fabio Estevam authored
No ECC initialization should happen during the host controller probe. In fact, we need the probe function to call nand_scan() in order to: - identify the device, its capabilities and constraints (nand_scan_ident()) - configure the ECC engine accordingly (->attach_chip()) - scan its content and prepare the core (nand_scan_tail()) Moving these lines to fsl_ifc_attach_chip() fixes a regression caused by a previous commit supposed to clarify these steps. Based on a fix done for the mxc_nand driver by Miquel Raynal. Fixes: d7157ff4 ("mtd: rawnand: Use the ECC framework user input parsing bits") Reported-by:
-
Fabio Estevam authored
No ECC initialization should happen during the host controller probe. In fact, we need the probe function to call nand_scan() in order to: - identify the device, its capabilities and constraints (nand_scan_ident()) - configure the ECC engine accordingly (->attach_chip()) - scan its content and prepare the core (nand_scan_tail()) Moving these lines to mxcnd_attach_chip() fixes a regression caused by a previous commit supposed to clarify these steps. When moving the ECC initialization from probe() to attach(), get rid of the pdata usage to determine the engine type and let the core decide instead. Tested on a imx27-pdk board. Fixes: d7157ff4 ("mtd: rawnand: Use the ECC framework user input parsing bits") Reported-by:
-
- Oct 12, 2020
-
-
Vignesh Raghavendra authored
commit 5de15b61 ("mtd: hyperbus: add Renesas RPC-IF driver") leads to build failure[1] with COMPILE_TEST and RPCIF_HYPERBUS enabled. This is because driver needs functions RENESAS_RPCIF which is only buildable for CONFIG_ARCH_RENESAS. Fix this by dropping COMPILE_TEST from RPCIF_HYPERBUS Kconfig entry. This ensures driver can be built only when RENESAS_RPCIF is also selected. [1]: rpc-if.c:(.text+0x20): undefined reference to `rpcif_disable_rpm' ld: drivers/mtd/hyperbus/rpc-if.o: in function `rpcif_hb_prepare_read': rpc-if.c:(.text+0xd6): undefined reference to `rpcif_prepare' ld: drivers/mtd/hyperbus/rpc-if.o: in function `rpcif_hb_read16': [...] Fixes: 5de15b61 ("mtd: hyperbus: add Renesas RPC-IF driver") leads Reported-by:
-
- Oct 06, 2020
-
-
Sergei Shtylyov authored
Add the HyperFLash driver for the Renesas RPC-IF. It's the "front end" driver using the "back end" APIs in the main driver to talk to the real hardware. Signed-off-by:
-
Vignesh Raghavendra authored
This reverts commit 03edda0e. This leads to warn dump like [1] on some platforms and reorders MTD devices which may break user space expectations [2]. So revert the change. [1]: [ 1.849801] ------------[ cut here ]------------ [ 1.854271] mscc_felix 0000:00:00.5: device is disabled, skipping [ 1.858753] WARNING: CPU: 1 PID: 7 at kernel/kmod.c:136 __request_module+0x3a4/0x568 [...] [2] Bug report: https://lore.kernel.org/linux-mtd/20201003150633.23416-1-michael@walle.cc/ Reported-by:
-
- Oct 02, 2020
-
-
Florian Fainelli authored
With commit 91e81150 ("mtd: parsers: bcm63xx: simplify CFE detection"), we generate a reference to fw_arg3 which is the fourth firmware/command line argument on MIPS platforms. That symbol is not exported and would cause a linking failure. The parser is typically necessary to boot a BCM63xx-based system anyway so having it be part of the kernel image makes sense, therefore make it 'bool' instead of 'tristate'. Fixes: 91e81150 ("mtd: parsers: bcm63xx: simplify CFE detection") Signed-off-by:
-
Miquel Raynal authored
This driver does not contain any architecture specific code, enable compile testing it. Signed-off-by:
-
Bernard Zhao authored
Change struct memcard`s element "removeable" -> "removable". Signed-off-by:
-
Serge Semin authored
Baikal-T1 Boot Controller provides an access to a RO storages, which are physically mapped into the SoC MMIO space. In particularly there are Internal ROM embedded into the SoC with a pre-installed firmware, externally attached SPI flash (also accessed in the read-only mode) and a memory region, which mirrors one of them in accordance with the currently enabled system boot mode (also called Boot ROM). This commit adds the Internal ROM support to the physmap driver of the MTD kernel subsystem. The driver will create the Internal ROM MTD as long as it is defined in the system dts file. The physically mapped SPI flash region will be used to implement the SPI-mem interface. The mirroring memory region won't be accessible directly since it's redundant due to both bootable regions being exposed anyway. Note we had to create a dedicated code for the ROMs since read from the corresponding memory regions must be done via the dword-aligned addresses. Signed-off-by:
-