I was trying to set-up an access point at the same time as I have a station (client) connection and I kept hitting a
brcmf_cfg80211_change_iface: iface validation failed: err=-16
error seen in syslog and dmesg. I found lots of posts in various places encountering this error with various work-arounds that didn't work for me and no real explanation.
Using rPi4B running Raspberry Pi OS buster (may 2021 version).
Answering my own question... I dug into some of the driver source code and I hope my report on what solved my issue helps others. All this is on RaspberryPi OS buster, if you're using something else YMMV... (I didn't want to follow some of the excellent guides on this site, e.g. Access point as WiFi router/repeater, optional with bridge because I don't want to use systemd-networkd)
The short answer is that err=-16 refers to a unix error number (errno) and corresponds to EBUSY, also described as "Device Busy". That doesn't help a ton per-se. Looking at the code, the error comes from cfg80211_check_combinations, which is a function in the stack that checks that the set of requested wifi interfaces are supported by the chip. For example, many chips support one station plus one access point, plus one ad-hoc interface, but not two access points, etc. You can check what your chip supports using iw list and in the long output look for "valid interface combinations" towards the very end. Anyway, EBUSY means that the requested combination is not supported. Yet iw list says that my Pi (a 4B) can support an access point at the same time as a station interface. So what gives?
A clue about the problem in my case came up by running hostapd manually. To do that:
sudo systemctl stop hostapd
sudo /usr/sbin/hostapd -P /run/hostapd.pid -d /etc/hostapd/hostapd.conf
(the -d outputs debug info). The output is long and verbose, but after watching it for a while it became clear that the error occurs at almost random points in time, periodically. If you have a different situation, running this may give you
some clue about what hostapd is trying to do when the error occurs.
So the final resolution for me was that by default dhcpcd (the DHCP client daemon) launches wpa_supplicant on every interface it discovers using a hook (/usr/share/dhcpcd/hooks/10-wpa_supplicant). This results in a conflict where hostapd wants to run the interface in AP mode and wpa_supplicant probably wants it in station mode. The solution is to disable the hook in the dhcpcd config file /etc/dhcpcd.conf by adding
interface ap0 # interface used by hostapd
nohook wpa_supplicant
The interface statement means that the subsequent lines apply only to that interface. The nohook statement disables the hook.