You could try to change it, I see references to mt6323-regulator in mfd/mt6397-core.c which according to mt7623n_evb_fwu_defconfig is built (CONFIG_MFD_MT6397=y), I’m not sure it will change anything.
Maybe it’s better to debug the problem like bitmaster wrotes…Since the problem seems to be in consys-node/reset and not in regulator (both regulators give positive feedback)
I’ve added some debug statements. Could you please apply the attached patch, reproduce the crash and see what’s in the log?
In your linux folder:
patch -p1 <
reset_ctrl_debug.patch (2.4 KB)
Then we know if we are on the right track.
1 Like
[ 53.667352] __of_reset_control_get: (drivers/reset/core.c:442) node=consys
[ 53.667360] __of_reset_control_get: (drivers/reset/core.c:450) index = 0
[ 53.667371] __of_reset_control_get: (drivers/reset/core.c:459) ret = (null)
[ 53.667379] __of_reset_control_get: (drivers/reset/core.c:468) 36a018ec == dcf41cbc
[ 53.667385] __of_reset_control_get: (drivers/reset/core.c:468) 36a018ec == f5e83680
[ 53.667390] __of_reset_control_get: (drivers/reset/core.c:468) 36a018ec == e79002de
[ 53.667396] __of_reset_control_get: (drivers/reset/core.c:468) 36a018ec == b839cf8c
[ 53.667401] __of_reset_control_get: (drivers/reset/core.c:478) !rcdev, returning -EPROBE_DEFER
wifi-debug.log (27,5 KB)
as far as i see the problem should be line 457 (above ret=NULL):
ret = of_parse_phandle_with_args(node, "resets", "#reset-cells",
index, &args);
printk(KERN_WARNING "%s: (%s:%i) ret = %p", __FUNCTION__, __FILE__, __LINE__, (void*)ret);
do we need the “#reset-cells” here and which value?? or is index 0 the problem?
if (id) {
index = of_property_match_string(node,
"reset-names", id);
printk(KERN_WARNING "%s: (%s:%i) index = %i", __FUNCTION__, __FILE__, __LINE__, index);
if (index == -EILSEQ)
return ERR_PTR(index);
if (index < 0)
return optional ? NULL : ERR_PTR(-ENOENT);
}Worth a try, but not likely going to work as it does not use ret anywhere else. Add #reset-cells = <1>; in the consys block in arch/arm/boot/dts/mt7623.dtsi to find out.
Did you find any prints of line 87 in drivers/reset/core.c? I would expect so, because there are entries in the list.
Then could you please change the printk in the list_for_each_entry (around line 463~466) to:
printk(KERN_WARNING "%s: (%s:%i) %s == %s", __FUNCTION__, __FILE__, __LINE__, args.np ? args.np->name : "<NULL>", r->of_node ? r->of_node->name : "<NULL>");
i have no message of line 87…had appended the full log to my last posting…
Sorry I meant dmesg log. Those printk’s end up in there, but also get spammed on the serial console when boot is done.
this log is from dmesg…i have only removed part before wifi init
you mean this message, right?
int reset_controller_register(struct reset_controller_dev *rcdev)
{
+ printk(KERN_WARNING "%s: (%s:%i) of_node=%s", __FUNCTION__, __FILE__, __LINE__, rcdev->of_node ? rcdev->of_node->name : "<NULL>");
should this be done on boot or when calling wmt-tools?
For the items currently in the list most likely on boot somewhere when the devices are probed. When wmt-tools inserts kernel modules, it might be called again, but not yet apparently.
ok, then i have stripped to much 
will do it when i’m at home again, also with additional printk for list-entries
1 Like
full dmesg including changed printk and #reset-cells: wifi-debug.log (31,1 KB)
at boottime i see nothing consys-related…
uploaded changes done for this log to repo (branch 4.16-wlan)
When starting the wlan modules, it’s looking for a device_node called ‘watchdog’, but there are only ‘syscon’ entries in the list:
[ 51.702101] __of_reset_control_get: (drivers/reset/core.c:469) watchdog == syscon
looks like watchdog is enabled though
[ 1.394286] mtk-wdt 10007000.watchdog: Watchdog enabled (timeout=31 sec, nowayout=0)
Something is missing… not quite sure yet what. Maybe check what happens with the same printk’s in 4.14.
By the way, do you have a file called /sys/kernel/debug/pinctrl-handles?
Can you cat it’s contents?
If it’s not there, could you first try to: mount -t debugfs none /sys/kernel/debug.
This is to check why the following message is printed:
[ 51.701826] [WMT-CONSYS-HW][E]mtk_wmt_probe(125):Wmt Cannot find pinctrl default!
how should the watchdog-node get into the list? i guess this should be done at boot-time by parsing the full dts(i)…is this done for full nodes or only nodes with resets?
will do 4.14-printk’s and the cat of debugfs (i should have it mounted because other tests before) when i’m at home
4.16-pinctrl-handles.txt (10,7 KB)
4.14-pinctrl-handles.txt (11,2 KB)
test with 4.14 (dmesg after wifi-script on same system as 4.16 before): wifi-debug-4.14.log (43,4 KB)
[ 1.535524] mtk-wdt 10007000.watchdog: Watchdog enabled (timeout=31 sec, nowayout=0)
[ 1.543534] reset_controller_register: (drivers/reset/core.c:87) of_node=watchdogAs far as I understand it, the driver modules get compiled into the kernel, they get probed during boot and then will look into the dts how to initialize the hardware etc.
Interesting logs. This line should most likely also happen in 4.16 for the wifi module to find it, unless in 4.16 they altered this behavior. I expect it to be somewhere (indirectly) in the mtk-wdt driver.
Just for fun I tried those printk’s also on 4.17-rc1, which also doesn’t call reset_controller_register for watchdog, same as your 4.16.
maybe this is related: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7e6127c1240ed569cdda2a67c8f03836f9f28c05
there is a patch for 7621 (not bpi-chip, but maybe interesting) which changes watchdog_register_device to devm_watchdog_register_device
Good find, but I don’t think these changes have any impact.
Could you please add some printk’s to: mtk_infrasys_init, at least at the top and before mtk_register_reset_controller. If reset controller is called, then continue in there. At the end of that function, the reset controller is registered. This method should be called. If you see no prints at all, check if the drivers/clk/mediatek/clk-mt2701.o file exists and has recent changes.
i try to include some printk’s:
printk(KERN_WARNING "%s: (%s:%i) regmap=%s", __FUNCTION__, __FILE__, __LINE__, regmap ? regmap->name : "<NULL>");
got this error:
drivers/clk/mediatek/reset.c:75:97: error: dereferencing pointer to incomplete type 'struct regmap'
printk(KERN_WARNING "%s: (%s:%i) regmap=%s", __FUNCTION__, __FILE__, __LINE__, regmap ? regmap->name : "<NULL>");
and i wonder how this can work:
struct regmap *regmap;
because variable-name is same as type…without the var-content log is here:
4.16-infrasys.txt (24,4 KB)
patch-file: infrasys.patch (2,6 KB)
Incomplete type in this case probably means the type was forward declared and only used as pointer (not as regmap type).
The logs are sufficient, thanks. On a quick look it seems that sadly were not on the right path as everything is called as it’s supposed to. I didn’t have any time yet to dive into further, busy weekend 
, but we need to find out how kernel 4.14 mtk_wdt_probe finally causes calling reset_controller_register. This what your earlier log was showing:
Note that the Watchdog enabled is the last line of mtk_wdt_probe, while the register_controller_register is called after, according to the log. I now suspect this is because the watchdog is scheduled somewhere, and registered upon start. I was hoping the infrasys logs would give some more insight…
In your wifi-debug.log (4.16-wlan) I don’t see the line MTK_WDT_NONRST_REG(0) that is in wifi-debug-4.14.log. I think you forgot to merge drivers/watchdog/mtk_wdt.c 
1 Like