mention U-Boot file and offset for Rockchip RK356x
ok? Index: distrib/notes/arm64/prep === RCS file: /cvs/src/distrib/notes/arm64/prep,v retrieving revision 1.18 diff -u -p -u -p -r1.18 prep --- distrib/notes/arm64/prep10 Apr 2023 12:57:15 - 1.18 +++ distrib/notes/arm64/prep18 Oct 2023 01:29:11 - @@ -132,3 +132,8 @@ Install on systems without a supported m of=/dev/sdXc seek=64 dd if=/usr/local/share/u-boot/board/u-boot.itb \ of=/dev/sdXc seek=16384 + + For systems based on Rockchip RK356x SoCs: + + dd if=/usr/local/share/u-boot/board/u-boot-rockchip.bin \ + of=/dev/sdXc seek=64
Re: Correct TP-LINK bluetooth ID
On Sat, Sep 09, 2023 at 03:16:08PM +0800, Kevin Lo wrote:
>
> On Sep 7 Douglas Silva reported this bug:
>
> https://marc.info/?l=openbsd-bugs=169407574511323=2
>
> The product id of the tp-link ub500 is 0x0604 which uses the RTL8761BUV chip.
> The diff below corrects TP-LINK bluetooth ID.
> ok?
Forgot to remove it in ure(4). Here's the revised diff, ok?
Index: sys/dev/usb/if_ure.c
===
RCS file: /cvs/src/sys/dev/usb/if_ure.c,v
retrieving revision 1.32
diff -u -p -u -p -r1.32 if_ure.c
--- sys/dev/usb/if_ure.c6 May 2023 08:07:10 - 1.32
+++ sys/dev/usb/if_ure.c9 Sep 2023 07:34:54 -
@@ -126,7 +126,6 @@ const struct usb_devno ure_devs[] = {
{ USB_VENDOR_TPLINK, USB_PRODUCT_TPLINK_EU300 },
{ USB_VENDOR_TPLINK, USB_PRODUCT_TPLINK_RTL8152B_1 },
{ USB_VENDOR_TPLINK, USB_PRODUCT_TPLINK_RTL8152B_2 },
- { USB_VENDOR_TPLINK, USB_PRODUCT_TPLINK_RTL8153 },
{ USB_VENDOR_TRENDNET, USB_PRODUCT_TRENDNET_RTL8156 },
{ USB_VENDOR_TTL, USB_PRODUCT_TTL_RTL8153 },
{ USB_VENDOR_TWINHEAD, USB_PRODUCT_TWINHEAD_RTL8153B },
Index: sys/dev/usb/usbdevs
===
RCS file: /cvs/src/sys/dev/usb/usbdevs,v
retrieving revision 1.758
diff -u -p -u -p -r1.758 usbdevs
--- sys/dev/usb/usbdevs 12 Aug 2023 20:43:49 - 1.758
+++ sys/dev/usb/usbdevs 9 Sep 2023 07:34:54 -
@@ -4478,7 +4478,7 @@ product TPLINK RTL8188EUS 0x010c RTL8188
product TPLINK EU300 0x0601 EU300
product TPLINK RTL8152B_1 0x0602 RTL8152B
product TPLINK RTL8152B_2 0x0603 RTL8152B
-product TPLINK RTL8153 0x0604 RTL8153
+product TPLINK UB500 0x0604 UB500
/* Trek Technology products */
product TREK THUMBDRIVE0x ThumbDrive
Correct TP-LINK bluetooth ID
On Sep 7 Douglas Silva reported this bug: https://marc.info/?l=openbsd-bugs=169407574511323=2 The product id of the tp-link ub500 is 0x0604 which uses the RTL8761BUV chip. The diff below corrects TP-LINK bluetooth ID. ok? Index: sys/dev/usb/usbdevs === RCS file: /cvs/src/sys/dev/usb/usbdevs,v retrieving revision 1.758 diff -u -p -u -p -r1.758 usbdevs --- sys/dev/usb/usbdevs 12 Aug 2023 20:43:49 - 1.758 +++ sys/dev/usb/usbdevs 9 Sep 2023 07:03:23 - @@ -4478,7 +4478,7 @@ product TPLINK RTL8188EUS 0x010c RTL8188 product TPLINK EU300 0x0601 EU300 product TPLINK RTL8152B_1 0x0602 RTL8152B product TPLINK RTL8152B_2 0x0603 RTL8152B -product TPLINK RTL8153 0x0604 RTL8153 +product TPLINK UB500 0x0604 UB500 /* Trek Technology products */ product TREK THUMBDRIVE0x ThumbDrive
Add Phison PS5021 ID
nvme0 at pci3 dev 0 function 0 vendor "Phison", unknown product 0x5021 rev 0x01: intx, NVMe 1.4 nvme0: TEAM TM8FPK500G, firmware ELFMB0.6, serial TPBF2210110040500017 The diff below adds another Phison NVMe device id. ok? Index: sys/dev/pci/pcidevs === RCS file: /cvs/src/sys/dev/pci/pcidevs,v retrieving revision 1.2045 diff -u -p -u -p -r1.2045 pcidevs --- sys/dev/pci/pcidevs 9 Aug 2023 21:27:47 - 1.2045 +++ sys/dev/pci/pcidevs 30 Aug 2023 06:05:11 - @@ -8236,6 +8236,7 @@ product PHILIPS SAA7231 0x7231 SAA7231 /* Phison products */ product PHISON PS5000 0x5000 PS5000 +product PHISON PS5021 0x5021 PS5021 /* Picopower */ product PICOPOWER PT80C826 0x PT80C826
Re: JH7110 PCIe device tree binding update
On Tue, Aug 29, 2023 at 09:15:41PM +0200, Mark Kettenis wrote: > > > Date: Tue, 29 Aug 2023 11:58:23 +0200 > > From: Mark Kettenis > > > > Upstreaming of the JH7110 PCIe device tree bindings isn't finished > > yet, but it seems some progress has been made and things have been > > reviewed by some of the key people involved: > > > > https://patchwork.kernel.org/project/linux-pci/list/?series=779297 > > > > Here is a diff that adjusts the driver to the current state of things > > such that we can use the latest device tree from: > > > > https://github.com/starfive-tech/linux/tree/JH7110_VisionFive2_upstream > > > > to continue development. The idea is to support the preliminary > > bindings a little bit longer such that folks can update their device > > trees. Will probably drop support for the preliminary bindings in a > > few weeks. > > > > ok? > > patrick@ pointed out that the dv_unit check won't work properly if the > first PCIe controller is disabled. So here is a diff that checks the > device address instead like we do for dwqe(4). > > ok? ok kevlo@ Tested on my VisionFive 2 v1.3b with the device tree from: https://raw.githubusercontent.com/starfive-tech/linux/JH7110_VisionFive2_upstream/arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2-v1.3b.dts It works fine, the NVMe is detected. BTW, I noticed that the memory statistics seem to be incorrect. The VisionFive 2 is equipped with 8GB RAM. OpenBSD 7.3-current (GENERIC.MP) #0: Wed Aug 30 11:52:03 CST 2023 kevlo@vf2:/usr/src/sys/arch/riscv64/compile/GENERIC.MP real mem = 4294967296 (4096MB) ^^^ avail mem = 8110370816 (7734MB) ^^^ SBI: OpenSBI v1.2, SBI Specification Version 1.0 random: good seed from bootblocks mainbus0 at root: StarFive VisionFive 2 v1.3B cpu0 at mainbus0: SiFive U7 imp 4210427 rv64imafdc_zba_zbb intc0 at cpu0 cpu0: 32KB 64b/line 64-way L1 I-cache, 32KB 64b/line 64-way L1 D-cache cpu0: 2048KB 64b/line 2048-way L2 cache cpu1 at mainbus0: SiFive U7 imp 4210427 rv64imafdc_zba_zbb cpu1: 32KB 64b/line 64-way L1 I-cache, 32KB 64b/line 64-way L1 D-cache cpu1: 2048KB 64b/line 2048-way L2 cache cpu2 at mainbus0: SiFive U7 imp 4210427 rv64imafdc_zba_zbb cpu2: 32KB 64b/line 64-way L1 I-cache, 32KB 64b/line 64-way L1 D-cache cpu2: 2048KB 64b/line 2048-way L2 cache cpu3 at mainbus0: SiFive U7 imp 4210427 rv64imafdc_zba_zbb cpu3: 32KB 64b/line 64-way L1 I-cache, 32KB 64b/line 64-way L1 D-cache cpu3: 2048KB 64b/line 2048-way L2 cache "opp-table-0" at mainbus0 not configured "display-subsystem" at mainbus0 not configured "stmmac-axi-config" at mainbus0 not configured "dvp-clock" at mainbus0 not configured "gmac0-rgmii-rxin-clock" at mainbus0 not configured "gmac0-rmii-refin-clock" at mainbus0 not configured "gmac1-rgmii-rxin-clock" at mainbus0 not configured "gmac1-rmii-refin-clock" at mainbus0 not configured "hdmitx0-pixel-clock" at mainbus0 not configured "i2srx-bclk-ext-clock" at mainbus0 not configured "i2srx-lrck-ext-clock" at mainbus0 not configured "i2stx-bclk-ext-clock" at mainbus0 not configured "i2stx-lrck-ext-clock" at mainbus0 not configured "mclk-ext-clock" at mainbus0 not configured "oscillator" at mainbus0 not configured "rtc-oscillator" at mainbus0 not configured "tdm-ext-clock" at mainbus0 not configured simplebus0 at mainbus0: "soc" plic0 at simplebus0 stfpciephy0 at simplebus0 stfpciephy1 at simplebus0 stfclock0 at simplebus0: stgcrg syscon0 at simplebus0: "syscon" stfclock1 at simplebus0: syscrg syscon1 at simplebus0: "syscon" stfclock2 at syscon1: pll stfpinctrl0 at simplebus0 stfclock3 at simplebus0: aoncrg syscon2 at simplebus0: "syscon" "timer" at simplebus0 not configured "cache-controller" at simplebus0 not configured com0 at simplebus0: dw16550 com0: console dwiic0 at simplebus0 iic0 at dwiic0 dwiic1 at simplebus0 iic1 at dwiic1 "spi" at simplebus0 not configured "tdm" at simplebus0 not configured "pwmdac" at simplebus0 not configured "i2s" at simplebus0 not configured "usb" at simplebus0 not configured "phy" at simplebus0 not configured dwiic2 at simplebus0 iic2 at dwiic2 axppmic0 at iic2 addr 0x36: AXP15060 dwiic3 at simplebus0 iic3 at dwiic3 "sony,imx219" at iic3 addr 0x10 not configured "i2s" at simplebus0 not configured "i2s" at simplebus0 not configured "pwm" at simplebus0 not configured stftemp0 at simplebus0 "spi" at simplebus0 not configured "timer" at simplebus0 not configured "watchdog" at simplebus0 not configured "crypto" at simplebus0 not configured "dma-controller" at simplebus0 not configured "rng" at simplebus0 not configured dwmmc0 at simplebus0: 49 MHz base clock sdmmc0 at dwmmc0: 8-bit, mmc high-speed, dma dwmmc1 at simplebus0: 49 MHz base clock sdmmc1 at dwmmc1: 4-bit, sd high-speed, dma dwqe0 at simplebus0 gmac 0: rev 0x00, address 6c:cf:39:00:31:1d ytphy0 at dwqe0 phy 0: YT8531 10/100/1000 PHY, rev. 11 dwqe1 at simplebus0 gmac 1: rev 0x00, address 6c:cf:39:00:31:1e dwqe1: reset timeout ytphy1 at dwqe1 phy 0:
Re: all platforms: separate cpu_initclocks() from cpu_startclock()
On Mon, Aug 21, 2023 at 10:34:53PM -0500, Scott Cheloha wrote: > > On Tue, Aug 22, 2023 at 11:28:25AM +0800, Kevin Lo wrote: > > On Mon, Aug 21, 2023 at 09:53:53PM -0500, Scott Cheloha wrote: > > > On Tue, Aug 22, 2023 at 02:36:31AM +, Mike Larkin wrote: > > > > On Mon, Aug 21, 2023 at 09:26:00PM -0500, Scott Cheloha wrote: > > > > > On Mon, Aug 21, 2023 at 10:10:58PM +, Mike Larkin wrote: > > > > > > > - alpha > > > > > > > - hppa > > > > > > > - m88k/luna88k > > > > > > > > > > > > if you are really interested in doing this [...] > > > > > > > > > > "really interested" is a bit strong. As always, my primary goal is > > > > > not to break anything when I make a commit. > > > > > > > > > > The luna88k patch looks pretty straightfoward, but it's hard to be > > > > > completely sure I didn't screw something up. > > > > > > > > > > > [...] you could run this in nono since you're just looking for > > > > > > a compile/boot test. > > > > > > > > > > Apparently the license forbids redistribution. Super annoying. > > > > > > > > > > > > > so? install it, boot a luna88k "vm", test your diff, then you have your > > > > question answered. you aren't redistributing anything. > > > > > > No, I mean that there is no binary for pkg_add, so I have to build it > > > by hand. Unless I'm missing something? > > > > Hi Scott, > > > > You could install emulators/nono, which is luna88k emulator. > > ??? > > I just tried that, it says there is no such thing. > > $ doas pkg_add nono > quirks-6.138 signed on 2023-08-20T20:51:44Z > Can't find nono > $ doas pkg_add emulators/nono > quirks-6.138 signed on 2023-08-20T20:51:44Z > file:emulators/: empty > Can't find nono > > What am I missing here? I'm really sorry, I'm stumped. Because of https://github.com/openbsd/ports/blob/master/emulators/nono/Makefile#L14, you need to install nono from the ports tree, thanks.
rtwn: R92C_RXDW0_OWN -> R92C_TXDW0_OWN
In rtwn_tx(), check if the OWN bit of Tx instead of Rx is set.
Luckily, definitions of R92C_TXDW0_OWN and R92C_RXDW0_OWN are the same.
ok?
Index: sys/dev/pci/if_rtwn.c
===
RCS file: /cvs/src/sys/dev/pci/if_rtwn.c,v
retrieving revision 1.40
diff -u -p -u -p -r1.40 if_rtwn.c
--- sys/dev/pci/if_rtwn.c 21 Apr 2022 21:03:03 - 1.40
+++ sys/dev/pci/if_rtwn.c 14 Jul 2023 06:43:06 -
@@ -1022,7 +1022,7 @@ rtwn_tx(void *cookie, struct mbuf *m, st
/* Fill Tx descriptor. */
txd = _ring->desc[tx_ring->cur];
- if (htole32(txd->txdw0) & R92C_RXDW0_OWN) {
+ if (htole32(txd->txdw0) & R92C_TXDW0_OWN) {
m_freem(m);
return (ENOBUFS);
}
ure(4): add support for RTL8153D
Hi,
This diff adds initial support for RTL8153D to ure(4).
The RTL8153D chipset shares many similarities with the already supported
RTL8156B chip but additionally requires a few semi-unique configurations.
Tested:
ure0 at uhub0 port 3 configuration 1 interface 0 "Realtek USB 10/100/1000 LAN"
rev 2.10/f3.f0 addr 2
ure0: RTL8153D (0x7420), address 00:e0:4c:xx:xx:xx
ok?
Index: sys/dev/usb/if_ure.c
===
RCS file: /cvs/src/sys/dev/usb/if_ure.c,v
retrieving revision 1.31
diff -u -p -u -p -r1.31 if_ure.c
--- sys/dev/usb/if_ure.c27 Oct 2022 13:21:14 - 1.31
+++ sys/dev/usb/if_ure.c4 May 2023 06:05:03 -
@@ -270,7 +270,7 @@ ure_read_1(struct ure_softc *sc, uint16_
shift = (reg & 3) << 3;
reg &= ~3;
-
+
ure_read_mem(sc, reg, index, , 4);
val = UGETDW(temp);
val >>= shift;
@@ -466,8 +466,8 @@ ure_ifmedia_init(struct ifnet *ifp)
reg = sc->ure_rxbufsz - URE_FRAMELEN(ifp->if_mtu) -
sizeof(struct ure_rxpkt) - URE_RX_BUF_ALIGN;
- if (sc->ure_flags & (URE_FLAG_8153B | URE_FLAG_8156 |
- URE_FLAG_8156B)) {
+ if (sc->ure_flags &
+ (URE_FLAG_8153B | URE_FLAG_8156 | URE_FLAG_8156B)) {
ure_write_2(sc, URE_USB_RX_EARLY_SIZE, URE_MCU_TYPE_USB,
reg / 8);
@@ -493,6 +493,11 @@ ure_ifmedia_init(struct ifnet *ifp)
reg);
}
+ if (sc->ure_chip & URE_CHIP_VER_7420) {
+ URE_SETBIT_2(sc, URE_PLA_MAC_PWR_CTRL4,
+ URE_MCU_TYPE_PLA, URE_IDLE_SPDWN_EN);
+ }
+
if ((sc->ure_chip & URE_CHIP_VER_6010) ||
(sc->ure_flags & URE_FLAG_8156B)) {
URE_CLRBIT_2(sc, URE_USB_FW_TASK, URE_MCU_TYPE_USB,
@@ -502,7 +507,7 @@ ure_ifmedia_init(struct ifnet *ifp)
URE_FC_PATCH_TASK);
}
}
-
+
/* Reset the packet filter. */
URE_CLRBIT_2(sc, URE_PLA_FMC, URE_MCU_TYPE_PLA, URE_FMC_FCR_MCU_EN);
URE_SETBIT_2(sc, URE_PLA_FMC, URE_MCU_TYPE_PLA, URE_FMC_FCR_MCU_EN);
@@ -530,15 +535,18 @@ ure_ifmedia_upd(struct ifnet *ifp)
if (IFM_TYPE(ifm->ifm_media) != IFM_ETHER)
return (EINVAL);
- reg = ure_ocp_reg_read(sc, 0xa5d4);
- reg &= ~URE_ADV_2500TFDX;
+ if (!(sc->ure_chip & URE_CHIP_VER_7420)) {
+ reg = ure_ocp_reg_read(sc, URE_OCP_10GBT_CTRL);
+ reg &= ~URE_ADV_2500TFDX;
+ }
anar = gig = 0;
switch (IFM_SUBTYPE(ifm->ifm_media)) {
case IFM_AUTO:
anar |= ANAR_TX_FD | ANAR_TX | ANAR_10_FD | ANAR_10;
gig |= GTCR_ADV_1000TFDX | GTCR_ADV_1000THDX;
- reg |= URE_ADV_2500TFDX;
+ if (!(sc->ure_chip & URE_CHIP_VER_7420))
+ reg |= URE_ADV_2500TFDX;
break;
case IFM_2500_T:
anar |= ANAR_TX_FD | ANAR_TX | ANAR_10_FD | ANAR_10;
@@ -566,9 +574,10 @@ ure_ifmedia_upd(struct ifnet *ifp)
}
ure_ocp_reg_write(sc, URE_OCP_BASE_MII + MII_ANAR * 2,
- anar | ANAR_PAUSE_ASYM | ANAR_FC);
- ure_ocp_reg_write(sc, URE_OCP_BASE_MII + MII_100T2CR * 2, gig);
- ure_ocp_reg_write(sc, 0xa5d4, reg);
+ anar | ANAR_PAUSE_ASYM | ANAR_FC);
+ ure_ocp_reg_write(sc, URE_OCP_BASE_MII + MII_100T2CR * 2, gig);
+ if (!(sc->ure_chip & URE_CHIP_VER_7420))
+ ure_ocp_reg_write(sc, URE_OCP_10GBT_CTRL, reg);
ure_ocp_reg_write(sc, URE_OCP_BASE_MII + MII_BMCR,
BMCR_AUTOEN | BMCR_STARTNEG);
@@ -602,7 +611,7 @@ ure_ifmedia_sts(struct ifnet *ifp, struc
status = ure_read_2(sc, URE_PLA_PHYSTATUS,
URE_MCU_TYPE_PLA);
if ((status & URE_PHYSTATUS_FDX) ||
- (status & URE_PHYSTATUS_2500MBPS))
+ (status & URE_PHYSTATUS_2500MBPS))
ifmr->ifm_active |= IFM_FDX;
else
ifmr->ifm_active |= IFM_HDX;
@@ -634,9 +643,11 @@ ure_add_media_types(struct ure_softc *sc
ifmedia_add(>ure_ifmedia, IFM_ETHER | IFM_1000_T, 0, NULL);
ifmedia_add(>ure_ifmedia, IFM_ETHER | IFM_1000_T | IFM_FDX, 0,
NULL);
- ifmedia_add(>ure_ifmedia, IFM_ETHER | IFM_2500_T, 0, NULL);
- ifmedia_add(>ure_ifmedia, IFM_ETHER | IFM_2500_T | IFM_FDX, 0,
- NULL);
+ if (!(sc->ure_chip & URE_CHIP_VER_7420)) {
+
Re: Add another Lenovo NVMe device id
May I commit this diff? Thanks. On Thu, Apr 27, 2023 at 02:44:12PM +0800, Kevin Lo wrote: > > Found in my x1 extreme gen 1: > nvme0 at pci4 dev 0 function 0 vendor "Lenovo", unknown product 0x0006 rev > 0x00: msix, NVMe 1.2 > > ok? > > Index: sys/dev/pci/pcidevs > === > RCS file: /cvs/src/sys/dev/pci/pcidevs,v > retrieving revision 1.2032 > diff -u -p -u -p -r1.2032 pcidevs > --- sys/dev/pci/pcidevs 25 Apr 2023 21:57:29 - 1.2032 > +++ sys/dev/pci/pcidevs 27 Apr 2023 06:38:24 - > @@ -7061,6 +7061,7 @@ product LEADTEK WINFAST_XP 0x6609 Leadte > > /* Lenovo products */ > product LENOVO NVME 0x0003 NVMe > +product LENOVO NVME_20x0006 NVMe > > /* Level 1 (Intel) */ > product LEVEL1 LXT1001 0x0001 LXT1001 >
Add another Lenovo NVMe device id
Found in my x1 extreme gen 1: nvme0 at pci4 dev 0 function 0 vendor "Lenovo", unknown product 0x0006 rev 0x00: msix, NVMe 1.2 ok? Index: sys/dev/pci/pcidevs === RCS file: /cvs/src/sys/dev/pci/pcidevs,v retrieving revision 1.2032 diff -u -p -u -p -r1.2032 pcidevs --- sys/dev/pci/pcidevs 25 Apr 2023 21:57:29 - 1.2032 +++ sys/dev/pci/pcidevs 27 Apr 2023 06:38:24 - @@ -7061,6 +7061,7 @@ product LEADTEK WINFAST_XP0x6609 Leadte /* Lenovo products */ product LENOVO NVME0x0003 NVMe +product LENOVO NVME_2 0x0006 NVMe /* Level 1 (Intel) */ product LEVEL1 LXT1001 0x0001 LXT1001
Re: atactl(8): 'readattr' subcommand quits silently.
On Thu, Apr 27, 2023 at 08:37:23AM +0900, YASUOKA Masahiko wrote:
>
> Hello,
>
> On Wed, 26 Apr 2023 16:32:28 +0900
> Yuichiro NAITO wrote:
> > These 2 revisions of 'attr_val' and 'attr_thr' are different on this
> > disk.
> > The comment says that it's wrong vendor implementation but I can see
> > 'smartctl' shows the attributes as follows. NetBSD's atactl doesn't
> > see these 2 revisions are same but checks each checksum is valid.
>
> The diff seems correct.
>
> ok?
ok kevlo@
> > diff --git a/sbin/atactl/atactl.c b/sbin/atactl/atactl.c
> > index 85dfced8c9a..1f77460ce3d 100644
> > --- a/sbin/atactl/atactl.c
> > +++ b/sbin/atactl/atactl.c
> > @@ -1657,13 +1657,11 @@ device_attr(int argc, char *argv[])
> > req.datalen = sizeof(attr_thr);
> > ata_command();
> >
> > - if (attr_val.revision != attr_thr.revision) {
> > - /*
> > -* Non standard vendor implementation.
> > -* Return, since we don't know how to use this.
> > -*/
> > - return;
> > - }
> > + if (smart_cksum((u_int8_t *)_val, sizeof(attr_val)) != 0)
> > + errx(1, "Checksum mismatch (attr_val)");
> > +
> > + if (smart_cksum((u_int8_t *)_thr, sizeof(attr_thr)) != 0)
> > + errx(1, "Checksum mismatch (attr_thr)");
> >
> > attr = attr_val.attribute;
> > thr = attr_thr.threshold;
> >
>
Re: pass M_CANFAIL to malloc() which use M_WAITOK but are tested for failure
On Wed, Apr 26, 2023 at 08:19:10PM +0200, Alexander Bluhm wrote:
>
> On Sat, Apr 15, 2023 at 10:44:15PM +0800, Kevin Lo wrote:
> > On Fri, Apr 14, 2023 at 02:01:29PM +0200, Alexander Bluhm wrote:
> > > I think you are trying to change the kernel in the wrong direction.
> > > It should not fail, but handle the requests. Panic if there is a
> > > bug.
> > >
> > > Why do you think M_CANFAIL is a good thing at this place?
> >
> > Because M_WAITOK will not return NULl, I think adding M_CANFAIL will
> > keep the mallocarray call unchanged.
>
> The goal is not to handle errors by failing, but to prevent them.
> Better keep M_WAITOK, avoid M_CANFAIL, and remove the check.
>
> Discussion in the hackroom concluded that M_CANFAIL is for input
> from userland that can be unlimited large. If userland requests
> too much, it can fail. But it is not for normal operation of the
> kernel.
>
> M_NOWAIT should be used when the kernel has a good way to deal with
> a temporary failure, e.g. drop the packet.
>
> M_CANFAIL | M_WAITOK deals with user input that cannot be fullfilled
> permanently and should be reported as an error.
>
> M_WAITOK is for all other cases. If it panics, fix the underlying
> bug that requested unrealistic memory size.
>
> Here use number of queues which should be reasonable low and limited
> by the driver code. Keep M_WAITOK and remove the error check.
Thank you for discussing this topic at the hackathon, and I also greatly
appreciate your detailed explanation.
> By the way, M_DEVBUF is also wrong. It should be M_TEMP as it is
> freed in the same function and not stored permanently. But I wont
> fix that now as malloc(9) type usage is far from consistent.
>
> ok?
ok kevlo@
> bluhm
>
> Index: dev/pci/if_igc.c
> ===
> RCS file: /data/mirror/openbsd/cvs/src/sys/dev/pci/if_igc.c,v
> retrieving revision 1.12
> diff -u -p -r1.12 if_igc.c
> --- dev/pci/if_igc.c 9 Mar 2023 00:13:47 - 1.12
> +++ dev/pci/if_igc.c 21 Apr 2023 18:25:35 -
> @@ -1209,9 +1209,8 @@ igc_rxrinfo(struct igc_softc *sc, struct
> struct rx_ring *rxr;
> int error, i, n = 0;
>
> - if ((ifr = mallocarray(sc->sc_nqueues, sizeof(*ifr), M_DEVBUF,
> - M_WAITOK | M_ZERO)) == NULL)
> - return ENOMEM;
> + ifr = mallocarray(sc->sc_nqueues, sizeof(*ifr), M_DEVBUF,
> + M_WAITOK | M_ZERO);
>
> for (i = 0; i < sc->sc_nqueues; i++) {
> rxr = >rx_rings[i];
> Index: dev/pci/if_ix.c
> ===
> RCS file: /data/mirror/openbsd/cvs/src/sys/dev/pci/if_ix.c,v
> retrieving revision 1.192
> diff -u -p -r1.192 if_ix.c
> --- dev/pci/if_ix.c 6 Feb 2023 20:27:44 - 1.192
> +++ dev/pci/if_ix.c 21 Apr 2023 18:25:35 -
> @@ -640,9 +640,8 @@ ixgbe_rxrinfo(struct ix_softc *sc, struc
> u_int n = 0;
>
> if (sc->num_queues > 1) {
> - if ((ifr = mallocarray(sc->num_queues, sizeof(*ifr), M_DEVBUF,
> - M_WAITOK | M_ZERO)) == NULL)
> - return (ENOMEM);
> + ifr = mallocarray(sc->num_queues, sizeof(*ifr), M_DEVBUF,
> + M_WAITOK | M_ZERO);
> } else
> ifr =
>
> Index: dev/pci/if_oce.c
> ===
> RCS file: /data/mirror/openbsd/cvs/src/sys/dev/pci/if_oce.c,v
> retrieving revision 1.106
> diff -u -p -r1.106 if_oce.c
> --- dev/pci/if_oce.c 11 Mar 2022 18:00:48 - 1.106
> +++ dev/pci/if_oce.c 21 Apr 2023 18:25:35 -
> @@ -902,9 +902,8 @@ oce_rxrinfo(struct oce_softc *sc, struct
> u_int n = 0;
>
> if (sc->sc_nrq > 1) {
> - if ((ifr = mallocarray(sc->sc_nrq, sizeof(*ifr), M_DEVBUF,
> - M_WAITOK | M_ZERO)) == NULL)
> - return (ENOMEM);
> + ifr = mallocarray(sc->sc_nrq, sizeof(*ifr), M_DEVBUF,
> + M_WAITOK | M_ZERO);
> } else
> ifr =
>
>
Re: pass M_CANFAIL to malloc() which use M_WAITOK but are tested for failure
On Fri, Apr 14, 2023 at 02:01:29PM +0200, Alexander Bluhm wrote: > > On Thu, Apr 13, 2023 at 10:43:30AM +0800, Kevin Lo wrote: > > M_CANFAIL > > In the M_WAITOK case, if not enough memory is available, > > return NULL instead of calling panic(9). If mallocarray() > > Did you see such a panic? If yes it would be better to understand > and fix the root cause. No, I didn't see that. > > detects an overflow or malloc() detects an excessive > > allocation, return NULL instead of calling panic(9). > > > > > > I'd like to keep the mallocarray call unchanged so I add M_CANFAIL > > to the flags. > > I think you are trying to change the kernel in the wrong direction. > It should not fail, but handle the requests. Panic if there is a > bug. > > Why do you think M_CANFAIL is a good thing at this place? Because M_WAITOK will not return NULl, I think adding M_CANFAIL will keep the mallocarray call unchanged. > bluhm >
Re: em(4) multiqueue
On Thu, Apr 13, 2023 at 01:30:36PM -0500, Brian Conway wrote: > > Reviving this thread, apologies for discontinuity in mail readers: > https://marc.info/?t=16564219358 > > After rebasing on 7.3, my results have mirrored Hrvoje's testing at the end > of that thread. No issues with throughput, unusual latency, or reliability. > `vmstat -i` shows some level of balancing between the queues. I've been > testing on as many em(4) systems as I have access to, some manually, some in > a packet forwarder/firewall scenarios: > > em0 at pci1 dev 0 function 0 "Intel I210" rev 0x03, msix, 2 queues, address > 00:f1:f3:... > em1 at pci2 dev 0 function 0 "Intel I210" rev 0x03, msix, 2 queues, address > 00:f1:f3:... > em2 at pci3 dev 0 function 0 "Intel I210" rev 0x03, msix, 2 queues, address > 00:f1:f3:... > em3 at pci4 dev 0 function 0 "Intel I210" rev 0x03, msix, 2 queues, address > 00:f1:f3:... > em4 at pci5 dev 0 function 0 "Intel I210" rev 0x03, msix, 2 queues, address > 00:f1:f3:... > em5 at pci6 dev 0 function 0 "Intel I210" rev 0x03, msix, 2 queues, address > 00:f1:f3:... > > em0 at pci1 dev 0 function 0 "Intel I210" rev 0x03, msix, 4 queues, address > 00:0d:b9:... > em1 at pci2 dev 0 function 0 "Intel I210" rev 0x03, msix, 4 queues, address > 00:0d:b9:... > em2 at pci3 dev 0 function 0 "Intel I210" rev 0x03, msix, 4 queues, address > 00:0d:b9:... > > em0 at pci1 dev 0 function 0 "Intel I211" rev 0x03, msix, 2 queues, address > 00:0d:b9:... > em1 at pci2 dev 0 function 0 "Intel I211" rev 0x03, msix, 2 queues, address > 00:0d:b9:... > em2 at pci3 dev 0 function 0 "Intel I211" rev 0x03, msix, 2 queues, address > 00:0d:b9:... Last time I tested (about a year go) on I211, rx locked up if I tried something like iperf3 or tcpbench. Don't know if you have a similar problem. > em0 at pci1 dev 0 function 0 "Intel 82574L" rev 0x00: msi, address > 68:05:ca:... > > The only questions I have are around queue identification. All the specs I've > been able to find indicate the I210 should have 4 queues, did Intel make a > cheaper version with 2 toward the end of production? Or could it be an I211 > masquerading as an I210 (and would that be bad for the driver)? > > Also, > https://www.mouser.com/pdfdocs/Intel_82574L_82574IT_GbE_Controller_brief.pdf > indicates that the 82574L should have 2 queues? > > Anyway, great work, please let me know if there's more I can do to help this > move forward. > > Brian Conway > Lead Software Engineer, Owner > RCE Software, LLC >
Re: pass M_CANFAIL to malloc() which use M_WAITOK but are tested for failure
On Thu, Apr 06, 2023 at 02:09:23PM +0200, Alexander Bluhm wrote:
>
> On Thu, Apr 06, 2023 at 02:58:56PM +0800, Kevin Lo wrote:
> > The diff below adds M_CANFAIL to the flag passed to malloc() since we are
> > able
> > to fail gracefully.
>
> I would not call a return ENOMEM a gracefull fail.
>
> Usually if we can wait with M_WAITOK and everyting is fine afterwards,
> that's a good solution. Dealing with ENOMEM in upper layer is
> harder. Someone has to retry or decide what to do.
>
> What problem do you want to fix?
>
> If the currently dead code, as the if is never taken, is your
> concern, just remove the if () return ENOMEM.
Sorry I may not have explained it clearly earlier.
The mallocarray(9) says:
M_CANFAIL
In the M_WAITOK case, if not enough memory is available,
return NULL instead of calling panic(9). If mallocarray()
detects an overflow or malloc() detects an excessive
allocation, return NULL instead of calling panic(9).
I'd like to keep the mallocarray call unchanged so I add M_CANFAIL
to the flags.
> > ok?
> >
> > Index: sys/dev/pci/if_igc.c
> > ===
> > RCS file: /cvs/src/sys/dev/pci/if_igc.c,v
> > retrieving revision 1.12
> > diff -u -p -u -p -r1.12 if_igc.c
> > --- sys/dev/pci/if_igc.c9 Mar 2023 00:13:47 - 1.12
> > +++ sys/dev/pci/if_igc.c6 Apr 2023 06:50:43 -
> > @@ -1210,7 +1210,7 @@ igc_rxrinfo(struct igc_softc *sc, struct
> > int error, i, n = 0;
> >
> > if ((ifr = mallocarray(sc->sc_nqueues, sizeof(*ifr), M_DEVBUF,
> > - M_WAITOK | M_ZERO)) == NULL)
> > + M_WAITOK | M_CANFAIL | M_ZERO)) == NULL)
> > return ENOMEM;
> >
> > for (i = 0; i < sc->sc_nqueues; i++) {
> > Index: sys/dev/pci/if_ix.c
> > ===
> > RCS file: /cvs/src/sys/dev/pci/if_ix.c,v
> > retrieving revision 1.192
> > diff -u -p -u -p -r1.192 if_ix.c
> > --- sys/dev/pci/if_ix.c 6 Feb 2023 20:27:44 - 1.192
> > +++ sys/dev/pci/if_ix.c 6 Apr 2023 06:50:44 -
> > @@ -641,7 +641,7 @@ ixgbe_rxrinfo(struct ix_softc *sc, struc
> >
> > if (sc->num_queues > 1) {
> > if ((ifr = mallocarray(sc->num_queues, sizeof(*ifr), M_DEVBUF,
> > - M_WAITOK | M_ZERO)) == NULL)
> > + M_WAITOK | M_CANFAIL | M_ZERO)) == NULL)
> > return (ENOMEM);
> > } else
> > ifr =
> > Index: sys/dev/pci/if_oce.c
> > ===
> > RCS file: /cvs/src/sys/dev/pci/if_oce.c,v
> > retrieving revision 1.106
> > diff -u -p -u -p -r1.106 if_oce.c
> > --- sys/dev/pci/if_oce.c11 Mar 2022 18:00:48 - 1.106
> > +++ sys/dev/pci/if_oce.c6 Apr 2023 06:50:44 -
> > @@ -903,7 +903,7 @@ oce_rxrinfo(struct oce_softc *sc, struct
> >
> > if (sc->sc_nrq > 1) {
> > if ((ifr = mallocarray(sc->sc_nrq, sizeof(*ifr), M_DEVBUF,
> > - M_WAITOK | M_ZERO)) == NULL)
> > + M_WAITOK | M_CANFAIL | M_ZERO)) == NULL)
> > return (ENOMEM);
> > } else
> > ifr =
>
pass M_CANFAIL to malloc() which use M_WAITOK but are tested for failure
Hi,
The diff below adds M_CANFAIL to the flag passed to malloc() since we are able
to fail gracefully.
ok?
Index: sys/dev/pci/if_igc.c
===
RCS file: /cvs/src/sys/dev/pci/if_igc.c,v
retrieving revision 1.12
diff -u -p -u -p -r1.12 if_igc.c
--- sys/dev/pci/if_igc.c9 Mar 2023 00:13:47 - 1.12
+++ sys/dev/pci/if_igc.c6 Apr 2023 06:50:43 -
@@ -1210,7 +1210,7 @@ igc_rxrinfo(struct igc_softc *sc, struct
int error, i, n = 0;
if ((ifr = mallocarray(sc->sc_nqueues, sizeof(*ifr), M_DEVBUF,
- M_WAITOK | M_ZERO)) == NULL)
+ M_WAITOK | M_CANFAIL | M_ZERO)) == NULL)
return ENOMEM;
for (i = 0; i < sc->sc_nqueues; i++) {
Index: sys/dev/pci/if_ix.c
===
RCS file: /cvs/src/sys/dev/pci/if_ix.c,v
retrieving revision 1.192
diff -u -p -u -p -r1.192 if_ix.c
--- sys/dev/pci/if_ix.c 6 Feb 2023 20:27:44 - 1.192
+++ sys/dev/pci/if_ix.c 6 Apr 2023 06:50:44 -
@@ -641,7 +641,7 @@ ixgbe_rxrinfo(struct ix_softc *sc, struc
if (sc->num_queues > 1) {
if ((ifr = mallocarray(sc->num_queues, sizeof(*ifr), M_DEVBUF,
- M_WAITOK | M_ZERO)) == NULL)
+ M_WAITOK | M_CANFAIL | M_ZERO)) == NULL)
return (ENOMEM);
} else
ifr =
Index: sys/dev/pci/if_oce.c
===
RCS file: /cvs/src/sys/dev/pci/if_oce.c,v
retrieving revision 1.106
diff -u -p -u -p -r1.106 if_oce.c
--- sys/dev/pci/if_oce.c11 Mar 2022 18:00:48 - 1.106
+++ sys/dev/pci/if_oce.c6 Apr 2023 06:50:44 -
@@ -903,7 +903,7 @@ oce_rxrinfo(struct oce_softc *sc, struct
if (sc->sc_nrq > 1) {
if ((ifr = mallocarray(sc->sc_nrq, sizeof(*ifr), M_DEVBUF,
- M_WAITOK | M_ZERO)) == NULL)
+ M_WAITOK | M_CANFAIL | M_ZERO)) == NULL)
return (ENOMEM);
} else
ifr =
Re: better support for Quectel EC25
On Fri, Mar 31, 2023 at 06:28:14PM +1000, David Gwynne wrote:
>
> i got a quectel ec25 to play with recently, and got side tracked
> thinking the usb controller was not talking to the modem correctly
> because when it attached it looked like this:
>
> umb0 at uhub2 port 1 "Android Android" rev 2.00/3.18 addr
> umb0: missing MBIM descriptor
>
> and the usb descriptors looked weird. i thought clocking or power
> or something was wrong. turns out that the host controller is fine,
> but the devices are complicated because they're based on the qualcomm
> qmi stuff, and in a lot of cases openbsd could do a better job of
> talking to them.
When I added support for ec25, I had already set it to mbim mode on Linux.
Because I didn't want to use any other mode (ppp & qmi, ecm), I didn't notice
the error message that would appear if it was in qmi mode.
It wasn't until dlg@ brought up this issue that I became aware of its existence.
> fortunately quectel seem to do a better job than a lot of other vendors
> usign the qmi stuff and try to make all their products support a common
> set of features. their linux driver guide is also very good, and is very
> clear about what to expect on these devices. basically, these modems
> are supposed to present a bunch of umsm interfaces, and at least
> one network interface. the usb network interface type can be changed by
> talking to the umsm interfaces, and could be qmi, ecm, or mbim.
>
> openbsd is currently hardcoded to attach umb(4) to these devices, and it
> will attach only umb at the device level. this means that the usms
> interfaces are hidden, and if the device is not in mbim mode then umb
> complains that the descriptors dont look right. which is fair.
>
> this diff tweaks the umsm and umb matches to follow the quectel doco.
> this allos umsm to attach to the correct interfaces, but leaves the
> network interface alone. this allows umb to attach to the network
> interface if the modem is configured in mbim mode based on class,
> otherwise ugen gets to attach to it. if we ever get qmi or ecm drivers,
> this will allow them to attach instead of ugen.
>
> eg, with these diffs and when the modem is in qmi mode:
>
> umsm0 at uhub2 port 1 configuration 1 interface 0 "Android Android" rev
> 2.00/3.18 addr 2
> ucom0 at umsm0
> umsm1 at uhub2 port 1 configuration 1 interface 1 "Android Android" rev
> 2.00/3.18 addr 2
> ucom1 at umsm1
> umsm2 at uhub2 port 1 configuration 1 interface 2 "Android Android" rev
> 2.00/3.18 addr 2
> ucom2 at umsm2
> umsm3 at uhub2 port 1 configuration 1 interface 3 "Android Android" rev
> 2.00/3.18 addr 2
> ucom3 at umsm3
> ugen0 at uhub2 port 1 configuration 1 "Android Android" rev 2.00/3.18 addr 2
>
> now that umsm is exposed i can tell it to expose mbim instead. next time
> it attaches i see this:
>
> umsm0 at uhub2 port 1 configuration 1 interface 0 "Android Android" rev
> 2.00/3.18 addr 2
> ucom0 at umsm0
> umsm1 at uhub2 port 1 configuration 1 interface 1 "Android Android" rev
> 2.00/3.18 addr 2
> ucom1 at umsm1
> umsm2 at uhub2 port 1 configuration 1 interface 2 "Android Android" rev
> 2.00/3.18 addr 2
> ucom2 at umsm2
> umsm3 at uhub2 port 1 configuration 1 interface 3 "Android Android" rev
> 2.00/3.18 addr 2
> ucom3 at umsm3
> umb0 at uhub2 port 1 configuration 1 interface 4 "Android Android" rev
> 2.00/3.18 addr 2
>
> and umb0 shows up in ifconfig and lets me configure an apn and stuff.
>
> thanks to kevlo for helping me out and testing.
>
> a follow up diff could (should) add the rest of the quectel usbids
> listed in their doco.
>
> the umsm chunk looks big because i made it return early if there's no
> umsm_lookup value, which lets me reduce the indentation of most of the
> code.
>
> ok?
With this patch, I'm able to send AT commands to ec25 modem without the
umsm attachments.
ok kevlo@, thanks!
> Index: if_umb.c
> ===
> RCS file: /cvs/src/sys/dev/usb/if_umb.c,v
> retrieving revision 1.49
> diff -u -p -r1.49 if_umb.c
> --- if_umb.c 11 Jan 2022 10:34:13 - 1.49
> +++ if_umb.c 31 Mar 2023 08:27:04 -
> @@ -238,13 +238,6 @@ const struct umb_quirk umb_quirks[] = {
> UMATCH_VENDOR_PRODUCT
> },
>
> - { { USB_VENDOR_QUECTEL, USB_PRODUCT_QUECTEL_EC25 },
> - 0,
> - 1,
> - UMATCH_VENDOR_PRODUCT
> - },
> -
> -
> { { USB_VENDOR_HUAWEI, USB_PRODUCT_HUAWEI_ME906S },
> UMBFLG_NDP_AT_END,
> 3,
> Index: umsm.c
> ===
> RCS file: /cvs/src/sys/dev/usb/umsm.c,v
> retrieving revision 1.122
> diff -u -p -r1.122 umsm.c
> --- umsm.c23 Aug 2022 08:12:30 - 1.122
> +++ umsm.c31 Mar 2023 08:27:04 -
> @@ -293,53 +293,66 @@ int
> umsm_match(struct device *parent, void *match, void *aux)
> {
> struct usb_attach_arg *uaa = aux;
> + const struct umsm_type *umsmt;
> usb_interface_descriptor_t *id;
>
txphy: update comment: RTL8139 -> TNETE2101
ok?
Index: sys/dev/mii/txphy.c
===
RCS file: /cvs/src/sys/dev/mii/txphy.c,v
retrieving revision 1.12
diff -u -p -u -p -r1.12 txphy.c
--- sys/dev/mii/txphy.c 6 Apr 2022 18:59:29 - 1.12
+++ sys/dev/mii/txphy.c 29 Mar 2023 08:05:27 -
@@ -114,7 +114,7 @@ txphy_service(struct mii_softc *sc, stru
return (ENXIO);
/*
-* Can't isolate the RTL8139 phy, so it has to be the only one.
+* Can't isolate the TNETE2101 phy, so it has to be the only one.
*/
if (IFM_INST(ife->ifm_media) != sc->mii_inst)
panic("txphy_service: attempt to isolate phy");
Add ASMedia ASM2142 xhci
Hi, I have a machine with the ASMedia USB 3.1 controller: xhci1 at pci3 dev 0 function 0 vendor "ASMedia", unknown product 0x2142 rev 0x00: msi, xHCI 1.10 ok? Index: sys/dev/pci/pcidevs === RCS file: /cvs/src/sys/dev/pci/pcidevs,v retrieving revision 1.2020 diff -u -p -u -p -r1.2020 pcidevs --- sys/dev/pci/pcidevs 5 Feb 2023 01:57:59 - 1.2020 +++ sys/dev/pci/pcidevs 7 Feb 2023 06:27:00 - @@ -1185,6 +1185,7 @@ product ASMEDIA ASM1182E 0x1182 ASM1182e product ASMEDIA ASM1184E 0x1184 ASM1184e product ASMEDIA ASM1042AE 0x1242 ASM1042AE xHCI product ASMEDIA ASM11430x1343 ASM1143 xHCI +product ASMEDIA ASM21420x2142 ASM2142 xHCI product ASMEDIA ASM28240x2824 ASM2824 /* ASPEED Technology products */
Re: igc(4) remove unnecessary PHY ID checks
On Wed, Jan 25, 2023 at 03:17:48PM +0100, Moritz Buhl wrote:
>
> Dear tech,
>
> Looking into various reports on errors with mini routers that use
> igc(4), I found the following diff in FreeBSD:
> https://github.com/freebsd/freebsd-src/commit/29d7f1ff579579711dd5a3325480728b8ed45f8c
>
> I additionally deleted the igc_set_d0_lplu_state_i225 and
> igc_set_d3_lplu_state_i225 functions since they are no longer used.
>
> I am not convinced that this diff really fixes any of the issues,
> however I do appreciate feedback.
I225 devices do have only one phy vendor, Linux also removes PHY ID checking:
https://github.com/torvalds/linux/commit/7c496de538eebd8212dc2a3c9a468386b264d0d4
> Ok?
ok kevlo@
> mbuhl
>
> Index: dev/pci/igc_i225.c
> ===
> RCS file: /cvs/src/sys/dev/pci/igc_i225.c,v
> retrieving revision 1.3
> diff -u -p -r1.3 igc_i225.c
> --- dev/pci/igc_i225.c11 May 2022 06:14:15 - 1.3
> +++ dev/pci/igc_i225.c10 Jan 2023 09:26:04 -
> @@ -163,16 +163,7 @@ igc_init_phy_params_i225(struct igc_hw *
> goto out;
>
> ret_val = igc_get_phy_id(hw);
> - /* Verify phy id and set remaining function pointers */
> - switch (phy->id) {
> - case I225_I_PHY_ID:
> - default:
> - phy->type = igc_phy_i225;
> - phy->ops.set_d0_lplu_state = igc_set_d0_lplu_state_i225;
> - phy->ops.set_d3_lplu_state = igc_set_d3_lplu_state_i225;
> - /* TODO - complete with GPY PHY information */
> - break;
> - }
> + phy->type = igc_phy_i225;
>
> out:
> return ret_val;
> @@ -1104,66 +1095,6 @@ igc_init_hw_i225(struct igc_hw *hw)
>
> ret_val = igc_init_hw_base(hw);
> return ret_val;
> -}
> -
> -/*
> - * igc_set_d0_lplu_state_i225 - Set Low-Power-Link-Up (LPLU) D0 state
> - * @hw: pointer to the HW structure
> - * @active: true to enable LPLU, false to disable
> - *
> - * Note: since I225 does not actually support LPLU, this function
> - * simply enables/disables 1G and 2.5G speeds in D0.
> - */
> -int
> -igc_set_d0_lplu_state_i225(struct igc_hw *hw, bool active)
> -{
> - uint32_t data;
> -
> - DEBUGFUNC("igc_set_d0_lplu_state_i225");
> -
> - data = IGC_READ_REG(hw, IGC_I225_PHPM);
> -
> - if (active) {
> - data |= IGC_I225_PHPM_DIS_1000;
> - data |= IGC_I225_PHPM_DIS_2500;
> - } else {
> - data &= ~IGC_I225_PHPM_DIS_1000;
> - data &= ~IGC_I225_PHPM_DIS_2500;
> - }
> -
> - IGC_WRITE_REG(hw, IGC_I225_PHPM, data);
> - return IGC_SUCCESS;
> -}
> -
> -/*
> - * igc_set_d3_lplu_state_i225 - Set Low-Power-Link-Up (LPLU) D3 state
> - * @hw: pointer to the HW structure
> - * @active: true to enable LPLU, false to disable
> - *
> - * Note: since I225 does not actually support LPLU, this function
> - * simply enables/disables 100M, 1G and 2.5G speeds in D3.
> - */
> -int
> -igc_set_d3_lplu_state_i225(struct igc_hw *hw, bool active)
> -{
> - uint32_t data;
> -
> - DEBUGFUNC("igc_set_d3_lplu_state_i225");
> -
> - data = IGC_READ_REG(hw, IGC_I225_PHPM);
> -
> - if (active) {
> - data |= IGC_I225_PHPM_DIS_100_D3;
> - data |= IGC_I225_PHPM_DIS_1000_D3;
> - data |= IGC_I225_PHPM_DIS_2500_D3;
> - } else {
> - data &= ~IGC_I225_PHPM_DIS_100_D3;
> - data &= ~IGC_I225_PHPM_DIS_1000_D3;
> - data &= ~IGC_I225_PHPM_DIS_2500_D3;
> - }
> -
> - IGC_WRITE_REG(hw, IGC_I225_PHPM, data);
> - return IGC_SUCCESS;
> }
>
> /**
> Index: dev/pci/igc_i225.h
> ===
> RCS file: /cvs/src/sys/dev/pci/igc_i225.h,v
> retrieving revision 1.1
> diff -u -p -r1.1 igc_i225.h
> --- dev/pci/igc_i225.h31 Oct 2021 14:52:57 - 1.1
> +++ dev/pci/igc_i225.h10 Jan 2023 09:37:40 -
> @@ -27,8 +27,6 @@ voidigc_release_swfw_sync_i225(struct i
> int igc_set_ltr_i225(struct igc_hw *, bool);
> int igc_init_hw_i225(struct igc_hw *);
> int igc_setup_copper_link_i225(struct igc_hw *);
> -int igc_set_d0_lplu_state_i225(struct igc_hw *, bool);
> -int igc_set_d3_lplu_state_i225(struct igc_hw *, bool);
> int igc_set_eee_i225(struct igc_hw *, bool, bool, bool);
>
> #define ID_LED_DEFAULT_I225 \
> Index: dev/pci/igc_phy.c
> ===
> RCS file: /cvs/src/sys/dev/pci/igc_phy.c,v
> retrieving revision 1.2
> diff -u -p -r1.2 igc_phy.c
> --- dev/pci/igc_phy.c 11 May 2022 06:14:15 - 1.2
> +++ dev/pci/igc_phy.c 10 Jan 2023 09:34:11 -
> @@ -307,8 +307,7 @@ igc_phy_setup_autoneg(struct igc_hw *hw)
> return ret_val;
> }
>
> - if ((phy->autoneg_mask & ADVERTISE_2500_FULL) &&
> - hw->phy.id == I225_I_PHY_ID) {
> + if (phy->autoneg_mask & ADVERTISE_2500_FULL)
Supprt FTDI FT232R
The diff below makes the serial interface of the Genio 1200 demo board (FT232R)
work. The upper 2 bits encode the fractional component of the FT232R is either
0 or 0.125.
uftdi0 at uhub0 port 3 configuration 1 interface 0 "FTDI FT232R USB UART" rev
2.00/6.00 addr 2
ucom0 at uftdi0 portno 1
Tested with cu.
ok?
Index: sys/dev/usb/uftdi.c
===
RCS file: /cvs/src/sys/dev/usb/uftdi.c,v
retrieving revision 1.77
diff -u -p -u -p -r1.77 uftdi.c
--- sys/dev/usb/uftdi.c 9 Apr 2022 20:07:44 - 1.77
+++ sys/dev/usb/uftdi.c 29 Dec 2022 06:40:32 -
@@ -97,7 +97,7 @@ void uftdi_read(void *sc, int portno, u_
void uftdi_write(void *sc, int portno, u_char *to, u_char *from,
u_int32_t *count);
void uftdi_break(void *sc, int portno, int onoff);
-intuftdi_8u232am_getrate(speed_t speed, int *rate);
+intuftdi_8u232am_getrate(struct uftdi_softc *sc, speed_t speed, int *rate);
intuftdi_2232h_getrate(speed_t speed, int *rate);
const struct ucom_methods uftdi_methods = {
@@ -772,6 +772,9 @@ uftdi_attach(struct device *parent, stru
if (uaa->release < 0x0200) {
sc->sc_type = UFTDI_TYPE_SIO;
sc->sc_hdrlen = 1;
+ } else if (uaa->release == 0x0600) {
+ sc->sc_type = UFTDI_TYPE_232R;
+ sc->sc_hdrlen = 0;
} else if (uaa->release == 0x0700 || uaa->release == 0x0800) {
sc->sc_type = UFTDI_TYPE_2232H;
sc->sc_hdrlen = 0;
@@ -1011,8 +1014,9 @@ uftdi_param(void *vsc, int portno, struc
}
break;
+ case UFTDI_TYPE_232R:
case UFTDI_TYPE_8U232AM:
- if (uftdi_8u232am_getrate(t->c_ospeed, ) == -1)
+ if (uftdi_8u232am_getrate(sc, t->c_ospeed, ) == -1)
return (EINVAL);
break;
case UFTDI_TYPE_2232H:
@@ -1131,7 +1135,7 @@ uftdi_break(void *vsc, int portno, int o
}
int
-uftdi_8u232am_getrate(speed_t speed, int *rate)
+uftdi_8u232am_getrate(struct uftdi_softc *sc, speed_t speed, int *rate)
{
/* Table of the nearest even powers-of-2 for values 0..15. */
static const unsigned char roundoff[16] = {
@@ -1182,11 +1186,13 @@ uftdi_8u232am_getrate(speed_t speed, int
* 0.125.
*/
result = d >> 4;
- if (d & 8)
- result |= 0x4000;
- else if (d & 4)
- result |= 0x8000;
- else if (d & 2)
+ if (sc->sc_type == UFTDI_TYPE_8U232AM) {
+ if (d & 8)
+ result |= 0x4000;
+ else if (d & 4)
+ result |= 0x8000;
+ }
+ if (d & 2)
result |= 0xc000;
done:
Index: sys/dev/usb/uftdireg.h
===
RCS file: /cvs/src/sys/dev/usb/uftdireg.h,v
retrieving revision 1.13
diff -u -p -u -p -r1.13 uftdireg.h
--- sys/dev/usb/uftdireg.h 11 Sep 2012 16:04:44 - 1.13
+++ sys/dev/usb/uftdireg.h 29 Dec 2022 06:40:32 -
@@ -36,7 +36,8 @@
enum uftdi_type {
UFTDI_TYPE_SIO,
UFTDI_TYPE_8U232AM,
- UFTDI_TYPE_2232H
+ UFTDI_TYPE_2232H,
+ UFTDI_TYPE_232R
};
/*
Re: is this rge crash known? - fixed
On Tue, Dec 20, 2022 at 01:02:23AM -0500, Geoff Steckel wrote:
>
> On 12/19/22 21:07, Kevin Lo wrote:
> > On Mon, Dec 19, 2022 at 03:50:45PM -0500, Geoff Steckel wrote:
> > > Thanks for all the suggestions:
> > >
> > > sysctl kern.pool_debug=1 = no change
> > > known working board in same slot = no change
> > >
> > > hardware version is indeed 0609
> > > em(4) in same slot = works
> > > test using old rge(4) board between two Linux systems = works
> > >
> > > Are any other drivers similar enough for me to compare with if_rge.c?
> > > Perhaps the AMD 5600G or the B550 chipset have quirks not seen before?
> > >
> > > I could possibly install FreeBSD if that would give any information.
> > The diff below syncs up the Rx descriptor setup code to the upstream.
> > It should fix the problem.
> >
> > Index: sys/dev/pci/if_rge.c
> > ===
> > RCS file: /cvs/src/sys/dev/pci/if_rge.c,v
> > retrieving revision 1.20
> > diff -u -p -u -p -r1.20 if_rge.c
> > --- sys/dev/pci/if_rge.c20 Nov 2022 23:47:51 - 1.20
> > +++ sys/dev/pci/if_rge.c20 Dec 2022 01:54:30 -
> > @@ -1104,24 +1104,16 @@ rge_newbuf(struct rge_queues *q)
> > /* Map the segments into RX descriptors. */
> > r = >q_rx.rge_rx_list[idx];
> > - if (RGE_OWN(r)) {
> > - printf("%s: tried to map busy RX descriptor\n",
> > - sc->sc_dev.dv_xname);
> > - m_freem(m);
> > - return (ENOBUFS);
> > - }
> > -
> > rxq->rxq_mbuf = m;
> > - r->rge_extsts = 0;
> > - r->rge_addrlo = htole32(RGE_ADDR_LO(rxmap->dm_segs[0].ds_addr));
> > - r->rge_addrhi = htole32(RGE_ADDR_HI(rxmap->dm_segs[0].ds_addr));
> > + r->hi_qword1.rx_qword4.rge_extsts = 0;
> > + r->hi_qword0.rge_addr = htole64(rxmap->dm_segs[0].ds_addr);
> > - r->rge_cmdsts = htole32(rxmap->dm_segs[0].ds_len);
> > + r->hi_qword1.rx_qword4.rge_cmdsts = htole32(rxmap->dm_segs[0].ds_len);
> > if (idx == RGE_RX_LIST_CNT - 1)
> > - r->rge_cmdsts |= htole32(RGE_RDCMDSTS_EOR);
> > + r->hi_qword1.rx_qword4.rge_cmdsts |= htole32(RGE_RDCMDSTS_EOR);
> > - r->rge_cmdsts |= htole32(RGE_RDCMDSTS_OWN);
> > + r->hi_qword1.rx_qword4.rge_cmdsts |= htole32(RGE_RDCMDSTS_OWN);
> > bus_dmamap_sync(sc->sc_dmat, q->q_rx.rge_rx_list_map,
> > idx * sizeof(struct rge_rx_desc), sizeof(struct rge_rx_desc),
> > @@ -1140,11 +1132,11 @@ rge_discard_rxbuf(struct rge_queues *q,
> > r = >q_rx.rge_rx_list[idx];
> > - r->rge_cmdsts = htole32(RGE_JUMBO_FRAMELEN);
> > - r->rge_extsts = 0;
> > + r->hi_qword1.rx_qword4.rge_cmdsts = htole32(RGE_JUMBO_FRAMELEN);
> > + r->hi_qword1.rx_qword4.rge_extsts = 0;
> > if (idx == RGE_RX_LIST_CNT - 1)
> > - r->rge_cmdsts |= htole32(RGE_RDCMDSTS_EOR);
> > - r->rge_cmdsts |= htole32(RGE_RDCMDSTS_OWN);
> > + r->hi_qword1.rx_qword4.rge_cmdsts |= htole32(RGE_RDCMDSTS_EOR);
> > + r->hi_qword1.rx_qword4.rge_cmdsts |= htole32(RGE_RDCMDSTS_OWN);
> > bus_dmamap_sync(sc->sc_dmat, q->q_rx.rge_rx_list_map,
> > idx * sizeof(struct rge_rx_desc), sizeof(struct rge_rx_desc),
> > @@ -1219,8 +1211,8 @@ rge_rxeof(struct rge_queues *q)
> > if (RGE_OWN(cur_rx))
> > break;
> > - rxstat = letoh32(cur_rx->rge_cmdsts);
> > - extsts = letoh32(cur_rx->rge_extsts);
> > + rxstat = letoh32(cur_rx->hi_qword1.rx_qword4.rge_cmdsts);
> > + extsts = letoh32(cur_rx->hi_qword1.rx_qword4.rge_extsts);
> >
> > total_len = RGE_RXBYTES(cur_rx);
> > rxq = >q_rx.rge_rxq[i];
> > @@ -1282,16 +1274,16 @@ rge_rxeof(struct rge_queues *q)
> > (total_len - ETHER_CRC_LEN);
> > /* Check IP header checksum. */
> > - if (!(rxstat & RGE_RDCMDSTS_IPCSUMERR) &&
> > + if (!(extsts & RGE_RDEXTSTS_IPCSUMERR) &&
> > (extsts & RGE_RDEXTSTS_IPV4))
> > m->m_pkthdr.csum_flags |= M_IPV4_CSUM_IN_OK;
> > /* Check TCP/UDP checksum. */
> > if ((extsts & (RGE_RDEXTSTS_IPV4 | RGE_RDEXTSTS_IPV6)) &&
> > - (((rxstat & RGE_RDCMDSTS_TCPPKT) &&
> > - !(rxstat & RGE_RDCMDSTS_TCPCSUMERR))
Re: is this rge crash known? - test results
On Mon, Dec 19, 2022 at 03:50:45PM -0500, Geoff Steckel wrote:
>
> Thanks for all the suggestions:
>
> sysctl kern.pool_debug=1 = no change
> known working board in same slot = no change
>
> hardware version is indeed 0609
> em(4) in same slot = works
> test using old rge(4) board between two Linux systems = works
>
> Are any other drivers similar enough for me to compare with if_rge.c?
> Perhaps the AMD 5600G or the B550 chipset have quirks not seen before?
>
> I could possibly install FreeBSD if that would give any information.
The diff below syncs up the Rx descriptor setup code to the upstream.
It should fix the problem.
Index: sys/dev/pci/if_rge.c
===
RCS file: /cvs/src/sys/dev/pci/if_rge.c,v
retrieving revision 1.20
diff -u -p -u -p -r1.20 if_rge.c
--- sys/dev/pci/if_rge.c20 Nov 2022 23:47:51 - 1.20
+++ sys/dev/pci/if_rge.c20 Dec 2022 01:54:30 -
@@ -1104,24 +1104,16 @@ rge_newbuf(struct rge_queues *q)
/* Map the segments into RX descriptors. */
r = >q_rx.rge_rx_list[idx];
- if (RGE_OWN(r)) {
- printf("%s: tried to map busy RX descriptor\n",
- sc->sc_dev.dv_xname);
- m_freem(m);
- return (ENOBUFS);
- }
-
rxq->rxq_mbuf = m;
- r->rge_extsts = 0;
- r->rge_addrlo = htole32(RGE_ADDR_LO(rxmap->dm_segs[0].ds_addr));
- r->rge_addrhi = htole32(RGE_ADDR_HI(rxmap->dm_segs[0].ds_addr));
+ r->hi_qword1.rx_qword4.rge_extsts = 0;
+ r->hi_qword0.rge_addr = htole64(rxmap->dm_segs[0].ds_addr);
- r->rge_cmdsts = htole32(rxmap->dm_segs[0].ds_len);
+ r->hi_qword1.rx_qword4.rge_cmdsts = htole32(rxmap->dm_segs[0].ds_len);
if (idx == RGE_RX_LIST_CNT - 1)
- r->rge_cmdsts |= htole32(RGE_RDCMDSTS_EOR);
+ r->hi_qword1.rx_qword4.rge_cmdsts |= htole32(RGE_RDCMDSTS_EOR);
- r->rge_cmdsts |= htole32(RGE_RDCMDSTS_OWN);
+ r->hi_qword1.rx_qword4.rge_cmdsts |= htole32(RGE_RDCMDSTS_OWN);
bus_dmamap_sync(sc->sc_dmat, q->q_rx.rge_rx_list_map,
idx * sizeof(struct rge_rx_desc), sizeof(struct rge_rx_desc),
@@ -1140,11 +1132,11 @@ rge_discard_rxbuf(struct rge_queues *q,
r = >q_rx.rge_rx_list[idx];
- r->rge_cmdsts = htole32(RGE_JUMBO_FRAMELEN);
- r->rge_extsts = 0;
+ r->hi_qword1.rx_qword4.rge_cmdsts = htole32(RGE_JUMBO_FRAMELEN);
+ r->hi_qword1.rx_qword4.rge_extsts = 0;
if (idx == RGE_RX_LIST_CNT - 1)
- r->rge_cmdsts |= htole32(RGE_RDCMDSTS_EOR);
- r->rge_cmdsts |= htole32(RGE_RDCMDSTS_OWN);
+ r->hi_qword1.rx_qword4.rge_cmdsts |= htole32(RGE_RDCMDSTS_EOR);
+ r->hi_qword1.rx_qword4.rge_cmdsts |= htole32(RGE_RDCMDSTS_OWN);
bus_dmamap_sync(sc->sc_dmat, q->q_rx.rge_rx_list_map,
idx * sizeof(struct rge_rx_desc), sizeof(struct rge_rx_desc),
@@ -1219,8 +1211,8 @@ rge_rxeof(struct rge_queues *q)
if (RGE_OWN(cur_rx))
break;
- rxstat = letoh32(cur_rx->rge_cmdsts);
- extsts = letoh32(cur_rx->rge_extsts);
+ rxstat = letoh32(cur_rx->hi_qword1.rx_qword4.rge_cmdsts);
+ extsts = letoh32(cur_rx->hi_qword1.rx_qword4.rge_extsts);
total_len = RGE_RXBYTES(cur_rx);
rxq = >q_rx.rge_rxq[i];
@@ -1282,16 +1274,16 @@ rge_rxeof(struct rge_queues *q)
(total_len - ETHER_CRC_LEN);
/* Check IP header checksum. */
- if (!(rxstat & RGE_RDCMDSTS_IPCSUMERR) &&
+ if (!(extsts & RGE_RDEXTSTS_IPCSUMERR) &&
(extsts & RGE_RDEXTSTS_IPV4))
m->m_pkthdr.csum_flags |= M_IPV4_CSUM_IN_OK;
/* Check TCP/UDP checksum. */
if ((extsts & (RGE_RDEXTSTS_IPV4 | RGE_RDEXTSTS_IPV6)) &&
- (((rxstat & RGE_RDCMDSTS_TCPPKT) &&
- !(rxstat & RGE_RDCMDSTS_TCPCSUMERR)) ||
- ((rxstat & RGE_RDCMDSTS_UDPPKT) &&
- !(rxstat & RGE_RDCMDSTS_UDPCSUMERR
+ (((extsts & RGE_RDEXTSTS_TCPPKT) &&
+ !(extsts & RGE_RDEXTSTS_TCPCSUMERR)) ||
+ ((extsts & RGE_RDEXTSTS_UDPPKT) &&
+ !(extsts & RGE_RDEXTSTS_UDPCSUMERR
m->m_pkthdr.csum_flags |= M_TCP_CSUM_IN_OK |
M_UDP_CSUM_IN_OK;
Index: sys/dev/pci/if_rgereg.h
===
RCS file: /cvs/src/sys/dev/pci/if_rgereg.h,v
retrieving revision 1.8
diff -u -p -u -p -r1.8 if_rgereg.h
--- sys/dev/pci/if_rgereg.h 20 Nov 2022 23:47:51 - 1.8
+++ sys/dev/pci/if_rgereg.h 20 Dec 2022 01:54:30 -
@@ -189,9 +189,10 @@
#define RGE_NEXT_RX_DESC(x)(((x) + 1) % RGE_RX_LIST_CNT)
#define RGE_ADDR_LO(y)
Re: is this rge crash known?
On Sun, Dec 18, 2022 at 08:53:26PM -0500, Geoff Steckel wrote:
> nc of 0's from one rge to another at full speed crashes
> in the input interrupt path with corruption of the memory
> pool used for the mbufs
> It's 100% reproduceable.
> Probably race condition & use-after-free or some such
> since it takes 200,000+ packets to happen.
> I suspect that the crash happens when the corruption is detected
> some time after it actually occurs.
> This is a ---very--- abbreviated description.
> If this crash hasn't been seen before I'll submit a full bug report.
> Is there any more info from sysctls, ddb, etc. that would help?
> I can put in breakpoints & dump (small) memory areas.
> If running the most recent snapshot would give better info I can do that.
> A serial console to get an exact transcript is possible but not easy.
> Any suggestions of something I can do to help beyond a standard bug
> report welcomed. I can run test patches easily.
> This is with the standard 1500 mtu.
> Setting mtu to 8000 trashes memory enough to cause a kernel protection
> fault.
Could you use the following patch to show the hardware revision?
I guess yours is 0x6090, thanks.
--- sys/dev/pci/if_rge.c.orig Wed Nov 23 16:29:44 2022
+++ sys/dev/pci/if_rge.cMon Dec 19 21:50:21 2022
@@ -249,6 +249,7 @@
printf(": unknown version 0x%08x\n", hwrev);
return;
}
+ printf(", hwrev 0x%08x", hwrev);
rge_config_imtype(sc, RGE_IMTYPE_SIM);
Fix typo in debug messages
OK?
Index: sys/dev/pci/if_bge.c
===
RCS file: /cvs/src/sys/dev/pci/if_bge.c,v
retrieving revision 1.398
diff -u -p -u -p -r1.398 if_bge.c
--- sys/dev/pci/if_bge.c11 Mar 2022 18:00:45 - 1.398
+++ sys/dev/pci/if_bge.c8 Oct 2022 14:28:54 -
@@ -2961,14 +2961,14 @@ bge_attach(struct device *parent, struct
sizeof(struct bge_ring_data));
goto fail_3;
}
- DPRINTFN(5, ("bus_dmamem_create\n"));
+ DPRINTFN(5, ("bus_dmamap_create\n"));
if (bus_dmamap_create(sc->bge_dmatag, sizeof(struct bge_ring_data), 1,
sizeof(struct bge_ring_data), 0,
BUS_DMA_NOWAIT, >bge_ring_map)) {
printf(": can't create dma map\n");
goto fail_4;
}
- DPRINTFN(5, ("bus_dmamem_load\n"));
+ DPRINTFN(5, ("bus_dmamap_load\n"));
if (bus_dmamap_load(sc->bge_dmatag, sc->bge_ring_map, kva,
sizeof(struct bge_ring_data), NULL,
BUS_DMA_NOWAIT)) {
Index: sys/dev/pci/if_lge.c
===
RCS file: /cvs/src/sys/dev/pci/if_lge.c,v
retrieving revision 1.78
diff -u -p -u -p -r1.78 if_lge.c
--- sys/dev/pci/if_lge.c11 Mar 2022 18:00:45 - 1.78
+++ sys/dev/pci/if_lge.c8 Oct 2022 14:28:54 -
@@ -475,14 +475,14 @@ lge_attach(struct device *parent, struct
sc->sc_dv.dv_xname, sizeof(struct lge_list_data));
goto fail_3;
}
- DPRINTFN(5, ("bus_dmamem_create\n"));
+ DPRINTFN(5, ("bus_dmamap_create\n"));
if (bus_dmamap_create(sc->sc_dmatag, sizeof(struct lge_list_data), 1,
sizeof(struct lge_list_data), 0,
BUS_DMA_NOWAIT, )) {
printf("%s: can't create dma map\n", sc->sc_dv.dv_xname);
goto fail_4;
}
- DPRINTFN(5, ("bus_dmamem_load\n"));
+ DPRINTFN(5, ("bus_dmamap_load\n"));
if (bus_dmamap_load(sc->sc_dmatag, dmamap, kva,
sizeof(struct lge_list_data), NULL,
BUS_DMA_NOWAIT)) {
Index: sys/dev/pci/if_nge.c
===
RCS file: /cvs/src/sys/dev/pci/if_nge.c,v
retrieving revision 1.96
diff -u -p -u -p -r1.96 if_nge.c
--- sys/dev/pci/if_nge.c11 Mar 2022 18:00:48 - 1.96
+++ sys/dev/pci/if_nge.c8 Oct 2022 14:28:54 -
@@ -768,14 +768,14 @@ nge_attach(struct device *parent, struct
sc->sc_dv.dv_xname, sizeof(struct nge_list_data));
goto fail_3;
}
- DPRINTFN(5, ("%s: bus_dmamem_create\n", sc->sc_dv.dv_xname));
+ DPRINTFN(5, ("%s: bus_dmamap_create\n", sc->sc_dv.dv_xname));
if (bus_dmamap_create(sc->sc_dmatag, sizeof(struct nge_list_data), 1,
sizeof(struct nge_list_data), 0,
BUS_DMA_NOWAIT, )) {
printf("%s: can't create dma map\n", sc->sc_dv.dv_xname);
goto fail_4;
}
- DPRINTFN(5, ("%s: bus_dmamem_load\n", sc->sc_dv.dv_xname));
+ DPRINTFN(5, ("%s: bus_dmamap_load\n", sc->sc_dv.dv_xname));
if (bus_dmamap_load(sc->sc_dmatag, dmamap, kva,
sizeof(struct nge_list_data), NULL,
BUS_DMA_NOWAIT)) {
List SIMCom SIM8262E-M2 as supported for umb(4)
The diff below adds SIMCom SIM8262E-M2 to umb man page. Tested: umb0 at uhub0 port 18 "SIMCOM SDXLEMUR-LITE-MTP _SN:59A7F2D2" rev 3.20/5.04 addr 7 Using 'AT+CUSBCFG=usbid,1e0e,9003' AT command to switch to MBIM mode. ok? Index: share/man/man4/umb.4 === RCS file: /cvs/src/share/man/man4/umb.4,v retrieving revision 1.14 diff -u -p -u -p -r1.14 umb.4 --- share/man/man4/umb.424 Sep 2021 05:25:37 - 1.14 +++ share/man/man4/umb.48 Oct 2022 14:17:47 - @@ -51,6 +51,7 @@ The following devices should work: .It Medion Mobile S4222 (MediaTek OEM) .It Quectel EC25 .It SIMCom SIM7600 +.It SIMCom SIM8262E-M2 .It Sierra Wireless EM7345 .It Sierra Wireless EM7455 .It Sierra Wireless EM8805
Re: ure(4): add support for RTL8156B
On Sat, Apr 02, 2022 at 04:04:24PM +0100, Stuart Henderson wrote:
> On 2022/04/02 15:47, Stuart Henderson wrote:
> > It doesn't, but this fixes it:
> >
> > Index: if_ure.c
> > ===
> > RCS file: /cvs/src/sys/dev/usb/if_ure.c,v
> > retrieving revision 1.29
> > diff -u -p -r1.29 if_ure.c
> > --- if_ure.c2 Apr 2022 12:22:56 - 1.29
> > +++ if_ure.c2 Apr 2022 14:46:50 -
> > @@ -2142,7 +2142,7 @@ ure_encap_txpkt(struct mbuf *m, char *bu
> >
> > #if NVLAN > 0
> > if (m->m_flags & M_VLANTAG)
> > - cflags |= swap16(m->m_pkthdr.ether_vtag | URE_TXPKT_VLAN_TAG);
> > + cflags |= URE_TXPKT_VLAN_TAG | swap16(m->m_pkthdr.ether_vtag);
> > #endif
> >
> > txhdr.ure_pktlen = htole32(m->m_pkthdr.len | URE_TXPKT_TX_FS |
> >
>
> And here's equivalent code in Realtek's Linux driver:
>
> 2059 static inline void rtl_tx_vlan_tag(struct tx_desc *desc, struct sk_buff
> *skb)
> 2060 {
> 2061 if (skb_vlan_tag_present(skb)) {
> 2062 u32 opts2;
> 2063
> 2064 opts2 = TX_VLAN_TAG | swab16(skb_vlan_tag_get(skb));
> 2065 desc->opts2 |= cpu_to_le32(opts2);
> 2066 }
> 2067 }
Good catch! Thanks. I shouldn't work on vacation.
Re: ure(4): add support for RTL8156B
On Fri, Apr 01, 2022 at 06:09:26PM +0100, Stuart Henderson wrote: > > On 2022/04/01 17:13, Stuart Henderson wrote: > > On 2022/04/01 10:26, Gerhard Roth wrote: > > > On 4/1/22 07:41, Kevin Lo wrote: > > > > > > > > ure0: RTL8153 (0x5c10), address 00:e0:4c:xx:xx:xx > > > > rgephy1 at ure0 phy 0: RTL8251 PHY, rev. 0 > > > > > > > > ure0: RTL8153B (0x6010), address f4:28:53:xx:xx:xx > > > > rgephy1 at ure0 phy 0: RTL8251 PHY, rev. 0 > > > > > > > > ure0 at uhub0 port 4 configuration 1 interface 0 "Planex USB > > > > 10/100/1G/2.5G LAN" rev 2.10/30.00 addr 5 > > > > ure0: RTL8156 (0x7030), address 1c:c0:35:xx:xx:xx > > > > > > > > > > > > > You can add another one to the list that works just fine with your > > > patch: > > > > > > ure0 at uhub1 port 1 configuration 1 interface 0 "Realtek USB 10/100/1000 > > > LAN" rev 3.00/30.00 addr 2 > > > ure0: RTL8153 (0x5c30), address 00:13:3b:xx:xx:xx > > > rgephy0 at ure0 phy 0: RTL8251 PHY, rev. 0 > > > > No new issues seen on RTL8153B: > > > > ure0 at uhub0 port 15 configuration 1 interface 0 "Realtek USB 10/100/1000 > > LAN" rev 3.00/31.00 addr 10 > > ure0: RTL8153B (0x6010), address 00:e0:4c:38:2b:0f > > rgephy0 at ure0 phy 0: RTL8251 PHY, rev. 0 > > > > I have also tested with vlan and discovered an existing issue, > > it seems that vlan transmission is not working correctly: no tag > > is sent on the outgoing packet. Reception appears to be ok. > > This occurs with the previous code too so it is not a regression. > > > > Tx works ok if I disable hw tagging. Thanks for the findings. Does it help if you replace the line [1] with "reg |= URE_CPCR_RX_VLAN | 0x80;" ? [1] https://github.com/openbsd/src/blob/master/sys/dev/usb/if_ure.c#L724
Re: ure(4): add support for RTL8156B
On Fri, Apr 01, 2022 at 12:06:02PM +1000, Jonathan Matthew wrote:
>
> On Thu, Mar 31, 2022 at 09:41:09PM +0800, Kevin Lo wrote:
> > Hi,
> >
> >
> >
> > This diff adds preliminary support for RTL8156B to ure(4) and
> > bug fixes for RTL8153/RTL8156.
> >
> > Tested:
> > ure0 at uhub0 port 12 configuration 1 interface 0 "Realtek USB
> > 10/100/1G/2.5G LAN" rev 3.20/31.00 addr 3
> > ure0: RTL8156B (0x7410), address 00:e0:4c:xx:xx:xx
>
> Works OK here:
>
> ure0 at uhub0 port 2 configuration 1 interface 0 "Realtek USB 10/100 LAN" rev
> 2.10/20.00 addr 2
> ure0: RTL8152 (0x4c00), address 00:e0:4c:xx:xx:xx
> rlphy0 at ure0 phy 0: RTL8201E 10/100 PHY, rev. 2
>
> Regarding this part:
>
> > @@ -1914,7 +2026,7 @@ ure_rxeof(struct usbd_xfer *xfer, void *
> > total_len -= roundup(pktlen, URE_RX_BUF_ALIGN);
> > buf += sizeof(rxhdr);
> >
> > - m = m_devget(buf, pktlen, ETHER_ALIGN);
> > + m = m_devget(buf, pktlen - ETHER_CRC_LEN, ETHER_ALIGN);
> > if (m == NULL) {
> > DPRINTF(("unable to allocate mbuf for next packet\n"));
> > ifp->if_ierrors++;
>
> We tried this earlier (r1.22 of if_ure.c) and had to back it out because it
> didn't work on some devices. Have we worked out what the problem was there?
First off, thanks for testing! I recall this problem. I used speedtest-cli
to test the connection speed at home, significant drop in download speed with
r1.22.
With my latest diff, no regressions seen on so far:
ure0: RTL8153 (0x5c10), address 00:e0:4c:xx:xx:xx
rgephy1 at ure0 phy 0: RTL8251 PHY, rev. 0
ure0: RTL8153B (0x6010), address f4:28:53:xx:xx:xx
rgephy1 at ure0 phy 0: RTL8251 PHY, rev. 0
ure0 at uhub0 port 4 configuration 1 interface 0 "Planex USB 10/100/1G/2.5G
LAN" rev 2.10/30.00 addr 5
ure0: RTL8156 (0x7030), address 1c:c0:35:xx:xx:xx
Re: ure(4): add support for RTL8156B
On Thu, Mar 31, 2022 at 08:07:02PM +0200, Stefan Sperling wrote: > > On Thu, Mar 31, 2022 at 09:41:09PM +0800, Kevin Lo wrote: > > This diff adds preliminary support for RTL8156B to ure(4) and > > bug fixes for RTL8153/RTL8156. > > > > Tested: > > ure0 at uhub0 port 12 configuration 1 interface 0 "Realtek USB > > 10/100/1G/2.5G LAN" rev 3.20/31.00 addr 3 > > ure0: RTL8156B (0x7410), address 00:e0:4c:xx:xx:xx > > Works for me. ok stsp@, with one question about the diff below: Thanks for testing! > > Index: sys/dev/usb/if_ure.c > > === > > RCS file: /cvs/src/sys/dev/usb/if_ure.c,v > > retrieving revision 1.28 > > diff -u -p -u -p -r1.28 if_ure.c > > --- sys/dev/usb/if_ure.c20 Aug 2021 04:54:10 - 1.28 > > +++ sys/dev/usb/if_ure.c31 Mar 2022 08:35:04 - > > @@ -197,7 +197,8 @@ voidure_rtl8153_init(struct ure_softc > > void ure_rtl8153b_init(struct ure_softc *); > > void ure_rtl8152_nic_reset(struct ure_softc *); > > void ure_rtl8153_nic_reset(struct ure_softc *); > > -void ure_rtl8153_phy_status(struct ure_softc *, int); > > +uint16_t ure_rtl8153_phy_status(struct ure_softc *, int); > > The function ure_rtl8153_phy_status() now returns a value, > but no caller is checking this value. Is this intentional? Yes, it's intentional. Vendor's Linux driver needs microcode patches for nearly every chipsets and PHYs, it accesses/programs large set of registers unknown to ure(4). Currently ure(4) heavily relies on power on default settings, I plan to add microcode patches although it contains many magic numbers. > Tested with xhci(4) and: > > ure0 at uhub2 port 1 configuration 1 interface 0 "Lenovo Thinkpad USB LAN" > rev 3.00/30.00 addr 6 > ure0: RTL8153 (0x5c20), address 3c:18:a0:a0:95:2b > rgephy0 at ure0 phy 0: RTL8251 PHY, rev. 0 > > This chip still works fine: > > Conn: 1 Mbps: 91.315 Peak Mbps: 92.233 Avg Mbps: 91.315 >27086 10557368 84.459 100.00% > Conn: 1 Mbps: 84.459 Peak Mbps: 92.233 Avg Mbps: 84.459 >280899950656 79.367 100.00% > Conn: 1 Mbps: 79.367 Peak Mbps: 92.233 Avg Mbps: 79.367 >290919335256 74.607 100.00% > Conn: 1 Mbps: 74.607 Peak Mbps: 92.233 Avg Mbps: 74.607 >30091 10476280 83.810 100.00% > Conn: 1 Mbps: 83.810 Peak Mbps: 92.233 Avg Mbps: 83.810 >310949746488 77.739 100.00% > Conn: 1 Mbps: 77.739 Peak Mbps: 92.233 Avg Mbps: 77.739 >320959582864 76.663 100.00% > Conn: 1 Mbps: 76.663 Peak Mbps: 92.233 Avg Mbps: 76.663 >33098 10091112 80.487 100.00% > Conn: 1 Mbps: 80.487 Peak Mbps: 92.233 Avg Mbps: 80.487 >341018650352 68.996 100.00% > Conn: 1 Mbps: 68.996 Peak Mbps: 92.233 Avg Mbps: 68.996 >351069438064 75.204 100.00% > Conn: 1 Mbps: 75.204 Peak Mbps: 92.233 Avg Mbps: 75.204 > ^C > --- 192.168.1.1 tcpbench statistics --- > 350301608 bytes sent over 35.602 seconds > bandwidth min/avg/max/std-dev = 26.875/78.824/92.233/11.918 Mbps
ure(4): add support for RTL8156B
Hi,
This diff adds preliminary support for RTL8156B to ure(4) and
bug fixes for RTL8153/RTL8156.
Tested:
ure0 at uhub0 port 12 configuration 1 interface 0 "Realtek USB 10/100/1G/2.5G
LAN" rev 3.20/31.00 addr 3
ure0: RTL8156B (0x7410), address 00:e0:4c:xx:xx:xx
Index: sys/dev/usb/if_ure.c
===
RCS file: /cvs/src/sys/dev/usb/if_ure.c,v
retrieving revision 1.28
diff -u -p -u -p -r1.28 if_ure.c
--- sys/dev/usb/if_ure.c20 Aug 2021 04:54:10 - 1.28
+++ sys/dev/usb/if_ure.c31 Mar 2022 08:35:04 -
@@ -197,7 +197,8 @@ voidure_rtl8153_init(struct ure_softc
void ure_rtl8153b_init(struct ure_softc *);
void ure_rtl8152_nic_reset(struct ure_softc *);
void ure_rtl8153_nic_reset(struct ure_softc *);
-void ure_rtl8153_phy_status(struct ure_softc *, int);
+uint16_t ure_rtl8153_phy_status(struct ure_softc *, int);
+void ure_wait_for_flash(struct ure_softc *);
void ure_reset_bmu(struct ure_softc *);
void ure_disable_teredo(struct ure_softc *);
@@ -458,14 +459,19 @@ ure_ifmedia_init(struct ifnet *ifp)
ure_write_1(sc, URE_PLA_CRWECR, URE_MCU_TYPE_PLA, URE_CRWECR_NORAML);
if (!(sc->ure_flags & URE_FLAG_8152)) {
+ if (sc->ure_flags & URE_FLAG_8156B)
+ URE_CLRBIT_2(sc, URE_USB_RX_AGGR_NUM, URE_MCU_TYPE_USB,
+ URE_RX_AGGR_NUM_MASK);
+
reg = sc->ure_rxbufsz - URE_FRAMELEN(ifp->if_mtu) -
sizeof(struct ure_rxpkt) - URE_RX_BUF_ALIGN;
- if (sc->ure_flags & (URE_FLAG_8153B | URE_FLAG_8156)) {
+ if (sc->ure_flags & (URE_FLAG_8153B | URE_FLAG_8156 |
+ URE_FLAG_8156B)) {
ure_write_2(sc, URE_USB_RX_EARLY_SIZE, URE_MCU_TYPE_USB,
reg / 8);
ure_write_2(sc, URE_USB_RX_EARLY_AGG, URE_MCU_TYPE_USB,
- (sc->ure_flags & URE_FLAG_8153B) ? 16 : 80);
+ (sc->ure_flags & URE_FLAG_8153B) ? 158 : 80);
ure_write_2(sc, URE_USB_PM_CTRL_STATUS,
URE_MCU_TYPE_USB, 1875);
} else {
@@ -485,6 +491,15 @@ ure_ifmedia_init(struct ifnet *ifp)
ure_write_2(sc, URE_USB_RX_EARLY_AGG, URE_MCU_TYPE_USB,
reg);
}
+
+ if ((sc->ure_chip & URE_CHIP_VER_6010) ||
+ (sc->ure_flags & URE_FLAG_8156B)) {
+ URE_CLRBIT_2(sc, URE_USB_FW_TASK, URE_MCU_TYPE_USB,
+ URE_FC_PATCH_TASK);
+ usbd_delay_ms(sc->ure_udev, 1);
+ URE_SETBIT_2(sc, URE_USB_FW_TASK, URE_MCU_TYPE_USB,
+ URE_FC_PATCH_TASK);
+ }
}
/* Reset the packet filter. */
@@ -494,7 +509,7 @@ ure_ifmedia_init(struct ifnet *ifp)
/* Enable transmit and receive. */
URE_SETBIT_1(sc, URE_PLA_CR, URE_MCU_TYPE_PLA, URE_CR_RE | URE_CR_TE);
- if (sc->ure_flags & (URE_FLAG_8153B | URE_FLAG_8156)) {
+ if (sc->ure_flags & (URE_FLAG_8153B | URE_FLAG_8156 | URE_FLAG_8156B)) {
ure_write_1(sc, URE_USB_UPT_RXDMA_OWN, URE_MCU_TYPE_USB,
URE_OWN_UPDATE | URE_OWN_CLEAR);
}
@@ -510,7 +525,7 @@ ure_ifmedia_upd(struct ifnet *ifp)
struct ifmedia *ifm = >ure_ifmedia;
int anar, gig, err, reg;
- if (sc->ure_flags & URE_FLAG_8156) {
+ if (sc->ure_flags & (URE_FLAG_8156 | URE_FLAG_8156B)) {
if (IFM_TYPE(ifm->ifm_media) != IFM_ETHER)
return (EINVAL);
@@ -579,7 +594,7 @@ ure_ifmedia_sts(struct ifnet *ifp, struc
struct mii_data *mii = >ure_mii;
uint16_tstatus = 0;
- if (sc->ure_flags & URE_FLAG_8156) {
+ if (sc->ure_flags & (URE_FLAG_8156 | URE_FLAG_8156B)) {
ifmr->ifm_status = IFM_AVALID;
if (ure_get_link_status(sc)) {
ifmr->ifm_status |= IFM_ACTIVE;
@@ -711,12 +726,12 @@ ure_rxvlan(struct ure_softc *sc)
struct ifnet*ifp = >ure_ac.ac_if;
uint16_treg;
- if (sc->ure_flags & URE_FLAG_8156) {
- reg = ure_read_2(sc, 0xc012, URE_MCU_TYPE_PLA);
- reg &= ~0x00c0;
+ if (sc->ure_flags & (URE_FLAG_8156 | URE_FLAG_8156B)) {
+ reg = ure_read_2(sc, URE_PLA_RCR1, URE_MCU_TYPE_PLA);
+ reg &= ~(URE_INNER_VLAN | URE_OUTER_VLAN);
if (ifp->if_capabilities & IFCAP_VLAN_HWTAGGING)
- reg |= 0x00c0;
-
Re: initial iwx(4) 11ac patch for testing
On Thu, Mar 10, 2022 at 12:35:20PM +0100, Stefan Sperling wrote: > > On Thu, Mar 10, 2022 at 12:25:17PM +0100, Stefan Sperling wrote: > > Unless anyone else finds a problem, this patch can be considered ready > > for review and commit. > > Of course, I forgot to apply my sysassert fix to the second phy context > command function... Fixed here. Tested: iwx0 at pci7 dev 0 function 0 "Intel Wi-Fi 6 AX200" rev 0x1a, msix iwx0: hw rev 0x340, fw ver 67.8f59b80b.0, address 50:e0:85:xx:xx:xx iwx0: flags=808843 mtu 1500 lladdr 50:e0:85:xx:xx:xx index 2 priority 4 llprio 3 groups: wlan egress media: IEEE802.11 autoselect (VHT-MCS9 mode 11ac) status: active ieee80211: join wing chan 36 bssid b4:8c:9d:49:7d:c8 100% wpakey wpaprotos wpa2 wpaakms psk wpaciphers ccmp wpagroupcipher ccmp inet 10.0.1.178 netmask 0xff00 broadcast 10.255.255.255 I've been running a kernel with this over 5 hours without encountering any issues. Thanks for your hard work!
Re: uchcom(4): fix Rx jammed
On Mon, Jan 17, 2022 at 10:01:17PM +0900, SASANO Takayoshi wrote:
>
> Hi,
>
> Sometimes uchcom(4) looks Rx jammed.
> Here is the movie (at Mastodon) that the problem has occured:
> https://social.tchncs.de/@uaa/107637913051446044
>
> Receiving an exact wMaxPacketSize bytes bulk packet from CH34x causes
> this problem, because this means USB transaction is not finished.
>
> uchcom(4)'s ibufsize for ucom(4) is too large, it should be same as
> wMaxPacketsize for bulk-in endpoint.
I often encounter the same issue while installing. I have had a similar diff
in my tree. Tested:
uchcom0 at uhub0 port 4 configuration 1 interface 0 "QinHeng Electronics
USB2.0-Serial" rev 1.10/2.63 addr 5
uchcom0: CH341
ucom0 at uchcom0
ok kevlo@
> Here's the diff.
>
> Index: uchcom.c
> ===
> RCS file: /cvs/src/sys/dev/usb/uchcom.c,v
> retrieving revision 1.31
> diff -u -p -r1.31 uchcom.c
> --- uchcom.c 19 Nov 2021 07:58:34 - 1.31
> +++ uchcom.c 17 Jan 2022 12:21:55 -
> @@ -113,7 +113,6 @@ int uchcomdebug = 0;
> #define UCHCOM_RESET_VALUE 0x501F /* line mode? */
> #define UCHCOM_RESET_INDEX 0xD90A /* baud rate? */
>
> -#define UCHCOMIBUFSIZE 256
> #define UCHCOMOBUFSIZE 256
>
> struct uchcom_softc
> @@ -141,6 +140,7 @@ struct uchcom_softc
> struct uchcom_endpoints
> {
> int ep_bulkin;
> + int ep_bulkin_size;
> int ep_bulkout;
> int ep_intr;
> int ep_intr_size;
> @@ -293,9 +293,9 @@ uchcom_attach(struct device *parent, str
> uca.portno = UCOM_UNK_PORTNO;
> uca.bulkin = endpoints.ep_bulkin;
> uca.bulkout = endpoints.ep_bulkout;
> - uca.ibufsize = UCHCOMIBUFSIZE;
> + uca.ibufsize = endpoints.ep_bulkin_size;
> uca.obufsize = UCHCOMOBUFSIZE;
> - uca.ibufsizepad = UCHCOMIBUFSIZE;
> + uca.ibufsizepad = endpoints.ep_bulkin_size;
> uca.opkthdrlen = 0;
> uca.device = dev;
> uca.iface = sc->sc_iface;
> @@ -349,7 +349,7 @@ int
> uchcom_find_endpoints(struct uchcom_softc *sc,
> struct uchcom_endpoints *endpoints)
> {
> - int i, bin=-1, bout=-1, intr=-1, isize=0;
> + int i, bin=-1, bout=-1, intr=-1, binsize=0, isize=0;
> usb_interface_descriptor_t *id;
> usb_endpoint_descriptor_t *ed;
>
> @@ -370,6 +370,7 @@ uchcom_find_endpoints(struct uchcom_soft
> } else if (UE_GET_DIR(ed->bEndpointAddress) == UE_DIR_IN &&
> UE_GET_XFERTYPE(ed->bmAttributes) == UE_BULK) {
> bin = ed->bEndpointAddress;
> + binsize = UGETW(ed->wMaxPacketSize);
> } else if (UE_GET_DIR(ed->bEndpointAddress) == UE_DIR_OUT &&
> UE_GET_XFERTYPE(ed->bmAttributes) == UE_BULK) {
> bout = ed->bEndpointAddress;
> @@ -402,6 +403,7 @@ uchcom_find_endpoints(struct uchcom_soft
> endpoints->ep_intr = intr;
> endpoints->ep_intr_size = isize;
> endpoints->ep_bulkin = bin;
> + endpoints->ep_bulkin_size = binsize;
> endpoints->ep_bulkout = bout;
>
> return 0;
>
> --
> SASANO Takayoshi (JG1UAA)
>
Makefile.riscv64: remove -target riscv64-unknown-openbsd from CMACHFLAGS
ok?
Index: sys/arch/riscv64/conf/Makefile.riscv64
===
RCS file: /cvs/src/sys/arch/riscv64/conf/Makefile.riscv64,v
retrieving revision 1.14
diff -u -p -u -p -r1.14 Makefile.riscv64
--- sys/arch/riscv64/conf/Makefile.riscv64 17 Dec 2021 14:59:22 -
1.14
+++ sys/arch/riscv64/conf/Makefile.riscv64 11 Jan 2022 07:13:14 -
@@ -34,7 +34,6 @@ CWARNFLAGS= -Werror -Wall -Wimplicit-fun
CMACHFLAGS=-march=rv64gc -mcmodel=medany -mno-relax \
-fno-omit-frame-pointer -mno-omit-leaf-frame-pointer
CMACHFLAGS+= -ffreestanding ${NOPIE_FLAGS}
-CMACHFLAGS+= -target riscv64-unknown-openbsd
SORTR= sort -R
.if ${IDENT:M-DNO_PROPOLICE}
CMACHFLAGS+= -fno-stack-protector
Re: iwx(4) 40MHz channel support
On Tue, Oct 12, 2021 at 02:47:54PM +0200, Stefan Sperling wrote: > > This patch adds support for 40MHz channels to iwx(4). > > Please sync your source tree before attempting to apply this patch. > I have committed some changes to this driver today which this patch > is based on. > > Works for me on AX200/AX201. Does anyone else want to do a pre-commit test? Tested with iwx0 at pci7 dev 0 function 0 "Intel Wi-Fi 6 AX200" rev 0x1a, msix iwx0: hw rev 0x340, fw ver 63.c04f3485.0, address 50:e0:85:xx:xx:xx Your diff improves performance. I also used tcpdump(8) to check if the AP supports 40MHz: 11:55:50.496408 802.11 flags=0<>: beacon, caps=421, s sid (dlink-657D-5GHz), rates 6M* 9M 12M* 18M 24M* 36M 48M 54M, tim 0x0001, c ountry 'GB ', channel 36 limit 30dB, channel 40 limit 30dB, channel 44 limit 30d B, channel 48 limit 30dB, channel 52 limit 30dB, channel 56 limit 30dB, channel 60 limit 30dB, channel 64 limit 30dB, channel 100 limit 20dB, channel 104 limit 20dB, channel 108 limit 20dB, channel 112 limit 20dB, channel 116 limit 20dB, ch annel 132 limit 20dB, channel 136 limit 20dB, channel 140 limit 20dB, power cons traint 0dB, tpcreport 0x0c00, htcaps=<20/40MHz,LDPC,SGI@20MHz,SGI@40MHz,TXSTBC,R XSTBC 1 stream,A-MSDU 7935,DSSS/CCK@40MHz,A-MPDU max 65535,A-MPDU spacing 16.00u s,RxMCS 0x>, htop=<40MHz chan 48:44,htprot non-member,basic MCS set 0x>, 127:8 0x0040, 191:12 0xb139c103faff0c03 faff0c03, 192:5 0x012a00f0ff, vendor 0x0050f2010150f2020250f2020050f2040 150f202, rsn=, vendor 0x0050f202010103a427a442435e0062322f00, ve ndor 0x00904c33ef191f180481, vendor 0x00 904c3430070100, vendor 0x00e04c02026004, ven dor 0x0050f204104a00011010440001021054000800060050f2040001101100074449522d383432 10080002200c10470010112233445566778899aa409bcd75657d103c0001031049000600372a0001 20, Thanks, Kevin
umb(4) supports for SIMCom SIM7600
Hi,
The diff below enables umb(4) support for SIMCom SIM7600.
The SIM7600 is a mbim compatible chip, you'll need to switch it into mbim
mode via specific AT-commands (AT+CUSBPIDSWITCH=9003,1,1 and AT+CLANMODE=1)
over the serial port.
umb0 at uhub1 port 2 "SIMCOM INCORPORATED SimTech, Incorporated" rev 2.00/3.18
addr 3
ok?
Index: share/man/man4/umb.4
===
RCS file: /cvs/src/share/man/man4/umb.4,v
retrieving revision 1.13
diff -u -p -u -p -r1.13 umb.4
--- share/man/man4/umb.418 May 2021 14:23:03 - 1.13
+++ share/man/man4/umb.424 Sep 2021 01:12:22 -
@@ -50,6 +50,7 @@ The following devices should work:
.\" .It Huawei ME906s -- attaches but needs more work
.It Medion Mobile S4222 (MediaTek OEM)
.It Quectel EC25
+.It SIMCom SIM7600
.It Sierra Wireless EM7345
.It Sierra Wireless EM7455
.It Sierra Wireless EM8805
Index: sys/dev/usb/if_umb.c
===
RCS file: /cvs/src/sys/dev/usb/if_umb.c,v
retrieving revision 1.46
diff -u -p -u -p -r1.46 if_umb.c
--- sys/dev/usb/if_umb.c4 Jul 2021 19:22:31 - 1.46
+++ sys/dev/usb/if_umb.c24 Sep 2021 01:12:24 -
@@ -256,6 +256,12 @@ const struct umb_quirk umb_quirks[] = {
0,
0
},
+
+ { { USB_VENDOR_SIMCOM, USB_PRODUCT_SIMCOM_SIM7600 },
+ 0,
+ 1,
+ UMATCH_VENDOR_PRODUCT
+ },
};
#define umb_lookup(vid, pid) \
Index: sys/dev/usb/usbdevs
===
RCS file: /cvs/src/sys/dev/usb/usbdevs,v
retrieving revision 1.741
diff -u -p -u -p -r1.741 usbdevs
--- sys/dev/usb/usbdevs 31 Aug 2021 22:55:56 - 1.741
+++ sys/dev/usb/usbdevs 24 Sep 2021 01:12:24 -
@@ -4123,6 +4123,7 @@ product SILICONPORTALS YAPPHONE 0x0201 Y
/* Simcom products */
product SIMCOM SIM7600E0x9001 SIM7600E modem
+product SIMCOM SIM7600 0x9003 SIM7600 LTE
/* Sirius Technologies products */
product SIRIUS ROADSTER0x0001 NetComm Roadster II 56
Re: updated patch for iwx(4) Tx aggregation
On Sat, Sep 11, 2021 at 02:04:32PM +0200, Stefan Sperling wrote: > > On Fri, Sep 10, 2021 at 06:49:49PM +0200, Stefan Sperling wrote: > > Here is another attempt at adding Tx aggregation to iwx(4). > > This patch is based on the latest state in CVS (if_iwx.c r1.107, which > > I have committed a minute ago). Sync your tree before applying this patch. > > > > Compared to previous iterations of this patch, I have fixed bugs which > > caused fatal firmware errors and which made traffic stall after roaming. > > > > This patch could still make 7.0 release if it gets sufficient test coverage. > > Please run with this and report any regressions. Thanks! > > > > So far, tested by me on AX200 and AX201 against a Pepwave 11ac AP. > > I have so far not seen any fatal firmware errors, and roaming between 2GHz > > and 5GHz channels offered by the same AP seems to work reliably. > > Throughput goes up to 100 Mbit/s max. > > The previous version had a problem where it did not take frames > off the Tx ring when they were done. It is possible that this > could lead to memory corruption (seen by mlarkin). > > Please run this updated patch instead. > > And please enable 'ifconfig iwx0 debug' while testing this patch. > Problem reports will be a lot more useful with debug enabled :) Tested on the following device with speedtest-cli looks like I'm seeing improvement. iwx0 at pci3 dev 0 function 0 "Intel Wi-Fi 6 AX200" rev 0x1a, msix iwx0: hw rev 0x340, fw ver 63.c04f3485.0, address 50:e0:85:xx:xx:xx My AX200 is now getting ~48 Mbps down / ~19 Mbps up where before I was getting ~28 Mbps down / ~13 Mbps up. I got a message "iwx0: device timeout", but didn't see fatal firmware errors.
Re: iwm/iwx suspend/resume improvement
On Thu, Sep 02, 2021 at 03:26:03PM +0200, Stefan Sperling wrote: > > This patch fixes suspend/resume with an AX201 device for gnezdo@. > Tests on any iwm/iwx device would be apreciated. > > Before testing this make sure to update your tree to -current which contains > a very recent fix for a double-free in the resume path of the iwx driver. > You won't have great results testing this patch without the double-free > fix in place. Tested with the following devices: iwm0 at pci0 dev 20 function 3 "Intel AC 9560" rev 0x10, msix iwm0: hw rev 0x310, fw ver 46.6b541b68.0, address 48:f1:7f:76:98:6f iwx0 at pci3 dev 0 function 0 "Intel Wi-Fi 6 AX200" rev 0x1a, msix iwx0: hw rev 0x340, fw ver 63.c04f3485.0, address 50:e0:85:a6:8e:3c Suspend/resume works properly, thanks.
Re: iwx(4): fix xtal latency values
On Thu, Sep 02, 2021 at 02:24:17PM +0200, Stefan Sperling wrote: > While review device-specific quirks in this driver I noticed that > the xtal latency values we send to the chip do no match those used > by the Linux driver. > > ok? One small nit below. With that fixed, ok kevlo@ > diff b81ef55c86817a4ccf18086fd9b7dc3ee49ae415 /usr/src (staged changes) > blob - 096caf79896dcd97f16f0744fb8206ad8a12a9d7 > blob + ac55b8e39fe1b6308a9637396caa32f15b5597f7 > --- sys/dev/pci/if_iwx.c > +++ sys/dev/pci/if_iwx.c > @@ -9363,7 +9363,7 @@ iwx_attach(struct device *parent, struct device *self, > sc->sc_integrated = 1; > sc->sc_ltr_delay = IWX_SOC_FLAGS_LTR_APPLY_DELAY_200; > sc->sc_low_latency_xtal = 0; > - sc->sc_xtal_latency = 5000; > + sc->sc_xtal_latency = 500; > sc->sc_tx_with_siso_diversity = 0; > sc->sc_uhb_supported = 0; > break; > @@ -9373,7 +9373,7 @@ iwx_attach(struct device *parent, struct device *self, > sc->sc_integrated = 1; > sc->sc_ltr_delay = IWX_SOC_FLAGS_LTR_APPLY_DELAY_200; ^ Should be IWX_SOC_FLAGS_LTR_APPLY_DELAY_1820. > sc->sc_low_latency_xtal = 0; > - sc->sc_xtal_latency = 5000; > + sc->sc_xtal_latency = 1820; > sc->sc_tx_with_siso_diversity = 0; > sc->sc_uhb_supported = 0; > break; >
Re: uaq(4): aquantia usb ethernet driver
On Wed, Sep 01, 2021 at 10:46:01AM +1000, Jonathan Matthew wrote: > > Here's a driver for the Aquantia USB ethernet devices I just added > to usbdevs. These are somewhat interesting because they theoretically > go up to 5GbE and support jumbo frames (not implemented yet). > > While working on this I noticed that it doesn't receive 15-25% of the packets > it should, even at very low packet rates, when connected to ehci(4) > controllers. > No such packet loss occurs with an xhci(4) controller. I'm not sure if this > is a problem with our ehci driver or a poor hardware interaction. I tested your diff with the following device: uaq0 at uhub0 port 19 configuration 1 interface 0 "QNAP QNAP QNA-UC5G1T USB to 5GbE Adapter" rev 3.20/1.01 addr 4 uaq0: ver 2.5.30, address 24:5e:be:xx:xx:xx I noticed that if the device connects to an xhci controller and connects to a Gigabit switch, I'll get a bunch of messages while running iperf3: uaq0: offset mismatch, got 5232 expected 49969927280 uaq0: offset mismatch, got -25912 expected 149128480565874 uaq0: offset mismatch, got 2192 expected 55976167568 ... Apart from that it's working fine. > ok? ok kevlo@
Re: Unplugging ure(4) during attach
On Wed, Aug 18, 2021 at 04:12:03PM +, Christian Ludwig wrote: > Hi, > > when plugging and unplugging an ure(4) adapter continuously, I came > across the following error with URE_DEBUG set: > > ure0 at uhub0 port 21 configuration 1 interface 0 "Realtek USB 10/100/1000 > LAN" rev 3.00/30.00 addr 4 > ure0: RTL8153 (0x5c10)ure_ctl: error 15 > ure_ctl: error 15 > ure_ctl: error 15 > > It waits for a timeout over and over again. The problem is that the > device has been unplugged, but the attach handler still issues USB > requests via ure_ctl(). While there is an early abort check with > usbd_is_dying() in that function, it does not work during attach. The > reason is that the attach handler runs from the USB exploration task. > But that task also handles device detach. So while the hardware port > change event has been noticed, it is up to the USB exploration task to > actually detach (and deactivate) the device. But it is still running > the ure(4) attach handler, which now happily waits for each USB request > to time out. And the ure(4) attach handler has a bunch of loops calling > ure_ctl(), which takes a really long time to complete altogether when > it waits for a timeout for each of them. During that time no other USB > device will get attached/detached either. > > The following diff helps with debugging. Plug a ure(4) device and > unplug it within 10 seconds. > > --- 8< --- > diff --git a/sys/dev/usb/if_ure.c b/sys/dev/usb/if_ure.c > index ea73db00954..93b76b421b3 100644 > --- a/sys/dev/usb/if_ure.c > +++ b/sys/dev/usb/if_ure.c > @@ -1702,6 +1704,8 @@ ure_attach(struct device *parent, struct device *self, > void *aux) > break; > } > > + usbd_delay_ms(sc->ure_udev, 1); > + > if (sc->ure_flags & URE_FLAG_8152) > ure_rtl8152_init(sc); > else if (sc->ure_flags & (URE_FLAG_8153B | URE_FLAG_8156)) > --- 8< --- > > The problem is that most of the callers of ure_ctl() do not check the > error return code, especially during attach. One solution could be to > propagate the error and handle it during attach. OTOH other USB device > drivers have the same problem. So one might argue that the USB stack is > at fault then. If we wanted to fix it in the USB stack, we would need > to decouple how port change events are handled. Maybe we could get away > with sneaking it into usbd_do_request(). But all of that looks rather > fragile and is well beyond me. > > The easiest solution is to deactivate the device proactively in > ure_ctl() when we see that error there. Linux's rtl8152 does something > similar and checks if the device is unplugged [1][2]. > > [1] > https://elixir.bootlin.com/linux/v5.14-rc5/source/drivers/net/usb/r8152.c#L1249 > [2] > https://elixir.bootlin.com/linux/v5.14-rc5/source/drivers/net/usb/r8152.c#L1293 > > Thanks to kevlo@ for helping me debug this. Committed. Thanks for spending the time in debugging the issue. > > So long, > > > - Christian Kevin
ix(4): fix Rx hash type
Hi,
The diff below fixes Rx desc RSS type. This matches what Linux and FreeBSD do.
ok?
Index: sys/dev/pci/if_ix.c
===
RCS file: /cvs/src/sys/dev/pci/if_ix.c,v
retrieving revision 1.178
diff -u -p -u -p -r1.178 if_ix.c
--- sys/dev/pci/if_ix.c 22 Dec 2020 23:25:37 - 1.178
+++ sys/dev/pci/if_ix.c 14 Jul 2021 05:41:08 -
@@ -3071,7 +3071,8 @@ ixgbe_rxeof(struct rx_ring *rxr)
i = rxr->next_to_check;
while (if_rxr_inuse(>rx_ring) > 0) {
- uint32_t hash, hashtype;
+ uint32_t hash;
+ uint16_t hashtype;
bus_dmamap_sync(rxr->rxdma.dma_tag, rxr->rxdma.dma_map,
dsize * i, dsize, BUS_DMASYNC_POSTREAD);
@@ -3101,7 +3102,8 @@ ixgbe_rxeof(struct rx_ring *rxr)
vtag = letoh16(rxdesc->wb.upper.vlan);
eop = ((staterr & IXGBE_RXD_STAT_EOP) != 0);
hash = lemtoh32(>wb.lower.hi_dword.rss);
- hashtype = lemtoh32(>wb.lower.lo_dword.data) &
+ hashtype =
+ lemtoh16(>wb.lower.lo_dword.hs_rss.pkt_info) &
IXGBE_RXDADV_RSSTYPE_MASK;
if (staterr & IXGBE_RXDADV_ERR_FRAME_ERR_MASK) {
Re: iwm(4): use new firmware images with fragattack fixes
On Tue, May 25, 2021 at 03:48:16PM +0200, Stefan Sperling wrote: > > This patch allows iwm(4) to use new firmware images which are part > of the iwm-20210512 firmware package, available via fw_update (you > need to run fw_update *before* booting with this patch). > > The new firmware images were published right after the fragattacks > embargo period ended. An advisory was published by Intel: > https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00473.html > > I have tested the following cards successfully: > 7265, 8265, 9260, 9560 > > I cannot test any other devices myself right now; help with testing this > patch would be much appreciated. It is likely that all devices will work. > But I would still prefer to see test reports for the following cards before > committing this patch: > 7260, 3160, 3165, 3168, 8260 > > The 7260 and 3160 cards did not receive firmware updates from Intel. Which > could be good or bad news, depending on whether the devices are vulnerable > to fragattacks. The fragattacks test tools might shed light on this if you > are curious. I'd be interested to learn more if you have test results or > any other solid information regarding this. Tested on: iwm0 at pci3 dev 0 function 0 "Intel Dual Band Wireless-AC 3168" rev 0x10, msi iwm0: hw rev 0x220, fw ver 29.198743027.0, address b0:35:9f:xx:xx:xx $ pkg_info -I iwm-firmware iwm-firmware-20210512 firmware binary images for iwm(4) driver No regressions under normal use. Thanks!
umsm(4)/umb(4) supports for Quectel EC25
Hi,
Attached is a diff for umsm(4)/umb(4) which enables support for Quectel EC25.
umsm0 at uhub0 port 2 configuration 1 interface 0 "Android Android" rev
2.00/3.18 addr 2
ucom0 at umsm0
umsm1 at uhub0 port 2 configuration 1 interface 1 "Android Android" rev
2.00/3.18 addr 2
ucom1 at umsm1
umsm2 at uhub0 port 2 configuration 1 interface 2 "Android Android" rev
2.00/3.18 addr 2
ucom2 at umsm2
umsm3 at uhub0 port 2 configuration 1 interface 3 "Android Android" rev
2.00/3.18 addr 2
ucom3 at umsm3
umsm4 at uhub0 port 2 configuration 1 interface 4 "Android Android" rev
2.00/3.18 addr 2
ucom4 at umsm4
The Quectel EC25 is a MBIM compatible chip, you'll need to switch it into MBIM
mode via a specific AT-command (AT+QCFG="usbnet",2) over the serial port cuaU2.
Need additional quirks to get Quectel to work.
umb0 at uhub0 port 2 "Android Android" rev 2.00/3.18 addr 2
Index: share/man/man4/umb.4
===
RCS file: /cvs/src/share/man/man4/umb.4,v
retrieving revision 1.12
diff -u -p -u -p -r1.12 umb.4
--- share/man/man4/umb.428 Mar 2021 12:10:05 - 1.12
+++ share/man/man4/umb.415 May 2021 09:05:33 -
@@ -49,6 +49,7 @@ The following devices should work:
.It Fibocom L831-EAU
.\" .It Huawei ME906s -- attaches but needs more work
.It Medion Mobile S4222 (MediaTek OEM)
+.It Quectel EC25
.It Sierra Wireless EM7345
.It Sierra Wireless EM7455
.It Sierra Wireless EM8805
Index: share/man/man4/umsm.4
===
RCS file: /cvs/src/share/man/man4/umsm.4,v
retrieving revision 1.95
diff -u -p -u -p -r1.95 umsm.4
--- share/man/man4/umsm.4 11 Apr 2018 04:23:10 - 1.95
+++ share/man/man4/umsm.4 15 May 2021 09:05:33 -
@@ -100,6 +100,7 @@ driver:
.It Li "Option iCON 225" Ta "USB"
.It Li "Option iCON 505" Ta "USB"
.It Li "Option GlobeTrotter HSUPA 380E" Ta "PCI Express Mini Card"
+.It Li "Quectel EC25" Ta "PCI Express Mini Card"
.It Li "Sierra Wireless MC8755" Ta "PCI Express Mini Card"
.It Li "Sierra Wireless MC8775" Ta "PCI Express Mini Card"
.It Li "Sierra Wireless MC8790" Ta "PCI Express Mini Card"
Index: sys/dev/usb/if_umb.c
===
RCS file: /cvs/src/sys/dev/usb/if_umb.c,v
retrieving revision 1.44
diff -u -p -u -p -r1.44 if_umb.c
--- sys/dev/usb/if_umb.c22 Apr 2021 14:06:59 - 1.44
+++ sys/dev/usb/if_umb.c15 May 2021 09:05:35 -
@@ -238,6 +238,13 @@ const struct umb_quirk umb_quirks[] = {
UMATCH_VENDOR_PRODUCT
},
+ { { USB_VENDOR_QUECTEL, USB_PRODUCT_QUECTEL_EC25 },
+ 0,
+ 1,
+ UMATCH_VENDOR_PRODUCT
+ },
+
+
{ { USB_VENDOR_HUAWEI, USB_PRODUCT_HUAWEI_ME906S },
UMBFLG_NDP_AT_END,
3,
Index: sys/dev/usb/umsm.c
===
RCS file: /cvs/src/sys/dev/usb/umsm.c,v
retrieving revision 1.118
diff -u -p -u -p -r1.118 umsm.c
--- sys/dev/usb/umsm.c 31 Jul 2020 10:49:33 - 1.118
+++ sys/dev/usb/umsm.c 15 May 2021 09:05:35 -
@@ -173,6 +173,8 @@ static const struct umsm_type umsm_devs[
{{ USB_VENDOR_QUANTA2, USB_PRODUCT_QUANTA2_UMASS }, DEV_UMASS4},
{{ USB_VENDOR_QUANTA2, USB_PRODUCT_QUANTA2_Q101 }, 0},
+ {{ USB_VENDOR_QUECTEL, USB_PRODUCT_QUECTEL_EC25 }, 0},
+
{{ USB_VENDOR_ZTE, USB_PRODUCT_ZTE_AC2746 }, 0},
{{ USB_VENDOR_ZTE, USB_PRODUCT_ZTE_UMASS_INSTALLER }, DEV_UMASS4},
{{ USB_VENDOR_ZTE, USB_PRODUCT_ZTE_UMASS_INSTALLER2 }, DEV_UMASS6},
Index: sys/dev/usb/usbdevs
===
RCS file: /cvs/src/sys/dev/usb/usbdevs,v
retrieving revision 1.739
diff -u -p -u -p -r1.739 usbdevs
--- sys/dev/usb/usbdevs 25 Apr 2021 15:58:01 - 1.739
+++ sys/dev/usb/usbdevs 15 May 2021 09:05:35 -
@@ -644,6 +644,7 @@ vendor THINGM 0x27b8 ThingM
vendor ASUSTEK 0x2821 ASUSTeK Computer
vendor PIONEERDJ 0x2b73 Pioneer DJ
vendor PLANEX 0x2c02 Planex Communications
+vendor QUECTEL 0x2c7c Quectel
vendor CLUB3D 0x2d1c Club 3D
vendor CLEVO 0x30da CLEVO
vendor DYNABOOK0x30f3 Dynabook
@@ -3679,6 +3680,9 @@ product QUALCOMM2 MSM_PHONE 0x6000 CDMA
product QUANTA RT3070 0x0304 RT3070
product QUANTA2 UMASS 0x1000 Quanta USB MSM (umass mode)
product QUANTA2 Q101 0xea02 Quanta Q101 HSDPA USB modem
+
+/* Quectel products */
+product QUECTEL EC25 0x0125 EC25 LTE
/* Quickshot products */
product QUICKSHOT STRIKEPAD0x6238 USB StrikePad
ure(4): correct the rx early size
The rx early size is used to reduce the loading of CPU by letting a transfer
contain more data to reduce the number of transfers.
The algorithm should be (ure_rxbufsz - packet size) / 8
This matches Linux path in r8153_set_rx_early_size().
ok?
Index: sys/dev/usb/if_ure.c
===
RCS file: /cvs/src/sys/dev/usb/if_ure.c,v
retrieving revision 1.23
diff -u -p -u -p -r1.23 if_ure.c
--- sys/dev/usb/if_ure.c7 Apr 2021 06:52:22 - 1.23
+++ sys/dev/usb/if_ure.c9 Apr 2021 08:32:55 -
@@ -761,8 +761,8 @@ ure_init(void *xsc)
ure_write_1(sc, URE_PLA_CRWECR, URE_MCU_TYPE_PLA, URE_CRWECR_NORAML);
if (!(sc->ure_flags & URE_FLAG_8152)) {
- reg = sc->ure_rxbufsz - URE_FRAMELEN(ifp->if_mtu) +
- sizeof(struct ure_rxpkt) + URE_RX_BUF_ALIGN;
+ reg = sc->ure_rxbufsz - URE_FRAMELEN(ifp->if_mtu) -
+ sizeof(struct ure_rxpkt) - URE_RX_BUF_ALIGN;
if (sc->ure_flags & (URE_FLAG_8153B | URE_FLAG_8156)) {
ure_write_2(sc, URE_USB_RX_EARLY_SIZE, URE_MCU_TYPE_USB,
reg / 8);
Re: veb(4) exceeds 1514 byte frame size while bridge(4) doesn't?
On Tue, Mar 23, 2021 at 08:24:56PM +1000, David Gwynne wrote:
>
> On Sun, Mar 21, 2021 at 04:24:24PM +0100, Jurjen Oskam wrote:
> > Hi,
> >
> > When trying out veb(4), I ran into a situation where TCP sessions across a
> > veb(4) bridge stalled while the exact same config using bridge(4) worked
> > fine.
> >
> > After some investigation, it seems that veb(4) adds an FCS to the outgoing
> > frame, while bridge(4) doesn't. When this causes the outgoing frame to
> > exceed
> > 1514 bytes, the destination doesn't receive it.
> >
> > I must note that I was using USB NICs, one of them being quite old.
> >
> > Am I doing something wrong, or is the problem in (one of) the NIC(s)?
>
> it looks like ure(4) hardware doesn't strip the fcs before pushing it to
> the host over usb, but the ure(4) driver doesn't strip it.
>
> this usually isn't a huge deal because layers like ip just ignore
> the extra bytes. bridge(4) was ok with this because it actually
> parses ip packets and removes the extra bytes. veb(4) does a lot less
> (by design) so it just lets the fcs on the end of ure packets go out to
> other nics.
>
> from what i can tell, ure should remove the fcs. that's what this diff
> does. can you try it?
You're right, ure(4) should strip the FCS.
ok kevlo@
> cheers,
> dlg
>
> Index: if_ure.c
> ===
> RCS file: /cvs/src/sys/dev/usb/if_ure.c,v
> retrieving revision 1.21
> diff -u -p -r1.21 if_ure.c
> --- if_ure.c 14 Oct 2020 23:47:55 - 1.21
> +++ if_ure.c 23 Mar 2021 10:18:54 -
> @@ -1896,10 +1896,17 @@ ure_rxeof(struct usbd_xfer *xfer, void *
> ifp->if_ierrors++;
> goto done;
> }
> + if (pktlen < ETHER_MIN_LEN) {
> + DPRINTF(("ethernet frame is too short\n"));
> + ifp->if_ierrors++;
> + goto done;
> + }
>
> total_len -= roundup(pktlen, URE_RX_BUF_ALIGN);
> buf += sizeof(rxhdr);
>
> + /* trim fcs */
> + pktlen -= ETHER_CRC_LEN;
> m = m_devget(buf, pktlen, ETHER_ALIGN);
> if (m == NULL) {
> DPRINTF(("unable to allocate mbuf for next packet\n"));
>
rge(4): move tx/rx descriptors into their own structs
Hi,
The diff below moves tx/rx descriptors into their own structs.
This is a first step toward making rge work with multiple queues and interrupts.
Only one queue is currently used.
While here, update the RTL8125B microcode.
Index: sys/dev/pci/if_rge.c
===
RCS file: /cvs/src/sys/dev/pci/if_rge.c,v
retrieving revision 1.12
diff -u -p -u -p -r1.12 if_rge.c
--- sys/dev/pci/if_rge.c11 Feb 2021 16:22:06 - 1.12
+++ sys/dev/pci/if_rge.c25 Mar 2021 09:14:17 -
@@ -61,7 +61,7 @@ int rge_match(struct device *, void *,
void rge_attach(struct device *, struct device *, void *);
intrge_activate(struct device *, int);
intrge_intr(void *);
-intrge_encap(struct rge_softc *, struct mbuf *, int);
+intrge_encap(struct rge_queues *, struct mbuf *, int);
intrge_ioctl(struct ifnet *, u_long, caddr_t);
void rge_start(struct ifqueue *);
void rge_watchdog(struct ifnet *);
@@ -70,13 +70,13 @@ voidrge_stop(struct ifnet *);
intrge_ifmedia_upd(struct ifnet *);
void rge_ifmedia_sts(struct ifnet *, struct ifmediareq *);
intrge_allocmem(struct rge_softc *);
-intrge_newbuf(struct rge_softc *);
-void rge_discard_rxbuf(struct rge_softc *, int);
-void rge_rx_list_init(struct rge_softc *);
-void rge_tx_list_init(struct rge_softc *);
-void rge_fill_rx_ring(struct rge_softc *);
-intrge_rxeof(struct rge_softc *);
-intrge_txeof(struct rge_softc *);
+intrge_newbuf(struct rge_queues *);
+void rge_discard_rxbuf(struct rge_queues *, int);
+void rge_rx_list_init(struct rge_queues *);
+void rge_tx_list_init(struct rge_queues *);
+void rge_fill_rx_ring(struct rge_queues *);
+intrge_rxeof(struct rge_queues *);
+intrge_txeof(struct rge_queues *);
void rge_reset(struct rge_softc *);
void rge_iff(struct rge_softc *);
void rge_set_phy_power(struct rge_softc *, int);
@@ -159,6 +159,7 @@ rge_attach(struct device *parent, struct
pci_intr_handle_t ih;
const char *intrstr = NULL;
struct ifnet *ifp;
+ struct rge_queues *q;
pcireg_t reg;
uint32_t hwrev;
uint8_t eaddr[ETHER_ADDR_LEN];
@@ -184,6 +185,17 @@ rge_attach(struct device *parent, struct
}
}
+ q = malloc(sizeof(struct rge_queues), M_DEVBUF, M_NOWAIT | M_ZERO);
+ if (q == NULL) {
+ printf(": unable to allocate queue memory\n");
+ return;
+ }
+ q->q_sc = sc;
+ q->q_index = 0;
+
+ sc->sc_queues = q;
+ sc->sc_nqueues = 1;
+
/*
* Allocate interrupt.
*/
@@ -323,9 +335,10 @@ int
rge_intr(void *arg)
{
struct rge_softc *sc = arg;
+ struct rge_queues *q = sc->sc_queues;
struct ifnet *ifp = >sc_arpcom.ac_if;
uint32_t status;
- int claimed = 0, rx, tx;
+ int claimed = 0, rv;
if (!(ifp->if_flags & IFF_RUNNING))
return (0);
@@ -345,29 +358,21 @@ rge_intr(void *arg)
if (status & RGE_ISR_PCS_TIMEOUT)
claimed = 1;
- rx = tx = 0;
+ rv = 0;
if (status & sc->rge_intrs) {
- if (status &
- (sc->rge_rx_ack | RGE_ISR_RX_ERR | RGE_ISR_RX_FIFO_OFLOW)) {
- rx |= rge_rxeof(sc);
- claimed = 1;
- }
-
- if (status & (sc->rge_tx_ack | RGE_ISR_TX_ERR)) {
- tx |= rge_txeof(sc);
- claimed = 1;
- }
+ rv |= rge_rxeof(q);
+ rv |= rge_txeof(q);
if (status & RGE_ISR_SYSTEM_ERR) {
KERNEL_LOCK();
rge_init(ifp);
KERNEL_UNLOCK();
- claimed = 1;
}
+ claimed = 1;
}
if (sc->rge_timerintr) {
- if ((tx | rx) == 0) {
+ if (!rv) {
/*
* Nothing needs to be processed, fallback
* to use TX/RX interrupts.
@@ -379,11 +384,11 @@ rge_intr(void *arg)
* race introduced by changing interrupt
* masks.
*/
- rge_rxeof(sc);
- rge_txeof(sc);
+ rge_rxeof(q);
+ rge_txeof(q);
} else
RGE_WRITE_4(sc, RGE_TIMERCNT, 1);
- } else if (tx | rx) {
+ } else if (rv) {
/*
* Assume that using simulated interrupt moderation
* (hardware timer based) could reduce the
Re: athn(4): switch Tx rate control to RA
On Tue, Mar 23, 2021 at 06:01:27PM +0100, Stefan Sperling wrote: > > This switches athn(4) to the new RA Tx rate adaptation module. > Tests on athn(4) PCI devices are welcome. > USB devices don't need to be tested in this case Tx rate adaptation > is taken care of by firmware. > > I could only test on AR9285 so far, but the result looks promising. Hi Stefan, I tested on ar9285 as well: athn0 at pci2 dev 0 function 0 "Atheros AR9285" rev 0x01: apic 1 int 17 athn0: AR9285 rev 2 (1T1R), ROM rev 14, address 74:2f:68:xx:xx:xx This patch works well for me and increased throughput notable. Nice work! :)
Re: Add missing break statement on if_rge.c
On Thu, Feb 11, 2021 at 12:24:37PM +, Ricardo Mestre wrote: > > Hi, > > Add missing break statement. OK? ok kevlo@. stsp@ has informed me earlier and has the same diff, I think he will be committing it later today. > CID 1501710 > > Index: if_rge.c > === > RCS file: /cvs/src/sys/dev/pci/if_rge.c,v > retrieving revision 1.11 > diff -u -p -c -u -r1.11 if_rge.c > --- if_rge.c 24 Dec 2020 06:34:03 - 1.11 > +++ if_rge.c 11 Feb 2021 12:21:33 - > @@ -311,6 +311,7 @@ rge_activate(struct device *self, int ac > #ifndef SMALL_KERNEL > rge_wol_power(sc); > #endif > + break; > default: > rv = config_activate_children(self, act); > break;
Document IFM_2500_T media type
The diff below documents IFM_2500_T media type. ok? Index: share/man/man4/ifmedia.4 === RCS file: /cvs/src/share/man/man4/ifmedia.4,v retrieving revision 1.27 diff -u -p -u -p -r1.27 ifmedia.4 --- share/man/man4/ifmedia.416 May 2020 12:23:12 - 1.27 +++ share/man/man4/ifmedia.421 Jan 2021 02:34:10 - @@ -164,6 +164,9 @@ Compatibility for 1000BASE-T. .It Dv IFM_2500_SX 2500BASE-SX, 2.5Gb/s over multi-mode fiber optic cables. [2500baseSX, 2500SX] +.It Dv IFM_2500_T +2500BASE-T, 2.5Gb/s over unshielded twisted pair, RJ45 connector. +[2500baseT, 2500BASE-T] .It Dv IFM_10G_CX4 10GBASE-CX4, 10Gb/s over XAUI 4-lane PCS and copper cables. [10GbaseCX4, 10GCX4, 10GBASE-CX4]
Wake on LAN support for rge(4)
Hi,
This diff implements WoL support in rge(4). I can wakeup the machine with WoL
after suspending it through `zzz` or powering off it through `halt -p`.
Index: share/man/man4/rge.4
===
RCS file: /cvs/src/share/man/man4/rge.4,v
retrieving revision 1.4
diff -u -p -u -p -r1.4 rge.4
--- share/man/man4/rge.412 Oct 2020 02:11:10 - 1.4
+++ share/man/man4/rge.423 Dec 2020 04:33:26 -
@@ -37,6 +37,15 @@ Rivet Networks Killer E3000 Adapter (250
.It
TP-LINK TL-NG421 Adapter (2500baseT)
.El
+.Pp
+The
+.Nm
+driver additionally supports Wake on LAN (WoL).
+See
+.Xr arp 8
+and
+.Xr ifconfig 8
+for more details.
.Sh SEE ALSO
.Xr arp 4 ,
.Xr ifmedia 4 ,
Index: sys/dev/pci/if_rge.c
===
RCS file: /cvs/src/sys/dev/pci/if_rge.c,v
retrieving revision 1.9
diff -u -p -u -p -r1.9 if_rge.c
--- sys/dev/pci/if_rge.c12 Dec 2020 11:48:53 - 1.9
+++ sys/dev/pci/if_rge.c23 Dec 2020 04:33:27 -
@@ -59,6 +59,7 @@ int rge_debug = 0;
intrge_match(struct device *, void *, void *);
void rge_attach(struct device *, struct device *, void *);
+intrge_activate(struct device *, int);
intrge_intr(void *);
intrge_encap(struct rge_softc *, struct mbuf *, int);
intrge_ioctl(struct ifnet *, u_long, caddr_t);
@@ -111,6 +112,10 @@ intrge_get_link_status(struct rge_soft
void rge_txstart(void *);
void rge_tick(void *);
void rge_link_state(struct rge_softc *);
+#ifndef SMALL_KERNEL
+intrge_wol(struct ifnet *, int);
+void rge_wol_power(struct rge_softc *);
+#endif
static const struct {
uint16_t reg;
@@ -126,7 +131,7 @@ static const struct {
};
struct cfattach rge_ca = {
- sizeof(struct rge_softc), rge_match, rge_attach
+ sizeof(struct rge_softc), rge_match, rge_attach, NULL, rge_activate
};
struct cfdriver rge_cd = {
@@ -272,6 +277,11 @@ rge_attach(struct device *parent, struct
ifp->if_capabilities |= IFCAP_VLAN_HWTAGGING;
#endif
+#ifndef SMALL_KERNEL
+ ifp->if_capabilities |= IFCAP_WOL;
+ ifp->if_wol = rge_wol;
+ rge_wol(ifp, 0);
+#endif
timeout_set(>sc_timeout, rge_tick, sc);
task_set(>sc_task, rge_txstart, sc);
@@ -288,6 +298,25 @@ rge_attach(struct device *parent, struct
}
int
+rge_activate(struct device *self, int act)
+{
+ struct rge_softc *sc = (struct rge_softc *)self;
+ int rv = 0;
+
+ switch (act) {
+ case DVACT_POWERDOWN:
+ rv = config_activate_children(self, act);
+#ifndef SMALL_KERNEL
+ rge_wol_power(sc);
+#endif
+ default:
+ rv = config_activate_children(self, act);
+ break;
+ }
+ return (rv);
+}
+
+int
rge_intr(void *arg)
{
struct rge_softc *sc = arg;
@@ -2025,6 +2054,7 @@ rge_hw_init(struct rge_softc *sc)
/* Set PCIe uncorrectable error status. */
rge_write_csi(sc, 0x108,
rge_read_csi(sc, 0x108) | 0x0010);
+
}
void
@@ -2391,3 +2421,48 @@ rge_link_state(struct rge_softc *sc)
if_link_state_change(ifp);
}
}
+
+#ifndef SMALL_KERNEL
+int
+rge_wol(struct ifnet *ifp, int enable)
+{
+ struct rge_softc *sc = ifp->if_softc;
+
+ if (enable) {
+ if (!(RGE_READ_1(sc, RGE_CFG1) & RGE_CFG1_PM_EN)) {
+ printf("%s: power management is disabled, "
+ "cannot do WOL\n", sc->sc_dev.dv_xname);
+ return (ENOTSUP);
+ }
+
+ }
+
+ rge_iff(sc);
+
+ if (enable)
+ RGE_MAC_SETBIT(sc, 0xc0b6, 0x0001);
+ else
+ RGE_MAC_CLRBIT(sc, 0xc0b6, 0x0001);
+
+ RGE_SETBIT_1(sc, RGE_EECMD, RGE_EECMD_WRITECFG);
+ RGE_CLRBIT_1(sc, RGE_CFG5, RGE_CFG5_WOL_LANWAKE | RGE_CFG5_WOL_UCAST |
+ RGE_CFG5_WOL_MCAST | RGE_CFG5_WOL_BCAST);
+ RGE_CLRBIT_1(sc, RGE_CFG3, RGE_CFG3_WOL_LINK | RGE_CFG3_WOL_MAGIC);
+ if (enable)
+ RGE_SETBIT_1(sc, RGE_CFG5, RGE_CFG5_WOL_LANWAKE);
+ RGE_CLRBIT_1(sc, RGE_EECMD, RGE_EECMD_WRITECFG);
+
+ return (0);
+}
+
+void
+rge_wol_power(struct rge_softc *sc)
+{
+ /* Disable RXDV gate. */
+ RGE_CLRBIT_1(sc, RGE_PPSW, 0x08);
+ DELAY(2000);
+
+ RGE_SETBIT_1(sc, RGE_CFG1, RGE_CFG1_PM_EN);
+ RGE_SETBIT_1(sc, RGE_CFG2, RGE_CFG2_PMSTS_EN);
+}
+#endif
Index: sys/dev/pci/if_rgereg.h
===
RCS file: /cvs/src/sys/dev/pci/if_rgereg.h,v
retrieving revision 1.5
diff -u -p -u -p -r1.5 if_rgereg.h
--- sys/dev/pci/if_rgereg.h 22 Nov 2020 14:06:22 - 1.5
+++ sys/dev/pci/if_rgereg.h 23 Dec 2020 04:33:27 -
@@ -111,16 +111,24 @@
#define RGE_EECMD_WRITECFG 0xc0
/* Flags for
Re: Un-const pci_attach_args var
On Sun, Nov 29, 2020 at 07:00:53PM -0800, Greg Steuck wrote: > > Kevin Lo writes: > > > ok? > > I guess your goal was consistency (though I'd prefer the opposite > direction). There's one more case: > > ./dev/pci/if_de.c:4401:struct pci_attach_args * const pa = (struct > pci_attach_args *) aux; > > which, funny enough, has been since rev 1.1. Regarding coding style of if_de.c, it seems to prefer making structures const. That's why I didn't touch it. > Thanks > Greg Regards, Kevin
Un-const pci_attach_args var
ok?
Index: sys/dev/pci/berkwdt.c
===
RCS file: /cvs/src/sys/dev/pci/berkwdt.c,v
retrieving revision 1.9
diff -u -p -u -p -r1.9 berkwdt.c
--- sys/dev/pci/berkwdt.c 8 Sep 2017 05:36:52 - 1.9
+++ sys/dev/pci/berkwdt.c 27 Nov 2020 05:51:59 -
@@ -179,7 +179,7 @@ void
berkwdt_attach(struct device *parent, struct device *self, void *aux)
{
struct berkwdt_softc *sc = (struct berkwdt_softc *)self;
- struct pci_attach_args *const pa = (struct pci_attach_args *)aux;
+ struct pci_attach_args *pa = (struct pci_attach_args *)aux;
bus_size_t iosize;
u_int8_t reg;
Index: sys/dev/pci/mbg.c
===
RCS file: /cvs/src/sys/dev/pci/mbg.c,v
retrieving revision 1.30
diff -u -p -u -p -r1.30 mbg.c
--- sys/dev/pci/mbg.c 8 Sep 2017 05:36:52 - 1.30
+++ sys/dev/pci/mbg.c 27 Nov 2020 05:51:59 -
@@ -174,7 +174,7 @@ void
mbg_attach(struct device *parent, struct device *self, void *aux)
{
struct mbg_softc *sc = (struct mbg_softc *)self;
- struct pci_attach_args *const pa = (struct pci_attach_args *)aux;
+ struct pci_attach_args *pa = (struct pci_attach_args *)aux;
struct mbg_time tframe;
pcireg_t memtype;
bus_size_t iosize, iosize2;
Index: sys/dev/pci/pwdog.c
===
RCS file: /cvs/src/sys/dev/pci/pwdog.c,v
retrieving revision 1.10
diff -u -p -u -p -r1.10 pwdog.c
--- sys/dev/pci/pwdog.c 8 Sep 2017 05:36:52 - 1.10
+++ sys/dev/pci/pwdog.c 27 Nov 2020 05:51:59 -
@@ -66,7 +66,7 @@ void
pwdog_attach(struct device *parent, struct device *self, void *aux)
{
struct pwdog_softc *pwdog = (struct pwdog_softc *)self;
- struct pci_attach_args *const pa = (struct pci_attach_args *)aux;
+ struct pci_attach_args *pa = (struct pci_attach_args *)aux;
pcireg_t memtype;
bus_size_t iosize;
Index: sys/dev/pci/wdt.c
===
RCS file: /cvs/src/sys/dev/pci/wdt.c,v
retrieving revision 1.24
diff -u -p -u -p -r1.24 wdt.c
--- sys/dev/pci/wdt.c 5 Jan 2020 01:07:59 - 1.24
+++ sys/dev/pci/wdt.c 27 Nov 2020 05:51:59 -
@@ -110,7 +110,7 @@ void
wdt_attach(struct device *parent, struct device *self, void *aux)
{
struct wdt_softc *wdt = (struct wdt_softc *)self;
- struct pci_attach_args *const pa = (struct pci_attach_args *)aux;
+ struct pci_attach_args *pa = (struct pci_attach_args *)aux;
bus_size_t iosize;
/* retrieve the I/O region (BAR2) */
myx(4): add initialization of sc_sff_lock rwlock
Ok? Index: sys/dev/pci/if_myx.c === RCS file: /cvs/src/sys/dev/pci/if_myx.c,v retrieving revision 1.111 diff -u -p -u -p -r1.111 if_myx.c --- sys/dev/pci/if_myx.c17 Jul 2020 03:37:36 - 1.111 +++ sys/dev/pci/if_myx.c26 Nov 2020 06:49:04 - @@ -270,6 +270,8 @@ myx_attach(struct device *parent, struct char part[32]; pcireg_t memtype; + rw_init(>sc_sff_lock, "myxsff"); + sc->sc_pc = pa->pa_pc; sc->sc_tag = pa->pa_tag; sc->sc_dmat = pa->pa_dmat;
Add PCI ids for Intel 2.5Gb adapters
ok? Index: sys/dev/pci/pcidevs === RCS file: /cvs/src/sys/dev/pci/pcidevs,v retrieving revision 1.1942 diff -u -p -u -p -r1.1942 pcidevs --- sys/dev/pci/pcidevs 28 Oct 2020 18:49:03 - 1.1942 +++ sys/dev/pci/pcidevs 16 Nov 2020 05:41:27 - @@ -3485,6 +3485,7 @@ product INTEL I219_LM10 0x0d4e I219-LM product INTEL I219_V10 0x0d4f I219-V product INTEL I219_LM120x0d53 I219-LM product INTEL I219_V12 0x0d55 I219-V +product INTEL I225_IT 0x0d9f I225_IT product INTEL E5V2_HB 0x0e00 E5 v2 Host product INTEL E5V2_PCIE_1 0x0e01 E5 v2 PCIE product INTEL E5V2_PCIE_2 0x0e02 E5 v2 PCIE @@ -3773,6 +3774,11 @@ product INTEL 82441FX0x1237 82441FX product INTEL 82380AB 0x123c 82380AB Mobile ISA product INTEL 82380FB 0x124b 82380FB Mobile product INTEL 82439HX 0x1250 82439HX +product INTEL I226_LM 0x125b I226-LM +product INTEL I226_V 0x125c I226-V +product INTEL I226_IT 0x125d I226-IT +product INTEL I221_V 0x125e I221-V +product INTEL I226_BLANK_NVM 0x125f I226 product INTEL 82806AA 0x1360 82806AA product INTEL 82870P2_PPB 0x1460 82870P2 PCIX-PCIX product INTEL 82870P2_IOXAPIC 0x1461 82870P2 IOxAPIC @@ -3885,11 +3891,16 @@ product INTEL I219_V9 0x15e2 I219-V product INTEL I219_LM5 0x15e3 I219-LM product INTEL X550EM_A_1G_T0x15e4 X553 SGMII product INTEL X550EM_A_1G_T_L 0x15e5 X553 SGMII +product INTEL I225_LM 0x15f2 I225-LM +product INTEL I225_V 0x15f3 I225-V product INTEL I219_LM150x15f4 I219-LM +product INTEL I220_V 0x15f7 I220-V +product INTEL I225_I 0x15f8 I225-I product INTEL I219_LM140x15f9 I219-LM product INTEL I219_V14 0x15fa I219-V product INTEL I219_LM130x15fb I219-LM product INTEL I219_V13 0x15fc I219-V +product INTEL I225_BLANK_NVM 0x15fd I225 product INTEL CORE5G_H_PCIE_X160x1601 Core 5G PCIE product INTEL CORE5G_M_GT1_1 0x1602 HD Graphics product INTEL CORE5G_THERM 0x1603 Core 5G Thermal @@ -4723,6 +4734,8 @@ product INTEL E5V3_SAD_1 0x2ffc E5 v3 SA product INTEL E5V3_SAD_2 0x2ffd E5 v3 SAD product INTEL E5V3_SAD_3 0x2ffe E5 v3 SAD product INTEL RCU320x3092 RCU32 I2O RAID +product INTEL I225_K 0x3100 I225-K +product INTEL I225_K2 0x3101 I225-K2 product INTEL 3124 0x3124 3124 SATA product INTEL WL_3165_10x3165 Dual Band Wireless AC 3165 product INTEL WL_3165_20x3166 Dual Band Wireless AC 3165 @@ -5177,6 +5190,7 @@ product INTEL EP80579_LAN_3 0x5048 EP80 product INTEL EP80579_LAN_60x5049 EP80579 LAN product INTEL 80960RD 0x5200 i960 RD product INTEL PRO_100_SERVER 0x5201 PRO 100 Server +product INTEL I225_LMVP0x5502 I225_LMVP product INTEL QEMU_NVME0x5845 QEMU NVM Express Controller product INTEL CORE7G_S_GT1 0x5902 HD Graphics 610 product INTEL CORE7G_U_HB 0x5904 Core 7G Host
cap_mkdb: remove igetnext prototype for the function does not exist
ok? Index: usr.bin/cap_mkdb/cap_mkdb.c === RCS file: /cvs/src/usr.bin/cap_mkdb/cap_mkdb.c,v retrieving revision 1.24 diff -u -p -u -p -r1.24 cap_mkdb.c --- usr.bin/cap_mkdb/cap_mkdb.c 28 Jun 2019 14:20:40 - 1.24 +++ usr.bin/cap_mkdb/cap_mkdb.c 15 Sep 2020 03:35:42 - @@ -49,8 +49,6 @@ voiddb_build(char **); voiddounlink(void); voidusage(void); -int igetnext(char **, char **); -int main(int, char *[]); DB *capdbp; int verbose;
Re: sdmmc(4): add UHS-I support
On Mon, Aug 17, 2020 at 12:57:58PM +0200, Mark Kettenis wrote: > > > Date: Sun, 16 Aug 2020 19:32:03 +0200 (CEST) > > From: Mark Kettenis > > > > The diff below adds support for higher speeds as supported by UHS-I SD > > cards to the generic sdmmc(4) layer. The diff in itself does not > > enable the use of those modes. That needs separate changes to the > > SD/MMC controller drivers. I have such a diff for amlmmc(4) that > > allows me to use SDR50 mode. > > > > However, to make sure this diff doesn't break existing lower speed > > modes I'd appreciate tests on a variety of hardware. So if sdmmc(4) > > shows up in your dmesg, please test this by exercising your (u)SD or > > (e)MMC cards. > > > > Thanks, > > > > Mark > > Previous diff didn't build properly on amd64. Here is a new diff. Tested on the GPD Pocket, no problems seen. OpenBSD 6.7-current (GENERIC.MP) #0: Tue Aug 18 16:08:43 CST 2020 ke...@gpdpocket.kevlo.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8477282304 (8084MB) avail mem = 8213426176 (7832MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.0 @ 0x7b8de000 (51 entries) bios0: vendor American Megatrends Inc. version "5.11" date 08/07/2017 bios0: Default string Default string acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S4 S5 acpi0: tables DSDT FACP APIC FPDT FIDT MCFG SSDT SSDT SSDT UEFI SSDT HPET SSDT SSDT SSDT LPIT BCFG PRAM BGRT TPM2 CSRT WDAT SSDT SSDT SSDT acpi0: wakeup devices acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Atom(TM) x7-Z8750 CPU @ 1.60GHz, 1600.40 MHz, 06-4c-04 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN cpu0: 1MB 64b/line 16-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 79MHz cpu0: mwait min=64, max=64, C-substates=0.2.0.0.0.0.3.3, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Atom(TM) x7-Z8750 CPU @ 1.60GHz, 1599.94 MHz, 06-4c-04 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN cpu1: 1MB 64b/line 16-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Atom(TM) x7-Z8750 CPU @ 1.60GHz, 1599.96 MHz, 06-4c-04 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN cpu2: 1MB 64b/line 16-way L2 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Atom(TM) x7-Z8750 CPU @ 1.60GHz, 1599.95 MHz, 06-4c-04 cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN cpu3: 1MB 64b/line 16-way L2 cache cpu3: smt 0, core 3, package 0 ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 115 pins acpimcfg0 at acpi0 acpimcfg0: addr 0xe000, bus 0-255 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 1 (RP01) acpiprt2 at acpi0: bus -1 (RP02) acpiprt3 at acpi0: bus -1 (RP03) acpiprt4 at acpi0: bus -1 (RP04) acpicpu0 at acpi0: C3(10@1000 mwait.1@0x64), C2(10@500 mwait.1@0x58), C1(1000@1 mwait.1), PSS acpicpu1 at acpi0: C3(10@1000 mwait.1@0x64), C2(10@500 mwait.1@0x58), C1(1000@1 mwait.1), PSS acpicpu2 at acpi0: C3(10@1000 mwait.1@0x64), C2(10@500 mwait.1@0x58), C1(1000@1 mwait.1), PSS acpicpu3 at acpi0: C3(10@1000 mwait.1@0x64), C2(10@500 mwait.1@0x58), C1(1000@1 mwait.1), PSS acpipwrres0 at acpi0: ID3C, resource for ISP3 acpipwrres1 at acpi0: WWPR, resource for HS03, MDM1 acpipwrres2 at acpi0: WWPR, resource for HS13, MDM1 acpipwrres3 at acpi0: WWPR, resource for SSC1, MDM3 acpipwrres4 at acpi0: WWPR, resource for SSCW, MDM3 acpipwrres5 at acpi0: WWPR, resource for HSC1, MDM2 acpipwrres6 at acpi0: WWPR, resource for HSC3, MDM4 acpipwrres7 at acpi0: CLK3, resource for RTK1, RTKA
Improve ure(4) performance
Hi,
Jonathon Fletcher has been helping get the better performance out of ure(4).
I ran the tcpbench with ure (RTL8156) for 5 minutes:
71538432760 bytes sent over 300.999 seconds
bandwidth min/avg/max/std-dev = 12.071/1901.448/1947.873/135.283 Mbps
A big thanks to Jonathon for his hard work.
ok?
Index: sys/dev/usb/if_ure.c
===
RCS file: /cvs/src/sys/dev/usb/if_ure.c,v
retrieving revision 1.16
diff -u -p -u -p -r1.16 if_ure.c
--- sys/dev/usb/if_ure.c10 Jul 2020 13:26:41 - 1.16
+++ sys/dev/usb/if_ure.c21 Jul 2020 05:37:45 -
@@ -117,11 +117,13 @@ void ure_miibus_writereg(struct device
void ure_lock_mii(struct ure_softc *);
void ure_unlock_mii(struct ure_softc *);
-inture_encap(struct ure_softc *, struct mbuf *);
+inture_encap_txpkt(struct mbuf *, char *, uint32_t);
+inture_encap_xfer(struct ifnet *, struct ure_softc *, struct
ure_chain *);
void ure_rxeof(struct usbd_xfer *, void *, usbd_status);
void ure_txeof(struct usbd_xfer *, void *, usbd_status);
-inture_rx_list_init(struct ure_softc *);
-inture_tx_list_init(struct ure_softc *);
+inture_xfer_list_init(struct ure_softc *, struct ure_chain *,
+ uint32_t, int);
+void ure_xfer_list_free(struct ure_softc *, struct ure_chain *, int);
void ure_tick_task(void *);
void ure_tick(void *);
@@ -625,12 +627,36 @@ void
ure_watchdog(struct ifnet *ifp)
{
struct ure_softc*sc = ifp->if_softc;
+ struct ure_chain*c;
+ usbd_status err;
+ int i, s;
+
+ ifp->if_timer = 0;
if (usbd_is_dying(sc->ure_udev))
return;
+ if ((ifp->if_flags & (IFF_RUNNING|IFF_UP)) != (IFF_RUNNING|IFF_UP))
+ return;
+
+ sc = ifp->if_softc;
+ s = splnet();
+
ifp->if_oerrors++;
- printf("%s: watchdog timeout\n", sc->ure_dev.dv_xname);
+ DPRINTF(("watchdog timeout\n"));
+
+ for (i = 0; i < URE_TX_LIST_CNT; i++) {
+ c = >ure_cdata.ure_tx_chain[i];
+ if (ml_len(>uc_mbuf_list) > 0) {
+ usbd_get_xfer_status(c->uc_xfer, NULL, NULL, NULL,
+ );
+ ure_txeof(c->uc_xfer, c, err);
+ }
+ }
+
+ if (ifq_is_oactive(>if_snd))
+ ifq_restart(>if_snd);
+ splx(s);
}
void
@@ -653,18 +679,26 @@ ure_init(void *xsc)
else
ure_rtl8153_nic_reset(sc);
- if (ure_rx_list_init(sc) == ENOBUFS) {
+ if (ure_xfer_list_init(sc, sc->ure_cdata.ure_rx_chain,
+ sc->ure_rxbufsz, URE_RX_LIST_CNT) == ENOBUFS) {
printf("%s: rx list init failed\n", sc->ure_dev.dv_xname);
splx(s);
return;
}
- if (ure_tx_list_init(sc) == ENOBUFS) {
+ if (ure_xfer_list_init(sc, sc->ure_cdata.ure_tx_chain,
+ sc->ure_txbufsz, URE_TX_LIST_CNT) == ENOBUFS) {
printf("%s: tx list init failed\n", sc->ure_dev.dv_xname);
splx(s);
return;
}
+ /* Initialize the SLIST we are using for the multiple tx buffers */
+ SLIST_INIT(>ure_cdata.ure_tx_free);
+ for (i = 0; i < URE_TX_LIST_CNT; i++)
+ SLIST_INSERT_HEAD(>ure_cdata.ure_tx_free,
+ >ure_cdata.ure_tx_chain[i], ure_list);
+
/* Set MAC address. */
ure_write_1(sc, URE_PLA_CRWECR, URE_MCU_TYPE_PLA, URE_CRWECR_CONFIG);
ure_write_mem(sc, URE_PLA_IDR, URE_MCU_TYPE_PLA | URE_BYTE_EN_SIX_BYTES,
@@ -739,9 +773,9 @@ ure_init(void *xsc)
/* Start up the receive pipe. */
for (i = 0; i < URE_RX_LIST_CNT; i++) {
- c = >ure_cdata.rx_chain[i];
+ c = >ure_cdata.ure_rx_chain[i];
usbd_setup_xfer(c->uc_xfer, sc->ure_ep[URE_ENDPT_RX],
- c, c->uc_buf, sc->ure_rxbufsz,
+ c, c->uc_buf, c->uc_bufmax,
USBD_SHORT_XFER_OK | USBD_NO_COPY,
USBD_NO_TIMEOUT, ure_rxeof);
usbd_transfer(c->uc_xfer);
@@ -763,34 +797,83 @@ void
ure_start(struct ifnet *ifp)
{
struct ure_softc*sc = ifp->if_softc;
- struct mbuf *m_head = NULL;
-
- if (!(ifp->if_flags & IFF_RUNNING) || ifq_is_oactive(>if_snd) ||
- !(sc->ure_flags & URE_FLAG_LINK))
+ struct ure_cdata*cd = >ure_cdata;
+ struct ure_chain*c;
+ struct mbuf *m = NULL;
+ uint32_t new_buflen;
+ int s, mlen;
+
+ if (!(sc->ure_flags & URE_FLAG_LINK) ||
+ (ifp->if_flags & (IFF_RUNNING|IFF_UP)) !=
+ (IFF_RUNNING|IFF_UP)) {
return;
+ }
+
+ s = splnet();
-
rge(4): support for Realtek RTL8125B
Hi,
The following diff adds Realtek RTL8125B support to rge(4) and uses
if_rxring to manage the number of filled slots on the rx ring.
Tested with the TP-LINK TL-NG421 adapter.
Index: share/man/man4/pci.4
===
RCS file: /cvs/src/share/man/man4/pci.4,v
retrieving revision 1.381
diff -u -p -u -p -r1.381 pci.4
--- share/man/man4/pci.419 Apr 2020 09:27:44 - 1.381
+++ share/man/man4/pci.417 Jul 2020 07:49:12 -
@@ -251,7 +251,7 @@ AMD PCnet-PCI 10/100 Ethernet device
.It Xr re 4
Realtek 8139C+/8169/816xS/811xS/8168/810xE 10/100/Gigabit Ethernet device
.It Xr rge 4
-Realtek 8125 PCI Express 2.5Gb Ethernet device
+Realtek 8125/8125B PCI Express 2.5Gb Ethernet device
.It Xr rl 4
Realtek 8129/8139 10/100 Ethernet device
.It Xr se 4
Index: share/man/man4/rge.4
===
RCS file: /cvs/src/share/man/man4/rge.4,v
retrieving revision 1.2
diff -u -p -u -p -r1.2 rge.4
--- share/man/man4/rge.418 Nov 2019 22:09:59 - 1.2
+++ share/man/man4/rge.417 Jul 2020 07:49:12 -
@@ -1,6 +1,6 @@
.\" $OpenBSD: rge.4,v 1.2 2019/11/18 22:09:59 jmc Exp $
.\"
-.\" Copyright (c) 2019 Kevin Lo
+.\" Copyright (c) 2019, 2020 Kevin Lo
.\"
.\" Permission to use, copy, modify, and distribute this software for any
.\" purpose with or without fee is hereby granted, provided that the above
@@ -19,18 +19,19 @@
.Os
.Sh NAME
.Nm rge
-.Nd Realtek 8125 PCI Express 2.5Gb Ethernet device
+.Nd Realtek 8125/8125B PCI Express 2.5Gb Ethernet device
.Sh SYNOPSIS
.Cd "rge* at pci?"
.Sh DESCRIPTION
The
.Nm
driver provides support for PCI Express 2.5Gb Ethernet adapters based
-on the Realtek RTL8125 Ethernet controller, including the following:
+on the Realtek RTL8125 and RTL8125B Ethernet controllers,
+including the following:
.Pp
.Bl -bullet -offset indent -compact
.It
-Realtek RTL8125 2.5GbE Adapter (2500baseT)
+Realtek 8125/8125B 2.5GbE Adapter (2500baseT)
.It
Rivet Networks Killer E3000 Adapter (2500baseT)
.El
Index: sys/dev/pci/if_rge.c
===
RCS file: /cvs/src/sys/dev/pci/if_rge.c,v
retrieving revision 1.4
diff -u -p -u -p -r1.4 if_rge.c
--- sys/dev/pci/if_rge.c10 Jul 2020 13:26:38 - 1.4
+++ sys/dev/pci/if_rge.c17 Jul 2020 07:49:13 -
@@ -1,7 +1,7 @@
/* $OpenBSD: if_rge.c,v 1.4 2020/07/10 13:26:38 patrick Exp $ */
/*
- * Copyright (c) 2019 Kevin Lo
+ * Copyright (c) 2019, 2020 Kevin Lo
*
* Permission to use, copy, modify, and distribute this software for any
* purpose with or without fee is hereby granted, provided that the above
@@ -50,6 +50,13 @@
#include
+#ifdef RGE_DEBUG
+#define DPRINTF(x) do { if (rge_debug > 0) printf x; } while (0)
+int rge_debug = 0;
+#else
+#define DPRINTF(x)
+#endif
+
intrge_match(struct device *, void *, void *);
void rge_attach(struct device *, struct device *, void *);
intrge_intr(void *);
@@ -62,16 +69,22 @@ voidrge_stop(struct ifnet *);
intrge_ifmedia_upd(struct ifnet *);
void rge_ifmedia_sts(struct ifnet *, struct ifmediareq *);
intrge_allocmem(struct rge_softc *);
-intrge_newbuf(struct rge_softc *, int);
+intrge_newbuf(struct rge_softc *);
void rge_discard_rxbuf(struct rge_softc *, int);
-intrge_rx_list_init(struct rge_softc *);
+void rge_rx_list_init(struct rge_softc *);
void rge_tx_list_init(struct rge_softc *);
+void rge_fill_rx_ring(struct rge_softc *);
intrge_rxeof(struct rge_softc *);
intrge_txeof(struct rge_softc *);
void rge_reset(struct rge_softc *);
void rge_iff(struct rge_softc *);
void rge_set_phy_power(struct rge_softc *, int);
void rge_phy_config(struct rge_softc *);
+void rge_phy_config_mac_cfg2(struct rge_softc *);
+void rge_phy_config_mac_cfg3(struct rge_softc *);
+void rge_phy_config_mac_cfg4(struct rge_softc *);
+void rge_phy_config_mac_cfg5(struct rge_softc *);
+void rge_phy_config_mcu(struct rge_softc *, uint16_t);
void rge_set_macaddr(struct rge_softc *, const uint8_t *);
void rge_get_macaddr(struct rge_softc *, uint8_t *);
void rge_hw_init(struct rge_softc *);
@@ -79,6 +92,7 @@ void rge_disable_phy_ocp_pwrsave(struct
void rge_patch_phy_mcu(struct rge_softc *, int);
void rge_add_media_types(struct rge_softc *);
void rge_config_imtype(struct rge_softc *, int);
+void rge_disable_hw_im(struct rge_softc *);
void rge_disable_sim_im(struct rge_softc *);
void rge_setup_sim_im(struct rge_softc *);
void rge_setup_intr(struct rge_softc *, in
Initialize sis_ring_init() 'sis_rx_prod' and 'sis_rx_cons' to 0
ok? Index: sys/dev/pci/if_sis.c === RCS file: /cvs/src/sys/dev/pci/if_sis.c,v retrieving revision 1.137 diff -u -p -u -p -r1.137 if_sis.c --- sys/dev/pci/if_sis.c10 Jul 2020 13:26:38 - 1.137 +++ sys/dev/pci/if_sis.c15 Jul 2020 07:11:47 - @@ -1285,7 +1285,7 @@ sis_ring_init(struct sis_softc *sc) ld->sis_rx_list[i].sis_ctl = 0; } - cd->sis_rx_prod = cd->sis_rx_cons; + cd->sis_rx_prod = cd->sis_rx_cons = 0; if_rxr_init(>sis_rx_ring, 2, SIS_RX_LIST_CNT - 1); sis_fill_rx_ring(sc);
Re: fix ifconfig joinlist width bug
On Sat, Feb 22, 2020 at 06:38:36PM +0100, Stefan Sperling wrote:
>
> This fixes display of hex SSIDs in 'ifconfig joinlist' and prevents a
> negative number being passed to printf on the following line when 'maxlen'
> ends up being capped below the maximum value returned from len_string():
>
> printf("%-*s", maxlen - len, " ");
>
> Hex SSIDs can be as wide as IEEE80211_NWID_LEN * 2 + 2 /* "0x" */
>
> ok?
ok kevlo@
>
> diff c20bd74017ceeadb2db0f78a352ed1f1e2b77c2b /usr/src
> blob - e1dc9dbb07bf109c3ec7f5fd4d851a7dbb5692f1
> file + sbin/ifconfig/ifconfig.c
> --- sbin/ifconfig/ifconfig.c
> +++ sbin/ifconfig/ifconfig.c
> @@ -2571,16 +2571,14 @@ join_status(void)
>
> maxlen = 0;
> for (i = 0; i < ja.ja_nodes; i++) {
> len = len_string(jn[i].i_nwid, jn[i].i_len);
> if (len > maxlen)
> maxlen = len;
> }
> - if (maxlen > IEEE80211_NWID_LEN)
> - maxlen = IEEE80211_NWID_LEN - 1;
>
> for (i = 0; i < ja.ja_nodes; i++) {
> printf("\t ");
> if (jn[i].i_len > IEEE80211_NWID_LEN)
> jn[i].i_len = IEEE80211_NWID_LEN;
> len = print_string(jn[i].i_nwid, jn[i].i_len);
> printf("%-*s", maxlen - len, " ");
>
Re: ifconfig man page fix
On Sat, Feb 22, 2020 at 06:40:39PM +0100, Stefan Sperling wrote: > > SSIDs are required to contain printable ASCII only. > Otherwise, they must be specified in hex. > > Let's document this explicitly. ok kevlo@ > diff c20bd74017ceeadb2db0f78a352ed1f1e2b77c2b /usr/src > blob - 3fb0780ba7cf1333894f5c3485a95e71885fbd6d > file + sbin/ifconfig/ifconfig.8 > --- sbin/ifconfig/ifconfig.8 > +++ sbin/ifconfig/ifconfig.8 > @@ -972,8 +972,9 @@ list if they are found during a scan. > .Pp > The > .Ar id > -can either be any text string up to 32 characters in length, > -or a series of hexadecimal digits up to 64 digits. > +can either be a printable ASCII string up to 32 characters in length, > +or a series of hexadecimal digits up to 64 digits preceded by > +.Dq 0x . > If > .Ar id > is the empty string > @@ -1077,6 +1078,12 @@ Remove specified flag. > .It Cm nwid Ar id > Connect to the network with NWID/ESSID > .Ar id . > +The > +.Ar id > +can either be a printable ASCII string up to 32 characters in length, > +or a series of hexadecimal digits up to 64 digits preceded by > +.Dq 0x . > +.Pp > Unlike > .Cm join , > the >
Enable rge(4) on arm64
Hi, I'd like to enable rge(4) on arm64. Tested on rockpro64: https://0x0.st/iztI.txt ok? Index: sys/arch/arm64/conf/GENERIC === RCS file: /cvs/src/sys/arch/arm64/conf/GENERIC,v retrieving revision 1.140 diff -u -p -u -p -r1.140 GENERIC --- sys/arch/arm64/conf/GENERIC 26 Jan 2020 06:20:30 - 1.140 +++ sys/arch/arm64/conf/GENERIC 31 Jan 2020 06:56:40 - @@ -232,6 +232,7 @@ mcx*at pci? # Mellanox ConnectX-4/5 mskc* at pci? # Marvell Yukon-2 msk* at mskc?# each port of above re*at pci? # Realtek 8169/8169S/8110S +rge* at pci? # Realtek 8125 # PCI SCSI ahci* at pci? flags 0x# AHCI SATA controllers Index: sys/arch/arm64/conf/RAMDISK === RCS file: /cvs/src/sys/arch/arm64/conf/RAMDISK,v retrieving revision 1.109 diff -u -p -u -p -r1.109 RAMDISK --- sys/arch/arm64/conf/RAMDISK 3 Dec 2019 09:12:46 - 1.109 +++ sys/arch/arm64/conf/RAMDISK 31 Jan 2020 06:56:41 - @@ -208,6 +208,7 @@ mcx*at pci? # Mellanox ConnectX-4/5 mskc* at pci? # Marvell Yukon-2 msk* at mskc?# each port of above re*at pci? # Realtek 8169/8169S/8110S +rge* at pci? # Realtek 8125 # PCI SCSI ahci* at pci? flags 0x# AHCI SATA controllers
Re: ublink(4), led(4) and ledctl(1)
On Fri, Dec 13, 2019 at 10:34:59PM +0100, Patrick Wildt wrote: > > Hi, > > I have a ThingM blink(1) USB RGB device that shows up as uhid(4). > The tooling is "interesting", especially with all those libusb and > HID libraries doing the abstraction. This introduces ublink(4), a > dedicated kernel driver for that device. There are two LEDs on the > device, which can be modified seperately. The firmware is impress- > ive and provides features like playing sequences and adjusting how > long it should take to fade from one colour to another. Obviously > this also increases the complexity of the tools involved to toggle > those RGB LEDs. Thus, the driver is kept simple (for now). > > In addition to providing a way to set RGB LEDs, we can also use it > as a watchdog. If we don't "tickle" it in a specific timeframe it > will play a (unless otherwise programmed) random sequence, which for > instance can be used to see that the machine has paniced. This has > been quite useful while debugging the USB stack, because once the > magic sequence started you know that you're in deep trouble. All > other features are unimplemented. Gamma correction would be nice > to have. > > Since there is no abstraction layer for LEDs yet, this also intro- > duces led(4), which attaches to ublink(4), and provides /dev/ledX. > > uhidev1 at uhub0 port 3 configuration 1 interface 0 "ThingM blink(1) mk2" rev > 2.00/0.02 addr 2 > uhidev1: iclass 3/0, 1 report id > ublink0 at uhidev1 reportid 1 > led0 at ublink0: 2 LEDs > > led(4) can be improved even further. We can attach the ThinkPad > LEDs to it to control it. There are also plenty of mouses that > have controllable RGBs. We could add "human readable descrip- > tions", for instance "upper side LED" or "docking station LED", > so that users can find out more easily which LED they have to > toggle. A fading or blinking mechanism, including hardware off- > loading, can probably be added as well. > > To be able to control those devices, there's ledctl(1), a simple > program that can turn on/off /dev/ledX devices and also set RGB > colours. > > I only did the MAKEDEV stuff for amd64, and also there are no > manpages yet. Also I haven't run it through make build yet, > sorry. And I don't often do userland tools, so feel free to > let me know how to improve it. I tested with my ThingM blink(1) mk2: uhidev2 at uhub3 port 4 configuration 1 interface 0 "ThingM blink(1) mk2" rev 2.00/0.02 addr 4 uhidev2: iclass 3/0, 1 report id ublink0 at uhidev2 reportid 1 led0 at ublink0: 2 LEDs Turning the LED on or off, and set it to blue (ledctl ff), all work for me. > Thanks, > Patrick Kevin
ure(4): add preliminary support for RTL8156
Hi,
This diff adds preliminary support for RTL8156 to ure(4).
Tested with the Planex USB-LAN2500R.
Index: share/man/man4/ure.4
===
RCS file: /cvs/src/share/man/man4/ure.4,v
retrieving revision 1.6
diff -u -p -u -p -r1.6 ure.4
--- share/man/man4/ure.429 Aug 2019 08:55:05 - 1.6
+++ share/man/man4/ure.43 Dec 2019 08:29:40 -
@@ -31,7 +31,7 @@
.Os
.Sh NAME
.Nm ure
-.Nd RealTek RTL8152/RTL8153/RTL8153B 10/100/Gigabit USB Ethernet device
+.Nd RealTek RTL8152/RTL8153/RTL8153B/RTL8156 10/100/Gigabit/2.5Gb USB Ethernet
device
.Sh SYNOPSIS
.Cd "ure* at uhub?"
.Cd "rgephy* at mii?"
@@ -40,12 +40,13 @@
The
.Nm
driver provides support for USB Ethernet adapters based on the RealTek
-RTL8152, RTL8153 and RTL8153B chipsets.
+RTL8152, RTL8153, RTL8153B and RTL8156 chipsets.
.Pp
The RTL8152 contains an integrated Fast Ethernet MAC, which supports
both 10 and 100Mbps speeds in either full or half duplex.
The RTL8153 and RTL8153B have Gigabit Ethernet MACs and additionally
support 1000Mbps speeds.
+NICs based on the RTL8156 are capable of 10, 100, 1000 and 2500Mbps operation.
.Pp
For more information on configuring this device, see
.Xr ifconfig 8 .
Index: share/man/man4/usb.4
===
RCS file: /cvs/src/share/man/man4/usb.4,v
retrieving revision 1.197
diff -u -p -u -p -r1.197 usb.4
--- share/man/man4/usb.429 Aug 2019 08:55:05 - 1.197
+++ share/man/man4/usb.43 Dec 2019 08:29:40 -
@@ -128,7 +128,7 @@ SMSC LAN95xx 10/100 USB Ethernet device
.It Xr udav 4
Davicom DM9601 10/100 USB Ethernet device
.It Xr ure 4
-RealTek RTL8152/RTL8153/RTL8153B 10/100/Gigabit USB Ethernet device
+RealTek RTL8152/RTL8153/RTL8153B/RTL8156 10/100/Gigabit/2.5Gb USB Ethernet
device
.It Xr url 4
Realtek RTL8150L 10/100 USB Ethernet device
.It Xr urndis 4
Index: sys/dev/usb/if_ure.c
===
RCS file: /cvs/src/sys/dev/usb/if_ure.c,v
retrieving revision 1.12
diff -u -p -u -p -r1.12 if_ure.c
--- sys/dev/usb/if_ure.c29 Aug 2019 14:04:48 - 1.12
+++ sys/dev/usb/if_ure.c3 Dec 2019 08:29:41 -
@@ -50,6 +50,7 @@
#include
#include
+#include
#include
#include
@@ -73,7 +74,8 @@ int uredebug = 0;
const struct usb_devno ure_devs[] = {
{ USB_VENDOR_LENOVO, USB_PRODUCT_LENOVO_DOCK_ETHERNET },
{ USB_VENDOR_REALTEK, USB_PRODUCT_REALTEK_RTL8152 },
- { USB_VENDOR_REALTEK, USB_PRODUCT_REALTEK_RTL8153 }
+ { USB_VENDOR_REALTEK, USB_PRODUCT_REALTEK_RTL8153 },
+ { USB_VENDOR_REALTEK, USB_PRODUCT_REALTEK_RTL8156 }
};
inture_match(struct device *, void *, void *);
@@ -107,6 +109,7 @@ voidure_init(void *);
void ure_stop(struct ure_softc *);
void ure_start(struct ifnet *);
void ure_reset(struct ure_softc *);
+void ure_watchdog(struct ifnet *);
void ure_miibus_statchg(struct device *);
inture_miibus_readreg(struct device *, int, int);
@@ -125,6 +128,9 @@ voidure_tick(void *);
inture_ifmedia_upd(struct ifnet *);
void ure_ifmedia_sts(struct ifnet *, struct ifmediareq *);
+void ure_add_media_types(struct ure_softc *);
+void ure_link_state(struct ure_softc *);
+inture_get_link_status(struct ure_softc *);
void ure_iff(struct ure_softc *);
void ure_rxvlan(struct ure_softc *);
inture_ioctl(struct ifnet *, u_long, caddr_t);
@@ -379,7 +385,57 @@ ure_ifmedia_upd(struct ifnet *ifp)
{
struct ure_softc*sc = ifp->if_softc;
struct mii_data *mii = >ure_mii;
- int err;
+ struct ifmedia *ifm = >ure_ifmedia;
+ int anar, gig, err, reg;
+
+ if (sc->ure_flags & URE_FLAG_8156) {
+ if (IFM_TYPE(ifm->ifm_media) != IFM_ETHER)
+ return (EINVAL);
+
+ reg = ure_ocp_reg_read(sc, 0xa5d4);
+ reg &= ~URE_ADV_2500TFDX;
+
+ anar = gig = 0;
+ switch (IFM_SUBTYPE(ifm->ifm_media)) {
+ case IFM_AUTO:
+ anar |= ANAR_TX_FD | ANAR_TX | ANAR_10_FD | ANAR_10;
+ gig |= GTCR_ADV_1000TFDX | GTCR_ADV_1000THDX;
+ reg |= URE_ADV_2500TFDX;
+ break;
+ case IFM_2500_T:
+ anar |= ANAR_TX_FD | ANAR_TX | ANAR_10_FD | ANAR_10;
+ gig |= GTCR_ADV_1000TFDX | GTCR_ADV_1000THDX;
+ reg |= URE_ADV_2500TFDX;
+ ifp->if_baudrate = IF_Mbps(2500);
+ break;
+ case IFM_1000_T:
+ anar |= ANAR_TX_FD | ANAR_TX | ANAR_10_FD | ANAR_10;
+ gig |=
Re: sdhc(4): no 0V one some Intel
On Tue, Nov 19, 2019 at 10:44:54AM +0100, Patrick Wildt wrote: > > Hi, Hi Patrick, > on some GPD Pocket mlarkin@ has the eMMC doesn't come up. One issue > is that we shouldn't go to 0V on some/most(?) Intel controllers. This > only adds it for his machine, but I know that the Appollo Lake versions > might also work if added to this check. But unless verified I'll not > add it. This makes mlarkin@'s machine work, even though it's utterly > slow. That would be the next thing to fix... probably low clocks or > doesn't use 8-bit. James Hastings has a similar diff for Intel Apollo Lake and Gemini Lake: https://www.mail-archive.com/tech@openbsd.org/msg51024.html It did work on my Apollo Lake box. > ok? > > Patrick > > diff --git a/sys/dev/pci/sdhc_pci.c b/sys/dev/pci/sdhc_pci.c > index d1b6688f573..dd6bc79c29c 100644 > --- a/sys/dev/pci/sdhc_pci.c > +++ b/sys/dev/pci/sdhc_pci.c > @@ -127,6 +127,11 @@ sdhc_pci_attach(struct device *parent, struct device > *self, void *aux) > PCI_PRODUCT(pa->pa_id) == PCI_PRODUCT_ENE_SDCARD) > sc->sc.sc_flags |= SDHC_F_NOPWR0; > > + /* Some Intel controllers break if set to 0V bus power. */ > + if (PCI_VENDOR(pa->pa_id) == PCI_VENDOR_INTEL && > + PCI_PRODUCT(pa->pa_id) == PCI_PRODUCT_INTEL_100SERIES_LP_EMMC) > + sc->sc.sc_flags |= SDHC_F_NOPWR0; > + > /* Some RICOH controllers need to be bumped into the right mode. */ > if (PCI_VENDOR(pa->pa_id) == PCI_VENDOR_RICOH && > (PCI_PRODUCT(pa->pa_id) == PCI_PRODUCT_RICOH_R5U822 || >
re(4): set isr to the correct value
Hi, This diff sets isr to the correct value (sc->rl_intrs). While here don't assign ifp twice in the same function. Tested with: re0 at pci2 dev 0 function 0 "Realtek 8168" rev 0x15: RTL8168H/8111H (0x5400), msi, address d8:cb:8a:xx:xx:xx re0 at pci3 dev 0 function 0 "Realtek 8168" rev 0x0c: RTL8168G/8111G (0x4c00), msi, address 30:9c:23:xx:x:xx ok? Index: sys/dev/ic/re.c === RCS file: /cvs/src/sys/dev/ic/re.c,v retrieving revision 1.202 diff -u -p -u -p -r1.202 re.c --- sys/dev/ic/re.c 19 Jun 2017 09:36:27 - 1.202 +++ sys/dev/ic/re.c 18 Nov 2019 06:59:26 - @@ -1416,8 +1416,6 @@ re_txeof(struct rl_softc *sc) unsigned intidx; int free = 0; - ifp = >sc_arpcom.ac_if; - prod = sc->rl_ldata.rl_txq_prodidx; cons = sc->rl_ldata.rl_txq_considx; @@ -1955,7 +1953,7 @@ re_init(struct ifnet *ifp) * Enable interrupts. */ re_setup_intr(sc, 1, sc->rl_imtype); - CSR_WRITE_2(sc, RL_ISR, sc->rl_imtype); + CSR_WRITE_2(sc, RL_ISR, sc->rl_intrs); /* Start RX/TX process. */ CSR_WRITE_4(sc, RL_MISSEDPKT, 0);
Re: Support for Realtek RTL8125 2.5Gb Ethernet controller
On Mon, Nov 18, 2019 at 07:08:33AM +1000, Jonathan Matthew wrote: > > On Fri, Nov 15, 2019 at 03:44:24PM +0800, Kevin Lo wrote: > > Hi, > > > > The following diff adds support for Realtek RTL8125 chip. > > Tested with Syba SD-PEX24065. > > > > Test reports and OKs are welcome. > > I don't have hardware to test with, but I've read through this and it looks > good to me. One thing I'd suggest is using if_rxring to manage the number of > filled slots on the rx ring rather than always keeping it full. dwge(4) is a > good example of how to use it. Thanks for the review and suggestions. I'll switch to use the interface receive ring API. Regards, Kevin
Re: iwm: support 9260 devices
On Sat, Nov 16, 2019 at 10:01:44PM -0800, Philip Guenther wrote: > > On Sat, Nov 16, 2019 at 8:19 AM Stefan Sperling wrote: > > > On Sat, Nov 16, 2019 at 04:51:44PM +0100, Stefan Sperling wrote: > > > This diff adds support for iwm(4) 9260 devices and hopefully 9560 > > > devices as well but I have not yet had time to test those. > > > > > > Joint work with patrick@. Some parts were lifted from FreeBSD. > > > > > > If you have the followng device in pcidump it should at least get > > > an IP address from DHCP and be able to ping: > > > 4:0:0: Intel Dual Band Wireless-AC 9260 > > > 0x: Vendor ID: 8086, Product ID: 2526 > > > > > > The firmware is not in fw_update yet. > > > In the meantime firmware can be fetched from here: > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/ > > > > > > Copy these files to /etc/firmware as indicated: > > > for 9260: iwlwifi-9260-th-b0-jf-b0-34.ucode -> /etc/firmware/iwm-9260-34 > > > for 9560: iwlwifi-9000-pu-b0-jf-b0-34.ucode -> /etc/firmware/iwm-9000-34 > > > > > > Checks for regressions on already supported devices are also welcome, > > > in which case the firmware isn't needed. > > > > Better diff which fixes an Rx throughput issue which was present in > > the previous diff. > > > Looking good so far on my X1 extreme once I > added PCI_PRODUCT_INTEL_WL_9560_2 next to the _1 lines in if_iwm.c. > Awesome! Also applied jcs and guenther diffs on my X1 Extreme: iwm0 at pci0 dev 20 function 3 "Intel Dual Band Wireless AC 9560" rev 0x10, msi iwm0: hw rev 0x310, fw ver 34.3125811985.0, address 48:f1:7f:xx:xx:xx iwm(4) works perfectly. Thanks, Kevin
Support for Realtek RTL8125 2.5Gb Ethernet controller
Hi, The following diff adds support for Realtek RTL8125 chip. Tested with Syba SD-PEX24065. Test reports and OKs are welcome. Index: share/man/man4/Makefile === RCS file: /cvs/src/share/man/man4/Makefile,v retrieving revision 1.740 diff -u -p -u -p -r1.740 Makefile --- share/man/man4/Makefile 4 Nov 2019 23:53:37 - 1.740 +++ share/man/man4/Makefile 15 Nov 2019 07:24:51 - @@ -62,7 +62,7 @@ MAN= aac.4 abcrtc.4 ac97.4 acphy.4 acrtc pvclock.4 pwdog.4 pwmbl.4 pwmreg.4 \ qla.4 qle.4 qlw.4 qsphy.4 \ radio.4 ral.4 random.4 rdomain.4 rd.4 rdac.4 re.4 rdcphy.4 rgephy.4 \ - ricohrtc.4 rkclock.4 rkdwusb.4 rkgpio.4 rkgrf.4 rkiic.4 \ + rge.4 ricohrtc.4 rkclock.4 rkdwusb.4 rkgpio.4 rkgrf.4 rkiic.4 \ rkpcie.4 rkpinctrl.4 rkpmic.4 rktemp.4 \ rl.4 rlphy.4 route.4 rsu.4 rtsx.4 rum.4 run.4 \ rtfps.4 rtw.4 rtwn.4 safe.4 safte.4 sbus.4 schsio.4 \ Index: share/man/man4/pci.4 === RCS file: /cvs/src/share/man/man4/pci.4,v retrieving revision 1.374 diff -u -p -u -p -r1.374 pci.4 --- share/man/man4/pci.426 Sep 2019 13:09:55 - 1.374 +++ share/man/man4/pci.415 Nov 2019 07:24:51 - @@ -253,6 +253,8 @@ Emulex OneConnect 10Gb Ethernet device AMD PCnet-PCI 10/100 Ethernet device .It Xr re 4 Realtek 8139C+/8169/816xS/811xS/8168/810xE 10/100/Gigabit Ethernet device +.It Xr rge 4 +Realtek 8125 2.5Gb Ethernet device .It Xr rl 4 Realtek 8129/8139 10/100 Ethernet device .It Xr se 4 Index: share/man/man4/rge.4 === RCS file: share/man/man4/rge.4 diff -N share/man/man4/rge.4 --- /dev/null 1 Jan 1970 00:00:00 - +++ share/man/man4/rge.415 Nov 2019 07:24:51 - @@ -0,0 +1,55 @@ +.\" $OpenBSD$ +.\" +.\" Copyright (c) 2019 Kevin Lo +.\" +.\" Permission to use, copy, modify, and distribute this software for any +.\" purpose with or without fee is hereby granted, provided that the above +.\" copyright notice and this permission notice appear in all copies. +.\" +.\" THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES +.\" WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF +.\" MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR +.\" ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES +.\" WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN +.\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF +.\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. +.\" +.Dd $Mdocdate$ +.Dt RGE 4 +.Os +.Sh NAME +.Nm rge +.Nd Realtek 8125 PCI Express 2.5Gb Ethernet device +.Sh SYNOPSIS +.Cd "rge* at pci?" +.Sh DESCRIPTION +The +.Nm +driver provides support for PCI Express 2.5Gb Ethernet adapters based +on the Realtek RTL8125 Ethernet controller, including the following: +.Pp +.Bl -bullet -offset indent -compact +.It +Realtek RTL8125 2.5GbE Adapter (2500baseT) +.It +Rivet Networks Killer E3000 Adapter (2500baseT) +.El +.Sh SEE ALSO +.Xr arp 4 , +.Xr ifmedia 4 , +.Xr intro 4 , +.Xr netintro 4 , +.Xr pci 4 , +.Xr hostname.if 5 , +.Xr ifconfig 8 +.Sh HISTORY +The +.Nm +driver first appeared in +.Ox 6.7 . +.Sh AUTHORS +.An -nosplit +The +.Nm +driver was written by +.An Kevin Lo Aq Mt ke...@openbsd.org . Index: sys/arch/amd64/conf/GENERIC === RCS file: /cvs/src/sys/arch/amd64/conf/GENERIC,v retrieving revision 1.480 diff -u -p -u -p -r1.480 GENERIC --- sys/arch/amd64/conf/GENERIC 26 Sep 2019 12:59:01 - 1.480 +++ sys/arch/amd64/conf/GENERIC 15 Nov 2019 07:24:52 - @@ -513,6 +513,7 @@ bge*at pci? # Broadcom BCM57xx (aka bnx* at pci? # Broadcom BCM5706/5708 GigE re*at pci? # Realtek 8169/8169S/8110S re*at cardbus? # Realtek 8169/8169S/8110S +rge* at pci? # Realtek 8125 stge* at pci? # Sundance TC9021 GigE #lge* at pci? # Level1 LXT1001 GigE hme* at pci? # Sun Happy Meal Index: sys/arch/i386/conf/GENERIC === RCS file: /cvs/src/sys/arch/i386/conf/GENERIC,v retrieving revision 1.844 diff -u -p -u -p -r1.844 GENERIC --- sys/arch/i386/conf/GENERIC 28 May 2019 08:44:27 - 1.844 +++ sys/arch/i386/conf/GENERIC 15 Nov 2019 07:24:52 - @@ -576,6 +576,7 @@ bge*at pci? # Broadcom BCM57xx (aka bnx* at pci? # Broadcom BCM5706/5708 GigE re*at pci? # Realtek 8169/8169S/8110S re*at cardbus?
Re: iwm: fix support for 3168 devices
On Mon, Nov 11, 2019 at 06:33:39PM +0200, Stefan Sperling wrote: > > On Mon, Nov 11, 2019 at 10:19:12AM +0800, Kevin Lo wrote: > > On Sat, Nov 09, 2019 at 01:01:39PM +0200, Stefan Sperling wrote: > > > > > > This diff makes 3168 devices actually work with iwm(4). > > > These devices have never worked right since the driver just threw > > > errors when trying to load firmware. > > > > Indeed. The 3168 device didn't work for me (for example, ifconfig iwm0 scan > > returns empty results) until your diff is applied. > > The previous diff broke 7260/7265 devices. I made a mistake which resulted > in channel data structures not being initialized on those devices which > resulted in "panic: iwm0: bogus channel pointer" during boot. > > Problem fixed with the diff below. This diff still works on my msi Cubi 3 Silent. > ok? ok kevlo@
Re: iwm: fix support for 3168 devices
On Sat, Nov 09, 2019 at 01:01:39PM +0200, Stefan Sperling wrote: > > This diff makes 3168 devices actually work with iwm(4). > These devices have never worked right since the driver just threw > errors when trying to load firmware. Indeed. The 3168 device didn't work for me (for example, ifconfig iwm0 scan returns empty results) until your diff is applied. > Loosely based on FreeBSD r345002 and Linux commit > 44fd09dad5d2b78efbaf623774e561e36cca > > Tested with: > iwm0 at pci4 dev 0 function 0 "Intel Dual Band Wireless-AC 3168" rev 0x10, msi > iwm0: hw rev 0x220, fw ver 29.1654887522.0, address xx:xx:xx:xx:xx:xx Tested with: iwm0 at pci3 dev 0 function 0 "Intel Dual Band Wireless-AC 3168" rev 0x10, msi iwm0: hw rev 0x220, fw ver 29.1654887522.0, address b0:35:9f:xx:xx:xx > Please also test on any other types of iwm devices to ensure that this > won't break anything. I also tested with 3165, it works as usual. Thank you, Kevin
Re: iwm: support dynamic queue allocation (DQA)
On Mon, Oct 14, 2019 at 01:51:02PM +0200, Stefan Sperling wrote: > > Newer iwm firmware requires the driver to use a feature known as > dynamic queue allocation (DQA). What matters is that the command queue > index was changed. Newer firmware images have stopped responding to > commands sent with the old command queue index, and this is preventing > us from dropping newer firmware versions into /etc/firmware without > breaking things. > > Some of our existing firmware images already support DQA (*-22 image > files), and some do not (*-16 image files), so we need to support both > modes of operation for now. (Linux has already removed non-DQA code > paths from their iwlwifi driver). > > I have successfully tested this diff on 8265 with our current firmware > image (22.361476.0) as well as a newer -22 firmware image (22.391740.0, > which is *not* in fw_update yet). I have also tested 7265 successfully. > > Tests on 7260 and 8260 devices are still required. > Nothing should change. At this point I am just looking for potential > regressions when using this diff against our current firmware images. > > Reviews and OKs are also welcome. Tested on 3165 with current firmware (16.242414.0), seems to be working fine. iwm0 at pci3 dev 0 function 0 "Intel Dual Band Wireless AC 3165" rev 0x81, msi iwm0: hw rev 0x210, fw ver 16.242414.0, address 08:d4:0c:xx:xx:xx
Argument order fix for MCLGETI
ok?
Index: sys/dev/ic/ti.c
===
RCS file: /cvs/src/sys/dev/ic/ti.c,v
retrieving revision 1.25
diff -u -p -u -p -r1.25 ti.c
--- sys/dev/ic/ti.c 22 Jan 2017 10:17:38 - 1.25
+++ sys/dev/ic/ti.c 25 Sep 2019 08:06:26 -
@@ -576,7 +576,7 @@ ti_newbuf_std(struct ti_softc *sc, int i
sc->ti_cdata.ti_rx_std_map[i] = dmamap;
if (m == NULL) {
- m_new = MCLGETI(NULL, MCLBYTES, NULL, M_DONTWAIT);
+ m_new = MCLGETI(NULL, M_DONTWAIT, NULL, MCLBYTES);
if (m_new == NULL)
return (ENOBUFS);
@@ -695,7 +695,7 @@ ti_newbuf_jumbo(struct ti_softc *sc, int
bus_dmamap_unload(sc->sc_dmatag, dmamap);
if (m == NULL) {
- m_new = MCLGETI(NULL, TI_JUMBO_FRAMELEN, NULL, M_DONTWAIT);
+ m_new = MCLGETI(NULL, M_DONTWAIT, NULL, TI_JUMBO_FRAMELEN);
if (m_new == NULL)
return (ENOBUFS);
Index: sys/dev/pci/if_lge.c
===
RCS file: /cvs/src/sys/dev/pci/if_lge.c,v
retrieving revision 1.73
diff -u -p -u -p -r1.73 if_lge.c
--- sys/dev/pci/if_lge.c22 Jan 2017 10:17:38 - 1.73
+++ sys/dev/pci/if_lge.c25 Sep 2019 08:06:26 -
@@ -626,7 +626,7 @@ lge_newbuf(struct lge_softc *sc, struct
struct mbuf *m_new = NULL;
if (m == NULL) {
- m_new = MCLGETI(NULL, LGE_JLEN, NULL, M_DONTWAIT);
+ m_new = MCLGETI(NULL, M_DONTWAIT, NULL, LGE_JLEN);
if (m_new == NULL)
return (ENOBUFS);
} else {
Index: sys/dev/pci/if_nfe.c
===
RCS file: /cvs/src/sys/dev/pci/if_nfe.c,v
retrieving revision 1.120
diff -u -p -u -p -r1.120 if_nfe.c
--- sys/dev/pci/if_nfe.c8 Sep 2017 05:36:52 - 1.120
+++ sys/dev/pci/if_nfe.c25 Sep 2019 08:06:26 -
@@ -697,7 +697,7 @@ nfe_rxeof(struct nfe_softc *sc)
* old mbuf. In the unlikely case that the old mbuf can't be
* reloaded either, explicitly panic.
*/
- mnew = MCLGETI(NULL, MCLBYTES, NULL, M_DONTWAIT);
+ mnew = MCLGETI(NULL, M_DONTWAIT, NULL, MCLBYTES);
if (mnew == NULL) {
ifp->if_ierrors++;
goto skip;
@@ -1210,7 +1210,7 @@ nfe_alloc_rx_ring(struct nfe_softc *sc,
for (i = 0; i < NFE_RX_RING_COUNT; i++) {
data = >rxq.data[i];
- data->m = MCLGETI(NULL, MCLBYTES, NULL, M_DONTWAIT);
+ data->m = MCLGETI(NULL, M_DONTWAIT, NULL, MCLBYTES);
if (data->m == NULL) {
printf("%s: could not allocate rx mbuf\n",
sc->sc_dev.dv_xname);
Index: sys/dev/pci/if_nge.c
===
RCS file: /cvs/src/sys/dev/pci/if_nge.c,v
retrieving revision 1.92
diff -u -p -u -p -r1.92 if_nge.c
--- sys/dev/pci/if_nge.c22 Jan 2017 10:17:38 - 1.92
+++ sys/dev/pci/if_nge.c25 Sep 2019 08:06:26 -
@@ -962,7 +962,7 @@ nge_newbuf(struct nge_softc *sc, struct
struct mbuf *m_new = NULL;
if (m == NULL) {
- m_new = MCLGETI(NULL, NGE_MCLBYTES, NULL, M_DONTWAIT);
+ m_new = MCLGETI(NULL, M_DONTWAIT, NULL, NGE_MCLBYTES);
if (m_new == NULL)
return (ENOBUFS);
} else {
Re: ure(4): add support for rtl8153b
On Tue, Aug 27, 2019 at 06:48:43AM +0100, Jason McIntyre wrote: > > On Tue, Aug 27, 2019 at 10:50:05AM +0800, Kevin Lo wrote: > > Hi, > > > > The diff below adds support for RTL8153B to ure(4). > > Tested on Totolink u1003. > > > > morning. the changes for ure.4 are fine, but can you adjust the entry in > usb.4 accordingly too, please? Sure, will do, thanks. > thanks, > jmc
Re: ure(4): add support for rtl8153b
On Tue, Aug 27, 2019 at 12:34:55PM +0800, Kevin Lo wrote: > On Tue, Aug 27, 2019 at 10:50:05AM +0800, Kevin Lo wrote: > > > > Hi, > > > > The diff below adds support for RTL8153B to ure(4). > > Tested on Totolink u1003. > > I should mention that it's based on Linux r8152 driver. My bad, should be "study of".
Re: ure(4): add support for rtl8153b
On Tue, Aug 27, 2019 at 10:50:05AM +0800, Kevin Lo wrote: > > Hi, > > The diff below adds support for RTL8153B to ure(4). > Tested on Totolink u1003. I should mention that it's based on Linux r8152 driver.
ure(4): add support for rtl8153b
Hi,
The diff below adds support for RTL8153B to ure(4).
Tested on Totolink u1003.
Index: share/man/man4/ure.4
===
RCS file: /cvs/src/share/man/man4/ure.4,v
retrieving revision 1.5
diff -u -p -u -p -r1.5 ure.4
--- share/man/man4/ure.416 Apr 2017 20:26:34 - 1.5
+++ share/man/man4/ure.427 Aug 2019 02:36:47 -
@@ -31,7 +31,7 @@
.Os
.Sh NAME
.Nm ure
-.Nd RealTek RTL8152/RTL8153 10/100/Gigabit USB Ethernet device
+.Nd RealTek RTL8152/RTL8153/RTL8153B 10/100/Gigabit USB Ethernet device
.Sh SYNOPSIS
.Cd "ure* at uhub?"
.Cd "rgephy* at mii?"
@@ -40,13 +40,12 @@
The
.Nm
driver provides support for USB Ethernet adapters based on the RealTek
-RTL8152 USB Fast Ethernet and RTL8153 USB Gigabit Ethernet controller
-chips.
+RTL8152, RTL8153 and RTL8153B chipsets.
.Pp
The RTL8152 contains an integrated Fast Ethernet MAC, which supports
both 10 and 100Mbps speeds in either full or half duplex.
-The RTL8153 has a Gigabit Ethernet MAC and additionally supports
-1000Mbps speeds.
+The RTL8153 and RTL8153B have Gigabit Ethernet MACs and additionally
+support 1000Mbps speeds.
.Pp
For more information on configuring this device, see
.Xr ifconfig 8 .
Index: sys/dev/usb/if_ure.c
===
RCS file: /cvs/src/sys/dev/usb/if_ure.c,v
retrieving revision 1.10
diff -u -p -u -p -r1.10 if_ure.c
--- sys/dev/usb/if_ure.c2 Nov 2018 21:32:30 - 1.10
+++ sys/dev/usb/if_ure.c27 Aug 2019 02:36:48 -
@@ -1,6 +1,6 @@
/* $OpenBSD: if_ure.c,v 1.10 2018/11/02 21:32:30 jcs Exp $ */
/*-
- * Copyright (c) 2015-2016 Kevin Lo
+ * Copyright (c) 2015, 2016, 2019 Kevin Lo
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -124,13 +124,31 @@ void ure_tick(void *);
inture_ifmedia_upd(struct ifnet *);
void ure_ifmedia_sts(struct ifnet *, struct ifmediareq *);
+void ure_iff(struct ure_softc *);
+void ure_rxvlan(struct ure_softc *);
inture_ioctl(struct ifnet *, u_long, caddr_t);
void ure_rtl8152_init(struct ure_softc *);
void ure_rtl8153_init(struct ure_softc *);
+void ure_rtl8153b_init(struct ure_softc *);
+void ure_rtl8152_nic_reset(struct ure_softc *);
+void ure_rtl8153_nic_reset(struct ure_softc *);
+void ure_rtl8153_phy_status(struct ure_softc *, int);
+void ure_reset_bmu(struct ure_softc *);
void ure_disable_teredo(struct ure_softc *);
-void ure_init_fifo(struct ure_softc *);
-
+#define URE_SETBIT_1(sc, reg, index, x) \
+ ure_write_1(sc, reg, index, ure_read_1(sc, reg, index) | (x))
+#define URE_SETBIT_2(sc, reg, index, x) \
+ ure_write_2(sc, reg, index, ure_read_2(sc, reg, index) | (x))
+#define URE_SETBIT_4(sc, reg, index, x) \
+ ure_write_4(sc, reg, index, ure_read_4(sc, reg, index) | (x))
+
+#define URE_CLRBIT_1(sc, reg, index, x) \
+ ure_write_1(sc, reg, index, ure_read_1(sc, reg, index) & ~(x))
+#define URE_CLRBIT_2(sc, reg, index, x) \
+ ure_write_2(sc, reg, index, ure_read_2(sc, reg, index) & ~(x))
+#define URE_CLRBIT_4(sc, reg, index, x) \
+ ure_write_4(sc, reg, index, ure_read_4(sc, reg, index) & ~(x))
int
ure_ctl(struct ure_softc *sc, uint8_t rw, uint16_t val, uint16_t index,
@@ -166,7 +184,6 @@ int
ure_read_mem(struct ure_softc *sc, uint16_t addr, uint16_t index,
void *buf, int len)
{
-
return (ure_ctl(sc, URE_CTL_READ, addr, index, buf, len));
}
@@ -174,16 +191,15 @@ int
ure_write_mem(struct ure_softc *sc, uint16_t addr, uint16_t index,
void *buf, int len)
{
-
return (ure_ctl(sc, URE_CTL_WRITE, addr, index, buf, len));
}
uint8_t
ure_read_1(struct ure_softc *sc, uint16_t reg, uint16_t index)
{
- uint32_t val;
- uint8_t temp[4];
- uint8_t shift;
+ uint32_tval;
+ uint8_t temp[4];
+ uint8_t shift;
shift = (reg & 3) << 3;
reg &= ~3;
@@ -198,9 +214,9 @@ ure_read_1(struct ure_softc *sc, uint16_
uint16_t
ure_read_2(struct ure_softc *sc, uint16_t reg, uint16_t index)
{
- uint32_t val;
- uint8_t temp[4];
- uint8_t shift;
+ uint32_tval;
+ uint8_t temp[4];
+ uint8_t shift;
shift = (reg & 2) << 3;
reg &= ~3;
@@ -215,7 +231,7 @@ ure_read_2(struct ure_softc *sc, uint16_
uint32_t
ure_read_4(struct ure_softc *sc, uint16_t reg, uint16_t index)
{
- uint8_t temp[4];
+ uint8_t temp[4];
ure_read_mem(sc, reg, index, , 4);
return (UGETDW(temp));
@@ -224,9 +240,9 @@ ure_read_4(struct ure_softc *sc, uint16_
int
ure_write_1(struct ure_softc *sc, uint16_t reg, uint16_t index, uint32_t val)
{
- uint16_t byen;
-
Re: net80211: remove redundant assignment to ic_curmode
On Sun, Aug 25, 2019 at 03:11:52PM +0200, Stefan Sperling wrote: > > This assigment to ic_curmode is redundant because it already occurs > inside ieee80211_setmode(), and channel information in selbs and ni > is equivalent after node_copy(). > > ok? ok kevlo@
remove duplicate definitions of LAPIC_ID_MASK and LAPIC_ID_SHIFT
ok? Index: sys/arch/amd64/include/i82489reg.h === RCS file: /cvs/src/sys/arch/amd64/include/i82489reg.h,v retrieving revision 1.4 diff -u -p -u -p -r1.4 i82489reg.h --- sys/arch/amd64/include/i82489reg.h 21 Jul 2015 04:48:33 - 1.4 +++ sys/arch/amd64/include/i82489reg.h 26 Jul 2019 01:36:01 - @@ -105,8 +105,6 @@ #define LAPIC_ICRHI0x310 /* Int. cmd. RW */ -# define LAPIC_ID_MASK0x0f00 -# define LAPIC_ID_SHIFT 24 #define LAPIC_LVTT 0x320 /* Loc.vec.(timer) RW */ # define LAPIC_LVTT_VEC_MASK 0x00ff Index: sys/arch/i386/include/i82489reg.h === RCS file: /cvs/src/sys/arch/i386/include/i82489reg.h,v retrieving revision 1.4 diff -u -p -u -p -r1.4 i82489reg.h --- sys/arch/i386/include/i82489reg.h 21 Jul 2015 06:19:50 - 1.4 +++ sys/arch/i386/include/i82489reg.h 26 Jul 2019 01:36:01 - @@ -105,8 +105,6 @@ #define LAPIC_ICRHI0x310 /* Int. cmd. RW */ -# define LAPIC_ID_MASK0x0f00 -# define LAPIC_ID_SHIFT 24 #define LAPIC_LVTT 0x320 /* Loc.vec.(timer) RW */ # define LAPIC_LVTT_VEC_MASK 0x00ff
ure and url need ifmedia attribute
ok? Index: sys/dev/usb/files.usb === RCS file: /cvs/src/sys/dev/usb/files.usb,v retrieving revision 1.139 diff -u -p -u -p -r1.139 files.usb --- sys/dev/usb/files.usb 7 Jun 2019 16:06:59 - 1.139 +++ sys/dev/usb/files.usb 9 Jul 2019 01:31:35 - @@ -276,12 +276,12 @@ attachugl at uhub file dev/usb/if_ugl.cugl # Realtek RTL8150L(M) -device url: ether, ifnet, mii +device url: ether, ifnet, mii, ifmedia attach url at uhub file dev/usb/if_url.curl # Realtek RTL8152 -device ure: ether, ifnet, mii +device ure: ether, ifnet, mii, ifmedia attach ure at uhub file dev/usb/if_ure.cure
remove duplicate code
ok?
Index: sys/dev/usb/if_axe.c
===
RCS file: /cvs/src/sys/dev/usb/if_axe.c,v
retrieving revision 1.138
diff -u -p -u -p -r1.138 if_axe.c
--- sys/dev/usb/if_axe.c22 Jan 2017 10:17:39 - 1.138
+++ sys/dev/usb/if_axe.c5 Jul 2019 05:56:19 -
@@ -881,10 +881,6 @@ axe_detach(struct device *self, int flag
sc->axe_dev.dv_xname);
#endif
- if (--sc->axe_refcnt >= 0) {
- /* Wait for processes to go away. */
- usb_detach_wait(>axe_dev);
- }
splx(s);
return (0);
Index: sys/dev/usb/if_axen.c
===
RCS file: /cvs/src/sys/dev/usb/if_axen.c,v
retrieving revision 1.26
diff -u -p -u -p -r1.26 if_axen.c
--- sys/dev/usb/if_axen.c 5 Dec 2018 15:54:58 - 1.26
+++ sys/dev/usb/if_axen.c 5 Jul 2019 05:56:19 -
@@ -778,10 +778,6 @@ axen_detach(struct device *self, int fla
sc->axen_dev.dv_xname);
#endif
- if (--sc->axen_refcnt >= 0) {
- /* Wait for processes to go away. */
- usb_detach_wait(>axen_dev);
- }
splx(s);
return 0;
Index: sys/dev/usb/if_mos.c
===
RCS file: /cvs/src/sys/dev/usb/if_mos.c,v
retrieving revision 1.39
diff -u -p -u -p -r1.39 if_mos.c
--- sys/dev/usb/if_mos.c3 Jul 2018 00:47:49 - 1.39
+++ sys/dev/usb/if_mos.c5 Jul 2019 05:56:19 -
@@ -784,10 +784,6 @@ mos_detach(struct device *self, int flag
sc->mos_dev.dv_xname);
#endif
- if (--sc->mos_refcnt >= 0) {
- /* Wait for processes to go away. */
- usb_detach_wait(>mos_dev);
- }
splx(s);
return (0);
Index: sys/dev/usb/if_mue.c
===
RCS file: /cvs/src/sys/dev/usb/if_mue.c,v
retrieving revision 1.5
diff -u -p -u -p -r1.5 if_mue.c
--- sys/dev/usb/if_mue.c19 Sep 2018 07:47:54 - 1.5
+++ sys/dev/usb/if_mue.c5 Jul 2019 05:56:19 -
@@ -855,10 +855,6 @@ mue_detach(struct device *self, int flag
if_detach(ifp);
}
- if (--sc->mue_refcnt >= 0) {
- /* Wait for processes to go away. */
- usb_detach_wait(>mue_dev);
- }
splx(s);
return (0);
Index: sys/dev/usb/if_smsc.c
===
RCS file: /cvs/src/sys/dev/usb/if_smsc.c,v
retrieving revision 1.32
diff -u -p -u -p -r1.32 if_smsc.c
--- sys/dev/usb/if_smsc.c 25 Aug 2018 17:09:40 - 1.32
+++ sys/dev/usb/if_smsc.c 5 Jul 2019 05:56:19 -
@@ -1118,10 +1118,6 @@ smsc_detach(struct device *self, int fla
sc->sc_dev.dv_xname);
#endif
- if (--sc->sc_refcnt >= 0) {
- /* Wait for processes to go away. */
- usb_detach_wait(>sc_dev);
- }
splx(s);
return (0);
ext2fs: more verbose messages about unsupported ext2fs features
Hi,
It may be useful for users to know which ext2fs features are not supported.
This patch adds more verbose messages mostly based on FreeBSD's r320578.
w/o patch:
ext2fs: unsupported incompat features 0x2c2
w/ patch:
ext2fs: unsupported incompat features: 64bit
Index: sys/ufs/ext2fs/ext2fs.h
===
RCS file: /cvs/src/sys/ufs/ext2fs/ext2fs.h,v
retrieving revision 1.23
diff -u -p -u -p -r1.23 ext2fs.h
--- sys/ufs/ext2fs/ext2fs.h 27 Apr 2016 11:27:24 - 1.23
+++ sys/ufs/ext2fs/ext2fs.h 28 Jun 2019 05:36:15 -
@@ -195,15 +195,25 @@ e2fs_overflow(struct m_ext2fs *fs, off_t
/* compatible/imcompatible features */
#define EXT2F_COMPAT_PREALLOC 0x0001
-#define EXT2F_COMPAT_HASJOURNAL0x0004
+#define EXT2F_COMPAT_IMAGIC_INODES 0x0002
+#define EXT2F_COMPAT_HAS_JOURNAL 0x0004
+#define EXT2F_COMPAT_EXT_ATTR 0x0008
#define EXT2F_COMPAT_RESIZE0x0010
-#define EXT2F_COMPAT_DIRHASHINDEX 0x0020
+#define EXT2F_COMPAT_DIR_INDEX 0x0020
+#define EXT2F_COMPAT_SPARSE_SUPER2 0x0200
-
-#define EXT2F_ROCOMPAT_SPARSESUPER 0x0001
-#define EXT2F_ROCOMPAT_LARGEFILE 0x0002
+#define EXT2F_ROCOMPAT_SPARSE_SUPER0x0001
+#define EXT2F_ROCOMPAT_LARGE_FILE 0x0002
#define EXT2F_ROCOMPAT_BTREE_DIR 0x0004
#define EXT2F_ROCOMPAT_HUGE_FILE 0x0008
+#define EXT2F_ROCOMPAT_GDT_CSUM0x0010
+#define EXT2F_ROCOMPAT_DIR_NLINK 0x0020
+#define EXT2F_ROCOMPAT_EXTRA_ISIZE 0x0040
+#define EXT2F_ROCOMPAT_QUOTA 0x0100
+#define EXT2F_ROCOMPAT_BIGALLOC0x0200
+#define EXT2F_ROCOMPAT_METADATA_CKSUM 0x0400
+#define EXT2F_ROCOMPAT_READONLY0x1000
+#define EXT2F_ROCOMPAT_PROJECT 0x2000
#define EXT2F_INCOMPAT_COMP0x0001
#define EXT2F_INCOMPAT_FTYPE 0x0002
@@ -211,12 +221,58 @@ e2fs_overflow(struct m_ext2fs *fs, off_t
#define EXT2F_INCOMPAT_JOURNAL_DEV 0x0008
#define EXT2F_INCOMPAT_META_BG 0x0010
#define EXT2F_INCOMPAT_EXTENTS 0x0040
+#define EXT2F_INCOMPAT_64BIT 0x0080
+#define EXT2F_INCOMPAT_MMP 0x0100
#define EXT2F_INCOMPAT_FLEX_BG 0x0200
+#define EXT2F_INCOMPAT_EA_INODE0x0400
+#define EXT2F_INCOMPAT_DIRDATA 0x1000
+#define EXT2F_INCOMPAT_CSUM_SEED 0x2000
+#define EXT2F_INCOMPAT_LARGEDIR0x4000
+#define EXT2F_INCOMPAT_INLINE_DATA 0x8000
+#define EXT2F_INCOMPAT_ENCRYPT 0x1
+
+struct ext2_feature {
+ uint32_t mask;
+ const char *name;
+};
+
+static const struct ext2_feature ro_compat[] = {
+ { EXT2F_ROCOMPAT_SPARSE_SUPER, "sparse_super" },
+ { EXT2F_ROCOMPAT_LARGE_FILE,"large_file" },
+ { EXT2F_ROCOMPAT_BTREE_DIR, "btree_dir" },
+ { EXT2F_ROCOMPAT_HUGE_FILE, "huge_file" },
+ { EXT2F_ROCOMPAT_GDT_CSUM, "uninit_bg" },
+ { EXT2F_ROCOMPAT_DIR_NLINK, "dir_nlink" },
+ { EXT2F_ROCOMPAT_EXTRA_ISIZE, "extra_isize" },
+ { EXT2F_ROCOMPAT_QUOTA, "quota" },
+ { EXT2F_ROCOMPAT_BIGALLOC, "bigalloc" },
+ { EXT2F_ROCOMPAT_METADATA_CKSUM,"metadata_csum" },
+ { EXT2F_ROCOMPAT_READONLY, "read-only" },
+ { EXT2F_ROCOMPAT_PROJECT, "project" }
+};
+
+static const struct ext2_feature incompat[] = {
+ { EXT2F_INCOMPAT_COMP, "compression" },
+ { EXT2F_INCOMPAT_FTYPE, "filetype" },
+ { EXT2F_INCOMPAT_RECOVER, "needs_recovery" },
+ { EXT2F_INCOMPAT_JOURNAL_DEV, "journal_dev" },
+ { EXT2F_INCOMPAT_META_BG, "meta_bg" },
+ { EXT2F_INCOMPAT_EXTENTS, "extents" },
+ { EXT2F_INCOMPAT_64BIT, "64bit" },
+ { EXT2F_INCOMPAT_MMP, "mmp" },
+ { EXT2F_INCOMPAT_FLEX_BG, "flex_bg" },
+ { EXT2F_INCOMPAT_EA_INODE, "ea_inode" },
+ { EXT2F_INCOMPAT_DIRDATA, "dirdata" },
+ { EXT2F_INCOMPAT_CSUM_SEED, "metadata_csum_seed" },
+ { EXT2F_INCOMPAT_LARGEDIR, "large_dir" },
+ { EXT2F_INCOMPAT_INLINE_DATA, "inline_data" },
+ { EXT2F_INCOMPAT_ENCRYPT, "encrypt" }
+};
/* features supported in this implementation */
#define EXT2F_COMPAT_SUPP 0x
-#define EXT2F_ROCOMPAT_SUPP(EXT2F_ROCOMPAT_SPARSESUPER | \
-EXT2F_ROCOMPAT_LARGEFILE)
+#define EXT2F_ROCOMPAT_SUPP(EXT2F_ROCOMPAT_SPARSE_SUPER | \
+EXT2F_ROCOMPAT_LARGE_FILE)
#define EXT2F_INCOMPAT_SUPP(EXT2F_INCOMPAT_FTYPE)
#define EXT4F_RO_INCOMPAT_SUPP (EXT2F_INCOMPAT_EXTENTS | \
EXT2F_INCOMPAT_FLEX_BG | \
@@ -258,7 +314,7 @@ struct ext2_gd {
};
/*
- * If the EXT2F_ROCOMPAT_SPARSESUPER flag is
Re: elf(5): mention the ELF machine type EM_AARCH64
On Mon, Jun 17, 2019 at 06:15:16PM +1000, Jonathan Gray wrote: > > On Mon, Jun 17, 2019 at 02:45:28PM +0800, Kevin Lo wrote: > > ok? > > The header also includes EM_PPC64 which isn't documented > (and EM_X86_64 which should probably be kept not documented). Documented EM_PPC64, thanks.
elf(5): mention the ELF machine type EM_AARCH64
ok? Index: share/man/man5/elf.5 === RCS file: /cvs/src/share/man/man5/elf.5,v retrieving revision 1.34 diff -u -p -u -p -r1.34 elf.5 --- share/man/man5/elf.527 Oct 2017 08:36:42 - 1.34 +++ share/man/man5/elf.517 Jun 2019 06:46:19 - @@ -325,6 +325,8 @@ Intel IA-64. AMD64. .It Dv EM_VAX DEC Vax. +.It Dv EM_AARCH64 +ARM 64-bit. .It Dv EM_ALPHA_EXP Compaq [DEC] Alpha with enhanced instruction set. .El
Re: upgt: use timeout_add_msec(9)
On Thu, Jun 13, 2019 at 11:23:55PM +0200, Klemens Nanni wrote: > > Same as with urtw(4) but a tad more obvious: > > /usr/include/dev/usb/if_upgtvar.h > 312:#define UPGT_LED_ACTION_TMP_DUR 100 /* ms */ > > OK? I don't have upgt(4), but it looks good to me. > Index: sys/dev/usb/if_upgt.c > === > RCS file: /cvs/src/sys/dev/usb/if_upgt.c,v > retrieving revision 1.83 > diff -u -p -r1.83 if_upgt.c > --- sys/dev/usb/if_upgt.c 25 Apr 2019 01:52:14 - 1.83 > +++ sys/dev/usb/if_upgt.c 13 Jun 2019 21:18:37 - > @@ -2014,7 +2014,6 @@ upgt_set_led(struct upgt_softc *sc, int > struct upgt_data *data_cmd = >cmd_data; > struct upgt_lmac_mem *mem; > struct upgt_lmac_led *led; > - struct timeval t; > int len; > > /* > @@ -2063,9 +2062,7 @@ upgt_set_led(struct upgt_softc *sc, int > led->action_tmp_dur = htole16(UPGT_LED_ACTION_TMP_DUR); > /* lock blink */ > sc->sc_led_blink = 1; > - t.tv_sec = 0; > - t.tv_usec = UPGT_LED_ACTION_TMP_DUR * 1000L; > - timeout_add(>led_to, tvtohz()); > + timeout_add_msec(>led_to, UPGT_LED_ACTION_TMP_DUR); > break; > default: > return; > >
Re: urtw: use timeout_add_msec(9)
On Thu, Jun 13, 2019 at 11:12:23PM +0200, Klemens Nanni wrote: > > Simple sleeps for 100ms that currently use a timeval to specify > miliseconds, convert them to Hz with tvtohz(9) so they can be converted > back by timeout_add(9) - we can do better by now. > > I lack appropiate hardware, but the diff is pretty safe imho. The fact > that the argument has never been zero and will never be with this diff > makes it safe for timeout_add_msec(9) to now always sleep for at least > one tick. > > Feedback? OK? Tested on: urtw0 at uhub0 port 4 configuration 1 interface 0 "Realtek RTL8187_Wireless" rev 2.00/1.00 addr 3 urtw0: RTL8187 rev 0x04, RFv2, address 00:40:0c:xx:xx:xx ok kevlo@
Re: iwm: fix ADD_STA status check
On Wed, May 08, 2019 at 03:26:00PM -0400, Stefan Sperling wrote: > > Correctly mask status bits in ADD_STA command response; remaining > bits are used by firmware to return the baid for a BA session. > > Dragonfly 74d41163ddac72b0d7ea7b7873d53fe134723a12 > Linux 837c4da98481d4e504b2aba077c8528fee1b6d13 > > Not sure if this matters for us yet, but it will likely matter > when we start doing Tx aggregation. > > Perhaps this will fix the 'could not add sta' problem we've seen > occasionally? Let's try... > > ok? ok kevlo@
Re: iwm: rx interrupt paranoia
On Wed, May 08, 2019 at 02:54:50PM -0400, Stefan Sperling wrote: > > Add two sanity checks to iwm's firmware notification interrupt handler: > > 1) Clamp the firmware-provided index into the rx ring to the size of the ring. > Linux started doing this, too, to work around HW bugs in the 9000 series. Right, this matches Linux commit 5eae443eb5e2b3777582ea37c6a002171ec134d5 > 2) Don't call iwm_cmd_done() if the firmware response in the Rx buffer > is not recognized. We should just skip such buffers, not act on them. > > Not tested on hardware yet; these changes evidenty shouldn't break anything. Tested: iwm0 at pci3 dev 0 function 0 "Intel Dual Band Wireless AC 3165" rev 0x81, msi iwm0: hw rev 0x210, fw ver 16.242414.0, address 08:d4:0c:xx:xx:xx > ok? ok kevlo@
Re: ifmedia_ioctl: ignore ENETRESET from ifm_change()
On Sun, Apr 21, 2019 at 01:02:39PM +1000, Jonathan Matthew wrote:
>
> On Mon, Apr 15, 2019 at 04:48:02PM +0200, Stefan Sperling wrote:
> > ieee80211_media_change() will return ENETRESET if the interface is
> > switched into 11a/b/g/n mode from any other mode.
> > ifmedia_ioctl() considers this an error and reverts ifmedia's state
> > to the previous setting, even though net80211 has actually succeeded.
> > The result is that if_media and net80211 have conflicting ideas about the
> > current media mode of the interface, which can be observed with ifconfig.
>
> Diff makes sense to me. Currently we have some drivers with media_change
> functions returning the errno from ieee80211_media_change (iwn, iwm) and some
> just returning 0 at the end (run, rtwn, ral). The ones returning 0 are mostly
> ignoring possible errors from x_init() so I'm leaning towards making them more
> like iwn/m.
Agreed. Here's a follow-up diff which returns the errno from
ieee80211_media_change().
Index: sys/dev/ic/bwfm.c
===
RCS file: /cvs/src/sys/dev/ic/bwfm.c,v
retrieving revision 1.59
diff -u -p -u -p -r1.59 bwfm.c
--- sys/dev/ic/bwfm.c 1 Apr 2019 15:19:56 - 1.59
+++ sys/dev/ic/bwfm.c 21 Apr 2019 13:26:12 -
@@ -757,7 +757,7 @@ bwfm_media_change(struct ifnet *ifp)
bwfm_stop(ifp);
bwfm_init(ifp);
}
- return 0;
+ return error;
}
/* Chip initialization (SDIO, PCIe) */
Index: sys/dev/ic/rtwn.c
===
RCS file: /cvs/src/sys/dev/ic/rtwn.c,v
retrieving revision 1.45
diff -u -p -u -p -r1.45 rtwn.c
--- sys/dev/ic/rtwn.c 11 Mar 2019 06:19:33 - 1.45
+++ sys/dev/ic/rtwn.c 21 Apr 2019 13:26:12 -
@@ -745,9 +745,9 @@ rtwn_media_change(struct ifnet *ifp)
if ((ifp->if_flags & (IFF_UP | IFF_RUNNING)) ==
(IFF_UP | IFF_RUNNING)) {
rtwn_stop(ifp);
- rtwn_init(ifp);
+ error = rtwn_init(ifp);
}
- return (0);
+ return (error);
}
/*
Index: sys/dev/pci/if_iwi.c
===
RCS file: /cvs/src/sys/dev/pci/if_iwi.c,v
retrieving revision 1.138
diff -u -p -u -p -r1.138 if_iwi.c
--- sys/dev/pci/if_iwi.c26 Apr 2018 12:50:07 - 1.138
+++ sys/dev/pci/if_iwi.c21 Apr 2019 13:26:12 -
@@ -647,9 +647,9 @@ iwi_media_change(struct ifnet *ifp)
return error;
if ((ifp->if_flags & (IFF_UP | IFF_RUNNING)) == (IFF_UP | IFF_RUNNING))
- iwi_init(ifp);
+ error = iwi_init(ifp);
- return 0;
+ return error;
}
void
Index: sys/dev/usb/if_ral.c
===
RCS file: /cvs/src/sys/dev/usb/if_ral.c,v
retrieving revision 1.145
diff -u -p -u -p -r1.145 if_ral.c
--- sys/dev/usb/if_ral.c13 Jan 2019 14:27:15 - 1.145
+++ sys/dev/usb/if_ral.c21 Apr 2019 13:26:12 -
@@ -497,9 +497,9 @@ ural_media_change(struct ifnet *ifp)
return error;
if ((ifp->if_flags & (IFF_UP | IFF_RUNNING)) == (IFF_UP | IFF_RUNNING))
- ural_init(ifp);
+ error = ural_init(ifp);
- return 0;
+ return error;
}
/*
Index: sys/dev/usb/if_rsu.c
===
RCS file: /cvs/src/sys/dev/usb/if_rsu.c,v
retrieving revision 1.43
diff -u -p -u -p -r1.43 if_rsu.c
--- sys/dev/usb/if_rsu.c26 Apr 2018 12:50:07 - 1.43
+++ sys/dev/usb/if_rsu.c21 Apr 2019 13:26:12 -
@@ -749,9 +749,9 @@ rsu_media_change(struct ifnet *ifp)
if ((ifp->if_flags & (IFF_UP | IFF_RUNNING)) ==
(IFF_UP | IFF_RUNNING)) {
rsu_stop(ifp);
- rsu_init(ifp);
+ error = rsu_init(ifp);
}
- return (0);
+ return (error);
}
void
Index: sys/dev/usb/if_rum.c
===
RCS file: /cvs/src/sys/dev/usb/if_rum.c,v
retrieving revision 1.123
diff -u -p -u -p -r1.123 if_rum.c
--- sys/dev/usb/if_rum.c26 Oct 2017 15:00:28 - 1.123
+++ sys/dev/usb/if_rum.c21 Apr 2019 13:26:12 -
@@ -591,9 +591,9 @@ rum_media_change(struct ifnet *ifp)
return error;
if ((ifp->if_flags & (IFF_UP | IFF_RUNNING)) == (IFF_UP | IFF_RUNNING))
- rum_init(ifp);
+ error = rum_init(ifp);
- return 0;
+ return error;
}
/*
Index: sys/dev/usb/if_run.c
===
RCS file: /cvs/src/sys/dev/usb/if_run.c,v
retrieving revision 1.125
diff -u -p -u -p -r1.125 if_run.c
--- sys/dev/usb/if_run.c30 Jan 2018 20:56:38 - 1.125
+++ sys/dev/usb/if_run.c21 Apr 2019 13:26:12 -
@@ -1693,10 +1693,10 @@ run_media_change(struct ifnet
ure(4): fix URE_WDT6_SET_MODE register definition
Hi, Based on FreeBSD r346028, this fixes ure(4) not detected after a reboot. Tested: ure0 at uhub0 port 4 configuration 1 interface 0 "Realtek USB 10/100 LAN" rev 2.10/20.00 addr 3 ure0: ver 4c10, address 00:e0:4c:xx:xx:xx rlphy0 at ure0 phy 0: RTL8201E 10/100 PHY, rev. 2 ure0 at uhub0 port 4 configuration 1 interface 0 "Realtek USB 10/100/1000 LAN" rev 2.10/30.00 addr 3 ure0: ver 5c10, address 00:e0:4c:xx:xx:xx rgephy2 at ure0 phy 0: RTL8251 PHY, rev. 0 ok? Index: sys/dev/usb/if_urereg.h === RCS file: /cvs/src/sys/dev/usb/if_urereg.h,v retrieving revision 1.5 diff -u -p -u -p -r1.5 if_urereg.h --- sys/dev/usb/if_urereg.h 2 Nov 2018 21:32:30 - 1.5 +++ sys/dev/usb/if_urereg.h 10 Apr 2019 01:33:30 - @@ -177,7 +177,7 @@ #defineURE_EEEP_CR_EEEP_TX 0x0002 /* PLA_WDT6_CTRL */ -#defineURE_WDT6_SET_MODE 0x001 +#defineURE_WDT6_SET_MODE 0x0010 /* PLA_TCR0 */ #defineURE_TCR0_TX_EMPTY 0x0800
fix the gpio pin for ar9287-based usb devices
Hi, AR9287-based usb devices use GPIO pin 10 for LED, not 8. Tested with TP-LINK TL-WN821N V3. ok? Index: sys/dev/ic/ar9287.c === RCS file: /cvs/src/sys/dev/ic/ar9287.c,v retrieving revision 1.27 diff -u -p -u -p -r1.27 ar9287.c --- sys/dev/ic/ar9287.c 29 Mar 2019 11:04:40 - 1.27 +++ sys/dev/ic/ar9287.c 31 Mar 2019 10:12:22 - @@ -104,7 +104,7 @@ ar9287_attach(struct athn_softc *sc) AR9287_HTC_EEP_START_LOC : AR9287_EEP_START_LOC; sc->eep_size = sizeof(struct ar9287_eeprom); sc->ngpiopins = (sc->flags & ATHN_FLAG_USB) ? 16 : 11; - sc->led_pin = 8; + sc->led_pin = (sc->flags & ATHN_FLAG_USB) ? 10 : 8; sc->workaround = AR9285_WA_DEFAULT; sc->ops.setup = ar9287_setup; sc->ops.swap_rom = ar9287_swap_rom;
Re: cleanup FBSDID
Here's the revised diff that removes $FreeBSD$ IDs from my previous diff.
Index: lib/libc/arch/amd64/sys/tfork_thread.S
===
RCS file: /cvs/src/lib/libc/arch/amd64/sys/tfork_thread.S,v
retrieving revision 1.6
diff -u -p -u -p -r1.6 tfork_thread.S
--- lib/libc/arch/amd64/sys/tfork_thread.S 7 May 2016 19:05:21 -
1.6
+++ lib/libc/arch/amd64/sys/tfork_thread.S 15 Mar 2019 03:37:05 -
@@ -27,9 +27,6 @@
*/
#include
-#if 0
-__FBSDID("$FreeBSD: /repoman/r/ncvs/src/lib/libc/amd64/gen/rfork_thread.S,v
1.1 2003/10/13 20:32:33 alc Exp $");
-#endif
/*
* With thanks to John Dyson for the original version of this.
Index: lib/libc/arch/i386/sys/tfork_thread.S
===
RCS file: /cvs/src/lib/libc/arch/i386/sys/tfork_thread.S,v
retrieving revision 1.8
diff -u -p -u -p -r1.8 tfork_thread.S
--- lib/libc/arch/i386/sys/tfork_thread.S 7 May 2016 19:05:21 -
1.8
+++ lib/libc/arch/i386/sys/tfork_thread.S 15 Mar 2019 03:37:05 -
@@ -26,9 +26,6 @@
*/
#include
-#if 0
-__FBSDID("$FreeBSD: /repoman/r/ncvs/src/lib/libc/i386/gen/rfork_thread.S,v 1.5
2003/05/07 17:23:25 jhb Exp $");
-#endif
/*
* With thanks to John Dyson for the original version of this.
Index: lib/libc/arch/sparc64/fpu/fpu_add.c
===
RCS file: /cvs/src/lib/libc/arch/sparc64/fpu/fpu_add.c,v
retrieving revision 1.2
diff -u -p -u -p -r1.2 fpu_add.c
--- lib/libc/arch/sparc64/fpu/fpu_add.c 5 Dec 2012 23:19:59 - 1.2
+++ lib/libc/arch/sparc64/fpu/fpu_add.c 15 Mar 2019 03:37:05 -
@@ -45,10 +45,6 @@
* $NetBSD: fpu_add.c,v 1.3 1996/03/14 19:41:52 christos Exp $
*/
-#if 0
-__FBSDID("$FreeBSD: src/lib/libc/sparc64/fpu/fpu_add.c,v 1.4 2002/04/27
21:56:28 jake Exp $");
-#endif
-
/*
* Perform an FPU add (return x + y).
*
Index: lib/libc/arch/sparc64/fpu/fpu_compare.c
===
RCS file: /cvs/src/lib/libc/arch/sparc64/fpu/fpu_compare.c,v
retrieving revision 1.2
diff -u -p -u -p -r1.2 fpu_compare.c
--- lib/libc/arch/sparc64/fpu/fpu_compare.c 5 Dec 2012 23:19:59 -
1.2
+++ lib/libc/arch/sparc64/fpu/fpu_compare.c 15 Mar 2019 03:37:05 -
@@ -45,10 +45,6 @@
* $NetBSD: fpu_compare.c,v 1.3 2001/08/26 05:46:31 eeh Exp $
*/
-#if 0
-__FBSDID("$FreeBSD: src/lib/libc/sparc64/fpu/fpu_compare.c,v 1.4 2002/03/22
21:52:58 obrien Exp $");
-#endif
-
/*
* CMP and CMPE instructions.
*
Index: lib/libc/arch/sparc64/fpu/fpu_div.c
===
RCS file: /cvs/src/lib/libc/arch/sparc64/fpu/fpu_div.c,v
retrieving revision 1.3
diff -u -p -u -p -r1.3 fpu_div.c
--- lib/libc/arch/sparc64/fpu/fpu_div.c 26 Nov 2013 20:33:07 - 1.3
+++ lib/libc/arch/sparc64/fpu/fpu_div.c 15 Mar 2019 03:37:05 -
@@ -45,10 +45,6 @@
* $NetBSD: fpu_div.c,v 1.2 1994/11/20 20:52:38 deraadt Exp $
*/
-#if 0
-__FBSDID("$FreeBSD: src/lib/libc/sparc64/fpu/fpu_div.c,v 1.3 2002/03/22
21:52:58 obrien Exp $");
-#endif
-
/*
* Perform an FPU divide (return x / y).
*/
Index: lib/libc/arch/sparc64/fpu/fpu_explode.c
===
RCS file: /cvs/src/lib/libc/arch/sparc64/fpu/fpu_explode.c,v
retrieving revision 1.8
diff -u -p -u -p -r1.8 fpu_explode.c
--- lib/libc/arch/sparc64/fpu/fpu_explode.c 8 May 2016 18:41:17 -
1.8
+++ lib/libc/arch/sparc64/fpu/fpu_explode.c 15 Mar 2019 03:37:05 -
@@ -45,10 +45,6 @@
* $NetBSD: fpu_explode.c,v 1.5 2000/08/03 18:32:08 eeh Exp $
*/
-#if 0
-__FBSDID("$FreeBSD: src/lib/libc/sparc64/fpu/fpu_explode.c,v 1.5 2002/05/11
21:20:04 jake Exp $");
-#endif
-
/*
* FPU subroutines: `explode' the machine's `packed binary' format numbers
* into our internal format.
Index: lib/libc/arch/sparc64/fpu/fpu_implode.c
===
RCS file: /cvs/src/lib/libc/arch/sparc64/fpu/fpu_implode.c,v
retrieving revision 1.5
diff -u -p -u -p -r1.5 fpu_implode.c
--- lib/libc/arch/sparc64/fpu/fpu_implode.c 15 Nov 2015 22:41:43 -
1.5
+++ lib/libc/arch/sparc64/fpu/fpu_implode.c 15 Mar 2019 03:37:05 -
@@ -45,10 +45,6 @@
* $NetBSD: fpu_implode.c,v 1.8 2001/08/26 05:44:46 eeh Exp $
*/
-#if 0
-__FBSDID("$FreeBSD: src/lib/libc/sparc64/fpu/fpu_implode.c,v 1.5 2002/04/27
21:56:28 jake Exp $");
-#endif
-
/*
* FPU subroutines: `implode' internal format numbers into the machine's
* `packed binary' format.
Index: lib/libc/arch/sparc64/fpu/fpu_mul.c
===
RCS file: /cvs/src/lib/libc/arch/sparc64/fpu/fpu_mul.c,v
retrieving revision 1.2
diff -u -p -u -p -r1.2 fpu_mul.c
--- lib/libc/arch/sparc64/fpu/fpu_mul.c 5 Dec 2012 23:19:59 - 1.2
+++
cleanup FBSDID
ok?
Index: lib/libc/arch/amd64/sys/tfork_thread.S
===
RCS file: /cvs/src/lib/libc/arch/amd64/sys/tfork_thread.S,v
retrieving revision 1.6
diff -u -p -u -p -r1.6 tfork_thread.S
--- lib/libc/arch/amd64/sys/tfork_thread.S 7 May 2016 19:05:21 -
1.6
+++ lib/libc/arch/amd64/sys/tfork_thread.S 13 Mar 2019 05:33:28 -
@@ -24,12 +24,11 @@
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
+ *
+ * $FreeBSD: /repoman/r/ncvs/src/lib/libc/amd64/gen/rfork_thread.S,v 1.1
2003/10/13 20:32:33 alc Exp $
*/
#include
-#if 0
-__FBSDID("$FreeBSD: /repoman/r/ncvs/src/lib/libc/amd64/gen/rfork_thread.S,v
1.1 2003/10/13 20:32:33 alc Exp $");
-#endif
/*
* With thanks to John Dyson for the original version of this.
Index: lib/libc/arch/i386/sys/tfork_thread.S
===
RCS file: /cvs/src/lib/libc/arch/i386/sys/tfork_thread.S,v
retrieving revision 1.8
diff -u -p -u -p -r1.8 tfork_thread.S
--- lib/libc/arch/i386/sys/tfork_thread.S 7 May 2016 19:05:21 -
1.8
+++ lib/libc/arch/i386/sys/tfork_thread.S 13 Mar 2019 05:33:28 -
@@ -23,12 +23,11 @@
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
+ *
+ * $FreeBSD: /repoman/r/ncvs/src/lib/libc/i386/gen/rfork_thread.S,v 1.5
2003/05/07 17:23:25 jhb Exp $
*/
#include
-#if 0
-__FBSDID("$FreeBSD: /repoman/r/ncvs/src/lib/libc/i386/gen/rfork_thread.S,v 1.5
2003/05/07 17:23:25 jhb Exp $");
-#endif
/*
* With thanks to John Dyson for the original version of this.
Index: lib/libc/arch/sparc64/fpu/fpu_add.c
===
RCS file: /cvs/src/lib/libc/arch/sparc64/fpu/fpu_add.c,v
retrieving revision 1.2
diff -u -p -u -p -r1.2 fpu_add.c
--- lib/libc/arch/sparc64/fpu/fpu_add.c 5 Dec 2012 23:19:59 - 1.2
+++ lib/libc/arch/sparc64/fpu/fpu_add.c 13 Mar 2019 05:33:28 -
@@ -43,11 +43,9 @@
*
* @(#)fpu_add.c 8.1 (Berkeley) 6/11/93
* $NetBSD: fpu_add.c,v 1.3 1996/03/14 19:41:52 christos Exp $
+ *
+ * $FreeBSD: src/lib/libc/sparc64/fpu/fpu_add.c,v 1.4 2002/04/27 21:56:28 jake
Exp $
*/
-
-#if 0
-__FBSDID("$FreeBSD: src/lib/libc/sparc64/fpu/fpu_add.c,v 1.4 2002/04/27
21:56:28 jake Exp $");
-#endif
/*
* Perform an FPU add (return x + y).
Index: lib/libc/arch/sparc64/fpu/fpu_compare.c
===
RCS file: /cvs/src/lib/libc/arch/sparc64/fpu/fpu_compare.c,v
retrieving revision 1.2
diff -u -p -u -p -r1.2 fpu_compare.c
--- lib/libc/arch/sparc64/fpu/fpu_compare.c 5 Dec 2012 23:19:59 -
1.2
+++ lib/libc/arch/sparc64/fpu/fpu_compare.c 13 Mar 2019 05:33:28 -
@@ -43,11 +43,9 @@
*
* @(#)fpu_compare.c 8.1 (Berkeley) 6/11/93
* $NetBSD: fpu_compare.c,v 1.3 2001/08/26 05:46:31 eeh Exp $
+ *
+ * $FreeBSD: src/lib/libc/sparc64/fpu/fpu_compare.c,v 1.4 2002/03/22 21:52:58
obrien Exp $
*/
-
-#if 0
-__FBSDID("$FreeBSD: src/lib/libc/sparc64/fpu/fpu_compare.c,v 1.4 2002/03/22
21:52:58 obrien Exp $");
-#endif
/*
* CMP and CMPE instructions.
Index: lib/libc/arch/sparc64/fpu/fpu_div.c
===
RCS file: /cvs/src/lib/libc/arch/sparc64/fpu/fpu_div.c,v
retrieving revision 1.3
diff -u -p -u -p -r1.3 fpu_div.c
--- lib/libc/arch/sparc64/fpu/fpu_div.c 26 Nov 2013 20:33:07 - 1.3
+++ lib/libc/arch/sparc64/fpu/fpu_div.c 13 Mar 2019 05:33:28 -
@@ -43,11 +43,9 @@
*
* @(#)fpu_div.c 8.1 (Berkeley) 6/11/93
* $NetBSD: fpu_div.c,v 1.2 1994/11/20 20:52:38 deraadt Exp $
+ *
+ * $FreeBSD: src/lib/libc/sparc64/fpu/fpu_div.c,v 1.3 2002/03/22 21:52:58
obrien Exp $
*/
-
-#if 0
-__FBSDID("$FreeBSD: src/lib/libc/sparc64/fpu/fpu_div.c,v 1.3 2002/03/22
21:52:58 obrien Exp $");
-#endif
/*
* Perform an FPU divide (return x / y).
Index: lib/libc/arch/sparc64/fpu/fpu_explode.c
===
RCS file: /cvs/src/lib/libc/arch/sparc64/fpu/fpu_explode.c,v
retrieving revision 1.8
diff -u -p -u -p -r1.8 fpu_explode.c
--- lib/libc/arch/sparc64/fpu/fpu_explode.c 8 May 2016 18:41:17 -
1.8
+++ lib/libc/arch/sparc64/fpu/fpu_explode.c 13 Mar 2019 05:33:28 -
@@ -43,11 +43,9 @@
*
* @(#)fpu_explode.c 8.1 (Berkeley) 6/11/93
* $NetBSD: fpu_explode.c,v 1.5 2000/08/03 18:32:08 eeh Exp $
+ *
+ * $FreeBSD: src/lib/libc/sparc64/fpu/fpu_explode.c,v 1.5 2002/05/11 21:20:04
jake Exp $
*/
-
-#if 0
-__FBSDID("$FreeBSD: src/lib/libc/sparc64/fpu/fpu_explode.c,v 1.5 2002/05/11
21:20:04 jake Exp $");
-#endif
/*
* FPU subroutines: `explode' the machine's `packed binary' format numbers
Re: athn(4): enable more calibration
On Tue, Jan 29, 2019 at 09:11:42PM +0100, Stefan Sperling wrote: > > The diff below enables periodic ADC/IQ calibration on athn(4) devices. > Without this calibration athn devices might perform suboptimally > as they warm up during operation. > > The code is already there, it was just not being called yet. > I don't know why it was left disabled but it seems to cause no harm on > my access points, though it doesn't make any notable difference either. > > I would like to get some test reports to see whether enabling > calibration causes problems or behaviour changes for anyone. No problem here. athn0 at uhub0 port 4 configuration 1 interface 0 "ATHEROS USB2.0 WLAN" rev 2.00/1.08 addr 3 athn0: AR9271 rev 1 (1T1R), ROM rev 13, address d8:5d:4c:xx:xx:xx
Re: [patch] urtwn(4): accept control frames when in monitor mode
On Wed, Jan 23, 2019 at 09:50:18AM +0100, Jesper Wallin wrote:
>
> Hi,
>
> This patch will allow urtwn(4) to see control frames when monitor mode
> is enabled. I've only tested this with my TP-LINK TL-WN821N v5 card, so
> perhaps more checks are needed to avoid breaking other cards.
>
> If you test this, enable monitor mode:
>
> $ doas ifconfig urtwn0 mediaopt monitor up
>
> Check with tcpdump if you receive any control frames (ack, rts, cts):
>
> $ doas tcpdump -i urtwn0 -n -v -y IEEE802_11_RADIO
>
>
> Also, please make sure that the NIC works BSS ("normal") mode as well.
First off, thanks for the diff. Right, urtwn(4) doesn't see any control
frames in monitor mode, I think we also need to set R92C_RCR_ADF, R92C_RCR_ACF,
and R92C_RCR_AMF bits in R92C_RCR to accept data/ctrl/mgmt frames explicitly.
ok?
Index: sys/dev/ic/rtwn.c
===
RCS file: /cvs/src/sys/dev/ic/rtwn.c,v
retrieving revision 1.43
diff -u -p -u -p -r1.43 rtwn.c
--- sys/dev/ic/rtwn.c 7 Dec 2018 01:53:20 - 1.43
+++ sys/dev/ic/rtwn.c 24 Jan 2019 07:20:29 -
@@ -1132,6 +1132,14 @@ rtwn_newstate(struct ieee80211com *ic, e
/* Enable Rx of data frames. */
rtwn_write_2(sc, R92C_RXFLTMAP2, 0x);
+ /* Enable Rx of control frames. */
+ rtwn_write_2(sc, R92C_RXFLTMAP1, 0x);
+
+ rtwn_write_4(sc, R92C_RCR,
+ rtwn_read_4(sc, R92C_RCR) |
+ R92C_RCR_AAP | R92C_RCR_ADF | R92C_RCR_ACF |
+ R92C_RCR_AMF);
+
/* Turn link LED on. */
rtwn_set_led(sc, RTWN_LED_LINK, 1);
break;
Add PCI IDs for Intel Apollo Lake SoC
Hi, Diff below adds PCI product IDs found on Intel Leaf Hill CRB, ok? Index: sys/dev/pci/pcidevs === RCS file: /cvs/src/sys/dev/pci/pcidevs,v retrieving revision 1.1871 diff -u -p -u -p -r1.1871 pcidevs --- sys/dev/pci/pcidevs 16 Dec 2018 15:11:30 - 1.1871 +++ sys/dev/pci/pcidevs 17 Dec 2018 07:30:07 - @@ -4734,7 +4734,8 @@ product INTEL CORE7G_U_GT2_2 0x591d HD G product INTEL CORE7G_Y_GT2 0x591e HD Graphics 615 product INTEL CORE7G_U_GT3_15W 0x5926 Iris Plus Graphics 640 product INTEL CORE7G_U_GT3_28W 0x5927 Iris Plus Graphics 650 -product INTEL APOLLOLAKE_IGD 0x5a85 HD Graphics 500 +product INTEL APOLLOLAKE_IGD_1 0x5a84 HD Graphics 505 +product INTEL APOLLOLAKE_IGD_2 0x5a85 HD Graphics 500 product INTEL APOLLOLAKE_HDA 0x5a98 Apollo Lake HD Audio product INTEL APOLLOLAKE_TXE 0x5a9a Apollo Lake TXE product INTEL APOLLOLAKE_XHCI 0x5aa8 Apollo Lake xHCI @@ -4743,6 +4744,9 @@ product INTEL APOLLOLAKE_UART_1 0x5abc A product INTEL APOLLOLAKE_SPI_1 0x5ac2 Apollo Lake SPI product INTEL APOLLOLAKE_SPI_2 0x5ac4 Apollo Lake SPI product INTEL APOLLOLAKE_SPI_3 0x5ac6 Apollo Lake SPI +product INTEL APOLLOLAKE_SDMMC 0x5aca Apollo Lake SD/MMC +product INTEL APOLLOLAKE_EMMC 0x5acc Apollo Lake eMMC +product INTEL APOLLOLAKE_SDIO 0x5ad0 Apollo Lake SDIO product INTEL APOLLOLAKE_SMB 0x5ad4 Apollo Lake SMBus product INTEL APOLLOLAKE_PCIE_10x5ad8 Apollo Lake PCIE product INTEL APOLLOLAKE_PCIE_20x5ad9 Apollo Lake PCIE
Re: ure(4): VLANs and Jumbo frames
On Tue, Oct 30, 2018 at 10:57:08AM +0100, Patrick Wildt wrote: > On Tue, Oct 30, 2018 at 05:30:55PM +0800, Kevin Lo wrote: > > On Tue, Oct 30, 2018 at 09:43:08AM +0100, Patrick Wildt wrote: > > > + if (sc->ure_flags & URE_FLAG_8152) > > > + ifp->ifp_hardmtu = URE_MAX_FRAMELEN_8152; > > > + else > > > + ifp->ifp_hardmtu = URE_MAX_FRAMELEN_8153; > > > + ifp->ifp_hardmtu -= (ETHER_HDR_LEN + ETHER_VLAN_ENCAP_LEN); > > > > Typo. Should be ifp->if_hardmtu, not ifp->ifp_hardmtu. > > Oops, yes, I sent the wrong diff that still had the typo. Fixed diff > attached which has no other change. ok kevlo@ > > diff --git a/sys/dev/usb/if_ure.c b/sys/dev/usb/if_ure.c > index b6c6c99ef34..9ec0dedceff 100644 > --- a/sys/dev/usb/if_ure.c > +++ b/sys/dev/usb/if_ure.c > @@ -695,6 +695,9 @@ ure_rtl8152_init(struct ure_softc *sc) > > ure_init_fifo(sc); > > + /* Set allowed frame size. */ > + ure_write_2(sc, URE_PLA_RMS, URE_MCU_TYPE_PLA, URE_MAX_FRAMELEN_8152); > + > ure_write_1(sc, URE_USB_TX_AGG, URE_MCU_TYPE_USB, > URE_TX_AGG_MAX_THRESHOLD); > ure_write_4(sc, URE_USB_RX_BUF_TH, URE_MCU_TYPE_USB, URE_RX_THR_HIGH); > @@ -835,6 +838,10 @@ ure_rtl8153_init(struct ure_softc *sc) > > ure_init_fifo(sc); > > + /* Set allowed frame size. */ > + ure_write_2(sc, URE_PLA_RMS, URE_MCU_TYPE_PLA, URE_MAX_FRAMELEN_8153); > + ure_write_2(sc, URE_PLA_MTPS, URE_MCU_TYPE_PLA, URE_MTPS_JUMBO); > + > /* Enable Rx aggregation. */ > ure_write_2(sc, URE_USB_USB_CTRL, URE_MCU_TYPE_USB, > ure_read_2(sc, URE_USB_USB_CTRL, URE_MCU_TYPE_USB) & > @@ -1147,6 +1154,12 @@ ure_attach(struct device *parent, struct device *self, > void *aux) > ifp->if_start = ure_start; > ifp->if_capabilities = 0; > > + if (sc->ure_flags & URE_FLAG_8152) > + ifp->if_hardmtu = URE_MAX_FRAMELEN_8152; > + else > + ifp->if_hardmtu = URE_MAX_FRAMELEN_8153; > + ifp->if_hardmtu -= (ETHER_HDR_LEN + ETHER_VLAN_ENCAP_LEN); > + > mii = >ure_mii; > mii->mii_ifp = ifp; > mii->mii_readreg = ure_miibus_readreg; > diff --git a/sys/dev/usb/if_urereg.h b/sys/dev/usb/if_urereg.h > index 2260ec37890..8963d2753ed 100644 > --- a/sys/dev/usb/if_urereg.h > +++ b/sys/dev/usb/if_urereg.h > @@ -41,7 +41,8 @@ > #define URE_BYTE_EN_BYTE0x11 > #define URE_BYTE_EN_SIX_BYTES 0x3f > > -#define URE_MAX_FRAMELEN(ETHER_MAX_LEN + ETHER_VLAN_ENCAP_LEN) > +#define URE_MAX_FRAMELEN_8152 (ETHER_MAX_LEN + ETHER_VLAN_ENCAP_LEN) > +#define URE_MAX_FRAMELEN_8153 (9 * 1024) > > #define URE_PLA_IDR 0xc000 > #define URE_PLA_RCR 0xc010 > @@ -186,6 +187,10 @@ > /* PLA_TCR1 */ > #define URE_VERSION_MASK0x7cf0 > > +/* PLA_MTPS */ > +#define URE_MTPS_JUMBO (12 * 1024 / 64) > +#define URE_MTPS_DEFAULT (6 * 1024 / 64) > + > /* PLA_CR */ > #define URE_CR_RST 0x10 > #define URE_CR_RE 0x08
Re: ure(4): VLANs and Jumbo frames
On Tue, Oct 30, 2018 at 09:43:08AM +0100, Patrick Wildt wrote: > > Hi, > > I recently wanted to use VLANs on ure(4) but failed. As it turns out, > hardmtu is set to 1500 which apparently does not leave enough space > for the VLAN tag. It looks like the Gigabit Version does even support > Jumbo frames. Thus we can set the maximum framelen on the RX path > to something bigger and enable Jumbo frames. > > I tried this on a Winyao USB1000F. Would be nice if people tested this > change who have those ure(4)s in active use. > > Thanks, > Patrick > > diff --git a/sys/dev/usb/if_ure.c b/sys/dev/usb/if_ure.c > index b6c6c99ef34..637fd5eca5f 100644 > --- a/sys/dev/usb/if_ure.c > +++ b/sys/dev/usb/if_ure.c > @@ -695,6 +695,9 @@ ure_rtl8152_init(struct ure_softc *sc) > > ure_init_fifo(sc); > > + /* Set allowed frame size. */ > + ure_write_2(sc, URE_PLA_RMS, URE_MCU_TYPE_PLA, URE_MAX_FRAMELEN_8152); > + > ure_write_1(sc, URE_USB_TX_AGG, URE_MCU_TYPE_USB, > URE_TX_AGG_MAX_THRESHOLD); > ure_write_4(sc, URE_USB_RX_BUF_TH, URE_MCU_TYPE_USB, URE_RX_THR_HIGH); > @@ -835,6 +838,10 @@ ure_rtl8153_init(struct ure_softc *sc) > > ure_init_fifo(sc); > > + /* Set allowed frame size. */ > + ure_write_2(sc, URE_PLA_RMS, URE_MCU_TYPE_PLA, URE_MAX_FRAMELEN_8153); > + ure_write_2(sc, URE_PLA_MTPS, URE_MCU_TYPE_PLA, URE_MTPS_JUMBO); > + > /* Enable Rx aggregation. */ > ure_write_2(sc, URE_USB_USB_CTRL, URE_MCU_TYPE_USB, > ure_read_2(sc, URE_USB_USB_CTRL, URE_MCU_TYPE_USB) & > @@ -1147,6 +1154,12 @@ ure_attach(struct device *parent, struct device *self, > void *aux) > ifp->if_start = ure_start; > ifp->if_capabilities = 0; > > + if (sc->ure_flags & URE_FLAG_8152) > + ifp->ifp_hardmtu = URE_MAX_FRAMELEN_8152; > + else > + ifp->ifp_hardmtu = URE_MAX_FRAMELEN_8153; > + ifp->ifp_hardmtu -= (ETHER_HDR_LEN + ETHER_VLAN_ENCAP_LEN); Typo. Should be ifp->if_hardmtu, not ifp->ifp_hardmtu. > + > mii = >ure_mii; > mii->mii_ifp = ifp; > mii->mii_readreg = ure_miibus_readreg; > diff --git a/sys/dev/usb/if_urereg.h b/sys/dev/usb/if_urereg.h > index 2260ec37890..8963d2753ed 100644 > --- a/sys/dev/usb/if_urereg.h > +++ b/sys/dev/usb/if_urereg.h > @@ -41,7 +41,8 @@ > #define URE_BYTE_EN_BYTE0x11 > #define URE_BYTE_EN_SIX_BYTES 0x3f > > -#define URE_MAX_FRAMELEN(ETHER_MAX_LEN + ETHER_VLAN_ENCAP_LEN) > +#define URE_MAX_FRAMELEN_8152 (ETHER_MAX_LEN + ETHER_VLAN_ENCAP_LEN) > +#define URE_MAX_FRAMELEN_8153 (9 * 1024) > > #define URE_PLA_IDR 0xc000 > #define URE_PLA_RCR 0xc010 > @@ -186,6 +187,10 @@ > /* PLA_TCR1 */ > #define URE_VERSION_MASK0x7cf0 > > +/* PLA_MTPS */ > +#define URE_MTPS_JUMBO (12 * 1024 / 64) > +#define URE_MTPS_DEFAULT (6 * 1024 / 64) > + > /* PLA_CR */ > #define URE_CR_RST 0x10 > #define URE_CR_RE 0x08 Tested on RTL8152 and RTL8153, seems to be working fine. ok kevlo@
Re: ral(4): add RT3290 support
On Mon, Sep 17, 2018 at 09:34:06PM -0400, James Hastings wrote: > > > Ported from original vendor driver. > RT3290 is similar to RT5390 but integrates WLAN + Bluetooth on single chip. > Bluetooth not supported. First off, thank you for working on this. I tested it on amd64, ifconfig ral0 up will cause system hang totally. The adapter is good since it works on Linux *shrug*. > New 4kb firmware at /etc/firmware/ral-rt3290 for this chip only. > New routines to read efuse rom and control wlan core. > Tested on RT3090 and RT5390. ^^ Typo? Did you test on RT3290? Thanks.
