Hello !
SB> the oldpackages feed is unsupported and will not be updated any more.
SB> If you want to submit packages or adopt packages from oldpackages which
SB> are not there yet please go to
SB> https://github.com/openwrt/packages and
SB> make a pull request there.
I wondering why drop so many
2014-07-14 21:05 GMT+04:00 Sergey Ryazanov :
> 2014-07-14 14:31 GMT+04:00 Karl Palsson :
>>
>> I've tried to test this on an ar2317, but the series isn't applying cleanly
>> to today's trunk.
>>
>> I got the first one to succeed, with some fuzz, the second applied cleanly,
>> but the third failed
Use AR2315_ prefix for macroses specific to AR2315/AR2316/AR2317 chips,
use AR5312_ prefix for macroses specific to AR5312/AR2312/AR2313 chips,
and use AR231X_ prefix for common macroses.
This patch should not cause any functional changes, only make clear
which macros is common and which macros is
Pass only physical address to 8250 serial port driver and set flag to
remap I/O memory inside the driver. Also fix AR5312 UART base address
definition, which seems specified already mapped.
Signed-off-by: Sergey Ryazanov
---
target/linux/atheros/patches-3.10/100-board.patch | 11 +--
1 f
Pass PHY I/O memory region via platform resources and remap them
unconditionally.
Signed-off-by: Sergey Ryazanov
---
target/linux/atheros/patches-3.10/100-board.patch | 57 ++
.../atheros/patches-3.10/110-ar2313_ethernet.patch | 48 +++---
.../patches-3.10/220-en
Use 32-bit aligned I/O and update base UART address (remove +3 offset).
Signed-off-by: Sergey Ryazanov
---
target/linux/atheros/patches-3.10/100-board.patch| 6 +++---
target/linux/atheros/patches-3.10/101-early-printk-support.patch | 4 ++--
2 files changed, 5 insertions(+), 5 d
Signed-off-by: Sergey Ryazanov
---
target/linux/atheros/patches-3.10/100-board.patch| 20 ++--
.../atheros/patches-3.10/110-ar2313_ethernet.patch | 19 ---
.../patches-3.10/220-enet_micrel_workaround.patch| 6 +++---
3 files changed, 21 insertions(+), 24
Each SoCs generation has own independent gpiolib realization, so we
have no reason to keep these realizations in semiuniversal form.
Following modifications are made:
* Remove valid_mask field
* Remove ar231x_gpio_chip structure
* Rename AR2315_GPIO_CR to AR2315_GPIO_DIR
* Fix count of AR5312 G
Currently AR5312 misc IRQ numbers are used for AR2315+ chips, what cause
us to use switch-case to map IRQ number to ISR bit. Introduce AR2315
specific misc IRQs set and simplify interrupt (un)mask operation.
Signed-off-by: Sergey Ryazanov
---
target/linux/atheros/patches-3.10/100-board.patch |
Signed-off-by: Sergey Ryazanov
---
target/linux/atheros/patches-3.10/100-board.patch | 34 +++---
.../atheros/patches-3.10/105-ar2315_pci.patch | 6 ++--
2 files changed, 14 insertions(+), 26 deletions(-)
diff --git a/target/linux/atheros/patches-3.10/100-board.patch
b/ta
Pass reset_set and reset_clear callback functions pointers via
platform_data instead of reset register address.
Signed-off-by: Sergey Ryazanov
---
target/linux/atheros/patches-3.10/100-board.patch | 49 ++
.../atheros/patches-3.10/110-ar2313_ethernet.patch | 24 ---
Move driver code to respective vendor subdirectory and fix config
symbol name.
Signed-off-by: Sergey Ryazanov
---
target/linux/atheros/config-3.10 | 2 +-
.../atheros/patches-3.10/110-ar2313_ethernet.patch | 59 +++---
.../patches-3.10/220-enet_micrel_workaroun
Align code with AR5312 realization.
Signed-off-by: Sergey Ryazanov
---
target/linux/atheros/patches-3.10/100-board.patch | 47 --
.../atheros/patches-3.10/105-ar2315_pci.patch | 15 +++
2 files changed, 34 insertions(+), 28 deletions(-)
diff --git a/target/linux/at
* Pass iomem and IRQ via platform device resources
* Remap iomem and use iowrite32 accessor function
Signed-off-by: Sergey Ryazanov
---
target/linux/atheros/patches-3.10/100-board.patch | 17 +++-
.../linux/atheros/patches-3.10/130-watchdog.patch | 45 --
2 files chan
Rename interrupt control handlers to be consistent with operation names
and add IRQ chips names.
Signed-off-by: Sergey Ryazanov
---
target/linux/atheros/patches-3.10/100-board.patch | 45 ---
1 file changed, 24 insertions(+), 21 deletions(-)
diff --git a/target/linux/atheros
Rename config symbol to AR2315_WDT to avoid confusion with other Atheros
SoCs.
Signed-off-by: Sergey Ryazanov
---
target/linux/atheros/config-3.10 | 2 +-
target/linux/atheros/patches-3.10/130-watchdog.patch | 11 ++-
2 files changed, 7 insertions(+), 6 deletions(-)
UART IRQ number could be different for different SoCs, so make them
configurable.
Signed-off-by: Sergey Ryazanov
---
target/linux/atheros/patches-3.10/100-board.patch | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/target/linux/atheros/patches-3.10/100-board.
* update driver id to be consistent with other ar231x drivers
* remove odd module_{init,exit}
* add module metadata (description, name, etc.)
Signed-off-by: Sergey Ryazanov
---
target/linux/atheros/patches-3.10/100-board.patch | 2 +-
.../linux/atheros/patches-3.10/130-watchdog.patch | 29
Make sparse happy :)
Signed-off-by: Sergey Ryazanov
---
target/linux/atheros/patches-3.10/100-board.patch | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/target/linux/atheros/patches-3.10/100-board.patch
b/target/linux/atheros/patches-3.10/100-board.patch
index 36ad7c8..
Acknowledge watchdog interrupt in arch irq dispatcher and remove odd
watchdog enable call from probe function.
Signed-off-by: Sergey Ryazanov
---
target/linux/atheros/patches-3.10/100-board.patch| 7 ---
target/linux/atheros/patches-3.10/130-watchdog.patch | 5 +
2 files changed, 5 i
Main goals of this series:
* Simplify interface between arch code and SoC drivers
* Simplify internal realization of arch code
* Make code consistent with mainstream kernel rules and practice
This series extensively tested with FON2202 (ar2315 based) and D-Link
DWL-2100AP (ar2313 based), but te
On Mon, Jul 14, 2014 at 11:35 PM, Rafał Miłecki wrote:
> On 14 July 2014 18:44, Jonas Gorski wrote:
>> On Mon, Jul 14, 2014 at 6:23 PM, Felix Fietkau wrote:
>>> It looks to me like the hardware is overwriting the skb shared info (at
>>> the end of the skb data buffer), possibly because the confi
On Mon, Jul 14, 2014 at 11:48 PM, Nikolai Zhubr wrote:
> 14.07.2014 20:44, Jonas Gorski:
> [...]
>
>>> If I were to speculate wildly, I would guess that B44_RXMAXLEN refers to
>>> the maximum frame length, not the maximum buffer length - and in the
>>> code, it's being fed with the maximum buffer
Hi everyone,
Le lundi 14 juillet 2014 à 22:17 +0900, Baptiste Jonglez a écrit :
> On Mon, Jul 14, 2014 at 02:38:16PM +0200, Steven Barth wrote:
> > Hi Baptiste,
> >
> > in general our current firewalling approach is to keep defaults for IPv4 and
> > IPv6 relatively close (not considering NAT here
On 14 July 2014 18:44, Jonas Gorski wrote:
> On Mon, Jul 14, 2014 at 6:23 PM, Felix Fietkau wrote:
>> It looks to me like the hardware is overwriting the skb shared info (at
>> the end of the skb data buffer), possibly because the configured maximum
>> frame length may be too big for the buffer.
Hello,
On Mon, 14 Jul 2014 22:16:03 +0200
Jo-Philipp Wich wrote:
> Hi.
>
> > Yes, I heard from other replies, that's good news, hope it will be
> > ready for prime time soon.
> >
> > Still, it would be nice to have good unbloated language for rapid
> > app development in constrained environmen
14.07.2014 20:44, Jonas Gorski:
[...]
If I were to speculate wildly, I would guess that B44_RXMAXLEN refers to
the maximum frame length, not the maximum buffer length - and in the
code, it's being fed with the maximum buffer length.
This would allow the hardware to receive slightly oversized fram
Move eeprom extraction from scripts to dts files.
Additionally there are few other changes like:
- whitespace fixes
- add partition labels where needed
- BR6524N board doesn't exist (lost in translation?)
- fix Edimax 3g-6200nl model
- add wmac eeprom to dts for Asus RT-N14U board
Compile tested a
Hi.
> Yes, I heard from other replies, that's good news, hope it will be
> ready for prime time soon.
>
> Still, it would be nice to have good unbloated language for rapid app
> development in constrained environments, like most routers on which
> OpenWRT runs. I made initial proof of concept web
Hi Sergey,
the oldpackages feed is unsupported and will not be updated any more.
If you want to submit packages or adopt packages from oldpackages which
are not there yet please go to https://github.com/openwrt/packages and
make a pull request there.
Cheers,
Steven
_
Hello,
On Mon, 14 Jul 2014 16:29:42 +0400
Nick Shvelidze wrote:
> Interesting, MicroPython is great. By the way, Luci2 doesn't use Lua
> at all.
Yes, I heard from other replies, that's good news, hope it will be
ready for prime time soon.
Still, it would be nice to have good unbloated language
On 14/07/2014 19:05, Sergey Ryazanov wrote:
> John, please, could you reject this series? I will send new one.
i just marked it as "Changes Requested"
John
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.o
ok, no idea why it is not in trunk but marked as accepted but i would
assume its my fault
thanks, merged in r41653
On 14/07/2014 18:55, Claudio Leite wrote:
> Hello,
>
> * Claudio Leite (lei...@staticky.com) wrote:
>> Use pr_debug rather than pr_info since it is only relevant for
>> debugging
2014-07-14 14:31 GMT+04:00 Karl Palsson :
>
> I've tried to test this on an ar2317, but the series isn't applying cleanly
> to today's trunk.
>
> I got the first one to succeed, with some fuzz, the second applied cleanly,
> but the third failed, and I stopped
> trying.
>
You right. I downloaded p
Hello,
* Claudio Leite (lei...@staticky.com) wrote:
> Use pr_debug rather than pr_info since it is only relevant
> for debugging.
>
> Signed-off-by: Claudio Leite
While we are talking about things for Barrier Breaker RC's, could this
patch be merged in? It was marked as accepted back in April,
On Mon, Jul 14, 2014 at 6:23 PM, Felix Fietkau wrote:
> On 2014-07-14 16:42, Rafał Miłecki wrote:
>> On 21 June 2014 18:36, Nikolai Zhubr wrote:
>>> [ 637.43] [ cut here ]
>>> [ 637.44] WARNING: at net/core/dev.c:2194
>>> skb_warn_bad_offload+0xc0/0xe8()
>>> [ 6
On 14/07/2014 15:56, Alive4Ever wrote:
> On Monday, July 14, 2014 12:00:01 PM
> openwrt-devel-requ...@lists.openwrt.org wrote:
>> The OpenWrt developers are proud to announce the first release
>> candidate of OpenWrt Barrier Breaker.
> Glad to know that Barrier Breaker will be ready to rock. Wou
On 2014-07-14 16:42, Rafał Miłecki wrote:
> On 21 June 2014 18:36, Nikolai Zhubr wrote:
>> [ 637.43] [ cut here ]
>> [ 637.44] WARNING: at net/core/dev.c:2194
>> skb_warn_bad_offload+0xc0/0xe8()
>> [ 637.45] b44: caps=(0x4000, 0x)
2014-07-14 14:31 GMT+04:00 Karl Palsson :
>
> I've tried to test this on an ar2317, but the series isn't applying cleanly
> to today's trunk.
>
> I got the first one to succeed, with some fuzz, the second applied cleanly,
> but the third failed, and I stopped
> trying.
>
Sounds strangely. I'll tr
14.07.2014 18:42, Rafał Miłecki:
[...]
[ 637.56] Call Trace:
[ 637.56] [<80010bb4>] show_stack+0x48/0x70
[ 637.57] [<80019bd4>] warn_slowpath_common+0x78/0xa8
[ 637.57] [<80019c30>] warn_slowpath_fmt+0x2c/0x38
[ 637.58] [<801b27dc>] skb_warn_bad_offload+0xc0/0xe8
[ 637.5
14.07.2014 18:34, Rafał Miłecki:
Please create a ticket with boot log, nvram show and your default
(broken) /etc/config/network.
Done,
https://dev.openwrt.org/ticket/17111
(Note: trac does not seem to know about rc1 yet, therefore I had to mark
it for trunk)
Thank you.
Nikolai
.
_
On 21 June 2014 18:36, Nikolai Zhubr wrote:
> [ 637.43] [ cut here ]
> [ 637.44] WARNING: at net/core/dev.c:2194
> skb_warn_bad_offload+0xc0/0xe8()
> [ 637.45] b44: caps=(0x4000, 0x) len=1500
> data_len=0 gso_size=53118 gso_type=59
On 14 July 2014 15:57, Nikolai Zhubr wrote:
> Additionally, there is now another (less important) problem. In 14.07
> ethernet ports of WL-500W get initially configured as if it was e.g.
> wl-500gp:
>
> - WAN is assigned to eth0.2 instead of eth1.
> - WAN6 is assigned to some "@wan".
> - LAN ports
On Monday, July 14, 2014 12:00:01 PM openwrt-devel-requ...@lists.openwrt.org
wrote:
> The OpenWrt developers are proud to announce the first release
> candidate of OpenWrt Barrier Breaker.
Glad to know that Barrier Breaker will be ready to rock.
Would it possible to include my ticket #17028 here? I
Hello all,
this is good news, however bad news is that brcm47xx (generic) target is
still seriously broken, at least on Asus WL-500W. The problem is
absolutely reproducible, and I reported it some time ago, but
unfortunately it attracted very little interest here for some reason.
Don't take m
Hi Steven,
On Mon, Jul 14, 2014 at 02:38:16PM +0200, Steven Barth wrote:
> Hi Baptiste,
>
> in general our current firewalling approach is to keep defaults for IPv4 and
> IPv6 relatively close (not considering NAT here of course).
Could you detail the reasoning behind this approach? "Don't conf
On Mon, 2014-07-14 at 15:17:13 +0400, Nick Shvelidze wrote:
> Good to see package feed on GitHub.
>
> Would be great if there was a full OpenWRT source mirror on GitHub,
> for some reason git.openwrt.org refuses connections on HTTPS, both
> from my home and work IPs.
>
Look at here :-) https://gi
Hi Baptiste,
in general our current firewalling approach is to keep defaults for IPv4
and IPv6 relatively close (not considering NAT here of course). Opening
up the IPv6 firewall by default would be unexpected and I don't really
like the approach for that matter and honestly I don't trust clie
Interesting, MicroPython is great. By the way, Luci2 doesn't use Lua at all.
On Mon, Jul 14, 2014 at 4:20 PM, Paul Sokolovsky wrote:
> Hello,
>
> I wondered if it makes sense to post about MicroPython, but recent post
> about Squirrel language prompted me to. So, there's a project to
> implemen
On Mon, Jul 14, 2014 at 11:12:01AM +0200, John Crispin wrote:
>
> The OpenWrt developers are proud to announce the first release
> candidate of OpenWrt Barrier Breaker.
Excellent news, thanks!
> * Native IPv6-support
> - RA & DHCPv6+PD client and server
> - Local prefix allocation &
Hello,
I wondered if it makes sense to post about MicroPython, but recent post
about Squirrel language prompted me to. So, there's a project to
implement, from scratch, very lean interpreter for Python3 scripting
language.
The project is well under way and currently implements good deal of
Python
On 14 July 2014 19:15, John Crispin wrote:
>
>
> On 14/07/2014 13:13, Yousong Zhou wrote:
>> On 14 July 2014 17:12, John Crispin wrote:
>>>
>>> The OpenWrt developers are proud to announce the first release
>>> candidate of OpenWrt Barrier Breaker. ___
>>> __ | |.-.-
Good to see package feed on GitHub.
Would be great if there was a full OpenWRT source mirror on GitHub, for
some reason git.openwrt.org refuses connections on HTTPS, both from my home
and work IPs.
On Mon, Jul 14, 2014 at 1:12 PM, John Crispin wrote:
>
> The OpenWrt developers are proud to ann
On 14/07/2014 13:13, Yousong Zhou wrote:
> On 14 July 2014 17:12, John Crispin wrote:
>>
>> The OpenWrt developers are proud to announce the first release
>> candidate of OpenWrt Barrier Breaker. ___
>> __ | |.-.-.-.| | | |..|
>> |_ | - || _ |
On 14 July 2014 17:12, John Crispin wrote:
>
> The OpenWrt developers are proud to announce the first release
> candidate of OpenWrt Barrier Breaker.
> ___ __
> | |.-.-.-.| | | |..| |_
> | - || _ | -__| || | | ||
On 14/07/2014 12:59, Xiongfei Guo wrote:
> Hi, john,
>
> How is the luci, which version the luci will be used. Teh devel? or
> luci will bump to 0.12?
>
> Xiongfei Guo Credo Semi.
>
> On 07/14/2014 05:12 PM, John Crispin wrote:
>> The OpenWrt developers are proud to announce the first release
Hi, john,
How is the luci, which version the luci will be used. Teh devel? or luci
will bump to 0.12?
Xiongfei Guo
Credo Semi.
On 07/14/2014 05:12 PM, John Crispin wrote:
The OpenWrt developers are proud to announce the first release
candidate of OpenWrt Barrier Breaker.
___
I've tried to test this on an ar2317, but the series isn't applying cleanly to
today's trunk.
I got the first one to succeed, with some fuzz, the second applied cleanly, but
the third failed, and I stopped
trying.
Cheers,
Karl P
2014-07-12 17:33 GMT+04:00 Sergey Ryazanov :
> Main goals of t
Hi all,
since i didn't hear anything about this in the last 6 weeks i like to
ask, if there are any problems/concerns to add this?
I would be more than happy to help :)
Thanks alot and have a nice week!
Ben
Am 02.06.2014 09:26, schrieb Ben:
Hi everybody,
to deploy minimal OpenWrt images on
The OpenWrt developers are proud to announce the first release
candidate of OpenWrt Barrier Breaker.
___ __
| |.-.-.-.| | | |..| |_
| - || _ | -__| || | | || _|| _|
|___|| __|_|__|__||||__|
60 matches
Mail list logo
