Re: [LEDE-DEV] issue with rt61-pci

[Eddi De Pieri]

Hi,

It seems that this issue is due to DMA. But... i can't find where is
the setup of dma for pci bus for bcm6358

Regards

On Sun, Sep 25, 2016 at 9:39 AM, Eddi De Pieri  wrote:
> Hi,
>
> I've just flashed an old device with onboard a rt2661 pci card.
>
>
> Lede-Trunk/Openwrt 15 and trunk:
> by using the wifi card(AP mode) dmesg show:
> [  257.472000] ieee80211 phy1: rt61pci_txdone: Warning - TX status
> report missed for entry 28
> [  257.48] ieee80211 phy1: rt61pci_txdone: Warning - TX status
> report missed for entry 29
> [  257.488000] ieee80211 phy1: rt61pci_txdone: Warning - TX status
> report missed for entry 30
> [  257.496000] ieee80211 phy1: rt61pci_txdone: Warning - TX status
> report missed for entry 31
> [  257.504000] ieee80211 phy1: rt61pci_txdone: Warning - TX status
> report missed for entry 1
> (don't remember which distribution i used to get this log... but all
> suffer of the same issue)
>
> and after few seconds of usage the wifi card stop working and it need
> a reboot or rmmod rt61-pci/modprobe to make it work again for few
> seconds
>
> root@OpenWrt:/lib/firmware# lspci -v
> 00:01.0 Network controller: Ralink corp. RT2600 802.11 MIMO
> Subsystem: Ralink corp. Device 2661
> Flags: bus master, slow devsel, latency 64, IRQ 39
> Memory at 3000 (32-bit, non-prefetchable) [size=32K]
> Memory at  (32-bit, non-prefetchable) [size=2]
> Memory at  (32-bit, non-prefetchable) [size=2]
> Memory at  (32-bit, non-prefetchable) [size=2]
> Memory at  (32-bit, non-prefetchable) [size=2]
> Memory at  (32-bit, non-prefetchable) [size=2]
> Expansion ROM at  [disabled] [size=2]
> Capabilities: [40] Power Management version 2
> Kernel driver in use: rt61pci
> lspci: Unable to load libkmod resources: error -12
>
> root@OpenWrt:/proc/irq/39# cat /proc/interrupts
>CPU0
>   0:  0  MIPS   0  smp_ipi0
>   1:  0  MIPS   1  smp_ipi1
>   7:7906287  MIPS   7  timer
>   8:  0  bcm6345-periph-intc   0  bcm63xx_timer
>  10: 27  bcm6345-periph-intc   2  bcm63xx_uart
>  13:  1  bcm6345-periph-intc   5  ohci_hcd:usb2
>  14:  6  bcm6345-periph-intc   6  eth1
>  17:  0  bcm6345-periph-intc   9  phy_interrupt
>  18:  0  bcm6345-periph-intc  10  ehci_hcd:usb1
>  25: 168436  bcm6345-periph-intc  17  eth1
>  26:  96231  bcm6345-periph-intc  18  eth1
>  39: 492016  bcm6345-periph-intc  31  rt61pci
> ERR:  0
> root@OpenWrt:/proc/irq/39#
>
>
> it seems that other people even on desktop systems get same error and
> is not clear if it is solved on latest ubuntu as well there is already
> a ticket opened on openwrt: https://dev.openwrt.org/ticket/18228
>
> On Openwrt 12.09 work correctly.
>
> Have you any idea about what could have introduced this regression?
> I've seen that between 3.3.8 and later kernel we use DTS, perhaps is
> missing some definitions for pirelli a226m device or something else
> more cfg80211 related?
>
>  ATTITUDE ADJUSTMENT (12.09, r36088)
>
> root@OpenWrt:/# cat /proc/version
> Linux version 3.3.8 (blogic@Debian-60-squeeze-64-minimal) (gcc version
> 4.6.3 20120201 (prerelease) (Linaro GCC 4.6-2012.02) ) #1 Sat Mar 23
> 18:09:20 UTC 2013
>
> root@OpenWrt:/# cat /proc/interrupts
>CPU0
>   2:  0  MIPS  cascade_ip2
>   7: 479612  MIPS  timer
>   8:  0  bcm63xx_ipic  bcm63xx_timer
>  10:  18149  bcm63xx_ipic  bcm63xx_uart
>  14: 19  bcm63xx_ipic  eth1
>  17:  0  bcm63xx_ipic  phy_interrupt
>  25: 247853  bcm63xx_ipic  eth1
>  26: 117400  bcm63xx_ipic  eth1
>  39: 552385  bcm63xx_ipic  :00:01.0
> ERR:  0
>
> root@OpenWrt:/# lspci -v
> 00:01.0 Network controller: Ralink corp. RT2600 802.11 MIMO
> Subsystem: Ralink corp. Device 2661
> Flags: bus master, slow devsel, latency 64, IRQ 39
> Memory at 3000 (32-bit, non-prefetchable) [size=32K]
> Capabilities: [40] Power Management version 2
> Kernel driver in use: rt61pci
>
> 01:1e.0 CardBus bridge: Broadcom Corporation Device 6358
> Subsystem: Broadcom Corporation Device 6358
> Flags: bus master, slow devsel, latency 0, IRQ 39
> Bus: primary=01, secondary=02, subordinate=05, sec-latency=176
> Memory window 0: -0fff
> Memory window 1: 0001-0fff
> I/O window 0: -0003
> I/O window 1: -0003
>
> Regards
> Eddi De Pieri

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] [PATCH] scripts/feeds: use git rev-parse for getting revision

[Rafał Miłecki]

From: Rafał Miłecki 

It provides simpler output so we don't need extra head and cut commands.

Signed-off-by: Rafał Miłecki 
---
 scripts/feeds | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/scripts/feeds b/scripts/feeds
index 481eb9b..81cf1f0 100755
--- a/scripts/feeds
+++ b/scripts/feeds
@@ -130,19 +130,19 @@ my %update_method = (
'init_commit'   => "git clone '%s' '%s' && cd '%s' && git 
checkout -b '%s' '%s' && cd -",
'update'=> "git pull --ff",
'controldir'=> ".git",
-   'revision'  => "git show --abbrev-commit HEAD | head -n 1 | 
cut -d ' ' -f 2 | tr -d '\n'"},
+   'revision'  => "git rev-parse --short HEAD | tr -d '\n'"},
'src-git-full' => {
'init'  => "git clone '%s' '%s'",
'init_branch'   => "git clone --branch '%s' '%s' '%s'",
'init_commit'   => "git clone '%s' '%s' && cd '%s' && git 
checkout -b '%s' '%s' && cd -",
'update'=> "git pull --ff",
'controldir'=> ".git",
-   'revision'  => "git show --abbrev-commit HEAD | head -n 1 | 
cut -d ' ' -f 2 | tr -d '\n'"},
+   'revision'  => "git rev-parse --short HEAD | tr -d '\n'"},
'src-gitsvn' => {
'init'  => "git svn clone -r HEAD '%s' '%s'",
'update'=> "git svn rebase",
'controldir'=> ".git",
-   'revision'  => "git show --abbrev-commit HEAD | head -n 1 | 
cut -d ' ' -f 2 | tr -d '\n'"},
+   'revision'  => "git rev-parse --short HEAD | tr -d '\n'"},
'src-bzr' => {
'init'  => "bzr checkout --lightweight '%s' '%s'",
'update'=> "bzr update",
-- 
2.10.1


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] kernel: update kernel 4.4 to version 4.4.30

[Rafał Miłecki]

On 2 November 2016 at 11:12,   wrote:
> If so, wouldn't it be clearer (for people like me :) ) if there were two
> seperate patches (i.e. one for kernel update+refreshes itself and one for the 
> internal
> refreshes (or refreshes that have been missed in previous updates) )?

It could be nice to have all patches properly formatted and updated
(refreshed) all the time, but it's sometimes easy to miss that.

I don't care about having commits *that* cleanly separated, as long as
refreshes are trivial, I'm OK with that. It may be you're spending
more time on this trivial issue than it's worth ;)

-- 
Rafał

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] kernel: update kernel 4.4 to version 4.4.30

[Hannu Nyman]

On 2.11.2016 13:48, p.wa...@gmx.at wrote:


I come to this conclusion: it may happen, that local changes/patches have
effect on other patches in the chain, resulting in a fuzzed applying of these.


That is right. Patches are chained and 'quilt' applies them in order. The 
same file can be touched multiple times.



I'll give it a try an do the following: write a simple script that
-) downloads upstream kernel
-) applies local generic patches
-) then, one-by-one, applies platform patches
if all patches are refreshed correctly, there shouldn't be any FAILED or
fuzz results.


I would have thought that the "refresh all kernel platforms" script from 
Kanjimonster (Jonas Gorski) that was linked yesterday in this message thread 
by Stijn Segers would do just that when applied to the current kernel 
version. But if you want to write another tool for that, feel free.



  (I've done all my patches using 'diff' and am using 'git diff'
for a month or so to do so, so I have no idea of 'quilt' and other tools :) )


You need to familiarize yourself with quilt basics if you seriously think 
about modifying kernel-related stuff here, as the local changes to kernel are 
done via patches. So you are always working with patch chains (and changes to 
them are patches that modify patches...). Some advice can be found in 
https://wiki.openwrt.org/doc/devel/patches



___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] kernel: update kernel 4.4 to version 4.4.30

[p . wassi]

Thank you Hannu for taking you time and writing those lines, which clarify
the whole situation for me. Now I also understand why the mvebu-patch is done 
here.

If I take some of your words
> From Openwrt/LEDE perspective, the kernel source is the original kernel
> source + the ~100 generic + the 10-50 platform-specific patches.

> So, that patch 053- got refreshed now to match the new reality (of the added
> rango line by the current 010- ).

> Yeah, there could be a separate "refresh patches for earlier changes" patch 
> before the kernel bump, but that would just be additional work (...)

I come to this conclusion: it may happen, that local changes/patches have
effect on other patches in the chain, resulting in a fuzzed applying of these.
I'll give it a try an do the following: write a simple script that
-) downloads upstream kernel
-) applies local generic patches
-) then, one-by-one, applies platform patches
if all patches are refreshed correctly, there shouldn't be any FAILED or
fuzz results. Those could then be reported to find such 'issues' just in time
(before the kernel bump). Furthermore this intermediate refreshing could
also be automated? (I've done all my patches using 'diff' and am using 'git 
diff'
for a month or so to do so, so I have no idea of 'quilt' and other tools :) )
I agree on you, that seperating kernel-refreshing and internal refreshing is
additional work, but if the process of internal refreshing could be automated,
it would detect issues introduces by local changes (which may result in a fuzz)
on time and in the same turn shorten kernel bumps+refreshing.
I mean if I sent in a patch that introduced such issues, I'd be glad to know
on time in order to be more careful at the next patch. If my patch caused those
'problems' (offsets), I'd not notice them a week/weeks later during a kernel 
upgrade.

Or am I overall totally going in the wrong direction and refreshing is not that
big deal I'm currently facing?

Best regards,
P. Wassi

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] include: Cortex-A53 is an aarch64 CPU

[Felix Fietkau]

On 2016-11-01 20:46, Florian Fainelli wrote:
> Fixes: SVN 48964
> Signed-off-by: Florian Fainelli 
> ---
>  include/target.mk | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/target.mk b/include/target.mk
> index c9c02fa03632..94d9570de387 100644
> --- a/include/target.mk
> +++ b/include/target.mk
> @@ -187,7 +187,6 @@ ifeq ($(DUMP),1)
>  CPU_CFLAGS_cortex-a8 = -mcpu=cortex-a8
>  CPU_CFLAGS_cortex-a9 = -mcpu=cortex-a9
>  CPU_CFLAGS_cortex-a15 = -mcpu=cortex-a15
> -CPU_CFLAGS_cortex-a53 = -mcpu=cortex-a53
>  CPU_CFLAGS_fa526 = -mcpu=fa526
>  CPU_CFLAGS_mpcore = -mcpu=mpcore
>  CPU_CFLAGS_xscale = -mcpu=xscale
> @@ -212,6 +211,7 @@ ifeq ($(DUMP),1)
>ifeq ($(ARCH),aarch64)
>  CPU_TYPE ?= armv8-a
>  CPU_CFLAGS_armv8-a = -mcpu=armv8-a
> +CPU_CFLAGS_cortex-a53 = -mcpu=cortex-a53
>endif
>ifeq ($(ARCH),arc)
>  CPU_TYPE ?= arc700
Apparently the bcm2710 subtarget uses it in 32-bit mode, so it should be
valid for both types.

- Felix

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] kernel: update kernel 4.4 to version 4.4.30

[Stijn Segers]

Stijn Segers schreef op 2016-11-02 09:44:

On 2016-11-02 03:17, Outback Dingo wrote:
[...]



I find it quite odd that it doesnt apply cleanly to my LEDE tree at 
git rev


commit 411babb28a3091f693832fb30d475aa1e99c6d11
which is a merge of the latest ipfilters changes



That's weird... Can't check now, at work, will check this evening.

Stijn


Stintel confirmed me the patch is fine, so that means the error is at 
your end...


Patch has already been accepted in LEDE's patchwork as well, of course 
that doesn't guarantee it doesn't break, but still.


Stijn

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] kernel: update kernel 4.4 to version 4.4.30

[Hannu Nyman]

p.wassi at gmx.at wrote on Wed Nov 2 03:12:32 PDT 2016:
> What may be my problem here is, that I'm totally stuck to the kernel 
changelog, which leads to my question: is it the case, that the patches 
getting refreshed here are not directly related to the upstream kernel changes.


Being "stuck to the upstream kernel changelog" is not enough. From 
Openwrt/LEDE perspective, the kernel source is the original kernel source + 
the ~100 generic (=common to all platforms) local patches + the 10-50 
platform-specific patches for each of the ~50 supported platforms (ar71xx, 
mvebu, ...). So a lot of local patches in several separate quilt chains.


When doing a kernel version bump, you need to adjust the generic & platform 
patches for the upstream changes in the upstream kernel. Some features may 
also have been accepted/changed upstream in the main kernel, so the 
Openwrt/LEDE patch needs to be removed/changed etc.


It is also possible that some local features have been added in a not-perfect 
way since the last kernel bump, so that all local patches have not been 
adjusted correctly.


The patches in the quilt chain can be left unrefreshed for some time, and 
patches still apply with fuzz. But it is good practice to refresh them every 
now and then. That should be done latest at the next kernel version bump, 
like here.


Looks like this time 
https://git.lede-project.org/?p=source.git;a=commitdiff;h=3764caa93478e3472df3128b79b6d0f6b0fb999c
changed target/linux/mvebu/patches-4.4/010-build_new_dtbs.patch (by adding 
the rango device) but did not adjust the later 
053-ARM-dts-Add-SolidRun-Armada-388-Clearfog-A1-DT-file.patch accordingly (to 
take the added one new line into account). So, that patch 053- got refreshed 
now to match the new reality (of the added rango line by the current 010- ).


Yeah, there could be a separate "refresh patches for earlier changes" patch 
before the kernel bump, but that would just be additional work as the patches 
should be refreshed in any case at the kernel bump.



___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] kernel: update kernel 4.4 to version 4.4.30

[p . wassi]

@Stijn, @Hannu:
Thank you for your explanation, I got it by now and I'm totally wrong
in interpreting the mvebu-patch. Sorry for causing this flurry.

If we stick to the mvebu-patch, what I still do not understand, is why
this patch refreshing is needed here.
According to
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/diff/?id=v4.4.30=v4.4=2
the file arch/arm/boot/dts/Makefile has never been changed by the kernel.
So there's a local patch which makes changes to this Makefile?
What may be my problem here is, that I'm totally stuck to the kernel changelog,
which leads to my question: is it the case, that the patches getting refreshed 
here
are not directly related to the upstream kernel changes.
If so, wouldn't it be clearer (for people like me :) ) if there were two
seperate patches (i.e. one for kernel update+refreshes itself and one for the 
internal
refreshes (or refreshes that have been missed in previous updates) )?

Best regards,
P. Wassi

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] kernel: update kernel 4.4 to version 4.4.30

[Stijn Segers]

On 2016-11-02 03:17, Outback Dingo wrote:
[...]



I find it quite odd that it doesnt apply cleanly to my LEDE tree at git 
rev


commit 411babb28a3091f693832fb30d475aa1e99c6d11
which is a merge of the latest ipfilters changes



That's weird... Can't check now, at work, will check this evening.

Stijn

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] kernel: update kernel 4.4 to version 4.4.30

[Stijn Tintel]

On 02-11-16 10:45, p.wa...@gmx.at wrote:
>> I find it quite odd that it doesnt apply cleanly to my LEDE tree at git rev
> I've just gone throgh the changes, and there is definitely more than just
> 'refreshing' the line numbers/offsets. This is seen at [1]. Have a special 
> look
> at [2] at the bottom of this mail, the line containing the caiman target is
> completely removed! This is not patch refreshing!
>
> Looking through the upstream changes 4.4.29->4.4.30 and the list of local
> LEDE/OpenWrt patches, the only thing required for a bump to 4.4.30 is
> the change in kernel-version.mk
>
> Best regards,
> P. Wassi
>
> [1]
> Add a space in an empty line:
This is likely due to git whitespace fixing. If you have this in your
.gitconfig:

[core]
whitespace = trailing-space
[apply]
whitespace = fix


If you create a patch with diff or quilt, the first character of each
line is either +, - or a space. So an empty line in the original file,
will be in the diff as an empty line, but starting with a single space.
This is completely normal. But when you have enabled whitespace fixing
in git for trailing-space, git apply (and git am) will strip that
whitespace. If you refresh patches with make ... refresh, quilt will add
that space again.

>> diff --git 
>> a/target/linux/generic/patches-4.4/051-0002-ovl-override-creds-with-the-ones-from-the-superblock.patch
>>  
>> b/target/linux/generic/patches-4.4/051-0002-ovl-override-creds-with-the-ones-from-the-superblock.patch
>> index f985ff3..eed7bb2 100644
>> --- 
>> a/target/linux/generic/patches-4.4/051-0002-ovl-override-creds-with-the-ones-from-the-superblock.patch
>> +++ 
>> b/target/linux/generic/patches-4.4/051-0002-ovl-override-creds-with-the-ones-from-the-superblock.patch
>> @@ -105,7 +105,7 @@ Signed-off-by: Miklos Szeredi 
>>  -out_free_link:
>>  if (link)
>>  free_page((unsigned long) link);
>> -
>> + 
>>  --- a/fs/overlayfs/dir.c
>>  +++ b/fs/overlayfs/dir.c
>>  @@ -408,28 +408,13 @@ static int ovl_create_or_link(struct den
> Remove the file timestamp:
This is due to the --no-timestamps option given to quilt, in
include/quilt.mk:
QUILT_DIFF_OPTS="-p" $(QUILT_CMD) refresh -p ab --no-index --no-timestamps;
What happened here is that the patch was originally added with
timestamps, and quilt simply removes them during make ... refresh.

>> diff --git 
>> a/target/linux/generic/patches-4.4/477-mtd-add-spi-nor-add-mx25u3235f.patch 
>> b/target/linux/generic/patches-4.4/477-mtd-add-spi-nor-add-mx25u3235f.patch
>> index 45533e1..eb99b28 100644
>> --- 
>> a/target/linux/generic/patches-4.4/477-mtd-add-spi-nor-add-mx25u3235f.patch
>> +++ 
>> b/target/linux/generic/patches-4.4/477-mtd-add-spi-nor-add-mx25u3235f.patch
>> @@ -1,5 +1,5 @@
>>  a/drivers/mtd/spi-nor/spi-nor.c 2016-10-09 00:34:19.206155838 +0200
>> -+++ b/drivers/mtd/spi-nor/spi-nor.c 2016-10-09 00:37:11.048495602 +0200
>> +--- a/drivers/mtd/spi-nor/spi-nor.c
>>  b/drivers/mtd/spi-nor/spi-nor.c
>>  @@ -721,6 +721,7 @@ static const struct flash_info spi_nor_i
>>  { "mx25l3205d",  INFO(0xc22016, 0, 64 * 1024,  64, SECT_4K) },
>>  { "mx25l3255e",  INFO(0xc29e16, 0, 64 * 1024,  64, SECT_4K) },
> Remove an empty line:
Similar to [1], git apply will strip lines at the end of a file if they
solely consist of whitespaces, when whitespace fixing is enabled. Or it
could be quilt, when the user has strip-trailing-whitespace enabled in
.quiltrc.
>> diff --git a/target/linux/lantiq/patches-4.4/0153-lantiq-VPE-softdog.patch 
>> b/target/linux/lantiq/patches-4.4/0153-lantiq-VPE-softdog.patch
>> index 2f5572a..eb76a24 100644
>> --- a/target/linux/lantiq/patches-4.4/0153-lantiq-VPE-softdog.patch
>> +++ b/target/linux/lantiq/patches-4.4/0153-lantiq-VPE-softdog.patch
>> @@ -157,7 +157,6 @@
>>  +MODULE_AUTHOR("LXDB");
>>  +MODULE_DESCRIPTION("Software Watchdog For VPE1");
>>  +MODULE_LICENSE("GPL");
>> -
>>  --- a/arch/mips/lantiq/Makefile
>>  +++ b/arch/mips/lantiq/Makefile
>>  @@ -6,6 +6,8 @@
> [2]
You are misinterpreting the change below. Apply the patch, and check
target/linux/mvebu/patches-4.4/053-ARM-dts-Add-SolidRun-Armada-388-Clearfog-A1-DT-file.patch
afterwards. You will notice that armada-385-linksys-caiman.dtb wasn't
removed. You are looking at a diff of a diff, and this can be confusing.
It's simply the offset that changes by 1 line.
>> diff --git 
>> a/target/linux/mvebu/patches-4.4/053-ARM-dts-Add-SolidRun-Armada-388-Clearfog-A1-DT-file.patch
>>  
>> b/target/linux/mvebu/patches-4.4/053-ARM-dts-Add-SolidRun-Armada-388-Clearfog-A1-DT-file.patch
>> index abf2a63..b25d710 100644
>> --- 
>> a/target/linux/mvebu/patches-4.4/053-ARM-dts-Add-SolidRun-Armada-388-Clearfog-A1-DT-file.patch
>> +++ 
>> b/target/linux/mvebu/patches-4.4/053-ARM-dts-Add-SolidRun-Armada-388-Clearfog-A1-DT-file.patch
>> @@ -24,9 +24,9 @@ Signed-off-by: Gregory CLEMENT > free-electrons.com>
>>  
>>  --- a/arch/arm/boot/dts/Makefile
>>  +++ b/arch/arm/boot/dts/Makefile
>> -@@ -749,6 +749,7 @@ 

Re: [LEDE-DEV] [PATCH] kernel: update kernel 4.4 to version 4.4.30

[p . wassi]

> I would also concur with this course, as I have done just that
> successfully. and have it now running on 4.4.30 :)

That's also what I did here.
Compile/run tested on kirkwood, brcm47xx, ar71xx

> Id be incline to ask for a resubmission, as this patch appears the be
> overkill and not appropriate

I think the change in
target/linux/mvebu/patches-4.4/053-ARM-dts-Add-SolidRun-Armada-388-Clearfog-A1-DT-file.patch
is to be discussed seperately (and probably not needed or 'harmful' (?) at 
all), so
this patch+refreshing for 4.4.30 shouldn't be applied to the tree as it is.

Best regards,
P. Wassi

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] kernel: update kernel 4.4 to version 4.4.30

[Outback Dingo]

On Wed, Nov 2, 2016 at 4:45 PM,   wrote:
>> I find it quite odd that it doesnt apply cleanly to my LEDE tree at git rev
>
> I've just gone throgh the changes, and there is definitely more than just
> 'refreshing' the line numbers/offsets. This is seen at [1]. Have a special 
> look
> at [2] at the bottom of this mail, the line containing the caiman target is
> completely removed! This is not patch refreshing!
>
> Looking through the upstream changes 4.4.29->4.4.30 and the list of local
> LEDE/OpenWrt patches, the only thing required for a bump to 4.4.30 is
> the change in kernel-version.mk

I would also concur with this course, as I have done just that
successfully. and have it now running on 4.4.30 :)
Id be incline to ask for a resubmission, as this patch appears the be
overkill and not appropriate


>
> Best regards,
> P. Wassi
>
> [1]
> Add a space in an empty line:
>> diff --git 
>> a/target/linux/generic/patches-4.4/051-0002-ovl-override-creds-with-the-ones-from-the-superblock.patch
>>  
>> b/target/linux/generic/patches-4.4/051-0002-ovl-override-creds-with-the-ones-from-the-superblock.patch
>> index f985ff3..eed7bb2 100644
>> --- 
>> a/target/linux/generic/patches-4.4/051-0002-ovl-override-creds-with-the-ones-from-the-superblock.patch
>> +++ 
>> b/target/linux/generic/patches-4.4/051-0002-ovl-override-creds-with-the-ones-from-the-superblock.patch
>> @@ -105,7 +105,7 @@ Signed-off-by: Miklos Szeredi 
>>  -out_free_link:
>>   if (link)
>>   free_page((unsigned long) link);
>> -
>> +
>>  --- a/fs/overlayfs/dir.c
>>  +++ b/fs/overlayfs/dir.c
>>  @@ -408,28 +408,13 @@ static int ovl_create_or_link(struct den
> Remove the file timestamp:
>> diff --git 
>> a/target/linux/generic/patches-4.4/477-mtd-add-spi-nor-add-mx25u3235f.patch 
>> b/target/linux/generic/patches-4.4/477-mtd-add-spi-nor-add-mx25u3235f.patch
>> index 45533e1..eb99b28 100644
>> --- 
>> a/target/linux/generic/patches-4.4/477-mtd-add-spi-nor-add-mx25u3235f.patch
>> +++ 
>> b/target/linux/generic/patches-4.4/477-mtd-add-spi-nor-add-mx25u3235f.patch
>> @@ -1,5 +1,5 @@
>>  a/drivers/mtd/spi-nor/spi-nor.c  2016-10-09 00:34:19.206155838 +0200
>> -+++ b/drivers/mtd/spi-nor/spi-nor.c  2016-10-09 00:37:11.048495602 +0200
>> +--- a/drivers/mtd/spi-nor/spi-nor.c
>>  b/drivers/mtd/spi-nor/spi-nor.c
>>  @@ -721,6 +721,7 @@ static const struct flash_info spi_nor_i
>>   { "mx25l3205d",  INFO(0xc22016, 0, 64 * 1024,  64, SECT_4K) },
>>   { "mx25l3255e",  INFO(0xc29e16, 0, 64 * 1024,  64, SECT_4K) },
> Remove an empty line:
>> diff --git a/target/linux/lantiq/patches-4.4/0153-lantiq-VPE-softdog.patch 
>> b/target/linux/lantiq/patches-4.4/0153-lantiq-VPE-softdog.patch
>> index 2f5572a..eb76a24 100644
>> --- a/target/linux/lantiq/patches-4.4/0153-lantiq-VPE-softdog.patch
>> +++ b/target/linux/lantiq/patches-4.4/0153-lantiq-VPE-softdog.patch
>> @@ -157,7 +157,6 @@
>>  +MODULE_AUTHOR("LXDB");
>>  +MODULE_DESCRIPTION("Software Watchdog For VPE1");
>>  +MODULE_LICENSE("GPL");
>> -
>>  --- a/arch/mips/lantiq/Makefile
>>  +++ b/arch/mips/lantiq/Makefile
>>  @@ -6,6 +6,8 @@
>
> [2]
>> diff --git 
>> a/target/linux/mvebu/patches-4.4/053-ARM-dts-Add-SolidRun-Armada-388-Clearfog-A1-DT-file.patch
>>  
>> b/target/linux/mvebu/patches-4.4/053-ARM-dts-Add-SolidRun-Armada-388-Clearfog-A1-DT-file.patch
>> index abf2a63..b25d710 100644
>> --- 
>> a/target/linux/mvebu/patches-4.4/053-ARM-dts-Add-SolidRun-Armada-388-Clearfog-A1-DT-file.patch
>> +++ 
>> b/target/linux/mvebu/patches-4.4/053-ARM-dts-Add-SolidRun-Armada-388-Clearfog-A1-DT-file.patch
>> @@ -24,9 +24,9 @@ Signed-off-by: Gregory CLEMENT > free-electrons.com>
>>
>>  --- a/arch/arm/boot/dts/Makefile
>>  +++ b/arch/arm/boot/dts/Makefile
>> -@@ -749,6 +749,7 @@ dtb-$(CONFIG_MACH_ARMADA_38X) += \
>> - armada-385-linksys-caiman.dtb \
>> +@@ -750,6 +750,7 @@ dtb-$(CONFIG_MACH_ARMADA_38X) += \
>>   armada-385-linksys-cobra.dtb \
>> + armada-385-linksys-rango.dtb \
>>   armada-385-linksys-shelby.dtb \
>>  +armada-388-clearfog.dtb \
>>   armada-388-db.dtb \

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] kernel: update kernel 4.4 to version 4.4.30

[p . wassi]

> I find it quite odd that it doesnt apply cleanly to my LEDE tree at git rev

I've just gone throgh the changes, and there is definitely more than just
'refreshing' the line numbers/offsets. This is seen at [1]. Have a special look
at [2] at the bottom of this mail, the line containing the caiman target is
completely removed! This is not patch refreshing!

Looking through the upstream changes 4.4.29->4.4.30 and the list of local
LEDE/OpenWrt patches, the only thing required for a bump to 4.4.30 is
the change in kernel-version.mk

Best regards,
P. Wassi

[1]
Add a space in an empty line:
> diff --git 
> a/target/linux/generic/patches-4.4/051-0002-ovl-override-creds-with-the-ones-from-the-superblock.patch
>  
> b/target/linux/generic/patches-4.4/051-0002-ovl-override-creds-with-the-ones-from-the-superblock.patch
> index f985ff3..eed7bb2 100644
> --- 
> a/target/linux/generic/patches-4.4/051-0002-ovl-override-creds-with-the-ones-from-the-superblock.patch
> +++ 
> b/target/linux/generic/patches-4.4/051-0002-ovl-override-creds-with-the-ones-from-the-superblock.patch
> @@ -105,7 +105,7 @@ Signed-off-by: Miklos Szeredi 
>  -out_free_link:
>   if (link)
>   free_page((unsigned long) link);
> -
> + 
>  --- a/fs/overlayfs/dir.c
>  +++ b/fs/overlayfs/dir.c
>  @@ -408,28 +408,13 @@ static int ovl_create_or_link(struct den
Remove the file timestamp:
> diff --git 
> a/target/linux/generic/patches-4.4/477-mtd-add-spi-nor-add-mx25u3235f.patch 
> b/target/linux/generic/patches-4.4/477-mtd-add-spi-nor-add-mx25u3235f.patch
> index 45533e1..eb99b28 100644
> --- 
> a/target/linux/generic/patches-4.4/477-mtd-add-spi-nor-add-mx25u3235f.patch
> +++ 
> b/target/linux/generic/patches-4.4/477-mtd-add-spi-nor-add-mx25u3235f.patch
> @@ -1,5 +1,5 @@
>  a/drivers/mtd/spi-nor/spi-nor.c  2016-10-09 00:34:19.206155838 +0200
> -+++ b/drivers/mtd/spi-nor/spi-nor.c  2016-10-09 00:37:11.048495602 +0200
> +--- a/drivers/mtd/spi-nor/spi-nor.c
>  b/drivers/mtd/spi-nor/spi-nor.c
>  @@ -721,6 +721,7 @@ static const struct flash_info spi_nor_i
>   { "mx25l3205d",  INFO(0xc22016, 0, 64 * 1024,  64, SECT_4K) },
>   { "mx25l3255e",  INFO(0xc29e16, 0, 64 * 1024,  64, SECT_4K) },
Remove an empty line:
> diff --git a/target/linux/lantiq/patches-4.4/0153-lantiq-VPE-softdog.patch 
> b/target/linux/lantiq/patches-4.4/0153-lantiq-VPE-softdog.patch
> index 2f5572a..eb76a24 100644
> --- a/target/linux/lantiq/patches-4.4/0153-lantiq-VPE-softdog.patch
> +++ b/target/linux/lantiq/patches-4.4/0153-lantiq-VPE-softdog.patch
> @@ -157,7 +157,6 @@
>  +MODULE_AUTHOR("LXDB");
>  +MODULE_DESCRIPTION("Software Watchdog For VPE1");
>  +MODULE_LICENSE("GPL");
> -
>  --- a/arch/mips/lantiq/Makefile
>  +++ b/arch/mips/lantiq/Makefile
>  @@ -6,6 +6,8 @@

[2]
> diff --git 
> a/target/linux/mvebu/patches-4.4/053-ARM-dts-Add-SolidRun-Armada-388-Clearfog-A1-DT-file.patch
>  
> b/target/linux/mvebu/patches-4.4/053-ARM-dts-Add-SolidRun-Armada-388-Clearfog-A1-DT-file.patch
> index abf2a63..b25d710 100644
> --- 
> a/target/linux/mvebu/patches-4.4/053-ARM-dts-Add-SolidRun-Armada-388-Clearfog-A1-DT-file.patch
> +++ 
> b/target/linux/mvebu/patches-4.4/053-ARM-dts-Add-SolidRun-Armada-388-Clearfog-A1-DT-file.patch
> @@ -24,9 +24,9 @@ Signed-off-by: Gregory CLEMENT  free-electrons.com>
>  
>  --- a/arch/arm/boot/dts/Makefile
>  +++ b/arch/arm/boot/dts/Makefile
> -@@ -749,6 +749,7 @@ dtb-$(CONFIG_MACH_ARMADA_38X) += \
> - armada-385-linksys-caiman.dtb \
> +@@ -750,6 +750,7 @@ dtb-$(CONFIG_MACH_ARMADA_38X) += \
>   armada-385-linksys-cobra.dtb \
> + armada-385-linksys-rango.dtb \
>   armada-385-linksys-shelby.dtb \
>  +armada-388-clearfog.dtb \
>   armada-388-db.dtb \

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] [PATCH netifd] interface: Fix triggering of interface update event

[Hans Dedecker]

In case the keep flag is set in proto_shell_update_link no interface
update event is triggered when IPv4/6 addresses/routes/... are updated
as the proto_event callback is not called due to keep being set.

Unconditionally call the proto_event callback handler in proto_shell_update_link
but let the proto_event callback handler; in this case interface_proto_event_cb,
decide which actions need to be taken dependant on the interface state.

In case the interface is already in the up state trigger an update event
only if the interface updated flag actually indicates either an IP address/
route/data change; before interface update events were actually sent wihtout
any parameter change.

Signed-off-by: Hans Dedecker 
---
 interface.c   | 9 ++---
 interface.h   | 2 +-
 proto-shell.c | 7 +++
 3 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/interface.c b/interface.c
index 5870422..a014111 100644
--- a/interface.c
+++ b/interface.c
@@ -693,7 +693,8 @@ interface_proto_event_cb(struct interface_proto_state 
*state, enum interface_pro
switch (ev) {
case IFPEV_UP:
if (iface->state != IFS_SETUP) {
-   interface_event(iface, IFEV_UPDATE);
+   if (iface->state == IFS_UP && iface->updated)
+   interface_event(iface, IFEV_UPDATE);
return;
}
 
@@ -1091,10 +1092,12 @@ set_config_state(struct interface *iface, enum 
interface_config_state s)
 }
 
 void
-interface_update_start(struct interface *iface)
+interface_update_start(struct interface *iface, const bool keep_old)
 {
iface->updated = 0;
-   interface_ip_update_start(>proto_ip);
+
+   if (!keep_old)
+   interface_ip_update_start(>proto_ip);
 }
 
 void
diff --git a/interface.h b/interface.h
index aa2085d..7d5b309 100644
--- a/interface.h
+++ b/interface.h
@@ -199,7 +199,7 @@ void interface_add_error(struct interface *iface, const 
char *subsystem,
 int interface_add_data(struct interface *iface, const struct blob_attr *data);
 int interface_parse_data(struct interface *iface, const struct blob_attr 
*attr);
 
-void interface_update_start(struct interface *iface);
+void interface_update_start(struct interface *iface, const bool keep_old);
 void interface_update_complete(struct interface *iface);
 
 void interface_start_pending(void);
diff --git a/proto-shell.c b/proto-shell.c
index 998a44c..ef56aa8 100644
--- a/proto-shell.c
+++ b/proto-shell.c
@@ -538,10 +538,10 @@ proto_shell_update_link(struct proto_shell_state *state, 
struct blob_attr *data,
return UBUS_STATUS_UNKNOWN_ERROR;
 
device_set_present(dev, true);
-
-   interface_update_start(iface);
}
 
+   interface_update_start(iface, keep);
+
proto_apply_ip_settings(iface, data, addr_ext);
 
if ((cur = tb[NOTIFY_ROUTES]) != NULL)
@@ -562,8 +562,7 @@ proto_shell_update_link(struct proto_shell_state *state, 
struct blob_attr *data,
interface_update_complete(state->proto.iface);
 
if ((state->sm != S_SETUP_ABORT) && (state->sm != S_TEARDOWN)) {
-   if (!keep)
-   state->proto.proto_event(>proto, IFPEV_UP);
+   state->proto.proto_event(>proto, IFPEV_UP);
state->sm = S_IDLE;
}
 
-- 
1.9.1


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev