NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

port-sparc/47771: possible fatal typo in sparc sbus_bus_addr() function

>Number:         47771
>Category:       port-sparc
>Synopsis:       possible fatal typo in sparc sbus_bus_addr() function
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    port-sparc-maintainer
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Apr 27 04:05:00 +0000 2013
>Originator:     Izumi Tsutsui
>Release:        NetBSD 6.0
System: NetBSD/sparc 6.0 GENERIC
Architecture: sparc
Machine: sparc
It looks there is (a bit fatal) type in sbus_bus_addr() function,
which is used for framebuffer's mmap() functions.

sys/arch/sparc/dev/sbus.c has the following code:

    507 bus_addr_t
    508 sbus_bus_addr(bus_space_tag_t t, u_int btype, u_int offset)
    509 {
    511         /* XXX: sbus_bus_addr should be g/c'ed */
    512         return (BUS_ADDR(btype, offset));
    513 }

The caller of this function in sys/dev/sbus/cgsix_sbus.c is:

     98         /* Remember cookies for cgsix_mmap() */
     99         sc->sc_bustag = sa->sa_bustag;
    100         sc->sc_paddr = sbus_bus_addr(sa->sa_bustag, sa->sa_slot, 

So sbus_bus_addr() takes a slot number in the 2nd arg
and offset in the 3rd arg.

This sc->sc_paddr is used to mmap(2) framebuffers in MI cgsix driver:

   1114                         return (bus_space_mmap(sc->sc_bustag,
   1115                                 sc->sc_paddr, u+mo->mo_physoff,
   1116                                 prot, BUS_SPACE_MAP_LINEAR));

On the other hand, the definition of BUS_ADDR() is:

     79 #define BUS_ADDR(io, pa)        \
     80         ((((uint64_t)(uint32_t)(io))<<32) | (uint32_t)(pa))

so there is no slot or offset in it.

The definition of SBUS_ADDR() is:

     54 #define SBUS_ADDR(slot, off)    (SBUS_BASE + ((slot) << 25) + (off))

so it looks BUS_ADDR() in sbus_bus_addr() is a typo of SBUS_ADDR().

Code inspection.

See above, but needs more confirmation by sparc guru.
I'm not sure how sparc Xservers works, but applications
which directly access wsfb via wsdisplay (ttyE0)
don't work on sparc.

Home | Main Index | Thread Index | Old Index