linux-kernel - Re: [PATCH v2 3/9] tty: serial: fsl_lpuart: handle EPROBE

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]

Date:   Thu, 27 Feb 2020 16:48:54 -0600
From:   Li Yang <leoyang.li@....com>
To:     Rob Herring <robh+dt@...nel.org>
Cc:     Michael Walle <michael@...le.cc>,
        "open list:SERIAL DRIVERS" <linux-serial@...r.kernel.org>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" 
        <linux-arm-kernel@...ts.infradead.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Mark Rutland <mark.rutland@....com>,
        Shawn Guo <shawnguo@...nel.org>, Jiri Slaby <jslaby@...e.com>,
        Peng Fan <peng.fan@....com>,
        Vabhav Sharma <vabhav.sharma@....com>
Subject: Re: [PATCH v2 3/9] tty: serial: fsl_lpuart: handle EPROBE_DEFER for DMA

On Thu, Feb 27, 2020 at 4:35 PM Rob Herring <robh+dt@...nel.org> wrote:
>
> On Fri, Feb 21, 2020 at 11:48 AM Michael Walle <michael@...le.cc> wrote:
> >
> > The DMA channel might not be available at the first probe time. This is
> > esp. the case if the DMA controller has an IOMMU mapping.
> >
> > Use the new dma_request_chan() API and handle EPROBE_DEFER errors. Also
> > reorder the code a bit, so that we don't prepare the whole UART just to
> > determine that the DMA channel is not ready yet and we have to undo all
> > the stuff. Try to map the DMA channels earlier.
>
> Changing this means you never probe successfully if you boot a kernel
> with the DMA driver disabled (or it's IOMMU disabled). Some other
> drivers request DMA in open() and can work either way.

We got this exact issue previously with another driver.  When the
required DMA driver is disabled, the DMA framework cannot figure out
this situation and keeps returning EPROBE_DEFER.  I'm wondering if we
should update the DMA framework to use your deferred probe timeout
mechanism.  Is it still only used for debug purpose?

Regards,
Leo