Re: [OpenWrt-Devel] [PATCH 1/2] wireguard.sh: Batch file writes

[Hartmut Knaack]

Rosen Penev schrieb am 01.01.2020 um 03:08:
> Speeds up config generation.
>
> Signed-off-by: Rosen Penev 
> ---
>  .../utils/wireguard-tools/files/wireguard.sh  | 32 ---
>  1 file changed, 14 insertions(+), 18 deletions(-)
>
> diff --git a/package/network/utils/wireguard-tools/files/wireguard.sh 
> b/package/network/utils/wireguard-tools/files/wireguard.sh
> index 4c811c6ba9..1e424e7959 100644
> --- a/package/network/utils/wireguard-tools/files/wireguard.sh
> +++ b/package/network/utils/wireguard-tools/files/wireguard.sh
> @@ -42,13 +42,12 @@ proto_wireguard_setup_peer() {
>   config_get endpoint_port "${peer_config}" "endpoint_port"
>   config_get persistent_keepalive "${peer_config}" "persistent_keepalive"
>
> - echo "[Peer]" >> "${wg_cfg}"
> - echo "PublicKey=${public_key}" >> "${wg_cfg}"
> - if [ "${preshared_key}" ]; then
> - echo "PresharedKey=${preshared_key}" >> "${wg_cfg}"
> - fi
> + {
> + echo "[Peer]"
> + echo "PublicKey=${public_key}"
> + [ "${preshared_key}" ] && echo "PresharedKey=${preshared_key}"
>   for allowed_ip in $allowed_ips; do
> - echo "AllowedIPs=${allowed_ip}" >> "${wg_cfg}"
> + echo "AllowedIPs=${allowed_ip}"
>   done
>   if [ "${endpoint_host}" ]; then
>   case "${endpoint_host}" in
> @@ -64,11 +63,10 @@ proto_wireguard_setup_peer() {
>   else
>   endpoint="${endpoint}:51820"
>   fi
> - echo "Endpoint=${endpoint}" >> "${wg_cfg}"
> - fi
> - if [ "${persistent_keepalive}" ]; then
> - echo "PersistentKeepalive=${persistent_keepalive}" >> 
> "${wg_cfg}"
> + echo "Endpoint=${endpoint}"
>   fi
> + [ "${persistent_keepalive}" ] && echo 
> "PersistentKeepalive=${persistent_keepalive}"
> + } >> "${wg_cfg}"
>

Hi,
I would prefer to have the above code block indented, as well.

>   if [ ${route_allowed_ips} -ne 0 ]; then
>   for allowed_ip in ${allowed_ips}; do
> @@ -119,14 +117,12 @@ proto_wireguard_setup() {
>
>   umask 077
>   mkdir -p "${wg_dir}"
> - echo "[Interface]" > "${wg_cfg}"
> - echo "PrivateKey=${private_key}" >> "${wg_cfg}"
> - if [ "${listen_port}" ]; then
> - echo "ListenPort=${listen_port}" >> "${wg_cfg}"
> - fi
> - if [ "${fwmark}" ]; then
> - echo "FwMark=${fwmark}" >> "${wg_cfg}"
> - fi
> + {
> + echo "[Interface]"
> + echo "PrivateKey=${private_key}"
> + [ "${listen_port}" ] && echo "ListenPort=${listen_port}"
> + [ "${fwmark}" ] && echo "FwMark=${fwmark}"
> + } > "${wg_cfg}"
>   config_foreach proto_wireguard_setup_peer "wireguard_${config}"
>
>   # apply configuration file
>


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCHv2 1/4] scripts/gen_image_generic.sh: Replace -o with ||

[Hartmut Knaack]

Rosen Penev schrieb am 30.12.2019 um 06:07:
> -o is not well defined.
>
> Found with shellcheck.
>
> Signed-off-by: Rosen Penev 
> ---
>  scripts/gen_image_generic.sh | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/scripts/gen_image_generic.sh b/scripts/gen_image_generic.sh
> index 2d2fb120ce..1e35b1b349 100755
> --- a/scripts/gen_image_generic.sh
> +++ b/scripts/gen_image_generic.sh
> @@ -1,10 +1,10 @@
>  #!/usr/bin/env bash
>  # Copyright (C) 2006-2012 OpenWrt.org
>  set -e -x
> -[ $# == 5 -o $# == 6 ] || {
> +if [ $# -ge 5 ] || [ $# -le 6 ]; then
>  echo "SYNTAX: $0 
>  []"
>  exit 1
> -}
> +fi
>
>  OUTPUT="$1"
>  KERNELSIZE="$2"
>
Hi,
this does not look right. You changed it from reporting a failure in case there
was any other amount of options than 5 or 6 given, to reporting a failure if at
least 5 or at most 6 options are provided (in other words: every amount).

Regards,

Hartmut


0x03684A18FAC89148.asc
Description: application/pgp-keys
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] OpenWrt 19.01 plans

[Hartmut Knaack]

Koen Vandeputte schrieb am 26.09.2018 um 09:38:
 
> These targets were also dropped in 18.06 branch.
> Maybe we should also consider dropping support for these targets in master?
> 
> 
> adm5120

I started working on this target last year, but had to focus on other
topics meanwhile. Still, I would not like to give up on this one.



0x03684A18FAC89148.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 2/2] kernel: add Si7020 relative humidity/temperature sensor driver

[Hartmut Knaack]

Add support for the Silicon Labs Si7020 family of relative humidity and
temperature sensors using the I2C bus.

Signed-off-by: Hartmut Knaack 
---
 package/kernel/linux/modules/iio.mk | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/package/kernel/linux/modules/iio.mk 
b/package/kernel/linux/modules/iio.mk
index d0c2c36..b7eb048 100644
--- a/package/kernel/linux/modules/iio.mk
+++ b/package/kernel/linux/modules/iio.mk
@@ -157,6 +157,24 @@ endef
 $(eval $(call KernelPackage,iio-htu21))
 
 
+define KernelPackage/iio-si7020
+  SUBMENU:=$(IIO_MENU)
+  DEPENDS:=+kmod-i2c-core +kmod-iio-core
+  TITLE:=Silicon Labs Si7020 sensor
+  KCONFIG:= CONFIG_SI7020
+  FILES:=$(LINUX_DIR)/drivers/iio/humidity/si7020.ko
+  AUTOLOAD:=$(call AutoLoad,56,si7020)
+endef
+
+define KernelPackage/iio-si7020/description
+ Support for Silicon Labs Si7020 family of relative humidity and
+ temperature sensors connected via I2C. Following models are usable:
+ Si7013, Si7020, Si7021, Hoperf TH06.
+endef
+
+$(eval $(call KernelPackage,iio-si7020))
+
+
 define KernelPackage/iio-tsl4531
   SUBMENU:=$(IIO_MENU)
   DEPENDS:=+kmod-i2c-core +kmod-iio-core
-- 
2.1.4


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 1/2] kernel: add TSL4531 ambient light sensor driver

[Hartmut Knaack]

Add support for the TAOS TSL4531x family of ambient light sensors using
the I2C bus.

Signed-off-by: Hartmut Knaack 
---
 package/kernel/linux/modules/iio.mk | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/package/kernel/linux/modules/iio.mk 
b/package/kernel/linux/modules/iio.mk
index a141017..d0c2c36 100644
--- a/package/kernel/linux/modules/iio.mk
+++ b/package/kernel/linux/modules/iio.mk
@@ -155,3 +155,21 @@ define KernelPackage/iio-htu21/description
 endef
 
 $(eval $(call KernelPackage,iio-htu21))
+
+
+define KernelPackage/iio-tsl4531
+  SUBMENU:=$(IIO_MENU)
+  DEPENDS:=+kmod-i2c-core +kmod-iio-core
+  TITLE:=TAOS TSL4531 ambient light sensor
+  KCONFIG:= CONFIG_TSL4531
+  FILES:=$(LINUX_DIR)/drivers/iio/light/tsl4531.ko
+  AUTOLOAD:=$(call AutoLoad,56,tsl4531)
+endef
+
+define KernelPackage/iio-tsl4531/description
+ Support for TAOS TSL4531x family of ambient light sensors
+ connected via I2C. Following models are usable:
+ TSL45311, TSL45313, TSL45315, TSL45317.
+endef
+
+$(eval $(call KernelPackage,iio-tsl4531))
-- 
2.1.4


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] ar71xx: WNR612v2: fix kernel panic due to wrong Wifi LED init

[Hartmut Knaack]

Mathias Kresin schrieb am 28.08.2018 um 10:02:
> 27.08.2018 22:22, Hartmut Knaack:
>> Mathias Kresin would have been the one to CC, as he contributed that code.
>> I just added him now.
> 
> Please don't top post! It's a pain to follow the conversation this way.
> 

I generally agree with that rule, but pointing out who else should be cc'd
is commonly put on top.

Thanks,

Hartmut

> Thanks a lot for fixing my mess. The patch is applied to master and the 
> 18.06. branch.
> 
> Mathias
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
> 



0x03684A18FAC89148.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] ar71xx: WNR612v2: fix kernel panic due to wrong Wifi LED init

[Hartmut Knaack]

Mathias Kresin would have been the one to CC, as he contributed that code.
I just added him now.


Michal Cieslakiewicz schrieb am 27.08.2018 um 20:24:
> Netgear WNR612v2 flashed with recent OpenWrt builds suffers from kernel panic
> at boot during wireless chip initialization, making device unusable 
> (system enters 'panic-reboot' loop). TFTP recovery procedure is required
> to load working image. 
> 
> LEDE-17.01 branch is working OK.
> All later builds (OpenWrt-18.06, current) are affected (including stable 
> official 18.06.1 image from downloads.openwrt.org).
> 
> Example log entry:
> 
>  ath: phy0: Ignoring endianness difference in EEPROM magic bytes.
>  ath: phy0: Enable LNA combining
>  CPU 0 Unable to handle kernel paging request at virtual address 1000fee1, 
> epc == 801d08f0, ra == 801d0d90
>  Oops[#1]:
>  CPU: 0 PID: 469 Comm: kmodloader Not tainted 4.9.120 #0
>  [ ... register dump etc ... ]
>  Kernel panic - not syncing: Fatal exception
>  Rebooting in 1 seconds..
> 
> This simple patch fixes above error. It keeps LED table in memory after kernel
> init phase for ath9k driver to operate correctly (__initdata removed).
> Also, another bug is fixed - correct array size is provided to function that
> adds platform LEDs (this device has only 1 connected to Wifi chip) preventing 
> code from going outside array bounds.
> Patch tested succesfully (router boots OK) for both 18.06 and current trees.
> 
> Please accept and include this patch for both current and 18.06 trees (applies
> to both branches identically) as without it WNR612v2 support is utterly 
> broken.
> 
> ===
> Notice to all WNR612v2 owners: please do not flash WNR612v2 with anything 
> newer
> than LEDE 17.01.x until bug mentioned here gets fixed.
> ===
> 
> Signed-off-by: Michal Cieslakiewicz 
> ---
>  target/linux/ar71xx/files/arch/mips/ath79/mach-wnr2000-v3.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-wnr2000-v3.c 
> b/target/linux/ar71xx/files/arch/mips/ath79/mach-wnr2000-v3.c
> index 6c18dc6d90..76c9cb99c9 100644
> --- a/target/linux/ar71xx/files/arch/mips/ath79/mach-wnr2000-v3.c
> +++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-wnr2000-v3.c
> @@ -197,7 +197,7 @@ static struct gpio_led wnr612v2_leds_gpio[] __initdata = {
>   }
>  };
>  
> -static struct gpio_led wnr612v2_wmac_leds_gpio[] __initdata = {
> +static struct gpio_led wnr612v2_wmac_leds_gpio[] = {
>   {
>   .name   = "netgear:green:wlan",
>   .gpio   = WNR612V2_GPIO_WMAC_LED_WLAN_GREEN,
> @@ -561,7 +561,7 @@ static void __init wnr612v2_setup(void)
>wnr612v2_leds_gpio);
>  
>   ap9x_pci_setup_wmac_leds(0, wnr612v2_wmac_leds_gpio,
> -  ARRAY_SIZE(wnr612v2_leds_gpio));
> +  ARRAY_SIZE(wnr612v2_wmac_leds_gpio));
>  
>   ap9x_pci_setup_wmac_btns(0, wnr612v2_wmac_keys_gpio,
>ARRAY_SIZE(wnr612v2_wmac_keys_gpio),
> 



0x03684A18FAC89148.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] Multipurpose pins not locked on WRT3200ACM

[Hartmut Knaack]

Hi,
I was curious if there are some GPIOs exposed on the Linksys WRT3200ACM, so
I started exporting them in /sys/class/gpio. I realized, that some are
locked against exporting (those claimed by gpio-leds and gpio-keys, power
regulator), while others exposed more or less problematic side effects.
Less critical are GPIOs 2 and 3, which seem to be used by the I2C bus,
where a LED driver controls some of the front LEDs.
A number of other GPIOs (22, 23, 25, 28, 30, 32, 33, 35, 56, 38, 40, 41,
42) however had an effect on the NAND-flash in the range of just not being
able to access it for the moment up to corrupt firmware partition (with the
need to unbrick from the boot loader) and even to the point, that it
requested bootloader code on the uart. It seems, GPIO 33 does major
corruption and GPIO 36 can be really nasty.
There are two more GPIOs, which are quite interesting: when GPIO 26 is
exported and set to output, setting its value to 1 causes all LAN LEDs to
light up constantly. May it be connected to the switch chip?
GPIO 52, when exported and set to output, also causes the LED driver on I2C
to not respond any more. What is the reason (connected to a reset line?)
The basic conclusion is: those multipurpose pins in use need to be locked,
just like the gpio-leds and gpio-keys modules do.
The question remaining is: which multipurpose pins are already in use by
NAND-flash, I2C bus, UART0, SATA(?), PCIe(?), some ethernet MII(?) or
something else?

@Imre Kaloz: From what I remember, you had a closer relationship to Linksys
and brought in support for this device (family). I hope you can shed some
light on this issue.

Thanks,

Hartmut


0x03684A18FAC89148.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v2 2/2] modify the header of the mach-gl-ar750s.c

[Hartmut Knaack]

Hi,
I don't see a reason why you would not put these changes into your first
patch right away?
Thanks,

Hartmut

Luochongjun schrieb am 21.05.2018 um 04:08:
> ---
>  target/linux/ar71xx/files/arch/mips/ath79/mach-gl-ar750s.c | 6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-gl-ar750s.c 
> b/target/linux/ar71xx/files/arch/mips/ath79/mach-gl-ar750s.c
> index 8457a0c..b556f9b 100755
> --- a/target/linux/ar71xx/files/arch/mips/ath79/mach-gl-ar750s.c
> +++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-gl-ar750s.c
> @@ -1,9 +1,7 @@
>  /*
> - *  Ubiquiti UniFi AC (LITE) board support
> + *  GL.iNet GL-AR750S board support
>   *
> - *  Copyright (C) 2015-2016 P. Wassi 
> - *
> - *  Derived from: mach-ubnt-xm.c
> + *  Copyright (C) 2018 luochongjun 
>   *
>   *  This program is free software; you can redistribute it and/or modify it
>   *  under the terms of the GNU General Public License version 2 as published
> 



0x03684A18FAC89148.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.infradead.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [LEDE-DEV] [PATCH v2] merge: add OpenWrt branding

[Hartmut Knaack]

Mike Baker wrote on 02.11.2017 16:59:

On 11/1/2017 5:18 PM, Hartmut Knaack wrote:


This raises some more questions: which terms and conditions did people
have
to approve to get an @openwrt.org address? Where can these terms and
conditions be found? Is every email sent from such an address supposed to
be discussed and approved by the group before it gets sent?
Furthermore: how many percent of "the group" needs to agree when it comes
to disabling someones address? 50% or 67%?

The issue is the use of an openwrt email address to make an announcement
on behalf of openwrt stating that openwrt had become lede without ever
discussing it. There were no warning signs, everybody from openwrt
suddenly found out that there was a new project and they had been kicked
out.

- Mike



I'm reading over Jows announcement over and over again, but can not see,
where he would announce it on behalf of openwrt. He has been using his
@openwrt.org, just like countless times before on the mailing list.
I can also not find the claim, that LEDE would be the successor of openwrt,
just that quite a lot of active developers would try to start a new project
with a different focus on certain issues.
I agree, that there were no warning signs on the public mailing list. But
still, what have been the terms and conditions for project email addresses?
How are sanctions decided?
And if I pick up your statement, that using an openwrt email address
implies that it is sent on behalf of openwrt (and thus, reviewed by the
project members and acknowledged by the majority), there should just be one
account for public relations (like version announcements, business
communication on behalf of the project).
I understand, that your feelings got hurt by the announcement, but your
reaction was not professional. So, IMHO you messed up, now deal with it.
Thanks,

Hartmut
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [LEDE-DEV] [PATCH v2] merge: add OpenWrt branding

[Hartmut Knaack]

Philip Prindeville wrote on 28.10.2017 23:20:

Hi all,

Does it seem to anyone else that we’re making this more complicated than it 
needs to be?

If one of the goals we’re going for from here on out is “equality”, then a 
basic litmus test to be applied to any action might be “does this get us closer 
to a level playing field, or further away”?

Since not everyone gets an @openwrt.org email address, I think the answer to “can we 
use @openwrt.org email addresses in SOB’s?” is by extension, “no, because it doesn’t 
get us closer to a level playing field."

We don’t need to argue the finer points of the letter of the law if the spirit 
of the law is already adequately clear.

-Philip



Full Ack!
And in addition, from my point of view, the openwrt mail service got
seriously tainted, when the early LEDE founders got their @openwrt.org
accounts deactivated without prior notice. What is it worth having such
an address in a SOB, if you can't trust that it will last?
Thanks,

Hartmut
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] OpenWrt or LEDE to support industry device; BoardFarm testing

[Hartmut Knaack]

Pfeuffer, Dieter schrieb am 08.08.2017 um 12:03:
> My questions:
> 1. What is the better way, staying at Chaos Calmer or moving to LEDE?

Use the LEDE codebase at the moment, it has seen more activity during the
past year. To be more precise, use the LEDE trunk version to start, if it
got accepted, you can backport to older stable releases.

> 2. On which one will the coming remerge be based?  

LEDE. It has had more progress.

> 3. Is there any deadline for the merge?

Not that I know. The first step (interacting with SPI) is taking much
longer than expected. So you could get your changes in before the remerge
of the code starts.

> 4. We still want to get mainline support for the NM50 in OpenWrt/LEDE. What 
> is the right way to do it with success?
> 

Checkout the current git-sources of LEDE, add high quality code and file a
pull request.



0xFAC89148.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Is "using gpio to simulate I2C bus" robust on AR9331?

[Hartmut Knaack]

Gareth Parker schrieb am 04.05.2017 um 23:33:
> OpenWrt seems dead these days, active development is over at lede-project.

True, but the question was not development-related.

> 
> Also for i2c I would recommend using a PIC microcontroller, its far easier 
> and designed for that purpose.  I use a PIC to control PLL IC's over i2c such 
> as the TSA5511 in FM broadcast gear I design.

And how do you connect to the PIC? First thing that would come to my mind would
be via rs232, but many OpenWrt devices provide just one such interface, and that
is already occupied for debugging messages and console login. Connecting via USB
doesn't look overly practical - I've used the I2C-Tiny USB and had lots of
troubles, caused by sudden USB disconnects and resets.
And any solution, where the kernel won't control the I2C bus, will prevent you 
from
using the massive amount of device drivers included in OpenWrt/LEDE or the Linux
kernel.

> 
> Gareth
> 
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On 
> Behalf Of Hartmut Knaack
> Sent: Friday, 5 May 2017 9:19 a.m.
> To: Xuebing Wang; OpenWrt Development List
> Cc: John Crispin
> Subject: Re: [OpenWrt-Devel] Is "using gpio to simulate I2C bus" robust on 
> AR9331?
> 
> Xuebing Wang schrieb am 04.05.2017 um 03:19:
>> Hi community,
>>
>> I am using Atheros AR9331 + OpenWRT Chaos Calmer 15.05 on a commercial 
>> product.
>>
>> I've used I2C on many projects, all with dedicated I2C controllers. 
>> I've never used GPIOs to simulate I2C on Linux.
>>
>> I may be wrong, I am tending to think that there is no way to generate 
>> good I2C waveforms by using 2 GPIOs (SCL/SDA), except that we disable 
>> all interrupts and maybe using high precision timer when outputing SCL/SDA?
>>
>> Is "using gpio to simulate I2C bus" robust on AR9331?
>>
> 
> I have been using a GPIO extender connected via I2C to a router powered by an 
> AR9132 (should be close enough), running for months without notable issues.
> In that case, I2C traffic was pretty low, it just had to access the GPIOs of 
> the extender a couple of times per hour. It has been way better than using an 
> I2C-Tiny USB adapter, but that would be a different story.
> 
>> Thanks.
>> Xuebing Wang
>> ___
>> openwrt-devel mailing list
>> openwrt-devel@lists.openwrt.org
>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>>
> 
> 
> 



0xFAC89148.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Is "using gpio to simulate I2C bus" robust on AR9331?

[Hartmut Knaack]

Xuebing Wang schrieb am 04.05.2017 um 03:19:
> Hi community,
> 
> I am using Atheros AR9331 + OpenWRT Chaos Calmer 15.05 on a commercial 
> product.
> 
> I've used I2C on many projects, all with dedicated I2C controllers. I've 
> never used GPIOs to simulate I2C on Linux.
> 
> I may be wrong, I am tending to think that there is no way to generate 
> good I2C waveforms by using 2 GPIOs (SCL/SDA), except that we disable 
> all interrupts and maybe using high precision timer when outputing SCL/SDA?
> 
> Is "using gpio to simulate I2C bus" robust on AR9331?
> 

I have been using a GPIO extender connected via I2C to a router powered by
an AR9132 (should be close enough), running for months without notable issues.
In that case, I2C traffic was pretty low, it just had to access the GPIOs of
the extender a couple of times per hour. It has been way better than using an
I2C-Tiny USB adapter, but that would be a different story.

> Thanks.
> Xuebing Wang
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> 



0xFAC89148.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Giveaway: Linksys WRT3200ACM units

[Hartmut Knaack]

Vincent Wiemann schrieb am 08.02.2017 um 22:29:
> Hi everyone,
> 
> has anyone received one of the units, yet?

According to the forum, two guys from Canada, one guy from Australia and
one guy from the UK already got their devices (all 5-eyes countries ;-).

> I wonder how long it takes as my experience with TP-Link (who don't
> really care about free software :D) is that they send their units with
> UPS Express and it never took more than a week...
> 
> On 17.01.2017 20:06, Hartmut Knaack wrote:
>>
>> OK, to answer my question: today we received an email from Belkin/Linksys,
>> asking for a shipping address.
>>
> 
> Kind regards,
> CodeFetch
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> 
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Giveaway: Linksys WRT3200ACM units

[Hartmut Knaack]

Hartmut Knaack schrieb am 15.01.2017 um 18:00:
> Imre Kaloz schrieb am 21.11.2016 um 15:56:
>> Hi,
>>
>> Linksys would like to give away 54 Rango (WRT3200ACM) units. Please use 
>> the relevant post [1] if you want to be one of them.
>>
> 
> Hi Imre,
> what's the current status on this topic? According to your announcement on
> the forum, the 54 persons should have been contacted starting 6 weeks ago.
> Nobody on the forum indicated, that this would have happened already. So,
> as the one who made such promises, please shed some light on what's going
> on.

OK, to answer my question: today we received an email from Belkin/Linksys,
asking for a shipping address.

> Thanks,
> 
> Hartmut
> 
>>
>>
>> Cheers,
>>
>> Imre
>>
>>
>> [1] https://forum.openwrt.org/viewtopic.php?pid=344315#p344315
>> ___
>> openwrt-devel mailing list
>> openwrt-devel@lists.openwrt.org
>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> 



0xFAC89148.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Giveaway: Linksys WRT3200ACM units

[Hartmut Knaack]

Imre Kaloz schrieb am 21.11.2016 um 15:56:
> Hi,
> 
> Linksys would like to give away 54 Rango (WRT3200ACM) units. Please use 
> the relevant post [1] if you want to be one of them.
> 

Hi Imre,
what's the current status on this topic? According to your announcement on
the forum, the 54 persons should have been contacted starting 6 weeks ago.
Nobody on the forum indicated, that this would have happened already. So,
as the one who made such promises, please shed some light on what's going
on.
Thanks,

Hartmut

> 
> 
> Cheers,
> 
> Imre
> 
> 
> [1] https://forum.openwrt.org/viewtopic.php?pid=344315#p344315
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> 
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [LEDE-DEV] Any interest in adding runit to OpenWRT?

[Hartmut Knaack]

Rob Landley schrieb am 03.12.2016 um 20:38:
> On 12/03/2016 09:30 AM, Felix Fietkau wrote:
>> Hi Denys,
>> Here's the thing: OpenWrt/LEDE is starting services via procd.
>> This is a rather essential piece of how we're dealing with system-wide
>> reloading of configuration and automatically restarting/reloading only
>> services which are affected by configuration changes.
>> In comparison, dealing with logging is rather trivial.
>>
>> Because of that, I think switching to runit is not a good trade-off.
>>
>> - Felix
> 
> Any idea why the fourth google hit
> https://www.lede-project.org/docs/procd.html was recently deleted?
> (Google has summary text, but the site says there's no article.)
> 
> Rob

It has probably just moved:

https://www.lede-project.org/docs/guide-developer/procd

> 
> ___
> Lede-dev mailing list
> lede-...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
> 
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Introducing the LEDE project

[Hartmut Knaack]

mbm schrieb am 05.05.2016 um 21:22:
> On 5/5/2016 7:40 AM, Felix Fietkau wrote:
>> Many of the changes that we previously tried to introduce were often 
>> squashed by internal disagreements. Resulting discussions often turned 
>> toxic quickly and led to nothing being done to address the issues. 
>> Setting up the LEDE project was our way of creating a testbed for 
>> changes that we believe are important for the survival of the project. 
> 
> Change is not easy. Discussions need to happen. The problem is simply 
> kicking out people you didn't agree with by starting a new organization 
> in secret; you've created the public perception that we're somehow 
> against you when really we all want the same things.
> 
>> A critical part of many of these debates was the fact that people who 
>> were controlling critical pieces of the infrastructure flat out 
>> refused to allow other people to step up and help, even in the face of 
>> being unable to deal with important issues themselves in a timely 
>> manner. This kind of single-point-of-failure thing has been going on 
>> for years, with no significant progress on resolving it. In the LEDE 
>> project we decided to significantly simplify the infrastructure and 
>> spread out admin access enough to minimize the chance of this 
>> situation ever happening again. 
>> While we have pushed for and actively worked on decentralizing the
>> infrastructure, we were also frequently asked to move back to
>> centralizing things again.
>> The excessive downtime of the main site this year is a good example of
>> why we definitely don't want to go that way.
> 
> I'll let Kaloz address this personally.
> 
>> Do you think we can get the changes outlined by the LEDE project
>> implement in OpenWrt? If so, how?
> 
> We can start by having an actual conversation between the two groups. 
> I'm not against what LEDE was trying to accomplish, but I am against how 
> it was done.
> 
>> We appreciate your effort to have an open discussion about this, 
>> however the sudden deletion of our widely published openwrt.org email 
>> addresses somewhat undermines this. We will not respond in kind and we 
>> will continue to maintain the critical parts of OpenWrt infrastructure 
>> that we control.
> 
> Let's be clear on this subject; no commit access was revoked, you still 
> have full read and write access to the entire OpenWrt tree.
> 
> Email forwarding was temporarily disabled following the LEDE announcement
> - LEDE's own rules prohibit project based email addresses
> - It's unclear if LEDE still represents OpenWrt
> 

Disabling someone's email-account without prior notice and a decent time frame
just because you don't agree with that persons behavior is totally immature
and inappropriate. The 'excuse' pointed out here just demonstrates this
ridiculousness.
Just my 2 cents.
Hartmut

> My hope is that this whole LEDE vs OpenWrt situation can be resolved.
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> 



0xFAC89148.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 2/3] ar71xx: add WNR2200 16M version

[Hartmut Knaack]

Hi Dirk,
just for the records (I didn't spot this myself), there is a typo in the
art partition config, which should be 64k but is just 64.
Please check back with Silent Wanderer before resending, so he may give
his tested-by tag.
Thanks,

Hartmut

Dirk Neukirchen schrieb am 07.03.2016 um 22:12:
> - change naming of old firmware to indicate 8M flash
> 
> this change should support 16M international version
> 
> totally untested, used
> - input from IRC chat,
> - ticket #14356 w. patch,
> - verified against GPL tarball (WNR2200 russia version)
> 
> Signed-off-by: Dirk Neukirchen 
> ---
>  target/linux/ar71xx/image/Makefile | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/target/linux/ar71xx/image/Makefile 
> b/target/linux/ar71xx/image/Makefile
> index ca4437b..d9168fd 100644
> --- a/target/linux/ar71xx/image/Makefile
> +++ b/target/linux/ar71xx/image/Makefile
> @@ -1594,7 +1594,8 @@ 
> dr344_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,6336k(rootfs),1
>  
> wpj531_mtdlayout_16M=mtdparts=spi0.0:192k(u-boot)ro,16128k(firmware),64k(art)ro
>  
> wpj558_mtdlayout_16M=mtdparts=spi0.0:192k(u-boot)ro,16128k(firmware),64k(art)ro
>  
> wndap360_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,1728k(kernel),6016k(rootfs),64k(nvram)ro,64k(art)ro,7744k@0x5(firmware)
> -wnr2200_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,7808k(firmware),64k(art)ro
> +wnr2200_mtdlayout_8M=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,7808k(firmware),64k(art)ro
> +wnr2200_mtdlayout_16M=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,14784k(firmware),64k(config)ro,1024k(language_table)ro,64k(pot)ro,64k(traffic_meter)ro,64(art)ro,1536k0x05(kernel),13248k@0x1d(rootfs)
>  
> wnr2000v3_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,3712k(firmware),64k(art)ro
>  
> wnr2000v4_mtdlayout=mtdparts=spi0.0:192k(u-boot)ro,64k(u-boot-env)ro,3776k(firmware),64k(art)ro
>  
> r6100_mtdlayout=mtdparts=ar934x-nfc:128k(u-boot)ro,256k(caldata),256k(caldata-backup),512k(config),512k(pot),2048k(kernel),122240k(ubi),25600k@0x1a(firmware),2048k(language),3072k(traffic_meter)
> @@ -2450,7 +2451,8 @@ $(eval $(call 
> SingleProfile,MyLoader,64k,WPE72_16M,wpe72,,ttyS0,115200,0x100
>  
>  $(eval $(call 
> SingleProfile,Netgear,64kraw,WNR2000V3,wnr2000v3,WNR2000V3,ttyS0,115200,$$(wnr2000v3_mtdlayout),0x32303033,WNR2000V3,""
>  NA,-H 29763551+04+32))
>  $(eval $(call 
> SingleProfile,NetgearLzma,64kraw,WNR2000V4,wnr2000v4,WNR2000V4,ttyS0,115200,$$(wnr2000v4_mtdlayout),0x32303034,WNR2000V4,""
>  NA,))
> -$(eval $(call 
> SingleProfile,Netgear,64kraw,WNR2200,wnr2200,WNR2200,ttyS0,115200,$$(wnr2200_mtdlayout),0x32323030,wnr2200,""
>  NA,))
> +$(eval $(call 
> SingleProfile,Netgear,64kraw,WNR2200_8M,wnr2200-8m,WNR2200,ttyS0,115200,$$(wnr2200_mtdlayout_8M),0x32323030,wnr2200,""
>  NA,))
> +$(eval $(call 
> SingleProfile,Netgear,64kraw,WNR2200_16M,wnr2200-16m,WNR2200,ttyS0,115200,$$(wnr2200_mtdlayout_16M),0x32323030,wnr2200,""
>  WW,))
>  $(eval $(call 
> SingleProfile,Netgear,64kraw,REALWNR612V2,wnr612v2,WNR612V2,ttyS0,115200,$$(wnr2000v3_mtdlayout),0x32303631,WNR612V2,"",))
>  $(eval $(call 
> SingleProfile,Netgear,64kraw,N150R,n150r,WNR612V2,ttyS0,115200,$$(wnr2000v3_mtdlayout),0x32303631,N150R,"",))
>  $(eval $(call 
> SingleProfile,Netgear,64kraw,REALWNR1000V2,wnr1000v2,WNR1000V2,ttyS0,115200,$$(wnr2000v3_mtdlayout),0x31303031,WNR1000V2,"",))
> @@ -2514,6 +2516,7 @@ $(eval $(call MultiProfile,TEW652BRP,TEW652BRP_FW 
> TEW652BRP_RECOVERY))
>  $(eval $(call MultiProfile,TUBE2H,TUBE2H8M TUBE2H16M))
>  $(eval $(call MultiProfile,WNR612V2,REALWNR612V2 N150R))
>  $(eval $(call MultiProfile,WNR1000V2,REALWNR1000V2 WNR1000V2_VC))
> +$(eval $(call MultiProfile,WNR2200,WNR2200_8M WNR2200_16M))
>  $(eval $(call MultiProfile,WP543,WP543_2M WP543_4M WP543_8M WP543_16M))
>  $(eval $(call MultiProfile,WPE72,WPE72_4M WPE72_8M WPE72_16M))
>  $(eval $(call MultiProfile,WPJ344,WPJ344_16M))
> 
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] CC:ar71xx: backport support for Netgear WPN824N

[Hartmut Knaack]

Add support for Netgear WPN824N.
Hardware specs:
  * AR7240, 4 LAN ports, 1 WAN port
  * AR9285 WLAN
  * 32 MB RAM
  * 4 MB Flash
  * 16 LEDs (LAN, WAN and Power/Status contain two LEDs for dual color
effect)
  * 3 Buttons (not supported)

Signed-off-by: Hartmut Knaack <knaac...@gmx.de>
---
Development Thread: https://forum.openwrt.org/viewtopic.php?id=30388
Test result: https://forum.openwrt.org/viewtopic.php?pid=313815#p313815
Wiki Page: https://wiki.openwrt.org/toh/netgear/wpn824n
---
 target/linux/ar71xx/base-files/etc/diag.sh |   3 +-
 .../ar71xx/base-files/etc/uci-defaults/01_leds |  20 +++-
 .../ar71xx/base-files/etc/uci-defaults/02_network  |   3 +-
 target/linux/ar71xx/base-files/lib/ar71xx.sh   |   3 +
 .../lib/preinit/05_set_preinit_iface_ar71xx|   1 +
 .../ar71xx/base-files/lib/upgrade/platform.sh  |   3 +-
 .../ar71xx/files/arch/mips/ath79/mach-wnr2000-v3.c | 124 -
 target/linux/ar71xx/generic/profiles/netgear.mk|  10 ++
 target/linux/ar71xx/image/Makefile |   1 +
 .../patches-3.18/907-MIPS-ath79-add-WPN824N.patch  |  21 
 .../files/drivers/mtd/mtdsplit/mtdsplit_uimage.c   |   2 +
 11 files changed, 185 insertions(+), 6 deletions(-)
 create mode 100644 
target/linux/ar71xx/patches-3.18/907-MIPS-ath79-add-WPN824N.patch

diff --git a/target/linux/ar71xx/base-files/etc/diag.sh 
b/target/linux/ar71xx/base-files/etc/diag.sh
index 89fe53c..178825a 100644
--- a/target/linux/ar71xx/base-files/etc/diag.sh
+++ b/target/linux/ar71xx/base-files/etc/diag.sh
@@ -324,7 +324,8 @@ get_status_led() {
wnr2000 | \
wnr2200 |\
wnr612-v2 |\
-   wnr1000-v2)
+   wnr1000-v2 |\
+   wpn824n)
status_led="netgear:green:power"
;;
wp543)
diff --git a/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds 
b/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds
index 5241db2..3b43011 100644
--- a/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds
+++ b/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds
@@ -563,7 +563,25 @@ wnr2000-v4)
ucidef_set_led_switch "lan3" "LAN3" "netgear:amber:lan3" "switch0" 
"0x08"
ucidef_set_led_switch "lan4" "LAN4" "netgear:amber:lan4" "switch0" 
"0x10"
ucidef_set_led_usbdev "usb" "USB" "netgear:amber:status" "1-1"
-;;
+   ;;
+
+wpn824n)
+   ucidef_set_led_netdev "wan-amber" "WAN (amber)" "netgear:amber:wan" 
"eth0"
+   ucidef_set_led_wlan "wlan" "WLAN" "netgear:blue:wlan" "phy0tpt"
+   ucidef_set_led_switch "lan1amber" "LAN1 (amber)" "netgear:amber:lan1" 
"switch0" "0x02"
+   ucidef_set_led_switch "lan2amber" "LAN2 (amber)" "netgear:amber:lan2" 
"switch0" "0x04"
+   ucidef_set_led_switch "lan3amber" "LAN3 (amber)" "netgear:amber:lan3" 
"switch0" "0x08"
+   ucidef_set_led_switch "lan4amber" "LAN4 (amber)" "netgear:amber:lan4" 
"switch0" "0x10"
+   ucidef_set_led_default "lan1green" "LAN1 (green)" "netgear:green:lan1" 
"0"
+   ucidef_set_led_default "lan2green" "LAN2 (green)" "netgear:green:lan2" 
"0"
+   ucidef_set_led_default "lan3green" "LAN3 (green)" "netgear:green:lan3" 
"0"
+   ucidef_set_led_default "lan4green" "LAN4 (green)" "netgear:green:lan4" 
"0"
+   ucidef_set_led_default "wan-green" "WAN (green)" "netgear:green:wan" "0"
+   ucidef_set_led_default "wps1" "WPS1" "netgear:blue:wps1" "0"
+   ucidef_set_led_default "wps2" "WPS2" "netgear:blue:wps2" "0"
+   ucidef_set_led_default "status" "STATUS" "netgear:amber:status" "0"
+   ucidef_set_led_default "test" "TEST" "netgear:amber:test" "0"
+   ;;
 
 wzr-hp-ag300h)
ucidef_set_led_default "diag" "DIAG" "buffalo:red:diag" "0"
diff --git a/target/linux/ar71xx/base-files/etc/uci-defaults/02_network 
b/target/linux/ar71xx/base-files/etc/uci-defaults/02_network
index 8143d2d..9a7e01e 100755
--- a/target/linux/ar71xx/base-files/etc/uci-defaults/02_network
+++ b/target/linux/ar71xx/base-files/etc/uci-defaults/02_network
@@ -230,7 +230,8 @@ wnr2000-v3 |\
 wnr2000-v4 |\
 wnr2200 |\
 wnr612-v2 |\
-wnr1000-v2)
+wnr1000-v2 |\
+wpn824n)
ucidef_set_interfaces_la

[OpenWrt-Devel] [PATCH 2/2] ar71xx: WPN824N: enable buttons

[Hartmut Knaack]

Enable buttons connected to the GPIOs of the AR9285.

Signed-off-by: Hartmut Knaack <knaac...@gmx.de>
---
 .../ar71xx/files/arch/mips/ath79/mach-wnr2000-v3.c | 38 +++---
 1 file changed, 33 insertions(+), 5 deletions(-)

diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-wnr2000-v3.c 
b/target/linux/ar71xx/files/arch/mips/ath79/mach-wnr2000-v3.c
index 1fea5ef..4961026 100644
--- a/target/linux/ar71xx/files/arch/mips/ath79/mach-wnr2000-v3.c
+++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-wnr2000-v3.c
@@ -80,7 +80,7 @@
 #define WNR1000V2_GPIO_WMAC_BTN_RESET  7
 #define WNR1000V2_GPIO_WMAC_BTN_RFKILL 8
 
-/* Connected through AR7240 */
+/* WPN824N - connected through AR7240 */
 #define WPN824N_GPIO_LED_WAN_AMBER 0
 #define WPN824N_GPIO_LED_STATUS_AMBER  1
 #define WPN824N_GPIO_LED_LAN1_AMBER6 /* AR724X_GPIO_FUNC_JTAG_DISABLE */
@@ -93,15 +93,15 @@
 #define WPN824N_GPIO_LED_LAN4_GREEN16
 #define WPN824N_GPIO_LED_WAN_GREEN 17
 
-/* Connected through AR9285 */
+/* WPN824N - connected through AR9285 */
 #define WPN824N_WGPIO_LED_PWR_GREEN0
 #define WPN824N_WGPIO_LED_WLAN_BLUE1
 #define WPN824N_WGPIO_LED_WPS1_BLUE5
 #define WPN824N_WGPIO_LED_WPS2_BLUE9
 #define WPN824N_WGPIO_LED_TEST_AMBER   10
-#define WPN824N_WGPIO_BTN_PUSH 6   /* currently unused */
-#define WPN824N_WGPIO_BTN_RESET7   /* currently unused */
-#define WPN824N_WGPIO_BTN_WLAN 8   /* currently unused */
+#define WPN824N_WGPIO_BTN_WPS  6
+#define WPN824N_WGPIO_BTN_RESET7
+#define WPN824N_WGPIO_BTN_WLAN 8
 
 #define WNR2000V3_KEYS_POLL_INTERVAL   20  /* msecs */
 #define WNR2000V3_KEYS_DEBOUNCE_INTERVAL   (3 * 
WNR2000V3_KEYS_POLL_INTERVAL)
@@ -391,6 +391,31 @@ static struct gpio_keys_button wnr1000v2_wmac_keys_gpio[] 
= {
}
 };
 
+static struct gpio_keys_button wpn824n_wmac_keys_gpio[] = {
+   {
+   .desc   = "reset",
+   .type   = EV_KEY,
+   .code   = KEY_RESTART,
+   .debounce_interval  = WNR2000V3_KEYS_DEBOUNCE_INTERVAL,
+   .gpio   = WPN824N_WGPIO_BTN_RESET,
+   .active_low = 1,
+   }, {
+   .desc   = "rfkill",
+   .type   = EV_KEY,
+   .code   = KEY_RFKILL,
+   .debounce_interval  = WNR2000V3_KEYS_DEBOUNCE_INTERVAL,
+   .gpio   = WPN824N_WGPIO_BTN_WLAN,
+   .active_low = 1,
+   }, {
+   .desc   = "wps",
+   .type   = EV_KEY,
+   .code   = KEY_WPS_BUTTON,
+   .debounce_interval  = WNR2000V3_KEYS_DEBOUNCE_INTERVAL,
+   .gpio   = WPN824N_WGPIO_BTN_WPS,
+   .active_low = 1,
+   }
+};
+
 /*
  * For WNR2000v3 ART flash area used for WLAN MAC is usually empty (0xff)
  * so ath9k driver uses random MAC instead each time module is loaded.
@@ -603,6 +628,9 @@ static void __init wpn824n_setup(void)
ap9x_pci_setup_wmac_led_name(0, wnr2000v3_wmac_led_name);
ap9x_pci_setup_wmac_leds(0, wpn824n_wmac_leds_gpio,
 ARRAY_SIZE(wpn824n_wmac_leds_gpio));
+   ap9x_pci_setup_wmac_btns(0, wpn824n_wmac_keys_gpio,
+ARRAY_SIZE(wpn824n_wmac_keys_gpio),
+WNR2000V3_KEYS_POLL_INTERVAL);
 }
 
 MIPS_MACHINE(ATH79_MACH_WPN824N, "WPN824N", "NETGEAR WPN824N", wpn824n_setup);
-- 
2.7.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 1/2] ar71xx: WPN824N: set WLAN LED name

[Hartmut Knaack]

Make use of ap9x_pci_setup_wmac_led_name() to set the name of the WLAN
LED.

Signed-off-by: Hartmut Knaack <knaac...@gmx.de>
---
 target/linux/ar71xx/files/arch/mips/ath79/mach-wnr2000-v3.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-wnr2000-v3.c 
b/target/linux/ar71xx/files/arch/mips/ath79/mach-wnr2000-v3.c
index 8f585fb..1fea5ef 100644
--- a/target/linux/ar71xx/files/arch/mips/ath79/mach-wnr2000-v3.c
+++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-wnr2000-v3.c
@@ -173,7 +173,7 @@ static struct gpio_led wnr2000v3_wmac_leds_gpio[] = {
}
 };
 
-/* Blue WLAN LED for: WNR2000v3, WNR1000v2 */
+/* Blue WLAN LED for: WNR2000v3, WNR1000v2, WPN824N */
 static const char *wnr2000v3_wmac_led_name = "netgear:blue:wlan";
 
 static struct gpio_led wnr612v2_leds_gpio[] __initdata = {
@@ -312,10 +312,6 @@ static struct gpio_led wpn824n_wmac_leds_gpio[] = {
.gpio   = WPN824N_WGPIO_LED_PWR_GREEN,
.active_low = 1,
}, {
-   .name   = "netgear:blue:wlan",
-   .gpio   = WPN824N_WGPIO_LED_WLAN_BLUE,
-   .active_low = 1,
-   }, {
.name   = "netgear:blue:wps1",
.gpio   = WPN824N_WGPIO_LED_WPS1_BLUE,
.active_low = 1,
@@ -604,6 +600,7 @@ static void __init wpn824n_setup(void)
 wpn824n_leds_gpio);
 
ap9x_pci_setup_wmac_led_pin(0, WPN824N_WGPIO_LED_WLAN_BLUE);
+   ap9x_pci_setup_wmac_led_name(0, wnr2000v3_wmac_led_name);
ap9x_pci_setup_wmac_leds(0, wpn824n_wmac_leds_gpio,
 ARRAY_SIZE(wpn824n_wmac_leds_gpio));
 }
-- 
2.7.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 2/2] ar71xx: WNR1000v2: enable control of all LEDs and buttons

[Hartmut Knaack]

Michal schrieb am 18.03.2016 um 00:36:
> From: Michal Cieslakiewicz 
> Date: Thu, 17 Mar 2016 23:32:48 +0100
> Subject: [PATCH 2/2] ar71xx: WNR1000v2: enable control of all LEDs and buttons
> 
> This patch provides full GPIO support for WNR1000v2 (LEDs and buttons).
> It exposes all LEDs to operating system, including Ethernet ones.

Hi Michal,
small nitpick: I would move up the entry in 01_leds to maintain alphabetical
order. Also in wnr1000v2_leds_gpio[], entries would better be grouped/sorted
by the .name property.
Thanks,

Hartmut

> 
> Signed-off-by: Michal Cieslakiewicz 
> ---
>  target/linux/ar71xx/base-files/etc/board.d/01_leds |   3 +-
>  .../ar71xx/files/arch/mips/ath79/mach-wnr2000-v3.c | 132 
> -
>  2 files changed, 129 insertions(+), 6 deletions(-)
> 
> diff --git a/target/linux/ar71xx/base-files/etc/board.d/01_leds 
> b/target/linux/ar71xx/base-files/etc/board.d/01_leds
> index eff6e0d..96c892c 100755
> --- a/target/linux/ar71xx/base-files/etc/board.d/01_leds
> +++ b/target/linux/ar71xx/base-files/etc/board.d/01_leds
> @@ -681,7 +681,8 @@ wlae-ag300n)
>   ucidef_set_led_netdev "wireless" "WIRELESS" "buffalo:green:wireless" 
> "wlan0"
>   ;;
>  
> -wnr2000-v3)
> +wnr2000-v3 |\
> +wnr1000-v2)
>   ucidef_set_led_netdev "wan-amber" "WAN (amber)" "netgear:amber:wan" 
> "eth0"
>   ucidef_set_led_default "wan-green" "WAN (green)" "netgear:green:wan" "0"
>   ucidef_set_led_netdev "wlan" "WLAN" "netgear:blue:wlan" "wlan0"
> diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-wnr2000-v3.c 
> b/target/linux/ar71xx/files/arch/mips/ath79/mach-wnr2000-v3.c
> index b1b0394..4af7b4d 100644
> --- a/target/linux/ar71xx/files/arch/mips/ath79/mach-wnr2000-v3.c
> +++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-wnr2000-v3.c
> @@ -59,8 +59,26 @@
>  #define WNR612V2_GPIO_WMAC_LED_WLAN_GREEN1
>  #define WNR612V2_GPIO_WMAC_BTN_RESET 7
>  
> -#define WNR1000V2_GPIO_LED_PWR_AMBER 1
> -#define WNR1000V2_GPIO_LED_PWR_GREEN 11
> +/* WNR1000v2 - connected through AR7240 */
> +#define WNR1000V2_GPIO_LED_WAN_AMBER 0
> +#define WNR1000V2_GPIO_LED_TEST_AMBER1
> +#define WNR1000V2_GPIO_LED_LAN1_AMBER6 /* 
> AR724X_GPIO_FUNC_JTAG_DISABLE */
> +#define WNR1000V2_GPIO_LED_LAN2_AMBER7 /* 
> AR724X_GPIO_FUNC_JTAG_DISABLE */
> +#define WNR1000V2_GPIO_LED_LAN3_AMBER8 /* 
> AR724X_GPIO_FUNC_JTAG_DISABLE */
> +#define WNR1000V2_GPIO_LED_POWER_GREEN   11
> +#define WNR1000V2_GPIO_LED_LAN4_AMBER12
> +#define WNR1000V2_GPIO_LED_LAN1_GREEN13 /* 
> AR724X_..._ETH_SWITCH_LED0 */
> +#define WNR1000V2_GPIO_LED_LAN2_GREEN14 /* 
> AR724X_..._ETH_SWITCH_LED1 */
> +#define WNR1000V2_GPIO_LED_LAN3_GREEN15 /* 
> AR724X_..._ETH_SWITCH_LED2 */
> +#define WNR1000V2_GPIO_LED_LAN4_GREEN16 /* 
> AR724X_..._ETH_SWITCH_LED3 */
> +#define WNR1000V2_GPIO_LED_WAN_GREEN 17 /* AR724X_..._ETH_SWITCH_LED4 */
> +
> +/* WNR1000v2 - connected through AR9285 */
> +#define WNR1000V2_GPIO_WMAC_LED_WLAN_BLUE1
> +#define WNR1000V2_GPIO_WMAC_LED_WPS_GREEN5
> +#define WNR1000V2_GPIO_WMAC_BTN_WPS  6
> +#define WNR1000V2_GPIO_WMAC_BTN_RESET7
> +#define WNR1000V2_GPIO_WMAC_BTN_RFKILL   8
>  
>  /* Connected through AR7240 */
>  #define WPN824N_GPIO_LED_WAN_AMBER   0
> @@ -155,6 +173,7 @@ static struct gpio_led wnr2000v3_wmac_leds_gpio[] = {
>   }
>  };
>  
> +/* Blue WLAN LED for: WNR2000v3, WNR1000v2 */
>  static const char *wnr2000v3_wmac_led_name = "netgear:blue:wlan";
>  
>  static struct gpio_led wnr612v2_leds_gpio[] __initdata = {
> @@ -181,12 +200,60 @@ static const char *wnr612v2_wmac_led_name = 
> "netgear:green:wlan";
>  
>  static struct gpio_led wnr1000v2_leds_gpio[] __initdata = {
>   {
> + .name   = "netgear:amber:wan",
> + .gpio   = WNR1000V2_GPIO_LED_WAN_AMBER,
> + .active_low = 1,
> + }, {
> + .name   = "netgear:amber:test",
> + .gpio   = WNR1000V2_GPIO_LED_TEST_AMBER,
> + .active_low = 1,
> + }, {
> + .name   = "netgear:amber:lan1",
> + .gpio   = WNR1000V2_GPIO_LED_LAN1_AMBER,
> + .active_low = 1,
> + }, {
> + .name   = "netgear:amber:lan2",
> + .gpio   = WNR1000V2_GPIO_LED_LAN2_AMBER,
> + .active_low = 1,
> + }, {
> + .name   = "netgear:amber:lan3",
> + .gpio   = WNR1000V2_GPIO_LED_LAN3_AMBER,
> + .active_low = 1,
> + }, {
>   .name   = "netgear:green:power",
> - .gpio   = WNR1000V2_GPIO_LED_PWR_GREEN,
> + .gpio   = WNR1000V2_GPIO_LED_POWER_GREEN,
> + .active_low = 1,
> + }, {
> + .name   = "netgear:amber:lan4",
> +

Re: [OpenWrt-Devel] [PATCH v4 4/8] mac80211: ath9k: enable access to GPIO

[Hartmut Knaack]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Michal schrieb am 01.02.2016 um 22:28:
> From: Michal Cieslakiewicz <michal.cieslakiew...@wp.pl>
> Subject: [PATCH v4 4/8] mac80211: ath9k: enable access to GPIO
> 
> Enable access to GPIO chip and its pins for Atheros AR92xx
> wireless devices. For now AR9285 and AR9287 are supported.
> 
> Signed-off-by: Michal Cieslakiewicz <michal.cieslakiew...@wp.pl>
Acked-by: Hartmut Knaack <knaac...@gmx.de>
> ---
>  .../patches/549-ath9k_enable_gpio_chip.patch   | 243 
> +
>  1 file changed, 243 insertions(+)
>  create mode 100644 
> package/kernel/mac80211/patches/549-ath9k_enable_gpio_chip.patch
> 
> diff --git a/package/kernel/mac80211/patches/549-ath9k_enable_gpio_chip.patch 
> b/package/kernel/mac80211/patches/549-ath9k_enable_gpio_chip.patch
> new file mode 100644
> index 000..beee169
> --- /dev/null
> +++ b/package/kernel/mac80211/patches/549-ath9k_enable_gpio_chip.patch
> @@ -0,0 +1,243 @@
> +From: Michal Cieslakiewicz <michal.cieslakiew...@wp.pl>
> +Date: Sun, 31 Jan 2016 21:01:31 +0100
> +Subject: [PATCH v4 4/8] mac80211: ath9k: enable access to GPIO
> +
> +Enable access to GPIO chip and its pins for Atheros AR92xx
> +wireless devices. For now AR9285 and AR9287 are supported.
> +
> +Signed-off-by: Michal Cieslakiewicz <michal.cieslakiew...@wp.pl>
> +---
> + ath9k.h |   23 
> + gpio.c  |  121 
> 
> + init.c  |2 +
> + 3 files changed, 146 insertions(+)
> +
> +--- a/drivers/net/wireless/ath/ath9k/ath9k.h
>  b/drivers/net/wireless/ath/ath9k/ath9k.h
> +@@ -24,6 +24,7 @@
> + #include 
> + #include 
> + #include 
> ++#include 
> + 
> + #include "common.h"
> + #include "debug.h"
> +@@ -817,6 +818,13 @@ void ath_fill_led_pin(struct ath_softc *
> + int ath_create_gpio_led(struct ath_softc *sc, int gpio, const char *name,
> + const char *trigger, bool active_low);
> + 
> ++/***/
> ++/*  GPIO Chip  */
> ++/***/
> ++
> ++void ath9k_register_gpio_chip(struct ath_softc *sc);
> ++void ath9k_unregister_gpio_chip(struct ath_softc *sc);
> ++
> + #else
> + static inline void ath_init_leds(struct ath_softc *sc)
> + {
> +@@ -828,6 +836,14 @@ static inline void ath_deinit_leds(struc
> + static inline void ath_fill_led_pin(struct ath_softc *sc)
> + {
> + }
> ++
> ++static inline void ath9k_register_gpio_chip(struct ath_softc *sc)
> ++{
> ++}
> ++
> ++static inline void ath9k_unregister_gpio_chip(struct ath_softc *sc)
> ++{
> ++}
> + #endif
> + 
> + //
> +@@ -963,6 +979,12 @@ struct ath_led {
> + struct led_classdev cdev;
> + };
> + 
> ++struct ath9k_gpio_chip {
> ++struct ath_softc *sc;
> ++char label[32];
> ++struct gpio_chip gchip;
> ++};
> ++
> + struct ath_softc {
> + struct ieee80211_hw *hw;
> + struct device *dev;
> +@@ -1017,6 +1039,7 @@ struct ath_softc {
> + #ifdef CPTCFG_MAC80211_LEDS
> + const char *led_default_trigger;
> + struct list_head leds;
> ++struct ath9k_gpio_chip *gpiochip;
> + #endif
> + 
> + #ifdef CPTCFG_ATH9K_DEBUGFS
> +--- a/drivers/net/wireless/ath/ath9k/gpio.c
>  b/drivers/net/wireless/ath/ath9k/gpio.c
> +@@ -22,6 +22,9 @@
> + //
> + 
> + #ifdef CPTCFG_MAC80211_LEDS
> ++
> ++#include 
> ++
> + static void ath_led_brightness(struct led_classdev *led_cdev,
> +enum led_brightness brightness)
> + {
> +@@ -60,6 +63,10 @@ static int ath_add_led(struct ath_softc
> + else
> + ath9k_hw_set_gpio(sc->sc_ah, gpio->gpio, gpio->active_low);
> + 
> ++/* If there is GPIO chip configured, reserve LED pin */
> ++if (sc->gpiochip)
> ++gpio_request(sc->gpiochip->gchip.base + gpio->gpio, gpio->name);
> ++
> + return 0;
> + }
> + 
> +@@ -116,6 +123,9 @@ void ath_deinit_leds(struct ath_softc *s
> + 
> + while (!list_empty(>leds)) {
> + led = list_first_entry(>leds, struct ath_led, list);
> ++/* If there is GPIO chip configured, free LED pin */
> ++if (sc->gpiochip)
> ++gpio_free(sc->gpiochip->gchip.base + led->gpio->gpio);
> + list_del(>list);
> + ath_led_brightness(>cdev, LED_OFF);
> + led_classdev_unregister(>cdev);
> +@@ -186,6 +196,117 @@ void ath_fill_led_pin(struct ath_softc *
> + /* LED off, active low */
> + ath9k_hw_set_gpio(ah, ah->led_pin, (ah->confi

Re: [OpenWrt-Devel] [PATCH v4 6/8] ar71xx: WNR2000v3: exclude USB modules from image

[Hartmut Knaack]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Michal schrieb am 01.02.2016 um 22:59:
> From: Michal Cieslakiewicz <michal.cieslakiew...@wp.pl>
> Subject: [PATCH v4 6/8] ar71xx: WNR2000v3: exclude USB modules from image
> 
> Netgear WNR2000v3 has no USB port yet default system image
> includes USB kernel modules. This patch fixes that.
> 
> Signed-off-by: Michal Cieslakiewicz <michal.cieslakiew...@wp.pl>
Acked-by: Hartmut Knaack <knaac...@gmx.de>
> ---
>  target/linux/ar71xx/generic/profiles/netgear.mk | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/target/linux/ar71xx/generic/profiles/netgear.mk 
> b/target/linux/ar71xx/generic/profiles/netgear.mk
> index ca22a18..0b05adf 100644
> --- a/target/linux/ar71xx/generic/profiles/netgear.mk
> +++ b/target/linux/ar71xx/generic/profiles/netgear.mk
> @@ -30,6 +30,7 @@ $(eval $(call Profile,WNDR3700))
>  
>  define Profile/WNR2000V3
>   NAME:=NETGEAR WNR2000V3
> + PACKAGES:=
>  endef
>  
>  define Profile/WNR2000V3/Description
> 

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWr+jbAAoJEANoShj6yJFI+UcP/1EnDjDrEg9OEzizhKvj0lD7
nhR9zJEoETvY89Rq5KgLTEfTZaUm+lVPqm9VICISsQNEWWswp8r3CI9XkoSM53Ay
vDg0qiKlx5ePylWY7Tm5ru9e6+Cd+/3HB2H6CCDkXvsw4rFo5GDxA28DKsoQqBR8
IWBMe7AtLqnTPkvIOV3ERDcg6T5IJBVBOjGblIxvofp2Z25BQCy/d6UeFPYwbTWE
5xk+nKTASKTKHRMMPywR0ana0tIQ5i/psZqdnP8SzL05kOzixp+DIrwwG7cOssuQ
MVqMmstT+hALG8a/oHI05P+44fc5MSKbGmyJ1xMKq5BhHCIVsvgeE9OjMDmxpH5m
g7ibG0vRjf2g//7iWt+FeVQCwCxD2huOfO44D3s6bCDGTcQ6csO6Duc/UqnUPnCg
910jobStBqLpOLaR6TvPllwrsNGrBfc9fssmx0tJqjK2YHAer01Ur7J0wQCl4XMf
WTdmuVpnZTWVGMqN9zaLN2nwrPytDnNpanLYn50kJ8aDCWhdzfUIsMBMAegq86Iy
mHkQFFySLgAbwcN8/hSG6A8cjJoXUev5CdZGgf5j/1RRjkvBoXJgNM12ZtWe4fT+
sVzoNR4jK2jIaS+DoUvq71qxsgO3E2P6XsH6GgAmFRQAnGPLt2pYTlIo5wRlOBbj
4VrrJOzUWCVo0uDIJiqz
=LQQy
-END PGP SIGNATURE-


0xFAC89148.asc
Description: application/pgp-keys
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v4 1/8] mac80211: ath9k: enable platform WLAN LED name

[Hartmut Knaack]

Michal schrieb am 01.02.2016 um 22:21:
> From: Michal Cieslakiewicz <michal.cieslakiew...@wp.pl>
> Subject: [PATCH v4 1/8] mac80211: ath9k: enable platform WLAN LED name
> 
> Enable platform-supplied WLAN LED name for ath9k device.
> 
> Signed-off-by: Michal Cieslakiewicz <michal.cieslakiew...@wp.pl>
Acked-by: Hartmut Knaack <knaac...@gmx.de>
> ---
>  .../patches/546-ath9k_platform_led_name.patch  | 48 
> ++
>  .../ar71xx/files/arch/mips/ath79/dev-ap9x-pci.c| 12 ++
>  .../ar71xx/files/arch/mips/ath79/dev-ap9x-pci.h|  3 ++
>  .../generic/files/include/linux/ath9k_platform.h   |  1 +
>  4 files changed, 64 insertions(+)
>  create mode 100644 
> package/kernel/mac80211/patches/546-ath9k_platform_led_name.patch
> 
> diff --git 
> a/package/kernel/mac80211/patches/546-ath9k_platform_led_name.patch 
> b/package/kernel/mac80211/patches/546-ath9k_platform_led_name.patch
> new file mode 100644
> index 000..8d2d899
> --- /dev/null
> +++ b/package/kernel/mac80211/patches/546-ath9k_platform_led_name.patch
> @@ -0,0 +1,48 @@
> +From: Michal Cieslakiewicz <michal.cieslakiew...@wp.pl>
> +Date: Sun, 31 Jan 2016 20:45:57 +0100
> +Subject: [PATCH v4 1/8] mac80211: ath9k: enable platform WLAN LED name
> +
> +Enable platform-supplied WLAN LED name for ath9k device. It replaces generic
> +'ath9k-phy*' label with string set during platform initialization.
> +
> +Signed-off-by: Michal Cieslakiewicz <michal.cieslakiew...@wp.pl>
> +---
> + drivers/net/wireless/ath/ath9k/gpio.c |   10 +++---
> + include/linux/ath9k_platform.h|1 +
> + 2 files changed, 8 insertions(+), 3 deletions(-)
> +
> +--- a/drivers/net/wireless/ath/ath9k/gpio.c
>  b/drivers/net/wireless/ath/ath9k/gpio.c
> +@@ -132,15 +132,19 @@ void ath_init_leds(struct ath_softc *sc)
> + if (AR_SREV_9100(sc->sc_ah))
> + return;
> + 
> +-snprintf(led_name, sizeof(led_name), "ath9k-%s",
> +- wiphy_name(sc->hw->wiphy));
> ++if (pdata && pdata->led_name)
> ++strncpy(led_name, pdata->led_name, sizeof(led_name));
> ++else
> ++snprintf(led_name, sizeof(led_name), "ath9k-%s",
> ++ wiphy_name(sc->hw->wiphy));
> + 
> + if (ath9k_led_blink)
> + trigger = sc->led_default_trigger;
> + else
> + trigger = ieee80211_get_radio_led_name(sc->hw);
> + 
> +-ath_create_gpio_led(sc, sc->sc_ah->led_pin, led_name, trigger, 
> !sc->sc_ah->config.led_active_high);
> ++ath_create_gpio_led(sc, sc->sc_ah->led_pin, led_name, trigger,
> ++!sc->sc_ah->config.led_active_high);
> + 
> + if (!pdata)
> + return;
> +--- a/include/linux/ath9k_platform.h
>  b/include/linux/ath9k_platform.h
> +@@ -45,6 +45,7 @@ struct ath9k_platform_data {
> + 
> + int num_leds;
> + const struct gpio_led *leds;
> ++const char *led_name;
> + };
> + 
> + #endif /* _LINUX_ATH9K_PLATFORM_H */
> diff --git a/target/linux/ar71xx/files/arch/mips/ath79/dev-ap9x-pci.c 
> b/target/linux/ar71xx/files/arch/mips/ath79/dev-ap9x-pci.c
> index d382453..bf80d4d 100644
> --- a/target/linux/ar71xx/files/arch/mips/ath79/dev-ap9x-pci.c
> +++ b/target/linux/ar71xx/files/arch/mips/ath79/dev-ap9x-pci.c
> @@ -39,6 +39,18 @@ __init void ap9x_pci_setup_wmac_led_pin(unsigned wmac, int 
> pin)
>   }
>  }
>  
> +__init void ap9x_pci_setup_wmac_led_name(unsigned wmac, const char *led_name)
> +{
> + switch (wmac) {
> + case 0:
> + ap9x_wmac0_data.led_name = led_name;
> + break;
> + case 1:
> + ap9x_wmac1_data.led_name = led_name;
> + break;
> + }
> +}
> +
>  __init struct ath9k_platform_data *ap9x_pci_get_wmac_data(unsigned wmac)
>  {
>   switch (wmac) {
> diff --git a/target/linux/ar71xx/files/arch/mips/ath79/dev-ap9x-pci.h 
> b/target/linux/ar71xx/files/arch/mips/ath79/dev-ap9x-pci.h
> index ad288cb..dcfe541 100644
> --- a/target/linux/ar71xx/files/arch/mips/ath79/dev-ap9x-pci.h
> +++ b/target/linux/ar71xx/files/arch/mips/ath79/dev-ap9x-pci.h
> @@ -19,6 +19,7 @@ void ap9x_pci_setup_wmac_led_pin(unsigned wmac, int pin);
>  void ap9x_pci_setup_wmac_gpio(unsigned wmac, u32 mask, u32 val);
>  void ap9x_pci_setup_wmac_leds(unsigned wmac, struct gpio_led *leds,
> int num_leds);
> +void ap9x_pci_setup_wmac_led_name(unsigned wmac, const char *led_name);
>  struct ath9k_platform_data *ap9x_pci_get_wmac_data(unsigned wmac);
>  
>  void ap91_pci_init(u8 *cal_data, u8 *mac_addr);
> @@ -

Re: [OpenWrt-Devel] [PATCH v4 3/8] mac80211: ath9k: show platform MAC address in kernel log if set

[Hartmut Knaack]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Michal schrieb am 01.02.2016 um 22:26:
> From: Michal Cieslakiewicz <michal.cieslakiew...@wp.pl>
> Subject: [PATCH v4 3/8] mac80211: ath9k: show platform MAC address in kernel 
> log if set
> 
> Add information in kernel log during module startup if MAC address
> of WLAN device is overridden by platform-supplied one.
> 
> Signed-off-by: Michal Cieslakiewicz <michal.cieslakiew...@wp.pl>
Acked-by: Hartmut Knaack <knaac...@gmx.de>
> ---
>  .../patches/548-ath9k_platform_mac_info.patch  | 31 
> ++
>  1 file changed, 31 insertions(+)
>  create mode 100644 
> package/kernel/mac80211/patches/548-ath9k_platform_mac_info.patch
> 
> diff --git 
> a/package/kernel/mac80211/patches/548-ath9k_platform_mac_info.patch 
> b/package/kernel/mac80211/patches/548-ath9k_platform_mac_info.patch
> new file mode 100644
> index 000..fece1f2
> --- /dev/null
> +++ b/package/kernel/mac80211/patches/548-ath9k_platform_mac_info.patch
> @@ -0,0 +1,31 @@
> +From: Michal Cieslakiewicz <michal.cieslakiew...@wp.pl>
> +Date: Sun, 31 Jan 2016 20:51:53 +0100
> +Subject: [PATCH v4 3/8] mac80211: ath9k: show platform MAC address in kernel
> + log if set
> +
> +Add information in kernel log during module startup if MAC address
> +of WLAN device is overridden by platform-supplied one. This one allows
> +user to see final MAC address for device, especially when invalid/random
> +address is assigned first and then overwritten by platform data.
> +
> +Signed-off-by: Michal Cieslakiewicz <michal.cieslakiew...@wp.pl>
> +---
> + init.c |6 +-
> + 1 file changed, 5 insertions(+), 1 deletion(-)
> +
> +--- a/drivers/net/wireless/ath/ath9k/init.c
>  b/drivers/net/wireless/ath/ath9k/init.c
> +@@ -640,8 +640,12 @@ static int ath9k_init_softc(u16 devid, s
> + if (ret)
> + goto err_hw;
> + 
> +-if (pdata && pdata->macaddr)
> ++if (pdata && pdata->macaddr) {
> + memcpy(common->macaddr, pdata->macaddr, ETH_ALEN);
> ++ath_info(common,
> ++ "platform MAC address will be used: %pM\n",
> ++ common->macaddr);
> ++}
> + 
> + ret = ath9k_init_queues(sc);
> + if (ret)
> 

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWr+dJAAoJEANoShj6yJFIKksP/jlNmkTEXw3Rnr2jjIgy+kUh
CekJ4LNuuJog4MUO75F06NO0haXQZI+OGllm6pOTmMLdTKJ65FX0NoEcst7bCctm
ukZ8i1CWOp/6j7NgSGirbFK2bDNnZX+5rP93V0MBVEXQGJogKgvEE0t2KLNcZW8u
rjFuNNdzLYsI7MpY+P1Y/6XzV5SWx1JJwtpxdAvP8PtXBAaHml3K/pFjmwEE2OK0
hEgGjVP49LG/crLwCgyK44PpEh9pAO7551MwbKcZih9vTj+fG/h5IkkGTE82bAAV
mJgzm1D/O7mvt0QtK2CasY3MZh5a8E2RDJLewp0GsddbISfJPBDh2ee460NftH5T
rapHCkw0L8upwEIwWQT8/2EYkHv4kKFgNNurErkaiuzarlVCMmkbxHx9vn/Tnlk3
8KW3O8fDdU03b0bkGF6UQ8kV0gtjszFm5XV/SbH9WSRlfJQqd2SJtMPhxskTyyLI
T3FVqjn28CvEo+wEtKnMZwGpTkUrtrSSjJYNpMGRPjA9b9q/Jf7ZJka4OnUYbNZ3
cw/QGmPH56qSw0ta4Vl8vA+iyVKeZGruH8pE51GwbIL5CjJugzzDyu9MUqrcgRMX
c+imYvVulCFCJ6f7YxtO8GfApXLCtNPVblUkxj1R2ael4tGgZ/9/Q5S7z6yQSKkl
QjxI4Yj5ex/GLPZTOhk2
=GTZj
-END PGP SIGNATURE-


0xFAC89148.asc
Description: application/pgp-keys
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v4 5/8] mac80211: ath9k: enable GPIO buttons

[Hartmut Knaack]

Michal schrieb am 01.02.2016 um 22:29:
> From: Michal Cieslakiewicz <michal.cieslakiew...@wp.pl>
> Subject: [PATCH v4 5/8] mac80211: ath9k: enable GPIO buttons
> 
> Enable platform-defined GPIO button support for ath9k device. Key poller
> is activated for attached platform buttons. Requires ath9k GPIO chip access.
> 
> Signed-off-by: Michal Cieslakiewicz <michal.cieslakiew...@wp.pl>
Acked-by: Hartmut Knaack <knaac...@gmx.de>
> ---
>  .../patches/550-ath9k_enable_gpio_buttons.patch| 178 
> +
>  .../ar71xx/files/arch/mips/ath79/dev-ap9x-pci.c|  14 ++
>  .../ar71xx/files/arch/mips/ath79/dev-ap9x-pci.h|   7 +
>  .../generic/files/include/linux/ath9k_platform.h   |   4 +
>  4 files changed, 203 insertions(+)
>  create mode 100644 
> package/kernel/mac80211/patches/550-ath9k_enable_gpio_buttons.patch
> 
> diff --git 
> a/package/kernel/mac80211/patches/550-ath9k_enable_gpio_buttons.patch 
> b/package/kernel/mac80211/patches/550-ath9k_enable_gpio_buttons.patch
> new file mode 100644
> index 000..485ccc3
> --- /dev/null
> +++ b/package/kernel/mac80211/patches/550-ath9k_enable_gpio_buttons.patch
> @@ -0,0 +1,178 @@
> +From: Michal Cieslakiewicz <michal.cieslakiew...@wp.pl>
> +Date: Sun, 31 Jan 2016 21:14:18 +0100
> +Subject: [PATCH v4 5/8] mac80211: ath9k: enable GPIO buttons
> +
> +Enable platform-defined GPIO button support for ath9k device. Key poller
> +is activated for attached platform buttons. Requires ath9k GPIO chip access.
> +
> +Signed-off-by: Michal Cieslakiewicz <michal.cieslakiew...@wp.pl>
> +---
> + drivers/net/wireless/ath/ath9k/ath9k.h |   16 ++
> + drivers/net/wireless/ath/ath9k/gpio.c  |   77 
> +
> + drivers/net/wireless/ath/ath9k/init.c  |2 
> + include/linux/ath9k_platform.h |4 +
> + 4 files changed, 99 insertions(+)
> +
> +--- a/drivers/net/wireless/ath/ath9k/ath9k.h
>  b/drivers/net/wireless/ath/ath9k/ath9k.h
> +@@ -825,6 +825,13 @@ int ath_create_gpio_led(struct ath_softc
> + void ath9k_register_gpio_chip(struct ath_softc *sc);
> + void ath9k_unregister_gpio_chip(struct ath_softc *sc);
> + 
> ++/**/
> ++/*  GPIO Buttons  */
> ++/**/
> ++
> ++void ath9k_init_buttons(struct ath_softc *sc);
> ++void ath9k_deinit_buttons(struct ath_softc *sc);
> ++
> + #else
> + static inline void ath_init_leds(struct ath_softc *sc)
> + {
> +@@ -844,6 +851,14 @@ static inline void ath9k_register_gpio_c
> + static inline void ath9k_unregister_gpio_chip(struct ath_softc *sc)
> + {
> + }
> ++
> ++static inline void ath9k_init_buttons(struct ath_softc *sc)
> ++{
> ++}
> ++
> ++static inline void ath9k_deinit_buttons(struct ath_softc *sc)
> ++{
> ++}
> + #endif
> + 
> + //
> +@@ -1040,6 +1055,7 @@ struct ath_softc {
> + const char *led_default_trigger;
> + struct list_head leds;
> + struct ath9k_gpio_chip *gpiochip;
> ++struct platform_device *btnpdev;/* gpio-keys-polled */
> + #endif
> + 
> + #ifdef CPTCFG_ATH9K_DEBUGFS
> +--- a/drivers/net/wireless/ath/ath9k/gpio.c
>  b/drivers/net/wireless/ath/ath9k/gpio.c
> +@@ -24,6 +24,8 @@
> + #ifdef CPTCFG_MAC80211_LEDS
> + 
> + #include 
> ++#include 
> ++#include 
> + 
> + static void ath_led_brightness(struct led_classdev *led_cdev,
> +enum led_brightness brightness)
> +@@ -307,6 +309,81 @@ void ath9k_unregister_gpio_chip(struct a
> + sc->gpiochip = NULL;
> + }
> + 
> ++/**/
> ++/*  GPIO Buttons  */
> ++/**/
> ++
> ++/* add GPIO buttons */
> ++void ath9k_init_buttons(struct ath_softc *sc)
> ++{
> ++struct ath9k_platform_data *pdata = sc->dev->platform_data;
> ++struct platform_device *pdev;
> ++struct gpio_keys_platform_data gkpdata;
> ++struct gpio_keys_button *bt;
> ++int i;
> ++
> ++if (!sc->gpiochip)
> ++return;
> ++
> ++bt = kmemdup(pdata->btns,
> ++ pdata->num_btns * sizeof(struct gpio_keys_button),
> ++ GFP_KERNEL);
> ++if (!bt)
> ++return;
> ++
> ++pdev = platform_device_alloc("gpio-keys-polled", PLATFORM_DEVID_AUTO);
> ++if (!pdev)
> ++goto err_bt_free;
> ++
> ++for (i = 0; i < pdata->num_btns; i++) {
> ++ath9k_hw_cfg_gpio_input(sc->sc_ah, pdata->btns[i].gpio);
> ++bt[i].gpio = sc->gpiochip->gchip.base + pdata->btns[i].gpio;
> ++}
> ++
> ++memset(, 0, sizeof(struct gpio_keys_platform_data));
> ++gkpdata.buttons = bt;
>

Re: [OpenWrt-Devel] [PATCH v4 7/8] ar71xx: WNR2000v3: fix for random WLAN MAC

[Hartmut Knaack]

Michal schrieb am 01.02.2016 um 23:01:
> From: Michal Cieslakiewicz <michal.cieslakiew...@wp.pl>
> Subject: [PATCH v4 7/8] ar71xx: WNR2000v3: fix for random WLAN MAC
> 
> Fix for invalid/random WLAN MAC address in WNR2000v3. Permanent platform MAC
> is calculated and assigned during system startup. WLAN MAC follows wired
> Ethernet interface addresses.
> 
> Signed-off-by: Michal Cieslakiewicz <michal.cieslakiew...@wp.pl>
Acked-by: Hartmut Knaack <knaac...@gmx.de>
> ---
>  .../ar71xx/files/arch/mips/ath79/mach-wnr2000-v3.c | 31 
> +-
>  1 file changed, 25 insertions(+), 6 deletions(-)
> 
> diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-wnr2000-v3.c 
> b/target/linux/ar71xx/files/arch/mips/ath79/mach-wnr2000-v3.c
> index 205c2e7..4a31ff7 100644
> --- a/target/linux/ar71xx/files/arch/mips/ath79/mach-wnr2000-v3.c
> +++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-wnr2000-v3.c
> @@ -14,6 +14,7 @@
>  
>  #include 
>  #include 
> +#include  /* for max() macro */
>  
>  #include 
>  #include  /* needed to disable switch LEDs */
> @@ -181,7 +182,7 @@ static struct gpio_keys_button wnr2000v3_gpio_keys[] 
> __initdata = {
>   }
>  };
>  
> -static void __init wnr_common_setup(void)
> +static void __init wnr_common_setup(u8 *wmac_addr)
>  {
>   u8 *art = (u8 *) KSEG1ADDR(0x1fff);
>  
> @@ -200,12 +201,30 @@ static void __init wnr_common_setup(void)
>   ath79_register_eth(1);
>  
>   ath79_register_m25p80(NULL);
> - ap91_pci_init(art + WNR2000V3_PCIE_CALDATA_OFFSET, NULL);
> + ap91_pci_init(art + WNR2000V3_PCIE_CALDATA_OFFSET, wmac_addr);
>  }
>  
>  static void __init wnr2000v3_setup(void)
>  {
> - wnr_common_setup();
> + u8 *art = (u8 *) KSEG1ADDR(0x1fff);
> + u8 wlan_mac_addr[6];
> + u8 *eth0_mac_addr = (u8 *) (art + WNR2000V3_MAC0_OFFSET);
> + u8 *eth1_mac_addr = (u8 *) (art + WNR2000V3_MAC1_OFFSET);
> +
> + /*
> +  * For WNR2000v3 ART flash area used for WLAN MAC is empty (0xff)
> +  * so ath9k driver uses random MAC instead each time module is loaded.
> +  * To fix that, assign permanent WLAN MAC equal to ethN's MAC plus 1,
> +  * so network interfaces get sequential addresses.
> +  */
> + memcpy(wlan_mac_addr, eth0_mac_addr, sizeof(wlan_mac_addr));
> + wlan_mac_addr[5] = max(eth0_mac_addr[5], eth1_mac_addr[5]) + 1;
> +
> + /* Avoid potential conflict in case: max(0xff, 0x00) + 1 == 0x00 */
> + if (!wlan_mac_addr[5])
> + wlan_mac_addr[5] = 1;
> +
> + wnr_common_setup(wlan_mac_addr);
>  
>   ath79_register_leds_gpio(-1, ARRAY_SIZE(wnr2000v3_leds_gpio),
>wnr2000v3_leds_gpio);
> @@ -219,7 +238,7 @@ MIPS_MACHINE(ATH79_MACH_WNR2000_V3, "WNR2000V3", "NETGEAR 
> WNR2000 V3", wnr2000v3
>  
>  static void __init wnr612v2_setup(void)
>  {
> - wnr_common_setup();
> + wnr_common_setup(NULL);
>  
>   ath79_register_leds_gpio(-1, ARRAY_SIZE(wnr612v2_leds_gpio),
>wnr612v2_leds_gpio);
> @@ -229,7 +248,7 @@ MIPS_MACHINE(ATH79_MACH_WNR612_V2, "WNR612V2", "NETGEAR 
> WNR612 V2", wnr612v2_set
>  
>  static void __init wnr1000v2_setup(void)
>  {
> - wnr_common_setup();
> + wnr_common_setup(NULL);
>  
>   ath79_register_leds_gpio(-1, ARRAY_SIZE(wnr1000v2_leds_gpio),
>wnr1000v2_leds_gpio);
> @@ -247,7 +266,7 @@ static void __init wpn824n_setup(void)
> AR724X_GPIO_FUNC_ETH_SWITCH_LED4_EN |
> AR724X_GPIO_FUNC_CLK_OBS3_EN);
>  
> - wnr_common_setup();
> + wnr_common_setup(NULL);
>  
>   ath79_register_leds_gpio(-1, ARRAY_SIZE(wpn824n_leds_gpio),
>wpn824n_leds_gpio);
> 
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v4 2/8] mac80211: ath9k: set default state for platform LEDs

[Hartmut Knaack]

Michal schrieb am 01.02.2016 um 22:24:
> From: Michal Cieslakiewicz <michal.cieslakiew...@wp.pl>
> Subject: [PATCH v4 2/8] mac80211: ath9k: set default state for platform LEDs
> 
> Support default state for platform LEDs connected to ath9k device.
> Now LEDs are correctly set on or off at ath9k module initialization.
> 
> Signed-off-by: Michal Cieslakiewicz <michal.cieslakiew...@wp.pl>
Acked-by: Hartmut Knaack <knaac...@gmx.de>
> ---
>  .../patches/547-ath9k_led_defstate_fix.patch   | 29 
> ++
>  1 file changed, 29 insertions(+)
>  create mode 100644 
> package/kernel/mac80211/patches/547-ath9k_led_defstate_fix.patch
> 
> diff --git a/package/kernel/mac80211/patches/547-ath9k_led_defstate_fix.patch 
> b/package/kernel/mac80211/patches/547-ath9k_led_defstate_fix.patch
> new file mode 100644
> index 000..db0b619
> --- /dev/null
> +++ b/package/kernel/mac80211/patches/547-ath9k_led_defstate_fix.patch
> @@ -0,0 +1,29 @@
> +From: Michal Cieslakiewicz <michal.cieslakiew...@wp.pl>
> +Date: Sun, 31 Jan 2016 20:48:49 +0100
> +Subject: [PATCH v4 2/8] mac80211: ath9k: set default state for platform LEDs
> +
> +Support default state for platform LEDs connected to ath9k device.
> +Now LEDs are correctly set on or off at ath9k module initialization.
> +Very useful if power LED is connected to wireless chip.
> +
> +Signed-off-by: Michal Cieslakiewicz <michal.cieslakiew...@wp.pl>
> +---
> + gpio.c |7 +--
> + 1 file changed, 5 insertions(+), 2 deletions(-)
> +
> +--- a/drivers/net/wireless/ath/ath9k/gpio.c
>  b/drivers/net/wireless/ath/ath9k/gpio.c
> +@@ -54,8 +54,11 @@ static int ath_add_led(struct ath_softc
> + ath9k_hw_cfg_output(sc->sc_ah, gpio->gpio,
> + AR_GPIO_OUTPUT_MUX_AS_OUTPUT);
> + 
> +-/* LED off */
> +-ath9k_hw_set_gpio(sc->sc_ah, gpio->gpio, gpio->active_low);
> ++/* Set default LED state */
> ++if (gpio->default_state == LEDS_GPIO_DEFSTATE_ON)
> ++ath9k_hw_set_gpio(sc->sc_ah, gpio->gpio, !gpio->active_low);
> ++else
> ++ath9k_hw_set_gpio(sc->sc_ah, gpio->gpio, gpio->active_low);
> + 
> + return 0;
> + }
> 
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 1/8] ath9k: enable platform WLAN LED name

[Hartmut Knaack]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Michal schrieb am 31.01.2016 um 22:53:
> On Sat, 30 Jan 2016 19:05:37 +0100
> Hartmut Knaack <knaac...@gmx.de> wrote:
> 
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>>
>> Michal schrieb am 27.01.2016 um 01:33:
>>> From: Michal Cieslakiewicz <michal.cieslakiew...@wp.pl>
>>>
>>> Enable platform-supplied WLAN LED name for ath9k device.
>>>
>>> Signed-off-by: Michal Cieslakiewicz <michal.cieslakiew...@wp.pl>  
>> Acked-by: Hartmut Knaack <knaac...@gmx.de>
>>> ---  
>>
>> Looking good overall. I also used this patch series to build
>> images for the WPN824N to test button support, connected via
>> the AR9285 GPIOs - no complains.
>> One very minor detail about the patch subject: it would be
>> good to prefix even with mac80211: ath9k: enable platform...
>> It is also good practice to add a description and your
>> Signed-off-by to the package patches. Many people don't seem
>> to have done this, as well, but it makes life easier for the
>> one who will eventually send these patches upstream.
>>
> 
> Hello Hartmut,
> 
> Formal question: does "description and signing package patches" means
> including filled cover letter (from git-format-patch) as sort of
> preamble to all 8 patches or should I modify heading comments in
> patched files themselves ?
> 

Hi Michal,
I would say, just add a Subject line, a short description and most
important your Signed-off-by line to the patches created with quilt.
See for example some of the patches in target/linux/ar71xx/patches-4.1.
The 8 patches, created with git, are fine.
Thanks,

Hartmut

> Regards
> Michal
> 

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWrpNiAAoJEANoShj6yJFIckEP/1zJN1E3xL8og+fOAP6oQaC+
/XuXYutyC+SKQy55onEFZKX1TY0CNZWS+3+kRwkcMIZpxW602MM02X4iRYJ+mq3x
fn0L+zOgVudJeJYuIQtDH5QGyk5jRZGTyoeyNriwH+1tdPhxGkI7SbImQPBHYGI7
htYev4qqTnnJ4LEnUjfywKdanKOLEAijbivmpQqp7dsUu3HaviftqU6EcDhQt8fr
pDOnDBZgmIwd7avVpXeYf5r6f7tTFpF+YyBceig68EYGYdzBVLPfsbMIomHZnApZ
B7SbqdvjP2wt+NRNyc1KgdFNG1j/9pmhuythxNYb7wv2nRqvDsrs2kS1S/j0U8/0
nJWGGzDUimPCUzzgea+Q+4+kieTE57USVMQHcf+VKsp91AF/EuWeBNv8TJ0Iz+o/
+MsUaF5qarfVwu5E+PXUy8dliAzFu2b3uIYaLIDiserIbVs5pW8nPIBXV/Gyidx5
2tLhRvpt4YonhVVKDNFYQeR4USRujX+eqeH5JjnNEIzXS3GUuC7Qy2/zxVxUwn9x
2w8moysbouyeeFIHnF7eLBtnIF4iftnWMFcFV69ehnxNTS6htXiEapuNrwxUxinv
gTySCbUgs+QNfOZedIHQszE2PWKnBKvtAsKifHsi8Jg7wDB+lgswHgh9ivrijFSh
f/cj3y24ysou3GlHtRfz
=NA0k
-END PGP SIGNATURE-


0xFAC89148.asc
Description: application/pgp-keys
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 3/8] ath9k: show platform MAC address in kernel log if set

[Hartmut Knaack]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Michal schrieb am 27.01.2016 um 01:36:
> From: Michal Cieslakiewicz <michal.cieslakiew...@wp.pl>
> 
> Add information in kernel log during module startup if MAC address
> of WLAN device is overridden by platform-supplied one.
> 
> Signed-off-by: Michal Cieslakiewicz <michal.cieslakiew...@wp.pl>
Acked-by: Hartmut Knaack <knaac...@gmx.de>
> ---
>  .../mac80211/patches/548-ath9k_platform_mac_info.patch   | 16 
> 
>  1 file changed, 16 insertions(+)
>  create mode 100644 
> package/kernel/mac80211/patches/548-ath9k_platform_mac_info.patch
> 
> diff --git 
> a/package/kernel/mac80211/patches/548-ath9k_platform_mac_info.patch 
> b/package/kernel/mac80211/patches/548-ath9k_platform_mac_info.patch
> new file mode 100644
> index 000..76115e1
> --- /dev/null
> +++ b/package/kernel/mac80211/patches/548-ath9k_platform_mac_info.patch
> @@ -0,0 +1,16 @@
> +--- a/drivers/net/wireless/ath/ath9k/init.c
>  b/drivers/net/wireless/ath/ath9k/init.c
> +@@ -640,8 +640,12 @@ static int ath9k_init_softc(u16 devid, s
> + if (ret)
> + goto err_hw;
> + 
> +-if (pdata && pdata->macaddr)
> ++if (pdata && pdata->macaddr) {
> + memcpy(common->macaddr, pdata->macaddr, ETH_ALEN);
> ++ath_info(common,
> ++ "platform MAC address will be used: %pM\n",
> ++ common->macaddr);
> ++}
> + 
> + ret = ath9k_init_queues(sc);
> + if (ret)
> 

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWrPvUAAoJEANoShj6yJFINx4QAJDwxgt9uc+k0d/zeaUXBcn4
EGA9dMvLjSlrAUx9zMwjTtkZDco24qBIub28RUPhuAdO4qecJHjuFJNIoaqlE+GJ
RrvAh/tsRi9LJ7WZnDzg5S9XvV+9tfgJxac3ib3ZJKD+5DsX+pVj+WX3JqEC7XaG
NLW3QqST00eVNIv7xk/3WbB6erd9ju1abFi0KrUgLOhUhfO3NuWYC/05hJTC2dQ1
7SVTCjoVjU3m+G+qEqJXC0qtdomqj/u4gdJpLLjtsk0wsDMNGEANGf6KctSJhupu
bEA3hU/xtUEXpGAT+rkL76afGkfSfAF7myKhOJeCiD0/qQhQQGOhd7OSxqMUni1x
Rc0DM9L5RA4LwPGx5H4hXGaT+7zCFEtAOV9uOfbAIRuzz4wBOROvWKwQKSUxr87H
jb1dslCJqA0tSIK4WEcQn3AoW5WpUKjAfGkhGngn7R87Fs5Llzch+BuTGJGrJ4in
aSBUztddz4+aA4dnMQXSTRsKNr1FSZF6K/ol8FIADW/3utk/7YFCpIDPj9A2acRa
ht4etrIQ09k6xO1Z2LWHue4D0Uu1TyoRKnn7j+EKxhsl+EjxeOi7q3cMhGQO78NW
/LTOsOcTx4xE2wUfbbemT1+ffhSm5pQdZTlpAzXDgj4bkhDB6pcFPoRIPRv+B0UV
j1QBvJOvhYXQJyQjrhpU
=9beH
-END PGP SIGNATURE-


0xFAC89148.asc
Description: application/pgp-keys
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 2/8] ath9k: set default state for platform LEDs

[Hartmut Knaack]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Michal schrieb am 27.01.2016 um 01:34:
> From: Michal Cieslakiewicz <michal.cieslakiew...@wp.pl>
> 
> Support default state for platform LEDs connected to ath9k device.
> Now LEDs are correctly set on or off at ath9k module initialization.
> 
> Signed-off-by: Michal Cieslakiewicz <michal.cieslakiew...@wp.pl>
Acked-by: Hartmut Knaack <knaac...@gmx.de>
> ---
>  .../mac80211/patches/547-ath9k_led_defstate_fix.patch| 16 
> 
>  1 file changed, 16 insertions(+)
>  create mode 100644 
> package/kernel/mac80211/patches/547-ath9k_led_defstate_fix.patch
> 
> diff --git a/package/kernel/mac80211/patches/547-ath9k_led_defstate_fix.patch 
> b/package/kernel/mac80211/patches/547-ath9k_led_defstate_fix.patch
> new file mode 100644
> index 000..3ecffb8
> --- /dev/null
> +++ b/package/kernel/mac80211/patches/547-ath9k_led_defstate_fix.patch
> @@ -0,0 +1,16 @@
> +--- a/drivers/net/wireless/ath/ath9k/gpio.c
>  b/drivers/net/wireless/ath/ath9k/gpio.c
> +@@ -54,8 +54,11 @@ static int ath_add_led(struct ath_softc
> + ath9k_hw_cfg_output(sc->sc_ah, gpio->gpio,
> + AR_GPIO_OUTPUT_MUX_AS_OUTPUT);
> + 
> +-/* LED off */
> +-ath9k_hw_set_gpio(sc->sc_ah, gpio->gpio, gpio->active_low);
> ++/* Set default LED state */
> ++if (gpio->default_state == LEDS_GPIO_DEFSTATE_ON)
> ++ath9k_hw_set_gpio(sc->sc_ah, gpio->gpio, !gpio->active_low);
> ++else
> ++ath9k_hw_set_gpio(sc->sc_ah, gpio->gpio, gpio->active_low);
> + 
> + return 0;
> + }
> 

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWrPuiAAoJEANoShj6yJFIK2gP/iAEP0nwLoWCUOde/vtM6x5M
ezrunVtDDu2ikHghVhjpKrbJdFYGcmrfqa/loXHJDdqAw2to2nQwOT5JB/+hMHQ2
EyNDNMYWN4r7/VJdxeaqOJV63VgPS6uHzw+owxQATHn1TQGhyQfOLjICUzfi5zkg
WVD8oBBzCBib2zaSuxfTFcW2TPb8cmXD31MvgQm/1/0wlKVyrgYXqk15T+QU4Qcr
qfGpCmGuJwI7F1TTLStvuKYp78+Qyxc1NV0mSDYK5rmfavIEYjCsT3ld90wb5mSn
CH6c9LrCgZzugwapzSWHgRaOE7O4Z9dra91XVlEF7DRq/10pYSqt4gXXbOHphkpj
0j7vI68TPsBnD3ACKtSnfnUVC8TQc+xuhNJzDTtv+zWdRVa0hzv39K3BXRPLiBHP
J9At3UodhjSZV1+3hbNe5wRdiKgAa2MhOQlbjhGbr+XIsQj7XwWS+uIq5afGrKrx
/ULeja+iwbuIU0C+rfZHipUTPE0x9RZgUC/qRpIN4AX2dr5W5jm2zXQA6eQfCF3C
qraih8L8b5KRwzfkbKE6uPql8wZ0Py0NEGs7GWn4SyutZf4/tl3htaWWGUGcb/ZO
zIiKLLeJamQregDkOvBehxPPVuNNvtjUYoqPs1d3/FTcUCJuvAKhVW7a+GQ8gnhp
hJvr04kUBwk0zFa9E1XB
=5S+V
-END PGP SIGNATURE-


0xFAC89148.asc
Description: application/pgp-keys
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 1/8] ath9k: enable platform WLAN LED name

[Hartmut Knaack]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Michal schrieb am 27.01.2016 um 01:33:
> From: Michal Cieslakiewicz <michal.cieslakiew...@wp.pl>
> 
> Enable platform-supplied WLAN LED name for ath9k device.
> 
> Signed-off-by: Michal Cieslakiewicz <michal.cieslakiew...@wp.pl>
Acked-by: Hartmut Knaack <knaac...@gmx.de>
> ---

Looking good overall. I also used this patch series to build
images for the WPN824N to test button support, connected via
the AR9285 GPIOs - no complains.
One very minor detail about the patch subject: it would be
good to prefix even with mac80211: ath9k: enable platform...
It is also good practice to add a description and your
Signed-off-by to the package patches. Many people don't seem
to have done this, as well, but it makes life easier for the
one who will eventually send these patches upstream.

>  .../patches/546-ath9k_platform_led_name.patch  | 35 
> ++
>  .../ar71xx/files/arch/mips/ath79/dev-ap9x-pci.c| 12 
>  .../ar71xx/files/arch/mips/ath79/dev-ap9x-pci.h|  3 ++
>  .../generic/files/include/linux/ath9k_platform.h   |  1 +
>  4 files changed, 51 insertions(+)
>  create mode 100644 
> package/kernel/mac80211/patches/546-ath9k_platform_led_name.patch
> 
> diff --git 
> a/package/kernel/mac80211/patches/546-ath9k_platform_led_name.patch 
> b/package/kernel/mac80211/patches/546-ath9k_platform_led_name.patch
> new file mode 100644
> index 000..04e312d
> --- /dev/null
> +++ b/package/kernel/mac80211/patches/546-ath9k_platform_led_name.patch
> @@ -0,0 +1,35 @@
> +--- a/drivers/net/wireless/ath/ath9k/gpio.c
>  b/drivers/net/wireless/ath/ath9k/gpio.c
> +@@ -132,15 +132,19 @@ void ath_init_leds(struct ath_softc *sc)
> + if (AR_SREV_9100(sc->sc_ah))
> + return;
> + 
> +-snprintf(led_name, sizeof(led_name), "ath9k-%s",
> +- wiphy_name(sc->hw->wiphy));
> ++if (pdata && pdata->led_name)
> ++strncpy(led_name, pdata->led_name, sizeof(led_name));
> ++else
> ++snprintf(led_name, sizeof(led_name), "ath9k-%s",
> ++ wiphy_name(sc->hw->wiphy));
> + 
> + if (ath9k_led_blink)
> + trigger = sc->led_default_trigger;
> + else
> + trigger = ieee80211_get_radio_led_name(sc->hw);
> + 
> +-ath_create_gpio_led(sc, sc->sc_ah->led_pin, led_name, trigger, 
> !sc->sc_ah->config.led_active_high);
> ++ath_create_gpio_led(sc, sc->sc_ah->led_pin, led_name, trigger,
> ++!sc->sc_ah->config.led_active_high);
> + 
> + if (!pdata)
> + return;
> +--- a/include/linux/ath9k_platform.h
>  b/include/linux/ath9k_platform.h
> +@@ -45,6 +45,7 @@ struct ath9k_platform_data {
> + 
> + int num_leds;
> + const struct gpio_led *leds;
> ++const char *led_name;
> + };
> + 
> + #endif /* _LINUX_ATH9K_PLATFORM_H */
> diff --git a/target/linux/ar71xx/files/arch/mips/ath79/dev-ap9x-pci.c 
> b/target/linux/ar71xx/files/arch/mips/ath79/dev-ap9x-pci.c
> index d382453..bf80d4d 100644
> --- a/target/linux/ar71xx/files/arch/mips/ath79/dev-ap9x-pci.c
> +++ b/target/linux/ar71xx/files/arch/mips/ath79/dev-ap9x-pci.c
> @@ -39,6 +39,18 @@ __init void ap9x_pci_setup_wmac_led_pin(unsigned wmac, int 
> pin)
>   }
>  }
>  
> +__init void ap9x_pci_setup_wmac_led_name(unsigned wmac, const char *led_name)
> +{
> + switch (wmac) {
> + case 0:
> + ap9x_wmac0_data.led_name = led_name;
> + break;
> + case 1:
> + ap9x_wmac1_data.led_name = led_name;
> + break;
> + }
> +}
> +
>  __init struct ath9k_platform_data *ap9x_pci_get_wmac_data(unsigned wmac)
>  {
>   switch (wmac) {
> diff --git a/target/linux/ar71xx/files/arch/mips/ath79/dev-ap9x-pci.h 
> b/target/linux/ar71xx/files/arch/mips/ath79/dev-ap9x-pci.h
> index ad288cb..dcfe541 100644
> --- a/target/linux/ar71xx/files/arch/mips/ath79/dev-ap9x-pci.h
> +++ b/target/linux/ar71xx/files/arch/mips/ath79/dev-ap9x-pci.h
> @@ -19,6 +19,7 @@ void ap9x_pci_setup_wmac_led_pin(unsigned wmac, int pin);
>  void ap9x_pci_setup_wmac_gpio(unsigned wmac, u32 mask, u32 val);
>  void ap9x_pci_setup_wmac_leds(unsigned wmac, struct gpio_led *leds,
> int num_leds);
> +void ap9x_pci_setup_wmac_led_name(unsigned wmac, const char *led_name);
>  struct ath9k_platform_data *ap9x_pci_get_wmac_data(unsigned wmac);
>  
>  void ap91_pci_init(u8 *cal_data, u8 *mac_addr);
> @@ -33,6 +34,8 @@ static inline void ap9x_pci_setup_wmac_gpio(unsigned wmac,
>  static inline void ap9x_pci_setup_wmac_leds(unsigned wmac,
>

Re: [OpenWrt-Devel] [PATCHv2 4/8] ath9k: enable access to GPIO

[Hartmut Knaack]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Michal schrieb am 27.01.2016 um 20:29:
> From: Michal Cieslakiewicz <michal.cieslakiew...@wp.pl>
> 
> Enable access to GPIO chip and its pins for Atheros AR92xx
> wireless devices. For now AR9285 and AR9287 are supported.
> 
> Signed-off-by: Michal Cieslakiewicz <michal.cieslakiew...@wp.pl>
Acked-by: Hartmut Knaack <knaac...@gmx.de>
> ---
> 
> (Removed unneeded pdata pointer check in ath9k_register_gpio_chip() function)
> 

I've put some suggestions about where to have empty lines and where not inline.

>  .../patches/549-ath9k_enable_gpio_chip.patch   | 229 
> +
>  1 file changed, 229 insertions(+)
>  create mode 100644 
> package/kernel/mac80211/patches/549-ath9k_enable_gpio_chip.patch
> 
> diff --git a/package/kernel/mac80211/patches/549-ath9k_enable_gpio_chip.patch 
> b/package/kernel/mac80211/patches/549-ath9k_enable_gpio_chip.patch
> new file mode 100644
> index 000..d49c80f
> --- /dev/null
> +++ b/package/kernel/mac80211/patches/549-ath9k_enable_gpio_chip.patch
> @@ -0,0 +1,229 @@
> +--- a/drivers/net/wireless/ath/ath9k/ath9k.h
>  b/drivers/net/wireless/ath/ath9k/ath9k.h
> +@@ -24,6 +24,7 @@
> + #include 
> + #include 
> + #include 
> ++#include 
> + 
> + #include "common.h"
> + #include "debug.h"
> +@@ -817,6 +818,13 @@ void ath_fill_led_pin(struct ath_softc *
> + int ath_create_gpio_led(struct ath_softc *sc, int gpio, const char *name,
> + const char *trigger, bool active_low);
> + 
> ++/***/
> ++/*  GPIO Chip  */
> ++/***/
> ++
> ++void ath9k_register_gpio_chip(struct ath_softc *sc);
> ++void ath9k_unregister_gpio_chip(struct ath_softc *sc);
> ++
> + #else
> + static inline void ath_init_leds(struct ath_softc *sc)
> + {
> +@@ -828,6 +836,13 @@ static inline void ath_deinit_leds(struc
> + static inline void ath_fill_led_pin(struct ath_softc *sc)
> + {
> + }
> ++
> ++static inline void ath9k_register_gpio_chip(struct ath_softc *sc)
> ++{
> ++}

I would leave an empty line here.

> ++static inline void ath9k_unregister_gpio_chip(struct ath_softc *sc)
> ++{
> ++}
> + #endif
> + 
> + //
> +@@ -963,6 +978,12 @@ struct ath_led {
> + struct led_classdev cdev;
> + };
> + 
> ++struct ath9k_gpio_chip {
> ++struct ath_softc *sc;
> ++char label[32];
> ++struct gpio_chip gchip;
> ++};
> ++
> + struct ath_softc {
> + struct ieee80211_hw *hw;
> + struct device *dev;
> +@@ -1017,6 +1038,7 @@ struct ath_softc {
> + #ifdef CPTCFG_MAC80211_LEDS
> + const char *led_default_trigger;
> + struct list_head leds;
> ++struct ath9k_gpio_chip *gpiochip;
> + #endif
> + 
> + #ifdef CPTCFG_ATH9K_DEBUGFS
> +--- a/drivers/net/wireless/ath/ath9k/gpio.c
>  b/drivers/net/wireless/ath/ath9k/gpio.c
> +@@ -22,6 +22,9 @@
> + //
> + 
> + #ifdef CPTCFG_MAC80211_LEDS
> ++
> ++#include 
> ++
> + static void ath_led_brightness(struct led_classdev *led_cdev,
> +enum led_brightness brightness)
> + {
> +@@ -60,6 +63,10 @@ static int ath_add_led(struct ath_softc
> + else
> + ath9k_hw_set_gpio(sc->sc_ah, gpio->gpio, gpio->active_low);
> + 
> ++/* If there is GPIO chip configured, reserve LED pin */
> ++if (sc->gpiochip)
> ++gpio_request(sc->gpiochip->gchip.base + gpio->gpio, gpio->name);
> ++
> + return 0;
> + }
> + 
> +@@ -116,6 +123,9 @@ void ath_deinit_leds(struct ath_softc *s
> + 
> + while (!list_empty(>leds)) {
> + led = list_first_entry(>leds, struct ath_led, list);
> ++/* If there is GPIO chip configured, free LED pin */
> ++if (sc->gpiochip)
> ++gpio_free(sc->gpiochip->gchip.base + led->gpio->gpio);
> + list_del(>list);
> + ath_led_brightness(>cdev, LED_OFF);
> + led_classdev_unregister(>cdev);
> +@@ -186,6 +196,118 @@ void ath_fill_led_pin(struct ath_softc *
> + /* LED off, active low */
> + ath9k_hw_set_gpio(ah, ah->led_pin, (ah->config.led_active_high) ? 0 : 
> 1);
> + }
> ++
> ++/***/
> ++/*  GPIO Chip  */
> ++/***/
> ++
> ++/* gpio_chip handler : set GPIO to input */
> ++static int ath9k_gpio_pin_cfg_input(struct gpio_chip *chip, unsigned offset)
> ++{
> ++struct ath9k_gpio_chip *gc = container_of(chip, struct ath9k_gpio_chip,
> ++  gchip);
> ++
> ++ath9k_hw_cfg_gpio_input(gc

Re: [OpenWrt-Devel] [PATCH 6/8] package: exclude USB modules from WNR2000v3 image

[Hartmut Knaack]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Michal schrieb am 27.01.2016 um 01:40:
> From: Michal Cieslakiewicz <michal.cieslakiew...@wp.pl>
> 
> Netgear WNR2000v3 has no USB port yet default system image
> includes USB kernel modules. This patch fixes that.
> 
> Signed-off-by: Michal Cieslakiewicz <michal.cieslakiew...@wp.pl>
Acked-by: Hartmut Knaack <knaac...@gmx.de>
> ---

Better subject of this patch would be ar71xx: WNR2000v3: exclude USB modules 
form image.

>  target/linux/ar71xx/generic/profiles/netgear.mk | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/target/linux/ar71xx/generic/profiles/netgear.mk 
> b/target/linux/ar71xx/generic/profiles/netgear.mk
> index ca22a18..0b05adf 100644
> --- a/target/linux/ar71xx/generic/profiles/netgear.mk
> +++ b/target/linux/ar71xx/generic/profiles/netgear.mk
> @@ -30,6 +30,7 @@ $(eval $(call Profile,WNDR3700))
>  
>  define Profile/WNR2000V3
>   NAME:=NETGEAR WNR2000V3
> + PACKAGES:=
>  endef
>  
>  define Profile/WNR2000V3/Description
> 

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWrQGNAAoJEANoShj6yJFIhacP/21YH27mixs3INbjYTISQys+
Sxp/l9uIWzEaVDfvMmGoirmwzt7DUuUGEDhQziWCT+Q1/ce/moL+Yu8lkz2zRwuR
1XmikhNnwP11B0Xbw3KJNNitjUe/SYtqkmhrmrIO2B+eANk05fK4zZYQigVFHxFK
X/vGjnG0ivZY+ofDEhlFn36mfTQi1LRxOlCderMSLRdrclNX/3n7Q7eMOxWQKG2m
XQ9LPQ7IM67QiWQIk9iHY/FH37HrLf+iim1/kjdHv0zVz6LK5p80ch/b+EWmNR3c
bjwGeJQTLdmu6kXgebWuUlygwFJIp/bDU0qGeJAondgzefz8ugi60v87rpPXtIyj
R3/mb9kn11D8tD5hpBJJMIYM/thZrxgw1TPmN/pQ2pSGx/mv1+wwcNUDpw5xh3Jb
wyN6Wp+zO38i+PfBPS+5X8FfJA12G04IvtJfAOIYWMNo3VMw09KHm26aPYrK1NeO
K/iSs47x0YI07ug8qiATTzr545Opk9M35Fwhxv3Px28hk8P6Jh+VglyDlIgJf5i5
YPa7YXDZvb1bm+QOH0m4gPhgt6LdAbPCDnbjVC0LMnqpQJ8XiceVmGk09HPsWWfi
1TLzXutNaf3rd3WzfO+f9kVTX0t5KwcFowdvRRvZ28C+BJrOxipJx+TO4JgFu15H
lx95qx0NVw6hGK4P3W1a
=We1d
-END PGP SIGNATURE-


0xFAC89148.asc
Description: application/pgp-keys
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 8/8] ath79: all LEDs and buttons for Netgear WNR2000v3

[Hartmut Knaack]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Michal schrieb am 27.01.2016 um 01:44:
> From: Michal Cieslakiewicz <michal.cieslakiew...@wp.pl>
> 
> This patch provides full GPIO support for WNR2000v3 (LEDs and buttons).
> It exposes all LEDs to operating system, including Ethernet ones.
> 
> Signed-off-by: Michal Cieslakiewicz <michal.cieslakiew...@wp.pl>
Acked-by: Hartmut Knaack <knaac...@gmx.de>
> ---

The patch subject should also be prefixed with ar71xx:WNR2000v3: ...
I would recommend to additionally use the following parameters with
git format-patch: --cover-letter -v4

>  target/linux/ar71xx/base-files/etc/board.d/01_leds |  14 +++
>  target/linux/ar71xx/base-files/etc/diag.sh |   1 +
>  .../ar71xx/files/arch/mips/ath79/mach-wnr2000-v3.c | 137 
> +++--
>  3 files changed, 142 insertions(+), 10 deletions(-)
> 
> diff --git a/target/linux/ar71xx/base-files/etc/board.d/01_leds 
> b/target/linux/ar71xx/base-files/etc/board.d/01_leds
> index 151eac2..7374422 100755
> --- a/target/linux/ar71xx/base-files/etc/board.d/01_leds
> +++ b/target/linux/ar71xx/base-files/etc/board.d/01_leds
> @@ -676,6 +676,20 @@ wlae-ag300n)
>   ucidef_set_led_netdev "wireless" "WIRELESS" "buffalo:green:wireless" 
> "wlan0"
>   ;;
>  
> +wnr2000-v3)
> + ucidef_set_led_netdev "wan-amber" "WAN (amber)" "netgear:amber:wan" 
> "eth0"
> + ucidef_set_led_default "wan-green" "WAN (green)" "netgear:green:wan" "0"
> + ucidef_set_led_netdev "wlan" "WLAN" "netgear:blue:wlan" "wlan0"
> + ucidef_set_led_switch "lan1green" "LAN1 (green)" "netgear:green:lan1" 
> "switch0" "0x02"
> + ucidef_set_led_switch "lan2green" "LAN2 (green)" "netgear:green:lan2" 
> "switch0" "0x04"
> + ucidef_set_led_switch "lan3green" "LAN3 (green)" "netgear:green:lan3" 
> "switch0" "0x08"
> + ucidef_set_led_switch "lan4green" "LAN4 (green)" "netgear:green:lan4" 
> "switch0" "0x10"
> + ucidef_set_led_default "lan1amber" "LAN1 (amber)" "netgear:amber:lan1" 
> "0"
> + ucidef_set_led_default "lan2amber" "LAN2 (amber)" "netgear:amber:lan2" 
> "0"
> + ucidef_set_led_default "lan3amber" "LAN3 (amber)" "netgear:amber:lan3" 
> "0"
> + ucidef_set_led_default "lan4amber" "LAN4 (amber)" "netgear:amber:lan4" 
> "0"
> + ;;
> +
>  wnr2000-v4)
>   ucidef_set_led_netdev "wan" "WAN" "netgear:green:wan" "eth0"
>   ucidef_set_led_netdev "wlan" "WLAN" "netgear:blue:wlan" "wlan0"
> diff --git a/target/linux/ar71xx/base-files/etc/diag.sh 
> b/target/linux/ar71xx/base-files/etc/diag.sh
> index c0e73ad..4ee40f7 100644
> --- a/target/linux/ar71xx/base-files/etc/diag.sh
> +++ b/target/linux/ar71xx/base-files/etc/diag.sh
> @@ -368,6 +368,7 @@ get_status_led() {
>   wndr3700v4 | \
>   wndr4300 | \
>   wnr2000 | \
> + wnr2000-v3 |\
>   wnr2200 |\
>   wnr612-v2 |\
>   wnr1000-v2 |\
> diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-wnr2000-v3.c 
> b/target/linux/ar71xx/files/arch/mips/ath79/mach-wnr2000-v3.c
> index ee6b449..b4ca9b1 100644
> --- a/target/linux/ar71xx/files/arch/mips/ath79/mach-wnr2000-v3.c
> +++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-wnr2000-v3.c
> @@ -14,6 +14,7 @@
>  
>  #include 
>  #include 
> +#include  /* PLATFORM_DEVID_AUTO is defined here */
>  
>  #include 
>  #include  /* needed to disable switch LEDs */
> @@ -26,11 +27,25 @@
>  #include "dev-m25p80.h"
>  #include "machtypes.h"
>  
> +/* ar7241 GPIOs */
>  #define WNR2000V3_GPIO_LED_WAN_GREEN 0
>  #define WNR2000V3_GPIO_LED_LAN1_AMBER1
> -#define WNR2000V3_GPIO_LED_LAN4_AMBER12
> -#define WNR2000V3_GPIO_LED_PWR_GREEN 14
> +#define WNR2000V3_GPIO_LED_LAN2_AMBER6
> +#define WNR2000V3_GPIO_LED_WPS_GREEN 7
> +#define WNR2000V3_GPIO_LED_LAN3_AMBER8
>  #define WNR2000V3_GPIO_BTN_WPS   11
> +#define WNR2000V3_GPIO_LED_LAN4_AMBER12
> +#define WNR2000V3_GPIO_LED_LAN1_GREEN13
> +#define WNR2000V3_GPIO_LED_LAN2_GREEN14
> +#define WNR2000V3_GPIO_LED_LAN3_GREEN15
> +#define WNR2000V3_GPIO_LED_LAN4_GREEN1

Re: [OpenWrt-Devel] [PATCH 7/8] ath79: fix for random WLAN MAC for WNR2000v3

[Hartmut Knaack]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Michal schrieb am 27.01.2016 um 01:41:
> From: Michal Cieslakiewicz <michal.cieslakiew...@wp.pl>
> 
> Fix for invalid/random WLAN MAC address in WNR2000v3. Permanent platform MAC
> is calculated and assigned during system startup. WLAN MAC follows wired
> Ethernet interface addresses.
> 
> Signed-off-by: Michal Cieslakiewicz <michal.cieslakiew...@wp.pl>
Acked-by: Hartmut Knaack <knaac...@gmx.de>
> ---

I've put some comments inline.
The subject should also be more like: ar71xx: WNR2000v3: fix for random WLAN 
MAC.

>  .../ar71xx/files/arch/mips/ath79/mach-wnr2000-v3.c | 30 
> +-
>  1 file changed, 24 insertions(+), 6 deletions(-)
> 
> diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-wnr2000-v3.c 
> b/target/linux/ar71xx/files/arch/mips/ath79/mach-wnr2000-v3.c
> index 205c2e7..ee6b449 100644
> --- a/target/linux/ar71xx/files/arch/mips/ath79/mach-wnr2000-v3.c
> +++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-wnr2000-v3.c
> @@ -181,7 +181,7 @@ static struct gpio_keys_button wnr2000v3_gpio_keys[] 
> __initdata = {
>   }
>  };
>  
> -static void __init wnr_common_setup(void)
> +static void __init wnr_common_setup(u8 *wmac_addr)
>  {
>   u8 *art = (u8 *) KSEG1ADDR(0x1fff);
>  
> @@ -200,12 +200,30 @@ static void __init wnr_common_setup(void)
>   ath79_register_eth(1);
>  
>   ath79_register_m25p80(NULL);
> - ap91_pci_init(art + WNR2000V3_PCIE_CALDATA_OFFSET, NULL);
> + ap91_pci_init(art + WNR2000V3_PCIE_CALDATA_OFFSET, wmac_addr);
>  }
>  
>  static void __init wnr2000v3_setup(void)
>  {
> - wnr_common_setup();
> + u8 *art = (u8 *) KSEG1ADDR(0x1fff);
> + u8 wlan_mac_addr[6];
> + u8 *eth0_mac_addr = (u8 *) (art + WNR2000V3_MAC0_OFFSET);
> + u8 *eth1_mac_addr = (u8 *) (art + WNR2000V3_MAC1_OFFSET);
> +
> + /*
> +  * For WNR2000v3 ART flash area used for wlan MAC is usually empty 
> (0xff)
> +  * so ath9k driver uses random MAC instead each time module is loaded.
> +  * To fix that, assign permanent wlan MAC equal to ethN's MAC plus 1,
> +  * so network interfaces get sequential addresses.
> +  */
> + memcpy(wlan_mac_addr, eth0_mac_addr, sizeof(wlan_mac_addr));
> + wlan_mac_addr[5] = (eth0_mac_addr[5] > eth1_mac_addr[5] ?
> +eth0_mac_addr[5] : eth1_mac_addr[5]) + 1;

This could benefit from the max macro
http://lxr.free-electrons.com/source/include/linux/kernel.h#L727

> +
> + /* Avoid potential conflict in case: max(0xff,0x00)+1==0x00 */
> + if (!wlan_mac_addr[5]) wlan_mac_addr[5] = 1;

Please put the second part in a new line.

> +
> + wnr_common_setup(wlan_mac_addr);
>  
>   ath79_register_leds_gpio(-1, ARRAY_SIZE(wnr2000v3_leds_gpio),
>wnr2000v3_leds_gpio);
> @@ -219,7 +237,7 @@ MIPS_MACHINE(ATH79_MACH_WNR2000_V3, "WNR2000V3", "NETGEAR 
> WNR2000 V3", wnr2000v3
>  
>  static void __init wnr612v2_setup(void)
>  {
> - wnr_common_setup();
> + wnr_common_setup(NULL);
>  
>   ath79_register_leds_gpio(-1, ARRAY_SIZE(wnr612v2_leds_gpio),
>wnr612v2_leds_gpio);
> @@ -229,7 +247,7 @@ MIPS_MACHINE(ATH79_MACH_WNR612_V2, "WNR612V2", "NETGEAR 
> WNR612 V2", wnr612v2_set
>  
>  static void __init wnr1000v2_setup(void)
>  {
> - wnr_common_setup();
> + wnr_common_setup(NULL);
>  
>   ath79_register_leds_gpio(-1, ARRAY_SIZE(wnr1000v2_leds_gpio),
>wnr1000v2_leds_gpio);
> @@ -247,7 +265,7 @@ static void __init wpn824n_setup(void)
> AR724X_GPIO_FUNC_ETH_SWITCH_LED4_EN |
> AR724X_GPIO_FUNC_CLK_OBS3_EN);
>  
> - wnr_common_setup();
> + wnr_common_setup(NULL);
>  
>   ath79_register_leds_gpio(-1, ARRAY_SIZE(wpn824n_leds_gpio),
>wpn824n_leds_gpio);
> 

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWrQNRAAoJEANoShj6yJFIZYkP+gKbiHX8jozsojxWzmhFyjiQ
v1Tzr64/QABNtAOnHbMgYaVNdqdDGKKdHAOZG9PYQmiBxKGXe4Rk3ESyRvljFgDJ
g9ntn/ZwL8thxSZmYz2IDw6+tD5N9qOIhzDwekhmT6v3Z50fI6yxbkpNeaad1iu+
+zEyrM9rR6P3bH9JAUGHEWqqRp47WDR9E/AaisRymNJm00os0/69+MXi7Ky4DGHo
uXBckLgsA7ynyrFwwoK8q932byPSl6F5aA5ATBARBEbNfn5mvzVXspzbDMOvydva
NvItIKd4qM295dkRGI+dFZRJTjbIAQBPomOzb7K8imSoa+Xwxz0tcHNMUJB3WnX6
YxgWg1Fy3TSmHQbfUUgvf1TgLqYZriz1bW21tO2s5rBPV++NAb6+5VzSaxI4LK6w
wPBHaPbhV8QlppYnET5OWYJsblVnYpoXYzjfcXizNtqMPdVxmsOKg4O8YFfgnYqj
10+Q8WbgBRaMbQHTqTbn7FKHTt5yDG8tSG2dGRu6wYTRc3iGlsjXtslFPs2ToFJD
xabvr7T8VSbW7yABVyg6xIawzUen8Gns9xXL25bVMsHKJsPL4Y07f4t69/XwzqaW
3XBGya0VPd34FPolXu8P3MxRaGS98MTgJjjG485KopZLlh7HyF3f9kIc6w+1YvCj
oI6VOu1YOGj4z09wWjYU
=ALoI
-END PGP SIGNATURE-


0xFAC89148.asc
Description: application/pgp-keys
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCHv3 5/8] ath9k: enable GPIO buttons

[Hartmut Knaack]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Michal schrieb am 28.01.2016 um 23:32:
> From: Michal Cieslakiewicz <michal.cieslakiew...@wp.pl>
> 
> Enable platform-defined GPIO button support for ath9k device. Key poller
> is activated for attached platform buttons. Requires ath9k GPIO chip access.
> 
> Signed-off-by: Michal Cieslakiewicz <michal.cieslakiew...@wp.pl>
Acked-by: Hartmut Knaack <knaac...@gmx.de>
> ---
> 

A few minor comments inline.

> (Minor code cleanup - dummy init/deinit functions changed to static inline)
> 
>  .../patches/550-ath9k_enable_gpio_buttons.patch| 164 
> +
>  .../ar71xx/files/arch/mips/ath79/dev-ap9x-pci.c|  18 +++
>  .../ar71xx/files/arch/mips/ath79/dev-ap9x-pci.h|   7 +
>  .../generic/files/include/linux/ath9k_platform.h   |   4 +
>  4 files changed, 193 insertions(+)
>  create mode 100644 
> package/kernel/mac80211/patches/550-ath9k_enable_gpio_buttons.patch
> 
> diff --git 
> a/package/kernel/mac80211/patches/550-ath9k_enable_gpio_buttons.patch 
> b/package/kernel/mac80211/patches/550-ath9k_enable_gpio_buttons.patch
> new file mode 100644
> index 000..01d0ade
> --- /dev/null
> +++ b/package/kernel/mac80211/patches/550-ath9k_enable_gpio_buttons.patch
> @@ -0,0 +1,164 @@
> +--- a/drivers/net/wireless/ath/ath9k/ath9k.h
>  b/drivers/net/wireless/ath/ath9k/ath9k.h
> +@@ -825,6 +825,13 @@ int ath_create_gpio_led(struct ath_softc
> + void ath9k_register_gpio_chip(struct ath_softc *sc);
> + void ath9k_unregister_gpio_chip(struct ath_softc *sc);
> + 
> ++/**/
> ++/*  GPIO Buttons  */
> ++/**/
> ++
> ++void ath9k_init_buttons(struct ath_softc *sc);
> ++void ath9k_deinit_buttons(struct ath_softc *sc);
> ++
> + #else
> + static inline void ath_init_leds(struct ath_softc *sc)
> + {
> +@@ -843,6 +850,13 @@ static inline void ath9k_register_gpio_c
> + static inline void ath9k_unregister_gpio_chip(struct ath_softc *sc)
> + {
> + }
> ++
> ++static inline void ath9k_init_buttons(struct ath_softc *sc)
> ++{
> ++}

I would leave an empty line here, too.

> ++static inline void ath9k_deinit_buttons(struct ath_softc *sc)
> ++{
> ++}
> + #endif
> + 
> + //
> +@@ -1039,6 +1053,7 @@ struct ath_softc {
> + const char *led_default_trigger;
> + struct list_head leds;
> + struct ath9k_gpio_chip *gpiochip;
> ++struct platform_device *btnpdev;/* gpio-keys-polled */
> + #endif
> + 
> + #ifdef CPTCFG_ATH9K_DEBUGFS
> +--- a/drivers/net/wireless/ath/ath9k/gpio.c
>  b/drivers/net/wireless/ath/ath9k/gpio.c
> +@@ -24,6 +24,8 @@
> + #ifdef CPTCFG_MAC80211_LEDS
> + 
> + #include 
> ++#include 
> ++#include 
> + 
> + static void ath_led_brightness(struct led_classdev *led_cdev,
> +enum led_brightness brightness)
> +@@ -308,6 +310,83 @@ void ath9k_unregister_gpio_chip(struct a
> + sc->gpiochip = NULL;
> + }
> + 
> ++/**/
> ++/*  GPIO Buttons  */
> ++/**/
> ++
> ++/* add GPIO buttons */
> ++void ath9k_init_buttons(struct ath_softc *sc)
> ++{
> ++struct ath9k_platform_data *pdata = sc->dev->platform_data;
> ++struct platform_device *pdev;
> ++struct gpio_keys_platform_data gkpdata;
> ++struct gpio_keys_button *bt;
> ++int i;
> ++
> ++if (!sc->gpiochip)
> ++return;
> ++
> ++bt = kmemdup(pdata->btns,
> ++ pdata->num_btns * sizeof(struct gpio_keys_button),
> ++ GFP_KERNEL);
> ++

I would drop this empty line.

> ++if (!bt)
> ++return;
> ++
> ++pdev = platform_device_alloc("gpio-keys-polled", PLATFORM_DEVID_AUTO);
> ++

And this one, too.

> ++if (!pdev)
> ++goto err_bt_free;
> ++
> ++for (i = 0; i < pdata->num_btns; i++) {
> ++ath9k_hw_cfg_gpio_input(sc->sc_ah, pdata->btns[i].gpio);
> ++bt[i].gpio = sc->gpiochip->gchip.base + pdata->btns[i].gpio;
> ++}
> ++
> ++memset(, 0, sizeof(struct gpio_keys_platform_data));
> ++gkpdata.buttons = bt;
> ++gkpdata.nbuttons = pdata->num_btns;
> ++gkpdata.poll_interval = pdata->btn_poll_interval;
> ++
> ++if (platform_device_add_data(pdev, , sizeof(gkpdata)))
> ++goto err_pdev_put;
> ++
> ++if (platform_device_add(pdev))
> ++goto err_pdev_put;
> ++
> ++sc->btnpdev = pdev;
> ++
> ++return;
> ++
> ++err_pdev_put:
> ++platform_device_put(pdev);
> ++
> ++err_bt_free:
> ++kfree(bt);
> ++}
> ++
> ++/* remove GPIO button

Re: [OpenWrt-Devel] [PATCH 1/6] [kernel] ath9k: enable GPIO access for ar9287 and ar9285

[Hartmut Knaack]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Michal Cieslakiewicz schrieb am 21.01.2016 um 00:11:
> From: Michal Cieslakiewicz 
> 
> Patch enables GPIO access for wireless chips ar9287 and ar9285.
> Key poller driver is activated when platform buttons are 
> defined. It also makes LEDs connected honour initial
> default_state and allows platform-supplied WLAN LED name.
> 
> Signed-off-by: Michal Cieslakiewicz 
> 

Looking pretty good over all. One problem throughout the whole set
however is, that you should diff from within your openwrt directory.
But the better way would be to use git format-patch.
Also, it might be a good idea to even split up this patch into the
topics that it covers: WLAN LED name and default state, registering
the gpio_chip and GPIO buttons. So that one patch addresses one issue.
Additional thoughts are inline.

> ---
> 
> This patch exports GPIOs connected to wireless chip. In some routers
> (for example Netgear WNR2000v3 which was used by me for development)
> certain buttons and LEDs are not connected to main SoC but to
> wifi chip instead.
> 
> Patch does the following:
> 
> * when CPTCFG_MAC80211_LEDS option is set and there are LEDs and/or 
>   buttons provided by device platform, ath9k module registers GPIO
>   chip, reserves GPIO pins and starts polling on keys using
>   'gpio-keys-polled' driver
> 
> * LED default_state is now honoured
> 
> * platform-supplied name for WLAN LED is supported (instead of
>   'ath9k-phy*' default)
> 
> GPIO chip base is auto-registered (as advised by kernel developers),
> so on my router pin numbers do not directly follow SoC GPIOs (0-19)
> but occupy numbers 53-63.
> 
> Due to nature of key polling, once started, module ath9k is locked
> and cannot be unloaded.
> 
> 
>  package/kernel/mac80211/patches/546-ath9k-gpio-enable.patch |  368 
> 
>  target/linux/generic/files/include/linux/ath9k_platform.h   |5 
>  2 files changed, 373 insertions(+)
> 
> 
> diff -pruN 
> a/openwrt/package/kernel/mac80211/patches/546-ath9k-gpio-enable.patch 
> b/openwrt/package/kernel/mac80211/patches/546-ath9k-gpio-enable.patch
> --- a/openwrt/package/kernel/mac80211/patches/546-ath9k-gpio-enable.patch 
> 1970-01-01 01:00:00.0 +0100
> +++ b/openwrt/package/kernel/mac80211/patches/546-ath9k-gpio-enable.patch 
> 2016-01-20 19:56:46.681693574 +0100
> @@ -0,0 +1,368 @@
> +diff -pruN a/drivers/net/wireless/ath/ath9k/ath9k.h 
> b/drivers/net/wireless/ath/ath9k/ath9k.h
> +--- a/drivers/net/wireless/ath/ath9k/ath9k.h 2016-01-20 19:52:13.849779144 
> +0100
>  b/drivers/net/wireless/ath/ath9k/ath9k.h 2016-01-20 19:52:13.752784871 
> +0100
> +@@ -24,6 +24,7 @@
> + #include 
> + #include 
> + #include 
> ++#include 
> + 
> + #include "common.h"
> + #include "debug.h"
> +@@ -817,6 +818,15 @@ void ath_fill_led_pin(struct ath_softc *
> + int ath_create_gpio_led(struct ath_softc *sc, int gpio, const char *name,
> + const char *trigger, bool active_low);
> + 
> ++//
> ++/*GPIO & Buttons*/
> ++//
> ++
> ++void ath9k_register_gpio_chip(struct ath_softc *sc);
> ++void ath9k_unregister_gpio_chip(struct ath_softc *sc);
> ++void ath9k_init_buttons(struct ath_softc *sc);
> ++void ath9k_deinit_buttons(struct ath_softc *sc);
> ++
> + #else
> + static inline void ath_init_leds(struct ath_softc *sc)
> + {
> +@@ -828,6 +838,20 @@ static inline void ath_deinit_leds(struc
> + static inline void ath_fill_led_pin(struct ath_softc *sc)
> + {
> + }
> ++
> ++static inline void ath9k_register_gpio_chip(struct ath_softc *sc)
> ++{
> ++}
> ++static inline void ath9k_unregister_gpio_chip(struct ath_softc *sc)
> ++{
> ++}
> ++
> ++void ath9k_init_buttons(struct ath_softc *sc)
> ++{
> ++}
> ++void ath9k_deinit_buttons(struct ath_softc *sc)
> ++{
> ++}
> + #endif
> + 
> + //
> +@@ -963,6 +987,12 @@ struct ath_led {
> + struct led_classdev cdev;
> + };
> + 
> ++struct ath9k_gpio_chip {
> ++struct ath_softc *sc;
> ++char label[32];
> ++struct gpio_chip gchip;
> ++};
> ++
> + struct ath_softc {
> + struct ieee80211_hw *hw;
> + struct device *dev;
> +@@ -1017,6 +1047,10 @@ struct ath_softc {
> + #ifdef CPTCFG_MAC80211_LEDS
> + const char *led_default_trigger;
> + struct list_head leds;
> ++
> ++struct ath9k_gpio_chip *gpiochip;
> ++
> ++struct platform_device *btnpdev;/* gpio-keys-polled */
> + #endif
> + 
> + #ifdef CPTCFG_ATH9K_DEBUGFS
> +diff -pruN a/drivers/net/wireless/ath/ath9k/gpio.c 
> b/drivers/net/wireless/ath/ath9k/gpio.c
> +--- a/drivers/net/wireless/ath/ath9k/gpio.c  2016-01-20 19:52:13.859778553 
> +0100
>  b/drivers/net/wireless/ath/ath9k/gpio.c  2016-01-20 19:52:13.761784340 
> +0100
> +@@ -22,6 +22,11 @@
> + //
> + 
> + #ifdef CPTCFG_MAC80211_LEDS
> ++
> ++#include 
> ++#include 
> ++#include 
> ++
> + static void ath_led_brightness(struct led_classdev *led_cdev,
> +   

[OpenWrt-Devel] [PATCH resend] ar71xx: add support for Netgear WPN824N

[Hartmut Knaack]

Add support for Netgear WPN824N.
Hardware specs:
  * AR7240, 4 LAN ports, 1 WAN port
  * AR9285 WLAN
  * 32 MB RAM
  * 4 MB Flash
  * 16 LEDs (LAN, WAN and Power/Status contain two LEDs for dual color
effect)
  * 3 Buttons (not supported)

Signed-off-by: Hartmut Knaack <knaac...@gmx.de>
---
Development Thread: https://forum.openwrt.org/viewtopic.php?id=30388
Wiki Page: https://wiki.openwrt.org/toh/netgear/wpn824n

Any suggestions about a better default configuration of the LAN/WAN LEDs,
to make use of their second color, are highly appreciated.

Resending, since PGP messed up previous message.
---
 target/linux/ar71xx/base-files/etc/board.d/01_leds |  20 +++-
 .../linux/ar71xx/base-files/etc/board.d/02_network |   3 +-
 target/linux/ar71xx/base-files/etc/diag.sh |   3 +-
 target/linux/ar71xx/base-files/lib/ar71xx.sh   |   3 +
 .../lib/preinit/05_set_preinit_iface_ar71xx|   1 +
 .../ar71xx/base-files/lib/upgrade/platform.sh  |   3 +-
 .../ar71xx/files/arch/mips/ath79/Kconfig.openwrt   |   2 +-
 .../ar71xx/files/arch/mips/ath79/mach-wnr2000-v3.c | 124 -
 .../linux/ar71xx/files/arch/mips/ath79/machtypes.h |   1 +
 target/linux/ar71xx/generic/profiles/netgear.mk|  10 ++
 target/linux/ar71xx/image/Makefile |   1 +
 .../files/drivers/mtd/mtdsplit/mtdsplit_uimage.c   |   2 +
 12 files changed, 166 insertions(+), 7 deletions(-)

diff --git a/target/linux/ar71xx/base-files/etc/board.d/01_leds 
b/target/linux/ar71xx/base-files/etc/board.d/01_leds
index cfb42a5..151eac2 100755
--- a/target/linux/ar71xx/base-files/etc/board.d/01_leds
+++ b/target/linux/ar71xx/base-files/etc/board.d/01_leds
@@ -684,7 +684,25 @@ wnr2000-v4)
ucidef_set_led_switch "lan3" "LAN3" "netgear:amber:lan3" "switch0" 
"0x08"
ucidef_set_led_switch "lan4" "LAN4" "netgear:amber:lan4" "switch0" 
"0x10"
ucidef_set_led_usbdev "usb" "USB" "netgear:amber:status" "1-1"
-;;
+   ;;
+
+wpn824n)
+   ucidef_set_led_netdev "wan-amber" "WAN (amber)" "netgear:amber:wan" 
"eth0"
+   ucidef_set_led_wlan "wlan" "WLAN" "netgear:blue:wlan" "phy0tpt"
+   ucidef_set_led_switch "lan1amber" "LAN1 (amber)" "netgear:amber:lan1" 
"switch0" "0x02"
+   ucidef_set_led_switch "lan2amber" "LAN2 (amber)" "netgear:amber:lan2" 
"switch0" "0x04"
+   ucidef_set_led_switch "lan3amber" "LAN3 (amber)" "netgear:amber:lan3" 
"switch0" "0x08"
+   ucidef_set_led_switch "lan4amber" "LAN4 (amber)" "netgear:amber:lan4" 
"switch0" "0x10"
+   ucidef_set_led_default "lan1green" "LAN1 (green)" "netgear:green:lan1" 
"0"
+   ucidef_set_led_default "lan2green" "LAN2 (green)" "netgear:green:lan2" 
"0"
+   ucidef_set_led_default "lan3green" "LAN3 (green)" "netgear:green:lan3" 
"0"
+   ucidef_set_led_default "lan4green" "LAN4 (green)" "netgear:green:lan4" 
"0"
+   ucidef_set_led_default "wan-green" "WAN (green)" "netgear:green:wan" "0"
+   ucidef_set_led_default "wps1" "WPS1" "netgear:blue:wps1" "0"
+   ucidef_set_led_default "wps2" "WPS2" "netgear:blue:wps2" "0"
+   ucidef_set_led_default "status" "STATUS" "netgear:amber:status" "0"
+   ucidef_set_led_default "test" "TEST" "netgear:amber:test" "0"
+   ;;
 
 wzr-hp-ag300h)
ucidef_set_led_default "diag" "DIAG" "buffalo:red:diag" "0"
diff --git a/target/linux/ar71xx/base-files/etc/board.d/02_network 
b/target/linux/ar71xx/base-files/etc/board.d/02_network
index 6b6c6a4..ed568b8 100755
--- a/target/linux/ar71xx/base-files/etc/board.d/02_network
+++ b/target/linux/ar71xx/base-files/etc/board.d/02_network
@@ -226,7 +226,8 @@ wnr2000-v3 |\
 wnr2000-v4 |\
 wnr2200 |\
 wnr612-v2 |\
-wnr1000-v2)
+wnr1000-v2 |\
+wpn824n)
ucidef_set_interfaces_lan_wan "eth1" "eth0"
ucidef_add_switch "switch0" \
"0:lan:4" "1:lan:3" "2:lan:2" "3:lan:1" "4@eth1" # XXX: confirm!
diff --git a/target/linux/ar71xx/base-files/etc/diag.sh 
b/target/linux/ar71xx/base-files/etc/diag.sh
index 13a0a98..c0e73ad 100644
--- a/target/linux/ar71xx/base-files/etc/diag.sh
+++ b/target/linux/ar71xx/base-files/e

[OpenWrt-Devel] [PATCH] ar71xx: add support for Netgear WPN824N

[Hartmut Knaack]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Add support for Netgear WPN824N.
Hardware specs:
  * AR7240, 4 LAN ports, 1 WAN port
  * AR9285 WLAN
  * 32 MB RAM
  * 4 MB Flash
  * 16 LEDs (LAN, WAN and Power/Status contain two LEDs for dual color
effect)
  * 3 Buttons (not supported)

Signed-off-by: Hartmut Knaack <knaac...@gmx.de>
- ---
Development Thread: https://forum.openwrt.org/viewtopic.php?id=30388
Wiki Page: https://wiki.openwrt.org/toh/netgear/wpn824n

Any suggestions about a better default configuration of the LAN/WAN LEDs,
to make use of their second color, are highly appreciated.
- ---
 target/linux/ar71xx/base-files/etc/board.d/01_leds |  20 +++-
 .../linux/ar71xx/base-files/etc/board.d/02_network |   3 +-
 target/linux/ar71xx/base-files/etc/diag.sh |   3 +-
 target/linux/ar71xx/base-files/lib/ar71xx.sh   |   3 +
 .../lib/preinit/05_set_preinit_iface_ar71xx|   1 +
 .../ar71xx/base-files/lib/upgrade/platform.sh  |   3 +-
 .../ar71xx/files/arch/mips/ath79/Kconfig.openwrt   |   2 +-
 .../ar71xx/files/arch/mips/ath79/mach-wnr2000-v3.c | 124 -
 .../linux/ar71xx/files/arch/mips/ath79/machtypes.h |   1 +
 target/linux/ar71xx/generic/profiles/netgear.mk|  10 ++
 target/linux/ar71xx/image/Makefile |   1 +
 .../files/drivers/mtd/mtdsplit/mtdsplit_uimage.c   |   2 +
 12 files changed, 166 insertions(+), 7 deletions(-)

diff --git a/target/linux/ar71xx/base-files/etc/board.d/01_leds 
b/target/linux/ar71xx/base-files/etc/board.d/01_leds
index cfb42a5..151eac2 100755
- --- a/target/linux/ar71xx/base-files/etc/board.d/01_leds
+++ b/target/linux/ar71xx/base-files/etc/board.d/01_leds
@@ -684,7 +684,25 @@ wnr2000-v4)
ucidef_set_led_switch "lan3" "LAN3" "netgear:amber:lan3" "switch0" 
"0x08"
ucidef_set_led_switch "lan4" "LAN4" "netgear:amber:lan4" "switch0" 
"0x10"
ucidef_set_led_usbdev "usb" "USB" "netgear:amber:status" "1-1"
- -;;
+   ;;
+
+wpn824n)
+   ucidef_set_led_netdev "wan-amber" "WAN (amber)" "netgear:amber:wan" 
"eth0"
+   ucidef_set_led_wlan "wlan" "WLAN" "netgear:blue:wlan" "phy0tpt"
+   ucidef_set_led_switch "lan1amber" "LAN1 (amber)" "netgear:amber:lan1" 
"switch0" "0x02"
+   ucidef_set_led_switch "lan2amber" "LAN2 (amber)" "netgear:amber:lan2" 
"switch0" "0x04"
+   ucidef_set_led_switch "lan3amber" "LAN3 (amber)" "netgear:amber:lan3" 
"switch0" "0x08"
+   ucidef_set_led_switch "lan4amber" "LAN4 (amber)" "netgear:amber:lan4" 
"switch0" "0x10"
+   ucidef_set_led_default "lan1green" "LAN1 (green)" "netgear:green:lan1" 
"0"
+   ucidef_set_led_default "lan2green" "LAN2 (green)" "netgear:green:lan2" 
"0"
+   ucidef_set_led_default "lan3green" "LAN3 (green)" "netgear:green:lan3" 
"0"
+   ucidef_set_led_default "lan4green" "LAN4 (green)" "netgear:green:lan4" 
"0"
+   ucidef_set_led_default "wan-green" "WAN (green)" "netgear:green:wan" "0"
+   ucidef_set_led_default "wps1" "WPS1" "netgear:blue:wps1" "0"
+   ucidef_set_led_default "wps2" "WPS2" "netgear:blue:wps2" "0"
+   ucidef_set_led_default "status" "STATUS" "netgear:amber:status" "0"
+   ucidef_set_led_default "test" "TEST" "netgear:amber:test" "0"
+   ;;
 
 wzr-hp-ag300h)
ucidef_set_led_default "diag" "DIAG" "buffalo:red:diag" "0"
diff --git a/target/linux/ar71xx/base-files/etc/board.d/02_network 
b/target/linux/ar71xx/base-files/etc/board.d/02_network
index 6b6c6a4..ed568b8 100755
- --- a/target/linux/ar71xx/base-files/etc/board.d/02_network
+++ b/target/linux/ar71xx/base-files/etc/board.d/02_network
@@ -226,7 +226,8 @@ wnr2000-v3 |\
 wnr2000-v4 |\
 wnr2200 |\
 wnr612-v2 |\
- -wnr1000-v2)
+wnr1000-v2 |\
+wpn824n)
ucidef_set_interfaces_lan_wan "eth1" "eth0"
ucidef_add_switch "switch0" \
"0:lan:4" "1:lan:3" "2:lan:2" "3:lan:1" "4@eth1" # XXX: confirm!
diff --git a/target/linux/ar71xx/base-files/etc/diag.sh 
b/target/linux/ar71xx/base-files/etc/diag.sh
index 13a0a98..c0e73ad 100644
- --- a/target/linux/ar71xx/base-files/etc/diag.sh
+++ b/target

Re: [OpenWrt-Devel] [PATCH] base-files: For sysfixtime use hwclock if RTC available

[Hartmut Knaack]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Daniel Dickinson schrieb am 10.01.2016 um 11:32:
> And yes you could make a regex that detect any sets of 8 spaces before 
> non-whitespace text, but that seems like a lot of effort for no good 
> reason, when not dealing with Makefiles.
> 
> Anything that applies a *hard* rule about whitespace is broken - 
> whitespace shouldn't be getting converted unless it's actually 
> necessary; a hard rule will fail under some conditions, and the real 
> issue is editors *changing* whitespace without user interaction (which 
> causes patches to fail).
> 
> Indead git's insistence on the exact same whitespace is the root issue, 
> since changing git would be a lot easier than changing a bazillion 
> editor to suite git (hint: ain't gonna happen).
> 
> I'm sure this has been discussed to death, but having patchwork be a 
> knob isn't the answer.
> 
> Regards,
> 
> Daniel
> 

Dude, no offense, but do you really think this is the right way to go? John
pointed out the place where the problem occurred, and instead of checking your
patch (takes maybe 2 minutes) you send 3 mails and speculate about unrelated
things. These small format issues happen to all of us some time, so I'd
recommend to take it easy, investigate more in the problem and think twice
before you send like 3 mails within one hour, mainly replying to yourself.
That said, I appreciate your effort in OpenWrt development and have no
intention to discourage you.
Keep up the good work.

Hartmut

> On 10/01/16 05:20 AM, Daniel Dickinson wrote:
>> Hi,
>>
>> On 10/01/16 05:10 AM, Gert Doering wrote:
>>> Hi,
>>>
>>> On Sun, Jan 10, 2016 at 04:47:05AM -0500, Daniel Dickinson wrote:
 I used git send-email so there shouldn't be any whitepspace mangling
 issues, unless patchwork is to blame.
>>>
>>> Over at openvpn-devel, we recently discovered that some versions of
>>> MS Exchange mangle whitespace for "mails in transit" - so even when the
>>> user did everything right (git send-email, etc.) Exchange still converted
>>> all tabs to 8x Space, leading to non-applying patches.
>>>
>>
>> I think this is a different issue. The issue here is that there is
>> indeed 8 spaces instead of a tab, *however* it's in a shell script AND
>> git doesn't complain, nor do regexes that detect things like spaces
>> before tabs (there is no tab after the spaces, only non-whitespace
>> text). In short patchwork appears to say 'for *all* files, you *must*
>> use tab instead of 8 spaces', which is not reasonable, and in some cases
>> is actually wrong.
>>
>> Also I am pretty certain provider is not running Windows, nor is
>> OpenWrt, so that is not likely to at issue.
>>
>>> Solution: send via freemail provider, using direct SMTP+Auth (which
>>> git send-email can do).
>>>
 That leaves receive-side error.  It seems likely given the line the
 error is on, that patchwork is pickier than git or the vim bit you sent
 me.  That is the 'offending' line is a shell script that happens to have
 8 spaces instead of tab.  Methinks this is not a relevant thing to
 complain about in a shell script; also I wonder whether it would do the
 same with with e.g. Python?  I suspect patchwork is applying Makefile
 rules to all patches, which is just wrong.
>>>
>>> The problem often is context.  If the parts before or after the actual
>>> change get whitespace-modified, git am will not accept it (traditional
>>> patch will, and complain about fuzz needed).
>>
>> However, the error being reported is not 'patch does not apply', it is
>> 'whitespace error', which implies that it's something patchwork is
>> reporting.
>>
>> Perhaps the error report really should be 'patch does not apply because
>> of whitespace error', but that is not what I was told, so I'm left
>> guessing.
>>
>> Regards,
>>
>> Daniel
>> ___
>> openwrt-devel mailing list
>> openwrt-devel@lists.openwrt.org
>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> 

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWkkDZAAoJEANoShj6yJFIdFIP/3nmjDmF3I2og74EmiPg4iaz
UwERlG1/dXy9mPc/DFg+3Eu9EoilGGfemoS7rSBHqJnxBIvxB18226Foe235x3S0
9KUCi3EmiqW5UYUHBg8PcZqKLJ2fRExfTyXhetWqs3UWN4D3Ah14aAK2cktEz4YD
1Nfnru1d0YLeoHVQvetILsozdbYxuyqOw74gKK/VtsOPiz5WAiwfKie7w47cunOX
ObnNNLxxW1+7fnPyFDv6vVtGpJkO79oywd4s74YqUT6xX1o164t46v86Tnn5C3Uj
HJTpTVxNgNCd0NJ6CbbWzWcnVyUuqdD0qIyYmZt29Tdse+fOO1V5iHUbR5L7vjNw
RdGg3CRXAgrq1J8+bsTbD+t1CdY35teE8s4Ayy13sMKtVr1rhqXBgAvSVhcpRRtF
fWWJHfr2zAag13/wkv/lqZfDquFT0IxgTVDzINrBrE1roq6JkUy+gEZnrOiardnp
f1Zj8xbuoi/1vQRb/NhM5gWKDK+MBlWjPHqpXiOnv9lsaDQBQvMi5V4+haBZrAM2
FWG9tVYpO+4mz02/jG0aemwUkRmj3In0RBfyCJNpBjKhfy0zknyT+pc7CxKacYPO
Nap7h5hqV6EsQ+XYCivugR/lfXrXwgXAZ5aDkGIO8puFHino0Awgx0PV29+BmwZw

Re: [OpenWrt-Devel] Convincing vim on Fedora to highlight 'bad' whitespace

[Hartmut Knaack]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Daniel Dickinson schrieb am 10.01.2016 um 16:01:
> Hi all,
> 
> While not strictly an OpenWrt topic, in the interests of helping other 
> with the style guidelines, here's a snipped for your $HOME/.vimrc
> 
> The following is mostly from John Crispin, with one additional regex 
> (for lines beginning with any number of sets of 8 spaces prior to 
> non-whitespace text).

I think such information should go into a wiki article at dev.openwrt.org.
Anybody starting development would more likely look there for information
than searching through the mailing list (at least that is how I did it).

> 
> Also note that on Fedora vim-minimal is install by default as vi.  If 
> you do not set up and alias or similar, when you type vi you get 
> vim-minimal (which doesn't have the required functionality) instead of 
> vim-enhanced (assuming you've installed it), for which you must use the 
> command vim.
> 
> [below here goes in $HOME/.vimrc]
> 
> highlight link localWhitespaceError Error
> 
> highlight link localWhitespaceError Error
> autocmd Syntax * syn match localWhitespaceError /\( \{8\}\)\+\ze[^\s]/ 
> display
> autocmd Syntax * syn match localWhitespaceError /\(\zs\%#\|\s\)\+$/ display
> autocmd Syntax * syn match localWhitespaceError / \ze\t/ display
> 
> 
> [above here goes in $HOME/.vimrc]
> 
> Regards,
> 
> Daniel
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> 

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWknc2AAoJEANoShj6yJFIPNEQAKIRlt5fIvQnSy1FjfZjHUxK
U5HCvTjnMH8xN75R0zJ6MIsKtCwDcIuMUUNcvQerfFYodOhppXEf05W9FwLQoLB4
PSYltqVLsnjUnzZt75F03fy5ZZFLSerZun4zEXXTUq1/aTuWpDtngt490RsWRgfM
2eSu0r1CXUrmgXhi75q4BuA9DkAo3CIvmiwDuM+qOSvf3CSOTt8WCsNAKB9mFzW8
bKESPFi+xiY7rxpL3ubQ+Ybn96CTTZYlnswDo1FJVPYdlOKe29fC8jKWRXBcsTGF
dSfhMVZT7W8/fyURTazYNdsyI6TL7y7NhGPaTIBEZYgHEUiNPaSHmIAeddQtAIma
QqjiTsK5E7yNGSauKHCIWFqreDlNB97Wb78jrTK34syaM4f5w6hHL6bcU80BHr4i
4PNCn64appMIo4XP+fP6CfKtVebj+eUFgH5kxf7RQYw7a9lC3lY1MjIIQxZijyxT
K4vEsF6wDtEfAZCTJZEj/FFzjQ9VZuR9KZ2UvUee1hOjy0zzc6mgHU5ADuMXAywi
uDc3UAxWDRRIXnRefQh1tjYGU9scIw53/uMEPZxCNXMqpOS9yc8TwIPQTJMpoaHT
zif/6cvAbHdN7r0sXBnd7eP0gD4b5EU6abdxCwGr8qqjOb9RFo/Rkl2mKcRrMo+J
h3Ybc4wmY0YnHHim7g4h
=f+wK
-END PGP SIGNATURE-


0xFAC89148.asc
Description: application/pgp-keys
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] How to config GPIO and read the GPIO value in OpenWRT

[Hartmut Knaack]

Afkar Rafique schrieb am 16.10.2015 um 03:47:
> Thanks for the reply.
> 
> I have change the script as below:
> 
> #!/bin/sh /etc/rc.common
> 
> START=19
> start() {   
> echo in > /sys/class/gpio/gpio16/direction 2> /dev/null   
> echo 16 > /sys/class/gpio/export 2> /dev/null

Still, you can only set the direction AFTER exporting the GPIO (otherwise the 
gpioXX
directory with its contents like direction don't exist).

> if [ "$(cat /sys/class/gpio/gpio16/value)" == "1" ] ; then
> echo "255" > 
> /sys/devices/platform/leds-gpio/leds/db120:green:status/brightness 
> else
> echo "0" > 
> /sys/devices/platform/leds-gpio/leds/db120:green:status/brightness 
> fi
> }
> 
> I need to monitor the LED on/off all the time during runtime.
> 
> During start of this script its working, but not getting how to make it work 
> run time.
> 
> Could you please explain how i can do it in gpio-button.

That would require you to add a custom button definition in the mach-file of 
your
specific device and compile your own firmware image.
You could however use a small script which infinitely loops through your poll 
and sleeps
for a second, so the CPU can work on other tasks, too (while true; do 
if...then...else
sleep 1; done). Downside is, that you can only react to "button press events", 
which are
long enough (one second, as this is the low limit of sleep time). Also, don't 
forget to
let it run in background, so you don't block your init process.

> 
> On Fri, Oct 16, 2015 at 3:38 AM, Hartmut Knaack <knaac...@gmx.de 
> <mailto:knaac...@gmx.de>> wrote:
> 
> Afkar Rafique schrieb am 15.10.2015 um 04:07:
> > Thanks for the reply.
> >
> > i have Create /etc/init.d/buttons and written below script:
> >
> > #!/bin/sh /etc/rc.common
> > START=19
> > start() {
> > /bin/umount /etc/config 2>/dev/null
> > echo out > /sys/class/gpio/gpio16/direction 2> /dev/null
> > echo 16 > /sys/class/gpio/export 2> /dev/null
> > if [ "$(cat /sys/class/gpio/gpio16/value)" == "1" ] ; then
> > echo "255" > 
> /sys/devices/platform/leds-gpio/leds/db120:green:status/brightness
> > else
> > echo "0" > 
> /sys/devices/platform/leds-gpio/leds/db120:green:status/brightness
> > fi
> > }
> >
> > and restart .
> >
> > chmod +x /etc/init.d/buttons
> > /etc/init.d/buttons enable
> > /etc/init.d/buttons start
> >
> > Now i am able to read the GPIO 16 value 1/0 based on GPIO state, but as 
> above script i have written to ON/OFF the Status LED based on GPIO value, 
> Status LED is not getting OFF even if GPIO16 value is "0".
> >
> > Can anyone please help on this
> >
> 
> Quite a mess you've got there. No idea why you need to umount /etc/config,
> but anyway: First thing in GPIO setup is exporting, then you set its 
> direction.
> If you intend to read the GPIO status, then better use "in" as direction.
> Now, do you just want to do an action (LED on/off) just during start of 
> this
> script, or all the time during runtime, when the GPIO status changes? In 
> the
> latter case, you should look into gpio-button.
> 
> >
> >
> > On Thu, Oct 15, 2015 at 12:37 AM, Martin Blumenstingl 
> <martin.blumensti...@googlemail.com 
> <mailto:martin.blumensti...@googlemail.com> 
> <mailto:martin.blumensti...@googlemail.com 
> <mailto:martin.blumensti...@googlemail.com>>> wrote:
> >
> > On Wed, Oct 14, 2015 at 12:19 PM, Afkar Rafique <afkar...@gmail.com 
> <mailto:afkar...@gmail.com> <mailto:afkar...@gmail.com 
> <mailto:afkar...@gmail.com>>> wrote:
> > > Could anyone please explain how i can configure and read GPIO 
> value.
> > There's an article on the wiki which explains how to set a GPIO to a
> > specific value: [0]
> > If you want to read a GPIO value then you use direction "in" and 
> then
> > simply cat to read the "value".
> >
> > The only thing that you might have to do is doing a bit of maths to
> > get the correct GPIO number.
> > When you are trying to read GPIO #16 then it's GPIO #16 of a 
> specific
> > chip -> /sys/class/gpio/ should contain a fi

Re: [OpenWrt-Devel] How to config GPIO and read the GPIO value in OpenWRT

[Hartmut Knaack]

Afkar Rafique schrieb am 15.10.2015 um 04:07:
> Thanks for the reply.
> 
> i have Create /etc/init.d/buttons and written below script:
> 
> #!/bin/sh /etc/rc.common
> START=19
> start() {
> /bin/umount /etc/config 2>/dev/null
> echo out > /sys/class/gpio/gpio16/direction 2> /dev/null   
> echo 16 > /sys/class/gpio/export 2> /dev/null
> if [ "$(cat /sys/class/gpio/gpio16/value)" == "1" ] ; then
> echo "255" > 
> /sys/devices/platform/leds-gpio/leds/db120:green:status/brightness 
> else
> echo "0" > 
> /sys/devices/platform/leds-gpio/leds/db120:green:status/brightness 
> fi
> }
> 
> and restart .
> 
> chmod +x /etc/init.d/buttons
> /etc/init.d/buttons enable
> /etc/init.d/buttons start
> 
> Now i am able to read the GPIO 16 value 1/0 based on GPIO state, but as above 
> script i have written to ON/OFF the Status LED based on GPIO value, Status 
> LED is not getting OFF even if GPIO16 value is "0".
> 
> Can anyone please help on this
> 

Quite a mess you've got there. No idea why you need to umount /etc/config,
but anyway: First thing in GPIO setup is exporting, then you set its direction.
If you intend to read the GPIO status, then better use "in" as direction.
Now, do you just want to do an action (LED on/off) just during start of this
script, or all the time during runtime, when the GPIO status changes? In the
latter case, you should look into gpio-button.

> 
> 
> On Thu, Oct 15, 2015 at 12:37 AM, Martin Blumenstingl 
>  > wrote:
> 
> On Wed, Oct 14, 2015 at 12:19 PM, Afkar Rafique  > wrote:
> > Could anyone please explain how i can configure and read GPIO value.
> There's an article on the wiki which explains how to set a GPIO to a
> specific value: [0]
> If you want to read a GPIO value then you use direction "in" and then
> simply cat to read the "value".
> 
> The only thing that you might have to do is doing a bit of maths to
> get the correct GPIO number.
> When you are trying to read GPIO #16 then it's GPIO #16 of a specific
> chip -> /sys/class/gpio/ should contain a file gpiochipNNN.
> What you do is take NNN (let's assume it's 456) and add your GPIO
> number to it: 456 + 16 = 472 -> this is the number needef to "export"
> the GPIO.
> 
> 
> [0] http://wiki.openwrt.org/doc/hardware/port.gpio#software
> 
> 
> 
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> 
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] Complete the trunk rename from Chaos Calmer to Designated Driver

[Hartmut Knaack]

Hannu Nyman schrieb am 13.09.2015 um 19:51:
> Sorry, but what is the problem?

Most importantly: laziness. In my case, I just keep hitting the next email
button and have a quick look. Having to open the attachment, choose an editor,
read, close the editor is just inconvenient (and then all the effort for just
one changed line of code). There are probably more people giving a silent ack
by not objecting.
Secondly: Commenting inline is much more inconvenient, if the patch is attached
rather than inline.

> ozlabs patchwork list shows the properly recognised patch:
> https://patchwork.ozlabs.org/patch/517209/
> 
> But in any case, inline below.
> 
> Hannu
> 
> Index: include/toplevel.mk
> ===
> --- include/toplevel.mk(revision 46894)
> +++ include/toplevel.mk(working copy)
> @@ -6,7 +6,7 @@
>   # See /LICENSE for more information.
>   #
> 
> -RELEASE:=Chaos Calmer
> +RELEASE:=Designated Driver
>   PREP_MK= OPENWRT_BUILD= QUIET=0
> 
>   export IS_TTY=$(shell tty -s && echo 1 || echo 0)
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> 
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Dark Destroyer

[Hartmut Knaack]

That Doodle poll turned out to be spamed/trolled, and everyone could even
change or delete other votes. Since this was just communicated over this
mailing list, and subscribers are at least basically verified, why not have a
good old fashioned poll?

Give your +1 answer on this mail if you prefer Dark Destroyer.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Designated Driver

[Hartmut Knaack]

That Doodle poll turned out to be spamed/trolled, and everyone could even
change or delete other votes. Since this was just communicated over this
mailing list, and subscribers are at least basically verified, why not have a
good old fashioned poll?

Give your +1 answer on this mail if you prefer Designated Driver.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Dirty Diamond

[Hartmut Knaack]

That Doodle poll turned out to be spamed/trolled, and everyone could even
change or delete other votes. Since this was just communicated over this
mailing list, and subscribers are at least basically verified, why not have a
good old fashioned poll?

Give your +1 answer on this mail if you prefer Dirty Diamond.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Designated Driver

[Hartmut Knaack]

+1

Hartmut Knaack schrieb am 07.04.2015 um 21:47:
 That Doodle poll turned out to be spamed/trolled, and everyone could even
 change or delete other votes. Since this was just communicated over this
 mailing list, and subscribers are at least basically verified, why not have a
 good old fashioned poll?
 
 Give your +1 answer on this mail if you prefer Designated Driver.
 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
 
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] OpenWrt release name

[Hartmut Knaack]

Robert P. J. Day schrieb am 06.04.2015 um 11:49:
 On Mon, 6 Apr 2015, edgar.sol...@web.de wrote:
 
 On 06.04.2015 09:35, John Crispin wrote:
 i think we have a winner with 96 vs 50 votes.

 == Dirty Diamond ==
 2 cl Rum
 2 cl Vodka
 2 cl Tequila Silver
 2 cl Campari
 2 cl Curaçao Blue
 2 cl Lime syrup
 2 1/2 cl Orange juice
  Coca Cola


 i also liked

 == Designated Driver ==
 1 part cranberry juice cocktail
 1 part grapefruit juice
 1 part orange juice
 1 part pineapple juice

 , which would also be a nice pun on router functionality.
 is it really to late to consider this additional entry?
 
   hey, that was my idea. :-) and given alphabetics, it's the last
 chance you'll get to use that particular pun. choose carefully.
 
 rday
 
 
+1 on Designated Driver. It's the one who needs to be responsible,
while everyone else can have fun. Fits perfectly to a router running
OpenWrt.

Hartmut

 
 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
 
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] [ar71xx] Add support for MERCURY MAC1200R

[Hartmut Knaack]

Roger Pueyo Centelles schrieb am 26.01.2015 um 18:10:
 Hi,
 
 Thank you both for your comments.
 
 @郭传鈜:
 
 +   ucidef_set_led_wlan wlan2g WLAN2G mercury:green:wlan2g 
 phy1tpt
 I think the following line is incorrect:
 +   ucidef_set_led_wlan wlan5g WLAN5G mercury:green:wlan5g 
 phy0tpt
 There is no LED trigger called 'phy0tpt' so I think we should use netdev 
 trigger like this:
 ucidef_set_led_netdev wlan5g WLAN5G mercury:green:wlan5g wlan0
 
 Ok!
 
 
 +static struct gpio_keys_button mac1200r_gpio_keys[] __initdata = {
 +   {
 +   .desc   = WPS button,
 +   .type   = EV_KEY,
 +   .code   = KEY_WPS_BUTTON,
 +   .debounce_interval = MAC1200R_KEYS_DEBOUNCE_INTERVAL,
 +   .gpio   = MAC1200R_GPIO_BTN_WPS,
 +   .active_low = 1,
 +   },
 +};
 Although the key is called WPS/RESET , I think a reset button is more 
 important than a WPS button.That's just my personal opinion :)
 
 I think you are right.
 
 
 +   ap91_pci_init(art + MAC1200R_PCIE_CALDATA_OFFSET, tmpmac);
 What? I think this function is only able to load CALDATA for ath9k 
 devices.Maybe I'm wrong:)
 
 The router has two radios, one ath9k and one ath10k. Isn't it needed for the 
 ath9k calibration data? Or this radio is already covered by 
 ath79_register_wmac(art + MAC1200R_WMAC_CALDATA_OFFSET, tmpmac); ...?
 
 
 +$(eval $(call 
 SingleProfile,TPLINK-LZMA,64kraw,MAC1200R,mc-mac1200r,MC-MAC1200R,ttyS0,115200,0x1201,1,8Mlzma))
The factory image is broken since TP-LINK started to use a new firmware 
format with RSA signature in China.This should be introduced in the TOH wiki 
I think:)
 
 Done!
 
 
 
 @John:
 
 Sorry. Do you mean a description for the patch? I am not aware of what SoB 
 means.

Yes, a patch description followed by your Signed-off-by (SoB) is missing. Have 
a look at the submitting patches wiki page for the patch format requirements. 
Also, check through your patch again and make sure to mind alphabetic order 
wherever needed.

 
 
 Thanks!
 
 Roger
 
 
 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
 
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] kernel: gpio: pca953x: backport gpio input fix

[Hartmut Knaack]

Pushpal Sidhu schrieb am 09.10.2014 02:51:
 This fix is for anyone on 3.10 using the pca953x driver. A regression
 was introduced when this driver was converted to using 8-bit
 reads/writes the bitmask in pca953x_gpio_get_value wasn't adjusted with
 the modulus BANK_SZ and consequently looks at the wrong bits in the
 input register.
 
 This backports the following commit from the mainline linux kernel:
 40a625daa88653d7942dc85483f6f289cd687cb7
I totally support getting this fix in, but I think the format you attempt to 
use is in conflict to what target/linux/generic/PATCHES states. First, I would 
recommend to number it according to 0xx - upstream backports, 004 seems to be 
free. Second, I would actually put the content of [1] into that patch file, as 
it contains all the useful information of when it was created originally and 
who was involved.

[1] 
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/patch/drivers/gpio/gpio-pca953x.c?id=40a625daa88653d7942dc85483f6f289cd687cb7
 
 Signed-off-by: Pushpal Sidhu psi...@gateworks.com
 ---
  .../350-gpio-pca953x-fix_gpio_input_on_gpio_offsets.patch   | 13 
 +
  1 file changed, 13 insertions(+)
  create mode 100644 
 target/linux/generic/patches-3.10/350-gpio-pca953x-fix_gpio_input_on_gpio_offsets.patch
 
 diff --git 
 a/target/linux/generic/patches-3.10/350-gpio-pca953x-fix_gpio_input_on_gpio_offsets.patch
  
 b/target/linux/generic/patches-3.10/350-gpio-pca953x-fix_gpio_input_on_gpio_offsets.patch
 new file mode 100644
 index 000..654fccf
 --- /dev/null
 +++ 
 b/target/linux/generic/patches-3.10/350-gpio-pca953x-fix_gpio_input_on_gpio_offsets.patch
 @@ -0,0 +1,13 @@
 +Index: linux-3.10.49/drivers/gpio/gpio-pca953x.c
 +===
 +--- linux-3.10.49.orig/drivers/gpio/gpio-pca953x.c   2014-07-17 
 15:58:15.0 -0700
  linux-3.10.49/drivers/gpio/gpio-pca953x.c2014-10-08 
 14:49:46.974913692 -0700
 +@@ -308,7 +308,7 @@
 + return 0;
 + }
 + 
 +-return (reg_val  (1u  off)) ? 1 : 0;
 ++return (reg_val  (1u  (off % BANK_SZ))) ? 1 : 0;
 + }
 + 
 + static void pca953x_gpio_set_value(struct gpio_chip *gc, unsigned off, int 
 val)
 
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] Add support for DHT11 driver

[Hartmut Knaack]

har...@ccbib.org schrieb am 26.09.2014 12:46:
 The DHT11 is a temperature and humidity sensor supported by linux
 since 3.14.
 
 This patch has been tested on recent mxs with kernel 3.14.18.
 
 Signed-off-by: Harald Geyer har...@ccbib.org
Hi,
I would expect to make it also depend on device tree or architectures which 
support device tree. From what I remember, there are still architectures which 
have not yet been converted to devicetree. In those cases, it would be 
confusing and useless to build this module. Or am I missing something? I don't 
have any practical experience with devicetree, so far.

 ---
  package/kernel/linux/modules/other.mk |   20 
  1 files changed, 20 insertions(+), 0 deletions(-)
 
 diff --git a/package/kernel/linux/modules/other.mk
 b/package/kernel/linux/modules/other.mk
 index d56bb50..bef24eb 100644
 --- a/package/kernel/linux/modules/other.mk
 +++ b/package/kernel/linux/modules/other.mk
 @@ -258,6 +258,26 @@ endef
  
  $(eval $(call KernelPackage,iio-ad799x))
  
 +
 +define KernelPackage/iio-dht11
 +  SUBMENU:=$(OTHER_MENU)
 +  DEPENDS:=kmod-iio-core @GPIO_SUPPORT
 +  TITLE:=DHT11 (and compatible) humidity and temperature sensors
 +  KCONFIG:= \
 + CONFIG_DHT11
 +  FILES:=$(LINUX_DIR)/drivers/iio/humidity/dht11.ko
 +  AUTOLOAD:=$(call AutoLoad,56,dht11)
 +endef
 +
 +define KernelPackage/iio-dht11/description
 + support for DHT11 and DHT22 digitial humidity and temperature sensors
 + attached at GPIO lines. You will need a custom device tree file to
 + specify the GPIO line to use.
 +endef
 +
 +$(eval $(call KernelPackage,iio-dht11))
 +
 +
  define KernelPackage/lp
SUBMENU:=$(OTHER_MENU)
TITLE:=Parallel port and line printer support
 
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH][BB]Backport essential fixes for ad799x

[Hartmut Knaack]

This patch ports back some fixes of the ad799x driver, which were
committed between 3.10 and 3.15.

Signed-off-by: Hartmut Knaack knaac...@gmx.de
---
This is the patch out of the series, which got committed to trunk lately, which 
is appropriate for Barrier Breaker.
http://patchwork.openwrt.org/patch/5771/

diff --git 
a/target/linux/generic/patches-3.10/065-iio_ad799x_backport_fixes.patch 
b/target/linux/generic/patches-3.10/065-iio_ad799x_backport_fixes.patch
new file mode 100644
index 000..4368ec7
--- /dev/null
+++ b/target/linux/generic/patches-3.10/065-iio_ad799x_backport_fixes.patch
@@ -0,0 +1,159 @@
+Backport essential fixes from 3.15
+
+From Linux 3.10 on this driver required platform data to load, which makes it
+unusable in OpenWRT. This commit backports the following fixes:
+  * Move to regulator framework for scaling
+  * Set endianness of the ADC to Big endian
+  * Fix device-removal path
+This commit should not be moved to newer kernel versions!
+
+Signed-off-by: Hartmut Knaack knaac...@gmx.de
+---
+diff -uprN a/drivers/staging/iio/adc/ad799x_core.c 
b/drivers/staging/iio/adc/ad799x_core.c
+--- a/drivers/staging/iio/adc/ad799x_core.c
 b/drivers/staging/iio/adc/ad799x_core.c
+@@ -163,7 +163,6 @@ static int ad799x_read_raw(struct iio_de
+ {
+   int ret;
+   struct ad799x_state *st = iio_priv(indio_dev);
+-  unsigned int scale_uv;
+ 
+   switch (m) {
+   case IIO_CHAN_INFO_RAW:
+@@ -180,10 +179,12 @@ static int ad799x_read_raw(struct iio_de
+   RES_MASK(chan-scan_type.realbits);
+   return IIO_VAL_INT;
+   case IIO_CHAN_INFO_SCALE:
+-  scale_uv = (st-int_vref_mv * 1000)  chan-scan_type.realbits;
+-  *val =  scale_uv / 1000;
+-  *val2 = (scale_uv % 1000) * 1000;
+-  return IIO_VAL_INT_PLUS_MICRO;
++  ret = regulator_get_voltage(st-vref);
++  if (ret  0)
++  return ret;
++  *val =  ret / 1000;
++  *val2 = chan-scan_type.realbits;
++  return IIO_VAL_FRACTIONAL_LOG2;
+   }
+   return -EINVAL;
+ }
+@@ -474,7 +475,13 @@ static const struct iio_info ad7993_4_7_
+   .info_mask_separate = BIT(IIO_CHAN_INFO_RAW), \
+   .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE), \
+   .scan_index = (_index), \
+-  .scan_type = IIO_ST('u', _realbits, 16, 12 - (_realbits)), \
++  .scan_type = { \
++  .sign = 'u', \
++  .realbits = (_realbits), \
++  .storagebits = 16, \
++  .shift = 12 - (_realbits), \
++  .endianness = IIO_BE, \
++  }, \
+   .event_mask = (_evmask), \
+ }
+ 
+@@ -584,7 +591,6 @@ static int ad799x_probe(struct i2c_clien
+  const struct i2c_device_id *id)
+ {
+   int ret;
+-  struct ad799x_platform_data *pdata = client-dev.platform_data;
+   struct ad799x_state *st;
+   struct iio_dev *indio_dev = iio_device_alloc(sizeof(*st));
+ 
+@@ -601,17 +607,21 @@ static int ad799x_probe(struct i2c_clien
+ 
+   /* TODO: Add pdata options for filtering and bit delay */
+ 
+-  if (!pdata)
+-  return -EINVAL;
+-
+-  st-int_vref_mv = pdata-vref_mv;
+-
+-  st-reg = regulator_get(client-dev, vcc);
+-  if (!IS_ERR(st-reg)) {
+-  ret = regulator_enable(st-reg);
+-  if (ret)
+-  goto error_put_reg;
++  st-reg = devm_regulator_get(client-dev, vcc);
++  if (IS_ERR(st-reg))
++  return PTR_ERR(st-reg);
++  ret = regulator_enable(st-reg);
++  if (ret)
++  return ret;
++  st-vref = devm_regulator_get(client-dev, vref);
++  if (IS_ERR(st-vref)) {
++  ret = PTR_ERR(st-vref);
++  goto error_disable_reg;
+   }
++  ret = regulator_enable(st-vref);
++  if (ret)
++  goto error_disable_reg;
++
+   st-client = client;
+ 
+   indio_dev-dev.parent = client-dev;
+@@ -624,7 +634,7 @@ static int ad799x_probe(struct i2c_clien
+ 
+   ret = ad799x_register_ring_funcs_and_init(indio_dev);
+   if (ret)
+-  goto error_disable_reg;
++  goto error_disable_vref;
+ 
+   if (client-irq  0) {
+   ret = request_threaded_irq(client-irq,
+@@ -648,12 +658,10 @@ error_free_irq:
+   free_irq(client-irq, indio_dev);
+ error_cleanup_ring:
+   ad799x_ring_cleanup(indio_dev);
++error_disable_vref:
++  regulator_disable(st-vref);
+ error_disable_reg:
+-  if (!IS_ERR(st-reg))
+-  regulator_disable(st-reg);
+-error_put_reg:
+-  if (!IS_ERR(st-reg))
+-  regulator_put(st-reg);
++  regulator_disable(st-reg);
+   iio_device_free(indio_dev);
+ 
+   return ret;
+@@ -669,10 +677,8 @@ static int ad799x_remove(struct i2c_clie
+   free_irq(client-irq, indio_dev);
+ 
+   ad799x_ring_cleanup(indio_dev);
+-  if (!IS_ERR(st-reg

Re: [OpenWrt-Devel] [PATCH] Backport essential fixes for ad799x

[Hartmut Knaack]

Ping
Any objections, or everybody just working on the stable release?

Hartmut Knaack schrieb:
 This series of patches ports back some fixes of the ad799x driver, which were
 commited between 3.10 and 3.15.

 Signed-off-by: Hartmut Knaack knaac...@gmx.de
 ---
 diff --git 
 a/target/linux/generic/patches-3.10/065-iio_ad799x_backport_fixes.patch 
 b/target/linux/generic/patches-3.10/065-iio_ad799x_backport_fixes.patch
 new file mode 100644
 index 000..4368ec7
 --- /dev/null
 +++ b/target/linux/generic/patches-3.10/065-iio_ad799x_backport_fixes.patch
 @@ -0,0 +1,159 @@
 +Backport essential fixes from 3.15
 +
 +From Linux 3.10 on this driver required platform data to load, which makes it
 +unusable in OpenWRT. This commit backports the following fixes:
 +  * Move to regulator framework for scaling
 +  * Set endianness of the ADC to Big endian
 +  * Fix device-removal path
 +This commit should not be moved to newer kernel versions!
 +
 +Signed-off-by: Hartmut Knaack knaac...@gmx.de
 +---
 +diff -uprN a/drivers/staging/iio/adc/ad799x_core.c 
 b/drivers/staging/iio/adc/ad799x_core.c
 +--- a/drivers/staging/iio/adc/ad799x_core.c
  b/drivers/staging/iio/adc/ad799x_core.c
 +@@ -163,7 +163,6 @@ static int ad799x_read_raw(struct iio_de
 + {
 + int ret;
 + struct ad799x_state *st = iio_priv(indio_dev);
 +-unsigned int scale_uv;
 + 
 + switch (m) {
 + case IIO_CHAN_INFO_RAW:
 +@@ -180,10 +179,12 @@ static int ad799x_read_raw(struct iio_de
 + RES_MASK(chan-scan_type.realbits);
 + return IIO_VAL_INT;
 + case IIO_CHAN_INFO_SCALE:
 +-scale_uv = (st-int_vref_mv * 1000)  chan-scan_type.realbits;
 +-*val =  scale_uv / 1000;
 +-*val2 = (scale_uv % 1000) * 1000;
 +-return IIO_VAL_INT_PLUS_MICRO;
 ++ret = regulator_get_voltage(st-vref);
 ++if (ret  0)
 ++return ret;
 ++*val =  ret / 1000;
 ++*val2 = chan-scan_type.realbits;
 ++return IIO_VAL_FRACTIONAL_LOG2;
 + }
 + return -EINVAL;
 + }
 +@@ -474,7 +475,13 @@ static const struct iio_info ad7993_4_7_
 + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW), \
 + .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE), \
 + .scan_index = (_index), \
 +-.scan_type = IIO_ST('u', _realbits, 16, 12 - (_realbits)), \
 ++.scan_type = { \
 ++.sign = 'u', \
 ++.realbits = (_realbits), \
 ++.storagebits = 16, \
 ++.shift = 12 - (_realbits), \
 ++.endianness = IIO_BE, \
 ++}, \
 + .event_mask = (_evmask), \
 + }
 + 
 +@@ -584,7 +591,6 @@ static int ad799x_probe(struct i2c_clien
 +const struct i2c_device_id *id)
 + {
 + int ret;
 +-struct ad799x_platform_data *pdata = client-dev.platform_data;
 + struct ad799x_state *st;
 + struct iio_dev *indio_dev = iio_device_alloc(sizeof(*st));
 + 
 +@@ -601,17 +607,21 @@ static int ad799x_probe(struct i2c_clien
 + 
 + /* TODO: Add pdata options for filtering and bit delay */
 + 
 +-if (!pdata)
 +-return -EINVAL;
 +-
 +-st-int_vref_mv = pdata-vref_mv;
 +-
 +-st-reg = regulator_get(client-dev, vcc);
 +-if (!IS_ERR(st-reg)) {
 +-ret = regulator_enable(st-reg);
 +-if (ret)
 +-goto error_put_reg;
 ++st-reg = devm_regulator_get(client-dev, vcc);
 ++if (IS_ERR(st-reg))
 ++return PTR_ERR(st-reg);
 ++ret = regulator_enable(st-reg);
 ++if (ret)
 ++return ret;
 ++st-vref = devm_regulator_get(client-dev, vref);
 ++if (IS_ERR(st-vref)) {
 ++ret = PTR_ERR(st-vref);
 ++goto error_disable_reg;
 + }
 ++ret = regulator_enable(st-vref);
 ++if (ret)
 ++goto error_disable_reg;
 ++
 + st-client = client;
 + 
 + indio_dev-dev.parent = client-dev;
 +@@ -624,7 +634,7 @@ static int ad799x_probe(struct i2c_clien
 + 
 + ret = ad799x_register_ring_funcs_and_init(indio_dev);
 + if (ret)
 +-goto error_disable_reg;
 ++goto error_disable_vref;
 + 
 + if (client-irq  0) {
 + ret = request_threaded_irq(client-irq,
 +@@ -648,12 +658,10 @@ error_free_irq:
 + free_irq(client-irq, indio_dev);
 + error_cleanup_ring:
 + ad799x_ring_cleanup(indio_dev);
 ++error_disable_vref:
 ++regulator_disable(st-vref);
 + error_disable_reg:
 +-if (!IS_ERR(st-reg))
 +-regulator_disable(st-reg);
 +-error_put_reg:
 +-if (!IS_ERR(st-reg))
 +-regulator_put(st-reg);
 ++regulator_disable(st-reg);
 + iio_device_free(indio_dev);
 + 
 + return ret;
 +@@ -669,10 +677,8 @@ static int ad799x_remove(struct i2c_clie
 + free_irq(client-irq, indio_dev);
 + 
 + ad799x_ring_cleanup(indio_dev);
 +-if (!IS_ERR(st-reg)) {
 +-regulator_disable(st-reg);
 +-regulator_put(st-reg

[OpenWrt-Devel] [PATCH]other.mk: update configuration for ad799x

[Hartmut Knaack]

The ad799x driver moved out of staging since kernel 3.16, so update filepath,
config elements and description.

Signed-off-by: Hartmut Knaack knaac...@gmx.de
---
diff --git a/package/kernel/linux/modules/other.mk 
b/package/kernel/linux/modules/other.mk
index 2f6f774..6afcbb6 100644
--- a/package/kernel/linux/modules/other.mk
+++ b/package/kernel/linux/modules/other.mk
@@ -239,17 +239,22 @@ define KernelPackage/iio-ad799x
   SUBMENU:=$(OTHER_MENU)
   DEPENDS:=kmod-i2c-core kmod-iio-core
   TITLE:=Analog Devices AD799x ADC driver
+ifeq ($(strip $(call CompareKernelPatchVer,$(KERNEL_PATCHVER),ge,3.16.0)),1)
+  KCONFIG:=CONFIG_AD799X
+  FILES:=$(LINUX_DIR)/drivers/iio/adc/ad799x.ko
+else
   KCONFIG:= \
CONFIG_AD799X_RING_BUFFER=y \
CONFIG_AD799X
   FILES:=$(LINUX_DIR)/drivers/staging/iio/adc/ad799x.ko
+endif
   AUTOLOAD:=$(call AutoLoad,56,ad799x)
 endef
 
 define KernelPackage/iio-ad799x/description
  support for Analog Devices:
  ad7991, ad7995, ad7999, ad7992, ad7993, ad7994, ad7997, ad7998
- i2c analog to digital converters (ADC). WARNING! This driver is still staging!
+ i2c analog to digital converters (ADC).
 endef
 
 $(eval $(call KernelPackage,iio-ad799x))
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] Backport essential fixes for ad799x

[Hartmut Knaack]

This series of patches ports back some fixes of the ad799x driver, which were
commited between 3.10 and 3.15.

Signed-off-by: Hartmut Knaack knaac...@gmx.de
---
diff --git 
a/target/linux/generic/patches-3.10/065-iio_ad799x_backport_fixes.patch 
b/target/linux/generic/patches-3.10/065-iio_ad799x_backport_fixes.patch
new file mode 100644
index 000..4368ec7
--- /dev/null
+++ b/target/linux/generic/patches-3.10/065-iio_ad799x_backport_fixes.patch
@@ -0,0 +1,159 @@
+Backport essential fixes from 3.15
+
+From Linux 3.10 on this driver required platform data to load, which makes it
+unusable in OpenWRT. This commit backports the following fixes:
+  * Move to regulator framework for scaling
+  * Set endianness of the ADC to Big endian
+  * Fix device-removal path
+This commit should not be moved to newer kernel versions!
+
+Signed-off-by: Hartmut Knaack knaac...@gmx.de
+---
+diff -uprN a/drivers/staging/iio/adc/ad799x_core.c 
b/drivers/staging/iio/adc/ad799x_core.c
+--- a/drivers/staging/iio/adc/ad799x_core.c
 b/drivers/staging/iio/adc/ad799x_core.c
+@@ -163,7 +163,6 @@ static int ad799x_read_raw(struct iio_de
+ {
+   int ret;
+   struct ad799x_state *st = iio_priv(indio_dev);
+-  unsigned int scale_uv;
+ 
+   switch (m) {
+   case IIO_CHAN_INFO_RAW:
+@@ -180,10 +179,12 @@ static int ad799x_read_raw(struct iio_de
+   RES_MASK(chan-scan_type.realbits);
+   return IIO_VAL_INT;
+   case IIO_CHAN_INFO_SCALE:
+-  scale_uv = (st-int_vref_mv * 1000)  chan-scan_type.realbits;
+-  *val =  scale_uv / 1000;
+-  *val2 = (scale_uv % 1000) * 1000;
+-  return IIO_VAL_INT_PLUS_MICRO;
++  ret = regulator_get_voltage(st-vref);
++  if (ret  0)
++  return ret;
++  *val =  ret / 1000;
++  *val2 = chan-scan_type.realbits;
++  return IIO_VAL_FRACTIONAL_LOG2;
+   }
+   return -EINVAL;
+ }
+@@ -474,7 +475,13 @@ static const struct iio_info ad7993_4_7_
+   .info_mask_separate = BIT(IIO_CHAN_INFO_RAW), \
+   .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE), \
+   .scan_index = (_index), \
+-  .scan_type = IIO_ST('u', _realbits, 16, 12 - (_realbits)), \
++  .scan_type = { \
++  .sign = 'u', \
++  .realbits = (_realbits), \
++  .storagebits = 16, \
++  .shift = 12 - (_realbits), \
++  .endianness = IIO_BE, \
++  }, \
+   .event_mask = (_evmask), \
+ }
+ 
+@@ -584,7 +591,6 @@ static int ad799x_probe(struct i2c_clien
+  const struct i2c_device_id *id)
+ {
+   int ret;
+-  struct ad799x_platform_data *pdata = client-dev.platform_data;
+   struct ad799x_state *st;
+   struct iio_dev *indio_dev = iio_device_alloc(sizeof(*st));
+ 
+@@ -601,17 +607,21 @@ static int ad799x_probe(struct i2c_clien
+ 
+   /* TODO: Add pdata options for filtering and bit delay */
+ 
+-  if (!pdata)
+-  return -EINVAL;
+-
+-  st-int_vref_mv = pdata-vref_mv;
+-
+-  st-reg = regulator_get(client-dev, vcc);
+-  if (!IS_ERR(st-reg)) {
+-  ret = regulator_enable(st-reg);
+-  if (ret)
+-  goto error_put_reg;
++  st-reg = devm_regulator_get(client-dev, vcc);
++  if (IS_ERR(st-reg))
++  return PTR_ERR(st-reg);
++  ret = regulator_enable(st-reg);
++  if (ret)
++  return ret;
++  st-vref = devm_regulator_get(client-dev, vref);
++  if (IS_ERR(st-vref)) {
++  ret = PTR_ERR(st-vref);
++  goto error_disable_reg;
+   }
++  ret = regulator_enable(st-vref);
++  if (ret)
++  goto error_disable_reg;
++
+   st-client = client;
+ 
+   indio_dev-dev.parent = client-dev;
+@@ -624,7 +634,7 @@ static int ad799x_probe(struct i2c_clien
+ 
+   ret = ad799x_register_ring_funcs_and_init(indio_dev);
+   if (ret)
+-  goto error_disable_reg;
++  goto error_disable_vref;
+ 
+   if (client-irq  0) {
+   ret = request_threaded_irq(client-irq,
+@@ -648,12 +658,10 @@ error_free_irq:
+   free_irq(client-irq, indio_dev);
+ error_cleanup_ring:
+   ad799x_ring_cleanup(indio_dev);
++error_disable_vref:
++  regulator_disable(st-vref);
+ error_disable_reg:
+-  if (!IS_ERR(st-reg))
+-  regulator_disable(st-reg);
+-error_put_reg:
+-  if (!IS_ERR(st-reg))
+-  regulator_put(st-reg);
++  regulator_disable(st-reg);
+   iio_device_free(indio_dev);
+ 
+   return ret;
+@@ -669,10 +677,8 @@ static int ad799x_remove(struct i2c_clie
+   free_irq(client-irq, indio_dev);
+ 
+   ad799x_ring_cleanup(indio_dev);
+-  if (!IS_ERR(st-reg)) {
+-  regulator_disable(st-reg);
+-  regulator_put(st-reg);
+-  }
++  regulator_disable(st-vref

Re: [OpenWrt-Devel] [PATCH] ar71xx: add support for the EnGenius ESR900

[Hartmut Knaack]

I'm afraid this patch has seriously been mangled by your mail client, please 
resend. Also, even though there is already some mess-up in alphabetic order in 
ar71xx_board_detect(), your entry should be between eap7660d and ja76pf.

Forest Crossman schrieb:
 Signed-off-by: Forest Crossman cyro...@gmail.com
 ---
  package/base-files/files/lib/functions/system.sh   |   1 +
  target/linux/ar71xx/base-files/etc/diag.sh |   3 +
  .../ar71xx/base-files/etc/uci-defaults/01_leds |   5 +
  .../ar71xx/base-files/etc/uci-defaults/02_network  |  11 +
  target/linux/ar71xx/base-files/lib/ar71xx.sh   |   3 +
  target/linux/ar71xx/config-3.10|   1 +
  .../ar71xx/files/arch/mips/ath79/mach-esr900.c | 232 
 +
  target/linux/ar71xx/files/arch/mips/ath79/nvram.c  |  16 ++
  target/linux/ar71xx/generic/profiles/engenius.mk   |  16 ++
  target/linux/ar71xx/image/Makefile |   2 +
  .../610-MIPS-ath79-openwrt-machines.patch  |  18 +-
  11 files changed, 305 insertions(+), 3 deletions(-)
  create mode 100644 target/linux/ar71xx/files/arch/mips/ath79/mach-esr900.c
  create mode 100644 target/linux/ar71xx/generic/profiles/engenius.mk

 diff --git a/package/base-files/files/lib/functions/system.sh
 b/package/base-files/files/lib/functions/system.sh
 index a4c0f26..8d75a5a 100644
 --- a/package/base-files/files/lib/functions/system.sh
 +++ b/package/base-files/files/lib/functions/system.sh
 @@ -82,6 +82,7 @@ macaddr_canonicalize()
   local mac=$1
   local canon=

 + mac=$(echo -n $mac | tr -d \)
   [ ${#mac} -gt 17 ]  return
   [ -n ${mac//[a-fA-F0-9\.: -]/} ]  return

 diff --git a/target/linux/ar71xx/base-files/etc/diag.sh
 b/target/linux/ar71xx/base-files/etc/diag.sh
 index d5063de..81e4eff 100755
 --- a/target/linux/ar71xx/base-files/etc/diag.sh
 +++ b/target/linux/ar71xx/base-files/etc/diag.sh
 @@ -238,6 +238,9 @@ get_status_led() {
   wlr8100)
   status_led=sitecom:amber:status
   ;;
 + esr900)
 + status_led=engenius:amber:power
 + ;;
   esac
  }

 diff --git a/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds
 b/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds
 index fe5ff93..8265b00 100755
 --- a/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds
 +++ b/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds
 @@ -103,6 +103,11 @@ dir-825-c1)
   ucidef_set_led_wlan wlan2g WLAN 2.4 GHz d-link:blue:wlan2g phy0tpt
   ;;

 +esr900)
 + ucidef_set_led_wlan wlan2g WLAN 2.4 GHz engenius:blue:wlan-2g 
 phy0tpt
 + ucidef_set_led_wlan wlan5g WLAN 5 GHz engenius:blue:wlan-5g phy1tpt
 + ;;
 +
  hiwifi-hc6361)
   ucidef_set_led_default inet INET hiwifi:blue:internet 0
   ucidef_set_led_wlan wlan WLAN hiwifi:blue:wlan-2p4 phy0tpt
 diff --git a/target/linux/ar71xx/base-files/etc/uci-defaults/02_network
 b/target/linux/ar71xx/base-files/etc/uci-defaults/02_network
 index a2b2762..08bd1c8 100755
 --- a/target/linux/ar71xx/base-files/etc/uci-defaults/02_network
 +++ b/target/linux/ar71xx/base-files/etc/uci-defaults/02_network
 @@ -378,6 +378,17 @@ wndr3700)
   uci set network.@switch_port[-1].led='2'
   ;;

 +esr900)
 + local wan_mac
 + local lan_mac
 + ucidef_set_interfaces_lan_wan eth0.1 eth0.2
 + ucidef_add_switch switch0 1 1
 + ucidef_add_switch_vlan switch0 1 0t 1 2 3 4
 + ucidef_add_switch_vlan switch0 2 0t 5
 + wan_mac=$(mtd_get_mac_ascii u-boot-env wanaddr)
 + [ -n $wan_mac ]  ucidef_set_interface_macaddr wan $wan_mac
 + ;;
 +
  *)
   ucidef_set_interfaces_lan_wan eth0 eth1
   ;;
 diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh
 b/target/linux/ar71xx/base-files/lib/ar71xx.sh
 index 6dd5e62..e346f97 100755
 --- a/target/linux/ar71xx/base-files/lib/ar71xx.sh
 +++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh
 @@ -676,6 +676,9 @@ ar71xx_board_detect() {
   *HiWiFi HC6361)
   name=hiwifi-hc6361
   ;;
 + *EnGenius ESR900)
 + name=esr900
 + ;;
   esac

   case $machine in
 diff --git a/target/linux/ar71xx/config-3.10 b/target/linux/ar71xx/config-3.10
 index c294cd8..78d5359 100644
 --- a/target/linux/ar71xx/config-3.10
 +++ b/target/linux/ar71xx/config-3.10
 @@ -47,6 +47,7 @@ CONFIG_ATH79_MACH_DIR_825_B1=y
  CONFIG_ATH79_MACH_DIR_825_C1=y
  CONFIG_ATH79_MACH_DRAGINO2=y
  CONFIG_ATH79_MACH_EAP7660D=y
 +CONFIG_ATH79_MACH_ESR900=y
  CONFIG_ATH79_MACH_EW_DORIN=y
  CONFIG_ATH79_MACH_GS_OOLITE=y
  CONFIG_ATH79_MACH_HORNET_UB=y
 diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-esr900.c
 b/target/linux/ar71xx/files/arch/mips/ath79/mach-esr900.c
 new file mode 100644
 index 000..64e590a
 --- /dev/null
 +++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-esr900.c
 @@ -0,0 +1,232 @@
 +/*
 + * EnGenius ESR900 board support
 + *
 + * Based on the Qualcomm Atheros AP135/AP136 reference board support code
 + * Copyright (c) 2012 Qualcomm Atheros
 + * Copyright (c) 2012-2013 Gabor Juhos juh...@openwrt.org
 + *
 + * Permission to use, copy, modify, and/or distribute this software for any
 + * purpose with or without fee is hereby 

Re: [OpenWrt-Devel] 转发：Re: [PATCH] [ar71xx] add support for Elink M-150/M-mini

[Hartmut Knaack]

黄方成 schrieb:
 Hi John,

 Please confirm that if the blew patch had fixed the white space problem.
 thanks!

No, there are still whitespace problems. Also when you patch 
target/linux/ar71xx/base-files/etc/uci-defaults/02_network, is there a specific 
reason to not reuse the existing 'ucidef_set_interface_lan eth0' around line 
250 for the el-mini? Everything else looks fine.
Take care

Hartmut
 patch:
 Index: target/linux/ar71xx/config-3.10
 ===
 --- target/linux/ar71xx/config-3.10(revision 40996)
 +++ target/linux/ar71xx/config-3.10(working copy)
 @@ -47,6 +47,8 @@
  CONFIG_ATH79_MACH_DIR_825_C1=y
  CONFIG_ATH79_MACH_DRAGINO2=y
  CONFIG_ATH79_MACH_EAP7660D=y
 +CONFIG_ATH79_MACH_EL_M150=y
 +CONFIG_ATH79_MACH_EL_MINI=y
  CONFIG_ATH79_MACH_EW_DORIN=y
  CONFIG_ATH79_MACH_GS_OOLITE=y
  CONFIG_ATH79_MACH_HORNET_UB=y
 Index: target/linux/ar71xx/base-files/lib/ar71xx.sh
 ===
 --- target/linux/ar71xx/base-files/lib/ar71xx.sh(revision 40996)
 +++ target/linux/ar71xx/base-files/lib/ar71xx.sh(working copy)
 @@ -91,6 +91,12 @@
  hwver=v${hwver#0}
  
  case $hwid in
 +015000*)
 +model=ELink EL-M150
 +;;
 +015300*)
 +model=ELink EL-MINI
 +;;
  3C0001*)
  model=OOLITE
  ;;
 @@ -307,6 +313,12 @@
  *EAP7660D)
  name=eap7660d
  ;;
 +*EL-M150)
 +name=el-m150
 +;;
 +*EL-MINI)
 +name=el-mini
 +;;
  *JA76PF)
  name=ja76pf
  ;;
 Index: target/linux/ar71xx/base-files/lib/upgrade/platform.sh
 ===
 --- target/linux/ar71xx/base-files/lib/upgrade/platform.sh(revision 40996)
 +++ target/linux/ar71xx/base-files/lib/upgrade/platform.sh(working copy)
 @@ -224,6 +224,8 @@
  ;;
  
  archer-c7 | \
 +el-m150 | \
 +el-mini | \
  oolite | \
  tl-mr10u | \
  tl-mr11u | \
 Index: 
 target/linux/ar71xx/base-files/etc/uci-defaults/03_network-switchX-migration
 ===
 --- 
 target/linux/ar71xx/base-files/etc/uci-defaults/03_network-switchX-migration  
   (revision 40996)
 +++ 
 target/linux/ar71xx/base-files/etc/uci-defaults/03_network-switchX-migration  
   (working copy)
 @@ -81,6 +81,7 @@
  migrate_switch_name eth0 switch0
  ;;
  
 +el-m150|\
  rb-450)
  migrate_switch_name eth1 switch0
  ;;
 Index: target/linux/ar71xx/base-files/etc/uci-defaults/02_network
 ===
 --- target/linux/ar71xx/base-files/etc/uci-defaults/02_network(revision 
 40996)
 +++ target/linux/ar71xx/base-files/etc/uci-defaults/02_network(working 
 copy)
 @@ -148,6 +148,16 @@
  ucidef_add_switch_vlan switch0 2 0t 2
  ;;

 +el-m150)
 +ucidef_set_interfaces_lan_wan eth1 eth0
 +ucidef_add_switch switch0 1 1
 +ucidef_add_switch_vlan switch0 1 0 1 3
 +;;
 +
 +el-mini)
 +ucidef_set_interface_lan eth0
 +;;
 +
  tl-wdr4300|\
  tl-wr1041n-v2)
  ucidef_set_interfaces_lan_wan eth0.1 eth0.2
 Index: target/linux/ar71xx/base-files/etc/diag.sh
 ===
 --- target/linux/ar71xx/base-files/etc/diag.sh(revision 40996)
 +++ target/linux/ar71xx/base-files/etc/diag.sh(working copy)
 @@ -65,6 +65,10 @@
  eap7660d)
  status_led=eap7660d:green:ds4
  ;;
 +el-m150 | \
 +el-mini)
 +status_led=elink:green:system
 +;;
  hiwifi-hc6361)
  status_led=hiwifi:blue:system
  ;;
 Index: target/linux/ar71xx/image/Makefile
 ===
 --- target/linux/ar71xx/image/Makefile(revision 40996)
 +++ target/linux/ar71xx/image/Makefile(working copy)
 @@ -1132,6 +1132,8 @@
  
  $(eval $(call 
 SingleProfile,TPLINK-LZMA,64kraw,ARCHERC7V1,archer-c7-v1,ARCHER-C7,ttyS0,115200,0x7501,1,8Mlzma))
  $(eval $(call 
 SingleProfile,TPLINK-LZMA,64kraw,ARCHERC7V2,archer-c7-v2,ARCHER-C7,ttyS0,115200,0xc702,1,16Mlzma))
 +$(eval $(call 
 SingleProfile,TPLINK-LZMA,64kraw,ELM150,el-m150,EL-M150,ttyATH0,115200,0x01500101,1,8Mlzma))
 +$(eval $(call 
 SingleProfile,TPLINK-LZMA,64kraw,ELMINI,el-mini,EL-MINI,ttyATH0,115200,0x01530001,1,8Mlzma))
  $(eval $(call 
 SingleProfile,TPLINK-LZMA,64kraw,TLMR10U,tl-mr10u-v1,TL-MR10U,ttyATH0,115200,0x00100101,1,4Mlzma))
  $(eval $(call 
 SingleProfile,TPLINK-LZMA,64kraw,TLMR11UV1,tl-mr11u-v1,TL-MR11U,ttyATH0,115200,0x00110101,1,4Mlzma))
  $(eval $(call 
 SingleProfile,TPLINK-LZMA,64kraw,TLMR11UV2,tl-mr11u-v2,TL-MR11U,ttyATH0,115200,0x00110102,1,4Mlzma))
 Index: target/linux/ar71xx/generic/profiles/easy-link.mk
 ===
 --- /dev/null
 +++ 

Re: [OpenWrt-Devel] [PATCH] add support for Elink EL-150

[Hartmut Knaack]

Larry Pinney schrieb:

 This patch adds support for the Elink EL-150.

 The Elink EL-150 is a Atheros AR9331 Module.

 http://item.taobao.com/item.htm?spm=a1z10.5.w4002-2498531248.10.ESiKXRid=16612265015

 Two Development Boards are available for this module.

 http://item.taobao.com/item.htm?spm=2013.1.0.0.7F5wOQid=25332812868scm=1007.10115.744.0pvid=9f4f22f6-8789-44a9-9811-dfb5ec530c64

 http://item.taobao.com/item.htm?spm=2013.1.0.0.7F5wOQid=20218043975scm=1007.10115.744.0pvid=9f4f22f6-8789-44a9-9811-dfb5ec530c64

 Signed-off-by: L. D. Pinney ldpin...@gmail.com mailto:ldpin...@gmail.com
3 days ago, the original patch author made an attempt to submit an improved 
version of the patch providing support for both, the M-150 and the M-mini. It 
seems, there were some problems in submitting to the list, although 
openwrt-devel@lists.openwrt.org was properly CC'ed. I would suggest to wait a 
bit longer for Fangcheng Huang to do a proper submission.

 -

 Index: target/linux/ar71xx/image/Makefile
 ===
 --- target/linux/ar71xx/image/Makefile
 +++ target/linux/ar71xx/image/Makefile
 @@ -1112,6 +1112,7 @@
  
  $(eval $(call 
 SingleProfile,TPLINK-LZMA,64kraw,ARCHERC7V1,archer-c7-v1,ARCHER-C7,ttyS0,115200,0x7501,1,8Mlzma))
  $(eval $(call 
 SingleProfile,TPLINK-LZMA,64kraw,ARCHERC7V2,archer-c7-v2,ARCHER-C7,ttyS0,115200,0xc702,1,16Mlzma))
 +$(eval $(call 
 SingleProfile,TPLINK-LZMA,64kraw,ELM150,el-m150,EL-M150,ttyATH0,115200,0x01500101,1,8Mlzma))
  $(eval $(call 
 SingleProfile,TPLINK-LZMA,64kraw,TLMR10U,tl-mr10u-v1,TL-MR10U,ttyATH0,115200,0x00100101,1,4Mlzma))
  $(eval $(call 
 SingleProfile,TPLINK-LZMA,64kraw,TLMR11UV1,tl-mr11u-v1,TL-MR11U,ttyATH0,115200,0x00110101,1,4Mlzma))
  $(eval $(call 
 SingleProfile,TPLINK-LZMA,64kraw,TLMR11UV2,tl-mr11u-v2,TL-MR11U,ttyATH0,115200,0x00110102,1,4Mlzma))
 Index: target/linux/ar71xx/config-3.10
 ===
 --- target/linux/ar71xx/config-3.10
 +++ target/linux/ar71xx/config-3.10
 @@ -47,6 +47,7 @@
  CONFIG_ATH79_MACH_DIR_825_C1=y
  CONFIG_ATH79_MACH_DRAGINO2=y
  CONFIG_ATH79_MACH_EAP7660D=y
 +CONFIG_ATH79_MACH_EL_M150=y
  CONFIG_ATH79_MACH_EW_DORIN=y
  CONFIG_ATH79_MACH_GS_OOLITE=y
  CONFIG_ATH79_MACH_HORNET_UB=y
 Index: target/linux/ar71xx/base-files/lib/ar71xx.sh
 ===
 --- target/linux/ar71xx/base-files/lib/ar71xx.sh
 +++ target/linux/ar71xx/base-files/lib/ar71xx.sh
 @@ -94,6 +94,9 @@
  3C0001*)
  model=OOLITE
  ;;
 +015000*)
 +model=ELink EL-M150
 +;;
  070300*)
  model=TP-Link TL-WR703N
  ;;
 @@ -298,6 +304,9 @@
  *EAP7660D)
  name=eap7660d
  ;;
 +*EL-M150)
 +name=el-m150
 +;;
  *JA76PF)
  name=ja76pf
  ;;
 Index: target/linux/ar71xx/base-files/lib/upgrade/platform.sh
 ===
 --- target/linux/ar71xx/base-files/lib/upgrade/platform.sh
 +++ target/linux/ar71xx/base-files/lib/upgrade/platform.sh
 @@ -220,6 +220,7 @@
  ;;
  
  archer-c7 | \
 +el-m150 | \
  oolite | \
  tl-mr10u | \
  tl-mr11u | \
 Index: 
 target/linux/ar71xx/base-files/etc/uci-defaults/03_network-switchX-migration
 ===
 --- 
 target/linux/ar71xx/base-files/etc/uci-defaults/03_network-switchX-migration
 +++ 
 target/linux/ar71xx/base-files/etc/uci-defaults/03_network-switchX-migration
 @@ -80,6 +80,7 @@
  migrate_switch_name eth0 switch0
  ;;
  
 +el-m150|\
  rb-450)
  migrate_switch_name eth1 switch0
  ;;
 Index: target/linux/ar71xx/base-files/etc/uci-defaults/02_network
 ===
 --- target/linux/ar71xx/base-files/etc/uci-defaults/02_network
 +++ target/linux/ar71xx/base-files/etc/uci-defaults/02_network
 @@ -148,6 +148,12 @@
  ucidef_add_switch_vlan switch0 2 0t 2
  ;;
  
 +el-m150)
 +ucidef_set_interfaces_lan_wan eth1 eth0
 +ucidef_add_switch switch0 1 1
 +ucidef_add_switch_vlan switch0 1 0 1 3
 +;;
 +
  tl-wdr4300|\
  tl-wr1041n-v2)
  ucidef_set_interfaces_lan_wan eth0.1 eth0.2
 Index: target/linux/ar71xx/base-files/etc/diag.sh
 ===
 --- target/linux/ar71xx/base-files/etc/diag.sh
 +++ target/linux/ar71xx/base-files/etc/diag.sh
 @@ -64,6 +64,9 @@
  eap7660d)
  status_led=eap7660d:green:ds4
  ;;
 +el-m150)
 +status_led=elink:green:system
 +;;
  hornet-ub)
  status_led=alfa:blue:wps
  ;;
 Index: target/linux/ar71xx/generic/profiles/easy-link.mk http://easy-link.mk
 ===
 --- /dev/null
 +++ target/linux/ar71xx/generic/profiles/easy-link.mk http://easy-link.mk
 @@ -0,0 +1,17 @@
 +#
 +# Copyright (C) 2009 OpenWrt.org
 +#
 +# This is free software, licensed under the GNU General Public License v2.
 +# See /LICENSE for more information.
 +#
 +
 

Re: [OpenWrt-Devel] [PATCH] [ar71xx] add support for Elink M-150/M-mini

[Hartmut Knaack]

`ōlunｘ schrieb:
 Hey guys,
   Here is a patch for adding Elink M-150/M-mini to OpenWrt.
 More infomation about Elink can be find below:
 M-150: 
 http://item.taobao.com/item.htm?spm=a1z10.5.w4002-2498531248.10.ESiKXRid=16612265015
 M-mini: 
 http://item.taobao.com/item.htm?spm=a1z10.5.w4002-2498531248.16.ESiKXRid=36485130954

 ---
 Signed-off-by: Fangcheng Huang huangfangch...@163.com
 Patch:
Hi, please make sure to have read the SubmittingPatches wiki entry: 
https://dev.openwrt.org/wiki/SubmittingPatches
Also, make sure your changes blend in as seamless as possible to existing code. 
Use a name scheme like el-m150 and el-mmini. Sort in your changes in alphabetic 
order. A few more comments below:
 Index: target/linux/ar71xx/base-files/etc/diag.sh
 ===
 --- target/linux/ar71xx/base-files/etc/diag.sh(Version 40773)
 +++ target/linux/ar71xx/base-files/etc/diag.sh(Working Copy)
 @@ -6,6 +6,9 @@
  
  get_status_led() {
   case $(ar71xx_board_name) in
 + EL-M150)
 + status_led=elink:green:system
 + ;;
   alfa-nx)
   status_led=alfa:green:led_8
   ;;
 Index: target/linux/ar71xx/base-files/etc/uci-defaults/02_network
 ===
 --- target/linux/ar71xx/base-files/etc/uci-defaults/02_network
 (Version 40773)
 +++ target/linux/ar71xx/base-files/etc/uci-defaults/02_network
 (Working Copy)
 @@ -22,6 +22,16 @@
   ucidef_set_interface_lan eth0 eth1
   ;;
  
 +M-mini)
 + ucidef_set_interfaces_lan_wan eth1 eth0
 + ;;
 +
This belongs between jwap003 and pb42. All other model names are lower-case, so 
use lower-case as well.

 +EL-M150)
 + ucidef_set_interfaces_lan_wan eth1 eth0
 + ucidef_add_switch switch0 1 1
 + ucidef_add_switch_vlan switch0 1 0 1 3
 + ;;
 +
  ap132 |\
  wlr8100)
   ucidef_set_interfaces_lan_wan eth0.1 eth0.2
 Index: 
 target/linux/ar71xx/base-files/etc/uci-defaults/03_network-switchX-migration
 ===
 --- 
 target/linux/ar71xx/base-files/etc/uci-defaults/03_network-switchX-migration  
 (Version 40773)
 +++ 
 target/linux/ar71xx/base-files/etc/uci-defaults/03_network-switchX-migration  
 (Working Copy)
 @@ -80,6 +80,7 @@
   migrate_switch_name eth0 switch0
   ;;
  
 +EL-M150|\
  rb-450)
   migrate_switch_name eth1 switch0
   ;;
 Index: target/linux/ar71xx/base-files/lib/ar71xx.sh
 ===
 --- target/linux/ar71xx/base-files/lib/ar71xx.sh  (Version 40773)
 +++ target/linux/ar71xx/base-files/lib/ar71xx.sh  (Working Copy)
 @@ -91,6 +91,12 @@
   hwver=v${hwver#0}
  
   case $hwid in
 + 015000*)
 + model=ELink EL-M150
 + ;;
 + 015300*)
 + model=ELink M-mini
 + ;;
   3C0001*)
   model=OOLITE
   ;;
 @@ -211,6 +217,12 @@
   machine=$(awk 'BEGIN{FS=[ \t]+:[ \t]} /machine/ {print $2}' 
 /proc/cpuinfo)
  
   case $machine in
 + *EL-M150)
 + name=EL-M150
 + ;;
 + *M-mini)
 + name=M-mini
 + ;;
   *Oolite V1.0)
   name=oolite
   ;;
 Index: target/linux/ar71xx/base-files/lib/upgrade/platform.sh
 ===
 --- target/linux/ar71xx/base-files/lib/upgrade/platform.sh(Version 40773)
 +++ target/linux/ar71xx/base-files/lib/upgrade/platform.sh(Working Copy)
 @@ -219,6 +219,8 @@
   return 1
   ;;
  
 + EL-M150 | \
 + M-mini | \
Sort alphabetically.

   archer-c7 | \
   oolite | \
   tl-mr10u | \
 Index: target/linux/ar71xx/config-3.10
 ===
 --- target/linux/ar71xx/config-3.10   (Version 40773)
 +++ target/linux/ar71xx/config-3.10   (Working Copy)
 @@ -47,6 +47,7 @@
  CONFIG_ATH79_MACH_DIR_825_C1=y
  CONFIG_ATH79_MACH_DRAGINO2=y
  CONFIG_ATH79_MACH_EAP7660D=y
 +CONFIG_ATH79_MACH_EL_M150=y
  CONFIG_ATH79_MACH_EW_DORIN=y
  CONFIG_ATH79_MACH_GS_OOLITE=y
  CONFIG_ATH79_MACH_HORNET_UB=y
 @@ -58,6 +59,7 @@
  CONFIG_ATH79_MACH_MYNET_REXT=y
  CONFIG_ATH79_MACH_MZK_W04NU=y
  CONFIG_ATH79_MACH_MZK_W300NH=y
 +CONFIG_ATH79_MACH_M_mini=y
  CONFIG_ATH79_MACH_NBG460N=y
  CONFIG_ATH79_MACH_NBG6716=y
  CONFIG_ATH79_MACH_OM2P=y
 Index: target/linux/ar71xx/files/arch/mips/ath79/mach-el-m150.c
 ===
 --- target/linux/ar71xx/files/arch/mips/ath79/mach-el-m150.c  (Version 0)
 +++ target/linux/ar71xx/files/arch/mips/ath79/mach-el-m150.c  (Working Copy)
 @@ -0,0 +1,138 @@
 +/*
 + *  ELINK EL-M150 board support
 + *
 + *  Copyright (C) 2012 HYS 550663...@qq.com
 + *  

Re: [OpenWrt-Devel] [PATCH] ramips: Support for Teltonika RUT5XX

[Hartmut Knaack]

Steve Weinreich schrieb:
 Added support for Teltonika RUT5XX hardware.

 Signed-off-by: Steffen Weinreich st...@weinreich.org
Please don't mess up alphabetic order more than it already is. Pointed out 
below:
 ---
  target/linux/ramips/base-files/etc/diag.sh |  3 +
  .../etc/hotplug.d/firmware/10-rt2x00-eeprom|  1 +
  target/linux/ramips/base-files/lib/ramips.sh   |  3 +
  .../ramips/base-files/lib/upgrade/platform.sh  |  1 +
  target/linux/ramips/dts/RUT5XX.dts | 86 
 ++
  target/linux/ramips/image/Makefile |  3 +
  6 files changed, 97 insertions(+)
  create mode 100644 target/linux/ramips/dts/RUT5XX.dts

 diff --git a/target/linux/ramips/base-files/etc/diag.sh 
 b/target/linux/ramips/base-files/etc/diag.sh
 index 075562a..ad9bbd7 100755
 --- a/target/linux/ramips/base-files/etc/diag.sh
 +++ b/target/linux/ramips/base-files/etc/diag.sh
 @@ -170,6 +170,9 @@ get_status_led() {
   na930)
   status_led=na930:blue:power
   ;;
 + rut5xx)
 + status_led=rut5xx:green:status
 + ;;
   esac
  }
  
 diff --git 
 a/target/linux/ramips/base-files/etc/hotplug.d/firmware/10-rt2x00-eeprom 
 b/target/linux/ramips/base-files/etc/hotplug.d/firmware/10-rt2x00-eeprom
 index 341fd5f..dd8c0f7 100644
 --- a/target/linux/ramips/base-files/etc/hotplug.d/firmware/10-rt2x00-eeprom
 +++ b/target/linux/ramips/base-files/etc/hotplug.d/firmware/10-rt2x00-eeprom
 @@ -119,6 +119,7 @@ case $FIRMWARE in
   ur-326n4g | \
   ur-336un | \
   xdxrn502j | \
 + rut5xx | \
Here.
   hg255d)
   rt2x00_eeprom_extract factory 0 512
   ;;
 diff --git a/target/linux/ramips/base-files/lib/ramips.sh 
 b/target/linux/ramips/base-files/lib/ramips.sh
 index 7f221f8..4619bef 100755
 --- a/target/linux/ramips/base-files/lib/ramips.sh
 +++ b/target/linux/ramips/base-files/lib/ramips.sh
 @@ -211,6 +211,9 @@ ramips_board_detect() {
   *RT-N56U)
   name=rt-n56u
   ;;
 + *RUT5XX)
 + name=rut5xx
 + ;;
   *Skyline SL-R7205*)
   name=sl-r7205
   ;;
 diff --git a/target/linux/ramips/base-files/lib/upgrade/platform.sh 
 b/target/linux/ramips/base-files/lib/upgrade/platform.sh
 index d8098b2..c85ee0f 100755
 --- a/target/linux/ramips/base-files/lib/upgrade/platform.sh
 +++ b/target/linux/ramips/base-files/lib/upgrade/platform.sh
 @@ -69,6 +69,7 @@ platform_check_image() {
   rt-n14u | \
   rt-n15 | \
   rt-n56u | \
 + rut5xx | \
   sl-r7205 | \
   tew-691gr | \
   tew-692gr | \
 diff --git a/target/linux/ramips/dts/RUT5XX.dts 
 b/target/linux/ramips/dts/RUT5XX.dts
 new file mode 100644
 index 000..530b8b1
 --- /dev/null
 +++ b/target/linux/ramips/dts/RUT5XX.dts
 @@ -0,0 +1,86 @@
 +/dts-v1/;
 +
 +/include/ rt3050.dtsi
 +
 +/ {
 + compatible = RUT5XX, ralink,rt3050-soc;
 + model = Teltonika RUT5XX;
 +
 + palmbus@1000 {
 + spi@b00 {
 + status = okay;
 + m25p80@0 {
 + #address-cells = 1;
 + #size-cells = 1;
 + compatible = n25q128a13;
 + reg = 0 0;
 + linux,modalias = m25p80, n25q128a13;
 + spi-max-frequency = 1000;
 +
 + partition@0 {
 + label = u-boot;
 + reg = 0x0 0x3;
 + read-only;
 + };
 +
 + partition@3 {
 + label = u-boot-env;
 + reg = 0x3 0x1;
 + read-only;
 + };
 +
 + factory: partition@4 {
 + label = factory;
 + reg = 0x4 0x1;
 + read-only;
 + };
 +
 + partition@5 {
 + label = firmware;
 + reg = 0x5 0xfb;
 + };
 + };
 + };
 + };
 +
 + pinctrl {
 + state_default: pinctrl0 {
 + gpio {
 + ralink,group = i2c, jtag, rgmii, mdio, 
 uartf;
 + ralink,function = gpio;
 + };
 + };
 + };
 +
 +ethernet@1010 {
 +mtd-mac-address = factory 0x28;
 +};
 +
 + esw@1011 {
 + ralink,portmap = 0x3e;
 + };
 +
 + gpio-leds {
 + compatible = gpio-leds;
 + status {
 + 

Re: [OpenWrt-Devel] [PATCH] [ramips] Add support for samsung cy-swr1100 wireless router

[Hartmut Knaack]

michael lee schrieb:
 It is base on rt3662 soc with dual band 802.11n
 wireless router. Use rtl8367R switch chip.
 This patch adds a profile for this board.
 It use seama image header. so i also enable it
 on kernel config.

 Signed-off-by: michael lee igv...@gmail.com
Sadly, there is already some mess, but please don't make it worse and mind 
alphabetic order. Some obvious areas pointed out below:
 ---
  target/linux/ramips/base-files/etc/diag.sh |   3 +
  .../etc/hotplug.d/firmware/10-rt2x00-eeprom|   4 +
  .../ramips/base-files/etc/uci-defaults/01_leds |   4 +
  .../ramips/base-files/etc/uci-defaults/02_network  |   8 ++
  .../etc/uci-defaults/09_fix-seama-header   |   1 +
  .../ramips/base-files/lib/preinit/06_set_iface_mac |   1 +
  target/linux/ramips/base-files/lib/ramips.sh   |   3 +
  .../ramips/base-files/lib/upgrade/platform.sh  |   1 +
  target/linux/ramips/dts/CY-SWR1100.dts | 135 
 +
  target/linux/ramips/image/Makefile |   3 +
  target/linux/ramips/rt3883/config-3.10 |   1 +
  target/linux/ramips/rt3883/profiles/samsung.mk |  16 +++
  12 files changed, 180 insertions(+)
  create mode 100644 target/linux/ramips/dts/CY-SWR1100.dts
  create mode 100644 target/linux/ramips/rt3883/profiles/samsung.mk

 diff --git a/target/linux/ramips/base-files/etc/diag.sh 
 b/target/linux/ramips/base-files/etc/diag.sh
 index 075562a..e120d42 100755
 --- a/target/linux/ramips/base-files/etc/diag.sh
 +++ b/target/linux/ramips/base-files/etc/diag.sh
 @@ -36,6 +36,9 @@ get_status_led() {
   dir-645)
   status_led=d-link:green:wps
   ;;
 + cy-swr1100)
 + status_led=samsung:blue:wps
 + ;;
Don't know how dap got below dir, but please move yours up.
   dap-1350)
   status_led=d-link:blue:power
   ;;
 diff --git 
 a/target/linux/ramips/base-files/etc/hotplug.d/firmware/10-rt2x00-eeprom 
 b/target/linux/ramips/base-files/etc/hotplug.d/firmware/10-rt2x00-eeprom
 index 341fd5f..5bda7a9 100644
 --- a/target/linux/ramips/base-files/etc/hotplug.d/firmware/10-rt2x00-eeprom
 +++ b/target/linux/ramips/base-files/etc/hotplug.d/firmware/10-rt2x00-eeprom
 @@ -78,6 +78,7 @@ case $FIRMWARE in
   dir-620-a1 | \
   dir-620-d1 | \
   dir-645 | \
 + cy-swr1100 | \
Here as well.
   esr-9753 | \
   f7c027 | \
   fonera20n | \
 @@ -135,6 +136,9 @@ case $FIRMWARE in
  
  rt2x00pci_1_0.eeprom)
   case $board in
 + cy-swr1100)
 + rt2x00_eeprom_extract factory 8192 512
 + ;;
   rt-n56u | whr-600d)
   rt2x00_eeprom_extract factory 32768 512
   ;;
 diff --git a/target/linux/ramips/base-files/etc/uci-defaults/01_leds 
 b/target/linux/ramips/base-files/etc/uci-defaults/01_leds
 index 74ba0ba..1e2683f 100755
 --- a/target/linux/ramips/base-files/etc/uci-defaults/01_leds
 +++ b/target/linux/ramips/base-files/etc/uci-defaults/01_leds
 @@ -173,6 +173,10 @@ case $board in
   ucidef_set_led_default power power buffalo:green:power 1
   ucidef_set_led_default router router buffalo:green:router 
 1
   ;;
 + cy-swr1100)
 + ucidef_set_led_default wps WPS samsung:blue:wps 0
 + set_usb_led samsung:blue:usb
 + ;;
  esac
  
  ucidef_commit_leds
 diff --git a/target/linux/ramips/base-files/etc/uci-defaults/02_network 
 b/target/linux/ramips/base-files/etc/uci-defaults/02_network
 index b66d176..b9524f6 100755
 --- a/target/linux/ramips/base-files/etc/uci-defaults/02_network
 +++ b/target/linux/ramips/base-files/etc/uci-defaults/02_network
 @@ -78,6 +78,13 @@ ramips_setup_interfaces()
   ucidef_add_switch_vlan switch0 1 1 2 3 4 6t
   ;;
  
 + cy-swr1100)
 + ucidef_set_interfaces_lan_wan eth0.1 eth0.2
 + ucidef_add_switch switch0 1 1
 + ucidef_add_switch_vlan switch0 1 0 1 2 3 9t
 + ucidef_add_switch_vlan switch0 2 4 9t
 + ;;
 +
   dir-610-a1 | \
   dir-300-b7 | \
   dir-320-b1 | \
 @@ -205,6 +212,7 @@ ramips_setup_macs()
   wan_mac=$(macaddr_add $lan_mac 1)
   ;;
  
 + cy-swr1100 | \
   dir-645)
   lan_mac=$(mtd_get_mac_ascii nvram lanmac)
   wan_mac=$(mtd_get_mac_ascii nvram wanmac)
 diff --git 
 a/target/linux/ramips/base-files/etc/uci-defaults/09_fix-seama-header 
 b/target/linux/ramips/base-files/etc/uci-defaults/09_fix-seama-header
 index d8bed79..a6c392c 100755
 --- a/target/linux/ramips/base-files/etc/uci-defaults/09_fix-seama-header
 +++ b/target/linux/ramips/base-files/etc/uci-defaults/09_fix-seama-header
 @@ -14,6 +14,7 @@ fix_seama_header() {
  board=$(ramips_board_name)
  
  case $board in
 +cy-swr1100 | \
  dir-645)
   fix_seama_header kernel
   ;;
 diff --git a/target/linux/ramips/base-files/lib/preinit/06_set_iface_mac 
 

Re: [OpenWrt-Devel] [PATCH 01/30][ WRT1900AC] Add Linksys Mamba WRT1900AC build profile

[Hartmut Knaack]

Hi Matt,
sorry to say that, but probably your mail client mangled all your mails, so 
tabs got changed to whitespaces. So, you need to resend. This resource [1] is 
quite helpful to solve this issue. Also, it might help to send some test-mail 
to yourself to see and check how your client submits your mails.
A nice to have would be to make your mails form a thread (with an introduction 
mail [PATCH 00/30]).
Good luck!

Matthew Fatheree schrieb:
 From 82a697fdd09beb673d94ed197ea1dd527b070cae Mon Sep 17 00:00:00 2001
 From: Matthew Fatheree matthew.fathe...@belkin.com
 Date: Sat, 3 May 2014 22:59:46 +0700
 Subject: [PATCH 01/30] Add Linksys Mamba WRT1900AC build profile

 Add Linksys Mamba WRT1900AC build profile to target/linux/mvebu
 Signed-off-by: Matthew Fatheree matthew.fathe...@belkin.com
 ---
  target/linux/mvebu/profiles/101-Linksys-Mamba.mk |   21 +
  1 file changed, 21 insertions(+)
  create mode 100644 target/linux/mvebu/profiles/101-Linksys-Mamba.mk

 diff --git a/target/linux/mvebu/profiles/101-Linksys-Mamba.mk 
 b/target/linux/mvebu/profiles/101-Linksys-Mamba.mk
 new file mode 100644
 index 000..de048a6
 --- /dev/null
 +++ b/target/linux/mvebu/profiles/101-Linksys-Mamba.mk
 @@ -0,0 +1,21 @@
 +#
 +# Copyright (C) 2013 OpenWrt.org
 +#
 +# This is free software, licensed under the GNU General Public License v2.
 +# See /LICENSE for more information.
 +#
 +
 +define Profile/Mamba
 +  NAME:=Linksys Mamba
 +  PACKAGES:= \
 +   kmod-usb-storage \
 +   kmod-of-i2c kmod-i2c-core kmod-i2c-mv64xxx \
 +   kmod-ata-core kmod-ata-marvell-sata \
 +   kmod-rtc-marvell kmod-thermal-armada
 +endef
 +
 +define Profile/Mamba/Description
 + Package set compatible with Linksys Mamba board (WRT1900AC board.)
 +endef
 +
 +$(eval $(call Profile,Mamba))
 --
 1.7.9.5




 __ 
 Confidential This e-mail and any files transmitted with it are the property 
 of Belkin International, Inc. and/or its affiliates, are confidential, and 
 are intended solely for the use of the individual or entity to whom this 
 e-mail is addressed. If you are not one of the named recipients or otherwise 
 have reason to believe that you have received this e-mail in error, please 
 notify the sender and delete this message immediately from your computer. Any 
 other use, retention, dissemination, forwarding, printing or copying of this 
 e-mail is strictly prohibited. Pour la version française: 
 http://www.belkin.com/email-notice/French.html Für die deutsche Übersetzung: 
 http://www.belkin.com/email-notice/German.html 
 __
 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 01/30][ WRT1900AC] Add Linksys Mamba WRT1900AC build profile

[Hartmut Knaack]

Hartmut Knaack schrieb:
 Hi Matt,
 sorry to say that, but probably your mail client mangled all your mails, so 
 tabs got changed to whitespaces. So, you need to resend. This resource [1] is 
 quite helpful to solve this issue. Also, it might help to send some test-mail 
 to yourself to see and check how your client submits your mails.
 A nice to have would be to make your mails form a thread (with an 
 introduction mail [PATCH 00/30]).
 Good luck!
Nobody is perfect.
[1] http://kerneltrap.org/Linux/Email_Clients_and_Patches

 Matthew Fatheree schrieb:
 From 82a697fdd09beb673d94ed197ea1dd527b070cae Mon Sep 17 00:00:00 2001
 From: Matthew Fatheree matthew.fathe...@belkin.com
 Date: Sat, 3 May 2014 22:59:46 +0700
 Subject: [PATCH 01/30] Add Linksys Mamba WRT1900AC build profile

 Add Linksys Mamba WRT1900AC build profile to target/linux/mvebu
 Signed-off-by: Matthew Fatheree matthew.fathe...@belkin.com
 ---
  target/linux/mvebu/profiles/101-Linksys-Mamba.mk |   21 
 +
  1 file changed, 21 insertions(+)
  create mode 100644 target/linux/mvebu/profiles/101-Linksys-Mamba.mk

 diff --git a/target/linux/mvebu/profiles/101-Linksys-Mamba.mk 
 b/target/linux/mvebu/profiles/101-Linksys-Mamba.mk
 new file mode 100644
 index 000..de048a6
 --- /dev/null
 +++ b/target/linux/mvebu/profiles/101-Linksys-Mamba.mk
 @@ -0,0 +1,21 @@
 +#
 +# Copyright (C) 2013 OpenWrt.org
 +#
 +# This is free software, licensed under the GNU General Public License v2.
 +# See /LICENSE for more information.
 +#
 +
 +define Profile/Mamba
 +  NAME:=Linksys Mamba
 +  PACKAGES:= \
 +   kmod-usb-storage \
 +   kmod-of-i2c kmod-i2c-core kmod-i2c-mv64xxx \
 +   kmod-ata-core kmod-ata-marvell-sata \
 +   kmod-rtc-marvell kmod-thermal-armada
 +endef
 +
 +define Profile/Mamba/Description
 + Package set compatible with Linksys Mamba board (WRT1900AC board.)
 +endef
 +
 +$(eval $(call Profile,Mamba))
 --
 1.7.9.5




 __ 
 Confidential This e-mail and any files transmitted with it are the property 
 of Belkin International, Inc. and/or its affiliates, are confidential, and 
 are intended solely for the use of the individual or entity to whom this 
 e-mail is addressed. If you are not one of the named recipients or otherwise 
 have reason to believe that you have received this e-mail in error, please 
 notify the sender and delete this message immediately from your computer. 
 Any other use, retention, dissemination, forwarding, printing or copying of 
 this e-mail is strictly prohibited. Pour la version française: 
 http://www.belkin.com/email-notice/French.html Für die deutsche Übersetzung: 
 http://www.belkin.com/email-notice/German.html 
 __
 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] PATCH: add support for GL-Inet V1 boards/routers (take 3)

[Hartmut Knaack]

Michel Stempin schrieb:

 Le 30/04/2014 23:48, Hartmut Knaack a écrit :
 maniac...@gmail.com schrieb:
 Hello,

 I didn't get ANY response on my previous version... here it is again.
 Please apply this patch to add support for the GL-iNet devices.

 I've updated a patch, available at
 https://github.com/alzhao/Openwrt-patches-for-GL.iNet/blob/master/001-gl-38300.patch
  

 The patch (also at https://dev.openwrt.org/ticket/15632 ) includes
 support for the GL-Inet V1 devices. Which are mostly compatible with the
 TP-Link WR-703N boards.

 The devices have 64M ram, 16M flash and 2 ethernet interfaces.

 The original patch was written by alzhao alz...@gmail.com although as
 far as I can see he never bothered to get this patch included in the
 mainline.

 I currently have 20+ of these routers, so I would appreciate it if this
 patch was included into the mainline, as that would make life easier
 here.

 The patch adds the following files:
 target/linux/ar71xx/files/arch/mips/ath79/mach-gl-inet.c
 target/linux/ar71xx/generic/profiles/gl-connect.mk
 target/linux/ar71xx/patches-3.10/911-MIPS-ath79-gl-machine.patch

 And adds a few lines to the following:
 tools/firmware-utils/src/mktplinkfw.c
 target/linux/ar71xx/config-3.10
 target/linux/ar71xx/base-files/lib/upgrade/platform.sh
 target/linux/ar71xx/base-files/lib/ar71xx.sh
 target/linux/ar71xx/base-files/etc/uci-defaults/02_network

 On second thought, why don't you completely rewrite the patches? The biggest 
 bunch seems to be the mach-gl-inet.c, which I think may be the wrong 
 attempt. Since it is almost the same as the mach-tl-wr703n.c (only different 
 LED-definition), just add the pieces for your board.
 See my attempt in a separate submission. For one reason, my MTA did not catch 
 the parent message ID.

 You can't easily, because there are 2 LEDs vs. a single one (and not with the 
 same prefix), and no GPIO to control the USB power, so this would add many 
 specific structures and tests or init functions to the mach-tl-wr703n.c file.

 It has not been done for the existing TL-MR3020 or GS-Oolite routers for 
 example, which are nevertheless TL-WR703N sister boards, probably not to 
 bloat the installed kernel with unrelated dead code/data.

 Otherwise, be prepared for consistency's sake to merge at least all related 
 mach-tl-mr*.c, mach-tl-wa*.c, mach-tl-wr*.c, etc.

 Time for a cleanup? I spotted some unordered boards into the target Bash 
 scripts too.
Good points, and the further I peek into it, the more mess I discover. But I 
don't have the time atm to do some cleanup.
 I myself do not claim any copyright on this, as I only rebased the
 patch. The original copyright statement included is/was:

 /*
 *  GL-CONNECT iNet board support
 *
 *  Copyright (C) 2011 dongyuqi 729650...@qq.com
 *  Copyright (C) 2011-2012 Gabor Juhos juh...@openwrt.org
 *  Copyright (C) 2013 alzhao alz...@gmail.com
 *
 *  This program is free software; you can redistribute it and/or modify it
 *  under the terms of the GNU General Public License version 2 as published
 *  by the Free Software Foundation.
 */

 Signed-off-by: Mark Janssen m...@sig-io.nl
 Signed-off-by: alzhao alz...@gmail.com


 -- patch --

 diff --git a/target/linux/ar71xx/base-files/etc/uci-defaults/02_network 
 b/target/linux/ar71xx/base-files/etc/uci-defaults/02_network
 index 62373e4..ff6d4d7 100755
 --- a/target/linux/ar71xx/base-files/etc/uci-defaults/02_network
 +++ b/target/linux/ar71xx/base-files/etc/uci-defaults/02_network
 @@ -268,6 +268,10 @@ dir-505-a1)
 ucidef_set_interface_lan eth1
 ;;
  
 +gl-inet)
 +   ucidef_set_interfaces_lan_wan eth1 eth0
 +   ;;
 +
 Wrong attempt. The section below does the same, so just merge your board 
 name in, at the right alphabetic position.
  alfa-ap96 |\
  alfa-nx |\
  ap83 |\
 diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh 
 b/target/linux/ar71xx/base-files/lib/ar71xx.sh
 index 02c46f9..9099f45 100755
 --- a/target/linux/ar71xx/base-files/lib/ar71xx.sh
 +++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh
 @@ -214,6 +214,9 @@ ar71xx_board_detect() {
 *Oolite V1.0)
 name=oolite
 ;;
 +   *GL-CONNECT INET v1)
 +   name=gl-inet
 +   ;;
 *AirRouter)
 name=airrouter
 ;;
 diff --git a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh 
 b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
 index 37ceea6..4760cd8 100755
 --- a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
 +++ b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
 @@ -242,6 +242,7 @@ platform_check_image() {
 tl-wdr4300 | \
 tl-wdr4900-v2 | \
 tl-wr703n | \
 +   gl-inet | \
 tl-wr710n | \
 tl-wr720n-v3 | \
 tl-wr741nd | \
 diff --git a/target/linux/ar71xx/config-3.10 
 b/target/linux/ar71xx/config-3.10
 index 4eb4b9f..f448f9d 100644
 --- a/target/linux/ar71xx/config-3.10
 +++ b/target/linux/ar71xx/config-3.10
 @@ -88,6

Re: [OpenWrt-Devel] PATCH: add support for GL-Inet V1 boards/routers (take 3)

[Hartmut Knaack]

maniac...@gmail.com schrieb:
 Hello,

 I didn't get ANY response on my previous version... here it is again.
 Please apply this patch to add support for the GL-iNet devices.

 I've updated a patch, available at
 https://github.com/alzhao/Openwrt-patches-for-GL.iNet/blob/master/001-gl-38300.patch
  

 The patch (also at https://dev.openwrt.org/ticket/15632 ) includes
 support for the GL-Inet V1 devices. Which are mostly compatible with the
 TP-Link WR-703N boards.

 The devices have 64M ram, 16M flash and 2 ethernet interfaces.

 The original patch was written by alzhao alz...@gmail.com although as
 far as I can see he never bothered to get this patch included in the
 mainline.

 I currently have 20+ of these routers, so I would appreciate it if this
 patch was included into the mainline, as that would make life easier
 here.

 The patch adds the following files:
 target/linux/ar71xx/files/arch/mips/ath79/mach-gl-inet.c
 target/linux/ar71xx/generic/profiles/gl-connect.mk
 target/linux/ar71xx/patches-3.10/911-MIPS-ath79-gl-machine.patch

 And adds a few lines to the following:
 tools/firmware-utils/src/mktplinkfw.c
 target/linux/ar71xx/config-3.10
 target/linux/ar71xx/base-files/lib/upgrade/platform.sh
 target/linux/ar71xx/base-files/lib/ar71xx.sh
 target/linux/ar71xx/base-files/etc/uci-defaults/02_network

On second thought, why don't you completely rewrite the patches? The biggest 
bunch seems to be the mach-gl-inet.c, which I think may be the wrong attempt. 
Since it is almost the same as the mach-tl-wr703n.c (only different 
LED-definition), just add the pieces for your board.

 I myself do not claim any copyright on this, as I only rebased the
 patch. The original copyright statement included is/was:

 /*
 *  GL-CONNECT iNet board support
 *
 *  Copyright (C) 2011 dongyuqi 729650...@qq.com
 *  Copyright (C) 2011-2012 Gabor Juhos juh...@openwrt.org
 *  Copyright (C) 2013 alzhao alz...@gmail.com
 *
 *  This program is free software; you can redistribute it and/or modify it
 *  under the terms of the GNU General Public License version 2 as published
 *  by the Free Software Foundation.
 */

 Signed-off-by: Mark Janssen m...@sig-io.nl
 Signed-off-by: alzhao alz...@gmail.com


 -- patch --

 diff --git a/target/linux/ar71xx/base-files/etc/uci-defaults/02_network 
 b/target/linux/ar71xx/base-files/etc/uci-defaults/02_network
 index 62373e4..ff6d4d7 100755
 --- a/target/linux/ar71xx/base-files/etc/uci-defaults/02_network
 +++ b/target/linux/ar71xx/base-files/etc/uci-defaults/02_network
 @@ -268,6 +268,10 @@ dir-505-a1)
   ucidef_set_interface_lan eth1
   ;;
  
 +gl-inet)
 + ucidef_set_interfaces_lan_wan eth1 eth0
 + ;;
 +
Wrong attempt. The section below does the same, so just merge your board name 
in, at the right alphabetic position.
  alfa-ap96 |\
  alfa-nx |\
  ap83 |\
 diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh 
 b/target/linux/ar71xx/base-files/lib/ar71xx.sh
 index 02c46f9..9099f45 100755
 --- a/target/linux/ar71xx/base-files/lib/ar71xx.sh
 +++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh
 @@ -214,6 +214,9 @@ ar71xx_board_detect() {
   *Oolite V1.0)
   name=oolite
   ;;
 + *GL-CONNECT INET v1)
 + name=gl-inet
 + ;;
   *AirRouter)
   name=airrouter
   ;;
 diff --git a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh 
 b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
 index 37ceea6..4760cd8 100755
 --- a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
 +++ b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
 @@ -242,6 +242,7 @@ platform_check_image() {
   tl-wdr4300 | \
   tl-wdr4900-v2 | \
   tl-wr703n | \
 + gl-inet | \
   tl-wr710n | \
   tl-wr720n-v3 | \
   tl-wr741nd | \
 diff --git a/target/linux/ar71xx/config-3.10 b/target/linux/ar71xx/config-3.10
 index 4eb4b9f..f448f9d 100644
 --- a/target/linux/ar71xx/config-3.10
 +++ b/target/linux/ar71xx/config-3.10
 @@ -88,6 +88,7 @@ CONFIG_ATH79_MACH_TL_WR1043ND=y
  CONFIG_ATH79_MACH_TL_WR1043ND_V2=y
  CONFIG_ATH79_MACH_TL_WR2543N=y
  CONFIG_ATH79_MACH_TL_WR703N=y
 +CONFIG_ATH79_MACH_GL_INET=y
  CONFIG_ATH79_MACH_TL_WR720N_V3=y
  CONFIG_ATH79_MACH_TL_WR741ND=y
  CONFIG_ATH79_MACH_TL_WR741ND_V4=y
 diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-gl-inet.c 
 b/target/linux/ar71xx/files/arch/mips/ath79/mach-gl-inet.c
 new file mode 100644
 index 000..0908918
 --- /dev/null
 +++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-gl-inet.c
 @@ -0,0 +1,106 @@
 +/*
 + *  GL-CONNECT iNet board support
 + *
 + *  Copyright (C) 2011 dongyuqi 729650...@qq.com
 + *  Copyright (C) 2011-2012 Gabor Juhos juh...@openwrt.org
 + *  Copyright (C) 2013 alzhao alz...@gmail.com
 + *
 + *  This program is free software; you can redistribute it and/or modify it
 + *  under the terms of the GNU General Public License version 2 as published
 + *  by 

Re: [OpenWrt-Devel] [PATCH] add support for GL-Inet V1 boards/routers

[Hartmut Knaack]

Michel Stempin schrieb:
 The GL-Connect GL.iNet v1 router is basically a TP-Link TL-WR703N with
 more DRAM/Flash, 2x Ethernet ports and console/GPIO header in the same
 small form-factor:
 http://www.gl-inet.com/w/?lang=en

 Moreover, the manufacturer is promoting the OpenWrt usage to replace
 the original firmware and proposing patches against both AA and trunk:
 http://www.gl-inet.com/w/?p=398lang=en

 This is a clean up of the original manufacturer GPLv2 patch by alzhao,
 proposed to the list by Mark Janssen.

 Signed-off-by: Michel Stempin michel.stem...@wanadoo.fr
 Signed-off-by: Mark Janssen m...@sig-io.nl
 Signed-off-by: alzhao alz...@gmail.com
 ---
  .../ar71xx/base-files/etc/uci-defaults/02_network  |1 +
  target/linux/ar71xx/base-files/lib/ar71xx.sh   |3 +
  .../ar71xx/base-files/lib/upgrade/platform.sh  |1 +
  target/linux/ar71xx/config-3.10|1 +
  .../ar71xx/files/arch/mips/ath79/mach-gl-inet.c|  109 
 
  target/linux/ar71xx/generic/profiles/gl-connect.mk |   17 +++
  target/linux/ar71xx/image/Makefile |2 +
  .../710-MIPS-ath79-add-gl-inet-v1-support.patch|   39 +++
  tools/firmware-utils/src/mktplinkfw.c  |6 ++
  9 files changed, 179 insertions(+)
Looks already way cleaner than the original. But as I pointed out on my second 
review on the other thread, the 710-MIPS*.patch should not be created, but 
instead the already existing 610-MIPS*.patch extended by the new board infos. 
Also, it might be a better idea to extend mach-tl-wr703n.c with the different 
LED configuration rather than adding an almost complete duplicate file.
  create mode 100644 target/linux/ar71xx/files/arch/mips/ath79/mach-gl-inet.c
  create mode 100644 target/linux/ar71xx/generic/profiles/gl-connect.mk
  create mode 100644 
 target/linux/ar71xx/patches-3.10/710-MIPS-ath79-add-gl-inet-v1-support.patch

 diff --git a/target/linux/ar71xx/base-files/etc/uci-defaults/02_network 
 b/target/linux/ar71xx/base-files/etc/uci-defaults/02_network
 index 62373e4..cf2b494 100755
 --- a/target/linux/ar71xx/base-files/etc/uci-defaults/02_network
 +++ b/target/linux/ar71xx/base-files/etc/uci-defaults/02_network
 @@ -271,6 +271,7 @@ dir-505-a1)
  alfa-ap96 |\
  alfa-nx |\
  ap83 |\
 +gl-inet |\
  jwap003 |\
  pb42 |\
  pb44 |\
 diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh 
 b/target/linux/ar71xx/base-files/lib/ar71xx.sh
 index 02c46f9..fd5d8b9 100755
 --- a/target/linux/ar71xx/base-files/lib/ar71xx.sh
 +++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh
 @@ -298,6 +298,9 @@ ar71xx_board_detect() {
   *EAP7660D)
   name=eap7660d
   ;;
 + *GL-CONNECT INET v1)
 + name=gl-inet
 + ;;
   *JA76PF)
   name=ja76pf
   ;;
 diff --git a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh 
 b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
 index 37ceea6..b52df00 100755
 --- a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
 +++ b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
 @@ -220,6 +220,7 @@ platform_check_image() {
   ;;
  
   archer-c7 | \
 + gl-inet | \
   oolite | \
   tl-mr10u | \
   tl-mr11u | \
 diff --git a/target/linux/ar71xx/config-3.10 b/target/linux/ar71xx/config-3.10
 index 4eb4b9f..26347a7 100644
 --- a/target/linux/ar71xx/config-3.10
 +++ b/target/linux/ar71xx/config-3.10
 @@ -48,6 +48,7 @@ CONFIG_ATH79_MACH_DIR_825_C1=y
  CONFIG_ATH79_MACH_DRAGINO2=y
  CONFIG_ATH79_MACH_EAP7660D=y
  CONFIG_ATH79_MACH_EW_DORIN=y
 +CONFIG_ATH79_MACH_GL_INET=y
  CONFIG_ATH79_MACH_GS_OOLITE=y
  CONFIG_ATH79_MACH_HORNET_UB=y
  CONFIG_ATH79_MACH_JA76PF=y
 diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-gl-inet.c 
 b/target/linux/ar71xx/files/arch/mips/ath79/mach-gl-inet.c
 new file mode 100644
 index 000..10f30b2
 --- /dev/null
 +++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-gl-inet.c
 @@ -0,0 +1,109 @@
 +/*
 + *  GL-CONNECT iNet board support
 + *
 + *  Copyright (C) 2011 dongyuqi 729650...@qq.com
 + *  Copyright (C) 2011-2012 Gabor Juhos juh...@openwrt.org
 + *  Copyright (C) 2013 alzhao alz...@gmail.com
 + *  Copyright (C) 2014 Michel Stempin michel.stem...@wanadoo.fr
 + *
 + *  This program is free software; you can redistribute it and/or modify it
 + *  under the terms of the GNU General Public License version 2 as published
 + *  by the Free Software Foundation.
 + */
 +
 +#include linux/gpio.h
 +
 +#include asm/mach-ath79/ath79.h
 +
 +#include dev-eth.h
 +#include dev-gpio-buttons.h
 +#include dev-leds-gpio.h
 +#include dev-m25p80.h
 +#include dev-usb.h
 +#include dev-wmac.h
 +#include machtypes.h
 +
 +#define GL_INET_GPIO_LED_WLAN0
 +#define GL_INET_GPIO_LED_LAN 13
 +#define GL_INET_GPIO_BTN_RESET   11
 +
 +#define GL_INET_KEYS_POLL_INTERVAL   20  /* msecs */
 +#define GL_INET_KEYS_DEBOUNCE_INTERVAL   (3 * 

Re: [OpenWrt-Devel] PATCH: add support for GL-Inet V1 boards/routers (take 3)

[Hartmut Knaack]

maniac...@gmail.com schrieb:
 Hello,

 I didn't get ANY response on my previous version... here it is again.
 Please apply this patch to add support for the GL-iNet devices.

 I've updated a patch, available at
 https://github.com/alzhao/Openwrt-patches-for-GL.iNet/blob/master/001-gl-38300.patch
  

 The patch (also at https://dev.openwrt.org/ticket/15632 ) includes
 support for the GL-Inet V1 devices. Which are mostly compatible with the
 TP-Link WR-703N boards.

 The devices have 64M ram, 16M flash and 2 ethernet interfaces.

 The original patch was written by alzhao alz...@gmail.com although as
 far as I can see he never bothered to get this patch included in the
 mainline.

 I currently have 20+ of these routers, so I would appreciate it if this
 patch was included into the mainline, as that would make life easier
 here.

 The patch adds the following files:
 target/linux/ar71xx/files/arch/mips/ath79/mach-gl-inet.c
 target/linux/ar71xx/generic/profiles/gl-connect.mk
 target/linux/ar71xx/patches-3.10/911-MIPS-ath79-gl-machine.patch
Hi,
not sure how it works to submit other people's patches, but at least for the 
added lines in the files below, you could rework the patch to not mess up 
alphabetic sort order. But best would probably be to contact the original patch 
author and convince that guy to submit here.
 And adds a few lines to the following:
 tools/firmware-utils/src/mktplinkfw.c
 target/linux/ar71xx/config-3.10
 target/linux/ar71xx/base-files/lib/upgrade/platform.sh
 target/linux/ar71xx/base-files/lib/ar71xx.sh
 target/linux/ar71xx/base-files/etc/uci-defaults/02_network



 I myself do not claim any copyright on this, as I only rebased the
 patch. The original copyright statement included is/was:

 /*
 *  GL-CONNECT iNet board support
 *
 *  Copyright (C) 2011 dongyuqi 729650...@qq.com
 *  Copyright (C) 2011-2012 Gabor Juhos juh...@openwrt.org
 *  Copyright (C) 2013 alzhao alz...@gmail.com
 *
 *  This program is free software; you can redistribute it and/or modify it
 *  under the terms of the GNU General Public License version 2 as published
 *  by the Free Software Foundation.
 */

 Signed-off-by: Mark Janssen m...@sig-io.nl
 Signed-off-by: alzhao alz...@gmail.com


 -- patch --

 diff --git a/target/linux/ar71xx/base-files/etc/uci-defaults/02_network 
 b/target/linux/ar71xx/base-files/etc/uci-defaults/02_network
 index 62373e4..ff6d4d7 100755
 --- a/target/linux/ar71xx/base-files/etc/uci-defaults/02_network
 +++ b/target/linux/ar71xx/base-files/etc/uci-defaults/02_network
 @@ -268,6 +268,10 @@ dir-505-a1)
   ucidef_set_interface_lan eth1
   ;;
  
 +gl-inet)
 + ucidef_set_interfaces_lan_wan eth1 eth0
 + ;;
 +
  alfa-ap96 |\
  alfa-nx |\
  ap83 |\
 diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh 
 b/target/linux/ar71xx/base-files/lib/ar71xx.sh
 index 02c46f9..9099f45 100755
 --- a/target/linux/ar71xx/base-files/lib/ar71xx.sh
 +++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh
 @@ -214,6 +214,9 @@ ar71xx_board_detect() {
   *Oolite V1.0)
   name=oolite
   ;;
 + *GL-CONNECT INET v1)
 + name=gl-inet
 + ;;
   *AirRouter)
   name=airrouter
   ;;
 diff --git a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh 
 b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
 index 37ceea6..4760cd8 100755
 --- a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
 +++ b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
 @@ -242,6 +242,7 @@ platform_check_image() {
   tl-wdr4300 | \
   tl-wdr4900-v2 | \
   tl-wr703n | \
 + gl-inet | \
   tl-wr710n | \
   tl-wr720n-v3 | \
   tl-wr741nd | \
 diff --git a/target/linux/ar71xx/config-3.10 b/target/linux/ar71xx/config-3.10
 index 4eb4b9f..f448f9d 100644
 --- a/target/linux/ar71xx/config-3.10
 +++ b/target/linux/ar71xx/config-3.10
 @@ -88,6 +88,7 @@ CONFIG_ATH79_MACH_TL_WR1043ND=y
  CONFIG_ATH79_MACH_TL_WR1043ND_V2=y
  CONFIG_ATH79_MACH_TL_WR2543N=y
  CONFIG_ATH79_MACH_TL_WR703N=y
 +CONFIG_ATH79_MACH_GL_INET=y
  CONFIG_ATH79_MACH_TL_WR720N_V3=y
  CONFIG_ATH79_MACH_TL_WR741ND=y
  CONFIG_ATH79_MACH_TL_WR741ND_V4=y
 diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-gl-inet.c 
 b/target/linux/ar71xx/files/arch/mips/ath79/mach-gl-inet.c
 new file mode 100644
 index 000..0908918
 --- /dev/null
 +++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-gl-inet.c
 @@ -0,0 +1,106 @@
 +/*
 + *  GL-CONNECT iNet board support
 + *
 + *  Copyright (C) 2011 dongyuqi 729650...@qq.com
 + *  Copyright (C) 2011-2012 Gabor Juhos juh...@openwrt.org
 + *  Copyright (C) 2013 alzhao alz...@gmail.com
 + *
 + *  This program is free software; you can redistribute it and/or modify it
 + *  under the terms of the GNU General Public License version 2 as published
 + *  by the Free Software Foundation.
 + */
 +
 +#include linux/gpio.h
 +
 +#include asm/mach-ath79/ath79.h
 +
 +#include 

Re: [OpenWrt-Devel] [PATCH] [packages] add opentracker package

[Hartmut Knaack]

Just a little typo in the description, see below.
Daniel schrieb:
 support for opentracker was suggested in ticket #7023
 it's much tighter than cbtt and got only 20% of cbtt's binary size

 Signed-off-by: Daniel Golle dan...@makrotopia.org
 ---
  net/opentracker/Makefile   | 51 
 ++
  net/opentracker/files/opentracker.init | 20 
  net/opentracker/patches/100-makefile.patch | 32 +++
  3 files changed, 103 insertions(+)
  create mode 100644 net/opentracker/Makefile
  create mode 100755 net/opentracker/files/opentracker.init
  create mode 100644 net/opentracker/patches/100-makefile.patch

 diff --git a/net/opentracker/Makefile b/net/opentracker/Makefile
 new file mode 100644
 index 000..7c01105
 --- /dev/null
 +++ b/net/opentracker/Makefile
 @@ -0,0 +1,51 @@
 +#
 +# Copyright (C) 2006-2014 OpenWrt.org
 +#
 +# This is free software, licensed under the GNU General Public License v2.
 +# See /LICENSE for more information.
 +#
 +
 +include $(TOPDIR)/rules.mk
 +
 +PKG_NAME:=opentracker
 +PKG_VERSION:=20130804
 +PKG_RELEASE:=1
 +PKG_REV:=954f5029dfa17734dc408336ef710c192268e8a4
 +
 +PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.bz2
 +PKG_SOURCE_URL:=git://erdgeist.org/opentracker
 +PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION)
 +PKG_SOURCE_VERSION:=$(PKG_REV)
 +PKG_SOURCE_PROTO:=git
 +PKG_BUILD_DEPENDS:=libowfat
 +
 +include $(INCLUDE_DIR)/package.mk
 +
 +define Package/opentracker
 +  SUBMENU:=BitTorrent
 +  SECTION:=net
 +  CATEGORY:=Network
 +  TITLE:=opentracker
 +  URL:=http://erdgeist.org/arts/software/opentracker/
 +  DEPENDS:=+zlib +libpthread
 +endef
 +
 +define Package/opentracker/description
 + opentracker - An open and free bittorrent tracker
 +
 + opentracker is a open and free bittorrent tracker project.
... is an open ...
 + It aims for minimal resource usage and is intended to run at your wlan 
 router. Currently it is deployed as an open and free tracker instance. Read 
 our free and open tracker blog and announce your torrents there (but do not 
 hesitate to setup your own free trackers!).
 +endef
 +
 +MAKE_FLAGS += PREFIX=$(STAGING_DIR)/usr
 +
 +define Package/opentracker/install
 + $(INSTALL_DIR) $(1)/usr/bin
 + $(INSTALL_BIN) $(PKG_BUILD_DIR)/opentracker $(1)/usr/bin
 + $(INSTALL_DIR) $(1)/etc
 + $(INSTALL_CONF) $(PKG_BUILD_DIR)/opentracker.conf.sample 
 $(1)/etc/opentracker.conf
 + $(INSTALL_DIR) $(1)/etc/init.d
 + $(INSTALL_BIN) ./files/opentracker.init $(1)/etc/init.d/opentracker
 +endef
 +
 +$(eval $(call BuildPackage,opentracker))
 diff --git a/net/opentracker/files/opentracker.init 
 b/net/opentracker/files/opentracker.init
 new file mode 100755
 index 000..c899548
 --- /dev/null
 +++ b/net/opentracker/files/opentracker.init
 @@ -0,0 +1,20 @@
 +#!/bin/sh /etc/rc.common
 +
 +START=10
 +STOP=15
 +
 +NAME=opentracker
 +PROG=/usr/bin/opentracker
 +OPTIONS=-f /etc/opentracker.conf
 +USE_PROCD=1
 +
 +start_service()
 +{
 + procd_open_instance
 + procd_set_param command $PROG $OPTIONS
 + procd_close_instance
 +}
 +
 +stop() {
 + service_stop $PROG
 +}
 diff --git a/net/opentracker/patches/100-makefile.patch 
 b/net/opentracker/patches/100-makefile.patch
 new file mode 100644
 index 000..f3f9038
 --- /dev/null
 +++ b/net/opentracker/patches/100-makefile.patch
 @@ -0,0 +1,32 @@
 +Index: opentracker-20130804/Makefile
 +===
 +--- opentracker-20130804.orig/Makefile
  opentracker-20130804/Makefile
 +@@ -9,13 +9,13 @@ CC?=gcc
 + 
 + # BSD flavour
 + # PREFIX?=/usr/local
 +-# LIBOWFAT_HEADERS=$(PREFIX)/include/libowfat
 +-# LIBOWFAT_LIBRARY=$(PREFIX)/lib
 ++LIBOWFAT_HEADERS=$(PREFIX)/include/libowfat
 ++LIBOWFAT_LIBRARY=$(PREFIX)/lib
 + 
 + # Debug flavour
 +-PREFIX?=..
 +-LIBOWFAT_HEADERS=$(PREFIX)/libowfat
 +-LIBOWFAT_LIBRARY=$(PREFIX)/libowfat
 ++# PREFIX?=..
 ++# LIBOWFAT_HEADERS=$(PREFIX)/libowfat
 ++# LIBOWFAT_LIBRARY=$(PREFIX)/libowfat
 + 
 + BINDIR?=$(PREFIX)/bin
 + 
 +@@ -66,7 +66,7 @@ CFLAGS_debug = $(CFLAGS) $(OPTS_debug) $
 + 
 + $(BINARY): $(OBJECTS) $(HEADERS)
 + $(CC) -o $@ $(OBJECTS) $(LDFLAGS)
 +-strip $@
 ++$(STRIP) $@
 + $(BINARY).debug: $(OBJECTS_debug) $(HEADERS)
 + $(CC) -o $@ $(OBJECTS_debug) $(LDFLAGS)
 + proxy: $(OBJECTS_proxy) $(HEADERS)


 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] is anybody working on supporting Linksys WRT1900ac ?

[Hartmut Knaack]

Toke Høiland-Jørgensen schrieb:
 There was a patch posted from linksys last week:

 http://thread.gmane.org/gmane.comp.embedded.openwrt.devel/23500
I would expect, that all on this thread were aware of that. Anyway, (I didn't 
check all of them, but) those patches also miss a Signed-off-by, the only thing 
getting close to an author is that:

From: Anonymous anonym...@veriksystems.com
Let's see, how it will progress.


 -Toke
 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] is anybody working on supporting Linksys WRT1900ac ?

[Hartmut Knaack]

Gerry Rozema schrieb:
 On 28/03/14 01:58 PM, Peter Lawler wrote:
 Hi Pete! We are working with one of the OpenWRT founders and his 
 team. We'll be sharing more details later... Stay tuned! :)
 https://dev.openwrt.org/wiki/people

 Two listed there as founders, and I'm one of the two.

 Isn't me, so it must be Mike
Mike, are you still alive and on the list?
 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] kernel: hwmon: GSC fix negative temps

[Hartmut Knaack]

Hi,
first off, a short description would have been nice, would make it easier to 
understand the problem and your solution.
So, from what I could see, this driver is already in here for 1 year and 4 
months, though I could not yet find it upstream. How comes? Last time I 
submitted a driver to hwmon, it made it into mainline within less than 4 
months. And the hwmon-maintainer, Guenter Roeck, is very experienced and could 
have pointed you to some of the problems in that driver. And keep in mind, that 
the patches in openwrt should just be a temporary solution (also to backport 
drivers to older kernel versions), but should go upstream ASAP.
Btw, a link to the datasheet (which is mandatory for hwmon) would also be of 
big help for reviewing.
Some comments inline.

Tim Harvey schrieb:
 Signed-off-by: Tim Harvey thar...@gateworks.com
 ---
  .../generic/patches-3.10/880-gateworks_system_controller.patch | 7 
 +--
  .../generic/patches-3.12/880-gateworks_system_controller.patch | 7 
 +--
  .../generic/patches-3.13/880-gateworks_system_controller.patch | 7 
 +--
  .../generic/patches-3.3/880-gateworks_system_controller.patch  | 7 
 +--
  .../generic/patches-3.6/880-gateworks_system_controller.patch  | 7 
 +--
  .../generic/patches-3.8/880-gateworks_system_controller.patch  | 7 
 +--
  .../generic/patches-3.9/880-gateworks_system_controller.patch  | 7 
 +--
  7 files changed, 35 insertions(+), 14 deletions(-)

 diff --git 
 a/target/linux/generic/patches-3.10/880-gateworks_system_controller.patch 
 b/target/linux/generic/patches-3.10/880-gateworks_system_controller.patch
 index d923485..450551a 100644
 --- a/target/linux/generic/patches-3.10/880-gateworks_system_controller.patch
 +++ b/target/linux/generic/patches-3.10/880-gateworks_system_controller.patch
 @@ -28,7 +28,7 @@
   
  --- /dev/null
  +++ b/drivers/hwmon/gsc.c
 -@@ -0,0 +1,308 @@
 +@@ -0,0 +1,311 @@
  +/*
  + * A hwmon driver for the Gateworks System Controller 
  + * Copyright (C) 2009 Gateworks Corporation
 @@ -132,11 +132,14 @@
  + */
  +static inline int gsp_read(struct i2c_client *client, u8 reg)
  +{
 -+unsigned int adc = 0;
 ++int adc = 0;
adc should be of type s16, and for the config you would need an int ret
  +if (reg == GSP_REG_TEMP_IN || reg  GSP_REG_CURRENT)
  +{
  +adc |= i2c_smbus_read_byte_data(client, reg);
  +adc |= i2c_smbus_read_byte_data(client, reg + 1)  8;
adc = i2c_smbus_read_word_data(client, reg);
 ++if (adc  0x8000) { /* neg temps from two's-complement */
 ++adc = adc - 0x;
 ++}
not needed, you just may have to check if adc gets casted to int during return.
  +return adc;
  +}
  +else
Some error-check after calling a function is also the regular behavior when 
coding properly. Then, from what I remember, hwmon also moved to the devm-API 
about a year ago.
Take care

Hartmut
 diff --git 
 a/target/linux/generic/patches-3.12/880-gateworks_system_controller.patch 
 b/target/linux/generic/patches-3.12/880-gateworks_system_controller.patch
 index 6e4ae30..bf521f5 100644
 --- a/target/linux/generic/patches-3.12/880-gateworks_system_controller.patch
 +++ b/target/linux/generic/patches-3.12/880-gateworks_system_controller.patch
 @@ -28,7 +28,7 @@
   
  --- /dev/null
  +++ b/drivers/hwmon/gsc.c
 -@@ -0,0 +1,308 @@
 +@@ -0,0 +1,311 @@
  +/*
  + * A hwmon driver for the Gateworks System Controller 
  + * Copyright (C) 2009 Gateworks Corporation
 @@ -132,11 +132,14 @@
  + */
  +static inline int gsp_read(struct i2c_client *client, u8 reg)
  +{
 -+unsigned int adc = 0;
 ++int adc = 0;
  +if (reg == GSP_REG_TEMP_IN || reg  GSP_REG_CURRENT)
  +{
  +adc |= i2c_smbus_read_byte_data(client, reg);
  +adc |= i2c_smbus_read_byte_data(client, reg + 1)  8;
 ++if (adc  0x8000) { /* neg temps from two's-complement */
 ++adc = adc - 0x;
 ++}
  +return adc;
  +}
  +else
 diff --git 
 a/target/linux/generic/patches-3.13/880-gateworks_system_controller.patch 
 b/target/linux/generic/patches-3.13/880-gateworks_system_controller.patch
 index 6e4ae30..bf521f5 100644
 --- a/target/linux/generic/patches-3.13/880-gateworks_system_controller.patch
 +++ b/target/linux/generic/patches-3.13/880-gateworks_system_controller.patch
 @@ -28,7 +28,7 @@
   
  --- /dev/null
  +++ b/drivers/hwmon/gsc.c
 -@@ -0,0 +1,308 @@
 +@@ -0,0 +1,311 @@
  +/*
  + * A hwmon driver for the Gateworks System Controller 
  + * Copyright (C) 2009 Gateworks Corporation
 @@ -132,11 +132,14 @@
  + */
  +static inline int gsp_read(struct i2c_client *client, u8 reg)
  +{
 -+unsigned int adc = 0;
 ++int adc = 0;
  +if (reg == GSP_REG_TEMP_IN || reg  GSP_REG_CURRENT)
  +{
  +adc |= i2c_smbus_read_byte_data(client, reg);
  +adc |= i2c_smbus_read_byte_data(client, reg + 1)  8;
 ++   

Re: [OpenWrt-Devel] [PATCH] kernel: hwmon: GSC fix negative temps

[Hartmut Knaack]

Hartmut Knaack schrieb:
 Hi,
 first off, a short description would have been nice, would make it easier to 
 understand the problem and your solution.
 So, from what I could see, this driver is already in here for 1 year and 4 
 months, though I could not yet find it upstream. How comes? Last time I 
 submitted a driver to hwmon, it made it into mainline within less than 4 
 months. And the hwmon-maintainer, Guenter Roeck, is very experienced and 
 could have pointed you to some of the problems in that driver. And keep in 
 mind, that the patches in openwrt should just be a temporary solution (also 
 to backport drivers to older kernel versions), but should go upstream ASAP.
 Btw, a link to the datasheet (which is mandatory for hwmon) would also be of 
 big help for reviewing.
 Some comments inline.

 Tim Harvey schrieb:
 Signed-off-by: Tim Harvey thar...@gateworks.com
 ---
  .../generic/patches-3.10/880-gateworks_system_controller.patch | 7 
 +--
  .../generic/patches-3.12/880-gateworks_system_controller.patch | 7 
 +--
  .../generic/patches-3.13/880-gateworks_system_controller.patch | 7 
 +--
  .../generic/patches-3.3/880-gateworks_system_controller.patch  | 7 
 +--
  .../generic/patches-3.6/880-gateworks_system_controller.patch  | 7 
 +--
  .../generic/patches-3.8/880-gateworks_system_controller.patch  | 7 
 +--
  .../generic/patches-3.9/880-gateworks_system_controller.patch  | 7 
 +--
  7 files changed, 35 insertions(+), 14 deletions(-)

 diff --git 
 a/target/linux/generic/patches-3.10/880-gateworks_system_controller.patch 
 b/target/linux/generic/patches-3.10/880-gateworks_system_controller.patch
 index d923485..450551a 100644
 --- a/target/linux/generic/patches-3.10/880-gateworks_system_controller.patch
 +++ b/target/linux/generic/patches-3.10/880-gateworks_system_controller.patch
 @@ -28,7 +28,7 @@
   
  --- /dev/null
  +++ b/drivers/hwmon/gsc.c
 -@@ -0,0 +1,308 @@
 +@@ -0,0 +1,311 @@
  +/*
  + * A hwmon driver for the Gateworks System Controller 
  + * Copyright (C) 2009 Gateworks Corporation
 @@ -132,11 +132,14 @@
  + */
  +static inline int gsp_read(struct i2c_client *client, u8 reg)
  +{
 -+   unsigned int adc = 0;
 ++   int adc = 0;
 adc should be of type s16, and for the config you would need an int ret
  +   if (reg == GSP_REG_TEMP_IN || reg  GSP_REG_CURRENT)
  +   {
  +   adc |= i2c_smbus_read_byte_data(client, reg);
  +   adc |= i2c_smbus_read_byte_data(client, reg + 1)  8;
 adc = i2c_smbus_read_word_data(client, reg);
Sorry, my bad. This doesn't allow error-handling. Better the following:
ret = i2c_smbus_read_word_data(client, reg);
if (ret  0)
do some error handling, because read failed;
adc = ret;
But basically, there is a major design flaw in this function: it is not 
designed to handle errors. So, you should start to rework show_adc() and then 
scp_read(). The same applies to store_fan() and gsp_write(). I also strongly 
recommend to have a look at recent hwmon drivers - you don't need to reinvent 
what's already present.
 ++   if (adc  0x8000) { /* neg temps from two's-complement */
 ++   adc = adc - 0x;
 ++   }
 not needed, you just may have to check if adc gets casted to int during 
 return.
  +   return adc;
  +   }
  +   else
 Some error-check after calling a function is also the regular behavior when 
 coding properly. Then, from what I remember, hwmon also moved to the devm-API 
 about a year ago.
 Take care

 Hartmut

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] How to use ethernet port as lan or wan port in WR703N

[Hartmut Knaack]

bjzhougong schrieb:
 Dear Sirs.
  
 As we know, we can configure network.lan.interface or 
 network.wan.interface as eth0 to use ethernet port as lan or wan port on 
 WR703N.
 I think it should need to do anything in driver for switch ethernet port, 
 and I want to know what happened between user space and kernel space after 
 we run /etc/init.d/network restart, 
 Thanks for any idea about this!
  
 If there is any help? Thanks!
Not sure, what exactly you want to know. When running /etc/init.d/network 
restart, all the configured options in /etc/config/network get configured. See 
http://wiki.openwrt.org/doc/uci/network for more information about available 
options.
When changing a certain network device from WAN to LAN, it is mainly about 
switching the configuration from being DHCP master or slave, and some routing 
configurations.
 --
 bjzhougong
  
  


 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] How to use ethernet port as lan or wan port in WR703N

[Hartmut Knaack]

jonsm...@gmail.com schrieb:
 The switch (esw) configuration separates the LAN and WAN ports.
But according to the wiki, the 703n has only one ethernet port and no switch.

 On Mon, Feb 17, 2014 at 4:07 PM, Hartmut Knaack knaac...@gmx.de wrote:
 bjzhougong schrieb:
 Dear Sirs.

 As we know, we can configure network.lan.interface or 
 network.wan.interface as eth0 to use ethernet port as lan or wan port 
 on WR703N.
 I think it should need to do anything in driver for switch ethernet port,
 and I want to know what happened between user space and kernel space 
 after we run /etc/init.d/network restart,
 Thanks for any idea about this!
 If there is any help? Thanks!
 Not sure, what exactly you want to know. When running /etc/init.d/network 
 restart, all the configured options in /etc/config/network get configured. 
 See http://wiki.openwrt.org/doc/uci/network for more information about 
 available options.
 When changing a certain network device from WAN to LAN, it is mainly about 
 switching the configuration from being DHCP master or slave, and some 
 routing configurations.
 --
 bjzhougong




 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] modprobe ignoring parameters in /etc/modules.d/files?

[Hartmut Knaack]

Hi,
I just installed latest trunk snapshot (r38999) and some i2c/hwmon-packages on 
my 1043nd and issued an
insmod i2c-gpio-custom bus0=0,20,0
which worked properly. So I created the file /etc/modules.d/66-i2c-gpio-custom 
with the content:
i2c-gpio-custom bus0=0,20,0
but after reboot I get like 7 times the following message in dmesg:
[7.16] Custom GPIO-based I2C driver version 0.1.1
[7.17] i2c-gpio-custom: no bus parameter(s) specified

This is not happening on a different router running still r37855. So it seems 
to me, that during the conversion from insmod to modprobe either the syntax for 
module parameter under /etc/modules.d/ has changed, or module parameters are 
ignored at the moment. Can somebody help?
Thanks.

Hartmut
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] Move I2C-GPIO drivers from i2c.mk to other.mk

[Hartmut Knaack]

Move pca953x support from i2c.mk to other.mk, where other GPIO drivers are 
located. Remove duplicate pcf857x support from i2c.mk.

Signed-off-by: Hartmut Knaack knaac...@gmx.de
---
Index: trunk/package/kernel/linux/modules/i2c.mk
===
--- trunk/package/kernel/linux/modules/i2c.mk   (Revision 38114)
+++ trunk/package/kernel/linux/modules/i2c.mk   (Arbeitskopie)
@@ -237,34 +237,3 @@
 endef
 
 $(eval $(call KernelPackage,i2c-mux-pca9541))
-
-GPIO_PCA953X_MODULES:= \
-  CONFIG_GPIO_PCA953X:drivers/gpio/gpio-pca953x
-
-define KernelPackage/pca953x
-  $(call i2c_defaults,$(GPIO_PCA953X_MODULES),51)
-  TITLE:=Philips PCA953x I2C GPIO extenders
-  DEPENDS:=kmod-i2c-core
-endef
-
-define KernelPackage/pca953x/description
- Kernel modules for PCA953x I2C GPIO extenders
-endef
-
-$(eval $(call KernelPackage,pca953x))
-
-
-GPIO_PCF857X_MODULES:= \
-  CONFIG_GPIO_PCF857X:drivers/gpio/gpio-pcf857x
-
-define KernelPackage/pcf857x
-  $(call i2c_defaults,$(GPIO_PCF857X_MODULES),51)
-  TITLE:=Philips PCF857x I2C GPIO extenders
-  DEPENDS:=kmod-i2c-core
-endef
-
-define KernelPackage/pcf857x/description
- Kernel modules for PCF857x I2C GPIO extenders
-endef
-
-$(eval $(call KernelPackage,pcf857x))
Index: trunk/package/kernel/linux/modules/other.mk
===
--- trunk/package/kernel/linux/modules/other.mk (Revision 38114)
+++ trunk/package/kernel/linux/modules/other.mk (Arbeitskopie)
@@ -162,6 +162,22 @@
 
 $(eval $(call KernelPackage,gpio-nxp-74hc164))
 
+define KernelPackage/gpio-pca953x
+  SUBMENU:=$(OTHER_MENU)
+  DEPENDS:=@GPIO_SUPPORT +kmod-i2c-core
+  TITLE:=PCA95xx, TCA64xx, and MAX7310 I/O ports
+  KCONFIG:=CONFIG_GPIO_PCA953X
+  FILES:=$(LINUX_DIR)/drivers/gpio/gpio-pca953x.ko
+  AUTOLOAD:=$(call AutoLoad,55,gpio-pca953x)
+endef
+
+define KernelPackage/gpio-pca953x/description
+ Kernel module for MAX731{0,2,3,5}, PCA6107, PCA953{4-9}, PCA955{4-7},
+ PCA957{4,5} and TCA64{08,16} I2C GPIO expanders
+endef
+
+$(eval $(call KernelPackage,gpio-pca953x))
+
 define KernelPackage/gpio-pcf857x
   SUBMENU:=$(OTHER_MENU)
   DEPENDS:=@GPIO_SUPPORT +kmod-i2c-core
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] Add hwmon driver for ADT7410

[Hartmut Knaack]

Add support for the ADT7410 hwmon driver, a high precision I2C temperature 
sensor.
Signed-off-by: Hartmut Knaack knaac...@gmx.de
---
Tested with kernel 3.8.
Index: trunk/package/kernel/linux/modules/hwmon.mk
===
--- trunk/package/kernel/linux/modules/hwmon.mk (Revision 38114)
+++ trunk/package/kernel/linux/modules/hwmon.mk (Arbeitskopie)
@@ -44,6 +44,31 @@
 $(eval $(call KernelPackage,hwmon-vid))
 
 
+define KernelPackage/hwmon-adt7410
+  TITLE:=ADT7410 monitoring support
+ifeq ($(strip $(call CompareKernelPatchVer,$(KERNEL_PATCHVER),ge,3.10.0)),1)
+  KCONFIG:= \
+   CONFIG_SENSORS_ADT7X10 \
+   CONFIG_SENSORS_ADT7410
+  FILES:= \
+   $(LINUX_DIR)/drivers/hwmon/adt7x10.ko \
+   $(LINUX_DIR)/drivers/hwmon/adt7410.ko
+  AUTOLOAD:=$(call AutoLoad,60,adt7x10 adt7410)
+else
+  KCONFIG:=CONFIG_SENSORS_ADT7410
+  FILES:=$(LINUX_DIR)/drivers/hwmon/adt7410.ko
+  AUTOLOAD:=$(call AutoLoad,60,adt7410)
+endif
+  $(call AddDepends/hwmon,+kmod-i2c-core @!(LINUX_3_3||LINUX_3_6))
+endef
+
+define KernelPackage/hwmon-adt7410/description
+ Kernel module for ADT7410/7420 I2C thermal monitor chip
+endef
+
+$(eval $(call KernelPackage,hwmon-adt7410))
+
+
 define KernelPackage/hwmon-adt7475
   TITLE:=ADT7473/7475/7476/7490 monitoring support
   KCONFIG:=CONFIG_SENSORS_ADT7475
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] Add support for industrial-io and AD799x

[Hartmut Knaack]

Add support for industrial IO core and (still staging) driver for AD799x, a 
high precision I2C ADC family.
Signed-off-by: Hartmut Knaack knaac...@gmx.de
---
Tested with kernel 3.8.
Index: trunk/package/kernel/linux/modules/other.mk
===
--- trunk/package/kernel/linux/modules/other.mk (Revision 38114)
+++ trunk/package/kernel/linux/modules/other.mk (Arbeitskopie)
@@ -177,6 +177,51 @@
 
 $(eval $(call KernelPackage,gpio-pcf857x))
 
+define KernelPackage/iio-core
+  SUBMENU:=$(OTHER_MENU)
+  DEPENDS:=@!LINUX_3_3
+  TITLE:=Industrial IO core
+  KCONFIG:= \
+   CONFIG_IIO \
+   CONFIG_IIO_BUFFER=y \
+   CONFIG_IIO_KFIFO_BUF \
+   CONFIG_IIO_TRIGGER=y \
+   CONFIG_IIO_TRIGGERED_BUFFER
+  FILES:= \
+   $(LINUX_DIR)/drivers/iio/industrialio.ko \
+   $(LINUX_DIR)/drivers/iio/industrialio-triggered-buffer.ko \
+   $(LINUX_DIR)/drivers/iio/kfifo_buf.ko
+  AUTOLOAD:=$(call AutoLoad,55,industrialio kfifo_buf 
industrialio-triggered-buffer)
+endef
+
+define KernelPackage/iio-core/description
+ The industrial I/O subsystem provides a unified framework for
+ drivers for many different types of embedded sensors using a
+ number of different physical interfaces (i2c, spi, etc)
+endef
+
+$(eval $(call KernelPackage,iio-core))
+
+
+define KernelPackage/iio-ad799x
+  SUBMENU:=$(OTHER_MENU)
+  DEPENDS:=kmod-i2c-core kmod-iio-core
+  TITLE:=Analog Devices AD799x ADC driver
+  KCONFIG:= \
+   CONFIG_AD799X_RING_BUFFER=y \
+   CONFIG_AD799X
+  FILES:=$(LINUX_DIR)/drivers/staging/iio/adc/ad799x.ko
+  AUTOLOAD:=$(call AutoLoad,56,ad799x)
+endef
+
+define KernelPackage/iio-ad799x/description
+ support for Analog Devices:
+ ad7991, ad7995, ad7999, ad7992, ad7993, ad7994, ad7997, ad7998
+ i2c analog to digital converters (ADC). WARNING! This driver is still staging!
+endef
+
+$(eval $(call KernelPackage,iio-ad799x))
+
 define KernelPackage/lp
   SUBMENU:=$(OTHER_MENU)
   TITLE:=Parallel port and line printer support
Index: trunk/target/linux/generic/config-3.8
===
--- trunk/target/linux/generic/config-3.8   (Revision 38114)
+++ trunk/target/linux/generic/config-3.8   (Arbeitskopie)
@@ -15,12 +15,25 @@
 # CONFIG_ACPI_HED is not set
 # CONFIG_ACPI_POWER_METER is not set
 # CONFIG_ACPI_QUICKSTART is not set
+# CONFIG_AD5064 is not set
 # CONFIG_AD525X_DPOT is not set
+# CONFIG_AD5380 is not set
+# CONFIG_AD5446 is not set
+# CONFIG_AD5933 is not set
+# CONFIG_AD7150 is not set
+# CONFIG_AD7152 is not set
+# CONFIG_AD7291 is not set
+# CONFIG_AD7606 is not set
+# CONFIG_AD7746 is not set
 # CONFIG_ADAPTEC_STARFIRE is not set
+# CONFIG_ADE7854 is not set
 # CONFIG_ADFS_FS is not set
 # CONFIG_ADIS16255 is not set
+# CONFIG_ADJD_S311 is not set
 # CONFIG_ADM6996_PHY is not set
 # CONFIG_ADM8211 is not set
+# CONFIG_ADT7316 is not set
+# CONFIG_ADT7410 is not set
 CONFIG_AEABI=y
 # CONFIG_AFFS_FS is not set
 # CONFIG_AFS_FS is not set
@@ -1124,6 +1137,13 @@
 # CONFIG_IGB is not set
 # CONFIG_IGBVF is not set
 # CONFIG_IIO is not set
+# CONFIG_IIO_BUFFER_CB is not set
+CONFIG_IIO_CONSUMERS_PER_TRIGGER=2
+# CONFIG_IIO_GPIO_TRIGGER is not set
+# CONFIG_IIO_SIMPLE_DUMMY is not set
+# CONFIG_IIO_ST_HWMON is not set
+# CONFIG_IIO_SW_RING is not set
+# CONFIG_IIO_SYSFS_TRIGGER is not set
 # CONFIG_IKCONFIG is not set
 # CONFIG_IKCONFIG_PROC is not set
 # CONFIG_IMAGE_CMDLINE_HACK is not set
@@ -1535,7 +1555,10 @@
 # CONFIG_MAC_PARTITION is not set
 # CONFIG_MAGIC_SYSRQ is not set
 # CONFIG_MARVELL_PHY is not set
+# CONFIG_MAX1363 is not set
+# CONFIG_MAX517 is not set
 # CONFIG_MAX63XX_WATCHDOG is not set
+# CONFIG_MCP4725 is not set
 # CONFIG_MD is not set
 # CONFIG_MDIO_BITBANG is not set
 # CONFIG_MDIO_BUS_MUX_GPIO is not set
@@ -2719,6 +2742,7 @@
 # CONFIG_SENSORS_ADT7462 is not set
 # CONFIG_SENSORS_ADT7470 is not set
 # CONFIG_SENSORS_ADT7475 is not set
+# CONFIG_SENSORS_AK8975 is not set
 # CONFIG_SENSORS_AMC6821 is not set
 # CONFIG_SENSORS_APDS990X is not set
 # CONFIG_SENSORS_APPLESMC is not set
@@ -2747,8 +2771,11 @@
 # CONFIG_SENSORS_GSC is not set
 # CONFIG_SENSORS_HDAPS is not set
 # CONFIG_SENSORS_HIH6130 is not set
+# CONFIG_SENSORS_HMC5843 is not set
 # CONFIG_SENSORS_I5K_AMB is not set
 # CONFIG_SENSORS_INA2XX is not set
+# CONFIG_SENSORS_ISL29018 is not set
+# CONFIG_SENSORS_ISL29028 is not set
 # CONFIG_SENSORS_IT87 is not set
 # CONFIG_SENSORS_JC42 is not set
 # CONFIG_SENSORS_K10TEMP is not set
@@ -2804,6 +2831,7 @@
 # CONFIG_SENSORS_TMP401 is not set
 # CONFIG_SENSORS_TMP421 is not set
 # CONFIG_SENSORS_TSL2550 is not set
+# CONFIG_SENSORS_TSL2563 is not set
 # CONFIG_SENSORS_VIA686A is not set
 # CONFIG_SENSORS_VIA_CPUTEMP is not set
 # CONFIG_SENSORS_VT1211 is not set
@@ -3195,6 +3223,7 @@
 # CONFIG_TIMER_STATS is not set
 CONFIG_TINY_RCU=y
 # CONFIG_TIPC is not set
+# CONFIG_TI_ADC081C is not set
 # CONFIG_TI_DAC7512 is not set
 # CONFIG_TI_ST

Re: [OpenWrt-Devel] 12.09 trunk: kernel is not upgradable?

[Hartmut Knaack]

Paolo Pisati schrieb:
 and what about missing packages in the release repo? (e.g. transmission in 
 12.09)

 but even more worryingly, what about security fixes?
 access points, dsl modem/routers, etcetc are at the forefront of our networks 
 and tier1 targets for attacks, how do we handle security?

 and besides, if we are meant to stick with the original release repo, what's 
 the point of 'opkg upgrade'?
This is a trade-off situation between bleeding-edge functionality and 
stability, and you need to decide on your own, which one is more important to 
you. Security fixes should get into the stable releases, which might require an 
update/upgrade of additionally installed packages. For security fixes in the 
firmware image though (kernel, basic system), it gets a bit tricky, since it 
requires a sysupgrade.
opkg upgrade should probably help you, when switching from one release to 
another via sysupgrade, to also move your installed packages to the new release.
And if you now want to switch to trunk, be warned, that this release is highly 
dynamic. While this is no big deal for program packages, you will encounter 
problems to install kernel modules as soon as the bot has built a newer version.



 On Tue, Sep 17, 2013 at 12:30 AM, Hartmut Knaack knaac...@gmx.de 
 mailto:knaac...@gmx.de wrote:

 Paolo Pisati schrieb:
  Alix2 installed from scratch using a 12.09 image:
 
  flag@OpenWrt:/mnt/storage/flag$ cat /etc/opkg.conf
  src/gz attitude_adjustment 
 http://downloads.openwrt.org/attitude_adjustment/12.09/x86/alix2/packages
  src/gz trunk http://downloads.openwrt.org/snapshots/trunk/x86/packages/
  dest root /
  dest ram /tmp
  lists_dir ext /var/opkg-lists
  option overlay_root /overlay
 
  Later on, since some packages were missing
  (see also 
 http://permalink.gmane.org/gmane.comp.embedded.openwrt.devel/20097), i added 
 the trunk
  repository to opkg.conf (BTW, is that the correct way to get new 
 pkgs?), and this morning i wanted
  to see which pkgs were eligible for an upgrade, but to my dismay the 
 kernel pkg wasn't among them:
 
  flag@OpenWrt:/mnt/storage/flag$ sudo opkg list-installed | grep kernel
  kernel - 3.3.8-1-856232096e5924b296e029cee7d328d1
 
  lag@OpenWrt:/mnt/storage/flag$ sudo opkg update
  Downloading 
 http://downloads.openwrt.org/attitude_adjustment/12.09/x86/alix2/packages/Packages.gz.
  Updated list of available packages in 
 /var/opkg-lists/attitude_adjustment.
  Downloading 
 http://downloads.openwrt.org/snapshots/trunk/x86/packages//Packages.gz.
  Updated list of available packages in /var/opkg-lists/trunk.
  flag@OpenWrt:/mnt/storage/flag$ sudo opkg list-upgradable | grep kernel
  flag@OpenWrt:/mnt/storage/flag$
 
  Last but not least, it seems a lot of pkgs (mainly kmod-*) are 
 duplicated among the two repos:
  flag@OpenWrt:/mnt/storage/flag$ sudo opkg list-upgradable | grep 
 Multiple
  Multiple packages (kmod-usb-storage and kmod-usb-storage) providing 
 same name marked HOLD or PREFER. Using latest.
  Multiple packages (kmod-i2c-scx200-acb and kmod-i2c-scx200-acb) 
 providing same name marked HOLD or PREFER. Using latest.
  Multiple packages (kmod-usb-core and kmod-usb-core) providing same name 
 marked HOLD or PREFER. Using latest.
  Multiple packages (kmod-crypto-manager and kmod-crypto-manager) 
 providing same name marked HOLD or PREFER. Using latest.
  ...
 
  what am i supposed to do here? Shall i disable the 12.09 repo and keep 
 trunk only?
 No, disable trunk and stick to the version that corresponds to your 
 installed image (12.09).
 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org mailto:openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel




 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] 12.09 trunk: kernel is not upgradable?

[Hartmut Knaack]

Paolo Pisati schrieb:
 On Tue, Sep 17, 2013 at 12:08 PM, Hartmut Knaack knaac...@gmx.de 
 mailto:knaac...@gmx.de wrote:

 Paolo Pisati schrieb:
  and what about missing packages in the release repo? (e.g. transmission 
 in 12.09)
 
  but even more worryingly, what about security fixes?
  access points, dsl modem/routers, etcetc are at the forefront of our 
 networks and tier1 targets for attacks, how do we handle security?
 
  and besides, if we are meant to stick with the original release repo, 
 what's the point of 'opkg upgrade'?
 This is a trade-off situation between bleeding-edge functionality and 
 stability, and you need to decide on your own, which one is more important to 
 you. Security fixes should get into the stable releases, which might require 
 an update/upgrade of additionally installed packages. For security fixes in 
 the firmware image though (kernel, basic system), it gets a bit tricky, since 
 it requires a sysupgrade.


 which pkgs are part of the core system? and how a pkg is selected to be part 
 of core or not?
You can figure that out issuing 'opkg list-installed' on a fresh system. Some 
of the packages are base-system, busybox, kernel, dropbear, ubus, procd, libc, 
libgcc,...
  

 opkg upgrade should probably help you, when switching from one release to 
 another via sysupgrade, to also move your installed packages to the new 
 release.
 And if you now want to switch to trunk, be warned, that this release is 
 highly dynamic. While this is no big deal for program packages, you will 
 encounter problems to install kernel modules as soon as the bot has built a 
 newer version.


 ok, let's say that i want to run the bleeding edge (thus trunk), why my 
 kernel pkg is not present in the list of upgradable pkgs (while there's 
 clearly a new version)?
Then you download the trunk image and issue sysupgrade with it. After that, you 
make sure to have only the trunk repository available in /etc/opkg.conf. Then 
somehow quickly install all your necessary packages (at least kernel modules), 
before buildbot finishes another batch of builds.

 flag@OpenWrt:/mnt/storage/flag$ sudo opkg update
 Downloading 
 http://downloads.openwrt.org/attitude_adjustment/12.09/x86/alix2/packages/Packages.gz.
 Updated list of available packages in /var/opkg-lists/attitude_adjustment.
 Downloading 
 http://downloads.openwrt.org/snapshots/trunk/x86/packages//Packages.gz.
 Updated list of available packages in /var/opkg-lists/trunk.
 flag@OpenWrt:/mnt/storage/flag$ sudo opkg list-upgradable | grep -i kernel
 flag@OpenWrt:/mnt/storage/flag$

 flag@OpenWrt:/mnt/storage/flag$ sudo opkg list | grep ^kernel 
 kernel - 3.3.8-1-856232096e5924b296e029cee7d328d1

 from my web browser:
 kernel_3.8.13-1-49956727e4f1f9c9dc03ff3fbe864c7.. 16-Sep-2013 01:49  
649

 only 649 bytes? looks like it doesn't detect the new kernel package as a 
 replacement for my old one, or there's something else wrong here
The kernel is in the firmware image.

 but at the same time, all the kmod pkgs require the new kernel (and thus if i 
 'opkg upgrade' i'll break my system):

 flag@OpenWrt:/mnt/storage/flag$ sudo opkg list-upgradable | grep kmod
 Multiple packages (kmod-usb-storage and kmod-usb-storage) providing same name 
 marked HOLD or PREFER. Using latest.
 kmod-usb-storage - 3.3.8-1 - 3.8.13-1
 Multiple packages (kmod-i2c-scx200-acb and kmod-i2c-scx200-acb) providing 
 same name marked HOLD or PREFER. Using latest.
 kmod-i2c-scx200-acb - 3.3.8-1 - 3.8.13-1
 Multiple packages (kmod-usb-core and kmod-usb-core) providing same name 
 marked HOLD or PREFER. Using latest.
 kmod-usb-core - 3.3.8-1 - 3.8.13-1
 Multiple packages (kmod-crypto-manager and kmod-crypto-manager) providing 
 same name marked HOLD or PREFER. Using latest.
 kmod-crypto-manager - 3.3.8-1 - 3.8.13-1
 ...etcetc...

 and what are those Multiple packages (kmod-crypto-manager and 
 kmod-crypto-manager) providing same name marked HOLD or PREFER. Using 
 latest. messages?
Just what it states: opkg finds packages with the same name in the two repos, 
with different versions, and it is trying to use the higher version (which does 
not match with your kernel version).

 bye,
 p.


 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] 12.09 trunk: kernel is not upgradable?

[Hartmut Knaack]

Paolo Pisati schrieb:
 Alix2 installed from scratch using a 12.09 image:

 flag@OpenWrt:/mnt/storage/flag$ cat /etc/opkg.conf 
 src/gz attitude_adjustment 
 http://downloads.openwrt.org/attitude_adjustment/12.09/x86/alix2/packages
 src/gz trunk http://downloads.openwrt.org/snapshots/trunk/x86/packages/
 dest root /
 dest ram /tmp
 lists_dir ext /var/opkg-lists
 option overlay_root /overlay

 Later on, since some packages were missing
 (see also 
 http://permalink.gmane.org/gmane.comp.embedded.openwrt.devel/20097), i added 
 the trunk 
 repository to opkg.conf (BTW, is that the correct way to get new pkgs?), and 
 this morning i wanted
 to see which pkgs were eligible for an upgrade, but to my dismay the kernel 
 pkg wasn't among them:

 flag@OpenWrt:/mnt/storage/flag$ sudo opkg list-installed | grep kernel
 kernel - 3.3.8-1-856232096e5924b296e029cee7d328d1

 lag@OpenWrt:/mnt/storage/flag$ sudo opkg update
 Downloading 
 http://downloads.openwrt.org/attitude_adjustment/12.09/x86/alix2/packages/Packages.gz.
 Updated list of available packages in /var/opkg-lists/attitude_adjustment.
 Downloading 
 http://downloads.openwrt.org/snapshots/trunk/x86/packages//Packages.gz.
 Updated list of available packages in /var/opkg-lists/trunk.
 flag@OpenWrt:/mnt/storage/flag$ sudo opkg list-upgradable | grep kernel
 flag@OpenWrt:/mnt/storage/flag$

 Last but not least, it seems a lot of pkgs (mainly kmod-*) are duplicated 
 among the two repos:
 flag@OpenWrt:/mnt/storage/flag$ sudo opkg list-upgradable | grep Multiple
 Multiple packages (kmod-usb-storage and kmod-usb-storage) providing same name 
 marked HOLD or PREFER. Using latest.
 Multiple packages (kmod-i2c-scx200-acb and kmod-i2c-scx200-acb) providing 
 same name marked HOLD or PREFER. Using latest.
 Multiple packages (kmod-usb-core and kmod-usb-core) providing same name 
 marked HOLD or PREFER. Using latest.
 Multiple packages (kmod-crypto-manager and kmod-crypto-manager) providing 
 same name marked HOLD or PREFER. Using latest.
 ...

 what am i supposed to do here? Shall i disable the 12.09 repo and keep trunk 
 only?
No, disable trunk and stick to the version that corresponds to your installed 
image (12.09).
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] Unexpected behaviour comparing Kernel Patch Versions

[Hartmut Knaack]

Hi,
I was working on getting a pretty new kernel device driver into 
package/kernel/linux/modules/hwmon.mk in recent trunk. My problem occured, when 
I encapsulated my new block to prevent it from building with older 
(unsupported) kernel versions.
So, to reproduce the problem properly, I checked out a fresh trunk and in the 
same file hwmon.mk I encapsulated the already existing block for the adt7475, 
so it looks like that:

ifeq ($(strip $(call CompareKernelPatchVer,$(KERNEL_PATCHVER),ge,3.1.0)),1)
define KernelPackage/hwmon-adt7475
  TITLE:=ADT7473/7475/7476/7490 monitoring support
  KCONFIG:=CONFIG_SENSORS_ADT7475
  FILES:=$(LINUX_DIR)/drivers/hwmon/adt7475.ko
  AUTOLOAD:=$(call AutoLoad,60,adt7475)
  $(call AddDepends/hwmon,+kmod-i2c-core +kmod-hwmon-vid)
endef

define KernelPackage/hwmon-adt7475/description
 Kernel module for ADT7473/7475/7476/7490 thermal monitor chip
endef

$(eval $(call KernelPackage,hwmon-adt7475))
endif

I tried with platforms ADM5120 (current Kernel version 3.8.13) and AR71xx 
(Kernel 3.10.x), but this block was in both cases invisible in menuconfig.
Trying to debug this problem, I encountered that $(KERNEL_PATCHVER) seems to be 
empty and $(call CompareKernelPatchVer,$(KERNEL_PATCHVER),ge,3.1.0) is 0.
Please help, and also have a check at the other locations, where Kernel 
versions are checked this way.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] add a option in menuconfig to set a custom folder for the images packages

[Hartmut Knaack]

Hi.

Oliver Ertl schrieb:
 Signed-off-by: Oliver Ertl oli...@ertls-netzwerk.de
 ---
  Config.in | 4 
  rules.mk  | 2 +-
  2 files changed, 5 insertions(+), 1 deletion(-)

 diff --git a/Config.in b/Config.in
 index 0ef2f14..0683125 100644
 --- a/Config.in
 +++ b/Config.in
 @@ -784,6 +784,10 @@ menuconfig DEVEL
   string Download folder if DEVEL
   default 
  
 + config BINARY_FOLDER
 + string Binary folder if DEVEL
 + default 
 +
   config LOCALMIRROR
   string Local mirror for source packages if DEVEL
   default 
 diff --git a/rules.mk b/rules.mk
 index 14171a0..2d4d5c8 100644
 --- a/rules.mk
 +++ b/rules.mk
 @@ -80,7 +80,7 @@ ifdef CONFIG_MIPS64_ABI
  endif
  
  DL_DIR:=$(if $(call qstrip,$(CONFIG_DOWNLOAD_FOLDER)),$(call 
 qstrip,$(CONFIG_DOWNLOAD_FOLDER)),$(TOPDIR)/dl)
 -BIN_DIR:=$(TOPDIR)/bin/$(BOARD)
 +DL_DIR:=$(if $(call qstrip,$(CONFIG_BINARY_FOLDER)),$(call 
 qstrip,$(CONFIG_BINARY_FOLDER)),$(TOPDIR)/bin/$(BOARD))
Shouldn't that be BIN_DIR?
  INCLUDE_DIR:=$(TOPDIR)/include
  SCRIPT_DIR:=$(TOPDIR)/scripts
  BUILD_DIR_BASE:=$(TOPDIR)/build_dir
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] add a option in menuconfig to set a custom folder for the images packages -- fix typo, sorry for this

[Hartmut Knaack]

Now I see. IMHO sending a [PATCH V2] would be the cleaner solution.

Oliver Ertl schrieb:
 Signed-off-by: Oliver Ertl oli...@ertls-netzwerk.de
 ---
  rules.mk | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/rules.mk b/rules.mk
 index 2d4d5c8..8594ca6 100644
 --- a/rules.mk
 +++ b/rules.mk
 @@ -80,7 +80,7 @@ ifdef CONFIG_MIPS64_ABI
  endif
  
  DL_DIR:=$(if $(call qstrip,$(CONFIG_DOWNLOAD_FOLDER)),$(call 
 qstrip,$(CONFIG_DOWNLOAD_FOLDER)),$(TOPDIR)/dl)
 -DL_DIR:=$(if $(call qstrip,$(CONFIG_BINARY_FOLDER)),$(call 
 qstrip,$(CONFIG_BINARY_FOLDER)),$(TOPDIR)/bin/$(BOARD))
 +BIN_DIR:=$(if $(call qstrip,$(CONFIG_BINARY_FOLDER)),$(call 
 qstrip,$(CONFIG_BINARY_FOLDER)),$(TOPDIR)/bin/$(BOARD))
  INCLUDE_DIR:=$(TOPDIR)/include
  SCRIPT_DIR:=$(TOPDIR)/scripts
  BUILD_DIR_BASE:=$(TOPDIR)/build_dir
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Freescale P1020 WLAN support?

[Hartmut Knaack]

John Clark schrieb:
 I have been looking and eventually found some set of patches which I have 
 been using that were posted in March.

 However, what was not clear from the various posts at that time was the 
 following:

 1) what SVN revision of OpenWRT that was used.
 2) whether anyone has done any further work.

 I found a reference to rev. 31088, which seem sort of close, but then I have 
 also tried
 using rev 31152 (which is about a day after the March 29 Patch posting.).

 In both cases some set of things break, with 'hunks' of patches being 
 rejected.

 The two files that 'break' the given set of patches are:

 110-fix_mpc8548_cds.patch
 100-fix_mpc8568e_mds.patch

Please provide full error log. From what I could see, the patch should apply 
without issues on those two files.
 Anyone have some information I'd appreciated it,

 John Clark.


 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/mailman/listinfo/openwrt-devel


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Linux 3.3.x has been EOLed ; time to move on ?

[Hartmut Knaack]

Hi,
my impression is, that a kernel version makes it into trunk if it is either a 
long term kernel, or it brings essential new functions. For 3.3 this was most 
certainly the introduction of BQL code. Keeping in mind that our main targets 
are network routers, the bufferbloat issue probably concerns most of the 
maintainers.

Emmanuel Deloget schrieb:
 Hello, 

 I understand that a lot of effort has been pushed in making 
 Linux 3.3 the trunk kernel, and I understand that I probably 
 missed long (IRC?) discussions on this very subject, but since 
 3.3.8 is going to be the last supported kernel in the 3.3.x 
 branch it might be a good idea to move on to another, more 
 recent kernel version - and to do it slightly better. Not 
 that anything is really bad, but there were obviously better 
 choices that 3.3 at the time it came up. 


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] ar9331's usb stability issue. eg.wr703n

[Hartmut Knaack]

This problem has also been discovered in the hardware hacking forum with 
wr841nd, and I had it on my wr1043nd (ar9132) 
(https://forum.openwrt.org/viewtopic.php?id=30839). The solution I found to 
be somehow working is to put a simple usb hub in between. But I would prefer to 
see a fix of the driver instead.

Vince Huang schrieb:
 Actually,I don't have a WR703N,but I got a 3G router with 4lan 1wan and a usb 
 port named wr743n v2 for Chinese market which also based on ar9331 soc.
 When I plug a HDD Dock with a 2TB WD Green HDD to it's usb port and then 
 write big files(500MB) through vsftp to reach 9-10mb/s transfer rates.The 
 device hang and reboot.However,the same dock works very fine on 
 wr843n(ar9341).
 Full serial messeges:
 http://pastebin.com/5ESfekWy
 It has been confirmed that two friends who have wr703Ns tried and found the 
 same problem.
 Sincerely hope that juhosg and other gurues can fix it.


 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/mailman/listinfo/openwrt-devel

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Exhausted on finding a gpio for USB_POWER...

[Hartmut Knaack]

Hi,
did you actually echo anything to /sys/class/gpio/gpioX/value?


Vince Huang schrieb:
 Hi,guys!
 I am finding the gpio to enable USB_POWER for tl-wr843n(arthoes ar9341).I've 
 tried out all gpio number just can't power up the usb(with factory firmware 
 it does).Can someone kind to help me solve this?
 These are the command I tried to find gpios,don't know if it's proper.But it 
 works on leds.
 root@OpenWrt:~# echo 6  /sys/class/gpio/export 
 root@OpenWrt:~# echo out  /sys/class/gpio/gpio6/direction 
 root@OpenWrt:~# echo 0  /sys/class/gpio/export 
 root@OpenWrt:~# echo out  /sys/class/gpio/gpio0/direction 
 root@OpenWrt:~# echo 1  /sys/class/gpio/export 
 root@OpenWrt:~# echo out  /sys/class/gpio/gpio1/direction 
 root@OpenWrt:~# echo 2  /sys/class/gpio/export 
 root@OpenWrt:~# echo out  /sys/class/gpio/gpio2/direction 
 root@OpenWrt:~# echo 3  /sys/class/gpio/export 
 root@OpenWrt:~# echo out  /sys/class/gpio/gpio3/direction 
 root@OpenWrt:~# echo 4  /sys/class/gpio/export 
 root@OpenWrt:~# echo out  /sys/class/gpio/gpio4/direction 
 Mach is attached. 




 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/mailman/listinfo/openwrt-devel

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] Initial support for Mikrotik RB751G-2HnD and RB751U-2HnD

[Hartmut Knaack]

It might help to send an e-mail to yourself with inline code and diff the 
received code with your original code files.
Take care

Hartmut


Hanno Schupp schrieb:
 I am at a loss then what to do. I even went to the length of installing 
 alpine on my pc just for the purpose of sending one email. 

 Why is this so hard? This makes porting openwrt to a new router model look 
 easy in comparison. I sent it to myself as a copy and it looked completely 
 normal to me. Where and how can I check it got mangled and how can I avoid it 
 getting it mangled. I followed the instructions in kernel.org for 
 email-clients and apparently the patch still gets mangled. Argh.

 Kind Regards

 Hanno 


 On 6/04/2012, at 9:24 AM, Jo-Philipp Wich x...@subsignal.org wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 It got line wrapped.

 ~ Jow
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.10 (GNU/Linux)
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

 iEYEARECAAYFAk9+DYgACgkQdputYINPTPPmbgCePy75NtkXFACVcCe01xA4Go7G
 9uAAn0DGSguFrkM+5U01dbltb4Yg9kbG
 =k+Hp
 -END PGP SIGNATURE-
 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/mailman/listinfo/openwrt-devel
 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/mailman/listinfo/openwrt-devel


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH V2] ar71xx: support for kernel 3.1

[Hartmut Knaack]

Sorry, but wrong thread. This is just 3.1, Gabor is seems to be maintaining 3.2.

Weedy schrieb:
 Big nasty FYI, NAND (ie mikrotik profile) is broken.


 make[5]: Leaving directory
 `/home/weedy/openwrt/build_dir/linux-ar71xx_nand/linux-3.2.1'

 LZMA 4.65 : Igor Pavlov : Public domain : 2009-02-03
 drivers/mtd/chips/cfi_cmdset_0002.c: In function 'cfi_amdstd_write_words':
 include/linux/mtd/map.h:330:11: warning: 'r$x$0' may be used
 uninitialized in this function
 fs/yaffs2/yaffs_vfs_glue.c:373:2: warning: initialization from
 incompatible pointer type
 fs/yaffs2/yaffs_vfs_glue.c:464:2: warning: initialization from
 incompatible pointer type
 fs/yaffs2/yaffs_vfs_glue.c: In function 'yaffs_fill_inode_from_obj':
 fs/yaffs2/yaffs_vfs_glue.c:1365:3: error: assignment of read-only member
 'i_nlink'
 fs/yaffs2/yaffs_vfs_glue.c: In function 'yaffs_unlink':
 fs/yaffs2/yaffs_vfs_glue.c:1813:3: error: decrement of read-only member
 'i_nlink'
 fs/yaffs2/yaffs_vfs_glue.c: In function 'yaffs_link':
 fs/yaffs2/yaffs_vfs_glue.c:1847:3: error: assignment of read-only member
 'i_nlink'
 fs/yaffs2/yaffs_vfs_glue.c: In function 'yaffs_rename':
 fs/yaffs2/yaffs_vfs_glue.c:1965:4: error: decrement of read-only member
 'i_nlink'
 fs/yaffs2/yaffs_vfs_glue.c: At top level:
 fs/yaffs2/yaffs_vfs_glue.c:3117:12: warning:
 'yaffs2_internal_read_super_mtd' defined but not used
 make[7]: *** [fs/yaffs2/yaffs_vfs_glue.o] Error 1
 make[6]: *** [fs/yaffs2] Error 2
 make[5]: *** [fs] Error 2
 make[5]: *** Waiting for unfinished jobs
 drivers/spi/spi-ath79.c: In function 'ath79_spi_setup_cs':
 drivers/spi/spi-ath79.c:119:20: warning: unused variable 'sp'
 drivers/net/phy/mdio-bitbang.c: In function 'mdiobb_read':
 drivers/net/phy/mdio-bitbang.c:158:11: warning: unused variable 'i'
 drivers/tty/serial/8250.c: In function 'serial8250_shutdown':
 drivers/tty/serial/8250.c:1728:19: warning: 'i' may be used
 uninitialized in this function
 make[4]: ***
 [/home/weedy/openwrt/build_dir/linux-ar71xx_nand/linux-3.2.1/.image] Error 2
 make[3]: *** [install] Error 2
 make[2]: *** [target/linux/install] Error 2
 make[1]: ***
 [/home/weedy/openwrt/staging_dir/target-mips_r2_uClibc-0.9.32/stamp/.target_install]
 Error 2
 make -r world: build failed. Please re-run make with V=99 to see what's
 going on
 make: *** [world] Error 1
 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/mailman/listinfo/openwrt-devel


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] adm5120: Linux 3.1 support

[Hartmut Knaack]

Jonas Gorski schrieb:
 Hi,


 On 22 January 2012 21:12, Hartmut Knaack knaac...@gmx.de wrote:
 Blow the dust off your adm5120 machines, here comes Linux 3.1 support. Main 
 issues:
 Any reason for choosing 3.1 over 3.2 (apart from 3.1 likely being
 easier ;)? 3.1 is EOL'd, it won't receive updates anymore.
Lazyness, experience, priorities - your choice. I started porting more than 2 
weeks ago, when 3.2 still lacked generic support in Openwrt and 3.1.8 was just 
out. Also, 3.1 came with some feature I need, while that's not the case with 
3.2 (from what I could see). But whoever feels like updating to 3.2 will 
certainly have less troubles starting with my patch than I had, starting from 
2.6.38. Anyway, like I mentioned in ar71xx, I will probably work on my next 
update when certain IIO drivers leave staging.

  - updated mtd api
  - many patches applied to usb, that ohci has received during the past years
  - some bits and pieces here and there
 Successfully built and basically tested with r29779 and Linux 3.1.10 on an 
 Edimax BR6104KP/Omnima Embedded Controller (Little Endian). Any feedback 
 appreciated.

 Signed-off-by: Hartmut Knaack knaack.h [at] gmx.de
 ---
 Index: target/linux/adm5120/router_be/config-3.1
 ===
 --- target/linux/adm5120/router_be/config-3.1   (Revision 0)
 +++ target/linux/adm5120/router_be/config-3.1   (Revision 0)
 @@ -0,0 +1,275 @@
 +CONFIG_32BIT=y
 +CONFIG_ADM5120=y
 +CONFIG_ADM5120_ENET=y
 +CONFIG_ADM5120_MACH_5GXI=y
 +CONFIG_ADM5120_MACH_BR_6104K=y
 +CONFIG_ADM5120_MACH_BR_6104KP=y
 +CONFIG_ADM5120_MACH_BR_61X4WG=y
 +CONFIG_ADM5120_MACH_CAS_771=y
 +CONFIG_ADM5120_MACH_EASY5120P_ATA=y
 +CONFIG_ADM5120_MACH_EASY5120_RT=y
 +CONFIG_ADM5120_MACH_EASY5120_WVOIP=y
 +CONFIG_ADM5120_MACH_EASY83000=y
 +CONFIG_ADM5120_MACH_EB_214A=y
 +CONFIG_ADM5120_MACH_NFS_101=y
 +CONFIG_ADM5120_MACH_NP27G=y
 +CONFIG_ADM5120_MACH_NP28G=y
 +CONFIG_ADM5120_MACH_PMUGW=y
 +CONFIG_ADM5120_MACH_RB_11X=y
 +CONFIG_ADM5120_MACH_RB_133=y
 +CONFIG_ADM5120_MACH_RB_133C=y
 +CONFIG_ADM5120_MACH_RB_150=y
 +CONFIG_ADM5120_MACH_RB_153=y
 +CONFIG_ADM5120_MACH_RB_192=y
 +CONFIG_ADM5120_MACH_WP54=y
 +CONFIG_ADM5120_OEM_CELLVISION=y
 +CONFIG_ADM5120_OEM_COMPEX=y
 +CONFIG_ADM5120_OEM_EDIMAX=y
 +CONFIG_ADM5120_OEM_GENERIC=y
 +CONFIG_ADM5120_OEM_INFINEON=y
 +CONFIG_ADM5120_OEM_MIKROTIK=y
 +CONFIG_ADM5120_OEM_MOTOROLA=y
 +CONFIG_ADM5120_OEM_OSBRIDGE=y
 +# CONFIG_ADM5120_OEM_ZYXEL is not set
 +CONFIG_ADM5120_SOC_BGA=y
 +CONFIG_ADM5120_WDT=y
 +# CONFIG_ALCHEMY_GPIO_INDIRECT is not set
 +# CONFIG_AR7 is not set
 +# CONFIG_ARCH_HAS_ILOG2_U32 is not set
 +# CONFIG_ARCH_HAS_ILOG2_U64 is not set
 +CONFIG_ARCH_HIBERNATION_POSSIBLE=y
 +# CONFIG_ARCH_PHYS_ADDR_T_64BIT is not set
 +CONFIG_ARCH_POPULATES_NODE_MAP=y
 +CONFIG_ARCH_REQUIRE_GPIOLIB=y
 +# CONFIG_ARCH_SUPPORTS_MSI is not set
 +CONFIG_ARCH_SUPPORTS_OPROFILE=y
 +CONFIG_ARCH_SUSPEND_POSSIBLE=y
 +CONFIG_ARM_AMBA=y
 +# CONFIG_ARM_SP805_WATCHDOG is not set
 +CONFIG_ATA=m
 +# CONFIG_ATH79 is not set
 +# CONFIG_BCM47XX is not set
 +# CONFIG_BCM63XX is not set
 +CONFIG_BITREVERSE=y
 +# CONFIG_CAVIUM_OCTEON_REFERENCE_BOARD is not set
 +# CONFIG_CAVIUM_OCTEON_SIMULATOR is not set
 +CONFIG_CC_OPTIMIZE_FOR_SIZE=y
 +CONFIG_CEVT_R4K=y
 +CONFIG_CEVT_R4K_LIB=y
 +CONFIG_CMDLINE=console=ttyS0,115200 rootfstype=squashfs,yaffs2,jffs2
 +CONFIG_CMDLINE_BOOL=y
 +# CONFIG_CMDLINE_OVERRIDE is not set
 +# CONFIG_CPU_BIG_ENDIAN is not set
 +CONFIG_CPU_HAS_PREFETCH=y
 +CONFIG_CPU_HAS_SYNC=y
 +CONFIG_CPU_LITTLE_ENDIAN=y
 +CONFIG_CPU_MIPS32=y
 +CONFIG_CPU_MIPS32_R1=y
 +CONFIG_CPU_MIPSR1=y
 +CONFIG_CPU_SUPPORTS_32BIT_KERNEL=y
 +CONFIG_CPU_SUPPORTS_HIGHMEM=y
 +CONFIG_CRYPTO=m
 +CONFIG_CRYPTO_AEAD2=m
 +CONFIG_CRYPTO_AES=m
 +CONFIG_CRYPTO_ALGAPI=m
 +CONFIG_CRYPTO_ALGAPI2=m
 +CONFIG_CRYPTO_ARC4=m
 +CONFIG_CRYPTO_BLKCIPHER=m
 +CONFIG_CRYPTO_BLKCIPHER2=m
 +CONFIG_CRYPTO_ECB=m
 +CONFIG_CRYPTO_HASH=m
 +CONFIG_CRYPTO_HASH2=m
 +CONFIG_CRYPTO_MANAGER=m
 +CONFIG_CRYPTO_MANAGER2=m
 I assume these are already part of the config file you used as a base,
 but can you try ro drop any =m symbols in the config? It should not
 have any ill effect, and should shrink the config.

 Index: target/linux/generic/patches-3.1/020-ssb_update.patch
 ===
 --- target/linux/generic/patches-3.1/020-ssb_update.patch   (Revision 
 29773)
 +++ target/linux/generic/patches-3.1/020-ssb_update.patch   
 (Arbeitskopie)
 Why do you need to touch this patch? It applies cleanly for me (at
 built fine for at least 3.1.9).

 This will break building b43, so NACK for this part.


 Regards
 Jonas
 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/mailman/listinfo/openwrt-devel

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt

Re: [OpenWrt-Devel] [PATCH V2] ar71xx: support for kernel 3.1

[Hartmut Knaack]

Otto Solares Cabrera schrieb:
 On Thu, Dec 08, 2011 at 11:57:46PM +0100, Hartmut Knaack wrote:
 juhosg was working quite hard to get us out of sync, with decent support of 
 nbd ;-) It took me a while, but we're finally back on the track. Minimum 
 kernel version is probably still 3.1.1. Successfully tested with kernel 
 3.1.4 on a WR1043ND. Kernel version in the Makefile still needs to be 
 adjusted manually. Any comments appreciated. Enjoy.
 Hi Harmut, do you have something for 3.2? I don't want to duplicate
 efforts :=)

I'd stick to 3.1 for the time being. As soon as IIO gets out of staging, I will 
probably do an update again :-)
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] adm5120: fix support for kernel 2.6.38

[Hartmut Knaack]

This patch fixes the following issues I encountered while compiling kernel 
2.6.38.8 for my Omnima Embedded Controller/Edimax BR6104KP:
- kernel comes up with machine selection during build, even though 
everything was properly set in menuconfig
- USB api changes
Successfully built and tested with r29755.

Signed-off-by: Hartmut Knaack knaack.h [at] gmx.de
---
Index: target/linux/adm5120/router_le/config-2.6.38
===
--- target/linux/adm5120/router_le/config-2.6.38(Revision 29755)
+++ target/linux/adm5120/router_le/config-2.6.38(Arbeitskopie)
@@ -47,6 +47,7 @@
 CONFIG_ARM_AMBA=y
 # CONFIG_ARM_SP805_WATCHDOG is not set
 CONFIG_ATA=m
+# CONFIG_ATH79 is not set
 # CONFIG_BCM47XX is not set
 # CONFIG_BCM63XX is not set
 CONFIG_BITREVERSE=y
Index: target/linux/adm5120/patches-2.6.38/010-adm5120_usb_new_api.patch
===
--- target/linux/adm5120/patches-2.6.38/010-adm5120_usb_new_api.patch
(Revision 0)
+++ target/linux/adm5120/patches-2.6.38/010-adm5120_usb_new_api.patch
(Revision 0)
@@ -0,0 +1,57 @@
+Index: drivers/usb/host/adm5120-hcd.c
+===
+--- a/drivers/usb/host/adm5120-hcd.c
 b/drivers/usb/host/adm5120-hcd.c
+@@ -32,6 +32,7 @@
+ #include linux/list.h
+ #include linux/usb.h
+ #include linux/usb/otg.h
++#include linux/usb/hcd.h
+ #include linux/dma-mapping.h
+ #include linux/dmapool.h
+ #include linux/reboot.h
+@@ -43,8 +44,6 @@
+ #include asm/unaligned.h
+ #include asm/byteorder.h
+
+-#include ../core/hcd.h
+-#include ../core/hub.h
+
+ #define DRIVER_VERSION0.27.0
+ #define DRIVER_AUTHORGabor Juhos juh...@openwrt.org
+@@ -571,7 +571,7 @@
+ periodic_reinit(ahcd);
+
+ /* use rhsc irqs after khubd is fully initialized */
+-hcd-poll_rh = 1;
++set_bit(HCD_FLAG_POLL_RH, hcd-flags);
+ hcd-uses_new_polling = 1;
+
+ #if 0
+@@ -688,7 +688,7 @@
+  */
+ admhc_vdbg(ahcd, Resume Detect\n);
+ admhc_intr_ack(ahcd, ADMHC_INTR_RESI);
+-hcd-poll_rh = 1;
++set_bit(HCD_FLAG_POLL_RH, hcd-flags);
+ if (ahcd-autostop) {
+ spin_lock(ahcd-lock);
+ admhc_rh_resume(ahcd);
+Index: drivers/usb/host/adm5120-hub.c
+===
+--- a/drivers/usb/host/adm5120-hub.c
 b/drivers/usb/host/adm5120-hub.c
+@@ -106,8 +106,11 @@
+ }
+ }
+
+-hcd-poll_rh = admhc_root_hub_state_changes(ahcd, changed,
+-any_connected);
++if (admhc_root_hub_state_changes(ahcd, changed,
++any_connected))
++  set_bit(HCD_FLAG_POLL_RH, hcd-flags);
++else
++  clear_bit(HCD_FLAG_POLL_RH, hcd-flags);
+
+ done:
+ spin_unlock_irqrestore(ahcd-lock, flags);

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] ar71xx: add support for TP-Link TL-MR3020 (V2.1)

[Hartmut Knaack]

Christian Cier-Zniewski schrieb:
 Sorry, patch v2 did not compile due to a typo.

 V2.1 compiles successfully.

 ---
 This patch adds support for the TP-Link device TL-MR3020 which is very 
 similiar to the TL-WR703N.
 The correct LED and button GPIO assignments have been added in this 
 second version of the patch.
 The TL-MR3020 uses 5 LEDs, 1 push button and a switch with 3 positions.
 Only four LEDs can be controlled via GPIO. The power LED is connected to 
 the power supply.
 The WPS push button has been mapped to KEY_WPS_BUTTON.
 The two GPIO signals of the sliding switch have been mapped to BTN_0 and 
 BTN_1.

 I have also setup a wiki page with details here:
 http://wiki.openwrt.org/toh/tp-link/tl-mr3020

 USB is working and has been tested with USB mass storage and USB UMTS stick.

 Wifi also seems to work.

 Ethernet is working too.

 Signed-off-by: Christian Cier-Zniewski c.c...@gmx.de


Hi,
even though you claim it to be very similar to the wr703, I would recommend to 
keep alphabetic sort order (meaning to put it next to the mr models instead of 
the wr models).
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH V3] ar71xx: support for kernel 3.1

[Hartmut Knaack]

Peter Naulls schrieb:
 On 12/22/2011 02:06 AM, Hartmut Knaack wrote:
 Caught up with the latest changes, mainly added machine support for
 wzr-hp-g300nh2 and hornet-ub. Successfully booted on WR1043ND with r29595
 running kernel 3.1.5.

 Mostly ok on G300NH, but:


 Jan  1 00:02:15 OpenWrt user.info sysinit: /etc/rc.common: eval: line 1: 
 can't 
 create /sys/class/leds/buffalo:blue:usb/device_name: nonexistent directory
 Jan  1 00:02:15 OpenWrt user.info sysinit: /etc/rc.common: eval: line 1: 
 can't 
 create /sys/class/leds/buffalo:blue:usb/activity_interval: nonexistent 
 director

 And I can't select USB and enable serial drivers I need in menuconfig.

Thanks for testing. This issue should be fixed in my new patch now.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel