Received: by 2002:a05:6a10:2726:0:0:0:0 with SMTP id ib38csp1050519pxb; Fri, 1 Apr 2022 03:17:38 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwA1IIARXPAArP3CIQmrcpLKP1BeXPyVS8eikli/CqrzHG5V9dhQKQMeYYvI3BQ6iuT0lHJ X-Received: by 2002:a65:6942:0:b0:378:9365:5963 with SMTP id w2-20020a656942000000b0037893655963mr14242489pgq.142.1648808258294; Fri, 01 Apr 2022 03:17:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1648808258; cv=none; d=google.com; s=arc-20160816; b=qBQwGK+oHTQGwcLZ8c5kO4EjkXLlBVX+1DPMasHsATw+CePxdGKKTDBviFUUv2qw1j KARGIyMcwTWQJZTl8RQn/RyZdwS5p9acxCgtrOpXmrmTujtCtoMOcq6lVOBNyBdFT9pM Lz7XnlZknPHiFsX86MQrT/uVlYYkK8+NF4mFFrar5059uFbksVsg+F5hEVEmzrxln8uM kAxaA2/z+PNtnvMywgbzFue0DS8wlB3C/9B6OUCXziCHsifJGCwkdtXs7P0UN3ZOpNb7 IwKdhlRqc6MfMG13NqoIgzSe/ggsu4FWxkA7sA0A/WUe+drGm4Q9LHjY5lsZEp/jzsIz Vwqw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=FJ6+B6SVcInb9iC1Wez+02DIvOOAl+vUSK1Ikq+PjXQ=; b=e03Dt3lSPWzOU1BKCZk0Z4nwI6T+jVdS3Lz+l+lIqQJkQ7G3pu0sbBPPkutme/rwb2 HF81wVGk4jEwF1FBn+bFNNNfo3XxsmHy/q2yMw53B17HSjhXy0WB6Y4XR85zo3M8TQyB XEWDu4kMZMqdRbxpkvkwD89xL+8uYWZFt+Et+G6I78kCmEgwR4jGNHJFY8OWX+v1hoEi 8pvMpuk52U+1kiqWYanl5HWALRJQRd4kplgyswGcB7VHVAhpgqqM/XmCzVTpVFwlaCdj tks8KWnPNcifi07US5LJKjd1nb7HKaShUjOPK8Kq00A6yYSo/fC4XWdS5JfEqJwEsW0t 56ww== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@collabora.com header.s=mail header.b=DE4VWC1b; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=collabora.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id q16-20020a056a00151000b004fa3a8dffe2si2237730pfu.153.2022.04.01.03.17.26; Fri, 01 Apr 2022 03:17:38 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@collabora.com header.s=mail header.b=DE4VWC1b; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=collabora.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240839AbiCaTnf (ORCPT + 99 others); Thu, 31 Mar 2022 15:43:35 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60142 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241156AbiCaTnJ (ORCPT ); Thu, 31 Mar 2022 15:43:09 -0400 Received: from bhuna.collabora.co.uk (bhuna.collabora.co.uk [IPv6:2a00:1098:0:82:1000:25:2eeb:e3e3]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3B1CC127589; Thu, 31 Mar 2022 12:41:22 -0700 (PDT) Received: from [IPV6:2a00:5f00:102:0:10b3:10ff:fe5d:4ec1] (unknown [IPv6:2a00:5f00:102:0:10b3:10ff:fe5d:4ec1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: dmitry.osipenko) by bhuna.collabora.co.uk (Postfix) with ESMTPSA id AD5941F46A5D; Thu, 31 Mar 2022 20:41:19 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1648755680; bh=XyZcQg6pqR159jgtxwGtbmonYgk2JzV10bPGOcjl0Qc=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=DE4VWC1bnVsxalr1+sXEPphCLUZNPnQ1i5KR46hOq9wpUWFkfxPTdYNwayv5PeJMy x1usxrG78HxHgRkrg80QEw4tYf9RiS2VsRKfx4c//GaCzdwCB134eYNMsU1X/Am5PZ CHMG8SEJbZRSQozYR+iQMjJ5aTBptRVxwbuCqS+5WoiwEuHs+PYVimXUgW6hIIW+0q JTspnl+6ZAsyyUGvZJl4MEjp2Gdx7k35YQiEeqnhVlJ76iikG1BaLgGjDc5dRxQ8Fj JKaP1em6qv0X5Nh8PQwTuJymfxQiVRhRauJ1KZVi3CiwsRah4g89P4jCPW3xXpeBWe SDDqSfoz/jJSQ== Message-ID: <22d9a9ff-1c44-ed41-6ae1-59a1f965ab6c@collabora.com> Date: Thu, 31 Mar 2022 22:41:16 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: [PATCH v2 10/10] drm/msm: Add a way for userspace to allocate GPU iova Content-Language: en-US To: Rob Clark Cc: dri-devel , freedreno , linux-arm-msm , Dmitry Baryshkov , Rob Clark , Sean Paul , Abhinav Kumar , David Airlie , Daniel Vetter , Akhil P Oommen , Jonathan Marek , Jordan Crouse , Emma Anholt , Dan Carpenter , open list References: <20220330204804.660819-1-robdclark@gmail.com> <20220330204804.660819-11-robdclark@gmail.com> From: Dmitry Osipenko In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,SPF_HELO_PASS, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 3/31/22 22:02, Rob Clark wrote: > On Thu, Mar 31, 2022 at 11:52 AM Dmitry Osipenko > wrote: >> >> ... >>> +/* >>> + * Get the requested iova but don't pin it. Fails if the requested iova is >>> + * not available. Doesn't need a put because iovas are currently valid for >>> + * the life of the object. >>> + * >>> + * Setting an iova of zero will clear the vma. >>> + */ >>> +int msm_gem_set_iova(struct drm_gem_object *obj, >>> + struct msm_gem_address_space *aspace, uint64_t iova) >>> +{ >>> + int ret = 0; >> >> nit: No need to initialize the ret > > actually, we do Indeed, sorry :) ... >>> int msm_gem_get_and_pin_iova_range(struct drm_gem_object *obj, >>> struct msm_gem_address_space *aspace, uint64_t *iova, >>> u64 range_start, u64 range_end); >> nit: There is an odd mix of uint64_t and u64 (and alike) in the MSM code >> :) The uint64_t variant shouldn't be used by kernel code in general and >> checkpatch should want about it. > > one of many things that I disagree with checkpatch about ;-) > > I prefer standard types to custom ones. I _kinda_ get the argument in > case of uapi (but IMHO that doesn't apply to how drm uapi headers are > used) I'd understand if it was all either uint64_t or u64, but the mix.. hm.