linux-kernel - Re: [PATCH 2/5] dmaengine: Add STM32 DMAMUX driver

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] [day] [month] [year] [list]

Message-ID: <15dd7c9c-2de3-a575-5936-cd1d1124f59b@st.com>
Date:   Thu, 4 May 2017 15:28:14 +0000
From:   Pierre Yves MORDRET <pierre-yves.mordret@...com>
To:     Vinod Koul <vinod.koul@...el.com>
CC:     "M'boumba Cedric Madianga" <cedric.madianga@...il.com>,
        "mark.rutland@....com" <mark.rutland@....com>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        Alexandre TORGUE <alexandre.torgue@...com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "robh+dt@...nel.org" <robh+dt@...nel.org>,
        "mcoquelin.stm32@...il.com" <mcoquelin.stm32@...il.com>,
        "dmaengine@...r.kernel.org" <dmaengine@...r.kernel.org>,
        "dan.j.williams@...el.com" <dan.j.williams@...el.com>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH 2/5] dmaengine: Add STM32 DMAMUX driver

On 05/01/2017 08:03 AM, Vinod Koul wrote:
> On Wed, Apr 26, 2017 at 09:17:37AM +0000, Pierre Yves MORDRET wrote:
>>>> +
>>>> +	ret = of_property_read_u32(node, "dma-channels",
>>>> +				   &dmamux->dmamux_channels);
>>>
>>> can we have property_xxx calls alone, that way driver is not strictly
>>> dependent on of
>>
>> Can you please explain what you are asking for ? Not sure to understand
>> correctly.
>
> Use device_property_read_u32() which is a generic property API.

OK Will be done in V2

>
>
>>>> +static int __init stm32_dmamux_init(void)
>>>> +{
>>>> +	return platform_driver_register(&stm32_dmamux_driver);
>>>> +}
>>>> +arch_initcall(stm32_dmamux_init);
>>>
>>> why not module init, wouldnt defer probe solve the dependencies
>>>
>>
>> The reason behind many devices (device_initcall level) rely on DMAs. If
>> init is deferred DMAMUX driver will be probed twice if dependents rely
>> on it. This sounds not a good call. This explains arch_initcall level.
>
> Why not deferred probe was introduced to help with dependencies...
>

Most DMAs devices are already in subsys_initcall to avoid multiple 
useless probe when clients are deferred. This DMAMUx is itself on top of 
DMAs.
DMAMUX ---> DMA#1 ---> Device Client #1
        |          |--> Device Client #2
        |               [...]
        |          |--> Device Client #N
        |    [...]
        |--> DMA#N ---> Device Client #1
                   |--> Device Client #2
                        [...]
                   |--> Device Client #N
arch_initcall might a good call in this case for DMAMUX.