From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D10C33A545E; Tue, 13 Oct 2026 10:00:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.21 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1791885633; cv=none; b=clYykD5zaagESxK4OHbo8tqbspmonjeKBLVLMpAEnx1H4JpL5yXMrKy5Y+eJIYPv4qPCq6efN2QSQ2cDg3SWtvCwYMoD64wqvWWmR5blnwB3tlbfwAL6LTXEtxphsa1JyicvGWVQyZmWPzIBoy2FuiDEMNMHxiHBI0icHKx52Bo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1791885633; c=relaxed/simple; bh=fTGeNaBIaLCVqoO0T9Dn+Yn3xOiEnsjDiubugzTxCX0=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=hGeSqJEy3awX4254dpoSGtPuKhZtsFJK+qwvUqkb87G53mJ4OLfBf2n1+Pp2jLPPmnOW2+qkpSR2bRn5mL/zcCNK8vr1jWLB5dEPa5P69fkRBEfh6ql/VodwUGl93yPyhr1YdXxHOIsPyxmgLfFYj2WcHDwqjTJx6P5LMNWpTWs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=czeWkbSM; arc=none smtp.client-ip=198.175.65.21 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="czeWkbSM" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1791885632; x=1823421632; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=fTGeNaBIaLCVqoO0T9Dn+Yn3xOiEnsjDiubugzTxCX0=; b=czeWkbSMOrILaEZukdso7oc4Osq3G8nOywlRtyp1xE78+PFbLNouEjx9 3cgyLlt99hZBN9AF70ZZLLwC7cO/4/r651D0gNLaVe7SScVIQ2rM/0eYl JLmVLtJaLMgSnxbgia8jWvRN77zBFM2LAJ47gmC33NwqdzuH+8+FghQUw lDXPik3hXJO8JToeJxahdB9HpdW8gJtu4eyhglVJE1xjCHnYYsteAUK9S GHmz6FUuu89BkNp4ch1eZA2WDhIwMfQyxVZmc9BZf5WQXXqxXK32xPdZj 3915D2gJKwU6wtQ2SKfu2Yd1sDslxKumYomuY68RlLkbLMimheCh+ak9I Q==; X-CSE-ConnectionGUID: PHvepvYzRz+erCip8MJKGA== X-CSE-MsgGUID: ww1TPNf0RQK4THe+Ctqtuw== X-IronPort-AV: E=McAfee;i="6800,10657,11933"; a="700894" X-IronPort-AV: E=Sophos;i="6.27,155,1787036400"; d="scan'208";a="700894" Received: from orviesa006.jf.intel.com ([10.64.159.146]) by orvoesa113.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Oct 2026 03:00:31 -0700 X-CSE-ConnectionGUID: 1iNYISSoTuuhs5glB6ekBw== X-CSE-MsgGUID: SGL4lvnmTw63CNrOzbER/w== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.27,155,1787036400"; d="scan'208";a="1174167" Received: from ncintean-mobl1.ger.corp.intel.com (HELO localhost) ([10.245.245.48]) by smtpauth.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Oct 2026 03:00:18 -0700 Date: Tue, 13 Oct 2026 13:00:16 +0300 From: Andy Shevchenko To: Jiri Slaby Cc: gregkh@linuxfoundation.org, linux-serial@vger.kernel.org, Ilpo =?iso-8859-1?Q?J=E4rvinen?= , Vadim Fedorenko , Richard Cochran , Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Joel Stanley , Andrew Jeffery , Ryan Chen , Billy Tsai , Florian Fainelli , Broadcom internal kernel review list , Ray Jui , Scott Branden , Al Cooper , Paul Cercueil , Matthias Brugger , AngeloGioacchino Del Regno , Chaitanya Vadrevu , "James E.J. Bottomley" , Helge Deller , Kumaravel Thiagarajan , Thierry Reding , Jonathan Hunter , Kunihiko Hayashi , Masami Hiramatsu , Kees Cook , "Gustavo A. R. Silva" , Uwe =?iso-8859-1?Q?Kleine-K=F6nig_=28The_Capable_Hub=29?= , netdev@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-aspeed@lists.ozlabs.org, linux-rpi-kernel@lists.infradead.org, linux-mips@vger.kernel.org, linux-mediatek@lists.infradead.org, linux-parisc@vger.kernel.org, linux-tegra@vger.kernel.org, linux-hardening@vger.kernel.org Subject: Re: [PATCH v2 6/6] serial: 8250: make port operations work on struct uart_8250_port Message-ID: References: Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - c/o Alberga Business Park, 6 krs, Bertel Jungin Aukio 5, 02600 Espoo On Tue, Oct 13, 2026 at 11:39:00AM +0200, Jiri Slaby wrote: > On 13. 10. 26, 11:09, Andy Shevchenko wrote: > > On Tue, Oct 13, 2026 at 09:53:26AM +0200, Jiri Slaby wrote: > > > On 13. 10. 26, 9:33, Andy Shevchenko wrote: > > > > On Tue, Oct 13, 2026 at 08:48:51AM +0200, Jiri Slaby (SUSE) wrote: ... > > > > > - rc = serial8250_register_8250_port(&port); > > > > > - if (rc < 0) > > > > > + struct uart_8250_port *uport = serial8250_register_8250_port(&port); > > > > > + if (IS_ERR(uport)) { > > > > > + rc = PTR_ERR(uport); > > > > > goto err_sysfs_remove; > > > > > + } > > > > > > > Also do not define > > > > variables in the middle of the code (it's only allowed for auto cleanup > > > > variables and for-loop iterators). > > > > > > Why, actually? > > > > Because it's the style. > > There is no hard style though. It varies across subsystems. The keyword is *slightly*. I do not see much of deviation in style in the subsystem maintainer-XXX.rst. Do you? > > Linus also told it many times > > Which is neither an argument. Linus is wrong at times ("Link:" use as an > example). Link is different, it wasn't about the code. So, for coding style we have stricter rules. > All in all, I do not insist on this at all. It's easier to read and follow > the code for me. Not necessarily the case for others... > > > First, it is used in the kernel quite a few times already > > > [1]. Second, while it is sort of c++ism (and I like to use modern c++), it > > > makes the life of the variable a lot more obvious. > > > > > > [1] eg. see output of: rg -U -C 5 '}\n+\s+struct .*\*.*=' drivers/ > > > > (you made me to install something I haven't heard about, it's better to use > > `git grep` though) > > rg is order of magnitude faster (searches in parallel). More importantly in > this case, supports multiline matches. (And respects .git ignores.) Isn't `git grep` fast enough due to looking into index and not into the files? `rg` may not look at the Git index, right? So I may not to use an arbitrary hash without checking it out first. > > Note excluded __free() if I get regexp correctly > > > > $ rg -U -l '}\n+\s+struct .*\*[^)]*=' drivers/ | less > > drivers/ufs/host/ufs-qcom.c > ... > > drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c > > > > So, less than dozen of drivers doing wrong is not an argument, try something > > better. But thanks, I will check and address this in some of the above. > > Well, it's only an example of a declaration after a previous opening brace > "{" -- this one turned out to be easy to search for. There is a lot of more, > of course. kernel/ included. Please, provide a better search line, I will look at that. For now it's just a hypothetical assumption, I am afraid. -- With Best Regards, Andy Shevchenko