Re: [LEDE-DEV] Lede-dev Digest, Vol 25, Issue 50

[cb]

Ich bin vom 7. bis 18. Mai im Urlaub und werde nur gelegentlich Zugang zu 
meinem Postfach haben. In dringenden Fällen wenden Sie sich bitte an 
i...@shoutrlabs.com.

I'm on vacation from 7 to 18 May and will only occasionally have access to my 
mailbox. In urgent cases, please contact i...@shoutrlabs.com.



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

Re: [LEDE-DEV] ar71xx: Non-Unique MAC addresses for GL-iNet GL-AR750

[Dongming Han]

Hi Sven,

We actually allocate two MAC per GL-AR750. In manufacturing procedure, every
scan of device label consumes two MAC in database.

Is there any pitfall not having unique MAC per interface on some use case?
Many thanks for your advice.

--
Best Regards,
Dongming Han

> I've just noticed that the mac addresses for this device aren't unique (on 
> the 
> device itself). Neither in the original firmware or in the OpenWrt/LEDE 
> support.
> 
> 2: eth0:  mtu 1500 qdisc noop state DOWN qlen 1000
> link/ether e4:95:6e:44:09:58 brd ff:ff:ff:ff:ff:ff
> 5: wlan1:  mtu 1500 qdisc noop state DOWN qlen 1000
> link/ether e4:95:6e:44:09:58 brd ff:ff:ff:ff:ff:ff
> 3: eth1:  mtu 1500 qdisc fq_codel state DOWN qlen 1000
> link/ether e4:95:6e:44:09:59 brd ff:ff:ff:ff:ff:ff
> 4: wlan0:  mtu 1500 qdisc noop state DOWN qlen 1000
> link/ether e4:95:6e:44:09:59 brd ff:ff:ff:ff:ff:ff
> 
> The address for eth0 is in the art partition (offset 0x0) and the rest are 
> calculated manually based on that. Now it would be interesting to know how 
> many addresses were actually allocated per device for the GL-AR750. The 
> devices which I've received seem to suggest that at max 4 mac addresses are 
> assigned per device (but maybe also only 2) and I can only hope that at least 
> two were allocated.
> 
> Kind regards,
>   Sven
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] kernel: bump to 4.9.99

[Michael Yartys via Lede-dev]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---


Tested-by: Michael Yartys  

Target: ipq806x (NETGEAR R7800)

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

[LEDE-DEV] [PATCH] kernel: bump to 4.9.99

[Kevin Darbyshire-Bryant via Lede-dev]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
Refresh patches.

Tested-on: ar71xx Archer C7 v2

Signed-off-by: Kevin Darbyshire-Bryant 
---
 include/kernel-version.mk  |  4 +--
 .../ar7/patches-4.9/300-add-ac49x-platform.patch   |  4 +--
 .../403-mtd_fix_cfi_cmdset_0002_status_check.patch | 14 +-
 .../411-mtd-cfi_cmdset_0002-force-word-write.patch |  6 ++---
 .../ar71xx/patches-4.9/500-MIPS-fw-myloader.patch  |  2 +-
 .../ar71xx/patches-4.9/604-MIPS-ath79-no-of.patch  |  2 +-
 ...4-ARM-at91-build-dtb-for-sama5d27-SOM1-Ek.patch | 31 ++
 ...105-ARM-at91-build-dtb-for-sama5d2-ptc-Ek.patch | 17 
 .../linux/ath25/patches-4.9/107-ar5312_gpio.patch  |  2 +-
 .../patches-4.9/950-0031-Add-dwc_otg-driver.patch  |  2 +-
 ...fill-user-BO-creation-requests-from-the-k.patch |  2 +-
 ...-OOPSes-from-trying-to-cache-a-partially-.patch |  2 +-
 ...01-MIPS-BCM63XX-add-clkdev-lookup-support.patch |  2 +-
 .../322-MIPS-BCM63XX-switch-to-IRQ_DOMAIN.patch|  2 +-
 .../linux/generic/hack-4.9/220-gc_sections.patch   |  2 +-
 .../hack-4.9/301-mips_image_cmdline_hack.patch |  2 +-
 ...net-usb-add-lte-modem-wistron-neweb-d18q1.patch |  2 +-
 ...t-qmi_wwan-add-BroadMobi-BM806U-2020-2033.patch |  2 +-
 .../pending-4.9/300-mips_expose_boot_raw.patch |  4 +--
 .../generic/pending-4.9/304-mips_disable_fpu.patch |  2 +-
 ...m-remove-no-op-dma_map_ops-where-possible.patch | 12 -
 ..._cmdset_0002-add-buffer-write-cmd-timeout.patch |  2 +-
 .../pending-4.9/630-packet_socket_type.patch   | 16 +--
 ...jecting-with-source-address-failed-policy.patch | 16 +--
 .../pending-4.9/890-uart_optional_sysrq.patch  |  2 +-
 .../patches-4.9/090-increase_entropy_pools.patch   |  2 +-
 .../linux/lantiq/patches-4.9/0152-lantiq-VPE.patch |  2 +-
 .../patches-4.9/817-usb-support-layerscape.patch   | 18 ++---
 .../102-powerpc-add-cmdline-override.patch |  2 +-
 29 files changed, 78 insertions(+), 100 deletions(-)

diff --git a/include/kernel-version.mk b/include/kernel-version.mk
index cf84e31f7b..e49b66dcf2 100644
--- a/include/kernel-version.mk
+++ b/include/kernel-version.mk
@@ -4,12 +4,12 @@ LINUX_RELEASE?=1
 
 LINUX_VERSION-3.18 = .71
 LINUX_VERSION-4.4 = .121
-LINUX_VERSION-4.9 = .96
+LINUX_VERSION-4.9 = .99
 LINUX_VERSION-4.14 = .37
 
 LINUX_KERNEL_HASH-3.18.71 = 
5abc9778ad44ce02ed6c8ab52ece8a21c6d20d21f6ed8a19287b4a38a50c1240
 LINUX_KERNEL_HASH-4.4.121 = 
44a88268b5088dc326b30c9b9133ac35a9a200b636b7268d08f32abeae6ca729
-LINUX_KERNEL_HASH-4.9.96 = 
826f596eb5197f8b17304649c2990dd7b766f5c79076cae79f4261c40cea877f
+LINUX_KERNEL_HASH-4.9.99 = 
3dc3eb8c918bca444c8e6c061d534b1a8a5ac60a5b5d7065141f7b8e204213df
 LINUX_KERNEL_HASH-4.14.37 = 
8197e7ed3620713e412905430a7bf93e2048384042ffba189a66f0eeb6908e92
 
 remove_uri_prefix=$(subst git://,,$(subst http://,,$(subst https://,,$(1
diff --git a/target/linux/ar7/patches-4.9/300-add-ac49x-platform.patch 
b/target/linux/ar7/patches-4.9/300-add-ac49x-platform.patch
index 67ed3e494a..639f09709b 100644
--- a/target/linux/ar7/patches-4.9/300-add-ac49x-platform.patch
+++ b/target/linux/ar7/patches-4.9/300-add-ac49x-platform.patch
@@ -37,7 +37,7 @@
  #define AR7_IRQ_UART0 15
 --- a/arch/mips/Kconfig
 +++ b/arch/mips/Kconfig
-@@ -160,7 +160,7 @@ config AR7
+@@ -161,7 +161,7 @@ config AR7
select HAVE_CLK
help
  Support for the Texas Instruments AR7 System-on-a-Chip
@@ -46,7 +46,7 @@
  
  config ATH25
bool "Atheros AR231x/AR531x SoC support"
-@@ -1004,6 +1004,7 @@ config MIPS_PARAVIRT
+@@ -1005,6 +1005,7 @@ config MIPS_PARAVIRT
  endchoice
  
  source "arch/mips/alchemy/Kconfig"
diff --git 
a/target/linux/ar71xx/patches-4.9/403-mtd_fix_cfi_cmdset_0002_status_check.patch
 
b/target/linux/ar71xx/patches-4.9/403-mtd_fix_cfi_cmdset_0002_status_check.patch
index 415d835ee3..3a7fe99e65 100644
--- 
a/target/linux/ar71xx/patches-4.9/403-mtd_fix_cfi_cmdset_0002_status_check.patch
+++ 
b/target/linux/ar71xx/patches-4.9/403-mtd_fix_cfi_cmdset_0002_status_check.patch
@@ -1,6 +1,6 @@
 --- a/drivers/mtd/chips/cfi_cmdset_0002.c
 +++ b/drivers/mtd/chips/cfi_cmdset_0002.c
-@@ -1630,8 +1630,8 @@ static int __xipram do_write_oneword(str
+@@ -1631,8 +1631,8 @@ static int __xipram do_write_oneword(str
break;
}
  
@@ -11,7 +11,7 @@
  
/* Latency issues. Drop the lock, wait a while and retry */
UDELAY(map, chip, adr, 1);
-@@ -1647,6 +1647,8 @@ static int __xipram do_write_oneword(str
+@@ -1648,6 +1648,8 @@ static int __xipram do_write_oneword(str
  
ret = -EIO;
}
@@ -20,7 +20,7 @@
xip_enable(map, chip, adr);
   op_done:
if (mode == 

[LEDE-DEV] ar71xx: Non-Unique MAC addresses for GL-iNet GL-AR750

[Sven Eckelmann]

Hi,

I've just noticed that the mac addresses for this device aren't unique (on the 
device itself). Neither in the original firmware or in the OpenWrt/LEDE 
support.

2: eth0:  mtu 1500 qdisc noop state DOWN qlen 1000
link/ether e4:95:6e:44:09:58 brd ff:ff:ff:ff:ff:ff
5: wlan1:  mtu 1500 qdisc noop state DOWN qlen 1000
link/ether e4:95:6e:44:09:58 brd ff:ff:ff:ff:ff:ff
3: eth1:  mtu 1500 qdisc fq_codel state DOWN qlen 1000
link/ether e4:95:6e:44:09:59 brd ff:ff:ff:ff:ff:ff
4: wlan0:  mtu 1500 qdisc noop state DOWN qlen 1000
link/ether e4:95:6e:44:09:59 brd ff:ff:ff:ff:ff:ff

The address for eth0 is in the art partition (offset 0x0) and the rest are 
calculated manually based on that. Now it would be interesting to know how 
many addresses were actually allocated per device for the GL-AR750. The 
devices which I've received seem to suggest that at max 4 mac addresses are 
assigned per device (but maybe also only 2) and I can only hope that at least 
two were allocated.

Kind regards,
Sven

signature.asc
Description: This is a digitally signed message part.
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH v2] kernel: bump 4.14 to 4.14.39

[Syrone Wong]

4.14.40 released.


Best Regards,
Syrone Wong


On Wed, May 9, 2018 at 6:04 PM, Stijn Segers  wrote:
> Op di, 8 mei 2018 om 6:42 , schreef Koen Vandeputte
> :
>>
>> Refreshed all patches
>>
>> Dropped upstreamed patches:
>> 522-PCI-aardvark-fix-logic-in-PCI-configuration-read-write-functions.patch
>> 523-PCI-aardvark-set-PIO_ADDR_LS-correctly-in-advk_pcie_rd_conf.patch
>>
>> 525-PCI-aardvark-use-isr1-instead-of-isr0-interrupt-in-legacy-irq-mode.patch
>> 527-PCI-aardvark-fix-PCIe-max-read-request-size-setting.patch
>>
>> updated patches:
>> 524-PCI-aardvark-set-host-and-device-to-the-same-MAX-payload-size.patch
>>
>> Compile-tested on: cns3xxx, imx6, mvebu, x86_64
>> Runtime-tested on: cns3xxx, imx6,
>
>
> Compile-tested: x86/64, ramips/mt7621
> Run-tested: ramips/mt7621
>
>>
>> Signed-off-by: Koen Vandeputte 
>
>
> Tested-by: Stijn Segers 
>
>>
>> ---
>>
>> note:
>> Please apply following patch first:  be374d13fef3 "kernel: bump to 4.9.98"
>>
>> V2:
>> - Rebased using the 4.9.98 bump patch from Kevin DB
>> - Fully refreshed including patch changes from commit f9dcdc7fefca
>> ("kernel: mark source kernel for netfilter backports")
>> - Removed bump script from patch ..
>> - Recompiled and retested mentioned targets
>>
>>
>>
>>  include/kernel-version.mk  |   4 +-
>>  ...d-firmware-loader-for-uPD720201-and-uPD72.patch |   6 +-
>>  .../802-usb-xhci-force-msi-renesas-xhci.patch  |   2 +-
>>  ...1-tty-serial-drop-QCA-pecific-SoC-symbols.patch |   7 +-
>>  .../0002-watchdog-ath79-fix-maximum-timeout.patch  |   7 +-
>>  ...03-leds-add-reset-controller-based-driver.patch |  16 +-
>>  .../patches-4.14/0004-phy-add-ath79-usb-phys.patch |  20 +-
>>  .../0005-usb-add-more-OF-quirk-properties.patch|   7 +-
>>  .../0006-usb-drop-deprecated-symbols.patch |   9 +-
>>  ...-ath79-intc-add-irq-cascade-driver-for-QC.patch |   8 -
>>  ...irqchip-irq-ath79-cpu-drop-OF-init-helper.patch |   5 -
>>  ...-MIPS-ath79-add-lots-of-missing-registers.patch |   8 +-
>>  ...0-MIPS-ath79-select-the-PINCTRL-subsystem.patch |   7 +-
>>  ...fix-register-address-in-ath79_ddr_wb_flus.patch |   5 -
>>  ...th79-Avoid-using-unitialized-reg-variable.patch |   5 -
>>  .../0013-MIPS-ath79-fix-system-restart.patch   |  11 +-
>>  .../0014-MIPS-ath79-finetune-cpu-overrides.patch   |   5 -
>>  ...MIPS-ath79-enable-uart-during-early_prink.patch |   7 +-
>>  ...16-MIPS-ath79-add-support-for-QCA953x-SoC.patch |  27 +--
>>  ...17-MIPS-ath79-add-support-for-qca956x-soc.patch |  29 +--
>>  ...PS-ath79-get-PCIe-controller-out-of-reset.patch |   9 +-
>>  ...turn-pci-ar71xx-driver-into-a-pure-OF-dri.patch |  17 +-
>>  ...turn-pci-ar724x-driver-into-a-pure-OF-dri.patch |  13 +-
>>  .../patches-4.14/0022-MIPS-ath79-drop-pci.c.patch  |  20 +-
>>  .../0023-MIPS-ath79-drop-mach-files.patch  |  32 +--
>>  .../0024-MIPS-ath79-drop-pdata-helpers.patch   |  41 
>>  .../patches-4.14/0025-MIPS-ath79-drop-irq.c.patch  |  10 -
>>  .../0026-MIPS-ath79-sanitize-Kconfig-symbols.patch |  24 +-
>>  ...0027-MIPS-ath79-drop-mips_machine-support.patch |  22 +-
>>  ...add-helpers-for-setting-clocks-and-expose.patch |   4 +-
>>  .../004-register_gpio_driver_earlier.patch |   6 +-
>>  .../405-mtd-tp-link-partition-parser.patch |  12 +-
>>  .../patches-4.14/420-net-ar71xx_mac_driver.patch   |   2 +-
>>  .../430-drivers-link-spi-before-mtd.patch  |   2 +-
>>  .../461-spi-ath79-add-fast-flash-read.patch|   6 +-
>>  ...MIPS-ath79-swizzle-pci-address-for-ar71xx.patch |  10 +-
>>  .../490-usb-ehci-add-quirks-for-qca-socs.patch |   6 +-
>>  ...tbang-prevent-rescheduling-during-command.patch |   6 +-
>>  .../902-at803x-add-reset-gpio-pdata.patch  |   6 +-
>>  .../patches-4.14/910-unaligned_access_hacks.patch  | 258
>> +++--
>>  ...ycon-initialise-baud-field-of-earlycon-de.patch |   2 +-
>>  .../brcm47xx/patches-4.14/159-cpu_fixes.patch  |   8 +-
>>  ...b-host-fotg2-restart-hcd-after-port-reset.patch |   7 +-
>>  ...ts-Fix-bootargs-for-Gemini-D-Link-devices.patch |   7 -
>>  ...-dts-Add-ethernet-to-a-bunch-of-platforms.patch |   7 -
>>  ...rm-dts-gemini-dlink-dir-685-add-rtl8366rb.patch |   2 +-
>>  ...ata-corruption-related-to-cache-coherence.patch |   6 +-
>>  ..._cmdset_0002-add-buffer-write-cmd-timeout.patch |   2 +-
>>  .../pending-4.14/630-packet_socket_type.patch  |  16 +-
>>  ...pppoe-support-hardware-flow-table-offload.patch |   2 +-
>>  ...jecting-with-source-address-failed-policy.patch |  16 +-
>>  ...in-PCI-configuration-read-write-functions.patch |  66 --
>>  ...IO_ADDR_LS-correctly-in-advk_pcie_rd_conf.patch |  53 -
>>  ...t-and-device-to-the-same-MAX-payload-size.patch |  11 +-
>>  ...tead-of-isr0-interrupt-in-legacy-irq-mode.patch | 143 
>>  ...rk-fix-PCIe-max-read-request-size-setting.patch |  63 -
>>  

Re: [LEDE-DEV] Layerscape package depending on libxml2

[Michael Heimpold]

Hi,


the mentioned PR included a few new packages. I don't know the layerscape
platform, so I just want to understand it: these packages are all  
necessary to

boot a "reasonable"
system? And this is true for fmc, too?


[Y.b. Lu] fmc is an important userspace tool for layerscape which is  
frequently used and required by our key customers.


my point is more whether it is absolutely not possible to boot up
a layerscape system without these tools/packages?

Or to  bring a somewhat constructed use-case: PHP7 is frequently used
and required by most of my customers - however, this does not justify
to move PHP7 to core openwrt.

Don't get me wrong, I'm not a core developer and this are just
a few thoughts...

Michael


Fmc build and usage depends on several packages. They are tclap,  
fmlib, and eth-config which I added in the PR. Both fmlib and  
eth-config are only for layerscape.




Then one option would be to move libxml2 to "core openwrt".

If not, it would be an alternative approach to move the not really important
packages to packages feed, and add the fmc package in the packages feed as
well. This way, the dependency to libxml2 is solved automatically and the
"core openwrt" stays as small as reasonable.

Or should we avoid packages in the package feed which have a strong
platform dependency?


[Y.b. Lu] Thanks a lot for your good suggestion. Actually I tend to  
move libxml2 to core openwrt.






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

Re: [LEDE-DEV] MMAP memory out of sync on AR71xx Rambutan (8devices) board.

[Daniel Danzberger]

On 05/08/2018 10:33 PM, Kevin Darbyshire-Bryant wrote:
> 
> 
>> On 8 May 2018, at 21:11, Rosen Penev  wrote:
>>
>>>
>>> So out of curiosity I built this for my Archer C7 v2 ar71xx device.  I also 
>>> modified the code to not give up on ‘OK’, so it always iterated 10 times.  
>>> I then ran this repeatedly using ‘watch’.  Observations:
>>>
>>> 1) Failure only occurred on 1st check, it never appeared/re-appeared on 
>>> subsequent passes.
>>> 2) Failure offsets are always at 32 byte intervals.  That corresponds 
>>> nicely with cache-line size.
>> Yeah the L1
>>>
>>> Grabbing at straws to some extent.
> 
> So I modified the user space code a little more, namely moving the usleep to 
> before the check (obviously still after the mmap) - I am yet to see an error.
> 
>  printf("mmap addr: %p\n", addr);
> data = addr;
> 
> for (i = 0; i < 10; i++) {
> usleep(50);
> check_data(data, page_size);
> }
> 
> So that smells more of a race condition between the writer filling with 0xFF 
> and the reader catching up.
The open() syscall does the memset(0xff) and blocks. This ensures the memory is
initialized before the open() returns. I don't think there is a race.
> 
> Again, assume that I am an idiot and am missing something fundamental.
> 
> 
> 

-- 
Regards

Daniel Danzberger
embeDD GmbH, Alter Postplatz 2, CH-6370 Stans

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

[LEDE-DEV] buildbot failure to compile because it lacks gtime host tool

[Alberto Bursi]

It seems that after the commit that added gtime as host dependency the 
buildbot failed to compile this target 
https://downloads.openwrt.org/snapshots/faillogs/aarch64_cortex-a53/


and all logs state that it is missing "gtime". I suppose that this will 
block compilation of any other target, eventually.


Can someone please install that tool in the buildbot so it will compile 
again?


Or maybe make the gtime an optional thing, as it was mostly supposed to 
be used for statistics in the patch I've seen from the thread


[LEDE-DEV] [PATCH v2] build: log time taken by each packages/steps

-Alberto


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

[LEDE-DEV] [PATCH] helpers: fix the set_helper in the rule structure

[Pierre Lebleu]

The set_helper field has to be set by set_helper and not helper.

Signed-off-by: Pierre Lebleu 
---
 rules.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/rules.c b/rules.c
index ea66771..f6b6044 100644
--- a/rules.c
+++ b/rules.c
@@ -33,7 +33,7 @@ const struct fw3_option fw3_rule_opts[] = {
 
FW3_OPT("ipset",   setmatch,  rule, ipset),
FW3_OPT("helper",  cthelper,  rule, helper),
-   FW3_OPT("set_helper",  cthelper,  rule, helper),
+   FW3_OPT("set_helper",  cthelper,  rule, set_helper),
 
FW3_LIST("proto",  protocol,  rule, proto),
 
-- 
1.9.1


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

Re: [LEDE-DEV] Layerscape package depending on libxml2

[Y.b. Lu]

Hi Michael,

> -Original Message-
> From: Michael Heimpold [mailto:m...@heimpold.de]
> Sent: Wednesday, May 9, 2018 2:41 AM
> To: lede-dev@lists.infradead.org; Xiaobo Xie 
> Cc: Y.b. Lu ; openwrt-de...@lists.openwrt.org; Hauke
> Mehrtens ; John Crispin 
> Subject: Re: [LEDE-DEV] Layerscape package depending on libxml2
> 
> Hi,
> 
> the mentioned PR included a few new packages. I don't know the layerscape
> platform, so I just want to understand it: these packages are all necessary to
> boot a "reasonable"
> system? And this is true for fmc, too?

[Y.b. Lu] fmc is an important userspace tool for layerscape which is frequently 
used and required by our key customers.
Fmc build and usage depends on several packages. They are tclap, fmlib, and 
eth-config which I added in the PR. Both fmlib and eth-config are only for 
layerscape.

> 
> Then one option would be to move libxml2 to "core openwrt".
> 
> If not, it would be an alternative approach to move the not really important
> packages to packages feed, and add the fmc package in the packages feed as
> well. This way, the dependency to libxml2 is solved automatically and the
> "core openwrt" stays as small as reasonable.
> 
> Or should we avoid packages in the package feed which have a strong
> platform dependency?

[Y.b. Lu] Thanks a lot for your good suggestion. Actually I tend to move 
libxml2 to core openwrt.

> 
> Just a few thoughts of mine,
> Michael
> 
> Am Dienstag, 8. Mai 2018, 08:44:27 CEST schrieb Y.b. Lu:
> > Hi John and Hauke,
> >
> > May I have your suggestion about an old problem? The pull request was
> merged leaving out fmc package.
> > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit
> >
> hub.com%2Fopenwrt%2Fopenwrt%2Fpull%2F724=02%7C01%7Cyangbo
> .lu%40nx
> >
> p.com%7C5af09f423eb34c8479c508d5b5133b9d%7C686ea1d3bc2b4c6fa92c
> d99c5c3
> >
> 01635%7C0%7C1%7C636614016566713359=N2jlxMw2erh3uIjx1T%2F
> nWfvWZBe
> > Zjsz7ioGMDsbNP%2BE%3D=0
> >
> > I'd like to add this package fmc (frame manager configuration) for
> layerscape.
> > However it depends on libxml2 package which is not in the base feed. Must
> install feeds to enable and build it.
> > So I think I need some suggestion to find out a proper way to add this
> package.
> >
> > Thanks a lot.
> >
> > Best regards,
> > Yangbo Lu
> >
> > ___
> > Lede-dev mailing list
> > Lede-dev@lists.infradead.org
> > https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flist
> >
> s.infradead.org%2Fmailman%2Flistinfo%2Flede-dev=02%7C01%7Cyangb
> o.
> >
> lu%40nxp.com%7C5af09f423eb34c8479c508d5b5133b9d%7C686ea1d3bc2b
> 4c6fa92cd99c5c301635%7C0%7C1%7C636614016566713359=BDODn
> CrzqggSQgIx7%2B3y6zIFRb23T01nVATTSyKI3HU%3D=0
> >
> 


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

Re: [LEDE-DEV] Lede-dev Digest, Vol 25, Issue 46

[cb]

Ich bin vom 7. bis 18. Mai im Urlaub und werde nur gelegentlich Zugang zu 
meinem Postfach haben. In dringenden Fällen wenden Sie sich bitte an 
i...@shoutrlabs.com.

I'm on vacation from 7 to 18 May and will only occasionally have access to my 
mailbox. In urgent cases, please contact i...@shoutrlabs.com.



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

Re: [LEDE-DEV] new ath79 target

[Rafał Miłecki]

On 8 May 2018 at 14:53, Lucian Cristian  wrote:
> I added this PR https://github.com/openwrt/openwrt/pull/931
>
> the forum discussion is here
> https://forum.lede-project.org/t/is-anybody-working-on-linux-4-14-for-ar71xx-platform-porting-guide/13013/35
>
> maybe someone has a clue about it ?

I've a request. Please don't use ucidef_set_led_usbdev but put info
about USB ports & LEDs in DT instead. For a reference you may check:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=69d22c70ac9ad66be671ad2517ad5ee41058255f
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0b1f11002a70abf958aacbf4c18858443f504986

-- 
Rafał

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