From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751864AbdGMMca (ORCPT ); Thu, 13 Jul 2017 08:32:30 -0400 Received: from mailapp01.imgtec.com ([195.59.15.196]:45348 "EHLO imgpgp01.kl.imgtec.org" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751157AbdGMMc2 (ORCPT ); Thu, 13 Jul 2017 08:32:28 -0400 X-PGP-Universal: processed; by imgpgp01.kl.imgtec.org on Thu, 13 Jul 2017 14:43:10 +0100 Date: Thu, 13 Jul 2017 13:32:26 +0100 From: James Hogan To: Michael Ellerman CC: Palmer Dabbelt , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , Subject: Re: [PATCH 08/17] tty: New RISC-V SBI console driver Message-ID: <20170713123225.GV6973@jhogan-linux.le.imgtec.org> References: <87lgnsk0na.fsf@concordia.ellerman.id.au> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="4vN2LI5NlaUbt/8f" Content-Disposition: inline In-Reply-To: <87lgnsk0na.fsf@concordia.ellerman.id.au> User-Agent: Mutt/1.5.24 (2015-08-30) X-Originating-IP: [192.168.154.110] X-ESG-ENCRYPT-TAG: 1b7d744b Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --4vN2LI5NlaUbt/8f Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 13, 2017 at 09:59:53PM +1000, Michael Ellerman wrote: > Palmer Dabbelt writes: >=20 > > On Wed, 12 Jul 2017 04:04:00 PDT (-0700), mpe@ellerman.id.au wrote: > >> Palmer Dabbelt writes: > >> > >>> On Mon, 10 Jul 2017 23:21:07 PDT (-0700), mpe@ellerman.id.au wrote: > >>>> Palmer Dabbelt writes: > >>>>> > >>>> ... > >>>>> +#ifdef CONFIG_EARLY_PRINTK > >>>>> +static void sbi_console_write(struct console *co, const char *buf, > >>>>> + unsigned int n) > >>>>> +{ > >>>>> + int i; > >>>>> + > >>>>> + for (i =3D 0; i < n; ++i) { > >>>>> + if (buf[i] =3D=3D '\n') > >>>>> + sbi_console_putchar('\r'); > >>>>> + sbi_console_putchar(buf[i]); > >>>>> + } > >>>>> +} > >>>>> + > >>>>> +static struct console early_console_dev __initdata =3D { > >>>>> + .name =3D "early", > >>>>> + .write =3D sbi_console_write, > >>>>> + .flags =3D CON_PRINTBUFFER | CON_BOOT, > >>>> > >>>> AFAICS you could add CON_ANYTIME here, which would mean this console > >>>> would print output before the CPU is online. > >>>> > >>>> I think it doesn't currently matter because you call parse_early_par= am() > >>>> from setup_arch(), at which point the boot CPU has been marked onlin= e. > >>>> > >>>> But if this console can actually work earlier then you might be bett= er > >>>> off just registering it unconditionally very early. > >>> > >>> That seems like a good idea. I'm not familiar with how all this work= s, but > >>> from my understanding of this early_initcall() should be sufficient t= o make > >>> this work? The only other driver that sets CON_ANYTIME and supports > >>> EARLY_PRINTK is hvc_xen, but that installs a header to let init code = register > >>> the console directly. The early_initcall mechanism seems cleaner if = it does > >>> the right thing. > >> > >> Unfortunately early_initcall is not very "early" :) It's earlier than > >> all the other initcalls, but it's late compared to most of the arch bo= ot > >> code. > >> > >> The early_param() will work better, ie. register the console earlier > >> and increase the chance of you getting output from an early crash, than > >> early_initcall. But it requires you to put earlyprintk on the command = line. > >> > >> The best option is to just register the console as early as you can, i= e. > >> as soon as it can give you output. So somewhere in your setup_arch(), = or > >> even earlier (I haven't read your boot code). > > > > Doing it that way would require either moving the TTY driver into arch = code (it > > was specifically suggested we move it out) or adding a header file to a= llow > > setup_arch() to call into the driver (XEN does this, and we're doing it= for our > > timer, but it seems hacky). >=20 > I think it's fairly uncontroversial to have the early console in arch > code, especially in a case like this where there's no code shared > between the console and the TTY driver. But maybe someone will prove me > wrong. >=20 > Doing it the other way is not really hacky IMO, you can just have an > extern for the early console in one of your asm headers. For reference both metag and mips do something like this for JTAG based consoles (with drivers both residing in drivers/tty/): https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arc= h/metag/kernel/setup.c#n107 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arc= h/metag/kernel/setup.c#n234 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arc= h/mips/include/asm/cdmm.h#n98 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arc= h/mips/kernel/setup.c#n958 Its not all that pretty but it gets you console output that much earlier and is a fairly special case, so I think its worth it. Cheers James --4vN2LI5NlaUbt/8f Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEd80NauSabkiESfLYbAtpk944dnoFAllnaFkACgkQbAtpk944 dnozAA/8CQThhBI+AIJwZw+LWXLc3S7S1yIOx9uuWCEqw0jCd1+JFjwqBoL+q2B4 6ToTTG+orMrghtwx7iHAqkyyVS6HYKFxH5DHwuYJLm7i30qerKOiFZf1RanwpWR4 BGvSGInYBg88NZZmx82xKo8i5HYlczAm9PwQA5ZSHlw7hFpGUxeBjonCvAPEmwUb 0TLxWWVQKbjve/d9A4rhQbHpbPRuO4elLn3gJiIdOW0O8DkSNto+53i6jMNJ7+CD gIQE9LPH5QGIhuimhaBVC2MSwaYRPxtT7jNPRIblacl3oy5W4hPpB9zH4aLEmAxy t3/yR+9nuYP2+QobADvzervb2em3zn2nzuzOlqymKXqMAk3iDHAezsxEwjrwqD4L gywx5k3FrZ49WTEPtIBILyPtCa4hh0N6TcehVm53PBfP15DXynZR1eQQtEU/MBmn iRhvf1o2I/mXvM2nPt68TBhwFU47tiokzBbhLYtdOj4OYdN3p1J9OUFy+12juvl+ 0x3PbTUAwZdWgIrQXoisQWuBJdH5UXOZuX5yJYOo+dqg6r6plb8dHH6xqzn/Iogf x3GUgK35kTLKpiS+bxa+dAWIk6uiO2OMATpCIrmrSKSZ97GT1/3YakmYVGDZKbYa mnJQR+xoJ1Q+992JKZpJYLvOmbdD7ohvWXLcDtgzdqVSPoVd7eE= =nlLT -----END PGP SIGNATURE----- --4vN2LI5NlaUbt/8f--