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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 17 Jul 2014 01:20:54 +0000 From: Peter Chen <Peter.Chen@...escale.com> To: Arnd Bergmann <arnd@...db.de> CC: Antoine Ténart <antoine.tenart@...e-electrons.com>, "sebastian.hesselbarth@...il.com" <sebastian.hesselbarth@...il.com>, "balbi@...com" <balbi@...com>, "p.zabel@...gutronix.de" <p.zabel@...gutronix.de>, "alexandre.belloni@...e-electrons.com" <alexandre.belloni@...e-electrons.com>, "thomas.petazzoni@...e-electrons.com" <thomas.petazzoni@...e-electrons.com>, "zmxu@...vell.com" <zmxu@...vell.com>, "jszhang@...vell.com" <jszhang@...vell.com>, "linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>, "linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>, "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org> Subject: RE: [PATCH v3 07/12] usb: chipidea: add a usb2 driver for ci13xxx > > > > > > > > Some people wanted the possibility to set the DMA mask as this > > > > USB2 CI driver does not do specific Berlin operation and can be > reused later. > > > > I don't particularly need to call dma_coerce_mask_and_coherent() > > > > in my case, as far as I know. > > > > > > Ok, just remove the call then and rely on the default mask. > > > > > > > They can maybe give the restrictions they might want to put on the > > > > DMA mask. > > > > > > If the restriction is from the bus, it should get handled > > > automatically by the device probe as long as the correct dma-ranges > > > property is there (though we have a small bug there at the moment). > > > If there is a variation of ci13xxx that can't do 32-bit DMA, that > > > should use a different compatible string and pass a fixed mask into > > > dma_set_mask_and_coherent() based on the device. > > > > > > > Correct me if my below understanding is wrong please. > > > > For three chipidea users: > > user_a: don't need dma mask > > user_b: dma mask value is dma_mask_b > > user_c: dma mask value is dma_mask_c > > > > We don't need to call dma_coerce_mask_and_coherent() at generic > > chipidea glue driver, and set dma-ranges as dma_mask_b at user_b's > > dts, and set dma-ranges as dma_mask_c at user_c's dts. > > The dma-ranges property doesn't just encode a dma-mask for a device, but > rather how the children of a bus see the memory address space of the > parent. > > For traditional reasons we default to assuming that a 32-bit dma_mask is > correct, but there may be multiple reasons why this is not true: > > - you have a device connected to a bus that is smaller than 32-bit wide > (and that would have a dma-ranges property describing that) > - you have a device that has fewer than 32 address lines but is connected > to a 32-bit upstream bus (hence the dma-ranges describe all 32 bit, > but the driver must set a smaller mask) > - you have a 64-bit capable device connected to a 32-bit bus: the driver > will ask for a 64-bit mask, but the dma_set_mask() call refuses this > because of the bus capabilities. > - you have a 64-bit capable device on a 64-bit capable bus, and the > dma_set_mask call should succeed. > > The mask is definitely never "user" specific, but is a combination of the > device you have and the bus it is connected to. > Thanks, arnd. For chipidea generic glue layer case, if there are three devices who use this driver, and all devices have 32-bit bus, some devices have less 32 address lines. For example: - the device_a doesn't need to use dma_mask - the device_b needs dma_mask as 0xfffffffff - the device_c needs dma_mask as 0xfffffff0, assume it has only 28 address lines My questions are: - Can we not set dma_mask at driver, and only set dma-ranges at dts for device_b and device_c as a solution to cover this different dma mask use case? - If we can't use this solution, would you suggest one? - If we can use this solution, for device_b and device_c, how can we write dma-ranges? I can't find any arm platforms use it, only some powerpc platform use it. According to the definition from Power_ePAPR_APPROVED_v1.1.pdf, it is dma-ranges = <child-bus-address, parent-bus-address, length> but I find the powerpc has different way for using dma-ranges. Peter -- 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