Re: [LEDE-DEV] [RFC] toolchain: fix GCC version check causing failure on Debian Testing with gcc-7

2017-11-26 Thread Martin Blumenstingl via Lede-dev 
The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
Hi Peter,

On Sun, Nov 26, 2017 at 5:12 PM, Peter Pöschl  wrote:
> In Debian Stretch/Testing gcc version 7 is called gcc-7 and g++-7 and
> 'gcc -dumpversion' returns '7' which causes 'make defconfig' to fail with
>
>Build dependency: Please install the GNU C Compiler ...
>Build dependency: Please install the GNU C++ Compiler ...
>
> The following patch is minimal invasive.
> Alternatively, it would be more robust to use the regex
>'^(4\.[8-9]|5\.[0-9]|6\.[0-9]|7(|.\[0-9]))'
> instead (currently even 1.4.0 would be accepted), but this might have 
> backward-compatibility ramifications.
a few hours ago a similar patch was pushed: [0] (I CC'ed the author of it)

there are some differences between your patch and the one which is
merged already
maybe you could check these and rebase your patch to improve the
merged patch even futher

>
> Signed-off-by: Peter Pöschl 
> ---
> diff --git a/include/prereq-build.mk b/include/prereq-build.mk
> index c6f99a2071..43a8da290f 100644
> --- a/include/prereq-build.mk
> +++ b/include/prereq-build.mk
> @@ -28,13 +28,14 @@ $(eval $(call TestHostCommand,proper-umask, \
>
>  $(eval $(call SetupHostCommand,gcc, \
> Please install the GNU C Compiler (gcc) 4.8 or later \
> -   $(CC) -dumpversion | grep -E '(4\.[8-9]|5\.[0-9]|6\.[0-9]|7\.[0-9])', 
> \
> -   gcc -dumpversion | grep -E '(4\.[8-9]|5\.[0-9]|6\.[0-9]|7\.[0-9])', \
> +   $(CC) -dumpversion | grep -E 
> '(4\.[8-9]|5\.[0-9]|6\.[0-9]|^7|7\.[0-9])', \
> +   gcc -dumpversion | grep -E 
> '(4\.[8-9]|5\.[0-9]|6\.[0-9]|^7|7\.[0-9])', \
your patch contains a match against EOL ($) which the merged version doesn't

> gcc48 --version | grep gcc, \
> gcc49 --version | grep gcc, \
> gcc5 --version | grep gcc, \
> gcc6 --version | grep gcc, \
> gcc7 --version | grep gcc, \
> +   gcc-7 --version | grep gcc, \
this part is new

> gcc --version | grep Apple.LLVM ))
>
>  $(eval $(call TestHostCommand,working-gcc, \
> @@ -45,13 +46,14 @@ $(eval $(call TestHostCommand,working-gcc, \
>
>  $(eval $(call SetupHostCommand,g++, \
> Please install the GNU C++ Compiler (g++) 4.8 or later \
> -   $(CXX) -dumpversion | grep -E 
> '(4\.[8-9]|5\.[0-9]|6\.[0-9]|7\.[0-9])', \
> -   g++ -dumpversion | grep -E '(4\.[8-9]|5\.[0-9]|6\.[0-9]|7\.[0-9])', \
> +   $(CXX) -dumpversion | grep -E 
> '(4\.[8-9]|5\.[0-9]|6\.[0-9]|^7|7\.[0-9])', \
> +   g++ -dumpversion | grep -E 
> '(4\.[8-9]|5\.[0-9]|6\.[0-9]|^7|7\.[0-9])', \
> g++48 --version | grep g++, \
> g++49 --version | grep g++, \
> g++5 --version | grep g++, \
> g++6 --version | grep g++, \
> g++7 --version | grep g++, \
> +   g++-7 --version | grep g++, \
> g++ --version | grep Apple.LLVM ))
>
>  $(eval $(call TestHostCommand,working-g++, \
> --
> 2.15.0
>
>
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev

Thank you!
Martin

[0] 
https://git.lede-project.org/?p=source.git;a=commitdiff;h=8ee2d3f718c79dc7c2e5e859766e23e8058cf3a6

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

Re: [LEDE-DEV] [PATCH 4/4] ramips/RT5350F-OLINUXINO(-EVB) dts: enable ttyS1

2017-09-16 Thread Martin Blumenstingl via Lede-dev 
The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
Hi Zoltan,

On Wed, Sep 6, 2017 at 2:25 AM, Zoltan Gyarmati
 wrote:
> Dear John,
>
> thanks for the review, see my response inline
>
> On 08/29/2017 09:37 AM, John Crispin wrote:
>> Hi,
>>
>> comment inline
>>
>>
>> On 26/08/17 21:54, Zoltan Gyarmati wrote:
>>>   The RT5350F's second UART pins are available on the base module and on
>>> the EVB as well, so enable it in the device tree.
>>>   Additionaly, the uartlite@c00 and uart@500 nodes swapped in
>>> rt5350.dtsi
>>> to keep the serial console as ttyS0.
>>>
>>> Signed-off-by: Zoltan Gyarmati 
>>> ---
>>>   target/linux/ramips/dts/RT5350F-OLINUXINO.dtsi | 11 +-
>>>   target/linux/ramips/dts/rt5350.dtsi| 30
>>> +-
>>>   2 files changed, 25 insertions(+), 16 deletions(-)
>>>
>>> diff --git a/target/linux/ramips/dts/RT5350F-OLINUXINO.dtsi
>>> b/target/linux/ramips/dts/RT5350F-OLINUXINO.dtsi
>>> index 955a13cddd..1632f3c085 100644
>>> --- a/target/linux/ramips/dts/RT5350F-OLINUXINO.dtsi
>>> +++ b/target/linux/ramips/dts/RT5350F-OLINUXINO.dtsi
>>> @@ -46,9 +46,13 @@
>>>{
>>>   state_default: pinctrl0 {
>>>   gpio {
>>> -ralink,group = "jtag", "rgmii", "mdio", "uartf";
>>> +ralink,group = "jtag", "rgmii", "mdio";
>>>   ralink,function = "gpio";
>>>   };
>>> +uartf_gpio {
>>> +ralink,group = "uartf";
>>> +ralink,function = "gpio uartf";
>>> +};
>>>   };
>>>   };
>>>   @@ -77,3 +81,8 @@
>>>{
>>>   status = "okay";
>>>   };
>>> +
>>> + {
>>> +status = "okay";
>>> +};
>>> +
>>> diff --git a/target/linux/ramips/dts/rt5350.dtsi
>>> b/target/linux/ramips/dts/rt5350.dtsi
>>> index a92c113043..f027e17d9d 100644
>>> --- a/target/linux/ramips/dts/rt5350.dtsi
>>> +++ b/target/linux/ramips/dts/rt5350.dtsi
>>> @@ -83,21 +83,6 @@
>>>   interrupts = <3>;
>>>   };
>>>   -uart: uart@500 {
>>> -compatible = "ralink,rt5350-uart", "ralink,rt2880-uart",
>>> "ns16550a";
>>> -reg = <0x500 0x100>;
>>> -
>>> -resets = < 12>;
>>> -reset-names = "uart";
>>> -
>>> -interrupt-parent = <>;
>>> -interrupts = <5>;
>>> -
>>> -reg-shift = <2>;
>>> -
>>> -status = "disabled";
>>> -};
>>> -
>>>   gpio0: gpio@600 {
>>>   compatible = "ralink,rt5350-gpio", "ralink,rt2880-gpio";
>>>   reg = <0x600 0x34>;
>>> @@ -221,6 +206,21 @@
>>>   reg-shift = <2>;
>>>   };
>>>   +uart: uart@500 {
>>> +compatible = "ralink,rt5350-uart", "ralink,rt2880-uart",
>>> "ns16550a";
>>> +reg = <0x500 0x100>;
>>> +
>>> +resets = < 12>;
>>> +reset-names = "uart";
>>> +
>>> +interrupt-parent = <>;
>>> +interrupts = <5>;
>>> +
>>> +reg-shift = <2>;
>>> +
>>> +status = "disabled";
>>> +};
>>
>> moving the node makes no sense. the change is a no-op. please remove
>> it and update the patch description
>
>
> I've just double checked it now, and the order of these nodes does
> change the order of the serial port numbering, therefore it's not no-op.
> Please see the relevant sections from both dmesg outputs:
have you tried using the devicetree aliases node (see [0] for example)
to configure the order?

>  With original rt5350.dtsi, uart@500 enabled
> [ 0.565407] gpio-export gpio_export: 3 gpio(s) exported
> [ 0.576247] Serial: 8250/16550 driver, 2 ports, IRQ sharing disabled
> [ 0.590942] console [ttyS0] disabled
> [0.598130] 1500.uart: ttyS0 at MMIO 0x1500 (irq = 13,
> base_baud = 250) is a Palmchip BK-3103
> [0.617160] console [ttyS0] enabled
> [0.630939] bootconsole [early0] disabled
> [0.647968] 1c00.uartlite: ttyS1 at MMIO 0x1c00 (irq = 20,
> base_baud = 250) is a Palmchip BK-3103
> [0.680207] spi spi0.0: force spi mode3
>
>  With swapped items in rt5350.dtsi
> [0.564356] gpio-export gpio_export: 3 gpio(s) exported
> [0.575201] Serial: 8250/16550 driver, 2 ports, IRQ sharing disabled
> [0.590006] console [ttyS0] disabled
> [0.597183] 1c00.uartlite: ttyS0 at MMIO 0x1c00 (irq = 20,
> base_baud = 250) is a Palmchip BK-3103
> [0.616906] console [ttyS0] enabled
> [0.630692] bootconsole [early0] disabled
> [0.647677] 1500.uart: ttyS1 at MMIO 0x1500 (irq = 13,
> base_baud = 250) is a Palmchip BK-3103
> [0.678972] spi spi0.0: force spi mode3
>
> Consequently (given that ttyS0 is configured as console in the kernel
> command line),
> the serial console moves to

Re: [LEDE-DEV] [PATCH 2/3] ramips-mt7621: add GPIO-config for Ubiquiti-EdgeRouterX(-SFP)

2017-05-14 Thread Martin Blumenstingl via Lede-dev 
The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
On Sun, May 14, 2017 at 10:13 PM, Sven Roederer  wrote:
> On Sonntag, 14. Mai 2017 21:22:42 CEST Sven Roederer wrote:
>>
>> I removed the 03_gpio_export and added this to the dts:
>> gpio_export {
>>   compatible = "gpio-export";
>>   #size-cells = <0>;
>>
>>   poe_passthrough {
>>   gpio-export,name = "poe_power_port0";
>>   gpio-export,output = <1>;
>>   gpios = < 496 0>;
>>   };
>> };
>>
>> But booting this kernel gives:
>> [1.66] [ cut here ]
>> [1.67] WARNING: CPU: 0 PID: 1 at drivers/gpio/gpiolib.c:85 
>> 0x801dc2fc()
>> [1.68] invalid GPIO -22
>> [1.69] Modules linked in:
>> [1.69] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.4.61 #0
>> [2.12] ---[ end trace ceab04cd8881362f ]---
>> [2.13] gpiod_request: invalid GPIO
>> [2.14] gpio-export gpio_export: 0 gpio(s) exported
>>
>>
>> I'm wondering on the "GPIO -22". Checking the source of
>> drivers/gpio/gpiolib.c shows gpio is of type unsigned, large enough to
>> handle gpio#496.
>>
>> Any Idea what's going on?
>> Probably it's something related to the SoC-gpios and the additional pins 
>> defined from the pca9555
>>
>
> When using the following dts-file it improves, a bit:
> / {
> model = "UBNT-ERX-SFP";
>
> i2c-gpio {
> compatible = "i2c-gpio";
> gpios = < 3 GPIO_ACTIVE_HIGH /* sda */
>   4 GPIO_ACTIVE_HIGH /* scl */
> >;
> #address-cells = <1>;
> #size-cells = <0>;
>
> gpio_pca: pca9555@25 {
> compatible = "pca9555";
> reg = <0x25>;
you seem to be missing two properties here which indicate that this is
actually a GPIO controller:
#gpio-cells = <2>;
gpio-controller;

value 2 in #gpio-cells means that whenever you reference a GPIO (just
like you do in your poe_passthrough node) that the first parameter is
the pin number and the second parameter is the polarity (active
high/low)
gpio-controller should be self-explanatory

> };
> };
>
> gpio_export {
> compatible = "gpio-export";
> #size-cells = <0>;
>
> poe_passthrough {
> gpio-export,name = "poe_power_port0";
> gpio-export,output = <1>;
> gpios = <_pca 0 0>;
> };
>
> };
> };
>
> I think I got the trick to define a name for the PCA-gpio-chip and
> reference it in the gpio-export section.
> But it fails now with
> [ 1.64] /gpio_export/poe_passthrough: could not get #gpio-cells for 
> /i2c-gpio/pca9555@25
> [1.66] [ cut here ]
> [1.67] WARNING: CPU: 3 PID: 1 at drivers/gpio/gpiolib.c:85 
> 0x801dc2fc()
> [ 1.68] invalid GPIO -22
> [ 1.69] Modules linked in:
> [ 1.69] CPU: 3 PID: 1 Comm: swapper/0 Not tainted 4.4.61 #0
>
> seems not to find the i2c-pca and it's gpios, as these modules are not
> compile into the kernel.
> [   10.46] kmodloader: loading kernel modules from /etc/modules.d/*
> [   10.47] i2c /dev entries driver
> [   10.48] pca953x 0-0025: interrupt support not compiled in
> [   10.50] i2c-gpio i2c-gpio: using pins 3 (SDA) and 4 (SCL)
> [   10.51] PPP generic driver version 2.4.2
>
> They will load during init.scripts.
> I see following options:
> - use the 03-gpio script in board.d
> - compile the drivers into the kernel, but will this be done for all
>  mt7621-kernels?
>
>
>
>
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev

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

Re: [LEDE-DEV] ath79 - pending tasks

2017-03-01 Thread Martin Blumenstingl via Lede-dev 
The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
Hi Alan,

first I'd like to say thank you for your work on upstream ath79 support!

On Wed, Mar 1, 2017 at 2:32 PM, Alban  wrote:
> There is some basic support for the TL-WR-1043ND V2 (irqchip driver for
> the QCA955X EXT interrupt controller + DT) and for the ath9k.
>
> That is not yet in my github tree, but I'm currently working on adding
> nvmem support to load the eeprom data for the ath9k. With this and a few
> other details the ath9k should be fully usable with DT. I hope to be
> able to submit this soon enough that it could potentially be merged in
> 4.12.
I've also seen your RFC patch on the linux-wireless list. you may want
to split things to make it easier to review though (that's my personal
opinion):
1. add the 25MHz clock handling to the existing ath9k_of_init function
2. add OF support to ath9k/ahb.c
3. add devdata support (maybe to eeprom.c instead of ahb.c since there
are many boards with ath9k PCI without EEPROM - there devdata support
could be interesting as well)

with just 1. and 2. you should be able to get the ath9k AHB devices
running if you add the "qca,no-eeprom" property and then provide the
EEPROM data using a firmware hotplug script (see [0] and [1])


Regards,
Martin


[0] 
http://lxr.free-electrons.com/source/drivers/net/wireless/ath/ath9k/init.c#L574
[1] 
https://github.com/torvalds/linux/blob/fc383ffdb91a393086daf56c3d48a545e1cbd6e4/Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt

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

[LEDE-DEV] [PATCH] kernel: fix compile error on linux 4.9 with CONFIG_KALLSYMS disabled

2017-02-12 Thread Martin Blumenstingl via Lede-dev 
The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
Upstream linux commit 7523e4dc5057e "module: use a structure to
encapsulate layout." moves some of the struct module members into a
separate struct module_layout.

Signed-off-by: Martin Blumenstingl 
---
NOTE: This is compile-tested only

 target/linux/generic/patches-4.9/205-backtrace_module_info.patch | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/target/linux/generic/patches-4.9/205-backtrace_module_info.patch 
b/target/linux/generic/patches-4.9/205-backtrace_module_info.patch
index 67338973e8..25fe3751aa 100644
--- a/target/linux/generic/patches-4.9/205-backtrace_module_info.patch
+++ b/target/linux/generic/patches-4.9/205-backtrace_module_info.patch
@@ -12,7 +12,7 @@
  #endif
  
if (fmt[1] == 'R')
-@@ -684,11 +686,15 @@ char *symbol_string(char *buf, char *end
+@@ -684,11 +686,16 @@ char *symbol_string(char *buf, char *end
sprint_symbol(sym, value);
else
sprint_symbol_no_offset(sym, value);
@@ -25,7 +25,8 @@
 +  mod = __module_address(value);
 +  if (mod)
 +  snprintf(sym + len, sizeof(sym) - len, " [%s@%p+0x%x]",
-+   mod->name, mod->module_core, mod->core_size);
++   mod->name, mod->core_layout.base,
++   mod->core_layout.size);
  #endif
 +  return string(buf, end, sym, spec);
  }
-- 
2.11.1


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

Re: [LEDE-DEV] [OpenWrt-Devel] upstreaming (most) rt2x00 patches

2017-01-14 Thread Martin Blumenstingl via Lede-dev 
The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
On Sat, Jan 14, 2017 at 3:44 AM, Daniel Golle  wrote:
> Hi Martin,
>
> On Sat, Jan 14, 2017 at 01:28:06AM +0100, Martin Blumenstingl wrote:
>> On Thu, Jan 12, 2017 at 3:35 PM, Daniel Golle  wrote:
>> > Hi!
>> >
>> > The amount of patches on top of rt2x00 has grown into a huge pile
>> > during the past couple of years. To get things into a shape that allow
>> > discussing and merging them upstream, I created a tree on github based
>> > on wireless-drivers-next.git:
>> >
>> > https://github.com/dangowrt/linux/commits/rt2x00-from-openwrt
>> >
>> > I had to fix up some of Gabor's patches to still apply on the updated
>> > code base, but apart from those small fixes, things still apply cleanly
>> > on that tree.
>> > Imho the patch adding support for MT7620 still needs some more cleaning
>> > (I fixed some white-space and indention issues already), and both
>> > MT7620 and RT5350 still use mdelay and udelay which should be replaced
>> > in the same way done for other codepaths upstream. It'd also be great
>> > not to mess up RF and RT, ie. correctly set the RF value
>> > for RT5350 and MT7620 according to the actual RF IP used on those
>> > chips. Just for clarification, RT6352 was later renamed to MT7620
>> >
>> > I for now didn't add any of the EEPROM-related patches, I a suppose
>> > that only read_eeprom_from_mtd() should go upstream and all file and
>> > firmware-loading mechanics can be considered legacy.
>> are you sure about removing the firmware-loading mechanism? I recently
>> *added* this to ath9k upstream due to the following problems we had
>> with "ath9k calibration data":
>> 1. calibration data is stored inside a UBI volume on some ar71xx and
>> lantiq devices
>> 2. calibration data is stored on an unaligned offset inside the NOR
>> flash of some lantiq (Fritz Box) devices
>> 3. some calibration data is simply broken (vendors did a swab16(),
>> messing up the position of some fields so we need another swab16() to
>> get valid calibration data)
>
> I'm fully aware of that and fully agree with you.
> However, the current state of rt2x00 eeprom loading hacks wasn't in
> shape for being sent upstream imho, ie. obvious things like missing
> additions to Documentation/devicetree/bindings/ and remaining
> platform_data legacy make it unlikely to have those patches merged
> at this stage.
> Apart from that, Mathias Kresin has recently been improving EEPROM
> loading on rt2x00 and once all the rest is in shape upstream he should
> just submit that on top once completed and cleaned up (ie. patches
> adding EEPROM file reading in various ways if requested via device-tree
> should be folded up, legacy platform_data stuff should be omitted).
then I just misunderstood you, problem solved!

>> there's also a similar discussion going on for wl1251 because there
>> seem to be devices where the calibration data is obfuscated, etc.
>> see [0] for more information on the wl1251 topic
>
> Interesting. Does that mean that the N900 hardware is now fully
> supported by kernel.org/torvalds/linux.git ?
seems so, but I don't have a N900 and I've only been following the
discussion loosely

>> apart from that: thank you for taking the time to upstream this
>> (building a pile of patches which *could* be upstreamed and
>> maintaining them for a very long time doesn't make us better than all
>> the vendors with their custom stacks, so big thanks :))!
>
> I recently started seeing new hope in rt2x00 as things were already
> working quite nicely with our current patchset (apart from MT7620
> which imho still needs quite some more work. If noone else comes first
> I might do that at some point).
>
> Now the driver has also received a lot of improvements related to
> aggregation upstream, so it might finally get somewhere near to the
> performance seen with ath9k. Adding proper upstream support for the
> WiSoC chips seems crucial, given the popularity of chips like the
> Rt5350, also to open the doors to other vanilla Linux based
> distributions on those platforms.
I actually used a device with RT3062F a bit more than a year ago,
because the main device I tried to use had crashing ath10k firmware
(due to some platforms not liking DMA bursts: [0]) and really poor
ath9k performance (due to [1]).
the device with RT3062F "just worked".

(so much for the off-topic stuff...)


[0] https://patchwork.kernel.org/patch/7173811/
[1] https://www.spinics.net/lists/linux-wireless/msg138953.html

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

Re: [LEDE-DEV] [PATCH] lantiq: update USB controller handling

2017-01-06 Thread Martin Blumenstingl via Lede-dev 
The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
Hi Hauke,

(CC'ing Mathias as he was looking into some of the USB issues as well)

On Fri, Jan 6, 2017 at 8:06 PM, Hauke Mehrtens  wrote:
> This makes the code use the same settings aas the vendor sdrivers.
s/aas/as/
s/sdrivers/driver/
you should probably also mention that this:
1. backports USB initialization fixes for XRX300, Danube and Amazon-SE
2. sets the clock source for all SoCs which fixes USB (initialization)
issues on Danube when using the dwc2 driver (thus fixes FS#351 and
supersedes Mathias' "lantiq: set the usb clock source" RFC patch)

> Signed-off-by: Hauke Mehrtens 
> ---
>  target/linux/lantiq/dts/amazonse.dtsi  |   3 +-
>  target/linux/lantiq/dts/ar9.dtsi   |   6 +-
>  target/linux/lantiq/dts/danube.dtsi|   2 +-
>  target/linux/lantiq/dts/vr9.dtsi   |   6 +-
>  ...MIPS-lantiq-danube-initialize-usb-on-boot.patch |  10 -
>  .../patches-4.4/0041-USB-DWC2-add-ltq-params.patch |  75 
>  .../linux/lantiq/patches-4.4/0047-poweroff.patch   |   2 +-
>  ...2-Add-support-for-Lantiq-ARX-and-XRX-SoCs.patch |  78 
>  ...ke-the-lantiq-settings-match-vendor-drive.patch |  53 ++
>  .../patches-4.4/0062-USB-DWC2-add-ltq-params.patch |  47 +
>  ...65-MIPS-lantiq-improve-USB-initialization.patch | 202 
> +
>  ...x200-add-gphy-clk-src-device-tree-binding.patch |   6 +-
>  12 files changed, 395 insertions(+), 95 deletions(-)
>  delete mode 100644 
> target/linux/lantiq/patches-4.4/0039-MIPS-lantiq-danube-initialize-usb-on-boot.patch
>  delete mode 100644 
> target/linux/lantiq/patches-4.4/0041-USB-DWC2-add-ltq-params.patch
>  create mode 100644 
> target/linux/lantiq/patches-4.4/0060-usb-dwc2-Add-support-for-Lantiq-ARX-and-XRX-SoCs.patch
>  create mode 100644 
> target/linux/lantiq/patches-4.4/0061-USB-DWC2-make-the-lantiq-settings-match-vendor-drive.patch
>  create mode 100644 
> target/linux/lantiq/patches-4.4/0062-USB-DWC2-add-ltq-params.patch
>  create mode 100644 
> target/linux/lantiq/patches-4.4/0065-MIPS-lantiq-improve-USB-initialization.patch
>
> diff --git a/target/linux/lantiq/dts/amazonse.dtsi 
> b/target/linux/lantiq/dts/amazonse.dtsi
> index bce618fed8..2b8ad08140 100644
> --- a/target/linux/lantiq/dts/amazonse.dtsi
> +++ b/target/linux/lantiq/dts/amazonse.dtsi
> @@ -122,11 +122,12 @@
> };
>
> ifxhcd@E101000 {
> -   compatible = "lantiq,ifxhcd-ase";
> +   compatible = "lantiq,ase-usb", "lantiq,ifxhcd-ase";
> reg = <0xE101000 0x1000
> 0xE12 0x3f000>;
> interrupt-parent = <>;
> interrupts = <39>;
> +   dr_mode = "host";
> status = "disabled";
> };
>
> diff --git a/target/linux/lantiq/dts/ar9.dtsi 
> b/target/linux/lantiq/dts/ar9.dtsi
> index 569f25f02c..2638a4b268 100644
> --- a/target/linux/lantiq/dts/ar9.dtsi
> +++ b/target/linux/lantiq/dts/ar9.dtsi
> @@ -137,20 +137,22 @@
> };
>
> ifxhcd@E101000 {
> -   compatible = "lantiq,ifxhcd-arx100", 
> "lantiq,ifxhcd-arx100-dwc2";
> +   compatible = "lantiq,arx100-usb", 
> "lantiq,ifxhcd-arx100";
> reg = <0xE101000 0x1000
> 0xE12 0x3f000>;
> interrupt-parent = <>;
> interrupts = <62 91>;
> +   dr_mode = "host";
> status = "disabled";
> };
>
> ifxhcd@E106000 {
> -   compatible = "lantiq,ifxhcd-arx100-dwc2";
> +   compatible = "lantiq,arx100-usb";
> reg = <0xE106000 0x1000
> 0xE1E 0x3f000>;
> interrupt-parent = <>;
> interrupts = <91>;
> +   dr_mode = "host";
> status = "disabled";
> };
>
> diff --git a/target/linux/lantiq/dts/danube.dtsi 
> b/target/linux/lantiq/dts/danube.dtsi
> index f11787f975..83e85c36a5 100644
> --- a/target/linux/lantiq/dts/danube.dtsi
> +++ b/target/linux/lantiq/dts/danube.dtsi
> @@ -143,7 +143,7 @@
> };
>
> ifxhcd@E101000 {
> -   compatible = "lantiq,ifxhcd-danube-dwc2", 
> "lantiq,ifxhcd-danube";
> +   compatible = "lantiq,danube-usb", 
> "lantiq,ifxhcd-danube";
> reg = <0xE101000 0x1000
> 0xE12 0x3f000>;
>

Re: [LEDE-DEV] [PATCH] lantiq: fix console print

2017-01-05 Thread Martin Blumenstingl via Lede-dev 
The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
Hi Hauke,

sorry for the late reply - turns out I didn't have time to look into
this all week until now.

On Wed, Jan 4, 2017 at 11:11 PM, Hauke Mehrtens  wrote:
> The boot loader of many boards provides a kernel boot argument with a
> broken console parameter to the kernel. This will be taken before the
> stdout-path defined in device tree and the serial will not work on this
> board. Multiple boards are affected by this problem, so revert this
> patch for all boards. Later we can remove the boot arguments from the
> device tree again, after the individual board was checked to work.
>
> This partly reverts this commit:
> commit 4995c64857a09c4cc92238ba0bd52cdb06c4c581
> Author: Martin Blumenstingl 
> Date:   Sun Dec 11 21:55:00 2016 +0100
>
> lantiq: specify console using stdout-path instead of cmdline argument
nit picking here: your patch actually fixes
6b94234a6598b855573a6516494de8e7d755e944 because I removed the
bootargs in that patch -> the kernel only uses the bootloader's
cmdline if there are no bootargs inside the .dts

your change looks good to me, except for two boards (there might be
more, I don't have access to a computer with a sane operating system
at the momemnt) which are still missing the bootargs:
* ARV4525PW
* ARV8539PW22

both are including danube.dtsi which provided default bootargs for all
danube boards, see [0]
unfortunately I won't be able to send a patch until Sunday (fingers
crossed...), so it'd be awesome if someone else could do this.

thanks for un-breaking things I broke!

Regards,
Martin


[0] 
https://git.lede-project.org/?p=source.git;a=blobdiff;f=target/linux/lantiq/dts/danube.dtsi;h=f11787f9754c9f6d0a04bb100944a53ea6fd;hp=37db51245448fa09eb86fa0e70c1c230833db99a;hb=6b94234a6598b855573a6516494de8e7d755e944;hpb=4995c64857a09c4cc92238ba0bd52cdb06c4c581

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

Re: [LEDE-DEV] [PATCH] kernel: make fix extending dtb cmd with bootloader

2016-12-27 Thread Martin Blumenstingl via Lede-dev 
The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
On Tue, Dec 27, 2016 at 2:01 PM, Hauke Mehrtens  wrote:
>
>
> On 12/25/2016 07:12 PM, Martin Blumenstingl wrote:
>> Hi John, Hi Hauke,
>>
>> On Fri, Dec 9, 2016 at 8:08 AM, John Crispin  wrote:
>>>
>>>
>>> On 09/12/2016 00:21, Hauke Mehrtens wrote:
 This was introduced in kernel 4.4, but broken there and fixed in 4.5.
 I would like to activate it, but I am scared about the boot loader
 around giving us all sorts of command lines.

 Signed-off-by: Hauke Mehrtens 
>>>
>>> we had previously used a syntax of prepending the cmdline with +/- to
>>> indicate whether this should replace/extend the bootloader cmdline. the
>>> biggest problem is that the bootloaders will pass console= and root= and
>>> thus breaking boot. merging/activating this as is will most likely lead
>>> to 50% of lantiq boards not booting anymore. imho this feature should be
>>> an opt-in based on the specific board
>> Mathias just pointed me at a bug report [0] where I caused the exact
>> problem you described (with [1]).
>> When /chosen/bootargs is not defined the kernel falls back to using
>> the cmdline passed from the bootloader - breaking at least the console
>> in that specific case.
>>
>> maybe we should consider the following use-cases:
>> 1) bootloader passed bogus root=/console= parameters
>> 2) Hauke wants to specify root= himself in the bootloader (where Hauke
>> stands for "developer who wants to use NFS rootfs)
>
> It would be sufficient if this would be possible for some boards where
> I have also control over the boot loader. This way I can make sure they
> will not add wrong data.
I guess there may be other use-cases than just NFS rootfs - but I kept
it because IMHO it's a good example

>> 3) bootloader passes some valid parameters (for example ethaddr) -
>> could be the same bootloader as #1
>
> For Voice we also get some parameters to reserve memory for the
> firmware, but we can also handle this reservation in a different way.
> This would also not get upstream because upstream already have a better
> mechanism to do this, but it needs a modified firmware which works on
> virtual memory. This is also not board specific and can also be added
> statically into the device tree.
do we typically get these parameters from the bootloader and if we do:
is this the desired state?
I'm not an expert on this, but it seems to me that describing this
information using devicetree and reserved-memory seems to be the
"upstream way"

>> maybe we can brainstorm potential solutions which work in all cases:
>> - if we simply revert my patch we're fixing #1 but that would still
>> leave #2 and #3 unsolved
>
> I like your patch in general. ;-)
so do I, that's why I sent it. unfortunately I had a typo during my
tests and failed to see that I could actually use the bootloader to
pass the cmdline :(

>> - checking with upstream why the bootloader cmdline is used
>> (CONFIG_MIPS_CMDLINE_FROM_BOOTLOADER is not set in our kernel config),
>> but that would only fix #1
>> - not reverting my patch and enabling CONFIG_MIPS_CMDLINE_DTB_EXTEND
>> would work for #2 and #3 but leave #1 broken
>
> We could do CONFIG_MIPS_CMDLINE_DTB_EXTEND the other way around. let the
> dtb overwrite everything is gets from the boot loader.
but wouldn't that mean that we still had to duplicate the values (=
virtually reverting my patch) which we want to override in .dts (for
example if we don't want anyone to pass init, then we'd have to
specify init=/etc/preinit in our .dts, instead of just saying "I don't
want bootloader's init arg")?

>> - reverting my patch and enabling CONFIG_MIPS_CMDLINE_DTB_EXTEND would
>> fix #2 and #3 while #1 is broken again
>> - not reverting my patch, enabling CONFIG_MIPS_CMDLINE_DTB_EXTEND and
>> adding a "black- or white-listed bootargs from bootloader" per device
>> might work for all 3 (John, I guess this is what you meant with this
>> opt-in specific behavior?)
>
> I would like this approach, would it be possible to get this into mainline?
should we discuss this with the linux-mips or devicetree list (or even both)?


Regards,
Martin

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

Re: [LEDE-DEV] [PATCH] kernel: make fix extending dtb cmd with bootloader

2016-12-25 Thread Martin Blumenstingl via Lede-dev 
The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
Hi John, Hi Hauke,

On Fri, Dec 9, 2016 at 8:08 AM, John Crispin  wrote:
>
>
> On 09/12/2016 00:21, Hauke Mehrtens wrote:
>> This was introduced in kernel 4.4, but broken there and fixed in 4.5.
>> I would like to activate it, but I am scared about the boot loader
>> around giving us all sorts of command lines.
>>
>> Signed-off-by: Hauke Mehrtens 
>
> we had previously used a syntax of prepending the cmdline with +/- to
> indicate whether this should replace/extend the bootloader cmdline. the
> biggest problem is that the bootloaders will pass console= and root= and
> thus breaking boot. merging/activating this as is will most likely lead
> to 50% of lantiq boards not booting anymore. imho this feature should be
> an opt-in based on the specific board
Mathias just pointed me at a bug report [0] where I caused the exact
problem you described (with [1]).
When /chosen/bootargs is not defined the kernel falls back to using
the cmdline passed from the bootloader - breaking at least the console
in that specific case.

maybe we should consider the following use-cases:
1) bootloader passed bogus root=/console= parameters
2) Hauke wants to specify root= himself in the bootloader (where Hauke
stands for "developer who wants to use NFS rootfs)
3) bootloader passes some valid parameters (for example ethaddr) -
could be the same bootloader as #1

maybe we can brainstorm potential solutions which work in all cases:
- if we simply revert my patch we're fixing #1 but that would still
leave #2 and #3 unsolved
- checking with upstream why the bootloader cmdline is used
(CONFIG_MIPS_CMDLINE_FROM_BOOTLOADER is not set in our kernel config),
but that would only fix #1
- not reverting my patch and enabling CONFIG_MIPS_CMDLINE_DTB_EXTEND
would work for #2 and #3 but leave #1 broken
- reverting my patch and enabling CONFIG_MIPS_CMDLINE_DTB_EXTEND would
fix #2 and #3 while #1 is broken again
- not reverting my patch, enabling CONFIG_MIPS_CMDLINE_DTB_EXTEND and
adding a "black- or white-listed bootargs from bootloader" per device
might work for all 3 (John, I guess this is what you meant with this
opt-in specific behavior?)

I'm open for more ideas. I can also have a look at the implementation
of a patch once we decided on a solution.


Regards,
Martin


[0] https://bugs.lede-project.org/index.php?do=details_id=350
[1] 
https://git.lede-project.org/?p=source.git;a=commitdiff;h=6b94234a6598b855573a6516494de8e7d755e944

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

Re: [LEDE-DEV] [PATCH RFC 1/2] openvpn: update to 2.4_rc2

2016-12-25 Thread Martin Blumenstingl via Lede-dev 
The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
Hello Magnus, Hi Felix,

On Sat, Dec 17, 2016 at 1:53 AM, Magnus Kroken  wrote:
> OpenVPN 2.4 builds with mbedTLS 2.x, rename openvpn-polarssl
> variant to openvpn-mbedtls.
>
> Some feature highlights:
> * Data channel cipher negotiation
> * AEAD cipher support for data channel encryption (currently only AES-GCM)
> * ECDH key exchange for control channel
> * LZ4 compression support
it seems that there's a small compatibility problem for "older VPN
servers" with OpenVPN 2.4 and mbedTLS:
TLS-DHE-* ciphers don't seem to be supported anymore. I'm not sure if
that's a problem in real-world (I just upgraded to latest LEDE git
HEAD and found one of my VPN connections "broken" - but I can't tell
if this is whether that VPN-server was exotic or if it's a real-world
problem).

the list of avaiable TLS ciphers in LEDE's OpenVPN when using mbedTLS:
# openvpn --show-tls
TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384
TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384
TLS-ECDHE-ECDSA-WITH-AES-256-CBC-SHA384
TLS-ECDHE-RSA-WITH-AES-256-CBC-SHA384
TLS-ECDHE-ECDSA-WITH-AES-256-CBC-SHA
TLS-ECDHE-RSA-WITH-AES-256-CBC-SHA
TLS-ECDHE-ECDSA-WITH-AES-128-GCM-SHA256
TLS-ECDHE-RSA-WITH-AES-128-GCM-SHA256
TLS-ECDHE-ECDSA-WITH-AES-128-CBC-SHA256
TLS-ECDHE-RSA-WITH-AES-128-CBC-SHA256
TLS-ECDHE-ECDSA-WITH-AES-128-CBC-SHA
TLS-ECDHE-RSA-WITH-AES-128-CBC-SHA
TLS-RSA-WITH-AES-256-GCM-SHA384
TLS-RSA-WITH-AES-256-CBC-SHA256
TLS-RSA-WITH-AES-256-CBC-SHA
TLS-RSA-WITH-AES-128-GCM-SHA256
TLS-RSA-WITH-AES-128-CBC-SHA256
TLS-RSA-WITH-AES-128-CBC-SHA
TLS-PSK-WITH-AES-256-GCM-SHA384
TLS-PSK-WITH-AES-256-CBC-SHA384
TLS-PSK-WITH-AES-256-CBC-SHA
TLS-PSK-WITH-AES-128-GCM-SHA256
TLS-PSK-WITH-AES-128-CBC-SHA256
TLS-PSK-WITH-AES-128-CBC-SHA

I guess this worked on LEDE with PolarSSL with OpenVPN 2.3:
#define POLARSSL_KEY_EXCHANGE_DHE_RSA_ENABLED
while
//#define MBEDTLS_KEY_EXCHANGE_DHE_RSA_ENABLED

can you tell if I ran into some corner case (the affected server was
using OpenVPN 2.3.14, most probably with OpenSSL backend) or if this
is a real problem?


Regards,
Martin

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