Fix serial_txx9 compile.

Fix serial_txx9 compile.

[Dave Jones]

drivers/serial/serial_txx9.c: In function 'receive_chars':
drivers/serial/serial_txx9.c:275: error: 'struct uart_info' has no member named 'tty'

Signed-off-by: Dave Jones <davej@redhat.com>

--- linux-2.6.26.noarch/drivers/serial/serial_txx9.c~	2008-07-21 17:13:21.000000000 -0400
+++ linux-2.6.26.noarch/drivers/serial/serial_txx9.c	2008-07-21 17:13:37.000000000 -0400
@@ -272,7 +272,7 @@ static void serial_txx9_initialize(struc
 static inline void
 receive_chars(struct uart_txx9_port *up, unsigned int *status)
 {
-	struct tty_struct *tty = up->port.info->tty;
+	struct tty_struct *tty = up->port.info->port.tty;
 	unsigned char ch;
 	unsigned int disr = *status;
 	int max_count = 256;

-- 
http://www.codemonkey.org.uk

Re: Fix serial_txx9 compile.

[Alan Cox]

On Mon, 21 Jul 2008 17:16:59 -0400
Dave Jones <davej@redhat.com> wrote:

> drivers/serial/serial_txx9.c: In function 'receive_chars':
> drivers/serial/serial_txx9.c:275: error: 'struct uart_info' has no member named 'tty'

Already fixed ages ago. Its in a patch that didn't get to Linus yet - see
the linux-next tree for the stuff pending.

Re: Fix serial_txx9 compile.

[Dave Jones]

On Mon, Jul 21, 2008 at 11:00:28PM +0100, Alan Cox wrote:
 > On Mon, 21 Jul 2008 17:16:59 -0400
 > Dave Jones <davej@redhat.com> wrote:
 > 
 > > drivers/serial/serial_txx9.c: In function 'receive_chars':
 > > drivers/serial/serial_txx9.c:275: error: 'struct uart_info' has no member named 'tty'
 > 
 > Already fixed ages ago. Its in a patch that didn't get to Linus yet - see
 > the linux-next tree for the stuff pending.

Odd. This breakage happened with the merge in -git8
Why didn't the associated fixes go along with that merge ?
If it was fixed ages ago, that implies we knowingly merged broken code,
which seems suboptimal.  If nothing else, we're breaking bisectability
by merging in two batches.

	Dave

-- 
http://www.codemonkey.org.uk

Re: Fix serial_txx9 compile.

[Alan Cox]

> Odd. This breakage happened with the merge in -git8
> Why didn't the associated fixes go along with that merge ?

Because they weren't fully tested against the clashing changes between
the tty tree, firmware and some other cleanups of unidentified origin.

Alan

Re: Fix icom serial compile.

[Dave Jones]

drivers/serial/icom.c: In function 'recv_interrupt':
drivers/serial/icom.c:733: error: 'struct uart_info' has no member named 'tty'

Signed-off-by: Dave Jones <davej@redhat.com>

--- linux-2.6.26.noarch/drivers/serial/icom.c~	2008-07-21 18:08:30.000000000 -0400
+++ linux-2.6.26.noarch/drivers/serial/icom.c	2008-07-21 18:13:00.000000000 -0400
@@ -730,7 +730,7 @@ static void xmit_interrupt(u16 port_int_
 static void recv_interrupt(u16 port_int_reg, struct icom_port *icom_port)
 {
 	short int count, rcv_buff;
-	struct tty_struct *tty = icom_port->uart_port.info->tty;
+	struct tty_struct *tty = icom_port->uart_port.info->port.tty;
 	unsigned short int status;
 	struct uart_icount *icount;
 	unsigned long offset;

-- 
http://www.codemonkey.org.uk

Re: Fix icom serial compile.

[Alan Cox]

On Mon, 21 Jul 2008 18:13:55 -0400
Dave Jones <davej@redhat.com> wrote:

> drivers/serial/icom.c: In function 'recv_interrupt':
> drivers/serial/icom.c:733: error: 'struct uart_info' has no member named 'tty'
> 
> Signed-off-by: Dave Jones <davej@redhat.com>

NAK. Already in the ttydev tree but not yet gone to Linus

Alan

Re: Fix icom serial compile.

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 726 bytes --]

Hi Alan,

On Mon, 21 Jul 2008 23:07:42 +0100 Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>
> On Mon, 21 Jul 2008 18:13:55 -0400
> Dave Jones <davej@redhat.com> wrote:
> 
> > drivers/serial/icom.c: In function 'recv_interrupt':
> > drivers/serial/icom.c:733: error: 'struct uart_info' has no member named 'tty'
> > 
> > Signed-off-by: Dave Jones <davej@redhat.com>
> 
> NAK. Already in the ttydev tree but not yet gone to Linus

I have just sent a similar patch.   I have to ask why you sent only some
of these patches since they were known to break some builds and you had
the fix patches already ...

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: Fix icom serial compile.

[Alan Cox]

> > NAK. Already in the ttydev tree but not yet gone to Linus
> 
> I have just sent a similar patch.   I have to ask why you sent only some
> of these patches since they were known to break some builds and you had
> the fix patches already ...

I sent the first batch only because some later stuff didnt apply and I
happen to believe in testing patches before sending them (something I
note certain other people clearly do after shitting the lot at Linus)

I spent the past two days travelling, and all the net time I could get
trying to get the patches merged and tested. Everyone and their
grandmother keep patching the tty code again and again. I just had
another go before bed - its now six pulls in a row someone has broken the
patches.

Quite frankly if you want to moan about the fact I've been working till
4am trying to sort this mess out you can go see figure 1.

Re: Fix icom serial compile.

[Dave Jones]

On Tue, Jul 22, 2008 at 03:05:19AM +0100, Alan Cox wrote:
 > > > NAK. Already in the ttydev tree but not yet gone to Linus
 > > 
 > > I have just sent a similar patch.   I have to ask why you sent only some
 > > of these patches since they were known to break some builds and you had
 > > the fix patches already ...
 > 
 > I sent the first batch only because some later stuff didnt apply and I
 > happen to believe in testing patches before sending them (something I
 > note certain other people clearly do after shitting the lot at Linus)

So what stopped you from just sending the two diffs already posted here
twice today ?  They're not dependant upon anything else, and the files
in questions haven't changed in months.

Leaving the tree broken, and NACKing attempts to fix it don't seem to be
particularly productive for anyone.

 > I spent the past two days travelling, and all the net time I could get
 > trying to get the patches merged and tested. Everyone and their
 > grandmother keep patching the tty code again and again. I just had
 > another go before bed - its now six pulls in a row someone has broken the
 > patches.
 > 
 > Quite frankly if you want to moan about the fact I've been working till
 > 4am trying to sort this mess out you can go see figure 1.

Please, less drama, more fixing.

	Dave

-- 
http://www.codemonkey.org.uk

Re: Fix icom serial compile.

[Alan Cox]

> Leaving the tree broken, and NACKing attempts to fix it don't seem to be
> particularly productive for anyone.

I NAKKed the fix because it would have broken the merge *AGAIN* which
would have messed up the merging for everything else all for the matter
of what four hours ?

> Please, less drama, more fixing.

Go see figure 1

Re: Fix icom serial compile.

[Paul Mackerras]

Alan Cox writes:

> On Mon, 21 Jul 2008 18:13:55 -0400
> Dave Jones <davej@redhat.com> wrote:
> 
> > drivers/serial/icom.c: In function 'recv_interrupt':
> > drivers/serial/icom.c:733: error: 'struct uart_info' has no member named 'tty'
> > 
> > Signed-off-by: Dave Jones <davej@redhat.com>
> 
> NAK. Already in the ttydev tree but not yet gone to Linus

Well then why on earth did you send Linus the patch that broke stuff
in the first place?  That seems like a pretty unfriendly act to me.

Paul.

Re: Fix icom serial compile.

[Alan Cox]

On Tue, 22 Jul 2008 11:56:46 +1000
Paul Mackerras <paulus@samba.org> wrote:

> Alan Cox writes:
> 
> > On Mon, 21 Jul 2008 18:13:55 -0400
> > Dave Jones <davej@redhat.com> wrote:
> > 
> > > drivers/serial/icom.c: In function 'recv_interrupt':
> > > drivers/serial/icom.c:733: error: 'struct uart_info' has no member named 'tty'
> > > 
> > > Signed-off-by: Dave Jones <davej@redhat.com>
> > 
> > NAK. Already in the ttydev tree but not yet gone to Linus
> 
> Well then why on earth did you send Linus the patch that broke stuff
> in the first place?  That seems like a pretty unfriendly act to me.

See previous replies, apologies to this address.