Replace an old cleanup patch that never made it upstream with the proper
upstream fix. This patch was incompatible with the recent changes that
affected the way that the flow tuple dst entry was used.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
If an spi-gpio was specified with num-chipselects = <0> in dts, kernel
will crash:
Unable to handle kernel paging request at virtual address 32697073
pgd = (ptrval)
[32697073] *pgd=00000000
Internal error: Oops: 5 [# 1] SMP ARM
Modules linked in:
CPU: 2 PID: 1 Comm: swapper/0 Not tainted 4.19.72 #0
Hardware name: Generic DT based system
PC is at validate_desc+0x28/0x80
LR is at gpiod_direction_output+0x14/0x128
...
[<c0544db4>] (validate_desc) from [<c0545228>] (gpiod_direction_output+0x14/0x128)
[<c0545228>] (gpiod_direction_output) from [<c05fa714>] (spi_gpio_setup+0x58/0x64)
[<c05fa714>] (spi_gpio_setup) from [<c05f7258>] (spi_setup+0x12c/0x148)
[<c05f7258>] (spi_setup) from [<c05f7330>] (spi_add_device+0xbc/0x12c)
[<c05f7330>] (spi_add_device) from [<c05f7f74>] (spi_register_controller+0x838/0x924)
[<c05f7f74>] (spi_register_controller) from [<c05fa494>] (spi_bitbang_start+0x108/0x120)
[<c05fa494>] (spi_bitbang_start) from [<c05faa34>] (spi_gpio_probe+0x314/0x338)
[<c05faa34>] (spi_gpio_probe) from [<c05a844c>] (platform_drv_probe+0x34/0x70)
The cause is spi_gpio_setup() did not check if the spi-gpio has
chipselect pins before setting their direction and results in derefing
an invalid pointer.
The bug is spotted in kernel 4.19.72 and does not occur in 4.14.
There is a similar fix upstream in kernel 5.2 in commit 249e2632dcd0
("spi: gpio: Don't request CS GPIO in DT use-case").
Ref: https://patchwork.kernel.org/patch/11150619/
Signed-off-by: DENG Qingfang <dengqf6@mail2.sysu.edu.cn>
[use upstream patch, moved from hack to pending dir, commit facelift]
Signed-off-by: Petr Štetiar <ynezz@true.cz>
Move the IRQ fix from generic to ar71xx specific.
Other targets like ath79 have specific pathes to delete this code.
This resulted in a build failure on ath79
While at it, wipe the 4.19 version, as ar71xx will never reach this.
Fixes: 530f76708cef ("ar71xx: Fix potentially missed IRQ handling during
dispatch")
Signed-off-by: Koen Vandeputte <koen.vandeputte@ncentric.com>
If both interrupts are set in the current implementation
only the 1st will be handled and the 2nd will be skipped
due to the "if else" condition.
Fix this by using the same approach as done for QCA955x
just below it.
Signed-off-by: Koen Vandeputte <koen.vandeputte@ncentric.com>
The net pointer in struct xt_tgdtor_param is not explicitly
initialized therefore is still NULL when dereferencing it.
So we have to find a way to pass the correct net pointer to
ipt_destroy_target().
The best way I find is just saving the net pointer inside the per
netns struct tcf_idrinfo, which could make this patch smaller.
Fixes: 0c66dc1ea3f0 ("netfilter: conntrack: register hooks in netns when needed by ruleset")
Reported-and-tested-by: Tony Ambardar <itugrok@xxxxxxxxx>
Cc: Jamal Hadi Salim <jhs@xxxxxxxxxxxx>
Cc: Jiri Pirko <jiri@xxxxxxxxxxx>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
[Backport for kernel v4.19 and v4.14]
[Bug Link: https://bugzilla.kernel.org/show_bug.cgi?id=204681]
Signed-off-by: Tony Ambardar <itugrok@yahoo.com>
We are not sure if 640-bridge-only-accept-EAP-locally.patch is still needed
as a first step, add disable_eap_hack sysfs config to allow to disable it
Signed-off-by: Etienne Champetier <champetier.etienne@gmail.com>
Refreshed all patches.
Also add a missing symbol for x86 which got used now in this bump.
- ISCSI_IBFT
Compile-tested on: cns3xxx
Runtime-tested on: cns3xxx
Signed-off-by: Koen Vandeputte <koen.vandeputte@ncentric.com>
Refreshed all patches.
Also add a missing symbol for x86 which got used now in this bump.
- ISCSI_IBFT
Compile-tested on: cns3xxx
Runtime-tested on: cns3xxx
Signed-off-by: Koen Vandeputte <koen.vandeputte@ncentric.com>
Revert "mac80211: add new minstrel_ht patches to improve probing on mt76x2" (9861050b85)
Revert "kernel: use bulk free in kfree_skb_list to improve performance" (98b654de2e)
Revert "ramips: add preliminary support for WIO ONE" (085141dc5b)
Revert "ramips: add preliminary support for SGE AP-MTKH7-0006 developer board" (b1db6d0539)
Revert "build: use config.site generated by autoconf-lean, drop hardcoded sitefiles" (363ce4329d)
Revert "toolchain: add autoconf-lean" (fdb30eed03)
Revert "build: allow overriding the filename on the remote server when downloading" (6fa0e07758)
Signed-off-by: Felix Fietkau <nbd@nbd.name>
This adds support for uImage used by OpenWrt kernel loader.
The parser searches for uImage header at flash eraseblock boundary
and it might attempt to split any firmware with loader, therefore
this entry doesn't have MTD_PARSER_TYPE_FIRMWARE so that this parser
is only used when explicitly defined in dts.
Signed-off-by: Chuanhong Guo <gch981213@gmail.com>
This parser's matching function appears to be too generic as it matches
e.g. Buffalo WZR-HP-G300NH. That results in incorrect parts parsing.
Luckily this parser is needed by Fon FON2601 only which uses DT-based
ramips target. It means we can depend on mtd subsystem matching of
"fonfxc,uimage" string.
That said triggering this parser based on the "firmware" (or whatever
MTD_SPLIT_FIRMWARE_NAME is) partiiton name is not needed. It can be
dropped which will automatically fix the Buffalo WZR-HP-G300NH case.
Fixes: a1c6a316d2 ("ramips: add support for Fon FON2601")
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
This reverts commit e92a14709d.
mtdsplit_uimage_parse_fonfxc() gets called in two situations:
1) It was /requested/ from DT using "fonfxc,uimage" compatible string
2) It was called by parsing code after finding "firmware"
(MTD_SPLIT_FIRMWARE_NAME) due to the parser's type
Code added in the /fix/ commit basically just disabled the second case.
If that's the real goal it could be achieved by simply dropping type
MTD_PARSER_TYPE_FIRMWARE. It may however require another solution as
it's possible that some non-DT target actually needs fonfxc uImage
parsing.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
This is already enabled as kernel built-in feature in mvebu target and
none other target will use it.
Signed-off-by: Tomasz Maciej Nowak <tomek_n@o2.pl>
We cannot distinguish between fonfxc uImage and generic uImage because
fonfxc uImage header is almost same as generic uImage, except padding
length after image name.
The fonfxc uImage parser is available when specifying directly with DT
compatible property. So this patch adds check if the partition DT node
is compatible with the parser.
Ref: https://bugs.openwrt.org/index.php?do=details&task_id=2413
Fixes: a1c6a316d2 ("ramips: add support for Fon FON2601")
Signed-off-by: NOGUCHI Hiroshi <drvlabo@gmail.com>
[commit light touches and removed C code comment]
Signed-off-by: Petr Štetiar <ynezz@true.cz>
