Re: [OpenWrt-Devel] AR8334 switch support

2015-04-24 Thread Heiner Kallweit 
Am 23.04.2015 um 14:43 schrieb Christian Mehlis:
> Am 22.04.2015 um 19:01 schrieb Heiner Kallweit:
>> Can you provide a complete dmesg output?
> 
> Bootlog is available here:
> http://wiki.openwrt.org/toh/compex/wpj344#openwrt_upstream_bootlog
> 
> Dmesg is attached.
> 
>> W/o having seen the datasheets for AR8337/AR8334 I'm hesitant to propose a 
>> patch.
>> 1. AR8334 identifies itself as AR8337/rev.2. There might be a real 
>> AR8337/rev.2 with 7 ports. How to tell between these two chips?
> 
> Perhaps there are some other registers where the number of ports are 
> available? But I don't have any datasheets to look into...
> 
> Best
> Christian

This patch tries to identify an AR8334/AR8335 by checking for non-existent PHYs.
I have systems with AR8327 only, the patch doesn't do any harm on them at least.
Could you please test this patch and provide the dmesg output?

Rgds, Heiner

---
 target/linux/generic/files/drivers/net/phy/ar8216.c |  8 
 target/linux/generic/files/drivers/net/phy/ar8216.h | 21 +++--
 target/linux/generic/files/drivers/net/phy/ar8327.c | 17 ++---
 3 files changed, 37 insertions(+), 9 deletions(-)

diff --git a/target/linux/generic/files/drivers/net/phy/ar8216.c 
b/target/linux/generic/files/drivers/net/phy/ar8216.c
index e39d540..25bbfc2 100644
--- a/target/linux/generic/files/drivers/net/phy/ar8216.c
+++ b/target/linux/generic/files/drivers/net/phy/ar8216.c
@@ -38,7 +38,7 @@
 #include "ar8216.h"
 
 extern const struct ar8xxx_chip ar8327_chip;
-extern const struct ar8xxx_chip ar8337_chip;
+extern const struct ar8xxx_chip ar833x_chip;
 
 #define AR8XXX_MIB_WORK_DELAY  2000 /* msecs */
 
@@ -1576,8 +1576,8 @@ ar8xxx_id_chip(struct ar8xxx_priv *priv)
case AR8XXX_VER_AR8327:
priv->chip = &ar8327_chip;
break;
-   case AR8XXX_VER_AR8337:
-   priv->chip = &ar8337_chip;
+   case AR8XXX_VER_AR833X:
+   priv->chip = &ar833x_chip;
break;
default:
pr_err("ar8216: Unknown Atheros device [ver=%d, rev=%d]\n",
@@ -1856,7 +1856,7 @@ ar8xxx_phy_config_aneg(struct phy_device *phydev)
 static const u32 ar8xxx_phy_ids[] = {
0x004dd033,
0x004dd034, /* AR8327 */
-   0x004dd036, /* AR8337 */
+   0x004dd036, /* AR833X */
0x004dd041,
0x004dd042,
0x004dd043, /* AR8236 */
diff --git a/target/linux/generic/files/drivers/net/phy/ar8216.h 
b/target/linux/generic/files/drivers/net/phy/ar8216.h
index 0f53f23..a50fb9d 100644
--- a/target/linux/generic/files/drivers/net/phy/ar8216.h
+++ b/target/linux/generic/files/drivers/net/phy/ar8216.h
@@ -334,7 +334,7 @@ enum {
AR8XXX_VER_AR8236 = 0x03,
AR8XXX_VER_AR8316 = 0x10,
AR8XXX_VER_AR8327 = 0x12,
-   AR8XXX_VER_AR8337 = 0x13,
+   AR8XXX_VER_AR833X = 0x13,
 };
 
 #define AR8XXX_NUM_ARL_RECORDS 100
@@ -409,6 +409,8 @@ struct ar8xxx_priv {
void *chip_data;
bool initialized;
bool port4_phy;
+   bool unavailable_phys[AR8XXX_NUM_PHYS];
+   int num_unavailable_phys;
char buf[2048];
struct arl_entry arl_table[AR8XXX_NUM_ARL_RECORDS];
char arl_buf[AR8XXX_NUM_ARL_RECORDS * 32 + 256];
@@ -562,9 +564,24 @@ static inline bool chip_is_ar8327(struct ar8xxx_priv *priv)
return priv->chip_ver == AR8XXX_VER_AR8327;
 }
 
+static inline bool chip_is_ar833x(struct ar8xxx_priv *priv)
+{
+   return priv->chip_ver == AR8XXX_VER_AR833X;
+}
+
+static inline bool chip_is_ar8334(struct ar8xxx_priv *priv)
+{
+   return chip_is_ar833x(priv) && priv->num_unavailable_phys == 3;
+}
+
+static inline bool chip_is_ar8335(struct ar8xxx_priv *priv)
+{
+   return chip_is_ar833x(priv) && priv->num_unavailable_phys == 2;
+}
+
 static inline bool chip_is_ar8337(struct ar8xxx_priv *priv)
 {
-   return priv->chip_ver == AR8XXX_VER_AR8337;
+   return chip_is_ar833x(priv) && priv->num_unavailable_phys == 0;
 }
 
 static inline void
diff --git a/target/linux/generic/files/drivers/net/phy/ar8327.c 
b/target/linux/generic/files/drivers/net/phy/ar8327.c
index 07e837e..a25372f 100644
--- a/target/linux/generic/files/drivers/net/phy/ar8327.c
+++ b/target/linux/generic/files/drivers/net/phy/ar8327.c
@@ -620,7 +620,18 @@ ar8327_hw_config_of(struct ar8xxx_priv *priv, struct 
device_node *np)
 static int
 ar8327_hw_init(struct ar8xxx_priv *priv)
 {
-   int ret;
+   int i, ret;
+
+   for (i = 0; i < AR8XXX_NUM_PHYS; i++)
+   /* certain bits are always set if the PHY exists */
+   if (!mdiobus_read(priv->mii_bus, i, MII_BMSR)) {
+   priv->unavailable_phys[i] = true;
+   priv->num_unavailable_phys++;
+   dev_info(&priv->phy->dev, "PHY %d not available\n", i);
+   }
+   if (chip_is_ar833x(priv))
+dev_info(&priv->phy->dev, "Detected AR833%d switch\n",
+ AR8327_NUM_PORTS - pri

[OpenWrt-Devel] [PATCH] mtd: correct/change warning text about partition split / read-only status

2015-04-24 Thread Hannu Nyman 
Since the kernel/rootfs split handling was modified 2 years ago by r37283 ( 
https://dev.openwrt.org/changeset/37283 ) and by the subsequent checkins, 
users have seen rather scary mtd errors in the log at every boot. The message 
ends "-- forcing read-only", which looks a bit error-like. That error has 
been mentioned in some forum threads, when users have noticed this message 
instead of some actual error.


[2.94] 0x0007-0x00ff : "firmware"
[2.97] 2 netgear-fw partitions found on MTD device firmware
[2.97] 0x0007-0x00188440 : "kernel"
[2.98] mtd: partition "kernel" must either start or end on erase 
block boundary or be smaller than an erase block -- forcing read-only

[2.99] 0x00188440-0x00ff : "rootfs"
[2.99] mtd: partition "rootfs" must either start or end on erase 
block boundary or be smaller than an erase block -- forcing read-only

[3.01] mtd: device 4 (rootfs) set to be root filesystem
[3.01] 1 squashfs-split partitions found on MTD device rootfs
[3.02] 0x0066-0x00ff : "rootfs_data"

The error text 'mtd: partition "kernel" must either start or end on erase 
block boundary or be smaller than an erase block -- forcing read-only' 
originates from 6 years ago, when nbd checked in r17658 to kernel 2.6.30.

https://dev.openwrt.org/changeset/17658
https://dev.openwrt.org/browser/trunk/target/linux/generic-2.6/patches-2.6.30/222-partial_eraseblock_write.patch?rev=17658

At that time, this message was rarely shown, as it was normal to have padding 
after kernel, so that rootfs started at the next block boundary. Currently 
many platforms have kernel & rootfs tightly packed without padding in 
between, so the message is shown quite frequently.


Additionally, I think that the original warning message has a logical fault: 
the first "or" should be "and". It should say "must either start AND end on 
erase block boundary or be smaller than an erase block".  (otherwise 'kernel' 
should not cause the warning message as it starts at a boundary...). The 
logic in 411-mtd-partial_eraseblock_write.patch is pretty hard to follow, but 
that is my reading about the correct reasoning.
https://dev.openwrt.org/browser/trunk/target/linux/generic/patches-3.18/411-mtd-partial_eraseblock_write.patch 



I propose that the message class is changed from a kernel warning to a kernel 
info message and the text is changed to be less scary: 'partition "kernel" is 
read-only: it does not start and end at erase block boundary and is larger 
than a single block'


[2.97] 2 netgear-fw partitions found on MTD device firmware
[2.97] 0x0007-0x00188440 : "kernel"
[2.98] mtd: partition "kernel" is read-only: it does not start and 
end at erase block boundary and is larger than a single block

[2.99] 0x00188440-0x00ff : "rootfs"
[2.99] mtd: partition "rootfs" is read-only: it does not start and 
end at erase block boundary and is larger than a single block



I would prefer to shorten the message even more, but I didn't invent a 
suitable short but informative wording. (Althoug as this is currently most 
often just an informative notice, I am not quite sure if the logic needs to 
be explained quite that closely in the message.)


Signed-off-by: Hannu Nyman 

--- target/linux/generic/patches-3.18/411-mtd-partial_eraseblock_write.patch
+++ target/linux/generic/patches-3.18/411-mtd-partial_eraseblock_write.patch
@@ -126,7 +126,7 @@
 +  slave->mtd.erasesize = slave->mtd.size;
}
 +  if ((slave->mtd.flags & (MTD_ERASE_PARTIAL|MTD_WRITEABLE)) == 
MTD_ERASE_PARTIAL)
-+  printk(KERN_WARNING"mtd: partition \"%s\" must either start or 
end on erase block boundary or be smaller than an erase block -- forcing 
read-only\n",
++  printk(KERN_INFO"mtd: partition \"%s\" is read-only: it does 
not start and end at erase block boundary and is larger than a single block\n",
 +  part->name);
  
slave->mtd.ecclayout = master->ecclayout;
--- target/linux/generic/patches-4.0/411-mtd-partial_eraseblock_write.patch
+++ target/linux/generic/patches-4.0/411-mtd-partial_eraseblock_write.patch
@@ -126,7 +126,7 @@
 +  slave->mtd.erasesize = slave->mtd.size;
}
 +  if ((slave->mtd.flags & (MTD_ERASE_PARTIAL|MTD_WRITEABLE)) == 
MTD_ERASE_PARTIAL)
-+  printk(KERN_WARNING"mtd: partition \"%s\" must either start or 
end on erase block boundary or be smaller than an erase block -- forcing 
read-only\n",
++  printk(KERN_INFO"mtd: partition \"%s\" is read-only: it does 
not start and end at erase block boundary and is larger than a single block\n",
 +  part->name);
  
slave->mtd.ecclayout = master->ecclayout;
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt

Re: [OpenWrt-Devel] Fwd: Re: [PATCH 10/10] brcmfmac: Add support for multiple PCIE devices in nvram.

2015-04-24 Thread Rafał Miłecki 
On 23 April 2015 at 13:14, Hante Meuleman  wrote:
> Attached are
> three files, one is from brcmfmac (firmware.c). This file is
> added to demo how brcmfmac will use a new function of
> bm47xx_nvram. The changes in this file are currently under
> internal review and the patch may change, but it has been
> tested and verified so it can be used to try it out.

There exists a diff/patch format for a very good reason. Please send
patches, so I can review your changes.


> The other
> two files bcm47xx_nvram.c and bcm47xx_nvram.h are
> OpenWRT specific kernel files.

Not really, they are part of the kernel. I was working for last few
months moving them out of MIPS arch code.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Fwd: Re: [PATCH 10/10] brcmfmac: Add support for multiple PCIE devices in nvram.

2015-04-24 Thread Hante Meuleman 
Do you want the patch on top of 

target/linux/bcm53xx/patches-3.18/110-firmware-backport-NVRAM-driver.patch

Or on top of the unpatched

drivers/firmware/broadcom/bcm47xx_nvram.c

Or on top of the kernel driver file where 110-firmwarepatch 
already has been applied?

Or on top of the file

target/linux/bcm53xx/files/drivers/firmware/Broadcom/bcm47xx_nvram.c

The latter would be the easiest, but it probably breaks the 110 patch.

In upstream kernels the bcm47xx_nvram is not part of the kernel, 
this made me believe that it was generated with a patch file. 
Didn’t realize that the OpenWRT also has a files directory from
which the additional kernel drivers get "injected" in the kernel:

target/linux/bcm53xx/files/drivers/firmware/broadcom

Still this makes me believe they are openwrt specific kernel file,
but I guess, that is just how one wants to read this sentence.

-Original Message-
On 23 April 2015 at 13:14, Hante Meuleman  wrote:
> Attached are
> three files, one is from brcmfmac (firmware.c). This file is
> added to demo how brcmfmac will use a new function of
> bm47xx_nvram. The changes in this file are currently under
> internal review and the patch may change, but it has been
> tested and verified so it can be used to try it out.

There exists a diff/patch format for a very good reason. Please send
patches, so I can review your changes.


> The other
> two files bcm47xx_nvram.c and bcm47xx_nvram.h are
> OpenWRT specific kernel files.

Not really, they are part of the kernel. I was working for last few
months moving them out of MIPS arch code.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Fwd: Re: [PATCH 10/10] brcmfmac: Add support for multiple PCIE devices in nvram.

2015-04-24 Thread Rafał Miłecki 
On 24 April 2015 at 10:18, Hante Meuleman  wrote:
> Do you want the patch on top of
>
> target/linux/bcm53xx/patches-3.18/110-firmware-backport-NVRAM-driver.patch
>
> Or on top of the unpatched
>
> drivers/firmware/broadcom/bcm47xx_nvram.c
>
> Or on top of the kernel driver file where 110-firmwarepatch
> already has been applied?
>
> Or on top of the file
>
> target/linux/bcm53xx/files/drivers/firmware/Broadcom/bcm47xx_nvram.c
>
> The latter would be the easiest, but it probably breaks the 110 patch.
>
> In upstream kernels the bcm47xx_nvram is not part of the kernel,
> this made me believe that it was generated with a patch file.
> Didn’t realize that the OpenWRT also has a files directory from
> which the additional kernel drivers get "injected" in the kernel:
>
> target/linux/bcm53xx/files/drivers/firmware/broadcom
>
> Still this makes me believe they are openwrt specific kernel file,
> but I guess, that is just how one wants to read this sentence.

NVRAM driver is part of upstream kernel, it's just living in arch/mips/ for now:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/mips/bcm47xx/nvram.c

bcm53xx's file is just a copy of above and that would be the best to
keep it this way.

I think you may prepare patch on top of
drivers/firmware/broadcom/bcm47xx_nvram.c for now, then we can work on
upstreaming it. Meanwhile I'll be happy to add your patch to
/home/zajec/openwrt/openwrt.git/target/linux/bcm53xx/patches-3.18/

It doesn't matter if you work on top of
110-firmware-backport-NVRAM-driver.patch, it doesn't even touch
(bcm47xx_)nvram.c.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Fwd: Re: [PATCH 10/10] brcmfmac: Add support for multiple PCIE devices in nvram.

2015-04-24 Thread Hante Meuleman 
Attached are the two patch files. They were generated from
include/linux/bcm47xx_nvram.h and from 
drivers/firmware/broadcom/bcm47xx_nvram.c.

Sorry about the confusion regarding the

target/linux/bcm53xx/patches-3.18/110-firmware-backport-NVRAM-driver.patch

I was looking at an older repo where this patch was different.

-Original Message-
> Do you want the patch on top of
>
> target/linux/bcm53xx/patches-3.18/110-firmware-backport-NVRAM-driver.patch
>
> Or on top of the unpatched
>
> drivers/firmware/broadcom/bcm47xx_nvram.c
>
> Or on top of the kernel driver file where 110-firmwarepatch
> already has been applied?
>
> Or on top of the file
>
> target/linux/bcm53xx/files/drivers/firmware/Broadcom/bcm47xx_nvram.c
>
> The latter would be the easiest, but it probably breaks the 110 patch.
>
> In upstream kernels the bcm47xx_nvram is not part of the kernel,
> this made me believe that it was generated with a patch file.
> Didn’t realize that the OpenWRT also has a files directory from
> which the additional kernel drivers get "injected" in the kernel:
>
> target/linux/bcm53xx/files/drivers/firmware/broadcom
>
> Still this makes me believe they are openwrt specific kernel file,
> but I guess, that is just how one wants to read this sentence.

NVRAM driver is part of upstream kernel, it's just living in arch/mips/ for now:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/mips/bcm47xx/nvram.c

bcm53xx's file is just a copy of above and that would be the best to
keep it this way.

I think you may prepare patch on top of
drivers/firmware/broadcom/bcm47xx_nvram.c for now, then we can work on
upstreaming it. Meanwhile I'll be happy to add your patch to
/home/zajec/openwrt/openwrt.git/target/linux/bcm53xx/patches-3.18/

It doesn't matter if you work on top of
110-firmware-backport-NVRAM-driver.patch, it doesn't even touch
(bcm47xx_)nvram.c.


bcm47xx_nvram.c.patch
Description: bcm47xx_nvram.c.patch


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

Re: [OpenWrt-Devel] dnsmasq and --dhcp-relay option ?

2015-04-24 Thread openwrt-de...@couprie.net 

Could something likes this be added ?

--- dnsmasq.orig2015-04-24 12:14:51.453093251 +0200
+++ dnsmasq2015-04-24 12:15:15.121092827 +0200
@@ -416,6 +416,10 @@
 xappend 
"--dhcp-range=$networkid,$START,$END,$NETMASK,$leasetime${options:+ 
$options}"


 dhcp_option_add "$cfg" "$networkid"
+
+config_get relay "$cfg" relay
+network_get_ipaddr interface_ip "$networkid"
+xappend "--dhcp-relay=$interface_ip,$relay"
 }

 dhcp_option_add() {

Perry

On 23-04-15 23:20, Kevin Darbyshire-Bryant wrote:

On 23/04/2015 21:55, openwrt-de...@couprie.net wrote:

Hi,

I need the dnsmasq --dhcp-relay option, how do i add this option to 
the dnsmasq script ?


Perry


You could edit '/etc/dnsmasq.conf' and add your option/s directly to 
it.  Does that achieve your aim?


Kevin


___
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] Fwd: Re: [PATCH 10/10] brcmfmac: Add support for multiple PCIE devices in nvram.

2015-04-24 Thread Rafał Miłecki 
On 24 April 2015 at 12:03, Hante Meuleman  wrote:
> Attached are the two patch files. They were generated from
> include/linux/bcm47xx_nvram.h and from
> drivers/firmware/broadcom/bcm47xx_nvram.c.

I think your idea is correct, I was just thinking about bcm47xx_nvram
copying content to provided buffer, instead of sharing its own. I got
an impression it's solution usually used when dealing with such
situations & this would also protect bcm47xx internals.

I'm not really sure how to submit this patch. It exports symbol and
will be required by brcmfmac, so I guess we should ask Kalle to pick
it. However I also planned moving nvram.c from mips to bcm47xx_nvram.c
in firmware and I planned to submit this patch to Ralf (mips
maintainer).

Maybe it'll be better to work on moving NVRAM driver first? This would
make more sense to Kalle accepting drivers/firmware/ patch rather than
arch/mips/. We could keep this change in OpenWrt for now. I could
submit patch to Ralf for 3.2 kernel. Then for 3.3 we could finally
upstream your change to Kalle's tree.

Can you also share your brcmfmac patch?
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH][RFC] ramips:Add support for HiWiFi HC5761.

2015-04-24 Thread Yousong Zhou 
Hi, Chuanhong

Sorry for this late reply, but the email was placed in my Spam folder
by Gmail.  Looks like there is something wrong with your mail setup.

On 19 April 2015 at 00:02, 郭传鈜  wrote:
> Hi,all!
>   I'm trying to add support for HiWiFi HC5761 router,This patch works 
> fine.Because the mac address is not saved in factory partition and I think my 
> way to deal with this problem is not so good,I hope I could get some 
> suggestions for this patch.
>   HiWiFi HC5761 is a dual band router with mt7620a SoC.It has 3 network 
> interface,SD card and USB.
> There is an MT7610E for 5G wireless but there is no open-source driver to 
> support this.I enabled the PCI-E interface so that I could use the 
> proprietary driver from MTK.
> MAC address is not in factory partition.It is defined in bdinfo partition in 
> ascii format.
> With 'strings' command we could see such a line:Vfac_mac = XX:XX:XX:XX:XX:XX
> There is a space between 'Vfac_mac' and '=' so 'mtd_get_mac_ascii' function 
> in /lib/functions/system.sh doesn't work.I copied the function and added a 
> space in the sed command.
> Because of the mac address,the calibration data for wireless should't be read 
> from mtd partition directly.I used the hotplug script to generate the 
> calibration data for the wireless driver.
> I think I added too much code for the MAC address:-( I wonder if there is a 
> better way to do this.

I do not have HC5761 but think it's just a HC5661 with 802.11ac
capability.  For the MT7610E chip, maybe you can give the mt76 [1]
driver a try.

For the ascii MAC address in bdinfo partition, $(mtd_get_mac_ascii
"bdinfo" "Vfac_mac ") works for me on HC5661.  But I prefer something
like mtd-mac-address directive in DTS as done in patch [2].

 [1] https://github.com/openwrt/mt76
 [2] target/linux/ramips/patches-3.18/0034-NET-add-of_get_mac_address_mtd.patch

More comments inline.

> Best regards.
> Guo Chuanhong
>
> Signed-off-by: 郭传鈜 
> ---
>  target/linux/ramips/base-files/etc/board.d/01_leds |   5 +
>  .../linux/ramips/base-files/etc/board.d/02_network |  20 +++
>  target/linux/ramips/base-files/etc/diag.sh |   3 +
>  .../etc/hotplug.d/firmware/10-rt2x00-eeprom|  39 +-
>  target/linux/ramips/base-files/lib/ramips.sh   |   3 +
>  .../ramips/base-files/lib/upgrade/platform.sh  |   1 +
>  target/linux/ramips/dts/HiWiFi-HC5761.dts  | 155 
> +
>  target/linux/ramips/image/Makefile |   3 +
>  8 files changed, 228 insertions(+), 1 deletion(-)
>  create mode 100644 target/linux/ramips/dts/HiWiFi-HC5761.dts
>
> diff --git a/target/linux/ramips/base-files/etc/board.d/01_leds 
> b/target/linux/ramips/base-files/etc/board.d/01_leds
> index 56ba3b7..e20732d 100755
> --- a/target/linux/ramips/base-files/etc/board.d/01_leds
> +++ b/target/linux/ramips/base-files/etc/board.d/01_leds
> @@ -222,6 +222,11 @@ case $board in
> set_usb_led "wr8305rt:usb"
> set_wifi_led "wr8305rt:wifi"
> ;;
> +   hiwifi-hc5761)
> +   ucidef_set_led_default "system" "system" "hiwifi:blue:system" 
> "1"
> +   ucidef_set_led_netdev "internet" "internet" 
> "hiwifi:blue:internet" "eth0.2"

Maybe ucidef_set_led_interface from /lib/functions/uci-defaults-new.sh
is the current recommended way to setting this.  Also please use
"hiwifi:blue:wan" for the LED name.  That seems to be the current
naming convention.

> +   set_wifi_led "hiwifi:blue:wlan-2p4"
> +   ;;
> wt1520)
> set_wifi_led "rt2800pci-phy0::radio"
> ;;
> diff --git a/target/linux/ramips/base-files/etc/board.d/02_network 
> b/target/linux/ramips/base-files/etc/board.d/02_network
> index 24e1ba8..615baa4 100755
> --- a/target/linux/ramips/base-files/etc/board.d/02_network
> +++ b/target/linux/ramips/base-files/etc/board.d/02_network
> @@ -223,6 +223,7 @@ ramips_setup_interfaces()
> ucidef_add_switch_vlan "switch0" "2" "4 6t"
> ;;
>
> +   hiwifi-hc5761 | \
> y1s)
> ucidef_set_interfaces_lan_wan "eth0.1" "eth0.2"
> ucidef_add_switch "switch0" "1" "1"
> @@ -288,6 +289,25 @@ ramips_setup_macs()
> wan_mac=$(macaddr_add "$lan_mac" 4)
> ;;
>
> +   hiwifi-hc5761)
> +   local part
> +   local mac_dirty
> +
> +   part=$(find_mtd_part "bdinfo")
> +   if [ -z "$part" ]; then
> +   echo "hiwifi_get_mac: partition bdinfo not found!" >&2
> +   return
> +   fi
> +
> +   mac_dirty=$(strings "$part" | sed -n 's/^'"Vfac_mac "'=//p')
> +
> +   # "canonicalize" mac
> +   [ -n "$mac_dirty" ] && {
> +   lan_mac=$(macaddr_canonicalize "$mac_dirty")
> +   }
> +   wan_mac=$(macaddr_add "$lan_mac" 1)
> +   ;;

Changes

Re: [OpenWrt-Devel] dnsmasq and --dhcp-relay option ?

2015-04-24 Thread openwrt-de...@couprie.net 

The diff is for /etc/init.d/dnsmasq

This diff works for me, it puts the following change in 
/var/etc/dnsmasq.conf


dhcp-relay=192.168.200.1,10.255.255.225

What do i need to change to submit it as a patch ?

Comments are welome :-)

Perry

On 24-04-15 13:21, Kevin Darbyshire-Bryant wrote:

On 24/04/2015 11:17, Perry Couprie wrote:

And something like this ?

--- dnsmasq.orig2015-04-24 12:14:51.453093251 +0200
+++ dnsmasq2015-04-24 12:15:15.121092827 +0200
@@ -416,6 +416,10 @@
 xappend 
"--dhcp-range=$networkid,$START,$END,$NETMASK,$leasetime${options:+ 
$options}"


 dhcp_option_add "$cfg" "$networkid"
+
+config_get relay "$cfg" relay
+network_get_ipaddr interface_ip "$networkid"
+xappend "--dhcp-relay=$interface_ip,$relay"
 }

 dhcp_option_add() {

Perry

That syntax won't work in /etc/dnsmasq.conf - it only understands 
dnsmasq options, not .init/uci script options which would then be 
passed to dnsmasq by /var/etc/dnsmasq.conf.  If you were talking about 
extending uci so that it understood additional dnsmasq options then 
I'm afraid you're beyond my level of knowledge. Stuff that uci doesn't 
know about and is relatively static I've put into /etc/dnsmasq.conf 
manually as /var/etc/dnsmasq.conf references /etc/dnsmasq.conf for 
just such user customisation purposes.


I hope that helps.

Kevin




On 24-04-15 07:48, Kevin Darbyshire-Bryant wrote:

Hi Perry,

The /etc/dnsmasq.conf file is outside of uci control,  so it doesn't 
get rebuilt at process start/stop and gets preserved across 
reboots/upgrades.  It's an ideal place for tweaks and options that 
the uci interface is not yet aware.  I use it all the time.  Edit 
with your favourite text editor.


Kevin


--
Cheers,

ke...@darbyshire-bryant.me.uk 


On 24 Apr 2015, at 00:10, Perry Couprie > wrote:



Can this be done by using uci commands ?

Perry

On 23-04-15 23:20, Kevin Darbyshire-Bryant wrote:

On 23/04/2015 21:55, openwrt-de...@couprie.net wrote:

Hi,

I need the dnsmasq --dhcp-relay option, how do i add this option 
to the dnsmasq script ?


Perry


You could edit '/etc/dnsmasq.conf' and add your option/s directly 
to it.  Does that achieve your aim?


Kevin


___
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] dnsmasq and --dhcp-relay option ?

2015-04-24 Thread Bruno Randolf 
On 04/24/2015 02:26 PM, openwrt-de...@couprie.net wrote:
> The diff is for /etc/init.d/dnsmasq
> 
> This diff works for me, it puts the following change in
> /var/etc/dnsmasq.conf
> 
> dhcp-relay=192.168.200.1,10.255.255.225
> 
> What do i need to change to submit it as a patch ?

Look at https://dev.openwrt.org/wiki/SubmittingPatches

In short:

 - Base your patch on openwrt trunk, git or svn version.

 - Create the patch from the top directory or via "git diff" so it
includes the full path.

 - Add a Signed-off-by line

 - Send with [PATCH] as subject prefix

 - Be careful that your email program does not line-wrap or otherwise
modify the patch. Best to use "git send-email" directly...

Hope that helps,
bruno


> Comments are welome :-)
> 
> Perry
> 
> On 24-04-15 13:21, Kevin Darbyshire-Bryant wrote:
>> On 24/04/2015 11:17, Perry Couprie wrote:
>>> And something like this ?
>>>
>>> --- dnsmasq.orig2015-04-24 12:14:51.453093251 +0200
>>> +++ dnsmasq2015-04-24 12:15:15.121092827 +0200
>>> @@ -416,6 +416,10 @@
>>>  xappend
>>> "--dhcp-range=$networkid,$START,$END,$NETMASK,$leasetime${options:+
>>> $options}"
>>>  
>>>  dhcp_option_add "$cfg" "$networkid"
>>> +
>>> +config_get relay "$cfg" relay
>>> +network_get_ipaddr interface_ip "$networkid"
>>> +xappend "--dhcp-relay=$interface_ip,$relay"
>>>  }
>>>  
>>>  dhcp_option_add() {
>>>
>>> Perry
>>>
>> That syntax won't work in /etc/dnsmasq.conf - it only understands
>> dnsmasq options, not .init/uci script options which would then be
>> passed to dnsmasq by /var/etc/dnsmasq.conf.  If you were talking about
>> extending uci so that it understood additional dnsmasq options then
>> I'm afraid you're beyond my level of knowledge.  Stuff that uci
>> doesn't know about and is relatively static I've put into
>> /etc/dnsmasq.conf manually as /var/etc/dnsmasq.conf references
>> /etc/dnsmasq.conf for just such user customisation purposes.
>>
>> I hope that helps.
>>
>> Kevin
>>
>>
>>
>>> On 24-04-15 07:48, Kevin Darbyshire-Bryant wrote:
 Hi Perry,

 The /etc/dnsmasq.conf file is outside of uci control,  so it doesn't
 get rebuilt at process start/stop and gets preserved across
 reboots/upgrades.  It's an ideal place for tweaks and options that
 the uci interface is not yet aware.  I use it all the time.  Edit
 with your favourite text editor.

 Kevin


 -- 
 Cheers,

 ke...@darbyshire-bryant.me.uk 


 On 24 Apr 2015, at 00:10, Perry Couprie >>> > wrote:

> Can this be done by using uci commands ?
>
> Perry
>
> On 23-04-15 23:20, Kevin Darbyshire-Bryant wrote:
>> On 23/04/2015 21:55, openwrt-de...@couprie.net wrote:
>>> Hi,
>>>
>>> I need the dnsmasq --dhcp-relay option, how do i add this option
>>> to the dnsmasq script ?
>>>
>>> Perry
>>
>> You could edit '/etc/dnsmasq.conf' and add your option/s directly
>> to it.  Does that achieve your aim?
>>
>> Kevin
>>
>>
>> ___
>> 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