mtk-20170518/target/linux/ramips, branch v18.06.1

ramips: add missing USB packages into ASL26555-16M

2018-08-13T13:10:30+00:00

Mirror the package list from the 8M device profile to the
16M device profile.

Signed-off-by: Zoltan HERPAI

Revert "mt7620: gsw: make IntPHY and ExtPHY share mdio addr 4 possible"

2018-08-06T17:54:19+00:00

This reverts commit b40316c21a960d332bc9b04ee1791b8aafcf8786.

That change causes ramips/mt7620 to fail with:

    drivers/net/ethernet/mtk/gsw_mt7620.c: In function 'mt7620_hw_init':
    drivers/net/ethernet/mtk/gsw_mt7620.c:171:14: error: 'mdio_mode' undeclared (first use in this function); did you mean 'd_move'?
      } else if (!mdio_mode) {
                  ^~~~~~~~~
                  d_move

Back it out for now to restore compilation.

Signed-off-by: Jo-Philipp Wich

mt7620: gsw: make IntPHY and ExtPHY share mdio addr 4 possible

2018-08-06T07:15:09+00:00

To share mdio addr for IntPHY and ExtPHY,
as described in the documentation (MT7620_ProgrammingGuide.pdf).
(refer: http://download.villagetelco.org/hardware/MT7620/MT7620_ProgrammingGuide.pdf)

when port4 setup to work as gmac mode, dts like:

&gsw {
    mediatek,port4 = "gmac";
};

we should set SYSCFG1.GE2_MODE==0x0 (RGMII).
but SYSCFG1.GE2_MODE may have been set to 3(RJ-45) by uboot/default
so we need to re-set it to 0x0

before this changes:
gsw: 4FE + 2GE may not work correctly and MDIO addr 4 cannot be used by ExtPHY

after this changes:
gsw: 4FE + 2GE works and MDIO addr 4 can be used by ExtPHY

Signed-off-by: Chen Minqiang 
(cherry picked from commit f6d81e2fa1f110d8025eaa434d67d0014aca1d42)

ramips: fix gigabit switch PHY access on MDIO

2018-08-06T07:15:09+00:00

When PHY's are defined on the MDIO bus in the DTS, gigabit support was
being masked out for no apparent reason, pegging all such ports to 10/100.
If gigabit support must be disabled for some reason, there should be a
"max-speed" property in the DTS.

Reported-by: James McKenzie 
Signed-off-by: Daniel Gimpelevich 
(cherry picked from commit 379fe506729a20c5fdb072840cb662b032e90c36)

kernel: bump 4.14 to 4.14.60 for 18.06

2018-08-06T05:30:41+00:00

* Refreshed patches.
* Patches made redundant by changes upstream:
  - target/linux/ramips/patches-4.14/0036-mtd-fix-cfi-cmdset-0002-erase-status-check.patch
* Patches accepted upstream:
  - target/linux/apm821xx/patches-4.14/020-0001-crypto-crypto4xx-remove-bad-list_del.patch
  - target/linux/apm821xx/patches-4.14/020-0011-crypto-crypto4xx-fix-crypto4xx_build_pdr-crypto4xx_b.patch
  - target/linux/brcm63xx/patches-4.14/001-4.15-08-bcm63xx_enet-correct-clock-usage.patch
  - target/linux/brcm63xx/patches-4.14/001-4.15-09-bcm63xx_enet-do-not-write-to-random-DMA-channel-on-B.patch
  - target/linux/generic/backport-4.14/080-net-convert-sock.sk_wmem_alloc-from-atomic_t-to-refc.patch
  - target/linux/generic/pending-4.14/900-gen_stats-fix-netlink-stats-padding.patch

The ext4 regression introduced in 4.14.55 has been fixed by 4.14.60 (commit f547aa20b4f61662ad3e1a2040bb3cc5778f19b0).

Fixes the following CVEs:
- CVE-2018-10876
- CVE-2018-10877
- CVE-2018-10879
- CVE-2018-10880
- CVE-2018-10881
- CVE-2018-10882
- CVE-2018-10883

Thanks to Stijn Tintel for the CVE list :-).

Compile-tested on: ramips/mt7621, x86/64
Run-tested on: ramips/mt7621, x86/64

Signed-off-by: Stijn Segers

ramips: clean up and fix MT7621 NAND driver issues

2018-07-13T15:01:41+00:00

- remove misaligned custom buffer allocation in the NAND driver
- remove broken bounce buffer implementation for 16-byte align

Let the MTD core take care of both

Fixes messages like these:
[  102.820541] Data buffer not 16 bytes aligned: 87daf08c

Signed-off-by: Felix Fietkau

ramips: ethernet: use own page_frag_cache

2018-07-13T14:39:49+00:00

Using the NAPI or netdev frag cache along with other drivers can lead to
32 KiB pages being held for a long time, despite only being used for
very few page fragment.
This can happen if the ethernet driver grabs one or two fragments for rx
ring refill, while other drivers use (and free up) the remaining
fragments. The 32 KiB higher-order page can only be freed once all users
have freed their fragments, which only happens after the rings of all
drivers holding the fragments have wrapped around.

Depending on the traffic patterns, this can waste a lot of memory and
look a lot like a memory leak

Signed-off-by: Felix Fietkau

ramips: ethernet: use skb_free_frag to free fragments

2018-07-13T14:39:46+00:00

Signed-off-by: Felix Fietkau

ramips: TP-Link TL-WR902AC v3: add missing wps button

2018-07-12T16:27:36+00:00

Signed-off-by: Peter Lundkvist

ramips: TP-Link TL-WR902AC v3: don't build factory image

2018-07-12T16:27:36+00:00

The line that produces factory image was accidentally left by me while
testing before inital commit.

I came to the conclusion that flashing from OEM firmware does not work
(seems to share this behavior with other tplinks based on mt7628).

I have not done any further analysis, as I was unable to open the
case and attach a serial port (too much glue). Maybe i will try once
more.

So the way to do initial flashing (or un-bricking) is to use the
tftp-recover image. It is possible to revert to OEM firmware with tftp
recovery; in this case the first 512 bytes the image file need to be
cut off.

Signed-off-by: Peter Lundkvist 
[add explaination provided via mail as commit message]
Signed-off-by: Mathias Kresin