lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 10 Dec 2021 17:35:12 +0300 From: "Andrey Jr. Melnikov" <temnota.am@...il.com> To: netdev@...r.kernel.org Cc: linux-mediatek@...ts.infradead.org, openwrt-devel@...ts.openwrt.org Subject: Re: MT7621 ethernet does not get probed on net-next branch after 5.15 merge In gmane.comp.embedded.openwrt.devel Sergio Paracuellos <sergio.paracuellos@...il.com> wrote: > Hi Qingfang, > On Fri, Oct 15, 2021 at 4:23 PM DENG Qingfang <dqfext@...il.com> wrote: > > > > Hi, > > > > After the merge of 5.15.y into net-next, MT7621 ethernet > > (mtk_eth_soc.c) does not get probed at all. > > > > Kernel log before 5.15 merge: > > ... > > libphy: Fixed MDIO Bus: probed > > libphy: mdio: probed > > mt7530 mdio-bus:1f: MT7530 adapts as multi-chip module > > mtk_soc_eth 1e100000.ethernet eth0: mediatek frame engine at 0xbe100000, irq 20 > > mt7621-pci 1e140000.pcie: host bridge /pcie@...40000 ranges: > > ... > > > > Kernel log after 5.15 merge: > > ... > > libphy: Fixed MDIO Bus: probed > > mt7621-pci 1e140000.pcie: host bridge /pcie@...40000 ranges: > > ... > > > > > > I tried adding debug prints into the .mtk_probe function, but it did > > not execute. > > There are no dts changes for MT7621 between 5.14 and 5.15, so I > > believe it should be something else. > > > > Any ideas? > I had time to create a new image for my gnubee board using kernel 5.15 > and this problem does not exist on my side. Since no more mails have > come for a while I guess this was a problem from your configuration, > but just in case I preferred to answer to let you know. I am currently > using v5.15.7 from linux-stable with some other patches that will be > for 5.16. Just in case, you can check the kernel tree [0] I am > currently using. There is problem with reset controller and devlink commutication. reset controller is abent in mainline, devlink defer all drivers which use reset lines until reset-controller become available - so no drivers probed. I'm create for myself this patch: https://drive.google.com/file/d/1AiKlfvIgtrBsxtI-2XFBvaxGoE0S-s9d/view?usp=sharing
Powered by blists - more mailing lists