[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHNKnsT_SDUCtisOx9QsfgUbQyi8uY8hUvYXvXtSxno_rfdzOQ@mail.gmail.com>
Date: Sat, 6 Nov 2021 21:10:29 +0300
From: Sergey Ryazanov <ryazanov.s.a@...il.com>
To: Ricardo Martinez <ricardo.martinez@...ux.intel.com>,
Johannes Berg <johannes@...solutions.net>,
Loic Poulain <loic.poulain@...aro.org>
Cc: netdev@...r.kernel.org, linux-wireless@...r.kernel.org,
Jakub Kicinski <kuba@...nel.org>,
David Miller <davem@...emloft.net>,
M Chetan Kumar <m.chetan.kumar@...el.com>,
chandrashekar.devegowda@...el.com,
Intel Corporation <linuxwwan@...el.com>,
chiranjeevi.rapolu@...ux.intel.com, haijun.liu@...iatek.com,
amir.hanania@...el.com,
Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
dinesh.sharma@...el.com, eliot.lee@...el.com,
mika.westerberg@...ux.intel.com, moises.veleta@...el.com,
pierre-louis.bossart@...el.com, muralidharan.sethuraman@...el.com,
Soumya.Prakash.Mishra@...el.com, sreehari.kancharla@...el.com,
suresh.nagaraj@...el.com
Subject: Re: [PATCH v2 13/14] net: wwan: t7xx: Add debug and test ports
On Mon, Nov 1, 2021 at 6:57 AM Ricardo Martinez
<ricardo.martinez@...ux.intel.com> 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
Powered by blists - more mailing lists