Date: Thu, 17 May 2018 08:59:27 -0600 From: Warner Losh <imp@bsdimp.com> To: Andriy Gapon <avg@freebsd.org> Cc: Ian Lepore <ian@freebsd.org>, freebsd-hackers <freebsd-hackers@freebsd.org>, FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: serial console vs suspend Message-ID: <CANCZdfrj41PoEz71v1uf4B9XLyrne--3pxvB5M%2BbQJTo%2BQUH4g@mail.gmail.com> In-Reply-To: <f5af0cc9-f62a-683b-db5a-d870ae87c45a@FreeBSD.org> References: <0e1d5601-f792-0708-3bcf-7153bea8f679@FreeBSD.org> <1526563552.32688.47.camel@freebsd.org> <f5af0cc9-f62a-683b-db5a-d870ae87c45a@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, May 17, 2018 at 7:28 AM, Andriy Gapon <avg@freebsd.org> wrote: > On 17/05/2018 16:25, Ian Lepore wrote: > > Why should it go through the console layer? If the uart hardware needs > > some re-init on resume, won't that be true whether the uart is serving > > as a console, a dial-in terminal, or the interface to wifi or bluetooth > > chip? > > I think that for those things a normal device resume should do. > console gets used very early, so it may require a special resume. > We should re-init both places (maybe with a flag to prevent double if that's harmful). The console is needed very early after the resume, often earlier than the accidental location in the device tree the console device_t node lives. That way we don't lose output. The console layer gives us a convenient hook early in resume to cope. It's yet another reason, though, it should be restricted to true console devices, but that's another conversation. Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfrj41PoEz71v1uf4B9XLyrne--3pxvB5M%2BbQJTo%2BQUH4g>