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>
index | next in thread | previous in thread | raw e-mail
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. Warnerhome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfrj41PoEz71v1uf4B9XLyrne--3pxvB5M%2BbQJTo%2BQUH4g>