lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Thu, 9 May 2013 11:39:22 +0100
From:	Grant Likely <grant.likely@...retlab.ca>
To:	Catalin Marinas <catalin.marinas@....com>
Cc:	Peter Maydell <peter.maydell@...aro.org>,
	"linaro-kernel@...ts.linaro.org" <linaro-kernel@...ts.linaro.org>,
	"patches@...aro.org" <patches@...aro.org>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Alexander Graf <agraf@...e.de>,
	"linux-kernel@...r.kernel.org List" <linux-kernel@...r.kernel.org>,
	Christopher Covington <cov@...eaurora.org>,
	Amit Shah <amit.shah@...hat.com>,
	"kvmarm@...ts.cs.columbia.edu" <kvmarm@...ts.cs.columbia.edu>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH 0/2] Early printk support for virtio console devices.

On Wed, May 8, 2013 at 3:17 PM, Catalin Marinas <catalin.marinas@....com> wrote:
> On Tue, May 07, 2013 at 04:58:23PM +0100, Peter Maydell wrote:
>> On 7 May 2013 16:52, Christopher Covington <cov@...eaurora.org> wrote:
>> This mixes up "information that the user provides to the
>> kernel" (ie configuration) with "information that QEMU or
>> kvmtool should provide to the kernel" (ie hardware
>> description), and would require QEMU/kvmtool to parse
>> the user's commandline tool to figure out if they
>> needed to override it or edit it (or alternatively,
>> would require the user to know internal details of
>> QEMU/kvmtool's address map for the guest). I think it
>> would be nicer to keep them separate.
>
> I'm not sure it's worth it, the earlyprintk is meant for debugging the
> early kernel booting code, not for general use (you have the normal
> console for this). Someone doing platform port should know the address
> of the uart and pass the right information on the kernel command line to
> help debug early booting issues.
>
> But if someone comes up with some bindings, I won't reject the patch.

Nicolas and I have tossed back and forth the idea of having a trivial
binding in the DT which specifies a couple of physical addresses and a
mask; one write register, one status register, and the mask to say
which bit to care about in the status. Basically the bare minimum to
say "here is something that will output to an already set up serial
device" without any reference to what it actually is. Something like
that would theoretically work with any device that implements or
emulates a UART write register. The thinking is that if it is trivial
to parse then it becomes more useful as an early printk target and
usable by the zImage wrapper (arm32 bit of course). Neither of us ever
followed up on it though.

g.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ