Re: [OpenWrt-Devel] [PATCH] Support Cisco/Linksys WAP-4410N

[Florian Fainelli]

Le 04/25/15 12:21, Caleb James DeLisle a écrit :
> This patch adds support for Cisco/Linksys WAP-4410N
> Currently there is no way to update from the factory firmware other than 
> using "tricks"
> but for the amount of times that is required, it's judged not to be a 
> significant problem.
> 
> Also the location of the kernel is moved from the factory location because 
> the 3.x kernel
> is larger than the 2.6 kernel they were using so keeping the memory position 
> was not feasible,
> therefore there is no way to install without changing the uboot environment 
> variable.

In case this helps, this C program deconstructs Linksys' original firmware:
https://github.com/ffainelli/firmware-tools/blob/master/unlapbind.c

and attached is an attempt at re-creating their proprietary firmware
format. I was never sure if we could upgrade without re-flashing u-boot,
so I did not give this a try on a real device, device which is now with
Gabor.
--
Florian
From 8a3c7b1527d114b015286b6e89bf828d3130a340 Mon Sep 17 00:00:00 2001
From: Florian Fainelli 
Date: Wed, 26 Sep 2012 22:10:08 +0200
Subject: [PATCH 1/2] [tools] firmware-utils: add Linksys WAP4410N image
 creator

---
 tools/firmware-utils/Makefile   |   1 +
 tools/firmware-utils/src/wap4410n.c | 299 
 2 files changed, 300 insertions(+)
 create mode 100644 tools/firmware-utils/src/wap4410n.c

diff --git a/tools/firmware-utils/Makefile b/tools/firmware-utils/Makefile
index a490c9e..9954bea 100644
--- a/tools/firmware-utils/Makefile
+++ b/tools/firmware-utils/Makefile
@@ -60,6 +60,7 @@ define Host/Compile
 	$(call cc,mkbrnimg)
 	$(call cc,mkdapimg)
 	$(call cc, mkcameofw, -Wall)
+	$(call cc,wap4410n,-lcrypto)
 endef
 
 define Host/Install
diff --git a/tools/firmware-utils/src/wap4410n.c b/tools/firmware-utils/src/wap4410n.c
new file mode 100644
index 000..b438440
--- /dev/null
+++ b/tools/firmware-utils/src/wap4410n.c
@@ -0,0 +1,299 @@
+/*
+ * Cisco/Linksys WAP4410N image creator
+ *
+ * Copyright (C) 2012, Florian Fainelli 
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
+ * TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
+ * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS
+ * BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ * POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Upgrade type is a bitmask, you can combine several upgrades */
+#define UPGRADE_TYPE_AUTO	0x00
+#define UPGRADE_TYPE_KERNEL	0x01
+#define UPGRADE_TYPE_ROOTFS	0x02
+#define UPGRADE_TYPE_BOOTROM	0x10
+#define UPGRADE_TYPE_BOARD_DATA	0x20
+
+#define PID_SIZE		112
+
+struct input_file {
+	const char *name;
+	uint8_t type;
+};
+
+/* valid upgrade types */
+static const struct input_file upgrade_types[] = {
+	{ "auto", UPGRADE_TYPE_AUTO },
+	{ "kernel", UPGRADE_TYPE_KERNEL },
+	{ "rootfs", UPGRADE_TYPE_ROOTFS },
+	{ "bootrom", UPGRADE_TYPE_BOOTROM },
+	{ "board", UPGRADE_TYPE_BOARD_DATA },
+};
+
+#define ARRAY_SIZE(x)	(sizeof((x)) / sizeof((x[0])))
+
+/* Main header */
+struct lap_hdr {
+	uint32_t	length;
+	uint8_t		upgrade_type;
+} __attribute__ ((__packed__));
+
+/* File descriptors headers */
+struct lap_desc_hdr {
+	uint8_t upgrade_type;
+	uint16_t version;
+	uint32_t length;
+} __attribute__ ((__packed__));
+
+static void usage(void)
+{
+	fprintf(stdout, "Usage: mkwap4410n [options]\n"
+			"-u:	upgrade type (auto, kernel, rootfs, bootrom...)\n"
+			"-p:	PID file\n"
+			"-b:	bootrom file\n"
+			"-k:	kernel file\n"
+			"-r:	roots file\n"
+			"-d:	board data file\n"
+			"-o:	output file\n");
+	exit(EXIT_FAILURE);
+}
+
+static uint8_t parse_upgrade_type(const char *upgrade_type)
+{
+	size_t i;
+
+	for (i = 0; i < ARRAY_SIZE(upgrade_types); i++) {
+		if (!strcmp(upgrade_types[i].name, upgrade_type))
+			return upgrade_types[i].type;
+	}
+
+	return 0xff;
+}
+
+static off_t get_file_size(const char *file)
+{
+	struct stat buf;
+	int ret;
+
+	ret = stat(file, &buf);
+	if (ret < 0)
+		return 0;
+	else
+		return buf.st_size;
+}
+
+#define MAX_FILES	5
+
+static int create_file(const char *upgrade_type, const char *version,
+			struct input_file *infiles, unsigned int num_infiles,
+			const char *outfile)
+{
+	int ret = 

Re: [OpenWrt-Devel] [PATCH] ar71xx: fix 100/10mbps ethernet link issues on mynet range extender

[Florian Fainelli]

Florian
On Jun 5, 2015 2:18 PM, "Dave Taht"  wrote:
>
> TX delay setting? What else can it do?

This is a delay between the transmit data lines and the transmit clock on a
RGMII interface. Based on PCB designs, this is something that may have to
be configured to align clock and data lines in a way that does not violate
timings and causes packet losses between the MAC and the PHY. These delays
are not valid when a RGMII interface operates at 10 or 100Mbits/sec since
the clock becomes slow enough the rise and fall times of the data lines are
negligable.

>
> My dream has been to find a way to set the tx completion interrupt
> to only return with a soft set rate. So if I had a gigE connection
> but my uplink was only 10Mbits, it would return the interrupt
> after 1.3ms had expired.

What you are referring to here is interrupt coalescing, which is different
and implemented at the Ethernet MAC and DMA engine levels and not all
controllers support that.

>
> this would let me get away entirely from using software rate limiting
> with htb, just program a register once with the uplink rate, and
> let bql and fq_codel handle the rest.
>
> On Wed, Jun 03, 2015 at 05:20:22PM +0200, Christian Lamparter wrote:
> > The mynet range extender hardware is suffering from ethernet
> > link loss when booting with a recent openwrt image. This only
> > happens on 100mbps links, with 1Gbps speed the link was fine.
> >
> > The cause of the problem is that the AR8035 PHY (aka F1E)
> > requires turning on and off the special TX delay setting
> > depending on the speed of the link.
> >
> > The 10mbps mode only needed the proper pll value, which was
> > extracted from the vendor code.
> >
> > Reported-by: Pascal Paradis
> > Signed-off-by: Christian Lamparter 
> > ---
> >  .../ar71xx/files/arch/mips/ath79/mach-mynet-rext.c | 20 
> >  ...t-phy-at803x-allow-to-configure-via-pdata.patch | 53
--
> >  2 files changed, 69 insertions(+), 4 deletions(-)
> >
> > diff --git
a/target/linux/ar71xx/files/arch/mips/ath79/mach-mynet-rext.c
b/target/linux/ar71xx/files/arch/mips/ath79/mach-mynet-rext.c
> > index 02d168e..3d48ca8 100644
> > --- a/target/linux/ar71xx/files/arch/mips/ath79/mach-mynet-rext.c
> > +++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-mynet-rext.c
> > @@ -14,6 +14,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >
> >  #include 
> >
> > @@ -124,6 +125,21 @@ static struct gpio_keys_button
mynet_rext_gpio_keys[] __initdata = {
> >   },
> >  };
> >
> > +static struct at803x_platform_data mynet_rext_at803x_data = {
> > + .disable_smarteee = 0,
> > + .enable_rgmii_rx_delay = 1,
> > + .enable_rgmii_tx_delay = 0,
> > + .fixup_rgmii_tx_delay = 1,
> > +};
> > +
> > +static struct mdio_board_info mynet_rext_mdio0_info[] = {
> > +{
> > +.bus_id = "ag71xx-mdio.0",
> > +.phy_addr = 4,
> > +.platform_data = &mynet_rext_at803x_data,
> > +},
> > +};
> > +
> >  static void mynet_rext_get_mac(const char *name, char *mac)
> >  {
> >   u8 *nvram = (u8 *) KSEG1ADDR(MYNET_REXT_NVRAM_ADDR);
> > @@ -169,12 +185,16 @@ static void __init mynet_rext_setup(void)
> >
> >   ath79_register_mdio(0, 0x0);
> >
> > + mdiobus_register_board_info(mynet_rext_mdio0_info,
> > + ARRAY_SIZE(mynet_rext_mdio0_info));
> > +
> >   /* LAN */
> >   mynet_rext_get_mac("et0macaddr=", ath79_eth0_data.mac_addr);
> >
> >   /* GMAC0 is connected to an external PHY on Port 4 */
> >   ath79_eth0_data.phy_if_mode = PHY_INTERFACE_MODE_RGMII;
> >   ath79_eth0_data.phy_mask = BIT(4);
> > + ath79_eth0_pll_data.pll_10   = 0x1313; /* athrs_mac.c */
> >   ath79_eth0_pll_data.pll_1000 = 0x0e00; /* athrs_mac.c */
> >   ath79_eth0_data.mii_bus_dev = &ath79_mdio0_device.dev;
> >   ath79_register_eth(0);
> > diff --git
a/target/linux/ar71xx/patches-3.18/425-net-phy-at803x-allow-to-configure-via-pdata.patch
b/target/linux/ar71xx/patches-3.18/425-net-phy-at803x-allow-to-configure-via-pdata.patch
> > index babc695..d046ede 100644
> > ---
a/target/linux/ar71xx/patches-3.18/425-net-phy-at803x-allow-to-configure-via-pdata.patch
> > +++
b/target/linux/ar71xx/patches-3.18/425-net-phy-at803x-allow-to-configure-via-pdata.patch
> > @@ -32,6 +32,14 @@
> >   #define AT803X_DEBUG_SYSTEM_MODE_CTRL   0x05
> >   #define AT803X_DEBUG_RGMII_TX_CLK_DLY   BIT(8)
> >
> > +@@ -50,6 +60,7 @@ MODULE_LICENSE("GPL");
> > + struct at803x_priv {
> > + bool phy_reset:1;
> > + struct gpio_desc *gpiod_reset;
> > ++int prev_speed;
> > + };
> > +
> > + struct at803x_context {
> >  @@ -61,6 +71,43 @@ struct at803x_context {
> >   u16 led_control;
> >   };
> > @@ -120,16 +128,53 @@
> >   return 0;
> >   }
> >
> > +@@ -258,6 +334,8 @@ static int at803x_config_intr(struct phy
> > + static void at803x_link_change_notify(struct phy_device *phydev)
> > + {
> > + struct at80

Re: [OpenWrt-Devel] [PATCH] ar71xx: fix 100/10mbps ethernet link issues on mynet range extender

[Florian Fainelli]

On Jun 9, 2015 7:36 AM, "Christian Lamparter" 
wrote:
>
> On Wednesday, June 03, 2015 05:20:22 PM Christian Lamparter wrote:
> > The mynet range extender hardware is suffering from ethernet
> > link loss when booting with a recent openwrt image. This only
> > happens on 100mbps links, with 1Gbps speed the link was fine.
> >
> > The cause of the problem is that the AR8035 PHY (aka F1E)
> > requires turning on and off the special TX delay setting
> > depending on the speed of the link.
> >
> > The 10mbps mode only needed the proper pll value, which was
> > extracted from the vendor code.
> >
> > Reported-by: Pascal Paradis
> > Signed-off-by: Christian Lamparter 
>
> No comments so far (but also, no merge). Ping?

Actually, I have one question, most PHY s should disable these kinds of
delays when linking at 10/100Mbits/sec. Is not that working here because
the registers used have a special behavior (force or override), or is it
broken at the hardware level?

>
> Regards,
>   Christian
> ___
> 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 WeIO Board (Chaos Calmer)

[Florian Fainelli]

On Jun 14, 2015 2:56 PM, "Drasko DRASKOVIC" 
wrote:
>
> Hello,
> please find below patch that adds support for WeIO board
> (http://we-io.net) to Chaos Calmer master branch.
>
> The board is based on Carambola2 module from 8Devices, and this patch
> adds a separate profile for WeIO.

Your patch has been mangled by your mailer, you might want to use
git-send-email instead. Since this is a new target, trunk is more
appropriate, once it gets there, backports to CC can be made.

>
> Best regards,
> Drasko
>
>
>
>
> From c68e410601b1fe656dad7b08ed41de470d0550c6 Mon Sep 17 00:00:00 2001
> From: Drasko DRASKOVIC 
> Date: Sun, 14 Jun 2015 22:41:45 +0200
> Subject: [PATCH] Add support for WeIO board
>
> Signed-off-by: Drasko DRASKOVIC 
> ---
>  .../ar71xx/base-files/etc/uci-defaults/01_leds |   6 +
>  target/linux/ar71xx/base-files/lib/ar71xx.sh   |   3 +
>  .../ar71xx/base-files/lib/upgrade/platform.sh  |   3 +-
>  target/linux/ar71xx/config-3.18|   1 +
>  .../linux/ar71xx/files/arch/mips/ath79/mach-weio.c | 148
+
>  target/linux/ar71xx/generic/profiles/weio.mk   |  17 +++
>  target/linux/ar71xx/image/Makefile |   8 ++
>  .../610-MIPS-ath79-openwrt-machines.patch  |  21 ++-
>  8 files changed, 201 insertions(+), 6 deletions(-)
>  create mode 100644 target/linux/ar71xx/files/arch/mips/ath79/mach-weio.c
>  create mode 100644 target/linux/ar71xx/generic/profiles/weio.mk
>
> 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 41b..b0fb36e 100644
> --- a/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds
> +++ b/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds
> @@ -63,6 +63,12 @@ carambola2)
>   ucidef_set_led_wlan "wlan" "WLAN" "carambola2:green:wlan" "phy0tpt"
>   ;;
>
> +weio)
> + ucidef_set_led_netdev "lan" "LAN" "weio:orange:eth0" "eth0"
> + ucidef_set_led_netdev "wan" "WAN" "weio:orange:eth1" "eth1"
> + ucidef_set_led_wlan "wlan" "WLAN" "weio:green:wlan" "phy0tpt"
> + ;;
> +
>  cpe510)
>   ucidef_set_led_switch "lan0" "LAN0" "tp-link:green:lan0" "switch0"
"0x20"
>   ucidef_set_led_switch "lan1" "LAN1" "tp-link:green:lan1" "switch0"
"0x10"
> diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh
> b/target/linux/ar71xx/base-files/lib/ar71xx.sh
> index b13be1e..fe7478c 100755
> --- a/target/linux/ar71xx/base-files/lib/ar71xx.sh
> +++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh
> @@ -892,6 +892,9 @@ ar71xx_board_detect() {
>   "8devices Carambola2"*)
>   name="carambola2"
>   ;;
> + *"WeIO")
> + name="weio"
> + ;;
>   *"Sitecom WLR-8100")
>   name="wlr8100"
>   ;;
> diff --git a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
> b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
> index 3dbd91c..0f2920b 100755
> --- a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
> +++ b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
> @@ -243,7 +243,8 @@ platform_check_image() {
>   nbg460n_550n_550nh | \
>   unifi | \
>   unifi-outdoor | \
> - carambola2 )
> + carambola2 | \
> + weio )
>   [ "$magic" != "2705" ] && {
>   echo "Invalid image type."
>   return 1
> diff --git a/target/linux/ar71xx/config-3.18
b/target/linux/ar71xx/config-3.18
> index 543b77e..ae68a18 100644
> --- a/target/linux/ar71xx/config-3.18
> +++ b/target/linux/ar71xx/config-3.18
> @@ -43,6 +43,7 @@ CONFIG_ATH79_MACH_AW_NR580=y
>  CONFIG_ATH79_MACH_BHU_BXU2000N2_A=y
>  CONFIG_ATH79_MACH_CAP4200AG=y
>  CONFIG_ATH79_MACH_CARAMBOLA2=y
> +CONFIG_ATH79_MACH_WEIO=y
>  CONFIG_ATH79_MACH_CPE510=y
>  CONFIG_ATH79_MACH_DB120=y
>  CONFIG_ATH79_MACH_DGL_5500_A1=y
> diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-weio.c
> b/target/linux/ar71xx/files/arch/mips/ath79/mach-weio.c
> new file mode 100644
> index 000..70ed543
> --- /dev/null
> +++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-weio.c
> @@ -0,0 +1,148 @@
> +/**
> + * WEIO Web Of Things Platform
> + *
> + * Copyright (C) 2013 Drasko DRASKOVIC and Uros PETREVSKI
> + *
> + *  ##  ##    ###
> + *  ##  ##  ## ####  ## ##
> + *  ##  ##  ## ####  ## ##
> + *  ##  ##  ## ####  ## ##
> + *  ##  ##  ## ####  ## ##
> + *  ##  ##  ## ####  ## ##
> + *   ###  ###     ###
> + *
> + *   Web Of Things Platform
> + *
> + * Authors :
> + * Drasko DRASKOVIC 
> + * Uros PETREVSKI 
> + */
> +
> +#include 
> +#include 
> +#include "common.h"
> +#include "dev-eth.h"
> +#include "dev-gpio-buttons.h"
> +#include "dev-leds-gpio.h"
> +#include "dev-m25p80.h"
> +#include "dev-spi.h"
> +#include "dev-usb.h"
> +#include "dev-wmac.h"
> +#include "machtypes.h"
> +#include "linux/i2c-gpio.h"
> +#include "linux/platform_device.h"
> +
> +#define WEIO_GPIO_LED_STA 1
> +#define WEIO_GPIO_LED_AP 16
> +//#define WEIO_GPIO_LED_ETH

Re: [OpenWrt-Devel] [PATCH] Add support for WeIO board

[Florian Fainelli]

Missing Signed-off-by tag and description of the patch.


Le 06/16/15 14:06, Drasko DRASKOVIC a écrit :
--
Florian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Controlling POE passthrough via GPIO

[Florian Fainelli]

On 22/06/15 16:48, Lars Kruse wrote:
> Hi,
> 
> within our wireless community we are using a couple of devices with the
> following features:
> * powered via POE through their first ethernet plug
> * another device can be powered via the second ethernet plug (POE passthrough
>   switchable via GPIO)
> 
> The POE passthrough feature can be controlled via GPIO pins.
> For our most common devices (Nanostation M5 and TP-Link CPE510) these are GPIO
> pins #2, #8 or #20 (depending on the model).
> 
> Currently we are using a custom script (see attached) for these models.
> 
> I have the feeling that this kind of hardware capabilities should be available
> within openwrt (similar to the LED setup).
> 
> Is there anything related already implemented within openwrt?
> If not: where would you recommend to put it?

You could eventually utilize the regulator framework to implement such
GPIO toggling to provide/remove power to a given device. I have not
looked at whether this is something controllable from user-space, but
there is an in-kernel API to be a "consumer" of the regulator API.

Of course this information should be made conditional to the device model.

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

Re: [OpenWrt-Devel] IPtables/NAT

[Florian Fainelli]

Hi,

Le 5 juil. 2015 20:20, "John kerry"  a écrit :
>
> Hi ,
>
> Hope you are doing great. I am working on Atheros QSDK.

You might get better support by contacting whoever maintains this QSDK ad
it is an OpenWrt derivative, however as far as OpenWrt is concerned, see
below.

i am able to compile the source code successfully and able to upgrade the
firmware using openWRT Luci GUI too. The OpenWRT being a linux distro for
embedded platform already has IPtables implemented. Before compiling the
source code i have to do a make menuconfig and enable the netfilter module
in networking. This would enable IPtables and compile it. Is my
undersatnding correct?

By default, OpennWrt comes with iptables and netfilter enabled.

>
> Could you please guide me to write the Iptables rule. Basically i have to
write the rules for iptables/NAT for the following condition.
> Router mode with NAT and iptables, the web page access to be available
only to LAN (WiFi/Wired).
> I have one LAN and one WAN Connection, the LAN ip set to some static IP
to access the GUI.

All of this is done by default by OpenWrt provided that you keep the
default selection of packages. You may have to ask the build system to
include luci (web gui) to include it in the image creation.

A lot of this is covered in details on the wiki, of course, working with
QSDK instead of the mainline OpenWrt, your mileage may vary.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 3/3] ar71xx: add spi nand driver support

[Florian Fainelli]

On 10/07/15 02:54, Pan, Miaoqing wrote:
> Agree with you,  I investigated this, tried to merge two into one.  E.g.  
> Implement the common core for spinand,  separate  vendors related codes,  but 
> give up finally as no device to verify mt29f:(  So I only add it to support 
> for ath79 platform.

There are some on-going efforts to come up with proper SPI NAND support
in the MTD layer, you might want to piggy back on that effort:

http://lists.infradead.org/pipermail/linux-mtd/2015-June/059837.html

> 
> Thanks,
> Miaoqing
> 
> -Original Message-
> From: Jonas Gorski [mailto:j...@openwrt.org] 
> Sent: Friday, July 10, 2015 5:44 PM
> To: Pan, Miaoqing
> Cc: OpenWrt Development List
> Subject: Re: [OpenWrt-Devel] [PATCH 3/3] ar71xx: add spi nand driver support
> 
> Hi,
> 
> On Fri, Jul 10, 2015 at 9:18 AM,   wrote:
>> From: Miaoqing Pan 
>>
>> Derived from 'drivers/staging/mt29f_spinand'.
>>
>> Only support Giga Device SPI NAND device now,
>> - GD5F1GQ4U 1G 3.3V 8-bit
>> - GD5F2GQ4U 2G 3.3V 8-bit
>> - GD5F1GQ4R 1G 1.8V 8-bit
>> - GD5F2GQ4R 2G 1.8V 8-bit
>>
>> Signed-off-by: Miaoqing Pan 
> 
> This looks exactly like mt29f_spinand, except with ath79_ prefixed to 
> everything. Also I don't see anything ath79 specific in here.
> 
> Why can't you just use mt29f_spinand directly? And why do you need to create 
> a copy of it instead of just fixing it in the driver itself?
> 
> 
> 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] Hard float ABI for BCM2708/BCM2709

[Florian Fainelli]

Le 11 juil. 2015 09:52, "Matthias Schiffer" 
a écrit :
>
> Hi,
> I've noticed that OpenWrt currently uses the soft-float ABI in the
> Raspberry Pi images. Is there a specific reason hard float is not used,
> even though most other distributions like Raspbian have switched to it?

I do not think there was any particular reason. This was one of the few
ARM-based targets that are not armv5, however armv5 may have been used as a
template to kick the initial port.

>
> I tried adding "fpu" to FEATURES to enable hard-float, and the generated
> images seem to work fine.

If you want to submit a patch doing this, I will gladly apply it, we may
have to set a different FPU ABI between brcm2708 and 09 though.
--
Florian
___
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] Prevent more gzip timestamps

[Florian Fainelli]

2015-07-12 9:41 GMT-07:00 Reiner Herrmann :
> To improve reproducibility, prevent the inclusion of timestamps
> in the gzip header.

This looks fine to me, this also unveils a lot of repetition in how we
invoke gzip and its parameters, would you mind factoring this in a
variable such that we control how gzip options are set globally?
Eventually someone will want to be able to turn back on timestamps and
original names in how gzip generates compressed files, and we might as
well have a single location to fix this.

Let's just hope that nobody relies on the original file names (does
not look like it).

>
> Signed-off-by: Reiner Herrmann 
> ---
>  docs/adding.tex| 2 +-
>  include/image.mk   | 2 +-
>  package/Makefile   | 2 +-
>  target/imagebuilder/files/Makefile | 2 +-
>  target/linux/adm5120/image/router_le.mk| 2 +-
>  target/linux/adm8668/image/Makefile| 2 +-
>  target/linux/ar71xx/image/Makefile | 6 +++---
>  target/linux/ath25/image/Makefile  | 2 +-
>  target/linux/brcm63xx/image/Makefile   | 2 +-
>  target/linux/generic/files/crypto/ocf/Makefile | 2 +-
>  target/linux/ipq806x/image/Makefile| 2 +-
>  target/linux/malta/image/Makefile  | 2 +-
>  target/linux/x86/image/Makefile| 4 ++--
>  target/linux/xburst/image/Makefile | 2 +-
>  14 files changed, 17 insertions(+), 17 deletions(-)
>
> diff --git a/docs/adding.tex b/docs/adding.tex
> index 97547ac..7b80c0d 100644
> --- a/docs/adding.tex
> +++ b/docs/adding.tex
> @@ -556,7 +556,7 @@ include $(INCLUDE_DIR)/image.mk
>
>  define Image/BuildKernel
>  cp $(KDIR)/vmlinux.elf $(BIN_DIR)/openwrt-$(BOARD)-vmlinux.elf
> -gzip -9 -c $(KDIR)/vmlinux > $(KDIR)/vmlinux.bin.gz
> +gzip -9n -c $(KDIR)/vmlinux > $(KDIR)/vmlinux.bin.gz
>  $(STAGING_DIR_HOST)/bin/lzma e $(KDIR)/vmlinux $(KDIR)/vmlinux.bin.l7
>  dd if=$(KDIR)/vmlinux.bin.l7 
> of=$(BIN_DIR)/openwrt-$(BOARD)-vmlinux.lzma bs=65536 conv=sync
>  dd if=$(KDIR)/vmlinux.bin.gz 
> of=$(BIN_DIR)/openwrt-$(BOARD)-vmlinux.gz bs=65536 conv=sync
> diff --git a/include/image.mk b/include/image.mk
> index 814e7dc..6767e76 100644
> --- a/include/image.mk
> +++ b/include/image.mk
> @@ -224,7 +224,7 @@ ifneq ($(CONFIG_TARGET_ROOTFS_UBIFS),)
>  endif
>
>  define Image/mkfs/cpiogz
> -   ( cd $(TARGET_DIR); find . | cpio -o -H newc | gzip -9 
> >$(BIN_DIR)/$(IMG_PREFIX)-rootfs.cpio.gz )
> +   ( cd $(TARGET_DIR); find . | cpio -o -H newc | gzip -9n 
> >$(BIN_DIR)/$(IMG_PREFIX)-rootfs.cpio.gz )
>  endef
>
>  define Image/mkfs/targz
> diff --git a/package/Makefile b/package/Makefile
> index 3ef34b1..cc691b5 100644
> --- a/package/Makefile
> +++ b/package/Makefile
> @@ -149,7 +149,7 @@ $(curdir)/index: FORCE
> mkdir -p $(PACKAGE_DIR)/$$d; \
> cd $(PACKAGE_DIR)/$$d || continue; \
> $(SCRIPT_DIR)/ipkg-make-index.sh . 2>&1 > Packages && \
> -   gzip -9c Packages > Packages.gz; \
> +   gzip -9nc Packages > Packages.gz; \
> ); done
>  ifdef CONFIG_SIGNED_PACKAGES
> @echo Signing package index...
> diff --git a/target/imagebuilder/files/Makefile 
> b/target/imagebuilder/files/Makefile
> index e28660f..8f25c4a 100644
> --- a/target/imagebuilder/files/Makefile
> +++ b/target/imagebuilder/files/Makefile
> @@ -121,7 +121,7 @@ package_index: FORCE
> @echo Building package index...
> @mkdir -p $(TMP_DIR) $(TARGET_DIR)/tmp
> (cd $(PACKAGE_DIR); $(SCRIPT_DIR)/ipkg-make-index.sh . > Packages && \
> -   gzip -9c Packages > Packages.gz \
> +   gzip -9nc Packages > Packages.gz \
> ) >/dev/null 2>/dev/null
> $(OPKG) update || true
>
> diff --git a/target/linux/adm5120/image/router_le.mk 
> b/target/linux/adm5120/image/router_le.mk
> index 6df6dcd..1e3d7f7 100644
> --- a/target/linux/adm5120/image/router_le.mk
> +++ b/target/linux/adm5120/image/router_le.mk
> @@ -72,7 +72,7 @@ define Image/Build/Cellvision
> $(call Image/Build/Loader,$(2),bin,0x8050,0x6D8,y,$(3))
> mkdir -p $(BIN_DIR)/tmp
> cp $(KDIR)/loader-$(2).bin $(BIN_DIR)/tmp/vmlinux.bin
> -   gzip -9 $(BIN_DIR)/tmp/vmlinux.bin
> +   gzip -9n $(BIN_DIR)/tmp/vmlinux.bin
> dd if=$(BIN_DIR)/tmp/vmlinux.bin.gz of=$(call 
> imgname,$(1),$(2))-xmodem.bin bs=64k conv=sync
> rm -rf $(BIN_DIR)/tmp
> $(call Image/Build/TRXNoloader,$(call imgname,$(1),$(2)).trx,$(1))
> diff --git a/target/linux/adm8668/image/Makefile 
> b/target/linux/adm8668/image/Makefile
> index 9e25224..597b8f7 100644
> --- a/target/linux/adm8668/image/Makefile
> +++ b/target/linux/adm8668/image/Makefile
> @@ -16,7 +16,7 @@ endef
>
>
>  define CompressGzip
> -   gzip -9 -c $(1) > $(2)
> +   gzip -9n -c $(1) > $(2)
>  endef
>
>  define MkImage
> diff -

Re: [OpenWrt-Devel] [PATCH 2/2] Prevent more gzip timestamps

[Florian Fainelli]

On 14/07/15 15:05, Reiner Herrmann wrote:
> On Sun, Jul 12, 2015 at 12:06:01PM -0700, Florian Fainelli wrote:
>> 2015-07-12 9:41 GMT-07:00 Reiner Herrmann :
>>> To improve reproducibility, prevent the inclusion of timestamps
>>> in the gzip header.
>>
>> This looks fine to me, this also unveils a lot of repetition in how we
>> invoke gzip and its parameters, would you mind factoring this in a
>> variable such that we control how gzip options are set globally?
>> Eventually someone will want to be able to turn back on timestamps and
>> original names in how gzip generates compressed files, and we might as
>> well have a single location to fix this.
> 
> The commands that are currently available in variables are named
> just in uppercase (FIND, TAR, etc.).
> But gzip also interprets the variable GZIP to parse additional
> options, so naming the variable for the command also GZIP will
> probably cause problems.

Ah good point. How about GZIP_CMD then?

> Or would it be better to just globally export GZIP with the
> default parameters (which would then differ from the currents
> semantics of having the command inside the variable)?

We could do that, I am just wondering if this would make it a bit more
difficult to debug in case we forgot to patch a given Makefile or that
we do reset the environment/do not inherit it.
--
Florian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Split kernel modules out of the base opkg repo?

[Florian Fainelli]

On Jul 25, 2015 7:39 AM, "Matthias Schiffer" 
wrote:
>
> On 07/25/2015 03:55 PM, John Crispin wrote:
> >
> >
> > On 25/07/2015 14:46, Matthias Schiffer wrote:
> >> Hi,
> >> I'd like to propose to split the current "base" opkg repo into two, one
> >> for userspace applications and one for kernel modules. This would
> >> greatly simplify providing your own kernel module repository with
> >> modules for a customized kernel, while still being able to rely on the
> >> upstream "base" repo for userspace.
> >>
> >> I'll provide a patch for this if you think this is a reasonable idea.
> >>
> >> Matthias
> >>
> >
> > i think the current setup works very well for open drivers and code.
> > fixing up openwrt for out of tree modules is imho not a good idea as it
> > allows companies to easily avoid upstreaming stuff.
> >
> > why dont you just include your magic USP into openwrt and/or upstream ?
>
> I'm not talking about out-of-tree modules at all, I'm talking about the
> kmod-* packages in the base repo. I want to provide an own opkg repo
> with the same kernel modules, but built for a customized kernel.
>
> As these modules' ABI depends on the kernel configuration (and thus the
> kernel configuration is included in the version number as "vermagic"), I
> need to provide the kernel modules built matching my configuration. As
> far as I know there's no way to tell opkg to prefer the modules from my
> repo, regardless of the version number, so I'm asking for a base repo
> without any kmod-* packages.

But since this is already a custom repository, why not take care yourself
of synchronizing the base packages (but not kmod-*) from OpenWrt's upstream
directly?

If you dedicate a custom kernel image version to make sure that OpenWrt
kmods cannot be installed, does not that work already?

>
>
> ___
> 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 v2 2/3] mcs814x: fix interrupts

[Florian Fainelli]

On Jul 27, 2015 3:54 AM, "Günther Kelleter" 
wrote:
>
> create explicit 1:1 mapping before mcs814x_alloc_gc/irq_setup_generic_chip
> marks all interrupts used and prevents mapping by dts init.
> IRQ 0 is the timer interrupt and is not illegal!

Is the second hunk of the patch still necessary then? Some other people
seem to have run into similar problems on Dove, you might to look at what
they did to avoid having to remove the check against virq 0.

>
> Was broken since kernel 3.14.
>
> Signed-off-by: Günther Kelleter 
> ---
>  target/linux/mcs814x/files-3.18/arch/arm/mach-mcs814x/irq.c |  6 +-
>  target/linux/mcs814x/patches-3.18/015-timer-irq.patch   | 11
+++
>  2 files changed, 16 insertions(+), 1 deletion(-)
>  create mode 100644 target/linux/mcs814x/patches-3.18/015-timer-irq.patch
>
> diff --git a/target/linux/mcs814x/files-3.18/arch/arm/mach-mcs814x/irq.c
b/target/linux/mcs814x/files-3.18/arch/arm/mach-mcs814x/irq.c
> index f84c412..fd4345f 100644
> --- a/target/linux/mcs814x/files-3.18/arch/arm/mach-mcs814x/irq.c
> +++ b/target/linux/mcs814x/files-3.18/arch/arm/mach-mcs814x/irq.c
> @@ -71,6 +71,7 @@ static const struct of_device_id mcs814x_intc_ids[] = {
>  void __init mcs814x_of_irq_init(void)
>  {
> struct device_node *np;
> +   struct irq_domain *domain;
>
> np = of_find_matching_node(NULL, mcs814x_intc_ids);
> if (!np)
> @@ -80,7 +81,10 @@ void __init mcs814x_of_irq_init(void)
> if (!mcs814x_intc_base)
> panic("unable to map intc cpu registers\n");
>
> -   irq_domain_add_simple(np, 32, 0, &irq_generic_chip_ops, NULL);
> +   domain = irq_domain_add_simple(np, 32, 0, &irq_domain_simple_ops,
NULL);
> +   if (!domain)
> +   panic("unable to add irq domain\n");
> +   irq_create_strict_mappings(domain, 0, 0, 32);
>
> of_node_put(np);
>
> diff --git a/target/linux/mcs814x/patches-3.18/015-timer-irq.patch
b/target/linux/mcs814x/patches-3.18/015-timer-irq.patch
> new file mode 100644
> index 000..9bbb094
> --- /dev/null
> +++ b/target/linux/mcs814x/patches-3.18/015-timer-irq.patch
> @@ -0,0 +1,11 @@
> +--- a/kernel/irq/irqdesc.c
>  b/kernel/irq/irqdesc.c
> +@@ -381,7 +381,7 @@ int __handle_domain_irq(struct irq_domai
> +* Some hardware gives randomly wrong interrupts.  Rather
> +* than crashing, do something sensible.
> +*/
> +-  if (unlikely(!irq || irq >= nr_irqs)) {
> ++  if (unlikely(irq >= nr_irqs)) {
> +   ack_bad_irq(irq);
> +   ret = -EINVAL;
> +   } else {
> --
> 2.4.6.89.g851dcf4
> ___
> 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 v2 1/3] mcs814x: fix debug UART

[Florian Fainelli]

On Jul 27, 2015 3:54 AM, "Günther Kelleter" 
wrote:
>
> It was broken since kernel 3.14

True, but your patch does not explain how you are fixing this, which is
what matters for a good commit message. Could expand on why migrating to
the generic 8250 debug uart code is fixing things?

>
> Signed-off-by: Günther Kelleter 
> ---
>  target/linux/mcs814x/config-3.18   | 10 --
>  .../linux/mcs814x/patches-3.18/014-debuguart.patch | 41
++
>  2 files changed, 48 insertions(+), 3 deletions(-)
>  create mode 100644 target/linux/mcs814x/patches-3.18/014-debuguart.patch
>
> diff --git a/target/linux/mcs814x/config-3.18
b/target/linux/mcs814x/config-3.18
> index 87a8382..e57f5ff 100644
> --- a/target/linux/mcs814x/config-3.18
> +++ b/target/linux/mcs814x/config-3.18
> @@ -49,10 +49,15 @@ CONFIG_CRYPTO_CRC32C=y
>  CONFIG_CRYPTO_HASH=y
>  CONFIG_CRYPTO_HASH2=y
>  CONFIG_DEBUG_LL=y
> -CONFIG_DEBUG_LL_INCLUDE="mach/debug-macro.S"
> +CONFIG_DEBUG_LL_INCLUDE="debug/8250.S"
>  CONFIG_DEBUG_LL_UART_NONE=y
> -# CONFIG_DEBUG_UART_8250 is not set
> +CONFIG_DEBUG_UART_8250=y
> +# CONFIG_DEBUG_UART_8250_FLOW_CONTROL is not set
> +CONFIG_DEBUG_UART_8250_SHIFT=2
> +# CONFIG_DEBUG_UART_8250_WORD is not set
> +CONFIG_DEBUG_UART_PHYS=0x400dc000
>  # CONFIG_DEBUG_UART_PL01X is not set
> +CONFIG_DEBUG_UART_VIRT=0xf00dc000
>  # CONFIG_DEBUG_USER is not set
>  CONFIG_DTC=y
>  CONFIG_EARLY_PRINTK=y
> @@ -157,7 +162,6 @@ CONFIG_MTD_PHYSMAP=y
>  CONFIG_MULTI_IRQ_HANDLER=y
>  CONFIG_NEED_DMA_MAP_STATE=y
>  CONFIG_NEED_KUSER_HELPERS=y
> -CONFIG_NEED_MACH_MEMORY_H=y
>  CONFIG_NEED_PER_CPU_KM=y
>  CONFIG_NET_KEY=y
>  # CONFIG_NET_VENDOR_BROADCOM is not set
> diff --git a/target/linux/mcs814x/patches-3.18/014-debuguart.patch
b/target/linux/mcs814x/patches-3.18/014-debuguart.patch
> new file mode 100644
> index 000..5f1b67f
> --- /dev/null
> +++ b/target/linux/mcs814x/patches-3.18/014-debuguart.patch
> @@ -0,0 +1,41 @@
> +--- a/arch/arm/mach-mcs814x/include/mach/debug-macro.S
>  /dev/null
> +@@ -1,11 +0,0 @@
> +-#include 
> +-
> +-.macro  addruart, rp, rv, tmp
> +-  ldr \rp, =MCS814X_PHYS_BASE
> +-  ldr \rv, =MCS814X_VIRT_BASE
> +-  orr \rp, \rp, #MCS814X_UART
> +-  orr \rv, \rv, #MCS814X_UART
> +-.endm
> +-
> +-#define UART_SHIFT2
> +-#include 
> +--- a/arch/arm/Kconfig.debug
>  b/arch/arm/Kconfig.debug
> +@@ -1089,7 +1089,7 @@ config DEBUG_UART_8250
> +   (FOOTBRIDGE && !DEBUG_DC21285_PORT) || \
> +   ARCH_GEMINI || ARCH_IOP13XX || ARCH_IOP32X || \
> +   ARCH_IOP33X || ARCH_IXP4XX || \
> +-  ARCH_LPC32XX || ARCH_MV78XX0 || ARCH_ORION5X || ARCH_RPC
> ++  ARCH_LPC32XX || ARCH_MCS814X || ARCH_MV78XX0 ||
ARCH_ORION5X || ARCH_RPC
> +
> + # Compatibility options for BCM63xx
> + config DEBUG_UART_BCM63XX
> +@@ -1124,6 +1124,7 @@ config DEBUG_UART_PHYS
> +   default 0x3e00 if DEBUG_BCM_KONA_UART
> +   default 0x4000e400 if DEBUG_LL_UART_EFM32
> +   default 0x4009 if ARCH_LPC32XX
> ++  default 0x400dc000 if ARCH_MCS814X
> +   default 0x4010 if DEBUG_PXA_UART1
> +   default 0x4200 if ARCH_GEMINI
> +   default 0x5000 if DEBUG_S3C24XX_UART && (DEBUG_S3C_UART0 || \
> +@@ -1178,6 +1179,7 @@ config DEBUG_UART_VIRT
> +   default 0xe0010fe0 if ARCH_RPC
> +   default 0xe100 if DEBUG_MSM_UART
> +   default 0xfbe0 if ARCH_EBSA110
> ++  default 0xf00dc000 if ARCH_MCS814X
> +   default 0xf01fb000 if DEBUG_NOMADIK_UART
> +   default 0xf0201000 if DEBUG_BCM2835
> +   default 0xf1000300 if DEBUG_BCM_5301X
> --
> 2.4.6.89.g851dcf4
> ___
> 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 v2 3/3] mcs814x: use firmware partition splitter on dLAN USB Extender

[Florian Fainelli]

On Jul 27, 2015 3:55 AM, "Günther Kelleter" 
wrote:

Looks good to me, having a better commit message would be welcome.

>
> Signed-off-by: Günther Kelleter 
> ---
>  target/linux/mcs814x/config-3.18  | 4

>  .../mcs814x/files-3.18/arch/arm/boot/dts/dlan-usb-extender.dts| 8

>  target/linux/mcs814x/image/Makefile   | 2 +-
>  3 files changed, 5 insertions(+), 9 deletions(-)
>
> diff --git a/target/linux/mcs814x/config-3.18
b/target/linux/mcs814x/config-3.18
> index e57f5ff..427a7c9 100644
> --- a/target/linux/mcs814x/config-3.18
> +++ b/target/linux/mcs814x/config-3.18
> @@ -159,6 +159,10 @@ CONFIG_MODULES_USE_ELF_REL=y
>  # CONFIG_MTD_IMPA7 is not set
>  CONFIG_MTD_JEDECPROBE=y
>  CONFIG_MTD_PHYSMAP=y
> +# CONFIG_MTD_ROOTFS_SPLIT is not set
> +CONFIG_MTD_SPLIT_FIRMWARE=y
> +CONFIG_MTD_SPLIT_FIRMWARE_NAME="linux"
> +CONFIG_MTD_SPLIT_UIMAGE_FW=y
>  CONFIG_MULTI_IRQ_HANDLER=y
>  CONFIG_NEED_DMA_MAP_STATE=y
>  CONFIG_NEED_KUSER_HELPERS=y
> diff --git
a/target/linux/mcs814x/files-3.18/arch/arm/boot/dts/dlan-usb-extender.dts
b/target/linux/mcs814x/files-3.18/arch/arm/boot/dts/dlan-usb-extender.dts
> index 0c85b94..59830e8 100644
> ---
a/target/linux/mcs814x/files-3.18/arch/arm/boot/dts/dlan-usb-extender.dts
> +++
b/target/linux/mcs814x/files-3.18/arch/arm/boot/dts/dlan-usb-extender.dts
> @@ -48,14 +48,6 @@
> reg = <0x4 0x1>;
> };
> partition@5 {
> -   label = "kernel";
> -   reg = <0x5 0x10>;
> -   };
> -   partition@15 {
> -   label = "rootfs";
> -   reg = <0x15 0x3C>;
> -   };
> -   partition@50001 {
> label = "linux";
> reg = <0x5 0x4C>;
> };
> diff --git a/target/linux/mcs814x/image/Makefile
b/target/linux/mcs814x/image/Makefile
> index 4c8af97..74f8ad4 100644
> --- a/target/linux/mcs814x/image/Makefile
> +++ b/target/linux/mcs814x/image/Makefile
> @@ -30,7 +30,7 @@ define Image/Build/DTB
>  endef
>
>  define Image/Build/Profile/dLAN_USB_Extender
> -   dd if=$(KDIR)/uImage-dlan-usb-extender bs=1M conv=sync
of=$(KDIR)/$(IMG_PREFIX)-dlan-usb-extender-upgrade-$(1).bin
> +   dd if=$(KDIR)/uImage-dlan-usb-extender bs=64k conv=sync
of=$(KDIR)/$(IMG_PREFIX)-dlan-usb-extender-upgrade-$(1).bin
> cat $(KDIR)/root.$(1) >>
$(KDIR)/$(IMG_PREFIX)-dlan-usb-extender-upgrade-$(1).bin
> cp $(KDIR)/$(IMG_PREFIX)-dlan-usb-extender-upgrade-$(1).bin
$(BIN_DIR)/
>  endef
> --
> 2.4.6.89.g851dcf4
> ___
> 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 6/6] malta: set CPU_TYPE:=24kc.

[Florian Fainelli]

Le 1 sept. 2015 05:22, "Yousong Zhou"  a écrit :
>
> Signed-off-by: Yousong Zhou 
> ---
>  target/linux/malta/Makefile |1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/target/linux/malta/Makefile b/target/linux/malta/Makefile
> index 9352dfa..0cce15e 100644
> --- a/target/linux/malta/Makefile
> +++ b/target/linux/malta/Makefile
> @@ -8,6 +8,7 @@ include $(TOPDIR)/rules.mk
>
>  BOARD:=malta
>  BOARDNAME:=MIPS Malta CoreLV board (qemu)
> +CPU_TYPE:=24kc

This is certainly valid, but needs to come up with a better explanation as
to why we would want this.

>  SUBTARGETS:=le be #le64 be64
>  INITRAMFS_EXTRA_FILES:=
>  MAINTAINER:=Florian Fainelli 
> --
> 1.7.10.4
> ___
> 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 4/6] generic: fix unrecognized opcode wsbh when building for MIPS16.

[Florian Fainelli]

Le 1 sept. 2015 05:22, "Yousong Zhou"  a écrit :
>
> The issue was found and reported by hynman [1] when compiling reaver for
ar71xx
> (Big Endian MIPS).
>
> {standard input}: Assembler messages:
> {standard input}:79: Error: unrecognized opcode `wsbh $2,$2'
> {standard input}:90: Error: unrecognized opcode `wsbh $3,$17'
> {standard input}:208: Error: unrecognized opcode `wsbh $2,$2'
> make[3]: *** [builder.o] Error 1

Could you submit this to the linux-mips mailing list first so we only get
to backport an accepted patch?
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] OpenWRT www version banner a security risk

[Florian Fainelli]

On Sep 13, 2015 2:00 PM, "Etienne Champetier" 
wrote:
>
> Hi Daniel,
>
> Le 13 sept. 2015 22:04, "Daniel Dickinson" 
a écrit :
> >
> > I do think allowing to choose to disable the banner is a minor benefit,
however, as I've said, there are much more effective means of preventing
accidential exposure, and quite frankly if the user is *choosing* to open
the web interface I think an warning and disabling the banner if the user
foolishly insists on opening the interface despite the warning is more
useful thank disabling the banner by default.
> >
> > If you're going to argue it prevents against internal threats than I
would argue that if your internal network is hostile enough that you need
to worry about attacks on openwrt from your internal network AND you're not
skilled enough to limit access to LuCI (or better, build an image without
LuCI and just use SSH) to the specific trusted hosts (preferably by
combination of MAC address and IP address) in the firewall, or (better) to
use a 'management' VPN or VLAN that only trusted hosts can get on, then
you're in a lot more trouble than eliminating the banner for LuCI will
solve.
> >
> >
> > Regards,
> >
> > Daniel
> >
> > On 2015-09-13 10:21 AM, MauritsVB wrote:
> >>
> >> At the moment the OpenWRT www login screen provides *very* detailed
version information before anyone has even entered a password. It displays
not just “15.05” or “Chaos Calmer” but even the exact git version on the
banner.
> >>
> >> While it’s not advised to open this login screen to the world, fact is
that it does happen intentionally or accidentally. Just a Google search for
“Powered by LuCI Master (git-“ will provide many accessible OpenWRT login
screens, including exact version information.
> >>
> >> As soon as someone discovers a vulnerability in a OpenWRT version all
an attacker needs to do is perform a Google search to find many
installations with versions that are vulnerable (even if a patch is already
available).
> >>
> >> In the interest of hardening the default OpenWRT install, can I
suggest that by default OpenWRT doesn’t disclose the version (not even
15.05 or “Chaos Calmer”) on the login screen? For extra safety I would even
suggest to leave “OpenWRT” off the login screen, the only people who should
use this screen already know it’s running OpenWRT.
> >>
> >> Any thoughts?
> >>
> >> Maurits
> >>
>
> For me listenning only on lan will break all my setups (15+):
> - On most of my openwrt there is no lan, it's management, or
'name-of-the-site' ...
> - on some of them i can access from multiple interface (VPNs + ...)
>
> You can't prevent people from shooting themselves in the foot (maybe port
openning was on purpose),
> but you can:
> -Put a huge warning in luci when you set firewall default to 'ACCEPT'
> -add robots.txt (i think the router will still end up on shodan)
> -add a big warning if robots.txt is accessed (reliable way to know that
you're open on the internet)
>
> Also you are talking about luci but what about dropbear (ssh)? There is
no anti brute force, and maybe there is a banner (on my phone, can't check)

For that you could setup different things ranging from using iptables'
mlimit match per protocol all the way to having something like fail2ban
(written in python though) which can do more complex
blacklisting/blackholing.

All of that is more of a security policy that you deploy rather than want
it by default, even though it may seem very sensible for a default use case.

The bottom line is that if you are exposed to the wild internet, just brace
yourself, it is only a matter of time before your host gets scanned, brute
forced or even penetrated.
--
Florian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [OpenWrt-Commits] r46981 - trunk/target/linux/generic/patches-3.18

[Florian Fainelli]

On 16/09/15 05:08, openwrt-comm...@openwrt.org wrote:
> Author: blogic
> Date: 2015-09-16 14:08:05 +0200 (Wed, 16 Sep 2015)
> New Revision: 46981
> 
> Modified:
>trunk/target/linux/generic/patches-3.18/652-atm_header_changes.patch
> Log:
> kernel: properly guard the lantiq atm abi hack with an ifdef

Would not it make sense to move this to target/linux/lantiq now that
this is target-specific?

> 
> Signed-off-by: John Crispin 
> 
> Modified: trunk/target/linux/generic/patches-3.18/652-atm_header_changes.patch
> ===
> --- trunk/target/linux/generic/patches-3.18/652-atm_header_changes.patch  
> 2015-09-16 09:37:39 UTC (rev 46980)
> +++ trunk/target/linux/generic/patches-3.18/652-atm_header_changes.patch  
> 2015-09-16 12:08:05 UTC (rev 46981)
> @@ -1,12 +1,14 @@
>  --- a/include/uapi/linux/atm.h
>  +++ b/include/uapi/linux/atm.h
> -@@ -154,6 +154,9 @@
> +@@ -154,6 +154,11 @@
>   unsigned int adtf  :10; /* ACR Decrease Time Factor (10-bit) */
>   unsigned int cdf   :3;  /* Cutoff Decrease Factor (3-bit) */
>   unsigned int spare :9;  /* spare bits */ 
> ++#ifdef CONFIG_LANTIQ
>  +int scr;/* sustained rate in cells per second */
>  +int mbs;/* maximum burst size (MBS) in cells */
>  +int cdv;/* Cell delay varition */
> ++#endif
>   };
>   
>   struct atm_qos {
> ___
> openwrt-commits mailing list
> openwrt-comm...@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-commits
> 
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] swconfig: support setting SWITCH_TYPE_LINK attributes

[Florian Fainelli]

On Jan 13, 2016 10:07 PM, "Stefan Rompf"  wrote:
>
> Hi,
>
> On Montag, 11. Januar 2016 23:45:39 Rafał Miłecki wrote:
>
> > > Any comments to this usage/syntax? It doesn't look too nice (this long
> > > quoted string as a value), but swconfig is strongly focused on simple
> > > values.
> >
> > One more RFC... anyone?
>
> I am not an OpenWRT core developer so I cannot comment on the niceness of
the
> interface ;-) The string does not allow to specify combinations like
autoneg
> on, advertise 10 and 1000, but not 100, but that would be a very esoteric
use
> case and it is about configuring a switch port and not an ethernet tester.
> IMHO for the normal use case, it allows to specify everything that is
needed.
>
> So for me it's all right.

Same here, does not really bother me to go through several command lines to
get the desired settings.

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

Re: [OpenWrt-Devel] [PATCH] kernel/build: Fix SetNfsCmdline to work with new .config.set

[Florian Fainelli]

On 09/02/16 09:08, Petr Štetiar wrote:
> This patch fixes SetNfsCmdline macro which is currently relying on old
> kernel .config file, which has been replaced with intermediate
> .config.set file. It was leading to the following kernel build error:
> 
>   rm -f linux-4.4/.config.prev
>   mv linux-4.4/.config linux-4.4/.config.old
>   mv: cannot stat 'linux-4.4/.config': No such file or directory
> 
> Signed-off-by: Petr Štetiar 

Thanks for fixing this, seems like I missed that while rebasing and
pushing the patch out.

> ---
>  include/kernel-defaults.mk | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/include/kernel-defaults.mk b/include/kernel-defaults.mk
> index 4b5de5b..44e3c27 100644
> --- a/include/kernel-defaults.mk
> +++ b/include/kernel-defaults.mk
> @@ -107,9 +107,9 @@ endef
>  ifeq ($(CONFIG_KERNEL_ROOT_NFS),y)
>define Kernel/SetNfsCmdline
>   rm -f $(LINUX_DIR)/.config.prev
> - mv $(LINUX_DIR)/.config $(LINUX_DIR)/.config.old
> - grep -v "CONFIG_CMDLINE=" $(LINUX_DIR)/.config.old > 
> $(LINUX_DIR)/.config
> - grep "CONFIG_CMDLINE=" $(LINUX_DIR)/.config.old | cut -d\" -f2 | sed 
> 's/root=\/dev\/\([a-z0-9]*\)\(.*\)/CONFIG_CMDLINE=\"root=\/dev\/nfs 
> ip=dhcp\2\"/' >> $(LINUX_DIR)/.config
> + mv $(LINUX_DIR)/.config.set $(LINUX_DIR)/.config.old
> + grep -v "CONFIG_CMDLINE=" $(LINUX_DIR)/.config.old > 
> $(LINUX_DIR)/.config.set
> + grep "CONFIG_CMDLINE=" $(LINUX_DIR)/.config.old | cut -d\" -f2 | sed 
> 's/root=\/dev\/\([a-z0-9]*\)\(.*\)/CONFIG_CMDLINE=\"root=\/dev\/nfs 
> ip=dhcp\2\"/' >> $(LINUX_DIR)/.config.set
>endef
>  else
>define Kernel/SetNfsCmdline
> 
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] kernel/build: Fix SetNfsCmdline to work with new .config.set

[Florian Fainelli]

Le 09/02/2016 12:16, Petr Štetiar a écrit :
> Petr Štetiar  [2016-02-09 21:04:14]:
> 
>>>define Kernel/SetNfsCmdline
>>> rm -f $(LINUX_DIR)/.config.prev
>>> -   mv $(LINUX_DIR)/.config $(LINUX_DIR)/.config.old
>>> -   grep -v "CONFIG_CMDLINE=" $(LINUX_DIR)/.config.old > 
>>> $(LINUX_DIR)/.config
>>> -   grep "CONFIG_CMDLINE=" $(LINUX_DIR)/.config.old | cut -d\" -f2 | sed 
>>> 's/root=\/dev\/\([a-z0-9]*\)\(.*\)/CONFIG_CMDLINE=\"root=\/dev\/nfs 
>>> ip=dhcp\2\"/' >> $(LINUX_DIR)/.config
>>> +   mv $(LINUX_DIR)/.config.set $(LINUX_DIR)/.config.old
>>> +   grep -v "CONFIG_CMDLINE=" $(LINUX_DIR)/.config.old > 
>>> $(LINUX_DIR)/.config.set
>>> +   grep "CONFIG_CMDLINE=" $(LINUX_DIR)/.config.old | cut -d\" -f2 | sed 
>>> 's/root=\/dev\/\([a-z0-9]*\)\(.*\)/CONFIG_CMDLINE=\"root=\/dev\/nfs 
>>> ip=dhcp\2\"/' >> $(LINUX_DIR)/.config.set
>>>endef
>>
>> This cut/sed kung-fu needs some improvements:
>>
>>  * it doesn't work correctly in case of empty cmdline, CONFIG_CMDLINE=""
>>  * how to handle custom cmdline options? For example I don't want to use this
>>hardcoded cmdline options, but use instead options provided by the 
>> bootloader
> 
> Hm, now I'm wondering why is this macro needed at all. In case I'll set
> CONFIG_KERNEL_ROOT_NFS=y, then I can set CONFIG_CMDLINE accordingly also,
> right?
> 
> Florian, what's your use case for this SetNfsCmdline macro, that you need to
> hardcode kernel cmdline options? Thanks.

Not all platforms get their command-line from the bootloader, or Device
Tree, or whatever, some do actually hardcode the command-line into the
kernel, that's what motivated this change in the first place.

I am fine dropping this, since obviously; if you turn on the option you
know what you are doing, can you re-submit the patch you think is
appropriate?
--
Florian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] kernel/build: Fix SetNfsCmdline to work with new .config.set

[Florian Fainelli]

Le 10/02/2016 03:43, Petr Štetiar a écrit :
> Florian Fainelli  [2016-02-09 19:57:22]:
> 
>> Le 09/02/2016 12:16, Petr Štetiar a écrit :
>>> Petr Štetiar  [2016-02-09 21:04:14]:
>>>
>>>>>define Kernel/SetNfsCmdline
>>>>>   rm -f $(LINUX_DIR)/.config.prev
>>>>> - mv $(LINUX_DIR)/.config $(LINUX_DIR)/.config.old
>>>>> - grep -v "CONFIG_CMDLINE=" $(LINUX_DIR)/.config.old > 
>>>>> $(LINUX_DIR)/.config
>>>>> - grep "CONFIG_CMDLINE=" $(LINUX_DIR)/.config.old | cut -d\" -f2 | sed 
>>>>> 's/root=\/dev\/\([a-z0-9]*\)\(.*\)/CONFIG_CMDLINE=\"root=\/dev\/nfs 
>>>>> ip=dhcp\2\"/' >> $(LINUX_DIR)/.config
>>>>> + mv $(LINUX_DIR)/.config.set $(LINUX_DIR)/.config.old
>>>>> + grep -v "CONFIG_CMDLINE=" $(LINUX_DIR)/.config.old > 
>>>>> $(LINUX_DIR)/.config.set
>>>>> + grep "CONFIG_CMDLINE=" $(LINUX_DIR)/.config.old | cut -d\" -f2 | sed 
>>>>> 's/root=\/dev\/\([a-z0-9]*\)\(.*\)/CONFIG_CMDLINE=\"root=\/dev\/nfs 
>>>>> ip=dhcp\2\"/' >> $(LINUX_DIR)/.config.set
>>>>>endef
>>>>
>>>> This cut/sed kung-fu needs some improvements:
>>>>
>>>>  * it doesn't work correctly in case of empty cmdline, CONFIG_CMDLINE=""
>>>>  * how to handle custom cmdline options? For example I don't want to use 
>>>> this
>>>>hardcoded cmdline options, but use instead options provided by the 
>>>> bootloader
>>>
>>> Hm, now I'm wondering why is this macro needed at all. In case I'll set
>>> CONFIG_KERNEL_ROOT_NFS=y, then I can set CONFIG_CMDLINE accordingly also,
>>> right?
>>>
>>> Florian, what's your use case for this SetNfsCmdline macro, that you need to
>>> hardcode kernel cmdline options? Thanks.
>>
>> Not all platforms get their command-line from the bootloader, or Device
>> Tree, or whatever, some do actually hardcode the command-line into the
>> kernel, that's what motivated this change in the first place.
> 
> I see, but I'm not sure how to handle it properly so it works for other use
> cases as well. Maybe adding something like CONFIG_CMDLINE_NFSROOT option, but
> this seems like overdesigning to me...
> 
> FYI, I'm using this base-files-nfs[1] package for development over NFS for a
> few years already, currently on i.MX6 with u-boot like this:
> 
>   setenv nfsroot /opt/devel/openwrt-master.git/bin/imx6/rootfs
>   setenv nfsargs root=/dev/nfs nfsroot=${serverip}:${nfsroot} 
> ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:apalis:eth0:off nfsrootdebug
> 
> I've noticed, that you've added something similar to the OpenWRT config
> directly:
> 
>buildroot: add options to build the kernel for NFS boot
> 
> And I've to test it yet - just wondering if we don't need to use similar
> approach to skip network initialization in case we boot over NFS as it's
> currently done in base-files-nfs[1] package.

We do need to skip network initialization yes, your commit looks good to
me, though we would want the default base-files to be nfsroot aware, not
a specific package (seems like you do this because of local
customization, that seems fine).

Grepping for "nfsroot" is not exactly failsafe AFAIR, since you can just
have "root=/dev/nfs" and that would be enough to trump the script. Even
better is probably to look at /proc/mounts.

> 
>> I am fine dropping this, since obviously; if you turn on the option you
>> know what you are doing, can you re-submit the patch you think is
>> appropriate?
> 
> From my point of view this macro SetNfsCmdline is not needed as you can
> specify CONFIG_CMDLINE directly in your config. If you think also, that we
> don't need this SetNfsCmdline macro, then you can just revert it yourself,
> right? :-)

I just reverted this in r48689
--
Florian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [RFC 0/4] Add support for Raspberry Pi 3

[Florian Fainelli]

On Feb 29, 2016 12:08 PM, "Álvaro Fernández Rojas" 
wrote:
>
> This adds untested support for Raspberry Pi 3.
> I will be able to test it when I get my RPi 3 ;D.

Will give it a shot tomorrow morning, thanks for quickly sending the
patches out.

>
> In the meantime if anyone already has a RPi 3 and wants to test it here's
the image:
>
http://files.noltari.es/openwrt/rpi3/openwrt-brcm2708-bcm2710-rpi-3-ext4-sdcard.img
>
http://files.noltari.es/openwrt/rpi3/openwrt-brcm2708-bcm2710-rpi-3-ext4-sdcard.img.gz
>
> Álvaro Fernández Rojas (4):
>   include: add Cortex-A53 CPU_TYPE
>   brcm2708-gpu-fw: update to latest version
>   brcm2708: update linux 4.4 patches to latest version
>   brcm2708: add Raspberry Pi 3 support
>
>  include/target.mk  |   1 +
>  package/kernel/brcm2708-gpu-fw/Makefile|   8 +-
>  target/linux/brcm2708/Makefile |   8 +-
>  target/linux/brcm2708/bcm2708/config-4.4   |   4 +-
>  target/linux/brcm2708/bcm2709/config-4.4   |   4 +-
>  target/linux/brcm2708/bcm2710/config-4.4   | 390 
>  .../brcm2708/bcm2710/profiles/RaspberryPi3.mk  |  14 +
>  target/linux/brcm2708/bcm2710/target.mk|  12 +
>  target/linux/brcm2708/image/Makefile   |  12 +-
>  target/linux/brcm2708/modules.mk   |  19 +
>  ...0001-smsx95xx-fix-crimes-against-truesize.patch |   4 +-
>  ...02-smsc95xx-Disable-turbo-mode-by-default.patch |   4 +-
>  ...around-for-issue-where-dirty-page-count-g.patch |   4 +-
>  .../0004-BCM2835_DT-Fix-I2S-register-map.patch |   4 +-
>  ...-Prevent-spurious-interrupts-and-trap-the.patch |   4 +-
>  .../0006-irqchip-bcm2835-Add-FIQ-support.patch |   4 +-
>  ...-irqchip-irq-bcm2835-Add-2836-FIQ-support.patch |   4 +-
>  ...erial-8250-Don-t-crash-when-nr_uarts-is-0.patch |   4 +-
>  ...2835-Set-base-to-0-give-expected-gpio-num.patch |   4 +-
>  ...2835-Fix-interrupt-handling-for-GPIOs-28-.patch |   4 +-
>  ...2835-Only-request-the-interrupts-listed-i.patch |   4 +-
>  ...cm2835-Support-pin-groups-other-than-7-11.patch |   4 +-
>  ...RM-bcm2835-Set-Serial-number-and-Revision.patch |   4 +-
>  ...-get-base-address-for-DMA-from-devicetree.patch |   4 +-
>  ...-add-24bit-support-update-bclk_ratio-to-m.patch |   4 +-
>  ...s-setup-clock-only-if-CPU-is-clock-master.patch |   4 +-
>  ...835-i2s-Eliminate-debugfs-directory-error.patch |   4 +-
>  .../0018-bcm2835-i2s-Register-PCM-device.patch |   4 +-
>  ...i2s-Enable-MMAP-support-via-a-DT-property.patch |   4 +-
>  ...0-dmaengine-bcm2835-Add-slave-dma-support.patch |   4 +-
>  ...ine-bcm2835-set-residue_granularity-field.patch |   4 +-
>  ...cm2835-Load-driver-early-and-support-lega.patch |   4 +-
>  ...-dma-Fix-dreq-not-set-for-slave-transfers.patch |   4 +-
>  ...-Limit-cyclic-transfers-on-lite-channels-.patch |   4 +-
>  .../0025-bcm2835-Add-support-for-uart1.patch   |   4 +-
>  ...irmware-bcm2835-Add-missing-property-tags.patch |   4 +-
>  .../0027-Main-bcm2708-bcm2709-linux-port.patch |   4 +-
>  ...-squash-include-ARCH_BCM2708-ARCH_BCM2709.patch |   4 +-
>  .../patches-4.4/0029-Add-dwc_otg-driver.patch  |   4 +-
>  .../0030-bcm2708-framebuffer-driver.patch  |   4 +-
>  .../0031-dmaengine-Add-support-for-BCM2708.patch   |   4 +-
>  ...-parameter-to-mmc-multi_io_quirk-callback.patch |   4 +-
>  .../0033-MMC-added-alternative-MMC-driver.patch|   4 +-
>  ...835-sdhost-driver-and-an-overlay-to-enabl.patch |   4 +-
>  ...ma-Add-vc_cma-driver-to-enable-use-of-CMA.patch |   4 +-
>  .../0036-bcm2708-alsa-sound-driver.patch   |   4 +-
>  .../patches-4.4/0037-bcm2708-vchiq-driver.patch|   4 +-
>  .../0038-vc_mem-Add-vc_mem-driver.patch|   4 +-
>  ...deoCore-shared-memory-service-for-BCM2835.patch |   4 +-
>  ...omem-device-for-rootless-user-GPIO-access.patch |   4 +-
>  .../brcm2708/patches-4.4/0041-Add-SMI-driver.patch |   4 +-
>  .../patches-4.4/0042-Add-SMI-NAND-driver.patch |   4 +-
>  ...3-lirc-added-support-for-RaspberryPi-GPIO.patch |   4 +-
>  .../patches-4.4/0044-Add-cpufreq-driver.patch  |   4 +-
>  ...-thermal-driver-for-reporting-core-temper.patch |   4 +-
>  .../0046-Add-Chris-Boot-s-i2c-driver.patch |   4 +-
>  .../0047-char-broadcom-Add-vcio-module.patch   |   4 +-
>  ...048-firmware-bcm2835-Support-ARCH_BCM270x.patch |   4 +-
>  .../0049-bcm2835-add-v4l2-camera-device.patch  |   4 +-
>  ...-mkknlimg-and-knlinfo-scripts-from-tools-.patch |   4 +-
>  ...port-for-the-CONFIG_CMDLINE_EXTEND-option.patch |   4 +-
>  ...0052-BCM2708-Add-core-Device-Tree-support.patch |   4 +-
>  ...3-bcm2835-Match-with-BCM2708-Device-Trees.patch |   4 +-
>  .../0054-fbdev-add-FBIOCOPYAREA-ioctl.patch|   4 +-
>  ...up-console-framebuffer-imageblit-function.patch |   4 +-
>  ...9-Allow-mac-address-to-be-set-in-smsc95xx.patch |   4 +-
>  ...e-realtime-clock-1-wire-chip-DS1307-and-1.patch |   4 +-
>  ...061-Added-Device-IDs-for-August-DVB-T-205

Re: [OpenWrt-Devel] [RFD] Future

[Florian Fainelli]

On 06/29/2016 01:31 PM, Hauke Mehrtens wrote:
> On 06/29/2016 04:55 PM, Imre Kaloz wrote:
>> All,
>>
>> There was an opportunity for a mini-meetup between Felix, Luka and
>> myself in Paris. We openly discussed the recent events. We've concluded
>> that it would be beneficial to members of both OpenWrt and LEDE to have
>> a face to face meeting in the near future.
>>
>> On that note, we would like to ask all project members to consider this
>> invitation as a way to move forward and resolve our issues.
> 
> I am against a Face-2-Face meeting. I think not everybody can travel to
> some other country for some 100$ on a short notice. For people that do
> OpenWrt/LEDE for a living and have their own company or get support form
> a company this is probably not problem, but some people have other jobs
> beside OpenWrt/LEDE and have to take some days off and then pay the
> money for traveling. The purpose of LEDE was to focus more on the community.
> 
> I am for a telephone conference like google hangout or this fuze meeting
> prpl uses, to make it easy for everybody to participate.

Pretty much on the same boat as you here, and on the west coast of the
US, so not very easy to travel in a short notice. If you actually meet
F2F and have the ability to make people join via Audio or Video that
would be terrific.

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

[OpenWrt-Devel] [PATCH ubus] cmake: Fix find_library for ubusd and examples/server

[Florian Fainelli]

Both ubusd and cli TARGET_LINK_LIBRARIES reference ${json} which is
obtained via find_library(), but since the find_library() is searched
after the TARGET_LINK_LIBRARIES for ubusd, ubusd always gets an empty
${json} variable.

examples/server also links against libjson-c, but we were not setting
TARGET_LINK_LIBRARIES accordingly, so do that too with ${json} appended.

This was causing linking errors for ubusd and then examples/server using
an external toolchain (stbgcc-4.8-1.x).

Fixes: 9f52d1769b762 ("cli: use the new json-c library name")
Signed-off-by: Florian Fainelli 
---
 CMakeLists.txt  | 3 ++-
 examples/CMakeLists.txt | 2 +-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 70a0de6536d9..7123096a0f93 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -32,10 +32,11 @@ INCLUDE_DIRECTORIES(${ubox_include_dir})
 ADD_LIBRARY(ubus SHARED libubus.c libubus-io.c libubus-obj.c libubus-sub.c 
libubus-req.c libubus-acl.c)
 TARGET_LINK_LIBRARIES(ubus ${ubox_library})
 
+find_library(json NAMES json-c json)
+
 ADD_EXECUTABLE(ubusd ubusd.c ubusd_id.c ubusd_obj.c ubusd_proto.c 
ubusd_event.c ubusd_acl.c ubusd_monitor.c)
 TARGET_LINK_LIBRARIES(ubusd ${ubox_library} ${blob_library} ${json})
 
-find_library(json NAMES json-c json)
 ADD_EXECUTABLE(cli cli.c)
 SET_TARGET_PROPERTIES(cli PROPERTIES OUTPUT_NAME ubus)
 TARGET_LINK_LIBRARIES(cli ubus ${ubox_library} ${blob_library} ${json})
diff --git a/examples/CMakeLists.txt b/examples/CMakeLists.txt
index 006dac42a27c..81f999752950 100644
--- a/examples/CMakeLists.txt
+++ b/examples/CMakeLists.txt
@@ -5,7 +5,7 @@ INCLUDE_DIRECTORIES(${CMAKE_CURRENT_SOURCE_DIR}/..)
 
 IF (BUILD_EXAMPLES)
ADD_EXECUTABLE(server server.c count.c)
-   TARGET_LINK_LIBRARIES(server ubus ${ubox_library} ${blob_library})
+   TARGET_LINK_LIBRARIES(server ubus ${ubox_library} ${blob_library} 
${json})
 
ADD_EXECUTABLE(client client.c count.c)
TARGET_LINK_LIBRARIES(client ubus ${ubox_library})
-- 
2.7.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Add ARC platforms to platforms wiki

[Florian Fainelli]

On 07/21/2016 10:45 AM, Alexey Brodkin wrote:
> Hello,
> 
> I'm wondering if there's a chance to add information about ARC
> platforms in the Wiki here https://dev.openwrt.org/wiki/platforms?

Done

> 
> I think something like this will work
> ==
> Target name   Platform   Architecture Endianness  
> Developer(s)Known
> Issues/Notes
> --
> arc770  Synopsys DesignWare ARC 770D   ARC  little
>   abrodkinarc770
> archs38 Synopsys DesignWare ARC HS38   ARC  little
>   abrodkinarchs38
> ==
> 
> Regards,
> Alexey
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> 


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

[OpenWrt-Devel] [PATCH firewall3] utils.h: Avoid name clashes for setbit/delbit/hasbit

[Florian Fainelli]

Rename to fw3_{set,del,has}bit to avoid name clashes with sys/param.h:

/opt/toolchains/stbgcc-4.8-1.5/arm-linux-gnueabihf/sys-root/usr/include/sys/param.h:80:0:
 note: this is the location of the previous definition
 #define setbit(a,i) ((a)[(i)/NBBY] |= 1<<((i)%NBBY))

Signed-off-by: Florian Fainelli 
---
 defaults.c |  2 +-
 forwards.c |  4 ++--
 iptables.c |  8 
 options.c  |  8 
 rules.c|  8 
 utils.h| 12 ++--
 zones.c| 26 +-
 7 files changed, 34 insertions(+), 34 deletions(-)

diff --git a/defaults.c b/defaults.c
index 2dbbb633e2e4..8afbf9acf832 100644
--- a/defaults.c
+++ b/defaults.c
@@ -154,7 +154,7 @@ fw3_print_default_chains(struct fw3_ipt_handle *handle, 
struct fw3_state *state,
continue;
 
if (c->flag &&
-   !hasbit(defs->flags[handle->family == FW3_FAMILY_V6], 
c->flag))
+   !fw3_hasbit(defs->flags[handle->family == FW3_FAMILY_V6], 
c->flag))
continue;
 
fw3_ipt_create_chain(handle, c->format);
diff --git a/forwards.c b/forwards.c
index 591173279996..6f950520fd37 100644
--- a/forwards.c
+++ b/forwards.c
@@ -86,8 +86,8 @@ fw3_load_forwards(struct fw3_state *state, struct uci_package 
*p)
/* NB: forward family... */
if (forward->_dest)
{
-   setbit(forward->_dest->flags[0], FW3_FLAG_ACCEPT);
-   setbit(forward->_dest->flags[1], FW3_FLAG_ACCEPT);
+   fw3_setbit(forward->_dest->flags[0], FW3_FLAG_ACCEPT);
+   fw3_setbit(forward->_dest->flags[1], FW3_FLAG_ACCEPT);
 
if (forward->_src &&
(forward->_src->conntrack || 
forward->_dest->conntrack))
diff --git a/iptables.c b/iptables.c
index 96fba12f0e90..e54ea53f2c39 100644
--- a/iptables.c
+++ b/iptables.c
@@ -1030,7 +1030,7 @@ fw3_ipt_rule_time(struct fw3_ipt_rule *r, struct fw3_time 
*time)
{
for (i = 1, p = buf; i < 32; i++)
{
-   if (hasbit(time->monthdays, i))
+   if (fw3_hasbit(time->monthdays, i))
{
if (p > buf)
*p++ = ',';
@@ -1039,14 +1039,14 @@ fw3_ipt_rule_time(struct fw3_ipt_rule *r, struct 
fw3_time *time)
}
}
 
-   fw3_ipt_rule_addarg(r, hasbit(time->monthdays, 0), 
"--monthdays", buf);
+   fw3_ipt_rule_addarg(r, fw3_hasbit(time->monthdays, 0), 
"--monthdays", buf);
}
 
if (time->weekdays & 0xFE)
{
for (i = 1, p = buf; i < 8; i++)
{
-   if (hasbit(time->weekdays, i))
+   if (fw3_hasbit(time->weekdays, i))
{
if (p > buf)
*p++ = ',';
@@ -1055,7 +1055,7 @@ fw3_ipt_rule_time(struct fw3_ipt_rule *r, struct fw3_time 
*time)
}
}
 
-   fw3_ipt_rule_addarg(r, hasbit(time->weekdays, 0), "--weekdays", 
buf);
+   fw3_ipt_rule_addarg(r, fw3_hasbit(time->weekdays, 0), 
"--weekdays", buf);
}
 }
 
diff --git a/options.c b/options.c
index 407931b4c490..d88d3ba09b50 100644
--- a/options.c
+++ b/options.c
@@ -718,7 +718,7 @@ fw3_parse_weekdays(void *ptr, const char *val, bool is_list)
 
if (*val == '!')
{
-   setbit(*(uint8_t *)ptr, 0);
+   fw3_setbit(*(uint8_t *)ptr, 0);
while (isspace(*++val));
}
 
@@ -738,7 +738,7 @@ fw3_parse_weekdays(void *ptr, const char *val, bool is_list)
}
}
 
-   setbit(*(uint8_t *)ptr, w);
+   fw3_setbit(*(uint8_t *)ptr, w);
}
 
free(s);
@@ -753,7 +753,7 @@ fw3_parse_monthdays(void *ptr, const char *val, bool 
is_list)
 
if (*val == '!')
{
-   setbit(*(uint32_t *)ptr, 0);
+   fw3_setbit(*(uint32_t *)ptr, 0);
while (isspace(*++val));
}
 
@@ -770,7 +770,7 @@ fw3_parse_monthdays(void *ptr, const char *val, bool 
is_list)
return false;
}
 
-   setbit(*(uint32_t *)ptr, d);
+   fw3_setbit(*(uint32_t *)ptr, d);
}
 
free(s);
diff --git a/rules.c b/rules.c
index 2c682b1b0b7e..8f232d3e0644 100644
--- a/rules.c
+++ b/rules.c
@@ -247,13 +247,13 @@ fw3_load_rules(struct fw3_state *state, struct 
uci_package *p,
/* NB: rule family... */
if (rule->_dest)

[OpenWrt-Devel] gen_initramfs_list.sh escaping problem or stale dependency file?

[Florian Fainelli]

Hi,

I have a root filesystem embedding filenames that look like these:

/lib/data/:

these are essentially files that can be matched against an USB
vendor/product id in an easy way.

Now, the fun part is that this is only a problem when doing the
following (using OpenWrt/LEDE as a build system):

1:
- set CONFIG_INITRAMFS_SOURCE=""
- build kernel modules
- build my user-space tools
- build the kernel image
- reconfigure the kernel to now use an initramfs
- build the kernel w/ initramfs

and then back to step 1 with the kernel build, would I hit this error:

usr/Makefile:64: *** multiple target patterns.  Stop.

which comes from usr/.initramfs_data.cpio.d containing these files
without escaping:

deps_initramfs := ./scripts/gen_initramfs_list.sh \
/exp00/fainelli/openwrt/trunk/build_dir/target-arm-linux-gnueabihf/root-brcmstb
\
/exp00/fainelli/openwrt/trunk/build_dir/target-arm-linux-gnueabihf/root-brcmstb/lib
\
...

/exp00/fainelli/openwrt/trunk/build_dir/target-arm-linux-gnueabihf/root-brcmstb/lib/network/wwan
\
/exp00/fainelli/openwrt/trunk/build_dir/target-arm-linux-gnueabihf/root-brcmstb/lib/network/wwan/19d2:0063
\

Which sorts of make sense here because the file name contains a ":"
which is not escaped, so GNU Make tries to interpret it.

Now the part that does not quite make sense to me is why this file is
even relevant here considering that the first thing we do is set
CONFIG_INITRAMFS_SOURCE="" to disable the initramfs basically.

Any clues what could be wrong here? I am happy to provide any build
drops you may need to reproduce that.

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

Re: [OpenWrt-Devel] [PATCH] bmips: add new target

[Florian Fainelli]

On 09/10/15 13:29, Álvaro Fernández Rojas wrote:
> Signed-off-by: Álvaro Fernández Rojas 

Nice, a commit message telling what this is about would have been
welcome, especially with the diffstat below which is pretty gigantic.

Could you make sure that all patches that are not upstream yet get
submitted to their respective maintainers?

Finally, which devices has this been tested with?

We can talk about that patchset off list.
--
Florian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 3/5] brcm63xx: lzma-loader: add BCM3380 support

[Florian Fainelli]

On 09/10/15 13:29, Álvaro Fernández Rojas wrote:
> Signed-off-by: Álvaro Fernández Rojas 

That is a first step, but there are additional kernel changes required
to boot on 3380, are you also going to submit these?

> ---
>  target/linux/brcm63xx/image/lzma-loader/src/board.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/target/linux/brcm63xx/image/lzma-loader/src/board.c 
> b/target/linux/brcm63xx/image/lzma-loader/src/board.c
> index 46af525..28b9c53 100644
> --- a/target/linux/brcm63xx/image/lzma-loader/src/board.c
> +++ b/target/linux/brcm63xx/image/lzma-loader/src/board.c
> @@ -70,6 +70,8 @@ void board_init(void)
>   case PRID_IMP_BMIPS43XX:
>   if ((prid & 0xff) == 0x04)
>   chipid_reg = 0xfff8c000;
> + else if ((prid & 0xff) == 0x70)
> + chipid_reg = 0xb4e0;
>   else if ((prid & 0xff) >= 0x30)
>   chipid_reg = 0xb000;
>   else
> @@ -95,6 +97,9 @@ void board_init(void)
>   case 0x6326:
>   uart_base = chipid_reg + 0x180;
>   break;
> + case 0x3380:
> + uart_base = chipid_reg + 0x200;
> + break;
>   case 0x6338:
>   case 0x6345:
>   case 0x6348:
> 
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 4/5] brcm63xx: fix Netgear CVG834G HCS magic bytes

[Florian Fainelli]

On 09/10/15 13:29, Álvaro Fernández Rojas wrote:
> Signed-off-by: Álvaro Fernández Rojas 

Acked-by: Florian Fainelli 

> ---
>  target/linux/brcm63xx/image/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>  mode change 100755 => 100644 target/linux/brcm63xx/image/Makefile
> 
> diff --git a/target/linux/brcm63xx/image/Makefile 
> b/target/linux/brcm63xx/image/Makefile
> old mode 100755
> new mode 100644
> index 9d3ec9f..9581116
> --- a/target/linux/brcm63xx/image/Makefile
> +++ b/target/linux/brcm63xx/image/Makefile
> @@ -581,7 +581,7 @@ $(eval $(call 
> bcm63xxCfeRamdisk,VG50,vg50,vg50,VW6339GU,63268))
>  # Inventel Livebox 1
>  $(eval $(call bcm63xxRedBoot,Livebox,livebox,livebox-blue-5g))
>  # Netgear CVG834G
> -$(eval $(call bcm33xxHcsRamdisk,CVG834G,cvg834g,cvg834g,a020,0001,0022))
> +$(eval $(call bcm33xxHcsRamdisk,CVG834G,cvg834g,cvg834g,0xa020,0001,0022))
>  # Netgear DG834GT/PN
>  $(eval $(call bcm63xxCfe,DG834GTPN,DG834GT_PN,dg834gtpn,96348GW-10,6348))
>  # Netgear DG834G v4
> 
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 1/5] brcm63xx: fix BCM3368 external interrupts

[Florian Fainelli]

On 09/10/15 13:29, Álvaro Fernández Rojas wrote:
> Signed-off-by: Álvaro Fernández Rojas 

Acked-by: Florian Fainelli 

This matches arch/mips/include/asm/mach-bcm63xx/bcm63xx_cpu.h

> ---
>  target/linux/brcm63xx/dts/bcm3368.dtsi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/target/linux/brcm63xx/dts/bcm3368.dtsi 
> b/target/linux/brcm63xx/dts/bcm3368.dtsi
> index f3b0b02..5be5c6a 100644
> --- a/target/linux/brcm63xx/dts/bcm3368.dtsi
> +++ b/target/linux/brcm63xx/dts/bcm3368.dtsi
> @@ -71,7 +71,7 @@
>   #interrupt-cells = <2>;
>  
>   interrupt-parent = <&periph_intc>;
> - interrupts = <24>, <25>, <26>, <27>;
> + interrupts = <25>, <26>, <27>, <28>;
>   };
>  
>   gpio1: gpio-controller@fff8c080 {
> 
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 2/5] brcm63xx: lzma-loader: add BCM3368 support

[Florian Fainelli]

On 09/10/15 13:29, Álvaro Fernández Rojas wrote:
> Signed-off-by: Álvaro Fernández Rojas 

Acked-by: Florian Fainelli 

> ---
>  target/linux/brcm63xx/image/lzma-loader/src/board.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/target/linux/brcm63xx/image/lzma-loader/src/board.c 
> b/target/linux/brcm63xx/image/lzma-loader/src/board.c
> index 1c715e3..46af525 100644
> --- a/target/linux/brcm63xx/image/lzma-loader/src/board.c
> +++ b/target/linux/brcm63xx/image/lzma-loader/src/board.c
> @@ -68,7 +68,9 @@ void board_init(void)
>   chipid_reg = 0xfffe;
>   break;
>   case PRID_IMP_BMIPS43XX:
> - if ((prid & 0xff) >= 0x30)
> + if ((prid & 0xff) == 0x04)
> + chipid_reg = 0xfff8c000;
> + else if ((prid & 0xff) >= 0x30)
>   chipid_reg = 0xb000;
>   else
>   chipid_reg = 0xfffe;
> @@ -80,6 +82,7 @@ void board_init(void)
>   chipid = READREG(chipid_reg);
>  
>   switch (chipid >> 16) {
> + case 0x3368:
>   case 0x6318:
>   case 0x6328:
>   case 0x6358:
> 
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Florian Fainelli]

2015-10-10 10:45 GMT-07:00 nemesis :
> On Sat, 10 Oct 2015 00:41:24 +0300, Roman Yeryomin 
> wrote:
>>
>> On 9 October 2015 at 21:22, Jo-Philipp Wich  wrote:
>>>
>>> Hi.
>>>
 Moving to Git seemed to have lots of traction at the summit, and I'll
 add my voice that this sounds like a step in the right direction for
 OpenWrt.  I'm assuming that we would want to do a proper SVN to Git
 conversion, and Eric's help on this would be great, I think.  My
 discussion with Eric is over on Google+ and marked public:
 https://plus.google.com/+JonathanBennett87/posts/bMPMjn7ZcJS
>>>
>>>
>>> Why does the core system need to migrate from svn to git?
>>>
>>
>> I thought everybody is using git anyway already. Are there people
>> still using svn?
>
>
> doing something because everybody is doing so is not the best argument IMHO.
>
> I would say that using git would improve quite a few things:
>
> * it would be easier to send upstream patches

I do not think it would make anything easier on that front, unless we
start putting existing git-managed projects as submodules of the
top-level openwrt.git repository, this could become fairly cumbersome
to maintain.

> * having a good git web interface like gitlab or github would allow
> newcomers to participate more easily

Fair enough, but then again, considering OpenWrt's development model,
the mailing-list should be good enough to get a grasp at what changes
are submitted/reviewed/commented on, no?

> * it would make life easier to the core contributors that prefer to work
> with git because git allows a very powerful development workflow compared to
> SVN

git-svn is kind of the best of both worlds right now.

There is a big problem with git, which is identifying what OpenWrt
release your image is based off. With subversion, it is fairly easy,
you have a revision number that keeps incrementing. With git, asking
people to give you their git-describe output might be a little harder.
On the plus side, we would know if someone had tampered with the
sources (-dirty), but we would not be able to track down changes
easily if someone just created branches and added patches there, since
these would be objects and references that are not accessible.
--
Florian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Florian Fainelli]

2015-10-11 14:16 GMT-07:00 Attila Lendvai :
>> Just my 2-cents
>>
>> IF it isn't BROKENplease DON'T fix it.
>
>
> the question here is: how much time coders (maintainers, contributors,
> and users) would spare if the administration was shifted to a
> different infrastructure.
>
> i cannot grow to like git (i still prefer darcs), but github simply
> provides so many extra goodies around git, and with such a smooth
> learning curve, that i think it's very much worth taking that road.
>
> i think it'd also be worth having a separate kernel fork (repo) as
> a git submodule under the openwrt git repo. it could have branches for
> the corresponding openwrt branches, and with its separate commit
> history it would make comparison with the mainline kernel way much
> simpler than it is today.

One of the complaints OpenWrt receives a lot (aside from pushing the
actual kernel changes upstream) is that the patches are a combination
of patches applied to the kernel, and files being directly copied into
the Linux sources as-is. Although this model is not ideal for some
people, it still provides some maintenance benefit since there is only
one set of files to target multiple Linux versions.

If we are to move to an OpenWrt branch of the Linux kernel, which is
per-version of Linux (e.g: v4.1-openwrt), this creates a maintenance
difficulty for these shared files/drivers (across multiple Linux
versions), because each Linux kernel branch needs to be updated.

Are we going to expect e.g: v4.1-openwrt git history never to be
rewritten when changes to existing patches are made (look at the
Raspberry Pi kernels, this is awful)? How can we guarantee that the
same fix is easily applied throughout multiple branches? Do we also
want to start maintaining per-platform branches built on top of
v4.1-openwrt, e.g: v4.1-openwrt-ar71xx etc.?

The idealistic answer would of course be: well, get your damn Linux
changes upstream, bite the bullet now, but in few releases, you will
get most of your patches and platforms supported, so this will just be
ancient history. We all know this is not happening overnight, and
working with the upstream Linux community can be challenging for
different reasons so we still need something that is able to cope with
the fast paced embedded market with 10+ new devices everyday with just
one tiny GPIO variation, without rocking the entire way existing
platforms are supported.

>
> potentially the same for some other projects as well, e.g. the
> toolchain repos?

Yes potentially, but then, this is a shortcut we can take just because
we are natively using git, and not another SCM, and git submodules are
possible. It could become a support/maintenance nightmare if everybody
wants to start using custom snapshots all over the place.

>
>
>> Regarding downstream forks, would using Git also make it easier for
>> people like project turris to push appropriate changes back into
>> OpenWrt proper?
>
>
> git checkout -b fixing-this-and-that
> gitk [and cherrypick or tailor the branch with the gui as needed]
> git push
> go to github.com and create a pull request
>
> the whole process can be shorter than 5 minutes, and after that anyone
> can go and browse it among the open pull requests.

We are talking about something slightly different here, because
OpenWrt would switch to git does not mean that it needs to completely
moves away from being self-hosted, and moved to github. I understand
and value the benefits of github and its tools, and tend not to think
that self-hosting makes much sense these days, but others may see
things differently.
--
Florian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 4/5] malta: convert to router type target.

[Florian Fainelli]

On Oct 28, 2015 5:56 AM, "Yousong Zhou"  wrote:
>
> There is currently no relevant definition for developerboard device type
> in include/target.mk, thus packages like iptables, firewall, dnsmasq
> etc. are missing in the default images, rendering it almost useless
> for regular testing or normal use.

This is by design as well here, Malta being used mostly for kernel,
toolchain and user space development, but not being an ideal router
platform.

AFAIR, the default device type is already router, so you could just
eliminate that.

>
> Signed-off-by: Yousong Zhou 
> ---
>  target/linux/malta/Makefile |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/target/linux/malta/Makefile b/target/linux/malta/Makefile
> index c9f1586..0cce15e 100644
> --- a/target/linux/malta/Makefile
> +++ b/target/linux/malta/Makefile
> @@ -15,7 +15,7 @@ MAINTAINER:=Florian Fainelli 
>
>  KERNEL_PATCHVER:=3.18
>
> -DEVICE_TYPE:=developerboard
> +DEVICE_TYPE:=router
>
>  include $(INCLUDE_DIR)/target.mk
>
> --
> 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] [PATCH 5/5] malta: use "static" proto for lan interface

[Florian Fainelli]

On Oct 28, 2015 5:56 AM, "Yousong Zhou"  wrote:
>
> This is almost the default config of OpenWrt targets (currently even
> those sunxi boards with only one ethernet interface use static IP
> address for its lan interface).

And this is intend intended, because Malta is primarily used under qemu,
from which you get your network to be NAT'd or bridged from/with the host.
Your change would force an user to reconfigure the network on boot, and
that seems like a less sensible default to me.

>
> While at it, also configure a wan interface if eth1 exists.
>
> Signed-off-by: Yousong Zhou 
> ---
>  target/linux/malta/base-files/etc/uci-defaults/02-network |5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/target/linux/malta/base-files/etc/uci-defaults/02-network
b/target/linux/malta/base-files/etc/uci-defaults/02-network
> index e90ecbe..1b22ec5 100644
> --- a/target/linux/malta/base-files/etc/uci-defaults/02-network
> +++ b/target/linux/malta/base-files/etc/uci-defaults/02-network
> @@ -3,4 +3,7 @@
>  . /lib/functions/uci-defaults.sh
>
>  ucidef_set_interface_loopback
> -ucidef_set_interface_raw "lan" "eth0" "dhcp"
> +ucidef_set_interface_lan "eth0"
> +if [ -d "/sys/class/net/eth1" ]; then
> +   ucidef_set_interface_wan "eth1"
> +fi
> --
> 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] [PATCH 5/5] malta: use "static" proto for lan interface

[Florian Fainelli]

Le 28/10/2015 19:32, Yousong Zhou a écrit :
> On 29 October 2015 at 00:19, Florian Fainelli  wrote:
>> On Oct 28, 2015 5:56 AM, "Yousong Zhou"  wrote:
>>>
>>> This is almost the default config of OpenWrt targets (currently even
>>> those sunxi boards with only one ethernet interface use static IP
>>> address for its lan interface).
>>
>> And this is intend intended, because Malta is primarily used under qemu,
>> from which you get your network to be NAT'd or bridged from/with the host.
>> Your change would force an user to reconfigure the network on boot, and that
>> seems like a less sensible default to me.
>>
> 
> The current default is not that sensible anyway.  If I understand it
> correctly, many packages in OpenWrt assume that lan is for the
> "internal" part of the network map, e.g. by default, dnsmasq will
> serve DHCP requests on lan interface, firewall will also allow
> forwarding on lan interface.  A workaround can be making eth0 the
> default wan interface.

But then again, by making eth0 the default wan interface, this is
enforcing a specific model of the networking, and with QEMU this is a
lot more flexible than that.

Since there does not see to be a good answer, then let's go with your
changes and I will do my local changes if I am unhappy with these...
--
Florian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v2 0/5] malta: changes for a better testing environment

[Florian Fainelli]

Le 30/10/2015 20:05, Yousong Zhou a écrit :
> The series is a refreshed version of a previous mixed one in September [1].
> 
> With many kind advices from linux-mips, the kernel patch was merged in 
> upstream
> since release 4.3-rc5.  It was run-tested with 3.18 kernel and only
> compile-tested with 4.0 and 4.1.

They have already been applied, but FWIW:

Reviewed-by: Florian Fainelli 

Thanks

> 
> [1] 
> https://lists.openwrt.org/pipermail/openwrt-devel/2015-September/thread.html#35515
> 
> v2 <- v1
> 
>   - Instead of setting the device type explicitly to router, just drop the
> definition and use the default
>   - Make eth0 the default ifname for wan interface and eth1 if exists the 
> lan
> interface
> 
> Yousong Zhou (5):
>   generic: fix unrecognized opcode wsbh when building for MIPS16.
>   target.mk: add optimization flags for MIPS 24Kc.
>   malta: set CPU_TYPE:=24kc.
>   malta: use as a default type device
>   malta: make eth0 the wan interface by default
> 
>  include/target.mk  |1 +
>  ...gnore-__arch_swab-16-32-64-when-using-MIP.patch |   58 
> 
>  ...gnore-__arch_swab-16-32-64-when-using-MIP.patch |   58 
> 
>  ...gnore-__arch_swab-16-32-64-when-using-MIP.patch |   58 
> 
>  target/linux/malta/Makefile|3 +-
>  .../malta/base-files/etc/uci-defaults/02-network   |5 +-
>  6 files changed, 180 insertions(+), 3 deletions(-)
>  create mode 100644 
> target/linux/generic/patches-3.18/133-MIPS-UAPI-Ignore-__arch_swab-16-32-64-when-using-MIP.patch
>  create mode 100644 
> target/linux/generic/patches-4.0/133-MIPS-UAPI-Ignore-__arch_swab-16-32-64-when-using-MIP.patch
>  create mode 100644 
> target/linux/generic/patches-4.1/133-MIPS-UAPI-Ignore-__arch_swab-16-32-64-when-using-MIP.patch
> 
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] update config.guess & config.sub

[Florian Fainelli]

On 02/11/15 11:01, Kathy Giori wrote:
> On Mon, Nov 2, 2015 at 9:40 AM, Alexey Brodkin
>  wrote:
>> Hi Felix,
>>
>> On Thu, 2015-07-30 at 11:43 +0300, Alexey Brodkin wrote:
>>> These are from today's master branch of:
>>> http://git.savannah.gnu.org/gitweb/?p=config.git;a=tree
>>>
>>> In particular it adds support for ARC architecture plus some more
>>> improvements and fixes.
>>>
>>> This patch is built-tested against NetGear WNDR3800.
>>>
>>> Signed-off-by: Alexey Brodkin 
>>> Cc: Florian Fainelli 
>>> Cc: Imre Kaloz 
>>> ---
>>>  scripts/config.guess | 378 
>>> +++
>>>  scripts/config.sub   | 150 
>>>  2 files changed, 238 insertions(+), 290 deletions(-)
>>
>> I'm wondering if there're any comments on this one.
>> Otherwise please consider applying.
>>
>> This patch is a prerequisite for ARC port submission I'm going to send out
>> shortly.
> 
> Alexey,
> 
> Is there a particular reason that this architecture must be submitted
> to OpenWrt under the terms GPL v3+? I would prefer that OpenWrt stick
> to GPL v2 in order to maintain better compatibility with the Linux
> kernel (kernel.org). The kernel is primarily GPL v2 licensed (or
> something FreeBSD-like which is more, not less, permissive). The
> OpenWrt distro has only a few GPL v3 package exceptions, such as
> samba.

This is a quick jump to invalid conclusions, the changes that Alexey is
submitting are to files under scripts/* which are only used during the
build process in this case, and there are no GPLv3 components being
included in the firmware image per-se.

These specific files are used by autotools and friends to detect the
architecture/machine we cross-compile for, and as such as a prerequisite
for supporting an ARC toolchain.

As such, the changes are completely fine, and have no bearing to the
resulting firmware image.

> 
> The OpenWrt core team are doing a good job building a better
> industry-community relationship for OpenWrt, which I think can be a
> win-win for overall project improvement (brings in more developer
> resources, much like kernel development depends on industry
> developers). Introducing more GPL v3 packages makes it problematic for
> certain industry partners to be able to fully collaborate.

Although I do share the same feeling, I think the justification is way
off, GPLv3 does not prevent anybody from contributing, it may just hurt
your distribution model, which is something entirely different.
--
Florian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 0/7] kirkwood: revamp Linksys EA3500 & EA4500 support

[Florian Fainelli]

Le 06/11/2015 18:29, Claudio Leite a écrit :
> This patch set reworks support for the Linksys EA3500 and EA4500,
> integrating significant amounts of code from the WRT1900AC port.
> 
> Previously these two routers were supported by flashing from the
> bootloader and setting new boot commands. They can now be flashed
> from the Linksys factory firmware and upgraded from within OpenWrt.
> This also adds support for the Linksys dual-image firmware layout
> and recovery mechanism.

Tested on a freshly purchased Linksys EA4500 and this worked like a
charm, really happy to see that!

Tested-by: Florian Fainelli 

> 
> These patches also transition from a single read-write UBIFS to
> squashfs on UBI + UBIFS overlay.
> 
> Claudio Leite (7):
>   kirkwood: enable squashfs-on-ubiblock support
>   kirkwood: match factory partitions on EA[34]500
>   kirkwood: find active Linksys root partition
>   kirkwood: generate factory images for Linksys EA[34]500
>   kirkwood: support Linksys boot counter on EA[34]500
>   kirkwood: support sysupgrade on Linksys EA[34]500
>   kirkwood: add diag LED on Linksys EA3500
> 
>  package/boot/uboot-envtools/files/kirkwood |  2 +-
>  package/system/mtd/src/Makefile|  1 +
>  target/linux/kirkwood/Makefile |  2 +-
>  target/linux/kirkwood/base-files/etc/diag.sh   |  3 +
>  .../base-files/etc/init.d/linksys_recovery | 20 ++
>  .../kirkwood/base-files/lib/upgrade/linksys.sh | 79 
> ++
>  .../kirkwood/base-files/lib/upgrade/platform.sh| 32 +
>  target/linux/kirkwood/config-3.18  |  3 +-
>  target/linux/kirkwood/config-4.3   |  3 +-
>  target/linux/kirkwood/image/Makefile   | 45 ++--
>  .../patches-3.18/100-find_active_root.patch| 61 +
>  .../linux/kirkwood/patches-3.18/160-ea4500.patch   | 36 +++---
>  .../linux/kirkwood/patches-3.18/170-ea3500.patch   | 39 ---
>  .../patches-4.3/100-find_active_root.patch | 61 +
>  target/linux/kirkwood/patches-4.3/140-ea4500.patch | 36 +++---
>  target/linux/kirkwood/patches-4.3/150-ea3500.patch | 39 ---
>  16 files changed, 416 insertions(+), 46 deletions(-)
>  create mode 100755 
> target/linux/kirkwood/base-files/etc/init.d/linksys_recovery
>  create mode 100644 target/linux/kirkwood/base-files/lib/upgrade/linksys.sh
>  create mode 100644 target/linux/kirkwood/base-files/lib/upgrade/platform.sh
>  create mode 100644 
> target/linux/kirkwood/patches-3.18/100-find_active_root.patch
>  create mode 100644 
> target/linux/kirkwood/patches-4.3/100-find_active_root.patch
> 
___
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] swconfig: add SWITCH_TYPE_LINK and support sending link info to user space

[Florian Fainelli]

Le 16 déc. 2015 09:19, "Rafał Miłecki"  a écrit :
>
> So far we were sending link data as a string. It got some drawbacks:
> 1) Didn't allow writing clean user space apps reading link state. It was
>needed to do some screen scraping.
> 2) Forced whole PORT_LINK communication to be string based. Adding
>support for *setting* port link required passing string and parting
>it in the kernel space.
>
> Signed-off-by: Rafał Miłecki 
> ---

[snip]

(struct sk_buff *msg, struct genl_info *info, int attr,
> +  const struct switch_port_link *link)
> +{
> +   struct nlattr *p = NULL;
> +   int err = 0;
> +
> +   p = nla_nest_start(msg, attr);
> +   if (nla_put_u32(msg, SWITCH_LINK_LINK, link->link))

Boolean?

> +   goto nla_put_failure;
> +   if (nla_put_u32(msg, SWITCH_LINK_DUPLEX, link->duplex))

Same here

> +   goto nla_put_failure;
> +   if (nla_put_u32(msg, SWITCH_LINK_ANEG, link->aneg))

And here

> +   goto nla_put_failure;
> +   if (nla_put_u32(msg, SWITCH_LINK_TX_FLOW, link->tx_flow))

And here

> +   goto nla_put_failure;
> +   if (nla_put_u32(msg, SWITCH_LINK_RX_FLOW, link->rx_flow))

And here too

> +   goto nla_put_failure;
> +   if (nla_put_u32(msg, SWITCH_LINK_SPEED, link->speed))
> +   goto nla_put_failure;
> +   if (link->eee & ADVERTISED_100baseT_Full) {
> +   if (nla_put_flag(msg,
SWITCH_LINK_FLAG_ADVERTISED_100BASET_FULL))
> +   goto nla_put_failure;
> +   }
> +   if (link->eee & ADVERTISED_1000baseT_Full) {
> +   if (nla_put_flag(msg,
SWITCH_LINK_FLAG_ADVERTISED_1000BASET_FULL))
> +   goto nla_put_failure;
> +   }

As mentioned by Stefan, these should reflect that is is EEE-related.
--
Florian
___
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] swconfig: support receiving SWITCH_TYPE_LINK from kernel

[Florian Fainelli]

Le 16 déc. 2015 09:21, "Rafał Miłecki"  a écrit :
>
> When using cli, print link state the same way kernel used to do it.
> This will allow kernel switching PORT_LINK from SWITCH_TYPE_STRING.
>
> Signed-off-by: Rafał Miłecki 
> ---
[snip]
> +   link->eee &
SWLIB_LINK_FLAG_ADVERTISED_100BASET_FULL ? "eee100 " : "",
> +   link->eee &
SWLIB_LINK_FLAG_ADVERTISED_1000BASET_FULL ? "eee1000 " : "",

EEE needs to be advertised, supported, and enabled on both link partners to
be used,what you are printing here is not very clear, as this is just the
advertised side

> +   link->aneg ? "auto" : "");
> +   else
> +   printf("port:%d link:down", val->port_vlan);
> +   break;
> default:
> printf("?unknown-type?");
> }
> diff --git a/package/network/config/swconfig/src/swlib.c
b/package/network/config/swconfig/src/swlib.c
> index 0dbace5..5239bf7 100644
> --- a/package/network/config/swconfig/src/swlib.c
> +++ b/package/network/config/swconfig/src/swlib.c
> @@ -51,6 +51,15 @@ static struct nla_policy
portmap_policy[SWITCH_PORTMAP_MAX] = {
> [SWITCH_PORTMAP_VIRT] = { .type = NLA_U32 },
>  };
>
> +static struct nla_policy link_policy[SWITCH_LINK_ATTR_MAX] = {
> +   [SWITCH_LINK_LINK] = { .type = NLA_U32 },
> +   [SWITCH_LINK_DUPLEX] = { .type = NLA_U32 },
> +   [SWITCH_LINK_ANEG] = { .type = NLA_U32 },
> +   [SWITCH_LINK_SPEED] = { .type = NLA_U32 },

As mentioned in patch 1, some of this fits in a boolean.
--
Florian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] qca8k: ipqess: ipq40xx: Kernel Panic on Adding VLAN Sub-Interface to Bridge

[Florian Fainelli]

On 3/19/19 11:14 AM, Christian Lamparter wrote:
> Cc: Florian. I hope you don't mind.
> 
> On Tuesday, March 19, 2019 5:50:01 PM CET Jeff Kletsky wrote:
>> Working with 4.19 / qca8k / ipqess patches from staging/chunkeey[1]
>> on an IPQ4019-based device, I can get basic connectivity either manually,
>> or with a "standard" UCI definition of the "lan" bridge[2].
>>
>> (I'm aware that this is not "production" code and expect "challenges".)
>>
>> However, I'm puzzled as how to manage VLANs and tagging, even using
>> `ip` and `bridge` (iproute2, from ip-bridge and ip-full packages).
>>
>> It appears that the qca8k driver doesn't support `bridge` VLAN-related
>> commands. Checking the source doesn't show implementation of the
>> `port_vlan_*` functions described in the Linux DSA doc[3].
>>
>>
>> Setting aside my suspicion that a port-based VLAN approach seems
>> unlikely to be able to handle trunking of VLANs, I tried adding a
>> sub-interface of one of the otherwise unused phy interfaces (renamed
>> in my DTS as "wan0" to not conflict with the OpenWrt OS usage of "wan").
> 
> At first glance, I think you are running into what's described in section
> "Design limitations" of DSA in [3]:"
> - inability to configure specific VLAN IDs / trunking VLANs between switches
>   when using a cascaded setup". (Sadly there isn't a link to a possible
> patch or discussion so I don't know the state of it).
> 
> However...
>  
>> This unfortunately results in a kernel panic when trying to add to the
>> bridge.
>>
>> Bridge br-lan initially set up with "default" UCI config[2]
>>
>> Full serial log available[4]
>>
>>ip link add link wan0 name wan0.100 type vlan id 100
>>ip link set wan0 up
>>ip link set wan0.100 up
>>ip link set wan0.100 master br-lan
>>(kernel panics)
>>
>>
>> I've traced this to passing of a null pointer to br_vlan_enabled()
>> with the diagnostic patch shown in [5]
> 
> Yes, this shouldn't crash. I think Florian has already a patch for this
> upstream [6].

Right, this specific commit omitted two key details which were that:

- not all drivers support port_vlan_{add,del}
- not all drivers support programming VID 0

This is fixed upstream with d6af21a4fb5fff2f6640feb011902212e658414d
("net: dsa: Use prepare/commit phase in dsa_slave_vlan_rx_add_vid()")

> 
> commit 061f6a505ac33659eab007731c0f6374df39ab55
> Author: Florian Fainelli 
> Date:   Wed Feb 20 14:35:39 2019 -0800
> 
> net: dsa: Add ndo_vlan_rx_{add, kill}_vid implementation
> 
> That should help with the NPEs since it now checks whenever the
> bridge_dev is valid or not.
>  
> [3] https://www.kernel.org/doc/Documentation/networking/dsa/dsa.txt
> [6] <https://patchwork.ozlabs.org/patch/1026172/>
> 
> 


-- 
Florian

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

Re: [OpenWrt-Devel] [PATCH] gemini: Bring up DSA switches

[Florian Fainelli]

On 7/13/2019 4:04 AM, Linus Walleij wrote:
> On Fri, Jul 12, 2019 at 8:57 AM Hauke Mehrtens  wrote:
>> On 7/12/19 8:07 AM, Linus Walleij wrote:
> 
>>> + # These are all connected to eth1 thru VSC7385
>>> + ucidef_set_interfaces_lan_wan "eth1 lan1 lan2 lan3 lan4" "eth0"
>>
>> This will create a bridge over eth1, lan1, lan2, lan3 and lan4, but I
>> think you do not have to put eth1 into this bridge, it should be
>> sufficient to have all the lanX in it.
> 
> It is really puzzling to me too :(

drivers/net/dsa/vitesse-vsc73xx.c returns DSA_TAG_PROTO_NONE for the
tagging protocol, which means that the DSA slave devices are only
control devices they are not used by the data-path (which requires an
appropriate tagging protocol to allow differentiating the Ethernet
frames on a per-port basis). If you supported a different tagging
protocol, then you would not be able to enslave the DSA master device
(eth1) into the bridge, because that would conflict with the bridge's
rx_handler, see 8db0a2ee2c6302a1dcbcdb93cb731dfc6c0cdb5e ("net: bridge:
reject DSA-enabled master netdevices as bridge members")

Your second sequence is more in line with what you should do, see the
recent documentation examples from Benedikt:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/networking/dsa/configuration.rst

> 
> What I notice is that if I do this everything works fine and if eth1
> is not included it doesn't.
> 
> This sequence also works fine:
> ifconfig eth1 169.254.1.2 netmask 255.255.255.0 up
> ifconfig lan1 up
> ifconfig lan2 up
> ifconfig lan3 up
> ifconfig lan4 up
> 
> I think the reason is that the IP address is not assigned to
> eth1 (the CPU port towards the switch/DSA).
> 
> Maybe other DSA switches are better with this? My dmesg
> looks like this with eth1 included in the lan-facing interfaces:
> 
> [   52.704396] gemini-ethernet-port 6000c000.ethernet-port eth1: link
> flow control: both
> [   53.046012] br-lan: port 1(eth1) entered blocking state
> [   53.170160] br-lan: port 1(eth1) entered disabled state
> [   53.253455] device eth1 entered promiscuous mode
> [   53.299150] IPv6: ADDRCONF(NETDEV_UP): br-lan: link is not ready
> [   53.388545] vsc73xx spi0.0: enable port 0
> [   53.446029] vsc73xx spi0.0 lan1: configuring for phy/gmii link mode
> [   53.526483] br-lan: port 2(lan1) entered blocking state
> [   53.594789] br-lan: port 2(lan1) entered disabled state
> [   53.665816] device lan1 entered promiscuous mode
> [   53.728728] br-lan: port 1(eth1) entered blocking state
> [   53.760176] br-lan: port 1(eth1) entered forwarding state
> [   53.874449] IPv6: ADDRCONF(NETDEV_CHANGE): br-lan: link becomes ready
> [   54.000353] vsc73xx spi0.0: enable port 1
> [   54.056099] vsc73xx spi0.0 lan2: configuring for phy/gmii link mode
> [   54.142223] br-lan: port 3(lan2) entered blocking state
> [   54.214679] br-lan: port 3(lan2) entered disabled state
> [   54.266496] device lan2 entered promiscuous mode
> [   54.308593] vsc73xx spi0.0: enable port 2
> [   54.335298] vsc73xx spi0.0 lan3: configuring for phy/gmii link mode
> [   54.377279] br-lan: port 4(lan3) entered blocking state
> [   54.97] br-lan: port 4(lan3) entered disabled state
> [   54.515791] device lan3 entered promiscuous mode
> [   54.588687] vsc73xx spi0.0: enable port 3
> [   54.646048] vsc73xx spi0.0 lan4: configuring for phy/gmii link mode
> [   54.726991] br-lan: port 5(lan4) entered blocking state
> [   54.785910] vsc73xx spi0.0 lan1: Link is Up - 1Gbps/Full - flow control 
> rx/tx
> [   54.844478] br-lan: port 5(lan4) entered disabled state
> [   54.915911] device lan4 entered promiscuous mode
> [   54.976533] br-lan: port 2(lan1) entered blocking state
> [   55.007954] br-lan: port 2(lan1) entered forwarding state
> 
> After this I can ping the host:
> # ping 169.254.1.1
> PING 169.254.1.1 (169.254.1.1): 56 data bytes
> 64 bytes from 169.254.1.1: seq=0 ttl=64 time=2.049 ms
> 64 bytes from 169.254.1.1: seq=6 ttl=64 time=0.913 ms
> 64 bytes from 169.254.1.1: seq=25 ttl=64 time=1.268 ms
> And the host can ping the device:
> $ ping 169.254.1.2
> PING 169.254.1.2 (169.254.1.2) 56(84) bytes of data.
> 64 bytes from 169.254.1.2: icmp_seq=1 ttl=64 time=1.12 ms
> 64 bytes from 169.254.1.2: icmp_seq=2 ttl=64 time=0.582 ms
> 64 bytes from 169.254.1.2: icmp_seq=3 ttl=64 time=0.576 ms
> 64 bytes from 169.254.1.2: icmp_seq=4 ttl=64 time=0.654 ms
> 
> But if I remove eth1 from the LAN facing interfaces it looks like
> this:
> 
> [   52.433253] gemini-ethernet-port 6000c000.ethernet-port eth1: link
> flow control: both
> [   52.769503] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
> [   52.925178] device eth1 entered promiscuous mode
> [   52.987672] vsc73xx spi0.0: enable port 0
> [   53.014460] vsc73xx spi0.0 lan1: configuring for phy/gmii link mode
> [   53.054754] br-lan: port 1(lan1) entered blocking state
> [   53.086323] br-lan: port 1(lan1) entered disabled state
> [   53.119857] device lan1 enter

Re: [OpenWrt-Devel] [PATCH 2/4 RFCv2] net: dsa: Add bindings for Realtek SMI DSAs

[Florian Fainelli]

On 05/28/2018 10:47 AM, Linus Walleij wrote:
> The Realtek SMI family is a set of DSA chips that provide
> switching in routers. This binding just follows the pattern
> set by other switches but with the introduction of an embedded
> irqchip to demux and handle the interrupts fired by the single
> line from the chip.
> 
> This interrupt construction is similar to how we handle
> interrupt controllers inside PCI bridges etc.
> 
> Cc: Antti Seppälä 
> Cc: Roman Yeryomin 
> Cc: Colin Leitner 
> Cc: Gabor Juhos 
> Cc: Florian Fainelli 
> Cc: devicet...@vger.kernel.org
> Signed-off-by: Linus Walleij 
> ---

> +
> + mdio {
> + compatible = "realtek,smi-mdio", "dsa-mdio";

You should drop the "dsa-mdio" compatible string here since it both non
documented and not matched either.

Other than that, this looks great, with that fixed:

Reviewed-by: Florian Fainelli 
-- 
Florian

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

Re: [OpenWrt-Devel] gen_initramfs_list.sh escaping problem or stale dependency file?

[Florian Fainelli]

On 09/13/2016 12:24 AM, Michal Marek wrote:
> On Mon, Sep 12, 2016 at 05:12:15PM -0700, Florian Fainelli wrote:
>> Hi,
>>
>> I have a root filesystem embedding filenames that look like these:
>>
>> /lib/data/:
>>
>> these are essentially files that can be matched against an USB
>> vendor/product id in an easy way.
>>
>> Now, the fun part is that this is only a problem when doing the
>> following (using OpenWrt/LEDE as a build system):
>>
>> 1:
>> - set CONFIG_INITRAMFS_SOURCE=""
>> - build kernel modules
>> - build my user-space tools
>> - build the kernel image
>> - reconfigure the kernel to now use an initramfs
>> - build the kernel w/ initramfs
>>
>> and then back to step 1 with the kernel build, would I hit this error:
>>
>> usr/Makefile:64: *** multiple target patterns.  Stop.
> [...]
>> Which sorts of make sense here because the file name contains a ":"
>> which is not escaped, so GNU Make tries to interpret it.
>>
>> Now the part that does not quite make sense to me is why this file is
>> even relevant here considering that the first thing we do is set
>> CONFIG_INITRAMFS_SOURCE="" to disable the initramfs basically.
> 
> It is possible that we read usr/Makefile twice for some reason. But the
> real problem is the lack of escaping. Can you try the following
> (untested) patch?

This patch works for me:

Tested-by: Florian Fainelli 

Kind of surprising that this has not showed up before, but maybe people
don't really go through the same steps while re-configuring/re-building
their kernels

Thanks Michal!

> 
> 
> diff --git a/scripts/gen_initramfs_list.sh b/scripts/gen_initramfs_list.sh
> index 17fa901418ae..5d3188e74101 100755
> --- a/scripts/gen_initramfs_list.sh
> +++ b/scripts/gen_initramfs_list.sh
> @@ -97,7 +97,10 @@ print_mtime() {
>  }
>  
>  list_parse() {
> - [ ! -L "$1" ] && echo "$1 \\" || :
> + if [ -L "$1" ]; then
> + return
> + fi
> + echo "$1" | sed 's/\([:%]\)/\\\1/g; s/$/ \\/'
>  }
>  
>  # for each file print a line in following format
> 
> Thanks,
> Michal
> 


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

Re: [OpenWrt-Devel] gen_initramfs_list.sh escaping problem or stale dependency file?

[Florian Fainelli]

On 09/13/2016 12:24 AM, Michal Marek wrote:
> On Mon, Sep 12, 2016 at 05:12:15PM -0700, Florian Fainelli wrote:
>> Hi,
>>
>> I have a root filesystem embedding filenames that look like these:
>>
>> /lib/data/:
>>
>> these are essentially files that can be matched against an USB
>> vendor/product id in an easy way.
>>
>> Now, the fun part is that this is only a problem when doing the
>> following (using OpenWrt/LEDE as a build system):
>>
>> 1:
>> - set CONFIG_INITRAMFS_SOURCE=""
>> - build kernel modules
>> - build my user-space tools
>> - build the kernel image
>> - reconfigure the kernel to now use an initramfs
>> - build the kernel w/ initramfs
>>
>> and then back to step 1 with the kernel build, would I hit this error:
>>
>> usr/Makefile:64: *** multiple target patterns.  Stop.
> [...]
>> Which sorts of make sense here because the file name contains a ":"
>> which is not escaped, so GNU Make tries to interpret it.
>>
>> Now the part that does not quite make sense to me is why this file is
>> even relevant here considering that the first thing we do is set
>> CONFIG_INITRAMFS_SOURCE="" to disable the initramfs basically.
> 
> It is possible that we read usr/Makefile twice for some reason. But the
> real problem is the lack of escaping. Can you try the following
> (untested) patch?

Can you submit an official patch for this? Thanks a lot!

> 
> 
> diff --git a/scripts/gen_initramfs_list.sh b/scripts/gen_initramfs_list.sh
> index 17fa901418ae..5d3188e74101 100755
> --- a/scripts/gen_initramfs_list.sh
> +++ b/scripts/gen_initramfs_list.sh
> @@ -97,7 +97,10 @@ print_mtime() {
>  }
>  
>  list_parse() {
> - [ ! -L "$1" ] && echo "$1 \\" || :
> + if [ -L "$1" ]; then
> + return
> + fi
> + echo "$1" | sed 's/\([:%]\)/\\\1/g; s/$/ \\/'
>  }
>  
>  # for each file print a line in following format
> 
> Thanks,
> Michal
> 


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

Re: [OpenWrt-Devel] boot-wrapper-aarch64.git repository missing/inaccessible; cannot build arm64 targets

[Florian Fainelli]

On 09/22/2016 02:38 PM, Alexander Duff wrote:
> Hello,
> 
> The quick version: a repository (boot-wrapper-aarch64.git) required for
> the default build of arm64 OpenWrt targets (default configuration) on
> the latest version of trunk seems to have disappeared from the Internet,
> and I'm unsure who to notify or how to proceed.  Furthermore, I can't
> seem to find anyone else reporting this issue or even talking about it
> and I can't understand why this isn't being reported anywhere, making me
> paranoid that I somehow messed up (which has been known to happen) or
> missed some announcement.

How about we use this copy:

https://github.com/artagnon/boot-wrapper-aarch64

or this one:

https://git.kernel.org/cgit/linux/kernel/git/mark/boot-wrapper-aarch64.git/

or even better, create a profile for the Foundation v8 simulator, for
which this boot wrapper is necessary, if you are using qemu, there is no
need for that.
-- 
Florian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] CVE-2016-5195 backport to linux-3.18.36 for Chaos Calmer

[Florian Fainelli]

On 10/21/2016 07:43 AM, revelstone wrote:
> Here is a backport for Chaos Calmer of commit
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=19be0eaffa3ac7d8eb6784ad9bdbc7d67ed8e619]19be0eaffa3ac7d8eb6784ad9bdbc7d67ed8e619
> that patches
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-5195]CVE-2016-5195
> 
> /DL
> 
> Signed-off-by: dl12345 

While this is appreciated, why not just wait for the stable tree to get
updated and update to the next stable 3.18 (and others)?
-- 
Florian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v2] mac80211: Make wlcore platform-independent

[Florian Fainelli]

On 11/10/2016 04:28 AM, Alexey Brodkin wrote:
> TI wl18xx and wl12xx are Wi-Fi/Bluetooth combo modules
> that could be found on different existing boards.
> 
> But it is possible to get those modules as a separate
> component and use with existing boards as well as
> new boards equipped with either module may appear so we
> remove dependency on OMAP instead we add dependency on MMC
> because this Wi-Fi module uses SDIO interface.
> 
> Signed-off-by: Alexey Brodkin 
> Cc: Jo-Philipp Wich 
> Cc: Felix Fietkau 
> Cc: Imre Kaloz 

Reviewed-by: Florian Fainelli 

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

Re: [OpenWrt-Devel] [LEDE-DEV] Talks between OpenWrt and LEDE

[Florian Fainelli]

On 12/21/2016 01:46 PM, Alberto Bursi wrote:
> On 12/21/2016 09:42 PM, Dave Taht wrote:
>> On Wed, Dec 21, 2016 at 12:29 PM, David Lang  wrote:
>>> On Wed, 21 Dec 2016, Kathy Giori wrote:
>>>
 From a PR perspective, I strongly suggest keeping the term OpenWrt as
 part of the branding of the project moving forward. It can just be
 cosmetic (web site, etc.) but the name has so much history, and
 positive connotation, that you don't want to lose that brand attached
 to the development moving forward.
>>>
>>>
>>> I agree, I think this is an obvious choice to make. OpenWRT has a lot of
>>> name recognition, it would be foolish to throw that away.
>>
>> Just to take the other side for rhetorical purposes, a purpose of a
>> re-branding exercise is to show a change in the "product" or
>> organisation behind it. OpenWrt is widely known... as a bleeding edge,
>> sometimes unstable, somewhat hard to use 3rd party firmware. DD-Wrt
>> and Tomato get a lot more press for some reason. So do things like
>> Yocto. If lede were to succeed in meeting its other goals, coherently,
>> preserving "lede" and moving forward as a separate project does make
>> sense.
>>
> 
> +1 for this. OpenWRT brand isn't 100% positive recognition, it has some 
> downsides too. Many people (I know and/or have seen around the internet) 
> were discouraged from contributing or using it due to the weaknesses of 
> OpenWRT project.
> 
> I like more the LEDE branding for this reason. It conveys that it is 
> significantly different, possibly for the better, from OpenWRT project.
> 
> But I don't have enough information to say for sure what is the better 
> brand to keep, so this is just my opinion.

Keeping or not the OpenWrt, or LEDE name is obviously part of the things
that need to be agreed upon before proceeding with a merger. If not
about the "brand", "recognition" or other more subjective criteria,
OpenWrt is a trademark, so that needs to be factored in for the
decision, in particular if there is any legal activity going on.
-- 
Florian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [LEDE-DEV] Talks between OpenWrt and LEDE

[Florian Fainelli]

On 12/21/2016 07:30 PM, Val Kulkov wrote:
> 
> On 21 December 2016 at 17:01, Florian Fainelli  <mailto:f.faine...@gmail.com>> wrote:
> 
> On 12/21/2016 01:46 PM, Alberto Bursi wrote:
> > On 12/21/2016 09:42 PM, Dave Taht wrote:
> >> On Wed, Dec 21, 2016 at 12:29 PM, David Lang  <mailto:da...@lang.hm>> wrote:
> >>> On Wed, 21 Dec 2016, Kathy Giori wrote:
> >>>
> >>>> From a PR perspective, I strongly suggest keeping the term
> OpenWrt as
> >>>> part of the branding of the project moving forward. It can just be
> >>>> cosmetic (web site, etc.) but the name has so much history, and
> >>>> positive connotation, that you don't want to lose that brand
> attached
> >>>> to the development moving forward.
> >>>
> >>>
> >>> I agree, I think this is an obvious choice to make. OpenWRT has
> a lot of
> >>> name recognition, it would be foolish to throw that away.
> >>
> >> Just to take the other side for rhetorical purposes, a purpose of a
> >> re-branding exercise is to show a change in the "product" or
> >> organisation behind it. OpenWrt is widely known... as a bleeding
> edge,
> >> sometimes unstable, somewhat hard to use 3rd party firmware. DD-Wrt
> >> and Tomato get a lot more press for some reason. So do things like
> >> Yocto. If lede were to succeed in meeting its other goals,
> coherently,
> >> preserving "lede" and moving forward as a separate project does make
> >> sense.
> >>
> >
> > +1 for this. OpenWRT brand isn't 100% positive recognition, it has
> some
> > downsides too. Many people (I know and/or have seen around the
> internet)
> > were discouraged from contributing or using it due to the
> weaknesses of
> > OpenWRT project.
> >
> > I like more the LEDE branding for this reason. It conveys that it is
> > significantly different, possibly for the better, from OpenWRT
> project.
> >
> > But I don't have enough information to say for sure what is the better
> > brand to keep, so this is just my opinion.
> 
> Keeping or not the OpenWrt, or LEDE name is obviously part of the things
> that need to be agreed upon before proceeding with a merger. If not
> about the "brand", "recognition" or other more subjective criteria,
> OpenWrt is a trademark, so that needs to be factored in for the
> decision, in particular if there is any legal activity going on.
> 
> 
> A trademark exists to protect its owner's rights. The "OpenWRT"
> trademark is owned by SPI:
> http://tmsearch.uspto.gov/bin/showfield?f=doc&state=4805:r3y94m.2.1
> 
> If there is no unauthorised use of a trademark, there is no legal issue.
> In other words, if the merged project continues as "LEDE", there is no
> legal issue in respect of the "OpenWRT" trademark.
> 
> SPI also has the right to oppose registration or use of a trademark that
> appears confusingly similar to "OpenWRT". This seems to be a purely
> hypothetical situation, but here it is: if OpenWRT and LEDE do not merge
> and for some reason the LEDE folks decide to rename LEDE to FreeWRT or
> alike, SPI may have a legal claim against the use of the "FreeWRT"
> trademark that some people may see as confusingly similar to OpenWRT.
> 
> My main objection to "LEDE" is that I have no idea how to pronounce this
> name correctly. I suspect that many English speakers will find
> themselves equally confused about how to pronounce "LEDE". Is it like in
> "LEAD the way", or like in "LEAD, a heavy metal", or like "LE DE"? While
> the core LEDE community might know how to pronounce the name correctly,
> try explaining it to the world outside. For this reason, "OpenWRT" is a
> better choice imho.
> 
> However, I also agree with Dave, Alberto and Stefan that a name change
> may be a really smart way to communicate the fresh start of the project,
> a reboot, especially if the new name rides on the popularity of
> "OpenWRT". It could be for example "OpenLD" (LD for Linux Device) or
> "LibreWRT". Of course this is all conditional on the merge of OpenWRT
> and LEDE. If the projects do not merge, the OpenWRT folks and SPI may
> have a claim against the use of OpenLD or LibreWRT or alike.
> 
> By the way, there is a pending application at the USPTO for the
> registration of "LEDE" trademark for use in some software or websites:
> http://tmsearch.uspto.gov/bin/showfield?f=doc&state=4805:8zgvq2.8.1

The point was that OpenWrt is already registered and managed by SPI, so
we may as well keep using it, and that is just what I meant to say here,
nothing more.
-- 
Florian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 00/22] Conversion of ARMv4 Gemini to DT and multiplatform

[Florian Fainelli]

On 01/22/2017 04:15 AM, Linus Walleij wrote:
> I got a Gemini platform from Florian Fainelli over at OpenWRT
> some time back. I finally got around to "future-proofing" the
> platform, which was the idea when he paintakingly sent the box
> over to me.

I would have happily tested that series ;) thanks a lot for making it
happen!

> 
> This is the result: Gemini is converted to device tree and
> multiplatform, all existing drivers are rewritten into their
> proper subsystems and the old board-specific and machine-specific
> code is deleted.
> 
> I would ideally like the irqchip, clocksource, gpio, rtc and MTD
> patches (and bindings) to simply be merged into the respective
> subsystem and the remaining ARM/ARM SoC patches funnelled to the
> ARM SoC tree in a single pull request, lock stock and barrel,
> with changes to board files and DTS additions in one go. But I
> guess I could also switch the DTS files to a separate branch.
> 
> The OpenWRT tree still have a whole bunch of significant out-of
> tree drivers:
> 
> - Watchdog
> - GMAC (ethernet)

Been wondering about the GMAC driver a little bit, and it does not
appear to be neither a Synopsys/Designware core (although not 100%
sure), nor the ftgmac100 either.

This submission does appear to be in a good shape:
https://lwn.net/Articles/437889/

> - FOT2G USB EHCI host
> - PATA
> - PCI
> 
> But I do not see any big obstacle in porting these over to be
> probed from the device tree and upstreamed on top of this patch
> series. I might tinker with it if I get time.
> 
> The out-of-tree code can be found here:
> http://git.openwrt.org/?p=openwrt.git;a=tree;f=target/linux/gemini;h=b74c3d8f0100e2ac8a4d71c4d23c082db2993e63;hb=HEAD
> 
> Linus Walleij (22):
>   ARM: gemini: convert to MULTI_IRQ_HANDLER
>   irqchip: DT bindings for Cortina Gemini irqchip
>   irqchip: add a driver for Cortina Gemini
>   clocksource: add DT bindings for Cortina Gemini
>   clocksource: Add driver for the Cortina Gemini
>   gpio: add DT bindings for Cortina Gemini GPIO
>   gpio: Add a driver for Cortina Systems Gemini GPIO
>   rtc: Add device tree probing to the Gemini driver
>   mtd: add DT bindings for the Cortina Systems Gemini Flash
>   mtd: physmap_of: add a hook for Gemini flash probing
>   ARM: dts: add top-level DT bindings for Cortina Gemini
>   ARM: gemini: DT for the Cortina Gemini SoC platforms
>   ARM: dts: add device tree for Gemini SoC and SQ201
>   ARM: dts: add a devicetree for Raidsonic NAS IB-4220-B
>   ARM: dts: add a devicetree for Teltonika RUT1xx
>   ARM: dts: add a devicetree for Wiliboard WBD-111
>   ARM: dts: add a devicetree for Wiliboard WBD-222
>   ARM: gemini: delete all boardfiles
>   ARM: gemini: switch to sparse IRQs
>   ARM: gemini: select ARM_PATCH_PHYS_VIRT and AUTO_ZRELADDR
>   ARM: gemini: convert to ARMv4 multiplatform
>   ARM: configs: add a gemini defconfig
> 
>  Documentation/devicetree/bindings/arm/gemini.txt   |  58 +
>  .../bindings/gpio/cortina,gemini-gpio.txt  |  24 ++
>  .../cortina,gemini-interrupt-controller.txt|  22 ++
>  .../bindings/mtd/cortina,gemini-flash.txt  |  24 ++
>  .../devicetree/bindings/rtc/cortina,gemini.txt |  14 ++
>  .../bindings/timer/cortina,gemini-timer.txt|  22 ++
>  arch/arm/Kconfig   |   9 -
>  arch/arm/boot/dts/Makefile |   6 +
>  arch/arm/boot/dts/gemini-nas4220b.dts  |  68 +
>  arch/arm/boot/dts/gemini-rut1xx.dts|  63 +
>  arch/arm/boot/dts/gemini-sq201.dts |  94 +++
>  arch/arm/boot/dts/gemini-wbd111.dts| 101 
>  arch/arm/boot/dts/gemini-wbd222.dts| 101 
>  arch/arm/boot/dts/gemini.dtsi  |  96 +++
>  arch/arm/configs/gemini_defconfig  |  63 +
>  arch/arm/mach-gemini/Kconfig   |  52 +---
>  arch/arm/mach-gemini/Makefile  |  15 +-
>  arch/arm/mach-gemini/Makefile.boot |   9 -
>  arch/arm/mach-gemini/board-dt.c|  62 +
>  arch/arm/mach-gemini/board-nas4220b.c  | 106 
>  arch/arm/mach-gemini/board-rut1xx.c|  92 ---
>  arch/arm/mach-gemini/board-wbd111.c| 133 --
>  arch/arm/mach-gemini/board-wbd222.c| 133 --
>  arch/arm/mach-gemini/common.h  |  33 ---
>  arch/arm/mach-gemini/devices.c | 118 -
>  arch/arm/mach-gemini/gpio.c| 231 -
>  arch/arm/mach-gemini/idle.c|  31 ---
>  arch/arm/mach-gemini/include/mach/entry-macro.S|  33 ---
&

Re: [OpenWrt-Devel] [PATCH 00/22] Conversion of ARMv4 Gemini to DT and multiplatform

[Florian Fainelli]

On 01/24/2017 12:47 PM, Linus Walleij wrote:
> Hans, Florian et al: does any of you have a copy of the kernel source
> dump(s) from Teltonika, Raidsonic or Wiliboard?
> 
> Would be nice to have the stuff that vendors are using.
> 
> On Tue, Jan 24, 2017 at 6:24 PM, Hans Ulli Kroll
>  wrote:
> 
>> AFAICR
>> This is a dual GMAC !
>>
>> They are two different base address for each GMAC and one shared
>> base address for both of them.
>> This is all in one address space which remaps the driver.
>>
>> And to make it worse two interrupt lines, one of them is also shared.
>>
>> Any ideas to "convert" this into DT ??
>> Because I think it's impossible to split both GMAC interfaces ??
> 
> Sounds odd.  Yeah hardware.h lists this:
> 
> #define GEMINI_TOE_BASE 0x6000
> #define GEMINI_GMAC0_BASE   0x6000A000
> #define GEMINI_GMAC1_BASE   0x6000E000
> 
> I guess one approach is to make a driver handling all of it in one,
> let it ioremap all regions and support one or two GMACs on the same
> TOE. More complex solutions is to share the TOE using
> syscons regmap mechanism but it looks cumbersome.
> 
> {
>compatible = "cortina,genesis-gmac-ethernet";
>reg = <0x6000 0xa000>, <0x6000a000 0x4000>, <0x6000e000 0x4000>;
>interrupts = <1 IRQ_TYPE_LEVEL_HIGH>, <2 IRQ_TYPE_LEVEL_HIGH>;
> }
> 
> Or something like that?

I'd recommend looking at how mv643xx_eth does it, there are shared and
individual portions of the register set in there, with concepts of
"ports" which result in network device instances.
-- 
Florian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 2/4] ata: Add DT bindings for the Gemini SATA bridge

[Florian Fainelli]

On 05/08/2017 02:16 PM, Tom Psyborg wrote:
> Is it ever going to be added so this endless spam can end?

It's the first iteration of the (S)ATA patchset, and if you are not
interested, just ignore the thread.

Linus is doing everyone a great favor here by making sure that this
platform gets properly supported upstream such that the cost of
maintaining in OpenWrt/LEDE/anywhere else comes down to almost zero.

Almost forgot: please don't top post.

> 
> 
> On 8 May 2017 at 22:33, Linus Walleij  > wrote:
> 
> On Mon, May 8, 2017 at 12:49 PM, Bartlomiej Zolnierkiewicz
> mailto:b.zolnier...@samsung.com>> wrote:
> > On Saturday, May 06, 2017 02:10:51 PM Linus Walleij wrote:
> 
> >> +  Mode 3: ata0 master <-> sata0
> >> +  ata1 slave  <-> sata1
> >
> > ata0 slave?
> >
> >> +  ata1 master and slave interfaces brought out
> >> +   on IDE pads
> 
> Of course. Thanks for reading close, much appreciated!
> 
> Yours,
> Linus Walleij
> ___
> 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
> 


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

Re: [OpenWrt-Devel] openwrt and lede - remerge proposal

[Florian Fainelli]

On 05/08/2017 06:19 AM, John Crispin wrote:
> Hi,
> 
> Felix, Imre and myself had 2 calls last week lasting several hours and
> discussed the following proposal of conditions for a remerge that we
> would like to propose and have people vote on.
> 
> *) branding
> - the owrt side sees no option of using the lede brand
> 
> - a (minor) majority voted for openwrt as a name over lede whilst most
> people said they did not care
> 
> - as the last vote had a 100% ACK for a remerge using the owrt brand is
> the only feasible option
> 
> *) domain
> - transfer owner ship to SPI for openwrt.org and lede-project.org
> - add them to the pool of urls at digital ocean
> - post remerge build a setup where we have several DNS servers in
> various locations
> - point git.openwrt.org at the lede git server
> - point bugs.openwrt.org to the lede flyspray instance
> - keep both wikis and forums as is (we should decide post remerge how to
> proceed to avoid these issues blocking the progress)
> - update the lede domain entries for build/download/rsync/... servers so
> that the openwrt domain also points at them
> 
> *) SPI
> - TBD post remerge
> 
> *) github
> - stop pushing to lede-project organisation
> - start pushing to the openwrt organisation
> - cleanup the list of owners in the openwrt organisation
> - obsolete all issues on the openwrt organisation and close the issue
> tracker
> - go through the open openwrt and lede PRs, pickup whats useful and
> close the rest, asking people to repost (things wont be rebasable anyhow)
> - close the lede PR tracker
> - keep the lede organisation in its current state so that forked trees
> dont get obsoleted
> 
> - obsolete the lede github org after a grace period of 3-6 months
> 
> *) landing page
> - update the lede landing page to represent the openwrt name
> - update the landing page to have the same look & feel as the current
> openwrt landing page
> - point openwrt.org at the lede landing page
> 
> *) trac
> - trac is already readonly, keep content so that search engines can
> still find the it
> - edit the trac html templates, adding a note pointing at the
> bug.openwrt.org instance
> 
> *) email accounts
> - currently there are around ~20 active openwrt.org mail accounts
> - turn all the webmaster@, hostmaster@, ... accounts into aliases that
> anyone with voting rights can be subscribed to
> - ask those people that are no longer active to voluntarily give up
> their accounts
> - mail addresses may under no conditions be used for any personal
> business, consultancy, applying for jobs, ... purposes
> 
> - any mail sent from an openwrt.org account needs to adhere the
> trademark policy and should only be used for FOSS purposes
> 
> 
> *) wiki / forum
> - TBD
> - asking in either forum/wiki will get a biased vote so keep them both
> around
> - start a separate discussion regarding these post remerge
> 
> *) LF
> - find out what doubts folks have about LF
> - find out benefits - we would have their hosting and sponsorship ?!
> - start a separate discussion regarding these post remerge
> 
> *) git trees
> - rebrand the lede tree to openwrt
> - work out what has happened inside the openwrt tree since the reboot
> and pick up the useful bits (zoltan has done some prior work on this
> already)
> 
> *) mailing list
> - ask david to add the openwrt-adm and openwrt lists
> - announce the switch to the infradead serves, asking people to
> unsubscribe if they have privacy issues with this
> - import the user DB from the current openwrt and lede ML into the 2 new
> mailing lists
> - find out if we can redirect/auto-reply  the existing lists to the new
> ones
> 
> *) trademark/sponsorship policy
> - review/ack imres trademark policy
> - review/ack jows sponsorship policy
> 
> *) timeline
> - refine / vote / agree on the proposal withing the next 2 week
> - work on the action items in the 4 weeks after that

All of this sounds good me, and thanks for taking the time to talk to
each other and come to an agreement.

How can we help?
-- 
Florian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [RFC] Pre-seeded files/directories for UBIFS

[Florian Fainelli]

Hello,

On 05/20/2017 09:12 AM, Richard Weinberger wrote:
> Hi!
> 
> These days I had an interesting discussion with Christoph about overlayfs and
> its burden. The main use-case of overlayfs in combination with UBIFS is 
> having a
> squashfs as lower and UBIFS as upper directory. Such that all changes to the
> read-only squashfs go into UBIFS. Upon a factory reset all files within the
> UBIFS will be removed  and the merged directory is clean again. Christoph 
> argued
> that such a functionality  could be achieved without overlayfs if the 
> filesystem
> supported something like pre-seeded  files or directories. This would lower
> memory pressure and complexity.

As you may know, OpenWrt/LEDE have been using this scheme for many years
now (before it was named overlayfs, this was called mini fanout overlay
~10 yrs ago) with squashfs + jffs2 before on P-NOR flashes. There are
still devices like those that benefit from squashfs(ro)+jffs2(rw), so
while bringing a similar functionality using UBIFS exclusively would be
interesting, it would still make Linux distribution want to support a
more generic scheme which is using overlayfs as well.

> 
> Today I had a thought about this and I'm pretty sure we can implement this in
> UBIFS with not too much effort. The basic idea is marking files or whole
> directories as seed upon mkfs.ubifs time.
> If these files will be changed at run-time, the original contents will stay on
> the medium and at any time these files can be reverted back to their seed 
> state.
> This includes file contents, attributes and extended attributes. I can think 
> of
> an UBIFS specific IOCTL to put files into seed state and to revert them again.
> 
> Since UBIFS is already a pure copy-on-write filesystem, all we have to do is
> teaching the index tree about seeds. We could add a flag to the UBIFS key 
> which
> indicates that the node behind this key is seeded.
> i.e. file "foo" is seeded and the corresponding inode number is 0x1234,
> then every key of every UBIFS node that belongs to that file will wear the new
> flag UBIFS_SEED_KEY.
> ubifs_ino_node: 0x1234 | UBIFS_INO_KEY | UBIFS_SEED_KEY
> ubifs_data_node: 0x1234 |  | UBIFS_DATA_KEY | UBIFS_SEED_KEY
> 
> The inode itself will have a flag which denotes whether this file is seeded 
> and
> whether some modifications have happened. This will allow us to lookup 
> directly
> in the index tree with UBIFS_SEED_KEY set or no. Otherwise we'd have to do two
> lookups every time.
> 
> If a seeded node faces a modification it will stay referenced in the index 
> tree
> and a copy without UBIFS_SEED_KEY is made. Upon next lookup the new node will
> be used automatically. Reverting to the original state means purging all nodes
> that don't have the UBIFS_SEED_KEY flag.
> 
> There are corner cases to consider, mostly for lookup of data nodes.
> Currently a missing data node denotes a hole in a file.
> With seeded files a missing data node can also mean that we need to fall back
> to a UBIFS_SEED_KEY lookup.
> 
> Storing UBIFS_SEED_KEY itself into the UBIFS key is also not trivial since
> almost all bits of the 32bit tuple are in use. But I'm sure we find some way
> to encode it.
> 
> Another thing to consider are seeded directory entries. This requires us to
> implement our own whiteout mechanism. But this could also be re-used for
> overlayfs whiteouts.
> 
> That said, I consider this feature as doable but not trivial.
> Artem, Adrian, you designed UBIFS, what do you think?
> Maybe I missed some major show-stopper. :)
> 
> Thanks,
> //richard
> 
> __
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
> 

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

Re: [OpenWrt-Devel] openwrt and lede - remerge proposal V2

[Florian Fainelli]

On 05/22/2017 02:02 AM, Rafał Miłecki wrote:
> On 05/22/2017 09:40 AM, John Crispin wrote:
>> *) branding
>> - the owrt side sees no option of using the lede brand
>> - a (minor) majority voted for openwrt as a name over lede whilst most
>> people said they did not care
>> - as the last vote had a 100% ACK for a remerge using the owrt brand
>> is the only feasible option
> 
> Since the project is going to be known/accessible under OpenWrt name now, I
> want also mbm and Kaloz to share #openwrt and #openwrt-devel privileges.
> 
> There were many times op was needed but mbm/Kaloz weren't around.
> 
> I was refused/ignored multiple times when asking for that, so I wanted to
> bring it as this point to be clear. Is that OK for you guys?

Yes that's fine, while your channel operator status is worked on, if
there is something specific you can private message me on IRC and I get
be op on these two channels for a little bit to do what is necessary.

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

Re: [OpenWrt-Devel] [OpenWrt-Hackers] openwrt and lede - remerge proposal V3

[Florian Fainelli]

Le 05/29/17 à 00:03, John Crispin a écrit :
> (resend, this time as plain text)
> 
> Hi,
> 
> here is a V3 of the remerge proposal, I tried to fold all the comments
> people made into it, if anything is missing let me know. Please remeber
> that post remerge anything can be voted on, so cluttering the proposal
> with many details will delay the remerge even more.
> 
> Ideally we manage to vote during this week.

Ack on everything, let's get this moving!
-- 
Florian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] openwrt and lede - remerge proposal V3

[Florian Fainelli]

On 05/28/2017 11:56 PM, John Crispin wrote:
> Hi,
> 
> here is a V3 of the remerge proposal, I tried to fold all the comments
> people made into it, if anything is missing let me know. Please remeber
> that post remerge anything can be voted on, so cluttering the proposal
> with many details will delay the remerge even more.
> 
> Ideally we manage to vote during this week.

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

Re: [OpenWrt-Devel] [LEDE-DEV] MV88E6060 switch

[Florian Fainelli]

On Jul 23, 2017 11:28, "Nerijus Baliūnas" 
wrote:

2017-07-21 19:48, Nerijus Baliūnas via Lede-dev rašė:

> How do I configure vlan? Here I changed eth0 to eth0.1:
>
> config interface 'lan'
> option type 'bridge'
>option ifname 'eth0.1'
>option proto 'static'
>option ipaddr '192.168.1.1'
>option netmask '255.255.255.0'
>option ip6assign '60'
>

I tried
config 'switch' 'eth0'
   option 'enable'  '1'
   option 'enable_vlan' '1'
   option 'reset'   '1'

config 'switch_vlan'
   option 'vlan'   '1'
   option 'device' 'eth0'
   option 'ports'  '1 2 3 4 5t'

config 'switch_vlan'
   option 'vlan'   '2'
   option 'device' 'eth0'
   option 'ports'  '0 5t'

Does not work. Do I need to have swconfig installed in order to
get the switch working? Because by default it is not installed.


Yes, it is necessary with this switch driver to have swconfig installed,
otherwise nothing would push CLEAN configurations to the mv88e6060 switch.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v3 0/6] staging: Introduce DPAA2 Ethernet Switch driver

[Florian Fainelli]

Hi,

On 10/14/2017 04:09 AM, Linus Walleij wrote:
> Top posting and resending since net...@vger.kernel.org
> is the right mail address for this. Mea culpa.
> 
> Linus Walleij
> 
> On Sat, Oct 14, 2017 at 11:35 AM, Linus Walleij
>  wrote:
>> On Thu, Oct 5, 2017 at 11:16 AM, Razvan Stefanescu
>>  wrote:
>>
>>> This patchset introduces the Ethernet Switch Driver for Freescale/NXP SoCs
>>> with DPAA2 (DataPath Acceleration Architecture v2). The driver manages
>>> switch objects discovered on the fsl-mc bus. A description of the driver
>>> can be found in the associated README file.
>>>
>>> The patchset consists of:
>>> * A set of libraries containing APIs for configuring and controlling
>>>   Management Complex (MC) switch objects
>>> * The DPAA2 Ethernet Switch driver
>>> * Patch adding ethtool support
>>
>> So it appears that ethernet switches is a class of device that need their own
>> subsystem in Linux, before this driver can move out of staging.

FWIW, I think the biggest dependency on this driver is not a switch
driver model because that exists but it's actually the specific bus (MC
AFAICT) that it depends on. More on the Ethernet switch device model below.

We do actually have a pretty good model for Ethernet switches now, in
fact, we got several options:

- Distributed Switching Architecture (DSA) should be used when the
CPU/management Ethernet controller is a traditional Ethernet MAC that is
either internally or externally attached to a switch. This usually comes
with the Ethernet switch capable of providing per-packet metadata (tag)
to indicate to the management interface why the packet is transmitted.
For older/dumber switches, using no management tag, but separating with
802.1Q tags is definitively an option that brings in the same
requirements for DSA. DSA does make use of switchdev to get notified
from the networking stack when there is an opportunity to offload
objects: VLAN, FDB, MDB, etc. DSA is both a device driver model and a
switch device abstraction model.

- switchdev should be used when the management interface is tightly
coupled with the switching hardware, such that, per-packet information
is obtained via DMA/PIO descriptors for instance. switchdev is not a
device driver model so the switch driver is responsible for creating its
own net_device instances and feeding the appropriate netdev_ops,
ethtool_ops and switchdev_ops, this is what is being done here, and this
is also perfectly fine.

>>
>> I ran into the problem in OpenWRT that has these out-of-tree patches for
>> off-chip ethernet switches, conveniently placed under net/phy:
>> https://github.com/openwrt/openwrt/tree/master/target/linux/generic/files/drivers/net/phy
>>
>> These are some 12 different ethernet switches. It is used in more or
>> less every home router out there.

The most deployed switch device drivers have been converted to DSA
already: b53, qca8k (ar83xx in OpenWrt/LEDE) and mtk7530 are all in
tree, and now we are getting new submissions from Michrochip to support
their pretty large KSZ series. Converting from swconfig to DSA is
actually quite simple, but like anything requires time and testing, and
access to hardware and ideally datasheet.

>>
>> It's not really working to have all of this out-of-tree, there must have been
>> discussions about the requirements for a proper ethernet switch subsystem.
>>
>> I'm not a good net developers, just a grumpy user having to deal with all
>> of this out-of-tree code that's not helpful with changing interfaces like
>> device tree and so on.
>>
>> Can you people who worked on this over the years pit in with your
>> requirements for an ethernet switch subsystem so we can house these
>> drivers in a proper way?
>>
>> What we need AFAICT:
>>
>> - Consensus on userspace ABI
>> - Consensus on ethtool extenstions
>> - Consensus on where in drivers/net this goes
>>
>> You can kick me for not knowing what I'm talking about and how complex the
>> problem is now.

Kicking you would not be fair, but you are about 3 years late ;) We had
such discussions in 2014 after a failed attempt at submitting swconfig
as a possible model. 3 years later we have 1 major switchdev driver:
mlxsw and quite a few active DSA drivers. The paradigms that apply are:

- normal Linux tools keep working: bridge, iproute2, ethtool
- every user-visible port has a corresponding network device, in order
to meet the first paradigm
- for every other part of the switch that does not have a net_device
representor, devlink can/should be used.
-- 
Florian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v3 0/6] staging: Introduce DPAA2 Ethernet Switch driver

[Florian Fainelli]

On October 14, 2017 2:59:22 PM PDT, Linus Walleij  
wrote:
>On Sat, Oct 14, 2017 at 8:52 PM, Florian Fainelli
> wrote:
>
>> The most deployed switch device drivers have been converted to DSA
>> already: b53, qca8k (ar83xx in OpenWrt/LEDE) and mtk7530 are all in
>> tree, and now we are getting new submissions from Michrochip to
>support
>> their pretty large KSZ series. Converting from swconfig to DSA is
>> actually quite simple, but like anything requires time and testing,
>and
>> access to hardware and ideally datasheet.
>
>Hm, I have a Realtek RB8366RB in this router on my desk.
>
>I guess that means I should just take the old switchdev-based
>SMI-driver and convert it to DSA.
>
>I bet I can do that :D

Yes, it really should not be too hard. The OpenWrt/LEDE driver had mostly the 
same semantics as what is needed for being a proper DSA driver. You should of 
course start simple: get basic switching working, then add statistics, VLAN, 
FDB, etc. OpenWrt/LEDE models switches as PHY device objects which would not 
work upstream so you should have the driver be probed as a MDIO/SPI/I2C (see 
b53 for example) and set up fixed-link properties between the CPU and the 
switch.

>
>Well, I will try. Because it's blocking me to work on the Gemini
>ethernet driver.

Well usually the boot loader may leave the switch in a good enough state that 
you can work on the CPU controller mostly independently from dealing with the 
switch. This is not universally true, and a properly working bootloader should 
actually quiesce/reset both blocks prior to OS control.

Don't hesitate if you have questions.

Cheers.

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

Re: [OpenWrt-Devel] OpenWrt -> LEDE git tree merge

[Florian Fainelli]

On 10/22/2017 11:46 AM, Hauke Mehrtens wrote:
> Hi,
> 
> I am working on merging the missing commits from the OpenWrt git
> repository into the LEDE repository.
> 
> Here is a list of all non merge commits from the OpenWrt git repository
> and their corresponding LEDE commit IDs:
> https://github.com/hauke/openwrt-lede-merge/blob/master/commits.csv
> 
> I only looked into the non merge commits and assumed that commits with
> the same title are the same, if this is wrong please point me to some
> place where this causes problems.
> 
> I used this script to generate the csv table:
> https://github.com/hauke/openwrt-lede-merge/blob/master/openwrt-merge.py
> 
> The bigger topics I see are:
> * addition of SoCFPGA target with kernel 4.4 support
>  * Will someone port this to kernel 4.9 or provide me with hardware so I
>can try to port this and test it?
> * There are some commits without a Signed-off-by line, I will contact
>   the authors.
> * The realview target was removed from LEDE, but it got an update to
>   kernel 4.4 in OpenWrt, how do we want to handle this? Does anyone need
>   the realview target?

armvirt is now a superset of realview so this can be dropped.
-- 
Florian
___
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

[Florian Fainelli]

On 10/27/2017 02:34 AM, p...@oranjevos.nl wrote:
> Dear Imre,
> 
> On the info for the version of the patch: my error, must have overlooked the 
> included version info, it is indeed included.
> 
> About the use of openwrt email addresses in the SOB:
> This has been discussed before, and the arguments against using an openwrt 
> mail address as a personal address haven't vanished.
> The address in the SOB is meant to identify a contributor, most likely a 
> natural person, not some entity of the openwrt project. Usage of an openwrt 
> mail address suggests that the person using that address has another position 
> in the project than those that use mail addresses not within the openwrt.org 
> domain, which does not go well with LEDE rules.
> 
> IIRC, during discussions on the remerge, the following compromis was reached: 
> usage of personal openwrt addresses wasn't ruled out completely, but only in 
> passive sense, as a means to keep receiving mail on the address and active 
> usage for personal business is not allowed. John remerge proposal v3 states 
> clearly:
> - mail addresses may under no conditions be used for any personal business, 
> consultancy, applying for jobs, ... purposes

Did you purposely omit the next bullet item that says?

- any mail sent from an openwrt.org account needs to adhere the
trademark policy and should only be used for FOSS purposes

Link:
http://lists.infradead.org/pipermail/lede-adm/2017-May/000517.html

> 
> As a mail address in a SOB is a personal address, is meant to be that, using 
> an openwrt address in a SOB goes directly against the agreed on rules, and 
> certainly against the spirit of the LEDE rules that have proven to be 
> successful in making the project getting traction and commitment.

LEDE project rule #10 does only stipulate that new email addresses will
not be given away on the premises of and privacy and equality:

https://lede-project.org/rules

10. The project will not offer email accounts under its project domain
for privacy and equality reasons.


That sentence is written with the future tense, and therefore does not
try to impose or specify anything with respect to emails given before
(so in the past).

Therefore, my reading of the LEDE project rules and the remerge proposal
makes me so inclined as to think that Imre is not in direct violation of
the LEDE project rules regarding the use of an @openwrt.org email
contributor for FOSS perspectives.

Quite frankly, if the goal is just to give Zoltan and Imre a hard time
and nitpick on everything possible just to delay (purposely or not) the
remerge, then you are doing a great job at it, but this goes against
rule #12.

> Paul
> 
> 
>  
> 
>> Op 26 okt. 2017, om 18:32 heeft Imre Kaloz  het volgende 
>> geschreven:
>>
>> Hi Paul,
>>
>> On 2017-10-26 18:16, p...@oranjevos.nl wrote:
>>> Please, could you add some info on what has changed with the new version of 
>>> the patch ?
>>> And, it would be appreciated when the SOB would not use an openwrt.org mail 
>>> address (assuming Imre has another suitable mail available).
>>>
>>> Paul
>>>
>>>
 Op 26 okt. 2017, om 17:41 heeft Zoltan HERPAI 
  het volgende geschreven:

 Given that we've decided to sail under the same flag for
 the benefit of the whole community, and acknowledge the
 achievements of the LEDE project, let's start the final
 steps of the merge.

 The git and other sources are untouched until the infra merge.

 v2: - dismiss bugtracker and forum change
- update uhttpd cert gen
- update banner
- update busybox NSLOOKUP patch

 Signed-off-by: Zoltan HERPAI 
 

 Signed-off-by: Imre Kaloz 
 



>>
>> Please find the changes listed in the description, but left it in above as 
>> well. As for using another email address, I won't use my personal one for 
>> this as I don't use this for that, simply as that. This is fully following 
>> what the merge agreement that has been voted for and got accepted defined.
>>
>>
>> Best,
>> Imre
>>
> 
> 
> ___
> Lede-dev mailing list
> lede-...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
> 


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

[OpenWrt-Devel] [PATCH RFC] mac80211: Don't check for platform files with external kernel trees

[Florian Fainelli]

When building with an external kernel tree, do not check the different
platform files since this is almost guaranteed they are going to differ.

Signed-off-by: Florian Fainelli 
---
 package/kernel/mac80211/Makefile | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/package/kernel/mac80211/Makefile b/package/kernel/mac80211/Makefile
index 385bea4d2f5d..1740c956fe9f 100644
--- a/package/kernel/mac80211/Makefile
+++ b/package/kernel/mac80211/Makefile
@@ -1751,11 +1751,16 @@ ifneq 
($(CONFIG_PACKAGE_kmod-cfg80211)$(CONFIG_PACKAGE_kmod-lib80211),)
  endef
 endif
 
-define Build/Configure
+ifeq ($(strip $(CONFIG_EXTERNAL_KERNEL_TREE)),"")
+ define Build/Configure
cmp $(PKG_BUILD_DIR)/include/linux/ath9k_platform.h 
$(LINUX_DIR)/include/linux/ath9k_platform.h
cmp $(PKG_BUILD_DIR)/include/linux/ath5k_platform.h 
$(LINUX_DIR)/include/linux/ath5k_platform.h
cmp $(PKG_BUILD_DIR)/include/linux/rt2x00_platform.h 
$(LINUX_DIR)/include/linux/rt2x00_platform.h
-endef
+  endef
+else
+  define Build/Configure
+  endef
+endif
 
 define Build/Compile
$(SH_FUNC) var2file "$(call shvar,mac80211_config)" 
$(PKG_BUILD_DIR)/.config
-- 
2.14.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 0/5] x86: add support for microcode update

[Florian Fainelli]

On January 17, 2018 11:41:01 AM PST, Zoltan HERPAI  wrote:
>Hi,
>
>This series will add support for microcode update on x86 targets,
>in light of the recent security issues.
>
>While other distributions use an early initramfs approach to update 
>the microcode as early as possible, in OpenWrt the earliest place
>where we can do this is preinit.
>
>The Intel microcode package is using the source package by Debian,
>the AMD microcode package is downloaded from the linux-firmware 
>git repository.
>
>This was tested on various Intel-based desktops with ancient BIOSes.
>
>Once the series is merged into trunk, this could/should be backported
>into 17.01 and 15.05 without too much hassle.

FWIW:

Reviewed-by: Florian Fainelli 

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

Re: [OpenWrt-Devel] What is the best approach to building the OpenWRT with external Kernel?

[Florian Fainelli]

On 03/07/2018 07:20 AM, Jorge Pereira wrote:
> Hi,
> 
> I have some specific board delivered with a Kernel 3.18.x that have some
> specific changes that definitely I cannot run using another kernel by
> now. So, what is the best approach to building the OpenWRT using this
> specific Kernel path?

There is an option for that:

make menuconfig
-> Advanced configuration options (for developers)  
- > Use external kernel tree

> 
> ps: The Kernel used by OpenWRT/LEDE has special changes for the project?

Yes it does, see target/linux/generic/patches*/

> 
> Thanks in advance.
> --
> Jorge Pereira
> 
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> 

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

Re: [OpenWrt-Devel] [PATCH v2] kernel: rtl8366-smi: add Realtek switch management via mii-bus

[Florian Fainelli]

On 04/03/2018 10:13 AM, Сергей Василюгин wrote:
> Current version of rtl8366-smi module support Realtek switch
> managment via two gpio lines only. This patch add Realtek switch
> management via mii_bus. For my board Tp-link Archer C2 v1 (Mediatek
> SoC mt7620a based) dts-file configuration looks like:
> 
>   rtl8367rb {
>   compatible = "realtek,rtl8367b", "rtl8367b";
>   realtek,extif1 = <1 0 1 1 1 1 1 1 2>;
>   mii-bus = <&mdio0>;

The switch node should be moved under the mdio controller node below,
parent/child relationships imply the control bus.

>   };
> 
> ðernet {
>   status = "okay";
>   mtd-mac-address = <&rom 0xf100>;
>   pinctrl-names = "default";
>   pinctrl-0 = <&rgmii1_pins &rgmii2_pins &mdio_pins>;
> 
>   port@5 {
>   status = "okay";
>   mediatek,fixed-link = <1000 1 1 1>;
>   phy-mode = "rgmii";
>   };
> 
>   mdio0: mdio-bus {
>   status = "okay";
>   };
> };
> 
> Realtek rtl8367rb switch is ok.
> Other Realtek switches and archs are untested but must work too.
> 
> Version 2: add mii_bus mutex_lock
> 
> Signed-off-by: Serge Vasilugin 
> --
> 

[snip]

> @@ -1416,7 +1520,24 @@ int rtl8366_smi_probe_of(struct platform_device *pdev, 
> struct rtl8366_smi *smi)
>  {
>   int sck = of_get_named_gpio(pdev->dev.of_node, "gpio-sck", 0);
>   int sda = of_get_named_gpio(pdev->dev.of_node, "gpio-sda", 0);
> + struct device_node *np = pdev->dev.of_node;;
> + struct device_node *mdio_node = NULL;
> +
> + mdio_node = of_parse_phandle(np, "mii-bus", 0);
> + if (!mdio_node) {
> + dev_err(&pdev->dev, "cannot find mdio node phandle");
> + goto try_gpio;
> + }

You should have two entry points for your driver, and have shared code,
one entry point is a gpio/platform_driver and the other one is a
mdio_device/driver. They would both call into the same code that does
the register read/write code, but how they are probed should be different.

See drivers/net/dsa/b53/ for an example of a driver that can deal with
multiple control buses.
-- 
Florian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] ath79: add spi nand driver, the source code from

[Florian Fainelli]

On 05/17/2018 06:14 PM, Luochongjun wrote:
> ---
>  .../patches-4.9/491-mtd-spi-nand-driver.patch  | 2785 
> 
>  1 file changed, 2785 insertions(+)
>  create mode 100644 
> target/linux/ar71xx/patches-4.9/491-mtd-spi-nand-driver.patch

Instead of combining all upstream patches that got recently submitted on
the MTD mailing-list into one large patch, you should provide a patch
that includes all the necessary patches to bring the recent SPI-NAND
framework into the OpenWrt kernel tree. This makes it much easier to
drop dependencies and/or backport fixes as we move from either 4.9 to
another 4.9 stable release, or from 4.9 to say 4.14 for instance.

See how bcm53xx does it for instance.

Thank you!
-- 
Florian

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

Re: [OpenWrt-Devel] [PATCH 1/3] net: dsa: Add DT bindings for Vitesse VSC73xx switches

[Florian Fainelli]

On 06/14/2018 05:35 AM, Linus Walleij wrote:
> This adds the device tree bindings for the Vitesse VSC73xx
> switches. We also add the vendor name for Vitesse.
> 
> Cc: devicet...@vger.kernel.org
> Signed-off-by: Linus Walleij 
> ---
>  .../bindings/net/dsa/vitesse,vsc73xx.txt  | 81 +++
>  .../devicetree/bindings/vendor-prefixes.txt   |  1 +
>  2 files changed, 82 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/net/dsa/vitesse,vsc73xx.txt
> 
> diff --git a/Documentation/devicetree/bindings/net/dsa/vitesse,vsc73xx.txt 
> b/Documentation/devicetree/bindings/net/dsa/vitesse,vsc73xx.txt
> new file mode 100644
> index ..474cdba5fa37
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/dsa/vitesse,vsc73xx.txt
> @@ -0,0 +1,81 @@
> +Vitess VSC73xx Switches
> +===
> +
> +This defines device tree bindings for the Vitesse VSC73xx switch chips.
> +The Vitesse company has been acquired by Microsemi and Microsemi in turn
> +acquired by Microchip but retains this vendor branding.
> +
> +The currently supported switch chips are:
> +Vitesse VSC7385 SparX-G5 5+1-port Integrated Gigabit Ethernet Switch
> +Vitesse VSC7388 SparX-G8 8-port Integrated Gigabit Ethernet Switch
> +Vitesse VSC7395 SparX-G5e 5+1-port Integrated Gigabit Ethernet Switch
> +Vitesse VSC7398 SparX-G8e 8-port Integrated Gigabit Ethernet Switch
> +
> +The device tree node is an SPI device so it must reside inside a SPI bus
> +device tree node, see spi/spi-bus.txt
> +
> +Required properties:
> +
> +- compatible: must be exactly one of:
> + "vitesse,vsc7385"
> + "vitesse,vsc7388"
> + "vitesse,vsc7395"
> + "vitesse,vsc7398"
> +- gpio-controller: indicates that this switch is also a GPIO controller,
> +  see gpio/

Missing reference here?

> +- #gpio-cells: this must be set to <2> and indicates that we are a twocell
> +  GPIO controller.

Should you also reference the standard binding here to interpret what
those two cells mean?

Other than that:

Reviewed-by: Florian Fainelli 

> +
> +Optional properties:
> +
> +- reset-gpios: a handle to a GPIO line that can issue reset of the chip.
> +  It should be tagged as active low.
> +
> +Required subnodes:
> +
> +See net/dsa/dsa.txt for a list of additional required and optional properties
> +and subnodes of DSA switches.
> +
> +Examples:
> +
> +switch@0 {
> + compatible = "vitesse,vsc7395";
> + reg = <0>;
> + /* Specified for 2.5 MHz or below */
> + spi-max-frequency = <250>;
> + gpio-controller;
> + #gpio-cells = <2>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + label = "lan1";
> + };
> + port@1 {
> + reg = <1>;
> + label = "lan2";
> + };
> + port@2 {
> + reg = <2>;
> + label = "lan3";
> + };
> + port@3 {
> + reg = <3>;
> + label = "lan4";
> + };
> + vsc: port@6 {
> + reg = <6>;
> + label = "cpu";
> + ethernet = <&gmac1>;
> + phy-mode = "rgmii";
> + fixed-link {
> + speed = <1000>;
> + full-duplex;
> + pause;
> + };
> + };
> + };
> +};
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
> b/Documentation/devicetree/bindings/vendor-prefixes.txt
> index b5f978a4cac6..e8473894700c 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> @@ -385,6 +385,7 @@ v3V3 Semiconductor
>  varisciteVariscite Ltd.
>  via  VIA Technologies, Inc.
>  virtio   Virtual I/O Device Specification, developed by the OASIS 
> consortium
> +vitesse  Vitesse Semiconductor Corporation
>  vivante  Vivante Corporation
>  vocore VoCore Studio
>  voipac   Voipac Technologies s.r.o.
> 

-- 
Florian

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

Re: [OpenWrt-Devel] [PATCH 2/3] net: phy: vitesse: Add support for VSC73xx

[Florian Fainelli]

On 06/14/2018 05:35 AM, Linus Walleij wrote:
> The VSC7385, VSC7388, VSC7395 and VSC7398 are integrated
> switch/router chips for 5+1 or 8-port switches/routers. When
> managed directly by Linux using DSA we need to do a special
> set-up "dance" on the PHY. Unfortunately these sequences
> switches the PHY to undocumented pages named 2a30 and 52b6
> and does undocumented things. It is described by these opaque
> sequences also in the reference manual. This is a best
> effort to integrate it anyways.
> 
> Signed-off-by: Linus Walleij 

Probably as good as it can get given the information you have access to.
Maybe the guys at Mircochip could help, adding them.

Reviewed-by: Florian Fainelli 

Just one nit below:

> ---
>  drivers/net/phy/vitesse.c | 162 ++
>  1 file changed, 162 insertions(+)
> 
> diff --git a/drivers/net/phy/vitesse.c b/drivers/net/phy/vitesse.c
> index d9dd8fbfffc7..526c71ae7d96 100644
> --- a/drivers/net/phy/vitesse.c
> +++ b/drivers/net/phy/vitesse.c
> @@ -16,6 +16,7 @@
>  #include 
>  #include 
>  #include 
> +#include 

Is that needed?
-- 
Florian

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

Re: [OpenWrt-Devel] [PATCH 3/3] net: dsa: Add Vitesse VSC73xx DSA router driver

[Florian Fainelli]

On 06/14/2018 05:35 AM, Linus Walleij wrote:
> This adds a DSA driver for:
> 
> Vitesse VSC7385 SparX-G5 5-port Integrated Gigabit Ethernet Switch
> Vitesse VSC7388 SparX-G8 8-port Integrated Gigabit Ethernet Switch
> Vitesse VSC7395 SparX-G5e 5+1-port Integrated Gigabit Ethernet Switch
> Vitesse VSC7398 SparX-G8e 8-port Integrated Gigabit Ethernet Switch
> 
> These switches have a built-in 8051 CPU and can download and execute
> firmware in this CPU. They can also be configured to use an external
> CPU handling the switch in a memory-mapped manner by connecting to
> that external CPU's memory bus.
> 
> This driver (currently) only takes control of the switch chip over
> SPI and configures it to route packages around when connected to a
> CPU port. The chip has embedded PHYs and VLAN support so we model it
> using DSA as a best fit so we can easily add VLAN support and maybe
> later also exploit the internal frame header to get more direct
> control over the switch.

Yes having the internal frame header working would be really great,
DSA_TAG_PROTO_NONE is really difficult to use without knowing all the
DSA details which reminds that we should have the following action items:

- document how DSA_TAG_PROTO_NONE behave differently with respect to
bridges/VLAN configuration and the DSA master device

- possibly introduce DSA_TAG_PROTO_8021Q which would automatically
partition ports by allocating one VLAN ID per-port (e.g: from top to
bottom) that would effectively offer the same features/paradigms as what
a proper header would offer (Port separation, if nothing else) and it
could be made seemingly automatic from within DSA

- get rid of b53's DSA_TAG_PROTO_NONE

> 
> The four built-in GPIO lines are exposed using a standard GPIO chip.

What are those typically used for out of curiosity? Is this to connect
to an EEPROM?

> 
> Signed-off-by: Linus Walleij 
> ---
>  drivers/net/dsa/Kconfig   |   12 +
>  drivers/net/dsa/Makefile  |1 +
>  drivers/net/dsa/vitesse-vsc73xx.c | 1362 +
>  3 files changed, 1375 insertions(+)
>  create mode 100644 drivers/net/dsa/vitesse-vsc73xx.c
> 
> diff --git a/drivers/net/dsa/Kconfig b/drivers/net/dsa/Kconfig
> index 2b81b97e994f..2f6207b969e3 100644
> --- a/drivers/net/dsa/Kconfig
> +++ b/drivers/net/dsa/Kconfig
> @@ -76,4 +76,16 @@ config NET_DSA_SMSC_LAN9303_MDIO
> Enable access functions if the SMSC/Microchip LAN9303 is configured
> for MDIO managed mode.
>  
> +config NET_DSA_VITESSE_VSC73XX
> + tristate "Vitesse VSC7385/7388/7395/7398 support"
> + depends on OF && SPI
> + depends on NET_DSA
> + select FIXED_PHY
> + select VITESSE_PHY
> + select NET_DSA_TAG_TRAILER

You advertise DSA_TAG_PROTO_NONE, so that appears to be unnecessary right?

[snip]
> +/**
> + * struct vsc73xx - VSC73xx state container
> + */
> +struct vsc73xx {
> + struct device   *dev;
> + struct gpio_desc*reset;
> + struct spi_device   *spi;
> + struct dsa_switch   *ds;
> + struct gpio_chipgc;
> + u16 chipid;
> + boolis_vsc7385;
> + boolis_vsc7388;
> + boolis_vsc7395;
> + boolis_vsc7398;

How about having an u16/u32 chip_id instead?

> + u8  addr[ETH_ALEN];
> + struct mutexlock; /* Protects SPI traffic */
> +};

[snip]

> +static enum dsa_tag_protocol vsc73xx_get_tag_protocol(struct dsa_switch *ds,
> +   int port)
> +{
> + /* The switch internally uses a 8 byte header with length,
> +  * source port, tag, LPA and priority. This is supposedly
> +  * only accessible when operating the switch using the internal
> +  * CPU or with an external CPU mapping the device in, but not
> +  * when operating the switch over SPI and putting frames in/out
> +  * on port 6 (the CPU port). So far we must assume that we
> +  * cannot access the tag. (See "Internal frame header" section
> +  * 3.9.1 in the manual.)

I would be really good if we could get this to work even in SPI with the
CPU controlling the switch, I cannot really think of why the 8051 would
have to be involved, because having the 8051 means either the switch is
entirely standalone and runs off an EEPROM (which is additional cost on
your BOM), or the host, through SPI can entirely take over.

Is the datasheet public somehow?

> +  */
> + return DSA_TAG_PROTO_NONE;
> +}

[snip]

> +static void vsc73xx_adjust_link(struct dsa_switch *ds, int port,
> + struct phy_device *phydev)
> +{
> + struct vsc73xx *vsc = ds->priv;
> + u32 val;

No is_pseudo_fixed_link() check, you really have to do all of this for
each front-panel port? That is really bad if that is the case... most
switches with front-panel built-in PHYs are at the very least capable of
re-con

Re: [OpenWrt-Devel] [Patch][BCM63XX][V2][RFC] Select HW_RANDOM_BCM63XX only in the SoCs that support it.

[Florian Fainelli]

2014-06-30 4:30 GMT-07:00 José Vázquez :
> 2014-06-29 22:45 GMT+02:00, Jonas Gorski :
>> On Sun, Jun 29, 2014 at 10:37 PM, José Vázquez 
>> wrote:
>>> 2014-06-28 19:54 GMT+02:00, Jonas Gorski :

 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
>>
> b43 and b43-legacy drivers enable CONFIG_HW_RANDOM in
> .config.override; without they selected the "problem" does not happen.
> More drivers need HW_RANDOM but they were not selected in my owrt
> config.
>
> define KernelPackage/b43
>   $(call KernelPackage/mac80211/Default)
>   TITLE:=Broadcom 43xx wireless support
>   URL:=http://linuxwireless.org/en/users/Drivers/b43
>   KCONFIG:= \
> CONFIG_HW_RANDOM=y
>
> I have no idea why these drivers enable HW_RANDOM but surely there is
> a good reason.

I think this is just from a time where there was not a package for
HW_RANDOM, you might want to make b43 depend on that specific kmod
package that would be cleaner in any case.

>
> A lot of thanks for your time and guidance.

And thanks for your perseverance, that is much appreciated!
-- 
Florian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 2/4] [rb532] change default package set

[Florian Fainelli]

2014-07-07 13:57 GMT-07:00 Roman Yeryomin :
> On 7 July 2014 11:52, Felix Fietkau  wrote:
>> On 2014-07-05 00:36, Roman Yeryomin wrote:
>>> There could be no wireless interfaces but ethernets are on board.
>>>
>>> Signed-off-by: Roman Yeryomin 
>> Not taking this one. Adding kmod-via-rhine is unnecessary, since the
>> driver is already built into the kernel.
>
> Ok, true... though I don't see the point in keeping wpad and madwifi there.

Could you resubmit with a more recent package set such as wpad-mini
and kmod-ath5k for instance?
-- 
Florian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 2/4] [rb532] change default package set

[Florian Fainelli]

2014-07-08 8:01 GMT-07:00 Roman Yeryomin :
> On 8 July 2014 04:17, Florian Fainelli  wrote:
>> 2014-07-07 13:57 GMT-07:00 Roman Yeryomin :
>>> On 7 July 2014 11:52, Felix Fietkau  wrote:
>>>> On 2014-07-05 00:36, Roman Yeryomin wrote:
>>>>> There could be no wireless interfaces but ethernets are on board.
>>>>>
>>>>> Signed-off-by: Roman Yeryomin 
>>>> Not taking this one. Adding kmod-via-rhine is unnecessary, since the
>>>> driver is already built into the kernel.
>>>
>>> Ok, true... though I don't see the point in keeping wpad and madwifi there.
>>
>> Could you resubmit with a more recent package set such as wpad-mini
>> and kmod-ath5k for instance?
>
> How about just removing wpad and madwifi? I understand that, most
> likely, there will be some wifi card installed but it can be any
> minipci card and some (like me) may not use any wifi cards at all.

How about keeping it? By the time the RB532 was sold, ath5k driven
mini-PCI cards were also sold, so they are likely to be still
installed. Either way, I am fine with nothing, you have already
dictated the use of 'eth0' as a WAN interface, so I guess that's a
fair change.
-- 
Florian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 00/17] atheros: checkpatch fixes

[Florian Fainelli]

On Jul 20, 2014 11:27 AM, "Daniel Gimpelevich" <
dan...@gimpelevich.san-francisco.ca.us> wrote:
>
> On Tue, 2014-06-24 at 13:51 -0700, Florian Fainelli wrote:
> > 2014-06-24 13:30 GMT-07:00 Daniel Gimpelevich
> > :
> > > On Tue, 2014-06-24 at 12:38 -0700, Florian Fainelli wrote:
> > >> I think AR231x has none of those, it's an End of Life platform, the
> > >> code base has been mostly static and well know for a while, so I
would
> > >> argue that Device Tree should not be made a requirement here as it
> > >> will just delay Sergey's upstreaming effort even more.
> > >>
> > > Very valuable input. Still, there is no way for software to determine
> > > which AR231x board it's running on, and they all have different uses
of
> > > GPIO, plus the AR2317 watchdog operates completely differently from
the
> > > AR2315 one. What solution do you propose? Some earlier discussion:
> > > http://patchwork.openwrt.org/patch/4351/
> >
> > For GPIOs, since the way they are used most likely varies on a
> > per-board basis, we could probably come up with the same mechanism as
> > used on ath79 where we end-up patching the kernel command-line to
> > insert a MIPS machine id for instance.
> >
> > For the watchdog driver, if we have access to a revision register we
> > can read at runtime, then we could use a separate platform driver name
> > (e.g: ar2315-wdt vs ar2317-wdt) that would lead to either two separate
> > drivers to get registered, or have different code-paths being used in
> > the same ar231x driver. In case we do not have that revision register,
> > we can leverage solution 1) for GPIOs.
>
> Wait, what is this "ath79" target?

Meant to write ar71xx, the upstream Linux name for it is ath79 from
arch/mips/

> ___
> 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] uClibc-ng

[Florian Fainelli]

Hello,

(adding uclibc and Bernhard)

2014-07-20 12:13 GMT-07:00 Waldemar Brodkorb :
> Hello Embedded Linux Hackers,
>
> it seems there is no plan to release a new uClibc version.
> The current maintainer does not response on any public or private mails
> about a plan to do a needed release. Therefore most of you carrying a lot
> of patches against uClibc 0.9.33.2 to make it work in your project.
> A really ugly situation.

Although I do welcome your action, and stepping in to offer a solution
to this, I feel like forking might have the potential of making this
situation worse, including, but not limited to:

- creating confusion between uclibc and uclibc-ng
- pissing off Bernhard
- duplicating existing infrastructure instead of gaining access to it
- what if you end up in the same situation as uClibc, we all have busy lives?

Thomas and I talked to Khem Raj about this uClibc situation during ELC
back in June, and Khem offered some help to see if we could:

- make Bernhard aware of the lack of release situation
- use his uclibc.org access to facilitate a 0.9.34? release

>
> To get out of this situation I started a spin-off called uClibc-ng.
> The website for the project is here: http://www.uclibc-ng.org
> Beta 3 is tagged and downloadable via
> http://downloads.uclibc-ng.org/uClibc-ng-1.0.0beta3.tar.xz
>
> If you want a 1.0 in the near future please test and report back any
> issues. You can use the bug tracker, the mailing list or dicussion forum
> to report back. To prevent spam you need to be subscribed or registered.
>
> I have added most of the patches from your projects on top of uClibc
> master.
>
> Thanks
>  Waldemar
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel



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

Re: [OpenWrt-Devel] uClibc-ng

[Florian Fainelli]

2014-07-21 11:42 GMT-07:00 Thomas Petazzoni
:
> Dear Florian Fainelli,
>
> On Mon, 21 Jul 2014 11:23:46 -0700, Florian Fainelli wrote:
>
>> 2014-07-20 12:13 GMT-07:00 Waldemar Brodkorb :
>> > Hello Embedded Linux Hackers,
>> >
>> > it seems there is no plan to release a new uClibc version.
>> > The current maintainer does not response on any public or private mails
>> > about a plan to do a needed release. Therefore most of you carrying a lot
>> > of patches against uClibc 0.9.33.2 to make it work in your project.
>> > A really ugly situation.
>>
>> Although I do welcome your action, and stepping in to offer a solution
>> to this, I feel like forking might have the potential of making this
>> situation worse, including, but not limited to:
>>
>> - creating confusion between uclibc and uclibc-ng
>> - pissing off Bernhard
>> - duplicating existing infrastructure instead of gaining access to it
>> - what if you end up in the same situation as uClibc, we all have busy lives?
>>
>> Thomas and I talked to Khem Raj about this uClibc situation during ELC
>> back in June, and Khem offered some help to see if we could:
>>
>> - make Bernhard aware of the lack of release situation
>> - use his uclibc.org access to facilitate a 0.9.34? release
>
> ELC was end of April, early May, and Khem told me he would act with one
> month. I've pinged him several times, and nothing happened. He might
> have been too afraid to piss off Bernhard.
>
> On my side, I fully support Waldemar's fork. The last uClibc release is
> more than 2 years old, and Bernhard has never been answering to *any*
> of the e-mails asking to do a release, sent since September 2013 or so.
> At this point, I think there is absolutely no hope to see any action
> being done by the existing uClibc community in terms of doing stable
> releases, and this case, the lever that open-source licenses provide is
> simple: fork. That's what Waldemar has done, and it's good.

To speak my mind, I think uClibc has no future in the next 2 or 3
years, musl is a much more active project, with multiple embedded
projects starting to use it, on the other end, (e)glibc has remedied
its own problems and its useful again.

No MMU architectures are becoming less and less popular, and the cost
for larger flash storage mediums keeps decreasing, so all these key
selling features (noMMU support and reduced memory footprint) that
uClibc has will soon no longer be any useful to it.

Bottom line is, I believe uClibc is a (relatively speaking) dead
project already, forking it might be useful to keep the existing user
base alive, but I expect all of them to transition to something active
and maintained, whether that's glibc or musl.
--
Florian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] valgrind: add x86_64 support

[Florian Fainelli]

2014-07-29 0:07 GMT-07:00 Alexandru Ardelean :
> ---
>  openwrt/package/devel/valgrind/Makefile | 17 -
>  1 file changed, 12 insertions(+), 5 deletions(-)

Your patch is missing a Signed-off-by tag, other than that, this looks
good to me.

>
> diff --git a/openwrt/package/devel/valgrind/Makefile 
> b/openwrt/package/devel/valgrind/Makefile
> index 6c22348..a55fb40 100644
> --- a/openwrt/package/devel/valgrind/Makefile
> +++ b/openwrt/package/devel/valgrind/Makefile
> @@ -28,7 +28,7 @@ include $(INCLUDE_DIR)/kernel.mk
>  define Package/valgrind
>SECTION:=devel
>CATEGORY:=Development
> -  DEPENDS:=@mips||mipsel||i386||powerpc||arm_v7 +libpthread +librt
> +  DEPENDS:=@mips||mipsel||i386||x86_64||powerpc||arm_v7 +libpthread +librt
>TITLE:=debugging and profiling tools for Linux
>URL:=http://www.valgrind.org
>  endef
> @@ -77,13 +77,20 @@ define Package/valgrind/description
> to speed up and reduce memory use of your programs.
>  endef
>
> -CPU := $(patsubst x86,i386,$(LINUX_KARCH))
> +CPU := $(patsubst x86_64,amd64,$(patsubst x86,i386,$(LINUX_KARCH)))
>
>  CONFIGURE_VARS += \
> UNAME_R=$(LINUX_VERSION)
>
> +ifeq ($(ARCH),x86_64)
> +   BITS := 64bit
> +else
> +   CONFIGURE_ARGS += \
> +   --enable-only32bit
> +   BITS := 32bit
> +endif
> +
>  CONFIGURE_ARGS += \
> -   --enable-only32bit \
> --enable-tls \
> --without-x \
> --without-uiout \
> @@ -101,8 +108,8 @@ define Package/valgrind/install
> $(PKG_INSTALL_DIR)/usr/lib/valgrind/none-* \
> $(PKG_INSTALL_DIR)/usr/lib/valgrind/vgpreload_core*.so \
> $(PKG_INSTALL_DIR)/usr/lib/valgrind/$(CPU)-*.xml \
> -   $(PKG_INSTALL_DIR)/usr/lib/valgrind/32bit-core*.xml \
> -   $(PKG_INSTALL_DIR)/usr/lib/valgrind/32bit-linux*.xml \
> +   $(PKG_INSTALL_DIR)/usr/lib/valgrind/$(BITS)-core*.xml \
> +   $(PKG_INSTALL_DIR)/usr/lib/valgrind/$(BITS)-linux*.xml \
> $(PKG_INSTALL_DIR)/usr/lib/valgrind/memcheck-* \
> $(PKG_INSTALL_DIR)/usr/lib/valgrind/vgpreload_memcheck*.so \
> $(1)/usr/lib/valgrind/
> --
> 1.8.4.5
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

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

Re: [OpenWrt-Devel] Make phy fixups patch generic

[Florian Fainelli]

Hi Sergey,

2014-07-30 15:09 GMT-07:00 Sergey Ryazanov :
> Hello Hauke,
>
> could you move your patch, which fix fixups call [1] from brcm47xx
> target to the generic patches, since mvswitch driver suffers from the
> same problem?
>
> 1. 
> https://dev.openwrt.org/browser/trunk/target/linux/brcm47xx/patches-3.14/960-fix-phy-device.patch

It's fixed upstream now BTW:
http://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit/?id=d92f5dec6325079c550889883af51db1b77d5623

expect a backport to the 3.14 stable tree anytime soon.
--
Florian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 3/3] netifd: GRE tunnel support

[Florian Fainelli]

On 07/30/14 04:56, Hans Dedecker wrote:

Adds support for gre, gretap, grev6 and grev6tap tunnels


This commit breaks the build for earlier kernel versions which do not 
have a bunch of IFLA_IPTUN_* missing constants, could you provide a 
fallback definition for these earlier Linux kernels?


See 
http://buildbot.openwrt.org:8010/builders/adm8668/builds/139/steps/compile_5/logs/stdio

for build failure details.

Thanks!



Signed-off-by: Hans Dedecker 
---
  system-dummy.c |2 +-
  system-linux.c |  190 +---
  system.c   |1 +
  system.h   |3 +-
  tunnel.c   |2 +-
  5 files changed, 186 insertions(+), 12 deletions(-)

diff --git a/system-dummy.c b/system-dummy.c
index 8bcebc1..8e420e1 100644
--- a/system-dummy.c
+++ b/system-dummy.c
@@ -235,7 +235,7 @@ time_t system_get_rtime(void)
return 0;
  }

-int system_del_ip_tunnel(const char *name)
+int system_del_ip_tunnel(const char *name, struct blob_attr *attr)
  {
return 0;
  }
diff --git a/system-linux.c b/system-linux.c
index ea3a138..2d65cef 100644
--- a/system-linux.c
+++ b/system-linux.c
@@ -806,7 +806,7 @@ nla_put_failure:
return -ENOMEM;
  }

-static int system_link_del(struct device *dev)
+static int system_link_del(const char *ifname)
  {
struct nl_msg *msg;
struct ifinfomsg iim = {
@@ -820,13 +820,13 @@ static int system_link_del(struct device *dev)
return -1;

nlmsg_append(msg, &iim, sizeof(iim), 0);
-   nla_put_string(msg, IFLA_IFNAME, dev->ifname);
+   nla_put_string(msg, IFLA_IFNAME, ifname);
return system_rtnl_call(msg);
  }

  int system_macvlan_del(struct device *macvlan)
  {
-   return system_link_del(macvlan);
+   return system_link_del(macvlan->ifname);
  }

  static int system_vlan(struct device *dev, int id)
@@ -912,7 +912,7 @@ nla_put_failure:

  int system_vlandev_del(struct device *vlandev)
  {
-   return system_link_del(vlandev);
+   return system_link_del(vlandev->ifname);
  }

  static void
@@ -1654,9 +1654,173 @@ static int tunnel_ioctl(const char *name, int cmd, void 
*p)
return ioctl(sock_ioctl, cmd, &ifr);
  }

-int system_del_ip_tunnel(const char *name)
+static int system_add_gre_tunnel(const char *name, const char *kind,
+const unsigned int link, struct blob_attr 
**tb, bool v6)
  {
-   return tunnel_ioctl(name, SIOCDELTUNNEL, NULL);
+   struct nl_msg *nlm;
+   struct ifinfomsg ifi = { .ifi_family = AF_UNSPEC, };
+   struct blob_attr *cur;
+   uint32_t ikey = 0, okey = 0;
+   uint16_t iflags = 0, oflags = 0;
+   int ret = 0, ttl = 64;
+
+   nlm = nlmsg_alloc_simple(RTM_NEWLINK, NLM_F_REQUEST | NLM_F_REPLACE | 
NLM_F_CREATE);
+   if (!nlm)
+   return -1;
+
+   nlmsg_append(nlm, &ifi, sizeof(ifi), 0);
+   nla_put_string(nlm, IFLA_IFNAME, name);
+
+   struct nlattr *linkinfo = nla_nest_start(nlm, IFLA_LINKINFO);
+   if (!linkinfo) {
+   ret = -ENOMEM;
+   goto failure;
+   }
+
+   nla_put_string(nlm, IFLA_INFO_KIND, kind);
+   struct nlattr *infodata = nla_nest_start(nlm, IFLA_INFO_DATA);
+   if (!infodata) {
+   ret = -ENOMEM;
+   goto failure;
+   }
+
+   if (link)
+   nla_put_u32(nlm, IFLA_GRE_LINK, link);
+
+   if ((cur = tb[TUNNEL_ATTR_TTL]))
+   ttl = blobmsg_get_u32(cur);
+
+   nla_put_u8(nlm, IFLA_GRE_TTL, ttl);
+
+   if ((cur = tb[TUNNEL_ATTR_INFO]) && (blobmsg_type(cur) == 
BLOBMSG_TYPE_STRING)) {
+   uint8_t icsum, ocsum, iseqno, oseqno;
+   if (sscanf(blobmsg_get_string(cur), "%u,%u,%hhu,%hhu,%hhu,%hhu",
+   &ikey, &okey, &icsum, &ocsum, &iseqno, &oseqno) < 6) {
+   ret = -EINVAL;
+   goto failure;
+   }
+
+   if (ikey)
+   iflags |= GRE_KEY;
+
+   if (okey)
+   oflags |= GRE_KEY;
+
+   if (icsum)
+   iflags |= GRE_CSUM;
+
+   if (ocsum)
+   oflags |= GRE_CSUM;
+
+   if (iseqno)
+   iflags |= GRE_SEQ;
+
+   if (oseqno)
+   oflags |= GRE_SEQ;
+   }
+
+   if (v6) {
+   struct in6_addr in6buf;
+   if ((cur = tb[TUNNEL_ATTR_LOCAL])) {
+   if (inet_pton(AF_INET6, blobmsg_data(cur), &in6buf) < 
1) {
+   ret = -EINVAL;
+   goto failure;
+   }
+   nla_put(nlm, IFLA_GRE_LOCAL, sizeof(in6buf), &in6buf);
+   }
+
+   if ((cur = tb[TUNNEL_ATTR_REMOTE])) {
+   if (inet_pton(AF_INET6, blobmsg_data(cur), &in6buf) < 
1) {
+   ret = -EINVAL;
+  

Re: [OpenWrt-Devel] [PATCH 1/2] ar8216: add new phyid 0x004dd043 (ar8326)

[Florian Fainelli]

On 07/13/14 22:23, Alexander Couzens wrote:

Used in ubiquity nanostation xw boards


Missing Signed-off-by tag, please re-submit, the same applies to your 
second patch in this series.



---
  target/linux/generic/files/drivers/net/phy/ar8216.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/target/linux/generic/files/drivers/net/phy/ar8216.c 
b/target/linux/generic/files/drivers/net/phy/ar8216.c
index fe0ddb9..3846159 100644
--- a/target/linux/generic/files/drivers/net/phy/ar8216.c
+++ b/target/linux/generic/files/drivers/net/phy/ar8216.c
@@ -2800,6 +2800,7 @@ static const u32 ar8xxx_phy_ids[] = {
0x004dd036, /* AR8337 */
0x004dd041,
0x004dd042,
+   0x004dd043, /* AR8236 */
  };

  static bool


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

Re: [OpenWrt-Devel] uClibc

[Florian Fainelli]

On 07/25/14 01:16, smile...@gmail.com wrote:

/lib/ld-uClibc.so.0: No such file or directory


Hallo guys,

have any body a idee for the dependency entry?


Where is that message coming from? The build process; running an 
application on your target? We are missing a lot of context here; please 
mention your target, the OpenWrt revision and branch you are building from.




Is there some were a list with the names of the hole ammount of
librarys?


Everything that is listed in the DEPENDS section of the packages 
installed on your root filesystem will add to the list.

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

Re: [OpenWrt-Devel] [PATCH 3/3] netifd: GRE tunnel support

[Florian Fainelli]

On Aug 5, 2014 12:50 AM, "Steven Barth"  wrote:
>
> To be fair I introduced IFLA_IPTUN_ stuff earlier with MAP-encapsulation
support. My general impression was that we do not care about <3.10 targets
any more.
>
> So even if Hans provides some patches for GRE it will not help much since
MAP-support does the same.

As long as this builds correctly for older kernels, I have no objection.
Whether that means a cmake switch and checking for these constants, or
provide empty stubs of support for GRE in the kernel has not been detected,
either way is fine.

>
>
> Cheers,
>
> Steven
>
> ___
> 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 3/3] netifd: GRE tunnel support

[Florian Fainelli]

Hi Steven,

On 08/06/2014 04:27 AM, Steven Barth wrote:
> Hi Florian,
> 
> I pushed a netifd revision 77a865b5b3ac476e05ff80f3c10d86686285c0da
> which disables
> ds-lite, map and gre using ifdefs if IFLA_IPTUN_MAX is not defined in
> the kernel headers.
> 
> Could you please check if that does the trick for you (note: I did not
> bump the netifd-Makefile in trunk yet)?

This works like a charm, can you bump the version in trunk and
barrier_breaker?

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

Re: [OpenWrt-Devel] Moving all feeds to OpenWrt GitHub organisation

[Florian Fainelli]

Hello,

Le 10 août 2014 09:44, "Etienne Champetier" 
a écrit :
>
>
> Le 10 août 2014 18:18, "Stefan Monnier"  a
écrit :
>
> >
> > > It would be great to have all feeds in one place, on GitHub.
> >
> > I think making oneself dependent upon a commercial company
> > without paying it (i.e. without leverage) would be a mistake.
> >
> >
> > Stefan
>
> We use git, the day github closes, or asks for money, or ..., we move. We
dont depend on github, we use it while it's there (and free).
> In the mean time it helps getting the job done
>
> Also paying is no leverage, a contract can be but there are always half
million clauses, and in the worst case scenario they pay you one month back

We already have an infrastructure deployed which is much wider than the
services offered by github. Surely we had our own administrative issues
with those machines but they have been sorted now and the process is much
stronger.

At this point, I don't think we would be getting any advantage of using a
3rd party service, but that's just me.

>
> Etienne
>
>
> ___
> 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 2/4] lantiq: export soc type

[Florian Fainelli]

On 08/11/2014 04:59 AM, Álvaro Fernández Rojas wrote:
> Signed-off-by: Álvaro Fernández Rojas 
> ---
> diff --git 
> a/target/linux/lantiq/patches-3.10/0209-lantiq-export-soc-type.patch 
> b/target/linux/lantiq/patches-3.10/0209-lantiq-export-soc-type.patch
> new file mode 100644
> index 000..cb0a559
> --- /dev/null
> +++ b/target/linux/lantiq/patches-3.10/0209-lantiq-export-soc-type.patch
> @@ -0,0 +1,25 @@
> +--- a/arch/mips/include/asm/mach-lantiq/lantiq.h
>  b/arch/mips/include/asm/mach-lantiq/lantiq.h
> +@@ -48,6 +48,8 @@ extern struct clk *clk_get_ppe(void);
> + extern unsigned char ltq_boot_select(void);
> + /* find out what caused the last cpu reset */
> + extern int ltq_reset_cause(void);
> ++/* find out the soc type */
> ++extern int ltq_soc_type(void);
> + 
> + #define IOPORT_RESOURCE_START   0x1000
> + #define IOPORT_RESOURCE_END 0x
> +--- a/arch/mips/lantiq/prom.c
>  b/arch/mips/lantiq/prom.c
> +@@ -35,6 +35,11 @@ const char *get_system_type(void)
> + return soc_info.sys_type;
> + }
> + 
> ++int ltq_soc_type(void)
> ++{
> ++return soc_info.type;
> ++}

You might want to have an EXPORT_SYMBOL() for this function such that it
can be used in modules too.

> ++
> + void prom_free_prom_memory(void)
> + {
> + }
> ___
> 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] kernel module runtime configuration

[Florian Fainelli]

Hello Brent,

On 08/14/2014 03:45 PM, Brent Thomson wrote:
> Hey all. I'm working on my first Linux kernel module. It's an
> adaptation of an hd44780-over-GPIO driver. You can see it here:
> 
> https://github.com/brnt/openwrt-hd44780
> 
> The driver is working fine, but I'd like to allow the user to
> configure which GPIOs are used by the driver. Rather than hard-coding
> the values in the C file (as they're currently done) I'd prefer to
> read values from a config file (or the equivalent). Is there a best
> practice for doing this at the kernel level module? In my googling,
> I've seen comments indicating that reading from files at the kernel
> level is a no-no? I'd prefer not to have to pass commands to insmod
> and instead allow a static file (potentially managed by uci). What's
> the right way to do this?

I believe configfs is the prefered interface for specifying such a
configuration. You could take a look at
target/linux/generic/patches-3.10/863-gpiommc.patch to see how you can
leverage this.
--
Florian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] at91: USB gadget cleanup

[Florian Fainelli]

Hi Owen,

On 08/18/2014 10:48 AM, Owen Kirby wrote:
> It's been a while since I submitted this to the mailing list. Has anyone
> had an opportunity to take a look at this patch? Anything I can do to
> help move it forward?

I have placed it in patchwork as "Under review", will probably get it
committed soon since it looks good to me.

Thanks!

> 
> Thanks,
> Owen
> 
> On 14-06-11 02:38 PM, Owen Kirby wrote:
>> The AT91 family of SoCs have a USB device controller, this patch
>> should enable the feature
>> and cleanup the default config of the at91 target to play nicely with
>> the gadget modules.
>>
>> kmod-usb-eth-gadget is added as a default module to retain the same
>> board functionality as
>> before this patch, though, the 'debug' network interface in the
>> default config is rather
>> useless.
>>
>> Signed-off-by: Owen Kirby 
>> ---
>> diff --git a/target/linux/at91/Makefile b/target/linux/at91/Makefile
>> index 8340d2a..9aed19f 100644
>> --- a/target/linux/at91/Makefile
>> +++ b/target/linux/at91/Makefile
>> @@ -10,13 +10,13 @@ ARCH:=arm
>>  BOARD:=at91
>>  MAINTAINER:=Claudio Mignanti 
>>  BOARDNAME:=Atmel AT91
>> -FEATURES:=squashfs targz ext2 usb
>> +FEATURES:=squashfs targz ext2 usb usbgadget ubifs
>>  CPU_TYPE:=arm926ej-s
>>
>>  LINUX_VERSION:=3.10.36
>>
>>  include $(INCLUDE_DIR)/target.mk
>>
>> -DEFAULT_PACKAGES += kmod-usb-ohci
>> +DEFAULT_PACKAGES += kmod-usb-ohci kmod-at91-udc kmod-usb-eth-gadget
>>
>>  $(eval $(call BuildTarget))
>> diff --git a/target/linux/at91/config-default
>> b/target/linux/at91/config-default
>> index e1c90a1..8281458 100644
>> --- a/target/linux/at91/config-default
>> +++ b/target/linux/at91/config-default
>> @@ -236,13 +236,7 @@ CONFIG_UID16=y
>>  CONFIG_UIDGID_CONVERTED=y
>>  CONFIG_UNCOMPRESS_INCLUDE="mach/uncompress.h"
>>  # CONFIG_USB_ARCH_HAS_XHCI is not set
>> -CONFIG_USB_AT91=y
>>  CONFIG_USB_COMMON=y
>> -CONFIG_USB_ETH=y
>> -# CONFIG_USB_ETH_EEM is not set
>> -CONFIG_USB_ETH_RNDIS=y
>> -CONFIG_USB_GADGET=y
>> -CONFIG_USB_LIBCOMPOSITE=y
>>  CONFIG_USB_SUPPORT=y
>>  CONFIG_USE_OF=y
>>  CONFIG_VECTORS_BASE=0x
>> diff --git a/target/linux/at91/modules.mk b/target/linux/at91/modules.mk
>> index 4678b92..9e82efc 100644
>> --- a/target/linux/at91/modules.mk
>> +++ b/target/linux/at91/modules.mk
>> @@ -50,6 +50,20 @@ endef
>>
>>  $(eval $(call KernelPackage,at91-adc))
>>
>> +define KernelPackage/at91-udc
>> +  SUBMENU:=$(USB_MENU)
>> +  TITLE:=USB Device on atmel SoC
>> +  DEPENDS:=@TARGET_at91 +kmod-usb-gadget
>> +  KCONFIG:=CONFIG_USB_AT91
>> +  FILES:=$(LINUX_DIR)/drivers/usb/gadget/at91_udc.ko
>> +  AUTOLOAD:=$(call AutoLoad,51,at91_udc)
>> +endef
>> +
>> +define KernelPackage/at91-udc/description
>> + Kernel module for the USB Device controller for Atmel AT91
>> +endef
>> +
>> +$(eval $(call KernelPackage,at91-udc))
>>
>>  I2C_AT91_MODULES:=\
>>CONFIG_I2C_AT91:drivers/i2c/busses/i2c-at91
>>
> ___
> 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] Fix VLAN on Atheros AR8327N

[Florian Fainelli]

On 08/31/2014 10:42 AM, Jiri Pirko wrote:
> Sat, Jul 19, 2014 at 09:49:38PM CEST, nolt...@gmail.com wrote:
>> Commit 40842 reverted the fix for tagged+untagged VLANs on AR8327:
>> https://dev.openwrt.org/changeset/40777
>> https://dev.openwrt.org/changeset/40842
>>
>> According to jow, some people experienced some "issues" on older devices. 
>> Can anyone tell me what were those issues?
>>
>> Anyway, that patch modified some parts of the ar8216/ar8236, so I suppose 
>> any device with those switches were affected.
>> However, I've modified the patch keeping the ar8216/ar8236 as much untouched 
>> as possible.
>> Could anyone test it on those devices?
>>
>> BTW, this works for me on a TP-Link WDR4300 (ar8327).
> 
> 
> I tested the patch on TL-WR1043ND v2 with Atheros AR8327 rev. 4. Vlans
> are working as expected. Please include this into BB (might need repost)
> 
> Thanks!
> 
> Tested-by: Jiri Pirko 

Unless there are further objections, we should probably just go ahead
and apply this patch since it affects a bunch of users.

> 
> 
>>
>> Signed-off-by: Saverio Proto 
>> Signed-off-by: Álvaro Fernández 
>> ---
>> diff --git a/target/linux/generic/files/drivers/net/phy/ar8216.c 
>> b/target/linux/generic/files/drivers/net/phy/ar8216.c
>> index 3846159..9eae624 100644
>> --- a/target/linux/generic/files/drivers/net/phy/ar8216.c
>> +++ b/target/linux/generic/files/drivers/net/phy/ar8216.c
>> @@ -78,7 +78,7 @@ struct ar8xxx_chip {
>>  u32 (*read_port_status)(struct ar8xxx_priv *priv, int port);
>>  int (*atu_flush)(struct ar8xxx_priv *priv);
>>  void (*vtu_flush)(struct ar8xxx_priv *priv);
>> -void (*vtu_load_vlan)(struct ar8xxx_priv *priv, u32 vid, u32 port_mask);
>> +void (*vtu_load_vlan)(struct ar8xxx_priv *priv, u32 vlan);
>>
>>  const struct ar8xxx_mib_desc *mib_decs;
>>  unsigned num_mibs;
>> @@ -112,7 +112,12 @@ struct ar8327_led {
>>  enum ar8327_led_pattern pattern;
>> };
>>
>> +struct ar8216_data {
>> +u8 vlan_tagged;
>> +};
>> +
>> struct ar8327_data {
>> +u8 vlan_tagged[AR8X16_MAX_VLANS];
>>  u32 port0_status;
>>  u32 port6_status;
>>
>> @@ -138,6 +143,7 @@ struct ar8xxx_priv {
>>  u8 chip_rev;
>>  const struct ar8xxx_chip *chip;
>>  union {
>> +struct ar8216_data ar8216;
>>  struct ar8327_data ar8327;
>>  } chip_data;
>>  bool initialized;
>> @@ -159,7 +165,6 @@ struct ar8xxx_priv {
>>  bool vlan;
>>  u16 vlan_id[AR8X16_MAX_VLANS];
>>  u8 vlan_table[AR8X16_MAX_VLANS];
>> -u8 vlan_tagged;
>>  u16 pvid[AR8X16_MAX_PORTS];
>>
>>  /* mirroring */
>> @@ -641,7 +646,7 @@ ar8216_mangle_rx(struct net_device *dev, struct sk_buff 
>> *skb)
>>  port = buf[0] & 0xf;
>>
>>  /* no need to fix up packets coming from a tagged source */
>> -if (priv->vlan_tagged & (1 << port))
>> +if (priv->chip_data.ar8216.vlan_tagged & BIT(port))
>>  return;
>>
>>  /* lookup port vid from local table, the switch passes an invalid vlan 
>> id */
>> @@ -695,10 +700,13 @@ ar8216_vtu_flush(struct ar8xxx_priv *priv)
>> }
>>
>> static void
>> -ar8216_vtu_load_vlan(struct ar8xxx_priv *priv, u32 vid, u32 port_mask)
>> +ar8216_vtu_load_vlan(struct ar8xxx_priv *priv, u32 vlan)
>> {
>>  u32 op;
>>
>> +u32 vid = priv->vlan_id[vlan];
>> +u32 port_mask = priv->vlan_table[vlan];
>> +
>>  op = AR8216_VTU_OP_LOAD | (vid << AR8216_VTU_VID_S);
>>  ar8216_vtu_op(priv, op, port_mask);
>> }
>> @@ -1705,12 +1713,16 @@ ar8327_vtu_flush(struct ar8xxx_priv *priv)
>> }
>>
>> static void
>> -ar8327_vtu_load_vlan(struct ar8xxx_priv *priv, u32 vid, u32 port_mask)
>> +ar8327_vtu_load_vlan(struct ar8xxx_priv *priv, u32 vlan)
>> {
>>  u32 op;
>>  u32 val;
>>  int i;
>>
>> +u32 vid = priv->vlan_id[vlan];
>> +u32 port_mask = priv->vlan_table[vlan];
>> +u32 tagged = priv->chip_data.ar8327.vlan_tagged[vlan];
>> +
>>  op = AR8327_VTU_FUNC1_OP_LOAD | (vid << AR8327_VTU_FUNC1_VID_S);
>>  val = AR8327_VTU_FUNC0_VALID | AR8327_VTU_FUNC0_IVL;
>>  for (i = 0; i < AR8327_NUM_PORTS; i++) {
>> @@ -1720,7 +1732,7 @@ ar8327_vtu_load_vlan(struct ar8xxx_priv *priv, u32 
>> vid, u32 port_mask)
>>  mode = AR8327_VTU_FUNC0_EG_MODE_NOT;
>>  else if (priv->vlan == 0)
>>  mode = AR8327_VTU_FUNC0_EG_MODE_KEEP;
>> -else if (priv->vlan_tagged & BIT(i))
>> +else if (tagged & BIT(i))
>>  mode = AR8327_VTU_FUNC0_EG_MODE_TAG;
>>  else
>>  mode = AR8327_VTU_FUNC0_EG_MODE_UNTAG;
>> @@ -1734,26 +1746,22 @@ static void
>> ar8327_setup_port(struct ar8xxx_priv *priv, int port, u32 egress, u32 
>> ingress,
>>u32 members, u32 pvid)
>> {
>> -u32 t;
>> -u32 mode;
>> +u32 mode, t;
>> +
>> +if (priv->vlan) {
>> +pvid = priv->vlan_id[priv->pvid[port]];
>> +mode = AR8327_PORT_VLAN1_OUT_MODE_UNMOD;
>> +ingress = AR8

Re: [OpenWrt-Devel] [PATCH] [kernel/brcm2708] fix for raspberry pi b+

[Florian Fainelli]

On 09/25/14 06:54, Morris Winkler wrote:

I attached a fix for package/kernel/brcm2708-gpu-fw/  that i diffed against 
14.07 from git.openwrt.org

it just patches the Makefile to download a newer source revision from 
https://github.com/Hexxeh/rpi-firmware/archive/


i tested that on a raspberry pi b and a b+, i don't have a "a" version here, 
but i am very confident it will boot too.


Applied a slightly more up to date firmware in r42676, thanks!




Cherrs

Morris Winkler









Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I
have the right to submit it under the open source license
indicated in the file; or

(b) The contribution is based upon previous work that, to the best
of my knowledge, is covered under an appropriate open source
license and I have the right under that license to submit that
work with modifications, whether created in whole or in part
by me, under the same open source license (unless I am
permitted to submit under a different license), as indicated
in the file; or

(c) The contribution was provided directly to me by some other
person who certified (a), (b) or (c) and I have not modified
it.

(d) I understand and agree that this project and the contribution
are public and that a record of the contribution (including all
personal information I submit with it, including my sign-off) is
maintained indefinitely and may be redistributed consistent with
this project or the open source license(s) involved.

Signed-off-by: Morris Winkler 



___
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] some questions/observations about building qemu/malta image

[Florian Fainelli]

Hello,

(short emails for separate issues do help BTW)

On 09/29/2014 03:32 PM, Robert P. J. Day wrote:
> 
>   a few questions about things i ran into today trying to build a qemu
> malta image using the latest git checkout of openwrt -- some are
> admittedly trivial, i just want to make sure i'm understanding
> everything related to them. i started with the config.malta_le config
> file downloaded from openwrt.org.
> 
>   first, i'm aware that trying to run the pre-built qemu image from
> downloads.openwrt.org will fail with a kernel panic, as explained
> here:
> 
>   http://wiki.openwrt.org/doc/howto/qemu#openwrt.in.qemu.mips

And as explained in the ticket, get an updated qemu binary to fix that
problem.

> 
> so during configuration, i deselected MIPS16 support. i'm not really
> familiar with the MIPS architecture but, as i read it, that support is
> really just an optimization so i can do away with it, yes?

MIPS16 allows compressing instructions, which are usually 32-bits, into
16-bits, increasing cache usage etc...

> 
>   next, haven't done this yet but to save piles of time, i'm going to
> deselect all config settings of the form:
> 
>   CONFIG_PACKAGE_...=m
> 
> as i understand it, those selections represent packages that will be
> compiled and packaged, but not built into the final rootfs. and, just
> to be clear, while such a final image might be deficient in all sorts
> of features, it should still *theoretically* boot, which is all i care
> about right now.

Correct.

> 
>   next issue i ran into was this (which looks like a real bug):
> 
> make[4]: Entering directory
> '/home/rpjday/openwrt/qemu_malta/build_dir/target-mipsel_mips32_uClibc-0.9.33.2/dump1090-2014-08-22'
> mipsel-openwrt-linux-uclibc-gcc -Os -pipe -mno-branch-likely -mips32
> -mtune=mips32 -fno-caller-saves -fhonour-copts
> -Wno-error=unused-but-set-variable -msoft-float -mips16
> -minterlink-mips16  -c dump1090.c
> In file included from dump1090.c:31:0:
> dump1090.h:60:25: fatal error: rtl-sdr.h: No such file or directory
>  #include "rtl-sdr.h"
>  ^
> compilation terminated.
> Makefile:21: recipe for target 'dump1090.o' failed
> make[4]: *** [dump1090.o] Error 1
> 
>   not sure what to make of that ... i checked under the build dir and
> there is such a header file at this location:
> 
> $ find build_dir/ -name rtl-sdr.h
> build_dir/target-mipsel_mips32_uClibc-0.9.33.2/dump1090-2014-08-22/rtlsdr/rtl-sdr.h
> $
> 
> is this a known issue? for now, i'll get around it by just
> deselecting the dump1090 package but that shouldn't be necessary.
> should i file a bug report on this?

This is a not a known issue, but really, that's not a necessary package
at all for testing purposes and going to a shell, why not just compile
it out for now?

> 
>   another issue was one i ran into before and that i reported here:
> 
> https://github.com/openwrt/packages/issues/296
> 
> a bit later this evening, i'll try applying the patch mentioned there.
> does anyone have any further info on this bug?
> 
>  finally (and this one is a bit weird), i was trying all of the above
> at a site where the corp firewall did not allow numerous fetching
> protocols, including git, ftp and wget, but i had most of the tarballs
> i needed already so i figured i was in good shape.  not so, it turns
> out.
> 
>   partway through the build, building gcc just hung, and i tracked it
> down to this:
> 
> $ vi 
> build_dir/mipsel_mips32_uClibc-0.9.33.2/gcc-4.8.3/contrib/download_prerequisites
> 
> MPFR=mpfr-2.4.2
> GMP=gmp-4.3.2
> MPC=mpc-0.8.1
> 
> wget ftp://gcc.gnu.org/pub/gcc/infrastructure/$MPFR.tar.bz2 || exit 1
> tar xjf $MPFR.tar.bz2 || exit 1
> ln -sf $MPFR mpfr || exit 1
> ... snip ...
> 
>   argh. so, as i read it, there is no way to preload tarballs to get
> around the above, is there? configuring gcc above *requires* net
> access, is that correct?

We should not be executing that make target in the contrib directory, it
sounds highly bogus and we already provide mpfr as a build
pre-requisite, I can take a look at this later though.

> 
>   anyway, feel free to comment on any of the above. thanks.
> 
> rday
> 
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] support for D-Link DNS-320 NAS (Marvell Kirkwood)

[Florian Fainelli]

On 10/05/14 13:32, Tivadar Szemethy wrote:

Hello,

I have created a github fork (
https://github.com/szemtiv/openwrt-dns320.git ) that adds support
(selectable as a profile from Marvell Kirkwood) for the DNS-320 NAS.
Apart from some trivial stuff (based on existing support fot other
Kirkwoods), it has a patch for u-boot, and an userland daemon (scraped
from various parts of the net, with acknowledgements) that controls
the DNS-320 fan in a separate package within Utils.


Could you submit what's missing in the current OpenWrt trunk?

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

Re: [OpenWrt-Devel] ffmpeg on au1500 --disable-mips32r2

[Florian Fainelli]

2014-10-13 9:16 GMT-07:00 Dirk Neukirchen :
> On 13.10.2014 17:55, Bruno Randolf wrote:
>> Hello again,
>>
>> ffmpeg tries to automatically enable optimizations for the MIPS
>> platform, but for au1500 it automatically enables mips32r2, which this
>> CPU does not support.
>>
>> For now, I could fix the problem by adding --disable-mips32r2 to
>> FFMPEG_CONFIGURE, but again, this is probably not the correct solution
>> for all platforms. How should it be done right?
>>
> use appropriate .config symbols (dunno which is the right one) and add 
> something like
>
> $(if $(CONFIG_TARGET_au1000),--disable-mips32r2)

I would test for CPU_TYPE instead of the target, since au1000 is not
the only one we support which is mips32r1 only. So something like:

$(ifeq $(CONFIG_CPU_TYPE),"mips32",--disable-mips32r2) would probably
work just fine. Anything that is mips32r2 sets a different CPU_TYPE,
such as 24kec+dsp, 34kc, 74k or even mips32r2.
-- 
Florian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] [PATCH V2] [boot] /init: allow easier customisation of ramfs boot.

[Florian Fainelli]

2014-10-13 12:44 GMT-07:00 John Crispin :
>
> On 13/10/2014 00:03, Stephen Parry wrote:
>> /init is the first pid 1 process in an initramfs environment. This fix adds
>> lines to check for the existence of /bin/ramfsinit or /sbin/ramfsinit and 
>> exec
>> if present. This allows packages to switch root early in the boot process. 
>> This
>> will help support booting or kexecing from external storage and go some way
>> toward fixing ticket #17465.
>
>
> the ticket says extroot fails for !mtd. please elaborate on that. i
> would rather we fix extroot to handle this use case rather than build a
> way to bypass extroot

Agreed, should not we standardize on /linuxrc instead of ramfsinit,
even though that is an initramfs, people might get confused even more
with this custom script name.

>
>
>
>
>
>
>> Signed-off-by: Stephen Parry 
>> ---
>> V2: Improved script structure using elif
>> ---
>>  target/linux/generic/base-files/init | 9 -
>>  1 file changed, 8 insertions(+), 1 deletion(-)
>>
>> diff --git a/target/linux/generic/base-files/init 
>> b/target/linux/generic/base-files/init
>> index 514be57..e80b324 100755
>> --- a/target/linux/generic/base-files/init
>> +++ b/target/linux/generic/base-files/init
>> @@ -1,4 +1,11 @@
>>  #!/bin/sh
>>  # Copyright (C) 2006 OpenWrt.org
>>  export INITRAMFS=1
>> -exec /sbin/init
>> +
>> +if [ -e /bin/ramfsinit ]; then
>> + exec /bin/ramfsinit
>> +elif [ -e /sbin/ramfsinit ]; then
>> + exec /sbin/ramfsinit
>> +else
>> + exec /sbin/init
>> +fi
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

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

Re: [OpenWrt-Devel] cyassl is causing build errors

[Florian Fainelli]

2014-10-13 0:20 GMT-07:00 Alive4Ever :
> I've experienced many build errors on bb-14.07 because of cyassl.

Is there a build log somewhere that shows these build failures or is
just download issues at this point?

>
> For your information, cyassl can't be downloaded directly from its
> official site. There is a form that needs to be filled before Wolfssl
> allows downloading of cyassl-3.2.0.zip. Any attemt to download cyassl
> directly will cause redirection to html download form here.
>
> http://wolfssl.com/yaSSL/download/downloadForm.php
>
> To simplify the download process, I suggest preparing pre-downloaded
> cyassl source on OpenWrt mirror and modifying PKG_SOURCE_URL accordingly
> and removing http://www.yassl.com from PKG_SOURCE_URL.

I am not seeing any checkbox for downloading cyassl-3.2.0.zip per se,
so I don't know whether this is a bug on their form, their form is
there because of the cryptography software restrictions that apply to
exporting such technology to other countries.

IANAL, but this export compliance restriction is not necessarily in
contradiction with GPLv2, so it is not as simple as putting their zip
archive on downloads.openwrt.org, by the same token, the agreement
button is about GPLv2, not the export compliance, so we might be just
fine after all with offering an alternate download method.
-- 
Florian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] [kernel] kernel: add missing symbols for 3.14

[Florian Fainelli]

On 10/14/2014 03:59 AM, John Crispin wrote:
> these should really go into the at91 config file. the CONFIG_AT91_*
> ones for sure but most likely also the others.

The others seems like candidate for the generic kernel config to me,
since they are shared by more than one ARM platform.

earlyprintk on ARM is kind of a pita though since you always need to
select which UART implementation/location you want, maybe we should just
remove the earlyprintk selection for ARM entirely.

> 
> 
> 
> 
> On 11/10/2014 07:51, John Szakmeister wrote:
>> --- Without these, my earlyprintk configuration was being lost.
>>
>> -John
>>
>> target/linux/generic/config-3.14 | 5 + 1 file changed, 5
>> insertions(+)
>>
>> diff --git a/target/linux/generic/config-3.14
>> b/target/linux/generic/config-3.14 index 830efff..5f16281 100644 
>> --- a/target/linux/generic/config-3.14 +++
>> b/target/linux/generic/config-3.14 @@ -240,6 +240,8 @@
>> CONFIG_ARPD=y # CONFIG_ASYNC_TX_DMA is not set #
>> CONFIG_AT76C50X_USB is not set # CONFIG_AT803X_PHY is not set +#
>> CONFIG_AT91_DEBUG_LL_DBGU0 is not set +# CONFIG_AT91_DEBUG_LL_DBGU1
>> is not set # CONFIG_ATA is not set # CONFIG_ATAGS is not set 
>> CONFIG_ATAGS_PROC=y @@ -770,6 +772,9 @@ CONFIG_DEBUG_KERNEL=y #
>> CONFIG_DEBUG_KOBJECT_RELEASE is not set # CONFIG_DEBUG_LIST is not
>> set # CONFIG_DEBUG_LL is not set +# CONFIG_DEBUG_LL_UART_8250 is
>> not set +# CONFIG_DEBUG_LL_UART_NONE is not set +#
>> CONFIG_DEBUG_LL_UART_PL01X is not set # CONFIG_DEBUG_LOCKDEP is not
>> set # CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set #
>> CONFIG_DEBUG_LOCK_ALLOC is not set
>>
> ___
> 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