Re: [OpenWrt-Devel] [PATCH 1/3] [ubox] validate: fix indentation
Hi,
blogic@debian:/openwrt/ubox$ git am 5748
Applying: validate: fix indentation
blogic@debian:/openwrt/ubox$ git am 5749
Applying: validate: fix indentation
error: patch failed: validate/validate.c:882
error: validate/validate.c: patch does not apply
Patch failed at 0001 validate: fix indentation
When you have resolved this problem run git am --resolved.
If you would prefer to skip this patch, instead run git am --skip.
To restore the original branch and stop patching run git am --abort.
blogic@debian:/openwrt/ubox$ git am --abort
blogic@debian:/openwrt/ubox$ patch -p1 5749
patching file validate/validate.c
Reversed (or previously applied) patch detected! Assume -R? [n] n
Apply anyway? [n] y
Hunk #1 FAILED at 882.
1 out of 1 hunk FAILED -- saving rejects to file validate/validate.c.rej
blogic@debian:/openwrt/ubox$
On 27/06/2014 11:09, Luka Perkov wrote:
Signed-off-by: Luka Perkov l...@openwrt.org ---
validate/validate.c | 88
++--- 1 file
changed, 44 insertions(+), 44 deletions(-)
diff --git a/validate/validate.c b/validate/validate.c index
150c08d..f550e76 100644 --- a/validate/validate.c +++
b/validate/validate.c @@ -882,50 +882,50 @@ dt_type_uci(struct
dt_state *s, int nargs)
static struct dt_fun dt_types[] = { - { or,
DT_INVALID,
dt_type_or}, -{ and,
DT_INVALID, dt_type_and }, -{
not,DT_INVALID, dt_type_not
}, -{ neg,DT_INVALID,
dt_type_neg }, -{ list,
DT_INVALID, dt_type_list}, -{
min,DT_NUMBER, dt_type_min
}, -{ max,DT_NUMBER,
dt_type_max }, -{ range,
DT_NUMBER, dt_type_range }, -{
minlength, DT_STRING, dt_type_minlen }, -
{ maxlength,
DT_STRING,dt_type_maxlen }, -{ rangelength,
DT_STRING,
dt_type_rangelen }, -{ integer,DT_NUMBER,
dt_type_int }, -
{ uinteger, DT_NUMBER, dt_type_uint}, -
{ float,
DT_NUMBER,dt_type_float }, -{ ufloat,
DT_NUMBER,
dt_type_ufloat}, -{ bool,
DT_BOOL,dt_type_bool}, -{
string, DT_STRING, dt_type_string
}, -{ hexstring,
DT_STRING,dt_type_hexstring }, -{ ip4addr,
DT_STRING,
dt_type_ip4addr }, -{ ip6addr,DT_STRING,
dt_type_ip6addr
}, - { ipaddr, DT_STRING, dt_type_ipaddr
}, -{ cidr4,
DT_STRING,dt_type_cidr4 }, -{ cidr6,
DT_STRING,
dt_type_cidr6 }, -{ cidr, DT_STRING,
dt_type_cidr}, -{
netmask4, DT_STRING, dt_type_netmask4}, -
{ netmask6,
DT_STRING,dt_type_netmask6}, -{ ipmask4,
DT_STRING,
dt_type_ipmask4 }, -{ ipmask6,DT_STRING,
dt_type_ipmask6
}, - { ipmask, DT_STRING, dt_type_ipmask
}, -{ port,
DT_NUMBER,dt_type_port}, -{ portrange,
DT_STRING,
dt_type_portrange }, -{ macaddr,DT_STRING,
dt_type_macaddr
}, - { uciname,DT_STRING, dt_type_uciname
}, -{ wpakey,
DT_STRING,dt_type_wpakey }, -{ wepkey,
DT_STRING,
dt_type_wepkey}, -{ hostname, DT_STRING,
dt_type_hostname
}, - { host, DT_STRING, dt_type_host
}, -{ network,
DT_STRING,dt_type_network }, -{ phonedigit,
DT_STRING,
dt_type_phonedigit}, -{ directory, DT_STRING,
dt_type_directory }, -{ device, DT_STRING,
dt_type_device
}, - { file, DT_STRING, dt_type_file
}, -{ regex,
DT_STRING,dt_type_regex }, -{ uci,
DT_STRING, dt_type_uci
}, + { or, DT_INVALID, dt_type_or }, +
{ and,DT_INVALID,
dt_type_and }, +{ not,DT_INVALID,
dt_type_not }, +{ neg,
DT_INVALID, dt_type_neg }, +{ list,
[OpenWrt-Devel] [Patch] Support for BMP085 pressure sensor
Hello ! Bosch Sensortec is one of most popular pressure sensors for building home weather stations, its cheap and easy to use. I decided to add two packages for each bus type because device usually have only one barometer and we does no need to waste firmware space for unused bus. Tested on trunk, ar71xx (ML2030) with kernel 3.10, i2c only (due absent of spi version), but I added patch files for all current kernels. === --- a/target/linux/generic/patches-3.6/263-bmp085_dynamic.patch 1970-01-01 04:00:00.0 +0400 +++ b/target/linux/generic/patches-3.6/263-bmp085_dynamic.patch 2014-06-08 14:42:38.0 +0400 @@ -0,0 +1,11 @@ +--- a/drivers/misc/Kconfig 2014-04-03 23:01:22.0 +0400 b/drivers/misc/Kconfig 2014-06-08 14:40:09.129048438 +0400 +@@ -453,7 +453,7 @@ + still useful. + + config BMP085 +- bool ++ tristate BMP085 digital pressure sensor generic support + depends on SYSFS + + config BMP085_I2C --- a/target/linux/generic/patches-3.8/263-bmp085_dynamic.patch 1970-01-01 04:00:00.0 +0400 +++ b/target/linux/generic/patches-3.8/263-bmp085_dynamic.patch 2014-06-08 14:42:38.0 +0400 @@ -0,0 +1,11 @@ +--- a/drivers/misc/Kconfig 2014-04-03 23:01:22.0 +0400 b/drivers/misc/Kconfig 2014-06-08 14:40:09.129048438 +0400 +@@ -443,7 +443,7 @@ + still useful. + + config BMP085 +- bool ++ tristate BMP085 digital pressure sensor generic support + depends on SYSFS + + config BMP085_I2C --- a/target/linux/generic/patches-3.9/263-bmp085_dynamic.patch 1970-01-01 04:00:00.0 +0400 +++ b/target/linux/generic/patches-3.9/263-bmp085_dynamic.patch 2014-06-08 14:42:38.0 +0400 @@ -0,0 +1,11 @@ +--- a/drivers/misc/Kconfig 2014-04-03 23:01:22.0 +0400 b/drivers/misc/Kconfig 2014-06-08 14:40:09.129048438 +0400 +@@ -443,7 +443,7 @@ + still useful. + + config BMP085 +- bool ++ tristate BMP085 digital pressure sensor generic support + depends on SYSFS + + config BMP085_I2C --- a/target/linux/generic/patches-3.10/263-bmp085_dynamic.patch 1970-01-01 04:00:00.0 +0400 +++ b/target/linux/generic/patches-3.10/263-bmp085_dynamic.patch 2014-06-08 14:42:38.0 +0400 @@ -0,0 +1,11 @@ +--- a/drivers/misc/Kconfig 2014-04-03 23:01:22.0 +0400 b/drivers/misc/Kconfig 2014-06-08 14:40:09.129048438 +0400 +@@ -451,7 +451,7 @@ + still useful. + + config BMP085 +- bool ++ tristate BMP085 digital pressure sensor generic support + depends on SYSFS + + config BMP085_I2C --- a/target/linux/generic/patches-3.12/263-bmp085_dynamic.patch 1970-01-01 04:00:00.0 +0400 +++ b/target/linux/generic/patches-3.12/263-bmp085_dynamic.patch 2014-06-08 14:42:38.0 +0400 @@ -0,0 +1,11 @@ +--- a/drivers/misc/Kconfig 2014-04-03 23:01:22.0 +0400 b/drivers/misc/Kconfig 2014-06-08 14:40:09.129048438 +0400 +@@ -451,7 +451,7 @@ + still useful. + + config BMP085 +- bool ++ tristate BMP085 digital pressure sensor generic support + depends on SYSFS + + config BMP085_I2C --- a/target/linux/generic/patches-3.13/263-bmp085_dynamic.patch 1970-01-01 04:00:00.0 +0400 +++ b/target/linux/generic/patches-3.13/263-bmp085_dynamic.patch 2014-06-08 14:42:38.0 +0400 @@ -0,0 +1,11 @@ +--- a/drivers/misc/Kconfig 2014-04-03 23:01:22.0 +0400 b/drivers/misc/Kconfig 2014-06-08 14:40:09.129048438 +0400 +@@ -438,7 +438,7 @@ + still useful. + + config BMP085 +- bool ++ tristate BMP085 digital pressure sensor generic support + depends on SYSFS + + config BMP085_I2C --- a/target/linux/generic/patches-3.14/263-bmp085_dynamic.patch 1970-01-01 04:00:00.0 +0400 +++ b/target/linux/generic/patches-3.14/263-bmp085_dynamic.patch 2014-06-08 14:42:38.0 +0400 @@ -0,0 +1,11 @@ +--- a/drivers/misc/Kconfig 2014-04-03 23:01:22.0 +0400 b/drivers/misc/Kconfig 2014-06-08 14:40:09.129048438 +0400 +@@ -438,7 +438,7 @@ + still useful. + + config BMP085 +- bool ++ tristate BMP085 digital pressure sensor generic support + depends on SYSFS + + config BMP085_I2C --- a/package/kernel/linux/modules/other.mk 2014-05-30 13:53:34.0 +0400 +++ b/package/kernel/linux/modules/other.mk 2014-06-08 16:47:48.315028290 +0400 @@ -698,6 +698,43 @@ $(eval $(call KernelPackage,regmap)) +define KernelPackage/bmp085-i2c + SUBMENU:=$(OTHER_MENU) + TITLE:=BMP085 digital pressure sensor on I2C + KCONFIG:=CONFIG_BMP085_I2C \ + CONFIG_BMP085 + DEPENDS:=+kmod-regmap + FILES:= \ + $(LINUX_DIR)/drivers/misc/bmp085-i2c.ko \ + $(LINUX_DIR)/drivers/misc/bmp085.ko + AUTOLOAD:=$(call AutoLoad,55,bmp085 bmp085-i2c) +endef + +define KernelPackage/bmp085-i2c/description +
Re: [OpenWrt-Devel] [Patch] Support for BMP085 pressure sensor
Hi, comments inline On 29/06/2014 10:13, Sergey Korolew wrote: Hello ! Bosch Sensortec is one of most popular pressure sensors for building home weather stations, its cheap and easy to use. I decided to add two packages for each bus type because device usually have only one barometer and we does no need to waste firmware space for unused bus. Tested on trunk, ar71xx (ML2030) with kernel 3.10, i2c only (due absent of spi version), but I added patch files for all current kernels. === --- a/target/linux/generic/patches-3.6/263-bmp085_dynamic.patch 1970-01-01 04:00:00.0 +0400 +++ b/target/linux/generic/patches-3.6/263-bmp085_dynamic.patch 2014-06-08 14:42:38.0 +0400 @@ -0,0 +1,11 @@ +--- a/drivers/misc/Kconfig2014-04-03 23:01:22.0 +0400 b/drivers/misc/Kconfig2014-06-08 14:40:09.129048438 +0400 +@@ -453,7 +453,7 @@ + still useful. + + config BMP085 +-bool ++ tristate BMP085 digital pressure sensor generic support + depends on SYSFS + i just had a look at the kernel Kconfig and it seems weird that the actual driver is bool while the busses are tristate. i would like to not carry your patches in trunk for future releases, so could please send this upstream aswell ? --- a/package/kernel/linux/modules/other.mk 2014-05-30 13:53:34.0 +0400 +++ b/package/kernel/linux/modules/other.mk 2014-06-08 16:47:48.315028290 +0400 @@ -698,6 +698,43 @@ $(eval $(call KernelPackage,regmap)) +define KernelPackage/bmp085-i2c + SUBMENU:=$(OTHER_MENU) + TITLE:=BMP085 digital pressure sensor on I2C + KCONFIG:=CONFIG_BMP085_I2C \ + CONFIG_BMP085 + DEPENDS:=+kmod-regmap + FILES:= \ + $(LINUX_DIR)/drivers/misc/bmp085-i2c.ko \ + $(LINUX_DIR)/drivers/misc/bmp085.ko + AUTOLOAD:=$(call AutoLoad,55,bmp085 bmp085-i2c) +endef please make bmp085.ko an extra package. it does not need the AUTOLOAD line. and for the i2c and spi package use AutoProbe instead of AutoLoad, that will tell kmodloader to figure out itself, that bmp085.ko needs to be loaded. John + +define KernelPackage/bmp085-i2c/description + Kernel module for BOSCH Sensortec pressure sensor on I2C +endef + +$(eval $(call KernelPackage,bmp085-i2c)) + +define KernelPackage/bmp085-spi + SUBMENU:=$(OTHER_MENU) + TITLE:=BMP085 digital pressure sensor on SPI + KCONFIG:=CONFIG_BMP085_SPI \ +CONFIG_BMP085 + DEPENDS:=+kmod-regmap + FILES:= \ + $(LINUX_DIR)/drivers/misc/bmp085-spi.ko \ + $(LINUX_DIR)/drivers/misc/bmp085.ko + AUTOLOAD:=$(call AutoLoad,55,bmp085 bmp085-spi) +endef + +define KernelPackage/bmp085-spi/description + Kernel module for BOSCH Sensortec pressure sensor on SPI +endef + +$(eval $(call KernelPackage,bmp085-spi)) + + define KernelPackage/ikconfig SUBMENU:=$(OTHER_MENU) TITLE:=Kernel configuration via /proc/config.gz === ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Resend patch to fix Support For Aztech GR7000
On 28/06/2014 15:49, Alpha Sparc wrote: I notice that support for lantiq mips34kc is also rather flaky, router somethings hangs and reboots abruptly... Is it possible to port the 34kc patches from TP-Link TD-W8970 SDK to OpenWRT? Is there a licensing issue. They have neatly place all their custom patches in a folder, porting should be doable. where inside the GPL tarball can i find the patches ? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Xilinx Zynq zedboard integration
I am still stuck on this. I think that the failing point here is the kernel image load, but the loading in the part of uboot. Javier Domingo Cansino ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 1/3] [ubox] validate: fix indentation
On Sun, Jun 29, 2014 at 8:58 AM, John Crispin j...@phrozen.org wrote: Hi, blogic@debian:/openwrt/ubox$ git am 5748 Applying: validate: fix indentation blogic@debian:/openwrt/ubox$ git am 5749 Applying: validate: fix indentation They have both the same subject, so you quite likely downloaded the same patch twice. Assuming the numbers are the patchwork patch ids, 5749 should be validate: add valid bool types enabled/disabled error: patch failed: validate/validate.c:882 error: validate/validate.c: patch does not apply Patch failed at 0001 validate: fix indentation When you have resolved this problem run git am --resolved. If you would prefer to skip this patch, instead run git am --skip. To restore the original branch and stop patching run git am --abort. blogic@debian:/openwrt/ubox$ git am --abort blogic@debian:/openwrt/ubox$ patch -p1 5749 patching file validate/validate.c Reversed (or previously applied) patch detected! Assume -R? [n] n Apply anyway? [n] y Hunk #1 FAILED at 882. 1 out of 1 hunk FAILED -- saving rejects to file validate/validate.c.rej Which would also perfectly explain this. Jonas ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 1/3] [ubox] validate: fix indentation
On 29/06/2014 12:38, Jonas Gorski wrote: On Sun, Jun 29, 2014 at 8:58 AM, John Crispin j...@phrozen.org wrote: Hi, blogic@debian:/openwrt/ubox$ git am 5748 Applying: validate: fix indentation blogic@debian:/openwrt/ubox$ git am 5749 Applying: validate: fix indentation They have both the same subject, so you quite likely downloaded the same patch twice. Assuming the numbers are the patchwork patch ids, 5749 should be validate: add valid bool types enabled/disabled error: patch failed: validate/validate.c:882 error: validate/validate.c: patch does not apply Patch failed at 0001 validate: fix indentation When you have resolved this problem run git am --resolved. If you would prefer to skip this patch, instead run git am --skip. To restore the original branch and stop patching run git am --abort. blogic@debian:/openwrt/ubox$ git am --abort blogic@debian:/openwrt/ubox$ patch -p1 5749 patching file validate/validate.c Reversed (or previously applied) patch detected! Assume -R? [n] n Apply anyway? [n] y Hunk #1 FAILED at 882. 1 out of 1 hunk FAILED -- saving rejects to file validate/validate.c.rej Which would also perfectly explain this. let me check the bash_history ... and indeed i fat fingered this while doing copy pasta :) Jonas ___ 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] Resend patch to fix Support For Aztech GR7000
You can find it in /lantiq/target/linux/ltqcpe/ patches-2.6.32/ There is also /lantiq/target/linux/generic-2.6/patches-2.6.32/ But these are largely OpenWRT patches they are using in their SDK except for 1 or 2. We just need to refresh them up to 3.10 if there are no major changes. On Sun, Jun 29, 2014 at 5:09 PM, John Crispin j...@phrozen.org wrote: On 28/06/2014 15:49, Alpha Sparc wrote: I notice that support for lantiq mips34kc is also rather flaky, router somethings hangs and reboots abruptly... Is it possible to port the 34kc patches from TP-Link TD-W8970 SDK to OpenWRT? Is there a licensing issue. They have neatly place all their custom patches in a folder, porting should be doable. where inside the GPL tarball can i find the patches ? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [RFC] mt7620 wifi
On 28 June 2014 19:17, Сергей Василюгин vasilu...@yandex.ru wrote: 26.06.2014, 06:03, Daniel dan...@makrotopia.org: Hi Roman, On 04/04/2014 04:39 PM, Roman Yeryomin wrote: I worked on other things lately but plan to return to rt2x00 soon and maybe try ralink driver on trunk again. I started looking into your patches and started to see things moving as far as you got. I suggest to define RT6352 and set chip.rt to that instead of checking for chip.rf == RF7620 in cases which were meant for RT5390. Is there any more recent version of your work on rt2x00 than the 630-rt2x00-add-mt7620-20140131.patch included in your first post? If so, please share it, I'd like to re-use what ever there is and try to botch things up a bit ;) Cheers Daniel After some attempts tonight I make working version of the patch. But my trunk revision really very old and I need time to rebase it. The key error was in rt2800_rfcsr_read for RF7620 (wrong bitmask). So *value = rt2x00_get_field32(reg, RF_CSR_CFG_DATA); instead of *value = rt2x00_get_field32(reg, RF_CSR_CFG_DATA_MT7620); broke all rf reading. Honestly that sounds weird because unless you change all the other masks for mt7620 you will have them overlapped. Also this is how that register is described in datasheet (the fields are in reverse order comparing to all other socs). If you say you got it working can you send at least binary image to test (while you are trying to rebase it)? Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Xilinx Zynq zedboard integration
I have manually executed the boot sequence in the uboot, and the result is that it fails on the command bootm loados. Any idea on how to debug what can be wrong? Cheers and I will keep searching, Javier Domingo Cansino zynq-uboot fatload mmc 0 0x300 uImage reading uImage 4582152 bytes read in 405 ms (10.8 MiB/s) zynq-uboot fatload mmc 0 0x2A0 devicetree.dtb reading devicetree.dtb 2739 bytes read in 15 ms (177.7 KiB/s) zynq-uboot fatload mmc 0 0x200 uramdisk.image.gz reading uramdisk.image.gz 796339 bytes read in 87 ms (8.7 MiB/s) zynq-uboot help bootm bootm - boot application image from memory Usage: bootm [addr [arg ...]] - boot application image stored in memory passing arguments 'arg ...'; when booting a Linux kernel, 'arg' can be the address of an initrd image When booting a Linux kernel which requires a flat device-tree a third argument is required which is the address of the device-tree blob. To boot that kernel without an initrd image, use a '-' for the second argument. If you do not pass a third a bd_info struct will be passed instead For the new multi component uImage format (FIT) addresses must be extened to include component or configuration unit name: addr:subimg_uname - direct component image specification addr#conf_uname - configuration specification Use iminfo command to get the list of existing component images and configurations. Sub-commands to do part of the bootm sequence. The sub-commands must be issued in the order below (it's ok to not issue all sub-commands): start [addr [arg ...]] loados - load OS image ramdisk - relocate initrd, set env initrd_start/initrd_end fdt - relocate flat device tree cmdline - OS specific command line processing/setup bdt - OS specific bd_t processing prep- OS specific prep before relocation or go go - start OS zynq-uboot bootm start 0x300 0x200 0x2A0 ## Booting kernel from Legacy Image at 0300 ... Image Name: ARM OpenWrt Linux-3.13.7 Image Type: ARM Linux Kernel Image (uncompressed) Data Size:4582088 Bytes = 4.4 MiB Load Address: 8000 Entry Point: 8000 Verifying Checksum ... OK ## Loading init Ramdisk from Legacy Image at 0200 ... Image Name: Image Type: ARM Linux RAMDisk Image (uncompressed) Data Size:796275 Bytes = 777.6 KiB Load Address: Entry Point: Verifying Checksum ... OK ## Flattened Device Tree blob at 02a0 Booting using the fdt blob at 0x2a0 zynq-uboot bootm loados Loading Kernel Image ... ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] kernel: add missing config symbols
Spotted by several buildbots. Signed-off-by: Michael Heimpold m...@heimpold.de --- target/linux/generic/config-3.10 |3 +++ target/linux/generic/config-3.13 |3 +++ target/linux/generic/config-3.14 |3 +++ 3 files changed, 9 insertions(+) diff --git a/target/linux/generic/config-3.10 b/target/linux/generic/config-3.10 index a55d5ac..1977f82 100644 --- a/target/linux/generic/config-3.10 +++ b/target/linux/generic/config-3.10 @@ -526,6 +526,7 @@ CONFIG_CAVIUM_OCTEON_HELPER=y # CONFIG_CIFS_FSCACHE is not set # CONFIG_CIFS_NFSD_EXPORT is not set CONFIG_CIFS_POSIX=y +# CONFIG_CIFS_ACL is not set # CONFIG_CIFS_SMB2 is not set CONFIG_CIFS_STATS=y # CONFIG_CIFS_STATS2 is not set @@ -2666,6 +2667,8 @@ CONFIG_RCU_FANOUT_LEAF=16 # CONFIG_REGULATOR_VIRTUAL_CONSUMER is not set # CONFIG_REISERFS_CHECK is not set # CONFIG_REISERFS_FS is not set +# CONFIG_REISERFS_FS_POSIX_ACL is not set +# CONFIG_REISERFS_FS_SECURITY is not set # CONFIG_REISERFS_FS_XATTR is not set # CONFIG_REISERFS_PROC_INFO is not set # CONFIG_RELAY is not set diff --git a/target/linux/generic/config-3.13 b/target/linux/generic/config-3.13 index cd68906..4a34710 100644 --- a/target/linux/generic/config-3.13 +++ b/target/linux/generic/config-3.13 @@ -567,6 +567,7 @@ CONFIG_CAVIUM_OCTEON_HELPER=y # CONFIG_CIFS_FSCACHE is not set # CONFIG_CIFS_NFSD_EXPORT is not set CONFIG_CIFS_POSIX=y +# CONFIG_CIFS_ACL is not set # CONFIG_CIFS_SMB2 is not set CONFIG_CIFS_STATS=y # CONFIG_CIFS_STATS2 is not set @@ -2809,6 +2810,8 @@ CONFIG_RCU_FANOUT_LEAF=16 # CONFIG_REGULATOR_VIRTUAL_CONSUMER is not set # CONFIG_REISERFS_CHECK is not set # CONFIG_REISERFS_FS is not set +# CONFIG_REISERFS_FS_POSIX_ACL is not set +# CONFIG_REISERFS_FS_SECURITY is not set # CONFIG_REISERFS_FS_XATTR is not set # CONFIG_REISERFS_PROC_INFO is not set # CONFIG_RELAY is not set diff --git a/target/linux/generic/config-3.14 b/target/linux/generic/config-3.14 index aac873d..f990e71 100644 --- a/target/linux/generic/config-3.14 +++ b/target/linux/generic/config-3.14 @@ -580,6 +580,7 @@ CONFIG_CC_STACKPROTECTOR_NONE=y # CONFIG_CIFS_FSCACHE is not set # CONFIG_CIFS_NFSD_EXPORT is not set CONFIG_CIFS_POSIX=y +# CONFIG_CIFS_ACL is not set # CONFIG_CIFS_SMB2 is not set CONFIG_CIFS_STATS=y # CONFIG_CIFS_STATS2 is not set @@ -2850,6 +2851,8 @@ CONFIG_RCU_FANOUT_LEAF=16 # CONFIG_REGULATOR_VIRTUAL_CONSUMER is not set # CONFIG_REISERFS_CHECK is not set # CONFIG_REISERFS_FS is not set +# CONFIG_REISERFS_FS_POSIX_ACL is not set +# CONFIG_REISERFS_FS_SECURITY is not set # CONFIG_REISERFS_FS_XATTR is not set # CONFIG_REISERFS_PROC_INFO is not set # CONFIG_RELAY is not set -- 1.7.10.4 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [RFC] mt7620 wifi
29.06.2014, 18:33, "Roman Yeryomin" leroi.li...@gmail.com:On 28 June 2014 19:17, Сергей Василюгин vasilu...@yandex.ru wrote: 26.06.2014, 06:03, "Daniel" dan...@makrotopia.org: Hi Roman, On 04/04/2014 04:39 PM, Roman Yeryomin wrote: I worked on other things lately but plan to return to rt2x00 soon and maybe try ralink driver on trunk again. I started looking into your patches and started to see things moving as far as you got. I suggest to define RT6352 and set chip.rt to that instead of checking for chip.rf == RF7620 in cases which were meant for RT5390. Is there any more recent version of your work on rt2x00 than the 630-rt2x00-add-mt7620-20140131.patch included in your first post? If so, please share it, I'd like to re-use what ever there is and try to botch things up a bit ;) Cheers Daniel After some attempts tonight I make working version of the patch. But my trunk revision really very old and I need time to rebase it. The key error was in rt2800_rfcsr_read for RF7620 (wrong bitmask). So *value = rt2x00_get_field32(reg, RF_CSR_CFG_DATA); instead of *value = rt2x00_get_field32(reg, RF_CSR_CFG_DATA_MT7620); broke all rf reading.Honestly that sounds weird because unless you change all the othermasks for mt7620 you will have them overlapped.Also this is how that register is described in datasheet (the fieldsare in reverse order comparing to all other socs).If you say you got it working can you send at least binary image totest (while you are trying to rebase it)?Regards,Roman1. As my friends say - let me show :)Your recently sent patch: static void rt2800_rfcsr_read(struct rt2x00_dev *rt2x00dev, const unsigned int word, u8 *value) {@@ -182,15 +221,31 @@ * doesn't become available in time, reg will be 0x * which means we return 0xff to the caller. */- if (WAIT_FOR_RFCSR(rt2x00dev, reg)) {- reg = 0;- rt2x00_set_field32(reg, RF_CSR_CFG_REGNUM, word);- rt2x00_set_field32(reg, RF_CSR_CFG_WRITE, 0);- rt2x00_set_field32(reg, RF_CSR_CFG_BUSY, 1);+ switch (rt2x00dev-chip.rf) {+ case RF7620:+ if (WAIT_FOR_RFCSR_MT7620(rt2x00dev, reg)) {+ reg = 0;+ rt2x00_set_field32(reg, RF_CSR_CFG_REGNUM_MT7620, word);+ rt2x00_set_field32(reg, RF_CSR_CFG_WRITE_MT7620, 0);+ rt2x00_set_field32(reg, RF_CSR_CFG_BUSY_MT7620, 1);++ rt2800_register_write_lock(rt2x00dev, RF_CSR_CFG, reg);++ WAIT_FOR_RFCSR_MT7620(rt2x00dev, reg);+ }+ break;+ default:+ if (WAIT_FOR_RFCSR(rt2x00dev, reg)) {+ reg = 0;+ rt2x00_set_field32(reg, RF_CSR_CFG_REGNUM, word);+ rt2x00_set_field32(reg, RF_CSR_CFG_WRITE, 0);+ rt2x00_set_field32(reg, RF_CSR_CFG_BUSY, 1); - rt2800_register_write_lock(rt2x00dev, RF_CSR_CFG, reg);+ rt2800_register_write_lock(rt2x00dev, RF_CSR_CFG, reg); - WAIT_FOR_RFCSR(rt2x00dev, reg);+ WAIT_FOR_RFCSR(rt2x00dev, reg);+ }+ break; } *value = rt2x00_get_field32(reg, RF_CSR_CFG_DATA);@@ -198,6 +253,12 @@ mutex_unlock(rt2x00dev-csr_mutex); } use call*value = rt2x00_get_field32(reg, RF_CSR_CFG_DATA);for both case - default and mt7620. I call*value = rt2x00_get_field32(reg, RF_CSR_CFG_DATA_MT7620);for mt7620 :) 2. Binary images: https://yadi.sk/d/OeTxrigZVMg8gDlink dir620f1 is my test board (pkg_id=0, chip_ver=2, eco_num=3 - auto detect not working yet). AFAIK asus rt-n14u use the same. ---serge ___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Xilinx Zynq zedboard integration
I have found that I was compiling u-boot with a wrong config. Anyway, I have advanced now till the next challenge. same output as before, but now: ## Flattened Device Tree blob at 02a0 Booting using the fdt blob at 0x2a0 Loading Kernel Image ... OK Loading Ramdisk to 1fa6d000, end 1fb2f649 ... OK Loading Device Tree to 1fa69000, end 1fa6cab2 ... OK Starting kernel ... So I suppose now there is really something wrong with the kernel. I have repeated the steps by hand, and now it stops printing after the Starting kernel ... line. I have enabled early_prinks, and all those things I have been said to. May it be due to the kernel not printing to the right device? Is there any way to check that? Javier Domingo Cansino ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH][packages] softflowd update
Hello all, Please consider the below patch, which updates softflowd to 0.9.9. This release fixed some crash bugs I hit in 0.9.8. I've been using 0.9.9 on attitude adjuster for a while, and have tested that it builds with the trunk SDK. Thanks, Ross commit d2705ac97cb8fc015ee95fd69bb9d766a1035ca7 Author: Ross Vandegrift r...@kallisti.us Date: Sun Jun 29 10:45:35 2014 -0400 softflowd: version 0.9.9 from google code Signed-off-by: Ross Vandegrift r...@kallisti.us diff --git a/net/softflowd/Makefile b/net/softflowd/Makefile index 8c97143..ec34be5 100644 --- a/net/softflowd/Makefile +++ b/net/softflowd/Makefile @@ -8,12 +8,12 @@ include $(TOPDIR)/rules.mk PKG_NAME:=softflowd -PKG_VERSION:=0.9.8 -PKG_RELEASE:=3 +PKG_VERSION:=0.9.9 +PKG_RELEASE:=1 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz -PKG_SOURCE_URL:=http://www.mindrot.org/files/softflowd/ -PKG_MD5SUM:=0054d1c80494396cc15edb0a1c7748b1 +PKG_SOURCE_URL:=http://softflowd.googlecode.com/files/ +PKG_MD5SUM:=ba83e2715e6250e6645ebcaa9ae1009d PKG_FIXUP:=autoreconf @@ -24,7 +24,7 @@ define Package/softflowd CATEGORY:=Network DEPENDS:=+libpcap TITLE:=softflowd - URL:=http://www.mindrot.org/projects/softflowd/ + URL:=http://code.google.com/p/softflowd/ endef define Package/softflowd/description ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [RFC] mt7620 wifi
On 29 June 2014 16:33, Сергей Василюгин vasilu...@yandex.ru wrote:
29.06.2014, 18:33, Roman Yeryomin leroi.li...@gmail.com:
On 28 June 2014 19:17, Сергей Василюгин vasilu...@yandex.ru wrote:
26.06.2014, 06:03, Daniel dan...@makrotopia.org:
Hi Roman,
On 04/04/2014 04:39 PM, Roman Yeryomin wrote:
I worked on other things lately but plan to return to rt2x00 soon and
maybe try ralink driver on trunk again.
I started looking into your patches and started to see things moving as far
as
you got.
I suggest to define RT6352 and set chip.rt to that instead of checking for
chip.rf == RF7620 in cases which were meant for RT5390.
Is there any more recent version of your work on rt2x00 than the
630-rt2x00-add-mt7620-20140131.patch included in your first post? If so,
please
share it, I'd like to re-use what ever there is and try to botch things up
a
bit ;)
Cheers
Daniel
After some attempts tonight I make working version of the patch. But my
trunk revision really very old and I need time to rebase it.
The key error was in rt2800_rfcsr_read for RF7620 (wrong bitmask). So
*value = rt2x00_get_field32(reg, RF_CSR_CFG_DATA);
instead of
*value = rt2x00_get_field32(reg, RF_CSR_CFG_DATA_MT7620);
broke all rf reading.
Honestly that sounds weird because unless you change all the other
masks for mt7620 you will have them overlapped.
Also this is how that register is described in datasheet (the fields
are in reverse order comparing to all other socs).
If you say you got it working can you send at least binary image to
test (while you are trying to rebase it)?
Regards,
Roman
1. As my friends say - let me show :)
Your recently sent patch:
static void rt2800_rfcsr_read(struct rt2x00_dev *rt2x00dev,
const unsigned int word, u8 *value)
{
@@ -182,15 +221,31 @@
* doesn't become available in time, reg will be 0x
* which means we return 0xff to the caller.
*/
- if (WAIT_FOR_RFCSR(rt2x00dev, reg)) {
- reg = 0;
- rt2x00_set_field32(reg, RF_CSR_CFG_REGNUM, word);
- rt2x00_set_field32(reg, RF_CSR_CFG_WRITE, 0);
- rt2x00_set_field32(reg, RF_CSR_CFG_BUSY, 1);
+ switch (rt2x00dev-chip.rf) {
+ case RF7620:
+ if (WAIT_FOR_RFCSR_MT7620(rt2x00dev, reg)) {
+ reg = 0;
+ rt2x00_set_field32(reg, RF_CSR_CFG_REGNUM_MT7620,
word);
+ rt2x00_set_field32(reg, RF_CSR_CFG_WRITE_MT7620,
0);
+ rt2x00_set_field32(reg, RF_CSR_CFG_BUSY_MT7620, 1);
+
+ rt2800_register_write_lock(rt2x00dev, RF_CSR_CFG,
reg);
+
+ WAIT_FOR_RFCSR_MT7620(rt2x00dev, reg);
+ }
+ break;
+ default:
+ if (WAIT_FOR_RFCSR(rt2x00dev, reg)) {
+ reg = 0;
+ rt2x00_set_field32(reg, RF_CSR_CFG_REGNUM, word);
+ rt2x00_set_field32(reg, RF_CSR_CFG_WRITE, 0);
+ rt2x00_set_field32(reg, RF_CSR_CFG_BUSY, 1);
- rt2800_register_write_lock(rt2x00dev, RF_CSR_CFG, reg);
+ rt2800_register_write_lock(rt2x00dev, RF_CSR_CFG,
reg);
- WAIT_FOR_RFCSR(rt2x00dev, reg);
+ WAIT_FOR_RFCSR(rt2x00dev, reg);
+ }
+ break;
}
*value = rt2x00_get_field32(reg, RF_CSR_CFG_DATA);
@@ -198,6 +253,12 @@
mutex_unlock(rt2x00dev-csr_mutex);
}
use call
*value = rt2x00_get_field32(reg, RF_CSR_CFG_DATA);
for both case - default and mt7620. I call
*value = rt2x00_get_field32(reg, RF_CSR_CFG_DATA_MT7620);
for mt7620 :)
2. Binary images: https://yadi.sk/d/OeTxrigZVMg8g
Dlink dir620f1 is my test board (pkg_id=0, chip_ver=2, eco_num=3 - auto
detect not working yet). AFAIK asus rt-n14u use the same.
Sorry, I've read your previous email wrong.
By looking at the code seems you are right! I can't believe I've
missed that line before! I will look - maybe I kept the old tree I was
experimenting with.
BTW, I don't know why but your image for rt-n14u didn't work for me -
even ethernet is not working.
Regards,
Roman
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [Patch][Resend] Support for BMP085 pressure sensor
Hello ! Here is the v2 of the patch, with suggestions from John Crispin. Three packages (one main and two for i2c/spi) selected using submenu. Kernel patch separated from other.mk part, possibly we will have it included in linux kernel. === --- a/package/kernel/linux/modules/other.mk 2014-06-29 15:21:39.359850523 +0400 +++ b/package/kernel/linux/modules/other.mk 2014-06-29 15:17:27.0 +0400 @@ -698,6 +698,54 @@ $(eval $(call KernelPackage,regmap)) + +define KernelPackage/bmp085 + SUBMENU:=$(OTHER_MENU) + TITLE:=BMP085 digital pressure sensor + KCONFIG:=CONFIG_BMP085 + DEPENDS:=+kmod-regmap + FILES:= \ + $(LINUX_DIR)/drivers/misc/bmp085.ko +endef + +define KernelPackage/bmp085/description + Kernel module for BOSCH Sensortec pressure sensor generic support +endef + +$(eval $(call KernelPackage,bmp085)) + +define KernelPackage/bmp085-i2c + SUBMENU:=$(OTHER_MENU) + TITLE:=BMP085 sensor on I2C bus + KCONFIG:=CONFIG_BMP085_I2C + FILES:= \ + $(LINUX_DIR)/drivers/misc/bmp085-i2c.ko + DEPENDS:=kmod-bmp085 + AUTOLOAD:=$(call AutoProbe,bmp085-i2c) +endef + +define KernelPackage/bmp085-i2c/description + Kernel module for BOSCH Sensortec pressure sensor on I2C bus +endef + +$(eval $(call KernelPackage,bmp085-i2c)) + +define KernelPackage/bmp085-spi + SUBMENU:=$(OTHER_MENU) + TITLE:=BMP085 sensor on SPI bus + KCONFIG:=CONFIG_BMP085_SPI + FILES:= \ + $(LINUX_DIR)/drivers/misc/bmp085-spi.ko + DEPENDS:=kmod-bmp085 + AUTOLOAD:=$(call AutoProbe,bmp085-spi) +endef + +define KernelPackage/bmp085-spi/description + Kernel module for BOSCH Sensortec pressure sensor on SPI bus +endef + +$(eval $(call KernelPackage,bmp085-spi)) + define KernelPackage/ikconfig SUBMENU:=$(OTHER_MENU) TITLE:=Kernel configuration via /proc/config.gz === Kernel part, adapted for OpenWRT, if someone want to compile now. Actually its only replace bool with tristate. === --- a/target/linux/generic/patches-3.6/263-bmp085_dynamic.patch 1970-01-01 04:00:00.0 +0400 +++ b/target/linux/generic/patches-3.6/263-bmp085_dynamic.patch 2014-06-08 14:42:38.0 +0400 @@ -0,0 +1,11 @@ +--- a/drivers/misc/Kconfig 2014-04-03 23:01:22.0 +0400 b/drivers/misc/Kconfig 2014-06-08 14:40:09.129048438 +0400 +@@ -453,7 +453,7 @@ + still useful. + + config BMP085 +- bool ++ tristate BMP085 digital pressure sensor generic support + depends on SYSFS + + config BMP085_I2C --- a/target/linux/generic/patches-3.8/263-bmp085_dynamic.patch 1970-01-01 04:00:00.0 +0400 +++ b/target/linux/generic/patches-3.8/263-bmp085_dynamic.patch 2014-06-08 14:42:38.0 +0400 @@ -0,0 +1,11 @@ +--- a/drivers/misc/Kconfig 2014-04-03 23:01:22.0 +0400 b/drivers/misc/Kconfig 2014-06-08 14:40:09.129048438 +0400 +@@ -443,7 +443,7 @@ + still useful. + + config BMP085 +- bool ++ tristate BMP085 digital pressure sensor generic support + depends on SYSFS + + config BMP085_I2C --- a/target/linux/generic/patches-3.9/263-bmp085_dynamic.patch 1970-01-01 04:00:00.0 +0400 +++ b/target/linux/generic/patches-3.9/263-bmp085_dynamic.patch 2014-06-08 14:42:38.0 +0400 @@ -0,0 +1,11 @@ +--- a/drivers/misc/Kconfig 2014-04-03 23:01:22.0 +0400 b/drivers/misc/Kconfig 2014-06-08 14:40:09.129048438 +0400 +@@ -443,7 +443,7 @@ + still useful. + + config BMP085 +- bool ++ tristate BMP085 digital pressure sensor generic support + depends on SYSFS + + config BMP085_I2C --- a/target/linux/generic/patches-3.10/263-bmp085_dynamic.patch 1970-01-01 04:00:00.0 +0400 +++ b/target/linux/generic/patches-3.10/263-bmp085_dynamic.patch 2014-06-08 14:42:38.0 +0400 @@ -0,0 +1,11 @@ +--- a/drivers/misc/Kconfig 2014-04-03 23:01:22.0 +0400 b/drivers/misc/Kconfig 2014-06-08 14:40:09.129048438 +0400 +@@ -451,7 +451,7 @@ + still useful. + + config BMP085 +- bool ++ tristate BMP085 digital pressure sensor generic support + depends on SYSFS + + config BMP085_I2C --- a/target/linux/generic/patches-3.12/263-bmp085_dynamic.patch 1970-01-01 04:00:00.0 +0400 +++ b/target/linux/generic/patches-3.12/263-bmp085_dynamic.patch 2014-06-08 14:42:38.0 +0400 @@ -0,0 +1,11 @@ +--- a/drivers/misc/Kconfig 2014-04-03 23:01:22.0 +0400 b/drivers/misc/Kconfig 2014-06-08 14:40:09.129048438 +0400 +@@ -451,7 +451,7 @@ + still useful. + + config BMP085 +- bool ++ tristate BMP085 digital pressure sensor generic support + depends on SYSFS + + config BMP085_I2C --- a/target/linux/generic/patches-3.13/263-bmp085_dynamic.patch 1970-01-01 04:00:00.0 +0400 +++ b/target/linux/generic/patches-3.13/263-bmp085_dynamic.patch
Re: [OpenWrt-Devel] [RFC netifd] Out-of-sync reference counter causes seg. fault
On 2014-06-18 18:12, Kristian Evensen wrote: From: Kristian Evensen kristian.even...@gmail.com Hello, I have written a small tool which automatically adds/removes a usb LAN dongle from uci. When the USB device is inserted, I add entries to UCI (using libuci) and do network reload (using libubus). When the device is removed, I remove the UCI-entries and do reload again. This all works fine. However, when I connect the device a second time, netifd crashes with a seg. fault. The problem seems to be that the reference counter is not reduced properly when device remove, and device is not properly removed from internal data structures. The missing reference counter update seems to be in device_release(). After adding a call to device_remove_user() here, the reference counter is correct, device is correctly removed and netifd is stable. I have also tested by adding/removing other types of network devices, and netifd seems to work fine. However, I am not familiar enough with the internal architecture of netifd to know if this is a correct fix or just a dirty hack. If this is a hack, does anyone have any feedback or hints to how I can properly solve this issue? Please test the latest version and check if that hack is still necessary. Thanks, - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] kernel: add missing config symbols
On Sun, Jun 29, 2014 at 2:09 PM, Michael Heimpold m...@heimpold.de wrote: Spotted by several buildbots. Signed-off-by: Michael Heimpold m...@heimpold.de Thanks, applied. Jonas ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [Patch][BCM63XX][V2][RFC] Select HW_RANDOM_BCM63XX only in the SoCs that support it.
2014-06-28 19:54 GMT+02:00, Jonas Gorski j...@openwrt.org: Ah, I guess your problem is that something in your openwrt config depends on kmod-random-core, which will cause HW_RANDOM to be selected (as m), which makes HW_RANDOM_BCM63XX visible. In that case you need to either add # CONFIG_HW_RANDOM_BCM63XX is not set to config/target/generic-3.10 or create a proper kernel module package for HW_RANDOM_BCM63XX. Jonas Now understand: something selects CONFIG_HW_RANDON=m and automatically, because depends on BCM63XX, CONFIG_HW_RANDOM_BCM63XX needs an m too. Sorry for the noise. Pepe ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [Patch][BCM63XX][V2][RFC] Select HW_RANDOM_BCM63XX only in the SoCs that support it.
On Sun, Jun 29, 2014 at 10:37 PM, José Vázquez ppvazquez...@gmail.com wrote: 2014-06-28 19:54 GMT+02:00, Jonas Gorski j...@openwrt.org: Ah, I guess your problem is that something in your openwrt config depends on kmod-random-core, which will cause HW_RANDOM to be selected (as m), which makes HW_RANDOM_BCM63XX visible. In that case you need to either add # CONFIG_HW_RANDOM_BCM63XX is not set to config/target/generic-3.10 or create a proper kernel module package for HW_RANDOM_BCM63XX. Jonas Now understand: something selects CONFIG_HW_RANDON=m and automatically, because depends on BCM63XX, CONFIG_HW_RANDOM_BCM63XX needs an m too. Sorry for the noise. Not quite. default config-3.10 has CONFIG_HW_RANDOM=y and CONFIG_HW_RANDOM_BCM63XX=y. You run make kernel_menuconfig and deselect CONFIG_HW_RANDOM. Because CONFIG_HW_RANDOM_BCM63XX depends on CONFIG_HW_RANDOM, CONFIG_HW_RANDOM_BCM63XX is not defined anymore, and your modified config-3.10 now only contains # CONFIG_HW_RANDOM is not set. Now something in the build system selects CONFIG_HW_RANDOM=m, and suddenly CONFIG_HW_RANDOM_BCM63XX is available again, but config-3.10 does not contain CONFIG_HW_RANDOM_BCM63XX anymore, so the kernel config system needs to ask what you want as its value. If you leave CONFIG_HW_RANDOM=y and only disable CONFIG_HW_RANDOM_BCM63XX, then you will have no issue, because then your config-3.10 will contain a line # CONFIG_HW_RANDOM_BCM63XX is not set Jonas ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [RFC netifd] Out-of-sync reference counter causes seg. fault
Hi Felix, On Sun, Jun 29, 2014 at 8:36 PM, Felix Fietkau n...@openwrt.org wrote: Please test the latest version and check if that hack is still necessary. Thanks for your reply. I tested with latest netifd and latest libubus, to make sure that I got the reload-fixes. The issue is unfortunately still present. I see that I forgot to reference the commit that introduced this seg. fault, it is 7233afd94910cb4583c9555840a990287fd5d642. When reverting this commit, I no longer see the crash. -Kristian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [RFC netifd] Out-of-sync reference counter causes seg. fault
On 2014-06-29 23:10, Kristian Evensen wrote: Hi Felix, On Sun, Jun 29, 2014 at 8:36 PM, Felix Fietkau n...@openwrt.org wrote: Please test the latest version and check if that hack is still necessary. Thanks for your reply. I tested with latest netifd and latest libubus, to make sure that I got the reload-fixes. The issue is unfortunately still present. I see that I forgot to reference the commit that introduced this seg. fault, it is 7233afd94910cb4583c9555840a990287fd5d642. When reverting this commit, I no longer see the crash. Thanks for the info about the commit that broke it, now this issue makes more sense to me. Please try this patch: --- --- a/interface.c +++ b/interface.c @@ -509,8 +509,8 @@ interface_cleanup_state(struct interface *iface) interface_clear_errors(iface); interface_set_proto_state(iface, NULL); - if (iface-main_dev.dev) - interface_set_main_dev(iface, NULL); + interface_set_main_dev(iface, NULL); + interface_set_l3_dev(iface, NULL); } static void ___ 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
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] [RFC netifd] Out-of-sync reference counter causes seg. fault
On Sun, Jun 29, 2014 at 11:19 PM, Felix Fietkau n...@openwrt.org wrote: Thanks for the info about the commit that broke it, now this issue makes more sense to me. Please try this patch: With this patch everything works fine, I do not see the crash any more. Thanks for the help! -Kristian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [RFC netifd] Out-of-sync reference counter causes seg. fault
On 2014-06-29 23:25, Kristian Evensen wrote: On Sun, Jun 29, 2014 at 11:19 PM, Felix Fietkau n...@openwrt.org wrote: Thanks for the info about the commit that broke it, now this issue makes more sense to me. Please try this patch: With this patch everything works fine, I do not see the crash any more. Thanks for the help! Thanks for testing. Fix pushed and committed in r41393 - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [RFC] mt7620 wifi
hi,
as I know, wrt get MAC address from some mtd partition, if it got all 0xff，the
ethernet will not boot up. for more details just check the dts file for rt-n14u.
Alex Guo
Roman Yeryomin leroi.li...@gmail.com编写：
On 29 June 2014 16:33, Сергей Василюгин vasilu...@yandex.ru wrote:
29.06.2014, 18:33, Roman Yeryomin leroi.li...@gmail.com:
On 28 June 2014 19:17, Сергей Василюгин vasilu...@yandex.ru wrote:
26.06.2014, 06:03, Daniel dan...@makrotopia.org:
Hi Roman,
On 04/04/2014 04:39 PM, Roman Yeryomin wrote:
I worked on other things lately but plan to return to rt2x00 soon and
maybe try ralink driver on trunk again.
I started looking into your patches and started to see things moving as far
as
you got.
I suggest to define RT6352 and set chip.rt to that instead of checking for
chip.rf == RF7620 in cases which were meant for RT5390.
Is there any more recent version of your work on rt2x00 than the
630-rt2x00-add-mt7620-20140131.patch included in your first post? If so,
please
share it, I'd like to re-use what ever there is and try to botch things up
a
bit ;)
Cheers
Daniel
After some attempts tonight I make working version of the patch. But my
trunk revision really very old and I need time to rebase it.
The key error was in rt2800_rfcsr_read for RF7620 (wrong bitmask). So
*value = rt2x00_get_field32(reg, RF_CSR_CFG_DATA);
instead of
*value = rt2x00_get_field32(reg, RF_CSR_CFG_DATA_MT7620);
broke all rf reading.
Honestly that sounds weird because unless you change all the other
masks for mt7620 you will have them overlapped.
Also this is how that register is described in datasheet (the fields
are in reverse order comparing to all other socs).
If you say you got it working can you send at least binary image to
test (while you are trying to rebase it)?
Regards,
Roman
1. As my friends say - let me show :)
Your recently sent patch:
static void rt2800_rfcsr_read(struct rt2x00_dev *rt2x00dev,
const unsigned int word, u8 *value)
{
@@ -182,15 +221,31 @@
* doesn't become available in time, reg will be 0x
* which means we return 0xff to the caller.
*/
- if (WAIT_FOR_RFCSR(rt2x00dev, reg)) {
- reg = 0;
- rt2x00_set_field32(reg, RF_CSR_CFG_REGNUM, word);
- rt2x00_set_field32(reg, RF_CSR_CFG_WRITE, 0);
- rt2x00_set_field32(reg, RF_CSR_CFG_BUSY, 1);
+ switch (rt2x00dev-chip.rf) {
+ case RF7620:
+ if (WAIT_FOR_RFCSR_MT7620(rt2x00dev, reg)) {
+ reg = 0;
+ rt2x00_set_field32(reg, RF_CSR_CFG_REGNUM_MT7620,
word);
+ rt2x00_set_field32(reg, RF_CSR_CFG_WRITE_MT7620,
0);
+ rt2x00_set_field32(reg, RF_CSR_CFG_BUSY_MT7620, 1);
+
+ rt2800_register_write_lock(rt2x00dev, RF_CSR_CFG,
reg);
+
+ WAIT_FOR_RFCSR_MT7620(rt2x00dev, reg);
+ }
+ break;
+ default:
+ if (WAIT_FOR_RFCSR(rt2x00dev, reg)) {
+ reg = 0;
+ rt2x00_set_field32(reg, RF_CSR_CFG_REGNUM, word);
+ rt2x00_set_field32(reg, RF_CSR_CFG_WRITE, 0);
+ rt2x00_set_field32(reg, RF_CSR_CFG_BUSY, 1);
- rt2800_register_write_lock(rt2x00dev, RF_CSR_CFG, reg);
+ rt2800_register_write_lock(rt2x00dev, RF_CSR_CFG,
reg);
- WAIT_FOR_RFCSR(rt2x00dev, reg);
+ WAIT_FOR_RFCSR(rt2x00dev, reg);
+ }
+ break;
}
*value = rt2x00_get_field32(reg, RF_CSR_CFG_DATA);
@@ -198,6 +253,12 @@
mutex_unlock(rt2x00dev-csr_mutex);
}
use call
*value = rt2x00_get_field32(reg, RF_CSR_CFG_DATA);
for both case - default and mt7620. I call
*value = rt2x00_get_field32(reg, RF_CSR_CFG_DATA_MT7620);
for mt7620 :)
2. Binary images: https://yadi.sk/d/OeTxrigZVMg8g
Dlink dir620f1 is my test board (pkg_id=0, chip_ver=2, eco_num=3 - auto
detect not working yet). AFAIK asus rt-n14u use the same.
Sorry, I've read your previous email wrong.
By looking at the code seems you are right! I can't believe I've
missed that line before! I will look - maybe I kept the old tree I was
experimenting with.
BTW, I don't know why but your image for rt-n14u didn't work for me -
even ethernet is not working.
Regards,
Roman
___
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] [RFC] mt7620 wifi
30.06.2014, 08:28, "xf...@credosemi.com" xf...@credosemi.com:hi,as I know, wrt get MAC address from some mtd partition, if it got all 0xff，the ethernet will not boot up. for more details just check the dts file for rt-n14u.Alex Guo Roman Yeryomin leroi.li...@gmail.com编写：On 29 June 2014 16:33, Сергей Василюгин vasilu...@yandex.ru wrote: 29.06.2014, 18:33, "Roman Yeryomin" leroi.li...@gmail.com: On 28 June 2014 19:17, Сергей Василюгин vasilu...@yandex.ru wrote: 26.06.2014, 06:03, "Daniel" dan...@makrotopia.org: Hi Roman, On 04/04/2014 04:39 PM, Roman Yeryomin wrote: I worked on other things lately but plan to return to rt2x00 soon and maybe try ralink driver on trunk again. I started looking into your patches and started to see things moving as far as you got. I suggest to define RT6352 and set chip.rt to that instead of checking for chip.rf == RF7620 in cases which were meant for RT5390. Is there any more recent version of your work on rt2x00 than the 630-rt2x00-add-mt7620-20140131.patch included in your first post? If so, please share it, I'd like to re-use what ever there is and try to botch things up a bit ;) Cheers Daniel After some attempts tonight I make working version of the patch. But my trunk revision really very old and I need time to rebase it. The key error was in rt2800_rfcsr_read for RF7620 (wrong bitmask). So *value = rt2x00_get_field32(reg, RF_CSR_CFG_DATA); instead of *value = rt2x00_get_field32(reg, RF_CSR_CFG_DATA_MT7620); broke all rf reading. Honestly that sounds weird because unless you change all the other masks for mt7620 you will have them overlapped. Also this is how that register is described in datasheet (the fields are in reverse order comparing to all other socs). If you say you got it working can you send at least binary image to test (while you are trying to rebase it)? Regards, Roman 1. As my friends say - let me show :) Your recently sent patch: static void rt2800_rfcsr_read(struct rt2x00_dev *rt2x00dev, const unsigned int word, u8 *value) { @@ -182,15 +221,31 @@ * doesn't become available in time, reg will be 0x * which means we return 0xff to the caller. */ - if (WAIT_FOR_RFCSR(rt2x00dev, reg)) { - reg = 0; - rt2x00_set_field32(reg, RF_CSR_CFG_REGNUM, word); - rt2x00_set_field32(reg, RF_CSR_CFG_WRITE, 0); - rt2x00_set_field32(reg, RF_CSR_CFG_BUSY, 1); + switch (rt2x00dev-chip.rf) { + case RF7620: + if (WAIT_FOR_RFCSR_MT7620(rt2x00dev, reg)) { + reg = 0; + rt2x00_set_field32(reg, RF_CSR_CFG_REGNUM_MT7620, word); + rt2x00_set_field32(reg, RF_CSR_CFG_WRITE_MT7620, 0); + rt2x00_set_field32(reg, RF_CSR_CFG_BUSY_MT7620, 1); + + rt2800_register_write_lock(rt2x00dev, RF_CSR_CFG, reg); + + WAIT_FOR_RFCSR_MT7620(rt2x00dev, reg); + } + break; + default: + if (WAIT_FOR_RFCSR(rt2x00dev, reg)) { + reg = 0; + rt2x00_set_field32(reg, RF_CSR_CFG_REGNUM, word); + rt2x00_set_field32(reg, RF_CSR_CFG_WRITE, 0); + rt2x00_set_field32(reg, RF_CSR_CFG_BUSY, 1); - rt2800_register_write_lock(rt2x00dev, RF_CSR_CFG, reg); + rt2800_register_write_lock(rt2x00dev, RF_CSR_CFG, reg); - WAIT_FOR_RFCSR(rt2x00dev, reg); + WAIT_FOR_RFCSR(rt2x00dev, reg); + } + break; } *value = rt2x00_get_field32(reg, RF_CSR_CFG_DATA); @@ -198,6 +253,12 @@ mutex_unlock(rt2x00dev-csr_mutex); } use call *value = rt2x00_get_field32(reg, RF_CSR_CFG_DATA); for both case - default and mt7620. I call *value = rt2x00_get_field32(reg, RF_CSR_CFG_DATA_MT7620); for mt7620 :) 2. Binary images: https://yadi.sk/d/OeTxrigZVMg8g Dlink dir620f1 is my test board (pkg_id=0, chip_ver=2, eco_num=3 - auto detect not working yet). AFAIK asus rt-n14u use the same.Sorry, I've read your previous email wrong.By looking at the code seems you are right! I can't believe I'vemissed that line before! I will look - maybe I kept the old tree I wasexperimenting with.BTW, I don't know why but your image for rt-n14u didn't work for me -even ethernet is not working.Regards,Roman___openwrt-devel mailing listopenwrt-devel@lists.openwrt.orghttps://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel It's a possible solution. My board haveethernet@1010 { mtd-mac-address = factory 0x4; ralink,port-map = "w"; };I'll rebuild images tonight for test. ---serge ___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
