Re: timer(4/sparc64): remove driver

2023-03-18 Thread Ted Bullock
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

2023-03-18 Thread Denis Fondras
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