Greg KH wrote:
> No, this doesn't work, I need just a fix, as I took your previous patch
> already.
Sorry, coming right up.
--
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozl
On Thu, Aug 25, 2011 at 10:32:25AM -0500, Timur Tabi wrote:
> The ePAPR embedded hypervisor specification provides an API for "byte
> channels", which are serial-like virtual devices for sending and receiving
> streams of bytes. This driver provides Linux kernel support for byte
> channels via thr
The ePAPR embedded hypervisor specification provides an API for "byte
channels", which are serial-like virtual devices for sending and receiving
streams of bytes. This driver provides Linux kernel support for byte
channels via three distinct interfaces:
1) An early-console (udbg) driver. This pr
On Fri, Jul 8, 2011 at 7:06 PM, Timur Tabi wrote:
> The ePAPR embedded hypervisor specification provides an API for "byte
> channels", which are serial-like virtual devices for sending and receiving
> streams of bytes. This driver provides Linux kernel support for byte
> channels via three distin
The ePAPR embedded hypervisor specification provides an API for "byte
channels", which are serial-like virtual devices for sending and receiving
streams of bytes. This driver provides Linux kernel support for byte
channels via three distinct interfaces:
1) An early-console (udbg) driver. This pr
On Fri, Jul 08, 2011 at 05:15:47PM -0500, Timur Tabi wrote:
> Greg KH wrote:
> > Doesn't apply at all to the tty-next tree, so I can't apply it here :(
>
> Um, where exactly is the tty-next tree? The only thing I see that looks like
> it
> is this:
>
> git://git.kernel.org/pub/scm/linux/kernel/
Greg KH wrote:
> Doesn't apply at all to the tty-next tree, so I can't apply it here :(
Um, where exactly is the tty-next tree? The only thing I see that looks like it
is this:
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty-2.6.git
But the description of this tree says, "junk tree, pl
Greg KH wrote:
>> > 3) A tty driver, which is used to handle user-space input and output. The
>> > byte channel used for the console is designated as the default tty.
>> >
>> > Signed-off-by: Timur Tabi
> Doesn't apply at all to the tty-next tree, so I can't apply it here :(
I shall take care o
On Thu, May 19, 2011 at 08:34:52AM -, Timur Tabi wrote:
> The ePAPR embedded hypervisor specification provides an API for "byte
> channels", which are serial-like virtual devices for sending and receiving
> streams of bytes. This driver provides Linux kernel support for byte
> channels via thr
On Thu, May 19, 2011 at 1:34 PM, Timur Tabi wrote:
> The ePAPR embedded hypervisor specification provides an API for "byte
> channels", which are serial-like virtual devices for sending and receiving
> streams of bytes. This driver provides Linux kernel support for byte
> channels via three disti
Timur Tabi wrote:
> The ePAPR embedded hypervisor specification provides an API for "byte
> channels", which are serial-like virtual devices for sending and receiving
> streams of bytes. This driver provides Linux kernel support for byte
> channels via three distinct interfaces:
>
> 1) An early-c
On Thu, 19 May 2011 11:05:49 -0500
Timur Tabi wrote:
> Alan Cox wrote:
> >> > +/* Pass the received data to the tty layer. Note that
> >> > this
> >> > + * function calls tty_buffer_request_room(), so I'm not
> >> > sure if
> >> > + * we should h
The ePAPR embedded hypervisor specification provides an API for "byte
channels", which are serial-like virtual devices for sending and receiving
streams of bytes. This driver provides Linux kernel support for byte
channels via three distinct interfaces:
1) An early-console (udbg) driver. This pr
On Thu, 19 May 2011 11:31:32 -0500
Timur Tabi wrote:
> Alan Cox wrote:
> > You really also need a hangup method so vhangup() does the right thing
> > and you can securely do logins etc and sessions on your console. As
> > you've got no hardware entangled in this and you already use tty_port
> > h
Alan Cox wrote:
> You really also need a hangup method so vhangup() does the right thing
> and you can securely do logins etc and sessions on your console. As
> you've got no hardware entangled in this and you already use tty_port
> helpers the hangup helper will do the work for you.
So all I need
Greg KH wrote:
> It's too late, it needed to be in linux-next _before_ the window opened.
>
> sorry,
Curses! Foiled again!
Well, then I'd like to get this patchset fixed up and approved soon after the
window closes, so that there's no excuse for missing 2.6.41.
--
Timur Tabi
Linux kernel deve
Alan Cox wrote:
>> > + /* Pass the received data to the tty layer. Note that this
>> > + * function calls tty_buffer_request_room(), so I'm not sure if
>> > + * we should have also called tty_buffer_request_room().
>> > + */
>> > + ret = tty_insert_f
On Thu, May 19, 2011 at 10:54:03AM -0500, Timur Tabi wrote:
> > Depends if the functionality is useful in your environment or not
>
> It is, but I'd like to add it later so that I can make the 2.6.40 window (if
> it
> isn't already too late).
It's too late, it needed to be in linux-next _before_
> Ok, I can do that.
>
> > Depends if the functionality is useful in your environment or not
>
> It is, but I'd like to add it later so that I can make the 2.6.40 window (if
> it
> isn't already too late).
Seems sensible.
Alan
___
Linuxppc-dev mailin
Alan Cox wrote:
>>> > > The kfifo API is probably faster and cleaner. Much of tty still uses
>>> > > CIRC_* because they predate the new APIs.
>> >
>> > Ok, I'll change it.
> I flag that one up as a general comment - don't feel you need to change
> it if CIRC_* works in your case.
CIRC_* does wor
> Under what circumstances can ttys be NULL? I currently only use this code in
> the RX and TX interrupt handlers, which are both enabled in the
> tty_port_operations.activate() function.
When you add hangup support.
>
> Is this right for the TX handler:
>
> static irqreturn_t ehv_bc_tty_tx_is
Alan Cox wrote:
> ttys = tty_port_tty_get(&bc->port);
> stuff
> if (ttys != NULL)
> tty stuff
> tty_kref_put(ttys);
Under what circumstances can ttys be NULL? I currently only use this code in
the RX and TX interrupt handlers, which are both enabled in the
tty_port_operations.activate
Arnd Bergmann wrote:
> Why is this using a full tty driver instead of the hvc framework that most
> other hypervisor consoles use?
Because HVC uses the same interface for consoles and tty, and that resulted in
dropped characters if the client driver returns EAGAIN because it's output
buffer is ful
> + struct tty_struct *ttys;
ttys are refcounted and you have a refcounted pointer for free in your
tty_port that is maintained by the tty_port logic, as well as it
providing ref counted, properly locked handling for the reference.
> +/ TTY DRIVER
> ***
On Thu, 19 May 2011 07:22:25 -0700
Greg KH wrote:
> On Thu, May 19, 2011 at 08:54:31AM -0500, Timur Tabi wrote:
> > +/*
> > + * The udbg subsystem calls this function to display a single character.
> > + * We convert CR to a CR/LF.
> > + */
> > +static void ehv_bc_udbg_putc(char c)
> > +{
> > +
On Thursday 19 May 2011, Timur Tabi wrote:
>
> The ePAPR embedded hypervisor specification provides an API for "byte
> channels", which are serial-like virtual devices for sending and receiving
> streams of bytes.
Why is this using a full tty driver instead of the hvc framework that most
other hy
On Thu, May 19, 2011 at 08:54:31AM -0500, Timur Tabi wrote:
> +/*
> + * The udbg subsystem calls this function to display a single character.
> + * We convert CR to a CR/LF.
> + */
> +static void ehv_bc_udbg_putc(char c)
> +{
> + if (c == '\n')
> + byte_channel_spin_send('\r');
> +
Greg KH wrote:
> Why do this conversion in the driver? Shouldn't that be something that
> userspace worries about?
The udbg interface is a very early kernel printk interface. I don't know what
the "u" stands for, but "dbg" is for "debug". The udbg interface is removed
once a normal console driv
The ePAPR embedded hypervisor specification provides an API for "byte
channels", which are serial-like virtual devices for sending and receiving
streams of bytes. This driver provides Linux kernel support for byte
channels via three distinct interfaces:
1) An early-console (udbg) driver. This pr
29 matches
Mail list logo
