On Mon, Nov 1, 2021 at 6:57 AM Ricardo Martinez <ricardo.martinez@xxxxxxxxxxxxxxx> wrote: > Creates char and tty port infrastructure for debug and testing. > Those ports support use cases such as: > * Modem log collection > * Memory dump > * Loop-back test > * Factory tests > * Device Service Streams A-ha. The purpose of chardev stuff in previous patches becomes much more clear. Please do not do this in such a way. This is not an everyday usage operation to be supported via the chardev. Also this will require an end user to study another one bunch of custom vendor tools for quite common development tasks. The kernel already has a rich set of frameworks for device debugging. If you need to update firmware use the devlink firmware updating facility, see e.g. Intel iosm driver for reference. For memory dumping you could utilize devlink or device coredump facilities (see ath10k driver for reference). For other debugging tasks I recommend you to use debugfs. The WWAN subsystem could be extended to provide a driver with a common debugfs infrastructure (e.g. create common directory for WWAN devices, etc.). As for modem logs, you could pipe them to the common kernel log via the dynamic debug logging or export them via the debugfs as well. Loic, Johannes, do you have some other advice on how to facilitate the modem debugging/development tasks? -- Sergey
