Messages in this thread | | | Date | Mon, 20 Feb 2023 14:07:27 +0100 | Subject | RFC: shall we have a baseband subsystem ? | From | "Enrico Weigelt, metux IT consult" <> |
| |
Hello folks,
in recent times we had several discussions on issues related to controlling various baseband controllers, which tend to be quite board specific - for example:
* RST lines on APU board family's M2 slots, which can be used to devices in there, eg. modems (actual GPIO is model specific) * switchable power supply (onboard basebands) * SIM-slot multiplexers (also on APU) * RF exposure sensors for TX strength regulation * active antenna or boosters * fly-mode (rfkill)
Originally I thought about extending rfkill, but quickly turned out that there're too many aspects in here that are way ouf of scope for rfkill. Similar for isdn4linux. And seems netdev the right place, since it usually comes into play much later, when an actual connection is made.
The biggest challenge from userland/application side IMHO is probing the presence of those feature and the actual connection between individual pieces. Since the kernel usually knows best about the current HW setup and serves as an universal HAL in many many other places, I believe that it also should carry the necessary knowledge of those stuff, too.
I'm currently thinking of a new device class, representing the whole baseband setup with its surrounding peripherals in sysfs. There we'll find several entries, eg.:
* model information, supported protocols and interfaces * link to the tty device (if it's speaking AT commands) * enumerating and setting sim slot choices * get / set power state * trigger HW reset * get/set TX limits * booster configuration * link to netdev (if applicable) * link to rfkill * link to mixer/dsp channels for direct mic links ...
Userland can now query this information or act on these devices in standard way, no need to care about individual HW details anymore. Even on an average PC, this can make detection of connected basebands easier (eg. no need to configure the tty device name, ...)
Probing probably needs some callbacks for dealing with hotplug, so board drivers can act when some other subsys detects a device that might be a baseband. For example on the APU boards, basebands are connected via USB, so we have to hook in here and let the board driver check whether the new USB device is a baseband and in which HW slot it's in - and in this case it sets up baseband device and connects all other peripherals.
Actually, I'm not fully settled on the naming yet - "baseband" was just the first to come in mind, but this should also work for other devices like wifi (hmm, maybe even some wired ones ?).
What's you oppinion on that ?
--mtx
-- --- Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren GPG/PGP-Schlüssel zu. --- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering info@metux.net -- +49-151-27565287
| |