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
| ||
|
Date: Fri, 28 Feb 2020 12:46:01 +0100 From: Michael Walle <michael@...le.cc> To: Rob Herring <robh+dt@...nel.org> Cc: Li Yang <leoyang.li@....com>, "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, "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 Hi Rob, Hi Leo, Am 2020-02-28 00:03, schrieb Rob Herring: > On Thu, Feb 27, 2020 at 4:49 PM Li Yang <leoyang.li@....com> wrote: >> >> 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. Oh, I see. >> We got this exact issue previously with another driver. When the What driver is it? I've been working on the i2c-mxs.c driver which has the same problem. Ie. its not working with DMA when the IOMMU is enabled. Now that I've learned that dma_request_chan() will return EPROBE_DEFER if the actual DMA driver is not available, I don't think there is any trick like this there. There is no function which would be called late except you'd do something like on the first master_xfer() try to request the DMA channels. But I don't think that would be the way to go. -michael >> 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? > > It's undergoing some rework ATM to not just be for debug. However, > it's not really going to help you if you care about the console > because waiting for the timeout will be too late to register the > console.
Powered by blists - more mailing lists