Re: sparc32 git tree

[Bob Breuer <breuerr@mc.net>]

David Miller wrote:
> The sunzilog change, hmmm... :)
> 
> This code works on my SBUS sparc64 machines using zilog serial,
> so I wonder what's going wrong.
> 
> The sunzilog_alloc_tables() sets up the global list
> sunzilog_irq_chain.
> 
> All the zilogs hang off of a single interrupt, and therefore
> we need that interrupt to process all zilogs in the system.
> That's why we pass sunzilog_irq_chain to request_irq().
> 
> I double checked the prtconf for a typical SS20 machine,
> and both zilog devices have an identical IRQ specification.
> 
> This is identical to the behavior of the driver before I made
> any changes, for example in 2.6.17.
> 
> What could be happening is that the interrupt hits before the
> start of the UART struct and device are fully setup.  Perhaps
> more of the uart_sunzilog_port initialization should be moved
> into sunzilog_alloc_tables(), but there are critical things
> we cannot initialize there because we don't have the of_device
> object handy yet.
> 
> Ok, I think I see what's happening.  We register sunzilog_interrupt
> before things like up->port.membase are fully setup.  We init
> the first port, by calling sunzilog_init_hw() and that makes
> the chip interrupt, I guess.  If that happens, the interrupt
> handler will try to read the channel registers of the other
> port as well, the pointer to which is still NULL.
> 
> Bob, can you confirm this is what is happening by putting some
> NULL checks in sunzilog_interrupt or similar?

I was debugging with a serial console, so maybe that caused it to fail
easier.  It triggered an interrupt before initializing the 2nd chip and
ZILOG_CHANNEL_FROM_PORT() was getting a NULL pointer in the interrupt
routine when it looped to the 2nd chip.

Bob