Re: usb: cdc-acm: BUG kmalloc-128 Poison overwritten
Den fre. 26. feb. 2021 kl. 15.14 skrev Bruno Thomsen : > > Den tor. 25. feb. 2021 kl. 10.57 skrev Oliver Neukum : > > > > Am Mittwoch, den 24.02.2021, 16:21 +0100 schrieb Bruno Thomsen: > > > > Hi, > > > > > No, this is not a regression from 5.10. It seems that many attempts to > > > fix cdc-acm in the 5.x kernel series have failed to fix the root cause of > > > these oops. I have not seen this on 4.14 and 4.19, but I have observed > > > it on at least 5.3 and newer kernels in slight variations. > > > I guess this is because cdc-acm is very common in the embedded > > > ARM world and rarely used on servers or laptops. Combined with > > > ARM devices still commonly use 4.x LTS kernels. Not sure if > > > hardening options on the kernel has increased change of reproducing > > > oops. > > > > OK, so this is not an additional problem. > > According to your logs, an URB that should have been killed wasn't. > > Thanks for looking into this bug rapport. > > > > I am ready to test new patches and will continue to report oops > > > > Could you test the attached patches? > > Yes, I am already running tests on the patches. > I have not seen any oops yet and it seems the USB cdc-acm driver is still > working as intended. > > The only notable trace I have seen is this new error from the cdc-acm driver > but everything kept on working. > kernel: cdc_acm 1-1.1:1.7: acm_start_wb - usb_submit_urb(write bulk) failed: > -19 > > Other then that I see this common error (should probably be a warning) during > device enumeration: > kernel: cdc_acm 1-1.2:1.0: failed to set dtr/rts > > I will post an update next week when the patches have survived some > more runtime. Tested-by: Bruno Thomsen I have not observed any oops with patches applied. Patches have seen more than 10 weeks of runtime testing across multiple devices. /Bruno
Re: usb: cdc-acm: BUG kmalloc-128 Poison overwritten
Den tor. 25. feb. 2021 kl. 10.57 skrev Oliver Neukum : > > Am Mittwoch, den 24.02.2021, 16:21 +0100 schrieb Bruno Thomsen: > > Hi, > > > No, this is not a regression from 5.10. It seems that many attempts to > > fix cdc-acm in the 5.x kernel series have failed to fix the root cause of > > these oops. I have not seen this on 4.14 and 4.19, but I have observed > > it on at least 5.3 and newer kernels in slight variations. > > I guess this is because cdc-acm is very common in the embedded > > ARM world and rarely used on servers or laptops. Combined with > > ARM devices still commonly use 4.x LTS kernels. Not sure if > > hardening options on the kernel has increased change of reproducing > > oops. > > OK, so this is not an additional problem. > According to your logs, an URB that should have been killed wasn't. Thanks for looking into this bug rapport. > > I am ready to test new patches and will continue to report oops > > Could you test the attached patches? Yes, I am already running tests on the patches. I have not seen any oops yet and it seems the USB cdc-acm driver is still working as intended. The only notable trace I have seen is this new error from the cdc-acm driver but everything kept on working. kernel: cdc_acm 1-1.1:1.7: acm_start_wb - usb_submit_urb(write bulk) failed: -19 Other then that I see this common error (should probably be a warning) during device enumeration: kernel: cdc_acm 1-1.2:1.0: failed to set dtr/rts I will post an update next week when the patches have survived some more runtime. /Bruno
Re: usb: cdc-acm: BUG kmalloc-128 Poison overwritten
Den man. 22. feb. 2021 kl. 10.36 skrev Oliver Neukum :
>
> Am Donnerstag, den 18.02.2021, 16:52 +0100 schrieb Bruno Thomsen:
> > Den fre. 12. feb. 2021 kl. 16.33 skrev Bruno Thomsen
> > :
> > > Hi,
> > >
> > > I have been experience random kernel oops in the cdc-acm driver on
> > > imx7 (arm arch). Normally it happens during the first 1-3min runtime
> > > after power-on. Below oops is from 5.8.17 mainline kernel with an
> > > extra patch back-ported in an attempt to fix it:
> > > 38203b8385 ("usb: cdc-acm: fix cooldown mechanism")
> >
> > I can now boot board with 5.11 kernel without any extra patches and
> > it produce similar issue. Hopefully that make the oops more useful.
> > Issue has been seen on multiple devices, so I don't think it's a bad
> > hardware issue.
>
> is this a regression from 5.10?
Hi Oliver
No, this is not a regression from 5.10. It seems that many attempts to
fix cdc-acm in the 5.x kernel series have failed to fix the root cause of
these oops. I have not seen this on 4.14 and 4.19, but I have observed
it on at least 5.3 and newer kernels in slight variations.
I guess this is because cdc-acm is very common in the embedded
ARM world and rarely used on servers or laptops. Combined with
ARM devices still commonly use 4.x LTS kernels. Not sure if
hardening options on the kernel has increased change of reproducing
oops.
I am ready to test new patches and will continue to report oops
/Bruno
Re: watchdog: pcf2127: systemd fails on 5.11
Den man. 22. feb. 2021 kl. 23.43 skrev Guenter Roeck : > > On Thu, Feb 18, 2021 at 01:35:36PM +0100, Bruno Thomsen wrote: > > Hi, > > > > After updating the kernel from 5.8.17 to 5.11 systemd (246.6) is > > unable to init watchdog in pcf2127 during boot. Kernel option > > CONFIG_WATCHDOG_OPEN_TIMEOUT=300 is working as expected. > > It's possible to get watchdog from userspace working in > > the following 2 ways. > > 1) Disable watchdog in systemd and use busybox watchdog. > > 2) Restart systemd after boot with "kill 1". > > > > During boot setting the system clock from RTC is working. > > RTC read/write from userland with hwclock is also working. > > > > DTS: imx7d-flex-concentrator-mfg.dts > > SOC: NXP i.MX7D > > Drivers: rtc-pcf2127, spi-imx > > Communication: SPI > > > > There are no patches applied to the kernel. > > > > When systemd changes watchdog timeout it receives an > > error that to our best knowledge comes from spi-imx[1]. > > > > We suspect it's a race condition between drivers or > > incompatible error handling. > > > > Any help in investigating the issue is appreciated. > > > Difficult to say without access to hardware. The code does have a > potential problem, though: It calls pcf2127_wdt_ping not only from > watchdog code but also from various rtc related functions, but there > is not access protection. This is even more concerning because the ping > function is called from an interrupt handler. At the same time, the > watchdog initialization sets min_hw_heartbeat_ms to 500, which suggests > that there may be a minimum time between heartbeats (which is clearly > violated by the current code). Hi Guenter Thanks for input. You could be right about that, I don't think the watchdog feature should be available for use if the alarm feature is enabled due to how CTRL2 register behaves. The hardware I am testing on is a custom board, but it's actually possible to get a Raspberry Pi module called RasClock that has the chip. I will test some locking around WD_VAL register access as that is used in pcf2127_wdt_ping function. My initial test shows that spin_lock_irqsave around regmap calls are not a good idea as it result in: BUG: scheduling while atomic: watchdog/70/0x0002 BUG: scheduling while atomic: systemd/1/0x0002 /Bruno
Re: usb: cdc-acm: BUG kmalloc-128 Poison overwritten
Den fre. 12. feb. 2021 kl. 16.33 skrev Bruno Thomsen :
>
> Hi,
>
> I have been experience random kernel oops in the cdc-acm driver on
> imx7 (arm arch). Normally it happens during the first 1-3min runtime
> after power-on. Below oops is from 5.8.17 mainline kernel with an
> extra patch back-ported in an attempt to fix it:
> 38203b8385 ("usb: cdc-acm: fix cooldown mechanism")
I can now boot board with 5.11 kernel without any extra patches and
it produce similar issue. Hopefully that make the oops more useful.
Issue has been seen on multiple devices, so I don't think it's a bad
hardware issue.
[ 76.458010] 8<--- cut here ---
[ 76.461178] Unable to handle kernel paging request at virtual address 6b6b6b93
[ 76.472958] pgd = f805d813
[ 76.475788] [6b6b6b93] *pgd=
[ 76.488068] Internal error: Oops: 5 [#1] PREEMPT SMP ARM
[ 76.493441] Modules linked in: xt_TCPMSS xt_tcpmss xt_hl nf_log_ipv6
nf_log_ipv4 nf_log_common xt_policy xt_limit xt_conntrack xt_tcpudp
xt_pkttype ip6table_mangle iptable_nat nf_nat nf_conntrack
nf_defrag_ipv6 nf_defrag_ipv4 iptable_mangle ip6table_filter
ip6_tables iptable_filter ip_tables des_generic md5 sch_fq_codel
cdc_mbim cdc_wdm cdc_ncm cdc_ether usbnet mii cdc_acm usb_storage
ip_tunnel xfrm_user xfrm6_tunnel tunnel6 xfrm4_tunnel tunnel4 esp6
esp4 ah6 ah4 xfrm_algo xt_LOG xt_LED xt_comment x_tables ipv6
[ 76.539032] CPU: 0 PID: 5 Comm: kworker/0:0 Tainted: G T 5.11.0 #1
[ 76.546539] Hardware name: Freescale i.MX7 Dual (Device Tree)
[ 76.552295] Workqueue: events acm_softint [cdc_acm]
[ 76.557223] PC is at usb_kill_urb+0x8/0x24
[ 76.561337] LR is at acm_softint+0x4c/0x10c [cdc_acm]
[ 76.566415] pc : [<805911a8>] lr : [<7f1168c4>] psr: 200e0113
[ 76.572689] sp : 84113f08 ip : 8575de7c fp : 840e92bc
[ 76.577920] r10: r9 : 893222a8 r8 : 89322008
[ 76.583151] r7 : 89322000 r6 : 89322438 r5 : 89322448 r4 : 000a
[ 76.589686] r3 : 6b6b6b6b r2 : 12d79029 r1 : 800e0113 r0 : 6b6b6b6b
[ 76.596223] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
[ 76.603369] Control: 10c5387d Table: 8933406a DAC: 0051
[ 76.609120] Process kworker/0:0 (pid: 5, stack limit = 0x8fb8cf7e)
[ 76.615315] Stack: (0x84113f08 to 0x84114000)
[ 76.619685] 3f00: 89322448 840e9280 bf6caf40 bf6ce100
[ 76.627875] 3f20: 8013f14c 84112000 bf6caf40 bf6caf58
840e9280 bf6caf40 840e9294
[ 76.636065] 3f40: bf6caf58 80c03d00 0008 84112000 bf6caf40
8013f3e8 80d0bbb0
[ 76.644255] 3f60: 840a7640 840a77c0 84112000 840ede7c
8013f3a4 840e9280 840a7664
[ 76.652445] 3f80: 801467d8 840a77c0 80146694
[ 76.660634] 3fa0: 80100150
[ 76.668823] 3fc0:
[ 76.677012] 3fe0: 0013
[ 76.685203] [<805911a8>] (usb_kill_urb) from [<7f1168c4>]
(acm_softint+0x4c/0x10c [cdc_acm])
[ 76.693690] [<7f1168c4>] (acm_softint [cdc_acm]) from [<8013f14c>]
(process_one_work+0x1bc/0x414)
[ 76.702605] [<8013f14c>] (process_one_work) from [<8013f3e8>]
(worker_thread+0x44/0x4dc)
[ 76.710719] [<8013f3e8>] (worker_thread) from [<801467d8>]
(kthread+0x144/0x180)
[ 76.718139] [<801467d8>] (kthread) from [<80100150>] (ret_from_fork+0x14/0x24)
[ 76.725380] Exception stack(0x84113fb0 to 0x84113ff8)
[ 76.730443] 3fa0:
[ 76.738632] 3fc0:
[ 76.746819] 3fe0: 0013
[ 76.753448] Code: eae0 eb081505 e2503000 012fff1e (e5932028)
[ 76.761647] ---[ end trace 05b398f82b2a04b9 ]---
watchdog: pcf2127: systemd fails on 5.11
Hi, After updating the kernel from 5.8.17 to 5.11 systemd (246.6) is unable to init watchdog in pcf2127 during boot. Kernel option CONFIG_WATCHDOG_OPEN_TIMEOUT=300 is working as expected. It's possible to get watchdog from userspace working in the following 2 ways. 1) Disable watchdog in systemd and use busybox watchdog. 2) Restart systemd after boot with "kill 1". During boot setting the system clock from RTC is working. RTC read/write from userland with hwclock is also working. DTS: imx7d-flex-concentrator-mfg.dts SOC: NXP i.MX7D Drivers: rtc-pcf2127, spi-imx Communication: SPI There are no patches applied to the kernel. When systemd changes watchdog timeout it receives an error that to our best knowledge comes from spi-imx[1]. We suspect it's a race condition between drivers or incompatible error handling. Any help in investigating the issue is appreciated. /Bruno [1] https://elixir.bootlin.com/linux/v5.11/source/drivers/spi/spi-imx.c#L1424 Relevant boot trace of pcf2127 and systemd: Feb 18 09:26:46 tqma7 kernel: rtc-pcf2127-spi spi1.0: pcf2127_probe Feb 18 09:26:46 tqma7 kernel: rtc-pcf2127-spi spi1.0: pcf2127_rtc_read_time: raw data is cr3=08, sec=37, min=26, hr=09, mday=18, wday=04, mon=02, year=21 Feb 18 09:26:46 tqma7 kernel: rtc-pcf2127-spi spi1.0: pcf2127_rtc_read_time: tm is secs=37, mins=26, hours=9, mday=18, mon=1, year=121, wday=4 Feb 18 09:26:46 tqma7 kernel: rtc-pcf2127-spi spi1.0: char device (252:0) Feb 18 09:26:46 tqma7 kernel: rtc-pcf2127-spi spi1.0: registered as rtc0 Feb 18 09:26:46 tqma7 kernel: rtc-pcf2127-spi spi1.0: pcf2127_rtc_read_time: raw data is cr3=08, sec=37, min=26, hr=09, mday=18, wday=04, mon=02, year=21 Feb 18 09:26:46 tqma7 kernel: rtc-pcf2127-spi spi1.0: pcf2127_rtc_read_time: tm is secs=37, mins=26, hours=9, mday=18, mon=1, year=121, wday=4 Feb 18 09:26:46 tqma7 kernel: rtc-pcf2127-spi spi1.0: setting system clock to 2021-02-18T09:26:37 UTC (1613640397) Feb 18 09:26:46 tqma7 kernel: rtc-pcf2127-spi spi1.0: I/O Error in PIO Feb 18 09:26:46 tqma7 kernel: rtc-pcf2127-spi spi1.0: SPI transfer failed: -110 Feb 18 09:26:46 tqma7 kernel: spi_master spi1: failed to transfer one message from queue Feb 18 09:26:46 tqma7 kernel: rtc-pcf2127-spi spi1.0: I/O Error in PIO Feb 18 09:26:46 tqma7 kernel: rtc-pcf2127-spi spi1.0: SPI transfer failed: -110 Feb 18 09:26:46 tqma7 kernel: spi_master spi1: failed to transfer one message from queue Feb 18 09:26:46 tqma7 systemd[1]: Hardware watchdog 'NXP PCF2127/PCF2129 Watchdog', version 0 Feb 18 09:26:46 tqma7 kernel: rtc-pcf2127-spi spi1.0: new watchdog timeout: 120s (old: 60s) Feb 18 09:26:46 tqma7 kernel: rtc-pcf2127-spi spi1.0: I/O Error in PIO Feb 18 09:26:46 tqma7 kernel: rtc-pcf2127-spi spi1.0: SPI transfer failed: -110 Feb 18 09:26:46 tqma7 kernel: spi_master spi1: failed to transfer one message from queue Feb 18 09:26:46 tqma7 kernel: rtc-pcf2127-spi spi1.0: pcf2127_wdt_active_ping: watchdog restart failed, ret=-110 Feb 18 09:26:46 tqma7 systemd[1]: Failed to set timeout to 120s: Connection timed out Relevant trace after systemd restart (kill 1): Feb 02 10:42:39 tqma7 kernel: watchdog: watchdog0: nowayout prevents watchdog being stopped! Feb 02 10:42:39 tqma7 kernel: watchdog: watchdog0: nowayout prevents watchdog being stopped! Feb 02 10:42:39 tqma7 kernel: watchdog: watchdog0: watchdog did not stop! Feb 02 10:42:39 tqma7 systemd[1]: systemd 246.6 running in system mode. (-PAM -AUDIT -SELINUX -IMA -APPARMOR -SMACK -SYSVINIT -UTMP -LIBCRYPTSETUP -GCRYPT -GNUTLS -ACL +XZ -LZ4 +ZSTD +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 -IDN -PCRE2 default-hierarchy=unified) Feb 02 10:42:39 tqma7 systemd[1]: Detected architecture arm. Feb 02 10:42:40 tqma7 systemd[1]: Hardware watchdog 'NXP PCF2127/PCF2129 Watchdog', version 0 Feb 02 10:42:40 tqma7 kernel: rtc-pcf2127-spi spi1.0: new watchdog timeout: 30s (old: 30s) Feb 02 10:42:40 tqma7 systemd[1]: Set hardware watchdog to 30s.
usb: cdc-acm: BUG kmalloc-128 Poison overwritten
Hi,
I have been experience random kernel oops in the cdc-acm driver on
imx7 (arm arch). Normally it happens during the first 1-3min runtime
after power-on. Below oops is from 5.8.17 mainline kernel with an
extra patch back-ported in an attempt to fix it:
38203b8385 ("usb: cdc-acm: fix cooldown mechanism")
Output from kconfig_hardened_check in version 2020-10-30-g2f8e7a4dc57a
has been included below oops as it might be related to the hardened kernel.
Currently I cannot update to latest mainline kernel as our board
isn't able to boot due to SPI errors on ecspi4 in versions 5.9-5.11rc6.
I am trying to bisect that issue, but I can still apply test patches if
anyone has an idea to why this is happening.
[ 55.065305] 8<--- cut here ---
[ 55.068392] Unable to handle kernel paging request at virtual
address 6b6b6c03
[ 55.075624] pgd = be866494
[ 55.078335] [6b6b6c03] *pgd=
[ 55.081924] Internal error: Oops: 5 [#1] PREEMPT SMP ARM
[ 55.087238] Modules linked in: ppp_async crc_ccitt ppp_generic slhc
xt_TCPMSS xt_tcpmss xt_hl nf_log_ipv6 nf_log_ipv4 nf_log_common
xt_policy xt_limit xt_conntrack xt_tcpudp xt_pkttype ip6table_mangle
iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4
iptable_mangle ip6table_filter ip6_tables iptable_filter ip_tables
des_generic md5 sch_fq_codel cdc_mbim cdc_wdm cdc_ncm usbnet mii
cdc_acm usb_storage ip_tunnel xfrm_user xfrm6_tunnel tunnel6
xfrm4_tunnel tunnel4 esp6 esp4 ah6 ah4 xfrm_algo xt_LOG xt_LED
xt_comment x_tables ipv6
[ 55.134954] CPU: 0 PID: 82 Comm: kworker/0:2 Tainted: G
T 5.8.17 #1
[ 55.142526] Hardware name: Freescale i.MX7 Dual (Device Tree)
[ 55.148304] Workqueue: events acm_softint [cdc_acm]
[ 55.153196] PC is at kobject_get+0x10/0xa4
[ 55.157302] LR is at usb_get_dev+0x14/0x1c
[ 55.161402] pc : [<8047c06c>]lr : [<80560448>]psr: 2193
[ 55.167671] sp : bca39ea8 ip : 7374 fp : bf6cbd80
[ 55.172899] r10: r9 : bdd92284 r8 : bdd92008
[ 55.178128] r7 : 6b6b6b6b r6 : fffe r5 : 6113 r4 : 6b6b6be3
[ 55.184658] r3 : 6b6b6b6b r2 : 0111 r1 : r0 : 6b6b6be3
[ 55.191191] Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM
Segment none
[ 55.198417] Control: 10c5387d Table: bcf0c06a DAC: 0051
[ 55.204168] Process kworker/0:2 (pid: 82, stack limit = 0x9bdd2a89)
[ 55.210439] Stack: (0xbca39ea8 to 0xbca3a000)
[ 55.214805] 9ea0: bf6cbd80 80769a50 6b6b6b6b
80560448 bdeb0500 8056bfe8
[ 55.222991] 9ec0: 0002 b76da000 bdeb0500 bdd92448
bca38000 bdeb0510 8056d69c
[ 55.231177] 9ee0: bca38000 80c050fc bca39f44
09d42015 0001
[ 55.239363] 9f00: bdd92448 bdd92438 bdd92000 7f1158c4 bdd92448
bca2ee00 bf6cbd80 bf6cef00
[ 55.247549] 9f20: 801412d8 bf6cbd98
80c03d00 bca2ee00 bf6cbd80
[ 55.255735] 9f40: bca2ee14 bf6cbd98 80c03d00 0008 bca38000
80141568 80c446ae
[ 55.263921] 9f60: bc9ed880 bc9f0700 bca38000 bc117eb4
80141524 bca2ee00 bc9ed8a4
[ 55.272107] 9f80: 80147cc8 bc9f0700 80147b84
[ 55.280292] 9fa0: 80100148
[ 55.288477] 9fc0:
[ 55.296662] 9fe0: 0013
[ 55.304860] [<8047c06c>] (kobject_get) from [<80560448>]
(usb_get_dev+0x14/0x1c)
[ 55.312271] [<80560448>] (usb_get_dev) from [<8056bfe8>]
(usb_hcd_unlink_urb+0x50/0xd8)
[ 55.320286] [<8056bfe8>] (usb_hcd_unlink_urb) from [<8056d69c>]
(usb_kill_urb.part.0+0x44/0xd0)
[ 55.329004] [<8056d69c>] (usb_kill_urb.part.0) from [<7f1158c4>]
(acm_softint+0x4c/0x10c [cdc_acm])
[ 55.338082] [<7f1158c4>] (acm_softint [cdc_acm]) from [<801412d8>]
(process_one_work+0x19c/0x3e8)
[ 55.346969] [<801412d8>] (process_one_work) from [<80141568>]
(worker_thread+0x44/0x4dc)
[ 55.355072] [<80141568>] (worker_thread) from [<80147cc8>]
(kthread+0x144/0x180)
[ 55.362481] [<80147cc8>] (kthread) from [<80100148>]
(ret_from_fork+0x14/0x2c)
[ 55.369706] Exception stack(0xbca39fb0 to 0xbca39ff8)
[ 55.374764] 9fa0:
[ 55.382949] 9fc0:
[ 55.391133] 9fe0: 0013
[ 55.397757] Code: e92d4010 e2504000 e24dd008 0a0e (e5d43020)
[ 55.403857] ---[ end trace 1ec2a82c3635d550 ]---
[ 55.408479] note: kworker/0:2[82] exited with preempt_count 1
[ 60.237377]
=
[ 60.245593] BUG kmalloc-128 (Tainted: G D T): Poison overwritten
[ 60.252737]
-
[ 60.252737]
[ 60.262402] INFO: 0xa0093f52-0xa0093f52 @offset=1296.
[PATCH] ARM: dts: imx7d-flex-concentrator: fix pcf2127 reset
RTC pcf2127 device driver has changed default behaviour of the watchdog
feature in v5.11-rc1. Now you need to explicitly enable it with a
device tree property, "reset-source", when used in the board design.
Fixes: 71ac13457d9d ("rtc: pcf2127: only use watchdog when explicitly
available")
Signed-off-by: Bruno Thomsen
Cc: Bruno Thomsen
Cc: Uwe Kleine-König
Cc: Rasmus Villemoes
Cc: Alexandre Belloni
---
arch/arm/boot/dts/imx7d-flex-concentrator.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/imx7d-flex-concentrator.dts
b/arch/arm/boot/dts/imx7d-flex-concentrator.dts
index 84b095279e65..bd6b5285aa8d 100644
--- a/arch/arm/boot/dts/imx7d-flex-concentrator.dts
+++ b/arch/arm/boot/dts/imx7d-flex-concentrator.dts
@@ -115,6 +115,7 @@ pcf2127: rtc@0 {
compatible = "nxp,pcf2127";
reg = <0>;
spi-max-frequency = <200>;
+ reset-source;
};
};
base-commit: 7c53f6b671f4aba70ff15e1b05148b10d58c2837
--
2.29.2
[PATCH v4 2/2] ARM: dts: imx7: add support for kamstrup flex concentrator
This adds support for the OMNIA Flex Concentrator product
from Kamstrup A/S. It's providing radio mesh communication
infrastructure for smart electricity meters.
Kamstrup OMNIA is a modular and scalable smart grid platform.
Signed-off-by: Bruno Thomsen
---
Thanks for v3 review Shawn Guo.
Changes since version 3:
- Removed "kam,imx7d-flex-concentrator" from compatible in mfg dts.
- Changed hmi-{b,c,d}-{red,green} to led-{0,1,2,3,4,5}.
- Removed 'default-state = "off"' as that is already default.
- Added heartbeat trigger on led-1.
- Updated gpio-leds labels.
- Added over-current-active-low in usbotg2.
- Don't delete m24c64 EEPROM node as TQ is unable to manufacture
modules without it.
Changes since version 2:
- Found root cause of Ethernet PHY auto detect issue and created
a mdio patch series that resolves the issue.
https://lore.kernel.org/netdev/20200730195749.4922-1-bruno.thom...@gmail.com/
- Ethernet PHY reset is using new MDIO bus reset.
- Ethernet PHY interrupt added.
- Removed SION from a few GPIOs used for Ethernet PHY.
Changes since version 1:
- Sorted labeling nodes.
- Sorted pinctrl entries.
- Removed deprecated fec phy reset properties.
- Added mdio phy reset properties.
- Disabled phy type auto detection and added note to commit message.
- Fixed two comment typos.
arch/arm/boot/dts/Makefile| 2 +
.../boot/dts/imx7d-flex-concentrator-mfg.dts | 25 ++
arch/arm/boot/dts/imx7d-flex-concentrator.dts | 314 ++
3 files changed, 341 insertions(+)
create mode 100644 arch/arm/boot/dts/imx7d-flex-concentrator-mfg.dts
create mode 100644 arch/arm/boot/dts/imx7d-flex-concentrator.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index ce66ffd5a1bb..937799614364 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -641,6 +641,8 @@ dtb-$(CONFIG_SOC_IMX7D) += \
imx7d-colibri-emmc-aster.dtb \
imx7d-colibri-emmc-eval-v3.dtb \
imx7d-colibri-eval-v3.dtb \
+ imx7d-flex-concentrator.dtb \
+ imx7d-flex-concentrator-mfg.dtb \
imx7d-mba7.dtb \
imx7d-meerkat96.dtb \
imx7d-nitrogen7.dtb \
diff --git a/arch/arm/boot/dts/imx7d-flex-concentrator-mfg.dts
b/arch/arm/boot/dts/imx7d-flex-concentrator-mfg.dts
new file mode 100644
index ..a6d68165fb1e
--- /dev/null
+++ b/arch/arm/boot/dts/imx7d-flex-concentrator-mfg.dts
@@ -0,0 +1,25 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree Source for Kamstrup OMNIA Flex Concentrator in
+ * manufacturing/debugging mode.
+ *
+ * Copyright (C) 2020 Kamstrup A/S
+ * Author: Bruno Thomsen
+ */
+
+/dts-v1/;
+
+#include "imx7d-flex-concentrator.dts"
+
+/ {
+ model = "Kamstrup OMNIA Flex Concentrator - Manufacturing";
+ compatible = "kam,imx7d-flex-concentrator-mfg", "fsl,imx7d";
+
+ chosen {
+ stdout-path =
+ };
+};
+
+ {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/imx7d-flex-concentrator.dts
b/arch/arm/boot/dts/imx7d-flex-concentrator.dts
new file mode 100644
index ..84b095279e65
--- /dev/null
+++ b/arch/arm/boot/dts/imx7d-flex-concentrator.dts
@@ -0,0 +1,314 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree Source for Kamstrup OMNIA Flex Concentrator.
+ *
+ * Copyright (C) 2020 Kamstrup A/S
+ * Author: Bruno Thomsen
+ */
+
+/dts-v1/;
+
+#include "imx7d-tqma7.dtsi"
+
+/* One I2C device on TQMa7 SoM is not mounted */
+/delete-node/
+
+/ {
+ model = "Kamstrup OMNIA Flex Concentrator";
+ compatible = "kam,imx7d-flex-concentrator", "fsl,imx7d";
+
+ memory@8000 {
+ device_type = "memory";
+ /* 1024 MB - TQMa7D board configuration */
+ reg = <0x8000 0x4000>;
+ };
+
+ reg_usb_otg2_vbus: regulator-usb-otg2-vbus {
+ compatible = "regulator-fixed";
+ regulator-name = "VBUS_USBOTG2";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ gpio = < 7 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ reg_vref_1v8: regulator-vref-1v8 {
+ compatible = "regulator-fixed";
+ regulator-name = "VCC1V8_REF";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ regulator-always-on;
+ vin-supply = <_reg>;
+ };
+
+ /*
+* Human Machine Interface consists of 4 dual red/green LEDs.
+* hmi-a:green is controlled directly by the switch-mode power supply.
+* hmi-a:red is not used.
+*/
+ gpio-leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+
[PATCH v4 1/2] dt-bindings: fsl: add kamstrup flex concentrator to schema
Add Kamstrup OMNIA Flex Concentrator compatibles to the schema so we can make use of them for the validation. Signed-off-by: Bruno Thomsen Acked-by: Rob Herring --- Changes since version 3: - Rebase patch to v5.10-rc4. No changes since version 2. Changes since version 1: - Patch prefix renamed to "dt-bindings: fsl:" - Added acked-by from Rob Herring. - Fixed typo in commit message. Documentation/devicetree/bindings/arm/fsl.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml index 934289446abb..a5eb9fb68209 100644 --- a/Documentation/devicetree/bindings/arm/fsl.yaml +++ b/Documentation/devicetree/bindings/arm/fsl.yaml @@ -362,6 +362,8 @@ properties: - enum: - fsl,imx7d-sdb # i.MX7 SabreSD Board - fsl,imx7d-sdb-reva# i.MX7 SabreSD Rev-A Board + - kam,imx7d-flex-concentrator # Kamstrup OMNIA Flex Concentrator + - kam,imx7d-flex-concentrator-mfg # Kamstrup OMNIA Flex Concentrator in manufacturing mode - novtech,imx7d-meerkat96 # i.MX7 Meerkat96 Board - technexion,imx7d-pico-dwarf # TechNexion i.MX7D Pico-Dwarf - technexion,imx7d-pico-hobbit # TechNexion i.MX7D Pico-Hobbit base-commit: 09162bc32c880a791c6c0668ce0745cf7958f576 -- 2.28.0
Re: PHY reset question
Hi Fabio and Oleksij
Den ons. 7. okt. 2020 kl. 11.50 skrev Fabio Estevam :
>
> Hi Oleksij,
>
> On Tue, Oct 6, 2020 at 5:05 AM Oleksij Rempel wrote:
> >
> > Hello PHY experts,
> >
> > Short version:
> > what is the proper way to handle the PHY reset before identifying PHY?
> >
> > Long version:
> > I stumbled over following issue:
> > If PHY reset is registered within PHY node. Then, sometimes, we will not be
> > able to identify it (read PHY ID), because PHY is under reset.
> >
> > mdio {
> > compatible = "virtual,mdio-gpio";
> >
> > [...]
> >
> > /* Microchip KSZ8081 */
> > usbeth_phy: ethernet-phy@3 {
> > reg = <0x3>;
> >
> > interrupts-extended = < 12 IRQ_TYPE_LEVEL_LOW>;
> > reset-gpios = < 11 GPIO_ACTIVE_LOW>;
> > reset-assert-us = <500>;
> > reset-deassert-us = <1000>;
> > };
> >
> > [...]
> > };
> >
> > On simple boards with one PHY per MDIO bus, it is easy to workaround by
> > using
> > phy-reset-gpios withing MAC node (illustrated in below DT example), instead
> > of
> > using reset-gpios within PHY node (see above DT example).
> >
> > {
> > [...]
> > phy-mode = "rmii";
> > phy-reset-gpios = < 12 GPIO_ACTIVE_LOW>;
> > [...]
>
> I thought this has been fixed by Bruno's series:
> https://www.spinics.net/lists/netdev/msg673611.html
Yes, that has fixed the Microchip/Micrel PHY ID auto detection
issue. I have send a DTS patch v3 that makes use of the newly
added device tree parameter:
https://lkml.org/lkml/2020/9/23/595
/Bruno
Re: [PATCH 2/2] [RFC] rtc: pcf2127: only use watchdog when explicitly available
Den tor. 24. sep. 2020 kl. 12.53 skrev Uwe Kleine-König : > > Most boards using the pcf2127 chip (in my bubble) don't make use of the > watchdog functionality and the respective output is not connected. The > effect on such a board is that there is a watchdog device provided that > doesn't work. > > So only register the watchdog if the device tree has a "has-watchdog" > property. > > Signed-off-by: Uwe Kleine-König > --- > drivers/rtc/rtc-pcf2127.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/rtc/rtc-pcf2127.c b/drivers/rtc/rtc-pcf2127.c > index 5b1f1949b5e5..8bd89d641578 100644 > --- a/drivers/rtc/rtc-pcf2127.c > +++ b/drivers/rtc/rtc-pcf2127.c > @@ -340,7 +340,8 @@ static int pcf2127_watchdog_init(struct device *dev, > struct pcf2127 *pcf2127) > u32 wdd_timeout; > int ret; > > - if (!IS_ENABLED(CONFIG_WATCHDOG)) > + if (!IS_ENABLED(CONFIG_WATCHDOG) || > + !device_property_read_bool(dev, "has-watchdog")) > return 0; I don't think the compiler can remove the function if CONFIG_WATCHDOG is disabled due to the device tree value check. Maybe it can if split into 2 conditions. if (!IS_ENABLED(CONFIG_WATCHDOG)) return 0; if (!device_property_read_bool(dev, "has-watchdog")) return 0; /Bruno > > pcf2127->wdd.parent = dev; > -- > 2.28.0 >
Re: [PATCH 1/2] rtc: pcf2127: move watchdog initialisation to a separate function
Den tor. 24. sep. 2020 kl. 12.53 skrev Uwe Kleine-König
:
>
> The obvious advantages are:
>
> - The linker can drop the watchdog functions if CONFIG_WATCHDOG is off.
> - All watchdog stuff grouped together with only a single function call
>left in generic code.
> - Watchdog register is only read when it is actually used.
> - Less #ifdefery
>
> Signed-off-by: Uwe Kleine-König
> ---
> drivers/rtc/rtc-pcf2127.c | 56 ++-
> 1 file changed, 31 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/rtc/rtc-pcf2127.c b/drivers/rtc/rtc-pcf2127.c
> index ed6316992cbb..5b1f1949b5e5 100644
> --- a/drivers/rtc/rtc-pcf2127.c
> +++ b/drivers/rtc/rtc-pcf2127.c
> @@ -335,6 +335,36 @@ static const struct watchdog_ops pcf2127_watchdog_ops = {
> .set_timeout = pcf2127_wdt_set_timeout,
> };
>
> +static int pcf2127_watchdog_init(struct device *dev, struct pcf2127 *pcf2127)
> +{
> + u32 wdd_timeout;
> + int ret;
> +
> + if (!IS_ENABLED(CONFIG_WATCHDOG))
> + return 0;
> +
> + pcf2127->wdd.parent = dev;
> + pcf2127->wdd.info = _wdt_info;
> + pcf2127->wdd.ops = _watchdog_ops;
> + pcf2127->wdd.min_timeout = PCF2127_WD_VAL_MIN;
> + pcf2127->wdd.max_timeout = PCF2127_WD_VAL_MAX;
> + pcf2127->wdd.timeout = PCF2127_WD_VAL_DEFAULT;
> + pcf2127->wdd.min_hw_heartbeat_ms = 500;
> + pcf2127->wdd.status = WATCHDOG_NOWAYOUT_INIT_STATUS;
> +
> + watchdog_set_drvdata(>wdd, pcf2127);
> +
> + /* Test if watchdog timer is started by bootloader */
> + ret = regmap_read(pcf2127->regmap, PCF2127_REG_WD_VAL, _timeout);
> + if (ret)
> + return ret;
> +
> + if (wdd_timeout)
> + set_bit(WDOG_HW_RUNNING, >wdd.status);
> +
> + return devm_watchdog_register_device(dev, >wdd);
> +}
> +
> /* Alarm */
> static int pcf2127_rtc_read_alarm(struct device *dev, struct rtc_wkalrm
> *alrm)
> {
> @@ -536,7 +566,6 @@ static int pcf2127_probe(struct device *dev, struct
> regmap *regmap,
> int alarm_irq, const char *name, bool has_nvmem)
> {
> struct pcf2127 *pcf2127;
> - u32 wdd_timeout;
> int ret = 0;
>
> dev_dbg(dev, "%s\n", __func__);
> @@ -575,17 +604,6 @@ static int pcf2127_probe(struct device *dev, struct
> regmap *regmap,
> pcf2127->rtc->ops = _rtc_alrm_ops;
> }
>
> - pcf2127->wdd.parent = dev;
> - pcf2127->wdd.info = _wdt_info;
> - pcf2127->wdd.ops = _watchdog_ops;
> - pcf2127->wdd.min_timeout = PCF2127_WD_VAL_MIN;
> - pcf2127->wdd.max_timeout = PCF2127_WD_VAL_MAX;
> - pcf2127->wdd.timeout = PCF2127_WD_VAL_DEFAULT;
> - pcf2127->wdd.min_hw_heartbeat_ms = 500;
> - pcf2127->wdd.status = WATCHDOG_NOWAYOUT_INIT_STATUS;
> -
> - watchdog_set_drvdata(>wdd, pcf2127);
> -
> if (has_nvmem) {
> struct nvmem_config nvmem_cfg = {
> .priv = pcf2127,
> @@ -615,19 +633,7 @@ static int pcf2127_probe(struct device *dev, struct
> regmap *regmap,
> return ret;
> }
>
> - /* Test if watchdog timer is started by bootloader */
> - ret = regmap_read(pcf2127->regmap, PCF2127_REG_WD_VAL, _timeout);
> - if (ret)
> - return ret;
> -
> - if (wdd_timeout)
> - set_bit(WDOG_HW_RUNNING, >wdd.status);
> -
> -#ifdef CONFIG_WATCHDOG
> - ret = devm_watchdog_register_device(dev, >wdd);
> - if (ret)
> - return ret;
> -#endif /* CONFIG_WATCHDOG */
> + pcf2127_watchdog_init(dev, pcf2127);
The code refactoring seems like a good idea Uwe, but the new
pcf2127_watchdog_init() is not a void function. If the return
value is not handled, it will change driver behavior. Correct
handling should look like this:
ret = pcf2127_watchdog_init(dev, pcf2127);
if (ret)
return ret;
/Bruno
> /*
> * Disable battery low/switch-over timestamp and interrupts.
> --
> 2.28.0
>
Re: [Patch v2 1/3] dt-bindings: rtc: pcf2127: Add bindings for nxp,pcf2127
Den tor. 24. sep. 2020 kl. 09.47 skrev Alexandre Belloni : > > Hi, > > On 24/09/2020 07:23:18+, Qiang Zhao wrote: > > > > Yes, you are right, There is not a fundamental solution. > > > > However it somewhat avoid this situation at least. > > > > > > > > And if without this issue, > > > > is it correct to register a rtc device as watchdog no matter it is used > > > > as > > > watchdog on the board? > > > > Every time Linux are booted up, watchdog device should be configured to > > > > the > > > right one manually. > > > > So the patch are useful, even though it is not for the issue. > > > > > > > > What should we do to really resolve this issue? > > > > > > I still think we need a kernel solution here. I would expect that most > > > assembled > > > pcf2127 chips are unable to act as a watchdog (i.e. don't have the RST > > > output > > > connected to something that resets the machine). > > > > > > So my favoured solution would be a positive property like: > > > > > > has-watchdog; > > > > > > or something similar. In my eyes this is definitely something we want to > > > specify > > > in the device tree because it is a relevant hardware property. > > > I consider it a bug to give a watchdog device to userspace that isn't > > > functional. > > > > > > Best regards > > > Uwe > > > > I strongly agree with you! It should be positive property. > > However, we couldn't identify which board are using pcf2127 as watchdog, > > So we are unable to modify the boards' dts to correct (watchdog or not) in > > this patchset. > > > > I noticed that only LS series platforms and imx6 have pcf2127 node, as far > > as I know, the LS platforms don't use it as watchdog, > > But I am not sure about imx6 > > > > I don't think there is any user upstream and it is recent engouh that we > can probably make that a positive property. > > Bruno, is it ok for you? you are the only know user of the feature. Hi This seems like an okay solution to me. I have a patch series on the way with a new product dts[1] that is using the watchdog feature in the pcf2127 chip. I know that the watchdog feature is used by other products with out-of-tree dts, but I will make sure to give them a heads up. /Bruno [1] https://lore.kernel.org/linux-arm-kernel/20200923154024.11417-2-bruno.thom...@gmail.com/
[PATCH v3 2/2] ARM: dts: imx7: add support for kamstrup flex concentrator
This adds support for the OMNIA Flex Concentrator product
from Kamstrup A/S. It's providing radio mesh communication
infrastructure for smart electricity meters.
Kamstrup OMNIA is a modular and scalable smart grid platform.
Signed-off-by: Bruno Thomsen
---
Changes since version 2:
- Found root cause of Ethernet PHY auto detect issue and created
a mdio patch series that resolves the issue.
https://lore.kernel.org/netdev/20200730195749.4922-1-bruno.thom...@gmail.com/
- Ethernet PHY reset is using new MDIO bus reset.
- Ethernet PHY interrupt added.
- Removed SION from a few GPIOs used for Ethernet PHY.
Changes since version 1:
- Sorted labeling nodes.
- Sorted pinctrl entries.
- Removed deprecated fec phy reset properties.
- Added mdio phy reset properties.
- Disabled phy type auto detection and added note to commit message.
- Fixed two comment typos.
arch/arm/boot/dts/Makefile| 2 +
.../boot/dts/imx7d-flex-concentrator-mfg.dts | 25 ++
arch/arm/boot/dts/imx7d-flex-concentrator.dts | 319 ++
3 files changed, 346 insertions(+)
create mode 100644 arch/arm/boot/dts/imx7d-flex-concentrator-mfg.dts
create mode 100644 arch/arm/boot/dts/imx7d-flex-concentrator.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 4572db3fa5ae..15be5a2fe831 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -634,6 +634,8 @@ dtb-$(CONFIG_SOC_IMX7D) += \
imx7d-colibri-emmc-aster.dtb \
imx7d-colibri-emmc-eval-v3.dtb \
imx7d-colibri-eval-v3.dtb \
+ imx7d-flex-concentrator.dtb \
+ imx7d-flex-concentrator-mfg.dtb \
imx7d-mba7.dtb \
imx7d-meerkat96.dtb \
imx7d-nitrogen7.dtb \
diff --git a/arch/arm/boot/dts/imx7d-flex-concentrator-mfg.dts
b/arch/arm/boot/dts/imx7d-flex-concentrator-mfg.dts
new file mode 100644
index ..789f0837058f
--- /dev/null
+++ b/arch/arm/boot/dts/imx7d-flex-concentrator-mfg.dts
@@ -0,0 +1,25 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree Source for Kamstrup OMNIA Flex Concentrator in
+ * manufacturing/debugging mode.
+ *
+ * Copyright (C) 2020 Kamstrup A/S
+ * Author: Bruno Thomsen
+ */
+
+/dts-v1/;
+
+#include "imx7d-flex-concentrator.dts"
+
+/ {
+ model = "Kamstrup OMNIA Flex Concentrator - Manufacturing";
+ compatible = "kam,imx7d-flex-concentrator-mfg",
"kam,imx7d-flex-concentrator", "fsl,imx7d";
+
+ chosen {
+ stdout-path =
+ };
+};
+
+ {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/imx7d-flex-concentrator.dts
b/arch/arm/boot/dts/imx7d-flex-concentrator.dts
new file mode 100644
index ..9f73c79253cb
--- /dev/null
+++ b/arch/arm/boot/dts/imx7d-flex-concentrator.dts
@@ -0,0 +1,319 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree Source for Kamstrup OMNIA Flex Concentrator.
+ *
+ * Copyright (C) 2020 Kamstrup A/S
+ * Author: Bruno Thomsen
+ */
+
+/dts-v1/;
+
+#include "imx7d-tqma7.dtsi"
+
+/* Some I2C devices on TQMa7 SoM are not mounted */
+/delete-node/
+/delete-node/
+
+/ {
+ model = "Kamstrup OMNIA Flex Concentrator";
+ compatible = "kam,imx7d-flex-concentrator", "fsl,imx7d";
+
+ memory@8000 {
+ device_type = "memory";
+ /* 1024 MB - TQMa7D board configuration */
+ reg = <0x8000 0x4000>;
+ };
+
+ reg_usb_otg2_vbus: regulator-usb-otg2-vbus {
+ compatible = "regulator-fixed";
+ regulator-name = "VBUS_USBOTG2";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ gpio = < 7 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ reg_vref_1v8: regulator-vref-1v8 {
+ compatible = "regulator-fixed";
+ regulator-name = "VCC1V8_REF";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ regulator-always-on;
+ vin-supply = <_reg>;
+ };
+
+ /*
+* Human Machine Interface consists of 4 dual red/green LEDs.
+* hmi-a-green is controlled directly by the switch-mode power supply.
+* hmi-a-red is not used.
+*/
+ gpio-leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <_leds>;
+
+ hmi-b-red {
+ label = "hmi-b:red:provisioning";
+ gpios = < 6 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ };
+
+ hmi-b-green {
+ label = "hmi-b:green:operation";
+
[PATCH v3 1/2] dt-bindings: fsl: add kamstrup flex concentrator to schema
Add Kamstrup OMNIA Flex Concentrator compatibles to the schema so we can make use of them for the validation. Signed-off-by: Bruno Thomsen Acked-by: Rob Herring --- No changes since version 2. Changes since version 1: - Patch prefix renamed to "dt-bindings: fsl:" - Added acked-by from Rob Herring. - Fixed typo in commit message. Documentation/devicetree/bindings/arm/fsl.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml index 6da9d734cdb7..8e9be78f3d68 100644 --- a/Documentation/devicetree/bindings/arm/fsl.yaml +++ b/Documentation/devicetree/bindings/arm/fsl.yaml @@ -304,6 +304,8 @@ properties: - enum: - fsl,imx7d-sdb # i.MX7 SabreSD Board - fsl,imx7d-sdb-reva# i.MX7 SabreSD Rev-A Board + - kam,imx7d-flex-concentrator # Kamstrup OMNIA Flex Concentrator + - kam,imx7d-flex-concentrator-mfg # Kamstrup OMNIA Flex Concentrator in manufacturing mode - novtech,imx7d-meerkat96 # i.MX7 Meerkat96 Board - technexion,imx7d-pico-dwarf # TechNexion i.MX7D Pico-Dwarf - technexion,imx7d-pico-hobbit # TechNexion i.MX7D Pico-Hobbit base-commit: 805c6d3c19210c90c109107d189744e960eae025 -- 2.26.2
Re: [PATCH 1/3] dt-bindings: rtc-2127: Add bindings for nxp,rtc-2127.txt
Den man. 14. sep. 2020 kl. 09.08 skrev Qiang Zhao : > > On Fri, Sep 11, 2020 at 22:03, Rob Herring wrote: > Please help to review as below, if it is ok, I will send the new version > patch. Thank you! > > diff --git a/Documentation/devicetree/bindings/rtc/nxp,pcf2127.yaml > b/Documentation/devicetree/bindings/rtc/nxp,pcf2127.yaml > new file mode 100644 > index 000..809dd59 > --- /dev/null > +++ b/Documentation/devicetree/bindings/rtc/nxp,pcf2127.yaml > @@ -0,0 +1,38 @@ > +# SPDX-License-Identifier: GPL-2.0 > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/rtc/nxp,pcf2127.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: PCF RTCs > + > +maintainers: > + - Qiang Zhao > + > +allOf: > + - $ref: "rtc.yaml#" > + > +properties: > + compatible: > +enum: > + - nxp,pcf2127 > + - nxp,pcf2129 The device driver have 3 compatible strings, "nxp,pca2129" is missing. /Bruno > + > + reg: > +maxItems: 1 > + > + interrupts: > +maxItems: 1 > + > + no-watchdog: > +maxItems: 1 > + > + start-year: true > + > +required: > + - compatible > + - reg > + > +additionalProperties: false > + > +... > > > > > Documentation/devicetree/writing-schema.rst and about 1000 examples in the > > kernel tree. > > > > Rob
Re: [PATCH v2 2/2] ARM: dts: imx7: add support for kamstrup flex concentrator
Hi Fabio,
Den tor. 16. jul. 2020 kl. 20.01 skrev Fabio Estevam :
> On Thu, Jul 16, 2020 at 2:26 PM Bruno Thomsen wrote:
>
> > Limitations: Ethernet PHY type auto detection does not
> > work when using reset-{assert-us,deassert-us,gpios}
> > properties so it's using a fixed PHY type ID for now. Auto
> > detection worked when using the deprecated FEC properties
> > phy-reset-{gpios,duration,post-delay}.
>
> I think we need to understand this better. Why does it fail?
Yes, we need to locate the root cause.
> I gave a test on an imx6q-sabresd and the Ethernet PHY (AR8031) could
> be properly detected using reset-{assert-us,deassert-us,gpios}
> properties inside the mdio node.
Okay, thanks.
> Is this a Micrel KSZ8081 specific issue?
Maybe, I'm actually beginning to suspect that the issue might be related
to polling vs interrupt mode. As all partially related examples I have seen
uses interrupt mode and I have only configured poll mode. But the hardware
does have the interrupt signal connected to the imx7.
> Please report this issue to the Ethernet PHY folks.
I'm going to send an Ethernet PHY mail tomorrow with the details I know
at the moment. Just wanted to get an updated version of the device tree
out in case of any other issues not related to the PHY part.
/Bruno
[PATCH v2 2/2] ARM: dts: imx7: add support for kamstrup flex concentrator
This adds support for the OMNIA Flex Concentrator product
from Kamstrup A/S. It's providing radio mesh communication
infrastructure for smart electricity meters.
Kamstrup OMNIA is a modular and scalable smart grid platform.
Limitations: Ethernet PHY type auto detection does not
work when using reset-{assert-us,deassert-us,gpios}
properties so it's using a fixed PHY type ID for now. Auto
detection worked when using the deprecated FEC properties
phy-reset-{gpios,duration,post-delay}.
Signed-off-by: Bruno Thomsen
---
Changes since version 1:
- Sorted labeling nodes.
- Sorted pinctrl entries.
- Removed deprecated fec phy reset properties.
- Added mdio phy reset properties.
- Disabled phy type auto detection and added note to
commit message.
- Fixed two comment typos.
arch/arm/boot/dts/Makefile| 2 +
.../boot/dts/imx7d-flex-concentrator-mfg.dts | 25 ++
arch/arm/boot/dts/imx7d-flex-concentrator.dts | 309 ++
3 files changed, 336 insertions(+)
create mode 100644 arch/arm/boot/dts/imx7d-flex-concentrator-mfg.dts
create mode 100644 arch/arm/boot/dts/imx7d-flex-concentrator.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index e6a1cac0bfc7..bf5c5d86a2e8 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -628,6 +628,8 @@ dtb-$(CONFIG_SOC_IMX7D) += \
imx7d-colibri-emmc-aster.dtb \
imx7d-colibri-emmc-eval-v3.dtb \
imx7d-colibri-eval-v3.dtb \
+ imx7d-flex-concentrator.dtb \
+ imx7d-flex-concentrator-mfg.dtb \
imx7d-mba7.dtb \
imx7d-meerkat96.dtb \
imx7d-nitrogen7.dtb \
diff --git a/arch/arm/boot/dts/imx7d-flex-concentrator-mfg.dts
b/arch/arm/boot/dts/imx7d-flex-concentrator-mfg.dts
new file mode 100644
index ..789f0837058f
--- /dev/null
+++ b/arch/arm/boot/dts/imx7d-flex-concentrator-mfg.dts
@@ -0,0 +1,25 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree Source for Kamstrup OMNIA Flex Concentrator in
+ * manufacturing/debugging mode.
+ *
+ * Copyright (C) 2020 Kamstrup A/S
+ * Author: Bruno Thomsen
+ */
+
+/dts-v1/;
+
+#include "imx7d-flex-concentrator.dts"
+
+/ {
+ model = "Kamstrup OMNIA Flex Concentrator - Manufacturing";
+ compatible = "kam,imx7d-flex-concentrator-mfg",
"kam,imx7d-flex-concentrator", "fsl,imx7d";
+
+ chosen {
+ stdout-path =
+ };
+};
+
+ {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/imx7d-flex-concentrator.dts
b/arch/arm/boot/dts/imx7d-flex-concentrator.dts
new file mode 100644
index ..017a21be5b9b
--- /dev/null
+++ b/arch/arm/boot/dts/imx7d-flex-concentrator.dts
@@ -0,0 +1,309 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree Source for Kamstrup OMNIA Flex Concentrator.
+ *
+ * Copyright (C) 2020 Kamstrup A/S
+ * Author: Bruno Thomsen
+ */
+
+/dts-v1/;
+
+#include "imx7d-tqma7.dtsi"
+
+/* Some I2C devices on TQMa7 SoM are not mounted */
+/delete-node/
+/delete-node/
+
+/ {
+ model = "Kamstrup OMNIA Flex Concentrator";
+ compatible = "kam,imx7d-flex-concentrator", "fsl,imx7d";
+
+ memory@8000 {
+ device_type = "memory";
+ /* 1024 MB - TQMa7D board configuration */
+ reg = <0x8000 0x4000>;
+ };
+
+ reg_usb_otg2_vbus: regulator-usb-otg2-vbus {
+ compatible = "regulator-fixed";
+ regulator-name = "VBUS_USBOTG2";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ gpio = < 7 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ reg_vref_1v8: regulator-vref-1v8 {
+ compatible = "regulator-fixed";
+ regulator-name = "VCC1V8_REF";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ regulator-always-on;
+ vin-supply = <_reg>;
+ };
+
+ /*
+* Human Machine Interface consists of 4 dual red/green LEDs.
+* hmi-a-green is controlled directly by the switch-mode power supply.
+* hmi-a-red is not used.
+*/
+ gpio-leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <_leds>;
+
+ hmi-b-red {
+ label = "hmi-b:red:provisioning";
+ gpios = < 6 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ };
+
+ hmi-b-green {
+ label = "hmi-b:green:operation";
+ gpios = < 28 GPIO_ACTIVE_HIGH>;
+ default-state = &qu
[PATCH v2 1/2] dt-bindings: fsl: add kamstrup flex concentrator to schema
Add Kamstrup OMNIA Flex Concentrator compatibles to the schema so we can make use of them for the validation. Signed-off-by: Bruno Thomsen Acked-by: Rob Herring --- Changes since version 1: - Patch prefix renamed to "dt-bindings: fsl:" - Added acked-by from Rob Herring. - Fixed typo in commit message. Documentation/devicetree/bindings/arm/fsl.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml index 05906e291e38..66627b272e40 100644 --- a/Documentation/devicetree/bindings/arm/fsl.yaml +++ b/Documentation/devicetree/bindings/arm/fsl.yaml @@ -299,6 +299,8 @@ properties: - enum: - fsl,imx7d-sdb # i.MX7 SabreSD Board - fsl,imx7d-sdb-reva# i.MX7 SabreSD Rev-A Board + - kam,imx7d-flex-concentrator # Kamstrup OMNIA Flex Concentrator + - kam,imx7d-flex-concentrator-mfg # Kamstrup OMNIA Flex Concentrator in manufacturing mode - novtech,imx7d-meerkat96 # i.MX7 Meerkat96 Board - technexion,imx7d-pico-dwarf # TechNexion i.MX7D Pico-Dwarf - technexion,imx7d-pico-hobbit # TechNexion i.MX7D Pico-Hobbit base-commit: f8456690ba8eb18ea4714e68554e242a04f65cff -- 2.26.2
Re: [PATCH 2/3] ARM: dts: imx7: add support for kamstrup flex concentrator
Den tir. 14. jul. 2020 kl. 13.54 skrev Fabio Estevam : > > Hi Bruno, > > On Tue, Jul 14, 2020 at 7:03 AM Bruno Thomsen wrote: > > > I have not yet been successful in converting the deprecated properties > > to generic phy properties, so hoping I could get a hit. > > > > Kernel error messages: > > mdio_bus 30be.ethernet-1: MDIO device at address 1 is missing. > > Please double-check whether 1 is the correct address for the KSZ8051 > Ethernet PHY as per your schematics. Hi Fabio, Thanks for the hints. Yes, the address is correct and configured with external resistors, but just realised that I wrote the wrong device name in the comment, it's actually KSZ8081RNB. Ethernet has been working with multiple mainline kernel versions (latest being 5.7.8) for the last year or so when using the DTS in patch. So I am pretty sure hardware and setup of mux is correct'ish. Kernel trace from patch version: kernel: Micrel KSZ8081 or KSZ8091 30be.ethernet-1:01: attached PHY driver [Micrel KSZ8081 or KSZ8091] (mii_bus:phy_addr=30be.ethernet-1:01, irq=POLL) Error first occurs when switching from fec phy reset to mdio phy reset code path, I understand that the fec phy reset is obsolete as phy properties was wrongly added to the mac and of course should be part of the phy (separate chip). When debugging it I end up with the get_phy_device() call not working inside of_mdiobus_register_phy(). Workaround at the moment seems to be extending compatible with "ethernet-phy-id0022.1560" to disable auto detection of phy type, and then Ethernet works again. At least the same PHY driver trace can be found and full transmission speed can be used without packet errors/loss. > Are there external pull-up/pull-down resistors for strapping the > various configuration pins for the PHY? Or are the pull-up/pull-down > provided by the i.MX7D pins? Config strapping is done with external resistors. > If there are no external pull-ups, please make sure to configure the > pinctrl_enet1 accordingly, so that the Ethernet PHY address can be > properly configured and then mdio_bus driver can find it at the > correct address. > > Please check in arch/arm/boot/dts/imx6qdl-sr-som.dtsi for an example > on how to configure the Ethernet PHY pin strapping via iMX IOMUX. Thanks, good examples can be hard to find. /Bruno
Re: [PATCH 2/3] ARM: dts: imx7: add support for kamstrup flex concentrator
Den man. 13. jul. 2020 kl. 04.52 skrev Shawn Guo :
>
> On Mon, Jun 29, 2020 at 01:49:26PM +0200, Bruno Thomsen wrote:
> > + {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <_enet1>;
> > + phy-mode = "rmii";
> > + phy-reset-gpios = < 15 GPIO_ACTIVE_LOW>;
> > + phy-reset-duration = <100>;
> > + phy-reset-post-delay = <1000>;
>
> These properties are deprecated.
Thanks for review Shawn.
I have not yet been successful in converting the deprecated properties
to generic phy properties, so hoping I could get a hit.
Kernel error messages:
mdio_bus 30be.ethernet-1: MDIO device at address 1 is missing.
fec 30be.ethernet eth0: Unable to connect to phy
Updated device tree section:
{
pinctrl-names = "default";
pinctrl-0 = <_enet1>;
phy-mode = "rmii";
phy-handle = <>;
status = "okay";
mdio {
#address-cells = <1>;
#size-cells = <0>;
ethphy: ethernet-phy@1 {
/* Micrel KSZ8051RNLV */
compatible = "ethernet-phy-ieee802.3-c22";
reg = <1>;
max-speed = <100>;
reset-assert-us = <10>;
reset-deassert-us = <100>;
reset-gpios = < 15 GPIO_ACTIVE_LOW>;
};
};
};
/Bruno
> > + phy-handle = <>;
> > + status = "okay";
> > +
> > + mdio {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + ethphy: ethernet-phy@1 {
> > + /* Micrel KSZ8051RNLV */
> > + compatible = "ethernet-phy-ieee802.3-c22";
> > + reg = <1>;
> > + };
> > + };
> > +};
Re: [PATCH 3/3] MAINTAINERS: Add Bruno Thomsen as reviewer of Kamstrup DTS
Den man. 13. jul. 2020 kl. 09.26 skrev Joe Perches :
>
> On Mon, 2020-07-13 at 15:13 +0800, Shawn Guo wrote:
> > On Sun, Jul 12, 2020 at 10:22:50PM -0700, Joe Perches wrote:
> []
> > > diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
> []
> > > @@ -436,7 +436,7 @@ sub maintainers_in_file {
> > >
> > > return if ($file =~ m@\bMAINTAINERS$@);
> > >
> > > -if (-f $file && ($email_file_emails || $file =~ /\.yaml$/)) {
> > > +if (-f $file && ($email_file_emails || $file =~
> > > /\.(?:yaml|dtsi?)$/)) {
> >
> > It should cover .dts file too?
>
> It does as dtsi? means the i is optional.
It sounds like a good idea for handling dts reviewers.
Maybe we could also update script/checkpatch.pl to ignore
new dts/dtsi files and not suggest updating MAINTAINERS
file.
/Bruno
[PATCH 2/3] ARM: dts: imx7: add support for kamstrup flex concentrator
This adds support for the OMNIA Flex Concentrator product
from Kamstrup A/S. It's providing radio mesh communication
infrastructure for smart electricity meters.
Kamstrup OMNIA is a modular and scalable smart grid platform.
Signed-off-by: Bruno Thomsen
---
arch/arm/boot/dts/Makefile| 2 +
.../boot/dts/imx7d-flex-concentrator-mfg.dts | 25 ++
arch/arm/boot/dts/imx7d-flex-concentrator.dts | 307 ++
3 files changed, 334 insertions(+)
create mode 100644 arch/arm/boot/dts/imx7d-flex-concentrator-mfg.dts
create mode 100644 arch/arm/boot/dts/imx7d-flex-concentrator.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index e6a1cac0bfc7..bf5c5d86a2e8 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -628,6 +628,8 @@ dtb-$(CONFIG_SOC_IMX7D) += \
imx7d-colibri-emmc-aster.dtb \
imx7d-colibri-emmc-eval-v3.dtb \
imx7d-colibri-eval-v3.dtb \
+ imx7d-flex-concentrator.dtb \
+ imx7d-flex-concentrator-mfg.dtb \
imx7d-mba7.dtb \
imx7d-meerkat96.dtb \
imx7d-nitrogen7.dtb \
diff --git a/arch/arm/boot/dts/imx7d-flex-concentrator-mfg.dts
b/arch/arm/boot/dts/imx7d-flex-concentrator-mfg.dts
new file mode 100644
index ..789f0837058f
--- /dev/null
+++ b/arch/arm/boot/dts/imx7d-flex-concentrator-mfg.dts
@@ -0,0 +1,25 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree Source for Kamstrup OMNIA Flex Concentrator in
+ * manufacturing/debugging mode.
+ *
+ * Copyright (C) 2020 Kamstrup A/S
+ * Author: Bruno Thomsen
+ */
+
+/dts-v1/;
+
+#include "imx7d-flex-concentrator.dts"
+
+/ {
+ model = "Kamstrup OMNIA Flex Concentrator - Manufacturing";
+ compatible = "kam,imx7d-flex-concentrator-mfg",
"kam,imx7d-flex-concentrator", "fsl,imx7d";
+
+ chosen {
+ stdout-path =
+ };
+};
+
+ {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/imx7d-flex-concentrator.dts
b/arch/arm/boot/dts/imx7d-flex-concentrator.dts
new file mode 100644
index ..887135cca650
--- /dev/null
+++ b/arch/arm/boot/dts/imx7d-flex-concentrator.dts
@@ -0,0 +1,307 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree Source for Kamstrup OMNIA Flex Concentrator.
+ *
+ * Copyright (C) 2020 Kamstrup A/S
+ * Author: Bruno Thomsen
+ */
+
+/dts-v1/;
+
+#include "imx7d-tqma7.dtsi"
+
+/* Some I2C devices on TQMa7 SoM are not mounted */
+/delete-node/
+/delete-node/
+
+/ {
+ model = "Kamstrup OMNIA Flex Concentrator";
+ compatible = "kam,imx7d-flex-concentrator", "fsl,imx7d";
+
+ memory@8000 {
+ device_type = "memory";
+ /* 1024 MB - TQMa7D board configuration */
+ reg = <0x8000 0x4000>;
+ };
+
+ reg_usb_otg2_vbus: regulator-usb-otg2-vbus {
+ compatible = "regulator-fixed";
+ regulator-name = "VBUS_USBOTG2";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ gpio = < 7 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ reg_vref_1v8: regulator-vref-1v8 {
+ compatible = "regulator-fixed";
+ regulator-name = "VCC1V8_REF";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ regulator-always-on;
+ vin-supply = <_reg>;
+ };
+
+ /*
+* Human Machine Interface consists of 4 dual red/green LEDs.
+* hmi-a-green is controlled directly by the switch-mode power supply.
+* hmi-a-red is not used.
+*/
+ gpio-leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <_leds>;
+
+ hmi-b-red {
+ label = "hmi-b:red:provisioning";
+ gpios = < 6 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ };
+
+ hmi-b-green {
+ label = "hmi-b:green:operation";
+ gpios = < 28 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ };
+
+ hmi-c-red {
+ label = "hmi-c:red:mesh-error";
+ gpios = < 29 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ };
+
+ hmi-c-green {
+ label = "hmi-c:green:mesh-activity";
+ gpios = < 30 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ };
+
+
[PATCH 3/3] MAINTAINERS: Add Bruno Thomsen as reviewer of Kamstrup DTS
Add myself as reviewer of device trees for Kamstrup Concentrators. Signed-off-by: Bruno Thomsen --- MAINTAINERS | 5 + 1 file changed, 5 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 496fd4eafb68..97fc112309af 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -9282,6 +9282,11 @@ S: Maintained F: Documentation/hwmon/k8temp.rst F: drivers/hwmon/k8temp.c +KAMSTRUP CONCENTRATORS +R: Bruno Thomsen +S: Maintained +F: arch/arm/boot/dts/imx7d-flex-concentrator*.dts + KASAN M: Andrey Ryabinin R: Alexander Potapenko -- 2.26.2
[PATCH 1/3] dt-bindings: ARM: imx: add kamstrup flex concentrator to schema
Add Kamstrup flex concentrator compatibles to the schema so we can make use of them for the validation. Signed-off-by: Bruno Thomsen --- Documentation/devicetree/bindings/arm/fsl.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml index 05906e291e38..66627b272e40 100644 --- a/Documentation/devicetree/bindings/arm/fsl.yaml +++ b/Documentation/devicetree/bindings/arm/fsl.yaml @@ -299,6 +299,8 @@ properties: - enum: - fsl,imx7d-sdb # i.MX7 SabreSD Board - fsl,imx7d-sdb-reva# i.MX7 SabreSD Rev-A Board + - kam,imx7d-flex-concentrator # Kamstrup OMNIA Flex Concentrator + - kam,imx7d-flex-concentrator-mfg # Kamstrup OMNIA Flex Concentrator in manufacturing mode - novtech,imx7d-meerkat96 # i.MX7 Meerkat96 Board - technexion,imx7d-pico-dwarf # TechNexion i.MX7D Pico-Dwarf - technexion,imx7d-pico-hobbit # TechNexion i.MX7D Pico-Hobbit base-commit: 9ebcfadb0610322ac537dd7aa5d9cbc2b2894c68 -- 2.26.2
Re: battery switch-over detection on pcf2127
Hi Rasmus Den tir. 5. maj 2020 kl. 22.07 skrev Alexandre Belloni : > > On 05/05/2020 21:54:47+0200, Rasmus Villemoes wrote: > > Hi Bruno > > > > I just noticed your "rtc: pcf2127: add tamper detection support" > > (03623b4b04) from 5.4. Unfortunately, clearing the BTSE bit breaks a use > > case of ours: > > > > We rely on the battery switch-over detection to distinguish a powerfail > > during boot from a PORESET by the external watchdog (in the latter case, > > the RTC is still powered throughout, meaning there is no battery > > switch-over event). OTOH, we do not use the tamper detection - in fact, > > the TS signal is unconnected on our board. > > > > We're currently still on 4.19, but we will eventually upgrade to a > > kernel containing the above commit. So I was wondering if we could > > figure out a way that would work for both of us - either some CONFIG > > knob, or perhaps something in the device-tree. Any ideas? > > > > Yes, I was working on a patch series last week allowing to read BF. I'm > not sure clearing BTSE is your issue but clearing BF is. > > I'm going to send it tonight, I'll copy you, let me now if that works > for you. You can then read BF using the RTC_VL_READ ioctl. The > RTC_VL_BACKUP_SWITCH flag will be set if a switchover happened. > The RTC_VL_CLR ioctl can be used to clear the flag. > > I think clearing BTSE is still the right thing to do. I think your use case is valid and it sounds like Alexandre solution will solve it as you just need to know if a battery switch-over has happened not when exactly it happened. I can help test the patches too. Now without google auto html.. Bruno
Re: [PATCH -next] rtc: pcf2127: Fix build error without CONFIG_WATCHDOG_CORE
Den ons. 28. aug. 2019 kl. 19.19 skrev Randy Dunlap : > > Definitively not, I fixed it that way: > > + select WATCHDOG_CORE if WATCHDOG > > > > No, that's not a fix. The build error still happens with that patch applied. Hi Randy, A bugfix has been created[1] and applied to the rtc tree. Bruno [1] https://lkml.org/lkml/2019/8/27/1018
[PATCH] rtc: pcf2127: bugfix: watchdog build dependency
Disable watchdog registation when kernel is build without
watchdog functionality, and enable watchdog core otherwise.
This removes compile errors like the one below:
drivers/rtc/rtc-pcf2127.o: in function `pcf2127_probe.constprop.3':
rtc-pcf2127.c:(.text.unlikely+0x2c8): undefined reference to
`devm_watchdog_register_device'
Watchdog feature in chip will always be configured as
this is safe to do in both cases and minimize code churn.
Reported-by: Hulk Robot
Reported-by: YueHaibing
Fixes: bbc597561ce1 ("rtc: pcf2127: add watchdog feature support")
Signed-off-by: Bruno Thomsen
---
drivers/rtc/Kconfig | 1 +
drivers/rtc/rtc-pcf2127.c | 2 ++
2 files changed, 3 insertions(+)
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index a3bb58a08879..ab0ccf4a3247 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -874,6 +874,7 @@ config RTC_DRV_DS3232_HWMON
config RTC_DRV_PCF2127
tristate "NXP PCF2127"
depends on RTC_I2C_AND_SPI
+ select WATCHDOG_CORE if WATCHDOG
help
If you say yes here you get support for the NXP PCF2127/29 RTC
chips with integrated quartz crystal for industrial applications.
diff --git a/drivers/rtc/rtc-pcf2127.c b/drivers/rtc/rtc-pcf2127.c
index 3ec87d320766..02b069caffd5 100644
--- a/drivers/rtc/rtc-pcf2127.c
+++ b/drivers/rtc/rtc-pcf2127.c
@@ -475,9 +475,11 @@ static int pcf2127_probe(struct device *dev, struct regmap
*regmap,
return ret;
}
+#ifdef CONFIG_WATCHDOG
ret = devm_watchdog_register_device(dev, >wdd);
if (ret)
return ret;
+#endif /* CONFIG_WATCHDOG */
/*
* Disable battery low/switch-over timestamp and interrupts.
--
2.21.0
Re: [PATCH -next] rtc: pcf2127: Fix build error without CONFIG_WATCHDOG_CORE
Den man. 26. aug. 2019 kl. 15.20 skrev Guenter Roeck :
>
> On 8/26/19 1:12 AM, Yuehaibing wrote:
> >
> >
> > On 2019/8/23 22:05, Alexandre Belloni wrote:
> >> On 23/08/2019 20:45:53+0800, YueHaibing wrote:
> >>> If WATCHDOG_CORE is not set, build fails:
> >>>
> >>> drivers/rtc/rtc-pcf2127.o: In function `pcf2127_probe.isra.6':
> >>> drivers/rtc/rtc-pcf2127.c:478: undefined reference to
> >>> `devm_watchdog_register_device'
> >>>
> >>> Add WATCHDOG_CORE Kconfig dependency to fix this.
> >>>
> >>> Reported-by: Hulk Robot
> >>> Fixes: bbc597561ce1 ("rtc: pcf2127: add watchdog feature support")
> >>> Signed-off-by: YueHaibing
> >>> ---
> >>> drivers/rtc/Kconfig | 2 ++
> >>> 1 file changed, 2 insertions(+)
> >>>
> >>> diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
> >>> index 25af63d..9dce7dc 100644
> >>> --- a/drivers/rtc/Kconfig
> >>> +++ b/drivers/rtc/Kconfig
> >>> @@ -886,6 +886,8 @@ config RTC_DRV_DS3232_HWMON
> >>> config RTC_DRV_PCF2127
> >>> tristate "NXP PCF2127"
> >>> depends on RTC_I2C_AND_SPI
> >>> + depends on WATCHDOG
> >>
> >> Definitively not, I fixed it that way:
> >> + select WATCHDOG_CORE if WATCHDOG
> >
> >
> > No, this still fails while WATCHDOG is not set
> >
>
> Correct, there are no dummy functions for watchdog device registration.
> There would have to be conditional code in the driver if the watchdog
> is supposed to be optional.
Hi
During review of version 1, there was a wish for the watchdog feature not
to be hidden behind Kconfig option, e.g. RTC_DRV_PCF2127_WDT, as
it would not result in a much bigger driver.
I did not add any other selects/depends on in Kconfig as
RTC_DRV_DS1374_WDT and RTC_DRV_M41T80_WDT options
does not select WATCHDOG_CORE and/or WATCHDOG either.
DS1374 and M41T80 does not seem to check on any other
WATCHDOG defines other then their _WDT Kconfig.
I can create a patch that hides the watchdog code if WATCHDOG
define is not set, if that's the right way?
Bruno
RE: phy/micrel: KSZ8031RNL RMII clock reconfiguration bug
> Did you specify a led-mode as well, or was the Operation Mode Strap Override > (OMSO) write the first access after the soft reset? No led-mode was specified so OMSO was the first write. > Did you try any other workarounds besides setting the clock mode before doing > the OMSO write? I spend around 2 weeks hunting down the bug. During which I tried many things in both the Freescale FEC MAC driver and the Micrel PHY driver. Changing the init and the probe flow as well as adding a lot of extra debug traces. > And REF_CLK (pin 16) is not connected? Yes, pin 16 is floating. > Would you able to test my series on your setup, and possibly a couple of > diagnostic patches on top? Sure, I can try later this week. /Bruno -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: phy/micrel: KSZ8031RNL RMII clock reconfiguration bug
Did you specify a led-mode as well, or was the Operation Mode Strap Override (OMSO) write the first access after the soft reset? No led-mode was specified so OMSO was the first write. Did you try any other workarounds besides setting the clock mode before doing the OMSO write? I spend around 2 weeks hunting down the bug. During which I tried many things in both the Freescale FEC MAC driver and the Micrel PHY driver. Changing the init and the probe flow as well as adding a lot of extra debug traces. And REF_CLK (pin 16) is not connected? Yes, pin 16 is floating. Would you able to test my series on your setup, and possibly a couple of diagnostic patches on top? Sure, I can try later this week. /Bruno -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: phy/micrel: KSZ8031RNL RMII clock reconfiguration bug
Hi Johan, > As you may have seen by now, I've been working on refactoring the micrel phy > driver to be able to use common initialisation code. > > Specifically, I've added generic support for disabling the broadcast address, > which is what the MII_KSZPHY_OMSO write above does. > > Generally you want this to be the first thing you do in order to avoid > unnecessary reconfigurations. If we ever were to allow concurrent probing > this would also be a requirement. > > Could you provide some detail about the setup were you find that the PHY > becomes unresponsive without your patch? Do you have more than one PHY on the > bus? Using what addresses? And using what clock modes (i.e. 25 MHz or 50 MHz)? > > Also, what exactly do you mean by "unresponsive"? Are you still able to read > the PHY registers for example? I think it sounds like a good idea to refactor the init code. My setup: iMX28 processor with dual Ethernet MAC; FEC0 (enabled) and FEC1 (disabled). There is a single KSZ8031 PHY that receives 50MHz RMII clock from the MAC. I am unable to read PHY registers from both user-land tools and extra debug PHY reads in driver code. Boot trace: [ 22.277785] fec 800f.ethernet eth0: Freescale FEC PHY driver [Micrel KSZ8031] (mii_bus:phy_addr=800f.etherne:00, irq=-1) [ 22.292527] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready [ 24.276217] libphy: 800f.etherne:00 - Link is Up - 100/Full [ 24.285094] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready Venlig hilsen / Best regards Kamstrup A/S <http://www.kamstrup.dk> Bruno Thomsen Development engineer Technology Kamstrup A/S Industrivej 28 DK-8660 Skanderborg Tel: +45 89 93 10 00 Fax: +45 89 93 10 01 Dir: +45 89 93 13 94 E-mail: b...@kamstrup.dk Web: www.kamstrup.dk -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: phy/micrel: KSZ8031RNL RMII clock reconfiguration bug
Hi Johan, As you may have seen by now, I've been working on refactoring the micrel phy driver to be able to use common initialisation code. Specifically, I've added generic support for disabling the broadcast address, which is what the MII_KSZPHY_OMSO write above does. Generally you want this to be the first thing you do in order to avoid unnecessary reconfigurations. If we ever were to allow concurrent probing this would also be a requirement. Could you provide some detail about the setup were you find that the PHY becomes unresponsive without your patch? Do you have more than one PHY on the bus? Using what addresses? And using what clock modes (i.e. 25 MHz or 50 MHz)? Also, what exactly do you mean by unresponsive? Are you still able to read the PHY registers for example? I think it sounds like a good idea to refactor the init code. My setup: iMX28 processor with dual Ethernet MAC; FEC0 (enabled) and FEC1 (disabled). There is a single KSZ8031 PHY that receives 50MHz RMII clock from the MAC. I am unable to read PHY registers from both user-land tools and extra debug PHY reads in driver code. Boot trace: [ 22.277785] fec 800f.ethernet eth0: Freescale FEC PHY driver [Micrel KSZ8031] (mii_bus:phy_addr=800f.etherne:00, irq=-1) [ 22.292527] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready [ 24.276217] libphy: 800f.etherne:00 - Link is Up - 100/Full [ 24.285094] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready Venlig hilsen / Best regards Kamstrup A/S http://www.kamstrup.dk Bruno Thomsen Development engineer Technology Kamstrup A/S Industrivej 28 DK-8660 Skanderborg Tel: +45 89 93 10 00 Fax: +45 89 93 10 01 Dir: +45 89 93 13 94 E-mail: b...@kamstrup.dk Web: www.kamstrup.dk -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
