Re: Switch issues and CI to GitHub
On Thu, Jan 20, 2022 at 10:42:15AM +0100, Paul Spooren wrote: >> Must confess: I was unaware of the ~16k issue body character limit... > > I discussed this with Drew (sourcehut developer) Thanks! That means there's a chance it will be documented and, if possible, fixed/improved. Incidentally, is this limit actually a problem for OpenWRT? (E.g. what % of bug reports would be affected?) >> # BROKEN HANDLING OF USER ACCOUNT DELETIONS >> >> [...] > > I think they are in a bit of a pickle there. Yes, GitHub messed up there. > If you delete everything a lot of issues miss comments and stop making > sense. Indeed. That would not be best practice at all, nor did I suggest it as a solution. > If you rename the the user account “aparcar” to a random string like > “mystery-blob-64”, other users can still “recreate” the deleted user > behavior by specifically looking for that _new_ name. Yes, best practice solution 2 is not *perfect*. But it's still a better solution than GitHub's current approach. Under solution 2, only people who already knew the original username of the contributor would be able to connect that username to the new one. (Anyone else would have to rely on those people, rather than GitHub, to make the connection.) Those people would have been aware of the original username's contributions anyway, so they would not gain any new information from GitHub as a result. (I.e. the user who had left GitHub would not suffer a reduction in privacy.) So, if GitHub followed solution 2, then GitHub would be upholding its legal responsibilities (e.g. GDPR Article 17 "right to erasure", etc). Especially if, having performed the replacement of the old name with the new one in all instances, GitHub then deleted its internal record of the connection between the old and new usernames. > Their solution seems to combine “anonymity" with usability (aka not > ruining issue discussions entirely). Alas, no. GitHub's solution combines: - *haphazard pseudonymity* (since the original username still appears in at-mentions, thereby potentially breaching GDPR Article 17, etc), and - *incomprehensibility* (both because "ghost" users can't be distinguished from each other; and because former users are referred to as "ghost" in some places and by their original usernames in others, even within the same thread). >> Worse still, because GitHub is proprietary and doesn't have a good >> way for users to report GitHub bugs or submit patches to fix them, >> bugs like this tend to go undiscussed and unfixed for years, leading >> to progressive corruption in GitHub discussions. > > They have a forum[0] and a “Discussion” thing[1] > > [0]: https://github.community OK, that's moderately new. (Just over 4 years old: https://github.blog/2017-11-01-connect-with-developers-around-the-world-on-the-github-community-forum/ .) It doesn't seem to be searchable. (At least not for some users.) Nor does it seem possible to post there without an account - and sign-up is unavailable for some users. > [1]: https://github.com/github/feedback/discussions OK, seems that's even newer. (Only just over a year old: https://github.com/github/feedback/commit/7f7cc0d6934fba7acc211f19a430b49f026e .) Again, it does not seem to be possible to post there without an account, and again, sign-up is unavailable for some users. >> # BROKEN SEARCH >> >> [...] > > This critique came up multiple times, are you aware of a better search > implementation? I’d be keen to find something better. From my > experience bugs.openwrt.org (aka flyspray) doesn’t do a much better > job here. Two counterarguments: - IME, Flyspray's search is far better than GitHub's. I haven't encountered search bugs in Flyspray like the one I kept encountering at GitHub. Can you give an example of a Flyspray search bug that is as severe? - Also, GitHub's issue/PR search bugs can't be fixed by users. Nor has Microsoft shown interest in fixing the one I mentioned. So that bug will continue impeding projects that depend on GitHub for issue-tracking or PRs. Any reasonably mature free software bug-tracker is an improvement over GitHub in this regard. >> # ACCESSIBILITY, PRIVACY, AND ETHICS PROBLEMS >> >> As previously discussed, e.g.: >> >> https://lists.openwrt.org/pipermail/openwrt-devel/2022-January/037546.html >> >> Understand that moving OpenWRT's issue-hosting to GitHub would make it >> impossible for some users to subscribe to OpenWRT's bug tracker to >> receive bug reports by email. > > I’m not familiar with Internet connectivity in Syria, Crimea and North > Korea, do you know if sr.ht and codeberg.org are reachable from over > there? The point isn't about whether governments of those territories block users from access to GitHub (or SourceHut, or Codeberg, or whatever). It's about whether the site owners (Microsoft; sr.ht LLC; Codeberg e.V.) prevent people in those territories
Re: Re: Switch issues and CI to GitHub
On Tue, Jan 25, 2022 at 09:45:52PM +0200, Sergey Ponomarev wrote: > Well, we may *speculate* and try to minimise risks but that's what I > tried to say: it's counterproductive. Avoiding unnecessary risks is productive. It's one of the ways in which projects and organisations stay afloat. > At least GH is big enough so that it can protect its users [...] Now > imagine that OpenWrt or SourceHut or whatewer website will be blocked. > Who will try to dispute? That is a mischaracterisation. AFAICT, GitHub is not (in general) blocked *by* Crimea. Rather, GitHub itself blocks users *in* Crimea (i.e. connecting from Crimea) from using *some* GitHub features: https://docs.github.com/en/github/site-policy/github-and-trade-controls#what-is-available-and-not-available GitHub is not "big enough" to protect users *from GitHub itself*, nor (given that it is headquartered in the USA) *from US Law*. > But hey, the GH CEO Nat Friedman even, while being a jew, personally > worked hard to unblock GH in Iran > https://github.blog/2021-01-05-advancing-developer-freedom-github-is-fully-available-in-iran/ Again a mischaracterisation. That issue didn't relate to GitHub being blocked *by* Iran. Rather, GitHub previously blocked users *in* Iran (i.e. connecting from Iran) from using some or all GitHub features. (BTW, Nat Friedman isn't GitHub's CEO anymore: https://www.theregister.com/2021/11/03/github_ceo_quits/ Also, I'm not sure he's Jewish, nor why that would be relevant.) > I just want to say that I personally agree with this concern and still > for me it looks like GH is at least not a worse option even from this > point of view. Codeberg and SourceHut both seem to be better than GitHub on this front. Best wishes, Sam -- A: When it messes up the order in which people normally read text. Q: When is top-posting a bad thing? () ASCII ribbon campaign. Please avoid HTML emails & proprietary /\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 5/5] ath79: mikrotik: add poe to hex poe board
Enable poe controller to hex poe board.
Signed-off-by: Oskari Lemmela
---
.../qca9557_mikrotik_routerboard-960pgs.dts | 31 +++
1 file changed, 31 insertions(+)
diff --git a/target/linux/ath79/dts/qca9557_mikrotik_routerboard-960pgs.dts
b/target/linux/ath79/dts/qca9557_mikrotik_routerboard-960pgs.dts
index 273357cf39..7748f3ec69 100644
--- a/target/linux/ath79/dts/qca9557_mikrotik_routerboard-960pgs.dts
+++ b/target/linux/ath79/dts/qca9557_mikrotik_routerboard-960pgs.dts
@@ -268,6 +268,37 @@
};
};
};
+ poe_ctrl@2 {
+ compatible = "mikrotik,poe-v3";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <2>;
+ spi-max-frequency = <210>;
+
+ port@2 {
+ compatible = "mikrotik,poeport";
+ reg = <4>;
+ label = "lan2";
+ };
+
+ port@3 {
+ compatible = "mikrotik,poeport";
+ reg = <3>;
+ label = "lan3";
+ };
+
+ port@4 {
+ compatible = "mikrotik,poeport";
+ reg = <2>;
+ label = "lan4";
+ };
+
+ port@5 {
+ compatible = "mikrotik,poeport";
+ reg = <1>;
+ label = "lan5";
+ };
+ };
};
&usb0 {
--
2.25.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 4/5] ath79: mikrotik: add poe driver
Add hwmon based driver for mikrotik POE controllers.
Signed-off-by: Oskari Lemmela
---
.../linux/ath79/files/drivers/hwmon/rbpoe.c | 256 ++
.../linux/ath79/files/drivers/hwmon/rbpoe.h | 25 ++
.../ath79/files/drivers/hwmon/rbpoeport.c | 311 ++
target/linux/ath79/mikrotik/config-default| 3 +
.../902-hwmon-support-for-mikrotik-poe.patch | 51 +++
5 files changed, 646 insertions(+)
create mode 100644 target/linux/ath79/files/drivers/hwmon/rbpoe.c
create mode 100644 target/linux/ath79/files/drivers/hwmon/rbpoe.h
create mode 100644 target/linux/ath79/files/drivers/hwmon/rbpoeport.c
create mode 100644
target/linux/ath79/patches-5.10/902-hwmon-support-for-mikrotik-poe.patch
diff --git a/target/linux/ath79/files/drivers/hwmon/rbpoe.c
b/target/linux/ath79/files/drivers/hwmon/rbpoe.c
new file mode 100644
index 00..fb5de6e6d7
--- /dev/null
+++ b/target/linux/ath79/files/drivers/hwmon/rbpoe.c
@@ -0,0 +1,256 @@
+// SPDX-License-Identifier: GPL-3.0-or-later
+/*
+ * Mikrotik POE driver
+ *
+ * Based on https://github.com/adron-s/mtpoe_ctrl
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "rbpoe.h"
+
+DECLARE_CRC8_TABLE(rbpoe_crc_table);
+
+#define MAX_PORTS 4
+
+int rb_poe_get_port_idx(struct rb_poe_data *poe, int reg)
+{
+ if (poe->data->reverse)
+ return (MAX_PORTS-reg);
+ else
+ return reg-1;
+}
+EXPORT_SYMBOL(rb_poe_get_port_idx);
+
+int rb_poe_write_cmd(struct rb_poe_data *poe, u16 *resp, u8 cmd, u8 arg1, u8
arg2)
+{
+ int ret;
+ u8 tx[4];
+ u8 rx[6];
+ u8 crc, retries;
+
+ struct spi_transfer xfers[] = {
+ {
+ .tx_buf = tx,
+ .len = 4,
+ .delay.value = 10,
+ .delay.unit = SPI_DELAY_UNIT_USECS,
+ },
+ {
+ .rx_buf = rx,
+ .len = 6,
+ },
+ };
+
+ mutex_lock(&poe->lock);
+
+ tx[0] = cmd;
+ tx[1] = arg1;
+ tx[2] = arg2;
+ tx[3] = crc8(rbpoe_crc_table, tx, 3, 0);
+
+ for (retries = 0; retries < MAX_RETRIES; retries++) {
+ ret = spi_sync_transfer(poe->spi, xfers, ARRAY_SIZE(xfers));
+ if (ret < 0) {
+ dev_err(&poe->spi->dev, "SPI transfer error");
+ goto out;
+ }
+
+ if (rx[1] != cmd) {
+ ndelay(13);
+ continue;
+ }
+
+ crc = crc8(rbpoe_crc_table, rx+1, 3, 0);
+
+ if (rx[4] != crc && rx[5] != crc)
+ continue;
+
+ resp[0] = rx[2] << 8 | rx[3];
+ goto out;
+ }
+out:
+ mutex_unlock(&poe->lock);
+ return ret;
+}
+EXPORT_SYMBOL(rb_poe_write_cmd);
+
+static int rb_poe_read_version(struct rb_poe_data *data)
+{
+ int ret;
+ u16 vers;
+
+ ret = rb_poe_write_cmd(data, &vers, 0x41, 0, 0);
+ if (ret < 0)
+ return ret;
+ return vers;
+}
+
+int rb_poe_read_voltage(struct rb_poe_data *data)
+{
+ int ret;
+ u16 val;
+
+ ret = rb_poe_write_cmd(data, &val, 0x42, 0, 0);
+ if (ret < 0)
+ return ret;
+ return val * data->data->volt_lsb;
+}
+EXPORT_SYMBOL(rb_poe_read_voltage);
+
+static int rb_poe_read_temperature(struct rb_poe_data *data)
+{
+ int ret;
+ u16 val;
+
+ ret = rb_poe_write_cmd(data, &val, 0x43, 0, 0);
+ if (ret < 0)
+ return ret;
+ return (val * data->data->temp_lsb) - data->data->temp_offset;
+}
+
+/* sysfs attributes */
+static ssize_t temp_input_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct rb_poe_data *data = dev_get_drvdata(dev);
+ int val;
+
+ if (IS_ERR(data))
+ return -ENODATA;
+
+ val = rb_poe_read_temperature(data);
+ if (val < 0)
+ return -ENODATA;
+
+ return sprintf(buf, "%d\n", val);
+}
+
+static ssize_t in_input_show(struct device *dev,
+struct device_attribute *attr, char *buf)
+{
+ struct rb_poe_data *data = dev_get_drvdata(dev);
+ int val;
+
+ if (IS_ERR(data))
+ return -ENODATA;
+
+ val = rb_poe_read_voltage(data);
+ if (val < 0)
+ return -ENODATA;
+
+ return sprintf(buf, "%d\n", val);
+}
+
+static SENSOR_DEVICE_ATTR_RO(temp1_input, temp_input, 0);
+static SENSOR_DEVICE_ATTR_RO(in0_input, in_input, 4);
+
+static struct attribute *rb_poe_attrs[] = {
+ &sensor_dev_attr_temp1_input.dev_attr.attr,
+ &sensor_dev_attr_in0_input.dev_attr.attr,
+ NULL
+};
+
+ATTRIBUTE_GROUPS(rb_poe);
+
+static int rb_poe_probe(struct spi_device *spi)
+{
[PATCH 2/5] ath79: add support for MikroTik RouterBOARD 960PGS (hEx PoE)
This patch adds support for the MikroTik RouterBOARD 960PGS (hEx PoE)
router. The device has a USB 2.0 port and a SFP port for adding optical
fiber connectivity. The ports 2-5 can power other PoE capable devices
with the same voltage as applied to the unit.
Specifications:
- SoC: Qualcomm Atheros QCA9557
- Flash: 16 MB (SPI)
- RAM: 128 MB
- 1x Ethernet SFP: 1000
- 1x Ethernet RJ45: 10/100/1000 port with passive POE in
- 4x Ethernet RJ45: 10/100/1000 ports with 802.3af/at PoE out
- 1x USB 2.0 host port
- 1x reset button
See https://mikrotik.com/product/RB960PGS for more details.
Flashing:
TFTP boot initramfs image and then perform sysupgrade. Follow common
MikroTik procedure as in https://openwrt.org/toh/mikrotik/common.
Signed-off-by: Oskari Lemmela
---
.../qca9557_mikrotik_routerboard-960pgs.dts | 279 ++
target/linux/ath79/image/mikrotik.mk | 9 +
.../base-files/etc/board.d/02_network | 14 +
.../lib/preinit/10_rename_interfaces.sh | 11 +
4 files changed, 313 insertions(+)
create mode 100644
target/linux/ath79/dts/qca9557_mikrotik_routerboard-960pgs.dts
create mode 100644
target/linux/ath79/mikrotik/base-files/lib/preinit/10_rename_interfaces.sh
diff --git a/target/linux/ath79/dts/qca9557_mikrotik_routerboard-960pgs.dts
b/target/linux/ath79/dts/qca9557_mikrotik_routerboard-960pgs.dts
new file mode 100644
index 00..273357cf39
--- /dev/null
+++ b/target/linux/ath79/dts/qca9557_mikrotik_routerboard-960pgs.dts
@@ -0,0 +1,279 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+
+#include "qca955x.dtsi"
+
+#include
+#include
+
+/ {
+ compatible = "mikrotik,routerboard-960pgs", "qca,qca9557";
+ model = "MikroTik RouterBOARD 960PGS";
+
+ aliases {
+ serial0 = &uart;
+ };
+
+ gpio_export {
+ compatible = "gpio-export";
+ #size-cells = <0>;
+
+ buzzer {
+ /* Beeper requires PWM for frequency selection */
+ gpio-export,name = "buzzer";
+ gpio-export,output = <0>;
+ gpios = <&gpio 4 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ i2c: i2c {
+ compatible = "i2c-gpio";
+
+ i2c-gpio,delay-us = <5>;
+ i2c-gpio,timeout-ms = <1>;
+ sda-gpios = <&gpio 18 (GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN)>;
+ scl-gpios = <&gpio 19 (GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN)>;
+
+ sfp_eeprom@50 {
+ compatible = "at,24c04";
+ reg = <0x50>;
+ };
+
+ sfp_eeprom@51 {
+ compatible = "at,24c04";
+ reg = <0x51>;
+ };
+ };
+
+ keys {
+ compatible = "gpio-keys";
+
+ reset {
+ debounce-interval = <60>;
+ gpios = <&gpio 20 GPIO_ACTIVE_LOW>;
+ label = "reset";
+ linux,code = ;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ led_user: user {
+ label = "green:user";
+ gpios = <&gpio 12 GPIO_ACTIVE_LOW>;
+ };
+
+ led_sfp: sfp {
+ label = "green:sfp";
+ gpios = <&gpio 2 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ sfp1: sfp {
+ compatible = "sff,sfp";
+
+ i2c-bus = <&i2c>;
+ maximum-power-milliwatt = <1000>;
+ los-gpios = <&gpio 21 GPIO_ACTIVE_HIGH>;
+ mod-def0-gpios = <&gpio 17 GPIO_ACTIVE_LOW>;
+ tx-disable-gpios = <&gpio 16 GPIO_ACTIVE_HIGH>;
+ };
+
+ reg_usb_vbus {
+ compatible = "regulator-fixed";
+ regulator-always-on;
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ regulator-name = "usb_vbus";
+ gpio = <&gpio 13 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+};
+
+&mdio0 {
+ status = "okay";
+
+ switch@0 {
+ compatible = "qca,qca8337";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ reg = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ label = "cpu";
+ ethernet = <ð0>;
+ phy-mode = "rgmii-id";
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
+ };
+
+ port@1 {
+
[PATCH 3/5] ath79: fix ar934x spi driver delays
Backport spi driver delay fixes from the 5.17-rc1 kernel.
Signed-off-by: Oskari Lemmela
---
...-ar934x-fix-transfer-and-word-delays.patch | 32 +
...3-v5.17-spi-ar934x-fix-transfer-size.patch | 67 +++
2 files changed, 99 insertions(+)
create mode 100644
target/linux/ath79/patches-5.10/402-v5.17-spi-ar934x-fix-transfer-and-word-delays.patch
create mode 100644
target/linux/ath79/patches-5.10/403-v5.17-spi-ar934x-fix-transfer-size.patch
diff --git
a/target/linux/ath79/patches-5.10/402-v5.17-spi-ar934x-fix-transfer-and-word-delays.patch
b/target/linux/ath79/patches-5.10/402-v5.17-spi-ar934x-fix-transfer-and-word-delays.patch
new file mode 100644
index 00..16aad7734a
--- /dev/null
+++
b/target/linux/ath79/patches-5.10/402-v5.17-spi-ar934x-fix-transfer-and-word-delays.patch
@@ -0,0 +1,32 @@
+From c70282457c380db7deb57c81a6894debc8f88efa Mon Sep 17 00:00:00 2001
+From: Oskari Lemmela
+Date: Wed, 22 Dec 2021 07:59:58 +0200
+Subject: [PATCH] spi: ar934x: fix transfer and word delays
+
+Add missing delay between transferred messages and words.
+
+Signed-off-by: Oskari Lemmela
+Link: https://lore.kernel.org/r/20211222055958.1383233-3-osk...@lemmela.net
+Signed-off-by: Mark Brown
+---
+ drivers/spi/spi-ar934x.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/drivers/spi/spi-ar934x.c b/drivers/spi/spi-ar934x.c
+index def32e0aaefe..e1b64e35900c 100644
+--- a/drivers/spi/spi-ar934x.c
b/drivers/spi/spi-ar934x.c
+@@ -137,8 +137,10 @@ static int ar934x_spi_transfer_one_message(struct
spi_controller *master,
+ reg >>= 8;
+ }
+ }
++ spi_delay_exec(&t->word_delay, t);
+ }
+ m->actual_length += t->len;
++ spi_transfer_delay_exec(t);
+ }
+
+ msg_done:
+--
+2.25.1
+
diff --git
a/target/linux/ath79/patches-5.10/403-v5.17-spi-ar934x-fix-transfer-size.patch
b/target/linux/ath79/patches-5.10/403-v5.17-spi-ar934x-fix-transfer-size.patch
new file mode 100644
index 00..361194e8ee
--- /dev/null
+++
b/target/linux/ath79/patches-5.10/403-v5.17-spi-ar934x-fix-transfer-size.patch
@@ -0,0 +1,67 @@
+From ebe33e5a98dcf14a9630845f3f10c193584ac054 Mon Sep 17 00:00:00 2001
+From: Oskari Lemmela
+Date: Wed, 22 Dec 2021 07:59:57 +0200
+Subject: [PATCH] spi: ar934x: fix transfer size
+
+If bits_per_word is configured, transfer only word amount
+of data per iteration.
+
+Signed-off-by: Oskari Lemmela
+Link: https://lore.kernel.org/r/20211222055958.1383233-2-osk...@lemmela.net
+Signed-off-by: Mark Brown
+---
+ drivers/spi/spi-ar934x.c | 16 +++-
+ 1 file changed, 11 insertions(+), 5 deletions(-)
+
+diff --git a/drivers/spi/spi-ar934x.c b/drivers/spi/spi-ar934x.c
+index e1b64e35900c..ec7250c4c810 100644
+--- a/drivers/spi/spi-ar934x.c
b/drivers/spi/spi-ar934x.c
+@@ -82,7 +82,7 @@ static int ar934x_spi_transfer_one_message(struct
spi_controller *master,
+ struct spi_device *spi = m->spi;
+ unsigned long trx_done, trx_cur;
+ int stat = 0;
+- u8 term = 0;
++ u8 bpw, term = 0;
+ int div, i;
+ u32 reg;
+ const u8 *tx_buf;
+@@ -90,6 +90,11 @@ static int ar934x_spi_transfer_one_message(struct
spi_controller *master,
+
+ m->actual_length = 0;
+ list_for_each_entry(t, &m->transfers, transfer_list) {
++ if (t->bits_per_word >= 8 && t->bits_per_word < 32)
++ bpw = t->bits_per_word >> 3;
++ else
++ bpw = 4;
++
+ if (t->speed_hz)
+ div = ar934x_spi_clk_div(sp, t->speed_hz);
+ else
+@@ -105,10 +110,10 @@ static int ar934x_spi_transfer_one_message(struct
spi_controller *master,
+ iowrite32(reg, sp->base + AR934X_SPI_REG_CTRL);
+ iowrite32(0, sp->base + AR934X_SPI_DATAOUT);
+
+- for (trx_done = 0; trx_done < t->len; trx_done += 4) {
++ for (trx_done = 0; trx_done < t->len; trx_done += bpw) {
+ trx_cur = t->len - trx_done;
+- if (trx_cur > 4)
+- trx_cur = 4;
++ if (trx_cur > bpw)
++ trx_cur = bpw;
+ else if (list_is_last(&t->transfer_list, &m->transfers))
+ term = 1;
+
+@@ -193,7 +198,8 @@ static int ar934x_spi_probe(struct platform_device *pdev)
+ ctlr->mode_bits = SPI_LSB_FIRST;
+ ctlr->setup = ar934x_spi_setup;
+ ctlr->transfer_one_message = ar934x_spi_transfer_one_message;
+- ctlr->bits_per_word_mask = SPI_BPW_MASK(8);
++ ctlr->bits_per_word_mask = SPI_BPW_MASK(32) | SPI_BPW_MASK(24) |
++ SPI_BPW_MASK(16) | SPI_BPW_MASK(8);
+ ctlr->dev.of_node = pdev->dev.of_node;
+ ctlr->num_chipselect = 3;
+
+--
+2.25.1
+
--
2.25.1
___
[PATCH 1/5] ath79: mikrotik: change to qca8k DSA driver
Current mikrotik ath79 devices do not use switch drivers. Enable the QCA8K driver and disable the old AR8126 phy. Signed-off-by: Oskari Lemmela --- target/linux/ath79/mikrotik/config-default | 4 1 file changed, 4 insertions(+) diff --git a/target/linux/ath79/mikrotik/config-default b/target/linux/ath79/mikrotik/config-default index 2ff8a14f1d..175c4fac1f 100644 --- a/target/linux/ath79/mikrotik/config-default +++ b/target/linux/ath79/mikrotik/config-default @@ -1,3 +1,5 @@ +CONFIG_AR8216_PHY=n +CONFIG_AR8216_PHY_LEDS=n CONFIG_CRC16=y CONFIG_CRYPTO_DEFLATE=y CONFIG_GPIO_LATCH=y @@ -27,6 +29,8 @@ CONFIG_MTD_UBI_BLOCK=y CONFIG_MTD_UBI_WL_THRESHOLD=4096 CONFIG_MTD_UBI_BEB_LIMIT=20 CONFIG_NET_DSA=y +CONFIG_NET_DSA_QCA8K=y +CONFIG_NET_DSA_TAG_QCA=y CONFIG_NET_SWITCHDEV=y CONFIG_PCI_AR71XX=y CONFIG_PHY_AR7100_USB=y -- 2.25.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 0/5] ath79: add support for routerboard 960pgs
This patchset converts the ath79 mikrotik to use the qca8k DSA driver. Once a generic ath79 target has been converted to a DSA, the change is no longer required. The SPI controller in the ar934x does not handle delays correctly. Backport SPI driver delay fixes from the 5.17-rc1 kernel. These fixes are required for the poe controller. Oskari Lemmela (5): ath79: mikrotik: change to qca8k DSA driver ath79: add support for MikroTik RouterBOARD 960PGS (hEx PoE) ath79: fix ar934x spi driver delays ath79: mikrotik: add poe driver ath79: mikrotik: add poe to hex poe board .../qca9557_mikrotik_routerboard-960pgs.dts | 310 + .../linux/ath79/files/drivers/hwmon/rbpoe.c | 256 ++ .../linux/ath79/files/drivers/hwmon/rbpoe.h | 25 ++ .../ath79/files/drivers/hwmon/rbpoeport.c | 311 ++ target/linux/ath79/image/mikrotik.mk | 9 + .../base-files/etc/board.d/02_network | 14 + .../lib/preinit/10_rename_interfaces.sh | 11 + target/linux/ath79/mikrotik/config-default| 7 + ...-ar934x-fix-transfer-and-word-delays.patch | 32 ++ ...3-v5.17-spi-ar934x-fix-transfer-size.patch | 67 .../902-hwmon-support-for-mikrotik-poe.patch | 51 +++ 11 files changed, 1093 insertions(+) create mode 100644 target/linux/ath79/dts/qca9557_mikrotik_routerboard-960pgs.dts create mode 100644 target/linux/ath79/files/drivers/hwmon/rbpoe.c create mode 100644 target/linux/ath79/files/drivers/hwmon/rbpoe.h create mode 100644 target/linux/ath79/files/drivers/hwmon/rbpoeport.c create mode 100644 target/linux/ath79/mikrotik/base-files/lib/preinit/10_rename_interfaces.sh create mode 100644 target/linux/ath79/patches-5.10/402-v5.17-spi-ar934x-fix-transfer-and-word-delays.patch create mode 100644 target/linux/ath79/patches-5.10/403-v5.17-spi-ar934x-fix-transfer-size.patch create mode 100644 target/linux/ath79/patches-5.10/902-hwmon-support-for-mikrotik-poe.patch -- 2.25.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] toolchain/gcc: set dialects for each version
On Tue, Jan 25, 2022 at 9:06 AM Stijn Tintel wrote: > > GCC has an option "-std=" to set the language standard for C and C++. > Newer GCC versions sometimes switch to newer standards by default. This > has the potential to break the OpenWrt toolchain build whenever a distro > introduces a new GCC version that uses a newer dialect by default. > > Let's set the default dialects used for each of the GCC versions we > support, to avoid these toolchain build failures in the future. > > Signed-off-by: Stijn Tintel > --- > toolchain/gcc/common.mk | 8 > 1 file changed, 8 insertions(+) > > diff --git a/toolchain/gcc/common.mk b/toolchain/gcc/common.mk > index bef4fa37f8..3e31a139cd 100644 > --- a/toolchain/gcc/common.mk > +++ b/toolchain/gcc/common.mk > @@ -29,14 +29,20 @@ PKG_SOURCE_URL:=@GNU/gcc/gcc-$(PKG_VERSION) > PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz > > ifeq ($(PKG_VERSION),8.4.0) > + C_DIALECT=-std=gnu17 > + CXX_DIALECT=-std=gnu++14 >PKG_HASH:=e30a6e52d10e1f27ed55104ad233c30bd1e99cfb5ff98ab022dc941edd1b2dd4 > endif > > ifeq ($(PKG_VERSION),10.3.0) > + C_DIALECT=-std=gnu17 > + CXX_DIALECT=-std=gnu++14 >PKG_HASH:=64f404c1a650f27fc33da242e1f2df54952e3963a49e06e73f6940f3223ac344 > endif > > ifeq ($(PKG_VERSION),11.2.0) > + C_DIALECT=-std=gnu17 > + CXX_DIALECT=-std=gnu++17 I mentioned this on IRC. GCC8 is the first version to support std=c++17. prereq-build says GCC6 which supports c++1z. >PKG_HASH:=d08edc536b54c372a1010ff6619dd274c0f1603aa49212ba20f7aa2cda36fa8b > endif > > @@ -86,6 +92,8 @@ GCC_CONFIGURE:= \ > CFLAGS="-O2 -fbracket-depth=512 -pipe" \ > CXXFLAGS="-O2 -fbracket-depth=512 -pipe" \ > ) \ > + CFLAGS="$(CFLAGS) $(C_DIALECT)" \ > + CXXFLAGS="$(CXXFLAGS) $(CXX_DIALECT)" \ > $(HOST_SOURCE_DIR)/configure \ > --with-bugurl=$(BUGURL) \ > --with-pkgversion="$(PKGVERSION)" \ > -- > 2.34.1 > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Re: Switch issues and CI to GitHub
Well, we may *speculate* and try to minimise risks but that's what I tried to say: it's counterproductive. For example, did you know that GitHub was blocked in Ukraine for one day? As far as I remember, literally some small court in a village said to block four hundred sites with GH and LiveJournal among them just because there was some gist with links to a cryptocurrency exchange. And Ukrainian laws allow the use of crypto currencies and don't allow anyone to block anything but there was a funny formulation like "seize intellectual property rights that Internet users have when using web resources". That's totally insane and no ISP hadn't blocked anything. That was quickly undone and maybe the judge was punished but still, who might predict this? At least GH is big enough so that it can protect its users and even Ukrainian ministers were worried about this. There was a story when Iranian with Canadian citizenship was blocked in GH when he visited his parents. But hey, the GH CEO Nat Friedman even, while being a jew, personally worked hard to unblock GH in Iran https://github.blog/2021-01-05-advancing-developer-freedom-github-is-fully-available-in-iran/ Now imagine that OpenWrt or SourceHut or whatewer website will be blocked. Who will try to dispute? I'll ask a developer from Crimea if GH is blocked there but I just tried to say that Crimea is a very popular destination unlike North Korea and thouthands of developers are visiting it and not only from Ukraine and Russia. That's a health resort and many astmatic people have to be there periodically because that's the cheapest way for them to survive. The problem here is that you may be blocked *unexpectedly* even before thinking about using VPN. I just want to say that I personally agree with this concern and still for me it looks like GH is at least not a worse option even from this point of view. Also any country which tries to protect its sovereignty, morality or lifestyle from outside influence should limit access from the entire internet itself. And ironically users may need OpenWrt more than others. But I hope that can be simply resolved by mirroring of binaries downloads and local forums. But participating in discussions and contribution still may be a problem but there is not a single good solution for this. At least we know that for core developers and maintainers that's not a problem at all. It's fair to use GH or any other hosting even if it will be accessible only from Germany :) On Tue, 25 Jan 2022 at 20:31, Sam Kuper wrote: > > On Tue, Jan 25, 2022 at 06:56:04PM +0200, Sergey Ponomarev wrote: > > Speaking about GitHub and access to it from sanctioned territories > > this is a really big concern. [..] > > Thank you for corroborating that concern. > > Some news reports, think-tank analysis, and legal guidance providers > suggest the current sanctions will be extended in unspecified ways, if > conflict escalates further in the region. If that happens, I would > *speculate* that for instance GitHub might end up blocking Russia. > > "Washington is trying to maintain transatlantic unity to build a > credible threat of sanctions as a deterrence against Moscow." > > > https://www.theguardian.com/world/2022/jan/25/us-uk-and-europe-totally-united-in-the-face-of-russia-threat-to-ukraine-biden-says > > > "If [Russia] launches a [new] military assault against Ukraine, > Western sanctions should target the Russian economy in a major way. > ... If the Kremlin choses lesser forms of aggression, consider > strong sanctions anyway ... the United States and the European > Union (EU) should use all options at their disposal, including > intensified export controls." > > > https://www.atlanticcouncil.org/blogs/new-atlanticist/what-if-russia-invades-ukraine-again-consider-these-options-for-sanctions-escalation/ > > > "In order to prepare [for possible imminent sanctions, Western] > businesses should do the following: > > - Identify all of their activities which relate to Russia and/or > Russian counterparties and/or Russian origin goods > > - Review (and expand if necessary) existing KYC to identify all > Russian counterparties and their beneficial owners ..." > > > https://www.lexology.com/library/detail.aspx?g=839e7b81-ee92-40bb-87ca-4d9e96eeccb8 > > > > > But let's be honest: that's not only GitHub but any website in the US > > or in NATO countries, > > I may be wrong, but I think some code/issue-hosting sites, including in > the USA or in other NATO jurisdictions, are accessible from sanctioned > territories. > > Potentially, that means SourceHut or CodeBerg would be better solutions > than GitHub in this (and other) respects. Certainly, I could find > nothing in their terms and conditions to indicate that they block users > by territory: > > https://codeberg.org/codeberg/org/src/branch/main/TermsOfUse.md > > https://codeberg.org/codeberg/org/src/branch/main/PrivacyPol
Re: Re: Switch issues and CI to GitHub
On Tue, Jan 25, 2022 at 06:56:04PM +0200, Sergey Ponomarev wrote: > Speaking about GitHub and access to it from sanctioned territories > this is a really big concern. [..] Thank you for corroborating that concern. Some news reports, think-tank analysis, and legal guidance providers suggest the current sanctions will be extended in unspecified ways, if conflict escalates further in the region. If that happens, I would *speculate* that for instance GitHub might end up blocking Russia. "Washington is trying to maintain transatlantic unity to build a credible threat of sanctions as a deterrence against Moscow." https://www.theguardian.com/world/2022/jan/25/us-uk-and-europe-totally-united-in-the-face-of-russia-threat-to-ukraine-biden-says "If [Russia] launches a [new] military assault against Ukraine, Western sanctions should target the Russian economy in a major way. ... If the Kremlin choses lesser forms of aggression, consider strong sanctions anyway ... the United States and the European Union (EU) should use all options at their disposal, including intensified export controls." https://www.atlanticcouncil.org/blogs/new-atlanticist/what-if-russia-invades-ukraine-again-consider-these-options-for-sanctions-escalation/ "In order to prepare [for possible imminent sanctions, Western] businesses should do the following: - Identify all of their activities which relate to Russia and/or Russian counterparties and/or Russian origin goods - Review (and expand if necessary) existing KYC to identify all Russian counterparties and their beneficial owners ..." https://www.lexology.com/library/detail.aspx?g=839e7b81-ee92-40bb-87ca-4d9e96eeccb8 > But let's be honest: that's not only GitHub but any website in the US > or in NATO countries, I may be wrong, but I think some code/issue-hosting sites, including in the USA or in other NATO jurisdictions, are accessible from sanctioned territories. Potentially, that means SourceHut or CodeBerg would be better solutions than GitHub in this (and other) respects. Certainly, I could find nothing in their terms and conditions to indicate that they block users by territory: https://codeberg.org/codeberg/org/src/branch/main/TermsOfUse.md https://codeberg.org/codeberg/org/src/branch/main/PrivacyPolicy.md https://codeberg.org/codeberg/org/src/branch/main/en/bylaws.md https://codeberg.org/codeberg/org/src/branch/main/Imprint.md https://man.sr.ht/terms.md https://man.sr.ht/privacy.md (Basically, IIUC - IANAL - sanctions are intended as deterrents to commercial activities. Non-profit or volunteer activities are less affected. I would *hope* that humanitarian activities - like developing free software that extends the usable life of computer and network infrastructure - would remain unaffected by sanctions, except insofar as commercial US hosts like GitHub might be barred from involvement.) I will write to SourceHut and CodeBerg to ask whether they block users by territory. Sam -- A: When it messes up the order in which people normally read text. Q: When is top-posting a bad thing? () ASCII ribbon campaign. Please avoid HTML emails & proprietary /\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] uqmi: add support for get operating mode
Currently only the set operation is supported.
Add support for getting the current operating mode.
Signed-off-by: Henrik Ginstmark
Signed-off-by: Oskari Lemmela
---
commands-dms.c | 46 +-
commands-dms.h | 2 ++
2 files changed, 35 insertions(+), 13 deletions(-)
diff --git a/commands-dms.c b/commands-dms.c
index 954daca..59648fb 100644
--- a/commands-dms.c
+++ b/commands-dms.c
@@ -27,6 +27,17 @@ static struct {
char* puk;
} dms_req_data;
+const char *oper_modes[] = {
+ [QMI_DMS_OPERATING_MODE_ONLINE] = "online",
+ [QMI_DMS_OPERATING_MODE_LOW_POWER] = "low_power",
+ [QMI_DMS_OPERATING_MODE_FACTORY_TEST] = "factory_test",
+ [QMI_DMS_OPERATING_MODE_OFFLINE] = "offline",
+ [QMI_DMS_OPERATING_MODE_RESET] = "reset",
+ [QMI_DMS_OPERATING_MODE_SHUTTING_DOWN] = "shutting_down",
+ [QMI_DMS_OPERATING_MODE_PERSISTENT_LOW_POWER] = "persistent_low_power",
+ [QMI_DMS_OPERATING_MODE_MODE_ONLY_LOW_POWER] = "mode_only_low_power",
+};
+
static void cmd_dms_get_capabilities_cb(struct qmi_dev *qmi, struct
qmi_request *req, struct qmi_msg *msg)
{
void *t, *networks;
@@ -375,30 +386,39 @@ cmd_dms_reset_prepare(struct qmi_dev *qmi, struct
qmi_request *req, struct qmi_m
return QMI_CMD_REQUEST;
}
+static void
+cmd_dms_get_operating_mode_cb(struct qmi_dev *qmi, struct qmi_request *req,
struct qmi_msg *msg)
+{
+ struct qmi_dms_get_operating_mode_response res;
+
+ qmi_parse_dms_get_operating_mode_response(msg, &res);
+ if (res.data.mode < ARRAY_SIZE(oper_modes))
+ blobmsg_add_string(&status, NULL, oper_modes[res.data.mode]);
+ else
+ blobmsg_add_string(&status, NULL, "unknown");
+}
+
+static enum qmi_cmd_result
+cmd_dms_get_operating_mode_prepare(struct qmi_dev *qmi, struct qmi_request
*req, struct qmi_msg *msg, char *arg)
+{
+ qmi_set_dms_get_operating_mode_request(msg);
+ return QMI_CMD_REQUEST;
+}
+
#define cmd_dms_set_operating_mode_cb no_cb
static enum qmi_cmd_result
cmd_dms_set_operating_mode_prepare(struct qmi_dev *qmi, struct qmi_request
*req, struct qmi_msg *msg, char *arg)
{
- static const char *modes[] = {
- [QMI_DMS_OPERATING_MODE_ONLINE] = "online",
- [QMI_DMS_OPERATING_MODE_LOW_POWER] = "low_power",
- [QMI_DMS_OPERATING_MODE_FACTORY_TEST] = "factory_test",
- [QMI_DMS_OPERATING_MODE_OFFLINE] = "offline",
- [QMI_DMS_OPERATING_MODE_RESET] = "reset",
- [QMI_DMS_OPERATING_MODE_SHUTTING_DOWN] = "shutting_down",
- [QMI_DMS_OPERATING_MODE_PERSISTENT_LOW_POWER] =
"persistent_low_power",
- [QMI_DMS_OPERATING_MODE_MODE_ONLY_LOW_POWER] =
"mode_only_low_power",
- };
static struct qmi_dms_set_operating_mode_request sreq = {
QMI_INIT(mode, QMI_DMS_OPERATING_MODE_ONLINE),
};
int i;
- for (i = 0; i < ARRAY_SIZE(modes); i++) {
- if (!modes[i])
+ for (i = 0; i < ARRAY_SIZE(oper_modes); i++) {
+ if (!oper_modes[i])
continue;
- if (strcmp(arg, modes[i]) != 0)
+ if (strcmp(arg, oper_modes[i]) != 0)
continue;
sreq.data.mode = i;
diff --git a/commands-dms.h b/commands-dms.h
index eea8308..68c004a 100644
--- a/commands-dms.h
+++ b/commands-dms.h
@@ -37,6 +37,7 @@
__uqmi_command(dms_get_imsi, get-imsi, no, QMI_SERVICE_DMS), \
__uqmi_command(dms_get_imei, get-imei, no, QMI_SERVICE_DMS), \
__uqmi_command(dms_get_msisdn, get-msisdn, no, QMI_SERVICE_DMS), \
+ __uqmi_command(dms_get_operating_mode, get-device-operating-mode, no,
QMI_SERVICE_DMS), \
__uqmi_command(dms_set_operating_mode, set-device-operating-mode,
required, QMI_SERVICE_DMS), \
__uqmi_command(dms_reset, reset-dms, no, QMI_SERVICE_DMS), \
__uqmi_command(dms_set_fcc_authentication, fcc-auth, no,
QMI_SERVICE_DMS) \
@@ -67,6 +68,7 @@
" --get-imei: Get International Mobile
Equipment ID\n" \
" --get-msisdn: Get the MSISDN (telephone
number)\n" \
" --reset-dms: Reset the DMS service\n" \
+ " --get-device-operating-mode Get the device operating
mode\n" \
" --set-device-operating-modeSet the device operating
mode\n" \
"(modes: online, low_power,
factory_test, offline\n" \
" reset, shutting_down,
persistent_low_power,\n" \
--
2.25.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] util-linux: add lslocks
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 --- This change adds the "lslocks" utility from util-linux. Signed-off-by: Roman Azarenko --- package/utils/util-linux/Makefile | 16 1 file changed, 16 insertions(+) diff --git a/package/utils/util-linux/Makefile b/package/utils/util-linux/Makefile index ded653e..bf8a67f 100644 --- a/package/utils/util-linux/Makefile +++ b/package/utils/util-linux/Makefile @@ -317,6 +317,16 @@ define Package/lscpu/description lscpu displays information about the CPU architecture endef +define Package/lslocks +$(call Package/util-linux/Default) + TITLE:=list local system locks + DEPENDS:= +libmount +libsmartcols +endef + +define Package/lslocks/description + lslocks lists information about all the currently held file locks in a Linux system +endef + define Package/more $(call Package/util-linux/Default) TITLE:=filter for paging through text one screenful at a time @@ -704,6 +714,11 @@ define Package/lscpu/install $(INSTALL_BIN) $(PKG_INSTALL_DIR)/usr/bin/lscpu $(1)/usr/bin/ endef +define Package/lslocks/install + $(INSTALL_DIR) $(1)/usr/bin + $(INSTALL_BIN) $(PKG_INSTALL_DIR)/usr/bin/lslocks $(1)/usr/bin/ +endef + define Package/more/install $(INSTALL_DIR) $(1)/usr/bin $(INSTALL_BIN) $(PKG_INSTALL_DIR)/usr/bin/more $(1)/usr/bin/ @@ -831,6 +846,7 @@ $(eval $(call BuildPackage,look)) $(eval $(call BuildPackage,losetup)) $(eval $(call BuildPackage,lsblk)) $(eval $(call BuildPackage,lscpu)) +$(eval $(call BuildPackage,lslocks)) $(eval $(call BuildPackage,more)) $(eval $(call BuildPackage,mcookie)) $(eval $(call BuildPackage,mount-utils)) -- 2.35.0 --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] toolchain/gcc: set dialects for each version
GCC has an option "-std=" to set the language standard for C and C++. Newer GCC versions sometimes switch to newer standards by default. This has the potential to break the OpenWrt toolchain build whenever a distro introduces a new GCC version that uses a newer dialect by default. Let's set the default dialects used for each of the GCC versions we support, to avoid these toolchain build failures in the future. Signed-off-by: Stijn Tintel --- toolchain/gcc/common.mk | 8 1 file changed, 8 insertions(+) diff --git a/toolchain/gcc/common.mk b/toolchain/gcc/common.mk index bef4fa37f8..3e31a139cd 100644 --- a/toolchain/gcc/common.mk +++ b/toolchain/gcc/common.mk @@ -29,14 +29,20 @@ PKG_SOURCE_URL:=@GNU/gcc/gcc-$(PKG_VERSION) PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz ifeq ($(PKG_VERSION),8.4.0) + C_DIALECT=-std=gnu17 + CXX_DIALECT=-std=gnu++14 PKG_HASH:=e30a6e52d10e1f27ed55104ad233c30bd1e99cfb5ff98ab022dc941edd1b2dd4 endif ifeq ($(PKG_VERSION),10.3.0) + C_DIALECT=-std=gnu17 + CXX_DIALECT=-std=gnu++14 PKG_HASH:=64f404c1a650f27fc33da242e1f2df54952e3963a49e06e73f6940f3223ac344 endif ifeq ($(PKG_VERSION),11.2.0) + C_DIALECT=-std=gnu17 + CXX_DIALECT=-std=gnu++17 PKG_HASH:=d08edc536b54c372a1010ff6619dd274c0f1603aa49212ba20f7aa2cda36fa8b endif @@ -86,6 +92,8 @@ GCC_CONFIGURE:= \ CFLAGS="-O2 -fbracket-depth=512 -pipe" \ CXXFLAGS="-O2 -fbracket-depth=512 -pipe" \ ) \ + CFLAGS="$(CFLAGS) $(C_DIALECT)" \ + CXXFLAGS="$(CXXFLAGS) $(CXX_DIALECT)" \ $(HOST_SOURCE_DIR)/configure \ --with-bugurl=$(BUGURL) \ --with-pkgversion="$(PKGVERSION)" \ -- 2.34.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Re: Switch issues and CI to GitHub
+1 for a GitHub +1 for GitLab +1 for a self hosting GitLab +1 for joining to any existing OS hosting -1 for plain emails. As a contributor but not a core developer I would like to ask. Please tell me honestly. Is the send-patch approach just an IQ test? Because I failed it :) My few patches that I sent are just lost somewhere. Yes, I already know about the patchwork (or how it was called?) but I remember that I missed a NULL check in one place but decided not to send a new update patch just because it's too boring. So if you ever decide to apply the "[PATCH] --header option to pass additional raw HTTP header" please let me know and I'll update it. I tried to contribute on a Weekend and I had only an hour or two while my child was sleeping but I wasted all my time configuring git send-email. I clearly understand that OpenWrt developers mightn't receive many PRs with a poor quality but still this makes many enthusiasts to be involved and increase a trust to the code base. Speaking of which hosting is to choose I really agree with all concerns, even about the LibreJS. And I'm certain that one day we'll have distributed/federated git hostings and comments from one system will be seen by participants in other systems. They are actively developed and this is just a matter of time when they become useful enough. Note that users also need some time to "grow" their skills. For many Junior developers the GitHub is a synonym of Git. At the same time the "centralised" way when many users are already on GitHub even today makes a lot of benefits. We can grow a community and then move to any other place. Speaking about GitHub and access to it from sanctioned territories this is a really big concern. I live in Ukraine but I am going to visit my friend in Crimea for her wedding. And the official GitHub app may detect my location and I'll be blocked even if I as a Ukrainian citizen visited a Ukrainian territory. In my previous work I had two colleagues who often visited their relatives in Crimea. But let's be honest: that's not only GitHub but any website in the US or in NATO countries, and not only in countries that practice blocking like Myanmar. In any country there is potentially a risk of getting blocked. Except for Sealand, maybe only Mongolia and Uruguay don't use blocking until. So even hosting on GitHub may be a "good enough" option. Regards, Sergey ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Pre-install MiniUPnPd on OpenWrt by default
I totally understand your concern and having a strict policy by default it's really a good practice to follow. I thought about this and IMHO the main problem here is most of the time that's a question of trade off. For example I developed a web app and to test OAuth flow I manually made a forwarding of 80 port from my router to my laptop's 8080. Finished but forgot to close the forwarding. And when I developed another app that also listens to the 8080 then it became available to the whole internet and I didn't even notice it. UPnP/PCP opens a port only for a specified time that a client must prolong. In that case this makes it more safe than the manual port forwarding. BTW it only allows forwarding for ports higher than 1024. And I can login and see all the leases in Luci in one place instead of analysing all firewall rules. There is a small web server for Chrome https://chrome.google.com/webstore/detail/web-server-for-chrome/ofhbbkphhbklhfoeikjpcbhemlocgigb It has 400,000+ users and most of them are not experienced like pupils who try to host their first home page. It has support for the exposing port via UPnP. Even if 1% of users use it that means that 4000 people have to go and manually enable port forwarding. I am just afraid of how many people may harm themselves. Also please note that many users just don't have access to the router e.g. because it belongs to an ISP or to a hotel. > any application in your LAN can open ports and poke holes Even now any application in my LAN can connect to any server and start uploading and receiving data. Should we block them? Or any computer in my LAN can connect to any other by default. So my guest or a hacked teapot can steal photos from my NAS. Should OpenWrt have an isolated clients policy be default? But the OpenWrt may have at least pre-configured Guest and IoT networks with the isolation enabled. Ideally also it may be a kind of captive portal or a firewall client app installed on the admin's computer. Currently any VoIP program uses a TURN server which is basically a server with a public IP that retransmits data from two peers behind NAT. And this opens a door for another attack: the TURN server may eavesdrop or collect metadata. It may be unexpectedly turned off, blocked or a huracan broke a line. Few countries already had a situation when due to protests the internet was just shut down. Imagine that you are trying to call your lost child when due to some disaster or earthquake the internet connectivity was partially broken. Probably most people want to have such ability even if their PlayStation may be potentially hacked. Also in my country there are not so many TURN servers and I feel that sound quality sometimes is bad even if I call my wife in the nearby building. So what is safer and better for privacy: allow peers to call each other directly or by the strict policy force their VoIP program to use TURN without even noticing them? Things become even worse with IoT devices: each vendor has its own "cloud". Once I couldn't start my vacuum cleaner robot because of problems with the internet. Disgusting. That was the whole point of that long discussion about allowing IPv6 connections from outside. I don't want to touch that topic but my IMHO is that here OpenWrt tries to save the world which is not possible. Each app developer must know that it may be accidentally or not be accessible for the entire internet. But if an app can explicitly ask for a port forwarding then that at least means that it's developers are clearly aware about security risks of this. As a compromise OpenWrt may allow only a short range of IPv6 ports to be accessed directly so users of old programs without PCP support may expose them by simply switching a port. But that's another question. Here we have a situation: a Regular User had a router with a UPnP, installed OpenWrt and now I don't have it and games work slower. That definitely is not what was expected. And the user will tell his friends not to install OpenWrt. And those friends will continue to use a proprietary firmware which is probably buggy and full of vulnerabilities and backdoors. What is safier? A Power User or a sysadmin, as opposed to the Regular User, must know about UPnP and can disable it and create forwarding manually. The world is dangerous but we may make it slightly comfortable. On Tue, 25 Jan 2022 at 15:51, Stijn Segers wrote: > > Hi Sergey, > > Op dinsdag 25 januari 2022 om 15u27 schreef Sergey Ponomarev > : > > Hi, > > > > Most routers support port forwarding via UPnP IDG or/and NAT-PMP/PCP. > > And many vendors use the MiniUPnPd http://miniupnp.free.fr This daemon > > is kind of standard de-facto. > > This is necessary for any p2p application but OpenWrt builds don't > > have it pre-installed and pre-configured. While it's not so difficult > > to install, this is an additional step and still something that users > > must know. For example, I didn't know about it for about two years > > while alre
Re: Pre-install MiniUPnPd on OpenWrt by default
Hi Sergey, Op dinsdag 25 januari 2022 om 15u27 schreef Sergey Ponomarev : Hi, Most routers support port forwarding via UPnP IDG or/and NAT-PMP/PCP. And many vendors use the MiniUPnPd http://miniupnp.free.fr This daemon is kind of standard de-facto. This is necessary for any p2p application but OpenWrt builds don't have it pre-installed and pre-configured. While it's not so difficult to install, this is an additional step and still something that users must know. For example, I didn't know about it for about two years while already using OpenWrt. For many users this makes life after switching to OpenWrt worse than it was before because, for example, now their gaming console works slower. Even if someone will try to install it there is a risk to configure it incorrectly and expose WAN to LAN forwarding. Could you include the MiniUPnPd into OpenWrt? Given the inherent flaws and threats the concept of UPnP poses, I don't think it stands a chance to be included by default. Just the fact that any application in your LAN can open ports and poke holes at will in your firewall is reason enough to *never* do that. A lot of people in the community advise users to find out what ports they need to open and do that manually, keeping control over what's open and what not, instead of relying on an easy (but risky) protocol like UPnP. Of course, that's just my 2 cents. Cheers Stijn There may be few concerns: 1. The UPnP IDG protocol has a very bad reputation. See "Universal Pwn n Play" talk. 2. The MiniUPnPd also had a security issue in 2014 when the WAN to LAN forwarding was enabled for NAT-PMP. 3. A disk space usage: I checked on OpenWrt with WR1043N (MIPS) and after installing the miniupnpd and it's dependency libcap-ng the disk size usage increased to 72Kb. The binary itself is 98565 bytes, in contrast with uhttpd 46212 and lighttpd 221413. Maybe for Tiny builds this may be too much. To make it smaller and easier for a code audit we may strip the UPnP and leave only NAT-PMP/PCP. See https://github.com/miniupnp/miniupnp/issues/545 In July 2014 there was two discussions about IPv6 firewall policy for direct connections: "OpenWRT IPv6 firewall" http://lists.openwrt.org/pipermail/openwrt-devel/2014-July/000763.html "IPv6 firewall and Port Control Protocol" http://lists.openwrt.org/pipermail/openwrt-devel/2014-July/000671.html The MiniUPnPd can solve the problem at least partially. See also: a forum discussion https://forum.openwrt.org/t/port-control-protocol-support/114411 Regards, Sergey ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Pre-install MiniUPnPd on OpenWrt by default
Hi, Most routers support port forwarding via UPnP IDG or/and NAT-PMP/PCP. And many vendors use the MiniUPnPd http://miniupnp.free.fr This daemon is kind of standard de-facto. This is necessary for any p2p application but OpenWrt builds don't have it pre-installed and pre-configured. While it's not so difficult to install, this is an additional step and still something that users must know. For example, I didn't know about it for about two years while already using OpenWrt. For many users this makes life after switching to OpenWrt worse than it was before because, for example, now their gaming console works slower. Even if someone will try to install it there is a risk to configure it incorrectly and expose WAN to LAN forwarding. Could you include the MiniUPnPd into OpenWrt? There may be few concerns: 1. The UPnP IDG protocol has a very bad reputation. See "Universal Pwn n Play" talk. 2. The MiniUPnPd also had a security issue in 2014 when the WAN to LAN forwarding was enabled for NAT-PMP. 3. A disk space usage: I checked on OpenWrt with WR1043N (MIPS) and after installing the miniupnpd and it's dependency libcap-ng the disk size usage increased to 72Kb. The binary itself is 98565 bytes, in contrast with uhttpd 46212 and lighttpd 221413. Maybe for Tiny builds this may be too much. To make it smaller and easier for a code audit we may strip the UPnP and leave only NAT-PMP/PCP. See https://github.com/miniupnp/miniupnp/issues/545 In July 2014 there was two discussions about IPv6 firewall policy for direct connections: "OpenWRT IPv6 firewall" http://lists.openwrt.org/pipermail/openwrt-devel/2014-July/000763.html "IPv6 firewall and Port Control Protocol" http://lists.openwrt.org/pipermail/openwrt-devel/2014-July/000671.html The MiniUPnPd can solve the problem at least partially. See also: a forum discussion https://forum.openwrt.org/t/port-control-protocol-support/114411 Regards, Sergey ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
