Received: by 2002:a05:6a10:1a4d:0:0:0:0 with SMTP id nk13csp1750046pxb; Wed, 9 Feb 2022 03:49:07 -0800 (PST) X-Google-Smtp-Source: ABdhPJw1g7JyCpiBt5SF1JqdnI7NzFmAFNebyB85cBdsulmi7i6Xbq+M8/kolVNhViefT/uvddCr X-Received: by 2002:a17:90b:4f46:: with SMTP id pj6mr2984319pjb.43.1644407347064; Wed, 09 Feb 2022 03:49:07 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1644407347; cv=none; d=google.com; s=arc-20160816; b=dwmqGshP4hVAy51gK2u7KBaeU9MFSLhJ4zlUkVeCvZfg2Asb2/n9/ba0JIVkc2m7g9 C/0dYMGoJ0XrOp6Af9Wqy6HazC5Ud6rvTOiG6AuzZY62/9+SuqmFlFMqizs9uHr56X2o omkkahMEb6n5OosVGF7er+GpqfUQTNYyGlWIrYR0w5LVp28Y5H9MqAI0TiEhWc74w32/ kqqL/uIFNeyq9XfEfCGppoBjQc0CnxQnMSUpGEKCB/QWFA95oh+Vmmo8pO6xy82wZyJE tzS/egDIRy1G6HmpA3Rl5aB7UEqloa/Dpjyo1N+YJP45muB5Zqyb1k4tKqWo1lmqvZxZ 4mUg== 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:to:from:date; bh=eLhhcqWhx+kweu8htGvon+aqaVwcvw/OAJ7I2T0rFH4=; b=zyQto+U70sFG3RlgilKqjQZxi+DiYVN25mTloATI2n8ht1sBl4sHz+wwkB6FdN1LRl KLlBaGg5LzzmCjeUDYVyTMzzYVcp+unmMa1djUZOzBORCjecPHLb4tKOpY/Il8pr/2vE 4UZL253wXuzvF+gTRPvUCTEsxYoTo24EjsQOkJlF6w7N5rwYL69qRlAKKsO9VjuczzNM D7rjvyC8vlMieCD5lR+zCQE0pXCLAg6FKHeUKqnC174A5nLR/OIlGYXgTbRMDwHmQKq7 dS+Y4/QMOZI+aREFuqbQ5TUhb0cyaF6N/BLvhXRU9IbPDUl7DQHpYvvYYEDJHhofIh/m RmUw== ARC-Authentication-Results: i=1; mx.google.com; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id il18si2115680pjb.62.2022.02.09.03.49.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 09 Feb 2022 03:49:07 -0800 (PST) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id DAE78E0E1F1E; Wed, 9 Feb 2022 01:59:22 -0800 (PST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1384897AbiBHSZj (ORCPT + 99 others); Tue, 8 Feb 2022 13:25:39 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56452 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1384908AbiBHSZ1 (ORCPT ); Tue, 8 Feb 2022 13:25:27 -0500 Received: from mx2.smtp.larsendata.com (mx2.smtp.larsendata.com [91.221.196.228]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 412BFC061576 for ; Tue, 8 Feb 2022 10:25:26 -0800 (PST) Received: from mail01.mxhotel.dk (mail01.mxhotel.dk [91.221.196.236]) by mx2.smtp.larsendata.com (Halon) with ESMTPS id a16c29e0-890c-11ec-ac19-0050568cd888; Tue, 08 Feb 2022 18:26:28 +0000 (UTC) Received: from ravnborg.org (80-162-45-141-cable.dk.customer.tdc.net [80.162.45.141]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: sam@ravnborg.org) by mail01.mxhotel.dk (Postfix) with ESMTPSA id EB6D7194BAE; Tue, 8 Feb 2022 19:25:24 +0100 (CET) Date: Tue, 8 Feb 2022 19:25:22 +0100 X-Report-Abuse-To: abuse@mxhotel.dk From: Sam Ravnborg To: DRI Development , linux-fbdev@vger.kernel.org, Thomas Zimmermann , Du Cheng , Tetsuo Handa , Intel Graphics Development , LKML , Claudio Suarez , Greg Kroah-Hartman , Daniel Vetter Subject: Re: [PATCH 13/21] fbcon: move more common code into fb_open() Message-ID: References: <20220131210552.482606-1-daniel.vetter@ffwll.ch> <20220131210552.482606-14-daniel.vetter@ffwll.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RDNS_NONE, SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no 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 Tue, Feb 08, 2022 at 02:53:59PM +0100, Daniel Vetter wrote: > On Fri, Feb 04, 2022 at 08:35:31PM +0100, Sam Ravnborg wrote: > > On Mon, Jan 31, 2022 at 10:05:44PM +0100, Daniel Vetter wrote: > > > No idea why con2fb_acquire_newinfo() initializes much less than > > > fbcon_startup(), but so be it. From a quick look most of the > > > un-initialized stuff should be fairly harmless, but who knows. > > > > > > Signed-off-by: Daniel Vetter > > > Cc: Daniel Vetter > > > Cc: Greg Kroah-Hartman > > > Cc: Tetsuo Handa > > > Cc: Thomas Zimmermann > > > Cc: Claudio Suarez > > > Cc: Du Cheng > > > --- > > > drivers/video/fbdev/core/fbcon.c | 74 +++++++++++++------------------- > > > 1 file changed, 31 insertions(+), 43 deletions(-) > > > > > > diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c > > > index b83a5a77d8a8..5a3391ff038d 100644 > > > --- a/drivers/video/fbdev/core/fbcon.c > > > +++ b/drivers/video/fbdev/core/fbcon.c > > > @@ -680,8 +680,18 @@ static int fbcon_invalid_charcount(struct fb_info *info, unsigned charcount) > > > > > > #endif /* CONFIG_MISC_TILEBLITTING */ > > > > > > +static void fbcon_release(struct fb_info *info) > > > +{ > > > + if (info->fbops->fb_release) > > > + info->fbops->fb_release(info, 0); > > > + > > > + module_put(info->fbops->owner); > > > +} > > > + > > > static int fbcon_open(struct fb_info *info) > > > { > > > + struct fbcon_ops *ops; > > > + > > > if (!try_module_get(info->fbops->owner)) > > > return -ENODEV; > > > > > > @@ -691,19 +701,22 @@ static int fbcon_open(struct fb_info *info) > > > return -ENODEV; > > > } > > > > > > - return 0; > > > -} > > > + ops = kzalloc(sizeof(struct fbcon_ops), GFP_KERNEL); > > > + if (!ops) { > > > + fbcon_release(info); > > > + return -ENOMEM; > > > + } > > > > > > -static void fbcon_release(struct fb_info *info) > > > -{ > > > - if (info->fbops->fb_release) > > > - info->fbops->fb_release(info, 0); > > > + INIT_DELAYED_WORK(&ops->cursor_work, fb_flashcursor); > > > + ops->info = info; > > > + info->fbcon_par = ops; > > > + ops->cur_blink_jiffies = HZ / 5; > > > > > > - module_put(info->fbops->owner); > > > + return 0; > > > } > > > > > > static int con2fb_acquire_newinfo(struct vc_data *vc, struct fb_info *info, > > > - int unit, int oldidx) > > > + int unit) > > > { > > > struct fbcon_ops *ops = NULL; > > > int err; > > > @@ -712,27 +725,10 @@ static int con2fb_acquire_newinfo(struct vc_data *vc, struct fb_info *info, > > > if (err) > > > return err; > > > > > > - if (!err) { > > > - ops = kzalloc(sizeof(struct fbcon_ops), GFP_KERNEL); > > > - if (!ops) > > > - err = -ENOMEM; > > > - > > > - INIT_DELAYED_WORK(&ops->cursor_work, fb_flashcursor); > > > - } > > > - > > > - if (!err) { > > > - ops->cur_blink_jiffies = HZ / 5; > > > - ops->info = info; > > > - info->fbcon_par = ops; > > > - > > > - if (vc) > > > - set_blitting_type(vc, info); > > > - } > > > + ops = info->fbcon_par; > > > > > > - if (err) { > > > - con2fb_map[unit] = oldidx; > > > - fbcon_release(info); > > > - } > > > + if (vc) > > > + set_blitting_type(vc, info); > > > > > > return err; > > > } > > > @@ -840,9 +836,11 @@ static int set_con2fb_map(int unit, int newidx, int user) > > > > > > found = search_fb_in_map(newidx); > > > > > > - con2fb_map[unit] = newidx; > > > - if (!err && !found) > > > - err = con2fb_acquire_newinfo(vc, info, unit, oldidx); > > > + if (!err && !found) { > > > + err = con2fb_acquire_newinfo(vc, info, unit); > > > + if (!err) > > > + con2fb_map[unit] = newidx; > > > + } > > This looks like an unintentional change of functionality as con2fb_map[unit] is > > only assigned when we do a con2fb_acquire_newinfo(). > > > > Staring at the code I could not say it is wrong, but not nice to hide > > the change in this patch. > > Nope, it's not an unintentional bugfix. The old con2fb_acquire_newinfo did > reset con2fb_map to oldidx upon failure, which I've found to be a most > bizarre calling convention. So this sorts this out. > > The reason I smashed this into the same patch is that I had to remove the > fbcon_release call, and so the error handling in there looked even more > funny. But I indeed failed to explain this all in the commit message. > > Ack with that explainer, or do you want me to split this out properly? Please update the commit message, then this patch has my: Acked-by: Sam Ravnborg