Ran the OEM firmware BT mac is ethernet mac + 3 and matches the bootloader
I've tested which flags are actually needed (SKIP_TEST is cruical, using it on 0xc00 breaks the bt uart at 0xe00).
UPF_SHARE_IRQ is now derived from the interrupt itself, the port.type and UPF_FIXED_TYPE and UPF_SKIP_TEST are set only if "uart-type" property is set in DTS. UPF_IOREMAP isn't needed.
I've redone the patches - (K.V. I've not had a chance to test a clean build with these yet, but they're working in my tree)
I think with this set it shouldn't be able to break anything that's currently working.
Looking at the driver, I don't think you need the "default" scheme. It's only used if you don't have "boot" gpio. DT parsing will not fail as long as bdev->boot is set:
bdev->boot = devm_gpiod_get_optional(&serdev->dev, "boot",
GPIOD_OUT_LOW);
..
bdev->pins_boot = pinctrl_lookup_state(bdev->pinctrl,
"default");
if (IS_ERR(bdev->pins_boot) && !bdev->boot) {
err = PTR_ERR(bdev->pins_boot);
dev_err(&serdev->dev,
"Should assign RXD to LOW at boot stage\n");
return err;
}
And probe() ignores the "default" (bdev->pins_boot) scheme:
if (bdev->boot) {
gpiod_set_value_cansleep(bdev->boot, 1);
} else {
/* Switch to the specific pin state for the booting
* requires.
*/
pinctrl_select_state(bdev->pinctrl, bdev->pins_boot);
}
Good spot! so with that, I can use the existing device node.
"no-loopback-test" seems to be the standard for setting UPF_SKIP_TEST so I added support for that. Tidied everything else up and added the odd helpful comment.
what's the form in openwrt - do I open a PR? or is it patches to a mailing list? or something else?
Also interested here. Would any of this be transferable to the U6+ in any way?
I can't see any evidence of BLE hardware on the U6+. It's a MT7981A (SOC+2.5Gbe+(abgn+ac+ax with 6E)) and a MT7976C (PCI+(abgn+ac+ax simulateous dual band with 6E))
I've looked these two products again and it appears you are right. Ubiquiti lists Ethernet and Bluetooth as management interfaces for U6 lite, but lists only Ethernet for U6+. So looks like if one needs Bluetooth and doesn't care for dual-band WiFi 6, U6+ isn't an option.
I thought this was just a firmware thing since when I took apart a U6+ one of its antennas had a "BT/5G2" silkscreen label. But maybe that's just a "copy-and-paste" error on Ubiquiti's part.
There's an unpopulated 48 pin QFN with a bunch of passives and what looks like a lumped PI filter on the north side, I'd hazard a guess that's for an nRF51822 bluetooth SoC. Perhaps they decided the feature wasn't worth the cost increase for this model.
There's a KernelPackage/btmtkuart definition in target/linux/mediatek/modules.mk, depending on @TARGET_mediatek_mt7622. I believe it is better to move this into package/kernel/linux/modules/other.mk , adding ||TARGET_ramips_mt7621, instead of duplicating the defintion in target/linux/ramips.
Likewise with the driver patches. Better move them to target/linux/generic since they apply to drivers shared between the mediatek and ramips targes.
I'm already frustrated enough by the different set of patches for the same drivers in those two targets. The worst example is target/linux/ramips/patches-5.15/700-net-ethernet-mediatek-support-net-labels.patch, which they won't even accept in target/linux/mediatek....
And you'll probably have to provide both 6.1 and 5.15 versions as long as both kernels are supported. The 6.1 patch is mostly a direct copy and refresh, but the FIRMWARE_MT7915 macro should probably go into btmtk.h for 6.1 where all the other FIRMWARE_* macros have moved. And maybe you want a MODULE_FIRMWARE(FIRMWARE_MT7915) in btmtk.c for consistency? This obviously makes no difference for the OpenWrt U6 lite support, but all the other firmware files have such meta data defintiions.
I see that the bd-addr nvmem support is modelled after the ti driver. IMHO it would be nice to have those drivers share that code and make it a generic bluetooth controller interface, provided upstream agrees nvmem support is a good idea. If they don't, then it's probably better to load the address from a userspace script instead of maintaining this code out-of-tree forever.
Just some random thoughts I had. OpenWrt developers and upstream bluetooth driver maintainers might disagree strongly. As they often do
I have two of these in our summer house. Don't know if that counts for much... I don't think I've ever tried 160MHz on them. Most of my clients don't support it.
There's a KernelPackage/btmtkuart definition in target/linux/mediatek/modules.mk
yes and the build system conflates their dependencies. I initially tried putting it in other.mk but that has the side effect of turning on SERDEV_ for builts for all which on some platforms required adding some more "is not set" to the kernel config, and the review bot then tagged my patch with all the other architectures, which didn't sound like I was going to have a fun day.
IMHO it would be nice to have those drivers share that code
I agree, but that's an kernel upstream problem. I wondered about using the same code used for of ethernet addresses since we're already doing a dirty bswap, a dodgy cast from ether_addr to bdaddr_t would be less ugly.
then it's probably better to load the address from a userspace script instead of maintaining this code out-of-tree forever
I'm not sure that's a winninest plan - BLE devices fall over all the time, so plenty of userspace stacks will reset them, so the kernel needs to be able to inject the correct mac as part of that process.
