All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sudeep Holla <sudeep.holla@arm.com>
To: Cristian Marussi <cristian.marussi@arm.com>
Cc: Mikhail Golubev <mikhail.golubev@opensynergy.com>,
	Peter Hilber <peter.hilber@opensynergy.com>,
	Igor Skalkin <Igor.Skalkin@opensynergy.com>,
	linux-arm-kernel@lists.infradead.org,
	Anton Yakovlev <Anton.Yakovlev@opensynergy.com>
Subject: Re: [PATCH v2 0/4] firmware: arm_scmi: Enable building SCMI as module
Date: Tue, 8 Sep 2020 12:11:14 +0100	[thread overview]
Message-ID: <20200908111105.GA16927@bogus> (raw)
In-Reply-To: <20200908090844.GA30729@e119603-lin.cambridge.arm.com>

On Tue, Sep 08, 2020 at 10:08:44AM +0100, Cristian Marussi wrote:
> Hi Sudeep
>
> On Mon, Sep 07, 2020 at 08:50:42PM +0100, Sudeep Holla wrote:
> > Hi,
> >
> > Though it was initially developed as module, so some reason(I can't
> > recollect why apart from some structuring arounf the way bus and
> > protocols were initialised), it was merged as a built-in only driver.
> >
> > Now, there is a need to build this as modules. This is mainly needed
> > by virtio transport. This also aligns well with GKI modularisation
> > efforts.
> >
> > Regards,
> > Sudeep
> >
>
> I re-tested this v2 (also regarding some interactions with notifications) and
> works generally fine for me, both builtin or modularized, BUT I've seen an
> issue on core module load/unload/load.
> Basically doing this:
>
> (debian-arm64)root@debarm64:~# insmod ./scmi-module.ko
> (debian-arm64)root@debarm64:~# insmod ./scmi-cpufreq.ko
>
> (debian-arm64)root@debarm64:~# rmmod ./scmi-cpufreq.ko
> (debian-arm64)root@debarm64:~# rmmod ./scmi-module.ko
> (debian-arm64)root@debarm64:~# lsmod
> Module                  Size  Used by
> (debian-arm64)root@debarm64:~# insmod ./scmi-module.ko
>
> I've got this:
>
>
> [  146.982413] mhu 2b1f0000.mhu: Channel in use
> [  146.982433] arm-scmi firmware:scmi: failed to request SCMI Tx mailbox
> [  146.982472] arm-scmi: probe of firmware:scmi failed with error -16
>
> and SCMI is broken then after reloading.
>
> Now this is an issue I've seen already in my ongoing WIP on full SCMI Protocols
> modularization for custom protocols, and it is related to the fact the the
> underlying transport init is bound to the SCMI device creation and not the
> protocol initialization, and we are not destroying and re-creating such
> devices properly. (things that I'm going to address in that WIP)
>
> Given that the solution to this is not so simple as of now, and given that
> unloading of the core as a whole module does not make so much sense anyway
> (while it will be needed for single custom protocols modules), couldn't we
> just make scmi-module a permanent by droppping module_exit() ?

Now I remember why I had bus_exit before unregistering the driver. I think
that should fix the issue. Let me know.

--
Regards,
Sudeep

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2020-09-08 11:12 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-07 19:50 [PATCH v2 0/4] firmware: arm_scmi: Enable building SCMI as module Sudeep Holla
2020-09-07 19:50 ` [PATCH v2 1/4] firmware: smccc: export both smccc functions Sudeep Holla
2020-09-07 19:50 ` [PATCH v2 2/4] firmware: arm_scmi: Move scmi bus init and exit calls into the driver Sudeep Holla
2020-09-07 19:50 ` [PATCH v2 3/4] firmware: arm_scmi: Move scmi protocols registration " Sudeep Holla
2020-09-07 19:50 ` [PATCH v2 4/4] firmware: arm_scmi: Enable building as a single module Sudeep Holla
2020-09-08  9:08 ` [PATCH v2 0/4] firmware: arm_scmi: Enable building SCMI as module Cristian Marussi
2020-09-08 11:11   ` Sudeep Holla [this message]
2020-09-08 11:53     ` Cristian Marussi
2020-09-08 12:10       ` Sudeep Holla
2020-09-14  6:36 ` Sudeep Holla

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=20200908111105.GA16927@bogus \
    --to=sudeep.holla@arm.com \
    --cc=Anton.Yakovlev@opensynergy.com \
    --cc=Igor.Skalkin@opensynergy.com \
    --cc=cristian.marussi@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=mikhail.golubev@opensynergy.com \
    --cc=peter.hilber@opensynergy.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.