From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id DB3A0C433F5 for ; Mon, 21 Feb 2022 18:30:09 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230098AbiBUSab (ORCPT ); Mon, 21 Feb 2022 13:30:31 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:49768 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232482AbiBUSaL (ORCPT ); Mon, 21 Feb 2022 13:30:11 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 09BA9C2A; Mon, 21 Feb 2022 10:29:47 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 70CE0614CE; Mon, 21 Feb 2022 18:29:47 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 43623C340E9; Mon, 21 Feb 2022 18:29:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1645468186; bh=ZfjUNmy1VfVROCOWpX9vGvVVCfkJxiBW68BcBOGRwWQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=WaD7mzvKN5pX1/r75f4SHYMAPQpMzXqLS9P6mDzUsc9wDemPRw5za5KM4G1/wKr2N zXIKy35J9NMK3kUlHgwBFOWk+QM3g01FnmQuYmKTloqSH3O83nPj/BoEJMdWz8OxMC aX6KriMB1D+1NlSCFAe9l6vk9U7fzDP/k+ARIYEc= Date: Mon, 21 Feb 2022 19:29:44 +0100 From: Greg Kroah-Hartman To: Sai Prakash Ranjan Cc: Mark Rutland , Jiri Slaby , Elliot Berman , linux-arm-kernel@lists.infradead.org, linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org, Shanker Donthineni , Adam Wallis , Timur Tabi , Elliot Berman Subject: Re: [PATCHv4] tty: hvc: dcc: Bind driver to CPU core0 for reads and writes Message-ID: References: <20220210135632.24638-1-quic_saipraka@quicinc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org On Tue, Feb 15, 2022 at 09:33:23AM +0530, Sai Prakash Ranjan wrote: > Hi Mark, > > On 2/14/2022 8:46 PM, Mark Rutland wrote: > > Hi, > > > > On Thu, Feb 10, 2022 at 07:26:32PM +0530, Sai Prakash Ranjan wrote: > > > From: Shanker Donthineni > > > > > > Some debuggers, such as Trace32 from Lauterbach GmbH, do not handle > > > reads/writes from/to DCC on secondary cores. Each core has its > > > own DCC device registers, so when a core reads or writes from/to DCC, > > > it only accesses its own DCC device. Since kernel code can run on > > > any core, every time the kernel wants to write to the console, it > > > might write to a different DCC. > > > > > > In SMP mode, Trace32 creates multiple windows, and each window shows > > > the DCC output only from that core's DCC. The result is that console > > > output is either lost or scattered across windows. > > This has been the Linux behaviour since the dawn of time, so why is this not > > considered to be a bug in the tools? Why can't Lauterbach add an option to > > treat the cores as one? > > More like a feature request than a bug? And why would tools add such a > feature when > it is the kernel which runs in SMP mode? Shouldn't kernel be the one having > such a feature > because there would be number of such tools with the same issue and we can't > send a feature > request to all those tool vendors to add this feature right. Instead adding > this in the kernel would > avoid all these centrally at one place. Please fix this in userspace. > > Importantly, with hotplug we *cannot* guarantee that all messages will go to > > the same CPU anyway, since that could be offlined (even if it is CPU 0), so in > > general we cann't provide a guarantee here. > > Right that is true, in case of CPU hotplug this would be pretty much broken > if CPU0 is offlined. > We use these during initial bringup stage of SoCs when we don't have debug > UART console up and running > and at the time we don't much care for testing out hotplugging the CPUs and > let alone trying out > to offline CPU0 which we use and shoot our own foot :) > > Given this is mostly a debug feature, we don't mind if this doesn't > guarantee to work in hotplug scenario. We do not get to choose this type of thing. Either it will work properly, or not. Offlineing cpu 0 happens with power management situations, right? Especially with big/little systems, if CPU0 was a big one, you would remove it while only the little ones were running. I still feel this should all be handled in userspace. Especially given the problems that this patch is having with being tested properly :( thanks, greg k-h From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 04122C433EF for ; Mon, 21 Feb 2022 18:31:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=zujpzYmrFQf26lCrXs8lebSI42rth0xfpeygZ/0lS7s=; b=xE9l9O9A0HOHb1 Gdv/usKVeik6D8mMMTc5owV4Qw+N/Yo4IZhwEBzvE1Do8p5QD1owVKTvPAv0oTtXLlX8HjC5fvKfz 3JRiS1q76DUoL0NsvpNMLxWUbtQunykERyCy2B4Lb0KtCRhkr+ejDEUOcNcs4cliPdA/4BuaHT+vL YdZdmNCAEBtTQ1PqUe3taW8QBbEaogL8UyEk0sVlXAb2XUfY1b5+6ZQUbpUXjs/5LbvXKyvaQHMWG e1YqeeRJ3vFjQbknZAvK95iluBsJT6Jo3PNZvvztliJZ4MTuBd/C4ItR0fqErTFCfMV5rAkaMXj7x BvDjKwgWW3NlTABUG8VQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nMDRX-006y6c-22; Mon, 21 Feb 2022 18:29:51 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nMDRT-006y6E-TI for linux-arm-kernel@lists.infradead.org; Mon, 21 Feb 2022 18:29:49 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 69C6D614B7; Mon, 21 Feb 2022 18:29:47 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 43623C340E9; Mon, 21 Feb 2022 18:29:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1645468186; bh=ZfjUNmy1VfVROCOWpX9vGvVVCfkJxiBW68BcBOGRwWQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=WaD7mzvKN5pX1/r75f4SHYMAPQpMzXqLS9P6mDzUsc9wDemPRw5za5KM4G1/wKr2N zXIKy35J9NMK3kUlHgwBFOWk+QM3g01FnmQuYmKTloqSH3O83nPj/BoEJMdWz8OxMC aX6KriMB1D+1NlSCFAe9l6vk9U7fzDP/k+ARIYEc= Date: Mon, 21 Feb 2022 19:29:44 +0100 From: Greg Kroah-Hartman To: Sai Prakash Ranjan Cc: Mark Rutland , Jiri Slaby , Elliot Berman , linux-arm-kernel@lists.infradead.org, linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org, Shanker Donthineni , Adam Wallis , Timur Tabi , Elliot Berman Subject: Re: [PATCHv4] tty: hvc: dcc: Bind driver to CPU core0 for reads and writes Message-ID: References: <20220210135632.24638-1-quic_saipraka@quicinc.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220221_102948_054405_EBDF565C X-CRM114-Status: GOOD ( 36.54 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, Feb 15, 2022 at 09:33:23AM +0530, Sai Prakash Ranjan wrote: > Hi Mark, > > On 2/14/2022 8:46 PM, Mark Rutland wrote: > > Hi, > > > > On Thu, Feb 10, 2022 at 07:26:32PM +0530, Sai Prakash Ranjan wrote: > > > From: Shanker Donthineni > > > > > > Some debuggers, such as Trace32 from Lauterbach GmbH, do not handle > > > reads/writes from/to DCC on secondary cores. Each core has its > > > own DCC device registers, so when a core reads or writes from/to DCC, > > > it only accesses its own DCC device. Since kernel code can run on > > > any core, every time the kernel wants to write to the console, it > > > might write to a different DCC. > > > > > > In SMP mode, Trace32 creates multiple windows, and each window shows > > > the DCC output only from that core's DCC. The result is that console > > > output is either lost or scattered across windows. > > This has been the Linux behaviour since the dawn of time, so why is this not > > considered to be a bug in the tools? Why can't Lauterbach add an option to > > treat the cores as one? > > More like a feature request than a bug? And why would tools add such a > feature when > it is the kernel which runs in SMP mode? Shouldn't kernel be the one having > such a feature > because there would be number of such tools with the same issue and we can't > send a feature > request to all those tool vendors to add this feature right. Instead adding > this in the kernel would > avoid all these centrally at one place. Please fix this in userspace. > > Importantly, with hotplug we *cannot* guarantee that all messages will go to > > the same CPU anyway, since that could be offlined (even if it is CPU 0), so in > > general we cann't provide a guarantee here. > > Right that is true, in case of CPU hotplug this would be pretty much broken > if CPU0 is offlined. > We use these during initial bringup stage of SoCs when we don't have debug > UART console up and running > and at the time we don't much care for testing out hotplugging the CPUs and > let alone trying out > to offline CPU0 which we use and shoot our own foot :) > > Given this is mostly a debug feature, we don't mind if this doesn't > guarantee to work in hotplug scenario. We do not get to choose this type of thing. Either it will work properly, or not. Offlineing cpu 0 happens with power management situations, right? Especially with big/little systems, if CPU0 was a big one, you would remove it while only the little ones were running. I still feel this should all be handled in userspace. Especially given the problems that this patch is having with being tested properly :( thanks, greg k-h _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel