Re: [PATCH/RFC 0/4] Probe deferral for IOMMU DT integration
Hi Marek, On Wednesday 04 March 2015 10:20:36 Marek Szyprowski wrote: > On 2015-02-16 17:14, Laurent Pinchart wrote: > > On Thursday 05 February 2015 16:31:58 Laura Abbott wrote: > >> Hi, > >> > >> On the heels of Exynos integrating SMMU in to the DT for probing, > >> this series attempts to add support to make SMMU drivers work with > >> deferred probing. This has been referenced before[1] but this is > >> some actual code to use as a starting point for discussion. > >> > >> The requirement for this is based on a previous patch to add clock > >> support to the ARM SMMU driver[2]. Once we have clock support, it's > >> possible that the driver itself may need to be defered which breaks > >> a bunch of assumptions about how SMMU probing is supposed to work. > >> The concept here is to have the driver call of_dma_configure which > >> may return -EPROBE_DEFER. of_dma_configure could possibly be moved > >> up to probe level. The existing method of initialization still needs > >> to be done as well which might mean we have the worst of both worlds. > >> > >> Open questions: > >> - This still doesn't really address Arnd's concerns[3] about disabling > >> IOMMUs > > > > Arnd, Will and I have discussed IOMMU probe deferral last week. Here's a > > summary of the discussion, before the details blur away. > > > > The discussion covered both higher level concepts and lower level details, > > in various directions. I'll try to make the summary clear by filling the > > gaps between pieces where needed, so some of the information below might > > not be a direct result of the discussions. Arnd and Will, please feel > > free to correct me. > > > > The first question we've discussed was whether probe deferral for IOMMUs > > is really needed. Various dependencies between IOMMU devices and other > > devices exist, in particular on clocks (as you have mentioned above) and > > on power domains (as mentioned by Marek in > > http://lists.infradead.org/pipermail/linux-arm-kernel/2015-February/32323 > > 8.html). While there are mechanism to handle some of them with probe > > deferral (for instance by using the OF_DECLARE macros to register clock > > drivers), generalizing those mechanisms would essentially recreate a > > probe ordering mechanism similar to link order probe ordering and > > couldn't really scale. > > > > Additionally, IOMMUs could also be present hot-pluggable devices and > > depend on resources that are thus hot-plugged. OF_DECLARE wouldn't help > > in that case. For all those reasons we have concluded that probe deferral > > for IOMMUs is desired if it can be implemented cleanly. > > > > The second question we've discussed was how to implement probe deferral > > cleanly :-) > > > > The current implementation configures DMA at device creation time and sets > > the following properties: > > > > - dma_map_ops (IOMMU, SWIOTLB, linear mapping) > > - initial DMA mask > > - DMA offset > > - DMA coherency > > > > Additionally the IOMMU group (when an IOMMU is present) will also be > > configured at the same time (patches are under review). > > > > The base idea is to defer probing of bus master devices when their IOMMU > > isn't present. Three cases need to be handled. > > > > 1. No IOMMU is declared by the firmware (through DT, ACPI, ...) for the > > bus master device. The bus master device probe doesn't need to be deferred > > due to the IOMMU. dma_map_ops must be set to SWIOTLB or linear mapping > > (the later should likely be implemented through SWIOTLB). > > > > 2. An IOMMU is declared for the bus master device and the IOMMU has been > > successfully probed and registered. The bus master device probe doesn't > > need to be deferred due to the IOMMU. dma_map_ops must be set to IOMMU > > ops. > > > > 3. An IOMMU is declared for the bus master device but the IOMMU isn't > > registered. This can be caused by different reasons: > > > > - a. No driver is loaded for this IOMMU (for instance because DT describes > > the IOMMU connection, but the IOMMU driver hasn't been developed yet, or > > an older kernel is used). If the IOMMU is optional the bus master device > > probe should succeed, and dma_map_ops should be set to linear. If the > > IOMMU is mandatory the bus master device probe should fail. > > > > Note that, as we require IOMMU drivers to be compiled in, we don't need to > > handle the case of loadable IOMMU drivers that haven't been loaded yet. > > > > - b. A driver is loaded for this IOMMU but the IOMMU hasn't been probed > > yet, or its probe has been deferred. The bus master device probe should > > be deferred. > > > > - c. A driver is loaded for this IOMMU but the IOMMU probe has failed > > permanently. It's not clear at the moment whether we should try to recover > > from this automatically using the same mechanism as case 3.a, or if we can > > considered this as an abnormal failure and disable the bus master device. > > > > Assuming that we should try to recover from such an error, we can'
Re: [PATCH/RFC 0/4] Probe deferral for IOMMU DT integration
Hi Will, (CC'ing Thierry Reding who was missing. Thierry, you'll have to look at the archive for the discussion, but here's at least a start pointer) On Wednesday 04 March 2015 15:25:05 Will Deacon wrote: > On Tue, Mar 03, 2015 at 11:54:46PM +, Laurent Pinchart wrote: > > Hello, > > Hi Laurent, > > > I haven't seen any reply to this e-mail. I know that the combination of > > IOMMU, DMA mapping and DT doesn't exactly sound like fun, but I think we > > still need to move on :-) > > Yup, and thanks for taking the time to write this up! > > > Will and Arnd, could you please confirm that my summary below matches your > > memories of our discussion ? > > It certainly matches my recollection, but I suspect the devil is in the > details and we'll have to have some discussions once somebody has a crack at > implementing this. You're not volunteering, are you ? ;-) -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC 0/4] Probe deferral for IOMMU DT integration
On Tue, Mar 03, 2015 at 11:54:46PM +, Laurent Pinchart wrote: > Hello, Hi Laurent, > I haven't seen any reply to this e-mail. I know that the combination of > IOMMU, > DMA mapping and DT doesn't exactly sound like fun, but I think we still need > to move on :-) Yup, and thanks for taking the time to write this up! > Will and Arnd, could you please confirm that my summary below matches your > memories of our discussion ? It certainly matches my recollection, but I suspect the devil is in the details and we'll have to have some discussions once somebody has a crack at implementing this. Will -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC 0/4] Probe deferral for IOMMU DT integration
Hello, On 2015-02-16 17:14, Laurent Pinchart wrote: Hi Laura and all, On Thursday 05 February 2015 16:31:58 Laura Abbott wrote: Hi, On the heels of Exynos integrating SMMU in to the DT for probing, this series attempts to add support to make SMMU drivers work with deferred probing. This has been referenced before[1] but this is some actual code to use as a starting point for discussion. The requirement for this is based on a previous patch to add clock support to the ARM SMMU driver[2]. Once we have clock support, it's possible that the driver itself may need to be defered which breaks a bunch of assumptions about how SMMU probing is supposed to work. The concept here is to have the driver call of_dma_configure which may return -EPROBE_DEFER. of_dma_configure could possibly be moved up to probe level. The existing method of initialization still needs to be done as well which might mean we have the worst of both worlds. Open questions: - This still doesn't really address Arnd's concerns[3] about disabling IOMMUs Arnd, Will and I have discussed IOMMU probe deferral last week. Here's a summary of the discussion, before the details blur away. The discussion covered both higher level concepts and lower level details, in various directions. I'll try to make the summary clear by filling the gaps between pieces where needed, so some of the information below might not be a direct result of the discussions. Arnd and Will, please feel free to correct me. The first question we've discussed was whether probe deferral for IOMMUs is really needed. Various dependencies between IOMMU devices and other devices exist, in particular on clocks (as you have mentioned above) and on power domains (as mentioned by Marek in http://lists.infradead.org/pipermail/linux-arm-kernel/2015-February/323238.html). While there are mechanism to handle some of them with probe deferral (for instance by using the OF_DECLARE macros to register clock drivers), generalizing those mechanisms would essentially recreate a probe ordering mechanism similar to link order probe ordering and couldn't really scale. Additionally, IOMMUs could also be present hot-pluggable devices and depend on resources that are thus hot-plugged. OF_DECLARE wouldn't help in that case. For all those reasons we have concluded that probe deferral for IOMMUs is desired if it can be implemented cleanly. The second question we've discussed was how to implement probe deferral cleanly :-) The current implementation configures DMA at device creation time and sets the following properties: - dma_map_ops (IOMMU, SWIOTLB, linear mapping) - initial DMA mask - DMA offset - DMA coherency Additionally the IOMMU group (when an IOMMU is present) will also be configured at the same time (patches are under review). The base idea is to defer probing of bus master devices when their IOMMU isn't present. Three cases need to be handled. 1. No IOMMU is declared by the firmware (through DT, ACPI, ...) for the bus master device. The bus master device probe doesn't need to be deferred due to the IOMMU. dma_map_ops must be set to SWIOTLB or linear mapping (the later should likely be implemented through SWIOTLB). 2. An IOMMU is declared for the bus master device and the IOMMU has been successfully probed and registered. The bus master device probe doesn't need to be deferred due to the IOMMU. dma_map_ops must be set to IOMMU ops. 3. An IOMMU is declared for the bus master device but the IOMMU isn't registered. This can be caused by different reasons: - a. No driver is loaded for this IOMMU (for instance because DT describes the IOMMU connection, but the IOMMU driver hasn't been developed yet, or an older kernel is used). If the IOMMU is optional the bus master device probe should succeed, and dma_map_ops should be set to linear. If the IOMMU is mandatory the bus master device probe should fail. Note that, as we require IOMMU drivers to be compiled in, we don't need to handle the case of loadable IOMMU drivers that haven't been loaded yet. - b. A driver is loaded for this IOMMU but the IOMMU hasn't been probed yet, or its probe has been deferred. The bus master device probe should be deferred. - c. A driver is loaded for this IOMMU but the IOMMU probe has failed permanently. It's not clear at the moment whether we should try to recover from this automatically using the same mechanism as case 3.a, or if we can considered this as an abnormal failure and disable the bus master device. Assuming that we should try to recover from such an error, we can't predict this case when the device is instantiated (even if IOMMUs are registered before bus master devices are added, for instance using the OF_DECLARE mechanism that Will has implemented). We thus need to setup the dma_map_ops and IOMMU group at bus master device probe time. Furthermore, we can't distinguish cases 3.a and 3.b at bus master probe time without early registration of IOMMU drivers. Case 3.a would instead be considered as
Re: [PATCH/RFC 0/4] Probe deferral for IOMMU DT integration
Hello, I haven't seen any reply to this e-mail. I know that the combination of IOMMU, DMA mapping and DT doesn't exactly sound like fun, but I think we still need to move on :-) Will and Arnd, could you please confirm that my summary below matches your memories of our discussion ? On Monday 16 February 2015 18:14:45 Laurent Pinchart wrote: > On Thursday 05 February 2015 16:31:58 Laura Abbott wrote: > > Hi, > > > > On the heels of Exynos integrating SMMU in to the DT for probing, > > this series attempts to add support to make SMMU drivers work with > > deferred probing. This has been referenced before[1] but this is > > some actual code to use as a starting point for discussion. > > > > The requirement for this is based on a previous patch to add clock > > support to the ARM SMMU driver[2]. Once we have clock support, it's > > possible that the driver itself may need to be defered which breaks > > a bunch of assumptions about how SMMU probing is supposed to work. > > The concept here is to have the driver call of_dma_configure which > > may return -EPROBE_DEFER. of_dma_configure could possibly be moved > > up to probe level. The existing method of initialization still needs > > to be done as well which might mean we have the worst of both worlds. > > > > Open questions: > > - This still doesn't really address Arnd's concerns[3] about disabling > > IOMMUs > > Arnd, Will and I have discussed IOMMU probe deferral last week. Here's a > summary of the discussion, before the details blur away. > > The discussion covered both higher level concepts and lower level details, > in various directions. I'll try to make the summary clear by filling the > gaps between pieces where needed, so some of the information below might > not be a direct result of the discussions. Arnd and Will, please feel free > to correct me. > > The first question we've discussed was whether probe deferral for IOMMUs is > really needed. Various dependencies between IOMMU devices and other devices > exist, in particular on clocks (as you have mentioned above) and on power > domains (as mentioned by Marek in > http://lists.infradead.org/pipermail/linux-arm-kernel/2015-February/323238. > html). While there are mechanism to handle some of them with probe deferral > (for instance by using the OF_DECLARE macros to register clock drivers), > generalizing those mechanisms would essentially recreate a probe ordering > mechanism similar to link order probe ordering and couldn't really scale. > > Additionally, IOMMUs could also be present hot-pluggable devices and depend > on resources that are thus hot-plugged. OF_DECLARE wouldn't help in that > case. For all those reasons we have concluded that probe deferral for > IOMMUs is desired if it can be implemented cleanly. > > The second question we've discussed was how to implement probe deferral > cleanly :-) > > The current implementation configures DMA at device creation time and sets > the following properties: > > - dma_map_ops (IOMMU, SWIOTLB, linear mapping) > - initial DMA mask > - DMA offset > - DMA coherency > > Additionally the IOMMU group (when an IOMMU is present) will also be > configured at the same time (patches are under review). > > The base idea is to defer probing of bus master devices when their IOMMU > isn't present. Three cases need to be handled. > > 1. No IOMMU is declared by the firmware (through DT, ACPI, ...) for the bus > master device. The bus master device probe doesn't need to be deferred due > to the IOMMU. dma_map_ops must be set to SWIOTLB or linear mapping (the > later should likely be implemented through SWIOTLB). > > 2. An IOMMU is declared for the bus master device and the IOMMU has been > successfully probed and registered. The bus master device probe doesn't need > to be deferred due to the IOMMU. dma_map_ops must be set to IOMMU ops. > > 3. An IOMMU is declared for the bus master device but the IOMMU isn't > registered. This can be caused by different reasons: > > - a. No driver is loaded for this IOMMU (for instance because DT describes > the IOMMU connection, but the IOMMU driver hasn't been developed yet, or an > older kernel is used). If the IOMMU is optional the bus master device probe > should succeed, and dma_map_ops should be set to linear. If the IOMMU is > mandatory the bus master device probe should fail. > > Note that, as we require IOMMU drivers to be compiled in, we don't need to > handle the case of loadable IOMMU drivers that haven't been loaded yet. > > - b. A driver is loaded for this IOMMU but the IOMMU hasn't been probed yet, > or its probe has been deferred. The bus master device probe should be > deferred. > > - c. A driver is loaded for this IOMMU but the IOMMU probe has failed > permanently. It's not clear at the moment whether we should try to recover > from this automatically using the same mechanism as case 3.a, or if we can > considered this as an abnormal failure and disable the bus master device. > > Assuming th
Re: [PATCH/RFC 0/4] Probe deferral for IOMMU DT integration
Hi Laura and all, On Thursday 05 February 2015 16:31:58 Laura Abbott wrote: > Hi, > > On the heels of Exynos integrating SMMU in to the DT for probing, > this series attempts to add support to make SMMU drivers work with > deferred probing. This has been referenced before[1] but this is > some actual code to use as a starting point for discussion. > > The requirement for this is based on a previous patch to add clock > support to the ARM SMMU driver[2]. Once we have clock support, it's > possible that the driver itself may need to be defered which breaks > a bunch of assumptions about how SMMU probing is supposed to work. > The concept here is to have the driver call of_dma_configure which > may return -EPROBE_DEFER. of_dma_configure could possibly be moved > up to probe level. The existing method of initialization still needs > to be done as well which might mean we have the worst of both worlds. > > Open questions: > - This still doesn't really address Arnd's concerns[3] about disabling > IOMMUs Arnd, Will and I have discussed IOMMU probe deferral last week. Here's a summary of the discussion, before the details blur away. The discussion covered both higher level concepts and lower level details, in various directions. I'll try to make the summary clear by filling the gaps between pieces where needed, so some of the information below might not be a direct result of the discussions. Arnd and Will, please feel free to correct me. The first question we've discussed was whether probe deferral for IOMMUs is really needed. Various dependencies between IOMMU devices and other devices exist, in particular on clocks (as you have mentioned above) and on power domains (as mentioned by Marek in http://lists.infradead.org/pipermail/linux-arm-kernel/2015-February/323238.html). While there are mechanism to handle some of them with probe deferral (for instance by using the OF_DECLARE macros to register clock drivers), generalizing those mechanisms would essentially recreate a probe ordering mechanism similar to link order probe ordering and couldn't really scale. Additionally, IOMMUs could also be present hot-pluggable devices and depend on resources that are thus hot-plugged. OF_DECLARE wouldn't help in that case. For all those reasons we have concluded that probe deferral for IOMMUs is desired if it can be implemented cleanly. The second question we've discussed was how to implement probe deferral cleanly :-) The current implementation configures DMA at device creation time and sets the following properties: - dma_map_ops (IOMMU, SWIOTLB, linear mapping) - initial DMA mask - DMA offset - DMA coherency Additionally the IOMMU group (when an IOMMU is present) will also be configured at the same time (patches are under review). The base idea is to defer probing of bus master devices when their IOMMU isn't present. Three cases need to be handled. 1. No IOMMU is declared by the firmware (through DT, ACPI, ...) for the bus master device. The bus master device probe doesn't need to be deferred due to the IOMMU. dma_map_ops must be set to SWIOTLB or linear mapping (the later should likely be implemented through SWIOTLB). 2. An IOMMU is declared for the bus master device and the IOMMU has been successfully probed and registered. The bus master device probe doesn't need to be deferred due to the IOMMU. dma_map_ops must be set to IOMMU ops. 3. An IOMMU is declared for the bus master device but the IOMMU isn't registered. This can be caused by different reasons: - a. No driver is loaded for this IOMMU (for instance because DT describes the IOMMU connection, but the IOMMU driver hasn't been developed yet, or an older kernel is used). If the IOMMU is optional the bus master device probe should succeed, and dma_map_ops should be set to linear. If the IOMMU is mandatory the bus master device probe should fail. Note that, as we require IOMMU drivers to be compiled in, we don't need to handle the case of loadable IOMMU drivers that haven't been loaded yet. - b. A driver is loaded for this IOMMU but the IOMMU hasn't been probed yet, or its probe has been deferred. The bus master device probe should be deferred. - c. A driver is loaded for this IOMMU but the IOMMU probe has failed permanently. It's not clear at the moment whether we should try to recover from this automatically using the same mechanism as case 3.a, or if we can considered this as an abnormal failure and disable the bus master device. Assuming that we should try to recover from such an error, we can't predict this case when the device is instantiated (even if IOMMUs are registered before bus master devices are added, for instance using the OF_DECLARE mechanism that Will has implemented). We thus need to setup the dma_map_ops and IOMMU group at bus master device probe time. Furthermore, we can't distinguish cases 3.a and 3.b at bus master probe time without early registration of IOMMU drivers. Case 3.a would in
Re: [PATCH/RFC 0/4] Probe deferral for IOMMU DT integration
Hello, On 2015-02-07 23:41, a...@arndb.de wrote: Laura Abbott hat am 6. Februar 2015 um 01:31 geschrieben: The requirement for this is based on a previous patch to add clock support to the ARM SMMU driver[2]. Once we have clock support, it's possible that the driver itself may need to be defered which breaks a bunch of assumptions about how SMMU probing is supposed to work. Hi Laura, I was hoping that we would not need this, and instead treat the iommu in the same way as timers and SMP initialization, both of which need to be run early at boot time but may rely on clock controllers to be initialized first. Is there a specific requirement that makes this impossible here, or is your intention to solve the problem more nicely by allowing deferred probing over forcing the input clocks of the iommu to be early? I case of Exynos SoCs there is also a dependency on power domains (some might be disabled by the bootloader). It is convenient to use the whole device infrastructure for this although it still doesn't provide any methods of modelling the real power management dependencies. Right now I simply ignored this problem and left it for the future. I will check if this patchset helps in our case. Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC 0/4] Probe deferral for IOMMU DT integration
On 2/7/2015 2:41 PM, a...@arndb.de wrote: Laura Abbott hat am 6. Februar 2015 um 01:31 geschrieben: The requirement for this is based on a previous patch to add clock support to the ARM SMMU driver[2]. Once we have clock support, it's possible that the driver itself may need to be defered which breaks a bunch of assumptions about how SMMU probing is supposed to work. Hi Laura, I was hoping that we would not need this, and instead treat the iommu in the same way as timers and SMP initialization, both of which need to be run early at boot time but may rely on clock controllers to be initialized first. Is there a specific requirement that makes this impossible here, or is your intention to solve the problem more nicely by allowing deferred probing over forcing the input clocks of the iommu to be early? Arnd The current clock driver for qcom targets doesn't support the early initialization needed for timers and SMP because neither of those depend on the clocksources. I discussed this with Stephen some and adding the early support would not mesh well with the device/driver design of the current clock driver so that's not really an option right now. I do think the deferred probing design is cleaner. Even cleaner would be a proper bus type but that's a different can of worms. Thanks, Laura -- Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC 0/4] Probe deferral for IOMMU DT integration
Laura Abbott hat am 6. Februar 2015 um 01:31 geschrieben: > > The requirement for this is based on a previous patch to add clock > support to the ARM SMMU driver[2]. Once we have clock support, it's > possible that the driver itself may need to be defered which breaks > a bunch of assumptions about how SMMU probing is supposed to work. Hi Laura, I was hoping that we would not need this, and instead treat the iommu in the same way as timers and SMP initialization, both of which need to be run early at boot time but may rely on clock controllers to be initialized first. Is there a specific requirement that makes this impossible here, or is your intention to solve the problem more nicely by allowing deferred probing over forcing the input clocks of the iommu to be early? Arnd -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC 0/4] Probe deferral for IOMMU DT integration
Hi, On the heels of Exynos integrating SMMU in to the DT for probing, this series attempts to add support to make SMMU drivers work with deferred probing. This has been referenced before[1] but this is some actual code to use as a starting point for discussion. The requirement for this is based on a previous patch to add clock support to the ARM SMMU driver[2]. Once we have clock support, it's possible that the driver itself may need to be defered which breaks a bunch of assumptions about how SMMU probing is supposed to work. The concept here is to have the driver call of_dma_configure which may return -EPROBE_DEFER. of_dma_configure could possibly be moved up to probe level. The existing method of initialization still needs to be done as well which might mean we have the worst of both worlds. Open questions: - This still doesn't really address Arnd's concerns[3] about disabling IOMMUs - Currently tested where we knew the driver was going to be deferring. Probably need some logic for calling of_dma_configure again. This is based on Robin Murphy's work for dma mapping[4] and a few patches from Murali Kaicheri[5] for of_dma_configure. [1] http://lists.linuxfoundation.org/pipermail/iommu/2015-January/011764.html [2] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-August/279036.html [3] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-December/311579.html [4] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-January/315459.html [5] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-January/319390.html Laura Abbott (3): dma-mapping: Make arch_setup_dma_ops return an error code of: Return error codes from of_dma_configure iommu/arm-smmu: Support deferred probing Mitchel Humpherys (1): iommu/arm-smmu: add support for specifying clocks arch/arm/include/asm/dma-mapping.h | 2 +- arch/arm/mm/dma-mapping.c| 4 +- arch/arm64/include/asm/dma-mapping.h | 2 +- arch/arm64/mm/dma-mapping.c | 16 +-- drivers/iommu/arm-smmu.c | 186 +-- drivers/iommu/iommu.c| 49 - drivers/iommu/of_iommu.c | 14 ++- drivers/of/device.c | 9 +- include/linux/dma-mapping.h | 7 +- include/linux/iommu.h| 2 + include/linux/of_device.h| 4 +- 11 files changed, 268 insertions(+), 27 deletions(-) -- Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
