netdev - RFC: shall we have a baseband subsystem ?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <f1f102dc-0e9a-4a13-1e40-f4c3d594fe7e@metux.net>
Date:   Mon, 20 Feb 2023 14:07:27 +0100
From:   "Enrico Weigelt, metux IT consult" <lkml@...ux.net>
To:     platform-driver-x86@...r.kernel.org,
        "Enrico Weigelt, metux IT consult" <info@...ux.net>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        netdev@...r.kernel.org, linux-wireless@...r.kernel.org,
        isdn@...ux-pingi.de
Subject: RFC: shall we have a baseband subsystem ?

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@...ux.net -- +49-151-27565287