tree 7b02e6ed9b35c90e4b82b9b91e7f9188e88ab373
parent 94024e94757b065f1c54e44ca7e37378408d46b1
author Daniel Golle <daniel@makrotopia.org> 1681331803 +0100
committer Tom Rini <trini@konsulko.com> 1683119124 -0400

pinctrl: mediatek: set R1/R0 in case pullen/pullsel succeeded

Commit dafe0fbfb0f3 ("pinctrl: mediatek: rewrite mtk_pinconf_set and
related functions") changed the logic deciding to set R0 and R1
registers for V1 devices.

Before:
	/* Also set PUPD/R0/R1 if the pin has them */
	err = mtk_hw_set_value(dev, pin, PINCTRL_PIN_REG_PUPD, !pullup);
	if (err != -EINVAL) {
		mtk_hw_set_value(dev, pin, PINCTRL_PIN_REG_R0, r0);
		mtk_hw_set_value(dev, pin, PINCTRL_PIN_REG_R1, r1);
	}

After:
	/* try pupd_r1_r0 if pullen_pullsel return error */
	err = mtk_pinconf_bias_set_pullen_pullsel(dev, pin, disable, pullup,
						  val);
	if (err)
		return mtk_pinconf_bias_set_pupd_r1_r0(dev, pin, disable,
						       pullup, val);

Tracing mtk_pinconf_bias_set_pullen_pullsel shows that the function
always either returns 0 in case of success or -EINVAL in case any error
has occurred. Hence the logic responsible of the decision to program R0
and R1 has been inverted.

This leads to problems on BananaPi R2 (MT7623N) when booting from
SDMMC, it turns out accessing eMMC no longer works since
U-Boot 2022.07:

MT7623> mmc dev 0
Card did not respond to voltage select! : -110

The problem wasn't detected for a long time as both eMMC and SDMMC work
fine if they are used to boot from, and hence R0 and R1 were already
setup by the bootrom and/or preloader.

Fix the logic to restore the originally intended and correct behavior
and also change the descriptive comment accordingly.

Fixes: dafe0fbfb0f3 ("pinctrl: mediatek: rewrite mtk_pinconf_set and related functions")
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Tested-By: Frank Wunderlich <frank-w@public-files.de>