Hi Tomasz,
On Sun, 2025-02-02 at 21:25 +0100, to...@terefe.re wrote:
> W dniu 2.02.2025 o 19:37, Sander Vanheule pisze:
> > Hi Tomasz,
>
> Hi
>
> >
> > On Sun, 2025-02-02 at 16:10 +0100, Tomasz Maciej Nowak wrote:
> > > + reg_usb_vbus: regulator-usb-vbus {
> > > + compatible = "regulator-fixed";
> > > + regulator-name = "usb-vbus";
> > > + regulator-min-microvolt = <5000000>;
> > > + regulator-max-microvolt = <5000000>;
> > > + gpios = <&gpio 4 GPIO_ACTIVE_LOW>;
> > > + };
> > > +
> > > + output-usb-vbus {
> > > + compatible = "regulator-output";
> > > + vout-supply = <®_usb_vbus>;
> > > + };
> > > +};
> > >
> > > + DEVICE_PACKAGES += kmod-regulator-userspace-consumer
> >
> > You could also add the regulator-boot-on to regulator-usb-vbus. If it is
> > already enabled by the
> > bootloader, regulator-boot-on will keep it enabled. Otherwise it should
> > cause the regulator to
> > be
> > enabled (GPIO set low in this case) when the driver probes.
>
> Issue is, bootloader doesn't enable power on the USB port, it's done when the
> vendor modified EHCI driver was loaded, and while regulator-boot-on enables
> power, the regulator is turned off later, as no driver seem to use it (a bug
> in
> userspace-consumer driver?). I'll check if specifying hog property will allow
> to
> still toggle it from userspace.
While regulator-always-on act as a consumer, regulator-boot-on doesn't. I can
imagine loading the
userspace-consumer driver has the side-effect of checking the consumer count
and disabling on zero.
I expect a gpio-hog would conflict with the fixed-regulator in claiming the
GPIO. And hogs don't
allow you to toggle them.
>
> > You could also add regulator-always-on to regulator-usb-vbus, in which case
> > the USB port can't
> > be
> > powered down anymore (from userspace). Is there any specific reason you
> > would want to power the
> > port
> > down?
>
> I can imagine someone using a LTE dongle to manage that AP, which sometime
> could
> lock itself up and only power-cycle could restore it. Power-cycling the USB
> port
> will restore the management capability without interrupting WiFi operation.
Sounds like a reasonable use-case.
Best,
Sander
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
