Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp369474ybi; Fri, 24 May 2019 05:14:14 -0700 (PDT) X-Google-Smtp-Source: APXvYqy8bw/5rWZYVtcz5fMAtzQYlonPFnqOHid26IG+Ok8eWgqgLj9u9JbRAybYfJwGqJamq7Z/ X-Received: by 2002:a17:90a:9a89:: with SMTP id e9mr8543063pjp.110.1558700054638; Fri, 24 May 2019 05:14:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1558700054; cv=none; d=google.com; s=arc-20160816; b=GcaMicwsoDKW70xncFopwsqm0hd3QhKpdExvQUSkxVV3fmyylo6pPDiy5eAwuuqYEK d2U2wkNfnnmHDduAbDg1YinlvGsisvTEzjrKswVfh1AszuUdko9tE4gX1JgYaVhPfaqt 1LBPiFKP0bo9tiYyMylZgG62MRTIjHDYBQBVHFkhVJl3HZsKiVp+6/wrtqoA+urqOhU+ qr8Pm3/0OSGRqzS8ukMz2M2lqdP+E1WwQcVMvjML6J2NJVXrcPrJIBH/UZb8ABN0yalv 5CHYqFkma31GxiU57CNd9JsM/7U8hcjX9qmyndSWeB0uVNVLvNIFpxoPnW8410wuelKs ljfg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=CfAavZcEwnMuntMYS97hcOgUai969E7Qjfqv+D94SdU=; b=zhnzdl2pbl6MIDnNFt9E+Vkfj+KmNpeu2DprlrMh2ycl32x14iHcfrBpaKtKhWsCew kzVxfErpd4BGRV//baRyGfkjqpWf80d67dFi4fkfHp7BZvzD2SUbFnclLn5GHFkznt74 t/7wb3R8I5PY77ntWpc1iXzEXcRYsEWXI+dXOBTDPpwsz2Um5Y4gZStXeinFVReEM8ln PPhW4ANDSGcH8QZGFGVoBPbN2r1SDp8YEECWAJzS5RFbf8DhXbfRhaOt+SZ2zYfDlSmi 3hQtdnsBaapCRvywONbjiuSCjB73VQ8ssvMmWNu2q64slFsxOezZRNH3ukqvzLRUCxF0 nHYw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w184si4497750pfw.271.2019.05.24.05.13.59; Fri, 24 May 2019 05:14:14 -0700 (PDT) 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; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2391429AbfEXMMd (ORCPT + 99 others); Fri, 24 May 2019 08:12:33 -0400 Received: from mga06.intel.com ([134.134.136.31]:48482 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2391253AbfEXMMd (ORCPT ); Fri, 24 May 2019 08:12:33 -0400 X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from orsmga006.jf.intel.com ([10.7.209.51]) by orsmga104.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 May 2019 05:12:32 -0700 X-ExtLoop1: 1 Received: from stinkbox.fi.intel.com (HELO stinkbox) ([10.237.72.174]) by orsmga006.jf.intel.com with SMTP; 24 May 2019 05:12:27 -0700 Received: by stinkbox (sSMTP sendmail emulation); Fri, 24 May 2019 15:12:26 +0300 Date: Fri, 24 May 2019 15:12:26 +0300 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= To: Brian Starkey Cc: "james qian wang (Arm Technology China)" , nd , "Lowry Li (Arm Technology China)" , "Tiannan Zhu (Arm Technology China)" , "airlied@linux.ie" , Liviu Dudau , "Jonathan Chai (Arm Technology China)" , "linux-kernel@vger.kernel.org" , "dri-devel@lists.freedesktop.org" , "Julien Yin (Arm Technology China)" , "Yiqi Kang (Arm Technology China)" , "thomas Sun (Arm Technology China)" , Ayan Halder , "sean@poorly.run" Subject: Re: [PATCH] drm/komeda: Added AFBC support for komeda driver Message-ID: <20190524121226.GD5942@intel.com> References: <20190404110552.15778-1-james.qian.wang@arm.com> <20190516135748.GC1372@arm.com> <20190521084552.GA20625@james-ThinkStation-P300> <20190524111009.beddu67vvx66wvmk@DESKTOP-E1NTVVP.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20190524111009.beddu67vvx66wvmk@DESKTOP-E1NTVVP.localdomain> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, May 24, 2019 at 11:10:09AM +0000, Brian Starkey wrote: > Hi, > > On Tue, May 21, 2019 at 09:45:58AM +0100, james qian wang (Arm Technology China) wrote: > > On Thu, May 16, 2019 at 09:57:49PM +0800, Ayan Halder wrote: > > > On Thu, Apr 04, 2019 at 12:06:14PM +0100, james qian wang (Arm Technology China) wrote: > > > > > > > > +static int > > > > +komeda_fb_afbc_size_check(struct komeda_fb *kfb, struct drm_file *file, > > > > + const struct drm_mode_fb_cmd2 *mode_cmd) > > > > +{ > > > > + struct drm_framebuffer *fb = &kfb->base; > > > > + const struct drm_format_info *info = fb->format; > > > > + struct drm_gem_object *obj; > > > > + u32 alignment_w = 0, alignment_h = 0, alignment_header; > > > > + u32 n_blocks = 0, min_size = 0; > > > > + > > > > + obj = drm_gem_object_lookup(file, mode_cmd->handles[0]); > > > > + if (!obj) { > > > > + DRM_DEBUG_KMS("Failed to lookup GEM object\n"); > > > > + return -ENOENT; > > > > + } > > > > + > > > > + switch (fb->modifier & AFBC_FORMAT_MOD_BLOCK_SIZE_MASK) { > > > > + case AFBC_FORMAT_MOD_BLOCK_SIZE_32x8: > > > > + alignment_w = 32; > > > > + alignment_h = 8; > > > > + break; > > > > + case AFBC_FORMAT_MOD_BLOCK_SIZE_16x16: > > > > + alignment_w = 16; > > > > + alignment_h = 16; > > > > + break; > > > > + default: > > > Can we have something like a warn here ? > > > > will add a WARN here. > > > > I think it's better not to. fb->modifier comes from > userspace, so a malicious app could spam us with WARNs, effectively > dos-ing the system. -EINVAL should be sufficient. Should probably check that the entire modifier+format is actually valid. Otherwise you risk passing on a bogus modifier deeper into the driver which may trigger interesting bugs. Also theoretically (however unlikely) some broken userspace might start to depend on the ability to create framebuffers with crap modifiers, which could later break if you change the way you handle the modifiers. Then you're stuck between the rock and hard place because you can't break existing userspace but you still want to change the way modifiers are handled in the kernel. Best not give userspace too much rope IMO. Two ways to go about that: 1) drm_any_plane_has_format() (assumes your .format_mod_supported() does its job properly) 2) roll your own -- Ville Syrj?l? Intel