Remove deprecated variables in sysctl(2)
Variables HW_PHYSMEM and HW_USERMEM were deprecated 13 years ago, maybe we can remove them from sysctl(2)? It was originally in sysctl(3) if someone want to do some history research https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libc/gen/Attic/sysctl.3#rev1.178 Index: sysctl.2 === RCS file: /home/reposync/src/lib/libc/sys/sysctl.2,v retrieving revision 1.44 diff -u -p -r1.44 sysctl.2 --- sysctl.218 May 2021 05:26:26 - 1.44 +++ sysctl.25 Oct 2021 16:03:28 - @@ -289,13 +289,11 @@ privileges may change the value. .It Dv HW_NCPUONLINE Ta "integer" Ta "no" .It Dv HW_PAGESIZE Ta "integer" Ta "no" .It Dv HW_PERFPOLICY Ta "string" Ta "yes" -.It Dv HW_PHYSMEM Ta "integer" Ta "no" .It Dv HW_PHYSMEM64 Ta "int64_t" Ta "no" .It Dv HW_PRODUCT Ta "string" Ta "no" .It Dv HW_SENSORS Ta "node" Ta "not applicable" .It Dv HW_SETPERF Ta "integer" Ta "yes" .It Dv HW_SMT Ta "integer" Ta "yes" -.It Dv HW_USERMEM Ta "integer" Ta "no" .It Dv HW_USERMEM64 Ta "int64_t" Ta "no" .It Dv HW_UUID Ta "string" Ta "no" .It Dv HW_VENDOR Ta "string" Ta "no" @@ -343,11 +341,6 @@ Can be one of .Dq auto , or .Dq high . -.It Dv HW_PHYSMEM -The total physical memory, in bytes. -This variable is deprecated; use -.Dv HW_PHYSMEM64 -instead. .It Dv HW_PHYSMEM64 Pq Va hw.physmem The total physical memory, in bytes. .It Dv HW_PRODUCT Pq Va hw.product @@ -393,11 +386,6 @@ is set to If set to 1, enable simultaneous multithreading (SMT) on CPUs that support it. Disabled by default. -.It Dv HW_USERMEM -The amount of available non-kernel memory in bytes. -This variable is deprecated; use -.Dv HW_USERMEM64 -instead. .It Dv HW_USERMEM64 Pq Va hw.usermem The amount of available non-kernel memory in bytes. .It Dv HW_UUID Pq Va hw.uuid
Re: Remove deprecated variables in sysctl(2)
Solene Rapenne wrote: > Variables HW_PHYSMEM and HW_USERMEM were deprecated 13 years ago, > maybe we can remove them from sysctl(2)? > > It was originally in sysctl(3) if someone want to do some history > research > https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libc/gen/Attic/sysctl.3#rev1.178 In a better world, HW_PHYSMEM and HW_USERMEM should become 64-bit by default, aliases for the 64-bit hackery that was introduced. Then everyone is happy.
Re: Remove deprecated variables in sysctl(2)
Stuart Henderson wrote: > On 2021/10/05 18:11, Solene Rapenne wrote: > > Variables HW_PHYSMEM and HW_USERMEM were deprecated 13 years ago, > > maybe we can remove them from sysctl(2)? > > "deprecated" doesn't mean removed or disabled, it just means that one > shouldn't use them. These are still in system headers and supported by > the kernel, and could possibly be used by ports. Yep. Please do not remove.
Re: Remove deprecated variables in sysctl(2)
On 2021/10/05 18:11, Solene Rapenne wrote: > Variables HW_PHYSMEM and HW_USERMEM were deprecated 13 years ago, > maybe we can remove them from sysctl(2)? "deprecated" doesn't mean removed or disabled, it just means that one shouldn't use them. These are still in system headers and supported by the kernel, and could possibly be used by ports. > It was originally in sysctl(3) if someone want to do some history > research > https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libc/gen/Attic/sysctl.3#rev1.178 > > Index: sysctl.2 > === > RCS file: /home/reposync/src/lib/libc/sys/sysctl.2,v > retrieving revision 1.44 > diff -u -p -r1.44 sysctl.2 > --- sysctl.2 18 May 2021 05:26:26 - 1.44 > +++ sysctl.2 5 Oct 2021 16:03:28 - > @@ -289,13 +289,11 @@ privileges may change the value. > .It Dv HW_NCPUONLINE Ta "integer" Ta "no" > .It Dv HW_PAGESIZE Ta "integer" Ta "no" > .It Dv HW_PERFPOLICY Ta "string" Ta "yes" > -.It Dv HW_PHYSMEM Ta "integer" Ta "no" > .It Dv HW_PHYSMEM64 Ta "int64_t" Ta "no" > .It Dv HW_PRODUCT Ta "string" Ta "no" > .It Dv HW_SENSORS Ta "node" Ta "not applicable" > .It Dv HW_SETPERF Ta "integer" Ta "yes" > .It Dv HW_SMT Ta "integer" Ta "yes" > -.It Dv HW_USERMEM Ta "integer" Ta "no" > .It Dv HW_USERMEM64 Ta "int64_t" Ta "no" > .It Dv HW_UUID Ta "string" Ta "no" > .It Dv HW_VENDOR Ta "string" Ta "no" > @@ -343,11 +341,6 @@ Can be one of > .Dq auto , > or > .Dq high . > -.It Dv HW_PHYSMEM > -The total physical memory, in bytes. > -This variable is deprecated; use > -.Dv HW_PHYSMEM64 > -instead. > .It Dv HW_PHYSMEM64 Pq Va hw.physmem > The total physical memory, in bytes. > .It Dv HW_PRODUCT Pq Va hw.product > @@ -393,11 +386,6 @@ is set to > If set to 1, enable simultaneous multithreading (SMT) on CPUs that > support it. > Disabled by default. > -.It Dv HW_USERMEM > -The amount of available non-kernel memory in bytes. > -This variable is deprecated; use > -.Dv HW_USERMEM64 > -instead. > .It Dv HW_USERMEM64 Pq Va hw.usermem > The amount of available non-kernel memory in bytes. > .It Dv HW_UUID Pq Va hw.uuid >
ifconfig(8): remove "autoconfprivacy"
OK?
diff --git ifconfig.c ifconfig.c
index 7d86e887561..33aea910d80 100644
--- ifconfig.c
+++ ifconfig.c
@@ -246,7 +246,6 @@ voidsetgroupattribs(char *, int, char *[]);
intprintgroup(char *, int);
void setautoconf(const char *, int);
void settemporary(const char *, int);
-void setprivacy(const char *, int);
void settrunkport(const char *, int);
void unsettrunkport(const char *, int);
void settrunkproto(const char *, int);
@@ -466,8 +465,6 @@ const structcmd {
{ "pltime", NEXTARG,0, setia6pltime },
{ "vltime", NEXTARG,0, setia6vltime },
{ "eui64", 0, 0, setia6eui64 },
- { "autoconfprivacy",1, 0, setprivacy },
- { "-autoconfprivacy", -1, 0, setprivacy },
{ "temporary", 1, 0, settemporary },
{ "-temporary", -1, 0, settemporary },
{ "soii", -IFXF_INET6_NOSOII, 0, setifxflags },
@@ -1602,14 +1599,6 @@ settemporary(const char *cmd, int val)
}
}
-/* XXX remove after 7.0 */
-void
-setprivacy(const char *cmd, int val)
-{
- warnx("The 'autoconfprivacy' option is deprecated, use 'temporary'");
- settemporary(cmd, val);
-}
-
#ifndef SMALL
/* ARGSUSED */
void
--
I'm not entirely sure you are real.
iwm/iwx: unbreak band-steering
AUTH -> AUTH state transitions happen if the access point uses band-steering.
This was originally implemented to fix interop with some Aruba APs.
A recent commit I made to iwm/iwx drivers probably broke this.
Here is a fix.
ok?
diff b1c80baf1b7d4bf6f528498fe67f3d1db4353371 /usr/src
blob - 8bf1224f792b4b4f1e1214660de9a211e3788d74
file + sys/dev/pci/if_iwm.c
--- sys/dev/pci/if_iwm.c
+++ sys/dev/pci/if_iwm.c
@@ -8945,9 +8945,11 @@ iwm_newstate(struct ieee80211com *ic, enum ieee80211_s
/*
* Prevent attemps to transition towards the same state, unless
* we are scanning in which case a SCAN -> SCAN transition
-* triggers another scan iteration.
+* triggers another scan iteration. And AUTH -> AUTH is needed
+* to support band-steering.
*/
- if (sc->ns_nstate == nstate && nstate != IEEE80211_S_SCAN)
+ if (sc->ns_nstate == nstate && nstate != IEEE80211_S_SCAN &&
+ nstate != IEEE80211_S_AUTH)
return 0;
if (ic->ic_state == IEEE80211_S_RUN) {
blob - 692f12524d78cde1117f4a660cc30cadf297e4af
file + sys/dev/pci/if_iwx.c
--- sys/dev/pci/if_iwx.c
+++ sys/dev/pci/if_iwx.c
@@ -7874,9 +7874,11 @@ iwx_newstate(struct ieee80211com *ic, enum ieee80211_s
/*
* Prevent attemps to transition towards the same state, unless
* we are scanning in which case a SCAN -> SCAN transition
-* triggers another scan iteration.
+* triggers another scan iteration. And AUTH -> AUTH is needed
+* to support band-steering.
*/
- if (sc->ns_nstate == nstate && nstate != IEEE80211_S_SCAN)
+ if (sc->ns_nstate == nstate && nstate != IEEE80211_S_SCAN &&
+ nstate != IEEE80211_S_AUTH)
return 0;
if (ic->ic_state == IEEE80211_S_RUN) {
Re: Handle openbsd,dma-constraint on armv7
> Date: Tue, 5 Oct 2021 12:42:21 +
> From: Visa Hankala
>
> On Mon, Oct 04, 2021 at 05:04:11PM +0200, Mark Kettenis wrote:
> > > Date: Mon, 4 Oct 2021 13:42:48 +
> > > From: Visa Hankala
> > >
> > > On the Zynq-7000, the lowest 512KiB of physical address space usually
> > > contains RAM that is usable by the CPUs. However, many other bus
> > > masters, such as the Ethernet and SDIO controllers, are not able to
> > > access the 256KiB range that starts at physical address 0x4.
> > >
> > > So far I have used a device tree that says that RAM starts at 0x8,
> > > to avoid the DMA hole. This is unconventional, though. Typically the
> > > memory node for Zynq-7000 specifies 0x0 as the starting address for RAM.
> > >
> > > I think armv7 DMA constraint should be adjusted on the Zynq-7000 so that
> > > less device tree customization would be needed.
> > >
> > > This diff makes armv7 efiboot and kernel handle the
> > > openbsd,dma-constraint device tree property, with a tweak for the Zynq.
> > > The code is similar to what is already present on arm64 and riscv64.
> > >
> > > OK?
> >
> > Hmm. How does Linux know it can't do DMA to that memory range?
> > Normally that is done through a dma-ranges property in the device
> > tree, and my idea has always been to add code to parse these
> > properties to determine the valid DMA constraints. The reason there
> > is special code for the rpi4 is because the initial device trees for
> > the rpi4 didn't have those dma-ranges properties.
>
> Linux reserves the first 512KiB in Zynq platform init code to prevent
> the region from being used.
So basically they do what we try to do here, but in the kernel. With
that explanation, this diff (with the suggested change) is ok kettenis@
Cheers,
Mark
> > I'm not necessarily against this diff going in, just curious if there
> > is a better way.
> >
> > > Index: arch/armv7/armv7/armv7_machdep.c
> > > ===
> > > RCS file: src/sys/arch/armv7/armv7/armv7_machdep.c,v
> > > retrieving revision 1.63
> > > diff -u -p -r1.63 armv7_machdep.c
> > > --- arch/armv7/armv7/armv7_machdep.c 25 Mar 2021 04:12:01 -
> > > 1.63
> > > +++ arch/armv7/armv7/armv7_machdep.c 4 Oct 2021 13:32:11 -
> > > @@ -453,6 +453,12 @@ initarm(void *arg0, void *arg1, void *ar
> > > len = fdt_node_property(node, "openbsd,uefi-mmap-desc-ver",
> > > );
> > > if (len == sizeof(mmap_desc_ver))
> > > mmap_desc_ver = bemtoh32((uint32_t *)prop);
> > > +
> > > + len = fdt_node_property(node, "openbsd,dma-constraint", );
> > > + if (len == sizeof(uint64_t[2])) {
> > > + dma_constraint.ucr_low = bemtoh64((uint64_t *)prop);
> > > + dma_constraint.ucr_high = bemtoh64((uint64_t *)prop +
> > > 1);
> > > + }
> > > }
> > >
> > > process_kernel_args();
> > > Index: arch/armv7/stand/efiboot/conf.c
> > > ===
> > > RCS file: src/sys/arch/armv7/stand/efiboot/conf.c,v
> > > retrieving revision 1.31
> > > diff -u -p -r1.31 conf.c
> > > --- arch/armv7/stand/efiboot/conf.c 10 Jun 2021 22:17:58 -
> > > 1.31
> > > +++ arch/armv7/stand/efiboot/conf.c 4 Oct 2021 13:32:11 -
> > > @@ -42,7 +42,7 @@
> > > #include "efidev.h"
> > > #include "efipxe.h"
> > >
> > > -const char version[] = "1.18";
> > > +const char version[] = "1.19";
> > > int debug = 0;
> > >
> > > struct fs_ops file_system[] = {
> > > Index: arch/armv7/stand/efiboot/efiboot.c
> > > ===
> > > RCS file: src/sys/arch/armv7/stand/efiboot/efiboot.c,v
> > > retrieving revision 1.34
> > > diff -u -p -r1.34 efiboot.c
> > > --- arch/armv7/stand/efiboot/efiboot.c7 Jun 2021 21:18:31 -
> > > 1.34
> > > +++ arch/armv7/stand/efiboot/efiboot.c4 Oct 2021 13:32:11 -
> > > @@ -435,6 +435,28 @@ efi_framebuffer(void)
> > > sizeof(framebuffer_path));
> > > }
> > >
> > > +uint64_t dma_constraint[2] = { 0, -1 };
> > > +
> > > +void
> > > +efi_dma_constraint(void)
> > > +{
> > > + void *node;
> > > +
> > > + /* Raspberry Pi 4 is "special". */
> > > + node = fdt_find_node("/");
> > > + if (fdt_node_is_compatible(node, "brcm,bcm2711"))
> > > + dma_constraint[1] = htobe64(0x3bff);
> > > +
> > > + /* Not all bus masters can access 0x4-0x7 on Zynq-7000. */
>
> Even range 0x0-0x3 has fine print on it, so I will change the above
> comment to:
>
> /* Not all bus masters can access 0x0-0x7 on Zynq-7000. */
>
> > > + if (fdt_node_is_compatible(node, "xlnx,zynq-7000"))
> > > + dma_constraint[0] = htobe64(0x0008);
> > > +
> > > + /* Pass DMA constraint. */
> > > + node = fdt_find_node("/chosen");
> > > + fdt_node_add_property(node, "openbsd,dma-constraint",
> > > + dma_constraint, sizeof(dma_constraint));
> > >
iwm: make old BSSID available to iwm_newstate when roaming
When roaming between APs, all data in struct net80211_node is replaced
as soon as we have decided to switch to a different AP.
This means that the BSSID of our old AP is no longer stored in ic_bss
once we enter iwm_newstate(). We do however use this address in firmware
commands while tearing things down, in order to prepare firmware for the
switch.
With this patch, firmware commands keep using the old BSSID while tearing
things down. We switch to the new address once we start back up in iwm_auth().
This should keep things consistent from the firmware's point of view.
(ic_bss->ni_chan is also affected. This will be fixed in a later patch
by using the channel stored in the phy context instead of ni_chan.)
Tested by florian, bket, and myself as part of a larger diff.
ok?
diff 10fe65f52d60daceea3a3690e6cc566759c1ab54
fbffc95c6dfab20098670aa21c2318a2eb3c9be7
blob - 64163c3776e9d3483e1e96c09efd40535626c10f
blob + 3c088a34148b5b8a7a41fd88d133005b9b98bc89
--- sys/dev/pci/if_iwm.c
+++ sys/dev/pci/if_iwm.c
@@ -5718,9 +5718,9 @@ iwm_rx_compressed_ba(struct iwm_softc *sc, struct iwm_
{
struct iwm_ba_notif *ban = (void *)pkt->data;
struct ieee80211com *ic = >sc_ic;
- struct ieee80211_node *ni;
+ struct ieee80211_node *ni = ic->ic_bss;
+ struct iwm_node *in = (void *)ni;
struct ieee80211_tx_ba *ba;
- struct iwm_node *in;
struct iwm_tx_ring *ring;
uint16_t seq, ssn;
int qid;
@@ -5732,12 +5732,9 @@ iwm_rx_compressed_ba(struct iwm_softc *sc, struct iwm_
return;
if (ban->sta_id != IWM_STATION_ID ||
- !IEEE80211_ADDR_EQ(ic->ic_bss->ni_macaddr, ban->sta_addr))
+ !IEEE80211_ADDR_EQ(in->in_macaddr, ban->sta_addr))
return;
- ni = ic->ic_bss;
- in = (void *)ni;
-
qid = le16toh(ban->scd_flow);
if (qid < IWM_FIRST_AGG_TX_QUEUE || qid > IWM_LAST_AGG_TX_QUEUE)
return;
@@ -6919,7 +6916,7 @@ iwm_add_sta_cmd(struct iwm_softc *sc, struct iwm_node
etherbroadcastaddr);
else
IEEE80211_ADDR_COPY(_sta_cmd.addr,
- in->in_ni.ni_bssid);
+ in->in_macaddr);
}
add_sta_cmd.add_modify = update ? 1 : 0;
add_sta_cmd.station_flags_msk
@@ -7900,7 +7897,7 @@ iwm_mac_ctxt_cmd_common(struct iwm_softc *sc, struct i
return;
}
- IEEE80211_ADDR_COPY(cmd->bssid_addr, ni->ni_bssid);
+ IEEE80211_ADDR_COPY(cmd->bssid_addr, in->in_macaddr);
iwm_ack_rates(sc, in, _ack_rates, _ack_rates);
cmd->cck_rates = htole32(cck_ack_rates);
cmd->ofdm_rates = htole32(ofdm_ack_rates);
@@ -8302,6 +8299,7 @@ iwm_auth(struct iwm_softc *sc)
return err;
}
in->in_phyctxt = >sc_phyctxt[0];
+ IEEE80211_ADDR_COPY(in->in_macaddr, in->in_ni.ni_macaddr);
err = iwm_mac_ctxt_cmd(sc, in, IWM_FW_CTXT_ACTION_ADD, 0);
if (err) {
@@ -9749,7 +9747,7 @@ int
iwm_allow_mcast(struct iwm_softc *sc)
{
struct ieee80211com *ic = >sc_ic;
- struct ieee80211_node *ni = ic->ic_bss;
+ struct iwm_node *in = (void *)ic->ic_bss;
struct iwm_mcast_filter_cmd *cmd;
size_t size;
int err;
@@ -9762,7 +9760,7 @@ iwm_allow_mcast(struct iwm_softc *sc)
cmd->port_id = 0;
cmd->count = 0;
cmd->pass_all = 1;
- IEEE80211_ADDR_COPY(cmd->bssid, ni->ni_bssid);
+ IEEE80211_ADDR_COPY(cmd->bssid, in->in_macaddr);
err = iwm_send_cmd_pdu(sc, IWM_MCAST_FILTER_CMD,
0, size, cmd);
@@ -9931,6 +9929,7 @@ iwm_stop(struct ifnet *ifp)
in->in_phyctxt = NULL;
in->tid_disable_ampdu = 0x;
in->tfd_queue_msk = 0;
+ IEEE80211_ADDR_COPY(in->in_macaddr, etheranyaddr);
sc->sc_flags &= ~(IWM_FLAG_SCANNING | IWM_FLAG_BGSCAN);
sc->sc_flags &= ~IWM_FLAG_MAC_ACTIVE;
blob - bcda8e9014625199c027cda244c649d0122f7560
blob + b43453c29a46742cad00be9e54c8a45f3ad6acb2
--- sys/dev/pci/if_iwmvar.h
+++ sys/dev/pci/if_iwmvar.h
@@ -654,6 +654,7 @@ struct iwm_softc {
struct iwm_node {
struct ieee80211_node in_ni;
struct iwm_phy_ctxt *in_phyctxt;
+ uint8_t in_macaddr[ETHER_ADDR_LEN];
uint16_t in_id;
uint16_t in_color;
Re: Handle openbsd,dma-constraint on armv7
On Mon, Oct 04, 2021 at 05:04:11PM +0200, Mark Kettenis wrote:
> > Date: Mon, 4 Oct 2021 13:42:48 +
> > From: Visa Hankala
> >
> > On the Zynq-7000, the lowest 512KiB of physical address space usually
> > contains RAM that is usable by the CPUs. However, many other bus
> > masters, such as the Ethernet and SDIO controllers, are not able to
> > access the 256KiB range that starts at physical address 0x4.
> >
> > So far I have used a device tree that says that RAM starts at 0x8,
> > to avoid the DMA hole. This is unconventional, though. Typically the
> > memory node for Zynq-7000 specifies 0x0 as the starting address for RAM.
> >
> > I think armv7 DMA constraint should be adjusted on the Zynq-7000 so that
> > less device tree customization would be needed.
> >
> > This diff makes armv7 efiboot and kernel handle the
> > openbsd,dma-constraint device tree property, with a tweak for the Zynq.
> > The code is similar to what is already present on arm64 and riscv64.
> >
> > OK?
>
> Hmm. How does Linux know it can't do DMA to that memory range?
> Normally that is done through a dma-ranges property in the device
> tree, and my idea has always been to add code to parse these
> properties to determine the valid DMA constraints. The reason there
> is special code for the rpi4 is because the initial device trees for
> the rpi4 didn't have those dma-ranges properties.
Linux reserves the first 512KiB in Zynq platform init code to prevent
the region from being used.
> I'm not necessarily against this diff going in, just curious if there
> is a better way.
>
> > Index: arch/armv7/armv7/armv7_machdep.c
> > ===
> > RCS file: src/sys/arch/armv7/armv7/armv7_machdep.c,v
> > retrieving revision 1.63
> > diff -u -p -r1.63 armv7_machdep.c
> > --- arch/armv7/armv7/armv7_machdep.c25 Mar 2021 04:12:01 -
> > 1.63
> > +++ arch/armv7/armv7/armv7_machdep.c4 Oct 2021 13:32:11 -
> > @@ -453,6 +453,12 @@ initarm(void *arg0, void *arg1, void *ar
> > len = fdt_node_property(node, "openbsd,uefi-mmap-desc-ver",
> > );
> > if (len == sizeof(mmap_desc_ver))
> > mmap_desc_ver = bemtoh32((uint32_t *)prop);
> > +
> > + len = fdt_node_property(node, "openbsd,dma-constraint", );
> > + if (len == sizeof(uint64_t[2])) {
> > + dma_constraint.ucr_low = bemtoh64((uint64_t *)prop);
> > + dma_constraint.ucr_high = bemtoh64((uint64_t *)prop +
> > 1);
> > + }
> > }
> >
> > process_kernel_args();
> > Index: arch/armv7/stand/efiboot/conf.c
> > ===
> > RCS file: src/sys/arch/armv7/stand/efiboot/conf.c,v
> > retrieving revision 1.31
> > diff -u -p -r1.31 conf.c
> > --- arch/armv7/stand/efiboot/conf.c 10 Jun 2021 22:17:58 - 1.31
> > +++ arch/armv7/stand/efiboot/conf.c 4 Oct 2021 13:32:11 -
> > @@ -42,7 +42,7 @@
> > #include "efidev.h"
> > #include "efipxe.h"
> >
> > -const char version[] = "1.18";
> > +const char version[] = "1.19";
> > intdebug = 0;
> >
> > struct fs_ops file_system[] = {
> > Index: arch/armv7/stand/efiboot/efiboot.c
> > ===
> > RCS file: src/sys/arch/armv7/stand/efiboot/efiboot.c,v
> > retrieving revision 1.34
> > diff -u -p -r1.34 efiboot.c
> > --- arch/armv7/stand/efiboot/efiboot.c 7 Jun 2021 21:18:31 -
> > 1.34
> > +++ arch/armv7/stand/efiboot/efiboot.c 4 Oct 2021 13:32:11 -
> > @@ -435,6 +435,28 @@ efi_framebuffer(void)
> > sizeof(framebuffer_path));
> > }
> >
> > +uint64_t dma_constraint[2] = { 0, -1 };
> > +
> > +void
> > +efi_dma_constraint(void)
> > +{
> > + void *node;
> > +
> > + /* Raspberry Pi 4 is "special". */
> > + node = fdt_find_node("/");
> > + if (fdt_node_is_compatible(node, "brcm,bcm2711"))
> > + dma_constraint[1] = htobe64(0x3bff);
> > +
> > + /* Not all bus masters can access 0x4-0x7 on Zynq-7000. */
Even range 0x0-0x3 has fine print on it, so I will change the above
comment to:
/* Not all bus masters can access 0x0-0x7 on Zynq-7000. */
> > + if (fdt_node_is_compatible(node, "xlnx,zynq-7000"))
> > + dma_constraint[0] = htobe64(0x0008);
> > +
> > + /* Pass DMA constraint. */
> > + node = fdt_find_node("/chosen");
> > + fdt_node_add_property(node, "openbsd,dma-constraint",
> > + dma_constraint, sizeof(dma_constraint));
> > +}
> > +
> > void
> > efi_console(void)
> > {
> > @@ -515,6 +537,7 @@ efi_makebootargs(char *bootargs, int how
> >
> > efi_framebuffer();
> > efi_console();
> > + efi_dma_constraint();
> >
> > fdt_finalize();
> >
> >
> >
>
net80211: send probe req to new AP when roaming
Send a probe request to our new AP when we are about to roam to it.
When the code modified below runs, we have just replaced ic_bss (ni)
with our new AP a few lines above.
Sending a probe request isn't strictly required but it might help to
initialize state in our AP in case our background scan was passive
(i.e. no probe requests were sent during the background scan).
Note that firmware might decide internally whether a given channel is
passive or not, without giving drivers control over this decision.
It might also help to initialize firmware state on the client side in case
firmware evaluates the probe response (beacon) which the AP should return.
This is known to happen in iwn/iwm/iwx firmware, at least.
ok?
diff 6ef004ad7244ea6e24d0c8fe19cc784f7a7c99d6
10fe65f52d60daceea3a3690e6cc566759c1ab54
blob - 213ef3fc1c96f1aa330597972dab6783ad08399a
blob + 1434b7bf27cc81ed2bd1b2343480c9ec16fdfac1
--- sys/net80211/ieee80211_node.c
+++ sys/net80211/ieee80211_node.c
@@ -1272,8 +1272,11 @@ ieee80211_node_join_bss(struct ieee80211com *ic, struc
* ieee80211_new_state() try to re-auth and thus send
* an AUTH frame to our newly selected AP.
*/
- if (bgscan)
+ if (bgscan) {
+ IEEE80211_SEND_MGMT(ic, ni,
+ IEEE80211_FC0_SUBTYPE_PROBE_REQ, 0);
mgt = IEEE80211_FC0_SUBTYPE_DEAUTH;
+ }
/*
* If we are trying another AP after the previous one
* failed (state transition AUTH->AUTH), ensure that
iwm: fixed Tx rate tweak
Make sure to use HT for data frames only in case our Tx rate is fixed.
Non-data frames are not supposed to use HT.
This change applies if the Tx rate has been fixed for testing purposes
with a command such as 'ifconfig iwm0 media HT-MCS13 mode 11n'.
I've only found this by code inspection, not because there was some
problem at run-time. But better play it safe.
ok?
diff 3f75e2890abe65d5050904183ad6752454ca8f3b
6ef004ad7244ea6e24d0c8fe19cc784f7a7c99d6
blob - 74545e96d1f0c4c07c3d3cb6fe58c0277628fbeb
blob + 64163c3776e9d3483e1e96c09efd40535626c10f
--- sys/dev/pci/if_iwm.c
+++ sys/dev/pci/if_iwm.c
@@ -6354,6 +6354,7 @@ iwm_tx_fill_cmd(struct iwm_softc *sc, struct iwm_node
if (IWM_RIDX_IS_CCK(ridx))
rate_flags |= IWM_RATE_MCS_CCK_MSK;
if ((ni->ni_flags & IEEE80211_NODE_HT) &&
+ type == IEEE80211_FC0_TYPE_DATA &&
rinfo->ht_plcp != IWM_RATE_HT_SISO_MCS_INV_PLCP) {
rate_flags |= IWM_RATE_MCS_HT_MSK;
if (ieee80211_node_supports_ht_sgi20(ni))
iwm: set assoc ID in ADD_STA command
While debugging iwm roaming issues which are now fixed in -current,
I noticed a small difference between our driver and the Linux driver:
Set the assoc ID assigned by our AP when updating the firmware station
with the ADD_STA command. Not sure if this strictly required but it
doesn't seem to hurt. This assoc ID is also present in the MAC context
data structure so presumably firmware might use this ID for something.
This needs to be done in the update case only because we don't know
our ID yet when the station is first added to firmware. The station
gets added before the association frame exchange begins.
Already tested by florian, bket, and myself as part of a larger diff.
ok?
diff 3995979b713a9ebcdddbee86864fdb4f14ca7112
3f75e2890abe65d5050904183ad6752454ca8f3b
blob - 35c4b352f905c1e493d64ccd360e022a77111e1e
blob + 74545e96d1f0c4c07c3d3cb6fe58c0277628fbeb
--- sys/dev/pci/if_iwm.c
+++ sys/dev/pci/if_iwm.c
@@ -6926,6 +6926,7 @@ iwm_add_sta_cmd(struct iwm_softc *sc, struct iwm_node
if (update) {
add_sta_cmd.modify_mask |= (IWM_STA_MODIFY_QUEUES |
IWM_STA_MODIFY_TID_DISABLE_TX);
+ add_sta_cmd.assoc_id = htole32(in->in_ni.ni_associd);
}
add_sta_cmd.tid_disable_tx = htole16(in->tid_disable_ampdu);
add_sta_cmd.tfd_queue_msk = htole32(in->tfd_queue_msk);
