Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Received-SPF: TempError (protection.outlook.com: error in processing during
 lookup of arm.com: DNS Timeout)
From:   Brian Starkey <Brian.Starkey@arm.com>
To:     John Stultz <john.stultz@linaro.org>
CC:     lkml <linux-kernel@vger.kernel.org>,
        "Andrew F. Davis" <afd@ti.com>, Laura Abbott <labbott@redhat.com>,
        Benjamin Gaignard <benjamin.gaignard@linaro.org>,
        Sumit Semwal <sumit.semwal@linaro.org>,
        Liam Mark <lmark@codeaurora.org>,
        Pratik Patel <pratikp@codeaurora.org>,
        Vincent Donnefort <Vincent.Donnefort@arm.com>,
        Sudipto Paul <Sudipto.Paul@arm.com>,
        Christoph Hellwig <hch@infradead.org>,
        Chenbo Feng <fengc@google.com>,
        Alistair Strachan <astrachan@google.com>,
        Hridya Valsaraju <hridya@google.com>,
        Hillf Danton <hdanton@sina.com>,
        "dri-devel@lists.freedesktop.org" <dri-devel@lists.freedesktop.org>,
        nd <nd@arm.com>
Subject: Re: [PATCH v12 1/5] dma-buf: Add dma-buf heaps framework
Thread-Topic: [PATCH v12 1/5] dma-buf: Add dma-buf heaps framework
Thread-Index: AQHVhXQuL0D7Z4fi0UChemDv0BA9l6dgQKQA
Date:   Fri, 18 Oct 2019 11:18:33 +0000
Message-ID: <20191018111832.o7wx3x54jm3ic6cq@DESKTOP-E1NTVVP.localdomain>
References: <20191018052323.21659-1-john.stultz@linaro.org>
 <20191018052323.21659-2-john.stultz@linaro.org>
In-Reply-To: <20191018052323.21659-2-john.stultz@linaro.org>
Accept-Language: en-GB, en-US
Content-Language: en-US
user-agent: NeoMutt/20180716-849-147d51-dirty
Authentication-Results-Original: spf=none (sender IP is )
 smtp.mailfrom=Brian.Starkey@arm.com; 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
X-MS-Office365-Filtering-Correlation-Id: 47d96852-38d9-41c5-22be-08d753bcf08f
X-MS-Office365-Filtering-HT: Tenant
X-MS-TrafficTypeDiagnostic: AM6PR08MB4231:|AM6PR08MB4231:|VI1PR08MB4624:
x-ms-exchange-transport-forked: True
X-Microsoft-Antispam-PRVS: <VI1PR08MB4624B06A3F6080D618D33352F06C0@VI1PR08MB4624.eurprd08.prod.outlook.com>
x-checkrecipientrouted: true
x-ms-oob-tlc-oobclassifiers: OLM:3631;OLM:3631;
x-forefront-prvs: 01949FE337
X-Forefront-Antispam-Report-Untrusted: SFV:NSPM;SFS:(10009020)(4636009)(136003)(366004)(39860400002)(396003)(376002)(346002)(189003)(199004)(71190400001)(476003)(6512007)(71200400001)(6246003)(81156014)(8676002)(102836004)(9686003)(86362001)(81166006)(1076003)(14454004)(11346002)(229853002)(446003)(186003)(99286004)(6116002)(3846002)(2906002)(4326008)(66556008)(64756008)(66446008)(8936002)(305945005)(66476007)(7736002)(66946007)(6916009)(316002)(26005)(6436002)(58126008)(25786009)(76176011)(256004)(7416002)(486006)(44832011)(52116002)(66066001)(478600001)(6506007)(6486002)(54906003)(5660300002)(386003);DIR:OUT;SFP:1101;SCL:1;SRVR:AM6PR08MB4231;H:AM6PR08MB3829.eurprd08.prod.outlook.com;FPR:;SPF:None;LANG:en;PTR:InfoNoRecords;MX:1;A:1;
received-spf: None (protection.outlook.com: arm.com does not designate
 permitted sender hosts)
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam-Untrusted: BCL:0;
X-Microsoft-Antispam-Message-Info-Original: YsmxL4WUAfrS3xWv26Vd2pz0ahldXNeUNYAck9Z5XXsuaPyWmFcIn6jp/35WB7LF1gq3nSf+HCTmjpFkIhV7fCE6ckdxWYyW/yFxjgICw4UI52CveT22xcG1Tch3eeRXuw6OzkI3YJbZGNI2IezJA+2r6ZShlHJ71uvR3MBpMYmZvvdFU0hkyL+DqT5SbtohxkoV+dMYC0J/HBsbRF+WHCtLiijl8WEk9FAf1f1TqFWI+tf7xiOIOFKyGo5hCrw7Ra5c/jFIP/eNI8l8zmy4DjsRsEZcxh/GuzaNvIlTVbZO3X5x7zpTDTpBP9SE8T4SGVaZEWqUjRdXohKAWXDcRdA1TERPUmTG1qKTXjh9N8IZ8ffi8g8rR+Gd8Q2gF+o5RpJZSYMEtJIzgMgxgKLAdZoskIatKMWedk1gUvnaxpw=
Content-Type: text/plain; charset="us-ascii"
Content-ID: <E50E73799F579541AA924FB0B9D97D68@eurprd08.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB4231
Original-Authentication-Results: spf=none (sender IP is )
 smtp.mailfrom=Brian.Starkey@arm.com; 
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT051.eop-EUR03.prod.protection.outlook.com
X-Forefront-Antispam-Report: CIP:63.35.35.123;IPV:CAL;SCL:-1;CTRY:IE;EFV:NLI;SFV:NSPM;SFS:(10009020)(4636009)(39860400002)(346002)(376002)(136003)(396003)(189003)(199004)(2906002)(4326008)(26826003)(47776003)(66066001)(478600001)(8676002)(86362001)(14454004)(356004)(58126008)(54906003)(50466002)(1076003)(46406003)(316002)(5660300002)(76176011)(11346002)(229853002)(446003)(486006)(126002)(63350400001)(476003)(97756001)(22756006)(70206006)(76130400001)(386003)(6506007)(70586007)(8936002)(7736002)(8746002)(305945005)(81166006)(81156014)(6862004)(6246003)(6512007)(9686003)(336012)(25786009)(186003)(26005)(102836004)(23726003)(3846002)(6116002)(99286004)(6486002);DIR:OUT;SFP:1101;SCL:1;SRVR:VI1PR08MB4624;H:64aa7808-outbound-1.mta.getcheckrecipient.com;FPR:;SPF:TempError;LANG:en;PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com;MX:1;A:1;
X-MS-Office365-Filtering-Correlation-Id-Prvs: 94550478-fdf6-441e-d4cc-08d753bce9d1
NoDisclaimer: True
X-Forefront-PRVS: 01949FE337
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: P4kp4XP6HuMJ5FGisbhS/zzIWnuto6KlOSHAdgVzuuDS2MBXRw3y6Phh0VYAcIOc7ifDgRcb9Ci1Xlq4FpGcqzuWxNfwEYsxsHFCrTS1WJs7sx/F061f9UYcKIva1RRevWoJ8Bzmekide9cS3J+17KGx8XP0IVZpGtoPfmTSFweUseyBQnLzRcLGMqgYVyd2UU3SUr9dDZvRtLtrHAhLQdtSloiiMV2P7ni1F6L1hxHlFY4qmMFQb3SxULVKaNsk3PbGuTZSCk/RGYDrcEXKbr9Ll4vPMW/IWB4RDuCnSbDGIhOV41wSzX1ePZxEd2/eE4Awl7Vihui06uCtjBzf8tgWVnCedXS0ibIlFdT5Z6mabQi/djKpW3I1pbMTopo2IeOxldq5vbN91ArBnoDUtMuKfu8iPa7YXHzrhLVT2b4=
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Oct 2019 11:18:45.0293
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 47d96852-38d9-41c5-22be-08d753bcf08f
X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[63.35.35.123];Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR08MB4624
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hi John,

On Fri, Oct 18, 2019 at 05:23:19AM +0000, John Stultz wrote:
> From: "Andrew F. Davis" <afd@ti.com>
>=20
> This framework allows a unified userspace interface for dma-buf
> exporters, allowing userland to allocate specific types of memory
> for use in dma-buf sharing.
>=20
> Each heap is given its own device node, which a user can allocate
> a dma-buf fd from using the DMA_HEAP_IOC_ALLOC.
>=20
> This code is an evoluiton of the Android ION implementation,
> and a big thanks is due to its authors/maintainers over time
> for their effort:
>   Rebecca Schultz Zavin, Colin Cross, Benjamin Gaignard,
>   Laura Abbott, and many other contributors!
>=20
> Cc: Laura Abbott <labbott@redhat.com>
> Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org>
> Cc: Sumit Semwal <sumit.semwal@linaro.org>
> Cc: Liam Mark <lmark@codeaurora.org>
> Cc: Pratik Patel <pratikp@codeaurora.org>
> Cc: Brian Starkey <Brian.Starkey@arm.com>
> Cc: Vincent Donnefort <Vincent.Donnefort@arm.com>
> Cc: Sudipto Paul <Sudipto.Paul@arm.com>
> Cc: Andrew F. Davis <afd@ti.com>
> Cc: Christoph Hellwig <hch@infradead.org>
> Cc: Chenbo Feng <fengc@google.com>
> Cc: Alistair Strachan <astrachan@google.com>
> Cc: Hridya Valsaraju <hridya@google.com>
> Cc: Hillf Danton <hdanton@sina.com>
> Cc: dri-devel@lists.freedesktop.org
> Reviewed-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
> Reviewed-by: Brian Starkey <brian.starkey@arm.com>
> Acked-by: Laura Abbott <labbott@redhat.com>
> Tested-by: Ayan Kumar Halder <ayan.halder@arm.com>
> Signed-off-by: Andrew F. Davis <afd@ti.com>
> Signed-off-by: John Stultz <john.stultz@linaro.org>
> ---
> v2:
> * Folded down fixes I had previously shared in implementing
>   heaps
> * Make flags a u64 (Suggested by Laura)
> * Add PAGE_ALIGN() fix to the core alloc funciton
> * IOCTL fixups suggested by Brian
> * Added fixes suggested by Benjamin
> * Removed core stats mgmt, as that should be implemented by
>   per-heap code
> * Changed alloc to return a dma-buf fd, rather than a buffer
>   (as it simplifies error handling)
> v3:
> * Removed scare-quotes in MAINTAINERS email address
> * Get rid of .release function as it didn't do anything (from
>   Christoph)
> * Renamed filp to file (suggested by Christoph)
> * Split out ioctl handling to separate function (suggested by
>   Christoph)
> * Add comment documenting PAGE_ALIGN usage (suggested by Brian)
> * Switch from idr to Xarray (suggested by Brian)
> * Fixup cdev creation (suggested by Brian)
> * Avoid EXPORT_SYMBOL until we finalize modules (suggested by
>   Brian)
> * Make struct dma_heap internal only (folded in from Andrew)
> * Small cleanups suggested by GregKH
> * Provide class->devnode callback to get consistent /dev/
>   subdirectory naming (Suggested by Bjorn)
> v4:
> * Folded down dma-heap.h change that was in a following patch
> * Added fd_flags entry to allocation structure and pass it
>   through to heap code for use on dma-buf fd creation (suggested
>   by Benjamin)
> v5:
> * Minor cleanups
> v6:
> * Improved error path handling, minor whitespace fixes, both
>   suggested by Brian
> v7:
> * Longer Kconfig description to quiet checkpatch warnings
> * Re-add compat_ioctl bits (Hridya noticed 32bit userland wasn't
>   working)
> v8:
> * Make struct dma_heap_ops consts (Suggested by Christoph)
> * Checkpatch whitespace fixups
> v9:
> * Minor cleanups suggested by Brian Starkey
> * Rename dma_heap_get_data->dma_heap_get_drvdata suggested
>   by Hilf Danton
> v11:
> * Kconfig text improvements suggested by Randy Dunlap
> v12:
> * Add logic to prevent duplicately named heaps being added
> * Add symbol exports for heaps as modules

As in v3:

 * Avoid EXPORT_SYMBOL until we finalize modules (suggested by
   Brian)

Did something change in that regard? I still think letting modules
register heaps without a way to remove them is a recipe for issues.

Thanks,
-Brian