Re: [PATCHv4] tty: hvc: dcc: Bind driver to CPU core0 for reads and writes - Greg Kroah-Hartman

From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Sai Prakash Ranjan <quic_saipraka@quicinc.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
	Jiri Slaby <jirislaby@kernel.org>,
	Elliot Berman <quic_eberman@quicinc.com>,
	linux-arm-kernel@lists.infradead.org,
	linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org,
	Shanker Donthineni <shankerd@codeaurora.org>,
	Adam Wallis <awallis@codeaurora.org>,
	Timur Tabi <timur@codeaurora.org>,
	Elliot Berman <eberman@codeaurora.org>
Subject: Re: [PATCHv4] tty: hvc: dcc: Bind driver to CPU core0 for reads and writes
Date: Mon, 21 Feb 2022 19:29:44 +0100	[thread overview]
Message-ID: <YhPaGB2xdf6EhEvs@kroah.com> (raw)
In-Reply-To: <f8ab050f-117b-2c8e-71b8-dbfa38d24c03@quicinc.com>

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 <shankerd@codeaurora.org>
> > > 
> > > 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