cvs commit: src/sys/dev/uart uart.h uart_core.c uart_cpu.h uart_cpu_alpha.c uart_cpu_amd64.c uart_cpu_i386.c uart_cpu_ia64.c uart_cpu_pc98.c uart_cpu_sparc64.c uart_dev_sab82532.c uart_dev_z8530.c

Marcel Moolenaar marcel at xcllnt.net
Tue Sep 23 14:11:43 PDT 2003


On Tue, Sep 23, 2003 at 02:25:38AM -0700, Takahashi Yoshihiro wrote:
> nyan        2003/09/23 02:25:38 PDT
> 
>   FreeBSD src repository
> 
>   Modified files:
>     sys/dev/uart         uart.h uart_core.c uart_cpu.h 
>                          uart_cpu_alpha.c uart_cpu_amd64.c 
>                          uart_cpu_i386.c uart_cpu_ia64.c 
>                          uart_cpu_pc98.c uart_cpu_sparc64.c 
>                          uart_dev_sab82532.c uart_dev_z8530.c 
>   Log:
>   - Keep the base address in struct uart_bas for sab82532 and z8530 modules.
>   - Remove buggy uart_cpu_busaddr() function.

I'm particularly unhappy with this change.  The addition of iobase
to struct uart_bas is very wrong. It's not needed prior to bus
enumeration and thus is not part of the minimal information required
to access the device. It strokes against newbusification in general.

Secondly, the need to the I/O address is limited to some hardware
drivers and only so that they know which channel they handle.  We
should therefore not pollute the otherwise hardware neutral infra-
structure with fields that are not genericly useful.  The hardware
driver's probe method should obtain the I/O base address only to
initialize a channel field in the hardware specific softc.

Please revert this and related/following pollution in other files.
I'm very much against this.

I also ask, very politely, that you let me review changes to uart(4)
for the time being. Even though I don't hold any locks or special
maintainer authority, I do claim guru status based on the fact that
I am the author and I do expect that people have the sensibility or
otherwise the respect to pass large or impacting changes by me. Even
if it's just for show.
I also realize that my lack of pc98 knowledge has resulted in code
that is based on assumptions that simply don't work on pc98, but
my mistake should not be kludging around by whole new and other
mistakes. 

Thanks for your cooperation,

-- 
 Marcel Moolenaar	  USPA: A-39004		 marcel at xcllnt.net


More information about the cvs-src mailing list