W dniu 2.02.2025 o 21:48, Sander Vanheule pisze:
> Hi Tomasz,
>
> On Sun, 2025-02-02 at 21:25 +0100, [email protected] 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.
Thanks, that seems to be what is done.
> I expect a gpio-hog would conflict with the fixed-regulator in claiming the
> GPIO. And hogs don't
> allow you to toggle them.
I did add hog definition toggling GPIO to high and then still could change state
through userspace-consumer sysfs but states were reversed ("enabled" disabled
the regulator), which would mean hog definition takes precedence and regulator
driver assumes it's default state. I'll leave current dts state, as that keeps
it
closer to vendor configured behavior.
>>
>>> 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
Thank You for all comments.
Regards
--
TMN
_______________________________________________
openwrt-devel mailing list
[email protected]
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
