Re: gpio-mt7621 offset fix for 5.10 kernel series

[Martin Blumenstingl via openwrt-devel]

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 Peter,

On Tue, Oct 18, 2022 at 9:34 PM Peter Naulls  wrote:
>
>
> Looks like there was some code loss when the driver came from an earlier 
> kernel
> series. Without this, my MT7621 board starts its GPIO offsets at 416 (why that
> number, I don't know):
You should also explain the problem with this behavior (if there's any).

Upstream kernel doc [0] mentions:
 * @base: identifies the first GPIO number handled by this chip;
 * or, if negative during registration, requests dynamic ID allocation.
 * DEPRECATION: providing anything non-negative and nailing the base
 * offset of GPIO chips is deprecated. Please pass -1 as base to
 * let gpiolib select the chip base in all possible cases. We want to
 * get rid of the static GPIO number space in the long run.

I never used it but my understanding is that the recommended way for
accessing GPIOs from userspace (in case that's what you need) should
be done through libgpiod.


Best regards,
Martin


[0] 
https://elixir.bootlin.com/linux/v4.14.295/source/include/linux/gpio/driver.h#L48

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

Re: [PATCH] uboot-fritz4040: build FritzBox 7520 variant

[Martin Blumenstingl via openwrt-devel]

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 Fri, Jul 15, 2022 at 8:02 AM Andre Heider  wrote:
>
> Support was added as variant of 7530 (DEVICE_ALT0_*) in:
> cb6f4be1 "ipq40xx: add support for FRITZ!Box 7520"
>
> u-boot has a distinct config for it [0], built it.
>
> [0] https://github.com/chunkeey/FritzBox-4040-UBOOT/pull/6
>
> Signed-off-by: Andre Heider 
Thanks for the patch! I got a cheap 7520 and flashed OpenWrt on it
using this patch. Everything works fine as far as I can tell, so:
Tested-by: Martin Blumenstingl 


Best regards,
Martin

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

Re: [PATCH] ltq-vdsl-app: disconnect when service is stopped

[Martin Blumenstingl via openwrt-devel]

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 Wed, Apr 27, 2022 at 8:00 PM Jan Hoffmann  wrote:
>
> Stop the connection when the control daemon is terminated. The code is
> a modified version of the termination routine in version 4.23.1 of the
> daemon (which doesn't support VR9 modems anymore).
>
> This could also be implemented by calling the acos and acs commands via
> dsl_cpe_pipe.sh in the init script. However, doing it in the daemon
> itself has the advantage of also working if it is terminated in another
> way (for example during sysupgrade).
>
> Signed-off-by: Jan Hoffmann 
sysupgrade with this patch in my tree doesn't break, so:
Tested-by: Martin Blumenstingl 

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

Re: [PATCH] ltq-vdsl/ltq-adsl: fix elapsed time calculation

[Martin Blumenstingl via openwrt-devel]

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 Mon, Apr 25, 2022 at 9:55 PM Jan Hoffmann  wrote:
>
> The driver maintains elapsed times by repeatedly accumulating the time
> since the previous update in a loop. For the elapsed showtime time, the
> time difference is truncated to seconds before adding it, leading to a
> sizable error over time.
>
> Move the truncation to before calculation of the time difference in
> order to remove this error. Also maintain the total elapsed time in the
> same way in full seconds, to prevent the unsigned 32-bit counter from
> wrapping around after about 50 days.
>
> Testing on a VR9 device shows that the reported line uptime now matches
> the actual elapsed wall time. The ADSL variant is only compile-tested,
> but it should also work as the relevant code is identical.
>
> Signed-off-by: Jan Hoffmann 
Tested-by: Martin Blumenstingl 

statistics seem fine to me with this, although I didn't test for 50+ days ;-)


Best regards,
Martin

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

Re: [PATCH] ltq-atm/ltq-ptm: avoid unnecessary build dependencies

[Martin Blumenstingl via openwrt-devel]

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 Mon, Apr 25, 2022 at 9:47 PM Jan Hoffmann  wrote:
>
> Right now, both ltq-adsl-mei and ltq-vdsl-mei are always built, even
> when they aren't necessary for the selected variant. This can cause the
> build to fail, for example ltq-vdsl-mei doesn't build successfully here
> on xway target due to the vectoring callback.
>
> Make these dependencies conditional on the specific package variants,
> so they are only built when actually needed.
>
> Signed-off-by: Jan Hoffmann 
Tested-by: Martin Blumenstingl 

This fixes a build issue on my local system when building the xway
subtarget with Linux 5.15.
Thank you Jan for identifying and fixing this!

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

Re: [PATCH 0/4] lantiq: fix VDSL2 vectoring

[Martin Blumenstingl via openwrt-devel]

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 Jan,

On Sun, Mar 13, 2022 at 10:17 PM Jan Hoffmann  wrote:
>
> For vectoring to work, the modem needs to send error reports to the
> vectoring control entity at the carrier office. With Lantiq VR9/VR10
> modems, a separate driver is needed to do this, which is currently
> missing in OpenWrt.
>
> In addition to that, the DSL connection may be interrupted at random
> intervals due to insufficient locking in the MEI driver. While this is
> technically not specific to vectoring, the additional interrupts from
> the error reports seem to trigger the issue.
>
> This patch set addresses both issues. The changes have been available
> in the forum [0] for some time now. Multiple users who previously
> experienced instability on vectoring-enabled VDSL2 lines have reported
> that these patches actually allow a stable connection.
I haven't experienced this personally. Still thank you for documenting
and working on this!

> Jan Hoffmann (4):
>   ltq-vectoring: add driver
>   ltq-vdsl-mei: enable vectoring error sample callback
>   ltq-vdsl-app: set MAC address for vectoring error reports
>   ltq-vdsl-mei: add locking to interrupt handler
I have tested these patches for a few days and they don't break my
HH5A so this gets my:
Tested-by: Martin Blumenstingl 


Best regards,
Martin

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

Re: [iwinfo PATCH 1/2] iwinfo: add support for indoor only chan restriction

[Martin Blumenstingl via openwrt-devel]

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 Ansuel,

below are a few comments from someone (me) who is not very familiar
with the whole topic. So please keep this in mind.

On Thu, Nov 18, 2021 at 5:42 PM Ansuel Smith  wrote:
>
> Some country permit a specific channel to be used only indoor.
country -> countries
indoor -> indoors

> Introduce a new restriction_flags entry to declare different restrition
restrition -> restrictions

[...]
> +   if 
> (freqs[NL80211_FREQUENCY_ATTR_INDOOR_ONLY])
> +   e->restricted_flags |= 
> IWINFO_FREQ_NO_OUTDOOR;
Is there a reason why _INDOOR_ONLY has to be translated to _NO_OUTDOOR?
Or in other words: why not simply IWINFO_FREQ_INDOOR_ONLY


Best regards,
Martin

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

Re: [RFT PATCH] ath9k: OF: qca, disable-(2|5)ghz => ieee80211-freq-limit

[Martin Blumenstingl via openwrt-devel]

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 Christian,

thank you for working on this!

On Fri, Oct 29, 2021 at 10:13 PM Christian Lamparter  wrote:
>
> OpenWrt maintains two special out-of-tree DT properties:
> "qca,disable-5ghz" and "qca,disable-2ghz". These are implemented
> in a mac80211 ath9k patch "550-ath9k-disable-bands-via-dt.patch".
>
> With the things being what they are, now might be a good
> point to switch the devices to the generic and upstream
> "ieee80211-freq-limit" property. This property is much
> broader and works differently. Instead of disabling the
> drivers logic which would adds the affected band and
typo: s/adds/add/

> channels. It now disables all channels which are not
> within the specified frequency range.
>
> Signed-off-by: Christian Lamparter 
apart from above typo this is:
Reviewed-by: Martin Blumenstingl 

as well as:
Tested-by: Martin Blumenstingl  # HH5A


Best regards,
Martin

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

Re: kernel: add a bridge feature for filtering BPDU packets on ports

[Martin Blumenstingl via openwrt-devel]

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, Sep 25, 2021 at 6:53 PM Martin Blumenstingl
 wrote:
>
> Hi Andre,
>
> On Sat, Sep 25, 2021 at 1:17 PM Andre Heider  wrote:
> [...]
> > With these 3 reverted (on top of da5bb885 "toolchain/gcc: switch to
> > version 11 by default") it works again:
> > Revert "hostapd: let netifd set bridge port attributes for snooping"
> > Revert "netifd: update to the latest version"
> > Revert "kernel: add a bridge feature for filtering BPDU packets on ports"
> thanks for investigating this!
>
> > With just the first 2 reverts it's still broken.
> I can confirm that reverting all three fixes communication between
> clients on the ath10k 802.11ac card on Home Hub 5A
> communication between a client connected to the ath9k 802.11bgn card
> and ath10k worked fine even without the revert on the Home Hub 5A.
it seems that commit 6cd54254e4bbe7ed2b71c17cb2d54ad7b0bc2991
("netifd: update to the latest version") fixed this issue for me


Best regards,
Martin

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

Re: kernel: add a bridge feature for filtering BPDU packets on ports

[Martin Blumenstingl via openwrt-devel]

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 Andre,

On Sat, Sep 25, 2021 at 1:17 PM Andre Heider  wrote:
[...]
> With these 3 reverted (on top of da5bb885 "toolchain/gcc: switch to
> version 11 by default") it works again:
> Revert "hostapd: let netifd set bridge port attributes for snooping"
> Revert "netifd: update to the latest version"
> Revert "kernel: add a bridge feature for filtering BPDU packets on ports"
thanks for investigating this!

> With just the first 2 reverts it's still broken.
I can confirm that reverting all three fixes communication between
clients on the ath10k 802.11ac card on Home Hub 5A
communication between a client connected to the ath9k 802.11bgn card
and ath10k worked fine even without the revert on the Home Hub 5A.


Best regards,
Martin

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

[PATCH v1 procd] watchdog: Add an info message if the watchdog reset the system

[Martin Blumenstingl via openwrt-devel]

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 ---
Investigating why a device has rebooted can be difficult, especially if
there's no output (for example during a kernel crash) on the serial
console. Some watchdog drivers can tell us if the watchdog has caused
the system to reboot. The corresponding WDIOF_CARDRESET flag is
documented as: "Card previously reset the CPU".

Add an info message if the watchdog supports the WDIOF_CARDRESET flag
and if the boot status indicates that the watchdog has previously reset
the system.

Signed-off-by: Martin Blumenstingl 
---
 watchdog.c | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/watchdog.c b/watchdog.c
index 9d770b4..39ae9ff 100644
--- a/watchdog.c
+++ b/watchdog.c
@@ -93,6 +93,35 @@ static int watchdog_set_drv_timeout(void)
return ioctl(wdt_fd, WDIOC_SETTIMEOUT, _drv_timeout);
 }
 
+static void watchdog_print_status(void)
+{
+   struct watchdog_info wdt_info;
+   int bootstatus;
+
+   if (wdt_fd < 0)
+   return;
+
+   if (ioctl(wdt_fd, WDIOC_GETSUPPORT, _info)) {
+   DEBUG(2, "Watchdog GETSUPPORT failed\n");
+   return;
+   }
+
+   if (!(wdt_info.options & WDIOF_CARDRESET)) {
+   DEBUG(2, "Watchdog does not have CARDRESET support\n");
+   return;
+   }
+
+   if (ioctl(wdt_fd, WDIOC_GETBOOTSTATUS, )) {
+   DEBUG(2, "Watchdog GETBOOTSTATUS failed\n");
+   return;
+   }
+
+   if (bootstatus & WDIOF_CARDRESET)
+   LOG("Watchdog has previously reset the system\n");
+   else
+   DEBUG(2, "Watchdog did not previously reset the system\n");
+}
+
 void watchdog_set_magicclose(bool val)
 {
wdt_magicclose = val;
@@ -170,6 +199,8 @@ void watchdog_init(int preinit)
watchdog_timeout_cb(_timeout);
 
DEBUG(4, "Opened watchdog with timeout %ds\n", watchdog_timeout(0));
+
+   watchdog_print_status();
 }
 
 
-- 
2.32.0


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

Re: OpenWrt 21.02: backport lantiq xrx200 DSA switch

[Martin Blumenstingl via openwrt-devel]

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 Martin,

On Thu, Jul 1, 2021 at 8:02 AM Martin Schiller  wrote:
>
> Hello all!
>
> Now that the Lantiq xrx200 DSA switch has finally made it into the
> master, I would like to ask whether we also want to pack this switch
> into the 21.02 release.
The DSA changes were tested on multiple devices (before the pull
request was merged).
Also I think backporting this to 21.02 would make many people in the
Home Hub 5A community happy, as they've been waiting for this for some
time now.

> The topic "DSA Support" is one of the key points of the 21.02 release
> and therefore this would fit very well.
>
> Any opinions?
In general I am fine with backporting this.
The part that I am not sure about is the OpenWrt release schedule for
21.02 - so I'll let others comment on this.


Best regards,
Martin

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

Re: [PATCH] ltq-deu: Mark lantiq DEU broken

[Martin Blumenstingl via openwrt-devel]

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,

On Sun, Jun 27, 2021 at 8:57 PM Hauke Mehrtens  wrote:
>
> On 6/27/21 9:38 AM, Martin Blumenstingl wrote:
> > Hi Hauke,
> >
> > On Sun, Jun 27, 2021 at 12:55 AM Hauke Mehrtens  wrote:
> >>
> >> When the ltq_deu_vr9 kernel module is loaded, hostapd does not start any
> >> more. it fails with thgis error message:
I just noticed a typo here:
thgis -> this

[...]
> Should we also remove the deu from the default images in OpenWrt 21.02?
>
> I would still build it, but not package it in the default images, it
> could be that more operations trigger this problem.
makes sense to me as I haven't noticed any missing functionality after
switching from Linux 5.4 to 5.10
allowing users to still install it as package still means we have some
backup plan (at least for OpenWrt 21.02) in case someone finds why
it's needed


Best regards,
Martin

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

Re: [PATCH] ltq-deu: Mark lantiq DEU broken

[Martin Blumenstingl via openwrt-devel]

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,

On Sun, Jun 27, 2021 at 12:55 AM Hauke Mehrtens  wrote:
>
> When the ltq_deu_vr9 kernel module is loaded, hostapd does not start any
> more. it fails with thgis error message:
> daemon.err hostapd: nl80211: kernel reports: key addition failed
> daemon.err hostapd: Interface initialization failed
>
> OpenWrt uses the standard Linux crypto API in the wifi drivers now
> and this probably makes the system offload more crypto operations to
> special hardware like the Lantiq DEU. There is probably a bug in the DEU
> and these operations fail and then hostapd does not start the interface.
>
> Just mark the Lantiq DEU as broken for now.
>
> Fixes: FS#3901
> Fixes: 53b6783907f3 ("mac80211: remove patches stripping down crypto support")
> Signed-off-by: Hauke Mehrtens 
I am testing wifi with Linux 5.10 only these days where ltq-deu is
disabled anyways
so feel free to add my:
Acked-by: Martin Blumenstingl 

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

Re: [PATCH 2/3] base-files: failsafe: Start also CPU interface for DSA

[Martin Blumenstingl via openwrt-devel]

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, Jun 19, 2021 at 8:39 PM Hauke Mehrtens  wrote:
>
> On a DSA switch the ports have an upper device, the CPU device, e.g.
> eth0. This device has to be in up state to bring up the lower devices
> like lan1.
>
> Parse the link device from "ip link show" and bring it into up stated
> before bringing up the actual interface.
>
> This is needed to make network in failsafe on systems with DSA work.
>
> Signed-off-by: Hauke Mehrtens 
if you're keeping this patch instead of going with the backport you can add my:
Tested-by: Martin Blumenstingl  #
BT Home Hub 5A with DSA patches

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

Re: [PATCH 1/3] base-files: failsafe: Fix IP configuration

[Martin Blumenstingl via openwrt-devel]

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, Jun 19, 2021 at 8:39 PM Hauke Mehrtens  wrote:
>
> Adapt the preinit_config_board() to the board.json network changes. It
> now looks for the device and the ports variables to configure the LAN
> network.
>
> This works with swconfig configurations.
>
> Fixes: FS#3866
> Fixes: d42640e389a8 ("base-files: use "ports" array in board.json network for 
> bridges")
> Signed-off-by: Hauke Mehrtens 
Tested-by: Martin Blumenstingl  #
BT Home Hub 5A with DSA patches

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

Re: Re: [OpenWrt-Devel] mt76x8: Strange GPIO numbering on Onion Omega2+

[Martin Blumenstingl via openwrt-devel]

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 Lukas,

On Sat, Jun 12, 2021 at 9:49 PM Lukas Zeller  wrote:
>
> Hi Gerd,
>
> > There is still one major issue migrating to 21.02 on my side: Reboot 
> > doesn't work. I need to switch power off/on on my Omega2+. AFAIU it has 
> > somethoing to do with the SPI 3byte/4byte mode. Older versions worked, but 
> > 4byte mode seems to boot faster. BTW: spi-nor spi0.0: mx25l25635e (32768 
> > Kbytes)
>
> This is a hardware problem of the Omega2+ (so further details -> probably off 
> topic for here). But in short: The SPI flash chip must be in 3-byte mode for 
> the MT7688 to start the way CHIP_MODE pins are wired in the Omega2. A power 
> cycle resets the flash to 3 byte mode, however just a SoC reset does not, and 
> if the SPI chip is in 4 byte mode when the reset occurs, the MT7688 will try 
> to boot in 3 byte mode from a chip that is in 4 byte mode.
There is a "broken-flash-reset" property which probably is missing in
the Omega2+ .dts(i) files
See target/linux/ramips/dts/mt7621_gnubee_gb-pc1.dts for an example on
how it's used

If you have already considered this and my comment does not apply then
please ignore it (I am not familiar with any of the Ralink/Mediatek
SoCs, I just recognized this problem description)


Best regards,
Martin


[0] 
https://elixir.bootlin.com/linux/v5.4.48/source/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt#L72

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

Re: [PATCH] tools: fix ninja build dependency

[Martin Blumenstingl via openwrt-devel]

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, Jun 12, 2021 at 2:15 PM Bjørn Mork  wrote:
>
> Fixing this build error:
>
>  make[3]: Entering directory '/p/tools/ccache'
>  MAKEFLAGS="" /p/staging_dir/host/bin/ninja  -j1 -C 
> /p/build_dir/host/ccache-4.2.1
>  bash: /p/staging_dir/host/bin/ninja: No such file or directory
>  make[3]: *** [Makefile:43: /p/build_dir/host/ccache-4.2.1/.built] Error 127
>  make[3]: Leaving directory '/p/tools/ccache'
>  time: tools/ccache/compile#0.03#0.00#0.04
>  ERROR: tools/ccache failed to build.
>  make[2]: *** [tools/Makefile:158: tools/ccache/compile] Error 1
>
> Fixes: 97258f53634d ("build: add ninja build tool and make it available for 
> cmake")
> Signed-off-by: Bjørn Mork 
Felix pushed a fix like 1.5 hours ago: [0]
to me your patch looks identical to Felix'


Best regards,
Martin


[0] 
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=d45baa860ffc79ae1cf68fceb94990e39bb06bab

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

Re: lantiq: upstream Linux efforts

[Martin Blumenstingl via openwrt-devel]

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 everyone,

On Sun, Apr 11, 2021 at 7:51 PM Martin Blumenstingl
 wrote:
[...]
> To improve the situation I suggest using Rafał Miłecki's approach also
> for the lantiq target:
> He is submitting patches upstream, then backporting them to OpenWrt.
> That way backports to the -stable tree are for free.
> Other patches can simply be dropped during the next major kernel
> version update (instead of having to rework them every time...).
it's great to hear that there's lots of positive feedback for this idea!

[...]
> Therefore I would like to know who is interested in upstreaming more
> patches and cleaning up some of the code which already exists
> upstream?
I started a repository to document the upstreaming status: [0]
Aleksander, Hauke, Martin Schiller and Mathias should have
write-access. Please feel free to add more TODOs  there
The idea is that we can find topics where multiple people are
interested in and also avoid duplicated work


Best regards,
Martin


[0] https://github.com/xdarklight/ltq-upstream-status

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

Re: lantiq: upstream Linux efforts

[Martin Blumenstingl via openwrt-devel]

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 Martin,

On Mon, Apr 12, 2021 at 11:59 AM Martin Schiller  wrote:
[...]
> >> This approach however only works when there are active contributors
> >> upstream.
> >> It brings the benefit of upstream code-reviews though - which in my
> >> experience improves the quality of the resulting code.
>
> I think there's quite a bit of work involved.
I don't expect that it'll be an easy task
in my opinion the first step is to reject new patches which are not
following this approach
then we need to work out how to clean up the remaining parts

> If you take for example the patch with the configurability of the LEDs
> on the phys:
> Hauke had already started one or more attempts to bring this upstream
> [1], but this was "rejected" with the reason that this belongs in the
> LED subsystem.
>
> Now I found an interesting solution on the mailing list, which
> implements this function as hw offloading of the netdev trigger. [2]
I think the original author abandoned this (unfortunately)
maybe there's not too many issues left with that series?

> Furthermore there are some patches for the target lantiq, which
> unfortunately don't contain any description and so we have to work out
> the deeper sense or necessity of this patch again.
yep, agreed.


Best regards,
Martin

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

Re: lantiq: upstream Linux efforts

[Martin Blumenstingl via openwrt-devel]

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,

On Mon, Apr 12, 2021 at 12:24 AM Hauke Mehrtens  wrote:
[...]
> > Therefore I would like to know who is interested in upstreaming more
> > patches and cleaning up some of the code which already exists
> > upstream?
> > Saying that you are not interested is fine, there is no pressure on anyone.
>
> Currently I do not plan to upstream anything for the lantiq target, but
> I can help someone when he works on this topic.
>
> Thanks for your work on the DSA switch and fixing all the bugs in there.
Having someone to discuss problems and to give some answers or hints
from the datasheet has been very helpful. So also thanks to you :-)

> What do you plan to do about the other patches still in the lantiq
> target like the PCIe driver?
I do have a few patches sitting in my tree which add the necessary
bits for the Lantiq SoCs to the
drivers/pci/controller/dwc/pcie-intel-gw.c driver (which is upstream
since Linux 5.6)
unfortunately this requires some extra work, including changes to the
PCI driver (which needs to move away from the MIPS specific PCI bits
and over to the "generic" PCI subsystem)
That said, working on that is going to be easier when we have Linux
5.10 support (even if it's just the testing kernel version)


Best regards,
Martin

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

lantiq: upstream Linux efforts

[Martin Blumenstingl via openwrt-devel]

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 everyone,

you are included in this email because you have previously worked on
patches for the Lantiq SoCs upstream.

In the past updating the kernel version for the lantiq target in
OpenWrt was an unpleasant task.
There are many out-of-tree patches and some of them are breaking with
newer kernel versions.

To improve the situation I suggest using Rafał Miłecki's approach also
for the lantiq target:
He is submitting patches upstream, then backporting them to OpenWrt.
That way backports to the -stable tree are for free.
Other patches can simply be dropped during the next major kernel
version update (instead of having to rework them every time...).

This approach however only works when there are active contributors upstream.
It brings the benefit of upstream code-reviews though - which in my
experience improves the quality of the resulting code.

Therefore I would like to know who is interested in upstreaming more
patches and cleaning up some of the code which already exists
upstream?
Saying that you are not interested is fine, there is no pressure on anyone.


Best regards,
Martin

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

[no subject]

[Martin Blumenstingl via openwrt-devel]

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 Adrian,

On Wed, Sep 30, 2020 at 9:11 PM Adrian Schmutzler
 wrote:
>
> Hi Martin,
>
> > -Original Message-
> > From: Martin Blumenstingl [mailto:martin.blumensti...@googlemail.com]
> > Sent: Mittwoch, 30. September 2020 20:55
> > To: Adrian Schmutzler 
> > Cc: openwrt-devel@lists.openwrt.org
> > Subject: Re: [RFC PATCH] ath79: remove model name from LED labels
> >
> > Hi Adrian,
> >
> > On Sat, Sep 26, 2020 at 6:33 PM Adrian Schmutzler
> >  wrote:
> > [...]
> > > Apart from our needs, upstream has deprecated the label property
> > > entirely and introduced new properties to specify color and function
> > > properties separately. However, the implementation does not appear to
> > > be ready and probably won't become ready and/or match our
> > requirements
> > > in the foreseeable future.
> > I recently did an experiment with the color and function properties and it's
> > working well for me with my F9K1115V2 to make it work I had to come up
> > with a (simple) patch that parses the "color" property: [0]
> >
> > there's no feedback in this mail - my goal is to understand what the 
> > concerns
> > are so I don't "just" start porting some of my boards to the new way that's
> > recommended upstream only to see this patch then being rejected in
> > OpenWrt.
>
> My initial idea was to go the same way; have a look at these two comment 
> where I summarized the response from upstream and why I consider that not 
> helpful:
>
> https://github.com/openwrt/openwrt/pull/3437#issuecomment-696377807
> https://github.com/openwrt/openwrt/pull/3437#issuecomment-699492366
Thanks for the background info!

> Apart from that, I'm aware that we obviously have the option to _partially_ 
> implement the upstream solution, i.e. use the color ids and just put the last 
> part of the former label into function. However, as discussed in the 
> referenced comments, this would essentially be an abuse of "function" as far 
> as upstream sees it: We should create the corresponding LED_FUNCTION entries 
> instead of putting strings into "function" directly, and my proposals for 
> adding some of them were rejected.
> Of course, we could just ignore that, and put into function what we like. 
> That would work perfectly, it's just a little more complicated to implement 
> in user-space as your patch shows. Nevertheless, I just hesitate to implement 
> a system against its intention (color/function) when we have an alternate 
> solution that we can use as intended (label).
I see

> Apart from that, as stated in the referenced comments, your solution will 
> break anyway when kernel starts to use the devicename strings again for 
> internal "devices" like phy0/wlan0/etc. as proposed in the discussion at 
> linux-leds (e.g. wlan0:green:activity instead of green:wlan2g).
it will break again for anything that requires setting the default
trigger from userspace
my hope is that most LEDs will not need userspace handling for their
default behavior anymore, for example all LAN or wifi activity LEDs.
I'm not sure about corner-cases though (for example: 2GHz wifi
specific WPS LED- if that's used anywhere)

> As I said in the PR, unfortunately all of this is essentially very 
> unsatisfying at the moment. So, what I plan to do with the labels is as much 
> improvement as I can get for now.
my personal opinion: I would skip this intermediate step and work with
upstream to implement the LED-triggers where needed. Then backport
these patches and switch to that ABI. Rafał did this with
ledtrig-usbport
that is because I'm not sure how hard the migration for this
intermediate step is. if much effort is required then I'd rather spend
time on something that will be usable in the future rather than
spending time on some temporary solution


Best regards,
Martin

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

[no subject]

[Martin Blumenstingl via openwrt-devel]

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 Adrian,

On Sat, Sep 26, 2020 at 6:33 PM Adrian Schmutzler
 wrote:
[...]
> Apart from our needs, upstream has deprecated the label property
> entirely and introduced new properties to specify color and
> function properties separately. However, the implementation does
> not appear to be ready and probably won't become ready and/or
> match our requirements in the foreseeable future.
I recently did an experiment with the color and function properties
and it's working well for me with my F9K1115V2
to make it work I had to come up with a (simple) patch that parses the
"color" property: [0]

there's no feedback in this mail - my goal is to understand what the
concerns are so I don't "just" start porting some of my boards to the
new way that's recommended upstream only to see this patch then being
rejected in OpenWrt.


Thank you!
Martin


[0] 
https://github.com/xdarklight/openwrt/commit/eddaa9004f1897688a15befbd37234f9de1a7ae1.patch

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

[no subject]

[Martin Blumenstingl via openwrt-devel]

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 Luca,

On Sun, Jul 5, 2020 at 3:07 PM Luca Olivetti  wrote:
>
> El 5/7/20 a les 13:59, Luca Olivetti ha escrit: escrit:
>
> > I'm recompiling again in case I misplaced the section in my previous
> > test. In ~30-40 minutes it should be ready and I'll report back.
>
> Success!
> I probably did something wrong before.
> I'm attaching the patch against 19.07.3 and my device, but I think the
> same should be done for trunk and other devices with a similar dts.
please let me know if I should be sending the patch for master
(previously known as "trunk").
I have no way of testing it, but with your test results I'm confident
that it'll work


Best regards,
Martin

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

[no subject]

[Martin Blumenstingl via openwrt-devel]

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 Luca,

On Sun, Jul 5, 2020 at 1:42 PM Luca Olivetti  wrote:
>
> El 5/7/20 a les 13:29, Martin Blumenstingl ha escrit:
> > Hi Luca,
> >
> > On Sun, Jul 5, 2020 at 1:07 PM Luca Olivetti  wrote:
> > [...]
> >> I put a printk in every step of reg_fixed_regulator_probe
> >> (drivers/regulator/fixed.c) and it seems it isn't called at all (my
> >> strings are indeed compiled in fixed.o).
> >>
> >> Why is that? Perhaps an error in the dts?
> > unfortunately you have only given an extract of your changes instead
> > of the full patch, which means I don't have much context and have to
> > guess
>
> No, now I was talking about the original dts.
ah, now I understand

> >
> >> I checked and it seems the same as other devices in 19.07.3, the only
> >> difference is the section (most devices have it in the first section
> >> while here it is in the  section) and the name after the colon
> >> (most use no name at all after the colon or the same as before, i.e.
> >> here it would be usb_vbus: usb_vbus ).
> >>
> >> This is the definition in the dts
> >>
> >>
> >>   usb_vbus: regulator-usb-vbus {
> >>   compatible = "regulator-fixed";
> >>
> >>   regulator-name = "USB_VBUS";
> >>
> >>   regulator-min-microvolt = <500>;
> >>   regulator-max-microvolt = <500>;
> >>
> >>   gpio = < 14 GPIO_ACTIVE_HIGH>;
> >>   enable-active-high;
> >>   };
> > assuming that board uses GPIO 14 with polarity "active high" this part
> > seems correct to me
> >
> > have you tried moving it out of the  node (and placing it similar
> > to what for example
> > target/linux/lantiq/files-5.4/arch/mips/boot/dts/lantiq/vr9_bt_homehub-v5a.dts
> > in master uses)?
>
> Yes, no change
no change means the regulator-fixed driver is still not probed?
it's working fine for me on my BT Home Hub 5A, so I'm surprised to
find that it's not working for you.
Here's what I'm seeing:
# find /proc/device-tree/ -name "regulator-usb-vbus"
/proc/device-tree/regulator-usb-vbus
# grep "regulator-usb-vbus" /sys/kernel/debug/gpio
gpio-495 (|regulator-usb-vbus  ) out hi


Best regards,
Martin

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

[no subject]

[Martin Blumenstingl via openwrt-devel]

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 Luca,

On Sun, Jul 5, 2020 at 1:07 PM Luca Olivetti  wrote:
[...]
> I put a printk in every step of reg_fixed_regulator_probe
> (drivers/regulator/fixed.c) and it seems it isn't called at all (my
> strings are indeed compiled in fixed.o).
>
> Why is that? Perhaps an error in the dts?
unfortunately you have only given an extract of your changes instead
of the full patch, which means I don't have much context and have to
guess

> I checked and it seems the same as other devices in 19.07.3, the only
> difference is the section (most devices have it in the first section
> while here it is in the  section) and the name after the colon
> (most use no name at all after the colon or the same as before, i.e.
> here it would be usb_vbus: usb_vbus ).
>
> This is the definition in the dts
>
>
>  usb_vbus: regulator-usb-vbus {
>  compatible = "regulator-fixed";
>
>  regulator-name = "USB_VBUS";
>
>  regulator-min-microvolt = <500>;
>  regulator-max-microvolt = <500>;
>
>  gpio = < 14 GPIO_ACTIVE_HIGH>;
>  enable-active-high;
>  };
assuming that board uses GPIO 14 with polarity "active high" this part
seems correct to me

have you tried moving it out of the  node (and placing it similar
to what for example
target/linux/lantiq/files-5.4/arch/mips/boot/dts/lantiq/vr9_bt_homehub-v5a.dts
in master uses)?
background info: device-tree nodes can not be placed in random
locations within the .dts. all nodes below top-level (where the model
property is defined for example) are supported. for all other nodes it
depends on the (driver) implementation: all nodes with compatible =
"simple-bus" are also scanned for child-nodes. However, any node
placed for example below the _phy node (I didn't check the 
implementation to see if it's the same) will NOT be scanned (because
the driver doesn't support that).

in case moving the _vbus node fixes it we probably have to fix
three more boards as the following four all place _vbus inside
 (on master, only looking at Linux 5.4):
- target/linux/lantiq/files-5.4/arch/mips/boot/dts/lantiq/ar9_zyxel_p-2601hn.dts
- 
target/linux/lantiq/files-5.4/arch/mips/boot/dts/lantiq/danube_arcadyan_arv752dpw.dts
- 
target/linux/lantiq/files-5.4/arch/mips/boot/dts/lantiq/danube_arcadyan_arv7510pw22.dts
- 
target/linux/lantiq/files-5.4/arch/mips/boot/dts/lantiq/danube_arcadyan_arv7518pw.dts

> Oh, and is there a quick way to test modifications to the dts? Every
> time I invoke make, even for a trivial change, it takes 40 minutes.
I don't know about this part of the OpenWrt build-system so I'm
passing this questions to somebody else


Best regards,
Martin

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

[no subject]

[Martin Blumenstingl via openwrt-devel]

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,

On Tue, Jun 23, 2020 at 11:43 AM John Crispin  wrote:
[...]
> @@ -1414,6 +1413,8 @@ wireless_device_notify(struct wireless_device *wdev, 
> struct blob_attr *data,
> if (*pdata)
> return UBUS_STATUS_INVALID_ARGUMENT;
>
> +   if (*pdata)
> +   free(*pdata);
there's another "if (*pdata)" right above this one which returns
(UBUS_STATUS_INVALID_ARGUMENT) from that function.
I'm probably missing something so to me it seems as if the new "if
(*pdata)" is not reachable


Martin

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

Re: [OpenWrt-Devel] [PATCH] lantiq: fritz7312: set maximum speed to 100 mbit on 5.4

[Martin Blumenstingl via openwrt-devel]

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 Adrian,

On Thu, Jun 18, 2020 at 11:49 AM Adrian Schmutzler
 wrote:
>
> The fritz 7312 does not support 1000 gbit. Advertising it makes it
> worse. Some NIC will change to 1000 gibt and turn off and on again for
> ever.
>
> The previous patch in 36f628910b8b was only applied to the 4.19 file.
according to [0] the 7312 has a 10/100Mbit/s Atheros AR8030-A PHY.
Do you know why it's advertising Gbit/s capabilities nevertheless?

I won't say "no" to this patch
If it's a hardware issue then more boarding will benefit from a fix in
the ar803x PHY driver.


Best regards,
Martin


[0] https://boxmatrix.info/wiki/FRITZ!Box_7312

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

Re: [OpenWrt-Devel] [PATCH] bcm63xx: a226m-fwb: fix linux partition offset

[Martin Blumenstingl via openwrt-devel]

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 Daniel,

On Mon, Jun 15, 2020 at 7:52 PM Daniel González Cabanelas
 wrote:
[...]
> diff --git a/target/linux/bcm63xx/dts/bcm6358-pirelli-a226m-fwb.dts 
> b/target/linux/bcm63xx/dts/bcm6358-pirelli-a226m-fwb.dts
> index d0b1e55213..b477fb40de 100644
> --- a/target/linux/bcm63xx/dts/bcm6358-pirelli-a226m-fwb.dts
> +++ b/target/linux/bcm63xx/dts/bcm6358-pirelli-a226m-fwb.dts
> @@ -109,7 +109,7 @@
>
> linux@1 {
please update the unit-address (above) as well, otherwise tools (like
dtc) may start to complain


Martin

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

Re: [OpenWrt-Devel] [RFC PATCH] ramips: remove patches for USB-dwc2

[Martin Blumenstingl via openwrt-devel]

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,

On Wed, Apr 22, 2020 at 1:21 AM Alexey Dobrovolskiy
 wrote:
>
> Hi,
> USB does not work in master at 35f208da3c built with testing kernel
> 5.4 with or without 0032-USB-dwc2-add-device_reset.patch.
> (ramips, ZyXEL Keenetic)
> In boot log:
> [6.888293] usbcore: registered new interface driver usbfs
> [6.899641] usbcore: registered new interface driver hub
> [6.910630] usbcore: registered new device driver usb
> [6.930904] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
> [6.955086] SCSI subsystem initialized
> [6.970394] ehci-fsl: Freescale EHCI Host controller driver
> [6.985235] ehci-platform: EHCI generic platform driver
> [7.00] dwc2 101c.otg: Configuration mismatch. dr_mode forced to 
> host
> [7.033189] dwc2 101c.otg: dwc2_core_reset: HANG! AHB Idle
> timeout GRSTCTL GRSTCTL_AHBIDLE
> [7.050637] dwc2: probe of 101c.otg failed with error -16
> [7.074662] usbcore: registered new interface driver usb-storage
>
> Full log attached to FS#2964
We had a similar issue on the Lantiq SoCs a while ago.
Based on these issues we submitted the following patches upstream:
- [0] usb: dwc2: use a longer AHB idle timeout in dwc2_core_reset()
- [1] usb: dwc2: use a longer core rest timeout in dwc2_core_reset()

while looking at target/linux/ramips/dts/rt3050.dts I observed that it uses:
  reset-names = "otg";
while the dwc2 driver actually [2] expects:
  reset-names = "dwc2";

quick disclaimer: I don't own any ramips based hardware, so I don't
expect that I'll be able to look further into this issue.


Regards
Martin


[0] 
https://github.com/torvalds/linux/commit/dfc4fdebc5d62ac4e2fe5428e59b273675515fb2
[1] 
https://github.com/torvalds/linux/commit/6689f0f4bb14e50917ba42eb9b41c25e0184970c
[2] 
https://elixir.bootlin.com/linux/v5.4.34/source/drivers/usb/dwc2/platform.c#L215

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

Re: [OpenWrt-Devel] Port labels for DSA targets/devices

[Martin Blumenstingl via openwrt-devel]

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 Adrian,

(sorry for being slightly off-topic)

On Mon, Apr 20, 2020 at 9:42 PM  wrote:
> recently, ramips/mt7621 has switched to DSA and mvebu [1] and kirkwood [2] 
> are waiting for it.
are these targets using any migration scripts?
my understanding is that a migration script (or rather the lack
thereof) is preventing us to switch to DSA for the Lantiq VRX200
target on 5.4
however, if a migration script is not mandatory then I might as well
consider switching 5.4 to DSA so there will be one release where many
targets switch from swconfig to DSA


Martin

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

Re: [OpenWrt-Devel] [RFC][lantiq] Custom PHY and ethernet/switch driver

[Martin Blumenstingl via openwrt-devel]

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 Andreas,

On Sat, Mar 28, 2020 at 11:27 AM Andreas Böhler  wrote:
[...]
> What is the current state in switching to the upstream DSA switch driver?
> Can both drivers be handled, i.e. DSA for newly added devices and the
> legacy driver for older devices?
> Which driver should I target first, the legacy xrx200 or the DSA driver?
personally I would like to switch to the upstream DSA driver as soon
as possible.
this reduced the maintenance overhead when updating kernel versions

there's also some people (see recent mails) working on ARX300 support.
I fear that they may need to change the Ethernet driver and having an
out-of-tree driver just means that the work has to be done twice.

on IRC I asked about the DSA migration as well (that was some weeks ago).
here's the relevant conversation:
 Hauke: how about switching to the DSA driver for 5.4? I
don't want to mess with the GPHY loader and the out-of-tree Ethernet
driver
 xdarklight: I would like to swithc to the DSA driver
 but we probably need some migration path
 Hauke: maybe we can share a TODO-list somewhere so we can
write down everything that comes to our mind and then work on it
one-by-one
 Hauke: I think it makes sense to switch to dsa without migration
 the wish for migration scripts exists for at least two years
(on mvebu and ipq806x) - and it's a good idea in principle, but
/etc/config/network is complex - and may be very complex at times (and
lantiq with the VLAN tagging necessary for multiple xDSL ISPs is not
an exception to that rule), so making migration support a requirement
probably ends up in a self-fullfilling prophecy to never switch to
 DSA (just because writing these scripts in a way that makes
them remotely safe to use is somewhere between very hard and close to
impossible)
 we do need to some enhance the existing for defining
vlan membership, pvids etc with vlan_aware bridges
 yes
 and this time we should define how the config should look like,
then implement it
 to avoid inconsistencies and poor config layout like with
swconfig in the past
 Hauke: I suggest switching to DSA without migration as well.
The biggest problem is the one CPU port issue. Needs a patch.

so to me it seems that the swconfig to DSA migration is needed by
Lantiq and multiple other targets as well (mvebu and ipq806x are
listed above, but I think also ath79 is affected due to some qca8k
switches for which OpenWrt is using an out-of-tree driver)
unfortunately I have zero experience in that area and no insight into
the requirements needed for this migration (for me personally
resetting the network config to defaults when upgrading to a DSA based
OpenWrt version would work perfectly fine)


Martin

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

Re: [OpenWrt-Devel] [PATCH] om-watchdog: Add support for GL-X1200 (GL.iNet)

[Martin Blumenstingl via openwrt-devel]

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,

On Fri, Apr 10, 2020 at 11:47 AM guilin.w...@gl-inet.com
 wrote:
>
> Signed-off-by: guilin.w...@gl-inet.com 
the format should be "your name "

> ---
>  package/kernel/om-watchdog/Makefile   |  2 +-
>  package/kernel/om-watchdog/files/om-watchdog  | 40 
> +++
>  package/kernel/om-watchdog/files/om-watchdog.init |  2 ++
>  3 files changed, 37 insertions(+), 7 deletions(-)
why not use a GPIO watchdog node in board.dts instead? see [0] for an example


Martin


[0] 
https://github.com/torvalds/linux/blob/v5.4/Documentation/devicetree/bindings/watchdog/gpio-wdt.txt

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

Re: [OpenWrt-Devel] gpio-export,output and GPIO_ACTIVE_*

[Martin Blumenstingl via openwrt-devel]

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 Adrian,

On Sun, Feb 23, 2020 at 8:52 PM  wrote:
>
> Hi,
>
> when defining gpio-export nodes, I'm never really sure about how the values 
> for "gpio-export,output" and GPIO_ACTIVE_HIGH/LOW in gpios have to be set up 
> correctly in relation to each other.
>
> I also was not able to retrieve a particular system in how this is set up 
> currently (for different devices).
>
> It would be nice if somebody could elaborate this to me (I've found several 
> shorter explanations in the PR comments throughout GitHub, but they 
> unfortunately were never comprehensive.)
I don't know about gpio-export

> (And I assume the same logic will apply to gpio-hogs with output-low/high and 
> gpios parameter?)
for gpio-hog there is documentation inside the kernel sources:
Documentation/devicetree/bindings/gpio/gpio.txt

I don't know why there are output-low, output-high, input properties
and if they are optional (meaning for example output-high can be
omitted when setting GPIO_ACTIVE_HIGH). when in doubt, ask on the
linux-gpio mailing-list


Regards
Martin

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

Re: [OpenWrt-Devel] ath79 equivalent of disable_smarteee

[Martin Blumenstingl via openwrt-devel]

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 Roger,

On Sun, Feb 2, 2020 at 12:00 AM Roger Pueyo Centelles
 wrote:
>
> Hi Martin, Adrian,
>
> Thanks for the info. The device is advertising EEE capabilities, and so
> is the adapter on my computer it is connected to:
>
> root@computer:~# ethtool --show-eee eth2
> EEE Settings for eth2:
> EEE status: enabled - active
> Tx LPI: disabled
> Supported EEE link modes:  100baseT/Full
>1000baseT/Full
> Advertised EEE link modes:  10baseT/Full
> 100baseT/Half
> Link partner advertised EEE link modes:  100baseT/Full
>  1000baseT/Full
>
> The eee-broken-100tx/eee-broken-1000t options are not yet set in the
> DTS, but I am not seeing any EEE-related messages on the router (nor on
> my computer) --or I'm not looking at the right place--. Is it just a
> matter of time (i.e., they will eventually appear)? In other words,
> should I add them to the DTS?
These properties were added upstream as part of debugging Ethernet
issues on boards using an Amlogic SoC. Slow transfer speeds were
observed by *some* people and eee-broken-100tx/eee-broken-1000t fixed
it for them.
personally I never observed any difference on all hardware (all boards
with Amlogic SoC together with all switches that I have) with or
without the eee-broken-100tx/eee-broken-1000t properties.

We have not figured out the actual root cause of these issues on Amlogic SoCs.
So we add the properties there whenever the authors of the .dts
believes that it fixes some problem for them (or someone else reports
a problem and adding those properties fixes it).
Unfortunately this also means that there's no specific test procedure
documented.


Martin

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

Re: [OpenWrt-Devel] ath79 equivalent of disable_smarteee

[Martin Blumenstingl via openwrt-devel]

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 Adrian,

On Sat, Feb 1, 2020 at 6:50 PM  wrote:
>
> Hi,
>
> in the device support PR for MikroTik RouterBOARD 922UAGS-5HPacD [1] for 
> ath79, we have the following in ar71xx mach files [2]:
>
> static struct at803x_platform_data rb922gs_at803x_data = {
> .disable_smarteee = 1,
> };
>
> Is there an ath79 equivalent available and necessary?
upstream has the following two properties (which need to be added
inside the Ethernet PHY devicetree node):
- eee-broken-100tx
- eee-broken-1000t
- (there are more, see Documentation/devicetree/bindings/net/ethernet-phy.yaml)

set them and EEE will not be advertised anymore.

there's some additional, AT803X PHY specific register write inside
at803x_disable_smarteee from
target/linux/generic/pending-4.14/734-net-phy-at803x-allow-to-configure-via-pdata.patch
This modifies the AT803X_PCS_SMART_EEE_CTRL3 register. I don't know
whether this is necessary when EEE is not advertised


Martin

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

Re: [OpenWrt-Devel] [RFC] commit message in YAML format for new devices

[Martin Blumenstingl via openwrt-devel]

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 Paul,

On Mon, Jan 13, 2020 at 9:13 AM Paul Spooren  wrote:
>
> Hi,
>
> On 1/12/20 1:05 PM, Martin Blumenstingl wrote:
> > Hi Paul,
> >
> > On Sun, Jan 12, 2020 at 10:47 PM Paul Spooren  wrote:
> >> Hi all,
> >>
> >> some time ago I created a (now outdated) device overview[0] based on
> >> YAML meta data. This approach could simplify maintaining an device
> >> overview and device specific pages[1].
> >>
> >> All commits adding new devices already include most relevant information
> >> for creating the overview. However it would be convenient if developers
> >> would format their commit messages in a generic format, therefore I'd
> >> propose the following:
> >>
> >> Every commit message for newly added devices must contain a number of
> >> hardware information and steps for an initial installation.
> >> The hardware information should contain at least the following
> >> information, maybe more:
> >>
> >> SoC, flash, ram, wifi, LEDs, buttons, USB, serial, vendor, model, device
> >> tree ID, Ethernet ports
> > can we automate this somehow?
> > the device tree files already contain most of that information.
>
> If you have a tool to extract such data or ideas on how to create such,
> that'd be great.
I don't have such a tool
my idea was that most of the data is already available in the .dts
files (or .dtb files, I haven't really thought about the
up-/downsides):
- SoC
- flash size
- RAM size
- (wifi can be detected on some devices where wifi is either part of
the SoC or the PCI(e) wifi chip is described in the .dts)
- buttons
- serial console (existence of such)
- model
- Ethernet ports
- USB controller(s)

this data can be parsed periodically to ensure that the TOH is
up-to-date, for example if a missing LED is added after the initial
submission of the device.
there are probably downsides when going this route, but I have not
thought these through yet (because I don't have time to implement a
tool which would do the parsing)

> As an alternative I could also create a shell script that extracts data
> on a running machine, but that might miss some details.
that would be another solution
the downside I see compared to .dts/.dtb parsing is that you need
access to the device to update the TOH. but I don't know whether this
is relevant for the use-case that we're discussing


Martin

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

Re: [OpenWrt-Devel] [RFC] commit message in YAML format for new devices

[Martin Blumenstingl via openwrt-devel]

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 Paul,

On Sun, Jan 12, 2020 at 10:47 PM Paul Spooren  wrote:
>
> Hi all,
>
> some time ago I created a (now outdated) device overview[0] based on
> YAML meta data. This approach could simplify maintaining an device
> overview and device specific pages[1].
>
> All commits adding new devices already include most relevant information
> for creating the overview. However it would be convenient if developers
> would format their commit messages in a generic format, therefore I'd
> propose the following:
>
> Every commit message for newly added devices must contain a number of
> hardware information and steps for an initial installation.
> The hardware information should contain at least the following
> information, maybe more:
>
> SoC, flash, ram, wifi, LEDs, buttons, USB, serial, vendor, model, device
> tree ID, Ethernet ports
can we automate this somehow?
the device tree files already contain most of that information.

(I'm all for providing good data for the TOH but I'm challenging the
idea of doing this manually)


Martin

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

Re: [OpenWrt-Devel] Lantiq xrx200: Access to ethernet phy registers (MDIO) from userspace

[Martin Blumenstingl via openwrt-devel]

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 Martin,

On Mon, Sep 16, 2019 at 12:54 PM Martin Schiller  wrote:
>
> Hi!
>
> I am searching for a possibility to disable Auto Negotiation of an
> PEF7072 which is attached to MAC1 of the Lantiq xrx200 switch.
>
> The xrx200-net driver does not seem to have support for that.
I don't know about xrx200-net, but ...

> Accessing the STD_CRTL register on the mdio bus from uboot with the mdio
> command works like expected.
>
> Any suggestions how to do that from linux userspace?
... my (limited) understanding is that this is one of the benefits of DSA:
you get one interface per port - with that you can use for example
ethtool to disable auto negotiation for one port
kernel source reference: [0]


Martin


[0] https://elixir.bootlin.com/linux/latest/source/net/dsa/slave.c#L1133

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

Re: [OpenWrt-Devel] AR10 GPHYs (WAS: Re: [lantiq] general help on AR10 platform)

[Martin Blumenstingl via openwrt-devel]

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 Enrico,

On Wed, Sep 4, 2019 at 12:07 PM Enrico Mioso  wrote:
>
> Hi there!
>
> So I am trying to get ethernet working on this AR10 device.
> It has 3 GPHYs:
>
> gphy0: gphy@20 {
> compatible = "lantiq,xrx300-gphy";
> reg = <0x20 0x4>;
>
> resets = < 31 30>, < 7 7>;
> reset-names = "gphy", "gphy2";
> };
>
> gphy1: gphy@58 {
> compatible = "lantiq,xrx300-gphy";
> reg = <0x58 0x4>;
>
> resets = < 29 28>, < 6 6>;
> reset-names = "gphy", "gphy2";
> };
>
> gphy2: gphy@ac {
> compatible = "lantiq,xrx300-gphy";
> reg = <0xac 0x4>;
> resets = < 27 26>, < 5 5>;
> reset-names = "gphy", "gphy2";
> };
>
> And firmware load addresses for GPHYs are correct as per the vendor code:
> #define IFX_RCU_GPHY0_FW_ADDR   ((volatile u32*)(IFX_RCU + 
> 0x0020))
> #define IFX_RCU_GPHY1_FW_ADDR   ((volatile u32*)(IFX_RCU + 
> 0x0058))
> #define IFX_RCU_GPHY2_FW_ADDR   ((volatile u32*)(IFX_RCU + 
> 0x00AC))
the register part of your .dts looks fine based on this

> But driver was failing to initialize due to missing clock gates.
> In sysctrl.c, we have:
> clkdev_add_pmu("1f203020.gphy", NULL, 1, 0, PMU_GPHY); // OK for GPHY0
> clkdev_add_pmu("1f203068.gphy", NULL, 1, 0, PMU_GPHY); //problem for GPHY1
>
> And GPHY2?
the UGW kernel documents all the PMUs in
drivers/char/ifxmips_pmu_SOC.h, in your case that is:
drivers/char/ifxmips_pmu_ar10.h [0]
I don't remember how to translate that file to an English sentence but
you can figure it out on your own (for example by comparing the vr9
sysctrl.c code with

resets are found in the same directory but a different file: ifxmips_rcu_ar10.h

(sorry for the short answer but I have to leave in a few minutes)


happy hacking!
Martin


[0] 
https://github.com/uwehermann/easybox-904-xdsl-firmware/blob/master/linux/linux-2.6.32.32/drivers/char/ifxmips_pmu_ar10.h

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

Re: [OpenWrt-Devel] [lantiq] help in supporting FRITZ!BOX 3272 (Fritz_Box_HW198))

[Martin Blumenstingl via openwrt-devel]

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 Enrico,

On Sat, Aug 24, 2019 at 1:15 AM Enrico Mioso  wrote:
>
> Sat, 24 Aug 2019 01:14:40 +0200 (CEST)ear OpenWRt list,
> I was looking at trying to add support to the FRITZ!BOX 3272 to OpenWRt.
> It is based on the Lantiq AR10 platform - for which I wasn't able to find any 
> informations, even tought I see kernel code to support it is already 
> available.
> From where may I start ?
from what I know AND if I remember correctly:
* the Ethernet controller is the same as on the VRX200 SoCs, only the
clocks are slightly different (the clock code may already account for
that, I don't know)
* the NAND controller got hardware ECC support (the upstream driver
doesn't support that yet and the upstream driver needs a rework
anyways because it's using the legacy NAND API)
* it has two PCIe controllers (VRX200 has one, our current PCIe
controller driver will not work with two controllers enabled - but
there's an ongoing effort in upstreaming the PCIe driver [0] which
will solve that problem)
* it has three built-in GPHY IP cores (VRX200 has only two, that means
it supports 2x Gbit ports - each using one GPHY - and 2x 10/100 Mbit/s
- using the third GPHY - Ethernet ports)
* upstream Linux should already have support for the clocks (there may
be bugs, but basic support is probably there)
* upstream Linux should already have support for GPIO and pin controllers
* the CPU cores are the same as on VRX200 so the whole CPU tree,
interrupt controller, etc. should all be the same (and thus supported
by upstream Linux)

Hauke is working on an upstream Ethernet driver, so if I were to touch
anything Ethernet related I would ask him about his plans fist.
upstream PCIe support is ongoing [0], I am following that discussion
instead of duplicating work.
Hardware ECC support for the NAND controller (as well as rewriting the
NAND controller driver to match the new upstream NAND driver API) is
something that nobody is working on (as far as I know).

> E.g.: is there any similar devices or places I might start looking?
the BT Home Hub 4A uses an ARX368 (= also "AR10")

adding support for any ARX300 based device ("AR10", such as the
FRITZ!Box 3272) then you I suggest to start very simple. if I would do
it then would use the following steps:
- create a bare minimum arx300.dtsi (I would start with one CPU,
memory and UART)
- add more devices, one-by-one to that .dtsi validating that each of them works
- find the ones that don't work and find out why that is (trying to
understand the out-of-tree drivers from the Lantiq "UGW" helps me here
- as well as feedback from Hauke and John)
- make it work (this typically involves sending kernel patches early
to upstream and getting feedback)


Martin


[0] https://lkml.org/lkml/2019/8/20/256

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

Re: [OpenWrt-Devel] ath9k: mtd-cal-data vs firmware bin file

[Martin Blumenstingl via openwrt-devel]

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 Michal,

On Wed, Aug 14, 2019 at 10:59 AM Michal Cieslakiewicz
 wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Hello Adrian,
>
> Thanks for helping me with WNR patchset, one question came to my mind
> in the process of developing it and after reading one of your emails.
> Sorry if it has been answered elsewhere...
>
> /etc/hotplug.d/firmware/10-ath9k-eeprom for these routers just extracts
> 4k of calibration data from ART to bin file in /lib/firmware. I
> compared bin file to mtd area and they are identical. Why ath9k cannot
> use this data directly accessing /dev/mtd6? Is that 'mtd-cal-data' dts
> option for? If so, why does it not work in this case? (tested, ath9k
> initialization ends with error)
> I recall there was no such operation in ar71xx target and older
> kernels...
(I am the one who brought the /lib/firmware based caldata upstream -
these are my thoughts on this topic)

upstream ath9k has support for retrieving the caldata through the
request_firmware mechanism (which requires copying it to
/lib/firmware).
some out-of-tree patches have/had a special mtd-cal-data property to
achieve a similar goal (passing the caldata to devices without a
physical EEPROM).

while I upstreamed the ath9k patches for request_firmware support
there was a bit of a discussion.
the discussion was whether the NVMEM subsystem should be used instead
of relying on request_firmware.
my primary target was the BT HomeHub 5A which stores the calibration
data inside a UBI volume which cannot be referenced from devicetree
(yet - or at least at the time I upstreamed the patches it could not
be referenced) so I still chose to push the request_firmware part
forward.

most devices have the caldata at a fixed location on the flash, so the
NVMEM subsystem can be used for this.
if someone wants to get rid of the caldata copy in /lib/firmware then
support for reading the caldata using the NVMEM framework could be
implemented in ath9k (and owl-loader).
the result would be close to what the mtd-cal-data provides, assuming
that the NVMEM subsystem can read the underlying data structures on
flash (AFAIK this currently excludes NAND with UBI, which is used by
the minority of the boards with an ath9k chip).


Martin

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

Re: [OpenWrt-Devel] [PATCH] ramips: use gpio_hog instead of gpio-export

[Martin Blumenstingl via openwrt-devel]

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, Aug 11, 2019 at 1:00 PM Birger Koblitz  wrote:
> I'll go through the patches and remove anything that sounds like it
> might need user space configuration (i.e. not power the USB bus or the
> like).
upstream GPIO maintainers prefer dedicated properties instead of a GPIO hog.

some USB controller drivers support a "vbus-supply" property, which
can be used together with a GPIO regulator
in case of the VBUS supply it means the GPIO will be turned off if the
USB port is "disabled" (for example by unloading the kernel USB
controller driver).

I'm not saying that you have to switch over to something other than GPIO hogs.
switching to an upstream solution is a good starting point!
just be aware that this may not be the final solution

> Is anyone working on converting the use-cases which require user space
> switching to libgpiod or any other solution?
how do you identify the "use-cases which require use space switching"?


Martin

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

Re: [OpenWrt-Devel] Problem reading flash zones in ath79

[Martin Blumenstingl via openwrt-devel]

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 Enrico,

On Mon, Jul 29, 2019 at 3:40 PM Enrico Mioso  wrote:
>
> Hello guys!
>
> I experienced an issue where I wasn't able to read all of a flash region on 
> an ATH79 device, the Archer C60 V2.
> Taking a look, it seems the MTD layer will return only 512-bytes when reading 
> an mtd device via the mtdblock layer.
I believe that this is related to the erase/write size of the flash on
your device (see /sys/class/mtd/*/{erase,write}size).

> So, in the case of my Archer C60 V2:
> - the first partition, "factory-boot" won't be completely readable (256 bytes 
> will be missing)
> - sameholds for "mac" partition
> - same holds for the "u-boot" partition
>
> This will prevent users from making proper backups of their devices.
> Should this be fixed on the mtd layer or on thedevicetrees we're using?
> Of course I don't think this is ath79 specific...
I suggest to also ask on the linux-mtd mailing list if you don't get
an answer here or before you spend time coding: [0]


Martin


[0] http://lists.infradead.org/mailman/listinfo/linux-mtd

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

Re: [OpenWrt-Devel] ath79 (qca95xx): Status of SPI-Attached NAND Drivers?

[Martin Blumenstingl via openwrt-devel]

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,

(disclaimer: my knowledge about the ath79 SoC is pretty limited)

On Fri, Jan 25, 2019 at 10:09 PM Jeff Kletsky  wrote:
[...]
> * What is the level of support for QCA9531 and QCA9563 SoCs for NAND?
for SPI NAND chips the SoC has to implement an SPI controller
the NAND controller is inside the SPI NAND chip itself

some SoCs (I believe also some of the ath79 SoCs) integrate a parallel
NAND controller. this has nothing to do with the SPI NAND devices
though

this doesn't answer your question, but the question (and thus the
answer) depends on the hardware you have:
1) SPI NAND: is the SPI controller supported? and: is the SPI NAND
chip supported?
2) parallel NAND: is the SoC's NAND controller supported? and: is the
NAND chip supported?

based on your other question I believe you want to know the status of case 1)

[...]
> * Linux Kernel commit eaa76499711535fd64d747cc4ef0d78ab0fd41c
>
>  Merge tag 'mtd/for-4.21' of git://git.infradead.org/linux-mtd
>
>SPI-NAND drivers changes:
> - Remove the depreacated mt29f_spinand driver from staging.
>
>
> (At least that's a while off, but reinforces the unwillingness of
> upstream acceptance of keeping the mt29f_spinand driver alive.)
the mt29f_spinand driver was removed in favor of the MTD SPI NAND
driver, see [0]
(the mt29f_spinand only supported the Micron SPI NAND chips. the new
MTD SPI NAND driver implements vendor agnostic logic and hooks where
NAND manufacturer specific logic can be integrated)
4.19 was the first kernel with the MTD SPI NAND driver (that gives you
context to mkresin's comment)


Regards
Martin


[0] https://github.com/torvalds/linux/tree/master/drivers/mtd/nand/spi

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

Re: [OpenWrt-Devel] [PATCH] ramips: add mt76x0 node to RT-AC51U device tree

[Martin Blumenstingl via openwrt-devel]

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 Lorenzo,

thank you for your work on the mt76 drivers!

On Mon, Oct 29, 2018 at 11:31 PM Lorenzo Bianconi
 wrote:
>
> Introduce mt76x0e device tree node in RT-AC51U dts.
> Define mt76x0e mtd partition and offset
>
> Signed-off-by: Lorenzo Bianconi 
> ---
>  target/linux/ramips/dts/RT-AC51U.dts | 11 +++
>  1 file changed, 11 insertions(+)
>
> diff --git a/target/linux/ramips/dts/RT-AC51U.dts 
> b/target/linux/ramips/dts/RT-AC51U.dts
> index 6bed8446e5..f6cc36b719 100644
> --- a/target/linux/ramips/dts/RT-AC51U.dts
> +++ b/target/linux/ramips/dts/RT-AC51U.dts
> @@ -135,3 +135,14 @@
> };
> };
>  };
> +
> + {
> +   status = "okay";
> +};
> +
> + {
> +   mt76@0,0 {
this should be wifi@0,0 because node-names are supposed to represent
the device type, not a specific "implementation"
quote from [0]: "A node for a 3com Ethernet adapter would be use the
name ethernet, not 3com509."

> +   reg = <0x 0 0 0 0>;
> +   mediatek,mtd-eeprom = < 0x8000>;
> +   };
> +};
> --
> 2.19.1
>
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[0] https://elinux.org/Device_Tree_Usage#Node_Names

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

Re: [OpenWrt-Devel] [PATCH] ath79: ar7100: remove IRQ code from PCI driver

[Martin Blumenstingl via openwrt-devel]

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 Wed, Aug 22, 2018 at 6:58 PM Dmitry Tunin  wrote:
>
> Looking into irq-ath79-misc.c I found a few things to cleanup.
>
> 1. It appears that two chips are declared: "qca,ar7100-misc-intc" and
> "qca,ar7240-misc-intc".
> The only difference is mask-ack proc. The registers seem to work the
> same way and practically we are using "qca,ar7240-misc-intc" on ar7100
> according to dtsi.
> I found that the other chip was declared only when looking into the code.
>
> At the same time the code I removed from the PCI driver used the
> ar7100 type of mask-ack, that worked also OK.
>
> I see no reason of having two different ways of mask-ack for similar
> hardware. We need to chose one that looks better and drop the other.
I suggest discussing any irq-ath79-misc changes with the upstream developers
Alban Bedel did *a lot* of work to make the ath79 code devicetree
compatible. it would be a shame not to "use" his knowledge by
including him in the discussion upstream

> 2. Instead of declaring two different chips this way, since we are
> reusing this driver for PCI, I suggest to declare also
> "qca,ath79-pci-intc" that will
> have a different chip name = "PCI", so that "MISC and "PCI" will be
> seen separately in /proc/interrupts.
some existing irqchip drivers:
- set the name dynamically, see drivers/irqchip/irq-ts4800.c for example
- have a different number of interrupts per "compatible", see
drivers/irqchip/irq-meson-gpio.c for example

you may need the latter for your other patch which tries to reduce
ATH79_MISC_IRQ_COUNT anyways

> 3. I suggest removing legacy __init ath79_misc_irq_init() and leaving
> only the OF stuff.
I suggest coordinating this with the upstream developers as well as
that function is part of the upstream code

> Any comments?
slightly off-topic: please try not to top-post as it can be confusing


Regards
Martin

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

Re: [OpenWrt-Devel] [PATCH] [RFC] ath79: ag71xx: apply interface mode to MII0/1_CNTL on ar71xx/ar913x

[Martin Blumenstingl via openwrt-devel]

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 Thu, Aug 16, 2018 at 5:06 AM Chuanhong Guo  wrote:
>
> Signed-off-by: Chuanhong Guo 
> ---
> RFC:
> Previous discussion about this patch can be found on GitHub PR#1271.
> This patch applies correct interface mode to MII0/1_CNTL register at 
> 0x1807/
> 0x18070004. But there is a small difference in values for these two registers:
> | GMAC0| GMAC1   |
> |--|-|
> | 0 GMII   | 0 RGMII |
> | 1 MII| 1 RMII  |
> | 2 RGMII  | |
> | 3 RMII   | |
> I currently have 4 ways of dealing with this:
> 1. Use a bool value in dts indicating whether this is the second GMAC. This 
> one
>is pretty dirty and I dropped it.
> 2. Split MII_CNTL into separated dt node and use different compatible for them
>like we did for ETH_CFG (gmac node) on ar933x and later SoCs. After some 
> discussion
>on GitHub it turns out to be unreasonable to treat those in separated 
> nodes.
> 3. Use ar7100-eth0/ar7100-eth1 as compatible string. This is what I've done in
>this patch I sent here. But I think my way of using compatible string here 
> is ugly :(
>A possible cleaner implementation would be introducing 
> ar7100-eth0/ar7100-eth1/
>ar9130-eth0/ar9130-eth1 to replace ar7100-eth/ar9130-eth. But I doubt 
> whether
>introducing 4 new compatible strings for such a slight difference is 
> worthy.
I think the naming "ar7100-eth0" / "ar7100-eth1" was my idea
maybe it's not super intuitive since it reads as if the target
Ethernet device will be called "eth0" or "eth1" - this is not what I
meant with this naming. I wonder if "ar7100-mii0-eth" /
"ar7100-mii1-eth" is any better. other ideas are highly welcome

"There are only two hard things in Computer Science: cache
invalidation and naming things."
-- Phil Karlton


Regards
Martin

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

Re: [OpenWrt-Devel] [PATCH] [RFC] ath79: ag71xx: apply interface mode to MII0/1_CNTL on ar71xx/ar913x

[Martin Blumenstingl via openwrt-devel]

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,

On Fri, Aug 17, 2018 at 12:05 PM Jonas Gorski  wrote:
>
> Hi,
>
> On 16 August 2018 at 05:05, Chuanhong Guo  wrote:
> > Signed-off-by: Chuanhong Guo 
> > ---
> > RFC:
> > Previous discussion about this patch can be found on GitHub PR#1271.
> > This patch applies correct interface mode to MII0/1_CNTL register at 
> > 0x1807/
> > 0x18070004. But there is a small difference in values for these two 
> > registers:
> > | GMAC0| GMAC1   |
> > |--|-|
> > | 0 GMII   | 0 RGMII |
> > | 1 MII| 1 RMII  |
> > | 2 RGMII  | |
> > | 3 RMII   | |
> > I currently have 4 ways of dealing with this:
> > 1. Use a bool value in dts indicating whether this is the second GMAC. This 
> > one
> >is pretty dirty and I dropped it.
> > 2. Split MII_CNTL into separated dt node and use different compatible for 
> > them
> >like we did for ETH_CFG (gmac node) on ar933x and later SoCs. After some 
> > discussion
> >on GitHub it turns out to be unreasonable to treat those in separated 
> > nodes.
> > 3. Use ar7100-eth0/ar7100-eth1 as compatible string. This is what I've done 
> > in
> >this patch I sent here. But I think my way of using compatible string 
> > here is ugly :(
> >A possible cleaner implementation would be introducing 
> > ar7100-eth0/ar7100-eth1/
> >ar9130-eth0/ar9130-eth1 to replace ar7100-eth/ar9130-eth. But I doubt 
> > whether
> >introducing 4 new compatible strings for such a slight difference is 
> > worthy.
as already stated on the github PR I prefer option #3

> > 4. Somehow write all the possible values for each interface mode in device 
> > tree.
> >e.g. qca,if-modes = "gmii","mii","rgmii","rmii"; for eth0 and
> > qca,if-modes = "rgmii","rmii"; for eth1.
this would encode register values in a devicetree property (index of
each string is the register value)
I believe that upstream devicetree maintainers don't want this anymore

the rule of thumb is: devicetree should describe the hardware (not
register contents or driver settings) because it should be "universal"
(some bootloaders use it, Linux uses it, ...)
if two devices are compatible they can use the same compatible string
however, if they are different (even just slightly) they should get
their own compatible string (see the stmmac bindings upstream for an
example: Documentation/devicetree/bindings/net/stmmac.txt contains the
original stmmac bindings while
Documentation/devicetree/bindings/net/meson-dwmac.txt /
Documentation/devicetree/bindings/net/stm32-dwmac.txt define new
compatible strings because each vendor has defined it's own extensions
to the original stmmac IP block)

> > Which one is better? Is there any other possible solutions for this problem?
>
> I'd prefer 4, or a modified 3:
>
> do something like
>
> aliases {
>  
>  ethernet0 = 
>  ethernet1 = 
> };
>
>
> and then you can find out if you are eth0 or eth1 by calling
>
> id = of_alias_get_id(node, "ethernet");
>
> and maybe warn (and don't configure mii mode) if it returns neither 0 or 1.
this is an interesting idea
do you have any upstream example where this behavior was reviewed (and
ACK'ed) by the upstream devicetree maintainers?
(I found some examples relying on that exact behavior, but I'm not
sure if the devicetree maintainers know about this code/want this
solution to be used in the future)


Regards
Martin

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

Re: [OpenWrt-Devel] [PATCH 0/2] ramips: fix RBMxxG name and partitionning

[Martin Blumenstingl via openwrt-devel]

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 Thu, Jul 19, 2018 at 7:13 PM Thibaut VARÈNE  wrote:
>
> This series fix the DTS files of the MikroTik RouterBOARD M11G and M33G. The
> changes are similar in both patches:
>
>  - The model name string is updated to match the hardware-stored (in flash)
>string that we cannot (yet?) extract at runtime.
>  - The partition scheme is updated to reflect areas reserved by OEM (as 
> defined
>in their GPL source code) and the reverse-engineered sections contained
>herein.
>
> The proposed partition scheme defines a "top-level" overlapping "RouterBoot"
> partition that matches the identically named, OEM-defined segment (in their 
> GPL
> code), and then defines extrapolated sub-segments.
>
> The rationale for this is as follows:
>  - OEM only defines the 0x0 0x4 segment in their source: the whole segment
>should thus be considered "reserved by OEM", despite having empty holes.
>  - The subsegments are reverse-engineered (initially by Gabor Juhos in
>target/linux/ar71xx/files/arch/mips/ath79/routerboot.c) and may vary from
>hardware to hardware (they are already different in size and offsets 
> between
>ar71xx and ramips).
>  - We have no certitude that the empty holes will remain empty: it is 
> desirable
>to make it perfectly clear that they should never be reclaimed as user
>storage space (preferably without having to define a clutter of empty
>partitions).
>  - OEM tools might be usable with this top level partition present and named
>identically with OEM.
>  - The top level partition is a convenient way to ask for a user dump ("please
>send the content of the RouterBoot partition") and build a database of such
>dumps whose use will become apparent below.
>  - I expect it might eventually be possible to split that top level partition
>at runtime with a splitter.
these seem good reasons to add a "big" partition ranging from 0x0 to 0x4

> This last point is of particular significance: currently the proposed 
> partition
> scheme "emulates" what the purported splitter would produce at runtime. In an
> ideal world the DTS would only define the top-level RouterBoot area and the
> splitter would produce the exact same partition as is currently defined, in a
> fashion very similar to what is done with e.g. the 'firmware' partition.
> Regardless, in this situation the partition scheme for these devices would 
> thus
> not change.
based on my understanding a splitter is used to dynamically
"configure" partitions based on some kind of metadata (header, footer,
...)
can you please add a bit more description which describes this
metadata in RouterBoot?

> I cannot immediately provide such a runtime splitter, notably because I would
> need to collect several dumps to extract a statistically meaningful working 
> set
> to test the splitter code against; and also because of DTS-specific challenges
> associated with this proposal (the MAC address and ART data are contained in a
> specific sub-partition currently directly referred in DTS).
>
> These subpartitions are nevertheless necessary in their own right: besides the
> primary and secondary bootloader (apparently common to all RB devices, across
> all platforms) defined as 'routerboot' and 'routerboot2', the 'hard_config'
> segment contains the device MAC address, its model name string, its serial
> number or its WLAN calibration data for instance.
to me this only seems relevant if the "hard_config" partition (or
"segment") doesn't have a fixed offset. if it is always at a fixed
offset then you can calculate the "final offset" to the data within
"hard_config" from the start of the flash (assuming the whole 0x0 to
0x4 area is described as a big partition)

> The 'soft_config' partition contains user-modifiable settings such as boot
> delay, boot order, selected bootloader, cpu frequency scaling or uart speed.
> These settings can be accessed and modified in OpenWRT via the 'rbcfg' 
> utility,
> which relies on the presence of the 'soft_config' partition to operate. This
> explains the naming choice for these subpartitions: it's been carried over 
> from
> ar71xx for consistency.
this is a very important bit of information - MAC address, serial,
etc. is all static data where a big partition marked as read-only
doesn't hurt


Regards
Martin

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

Re: [OpenWrt-Devel] [PATCH 2/2] ramips: fix RBM11G name and partitioning

[Martin Blumenstingl via openwrt-devel]

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 Thu, Jul 19, 2018 at 7:12 PM Thibaut VARÈNE  wrote:
>
> This patch improves faf64056ddd46992a75b1e277d94541c7251035c by setting
> the correct partition scheme for the RouterBoot section of the flash.
>
> This section is subdivided in several segments, as they are on ar71xx
> RB devices, albeit with different offsets and sizes. The naming convention
> from ar71xx has been preserved, with an overlapping "RouterBoot" top level
> partition added for clarity due to the many holes.
>
> The resulting partition scheme looks like this:
> [2.477826] Creating 7 MTD partitions on "spi0.0":
> [2.482604] 0x-0x0004 : "RouterBoot"
> [2.488948] 0x-0xf000 : "routerboot"
> [2.495289] 0xf000-0x0001 : "hard_config"
> [2.501596] 0x0001-0x0001f000 : "routerboot2"
> [2.507966] 0x0002-0x00021000 : "soft_config"
> [2.514307] 0x0003-0x00031000 : "bios"
> [2.520108] 0x0004-0x0100 : "firmware"
>
> The device name is corrected to match the hardware-stored (in hard_config)
> device name.
>
> Leave a note in DTS to mention this device supports hardware crypto.
I find this bit of information strange since it has nothing to do with
the other changes. also: what kind of hardware crypto does it support?

> Leave a note in DTS to explain how the original author selected the SPI speed.
>
> Note: more work is required to get rbcfg working on this device due to
> endianness.
>
> Tested-by: Tobias Schramm 
> Signed-off-by: Thibaut VARÈNE 
> ---
>  target/linux/ramips/dts/RBM11G.dts | 62 
> +++---
>  1 file changed, 45 insertions(+), 17 deletions(-)
>
> diff --git a/target/linux/ramips/dts/RBM11G.dts 
> b/target/linux/ramips/dts/RBM11G.dts
> index f312093a22..079b4fc146 100644
> --- a/target/linux/ramips/dts/RBM11G.dts
> +++ b/target/linux/ramips/dts/RBM11G.dts
> @@ -7,7 +7,7 @@
>
>  / {
> compatible = "mikrotik,rbm11g", "mediatek,mt7621-soc";
> -   model = "MikroTik RBM11G";
> +   model = "MikroTik RouterBOARD M11G";
why do you need to change the model when updating the partitions? the
commit message doesn't explain this

>
> aliases {
> led-status = _usr;
> @@ -90,29 +90,54 @@
> #size-cells = <1>;
> compatible = "jedec,spi-nor";
> reg = <0>;
> +   // XXX empiric value to obtain actual 10MHz SCK at the chip
> spi-max-frequency = <3125000>;
>
> -   partition@0 {
> -   label = "routerboot";
> -   reg = <0x00 0x00F000>;
> -   read-only;
> -   };
> -
> -   factory: partition@f000 {
> -   label = "factory";
> -   reg = <0x00F000 0x031000>;
> -   read-only;
> -   };
> -
> -   partition@4 {
> -   label = "firmware";
> -   reg = <0x04 0xFC>;
> +   partitions {
> +   compatible = "fixed-partitions";
> +   #address-cells = <1>;
> +   #size-cells = <1>;
> +
> +   partition@0 {
> +   label = "RouterBoot";
> +   reg = <0x0 0x4>;
> +   read-only;
> +   };
> +
> +   routerboot@0 {
> +   reg = <0x0 0xf000>;
> +   read-only;
> +   };
isn't the recommended node name "partition" nowadays?
both partitions above would then become "partition@0" -> whether the
second node overwrites the first one (since both node names and
addresses/offsets are identical) or both are added to the resulting
.dtb depends on the dtc (device tree compiler) version, so I highly
recommend *NOT* doing this

> +   hard_config: hard_config@f000 {
> +   reg = <0xf000 0x1000>;
> +   read-only;
> +   };
> +
> +   routerboot2@1 {
> +   reg = <0x1 0xf000>;
> +   read-only;
> +   };
> +
> +   soft_config@2 {
> +   reg = <0x2 0x1000>;
> +   };
> +
> +   // valid data only extends up to 0x4f but make it 
> 0x1000 to match ar71xx
> +   bios@3 {
> +   reg = <0x3 0x1000>;
> +  

Re: [OpenWrt-Devel] [PATCH 2/3] mvebu: reduce speed to gen1 for armada 37xx devices pcie

[Martin Blumenstingl via openwrt-devel]

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, Jun 9, 2018 at 11:09 PM Tomasz Maciej Nowak  wrote:
>
> W dniu 09.06.2018 o 19:02, Martin Blumenstingl pisze:
> > On Sat, Jun 9, 2018 at 4:15 PM Tomasz Maciej Nowak  wrote:
> >>
> >> Since the beginning there's been an issue with initializing the Atheros
> >> based MiniPCIe wlan cards. Here's an example of kerenel log:
> >>
> >> advk-pcie d007.pcie: Posted PIO Response Status: CA,0xe00 @ 0x3c
> >> advk-pcie d007.pcie: Posted PIO Response Status: CA,0xe00 @ 0x44
> >> advk-pcie d007.pcie: Posted PIO Response Status: CA,0xe00 @ 0x4
> >> ath9k :00:00.0: enabling device ( -> 0002)
> >> advk-pcie d007.pcie: Posted PIO Response Status: CA,0xe00 @ 0x3c
> >> advk-pcie d007.pcie: Posted PIO Response Status: CA,0xe00 @ 0xc
> >> advk-pcie d007.pcie: Posted PIO Response Status: CA,0xe00 @ 0x4
> >> advk-pcie d007.pcie: Posted PIO Response Status: CA,0xe00 @ 0x40
> >> ath9k :00:00.0: request_irq failed
> >> advk-pcie d007.pcie: Posted PIO Response Status: CA,0xe00 @ 0x4
> >> ath9k: probe of :00:00.0 failed with error -22
> >>
> >> The same happens for ath5k cards, while ath10k card didn't appear at
> >> all (not detected). Following the issue on esppressobin.net forum [1]
> >> the workaround seems to be limiting the speed of PCIe bridge to 1st
> >> generation. This fixed the initialization of ath5k, ath9k and ath10k
> >> cards. The change shouldn't affect the performance for wireless cards,
> >> it could reduce the performance of storage controller cards but since
> >> OpenWrt focuses on wireless connectivity, fixing compatibility with
> >> wireless cards should be a priority.
> >> For the record, the iwlwifi and mt76 cards were not affected by this
> >> issue.
> > does this meant that the PCIe link speed depends on the board?
>
> No, that depends on the SoC board has and PCIe card which negotiates the 
> speed and capabilities. It shouldn't depend on the board, of course if there 
> are no design faults. Maybe some code in Atheros drivers also affects this or 
> there's bug in aardvark enumerating code. The assessment of this is outside 
> of my skills.
I was curious because officially the SoCs from the Armada 3700 series
support PCIe 2.0, so it seems strange to force/limit the hardware to
PCIe 1.0

> >
> > the PCI dt-bindings already specify a "max-link-speed" property, see [0]
> > there's even a helper function to parse that property: 
> > of_pci_get_max_link_speed
> >
> > this would give you control over the PCIe link speed per board (I am
> > assuming that the mvebu target uses devicetree).
>
> I tried this before submitting the patch, just to be sure retried it after 
> Your mail. Setting this had no effect, the state was as if there was no 
> change.
as far as I can see the pci-aardvark driver does not parse the
"max-link-speed" devicetree property yet (because it does not use/call
of_pci_get_max_link_speed).
so to use the "max-link-speed" property one would:
- implement support for it in the driver
- add the property to the .dts file

> > additionally this would allow you to send the patch upstream so
> > OpenWrt doesn't have to carry custom patches around forever
> >
> > what do you think?
>
> This driver still is in early stage, there are still some issues, until it'll 
> be more mature I'm reluctant to send this workaround upstream or sending bug 
> report. Thomas Petazzoni from Bootlin is working on this driver and still has 
> some pending changes but that will take few months. Until his changes will 
> hit upstream I'm inclined to keep this.
I'm not against adding this patch
it just seems to me that all PCI related kernel patches in OpenWrt are
backports from upstream patches
so why not report your issue upstream, work on a fix with them and
backport the result (this will make kernel updates on the mvebu target
easier, since it'll allow dropping patches when updating rather then
having to figure out why they are still needed, rebasing and testing
them again, ...)

> There is also upcoming device from CZ.nic, namely Turris MOX, which is based 
> on the same processor as ESPRESSObin. They already submitted watchdog driver 
> to LKML and U-Boot tree and minor fixes to U-Boot. Maybe their involvement 
> will speed up the changes and we'll see this workaround unnecessary.
by 

Re: [OpenWrt-Devel] [PATCH 2/3] mvebu: reduce speed to gen1 for armada 37xx devices pcie

[Martin Blumenstingl via openwrt-devel]

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, Jun 9, 2018 at 4:15 PM Tomasz Maciej Nowak  wrote:
>
> Since the beginning there's been an issue with initializing the Atheros
> based MiniPCIe wlan cards. Here's an example of kerenel log:
>
> advk-pcie d007.pcie: Posted PIO Response Status: CA,0xe00 @ 0x3c
> advk-pcie d007.pcie: Posted PIO Response Status: CA,0xe00 @ 0x44
> advk-pcie d007.pcie: Posted PIO Response Status: CA,0xe00 @ 0x4
> ath9k :00:00.0: enabling device ( -> 0002)
> advk-pcie d007.pcie: Posted PIO Response Status: CA,0xe00 @ 0x3c
> advk-pcie d007.pcie: Posted PIO Response Status: CA,0xe00 @ 0xc
> advk-pcie d007.pcie: Posted PIO Response Status: CA,0xe00 @ 0x4
> advk-pcie d007.pcie: Posted PIO Response Status: CA,0xe00 @ 0x40
> ath9k :00:00.0: request_irq failed
> advk-pcie d007.pcie: Posted PIO Response Status: CA,0xe00 @ 0x4
> ath9k: probe of :00:00.0 failed with error -22
>
> The same happens for ath5k cards, while ath10k card didn't appear at
> all (not detected). Following the issue on esppressobin.net forum [1]
> the workaround seems to be limiting the speed of PCIe bridge to 1st
> generation. This fixed the initialization of ath5k, ath9k and ath10k
> cards. The change shouldn't affect the performance for wireless cards,
> it could reduce the performance of storage controller cards but since
> OpenWrt focuses on wireless connectivity, fixing compatibility with
> wireless cards should be a priority.
> For the record, the iwlwifi and mt76 cards were not affected by this
> issue.
does this meant that the PCIe link speed depends on the board?

the PCI dt-bindings already specify a "max-link-speed" property, see [0]
there's even a helper function to parse that property: of_pci_get_max_link_speed

this would give you control over the PCIe link speed per board (I am
assuming that the mvebu target uses devicetree).
additionally this would allow you to send the patch upstream so
OpenWrt doesn't have to carry custom patches around forever

what do you think?


Regards
Martin


[0] 
https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/pci/pci.txt

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

Re: [OpenWrt-Devel] 18.06 Bug: Baby Jumbo Frames on mt7621

[Martin Blumenstingl via openwrt-devel]

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 Jaap,

On Thu, May 24, 2018 at 12:00 PM, Jaap Buurman  wrote:
> Dear all,
>
> I found some additional information in the system log: Thu May 24
> 11:38:39 2018 kern.err kernel: [83864.729458] eth0: Invalid MTU 1508
> requested, hw max 1500
> Digging deeper, this seems like a message that is spawned by a
> function in /net/core.dev.c of the linux kernel:
>
> if (dev->max_mtu > 0 && new_mtu > dev->max_mtu) {
> net_err_ratelimited("%s: Invalid MTU %d requested, hw max %d\n",
> dev->name, new_mtu, dev->max_mtu);
> return -EINVAL;
> }
>
> Is there anybody that happens to know where exactly this max_mtu value
> is set to 1500? For mt7621 devices this should be 2048 (Baby jambo
> frames).
>
> Thank you very much in advance.
>
> Yours sincerely,
>
> Jaap Buurman
>
> On Tue, May 22, 2018 at 3:05 PM, Jaap Buurman  wrote:
>> Dear all,
>>
>> The switch to the 4.14 kernel apparently broke the baby jumbo frames
>> support of 2048 bytes that the switch is capable off. I found out that
>> changing the mtu above 1500 via Luci no longer applies properly.
>> Trying to manually change the mtu via ssh also fails:
>>
>> root@LEDE:~# ifconfig eth0 mtu 1508 up
>> ifconfig: SIOCSIFMTU: Invalid argument
>>
>> If there is any additional information that I can supply, please let
>> me know. I am also more than willing to help test potential fixes :)
I *believe* Mathias has a fix for this in his tree (but I'm not sure
if he has the hardware to test it): [0]
maybe you can give it a go and report back?


Regards
Martin


[0] 
https://git.openwrt.org/?p=openwrt/staging/mkresin.git;a=commitdiff;h=cc5f1fe7aa02943f3b39ffbd9dc3b8fcad569c8f

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

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

[Martin Blumenstingl]

On Sat, Jan 14, 2017 at 3:44 AM, Daniel Golle <dan...@makrotopia.org> 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 <dan...@makrotopia.org> 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
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

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

[Martin Blumenstingl]

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)

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

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 :))!


Regards,
Martin


[0] https://marc.info/?l=linux-wireless=148259864900818=2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Support for BTHomeHub5

[Martin Blumenstingl]

On Fri, Jan 13, 2017 at 6:30 PM, Mauro M.  wrote:
> Hello,
>
> Is OpenWRT going to backport support for BtHomeHub5 from LEDE?
> This router is very well supported in LEDE, whilst support is only basic in
> OpenWrt,
> LEDE implemented some broken changes in the firewall that prevent basic
> routing (it defeats the primary purpose of a router!), so I would like to
> use OpenWrt where routing works as expected, but I need to run it on BT Home
> Hub 5 routers.
have you reported this to the LEDE guys? There are currently talks
between the OpenWrt and LEDE guys [0] (so if they decide to merge that
routing bug might be "merged" as well)


[0] https://lists.openwrt.org/pipermail/openwrt-devel/2016-December/042462.html
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] ath10k mesh + ap + encryption?

[Martin Blumenstingl]

Hi Simon,

On Tue, Sep 13, 2016 at 1:13 PM, Simon Wunderlich <s...@simonwunderlich.de> 
wrote:
> On Tuesday, September 13, 2016 10:59:31 AM CEST Valo, Kalle wrote:
>> Simon Wunderlich <s...@simonwunderlich.de> writes:
>> > we have done some experiments last week on ath10k, trying to run mesh
>> > (802.11s) and access point at the same time, both encrypted.
>> >
>> > We have tested a recent LEDE (reboot-1519-g42f559e) but with
>> > firmware-5.bin_10.2.4.70.42-2 and the included wpa_supplicant, which gave
>> > us a working encrypted 802.11s network. However, starting an AP at the
>> > same time didn't work (AP doesn't beacon). This wasn't a problem when
>> > 802.11s was running unencrypted.
>> >
>> > We also tested version 10.2.4.97 (from codeaurora), which is now default
>> > in
>> > LEDE. However, this version apparently doesn't support 11s mesh at all
>> > (WMI_SERVICE_MESH_11S is disabled in the service map, but cfg/mac80211
>> > advertises support).
>> >
>> > So here are my questions:
>> >  * Did anyone succesfully run AP and mesh, both encrypted at the same
>> >  time?
>> >  * Do you have any pointers how we could fix this? Could it be fixable in
>> >  the>
>> > driver (i.e. not in firmware)?
>> >
>> >  * Does anyone have an idea if 11s will be supported in future versions? I
>> >
>> > didn't find any changelogs, but having 11s mode no longer in the service
>> > map does not make me optimistic.
>>
>> Why is LEDE using 10.2.4.97? It seems to be a quite old release and I
>> have no knowledge if anyone even tests that firmware branch with ath10k.
>> I recommend to only use firmware releases from ath10k-firmware.git as we
>> use those internally with ath10k. In any case, don't make any
>> assumptions about future from that firmware branch as it's so old.
Thanks for clarifying this.

> This was introduced in December 25th, 2015 after some firmware-related
> problems. I'm CC'ing Martin Blumenstingl who suggested this change.
>
> Since then, ath10k is pulling firmware from here (unless ct firmware is used):
>
> https://source.codeaurora.org/quic/qsdk/oss/firmware/ath10k-firmware/plain/
> 10.2.4/firmware-5.bin_10.2.4.97-1
I initially updated to version 10.2.4.70.13-2, but we decided to
update to the "latest" firmware back then (see the thread at [0])
With the explanation from Kalle it makes sense to only use the
firmware binaries distributed in his repo (to ensure that the firmware
is tested by QCA's internal team).

> However, I don't understand the numbering? 10.2.4.97 > 10.2.4.70, but you say
> 10.2.4.70.42-2 is more recent? I would have assumed otherwise from the
> numbers.
That looks strange to me as well

as a side-note: I am currently preparing and testing a patch to update
the ath10k-firmware in LEDE to 10.2.4.70.52


Regards,
Martin


[0] https://www.mail-archive.com/openwrt-devel@lists.openwrt.org/msg35623.html
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] latency on PPPoA ADSL Annex A on using Lantiq

[Martin Blumenstingl]

On Tue, Aug 2, 2016 at 6:10 PM, Alexander Couzens  wrote:
> On Tue, 2 Aug 2016 13:38:55 +
> Daniel Niasoff  wrote:
>
>> I can provide remote ssh access if required. When using SSH you will
>> notice it feels sluggish due to this issue.
>>
>> Any ideas plase, I am really stuck here?
>
> I can confirm your problem with PPPoE on ADSL. Also noticed high
> latency on ssh connection through the router.
> I guess it's not in the DSL part, because when using the TD8970 as
> modem with pass through everything is fine.
someone else did performance/throughput testing on the HH5A, the
results are posted here: [0]

I did not have time to look into this yet, but maybe Hauke or John
have an idea what's going on.


[0] http://openwrt.ebilan.co.uk/viewtopic.php?f=7=1189
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] [RFC] lantiq: disable a bunch of features not applicable to my box

[Martin Blumenstingl]

On Wed, May 18, 2016 at 9:54 AM, Ben Mulvihill  wrote:
> On Wed, 2016-05-18 at 09:39 +0200, Oswald Buddenhagen wrote:
>> - NAND/UBI support is completely irrelevant for my box, and for
>>   lantiq/Danube in general (IIRC). It appears to me that it would make
>>   sense to split it off from the xway target.
>
> NAND/UBI is required on BTHOMEHUB2B (xway danube) and
> BTHOMEHUB3A (xway ar9).
I think this patch is more of a "how to reduce the image size for
devices with limited space" - not an actual patch.

Some other brnboot based boards are running into the same problem.
The solution for these was to switch to u-boot - but changing the
bootloader is always dangerous.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Add support for AVM Fritzbox 7360 SL

[Martin Blumenstingl]

On Sun, May 15, 2016 at 9:45 PM, Sebastian Ortwein <k...@animeland.de> wrote:
> Am 15.05.2016 um 17:37 schrieb Martin Blumenstingl:
> Okay thank you for support. Now all thinks works fine LAN, WIFI, Switch and
> USB.
> I attach my patch to add the support for OpenWRT.
Great - congratulations :-)

> Is there anything to do for including this patch in OpenWRT?
actually you should split your patch into two:
1. adding support for 7360 SL
2. enabling CONFIG_AT803X_PHY saying that it's needed by 7360 SL

Make sure that you commit the patches with "git commit -s" (to add
"signed-off-by") and give them a nice description.
Then send them to this mailing-list (preferrably with git send-email -
see also: [0]).

PS: maybe you could change the LED labels in your patch to have a
"fritz7360sl" prefix, instead of "fritz7360" before sending the patch.


Martin

[0] https://wiki.openwrt.org/doc/patch/using.git
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Add support for AVM Fritzbox 7360 SL

[Martin Blumenstingl]

On Sun, May 15, 2016 at 3:44 PM, Sebastian Ortwein <k...@animeland.de> wrote:
> USB, WLAN and LAN works now. The only think what would not work is phy0 &
> phy1.
> I have attached my lastet patch.
if you google around a bit you'll find an AR8035 datasheet: that phy
is from the same series as the AR8030.
It defines that the RST pin is "active low" -> meaning you have to
pull it high to ensure that the PHY is not being reset:
http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/pinctrl/lantiq,pinctrl-xway.txt?v=4.4#L61
This means you should probably use:
lantiq,output = <1>;
lantiq,pull = <2>;
lantiq,open-drain;

> [ 0.993675] libphy: lantiq,xrx200-mdio: probed
> [1.004257] eth0: attached PHY [Generic PHY] (phy_addr=0:00, irq=-1)
> [1.009606] eth0: attached PHY [Generic PHY] (phy_addr=0:01, irq=-1)
> [1.079564] eth0: attached PHY [Lantiq XWAY VR9 GPHY 11G v1.4]
> (phy_addr=0:11, irq=-1)
> [1.147555] eth0: attached PHY [Lantiq XWAY VR9 GPHY 11G v1.4]
> (phy_addr=0:13, irq=-1)
"Generic PHY" means that no specific driver for this PHY is loaded.
Make sure you enable CONFIG_AT803X_PHY in target/linux/lantiq/config-4.4

Additionally you should check the phy-mode:
You are setting phy-mode = "rgmii", but Atheros says that the AR8030
is an "Ultra low-power single RMII Fast Ethernet PHY".
Thus you should probably change "rgmii" to "rmii".


Martin

On Sun, May 15, 2016 at 3:44 PM, Sebastian Ortwein <k...@animeland.de> wrote:
> Am 08.05.2016 um 18:40 schrieb Martin Blumenstingl:
>>
>> On Sun, May 8, 2016 at 5:49 PM, Sebastian Ortwein <k...@animeland.de>
>> wrote:
>>>
>>> can I add it the following way ?
>>>  mdio@0 {
>>>  #address-cells = <1>;
>>>  #size-cells = <0>;
>>>  compatible = "lantiq,xrx200-mdio";
>>>  phy0: ethernet-phy@0 {
>>>  reg = <0x0>;
>>>  compatible = "lantiq,phy11g",
>>> "ethernet-phy-ieee802.3-c22";
>>>  gpios = < 37 0>;
>>>  };
>>>  phy1: ethernet-phy@1 {
>>>  reg = <0x1>;
>>>  compatible = "lantiq,phy11g",
>>> "ethernet-phy-ieee802.3-c22";
>>>  gpios = < 44 0>;
>>>  };
>>>  phy11: ethernet-phy@11 {
>>>  reg = <0x11>;
>>>  compatible = "lantiq,phy11g",
>>> "ethernet-phy-ieee802.3-c22";
>>>  };
>>>  phy13: ethernet-phy@13 {
>>>  reg = <0x13>;
>>>  compatible = "lantiq,phy11g",
>>> "ethernet-phy-ieee802.3-c22";
>>>  };
>>
>> I think you have to name the property "reset-gpios", but apart from
>> that it looks good.
>
> I have try it like you sayed. But without success.
> I think the gpios are defined here, but it won't working.
>
> phy-rst {
> lantiq,pins = "io37", "io44";
> lantiq,pull = <0>;
> lantiq,open-drain = <0>;
> lantiq,output = <1>;
> };
>
>>>> I cannot see any ath9k messages in your kernel log - are you sure it's
>>>> being installed (/lib/modules/*/ath9k.ko)?
>>>> Your first patch lists kmod-ath9k, but if you added that after you
>>>> generated your .config then you're probably still missing it.
>>>> Please check "grep kmod-ath9k .config" and enable (set it to
>>>> =y/built-in) it if it's missing.
>>>
>>> I have not disable the ath9k driver. it is present and loaded.
>>
>> I think I see the problem after looking at your .dts again:
>> you *must* specify the ath,pci-slot property, otherwise the fixup is
>> not executed.
>> It seems that the wifi part is similar to the TD-W8980 (AR9287 behind
>> the PCIe-to-PCI bridge), so "0" should be the right value.
>> (otherwise it's pretty easy to find out by looking at sysfs:
>> /sys/bus/pci/devices/\:00\:0e.0/ -> that's where the ath9k device
>> on HH5A can be found, there we use at

Re: [OpenWrt-Devel] Add support for AVM Fritzbox 7360 SL

[Martin Blumenstingl]

On Sun, May 8, 2016 at 5:49 PM, Sebastian Ortwein  wrote:
> can I add it the following way ?
> mdio@0 {
> #address-cells = <1>;
> #size-cells = <0>;
> compatible = "lantiq,xrx200-mdio";
> phy0: ethernet-phy@0 {
> reg = <0x0>;
> compatible = "lantiq,phy11g",
> "ethernet-phy-ieee802.3-c22";
> gpios = < 37 0>;
> };
> phy1: ethernet-phy@1 {
> reg = <0x1>;
> compatible = "lantiq,phy11g",
> "ethernet-phy-ieee802.3-c22";
> gpios = < 44 0>;
> };
> phy11: ethernet-phy@11 {
> reg = <0x11>;
> compatible = "lantiq,phy11g",
> "ethernet-phy-ieee802.3-c22";
> };
> phy13: ethernet-phy@13 {
> reg = <0x13>;
> compatible = "lantiq,phy11g",
> "ethernet-phy-ieee802.3-c22";
> };
I think you have to name the property "reset-gpios", but apart from
that it looks good.

>> I cannot see any ath9k messages in your kernel log - are you sure it's
>> being installed (/lib/modules/*/ath9k.ko)?
>> Your first patch lists kmod-ath9k, but if you added that after you
>> generated your .config then you're probably still missing it.
>> Please check "grep kmod-ath9k .config" and enable (set it to
>> =y/built-in) it if it's missing.
>
> I have not disable the ath9k driver. it is present and loaded.
I think I see the problem after looking at your .dts again:
you *must* specify the ath,pci-slot property, otherwise the fixup is
not executed.
It seems that the wifi part is similar to the TD-W8980 (AR9287 behind
the PCIe-to-PCI bridge), so "0" should be the right value.
(otherwise it's pretty easy to find out by looking at sysfs:
/sys/bus/pci/devices/\:00\:0e.0/ -> that's where the ath9k device
on HH5A can be found, there we use ath,pci-slot = <0xe>;)


Martin


[0] 
https://github.com/openwrt/openwrt/blob/master/target/linux/lantiq/patches-4.4/0035-owrt-lantiq-wifi-and-ethernet-eeprom-handling.patch#L178
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Add support for AVM Fritzbox 7360 SL

[Martin Blumenstingl]

On Sun, May 8, 2016 at 10:33 AM, Sebastian Ortwein  wrote:
> I get the eeprom from the ath9k driver working, but wifi will not showed.
> First, I get a error message that from the ath9k driver that the eeprom
> couldn't load. After PCI Bus is initialize the eeprom is loaded.
That is "normal" - nothing to worry about here.

> [1.16] found entry name -> annex=B
> [1.192650] found entry name -> maca=BC:05:43:D7:1E:7C
> [1.197738] found entry name -> macb=BC:05:43:D7:1E:7D
> [1.202875] found entry name -> macwlan=BC:05:43:D7:1E:7E
> [1.208269] found entry name -> macdsl=BC:05:43:D7:1E:7F
> [1.213632] found entry name -> macwlan2=BC:05:43:D7:1E:81
> [1.219063] found entry name -> wlan_key=4004584479108575
> [1.227509] ath9k,eeprom ath9k_eep: endian check enabled.
> [1.231483] ath9k,eeprom ath9k_eep: using random mac
> [1.236475] ath9k,eeprom ath9k_eep: loaded ath9k eeprom
> [1.246508] UBIFS error (pid: 1): cannot open "ubi0:rootfs", error -19
> [1.257496] VFS: Mounted root (squashfs filesystem) readonly on device
> 31:3.
> [1.265035] Freeing unused kernel memory: 1224K (804fe000 - 8063)
> [2.475280] init: Console is alive
> .
>
> As you can see OpenWrt will find the mac-adesses from all devices, how can I
> asign it in the dts file?
I think you can't (at least not with the current tffs driver). All it
currently does is printing the mac addresses: [0]
My fritz_tffs_read tool is userspace only. The only downside is that
you currently cannot userspace tools to set the mac address in the
ath9k calibration data. We would need a solution like Christian's
OWL-loader, see [1] (or another TFFS kernel driver).

> The wiki is right. I will upload some images to the openwrt Wiki when the
> box is working.
> But phy0 and phy1 works only somtimes. In my dts file I assigned the reset
> GPIO's like in the FRITZ3370.dts file.
> I have take GPIO config from the AVM GPL sources. Is there anything I forgot
> orwrong in my new DTS file ?
I think the GPIOs definition is in the wrong place - it has to be per
PHY (thus you should put it into the mdio@0 section below).

I cannot see any ath9k messages in your kernel log - are you sure it's
being installed (/lib/modules/*/ath9k.ko)?
Your first patch lists kmod-ath9k, but if you added that after you
generated your .config then you're probably still missing it.
Please check "grep kmod-ath9k .config" and enable (set it to
=y/built-in) it if it's missing.


Martin


[0] 
https://github.com/openwrt/openwrt/blob/master/target/linux/lantiq/patches-4.4/0007-MIPS-lantiq-add-basic-tffs-driver.patch
[1] https://lists.openwrt.org/pipermail/openwrt-devel/2016-April/040755.html
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Add support for AVM Fritzbox 7360 SL

[Martin Blumenstingl]

On Sat, May 7, 2016 at 12:40 AM, Sebastian Ortwein  wrote:
> Hey
>
> I have tried do get openwrt working on my Fritzbox. Openwrt will start
> Network and VDSL Modem is working. But WLAN ist not working. The Chip is
> supported bei the ath9k driver. Any hint how I can get Wifi working ?
I see you already got most things working - see my comments inline.

> root@OpenWrt:/# dmesg
> [0.00] Linux version 4.4.7 (sebastian@sebastian-desktop) (gcc
> version 5.3.0 (OpenWrt GCC 5.3.0 r49296) ) #1 Fri May 6 22:23:36 UTC 2016
> [0.00] SoC: xRX200 rev 1.1
> [0.00] bootconsole [early0] enabled
> [0.00] CPU0 revision is: 00019555 (MIPS 34Kc)
> [0.00] MIPS: machine is FRITZ7360SL - 1&1 HomeServer
> [0.00] Determined physical RAM map:
> [0.00]  memory: 0800 @  (usable)
> [0.00] Initrd not found or empty - disabling initrd
> [0.00] Zone ranges:
> [0.00]   Normal   [mem 0x-0x07ff]
> [0.00] Movable zone start for each node
> [0.00] Early memory node ranges
> [0.00]   node   0: [mem 0x-0x07ff]
> [0.00] Initmem setup node 0 [mem
> 0x-0x07ff]
> [0.00] On node 0 totalpages: 32768
> [0.00] free_area_init_node: node 0, pgdat 804d6390, node_mem_map
> 81007a80
> [0.00]   Normal zone: 256 pages used for memmap
> [0.00]   Normal zone: 0 pages reserved
> [0.00]   Normal zone: 32768 pages, LIFO batch:7
> [0.00] Primary instruction cache 32kB, VIPT, 4-way, linesize 32
> bytes.
> [0.00] Primary data cache 32kB, 4-way, VIPT, cache aliases, linesize
> 32 bytes
> [0.00] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
> [0.00] pcpu-alloc: [0] 0
> [0.00] Built 1 zonelists in Zone order, mobility grouping on.  Total
> pages: 32512
> [0.00] Kernel command line: console=ttyLTQ0,115200 init=/etc/preinit
> [0.00] PID hash table entries: 512 (order: -1, 2048 bytes)
> [0.00] Dentry cache hash table entries: 16384 (order: 4, 65536
> bytes)
> [0.00] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
> [0.00] Writing ErrCtl register=00064202
> [0.00] Readback ErrCtl register=00064202
> [0.00] Memory: 123376K/131072K available (3764K kernel code, 164K
> rwdata, 1144K rodata, 1184K init, 211K bss, 7696K reserved, 0K cma-reserved)
> [0.00] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
> [0.00] NR_IRQS:256
> [0.00] CPU Clock: 500MHz
> [0.00] clocksource: MIPS: mask: 0x max_cycles: 0x,
> max_idle_ns: 7645041786 ns
> [0.12] sched_clock: 32 bits at 250MHz, resolution 4ns, wraps every
> 8589934590ns
> [0.007862] Calibrating delay loop... 332.54 BogoMIPS (lpj=665088)
> [0.042318] pid_max: default: 32768 minimum: 301
> [0.047171] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
> [0.053731] Mountpoint-cache hash table entries: 1024 (order: 0, 4096
> bytes)
> [0.03] clocksource: jiffies: mask: 0x max_cycles:
> 0x, max_idle_ns: 764504178510 ns
> [0.076441] pinctrl core: initialized pinctrl subsystem
> [0.082322] NET: Registered protocol family 16
> [0.091448] pinctrl-xway 1e100b10.pinmux: Init done
> [0.096999] dma-xway 1e104100.dma: Init done - hw rev: 7, ports: 7,
> channels: 28
> [ 0.206470] dcdc-xrx200 1f106a00.dcdc: Core Voltage : 1016 mV
> [ 0.347018] usbcore: registered new interface driver usbfs
> [ 0.352523] usbcore: registered new interface driver hub
> [ 0.357878] usbcore: registered new device driver usb
> [ 0.363254] PCI host bridge to bus :00
> [ 0.367244] pci_bus :00: root bus resource [mem 0x1c00-0x1cff]
> [ 0.374158] pci_bus :00: root bus resource [io 0x1d80-0x1d8f]
> [ 0.381101] pci_bus :00: root bus resource [??? 0x flags 0x0]
> [ 0.387957] pci_bus :00: No busn resource found for root bus, will use
> [bus 00-ff]
> [ 0.395990] pci :00:00.0: [15d1:0011] type 01 class 0x06
> [ 0.396028] ifx_pcie_rc_class_early_fixup: fixed pcie host bridge to pci-pci
> bridge
> [ 0.413669] ifx_pcie_fixup_resource: fixup host controller :00:00.0
> (15d1:0011)
> [ 0.421261] pci :00:00.0: PME# supported from D0 D3hot
> [ 0.421831] pci :01:00.0: [168c:ff1c] type 00 class 0x02
ff1c means that the calibration data was not loaded yet - see
FRITZ3370.dts for example.

> [ 0.421921] pci :01:00.0: reg 0x10: [mem 0x-0x 64bit]
> [ 0.422076] pci :01:00.0: supports D1
> [ 0.422096] pci :01:00.0: PME# supported from D0 D1 D3hot
> [ 0.422408] pci_bus :01: busn_res: [bus 01-ff] end is updated to 01
> [ 0.422448] pci_bus :00: busn_res: [bus 00-ff] end is updated to 01
> [ 0.422506] pci :00:00.0: BAR 8: assigned [mem 0x1c00-0x1c0f]
> [ 0.429195] pci :01:00.0: BAR 0: 

Re: [OpenWrt-Devel] [PATCH] lantiq: remove read-only flag on two partitions on BTHOMEHUBV3A

[Martin Blumenstingl]

On Mon, Apr 25, 2016 at 5:38 PM, Ben Mulvihill  wrote:
>> @Ben: one probably has to enable caldata swapping in the .dts.
>
> I saw your comment on openwrt.ebilan.co.uk that the "ath,eep-swap;"
> flag should be added to the dts in order to use unmodified calibration
> data, but actually this does not appear to be the case. I have just
> installed a board using unmodified calibration data and unmodified dts
> (apart from read-only flag) and it works fine. I then tried adding
> "ath,eep-swap;" just to see what would happen and it no longer worked.
probably because the values are swapped twice then, the first time
using the "wrong" 32bit swap method which results in the same problem
that existed before those ath9k patches.
great to hear that it's working for you :-)
___
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] lantiq: Fix status LED on TDW89X0 after boot is completed.

[Martin Blumenstingl]

On Mon, Apr 25, 2016 at 8:51 PM, Vittorio G (VittGam)
 wrote:
> For the record, if anyone wants the old behaviour they just need to put
> this in /etc/config/system:
>
> config led 'led_system'
> option name 'System'
> option sysfs 'tdw89x0:green:wps'
> option default '1'
>
> And the LED will default to on after a successful boot.
maybe you could document this in the wiki: [0]
Most people check the wiki when they are looking for configuration
hints like this


Martin

[0] https://wiki.openwrt.org/toh/tp-link/td-w8970
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [RFC] ramips: fix bad patch awake rt305x USB controller

[Martin Blumenstingl]

On Mon, Apr 25, 2016 at 3:11 PM, John Crispin  wrote:
> i dont see why this is needed.the patch in the tree does not look broken
> and seems to compile fine.
It seems that Hauke already pushed a similar fix:
https://dev.openwrt.org/changeset/49221/
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] lantiq: remove read-only flag on two partitions on BTHOMEHUBV3A

[Martin Blumenstingl]

On Mon, Apr 25, 2016 at 3:00 PM, John Crispin  wrote:
> is this not a bit risky ? normally we try to keep them read-only so that
> users cannot accidentally kill them. is the calib data normally not
> located in the art partition or why do you need to copy it after flashing ?
I think the caldata partition is made writable because of some bug in
ath9k which required HH3A users to manually modify the ath9k caldata.
This is not necessary anymore since my patch (+ Felix' fix on top of
it) is now upstream: [0]

@Ben: one probably has to enable caldata swapping in the .dts.
Then we have to figure out what to do with existing HH3A installations.


Martin

[0] 
https://github.com/torvalds/linux/commit/6fa658fd5ab26a769ca7df7bfdd53c212a0ba852
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v3] ipvs: Linux IP Virtual Server kernel modules (netfilter.mk patch)

[Martin Blumenstingl]

> The ftp module is in kernel 3, but not in kernel 4 for which the patch was 
> built.
> Is there a way to include modules conditionally dependent on the kernel 
> version?
sure, you can either exclude .ko files from the package/AUTOLOAD (see
[0]) or make a whole package depend on specific kernel versions (see
[1]).


[0] 
https://dev.openwrt.org/browser/trunk/package/kernel/linux/modules/crypto.mk#L111
[1] 
https://dev.openwrt.org/browser/trunk/package/kernel/linux/modules/crypto.mk#L30
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [RFC 2/3] kernel: owl-loader for delayed Atheros ath9k fixup

[Martin Blumenstingl]

On Thu, Mar 10, 2016 at 12:22 PM, Christian Lamparter
 wrote:
>> Seems like there are only two differences between the lantiq and the
>> ar71xx code:
>> 1. pci_write_config_dword(dev, PCI_BASE_ADDRESS_0, base); vs per-SoC
>> value in ar71xx
>> 2. swab32(val) when writing the caldata
> Ok, if this common arch-specific pci_ath9k_fixup isn't a thing.
> Then what about moving this to ath9k? As this code is duplicated
> for several archs in the same way (ar71xx, bcm63xx, lantiq and
> also a cut-down version can be found for mpc85xx [0]).
>
> We simply move the platform-specific "base" into ath9k_platform_data
> and pass it to the driver and have a bools to control whenever the
> vals need to be swapped or not.
sounds fine to me

@Felix: I added you because you are the mac80211 package maintainer.
would be great if you could comment on this patch and the whole idea
in this thread.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [RFC 2/3] kernel: owl-loader for delayed Atheros ath9k fixup

[Martin Blumenstingl]

On Wed, Mar 9, 2016 at 6:30 PM, Christian Lamparter
 wrote:
> lantiq on the other hand has copied the func from ar71xx and adapted
> and renamed it, but kept the signature:
> ltq_pci_ath_fixup(unsigned slot, u16 *cal_data)
> it's in arch/mips/lantiq/xway/pci-ath-fixup.c.
Maybe we could also move pci-ath-fixup.c to a separate package (or
even the same as owl-loader)?

Seems like there are only two differences between the lantiq and the
ar71xx code:
1. pci_write_config_dword(dev, PCI_BASE_ADDRESS_0, base); vs per-SoC
value in ar71xx
2. swab32(val) when writing the caldata


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

Re: [OpenWrt-Devel] [RFC 2/3] kernel: owl-loader for delayed Atheros ath9k fixup

[Martin Blumenstingl]

On Wed, Mar 9, 2016 at 12:14 AM, Christian Lamparter
 wrote:
> Some devices (like the Cisco Meraki Z1 Cloud Managed Teleworker Gateway)
> need to be able to initialize the PCIe wifi device. Normally, this is done
> during the early stages of booting linux, because the necessary init code
> is read from the memory mapped SPI and passed to pci_enable_ath9k_fixup.
> However,this isn't possible for devices which have the init code for the
> Atheros chip stored on NAND. Hence, this module can be used to initialze
> the chip when the user-space is ready to extract the init code.
I assume that you are speaking of UBI when you said "NAND".
This case is tricky indeed, because the UBI initialization starts as
late_initcall. Additionally there is some event-handling inside
UBI/ubifs which makes it hard to read from an ubi volume from another
kernel driver.

Mathias and I have already experimented with reading calibration data
from an UBI volume (we started with MAC addresses, but it will be the
same for the ath9k caldata).
It sounds easy at first sight, but it turns out to be tricky.

I would like to find a generic solution for this (which does not
depend on the ar71xx target) because we probably need the same code
for the lantiq target as well.


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

Re: [OpenWrt-Devel] [PATCH v3 01/11] dsl-vrx200-firmware-xdsl: create Lantiq vrx200 firmware patches

[Martin Blumenstingl]

On Tue, Mar 8, 2016 at 7:49 AM, John Crispin  wrote:
> what happened to these patches ? it look slike they are gone from
> patchwork and they dont seem to apply.
it seems that Felix has already merged them yesterday (in svn r48939)
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] lantiq/xrx200-net: separate lan and wan ports

[Martin Blumenstingl]

On Tue, Feb 16, 2016 at 8:06 AM, Martin Schiller  wrote:
> Hi!
>
> I need to set up the xrx200 switch with one LAN switch part (phy2-phy5) and 
> one WAN port (phy1).
>
> The problem is, that I can see the LAN traffic on the WAN port and vice versa.
>
> It doesn't also matter if SW_PORTMAP is defined or not.
>
> I think it maybe has something to do with the PCE_PMAPx setup, but how to set 
> this port mappings to get separated LAN and WAN groups?
I think you are right on this one. There's one user who investigated
some PPPoE/broadcast issue with the WAN port and here's what he found
out: [0]
Here's where the initialization takes place in the OpenWrt driver: [1]

To sum up "ased's" findings, the original driver (at least in some of
the ifxmips_ppa_datapath_vr9_* configurations):
- PCE_PMAP1 is set to 0x40 (= port 7 / CPU port) instead of 0x7f (= all ports)
- PCE_PMAP2 and 3 are set to 0x7f & (~priv->hw->wan_map) ("all but the
configured WAN port(s)")

I don't have access to the datasheets, so I cannot say what
"monitoring" means exactly (PCE_PMAP1).
Unfortunately I did not have time to play around with it yet, so I
can't tell you much more.
But maybe someone with access to the datasheets can at least confirm
this and explain the PCE_PMAP1 register.


Regards,
Martin


[0] http://openwrt.ebilan.co.uk/viewtopic.php?p=893#p893
[1] 
https://github.com/openwrt/openwrt/blob/master/target/linux/lantiq/patches-4.4/0025-NET-MIPS-lantiq-adds-xrx200-net.patch#L1696
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] loading calibration data from UBI volume

[Martin Blumenstingl]

Hello,

currently we (Mathias and I) are planning to simplify the installation
procedure for a lantiq based device (HH5A).
Currently the installation steps require copying the calibration data
from an UBI volume on the original firmware and moving the data to a
separate mtd partition. This way the mac-addresses and ath9k caldata
can be given using phandles to that partition in mtd-mac-address and
ath,eep-flash.

However, to simplify the installation we would like to get rid of
those manual steps and leave the caldata as an UBI volume.
This brings up two problems:
1. mtd-mac-address cannot be used anymore because we don't have an mtd
device anymore
2. ath,eep-flash has the same problem

I have come up with two ideas for which I'd like to hear your comments
(other ideas are always welcome too):
- moving all handling from kernel-space to userspace by utilizing the
request_firmware() mechanism (this might cause problems because on the
lantiq target the ath9k caldata is needed very early for the PCI fixup
mechanism)
- implementing ubivol-mac-address and ath,eep-ubivol (= similar to
mtd-mac-address and ath,eep-flash) which get the name of an ubi volume
and the offset passed


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

[OpenWrt-Devel] [PATCH] lantiq: Make the ar9.dtsi sram node match "simple-bus"

[Martin Blumenstingl]

All other SoC types are using "lantiq,sram" and "simple-bus" to ensure
that all child nodes are set up correctly during linux kernel
initialization (plat_of_setup(void) in arch/mips/lantiq/prom.c). Without
this some of sram child nodes might not be parsed.

Signed-off-by: Martin Blumenstingl <martin.blumensti...@googlemail.com>
---
 target/linux/lantiq/dts/ar9.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/linux/lantiq/dts/ar9.dtsi b/target/linux/lantiq/dts/ar9.dtsi
index 0be95c3..9feb8a0 100644
--- a/target/linux/lantiq/dts/ar9.dtsi
+++ b/target/linux/lantiq/dts/ar9.dtsi
@@ -40,7 +40,7 @@
sram@1F00 {
#address-cells = <1>;
#size-cells = <1>;
-   compatible = "lantiq,sram";
+   compatible = "lantiq,sram", "simple-bus";
reg = <0x1F00 0x80>;
ranges = <0x0 0x1F00 0x7F>;
 
-- 
2.7.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] lantiq: Move the definition of the xrx200-net node to vr9.dtsi

[Martin Blumenstingl]

This removes a lot of duplicate register and interrupt definitions by
moving the xrx200-net definition to vr9.dtsi and making all devices re-
use it.

Signed-off-by: Martin Blumenstingl <martin.blumensti...@googlemail.com>
---
 target/linux/lantiq/dts/ARV7519RW22.dts  | 147 -
 target/linux/lantiq/dts/BTHOMEHUBV5A.dts | 170 ++---
 target/linux/lantiq/dts/EASY80920.dtsi   | 179 +++
 target/linux/lantiq/dts/FRITZ3370.dts| 131 +++---
 target/linux/lantiq/dts/P2812HNUFX.dtsi  | 148 -
 target/linux/lantiq/dts/TDW89X0.dtsi | 129 ++
 target/linux/lantiq/dts/VG3503J.dtsi |  85 +++
 target/linux/lantiq/dts/VGV7510KW22.dtsi | 129 ++
 target/linux/lantiq/dts/VGV7519.dtsi | 173 ++---
 target/linux/lantiq/dts/VR200v.dts   | 129 ++
 target/linux/lantiq/dts/vr9.dtsi |  13 +++
 11 files changed, 669 insertions(+), 764 deletions(-)

diff --git a/target/linux/lantiq/dts/ARV7519RW22.dts 
b/target/linux/lantiq/dts/ARV7519RW22.dts
index dfc7e8f..6f5d356 100644
--- a/target/linux/lantiq/dts/ARV7519RW22.dts
+++ b/target/linux/lantiq/dts/ARV7519RW22.dts
@@ -72,85 +72,6 @@
};
};
 
-   eth@E108000 {
-   #address-cells = <1>;
-   #size-cells = <0>;
-   compatible = "lantiq,xrx200-net";
-   reg = < 0xE108000 0x3000 /* switch */
-   0xE10B100 0x70 /* mdio */
-   0xE10B1D8 0x30 /* mii */
-   0xE10B308 0x30 /* pmac */
-   >;
-   interrupt-parent = <>;
-   interrupts = <73 72>;
-
-   lan: interface@0 {
-   compatible = "lantiq,xrx200-pdi";
-   #address-cells = <1>;
-   #size-cells = <0>;
-   reg = <0>;
-   mtd-mac-address = < 0x16>;
-   lantiq,switch;
-
-   ethernet@0 {
-   compatible = "lantiq,xrx200-pdi-port";
-   reg = <0>;
-   phy-mode = "rgmii";
-   phy-handle = <>;
-   };
-   ethernet@1 {
-   compatible = "lantiq,xrx200-pdi-port";
-   reg = <4>;
-   phy-mode = "mii";
-   phy-handle = <>;
-   };
-   ethernet@2 {
-   compatible = "lantiq,xrx200-pdi-port";
-   reg = <5>;
-   phy-mode = "mii";
-   phy-handle = <>;
-   };
-   ethernet@3 {
-   compatible = "lantiq,xrx200-pdi-port";
-   reg = <2>;
-   phy-mode = "mii";
-   phy-handle = <>;
-   };
-   ethernet@4 {
-   compatible = "lantiq,xrx200-pdi-port";
-   reg = <3>;
-   phy-mode = "mii";
-   phy-handle = <>;
-   };
-   };
-
-   mdio@0 {
-   #address-cells = <1>;
-   #size-cells = <0>;
-   compatible = "lantiq,xrx200-mdio";
-   phy0: ethernet-phy@0 {
-   reg = <0x0>;
-   compatible = "lantiq,phy11g", 
"ethernet-phy-ieee802.3-c22";
-   };
-   phy11: ethernet-phy@11 {
-   reg = <0x11>;
-   compatible = "lantiq,phy22f", 
"ethernet-phy-ieee802.3-c22";
-   };
-   phy12: et

[OpenWrt-Devel] [PATCH] lantiq: Enable the uImage mtd splitter

[Martin Blumenstingl]

Until linux 4.1 the lantiq target used CONFIG_MTD_UIMAGE_SPLIT=y. That
option however is only available until linux 4.3 - thus it was not added
to lantiq's 4.4 kernel config (in r48307). This results in broken images
for devices which are using uImages. This fixes #21652

Signed-off-by: Martin Blumenstingl <martin.blumensti...@googlemail.com>
---
 target/linux/lantiq/config-4.4 | 1 +
 1 file changed, 1 insertion(+)

diff --git a/target/linux/lantiq/config-4.4 b/target/linux/lantiq/config-4.4
index 8943c6f..08a1228 100644
--- a/target/linux/lantiq/config-4.4
+++ b/target/linux/lantiq/config-4.4
@@ -141,6 +141,7 @@ CONFIG_MTD_SPLIT_BRNIMAGE_FW=y
 CONFIG_MTD_SPLIT_EVA_FW=y
 CONFIG_MTD_SPLIT_FIRMWARE=y
 CONFIG_MTD_SPLIT_TPLINK_FW=y
+CONFIG_MTD_SPLIT_UIMAGE_FW=Y
 CONFIG_NEED_DMA_MAP_STATE=y
 CONFIG_NEED_PER_CPU_KM=y
 CONFIG_NO_GENERIC_PCI_IOPORT_MAP=y
-- 
2.7.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] lantiq: Fix enabling CONFIG_MTD_UIMAGE_SPLIT

[Martin Blumenstingl]

r48381 added CONFIG_MTD_SPLIT_UIMAGE_FW=Y to the lantiq kernel
configuration. That unfortunately contains a typo since the "y" has to
be lower-case. This leads to the kernel asking whether the config
symbol should be enabled and thus breaking the build.

FIXES: r48381/feab990887b4: lantiq: Enable the uImage mtd splitter
Signed-off-by: Martin Blumenstingl <martin.blumensti...@googlemail.com>
---
 target/linux/lantiq/config-4.4 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/linux/lantiq/config-4.4 b/target/linux/lantiq/config-4.4
index 08a1228..5d4b7cc 100644
--- a/target/linux/lantiq/config-4.4
+++ b/target/linux/lantiq/config-4.4
@@ -141,7 +141,7 @@ CONFIG_MTD_SPLIT_BRNIMAGE_FW=y
 CONFIG_MTD_SPLIT_EVA_FW=y
 CONFIG_MTD_SPLIT_FIRMWARE=y
 CONFIG_MTD_SPLIT_TPLINK_FW=y
-CONFIG_MTD_SPLIT_UIMAGE_FW=Y
+CONFIG_MTD_SPLIT_UIMAGE_FW=y
 CONFIG_NEED_DMA_MAP_STATE=y
 CONFIG_NEED_PER_CPU_KM=y
 CONFIG_NO_GENERIC_PCI_IOPORT_MAP=y
-- 
2.7.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 01/13] lantiq: Backport upstream pinctrl-xway patches from 4.5

[Martin Blumenstingl]

Upstream commit be14811c03cf2 "pinctrl/lantiq: introduce new dedicated
devicetree bindings" allows us to use each pin in the pinmux. This is
useful for example in the "spi" group which contains some pins which
are inputs, and some which are outputs.
These can only be used once the new compatible strings for the pinctrl
node are used.
Additionally 0150-lantiq-pinctrl-xway.patch and the "GPIO PORT3 fix"
(which was part of 0012-pinctrl-lantiq-fix-up-pinmux.patch) were
replaced with their upstream variants which are also in 4.5.

Signed-off-by: Martin Blumenstingl <martin.blumensti...@googlemail.com>
---
 .../0012-pinctrl-lantiq-fix-up-pinmux.patch|   15 +-
 ...tiq-introduce-new-dedicated-devicetree-bi.patch | 1378 
 ...nctrl-lantiq-Fix-GPIO-Setup-of-GPIO-Port3.patch |   28 +
 ...trl-lantiq-2-pins-have-the-wrong-mux-list.patch |   28 +
 .../patches-4.1/0150-lantiq-pinctrl-xway.patch |   15 -
 5 files changed, 1436 insertions(+), 28 deletions(-)
 create mode 100644 
target/linux/lantiq/patches-4.1/0044-pinctrl-lantiq-introduce-new-dedicated-devicetree-bi.patch
 create mode 100644 
target/linux/lantiq/patches-4.1/0045-pinctrl-lantiq-Fix-GPIO-Setup-of-GPIO-Port3.patch
 create mode 100644 
target/linux/lantiq/patches-4.1/0046-pinctrl-lantiq-2-pins-have-the-wrong-mux-list.patch
 delete mode 100644 
target/linux/lantiq/patches-4.1/0150-lantiq-pinctrl-xway.patch

diff --git 
a/target/linux/lantiq/patches-4.1/0012-pinctrl-lantiq-fix-up-pinmux.patch 
b/target/linux/lantiq/patches-4.1/0012-pinctrl-lantiq-fix-up-pinmux.patch
index ecd143f..8a5d270 100644
--- a/target/linux/lantiq/patches-4.1/0012-pinctrl-lantiq-fix-up-pinmux.patch
+++ b/target/linux/lantiq/patches-4.1/0012-pinctrl-lantiq-fix-up-pinmux.patch
@@ -39,18 +39,7 @@ Signed-off-by: John Crispin <blo...@openwrt.org>
  static const struct ltq_cfg_param xway_cfg_params[] = {
{"lantiq,pull", LTQ_PINCONF_PARAM_PULL},
{"lantiq,open-drain",   LTQ_PINCONF_PARAM_OPEN_DRAIN},
-@@ -676,6 +683,10 @@ static int xway_gpio_dir_out(struct gpio
- {
-   struct ltq_pinmux_info *info = dev_get_drvdata(chip->dev);
- 
-+  if (PORT(pin) == PORT3)
-+  gpio_setbit(info->membase[0], GPIO3_OD, PORT_PIN(pin));
-+  else
-+  gpio_setbit(info->membase[0], GPIO_OD(pin), PORT_PIN(pin));
-   gpio_setbit(info->membase[0], GPIO_DIR(pin), PORT_PIN(pin));
-   xway_gpio_set(chip, pin, val);
- 
-@@ -696,6 +707,18 @@ static void xway_gpio_free(struct gpio_c
+@@ -696,6 +703,18 @@ static void xway_gpio_free(struct gpio_c
pinctrl_free_gpio(gpio);
  }
  
@@ -69,7 +58,7 @@ Signed-off-by: John Crispin <blo...@openwrt.org>
  static struct gpio_chip xway_chip = {
.label = "gpio-xway",
.direction_input = xway_gpio_dir_in,
-@@ -704,6 +727,7 @@ static struct gpio_chip xway_chip = {
+@@ -704,6 +723,7 @@ static struct gpio_chip xway_chip = {
.set = xway_gpio_set,
.request = xway_gpio_req,
.free = xway_gpio_free,
diff --git 
a/target/linux/lantiq/patches-4.1/0044-pinctrl-lantiq-introduce-new-dedicated-devicetree-bi.patch
 
b/target/linux/lantiq/patches-4.1/0044-pinctrl-lantiq-introduce-new-dedicated-devicetree-bi.patch
new file mode 100644
index 000..bfa8b35
--- /dev/null
+++ 
b/target/linux/lantiq/patches-4.1/0044-pinctrl-lantiq-introduce-new-dedicated-devicetree-bi.patch
@@ -0,0 +1,1378 @@
+From be14811c03cf20c793fd176a347625335110b0e6 Mon Sep 17 00:00:00 2001
+From: Martin Schiller <mschil...@tdt.de>
+Date: Thu, 26 Nov 2015 11:00:07 +0100
+Subject: [PATCH] pinctrl/lantiq: introduce new dedicated devicetree bindings
+
+This patch introduces new dedicated "lantiq,-pinctrl" devicetree
+bindings, where  is one of "ase", "danube", "xrx100", "xrx200" or
+"xrx300" and marks the "lantiq,pinctrl-xway", "lantiq,pinctrl-ase" and
+"lantiq,pinctrl-xr9" bindings as DEPRECATED.
+
+Based on the newest Lantiq Hardware Description it turend out, that there are
+some differences in the GPIO alternative functions of the Danube, xRX100 and
+xRX200 families, which makes it impossible to use only one xway_mfp table.
+
+This patch also adds support for the xRX300 family.
+
+Signed-off-by: Martin Schiller <mschil...@tdt.de>
+Signed-off-by: Linus Walleij <linus.wall...@linaro.org>
+---
+ drivers/pinctrl/pinctrl-lantiq.h |8 +
+ drivers/pinctrl/pinctrl-xway.c   | 1181 +-
+ 2 files changed, 1059 insertions(+), 130 deletions(-)
+
+--- a/drivers/pinctrl/pinctrl-lantiq.h
 b/drivers/pinctrl/pinctrl-lantiq.h
+@@ -162,6 +162,14 @@ enum ltq_pin {
+   GPIO53,
+   GPIO54,
+   GPIO55,
++  GPIO56,
++  GPIO57,
++  GPIO58,
++  GPIO59,
++  GPIO60, /* 60 */
++  GPIO61,
++  GPIO62,
++  GPIO63,
+ 
+   GPIO64,
+   

[OpenWrt-Devel] lantiq: SPI cleanups and update to the new SPI driver

[Martin Blumenstingl]

While upgrading the lantiq target to linux 4.4 it was discovered that the
SPI driver is not working with 4.4 anymore. Fixing it also does not seem
to be trivial.
However, Daniel Schwierzeck (thanks!) has provided a rewritten SPI driver.
His version works fine on 4.1 and 4.5, is now independant of spi-bitbang
and uses the same chip-select numbering as described in the datasheets.

While updating to this version there are some related clean-ups:
- our device .dts files are now initializing SPI correctly, regardless
  of the state in which the bootloader leaves the SPI pins
- all devices are now using the hardware SPI driver (FRITZ3370 and
  DGN3500/DGN3500B were still using spi-gpio)
- SPI can be re-enabled on EASY80920 since the SPI driver actually works
  now
- Due to pinctrl changes (see patch 01 - 03) the hardcoded PCIe reset
  GPIO did not work anymore - thus we are now passing it via device-tree

I have successfully tested this changeset on two devices:
- TD-W8970 which uses SPI flash
- an ARX100 based board with NOR flash (to ensure that the pinctrl changes
  did not break other boards)
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 03/13] lantiq: Configure the PCIe reset GPIO using OF

[Martin Blumenstingl]

After the latest pinctrl backports there are only 50 (instead of 56 as
before) GPIOs/pins exported (thus the first GPIO on VRX200 SoCs is now
462, before it was 456). This means that any hardcoded GPIOs have to be
adjusted.
This broke the PCIe driver (which seems to be the only driver which uses
hardcoded GPIO numbers), it only reports:
ifx_pcie_wait_phy_link_up timeout
ifx_pcie_wait_phy_link_up timeout
ifx_pcie_wait_phy_link_up timeout
ifx_pcie_wait_phy_link_up timeout
ifx_pcie_wait_phy_link_up timeout
pcie_rc_initialize link up failed!

To prevent more of these issues in the future we remove the hardcoded
PCIe reset GPIO definition and simply pass it via device-tree (like the
PCI driver does).

Signed-off-by: Martin Blumenstingl <martin.blumensti...@googlemail.com>
---
 target/linux/lantiq/dts/vr9.dtsi   |   1 +
 .../0151-lantiq-ifxmips_pcie-use-of.patch  | 113 -
 2 files changed, 111 insertions(+), 3 deletions(-)

diff --git a/target/linux/lantiq/dts/vr9.dtsi b/target/linux/lantiq/dts/vr9.dtsi
index 8f96358..2330bf1 100644
--- a/target/linux/lantiq/dts/vr9.dtsi
+++ b/target/linux/lantiq/dts/vr9.dtsi
@@ -175,6 +175,7 @@
interrupt-parent = <>;
interrupts = <161 144>;
compatible = "lantiq,pcie-xrx200";
+   gpio-reset = < 38 0>;
};
 
pci0: pci@E105400 {
diff --git 
a/target/linux/lantiq/patches-4.1/0151-lantiq-ifxmips_pcie-use-of.patch 
b/target/linux/lantiq/patches-4.1/0151-lantiq-ifxmips_pcie-use-of.patch
index 26a3a65..ed7927e 100644
--- a/target/linux/lantiq/patches-4.1/0151-lantiq-ifxmips_pcie-use-of.patch
+++ b/target/linux/lantiq/patches-4.1/0151-lantiq-ifxmips_pcie-use-of.patch
@@ -1,24 +1,77 @@
 --- a/arch/mips/pci/ifxmips_pcie.c
 +++ b/arch/mips/pci/ifxmips_pcie.c
-@@ -18,6 +18,8 @@
+@@ -18,6 +18,9 @@
  #include 
  #include 
  
++#include 
 +#include 
 +
  #include "ifxmips_pcie.h"
  #include "ifxmips_pcie_reg.h"
  
-@@ -1045,7 +1047,7 @@ pcie_rc_initialize(int pcie_port)
+@@ -40,6 +43,7 @@
+ static DEFINE_SPINLOCK(ifx_pcie_lock);
+ 
+ u32 g_pcie_debug_flag = PCIE_MSG_ANY & (~PCIE_MSG_CFG);
++static int pcie_reset_gpio;
+ 
+ static ifx_pcie_irq_t pcie_irqs[IFX_PCIE_CORE_NR] = {
+ {
+@@ -82,6 +86,22 @@ void ifx_pcie_debug(const char *fmt, ...
+   printk("%s", buf);
+ }
+ 
++static inline void pcie_ep_gpio_rst_init(int pcie_port)
++{
++  gpio_direction_output(pcie_reset_gpio, 1);
++  gpio_set_value(pcie_reset_gpio, 1);
++}
++
++static inline void pcie_device_rst_assert(int pcie_port)
++{
++  gpio_set_value(pcie_reset_gpio, 0);
++}
++
++static inline void pcie_device_rst_deassert(int pcie_port)
++{
++  mdelay(100);
++  gpio_direction_output(pcie_reset_gpio, 1);
++}
+ 
+ static inline int pcie_ltssm_enable(int pcie_port)
+ {
+@@ -1045,8 +1065,9 @@ pcie_rc_initialize(int pcie_port)
return 0;
  }
  
 -static int __init ifx_pcie_bios_init(void)
 +static int __init ifx_pcie_bios_probe(struct platform_device *pdev)
  {
++struct device_node *node = pdev->dev.of_node;
  void __iomem *io_map_base;
  int pcie_port;
-@@ -1083,6 +1085,30 @@ static int __init ifx_pcie_bios_init(voi
+ int startup_port;
+@@ -1055,7 +1076,17 @@ static int __init ifx_pcie_bios_init(voi
+ pcie_ahb_pmu_setup();
+ 
+ startup_port = IFX_PCIE_PORT0;
+-
++
++pcie_reset_gpio = of_get_named_gpio(node, "gpio-reset", 0);
++if (gpio_is_valid(pcie_reset_gpio)) {
++int ret = devm_gpio_request(>dev, pcie_reset_gpio, 
"pcie-reset");
++if (ret) {
++dev_err(>dev, "failed to request gpio %d\n", 
pcie_reset_gpio);
++return ret;
++}
++gpio_direction_output(pcie_reset_gpio, 1);
++}
++
+ for (pcie_port = startup_port; pcie_port < IFX_PCIE_CORE_NR; pcie_port++){
+   if (pcie_rc_initialize(pcie_port) == 0) {
+   IFX_PCIE_PRINT(PCIE_MSG_INIT, "%s: ifx_pcie_cfg_base 0x%p\n", 
+@@ -1083,6 +1114,30 @@ static int __init ifx_pcie_bios_init(voi
  
  return 0;
  }
@@ -49,3 +102,57 @@
  arch_initcall(ifx_pcie_bios_init);
  
  MODULE_LICENSE("GPL");
+--- a/arch/mips/pci/ifxmips_pcie_vr9.h
 b/arch/mips/pci/ifxmips_pcie_vr9.h
+@@ -22,8 +22,6 @@
+ #include 
+ #include 
+ 
+-#define IFX_PCIE_GPIO_RESET  494
+-
+ #define IFX_REG_R32ltq_r32
+ #define IFX_REG_W32ltq_w32
+ #define CONFIG_IFX_PCIE_HW_SWAP
+@@ -53,21 +51,6 @@
+ #define OUT   ((volatile u32*)(IFX_GPIO + 0x0070))
+ 
+ 
+-static inline void pcie_ep_gpio_rst_init(int pcie_port)
+-{
+-
+-  gpio_request(IFX_PCIE_GPIO_RESET, "pcie-reset");
+-  gpio_direction_output(IFX_PCIE_GPIO_RESET, 1);
+-  gpio_set_value(IFX_PCIE_GPIO_RESET, 1);
+-
+-/*ifx_gpio_pin_reserve(IFX_PC

[OpenWrt-Devel] [PATCH 02/13] lantiq: Use the new pinctrl compatible strings

[Martin Blumenstingl]

These were introduced in upstream commit
be14811c03cf "pinctrl/lantiq: introduce new dedicated devicetree
bindings" and finally allow us to use the individual pins within our dts
(for example spi_clk, etc.).
Please note that this changes the number of GPIOs which are available for
some SoCs. VRX200 SoCs for example only have 50 pins, but previously 56
pins were exposed. This means that all places which are using hardcoded
GPIO numbers (which are not passed via device-tree) need to be adjusted
(because the first GPIO number is now 462, instead of 456).

Signed-off-by: Martin Blumenstingl <martin.blumensti...@googlemail.com>
---
 target/linux/lantiq/dts/amazonse.dtsi | 2 +-
 target/linux/lantiq/dts/ar9.dtsi  | 2 +-
 target/linux/lantiq/dts/danube.dtsi   | 2 +-
 target/linux/lantiq/dts/vr9.dtsi  | 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/target/linux/lantiq/dts/amazonse.dtsi 
b/target/linux/lantiq/dts/amazonse.dtsi
index 13d3e73..5389446 100644
--- a/target/linux/lantiq/dts/amazonse.dtsi
+++ b/target/linux/lantiq/dts/amazonse.dtsi
@@ -90,7 +90,7 @@
};
 
gpio: pinmux@E100B10 {
-   compatible = "lantiq,pinctrl-ase";
+   compatible = "lantiq,ase-pinctrl";
#gpio-cells = <2>;
gpio-controller;
reg = <0xE100B10 0xA0>;
diff --git a/target/linux/lantiq/dts/ar9.dtsi b/target/linux/lantiq/dts/ar9.dtsi
index ee4e374..f69a7ae 100644
--- a/target/linux/lantiq/dts/ar9.dtsi
+++ b/target/linux/lantiq/dts/ar9.dtsi
@@ -101,7 +101,7 @@
};
 
gpio: pinmux@E100B10 {
-   compatible = "lantiq,pinctrl-xr9";
+   compatible = "lantiq,xrx100-pinctrl";
#gpio-cells = <2>;
gpio-controller;
reg = <0xE100B10 0xA0>;
diff --git a/target/linux/lantiq/dts/danube.dtsi 
b/target/linux/lantiq/dts/danube.dtsi
index 698196d..0a75fd9 100644
--- a/target/linux/lantiq/dts/danube.dtsi
+++ b/target/linux/lantiq/dts/danube.dtsi
@@ -123,7 +123,7 @@
};
 
gpio: pinmux@E100B10 {
-   compatible = "lantiq,pinctrl-xway";
+   compatible = "lantiq,danube-pinctrl";
#gpio-cells = <2>;
gpio-controller;
reg = <0xE100B10 0xA0>;
diff --git a/target/linux/lantiq/dts/vr9.dtsi b/target/linux/lantiq/dts/vr9.dtsi
index df63ce7..8f96358 100644
--- a/target/linux/lantiq/dts/vr9.dtsi
+++ b/target/linux/lantiq/dts/vr9.dtsi
@@ -113,7 +113,7 @@
};
 
gpio: pinmux@E100B10 {
-   compatible = "lantiq,pinctrl-xr9";
+   compatible = "lantiq,xrx200-pinctrl";
#gpio-cells = <2>;
gpio-controller;
reg = <0xE100B10 0xA0>;
-- 
2.7.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 05/13] lantiq: Re-use the SPI node from vr9.dtsi in TDW89X0.dtsi

[Martin Blumenstingl]

This removes the duplicate SPI register definition.

Signed-off-by: Martin Blumenstingl <martin.blumensti...@googlemail.com>
---
 target/linux/lantiq/dts/TDW89X0.dtsi | 76 +---
 1 file changed, 36 insertions(+), 40 deletions(-)

diff --git a/target/linux/lantiq/dts/TDW89X0.dtsi 
b/target/linux/lantiq/dts/TDW89X0.dtsi
index 99b4ecb..30225d5 100644
--- a/target/linux/lantiq/dts/TDW89X0.dtsi
+++ b/target/linux/lantiq/dts/TDW89X0.dtsi
@@ -21,46 +21,6 @@
};
 
fpi@1000 {
-   spi@E100800 {
-   compatible = "lantiq,spi-xway";
-   reg = <0xE100800 0x100>;
-   interrupt-parent = <>;
-   interrupts = <22 23 24>;
-   #address-cells = <1>;
-   #size-cells = <1>;
-   m25p80@0 {
-   #address-cells = <1>;
-   #size-cells = <1>;
-   compatible = "jedec,spi-nor";
-   reg = <3 0>;
-   spi-max-frequency = <3325>;
-   m25p,fast-read;
-
-   partition@0 {
-   reg = <0x0 0x2>;
-   label = "u-boot";
-   read-only;
-   };
-
-   partition@2 {
-   reg = <0x2 0x7a>;
-   label = "firmware";
-   };
-
-   partition@7c {
-   reg = <0x7c 0x1>;
-   label = "config";
-   read-only;
-   };
-
-   ath9k_cal: partition@7d {
-   reg = <0x7d 0x3>;
-   label = "boardconfig";
-   read-only;
-   };
-   };
-   };
-
gpio: pinmux@E100B10 {
pinctrl-names = "default";
pinctrl-0 = <_default>;
@@ -249,3 +209,39 @@
};
};
 };
+
+ {
+   status = "ok";
+
+   m25p80@3 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "jedec,spi-nor";
+   reg = <3 0>;
+   spi-max-frequency = <3325>;
+   m25p,fast-read;
+
+   partition@0 {
+   reg = <0x0 0x2>;
+   label = "u-boot";
+   read-only;
+   };
+
+   partition@2 {
+   reg = <0x2 0x7a>;
+   label = "firmware";
+   };
+
+   partition@7c {
+   reg = <0x7c 0x1>;
+   label = "config";
+   read-only;
+   };
+
+   ath9k_cal: partition@7d {
+   reg = <0x7d 0x3>;
+   label = "boardconfig";
+   read-only;
+   };
+   };
+};
-- 
2.7.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 07/13] lantiq: Enable SPI for the EASY80920 board again

[Martin Blumenstingl]

Also switch to the SPI definition provided by vr9.dtsi

Signed-off-by: Martin Blumenstingl <martin.blumensti...@googlemail.com>
---
 target/linux/lantiq/dts/EASY80920.dtsi | 87 --
 1 file changed, 41 insertions(+), 46 deletions(-)

diff --git a/target/linux/lantiq/dts/EASY80920.dtsi 
b/target/linux/lantiq/dts/EASY80920.dtsi
index cf37e23..56efe71 100644
--- a/target/linux/lantiq/dts/EASY80920.dtsi
+++ b/target/linux/lantiq/dts/EASY80920.dtsi
@@ -32,52 +32,6 @@
 
};
 
-   spi@E100800 {
-   compatible = "lantiq,spi-xway-broken";
-   reg = <0xE100800 0x100>;
-   interrupt-parent = <>;
-   interrupts = <22 23 24>;
-   #address-cells = <1>;
-   #size-cells = <1>;
-
-   m25p80@0 {
-   #address-cells = <1>;
-   #size-cells = <1>;
-   compatible = "jedec,spi-nor";
-   reg = <0 0>;
-   spi-max-frequency = <100>;
-
-   partition@0 {
-   reg = <0x0 0x2>;
-   label = "SPI (RO) U-Boot Image";
-   read-only;
-   };
-
-   partition@2 {
-   reg = <0x2 0x1>;
-   label = "ENV_MAC";
-   read-only;
-   };
-
-   partition@3 {
-   reg = <0x3 0x1>;
-   label = "DPF";
-   read-only;
-   };
-
-   partition@4 {
-   reg = <0x4 0x1>;
-   label = "NVRAM";
-   read-only;
-   };
-
-   partition@50 {
-   reg = <0x5 0x003a>;
-   label = "kernel";
-   };
-   };
-   };
-
gpio: pinmux@E100B10 {
compatible = "lantiq,pinctrl-xr9";
pinctrl-names = "default";
@@ -341,3 +295,44 @@
};
};
 };
+
+ {
+   status = "ok";
+
+   m25p80@3 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "jedec,spi-nor";
+   reg = <3 0>;
+   spi-max-frequency = <100>;
+
+   partition@0 {
+   reg = <0x0 0x2>;
+   label = "SPI (RO) U-Boot Image";
+   read-only;
+   };
+
+   partition@2 {
+   reg = <0x2 0x1>;
+   label = "ENV_MAC";
+   read-only;
+   };
+
+   partition@3 {
+   reg = <0x3 0x1>;
+   label = "DPF";
+   read-only;
+   };
+
+   partition@4 {
+   reg = <0x4 0x1>;
+   label = "NVRAM";
+   read-only;
+   };
+
+   partition@50 {
+   reg = <0x5 0x003a>;
+   label = "kernel";
+   };
+   };
+};
-- 
2.7.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 06/13] lantiq: Switch FRITZ3370 from spi-gpio to the hardware SPI driver

[Martin Blumenstingl]

Signed-off-by: Martin Blumenstingl <martin.blumensti...@googlemail.com>
---
 target/linux/lantiq/dts/FRITZ3370.dts | 71 +++
 1 file changed, 31 insertions(+), 40 deletions(-)

diff --git a/target/linux/lantiq/dts/FRITZ3370.dts 
b/target/linux/lantiq/dts/FRITZ3370.dts
index 7344052..c6a593b 100644
--- a/target/linux/lantiq/dts/FRITZ3370.dts
+++ b/target/linux/lantiq/dts/FRITZ3370.dts
@@ -68,7 +68,7 @@
state_default: pinmux {
spi {
lantiq,groups = "spi", "spi_cs4";
-   lantiq,function = "gpio";
+   lantiq,function = "spi";
};
mdio {
lantiq,groups = "mdio";
@@ -173,45 +173,6 @@
};
};
 
-   spi {
-   #address-cells = <1>;
-   #size-cells = <1>;
-
-   compatible = "spi-gpio";
-
-   gpio-miso = < 16 0>;
-   gpio-mosi = < 17 0>;
-   gpio-sck = < 18 0>;
-   num-chipselects = <1>;
-   cs-gpios = < 10 1>;
-
-   m25p80@0 {
-   #address-cells = <1>;
-   #size-cells = <1>;
-   compatible = "jedec,spi-nor";
-   reg = <0 0>;
-   spi-max-frequency = <100>;
-
-   ath9k_cal: partition@0 {
-   reg = <0x0 0x2>;
-   label = "urlader";
-   read-only;
-   };
-
-   partition@2 {
-   reg = <0x2 0x1>;
-   label = "tffs (1)";
-   read-only;
-   };
-
-   partition@3 {
-   reg = <0x3 0x1>;
-   label = "tffs (2)";
-   read-only;
-   };
-   };
-   };
-
ath9k_eep {
compatible = "ath9k,eeprom";
ath,eep-flash = <_cal 0x985>;
@@ -276,3 +237,33 @@
};
};
 };
+
+ {
+   status = "ok";
+
+   m25p80@3 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "jedec,spi-nor";
+   reg = <3 0>;
+   spi-max-frequency = <100>;
+
+   ath9k_cal: partition@0 {
+   reg = <0x0 0x2>;
+   label = "urlader";
+   read-only;
+   };
+
+   partition@2 {
+   reg = <0x2 0x1>;
+   label = "tffs (1)";
+   read-only;
+   };
+
+   partition@3 {
+   reg = <0x3 0x1>;
+   label = "tffs (2)";
+   read-only;
+   };
+   };
+};
-- 
2.7.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 04/13] lantiq: Add the SPI node to ar9.dtsi and vr9.dtsi

[Martin Blumenstingl]

This allows devices to use SPI without having to re-define (and thus
duplicating) the whole SPI node.
By default SPI is disabled (as before) because only few devices need it.

Signed-off-by: Martin Blumenstingl <martin.blumensti...@googlemail.com>
---
 target/linux/lantiq/dts/ar9.dtsi | 10 ++
 target/linux/lantiq/dts/vr9.dtsi | 10 ++
 2 files changed, 20 insertions(+)

diff --git a/target/linux/lantiq/dts/ar9.dtsi b/target/linux/lantiq/dts/ar9.dtsi
index f69a7ae..25b8346 100644
--- a/target/linux/lantiq/dts/ar9.dtsi
+++ b/target/linux/lantiq/dts/ar9.dtsi
@@ -100,6 +100,16 @@
status = "disabled";
};
 
+   spi: spi@E100800 {
+   compatible = "lantiq,spi-xway";
+   reg = <0xE100800 0x100>;
+   interrupt-parent = <>;
+   interrupts = <22 23 24>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   status = "disabled";
+   };
+
gpio: pinmux@E100B10 {
compatible = "lantiq,xrx100-pinctrl";
#gpio-cells = <2>;
diff --git a/target/linux/lantiq/dts/vr9.dtsi b/target/linux/lantiq/dts/vr9.dtsi
index 2330bf1..e38541e 100644
--- a/target/linux/lantiq/dts/vr9.dtsi
+++ b/target/linux/lantiq/dts/vr9.dtsi
@@ -112,6 +112,16 @@
status = "disabled";
};
 
+   spi: spi@E100800 {
+   compatible = "lantiq,spi-xway";
+   reg = <0xE100800 0x100>;
+   interrupt-parent = <>;
+   interrupts = <22 23 24>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   status = "disabled";
+   };
+
gpio: pinmux@E100B10 {
compatible = "lantiq,xrx200-pinctrl";
#gpio-cells = <2>;
-- 
2.7.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 09/13] lantiq: Disable CONFIG_SPI_GPIO

[Martin Blumenstingl]

All devices are now using the HW SPI driver, so this is not necessary
anymore.

Signed-off-by: Martin Blumenstingl <martin.blumensti...@googlemail.com>
---
 target/linux/lantiq/xrx200/config-default | 1 -
 target/linux/lantiq/xway/config-default   | 1 -
 2 files changed, 2 deletions(-)

diff --git a/target/linux/lantiq/xrx200/config-default 
b/target/linux/lantiq/xrx200/config-default
index c18ad1f..ece2706 100644
--- a/target/linux/lantiq/xrx200/config-default
+++ b/target/linux/lantiq/xrx200/config-default
@@ -57,7 +57,6 @@ CONFIG_RTL8367B_PHY=y
 CONFIG_RTL8367_PHY=y
 CONFIG_SPI=y
 CONFIG_SPI_BITBANG=y
-CONFIG_SPI_GPIO=y
 CONFIG_SPI_MASTER=y
 CONFIG_SPI_XWAY=y
 CONFIG_SYS_SUPPORTS_MIPS16=y
diff --git a/target/linux/lantiq/xway/config-default 
b/target/linux/lantiq/xway/config-default
index 7334c97..974b06b 100644
--- a/target/linux/lantiq/xway/config-default
+++ b/target/linux/lantiq/xway/config-default
@@ -55,7 +55,6 @@ CONFIG_RTL8367B_PHY=y
 CONFIG_RTL8367_PHY=y
 CONFIG_SPI=y
 CONFIG_SPI_BITBANG=y
-CONFIG_SPI_GPIO=y
 CONFIG_SPI_MASTER=y
 CONFIG_SPI_XWAY=y
 CONFIG_SYS_SUPPORTS_MIPS16=y
-- 
2.7.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 08/13] lantiq: Enable the hardware SPI driver on the DGN3500/DGN3500B

[Martin Blumenstingl]

Signed-off-by: Martin Blumenstingl <martin.blumensti...@googlemail.com>
---
 target/linux/lantiq/dts/DGN3500.dtsi | 91 +++-
 1 file changed, 38 insertions(+), 53 deletions(-)

diff --git a/target/linux/lantiq/dts/DGN3500.dtsi 
b/target/linux/lantiq/dts/DGN3500.dtsi
index bda4006..d43da9d 100644
--- a/target/linux/lantiq/dts/DGN3500.dtsi
+++ b/target/linux/lantiq/dts/DGN3500.dtsi
@@ -45,15 +45,9 @@
lantiq,output = <1>;
lantiq,pull = <0>;
};
-   spi-in {
-   lantiq,pins = "io16";
-   lantiq,open-drain = <1>;
-   lantiq,pull = <2>;
-   };
-   spi-out {
-   lantiq,pins = "io10", "io17", "io18", 
"io21";
-   lantiq,open-drain = <0>;
-   lantiq,pull = <2>;
+   spi {
+   lantiq,groups = "spi", "spi_cs4";
+   lantiq,function = "spi";
};
};
};
@@ -78,50 +72,6 @@
};
};
 
-   spi {
-   #address-cells = <1>;
-   #size-cells = <1>;
-
-   compatible = "spi-gpio";
-
-   gpio-miso = < 16 0>;
-   gpio-mosi = < 17 0>;
-   gpio-sck = < 18 0>;
-   num-chipselects = <1>;
-   cs-gpios = < 10 1>;
-
-   m25p80@0 {
-   #address-cells = <1>;
-   #size-cells = <1>;
-   compatible = "jedec,spi-nor";
-   reg = <0 0>;
-   spi-max-frequency = <100>;
-
-   partition@0 {
-   reg = <0x0 0x1>;
-   label = "uboot";
-   read-only;
-   };
-
-   partition@1 {
-   reg = <0x1 0x1>;
-   label = "uboot-env";
-   read-only;
-   };
-
-   ath9k_cal: partition@2 {
-   reg = <0x2 0x1>;
-   label = "calibration";
-   read-only;
-   };
-
-   partition@5 {
-   reg = <0x5 0xfa>;
-   label = "firmware";
-   };
-   };
-   };
-
ath9k_eep {
compatible = "ath9k,eeprom";
ath,eep-flash = <_cal 0xf000>;
@@ -198,3 +148,38 @@
};
};
 };
+
+ {
+   status = "ok";
+
+   m25p80@3 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "jedec,spi-nor";
+   reg = <3 0>;
+   spi-max-frequency = <100>;
+
+   partition@0 {
+   reg = <0x0 0x1>;
+   label = "uboot";
+   read-only;
+   };
+
+   partition@1 {
+   reg = <0x1 0x1>;
+   label = "uboot-env";
+   read-only;
+   };
+
+   ath9k_cal: partition@2 {
+   reg = <0x2 0x1>;
+   label = "calibration";
+   read-only;
+   };
+
+   partition@5 {
+   reg = <0x5 0xfa>;
+   label = "firmware";
+   };
+   };
+};
-- 
2.7.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 12/13] lantiq: Remove the old SPI driver patch

[Martin Blumenstingl]

Signed-off-by: Martin Blumenstingl <martin.blumensti...@googlemail.com>
---
 .../0033-SPI-MIPS-lantiq-adds-spi-xway.patch   | 1048 
 1 file changed, 1048 deletions(-)
 delete mode 100644 
target/linux/lantiq/patches-4.1/0033-SPI-MIPS-lantiq-adds-spi-xway.patch

diff --git 
a/target/linux/lantiq/patches-4.1/0033-SPI-MIPS-lantiq-adds-spi-xway.patch 
b/target/linux/lantiq/patches-4.1/0033-SPI-MIPS-lantiq-adds-spi-xway.patch
deleted file mode 100644
index 93a2972..000
--- a/target/linux/lantiq/patches-4.1/0033-SPI-MIPS-lantiq-adds-spi-xway.patch
+++ /dev/null
@@ -1,1048 +0,0 @@
-From e75df4f96373e5d16f8ca13aa031e54cdcfeda62 Mon Sep 17 00:00:00 2001
-From: John Crispin <blo...@openwrt.org>
-Date: Wed, 13 Mar 2013 09:29:37 +0100
-Subject: [PATCH 33/36] SPI: MIPS: lantiq: adds spi-xway
-
-This patch adds support for the SPI core found on several Lantiq SoCs.
-The Driver has been runtime tested in combination with m25p80 Flash Devices
-on Amazon_SE and VR9.
-
-Signed-off-by: Daniel Schwierzeck <daniel.schwierz...@googlemail.com>
-Signed-off-by: John Crispin <blo...@openwrt.org>

- drivers/spi/Kconfig|8 +
- drivers/spi/Makefile   |1 +
- drivers/spi/spi-xway.c |  977 
- 3 files changed, 986 insertions(+)
- create mode 100644 drivers/spi/spi-xway.c
-
 a/drivers/spi/Kconfig
-+++ b/drivers/spi/Kconfig
-@@ -626,6 +626,14 @@ config SPI_NUC900
-   help
- SPI driver for Nuvoton NUC900 series ARM SoCs
- 
-+config SPI_XWAY
-+  tristate "Lantiq SPI controller"
-+  depends on LANTIQ
-+  select SPI_BITBANG
-+  help
-+This driver supports the Lantiq SoC SPI controller in master
-+mode.
-+
- #
- # Add new SPI master controllers in alphabetical order above this line
- #
 a/drivers/spi/Makefile
-+++ b/drivers/spi/Makefile
-@@ -90,3 +90,4 @@ obj-$(CONFIG_SPI_TXX9)   += spi-txx9.o
- obj-$(CONFIG_SPI_XCOMM)   += spi-xcomm.o
- obj-$(CONFIG_SPI_XILINX)  += spi-xilinx.o
- obj-$(CONFIG_SPI_XTENSA_XTFPGA)   += spi-xtensa-xtfpga.o
-+obj-$(CONFIG_SPI_XWAY)+= spi-xway.o
 /dev/null
-+++ b/drivers/spi/spi-xway.c
-@@ -0,0 +1,1003 @@
-+/*
-+ * Lantiq SoC SPI controller
-+ *
-+ * Copyright (C) 2011 Daniel Schwierzeck <daniel.schwierz...@googlemail.com>
-+ * Copyright (C) 2012 John Crispin <blo...@openwrt.org>
-+ *
-+ * This program is free software; you can distribute 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 
-+#include 
-+#include 
-+#include 
-+#include 
-+#include 
-+#include 
-+#include 
-+
-+#include 
-+
-+#define LTQ_SPI_CLC   0x00/* Clock control */
-+#define LTQ_SPI_PISEL 0x04/* Port input select */
-+#define LTQ_SPI_ID0x08/* Identification */
-+#define LTQ_SPI_CON   0x10/* Control */
-+#define LTQ_SPI_STAT  0x14/* Status */
-+#define LTQ_SPI_WHBSTATE  0x18/* Write HW modified state */
-+#define LTQ_SPI_TB0x20/* Transmit buffer */
-+#define LTQ_SPI_RB0x24/* Receive buffer */
-+#define LTQ_SPI_RXFCON0x30/* Receive FIFO control */
-+#define LTQ_SPI_TXFCON0x34/* Transmit FIFO control */
-+#define LTQ_SPI_FSTAT 0x38/* FIFO status */
-+#define LTQ_SPI_BRT   0x40/* Baudrate timer */
-+#define LTQ_SPI_BRSTAT0x44/* Baudrate timer status */
-+#define LTQ_SPI_SFCON 0x60/* Serial frame control */
-+#define LTQ_SPI_SFSTAT0x64/* Serial frame status */
-+#define LTQ_SPI_GPOCON0x70/* General purpose output 
control */
-+#define LTQ_SPI_GPOSTAT   0x74/* General purpose output 
status */
-+#define LTQ_SPI_FGPO  0x78/* Forced general purpose output */
-+#define LTQ_SPI_RXREQ 0x80/* Receive request */
-+#define LTQ_SPI_RXCNT 0x84/* Receive count */
-+#define LTQ_SPI_DMACON0xEC/* DMA control */
-+#define LTQ_SPI_IRNEN 0xF4/* Interrupt node enable */
-+#define LTQ_SPI_IRNICR0xF8/* Interrupt node interrupt 
capture */
-+#define LTQ_SPI_IRNCR 0xFC/* Interrupt node control */
-+
-+#define LTQ_SPI_CLC_SMC_SHIFT 16  /* Clock divider for sleep mode */
-+#define LTQ_SPI_CLC_SMC_MASK  0xFF
-+#define LTQ_SPI_CLC_RMC_SHIFT 8   /* Clock divider for normal run mode */
-+#define LTQ_SPI_CLC_RMC_MASK  0xFF
-+#define LTQ_SPI_CLC_DISS  BIT(1)  /* Disable status bit */
-+#define LTQ_SPI_CLC_DISR  BIT(0)  /* Disable request bit */
-+
-+#define LTQ_SPI_ID_TXFS_SHIFT 24  /* Implemented TX FIFO size */
-+#define LTQ_SPI_ID_TXFS

[OpenWrt-Devel] [PATCH 13/13] lantiq: Remove incorrect PCIe compatible strings

[Martin Blumenstingl]

Re-defining the compatible property is not required since the correct
value is inherited from vr9.dtsi.

Signed-off-by: Martin Blumenstingl <martin.blumensti...@googlemail.com>
---
 target/linux/lantiq/dts/ARV7519RW22.dts | 1 -
 target/linux/lantiq/dts/TDW89X0.dtsi| 4 
 2 files changed, 5 deletions(-)

diff --git a/target/linux/lantiq/dts/ARV7519RW22.dts 
b/target/linux/lantiq/dts/ARV7519RW22.dts
index 43d6c6e..dfc7e8f 100644
--- a/target/linux/lantiq/dts/ARV7519RW22.dts
+++ b/target/linux/lantiq/dts/ARV7519RW22.dts
@@ -163,7 +163,6 @@
 
pcie@d90 {
status = "disabled";
-   compatible = "lantiq,pcie-xway";
};
 
pci@E105400 {
diff --git a/target/linux/lantiq/dts/TDW89X0.dtsi 
b/target/linux/lantiq/dts/TDW89X0.dtsi
index eabb980..b7be27e 100644
--- a/target/linux/lantiq/dts/TDW89X0.dtsi
+++ b/target/linux/lantiq/dts/TDW89X0.dtsi
@@ -151,10 +151,6 @@
phys = [ 00 01 ];
};
 
-   pcie {
-   compatible = "lantiq,pcie-xway";
-   };
-
ath9k_eep {
compatible = "ath9k,eeprom";
ath,eep-flash = <_cal 0x21000>;
-- 
2.7.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 10/13] lantiq: Add a rewritten version of the SPI driver

[Martin Blumenstingl]

The new driver provides a few improvements over the old one:
- Separate compatible strings per SoC type (this allows removing some
  hardcoded of_device_is_compatible() checks)
- It does not rely upon spi-bitbang anymore
- chip-selects are numbered as in the datasheet (= starting at 1 instead
  of 0)

Signed-off-by: Martin Blumenstingl <martin.blumensti...@googlemail.com>
---
 ...spi-add-support-for-Lantiq-SPI-controller.patch | 1133 
 1 file changed, 1133 insertions(+)
 create mode 100644 
target/linux/lantiq/patches-4.1/0100-spi-add-support-for-Lantiq-SPI-controller.patch

diff --git 
a/target/linux/lantiq/patches-4.1/0100-spi-add-support-for-Lantiq-SPI-controller.patch
 
b/target/linux/lantiq/patches-4.1/0100-spi-add-support-for-Lantiq-SPI-controller.patch
new file mode 100644
index 000..052b232
--- /dev/null
+++ 
b/target/linux/lantiq/patches-4.1/0100-spi-add-support-for-Lantiq-SPI-controller.patch
@@ -0,0 +1,1133 @@
+From 0175fc559debc22fe8d17e9b8ffd1452e0a4667d Mon Sep 17 00:00:00 2001
+From: Daniel Schwierzeck <daniel.schwierz...@gmail.com>
+Date: Tue, 16 Dec 2014 15:40:32 +0100
+Subject: [PATCH 1/2] spi: add support for Lantiq SPI controller
+
+Signed-off-by: Daniel Schwierzeck <daniel.schwierz...@gmail.com>
+---
+ drivers/spi/Kconfig  |7 +
+ drivers/spi/Makefile |1 +
+ drivers/spi/spi-lantiq.c | 1089 ++
+ 3 files changed, 1097 insertions(+)
+ create mode 100644 drivers/spi/spi-lantiq.c
+
+--- a/drivers/spi/Kconfig
 b/drivers/spi/Kconfig
+@@ -334,6 +334,13 @@ config SPI_MESON_SPIFC
+ This enables master mode support for the SPIFC (SPI flash
+ controller) available in Amlogic Meson SoCs.
+ 
++config SPI_LANTIQ
++  tristate "Lantiq SPI controller"
++  depends on LANTIQ && (SOC_TYPE_XWAY || SOC_FALCON)
++  help
++This driver supports the Lantiq SPI controller in master
++mode.
++
+ config SPI_OC_TINY
+   tristate "OpenCores tiny SPI"
+   depends on GPIOLIB
+--- a/drivers/spi/Makefile
 b/drivers/spi/Makefile
+@@ -44,6 +44,7 @@ obj-$(CONFIG_SPI_GPIO)   += spi-gpio.o
+ obj-$(CONFIG_SPI_GPIO_OLD)+= spi_gpio_old.o
+ obj-$(CONFIG_SPI_IMG_SPFI)+= spi-img-spfi.o
+ obj-$(CONFIG_SPI_IMX) += spi-imx.o
++obj-$(CONFIG_SPI_LANTIQ)  += spi-lantiq.o
+ obj-$(CONFIG_SPI_LM70_LLP)+= spi-lm70llp.o
+ obj-$(CONFIG_SPI_MESON_SPIFC) += spi-meson-spifc.o
+ obj-$(CONFIG_SPI_MPC512x_PSC) += spi-mpc512x-psc.o
+--- /dev/null
 b/drivers/spi/spi-lantiq.c
+@@ -0,0 +1,1091 @@
++/*
++ * Copyright (C) 2011-2015 Daniel Schwierzeck <daniel.schwierz...@gmail.com>
++ *
++ * This program is free software; you can distribute 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 
++#include 
++#include 
++#include 
++#include 
++#include 
++
++#include 
++
++#define SPI_RX_IRQ_NAME   "spi_rx"
++#define SPI_TX_IRQ_NAME   "spi_tx"
++#define SPI_ERR_IRQ_NAME  "spi_err"
++#define SPI_FRM_IRQ_NAME  "spi_frm"
++
++#define SPI_CLC   0x00
++#define SPI_PISEL 0x04
++#define SPI_ID0x08
++#define SPI_CON   0x10
++#define SPI_STAT  0x14
++#define SPI_WHBSTATE  0x18
++#define SPI_TB0x20
++#define SPI_RB0x24
++#define SPI_RXFCON0x30
++#define SPI_TXFCON0x34
++#define SPI_FSTAT 0x38
++#define SPI_BRT   0x40
++#define SPI_BRSTAT0x44
++#define SPI_SFCON 0x60
++#define SPI_SFSTAT0x64
++#define SPI_GPOCON0x70
++#define SPI_GPOSTAT   0x74
++#define SPI_FPGO  0x78
++#define SPI_RXREQ 0x80
++#define SPI_RXCNT 0x84
++#define SPI_DMACON0xec
++#define SPI_IRNEN 0xf4
++#define SPI_IRNICR0xf8
++#define SPI_IRNCR 0xfc
++
++#define SPI_CLC_SMC_S 16  /* Clock divider for sleep mode */
++#define SPI_CLC_SMC_M (0xFF << SPI_CLC_SMC_S)
++#define SPI_CLC_RMC_S 8   /* Clock divider for normal run mode */
++#define SPI_CLC_RMC_M (0xFF << SPI_CLC_RMC_S)
++#define SPI_CLC_DISS  BIT(1)  /* Disable status bit */
++#define SPI_CLC_DISR  BIT(0)  /* Disable request bit */
++
++#define SPI_ID_TXFS_S 24  /* Implemented TX FIFO size */
++#define SPI_ID_TXFS_M (0x3F << SPI_ID_TXFS_S)
++#define SPI_ID_RXFS_S 16  /* Implemented RX FIFO size */
++#define SPI_ID_RXFS_M (0x3F << SPI_ID_

[OpenWrt-Devel] [PATCH 11/13] lantiq: Switch to the new SPI driver

[Martin Blumenstingl]

Compared to the "old" driver:
- Each device must assign a pinctrl setting to the SPI node to allow the
  new SPI driver to configure the SPI pins.
  While here we are also using separate input and output settings so we
  are independent of whether the bootloader configures the pins correctly.
- We use the new "compatible" strings to make the driver choose the
  correct number of chip-selects for each SoC.
- The new driver starts counting the chip-selects at 1 (instead of 0, like
  the old one did). Thus we have to adjust the devices accordingly.

Signed-off-by: Martin Blumenstingl <martin.blumensti...@googlemail.com>
---
 target/linux/lantiq/dts/DGN1000B.dts  | 23 +--
 target/linux/lantiq/dts/DGN3500.dtsi  | 19 +++
 target/linux/lantiq/dts/EASY80920.dtsi| 23 +--
 target/linux/lantiq/dts/FRITZ3370.dts | 23 +--
 target/linux/lantiq/dts/TDW89X0.dtsi  | 23 +--
 target/linux/lantiq/dts/amazonse.dtsi |  4 +++-
 target/linux/lantiq/dts/ar9.dtsi  |  4 +++-
 target/linux/lantiq/dts/vr9.dtsi  |  4 +++-
 target/linux/lantiq/xrx200/config-default |  3 +--
 target/linux/lantiq/xway/config-default   |  3 +--
 10 files changed, 94 insertions(+), 35 deletions(-)

diff --git a/target/linux/lantiq/dts/DGN1000B.dts 
b/target/linux/lantiq/dts/DGN1000B.dts
index a6bd5a8..68415ca 100644
--- a/target/linux/lantiq/dts/DGN1000B.dts
+++ b/target/linux/lantiq/dts/DGN1000B.dts
@@ -28,10 +28,6 @@
pinctrl-0 = <_default>;
 
state_default: pinmux {
-   spi {
-   lantiq,groups = "spi", "spi_cs1";
-   lantiq,function = "spi";
-   };
asc {
lantiq,groups = "asc";
lantiq,function = "asc";
@@ -42,6 +38,18 @@
lantiq,open-drain = <1>;
};
};
+   pins_spi_default: pins_spi_default {
+   spi_in {
+   lantiq,groups = "spi_di";
+   lantiq,function = "spi";
+   };
+   spi_out {
+   lantiq,groups = "spi_do", "spi_clk",
+   "spi_cs1";
+   lantiq,function = "spi";
+   lantiq,output = <1>;
+   };
+   };
};
 
etop@E18 {
@@ -50,11 +58,14 @@
};
 
spi@E100800 {
-   m25p80@0 {
+   pinctrl-names = "default";
+   pinctrl-0 = <_spi_default>;
+
+   m25p80@1 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "jedec,spi-nor";
-   reg = <0 0>;
+   reg = <1 0>;
spi-max-frequency = <500>;
 
partition@0 {
diff --git a/target/linux/lantiq/dts/DGN3500.dtsi 
b/target/linux/lantiq/dts/DGN3500.dtsi
index d43da9d..48e2471e4 100644
--- a/target/linux/lantiq/dts/DGN3500.dtsi
+++ b/target/linux/lantiq/dts/DGN3500.dtsi
@@ -45,10 +45,18 @@
lantiq,output = <1>;
lantiq,pull = <0>;
};
-   spi {
-   lantiq,groups = "spi", "spi_cs4";
+   };
+   pins_spi_default: pins_spi_default {
+   spi_in {
+   lantiq,groups = "spi_di";
lantiq,function = "spi";
};
+   spi_out {
+   lantiq,groups = "spi_do", "spi_clk",
+   "spi_cs4";
+   lantiq,function = "spi";
+   lantiq,output = <1>;
+   };
};
};
 
@@ -150,13 +158,16 @@
 };
 
  {
+   pinctrl-names = &quo

Re: [OpenWrt-Devel] lantiq: Initial linux 4.4 support (with SPI problems)

[Martin Blumenstingl]

On Sat, Jan 16, 2016 at 10:48 PM, Daniel Schwierzeck
<daniel.schwierz...@gmail.com> wrote:
> Am Samstag, den 16.01.2016, 21:17 +0100 schrieb Martin Blumenstingl:
>
>> So compared to your patch the final list of changes is:
>> - INIT_COMPLETION -> reinit_completion
>> - use clk_get_fpi()
>> - of_device_id for "lantiq,spi-xrx100"
>>
>> I only have three small questions left:
>> - The "spi_frm" interrupt is currently unused - is that on purpose?
>
> yes, this interrupt is only needed for DMA transfers.
ok, thanks!

>> - I went ahead and added multiple "compatible" strings to the
>> soc.dtsi, for example: compatible = "lantiq,spi-ase",
>> "lantiq,spi-xway"; - do you see any problems with that?
>
> there should be only one compatible string in the DTS. For backward
> compatibility the driver could support old and new strings.
I have fixed this, see below

>> Please let me know if you have more feedback - otherwise I'll do the
>> final round of tests and send the patches later.
>
> AFAIK the upstream preference is to have "lantiq,-spi". I forgot
> to fix that in the driver. Could you change that? Thanks.
The new of_device_id table is now:
 { .compatible = "lantiq,spi-xway", .data = _xway, }, /* DEPRECATED */
 { .compatible = "lantiq,ase-spi", .data = _xway, },
 { .compatible = "lantiq,xrx100-spi", .data = _xrx, },
 { .compatible = "lantiq,xrx200-spi", .data = _xrx, },
 { .compatible = "lantiq,xrx330-spi", .data = _xrx, },

This way we are still backwards compatible but have dedicated entries per SoC.
I could not find a danube device with SPI so I skipped that property for now.

While testing the changes I found that PCIe (and thus wifi) stopped
working on my TD-W8970. This was due to the backported pinctrl patches
which only add 50 pins for XRX200 instead of 56 (as before). That
changed the kernel-internal GPIO numbering, the first GPIO now starts
at 462. And since the PCIe driver used hardcoded GPIO numbers it broke
(because it failed to reset the PCIe device).
To make a long story short: I wrote a patch which fixes this - I'll
send the whole series in a few minutes.


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

[OpenWrt-Devel] [PATCH] lantiq: Fixed brnImage signature for the VGV7510KW22BRN images

[Martin Blumenstingl]

The old signature only worked because brnboot ignores the leading "5" in
the signature. We can see the correct signature when flashing a brnImage
via recovery web-interface, in this case brnboot reports:
[CGI-Signature Check] buf:[BRNDA6431], sigInFlash:[BRNDA6431]

Thanks to Mathias Kresin for reporting this.

Signed-off-by: Martin Blumenstingl <martin.blumensti...@googlemail.com>
---
 target/linux/lantiq/image/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/linux/lantiq/image/Makefile 
b/target/linux/lantiq/image/Makefile
index 553bdc1..f986d38 100644
--- a/target/linux/lantiq/image/Makefile
+++ b/target/linux/lantiq/image/Makefile
@@ -417,7 +417,7 @@ Image/BuildKernel/Profile/VGV7510KW22NOR=$(call 
Image/BuildKernel/Template,VGV75
 Image/Build/Profile/VGV7510KW22NOR=$(call Image/Build/$(1),$(1),VGV7510KW22NOR)
 
 Image/BuildKernel/Profile/VGV7510KW22BRN=$(call 
Image/BuildKernel/Template,VGV7510KW22BRN,$(1))
-Image/Build/Profile/VGV7510KW22BRN=$(call 
Image/Build/$(1),$(1),VGV7510KW22BRN,5BRNDA6431,0x12345678,0x04c11db7,$(1))
+Image/Build/Profile/VGV7510KW22BRN=$(call 
Image/Build/$(1),$(1),VGV7510KW22BRN,BRNDA6431,0x12345678,0x04c11db7,$(1))
 
 Image/BuildKernel/Profile/VGV7519NOR=$(call 
Image/BuildKernel/Template,VGV7519NOR,$(1))
 Image/Build/Profile/VGV7519NOR=$(call Image/Build/$(1),$(1),VGV7519NOR)
-- 
2.7.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] lantiq: Initial linux 4.4 support (with SPI problems)

[Martin Blumenstingl]

Hi Daniel,

On Sat, Jan 16, 2016 at 1:06 AM, Martin Blumenstingl
<martin.blumensti...@googlemail.com> wrote:
>> It is a complete rewrite with DT support and runs against the UGW-6.1.1
>> kernel. Unfortunately I hadn't time yet to adapt and test it with
>> OpenWRT. Maybe you want to volunteer for that ;)
> Thanks for this update! I am going to test it on kernel 4.1 in the
> next days and let you know about the results.
I had to make 3 adjustments to get it working on OpenWrt:
- replace INIT_COMPLECTION with reinit_completion (this is due the
newer kernel version in OpenWrt)
- use clk_get_fpi() to obtain the FPI clock (horrible, I am currently
porting the lantiq clock code to the common clk framework, then we can
pass this in correctly)
- remove the " - 1" in "cs - 1" (it seems that your chipselect
indexing in the .dts begins at 1, whereas the previous driver started
at 0)

After that everything is working nicely on linux 4.1 (on my TD-W8970):
[0.926597] spi-lantiq 1e100800.spi: using internal chipselect 3
[0.931499] spi-lantiq 1e100800.spi: spi_clk 12500,
max_speed_hz 3325, brt 2
[0.939351] m25p80 spi0.3: s25fl064k (8192 Kbytes)
[0.943763] 4 ofpart partitions found on MTD device spi0.3
[0.949192] Creating 4 MTD partitions on "spi0.3":
[0.953984] 0x-0x0002 : "u-boot"
[0.960136] 0x0002-0x007c : "firmware"
[0.966720] 0x001cf40c-0x007c : "rootfs"
[0.971380] mtd: device 2 (rootfs) set to be root filesystem
[0.976814] 1 squashfs-split partitions found on MTD device rootfs
[0.982126] 0x0046-0x007c : "rootfs_data"
[1.030051] 0x007c-0x007d : "config"
[1.034667] 0x007d-0x0080 : "boardconfig"
[1.040154] spi-lantiq 1e100800.spi: Lantiq SPI controller (TXFS 8,
RXFS 8, DMA 32)

I have pushed my changes to the OpenWrt tree here: [0]
My plan is to finish them soon (I want to do a little more testing,
and I need to verify that my other dts changes are correct).

Thank you for your help!


Regards,
Martin

[0] https://github.com/xdarklight/openwrt/commits/lantiq-spi-driver-daniel-v2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] lantiq: Initial linux 4.4 support (with SPI problems)

[Martin Blumenstingl]

On Sat, Jan 16, 2016 at 4:34 PM, Daniel Schwierzeck
 wrote:
> nice, thanks for testing :)
Thanks for writing nice patches ;-)

>> - replace INIT_COMPLECTION with reinit_completion (this is due the
>> newer kernel version in OpenWrt)
>> - use clk_get_fpi() to obtain the FPI clock (horrible, I am currently
>> porting the lantiq clock code to the common clk framework, then we
>> can
>> pass this in correctly)
>> - remove the " - 1" in "cs - 1" (it seems that your chipselect
>> indexing in the .dts begins at 1, whereas the previous driver started
>> at 0)
>
> I fixed that because datasheets and pin descriptions in schematics use
> CS1..CS6. I think DT should be in sync to the datasheets.
I am not sure if this would work with GPIO chipselects then, see [0].
If I understand it correctly then you would have to change the "reg"
property of each device to "0" if you would use GPIO CS0 and then back
to "1" if you want to use hardware CS0.
Let me know if we should still go with chipselects starting at 1, then
I will simply adjust them in the commit which switches to your new SPI
driver.

> linux-4.4 finally has the patch [1] I was referring to. Maybe we should
> also add it to 4.1. It is important to be able to setup each SPI pin
> separately. You always should explicitely setup spi_clk and spi_do to
> "lantiq,output = <1>" and spi_di to "lantiq,input". Depending on the
> board, you optionally have to enable internal pull-up's, if there are
> no external ones. The current DT pinmux setup with only one spi pin
> group relies on the bootloader setup. This only works if the board
> boots from SPI and the bootloader have to setup the SPI pins. With
> other boot variants the SPI pins are likely not setup.
I am assuming that you are speaking of upstream commit
be14811c03cf20c793fd176a347625335110b0e6.
I went ahead and also backported that to 4.1, you can find the updated
patchset here: [1]

While reviewing my changes I may have found a small problem with your driver:
You don't have a separate "lantiq,spi-xrx100" OF-match. I think you
should add one with the same settings as for the other xrx-SoCs.
If you look at DGN3500.dtsi [2] you'll see that it's an ARX100 board
using spi_cs4.


Martin

[0] https://www.kernel.org/doc/Documentation/devicetree/bindings/spi/spi-bus.txt
[1] https://github.com/xdarklight/openwrt/commits/lantiq-spi-driver-daniel-v3
[2] https://dev.openwrt.org/browser/trunk/target/linux/lantiq/dts/DGN3500.dtsi
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 0/5] update at91 kernel to 4.1

[Martin Blumenstingl]

Hi Ben,

On Sat, Jan 16, 2016 at 6:00 PM, Ben Whitten  wrote:
> This patch series adds support for kernel 4.1 to the at91 target.
> Patches for legacy boards are dropped as the platform has been converted
> to DT in 4.1.
Do you have plans for updating at91 to linux 4.4?
As far as I know the DD (trunk) release will be based on linux 4.4
(which is the latest LTS kernel).
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel