| 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
| ||
|
Message-ID: <22e53878-42e2-78ed-c460-3fa339c306ad@kontron.de>
Date: Thu, 23 Jul 2020 13:51:44 +0200
From: Frieder Schrempf <frieder.schrempf@...tron.de>
To: Robin Gong <yibin.gong@....com>,
"mark.rutland@....com" <mark.rutland@....com>,
"broonie@...nel.org" <broonie@...nel.org>,
"robh+dt@...nel.org" <robh+dt@...nel.org>,
"catalin.marinas@....com" <catalin.marinas@....com>,
"vkoul@...nel.org" <vkoul@...nel.org>,
"will.deacon@....com" <will.deacon@....com>,
"shawnguo@...nel.org" <shawnguo@...nel.org>,
"festevam@...il.com" <festevam@...il.com>,
"s.hauer@...gutronix.de" <s.hauer@...gutronix.de>,
"martin.fuzzey@...wbird.group" <martin.fuzzey@...wbird.group>,
"u.kleine-koenig@...gutronix.de" <u.kleine-koenig@...gutronix.de>,
"dan.j.williams@...el.com" <dan.j.williams@...el.com>,
"matthias.schiffer@...tq-group.com"
<matthias.schiffer@...tq-group.com>
Cc: "linux-spi@...r.kernel.org" <linux-spi@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"kernel@...gutronix.de" <kernel@...gutronix.de>,
"dmaengine@...r.kernel.org" <dmaengine@...r.kernel.org>,
dl-linux-imx <linux-imx@....com>
Subject: Re: [PATCH v10 05/12] dmaengine: dma: imx-sdma: add fw_loaded and
is_ram_script
On 23.07.20 13:12, Robin Gong wrote:
>> On 2020/07/23 17:04 Frieder Schrempf <frieder.schrempf@...tron.de>
>> wrote:
>>> Hi Robin,
>>>
>>> On 30.06.20 15:31, Robin Gong wrote:
>>>> Add 'fw_loaded' and 'is_ram_script' to check if the script used by
>>>> channel is ram script and it's loaded or not, so that could prevent
>>>> meaningless following malloc dma descriptor and bd allocate in
>>>> sdma_transfer_init(), otherwise memory may be consumed out
>>>> potentially without free in case that spi fallback into pio while
>>>> dma transfer failed by sdma firmware not ready(next ERR009165 patch
>>>> depends on sdma
>>> RAM scripts/firmware).
>>>>
>>>> Signed-off-by: Robin Gong <yibin.gong@....com>
>>>> Acked-By: Vinod Koul <vkoul@...nel.org>
>>>> ---
>>>> drivers/dma/imx-sdma.c | 13 +++++++++++++
>>>> 1 file changed, 13 insertions(+)
>>>>
>>>> diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c index
>>>> 5411e01e..ce1c83e 100644
>>>> --- a/drivers/dma/imx-sdma.c
>>>> +++ b/drivers/dma/imx-sdma.c
>>>> @@ -379,6 +379,7 @@ struct sdma_channel {
>>>> enum dma_status status;
>>>> struct imx_dma_data data;
>>>> struct work_struct terminate_worker;
>>>> + bool is_ram_script;
>>>> };
>>>>
>>>> #define IMX_DMA_SG_LOOP BIT(0)
>>>> @@ -443,6 +444,7 @@ struct sdma_engine {
>>>> struct sdma_buffer_descriptor *bd0;
>>>> /* clock ratio for AHB:SDMA core. 1:1 is 1, 2:1 is 0*/
>>>> bool clk_ratio;
>>>> + bool fw_loaded;
>>>> };
>>>>
>>>> static int sdma_config_write(struct dma_chan *chan, @@ -929,6
>>>> +931,7 @@ static void sdma_get_pc(struct sdma_channel *sdmac,
>>>> case IMX_DMATYPE_SSI_DUAL:
>>>> per_2_emi = sdma->script_addrs->ssish_2_mcu_addr;
>>>> emi_2_per = sdma->script_addrs->mcu_2_ssish_addr;
>>>> + sdmac->is_ram_script = true;
>>>> break;
>>>> case IMX_DMATYPE_SSI_SP:
>>>> case IMX_DMATYPE_MMC:
>>>> @@ -943,6 +946,7 @@ static void sdma_get_pc(struct sdma_channel
>>> *sdmac,
>>>> per_2_emi = sdma->script_addrs->asrc_2_mcu_addr;
>>>> emi_2_per = sdma->script_addrs->asrc_2_mcu_addr;
>>>> per_2_per = sdma->script_addrs->per_2_per_addr;
>>>> + sdmac->is_ram_script = true;
>>>> break;
>>>> case IMX_DMATYPE_ASRC_SP:
>>>> per_2_emi = sdma->script_addrs->shp_2_mcu_addr;
>>>> @@ -1339,6 +1343,11 @@ static struct sdma_desc
>>> *sdma_transfer_init(struct sdma_channel *sdmac,
>>>> {
>>>> struct sdma_desc *desc;
>>>>
>>>> + if (!sdmac->sdma->fw_loaded && sdmac->is_ram_script) {
>>>> + dev_err(sdmac->sdma->dev, "sdma firmware not ready!\n");
>>>> + goto err_out;
>>>> + }
>>>
>>> I tried your v10 patches on next-20200722 with i.MX8MM and it mostly
>>> seems to work fine.
>>>
>>> When I tried first, I had the imx-sdma driver compiled into the
>>> kernel, so it didn't load the firmware and fell back to the ROM scripts.
>>> With this, SPI transactions work just fine, but I got the above error
>>> message printed continuously when sending data in SPI3 via spidev.
>> That's caused by you didn't load ram firmware as this patch set described.
>> Please follow below steps to load firmware manually if you don't want to use
>> NXP official Yocto release package:
>>
>> 1. Get sdma firmware from below linux-firmware and copy it to your local
>> rootfs /lib/firmware/imx/sdma.
>> https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Ffirmware%2Flinux-firmware.git%2Ft&data=02%7C01%7Cfrieder.schrempf%40kontron.de%7C08276b76f9a14dae1f8408d82ef94da1%7C8c9d3c973fd941c8a2b1646f3942daf1%7C0%7C0%7C637310995564511410&sdata=YA1455ILoNgRDHAOy1H2051J9cu5VsHk39xtQive8mo%3D&reserved=0
>> ree/imx/sdma
>> 2. Load firmware manually:
>> echo 1 > /sys/$DEVPATH/loading
>> cat $MY_FW_DIR/$FIRMWARE > /sys/$DEVPATH/data
>> echo 0 > /sys/$DEVPATH/loading
>> Please refer to Documentation/driver-api/firmware/fallback-mechanisms.rst
>> and load the firmware in 60s (firmware fallback loading timeout) from kernel
>> boot up.
>>
>>>
>>> When I build imx-sdma as a module, the firmware is loaded correctly
>>> and everything works as expected.
>> I guess that's not related with sdma building as module. If sdma build as
>> module, spi will fall to pio mode at spi-imx driver probe phase so that the
>> above warning log never to be walked. Would you please add some debug
>> info to double confirm?
> Hi Frider,
> Please ignore this comment, since there is -EPROBE_DEFER checking
> , so you load sdma firmware by building sdma driver as module instead of
> the above comment I mentioned?
Yes, correct.
> The warning log comes out during spi
> transfer start and sdma firmware loading done, but if sdma driver building as
> module could ensure firmware loading done in sdma_driver_probe_phase->
> spi_imx_probe_phase, which means sdma firmware loading has been ready
> before spi transfer start, hence no such warning message.
>
> But I am not sure if all client drivers except spi are in good shape to support
> ' CONFIG_IMX_SDMA=m '.
I'm pretty sure that CONFIG_IMX_SDMA=m is supported and common.
Otherwise it wouldn't be an option in Kconfig.
> Besides, do you think 'dev_err_once ' instead of 'dev_err' is okay for you?
I can't really judge if this is a proper fix as I haven't looked at the
code in detail, but if you want to use dev_err_once(), that would be ok
for me, maybe even better dev_warn_once().
As chances are that even without firmware transfers will work a warning
instead of an error makes more sense to me.
Powered by blists - more mailing lists