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: Tue, 13 Oct 2015 08:52:21 -0700 From: Suravee Suthikulpanit <suravee.suthikulpanit@....com> To: Bjorn Helgaas <bhelgaas@...gle.com> CC: <rjw@...ysocki.net>, <lenb@...nel.org>, <catalin.marinas@....com>, <will.deacon@....com>, <hanjun.guo@...aro.org>, <linux-acpi@...r.kernel.org>, <linux-pci@...r.kernel.org>, <linux-kernel@...r.kernel.org>, <linux-arm-kernel@...ts.infradead.org>, Rob Herring <robh+dt@...nel.org> Subject: Re: [PATCH V3 2/4] ACPI/scan: Clean up acpi_check_dma Hi Bjorn, Thanks for your feedback. And sorry for late response. Some how I didn't see this earlier. Please see my comments below. On 09/14/2015 09:34 AM, Bjorn Helgaas wrote: >> [..] >> So, in order to simplify the function, this patch renames acpi_check_dma() >> to acpi_check_dma_coherency() to clearly indicate the purpose of this >> function, and only returns an integer where -1 means DMA not supported, >> 1 means coherent DMA, and 0 means non-coherent DMA. > > I think acpi_check_dma_coherency() is better, but only slightly. It > still doesn't give a hint about the *sense* of the return value. I > think it'd be easier to read if there were two functions, e.g., I have been going back-and-forth between the current version, and the two-function-approach in the past. I can definitely go with this route if you would prefer. Although, if acpi_dma_is_coherent() == 0, it would be ambiguous whether DMA is not supported or non-coherent DMA is supported. Then, we would need to call acpi_dma_is_supported() to find out. So, that's okay with you? >> [...] >> + >> + /** >> + * Currently, we only support _CCA=1 (i.e. coherent_dma=1) >> + * This should be equivalent to specifying dma-coherent for >> + * a device in OF. >> + * >> + * For the case when _CCA=0 (i.e. coherent_dma=0 && cca_seen=1), >> + * we have two choices: >> + * 1. Do not support and disable DMA. > > I know you didn't write this comment, but do we actually *disable* DMA in > the sense of turning off PCI bus mastering or calling an ACPI method that > disables DMA by this device? I suspect we just don't set up DMA ops and > masks for this device. Actually, I wrote this comment. When we disable DMA, we basically set dma-mask=0 and do not setup DMA ops as you mentioned. We don't actually mess with the hardware. Thanks, Suravee -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists