Mikrotik RBM33g k5.14, usb not powered

For Developers
1

hi
I am trying to prepare a custom Linux kernel v5.15.107 and I have a problem with the rear usb. It seems it's not powered.

I see there is a GPIO pin to enable/disable the power on the rear USB, but it's not clear

  1. if the device tree is ok, or if I have to add/modify something
  2. if I have to configure something in the kernel .config file
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
clocksource: Switched to clocksource GIC
workingset: timestamp_bits=30 max_order=16 bucket_order=0
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 252)
io scheduler mq-deadline registered
io scheduler kyber registered
mt7621_gpio 1e000600.gpio: registering 32 gpios
mt7621_gpio 1e000600.gpio: registering 32 gpios
mt7621_gpio 1e000600.gpio: registering 32 gpios
Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
1e000c00.uartlite: ttyS0 at MMIO 0x1e000c00 (irq = 19, base_baud = 3125000) is a 16550A
1e000e00.uartlite3: ttyS1 at MMIO 0x1e000e00 (irq = 20, base_baud = 3125000) is a 16550A
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
usbcore: registered new interface driver usb-storage
i2c_dev: i2c /dev entries driver
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
reg-fixed-voltage reg_usb_vbus33: nonexclusive access to GPIO for reg_usb_vbus33
reg-fixed-voltage usb_vcc_reg: nonexclusive access to GPIO for usb_vcc_reg
xhci-mtk 1e1c0000.xhci: supply vusb33 not found, using dummy regulator
xhci-mtk 1e1c0000.xhci: xHCI Host Controller
xhci-mtk 1e1c0000.xhci: new USB bus registered, assigned bus number 1
xhci-mtk 1e1c0000.xhci: hcc params 0x01401198 hci version 0x96 quirks 0x0000000000290010
xhci-mtk 1e1c0000.xhci: irq 22, io mem 0x1e1c0000
xhci-mtk 1e1c0000.xhci: xHCI Host Controller
xhci-mtk 1e1c0000.xhci: new USB bus registered, assigned bus number 2
xhci-mtk 1e1c0000.xhci: Host supports USB 3.0 SuperSpeed
usb usb1: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 5.15
usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb1: Product: xHCI Host Controller
usb usb1: Manufacturer: Linux 5.15.107 xhci-hcd
usb usb1: SerialNumber: 1e1c0000.xhci
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
usb usb2: We don't know the algorithms for LPM for this host, disabling LPM.
usb usb2: New USB device found, idVendor=1d6b, idProduct=0003, bcdDevice= 5.15
usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb2: Product: xHCI Host Controller
usb usb2: Manufacturer: Linux 5.15.107 xhci-hcd
usb usb2: SerialNumber: 1e1c0000.xhci
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 1 port detected
i2c-mt7621 1e000900.i2c: clock 100 kHz
spi-mt7621 1e000b00.spi: sys_freq: 150000000

This is what the kernel says, and it seems there is something wrong here

reg-fixed-voltage usb_vcc_reg: nonexclusive access to GPIO for usb_vcc_reg
2

I see in drivers/usb/host/xhci-mtk.c

        ret = regulator_enable(mtk->vbus);
        if (ret) {
                dev_err(mtk->dev, "failed to enable vbus\n");
                return ret;
        }

        ret = regulator_enable(mtk->vusb33);
        if (ret) {
                dev_err(mtk->dev, "failed to enable vusb33\n");
                regulator_disable(mtk->vbus);
                return ret;
        }

but there is no reference in the dts for the vusb33: where is it defined? and what's its purpose?

3

vusb33 may be an auxiliary 3v3 supply for things like a separate USB PHY.
From your boot log it mentions that it couldn't find such a vusb33 (likely as you mention it wasn't listed in the DT) and hence it's used a dummy regulator

xhci-mtk 1e1c0000.xhci: supply vusb33 not found, using dummy regulator

If you know there is a GPIO for turning on the (+5V) VUSB supply, have you confirmed that this GPIO is indeed in the state required? If it is, then perhaps there's a hardware issue (blown fuse / damaged FET or similar).
If it's not, then it does seem there is a software issue. You'd want to identify if that GPIO is referenced at all, my expectation is that it would be in the DT associated with the VUSB for that port. But possibly there aren't enough power domains currently in the DT to encapsulate that.. i.e. the DT might be built for use of the 'other' USBs, but not to turn on the VUSB to the 'rear' USB

It looks like overall there are three ports

hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
...
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 1 port detected

Would that align with the 2 you can currently use, and the one rear USB port that you can't?

I'd say this is likely either a hardware, or a DT problem.