Re: timer(4/sparc64): remove driver
On 2023-03-17 12:29 p.m., Mike Larkin wrote: > On Thu, Mar 16, 2023 at 12:25:15PM -0500, Scott Cheloha wrote: >> This code has been dead since we switched sparc64 to clockintr several >> months ago. Nobody has come forward asking for a timer(4/sparc64) >> intrclock. >> >> As of now, you need %TICK_CMPR or %STICK_CMPR to run OpenBSD on >> sparc64. The only machines maybe lacking these registers are certain >> early HAL/Fujitsu models like SPARC64 I and II, and maybe SPARC64 III. >> >> We can remove the driver now or wait until after unlock. >> >> The driver implementation is mixed into sparc64/clock.c. I think I >> got everything, but I'm not positive. > > I would just wait until after unlock. ok mlarkin for removing dead code > once unlock happens. Is that specific to Fujitsu variants of Sparc64 or will that hit Sun variants too? I use the sunblade 100, which uses has a IIe I think but this one is a sun branded chip as far as I'm aware.
bnxt(4): reverse bus_space_unmap(9) order
Hello, It looks to me that unmap_1 and unmap_2 in bnxt_attach() are reversed. When pci_mapreg_map() is called for sc_db_* and fails we unmap sc_db_* when we should unmap previous pci_mapreg_map() call for sc_hwrm_*. Index: if_bnxt.c === RCS file: /cvs/src/sys/dev/pci/if_bnxt.c,v retrieving revision 1.37 diff -u -p -r1.37 if_bnxt.c --- if_bnxt.c 27 Jun 2022 10:02:20 - 1.37 +++ if_bnxt.c 18 Mar 2023 14:01:59 - @@ -725,11 +725,11 @@ deintr: free_resp: bnxt_dmamem_free(sc, sc->sc_cmd_resp); unmap_2: - bus_space_unmap(sc->sc_hwrm_t, sc->sc_hwrm_h, sc->sc_hwrm_s); - sc->sc_hwrm_s = 0; -unmap_1: bus_space_unmap(sc->sc_db_t, sc->sc_db_h, sc->sc_db_s); sc->sc_db_s = 0; +unmap_1: + bus_space_unmap(sc->sc_hwrm_t, sc->sc_hwrm_h, sc->sc_hwrm_s); + sc->sc_hwrm_s = 0; } void