Hello.
Tom Rini wrote:
>>>>> We've found out that drivers/serial/serial_core.c had a call to
>>>>>kgdb8250_add_port() from uart_add_one_port() and that didn't work for
>>>>>us anyway until the subsequent call to kgdb8250_add_platform_port()
>>>>>call was added to the platform code. I think we have several issues
>>>>>with this call:
>>>>So when I was doing this originally, I found that things were a bit
>>>>sensitive to where/when stuff was called. My bet is that what happened
>>>>is that in the 5-6 kernel versions that have happened since, the call
>>>>order and/or meaning of things has changed, and we need to rework this
>>>>hook.
>>> In my understanding, it's completely useless in its current form
>>>stuck anywhere in drivers/serial/ -- I mean using kgdb8250_add_port(),
>>>unless that latter function is changed.
>> Maybe it was intended for the modular 8250 driver? This way, it should
>>make sense. But anyway, it (and/or driver itself) needs to be reworked WRT
>>of registering UARTs that the KGDB driver can't support, and probably
>>moving the hook into 8250 driver itself.
> Ah yes, modular serial (and modular kgdb) are the cases I left out in
> describing things in the follow up to Vitaly.
Hm, even in this case it looks like the hook is now useless. I guess the
function marked as 'module_init' will be called before any exported function
of the module? If so, kgdb_init_io() will be called before kgdb8250_add_port()
leaving us in the same situaltion...
>> BTW, is there plans to support something other than UPIO_PORT and
>> UPIO_MEM in 8250_kgdb.c? This mainly concerns UPIO_MEM32 and UPIO_AU (and
>>maybe UPIO_TSI which actually is the same as UPIO_MEM but masks couple of
>>the hardware issues with Tsi108 UART). At least the driver should filter
>>out unsupported UARTs, not treat them as UPIO_PORT like it does now...
> Patches or hardware donations accepted. I thought that once upon a time
> we did reject if it wasn't PORT or MEM, but that wasn't a tested code
> path, so perhaps it wasn't right or was dropped.
Erm, I have a separate KGDB driver for Alchemy UART form the time when it
was still driven by its own driver, au1x00_uart.c, not by 8250.c. The issue
with it was that even if port unregistering call is added it wouldn't work
because a buglet in uart_match_port() wouldn't allow unregistering. I have now
sent the trivial fix for that buglet to Russel and he's accepted it. The
question is: do we need the Alchemy code integrated to 8250_kgdb.c (that being
somewhat non-trivial addition) or can it still live in its own driver?
WBR, Sergei
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Kgdb-bugreport mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport
