[LEDE-DEV] [PATCH] Allow sending a fd in a ubus_request

In the current implementation, a fd can be sent in the reply to an existing request which can be inefficient in certain cases. Example: when you want to create a pipe between two process with the help of a 3rd process acting as a manager: you need 3 pipe with the current implementation and only

Re: [LEDE-DEV] [PATCH] Allow sending a fd in a ubus_request

On 08/12/2016 13:47, amine.ahd wrote: > In the current implementation, a fd can be sent in the reply to an existing > request which can be inefficient in certain cases. > Example: when you want to create a pipe between two process with the help of > a 3rd process acting as a manager: you need 3

Re: [LEDE-DEV] [PATCH] kernel: add KERNEL_DEBUG_PINCTRL and KERNEL_DEBUG_GPIO

On 07/12/2016 22:44, Hauke Mehrtens wrote: > This makes it possible to activate the gpio and the pinctl debugging > from LEDE menuconfig. > > Signed-off-by: Hauke Mehrtens Acked-by: John Crispin > --- > config/Config-kernel.in | 8 > 1 file changed, 8 insertions(+) > > diff --git

Re: [LEDE-DEV] [PATCH] kernel: add TI tmp102 and tmp103 temperature sensors

On 07/12/2016 22:45, Hauke Mehrtens wrote: > This just adds the kmods for these kernel modules. > This is found on some Lantiq / Intel reference boards. > > Signed-off-by: Hauke Mehrtens > --- > package/kernel/linux/modules/hwmon.mk | 30 ++ > 1 file changed, 30 ins

Re: [LEDE-DEV] [PATCH 1/1] add support for overlaying rootfs content

On 07/12/2016 21:52, Karl Palsson wrote: > > Rafał Miłecki wrote: >> On 7 December 2016 at 16:44, Karl Palsson >> wrote: >>> How is this different from just reverting the commit that stopped >>> this from working? I'm all for this, don't get me wrong, but if a >>> package can just explicitly

Re: [LEDE-DEV] [PATCH] comgt-ncm: Add support for specifying profile index

> >/--- a/package/network/utils/comgt/files/getcardinfo.gcom />/+++ > >b/package/network/utils/comgt/files/getcardinfo.gcom />/@@ -6,7 +6,7 @@ > >opengt />/flash 0.1 />//>/:start />/- send "ATI^m" />/+ send "AT+CGMI^m" / > >/diff --git a/package/network/utils/comgt/files/ncm.json / > > >/diff --g

Re: [LEDE-DEV] [LEDE-DEV, 3/3, v3] uqmi: Prevent 'POLICY MISMATCH' error.

> > Add uqmi 'sync' command call to release stalled cid when preparing to > setup new connection. As a result it prevents 'POLICY MISMATCH' errors. > > Signed-off-by: Nickolay Ledovskikh

Re: [LEDE-DEV] [LEDE-DEV, 3/3, v3] uqmi: Prevent 'POLICY MISMATCH' error.

No. All this is not working if cid is not released for some reason. For example: we have multiple modems with external power source, if usb DATA cable connection is broken for some reason, the cid will not be released and new network connection will not be established until you release the cid manu

Re: [LEDE-DEV] [LEDE-DEV, 3/3, v3] uqmi: Prevent 'POLICY MISMATCH' error.

Matti Laakso [2016-12-08 15:39:57]: Hi, > I don't like the autoconnect at all, it being so unpredictable across > various models. This autoconnect feature should burn in hell :-) The funny thing about this feature is, that the behaviour is network specific[1] also. I still can't find some time

Re: [LEDE-DEV] [PATCH 1/2] armvirt: new target

On 7 December 2016 at 21:35, Felix Fietkau wrote: > On 2016-12-07 03:02, Yousong Zhou wrote: >> An ARM Cortex-A15 machine provided by QEMU. >> >> Kernel drivers enabled: >> >> - pl011, uart >> - pl031, rtc >> - pl061, gpio >> - pci-host-generic >> - virtio_{mmio,pci,net,blk,scsi,9p,console,ba

Re: [LEDE-DEV] [LEDE-DEV, 3/3, v3] uqmi: Prevent 'POLICY MISMATCH' error.

> This autoconnect feature should burn in hell :-) The funny thing about this > feature is, that the behaviour is network specific[1] also. Maybe. I'm not too familiar with qmi proto. I just catched this behaviour in our test environment and found pdf that says: "Gobi3000 devices, though, have the

Re: [LEDE-DEV] [LEDE-DEV, 3/3, v3] uqmi: Prevent 'POLICY MISMATCH' error.

Petr Štetiar writes: > Matti Laakso [2016-12-08 15:39:57]: > > Hi, > >> I don't like the autoconnect at all, it being so unpredictable across >> various models. > > This autoconnect feature should burn in hell :-) The funny thing about this > feature is, that the behaviour is network specific[1]

[LEDE-DEV] [PATCH v2 0/2] target: replace realview with new target armvirt

Changes since PATCH v1 - Enabled CONFIG_XZ_DEC_BCJ - Enabled squashfs rootfs Changes since RFC v1 - CONFIG_SMP enabled with CONFIG_NR_CPUS=4 - CPU_SUBTYPE changed from neon to neon-vfpv4 - Additional rootfs types exported: cpiogz, targz - virtio-9p and 9p-fs are now enabled - README now c

[LEDE-DEV] [PATCH v2 2/2] realview: drop the target

Signed-off-by: Yousong Zhou --- target/linux/realview/Makefile | 29 -- target/linux/realview/README | 12 - .../linux/realview/base-files/etc/board.d/00_model | 13 - .../realview/base-files/etc/board.d/02_network | 7 - target/linux/realview/ba

[LEDE-DEV] [PATCH v2 1/2] armvirt: new target

An ARM Cortex-A15 machine provided by QEMU. Kernel drivers enabled: - pl011, uart - pl031, rtc - pl061, gpio - pci-host-generic - virtio_{mmio,pci,net,blk,scsi,9p,console,balloon} - smp with NR_CPUS=4 - cpu-hotplug - ext4 - neon, vfp extensions support (otherwise userland will fail with

Re: [LEDE-DEV] [LEDE-DEV, 3/3, v3] uqmi: Prevent 'POLICY MISMATCH' error.

Bjørn Mork [2016-12-08 16:11:18]: Hi, > I don't think we can trust the modem firmware with complex features like > autoconnect. There are too many things that can go wrong. And we don't have > any way to debug or fix any of those issues when they.happen inside the > modem firmware "black box".

Re: [LEDE-DEV] What's the purpose / gain from using VARIANT?

On 8 December 2016 at 02:00, Florian Fainelli wrote: > On 12/07/2016 11:52 AM, Rafał Miłecki wrote: >> On 12/07/2016 08:36 PM, Sergey Ryazanov wrote: >>> On Wed, Dec 7, 2016 at 10:10 PM, Rafał Miłecki wrote: I'm aware some packages (e.g. upstream-ssl, hostapd, dnsmasq) use VARIANT.

Re: [LEDE-DEV] uqmi: re-enable autoconnect which was dropped without explanation

Hi Felix, just a small ping :) > On Petr Štetiar [2016-10-21 11:06:03]: > > Felix Fietkau [2016-10-20 12:09:36]: > > > On 2016-10-19 23:49, Petr Štetiar wrote: > > > > > > How to fix it for both use cases, with and without autoconnect feature? > > > Introduce qmi_autoconnect config option? >

[LEDE-DEV] Kernel Oops / panic

Hi, I'm using a TP-Link Archer C7 (Atheros AR7xxx/AR9xxx). Since my build from 4.12.2016 ~12:00, the kernel crashes after 2..4 hours: [ 155.440310] pppoe-wan: renamed from ppp0 [ 6727.257095] CPU 0 Unable to handle kernel paging request at virtual address 0104, epc == 868c1310, ra == 868c1

[LEDE-DEV] Convert ar71xx to devicetree

Hi, one of the open ToDos for LEDE is 'Convert ar71xx to devicetree'. In the last weeks, I've tried some stuff to get myself an idea of what needs to be done. Currently, I'm in this state: -) AR9331 devices (TL-WR740-v4, TL-WR741-v4, TL-MR3020) boot up fine with DTB, -) (All?) of the device's hard

Re: [LEDE-DEV] Kernel Oops / panic

Hi, are you using snapshots or building the image yourself ? if it is self built then please enable KALLSYMS and paste the log. John On 08/12/2016 17:14, e9hack wrote: > Hi, > > I'm using a TP-Link Archer C7 (Atheros AR7xxx/AR9xxx). Since my build from > 4.12.2016 ~12:00, the kernel cr

Re: [LEDE-DEV] Convert ar71xx to devicetree

On 08/12/2016 17:17, p.wa...@gmx.at wrote: > Hi, > > one of the open ToDos for LEDE is 'Convert ar71xx to devicetree'. > In the last weeks, I've tried some stuff to get myself an idea of what > needs to be done. Currently, I'm in this state: > -) AR9331 devices (TL-WR740-v4, TL-WR741-v4, TL-MR30

Re: [LEDE-DEV] Kernel Oops / panic

Hi, it's my own build and KALLSYMS is enabled already. Which log shall I paste? Regards, Hartmut Am 08.12.2016 um 17:19 schrieb John Crispin: > Hi, > > are you using snapshots or building the image yourself ? if it is self > built then please enable KALLSYMS and paste the log. > > John >

Re: [LEDE-DEV] Convert ar71xx to devicetree

On 2016-12-08 17:31, John Crispin wrote: > Hi, > > i was planning to start working on this in early 2017. i was hoping that > rather than converting ar71xx to DT we simply create a new target called > ath79 and start moving board support over from the legacy to the new > target. this would allow u

Re: [LEDE-DEV] Convert ar71xx to devicetree

> rather than converting ar71xx to DT we simply create a new target called > ath79 and start moving board support over from the legacy to the new > target. this would allow us to make the ath79 target much cleaner than > having to worry about legacy cruft. That's what I meant with ar71xx-dt :) Yea

Re: [LEDE-DEV] Convert ar71xx to devicetree

On 08/12/2016 18:10, Felix Fietkau wrote: > On 2016-12-08 18:08, John Crispin wrote: >> >> >> On 08/12/2016 18:06, Felix Fietkau wrote: >>> On 2016-12-08 17:31, John Crispin wrote: Hi, i was planning to start working on this in early 2017. i was hoping that rather than convert

Re: [LEDE-DEV] Convert ar71xx to devicetree

On 2016-12-08 18:08, John Crispin wrote: > > > On 08/12/2016 18:06, Felix Fietkau wrote: >> On 2016-12-08 17:31, John Crispin wrote: >>> Hi, >>> >>> i was planning to start working on this in early 2017. i was hoping that >>> rather than converting ar71xx to DT we simply create a new target calle

Re: [LEDE-DEV] Convert ar71xx to devicetree

> I think it should not be too hard to support both DT and non-DT devices > with the same kernel. Also, in ar71xx patches, there's the 001-revert_spi_device_tree_support.patch which was introduced by Felix when switching to 4.4. (I've removed this patch now to get the SPI-NOR flash working) Witho

Re: [LEDE-DEV] Convert ar71xx to devicetree

On 2016-12-08 18:17, John Crispin wrote: > > > On 08/12/2016 18:10, Felix Fietkau wrote: >> On 2016-12-08 18:08, John Crispin wrote: >>> >>> >>> On 08/12/2016 18:06, Felix Fietkau wrote: On 2016-12-08 17:31, John Crispin wrote: > Hi, > > i was planning to start working on this in

Re: [LEDE-DEV] Convert ar71xx to devicetree

> > how would that be confusing ? i would argue the exact opposite > Because suddenly there are two targets and you have to look up which > device is supported by which target. We'd just fill ath79 with supported targets and can discuss, whether these supported devices should then disappear in ar7

Re: [LEDE-DEV] ramips: image validator and board variants

On 2016-12-06 17:54, John Crispin wrote: > > > On 05/12/2016 10:17, Mathias Kresin wrote: >> Hey John, Hey Felix >> >> I'm near to finished with porting the remaining ramips devices to the >> new image build code. While doing this, I might have spotted a ramips >> specific issue with the new ima

Re: [LEDE-DEV] Convert ar71xx to devicetree

On 08/12/2016 18:28, Felix Fietkau wrote: > On 2016-12-08 18:17, John Crispin wrote: >> >> >> On 08/12/2016 18:10, Felix Fietkau wrote: >>> On 2016-12-08 18:08, John Crispin wrote: On 08/12/2016 18:06, Felix Fietkau wrote: > On 2016-12-08 17:31, John Crispin wrote: >> Hi, >

Re: [LEDE-DEV] Convert ar71xx to devicetree

On 08/12/2016 18:06, Felix Fietkau wrote: > On 2016-12-08 17:31, John Crispin wrote: >> Hi, >> >> i was planning to start working on this in early 2017. i was hoping that >> rather than converting ar71xx to DT we simply create a new target called >> ath79 and start moving board support over from

Re: [LEDE-DEV] Convert ar71xx to devicetree

> Can you please share your work by putting it up in a tree somewhere? So should I create a fork of lede-project/source then (on github)? Keep in mind, it was/is just a proof of concept and still a lot of work has to be done for clean DT-hooks and other SoCs. But I'll split the changes into logica

Re: [LEDE-DEV] Convert ar71xx to devicetree

On 2016-12-08 18:27, p.wa...@gmx.at wrote: >> I think it should not be too hard to support both DT and non-DT devices >> with the same kernel. > > Also, in ar71xx patches, there's the > 001-revert_spi_device_tree_support.patch > which was introduced by Felix when switching to 4.4. > (I've removed

Re: [LEDE-DEV] Convert ar71xx to devicetree

On 2016-12-08 18:52, p.wa...@gmx.at wrote: >> Can you please share your work by putting it up in a tree somewhere? > > So should I create a fork of lede-project/source then (on github)? > Keep in mind, it was/is just a proof of concept and still a lot of work > has to be done for clean DT-hooks an

Re: [LEDE-DEV] Convert ar71xx to devicetree

On 2016-12-08 19:16, Felix Fietkau wrote: > On 2016-12-08 18:52, p.wa...@gmx.at wrote: >>> Can you please share your work by putting it up in a tree somewhere? >> >> So should I create a fork of lede-project/source then (on github)? >> Keep in mind, it was/is just a proof of concept and still a lo

[LEDE-DEV] RFC: removing support for old Atheros reference boards

Hi all, support code for some old ar71xx reference boards (e.g. AP83) carries quite a bit of specific code that bloats images. I consider it highly unlikely that anybody still actually uses this stuff, so I would like to propose removing support for the following devices: AP81 AP83 AP96 PB92 AP113

Re: [LEDE-DEV] RFC: removing support for old Atheros reference boards

On 2016-12-08 21:26, Felix Fietkau wrote: > Hi all, > > support code for some old ar71xx reference boards (e.g. AP83) carries > quite a bit of specific code that bloats images. I consider it highly > unlikely that anybody still actually uses this stuff, so I would like to > propose removing suppor

[LEDE-DEV] [Forum] Certificate expired

It's currently not possible to visit the forum with Firefox + Chrome: forum.lede-project.org verwendet ein ungültiges Sicherheitszertifikat. Das Zertifikat ist am Donnerstag, 8. Dezember 2016 20:00 abgelaufen. Die aktuelle Zeit ist Donnerstag, 8. Dezember 2016 22:01. Fehlercode: SEC_ERROR_EXPIRED_

Re: [LEDE-DEV] [Forum] Certificate expired

Thanks Thomas, will check in approx. one or two hours unless Ted beats me to it. ~ Jo > Am 08.12.2016 um 22:04 schrieb Thomas Endt : > > It's currently not possible to visit the forum with Firefox + Chrome: > > forum.lede-project.org verwendet ein ungültiges Sicherheitszertifikat. > Das Zerti

Re: [LEDE-DEV] [PATCH] kernel: add TI tmp102 and tmp103 temperature sensors

On 12/08/2016 02:00 PM, John Crispin wrote: > > > On 07/12/2016 22:45, Hauke Mehrtens wrote: >> This just adds the kmods for these kernel modules. >> This is found on some Lantiq / Intel reference boards. >> >> Signed-off-by: Hauke Mehrtens >> --- >> package/kernel/linux/modules/hwmon.mk | 30 +

[LEDE-DEV] [PATCH] kernel: make fix extending dtb cmd with bootloader

This was introduced in kernel 4.4, but broken there and fixed in 4.5. I would like to activate it, but I am scared about the boot loader around giving us all sorts of command lines. Signed-off-by: Hauke Mehrtens --- .../patches-4.4/094-MIPS-Fix-macro-typo.patch | 33 ++

Re: [LEDE-DEV] [Forum] Certificate expired

Hello Thomas, the cert actually got renewed properly but a hook was missing to reload the nginx process in order to pick up the updated certificates. I am very sorry for the inconvenience. ~ Jo signature.asc Description: OpenPGP digital signature __

Re: [LEDE-DEV] [Forum] Certificate expired

Nope, @jow - you won... /ted -Original Message- From: Jo-Philipp Wich Sent: Thursday, December 08, 2016 5:09 PM To: Thomas Endt Cc: lede-dev@lists.infradead.org Subject: Re: [LEDE-DEV] [Forum] Certificate expired Thanks Thomas, will check in approx. one or two hours unless Ted beats

[LEDE-DEV] [PATCH] kernel: Add kmod-ethoc

Add the kernel module package for the Opencores.org Ethernet MAC, depends on PHYLIB. Signed-off-by: Florian Fainelli --- package/kernel/linux/modules/netdevices.mk | 15 +++ 1 file changed, 15 insertions(+) diff --git a/package/kernel/linux/modules/netdevices.mk b/package/kernel/li

Re: [LEDE-DEV] RFC: removing support for old Atheros reference boards

On 08/12/2016 21:27, Felix Fietkau wrote: > On 2016-12-08 21:26, Felix Fietkau wrote: >> Hi all, >> >> support code for some old ar71xx reference boards (e.g. AP83) carries >> quite a bit of specific code that bloats images. I consider it highly >> unlikely that anybody still actually uses this s

Re: [LEDE-DEV] [PATCH] kernel: Add kmod-ethoc

On 09/12/2016 04:31, Florian Fainelli wrote: > Add the kernel module package for the Opencores.org Ethernet MAC, > depends on PHYLIB. > > Signed-off-by: Florian Fainelli > --- > package/kernel/linux/modules/netdevices.mk | 15 +++ > 1 file changed, 15 insertions(+) > > diff --git

Re: [LEDE-DEV] [PATCH] kernel: make fix extending dtb cmd with bootloader

On 09/12/2016 00:21, Hauke Mehrtens wrote: > This was introduced in kernel 4.4, but broken there and fixed in 4.5. > I would like to activate it, but I am scared about the boot loader > around giving us all sorts of command lines. > > Signed-off-by: Hauke Mehrtens we had previously used a synt

Re: [LEDE-DEV] [PATCH] package-ipkg: Do not fail build without base-files

Hi Florian On 06/12/2016 23:14, Florian Fainelli wrote: > If the base-files package is not selected, we will fail executing the > very first postinst script: > > make[3]: Leaving directory `/local/users/fainelli/openwrt/trunk' > cp -fpR > /local/users/fainelli/openwrt/trunk/build_dir/target-arm_x