Re: help to submit patch

[John Thomson]

Hi,

On Thu, 22 Sep 2022, at 19:49, davidea wrote:
> hi guys, i get some LTE module HUAWEI model EC200AEUHA-N06-SNASA , this 
> module arent' recognized from the kernel, or better, the kernel 
> recognize the CDC-ETHER section, but not the ttyUSB were i must 
> configure the APN and lunch the connection
>
> root@OpenWrt:~# lsusb
> Bus 002 Device 001: ID 1d6b:0001 Linux 5.4.203 ohci_hcd Generic Platform 
> OHCI controller
> Bus 001 Device 002: ID 2c7c:6005 Android Android
> Bus 001 Device 001: ID 1d6b:0002 Linux 5.4.203 ehci_hcd EHCI Host 
> Controller
> root@OpenWrt:~#
>
> it's the 2c7c:6005 usbid
>
> then i check for huawei support and they pointed me in the right 
> direction (they give me the source code for some x64 processor)
>
> i check it, and some other pdf and i try to patch openwrt
>
> i downloaded the openwrt code, and tried to modify the option.c file under
>
> openwrt/build_dir/target-mipsel_24kc_musl/linux-ramips_mt76x8/linux-5.4.203/drivers/usb/serial/option.c
>
> adding the definition for this pid
>
>
> #define QUECTEL_PRODUCT_RM500K  0x7001
> +#define QUECTEL_PRODUCT_EC200A  0x6005
> #define CMOTECH_VENDOR_ID   0x16d8
>
>
>      { USB_DEVICE_AND_INTERFACE_INFO(QUECTEL_VENDOR_ID, 
> QUECTEL_PRODUCT_EC200S_CN, 0xff, 0, 0) },
> +    { USB_DEVICE_AND_INTERFACE_INFO(QUECTEL_VENDOR_ID, 
> QUECTEL_PRODUCT_EC200A, 0xff, 0, 0) },
>      { USB_DEVICE_AND_INTERFACE_INFO(QUECTEL_VENDOR_ID, 
> QUECTEL_PRODUCT_EC200T, 0xff, 0, 0) },
>
>
> i complie the code and it's work, now i've the ttyUSB0 to 2 device
>
> how can i submit this patch??
>

You will need to use git to format and submit your change.

Ideally, you submit this change "upstream", to the Linux mailing lists.
The documentation about this process here:
https://www.kernel.org/doc/html/latest/process/submitting-patches.html

Here are examples of making this addition for a similar device:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/log/drivers/usb/serial/option.c
An email which was sent to get a change to happen:
https://lore.kernel.org/all/meyp282mb23740dc78fb0de954c59d3defd...@meyp282mb2374.ausp282.prod.outlook.com/
For these USB changes, the commit message includes the relevant parts from 
/sys/kernel/debug/usb/devices, or usb-devices shell script. Some of them also 
have lsusb -v for the device:
https://lore.kernel.org/linux-usb/20210809133553.71158-1-zhangzheng...@aicrobo.com/

You then wait for this change to be included in a linux-stable release,
or add a kernel patch to OpenWrt (see target/linux/generic/pending-5.10 in the 
OpenWrt tree for examples) as well:
https://openwrt.org/docs/guide-developer/toolchain/use-patches-with-buildsystem#adding_or_editing_kernel_patches
https://openwrt.org/submitting-patches


You might get better responses to these process-related queries on the OpenWrt 
Forum.


Cheers,
-- 
  John

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

[PATCH] ipq40xx: cut ath10k board file for mikrotik subtarget

[John Thomson]

Avoid shipping ath10k board file in Mikrotik initram images

Most will only ever need to use these initram images once—to initially
load OpenWrt, but fix these images for more consistent Wi-Fi performance
between the initram and installed squashfs images.

OpenWrt BUILDBOT config ignores -cut packages in the initram images build.
This results in BUILDBOT initram images including the linux-firmware
qca4019 board-2.bin, and (initram image booted) Mikrotik devices loading
a generic BDF, rather than the intended BDF data loaded
from NOR as an api 1 board_file.

buildbot snapshot booted as initram image:
cat /etc/openwrt_version
r19679-810eac8c7f
dmesg | grep ath10k | grep -E board\|BDF
[9.794556] ath10k_ahb a00.wifi: Loading BDF type 0
[9.807192] ath10k_ahb a00.wifi: board_file api 2 bmi_id 0:16
crc32 11892f9b
[   12.457105] ath10k_ahb a80.wifi: Loading BDF type 0
[   12.464945] ath10k_ahb a80.wifi: board_file api 2 bmi_id 0:17
crc32 11892f9b

CC: Robert Marko 
Fixes: 5eee67a72fed ("ipq40xx: mikrotik: dont include ath10k-board-qca4019 by 
default")

Signed-off-by: John Thomson 
---
 target/linux/ipq40xx/Makefile   | 2 +-
 target/linux/ipq40xx/chromium/target.mk | 1 +
 target/linux/ipq40xx/generic/target.mk  | 1 +
 target/linux/ipq40xx/mikrotik/target.mk | 1 -
 4 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/target/linux/ipq40xx/Makefile b/target/linux/ipq40xx/Makefile
index 7df920e2d8..19b63cdd65 100644
--- a/target/linux/ipq40xx/Makefile
+++ b/target/linux/ipq40xx/Makefile
@@ -19,6 +19,6 @@ DEFAULT_PACKAGES += \
kmod-leds-gpio kmod-gpio-button-hotplug swconfig \
kmod-ath10k-ct wpad-basic-wolfssl \
kmod-usb3 kmod-usb-dwc3 ath10k-firmware-qca4019-ct \
-   ath10k-board-qca4019 uboot-envtools
+   uboot-envtools
 
 $(eval $(call BuildTarget))
diff --git a/target/linux/ipq40xx/chromium/target.mk 
b/target/linux/ipq40xx/chromium/target.mk
index 3983a9281a..98bd37ed71 100644
--- a/target/linux/ipq40xx/chromium/target.mk
+++ b/target/linux/ipq40xx/chromium/target.mk
@@ -1,2 +1,3 @@
 BOARDNAME:=Google Chromium
 FEATURES += emmc boot-part rootfs-part
+DEFAULT_PACKAGES += ath10k-board-qca4019
diff --git a/target/linux/ipq40xx/generic/target.mk 
b/target/linux/ipq40xx/generic/target.mk
index e158b1c98b..90c1b762af 100644
--- a/target/linux/ipq40xx/generic/target.mk
+++ b/target/linux/ipq40xx/generic/target.mk
@@ -1,2 +1,3 @@
 BOARDNAME:=Generic
 FEATURES+=emmc
+DEFAULT_PACKAGES += ath10k-board-qca4019
diff --git a/target/linux/ipq40xx/mikrotik/target.mk 
b/target/linux/ipq40xx/mikrotik/target.mk
index 8b17c61585..4530a90985 100644
--- a/target/linux/ipq40xx/mikrotik/target.mk
+++ b/target/linux/ipq40xx/mikrotik/target.mk
@@ -2,4 +2,3 @@ BOARDNAME:=MikroTik
 FEATURES += minor
 KERNEL_IMAGES:=vmlinux
 IMAGES_DIR:=compressed
-DEFAULT_PACKAGES += -ath10k-board-qca4019
-- 
2.36.1


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

[PATCH] kernel: 5.15: fix mediatek usb module change

[John Thomson]

The mediatek USB kernel module xhci-mtk was restructed.
The module after kernel 5.13 is named xhci-mtk-hcd.
Link:
https://lore.kernel.org/all/0b62e21ddfacc1c2874726dd27ccab80c993f303.1615170625.git.chunfeng@mediatek.com/
Linux 14295a150050 ("usb: xhci-mtk: support to build xhci-mtk-hcd.ko")

Signed-off-by: John Thomson 
---
 package/kernel/linux/modules/usb.mk | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/package/kernel/linux/modules/usb.mk 
b/package/kernel/linux/modules/usb.mk
index c12150fc5c..a52ba745ef 100644
--- a/package/kernel/linux/modules/usb.mk
+++ b/package/kernel/linux/modules/usb.mk
@@ -1787,8 +1787,10 @@ define KernelPackage/usb-xhci-mtk
   DEPENDS:=+kmod-usb-xhci-hcd
   KCONFIG:=CONFIG_USB_XHCI_MTK
   HIDDEN:=1
-  FILES:=$(LINUX_DIR)/drivers/usb/host/xhci-mtk.ko
-  AUTOLOAD:=$(call AutoLoad,54,xhci-mtk,1)
+  FILES:= \
+$(LINUX_DIR)/drivers/usb/host/xhci-mtk.ko@lt5.13 \
+$(LINUX_DIR)/drivers/usb/host/xhci-mtk-hcd.ko@ge5.13
+  AUTOLOAD:=$(call AutoLoad,54,xhci-mtk@lt5.13 xhci-mtk-hcd@gt5.13,1)
   $(call AddDepends/usb)
 endef
 
-- 
2.35.1


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

Re: [PATCH 6/6] binutils: Update to version 2.37

[John Thomson]

Hi Hauke,

On Mon, 1 Nov 2021, at 16:54, Hauke Mehrtens wrote:
>  PKG_NAME:=binutils
> -PKG_VERSION:=2.35.2
> +PKG_VERSION:=2.37

I am seeing a problem compiling package/devel/binutils 2.37
This is not showing on the buildbots, so not urgent.
I opened an upstream bug report here: 
https://sourceware.org/bugzilla/show_bug.cgi?id=28545
I have some more details and a compile log there.

I believe binutils 2.37 in install relink libctf is trying to use some host 
libraries first through
-L/usr/lib (instead of cross-compiled); for libiberty.a, libz.so, and libz.a
These is an upstream fix in master to avoid host libiberty.a in this relink, 
but not zlib

The previous package 2.35.2 compiles without these errors.

First error message in libtool: install: warning: relinking `libctf.la'
/usr/lib/libiberty.a: error adding symbols: file format not recognized


My host is Arch Linux x86_64 (which has libiberty.a, libz.so, and libz.a in 
/usr/lib). My target is ipq40xx.
Compiling binutils packages as a (sub) dependency of iproute2 ip-full.
An ath79 test build also tries to use host libraries, but skips the host 
libraries as incompatible.

I can also see that the autoreconf is failing:
autoreconf: running: /mnt/pool_ssd/code/openwrt/staging_dir/host/bin/aclocal -I 
/mnt/pool_ssd/code/openwrt/staging_dir/target-arm_cortex-a7+neon-vfpv4_musl_eabi/host/share/aclocal
 -I /mnt/pool_ssd/code/openwrt/staging_dir/hostpkg/share/aclocal -I 
/mnt/pool_ssd/code/openwrt/staging_dir/target-arm_cortex-a7+neon-vfpv4_musl_eabi/usr/share/aclocal
 -I m4 -I . -I gas -I bfd -I opcodes -I gprof -I binutils -I ld -I libiberty -I 
gold -I intl --force 
aclocal.real: error: configure.ac:27: file 'libtool.m4' does not exist
autoreconf: /mnt/pool_ssd/code/openwrt/staging_dir/host/bin/aclocal failed with 
exit status: 1

Cheers,
-- 
  John Thomson

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

Re: dnsmasq compile error: rfc1035.c:978:56: error: 'struct dnsmasq_daemon' has no member named 'workspacename'

[John Thomson]

Hi Patrick,

On Tue, 28 Sep 2021, at 09:29, John Thomson wrote:
> This looks like a problem in dnsmasq, because you are building with 
> ubus and contrack, but without dnssec.

Yes, this is a dnsmasq bug which Simon has now fixed upstream:
https://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commitdiff;h=2c60441239e1c10c4987cb586653b1ea08f703c0

If you want to use these OpenWrt dnsmasq configuration options,
you might be able to patch OpenWrt's dnsmasq by adding the fix to
package/network/services/dnsmasq/patches

Cheers,
-- 
  John Thomson

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

Re: dnsmasq compile error: rfc1035.c:978:56: error: 'struct dnsmasq_daemon' has no member named 'workspacename'

[John Thomson]

Hi Patrick,

On Mon, 27 Sep 2021, at 20:21, Patrick Vorlicek wrote:
> make[5]: Entering directory
> '/root/openwrt/ea8500/build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/dnsmasq-full/dnsmasq-2.86/src'
> arm-openwrt-linux-muslgnueabi-gcc -Os -pipe -fno-caller-saves -fno-plt
> -fhonour-copts -Wno-error=unused-but-set-variable
> -Wno-error=unused-result -mfloat-abi=hard
> -fmacro-prefix-map=/root/openwrt/ea8500/build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/dnsmasq-full/dnsmasq-2.86=dnsmasq-2.86
> -Wformat -Werror=format-security -DPIC -fpic -fstack-protector
> -D_FORTIFY_SOURCE=1 -Wl,-z,now -Wl,-z,relro -flto
> -I/root/openwrt/ea8500/staging_dir/toolchain-arm_cortex-a15+neon-vfpv4_gcc-11.2.0_musl_eabi/usr/include
> -I/root/openwrt/ea8500/staging_dir/toolchain-arm_cortex-a15+neon-vfpv4_gcc-11.2.0_musl_eabi/include/fortify
> -I/root/openwrt/ea8500/staging_dir/toolchain-arm_cortex-a15+neon-vfpv4_gcc-11.2.0_musl_eabi/include
> -DHAVE_UBUS -DHAVE_POLL_H   -DHAVE_CONNTRACK -DNO_ID  -DNO_TFTP  
> -DVERSION='"2.86"' 
> -I/root/openwrt/ea8500/staging_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/usr/include
>  
> -c rfc1035.c
> rfc1035.c: In function 'report_addresses':
> rfc1035.c:978:56: error: 'struct dnsmasq_daemon' has no member named
> 'workspacename'
>   978 |   if (!extract_name(header, len, ,
> daemon->workspacename, 1, 0))
>   |    ^~
> rfc1035.c:980:66: error: 'struct dnsmasq_daemon' has no member named
> 'workspacename'
>   980 |   if (safe_name(daemon->namebuff) &&
> safe_name(daemon->workspacename))
>   
> |  ^~
> rfc1035.c:981:92: error: 'struct dnsmasq_daemon' has no member named
> 'workspacename'
>   981 |
> ubus_event_bcast_connmark_allowlist_resolved(mark, daemon->namebuff,
> daemon->workspacename, attl);
> 
> | 
>   
> ^~
> make[5]: ***
> [/root/openwrt/ea8500/build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/dnsmasq-full/dnsmasq-2.86/Makefile:166:
> rfc1035.o] Error 1
> make[5]: Leaving directory
> '/root/openwrt/ea8500/build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/dnsmasq-full/dnsmasq-2.86/src'
>
> It's a custom build of current master
> (830c2e53781ade1817b03bbb8ece6291ae34df5d) with the following dnsmasq
> config:
>
> # CONFIG_PACKAGE_dnsmasq is not set
> # CONFIG_PACKAGE_dnsmasq-dhcpv6 is not set
> CONFIG_PACKAGE_dnsmasq-full=y
> CONFIG_PACKAGE_dnsmasq_full_dhcp=y
> CONFIG_PACKAGE_dnsmasq_full_dhcpv6=y
> # CONFIG_PACKAGE_dnsmasq_full_dnssec is not set
> CONFIG_PACKAGE_dnsmasq_full_auth=y
> CONFIG_PACKAGE_dnsmasq_full_ipset=y
> CONFIG_PACKAGE_dnsmasq_full_conntrack=y
> CONFIG_PACKAGE_dnsmasq_full_noid=y
> # CONFIG_PACKAGE_dnsmasq_full_broken_rtc is not set
> # CONFIG_PACKAGE_dnsmasq_full_tftp is not set


This looks like a problem in dnsmasq, because you are building with ubus and 
contrack,
but without dnssec.
If this is a valid configuration combination for dnsmasq, this is a bug.
Otherwise, we will need to update the OpenWrt package so that these settings 
cannot occur together.

I have included dnsmasq-discuss


daemon->workspacename is guarded by HAVE_DNSSEC in src/dnsmasq.h
extern struct daemon {
…
#ifdef HAVE_DNSSEC
   char *keyname; /* MAXDNAME size buffer */
   char *workspacename; /* ditto */

but access to daemon->workspacename is guarded by
HAVE_CONNTRACK && HAVE_UBUS in src/rfc1035.c

#if defined(HAVE_CONNTRACK) && defined(HAVE_UBUS)
…
void report_addresses(struct dns_header *header, size_t len, u32 mark)
…
   if (!extract_name(header, len, , daemon->workspacename, 1, 0))


Cheers,
-- 
  John Thomson

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

Re: GPIO mapping on Onion Omega2+ (MT7688)

[John Thomson]

Hi Mike,

On Mon, 30 Aug 2021, at 21:05, Mike Bernardo wrote:

> root@onion1:~# echo 15 > /sys/class/gpio/export
> ash: write error: Invalid argument
> 
> I guess the number I specify to export would need to be at least 416?

Yes, that's it.
You need to add the Linux gpiochip base to the (SoC) GPIO number you want to 
use.
You may need to try each bank to get the correct one.
See https://openwrt.org/docs/techref/hardware/port.gpio#software

> All of the GPIOs are unlableled, am I missing some type of ACPI mapping 
> table? Or some kind of mapping in U-boot?

If you want these names populated,
you can add the details to your dts file.
The Linux binding documentation shows how (gpio-line-names):
https://elixir.bootlin.com/linux/latest/source/Documentation/devicetree/bindings/gpio/gpio.txt

https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/ramips/dts/mt7628an_onion_omega2.dtsi
shows that GPIO 38 is a reset button, and 44 is the system LED,
so you could have 38 blank names: "", and the 39th as "reset"

> I can create all of the GPIOs from 416-511 and they show in 
> /sys/kernel/debug/gpio but most are labeled with "sysfs", I guess I was 
> looking for one to be labeled like "GPIO15"?

sysfs here is the driver that has claimed this GPIO number,
because you (or something else) has exported that gpio number in 
/sys/class/gpio/

> It seems crazy it would have 3 GPIO chips with 32 lines each, so 
> something seems wrong.

Expected: This is the way this system on a chip is built.

> Is it possible this might help?
> 
> http://patchwork.ozlabs.org/project/linux-gpio/patch/20210727152026.31019-3-sergio.paracuel...@gmail.com/

That patch is part of a series which fixes lazy labelling:
An incomplete gpio-line-names array (where the number of passed
named are less than ngpios)


Hope that helps.

-- 
  John Thomson

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

Re: OpenWrt DSA Mini-Tutorial

[John Thomson]

On Sun, 18 Jul 2021, at 20:45, Rich Brown wrote:
> I have updated the DSA Mini-tutorial in the playground: 
> https://openwrt.org/playground/richb/dsa-mini-tutorial
> 
> I finished the first section ("Bridging all LAN ports"), and I am going 
> to stop editing now, because:
> 
> 1) I need someone else to look at the overall format of the document
> 2) I made some bold assertions and simplifications of the language in 
> the document. But because I don't really understand DSA, I may be 
> totally wrong...
> 3) If it's not right, we won't have to patch up the remainder, that is 
> substantially unchanged from the Forum post.
> 
> Please check it out and either change it, or let me know what needs to 
> be fixed. Thanks.

Hi Rich,

Thank you for putting this together.
I had a skim through it, and was rather confused when I got to bridge-vlan,
but ended up learning more.
Could we please introduce bridge-vlan in the guide,
and also document it in throughout the wiki:
https://openwrt.org/docs/guide-user/network/ucicheatsheet
https://openwrt.org/docs/guide-user/base-system/basic-networking?s[]=bridge-vlan#switch_configuration_dsabridge-vlan

I found good resources in an early cover letter, and a RedHat blog:
https://lwn.net/Articles/532128/
https://developers.redhat.com/blog/2017/09/14/vlan-filter-support-on-bridge#with_vlan_filtering

Guessing if I wanted to display or modify the bridge vlan configuration
at the linux level I would need to install additional packages?
Maybe: ip-bridge ip-full

My situation:
I have mt7621 devices. They use DSA; there is a linux network device for
each port of the device switch in `ls /sys/class/net` or `ip link show`,
but they don't use bridge-vlan (or vlan_filtering) in the default config.
Without having seen bridge-vlan, I was using the OpenWrt configuration
of multiple bridge devices (and interfaces) to isolate networks,
and using device bridge `list ports 'portname.vlan'` to force VLAN tags for 
ports.
It looks like bridge-vlan allows finer control and many more options.


Cheers,
-- 
  John

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

Re: [PATCH v2] ramips: fix at803x patch again

[John Thomson]

On Fri, 11 Jun 2021, at 08:10, David Bauer wrote:
> Can you be more precise in terms of which issues are you facing? The 
> PHY capabilities on
> the AR8333 now read 1000B-X as a supported link mode, so fiber 
> operation should be possible.
> 
> Can you share the capabilities advertised with current master and your 
> path (ethtool).
> 
> Reverting these patches would divert from upcoming kernel versions 
> (mind both are backports,
> not downstream hacks), thus this is not a solution. Ideally, the fiber 
> operation should be
> integrated into the upstream driver.

I agree that this should be corrected atop the backports.
It would be great to see this SFP support upstreamed.
I have not tested SFP on OpenWrt master for some time, so I cannot blame a 
change yet.

This is what I am seeing on ramips 760igs:

SFP (module, and driver LOS) has link detected, but this is not reflected by 
the interface
(which is configured in OpenWrt as part of a bridge)

sfp:  mtu 1500 qdisc fq_codel master br-wan 
state DOWN qlen 1000

r16925+6-b721579842 master, plus my
SPI-NOR changes: https://github.com/openwrt/openwrt/pull/3271/commits

I do not remember these being looped in dmesg when I had working SFP:
sfp sfp1: SM: enter present:up:link_up event dev_up
sfp sfp1: SM: exit present:up:link_up

ethtool sfp
Settings for sfp:
Supported ports: [ TP MII ]
Supported link modes:   10baseT/Half 10baseT/Full 
100baseT/Half 100baseT/Full 
1000baseT/Full 
1000baseX/Full 
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes:  10baseT/Half 10baseT/Full 
100baseT/Half 100baseT/Full 
1000baseT/Full 
1000baseX/Full 
Advertised pause frame use: Symmetric Receive-only
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Speed: Unknown!
Duplex: Unknown! (255)
Port: MII
PHYAD: 7
Transceiver: external
Auto-negotiation: on
Current message level: 0x00ff (255)
   drv probe link timer ifdown ifup rx_err tx_err
Link detected: no

Pieces missing from a very old (r14885+1-fe302d472a) working SFP build: link 
partner advertisement and link speed / duplex
Link partner advertised link modes:  1000baseX/Full
Link partner advertised pause frame use: Symmetric Receive-only
Link partner advertised auto-negotiation: Yes
Link partner advertised FEC modes: Not reported
Speed: 1000Mb/s
Duplex: Full
Port: MII
PHYAD: 7
Transceiver: external
Auto-negotiation: on
Current message level: 0x00ff (255)
   drv probe link timer ifdown ifup rx_err tx_err
Link detected: yes

these cannot be forced on my current build:
ethtool -s sfp speed 1000 duplex full
[  182.182182] at803x_config_aneg: fiber


Attached:
version=$(cat /etc/openwrt_version)
mkdir -p "/tmp/sfp/$version"
dmesg > "/tmp/sfp/$version/dmesg"
logread > "/tmp/sfp/$version/logread"
ethtool sfp > "/tmp/sfp/$version/ethtool_sfp"
ethtool -m sfp > "/tmp/sfp/$version/ethtool_m_sfp"
echo -n 'file sfp.c +p' > /sys/kernel/debug/dynamic_debug/control
/etc/init.d/network restart
dmesg > "/tmp/sfp/$version/dmesg_reup"
logread > "/tmp/sfp/$version/logread_reup"
# remove, and reinsert SFP module
dmesg > "/tmp/sfp/$version/dmesg_reinsert"
logread > "/tmp/sfp/$version/logread_reinsert"

diffconfig:
CONFIG_TARGET_ramips=y
CONFIG_TARGET_ramips_mt7621=y
CONFIG_TARGET_ramips_mt7621_DEVICE_mikrotik_routerboard-760igs=y
CONFIG_KERNEL_DYNAMIC_DEBUG=y
CONFIG_KERNEL_MTD_PARTITIONED_MASTER=y
CONFIG_PACKAGE_ethtool=y
CONFIG_ETHTOOL_PRETTY_DUMP=y

Cheers,
-- 
  John Thomson

openwrt_sfp_logs.tar.zstd
Description: Binary data
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH v2] ramips: fix at803x patch again

[John Thomson]

On Fri, 4 Jun 2021, at 16:19, David Bauer wrote:
> See the commit "generic: backport at803x fixes" in my staging tree [0].
> [0] https://git.openwrt.org/?p=openwrt/staging/blocktrron.git;a=summary

This (efbaa6c8bd4c atop master) would not compile for me with 5.4?
CONFIG_TARGET_ramips=y
CONFIG_TARGET_ramips_mt7621=y
CONFIG_TARGET_ramips_mt7621_DEVICE_mikrotik_routerboard-760igs=y
CONFIG_KERNEL_DYNAMIC_DEBUG=y

Missing functions from:
(5.5) net: phy: at803x: add device tree binding 
2f664823a47021ae029fe91272adbf0a223e477f

(5.5) net: phy: add helpers phy_(un)lock_mdio_bus 
bec170e55982c2d3b8e1beccadf16e288fe6fb5a

  CHK include/generated/compile.h
  CC  drivers/net/phy/at803x.o
drivers/net/phy/at803x.c: In function 'at803x_probe':
drivers/net/phy/at803x.c:365:6: error: implicit declaration of function 
'at803x_match_phy_id'; did you mean 'cpupid_match_pid'? 
[-Werror=implicit-function-declaration]
  if (at803x_match_phy_id(phydev, ATH8031_PHY_ID)) {
  ^~~
  cpupid_match_pid
drivers/net/phy/at803x.c:366:3: error: implicit declaration of function 
'phy_lock_mdio_bus' [-Werror=implicit-function-declaration]
   phy_lock_mdio_bus(phydev);
   ^
drivers/net/phy/at803x.c:368:3: error: implicit declaration of function 
'phy_unlock_mdio_bus' [-Werror=implicit-function-declaration]
   phy_unlock_mdio_bus(phydev);
   ^~~
cc1: some warnings being treated as errors
make[8]: *** [scripts/Makefile.build:262: drivers/net/phy/at803x.o] Error 1

Cheers,

-- 
  John Thomson

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

Re: [PATCH RFC] kernel: mtd spi-nor: allow use of mixed erasesizes (E.g. 64K & 4K)

[John Thomson]

On Sun, 11 Oct 2020, at 18:45, Robert Marko wrote:

> I can test this on hAP ac2 (IPQ40xx), but can you provide all of the
> patches needed as you mention partially removing 411 and 412 patches,
> and removing 470 completely?

Great. It has been working for me on older devices, but make sure you have a 
backup of the Routerboot partitions first, and a means to write them back.

The 411, 412, and 470 patches all get removed. I should have been more clear.
ls target/linux/generic/pending-5.4/{411,412,470}*
rm target/linux/generic/pending-5.4/{411,412,470}*

These are on my PR as commits, along with a no-op write/erase, and debug 
utility package. https://github.com/openwrt/openwrt/pull/3271

Cheers,

-- 
  John Thomson

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

[PATCH RFC] kernel: mtd spi-nor: allow use of mixed erasesizes (E.g. 64K & 4K)

[John Thomson]

Allow SPI NOR code to be configured to use the multiple erase-regions
code path for a uniform erase-region device. This code path allows an
erase request to select and run a list of erase operations (including 4K
erases where supported by the device, and needed by the request). The
multi erase-regions code path does additional checks before the erase
starts, therefore may take slightly longer before the erase runs on device.

Kernel config options:
Introduces:
CONFIG_MTD_SPI_NOR_USE_VARIABLE_ERASE=y
Used with:
CONFIG_MTD_SPI_NOR_USE_4K_SECTORS=n

Previous users of partial or 4K erase in Openwrt:
- Mikrotik routerboot bootloader configuration
  target/linux/generic/files/drivers/platform/mikrotik/rb_softconfig.c
  Will work with this patch, with the 4K_SECTORS test removed.
- RedBoot "FIS directory" partition scheme layout update
  package/system/mtd/src/fis.c
  Will need to be changed to use the size of the FIS directory partition,
  rather than the partition erasesize.
  The partial erase patchset set erasesize to partition size where
  partition boundary was not major erasesize aligned. This patch sets
  partition erasesize to minor erasesize only where the boundary is
  minor erasesize aligned.

An erasesize_minor variable is added to the MTD struct mtd_info, so that
the mtd level does not need access to the SPI NOR level to calculate the
smallest (minor) universal erasesize. This is set in spi-nor.c device
initialisation.

mtdpart.c is modified to not prevent writing to partitions with a
boundary on a minor eraseblock. As mtd partitions are currently a stack
of structs, the erasesize_minor need to be copied (from parent) to each
partition. MTD partitions use a list in kernel 5.7, but the erasesize
boundary code remains the same.

There appears to be a bug in spi-nor.c for univeral erase-region devices,
in a code path that only this patch uses: A pointer to an address within
a struct is not updated following a memcpy of the struct.

Signed-off-by: John Thomson 

---

Replaces Openwrt generic patches:
These cuts are not included in this patch to reduce RFC length.
- partial erase 411 & 412
- 4K limit 470 (non-functional on 5.4)

Any suggestions welcome!

Further discussion here: https://github.com/openwrt/openwrt/pull/3271

WIP: Do not run this without a full NOR backup,
and a means to restore it.
E.g. SOIC8 clip? + single board computer with extra SPI.

Run tested with Mikrotik soft_config writes on ath79 & ramips.
Not tested on Redboot FIS layout update (fis code needs changes).

An earlier patch which modified the default universal erase-region code
path in spi-nor.c was sent RFC to linux-mtd, but received no comments.

The update pointer to memcpy'd address patch has been recently sent RFC
to linux-mtd and maintainers. My intention is that once this gets addressed,
I send through the erasesize_minor and mtdpart changes.

- I am not sure that testing if (wr_alignment_minor) is enough to check
  that the device has an erasesize_minor set?
- I am not sure that the picked erasesize_minor would be universal for
  multi erase-regions devices.

It is my opinion that code requesting an mtd_erase should manage the
whole eraseblock. The partial erase patchset currently manages this in
kernel, and a recently fixed merge bug in it was able to cause data loss
and bootloader corruption on some Mikrotik and Redboot devices. In
kernel 5.7, the mtd partition code is changed and would require a
rewrite of the partial erase, as part_erase is no longer used.

There may be devices that currently use partial erase which do not support 4K
erase. They would lose functionaly with this patch.

If there are any other user of 4K or partial erase, please let me know.

Cheers!
---
 ...9-0-mtd-spi-nor-allow-variable-erase.patch | 172 ++
 1 file changed, 172 insertions(+)
 create mode 100644 
target/linux/generic/pending-5.4/499-0-mtd-spi-nor-allow-variable-erase.patch

diff --git 
a/target/linux/generic/pending-5.4/499-0-mtd-spi-nor-allow-variable-erase.patch 
b/target/linux/generic/pending-5.4/499-0-mtd-spi-nor-allow-variable-erase.patch
new file mode 100644
index 00..a7d727f2b0
--- /dev/null
+++ 
b/target/linux/generic/pending-5.4/499-0-mtd-spi-nor-allow-variable-erase.patch
@@ -0,0 +1,172 @@
+--- a/drivers/mtd/mtdpart.c
 b/drivers/mtd/mtdpart.c
+@@ -331,8 +331,9 @@ static struct mtd_part *allocate_partiti
+ {
+   int wr_alignment = (parent->flags & MTD_NO_ERASE) ? parent->writesize :
+   parent->erasesize;
++  int wr_alignment_minor = parent->erasesize_minor;
+   struct mtd_part *slave;
+-  u32 remainder;
++  u32 remainder, remainder_minor;
+   char *name;
+   u64 tmp;
+ 
+@@ -433,6 +434,9 @@ static struct mtd_part *allocate_partiti
+   if (parent->_put_device)
+   slave->mtd._put_device = part_put_device;
+ 
++  if (parent->erasesize_minor)
++  

Re: [PATCH] kernel: fix mtd partition erase

[John Thomson]

On Wed, 5 Aug 2020, at 21:13, John Thomson wrote:

> -@@ -213,6 +262,24 @@ static int part_erase(struct mtd_info *m
>   if (instr->fail_addr != MTD_FAIL_ADDR_UNKNOWN)
>   instr->fail_addr -= part->offset;

I should modify this to avoid the _write, if the _erase fails before the write 
address?

>   if (mtd->flags & MTD_ERASE_PARTIAL) {
>   if (partial_start) {
>   part->parent->_write(part->parent,


-- 
  John Thomson

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

[PATCH] kernel: fix mtd partition erase

[John Thomson]

This bug applied where mtd partition end address,
or erase start address, was not cleanly divisible by parent mtd erasesize.

This error would cause the bits following the end of the partition
to the next erasesize block boundary to be erased,
and this partition-overflow data to be written to the partition erase
address (missing additional partition offset address)
of the mtd (top) parent device.

Signed-off-by: John Thomson 

--

4.19 also requires this fix

A little discussion here:
https://github.com/openwrt/openwrt/pull/3103#issuecomment-667610510

mtdpart.c should be made to work with 4K erase sectors, where available
Considering this here:
https://github.com/openwrt/openwrt/pull/3271
---
 .../411-mtd-partial_eraseblock_write.patch  | 13 ++---
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git 
a/target/linux/generic/pending-5.4/411-mtd-partial_eraseblock_write.patch 
b/target/linux/generic/pending-5.4/411-mtd-partial_eraseblock_write.patch
index b46c3f5ed4..c48a144d3d 100644
--- a/target/linux/generic/pending-5.4/411-mtd-partial_eraseblock_write.patch
+++ b/target/linux/generic/pending-5.4/411-mtd-partial_eraseblock_write.patch
@@ -19,7 +19,7 @@ Signed-off-by: Felix Fietkau 
  /* Our partition linked list */
  static LIST_HEAD(mtd_partitions);
  static DEFINE_MUTEX(mtd_partitions_mutex);
-@@ -206,6 +208,53 @@ static int part_erase(struct mtd_info *m
+@@ -206,11 +208,77 @@ static int part_erase(struct mtd_info *m
  {
struct mtd_part *part = mtd_to_part(mtd);
int ret;
@@ -73,10 +73,9 @@ Signed-off-by: Felix Fietkau 
  
instr->addr += part->offset;
ret = part->parent->_erase(part->parent, instr);
-@@ -213,6 +262,24 @@ static int part_erase(struct mtd_info *m
+   if (instr->fail_addr != MTD_FAIL_ADDR_UNKNOWN)
instr->fail_addr -= part->offset;
-   instr->addr -= part->offset;
- 
++
 +  if (mtd->flags & MTD_ERASE_PARTIAL) {
 +  if (partial_start) {
 +  part->parent->_write(part->parent,
@@ -95,10 +94,10 @@ Signed-off-by: Felix Fietkau 
 +  kfree(erase_buf);
 +  }
 +
-   return ret;
- }
+   instr->addr -= part->offset;
  
-@@ -525,19 +592,22 @@ static struct mtd_part *allocate_partiti
+   return ret;
+@@ -525,19 +593,22 @@ static struct mtd_part *allocate_partiti
remainder = do_div(tmp, wr_alignment);
if ((slave->mtd.flags & MTD_WRITEABLE) && remainder) {
/* Doesn't start on a boundary of major erase size */
-- 
2.28.0


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