linux-kernel - Re: [PATCH] soc: qcom: Introduce WCNSS

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20151022135056.GV24668@usrtlx11787.corpusers.net>
Date:	Thu, 22 Oct 2015 06:50:56 -0700
From:	Bjorn Andersson <bjorn.andersson@...ymobile.com>
To:	yfw <fengwei.yin@...aro.org>
CC:	Andy Gross <agross@...eaurora.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-msm@...r.kernel.org" <linux-arm-msm@...r.kernel.org>,
	"linux-soc@...r.kernel.org" <linux-soc@...r.kernel.org>
Subject: Re: [PATCH] soc: qcom: Introduce WCNSS_CTRL SMD client

On Thu 22 Oct 03:25 PDT 2015, yfw wrote:

> Hi Bjorn,
> 
> On 2015/9/22 1:52, Bjorn Andersson wrote:
[..]
> 
> I have a question: Do you have plan to add the nob to trigger wcnss firmware
> downloading which is also common for wifi and BT?
> 

In caf the wcnss driver is actually two drivers intermingled;
* a SMD client driver, responsible for pushing NV, something related to
  calibration, some power properties and so on

* a platform_driver implementing the wcnss specifics of the PIL through
  some hooks and providing the knob to trigger the PIL.

The first driver is related to the "OS" running on the wcnss, so that
should follow the life cycle of the SMD channel "WCNSS_CTRL". This is
what this patch provides - it loads the NV every time the wcnss core is
booted.

For the second part, I strongly believe that the PIL implementation
should deal with the specifics (e.g. regulator handling and
xo_calibration), rather than having a piece bolted on elsewhere - so
that's in the remoteproc-wcnss driver.

Left is a mechanism to trigger the thing to boot and shutdown. One
potential solution would be to have the module_init/exit call
rproc_boot/shutdown from the WiFi & BT drivers. That way if one loads
the wcn36xx driver, the core is booted. This would also fit quite nicely
for other things - e.g. load the ALSA driver to trigger the ADSP
loading.

The problem here is that we're then forced to either have a method of
deferring the rproc_boot() until the firmware is available or we always
must compile these drivers as kernel modules. This because the
file system isn't there during boot to provide the firmware.

We do have the same thing in e.g. the Broadcom WiFi/BT solution and
there seems to be discussions related to this.

So for now, I punted and put a knob in the wcnss remoteproc driver.

Regards,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/