Hi
On 31/12/2015 01:10, Martin Blumenstingl wrote:
> +
> +#if LINUX_VERSION_CODE >= KERNEL_VERSION(4,2,0)
> +#include
> +#else
> #include
> +#endif
please just drop the old code. there is no need to be compatible to old
kernels.
John
___
ope
Hello,
I had a working build r42397 which was stable enough so I didn't touch it
until today.
I built openwrt trunk r48016 (last night) and everything built without any
issues.
I like to load thing the factory image but this time loading the factory
image resulted in no internet. Router came on,
Upstream linux 4.2 commit 84be456f883c4685680fba8e5154b5f72e92957e
"remove " moves scatterlist.h to linux/ instead of asm/.
Upstream linux 4.3 commit b0d955ba4688fcba8112884931aea1f1e6f50f03
"crypto: aead - Remove old AEAD interfaces" removed aead_request_set_assoc.
aead_request_set_ad should be u
gpio.h needs the linux/ prefix with linux 4.4.
---
package/kernel/lantiq/ltq-vmmc/patches/100-target.patch | 8
package/kernel/lantiq/ltq-vmmc/patches/400-falcon.patch | 2 +-
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/package/kernel/lantiq/ltq-vmmc/patches/100-target.
linux 4.4 (since commit 08b3c894e56580b8ed3e601212a25bda974c3cc2
"MIPS: lantiq: Disable xbar fpi burst mode") requires that the xbar is
defined in the .dts of vrx200 (VR9) SoCs.
---
I am not sure if the xbar size is really 0x1000 or if it's smaller/larger.
Unfortunately there doesn't seem to be pub
Add back a slightly modified version of the lowlevel settings which
where removed with r46920.
In compare to the old lowlevel settings, the B43c tone is added to
tone_adsl_b and tone_adsl_bv.
If an unsupported tone value is used, the auto probing mode is used, in
compare to the fallback to tone_a
According to ITU-T G.997.1 Amendment 2 (04/2013) section 2.1, bit 3 of
XTSE octet 8 either allow or denies the initialization of G.993.5.
Even if the current redistributable xDSL firmware doesn't include
G.993.5 vectoring support, enable this bit by default to allow people to
get their G.993.5 lin
Changes in v2:
- dropped "ltq-vdsl-app: disable Annex I" patch, this one was wrong
Mathias Kresin (5):
ltq-vdsl-app: use the final xtse format
ltq-vdsl-app: add/enable missing G.993.2 XTSE bits
ltq-vdsl-app: let the driver/app probe the xtse on missing annex
ltq-vdsl-app: enable G.993.5
r47933 revealed that the driver/app in combination with the chosen
firmware does a good job in selecting a working xtse.
Use this probing mode if no annex is specified.
Signed-off-by: Mathias Kresin
---
Since a predefined annex isn't required, what about using 'auto' when
creating the initial
This way we can drop the call to sed.
Signed-off-by: Mathias Kresin
---
package/network/config/ltq-vdsl-app/files/dsl_control | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/package/network/config/ltq-vdsl-app/files/dsl_control
b/package/network/config/ltq-vdsl-ap
This patch adds the missing VDSL2 bits to the annex specific XTSE (like
it should be according to the comments above the XTSE bits).
Since r47933 it's mandatory to remove the annex option to switch to
VDSL2 (only) operation mode.
As shown by ticket #21436 and a few mails I received personally, ev
On 30/12/2015 17:37, Baptiste Clenet wrote:
> Hi,
>
> I'm using a custom board including a MT7688 chip, I made the image
> with the latest openwrt build (I've just downloaded it), I got an
> image of 2,9Mo.
>
> I flashed it and here is the debug:
>
> ## Booting image at bc05 ...
>Image
On 30/12/2015 15:04, Baptiste Clenet wrote:
> 2015-12-30 11:52 GMT+01:00 Baptiste Clenet :
>> Hi,
>>
>> I'm working on the MT7628 board and I try to register GPIO's irq. (I
>> haven't updated to kernel 4.3, I'm still on the previous version 3.18)
>> I've got two interrupts on GPIO 15 and GPIO 46.
Hi,
I'm using a custom board including a MT7688 chip, I made the image
with the latest openwrt build (I've just downloaded it), I got an
image of 2,9Mo.
I flashed it and here is the debug:
## Booting image at bc05 ...
Image Name: MIPS OpenWrt Linux-4.3
Image Type: MIPS Linux Kernel
On Wednesday, 30 December 2015, Nathan Hintz wrote:
> Hi:
> On Dec 30, 2015 4:01 AM, Yousong Zhou > wrote:
> >
> > With the default /e/c/network present, board_detect won't create a new
> > config from board.json. Move this default configuration to
> > generate_static_network of config_generate
Hi:
On Dec 30, 2015 4:01 AM, Yousong Zhou wrote:
>
> With the default /e/c/network present, board_detect won't create a new
> config from board.json. Move this default configuration to
> generate_static_network of config_generate instead.
>
> This should fix the issue on malta target and should n
2015-12-30 11:52 GMT+01:00 Baptiste Clenet :
> Hi,
>
> I'm working on the MT7628 board and I try to register GPIO's irq. (I
> haven't updated to kernel 4.3, I'm still on the previous version 3.18)
> I've got two interrupts on GPIO 15 and GPIO 46. I see that to register
> the interrupts it uses the
Hi,
On 30 December 2015 at 20:12, Amine Aouled Hamed wrote:
>
> Hi,
> Can you elaborate more on why you prefer uci state? I am just starting with
> OpenWRT and the first thing I found was procd.
>
Most of it is really just personal preference. I prefer uci because
it can provide more structure
On 30 December 2015 at 20:12, Jo-Philipp Wich wrote:
> Hi Yousong.
>
> NAK - thats by design. If a network config is present then there is no
> point in regenerating it.
>
> I'd prefer if the Malta target would simply drop its default config and
> switch to board.d, this could be useful to e.g. dy
Fix broken Failsafe on MT7620 caused by the fact that the switch on
MT7620 has VLANs enabled by default and eth0 won't receive any packet.
This patch turns off VLAN support to get Failsafe working.
Fixes https://dev.openwrt.org/ticket/18768 and has been discussed and
tested there.
Signed-off-by:
Hi,
Can you elaborate more on why you prefer uci state? I am just starting with
OpenWRT and the first thing I found was procd.
Regards,
Amine.
On Thu, Dec 24, 2015 at 2:35 PM, Yousong Zhou wrote:
> Hi, amine
>
> On 23 December 2015 at 00:00, amine ahd wrote:
> > The current state of NTP is to
I was expecting the openvpn.init script to include something like:
service_triggers()
{
procd_add_reload_trigger "openvpn"
}
But it doesn't. This makes "/sbin/reload_config" ineffective for openvpn.
Is that intentional? If not intentional I can send a patch.
I already tested the patch and it
Hi Yousong.
NAK - thats by design. If a network config is present then there is no
point in regenerating it.
I'd prefer if the Malta target would simply drop its default config and
switch to board.d, this could be useful to e.g. dynamically handle
different amounts of eth* devices:
eth0 -> lan
The ticket has been created, but an error occurred while sending
notifications: [Errno 111] Connection refused
I also did not receive the confirmation mail with the token to activate
my trac account.
Nemesis
___
openwrt-devel mailing list
openwrt-devel@
With the default /e/c/network present, board_detect won't create a new
config from board.json. Move this default configuration to
generate_static_network of config_generate instead.
This should fix the issue on malta target and should not affect other
targets that provide its own default network
Supported syntax is inspired by ethtool. Example usage:
swconfig dev switch0 port 2 set link "duplex half speed 100 autoneg off"
Signed-off-by: Rafał Miłecki
---
package/network/config/swconfig/src/swlib.c | 51 +
1 file changed, 51 insertions(+)
diff --git a/package
Hi,
I'm working on the MT7628 board and I try to register GPIO's irq. (I
haven't updated to kernel 4.3, I'm still on the previous version 3.18)
I've got two interrupts on GPIO 15 and GPIO 46. I see that to register
the interrupts it uses the internal GPIO interrupts (number 6). The
fact is, it reg
27 matches
Mail list logo