From: Andi Shyti <andi.shyti@linux.intel.com>
To: Mauro Carvalho Chehab <mauro.chehab@linux.intel.com>
Cc: igt-dev@lists.freedesktop.org,
Ch Sai Gowtham <sai.gowtham.ch@intel.com>,
Petri Latvala <petri.latvala@intel.com>,
Andrzej Hajda <andrzej.hajda@intel.com>
Subject: Re: [igt-dev] [PATCH i-g-t v2 3/6] lib/igt_kmod: improve audio unbind logic
Date: Thu, 5 May 2022 18:44:43 +0200 [thread overview]
Message-ID: <YnP++wDyxg1Me+jA@intel.intel> (raw)
In-Reply-To: <20220504095904.2145592-4-mauro.chehab@linux.intel.com>
Hi Mauro,
> +static struct module_ref *read_module_dependencies(unsigned int *num_mod)
> +{
> + FILE *fp = fopen("/proc/modules", "r");
> + struct module_ref *mod = NULL;
> + size_t line_buf_size = 0;
> + char *required_by, *p;
> + unsigned n_mod = 0;
> + unsigned num_req;
> + char *line = NULL;
> + int len = 0;
> + int i, ret;
> +
> + igt_assert(fp);
> +
> + while ((len = getline(&line, &line_buf_size, fp)) > 0) {
> + mod = realloc(mod, (n_mod + 1) * sizeof(*mod));
> + igt_assert(mod);
> + mod[n_mod].required_by = NULL;
> +
> + p = strtok(line, " ");
> + mod[n_mod].name = strdup(p);
> +
> + p = strtok(NULL, " ");
> + ret = sscanf(p, "%lu", &mod[n_mod].mem);
> + igt_assert(ret == 1);
> +
> + p = strtok(NULL, " ");
> + ret = sscanf(p, "%u", &mod[n_mod].ref_count);
> + igt_assert(ret == 1);
> +
> + num_req = 0;
> + required_by = strtok(NULL, " ");
> + if (strcmp(required_by, "-")) {
> + p = strtok(required_by, ",");
> + while (p) {
> + for (i = 0; i < n_mod; i++) {
> + if (!strcmp(p, mod[i].name))
> + break;
> + }
brackets not needed here
> + igt_assert(i < n_mod);
> +
> + mod[n_mod].required_by = realloc(mod[n_mod].required_by,
> + (num_req + 1) * sizeof(unsigned int));
> + mod[n_mod].required_by[num_req] = i;
> + num_req++;
> + p = strtok(NULL, ",");
> + }
> + }
> + mod[n_mod].num_required = num_req;
> + n_mod++;
> + }
> + free(line);
> + fclose(fp);
> +
> + *num_mod = n_mod;
> + return mod;
> +}
it looks correct, haven't spotted any error in this function, but
I admit that string parsing can be complex. I trust you have
tested it properly. I will check it again, though.
[...]
> +#define LINUX_VERSION(major, minor, patch) \
> + ((major) << 16 | (minor) << 8 | (patch))
I can't believe that the glibc is not providing anything similar.
> +
> +
you have an extra line here
> +static int linux_kernel_version(void)
> +{
> + struct utsname utsname;
> + int ver[3] = { 0 };
[...]
> +
> +int igt_audio_driver_unload(const char **who)
ha! this confused me because I start reading from the bottom and
I didn't notice the above
-int igt_audio_driver_unload(const char **who)
+static int igt_always_unload_audio_driver(const char **who)
> +{
> + unsigned int num_mod, i, j;
> + struct module_ref *mod;
> + int pos = -1;
> + int ret = 0;
> +
> + /*
> + * On older Kernels, there's no way to check if the audio driver
> + * binds into the DRM one. So, always remove audio drivers that
> + * might be binding.
> + */
> + if (linux_kernel_version() < LINUX_VERSION(5, 20, 0))
> + return igt_always_unload_audio_driver(who);
... so that this one becomes what you did in patch 1.
> +
> + /*
> + * Newer Kernels gained support for showing the dependencies between
> + * audio and DRM drivers via /proc/modules and lsmod. Use it to
> + * detect if removing the audio driver is needed, properly unloading
> + * any audio processes that could be using the audio driver and
> + * handling module dependencies. Such solution should be generic
> + * enough to work with newer SOC/SOF drivers if ever needed.
> + */
> +
> + mod = read_module_dependencies(&num_mod);
> +
> + for (i = 0; i < num_mod; i++) {
> + if (!strcmp(mod[i].name, "i915")) {
> + break;
> + }
> + }
no need for brackets here.
> +
> + if (i == num_mod)
> + return 0;
> +
> + /* Recursively remove all drivers that depend on i915 */
> + for (j = 0; j < mod[i].num_required; j++) {
> + pos = mod[i].required_by[j];
> + if (who)
> + *who = strdup(mod[pos].name);
> + /*
> + * If a sound driver depends on i915, kill audio processes
> + * first, in order to make it possible to unload the driver
> + */
> + if (strstr(mod[pos].name, "snd")) {
> + if (igt_lsof_kill_audio_processes()) {
> + ret = 1;
is this a boolean function? Shall we choose some proper errnos?
> + goto ret;
do we need to free who here...
> + }
> + }
> + ret = igt_unload_driver(mod, num_mod, pos);
... and here?
And here... do we need to handle the error?
> + }
> +
> +ret:
> + free_module_ref(mod, num_mod);
> +
> + return ret;
> +}
Thanks,
Andi
next prev parent reply other threads:[~2022-05-05 16:44 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-04 9:58 [igt-dev] [PATCH i-g-t v2 0/6] Improve logic to work with audio dependency on DRM driver Mauro Carvalho Chehab
2022-05-04 9:58 ` [igt-dev] [PATCH i-g-t v2 1/6] tests/core_hotunplug: properly finish processes using audio devices Mauro Carvalho Chehab
2022-05-05 15:54 ` Andi Shyti
2022-05-05 17:52 ` Andi Shyti
2022-05-06 8:36 ` Mauro Carvalho Chehab
2022-05-04 9:59 ` [igt-dev] [PATCH i-g-t v2 2/6] lib/igt_kmod: always fill who when unloading audio driver Mauro Carvalho Chehab
2022-05-05 15:57 ` Andi Shyti
2022-05-04 9:59 ` [igt-dev] [PATCH i-g-t v2 3/6] lib/igt_kmod: improve audio unbind logic Mauro Carvalho Chehab
2022-05-05 16:44 ` Andi Shyti [this message]
2022-05-06 9:12 ` Mauro Carvalho Chehab
2022-05-04 9:59 ` [igt-dev] [PATCH i-g-t v2 4/6] core_hotunplug: fix " Mauro Carvalho Chehab
2022-05-05 17:22 ` Andi Shyti
2022-05-04 9:59 ` [igt-dev] [PATCH i-g-t v2 5/6] lib/igt_kmod: make it less pedantic with audio driver removal Mauro Carvalho Chehab
2022-05-05 17:57 ` Andi Shyti
2022-05-04 9:59 ` [igt-dev] [PATCH i-g-t v2 6/6] lib/igt_kmod: properly handle pipewire-pulse Mauro Carvalho Chehab
2022-05-05 18:18 ` Andi Shyti
2022-05-06 6:32 ` Mauro Carvalho Chehab
2022-05-04 11:57 ` [igt-dev] ✗ Fi.CI.BAT: failure for Improve logic to work with audio dependency on DRM driver Patchwork
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YnP++wDyxg1Me+jA@intel.intel \
--to=andi.shyti@linux.intel.com \
--cc=andrzej.hajda@intel.com \
--cc=igt-dev@lists.freedesktop.org \
--cc=mauro.chehab@linux.intel.com \
--cc=petri.latvala@intel.com \
--cc=sai.gowtham.ch@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.