Hi Florian,
i merged most of these, waiting for repo access for the remaining 3 patches
John
On 01/07/2016 23:57, Florian Fainelli wrote:
> Both ubusd and cli TARGET_LINK_LIBRARIES reference ${json} which is
> obtained via find_library(), but since the find_library() is searched
> after
Hi Steven,
can you please give me commit access to the odhcp* repos so that i can
merge fixes such as this one --> https://patchwork.ozlabs.org/patch/643331/
John
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org
Add a CMake FIND_PATH and INCLUDE_DIRECTORIES searching for
libubox/uloop.h. Some external toolchains which do not include standard
locations would fail to find the header otherwise.
Signed-off-by: Florian Fainelli
---
CMakeLists.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/CMakeLi
On 07/01/2016 04:05 PM, Florian Fainelli wrote:
> Add a CMake FIND_PATH and INCLUDE_DIRECTORIES searching for uci.h. Some
> external toolchains which do not include standard locations would fail
> to find the header otherwise.
>
> Signed-off-by: Florian Fainelli
Forgot to put it in the title, th
Add a CMake FIND_PATH and INCLUDE_DIRECTORIES searching for
libubox/ulog.h. Some external toolchains which do not include standard
locations would fail to find the header otherwise.
Signed-off-by: Florian Fainelli
---
CMakeLists.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/CMakeLi
Add a CMake FIND_PATH and INCLUDE_DIRECTORIES searching for
libubox/list.h. Some external toolchains which do not include standard
locations would fail to find the header otherwise.
Signed-off-by: Florian Fainelli
---
CMakeLists.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/CMakeLi
Add a CMake FIND_PATH and INCLUDE_DIRECTORIES searching for
libubox/uloop.h. Some external toolchains which do not include standard
locations would fail to find the header otherwise.
Signed-off-by: Florian Fainelli
---
CMakeLists.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/CMakeLi
block uses libblob_msgjson which requires us to link against libjson-c.
Some external toolchains would be failing to find that library unless
specified explicitly.
Signed-off-by: Florian Fainelli
---
CMakeLists.txt | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/CMakeLi
Add a CMake FIND_PATH and INCLUDE_DIRECTORIES searching for uci.h. Some
external toolchains which do not include standard locations would fail
to find the header otherwise.
Signed-off-by: Florian Fainelli
---
CMakeLists.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/CMakeLists.txt b/
Add a CMake FIND_PATH and INCLUDE_DIRECTORIES searching for
libubox/utils.h. Some external toolchains which do not include standard
locations would fail to find the header otherwise.
Signed-off-by: Florian Fainelli
---
CMakeLists.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/CMakeLi
Add a CMake FIND_PATH and INCLUDE_DIRECTORIES searching for
libubox/ustream-ssl.h. Some external toolchains which do not include
standard locations would fail to find the header otherwise.
Signed-off-by: Florian Fainelli
---
CMakeLists.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/
Add a CMake FIND_PATH and INCLUDE_DIRECTORIES searching for
libubox/ustream-ssl.h. Some external toolchains which do not include
standard locations would fail to find the header otherwise.
Signed-off-by: Florian Fainelli
---
CMakeLists.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/
Both ubusd and cli TARGET_LINK_LIBRARIES reference ${json} which is
obtained via find_library(), but since the find_library() is searched
after the TARGET_LINK_LIBRARIES for ubusd, ubusd always gets an empty
${json} variable.
examples/server also links against libjson-c, but we were not setting
TA
Hi Thomas,
Another missing thing is instruction set.
May I have 2 new items there: ARC and ARCv2?
-Alexey
On Fri, 2016-07-01 at 21:01 +0200, Thomas Endt wrote:
> Hey Alexey,
>
> nice to see that you are actively working on these targets!
> Targets arc770, archs38 added.
>
> Let me know when yo
On Thursday, June 30, 2016 10:16:42 PM Hauke Mehrtens wrote:
> On 06/30/2016 09:07 PM, John Crispin wrote:
> > i have already added this to my staging tree, feel free to send a ptch
> > that i can fold into haukes patch
> >
> > John
>
> I already pushed this, but send a patch to improve this
From: Mathias Kresin
Signed-off-by: Mathias Kresin
Signed-off-by: Martin Blumenstingl
---
.../100-remove-cryptoapi-dependencies.patch| 90 --
.../mac80211/patches/530-ath9k_extra_leds.patch| 12 +--
...mfmac-register-wiphy-s-during-module_init.patch | 2 +-
...
This folds 550-ath9k_add_ar9280_gpio_chip.patch into
548-ath9k_enable_gpio_chip.patch because the former patch only extends
code which is introduced in the latter.
Signed-off-by: Martin Blumenstingl
---
.../patches/548-ath9k_enable_gpio_chip.patch | 14 ++-
.../patches/549-ath9k_en
This enables ath9k's built-in GPIO controller for all chip versions
(instead of an explicit whitelist). This also allows us to get rid of
some duplicate code between hw.c and gpio.c because hw.c already
determines the number of GPIOs.
Signed-off-by: Martin Blumenstingl
---
.../patches/548-ath9k_
This allows gpiolib to re-use ath9k's devicetree node as GPIO
controller.
Example:
ath9k: ath9k@0 {
#gpio-cells = <2>;
gpio-controller;
}
Now the ath9k node can be used just like any other GPIO controller:
gpios = <&ath9k 1 GPIO_ACTIVE_HIGH>;
Signed-off-by: Martin Blumens
This re-uses the "number of GPIOs" which are already configured per
ath9k chip/revision during chip initialization in hw.c's
ath9k_hw_fill_cap_info().
It also sets the parent device of the GPIO controller which is not only
good practice, but it will also allow using the ath9k device as GPIO
control
Signed-off-by: Rafał Miłecki
---
Unfortunately I didn't manage to get jekyll2.0 build page locally for me. I hope
the syntax is OK.
---
_includes/docs_nav.html | 1 +
docs/rpcd.txt | 14 ++
2 files changed, 15 insertions(+)
create mode 100644 docs/rpcd.txt
diff --git a/_i
Hi Felix,
1) Just set a non-allowed DFS channel for DE, for instance.
2) Enable wireless; it fails
3) Change to a valid channel; the wdev is not set up.
There is also a leftover on /etc/init.d/network reload. I think it should call
/sbin/wifi instead of /sbin/wifi reload.
Eduardo
On 01.07.20
On 2016-06-30 01:17, Martin Blumenstingl wrote:
> This re-uses the "number of GPIOs" which are already configured per
> ath9k chip/revision during chip initialization in hw.c's
> ath9k_hw_fill_cap_info().
> It also sets the parent device of the GPIO controller which is not only
> good practice, but
This only happens once in a while.
[ 35.04] wlan0: Trigger new scan to find an IBSS to join
[ 37.04] wlan3: Trigger new scan to find an IBSS to join
[ 37.05] wlan1: Trigger new scan to find an IBSS to join
[ 37.05] wlan2: Trigger new scan to find an IBSS to join
[ 37.71
On 01/07/2016 09:14, Jurgen Van Ham wrote:
> Dear all,
>
> The current version of procd can respond to a failing daemon by
> respawning it. This works for daemons that no (or not many) daemons
> rely on.
>
> Is there an elegant way to cause a restart after critical service
> dies. With critical
Ok, I'll try this and once I confirm that it behaves as expected, I'll
publish the patch here.
On Fri, Jul 1, 2016 at 10:26 AM, John Crispin wrote:
>
>
> On 01/07/2016 08:45, Jurgen Van Ham wrote:
>> Dear all,
>>
>> Procd supports instance_writepid and instance_removepid in the file
>> instance.
On 01/07/2016 08:45, Jurgen Van Ham wrote:
> Dear all,
>
> Procd supports instance_writepid and instance_removepid in the file
> instance.c.
> The removepid is called when stopping a daemon or restarting it.
> However, when a daemon
> dies and it is not configured to respawn the pidfile is not
Hi Thomas,
On Fri, 2016-07-01 at 02:12 +0200, Thomas Endt wrote:
>
>
> Hi Alexey,
>
> Those two targets are not listed at https://dev.openwrt.org/wiki/platforms.
Hm looks like I need to ask somebody to add info to that page because even if
logged in
I don't see any "edit" button.
>
>
> Are
Dear all,
The current version of procd can respond to a failing daemon by
respawning it. This works for daemons that no (or not many) daemons
rely on.
Is there an elegant way to cause a restart after critical service
dies. With critical I mean that a mere restart would require too many
actions fr
29 matches
Mail list logo
