13.08.2018 08:23, John Crispin:
Hi
this following chunk need to be annotated and sent upstream. also using
initvals might not be the best option. please also check if there is a
binding doc and add this new property.
You might want to name the property "lines-initial-states" as defined
for
Hi,
personally I'm opposed to the entire code load thing.
First of all I was unable to reproduce the tarballs offered by Github.
Github seems to use an extended tar (pax) format while we pack our SCM
clones using the more traditional ustar format, however even using `tar
-cp -H pax --numeric-own
"Daniel F. Dickinson" wrote:
> Posting on list as I think the discussion should include as
> folks as possible in the discussion.
>
> https://github.com/openwrt/packages/issues/6745
>
> > Especially when getting started with OpenWrt finding things in menuconfig
> > is complicated by the second
On 2018-08-13 06:19 AM, Karl Palsson wrote:
>
> "Daniel F. Dickinson" wrote:
>> Posting on list as I think the discussion should include as
>> folks as possible in the discussion.
>>
>> https://github.com/openwrt/packages/issues/6745
>>
>>> Especially when getting started with OpenWrt finding thi
Refreshed all patches.
Compile-tested on: adm5120, adm8668, au1000, mcs814x, ppc40x, ppc44x, xburst
Runtime-tested on: none
Signed-off-by: Koen Vandeputte
---
include/kernel-version.mk | 4 +-
.../patches-3.18/007-adm5120_pci.patch| 2 +-
.../101-cfi_fixup_macronix
This target is on 4.9 currently.
It seems the support for this old kernel never got dropped.
Signed-off-by: Koen Vandeputte
---
target/linux/ar7/config-3.18 | 129
.../001-mips-ar7-fix-serial.patch | 23 --
...re-the-port-type-s-FCR-value-is-used.patch | 4
On Sun, 12 Aug 2018 at 14:41, Enrico Mioso wrote:
>
> If a new section with the same name and type of an old one is found, a
> memory reallocation happens. Still, the options list for the section is
> not reinitialized, hence a stale pointer is being used.
>
> Signed-off-by: Enrico Mioso
> ---
>
On 13/08/18 11:45, Jo-Philipp Wich wrote:
So TLDR; I prefer a locally reproducible, cached tarball of a given SCM
clone over an opaque Github offer.
I would like to second that notion
John
___
openwrt-devel mailing list
openwrt-devel@lists.open
Hi,
as 19.01 will probably use v4.14 as baseline and ath79 wont be a full
replacement for ar71xx by then we decided to bump ar71xx to v4.14. This
is available for testing inside my staging tree ->
https://git.openwrt.org/?p=openwrt/staging/blogic.git;a=shortlog;h=refs/heads/staging
The tree
Add support for the ar71xx supported Tp_link MR-3040 v2 to ath79.
Signed-off-by: Dmitry Tunin
---
.../linux/ath79/base-files/etc/board.d/02_network | 1 +
.../linux/ath79/dts/ar9331_tplink_tl-mr3040-v2.dts | 161 +
target/linux/ath79/image/tiny-tp-link.mk | 10 +
2018-08-13 18:28 GMT+02:00 Dmitry Tunin :
> Add support for the ar71xx supported Tp_link MR-3040 v2 to ath79.
>
> Signed-off-by: Dmitry Tunin
> ---
> .../linux/ath79/base-files/etc/board.d/02_network | 1 +
> .../linux/ath79/dts/ar9331_tplink_tl-mr3040-v2.dts | 161
> +
>
13.08.2018 19:34, Mathias Kresin пишет:
2018-08-13 18:28 GMT+02:00 Dmitry Tunin :
Add support for the ar71xx supported Tp_link MR-3040 v2 to ath79.
Signed-off-by: Dmitry Tunin
---
.../linux/ath79/base-files/etc/board.d/02_network | 1 +
.../linux/ath79/dts/ar9331_tplink_tl-mr3040-v2.dt
13.08.2018 19:34, Mathias Kresin пишет:
2018-08-13 18:28 GMT+02:00 Dmitry Tunin :
Add support for the ar71xx supported Tp_link MR-3040 v2 to ath79.
Signed-off-by: Dmitry Tunin
---
.../linux/ath79/base-files/etc/board.d/02_network | 1 +
.../linux/ath79/dts/ar9331_tplink_tl-mr3040-v2.dt
On Mon, Aug 13, 2018 at 2:45 AM Jo-Philipp Wich wrote:
>
> Hi,
>
> personally I'm opposed to the entire code load thing.
>
> First of all I was unable to reproduce the tarballs offered by Github.
>
> Github seems to use an extended tar (pax) format while we pack our SCM
> clones using the more tra
On 2018-08-13 01:45 PM, Rosen Penev wrote:
>> Furthermore I dislike the idea of tailoring download mechanisms around a
>> specific proprietary service.
This I agree with
>>
>> If the allegations about hash changes for unknown reasons are correct,
>> then this raises a huge red flag for me
> I ca
Hi,
I've won the prototype fund to work for the next 6 months on building
up an automated hardware testing infrastructure [0].
I'll use LAVA [1] for it. The rough idea is to bootstrap an
infrastructure for hw tests which also allow the community to
contribute.
Documentation is part of project wh
Hello, and thank you for your help, and review.
I agree on not changing behaviour. the problem is not actually a memory leak,
but the fact that ptr->s->options seems to not be a valid pointer at that point.
At least, this is what valgrind suggested, if I am not wrong or interpreting
wrongly the o
On Tue, 14 Aug 2018 at 04:56, Enrico Mioso wrote:
>
> Hello, and thank you for your help, and review.
> I agree on not changing behaviour. the problem is not actually a memory leak,
> but the fact that ptr->s->options seems to not be a valid pointer at that
> point.
> At least, this is what valg
Hello!
First of all, thank you very very much for your patience and review.
You are right, my patch introduces an unintended change in behaviour, and
actually does not solve the problem.
That day I didn't see this.
However, I think it is still useful to report what happens here, even just for
t
19 matches
Mail list logo
