On Sat, Dec 8, 2018 at 2:50 AM Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > > On Sat, Dec 08, 2018 at 11:21:41AM +0530, Jassi Brar wrote: > > On Fri, Dec 7, 2018 at 11:50 AM Mikko Perttunen <cyndis@xxxxxxxx> wrote: > > > > > > On 07/12/2018 11.26, Jassi Brar wrote: > > > >> I thought that I could also mitigate 2) by busy looping in the TCU driver, > > > >> but it turns out that that doesn't work. The reason is that since we are > > > >> in atomic context with all interrupts disabled, the mailbox won't ever > > > >> consume any new characters, so the read pointer in the circular buffer > > > >> won't increment, leaving me with no condition upon which to loop that > > > >> would work. > > > >> > > > > So you want to be able to rely on an emulated console (running on a > > > > totally different subsystem) to dump development-phase early-boot > > > > logs? At the cost of legitimizing busy looping in atomic context - one > > > > random driver messing up the api for ever. Maybe you could have the > > > > ring buffer in some shmem and only pass the number of valid characters > > > > in it, to the remote? > > > > > > > > > > I would like to note that this is the one and only console interface > > > that exists on these systems, for both development phase and production. > > > Other UARTs are not externally accessible on the systems, or they are > > > comparatively difficult to access as they aren't intended to be used as > > > consoles in the system design. > > > > > The combination of hardware and firmware > > > implementing the console is black box from software's point of view > > > (similarly to any other UART HW). The interface has also been fixed at > > > an early system design phase, as there are many operating systems > > > running on these boards, each with their own drivers. > > > > > That is the saddest part - someone, who writes test cases for the h/w > > team and with almost no knowledge of how OSes work, decides how the > > firmware is going to work and calls it done. Then the Linux is left to > > deal with the mess as we "can't do anything about it". > > That is totally normal, and is how hardware has been almost _always_ > been designed and implemented. Nothing new here at all, it's just the > life us kernel developers get used to very quickly as it is our job to > make that hardware work and appear to userspace as something sane and > universal. > Hardware yes, we can't really change much after the fact. In this case the issue arises from the firmware - TCU's mailbox protocol implementation. Which usually is just another image loaded onto the remote master during cold-boot, and should actually be not that hard to fix/change. Even if other OSes (really?) have adapted, a pushback right now will help fix atleast the next version, otherwise the api designer will never know what s/he is doing wrong. Anyways, thanks for chiming in. I will pull the patchset. Thanks.
