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: <c14dd693-74e6-7e48-9697-849f44b8e0d9@ti.com>
Date:   Thu, 21 Nov 2019 10:40:44 +0200
From:   Peter Ujfalusi <peter.ujfalusi@...com>
To:     Geert Uytterhoeven <geert@...ux-m68k.org>
CC:     Mark Brown <broonie@...nel.org>, Vinod <vkoul@...nel.org>,
        linux-spi <linux-spi@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] spi: pic32: Retire dma_request_slave_channel_compat()

Hi Geert,

On 21/11/2019 10.30, Geert Uytterhoeven wrote:
> Hi Peter,
> 
> On Thu, Nov 21, 2019 at 9:11 AM Peter Ujfalusi <peter.ujfalusi@...com> wrote:
>> There is no reason to use the dma_request_slave_channel_compat() as no
>> filter function and parameter is provided.
>>
>> Switch the driver to use dma_request_chan() instead.
>>
>> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@...com>
> 
>> --- a/drivers/spi/spi-pic32.c
>> +++ b/drivers/spi/spi-pic32.c
>> @@ -609,22 +609,18 @@ static void pic32_spi_cleanup(struct spi_device *spi)
>>  static void pic32_spi_dma_prep(struct pic32_spi *pic32s, struct device *dev)
>>  {
>>         struct spi_master *master = pic32s->master;
>> -       dma_cap_mask_t mask;
>>
>> -       dma_cap_zero(mask);
>> -       dma_cap_set(DMA_SLAVE, mask);
>> -
>> -       master->dma_rx = dma_request_slave_channel_compat(mask, NULL, NULL,
>> -                                                         dev, "spi-rx");
>> -       if (!master->dma_rx) {
>> +       master->dma_rx = dma_request_chan(dev, "spi-rx");
> 
> Why not dma_request_slave_channel()?

The longer term plan is to retire dma_request_slave_channel() as well.
With dma_request_chan() deferred probing against DMA drivers is possible
and it also supports legacy boot with dma_slave_map.

At the end we should be left with only dma_request_chan() for slave
channels in the kernel.

> That way you...
> 
>> +       if (IS_ERR(master->dma_rx)) {
> 
> ... don't have to change the NULL check here, and...
> 
>>                 dev_warn(dev, "RX channel not found.\n");
>> +               master->dma_rx = NULL;
> 
> ...  don't have to override by NULL here.

It is a small sacrifice, true, but if anyone cares the driver can
support deferred probing with dma_request_chan().

> 
> (same for TX below).
> 
> Gr{oetje,eeting}s,
> 
>                         Geert
> 

- Péter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ