Re: [OpenWrt-Devel] [PATCH] gpio-button-hotplug: gpio-keys: read initial state
On Sun, Jun 16, 2019 at 4:31 PM David Bauer wrote:
> It seems the input is indeed not stable after setting the GPIO
> direction. With the following patch applied, i get zero ghost presses
> and the buttons work as expected. However I'm not sure if this approach
> is the right one to fix the underlying issue.
It shows what the problem is for sure. delays are forbidden in
irqchip callback functions since they are all called from
IRQ context with IRQs disabled though.
> @@ -96,6 +97,12 @@ static void ath79_gpio_irq_enable(struct irq_data *data)
> u32 mask = BIT(irqd_to_hwirq(data));
> unsigned long flags;
>
> + /*
> +* The input can be unstable after configuring GPIO direction.
> +* Wait a bit to assert the input is stable.
> +*/
> + msleep(25);
> +
> raw_spin_lock_irqsave(>lock, flags);
> ath79_gpio_update_bits(ctrl, AR71XX_GPIO_REG_INT_ENABLE, mask, mask);
> ath79_gpio_update_bits(ctrl, AR71XX_GPIO_REG_INT_MASK, mask, mask);
After this and before the raw_spin_unlock() try to read the status
register until it
eads zero for the requested IRQ:
while (ath79_gpio_read(ctrl, AR71XX_GPIO_REG_INT_PENDING) & mask) {}
This way we wait for the status to go low before we allow any IRQs to
fire after enableing.
Maybe not so good since we may want to turn on IRQs that are asserted
at some point, but worth a try.
Yours,
Linus Walleij
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] ARM: dts: gemini Fix up DNS-313 compatible string
It's a simple typo in the DNS file, which was pretty serious.
No scripts were working properly. Fix it up.
Signed-off-by: Linus Walleij
---
arch/arm/boot/dts/gemini-dlink-dns-313.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/gemini-dlink-dns-313.dts
b/arch/arm/boot/dts/gemini-dlink-dns-313.dts
index b12504e10f0b..360642a02a48 100644
--- a/arch/arm/boot/dts/gemini-dlink-dns-313.dts
+++ b/arch/arm/boot/dts/gemini-dlink-dns-313.dts
@@ -11,7 +11,7 @@
/ {
model = "D-Link DNS-313 1-Bay Network Storage Enclosure";
- compatible = "dlink,dir-313", "cortina,gemini";
+ compatible = "dlink,dns-313", "cortina,gemini";
#address-cells = <1>;
#size-cells = <1>;
--
2.21.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] phytool: add phytool utility
Hi Christian, On 16.06.2019 20:50, Christian Lamparter wrote: Hello Piotr, On Sun, Jun 16, 2019 at 7:08 PM Piotr Dymacz wrote: Hi Christian, On 16.06.2019 13:56, Christian Lamparter wrote: > From the README.md: > > phytool is a Linux MDIO register access utility. Is there any reason to keep it inside the main code base rather than in packages feed? K, I rejected it on patchwork. Just a side note here. During the meetup in Hamburg we discussed about having only the required and actually "basic" packages inside the master tree and move everything else to packages feed (after reviewing what's there). I believe this will be also included in the official summary from the meetup and discussed further afterwards. -- Cheers, Piotr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [sdwalker/sdwalker.github.io] 413a1f: This week's update
Branch: refs/heads/master Home: https://github.com/sdwalker/sdwalker.github.io Commit: 413a1fe72fb176c718b887612db8174684d1038a https://github.com/sdwalker/sdwalker.github.io/commit/413a1fe72fb176c718b887612db8174684d1038a Author: Stephen Walker Date: 2019-06-16 (Sun, 16 Jun 2019) Changed paths: M uscan/index-18.06.html M uscan/index.html Log Message: --- This week's update ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] phytool: add phytool utility
Hi Christian, On 16.06.2019 13:56, Christian Lamparter wrote: From the README.md: phytool is a Linux MDIO register access utility. Is there any reason to keep it inside the main code base rather than in packages feed? -- Cheers, Piotr Usage: phytool read IFACE/ADDR/REG phytool write IFACE/ADDR/REG <0-0x> phytool print IFACE/ADDR[/REG] where ADDR := C22 | C45 C22 := <0-0x1f> C45 := <0-0x1f>:<0-0x1f> REG := <0-0x1f> Note: Not all MDIO drivers support the port:device Clause 45 address format. The read and write commands are simple register level accessors. The print command will pretty-print a register. When using the print command, the register is optional. If left out, the most common registers will be shown. Signed-off-by: Christian Lamparter --- package/network/utils/phytool/Makefile | 46 ++ 1 file changed, 46 insertions(+) create mode 100644 package/network/utils/phytool/Makefile diff --git a/package/network/utils/phytool/Makefile b/package/network/utils/phytool/Makefile new file mode 100644 index 00..b971c1ad13 --- /dev/null +++ b/package/network/utils/phytool/Makefile @@ -0,0 +1,46 @@ +include $(TOPDIR)/rules.mk + +PKG_NAME:=phytool +PKG_VERSION:=2 +PKG_RELEASE:=1 + +PKG_RELEASE=$(PKG_SOURCE_VERSION) + +PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz +PKG_SOURCE_URL:=https://github.com/wkz/phytool/releases/download/v$(PKG_VERSION) +PKG_HASH:=9901a14e8c6af02b7333c60b21ff81f50620e8326d54827185e5617ff9b11d21 + +PKG_LICENSE:=GPL-2.0+ +PKG_LICENSE_FILES:=LICENSE + +PKG_MAINTAINER:=Christian Lamparter + +include $(INCLUDE_DIR)/package.mk + +define Package/phytool + SECTION:=net + CATEGORY:=Utilities + TITLE:=phytool Linux MDIO register access + URL:=https://github.com/wkz/phytool.git +endef + +define Package/phytool/description + Linux MDIO register access +endef + +define Build/Configure +endef + +define Build/Compile + $(MAKE) -C $(PKG_BUILD_DIR) \ + CC="$(TARGET_CC)" \ + CFLAGS="$(TARGET_CFLAGS) -Wall" \ + LDFLAGS="$(TARGET_LDFLAGS)" +endef + +define Package/phytool/install + $(INSTALL_DIR) $(1)/usr/bin + $(INSTALL_BIN) $(PKG_BUILD_DIR)/phytool $(1)/usr/bin/ +endef + +$(eval $(call BuildPackage,phytool)) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [fstools PATCH: 3/4] libblkid-tiny: adds blkid_probe_set_utf8label support
Currently set_utf8label support is missing. Adds a stripped down version of
encode.c file from original libblkid and adds the function to libblkid-tiny.c.
Signed-off-by: Ansuel Smith
---
CMakeLists.txt| 1 +
libblkid-tiny/encode.c| 66 +++
libblkid-tiny/encode.h| 11 ++
libblkid-tiny/libblkid-tiny.c | 15
4 files changed, 93 insertions(+)
create mode 100644 libblkid-tiny/encode.c
create mode 100644 libblkid-tiny/encode.h
diff --git a/CMakeLists.txt b/CMakeLists.txt
index f86a4d5..7f13c4f 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -19,6 +19,7 @@ TARGET_LINK_LIBRARIES(fstools ubox)
INSTALL(TARGETS fstools LIBRARY DESTINATION lib)
ADD_LIBRARY(blkid-tiny SHARED
+ libblkid-tiny/encode.c
libblkid-tiny/libblkid-tiny.c
libblkid-tiny/mkdev.c
libblkid-tiny/ext.c
diff --git a/libblkid-tiny/encode.c b/libblkid-tiny/encode.c
new file mode 100644
index 000..4d8343e
--- /dev/null
+++ b/libblkid-tiny/encode.c
@@ -0,0 +1,66 @@
+/*
+ * encode.c - string conversion routines (mostly for compatibility with
+ *udev/volume_id)
+ *
+ * Copyright (C) 2008 Kay Sievers
+ * Copyright (C) 2009 Karel Zak
+ *
+ * This file may be redistributed under the terms of the
+ * GNU Lesser General Public License.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "encode.h"
+
+size_t blkid_encode_to_utf8(int enc, unsigned char *dest, size_t len,
+ const unsigned char *src, size_t count)
+{
+ size_t i, j;
+ uint16_t c;
+
+ for (j = i = 0; i < count; i++) {
+ if (enc == BLKID_ENC_UTF16LE) {
+ if (i+2 > count)
+ break;
+ c = (src[i+1] << 8) | src[i];
+ i++;
+ } else if (enc == BLKID_ENC_UTF16BE) {
+ if (i+2 > count)
+ break;
+ c = (src[i] << 8) | src[i+1];
+ i++;
+ } else if (enc == BLKID_ENC_LATIN1) {
+ c = src[i];
+ } else {
+ return 0;
+ }
+ if (c == 0) {
+ dest[j] = '\0';
+ break;
+ } else if (c < 0x80) {
+ if (j+1 >= len)
+ break;
+ dest[j++] = (uint8_t) c;
+ } else if (c < 0x800) {
+ if (j+2 >= len)
+ break;
+ dest[j++] = (uint8_t) (0xc0 | (c >> 6));
+ dest[j++] = (uint8_t) (0x80 | (c & 0x3f));
+ } else {
+ if (j+3 >= len)
+ break;
+ dest[j++] = (uint8_t) (0xe0 | (c >> 12));
+ dest[j++] = (uint8_t) (0x80 | ((c >> 6) & 0x3f));
+ dest[j++] = (uint8_t) (0x80 | (c & 0x3f));
+ }
+ }
+ dest[j] = '\0';
+ return j;
+}
\ No newline at end of file
diff --git a/libblkid-tiny/encode.h b/libblkid-tiny/encode.h
new file mode 100644
index 000..92fcc21
--- /dev/null
+++ b/libblkid-tiny/encode.h
@@ -0,0 +1,11 @@
+#ifndef _ENCODE_H
+#define _ENCODE_H
+
+#define BLKID_ENC_UTF16BE 0
+#define BLKID_ENC_UTF16LE 1
+#define BLKID_ENC_LATIN1 2
+
+size_t blkid_encode_to_utf8(int enc, unsigned char *dest, size_t len,
+ const unsigned char *src, size_t count);
+
+#endif /* _ENCODE_H */
\ No newline at end of file
diff --git a/libblkid-tiny/libblkid-tiny.c b/libblkid-tiny/libblkid-tiny.c
index f020e23..a30f619 100644
--- a/libblkid-tiny/libblkid-tiny.c
+++ b/libblkid-tiny/libblkid-tiny.c
@@ -121,6 +121,21 @@ int blkid_probe_set_label(blkid_probe pr, unsigned char
*label, size_t len)
return 0;
}
+int blkid_probe_set_utf8label(blkid_probe pr, unsigned char *label,
+ size_t len, int enc)
+{
+ if (len > (sizeof(pr->label) - 1)) {
+ fprintf(stderr, "label buffer too small %d > %d\n",
+ (int) len, (int) sizeof(pr->label) - 1);
+ return -1;
+ }
+
+ blkid_encode_to_utf8(enc,(unsigned char*) pr->label, len,
+ label, len+1);
+
+ return 0;
+}
+
int blkid_probe_set_uuid_as(blkid_probe pr, unsigned char *uuid, const char
*name)
{
short unsigned int*u = (short unsigned int*) uuid;
--
2.20.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [fstools PATCH: 1/4] libblkid-tiny: fix wrong btrfs label length
Btrfs label length is 256 included the termination char ( '\0' ) as the real max length is 255 (less than 256 from the wiki). Signed-off-by: Ansuel Smith --- libblkid-tiny/btrfs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libblkid-tiny/btrfs.c b/libblkid-tiny/btrfs.c index 7ce3dff..cf33db5 100644 --- a/libblkid-tiny/btrfs.c +++ b/libblkid-tiny/btrfs.c @@ -70,7 +70,7 @@ static int probe_btrfs(blkid_probe pr, const struct blkid_idmag *mag) if (*bfs->label) blkid_probe_set_label(pr, (unsigned char *) bfs->label, - sizeof(bfs->label)); + sizeof(bfs->label) - 1); blkid_probe_set_uuid(pr, bfs->fsid); blkid_probe_set_uuid_as(pr, bfs->dev_item.uuid, "UUID_SUB"); -- 2.20.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [fstools PATCH: 2/4] libblkid-tiny: increment label size to 256
Btrfs max label lenght is 255. Increment the blkid_struct_probe struct to respect this new max value. Signed-off-by: Ansuel Smith --- libblkid-tiny/libblkid-tiny.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libblkid-tiny/libblkid-tiny.h b/libblkid-tiny/libblkid-tiny.h index 193d926..419d5db 100644 --- a/libblkid-tiny/libblkid-tiny.h +++ b/libblkid-tiny/libblkid-tiny.h @@ -56,7 +56,7 @@ struct blkid_struct_probe int err; chardev[32]; charuuid[64]; - charlabel[64]; + charlabel[256]; charversion[64]; }; -- 2.20.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] phytool: add phytool utility
Hi Christan, > phytool is a Linux MDIO register access utility. thank you. I've looked from time to time for such utility when debugging network drivers & phys. Acked-By: Alexander Couzens Best, lynxis pgpLAsyY5y4fg.pgp Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 1/1] ipq40xx: Linksys: sysupgrade: Ensure OEM volumes are removed
On 6/16/19 4:49 AM, Christian Lamparter wrote: On Saturday, June 15, 2019 11:40:56 PM CEST Jeff Kletsky wrote: From: Jeff Kletsky When OEM volumes are present in the [alt_]firmware partition, sysupgrade will write a new kernel, but will fail to write the root file system. The next boot will hang indefinitely Waiting for root device /dev/ubiblock0_0... Modified ipq40xx/base-files/lib/upgrade/linksys.sh to remove both `squashfs` and `ubifs` if found on the target firmware partition's UBI device. Run-tested-on: Linksys EA8300 Signed-off-by: Jeff Kletsky Can you check if this is still working? Or if I broke it when I was implementing the shellcheck changes? https://git.openwrt.org/?p=openwrt/staging/chunkeey.git;a=commit;h=003c63f7b1102702fb4a0580683b21ded1ee1a3e Cheers, Christian [...] With the caveat that I don't know how to exercise the [ "$magic_long" = "27051956" ] branch of the code[1], your referenced commit from staging/chunkeey is able to sysupgrade my ipq4019-based EA8300 both over OpenWrt as well as over OEM. I have also spot-checked the "missing boot_part" path. Thanks for the quick review of the changes as well as the clean-up of existing code. Jeff --- [1] EA8300 "factory" images don't match the "other" branch $ hexdump -C -n 128 ~/devel/ea8300/FW_EA8300_1.1.4.191539_prod.img d0 0d fe ed 00 27 72 7c 00 00 00 38 00 27 6e a8 |.'r|...8.'n.| 0010 00 00 00 28 00 00 00 11 00 00 00 10 00 00 00 00 |...(| 0020 00 00 00 6c 00 27 6e 70 00 00 00 00 00 00 00 00 |...l.'np| 0030 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 || 0040 00 00 00 03 00 00 00 04 00 00 00 5c 5b d0 bf b0 |...\[...| 0050 00 00 00 03 00 00 00 27 00 00 00 00 41 52 4d 20 |...'ARM | 0060 4c 69 6e 6b 73 79 73 20 46 49 54 20 28 46 6c 61 |Linksys FIT (Fla| 0070 74 74 65 6e 65 64 20 49 6d 61 67 65 20 54 72 65 |ttened Image Tre| 0080 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] gpio-button-hotplug: gpio-keys: read initial state
Hello Linus, On 15.06.19 10:26, Linus Walleij wrote: > Without any detailed knowledge I'd say the most common cause > is the underlying GPIO chip implementation. There are often transient > line events when the system is powered up and initialized and it > is often necessary for the gpio_chip driver to clear any interrupt > flags in hardware before setting up the gpio chip, especially the > irqchip portions of it. > > I tried to half-guess what gpio chip this is using and since it > is WiFi pro 1200e I guess ths gpio driver is > drivers/gpio-ath79.c which does indeed initialize an > irqchip without clearing the interrupts first. > > Can you try this patch, if this solves the problem I will commit > it upstream as well: Thanks for your patch. I've tested it on my device but sadly, i still see the ghost presses. It seems the input is indeed not stable after setting the GPIO direction. With the following patch applied, i get zero ghost presses and the buttons work as expected. However I'm not sure if this approach is the right one to fix the underlying issue. >From 2b0c12c9c9aa1955a1fa42234597601148bcf548 Mon Sep 17 00:00:00 2001 From: David Bauer Date: Sun, 16 Jun 2019 16:20:49 +0200 Subject: [PATCH] gpio: ath79: circumvent ghost interrupts The ath79 gpio driver may emit "ghost interrupts" in case the interrupts are registered directly after setting the GPIO direction. This patch adds a short delay before activating interrupts on any line to make sure no ghost interrupts will be registered. Signed-off-by: David Bauer --- drivers/gpio/gpio-ath79.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/gpio/gpio-ath79.c b/drivers/gpio/gpio-ath79.c index 0a553d676042..238f5bdbe7a8 100644 --- a/drivers/gpio/gpio-ath79.c +++ b/drivers/gpio/gpio-ath79.c @@ -12,6 +12,7 @@ */ #include +#include #include #include #include @@ -96,6 +97,12 @@ static void ath79_gpio_irq_enable(struct irq_data *data) u32 mask = BIT(irqd_to_hwirq(data)); unsigned long flags; + /* +* The input can be unstable after configuring GPIO direction. +* Wait a bit to assert the input is stable. +*/ + msleep(25); + raw_spin_lock_irqsave(>lock, flags); ath79_gpio_update_bits(ctrl, AR71XX_GPIO_REG_INT_ENABLE, mask, mask); ath79_gpio_update_bits(ctrl, AR71XX_GPIO_REG_INT_MASK, mask, mask); -- 2.22.0 Best wishes David ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] phytool: add phytool utility
>From the README.md: phytool is a Linux MDIO register access utility. Usage: phytool read IFACE/ADDR/REG phytool write IFACE/ADDR/REG <0-0x> phytool print IFACE/ADDR[/REG] where ADDR := C22 | C45 C22 := <0-0x1f> C45 := <0-0x1f>:<0-0x1f> REG := <0-0x1f> Note: Not all MDIO drivers support the port:device Clause 45 address format. The read and write commands are simple register level accessors. The print command will pretty-print a register. When using the print command, the register is optional. If left out, the most common registers will be shown. Signed-off-by: Christian Lamparter --- package/network/utils/phytool/Makefile | 46 ++ 1 file changed, 46 insertions(+) create mode 100644 package/network/utils/phytool/Makefile diff --git a/package/network/utils/phytool/Makefile b/package/network/utils/phytool/Makefile new file mode 100644 index 00..b971c1ad13 --- /dev/null +++ b/package/network/utils/phytool/Makefile @@ -0,0 +1,46 @@ +include $(TOPDIR)/rules.mk + +PKG_NAME:=phytool +PKG_VERSION:=2 +PKG_RELEASE:=1 + +PKG_RELEASE=$(PKG_SOURCE_VERSION) + +PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz +PKG_SOURCE_URL:=https://github.com/wkz/phytool/releases/download/v$(PKG_VERSION) +PKG_HASH:=9901a14e8c6af02b7333c60b21ff81f50620e8326d54827185e5617ff9b11d21 + +PKG_LICENSE:=GPL-2.0+ +PKG_LICENSE_FILES:=LICENSE + +PKG_MAINTAINER:=Christian Lamparter + +include $(INCLUDE_DIR)/package.mk + +define Package/phytool + SECTION:=net + CATEGORY:=Utilities + TITLE:=phytool Linux MDIO register access + URL:=https://github.com/wkz/phytool.git +endef + +define Package/phytool/description + Linux MDIO register access +endef + +define Build/Configure +endef + +define Build/Compile + $(MAKE) -C $(PKG_BUILD_DIR) \ + CC="$(TARGET_CC)" \ + CFLAGS="$(TARGET_CFLAGS) -Wall" \ + LDFLAGS="$(TARGET_LDFLAGS)" +endef + +define Package/phytool/install + $(INSTALL_DIR) $(1)/usr/bin + $(INSTALL_BIN) $(PKG_BUILD_DIR)/phytool $(1)/usr/bin/ +endef + +$(eval $(call BuildPackage,phytool)) -- 2.20.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 1/1] ipq40xx: Linksys: sysupgrade: Ensure OEM volumes are removed
On Saturday, June 15, 2019 11:40:56 PM CEST Jeff Kletsky wrote:
> From: Jeff Kletsky
>
> When OEM volumes are present in the [alt_]firmware partition,
> sysupgrade will write a new kernel, but will fail to write
> the root file system. The next boot will hang indefinitely
>
> Waiting for root device /dev/ubiblock0_0...
>
> Modified ipq40xx/base-files/lib/upgrade/linksys.sh
> to remove both `squashfs` and `ubifs` if found
> on the target firmware partition's UBI device.
>
> Run-tested-on: Linksys EA8300
>
> Signed-off-by: Jeff Kletsky
Can you check if this is still working? Or if I broke it
when I was implementing the shellcheck changes?
https://git.openwrt.org/?p=openwrt/staging/chunkeey.git;a=commit;h=003c63f7b1102702fb4a0580683b21ded1ee1a3e
Cheers,
Christian
> ---
> .../ipq40xx/base-files/lib/upgrade/linksys.sh | 22 +++
> 1 file changed, 13 insertions(+), 9 deletions(-)
>
> diff --git a/target/linux/ipq40xx/base-files/lib/upgrade/linksys.sh
> b/target/linux/ipq40xx/base-files/lib/upgrade/linksys.sh
> index b8e6dd7352..a6cf5d8de9 100755
> --- a/target/linux/ipq40xx/base-files/lib/upgrade/linksys.sh
> +++ b/target/linux/ipq40xx/base-files/lib/upgrade/linksys.sh
> @@ -1,3 +1,5 @@
> +#!/bin/sh
> +
> linksys_get_target_firmware() {
>
> local cur_boot_part mtd_ubi0
> @@ -53,8 +55,12 @@ linksys_get_root_magic() {
> }
>
> platform_do_upgrade_linksys() {
> +
> local magic_long="$(get_magic_long "$1")"
>
> + local rm_oem_fw_vols="squashfs ubifs" # from OEM [alt_]rootfs UBI
> + local vol
> +
> mkdir -p /var/lock
> local part_label="$(linksys_get_target_firmware)"
> touch /var/lock/fw_printenv.lock
> @@ -64,7 +70,7 @@ platform_do_upgrade_linksys() {
> exit 1
> fi
>
> - local target_mtd=$(find_mtd_part $part_label)
> + local target_mtd=$(find_mtd_part "$part_label")
>
> [ "$magic_long" = "73797375" ] && {
> CI_KERNPART="$part_label"
> @@ -74,8 +80,6 @@ platform_do_upgrade_linksys() {
> CI_UBIPART="alt_rootfs"
> fi
>
> - # remove "squashfs" vol (in case we are flashing over a stock
> image, which is also UBI)
> -
> local mtdnum="$( find_mtd_index "$CI_UBIPART" )"
> if [ ! "$mtdnum" ]; then
> echo "cannot find ubi mtd partition $CI_UBIPART"
> @@ -89,15 +93,14 @@ platform_do_upgrade_linksys() {
> ubidev="$( nand_find_ubi "$CI_UBIPART" )"
> fi
>
> - if [ "$ubidev" ]; then
> - local squash_ubivol="$( nand_find_volume $ubidev
> squashfs )"
> - # kill volume
> - [ "$squash_ubivol" ] && ubirmvol /dev/$ubidev -N
> squashfs || true
> - fi
> + [ "$ubidev" ] && for vol in $rm_oem_fw_vols ; do
> + ubirmvol "/dev/$ubidev" -N "$vol" 2>/dev/null
> + done
>
> # complete std upgrade
> nand_upgrade_tar "$1"
> }
> +
> [ "$magic_long" = "27051956" ] && {
> # This magic is for a uImage (which is a sysupgrade image)
> # check firmwares' rootfs types
> @@ -107,7 +110,8 @@ platform_do_upgrade_linksys() {
> if [ "$newroot" = "55424923" -a "$oldroot" = "55424923" ]; then
> # we're upgrading from a firmware with UBI to one with
> UBI
> # erase everything to be safe
> - # - Is that really needed? Won't remove (or comment)
> the if, because it may be needed in a future device.
> + # - Is that really needed? Won't remove (or comment)
> the if,
> + # because it may be needed in a future device.
> #mtd erase $part_label
> #get_image "$1" | mtd -n write - $part_label
> echo "writing \"$1\" UBI image to \"$part_label\"
> (UBI)..."
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Understanding Ethernet Architecture (I/O --> MDIO --> MII vs I/O --> MAC) for mt7620 (OpenWRT)
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 ---
Quoting Daniel Santos :
Hi Daniel,
Ah hah! I've found my answer on page 340 (414. PIAC: PHY Indirect Access
Control(offset:0x7004)) and in mt7620_gsw_config:
static int mt7620_gsw_config(struct fe_priv *priv)
{
struct mt7620_gsw *gsw = (struct mt7620_gsw *) priv->soc->swpriv;
/* is the mt7530 internal or external */
if (priv->mii_bus && mdiobus_get_phy(priv->mii_bus, 0x1f)) {
mt7530_probe(priv->dev, gsw->base, NULL, 0);
mt7530_probe(priv->dev, NULL, priv->mii_bus, 1);
} else {
mt7530_probe(priv->dev, gsw->base, NULL, 1);
}
return 0;
}
So priv->mii_bus is non-null when the chip's network hardware is
external because the similarly (and confusingly) named mt7530 is only
the switch hardware, where as the mt7620 is a full µC that has an mt7530
integrated into it. Which leads me to the question of what "GSW"
means? This is the name of the hardware that has the PIAC register, but
nowhere in the data sheet or programming guide can I find a definition.
GSW = Gigabit Switch.
Quote out of an old patch see https://lkml.org/lkml/2018/3/14/1044
"Although the builtin MT7530 is gbit capable, the builtin PHYs are
only 100mbit."
Greats,
René
Thanks,
Daniel
On 6/14/19 5:53 PM, Daniel Santos wrote:
Hello,
I'm still fairly new to Ethernet drivers and there are a lot of
interesting pieces. What I need help with is understanding MDIO -->
(R)MII vs direct I/O to the MAC (e.g., via ioread32, iowrite32). Why is
there not always a struct mii_bus to talk to this hardware? Is it
because the PHY and/or MAC hardware sometimes attached via an MDIO
device and sometimes directly to the I/O bus? Or does some type of
"indirect access" need to be enabled for that to work?
I might be trying to do something that's unnecessary however, I'm not
sure yet. I need to add functionality to change a port's
auto-negotiate, duplex, etc. I'm adding it to the swconfig first and
then will look at adding it for DSA afterwards. When I run "swconfig
dev switch0 port 0 show", the current mt7530 / mt7620 driver is querying
the MAC status register (at base + 0x3008 + 0x100 * port, described on
pages 323-324 of the MT7620 Programming Guide), so I implemented the
"set" functionality by modifying the MAC's control register (offset
0x3000 on page 321), but it doesn't seem to change anything. So I
figured maybe I need to modify the MII interface's control register for
the port (page 350), but upon debugging I can see that the struct
mii_bus *bus member is NULL.
So should I be able to change it via the MAC's control register and
something else is wrong? Why is there no struct mii_bus? Can I talk to
the MII hardware in some other way?
Thanks,
Daniel
https://download.villagetelco.org/hardware/MT7620/MT7620_ProgrammingGuide.pdf
--
Met vriendelijke groet,
René van Dorst
--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Understanding Ethernet Architecture (I/O --> MDIO --> MII vs I/O --> MAC) for mt7620 (OpenWRT)
Ah hah! I've found my answer on page 340 (414. PIAC: PHY Indirect Access
Control(offset:0x7004)) and in mt7620_gsw_config:
static int mt7620_gsw_config(struct fe_priv *priv)
{
struct mt7620_gsw *gsw = (struct mt7620_gsw *) priv->soc->swpriv;
/* is the mt7530 internal or external */
if (priv->mii_bus && mdiobus_get_phy(priv->mii_bus, 0x1f)) {
mt7530_probe(priv->dev, gsw->base, NULL, 0);
mt7530_probe(priv->dev, NULL, priv->mii_bus, 1);
} else {
mt7530_probe(priv->dev, gsw->base, NULL, 1);
}
return 0;
}
So priv->mii_bus is non-null when the chip's network hardware is
external because the similarly (and confusingly) named mt7530 is only
the switch hardware, where as the mt7620 is a full µC that has an mt7530
integrated into it. Which leads me to the question of what "GSW"
means? This is the name of the hardware that has the PIAC register, but
nowhere in the data sheet or programming guide can I find a definition.
Thanks,
Daniel
On 6/14/19 5:53 PM, Daniel Santos wrote:
> Hello,
>
> I'm still fairly new to Ethernet drivers and there are a lot of
> interesting pieces. What I need help with is understanding MDIO -->
> (R)MII vs direct I/O to the MAC (e.g., via ioread32, iowrite32). Why is
> there not always a struct mii_bus to talk to this hardware? Is it
> because the PHY and/or MAC hardware sometimes attached via an MDIO
> device and sometimes directly to the I/O bus? Or does some type of
> "indirect access" need to be enabled for that to work?
>
> I might be trying to do something that's unnecessary however, I'm not
> sure yet. I need to add functionality to change a port's
> auto-negotiate, duplex, etc. I'm adding it to the swconfig first and
> then will look at adding it for DSA afterwards. When I run "swconfig
> dev switch0 port 0 show", the current mt7530 / mt7620 driver is querying
> the MAC status register (at base + 0x3008 + 0x100 * port, described on
> pages 323-324 of the MT7620 Programming Guide), so I implemented the
> "set" functionality by modifying the MAC's control register (offset
> 0x3000 on page 321), but it doesn't seem to change anything. So I
> figured maybe I need to modify the MII interface's control register for
> the port (page 350), but upon debugging I can see that the struct
> mii_bus *bus member is NULL.
>
> So should I be able to change it via the MAC's control register and
> something else is wrong? Why is there no struct mii_bus? Can I talk to
> the MII hardware in some other way?
>
> Thanks,
> Daniel
>
> https://download.villagetelco.org/hardware/MT7620/MT7620_ProgrammingGuide.pdf
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/3] netsupport: improve xfrm module support
On Sun, Jun 16, 2019 at 1:50 AM Andre Valentin wrote: > > Hi! > Am 15.06.19 um 21:35 schrieb Hans Dedecker: > > Hi, > > > > On Fri, Jun 14, 2019 at 1:10 PM André Valentin > > wrote: > >> > >> -switch to module autoprobe > >> -exclude 4.9 kernel > >> > >> Signed-off-by: André Valentin > >> --- > >> package/kernel/linux/modules/netsupport.mk | 4 ++-- > >> 1 file changed, 2 insertions(+), 2 deletions(-) > >> > >> diff --git a/package/kernel/linux/modules/netsupport.mk > >> b/package/kernel/linux/modules/netsupport.mk > >> index 20616d9af6..9732ee0d73 100644 > >> --- a/package/kernel/linux/modules/netsupport.mk > >> +++ b/package/kernel/linux/modules/netsupport.mk > >> @@ -386,10 +386,10 @@ $(eval $(call KernelPackage,ip6-vti)) > >> define KernelPackage/xfrm-interface > >>SUBMENU:=$(NETWORK_SUPPORT_MENU) > >>TITLE:=IPsec XFRM Interface > >> - DEPENDS:=+kmod-ipsec4 +kmod-ipsec6 @!LINUX_4_14 > >> + DEPENDS:=+kmod-ipsec4 +kmod-ipsec6 @!LINUX_4_14 @!LINUX_4_9 > > Is there a reason why you want to exclude kernel version 4.9 as in > > master all targets will be switched to 4.19 and afaik no targets will > > use 4.9 > > > It was Hauke Mehrtens wish, so I'm a bit in between. Fine; I will check with Hauke Hans > > Kind regards, > > André > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
