linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Cristian Marussi <cristian.marussi@arm.com>
To: Sudeep Holla <sudeep.holla@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:53:05 +0100	[thread overview]
Message-ID: <20200908115305.GA6904@e119603-lin.cambridge.arm.com> (raw)
In-Reply-To: <20200908111105.GA16927@bogus>

On Tue, Sep 08, 2020 at 12:11:14PM +0100, Sudeep Holla wrote:
> 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.
> 

Yes that works for me, both as builtin or as a module now.

Cristian

> --
> 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:53 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
2020-09-08 11:53     ` Cristian Marussi [this message]
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=20200908115305.GA6904@e119603-lin.cambridge.arm.com \
    --to=cristian.marussi@arm.com \
    --cc=Anton.Yakovlev@opensynergy.com \
    --cc=Igor.Skalkin@opensynergy.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=mikhail.golubev@opensynergy.com \
    --cc=peter.hilber@opensynergy.com \
    --cc=sudeep.holla@arm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).