The following devices have a Winbond W25Q256FV flash chip,
which does not have the RESET pin enabled by default,
and otherwise would require setting a bit in a status register.

Before moving to Linux 5.4, we had the patch:
0053-mtd-spi-nor-add-w25q256-3b-mode-switch.patch
which kept specific flash chips with explicit 3-byte and 4-byte address modes
to stay in 3-byte address mode while idle (after an erase or write)
by using a custom flag SPI_NOR_4B_READ_OP that was part of the patch.

this was obsoleted by the patch:
481-mtd-spi-nor-rework-broken-flash-reset-support.patch
which uses the newer upstream flag SNOR_F_BROKEN_RESET
for devices with a flash chip that cannot be hardware reset with RESET pin
and therefore must be left in 3-byte address mode when idle.

The new patch requires that the DTS of affected devices
have the property "broken-flash-reset", which was not yet added for most of them.

This commit adds the property for remaining affected devices in ramips target,
specifically because of the flash chip model.

However, it is possible that there are other devices
where the flash chip uses an explicit 4-byte address mode
and the RESET pin is not connected to the SOC on the board,
and those DTS would also need this property.

Ref: 22d982ea ("ramips: add support for switching between 3-byte and 4-byte addressing")
Ref: dfa521f1 ("generic: spi-nor: rework broken-flash-reset")
Signed-off-by: Michael Pratt <mcpratt@pm.me>

Convert most of the cases from mtd-mac-address to nvmem where
MAC addresses are set in the DTSI, but the partitions are only
located in the device DTS. This posed some problems earlier, since
in these cases we are using partitions before they are defined,
and the nvmem system did not seem to like that.

There have been a few different resolution approaches, based on
the different tradeoffs of deduplication vs. maintainability:

 1. In many cases, the partition tables were identical except for
    the firmware partition size, and the firmware partition was
    the last in the table.
    In these cases, the partition table has been moved to the
    DTSI, and only the firmware partition's "reg" property has
    been kept in the DTS files. So, the updated nvmem definition
    could stay in the DTSI files as well.

 2. For all other cases, splitting up the partition table would
    have introduced additional complexity. Thus, the nodes to be
    converted to nvmem have been moved to the DTS files where the
    partitioning was defined.

 3. For Netgear EX2700 and WN3000RP v3, the remaining DTSI file
    was completely dissolved, as it was quite small and the name
    was not really nice either.

 4. The D-Link DIR-853 A3 was converted to nvmem as well, though
    it is just a plain DTS file not taken care of in the first
    wave.

In addition, some minor rearrangements have been made for tidyness.

Not covered (yet) by this patch are:

 * Various unielec devices
 * The D-Link DIR-8xx family

Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>

The "/dts-v1/;" identifier is supposed to be present once at the
top of a device tree file after the includes have been processed.

In ramips, we therefore requested to have in the DTS files so far,
and omit it in the DTSI files. However, essentially the syntax of
the parent mtxxxx/rtxxxx DTSI files already determines the DTS
version, so putting it into the DTS files is just a useless repetition.

Consequently, this patch puts the dts-v1 statement into the top-level
SoC-based DTSI files, and removes all other occurences.
Since the dts-v1 statement needs to be before any other definitions,
this also moves the includes accordingly where necessary.

Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>

In DTS Checklist[1] we're now demanding proper generic node names, as
the name of a node should reflect the function of the device and use
generic name for that[2]. Everybody seems to be copy&pasting from DTS
files available in the repository today, so let's unify that naming
there as well and provide proper examples.

While at it, remove unused m25p80 label.

Tested on rt5350 (for spi-nor) and rt3662 (for cfi-flash).

1. https://openwrt.org/submitting-patches#dts_checklist
2. https://github.com/devicetree-org/devicetree-specification/blob/master/source/devicetree-basics.rst#generic-names-recommendation



Signed-off-by: Sungbo Eo <mans0n@gorani.run>

Spelling of Zbtlink varies across image definitions and DTS files.

This patch uses Zbtlink consistently and also updates the model
in DTS files to contain the vendor in all cases.

This patch is cosmetical, as there should be no dependencies on
device model name in ramips anymore.

Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>

As introduced with ath79, DTS files for ramips will now be labelled
soc_vendor_device.dts(i). With this change, DTS files can be
selected automatically without further manual links.

Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>

Specify firmware partition format by compatible string.

formats in ramips:

- denx,uimage
- tplink,firmware
- seama

It's unlikely but the firmware splitting might not work any longer for
the following boards, due to a custom header:

- EX2700: two uImage headers
- BR-6478AC-V2: edimax-header
- 3G-6200N: edimax-header
- 3G-6200NL: edimax-header
- BR-6475ND: edimax-header
- TEW-638APB-V2: umedia-header
- RT-N56U: mkrtn56uimg

But it rather looks like the uImage splitter is fine with the extra
header.

The following dts are not touched, due to lack of a compatible string in
the matching firmware splitter submodule:

- CONFIG_MTD_SPLIT_JIMAGE_FW
    DWR-116-A1.dts
    DWR-118-A2.dts
    DWR-512-B.dts
    DWR-921-C1.dts
    LR-25G001.dts
- CONFIG_MTD_SPLIT_TRX_FW
    WCR-1166DS.dts
    WSR-1166.dts
- CONFIG_MTD_SPLIT_MINOR_FW
    RBM11G.dts
    RBM33G.dts
- CONFIG_MTD_SPLIT_LZMA_FW
    AR670W.dts
- CONFIG_MTD_SPLIT_WRGG_FW
    DAP-1522-A1.dts

Signed-off-by: INAGAKI Hiroshi <musashino.open@gmail.com>

Starting with kernel 4.4, the use of partitions as direct subnodes of the
mtd device is discouraged and only supported for backward compatiblity
reasons.

Signed-off-by: Alex Maclean <monkeh@monkeh.net>

Use the GPIO dt-bindings macros and add compatible strings in the
ramips device tree source files.

Signed-off-by: L. D. Pinney <ldpinney@gmail.com>
Signed-off-by: Mathias Kresin <dev@kresin.me>

Fix a copy/paste error and include the ZBT-WE826 dtsi instead of the
ZBT-WG3526 one.

Fix the syntax error in the ZBT-WE826 dtsi to prevent an compile error.

Signed-off-by: Mathias Kresin <dev@kresin.me>

The ZBT-WG826 is available with 16 or 32 MByte of flash. Split the
device tree source file, rename the currently supported 16 MByte
version and add the 32 MByte variant.

Signed-off-by: Mathias Kresin <dev@kresin.me>