Re: [OpenWrt-Devel] [PATCH 2/5] build: image: Add pad-to and pad-rootfs-squashfs helpers
Hi, >>> I would like to avoid adding generating padded images by default. >> >> To just save some space? We're gzipping the images by default, which makes >> image padded to 256M just 2.7M big. I find 256M overkill for testing, so >> that's why I've suggested 32M by default for QEMU padded images. > Not building padded images saves build time, because the system doesn't > have to waste so many cycles compressing empty data. There's so many inefficiencies in the overall build process that gzip compressing a 256MB file is neglectible. >>> I just came up with this simple script, which takes an existing image and >>> pads it to full size: http://nbd.name/pad-image.pl With this, shipping >>> padded images should be unnecessary. >> >> Ok, if that is preferred, it's fine with me. But we should probably add some >> note somewhere, that in order to test this images in QEMU (x86, armvirt, >> malta), the images should be padded with this script in order to provide >> usable images. Most other targets ship image artifacts which are usable ootb, requiring one extra step to pad the combined images is a waste of user resources every single time. It also causes recurring confusion among users wanting to use x86 builds since the need for padding is neither documented, nor obvious while a combined.img.gz makes it obvious that it is an image file which requires decompression. I really don't see the huge problem with conservatively padding the combined image artifacts to something like 32 or 48MB, it must not even be 256M or more. ~ Jo signature.asc Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 4/7] zynq: kernel: remove video/camera kconfig options
The options are managed on a generic way by video packages Additionally, only one of the currently supported boards has a camera interface, but it requires programming the FPGA fabric first Signed-off-by: Luis Araneda --- target/linux/zynq/config-4.14 | 12 1 file changed, 12 deletions(-) diff --git a/target/linux/zynq/config-4.14 b/target/linux/zynq/config-4.14 index 688ad4cbee..7ec3a586ca 100644 --- a/target/linux/zynq/config-4.14 +++ b/target/linux/zynq/config-4.14 @@ -410,9 +410,6 @@ CONFIG_MDIO_BITBANG=y CONFIG_MDIO_BUS=y CONFIG_MDIO_DEVICE=y # CONFIG_MDIO_GPIO is not set -CONFIG_MEDIA_CAMERA_SUPPORT=y -CONFIG_MEDIA_CONTROLLER=y -CONFIG_MEDIA_SUPPORT=y CONFIG_MEMORY=y CONFIG_MEMORY_ISOLATION=y CONFIG_MFD_CORE=y @@ -658,7 +655,6 @@ CONFIG_USB_ULPI_VIEWPORT=y CONFIG_USELIB=y # CONFIG_USERIO is not set CONFIG_USE_OF=y -# CONFIG_V4L_PLATFORM_DRIVERS is not set CONFIG_VECTORS_BASE=0x CONFIG_VEXPRESS_CONFIG=y CONFIG_VEXPRESS_SYSCFG=y @@ -667,14 +663,6 @@ CONFIG_VFP=y CONFIG_VFPv3=y CONFIG_VGA_ARB=y CONFIG_VGA_ARB_MAX_GPUS=16 -# CONFIG_VIDEO_AD5820 is not set -# CONFIG_VIDEO_ADP1653 is not set -# CONFIG_VIDEO_AS3645A is not set -CONFIG_VIDEO_DEV=y -# CONFIG_VIDEO_LM3560 is not set -# CONFIG_VIDEO_LM3646 is not set -CONFIG_VIDEO_V4L2=y -# CONFIG_VIDEO_V4L2_SUBDEV_API is not set CONFIG_VITESSE_PHY=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_VT=y -- 2.21.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 6/7] zynq: replace CAN kconfig options by device packages
The options are managed on a generic way by the can kmod packages Additionally, select can packages only for devices that currently has CAN enabled, which is only the ZC702 Signed-off-by: Luis Araneda --- This change was run-tested on a Zybo-z7 board with a modified device tree that enabled can0 --- target/linux/zynq/config-4.14| 21 - target/linux/zynq/image/Makefile | 1 + 2 files changed, 1 insertion(+), 21 deletions(-) diff --git a/target/linux/zynq/config-4.14 b/target/linux/zynq/config-4.14 index 7ec3a586ca..b78113a21f 100644 --- a/target/linux/zynq/config-4.14 +++ b/target/linux/zynq/config-4.14 @@ -81,27 +81,6 @@ CONFIG_BUILD_BIN2C=y CONFIG_CACHE_L2X0=y CONFIG_CADENCE_TTC_TIMER=y CONFIG_CADENCE_WATCHDOG=y -CONFIG_CAN=y -# CONFIG_CAN_8DEV_USB is not set -CONFIG_CAN_BCM=y -CONFIG_CAN_CALC_BITTIMING=y -# CONFIG_CAN_CC770 is not set -# CONFIG_CAN_C_CAN is not set -CONFIG_CAN_DEV=y -# CONFIG_CAN_EMS_USB is not set -# CONFIG_CAN_ESD_USB2 is not set -# CONFIG_CAN_FLEXCAN is not set -# CONFIG_CAN_GRCAN is not set -CONFIG_CAN_GW=y -# CONFIG_CAN_KVASER_USB is not set -# CONFIG_CAN_LEDS is not set -# CONFIG_CAN_MCP251X is not set -# CONFIG_CAN_PEAK_USB is not set -CONFIG_CAN_RAW=y -# CONFIG_CAN_SJA1000 is not set -# CONFIG_CAN_SOFTING is not set -# CONFIG_CAN_TI_HECC is not set -CONFIG_CAN_XILINXCAN=y CONFIG_CHR_DEV_SG=y CONFIG_CLKDEV_LOOKUP=y CONFIG_CLKSRC_ARM_GLOBAL_TIMER_SCHED_CLOCK=y diff --git a/target/linux/zynq/image/Makefile b/target/linux/zynq/image/Makefile index aac9953b45..d8a882313b 100644 --- a/target/linux/zynq/image/Makefile +++ b/target/linux/zynq/image/Makefile @@ -74,6 +74,7 @@ define Device/xlnx_zynq-zc702 $(call Device/FitImageGzip) DEVICE_TITLE := ZC702 Development Board DEVICE_DTS := zynq-zc702 + DEVICE_PACKAGES:=kmod-can kmod-can-xilinx-can endef TARGET_DEVICES += xlnx_zynq-zc702 -- 2.21.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 1/7] zynq: kernel: refresh config
Signed-off-by: Luis Araneda --- target/linux/zynq/config-4.14 | 16 ++-- 1 file changed, 2 insertions(+), 14 deletions(-) diff --git a/target/linux/zynq/config-4.14 b/target/linux/zynq/config-4.14 index 72b3a2d6c7..a28e91f842 100644 --- a/target/linux/zynq/config-4.14 +++ b/target/linux/zynq/config-4.14 @@ -40,7 +40,6 @@ CONFIG_ARM_CCI=y CONFIG_ARM_CCI400_COMMON=y CONFIG_ARM_CCI400_PMU=y CONFIG_ARM_CCI_PMU=y -# CONFIG_ARM_CHARLCD is not set CONFIG_ARM_CPU_SUSPEND=y CONFIG_ARM_ERRATA_643719=y CONFIG_ARM_ERRATA_720789=y @@ -159,6 +158,7 @@ CONFIG_CPU_IDLE_GOV_MENU=y CONFIG_CPU_PABRT_V7=y CONFIG_CPU_PM=y CONFIG_CPU_RMAP=y +CONFIG_CPU_SPECTRE=y CONFIG_CPU_THERMAL=y CONFIG_CPU_THUMB_CAPABLE=y CONFIG_CPU_TLB_V7=y @@ -256,6 +256,7 @@ CONFIG_GENERIC_EARLY_IOREMAP=y CONFIG_GENERIC_IDLE_POLL_SETUP=y CONFIG_GENERIC_IO=y CONFIG_GENERIC_IRQ_EFFECTIVE_AFF_MASK=y +CONFIG_GENERIC_IRQ_MIGRATION=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_GENERIC_IRQ_SHOW_LEVEL=y CONFIG_GENERIC_MSI_IRQ=y @@ -572,22 +573,9 @@ CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_SCHED_MC=y CONFIG_SCHED_SMT=y CONFIG_SCSI=y -# CONFIG_SENSORS_ADM1275 is not set -# CONFIG_SENSORS_IBM_CFFPS is not set -# CONFIG_SENSORS_IR35221 is not set -# CONFIG_SENSORS_LM25066 is not set -# CONFIG_SENSORS_LTC2978 is not set -# CONFIG_SENSORS_LTC3815 is not set -# CONFIG_SENSORS_MAX16064 is not set -# CONFIG_SENSORS_MAX20751 is not set -# CONFIG_SENSORS_MAX34440 is not set -# CONFIG_SENSORS_MAX8688 is not set CONFIG_SENSORS_PMBUS=y -# CONFIG_SENSORS_TPS40422 is not set -# CONFIG_SENSORS_TPS53679 is not set CONFIG_SENSORS_UCD9000=y CONFIG_SENSORS_UCD9200=y -# CONFIG_SENSORS_ZL6100 is not set # CONFIG_SERIAL_8250 is not set # CONFIG_SERIAL_AMBA_PL011 is not set CONFIG_SERIAL_XILINX_PS_UART=y -- 2.21.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 3/7] zynq: kernel: remove sound kconfig options
The options are managed on a generic way by the sound kmod packages Additionally, none of the currently supported boards have sound support out of the box, as they require programming the FPGA fabric first Signed-off-by: Luis Araneda --- target/linux/zynq/config-4.14 | 19 --- 1 file changed, 19 deletions(-) diff --git a/target/linux/zynq/config-4.14 b/target/linux/zynq/config-4.14 index a28e91f842..688ad4cbee 100644 --- a/target/linux/zynq/config-4.14 +++ b/target/linux/zynq/config-4.14 @@ -586,26 +586,7 @@ CONFIG_SERIO_SERPORT=y CONFIG_SG_POOL=y CONFIG_SMP=y CONFIG_SMP_ON_UP=y -CONFIG_SND=y -CONFIG_SND_ARM=y -# CONFIG_SND_ARMAACI is not set -CONFIG_SND_COMPRESS_OFFLOAD=y -CONFIG_SND_DMAENGINE_PCM=y -CONFIG_SND_JACK=y -CONFIG_SND_JACK_INPUT_DEV=y -CONFIG_SND_PCM=y -CONFIG_SND_SOC=y -CONFIG_SND_SOC_ADI=y -CONFIG_SND_SOC_ADI_AXI_I2S=y -CONFIG_SND_SOC_ADI_AXI_SPDIF=y -CONFIG_SND_SOC_GENERIC_DMAENGINE_PCM=y -CONFIG_SND_SOC_I2C_AND_SPI=y -CONFIG_SND_SPI=y -CONFIG_SND_SUPPORT_OLD_API=y CONFIG_SOC_BUS=y -CONFIG_SOUND=y -CONFIG_SOUND_OSS_CORE=y -CONFIG_SOUND_OSS_CORE_PRECLAIM=y CONFIG_SPARSE_IRQ=y CONFIG_SPI=y CONFIG_SPI_BITBANG=y -- 2.21.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Rebasing "Generate EFI grub images for x86 platforms" (resend)
Hi all. I was trying to rebase my branch to upstream/master recently, but I couldn’t because this commit conflicted: commit 9e3edeb55a2f85ecf6233a5780e495ea1755c998 Author: DUPONCHEEL Sébastien Date: Tue Apr 11 12:46:44 2017 +0200 Generate EFI grub images for x86 platforms Signed-off-by: DUPONCHEEL Sébastien here are the conflicts: CONFLICT (content): Merge conflict in target/linux/x86/image/Makefile CONFLICT (content): Merge conflict in package/boot/grub2/common.mk CONFLICT (content): Merge conflict in config/Config-images.in It might be related to: commit 55b808e0c4be681a0aab565d32a70f5af06a1f8a Author: Tomasz Maciej Nowak Date: Sun Jan 13 21:39:36 2019 +0100 x86: image: add test module to bootloader It was previously added in 546fced, which was part of "intel-microcode: load as early as possible" series. Unfortunately the conditionals added to GRUB config caused error on boot, because on sysupgrade, bootloader is not updated and is left with old features/modules. Since this module is needed for early microcode load and transition to this needs to be done step by step, enable the test module now, so that every newly created image has it already embedded. Signed-off-by: Tomasz Maciej Nowak or: commit bb0e4f9fb0c101b86b1a0c2785fec9b38b19fd02 Author: Tomasz Maciej Nowak Date: Sun Jan 13 21:37:47 2019 +0100 build: remove leftovers from previous x86 commits VBoxManage is not used and the image is created with proper permisions: 0f5d0f6 image: use internal qemu-img for vmdk and vdi images drop host dependencies on qemu-utils and VirtualBox Unreachable config symbols: 9e0759e x86: merge all geode based subtargets into one No need to define those symbols since x86_64 is subtarget of x86: 196fb76 x86: make x86_64 a subtarget instead of a standalone target Unreachable config symbols, so remove GRUB_ROOT: 371b382 x86: remove the xen_domu subtarget Signed-off-by: Tomasz Maciej Nowak Sebastian or Jo-Philipp: Is there a rebased version of this I can grab? What’s the state of the EFI changes making it into master, anyway? I’ve not been able to build an image in 3 months now. Thanks, -Philip ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [Request] Build x86_64 with EFI Images for ext4 combined
Yup, amen to that, but it seems to be something that’s for whatever reason is not quick to happen… > On Aug 22, 2018, at 1:17 AM, Joel Wirāmu Pauling wrote: > > Currently the Auto-generated x86/64 images are all msdos > partition/boot layouts. Which means they are a PITA to run on > increasingly UEFI only hardware. > > It would be great to have the release images and snapshots build have > two new variants a combined ext4 efi in particular would be very > useful. > > Cheers > > -Joel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [sdwalker/sdwalker.github.io] 3c0590: This week's update
Branch: refs/heads/master Home: https://github.com/sdwalker/sdwalker.github.io Commit: 3c0590e4fcf4174eb601db6ea9c130018141c0bf https://github.com/sdwalker/sdwalker.github.io/commit/3c0590e4fcf4174eb601db6ea9c130018141c0bf Author: Stephen Walker Date: 2019-03-31 (Sun, 31 Mar 2019) Changed paths: M uscan/index-18.06.html M uscan/index.html Log Message: --- This week's update ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/5] build: image: Add pad-to and pad-rootfs-squashfs helpers
On 2019-03-31 20:41, Petr Štetiar wrote: > Felix Fietkau [2019-03-30 09:18:39]: > >> >> On 2019-03-29 15:07, Petr Štetiar wrote: >> > >> > Should we simply add CONFIG_QEMU_SQUASHFS_IMAGES (enabled by default) and >> > CONFIG_QEMU_SQUASHFS_PARTSIZE=32 and use this information for generating of >> > images for QEMU? On armvirt/malta it will simply produce working images >> > based >> > on this settings, on x86 it will produce two additional images usable in >> > QEMU >> > as well: >> >> I would like to avoid adding generating padded images by default. > > To just save some space? We're gzipping the images by default, which makes > image padded to 256M just 2.7M big. I find 256M overkill for testing, so > that's why I've suggested 32M by default for QEMU padded images. Not building padded images saves build time, because the system doesn't have to waste so many cycles compressing empty data. >> I just came up with this simple script, which takes an existing image and >> pads it to full size: http://nbd.name/pad-image.pl With this, shipping >> padded images should be unnecessary. > > Ok, if that is preferred, it's fine with me. But we should probably add some > note somewhere, that in order to test this images in QEMU (x86, armvirt, > malta), the images should be padded with this script in order to provide > usable images. I agree. > BTW that script needs some tweaking, it's producing here 2TB images from this > file > > http://downloads.openwrt.org/snapshots/targets/x86/64/openwrt-x86-64-rootfs-squashfs.img.gz That's just the rootfs image, you're supposed to run the script on a combined image. What do you need that rootfs image for? - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] instance: add support for customizable syslog facilities
This allow using a different (read: user-defined) syslog facility
other than LOG_DAEMON when an instance's stdout/stderr is forwarded
to syslog.
It might be used to handle such messages different, e.g.
filter/forward them etc.
Signed-off-by: Michael Heimpold
---
service/instance.c | 34 +-
service/instance.h | 1 +
2 files changed, 34 insertions(+), 1 deletion(-)
diff --git a/service/instance.c b/service/instance.c
index 3b92536..983494b 100644
--- a/service/instance.c
+++ b/service/instance.c
@@ -26,6 +26,8 @@
#include
#include
#include
+#define SYSLOG_NAMES
+#include
#include
@@ -58,6 +60,7 @@ enum {
INSTANCE_ATTR_PIDFILE,
INSTANCE_ATTR_RELOADSIG,
INSTANCE_ATTR_TERMTIMEOUT,
+ INSTANCE_ATTR_FACILITY,
__INSTANCE_ATTR_MAX
};
@@ -84,6 +87,7 @@ static const struct blobmsg_policy
instance_attr[__INSTANCE_ATTR_MAX] = {
[INSTANCE_ATTR_PIDFILE] = { "pidfile", BLOBMSG_TYPE_STRING },
[INSTANCE_ATTR_RELOADSIG] = { "reload_signal", BLOBMSG_TYPE_INT32 },
[INSTANCE_ATTR_TERMTIMEOUT] = { "term_timeout", BLOBMSG_TYPE_INT32 },
+ [INSTANCE_ATTR_FACILITY] = { "facility", BLOBMSG_TYPE_STRING },
};
enum {
@@ -150,6 +154,18 @@ static void closefd(int fd)
close(fd);
}
+/* convert a string into numeric syslog facility or return -1 if no match
found */
+static int
+syslog_facility_str_to_int(const char *facility)
+{
+ CODE *p = facilitynames;
+
+ while (p->c_name && strcasecmp(p->c_name, facility))
+ p++;
+
+ return p->c_val;
+}
+
static void
instance_limits(const char *limit, const char *value)
{
@@ -468,7 +484,7 @@ instance_stdio(struct ustream *s, int prio, struct
service_instance *in)
arg0 = basename(blobmsg_data(blobmsg_data(in->command)));
snprintf(ident, sizeof(ident), "%s[%d]", arg0, in->proc.pid);
- ulog_open(ULOG_SYSLOG, LOG_DAEMON, ident);
+ ulog_open(ULOG_SYSLOG, in->syslog_facility, ident);
do {
str = ustream_get_read_buf(s, );
@@ -622,6 +638,9 @@ instance_config_changed(struct service_instance *in, struct
service_instance *in
if (in->nice != in_new->nice)
return true;
+ if (in->syslog_facility != in_new->syslog_facility)
+ return true;
+
if (string_changed(in->user, in_new->user))
return true;
@@ -944,6 +963,17 @@ instance_config_parse(struct service_instance *in)
if (!instance_fill_array(>errors, tb[INSTANCE_ATTR_ERROR], NULL,
true))
return false;
+ if (tb[INSTANCE_ATTR_FACILITY]) {
+ int facility =
syslog_facility_str_to_int(blobmsg_get_string(tb[INSTANCE_ATTR_FACILITY]));
+ if (facility != -1) {
+ DEBUG(3, "setting facility '%s'\n",
blobmsg_get_string(tb[INSTANCE_ATTR_FACILITY]));
+ in->syslog_facility = facility;
+ } else {
+ DEBUG(3, "unknown syslog facility '%s' given, using
default (LOG_DAEMON)\n", blobmsg_get_string(tb[INSTANCE_ATTR_FACILITY]));
+ in->syslog_facility = LOG_DAEMON;
+ }
+ }
+
return true;
}
@@ -980,6 +1010,7 @@ instance_config_move(struct service_instance *in, struct
service_instance *in_sr
in->trace = in_src->trace;
in->seccomp = in_src->seccomp;
in->node.avl.key = in_src->node.avl.key;
+ in->syslog_facility = in_src->syslog_facility;
free(in->config);
in->config = in_src->config;
@@ -1029,6 +1060,7 @@ instance_init(struct service_instance *in, struct service
*s, struct blob_attr *
in->timeout.cb = instance_timeout;
in->proc.cb = instance_exit;
in->term_timeout = 5;
+ in->syslog_facility = LOG_DAEMON;
in->_stdout.fd.fd = -2;
in->_stdout.stream.string_data = true;
diff --git a/service/instance.h b/service/instance.h
index 84ce002..42cc4be 100644
--- a/service/instance.h
+++ b/service/instance.h
@@ -61,6 +61,7 @@ struct service_instance {
struct jail jail;
char *seccomp;
char *pidfile;
+ int syslog_facility;
uint32_t term_timeout;
uint32_t respawn_timeout;
--
2.17.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ath9k: fix dynack in IBSS mode
>
> On Sun, Mar 31, 2019 at 6:45 AM Lorenzo Bianconi
> wrote:
> >
> > >
> > > bump.
> >
> > Hi Joe,
> >
> > sorry for the delay
> >
> > >
> > > On Mon, Mar 18, 2019 at 10:59 PM Joe Ayers wrote:
> > >>
> > >> Lorenzo, I have tested dynack on a (real distance apart) ~60km link
> > >> with some success. This is the code change made:
> > >>
> > >> --- a/drivers/net/wireless/ath/ath9k/dynack.c
> > >> +++ b/drivers/net/wireless/ath/ath9k/dynack.c
> > >> @@ -20,8 +20,9 @@
> > >>
> > >> #define COMPUTE_TO (5 * HZ)
> > >> #define LATEACK_DELAY (10 * HZ)
> > >> -#define LATEACK_TO 256
> > >> -#define MAX_DELAY 300
> > >> +#define LATEACK_TO 1054
> > >> +/* AREDN max distance set to 150km */
> > >> +#define MAX_DELAY 1054
> > >> #define EWMA_LEVEL 96
> > >> #define EWMA_DIV 128
> > >>
> > >> @@ -293,7 +294,8 @@
> > >> void ath_dynack_node_init(struct ath_hw *ah, struct ath_node *an)
> > >> {
> > >> /* ackto = slottime + sifs + air delay */
> > >> - u32 ackto = 9 + 16 + 64;
> > >> + /* AREDN starting point is 20km */
> > >> + u32 ackto = 9 + 16 + 171;
> > >> struct ath_dynack *da = >dynack;
> > >>
> > >> an->ackto = ackto;
> > >> @@ -328,7 +330,8 @@
> > >> void ath_dynack_reset(struct ath_hw *ah)
> > >> {
> > >> /* ackto = slottime + sifs + air delay */
> > >> - u32 ackto = 9 + 16 + 64;
> > >> + /* AREDN starting point is 20km */
> > >> + u32 ackto = 9 + 16 + 171;
> > >> struct ath_dynack *da = >dynack;
> > >>
> > >> da->lto = jiffies;
> > >>
> > >> Notes:
> > >>
> > >> 1) The stations are showing ack_to between 525 up to 575 A. When
> > >> static set at 60k distance, the timeout is set to 460 S.
> > >> 2) significant performance improvement between these settings with
> > >> iperf3 and back to back runs with reboot in the middle:
> > >>
> >
> > could you please try to attached patch? The max distance the hw can
> > support depends of channel width:
> > e.g @20MHz (HT20, 5GHz)
> >
> > max distance is ~ 61Km
> >
>
> Could these max distance specs be what the manufacture tested, not
> necessarily a hardware limitation -- just not known?
>
https://github.com/torvalds/linux/blob/master/drivers/net/wireless/ath/ath9k/hw.c#L1006
max timeout you can set is AR_TIME_OUT_ACK (0x3fff) / clock_rate
> I suspect in the calculation for max_to, if the channel is 10MHz, the
> max distance can be doubled for the hardware--do the specs only give
> 20MHz values? This would be consistent with, for example, the symbol
> lengths are doubled when cutting the bandwidth in half, hence half the
> rates and still 64 bins or 64 point fft squeezed in the channel. SNR
> is also 3dB higher given same energy in half the bandwidth. We don't
> see 20MHz channels working at these long distances, rather use 10MHz
> for it to work. Intuitively, as I understand it, more time is needed
> with increased distance for reflection signals to not be received past
> the symbol time and increased inter-symbol interference.
yes, but it is already done in ath9k_hw_set_clockrate()
https://github.com/torvalds/linux/blob/master/drivers/net/wireless/ath/ath9k/hw.c#L61
>
> > @Koen: do you have any chance to test the attached patch in your
> > environment? Thx
> >
> > >> run 1 @ static 60km:
> > >> [ 5] 0.00-10.00 sec 7.31 MBytes 6.13 Mbits/sec0
> > >> sender
> > >> [ 5] 0.00-10.08 sec 7.16 MBytes 5.95 Mbits/sec
> > >> receiver
> > >>
> > >> run 2 @ static 60km:
> > >> [ 5] 0.00-10.00 sec 5.88 MBytes 4.93 Mbits/sec0
> > >> sender
> > >> [ 5] 0.00-10.04 sec 5.77 MBytes 4.81 Mbits/sec
> > >> receiver
> > >>
> > >> run 1 and 2 @ auto distance -- goes up to ~575us with data flow,
> > >> floats back to ~525 otherwise:
> > >> [ 5] 0.00-10.00 sec 20.0 MBytes 16.8 Mbits/sec0
> > >> sender
> > >> [ 5] 0.00-10.07 sec 19.8 MBytes 16.5 Mbits/sec
> > >> receiver
> > >>
> > >> [ 5] 0.00-10.00 sec 21.4 MBytes 18.0 Mbits/sec0
> > >> sender
> > >> [ 5] 0.00-10.04 sec 21.2 MBytes 17.7 Mbits/sec
> > >> receiver
> > >>
> > >> 3) running wpa_supplicant and psk2
> > >> 4) running ibss on ch 176 with AREDN channels on top of 18.06.2
> > >> 5) on one reboot, one of the stations stayed down at initial 196, then
> > >> bumped up to ~250 range and stayed there, link not functional. Not
> > >> sure how to explain this value...
> > >>
> > >> Question, can this condition be true periodically while the link is
> > >> live or only at initial 802.11 adhoc link setup?:
> > >>
> > >> if (ieee80211_is_assoc_req(hdr->frame_control) ||
> > >> ieee80211_is_assoc_resp(hdr->frame_control) ||
> > >> ieee80211_is_auth(hdr->frame_control)) {
> > >>
> >
> > I do not think so since AFAIK auth frames are sent just during ibss join
> >
> > >> 6) Auto distance stayed at initial 196 when turning off encryption.
> > >>
> > >> Any ideas of
[OpenWrt-Devel] Merged: ramips: add missing SPDX identifier for EX6150
Thanks! Merged into my staging tree at https://git.openwrt.org/openwrt/staging/ynezz.git ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/5] build: image: Add pad-to and pad-rootfs-squashfs helpers
Felix Fietkau [2019-03-30 09:18:39]: > >> On 2019-03-29 15:07, Petr Štetiar wrote: > > > > Should we simply add CONFIG_QEMU_SQUASHFS_IMAGES (enabled by default) and > > CONFIG_QEMU_SQUASHFS_PARTSIZE=32 and use this information for generating of > > images for QEMU? On armvirt/malta it will simply produce working images > > based > > on this settings, on x86 it will produce two additional images usable in > > QEMU > > as well: > > I would like to avoid adding generating padded images by default. To just save some space? We're gzipping the images by default, which makes image padded to 256M just 2.7M big. I find 256M overkill for testing, so that's why I've suggested 32M by default for QEMU padded images. > I just came up with this simple script, which takes an existing image and > pads it to full size: http://nbd.name/pad-image.pl With this, shipping > padded images should be unnecessary. Ok, if that is preferred, it's fine with me. But we should probably add some note somewhere, that in order to test this images in QEMU (x86, armvirt, malta), the images should be padded with this script in order to provide usable images. BTW that script needs some tweaking, it's producing here 2TB images from this file http://downloads.openwrt.org/snapshots/targets/x86/64/openwrt-x86-64-rootfs-squashfs.img.gz > > openwrt-x86-64-qemu-combined-squashfs.img > > openwrt-x86-64-qemu-rootfs-squashfs.img > > Another semi-related thing: do we really need those separate rootfs > images? We could save some download server storage space by dropping > them. If necessary, we could make another script like the one above to > extract it from the combined image. On x86, the only use case which comes to my mind is kernel testing, otherwise combined image is good enough (if I ommit the missing padding for QEMU). On armivrt/malta those images are probably necessary, as there is no combined image on this targets. Again, without padding the images are unusable as well. -- ynezz ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ath9k: fix dynack in IBSS mode
On Sun, Mar 31, 2019 at 6:45 AM Lorenzo Bianconi
wrote:
>
> >
> > bump.
>
> Hi Joe,
>
> sorry for the delay
>
> >
> > On Mon, Mar 18, 2019 at 10:59 PM Joe Ayers wrote:
> >>
> >> Lorenzo, I have tested dynack on a (real distance apart) ~60km link
> >> with some success. This is the code change made:
> >>
> >> --- a/drivers/net/wireless/ath/ath9k/dynack.c
> >> +++ b/drivers/net/wireless/ath/ath9k/dynack.c
> >> @@ -20,8 +20,9 @@
> >>
> >> #define COMPUTE_TO (5 * HZ)
> >> #define LATEACK_DELAY (10 * HZ)
> >> -#define LATEACK_TO 256
> >> -#define MAX_DELAY 300
> >> +#define LATEACK_TO 1054
> >> +/* AREDN max distance set to 150km */
> >> +#define MAX_DELAY 1054
> >> #define EWMA_LEVEL 96
> >> #define EWMA_DIV 128
> >>
> >> @@ -293,7 +294,8 @@
> >> void ath_dynack_node_init(struct ath_hw *ah, struct ath_node *an)
> >> {
> >> /* ackto = slottime + sifs + air delay */
> >> - u32 ackto = 9 + 16 + 64;
> >> + /* AREDN starting point is 20km */
> >> + u32 ackto = 9 + 16 + 171;
> >> struct ath_dynack *da = >dynack;
> >>
> >> an->ackto = ackto;
> >> @@ -328,7 +330,8 @@
> >> void ath_dynack_reset(struct ath_hw *ah)
> >> {
> >> /* ackto = slottime + sifs + air delay */
> >> - u32 ackto = 9 + 16 + 64;
> >> + /* AREDN starting point is 20km */
> >> + u32 ackto = 9 + 16 + 171;
> >> struct ath_dynack *da = >dynack;
> >>
> >> da->lto = jiffies;
> >>
> >> Notes:
> >>
> >> 1) The stations are showing ack_to between 525 up to 575 A. When
> >> static set at 60k distance, the timeout is set to 460 S.
> >> 2) significant performance improvement between these settings with
> >> iperf3 and back to back runs with reboot in the middle:
> >>
>
> could you please try to attached patch? The max distance the hw can
> support depends of channel width:
> e.g @20MHz (HT20, 5GHz)
>
> max distance is ~ 61Km
>
Could these max distance specs be what the manufacture tested, not
necessarily a hardware limitation -- just not known?
I suspect in the calculation for max_to, if the channel is 10MHz, the
max distance can be doubled for the hardware--do the specs only give
20MHz values? This would be consistent with, for example, the symbol
lengths are doubled when cutting the bandwidth in half, hence half the
rates and still 64 bins or 64 point fft squeezed in the channel. SNR
is also 3dB higher given same energy in half the bandwidth. We don't
see 20MHz channels working at these long distances, rather use 10MHz
for it to work. Intuitively, as I understand it, more time is needed
with increased distance for reflection signals to not be received past
the symbol time and increased inter-symbol interference.
> @Koen: do you have any chance to test the attached patch in your
> environment? Thx
>
> >> run 1 @ static 60km:
> >> [ 5] 0.00-10.00 sec 7.31 MBytes 6.13 Mbits/sec0
> >> sender
> >> [ 5] 0.00-10.08 sec 7.16 MBytes 5.95 Mbits/sec
> >> receiver
> >>
> >> run 2 @ static 60km:
> >> [ 5] 0.00-10.00 sec 5.88 MBytes 4.93 Mbits/sec0
> >> sender
> >> [ 5] 0.00-10.04 sec 5.77 MBytes 4.81 Mbits/sec
> >> receiver
> >>
> >> run 1 and 2 @ auto distance -- goes up to ~575us with data flow,
> >> floats back to ~525 otherwise:
> >> [ 5] 0.00-10.00 sec 20.0 MBytes 16.8 Mbits/sec0
> >> sender
> >> [ 5] 0.00-10.07 sec 19.8 MBytes 16.5 Mbits/sec
> >> receiver
> >>
> >> [ 5] 0.00-10.00 sec 21.4 MBytes 18.0 Mbits/sec0
> >> sender
> >> [ 5] 0.00-10.04 sec 21.2 MBytes 17.7 Mbits/sec
> >> receiver
> >>
> >> 3) running wpa_supplicant and psk2
> >> 4) running ibss on ch 176 with AREDN channels on top of 18.06.2
> >> 5) on one reboot, one of the stations stayed down at initial 196, then
> >> bumped up to ~250 range and stayed there, link not functional. Not
> >> sure how to explain this value...
> >>
> >> Question, can this condition be true periodically while the link is
> >> live or only at initial 802.11 adhoc link setup?:
> >>
> >> if (ieee80211_is_assoc_req(hdr->frame_control) ||
> >> ieee80211_is_assoc_resp(hdr->frame_control) ||
> >> ieee80211_is_auth(hdr->frame_control)) {
> >>
>
> I do not think so since AFAIK auth frames are sent just during ibss join
>
> >> 6) Auto distance stayed at initial 196 when turning off encryption.
> >>
> >> Any ideas of alternative options of packets to key off in late ack
> >> situation? running wpad-mini is ~500k file size and RAM consumer.
> >> It would be beneficial to take wpa_supplicant out of the equation if
> >> at all possible.
> >>
>
> What is mandatory are unicast frames during joining phase, maybe you can
> develop an userspace daemon for this purpose
>
I see where you're going with this. I'd have to learn a lot to do
this. Possibly a simpler approach, if it doesn't add too much
penalty. What if the initial ack_to is at max, it quickly settles
Re: [OpenWrt-Devel] ath9k: fix dynack in IBSS mode
>
> bump.
Hi Joe,
sorry for the delay
>
> On Mon, Mar 18, 2019 at 10:59 PM Joe Ayers wrote:
>>
>> Lorenzo, I have tested dynack on a (real distance apart) ~60km link
>> with some success. This is the code change made:
>>
>> --- a/drivers/net/wireless/ath/ath9k/dynack.c
>> +++ b/drivers/net/wireless/ath/ath9k/dynack.c
>> @@ -20,8 +20,9 @@
>>
>> #define COMPUTE_TO (5 * HZ)
>> #define LATEACK_DELAY (10 * HZ)
>> -#define LATEACK_TO 256
>> -#define MAX_DELAY 300
>> +#define LATEACK_TO 1054
>> +/* AREDN max distance set to 150km */
>> +#define MAX_DELAY 1054
>> #define EWMA_LEVEL 96
>> #define EWMA_DIV 128
>>
>> @@ -293,7 +294,8 @@
>> void ath_dynack_node_init(struct ath_hw *ah, struct ath_node *an)
>> {
>> /* ackto = slottime + sifs + air delay */
>> - u32 ackto = 9 + 16 + 64;
>> + /* AREDN starting point is 20km */
>> + u32 ackto = 9 + 16 + 171;
>> struct ath_dynack *da = >dynack;
>>
>> an->ackto = ackto;
>> @@ -328,7 +330,8 @@
>> void ath_dynack_reset(struct ath_hw *ah)
>> {
>> /* ackto = slottime + sifs + air delay */
>> - u32 ackto = 9 + 16 + 64;
>> + /* AREDN starting point is 20km */
>> + u32 ackto = 9 + 16 + 171;
>> struct ath_dynack *da = >dynack;
>>
>> da->lto = jiffies;
>>
>> Notes:
>>
>> 1) The stations are showing ack_to between 525 up to 575 A. When
>> static set at 60k distance, the timeout is set to 460 S.
>> 2) significant performance improvement between these settings with
>> iperf3 and back to back runs with reboot in the middle:
>>
could you please try to attached patch? The max distance the hw can
support depends of channel width:
e.g @20MHz (HT20, 5GHz)
max distance is ~ 61Km
@Koen: do you have any chance to test the attached patch in your
environment? Thx
>> run 1 @ static 60km:
>> [ 5] 0.00-10.00 sec 7.31 MBytes 6.13 Mbits/sec0 sender
>> [ 5] 0.00-10.08 sec 7.16 MBytes 5.95 Mbits/sec
>> receiver
>>
>> run 2 @ static 60km:
>> [ 5] 0.00-10.00 sec 5.88 MBytes 4.93 Mbits/sec0 sender
>> [ 5] 0.00-10.04 sec 5.77 MBytes 4.81 Mbits/sec
>> receiver
>>
>> run 1 and 2 @ auto distance -- goes up to ~575us with data flow,
>> floats back to ~525 otherwise:
>> [ 5] 0.00-10.00 sec 20.0 MBytes 16.8 Mbits/sec0 sender
>> [ 5] 0.00-10.07 sec 19.8 MBytes 16.5 Mbits/sec
>> receiver
>>
>> [ 5] 0.00-10.00 sec 21.4 MBytes 18.0 Mbits/sec0 sender
>> [ 5] 0.00-10.04 sec 21.2 MBytes 17.7 Mbits/sec
>> receiver
>>
>> 3) running wpa_supplicant and psk2
>> 4) running ibss on ch 176 with AREDN channels on top of 18.06.2
>> 5) on one reboot, one of the stations stayed down at initial 196, then
>> bumped up to ~250 range and stayed there, link not functional. Not
>> sure how to explain this value...
>>
>> Question, can this condition be true periodically while the link is
>> live or only at initial 802.11 adhoc link setup?:
>>
>> if (ieee80211_is_assoc_req(hdr->frame_control) ||
>> ieee80211_is_assoc_resp(hdr->frame_control) ||
>> ieee80211_is_auth(hdr->frame_control)) {
>>
I do not think so since AFAIK auth frames are sent just during ibss join
>> 6) Auto distance stayed at initial 196 when turning off encryption.
>>
>> Any ideas of alternative options of packets to key off in late ack
>> situation? running wpad-mini is ~500k file size and RAM consumer.
>> It would be beneficial to take wpa_supplicant out of the equation if
>> at all possible.
>>
What is mandatory are unicast frames during joining phase, maybe you can
develop an userspace daemon for this purpose
>> Joe
Regards,
Lorenzo
From 72f4ba6f6b6021fcc48d07d03407c2fdb16a46c5 Mon Sep 17 00:00:00 2001
Message-Id: <72f4ba6f6b6021fcc48d07d03407c2fdb16a46c5.1554035972.git.lore...@kernel.org>
In-Reply-To:
References:
From: Lorenzo Bianconi
Date: Sun, 31 Mar 2019 14:38:49 +0200
Subject: [PATCH] ath: dynack: set max timeout according to clockrate
Signed-off-by: Lorenzo Bianconi
---
drivers/net/wireless/ath/ath9k/dynack.c | 36 ++---
1 file changed, 26 insertions(+), 10 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/dynack.c b/drivers/net/wireless/ath/ath9k/dynack.c
index f112fa5b2eac..0627111249dd 100644
--- a/drivers/net/wireless/ath/ath9k/dynack.c
+++ b/drivers/net/wireless/ath/ath9k/dynack.c
@@ -20,11 +20,24 @@
#define COMPUTE_TO (5 * HZ)
#define LATEACK_DELAY (10 * HZ)
-#define LATEACK_TO 256
-#define MAX_DELAY 300
#define EWMA_LEVEL 96
#define EWMA_DIV 128
+/**
+ * ath_dynack_get_max_to - set max timeout according to clockrate
+ * @ah: ath hw
+ *
+ */
+static u32 ath_dynack_get_max_to(struct ath_hw *ah)
+{
+ struct ath_common *common = ath9k_hw_common(ah);
+
+ if (common->clockrate)
+ return AR_TIME_OUT_ACK / common->clockrate;
+
+ return 300;
+}
+
/**
* ath_dynack_ewma - EWMA (Exponentially Weighted Moving Average) calculation
*
@@
Re: [OpenWrt-Devel] [PATCH v3 4/7] uboot-tegra: add U-Boot for tegra boards
Hi Jo, W dniu 31.03.2019 o 14:30, Jo-Philipp Wich pisze: > Hi Tomasz, > >> BTW Is there somewhere a list of packages installed on buildbots and is the >> list consistent across all of them? > > we're slowly converging towards this: > > apt-get install -y \ > pwgen \ > locales \ > buildbot-slave \ > build-essential \ > git-core \ > subversion \ > libncurses5-dev \ > gawk \ > unzip \ > wget \ > curl \ > ccache \ > rsync > > on top of a Debian 9 base image. The effective resulting package list is > attached to this mail. Thank You for this list, it'll help in future contributions to avoid breakages. > > The packages installed are not yet consistent among all slaves but the > list attached to this mail should be the common subset. Would be nice to see this list on OpenWrt documentation, after all builbots setups are identical. > > ~ Jo > Regards -- TMN ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v3 4/7] uboot-tegra: add U-Boot for tegra boards
W dniu 31.03.2019 o 14:12, Tomasz Maciej Nowak pisze: > W dniu 31.03.2019 o 00:01, Hauke Mehrtens pisze: >> On 3/28/19 5:20 PM, Tomasz Maciej Nowak wrote: >>> Add U-Boot for NVIDIA Tegra based boards, with the first being CompuLab >>> TrimSlice. This is part of initial support for this board. >>> >>> Signed-off-by: Tomasz Maciej Nowak >>> --- >> >> U-Boot uses binman for tegra and binman needs swig to build. >> In mainline U-Boot sunxi, tegra and x86 are using binman for building >> and depend on swig at build time. On sunxi I patched this dependency >> out, but I do not know how we should handle this here? > > Thanks for pointing this out. Looks like tegra has already definition in > place for building without binman[1], so deleting 'select BINMAN' from > arch/arm/mach-tegra/Kconfig lets the package build without swig. > After testing on the hardware, I'll send next iteration of the patches. > >> >> "apt install swig" solves the problem for me, I do not know if we can >> easily build swig in the tools and if this would be sufficient. > > Following documentation[2] it needs libpcre, but I don't have any insight if > we can rely on host library or should provide one in tools. Anyway U-Boot is > building fine *for now* without it. Oh wait, if it links against libpcre, that would definitely require us to provide libpcre in tools, but as mentioned swig is not required, for now. > > BTW Is there somewhere a list of packages installed on buildbots and is the > list consistent across all of them? > > 1. > http://git.denx.de/?p=u-boot.git;a=blob;f=Makefile;h=c1af9307b38e2b941d651bc316dcdf82e1bff8e6#l1363 > 2. http://swig.org/Doc4.0/Preface.html#Preface_unix_installation > >> >> Hauke >> > > Regards > Regards -- TMN ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v3 4/7] uboot-tegra: add U-Boot for tegra boards
Hi Tomasz, > BTW Is there somewhere a list of packages installed on buildbots and is the > list consistent across all of them? we're slowly converging towards this: apt-get install -y \ pwgen \ locales \ buildbot-slave \ build-essential \ git-core \ subversion \ libncurses5-dev \ gawk \ unzip \ wget \ curl \ ccache \ rsync on top of a Debian 9 base image. The effective resulting package list is attached to this mail. The packages installed are not yet consistent among all slaves but the list attached to this mail should be the common subset. ~ Jo root@1be523fcdeb0:/# dpkg --get-selections adduser install apt install base-files install base-passwd install bashinstall binutilsinstall bsdutilsinstall build-essential install buildbot-slave install bzip2 install ca-certificates install ccache install coreutils install cpp install cpp-6 install curlinstall dashinstall debconf install debian-archive-keyring install debianutils install diffutils install dirmngr install dpkginstall dpkg-devinstall e2fslibs:amd64 install e2fsprogs install fakerootinstall fileinstall findutils install g++ install g++-6 install gawkinstall gcc install gcc-6 install gcc-6-base:amd64install git install git-coreinstall git-man install gnupg install gnupg-agent install gnupg-l10n install gosuinstall gpgvinstall grepinstall gzipinstall hostnameinstall init-system-helpers install iproute2install iputils-pinginstall krb5-localesinstall lessinstall libacl1:amd64 install libalgorithm-diff-perl install libalgorithm-diff-xs-perl install libalgorithm-merge-perl install libapr1:amd64 install libaprutil1:amd64 install libapt-pkg5.0:amd64 install libasan3:amd64 install libassuan0:amd64install libatomic1:amd64install libattr1:amd64 install libaudit-common install libaudit1:amd64 install libblkid1:amd64 install libbsd0:amd64 install libbz2-1.0:amd64install libc-bininstall libc-dev-bininstall libc-l10n install libc6:amd64 install libc6-dev:amd64 install libcap-ng0:amd64install libcap2:amd64 install libcc1-0:amd64 install libcilkrts5:amd64 install libcomerr2:amd64
Re: [OpenWrt-Devel] [PATCH v3 4/7] uboot-tegra: add U-Boot for tegra boards
W dniu 31.03.2019 o 00:01, Hauke Mehrtens pisze: > On 3/28/19 5:20 PM, Tomasz Maciej Nowak wrote: >> Add U-Boot for NVIDIA Tegra based boards, with the first being CompuLab >> TrimSlice. This is part of initial support for this board. >> >> Signed-off-by: Tomasz Maciej Nowak >> --- > > U-Boot uses binman for tegra and binman needs swig to build. > In mainline U-Boot sunxi, tegra and x86 are using binman for building > and depend on swig at build time. On sunxi I patched this dependency > out, but I do not know how we should handle this here? Thanks for pointing this out. Looks like tegra has already definition in place for building without binman[1], so deleting 'select BINMAN' from arch/arm/mach-tegra/Kconfig lets the package build without swig. After testing on the hardware, I'll send next iteration of the patches. > > "apt install swig" solves the problem for me, I do not know if we can > easily build swig in the tools and if this would be sufficient. Following documentation[2] it needs libpcre, but I don't have any insight if we can rely on host library or should provide one in tools. Anyway U-Boot is building fine *for now* without it. BTW Is there somewhere a list of packages installed on buildbots and is the list consistent across all of them? 1. http://git.denx.de/?p=u-boot.git;a=blob;f=Makefile;h=c1af9307b38e2b941d651bc316dcdf82e1bff8e6#l1363 2. http://swig.org/Doc4.0/Preface.html#Preface_unix_installation > > Hauke > Regards -- TMN ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] base-files/hotplug: add "dialout" user group and use it for ttyXYZ devices
Hi Michael, > well, it seems that the second commit did not survive (at least in master > branch)... indeed, it was broken by an improperly rebased commit: https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=5209cfa534293cb6d27574b51d03bd69a5defb0c I'd be fine with a v2 which reintroduces the lost hunk and renames tty to dialout at the same time. ~ Jo signature.asc Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
