When should gpio-restart be used/avoided?

Bjørn Mork bjorn at mork.no
Sun Aug 14 03:34:29 PDT 2022


Lech Perczak <lech.perczak at gmail.com> writes:

> Hi,
>
> Yes, I can confirm, this is used to reset the modem on rebooting the device.
>
> At least when used in conjunction with uqmi, the modem would misbehave
> otherwise,
> and connection attempts would fail after rebooting the device. The
> same is true for its ath79-based predecessors.
> I think this issue deserves investigation on its own.

Yes, this sounds more like a generic problem with how we use uqmi to
manage the modem than anything else.  I must admit that I'm not much of
an uqmi user.  I am too spoiled with ModemManager on my laptop for the
last 10 years.  It just works. And I do prefer to use it on OpenWrt
too.

FWIW, I did a simple test now using ModemManager on the MF286D.  There
is no issue with the modem after reboot, even if the gpio-restart device
is disabled.

This is my MM config:

config interface 'wan'
        option device '/sys/devices/platform/soc/8af8800.usb3/8a00000.dwc3/xhci-hcd.0.auto/usb2/2-1'
        option proto 'modemmanager'
        option apn 'internet.public'


I disabled the gpio-restart by doing

 echo gpio-restart >/sys/bus/platform/drivers/restart-gpio/unbind

Rebooting brings up the modem connection comes up just fine.  I can't
see anything wrong with it.

In theory all services in a QMI modem should be reset to defaults and
all state cleared by simply sending a QMI_CTL SYNC request to the modem.
And I see that we do send this during setup in

package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh 

A bit late maybe, after PIN and framing config, but that's probably
fine.  At least I don't expect the SIM state to be reset by SYNC.  Don't
know about 802.3 framing, but I'd have to dig out an old modem to find
out.  I guess it will work since the framing is a persistent setting
IIRC.

I'll do a test with uqmi too.

> Issue with this pin is that if we'd just like to reset the modem, it's
> not possible without resetting the device,
> as this is basically a "suicide switch" rather than just USB power cutoff.

Yes, looks like this pin controls the 3.3V regulator maybe? Not the
nicest thing to do to the system, regardless of console connection, is
it?



Bjørn



More information about the openwrt-devel mailing list