Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp1841278pxb; Sat, 14 Nov 2020 04:21:26 -0800 (PST) X-Google-Smtp-Source: ABdhPJwLInuGey4fZFRkFMVA4fsvi60qAD9PevQOcRZMEChg6MDemlglngLc65NuvZGVudT0E1S+ X-Received: by 2002:a17:906:4753:: with SMTP id j19mr6009569ejs.65.1605356486666; Sat, 14 Nov 2020 04:21:26 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1605356486; cv=none; d=google.com; s=arc-20160816; b=qdiY6RiaNl58N8o7oraSGlx83j8CK1EBR0jTRt1hjJqhR8bflvjkWEtsu3atkYO4A2 xljsVVIxMXyUYv84ZqHz/Lx8AkLc5KDI7hkimOdH41DPY/xAbsbEbHO6cttvGTVLy5AV rZwsirXYvnEYcxo6570V13h9fWwUbBndNzaXfC8nuoRY9ksAbUOknKxPaw1K7JsXDd7v 2EaXz8tsjNE0sSpXyT4ALVbL1r6LgwcpBC/3IR+3OcUKEk1oOF/ncq+2SrSbgX+H+2Ii mWj7xjTUK0bGF/rp6sKSbvtnMgiByqmzRr0VPkzbYI6lJU8OG48UDNwPHh4ZSeC33wiW c6lg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=UeRGnFh2UcWWLE99FlzvX9PdolccW/1CV/kMr99tvQ8=; b=cBzSDP40bfj4I4U7C0f+D7s1yFI/JSIfrmTUKdJn0GdZ6Eh3dDYuK0swmRlVgb7Y0M llvsQs3b2847m4w6uiGmNC63z+cwtDVTirN4PCzYU65KpkqX3OVER71OBqqN3bNU7q2d OtrYr4fDKjv4nV60ryTSGXHKvtoZA9a058rzZ5nlZCye8H9jgf6Eyfa3zySpsS5h377D ELcHx2ClYRNLMXax3zkKanycRjyoh/UhgGcFho1ocCpYyMxWylV+ufznzfsYHRV9pSjM jMwr/HxqVj+QuIRl5zv7ZmoSZjKtsxzFmsIgIKfrzmLiynY5oUZAIInWV0th5DhudEpa UewA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=PHNGwpxV; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id z8si7364788ejr.523.2020.11.14.04.21.03; Sat, 14 Nov 2020 04:21:26 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=PHNGwpxV; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726826AbgKNMRM (ORCPT + 99 others); Sat, 14 Nov 2020 07:17:12 -0500 Received: from mail.kernel.org ([198.145.29.99]:35136 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726618AbgKNMRL (ORCPT ); Sat, 14 Nov 2020 07:17:11 -0500 Received: from localhost (83-86-74-64.cable.dynamic.v4.ziggo.nl [83.86.74.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id A419C22240; Sat, 14 Nov 2020 12:17:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1605356231; bh=j0DSarFbsVLsjQPuCm5CwA5GVvdprYRqIia4pc4AM2w=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=PHNGwpxVYNZRVTkv4iQsYkQ+a2QRNhXlzj1AkXHhCLMHre7YcmLbMbBesS8g6jJF3 oQpu7E+FSKKAiF6a+2OCxrEYI6BpgpRWgcX4zRWmKzPwbef3OUK1KXGe1+myDG2QW/ FZhMp/J4wMiRpv796OfdoCXPm1LL/YO7R3M50Bvc= Date: Sat, 14 Nov 2020 13:18:05 +0100 From: Greg Kroah-Hartman To: Peilin Ye Cc: Daniel Vetter , Jiri Slaby , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-fbdev@vger.kernel.org Subject: Re: [PATCH v3 0/5] console: Miscellaneous clean-ups, do not use FNTCHARCNT() in fbcon.c Message-ID: References: <20201113211633.GY401619@phenom.ffwll.local> <20201114081021.GA11811@PWN> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201114081021.GA11811@PWN> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Nov 14, 2020 at 03:10:21AM -0500, Peilin Ye wrote: > > On Fri, Nov 13, 2020 at 10:16:33PM +0100, Daniel Vetter wrote: > > > On Thu, Nov 12, 2020 at 07:02:21AM -0500, Peilin Ye wrote: > > > > Peilin Ye (5): > > > > console: Delete unused con_font_copy() callback implementations > > > > console: Delete dummy con_font_set() and con_font_default() callback implementations > > > > Fonts: Add charcount field to font_desc > > > > parisc/sticore: Avoid hard-coding built-in font charcount > > > > fbcon: Avoid using FNTCHARCNT() and hard-coded built-in font charcount > > > > > > Patches all look good to me, if Greg is ok with me applying the entire > > > pile to drm-misc-next I'll do that next week. > > On Fri, Nov 13, 2020 at 11:47:51PM +0100, Greg Kroah-Hartman wrote: > > Reviewed-by: Greg Kroah-Hartman > > Thanks for reviewing! Questions about the last patch [5/5] though, it > depends on the following assumption: > > """ > For each console `idx`, `vc_cons[idx].d->vc_font.data` and > `fb_display[idx].fontdata` always point to the same buffer. > """ > > Is this true? I think it is true by grepping for `fontdata`. I also > noticed that fbcon.c is using `vc->vc_font.data` and `p->fontdata` > interchangeably, see fbcon_get_requirement(): > > vc = vc_cons[fg_console].d; > [...] > p = &fb_display[fg_console]; > caps->x = 1 << (vc->vc_font.width - 1); > ^^^^^^^^^^^ > caps->y = 1 << (vc->vc_font.height - 1); > ^^^^^^^^^^^ > caps->len = (p->userfont) ? > FNTCHARCNT(p->fontdata) : 256; > ^^^^^^^^^^^ > > If it is true, then what is the point of using `fontdata` in `struct > fbcon_display`? Just for the `userfont` flag? Should we delete > `fontdata`, when we no longer need the `userfont` flag? Yes, after a quick look, I think your analysis here is correct. So if you can delete that, it would be nice if possible. > In this sense I think [5/5] needs more testing. Do we have test files > for fbcon, or should I try to write some tests from scratch? I don't know of any direct tests, I usually just booted into that mode and saw if everything looked like it did before. There must be some tool that you can use to change the current font, as it seems to happen at boot time on some distros. I can't remember what it's called at the moment... thanks, greg k-h