From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753028AbbBKQX2 (ORCPT ); Wed, 11 Feb 2015 11:23:28 -0500 Received: from pandora.arm.linux.org.uk ([78.32.30.218]:34535 "EHLO pandora.arm.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752200AbbBKQX0 (ORCPT ); Wed, 11 Feb 2015 11:23:26 -0500 Date: Wed, 11 Feb 2015 16:23:12 +0000 From: Russell King - ARM Linux To: Marek Szyprowski Cc: Sumit Semwal , linux-kernel@vger.kernel.org, linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org, linux-arm-kernel@lists.infradead.org, linux-mm@kvack.org, robin.murphy@arm.com, robdclark@gmail.com, linaro-kernel@lists.linaro.org, stanislawski.tomasz@googlemail.com, daniel@ffwll.ch Subject: Re: [RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms Message-ID: <20150211162312.GR8656@n2100.arm.linux.org.uk> References: <1422347154-15258-1-git-send-email-sumit.semwal@linaro.org> <1422347154-15258-2-git-send-email-sumit.semwal@linaro.org> <54DB12B5.4080000@samsung.com> <20150211111258.GP8656@n2100.arm.linux.org.uk> <54DB4908.10004@samsung.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54DB4908.10004@samsung.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Feb 11, 2015 at 01:20:24PM +0100, Marek Szyprowski wrote: > Hello, > > On 2015-02-11 12:12, Russell King - ARM Linux wrote: > >Which is a damn good reason to NAK it - by that admission, it's a half-baked > >idea. > > > >If all we want to know is whether the importer can accept only contiguous > >memory or not, make a flag to do that, and allow the exporter to test this > >flag. Don't over-engineer this to make it _seem_ like it can do something > >that it actually totally fails with. > > > >As I've already pointed out, there's a major problem if you have already > >had a less restrictive attachment which has an active mapping, and a new > >more restrictive attachment comes along later. > > > >It seems from Rob's descriptions that we also need another flag in the > >importer to indicate whether it wants to have a valid struct page in the > >scatter list, or whether it (correctly) uses the DMA accessors on the > >scatter list - so that exporters can reject importers which are buggy. > > Okay, but flag-based approach also have limitations. Yes, the flag-based approach doesn't let you describe in detail what the importer can accept - which, given the issues that I've raised is a *good* thing. We won't be misleading anyone into thinking that we can do something that's really half-baked, and which we have no present requirement for. This is precisely what Linus talks about when he says "don't over- engineer" - if we over-engineer this, we end up with something that sort-of works, and that's a bad thing. The Keep It Simple approach here makes total sense - what are our current requirements - to be able to say that an importer can only accept: - contiguous memory rather than a scatterlist - scatterlists with struct page pointers Does solving that need us to compare all the constraints of each and every importer, possibly ending up with constraints which can't be satisfied? No. Does the flag approach satisfy the requirements? Yes. > Frankly, if we want to make it really portable and sharable between devices, > then IMO we should get rid of struct scatterlist and replace it with simple > array of pfns in dma_buf. This way at least the problem of missing struct > page will be solved and the buffer representation will be also a bit more > compact. ... and move the mapping and unmapping of the PFNs to the importer, which IMHO is where it should already be (so the importer can decide when it should map the buffer itself independently of getting the details of the buffer.) > Such solution however also requires extending dma-mapping API to handle > mapping and unmapping of such pfn arrays. The advantage of this approach > is the fact that it will be completely new API, so it can be designed > well from the beginning. As far as I'm aware, there was no big discussion of the dma_buf API - it's something that just appeared one day (I don't remember seeing it discussed.) So, that may well be a good thing if it means we can get these kinds of details better hammered out. However, I don't share your view of "completely new API" - that would be far too disruptive. I think we can modify the existing API, to achieve our goals. I don't think changing the dma-mapping API just for this case is really on though - if we're passed a list of PFNs, they either must be all associated with a struct page - iow, pfn_valid(pfn) returns true for all of them or none of them. If none of them, then we need to be able to convert those PFNs to a dma_addr_t for the target device (yes, that may need the dma-mapping API augmenting.) However, if they are associated with a struct page, then we should use the established APIs and use a scatterlist, otherwise we're looking at rewriting all IOMMUs and all DMA mapping implementations to handle what would become a special case for dma_buf. I'd rather... Keep It Simple. So, maybe, as a first step, let's augment dma_buf with a pair of functions which get the "raw" unmapped scatterlist: struct sg_table *dma_buf_get_scatterlist(struct dma_buf_attachment *attach) { struct sg_table *sg_table; might_sleep(); if (!attach->dmabuf->ops->get_scatterlist) return ERR_PTR(-EINVAL); sg_table = attach->dmabuf->ops->get_scatterlist(attach); if (!sg_table) sg_table = ERR_PTR(-ENOMEM); return sg_table; } void dma_buf_put_scatterlist(struct dma_buf_attachment *attach, struct sg_table *sg_table) { might_sleep(); attach->dmabuf->ops->put_scatterlist(attach, sg_table); } Implementations should arrange for dma_buf_get_scatterlist() to return the EINVAL error pointer if they are unable to provide an unmapped scatterlist (in other words, they are exporting a set of PFNs or already-mapped dma_addr_t's.) This can be done by either not implementing the get_scatterlist method, or by implementing it and returning that forementioned error pointer value. Where these two are implemented and used, the importer is responsible for calling dma_map_sg() and dma_unmap_sg() on the returned scatterlist table. unsigned long *dma_buf_get_pfns(struct dma_buf_attachment *attach) { unsigned long *pfns; might_sleep(); if (!attach->dmabuf->ops->get_pfns) return ERR_PTR(-EINVAL); return attach->dmabuf->ops->get_pfns(attach); } void dma_buf_put_pfns(struct dma_buf_attachment *attach, unsigned long *pfns) { might_sleep(); attach->dmabuf->ops->put_pfns(attach, pfns); } Similar to the above, but this gets a list of PFNs. Each PFN entry prior to the last describes a page starting at offset 0 extending to the end of the page. The last PFN entry describes a page starting at offset 0 and extending to the offset of the attachment size within the page. Again, if not implemented or it is not possible to represent the buffer as PFNs, it returns -EINVAL. For the time being, we keep the existing dma_buf_map_attachment() and dma_buf_unmap_attachment() while we transition users over to the new interfaces. We may wish to augment struct dma_buf_attachment with a couple of flags to indicate which of these the attached dma_buf supports, so that drivers can deal with these themselves. We may also wish in the longer term to keep dma_buf_map_attachment() but implement it as a wrapper around get_scatterlist() as a helper to provide its existing functionality - providing a mapped scatterlist. Possibly also including get_pfns() in that as well if we need to. However, I would still like more thought put into Rob's issue to see whether we can solve his problem with using the dma_addr_t in a more elegant way. (I wish I had some hardware to experiment with for that.) -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lb0-f179.google.com (mail-lb0-f179.google.com [209.85.217.179]) by kanga.kvack.org (Postfix) with ESMTP id 747F06B0038 for ; Wed, 11 Feb 2015 11:23:34 -0500 (EST) Received: by mail-lb0-f179.google.com with SMTP id w7so4164157lbi.10 for ; Wed, 11 Feb 2015 08:23:33 -0800 (PST) Received: from pandora.arm.linux.org.uk (pandora.arm.linux.org.uk. [2001:4d48:ad52:3201:214:fdff:fe10:1be6]) by mx.google.com with ESMTPS id q6si4256066wiz.104.2015.02.11.08.23.31 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 11 Feb 2015 08:23:32 -0800 (PST) Date: Wed, 11 Feb 2015 16:23:12 +0000 From: Russell King - ARM Linux Subject: Re: [RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms Message-ID: <20150211162312.GR8656@n2100.arm.linux.org.uk> References: <1422347154-15258-1-git-send-email-sumit.semwal@linaro.org> <1422347154-15258-2-git-send-email-sumit.semwal@linaro.org> <54DB12B5.4080000@samsung.com> <20150211111258.GP8656@n2100.arm.linux.org.uk> <54DB4908.10004@samsung.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54DB4908.10004@samsung.com> Sender: owner-linux-mm@kvack.org List-ID: To: Marek Szyprowski Cc: Sumit Semwal , linux-kernel@vger.kernel.org, linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org, linux-arm-kernel@lists.infradead.org, linux-mm@kvack.org, robin.murphy@arm.com, robdclark@gmail.com, linaro-kernel@lists.linaro.org, stanislawski.tomasz@googlemail.com, daniel@ffwll.ch On Wed, Feb 11, 2015 at 01:20:24PM +0100, Marek Szyprowski wrote: > Hello, > > On 2015-02-11 12:12, Russell King - ARM Linux wrote: > >Which is a damn good reason to NAK it - by that admission, it's a half-baked > >idea. > > > >If all we want to know is whether the importer can accept only contiguous > >memory or not, make a flag to do that, and allow the exporter to test this > >flag. Don't over-engineer this to make it _seem_ like it can do something > >that it actually totally fails with. > > > >As I've already pointed out, there's a major problem if you have already > >had a less restrictive attachment which has an active mapping, and a new > >more restrictive attachment comes along later. > > > >It seems from Rob's descriptions that we also need another flag in the > >importer to indicate whether it wants to have a valid struct page in the > >scatter list, or whether it (correctly) uses the DMA accessors on the > >scatter list - so that exporters can reject importers which are buggy. > > Okay, but flag-based approach also have limitations. Yes, the flag-based approach doesn't let you describe in detail what the importer can accept - which, given the issues that I've raised is a *good* thing. We won't be misleading anyone into thinking that we can do something that's really half-baked, and which we have no present requirement for. This is precisely what Linus talks about when he says "don't over- engineer" - if we over-engineer this, we end up with something that sort-of works, and that's a bad thing. The Keep It Simple approach here makes total sense - what are our current requirements - to be able to say that an importer can only accept: - contiguous memory rather than a scatterlist - scatterlists with struct page pointers Does solving that need us to compare all the constraints of each and every importer, possibly ending up with constraints which can't be satisfied? No. Does the flag approach satisfy the requirements? Yes. > Frankly, if we want to make it really portable and sharable between devices, > then IMO we should get rid of struct scatterlist and replace it with simple > array of pfns in dma_buf. This way at least the problem of missing struct > page will be solved and the buffer representation will be also a bit more > compact. ... and move the mapping and unmapping of the PFNs to the importer, which IMHO is where it should already be (so the importer can decide when it should map the buffer itself independently of getting the details of the buffer.) > Such solution however also requires extending dma-mapping API to handle > mapping and unmapping of such pfn arrays. The advantage of this approach > is the fact that it will be completely new API, so it can be designed > well from the beginning. As far as I'm aware, there was no big discussion of the dma_buf API - it's something that just appeared one day (I don't remember seeing it discussed.) So, that may well be a good thing if it means we can get these kinds of details better hammered out. However, I don't share your view of "completely new API" - that would be far too disruptive. I think we can modify the existing API, to achieve our goals. I don't think changing the dma-mapping API just for this case is really on though - if we're passed a list of PFNs, they either must be all associated with a struct page - iow, pfn_valid(pfn) returns true for all of them or none of them. If none of them, then we need to be able to convert those PFNs to a dma_addr_t for the target device (yes, that may need the dma-mapping API augmenting.) However, if they are associated with a struct page, then we should use the established APIs and use a scatterlist, otherwise we're looking at rewriting all IOMMUs and all DMA mapping implementations to handle what would become a special case for dma_buf. I'd rather... Keep It Simple. So, maybe, as a first step, let's augment dma_buf with a pair of functions which get the "raw" unmapped scatterlist: struct sg_table *dma_buf_get_scatterlist(struct dma_buf_attachment *attach) { struct sg_table *sg_table; might_sleep(); if (!attach->dmabuf->ops->get_scatterlist) return ERR_PTR(-EINVAL); sg_table = attach->dmabuf->ops->get_scatterlist(attach); if (!sg_table) sg_table = ERR_PTR(-ENOMEM); return sg_table; } void dma_buf_put_scatterlist(struct dma_buf_attachment *attach, struct sg_table *sg_table) { might_sleep(); attach->dmabuf->ops->put_scatterlist(attach, sg_table); } Implementations should arrange for dma_buf_get_scatterlist() to return the EINVAL error pointer if they are unable to provide an unmapped scatterlist (in other words, they are exporting a set of PFNs or already-mapped dma_addr_t's.) This can be done by either not implementing the get_scatterlist method, or by implementing it and returning that forementioned error pointer value. Where these two are implemented and used, the importer is responsible for calling dma_map_sg() and dma_unmap_sg() on the returned scatterlist table. unsigned long *dma_buf_get_pfns(struct dma_buf_attachment *attach) { unsigned long *pfns; might_sleep(); if (!attach->dmabuf->ops->get_pfns) return ERR_PTR(-EINVAL); return attach->dmabuf->ops->get_pfns(attach); } void dma_buf_put_pfns(struct dma_buf_attachment *attach, unsigned long *pfns) { might_sleep(); attach->dmabuf->ops->put_pfns(attach, pfns); } Similar to the above, but this gets a list of PFNs. Each PFN entry prior to the last describes a page starting at offset 0 extending to the end of the page. The last PFN entry describes a page starting at offset 0 and extending to the offset of the attachment size within the page. Again, if not implemented or it is not possible to represent the buffer as PFNs, it returns -EINVAL. For the time being, we keep the existing dma_buf_map_attachment() and dma_buf_unmap_attachment() while we transition users over to the new interfaces. We may wish to augment struct dma_buf_attachment with a couple of flags to indicate which of these the attached dma_buf supports, so that drivers can deal with these themselves. We may also wish in the longer term to keep dma_buf_map_attachment() but implement it as a wrapper around get_scatterlist() as a helper to provide its existing functionality - providing a mapped scatterlist. Possibly also including get_pfns() in that as well if we need to. However, I would still like more thought put into Rob's issue to see whether we can solve his problem with using the dma_addr_t in a more elegant way. (I wish I had some hardware to experiment with for that.) -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 From: linux@arm.linux.org.uk (Russell King - ARM Linux) Date: Wed, 11 Feb 2015 16:23:12 +0000 Subject: [RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms In-Reply-To: <54DB4908.10004@samsung.com> References: <1422347154-15258-1-git-send-email-sumit.semwal@linaro.org> <1422347154-15258-2-git-send-email-sumit.semwal@linaro.org> <54DB12B5.4080000@samsung.com> <20150211111258.GP8656@n2100.arm.linux.org.uk> <54DB4908.10004@samsung.com> Message-ID: <20150211162312.GR8656@n2100.arm.linux.org.uk> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Wed, Feb 11, 2015 at 01:20:24PM +0100, Marek Szyprowski wrote: > Hello, > > On 2015-02-11 12:12, Russell King - ARM Linux wrote: > >Which is a damn good reason to NAK it - by that admission, it's a half-baked > >idea. > > > >If all we want to know is whether the importer can accept only contiguous > >memory or not, make a flag to do that, and allow the exporter to test this > >flag. Don't over-engineer this to make it _seem_ like it can do something > >that it actually totally fails with. > > > >As I've already pointed out, there's a major problem if you have already > >had a less restrictive attachment which has an active mapping, and a new > >more restrictive attachment comes along later. > > > >It seems from Rob's descriptions that we also need another flag in the > >importer to indicate whether it wants to have a valid struct page in the > >scatter list, or whether it (correctly) uses the DMA accessors on the > >scatter list - so that exporters can reject importers which are buggy. > > Okay, but flag-based approach also have limitations. Yes, the flag-based approach doesn't let you describe in detail what the importer can accept - which, given the issues that I've raised is a *good* thing. We won't be misleading anyone into thinking that we can do something that's really half-baked, and which we have no present requirement for. This is precisely what Linus talks about when he says "don't over- engineer" - if we over-engineer this, we end up with something that sort-of works, and that's a bad thing. The Keep It Simple approach here makes total sense - what are our current requirements - to be able to say that an importer can only accept: - contiguous memory rather than a scatterlist - scatterlists with struct page pointers Does solving that need us to compare all the constraints of each and every importer, possibly ending up with constraints which can't be satisfied? No. Does the flag approach satisfy the requirements? Yes. > Frankly, if we want to make it really portable and sharable between devices, > then IMO we should get rid of struct scatterlist and replace it with simple > array of pfns in dma_buf. This way at least the problem of missing struct > page will be solved and the buffer representation will be also a bit more > compact. ... and move the mapping and unmapping of the PFNs to the importer, which IMHO is where it should already be (so the importer can decide when it should map the buffer itself independently of getting the details of the buffer.) > Such solution however also requires extending dma-mapping API to handle > mapping and unmapping of such pfn arrays. The advantage of this approach > is the fact that it will be completely new API, so it can be designed > well from the beginning. As far as I'm aware, there was no big discussion of the dma_buf API - it's something that just appeared one day (I don't remember seeing it discussed.) So, that may well be a good thing if it means we can get these kinds of details better hammered out. However, I don't share your view of "completely new API" - that would be far too disruptive. I think we can modify the existing API, to achieve our goals. I don't think changing the dma-mapping API just for this case is really on though - if we're passed a list of PFNs, they either must be all associated with a struct page - iow, pfn_valid(pfn) returns true for all of them or none of them. If none of them, then we need to be able to convert those PFNs to a dma_addr_t for the target device (yes, that may need the dma-mapping API augmenting.) However, if they are associated with a struct page, then we should use the established APIs and use a scatterlist, otherwise we're looking at rewriting all IOMMUs and all DMA mapping implementations to handle what would become a special case for dma_buf. I'd rather... Keep It Simple. So, maybe, as a first step, let's augment dma_buf with a pair of functions which get the "raw" unmapped scatterlist: struct sg_table *dma_buf_get_scatterlist(struct dma_buf_attachment *attach) { struct sg_table *sg_table; might_sleep(); if (!attach->dmabuf->ops->get_scatterlist) return ERR_PTR(-EINVAL); sg_table = attach->dmabuf->ops->get_scatterlist(attach); if (!sg_table) sg_table = ERR_PTR(-ENOMEM); return sg_table; } void dma_buf_put_scatterlist(struct dma_buf_attachment *attach, struct sg_table *sg_table) { might_sleep(); attach->dmabuf->ops->put_scatterlist(attach, sg_table); } Implementations should arrange for dma_buf_get_scatterlist() to return the EINVAL error pointer if they are unable to provide an unmapped scatterlist (in other words, they are exporting a set of PFNs or already-mapped dma_addr_t's.) This can be done by either not implementing the get_scatterlist method, or by implementing it and returning that forementioned error pointer value. Where these two are implemented and used, the importer is responsible for calling dma_map_sg() and dma_unmap_sg() on the returned scatterlist table. unsigned long *dma_buf_get_pfns(struct dma_buf_attachment *attach) { unsigned long *pfns; might_sleep(); if (!attach->dmabuf->ops->get_pfns) return ERR_PTR(-EINVAL); return attach->dmabuf->ops->get_pfns(attach); } void dma_buf_put_pfns(struct dma_buf_attachment *attach, unsigned long *pfns) { might_sleep(); attach->dmabuf->ops->put_pfns(attach, pfns); } Similar to the above, but this gets a list of PFNs. Each PFN entry prior to the last describes a page starting at offset 0 extending to the end of the page. The last PFN entry describes a page starting at offset 0 and extending to the offset of the attachment size within the page. Again, if not implemented or it is not possible to represent the buffer as PFNs, it returns -EINVAL. For the time being, we keep the existing dma_buf_map_attachment() and dma_buf_unmap_attachment() while we transition users over to the new interfaces. We may wish to augment struct dma_buf_attachment with a couple of flags to indicate which of these the attached dma_buf supports, so that drivers can deal with these themselves. We may also wish in the longer term to keep dma_buf_map_attachment() but implement it as a wrapper around get_scatterlist() as a helper to provide its existing functionality - providing a mapped scatterlist. Possibly also including get_pfns() in that as well if we need to. However, I would still like more thought put into Rob's issue to see whether we can solve his problem with using the dma_addr_t in a more elegant way. (I wish I had some hardware to experiment with for that.) -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Russell King - ARM Linux Subject: Re: [RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms Date: Wed, 11 Feb 2015 16:23:12 +0000 Message-ID: <20150211162312.GR8656@n2100.arm.linux.org.uk> References: <1422347154-15258-1-git-send-email-sumit.semwal@linaro.org> <1422347154-15258-2-git-send-email-sumit.semwal@linaro.org> <54DB12B5.4080000@samsung.com> <20150211111258.GP8656@n2100.arm.linux.org.uk> <54DB4908.10004@samsung.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Received: from pandora.arm.linux.org.uk (pandora.arm.linux.org.uk [78.32.30.218]) by gabe.freedesktop.org (Postfix) with ESMTP id 8181B6E32A for ; Wed, 11 Feb 2015 08:23:28 -0800 (PST) Content-Disposition: inline In-Reply-To: <54DB4908.10004@samsung.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Marek Szyprowski Cc: linaro-kernel@lists.linaro.org, stanislawski.tomasz@googlemail.com, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org, linux-mm@kvack.org, robin.murphy@arm.com, linux-arm-kernel@lists.infradead.org, linux-media@vger.kernel.org List-Id: dri-devel@lists.freedesktop.org T24gV2VkLCBGZWIgMTEsIDIwMTUgYXQgMDE6MjA6MjRQTSArMDEwMCwgTWFyZWsgU3p5cHJvd3Nr aSB3cm90ZToKPiBIZWxsbywKPiAKPiBPbiAyMDE1LTAyLTExIDEyOjEyLCBSdXNzZWxsIEtpbmcg LSBBUk0gTGludXggd3JvdGU6Cj4gPldoaWNoIGlzIGEgZGFtbiBnb29kIHJlYXNvbiB0byBOQUsg aXQgLSBieSB0aGF0IGFkbWlzc2lvbiwgaXQncyBhIGhhbGYtYmFrZWQKPiA+aWRlYS4KPiA+Cj4g PklmIGFsbCB3ZSB3YW50IHRvIGtub3cgaXMgd2hldGhlciB0aGUgaW1wb3J0ZXIgY2FuIGFjY2Vw dCBvbmx5IGNvbnRpZ3VvdXMKPiA+bWVtb3J5IG9yIG5vdCwgbWFrZSBhIGZsYWcgdG8gZG8gdGhh dCwgYW5kIGFsbG93IHRoZSBleHBvcnRlciB0byB0ZXN0IHRoaXMKPiA+ZmxhZy4gIERvbid0IG92 ZXItZW5naW5lZXIgdGhpcyB0byBtYWtlIGl0IF9zZWVtXyBsaWtlIGl0IGNhbiBkbyBzb21ldGhp bmcKPiA+dGhhdCBpdCBhY3R1YWxseSB0b3RhbGx5IGZhaWxzIHdpdGguCj4gPgo+ID5BcyBJJ3Zl IGFscmVhZHkgcG9pbnRlZCBvdXQsIHRoZXJlJ3MgYSBtYWpvciBwcm9ibGVtIGlmIHlvdSBoYXZl IGFscmVhZHkKPiA+aGFkIGEgbGVzcyByZXN0cmljdGl2ZSBhdHRhY2htZW50IHdoaWNoIGhhcyBh biBhY3RpdmUgbWFwcGluZywgYW5kIGEgbmV3Cj4gPm1vcmUgcmVzdHJpY3RpdmUgYXR0YWNobWVu dCBjb21lcyBhbG9uZyBsYXRlci4KPiA+Cj4gPkl0IHNlZW1zIGZyb20gUm9iJ3MgZGVzY3JpcHRp b25zIHRoYXQgd2UgYWxzbyBuZWVkIGFub3RoZXIgZmxhZyBpbiB0aGUKPiA+aW1wb3J0ZXIgdG8g aW5kaWNhdGUgd2hldGhlciBpdCB3YW50cyB0byBoYXZlIGEgdmFsaWQgc3RydWN0IHBhZ2UgaW4g dGhlCj4gPnNjYXR0ZXIgbGlzdCwgb3Igd2hldGhlciBpdCAoY29ycmVjdGx5KSB1c2VzIHRoZSBE TUEgYWNjZXNzb3JzIG9uIHRoZQo+ID5zY2F0dGVyIGxpc3QgLSBzbyB0aGF0IGV4cG9ydGVycyBj YW4gcmVqZWN0IGltcG9ydGVycyB3aGljaCBhcmUgYnVnZ3kuCj4gCj4gT2theSwgYnV0IGZsYWct YmFzZWQgYXBwcm9hY2ggYWxzbyBoYXZlIGxpbWl0YXRpb25zLgoKWWVzLCB0aGUgZmxhZy1iYXNl ZCBhcHByb2FjaCBkb2Vzbid0IGxldCB5b3UgZGVzY3JpYmUgaW4gZGV0YWlsIHdoYXQKdGhlIGlt cG9ydGVyIGNhbiBhY2NlcHQgLSB3aGljaCwgZ2l2ZW4gdGhlIGlzc3VlcyB0aGF0IEkndmUgcmFp c2VkCmlzIGEgKmdvb2QqIHRoaW5nLiAgV2Ugd29uJ3QgYmUgbWlzbGVhZGluZyBhbnlvbmUgaW50 byB0aGlua2luZyB0aGF0CndlIGNhbiBkbyBzb21ldGhpbmcgdGhhdCdzIHJlYWxseSBoYWxmLWJh a2VkLCBhbmQgd2hpY2ggd2UgaGF2ZSBubwpwcmVzZW50IHJlcXVpcmVtZW50IGZvci4KClRoaXMg aXMgcHJlY2lzZWx5IHdoYXQgTGludXMgdGFsa3MgYWJvdXQgd2hlbiBoZSBzYXlzICJkb24ndCBv dmVyLQplbmdpbmVlciIgLSBpZiB3ZSBvdmVyLWVuZ2luZWVyIHRoaXMsIHdlIGVuZCB1cCB3aXRo IHNvbWV0aGluZyB0aGF0CnNvcnQtb2Ygd29ya3MsIGFuZCB0aGF0J3MgYSBiYWQgdGhpbmcuCgpU aGUgS2VlcCBJdCBTaW1wbGUgYXBwcm9hY2ggaGVyZSBtYWtlcyB0b3RhbCBzZW5zZSAtIHdoYXQg YXJlIG91cgpjdXJyZW50IHJlcXVpcmVtZW50cyAtIHRvIGJlIGFibGUgdG8gc2F5IHRoYXQgYW4g aW1wb3J0ZXIgY2FuIG9ubHkgYWNjZXB0OgogIC0gY29udGlndW91cyBtZW1vcnkgcmF0aGVyIHRo YW4gYSBzY2F0dGVybGlzdAogIC0gc2NhdHRlcmxpc3RzIHdpdGggc3RydWN0IHBhZ2UgcG9pbnRl cnMKCkRvZXMgc29sdmluZyB0aGF0IG5lZWQgdXMgdG8gY29tcGFyZSBhbGwgdGhlIGNvbnN0cmFp bnRzIG9mIGVhY2ggYW5kCmV2ZXJ5IGltcG9ydGVyLCBwb3NzaWJseSBlbmRpbmcgdXAgd2l0aCBj b25zdHJhaW50cyB3aGljaCBjYW4ndCBiZQpzYXRpc2ZpZWQ/ICBOby4gIERvZXMgdGhlIGZsYWcg YXBwcm9hY2ggc2F0aXNmeSB0aGUgcmVxdWlyZW1lbnRzPyAgWWVzLgoKPiBGcmFua2x5LCBpZiB3 ZSB3YW50IHRvIG1ha2UgaXQgcmVhbGx5IHBvcnRhYmxlIGFuZCBzaGFyYWJsZSBiZXR3ZWVuIGRl dmljZXMsCj4gdGhlbiBJTU8gd2Ugc2hvdWxkIGdldCByaWQgb2Ygc3RydWN0IHNjYXR0ZXJsaXN0 IGFuZCByZXBsYWNlIGl0IHdpdGggc2ltcGxlCj4gYXJyYXkgb2YgcGZucyBpbiBkbWFfYnVmLiBU aGlzIHdheSBhdCBsZWFzdCB0aGUgcHJvYmxlbSBvZiBtaXNzaW5nIHN0cnVjdAo+IHBhZ2Ugd2ls bCBiZSBzb2x2ZWQgYW5kIHRoZSBidWZmZXIgcmVwcmVzZW50YXRpb24gd2lsbCBiZSBhbHNvIGEg Yml0IG1vcmUKPiBjb21wYWN0LgoKLi4uIGFuZCBtb3ZlIHRoZSBtYXBwaW5nIGFuZCB1bm1hcHBp bmcgb2YgdGhlIFBGTnMgdG8gdGhlIGltcG9ydGVyLAp3aGljaCBJTUhPIGlzIHdoZXJlIGl0IHNo b3VsZCBhbHJlYWR5IGJlIChzbyB0aGUgaW1wb3J0ZXIgY2FuIGRlY2lkZQp3aGVuIGl0IHNob3Vs ZCBtYXAgdGhlIGJ1ZmZlciBpdHNlbGYgaW5kZXBlbmRlbnRseSBvZiBnZXR0aW5nIHRoZQpkZXRh aWxzIG9mIHRoZSBidWZmZXIuKQoKPiBTdWNoIHNvbHV0aW9uIGhvd2V2ZXIgYWxzbyByZXF1aXJl cyBleHRlbmRpbmcgZG1hLW1hcHBpbmcgQVBJIHRvIGhhbmRsZQo+IG1hcHBpbmcgYW5kIHVubWFw cGluZyBvZiBzdWNoIHBmbiBhcnJheXMuIFRoZSBhZHZhbnRhZ2Ugb2YgdGhpcyBhcHByb2FjaAo+ IGlzIHRoZSBmYWN0IHRoYXQgaXQgd2lsbCBiZSBjb21wbGV0ZWx5IG5ldyBBUEksIHNvIGl0IGNh biBiZSBkZXNpZ25lZAo+IHdlbGwgZnJvbSB0aGUgYmVnaW5uaW5nLgoKQXMgZmFyIGFzIEknbSBh d2FyZSwgdGhlcmUgd2FzIG5vIGJpZyBkaXNjdXNzaW9uIG9mIHRoZSBkbWFfYnVmIEFQSSAtCml0 J3Mgc29tZXRoaW5nIHRoYXQganVzdCBhcHBlYXJlZCBvbmUgZGF5IChJIGRvbid0IHJlbWVtYmVy IHNlZWluZyBpdApkaXNjdXNzZWQuKSAgU28sIHRoYXQgbWF5IHdlbGwgYmUgYSBnb29kIHRoaW5n IGlmIGl0IG1lYW5zIHdlIGNhbiBnZXQKdGhlc2Uga2luZHMgb2YgZGV0YWlscyBiZXR0ZXIgaGFt bWVyZWQgb3V0LgoKSG93ZXZlciwgSSBkb24ndCBzaGFyZSB5b3VyIHZpZXcgb2YgImNvbXBsZXRl bHkgbmV3IEFQSSIgLSB0aGF0IHdvdWxkCmJlIGZhciB0b28gZGlzcnVwdGl2ZS4gIEkgdGhpbmsg d2UgY2FuIG1vZGlmeSB0aGUgZXhpc3RpbmcgQVBJLCB0bwphY2hpZXZlIG91ciBnb2Fscy4KCkkg ZG9uJ3QgdGhpbmsgY2hhbmdpbmcgdGhlIGRtYS1tYXBwaW5nIEFQSSBqdXN0IGZvciB0aGlzIGNh c2UgaXMgcmVhbGx5Cm9uIHRob3VnaCAtIGlmIHdlJ3JlIHBhc3NlZCBhIGxpc3Qgb2YgUEZOcywg dGhleSBlaXRoZXIgbXVzdCBiZSBhbGwKYXNzb2NpYXRlZCB3aXRoIGEgc3RydWN0IHBhZ2UgLSBp b3csIHBmbl92YWxpZChwZm4pIHJldHVybnMgdHJ1ZSBmb3IKYWxsIG9mIHRoZW0gb3Igbm9uZSBv ZiB0aGVtLiAgSWYgbm9uZSBvZiB0aGVtLCB0aGVuIHdlIG5lZWQgdG8gYmUgYWJsZQp0byBjb252 ZXJ0IHRob3NlIFBGTnMgdG8gYSBkbWFfYWRkcl90IGZvciB0aGUgdGFyZ2V0IGRldmljZSAoeWVz LCB0aGF0Cm1heSBuZWVkIHRoZSBkbWEtbWFwcGluZyBBUEkgYXVnbWVudGluZy4pCgpIb3dldmVy LCBpZiB0aGV5IGFyZSBhc3NvY2lhdGVkIHdpdGggYSBzdHJ1Y3QgcGFnZSwgdGhlbiB3ZSBzaG91 bGQgdXNlCnRoZSBlc3RhYmxpc2hlZCBBUElzIGFuZCB1c2UgYSBzY2F0dGVybGlzdCwgb3RoZXJ3 aXNlIHdlJ3JlIGxvb2tpbmcKYXQgcmV3cml0aW5nIGFsbCBJT01NVXMgYW5kIGFsbCBETUEgbWFw cGluZyBpbXBsZW1lbnRhdGlvbnMgdG8gaGFuZGxlCndoYXQgd291bGQgYmVjb21lIGEgc3BlY2lh bCBjYXNlIGZvciBkbWFfYnVmLgoKSSdkIHJhdGhlci4uLiBLZWVwIEl0IFNpbXBsZS4KClNvLCBt YXliZSwgYXMgYSBmaXJzdCBzdGVwLCBsZXQncyBhdWdtZW50IGRtYV9idWYgd2l0aCBhIHBhaXIg b2YKZnVuY3Rpb25zIHdoaWNoIGdldCB0aGUgInJhdyIgdW5tYXBwZWQgc2NhdHRlcmxpc3Q6Cgpz dHJ1Y3Qgc2dfdGFibGUgKmRtYV9idWZfZ2V0X3NjYXR0ZXJsaXN0KHN0cnVjdCBkbWFfYnVmX2F0 dGFjaG1lbnQgKmF0dGFjaCkKewoJc3RydWN0IHNnX3RhYmxlICpzZ190YWJsZTsKCgltaWdodF9z bGVlcCgpOwoKCWlmICghYXR0YWNoLT5kbWFidWYtPm9wcy0+Z2V0X3NjYXR0ZXJsaXN0KQoJCXJl dHVybiBFUlJfUFRSKC1FSU5WQUwpOwoKCXNnX3RhYmxlID0gYXR0YWNoLT5kbWFidWYtPm9wcy0+ Z2V0X3NjYXR0ZXJsaXN0KGF0dGFjaCk7CglpZiAoIXNnX3RhYmxlKQoJCXNnX3RhYmxlID0gRVJS X1BUUigtRU5PTUVNKTsKCglyZXR1cm4gc2dfdGFibGU7Cn0KCnZvaWQgZG1hX2J1Zl9wdXRfc2Nh dHRlcmxpc3Qoc3RydWN0IGRtYV9idWZfYXR0YWNobWVudCAqYXR0YWNoLAoJCQkgICAgIHN0cnVj dCBzZ190YWJsZSAqc2dfdGFibGUpCnsKCW1pZ2h0X3NsZWVwKCk7CgoJYXR0YWNoLT5kbWFidWYt Pm9wcy0+cHV0X3NjYXR0ZXJsaXN0KGF0dGFjaCwgc2dfdGFibGUpOwp9CgpJbXBsZW1lbnRhdGlv bnMgc2hvdWxkIGFycmFuZ2UgZm9yIGRtYV9idWZfZ2V0X3NjYXR0ZXJsaXN0KCkgdG8gcmV0dXJu CnRoZSBFSU5WQUwgZXJyb3IgcG9pbnRlciBpZiB0aGV5IGFyZSB1bmFibGUgdG8gcHJvdmlkZSBh biB1bm1hcHBlZApzY2F0dGVybGlzdCAoaW4gb3RoZXIgd29yZHMsIHRoZXkgYXJlIGV4cG9ydGlu ZyBhIHNldCBvZiBQRk5zIG9yCmFscmVhZHktbWFwcGVkIGRtYV9hZGRyX3Qncy4pICBUaGlzIGNh biBiZSBkb25lIGJ5IGVpdGhlciBub3QKaW1wbGVtZW50aW5nIHRoZSBnZXRfc2NhdHRlcmxpc3Qg bWV0aG9kLCBvciBieSBpbXBsZW1lbnRpbmcgaXQgYW5kCnJldHVybmluZyB0aGF0IGZvcmVtZW50 aW9uZWQgZXJyb3IgcG9pbnRlciB2YWx1ZS4KCldoZXJlIHRoZXNlIHR3byBhcmUgaW1wbGVtZW50 ZWQgYW5kIHVzZWQsIHRoZSBpbXBvcnRlciBpcyByZXNwb25zaWJsZQpmb3IgY2FsbGluZyBkbWFf bWFwX3NnKCkgYW5kIGRtYV91bm1hcF9zZygpIG9uIHRoZSByZXR1cm5lZCBzY2F0dGVybGlzdAp0 YWJsZS4KCnVuc2lnbmVkIGxvbmcgKmRtYV9idWZfZ2V0X3BmbnMoc3RydWN0IGRtYV9idWZfYXR0 YWNobWVudCAqYXR0YWNoKQp7Cgl1bnNpZ25lZCBsb25nICpwZm5zOwoKCW1pZ2h0X3NsZWVwKCk7 CgoJaWYgKCFhdHRhY2gtPmRtYWJ1Zi0+b3BzLT5nZXRfcGZucykKCQlyZXR1cm4gRVJSX1BUUigt RUlOVkFMKTsKCglyZXR1cm4gYXR0YWNoLT5kbWFidWYtPm9wcy0+Z2V0X3BmbnMoYXR0YWNoKTsK fQoKdm9pZCBkbWFfYnVmX3B1dF9wZm5zKHN0cnVjdCBkbWFfYnVmX2F0dGFjaG1lbnQgKmF0dGFj aCwgdW5zaWduZWQgbG9uZyAqcGZucykKewoJbWlnaHRfc2xlZXAoKTsKCglhdHRhY2gtPmRtYWJ1 Zi0+b3BzLT5wdXRfcGZucyhhdHRhY2gsIHBmbnMpOwp9CgpTaW1pbGFyIHRvIHRoZSBhYm92ZSwg YnV0IHRoaXMgZ2V0cyBhIGxpc3Qgb2YgUEZOcy4gIEVhY2ggUEZOIGVudHJ5IHByaW9yCnRvIHRo ZSBsYXN0IGRlc2NyaWJlcyBhIHBhZ2Ugc3RhcnRpbmcgYXQgb2Zmc2V0IDAgZXh0ZW5kaW5nIHRv IHRoZSBlbmQgb2YKdGhlIHBhZ2UuICBUaGUgbGFzdCBQRk4gZW50cnkgZGVzY3JpYmVzIGEgcGFn ZSBzdGFydGluZyBhdCBvZmZzZXQgMCBhbmQKZXh0ZW5kaW5nIHRvIHRoZSBvZmZzZXQgb2YgdGhl IGF0dGFjaG1lbnQgc2l6ZSB3aXRoaW4gdGhlIHBhZ2UuICBBZ2FpbiwKaWYgbm90IGltcGxlbWVu dGVkIG9yIGl0IGlzIG5vdCBwb3NzaWJsZSB0byByZXByZXNlbnQgdGhlIGJ1ZmZlciBhcyBQRk5z LAppdCByZXR1cm5zIC1FSU5WQUwuCgpGb3IgdGhlIHRpbWUgYmVpbmcsIHdlIGtlZXAgdGhlIGV4 aXN0aW5nIGRtYV9idWZfbWFwX2F0dGFjaG1lbnQoKSBhbmQKZG1hX2J1Zl91bm1hcF9hdHRhY2ht ZW50KCkgd2hpbGUgd2UgdHJhbnNpdGlvbiB1c2VycyBvdmVyIHRvIHRoZSBuZXcKaW50ZXJmYWNl cy4KCldlIG1heSB3aXNoIHRvIGF1Z21lbnQgc3RydWN0IGRtYV9idWZfYXR0YWNobWVudCB3aXRo IGEgY291cGxlIG9mIGZsYWdzCnRvIGluZGljYXRlIHdoaWNoIG9mIHRoZXNlIHRoZSBhdHRhY2hl ZCBkbWFfYnVmIHN1cHBvcnRzLCBzbyB0aGF0IGRyaXZlcnMKY2FuIGRlYWwgd2l0aCB0aGVzZSB0 aGVtc2VsdmVzLgoKV2UgbWF5IGFsc28gd2lzaCBpbiB0aGUgbG9uZ2VyIHRlcm0gdG8ga2VlcCBk bWFfYnVmX21hcF9hdHRhY2htZW50KCkgYnV0CmltcGxlbWVudCBpdCBhcyBhIHdyYXBwZXIgYXJv dW5kIGdldF9zY2F0dGVybGlzdCgpIGFzIGEgaGVscGVyIHRvIHByb3ZpZGUKaXRzIGV4aXN0aW5n IGZ1bmN0aW9uYWxpdHkgLSBwcm92aWRpbmcgYSBtYXBwZWQgc2NhdHRlcmxpc3QuICBQb3NzaWJs eQphbHNvIGluY2x1ZGluZyBnZXRfcGZucygpIGluIHRoYXQgYXMgd2VsbCBpZiB3ZSBuZWVkIHRv LgoKSG93ZXZlciwgSSB3b3VsZCBzdGlsbCBsaWtlIG1vcmUgdGhvdWdodCBwdXQgaW50byBSb2In cyBpc3N1ZSB0byBzZWUKd2hldGhlciB3ZSBjYW4gc29sdmUgaGlzIHByb2JsZW0gd2l0aCB1c2lu ZyB0aGUgZG1hX2FkZHJfdCBpbiBhIG1vcmUKZWxlZ2FudCB3YXkuICAoSSB3aXNoIEkgaGFkIHNv bWUgaGFyZHdhcmUgdG8gZXhwZXJpbWVudCB3aXRoIGZvciB0aGF0LikKCi0tIApGVFRDIGJyb2Fk YmFuZCBmb3IgMC44bWlsZSBsaW5lOiBjdXJyZW50bHkgYXQgMTAuNU1icHMgZG93biA0MDBrYnBz IHVwCmFjY29yZGluZyB0byBzcGVlZHRlc3QubmV0LgpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXwpkcmktZGV2ZWwgbWFpbGluZyBsaXN0CmRyaS1kZXZlbEBs aXN0cy5mcmVlZGVza3RvcC5vcmcKaHR0cDovL2xpc3RzLmZyZWVkZXNrdG9wLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2RyaS1kZXZlbAo=