Re: [RFC PATCH] openssl: make the patches QUILT-friendly
> On 27 Mar 2021, at 00:41, Eneas U de Queiroz wrote: > > On Fri, Mar 26, 2021 at 7:35 PM Kevin 'ldir' Darbyshire-Bryant > wrote: >> >> ... I was also frustrated that there was patch fuzz in the tree on a fairly >> core package - that really shouldn’t be the case. > > My apologies. I work in a clone of the openssl git repo, rebasing the > changes on top of the current version. I always look at the diffs > before sending the patch to openwrt. If they were just line changes, > I wouldn't bother to touch the patch, in order to minimize changes. > I'll revise my approach and change the files no matter what. Thanks for that and I understand your workflow. I’ve a similar thing when I play with dnsmasq updates :-) As a pedantic note, please check your quiltrc settings as per https://openwrt.org/docs/guide-developer/build-system/use-patches-with-buildsystem ‘cos the ‘refresh,update’ output you attached still contains index info which is usually stripped. Thanks for all your work on openssl - I don’t understand it but know it’s important :-) Kevin signature.asc Description: Message signed with OpenPGP ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [RFC PATCH] openssl: make the patches QUILT-friendly
> On 26 Mar 2021, at 18:55, Eneas U de Queiroz wrote:
>
> The patches in this package are all made by git format-patches. If one
> were to run 'make package/openssl/{refresh,update}', then things will
> not work as expected, because quilt QUILT does not deal well with
> patches that rename files. For openssl, the problematic patch is
> 430-e_devcrypto-make-the-dev-crypto-engine-dynamic.patch.
>
> So, I've generated a new patch with 'git format-patch --no-renames', and
> then 'make package/openssl/{refresh,update}'.
>
> Signed-off-by: Eneas U de Queiroz
> ---
>
> While I really prefer to leave the git-formatted patches as they are, I
> know quilt is the preferred way of handling patches in OpenWRT, so I'm
> presenting this as RFC, so the core developers can decide.
>
> ldir has made a similar commit e27ef2da0d, and then reverted it right away
> in bbb9c1c2be, and I don't know why.
I was trying to do my own 1.1.1k bump which ended badly. I was also frustrated
that there was patch fuzz in the tree on a fairly core package - that really
shouldn’t be the case. So I resolved to fix that and push it before
understanding the full implications of the file rename stuff going on. I
reverted on the basis I was in far too deep.
signature.asc
Description: Message signed with OpenPGP
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] kernel: bump 5.4 to 5.4.47
> On 18 Jun 2020, at 08:58, Koen Vandeputte > wrote: > > > On 18.06.20 08:50, Kevin Darbyshire-Bryant wrote: >> Refreshed patches. >> >> Run tested: x86/64 (apu2) >> >> Signed-off-by: Kevin Darbyshire-Bryant >> --- > > > I've got the bumps in my staging already sinds a day or 2 :-) > AFAIUI 5.4.47 was release 17 hours ago, a few hours after ynezz committed 5.4.46 - I think. signature.asc Description: Message signed with OpenPGP ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Do not hard-code IS_TTY in script scripts/feeds
> From: "R. Diez" > Subject: Re: [OpenWrt-Devel] [PATCH] Do not hard-code IS_TTY in script > scripts/feeds > Date: 6 June 2020 at 13:44:11 BST > To: Petr Štetiar > Cc: openwrt-devel@lists.openwrt.org > > > >> https://openwrt.org/submitting-patches#no_mime_no_links_no_compression_no_attachments_just_plain_text > > Sometimes I use Thunderbird, and sometimes I use the Yahoo web interface. > Both have problems with e-mail formatting, as they tend to reflow text lines > and mess with quotations and blanks. Sending patches as plain text inside > e-mails is too much trouble for me. > > I do not understand why Patchwork cannot automatically pick up a patch from > an e-mail attachment aptly named xxx.patch, and with an e-mail title that > starts with [PATCH]. > > Is it possible to add patches manually to Patchwork using its web interface? > If so, I would try that way. > > Otherwise, I am tempted to drop it (and other such further contributions I > had in the pipeline). This is a trivial fix and the administrative cost of > getting it right is clearly disproportionate. I recognise the frustration! When I first started trying to send patches I had similar issues (white space wrapping/reflow etc) The same issues are encountered when sending to many open source email patch lists including the Linux kernel. I came very, very, very close to giving up with openwrt, before being introduced to ‘git send-email’. I fought a little with configuring git send-email and got it working, before I then discovered https://www.freedesktop.org/wiki/Software/PulseAudio/HowToUseGitSendEmail/ which is a quite helpful guide. Maybe that can help you too? Kevin ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Sysupgrade and Failed to kill all processes
> On 13 May 2020, at 09:57, Jo-Philipp Wich wrote: > > Hi, > >> >>That loop-kill-all thing should be a kind of last resort really, what's >>actually needed is some kind of "init 1" procd equivalent which shuts >> down all >>services in a more or less clean manner. >> Beware the watchdog Luke. Kevin ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH fstools] block: fix segfault triggered by non-autofs mounts
> On 12 May 2020, at 06:54, Rafał Miłecki wrote:
>
> On 2020-05-12 01:45, Daniel Golle wrote:
>> Program received signal SIGSEGV, Segmentation fault.
>> main_autofs (argv=, argc=)
>>at fstools-2020-05-06-eec16e2f/block.c:1193
>> 1193:if (!m->autofs && (mp = find_mount_point(pr->dev))) {
>> Fixes: 9ab936d ("block(d): always call hotplug.d "mount" scripts from
>> blockd")
>> Signed-off-by: Daniel Golle
>
> Thanks! Please push it asap!
Fixes for me.
Acked-by: Kevin Darbyshire-Bryant
Cheers,
Kevin D-B
gpg: 012C ACB2 28C6 C53E 9775 9123 B3A2 389B 9DE2 334A
signature.asc
Description: Message signed with OpenPGP
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCHv3] ubox: run init script through shellcheck
> On 18 Apr 2020, at 01:56, Rosen Penev wrote: > > On Fri, Apr 17, 2020 at 1:50 AM wrote: >> >>> >>> - [ $log_buffer_size -eq 0 -a $log_size -gt 0 ] && >>> log_buffer_size=$log_size >>> - [ $log_buffer_size -eq 0 ] && log_buffer_size=64 >>> + [ "$log_buffer_size" -eq 0 ] && [ "$log_size" -gt 0 ] && >> >> I'm never sure whether a comparison [ "$string" -eq 0 ], i.e. one with >> quotes and one without using -eq works as expected in all cases. >> I typically use [ "$string" = "0" ] instead, but I'm not sure whether that's >> effectively just the same. > Sounds bogus. log_buffer_size and log_size are stated to be uintegers above. >> >> Rest seems fine, despite some similar cases with -eq/-ne below. > -eq/-ne vs = is a stylistic difference. I disagree. ‘= != < >’ are string comparisons, -eq/-ne/gt/lt/ge/le are numeric/arithmetic comparisons. Consider this slightly contrived case where to emphasise the difference between string and numeric comparison I compare to ’00’ which is arithmetically zero, but not just a simple, lone ‘0’ string. #!/bin/sh set -x [ "$foo" -eq 00 ] && echo Z [ "$foo" = 00 ] && echo Z [ $foo -eq 00 ] && echo Z [ $foo = 00 ] && echo Z foo=“0" [ "$foo" -eq 00 ] && echo Z [ "$foo" = 00 ] && echo Z [ $foo -eq 00 ] && echo Z [ $foo = 00 ] && echo Z foo=0 [ "$foo" -eq 00 ] && echo Z [ "$foo" = 00 ] && echo Z [ $foo -eq 00 ] && echo Z [ $foo = 00 ] && echo Z The unquoted expansions of $foo in the first block will lead to unknown operand errors since $foo expands to nothing. The quoted $foo in the first block will lead to ’sh: out of range’ because “” is not an integer suitable for the integer -eq comparison. A solution: [ "$foo" ] && [ "$foo" -eq 00 ] && echo Z In later blocks, because $foo is now set it always expands to something so there’s no difference between quoted vs unquoted behaviour (in this example!) we’re just into the differences between string vs numeric value comparisons, ie. string ‘0’ is not equal to ’00’ but value ‘0’ is equal to ’00' Maybe that helps. signature.asc Description: Message signed with OpenPGP ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v1 1/2] kmod-sched-cake: rename to kmod-sched-cake-oot
> On 1 Apr 2020, at 18:07, Hannu Nyman wrote:
>
> Kevin Darbyshire-Bryant kirjoitti 1.4.2020 klo 13.14:
>> In preparation for dropping the out of tree cake module and using
>> in tree cake from upstream, rename the package to kmod-sched-cake-oot
>> (out of tree)
>>
>> Initially add a PROVIDES kmod-sched-cake so that package dependencies
>> can be satisfied.
>>
>> Ultimately this package will be removed when linux 4.14 is removed.
>>
>> Signed-off-by: Kevin Darbyshire-Bryant
>> ---
>> .../Makefile| 13 +++--
>> 1 file changed, 7 insertions(+), 6 deletions(-)
>> rename package/kernel/{kmod-sched-cake => kmod-sched-cake-oot}/Makefile
>> (75%)
>>
>> diff --git a/package/kernel/kmod-sched-cake/Makefile
>> b/package/kernel/kmod-sched-cake-oot/Makefile
>> similarity index 75%
>> rename from package/kernel/kmod-sched-cake/Makefile
>> rename to package/kernel/kmod-sched-cake-oot/Makefile
>> index 42e45b5789..fbcb9cec4b 100644
>> --- a/package/kernel/kmod-sched-cake/Makefile
>> +++ b/package/kernel/kmod-sched-cake-oot/Makefile
>> @@ -8,7 +8,7 @@
>> include $(TOPDIR)/rules.mk
>> include $(INCLUDE_DIR)/kernel.mk
>> -PKG_NAME:=sched-cake
>> +PKG_NAME:=sched-cake-oot
>> PKG_RELEASE:=1
>>PKG_SOURCE_PROTO:=git
>> @@ -20,23 +20,24 @@ PKG_MAINTAINER:=Kevin Darbyshire-Bryant
>>
>>include $(INCLUDE_DIR)/package.mk
>> -define KernelPackage/sched-cake
>> +define KernelPackage/sched-cake-oot
>>SUBMENU:=Network Support
>> - TITLE:=Cake fq_codel/blue derived shaper
>> + TITLE:=OOT Cake fq_codel/blue derived shaper
>>URL:=https://github.com/dtaht/sch_cake
>>FILES:=$(PKG_BUILD_DIR)/sch_cake.ko
>>AUTOLOAD:=$(call AutoLoad,75,sch_cake)
>> - DEPENDS:=+kmod-ipt-conntrack
>> + DEPENDS:=+kmod-sched-core
>> + PROVIDES:=kmod-sched-cake
>> endef
>>
>
> I tried to compile kmod-sched-cake-oot for ar71xx with kernel 4.14, and it
> failed due to dependency error:
>
> Package kmod-sched-cake-oot is missing dependencies for the following
> libraries:
> nf_conntrack.ko
> make[3]: *** [Makefile:52:
> /Openwrt/wndr3700/bin/targets/ar71xx/generic/packages/kmod-sched-cake-oot_4.14.172+2020-01-10-aeff7a3e-1_mips_24kc.ipk]
> Error 1
> make[3]: Leaving directory
> '/Openwrt/wndr3700/package/kernel/kmod-sched-cake-oot'
>
> The old (out-of-tree) package had dependency for kmod-ipt-conntrack that was
> now replaced by sched-core, but that is apparently not enough?
> (kmod-ipt-conntrack selects kmod-nf-conntrack)
Ooops! - Yes it also needs +kmod-ipt-conntrack, I’ll amend and resend soon.
Currently can’t get a build out of my mac due to the grub2 efi bump, so
battling other issues.
Thanks for testing.
Cheers,
Kevin
signature.asc
Description: Message signed with OpenPGP
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Strongswan compile fails since connmark related commits in OpenWrt
Hi Sebastian,
I’ve just done a fix for this. Just waiting for a build to complete before I
push it.
In essence, the kernel hack patches for 4.19 were copied to 5.4. The patch in
4.19 was fixed but the one in 5.4 got forgotten about, since no one was
actually building with a 5.4 kernel till now.
What I really don’t understand as the author of the patch is quite how the old
header syntax still exists, since the version of patches I sent upstream has
the fix….and in theory I backported those updates to openwrt.
If you can’t wait then tweak
hack-5.4/645-netfilter-connmark-introduce-set-dscpmark.patch:
diff --git
a/target/linux/generic/hack-5.4/645-netfilter-connmark-introduce-set-dscpmark.patch
b/target/linux/generic/hack-5.4/645-netfilter-connmark-introduce-set-dscpmark.patch
index f5ca1bef6e..2d3fe01a75 100644
---
a/target/linux/generic/hack-5.4/645-netfilter-connmark-introduce-set-dscpmark.patch
+++
b/target/linux/generic/hack-5.4/645-netfilter-connmark-introduce-set-dscpmark.patch
@@ -87,8 +87,8 @@ Signed-off-by: Kevin Darbyshire-Bryant
};
enum {
-+ XT_CONNMARK_VALUE = BIT(0),
-+ XT_CONNMARK_DSCP = BIT(1)
++ XT_CONNMARK_VALUE = (1 << 0),
++ XT_CONNMARK_DSCP = (1 << 1)
+};
+
+enum {
Apologies for the inconvenience.
Kevin
> On 21 Mar 2020, at 09:13, Sebastian Kemper wrote:
>
> Hi all,
>
> strongswan fails to compile since many weeks:
>
> In file included from
> /builder/shared-workdir/build/sdk/staging_dir/toolchain-aarch64_cortex-a53_gcc-8.4.0_musl/include/linux/netfilter/xt_CONNMARK.h:5,
> from connmark_listener.c:30:
> /builder/shared-workdir/build/sdk/staging_dir/toolchain-aarch64_cortex-a53_gcc-8.4.0_musl/include/linux/netfilter/xt_connmark.h:23:2:
> error: enumerator value for 'XT_CONNMARK_VALUE' is not an integer constant
> XT_CONNMARK_VALUE = BIT(0),
> ^
> /builder/shared-workdir/build/sdk/staging_dir/toolchain-aarch64_cortex-a53_gcc-8.4.0_musl/include/linux/netfilter/xt_connmark.h:25:1:
> error: enumerator value for 'XT_CONNMARK_DSCP' is not an integer constant
> };
> ^
>
> Full log example:
>
> https://downloads.openwrt.org/snapshots/faillogs/aarch64_cortex-a53/packages/strongswan/compile.txt
>
> I think that this build failure is related to one of the following commits:
>
> https://github.com/openwrt/openwrt/commit/e481df07fa6599e18a0570acb4dadabc56299b7b
> https://github.com/openwrt/openwrt/commit/a1cfe0dcbb242ab440af6801e223ebde540ed90f
>
> (probably the second one)
>
> Maybe anybody can take a look at this?
>
> If you want me to raise an issue in Flyspray let me know.
>
> Kind regards,
> Seb
Cheers,
Kevin D-B
gpg: 012C ACB2 28C6 C53E 9775 9123 B3A2 389B 9DE2 334A
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 1/2] base-files: make USE_PROCD=1 default
> On 2 Aug 2019, at 16:00, Hannu Nyman wrote: > > Hauke Mehrtens kirjoitti 2.8.2019 klo 17.42: >> On 7/23/19 3:37 PM, Petr Štetiar wrote: >>> Transition period for init script migration was long enough, let's >>> make USE_PROCD=1 default now so there's enough time to convert the >>> remaining services/init scripts for the next release. >>> >>> Signed-off-by: Petr Štetiar >>> --- >>> package/base-files/files/etc/rc.common | 113 ++--- >>> 1 file changed, 47 insertions(+), 66 deletions(-) >>> >> Do you know how many packages in the package feed and the main >> repository are still not using procd? >> >> External repositories, not the package feed, will probably be affected >> most, but I think we do not have to care and there were many years to >> convert. >> >> Acked-by: Hauke Mehrtens >> >> Hauke >> > > I do not remember seeing ever a general call for converting the old packages > to using procd. In that sense this proposed change to switch the default > comes a bit surpise. > > Quick search in the packages feed repo reveals that there are 281 instances > of "/etc/rc.common" and only 205 instances of USE_PROCD. So, likely about 75 > packages in the packages feed repo only are using the old syntax without > procd. > > Has a decision been made to declare the old-style init file invalid? Will it > be possible to still use the syntax? What is the new "override" to indicate > the usage of the old syntax? > > Or will the proposed change disable the packages using the old init file > syntax totally? My reading of the change is that old syntax is basically dropped. Wish for: We should be using procd and to that end I started looking at converting the ‘important to me’ packages: ddns & miniupnpd. Real life: Documentation is confusing vs real life which is just plain different. See adblock startup script as an excellent example of that just isn’t documented. I gave up and left the process feeling very angry. KDB signature.asc Description: Message signed with OpenPGP ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Merged: rb532: Fix missing DEVICE_TITLE
> On 9 Jul 2019, at 21:23, m...@adrianschmutzler.de wrote: > >> -Original Message- >> From: Darbyshire-Bryant, Kevin [mailto:ke...@darbyshire-bryant.me.uk] On >> Behalf Of Kevin Darbyshire-Bryant >> Sent: Dienstag, 9. Juli 2019 21:09 >> To: openwrt-devel@lists.openwrt.org >> Cc: Adrian Schmutzler ; Kevin Darbyshire- >> Bryant >> Subject: Merged: rb532: Fix missing DEVICE_TITLE >> >> Merged into my staging tree. >> Thank you! > > Does this require backporting to 19.07? The warnings do not occur there > (seems to be interference with some other changes in master), but > DEVICE_TITLE is not set on 19.07 either. I don’t think so, or it doesn’t generate the warnings at least. I suspect related to one or more of 0096a1cf00 scripts/config: fix *c_shipped build depency tracking 75dcaf3d23 config: fix relational operators for bool and tristate symbols 972123f1e0 config: regenerate *_shipped sources Kevin signature.asc Description: Message signed with OpenPGP ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] ath10k-ct crash Archer C7 v2 - OpenWrt r10307-629e6538a1 - k4.19
Unfortunately flyspray won’t let me create a task, so filing this here so it doesn’t get lost. Archer C7 v2 - OpenWrt r10307-629e6538a1 - k4.19 Recently seen the following firmware crashes on the device. Seems to be related to my macbook coming out of power save mode. There's been a recent ath10k-ct firmware bump so unclear if this is a wireless firmware bug or a kernel driver bug, or both. Maybe the crashlog holds a clue. [76300.806621] ath10k_pci :00:00.0: firmware crashed! (guid n/a) [76300.812839] ath10k_pci :00:00.0: qca988x hw2.0 target 0x4100016c chip_id 0x043202ff sub : [76300.822239] ath10k_pci :00:00.0: kconfig debug 0 debugfs 1 tracing 0 dfs 1 testmode 0 [76300.834379] ath10k_pci :00:00.0: firmware ver 10.1-ct-8x-__fH-022-8f2afb9e api 2 features wmi-10.x,mfp,txstatus-noack,wmi-10.x-CT,ratemask-CT,regdump-CT,txrate-CT,flush-all-CT,pingpong-CT,ch-regs-CT,nop-CT,set-special-CT,get-temp-CT,tx-rc-CT,cust-stats-CT,retry-gt2-CT,txrate2-CT,beacon-cb-CT,wmi-block-ack-CT crc32 98d412c4 [76300.863764] ath10k_pci :00:00.0: board_file api 1 bmi_id N/A crc32 bebc7c08 [76300.871195] ath10k_pci :00:00.0: htt-ver 2.2 wmi-op 2 htt-op 2 cal file max-sta 128 raw 0 hwcrypto 1 [76300.882843] ath10k_pci :00:00.0: firmware register dump: [76300.888598] ath10k_pci :00:00.0: [00]: 0x4100016C 0x 0x009963E5 0x [76300.896637] ath10k_pci :00:00.0: [04]: 0x 0x00060324 0x 0x [76300.904670] ath10k_pci :00:00.0: [08]: 0x 0x 0x 0x [76300.912706] ath10k_pci :00:00.0: [12]: 0x0005 0x 0x 0x [76300.920750] ath10k_pci :00:00.0: [16]: 0x009B8BAB 0x0094085D 0x 0x009963E5 [76300.928793] ath10k_pci :00:00.0: [20]: 0x809430B8 0x00401A40 0x0001 0x0002 [76300.936837] ath10k_pci :00:00.0: [24]: 0x80940975 0x00401A60 0x001F 0x00403BEC [76300.944869] ath10k_pci :00:00.0: [28]: 0x409406B9 0x00401A80 0x001F 0x000F [76300.952905] ath10k_pci :00:00.0: [32]: 0x 0x00401AA0 0x00050024 0x0403 [76300.960953] ath10k_pci :00:00.0: [36]: 0x 0x 0x 0x [76300.968991] ath10k_pci :00:00.0: [40]: 0x 0x 0x 0x [76300.977034] ath10k_pci :00:00.0: [44]: 0x 0x 0x 0x [76300.985066] ath10k_pci :00:00.0: [48]: 0x 0x 0x 0x [76300.993103] ath10k_pci :00:00.0: [52]: 0x 0x 0x 0x [76301.001146] ath10k_pci :00:00.0: [56]: 0x 0x 0x 0x [76301.009186] ath10k_pci :00:00.0: Copy Engine register dump: [76301.015196] ath10k_pci :00:00.0: [00]: 0x00057400 14 14 3 3 [76301.021745] ath10k_pci :00:00.0: [01]: 0x00057800 20 20 54 55 [76301.028291] ath10k_pci :00:00.0: [02]: 0x00057c00 21 21 84 85 [76301.034826] ath10k_pci :00:00.0: [03]: 0x00058000 28 28 30 28 [76301.041378] ath10k_pci :00:00.0: [04]: 0x00058400 5087 5087 25 241 [76301.048100] ath10k_pci :00:00.0: [05]: 0x00058800 6 6 101 102 [76301.054636] ath10k_pci :00:00.0: [06]: 0x00058c00 22 22 22 22 [76301.061186] ath10k_pci :00:00.0: [07]: 0x00059000 0 0 0 0 [76301.069742] ath10k_pci :00:00.0: debug log header, dbuf: 0x412708 dropped: 0 [76301.078358] ath10k_pci :00:00.0: [0] next: 0x412720 buf: 0x41056c sz: 1500 len: 52 count: 2 free: 0 [76301.088905] ath10k_pci :00:00.0: ath10k_pci ATH10K_DBG_BUFFER: [76301.095175] ath10k: []: 184AA804 0600FC13 1091 0808 184AA804 0100FC17 [76301.104362] ath10k: [0008]: 30194000 6C010041 [76301.68] ath10k_pci :00:00.0: ATH10K_END [76301.116785] ath10k_pci :00:00.0: [1] next: 0x412708 buf: 0x410b5c sz: 1500 len: 0 count: 0 free: 0 [76301.129238] ath10k_pci :00:00.0: removing peer, cleanup-all, deleting: peer 1e425dff vdev: 0 addr: 8c:85:90:36:ea:10 [76301.140415] ath10k_pci :00:00.0: removing peer, cleanup-all, deleting: peer 29f27609 vdev: 0 addr: 08:e6:89:40:12:7e [76301.151549] ath10k_pci :00:00.0: removing peer, cleanup-all, deleting: peer 7cbbd9a3 vdev: 0 addr: c4:61:8b:23:6d:ca [76301.162681] ath10k_pci :00:00.0: removing peer, cleanup-all, deleting: peer 15825a2b vdev: 0 addr: c8:f6:50:68:97:e5 [76301.173808] ath10k_pci :00:00.0: removing peer, cleanup-all, deleting: peer 8f0f5636 vdev: 0 addr: 14:cc:20:be:89:31 [76301.349424] ieee80211 phy0: Hardware restart was requested [76302.616934] ath10k_pci :00:00.0: 10.1 wmi init: vdevs: 16 peers: 127 tid: 256 [76302.634435] ath10k_pci :00:00.0: wmi print 'P 128 V 8 T 410' [76302.640835] ath10k_pci :00:00.0: wmi print 'msdu-desc: 1424 sw-crypt: 0 ct-sta: 0' [76302.649021] ath10k_pci :00:00.0: wmi print 'alloc rem: 24632 iram: 26408' [76302.732331] ath10k_pci :00:00.0: pdev param 0 not
Re: [OpenWrt-Devel] [PATCH] lantiq: net: wrong operator
This was a test - please ignore. Already deleted from patchwork > On 27 May 2019, at 18:44, Kevin 'ldir' Darbyshire-Bryant > wrote: > > Signed-off-by: Kevin Darbyshire-Bryant > --- > .../patches-4.14/0025-NET-MIPS-lantiq-adds-xrx200-net.patch | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git > a/target/linux/lantiq/patches-4.14/0025-NET-MIPS-lantiq-adds-xrx200-net.patch > b/target/linux/lantiq/patches-4.14/0025-NET-MIPS-lantiq-adds-xrx200-net.patch > index 7eaf0b7b7b..0d97b4742b 100644 > --- > a/target/linux/lantiq/patches-4.14/0025-NET-MIPS-lantiq-adds-xrx200-net.patch > +++ > b/target/linux/lantiq/patches-4.14/0025-NET-MIPS-lantiq-adds-xrx200-net.patch > @@ -934,8 +934,8 @@ Subject: [PATCH 25/36] NET: MIPS: lantiq: adds xrx200-net > + > + link->duplex = xrx200sw_read_x(XRX200_MAC_PSTAT_FDUP, port); > + > -+link->rx_flow = !!(xrx200sw_read_x(XRX200_MAC_CTRL_0_FCON, port) && > 0x0010); > -+link->tx_flow = !!(xrx200sw_read_x(XRX200_MAC_CTRL_0_FCON, port) && > 0x0020); > ++link->rx_flow = !!(xrx200sw_read_x(XRX200_MAC_CTRL_0_FCON, port) & > 0x0010); > ++link->tx_flow = !!(xrx200sw_read_x(XRX200_MAC_CTRL_0_FCON, port) & > 0x0020); > + link->aneg = !(xrx200sw_read_x(XRX200_MAC_CTRL_0_FCON, port)); > + > + link->speed = SWITCH_PORT_SPEED_10; > -- > 2.20.1 (Apple Git-117) > Cheers, Kevin D-B gpg: 012C ACB2 28C6 C53E 9775 9123 B3A2 389B 9DE2 334A ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] restoring dscp on ingress
This was a test - please ignore. Already deleted from patchwork
> On 27 May 2019, at 19:02, Kevin 'ldir' Darbyshire-Bryant
> wrote:
>
> A combination of tc filter action act_ctinfo to do the restoration,
> a new savedscp option to iptables xt_connmark to store the DSCP
>
> Signed-off-by: Kevin Darbyshire-Bryant
> ---
> package/kernel/linux/modules/netsupport.mk| 10 +-
> ...-experimental-support-for-act_ctinfo.patch | 374 ++
> .../iptables/patches/0001-savedscp.patch | 213 ++
> ...et-sched-Introduce-act_ctinfo-action.patch | 636 +
> ...etfilter-connmark-introduce-savedscp.patch | 107 +++
> ...et-sched-Introduce-act_ctinfo-action.patch | 658 ++
> ...etfilter-connmark-introduce-savedscp.patch | 142
> 7 files changed, 2139 insertions(+), 1 deletion(-)
> create mode 100644
> package/network/utils/iproute2/patches/0001-initial-experimental-support-for-act_ctinfo.patch
> create mode 100644 package/network/utils/iptables/patches/0001-savedscp.patch
> create mode 100644
> target/linux/generic/hack-4.14/0001-net-sched-Introduce-act_ctinfo-action.patch
> create mode 100644
> target/linux/generic/hack-4.14/0001-netfilter-connmark-introduce-savedscp.patch
> create mode 100644
> target/linux/generic/hack-4.19/0001-net-sched-Introduce-act_ctinfo-action.patch
> create mode 100644
> target/linux/generic/hack-4.19/0001-netfilter-connmark-introduce-savedscp.patch
>
> diff --git a/package/kernel/linux/modules/netsupport.mk
> b/package/kernel/linux/modules/netsupport.mk
> index d92992e13f..7ab6d3b1b3 100644
> --- a/package/kernel/linux/modules/netsupport.mk
> +++ b/package/kernel/linux/modules/netsupport.mk
> @@ -803,7 +803,6 @@ endef
>
> $(eval $(call KernelPackage,sched-mqprio))
>
> -
> define KernelPackage/sched-connmark
> SUBMENU:=$(NETWORK_SUPPORT_MENU)
> TITLE:=Traffic shaper conntrack mark support
> @@ -814,6 +813,15 @@ define KernelPackage/sched-connmark
> endef
> $(eval $(call KernelPackage,sched-connmark))
>
> +define KernelPackage/sched-ctinfo
> + SUBMENU:=$(NETWORK_SUPPORT_MENU)
> + TITLE:=Traffic shaper ctinfo support
> + DEPENDS:=+kmod-sched-core +kmod-ipt-core +kmod-ipt-conntrack-extra
> + KCONFIG:=CONFIG_NET_ACT_CTINFO
> + FILES:=$(LINUX_DIR)/net/sched/act_ctinfo.ko
> + AUTOLOAD:=$(call AutoLoad,71, act_ctinfo)
> +endef
> +$(eval $(call KernelPackage,sched-ctinfo))
>
> define KernelPackage/sched-ipset
> SUBMENU:=$(NETWORK_SUPPORT_MENU)
> diff --git
> a/package/network/utils/iproute2/patches/0001-initial-experimental-support-for-act_ctinfo.patch
>
> b/package/network/utils/iproute2/patches/0001-initial-experimental-support-for-act_ctinfo.patch
> new file mode 100644
> index 00..6983e7faed
> --- /dev/null
> +++
> b/package/network/utils/iproute2/patches/0001-initial-experimental-support-for-act_ctinfo.patch
> @@ -0,0 +1,374 @@
> +From 5dd8945255b679246041866285faab2e4348362c Mon Sep 17 00:00:00 2001
> +From: Kevin Darbyshire-Bryant
> +Date: Fri, 15 Mar 2019 09:35:37 +
> +Subject: [PATCH] initial experimental support for act_ctinfo
> +
> +switchtoctinfo
> +
> +Signed-off-by: Kevin Darbyshire-Bryant
> +---
> + include/uapi/linux/pkt_cls.h | 1 +
> + include/uapi/linux/tc_act/tc_ctinfo.h | 52 +
> + tc/Makefile | 1 +
> + tc/m_ctinfo.c | 266 ++
> + 4 files changed, 320 insertions(+)
> + create mode 100644 include/uapi/linux/tc_act/tc_ctinfo.h
> + create mode 100644 tc/m_ctinfo.c
> +
> +diff --git a/include/uapi/linux/pkt_cls.h b/include/uapi/linux/pkt_cls.h
> +index 95d0db2a..7df0e808 100644
> +--- a/include/uapi/linux/pkt_cls.h
> b/include/uapi/linux/pkt_cls.h
> +@@ -68,6 +68,7 @@ enum {
> + TCA_ID_UNSPEC=0,
> + TCA_ID_POLICE=1,
> + /* other actions go here */
> ++TCA_ID_CTINFO=27,
> + __TCA_ID_MAX=255
> + };
> +
> +diff --git a/include/uapi/linux/tc_act/tc_ctinfo.h
> b/include/uapi/linux/tc_act/tc_ctinfo.h
> +new file mode 100644
> +index ..48c40f65
> +--- /dev/null
> b/include/uapi/linux/tc_act/tc_ctinfo.h
> +@@ -0,0 +1,52 @@
> ++/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
> ++#ifndef __UAPI_TC_CTINFO_H
> ++#define __UAPI_TC_CTINFO_H
> ++
> ++#include
> ++#include
> ++
> ++struct tc_ctinfo {
> ++tc_gen;
> ++};
> ++
> ++struct tc_ctinfo_dscp {
> ++__u32 mask;
> ++__u32 statemask;
> ++};
> ++
> ++struct tc_ctinfo_cpmark {
> ++__u32 mask;
> ++};
> ++
> ++struct tc_ctinfo_stats_dscp {
> ++__u64 set;
> ++__u64 error;
> ++};
> ++
> ++struct tc_ctinfo_stats_c
[OpenWrt-Devel] [PATCH] restoring dscp on ingress
A combination of tc filter action act_ctinfo to do the restoration,
a new savedscp option to iptables xt_connmark to store the DSCP
Signed-off-by: Kevin Darbyshire-Bryant
---
package/kernel/linux/modules/netsupport.mk| 10 +-
...-experimental-support-for-act_ctinfo.patch | 374 ++
.../iptables/patches/0001-savedscp.patch | 213 ++
...et-sched-Introduce-act_ctinfo-action.patch | 636 +
...etfilter-connmark-introduce-savedscp.patch | 107 +++
...et-sched-Introduce-act_ctinfo-action.patch | 658 ++
...etfilter-connmark-introduce-savedscp.patch | 142
7 files changed, 2139 insertions(+), 1 deletion(-)
create mode 100644
package/network/utils/iproute2/patches/0001-initial-experimental-support-for-act_ctinfo.patch
create mode 100644 package/network/utils/iptables/patches/0001-savedscp.patch
create mode 100644
target/linux/generic/hack-4.14/0001-net-sched-Introduce-act_ctinfo-action.patch
create mode 100644
target/linux/generic/hack-4.14/0001-netfilter-connmark-introduce-savedscp.patch
create mode 100644
target/linux/generic/hack-4.19/0001-net-sched-Introduce-act_ctinfo-action.patch
create mode 100644
target/linux/generic/hack-4.19/0001-netfilter-connmark-introduce-savedscp.patch
diff --git a/package/kernel/linux/modules/netsupport.mk
b/package/kernel/linux/modules/netsupport.mk
index d92992e13f..7ab6d3b1b3 100644
--- a/package/kernel/linux/modules/netsupport.mk
+++ b/package/kernel/linux/modules/netsupport.mk
@@ -803,7 +803,6 @@ endef
$(eval $(call KernelPackage,sched-mqprio))
-
define KernelPackage/sched-connmark
SUBMENU:=$(NETWORK_SUPPORT_MENU)
TITLE:=Traffic shaper conntrack mark support
@@ -814,6 +813,15 @@ define KernelPackage/sched-connmark
endef
$(eval $(call KernelPackage,sched-connmark))
+define KernelPackage/sched-ctinfo
+ SUBMENU:=$(NETWORK_SUPPORT_MENU)
+ TITLE:=Traffic shaper ctinfo support
+ DEPENDS:=+kmod-sched-core +kmod-ipt-core +kmod-ipt-conntrack-extra
+ KCONFIG:=CONFIG_NET_ACT_CTINFO
+ FILES:=$(LINUX_DIR)/net/sched/act_ctinfo.ko
+ AUTOLOAD:=$(call AutoLoad,71, act_ctinfo)
+endef
+$(eval $(call KernelPackage,sched-ctinfo))
define KernelPackage/sched-ipset
SUBMENU:=$(NETWORK_SUPPORT_MENU)
diff --git
a/package/network/utils/iproute2/patches/0001-initial-experimental-support-for-act_ctinfo.patch
b/package/network/utils/iproute2/patches/0001-initial-experimental-support-for-act_ctinfo.patch
new file mode 100644
index 00..6983e7faed
--- /dev/null
+++
b/package/network/utils/iproute2/patches/0001-initial-experimental-support-for-act_ctinfo.patch
@@ -0,0 +1,374 @@
+From 5dd8945255b679246041866285faab2e4348362c Mon Sep 17 00:00:00 2001
+From: Kevin Darbyshire-Bryant
+Date: Fri, 15 Mar 2019 09:35:37 +
+Subject: [PATCH] initial experimental support for act_ctinfo
+
+switchtoctinfo
+
+Signed-off-by: Kevin Darbyshire-Bryant
+---
+ include/uapi/linux/pkt_cls.h | 1 +
+ include/uapi/linux/tc_act/tc_ctinfo.h | 52 +
+ tc/Makefile | 1 +
+ tc/m_ctinfo.c | 266 ++
+ 4 files changed, 320 insertions(+)
+ create mode 100644 include/uapi/linux/tc_act/tc_ctinfo.h
+ create mode 100644 tc/m_ctinfo.c
+
+diff --git a/include/uapi/linux/pkt_cls.h b/include/uapi/linux/pkt_cls.h
+index 95d0db2a..7df0e808 100644
+--- a/include/uapi/linux/pkt_cls.h
b/include/uapi/linux/pkt_cls.h
+@@ -68,6 +68,7 @@ enum {
+ TCA_ID_UNSPEC=0,
+ TCA_ID_POLICE=1,
+ /* other actions go here */
++ TCA_ID_CTINFO=27,
+ __TCA_ID_MAX=255
+ };
+
+diff --git a/include/uapi/linux/tc_act/tc_ctinfo.h
b/include/uapi/linux/tc_act/tc_ctinfo.h
+new file mode 100644
+index ..48c40f65
+--- /dev/null
b/include/uapi/linux/tc_act/tc_ctinfo.h
+@@ -0,0 +1,52 @@
++/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
++#ifndef __UAPI_TC_CTINFO_H
++#define __UAPI_TC_CTINFO_H
++
++#include
++#include
++
++struct tc_ctinfo {
++ tc_gen;
++};
++
++struct tc_ctinfo_dscp {
++ __u32 mask;
++ __u32 statemask;
++};
++
++struct tc_ctinfo_cpmark {
++ __u32 mask;
++};
++
++struct tc_ctinfo_stats_dscp {
++ __u64 set;
++ __u64 error;
++};
++
++struct tc_ctinfo_stats_cpmark {
++ __u64 set;
++};
++
++enum {
++ TCA_CTINFO_UNSPEC,
++ TCA_CTINFO_PAD,
++ TCA_CTINFO_TM,
++ TCA_CTINFO_ACT,
++ TCA_CTINFO_ZONE,
++ TCA_CTINFO_PARMS_DSCP,
++ TCA_CTINFO_PARMS_CPMARK,
++ TCA_CTINFO_MODE_DSCP,
++ TCA_CTINFO_MODE_CPMARK,
++ TCA_CTINFO_STATS_DSCP,
++ TCA_CTINFO_STATS_CPMARK,
++ __TCA_CTINFO_MAX
++};
++
++#define TCA_CTINFO_MAX (__TCA_CTINFO_MAX - 1)
++
++enum {
++ CTINFO_MODE_DSCP= BIT(0),
++ CTINFO_MODE_CPMARK = BIT(1)
++};
++
++#endif
+diff --git a/tc/Makefile b/tc/Makefile
+index 2edaf2c8..ec93a9a1 100644
+--- a/tc/Makefile
b/tc/Makefile
+@@ -48,6 +48,7 @@ TCMODULES += m_csum.o
+ TCMODULES += m_simple.o
+
[OpenWrt-Devel] [PATCH] lantiq: net: wrong operator
Signed-off-by: Kevin Darbyshire-Bryant --- .../patches-4.14/0025-NET-MIPS-lantiq-adds-xrx200-net.patch | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/target/linux/lantiq/patches-4.14/0025-NET-MIPS-lantiq-adds-xrx200-net.patch b/target/linux/lantiq/patches-4.14/0025-NET-MIPS-lantiq-adds-xrx200-net.patch index 7eaf0b7b7b..0d97b4742b 100644 --- a/target/linux/lantiq/patches-4.14/0025-NET-MIPS-lantiq-adds-xrx200-net.patch +++ b/target/linux/lantiq/patches-4.14/0025-NET-MIPS-lantiq-adds-xrx200-net.patch @@ -934,8 +934,8 @@ Subject: [PATCH 25/36] NET: MIPS: lantiq: adds xrx200-net + + link->duplex = xrx200sw_read_x(XRX200_MAC_PSTAT_FDUP, port); + -+ link->rx_flow = !!(xrx200sw_read_x(XRX200_MAC_CTRL_0_FCON, port) && 0x0010); -+ link->tx_flow = !!(xrx200sw_read_x(XRX200_MAC_CTRL_0_FCON, port) && 0x0020); ++ link->rx_flow = !!(xrx200sw_read_x(XRX200_MAC_CTRL_0_FCON, port) & 0x0010); ++ link->tx_flow = !!(xrx200sw_read_x(XRX200_MAC_CTRL_0_FCON, port) & 0x0020); + link->aneg = !(xrx200sw_read_x(XRX200_MAC_CTRL_0_FCON, port)); + + link->speed = SWITCH_PORT_SPEED_10; -- 2.20.1 (Apple Git-117) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ar71xx: add support for GL.iNet GL-X1200
> On 11 Apr 2019, at 08:53, wellnw wrote:
>
> This patch adds supports for GL-X1200.
>
> Specification:
> - SOC: QCA9563 (775MHz)
> - Flash: 16 MiB (W25Q128FVSG)
> - RAM: 128 MiB DDR2
> - Ethernet: 4x 1Gbps LAN + 1x 1Gbps WAN
> - Wireless: QCA9563(2.4GHz) and QCA9886(5GHz)
> - SIM: 2x SIM card slots
> - MicroSD: 1x microSD slot
> - Antenna: 2x external 5dBi antennas
> - USB: 1x USB 2.0 port
> - Button: 1x reset button
> - LED: 16x LEDs (3x GPIO controllable)
> - UART: 1x UART on PCB (JP1: 3.3V, RX, TX, GND)
>
> Signed-off-by: wellnw
> ---
> target/linux/ar71xx/base-files/etc/board.d/01_leds | 4 +
> .../linux/ar71xx/base-files/etc/board.d/02_network | 4 +
> .../etc/hotplug.d/firmware/11-ath10k-caldata | 5 +
> target/linux/ar71xx/base-files/lib/ar71xx.sh | 3 +
> .../ar71xx/base-files/lib/upgrade/platform.sh | 1 +
> target/linux/ar71xx/config-4.14| 1 +
> .../ar71xx/files/arch/mips/ath79/Kconfig.openwrt | 11 ++
> target/linux/ar71xx/files/arch/mips/ath79/Makefile | 1 +
> .../ar71xx/files/arch/mips/ath79/mach-gl-x1200.c | 173 +
> .../linux/ar71xx/files/arch/mips/ath79/machtypes.h | 1 +
> target/linux/ar71xx/generic/config-default | 1 +
> target/linux/ar71xx/image/generic.mk | 13 ++
> 12 files changed, 218 insertions(+)
> create mode 100644 target/linux/ar71xx/files/arch/mips/ath79/mach-gl-x1200.c
>
> diff --git a/target/linux/ar71xx/base-files/etc/board.d/01_leds
> b/target/linux/ar71xx/base-files/etc/board.d/01_leds
> index 41dd8c5..eb455ce 100755
> --- a/target/linux/ar71xx/base-files/etc/board.d/01_leds
> +++ b/target/linux/ar71xx/base-files/etc/board.d/01_leds
> @@ -448,6 +448,10 @@ gl-inet)
> ucidef_set_led_netdev "lan" "LAN" "$board:green:lan" "eth1"
> ucidef_set_led_wlan "wlan" "WLAN" "$board:red:wlan" "phy0tpt"
> ;;
> +gl-x1200)
> + ucidef_set_led_wlan "wlan2g" "WLAN2G" "$board:green:wlan2g" "phy1tpt"
> + ucidef_set_led_wlan "wlan5g" "WLAN5G" "$board:green:wlan5g" "phy0tpt"
> + ;;
> hiwifi-hc6361)
> ucidef_set_led_netdev "inet" "INET" "hiwifi:blue:internet" "eth1"
> ucidef_set_led_wlan "wlan" "WLAN" "hiwifi:blue:wlan-2p4" "phy0tpt"
> diff --git a/target/linux/ar71xx/base-files/etc/board.d/02_network
> b/target/linux/ar71xx/base-files/etc/board.d/02_network
> index 68874e0..6fd4c25 100755
> --- a/target/linux/ar71xx/base-files/etc/board.d/02_network
> +++ b/target/linux/ar71xx/base-files/etc/board.d/02_network
> @@ -456,6 +456,10 @@ ar71xx_setup_interfaces()
> ucidef_add_switch "switch0" \
> "0@eth0" "2:lan:2" "3:lan:1" "1:wan"
> ;;
> + gl-x1200)
> + ucidef_add_switch "switch0" \
> + "0@eth0" "1:lan" "2:lan" "3:lan" "4:lan" "5:wan"
> + ;;
> jwap230)
> ucidef_set_interfaces_lan_wan "eth0.1" "eth1.2"
> ucidef_add_switch "switch0" \
> diff --git
> a/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
> b/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
> index 2ded261..fd6f213 100644
> --- a/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
> +++ b/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
> @@ -187,6 +187,11 @@ case "$FIRMWARE" in
> cf-e385ac)
> ath10kcal_extract "art" 20480 12064
> ;;
> + gl-x1200)
> + ath10kcal_extract "art" 20480 12064
> + ln -sf /lib/firmware/ath10k/pre-cal-pci-\:00\:00.0.bin \
> + /lib/firmware/ath10k/QCA9888/hw2.0/board.bin
> + ;;
> esac
> ;;
> *)
> diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh
> b/target/linux/ar71xx/base-files/lib/ar71xx.sh
> index 990683a..42902d0 100755
> --- a/target/linux/ar71xx/base-files/lib/ar71xx.sh
> +++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh
> @@ -794,6 +794,9 @@ ar71xx_board_detect() {
> *"GL-USB150")
> name="gl-usb150"
> ;;
> + *"GL-X1200")
> + name="gl-x1200"
> + ;;
> *"HiveAP-121")
> name="hiveap-121"
> ;;
> diff --git a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
> b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
> index 8173501..55be0a3 100755
> --- a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
> +++ b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
> @@ -273,6 +273,7 @@ platform_check_image() {
> gl-domino|\
> gl-mifi|\
> gl-usb150|\
> + gl-x1200|\
> hiwifi-hc6361|\
> hornet-ub-x2|\
> jwap230|\
> diff --git a/target/linux/ar71xx/config-4.14 b/target/linux/ar71xx/config-4.14
> index 9a524fa..8f8d8ce 100644
> --- a/target/linux/ar71xx/config-4.14
> +++ b/target/linux/ar71xx/config-4.14
> @@ -130,6
Re: [OpenWrt-Devel] [BUG] lantiq: net: wrong operator
> On 17 Feb 2019, at 08:57, Mathias Kresin wrote:
>
> 08/02/2019 09:23, Petr Cvek:
>> Hello,
>> There is a wrong code in 0025-NET-MIPS-lantiq-adds-xrx200-net.patch [1], the
>> original code:
>> +link->rx_flow = !!(xrx200sw_read_x(XRX200_MAC_CTRL_0_FCON, port) &&
>> 0x0010);
>> +link->tx_flow = !!(xrx200sw_read_x(XRX200_MAC_CTRL_0_FCON, port) &&
>> 0x0020);
>> wants to mask the register value and is using a logical AND and not a
>> bitwise AND.
>> The fix should be:
>> +link->rx_flow = !!(xrx200sw_read_x(XRX200_MAC_CTRL_0_FCON, port) &
>> 0x0010);
>> +link->tx_flow = !!(xrx200sw_read_x(XRX200_MAC_CTRL_0_FCON, port) &
>> 0x0020);
>> References:
>> [1]
>> https://github.com/openwrt/openwrt/blob/master/target/linux/lantiq/patches-4.14/0025-NET-MIPS-lantiq-adds-xrx200-net.patch#L937
>>
>
> Hey Petr,
>
> it looks indeed wrong. And looking more closer at the lines, I don't get why
> we need the double negation.
Having seen this code structure before, it’s a non-obvious way of turning a
masked and hence value based true/false into a binary 0 or 1 result: Exhibit A
moronic demo c programme:
#include
int main()
{
printf("%d\n", 5 & 4);
printf("%d\n", (5 & 4));
printf("%d\n", !(5 & 4));
printf("%d\n", !!(5 & 4));
}
Results in:
4
4
0
1
Cheers,
Kevin D-B
012C ACB2 28C6 C53E 9775 9123 B3A2 389B 9DE2 334A
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] net: Allow class-e address assignment via ifconfig ioctl
Hi Linus,
FYI this was backported to the Openwrt patch tree by yours truly in
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=2574c86ce66c4032e5905d46601106ccc0c69676
and the follow up fix in
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=1fdb4a7907e0290c7fe5ca3346d40782002dec7b
I await the opportunity to remove the patches for 4.9/4.14/4.19 courtesy
delivery from upstream :-)
Cheers,
Kevin
> On 14 Feb 2019, at 12:22, Linus Walleij wrote:
>
> From: Dave Taht
>
> commit 65cab850f0eeaa9180bd2e10a231964f33743edf upstream.
>
> While most distributions long ago switched to the iproute2 suite
> of utilities, which allow class-e (240.0.0.0/4) address assignment,
> distributions relying on busybox, toybox and other forms of
> ifconfig cannot assign class-e addresses without this kernel patch.
>
> While CIDR has been obsolete for 2 decades, and a survey of all the
> open source code in the world shows the IN_whatever macros are also
> obsolete... rather than obsolete CIDR from this ioctl entirely, this
> patch merely enables class-e assignment, sanely.
>
> Signed-off-by: Dave Taht
> Signed-off-by: David S. Miller
> ---
> - This commit is upstream in v4.20
> - This should ve applied for stable v4.19.y, v4.14.y and v4.9.y
> ---
> include/uapi/linux/in.h | 10 +++---
> net/ipv4/devinet.c | 5 +++--
> net/ipv4/ipconfig.c | 2 ++
> 3 files changed, 12 insertions(+), 5 deletions(-)
>
> diff --git a/include/uapi/linux/in.h b/include/uapi/linux/in.h
> index 48e8a225b985..f6052e70bf40 100644
> --- a/include/uapi/linux/in.h
> +++ b/include/uapi/linux/in.h
> @@ -266,10 +266,14 @@ struct sockaddr_in {
>
> #define IN_CLASSD(a)long int) (a)) & 0xf000) ==
> 0xe000)
> #define IN_MULTICAST(a) IN_CLASSD(a)
> -#define IN_MULTICAST_NET 0xF000
> +#define IN_MULTICAST_NET0xe000
>
> -#define IN_EXPERIMENTAL(a) long int) (a)) & 0xf000) ==
> 0xf000)
> -#define IN_BADCLASS(a) IN_EXPERIMENTAL((a))
> +#define IN_BADCLASS(a) long int) (a) ) == 0x)
> +#define IN_EXPERIMENTAL(a) IN_BADCLASS((a))
> +
> +#define IN_CLASSE(a)long int) (a)) & 0xf000) ==
> 0xf000)
> +#define IN_CLASSE_NET 0x
> +#define IN_CLASSE_NSHIFT0
>
> /* Address to accept any incoming messages. */
> #define INADDR_ANY ((unsigned long int) 0x)
> diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c
> index ea4bd8a52422..e38042933a27 100644
> --- a/net/ipv4/devinet.c
> +++ b/net/ipv4/devinet.c
> @@ -941,17 +941,18 @@ static int inet_abc_len(__be32 addr)
> {
> int rc = -1;/* Something else, probably a multicast. */
>
> - if (ipv4_is_zeronet(addr))
> + if (ipv4_is_zeronet(addr) || ipv4_is_lbcast(addr))
> rc = 0;
> else {
> __u32 haddr = ntohl(addr);
> -
> if (IN_CLASSA(haddr))
> rc = 8;
> else if (IN_CLASSB(haddr))
> rc = 16;
> else if (IN_CLASSC(haddr))
> rc = 24;
> + else if (IN_CLASSE(haddr))
> + rc = 32;
> }
>
> return rc;
> diff --git a/net/ipv4/ipconfig.c b/net/ipv4/ipconfig.c
> index 88212615bf4c..2393e5c106bf 100644
> --- a/net/ipv4/ipconfig.c
> +++ b/net/ipv4/ipconfig.c
> @@ -429,6 +429,8 @@ static int __init ic_defaults(void)
> ic_netmask = htonl(IN_CLASSB_NET);
> else if (IN_CLASSC(ntohl(ic_myaddr)))
> ic_netmask = htonl(IN_CLASSC_NET);
> + else if (IN_CLASSE(ntohl(ic_myaddr)))
> + ic_netmask = htonl(IN_CLASSE_NET);
> else {
> pr_err("IP-Config: Unable to guess netmask for address
> %pI4\n",
> _myaddr);
> --
> 2.20.1
>
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Cheers,
Kevin D-B
012C ACB2 28C6 C53E 9775 9123 B3A2 389B 9DE2 334A
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] kernel: MIPS: math-emu Write-protect delay slot emulation pages
> On 24 Dec 2018, at 03:53, Yousong Zhou wrote: > >> > Hi, Kevin > > I just took another look at the build system. On OpenWrt, we have a > pending patch 304-mips_disable_fpu.patch that makes fpu emulation for > mips an optional feature. We have most mips targets have that feature > disabled. The absence should be fine as we tell toolchain to use > soft-float explicitly for the whole build. > > So another approach would be enhancing the disable-fpu patch to also > not mapping the dsemu page at all. ha - you can’t exploit a page that doesn’t exist :-) Just pushed the backport to openwrt and I have your ‘don’t allocate the page’ patch as an additional commit in my staging tree here https://git.openwrt.org/?p=openwrt/staging/ldir.git;a=summary It’s all running on my box ok so far cat /proc/self/maps 0040-0047a000 r-xp 1f:03 1825 /bin/busybox 00489000-0048a000 r-xp 00079000 1f:03 1825 /bin/busybox 0048a000-0048b000 rwxp 0007a000 1f:03 1825 /bin/busybox 77e9e000-77ec3000 r-xp 1f:03 2298 /lib/libgcc_s.so.1 77ec3000-77ec4000 rwxp 00015000 1f:03 2298 /lib/libgcc_s.so.1 77ec4000-77f57000 r-xp 1f:03 2474 /lib/libc.so 77f66000-77f68000 rwxp 00092000 1f:03 2474 /lib/libc.so 77f68000-77f6a000 rwxp 00:00 0 7f744000-7f765000 rw-p 00:00 0 [stack] 7ff88000-7ff89000 r--p 00:00 0 [vvar] 7ff89000-7ff8a000 r-xp 00:00 0 [vdso] Nothing 7xxx related has a static address :-) Cheers, Kevin D-B 012C ACB2 28C6 C53E 9775 9123 B3A2 389B 9DE2 334A ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] kernel: MIPS: math-emu Write-protect delay slot emulation pages
> On 23 Dec 2018, at 09:43, Kevin 'ldir' Darbyshire-Bryant
> wrote:
>
> I’d suggest putting the champagne away for the moment. I’m not convinced and
> I’ll explain why after a bit more checking.
TL;DR - I don’t think the mips processor, certainly in the Archer c7 supports
ri/xi.
I dropped the cpu_has_rixi 0 override in
0014-MIPS-ath79-finetune-cpu-overrides.patch. I then patched the kernel to
dump a little bit more info from /proc/cpuinfo:
diff --git a/arch/mips/kernel/proc.c b/arch/mips/kernel/proc.c
index b2de408a2..3ae85c792 100644
--- a/arch/mips/kernel/proc.c
+++ b/arch/mips/kernel/proc.c
@@ -126,6 +126,9 @@ static int show_cpuinfo(struct seq_file *m, void *v)
if (cpu_has_xpa)seq_printf(m, "%s", " xpa");
seq_printf(m, "\n");
+ seq_printf(m, "rixi used:\t: %s\n", cpu_has_rixi ? "yes" : "no");
+ seq_printf(m, "config3:\t: %X %X\n", (read_c0_config3() >> 16),
read_c0_config3());
+
if (cpu_has_mmips) {
seq_printf(m, "micromips kernel\t: %s\n",
(read_c0_config3() & MIPS_CONF3_ISA_OE) ? "yes" : "no");
cat /proc/cpuinfo
system type : Qualcomm Atheros QCA9558 ver 1 rev 0
machine : TP-Link Archer C7 Version 2
processor : 0
cpu model : MIPS 74Kc V5.0
BogoMIPS: 358.80
wait instruction: yes
microsecond timers : yes
tlb_entries : 32
extra interrupt vector : yes
hardware watchpoint : yes, count: 4, address/irw mask: [0x0ffc, 0x0ffc,
0x0ffb, 0x0ffb]
isa : mips1 mips2 mips32r1 mips32r2
ASEs implemented: mips16 dsp dsp2
rixi used: : no
config3:: 0 2E28
shadow register sets: 1
kscratch registers : 0
package : 0
core: 0
VCED exceptions : not available
VCEI exceptions : not available
According to the doc Hauke linked on page 235 here:
https://s3-eu-west-1.amazonaws.com/downloads-mips/I7200/I7200+product+launch/MIPS_nanoMIPS32_PRA_06_09_MD01251.pdf
bit 12 of config3 is the flag of interest. 0x2E28 does not set bit 12, so
"The RIE and XIE bits are not implemented within the PageGrain register."
There is a remaining mystery related to the config3 register. The
documentation claims it to be 32 bits wide yet none of the top 16 bits are set
(and I even shifted them down in case the printf couldn’t cope) so I remain
confused.
In terms of the ath79-finetune-cpu-overrides.patch, why do it? Optimisation.
The cpu_has_foo options are macros which if forced to 0/1 enable the compile to
exclude/include code at build time…so like many things Openwrt it’s a size
thing…. well as far as I understand it.
I’m now concentrating on the festive period in the comfort that at least I’ve
had a go at backporting the fpu writeable page fix with I think success (yet to
be committed) and I have a little more grasp of what rixi means.
Kevin
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] kernel: MIPS: math-emu Write-protect delay slot emulation pages
I’d suggest putting the champagne away for the moment. I’m not convinced and I’ll explain why after a bit more checking. Cheers, Kevin D-B 012C ACB2 28C6 C53E 9775 9123 B3A2 389B 9DE2 334A ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] kernel: MIPS: math-emu Write-protect delay slot emulation pages
> On 22 Dec 2018, at 18:28, Hauke Mehrtens wrote: > > > Hi Yousong, > > ASLR is currently not activated by default in OpenWrt, so the binary itself > is not randomized. Activate CONFIG_PKG_ASLR_PIE to compile Openwrt with ASLR, > but this increases the size of the binary. > > I haven't understood why some parts of the busybox binary and other binaries > are mapped rwx, when I look into it with readelf no section is mapped rwx, > but it looks like some sections are ending at an not page aligned offset and > the next section starts directly after that. I assume that Linux merges the > permissions when one page needs different permissions. > > I am still not sure if the common mips CPUs (24Kec, 74Kec) support > restricting execution on pages anyway. > > Huake At the risk of going further down the rabbit hole/off topic, if you set the cpu_has_rixi to 1 in target/linux/ath79/patches-4.14/0014-MIPS-ath79-finetune-cpu-overrides.patch and with PKG_ASLR_PIE [=y] you get: cat /proc/self/maps 0040-0047a000 r-xp 1f:03 1825 /bin/busybox 00489000-0048a000 r--p 00079000 1f:03 1825 /bin/busybox 0048a000-0048b000 rw-p 0007a000 1f:03 1825 /bin/busybox 77e38000-77e5d000 r-xp 1f:03 2298 /lib/libgcc_s.so.1 77e5d000-77e5e000 rw-p 00015000 1f:03 2298 /lib/libgcc_s.so.1 77e5e000-77ef1000 r-xp 1f:03 2474 /lib/libc.so 77f0-77f02000 rw-p 00092000 1f:03 2474 /lib/libc.so 77f02000-77f04000 rw-p 00:00 0 7f9bd000-7f9de000 rw-p 00:00 0 [stack] 7fefb000-7fefc000 r-xp 00:00 0 7ff68000-7ff69000 r--p 00:00 0 [vvar] 7ff69000-7ff6a000 r-xp 00:00 0 [vdso] The archer hasn’t blown up…….yet Cheers, Kevin D-B 012C ACB2 28C6 C53E 9775 9123 B3A2 389B 9DE2 334A ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] kernel: MIPS: math-emu Write-protect delay slot emulation pages
> On 22 Dec 2018, at 04:04, Yousong Zhou wrote:
>
> On Sat, 22 Dec 2018 at 01:21, Kevin 'ldir' Darbyshire-Bryant
> wrote:
>>
>> Backport
>> https://git.kernel.org/pub/scm/linux/kernel/git/mips/linux.git/commit/?id=adcc81f148d733b7e8e641300c5590a2cdc13bf3
>>
>> "Mapping the delay slot emulation page as both writeable & executable
>> presents a security risk, in that if an exploit can write to & jump into
>> the page then it can be used as an easy way to execute arbitrary code.
>>
>> Prevent this by mapping the page read-only for userland, and using
>> access_process_vm() with the FOLL_FORCE flag to write to it from
>> mips_dsemul().
>>
>> This will likely be less efficient due to copy_to_user_page() performing
>> cache maintenance on a whole page, rather than a single line as in the
>> previous use of flush_cache_sigtramp(). However this delay slot
>> emulation code ought not to be running in any performance critical paths
>> anyway so this isn't really a problem, and we can probably do better in
>> copy_to_user_page() anyway in future.
>>
>> A major advantage of this approach is that the fix is small & simple to
>> backport to stable kernels.
>>
>> Reported-by: Andy Lutomirski
>> Signed-off-by: Paul Burton
>> Fixes: 432c6bacbd0c ("MIPS: Use per-mm page to execute branch delay slot
>> instructions")"
>>
>> Without patch:
>>
>> cat /proc/self/maps
>> 0040-0047a000 r-xp 1f:03 1823 /bin/busybox
>> 00489000-0048a000 r-xp 00079000 1f:03 1823 /bin/busybox
>> 0048a000-0048b000 rwxp 0007a000 1f:03 1823 /bin/busybox
>> 77ec8000-77eed000 r-xp 1f:03 2296 /lib/libgcc_s.so.1
>> 77eed000-77eee000 rwxp 00015000 1f:03 2296 /lib/libgcc_s.so.1
>> 77eee000-77f81000 r-xp 1f:03 2470 /lib/libc.so
>> 77f9-77f92000 rwxp 00092000 1f:03 2470 /lib/libc.so
>> 77f92000-77f94000 rwxp 00:00 0
>> 7f946000-7f967000 rw-p 00:00 0 [stack]
>> 7fefb000-7fefc000 rwxp 00:00 0
>> 7ffac000-7ffad000 r--p 00:00 0 [vvar]
>> 7ffad000-7ffae000 r-xp 00:00 0 [vdso]
>
> Hi,
>
> I must miss something. After reading another thread on mips security,
> I was thinking that all segments with w and x permission set were
> problematic: the same attacker can write and execute shellcode there,
> right? Sorry, if the answer is too apparent ;(
>
> Regards,
>yousong
Hi Yousong,
My limited understanding goes something like this: Most of the other segments
address ranges change on each execution due to ASLR, thus whilst they can be
written to things are harder for an attacker because locations change. The
math emulation page was especially bad because a) user space had write
permission to it and b) it was always in a fixed location. The patch removes
user space write permission to the page thus the process should receive a
SIGSEGV if it attempts to do so.
Cheers,
Kevin D-B
012C ACB2 28C6 C53E 9775 9123 B3A2 389B 9DE2 334A
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] kernel: MIPS: math-emu Write-protect delay slot emulation pages
Backport
https://git.kernel.org/pub/scm/linux/kernel/git/mips/linux.git/commit/?id=adcc81f148d733b7e8e641300c5590a2cdc13bf3
"Mapping the delay slot emulation page as both writeable & executable
presents a security risk, in that if an exploit can write to & jump into
the page then it can be used as an easy way to execute arbitrary code.
Prevent this by mapping the page read-only for userland, and using
access_process_vm() with the FOLL_FORCE flag to write to it from
mips_dsemul().
This will likely be less efficient due to copy_to_user_page() performing
cache maintenance on a whole page, rather than a single line as in the
previous use of flush_cache_sigtramp(). However this delay slot
emulation code ought not to be running in any performance critical paths
anyway so this isn't really a problem, and we can probably do better in
copy_to_user_page() anyway in future.
A major advantage of this approach is that the fix is small & simple to
backport to stable kernels.
Reported-by: Andy Lutomirski
Signed-off-by: Paul Burton
Fixes: 432c6bacbd0c ("MIPS: Use per-mm page to execute branch delay slot
instructions")"
Without patch:
cat /proc/self/maps
0040-0047a000 r-xp 1f:03 1823 /bin/busybox
00489000-0048a000 r-xp 00079000 1f:03 1823 /bin/busybox
0048a000-0048b000 rwxp 0007a000 1f:03 1823 /bin/busybox
77ec8000-77eed000 r-xp 1f:03 2296 /lib/libgcc_s.so.1
77eed000-77eee000 rwxp 00015000 1f:03 2296 /lib/libgcc_s.so.1
77eee000-77f81000 r-xp 1f:03 2470 /lib/libc.so
77f9-77f92000 rwxp 00092000 1f:03 2470 /lib/libc.so
77f92000-77f94000 rwxp 00:00 0
7f946000-7f967000 rw-p 00:00 0 [stack]
7fefb000-7fefc000 rwxp 00:00 0
7ffac000-7ffad000 r--p 00:00 0 [vvar]
7ffad000-7ffae000 r-xp 00:00 0 [vdso]
Patch applied:
cat /proc/self/maps
0040-0047a000 r-xp 1f:03 1825 /bin/busybox
00489000-0048a000 r-xp 00079000 1f:03 1825 /bin/busybox
0048a000-0048b000 rwxp 0007a000 1f:03 1825 /bin/busybox
77ed-77ef5000 r-xp 1f:03 2298 /lib/libgcc_s.so.1
77ef5000-77ef6000 rwxp 00015000 1f:03 2298 /lib/libgcc_s.so.1
77ef6000-77f89000 r-xp 1f:03 2474 /lib/libc.so
77f98000-77f9a000 rwxp 00092000 1f:03 2474 /lib/libc.so
77f9a000-77f9c000 rwxp 00:00 0
7fbed000-7fc0e000 rw-p 00:00 0 [stack]
7fefb000-7fefc000 r-xp 00:00 0
7fff6000-7fff7000 r--p 00:00 0 [vvar]
7fff7000-7fff8000 r-xp 00:00 0 [vdso]
Note lack of write permission to 7fefb000-7fefc000
This has received minimal testing on ath79 4.14 Archer C7 v2 only
Signed-off-by: Kevin Darbyshire-Bryant
---
...e-protect-delay-slot-emulation-pages.patch | 119 ++
...e-protect-delay-slot-emulation-pages.patch | 119 ++
...e-protect-delay-slot-emulation-pages.patch | 119 ++
3 files changed, 357 insertions(+)
create mode 100644
target/linux/generic/backport-4.14/096-mips-math-emu-Write-protect-delay-slot-emulation-pages.patch
create mode 100644
target/linux/generic/backport-4.19/096-mips-math-emu-Write-protect-delay-slot-emulation-pages.patch
create mode 100644
target/linux/generic/backport-4.9/096-mips-math-emu-Write-protect-delay-slot-emulation-pages.patch
diff --git
a/target/linux/generic/backport-4.14/096-mips-math-emu-Write-protect-delay-slot-emulation-pages.patch
b/target/linux/generic/backport-4.14/096-mips-math-emu-Write-protect-delay-slot-emulation-pages.patch
new file mode 100644
index 00..f428285a64
--- /dev/null
+++
b/target/linux/generic/backport-4.14/096-mips-math-emu-Write-protect-delay-slot-emulation-pages.patch
@@ -0,0 +1,119 @@
+From adcc81f148d733b7e8e641300c5590a2cdc13bf3 Mon Sep 17 00:00:00 2001
+From: Paul Burton
+Date: Thu, 20 Dec 2018 17:45:43 +
+Subject: MIPS: math-emu: Write-protect delay slot emulation pages
+
+Mapping the delay slot emulation page as both writeable & executable
+presents a security risk, in that if an exploit can write to & jump into
+the page then it can be used as an easy way to execute arbitrary code.
+
+Prevent this by mapping the page read-only for userland, and using
+access_process_vm() with the FOLL_FORCE flag to write to it from
+mips_dsemul().
+
+This will likely be less efficient due to copy_to_user_page() performing
+cache maintenance on a whole page, rather than a single line as in the
+previous use of flush_cache_sigtramp(). However this delay slot
+emulation code ought not to be running in any performance critical paths
+anyway so this isn't really a problem, and we can probably do better in
+copy_to_user_page() anyway in future.
+
+A major advantage of this approach is that the fix is small & simple to
+backport to stable kernels.
+
+Reported-by: Andy Lutomirski
+Signed-off-by: Paul Burton
+Fixes: 432c6bacbd0c ("MIPS: Use per-mm page to execute branch delay slot
Re: [OpenWrt-Devel] [RFC PATCH] kernel: drop MIPS: fix cache flushing for highmem pages
> On 19 Dec 2018, at 09:57, Felix Fietkau wrote: > > On 2018-12-18 17:43, Rosen Penev wrote: >>> >> I've tested removing the patch on a 512MB mt7621 device where HIGHMEM >> is used for the second 256MB. No issues. > I think to be on the safe side we should test running fuse (ntfs-3g or > sshfs or something similar) on such a device. If that doesn't turn up > any weird hangs or data corruption within a few minutes of use, I'm all > for dropping this patch. > Rosen, is that something you could take a closer look at with your 512MB device? Kevin ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] tools: Update endian definitions for Mac OSX
- it appears (at least from OS X verison 10.10, Yosemite) that the big and little endian defintions have changed. the older #include #include reference yielded the following warning: #define __bswap_16(x) NXSwapShort(x) ^ /usr/include/architecture/byte_order.h:45:1: note: 'NXSwapShort' has been explicitly marked deprecated here For the new OS X editions, it seems that we need to refer to: #include #include and respectively use 'OSSwapInt16', 'OSSwapInt32', & 'OSSwapInt64', in place of 'NXSwapShort', 'NXSwapLong' & 'NXSwapLongLong'. Signed-off-by: Kevin Darbyshire-Bryant --- tools/include/endian.h | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/tools/include/endian.h b/tools/include/endian.h index bba70abd83..e2ac755667 100644 --- a/tools/include/endian.h +++ b/tools/include/endian.h @@ -5,11 +5,11 @@ #include #include_next #elif defined(__APPLE__) -#include -#include -#define bswap_16(x) NXSwapShort(x) -#define bswap_32(x) NXSwapInt(x) -#define bswap_64(x) NXSwapLongLong(x) +#include +#include +#define bswap_16(x) OSSwapInt16(x) +#define bswap_32(x) OSSwapInt32(x) +#define bswap_64(x) OSSwapInt64(x) #elif defined(__FreeBSD__) #include #define bswap_16(x) bswap16(x) -- 2.17.2 (Apple Git-113) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [RFC PATCH] kernel: drop MIPS: fix cache flushing for highmem pages
Signed-off-by: Kevin Darbyshire-Bryant
---
This patch, in a variety of forms, has been around since beginning 2016
as e756c2bb07, ending up in present form 0aa6c7df60 (kernel 4.4.13 bump)
and carried forward ever since.
There have been a number of MIPS kernel memory handling changes since,
including VDSO fixes that meant openwrt patches have been dropped with
no apparent fallout.
I'm basically wondering if this patch needs to still exist in the kernel
4.14.88 world? I have been running without this patch for 3+ months on
Archer C7 v2 with no obvious ill effects (I'd expect to see "nasty
segfaults and kernel crashes")
If it does still need to exist, should it go upstream?
Thoughts, comments, more testers?
...fix-cache-flushing-for-highmem-pages.patch | 30 ---
1 file changed, 30 deletions(-)
delete mode 100644
target/linux/generic/pending-4.14/100-MIPS-fix-cache-flushing-for-highmem-pages.patch
diff --git
a/target/linux/generic/pending-4.14/100-MIPS-fix-cache-flushing-for-highmem-pages.patch
b/target/linux/generic/pending-4.14/100-MIPS-fix-cache-flushing-for-highmem-pages.patch
deleted file mode 100644
index b1c65f7cd8..00
---
a/target/linux/generic/pending-4.14/100-MIPS-fix-cache-flushing-for-highmem-pages.patch
+++ /dev/null
@@ -1,30 +0,0 @@
-From: Felix Fietkau
-Subject: MIPS: fix cache flushing for highmem pages
-
-Most cache flush ops were no-op for highmem pages. This led to nasty
-segfaults and (in the case of page_address(page) == NULL) kernel
-crashes.
-
-Fix this by always flushing highmem pages using kmap/kunmap_atomic
-around the actual cache flush. This might be a bit inefficient, but at
-least it's stable.
-
-Signed-off-by: Felix Fietkau
-
a/arch/mips/mm/cache.c
-+++ b/arch/mips/mm/cache.c
-@@ -116,6 +116,13 @@ void __flush_anon_page(struct page *page
- {
- unsigned long addr = (unsigned long) page_address(page);
-
-+ if (PageHighMem(page)) {
-+ addr = (unsigned long)kmap_atomic(page);
-+ flush_data_cache_page(addr);
-+ __kunmap_atomic((void *)addr);
-+ return;
-+ }
-+
- if (pages_do_alias(addr, vmaddr)) {
- if (page_mapcount(page) && !Page_dcache_dirty(page)) {
- void *kaddr;
--
2.17.2 (Apple Git-113)
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v2] kernel: backport ifconfig ioctl support for class e addresses
Backport net: Allow class-e address assignment via ifconfig ioctl
While most distributions long ago switched to the iproute2 suite
of utilities, which allow class-e (240.0.0.0/4) address assignment,
distributions relying on busybox, toybox and other forms of
ifconfig cannot assign class-e addresses without this kernel patch.
While CIDR has been obsolete for 2 decades, and a survey of all the
open source code in the world shows the IN_whatever macros are also
obsolete... rather than obsolete CIDR from this ioctl entirely, this
patch merely enables class-e assignment, sanely.
https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/commit/?id=65cab850f0eeaa9180bd2e10a231964f33743edf
Signed-off-by: Kevin Darbyshire-Bryant
---
v2 - change patch number
...ddress-assignment-via-ifconfig-ioctl.patch | 79 +++
...ddress-assignment-via-ifconfig-ioctl.patch | 79 +++
...ddress-assignment-via-ifconfig-ioctl.patch | 79 +++
3 files changed, 237 insertions(+)
create mode 100644
target/linux/generic/backport-4.14/095-Allow-class-e-address-assignment-via-ifconfig-ioctl.patch
create mode 100644
target/linux/generic/backport-4.19/095-Allow-class-e-address-assignment-via-ifconfig-ioctl.patch
create mode 100644
target/linux/generic/backport-4.9/095-Allow-class-e-address-assignment-via-ifconfig-ioctl.patch
diff --git
a/target/linux/generic/backport-4.14/095-Allow-class-e-address-assignment-via-ifconfig-ioctl.patch
b/target/linux/generic/backport-4.14/095-Allow-class-e-address-assignment-via-ifconfig-ioctl.patch
new file mode 100644
index 00..fec083dadb
--- /dev/null
+++
b/target/linux/generic/backport-4.14/095-Allow-class-e-address-assignment-via-ifconfig-ioctl.patch
@@ -0,0 +1,79 @@
+From 46bf067870156abd61fe24d14c2486d15b8b502c Mon Sep 17 00:00:00 2001
+From: Dave Taht
+Date: Fri, 14 Dec 2018 18:38:40 +
+Subject: [PATCH 1/1] Allow class-e address assignment in ifconfig and early
+ boot
+
+While the linux kernel became mostly "class-e clean" a decade ago,
+and most distributions long ago switched to the iproute2 suite
+of utilities, which allow class-e (240.0.0.0/4) address assignment,
+distributions relying on busybox, toybox and other forms of
+ifconfig cannot assign class-e addresses without this kernel patch.
+
+With this patch, also, a boot command line on these addresses is feasible:
+(ip=248.0.1.2::248.0.1.1:255.255.255.0).
+
+While CIDR has been obsolete for 2 decades, and a survey of all the
+userspace open source code in the world shows most IN_whatever macros
+are also obsolete... rather than obsolete CIDR from this ioctl entirely,
+this patch merely enables class-e assignment, sanely.
+
+H/T to Vince Fuller and his original patch here:
+https://lkml.org/lkml/2008/1/7/370
+
+Signed-off-by: Dave Taht
+Reviewed-by: John Gilmore
+---
+ include/uapi/linux/in.h | 8 ++--
+ net/ipv4/devinet.c | 4 +++-
+ net/ipv4/ipconfig.c | 2 ++
+ 3 files changed, 11 insertions(+), 3 deletions(-)
+
+--- a/include/uapi/linux/in.h
b/include/uapi/linux/in.h
+@@ -268,8 +268,12 @@ struct sockaddr_in {
+ #define IN_MULTICAST(a) IN_CLASSD(a)
+ #define IN_MULTICAST_NET 0xF000
+
+-#define IN_EXPERIMENTAL(a) long int) (a)) & 0xf000) ==
0xf000)
+-#define IN_BADCLASS(a) IN_EXPERIMENTAL((a))
++#define IN_BADCLASS(a) long int) (a) ) == 0x)
++#define IN_EXPERIMENTAL(a) IN_BADCLASS((a))
++
++#define IN_CLASSE(a)long int) (a)) & 0xf000) ==
0xf000)
++#define IN_CLASSE_NET 0x
++#define IN_CLASSE_NSHIFT0
+
+ /* Address to accept any incoming messages. */
+ #define INADDR_ANY ((unsigned long int) 0x)
+--- a/net/ipv4/devinet.c
b/net/ipv4/devinet.c
+@@ -921,7 +921,7 @@ static int inet_abc_len(__be32 addr)
+ {
+ int rc = -1;/* Something else, probably a multicast. */
+
+- if (ipv4_is_zeronet(addr))
++ if (ipv4_is_zeronet(addr) || ipv4_is_lbcast(addr))
+ rc = 0;
+ else {
+ __u32 haddr = ntohl(addr);
+@@ -932,6 +932,8 @@ static int inet_abc_len(__be32 addr)
+ rc = 16;
+ else if (IN_CLASSC(haddr))
+ rc = 24;
++ else if (IN_CLASSE(haddr))
++ rc = 32;
+ }
+
+ return rc;
+--- a/net/ipv4/ipconfig.c
b/net/ipv4/ipconfig.c
+@@ -457,6 +457,8 @@ static int __init ic_defaults(void)
+ ic_netmask = htonl(IN_CLASSB_NET);
+ else if (IN_CLASSC(ntohl(ic_myaddr)))
+ ic_netmask = htonl(IN_CLASSC_NET);
++ else if (IN_CLASSE(ntohl(ic_myaddr)))
++ ic_netmask = htonl(IN_CLASSE_NET);
+ else {
+ pr_err("IP-Config: Unable to guess netmask for address
%pI4\n",
+
[OpenWrt-Devel] [PATCH] kernel: backport ifconfig ioctl support for class e addresses
Backport net: Allow class-e address assignment via ifconfig ioctl
While most distributions long ago switched to the iproute2 suite
of utilities, which allow class-e (240.0.0.0/4) address assignment,
distributions relying on busybox, toybox and other forms of
ifconfig cannot assign class-e addresses without this kernel patch.
While CIDR has been obsolete for 2 decades, and a survey of all the
open source code in the world shows the IN_whatever macros are also
obsolete... rather than obsolete CIDR from this ioctl entirely, this
patch merely enables class-e assignment, sanely.
https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/commit/?id=65cab850f0eeaa9180bd2e10a231964f33743edf
Signed-off-by: Kevin Darbyshire-Bryant
---
...ddress-assignment-via-ifconfig-ioctl.patch | 79 +++
...ddress-assignment-via-ifconfig-ioctl.patch | 79 +++
...ddress-assignment-via-ifconfig-ioctl.patch | 79 +++
3 files changed, 237 insertions(+)
create mode 100644
target/linux/generic/backport-4.14/700-Allow-class-e-address-assignment-via-ifconfig-ioctl.patch
create mode 100644
target/linux/generic/backport-4.19/700-Allow-class-e-address-assignment-via-ifconfig-ioctl.patch
create mode 100644
target/linux/generic/backport-4.9/700-Allow-class-e-address-assignment-via-ifconfig-ioctl.patch
diff --git
a/target/linux/generic/backport-4.14/700-Allow-class-e-address-assignment-via-ifconfig-ioctl.patch
b/target/linux/generic/backport-4.14/700-Allow-class-e-address-assignment-via-ifconfig-ioctl.patch
new file mode 100644
index 00..fec083dadb
--- /dev/null
+++
b/target/linux/generic/backport-4.14/700-Allow-class-e-address-assignment-via-ifconfig-ioctl.patch
@@ -0,0 +1,79 @@
+From 46bf067870156abd61fe24d14c2486d15b8b502c Mon Sep 17 00:00:00 2001
+From: Dave Taht
+Date: Fri, 14 Dec 2018 18:38:40 +
+Subject: [PATCH 1/1] Allow class-e address assignment in ifconfig and early
+ boot
+
+While the linux kernel became mostly "class-e clean" a decade ago,
+and most distributions long ago switched to the iproute2 suite
+of utilities, which allow class-e (240.0.0.0/4) address assignment,
+distributions relying on busybox, toybox and other forms of
+ifconfig cannot assign class-e addresses without this kernel patch.
+
+With this patch, also, a boot command line on these addresses is feasible:
+(ip=248.0.1.2::248.0.1.1:255.255.255.0).
+
+While CIDR has been obsolete for 2 decades, and a survey of all the
+userspace open source code in the world shows most IN_whatever macros
+are also obsolete... rather than obsolete CIDR from this ioctl entirely,
+this patch merely enables class-e assignment, sanely.
+
+H/T to Vince Fuller and his original patch here:
+https://lkml.org/lkml/2008/1/7/370
+
+Signed-off-by: Dave Taht
+Reviewed-by: John Gilmore
+---
+ include/uapi/linux/in.h | 8 ++--
+ net/ipv4/devinet.c | 4 +++-
+ net/ipv4/ipconfig.c | 2 ++
+ 3 files changed, 11 insertions(+), 3 deletions(-)
+
+--- a/include/uapi/linux/in.h
b/include/uapi/linux/in.h
+@@ -268,8 +268,12 @@ struct sockaddr_in {
+ #define IN_MULTICAST(a) IN_CLASSD(a)
+ #define IN_MULTICAST_NET 0xF000
+
+-#define IN_EXPERIMENTAL(a) long int) (a)) & 0xf000) ==
0xf000)
+-#define IN_BADCLASS(a) IN_EXPERIMENTAL((a))
++#define IN_BADCLASS(a) long int) (a) ) == 0x)
++#define IN_EXPERIMENTAL(a) IN_BADCLASS((a))
++
++#define IN_CLASSE(a)long int) (a)) & 0xf000) ==
0xf000)
++#define IN_CLASSE_NET 0x
++#define IN_CLASSE_NSHIFT0
+
+ /* Address to accept any incoming messages. */
+ #define INADDR_ANY ((unsigned long int) 0x)
+--- a/net/ipv4/devinet.c
b/net/ipv4/devinet.c
+@@ -921,7 +921,7 @@ static int inet_abc_len(__be32 addr)
+ {
+ int rc = -1;/* Something else, probably a multicast. */
+
+- if (ipv4_is_zeronet(addr))
++ if (ipv4_is_zeronet(addr) || ipv4_is_lbcast(addr))
+ rc = 0;
+ else {
+ __u32 haddr = ntohl(addr);
+@@ -932,6 +932,8 @@ static int inet_abc_len(__be32 addr)
+ rc = 16;
+ else if (IN_CLASSC(haddr))
+ rc = 24;
++ else if (IN_CLASSE(haddr))
++ rc = 32;
+ }
+
+ return rc;
+--- a/net/ipv4/ipconfig.c
b/net/ipv4/ipconfig.c
+@@ -457,6 +457,8 @@ static int __init ic_defaults(void)
+ ic_netmask = htonl(IN_CLASSB_NET);
+ else if (IN_CLASSC(ntohl(ic_myaddr)))
+ ic_netmask = htonl(IN_CLASSC_NET);
++ else if (IN_CLASSE(ntohl(ic_myaddr)))
++ ic_netmask = htonl(IN_CLASSE_NET);
+ else {
+ pr_err("IP-Config: Unable to guess netmask for address
%pI4\n",
+ _myaddr);
diff --git
Re: [OpenWrt-Devel] ar71xx Vs ath79 -- sysupgrade
> On 3 Dec 2018, at 18:23, Petr Štetiar wrote: > > On December 3, 2018 6:04:28 PM UTC, Henrique de Moraes Holschuh > wrote: >> (openwrt-adm dropped from this subthread) >> >> Is there a viable way to "sysupgrade" from ar71xx to ath79? > > Have you tried it? It didn't work for you? > >> Even if it would require a model-by-model "update map" for the >> lower-level stuff (LEDs, switch ports?, etc), that would be valuable. >> Otherwise, it will be difficult for people with fleets of ar71xx >> devices >> to remotely switch them to ath79... > > It works out of the box for me if the ar71xx board name matches the one in > ath79 DTS (which isn't the case for example for Nanostation, but I'll send > the patch to fix that), otherwise you just need to use force flag in > sysupgrade (if you know what you're doing) and it should work. I did one of the earlier C7 v2 migrations, with the minor glitch of having to swap the wifi devices everything went very well. Cheers, Kevin D-B 012C ACB2 28C6 C53E 9775 9123 B3A2 389B 9DE2 334A ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
