On Thu, Oct 23, 2008 at 9:54 PM, David Gibson <[EMAIL PROTECTED]> wrote:
> This can be used to quickly implement a userspace usable console while > you're working on a proper driver for whatever console I/O device the > hardware has. Or, it can be used to avoid writing a full blown > tty/console driver entirely for quick-and-dirty I/O hardware that will > later be replaced by something else. Ok, I think I understand this better now. Your approach seems backwards to me. HVC console client drivers already have simple put/get functions. You've written an hvc driver that makes udbg calls. Wouldn't it have been better to make a udbg driver that makes hvc calls? That way, you effectively give udbg support to all hvc drivers in one shot. In order to support udbg in my hvc driver, I have to add udbg calls. In fact, now that I've thought about it, I don't understand what your driver does. You take hvc callbacks and route them through udbg, but this only works on drivers that have udbg callbacks in the first place. In that case, why would these drivers need an hvc middle-man? -- Timur Tabi Linux kernel developer at Freescale _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
