Re: [PATCH 3/3] uclient-fetch: Support for WebDAV methods
On Fri, Apr 07, 2023 at 12:39:09AM +0300, Sergey Ponomarev wrote:
> The WebDAV is an extension for HTTP for shared folders.
> In order to make wget working with it we have to declare the missing
> constants with methods.
> They don't take part in a logic except of OPTIONS methods that can't have a
> body.
>
> Signed-off-by: Sergey Ponomarev
Please examine:
https://openwrt.org/submitting-patches#submission_guidelines
The commit message needs line-wrapping.
> @@ -292,7 +308,7 @@ static void uclient_http_process_headers(struct
> uclient_http *uh)
>
> static bool uclient_request_supports_body(enum request_type req_type)
> {
> - return !(req_type == REQ_GET || req_type == REQ_HEAD);
> + return !(req_type == REQ_GET || req_type == REQ_HEAD || req_type ==
> REQ_OPTIONS);
> }
>
> static int
Here we have the problem mentioned in the previous message. That line
is going to keep growing, and growing, and growing, and growing. Whereas
if you merely invert the cases on the switch:
case REQ_GET:
case REQ_HEAD:
case REQ_OPTIONS:
return false;
default:
return true;
The rest seems reasonable. Again, note I am *not* a maintainer, so this
is *my* opinion and I do not have any authority (besides experience).
--
(\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/)
\BS (| ehem+sig...@m5p.com PGP 87145445 |) /
\_CS\ | _ -O #include O- _ | / _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 2/3] uclient-fetch: Simplify uclient_request_supports_body()
On Fri, Apr 07, 2023 at 12:39:08AM +0300, Sergey Ponomarev wrote:
> Only GET and HEAD shouldn't have a body
>
> Signed-off-by: Sergey Ponomarev
Still kind of on the short side. Also doesn't exactly describe what the
patch is doing.
> @@ -292,14 +292,7 @@ static void uclient_http_process_headers(struct
> uclient_http *uh)
>
> static bool uclient_request_supports_body(enum request_type req_type)
> {
> - switch (req_type) {
> - case REQ_POST:
> - case REQ_PUT:
> - case REQ_DELETE:
> - return true;
> - default:
> - return false;
> - }
> + return !(req_type == REQ_GET || req_type == REQ_HEAD);
> }
>
> static int
Rather than one thing being done here, I see two distinct things being
done.
First, you're inverting the default logic. You would get the same result
by having `case REQ_GET:`, `case REQ_HEAD:`, `return false;`. Then
having the default `return true;`.
This seems reasonable to do, but isn't really any simpler.
Second, you're changing from a `switch` construct to a conditional
expression. Since this is effectively a list of values, this seems
rather questionable on its own. There is a reduction of 7 lines, but
you're substituting 7 short lines for one rather long one.
Notably this is less maintainable since that line keeps growing for each
and every case you add.
The first may go through, the second seems very dubious.
(note, I am *not* an OpenWRT maintainer, a maintainer could have a
different opinion)
--
(\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/)
\BS (| ehem+sig...@m5p.com PGP 87145445 |) /
\_CS\ | _ -O #include O- _ | / _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 1/3] uclient-fetch: Make request_types sorted to optimize search
On Fri, Apr 07, 2023 at 12:39:07AM +0300, Sergey Ponomarev wrote:
> Signed-off-by: Sergey Ponomarev
> ---
That is a *very* short commit message. If self-explanatory that is
enough, but I tend to be wary of patches with so little exposition.
Mostly you're sorting things, which does tend to ease maintainance.
> @@ -40,11 +40,11 @@ enum auth_type {
> };
>
> enum request_type {
> + REQ_DELETE,
> REQ_GET,
> REQ_HEAD,
> REQ_POST,
> REQ_PUT,
> - REQ_DELETE,
> __REQ_MAX
> };
>
This is missing the comment you added below.
> @@ -57,12 +57,13 @@ enum http_state {
> HTTP_STATE_ERROR,
> };
>
> +// Must be sorted aplhabeticaly
> static const char * const request_types[__REQ_MAX] = {
> + [REQ_DELETE] = "DELETE",
> [REQ_GET] = "GET",
> [REQ_HEAD] = "HEAD",
> [REQ_POST] = "POST",
> [REQ_PUT] = "PUT",
> - [REQ_DELETE] = "DELETE",
> };
>
> struct uclient_http {
If you're going to add a comment like this, you should also add it to
request_type. I'm unsure what the style standard is here, the maintainer
may want /* */ instead of //.
Also, "Must be sorted alphabetically".
Not the topic of this commit, but appears http_state should be before
request_type or else after request_types (splitting "request_type" and
"request_types" is a Bad Thing).
> @@ -991,11 +992,15 @@ uclient_http_set_request_type(struct uclient *cl, const
> char *type)
> return -1;
>
> for (i = 0; i < ARRAY_SIZE(request_types); i++) {
> - if (strcmp(request_types[i], type) != 0)
> + int c = strcmp(request_types[i], type);
> + if (c < 0) {
> continue;
> -
> - uh->req_type = i;
> - return 0;
> + } else if (c == 0) {
> + uh->req_type = i;
> + return 0;
> + } else {
> + return -1;
> + }
> }
>
> return -1;
I am not the maintainer for this OpenWRT repository so this is strictly
an observer's opinion.
If you're truly aiming for performance, you've left a lot on the table.
There is a classic algorithm for this situation:
@@ -982,7 +984,8 @@ int
uclient_http_set_request_type(struct uclient *cl, const char *type)
{
struct uclient_http *uh = container_of(cl, struct uclient_http, uc);
- unsigned int i;
+ unsigned lo = 0, hi = __REQ_MAX, mid;
+ int res;
if (cl->backend != _backend_http)
return -1;
@@ -990,15 +993,17 @@
if (uh->state > HTTP_STATE_INIT)
return -1;
- for (i = 0; i < ARRAY_SIZE(request_types); i++) {
- if (strcmp(request_types[i], type) != 0)
- continue;
-
- uh->req_type = i;
- return 0;
+ while (res = strcmp(request_types[mid = (hi + lo) / 2], type)) {
+ if (res < 0)
+ hi = mid;
+ else
+ lo = mid + 1;
+ if (lo == hi)
+ return -1;
}
- return -1;
+ uh->req_type = mid;
+ return 0;
}
int
What you've got reduces runtime by 50% on average. The above does
log(2). I could see the maintainer preferring:
@@ -982,7 +984,7 @@ int
uclient_http_set_request_type(struct uclient *cl, const char *type)
{
struct uclient_http *uh = container_of(cl, struct uclient_http, uc);
- unsigned int i;
+ unsigned lo = 0, hi = __REQ_MAX;
if (cl->backend != _backend_http)
return -1;
@@ -990,13 +992,19 @@ uclient_http_set_request_type(struct uclient *cl, const
char *type)
if (uh->state > HTTP_STATE_INIT)
return -1;
- for (i = 0; i < ARRAY_SIZE(request_types); i++) {
- if (strcmp(request_types[i], type) != 0)
- continue;
+ do {
+ const unsigned mid = (hi + lo) / 2;
+ const int res = strcmp(request_types[mid], type);
- uh->req_type = i;
- return 0;
- }
+ if (res < 0)
+ hi = mid;
+ else if (res > 0)
+ lo = mid + 1;
+ else {
+ uh->req_type = mid;
+ return 0;
+ }
+ } while (hi != lo);
return -1;
}
I strongly prefer the former as it has all early returns as the same type
(failure) and has the end being different. Whereas this one, one early
return is success and most are failures.
Notable request_types[ARRAY_SIZE(request_types)] is an invalid entry.
This is a presently harmless bug.
Overall not a bad idea, just some patch issues.
If you use either of the above, both are:
"Signed-off-by: Elliott Mitchell "
--
(\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/)
\BS (| ehem+sig...@m5p.com PGP 87145445
Best practices for meta packages with variants
Hi, Hoping to get a little guidance from my peers. I'm trying to create a meta-package that can be selected and it will include all of the subordinate/dependent packages, but in this case one of the subordinate packages comes in two variants (IPv4-only or IPv4/v6): https://github.com/openwrt/packages/pull/20731 What's the best way to handle this? Are there any good examples already in the codebase of how to express this? Specifically this part: https://github.com/openwrt/packages/pull/20731/files#diff-00606439ee2b214f1dbac09d66df596b3cc63d3b98e49aab0fa05e0fa127250aR138 Should the meta package also have IPv4/IPv6 variants? That seems clumsy... Thanks, -Philip ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: next OpenWrt 22.03 and 21.02 minor release
Mateusz Jończyk wrote on 06.04.23 14:18: W dniu 28.03.2023 o 00:54, hauke at hauke-m.de (Hauke Mehrtens) pisze: Hi, I was wondering whether you would like to delay the release until this is fixed in mainline Linux. Hi Mateusz, this paper is about CVE-2022-47522 which seems to be fixed in all supported OpenWrt branches by commits that were pushed 7 days ago by Felix Fietkau. E.g. 4ae854d05568bc36a4df2cb6dd8fb023b5ef9944 in branch openwrt-22.03. Greetings, Andreas Hey there, Unfortunately, that commit at least breaks ath11k on Xiaomi AX3600 - I know this is not a supported device but wonder if there is other regressions? See https://forum.openwrt.org/t/xiaomi-ax3600-ath11k-failed-to-flush-transmit-queue-and-wifi-disruption/156530 this forum post. (ath11k queue flush fails on disconnect thus interrupting the whole wifi for a few seconds) Greetings, Matthias ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH-22.03 07/10] ipq40xx: add LED functions for Google WiFi
From: Jan-Niklas Burfeind
Add LED function properties for the LED controller to avoid failing
driver probe with kernel 5.15.
While at it, also define the OpenWrt LED indicator patterns for this
device.
Ref commit 583ac0e11df7 ("mpc85xx: update lp5521 led-controller node for 5.10")
Google uses white for running and red for an issue
Signed-off-by: Jan-Niklas Burfeind
Tested-by: Andrijan Möcker
Reviewed-by: Brian Norris
Signed-off-by: David Bauer
(cherry picked from commit 9b005036f8d070594fc7f3374f82c81f0a692918)
---
.../files/arch/arm/boot/dts/qcom-ipq4019-wifi.dts | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/target/linux/ipq40xx/files/arch/arm/boot/dts/qcom-ipq4019-wifi.dts
b/target/linux/ipq40xx/files/arch/arm/boot/dts/qcom-ipq4019-wifi.dts
index c48d6a75b3..173c6ff804 100644
--- a/target/linux/ipq40xx/files/arch/arm/boot/dts/qcom-ipq4019-wifi.dts
+++ b/target/linux/ipq40xx/files/arch/arm/boot/dts/qcom-ipq4019-wifi.dts
@@ -13,6 +13,13 @@
model = "Google WiFi (Gale)";
compatible = "google,wifi", "google,gale-v2", "qcom,ipq4019";
+ aliases {
+ led-boot = _blue;
+ led-failsafe = _red;
+ led-running = _blue;
+ led-upgrade = _red;
+ };
+
chosen {
/*
* rootwait: in case we're booting from slow/async USB storage.
@@ -245,12 +252,13 @@
clock-mode = /bits/ 8 <1>;
#if 1
- led@0 {
+ led0_red: led@0 {
reg = <0>;
chan-name = "LED0_Red";
led-cur = /bits/ 8 <0x64>;
max-cur = /bits/ 8 <0x78>;
color = ;
+ function = LED_FUNCTION_FAULT;
};
led@1 {
@@ -261,12 +269,13 @@
color = ;
};
- led@2 {
+ led0_blue: led@2 {
reg = <2>;
chan-name = "LED0_Blue";
led-cur = /bits/ 8 <0x64>;
max-cur = /bits/ 8 <0x78>;
color = ;
+ function = LED_FUNCTION_POWER;
};
#else
/*
@@ -275,6 +284,7 @@
* # echo 255 > /sys/class/leds/tricolor/brightness
*/
multi-led@2 {
+ function = LED_FUNCTION_POWER;
reg = <2>;
color = ;
#address-cells = <1>;
--
2.40.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH-22.03 02/10] ipq40xx: Add subtarget for Google WiFi (Gale)
From: Brian Norris
Google WiFi (codename: Gale) is an IPQ4019-based AP, with 2 Ethernet
ports, 2x2 2.4+5GHz WiFi, 512 MB RAM, 4 GB eMMC, and a USB type C port.
In its stock configuration, it runs a Chromium OS-based system, but you
wouldn't know it, since you can only manage it via a "cloud" +
mobile-app system.
The "v2" label is coded into the bootloader, which prefers the
"google,gale-v2" compatible string. I believe "v1" must have been
pre-release hardware.
Note: this is *not* the Google Nest WiFi, released in 2019.
I include "factory.bin" support, where we generate a GPT-based disk
image with 2 partitions -- a kernel partition (using the custom "Chrome
OS kernel" GUID type) and a root filesystem partition. See below for
flashing instructions.
Sysupgrade is supported via recent emmc_do_upgrade() helper.
This is a subtarget because it enables different features
(FEATURES=boot-part rootfs-part) whose configurations don't make sense
in the "generic" target, and because it builds in a few USB drivers,
which are necessary for installation (installation is performed by
booting from USB storage, and so these drivers cannot be built as
modules, since we need to load modules from USB storage).
Flashing instructions
=
Documented here:
https://openwrt.org/inbox/toh/google/google_wifi
Note this requires booting from USB storage.
Features
I've tested:
* Ethernet, both WAN and LAN ports
* eMMC
* USB-C (hub, power-delivery, peripherals)
* LED0 (R/G/B)
* WiFi (limited testing)
* SPI flash
* Serial console: once in developer mode, console can be accessed via
the USB-C port with SuzyQable, or other similar "Closed Case
Debugging" tools:
https://chromium.googlesource.com/chromiumos/third_party/hdctools/+/master/docs/ccd.md#suzyq-suzyqable
* Sysupgrade
Not tested:
* TPM
Known not working:
* Reboot: this requires some additional TrustZone / SCM
configuration to disable Qualcomm's SDI. I have a proposal upstream,
and based on IRC chats, this might be acceptable with additional DT
logic:
[RFC PATCH] firmware: qcom_scm: disable SDI at boot
https://lore.kernel.org/linux-arm-msm/20200721080054.2803881-1-computersforpe...@gmail.com/
* SMP: enabling secondary CPUs doesn't currently work using the stock
bootloader, as the qcom_scm driver assumes newer features than this
TrustZone firmware has. I posted notes here:
[RFC] qcom_scm: IPQ4019 firmware does not support atomic API?
https://lore.kernel.org/linux-arm-msm/20200913201608.GA3162100@bDebian/
* There's a single external button, and a few useful internal GPIO
switches. I haven't hooked them up.
The first two are fixed with subsequent commits.
Additional notes
Much of the DTS is pulled from the Chrome OS kernel 3.18 branch, which
the manufacturer image uses.
Note: the manufacturer bootloader knows how to patch in calibration data
via the wifi{0,1} aliases in the DTB, so while these properties aren't
present in the DTS, they are available at runtime:
# ls -l
/sys/firmware/devicetree/base/soc/wifi@a*/qcom,ath10k-pre-calibration-data
-r--r--r--1 root root 12064 Jul 15 19:11
/sys/firmware/devicetree/base/soc/wifi@a00/qcom,ath10k-pre-calibration-data
-r--r--r--1 root root 12064 Jul 15 19:11
/sys/firmware/devicetree/base/soc/wifi@a80/qcom,ath10k-pre-calibration-data
Ethernet MAC addresses are similarly patched in via the ethernet{0,1} aliases.
Signed-off-by: Brian Norris
(updated 901 - x1pro moved in the process)
Signed-off-by: Christian Lamparter
(cherry picked from commit f1c041e34f9742fcdd0c8c65f69888d3ec580541)
Signed-off-by: Jan-Niklas Burfeind
(updated 901 - fixed offset, after missing drop commit)
---
target/linux/ipq40xx/Makefile | 2 +-
.../ipq40xx/base-files/etc/board.d/02_network | 1 +
.../base-files/lib/upgrade/platform.sh| 10 +-
target/linux/ipq40xx/chromium/config-default | 10 +
target/linux/ipq40xx/chromium/target.mk | 2 +
.../arch/arm/boot/dts/qcom-ipq4019-wifi.dts | 413 ++
target/linux/ipq40xx/image/chromium.mk| 14 +
.../901-arm-boot-add-dts-files.patch | 5 +-
8 files changed, 453 insertions(+), 4 deletions(-)
create mode 100644 target/linux/ipq40xx/chromium/config-default
create mode 100644 target/linux/ipq40xx/chromium/target.mk
create mode 100644
target/linux/ipq40xx/files/arch/arm/boot/dts/qcom-ipq4019-wifi.dts
diff --git a/target/linux/ipq40xx/Makefile b/target/linux/ipq40xx/Makefile
index b704e1b54e..6051c82945 100644
--- a/target/linux/ipq40xx/Makefile
+++ b/target/linux/ipq40xx/Makefile
@@ -6,7 +6,7 @@ BOARDNAME:=Qualcomm Atheros IPQ40XX
FEATURES:=squashfs fpu ramdisk nand
CPU_TYPE:=cortex-a7
CPU_SUBTYPE:=neon-vfpv4
-SUBTARGETS:=generic mikrotik
+SUBTARGETS:=generic chromium mikrotik
KERNEL_PATCHVER:=5.10
KERNEL_TESTING_PATCHVER:=5.10
diff --git
[PATCH-22.03 06/10] ipq40xx: add reset button for Google WiFi (Gale)
From: Jan-Niklas Burfeind
Add the external reset button for use with OpenWrt.
Co-authored-by: Brian Norris
Signed-off-by: Jan-Niklas Burfeind
Reviewed-by: Brian Norris
Tested-by: Brian Norris
Signed-off-by: David Bauer
(cherry picked from commit 791550b94fc791866e486e52d3c4d1d0378966ff)
---
.../files/arch/arm/boot/dts/qcom-ipq4019-wifi.dts | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/target/linux/ipq40xx/files/arch/arm/boot/dts/qcom-ipq4019-wifi.dts
b/target/linux/ipq40xx/files/arch/arm/boot/dts/qcom-ipq4019-wifi.dts
index 9448e5145e..c48d6a75b3 100644
--- a/target/linux/ipq40xx/files/arch/arm/boot/dts/qcom-ipq4019-wifi.dts
+++ b/target/linux/ipq40xx/files/arch/arm/boot/dts/qcom-ipq4019-wifi.dts
@@ -39,16 +39,29 @@
status = "okay";
};
};
+
+ keys {
+ compatible = "gpio-keys";
+ pinctrl-0 = <_pinmux>;
+ pinctrl-names = "default";
+
+ reset {
+ label = "reset";
+ gpios = < 57 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ };
+ };
};
{
- fw_pinmux {
+ fw_pinmux: fw_pinmux {
wp {
pins = "gpio53";
output-low;
};
recovery {
pins = "gpio57";
+ function = "gpio";
bias-none;
};
developer {
--
2.40.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH-22.03 01/10] ipq40xx: Support Chromium OS image-type creation
From: Brian Norris
See firmware-utils.git commits [1], which implemented the cros-vbutil
verified-boot payload-packing tool, and extended ptgen for the CrOS
kernel partition type. With these, it's now possible to package kernel +
rootfs to make disk images that can boot a Chrome OS-based system (e.g.,
Chromebooks, or even a few AP models).
Regarding PARTUUID= changes: Chromium bootloaders work well with a
partition number offset (i.e., relative to the kernel partition), so
we'll be using a slightly different root UUID line.
NB: I've made this support specific to ip40xx for now, because I only
plan to support an IPQ4019-based AP that uses a Chromium-based
bootloader, but this image format can be used for essentially any
Chromebook, as well as the Google OnHub, a prior Chromium-based AP using
an IPQ8064 chipset.
[1]
ptgen: add Chromium OS kernel partition support
https://git.openwrt.org/?p=project/firmware-utils.git;a=commit;h=6c95945b5de973026dc6f52eb088d0943efa96bb
cros-vbutil: add Chrome OS vboot kernel-signing utility
https://git.openwrt.org/?p=project/firmware-utils.git;a=commit;h=8e7274e02fdc6f2cb61b415d6e5b2e1c7e977aa1
Signed-off-by: Brian Norris
(cherry picked from commit 17b05045bd82f04a8839666ec0fe43a5041d77c7)
Signed-off-by: Jan-Niklas Burfeind
---
Good afternoon everyone.
This series intends to support Google WiFi device 'Gale'.
I think I found all relevant commits and testing looked promising.
Feedback is highly appreciated; I realize these are a lot commits but as
most of them is pretty isolated from other devices and even subtargets,
this might be just fine?
Anyway. Have a nice weekend,
Aiyion
.../base-files/files/lib/upgrade/common.sh| 4 +++-
target/linux/ipq40xx/image/chromium.mk| 22 +++
2 files changed, 25 insertions(+), 1 deletion(-)
create mode 100644 target/linux/ipq40xx/image/chromium.mk
diff --git a/package/base-files/files/lib/upgrade/common.sh
b/package/base-files/files/lib/upgrade/common.sh
index 24ff77a8b3..5af061f6a4 100644
--- a/package/base-files/files/lib/upgrade/common.sh
+++ b/package/base-files/files/lib/upgrade/common.sh
@@ -155,9 +155,11 @@ export_bootdevice() {
fi
done
;;
+ PARTUUID=----??0?/PARTNROFF=1 | \
PARTUUID=----??02)
uuid="${rootpart#PARTUUID=}"
- uuid="${uuid%02}00"
+ uuid="${uuid%/PARTNROFF=1}"
+ uuid="${uuid%0?}00"
for disk in $(find /dev -type b); do
set -- $(dd if=$disk bs=1 skip=568 count=16
2>/dev/null | hexdump -v -e '8/1 "%02x "" "2/1 "%02x""-"6/1 "%02x"')
if [ "$4$3$2$1-$6$5-$8$7-$9" = "$uuid" ]; then
diff --git a/target/linux/ipq40xx/image/chromium.mk
b/target/linux/ipq40xx/image/chromium.mk
new file mode 100644
index 00..15d4c1a077
--- /dev/null
+++ b/target/linux/ipq40xx/image/chromium.mk
@@ -0,0 +1,22 @@
+define Build/cros-gpt
+ cp $@ $@.tmp 2>/dev/null || true
+ ptgen -o $@.tmp -g \
+ -T cros_kernel -N kernel -p $(CONFIG_TARGET_KERNEL_PARTSIZE)m \
+ -N rootfs -p $(CONFIG_TARGET_ROOTFS_PARTSIZE)m
+ cat $@.tmp >> $@
+ rm $@.tmp
+endef
+
+define Build/append-kernel-part
+ dd if=$(IMAGE_KERNEL) bs=$(CONFIG_TARGET_KERNEL_PARTSIZE)M conv=sync >>
$@
+endef
+
+# NB: Chrome OS bootloaders replace the '%U' in command lines with the UUID of
+# the kernel partition it chooses to boot from. This gives a flexible way to
+# consistently build and sign kernels that always use the subsequent
+# (PARTNROFF=1) partition as their rootfs.
+define Build/cros-vboot
+ $(STAGING_DIR_HOST)/bin/cros-vbutil \
+ -k $@ -c "root=PARTUUID=%U/PARTNROFF=1" -o $@.new
+ @mv $@.new $@
+endef
--
2.40.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH-22.03 09/10] ipq40xx: qcom_scm: Fix cold boot address command
From: Brian Norris
See my upstream questions:
https://lore.kernel.org/linux-arm-msm/20200913201608.GA3162100@bDebian/
This effectively reverts upstream Linux commit 13e77747800e ("firmware:
qcom: scm: Use atomic SCM for cold boot"), because Google WiFi boot
firmwares don't support the atomic variant.
This fixes SMP support for Google WiFi.
Signed-off-by: Brian Norris
(cherry picked from commit 26af098e0e97124a741c5c96a824b17e7f1b6434)
---
...-firmware-qcom-scm-cold-boot-address.patch | 121 ++
1 file changed, 121 insertions(+)
create mode 100644
target/linux/ipq40xx/patches-5.10/421-firmware-qcom-scm-cold-boot-address.patch
diff --git
a/target/linux/ipq40xx/patches-5.10/421-firmware-qcom-scm-cold-boot-address.patch
b/target/linux/ipq40xx/patches-5.10/421-firmware-qcom-scm-cold-boot-address.patch
new file mode 100644
index 00..accf3e9686
--- /dev/null
+++
b/target/linux/ipq40xx/patches-5.10/421-firmware-qcom-scm-cold-boot-address.patch
@@ -0,0 +1,121 @@
+--- a/drivers/firmware/qcom_scm-legacy.c
b/drivers/firmware/qcom_scm-legacy.c
+@@ -13,6 +13,9 @@
+ #include
+ #include
+
++#include
++#include
++
+ #include "qcom_scm.h"
+
+ static DEFINE_MUTEX(qcom_scm_lock);
+@@ -117,6 +120,25 @@ static void __scm_legacy_do(const struct
+ } while (res->a0 == QCOM_SCM_INTERRUPTED);
+ }
+
++static void qcom_scm_inv_range(unsigned long start, unsigned long end)
++{
++ u32 cacheline_size, ctr;
++
++ asm volatile("mrc p15, 0, %0, c0, c0, 1" : "=r" (ctr));
++ cacheline_size = 4 << ((ctr >> 16) & 0xf);
++
++ start = round_down(start, cacheline_size);
++ end = round_up(end, cacheline_size);
++ outer_inv_range(start, end);
++ while (start < end) {
++ asm ("mcr p15, 0, %0, c7, c6, 1" : : "r" (start)
++ : "memory");
++ start += cacheline_size;
++ }
++ dsb();
++ isb();
++}
++
+ /**
+ * qcom_scm_call() - Sends a command to the SCM and waits for the command to
+ * finish processing.
+@@ -160,10 +182,16 @@ int scm_legacy_call(struct device *dev,
+
+ rsp = scm_legacy_command_to_response(cmd);
+
+- cmd_phys = dma_map_single(dev, cmd, alloc_len, DMA_TO_DEVICE);
+- if (dma_mapping_error(dev, cmd_phys)) {
+- kfree(cmd);
+- return -ENOMEM;
++ if (dev) {
++ cmd_phys = dma_map_single(dev, cmd, alloc_len, DMA_TO_DEVICE);
++ if (dma_mapping_error(dev, cmd_phys)) {
++ kfree(cmd);
++ return -ENOMEM;
++ }
++ } else {
++ cmd_phys = virt_to_phys(cmd);
++ __cpuc_flush_dcache_area(cmd, alloc_len);
++ outer_flush_range(cmd_phys, cmd_phys + alloc_len);
+ }
+
+ smc.args[0] = 1;
+@@ -179,13 +207,26 @@ int scm_legacy_call(struct device *dev,
+ goto out;
+
+ do {
+- dma_sync_single_for_cpu(dev, cmd_phys + sizeof(*cmd) + cmd_len,
+- sizeof(*rsp), DMA_FROM_DEVICE);
++ if (dev) {
++ dma_sync_single_for_cpu(dev, cmd_phys + sizeof(*cmd) +
++ cmd_len, sizeof(*rsp),
++ DMA_FROM_DEVICE);
++ } else {
++ unsigned long start = (uintptr_t)cmd + sizeof(*cmd) +
++cmd_len;
++ qcom_scm_inv_range(start, start + sizeof(*rsp));
++ }
+ } while (!rsp->is_complete);
+
+- dma_sync_single_for_cpu(dev, cmd_phys + sizeof(*cmd) + cmd_len +
+- le32_to_cpu(rsp->buf_offset),
+- resp_len, DMA_FROM_DEVICE);
++ if (dev) {
++ dma_sync_single_for_cpu(dev, cmd_phys + sizeof(*cmd) + cmd_len +
++ le32_to_cpu(rsp->buf_offset),
++ resp_len, DMA_FROM_DEVICE);
++ } else {
++ unsigned long start = (uintptr_t)cmd + sizeof(*cmd) + cmd_len +
++le32_to_cpu(rsp->buf_offset);
++ qcom_scm_inv_range(start, start + resp_len);
++ }
+
+ if (res) {
+ res_buf = scm_legacy_get_response_buffer(rsp);
+@@ -193,7 +234,8 @@ int scm_legacy_call(struct device *dev,
+ res->result[i] = le32_to_cpu(res_buf[i]);
+ }
+ out:
+- dma_unmap_single(dev, cmd_phys, alloc_len, DMA_TO_DEVICE);
++ if (dev)
++ dma_unmap_single(dev, cmd_phys, alloc_len, DMA_TO_DEVICE);
+ kfree(cmd);
+ return ret;
+ }
+--- a/drivers/firmware/qcom_scm.c
b/drivers/firmware/qcom_scm.c
+@@ -344,6 +344,17 @@ int qcom_scm_set_cold_boot_addr(void *en
+ desc.args[0] = flags;
+ desc.args[1] = virt_to_phys(entry);
+
++ /*
++ * Factory firmware doesn't support the atomic variant. Non-atomic
[PATCH-22.03 05/10] ipq40xx: qcom_scm: Disable SDI at boot
From: Brian Norris
See my upstream RFC of this:
https://lore.kernel.org/linux-arm-msm/20200721080054.2803881-1-computersforpe...@gmail.com/
This fixes warm boot (reboot) for Google WiFi devices using their
factory bootloader/firmware.
I may resend this upstream eventually.
Signed-off-by: Brian Norris
(cherry picked from commit a93ec36630ef4ff5a2195ad613b616bffa50d00d)
Signed-off-by: Jan-Niklas Burfeind
---
.../420-firmware-qcom-scm-disable-SDI.patch | 47 +++
1 file changed, 47 insertions(+)
create mode 100644
target/linux/ipq40xx/patches-5.10/420-firmware-qcom-scm-disable-SDI.patch
diff --git
a/target/linux/ipq40xx/patches-5.10/420-firmware-qcom-scm-disable-SDI.patch
b/target/linux/ipq40xx/patches-5.10/420-firmware-qcom-scm-disable-SDI.patch
new file mode 100644
index 00..eb474500b1
--- /dev/null
+++ b/target/linux/ipq40xx/patches-5.10/420-firmware-qcom-scm-disable-SDI.patch
@@ -0,0 +1,47 @@
+--- a/drivers/firmware/qcom_scm.c
b/drivers/firmware/qcom_scm.c
+@@ -404,6 +404,20 @@ static int __qcom_scm_set_dload_mode(str
+ return qcom_scm_call_atomic(__scm->dev, , NULL);
+ }
+
++static int __qcom_scm_disable_sdi(struct device *dev)
++{
++ struct qcom_scm_desc desc = {
++ .svc = QCOM_SCM_SVC_BOOT,
++ .cmd = QCOM_SCM_BOOT_CONFIG_SDI,
++ .arginfo = QCOM_SCM_ARGS(2),
++ .args[0] = 1 /* 1: disable watchdog debug */,
++ .args[1] = 0 /* 0: disable SDI */,
++ .owner = ARM_SMCCC_OWNER_SIP,
++ };
++
++ return qcom_scm_call(__scm->dev, , NULL);
++}
++
+ static void qcom_scm_set_download_mode(bool enable)
+ {
+ bool avail;
+@@ -1256,6 +1270,13 @@ static int qcom_scm_probe(struct platfor
+ if (download_mode)
+ qcom_scm_set_download_mode(true);
+
++ /*
++ * Factory firmware leaves SDI (a debug interface), which prevents
++ * clean reboot.
++ */
++ if (of_machine_is_compatible("google,wifi"))
++ __qcom_scm_disable_sdi(__scm->dev);
++
+ return 0;
+ }
+
+--- a/drivers/firmware/qcom_scm.h
b/drivers/firmware/qcom_scm.h
+@@ -77,6 +77,7 @@ extern int scm_legacy_call(struct device
+ #define QCOM_SCM_SVC_BOOT 0x01
+ #define QCOM_SCM_BOOT_SET_ADDR0x01
+ #define QCOM_SCM_BOOT_TERMINATE_PC0x02
++#define QCOM_SCM_BOOT_CONFIG_SDI 0x09
+ #define QCOM_SCM_BOOT_SET_DLOAD_MODE 0x10
+ #define QCOM_SCM_BOOT_SET_REMOTE_STATE0x0a
+ #define QCOM_SCM_FLUSH_FLAG_MASK 0x3
--
2.40.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH-22.03 08/10] kernel: Package GOOGLE_FIRMWARE drivers
From: Brian Norris Useful for some Chromium OS based systems, like Google WiFi. Signed-off-by: Brian Norris (cherry picked from commit e5b009e532813d73fe7d3e3deb77b4a60c364913) --- package/kernel/linux/modules/other.mk | 26 ++ 1 file changed, 26 insertions(+) diff --git a/package/kernel/linux/modules/other.mk b/package/kernel/linux/modules/other.mk index 36f4c8a57e..178ab003d5 100644 --- a/package/kernel/linux/modules/other.mk +++ b/package/kernel/linux/modules/other.mk @@ -198,6 +198,32 @@ endef $(eval $(call KernelPackage,eeprom-at25)) +define KernelPackage/google-firmware + SUBMENU:=$(OTHER_MENU) + TITLE:=Google firmware drivers (Coreboot, VPD, Memconsole) + KCONFIG:= \ + CONFIG_GOOGLE_FIRMWARE=y \ + CONFIG_GOOGLE_COREBOOT_TABLE \ + CONFIG_GOOGLE_MEMCONSOLE \ + CONFIG_GOOGLE_MEMCONSOLE_COREBOOT \ + CONFIG_GOOGLE_VPD + FILES:= \ + $(LINUX_DIR)/drivers/firmware/google/coreboot_table.ko \ + $(LINUX_DIR)/drivers/firmware/google/memconsole.ko \ + $(LINUX_DIR)/drivers/firmware/google/memconsole-coreboot.ko \ + $(LINUX_DIR)/drivers/firmware/google/vpd-sysfs.ko + AUTOLOAD:=$(call AutoProbe,coreboot_table memconsole-coreboot vpd-sysfs) +endef + +define KernelPackage/google-firmware/description + Kernel modules for Google firmware drivers. Useful for examining firmware and + boot details on devices using a Google bootloader based on Coreboot. Provides + files like /sys/firmware/log and /sys/firmware/vpd. +endef + +$(eval $(call KernelPackage,google-firmware)) + + define KernelPackage/gpio-f7188x SUBMENU:=$(OTHER_MENU) TITLE:=Fintek F718xx/F818xx GPIO Support -- 2.40.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH-22.03 04/10] ipq40xx: chromium: Enable kmod-ramoops by default
From: Brian Norris Chromium devices (like Google WiFi) have ramoops memory reserved by the bootloader. Let's enable the ramoops kernel module by default, so we get better crash logging. Signed-off-by: Brian Norris Signed-off-by: Jan-Niklas Burfeind (updated makefile after missing drop commit) --- target/linux/ipq40xx/image/chromium.mk | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/target/linux/ipq40xx/image/chromium.mk b/target/linux/ipq40xx/image/chromium.mk index 2c8457dcfb..e17398929e 100644 --- a/target/linux/ipq40xx/image/chromium.mk +++ b/target/linux/ipq40xx/image/chromium.mk @@ -30,7 +30,11 @@ define Device/google_wifi KERNEL_NAME := zImage IMAGES += factory.bin IMAGE/factory.bin := cros-gpt | append-kernel-part | append-rootfs + # Note: Chromium/Depthcharge-based bootloaders insert a reserved-memory + # ramoops node into the Device Tree automatically, so we can use + # kmod-ramoops. DEVICE_PACKAGES := ipq-wifi-google_wifi partx-utils mkf2fs e2fsprogs \ - kmod-fs-ext4 kmod-fs-f2fs kmod-google-firmware + kmod-fs-ext4 kmod-fs-f2fs kmod-google-firmware \ + kmod-ramoops endef TARGET_DEVICES += google_wifi -- 2.40.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH-22.03 10/10] ipq40xx: google (gale) add label-mac-device
From: Jan-Niklas Burfeind
use gmac0 as in
commit a3da858ab030 ("ipq40xx: Convert Google Wifi to DSA, reenable")
Signed-off-by: Jan-Niklas Burfeind
---
.../linux/ipq40xx/files/arch/arm/boot/dts/qcom-ipq4019-wifi.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/target/linux/ipq40xx/files/arch/arm/boot/dts/qcom-ipq4019-wifi.dts
b/target/linux/ipq40xx/files/arch/arm/boot/dts/qcom-ipq4019-wifi.dts
index 173c6ff804..d650317863 100644
--- a/target/linux/ipq40xx/files/arch/arm/boot/dts/qcom-ipq4019-wifi.dts
+++ b/target/linux/ipq40xx/files/arch/arm/boot/dts/qcom-ipq4019-wifi.dts
@@ -14,6 +14,7 @@
compatible = "google,wifi", "google,gale-v2", "qcom,ipq4019";
aliases {
+ label-mac-device =
led-boot = _blue;
led-failsafe = _red;
led-running = _blue;
--
2.40.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH-22.03 03/10] firmware/ipq-wifi: Add Google Wifi board-2.bin
From: Brian Norris
>From a manufacturer's image (version R89-13729.57.27), with appopriate
',variant=' appended to the board names:
$ .../qca-swiss-army-knife/tools/scripts/ath10k/ath10k-bdencoder \
-i ./board-google_wifi.qca4019
FileSize: 48596
FileCRC32: 3966df5d
FileMD5: d54161b0fb9e93691c4272649c37535a
BoardNames[0]: 'bus=ahb,bmi-chip-id=0,bmi-board-id=16,variant=GO_GALE'
BoardLength[0]: 12064
BoardCRC32[0]: e117f336
BoardMD5[0]: ea35e78c88a8571201da8b75edc9b881
BoardNames[1]: 'bus=ahb,bmi-chip-id=0,bmi-board-id=21,variant=GO_GALE'
BoardLength[1]: 12064
BoardCRC32[1]: 6c751ec9
BoardMD5[1]: 44cbc4ca6cb7141ba4249615f7065582
BoardNames[2]: 'bus=ahb,bmi-chip-id=0,bmi-board-id=16,variant=GO_BREEZE'
BoardLength[2]: 12064
BoardCRC32[2]: 24fba117
BoardMD5[2]: b4ac055b3ab67d5a6f5607a96af39a1f
BoardNames[3]: 'bus=ahb,bmi-chip-id=0,bmi-board-id=21,variant=GO_BREEZE'
BoardLength[3]: 12064
BoardCRC32[3]: a3e16b2a
BoardMD5[3]: 8b26cb285032314247304114b8ac50e7
Naming follows existing Google projects included in upstream board-2.bin
-- GO(ogle) prefix, an underscore (_), and the project code name, all in
caps.
Note that I only tested the "gale" model; the "breeze" model is a later
revision (same marketing name) with very small hardware changes but
otherwise using the same firmware image.
Submitted upstream here:
ath10k-firmware: QCA4019: hw1.0: Add Google Wifi BDFs
http://lists.infradead.org/pipermail/ath10k/2022-March/013465.html
https://lore.kernel.org/ath10k/YjaNGW252Ls%2FyDw8@localhost/
Signed-off-by: Brian Norris
(cherry picked from commit 331d78a90f3f11e9abfbc114a601c565899e3764)
Signed-off-by: Jan-Niklas Burfeind
---
package/firmware/ipq-wifi/Makefile | 2 ++
.../firmware/ipq-wifi/board-google_wifi.qca4019 | Bin 0 -> 48596 bytes
2 files changed, 2 insertions(+)
create mode 100644 package/firmware/ipq-wifi/board-google_wifi.qca4019
diff --git a/package/firmware/ipq-wifi/Makefile
b/package/firmware/ipq-wifi/Makefile
index be9b547cd0..74d789bdf6 100644
--- a/package/firmware/ipq-wifi/Makefile
+++ b/package/firmware/ipq-wifi/Makefile
@@ -43,6 +43,7 @@ ALLWIFIBOARDS:= \
glinet_gl-ap1300 \
glinet_gl-b2200 \
glinet_gl-s1300 \
+ google_wifi \
linksys_ea8300 \
linksys_mr8300-v0 \
luma_wrtq-329acn \
@@ -134,6 +135,7 @@ $(eval $(call
generate-ipq-wifi-package,ezviz_cs-w3-wd1200g-eup,EZVIZ CS-W3-WD12
$(eval $(call generate-ipq-wifi-package,glinet_gl-ap1300,GL.iNet GL-AP1300))
$(eval $(call generate-ipq-wifi-package,glinet_gl-b2200,GL.iNet GL-B2200))
$(eval $(call generate-ipq-wifi-package,glinet_gl-s1300,GL.iNet GL-S1300))
+$(eval $(call generate-ipq-wifi-package,google_wifi,Google WiFi))
$(eval $(call generate-ipq-wifi-package,linksys_ea8300,Linksys EA8300))
$(eval $(call generate-ipq-wifi-package,linksys_mr8300-v0,Linksys MR8300))
$(eval $(call generate-ipq-wifi-package,luma_wrtq-329acn,Luma WRTQ-329ACN))
diff --git a/package/firmware/ipq-wifi/board-google_wifi.qca4019
b/package/firmware/ipq-wifi/board-google_wifi.qca4019
new file mode 100644
index
..1c10731f0d4945c9751ed797a679619ac621b6ac
GIT binary patch
literal 48596
zcmeHQdsI_L8lNC9pKwD#J011Qu@f9@|M5G`oTGv;oONCMku~YOD)IMR>k^gZBO-d|LUHzd+eU>cJ~~6*6sGaXS=d9_vR)y$-R;U&=}@}
znfd0M*Ehd=6K*n}Kc8B(FnQsMoV3)uY
zNoUeHk>d#0>S7@H(6Q%UdL=Lj1-4mgmR{YCy_tFlqrkn;Ka2tS$mq5*ozvs9XhpYV
zg0;68&_7m#MG*nKHA5-i-3i4&(xacclaXNlF;V$pi7mItX+
zG@nAZjYaHNzJ20!QGsCDl7hV4xtDs{cQ;j*J(WBAQZLl1%9iKO`Wedg
zj}!^uZqMnRO+rF!=v_O}uy>t?FE6B~})k52RYQT+zL~ytJbVJ>m
zf_b@0ICMwdvjthO+p+d0I5bZqzjV5NUtLAPa!smbK!Ux0L)7Y^4AI5D84s|>gS+Mn
zC~@!X(Xw9a*syhpA$4_l`l%yTjdM!kRz~Js?Ag?oy<1*6eO+7c(`|Eii>tzl
z$lD-*T!A*OBMPk-G?XZ4ldoTs(S3%_j+sFo_syIHhTTFBNYwVE_=3VXH
zxMRu2_?6*V$B@<}@YMMwOmFU2`;LTTDgRx@9;pK+yP!lS7EGsna5&9*be#
z@ogn~kF^Oi%C3YDMDX!K;OFNjK>4_F0RaJl776NW-Cnxv#w*L@BAHAIf8!*vu~JE_
zM6$|1*x{MPZcCw%o@Mm%ic|1;1WsSEt@#v6XeA{}66NtSNh~rX%AsP>hG~;<%;$lP
z3l)MSh=t@rB8^NVDyp|^+wofS{w_v2WmSMiRf(ddz1^xrTI7@KYfX
zNk*z7b)jS^F`djLGgXrT$b+%p>Qi=IK({CYqy%L
z{@ANPn!-rekgC{vjk>tiSbBpn?_#N}zOjsSb~0M5$Eui-jt)i>+o=&|rk(JgUel
zEmlp$R)?G+j10RQMnsWOswmwea?#yIL>`%^%G1ptXWX4Z%qQoo=If|?qm|0(3(^%M
zl}g|4WanZTln!=|prTRY=TzKtyTG$aSvIl6Z%UNfCyr?_E??Jo}}xw#FE~gm~+|f`EP00{^aD?Z-cZSGMTZmKytS
z0szaGj2-w62#_%o0Hcr)ghSbDDO)V1JeUAlp!LrH1o-5tVmkn7KuQ20hJiN{
z7|+8bEwpC_C_c*!Qv3lXR8lF_p8!GI1H>m_`|Z!}fX_d_LzPHJ35)L{FxWRq9{*U>}g!nkw!%Xza9eq|upU)tyr^mT}i2N
zZ%gapj_wnu`ufjZ{NVb>H{EXl9zC``N`nA(4yqG2GAE(b8K^F^kvRpW&<<6
zeGqv^_&(w*Q#zPfT|oWH7Yee;1M$INF3KH}4T2ok%ki0+AqXfj$AtrLN)ds&2z
z)Twm3EHLxlOhQX)Ra)K55{?x3J5VaCJCA3bWPOM80sgdN%R6u;38-ah`zrJI9od
z%10bGu|{ewUNgY941OGSTA?Erx&-hOHjjS7rZnu6l(`9z_Y(6G_*_5u`d
Re: [PATCH 1/3] uclient-fetch: Make request_types sorted to optimize search
The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.
To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
Op 06-04-2023 om 23:39 schreef Sergey Ponomarev:
Signed-off-by: Sergey Ponomarev
---
uclient-http.c | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/uclient-http.c b/uclient-http.c
index c2bba6b..80d4495 100644
--- a/uclient-http.c
+++ b/uclient-http.c
@@ -40,11 +40,11 @@ enum auth_type {
};
enum request_type {
+ REQ_DELETE,
REQ_GET,
REQ_HEAD,
REQ_POST,
REQ_PUT,
- REQ_DELETE,
__REQ_MAX
};
@@ -57,12 +57,13 @@ enum http_state {
HTTP_STATE_ERROR,
};
+// Must be sorted aplhabeticaly
static const char * const request_types[__REQ_MAX] = {
+ [REQ_DELETE] = "DELETE",
[REQ_GET] = "GET",
[REQ_HEAD] = "HEAD",
[REQ_POST] = "POST",
[REQ_PUT] = "PUT",
- [REQ_DELETE] = "DELETE",
};
struct uclient_http {
@@ -991,11 +992,15 @@ uclient_http_set_request_type(struct uclient *cl, const
char *type)
return -1;
for (i = 0; i < ARRAY_SIZE(request_types); i++) {
- if (strcmp(request_types[i], type) != 0)
+ int c = strcmp(request_types[i], type);
+ if (c < 0) {
continue;
-
- uh->req_type = i;
- return 0;
+ } else if (c == 0) {
+ uh->req_type = i;
+ return 0;
+ } else {
+ return -1;
+ }
}
return -1;
Hi Sergey,
Seems okay, but one remark. An else branch after statements like
continue or return is not needed. Without the else the code saves
indents and becomes clearer.
So:
for (i = 0; i < ARRAY_SIZE(request_types); i++) {
- if (strcmp(request_types[i], type) != 0)
+ int c = strcmp(request_types[i], type);
+ if (c < 0) {
continue;
-
- uh->req_type = i;
- return 0;
+ }
+ if (c == 0) {
+ uh->req_type = i;
+ return 0;
+ }
+ return -1;
}
return -1;
Also it looks like the return -1 after the loop can/should be dropped as
that (iff request_types is sorted and contains > 0 elements) can never
be reached. Or the return at the end of the loop block could be dropped
as it provides a neglectible optimalisation.
Regards, Paul
--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
