date:20180403

[LEDE-DEV] [PATCH] kernel: bump kernel 4.4 to 4.4.126 for 17.01

2018-04-03 Thread Stijn Segers

* Refreshed patches

Compile-tested: ar71xx, ramips/mt7621, x86/64
Run-tested: ar71xx

Signed-off-by: Stijn Segers 
---
 include/kernel-version.mk  |  4 ++--
 ...onvert-IDE-trigger-to-common-disk-trigger.patch |  2 +-
 ...-add-a-round-up-ability-to-the-clock-divi.patch |  6 ++---
 ...cm2835-Support-for-clock-parent-selection.patch |  8 +++
 .../0254-clk-bcm2835-Add-PWM-clock-support.patch   |  2 +-
 ...-correctly-enable-fractional-clock-suppor.patch |  6 ++---
 ...-clk-bcm2835-clean-up-coding-style-issues.patch |  4 ++--
 ...35-expose-raw-clock-registers-via-debugfs.patch | 14 +--
 ...-remove-use-of-BCM2835_CLOCK_COUNT-in-dri.patch |  4 ++--
 ...-reorganize-bcm2835_clock_array-assignmen.patch |  4 ++--
 ...lk-bcm2835-enable-management-of-PCM-clock.patch |  2 +-
 ...lk-bcm2835-add-missing-PLL-clock-dividers.patch |  4 ++--
 ...lk-bcm2835-add-missing-osc-and-per-clocks.patch | 12 +-
 ...lk-bcm2835-Mark-the-VPU-clock-as-critical.patch |  4 ++--
 ...-Mark-GPIO-clocks-enabled-at-boot-as-crit.patch |  4 ++--
 ...-Skip-PLLC-clocks-when-deciding-on-a-new-.patch |  4 ++--
 ...-Mark-the-CM-SDRAM-clock-s-parent-as-crit.patch |  6 ++---
 ...-Don-t-rate-change-PLLs-on-behalf-of-divi.patch |  2 +-
 ...-Do-appropriate-name-lookups-for-DSI1-s-p.patch |  6 ++---
 ...2835-Add-an-enum-for-the-DSI1-pixel-clock.patch |  8 +++
 ...-Clamp-the-PLL-s-requested-rate-to-the-ha.patch |  2 +-
 ...clk-bcm2835-Fix-fixed_divider-of-pllh_aux.patch |  2 +-
 ...port-rate-change-propagation-on-bcm2835-c.patch |  6 ++---
 ...ow-rate-change-propagation-to-PLLH_AUX-on.patch |  2 +-
 ...-maybe-uninitialized-warning-in-bcm2835_c.patch |  2 +-
 ...-Don-t-rate-change-PLLs-on-behalf-of-DSI-.patch | 28 +++---
 .../generic/patches-4.4/834-ledtrig-libata.patch   |  8 +++
 ...c-Segregate-IFC-fcm-and-runtime-registers.patch | 20 
 ...-pci-layerscape-add-MSI-interrupt-support.patch |  2 +-
 ...4-use-fixmap-region-for-permanent-FDT-map.patch |  9 ---
 ...0074-mtd-nand-import-nand_hw_control_init.patch |  2 +-
 .../linux/oxnas/patches-4.4/999-libata-hacks.patch |  4 ++--
 32 files changed, 98 insertions(+), 95 deletions(-)

diff --git a/include/kernel-version.mk b/include/kernel-version.mk
index deb13a6a82..ccffa7aa0e 100644
--- a/include/kernel-version.mk
+++ b/include/kernel-version.mk
@@ -3,10 +3,10 @@
 LINUX_RELEASE?=1
 
 LINUX_VERSION-3.18 = .43
-LINUX_VERSION-4.4 = .124
+LINUX_VERSION-4.4 = .126
 
 LINUX_KERNEL_HASH-3.18.43 = 
1236e8123a6ce537d5029232560966feed054ae31776fe8481dd7d18cdd5492c
-LINUX_KERNEL_HASH-4.4.124 = 
59341c0af64bf0e2ba6f5305bff564286c228755827b8bebd002a9db2abc2129
+LINUX_KERNEL_HASH-4.4.126 = 
e9c8f4c4cda89124e7c53bda979db3f9c12f7c177bee90ddd3ab38d5ae99cd58
 
 ifdef KERNEL_PATCHVER
   LINUX_VERSION:=$(KERNEL_PATCHVER)$(strip $(LINUX_VERSION-$(KERNEL_PATCHVER)))
diff --git 
a/target/linux/apm821xx/patches-4.4/040-backport_leds-convert-IDE-trigger-to-common-disk-trigger.patch
 
b/target/linux/apm821xx/patches-4.4/040-backport_leds-convert-IDE-trigger-to-common-disk-trigger.patch
index 7cce9bc77f..6441866806 100644
--- 
a/target/linux/apm821xx/patches-4.4/040-backport_leds-convert-IDE-trigger-to-common-disk-trigger.patch
+++ 
b/target/linux/apm821xx/patches-4.4/040-backport_leds-convert-IDE-trigger-to-common-disk-trigger.patch
@@ -47,7 +47,7 @@ Signed-off-by: Jacek Anaszewski 
  #include 
  #include 
  
-@@ -4915,6 +4916,9 @@ void ata_qc_complete(struct ata_queued_c
+@@ -4936,6 +4937,9 @@ void ata_qc_complete(struct ata_queued_c
  {
struct ata_port *ap = qc->ap;
  
diff --git 
a/target/linux/brcm2708/patches-4.4/0252-clk-bcm2835-add-a-round-up-ability-to-the-clock-divi.patch
 
b/target/linux/brcm2708/patches-4.4/0252-clk-bcm2835-add-a-round-up-ability-to-the-clock-divi.patch
index b9b139ce9b..d9e82c78d2 100644
--- 
a/target/linux/brcm2708/patches-4.4/0252-clk-bcm2835-add-a-round-up-ability-to-the-clock-divi.patch
+++ 
b/target/linux/brcm2708/patches-4.4/0252-clk-bcm2835-add-a-round-up-ability-to-the-clock-divi.patch
@@ -16,7 +16,7 @@ Signed-off-by: Michael Turquette 
 
 --- a/drivers/clk/bcm/clk-bcm2835.c
 +++ b/drivers/clk/bcm/clk-bcm2835.c
-@@ -1166,22 +1166,24 @@ static int bcm2835_clock_is_on(struct cl
+@@ -1170,22 +1170,24 @@ static int bcm2835_clock_is_on(struct cl
  
  static u32 bcm2835_clock_choose_div(struct clk_hw *hw,
unsigned long rate,
@@ -49,7 +49,7 @@ Signed-off-by: Michael Turquette 
  
/* clamp to min divider of 1 */
div = max_t(u32, div, 1 << CM_DIV_FRAC_BITS);
-@@ -1221,7 +1223,7 @@ static long bcm2835_clock_round_rate(str
+@@ -1225,7 +1227,7 @@ static long bcm2835_clock_round_rate(str
 unsigned long *parent_rate)
  {
struct bcm2835_clock *clock = bcm2835_clock_from_hw(hw);
@@ -58,7 +58,7 @@ Signed-off-by: Michael Turquette

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

2018-04-03 Thread 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 = <>;

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

>   };
> 
>  {
>   status = "okay";
>   mtd-mac-address = < 0xf100>;
>   pinctrl-names = "default";
>   pinctrl-0 = <_pins _pins _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(>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

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] [PATCH v2] kernel: rtl8366-smi: add Realtek switch management via mii-bus

2018-04-03 Thread Сергей Василюгин

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 = <>;
};

 {
status = "okay";
mtd-mac-address = < 0xf100>;
pinctrl-names = "default";
pinctrl-0 = <_pins _pins _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 
--

diff --git a/target/linux/generic/files/drivers/net/phy/rtl8366_smi.c 
b/target/linux/generic/files/drivers/net/phy/rtl8366_smi.c
index ae04597..c190ebc 100644
--- a/target/linux/generic/files/drivers/net/phy/rtl8366_smi.c
+++ b/target/linux/generic/files/drivers/net/phy/rtl8366_smi.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -198,7 +199,7 @@ static int rtl8366_smi_read_byte1(struct rtl8366_smi *smi, 
u8 *data)
return 0;
 }
 
-int rtl8366_smi_read_reg(struct rtl8366_smi *smi, u32 addr, u32 *data)
+static int __rtl8366_smi_read_reg(struct rtl8366_smi *smi, u32 addr, u32 *data)
 {
unsigned long flags;
u8 lo = 0;
@@ -239,6 +240,101 @@ int rtl8366_smi_read_reg(struct rtl8366_smi *smi, u32 
addr, u32 *data)
 
return ret;
 }
+/* Read/write via mdiobus */
+#define MDC_MDIO_CTRL0_REG 31
+#define MDC_MDIO_START_REG 29
+#define MDC_MDIO_CTRL1_REG 21
+#define MDC_MDIO_ADDRESS_REG   23
+#define MDC_MDIO_DATA_WRITE_REG24
+#define MDC_MDIO_DATA_READ_REG 25
+
+#define MDC_MDIO_START_OP  0x
+#define MDC_MDIO_ADDR_OP   0x000E
+#define MDC_MDIO_READ_OP   0x0001
+#define MDC_MDIO_WRITE_OP  0x0003
+#define MDC_REALTEK_PHY_ADDR   0x0
+
+int __rtl8366_mdio_read_reg(struct rtl8366_smi *smi, u32 addr, u32 *data)
+{
+   u32 phy_id = MDC_REALTEK_PHY_ADDR;
+   struct mii_bus *mbus = smi->ext_mbus;
+
+   BUG_ON(in_interrupt());
+
+   mutex_lock(>mdio_lock);
+   /* Write Start command to register 29 */
+   mbus->write(mbus, phy_id, MDC_MDIO_START_REG, MDC_MDIO_START_OP);
+
+   /* Write address control code to register 31 */
+   mbus->write(mbus, phy_id, MDC_MDIO_CTRL0_REG, MDC_MDIO_ADDR_OP);
+
+   /* Write Start command to register 29 */
+   mbus->write(mbus, phy_id, MDC_MDIO_START_REG, MDC_MDIO_START_OP);
+
+   /* Write address to register 23 */
+   mbus->write(mbus, phy_id, MDC_MDIO_ADDRESS_REG, addr);
+
+   /* Write Start command to register 29 */
+   mbus->write(mbus, phy_id, MDC_MDIO_START_REG, MDC_MDIO_START_OP);
+
+   /* Write read control code to register 21 */
+   mbus->write(mbus, phy_id, MDC_MDIO_CTRL1_REG, MDC_MDIO_READ_OP);
+
+   /* Write Start command to register 29 */
+   mbus->write(smi->ext_mbus, phy_id, MDC_MDIO_START_REG, 
MDC_MDIO_START_OP);
+
+   /* Read data from register 25 */
+   *data = mbus->read(mbus, phy_id, MDC_MDIO_DATA_READ_REG);
+
+   mutex_unlock(>mdio_lock);
+
+   return 0;
+}
+
+static int __rtl8366_mdio_write_reg(struct rtl8366_smi *smi, u32 addr, u32 
data)
+{
+   u32 phy_id = MDC_REALTEK_PHY_ADDR;
+   struct mii_bus *mbus = smi->ext_mbus;
+
+   BUG_ON(in_interrupt());
+
+   mutex_lock(>mdio_lock);
+
+   /* Write Start command to register 29 */
+   mbus->write(mbus, phy_id, MDC_MDIO_START_REG, MDC_MDIO_START_OP);
+
+   /* Write address control code to register 31 */
+   mbus->write(mbus, phy_id, MDC_MDIO_CTRL0_REG, MDC_MDIO_ADDR_OP);
+
+   /* Write Start command to register 29 */
+   mbus->write(mbus, phy_id, MDC_MDIO_START_REG, MDC_MDIO_START_OP);
+
+   /* Write address to register 23 */
+   mbus->write(mbus, phy_id, MDC_MDIO_ADDRESS_REG, addr);
+
+   /* Write Start command to register 29 */
+   mbus->write(mbus, phy_id, MDC_MDIO_START_REG, MDC_MDIO_START_OP);
+
+   /* Write data to register 24 */
+   mbus->write(mbus, phy_id, MDC_MDIO_DATA_WRITE_REG, data);
+
+   /* Write Start command to register 29 */
+   mbus->write(mbus, phy_id, MDC_MDIO_START_REG, MDC_MDIO_START_OP);
+
+   /* Write data control code to register 21 */
+   mbus->write(mbus, phy_id, MDC_MDIO_CTRL1_REG, MDC_MDIO_WRITE_OP);
+
+   mutex_unlock(>mdio_lock);
+   return 0;
+}
+
+int rtl8366_smi_read_reg(struct rtl8366_smi *smi, u32 addr, u32 *data)
+{
+if(smi->ext_mbus)
+   return

Re: [LEDE-DEV] [PATCH 03/12] uboot-at91: fetch uboot src from u-boot-at91 github

2018-04-03 Thread SandeepSheriker.Mallikarjun

Hi,
  Yes its pre patched. Contains new boards and latest changes which will be 
mainlined.

Regards,
Sandeep Sheriker M 

> -Original Message-
> From: John Crispin [mailto:j...@phrozen.org]
> Sent: Monday, April 2, 2018 10:19 PM
> To: Sandeep Sheriker Mallikarjun - C17018
> ; lede-
> d...@lists.infradead.org
> Subject: Re: [LEDE-DEV] [PATCH 03/12] uboot-at91: fetch uboot src from u-
> boot-at91 github
> 
> 
> 
> On 02/04/18 18:34, Sandeep Sheriker Mallikarjun wrote:
> > fetching uboot src from linux4sam/u-boot-at91 github for all at91
> > target.
> >
> > Signed-off-by: Sandeep Sheriker Mallikarjun
> > 
> 
> Hi,
> Whats the difference between these uboots ? I am guessing its pre-patched
> ?
>      John
> > ---
> >   package/boot/uboot-at91/Makefile | 17 +++--
> >   1 file changed, 11 insertions(+), 6 deletions(-)
> >
> > diff --git a/package/boot/uboot-at91/Makefile
> > b/package/boot/uboot-at91/Makefile
> > index cad12ec..27b113e 100644
> > --- a/package/boot/uboot-at91/Makefile
> > +++ b/package/boot/uboot-at91/Makefile
> > @@ -7,10 +7,12 @@
> >
> >   include $(TOPDIR)/rules.mk
> >
> > -PKG_VERSION:=2016.05
> > +PKG_VERSION:=linux4sam_5.8
> >   PKG_RELEASE:=1
> >
> > -
> PKG_HASH:=87d02275615aaf0cd007b54cbe9fbadceef2bee7c79e6c323ea1ae8
> 956d
> > cb171
> > +PKG_SOURCE_PROTO:=git
> > +PKG_SOURCE_URL:=https://github.com/linux4sam/u-boot-at91.git
> > +PKG_SOURCE_VERSION:=59f202622154f82e708a6ca2bf86350a5c1b2d33
> >
> >   include $(INCLUDE_DIR)/u-boot.mk
> >   include $(INCLUDE_DIR)/package.mk
> > @@ -30,7 +32,9 @@ endef
> >   define U-Boot/at91sam9x5ek_nandflash
> > NAME:=AT91SAM9X5-EK board (NandFlash)
> > BUILD_SUBTARGET:=legacy
> > -  BUILD_DEVICES:=at91sam9g15ek at91sam9g25ek at91sam9g35ek
> > at91sam9x25ek at91sam9x35ek
> > +  BUILD_DEVICES:=at91sam9g15ek at91sam9g25ek \
> > + at91sam9g35ek at91sam9x25ek \
> > +at91sam9x35ek
> >   endef
> >
> >   define U-Boot/sama5d3_xplained_nandflash @@ -87,9 +91,10 @@
> > UBOOT_TARGETS := \
> > sama5d4_xplained_nandflash
> >
> >   define Build/Compile
> > -   +$(MAKE) $(PKG_JOBS) -C $(PKG_BUILD_DIR) \
> > -   CROSS_COMPILE=$(TARGET_CROSS) \
> > -   KCFLAGS="$(filter-out -fstack-protector -mfloat-abi=hard,
> $(TARGET_CFLAGS)) -mfloat-abi=soft"
> > +  +$(MAKE) $(PKG_JOBS) -C $(PKG_BUILD_DIR) \
> > + CROSS_COMPILE=$(TARGET_CROSS) \
> > + KCFLAGS="$(filter-out -fstack-protector \
> > +  -mfloat-abi=hard, $(TARGET_CFLAGS)) -mfloat-abi=soft"
> >   endef
> >
> >   $(eval $(call BuildPackage/U-Boot))

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] [PATCHv2] firewall: fix logging of dropped & rejected packets

2018-04-03 Thread Alin Nastac

From: Alin Nastac 

Reproduction scenario:
 - use 3 interfaces with 3 different zones - lan, wan and guest
 - configure firewall to allow forwarding from lan to wan
 - add DROP rule to prevent forwarding from lan to guest
 - although packets are forwarded from lan to wan, "DROP(dest guest)"
 traces are generated by zone_guest_dest_DROP chain

Signed-off-by: Alin Nastac 
---
 zones.c | 72 ++---
 1 file changed, 60 insertions(+), 12 deletions(-)

diff --git a/zones.c b/zones.c
index e00d527..9f00aca 100644
--- a/zones.c
+++ b/zones.c
@@ -20,6 +20,8 @@
 #include "ubus.h"
 #include "helpers.h"
 
+#define filter_target(t) \
+   ((t == FW3_FLAG_REJECT) ? "reject" : fw3_flag_names[t])
 
 #define C(f, tbl, tgt, fmt) \
{ FW3_FAMILY_##f, FW3_TABLE_##tbl, FW3_FLAG_##tgt, fmt }
@@ -401,6 +403,19 @@ print_zone_chain(struct fw3_ipt_handle *handle, struct 
fw3_state *state,
set(zone->flags, handle->family, handle->table);
 }
 
+static const char*
+jump_target(enum fw3_flag t, bool src, struct fw3_zone *zone, char *buf, 
size_t size)
+{
+   if ((zone->log & FW3_ZONE_LOG_FILTER) && t > FW3_FLAG_ACCEPT)
+   {
+   snprintf(buf, size, "%s_%s_%s", fw3_flag_names[t],
+   src ? "src" : "dest", zone->name);
+   return buf;
+   }
+
+   return filter_target(t);
+}
+
 static void
 print_interface_rule(struct fw3_ipt_handle *handle, struct fw3_state *state,
 bool reload, struct fw3_zone *zone,
@@ -420,9 +435,6 @@ print_interface_rule(struct fw3_ipt_handle *handle, struct 
fw3_state *state,
"forward", "FORWARD",
};
 
-#define jump_target(t) \
-   ((t == FW3_FLAG_REJECT) ? "reject" : fw3_flag_names[t])
-
if (handle->table == FW3_TABLE_FILTER)
{
for (t = FW3_FLAG_ACCEPT; t <= FW3_FLAG_DROP; t++)
@@ -430,7 +442,7 @@ print_interface_rule(struct fw3_ipt_handle *handle, struct 
fw3_state *state,
if (has(zone->flags, handle->family, 
fw3_to_src_target(t)))
{
r = fw3_ipt_rule_create(handle, NULL, dev, 
NULL, sub, NULL);
-   fw3_ipt_rule_target(r, jump_target(t));
+   fw3_ipt_rule_target(r, jump_target(t, true, 
zone, buf, sizeof(buf)));
fw3_ipt_rule_extra(r, zone->extra_src);
 
if (t == FW3_FLAG_ACCEPT && 
!state->defaults.drop_invalid)
@@ -455,7 +467,7 @@ print_interface_rule(struct fw3_ipt_handle *handle, struct 
fw3_state *state,
}
 
r = fw3_ipt_rule_create(handle, NULL, NULL, 
dev, NULL, sub);
-   fw3_ipt_rule_target(r, jump_target(t));
+   fw3_ipt_rule_target(r, jump_target(t, false, 
zone, buf, sizeof(buf)));
fw3_ipt_rule_extra(r, zone->extra_dest);
fw3_ipt_rule_replace(r, "zone_%s_dest_%s", 
zone->name,
 fw3_flag_names[t]);
@@ -503,7 +515,7 @@ print_interface_rule(struct fw3_ipt_handle *handle, struct 
fw3_state *state,
{
if (zone->log & FW3_ZONE_LOG_MANGLE)
{
-   snprintf(buf, sizeof(buf) - 1, "MSSFIX(%s): ", 
zone->name);
+   snprintf(buf, sizeof(buf), "MSSFIX(%s): ", 
zone->name);
 
r = fw3_ipt_rule_create(handle, , NULL, 
dev, NULL, sub);
fw3_ipt_rule_addarg(r, false, "--tcp-flags", 
"SYN,RST");
@@ -640,30 +652,46 @@ print_zone_rule(struct fw3_ipt_handle *handle, struct 
fw3_state *state,
{
if (has(zone->flags, handle->family, 
fw3_to_src_target(t)))
{
+   fw3_ipt_create_chain(handle, 
"%s_src_%s",
+fw3_flag_names[t], 
zone->name);
+
r = fw3_ipt_rule_new(handle);
 
-   snprintf(buf, sizeof(buf) - 1, "%s(src 
%s)",
+   snprintf(buf, sizeof(buf), "%s(src %s)",
 fw3_flag_names[t], zone->name);
 
fw3_ipt_rule_limit(r, >log_limit);
fw3_ipt_rule_target(r, "LOG");
fw3_ipt_rule_addarg(r, false, 
"--log-prefix", buf);
-   fw3_ipt_rule_append(r, "zone_%s_src_%s",
-   zone->name, 
fw3_flag_names[t]);

Re: [LEDE-DEV] [PATCH] firewall: fix logging of dropped & rejected packets

2018-04-03 Thread Alin Năstac

Hi Jo,

The idea is to fix log issues created by chains such as these:
iptables -S zone_lan_forward
-A zone_lan_forward -m comment --comment "!fw3: user chain for
forwarding" -j forwarding_lan_rule
-A zone_lan_forward -m comment --comment "!fw3: drop_lan_2_guest" -j
zone_guest_dest_DROP
-A zone_lan_forward -m comment --comment "!fw3: Default action for
outgoing NAT" -j zone_wan_dest_ACCEPT
-A zone_lan_forward -m comment --comment "!fw3: forwarding lan -> wan"
-j zone_wan_dest_ACCEPT
-A zone_lan_forward -m conntrack --ctstate DNAT -m comment --comment
"!fw3: Accept port forwards" -j ACCEPT
-A zone_lan_forward -m comment --comment "!fw3" -j zone_lan_dest_ACCEPT
iptables -S zone_guest_dest_DROP
-A zone_guest_dest_DROP -m limit --limit 5/min -m comment --comment
"!fw3" -j LOG --log-prefix "DROP(dest guest)"
-A zone_guest_dest_DROP -o br-guest -m comment --comment "!fw3" -j DROP

As you can see, packets forwarded from lan to wan will also pass
zone_guest_dest_DROP which will generate traces such as these:
[17091.072000] DROP(dest guest)IN=br-lan OUT=pppoe-wan
MAC=a4:91:b1:46:44:6e:30:91:8f:f7:e5:e5:08:00 SRC=192.168.1.105
DST=83.170.84.172 LEN=52 TOS=0x00 PREC=0x00 TTL=127 ID=20150 DF
PROTO=TCP SPT=53122 DPT=80 WINDOW=8192 RES=0x00 SYN URGP=0 MARK=0x9800

To do that I had to unify the LOG and DROP targets in a new chain
called DROP_dest_guest. These types of chains are created only when
necessary, i.e. when zone has log=1. Here is an example of how such
chains are created:
iptables -S zone_wan_dest_DROP
-A zone_wan_dest_DROP -o pppoe-wan -m comment --comment "!fw3" -j DROP_dest_wan
iptables -S DROP_dest_wan
-A DROP_dest_wan -m limit --limit 10/sec -m comment --comment "!fw3"
-j LOG --log-prefix "DROP(dest wan)"
-A DROP_dest_wan -m comment --comment "!fw3" -j DROP

BR,
Alin

On Tue, Apr 3, 2018 at 3:44 PM, Jo-Philipp Wich  wrote:
> Hi Alin,
>
> thanks for the patch.
>
> Unfortunately it definitely is too big for a simple "fix logging". Will
> take a deeper look at it later but from a first glance it does a few
> unrelated changes, renames chains and has some minor style deviations.
>
> Regards,
> Jo

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] libjson-c: Update to 0.13

2018-04-03 Thread Alexandru Ardelean

On Tue, Apr 3, 2018 at 4:33 PM, Karl Palsson  wrote:
>
> Alexandru Ardelean  wrote:
>> On Sat, Mar 31, 2018 at 9:45 AM, Hans Dedecker
>>  wrote:
>> > On Sat, Mar 31, 2018 at 12:25 AM, Rosen Penev  wrote:
>> >> From: Daniel Engberg 
>> >>
>> >> Update (lib)json-c to 0.13
>> > What are the changes?
>> > Is there any size increase ?
>> > Please be a bit more verbose in the git commit description
>> >
>>
>> From me, this is a NAK.
>> See https://github.com/lede-project/source/pull/1575
>>
>> The size increase is reasonably big [percentage-wise +30%, even
>> though the lib is small]. 0.13 adds a few new features, but
>> nothing that is of interest to OpenWrt. The set of features in
>> 0.12 is sufficient for now.
>
> And fixes a pile of bugs, and improves performance :)

Not sure about performance, but I agree on the bugs part.

>
> Please remember that this library is heavily used by packages
> too, not just the ones in core. Yes, it's bigger, but hey, linux
> 4.14 is bigger than linux 4.9 too.

I agree on the linux 4.14 vs 4.9 size increase, but I would not use it
as an argument.
OpenWrt has also run on systems with 2 MB of flash, which is why it's
interesting to have disable flags for whatever is possible.
Or create libjson-c variants [libjson-c-tiny, libjson-c-full].
That may work for both core & packages.

>
>> What would be interesting in 0.13 or later, is to have disable
>> flags, to keep it slim. And maybe switch to cmake, since it's
>> better supported, and preferred [by various users of
>> libjson-c]. Maybe once we have the disable flags, then it would
>> be fine to upgrade.
>
> cmake better supported what? Upstream's "how to build"
> documentation doesn't even _mention_ cmake. The extended docs say
> that cmake is there for win32.

tbh, i did not check the docs about cmake;
i built libjson-c with cmake on my linux desktop a while back; not on
OpenWrt though ;
i also had to push some fixes for linux though:
https://github.com/json-c/json-c/pull/321/files
https://github.com/json-c/json-c/pull/329/files

I'd say, cmake is better supported in 0.13 vs 0.12.
But it's fine if we don't agree here :)

>
> Cheers,
> Karl P

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] kernel: update kernel 4.14 to 4.14.32

2018-04-03 Thread Koen Vandeputte


Tested-by: Koen Vandeputte 

Targets: cns3xxx, imx6


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] firewall: fix logging of dropped & rejected packets

2018-04-03 Thread Jo-Philipp Wich

Hi Alin,

thanks for the patch.

Unfortunately it definitely is too big for a simple "fix logging". Will
take a deeper look at it later but from a first glance it does a few
unrelated changes, renames chains and has some minor style deviations.

Regards,
Jo

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] libjson-c: Update to 0.13

2018-04-03 Thread Karl Palsson


Alexandru Ardelean  wrote:
> On Sat, Mar 31, 2018 at 9:45 AM, Hans Dedecker
>  wrote:
> > On Sat, Mar 31, 2018 at 12:25 AM, Rosen Penev  wrote:
> >> From: Daniel Engberg 
> >>
> >> Update (lib)json-c to 0.13
> > What are the changes?
> > Is there any size increase ?
> > Please be a bit more verbose in the git commit description
> >
> 
> From me, this is a NAK.
> See https://github.com/lede-project/source/pull/1575
> 
> The size increase is reasonably big [percentage-wise +30%, even
> though the lib is small]. 0.13 adds a few new features, but
> nothing that is of interest to OpenWrt. The set of features in
> 0.12 is sufficient for now.

And fixes a pile of bugs, and improves performance :)

Please remember that this library is heavily used by packages
too, not just the ones in core. Yes, it's bigger, but hey, linux
4.14 is bigger than linux 4.9 too.

> What would be interesting in 0.13 or later, is to have disable
> flags, to keep it slim. And maybe switch to cmake, since it's
> better supported, and preferred [by various users of
> libjson-c]. Maybe once we have the disable flags, then it would
> be fine to upgrade.

cmake better supported what? Upstream's "how to build"
documentation doesn't even _mention_ cmake. The extended docs say
that cmake is there for win32.

Cheers,
Karl P

signature.html
Description: OpenPGP Digital Signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] [PATCH] firewall: fix logging of dropped & rejected packets

2018-04-03 Thread Alin Nastac

Reproduction scenario:
 - use 3 interfaces with 3 different zones - lan, wan and guest
 - configure firewall to allow forwarding from lan to wan
 - add DROP rule to prevent forwarding from lan to guest
 - although packets are forwarded from lan to wan, "DROP(dest guest)"
 traces are generated by zone_guest_dest_DROP chain

Signed-off-by: Alin Nastac 
---
 zones.c | 74 ++---
 1 file changed, 62 insertions(+), 12 deletions(-)

diff --git a/zones.c b/zones.c
index e00d527..1f55aa6 100644
--- a/zones.c
+++ b/zones.c
@@ -20,6 +20,8 @@
 #include "ubus.h"
 #include "helpers.h"
 
+#define filter_target(t) \
+   ((t == FW3_FLAG_REJECT) ? "reject" : fw3_flag_names[t])
 
 #define C(f, tbl, tgt, fmt) \
{ FW3_FAMILY_##f, FW3_TABLE_##tbl, FW3_FLAG_##tgt, fmt }
@@ -401,6 +403,19 @@ print_zone_chain(struct fw3_ipt_handle *handle, struct 
fw3_state *state,
set(zone->flags, handle->family, handle->table);
 }
 
+static const char*
+jump_target(enum fw3_flag t, bool src, struct fw3_zone *zone, char *buf, 
size_t size)
+{
+   if ((zone->log & FW3_ZONE_LOG_FILTER) && t > FW3_FLAG_ACCEPT)
+   {
+   snprintf(buf, size, "%s_%s_%s", fw3_flag_names[t],
+   src ? "src" : "dest", zone->name);
+   return buf;
+   }
+
+   return filter_target(t);
+}
+
 static void
 print_interface_rule(struct fw3_ipt_handle *handle, struct fw3_state *state,
 bool reload, struct fw3_zone *zone,
@@ -420,9 +435,6 @@ print_interface_rule(struct fw3_ipt_handle *handle, struct 
fw3_state *state,
"forward", "FORWARD",
};
 
-#define jump_target(t) \
-   ((t == FW3_FLAG_REJECT) ? "reject" : fw3_flag_names[t])
-
if (handle->table == FW3_TABLE_FILTER)
{
for (t = FW3_FLAG_ACCEPT; t <= FW3_FLAG_DROP; t++)
@@ -430,7 +442,7 @@ print_interface_rule(struct fw3_ipt_handle *handle, struct 
fw3_state *state,
if (has(zone->flags, handle->family, 
fw3_to_src_target(t)))
{
r = fw3_ipt_rule_create(handle, NULL, dev, 
NULL, sub, NULL);
-   fw3_ipt_rule_target(r, jump_target(t));
+   fw3_ipt_rule_target(r, jump_target(t, true, 
zone, buf, sizeof(buf)));
fw3_ipt_rule_extra(r, zone->extra_src);
 
if (t == FW3_FLAG_ACCEPT && 
!state->defaults.drop_invalid)
@@ -455,7 +467,7 @@ print_interface_rule(struct fw3_ipt_handle *handle, struct 
fw3_state *state,
}
 
r = fw3_ipt_rule_create(handle, NULL, NULL, 
dev, NULL, sub);
-   fw3_ipt_rule_target(r, jump_target(t));
+   fw3_ipt_rule_target(r, jump_target(t, false, 
zone, buf, sizeof(buf)));
fw3_ipt_rule_extra(r, zone->extra_dest);
fw3_ipt_rule_replace(r, "zone_%s_dest_%s", 
zone->name,
 fw3_flag_names[t]);
@@ -503,7 +515,7 @@ print_interface_rule(struct fw3_ipt_handle *handle, struct 
fw3_state *state,
{
if (zone->log & FW3_ZONE_LOG_MANGLE)
{
-   snprintf(buf, sizeof(buf) - 1, "MSSFIX(%s): ", 
zone->name);
+   snprintf(buf, sizeof(buf), "MSSFIX(%s): ", 
zone->name);
 
r = fw3_ipt_rule_create(handle, , NULL, 
dev, NULL, sub);
fw3_ipt_rule_addarg(r, false, "--tcp-flags", 
"SYN,RST");
@@ -640,30 +652,46 @@ print_zone_rule(struct fw3_ipt_handle *handle, struct 
fw3_state *state,
{
if (has(zone->flags, handle->family, 
fw3_to_src_target(t)))
{
+   fw3_ipt_create_chain(handle, 
"%s_src_%s",
+fw3_flag_names[t], 
zone->name);
+
r = fw3_ipt_rule_new(handle);
 
-   snprintf(buf, sizeof(buf) - 1, "%s(src 
%s)",
+   snprintf(buf, sizeof(buf), "%s(src %s)",
 fw3_flag_names[t], zone->name);
 
fw3_ipt_rule_limit(r, >log_limit);
fw3_ipt_rule_target(r, "LOG");
fw3_ipt_rule_addarg(r, false, 
"--log-prefix", buf);
-   fw3_ipt_rule_append(r, "zone_%s_src_%s",
-   zone->name, 
fw3_flag_names[t]);
+

[LEDE-DEV] [PATCH 3/3] intel-microcode: create early load microcode image

2018-04-03 Thread Tomasz Maciej Nowak

Create initrd image with packed microcode. This'll allow to load it at
early boot stage. Unfortunately the package can't install files directly
to /boot directory, therefore additional installation hooks are placed
for standalone package and when building directly into target image.

Signed-off-by: Tomasz Maciej Nowak 
---
 package/firmware/intel-microcode/Makefile | 32 +--
 target/linux/x86/image/Makefile   |  6 ++
 2 files changed, 32 insertions(+), 6 deletions(-)

diff --git a/package/firmware/intel-microcode/Makefile 
b/package/firmware/intel-microcode/Makefile
index d2663bb901..9970f8f072 100644
--- a/package/firmware/intel-microcode/Makefile
+++ b/package/firmware/intel-microcode/Makefile
@@ -35,15 +35,35 @@ define Package/intel-microcode
 endef
 
 define Build/Compile
-   IUCODE_TOOL=$(STAGING_DIR)/../host/bin/iucode_tool $(MAKE) -C 
$(PKG_BUILD_DIR)
-   mkdir $(PKG_BUILD_DIR)/intel-ucode
-   $(STAGING_DIR)/../host/bin/iucode_tool -q \
-   --write-firmware=$(PKG_BUILD_DIR)/intel-ucode 
$(PKG_BUILD_DIR)/$(MICROCODE).bin
+   IUCODE_TOOL=$(STAGING_DIR)/../host/bin/iucode_tool \
+   $(MAKE) -C $(PKG_BUILD_DIR)
+   $(STAGING_DIR)/../host/bin/iucode_tool -q --mini-earlyfw \
+   --write-earlyfw=$(PKG_BUILD_DIR)/intel-ucode.cpio \
+   $(PKG_BUILD_DIR)/$(MICROCODE).bin
 endef
 
 define Package/intel-microcode/install
-   $(INSTALL_DIR) $(1)/lib/firmware/intel-ucode
-   $(INSTALL_DATA) $(PKG_BUILD_DIR)/intel-ucode/* 
$(1)/lib/firmware/intel-ucode
+   $(INSTALL_DIR) $(1)/lib/firmware
+   $(INSTALL_DATA) $(PKG_BUILD_DIR)/intel-ucode.cpio \
+   $(1)/lib/firmware/intel-ucode.img
+endef
+
+ifeq ($(CONFIG_PACKAGE_intel-microcode),m)
+define Package/intel-microcode/postinst
+#!/bin/sh
+
+mount /boot -o remount,rw,noatime
+cp -f /lib/firmware/intel-ucode.img /boot/
+mount /boot -o remount,ro,noatime
+endef
+endif
+
+define Package/intel-microcode/prerm
+#!/bin/sh
+
+mount /boot -o remount,rw,noatime
+rm /boot/intel-ucode.img
+mount /boot -o remount,ro,noatime
 endef
 
 $(eval $(call BuildPackage,intel-microcode))
diff --git a/target/linux/x86/image/Makefile b/target/linux/x86/image/Makefile
index a05f4babd9..4d6a3016d2 100644
--- a/target/linux/x86/image/Makefile
+++ b/target/linux/x86/image/Makefile
@@ -83,6 +83,9 @@ ifneq ($(CONFIG_GRUB_IMAGES),)
-e 's#@TIMEOUT@#$(GRUB_TIMEOUT)#g' \
-e 's#@ROOT@#$(GRUB_ROOT)#g' \
./grub.cfg > $(KDIR)/root.grub/boot/grub/grub.cfg
+ifeq ($(CONFIG_PACKAGE_intel-microcode),y)
+   $(CP) $(STAGING_DIR)/root-x86/lib/firmware/intel-ucode.img 
$(KDIR)/root.grub/boot/
+endif
PADDING="$(CONFIG_TARGET_IMAGES_PAD)" SIGNATURE="$(SIGNATURE)" 
PATH="$(TARGET_PATH)" $(SCRIPT_DIR)/gen_image_generic.sh \
$(BIN_DIR)/$(IMG_PREFIX)-combined-$(1).img \
$(CONFIG_TARGET_KERNEL_PARTSIZE) $(KDIR)/root.grub \
@@ -120,6 +123,9 @@ define Image/Build/iso
-e 's#@CMDLINE@#root=/dev/sr0 rootfstype=iso9660 rootwait 
$(strip $(call Image/cmdline/$(1)) $(BOOTOPTS) $(GRUB_CONSOLE_CMDLINE))#g' \
-e 's#@TIMEOUT@#$(GRUB_TIMEOUT)#g' \
./grub-iso.cfg > $(KDIR)/root.grub/boot/grub/grub.cfg
+  ifeq ($(CONFIG_PACKAGE_intel-microcode),y)
+   $(CP) $(STAGING_DIR)/root-x86/lib/firmware/intel-ucode.img 
$(KDIR)/root.grub/boot/
+  endif
mkisofs -R -b boot/grub/eltorito.img -no-emul-boot -boot-info-table \
-o $(KDIR)/root.iso $(KDIR)/root.grub $(TARGET_DIR)
 endef
-- 
2.16.3


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] [PATCH 2/3] x86: add intel microcode entries to grub config

2018-04-03 Thread Tomasz Maciej Nowak

Create initrd enries for x86 images, that'll load intel microcode as
early as possible. Also restrict the late load of microcode to AMD
processors.

Signed-off-by: Tomasz Maciej Nowak 
---
 target/linux/x86/base-files/lib/preinit/02_load_x86_ucode | 6 --
 target/linux/x86/image/Makefile   | 4 ++--
 target/linux/x86/image/grub-iso.cfg   | 3 +++
 target/linux/x86/image/grub.cfg   | 3 +++
 4 files changed, 12 insertions(+), 4 deletions(-)

diff --git a/target/linux/x86/base-files/lib/preinit/02_load_x86_ucode 
b/target/linux/x86/base-files/lib/preinit/02_load_x86_ucode
index fb309c75c1..68ebdf8651 100644
--- a/target/linux/x86/base-files/lib/preinit/02_load_x86_ucode
+++ b/target/linux/x86/base-files/lib/preinit/02_load_x86_ucode
@@ -2,8 +2,10 @@
 # Copyright (C) 2018 OpenWrt.org
 
 do_load_x86_ucode() {
-   if [ -e "/sys/devices/system/cpu/microcode/reload" ]; then
-   echo 1 > /sys/devices/system/cpu/microcode/reload
+   if [ "$(grep -c AuthenticAMD /proc/cpuinfo)" -gt "0" ]; then
+   if [ -e "/sys/devices/system/cpu/microcode/reload" ]; then
+   echo 1 > /sys/devices/system/cpu/microcode/reload
+   fi
fi
 }
 
diff --git a/target/linux/x86/image/Makefile b/target/linux/x86/image/Makefile
index 8a3cb327e3..a05f4babd9 100644
--- a/target/linux/x86/image/Makefile
+++ b/target/linux/x86/image/Makefile
@@ -9,8 +9,8 @@ include $(INCLUDE_DIR)/image.mk
 
 export PATH=$(TARGET_PATH):/sbin
 
-GRUB2_MODULES = biosdisk boot chain configfile ext2 linux ls part_msdos reboot 
serial vga
-GRUB2_MODULES_ISO = biosdisk boot chain configfile iso9660 linux ls part_msdos 
reboot serial vga
+GRUB2_MODULES = biosdisk boot chain configfile ext2 linux ls part_msdos reboot 
serial test vga
+GRUB2_MODULES_ISO = biosdisk boot chain configfile iso9660 linux ls part_msdos 
reboot serial test vga
 GRUB_TERMINALS =
 GRUB_SERIAL_CONFIG =
 GRUB_TERMINAL_CONFIG =
diff --git a/target/linux/x86/image/grub-iso.cfg 
b/target/linux/x86/image/grub-iso.cfg
index 3d47a95a4b..30b587bd1c 100644
--- a/target/linux/x86/image/grub-iso.cfg
+++ b/target/linux/x86/image/grub-iso.cfg
@@ -7,4 +7,7 @@ set root='(cd)'
 
 menuentry "OpenWrt" {
linux /boot/vmlinuz @CMDLINE@ noinitrd
+   if [ -e /boot/intel-ucode.img ]; then
+   initrd /boot/intel-ucode.img
+   fi
 }
diff --git a/target/linux/x86/image/grub.cfg b/target/linux/x86/image/grub.cfg
index 9ec6b2d39c..dde24b95ce 100644
--- a/target/linux/x86/image/grub.cfg
+++ b/target/linux/x86/image/grub.cfg
@@ -7,6 +7,9 @@ set root='(@ROOT@)'
 
 menuentry "OpenWrt" {
linux /boot/vmlinuz @CMDLINE@ noinitrd
+   if [ -e /boot/intel-ucode.img ]; then
+   initrd /boot/intel-ucode.img
+   fi
 }
 menuentry "OpenWrt (failsafe)" {
linux /boot/vmlinuz failsafe=true @CMDLINE@ noinitrd
-- 
2.16.3


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] [PATCH 1/3] intel-microcode: remove dependency on iucode-tool

2018-04-03 Thread Tomasz Maciej Nowak

It is not necessary to have iucode-tool present on target system to have
functional intel-microcode package. The build time dependency is kept.

Signed-off-by: Tomasz Maciej Nowak 
---
 package/firmware/intel-microcode/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/package/firmware/intel-microcode/Makefile 
b/package/firmware/intel-microcode/Makefile
index 1b7288fc14..d2663bb901 100644
--- a/package/firmware/intel-microcode/Makefile
+++ b/package/firmware/intel-microcode/Makefile
@@ -30,7 +30,7 @@ define Package/intel-microcode
   SECTION:=firmware
   CATEGORY:=Firmware
   URL:=$(PKG_SOURCE_URL)
-  DEPENDS:=@TARGET_x86 +iucode-tool
+  DEPENDS:=@TARGET_x86
   TITLE:=Intel x86 CPU microcode
 endef
 
-- 
2.16.3


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] [RFC PATCH 0/3] intel-microcode: load as early as possible

2018-04-03 Thread Tomasz Maciej Nowak

This small series addresses current problem with late loading of Intel
microcode in OpenWrt. Following the commit messages [1] and later
discussion, late loading off the microcode can be ineffective for some
processors [2] and for others disabled [3]. Also it is discouraged for
any processor starting from Haswell and Silvermont.
Therefore this series converts the Intel microcode bundle to an initial
ram disk which is loaded with grub, so kernel has access to it as early
as possible.

1. https://lwn.net/Articles/530346
2. 
http://linux-kernel.vger.kernel.narkive.com/9XAb9Kw2/patch-v4-00-11-x86-microcode-early-load-microcode#post18
3. 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=723f2828a98c8ca19842042f418fb30dd8cfc0f7

Tomasz Maciej Nowak (3):
  intel-microcode: remove dependency on iucode-tool
  x86: add intel microcode entries to grub config
  intel-microcode: create early load microcode image

 package/firmware/intel-microcode/Makefile  | 34 +-
 .../x86/base-files/lib/preinit/02_load_x86_ucode   |  6 ++--
 target/linux/x86/image/Makefile| 10 +--
 target/linux/x86/image/grub-iso.cfg|  3 ++
 target/linux/x86/image/grub.cfg|  3 ++
 5 files changed, 45 insertions(+), 11 deletions(-)

-- 
2.16.3


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] [PATCH] kernel: bump kernel 4.4 to 4.4.126 for 17.01

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

[LEDE-DEV] [PATCH v2] kernel: rtl8366-smi: add Realtek switch management via mii-bus

Re: [LEDE-DEV] [PATCH 03/12] uboot-at91: fetch uboot src from u-boot-at91 github

[LEDE-DEV] [PATCHv2] firewall: fix logging of dropped & rejected packets

Re: [LEDE-DEV] [PATCH] firewall: fix logging of dropped & rejected packets

Re: [LEDE-DEV] [PATCH] libjson-c: Update to 0.13

Re: [LEDE-DEV] [PATCH] kernel: update kernel 4.14 to 4.14.32

Re: [LEDE-DEV] [PATCH] firewall: fix logging of dropped & rejected packets

Re: [LEDE-DEV] [PATCH] libjson-c: Update to 0.13

[LEDE-DEV] [PATCH] firewall: fix logging of dropped & rejected packets

[LEDE-DEV] [PATCH 3/3] intel-microcode: create early load microcode image

[LEDE-DEV] [PATCH 2/3] x86: add intel microcode entries to grub config

[LEDE-DEV] [PATCH 1/3] intel-microcode: remove dependency on iucode-tool

[LEDE-DEV] [RFC PATCH 0/3] intel-microcode: load as early as possible

15 matches

Site Navigation

Mail list logo

Footer information