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

2017-05-08 Thread Linus Walleij 
On Tue, May 9, 2017 at 12:52 AM, Florian Fainelli  wrote:
> 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.

I mailed with Tom and it turns out he thinks openwrt-devel is getting
spammed with these submissions.

It's true in a sense: the patches are targeted for upstream and not
for the openwrt repo.

It's no big deal, I don't want to unnecessarily increase traffic on
openwrt-devel if it is annoying to some.

> 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.

I am porting to D-Link DIR-685 and DNS-313 as part of the
process, so we have two new high-volume routers/NAS boxes
as part of the process. I don't know how to fix the OpenWRT
install and builds for these in the end though.

It is actually probably an even bigger win though.

We have learnt that Faraday Technology is sprinkling silicon blocks
all over any silicon foundries close to Taiwan. Their stuff appear
to be in a lot of cheap routers, NAS etc. They use the number of
successful deployments of the IP block as a selling point. I guess
these guys are commonly called in to consult when kickstarting
silicon design, simply.

It turns out that this and other silicon vendors such as Grain Media,
Andestech, Moschip etc are using the same silicon blocks, so
a bunch of out-of-tree code is actually just duplicate implementations
of Faraday drivers... we already merged Gemini and MoxaArt in
the upstream kernel so we have a common interrupt chip, timer,
PCI driver, and now this IDE/ATA driver (not the FTIDE200 yet though).

So there is maybe not as much unique silicon
in the world as we have come to think, we need to pay attention
to how register maps look on different things.

Yours,
Linus Walleij
___
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

2017-05-08 Thread 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] [PATCH 1/2 v2] clk: Add bindings for the Gemini Clock Controller

2017-05-08 Thread Linus Walleij 
On Mon, May 8, 2017 at 11:24 PM, Rob Herring  wrote:

>> +Example:
>> +
>> +syscon: syscon@4000 {
>> +   compatible = "cortina,gemini-syscon", 
>> "cortina,gemini-clock-controller",
>> +"syscon", "simple-mfd";
>
> There are no child nodes, so you don't need simple-mfd.

The example is taken from an actual device tree (look below),
where there are child nodes, I can trim it down.

>> +   reg = <0x4000 0x1000>;
>
> Looks like you have 2 nodes pointing to the same address with your
> reset binding? You shouldn't have overlapping resources. It's allowed
> for historical reasons but breaks resource creation in Linux.

No... they are all in the same node, just sharing the same
resource by way of regmap (syscon).

In the end, as I think you requested, when you said:

>> + clock-controller {
>> + compatible = "cortina,gemini-clock-controller";
>> + #clock-cells = <1>;
(...)
> There's not really much reason to have a child node here. The parent can
> be the clock provider.
(...)
> Same comment as clocks. The parent can be the provider.

So as you say, no specific child is needed and syscon provides
clocks and resets:

syscon: syscon@4000 {
compatible = "cortina,gemini-syscon",
 "cortina,gemini-clock-controller",
 "cortina,gemini-reset",
 "syscon", "simple-mfd";
reg = <0x4000 0x1000>;
#clock-cells = <1>;
#reset-cells = <1>;

syscon-reboot {
compatible = "syscon-reboot";
regmap = <&syscon>;
/* GLOBAL_RESET register */
offset = <0x0c>;
/* RESET_GLOBAL | RESET_CPU1 */
mask = <0xC000>;
};
};

Before your (as I percieved it) requested changes to avoid
surplus children in the syscon it looked like this:

syscon: syscon@4000 {
compatible = "cortina,gemini-syscon",
"syscon", "simple-mfd";
reg = <0x4000 0x1000>;

syscon-reboot {
compatible = "syscon-reboot";
regmap = <&syscon>;
/* GLOBAL_RESET register */
offset = <0x0c>;
/* RESET_GLOBAL | RESET_CPU1 */
mask = <0xC000>;
};

rcon: reset-controller {
compatible = "cortina,gemini-reset";
#reset-cells = <1>;
};

gcc: clock-controller {
compatible = "cortina,gemini-clock-controller";
#clock-cells = <1>;
};
};


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

Re: [OpenWrt-Devel] [PATCH 1/2 v2] reset: Add DT bindings for the Gemini reset controller

2017-05-08 Thread Tom Psyborg 
Is it ever going to be added so this endless spam can end?


On 8 May 2017 at 22:07, Linus Walleij  wrote:

> This is a simple reset controller in a single 32bit
> register.
>
> Signed-off-by: Linus Walleij 
> ---
> ChangeLog v1->v2:
> - Move the reset controller node to be the same as the syscon
>   node, no need for a specific child node.
> - Add an include file with nice #defines.
> ---
>  .../bindings/reset/cortina,gemini-reset.txt| 58
> ++
>  include/dt-bindings/reset/cortina,gemini-reset.h   | 36 ++
>  2 files changed, 94 insertions(+)
>  create mode 100644 Documentation/devicetree/
> bindings/reset/cortina,gemini-reset.txt
>  create mode 100644 include/dt-bindings/reset/cortina,gemini-reset.h
>
> diff --git a/Documentation/devicetree/bindings/reset/cortina,gemini-reset.txt
> b/Documentation/devicetree/bindings/reset/cortina,gemini-reset.txt
> new file mode 100644
> index ..aa3d1b2a9677
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/reset/cortina,gemini-reset.txt
> @@ -0,0 +1,58 @@
> +Cortina Gemini Reset Controller
> +
> +This reset controller is found in Cortina Systems CS3516 and
> +the predecessor StorLink SL3516.
> +
> +Required properties:
> +- compatible: "cortina,gemini-reset"
> +- #reset-cells: Must be 1
> +
> +The Gemini reset controller must be identical to the system controller
> node.
> +Apart from this it follows the standard reset controller bindings.
> +
> +Valid reset line values:
> +
> +0:  DRAM controller
> +1:  Flash controller
> +2:  IDE controller
> +3:  RAID controller
> +4:  Security module
> +5:  GMAC0 (ethernet)
> +6:  GMAC1 (ethernet)
> +7:  PCI host bridge
> +8:  USB0 USB host controller
> +9:  USB1 USB host controller
> +10: General DMA controller
> +11: APB bridge
> +12: LPC (Low Pin Count) controller
> +13: LCD module
> +14: Interrupt controller 0
> +15: Interrupt controller 1
> +16: RTC module
> +17: Timer module
> +18: UART controller
> +19: SSP controller
> +20: GPIO0 GPIO controller
> +21: GPIO1 GPIO controller
> +22: GPIO2 GPIO controller
> +23: Watchdog timer
> +24: External device reset
> +25: CIR module (infrared)
> +26: SATA0 SATA bridge
> +27: SATA1 SATA bridge
> +28: TVE TV Encoder module
> +29: Reserved
> +30: CPU1 reset
> +31: Global soft reset
> +
> +These also have shorthand defines in the include file:
> +
> +
> +Example:
> +
> +syscon: syscon@4000 {
> +   compatible = "cortina,gemini-syscon", "cortina,gemini-reset",
> +"syscon", "simple-mfd";
> +   reg = <0x4000 0x1000>;
> +   #reset-cells = <1>;
> +};
> diff --git a/include/dt-bindings/reset/cortina,gemini-reset.h
> b/include/dt-bindings/reset/cortina,gemini-reset.h
> new file mode 100644
> index ..aebecae43721
> --- /dev/null
> +++ b/include/dt-bindings/reset/cortina,gemini-reset.h
> @@ -0,0 +1,36 @@
> +#ifndef _DT_BINDINGS_RESET_CORTINA_GEMINI_H
> +#define _DT_BINDINGS_RESET_CORTINA_GEMINI_H
> +
> +#define GEMINI_RESET_DRAM  0
> +#define GEMINI_RESET_FLASH 1
> +#define GEMINI_RESET_IDE   2
> +#define GEMINI_RESET_RAID  3
> +#define GEMINI_RESET_SECURITY  4
> +#define GEMINI_RESET_GMAC0 5
> +#define GEMINI_RESET_GMAC1 6
> +#define GEMINI_RESET_PCI   7
> +#define GEMINI_RESET_USB0  8
> +#define GEMINI_RESET_USB1  9
> +#define GEMINI_RESET_DMAC  10
> +#define GEMINI_RESET_APB   11
> +#define GEMINI_RESET_LPC   12
> +#define GEMINI_RESET_LCD   13
> +#define GEMINI_RESET_INTCON0   14
> +#define GEMINI_RESET_INTCON1   15
> +#define GEMINI_RESET_RTC   16
> +#define GEMINI_RESET_TIMER 17
> +#define GEMINI_RESET_UART  18
> +#define GEMINI_RESET_SSP   19
> +#define GEMINI_RESET_GPIO0 20
> +#define GEMINI_RESET_GPIO1 21
> +#define GEMINI_RESET_GPIO2 22
> +#define GEMINI_RESET_WDOG  23
> +#define GEMINI_RESET_EXTERN24
> +#define GEMINI_RESET_CIR   25
> +#define GEMINI_RESET_SATA0 26
> +#define GEMINI_RESET_SATA1 27
> +#define GEMINI_RESET_TVE   28
> +#define GEMINI_RESET_CPU1  30
> +#define GEMINI_RESET_GLOBAL31
> +
> +#endif
> --
> 2.9.3
> ___
> 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 1/2 v2] clk: Add bindings for the Gemini Clock Controller

2017-05-08 Thread Tom Psyborg 
Is it ever going to be added so this endless spam can end?


On 8 May 2017 at 22:11, Linus Walleij  wrote:

> This adds device tree bindings and a header for the Gemini SoC
> Clock Controller.
>
> Signed-off-by: Linus Walleij 
> ---
> ChangeLog v1->v2:
> - Move the clock controller to be directly in the parent syscon
>   node.
> ---
>  .../clock/cortina,gemini-clock-controller.txt  | 22 
>  include/dt-bindings/clock/cortina,gemini-clock.h   | 29
> ++
>  2 files changed, 51 insertions(+)
>  create mode 100644 Documentation/devicetree/
> bindings/clock/cortina,gemini-clock-controller.txt
>  create mode 100644 include/dt-bindings/clock/cortina,gemini-clock.h
>
> diff --git 
> a/Documentation/devicetree/bindings/clock/cortina,gemini-clock-controller.txt
> b/Documentation/devicetree/bindings/clock/cortina,gemini-
> clock-controller.txt
> new file mode 100644
> index ..ae0046bccba0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/cortina,gemini-
> clock-controller.txt
> @@ -0,0 +1,22 @@
> +Clock bindings for the Cortina Systems Gemini SoC Clock Controller
> +
> +Required properties :
> +- compatible : shall contain the following:
> +  "cortina,gemini-clock-controller"
> +- #clock-cells should be <1>
> +
> +The Gemini clock controller needs to be identical to the system controller
> +node.
> +
> +All available clocks are defined as preprocessor macros in
> +dt-bindings/clock/cortina,gemini-clock.h header and can be used in device
> +tree sources.
> +
> +Example:
> +
> +syscon: syscon@4000 {
> +   compatible = "cortina,gemini-syscon", "cortina,gemini-clock-
> controller",
> +"syscon", "simple-mfd";
> +   reg = <0x4000 0x1000>;
> +   #clock-cells = <1>;
> +};
> diff --git a/include/dt-bindings/clock/cortina,gemini-clock.h
> b/include/dt-bindings/clock/cortina,gemini-clock.h
> new file mode 100644
> index ..acf5cd550b0c
> --- /dev/null
> +++ b/include/dt-bindings/clock/cortina,gemini-clock.h
> @@ -0,0 +1,29 @@
> +#ifndef DT_BINDINGS_CORTINA_GEMINI_CLOCK_H
> +#define DT_BINDINGS_CORTINA_GEMINI_CLOCK_H
> +
> +/* RTC, AHB, APB, CPU, PCI, TVC, UART clocks and 13 gates */
> +#define GEMINI_NUM_CLKS 20
> +
> +#define GEMINI_CLK_RTC 0
> +#define GEMINI_CLK_AHB 1
> +#define GEMINI_CLK_APB 2
> +#define GEMINI_CLK_CPU 3
> +#define GEMINI_CLK_PCI 4
> +#define GEMINI_CLK_TVC 5
> +#define GEMINI_CLK_UART 6
> +#define GEMINI_CLK_GATES 7
> +#define GEMINI_CLK_GATE_SECURITY 7
> +#define GEMINI_CLK_GATE_GMAC0 8
> +#define GEMINI_CLK_GATE_GMAC1 9
> +#define GEMINI_CLK_GATE_SATA0 10
> +#define GEMINI_CLK_GATE_SATA1 11
> +#define GEMINI_CLK_GATE_USB0 12
> +#define GEMINI_CLK_GATE_USB1 13
> +#define GEMINI_CLK_GATE_IDE 14
> +#define GEMINI_CLK_GATE_PCI 15
> +#define GEMINI_CLK_GATE_DDR 16
> +#define GEMINI_CLK_GATE_FLASH 17
> +#define GEMINI_CLK_GATE_TVC 18
> +#define GEMINI_CLK_GATE_BOOT 19
> +
> +#endif /* DT_BINDINGS_CORTINA_GEMINI_CLOCK_H */
> --
> 2.9.3
> ___
> 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] ata: Add DT bindings for the Gemini SATA bridge

2017-05-08 Thread Tom Psyborg 
Is it ever going to be added so this endless spam can end?


On 8 May 2017 at 22:33, Linus Walleij  wrote:

> On Mon, May 8, 2017 at 12:49 PM, Bartlomiej Zolnierkiewicz
>  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

Re: [OpenWrt-Devel] [PATCH 2/2 v2] clk: Add Gemini SoC clock controller

2017-05-08 Thread Tom Psyborg 
Is it ever going to be added so this endless spam can end?


On 8 May 2017 at 22:12, Linus Walleij  wrote:

> The Cortina Systems Gemini (SL3516/CS3516) has an on-chip clock
> controller that derive all clocks from a single crystal, using some
> documented and some undocumented PLLs, half dividers, counters and
> gates. This is a best attempt to construct a clock driver for the
> clocks so at least we can gate off unused hardware and driver the
> PCI bus clock.
>
> Signed-off-by: Linus Walleij 
> ---
> ChangeLog v1->v2:
> - Move the clock controller to be part of the syscon node. No
>   need for a separate child node for this.
> ---
>  drivers/clk/Kconfig  |   7 +
>  drivers/clk/Makefile |   1 +
>  drivers/clk/clk-gemini.c | 358 ++
> +
>  3 files changed, 366 insertions(+)
>  create mode 100644 drivers/clk/clk-gemini.c
>
> diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
> index 9356ab4b7d76..9e7619f9bf0e 100644
> --- a/drivers/clk/Kconfig
> +++ b/drivers/clk/Kconfig
> @@ -118,6 +118,13 @@ config COMMON_CLK_CS2000_CP
> help
>   If you say yes here you get support for the CS2000 clock
> multiplier.
>
> +config COMMON_CLK_GEMINI
> +   bool "Clock driver for Cortina Systems Gemini SoC"
> +   select MFD_SYSCON
> +   ---help---
> + This driver supports the SoC clocks on the Cortina Systems Gemini
> + platform, also known as SL3516 or CS3516.
> +
>  config COMMON_CLK_S2MPS11
> tristate "Clock driver for S2MPS1X/S5M8767 MFD"
> depends on MFD_SEC_CORE || COMPILE_TEST
> diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
> index 92c12b86c2e8..e100d911a554 100644
> --- a/drivers/clk/Makefile
> +++ b/drivers/clk/Makefile
> @@ -25,6 +25,7 @@ obj-$(CONFIG_COMMON_CLK_CDCE925)  += clk-cdce925.o
>  obj-$(CONFIG_ARCH_CLPS711X)+= clk-clps711x.o
>  obj-$(CONFIG_COMMON_CLK_CS2000_CP) += clk-cs2000-cp.o
>  obj-$(CONFIG_ARCH_EFM32)   += clk-efm32gg.o
> +obj-$(CONFIG_COMMON_CLK_GEMINI)+= clk-gemini.o
>  obj-$(CONFIG_ARCH_HIGHBANK)+= clk-highbank.o
>  obj-$(CONFIG_COMMON_CLK_MAX77686)  += clk-max77686.o
>  obj-$(CONFIG_ARCH_MB86S7X) += clk-mb86s7x.o
> diff --git a/drivers/clk/clk-gemini.c b/drivers/clk/clk-gemini.c
> new file mode 100644
> index ..340c2570f24e
> --- /dev/null
> +++ b/drivers/clk/clk-gemini.c
> @@ -0,0 +1,358 @@
> +/*
> + * Cortina Gemini Clock Controller driver
> + * Copyright (c) 2017 Linus Walleij 
> + */
> +
> +#define pr_fmt(fmt) "clk-gemini: " fmt
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* Globally visible clocks */
> +static DEFINE_SPINLOCK(gemini_clk_lock);
> +static struct clk *gemini_clks[GEMINI_NUM_CLKS];
> +static struct clk_onecell_data gemini_clk_data;
> +
> +#define GEMINI_GLOBAL_STATUS 0x04
> +#define PLL_OSC_SEL BIT(30)
> +#define AHBSPEED_SHIFT (15)
> +#define AHBSPEED_MASK 0x07
> +#define CPU_AHB_RATIO_SHIFT (18)
> +#define CPU_AHB_RATIO_MASK 0x03
> +
> +#define GEMINI_GLOBAL_PLL_CONTROL 0x08
> +
> +#define GEMINI_GLOBAL_MISC_CONTROL 0x30
> +#define PCI_CLK_66MHZ BIT(18)
> +#define PCI_CLK_OE BIT(17)
> +
> +#define GEMINI_GLOBAL_CLOCK_CONTROL 0x34
> +#define PCI_CLKRUN_EN BIT(16)
> +#define TVC_HALFDIV_SHIFT (24)
> +#define TVC_HALFDIV_MASK 0x1f
> +#define SECURITY_CLK_SEL BIT(29)
> +
> +#define GEMINI_GLOBAL_PCI_DLL_CONTROL 0x44
> +#define PCI_DLL_BYPASS BIT(31)
> +#define PCI_DLL_TAP_SEL_MASK 0x1f
> +
> +struct gemini_gate_data {
> +   u8 bit_idx;
> +   const char *name;
> +   const char *parent_name;
> +   unsigned long flags;
> +};
> +
> +/**
> + * struct clk_gemini_pci - Gemini PCI clock
> + * @hw: corresponding clock hardware entry
> + * @map: regmap to access the registers
> + * @rate: current rate
> + */
> +struct clk_gemini_pci {
> +   struct clk_hw hw;
> +   struct regmap *map;
> +   unsigned long rate;
> +};
> +
> +/*
> + * FIXME: some clocks are marked as CLK_IGNORE_UNUSED: this is
> + * because their kernel drivers lack proper clock handling so we
> + * need to avoid them being gated off by default. Remove this as
> + * the drivers get fixed to handle clocks properly.
> + *
> + * The DDR controller may never have a driver, but certainly must
> + * not be gated off.
> + */
> +static const struct gemini_gate_data gemini_gates[] __initconst = {
> +   { 1, "security-gate", "secdiv", 0 },
> +   { 2, "gmac0-gate", "ahb", 0 },
> +   { 3, "gmac1-gate", "ahb", 0 },
> +   { 4, "sata0-gate", "ahb", 0 },
> +   { 5, "sata1-gate", "ahb", 0 },
> +   { 6, "usb0-gate", "ahb", 0 },
> +   { 7, "usb1-gate", "ahb", 0 },
> +   { 8, "ide-gate", "ahb", 0 },
> +   { 9, "pci-gate", "ahb", 0 },
> +   { 10, "ddr-gate", "ahb", CLK_IGNORE_UNUSED },
> +   { 11, "flash-gate", "ahb", CLK_IGNORE_UNUSED },
> +   { 12, "tvc-gate", "ahb",

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

2017-05-08 Thread Linus Walleij 
On Mon, May 8, 2017 at 12:49 PM, Bartlomiej Zolnierkiewicz
 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

Re: [OpenWrt-Devel] [PATCH 1/4] ata: Add DT bindings for Faraday Technology FTIDE010

2017-05-08 Thread Linus Walleij 
On Mon, May 8, 2017 at 12:47 PM, Bartlomiej Zolnierkiewicz
 wrote:

> Also for all current drivers we just put timing values (or a logic
> to calculate them from the standard ATA timings) into the driver
> itself and not device tree (as they are based on values are dictated
> by ATA standard and should not change for a given controller type).

I had it like that at first (and I can of course switch it back). But I
came to think this is better.

I was looking at these values from the point that it depends a bit
on the silicon where it is synthesized. So the vendor tree has
things like this:

#ifndef SL2312_FPGA_IDE
static unsigned char PIO_TIMING[5] = { 0xaa, 0xa3, 0xa1, 0x33, 0x31 };
static unsigned char TIMING_MDMA_50M[3] = { 0x66, 0x22, 0x21 };
static unsigned char TIMING_MDMA_66M[3] = { 0x88, 0x32, 0x31 };
static unsigned char TIMING_UDMA_50M[6] = { 0x33, 0x31, 0x21, 0x21,
0x11, 0x91 };
static unsigned char TIMING_UDMA_66M[7] = { 0x44, 0x42, 0x31, 0x21,
0x11, 0x91,  0x91};
#else
static unsigned char PIO_TIMING[5] = { 0x88, 0x82, 0x81, 0x32, 0x21 };
static unsigned char TIMING_MDMA_50M[3] = { 0x33, 0x11, 0x11 };
static unsigned char TIMING_MDMA_66M[3] = { 0x33, 0x11, 0x11 };
static unsigned char TIMING_UDMA_50M[6] = { 0x22, 0x11, 0x11, 0x11 };
static unsigned char TIMING_UDMA_66M[7] = { 0x22, 0x11, 0x11, 0x11 };
#endif

(From D-Link DIR-685 source release from Storlink/Cortina board support.)

So depending on whether they use an FPGA or an ASIC the values are
different, no matter what frequency (50 or 66 MHz) is used. So it is not
derived from frequency.

So I think it makes most sense to have it in the device tree as we don't
know what designs are out there.

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

[OpenWrt-Devel] [PATCH 2/2 v2] clk: Add Gemini SoC clock controller

2017-05-08 Thread Linus Walleij 
The Cortina Systems Gemini (SL3516/CS3516) has an on-chip clock
controller that derive all clocks from a single crystal, using some
documented and some undocumented PLLs, half dividers, counters and
gates. This is a best attempt to construct a clock driver for the
clocks so at least we can gate off unused hardware and driver the
PCI bus clock.

Signed-off-by: Linus Walleij 
---
ChangeLog v1->v2:
- Move the clock controller to be part of the syscon node. No
  need for a separate child node for this.
---
 drivers/clk/Kconfig  |   7 +
 drivers/clk/Makefile |   1 +
 drivers/clk/clk-gemini.c | 358 +++
 3 files changed, 366 insertions(+)
 create mode 100644 drivers/clk/clk-gemini.c

diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 9356ab4b7d76..9e7619f9bf0e 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -118,6 +118,13 @@ config COMMON_CLK_CS2000_CP
help
  If you say yes here you get support for the CS2000 clock multiplier.
 
+config COMMON_CLK_GEMINI
+   bool "Clock driver for Cortina Systems Gemini SoC"
+   select MFD_SYSCON
+   ---help---
+ This driver supports the SoC clocks on the Cortina Systems Gemini
+ platform, also known as SL3516 or CS3516.
+
 config COMMON_CLK_S2MPS11
tristate "Clock driver for S2MPS1X/S5M8767 MFD"
depends on MFD_SEC_CORE || COMPILE_TEST
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 92c12b86c2e8..e100d911a554 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -25,6 +25,7 @@ obj-$(CONFIG_COMMON_CLK_CDCE925)  += clk-cdce925.o
 obj-$(CONFIG_ARCH_CLPS711X)+= clk-clps711x.o
 obj-$(CONFIG_COMMON_CLK_CS2000_CP) += clk-cs2000-cp.o
 obj-$(CONFIG_ARCH_EFM32)   += clk-efm32gg.o
+obj-$(CONFIG_COMMON_CLK_GEMINI)+= clk-gemini.o
 obj-$(CONFIG_ARCH_HIGHBANK)+= clk-highbank.o
 obj-$(CONFIG_COMMON_CLK_MAX77686)  += clk-max77686.o
 obj-$(CONFIG_ARCH_MB86S7X) += clk-mb86s7x.o
diff --git a/drivers/clk/clk-gemini.c b/drivers/clk/clk-gemini.c
new file mode 100644
index ..340c2570f24e
--- /dev/null
+++ b/drivers/clk/clk-gemini.c
@@ -0,0 +1,358 @@
+/*
+ * Cortina Gemini Clock Controller driver
+ * Copyright (c) 2017 Linus Walleij 
+ */
+
+#define pr_fmt(fmt) "clk-gemini: " fmt
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Globally visible clocks */
+static DEFINE_SPINLOCK(gemini_clk_lock);
+static struct clk *gemini_clks[GEMINI_NUM_CLKS];
+static struct clk_onecell_data gemini_clk_data;
+
+#define GEMINI_GLOBAL_STATUS 0x04
+#define PLL_OSC_SEL BIT(30)
+#define AHBSPEED_SHIFT (15)
+#define AHBSPEED_MASK 0x07
+#define CPU_AHB_RATIO_SHIFT (18)
+#define CPU_AHB_RATIO_MASK 0x03
+
+#define GEMINI_GLOBAL_PLL_CONTROL 0x08
+
+#define GEMINI_GLOBAL_MISC_CONTROL 0x30
+#define PCI_CLK_66MHZ BIT(18)
+#define PCI_CLK_OE BIT(17)
+
+#define GEMINI_GLOBAL_CLOCK_CONTROL 0x34
+#define PCI_CLKRUN_EN BIT(16)
+#define TVC_HALFDIV_SHIFT (24)
+#define TVC_HALFDIV_MASK 0x1f
+#define SECURITY_CLK_SEL BIT(29)
+
+#define GEMINI_GLOBAL_PCI_DLL_CONTROL 0x44
+#define PCI_DLL_BYPASS BIT(31)
+#define PCI_DLL_TAP_SEL_MASK 0x1f
+
+struct gemini_gate_data {
+   u8 bit_idx;
+   const char *name;
+   const char *parent_name;
+   unsigned long flags;
+};
+
+/**
+ * struct clk_gemini_pci - Gemini PCI clock
+ * @hw: corresponding clock hardware entry
+ * @map: regmap to access the registers
+ * @rate: current rate
+ */
+struct clk_gemini_pci {
+   struct clk_hw hw;
+   struct regmap *map;
+   unsigned long rate;
+};
+
+/*
+ * FIXME: some clocks are marked as CLK_IGNORE_UNUSED: this is
+ * because their kernel drivers lack proper clock handling so we
+ * need to avoid them being gated off by default. Remove this as
+ * the drivers get fixed to handle clocks properly.
+ *
+ * The DDR controller may never have a driver, but certainly must
+ * not be gated off.
+ */
+static const struct gemini_gate_data gemini_gates[] __initconst = {
+   { 1, "security-gate", "secdiv", 0 },
+   { 2, "gmac0-gate", "ahb", 0 },
+   { 3, "gmac1-gate", "ahb", 0 },
+   { 4, "sata0-gate", "ahb", 0 },
+   { 5, "sata1-gate", "ahb", 0 },
+   { 6, "usb0-gate", "ahb", 0 },
+   { 7, "usb1-gate", "ahb", 0 },
+   { 8, "ide-gate", "ahb", 0 },
+   { 9, "pci-gate", "ahb", 0 },
+   { 10, "ddr-gate", "ahb", CLK_IGNORE_UNUSED },
+   { 11, "flash-gate", "ahb", CLK_IGNORE_UNUSED },
+   { 12, "tvc-gate", "ahb", 0 },
+   { 13, "boot-gate", "apb", 0 },
+};
+
+#define to_pciclk(_hw) container_of(_hw, struct clk_gemini_pci, hw)
+
+static unsigned long gemini_pci_recalc_rate(struct clk_hw *hw,
+   unsigned long parent_rate)
+{
+   struct clk_gemini_pci *pciclk = to_pciclk(hw);
+   u32 val;
+   int ret;
+
+   ret = regmap_read(pciclk->map, GEM

[OpenWrt-Devel] [PATCH 1/2 v2] clk: Add bindings for the Gemini Clock Controller

2017-05-08 Thread Linus Walleij 
This adds device tree bindings and a header for the Gemini SoC
Clock Controller.

Signed-off-by: Linus Walleij 
---
ChangeLog v1->v2:
- Move the clock controller to be directly in the parent syscon
  node.
---
 .../clock/cortina,gemini-clock-controller.txt  | 22 
 include/dt-bindings/clock/cortina,gemini-clock.h   | 29 ++
 2 files changed, 51 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/clock/cortina,gemini-clock-controller.txt
 create mode 100644 include/dt-bindings/clock/cortina,gemini-clock.h

diff --git 
a/Documentation/devicetree/bindings/clock/cortina,gemini-clock-controller.txt 
b/Documentation/devicetree/bindings/clock/cortina,gemini-clock-controller.txt
new file mode 100644
index ..ae0046bccba0
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/clock/cortina,gemini-clock-controller.txt
@@ -0,0 +1,22 @@
+Clock bindings for the Cortina Systems Gemini SoC Clock Controller
+
+Required properties :
+- compatible : shall contain the following:
+  "cortina,gemini-clock-controller"
+- #clock-cells should be <1>
+
+The Gemini clock controller needs to be identical to the system controller
+node.
+
+All available clocks are defined as preprocessor macros in
+dt-bindings/clock/cortina,gemini-clock.h header and can be used in device
+tree sources.
+
+Example:
+
+syscon: syscon@4000 {
+   compatible = "cortina,gemini-syscon", "cortina,gemini-clock-controller",
+"syscon", "simple-mfd";
+   reg = <0x4000 0x1000>;
+   #clock-cells = <1>;
+};
diff --git a/include/dt-bindings/clock/cortina,gemini-clock.h 
b/include/dt-bindings/clock/cortina,gemini-clock.h
new file mode 100644
index ..acf5cd550b0c
--- /dev/null
+++ b/include/dt-bindings/clock/cortina,gemini-clock.h
@@ -0,0 +1,29 @@
+#ifndef DT_BINDINGS_CORTINA_GEMINI_CLOCK_H
+#define DT_BINDINGS_CORTINA_GEMINI_CLOCK_H
+
+/* RTC, AHB, APB, CPU, PCI, TVC, UART clocks and 13 gates */
+#define GEMINI_NUM_CLKS 20
+
+#define GEMINI_CLK_RTC 0
+#define GEMINI_CLK_AHB 1
+#define GEMINI_CLK_APB 2
+#define GEMINI_CLK_CPU 3
+#define GEMINI_CLK_PCI 4
+#define GEMINI_CLK_TVC 5
+#define GEMINI_CLK_UART 6
+#define GEMINI_CLK_GATES 7
+#define GEMINI_CLK_GATE_SECURITY 7
+#define GEMINI_CLK_GATE_GMAC0 8
+#define GEMINI_CLK_GATE_GMAC1 9
+#define GEMINI_CLK_GATE_SATA0 10
+#define GEMINI_CLK_GATE_SATA1 11
+#define GEMINI_CLK_GATE_USB0 12
+#define GEMINI_CLK_GATE_USB1 13
+#define GEMINI_CLK_GATE_IDE 14
+#define GEMINI_CLK_GATE_PCI 15
+#define GEMINI_CLK_GATE_DDR 16
+#define GEMINI_CLK_GATE_FLASH 17
+#define GEMINI_CLK_GATE_TVC 18
+#define GEMINI_CLK_GATE_BOOT 19
+
+#endif /* DT_BINDINGS_CORTINA_GEMINI_CLOCK_H */
-- 
2.9.3
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 2/2 v2] reset: Add a Gemini reset controller

2017-05-08 Thread Linus Walleij 
The Cortina Systems Gemini reset controller is a simple
32bit register with self-deasserting reset lines. It is
accessed using regmap over syscon.

Signed-off-by: Linus Walleij 
---
ChangeLog v1->v2:
- Add an explicit GPL license statement.
- Move the reset controller to be identical to the sycon
  node, no need to a separate child node for this.
- Drop unneeded struct device *dev pointer from state
  container.
- Print error code on missing regmap.
- Use #define from the  to indicate that we
  always set the CPU1 reset line to 1 when writing the
  resets.
---
 drivers/reset/Kconfig|   7 +++
 drivers/reset/Makefile   |   1 +
 drivers/reset/reset-gemini.c | 110 +++
 3 files changed, 118 insertions(+)
 create mode 100644 drivers/reset/reset-gemini.c

diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
index f4cdfe94b9ec..a82e1a78de25 100644
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -27,6 +27,13 @@ config RESET_BERLIN
help
  This enables the reset controller driver for Marvell Berlin SoCs.
 
+config RESET_GEMINI
+   bool "Gemini Reset Driver" if COMPILE_TEST
+   default ARCH_GEMINI
+   select MFD_SYSCON
+   help
+ This enables the reset controller driver for Cortina Systems Gemini.
+
 config RESET_LPC18XX
bool "LPC18xx/43xx Reset Driver" if COMPILE_TEST
default ARCH_LPC18XX
diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
index 2cd3f6c45165..99e90ad18545 100644
--- a/drivers/reset/Makefile
+++ b/drivers/reset/Makefile
@@ -4,6 +4,7 @@ obj-$(CONFIG_ARCH_STI) += sti/
 obj-$(CONFIG_ARCH_TEGRA) += tegra/
 obj-$(CONFIG_RESET_ATH79) += reset-ath79.o
 obj-$(CONFIG_RESET_BERLIN) += reset-berlin.o
+obj-$(CONFIG_RESET_GEMINI) += reset-gemini.o
 obj-$(CONFIG_RESET_LPC18XX) += reset-lpc18xx.o
 obj-$(CONFIG_RESET_MESON) += reset-meson.o
 obj-$(CONFIG_RESET_OXNAS) += reset-oxnas.o
diff --git a/drivers/reset/reset-gemini.c b/drivers/reset/reset-gemini.c
new file mode 100644
index ..ebe59eb25b20
--- /dev/null
+++ b/drivers/reset/reset-gemini.c
@@ -0,0 +1,110 @@
+/*
+ * Cortina Gemini Reset controller driver
+ * Copyright (C) 2017 Linus Walleij 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/**
+ * struct gemini_reset - gemini reset controller
+ * @map: regmap to access the containing system controller
+ * @rcdev: reset controller device
+ */
+struct gemini_reset {
+   struct regmap *map;
+   struct reset_controller_dev rcdev;
+};
+
+#define GEMINI_GLOBAL_SOFT_RESET 0x0c
+
+#define to_gemini_reset(p) \
+   container_of((p), struct gemini_reset, rcdev)
+
+/*
+ * This is a self-deasserting reset controller.
+ */
+static int gemini_reset(struct reset_controller_dev *rcdev,
+   unsigned long id)
+{
+   struct gemini_reset *gr = to_gemini_reset(rcdev);
+
+   /* Manual says to always set BIT 30 (CPU1) to 1 */
+   return regmap_write(gr->map,
+   GEMINI_GLOBAL_SOFT_RESET,
+   BIT(GEMINI_RESET_CPU1) | BIT(id));
+}
+
+static int gemini_reset_status(struct reset_controller_dev *rcdev,
+unsigned long id)
+{
+   struct gemini_reset *gr = to_gemini_reset(rcdev);
+   u32 val;
+   int ret;
+
+   ret = regmap_read(gr->map, GEMINI_GLOBAL_SOFT_RESET, &val);
+   if (ret)
+   return ret;
+
+   return !!(val & BIT(id));
+}
+
+static const struct reset_control_ops gemini_reset_ops = {
+   .reset = gemini_reset,
+   .status = gemini_reset_status,
+};
+
+static int gemini_reset_probe(struct platform_device *pdev)
+{
+   struct gemini_reset *gr;
+   struct device *dev = &pdev->dev;
+   struct device_node *np = dev->of_node;
+   int ret;
+
+   gr = devm_kzalloc(dev, sizeof(*gr), GFP_KERNEL);
+   if (!gr)
+   return -ENOMEM;
+
+   gr->map = syscon_node_to_regmap(np);
+   if (IS_ERR(gr->map)) {
+   ret = PTR_ERR(gr->map);
+   dev_err(dev, "unable to get regmap (%d)", ret);
+   return ret;
+   }
+   gr->rcdev.owner = THIS_MODULE;
+   gr->rcdev.nr_resets = 32;
+   gr->rcdev.ops = &gemini_reset_ops;
+   gr->rcdev.of_node = pdev->dev.of_node;
+
+   ret = devm_reset_controller_register(&pdev->dev, &gr->rcdev);
+   if (ret)
+   return ret;
+
+   dev_info(dev, "registered Gemini reset controller\n");
+   return 0;
+}
+
+static const struct of_device_id gemini_reset_dt_ids[] = {
+   { .compatible = "cortina,gemini-reset", },
+   { /* sentinel */ },
+};
+
+static struct platform_driver gemini_reset_driver = {
+   .probe  = gemini_reset_probe,
+   .driver = {
+

[OpenWrt-Devel] [PATCH 1/2 v2] reset: Add DT bindings for the Gemini reset controller

2017-05-08 Thread Linus Walleij 
This is a simple reset controller in a single 32bit
register.

Signed-off-by: Linus Walleij 
---
ChangeLog v1->v2:
- Move the reset controller node to be the same as the syscon
  node, no need for a specific child node.
- Add an include file with nice #defines.
---
 .../bindings/reset/cortina,gemini-reset.txt| 58 ++
 include/dt-bindings/reset/cortina,gemini-reset.h   | 36 ++
 2 files changed, 94 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/reset/cortina,gemini-reset.txt
 create mode 100644 include/dt-bindings/reset/cortina,gemini-reset.h

diff --git a/Documentation/devicetree/bindings/reset/cortina,gemini-reset.txt 
b/Documentation/devicetree/bindings/reset/cortina,gemini-reset.txt
new file mode 100644
index ..aa3d1b2a9677
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/cortina,gemini-reset.txt
@@ -0,0 +1,58 @@
+Cortina Gemini Reset Controller
+
+This reset controller is found in Cortina Systems CS3516 and
+the predecessor StorLink SL3516.
+
+Required properties:
+- compatible: "cortina,gemini-reset"
+- #reset-cells: Must be 1
+
+The Gemini reset controller must be identical to the system controller node.
+Apart from this it follows the standard reset controller bindings.
+
+Valid reset line values:
+
+0:  DRAM controller
+1:  Flash controller
+2:  IDE controller
+3:  RAID controller
+4:  Security module
+5:  GMAC0 (ethernet)
+6:  GMAC1 (ethernet)
+7:  PCI host bridge
+8:  USB0 USB host controller
+9:  USB1 USB host controller
+10: General DMA controller
+11: APB bridge
+12: LPC (Low Pin Count) controller
+13: LCD module
+14: Interrupt controller 0
+15: Interrupt controller 1
+16: RTC module
+17: Timer module
+18: UART controller
+19: SSP controller
+20: GPIO0 GPIO controller
+21: GPIO1 GPIO controller
+22: GPIO2 GPIO controller
+23: Watchdog timer
+24: External device reset
+25: CIR module (infrared)
+26: SATA0 SATA bridge
+27: SATA1 SATA bridge
+28: TVE TV Encoder module
+29: Reserved
+30: CPU1 reset
+31: Global soft reset
+
+These also have shorthand defines in the include file:
+
+
+Example:
+
+syscon: syscon@4000 {
+   compatible = "cortina,gemini-syscon", "cortina,gemini-reset",
+"syscon", "simple-mfd";
+   reg = <0x4000 0x1000>;
+   #reset-cells = <1>;
+};
diff --git a/include/dt-bindings/reset/cortina,gemini-reset.h 
b/include/dt-bindings/reset/cortina,gemini-reset.h
new file mode 100644
index ..aebecae43721
--- /dev/null
+++ b/include/dt-bindings/reset/cortina,gemini-reset.h
@@ -0,0 +1,36 @@
+#ifndef _DT_BINDINGS_RESET_CORTINA_GEMINI_H
+#define _DT_BINDINGS_RESET_CORTINA_GEMINI_H
+
+#define GEMINI_RESET_DRAM  0
+#define GEMINI_RESET_FLASH 1
+#define GEMINI_RESET_IDE   2
+#define GEMINI_RESET_RAID  3
+#define GEMINI_RESET_SECURITY  4
+#define GEMINI_RESET_GMAC0 5
+#define GEMINI_RESET_GMAC1 6
+#define GEMINI_RESET_PCI   7
+#define GEMINI_RESET_USB0  8
+#define GEMINI_RESET_USB1  9
+#define GEMINI_RESET_DMAC  10
+#define GEMINI_RESET_APB   11
+#define GEMINI_RESET_LPC   12
+#define GEMINI_RESET_LCD   13
+#define GEMINI_RESET_INTCON0   14
+#define GEMINI_RESET_INTCON1   15
+#define GEMINI_RESET_RTC   16
+#define GEMINI_RESET_TIMER 17
+#define GEMINI_RESET_UART  18
+#define GEMINI_RESET_SSP   19
+#define GEMINI_RESET_GPIO0 20
+#define GEMINI_RESET_GPIO1 21
+#define GEMINI_RESET_GPIO2 22
+#define GEMINI_RESET_WDOG  23
+#define GEMINI_RESET_EXTERN24
+#define GEMINI_RESET_CIR   25
+#define GEMINI_RESET_SATA0 26
+#define GEMINI_RESET_SATA1 27
+#define GEMINI_RESET_TVE   28
+#define GEMINI_RESET_CPU1  30
+#define GEMINI_RESET_GLOBAL31
+
+#endif
-- 
2.9.3
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

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

2017-05-08 Thread Daniel Golle 
On Mon, May 08, 2017 at 09:19:42PM +0200, Zoltan HERPAI wrote:
> Hi,
> 
> On Mon, 8 May 2017, Daniel Engberg wrote:
> 
> > Trac:
> > Is it really worth keeping trac at all? What value does it add? Just
> > display a page explaining that it's shutdown and forward to OpenWrt?
> 
> There is a lot of "added value" in the tickets submitted throughout the
> years, either as comments, notes, fixes or just the issue being raised, so
> it's a good idea to keep it for archiving purposes. Older devices do die,
> but every year or so I come across shops selling brand new WRT54G (really),
> so keeping the knowledge base in an unsorted form (compared to a wiki) to
> the users can be useful. Whether that's a staticized archive or running the
> trac engine itself is another question.

I agree that there are a lot of references to dev.openwrt.org which
should remain intact. A non-interactive version would imho be
sufficient, tickets which are actually still relevant should be
re-opened on bugs.lede-project.org (which will become bugs.openwrt.org)
A grace period of 1 month starting from the notification until the
service is being shutdown (or archived read-only) would also be nice.

> 
> Other than that, I very much welcome the groundwork for the planned merge -
> thanks John, Imre and Felix for putting it together.

I agree. Thanks a lot for all the work done, this is great progress!


Cheers


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

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

2017-05-08 Thread Zoltan HERPAI 

Hi,

On Mon, 8 May 2017, Daniel Engberg wrote:


Trac:
Is it really worth keeping trac at all? What value does it add? Just display 
a page explaining that it's shutdown and forward to OpenWrt?


There is a lot of "added value" in the tickets submitted throughout the 
years, either as comments, notes, fixes or just the issue being raised, so
it's a good idea to keep it for archiving purposes. Older devices do die, 
but every year or so I come across shops selling brand new WRT54G 
(really), so keeping the knowledge base in an unsorted form (compared to a 
wiki) to the users can be useful. Whether that's a staticized archive or 
running the trac engine itself is another question.


Other than that, I very much welcome the groundwork for the planned merge 
- thanks John, Imre and Felix for putting it together.


Regards,
Zoltan H
___
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

2017-05-08 Thread John Crispin 



On 08/05/17 15:29, David Woodhouse wrote:

On Mon, 2017-05-08 at 15:19 +0200, John Crispin wrote:

*) 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

Yes, we can redirect the existing lists to the new ones — so for
example, mail sent to lede-dev will just turn up on the openwrt-dev
list instead. Assuming that's what you meant.

For importing subscribers, if that's what you want to do, I'd be
inclined to send *invitations* not just subscribe people. So each
person will get the 'someone has requested that your address be
subscribed; click here to actually do it' message. We can write our own
blurb to go out at the top of those invitations.


Hi David,

Thanks for clarifying this, sending out invites does sound reasonable.



I still haven't worked out if I actually have a vote here or not but
FWIW the rest of the proposal looked good to me.


glad that you like it.

John
___
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

2017-05-08 Thread Imre Kaloz 

On 2017-05-08 15:43, Toke Høiland-Jørgensen wrote:

John Crispin  writes:


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.


Great to hear progress is being made on this! I think the proposal looks
reasonable, generally. A few comments / questions:

- What will this mean for the community rules and the release schedule?
  Will they continue from the current LEDE practices?


- update the landing page to have the same look & feel as the current openwrt
landing page


Well, I like the L&F of lede-project.org better - but it's not something
worth bikeshedding over, so meh, fine... ;)


Well, the OpenWrt one might be from 2000s, but the LEDE one is from '95 
;) I think the CSS jow did for the OpenWrt forum looks the best TBH :)



*) trademark/sponsorship policy
- review/ack imres trademark policy
- review/ack jows sponsorship policy


Links to these?


On the tm policy: https://openwrt.org/trademark - I guess jow will chime 
in with the location of the sponsorship one, too.





Imre
___
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

2017-05-08 Thread Toke Høiland-Jørgensen 
John Crispin  writes:

> 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.

Great to hear progress is being made on this! I think the proposal looks
reasonable, generally. A few comments / questions:

- What will this mean for the community rules and the release schedule?
  Will they continue from the current LEDE practices?

> - update the landing page to have the same look & feel as the current openwrt
> landing page

Well, I like the L&F of lede-project.org better - but it's not something
worth bikeshedding over, so meh, fine... ;)

> *) trademark/sponsorship policy
> - review/ack imres trademark policy
> - review/ack jows sponsorship policy

Links to these?

-Toke
___
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

2017-05-08 Thread David Woodhouse 
On Mon, 2017-05-08 at 15:19 +0200, John Crispin wrote:
> 
> *) 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

Yes, we can redirect the existing lists to the new ones — so for
example, mail sent to lede-dev will just turn up on the openwrt-dev
list instead. Assuming that's what you meant.

For importing subscribers, if that's what you want to do, I'd be
inclined to send *invitations* not just subscribe people. So each
person will get the 'someone has requested that your address be
subscribed; click here to actually do it' message. We can write our own
blurb to go out at the top of those invitations.

I still haven't worked out if I actually have a vote here or not but
FWIW the rest of the proposal looked good to me.


smime.p7s
Description: S/MIME cryptographic signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] openwrt and lede - remerge proposal

2017-05-08 Thread John Crispin 

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

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

Re: [OpenWrt-Devel] Factory startup issues since mount_root / libfstools improvements in Chaos Calmer

2017-05-08 Thread Smith, Pieter 
Hi Rafał,

I am still hoping to get confirmation from you on this patch. Is this 
acceptable for upstreaming?

> Hi Rafał,
>
> > > On 03/29/2017 11:53 AM, Smith, Pieter wrote:
> > > > My apologies. I am not able to get mutt working with our corporate
> > > > infrastructure. I hope it arrives unmangled as an attachment. If
> > > > not, I'll use my personal mail.
> > >
> > > This would be acceptable for me to pick patch sent as attachment,
> > > but you really need to sign it off with your name. Please add a
> > > proper
> > > Signed-off-by:
> > > line and resend.
> >
> > Off-course! My bad...
>
> In adding more logging so that you can diagnose the issue, I tracked down the 
> root cause and fixed the issue. Attached, > please find an updated patch with 
> sign-off and a problem description.
>
> - Pieter

Regards,
Pieter



The information contained in this message may be confidential and legally 
protected under applicable law. The message is intended solely for the 
addressee(s). If you are not the intended recipient, you are hereby notified 
that any use, forwarding, dissemination, or reproduction of this message is 
strictly prohibited and may be unlawful. If you are not the intended recipient, 
please contact the sender by return e-mail and destroy all copies of the 
original message.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel