Re: pcidevs update for AMD Sensor Fusion Hub

2022-05-05 Thread Jonathan Gray
On Thu, May 05, 2022 at 12:34:33PM +0200, Frederic Cambus wrote:
> On Thu, May 05, 2022 at 08:04:16PM +1000, Jonathan Gray wrote:
> > On Thu, May 05, 2022 at 11:26:23AM +0200, Frederic Cambus wrote:
> > > Hi tech@,
> > > 
> > > Here is a diff to add ID for the AMD Sensor Fusion Hub found on my
> > > Ryzen-based ZBOX CA621. Full dmesg below.
> > > 
> > > Comments? OK?
> > 
> > Can the string instead be "17h/1xh SFH"?
> 
> Sure thing, new diff below.

ok jsg@

> 
> Index: sys/dev/pci/pcidevs
> ===
> RCS file: /cvs/src/sys/dev/pci/pcidevs,v
> retrieving revision 1.1992
> diff -u -p -r1.1992 pcidevs
> --- sys/dev/pci/pcidevs   4 May 2022 08:10:43 -   1.1992
> +++ sys/dev/pci/pcidevs   5 May 2022 10:28:50 -
> @@ -818,6 +818,7 @@ product AMD 17_1X_XHCI_1  0x15e0  17h/1xh 
>  product AMD 17_1X_XHCI_2 0x15e1  17h/1xh xHCI
>  product AMD 17_1X_ACP0x15e2  17h/1xh I2S Audio
>  product AMD 17_1X_HDA0x15e3  17h/1xh HD Audio
> +product AMD 17_1X_SFH0x15e6  17h/1xh SFH
>  product AMD 17_1X_DF_0   0x15e8  17h/1xh Data Fabric
>  product AMD 17_1X_DF_1   0x15e9  17h/1xh Data Fabric
>  product AMD 17_1X_DF_2   0x15ea  17h/1xh Data Fabric
> 



Re: pcidevs update for AMD Sensor Fusion Hub

2022-05-05 Thread Jonathan Gray
On Thu, May 05, 2022 at 11:26:23AM +0200, Frederic Cambus wrote:
> Hi tech@,
> 
> Here is a diff to add ID for the AMD Sensor Fusion Hub found on my
> Ryzen-based ZBOX CA621. Full dmesg below.
> 
> Comments? OK?

Can the string instead be "17h/1xh SFH"?

> 
> Index: sys/dev/pci/pcidevs
> ===
> RCS file: /cvs/src/sys/dev/pci/pcidevs,v
> retrieving revision 1.1988
> diff -u -p -r1.1988 pcidevs
> --- sys/dev/pci/pcidevs   11 Mar 2022 08:28:40 -  1.1988
> +++ sys/dev/pci/pcidevs   4 May 2022 09:04:34 -
> @@ -818,6 +818,7 @@ product AMD 17_1X_XHCI_1  0x15e0  17h/1xh 
>  product AMD 17_1X_XHCI_2 0x15e1  17h/1xh xHCI
>  product AMD 17_1X_ACP0x15e2  17h/1xh I2S Audio
>  product AMD 17_1X_HDA0x15e3  17h/1xh HD Audio
> +product AMD 17_1X_SFH0x15e6  17h/1xh Sensor Fusion Hub
>  product AMD 17_1X_DF_0   0x15e8  17h/1xh Data Fabric
>  product AMD 17_1X_DF_1   0x15e9  17h/1xh Data Fabric
>  product AMD 17_1X_DF_2   0x15ea  17h/1xh Data Fabric
> 
> 
> OpenBSD 7.1-current (GENERIC.MP) #1: Wed May  4 13:09:09 CEST 2022
> fcam...@amd64.my.domain:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 32125165568 (30636MB)
> avail mem = 31134224384 (29691MB)
> random: good seed from bootblocks
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 3.2 @ 0xeacc0 (44 entries)
> bios0: vendor American Megatrends Inc. version "B410P112" date 09/08/2021
> bios0: ZOTAC B410
> acpi0 at bios0: ACPI 6.0
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP APIC FPDT FIDT SSDT MCFG HPET UEFI TPM2 SSDT CRAT 
> CDIT SSDT SSDT SSDT WSMT SSDT
> acpi0: wakeup devices GPP0(S4) GPP1(S4) GPP2(S4) GPP3(S4) GPP4(S4) GPP5(S4) 
> GPP6(S4) GP17(S4) XHC0(S4) XHC1(S4) GP18(S4) SIO1(S3)
> acpitimer0 at acpi0: 3579545 Hz, 32 bits
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: AMD Ryzen 3 3200U with Radeon Vega Mobile Gfx, 2595.56 MHz, 17-18-01
> cpu0: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
> cpu0: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 
> 64b/line 8-way L2 cache
> cpu0: ITLB 64 4KB entries fully associative, 64 4MB entries fully associative
> cpu0: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative
> cpu0: smt 0, core 0, package 0
> mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
> cpu0: apic clock running at 24MHz
> cpu0: mwait min=64, max=64, C-substates=1.1, IBE
> cpu1 at mainbus0: apid 1 (application processor)
> cpu1: AMD Ryzen 3 3200U with Radeon Vega Mobile Gfx, 2595.10 MHz, 17-18-01
> cpu1: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
> cpu1: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 
> 64b/line 8-way L2 cache
> cpu1: ITLB 64 4KB entries fully associative, 64 4MB entries fully associative
> cpu1: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative
> cpu1: smt 1, core 0, package 0
> cpu2 at mainbus0: apid 2 (application processor)
> cpu2: AMD Ryzen 3 3200U with Radeon Vega Mobile Gfx, 2595.10 MHz, 17-18-01
> cpu2: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
> cpu2: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 
> 64b/line 8-way L2 cache
> cpu2: ITLB 64 4KB entries fully associative, 64 4MB entries fully associative
> cpu2: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative
> cpu2: smt 0, core 1, package 0
> cpu3 at mainbus0: apid 3 (application processor)
> cpu3: AMD Ryzen 3 3200U with Radeon Vega Mobile Gfx, 2595.10 MHz, 17-18-01
> cpu3: 
> 

Re: Potential NULL dereference id_entry

2022-04-30 Thread Jonathan Gray
On Sat, Apr 30, 2022 at 07:54:12PM -0600, Ted Bullock wrote:
> in radeondrm_attach_kms:508 could potentially fail and result in a NULL
> dereference at line 510. Check this with KASSERT().

This can not happen.  drm_pciprobe() uses drm_find_description()
if it returned NULL the driver would not match.

> 
> diff 5fbcee9a5968b225053e9e1b0363430e36326626 /usr/src
> blob - 94f38e8769827e9c649147689a9ca6f889d1464f
> file + sys/dev/pci/drm/radeon/radeon_kms.c
> --- sys/dev/pci/drm/radeon/radeon_kms.c
> +++ sys/dev/pci/drm/radeon/radeon_kms.c
> @@ -507,6 +507,8 @@ radeondrm_attach_kms(struct device *parent, struct dev
>  
>   id_entry = drm_find_description(PCI_VENDOR(pa->pa_id),
>   PCI_PRODUCT(pa->pa_id), radeondrm_pciidlist);
> + KASSERT(id_entry != NULL);
> + 
>   rdev->flags = id_entry->driver_data;
>   rdev->family = rdev->flags & RADEON_FAMILY_MASK;
>   rdev->pc = pa->pa_pc;
> 
> 
> 
> -- 
> Ted Bullock 
> 
> 



Re: xenodm and login_fbtab

2022-04-20 Thread Jonathan Gray
On Wed, Apr 20, 2022 at 05:17:58PM -0500, joshua stein wrote:
> xenodm supports login_fbtab(3) to chown devices but it currently 
> doesn't do anything because /etc/fbtab does not list /dev/ttyC4.  It 
> uses the GiveConsole and TakeConsole scripts in /etc/X11/xenodm/ to 
> do this manually, but the file lists are not complete.
> 
> I would like to remove all of the custom chown/chmod calls in the 
> GiveConsole and TakeConsole scripts and move this into /etc/fbtab by 
> adding /dev/ttyC4 and all of the wskbd* and wsmouse* devices so that 
> wsconsctl from within X11 works. (These wildcards require the 
> just-committed changes to libutil.)
> 
> The current fbtab lists many of these devices for /dev/ttyC0 which 
> seems only relevant for running OpenGL applications from the console 
> (is this even possible?) or running X11 as an unprivileged user 
> which we don't support anymore.

using startx still works with the modesetting xorg driver
when the pci bus does not need to be probed

does your diff no longer change ownership of the devices for
startx?


revision 1.7
date: 2019/09/15 12:25:40;  author: kettenis;  state: Exp;  lines: +1 -1;  
commitid: zDNBYfUsKpdfByaf;
Add ttyC4 to lost of devices to change when logging in on ttyC0 (and in
some cases also the serial console) such that X can use it as its VT
when running without root privileges.

ok jsg@, matthieu@


> 
> Is there any particular reason to keep these around for /dev/ttyC0?
> 
> This has bit me before when I am logged into X11 as my normal user, 
> I login to ttyC0 as root to check something which chowns all the 
> devices to root, then later in X11 I notice no GL-using apps like 
> Firefox work anymore because they can't open /dev/dri nodes.
> 
> Once these file lists are ironed out, I will make diffs for all the 
> other arches.
> 
> 
> diff --git etc/etc.amd64/fbtab etc/etc.amd64/fbtab
> index aec447931a7..df5a7a29cdd 100644
> --- etc/etc.amd64/fbtab
> +++ etc/etc.amd64/fbtab
> @@ -1 +1,2 @@
> -/dev/ttyC0   0600
> /dev/console:/dev/wskbd:/dev/wskbd0:/dev/wsmouse:/dev/wsmouse0:/dev/ttyCcfg:/dev/ttyC4:/dev/dri/card0:/dev/dri/renderD128
> +/dev/ttyC0   0600/dev/console:/dev/wskbd*:/dev/wsmouse*:/dev/ttyCcfg
> +/dev/ttyC4   0600
> /dev/console:/dev/wskbd*:/dev/wsmouse*:/dev/ttyCcfg:/dev/ttyC4:/dev/dri/*
> 
> 



Re: amd64: do CPU identification before TSC sync test

2022-03-28 Thread Jonathan Gray
On Mon, Mar 28, 2022 at 10:52:09PM -0500, Scott Cheloha wrote:
> I want to use the IA32_TSC_ADJUST MSR where available when testing TSC
> synchronization.  We note if it's available during CPU identification.
> 
> Can we do CPU identification earlier in cpu_hatch() and
> cpu_start_secondary(), before we do the TSC sync testing?
> 
> This can wait until after release.  I'm just trying to suss out
> whether there is an order dependency I'm not seeing.  My laptop
> appears to boot and resume no differently with this patch.
> 
> Thoughts?

The rest aside, moving the cpu_ucode_apply() call to after the
identifycpu() call is wrong as microcode can add cpuid bits.
I would keep cpu_tsx_disable() before it as well.

I'm sure I've had problems trying to change the sequencing
of lapic, tsc freq and identify in the past.  It caused problems
only on certain machines.

> 
> Index: cpu.c
> ===
> RCS file: /cvs/src/sys/arch/amd64/amd64/cpu.c,v
> retrieving revision 1.155
> diff -u -p -r1.155 cpu.c
> --- cpu.c 21 Feb 2022 11:03:39 -  1.155
> +++ cpu.c 29 Mar 2022 03:49:31 -
> @@ -842,20 +842,7 @@ cpu_start_secondary(struct cpu_info *ci)
>   printf("dropping into debugger; continue from here to resume 
> boot\n");
>   db_enter();
>  #endif
> - } else {
> - /*
> -  * Synchronize time stamp counters. Invalidate cache and
> -  * synchronize twice (in tsc_sync_bp) to minimize possible
> -  * cache effects. Disable interrupts to try and rule out any
> -  * external interference.
> -  */
> - s = intr_disable();
> - wbinvd();
> - tsc_sync_bp(ci);
> - intr_restore(s);
> -#ifdef TSC_DEBUG
> - printf("TSC skew=%lld\n", (long long)ci->ci_tsc_skew);
> -#endif
> + goto cleanup;
>   }
>  
>   if ((ci->ci_flags & CPUF_IDENTIFIED) == 0) {
> @@ -865,11 +852,28 @@ cpu_start_secondary(struct cpu_info *ci)
>   for (i = 200; (ci->ci_flags & CPUF_IDENTIFY) && i > 0; i--)
>   delay(10);
>  
> - if (ci->ci_flags & CPUF_IDENTIFY)
> + if (ci->ci_flags & CPUF_IDENTIFY) {
>   printf("%s: failed to identify\n",
>   ci->ci_dev->dv_xname);
> + goto cleanup;
> + }
>   }
>  
> + /*
> +  * Synchronize time stamp counters. Invalidate cache and
> +  * synchronize twice (in tsc_sync_bp) to minimize possible
> +  * cache effects. Disable interrupts to try and rule out any
> +  * external interference.
> +  */
> + s = intr_disable();
> + wbinvd();
> + tsc_sync_bp(ci);
> + intr_restore(s);
> +#ifdef TSC_DEBUG
> + printf("TSC skew=%lld\n", (long long)ci->ci_tsc_skew);
> +#endif
> +
> +cleanup:
>   CPU_START_CLEANUP(ci);
>  
>   pmap_kremove(MP_TRAMPOLINE, PAGE_SIZE);
> @@ -930,20 +934,7 @@ cpu_hatch(void *v)
>   if (ci->ci_flags & CPUF_PRESENT)
>   panic("%s: already running!?", ci->ci_dev->dv_xname);
>  #endif
> -
> - /*
> -  * Synchronize the TSC for the first time. Note that interrupts are
> -  * off at this point.
> -  */
> - wbinvd();
>   ci->ci_flags |= CPUF_PRESENT;
> - ci->ci_tsc_skew = 0;/* reset on resume */
> - tsc_sync_ap(ci);
> -
> - lapic_enable();
> - lapic_startclock();
> - cpu_ucode_apply(ci);
> - cpu_tsx_disable(ci);
>  
>   if ((ci->ci_flags & CPUF_IDENTIFIED) == 0) {
>   /*
> @@ -960,6 +951,19 @@ cpu_hatch(void *v)
>   /* Prevent identifycpu() from running again */
>   atomic_setbits_int(>ci_flags, CPUF_IDENTIFIED);
>   }
> +
> + /*
> +  * Synchronize the TSC for the first time. Note that interrupts are
> +  * off at this point.
> +  */
> + wbinvd();
> + ci->ci_tsc_skew = 0;/* reset on resume */
> + tsc_sync_ap(ci);
> +
> + lapic_enable();
> + lapic_startclock();
> + cpu_ucode_apply(ci);
> + cpu_tsx_disable(ci);
>  
>   while ((ci->ci_flags & CPUF_GO) == 0)
>   delay(10);
> 
> 



Re: riscv64: simplify

2022-03-21 Thread Jonathan Gray
On Mon, Mar 21, 2022 at 07:51:25PM +, Miod Vallat wrote:
> The riscv64  was likely copied from an architecture
> providing optimized byte-swapping code (I'd bet arm64), but doesn't have
> any such optimization, and copies the MI code.
> 
> Acknowledge this by dropping the __HAVE_MD_SWAP define to get the MI
> code for free, rather than duplicating it.
> 
> Completely untested due to lack of applicable hardware.

a kernel with this boots on qemu-system-riscv64

ok jsg@

> 
> Index: endian.h
> ===
> RCS file: /OpenBSD/src/sys/arch/riscv64/include/endian.h,v
> retrieving revision 1.2
> diff -u -p -r1.2 endian.h
> --- endian.h  12 May 2021 01:20:52 -  1.2
> +++ endian.h  21 Mar 2022 19:47:43 -
> @@ -19,51 +19,11 @@
>  #ifndef _MACHINE_ENDIAN_H_
>  #define _MACHINE_ENDIAN_H_
>  
> -#ifndef __FROM_SYS__ENDIAN
> -#include 
> -#endif
> -
> -static __inline __uint16_t
> -__swap16md(__uint16_t _x)
> -{
> - __uint32_t ret;
> - ret = ((_x >> 8) | ((_x << 8) & 0xff00));
> -
> - return ((__uint16_t)ret);
> -}
> -
> -static __inline __uint32_t
> -__swap32md(__uint32_t _x)
> -{
> - return ((_x >> 24) | ((_x >> 8) & 0xff00) | ((_x << 8) & 0xff) |
> - ((_x << 24) & 0xff00));
> -}
> -
> -static __inline __uint64_t
> -__swap64md(__uint64_t _x)
> -{
> - __uint64_t ret;
> -
> - ret = (_x >> 56);
> - ret |= ((_x >> 40) & 0xff00);
> - ret |= ((_x >> 24) & 0xff);
> - ret |= ((_x >>  8) & 0xff00);
> - ret |= ((_x <<  8) & ((__uint64_t)0xff << 32));
> - ret |= ((_x << 24) & ((__uint64_t)0xff << 40));
> - ret |= ((_x << 40) & ((__uint64_t)0xff << 48));
> - ret |= (_x << 56);
> -
> - return (ret);
> -}
> -
> -/* Tell sys/endian.h we have MD variants of the swap macros.  */
> -#define __HAVE_MD_SWAP
> -
> -
>  #define _BYTE_ORDER _LITTLE_ENDIAN
>  #define  __STRICT_ALIGNMENT
>  
>  #ifndef __FROM_SYS__ENDIAN
>  #include 
>  #endif
> +
>  #endif /* _MACHINE_ENDIAN_H_ */
> 
> 



Re: riscv64: faster setregs()

2022-03-21 Thread Jonathan Gray
On Mon, Mar 21, 2022 at 08:00:56PM +, Miod Vallat wrote:
> The current state of the kernel starts userland processes with register
> a0 pointing to the stack, with a comment mentioning this is copied from
> FreeBSD.
> 
> But while FreeBSD userland startup code (lib/csu) depends on this,
> OpenBSD binaries do not need this.
> 
> Thus, don't bother setting up a0 upon startup.
> 
> Completely untested.

tested with qemu-system-riscv64 userland

ok jsg@

> 
> Index: machdep.c
> ===
> RCS file: /OpenBSD/src/sys/arch/riscv64/riscv64/machdep.c,v
> retrieving revision 1.26
> diff -u -p -r1.26 machdep.c
> --- machdep.c 14 Sep 2021 12:03:49 -  1.26
> +++ machdep.c 21 Mar 2022 19:58:15 -
> @@ -418,7 +418,6 @@ setregs(struct proc *p, struct exec_pack
>   tf->tf_sstatus |= SSTATUS_FS_OFF;
>  
>   memset(tf, 0, sizeof(*tf));
> - tf->tf_a[0] = stack; // XXX Inherited from FreeBSD. Why?
>   tf->tf_sp = STACKALIGN(stack);
>   tf->tf_ra = pack->ep_entry;
>   tf->tf_sepc = pack->ep_entry;
> 
> 



Re: riscv64: minor tweaks to sig_machdep.c

2022-03-21 Thread Jonathan Gray
On Mon, Mar 21, 2022 at 08:24:05PM +, Miod Vallat wrote:
> Two simple changes here:
> - dumpframe() is not used by anything. I opted to remove it, but it
>   could be wrapped in #if 0 or #ifdef DEBUG if people want to keep it
>   around.
> - the /* NOTREACHED */ comment in sendsig() is obviously reachable, so
>   remove it and update the comment to match the new world order.
> 
> Completely untested (see a trend there?)

ok jsg@

> 
> Index: sig_machdep.c
> ===
> RCS file: /OpenBSD/src/sys/arch/riscv64/riscv64/sig_machdep.c,v
> retrieving revision 1.9
> diff -u -p -r1.9 sig_machdep.c
> --- sig_machdep.c 6 Oct 2021 15:46:03 -   1.9
> +++ sig_machdep.c 21 Mar 2022 20:21:57 -
> @@ -84,24 +84,6 @@ process_frame(struct proc *p)
>   return p->p_addr->u_pcb.pcb_tf;
>  }
>  
> -void dumpframe (char *msg, struct trapframe *tf, void *p)
> -{
> - int i;
> - printf("%s\n",msg);
> - printf("pc %lx ra %lx sp %lx tp %lx\n", tf->tf_sepc, tf->tf_ra, 
> tf->tf_sp, tf->tf_tp);
> - for(i = 0; i < 7; i++)
> - printf("%st%d %lx", (i==0)?"":", ", i, tf->tf_t[i]);
> - printf("\n");
> - for(i = 0; i < 12; i++)
> - printf("%ss%d %lx", (i==0)?"":", ", i, tf->tf_s[i]);
> - printf("\n");
> - for(i = 0; i < 8; i++)
> - printf("%sa%d %lx", (i==0)?"":", ", i, tf->tf_a[i]);
> - printf("\n");
> - if (p != NULL)
> - printf("fp %p\n", p);
> -}
> -
>  /*
>   * Send an interrupt to process.
>   *
> @@ -176,10 +158,10 @@ sendsig(sig_t catcher, int sig, sigset_t
>   frame.sf_sc.sc_cookie = (long)>sf_sc ^ p->p_p->ps_sigcookie;
>   if (copyout(, fp, sizeof(frame)) != 0) {
>   /*
> -  * Process has trashed its stack; give it an illegal
> -  * instruction to halt it in its tracks.
> +  * Process has trashed its stack; alert caller which
> +  * will give it an illegal instruction to halt it in
> +  * its tracks.
>*/
> - /* NOTREACHED */
>   return 1;
>   }
>  
> 
> 



Re: riscv64: fix kernel longjmp

2022-03-21 Thread Jonathan Gray
On Mon, Mar 21, 2022 at 08:03:40PM +, Miod Vallat wrote:
> Unlike userland, the OpenBSD kernel longjmp() function does not take a
> return value for setjmp as second argument, but is guaranteed to return
> nonzero.
> 
> The following diff makes sure the code matches this expectation.
> 
> Completely untested, yadda yadda.

powerpc64 also needs a change for this
ok jsg@ for both

Index: locore.S
===
RCS file: /cvs/src/sys/arch/powerpc64/powerpc64/locore.S,v
retrieving revision 1.43
diff -u -p -r1.43 locore.S
--- locore.S23 Jan 2021 12:10:08 -  1.43
+++ locore.S22 Mar 2022 00:34:40 -
@@ -562,7 +562,7 @@ longjmp:
ld  %r29, 0x98(%r3)
ld  %r30, 0xa0(%r3)
ld  %r31, 0xa8(%r3)
-   mr  %r4, %r3/* return val */
+   li  %r3, 1  /* return non-zero */
RETGUARD_CHECK(longjmp, %r11)
blr
 #endif

> 
> Index: support.S
> ===
> RCS file: /OpenBSD/src/sys/arch/riscv64/riscv64/support.S,v
> retrieving revision 1.2
> diff -u -p -r1.2 support.S
> --- support.S 12 May 2021 01:20:52 -  1.2
> +++ support.S 21 Mar 2022 20:02:03 -
> @@ -58,7 +58,7 @@ ENTRY(setjmp)
>   sd  s11, (11 * 8)(a0)
>   sd  ra, (12 * 8)(a0)
>  
> - /* Return value */
> + /* Return zero */
>   li  a0, 0
>   ret
>  END(setjmp)
> @@ -83,7 +83,7 @@ ENTRY(longjmp)
>   ld  s11, (11 * 8)(a0)
>   ld  ra, (12 * 8)(a0)
>  
> - /* Load the return value */
> - mv  a0, a1
> + /* Return nonzero */
> + li  a0, 1
>   ret
>  END(longjmp)
> 
> 



Re: sdmmc: simplify devlist2h

2022-03-17 Thread Jonathan Gray
On Thu, Mar 17, 2022 at 08:03:20AM +, Miod Vallat wrote:
> sys/dev/sdmmc/devlist2h.awk was based upon sys/dev/pcmcia/devlist2h.awk.
> The latter contains code to define optional CIS tuple overrides, which
> are not used in sdmmc - there is only one override and it is applied in
> sdmmc_check_cis_quirks().
> 
> The following diff removes this feature from devlist2h. As a result,
> there will no longer be SDMMC_CIS_* defines in sdmmcdevs.h.

ok jsg@

> 
> Index: devlist2h.awk
> ===
> RCS file: /OpenBSD/src/sys/dev/sdmmc/devlist2h.awk,v
> retrieving revision 1.2
> diff -u -p -r1.2 devlist2h.awk
> --- devlist2h.awk 2 Jun 2006 21:16:44 -   1.2
> +++ devlist2h.awk 17 Mar 2022 07:59:44 -
> @@ -80,7 +80,6 @@ NR == 1 {
>  $1 == "vendor" {
>   nvendors++
>  
> - vendorindex[$2] = nvendors; # record index for this name, 
> for later.
>   vendors[nvendors, 1] = $2;  # name
>   vendors[nvendors, 2] = $3;  # id
>   printf("#define\tSDMMC_VENDOR_%s\t%s\t", vendors[nvendors, 1],
> @@ -95,45 +94,8 @@ $1 == "product" {
>   products[nproducts, 1] = $2;# vendor name
>   products[nproducts, 2] = $3;# product id
>   products[nproducts, 3] = $4;# id
> -
> - f = 5;
> -
> - if ($4 == "{") {
> - products[nproducts, 3] = "SDMMC_PRODUCT_INVALID"
> - z = "{ "
> - for (i = 0; i < 4; i++) {
> - if (f <= NF) {
> - gsub("", " ", $f)
> - gsub("", "\t", $f)
> - gsub("", "\n", $f)
> - z = z $f " "
> - f++
> - }
> - else {
> - if (i == 3)
> - z = z "NULL "
> - else
> - z = z "NULL, "
> - }
> - }
> - products[nproducts, 4] = z $f
> - f++
> - }
> - else {
> - products[nproducts, 4] = "{ NULL, NULL, NULL, NULL }"
> - }
> - printf("#define\tSDMMC_CIS_%s_%s\t%s\n",
> - products[nproducts, 1], products[nproducts, 2],
> - products[nproducts, 4]) > hfile
>   printf("#define\tSDMMC_PRODUCT_%s_%s\t%s\n", products[nproducts, 1],
>   products[nproducts, 2], products[nproducts, 3]) > hfile
> -
> -#products[nproducts, 5] = collectline(f, line)
> -#
> -#printf("#define\tSDMMC_STR_%s_%s\t\"%s\"\n",
> -#products[nproducts, 1], products[nproducts, 2],
> -#products[nproducts, 5]) > hfile
> -
>   next
>  }
>  {
> 
> 



Re: bwfm@sdmmc: use symbolic constants for matching

2022-03-17 Thread Jonathan Gray
On Thu, Mar 17, 2022 at 08:05:38AM +, Miod Vallat wrote:
> The following diff declares the various devices bwfm@sdmmc checks for,
> and introduces no functional change.
> 
> Index: if_bwfm_sdio.c
> ===
> RCS file: /OpenBSD/src/sys/dev/sdmmc/if_bwfm_sdio.c,v
> retrieving revision 1.42
> diff -u -p -r1.42 if_bwfm_sdio.c
> --- if_bwfm_sdio.c2 Nov 2021 14:49:53 -   1.42
> +++ if_bwfm_sdio.c17 Mar 2022 07:59:57 -
> @@ -45,6 +45,7 @@
>  
>  #include 
>  
> +#include 
>  #include 
>  
>  #include 
> @@ -207,27 +208,27 @@ bwfm_sdio_match(struct device *parent, v
>  
>   /* Look for Broadcom. */
>   cis = >sc->sc_fn0->cis;
> - if (cis->manufacturer != 0x02d0)
> + if (cis->manufacturer != SDMMC_VENDOR_BROADCOM)
>   return 0;
>  
>   /* Look for supported chips. */
>   switch (cis->product) {
> - case 0x4324:
> - case 0x4330:
> - case 0x4334:
> - case 0x4329:
> - case 0x4335:
> - case 0x4339:
> - case 0x4345:
> - case 0x4354:
> - case 0x4356:
> - case 0x4359:
> - case 0xa887:/* BCM43143 */
> - case 0xa94c:/* BCM43340 */
> - case 0xa94d:/* BCM43341 */
> - case 0xa962:/* BCM43362 */
> - case 0xa9a6:/* BCM43430 */
> - case 0xa9bf:/* BCM43364 */
> + case SDMMC_PRODUCT_BROADCOM_BCM4324:
> + case SDMMC_PRODUCT_BROADCOM_BCM4329:
> + case SDMMC_PRODUCT_BROADCOM_BCM4330:
> + case SDMMC_PRODUCT_BROADCOM_BCM4334:
> + case SDMMC_PRODUCT_BROADCOM_BCM4335:
> + case SDMMC_PRODUCT_BROADCOM_BCM4339:
> + case SDMMC_PRODUCT_BROADCOM_BCM4345:
> + case SDMMC_PRODUCT_BROADCOM_BCM4354:
> + case SDMMC_PRODUCT_BROADCOM_BCM4356:
> + case SDMMC_PRODUCT_BROADCOM_BCM4359:
> + case SDMMC_PRODUCT_BROADCOM_BCM43143:
> + case SDMMC_PRODUCT_BROADCOM_BCM43340:
> + case SDMMC_PRODUCT_BROADCOM_BCM43341:
> + case SDMMC_PRODUCT_BROADCOM_BCM43362:
> + case SDMMC_PRODUCT_BROADCOM_BCM43430:
> + case SDMMC_PRODUCT_BROADCOM_BCM43364:
>   break;
>   default:
>   return 0;
> Index: sdmmcdevs
> ===
> RCS file: /OpenBSD/src/sys/dev/sdmmc/sdmmcdevs,v
> retrieving revision 1.8
> diff -u -p -r1.8 sdmmcdevs
> --- sdmmcdevs 11 May 2007 17:16:16 -  1.8
> +++ sdmmcdevs 17 Mar 2022 07:59:57 -
> @@ -24,6 +24,7 @@ vendor CGUYS0x0092  C-guys, Inc.
>  vendor TOSHIBA   0x0098  Toshiba
>  vendor SOCKETCOM 0x0104  Socket Communications, Inc.
>  vendor ATHEROS   0x0271  Atheros
> +vendor BROADCOM  0x02d0  Broadcom
>  vendor SYCHIP0x02db  SyChip Inc.
>  vendor SPECTEC   0x02fe  Spectec Computer Co., Ltd
>  vendor GLOBALSAT 0x0501  Globalsat Technology Co.
> @@ -42,6 +43,24 @@ product ATHEROSAR6001_80x0108  AR6001
>  product ATHEROS  AR6001_90x0109  AR6001
>  product ATHEROS  AR6001_a0x010a  AR6001
>  product ATHEROS  AR6001_b0x010b  AR6001
> +
> +/* Broadcom */
> +product  BROADCOM BCM43240x4324  BCM4324
> +product  BROADCOM BCM43290x4329  BCM4329

the whitespace in your broadcom additions is different

 product ATHEROS^IAR6001_b^I0x010b^IAR6001$
+$
+/* Broadcom */$
+product^IBROADCOM BCM4324^I0x4324^IBCM4324$
+product^IBROADCOM BCM4329^I0x4329^IBCM4329$

pcidevs and usbdevs are product VENDOR DEVICE\t0x1234\tDevice

ok jsg@ if that is fixed

the existing atheros entries also get this wrong

> +product  BROADCOM BCM43300x4330  BCM4330
> +product  BROADCOM BCM43340x4334  BCM4334
> +product  BROADCOM BCM43350x4335  BCM4335
> +product  BROADCOM BCM43390x4339  BCM4339
> +product  BROADCOM BCM43450x4345  BCM4345
> +product  BROADCOM BCM43540x4354  BCM4354
> +product  BROADCOM BCM43560x4356  BCM4356
> +product  BROADCOM BCM43590x4359  BCM4359
> +product  BROADCOM BCM43143   0xa887  BCM43143
> +product  BROADCOM BCM43340   0xa94c  BCM43340
> +product  BROADCOM BCM43341   0xa94d  BCM43341
> +product  BROADCOM BCM43362   0xa962  BCM43362
> +product  BROADCOM BCM43430   0xa9a6  BCM43430
> +product  BROADCOM BCM43364   0xa9bf  BCM43364
>  
>  /* C-guys, Inc. */
>  product CGUYS TIACX100   0x0001  TI ACX100 SD-Link11b WiFi Card
> 
> 



Re: add -k / --keep for gzip(1)

2022-03-03 Thread Jonathan Gray
On Thu, Mar 03, 2022 at 01:13:16PM +0100, Solene Rapenne wrote:
> The following diff adds support for -k flag to keep the input file for
> gzip / compress when compressing, and the input file (the compressed
> one) for gunzip / uncompress

what case is not covered by -c > file ?

> 
> This will improve uses cases like: zcat -f "${file}" > "${file}.gz"

the result won't be gzip compressed
unclear what you have in mind



Re: Multiple issues with radeondrm startup code

2022-02-13 Thread Jonathan Gray
On Mon, Feb 14, 2022 at 12:05:44AM -0700, Ted Bullock wrote:
> 
> On 2022-02-13 11:02 p.m., Jonathan Gray wrote:
> > On Sun, Feb 13, 2022 at 12:22:38PM -0700, Ted Bullock wrote:
> > > On 2022-02-12 6:46 p.m., Jonathan Gray wrote:
> > > > I will review further when you drop the function.
> > > 
> > > Alright try this again,
> > 
> > I have committed some parts of this, with one commit per specific issue.
> > 
> > pa_memex NULL test
> > sparc64 ifndef
> > drm_attach_pci return test
> > 
> > the result of pci_mapreg_type() is already fine as it does
> > _PCI_MAPREG_TYPEBITS() which which masks the bits
> > 
> > I still find this diff hard to follow as you are moving code around.
> > The arrays of bar information can be dropped.
> When you cherrypicked fixes, you missed the for loop as per the initial
> mail, the type checks are incorrect and won't match. You need the helper
> macros since those types are bitmaps not types. This has been like this
> since 1.71 (Oct 2020)
> 
> for (i = PCI_MAPREG_START; i < PCI_MAPREG_END; i += 4) {
>   type = pci_mapreg_type(pa->pa_pc, pa->pa_tag, i);
>   if (type == PCI_MAPREG_TYPE_IO) {
> 
>   pci_mapreg_map(pa, i, type, 0, NULL,
>   >rio_mem, NULL, >rio_mem_size, 0);
>   break;
>   }
>   if (type == PCI_MAPREG_MEM_TYPE_64BIT)
> 
>   i += 4;
> }

type = _PCI_MAPREG_TYPEBITS(pci_conf_read(pc, tag, reg));
if (type == 1) {
pci_mapreg_map();
break;
}
if (type == 4)
i += 4;

---

x = pci_conf_read(pc, tag, reg);
if ((x & 1) == 1)
type = x & 1;
else
type = x & 7;

if (type == 1) {
pci_mapreg_map();
break;
}
if (type == 4)
i += 4;

which other bits do you expect?

001 io space
000 32-bit mem space
100 64-bit mem space



Re: Multiple issues with radeondrm startup code

2022-02-13 Thread Jonathan Gray
On Sun, Feb 13, 2022 at 12:22:38PM -0700, Ted Bullock wrote:
> On 2022-02-12 6:46 p.m., Jonathan Gray wrote:
> > I will review further when you drop the function.
> 
> Alright try this again,

I have committed some parts of this, with one commit per specific issue.

pa_memex NULL test
sparc64 ifndef
drm_attach_pci return test

the result of pci_mapreg_type() is already fine as it does
_PCI_MAPREG_TYPEBITS() which which masks the bits

I still find this diff hard to follow as you are moving code around.
The arrays of bar information can be dropped.

> 
> diff b5c3be43fcdaf7cbd7d070c07746b451413f6b4a 
> 453e49da7f0804392d6d51fb578cfd8255f4fb77
> blob - a2d53f752bccb1ab54993ec2a7d5791ec2216e0a
> blob + f6353eb5f76e0ae0e21277f82e86b70b36dd401d
> --- sys/dev/pci/drm/radeon/radeon_kms.c
> +++ sys/dev/pci/drm/radeon/radeon_kms.c
> @@ -494,14 +494,13 @@ radeondrm_attach_kms(struct device *parent, struct dev
>   struct pci_attach_args  *pa = aux;
>   const struct pci_device_id *id_entry;
>   int  is_agp;
> - pcireg_t type;
> - int  i;
> - uint8_t  rmmio_bar;
>   paddr_t  fb_aper;
> -#if !defined(__sparc64__)
>   pcireg_t addr, mask;
> - int  s;
> -#endif
> + int  s, error;
> + uint8_t  i, mm;
> + pcireg_t type[6];
> + int  bar[6];
> + const uint8_tBAR[6] = {0x10,0x14,0x18,0x1C,0x20,0x24};
>  
>  #if defined(__sparc64__) || defined(__macppc__)
>   extern int fbnode;
> @@ -542,75 +541,115 @@ radeondrm_attach_kms(struct device *parent, struct dev
>  #endif
>  #endif
>  
> -#define RADEON_PCI_MEM   0x10
> + /* Start PCI BAR mappings */
> + bar[0] = pci_mapreg_probe(rdev->pc, rdev->pa_tag, BAR[0], [0]);
> + bar[1] = pci_mapreg_probe(rdev->pc, rdev->pa_tag, BAR[1], [1]);
> + bar[2] = pci_mapreg_probe(rdev->pc, rdev->pa_tag, BAR[2], [2]);
> + bar[3] = pci_mapreg_probe(rdev->pc, rdev->pa_tag, BAR[3], [3]);
> + bar[4] = pci_mapreg_probe(rdev->pc, rdev->pa_tag, BAR[4], [4]);
> + bar[5] = pci_mapreg_probe(rdev->pc, rdev->pa_tag, BAR[5], [5]);
>  
> - type = pci_mapreg_type(pa->pa_pc, pa->pa_tag, RADEON_PCI_MEM);
> - if (PCI_MAPREG_TYPE(type) != PCI_MAPREG_TYPE_MEM ||
> - pci_mapreg_info(pa->pa_pc, pa->pa_tag, RADEON_PCI_MEM,
> - type, >fb_aper_offset, >fb_aper_size, NULL)) {
> - printf(": can't get frambuffer info\n");
> + /* Framebuffer offset is saved at BAR0 */
> + if (!bar[0] || PCI_MAPREG_TYPE(type[0]) != PCI_MAPREG_TYPE_MEM) {
> + printf(": BAR0 (framebuffer) is not memory mapped.\n");
> + radeon_fatal_error = 1;
>   return;
>   }
> -#if !defined(__sparc64__)
> +
> + error = pci_mapreg_info(rdev->pc, rdev->pa_tag, BAR[0],
> + type[0], >fb_aper_offset, >fb_aper_size, NULL);
> + if (error) {
> + printf(": Cannot get FB parameters from BAR0 (%d).\n", error);
> + radeon_fatal_error = 1;
> + return;
> + }
> +
>   if (rdev->fb_aper_offset == 0) {
>   bus_size_t start, end;
>   bus_addr_t base;
>  
> + KASSERT(pa->pa_memex != NULL);
> +
>   start = max(PCI_MEM_START, pa->pa_memex->ex_start);
>   end = min(PCI_MEM_END, pa->pa_memex->ex_end);
> - if (pa->pa_memex == NULL ||
> - extent_alloc_subregion(pa->pa_memex, start, end,
> - rdev->fb_aper_size, rdev->fb_aper_size, 0, 0, 0, )) {
> - printf(": can't reserve framebuffer space\n");
> +
> + error = extent_alloc_subregion(pa->pa_memex, start, end,
> + rdev->fb_aper_size, rdev->fb_aper_size, 0, 0, 0, );
> + if (error) {
> + printf(": Cannot allocate framebuffer (%d).\n", error);
> + radeon_fatal_error = 1;
>   return;
>   }
> - pci_conf_write(pa->pa_pc, pa->pa_tag, RADEON_PCI_MEM, base);
> - if (PCI_MAPREG_MEM_TYPE(type) == PCI_MAPREG_MEM_TYPE_64BIT)
> - pci_conf_write(pa->pa_pc, pa->pa_tag,
> - RADEON_PCI_MEM + 4, (uint64_t)base >> 32);
> +
> + /* Set FB aperature to 32bit space for MI purposes */
> + switch (PCI_MAPREG_MEM_TYPE(type[0])) {
> +

Re: mvpcie(4): fix panic if "reset-gpios" is not available

2022-02-13 Thread Jonathan Gray
On Sun, Feb 13, 2022 at 03:17:27PM +0100, Theo Buehler wrote:
> On Sun, Feb 13, 2022 at 02:30:21PM +0100, Tobias Heider wrote:
> > OF_getproplen() will return -1 if "reset-gpios" is not found which
> > currently causes a panic:
> > 
> > panic: malloc: allocation too large, type = 2, size = 4294967295
> > 
> > Below is a fix.
> 
> There are more of these:
> 
> dev/ofw/ofw_regulator.c:336:if ((glen = OF_getproplen(node, "gpios")) <= 
> 0)
> dev/ofw/ofw_regulator.c:338:if ((slen = OF_getproplen(node, "states")) <= 
> 0)
> dev/ofw/ofw_regulator.c:401:if ((glen = OF_getproplen(node, "gpios")) <= 
> 0)
> dev/ofw/ofw_regulator.c:403:if ((slen = OF_getproplen(node, "states")) <= 
> 0)
> 
> where glen and slen are size_t and

Index: ofw_regulator.c
===
RCS file: /cvs/src/sys/dev/ofw/ofw_regulator.c,v
retrieving revision 1.15
diff -u -p -r1.15 ofw_regulator.c
--- ofw_regulator.c 23 Dec 2020 11:58:36 -  1.15
+++ ofw_regulator.c 14 Feb 2022 00:55:28 -
@@ -328,8 +328,7 @@ regulator_gpio_get(int node)
 {
uint32_t *gpio, *gpios, *states;
uint32_t idx, value;
-   size_t glen, slen;
-   int i;
+   int glen, slen, i;
 
pinctrl_byname(node, "default");
 
@@ -377,10 +376,9 @@ int
 regulator_gpio_set(int node, uint32_t value)
 {
uint32_t *gpio, *gpios, *states;
-   size_t glen, slen;
uint32_t min, max;
uint32_t idx;
-   int i;
+   int glen, slen, i;
 
pinctrl_byname(node, "default");
 



Re: Import seq(1) from FreeBSD

2022-02-13 Thread Jonathan Gray
On Sun, Feb 13, 2022 at 12:07:31PM -0800, Greg Steuck wrote:
> Ingo Schwarze  writes:
> 
> > Hi Todd,
> >
> > in view of your arguments and sthen@'s OK, i'm also OK with this
> > going in.  I think a bit of code cleanup and copy editing in the
> > manual page may be useful afterwards, but that can be done in the
> > tree, no need for playing patch ping pong.
> 
> I noticed that despite the OKs the code didn't submitted. Should we
> revive this diff now and continue in the tree?
> 
> I have vested interest: I don't want to fix up lang/ghc test suite which
> is full of seq(1).
> 
> Thanks
> Greg

here is a port of the plan 9 seq from the last time this came up

--- /dev/null   Mon Feb 14 10:16:42 2022
+++ seq.c   Wed Mar 24 16:24:15 2021
@@ -0,0 +1,135 @@
+/* $OpenBSD$   */
+
+/*
+ * Copyright 2021 Plan 9 Foundation
+ * 
+ * Permission is hereby granted, free of charge, to any person obtaining
+ * a copy of this software and associated documentation files (the
+ * "Software"), to deal in the Software without restriction, including
+ * without limitation the rights to use, copy, modify, merge, publish,
+ * distribute, sublicense, and/or sell copies of the Software, and to
+ * permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ * 
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ * 
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
+ * IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY
+ * CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
+ * TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
+ * SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+double min = 1.0;
+double max = 0.0;
+double incr = 1.0;
+intconstant = 0;
+intnsteps;
+char   *format;
+
+void
+usage(void)
+{
+   fprintf(stderr, "usage: seq [-fformat] [-w] [first [incr]] last\n");
+   exit(1);
+}
+
+void
+buildfmt(void)
+{
+   char *dp;
+   int w, p, maxw, maxp;
+   static char fmt[16];
+   char buf[32];
+   double val;
+
+   format = "%g\n";
+   if (!constant)
+   return;
+   maxw = 0;
+   maxp = 0;
+   for (val = min; val <= max; val += incr) {
+   sprintf(buf, "%g", val);
+   if (strchr(buf, 'e') != 0)
+   return;
+   dp = strchr(buf,'.');
+   w = dp == 0 ? strlen(buf) : dp - buf;
+   p = dp == 0 ? 0 : strlen(strchr(buf,'.') + 1);
+   if (w > maxw)
+   maxw = w;
+   if (p > maxp)
+   maxp = p;
+   }
+   if (maxp > 0)
+   maxw += maxp + 1;
+   sprintf(fmt, "%%%d.%df\n", maxw, maxp);
+   format = fmt;
+}
+
+int
+main(int argc, char *argv[])
+{
+   int j, n, c;
+   char buf[256], ffmt[4096];
+   double val;
+
+   if (pledge("stdio", NULL) == -1)
+   err(1, "pledge");
+
+   while ((c = getopt(argc, argv, "wf:")) != -1)
+   switch (c) {
+   case 'w':
+   constant++;
+   break;
+   case 'f':
+   format = optarg;
+   if (format[strlen(format) - 1] != '\n') {
+   sprintf(ffmt, "%s\n", format);
+   format = ffmt;
+   }
+   break;
+   default:
+   goto out;
+   }
+   argc -= optind;
+   argv += optind;
+out:
+   if (argc < 1 || argc > 3)
+   usage();
+   max = atof(argv[argc - 1]);
+   if (argc > 1)
+   min = atof(argv[0]);
+   if (argc > 2)
+   incr = atof(argv[1]);
+   if (incr == 0)
+   errx(1, "zero increment");
+   if (!format)
+   buildfmt();
+   if (incr > 0) {
+   for (val = min; val <= max; val += incr) {
+   n = sprintf(buf, format, val);
+   if (constant)
+   for (j=0; buf[j] == ' '; j++)
+   buf[j] = '0';
+   write(1, buf, n);
+   }
+   } else {
+   for (val = min; val >= max; val += incr) {
+   n = sprintf(buf, format, val);
+   if (constant)
+   for (j=0; buf[j] == ' '; j++)
+   buf[j] = '0';
+   write(1, buf, n);
+   }
+   }
+   return 0;
+}
--- /dev/null   Mon Feb 14 10:16:46 2022
+++ seq.1   

Re: mvpcie(4): fix panic if "reset-gpios" is not available

2022-02-13 Thread Jonathan Gray
On Mon, Feb 14, 2022 at 01:31:57AM +1100, Jonathan Gray wrote:
> On Sun, Feb 13, 2022 at 03:17:27PM +0100, Theo Buehler wrote:
> > On Sun, Feb 13, 2022 at 02:30:21PM +0100, Tobias Heider wrote:
> > > OF_getproplen() will return -1 if "reset-gpios" is not found which
> > > currently causes a panic:
> > > 
> > > panic: malloc: allocation too large, type = 2, size = 4294967295
> > > 
> > > Below is a fix.
> > 
> > There are more of these:
> > 
> > dev/ofw/ofw_regulator.c:336:if ((glen = OF_getproplen(node, "gpios")) 
> > <= 0)
> > dev/ofw/ofw_regulator.c:338:if ((slen = OF_getproplen(node, "states")) 
> > <= 0)
> > dev/ofw/ofw_regulator.c:401:if ((glen = OF_getproplen(node, "gpios")) 
> > <= 0)
> > dev/ofw/ofw_regulator.c:403:if ((slen = OF_getproplen(node, "states")) 
> > <= 0)
> > 
> > where glen and slen are size_t and
> > 
> > arch/sparc64/sparc64/pmap.c:806:sz = OF_getproplen(memh, 
> > "available") + sizeof(struct mem_region);
> > 
> > with a size_t sz.
> 
> another in imxspi

some more

ssdfb.c has a size_t sc_gpiolen but stores the
result in a ssize_t and tests that before storing to it

Index: dev/fdt/simpleamp.c
===
RCS file: /cvs/src/sys/dev/fdt/simpleamp.c,v
retrieving revision 1.1
diff -u -p -r1.1 simpleamp.c
--- dev/fdt/simpleamp.c 10 Jun 2020 23:59:07 -  1.1
+++ dev/fdt/simpleamp.c 13 Feb 2022 14:35:09 -
@@ -42,7 +42,7 @@ struct simpleamp_softc {
struct dai_device   sc_dai;
 
uint32_t*sc_gpio;
-   size_t  sc_gpiolen;
+   int sc_gpiolen;
uint32_tsc_vcc;
 };
 
Index: arch/arm64/dev/aplhidev.c
===
RCS file: /cvs/src/sys/arch/arm64/dev/aplhidev.c,v
retrieving revision 1.4
diff -u -p -r1.4 aplhidev.c
--- arch/arm64/dev/aplhidev.c   11 Dec 2021 20:36:26 -  1.4
+++ arch/arm64/dev/aplhidev.c   13 Feb 2022 14:33:57 -
@@ -117,7 +117,7 @@ struct aplhidev_softc {
uint8_t sc_msgid;
 
uint32_t*sc_gpio;
-   size_t  sc_gpiolen;
+   int sc_gpiolen;
 
struct device   *sc_kbd;
uint8_t sc_kbddesc[APLHIDEV_DESC_MAX];



Re: mvpcie(4): fix panic if "reset-gpios" is not available

2022-02-13 Thread Jonathan Gray
On Sun, Feb 13, 2022 at 03:17:27PM +0100, Theo Buehler wrote:
> On Sun, Feb 13, 2022 at 02:30:21PM +0100, Tobias Heider wrote:
> > OF_getproplen() will return -1 if "reset-gpios" is not found which
> > currently causes a panic:
> > 
> > panic: malloc: allocation too large, type = 2, size = 4294967295
> > 
> > Below is a fix.
> 
> There are more of these:
> 
> dev/ofw/ofw_regulator.c:336:if ((glen = OF_getproplen(node, "gpios")) <= 
> 0)
> dev/ofw/ofw_regulator.c:338:if ((slen = OF_getproplen(node, "states")) <= 
> 0)
> dev/ofw/ofw_regulator.c:401:if ((glen = OF_getproplen(node, "gpios")) <= 
> 0)
> dev/ofw/ofw_regulator.c:403:if ((slen = OF_getproplen(node, "states")) <= 
> 0)
> 
> where glen and slen are size_t and
> 
> arch/sparc64/sparc64/pmap.c:806:sz = OF_getproplen(memh, "available") 
> + sizeof(struct mem_region);
> 
> with a size_t sz.

another in imxspi

Index: imxspi.c
===
RCS file: /cvs/src/sys/dev/fdt/imxspi.c,v
retrieving revision 1.3
diff -u -p -r1.3 imxspi.c
--- imxspi.c31 Oct 2021 15:12:00 -  1.3
+++ imxspi.c13 Feb 2022 14:21:01 -
@@ -91,7 +91,7 @@ struct imxspi_softc {
int  sc_node;
 
uint32_t*sc_gpio;
-   size_t   sc_gpiolen;
+   int  sc_gpiolen;
 
struct rwlocksc_buslock;
struct spi_controllersc_tag;
@@ -179,7 +179,7 @@ imxspi_attachhook(struct device *self)
clock_enable(sc->sc_node, NULL);
 
sc->sc_gpiolen = OF_getproplen(sc->sc_node, "cs-gpios");
-   if (sc->sc_gpiolen) {
+   if (sc->sc_gpiolen > 0) {
sc->sc_gpio = malloc(sc->sc_gpiolen, M_DEVBUF, M_WAITOK);
OF_getpropintarray(sc->sc_node, "cs-gpios",
sc->sc_gpio, sc->sc_gpiolen);



Re: Multiple issues with radeondrm startup code

2022-02-12 Thread Jonathan Gray
On Sat, Feb 12, 2022 at 02:42:16PM -0700, Ted Bullock wrote:
> On 2022-02-11 7:16 p.m., Jonathan Gray wrote:
> > I'm not so keen on another function and putting bar information into
> >  local arrays seems odd.
> 
> Are there technical reasons for not wanting a function? I know that
> pulling in the linux kernel code is probably a big headache, does it
> have to do with that?

Look at other pci drivers and you will see they deal with
bars in attach.

> 
> As to the arrays, I chose to use a idiom for searching the BARs
> deliberately that (to me) reads as dramatically simpler and clearer. The
> BAR code already in tree for this driver is a mess with inline global
> defines sometimes, direct hex codes other times and assigned variables
> yet other times.

Drivers normally look at one bar and have a define for the offset
used in attach.  Iterating over bars and generation specific tests
aren't the norm.  The linux interfaces all want to deal with a bar
number instead of of offset.  For radeon linux does it in
radeon_device_init().

> 
> > It would be easier to review changes if you would stick to either 
> > changing or moving code, not both at the same time.
> 
> Yeah, moving/changing does make the review harder sorry about that :(
> 
> > For example when iterating over bars you lost the part that skips one
> > if a bar is 64-bit.
> 
> No. This was deliberate and not lost, I looked at this very carefully.
> 
> bar[i] && PCI_MAPREG_TYPE(type[i]) == PCI_MAPREG_TYPE_IO
> 
> This should not match to the top half of a 64bit memory mapped
> BAR, so having a special code to modify the loop to handle such a
> condition is just adding needless complexity.
> 
> For a memory BAR, bit 0 is always 0.
> For an IO BAR, bit 0 is 1.
> 
> Since this loop is explicitly searching for an IO bar, we should not
> need to handle MM semantics when searching, the simple match for the
> first bit should be enough. Is this incorrect?
> 
> > Generally bool is avoided in kernel code, it was added to not have
> > to change drm code.
> 
> No problem, the function is probably more correctly written with integer
> returns accurately describing problems from errno.h
> 
> > We use 'if (' not 'if(' as well.
> 
> Oops; I missed this despite staring at the code for a week.
> 
> Thanks for taking the time to review :) Much appreciated, tentatively I
> left the function in but with the changed return type and adjusted to
> your other notes, if it is a problem this can of course be amended.

I will review further when you drop the function.



Re: Multiple issues with radeondrm startup code

2022-02-11 Thread Jonathan Gray
On Fri, Feb 11, 2022 at 06:42:11PM -0700, Ted Bullock wrote:
> Hey,
> 
> I've found some problems with the radeondrm initialization
> codepath (radeon_kms.c). Before I start, I should mention that I am
> working on some diffs to remove a bunch of the sparc64 MD ifdef's as
> well. In radeondrm_attach_kms:
> 
> starting from line 545
> ==
> #define RADEON_PCI_MEM0x10
> ^^ inline defines for bar registers reads as weird/bad to me
> 
>   type = pci_mapreg_type(pa->pa_pc, pa->pa_tag, RADEON_PCI_MEM);
>   if (PCI_MAPREG_TYPE(type) != PCI_MAPREG_TYPE_MEM ||
>   pci_mapreg_info(pa->pa_pc, pa->pa_tag, RADEON_PCI_MEM,
>   type, >fb_aper_offset, >fb_aper_size, NULL)) {
>   printf(": can't get frambuffer info\n");
>   return;
> ^^
> Should set radeon_fatal_error = 1 before returning
>   }
> #if !defined(__sparc64__)
> ^^ I've tested this on sparc64 xvr-100, this ifdef isn't needed
>   if (rdev->fb_aper_offset == 0) {
>   bus_size_t start, end;
>   bus_addr_t base;
> 
>   start = max(PCI_MEM_START, pa->pa_memex->ex_start);
> Potential NULL dereference ->
>   end = min(PCI_MEM_END, pa->pa_memex->ex_end);
> And here --->^^
>   if (pa->pa_memex == NULL ||
> 
> Obviously just move this NULL check up two lines
>   extent_alloc_subregion(pa->pa_memex, start, end,
>   rdev->fb_aper_size, rdev->fb_aper_size, 0, 0, 0, )) {
>   printf(": can't reserve framebuffer space\n");
>   return;
> ^^
> Should set radeon_fatal_error = 1 before returning
>   }
>   pci_conf_write(pa->pa_pc, pa->pa_tag, RADEON_PCI_MEM, base);
>   if (PCI_MAPREG_MEM_TYPE(type) == PCI_MAPREG_MEM_TYPE_64BIT)
>   pci_conf_write(pa->pa_pc, pa->pa_tag,
>   RADEON_PCI_MEM + 4, (uint64_t)base >> 32);
> This evaluates to zero on all architectures --->
>   rdev->fb_aper_offset = base;
>   }
> #endif
> 
>   for (i = PCI_MAPREG_START; i < PCI_MAPREG_END; i += 4) {
> ^^
> This is an awkward (bad) idiom to iterate through BARs
>   type = pci_mapreg_type(pa->pa_pc, pa->pa_tag, i);
>   if (type == PCI_MAPREG_TYPE_IO) {
> 
> This is a bitmap, you cannot use it like this, the correct usage
> would be PCI_MAPREG_TYPE(type) == PCI_MAPREG_TYPE_IO
> 
>   pci_mapreg_map(pa, i, type, 0, NULL,
>   >rio_mem, NULL, >rio_mem_size, 0);
>   break;
>   }
>   if (type == PCI_MAPREG_MEM_TYPE_64BIT)
>   
> Same as above, this is incorrect usage
>   i += 4;
>   }
> 
> A note about this for loop. This loop was broken in revision 1.72 to
> support radeon devices on POWER9 systems. These registers are available
> (I believe) through the MMIO BAR so people haven't noticed that it's
> broken.  I don't know if ALL devices work like that, though certainly
> most do, if so this entire loop could possibly be removed and just rely
> on MMIO access to these registers.
> 
>   if (rdev->family >= CHIP_BONAIRE) {
>   type = pci_mapreg_type(pa->pa_pc, pa->pa_tag, 0x18);
>-->
> If putting an inline #define was appropriate earlier why not here
>   if (PCI_MAPREG_TYPE(type) != PCI_MAPREG_TYPE_MEM ||
>   pci_mapreg_map(pa, 0x18, type, BUS_SPACE_MAP_LINEAR, NULL,
> And here  >
>   >doorbell.bsh, >doorbell.base,
>   >doorbell.size, 0)) {
>   printf(": can't map doorbell space\n");
>   return;
>   ^^
> Should set radeon_fatal_error = 1 before returning
>   }
>   rdev->doorbell.ptr = bus_space_vaddr(rdev->memt,
>   rdev->doorbell.bsh);
>   }
> 
>   if (rdev->family >= CHIP_BONAIRE)
>   rmmio_bar = 0x24;
>   else
>   rmmio_bar = 0x18;
> 
>   type = pci_mapreg_type(pa->pa_pc, pa->pa_tag, rmmio_bar);
>   if (PCI_MAPREG_TYPE(type) != PCI_MAPREG_TYPE_MEM ||
>   pci_mapreg_map(pa, rmmio_bar, type, BUS_SPACE_MAP_LINEAR, NULL,
>   >rmmio_bsh, >rmmio_base, >rmmio_size, 0)) {
>   printf(": can't map rmmio space\n");
>   return;
>   ^^
> Should set radeon_fatal_error = 1 before returning
>   }
>   rdev->rmmio = bus_space_vaddr(rdev->memt, rdev->rmmio_bsh);
> 
> #if !defined(__sparc64__)
> ^
> 

Re: Adding POSIX c99 compiler wrapper script

2022-02-11 Thread Jonathan Gray
On Fri, Feb 11, 2022 at 04:13:22PM -0600, Joe Nelson wrote:
> 
> I noticed that OpenBSD lacks the POSIX "c99" compiler wrapper.
> https://pubs.opengroup.org/onlinepubs/9699919799/utilities/c99.html

"[CD] C-Language Development Utilities 
The functionality described is optional."

I don't see the point in adding a c89 c99 c11 c17 or
c++98 c++03 c++11 c++14 c++17 c++20 c++23 wrapper.

It is easy enough to specify -std and many people would
be using the flags that add gnu extensions instead.

> 
> Is it missing because the community feels it's ill conceived, or just
> because nobody stepped up to implement it? If the latter, I can
> contribute a patch to add it as a wrapper around cc.
> 
> A few questions about the desired behavior:
> 
> * If the user passes options not listed by POSIX, should the wrapper
>   die with a usage error, or pass them silently to the underlying
>   compiler? The FreeBSD implementation [0] does strict checking, while
>   NetBSD [1] and GCC on Debian [2] pass along all parameters.
> 
> * Should it add -pedantic as well as -std=c99?
> 
> * Is /usr/bin/c99 something that should go in OpenBSD base, or in
>   compiler ports?
> 
> 0: https://github.com/freebsd/freebsd-src/blob/main/usr.bin/c99/c99.c
> 1: https://github.com/NetBSD/src/blob/trunk/usr.bin/c99/c99.sh
> 2: https://salsa.debian.org/toolchain-team/gcc-defaults/-/blob/master/c99
> 
> 



Re: explicit_bzero vs ASAN on linux

2022-02-09 Thread Jonathan Gray
On Wed, Feb 09, 2022 at 09:09:35AM +0100, Theo Buehler wrote:
> In libressl-portable we run the explicit_bzero tests as part of the
> builds. If we enable ASAN on linux, this test segfaults in
> __interceptor_memmem() in the two test_with{,out}_bzero() functions,
> presumably because the sigaltstack magic is too low level for ASAN to
> grok.
> 
> Would the patch below that disables ASAN for these functions be
> acceptable or shold we maintain it in the libressl-portable repo?
> 
> https://github.com/google/sanitizers/wiki/AddressSanitizer#turning-off-instrumentation
> 
> Index: explicit_bzero.c
> ===
> RCS file: /cvs/src/regress/lib/libc/explicit_bzero/explicit_bzero.c,v
> retrieving revision 1.8
> diff -u -p -r1.8 explicit_bzero.c
> --- explicit_bzero.c  9 Feb 2022 07:48:15 -   1.8
> +++ explicit_bzero.c  9 Feb 2022 07:56:43 -
> @@ -26,6 +26,12 @@
>  #define ASSERT_NE(a, b) assert((a) != (b))
>  #define ASSERT_GE(a, b) assert((a) >= (b))
>  
> +#if defined(__clang__) || defined (__GNUC__)
> +#define ATTRIBUTE_NO_SANITIZE_ADDRESS __attribute__((no_sanitize_address))
> +#else
> +#define ATTRIBUTE_NO_SANITIZE_ADDRESS
> +#endif
> +

clang also defines __GNUC__, not sure if clang-cl is different

with clang 13.0.0 still 4.2.1

#define __GNUC__ 4
#define __GNUC_MINOR__ 2
#define __GNUC_PATCHLEVEL__ 1

I was curious how actual gcc 4.2.1 would handle this so I tried on
sparc64.  The test still passes but there is a warning about an unknown
attribute.

 run-regress-explicit_bzero 
cc -O2 -pipe   -MD -MP  -c 
/usr/src/regress/lib/libc/explicit_bzero/explicit_bzero.c
/usr/src/regress/lib/libc/explicit_bzero/explicit_bzero.c:149: warning: 
'no_sanitize_address' attribute directive ignored
/usr/src/regress/lib/libc/explicit_bzero/explicit_bzero.c:160: warning: 
'no_sanitize_address' attribute directive ignored
cc   -o explicit_bzero explicit_bzero.o 
./explicit_bzero

>  /* 128 bits of random data. */
>  static const char secret[16] = {
>   0xa0, 0x6c, 0x0c, 0x81, 0xba, 0xd8, 0x5b, 0x0c,
> @@ -138,7 +144,7 @@ count_secrets(const char *buf)
>   return (res);
>  }
>  
> -static char *
> +ATTRIBUTE_NO_SANITIZE_ADDRESS static char *
>  test_without_bzero(void)
>  {
>   char buf[SECRETBYTES];
> @@ -149,7 +155,7 @@ test_without_bzero(void)
>   return (res);
>  }
>  
> -static char *
> +ATTRIBUTE_NO_SANITIZE_ADDRESS static char *
>  test_with_bzero(void)
>  {
>   char buf[SECRETBYTES];
> 
> 



Re: Use km_alloc(9) in drm

2022-02-06 Thread Jonathan Gray
On Sat, Feb 05, 2022 at 02:26:48PM +0100, Mark Kettenis wrote:
> > Date: Sat, 5 Feb 2022 22:34:10 +1100
> > From: Jonathan Gray 
> > 
> > On Sat, Feb 05, 2022 at 11:44:03AM +0100, Mark Kettenis wrote:
> > > We want to get rid of the uvm_km_valloc() interfaces in favour of
> > > km_alloc().  This changes the calls in drm(4) over.  The kv_physwait
> > > struct is made static to prevent collission with a symbol in
> > > vm_machdep.c on some architectures.  The goal is to move this into
> > > uvm/uvm_km.c eventually.
> > > 
> > > Just to make sure I didn't screw the conversion up somehow a few tests
> > > on a mix of inteldrm(4) and amdgpu(4) systems would be good.
> > > 
> > > ok?
> > > 
> > > 
> > > Index: dev/pci/drm/drm_linux.c
> > > ===
> > > RCS file: /cvs/src/sys/dev/pci/drm/drm_linux.c,v
> > > retrieving revision 1.89
> > > diff -u -p -r1.89 drm_linux.c
> > > --- dev/pci/drm/drm_linux.c   21 Jan 2022 23:49:36 -  1.89
> > > +++ dev/pci/drm/drm_linux.c   5 Feb 2022 10:40:22 -
> > > @@ -564,6 +564,11 @@ __pagevec_release(struct pagevec *pvec)
> > >   pagevec_reinit(pvec);
> > >  }
> > >  
> > > +static struct kmem_va_mode kv_physwait = {
> > > + .kv_map = _map,
> > > + .kv_wait = 1,
> > > +};
> > > +
> > >  void *
> > >  kmap(struct vm_page *pg)
> > >  {
> > > @@ -572,7 +577,7 @@ kmap(struct vm_page *pg)
> > >  #if defined (__HAVE_PMAP_DIRECT)
> > >   va = pmap_map_direct(pg);
> > >  #else
> > > - va = uvm_km_valloc_wait(phys_map, PAGE_SIZE);
> > > + va = (vaddr_t)km_alloc(PAGE_SIZE, _physwait, _none, _waitok);
> > >   pmap_kenter_pa(va, VM_PAGE_TO_PHYS(pg), PROT_READ | PROT_WRITE);
> > >   pmap_update(pmap_kernel());
> > >  #endif
> > > @@ -589,7 +594,7 @@ kunmap_va(void *addr)
> > >  #else
> > >   pmap_kremove(va, PAGE_SIZE);
> > >   pmap_update(pmap_kernel());
> > > - uvm_km_free_wakeup(phys_map, va, PAGE_SIZE);
> > > + km_free((void *)va, PAGE_SIZE, _physwait, _none);
> > >  #endif
> > >  }
> > >  
> > > @@ -624,7 +629,8 @@ vmap(struct vm_page **pages, unsigned in
> > >   paddr_t pa;
> > >   int i;
> > >  
> > > - va = uvm_km_valloc(kernel_map, PAGE_SIZE * npages);
> > > + va = (vaddr_t)km_alloc(PAGE_SIZE * npages, _any, _none,
> > > + _nowait);
> > 
> > this could be kd_waitok as the linux vmap() uses might_sleep()
> > but I suppose that would be a change in behaviour/different diff
> 
> Actually that doesn't make a difference.  Specifying kd_waitok will
> only make it wait for physical pages.  But we're passing kp_none so no
> physical pages are allocated.
> 
> Yes, this is confusing and continues to trip people up.

ah right

tested by starting X and chromium on

amd64
amdgpu0: VEGA10 56 CU rev 0x01
inteldrm0: msi, BROADWELL, gen 8

i386
X and crack-attack (chromium won't start due to illegal instruction)
radeondrm0: RV200
inteldrm0: apic 1 int 16, I85X, gen 2

ok jsg@

> 
> > 
> > >   if (va == 0)
> > >   return NULL;
> > >   for (i = 0; i < npages; i++) {
> > > @@ -645,7 +651,7 @@ vunmap(void *addr, size_t size)
> > >  
> > >   pmap_remove(pmap_kernel(), va, va + size);
> > >   pmap_update(pmap_kernel());
> > > - uvm_km_free(kernel_map, va, size);
> > > + km_free((void *)va, size, _any, _none);
> > >  }
> > >  
> > >  bool
> > > 
> > > 
> > 
> 
> 



drop please from manual pages

2022-02-05 Thread Jonathan Gray
drop please from manual pages excluding third party parts of tree
suggested by multiple documentation style guides

diff --git lib/libc/stdlib/atexit.3 lib/libc/stdlib/atexit.3
index a95a45b92e4..891641489e3 100644
--- lib/libc/stdlib/atexit.3
+++ lib/libc/stdlib/atexit.3
@@ -68,7 +68,7 @@ that matters, not the source of the function that was 
registered.
 is very difficult to use correctly without creating
 .Xr exit 3 Ns -time
 races.
-Unless absolutely necessary, please avoid using it.
+Unless absolutely necessary, avoid using it.
 .Sh RETURN VALUES
 The
 .Nm
diff --git lib/libc/sys/getentropy.2 lib/libc/sys/getentropy.2
index 234969e7a1d..942a591a0cc 100644
--- lib/libc/sys/getentropy.2
+++ lib/libc/sys/getentropy.2
@@ -33,7 +33,7 @@ as input for process-context pseudorandom generators like
 The maximum buffer size permitted is 256 bytes.
 .Pp
 .Fn getentropy
-is not intended for regular code; please use the
+is not intended for regular code; use the
 .Xr arc4random 3
 family of functions instead.
 .Pp
diff --git lib/libkeynote/keynote.4 lib/libkeynote/keynote.4
index aabd2db365d..6e5a29dffb4 100644
--- lib/libkeynote/keynote.4
+++ lib/libkeynote/keynote.4
@@ -374,7 +374,7 @@ attribute
 .Sh QUERY SEMANTICS
 The discussion in the following sections assume some familiarity with
 assertion syntax.
-Please refer to
+Refer to
 .Xr keynote 5
 for more details on the syntax.
 .Sh QUERY PARAMETERS
diff --git lib/libpthread/man/pthreads.3 lib/libpthread/man/pthreads.3
index 94e86227874..c2de5274f3a 100644
--- lib/libpthread/man/pthreads.3
+++ lib/libpthread/man/pthreads.3
@@ -463,7 +463,7 @@ conform to
 .St -p1003.1-96
 and various later versions of
 .Pq Dq Tn POSIX .
-Please consult the manpages for the individual functions for details.
+Consult the manpages for the individual functions for details.
 .Sh HISTORY
 This 1-to-1 implementation of the
 .Nm
diff --git lib/libssl/man/SSL_get_ex_data_X509_STORE_CTX_idx.3 
lib/libssl/man/SSL_get_ex_data_X509_STORE_CTX_idx.3
index e30e4de84fa..adea288e4df 100644
--- lib/libssl/man/SSL_get_ex_data_X509_STORE_CTX_idx.3
+++ lib/libssl/man/SSL_get_ex_data_X509_STORE_CTX_idx.3
@@ -104,7 +104,7 @@ provides access to
 object for the connection during the
 .Fn verify_callback
 when checking the peer's certificate.
-Please check the example in
+Check the example in
 .Xr SSL_CTX_set_verify 3 .
 .Sh SEE ALSO
 .Xr CRYPTO_set_ex_data 3 ,
diff --git sbin/iked/iked.conf.5 sbin/iked/iked.conf.5
index 78dfbbfa1d1..7343c4a01ea 100644
--- sbin/iked/iked.conf.5
+++ sbin/iked/iked.conf.5
@@ -197,8 +197,7 @@ Enable OCSP and set the fallback URL of the OCSP responder.
 This fallback will be used if the trusted CA from
 .Pa /etc/iked/ca/
 does not have an OCSP-URL extension.
-Please note that the matching responder certificates
-have to be placed in
+The matching responder certificates have to be placed in
 .Pa /etc/iked/ocsp/responder.crt .
 .Pp
 The optional
@@ -231,7 +230,7 @@ and the
 and
 .Ar password
 arguments.
-Note that the password has to be specified in plain text which is
+The password has to be specified in plain text which is
 required to support different challenge-based EAP methods like
 EAP-MD5 or EAP-MSCHAPv2.
 .El
@@ -255,7 +254,7 @@ the connection, the default action is to ignore the 
connection attempt or
 to use the
 .Ar default
 policy, if set.
-Please also see the
+See the
 .Sx EXAMPLES
 section for a detailed example of the policy evaluation.
 .Pp
@@ -360,7 +359,7 @@ which can be either
 .Ar inet
 or
 .Ar inet6 .
-Note that this only matters for IKEv2 endpoints and does not
+This only matters for IKEv2 endpoints and does not
 restrict the traffic selectors to negotiate flows with different
 address families, e.g. IPv6 flows negotiated by IPv4 endpoints.
 .Pp
@@ -626,7 +625,7 @@ and
 .Ql G
 for kilo-, mega- and gigabytes accordingly.
 .Pp
-Please note that rekeying must happen at least several times a day as
+Rekeying must happen at least several times a day as
 IPsec security heavily depends on frequent key renewals.
 .Pp
 .It Op Ar ikeauth
@@ -1028,7 +1027,7 @@ The currently supported group types are either
 MODP (exponentiation groups modulo a prime),
 ECP (elliptic curve groups modulo a prime),
 or Curve25519.
-Please note that MODP groups of less than 2048 bits are considered
+MODP groups of less than 2048 bits are considered
 as weak or insecure (see RFC 8247 section 2.4) and only provided for
 backwards compatibility.
 .Sh FILES
diff --git sbin/isakmpd/isakmpd.conf.5 sbin/isakmpd/isakmpd.conf.5
index 4d35e162393..1ea562f3447 100644
--- sbin/isakmpd/isakmpd.conf.5
+++ sbin/isakmpd/isakmpd.conf.5
@@ -1372,7 +1372,7 @@ LIFE_DURATION=1000,768:1536
 .Xr isakmpd 8
 .Sh CAVEATS
 Using aggressive mode is discouraged due to various design problems.
-If your peer only supports aggressive mode, please consider replacing that
+If your peer only supports aggressive mode, consider replacing that
 peer with a sane ISAKMP/IKE implementation.
 For details see
 .Lk 

Re: Use km_alloc(9) in drm

2022-02-05 Thread Jonathan Gray
On Sat, Feb 05, 2022 at 11:44:03AM +0100, Mark Kettenis wrote:
> We want to get rid of the uvm_km_valloc() interfaces in favour of
> km_alloc().  This changes the calls in drm(4) over.  The kv_physwait
> struct is made static to prevent collission with a symbol in
> vm_machdep.c on some architectures.  The goal is to move this into
> uvm/uvm_km.c eventually.
> 
> Just to make sure I didn't screw the conversion up somehow a few tests
> on a mix of inteldrm(4) and amdgpu(4) systems would be good.
> 
> ok?
> 
> 
> Index: dev/pci/drm/drm_linux.c
> ===
> RCS file: /cvs/src/sys/dev/pci/drm/drm_linux.c,v
> retrieving revision 1.89
> diff -u -p -r1.89 drm_linux.c
> --- dev/pci/drm/drm_linux.c   21 Jan 2022 23:49:36 -  1.89
> +++ dev/pci/drm/drm_linux.c   5 Feb 2022 10:40:22 -
> @@ -564,6 +564,11 @@ __pagevec_release(struct pagevec *pvec)
>   pagevec_reinit(pvec);
>  }
>  
> +static struct kmem_va_mode kv_physwait = {
> + .kv_map = _map,
> + .kv_wait = 1,
> +};
> +
>  void *
>  kmap(struct vm_page *pg)
>  {
> @@ -572,7 +577,7 @@ kmap(struct vm_page *pg)
>  #if defined (__HAVE_PMAP_DIRECT)
>   va = pmap_map_direct(pg);
>  #else
> - va = uvm_km_valloc_wait(phys_map, PAGE_SIZE);
> + va = (vaddr_t)km_alloc(PAGE_SIZE, _physwait, _none, _waitok);
>   pmap_kenter_pa(va, VM_PAGE_TO_PHYS(pg), PROT_READ | PROT_WRITE);
>   pmap_update(pmap_kernel());
>  #endif
> @@ -589,7 +594,7 @@ kunmap_va(void *addr)
>  #else
>   pmap_kremove(va, PAGE_SIZE);
>   pmap_update(pmap_kernel());
> - uvm_km_free_wakeup(phys_map, va, PAGE_SIZE);
> + km_free((void *)va, PAGE_SIZE, _physwait, _none);
>  #endif
>  }
>  
> @@ -624,7 +629,8 @@ vmap(struct vm_page **pages, unsigned in
>   paddr_t pa;
>   int i;
>  
> - va = uvm_km_valloc(kernel_map, PAGE_SIZE * npages);
> + va = (vaddr_t)km_alloc(PAGE_SIZE * npages, _any, _none,
> + _nowait);

this could be kd_waitok as the linux vmap() uses might_sleep()
but I suppose that would be a change in behaviour/different diff

>   if (va == 0)
>   return NULL;
>   for (i = 0; i < npages; i++) {
> @@ -645,7 +651,7 @@ vunmap(void *addr, size_t size)
>  
>   pmap_remove(pmap_kernel(), va, va + size);
>   pmap_update(pmap_kernel());
> - uvm_km_free(kernel_map, va, size);
> + km_free((void *)va, size, _any, _none);
>  }
>  
>  bool
> 
> 



Re: Fix a bug in sfcc_cache_wbinv_range()

2022-01-15 Thread Jonathan Gray
On Sat, Jan 15, 2022 at 12:21:59PM +, Visa Hankala wrote:
> If the ending address in sfcc_cache_wbinv_range(), pa + len, is not
> cache-line-aligned, the function spins because len wraps around.
> The following patch fixes this.
> 
> There still is a subtle detail. If len is zero but pa is non-aligned,
> the function is not a no-op. However, shouldn't upper layers handle
> things so that zero length does not reach this deep?
> 
> OK?

This driver was added to workaround the lack of coherency on
beaglev and is unused on the unmatched (sifive,fu740-c000-ccache).

The polarfire device tree has sifive,fu540-c000-ccache this
driver matches on but does it actually need this driver?



fix some spelling mistakes in sys/*fs

2022-01-10 Thread Jonathan Gray
diff --git sys/isofs/cd9660/cd9660_lookup.c sys/isofs/cd9660/cd9660_lookup.c
index 3b56a930349..19f2773600e 100644
--- sys/isofs/cd9660/cd9660_lookup.c
+++ sys/isofs/cd9660/cd9660_lookup.c
@@ -133,7 +133,7 @@ cd9660_lookup(void *v)
lockparent = flags & LOCKPARENT;

/*
-* Check accessiblity of directory.
+* Check accessibility of directory.
 */
if ((error = VOP_ACCESS(vdp, VEXEC, cred, cnp->cn_proc)) != 0)
return (error);
diff --git sys/isofs/udf/ecma167-udf.h sys/isofs/udf/ecma167-udf.h
index 4210d49dfa3..175b7ff53cc 100644
--- sys/isofs/udf/ecma167-udf.h
+++ sys/isofs/udf/ecma167-udf.h
@@ -89,7 +89,7 @@ enum {
TAGID_EXTATTR_HDR = 262,
TAGID_UNALL_SP_ENTRY =  263,
TAGID_SPACE_BITMAP =264,
-   TAGID_PART_INTEGRETY =  265,
+   TAGID_PART_INTEGRITY =  265,
TAGID_EXTFENTRY =   266,
TAGID_MAX = 266
 };
@@ -106,7 +106,7 @@ enum {
UDF_ACCESSTYPE_PSEUDO_OVERWITE = 0, /* pseudo overwritable, e.g. 
BD-R's LOW */
UDF_ACCESSTYPE_READ_ONLY   = 1, /* really only readable 
*/
UDF_ACCESSTYPE_WRITE_ONCE  = 2, /* write once and you're done   
*/
-   UDF_ACCESSTYPE_REWRITEABLE = 3, /* may need extra work to 
rewrite   */
+   UDF_ACCESSTYPE_REWRITABLE  = 3, /* may need extra work to 
rewrite   */
UDF_ACCESSTYPE_OVERWRITABLE= 4  /* no limits on rewriting; e.g. 
harddisc*/
 };
 
@@ -260,7 +260,7 @@ struct icb_tag {
 
 #define UDF_ICB_TAG_FLAGS_DIRORDERED   (1<< 3)
 #define UDF_ICB_TAG_FLAGS_NONRELOC (1<< 4)
-#define UDF_ICB_TAG_FLAGS_CONTIGUES(1<< 9)
+#define UDF_ICB_TAG_FLAGS_CONTIGUOUS   (1<< 9)
 #define UDF_ICB_TAG_FLAGS_MULTIPLEVERS (1<<12)
 
 #defineUDF_ICB_TAG_FLAGS_SETUID(1<< 6)
@@ -525,7 +525,7 @@ struct space_entry_desc {
 struct part_hdr_desc {
struct short_ad unalloc_space_table;
struct short_ad unalloc_space_bitmap;
-   struct short_ad part_integrety_table;   /* has to be ZERO for 
UDF */
+   struct short_ad part_integrity_table;   /* has to be ZERO for 
UDF */
struct short_ad freed_space_table;
struct short_ad freed_space_bitmap;
uint8_t reserved[88];
diff --git sys/isofs/udf/udf_vfsops.c sys/isofs/udf/udf_vfsops.c
index 2ba23e9686e..491b063be84 100644
--- sys/isofs/udf/udf_vfsops.c
+++ sys/isofs/udf/udf_vfsops.c
@@ -35,7 +35,7 @@
 /*
  * Ok, here's how it goes.  The UDF specs are pretty clear on how each data
  * structure is made up, but not very clear on how they relate to each other.
- * Here is the skinny... This demostrates a filesystem with one file in the
+ * Here is the skinny... This demonstrates a filesystem with one file in the
  * root directory.  Subdirectories are treated just as normal files, but they
  * have File Id Descriptors of their children as their file data.  As for the
  * Anchor Volume Descriptor Pointer, it can exist in two of the following three
diff --git sys/msdosfs/msdosfs_lookup.c sys/msdosfs/msdosfs_lookup.c
index 73c9d41989f..39f2c81fe03 100644
--- sys/msdosfs/msdosfs_lookup.c
+++ sys/msdosfs/msdosfs_lookup.c
@@ -130,7 +130,7 @@ msdosfs_lookup(void *v)
 #endif
 
/*
-* Check accessiblity of directory.
+* Check accessibility of directory.
 */
if ((dp->de_Attributes & ATTR_DIRECTORY) == 0)
return (ENOTDIR);
diff --git sys/nfs/nfs_aiod.c sys/nfs/nfs_aiod.c
index 98c4335f7f6..4cd453262a8 100644
--- sys/nfs/nfs_aiod.c
+++ sys/nfs/nfs_aiod.c
@@ -150,7 +150,7 @@ out1:
free(aiod, M_TEMP, sizeof(*aiod));
nfs_numaiods--;
KASSERT(nfs_numaiods >= 0);
-   /* Rejust the limit of bufs to queue. See comment above. */
+   /* Readjust the limit of bufs to queue. See comment above. */
if (nfs_numaiods > 0)
nfs_aiodbufqmax = max((bcstats.numbufs / 4) / nfs_numaiods, 64);
else
diff --git sys/nfs/nfs_socket.c sys/nfs/nfs_socket.c
index 38e0ee99d66..0a310837760 100644
--- sys/nfs/nfs_socket.c
+++ sys/nfs/nfs_socket.c
@@ -1114,7 +1114,7 @@ nfs_rephead(int siz, struct nfsrv_descript *nd, struct 
nfssvc_sock *slp,
 
 /*
  * nfs timer routine
- * Scan the nfsreq list and retranmit any requests that have timed out.
+ * Scan the nfsreq list and retransmit any requests that have timed out.
  */
 void
 nfs_timer(void *arg)
diff --git sys/nfs/nfs_subs.c sys/nfs/nfs_subs.c
index 2c6a0cc1c3f..ef2917010b6 100644
--- sys/nfs/nfs_subs.c
+++ sys/nfs/nfs_subs.c
@@ -559,7 +559,7 @@ nfsm_rpchead(struct nfsreq *req, struct ucred *cr, int 
auth_type)
/*
 * RPCAUTH_UNIX fits in an hdr mbuf, in the future other
 * authorization methods need to figure out their own sizes
-* and allocate and chain mbuf's accorindgly.
+* and allocate and chain mbufs accordingly.
 */

Re: fix some spelling mistakes in sys/dev

2022-01-08 Thread Jonathan Gray
On Sat, Jan 08, 2022 at 09:59:10AM +, Jason McIntyre wrote:
> On Sat, Jan 08, 2022 at 02:38:05PM +1100, Jonathan Gray wrote:
> > dwc2, drm and microcode purposefully excluded
> > 
> 
> morning.
> 
> no need for breakfast after reading this one!
> 
> the spelling checks out. i have a few tweaks though:
> 
> acpireg.h:
> rsdp_signaturee is a change to the actual #define. not sure if that
> changes anything.

there are no other references to that define

> 
> if_wi_ieee.h:
> "weirdity" should probably just be "oddity", but whatever
> 
> wdcvar.h:
> channels-specific data -> channel-specific data
> 
> pcppi.c:
> normally it's be to quick -> normally it's too quick

tb@ suggested this as well

> 
> if_iwmreg.h:
> allows Tx with narrower BW then requested -> ... than requested
> 
> pciide.c:
> timings setups -> timing setups
> 
> cgtwelve.c/tvtwo.c/zx.c:
> advertize -> advertise: although i dislike the "z" spelling myself,
> it is not incorrect. generally -ise -> -ize seems to be preferred in US 
> english.

I think this is an exception?

> 
> zx.c:
> a 8-bit plane -> an 8-bit plane
> 
> if_atu.c:
> "requeres" line has a double full stop,
> as does if_atureg.h "psuedo" line

The .. in this file seems to be for indicating a range of values

thanks, adding the below, pcppi part already included

diff --git sys/dev/ic/if_wi_ieee.h sys/dev/ic/if_wi_ieee.h
index 3ece9a1e4cf..434351fc64a 100644
--- sys/dev/ic/if_wi_ieee.h
+++ sys/dev/ic/if_wi_ieee.h
@@ -440,7 +440,7 @@ struct wi_rx_frame {
u_int8_twi_addr4[6];
u_int16_t   wi_dat_len;
/*
-* another weirdity with the drivers. they append a 802.3 header which
+* another oddity with the drivers. they append a 802.3 header which
 * is somewhat redundant, since all the same data is provided in the
 * 802.11 header.
 */
diff --git sys/dev/ic/wdcvar.h sys/dev/ic/wdcvar.h
index f39b7879712..f146dde8936 100644
--- sys/dev/ic/wdcvar.h
+++ sys/dev/ic/wdcvar.h
@@ -167,7 +167,7 @@ struct wdc_softc { /* Per controller state */
u_int8_t  DMA_cap; /* highest DMA mode supported */
u_int8_t  UDMA_cap; /* highest UDMA mode supported */
int nchannels;  /* Number of channels on this controller */
-   struct channel_softc **channels;  /* channels-specific data (array) */
+   struct channel_softc **channels;  /* channel-specific data (array) */
u_int16_t quirks;   /* per-device oddities */
 #define WDC_QUIRK_NOSHORTDMA   0x0001  /* can't do short DMA transfers */
 #define WDC_QUIRK_NOATA0x0002  /* skip attaching ATA disks */
diff --git sys/dev/pci/if_iwmreg.h sys/dev/pci/if_iwmreg.h
index 5293af8525b..7c4005ab77a 100644
--- sys/dev/pci/if_iwmreg.h
+++ sys/dev/pci/if_iwmreg.h
@@ -4671,7 +4671,7 @@ enum {
 #define IWM_LQ_FLAG_RTS_BW_SIG_DYNAMIC  (2 << IWM_LQ_FLAG_RTS_BW_SIG_POS)
 
 /* Bit 6: (0) No dynamic BW selection (1) Allow dynamic BW selection
- * Dynamic BW selection allows Tx with narrower BW then requested in rates
+ * Dynamic BW selection allows Tx with narrower BW than requested in rates
  */
 #define IWM_LQ_FLAG_DYNAMIC_BW_POS  6
 #define IWM_LQ_FLAG_DYNAMIC_BW_MSK  (1 << IWM_LQ_FLAG_DYNAMIC_BW_POS)
diff --git sys/dev/pci/pciide.c sys/dev/pci/pciide.c
index 905ed3e7ae1..e03218fb815 100644
--- sys/dev/pci/pciide.c
+++ sys/dev/pci/pciide.c
@@ -3190,8 +3190,8 @@ piix_setup_idetim_drvs(struct ata_drive_datas *drvp)
u_int8_t drive = drvp->drive;
 
/*
-* If drive is using UDMA, timings setups are independent
-* So just check DMA and PIO here.
+* If drive is using UDMA, timing setup is independent
+* so just check DMA and PIO here.
 */
if (drvp->drive_flags & DRIVE_DMA) {
/* if mode = DMA mode 0, use compatible timings */
diff --git sys/dev/sbus/zx.c sys/dev/sbus/zx.c
index b97f80fa779..abb1f1afc8d 100644
--- sys/dev/sbus/zx.c
+++ sys/dev/sbus/zx.c
@@ -318,7 +318,7 @@ zx_ioctl(void *dev, u_long cmd, caddr_t data, int flags, 
struct proc *p)
 
/*
 * Note that, although the emulation (text) mode is running in
-* a 8-bit plane, we advertise the frame buffer as the full-blown
+* an 8-bit plane, we advertise the frame buffer as the full-blown
 * 32-bit beast it is.
 */
switch (cmd) {
diff --git sys/dev/usb/if_atu.c sys/dev/usb/if_atu.c
index b77f5b00258..b2f687e92ef 100644
--- sys/dev/usb/if_atu.c
+++ sys/dev/usb/if_atu.c
@@ -1280,7 +1280,7 @@ atu_attach(struct device *parent, struct device *self, 
void *aux)
 * Check in the interface descriptor if we're in DFU mode
 * If we're in DFU mode, we upload the external firmware
 * If we're not, 

remove unused make defines

2022-01-03 Thread Jonathan Gray
DEFMAXLOCAL unused since 2007
'kill local/jobs distinction. Correctly this time...'
https://github.com/openbsd/src/commit/f01cd4cc8e1908cec38b82298fe3fc96c7421321

RANLIBMAG unused since 2012
'more changes, discussed and tested by various people'
https://github.com/openbsd/src/commit/1bae8e1fd6d14563435f62552acb95dc3149819a

Index: config.h
===
RCS file: /cvs/src/usr.bin/make/config.h,v
retrieving revision 1.20
diff -u -p -r1.20 config.h
--- config.h18 Oct 2014 07:50:06 -  1.20
+++ config.h7 Dec 2021 07:10:38 -
@@ -44,15 +44,10 @@
 
 /*
  * DEFMAXJOBS
- * DEFMAXLOCAL
- * These control the default concurrency. On no occasion will more
- * than DEFMAXJOBS targets be created at once (locally or remotely)
- * DEFMAXLOCAL is the highest number of targets which will be
- * created on the local machine at once. Note that if you set this
- * to 0, nothing will ever happen...
+ * This controls the default concurrency. On no occasion will more
+ * than DEFMAXJOBS targets be created at once.
  */
 #define DEFMAXJOBS 4
-#define DEFMAXLOCAL1
 
 /*
  * SYSVINCLUDE
@@ -71,12 +66,6 @@
  * # of ${VAR}
  */
 #define SUNSHCMD
-
-#if !defined(__svr4__) && !defined(__SVR4) && !defined(__ELF__)
-# ifndef RANLIBMAG
-#  define RANLIBMAG "__.SYMDEF"
-# endif
-#endif
 
 #ifdef HAS_EXTENDED_GETCWD
 #define dogetcwd() getcwd(NULL, 0)



Re: remove references to prism54.org

2022-01-03 Thread Jonathan Gray
On Mon, Jan 03, 2022 at 11:37:41AM +0100, Stefan Sperling wrote:
> On Mon, Jan 03, 2022 at 12:20:37PM +1100, Jonathan Gray wrote:
> > the prism54.org domain is long abandoned
> > don't give any traffic to whoever registered it afterwards
> > 
> 
> ok stsp@
> 
> A quick web search suggests that no efforts were made to save the
> original content of the site :(

there are snapshots of some of it on archive.org
https://web.archive.org/web/20080907230829/http://prism54.org:80/
https://web.archive.org/web/20150929204839/http://lekernel.net/prism54//
https://web.archive.org/web/20151002085545/http://lekernel.net/prism54//developers.html
https://web.archive.org/web/20080624074509/http://islsm.org/wiki/doku.php?id=

http://jbnote.free.fr/prism54usb/index.html

> 
> > Index: share/man/man4/upgt.4
> > ===
> > RCS file: /cvs/src/share/man/man4/upgt.4,v
> > retrieving revision 1.29
> > diff -u -p -r1.29 upgt.4
> > --- share/man/man4/upgt.4   24 Oct 2021 12:32:42 -  1.29
> > +++ share/man/man4/upgt.4   3 Jan 2022 01:12:18 -
> > @@ -182,9 +182,6 @@ The
> >  .Nm
> >  driver was written by
> >  .An Marcus Glocker Aq Mt mgloc...@openbsd.org .
> > -.Pp
> > -The hardware specification was reverse engineered by the people at
> > -.Lk http://www.prism54.org .
> >  .Sh CAVEATS
> >  The
> >  .Nm
> > Index: sys/dev/ic/pgt.c
> > ===
> > RCS file: /cvs/src/sys/dev/ic/pgt.c,v
> > retrieving revision 1.100
> > diff -u -p -r1.100 pgt.c
> > --- sys/dev/ic/pgt.c3 Mar 2021 23:58:28 -   1.100
> > +++ sys/dev/ic/pgt.c3 Jan 2022 01:12:44 -
> > @@ -96,8 +96,7 @@
> >  
> >  /*
> >   * This is a driver for the Intersil Prism family of 802.11g network cards,
> > - * based upon version 1.2 of the Linux driver and firmware found at
> > - * http://www.prism54.org/.
> > + * based upon version 1.2 of the Linux driver.
> >   */
> >  
> >  #define SCAN_TIMEOUT   5   /* 5 seconds */
> > 
> > 
> 
> 



fix aac(4) build

2022-01-03 Thread Jonathan Gray
or perhaps we just remove aac entirely?

/sys/dev/ic/aac.c:1282:6: error: variable 'error' is used uninitialized 
whenever 'if' condition is true [-Werror,-Wsometimes-uninitialized]
if (sc->total_fibs == 0)
^~~

Index: aac.c
===
RCS file: /cvs/src/sys/dev/ic/aac.c,v
retrieving revision 1.91
diff -u -p -r1.91 aac.c
--- aac.c   15 Oct 2020 00:01:24 -  1.91
+++ aac.c   3 Jan 2022 08:37:24 -
@@ -1279,8 +1279,10 @@ aac_init(struct aac_softc *sc)
if (aac_alloc_commands(sc) != 0)
break;
}
-   if (sc->total_fibs == 0)
-   goto out;
+   if (sc->total_fibs == 0) {
+   error = ENOMEM;
+   goto bail_out;
+   }
 
scsi_iopool_init(>aac_iopool, sc,
aac_alloc_command, aac_release_command);
@@ -1430,7 +1432,6 @@ aac_init(struct aac_softc *sc)
if (state > 0)
bus_dmamem_free(sc->aac_dmat, , 1);
 
- out:
return (error);
 }
 



remove references to prism54.org

2022-01-02 Thread Jonathan Gray
the prism54.org domain is long abandoned
don't give any traffic to whoever registered it afterwards

Index: share/man/man4/upgt.4
===
RCS file: /cvs/src/share/man/man4/upgt.4,v
retrieving revision 1.29
diff -u -p -r1.29 upgt.4
--- share/man/man4/upgt.4   24 Oct 2021 12:32:42 -  1.29
+++ share/man/man4/upgt.4   3 Jan 2022 01:12:18 -
@@ -182,9 +182,6 @@ The
 .Nm
 driver was written by
 .An Marcus Glocker Aq Mt mgloc...@openbsd.org .
-.Pp
-The hardware specification was reverse engineered by the people at
-.Lk http://www.prism54.org .
 .Sh CAVEATS
 The
 .Nm
Index: sys/dev/ic/pgt.c
===
RCS file: /cvs/src/sys/dev/ic/pgt.c,v
retrieving revision 1.100
diff -u -p -r1.100 pgt.c
--- sys/dev/ic/pgt.c3 Mar 2021 23:58:28 -   1.100
+++ sys/dev/ic/pgt.c3 Jan 2022 01:12:44 -
@@ -96,8 +96,7 @@
 
 /*
  * This is a driver for the Intersil Prism family of 802.11g network cards,
- * based upon version 1.2 of the Linux driver and firmware found at
- * http://www.prism54.org/.
+ * based upon version 1.2 of the Linux driver.
  */
 
 #define SCAN_TIMEOUT   5   /* 5 seconds */



fix some spelling mistakes in sys/net*

2022-01-02 Thread Jonathan Gray
diff --git sys/net/fq_codel.c sys/net/fq_codel.c
index e5d103cdf57..e614f4c56a7 100644
--- sys/net/fq_codel.c
+++ sys/net/fq_codel.c
@@ -188,7 +188,7 @@ static const int64_t codel_target = 500;
 /* Grace period after last drop, 16 100ms intervals */
 static const int64_t codel_grace = 16;
 
-/* First 399 "100 / sqrt(x)" intervarls, ns precision */
+/* First 399 "100 / sqrt(x)" intervals, ns precision */
 static const uint32_t codel_intervals[] = {
1, 70710678, 57735027, 5000, 44721360, 40824829, 37796447,
35355339,  , 31622777, 30151134, 28867513, 27735010, 26726124,
diff --git sys/net/if.c sys/net/if.c
index 91bacd06a77..f004c5ed78b 100644
--- sys/net/if.c
+++ sys/net/if.c
@@ -258,7 +258,7 @@ ifinit(void)
 
/*
 * most machines boot with 4 or 5 interfaces, so size the initial map
-* to accomodate this
+* to accommodate this
 */
if_idxmap_init(8);
 
@@ -744,7 +744,7 @@ if_input_local(struct ifnet *ifp, struct mbuf *m, 
sa_family_t af)
 
 #if NBPFILTER > 0
/*
-* Only send packets to bpf if they are destinated to local
+* Only send packets to bpf if they are destined to local
 * addresses.
 *
 * if_input_local() is also called for SIMPLEX interfaces to
diff --git sys/net/if_ppp.h sys/net/if_ppp.h
index eb13a36f2c0..4e9ea0942e1 100644
--- sys/net/if_ppp.h
+++ sys/net/if_ppp.h
@@ -93,7 +93,7 @@
  */
 
 struct npioctl {
-intprotocol;   /* PPP procotol, e.g. PPP_IP */
+intprotocol;   /* PPP protocol, e.g. PPP_IP */
 enum NPmodemode;
 };
 
diff --git sys/net/if_spppsubr.c sys/net/if_spppsubr.c
index 3982c29bbdc..8a4da24a14b 100644
--- sys/net/if_spppsubr.c
+++ sys/net/if_spppsubr.c
@@ -4015,7 +4015,7 @@ sppp_pap_scr(struct sppp *sp)
 /*
  * Send a PAP or CHAP proto packet.
  *
- * Varadic function, each of the elements for the ellipsis is of type
+ * Variadic function, each of the elements for the ellipsis is of type
  * ``size_t mlen, const u_char *msg''.  Processing will stop iff
  * mlen == 0.
  */
diff --git sys/net/if_types.h sys/net/if_types.h
index 64400f95c54..f3da11c6b5f 100644
--- sys/net/if_types.h
+++ sys/net/if_types.h
@@ -205,7 +205,7 @@
 #defineIFT_USB0xa0 /* USB Interface */
 #defineIFT_IEEE8023ADLAG  0xa1 /* IEEE 802.3ad Link Aggregate*/
 #defineIFT_BGPPOLICYACCOUNTING0xa2 /* BGP Policy Accounting */
-#defineIFT_FRF16MFRBUNDLE 0xa3 /* FRF.16 Multilik Frame Relay*/
+#defineIFT_FRF16MFRBUNDLE 0xa3 /* FRF.16 Multilink Frame 
Relay*/
 #defineIFT_H323GATEKEEPER 0xa4 /* H323 Gatekeeper */
 #defineIFT_H323PROXY  0xa5 /* H323 Voice and Video Proxy */
 #defineIFT_MPLS   0xa6 /* MPLS */
diff --git sys/net/if_wg.c sys/net/if_wg.c
index 996ab20d9e4..816ce8fc5ed 100644
--- sys/net/if_wg.c
+++ sys/net/if_wg.c
@@ -1621,7 +1621,7 @@ wg_decap(struct wg_softc *sc, struct mbuf *m)
 * IP header, we just worry about the sizeof and the version, so we can
 * read the source address in wg_aip_lookup.
 *
-* We also need to trim the packet, as it was likely paddded before
+* We also need to trim the packet, as it was likely padded before
 * encryption. While we could drop it here, it will be more helpful to
 * pass it to bpf_mtap and use the counters that people are expecting
 * in ipv4_input and ipv6_input. We can rely on ipv4_input and
diff --git sys/net/pf.c sys/net/pf.c
index 4d497212304..f84e2055fc6 100644
--- sys/net/pf.c
+++ sys/net/pf.c
@@ -1341,7 +1341,7 @@ pf_state_expires(const struct pf_state *state, uint8_t 
stimeout)
 * state->timeout by having the caller do the read (and any
 * chacks it needs to do on the same variable) and then pass
 * their view of the timeout in here for this function to use.
-* the only consequnce of using a stale timeout value is
+* the only consequence of using a stale timeout value is
 * that the state won't be a candidate for purging until the
 * next pass of the purge task.
 */
diff --git sys/net/pfvar_priv.h sys/net/pfvar_priv.h
index 5bba87b19a8..ffdd7ee959f 100644
--- sys/net/pfvar_priv.h
+++ sys/net/pfvar_priv.h
@@ -176,7 +176,7 @@ struct pf_pdesc {
u_int32_toff;   /* protocol header offset */
u_int32_thdrlen;/* protocol header length */
u_int32_tp_len; /* length of protocol payload */
-   u_int32_textoff;/* extentsion header offset */
+   u_int32_textoff;/* extension header offset */
u_int32_tfragoff;   /* fragment header offset */
u_int32_tjumbolen;  /* length from v6 jumbo header */
u_int32_tbadopts;   /* v4 options or v6 routing 

Re: syzkaller vnd ioctl unlock

2021-12-22 Thread Jonathan Gray
On Wed, Dec 22, 2021 at 11:56:38PM +0100, Alexander Bluhm wrote:
> Hi,
> 
> syzkaller found a missing unlock in vnd ioctl error path.
> 
> https://syzkaller.appspot.com/bug?id=b35a411a91f835fffb793df63aa8bcd7be99ad87
> 
> ok?

ok jsg@

> 
> bluhm
> 
> Index: dev/vnd.c
> ===
> RCS file: /data/mirror/openbsd/cvs/src/sys/dev/vnd.c,v
> retrieving revision 1.176
> diff -u -p -r1.176 vnd.c
> --- dev/vnd.c 21 Dec 2021 06:12:03 -  1.176
> +++ dev/vnd.c 22 Dec 2021 22:46:29 -
> @@ -498,6 +498,7 @@ fail:
>   if ((error = disk_lock(>sc_dk)) != 0)
>   goto fail;
>   if (sc->sc_flags & VNF_INITED) {
> + disk_unlock(>sc_dk);
>   error = EBUSY;
>   goto fail;
>   }
> 
> 



Re: dev/videomode/vesagtf.c: -Werror,-Wunused-but-set-variable fix

2021-12-19 Thread Jonathan Gray
On Sun, Dec 19, 2021 at 08:56:41PM +0900, SASANO Takayoshi wrote:
> Hi,
> 
> recently, using -Werror,-Wunused-but-set-variable option makes compile error.
> at least vesagtf.c needs fix but some (many?) other codes need do so.

clang kernels are built with -Wno-unused-but-set-variable
try running 'make config' again



Re: syzkaller nd6_dad_duplicated

2021-12-12 Thread Jonathan Gray
On Sun, Dec 12, 2021 at 11:57:54PM +0100, Alexander Bluhm wrote:
> Hi,
> 
> Syskaller has found a NULL deref in nd6_dad_duplicated().
> 
> https://syzkaller.appspot.com/bug?id=f2ee1cc75911fa580176b09e7c1ab9d867590994
> 
> The code in nd6_dad_ns_input() looks fishy.  It checks dp in two
> of three places.  One check got lost in revision 1.83.  Do a dp ==
> NULL once at the beginning.
> 
> ok?

ok jsg@

> 
> bluhm
> 
> Index: netinet6/nd6_nbr.c
> ===
> RCS file: /data/mirror/openbsd/cvs/src/sys/netinet6/nd6_nbr.c,v
> retrieving revision 1.129
> diff -u -p -U6 -r1.129 nd6_nbr.c
> --- netinet6/nd6_nbr.c29 Nov 2019 16:41:02 -  1.129
> +++ netinet6/nd6_nbr.c12 Dec 2021 22:50:54 -
> @@ -1324,32 +1324,35 @@ nd6_dad_ns_input(struct ifaddr *ifa)
>  
>   if (!ifa)
>   panic("%s: ifa == NULL", __func__);
>  
>   duplicate = 0;
>   dp = nd6_dad_find(ifa);
> + if (dp == NULL) {
> + log(LOG_ERR, "%s: DAD structure not found\n", __func__);
> + return;
> + }
>  
>   /*
>* if I'm yet to start DAD, someone else started using this address
>* first.  I have a duplicate and you win.
>*/
> - if (!dp || dp->dad_ns_ocount == 0)
> + if (dp->dad_ns_ocount == 0)
>   duplicate++;
>  
>   /* XXX more checks for loopback situation - see nd6_dad_timer too */
>  
>   if (duplicate) {
>   /* dp will be freed in nd6_dad_duplicated() */
>   nd6_dad_duplicated(dp);
>   } else {
>   /*
>* not sure if I got a duplicate.
>* increment ns count and see what happens.
>*/
> - if (dp)
> - dp->dad_ns_icount++;
> + dp->dad_ns_icount++;
>   }
>  }
>  
>  /*
>   * Check whether ``addr'' is a neighbor address connected to ``ifp''.
>   */
> 
> 



Re: Handle multi-port CP2108 devices in uslcom(4)

2021-12-12 Thread Jonathan Gray
On Sun, Dec 12, 2021 at 03:18:21PM +, Visa Hankala wrote:
> Silicon Labs CP2108 USB device can implement up to four COM ports. Each
> port appears as a separate USB virtual COM interface under the device.
> 
> Currently, uslcom(4) always uses the device's first interface, which is
> wrong when there are multiple ports. The following patch adjusts the
> driver to use the USB interface that the USB attachment code provides.
> This makes the different ports usable.
> 
> dmesg before:
> 
> uslcom0 at uhub0 port 3 configuration 1 interface 0 "Silicon Labs CP2108 Quad 
> USB to UART Bridge Controller" rev 2.00/1.70 addr 2
> ucom0 at uslcom0 portno 0
> uslcom1 at uhub0 port 3 configuration 1 interface 1 "Silicon Labs CP2108 Quad 
> USB to UART Bridge Controller" rev 2.00/1.70 addr 2
> ucom1 at uslcom1 portno 0
> uslcom2 at uhub0 port 3 configuration 1 interface 2 "Silicon Labs CP2108 Quad 
> USB to UART Bridge Controller" rev 2.00/1.70 addr 2
> ucom2 at uslcom2 portno 0
> uslcom3 at uhub0 port 3 configuration 1 interface 3 "Silicon Labs CP2108 Quad 
> USB to UART Bridge Controller" rev 2.00/1.70 addr 2
> ucom3 at uslcom3 portno 0
> 
> dmesg after:
> 
> uslcom0 at uhub0 port 3 configuration 1 interface 0 "Silicon Labs CP2108 Quad 
> USB to UART Bridge Controller" rev 2.00/1.70 addr 2
> ucom0 at uslcom0 portno 0
> uslcom1 at uhub0 port 3 configuration 1 interface 1 "Silicon Labs CP2108 Quad 
> USB to UART Bridge Controller" rev 2.00/1.70 addr 2
> ucom1 at uslcom1 portno 1
> uslcom2 at uhub0 port 3 configuration 1 interface 2 "Silicon Labs CP2108 Quad 
> USB to UART Bridge Controller" rev 2.00/1.70 addr 2
> ucom2 at uslcom2 portno 2
> uslcom3 at uhub0 port 3 configuration 1 interface 3 "Silicon Labs CP2108 Quad 
> USB to UART Bridge Controller" rev 2.00/1.70 addr 2
> ucom3 at uslcom3 portno 3
> 
> OK?

tested without any problems on
uslcom0 at uhub2 port 2 configuration 1 interface 0 "Silicon Labs CP2102 USB to 
UART Bridge Controller" rev 1.10/1.00 addr 3
ucom0 at uslcom0 portno 0

ok jsg@

> 
> Index: share/man/man4/uslcom.4
> ===
> RCS file: src/share/man/man4/uslcom.4,v
> retrieving revision 1.15
> diff -u -p -r1.15 uslcom.4
> --- share/man/man4/uslcom.4   26 Apr 2019 06:02:10 -  1.15
> +++ share/man/man4/uslcom.4   12 Dec 2021 14:51:03 -
> @@ -26,12 +26,12 @@
>  .Sh DESCRIPTION
>  The
>  .Nm
> -driver supports Silicon Laboratories CP2101/CP2102/CP2103/CP2104/CP2105
> +driver supports Silicon Laboratories 
> CP2101/CP2102/CP2103/CP2104/CP2105/CP2108
>  based serial adapters.
>  .Pp
>  The CP2101/CP2102/CP2103 devices only support a variety of baud rates
>  up to 921600.
> -CP2104 and CP2105 devices support any baud rate up to 2 Mbps.
> +CP2104, CP2105 and CP2108 devices support any baud rate up to 2 Mbps.
>  .Pp
>  The following devices should work with the
>  .Nm
> Index: sys/dev/usb/uslcom.c
> ===
> RCS file: src/sys/dev/usb/uslcom.c,v
> retrieving revision 1.42
> diff -u -p -r1.42 uslcom.c
> --- sys/dev/usb/uslcom.c  5 Jan 2020 00:54:13 -   1.42
> +++ sys/dev/usb/uslcom.c  12 Dec 2021 14:51:03 -
> @@ -38,7 +38,6 @@ int uslcomdebug = 0;
>  #define DPRINTF(x) DPRINTFN(0, x)
>  
>  #define USLCOMBUFSZ  256
> -#define USLCOM_IFACE_NO  0
>  
>  #define USLCOM_SET_DATA_BITS(x)  (x << 8)
>  
> @@ -292,21 +291,11 @@ uslcom_attach(struct device *parent, str
>   struct ucom_attach_args uca;
>   usb_interface_descriptor_t *id;
>   usb_endpoint_descriptor_t *ed;
> - usbd_status error;
>   int i;
>  
>   bzero(, sizeof(uca));
>   sc->sc_udev = uaa->device;
> -
> - /* get the first interface handle */
> - error = usbd_device2interface_handle(sc->sc_udev, USLCOM_IFACE_NO,
> - >sc_iface);
> - if (error != 0) {
> - printf("%s: could not get interface handle\n",
> - sc->sc_dev.dv_xname);
> - usbd_deactivate(sc->sc_udev);
> - return;
> - }
> + sc->sc_iface = uaa->iface;
>  
>   id = usbd_get_interface_descriptor(sc->sc_iface);
>  
> @@ -334,6 +323,7 @@ uslcom_attach(struct device *parent, str
>   return;
>   }
>  
> + uca.portno = id->bInterfaceNumber;
>   uca.ibufsize = USLCOMBUFSZ;
>   uca.obufsize = USLCOMBUFSZ;
>   uca.ibufsizepad = USLCOMBUFSZ;
> 
> 



Re: uvn_reference(): correct printf() argument order

2021-12-06 Thread Jonathan Gray
On Mon, Dec 06, 2021 at 08:46:57PM -0600, Scott Cheloha wrote:
> The arguments to printf() here are backwards.
> 
> ok?

ok jsg@

> 
> Index: uvm_vnode.c
> ===
> RCS file: /cvs/src/sys/uvm/uvm_vnode.c,v
> retrieving revision 1.119
> diff -u -p -r1.119 uvm_vnode.c
> --- uvm_vnode.c   23 Oct 2021 14:42:08 -  1.119
> +++ uvm_vnode.c   7 Dec 2021 02:45:09 -
> @@ -275,8 +275,8 @@ uvn_reference(struct uvm_object *uobj)
>  
>  #ifdef DEBUG
>   if ((uvn->u_flags & UVM_VNODE_VALID) == 0) {
> - printf("uvn_reference: ref=%d, flags=0x%x\n", uvn->u_flags,
> - uobj->uo_refs);
> + printf("uvn_reference: ref=%d, flags=0x%x\n",
> + uobj->uo_refs, uvn->u_flags);
>   panic("uvn_reference: invalid state");
>   }
>  #endif
> 
> 



Re: em(4) vlan tagging support for 82576

2021-12-06 Thread Jonathan Gray
On Mon, Dec 06, 2021 at 10:07:47AM +, Stuart Henderson wrote:
> On 2021/12/05 19:22, Yury Shefer wrote:
> > Hi all,
> > 
> > I have quad-port Intel ET2 NIC based on 82576[1] controller. The manual
> > says that hardware VLAN tagging should be supported but ifconfig output
> > shows VLAN_MTU only in hwfeatures on OpenBSD 7.0. How do I check if 802.1Q
> > tagging is offloaded or not? And if it's not - does it matter at 1Gbps
> > speeds on 3 Ghz CPU?
> > 
> > $ dmesg | grep em0
> > em0 at pci11 dev 0 function 0 "Intel 82576" rev 0x01: msi, address
> > 90:e2:ba:84:64:14
> > 
> > $ ifconfig em0 hwfeatures
> > em0: flags=808843 mtu 1500
> 
> Not supported by the driver with 82576 - you would see VLAN_HWTAGGING here:
> 
> > hwfeatures=10 hardmtu 9216
>   ^
> 
> >From if_em.c:
> 
> 1949 #if NVLAN > 0
> 1950 if (sc->hw.mac_type != em_82575 && sc->hw.mac_type != em_82580 
> &&  1951 sc->hw.mac_type != em_82576 &&
> 1952 sc->hw.mac_type != em_i210 && sc->hw.mac_type != em_i350)
>   1953 ifp->if_capabilities |= 
> IFCAP_VLAN_HWTAGGING;
> 1954 #endif
> 
> >From commit log:
> 
>   
>   revision 1.242
> date: 2010/08/03 16:21:52;  author: jsg;  state: Exp;  lines: +3 -2;  
>   Disable hardware VLAN stripping/insertion on 8257[56] for 
> now.  While
> stripping works insertion seems to have trouble in certain conditions,
>   which needs to be fixed before we want to enable hardware 
> support for this.
>   
>   ok deraadt@
> 

I do not recall specifics but 82575/82576 introduce new style
descriptors closer to ix.  We use the old descriptor format.
I would not be surprised if some of the offload features require using
the newer descriptor format to work.

Sometimes problems with offloading don't show until using things like
ospf and nfs or forcing fragmentation with large mtu values.

> 
> You are best placed to tell whether it matters for your system. Is it fast
> enough already? Bandwidth doesn't matter all that much, packets-per-second is
> more important.
> 
> 



Re: Xserver 21.1 mode selection fixes

2021-12-05 Thread Jonathan Gray
On Sun, Dec 05, 2021 at 10:28:53PM +0100, Matthieu Herrb wrote:
> Hi,
> 
> steven@ reported that, using xf68-video-nv X server 21.1 is dumping
> core on startup.
> 
> The following patch fixes it. While here I also fixed another bug on
> drivers that don't intialize a private structure. 
> 
> If you're using one older graphics card (ie not  inteldrm or radeondrm
> based), please test.
> 
> These are also:
> https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/807
> and https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/808
> 
> ok ?
> 
> Index: hw/xfree86/modes/xf86Crtc.h
> ===
> RCS file: /cvs/OpenBSD/xenocara/xserver/hw/xfree86/modes/xf86Crtc.h,v
> retrieving revision 1.15
> diff -u -p -u -r1.15 xf86Crtc.h
> --- hw/xfree86/modes/xf86Crtc.h   11 Nov 2021 09:10:04 -  1.15
> +++ hw/xfree86/modes/xf86Crtc.h   4 Dec 2021 17:50:33 -
> @@ -837,11 +837,11 @@ extern _X_EXPORT int xf86CrtcConfigPriva
>  static _X_INLINE xf86OutputPtr
>  xf86CompatOutput(ScrnInfoPtr pScrn)
>  {
> -xf86CrtcConfigPtr config = XF86_CRTC_CONFIG_PTR(pScrn);
> +xf86CrtcConfigPtr config;
>  
>  if (xf86CrtcConfigPrivateIndex == -1)
> -return NULL;
> -
> +return NULL;

this introduces whitespace at eol

with that fixed ok jsg@ for both changes

> +config = XF86_CRTC_CONFIG_PTR(pScrn);
>  if (config->compat_output < 0)
>  return NULL;
>  return config->output[config->compat_output];
> Index: hw/xfree86/modes/xf86Modes.c
> ===
> RCS file: /cvs/OpenBSD/xenocara/xserver/hw/xfree86/modes/xf86Modes.c,v
> retrieving revision 1.12
> diff -u -p -u -r1.12 xf86Modes.c
> --- hw/xfree86/modes/xf86Modes.c  11 Nov 2021 09:03:08 -  1.12
> +++ hw/xfree86/modes/xf86Modes.c  5 Dec 2021 18:20:52 -
> @@ -803,10 +803,14 @@ xf86CVTMode(int HDisplay, int VDisplay, 
>  {
>  struct libxcvt_mode_info *libxcvt_mode_info;
>  DisplayModeRec *Mode = xnfcalloc(1, sizeof(DisplayModeRec));
> +char *tmp;
>  
>  libxcvt_mode_info =
>  libxcvt_gen_mode_info(HDisplay, VDisplay, VRefresh, Reduced, 
> Interlaced);
>  
> +XNFasprintf(, "%dx%d", HDisplay, VDisplay);
> +Mode->name = tmp;
> +
>  Mode->VDisplay   = libxcvt_mode_info->vdisplay;
>  Mode->HDisplay   = libxcvt_mode_info->hdisplay;
>  Mode->Clock  = libxcvt_mode_info->dot_clock;
> 
> -- 
> Matthieu Herrb
> 
> 



Re: Stop building the kernel with -Wno-uninitialized on clang archs

2021-11-26 Thread Jonathan Gray
On Fri, Nov 26, 2021 at 05:41:20PM +0100, Jan Stary wrote:
> > > Stop building the kernel with -Wno-uninitialized on clang archs.
> > > This hides real problems like the recently fixed uninitialised memory
> > > use in pf and igc.
> > > 
> > > [-Wsometimes-uninitialized] /sys/arch/arm/arm/cpu.c:352:6: warning: 
> > > variable 'ci' is used uninitialized whenever 'if' condition is false
> > > [-Wsometimes-uninitialized] /sys/arch/arm64/arm64/cpu.c:613:6: warning: 
> > > variable 'ci' is used uninitialized whenever 'if' condition is false
> > > [-Wsometimes-uninitialized] /sys/arch/riscv64/riscv64/cpu.c:169:6: 
> > > warning: variable 'ci' is used uninitialized whenever 'if' condition is 
> > > false
> > > [-Wsometimes-uninitialized] 
> > > /tmp/src/sys/arch/powerpc/powerpc/trap.c:467:7: error: variable 'offset' 
> > > is used uninitialized whenever 'if' condition is false
> > > [-Wuninitialized] /sys/arch/arm64/dev/acpiiort.c:174:28: warning: 
> > > variable 'rid' is uninitialized when used here
> > > 
> > > cpu.c warnings occur with MULTIPROCESSOR not defined
> > > powerpc trap.c occurs with DDB not defined
> > > 
> > > patch to address these and remove the flag below
> > > acpiiort part from patrick@
> 
> On each of the following platforms, the kernel builds fine for me
> with this patch and the compilation shows none of the above warnings.
> 
> i386   (ALIX.1E)
> amd64  (Thinkpad T400)
> arm64  (Raspberry Pi 3 and 4)
> armv7  (BeagleBone Black)
> macppc (Mac Mini 7447A)

thanks, committed with the i386 part changed to not remove -Werror

> 
> 
>   Jan
> 
> > > Index: arch/amd64/conf/Makefile.amd64
> > > ===
> > > RCS file: /cvs/src/sys/arch/amd64/conf/Makefile.amd64,v
> > > retrieving revision 1.121
> > > diff -u -p -r1.121 Makefile.amd64
> > > --- arch/amd64/conf/Makefile.amd6412 Jul 2021 06:07:33 -  
> > > 1.121
> > > +++ arch/amd64/conf/Makefile.amd6426 Nov 2021 04:54:10 -
> > > @@ -48,7 +48,7 @@ INCLUDES=   -nostdinc -I$S -I${.OBJDIR} -I
> > >  CPPFLAGS=${INCLUDES} ${IDENT} ${PARAM} -D_KERNEL -MD -MP \
> > >   -DCONFIG_DRM_AMD_DC_DCN3_0
> > >  CWARNFLAGS=  -Werror -Wall -Wimplicit-function-declaration \
> > > - -Wno-uninitialized -Wno-pointer-sign \
> > > + -Wno-pointer-sign \
> > >   -Wframe-larger-than=2047
> > >  
> > >  CMACHFLAGS=  -mcmodel=kernel -mno-red-zone -mno-sse2 -mno-sse 
> > > -mno-3dnow \
> > > Index: arch/arm/arm/cpu.c
> > > ===
> > > RCS file: /cvs/src/sys/arch/arm/arm/cpu.c,v
> > > retrieving revision 1.55
> > > diff -u -p -r1.55 cpu.c
> > > --- arch/arm/arm/cpu.c25 Mar 2021 04:12:00 -  1.55
> > > +++ arch/arm/arm/cpu.c23 Nov 2021 00:19:43 -
> > > @@ -349,14 +349,11 @@ cpu_attach(struct device *parent, struct
> > >   __asm volatile("mrc p15, 0, %0, c0, c0, 5" : "=r"(mpidr));
> > >   KASSERT(faa->fa_nreg > 0);
> > >  
> > > +#ifdef MULTIPROCESSOR
> > >   if (faa->fa_reg[0].addr == (mpidr & MPIDR_AFF)) {
> > >   ci = _info_primary;
> > > -#ifdef MULTIPROCESSOR
> > >   ci->ci_flags |= CPUF_RUNNING | CPUF_PRESENT | CPUF_PRIMARY;
> > > -#endif
> > > - }
> > > -#ifdef MULTIPROCESSOR
> > > - else {
> > > + } else {
> > >   ci = malloc(sizeof(*ci), M_DEVBUF, M_WAITOK | M_ZERO);
> > >   cpu_info[dev->dv_unit] = ci;
> > >   ci->ci_next = cpu_info_list->ci_next;
> > > @@ -364,6 +361,8 @@ cpu_attach(struct device *parent, struct
> > >   ci->ci_flags |= CPUF_AP;
> > >   ncpus++;
> > >   }
> > > +#else
> > > + ci = _info_primary;
> > >  #endif
> > >  
> > >   ci->ci_dev = dev;
> > > Index: arch/arm64/arm64/cpu.c
> > > ===
> > > RCS file: /cvs/src/sys/arch/arm64/arm64/cpu.c,v
> > > retrieving revision 1.58
> > > diff -u -p -r1.58 cpu.c
> > > --- arch/arm64/arm64/cpu.c23 Nov 2021 01:03:35 -  1.58
> > > +++ arch/arm64/arm64/cpu.c23 Nov 2021 01:28:26 -
> > > @@ -604,20 +604,19 @@ cpu_attach(struct device *parent, struct
> > >  {
> > >   struct fdt_attach_args *faa = aux;
> > >   struct cpu_info *ci;
> > > +#ifdef MULTIPROCESSOR
> > >   uint64_t mpidr = READ_SPECIALREG(mpidr_el1);
> > > +#endif
> > >   uint64_t id_aa64mmfr1, sctlr;
> > >   uint32_t opp;
> > >  
> > >   KASSERT(faa->fa_nreg > 0);
> > >  
> > > +#ifdef MULTIPROCESSOR
> > >   if (faa->fa_reg[0].addr == (mpidr & MPIDR_AFF)) {
> > >   ci = _info_primary;
> > > -#ifdef MULTIPROCESSOR
> > >   ci->ci_flags |= CPUF_RUNNING | CPUF_PRESENT | CPUF_PRIMARY;
> > > -#endif
> > > - }
> > > -#ifdef MULTIPROCESSOR
> > > - else {
> > > + } else {
> > >   ci = malloc(sizeof(*ci), M_DEVBUF, M_WAITOK | M_ZERO);
> > >   cpu_info[dev->dv_unit] = ci;
> > >   ci->ci_next = cpu_info_list->ci_next;
> > > @@ -625,6 +624,8 @@ cpu_attach(struct device 

Re: [External] : Stop building the kernel with -Wno-uninitialized on clang archs

2021-11-26 Thread Jonathan Gray
On Fri, Nov 26, 2021 at 12:04:21PM +0100, Alexandr Nedvedicky wrote:
> Hello,
> 
> On Fri, Nov 26, 2021 at 04:32:59PM +1100, Jonathan Gray wrote:
> > Stop building the kernel with -Wno-uninitialized on clang archs.
> > This hides real problems like the recently fixed uninitialised memory
> > use in pf and igc.
> 
> yes, please. I'd like to have the warning enabled.
> I'm just able to build amd64,i386 only, not other archs
> so can't OK those archs.
> 
> amd64 builds with warning enabled.
> 
> i386 seems to rquire  two touches below. those diffs are just my wild
> guess to keep build running. I'm far from saying it's correct
> fix.

Update your tree, I committed changes to these files a few days ago.

> 
> thank you for proposing this change.
> 
> regards
> sashan
> 
> 8<---8<---8<--8<
> diff --git a/sys/dev/ic/tea5757.c b/sys/dev/ic/tea5757.c
> index 3a4bafa3dc6..d416a80e382 100644
> --- a/sys/dev/ic/tea5757.c
> +++ b/sys/dev/ic/tea5757.c
> @@ -159,7 +159,7 @@ tea5757_encode_lock(u_int8_t lock)
>   ret = TEA5757_S010;
>   else if (lock > 14 && lock < 51)
>   ret = TEA5757_S030;
> - else if (lock > 50)
> + else
>   ret = TEA5757_S150;
>  
>   return ret;
> diff --git a/sys/dev/pci/fmsradio.c b/sys/dev/pci/fmsradio.c
> index 5ab13f2ea5b..07310664603 100644
> --- a/sys/dev/pci/fmsradio.c
> +++ b/sys/dev/pci/fmsradio.c
> @@ -537,7 +537,8 @@ fmsradio_get_info(void *v, struct radio_info *ri)
>   ri->info |= buf & PCR_INFO_STEREO ? 0 : RADIO_INFO_STEREO;
>   break;
>   default:
> - break;
> + ri->rfreq = 0;
> + return (-1);
>   }
>  
>   ri->freq = radio->freq = tea5757_decode_freq(buf,
> 
> 



Stop building the kernel with -Wno-uninitialized on clang archs

2021-11-25 Thread Jonathan Gray
Stop building the kernel with -Wno-uninitialized on clang archs.
This hides real problems like the recently fixed uninitialised memory
use in pf and igc.

After visa's recent commit the remaining warnings are

[-Wsometimes-uninitialized] /sys/arch/arm/arm/cpu.c:352:6: warning: variable 
'ci' is used uninitialized whenever 'if' condition is false
[-Wsometimes-uninitialized] /sys/arch/arm64/arm64/cpu.c:613:6: warning: 
variable 'ci' is used uninitialized whenever 'if' condition is false
[-Wsometimes-uninitialized] /sys/arch/riscv64/riscv64/cpu.c:169:6: warning: 
variable 'ci' is used uninitialized whenever 'if' condition is false
[-Wsometimes-uninitialized] /tmp/src/sys/arch/powerpc/powerpc/trap.c:467:7: 
error: variable 'offset' is used uninitialized whenever 'if' condition is false
[-Wuninitialized] /sys/arch/arm64/dev/acpiiort.c:174:28: warning: variable 
'rid' is uninitialized when used here

cpu.c warnings occur with MULTIPROCESSOR not defined
powerpc trap.c occurs with DDB not defined

patch to address these and remove the flag below
acpiiort part from patrick@

Index: arch/amd64/conf/Makefile.amd64
===
RCS file: /cvs/src/sys/arch/amd64/conf/Makefile.amd64,v
retrieving revision 1.121
diff -u -p -r1.121 Makefile.amd64
--- arch/amd64/conf/Makefile.amd64  12 Jul 2021 06:07:33 -  1.121
+++ arch/amd64/conf/Makefile.amd64  26 Nov 2021 04:54:10 -
@@ -48,7 +48,7 @@ INCLUDES= -nostdinc -I$S -I${.OBJDIR} -I
 CPPFLAGS=  ${INCLUDES} ${IDENT} ${PARAM} -D_KERNEL -MD -MP \
-DCONFIG_DRM_AMD_DC_DCN3_0
 CWARNFLAGS=-Werror -Wall -Wimplicit-function-declaration \
-   -Wno-uninitialized -Wno-pointer-sign \
+   -Wno-pointer-sign \
-Wframe-larger-than=2047
 
 CMACHFLAGS=-mcmodel=kernel -mno-red-zone -mno-sse2 -mno-sse -mno-3dnow \
Index: arch/arm/arm/cpu.c
===
RCS file: /cvs/src/sys/arch/arm/arm/cpu.c,v
retrieving revision 1.55
diff -u -p -r1.55 cpu.c
--- arch/arm/arm/cpu.c  25 Mar 2021 04:12:00 -  1.55
+++ arch/arm/arm/cpu.c  23 Nov 2021 00:19:43 -
@@ -349,14 +349,11 @@ cpu_attach(struct device *parent, struct
__asm volatile("mrc p15, 0, %0, c0, c0, 5" : "=r"(mpidr));
KASSERT(faa->fa_nreg > 0);
 
+#ifdef MULTIPROCESSOR
if (faa->fa_reg[0].addr == (mpidr & MPIDR_AFF)) {
ci = _info_primary;
-#ifdef MULTIPROCESSOR
ci->ci_flags |= CPUF_RUNNING | CPUF_PRESENT | CPUF_PRIMARY;
-#endif
-   }
-#ifdef MULTIPROCESSOR
-   else {
+   } else {
ci = malloc(sizeof(*ci), M_DEVBUF, M_WAITOK | M_ZERO);
cpu_info[dev->dv_unit] = ci;
ci->ci_next = cpu_info_list->ci_next;
@@ -364,6 +361,8 @@ cpu_attach(struct device *parent, struct
ci->ci_flags |= CPUF_AP;
ncpus++;
}
+#else
+   ci = _info_primary;
 #endif
 
ci->ci_dev = dev;
Index: arch/arm64/arm64/cpu.c
===
RCS file: /cvs/src/sys/arch/arm64/arm64/cpu.c,v
retrieving revision 1.58
diff -u -p -r1.58 cpu.c
--- arch/arm64/arm64/cpu.c  23 Nov 2021 01:03:35 -  1.58
+++ arch/arm64/arm64/cpu.c  23 Nov 2021 01:28:26 -
@@ -604,20 +604,19 @@ cpu_attach(struct device *parent, struct
 {
struct fdt_attach_args *faa = aux;
struct cpu_info *ci;
+#ifdef MULTIPROCESSOR
uint64_t mpidr = READ_SPECIALREG(mpidr_el1);
+#endif
uint64_t id_aa64mmfr1, sctlr;
uint32_t opp;
 
KASSERT(faa->fa_nreg > 0);
 
+#ifdef MULTIPROCESSOR
if (faa->fa_reg[0].addr == (mpidr & MPIDR_AFF)) {
ci = _info_primary;
-#ifdef MULTIPROCESSOR
ci->ci_flags |= CPUF_RUNNING | CPUF_PRESENT | CPUF_PRIMARY;
-#endif
-   }
-#ifdef MULTIPROCESSOR
-   else {
+   } else {
ci = malloc(sizeof(*ci), M_DEVBUF, M_WAITOK | M_ZERO);
cpu_info[dev->dv_unit] = ci;
ci->ci_next = cpu_info_list->ci_next;
@@ -625,6 +624,8 @@ cpu_attach(struct device *parent, struct
ci->ci_flags |= CPUF_AP;
ncpus++;
}
+#else
+   ci = _info_primary;
 #endif
 
ci->ci_dev = dev;
Index: arch/arm64/conf/Makefile.arm64
===
RCS file: /cvs/src/sys/arch/arm64/conf/Makefile.arm64,v
retrieving revision 1.39
diff -u -p -r1.39 Makefile.arm64
--- arch/arm64/conf/Makefile.arm64  7 Jul 2021 02:38:21 -   1.39
+++ arch/arm64/conf/Makefile.arm64  26 Nov 2021 04:55:52 -
@@ -46,7 +46,7 @@ INCLUDES= -nostdinc -I$S -I${.OBJDIR} -I
-I$S/dev/pci/drm/amd/display/dmub/inc
 CPPFLAGS=  ${INCLUDES} ${IDENT} ${PARAM} -D_KERNEL -D__${_mach}__ -MD -MP
 CWARNFLAGS=-Werror -Wall -Wimplicit-function-declaration \
-   

Re: ifconfig: zap dead code

2021-11-03 Thread Jonathan Gray
On Tue, Nov 02, 2021 at 11:47:33PM +, Klemens Nanni wrote:
> No idea what it was supposed to do back then;  cvs blame points at
> 
>   revision 1.19
>   date: 1998/09/03 06:24:18;  author: jason;  state: Exp;  lines: +502 
> -38;
>   o OpenBSD gets if_media support (from NetBSD)
>   o rework/simplify if_xl to use 
> 
> OK?
> 
> Index: ifconfig.c
> ===
> RCS file: /cvs/src/sbin/ifconfig/ifconfig.c,v
> retrieving revision 1.447
> diff -u -p -r1.447 ifconfig.c
> --- ifconfig.c2 Nov 2021 23:39:27 -   1.447
> +++ ifconfig.c2 Nov 2021 23:46:28 -
> @@ -411,11 +411,6 @@ const struct cmd {
>   { "alias",  IFF_UP, 0,  notealias },
>   { "-alias", -IFF_UP,0,  notealias },
>   { "delete", -IFF_UP,0,  notealias },
> -#ifdef notdef
> -#define  EN_SWABIPS  0x1000
> - { "swabips",EN_SWABIPS, 0,  setifflags },
> - { "-swabips",   -EN_SWABIPS,0,  setifflags },
> -#endif /* notdef */
>   { "netmask",NEXTARG,0,  setifnetmask },
>   { "mtu",NEXTARG,0,  setifmtu },
>   { "nwid",   NEXTARG,0,  setifnwid },
> 
> 

ifdef'd since it was added in 1983

commit ccd6c9e869e1397bbfa7451641696a91fe00a339
Author: Sam Leffler 
Date:   Fri Sep 16 18:39:22 1983 -0700

show stanford how to add swabip crap

SCCS-vsn: 4.3

diff --git sbin/ifconfig/ifconfig.c sbin/ifconfig/ifconfig.c
index 449447f453..8c1922ddc5 100644
--- sbin/ifconfig/ifconfig.c
+++ sbin/ifconfig/ifconfig.c
@@ -1,5 +1,5 @@
 #ifndef lint
-static char sccsid[] = "@(#)ifconfig.c 4.2 (Berkeley) 08/28/83";
+static char sccsid[] = "@(#)ifconfig.c 4.3 (Berkeley) 09/16/83";
 #endif
 
 #include 
@@ -33,6 +33,11 @@ struct   cmd {
{ "-trailers",  IFF_NOTRAILERS, setifflags },
{ "arp",IFF_NOARP,  setifflags },
{ "-arp",   -IFF_NOARP, setifflags },
+#ifdef notdef
+#defineEN_SWABIPS  0x100
+   { "swabips",EN_SWABIPS, setifflags },
+   { "-swabips",   -EN_SWABIPS,setifflags },
+#endif
{ 0,0,  setifaddr },
 };
 



Re: Stop mentioning ld(1) warning messages in mktemp.3 and tmpnam.3

2021-10-24 Thread Jonathan Gray
On Sun, Oct 24, 2021 at 02:27:55PM +0200, Frederic Cambus wrote:
> Hi tech@,
> 
> This diff removes mentions of ld warning messages for mktemp(3),
> tmpnam(3), and tempnam(3).
> 
> LLD doesn't emit warnings when encountering .gnu.warning.* sections, so
> those warnings are not emitted anymore for a majority of users since we
> switched to LLD as the default linker on most architectures.
> 
> Manual pages for other libc functions for which we have .gnu.warning.*
> sections did not mention ld warnings. For the record, those functions
> are: getwd(3), rand(3), rand_r(3), random(3), sprintf(3), stpcpy(3),
> strcat(3), strcpy(3), vsprintf(3), wcscat(3), and wcscpy(3).
> 
> Comments? OK?

Shouldn't lld instead be changed to show warnings?

> 
> Index: lib/libc/stdio/mktemp.3
> ===
> RCS file: /cvs/src/lib/libc/stdio/mktemp.3,v
> retrieving revision 1.54
> diff -u -p -r1.54 mktemp.3
> --- lib/libc/stdio/mktemp.3   26 Oct 2014 12:54:18 -  1.54
> +++ lib/libc/stdio/mktemp.3   24 Oct 2021 10:38:29 -
> @@ -408,8 +408,3 @@ Whenever it is possible,
>  or
>  .Fn mkdtemp
>  should be used instead.
> -.Pp
> -For this reason,
> -.Xr ld 1
> -will output a warning message whenever it links code that uses
> -.Fn mktemp .
> Index: lib/libc/stdio/tmpnam.3
> ===
> RCS file: /cvs/src/lib/libc/stdio/tmpnam.3,v
> retrieving revision 1.23
> diff -u -p -r1.23 tmpnam.3
> --- lib/libc/stdio/tmpnam.3   30 Aug 2019 23:33:45 -  1.23
> +++ lib/libc/stdio/tmpnam.3   24 Oct 2021 10:38:29 -
> @@ -219,10 +219,3 @@ temporary files are created.
>  .Pp
>  This implementation does not have these flaws, but portable software
>  cannot depend on that.
> -.Pp
> -For these reasons,
> -.Xr ld 1
> -will output a warning message whenever it links code that uses the functions
> -.Fn tmpnam
> -or
> -.Fn tempnam .
> 
> 



Re: use NULL instead of 0 for pointers in sys/net

2021-10-23 Thread Jonathan Gray
On Sun, Oct 24, 2021 at 07:23:30AM +0200, Sebastien Marie wrote:
> 
> ok semarie@
> 
> and while reviewing the code, I saw sppp_get_ip_addrs() last argument
> (u_int32_t *srcmask) is always passed as NULL.
> 
> In fact, both sppp_get_ip_addrs() and sppp_get_ip6_addrs() has the
> same argument never used.
> 
> Does it is something to simplify ? The code inside the functions is
> relatively small. Not sure it would be helpfull to remove it.

Yes, that argument could go.

It was used by the cisco hdlc code removed in 2015 with
if_spppsubr.c rev 1.138.

> 
> Thanks
> -- 
> Sebastien Marie
> 
> 
> 
> On Sun, Oct 24, 2021 at 12:14:22PM +1100, Jonathan Gray wrote:
> > diff --git sys/net/bpf.c sys/net/bpf.c
> > index 87a9d726423..87418c3dc17 100644
> > --- sys/net/bpf.c
> > +++ sys/net/bpf.c
> > @@ -1019,7 +1019,7 @@ bpf_setf(struct bpf_d *d, struct bpf_program *fp, int 
> > wf)
> >  
> > KERNEL_ASSERT_LOCKED();
> >  
> > -   if (fp->bf_insns == 0) {
> > +   if (fp->bf_insns == NULL) {
> > if (fp->bf_len != 0)
> > return (EINVAL);
> > bps = NULL;
> > diff --git sys/net/if.c sys/net/if.c
> > index 8fe99eff4df..6bd8899561c 100644
> > --- sys/net/if.c
> > +++ sys/net/if.c
> > @@ -1440,7 +1440,8 @@ ifaof_ifpforaddr(struct sockaddr *addr, struct ifnet 
> > *ifp)
> > continue;
> > if (ifa_maybe == NULL)
> > ifa_maybe = ifa;
> > -   if (ifa->ifa_netmask == 0 || ifp->if_flags & IFF_POINTOPOINT) {
> > +   if (ifa->ifa_netmask == NULL ||
> > +   ifp->if_flags & IFF_POINTOPOINT) {
> > if (equal(addr, ifa->ifa_addr) ||
> > (ifa->ifa_dstaddr && equal(addr, ifa->ifa_dstaddr)))
> > return (ifa);
> > diff --git sys/net/if_mpip.c sys/net/if_mpip.c
> > index a8daeeea314..fe155eb18d8 100644
> > --- sys/net/if_mpip.c
> > +++ sys/net/if_mpip.c
> > @@ -96,7 +96,7 @@ mpip_clone_create(struct if_clone *ifc, int unit)
> >  
> > sc->sc_txhprio = 0;
> > sc->sc_rxhprio = IF_HDRPRIO_PACKET;
> > -   sc->sc_neighbor = 0;
> > +   sc->sc_neighbor = NULL;
> > sc->sc_cword = 0; /* default to no control word */
> > sc->sc_fword = 0; /* both sides have to agree on FAT first */
> > sc->sc_flow = arc4random() & 0xf;
> > diff --git sys/net/if_ppp.c sys/net/if_ppp.c
> > index fb32d9ea9ef..c3b6d9051b7 100644
> > --- sys/net/if_ppp.c
> > +++ sys/net/if_ppp.c
> > @@ -324,21 +324,21 @@ pppdealloc(struct ppp_softc *sc)
> > sc->sc_rc_state = NULL;
> >  #endif /* PPP_COMPRESS */
> >  #if NBPFILTER > 0
> > -   if (sc->sc_pass_filt.bf_insns != 0) {
> > +   if (sc->sc_pass_filt.bf_insns != NULL) {
> > free(sc->sc_pass_filt.bf_insns, M_DEVBUF, 0);
> > -   sc->sc_pass_filt.bf_insns = 0;
> > +   sc->sc_pass_filt.bf_insns = NULL;
> > sc->sc_pass_filt.bf_len = 0;
> > }
> > -   if (sc->sc_active_filt.bf_insns != 0) {
> > +   if (sc->sc_active_filt.bf_insns != NULL) {
> > free(sc->sc_active_filt.bf_insns, M_DEVBUF, 0);
> > -   sc->sc_active_filt.bf_insns = 0;
> > +   sc->sc_active_filt.bf_insns = NULL;
> > sc->sc_active_filt.bf_len = 0;
> > }
> >  #endif
> >  #ifdef VJC
> > -   if (sc->sc_comp != 0) {
> > +   if (sc->sc_comp != NULL) {
> > free(sc->sc_comp, M_DEVBUF, 0);
> > -   sc->sc_comp = 0;
> > +   sc->sc_comp = NULL;
> > }
> >  #endif
> > NET_UNLOCK();
> > @@ -538,7 +538,7 @@ pppioctl(struct ppp_softc *sc, u_long cmd, caddr_t 
> > data, int flag,
> > return EINVAL;
> > }
> > } else
> > -   newcode = 0;
> > +   newcode = NULL;
> > bp = (cmd == PPPIOCSPASS) ?
> > >sc_pass_filt : >sc_active_filt;
> > oldcode = bp->bf_insns;
> > @@ -546,7 +546,7 @@ pppioctl(struct ppp_softc *sc, u_long cmd, caddr_t 
> > data, int flag,
> > bp->bf_len = nbp->bf_len;
> > bp->bf_insns = newcode;
> > splx(s);
> > -   if (oldcode != 0)
> > +   if (oldcode != NULL)
> > free(old

libc ansi

2021-10-23 Thread Jonathan Gray
Index: db/btree/bt_close.c
===
RCS file: /cvs/src/lib/libc/db/btree/bt_close.c,v
retrieving revision 1.10
diff -u -p -r1.10 bt_close.c
--- db/btree/bt_close.c 16 Jan 2015 16:48:51 -  1.10
+++ db/btree/bt_close.c 24 Oct 2021 03:49:16 -
@@ -107,9 +107,7 @@ __bt_close(DB *dbp)
  * RET_SUCCESS, RET_ERROR.
  */
 int
-__bt_sync(dbp, flags)
-   const DB *dbp;
-   u_int flags;
+__bt_sync(const DB *dbp, u_int flags)
 {
BTREE *t;
int status;
@@ -150,8 +148,7 @@ __bt_sync(dbp, flags)
  * RET_ERROR, RET_SUCCESS
  */
 static int
-bt_meta(t)
-   BTREE *t;
+bt_meta(BTREE *t)
 {
BTMETA m;
void *p;
Index: db/btree/bt_utils.c
===
RCS file: /cvs/src/lib/libc/db/btree/bt_utils.c,v
retrieving revision 1.11
diff -u -p -r1.11 bt_utils.c
--- db/btree/bt_utils.c 16 Jan 2015 16:48:51 -  1.11
+++ db/btree/bt_utils.c 24 Oct 2021 03:49:59 -
@@ -226,8 +226,7 @@ __bt_defcmp(const DBT *a, const DBT *b)
  * Number of bytes needed to distinguish b from a.
  */
 size_t
-__bt_defpfx(a, b)
-   const DBT *a, *b;
+__bt_defpfx(const DBT *a, const DBT *b)
 {
u_char *p1, *p2;
size_t cnt, len;
Index: db/hash/ndbm.c
===
RCS file: /cvs/src/lib/libc/db/hash/ndbm.c,v
retrieving revision 1.26
diff -u -p -r1.26 ndbm.c
--- db/hash/ndbm.c  7 May 2016 21:58:06 -   1.26
+++ db/hash/ndbm.c  24 Oct 2021 03:58:27 -
@@ -57,11 +57,7 @@ static DBM *_dbm_open(const char *, cons
  *  NULL on failure
  */
 static DBM *
-_dbm_open(file, suff, flags, mode)
-   const char *file;
-   const char *suff;
-   int flags;
-   mode_t mode;
+_dbm_open(const char *file, const char *suff, int flags, mode_t mode)
 {
HASHINFO info;
char path[PATH_MAX];
@@ -92,10 +88,7 @@ _dbm_open(file, suff, flags, mode)
  *  NULL on failure
  */
 DBM *
-dbm_open(file, flags, mode)
-   const char *file;
-   int flags;
-   mode_t mode;
+dbm_open(const char *file, int flags, mode_t mode)
 {
 
return(_dbm_open(file, DBM_SUFFIX, flags, mode));
@@ -106,8 +99,7 @@ dbm_open(file, flags, mode)
  * Nothing.
  */
 void
-dbm_close(db)
-   DBM *db;
+dbm_close(DBM *db)
 {
 
(void)(db->close)(db);
@@ -120,9 +112,7 @@ DEF_WEAK(dbm_close);
  * NULL on failure
  */
 datum
-dbm_fetch(db, key)
-   DBM *db;
-   datum key;
+dbm_fetch(DBM *db, datum key)
 {
datum retdata;
int status;
@@ -147,8 +137,7 @@ DEF_WEAK(dbm_fetch);
  * NULL on failure
  */
 datum
-dbm_firstkey(db)
-   DBM *db;
+dbm_firstkey(DBM *db)
 {
int status;
datum retkey;
@@ -169,8 +158,7 @@ DEF_WEAK(dbm_firstkey);
  * NULL on failure
  */
 datum
-dbm_nextkey(db)
-   DBM *db;
+dbm_nextkey(DBM *db)
 {
int status;
datum retkey;
@@ -191,9 +179,7 @@ DEF_WEAK(dbm_nextkey);
  * <0 on failure
  */
 int
-dbm_delete(db, key)
-   DBM *db;
-   datum key;
+dbm_delete(DBM *db, datum key)
 {
int status;
DBT dbtkey;
@@ -215,10 +201,7 @@ DEF_WEAK(dbm_delete);
  *  1 if DBM_INSERT and entry exists
  */
 int
-dbm_store(db, key, data, flags)
-   DBM *db;
-   datum key, data;
-   int flags;
+dbm_store(DBM *db, datum key, datum data, int flags)
 {
DBT dbtkey, dbtdata;
 
@@ -232,8 +215,7 @@ dbm_store(db, key, data, flags)
 DEF_WEAK(dbm_store);
 
 int
-dbm_error(db)
-   DBM *db;
+dbm_error(DBM *db)
 {
HTAB *hp;
 
@@ -242,8 +224,7 @@ dbm_error(db)
 }
 
 int
-dbm_clearerr(db)
-   DBM *db;
+dbm_clearerr(DBM *db)
 {
HTAB *hp;
 
@@ -253,16 +234,14 @@ dbm_clearerr(db)
 }
 
 int
-dbm_dirfno(db)
-   DBM *db;
+dbm_dirfno(DBM *db)
 {
 
return(((HTAB *)db->internal)->fp);
 }
 
 int
-dbm_rdonly(dbp)
-   DBM *dbp;
+dbm_rdonly(DBM *dbp)
 {
HTAB *hashp = (HTAB *)dbp->internal;
 
Index: net/base64.c
===
RCS file: /cvs/src/lib/libc/net/base64.c,v
retrieving revision 1.12
diff -u -p -r1.12 base64.c
--- net/base64.c22 Oct 2021 10:22:15 -  1.12
+++ net/base64.c24 Oct 2021 03:52:40 -
@@ -121,11 +121,8 @@ static const char Pad64 = '=';
*/
 
 int
-b64_ntop(src, srclength, target, targsize)
-   unsigned char const *src;
-   size_t srclength;
-   char *target;
-   size_t targsize;
+b64_ntop(unsigned char const *src, size_t srclength, char *target,
+size_t targsize)
 {
size_t datalength = 0;
unsigned char input[3];
@@ -185,10 +182,7 @@ b64_ntop(src, srclength, target, targsiz
  */
 
 int
-b64_pton(src, target, targsize)
-   char const *src;
-   unsigned char *target;
-   size_t targsize;
+b64_pton(char const *src, unsigned char *target, size_t targsize)
 {
int tarindex, state, ch;
unsigned 

use NULL instead of 0 for pointers in sys/{crypto,nfs,scsi,uvm}

2021-10-23 Thread Jonathan Gray
excluding sys/crypto/xform_ipcomp.c:76:23 as zlib has Z_NULL as 0

diff --git sys/crypto/cryptosoft.c sys/crypto/cryptosoft.c
index dcb815aaa17..be1f3f1ec5c 100644
--- sys/crypto/cryptosoft.c
+++ sys/crypto/cryptosoft.c
@@ -424,7 +424,7 @@ swcr_authcompute(struct cryptop *crp, struct cryptodesc 
*crd,
union authctx ctx;
int err;
 
-   if (sw->sw_ictx == 0)
+   if (sw->sw_ictx == NULL)
return EINVAL;
 
axf = sw->sw_axf;
@@ -521,7 +521,7 @@ swcr_authenc(struct cryptop *crp)
swa = sw;
crda = crd;
axf = swa->sw_axf;
-   if (swa->sw_ictx == 0)
+   if (swa->sw_ictx == NULL)
return (EINVAL);
bcopy(swa->sw_ictx, , axf->ctxsize);
blksz = axf->blocksize;
diff --git sys/nfs/nfs_socket.c sys/nfs/nfs_socket.c
index 38e0ee99d66..6f265982818 100644
--- sys/nfs/nfs_socket.c
+++ sys/nfs/nfs_socket.c
@@ -824,7 +824,7 @@ nfsmout:
 * If not matched to a request, drop it.
 * If it's mine, get out.
 */
-   if (rep == 0) {
+   if (rep == NULL) {
nfsstats.rpcunexpected++;
m_freem(info.nmi_mrep);
} else if (rep == myrep) {
diff --git sys/scsi/scsiconf.c sys/scsi/scsiconf.c
index baa4dfdcdd7..e41717d387a 100644
--- sys/scsi/scsiconf.c
+++ sys/scsi/scsiconf.c
@@ -701,7 +701,7 @@ scsi_probe_link(struct scsibus_softc *sb, int target, int 
lun, int dumbscan)
sa.sa_sc_link = link;
 
if ((cf = config_search(scsibussubmatch, (struct device *)sb,
-   )) == 0) {
+   )) == NULL) {
scsibussubprint(, sb->sc_dev.dv_xname);
printf(" not configured\n");
goto free_devid;
@@ -1089,7 +1089,8 @@ scsi_inqmatch(struct scsi_inquiry_data *inqbuf, const 
void *_base,
/* Include the qualifier to catch vendor-unique types. */
removable = ISSET(inqbuf->dev_qual2, SID_REMOVABLE) ? T_REMOV : T_FIXED;
 
-   for (*bestpriority = 0, bestmatch = 0; nmatches--; base += matchsize) {
+   for (*bestpriority = 0, bestmatch = NULL; nmatches--;
+   base += matchsize) {
struct scsi_inquiry_pattern *match = (void *)base;
int priority, len;
 
diff --git sys/uvm/uvm_swap.c sys/uvm/uvm_swap.c
index d333e547e06..a2287333574 100644
--- sys/uvm/uvm_swap.c
+++ sys/uvm/uvm_swap.c
@@ -272,8 +272,8 @@ uvm_swap_init(void)
 * or no allocation).
 */
swapmap = extent_create("swapmap", 1, INT_MAX,
-   M_VMSWAP, 0, 0, EX_NOWAIT);
-   if (swapmap == 0)
+   M_VMSWAP, NULL, 0, EX_NOWAIT);
+   if (swapmap == NULL)
panic("uvm_swap_init: extent_create failed");
 
/* allocate pools for structures used for swapping to files. */
@@ -863,7 +863,7 @@ swap_on(struct proc *p, struct swapdev *sdp)
 */
switch (vp->v_type) {
case VBLK:
-   if (bdevsw[major(dev)].d_psize == 0 ||
+   if (bdevsw[major(dev)].d_psize == NULL ||
(nblocks = (*bdevsw[major(dev)].d_psize)(dev)) == -1) {
error = ENXIO;
goto bad;
@@ -939,7 +939,7 @@ swap_on(struct proc *p, struct swapdev *sdp)
 
/* note that extent_create's 3rd arg is inclusive, thus "- 1" */
sdp->swd_ex = extent_create(sdp->swd_exname, 0, npages - 1, M_VMSWAP,
-   0, 0, EX_WAITOK);
+   NULL, 0, EX_WAITOK);
/* allocate the `saved' region from the extent so it won't be used */
if (addr) {
if (extent_alloc_region(sdp->swd_ex, 0, addr, EX_WAITOK))
diff --git sys/uvm/uvm_vnode.c sys/uvm/uvm_vnode.c
index 3cbdd5222b6..f4f29196800 100644
--- sys/uvm/uvm_vnode.c
+++ sys/uvm/uvm_vnode.c
@@ -614,7 +614,7 @@ uvn_flush(struct uvm_object *uobj, voff_t start, voff_t 
stop, int flags)
 * [borrowed PG_CLEANCHK idea from FreeBSD VM]
 */
if ((flags & PGO_CLEANIT) != 0) {
-   KASSERT(uobj->pgops->pgo_mk_pcluster != 0);
+   KASSERT(uobj->pgops->pgo_mk_pcluster != NULL);
for (curoff = start ; curoff < stop; curoff += PAGE_SIZE) {
if ((pp = uvm_pagelookup(uobj, curoff)) != NULL)
atomic_clearbits_int(>pg_flags,



use NULL instead of 0 for pointers in sys/ddb

2021-10-23 Thread Jonathan Gray
diff --git sys/ddb/db_break.c sys/ddb/db_break.c
index dfe2f3af912..85354e32987 100644
--- sys/ddb/db_break.c
+++ sys/ddb/db_break.c
@@ -46,8 +46,8 @@
 #defineNBREAKPOINTS100
 struct db_breakpoint   db_break_table[NBREAKPOINTS];
 db_breakpoint_tdb_next_free_breakpoint = _break_table[0];
-db_breakpoint_tdb_free_breakpoints = 0;
-db_breakpoint_tdb_breakpoint_list = 0;
+db_breakpoint_tdb_free_breakpoints = NULL;
+db_breakpoint_tdb_breakpoint_list = NULL;
 
 db_breakpoint_t db_breakpoint_alloc(void);
 void db_breakpoint_free(db_breakpoint_t);
@@ -60,13 +60,13 @@ db_breakpoint_alloc(void)
 {
db_breakpoint_t bkpt;
 
-   if ((bkpt = db_free_breakpoints) != 0) {
+   if ((bkpt = db_free_breakpoints) != NULL) {
db_free_breakpoints = bkpt->link;
return (bkpt);
}
if (db_next_free_breakpoint == _break_table[NBREAKPOINTS]) {
db_printf("All breakpoints used.\n");
-   return (0);
+   return (NULL);
}
bkpt = db_next_free_breakpoint;
db_next_free_breakpoint++;
@@ -99,7 +99,7 @@ db_set_breakpoint(vaddr_t addr, int count)
 #endif
 
bkpt = db_breakpoint_alloc();
-   if (bkpt == 0) {
+   if (bkpt == NULL) {
db_printf("Too many breakpoints.\n");
return;
}
@@ -119,14 +119,14 @@ db_delete_breakpoint(vaddr_t addr)
db_breakpoint_t bkpt;
db_breakpoint_t *prev;
 
-   for (prev = _breakpoint_list; (bkpt = *prev) != 0;
+   for (prev = _breakpoint_list; (bkpt = *prev) != NULL;
prev = >link) {
if (bkpt->address == addr) {
*prev = bkpt->link;
break;
}
}
-   if (bkpt == 0) {
+   if (bkpt == NULL) {
db_printf("Not set.\n");
return;
}
@@ -139,11 +139,11 @@ db_find_breakpoint(vaddr_t addr)
 {
db_breakpoint_t bkpt;
 
-   for (bkpt = db_breakpoint_list; bkpt != 0; bkpt = bkpt->link)
+   for (bkpt = db_breakpoint_list; bkpt != NULL; bkpt = bkpt->link)
if (bkpt->address == addr)
return (bkpt);
 
-   return (0);
+   return (NULL);
 }
 
 int db_breakpoints_inserted = 1;
@@ -154,7 +154,8 @@ db_set_breakpoints(void)
db_breakpoint_t bkpt;
 
if (!db_breakpoints_inserted) {
-   for (bkpt = db_breakpoint_list; bkpt != 0; bkpt = bkpt->link) {
+   for (bkpt = db_breakpoint_list; bkpt != NULL;
+   bkpt = bkpt->link) {
bkpt->bkpt_inst =
db_get_value(bkpt->address, BKPT_SIZE, 0);
db_put_value(bkpt->address, BKPT_SIZE,
@@ -170,7 +171,7 @@ db_clear_breakpoints(void)
db_breakpoint_t bkpt;
 
if (db_breakpoints_inserted) {
-   for (bkpt = db_breakpoint_list; bkpt != 0; bkpt = bkpt->link)
+   for (bkpt = db_breakpoint_list; bkpt != NULL; bkpt = bkpt->link)
db_put_value(bkpt->address, BKPT_SIZE, bkpt->bkpt_inst);
db_breakpoints_inserted = 0;
}
@@ -194,9 +195,9 @@ db_set_temp_breakpoint(vaddr_t addr)
 #endif
 
bkpt = db_breakpoint_alloc();
-   if (bkpt == 0) {
+   if (bkpt == NULL) {
db_printf("Too many breakpoints.\n");
-   return (0);
+   return (NULL);
}
 
bkpt->address = addr;
@@ -230,7 +231,7 @@ db_list_breakpoints(void)
}
 
db_printf(" CountAddress\n");
-   for (bkpt = db_breakpoint_list; bkpt != 0; bkpt = bkpt->link) {
+   for (bkpt = db_breakpoint_list; bkpt != NULL; bkpt = bkpt->link) {
db_printf(" %5d", bkpt->init_count);
db_printsym(bkpt->address, DB_STGY_PROC, db_printf);
db_printf("\n");
diff --git sys/ddb/db_command.c sys/ddb/db_command.c
index 57f0b7c1257..0f1d8edecee 100644
--- sys/ddb/db_command.c
+++ sys/ddb/db_command.c
@@ -148,7 +148,7 @@ db_cmd_search(char *name, struct db_command *table, struct 
db_command **cmdp)
struct db_command   *cmd;
int result = CMD_NONE;
 
-   for (cmd = table; cmd->name != 0; cmd++) {
+   for (cmd = table; cmd->name != NULL; cmd++) {
char *lp = name, *rp = cmd->name;
int  c;
 
@@ -181,7 +181,7 @@ db_cmd_list(struct db_command *table)
 {
struct db_command *cmd;
 
-   for (cmd = table; cmd->name != 0; cmd++) {
+   for (cmd = table; cmd->name != NULL; cmd++) {
db_printf("%-12s", cmd->name);
db_end_line(12);
}
@@ -227,7 +227,7 @@ db_command(struct db_command **last_cmdp, struct db_command 
*cmd_table)
default:
break;
}
-   if 

use NULL instead of 0 for pointers in sys/netinet*

2021-10-23 Thread Jonathan Gray
diff --git sys/netinet/in_pcb.c sys/netinet/in_pcb.c
index cd60f66b50a..d3b6e4a1015 100644
--- sys/netinet/in_pcb.c
+++ sys/netinet/in_pcb.c
@@ -756,7 +756,7 @@ in_rtchange(struct inpcb *inp, int errno)
 {
if (inp->inp_route.ro_rt) {
rtfree(inp->inp_route.ro_rt);
-   inp->inp_route.ro_rt = 0;
+   inp->inp_route.ro_rt = NULL;
/*
 * A new route can be allocated the next time
 * output is attempted.
diff --git sys/netinet/ip_input.c sys/netinet/ip_input.c
index 3915225657e..0c5db58ac6b 100644
--- sys/netinet/ip_input.c
+++ sys/netinet/ip_input.c
@@ -945,11 +945,11 @@ insert:
for (p = NULL, q = LIST_FIRST(>ipq_fragq); q != NULL;
p = q, q = LIST_NEXT(q, ipqe_q)) {
if (ntohs(q->ipqe_ip->ip_off) != next)
-   return (0);
+   return (NULL);
next += ntohs(q->ipqe_ip->ip_len);
}
if (p->ipqe_mff)
-   return (0);
+   return (NULL);
 
/*
 * Reassembly is complete.  Check for a bogus message size and
@@ -960,11 +960,11 @@ insert:
if ((next + (ip->ip_hl << 2)) > IP_MAXPACKET) {
ipstat_inc(ips_toolong);
ip_freef(fp);
-   return (0);
+   return (NULL);
}
m = q->ipqe_m;
t = m->m_next;
-   m->m_next = 0;
+   m->m_next = NULL;
m_cat(m, t);
nq = LIST_NEXT(q, ipqe_q);
pool_put(_pool, q);
diff --git sys/netinet/ip_ipcomp.c sys/netinet/ip_ipcomp.c
index 4a2a52f42af..8e54dae0779 100644
--- sys/netinet/ip_ipcomp.c
+++ sys/netinet/ip_ipcomp.c
@@ -255,7 +255,8 @@ ipcomp_input_cb(struct tdb *tdb, struct tdb_crypto *tc, 
struct mbuf *m, int clen
/* In case it's not done already, adjust the size of the mbuf chain */
m->m_pkthdr.len = clen + hlen + skip;
 
-   if ((m->m_len < skip + hlen) && (m = m_pullup(m, skip + hlen)) == 0) {
+   if ((m->m_len < skip + hlen) &&
+   (m = m_pullup(m, skip + hlen)) == NULL) {
ipcompstat_inc(ipcomps_hdrops);
goto baddone;
}
diff --git sys/netinet/tcp_input.c sys/netinet/tcp_input.c
index 288cfa87706..5ff904361dd 100644
--- sys/netinet/tcp_input.c
+++ sys/netinet/tcp_input.c
@@ -2549,7 +2549,7 @@ tcp_sack_option(struct tcpcb *tp, struct tcphdr *th, 
u_char *cp, int optlen)
if (temp->dups < 1)
temp->dups = 1;
temp->rxmit = temp->start;
-   temp->next = 0;
+   temp->next = NULL;
p->next = temp;
tp->rcv_lastsack = sack.end;
tp->snd_numholes++;
@@ -3576,7 +3576,7 @@ syn_cache_get(struct sockaddr *src, struct sockaddr *dst, 
struct tcphdr *th,
tp->t_flags |= TF_REQ_TSTMP|TF_RCVD_TSTMP;
 
tp->t_template = tcp_template(tp);
-   if (tp->t_template == 0) {
+   if (tp->t_template == NULL) {
tp = tcp_drop(tp, ENOBUFS); /* destroys socket */
so = NULL;
goto abort;
diff --git sys/netinet/tcp_output.c sys/netinet/tcp_output.c
index 8d603d35699..8fcd8761d03 100644
--- sys/netinet/tcp_output.c
+++ sys/netinet/tcp_output.c
@@ -672,7 +672,7 @@ send:
} else {
m->m_next = m_copym(so->so_snd.sb_mb, off, (int) len,
M_NOWAIT);
-   if (m->m_next == 0) {
+   if (m->m_next == NULL) {
(void) m_free(m);
error = ENOBUFS;
goto out;
diff --git sys/netinet/tcp_subr.c sys/netinet/tcp_subr.c
index 87819a1a74b..80c0da43e08 100644
--- sys/netinet/tcp_subr.c
+++ sys/netinet/tcp_subr.c
@@ -194,10 +194,10 @@ tcp_template(struct tcpcb *tp)
CTASSERT(sizeof(struct ip) + sizeof(struct tcphdr) <= MHLEN);
CTASSERT(sizeof(struct ip6_hdr) + sizeof(struct tcphdr) <= MHLEN);
 
-   if ((m = tp->t_template) == 0) {
+   if ((m = tp->t_template) == NULL) {
m = m_get(M_DONTWAIT, MT_HEADER);
if (m == NULL)
-   return (0);
+   return (NULL);
 
switch (tp->pf) {
case 0: /*default to PF_INET*/
@@ -510,7 +510,7 @@ tcp_close(struct tcpcb *tp)
 
/* Free SACK holes. */
q = p = tp->snd_holes;
-   while (p != 0) {
+   while (p != NULL) {
q = p->next;
pool_put(_pool, p);
p = q;
@@ -722,7 +722,7 @@ tcp_ctlinput(int cmd, struct sockaddr *sa, u_int rdomain, 
void *v)
 */
return;
else if (PRC_IS_REDIRECT(cmd))
-   notify = in_rtchange, ip = 0;
+   notify = in_rtchange, ip = NULL;
else if (cmd == PRC_MSGSIZE 

use NULL instead of 0 for pointers in sys/net

2021-10-23 Thread Jonathan Gray
diff --git sys/net/bpf.c sys/net/bpf.c
index 87a9d726423..87418c3dc17 100644
--- sys/net/bpf.c
+++ sys/net/bpf.c
@@ -1019,7 +1019,7 @@ bpf_setf(struct bpf_d *d, struct bpf_program *fp, int wf)
 
KERNEL_ASSERT_LOCKED();
 
-   if (fp->bf_insns == 0) {
+   if (fp->bf_insns == NULL) {
if (fp->bf_len != 0)
return (EINVAL);
bps = NULL;
diff --git sys/net/if.c sys/net/if.c
index 8fe99eff4df..6bd8899561c 100644
--- sys/net/if.c
+++ sys/net/if.c
@@ -1440,7 +1440,8 @@ ifaof_ifpforaddr(struct sockaddr *addr, struct ifnet *ifp)
continue;
if (ifa_maybe == NULL)
ifa_maybe = ifa;
-   if (ifa->ifa_netmask == 0 || ifp->if_flags & IFF_POINTOPOINT) {
+   if (ifa->ifa_netmask == NULL ||
+   ifp->if_flags & IFF_POINTOPOINT) {
if (equal(addr, ifa->ifa_addr) ||
(ifa->ifa_dstaddr && equal(addr, ifa->ifa_dstaddr)))
return (ifa);
diff --git sys/net/if_mpip.c sys/net/if_mpip.c
index a8daeeea314..fe155eb18d8 100644
--- sys/net/if_mpip.c
+++ sys/net/if_mpip.c
@@ -96,7 +96,7 @@ mpip_clone_create(struct if_clone *ifc, int unit)
 
sc->sc_txhprio = 0;
sc->sc_rxhprio = IF_HDRPRIO_PACKET;
-   sc->sc_neighbor = 0;
+   sc->sc_neighbor = NULL;
sc->sc_cword = 0; /* default to no control word */
sc->sc_fword = 0; /* both sides have to agree on FAT first */
sc->sc_flow = arc4random() & 0xf;
diff --git sys/net/if_ppp.c sys/net/if_ppp.c
index fb32d9ea9ef..c3b6d9051b7 100644
--- sys/net/if_ppp.c
+++ sys/net/if_ppp.c
@@ -324,21 +324,21 @@ pppdealloc(struct ppp_softc *sc)
sc->sc_rc_state = NULL;
 #endif /* PPP_COMPRESS */
 #if NBPFILTER > 0
-   if (sc->sc_pass_filt.bf_insns != 0) {
+   if (sc->sc_pass_filt.bf_insns != NULL) {
free(sc->sc_pass_filt.bf_insns, M_DEVBUF, 0);
-   sc->sc_pass_filt.bf_insns = 0;
+   sc->sc_pass_filt.bf_insns = NULL;
sc->sc_pass_filt.bf_len = 0;
}
-   if (sc->sc_active_filt.bf_insns != 0) {
+   if (sc->sc_active_filt.bf_insns != NULL) {
free(sc->sc_active_filt.bf_insns, M_DEVBUF, 0);
-   sc->sc_active_filt.bf_insns = 0;
+   sc->sc_active_filt.bf_insns = NULL;
sc->sc_active_filt.bf_len = 0;
}
 #endif
 #ifdef VJC
-   if (sc->sc_comp != 0) {
+   if (sc->sc_comp != NULL) {
free(sc->sc_comp, M_DEVBUF, 0);
-   sc->sc_comp = 0;
+   sc->sc_comp = NULL;
}
 #endif
NET_UNLOCK();
@@ -538,7 +538,7 @@ pppioctl(struct ppp_softc *sc, u_long cmd, caddr_t data, 
int flag,
return EINVAL;
}
} else
-   newcode = 0;
+   newcode = NULL;
bp = (cmd == PPPIOCSPASS) ?
>sc_pass_filt : >sc_active_filt;
oldcode = bp->bf_insns;
@@ -546,7 +546,7 @@ pppioctl(struct ppp_softc *sc, u_long cmd, caddr_t data, 
int flag,
bp->bf_len = nbp->bf_len;
bp->bf_insns = newcode;
splx(s);
-   if (oldcode != 0)
+   if (oldcode != NULL)
free(oldcode, M_DEVBUF, 0);
break;
 #endif
@@ -730,7 +730,7 @@ pppoutput(struct ifnet *ifp, struct mbuf *m0, struct 
sockaddr *dst,
 * but only if it is a data packet.
 */
*mtod(m0, u_char *) = 1;/* indicates outbound */
-   if (sc->sc_pass_filt.bf_insns != 0 &&
+   if (sc->sc_pass_filt.bf_insns != NULL &&
bpf_filter(sc->sc_pass_filt.bf_insns, (u_char *)m0,
len, 0) == 0) {
error = 0; /* drop this packet */
@@ -740,7 +740,7 @@ pppoutput(struct ifnet *ifp, struct mbuf *m0, struct 
sockaddr *dst,
/*
 * Update the time we sent the most recent packet.
 */
-   if (sc->sc_active_filt.bf_insns == 0 ||
+   if (sc->sc_active_filt.bf_insns == NULL ||
bpf_filter(sc->sc_active_filt.bf_insns, (u_char *)m0,
len, 0))
sc->sc_last_sent = getuptime();
@@ -1254,7 +1254,7 @@ ppp_inproc(struct ppp_softc *sc, struct mbuf *m)
 * See if we have a VJ-compressed packet to uncompress.
 */
if (proto == PPP_VJC_COMP) {
-   if ((sc->sc_flags & SC_REJ_COMP_TCP) || sc->sc_comp == 0)
+   if ((sc->sc_flags & SC_REJ_COMP_TCP) || sc->sc_comp == NULL)
goto bad;
 
xlen = sl_uncompress_tcp_core(cp + PPP_HDRLEN,
@@ -1311,7 +1311,7 @@ ppp_inproc(struct ppp_softc *sc, struct mbuf *m)
ilen += hlen - xlen;
 
} 

Re: pcidevs: intel gemini lake mei

2021-10-21 Thread Jonathan Gray
On Thu, Oct 21, 2021 at 11:17:56PM +0200, Felix Kronlage-Dammers wrote:
> hi,
> 
> found this mei pci device id in a gemini lake based shuttle pc.

thanks, committed



Re: patch: nullify v_data with NULL (and not with 0)

2021-10-19 Thread Jonathan Gray
On Tue, Oct 19, 2021 at 07:37:36AM -0600, Todd C. Miller wrote:
> On Tue, 19 Oct 2021 18:08:04 +1100, Jonathan Gray wrote:
> 
> > There are many others along those lines in the kernel, for example
> > sparse complains about these in vfs_subr.c
> >
> > /sys/kern/vfs_subr.c:274:64: warning: Using plain integer as NULL pointer
> > /sys/kern/vfs_subr.c:275:64: warning: Using plain integer as NULL pointer
> > /sys/kern/vfs_subr.c:430:32: warning: Using plain integer as NULL pointer
> > /sys/kern/vfs_subr.c:467:22: warning: Using plain integer as NULL pointer
> > /sys/kern/vfs_subr.c:533:50: warning: Using plain integer as NULL pointer
> > /sys/kern/vfs_subr.c:1150:77: warning: Using plain integer as NULL pointer
> > /sys/kern/vfs_subr.c:1430:42: warning: Using plain integer as NULL pointer
> > /sys/kern/vfs_subr.c:1483:19: warning: Using plain integer as NULL pointer
> > /sys/kern/vfs_subr.c:1752:25: warning: Using plain integer as NULL pointer
> >
> > If this is something worth changing should it be a larger diff?
> 
> I think it is worth changing.  Using NULL in place of 0 makes the
> code easier to parse for humans too.
> 
>  - todd

amd64 mp build shows 923 warnings though some of those are in places
we wouldn't want to change like libz and drm.

here is a diff to remove the warnings from sys/kern/

diff --git sys/ddb/db_sym.h sys/ddb/db_sym.h
index fe1aff6d6af..c8daa983104 100644
--- sys/ddb/db_sym.h
+++ sys/ddb/db_sym.h
@@ -75,11 +75,11 @@ void db_symbol_values(Elf_Sym *, char **, db_expr_t *);
/* return name and value of symbol */
 
 #define db_find_sym_and_offset(val,namep,offp) \
-   db_symbol_values(db_search_symbol(val,DB_STGY_ANY,offp),namep,0)
+   db_symbol_values(db_search_symbol(val,DB_STGY_ANY,offp),namep,NULL)
/* find name given approx val */
 
 #define db_find_xtrn_sym_and_offset(val,namep,offp)\
-   db_symbol_values(db_search_symbol(val,DB_STGY_XTRN,offp),namep,0)
+   db_symbol_values(db_search_symbol(val,DB_STGY_XTRN,offp),namep,NULL)
/* ditto, but no locals */
 
 void db_printsym(db_expr_t, db_strategy_t, int (*)(const char *, ...));
diff --git sys/kern/kern_exit.c sys/kern/kern_exit.c
index 0c6ceb3546d..3b194b054af 100644
--- sys/kern/kern_exit.c
+++ sys/kern/kern_exit.c
@@ -266,7 +266,7 @@ exit1(struct proc *p, int xexit, int xsig, int flags)
qr = LIST_FIRST(>ps_children);
if (qr) /* only need this if any child is S_ZOMB */
wakeup(initprocess);
-   for (; qr != 0; qr = nqr) {
+   for (; qr != NULL; qr = nqr) {
nqr = LIST_NEXT(qr, ps_sibling);
/*
 * Traced processes are killed since their
diff --git sys/kern/kern_proc.c sys/kern/kern_proc.c
index bbe709ea883..a2fa098273e 100644
--- sys/kern/kern_proc.c
+++ sys/kern/kern_proc.c
@@ -320,7 +320,7 @@ leavepgrp(struct process *pr)
LIST_REMOVE(pr, ps_pglist);
if (LIST_EMPTY(>ps_pgrp->pg_members))
pgdelete(pr->ps_pgrp);
-   pr->ps_pgrp = 0;
+   pr->ps_pgrp = NULL;
 }
 
 /*
diff --git sys/kern/kern_prot.c sys/kern/kern_prot.c
index f6fff9d87bb..5414550def0 100644
--- sys/kern/kern_prot.c
+++ sys/kern/kern_prot.c
@@ -271,7 +271,8 @@ sys_setpgid(struct proc *curp, void *v, register_t *retval)
newpgrp = pool_get(_pool, PR_WAITOK);
 
if (pid != 0 && pid != curpr->ps_pid) {
-   if ((targpr = prfind(pid)) == 0 || !inferior(targpr, curpr)) {
+   if ((targpr = prfind(pid)) == NULL ||
+   !inferior(targpr, curpr)) {
error = ESRCH;
goto out;
}
diff --git sys/kern/kern_sig.c sys/kern/kern_sig.c
index 83d183aed8d..f5c42ab5fc8 100644
--- sys/kern/kern_sig.c
+++ sys/kern/kern_sig.c
@@ -230,7 +230,7 @@ sigstkinit(struct sigaltstack *ss)
 {
ss->ss_flags = SS_DISABLE;
ss->ss_size = 0;
-   ss->ss_sp = 0;
+   ss->ss_sp = NULL;
 }
 
 /*
@@ -1116,7 +1116,7 @@ ptsignal(struct proc *p, int signum, enum signal_type 
type)
atomic_clearbits_int(siglist, mask);
if (action == SIG_CATCH)
goto runfast;
-   if (p->p_wchan == 0)
+   if (p->p_wchan == NULL)
goto run;
p->p_stat = SSLEEP;
goto out;
@@ -1410,12 +1410,12 @@ postsig(struct proc *p, int signum)
action = ps->ps_sigact[signum];
info = (ps->ps_siginfo & mask) != 0;
onstack = (ps->ps_sigonstack & mask) != 0;
-   sigval.sival_ptr 

Re: patch: nullify v_data with NULL (and not with 0)

2021-10-19 Thread Jonathan Gray
On Tue, Oct 19, 2021 at 08:32:57AM +0200, Sebastien Marie wrote:
> Hi,
> 
> Simple online diff for properly nullify v_data (which is `void *`)
> with NULL instead of 0.
> 
> Comments or OK ?
> -- 
> Sebastien Marie
> 

There are many others along those lines in the kernel, for example
sparse complains about these in vfs_subr.c

/sys/kern/vfs_subr.c:274:64: warning: Using plain integer as NULL pointer
/sys/kern/vfs_subr.c:275:64: warning: Using plain integer as NULL pointer
/sys/kern/vfs_subr.c:430:32: warning: Using plain integer as NULL pointer
/sys/kern/vfs_subr.c:467:22: warning: Using plain integer as NULL pointer
/sys/kern/vfs_subr.c:533:50: warning: Using plain integer as NULL pointer
/sys/kern/vfs_subr.c:1150:77: warning: Using plain integer as NULL pointer
/sys/kern/vfs_subr.c:1430:42: warning: Using plain integer as NULL pointer
/sys/kern/vfs_subr.c:1483:19: warning: Using plain integer as NULL pointer
/sys/kern/vfs_subr.c:1752:25: warning: Using plain integer as NULL pointer

If this is something worth changing should it be a larger diff?

> 
> blob - 1f7409235f4696765c6b8b22e65d953b1d6e5100
> blob + 8cb011e9c3e48fcc34b8ce62974cafd430bb4e6a
> --- sys/kern/vfs_subr.c
> +++ sys/kern/vfs_subr.c
> @@ -469,7 +469,7 @@ getnewvnode(enum vtagtype tag, struct mount *mp, const
>   panic("%s: free vnode %p isn't lock free", __func__, vp);
>  #endif
>   vp->v_usecount = 1;
> - vp->v_data = 0;
> + vp->v_data = NULL;
>   return (0);
>  }
>  
> 
> 



Re: [diff] usr.sbin/smtpd add missing includes

2021-10-17 Thread Jonathan Gray
On Sun, Oct 17, 2021 at 04:23:50PM +0200, Philipp wrote:
> Hello
> 
> I'm currently working on getting OpenSMTPD-portable build. During this
> I found some missing includes.

It would help if you could describe the platform you are building on and
show the compile errors.

> 
> diff --git a/usr.sbin/smtpd/parse.y b/usr.sbin/smtpd/parse.y
> index 7de52a1c568..b1307c4daa6 100644
> --- a/usr.sbin/smtpd/parse.y
> +++ b/usr.sbin/smtpd/parse.y
> @@ -28,6 +28,8 @@
>  #include 
>  #include 
>  
> +#include 
> +#include 
>  #include 
>  #include 
>  #include 
> diff --git a/usr.sbin/smtpd/smtpctl.c b/usr.sbin/smtpd/smtpctl.c
> index 3d5926efdad..9e88f150ae5 100644
> --- a/usr.sbin/smtpd/smtpctl.c
> +++ b/usr.sbin/smtpd/smtpctl.c
> @@ -27,6 +27,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> 
> 



Re: missing newlines in est.c printfs

2021-08-12 Thread Jonathan Gray
On Thu, Aug 12, 2021 at 07:47:36AM +0200, Theo Buehler wrote:
> On Thu, Aug 12, 2021 at 03:01:37PM +1000, Jonathan Gray wrote:
> > On Thu, Aug 12, 2021 at 06:44:51AM +0200, Theo Buehler wrote:
> > > There doesn't seem to be a good reason for omitting the newlines here.
> > > If those are ever hit, it will look odd. Am I missing something?
> > 
> > See the i386 p3_get_bus_clock() which is where this came from.
> > i386 prints the msr value and a newline.
> > 
> > Wether that part is added to amd64 or removed from i386 it would be best
> > to keep them in sync as much as possible.
> 
> Thanks. This syncs the print_msr code path from i386 in p3_get_bus_clock
> and adds the missing newlines in est_acpi_pss_changed() in i386.

ok jsg@

> 
> Index: sys/arch/i386/i386/est.c
> ===
> RCS file: /cvs/src/sys/arch/i386/i386/est.c,v
> retrieving revision 1.52
> diff -u -p -r1.52 est.c
> --- sys/arch/i386/i386/est.c  31 Mar 2018 13:45:03 -  1.52
> +++ sys/arch/i386/i386/est.c  12 Aug 2021 05:46:12 -
> @@ -1017,14 +1017,14 @@ est_acpi_pss_changed(struct acpicpu_pss 
>   if ((acpilist = malloc(sizeof(struct fqlist), M_DEVBUF, M_NOWAIT))
>   == NULL) {
>   printf("est_acpi_pss_changed: cannot allocate memory for new "
> - "est state");
> + "est state\n");
>   return;
>   }
>  
>   if ((acpilist->table = mallocarray(npss, sizeof(struct est_op),
>   M_DEVBUF, M_NOWAIT)) == NULL) {
>   printf("est_acpi_pss_changed: cannot allocate memory for new "
> - "operating points");
> + "operating points\n");
>   free(acpilist, M_DEVBUF, sizeof(*acpilist));
>   return;
>   }
> Index: sys/arch/amd64/amd64/est.c
> ===
> RCS file: /cvs/src/sys/arch/amd64/amd64/est.c,v
> retrieving revision 1.40
> diff -u -p -r1.40 est.c
> --- sys/arch/amd64/amd64/est.c11 Aug 2021 18:15:50 -  1.40
> +++ sys/arch/amd64/amd64/est.c12 Aug 2021 05:32:49 -
> @@ -187,7 +187,7 @@ p3_get_bus_clock(struct cpu_info *ci)
>   default:
>   printf("%s: unknown Core FSB_FREQ value %d",
>   ci->ci_dev->dv_xname, bus);
> - break;
> + goto print_msr;
>   }
>   break;
>   case 0x1c: /* Atom */
> @@ -211,13 +211,20 @@ p3_get_bus_clock(struct cpu_info *ci)
>   default:
>   printf("%s: unknown Atom FSB_FREQ value %d",
>   ci->ci_dev->dv_xname, bus);
> - break;
> + goto print_msr;
>   }
>   break;
>   default:
>   /* no FSB on modern Intel processors */
>   break;
>   }
> + return;
> +print_msr:
> + /*
> +  * Show the EBL_CR_POWERON MSR, so we'll at least have
> +  * some extra information, such as clock ratio, etc.
> +  */
> + printf(" (0x%llx)\n", rdmsr(MSR_EBL_CR_POWERON));
>  }
>  
>  #if NACPICPU > 0
> @@ -291,14 +298,14 @@ est_acpi_pss_changed(struct acpicpu_pss 
>   if ((acpilist = malloc(sizeof(struct fqlist), M_DEVBUF, M_NOWAIT))
>   == NULL) {
>   printf("est_acpi_pss_changed: cannot allocate memory for new "
> - "est state");
> + "est state\n");
>   return;
>   }
>  
>   if ((acpilist->table = mallocarray(npss, sizeof(struct est_op),
>   M_DEVBUF, M_NOWAIT)) == NULL) {
>   printf("est_acpi_pss_changed: cannot allocate memory for new "
> - "operating points");
> + "operating points\n");
>   free(acpilist, M_DEVBUF, sizeof(struct fqlist));
>   return;
>   }
> 
> 



Re: missing newlines in est.c printfs

2021-08-11 Thread Jonathan Gray
On Thu, Aug 12, 2021 at 06:44:51AM +0200, Theo Buehler wrote:
> There doesn't seem to be a good reason for omitting the newlines here.
> If those are ever hit, it will look odd. Am I missing something?

See the i386 p3_get_bus_clock() which is where this came from.
i386 prints the msr value and a newline.

Wether that part is added to amd64 or removed from i386 it would be best
to keep them in sync as much as possible.

> 
> Index: est.c
> ===
> RCS file: /cvs/src/sys/arch/amd64/amd64/est.c,v
> retrieving revision 1.40
> diff -u -p -r1.40 est.c
> --- est.c 11 Aug 2021 18:15:50 -  1.40
> +++ est.c 12 Aug 2021 04:40:14 -
> @@ -185,7 +185,7 @@ p3_get_bus_clock(struct cpu_info *ci)
>   bus_clock = BUS333;
>   break;
>   default:
> - printf("%s: unknown Core FSB_FREQ value %d",
> + printf("%s: unknown Core FSB_FREQ value %d\n",
>   ci->ci_dev->dv_xname, bus);
>   break;
>   }
> @@ -209,7 +209,7 @@ p3_get_bus_clock(struct cpu_info *ci)
>   bus_clock = BUS200;
>   break;
>   default:
> - printf("%s: unknown Atom FSB_FREQ value %d",
> + printf("%s: unknown Atom FSB_FREQ value %d\n",
>   ci->ci_dev->dv_xname, bus);
>   break;
>   }
> @@ -291,14 +291,14 @@ est_acpi_pss_changed(struct acpicpu_pss 
>   if ((acpilist = malloc(sizeof(struct fqlist), M_DEVBUF, M_NOWAIT))
>   == NULL) {
>   printf("est_acpi_pss_changed: cannot allocate memory for new "
> - "est state");
> + "est state\n");
>   return;
>   }
>  
>   if ((acpilist->table = mallocarray(npss, sizeof(struct est_op),
>   M_DEVBUF, M_NOWAIT)) == NULL) {
>   printf("est_acpi_pss_changed: cannot allocate memory for new "
> - "operating points");
> + "operating points\n");
>   free(acpilist, M_DEVBUF, sizeof(struct fqlist));
>   return;
>   }
> 
> 



remove efibind.h cruft

2021-07-26 Thread Jonathan Gray
Follow what was done with riscv64 and replace efibind.h with just the
defines we need.

Tested on armv7 arm64 and amd64 (bootx64).

Index: sys/stand/efi/include/amd64/efibind.h
===
RCS file: /cvs/src/sys/stand/efi/include/amd64/efibind.h,v
retrieving revision 1.2
diff -u -p -r1.2 efibind.h
--- sys/stand/efi/include/amd64/efibind.h   4 Jun 2021 00:09:34 -   
1.2
+++ sys/stand/efi/include/amd64/efibind.h   26 Jul 2021 05:39:34 -
@@ -1,271 +1,22 @@
-/* $FreeBSD: head/sys/boot/efi/include/amd64/efibind.h 279038 2015-02-20 
01:40:55Z imp $ */
-/*++
+/* Public Domain. */
 
-Copyright (c)  1999 - 2003 Intel Corporation. All rights reserved
-This software and associated documentation (if any) is furnished
-under a license and may only be used or copied in accordance
-with the terms of the license. Except as permitted by such
-license, no part of this software or documentation may be
-reproduced, stored in a retrieval system, or transmitted in any
-form or by any means without the express written consent of
-Intel Corporation.
-
-Module Name:
-
-efefind.h
-
-Abstract:
-
-EFI to compile bindings
-
-
-
-
-Revision History
-
---*/
-
-#pragma pack()
-
-
-#if defined(__FreeBSD__) || defined(__OpenBSD__)
 #include 
-#else
-//
-// Basic int types of various widths
-//
-
-#if (__STDC_VERSION__ < 199901L )
-
-// No ANSI C 1999/2000 stdint.h integer width declarations
-
-#if _MSC_EXTENSIONS
-
-// Use Microsoft C compiler integer width declarations
-
-typedef unsigned __int64uint64_t;
-typedef __int64 int64_t;
-typedef unsigned __int32uint32_t;
-typedef __int32 int32_t;
-typedef unsigned short  uint16_t;
-typedef short   int16_t;
-typedef unsigned char   uint8_t;
-typedef charint8_t;
-#else
-#ifdef UNIX_LP64
-
-// Use LP64 programming model from C_FLAGS for integer width 
declarations
-
-typedef unsigned long   uint64_t;
-typedef longint64_t;
-typedef unsigned intuint32_t;
-typedef int int32_t;
-typedef unsigned short  uint16_t;
-typedef short   int16_t;
-typedef unsigned char   uint8_t;
-typedef charint8_t;
-#else
-
-// Assume P64 programming model from C_FLAGS for integer width 
declarations
-
-typedef unsigned long long  uint64_t;
-typedef long long   int64_t;
-typedef unsigned intuint32_t;
-typedef int int32_t;
-typedef unsigned short  uint16_t;
-typedef short   int16_t;
-typedef unsigned char   uint8_t;
-typedef charint8_t;
-#endif
-#endif
-#endif
-#endif /* __FreeBSD__ || __OpenBSD__ */
-
-//
-// Basic EFI types of various widths
-//
-
-#ifndef ACPI_THREAD_ID /* ACPI's definitions are fine */
-#define ACPI_USE_SYSTEM_INTTYPES 1 /* Tell ACPI we've defined types */
-
-typedef uint64_t   UINT64;
-typedef int64_tINT64;
-
-#ifndef _BASETSD_H_
-typedef uint32_t   UINT32;
-typedef int32_tINT32;
-#endif
-
-typedef uint16_t   UINT16;
-typedef int16_tINT16;
-typedef uint8_tUINT8;
-typedef int8_t INT8;
-
-#endif
-
-#undef VOID
-#define VOIDvoid
-
-
-typedef int64_tINTN;
-typedef uint64_t   UINTN;
-
-#ifdef EFI_NT_EMULATOR
-#define POST_CODE(_Data)
-#else
-#ifdef EFI_DEBUG
-#define POST_CODE(_Data)__asm mov eax,(_Data) __asm out 0x80,al
-#else
-#define POST_CODE(_Data)
-#endif
-#endif
-
-#define EFIERR(a)   (0x8000 | a)
-#define EFI_ERROR_MASK  0x8000
-#define EFIERR_OEM(a)   (0xc000 | a)
-
-
-#define BAD_POINTER 0xFBFBFBFBFBFBFBFB
-#define MAX_ADDRESS 0x
-
-#define BREAKPOINT()__asm { int 3 }
-
-//
-// Pointers must be aligned to these address to function
-//
-
-#define MIN_ALIGNMENT_SIZE  4
-
-#define ALIGN_VARIABLE(Value ,Adjustment) \
-(UINTN)Adjustment = 0; \
-if((UINTN)Value % MIN_ALIGNMENT_SIZE) \
-(UINTN)Adjustment = MIN_ALIGNMENT_SIZE - ((UINTN)Value % 
MIN_ALIGNMENT_SIZE); \
-Value = (UINTN)Value + (UINTN)Adjustment
-
-
-//
-// Define macros to build data structure signatures from characters.
-//
-
-#define EFI_SIGNATURE_16(A,B) ((A) | (B<<8))
-#define EFI_SIGNATURE_32(A,B,C,D) (EFI_SIGNATURE_16(A,B) | 
(EFI_SIGNATURE_16(C,D) << 16))
-#define EFI_SIGNATURE_64(A,B,C,D,E,F,G,H) (EFI_SIGNATURE_32(A,B,C,D) | 
((UINT64)(EFI_SIGNATURE_32(E,F,G,H)) << 32))
-
-//
-// EFIAPI - prototype calling convention for EFI function pointers
-// BOOTSERVICE - prototype for 

Re: iwm(4): enable on riscv64

2021-07-25 Thread Jonathan Gray
On Fri, Jul 23, 2021 at 04:36:57PM -0400, Ashton Fagg wrote:
> The following diffs adds iwm(4) to the riscv64 kernel config.
> 
> I tested this with the following device:
> 
> iwm0 at pci5 dev 0 function 0 "Intel Dual Band Wireless-AC 9260" rev 0x29, 
> intx
> 
> icarus$ ifconfig iwm0
> iwm0: flags=808843 mtu 1500
> lladdr bc:54:2f:cb:3b:21
> index 2 priority 4 llprio 3
> groups: wlan egress
> media: IEEE802.11 autoselect (HT-MCS0 mode 11n)
> status: active
> ieee80211: nwid  chan 36 bssid 18:4b:0d:17:c0:ac 100% wpakey 
> wpaprotos wpa2 wpaakms psk wpaciphers ccmp wpagroupcipher ccmp
> inet 192.168.1.76 netmask 0xff00 broadcast 192.168.1.255
> 
> Patch and dmesg to follow. fw_update went fine and after enabling
> debugging on the driver it doesn't seem to be throwing firmware errors
> or anything like that. This is my only iwm(4) compatible device
> unfortunately so I can't test with any others. This seems to be happily
> passing packets.

thanks, committed with the same change in RAMDISK

> 
> 
> Index: sys/arch/riscv64/conf/GENERIC
> ===
> RCS file: /cvs/src/sys/arch/riscv64/conf/GENERIC,v
> retrieving revision 1.26
> diff -u -p -u -p -r1.26 GENERIC
> --- sys/arch/riscv64/conf/GENERIC 12 Jul 2021 19:11:42 -  1.26
> +++ sys/arch/riscv64/conf/GENERIC 23 Jul 2021 20:26:25 -
> @@ -95,6 +95,9 @@ em* at pci? # Intel Pro/1000 Ethernet
>  bge* at pci? # Broadcom BCM57xx (aka Tigon3)
>  oce* at pci? # Emulex OneConnect 10Gb ethernet
>  
> +# Wireless network cards
> +iwm* at pci? # Intel WiFi Link 7xxx
> +
>  nvme*at pci? # NVMe controllers
>  ahci*at pci? # AHCI SATA controllers
> 
> dmesg:
> 
> OpenBSD 6.9-current (GENERIC) #6: Fri Jul 23 16:16:13 EDT 2021
> f...@icarus.fagg.id.au:/usr/src/sys/arch/riscv64/compile/GENERIC
> real mem  = 17179869184 (16384MB)
> avail mem = 16416555008 (15656MB)
> random: good seed from bootblocks
> mainbus0 at root: SiFive HiFive Unmatched A00
> cpu0 at mainbus0: SiFive U7 imp 20181004 rv64imafdc
> intc0 at cpu0
> cpu0: 32KB 64b/line 128-way L1 I-cache, 32KB 64b/line 64-way L1 D-cache
> cpu0: 2048KB 64b/line 2048-way L2 cache
> "fit-images" at mainbus0 not configured
> simplebus0 at mainbus0: "soc"
> plic0 at simplebus0
> sfclock0 at simplebus0
> sfuart0 at simplebus0: console
> sfuart1 at simplebus0
> ociic0 at simplebus0
> iic0 at ociic0
> titmp0 at iic0 addr 0x4c
> dapmic0 at iic0 addr 0x58
> "spi" at simplebus0 not configured
> "spi" at simplebus0 not configured
> cad0 at simplebus0: rev 0x10070109, address 70:b3:d5:92:f9:7b
> ukphy0 at cad0 phy 0: Generic IEEE 802.3u media interface, rev. 2: OUI 
> 0x0001c1, model 0x0037
> "pwm" at simplebus0 not configured
> "pwm" at simplebus0 not configured
> "cache-controller" at simplebus0 not configured
> "gpio" at simplebus0 not configured
> dwpcie0 at simplebus0
> "clint" at simplebus0 not configured
> "dmc" at simplebus0 not configured
> pci0 at dwpcie0
> ppb0 at pci0 dev 0 function 0 "SiFive PCIe" rev 0x00
> pci1 at ppb0 bus 1
> ppb1 at pci1 dev 0 function 0 "ASMedia ASM2824" rev 0x01
> pci2 at ppb1 bus 2
> ppb2 at pci2 dev 0 function 0 "ASMedia ASM2824" rev 0x01: intx
> pci3 at ppb2 bus 3
> ppb3 at pci2 dev 2 function 0 "ASMedia ASM2824" rev 0x01: intx
> pci4 at ppb3 bus 4
> xhci0 at pci4 dev 0 function 0 "ASMedia ASM1042A xHCI" rev 0x00: intx, xHCI 
> 1.0
> usb0 at xhci0: USB revision 3.0
> uhub0 at usb0 configuration 1 interface 0 "ASMedia xHCI root hub" rev 
> 3.00/1.00 addr 1
> ppb4 at pci2 dev 3 function 0 "ASMedia ASM2824" rev 0x01: intx
> pci5 at ppb4 bus 5
> iwm0 at pci5 dev 0 function 0 "Intel Dual Band Wireless-AC 9260" rev 0x29, 
> intx
> ppb5 at pci2 dev 4 function 0 "ASMedia ASM2824" rev 0x01: intx
> pci6 at ppb5 bus 6
> nvme0 at pci6 dev 0 function 0 vendor "Silicon Motion", unknown product 
> 0x2263 rev 0x03: intx, NVMe 1.3
> nvme0: Inland NVMe SSD 256GB, firmware T0918A0L, serial IBSCMC210625600201
> scsibus0 at nvme0: 2 targets, initiator 0
> sd0 at scsibus0 targ 1 lun 0: 
> sd0: 244198MB, 512 bytes/sector, 500118192 sectors
> ppb6 at pci2 dev 8 function 0 "ASMedia ASM2824" rev 0x01: intx
> pci7 at ppb6 bus 7
> "hfclk" at mainbus0 not configured
> "rtcclk" at mainbus0 not configured
> "gpio-poweroff" at mainbus0 not configured
> uhub1 at uhub0 port 2 configuration 1 interface 0 "ASMedia AS2107" rev 
> 3.00/0.01 addr 2
> uhub2 at uhub0 port 4 configuration 1 interface 0 "ASMedia AS2107" rev 
> 2.10/0.01 addr 3
> "vendor 0x8087 product 0x0025" rev 2.00/0.02 addr 4 at uhub2 port 4 not 
> configured
> vscsi0 at root
> scsibus1 at vscsi0: 256 targets
> softraid0 at root
> scsibus2 at softraid0: 256 targets
> root on sd0a (298fb3493efcd19a.a) swap on sd0b dump on sd0b
> iwm0: hw rev 0x320, fw ver 46.6b541b68.0, address bc:54:2f:cb:3b:21
> 
> 



Re: ix(4)/riscv64: Make ix(4) work when MSI-X interrupts aren't available

2021-07-24 Thread Jonathan Gray
On Thu, Jul 22, 2021 at 09:04:29PM -0400, Ashton Fagg wrote:
> Jonathan Matthew  writes:
> 
> > Yes, on second look that makes sense.  Here's a better diff with that
> > change, and that also doesn't break arches without __HAVE_PCI_MSIX.
> > ok?
> 
> Jonathan/Mark,
> 
> Thank you for your help here.
> 
> Just confirming that does indeed work for me.
> 
> Any chance the other part of my diff could go in as well?

thanks, committed with the same change in RAMDISK

> 
> Thanks,
> 
> Ash
> 
> Index: sys/arch/riscv64/conf/GENERIC
> ===
> RCS file: /cvs/src/sys/arch/riscv64/conf/GENERIC,v
> retrieving revision 1.26
> diff -u -p -u -p -r1.26 GENERIC
> --- sys/arch/riscv64/conf/GENERIC 12 Jul 2021 19:11:42 -  1.26
> +++ sys/arch/riscv64/conf/GENERIC 19 Jul 2021 22:53:38 -
> @@ -94,6 +94,7 @@ wsdisplay*  at radeondrm?
>  em*  at pci? # Intel Pro/1000 Ethernet
>  bge* at pci? # Broadcom BCM57xx (aka Tigon3)
>  oce* at pci? # Emulex OneConnect 10Gb ethernet
> +ix*  at pci? # Intel 82598EB 10Gb ethernet
>  
>  nvme*at pci? # NVMe controllers
>  ahci*at pci? # AHCI SATA controllers
> 
> 



Re: sleep.3: miscellaneous cleanup and rewrites

2021-07-24 Thread Jonathan Gray
On Sat, Jul 24, 2021 at 10:39:49PM -0500, Scott Cheloha wrote:
> Okay, the nanosleep.2 changes are committed, let's do sleep.3 next.
> 
> Here's a changelist by section.  I have some questions in there at end
> of sections where I'm unsure about something.
> 
> NAME
> 
> - This is clunky.  Tighten it up.
> 
> - It's also wrong.  Remove reference to the process: sleep suspends
>   the calling thread.
> 
> DESCRIPTION
> 
> - Again, it suspends the thread, not the process.
> 
> - If we borrow language/style from nanosleep.2 we can condense this
>   first paragraph into a single sentence.
> 
> - In the second paragraph I don't think we need to talk about SIGALRM
>   explicitly.  It isn't relevant to our implementation.
> 
>   I think such comments belong in the Standards section.  See below.
> 
> - Probably worth mentioning the sole implication of an implementation
>   based on nanosleep(2) here instead of telling the reader to schlep
>   off to that page to get the details there.
> 
> I'm not positive about cutting the discussion of timers and SIGALARM
> here.  My thinking is: here in 2021, the fact that our sleep() doesn't
> touch the process timer or the signal mask doesn't seem significant
> enough to warrant inclusion.  I wonder if this detail confuses some
> readers ("why are they bringing this up?").
> 
> RETURN VALUES
> 
> - Tighten this up.
> 
> - Prefer a literal "0" for an integral return value.
> 
> Should we mention that sleep(3) can set errno?
> 
> If so, do we need to mention how to check whether it was interrupted
> by a signal?  It's similar to other libc syscall wrappers:
> 
>   errno = 0;
>   sleep(...);
>   if (errno != 0)
>   warn("sleep");
> 
> No, you can't just check if the return value is greater than 0.  If we
> get a signal but the scheduler doesn't choose to run us until after
> the timeout has elapsed we'll get 0 back but errno will be set.  No
> way to avoid this race.
> 
> ERRORS
> 
> Is this section missing?  Maybe just a nod to nanosleep(2), like:
> 
>   The sleep() function may fail for any of the reasons
>   given in nanosleep(2).
> 
> Something else?
> 
> SEE ALSO
> 
> - Add sigaction(2).  We mention SA_RESTART and signals in the
>   Description.
> 
> STANDARDS
> 
> - Bump the relevant standard to POSIX.1-2001.  That version
>   incorporates details about threads, which our version respects.
> 
>   For sake of completeness, I will note that SUSv2 mentions threads
>   too:
> 
>   https://pubs.opengroup.org/onlinepubs/7908799/xsh/sleep.html
> 
>   SUSv2 is older than POSIX.1-2001.  Do we prefer the earlier
>   standard?
> 
> - Mention the two possible implementations.  Mention that they
>   are not the same and might behave differently.  Offer a
>   solution for portable applications.
> 
> For the portability paragraph I'm just spitballing.  No idea what the
> right language is here or what recommendations are appropriate.
> 
> In general, the nanosleep() spec is simple and the sleep() spec is
> complex due to some historical mishaps.  From a spec perspective,
> nanosleep(2) is the safer bet because you know what you're getting,
> warts and all.
> 
> However:
> 
> I honestly haven't looked very deeply into the specific behavioral
> differences between the two approaches, I'm just taking POSIX at their
> word.  We have an old-school implementation in CVS:
> 
> http://cvsweb.openbsd.org/src/lib/libc/gen/sleep.c?rev=1.6=text/x-cvsweb-markup
> 
> ... at a glance I can imagine how it might behave differently from the
> current approach:
> 
> http://cvsweb.openbsd.org/src/lib/libc/gen/sleep.c?rev=1.13=text/x-cvsweb-markup
> 
> I also don't know where you would find an alarm(3)-based approach
> anymore.  I caveat my recommendation with the "although the
> alarm(3)-based approach is increasingly rare" bit to acknowledge this,
> though still I feel like we ought to say something, just in case.
> 
> HISTORY
> 
> - I cannot find a sleep() system call in Research UNIX v2.
> 
>   I can find it in v3:
> 
>   
> https://github.com/dspinellis/unix-history-repo/blob/Research-V3/man/man2/sleep.2
> 
>   So, change ".At v2" to ".At v3".
> 
> I must admit I have a hard time tracking the changes in the Research
> UNIX code.  Shit moves around *constantly*.  So sleep() might indeed
> be in v2 and I'm just not seeing it.

See the "Combined Tables of Contents" in Doug McIlroy's
"A Research UNIX Reader".

2. System calls

Edition   Title  Purpose
1 2 3 4 5 6 7 8 9
. + + + + + . . . sleep  delay execution [alarm]

And indeed it is documented in

https://www.tuhs.org/Archive/Distributions/Research/Dennis_v2/v2man.pdf

> 
> --
> 
> Index: sleep.3
> ===
> RCS file: /cvs/src/lib/libc/gen/sleep.3,v
> retrieving revision 1.16
> diff -u -p -r1.16 sleep.3
> --- sleep.3   8 Feb 2020 01:09:57 -   1.16
> +++ sleep.3   25 Jul 2021 03:27:27 -
> @@ -32,7 +32,7 @@
>  .Os
>  .Sh NAME
>  .Nm sleep
> -.Nd 

update xf86-video-amdgpu to latest git

2021-07-08 Thread Jonathan Gray
The latest xf86-video-amdgpu release was in 2019.

xf86-video-amdgpu-19.1.0..origin/master

minus commits we already have
cb27a5b Handle NULL fb_ptr in pixmap_get_fb
e2cd67a Bail from amdgpu_pixmap_get_handle with ShadowFB
edcbe5f Fix link failure with gcc 10

With a X_PRIVSEP path added to amdgpu_probe.c to handle the change from
drmOpen() to open().

aedbf47 Include xf86drm.h instead of sarea.h
6ed4863 Drop dri.h includes
6234a1b Fix drmmode_crtc_scanout_create logic
6bd3dc6 Check for AMDGPU_CREATE_PIXMAP_SCANOUT in amdgpu_glamor_create_pixmap
2202cdf Replace a few more instances of "master"
0d1d479 Fix build against ABI_VIDEODRV_VERSION 25.2
442efe7 Make drmmode_crtc_scanout_create/destroy static
99f3c82 Drop struct drmmode_scanout altogether in favour of PixmapPtrs
cfce4b3 Drop bo/width/height members from struct drmmode_scanout
680b9a2 Fix return value check of drmIoctl()
e923642 gitlab CI: update to use the latest CI templates
0732f81 glamor: Make pixmap scanout compatible if its dimensions are
42a3148 Factor out common code to amdgpu_probe()
eeaaf37 Introduce amdgpu_device_setup helper
1c9742e Kill off drmOpen/Close/drmSetInterfaceVersion in favour of drmDevices
2dd7307 Use the device_id straight from gpu_info
655b3c5 Reuse the existing busid string
b357a84 Store the busid string in AMDGPUEnt
2c0c154 Remove NULL check after a "cannot fail" function
16ae0d0 Fixup the amdgpu_bus_id() string format
abbe23f Remove drmCheckModesettingSupported and kernel module loading, on Linux
0b3bc7a Use ODEV_ATTRIB_PATH where possible for the device node.
fd66f5c kms: Handle changes to SourceValidate call chain in xserver 19

Index: driver/xf86-video-amdgpu/Makefile.in
===
RCS file: /cvs/xenocara/driver/xf86-video-amdgpu/Makefile.in,v
retrieving revision 1.2
diff -u -p -r1.2 Makefile.in
--- driver/xf86-video-amdgpu/Makefile.in16 Apr 2019 01:59:34 -  
1.2
+++ driver/xf86-video-amdgpu/Makefile.in8 Jul 2021 07:13:57 -
@@ -314,6 +314,7 @@ pdfdir = @pdfdir@
 prefix = @prefix@
 program_transform_name = @program_transform_name@
 psdir = @psdir@
+runstatedir = @runstatedir@
 sbindir = @sbindir@
 sharedstatedir = @sharedstatedir@
 srcdir = @srcdir@
Index: driver/xf86-video-amdgpu/README.md
===
RCS file: /cvs/xenocara/driver/xf86-video-amdgpu/README.md,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 README.md
--- driver/xf86-video-amdgpu/README.md  16 Apr 2019 01:49:01 -  1.1.1.1
+++ driver/xf86-video-amdgpu/README.md  7 Jul 2021 13:42:19 -
@@ -9,7 +9,7 @@ Please
 to the Xorg bugzilla.
 
 The
-[master development code 
repository](https://gitlab.freedesktop.org/xorg/driver/xf86-video-amdgpu)
+[main development code 
repository](https://gitlab.freedesktop.org/xorg/driver/xf86-video-amdgpu)
 can be found at FreeDesktop Gitlab.
 
 Please use merge requests for patch submission.
Index: driver/xf86-video-amdgpu/aclocal.m4
===
RCS file: /cvs/xenocara/driver/xf86-video-amdgpu/aclocal.m4,v
retrieving revision 1.2
diff -u -p -r1.2 aclocal.m4
--- driver/xf86-video-amdgpu/aclocal.m4 16 Apr 2019 01:59:34 -  1.2
+++ driver/xf86-video-amdgpu/aclocal.m4 8 Jul 2021 07:13:54 -
@@ -19,9 +19,9 @@ You have another version of autoconf.  I
 If you have problems, you may need to regenerate the build system entirely.
 To do so, use the procedure documented by the package, typically 
'autoreconf'.])])
 
-dnl pkg.m4 - Macros to locate and utilise pkg-config.   -*- Autoconf -*-
-dnl serial 11 (pkg-config-0.29.1)
-dnl
+# pkg.m4 - Macros to locate and utilise pkg-config.   -*- Autoconf -*-
+# serial 12 (pkg-config-0.29.2)
+
 dnl Copyright © 2004 Scott James Remnant .
 dnl Copyright © 2012-2015 Dan Nicholson 
 dnl
@@ -62,7 +62,7 @@ dnl
 dnl See the "Since" comment for each macro you use to see what version
 dnl of the macros you require.
 m4_defun([PKG_PREREQ],
-[m4_define([PKG_MACROS_VERSION], [0.29.1])
+[m4_define([PKG_MACROS_VERSION], [0.29.2])
 m4_if(m4_version_compare(PKG_MACROS_VERSION, [$1]), -1,
 [m4_fatal([pkg.m4 version $1 or higher is required but 
]PKG_MACROS_VERSION[ found])])
 ])dnl PKG_PREREQ
@@ -163,7 +163,7 @@ AC_ARG_VAR([$1][_CFLAGS], [C compiler fl
 AC_ARG_VAR([$1][_LIBS], [linker flags for $1, overriding pkg-config])dnl
 
 pkg_failed=no
-AC_MSG_CHECKING([for $1])
+AC_MSG_CHECKING([for $2])
 
 _PKG_CONFIG([$1][_CFLAGS], [cflags], [$2])
 _PKG_CONFIG([$1][_LIBS], [libs], [$2])
@@ -173,11 +173,11 @@ and $1[]_LIBS to avoid the need to call 
 See the pkg-config man page for more details.])
 
 if test $pkg_failed = yes; then
-   AC_MSG_RESULT([no])
+AC_MSG_RESULT([no])
 _PKG_SHORT_ERRORS_SUPPORTED
 if test $_pkg_short_errors_supported = yes; then
$1[]_PKG_ERRORS=`$PKG_CONFIG --short-errors --print-errors 
--cflags --libs "$2" 2>&1`
-else 
+  

Re: arm9 support?

2021-06-30 Thread Jonathan Gray
On Tue, Jun 29, 2021 at 10:38:33PM -0700, pion wrote:
> I’m interested in porting OpenBSD to the Nuvoton NUC980, which uses an 
> ARM926EJ-S core. I discovered that arm9 support was removed in 2016 and found 
> the relevant patches in tech@. It seems that the rationale was that arm8/9 
> platforms were not being used with OpenBSD and were therefore a source of 
> dead code.
> 
> I am strongly motivated to help bring back enough arm9 support to get the 
> NUC980 chip going and deploy it onto the Nuvoton Chili eval board. This is an 
> extremely compact 100Mbit Ethernet-capable board running at 300 MHz and is 
> perfect for IoT devices and compact servers. It would be very helpful to have 
> guidance from more experienced developers here. Is anyone interested in 
> working with me to bring back support? I am happy to ship hardware to anyone 
> who is interested.
> 
> Thanks,
> 
> -p
> 

We switched to eabi, require vfp floating point, armv7 atomics/barriers,
switched to clang and have a different pmap.

armv4 would be a different arch/toolchain you'd have to build/maintain
yourself out of tree at this point.



Re: Adjust url of SD Association in comment in sdhc.c

2021-06-13 Thread Jonathan Gray
On Sun, Jun 13, 2021 at 05:41:32AM +0200, Felix Kronlage-Dammers wrote:
> hi,
> 
> the legit URL of the SD Associations is www.sdcard.org, not
> www.sdcard.com.
> 
> felix
> 

thanks, committed

> 
> 
> Index: sys/dev/sdmmc/sdhc.c
> ===
> RCS file: /cvs/src/sys/dev/sdmmc/sdhc.c,v
> retrieving revision 1.69
> diff -u -p -u -r1.69 sdhc.c
> --- sys/dev/sdmmc/sdhc.c  14 Aug 2020 14:49:04 -  1.69
> +++ sys/dev/sdmmc/sdhc.c  13 Jun 2021 03:36:39 -
> @@ -18,7 +18,7 @@
>  
>  /*
>   * SD Host Controller driver based on the SD Host Controller Standard
> - * Simplified Specification Version 1.00 (www.sdcard.com).
> + * Simplified Specification Version 1.00 (www.sdcard.org).
>   */
>  
>  #include 
> 
> -- 
> GPG/PGP:   7A0B612C /  5F4D 9B06 C240 3250 35BF  66ED 1AD3 A9B8 7A0B 612C
> https://hazardous.org/  -  f...@hazardous.org  -  fkr@irc - @felixkronlage
> 
> 



Re: pcidevs + azalia: patch for new intel audio

2021-06-11 Thread Jonathan Gray
On Fri, Jun 11, 2021 at 10:03:07AM -0400, Ashton Fagg wrote:
> Friendly ping.
> 
> Ashton Fagg  writes:
> 
> > My new Intel Z590-based machine seems to have some different kind of
> > Intel audio device onboard.
> >
> > I couldn't find very much online about it (all the usual pci id
> > databases don't seem to have it yet). The only really useful thing I
> > found was this:
> >
> > https://github.com/torvalds/linux/commit/f84d3a1ec375e46a55cc3ba85c04272b24bd3921#diff-bfe681fff464a07274400d493ba696cc6e10649a993ae7c1cfc1c29a106feda0
> >
> > This doesn't give much info but seems to indicate that it's a variant of
> > some existing chip.

I can't find 0xf0c8 in the datasheets either.

I've committed this but moved the added line in pcidevs to maintain
ordering by device id.  Thanks for the patch.

> >
> > I gave this the not very descriptive name of
> > "PCI_PRODUCT_INTEL_500SERIES_HDA_2", since that's about all I could come
> > up with, since I'm assuming it's a variant of
> > "PCI_PRODUCT_INTEL_500SERIES_HDA".
> >
> > Patch which defines device in pcidevs and tells azalia how to
> > configure it is attached. Playback was the only thing I could readily
> > test and that's working - so my itch here has been scratched.
> >
> > I've also attached a dmesg output and a pcidump output (dmesg has also
> > been sent to dmesg@).
> >
> > Feedback greatly welcomed.
> >
> > Before:
> >
> > azalia0 at pci0 dev 31 function 3 vendor "Intel", unknown product 0xf0c8 
> > rev 0x11: msi
> > azalia0: codecs: Realtek/0x0897, 0x/0x, using Realtek/0x0897
> > audio0 at azalia0
> >
> > After:
> >
> > azalia0 at pci0 dev 31 function 3 "Intel 500 Series HD Audio" rev 0x11: msi
> > azalia0: codecs: Realtek/0x0897, 0x/0x, using Realtek/0x0897
> > audio0 at azalia0
> 

> Index: sys/dev/pci/azalia.c
> ===
> RCS file: /cvs/src/sys/dev/pci/azalia.c,v
> retrieving revision 1.262
> diff -u -p -u -p -r1.262 azalia.c
> --- sys/dev/pci/azalia.c  30 May 2021 02:54:36 -  1.262
> +++ sys/dev/pci/azalia.c  1 Jun 2021 01:20:42 -
> @@ -470,6 +470,7 @@ azalia_configure_pci(azalia_t *az)
>   case PCI_PRODUCT_INTEL_400SERIES_LP_HDA:
>   case PCI_PRODUCT_INTEL_495SERIES_LP_HDA:
>   case PCI_PRODUCT_INTEL_500SERIES_HDA:
> + case PCI_PRODUCT_INTEL_500SERIES_HDA_2:
>   case PCI_PRODUCT_INTEL_500SERIES_LP_HDA:
>   case PCI_PRODUCT_INTEL_C600_HDA:
>   case PCI_PRODUCT_INTEL_C610_HDA_1:
> Index: sys/dev/pci/pcidevs
> ===
> RCS file: /cvs/src/sys/dev/pci/pcidevs,v
> retrieving revision 1.1970
> diff -u -p -u -p -r1.1970 pcidevs
> --- sys/dev/pci/pcidevs   19 May 2021 05:20:48 -  1.1970
> +++ sys/dev/pci/pcidevs   1 Jun 2021 01:20:42 -
> @@ -5371,6 +5371,7 @@ product INTEL 500SERIES_PCIE_22 0x43c5  5
>  product INTEL 500SERIES_PCIE_23  0x43c6  500 Series PCIE
>  product INTEL 500SERIES_PCIE_24  0x43c7  500 Series PCIE
>  product INTEL 500SERIES_HDA  0x43c8  500 Series HD Audio
> +product INTEL 500SERIES_HDA_20xf0c8  500 Series HD Audio
>  product INTEL 500SERIES_THC_00x43d0  500 Series THC
>  product INTEL 500SERIES_THC_10x43d1  500 Series THC
>  product INTEL 500SERIES_AHCI_1   0x43d2  500 Series AHCI
> Index: sys/dev/pci/pcidevs.h
> ===
> RCS file: /cvs/src/sys/dev/pci/pcidevs.h,v
> retrieving revision 1.1964
> diff -u -p -u -p -r1.1964 pcidevs.h
> --- sys/dev/pci/pcidevs.h 19 May 2021 05:21:24 -  1.1964
> +++ sys/dev/pci/pcidevs.h 1 Jun 2021 01:20:42 -
> @@ -5376,6 +5376,7 @@
>  #define  PCI_PRODUCT_INTEL_500SERIES_PCIE_23 0x43c6  /* 500 
> Series PCIE */
>  #define  PCI_PRODUCT_INTEL_500SERIES_PCIE_24 0x43c7  /* 500 
> Series PCIE */
>  #define  PCI_PRODUCT_INTEL_500SERIES_HDA 0x43c8  /* 500 Series 
> HD Audio */
> +#define  PCI_PRODUCT_INTEL_500SERIES_HDA_2   0xf0c8  /* 500 
> Series HD Audio */
>  #define  PCI_PRODUCT_INTEL_500SERIES_THC_0   0x43d0  /* 500 
> Series THC */
>  #define  PCI_PRODUCT_INTEL_500SERIES_THC_1   0x43d1  /* 500 
> Series THC */
>  #define  PCI_PRODUCT_INTEL_500SERIES_AHCI_1  0x43d2  /* 500 
> Series AHCI */
> Index: sys/dev/pci/pcidevs_data.h
> ===
> RCS file: /cvs/src/sys/dev/pci/pcidevs_data.h,v
> retrieving revision 1.1959
> diff -u -p -u -p -r1.1959 pcidevs_data.h
> --- sys/dev/pci/pcidevs_data.h19 May 2021 05:21:24 -  1.1959
> +++ sys/dev/pci/pcidevs_data.h1 Jun 2021 01:20:43 -
> @@ -18912,6 +18912,10 @@ static const struct pci_known_product pc
>   "500 Series HD Audio",
>   },
>   {
> + PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_500SERIES_HDA_2,
> + "500 Series HD Audio",
> + 

Re: limit MSR_INT_PEN_MSG use to < family 16h

2021-06-10 Thread Jonathan Gray
On Wed, Jun 09, 2021 at 10:35:48PM -0700, Mike Larkin wrote:
> On Thu, Jun 10, 2021 at 03:19:43PM +1000, Jonathan Gray wrote:
> > Ilya Voronin sent a diff to misc to limit MSR_INT_PEN_MSG use to
> > < AMD family 17h prompted by a problem with an AWS t3a instance.
> >
> > https://marc.info/?l=openbsd-misc=162120066715633=2
> >
> > Digging some more the 16h bkdgs have it as RAZ/non-functional as well.
> > Bits are documented in 15h.
> >
> > BKDG for AMD Family 16h Models 00h-0Fh Processors
> > MSRC001_0055 Interrupt Pending
> > 63:0 RAZ.
> >
> > BKDG for AMD Family 16h Models 30h-3Fh Processors
> > MSRC001_0055 Interrupt Pending
> > 63:0 RAZ
> >
> > PPR for AMD Family 17h Model 71h B0
> > MSRC001_0055 [Reserved.] (Core::X86::Msr::IntPend)
> > Read-only. Reset: Fixed,___h.
> >
> > Change the test to use extended family id while here.
> >
> 
> I'd be ok with this if someone reported that it works on a bare metal EPYC,
> since the fix here is for a virtualized environment (and we don't know what
> AWS is doing here).

I don't have an epyc but this boots with a mp kernel on
cpu0: AMD Ryzen 5 2600X Six-Core Processor, 3593.93 MHz, 17-08-02

The c1e timer stop problem / erratum 400 should only be a problem
on families 0xf and 0x10.

Index: sys/arch/amd64/amd64/lapic.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/lapic.c,v
retrieving revision 1.57
diff -u -p -r1.57 lapic.c
--- sys/arch/amd64/amd64/lapic.c6 Sep 2020 20:50:00 -   1.57
+++ sys/arch/amd64/amd64/lapic.c10 Jun 2021 06:13:38 -
@@ -299,8 +299,7 @@ lapic_set_lvt(void)
 *Family 0Fh Processors"
 *   #32559 revision 3.00
 */
-   if ((cpu_id & 0x0f00) == 0x0f00 &&
-   (cpu_id & 0x0fff) >= 0x0004) {
+   if (ci->ci_family == 0xf || ci->ci_family == 0x10) {
uint64_t msr;
 
msr = rdmsr(MSR_INT_PEN_MSG);
Index: sys/arch/i386/i386/lapic.c
===
RCS file: /cvs/src/sys/arch/i386/i386/lapic.c,v
retrieving revision 1.47
diff -u -p -r1.47 lapic.c
--- sys/arch/i386/i386/lapic.c  30 Jul 2018 14:19:12 -  1.47
+++ sys/arch/i386/i386/lapic.c  10 Jun 2021 06:13:21 -
@@ -160,8 +160,7 @@ lapic_set_lvt(void)
 *Family 0Fh Processors"
 *   #32559 revision 3.00
 */
-   if ((cpu_id & 0x0f00) == 0x0f00 &&
-   (cpu_id & 0x0fff) >= 0x0004) {
+   if (ci->ci_family == 0xf || ci->ci_family == 0x10) {
uint64_t msr;
 
msr = rdmsr(MSR_INT_PEN_MSG);



limit MSR_INT_PEN_MSG use to < family 16h

2021-06-09 Thread Jonathan Gray
Ilya Voronin sent a diff to misc to limit MSR_INT_PEN_MSG use to
< AMD family 17h prompted by a problem with an AWS t3a instance.

https://marc.info/?l=openbsd-misc=162120066715633=2

Digging some more the 16h bkdgs have it as RAZ/non-functional as well.
Bits are documented in 15h.

BKDG for AMD Family 16h Models 00h-0Fh Processors
MSRC001_0055 Interrupt Pending
63:0 RAZ.

BKDG for AMD Family 16h Models 30h-3Fh Processors
MSRC001_0055 Interrupt Pending
63:0 RAZ

PPR for AMD Family 17h Model 71h B0
MSRC001_0055 [Reserved.] (Core::X86::Msr::IntPend)
Read-only. Reset: Fixed,___h.

Change the test to use extended family id while here.

Index: sys/arch/amd64/amd64/lapic.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/lapic.c,v
retrieving revision 1.57
diff -u -p -r1.57 lapic.c
--- sys/arch/amd64/amd64/lapic.c6 Sep 2020 20:50:00 -   1.57
+++ sys/arch/amd64/amd64/lapic.c19 May 2021 09:16:37 -
@@ -299,8 +299,7 @@ lapic_set_lvt(void)
 *Family 0Fh Processors"
 *   #32559 revision 3.00
 */
-   if ((cpu_id & 0x0f00) == 0x0f00 &&
-   (cpu_id & 0x0fff) >= 0x0004) {
+   if (ci->ci_family >= 0xf && ci->ci_family < 0x16) {
uint64_t msr;
 
msr = rdmsr(MSR_INT_PEN_MSG);
Index: sys/arch/i386/i386/lapic.c
===
RCS file: /cvs/src/sys/arch/i386/i386/lapic.c,v
retrieving revision 1.47
diff -u -p -r1.47 lapic.c
--- sys/arch/i386/i386/lapic.c  30 Jul 2018 14:19:12 -  1.47
+++ sys/arch/i386/i386/lapic.c  19 May 2021 09:19:41 -
@@ -160,8 +160,7 @@ lapic_set_lvt(void)
 *Family 0Fh Processors"
 *   #32559 revision 3.00
 */
-   if ((cpu_id & 0x0f00) == 0x0f00 &&
-   (cpu_id & 0x0fff) >= 0x0004) {
+   if (ci->ci_family >= 0xf && ci->ci_family < 0x16) {
uint64_t msr;
 
msr = rdmsr(MSR_INT_PEN_MSG);




Re: mkuboot.8: Add missing arm64 architecture

2021-05-31 Thread Jonathan Gray
On Tue, Jun 01, 2021 at 01:43:32AM +0200, Leon Fischer wrote:
> The mkuboot(8) man page was not updated after this commit:
> 
> RCS file: /cvs/src/usr.sbin/mkuboot/mkuboot.c,v
> 
> revision 1.7
> date: 2016/12/20 11:27:11;  author: jsg;  state: Exp;  lines: +3 -1;  
> commitid: fELL92HBrGHkYVvc;
> Add the u-boot arm64 architecture number and map it to "aarch64" to
> match OpenBSD/arm64 MACHINE_ARCH.
> 
> ok patrick@
> 
> 
> Here's a patch to add it to the supported architectures list.

thanks, committed

> 
> This man page is still missing a few things: what is "infile", what do
> the types mean, an example for installing the image, etc.

Before there were armv7/arm64 efi bootloaders kernels used to require
having a U-Boot header and had to reside on a fat/ext filesystem.
With boot scripts created by something like
'mkuboot -t script -a arm -o linux boot.cmd boot.scr' with boot.scr
also placed on the fat/ext filesystem.  boot.cmd being a text file with
U-Boot commands.

Now U-Boot supports uefi and generic distro boot there isn't a need to
use mkuboot for the most part.

> 
> Index: mkuboot.8
> ===
> RCS file: /cvs/src/usr.sbin/mkuboot/mkuboot.8,v
> retrieving revision 1.1
> diff -u -p -r1.1 mkuboot.8
> --- mkuboot.8 30 May 2013 19:17:15 -  1.1
> +++ mkuboot.8 31 May 2021 23:30:54 -
> @@ -65,6 +65,7 @@ The following arguments are valid as the
>  .Ar arch
>  parameter:
>  .Bd -unfilled -offset indent -compact
> +aarch64
>  alpha
>  amd64
>  arm
> 
> 



Re: Fix and includes on powerpc*

2021-05-29 Thread Jonathan Gray
On Sun, May 30, 2021 at 05:03:47AM +, Visa Hankala wrote:
> powerpc and powerpc64's  include  too late
> and accidentally rely on other code to pull in the header. If the mutex
> header is removed from the , the build fails:
> 
> In file included from src/sys/dev/rnd.c:84:
> In file included from src/sys/uvm/uvm_extern.h:180:
> In file included from src/sys/uvm/uvm_pmap.h:86:
> src/sys/arch/powerpc64/compile/GENERIC/obj/machine/pmap.h:38:16: error: field 
> has incomplete type 'struct mutex'
> struct mutexpm_mtx;
> ^
> 
> The following diff fixes the above. Also, it adds  in
> powerpc's pmap.h for consistency with powerpc64 (struct vm_page_md uses
> LIST_HEAD() after all). powerpc64's  appears to have
> a hidden dependency on .
> 
> OK?

ok jsg@

> 
> Index: arch/powerpc/include/pmap.h
> ===
> RCS file: src/sys/arch/powerpc/include/pmap.h,v
> retrieving revision 1.59
> diff -u -p -r1.59 pmap.h
> --- arch/powerpc/include/pmap.h   8 Oct 2015 10:20:14 -   1.59
> +++ arch/powerpc/include/pmap.h   30 May 2021 04:28:46 -
> @@ -77,6 +77,9 @@ typedef u_int sr_t;
>  #define PMAP_CACHE_WT2   /* writethru */
>  #define PMAP_CACHE_WB3   /* writeback */
>  
> +#include 
> +#include 
> +
>  #ifdef   _KERNEL
>  
>  /*
> @@ -164,8 +167,6 @@ int reserve_dumppages(caddr_t p);
>  
>  #endif   /* _KERNEL */
>  
> -#include 
> -
>  struct vm_page_md {
>   struct mutex pv_mtx;
>   LIST_HEAD(,pte_desc) pv_list;
> Index: arch/powerpc64/include/intr.h
> ===
> RCS file: src/sys/arch/powerpc64/include/intr.h,v
> retrieving revision 1.13
> diff -u -p -r1.13 intr.h
> --- arch/powerpc64/include/intr.h 24 Oct 2020 21:42:10 -  1.13
> +++ arch/powerpc64/include/intr.h 30 May 2021 04:28:46 -
> @@ -19,6 +19,8 @@
>  #ifndef _MACHINE_INTR_H_
>  #define _MACHINE_INTR_H_
>  
> +#include 
> +
>  struct cpu_info;
>  struct trapframe;
>  
> Index: arch/powerpc64/include/pmap.h
> ===
> RCS file: src/sys/arch/powerpc64/include/pmap.h,v
> retrieving revision 1.16
> diff -u -p -r1.16 pmap.h
> --- arch/powerpc64/include/pmap.h 11 May 2021 18:21:12 -  1.16
> +++ arch/powerpc64/include/pmap.h 30 May 2021 04:28:46 -
> @@ -19,6 +19,9 @@
>  #ifndef _MACHINE_PMAP_H_
>  #define _MACHINE_PMAP_H_
>  
> +#include 
> +#include 
> +
>  #ifdef _KERNEL
>  
>  #include 
> @@ -80,9 +83,6 @@ struct pte *pmap_get_kernel_pte(vaddr_t)
>  
>  #endif   /* _KERNEL */
>  
> -#include 
> -#include 
> -
>  struct vm_page_md {
>   struct mutex pv_mtx;
>   LIST_HEAD(,pte_desc) pv_list;
> 
> 



Re: Add missing includes

2021-05-29 Thread Jonathan Gray
On Sun, May 30, 2021 at 05:01:05AM +, Visa Hankala wrote:
> The kernel has places where mutexes are used but  is not
> included directly. Some of them get exposed when #include 
> is removed from soft interrupt headers. The following diff fixes them.
> 
> OK?

ok jsg@

> 
> Index: arch/amd64/amd64/db_interface.c
> ===
> RCS file: src/sys/arch/amd64/amd64/db_interface.c,v
> retrieving revision 1.35
> diff -u -p -r1.35 db_interface.c
> --- arch/amd64/amd64/db_interface.c   6 Nov 2019 07:34:35 -   1.35
> +++ arch/amd64/amd64/db_interface.c   30 May 2021 04:28:45 -
> @@ -36,6 +36,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  
> Index: arch/arm64/arm64/db_interface.c
> ===
> RCS file: src/sys/arch/arm64/arm64/db_interface.c,v
> retrieving revision 1.9
> diff -u -p -r1.9 db_interface.c
> --- arch/arm64/arm64/db_interface.c   11 Mar 2021 11:16:55 -  1.9
> +++ arch/arm64/arm64/db_interface.c   30 May 2021 04:28:45 -
> @@ -39,6 +39,7 @@
>  #include 
>  #include/* just for boothowto */
>  #include 
> +#include 
>  
>  #include 
>  
> Index: arch/arm64/dev/apldart.c
> ===
> RCS file: src/sys/arch/arm64/dev/apldart.c,v
> retrieving revision 1.3
> diff -u -p -r1.3 apldart.c
> --- arch/arm64/dev/apldart.c  24 May 2021 18:38:29 -  1.3
> +++ arch/arm64/dev/apldart.c  30 May 2021 04:28:45 -
> @@ -20,6 +20,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> Index: arch/mips64/mips64/db_machdep.c
> ===
> RCS file: src/sys/arch/mips64/mips64/db_machdep.c,v
> retrieving revision 1.56
> diff -u -p -r1.56 db_machdep.c
> --- arch/mips64/mips64/db_machdep.c   1 May 2021 16:11:11 -   1.56
> +++ arch/mips64/mips64/db_machdep.c   30 May 2021 04:28:46 -
> @@ -28,6 +28,7 @@
>  
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> Index: arch/powerpc/ddb/db_interface.c
> ===
> RCS file: src/sys/arch/powerpc/ddb/db_interface.c,v
> retrieving revision 1.6
> diff -u -p -r1.6 db_interface.c
> --- arch/powerpc/ddb/db_interface.c   7 Nov 2019 15:58:39 -   1.6
> +++ arch/powerpc/ddb/db_interface.c   30 May 2021 04:28:46 -
> @@ -32,6 +32,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  
> Index: arch/powerpc64/powerpc64/db_interface.c
> ===
> RCS file: src/sys/arch/powerpc64/powerpc64/db_interface.c,v
> retrieving revision 1.3
> diff -u -p -r1.3 db_interface.c
> --- arch/powerpc64/powerpc64/db_interface.c   22 Jul 2020 20:41:26 -  
> 1.3
> +++ arch/powerpc64/powerpc64/db_interface.c   30 May 2021 04:28:46 -
> @@ -31,6 +31,7 @@
>  
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> Index: arch/sparc64/sparc64/db_interface.c
> ===
> RCS file: src/sys/arch/sparc64/sparc64/db_interface.c,v
> retrieving revision 1.55
> diff -u -p -r1.55 db_interface.c
> --- arch/sparc64/sparc64/db_interface.c   30 Jan 2020 08:51:27 -  
> 1.55
> +++ arch/sparc64/sparc64/db_interface.c   30 May 2021 04:28:46 -
> @@ -35,6 +35,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  
> Index: dev/fdt/bcm2835_mbox.c
> ===
> RCS file: src/sys/dev/fdt/bcm2835_mbox.c,v
> retrieving revision 1.1
> diff -u -p -r1.1 bcm2835_mbox.c
> --- dev/fdt/bcm2835_mbox.c19 Apr 2020 14:51:52 -  1.1
> +++ dev/fdt/bcm2835_mbox.c30 May 2021 04:28:46 -
> @@ -48,6 +48,7 @@
>  
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> Index: dev/ic/ahcivar.h
> ===
> RCS file: src/sys/dev/ic/ahcivar.h,v
> retrieving revision 1.10
> diff -u -p -r1.10 ahcivar.h
> --- dev/ic/ahcivar.h  21 Aug 2017 21:43:46 -  1.10
> +++ dev/ic/ahcivar.h  30 May 2021 04:28:46 -
> @@ -18,6 +18,7 @@
>   * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
>   */
>  
> +#include 
>  #include 
>  #include 
>  #include 
> 
> 



Re: [PATCH] [src] sys/dev/usb/usbdevs - add "SHARKOON Technologies GmbH" vendor ID

2021-05-24 Thread Jonathan Gray
On Mon, May 24, 2021 at 03:52:44PM +0100, Raf Czlonka wrote:
> Hello,
> 
> Pretty self-explanatory - add "SHARKOON Technologies GmbH" vendor ID.

0x1ea7 / 7847 is 'SEMITEK INTERNATIONAL (HK) HOLDING LTD.' in
https://usb.org/sites/default/files/vendor_ids033021.pdf

> 
> Regards,
> 
> Raf
> 
> Index: sys/dev/usb/usbdevs
> ===
> RCS file: /cvs/src/sys/dev/usb/usbdevs,v
> retrieving revision 1.740
> diff -u -p -r1.740 usbdevs
> --- sys/dev/usb/usbdevs   18 May 2021 14:23:03 -  1.740
> +++ sys/dev/usb/usbdevs   24 May 2021 14:37:14 -
> @@ -618,6 +618,7 @@ vendor SELUXIT0x1d6f  Seluxit
>  vendor METAGEEK  0x1dd5  MetaGeek
>  vendor SIMCOM0x1e0e  SIMCom Wireless Solutions Co., Ltd.
>  vendor FESTO 0x1e29  Festo
> +vendor SHARKOON  0x1ea7  SHARKOON Technologies GmbH
>  vendor MODACOM   0x1eb8  Modacom
>  vendor AIRTIES   0x1eda  AirTies
>  vendor LAKESHORE 0x1fb9  Lake Shore
> 
> 



Re: [Patch] Add support for Realtek RTL8111FP-CG Ethernet Controller

2021-05-06 Thread Jonathan Gray
On Thu, May 06, 2021 at 12:38:17PM -0400, Stephen Taylor wrote:
> This is my first post to the mailing list and my first time customizing 
> the kernel. I apologize in advance for mistakes I make.
> 
> I have a Lenovo ThinkCenter M75n Nano IoT computer. It uses the Realtek 
> RTL8111FP-CG Ethernet controller, as do other similar small form factor 
> computers. OpenBSD 6.9 does not recognize the controller. dmesg shows:
> 
> re0 at pci2 dev 0 function 1 "Realtek 8168" rev 0x1a: unknown ASIC 
> (0x5480), msi, address 00:00:00:00
> 
> Studying similar posts in the mailing lists, I made the changes shown
> in the diffs below, compiled the kernel, and now OpenBSD recognizes 
> and can use the Ethernet.
> 
> Would someone be willing to review and/or commit this? Thank you!

Thanks, committed.  This id is also used by RTL8117.

> 
>  
> Index: re.c
> ===
> RCS file: /cvs/src/sys/dev/ic/re.c,v
> retrieving revision 1.208
> diff -u -p -u -r1.208 re.c
> --- re.c  12 Dec 2020 11:48:52 -  1.208
> +++ re.c  6 May 2021 16:13:43 -
> @@ -248,6 +248,7 @@ static const struct re_revision {
>   { RL_HWREV_8168E,   "RTL8168E/8111E" },
>   { RL_HWREV_8168E_VL,"RTL8168E/8111E-VL" },
>   { RL_HWREV_8168EP,  "RTL8168EP/8111EP" },
> + { RL_HWREV_8168FP,  "RTL8168FP/8111FP" },
>   { RL_HWREV_8169,"RTL8169" },
>   { RL_HWREV_8169_8110SB, "RTL8169/8110SB" },
>   { RL_HWREV_8169_8110SBL, "RTL8169SBL" },
> @@ -754,6 +755,7 @@ re_attach(struct rl_softc *sc, const cha
>   sc->rl_max_mtu = RL_JUMBO_MTU_9K;
>   break;
>   case RL_HWREV_8168EP:
> + case RL_HWREV_8168FP:
>   case RL_HWREV_8168G:
>   case RL_HWREV_8168GU:
>   case RL_HWREV_8168H:
> Index: rtl81x9reg.h
> ===
> RCS file: /cvs/src/sys/dev/ic/rtl81x9reg.h,v
> retrieving revision 1.101
> diff -u -p -u -r1.101 rtl81x9reg.h
> --- rtl81x9reg.h  11 Apr 2018 08:02:18 -  1.101
> +++ rtl81x9reg.h  6 May 2021 16:13:43 -
> @@ -210,6 +210,7 @@
>  #define RL_HWREV_8168EP  0x5000
>  #define RL_HWREV_8168GU  0x5080
>  #define RL_HWREV_8168H   0x5400
> +#define RL_HWREV_8168FP  0x5480
>  #define RL_HWREV_8411B   0x5c80  
>  #define RL_HWREV_81390x6000
>  #define RL_HWREV_8139A   0x7000
> 
> 



Re: enable dt(4)

2021-04-26 Thread Jonathan Gray
On Mon, Apr 26, 2021 at 03:01:58PM +0200, Alexander Bluhm wrote:
> On Mon, Apr 26, 2021 at 12:35:11PM +0200, Patrick Wildt wrote:
> > I can't vouch that it builds for all architectures... Did anyone do
> > that?  Number 1 rule: don't break Theo's build.
> 
> Compiled, booted, set kern.allowdt=1, created kstack on i386, amd64,
> arm64, powerpc64.
> 
> does not link on armv7
> 
> ld -T ld.script --warn-common -nopie -o bsd ${SYSTEM_HEAD} vers.o ${OBJS}
> ld: error: undefined symbol: stacktrace_save_at
> >>> referenced by dt_dev.c:0 (/usr/src/sys/dev/dt/dt_dev.c:0)
> >>>   dt_dev.o:(dt_pcb_ring_get)
> *** Error 1 in /usr/src/sys/arch/armv7/compile/GENERIC (Makefile:628 'bsd': 
> @echo ld -T ld.script --warn-common -nopie -o bsd '${SYSTEM_HEAD...)

also missing on alpha, landisk, luna88k, riscv64

> 
> > diff --git a/sys/conf/GENERIC b/sys/conf/GENERIC
> > index 33d0f368968..c47bea90cde 100644
> > --- a/sys/conf/GENERIC
> > +++ b/sys/conf/GENERIC
> > @@ -82,7 +82,7 @@ pseudo-device msts1   # MSTS line discipline
> >  pseudo-device  endrun  1   # EndRun line discipline
> >  pseudo-device  vnd 4   # vnode disk devices
> >  pseudo-device  ksyms   1   # kernel symbols device
> > -#pseudo-device dt  # Dynamic Tracer
> > +pseudo-device  dt  # Dynamic Tracer
> >  
> >  # clonable devices
> >  pseudo-device  bpfilter# packet filter
> 
> 



Re: [Patch] Fix mangled sentence in 69.html (apmd control socket)

2021-04-19 Thread Jonathan Gray
On Sun, Apr 18, 2021 at 09:09:24PM +1000, Ross L Richardson wrote:
> Simplest fix below.
> 
> Ross
> 

thanks, committed this with a few more changes

Index: 69.html
===
RCS file: /cvs/www/69.html,v
retrieving revision 1.58
diff -u -p -r1.58 69.html
--- 69.html 19 Apr 2021 06:45:41 -  1.58
+++ 69.html 19 Apr 2021 06:52:22 -
@@ -447,10 +447,10 @@ to 6.9.
Removed the 30s minimum delay for https://man.openbsd.org/xlock.1;>xlock(1) timeouts.
Stopped deleting the control socket on exit in https://man.openbsd.org/apmd.8;>apmd(8) exit, as 
deleting
-   the socket in process after calling https://man.openbsd.org/unveil.2;>unveil(2) would 
cause a
-   unveil restriction violation,
+   href="https://man.openbsd.org/apmd.8;>apmd(8), as deleting
+   the socket after calling https://man.openbsd.org/unveil.2;>unveil(2) would 
cause an
+   unveil violation.
   
 
 Improved hardware support and driver bugfixes, including:

> 
> Index: 69.html
> ===
> RCS file: /cvs/www/69.html,v
> retrieving revision 1.52
> diff -u -p -r1.52 69.html
> --- 69.html   17 Apr 2021 20:45:22 -  1.52
> +++ 69.html   18 Apr 2021 11:05:33 -
> @@ -450,9 +450,9 @@ to 6.9.
>   Removed the 30s minimum delay forhref="https://man.openbsd.org/xlock.1;>xlock(1) timeouts.
>   Stopped deleting the control socket on exit in  - href="https://man.openbsd.org/apmd.8;>apmd(8) exit, as 
> deleting
> + href="https://man.openbsd.org/apmd.8;>apmd(8), as deleting
>   the socket in process after calling  - href="https://man.openbsd.org/unveil.2;>unveil(2) would 
> cause a
> + href="https://man.openbsd.org/unveil.2;>unveil(2) would 
> cause an
>   unveil restriction violation,
>
>  
> 
> 



Re: [Patch] "usb" ==> "USB" for consistency

2021-04-19 Thread Jonathan Gray
On Sun, Apr 18, 2021 at 09:21:45PM +1000, Ross L Richardson wrote:
> Probably!
> 
> Ross
> 
> 

thanks, committed

> 
> Index: 69.html
> ===
> RCS file: /cvs/www/69.html,v
> retrieving revision 1.52
> diff -u -p -r1.52 69.html
> --- 69.html   17 Apr 2021 20:45:22 -  1.52
> +++ 69.html   18 Apr 2021 11:19:14 -
> @@ -424,7 +424,7 @@ to 6.9.
>   defaulting offset to the beginning of the largest free space and
>   preventing the creation of overlapping partitions.
>   Fixed a crash that could occur in  - href="https://man.openbsd.org/sndiod.8;>sndiod(8) when a usb
> + href="https://man.openbsd.org/sndiod.8;>sndiod(8) when a USB
>   device is unplugged.
>   Append .html suffixes to temporary files inhref="https://man.openbsd.org/mandoc.1;>mandoc(1) to allow
> 
> 



Re: [Patch] Typo ("it's" should be "its") in 69.html

2021-04-19 Thread Jonathan Gray
On Mon, Apr 19, 2021 at 02:30:13PM +1000, Ross L Richardson wrote:
> Just an incorrect possessive form...
> 
> Ross
> 

thanks, committed

> 
> Index: 69.html
> ===
> RCS file: /cvs/www/69.html,v
> retrieving revision 1.53
> diff -u -p -r1.53 69.html
> --- 69.html   18 Apr 2021 12:08:06 -  1.53
> +++ 69.html   19 Apr 2021 04:25:56 -
> @@ -757,7 +757,7 @@ to 6.9.
>   href="https://man.openbsd.org/ospfd.8;>ospfd(8) for interfaces
>   that share the same IP.
>  
> -The https://man.openbsd.org/pf.4;>pf(4) packet filter 
> and it's userland utility:
> +The https://man.openbsd.org/pf.4;>pf(4) packet filter 
> and its userland utility:
>  
>   Relaxed checks inhref="https://man.openbsd.org/pfctl.8;>pfctl(8) and  
> 



Re: [Patch] Relocate a vmctl entry in 69.html

2021-04-19 Thread Jonathan Gray
On Mon, Apr 19, 2021 at 03:08:13PM +1000, Ross L Richardson wrote:
> It probably belongs with the other vmctl entry rather than under
> userland networking changes...
> 
> Ross
> 

thanks, committed

> 
> Index: 69.html
> ===
> RCS file: /cvs/www/69.html,v
> retrieving revision 1.53
> diff -u -p -r1.53 69.html
> --- 69.html   18 Apr 2021 12:08:06 -  1.53
> +++ 69.html   19 Apr 2021 05:06:03 -
> @@ -307,6 +307,11 @@ to 6.9.
>   Made https://man.openbsd.org/vmctl.8;>vmctl(8)
>   properly indicate VMs are stopping instead of "running" with 
> "vmctl
>   status".
> + Simplify argument parsing of
> + https://man.openbsd.org/vmctl.8;>vmctl(8) 
> stop
> + thereby avoiding a
> + https://man.openbsd.org/printf.3;>printf(3) "%s" 
> NULL,
> + a use of uninitialized and a dead else branch.
>   Cleaned up events onhref="https://man.openbsd.org/vmd.8;>vmd(8) pause or resume 
> and
>   fixed an issue leading to broken serial console by cleanly 
> tearing
> @@ -1094,11 +1099,6 @@ to 6.9.
>   analysis of TCP connections.
>   Avoid leaking the help text in
>   https://man.openbsd.org/tcpbench.1;>systat(8).
> - Simplify argument parsing of
> - https://man.openbsd.org/vmctl.8;>vmctl(8) 
> stop
> - thereby avoiding a
> - https://man.openbsd.org/printf.3;>printf(3) "%s" 
> NULL,
> - a use of uninitialized and a dead else branch.
>   Increased the maximum length for CHAP challenges to 96 octets to
>   ensure https://man.openbsd.org/npppd.8;>npppd(8) 
> can
>   handle longer challenges, such as those sent by Juniper.
> 
> 



Re: add missing PCI ID for Intel NVMe

2021-03-13 Thread Jonathan Gray
On Sat, Mar 13, 2021 at 09:51:30PM +0100, Jan Klemkow wrote:
> On Fri, Mar 12, 2021 at 11:56:00AM +0100, Mark Kettenis wrote:
> > I believe this is what ark.intel.com calls a "Intel SSD DC P4510
> > Series" part.  Is that correct?
> 
> Yes, that is correct.
> 
> On Fri, Mar 12, 2021 at 10:00:54PM +1100, Jonathan Gray wrote:
> > On Fri, Mar 12, 2021 at 11:30:04AM +0100, Jan Klemkow wrote:
> > So it is a 'SSD DC P4510'
> > 
> > A driver downloaded from Intel has
> > ...
> > PCI\VEN_8086_0A54.DeviceDesc = "Intel(R) SSD DC 
> > P4500/4600/4501/4601/4608/4510/4610/4511 Series"
> > ...
> > 
> > perhaps just
> > product INTEL NVME_50x0a54  SSD DC
> 
> You are right, that's a better name.  Also the sticker on the disk just
> says "Intel SSD DC".
> 
> OK?

ok jsg@

> 
> Thanks,
> Jan
> 
> Index: pcidevs
> ===
> RCS file: /cvs/src/sys/dev/pci/pcidevs,v
> retrieving revision 1.1959
> diff -u -p -r1.1959 pcidevs
> --- pcidevs   27 Feb 2021 03:00:54 -  1.1959
> +++ pcidevs   13 Mar 2021 20:22:04 -
> @@ -3465,6 +3465,7 @@ product INTEL CORE4G_M_ULT_GT3  0x0a26  HD
>  product INTEL CORE4G_S_ULT_GT3   0x0a2a  HD Graphics
>  product INTEL CORE4G_R_ULT_GT3_1 0x0a2b  HD Graphics
>  product INTEL CORE4G_R_ULT_GT3_2 0x0a2e  Iris Graphics 5100
> +product INTEL NVME_5 0x0a54  SSD DC
>  product INTEL GMA3600_0  0x0be0  GMA 3600
>  product INTEL D2000_IGD  0x0be1  Atom D2000/N2000 Video
>  product INTEL GMA3600_2  0x0be2  GMA 3600
> Index: pcidevs.h
> ===
> RCS file: /cvs/src/sys/dev/pci/pcidevs.h,v
> retrieving revision 1.1953
> diff -u -p -r1.1953 pcidevs.h
> --- pcidevs.h 27 Feb 2021 03:01:25 -  1.1953
> +++ pcidevs.h 13 Mar 2021 20:22:06 -
> @@ -3470,6 +3470,7 @@
>  #define  PCI_PRODUCT_INTEL_CORE4G_S_ULT_GT3  0x0a2a  /* HD 
> Graphics */
>  #define  PCI_PRODUCT_INTEL_CORE4G_R_ULT_GT3_10x0a2b  /* HD 
> Graphics */
>  #define  PCI_PRODUCT_INTEL_CORE4G_R_ULT_GT3_20x0a2e  /* Iris 
> Graphics 5100 */
> +#define  PCI_PRODUCT_INTEL_NVME_50x0a54  /* SSD DC */
>  #define  PCI_PRODUCT_INTEL_GMA3600_0 0x0be0  /* GMA 3600 */
>  #define  PCI_PRODUCT_INTEL_D2000_IGD 0x0be1  /* Atom 
> D2000/N2000 Video */
>  #define  PCI_PRODUCT_INTEL_GMA3600_2 0x0be2  /* GMA 3600 */
> Index: pcidevs_data.h
> ===
> RCS file: /cvs/src/sys/dev/pci/pcidevs_data.h,v
> retrieving revision 1.1948
> diff -u -p -r1.1948 pcidevs_data.h
> --- pcidevs_data.h27 Feb 2021 03:01:25 -  1.1948
> +++ pcidevs_data.h13 Mar 2021 20:22:06 -
> @@ -11304,6 +11304,10 @@ static const struct pci_known_product pc
>   "Iris Graphics 5100",
>   },
>   {
> + PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_NVME_5,
> + "SSD DC",
> + },
> + {
>   PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_GMA3600_0,
>   "GMA 3600",
>   },
> 



Re: add missing PCI ID for Intel NVMe

2021-03-12 Thread Jonathan Gray
On Fri, Mar 12, 2021 at 11:30:04AM +0100, Jan Klemkow wrote:
> Hi,
> 
> This diff add a missing PCI ID of an Intel NVMe disk.  The disk works
> after my last fix [1].
> 
> OK?
> 
> bye,
> Jan
> 
> [1]: https://marc.info/?l=openbsd-tech=161418460303831

So it is a 'SSD DC P4510'

A driver downloaded from Intel has
PCI\VEN_8086_F1A6.DeviceDesc = "Intel(R) SSD Pro 7600p/760p/E 6100p Series"
PCI\VEN_8086_F1A8.DeviceDesc = "Intel(R) SSD 660p Series"
PCI\VEN_8086_FAF0.DeviceDesc = "Intel(R) SSD 665p Series"
PCI\VEN_8086_0953.DeviceDesc = "Intel(R) Solid-State Drive 
P3700/P3600/P3500/P3520/750 Series"
PCI\VEN_8086_0A53.DeviceDesc = "Intel(R) Solid-State Drive DC P3520 Series"
PCI\VEN_8086_0A54.DeviceDesc = "Intel(R) SSD DC 
P4500/4600/4501/4601/4608/4510/4610/4511 Series"
PCI\VEN_8086_0A55.DeviceDesc = "Intel(R) SSD DC P4600 Series"
PCI\VEN_8086_2700.DeviceDesc = "Intel(R) Optane(tm) SSD 900P/905P Series"
PCI\VEN_8086_2701.DeviceDesc = "Intel(R) Optane(tm) SSD DC P4800X Series"
PCI\VEN_8086_0B60.DeviceDesc = "Intel(R) SSD D7-P5500/P5600 Series"
PCI\VEN_8086_4140.DeviceDesc = "Intel(R) Optane(tm) SSD DC P5800X Series"

perhaps just
product INTEL NVME_50x0a54  SSD DC

> 
> Index: pcidevs
> ===
> RCS file: /cvs/src/sys/dev/pci/pcidevs,v
> retrieving revision 1.1959
> diff -u -p -r1.1959 pcidevs
> --- pcidevs   27 Feb 2021 03:00:54 -  1.1959
> +++ pcidevs   12 Mar 2021 10:16:44 -
> @@ -3465,6 +3465,7 @@ product INTEL CORE4G_M_ULT_GT3  0x0a26  HD
>  product INTEL CORE4G_S_ULT_GT3   0x0a2a  HD Graphics
>  product INTEL CORE4G_R_ULT_GT3_1 0x0a2b  HD Graphics
>  product INTEL CORE4G_R_ULT_GT3_2 0x0a2e  Iris Graphics 5100
> +product INTEL NVME_1 0x0a54  NVMe Datacenter SSD
>  product INTEL GMA3600_0  0x0be0  GMA 3600
>  product INTEL D2000_IGD  0x0be1  Atom D2000/N2000 Video
>  product INTEL GMA3600_2  0x0be2  GMA 3600
> Index: pcidevs.h
> ===
> RCS file: /cvs/src/sys/dev/pci/pcidevs.h,v
> retrieving revision 1.1953
> diff -u -p -r1.1953 pcidevs.h
> --- pcidevs.h 27 Feb 2021 03:01:25 -  1.1953
> +++ pcidevs.h 12 Mar 2021 10:16:46 -
> @@ -3470,6 +3470,7 @@
>  #define  PCI_PRODUCT_INTEL_CORE4G_S_ULT_GT3  0x0a2a  /* HD 
> Graphics */
>  #define  PCI_PRODUCT_INTEL_CORE4G_R_ULT_GT3_10x0a2b  /* HD 
> Graphics */
>  #define  PCI_PRODUCT_INTEL_CORE4G_R_ULT_GT3_20x0a2e  /* Iris 
> Graphics 5100 */
> +#define  PCI_PRODUCT_INTEL_NVME_10x0a54  /* NVMe 
> Datacenter SSD */
>  #define  PCI_PRODUCT_INTEL_GMA3600_0 0x0be0  /* GMA 3600 */
>  #define  PCI_PRODUCT_INTEL_D2000_IGD 0x0be1  /* Atom 
> D2000/N2000 Video */
>  #define  PCI_PRODUCT_INTEL_GMA3600_2 0x0be2  /* GMA 3600 */
> Index: pcidevs_data.h
> ===
> RCS file: /cvs/src/sys/dev/pci/pcidevs_data.h,v
> retrieving revision 1.1948
> diff -u -p -r1.1948 pcidevs_data.h
> --- pcidevs_data.h27 Feb 2021 03:01:25 -  1.1948
> +++ pcidevs_data.h12 Mar 2021 10:16:46 -
> @@ -11304,6 +11304,10 @@ static const struct pci_known_product pc
>   "Iris Graphics 5100",
>   },
>   {
> + PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_NVME_1,
> + "NVMe Datacenter SSD",
> + },
> + {
>   PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_GMA3600_0,
>   "GMA 3600",
>   },
> 
> 



Re: Sky Lake-E PCI ids.

2021-02-26 Thread Jonathan Gray
On Fri, Feb 26, 2021 at 11:12:17AM +0100, Karel Gardas wrote:
> On 2/26/21 7:24 AM, Jonathan Gray wrote:
> > As the ids are used on more than just Skylake-E here is another diff.
> > Though I think these ids are shared with Core X Skylake.  So perhaps
> > giving up on a marketing name is indeed the thing to do.
> 
> Indeed, Intel made quite a mess in this, but I think this your combination
> is probably the best one,
> although we risk to show "Xeon" on user system with high-end Core X cpus.
> The thing
> is those makes minority of all the chips in the family and technically they
> are crippled Xeons anyway,
> so if I may I would vote for this diff.
> 
> Thanks a lot for dealing with this mess.

thanks, committed

> 
> > Index: pcidevs
> > ===
> > RCS file: /cvs/src/sys/dev/pci/pcidevs,v
> > retrieving revision 1.1956
> > diff -u -p -r1.1956 pcidevs
> > --- pcidevs 22 Feb 2021 01:17:23 -  1.1956
> > +++ pcidevs 26 Feb 2021 05:39:05 -
> > @@ -4188,6 +4188,61 @@ product INTEL ATOMC2000_PCU_SMB  0x1f3c  A
> >   product INTEL I354_BP_1GBPS   0x1f40  I354
> >   product INTEL I354_SGMII  0x1f41  I354 SGMII
> >   product INTEL I354_BP_2_5GBPS 0x1f45  I354
> > +product INTEL XEONS_UBOX_1 0x2014  Xeon Scalable Ubox
> > +product INTEL XEONS_UBOX_2 0x2015  Xeon Scalable Ubox
> > +product INTEL XEONS_UBOX_3 0x2016  Xeon Scalable Ubox
> > 
> 
> 



Mesa leak in intel iris driver

2021-02-26 Thread Jonathan Gray
Bring in a change which was backported to Mesa 20.1 but not 20.0.
This is for inteldrm with >= gen8/broadwell hardware.
/var/log/Xorg.0.log with 'DRI driver: iris' and 'xdriinfo' will
show 'Screen 0: iris' if you are using the iris driver.

commit 17991448a2eb0930b106068bffc366946a05556e
Author: Kenneth Graunke 
Date:   Wed Jun 5 13:12:58 2019 -0700

iris: Delete shader variants when deleting the API-facing shader

We were space-leaking iris_compiled_shader objects, leaving them around
basically forever - long after the associated iris_uncompiled_shader was
deleted.  Perhaps even more importantly, this left the BO containing the
assembly referenced, meaning those were never reclaimed either.  For
long running applications, this can leak quite a bit of memory.

Now, when freeing iris_uncompiled_shader, we hunt down any associated
iris_compiled_shader objects and pitch those (and their BO) as well.

One issue is that the shader variants can still be bound, because we
haven't done a draw that updates the compiled shaders yet.  This can
cause issues because state changes want to look at the old program to
know what to flag dirty.  It's a bit tricky to get right, so instead
we defer variant deletion until the shaders are properly unbound, by
stashing them on a "dead" list and tidying that each time we try and
delete some shader variants.

This ensures long running programs delete their shaders eventually.

Fixes: ed4ffb97158 ("iris: rework program cache interface")
Reviewed-by: Matt Turner 
Part-of: 
(cherry picked from commit 128cbcd3a7ba543d644ed3189dcd668900b270f4)

Index: src/gallium/drivers/iris/iris_context.h
===
RCS file: /cvs/xenocara/lib/mesa/src/gallium/drivers/iris/iris_context.h,v
retrieving revision 1.1.1.3
diff -u -p -r1.1.1.3 iris_context.h
--- src/gallium/drivers/iris/iris_context.h 22 Sep 2020 01:31:05 -  
1.1.1.3
+++ src/gallium/drivers/iris/iris_context.h 26 Feb 2021 13:06:09 -
@@ -406,6 +406,8 @@ struct iris_binding_table {
  * (iris_uncompiled_shader), due to state-based recompiles (brw_*_prog_key).
  */
 struct iris_compiled_shader {
+   struct list_head link;
+
/** Reference to the uploaded assembly. */
struct iris_state_ref assembly;
 
@@ -664,6 +666,9 @@ struct iris_context {
   struct iris_compiled_shader *prog[MESA_SHADER_STAGES];
   struct brw_vue_map *last_vue_map;
 
+  /** List of shader variants whose deletion has been deferred for now */
+  struct list_head deleted_variants[MESA_SHADER_STAGES];
+
   struct u_upload_mgr *uploader;
   struct hash_table *cache;
 
@@ -945,6 +950,8 @@ struct iris_compiled_shader *iris_upload
 const void *iris_find_previous_compile(const struct iris_context *ice,
enum iris_program_cache_id cache_id,
unsigned program_string_id);
+void iris_delete_shader_variants(struct iris_context *ice,
+ struct iris_uncompiled_shader *ish);
 bool iris_blorp_lookup_shader(struct blorp_batch *blorp_batch,
   const void *key,
   uint32_t key_size,
Index: src/gallium/drivers/iris/iris_program.c
===
RCS file: /cvs/xenocara/lib/mesa/src/gallium/drivers/iris/iris_program.c,v
retrieving revision 1.1.1.3
diff -u -p -r1.1.1.3 iris_program.c
--- src/gallium/drivers/iris/iris_program.c 22 Sep 2020 01:31:05 -  
1.1.1.3
+++ src/gallium/drivers/iris/iris_program.c 26 Feb 2021 13:06:09 -
@@ -1812,9 +1812,6 @@ get_vue_prog_data(struct iris_context *i
return (void *) ice->shaders.prog[stage]->prog_data;
 }
 
-// XXX: iris_compiled_shaders are space-leaking :(
-// XXX: do remember to unbind them if deleting them.
-
 /**
  * Update the current shader variants for the given state.
  *
@@ -2387,6 +2384,8 @@ iris_delete_shader_state(struct pipe_con
   pipe_resource_reference(>const_data, NULL);
   pipe_resource_reference(>const_data_state.res, NULL);
}
+
+   iris_delete_shader_variants(ice, ish);
 
ralloc_free(ish->nir);
free(ish);
Index: src/gallium/drivers/iris/iris_program_cache.c
===
RCS file: /cvs/xenocara/lib/mesa/src/gallium/drivers/iris/iris_program_cache.c,v
retrieving revision 1.1.1.3
diff -u -p -r1.1.1.3 iris_program_cache.c
--- src/gallium/drivers/iris/iris_program_cache.c   22 Sep 2020 01:31:06 
-  1.1.1.3
+++ src/gallium/drivers/iris/iris_program_cache.c   26 Feb 2021 13:06:09 
-
@@ -115,6 +115,59 @@ iris_find_previous_compile(const struct 
return NULL;
 }
 
+void
+iris_delete_shader_variants(struct iris_context *ice,
+  

Re: Sky Lake-E PCI ids.

2021-02-25 Thread Jonathan Gray
On Fri, Feb 26, 2021 at 05:24:59PM +1100, Jonathan Gray wrote:
> On Thu, Feb 25, 2021 at 02:55:22PM +0100, Karel Gardas wrote:
> > 
> > > The marketing name is 'Xeon Processor Scalable Family'
> > > Intel Xeon Bronze 3XXX processor
> > > Intel Xeon Gold 6XXF processor
> > > Intel Xeon Platinum 6XXF processor
> > > Intel Xeon Platinum 8XXF processor
> > > Intel Xeon Silver 4XXX processor
> > > Intel Xeon Gold 5XXX processor
> > > Intel Xeon Platinum 6XXX processor
> > > Intel Xeon Platinum 8XXX processor
> > > Intel Xeon processor E Family
> > > Intel Xeon processor W Family
> > > Intel Core X-Series Processor Family i7 78xx and i9-79xx Series
> > > 
> > > With there also being '2nd Generation Intel Xeon Scalable Processors' and
> > > '3rd Generation Intel Xeon Scalable Processors'.
> > > 
> > > Intel documents contain statements like "The new Intel Xeon W processors
> > > are based on the Intel Xeon Scalable processor".
> > 
> > Xeon W-32xx/W-22xx are from marketing point of view 2nd generation already.
> > The only difference between W-21xx and W-22xx as I see it here
> > is revision change from 0x4 to 0x7 on related chips.
> 
> Yes the second generation scalable (Cascade Lake) parts reuse the cpuid
> model of Skylake and apparently the pci ids.
> 
> The steppings mentioned in the microcode release notes are
> 
> SKX-SP06-55-03/97 Xeon Scalable
> SKX-D 06-55-04/b7 Xeon D-21xx
> SKX-SP06-55-04/b7 Xeon Scalable
> CLX-SP06-55-06/bf Xeon Scalable Gen2
> CLX-SP06-55-07/bf Xeon Scalable Gen2
> CPX-SP06-55-0b/bf Xeon Scalable Gen3
> 
> https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/blob/microcode-20210216/releasenote.md
> 
> https://software.intel.com/security-software-guidance/processors-affected-transient-execution-attack-mitigation-product-cpu-model
> goes into more detail
> 
> > 
> > > 
> > > So I think it should be 'SP' and 'SP 2G' much like the way 'E5' is used.
> > 
> > E5 and E3, E7 were well known names. Your SP and SP 2G are completely new
> > and it would be still OK to use them in defines, but IMHO not OK to use them
> > in
> > the actual dmesg. Since current marketing output provided by Intel is
> > complete chaos,
> > I understand why others are rather using code names than marketing names or
> > even
> > abbreviation of long marketing names.
> 
> As the ids are used on more than just Skylake-E here is another diff.
> Though I think these ids are shared with Core X Skylake.  So perhaps
> giving up on a marketing name is indeed the thing to do.

with Skylake-E

Index: pcidevs
===
RCS file: /cvs/src/sys/dev/pci/pcidevs,v
retrieving revision 1.1956
diff -u -p -r1.1956 pcidevs
--- pcidevs 22 Feb 2021 01:17:23 -  1.1956
+++ pcidevs 26 Feb 2021 06:47:28 -
@@ -4188,6 +4188,61 @@ product INTEL ATOMC2000_PCU_SMB  0x1f3c  A
 product INTEL I354_BP_1GBPS0x1f40  I354
 product INTEL I354_SGMII   0x1f41  I354 SGMII
 product INTEL I354_BP_2_5GBPS  0x1f45  I354
+product INTEL SKX_UBOX_1   0x2014  Skylake-E Ubox
+product INTEL SKX_UBOX_2   0x2015  Skylake-E Ubox
+product INTEL SKX_UBOX_3   0x2016  Skylake-E Ubox
+product INTEL SKX_M2PCI0x2018  Skylake-E M2PCI
+product INTEL SKX_HB   0x2020  Skylake-E Host
+product INTEL SKX_CBDMA0x2021  Skylake-E CBDMA
+product INTEL SKX_VTD_10x2024  Skylake-E VT-d
+product INTEL SKX_RAS_10x2025  Skylake-E RAS
+product INTEL SKX_IOAPIC   0x2026  Skylake-E I/O APIC
+product INTEL SKX_PCIE_1   0x2030  Skylake-E PCIE
+product INTEL SKX_PCIE_2   0x2031  Skylake-E PCIE
+product INTEL SKX_PCIE_3   0x2032  Skylake-E PCIE
+product INTEL SKX_PCIE_4   0x2033  Skylake-E PCIE
+product INTEL SKX_VTD_20x2034  Skylake-E VT-d
+product INTEL SKX_RAS_20x2035  Skylake-E RAS
+product INTEL SKX_IOXAPIC  0x2036  Skylake-E IOxAPIC
+product INTEL SKX_IMC_10x2040  Skylake-E IMC
+product INTEL SKX_IMC_20x2041  Skylake-E IMC
+product INTEL SKX_IMC_30x2042  Skylake-E IMC
+product INTEL SKX_IMC_40x2043  Skylake-E IMC
+product INTEL SKX_IMC_50x2044  Skylake-E IMC
+product INTEL SKX_LM_C10x2045  Skylake-E LM
+product INTEL SKX_LMS_C1   0x2046  Skylake-E LMS
+product INTEL SKX_LMDP_C1  0x2047  Skylake-E LMDP
+product INTEL SKX_DECS_C2  0x2048  Skylake-E DECS
+product INTEL SKX_LM_C20x2049  Skylake-E LM
+product INTEL SKX_LMS_C2   0x20

Re: Sky Lake-E PCI ids.

2021-02-25 Thread Jonathan Gray
On Thu, Feb 25, 2021 at 02:55:22PM +0100, Karel Gardas wrote:
> 
> > The marketing name is 'Xeon Processor Scalable Family'
> > Intel Xeon Bronze 3XXX processor
> > Intel Xeon Gold 6XXF processor
> > Intel Xeon Platinum 6XXF processor
> > Intel Xeon Platinum 8XXF processor
> > Intel Xeon Silver 4XXX processor
> > Intel Xeon Gold 5XXX processor
> > Intel Xeon Platinum 6XXX processor
> > Intel Xeon Platinum 8XXX processor
> > Intel Xeon processor E Family
> > Intel Xeon processor W Family
> > Intel Core X-Series Processor Family i7 78xx and i9-79xx Series
> > 
> > With there also being '2nd Generation Intel Xeon Scalable Processors' and
> > '3rd Generation Intel Xeon Scalable Processors'.
> > 
> > Intel documents contain statements like "The new Intel Xeon W processors
> > are based on the Intel Xeon Scalable processor".
> 
> Xeon W-32xx/W-22xx are from marketing point of view 2nd generation already.
> The only difference between W-21xx and W-22xx as I see it here
> is revision change from 0x4 to 0x7 on related chips.

Yes the second generation scalable (Cascade Lake) parts reuse the cpuid
model of Skylake and apparently the pci ids.

The steppings mentioned in the microcode release notes are

SKX-SP  06-55-03/97 Xeon Scalable
SKX-D   06-55-04/b7 Xeon D-21xx
SKX-SP  06-55-04/b7 Xeon Scalable
CLX-SP  06-55-06/bf Xeon Scalable Gen2
CLX-SP  06-55-07/bf Xeon Scalable Gen2
CPX-SP  06-55-0b/bf Xeon Scalable Gen3

https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/blob/microcode-20210216/releasenote.md

https://software.intel.com/security-software-guidance/processors-affected-transient-execution-attack-mitigation-product-cpu-model
goes into more detail

> 
> > 
> > So I think it should be 'SP' and 'SP 2G' much like the way 'E5' is used.
> 
> E5 and E3, E7 were well known names. Your SP and SP 2G are completely new
> and it would be still OK to use them in defines, but IMHO not OK to use them
> in
> the actual dmesg. Since current marketing output provided by Intel is
> complete chaos,
> I understand why others are rather using code names than marketing names or
> even
> abbreviation of long marketing names.

As the ids are used on more than just Skylake-E here is another diff.
Though I think these ids are shared with Core X Skylake.  So perhaps
giving up on a marketing name is indeed the thing to do.

Index: pcidevs
===
RCS file: /cvs/src/sys/dev/pci/pcidevs,v
retrieving revision 1.1956
diff -u -p -r1.1956 pcidevs
--- pcidevs 22 Feb 2021 01:17:23 -  1.1956
+++ pcidevs 26 Feb 2021 05:39:05 -
@@ -4188,6 +4188,61 @@ product INTEL ATOMC2000_PCU_SMB  0x1f3c  A
 product INTEL I354_BP_1GBPS0x1f40  I354
 product INTEL I354_SGMII   0x1f41  I354 SGMII
 product INTEL I354_BP_2_5GBPS  0x1f45  I354
+product INTEL XEONS_UBOX_1 0x2014  Xeon Scalable Ubox
+product INTEL XEONS_UBOX_2 0x2015  Xeon Scalable Ubox
+product INTEL XEONS_UBOX_3 0x2016  Xeon Scalable Ubox
+product INTEL XEONS_M2PCI  0x2018  Xeon Scalable M2PCI
+product INTEL XEONS_HB 0x2020  Xeon Scalable Host
+product INTEL XEONS_CBDMA  0x2021  Xeon Scalable CBDMA
+product INTEL XEONS_VTD_1  0x2024  Xeon Scalable VT-d
+product INTEL XEONS_RAS_1  0x2025  Xeon Scalable RAS
+product INTEL XEONS_IOAPIC 0x2026  Xeon Scalable I/O APIC
+product INTEL XEONS_PCIE_1 0x2030  Xeon Scalable PCIE
+product INTEL XEONS_PCIE_2 0x2031  Xeon Scalable PCIE
+product INTEL XEONS_PCIE_3 0x2032  Xeon Scalable PCIE
+product INTEL XEONS_PCIE_4 0x2033  Xeon Scalable PCIE
+product INTEL XEONS_VTD_2  0x2034  Xeon Scalable VT-d
+product INTEL XEONS_RAS_2  0x2035  Xeon Scalable RAS
+product INTEL XEONS_IOXAPIC0x2036  Xeon Scalable IOxAPIC
+product INTEL XEONS_IMC_1  0x2040  Xeon Scalable IMC
+product INTEL XEONS_IMC_2  0x2041  Xeon Scalable IMC
+product INTEL XEONS_IMC_3  0x2042  Xeon Scalable IMC
+product INTEL XEONS_IMC_4  0x2043  Xeon Scalable IMC
+product INTEL XEONS_IMC_5  0x2044  Xeon Scalable IMC
+product INTEL XEONS_LM_C1  0x2045  Xeon Scalable LM
+product INTEL XEONS_LMS_C1 0x2046  Xeon Scalable LMS
+product INTEL XEONS_LMDP_C10x2047  Xeon Scalable LMDP
+product INTEL XEONS_DECS_C20x2048  Xeon Scalable DECS
+product INTEL XEONS_LM_C2  0x2049  Xeon Scalable LM
+product INTEL XEONS_LMS_C2 0x204a  Xeon Scalable LMS
+product INTEL XEONS_LMDP_C20x204b  Xeon Scalable LMDP
+product INTEL XEONS_M3KTI_10x204c  Xeon Scalable M3KTI
+product INTEL XEONS_M3KTI_20x204d  Xeon Scalable M3KTI
+product INTEL XEONS_M3KTI_30x204e  Xeon Scalable M3KTI
+product INTEL XEONS_CHA_1  0x2054  Xeon Scalable CHA
+product INTEL XEONS_CHA_2  0x2055  Xeon Scalable CHA
+product INTEL XEONS_CHA_3  0x2056  Xeon Scalable CHA
+product INTEL XEONS_CHA_4  0x2057  Xeon Scalable CHA
+product INTEL XEONS_KTI0x2058  Xeon Scalable KTI
+product 

Re: Sky Lake-E PCI ids.

2021-02-25 Thread Jonathan Gray
On Thu, Feb 25, 2021 at 11:29:09AM +0100, Karel Gardas wrote:
> On 2/25/21 10:34 AM, Jonathan Gray wrote:
> > On Wed, Feb 24, 2021 at 05:01:50PM +0100, Karel Gardas wrote:
> > > Hello,
> > > 
> > > attach patch adds some SkyLake-E related PCI ids. Tested on 
> > > Kontron/Fujitsu
> > > D3598-B with Intel Xeon W-2123.
> > > 
> > > Thanks for review, comment(s) and/or commit.
> > > 
> > > Karel
> > > 
> > I can only find a handful of Ubox/PCU numbers in
> > 
> > '614073-336062-Xeon Scalable Mem Datasheet Vol2 R4.pdf'
> > Intel Xeon Processor Scalable Family
> > Datasheet, Volume Two: Registers
> > August 2020
> > 336062-004US
> 
> Thanks for the document reference. But I've used...
> 
> > Is there a document that has most of these?
> 
> FreeBSD's own pci vendor DB which claims to use data from PCI ID project:
> 
> https://raw.githubusercontent.com/freebsd/freebsd-src/main/share/misc/pci_vendors
> 
> > Can you send a dmesg without this diff applied?
> 
> I hope you don't mind dmesg from current but from Dec 8 2020. Dmesg is from
> W-2265 which shows a bit more
> registers than W-2123. See below.
> 
> > It is 'Skylake' not 'Sky Lake' and the descriptions are too verbose
> > compared to existing pcidevs entries.
> 
> If it is not 'Sky Lake' then it is in kind of format violation with
> OpenBSD's own 'Apollo Lake' and 'Gemini Lake'.

'Products formerly Skylake'
https://ark.intel.com/content/www/us/en/ark/products/codename/37572/skylake.html

'Products formerly Apollo Lake'
https://ark.intel.com/content/www/us/en/ark/products/codename/80644/apollo-lake.html

> So I would rather stay with 'Sky Lake-E'. As per verbosity I guess you are
> most against 'Integrated Memory Controller' and against
> various ' Registers'. I may shorten and remove those...

The marketing name is 'Xeon Processor Scalable Family'
Intel Xeon Bronze 3XXX processor
Intel Xeon Gold 6XXF processor
Intel Xeon Platinum 6XXF processor
Intel Xeon Platinum 8XXF processor
Intel Xeon Silver 4XXX processor
Intel Xeon Gold 5XXX processor
Intel Xeon Platinum 6XXX processor
Intel Xeon Platinum 8XXX processor
Intel Xeon processor E Family
Intel Xeon processor W Family
Intel Core X-Series Processor Family i7 78xx and i9-79xx Series

With there also being '2nd Generation Intel Xeon Scalable Processors' and
'3rd Generation Intel Xeon Scalable Processors'.

Intel documents contain statements like "The new Intel Xeon W processors
are based on the Intel Xeon Scalable processor".

So I think it should be 'SP' and 'SP 2G' much like the way 'E5' is used.

> 
> Thanks,
> Karel

Going to the fujitsu page for D3598-B1 leads to
FTS_ChipsetSoftwareInstallationUtility_101144PV_1184194.zip and inside
that eventually is Skylake-ESystem.inf and KabyLakePCH-HSystem.inf

PCI\VEN_8086_A2D3Desc="Intel(R) 200 Series Chipset Family LPC Controller 
(C422) - A2D3"

PCI\VEN_8086_2014Desc="Intel(R) Xeon(R) processor P family/Core i7 Ubox 
Registers - 2014"
PCI\VEN_8086_2015Desc="Intel(R) Xeon(R) processor P family/Core i7 Ubox 
Registers - 2015"
PCI\VEN_8086_2016Desc="Intel(R) Xeon(R) processor P family/Core i7 Ubox 
Registers - 2016"
PCI\VEN_8086_2018Desc="Intel(R) Xeon(R) processor P family/Core i7 M2PCI 
Registers - 2018"
PCI\VEN_8086_2020Desc="Intel(R) Xeon(R) processor P family/Core i7 DMI3 
Port - 2020"
PCI\VEN_8086_2021Desc="Intel(R) Xeon(R) processor P family/Core i7 CBDMA 
Registers - 2021"
PCI\VEN_8086_2024Desc="Intel(R) Xeon(R) processor P family/Core i7 MM/Vt - 
d Configuration Registers - 2024"
PCI\VEN_8086_2025Desc="Intel(R) Xeon(R) processor P family/Core i7 RAS - 
2025"
PCI\VEN_8086_2026Desc="Intel(R) Xeon(R) processor P family/Core i7 IOAPIC - 
2026"
PCI\VEN_8086_2030Desc="Intel(R) Xeon(R) processor P family/Core i7 PCI 
Express Root Port 1A - 2030"
PCI\VEN_8086_2031Desc="Intel(R) Xeon(R) processor P family/Core i7 PCI 
Express Root Port 1B - 2031"
PCI\VEN_8086_2032Desc="Intel(R) Xeon(R) processor P family/Core i7 PCI 
Express Root Port 1C - 2032"
PCI\VEN_8086_2033Desc="Intel(R) Xeon(R) processor P family/Core i7 PCI 
Express Root Port 1D - 2033"
PCI\VEN_8086_2034Desc="Intel(R) Xeon(R) processor P family/Core i7 Intel VT 
- D - 2034"
PCI\VEN_8086_2035Desc="Intel(R) Xeon(R) processor P family/Core i7 RAS 
Configuration Registers - 2035"
PCI\VEN_8086_2036Desc="Intel(R) Xeon(R) processor P family/Core i7 IOxAPIC 
Configuration Registers - 2036"
PCI\VEN_8086_2040Desc="Intel(R) Xeon(R) processor P family/Core i7 
Integrated Memory Controller - 2040"
PCI\VEN_8086_2041Desc="Intel(R) Xeon(R) processor P family/Core i7 
Integrated Memory 

Re: Sky Lake-E PCI ids.

2021-02-25 Thread Jonathan Gray
On Wed, Feb 24, 2021 at 05:01:50PM +0100, Karel Gardas wrote:
> 
> Hello,
> 
> attach patch adds some SkyLake-E related PCI ids. Tested on Kontron/Fujitsu
> D3598-B with Intel Xeon W-2123.
> 
> Thanks for review, comment(s) and/or commit.
> 
> Karel
> 

I can only find a handful of Ubox/PCU numbers in

'614073-336062-Xeon Scalable Mem Datasheet Vol2 R4.pdf'
Intel Xeon Processor Scalable Family
Datasheet, Volume Two: Registers
August 2020
336062-004US

Is there a document that has most of these?

Can you send a dmesg without this diff applied?

It is 'Skylake' not 'Sky Lake' and the descriptions are too verbose
compared to existing pcidevs entries.

https://ark.intel.com/content/www/us/en/ark/products/125036/intel-xeon-w-2123-processor-8-25m-cache-3-60-ghz.html

> 

> diff --git a/sys/dev/pci/pcidevs b/sys/dev/pci/pcidevs
> index ba975d05548..10d98d3ce2b 100644
> --- a/sys/dev/pci/pcidevs
> +++ b/sys/dev/pci/pcidevs
> @@ -4188,6 +4188,53 @@ product INTEL ATOMC2000_PCU_SMB0x1f3c  Atom 
> C2000 PCU SMBus
>  product INTEL I354_BP_1GBPS  0x1f40  I354
>  product INTEL I354_SGMII 0x1f41  I354 SGMII
>  product INTEL I354_BP_2_5GBPS0x1f45  I354
> +product INTEL SKYLAKE_E_UBOX_1   0x2014  Sky Lake-E Ubox Registers
> +product INTEL SKYLAKE_E_UBOX_2   0x2015  Sky Lake-E Ubox Registers
> +product INTEL SKYLAKE_E_UBOX_3   0x2016  Sky Lake-E Ubox Registers
> +product INTEL SKYLAKE_E_M2PCI0x2018  Sky Lake-E M2PCI Registers
> +product INTEL SKYLAKE_E_DMI3 0x2020  Sky Lake-E DMI3 Registers
> +product INTEL SKYLAKE_E_CBDMA0x2021  Sky Lake-E CBDMA Registers
> +product INTEL SKYLAKE_E_MMVTD0x2024  Sky Lake-E MM/VT-d 
> Configuration Registers
> +product INTEL SKYLAKE_E_RAS  0x2025  Sky Lake-E RAS
> +product INTEL SKYLAKE_E_IOAPIC   0x2026  Sky Lake-E IOAPIC
> +product INTEL SKYLAKE_E_PCIE_RPA 0x2030  Sky Lake-E PCI Express Root 
> Port A
> +product INTEL SKYLAKE_E_PCIE_RPB 0x2031  Sky Lake-E PCI Express Root 
> Port B
> +product INTEL SKYLAKE_E_PCIE_RPC 0x2032  Sky Lake-E PCI Express Root 
> Port C
> +product INTEL SKYLAKE_E_PCIE_RPD 0x2033  Sky Lake-E PCI Express Root 
> Port D
> +product INTEL SKYLAKE_E_VTD  0x2034  Sky Lake-E VT-d
> +product INTEL SKYLAKE_E_RAS_CR   0x2035  Sky Lake-E RAS Configuration 
> Registers
> +product INTEL SKYLAKE_E_IOAPIC_CR0x2036  Sky Lake-E IO xAPIC 
> Configuration Registers
> +product INTEL SKYLAKE_E_IMC_10x2040  Sky Lake-E Integrated Memory 
> Controller
> +product INTEL SKYLAKE_E_IMC_20x2041  Sky Lake-E Integrated Memory 
> Controller
> +product INTEL SKYLAKE_E_IMC_30x2042  Sky Lake-E Integrated Memory 
> Controller
> +product INTEL SKYLAKE_E_IMC_40x2043  Sky Lake-E Integrated Memory 
> Controller
> +product INTEL SKYLAKE_E_IMC_50x2044  Sky Lake-E Integrated Memory 
> Controller
> +product INTEL SKYLAKE_E_LM_CH_1  0x2045  Sky Lake-E LM Channel 1
> +product INTEL SKYLAKE_E_LMS_CH_1 0x2046  Sky Lake-E LMS Channel 1
> +product INTEL SKYLAKE_E_LMDP_CH_10x2047  Sky Lake-E LMDP Channel 1
> +product INTEL SKYLAKE_E_DECS_CH_20x2048  Sky Lake-E DECS Channel 2
> +product INTEL SKYLAKE_E_LM_CH_2  0x2049  Sky Lake-E LM Channel 2
> +product INTEL SKYLAKE_E_LMS_CH_2 0x204a  Sky Lake-E LMS Channel 2
> +product INTEL SKYLAKE_E_LMDP_CH_20x204b  Sky Lake-E LMDP Channel 2
> +product INTEL SKYLAKE_E_M3KTI_1  0x204c  Sky Lake-E M3KTI Registers
> +product INTEL SKYLAKE_E_M3KTI_2  0x204d  Sky Lake-E M3KTI Registers
> +product INTEL SKYLAKE_E_M3KTI_3  0x204e  Sky Lake-E M3KTI Registers
> +product INTEL SKYLAKE_E_IMC_60x2066  Sky Lake-E Integrated Memory 
> Controller
> +product INTEL SKYLAKE_E_CHA_10x2054  Sky Lake-E CHA Registers
> +product INTEL SKYLAKE_E_CHA_20x2055  Sky Lake-E CHA Registers
> +product INTEL SKYLAKE_E_CHA_30x2056  Sky Lake-E CHA Registers
> +product INTEL SKYLAKE_E_CHA_40x2057  Sky Lake-E CHA Registers
> +product INTEL SKYLAKE_E_PCU_10x2078  Sky Lake-E PCU Registers
> +product INTEL SKYLAKE_E_PCU_20x207a  Sky Lake-E PCU Registers
> +product INTEL SKYLAKE_E_PCU_30x2080  Sky Lake-E PCU Registers
> +product INTEL SKYLAKE_E_PCU_40x2081  Sky Lake-E PCU Registers
> +product INTEL SKYLAKE_E_PCU_50x2082  Sky Lake-E PCU Registers
> +product INTEL SKYLAKE_E_PCU_60x2083  Sky Lake-E PCU Registers
> +product INTEL SKYLAKE_E_PCU_70x2084  Sky Lake-E PCU Registers
> +product INTEL SKYLAKE_E_PCU_80x2085  Sky Lake-E PCU Registers
> +product INTEL SKYLAKE_E_PCU_90x2086  Sky Lake-E PCU Registers
> +product INTEL SKYLAKE_E_CHA_50x208d  Sky Lake-E CHA Registers
> +product INTEL SKYLAKE_E_CHA_60x208e  Sky Lake-E CHA Registers
>  product INTEL BSW_HB 0x2280  Braswell Host
>  product INTEL BSW_HDA0x2284  Braswell HD Audio
>  product INTEL BSW_SIO_DMA_2  0x2286  Braswell SIO DMA
> @@ -6001,6 +6048,7 @@ product 

Re: occasional SSIGSEGV on C++ exception handling

2021-02-22 Thread Jonathan Gray
On Tue, Feb 23, 2021 at 08:10:54AM +0100, Otto Moerbeek wrote:
> On Mon, Feb 22, 2021 at 08:58:07PM -, Miod Vallat wrote:
> 
> > 
> > > No problem, real-life often takes precedence.
> > 
> > No way! operator(7) would need an update!
> > 
> 
> What do we do when we see a bug? We fix it! What if it is not fixable?
> We document it!
> 
>   -Otto

real life is not a C operator

> 
> Index: operator.7
> ===
> RCS file: /cvs/src/share/man/man7/operator.7,v
> retrieving revision 1.11
> diff -u -p -r1.11 operator.7
> --- operator.721 Jun 2019 02:28:34 -  1.11
> +++ operator.723 Feb 2021 07:09:10 -
> @@ -57,3 +57,5 @@
>  .It "\&," Ta "left to right"
>  .El
>  .Ed
> +.Sh BUGS
> +Often real life takes precedence.
> 
> 



Re: use /dev/dri/ in xenocara

2021-02-18 Thread Jonathan Gray
On Thu, Feb 18, 2021 at 11:34:19AM +, Stuart Henderson wrote:
> On 2021/02/18 22:24, Jonathan Gray wrote:
> > On Thu, Feb 18, 2021 at 12:01:28PM +0100, Mark Kettenis wrote:
> > > > Date: Thu, 18 Feb 2021 21:18:51 +1100
> > > > From: Jonathan Gray 
> > > 
> > > I suspect that there are some ports that need to get their unveils
> > > updated if we do this.
> > 
> > firefox ports were updated.  Not aware of anything else in ports that
> > unveils /dev/drm.
> 
> unveils: not afaik
> 
> others: gdm already handled it, some other ports will need patches changing:
> 
> graphics/clutter/cogl/patches/patch-cogl_winsys_cogl-winsys-egl-kms_c
> graphics/waffle/patches/patch-src_waffle_gbm_wgbm_display_c
> x11/compton/patches/patch-src_compton_c
> x11/slim/patches/patch-slim_conf

This is a display manager like xdm/gdm.  The last upstream release was
in 2013.  I can patch it after the xenocara changes go in or perhaps we
remove it as landry suggested in


revision 1.55
date: 2020/07/24 05:41:37;  author: landry;  state: Exp;  lines: +2 -3;  
commitid: yb1SZfwKZuXceEq0;
Drop maintainership, i havent used slim in ages.

Anyway it's more or less dead upstream since 7 years, which doesnt look
good for a login manager.. candidate for removal ? xenodm works ootb,
and is customizable once you grok X properties..


> x11/picom/patches/patch-src_vsync_c

/dev/drm will stay for now so the others can be updated later.



Re: use /dev/dri/ in xenocara

2021-02-18 Thread Jonathan Gray
On Thu, Feb 18, 2021 at 12:29:29PM +0100, Mark Kettenis wrote:
> > Date: Thu, 18 Feb 2021 22:24:10 +1100
> > From: Jonathan Gray 
> > 
> > On Thu, Feb 18, 2021 at 12:01:28PM +0100, Mark Kettenis wrote:
> > > > Date: Thu, 18 Feb 2021 21:18:51 +1100
> > > > From: Jonathan Gray 
> > > 
> > > I suspect that there are some ports that need to get their unveils
> > > updated if we do this.
> > 
> > firefox ports were updated.  Not aware of anything else in ports that
> > unveils /dev/drm.
> 
> Doesn't chromium use unveil?

chromium opens the device outside of the sandbox

> 
> Anyway, this should make unveiling easier and if you are coordinating
> with the ports folks, this is ok kettenis@
> 
> > > > Index: lib/libdrm/xf86drm.h
> > > > ===
> > > > RCS file: /cvs/xenocara/lib/libdrm/xf86drm.h,v
> > > > retrieving revision 1.21
> > > > diff -u -p -r1.21 xf86drm.h
> > > > --- lib/libdrm/xf86drm.h11 Feb 2021 10:27:08 -  1.21
> > > > +++ lib/libdrm/xf86drm.h18 Feb 2021 10:02:03 -
> > > > @@ -76,18 +76,11 @@ extern "C" {
> > > > (S_IRUSR|S_IWUSR|S_IXUSR|S_IRGRP|S_IXGRP|S_IROTH|S_IXOTH)
> > > >  #define DRM_DEV_MODE(S_IRUSR|S_IWUSR|S_IRGRP|S_IWGRP)
> > > >  
> > > > -#ifdef __OpenBSD__
> > > > -#define DRM_DIR_NAME  "/dev"
> > > > -#define DRM_PRIMARY_MINOR_NAME  "drm"
> > > > -#define DRM_CONTROL_MINOR_NAME  "drmC"
> > > > -#define DRM_RENDER_MINOR_NAME   "drmR"
> > > > -#else
> > > >  #define DRM_DIR_NAME  "/dev/dri"
> > > >  #define DRM_PRIMARY_MINOR_NAME  "card"
> > > >  #define DRM_CONTROL_MINOR_NAME  "controlD"
> > > >  #define DRM_RENDER_MINOR_NAME   "renderD"
> > > >  #define DRM_PROC_NAME "/proc/dri/" /* For backward Linux compatibility 
> > > > */
> > > > -#endif
> > > >  
> > > >  #define DRM_DEV_NAME  "%s/" DRM_PRIMARY_MINOR_NAME "%d"
> > > >  #define DRM_CONTROL_DEV_NAME  "%s/" DRM_CONTROL_MINOR_NAME "%d"
> > > > Index: xserver/hw/xfree86/drivers/modesetting/driver.c
> > > > ===
> > > > RCS file: 
> > > > /cvs/xenocara/xserver/hw/xfree86/drivers/modesetting/driver.c,v
> > > > retrieving revision 1.9
> > > > diff -u -p -r1.9 driver.c
> > > > --- xserver/hw/xfree86/drivers/modesetting/driver.c 12 Dec 2020 
> > > > 09:30:54 -  1.9
> > > > +++ xserver/hw/xfree86/drivers/modesetting/driver.c 18 Feb 2021 
> > > > 10:02:03 -
> > > > @@ -226,7 +226,7 @@ open_hw(const char *dev)
> > > >  else {
> > > >  dev = getenv("KMSDEVICE");
> > > >  if ((NULL == dev) || ((fd = priv_open_device(dev)) == -1)) {
> > > > -dev = "/dev/drm0";
> > > > +dev = "/dev/dri/card0";
> > > >  fd = priv_open_device(dev);
> > > >  }
> > > >  }
> > > > 
> > > > 
> > > 
> > 
> 



Re: use /dev/dri/ in xenocara

2021-02-18 Thread Jonathan Gray
On Thu, Feb 18, 2021 at 12:01:28PM +0100, Mark Kettenis wrote:
> > Date: Thu, 18 Feb 2021 21:18:51 +1100
> > From: Jonathan Gray 
> 
> I suspect that there are some ports that need to get their unveils
> updated if we do this.

firefox ports were updated.  Not aware of anything else in ports that
unveils /dev/drm.

> 
> > Index: lib/libdrm/xf86drm.h
> > ===
> > RCS file: /cvs/xenocara/lib/libdrm/xf86drm.h,v
> > retrieving revision 1.21
> > diff -u -p -r1.21 xf86drm.h
> > --- lib/libdrm/xf86drm.h11 Feb 2021 10:27:08 -  1.21
> > +++ lib/libdrm/xf86drm.h18 Feb 2021 10:02:03 -
> > @@ -76,18 +76,11 @@ extern "C" {
> > (S_IRUSR|S_IWUSR|S_IXUSR|S_IRGRP|S_IXGRP|S_IROTH|S_IXOTH)
> >  #define DRM_DEV_MODE(S_IRUSR|S_IWUSR|S_IRGRP|S_IWGRP)
> >  
> > -#ifdef __OpenBSD__
> > -#define DRM_DIR_NAME  "/dev"
> > -#define DRM_PRIMARY_MINOR_NAME  "drm"
> > -#define DRM_CONTROL_MINOR_NAME  "drmC"
> > -#define DRM_RENDER_MINOR_NAME   "drmR"
> > -#else
> >  #define DRM_DIR_NAME  "/dev/dri"
> >  #define DRM_PRIMARY_MINOR_NAME  "card"
> >  #define DRM_CONTROL_MINOR_NAME  "controlD"
> >  #define DRM_RENDER_MINOR_NAME   "renderD"
> >  #define DRM_PROC_NAME "/proc/dri/" /* For backward Linux compatibility */
> > -#endif
> >  
> >  #define DRM_DEV_NAME  "%s/" DRM_PRIMARY_MINOR_NAME "%d"
> >  #define DRM_CONTROL_DEV_NAME  "%s/" DRM_CONTROL_MINOR_NAME "%d"
> > Index: xserver/hw/xfree86/drivers/modesetting/driver.c
> > ===
> > RCS file: /cvs/xenocara/xserver/hw/xfree86/drivers/modesetting/driver.c,v
> > retrieving revision 1.9
> > diff -u -p -r1.9 driver.c
> > --- xserver/hw/xfree86/drivers/modesetting/driver.c 12 Dec 2020 09:30:54 
> > -  1.9
> > +++ xserver/hw/xfree86/drivers/modesetting/driver.c 18 Feb 2021 10:02:03 
> > -
> > @@ -226,7 +226,7 @@ open_hw(const char *dev)
> >  else {
> >  dev = getenv("KMSDEVICE");
> >  if ((NULL == dev) || ((fd = priv_open_device(dev)) == -1)) {
> > -dev = "/dev/drm0";
> > +dev = "/dev/dri/card0";
> >  fd = priv_open_device(dev);
> >  }
> >  }
> > 
> > 
> 



use /dev/dri/ in xenocara

2021-02-18 Thread Jonathan Gray
Index: lib/libdrm/xf86drm.h
===
RCS file: /cvs/xenocara/lib/libdrm/xf86drm.h,v
retrieving revision 1.21
diff -u -p -r1.21 xf86drm.h
--- lib/libdrm/xf86drm.h11 Feb 2021 10:27:08 -  1.21
+++ lib/libdrm/xf86drm.h18 Feb 2021 10:02:03 -
@@ -76,18 +76,11 @@ extern "C" {
(S_IRUSR|S_IWUSR|S_IXUSR|S_IRGRP|S_IXGRP|S_IROTH|S_IXOTH)
 #define DRM_DEV_MODE(S_IRUSR|S_IWUSR|S_IRGRP|S_IWGRP)
 
-#ifdef __OpenBSD__
-#define DRM_DIR_NAME  "/dev"
-#define DRM_PRIMARY_MINOR_NAME  "drm"
-#define DRM_CONTROL_MINOR_NAME  "drmC"
-#define DRM_RENDER_MINOR_NAME   "drmR"
-#else
 #define DRM_DIR_NAME  "/dev/dri"
 #define DRM_PRIMARY_MINOR_NAME  "card"
 #define DRM_CONTROL_MINOR_NAME  "controlD"
 #define DRM_RENDER_MINOR_NAME   "renderD"
 #define DRM_PROC_NAME "/proc/dri/" /* For backward Linux compatibility */
-#endif
 
 #define DRM_DEV_NAME  "%s/" DRM_PRIMARY_MINOR_NAME "%d"
 #define DRM_CONTROL_DEV_NAME  "%s/" DRM_CONTROL_MINOR_NAME "%d"
Index: xserver/hw/xfree86/drivers/modesetting/driver.c
===
RCS file: /cvs/xenocara/xserver/hw/xfree86/drivers/modesetting/driver.c,v
retrieving revision 1.9
diff -u -p -r1.9 driver.c
--- xserver/hw/xfree86/drivers/modesetting/driver.c 12 Dec 2020 09:30:54 
-  1.9
+++ xserver/hw/xfree86/drivers/modesetting/driver.c 18 Feb 2021 10:02:03 
-
@@ -226,7 +226,7 @@ open_hw(const char *dev)
 else {
 dev = getenv("KMSDEVICE");
 if ((NULL == dev) || ((fd = priv_open_device(dev)) == -1)) {
-dev = "/dev/drm0";
+dev = "/dev/dri/card0";
 fd = priv_open_device(dev);
 }
 }



Re: add simplepmbus(4)

2021-02-17 Thread Jonathan Gray
On Wed, Feb 17, 2021 at 11:49:27AM +0100, Mark Kettenis wrote:
> > Date: Wed, 17 Feb 2021 20:59:06 +1100
> > From: Jonathan Gray 
> > 
> > On Wed, Feb 17, 2021 at 10:33:18AM +0100, Patrick Wildt wrote:
> > > Am Wed, Feb 17, 2021 at 11:56:16AM +1100 schrieb Jonathan Gray:
> > > > Add a driver for "simple-pm-bus" a way to enable a clock and/or
> > > > power domain for a group of devices.
> > > > 
> > > > https://www.kernel.org/doc/Documentation/devicetree/bindings/bus/simple-pm-bus.txt
> > > > 
> > > > This is needed to use am335x/omap4 dtbs from linux 5.11.
> > > 
> > > "A Simple Power-Managed Bus is a transparent bus that doesn't need a real
> > > driver, as it's typically initialized by the boot loader."
> > > 
> > > That's a bit funny though. :-)  But I think they meant "it doesn't need
> > > a real driver, apart from the generic simple-pm-bus driver".
> > > 
> > > 
> > > > Index: sys/dev/fdt/files.fdt
> > > > ===
> > > > RCS file: /cvs/src/sys/dev/fdt/files.fdt,v
> > > > retrieving revision 1.146
> > > > diff -u -p -r1.146 files.fdt
> > > > --- sys/dev/fdt/files.fdt   5 Feb 2021 00:05:20 -   1.146
> > > > +++ sys/dev/fdt/files.fdt   17 Feb 2021 00:49:02 -
> > > > @@ -23,6 +23,10 @@ device   simplepanel
> > > >  attach simplepanel at fdt
> > > >  file   dev/fdt/simplepanel.c   simplepanel
> > > >  
> > > > +device simplepmbus: fdt
> > > > +attach simplepmbus at fdt
> > > > +file   dev/fdt/simplepmbus.c   simplepmbus
> > > > +
> > > >  device sxiccmu
> > > >  attach sxiccmu at fdt
> > > >  file   dev/fdt/sxiccmu.c   sxiccmu
> > > > Index: share/man/man4/Makefile
> > > > ===
> > > > RCS file: /cvs/src/share/man/man4/Makefile,v
> > > > retrieving revision 1.792
> > > > diff -u -p -r1.792 Makefile
> > > > --- share/man/man4/Makefile 4 Feb 2021 16:25:38 -   1.792
> > > > +++ share/man/man4/Makefile 17 Feb 2021 00:49:02 -
> > > > @@ -72,7 +72,8 @@ MAN=  aac.4 abcrtc.4 abl.4 ac97.4 acphy.4
> > > > rl.4 rlphy.4 route.4 rsu.4 rtsx.4 rum.4 run.4 rtw.4 rtwn.4 \
> > > > safe.4 safte.4 sbus.4 schsio.4 scsi.4 sd.4 \
> > > > sdmmc.4 sdhc.4 se.4 ses.4 sf.4 sili.4 \
> > > > -   simpleamp.4 simpleaudio.4 simplefb.4 simplepanel.4 siop.4 sis.4 
> > > > sk.4 \
> > > > +   simpleamp.4 simpleaudio.4 simplefb.4 simplepanel.4 
> > > > simplepmbus.4 \
> > > > +   siop.4 sis.4 sk.4 \
> > > > sm.4 smsc.4 softraid.4 spdmem.4 sdtemp.4 speaker.4 sppp.4 
> > > > sqphy.4 \
> > > > ssdfb.4 st.4 ste.4 stge.4 sti.4 stp.4 sv.4 switch.4 sxiccmu.4 \
> > > > sxidog.4 sximmc.4 sxipio.4 sxipwm.4 sxirsb.4 sxirtc.4 sxisid.4 \
> > > > Index: sys/arch/armv7/conf/GENERIC
> > > > ===
> > > > RCS file: /cvs/src/sys/arch/armv7/conf/GENERIC,v
> > > > retrieving revision 1.134
> > > > diff -u -p -r1.134 GENERIC
> > > > --- sys/arch/armv7/conf/GENERIC 4 Feb 2021 16:25:39 -   1.134
> > > > +++ sys/arch/armv7/conf/GENERIC 17 Feb 2021 00:49:02 -
> > > > @@ -31,6 +31,7 @@ configbsd swap generic
> > > >  # The main bus device
> > > >  mainbus0   at root
> > > >  simplebus* at fdt?
> > > > +simplepmbus*   at fdt?
> > > >  cpu0   at mainbus?
> > > >  
> > > >  # Cortex-A9
> > > > Index: sys/arch/armv7/conf/RAMDISK
> > > > ===
> > > > RCS file: /cvs/src/sys/arch/armv7/conf/RAMDISK,v
> > > > retrieving revision 1.119
> > > > diff -u -p -r1.119 RAMDISK
> > > > --- sys/arch/armv7/conf/RAMDISK 18 Jun 2020 08:48:04 -  1.119
> > > > +++ sys/arch/armv7/conf/RAMDISK 17 Feb 2021 00:49:02 -
> > > > @@ -30,6 +30,7 @@ configbsd root on rd0a swap on rd0b
> > > >  mainbus0   at root
> > > >  softraid0  at root
> > > >  simplebus* at f

Re: add simplepmbus(4)

2021-02-17 Thread Jonathan Gray
On Wed, Feb 17, 2021 at 10:33:18AM +0100, Patrick Wildt wrote:
> Am Wed, Feb 17, 2021 at 11:56:16AM +1100 schrieb Jonathan Gray:
> > Add a driver for "simple-pm-bus" a way to enable a clock and/or
> > power domain for a group of devices.
> > 
> > https://www.kernel.org/doc/Documentation/devicetree/bindings/bus/simple-pm-bus.txt
> > 
> > This is needed to use am335x/omap4 dtbs from linux 5.11.
> 
> "A Simple Power-Managed Bus is a transparent bus that doesn't need a real
> driver, as it's typically initialized by the boot loader."
> 
> That's a bit funny though. :-)  But I think they meant "it doesn't need
> a real driver, apart from the generic simple-pm-bus driver".
> 
> 
> > Index: sys/dev/fdt/files.fdt
> > ===
> > RCS file: /cvs/src/sys/dev/fdt/files.fdt,v
> > retrieving revision 1.146
> > diff -u -p -r1.146 files.fdt
> > --- sys/dev/fdt/files.fdt   5 Feb 2021 00:05:20 -   1.146
> > +++ sys/dev/fdt/files.fdt   17 Feb 2021 00:49:02 -
> > @@ -23,6 +23,10 @@ device   simplepanel
> >  attach simplepanel at fdt
> >  file   dev/fdt/simplepanel.c   simplepanel
> >  
> > +device simplepmbus: fdt
> > +attach simplepmbus at fdt
> > +file   dev/fdt/simplepmbus.c   simplepmbus
> > +
> >  device sxiccmu
> >  attach sxiccmu at fdt
> >  file   dev/fdt/sxiccmu.c   sxiccmu
> > Index: share/man/man4/Makefile
> > ===
> > RCS file: /cvs/src/share/man/man4/Makefile,v
> > retrieving revision 1.792
> > diff -u -p -r1.792 Makefile
> > --- share/man/man4/Makefile 4 Feb 2021 16:25:38 -   1.792
> > +++ share/man/man4/Makefile 17 Feb 2021 00:49:02 -
> > @@ -72,7 +72,8 @@ MAN=  aac.4 abcrtc.4 abl.4 ac97.4 acphy.4
> > rl.4 rlphy.4 route.4 rsu.4 rtsx.4 rum.4 run.4 rtw.4 rtwn.4 \
> > safe.4 safte.4 sbus.4 schsio.4 scsi.4 sd.4 \
> > sdmmc.4 sdhc.4 se.4 ses.4 sf.4 sili.4 \
> > -   simpleamp.4 simpleaudio.4 simplefb.4 simplepanel.4 siop.4 sis.4 sk.4 \
> > +   simpleamp.4 simpleaudio.4 simplefb.4 simplepanel.4 simplepmbus.4 \
> > +   siop.4 sis.4 sk.4 \
> > sm.4 smsc.4 softraid.4 spdmem.4 sdtemp.4 speaker.4 sppp.4 sqphy.4 \
> > ssdfb.4 st.4 ste.4 stge.4 sti.4 stp.4 sv.4 switch.4 sxiccmu.4 \
> > sxidog.4 sximmc.4 sxipio.4 sxipwm.4 sxirsb.4 sxirtc.4 sxisid.4 \
> > Index: sys/arch/armv7/conf/GENERIC
> > ===
> > RCS file: /cvs/src/sys/arch/armv7/conf/GENERIC,v
> > retrieving revision 1.134
> > diff -u -p -r1.134 GENERIC
> > --- sys/arch/armv7/conf/GENERIC 4 Feb 2021 16:25:39 -   1.134
> > +++ sys/arch/armv7/conf/GENERIC 17 Feb 2021 00:49:02 -
> > @@ -31,6 +31,7 @@ configbsd swap generic
> >  # The main bus device
> >  mainbus0   at root
> >  simplebus* at fdt?
> > +simplepmbus*   at fdt?
> >  cpu0   at mainbus?
> >  
> >  # Cortex-A9
> > Index: sys/arch/armv7/conf/RAMDISK
> > ===
> > RCS file: /cvs/src/sys/arch/armv7/conf/RAMDISK,v
> > retrieving revision 1.119
> > diff -u -p -r1.119 RAMDISK
> > --- sys/arch/armv7/conf/RAMDISK 18 Jun 2020 08:48:04 -  1.119
> > +++ sys/arch/armv7/conf/RAMDISK 17 Feb 2021 00:49:02 -
> > @@ -30,6 +30,7 @@ configbsd root on rd0a swap on rd0b
> >  mainbus0   at root
> >  softraid0  at root
> >  simplebus* at fdt?
> > +simplepmbus*   at fdt?
> >  cpu0   at mainbus?
> >  
> >  # Cortex-A9
> > --- /dev/null   Wed Feb 17 11:49:05 2021
> > +++ sys/dev/fdt/simplepmbus.c   Tue Feb 16 17:24:55 2021
> > @@ -0,0 +1,62 @@
> > +/* $OpenBSD$   */
> > +/*
> > + * Copyright (c) 2021 Jonathan Gray 
> > + *
> > + * 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 RE

add simplepmbus(4)

2021-02-16 Thread Jonathan Gray
Add a driver for "simple-pm-bus" a way to enable a clock and/or
power domain for a group of devices.

https://www.kernel.org/doc/Documentation/devicetree/bindings/bus/simple-pm-bus.txt

This is needed to use am335x/omap4 dtbs from linux 5.11.

Index: sys/dev/fdt/files.fdt
===
RCS file: /cvs/src/sys/dev/fdt/files.fdt,v
retrieving revision 1.146
diff -u -p -r1.146 files.fdt
--- sys/dev/fdt/files.fdt   5 Feb 2021 00:05:20 -   1.146
+++ sys/dev/fdt/files.fdt   17 Feb 2021 00:49:02 -
@@ -23,6 +23,10 @@ device   simplepanel
 attach simplepanel at fdt
 file   dev/fdt/simplepanel.c   simplepanel
 
+device simplepmbus: fdt
+attach simplepmbus at fdt
+file   dev/fdt/simplepmbus.c   simplepmbus
+
 device sxiccmu
 attach sxiccmu at fdt
 file   dev/fdt/sxiccmu.c   sxiccmu
Index: share/man/man4/Makefile
===
RCS file: /cvs/src/share/man/man4/Makefile,v
retrieving revision 1.792
diff -u -p -r1.792 Makefile
--- share/man/man4/Makefile 4 Feb 2021 16:25:38 -   1.792
+++ share/man/man4/Makefile 17 Feb 2021 00:49:02 -
@@ -72,7 +72,8 @@ MAN=  aac.4 abcrtc.4 abl.4 ac97.4 acphy.4
rl.4 rlphy.4 route.4 rsu.4 rtsx.4 rum.4 run.4 rtw.4 rtwn.4 \
safe.4 safte.4 sbus.4 schsio.4 scsi.4 sd.4 \
sdmmc.4 sdhc.4 se.4 ses.4 sf.4 sili.4 \
-   simpleamp.4 simpleaudio.4 simplefb.4 simplepanel.4 siop.4 sis.4 sk.4 \
+   simpleamp.4 simpleaudio.4 simplefb.4 simplepanel.4 simplepmbus.4 \
+   siop.4 sis.4 sk.4 \
sm.4 smsc.4 softraid.4 spdmem.4 sdtemp.4 speaker.4 sppp.4 sqphy.4 \
ssdfb.4 st.4 ste.4 stge.4 sti.4 stp.4 sv.4 switch.4 sxiccmu.4 \
sxidog.4 sximmc.4 sxipio.4 sxipwm.4 sxirsb.4 sxirtc.4 sxisid.4 \
Index: sys/arch/armv7/conf/GENERIC
===
RCS file: /cvs/src/sys/arch/armv7/conf/GENERIC,v
retrieving revision 1.134
diff -u -p -r1.134 GENERIC
--- sys/arch/armv7/conf/GENERIC 4 Feb 2021 16:25:39 -   1.134
+++ sys/arch/armv7/conf/GENERIC 17 Feb 2021 00:49:02 -
@@ -31,6 +31,7 @@ configbsd swap generic
 # The main bus device
 mainbus0   at root
 simplebus* at fdt?
+simplepmbus*   at fdt?
 cpu0   at mainbus?
 
 # Cortex-A9
Index: sys/arch/armv7/conf/RAMDISK
===
RCS file: /cvs/src/sys/arch/armv7/conf/RAMDISK,v
retrieving revision 1.119
diff -u -p -r1.119 RAMDISK
--- sys/arch/armv7/conf/RAMDISK 18 Jun 2020 08:48:04 -  1.119
+++ sys/arch/armv7/conf/RAMDISK 17 Feb 2021 00:49:02 -
@@ -30,6 +30,7 @@ configbsd root on rd0a swap on rd0b
 mainbus0   at root
 softraid0  at root
 simplebus* at fdt?
+simplepmbus*   at fdt?
 cpu0   at mainbus?
 
 # Cortex-A9
--- /dev/null   Wed Feb 17 11:49:05 2021
+++ sys/dev/fdt/simplepmbus.c   Tue Feb 16 17:24:55 2021
@@ -0,0 +1,62 @@
+/* $OpenBSD$   */
+/*
+ * Copyright (c) 2021 Jonathan Gray 
+ *
+ * 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.
+ */
+
+#include 
+#include 
+
+#include 
+
+#include 
+#include 
+#include 
+
+#include 
+
+intsimplepmbus_match(struct device *, void *, void *);
+void   simplepmbus_attach(struct device *, struct device *, void *);
+
+struct simplepmbus_softc {
+   struct simplebus_softc sc_bus;
+};
+
+struct cfattach simplepmbus_ca = {
+   sizeof(struct simplepmbus_softc), simplepmbus_match, simplepmbus_attach
+};
+
+struct cfdriver simplepmbus_cd = {
+   NULL, "simplepmbus", DV_DULL
+};
+
+int
+simplepmbus_match(struct device *parent, void *cfdata, void *aux)
+{
+   struct fdt_attach_args *faa = aux;
+
+   return OF_is_compatible(faa->fa_node, "simple-pm-bus");
+}
+
+void
+simplepmbus_attach(struct device *parent, struct device *self, void *aux)
+{
+   struct simplepmbus_softc *sc = (struct simplepmbus_softc *)self;
+   struct fdt_attach_args *faa = aux;
+
+   power_domain_enable(faa->fa_node);
+   clock_enable_all(faa->fa_node);
+
+   simplebus_attach(parent, >sc_bus.sc_dev, faa);
+}
--- /dev/null   Wed Feb 17 11:49:07 2021
+++ share/man/man4/simplep

Re: some Ryzen, AMD 500 Chipset, Navi 10 and Kingson pcidev

2021-02-15 Thread Jonathan Gray
On Mon, Feb 08, 2021 at 10:48:26AM +0100, Sven Wolf wrote:
> Hi,
> 
> thanks for your fast response.
> I've chosen "AMD 17_3X_IOMMU" instead of "Starship/Matisse" because in my
> point of view, also the other Ryzen Zen 2 pci devices were named 17_3x (e.g.
> PCI_PRODUCT_AMD_17_3X_RC 0x1480 /* 17h/3xh Root Complex */)

family 17h model 31h is used by zen 2 based epyc 'rome' and
family 17h model 71h is used by zen 2 based desktop ryzen 'matisse'

As you have a 17_7X I'd go with using that and not specifying the model
in the string.

> 
> Maybe I'm wrong, but we should choose the same descriptions for all of the
> Ryzen/Zen devices. We should take the code name e.g. Starship/Matisse or we
> should take the vendor codes e.g. 17h/3x
> (http://developer.amd.com/wp-content/resources/56323-PUB_0.74.pdf) but we
> should not mix them.
> 
> Regarding to the NAVI10 entry. In my case its an RX5700.
> For me it's not clear, when we choose the architecture name and when we
> choose the product name in the pcidevs :(
> I find both of them in the pcidevs
> E.g.
> definePCI_PRODUCT_ATI_RADEON_HD7990   0x679b /* Radeon HD 7990 */
> definePCI_PRODUCT_ATI_TAHITI_50x679f  /* Tahiti */

A product name is preferred but the product names often need
another number like revision id to be identified.

see the table in
https://gitlab.freedesktop.org/mesa/drm/-/blob/master/data/amdgpu.ids
/usr/X11R6/share/libdrm/amdgpu.ids

For example 0x731f
731F,   C0, AMD Radeon RX 5700 XT 50th Anniversary
731F,   C1, AMD Radeon RX 5700 XT
731F,   C2, AMD Radeon RX 5600M
731F,   C3, AMD Radeon RX 5700M
731F,   C4, AMD Radeon RX 5700
731F,   C5, AMD Radeon RX 5700 XT
731F,   CA, AMD Radeon RX 5600 XT
731F,   CB, AMD Radeon RX 5600 OEM

and generally these names aren't known till sometime after the codenames
are known.  Recently AMD have started doing codenames for codenames,
for example Sienna_Cichlid for Navi 21.

how about this?

Index: pcidevs
===
RCS file: /cvs/src/sys/dev/pci/pcidevs,v
retrieving revision 1.1955
diff -u -p -r1.1955 pcidevs
--- pcidevs 14 Feb 2021 17:20:47 -  1.1955
+++ pcidevs 16 Feb 2021 05:14:35 -
@@ -346,6 +346,7 @@ vendor  AMPERE  0x1def  Ampere
 vendor SSSTC   0x1e95  SSSTC
 vendor TEHUTI  0x1fc9  Tehuti Networks
 vendor SUNIX2  0x1fd4  Sunix
+vendor KINGSTON0x2646  Kingston
 vendor HINT0x3388  Hint
 vendor 3DLABS  0x3d3d  3D Labs
 vendor AVANCE2 0x4005  Avance Logic
@@ -722,6 +723,14 @@ product AMD 15_3X_PCIE_1   0x1424  15h PCIE
 product AMD 15_3X_PCIE_2   0x1425  15h PCIE
 product AMD 15_3X_PCIE_3   0x1426  15h PCIE
 product AMD 16_PCIE0x1439  16h PCIE
+product AMD 17_7X_DF_1 0x1440  17h Data Fabric
+product AMD 17_7X_DF_2 0x1441  17h Data Fabric
+product AMD 17_7X_DF_3 0x1442  17h Data Fabric
+product AMD 17_7X_DF_4 0x1443  17h Data Fabric
+product AMD 17_7X_DF_5 0x1444  17h Data Fabric
+product AMD 17_7X_DF_6 0x1445  17h Data Fabric
+product AMD 17_7X_DF_7 0x1446  17h Data Fabric
+product AMD 17_7X_DF_8 0x1447  17h Data Fabric
 product AMD 17_6X_DF_0 0x1448  17h/6xh Data Fabric
 product AMD 17_6X_DF_1 0x1449  17h/6xh Data Fabric
 product AMD 17_6X_DF_2 0x144a  17h/6xh Data Fabric
@@ -750,9 +759,14 @@ product AMD 17_DF_80x1467  17h Data Fab
 product AMD 17_CCP_2   0x1468  17h Crypto
 product AMD 17_PCIE_4  0x1470  17h PCIE
 product AMD 17_PCIE_5  0x1471  17h PCIE
-product AMD 17_3X_RC   0x1480  17h/3xh Root Complex
-product AMD 17_3X_CCP  0x1486  17h/3xh Crypto
-product AMD 17_3X_HDA  0x1487  17h/3xh HD Audio
+product AMD 17_3X_RC   0x1480  17h Root Complex
+product AMD 17_7X_IOMMU0x1481  17h IOMMU
+product AMD 17_7X_HB   0x1482  17h Host
+product AMD 17_7X_PCIE_1   0x1483  17h PCIE
+product AMD 17_7X_PCIE_2   0x1484  17h PCIE
+product AMD 17_3X_CCP  0x1486  17h Crypto
+product AMD 17_3X_HDA  0x1487  17h HD Audio
+product AMD 17_7X_XHCI 0x149c  17h xHCI
 product AMD 14_HB  0x1510  14h Host
 product AMD 14_PCIE_1  0x1512  14h PCIE
 product AMD 14_PCIE_2  0x1513  14h PCIE
@@ -861,6 +875,10 @@ product AMD 400SERIES_PCIE_1   0x43c6  400 
 product AMD 400SERIES_PCIE_2   0x43c7  400 Series PCIE
 product AMD 400SERIES_AHCI 0x43c8  400 Series AHCI
 product AMD 400SERIES_XHCI 0x43d0  400 Series xHCI
+product AMD 500SERIES_PCIE_1   0x43e9  500 Series PCIE
+product AMD 500SERIES_PCIE_2   0x43ea  500 Series PCIE
+product AMD 500SERIES_AHCI 0x43eb  500 Series AHCI
+product AMD 500SERIES_XHCI 0x43ee  500 Series xHCI
 /* http://www.amd.com/products/cpg/athlon/techdocs/pdf/21910.pdf */
 product AMD SC751_SC   0x7006  751 System
 product AMD 

Re: some Ryzen, AMD 500 Chipset, Navi 10 and Kingson pcidev

2021-02-07 Thread Jonathan Gray
On Sun, Feb 07, 2021 at 07:58:52PM +0100, Sven Wolf wrote:
> Hi,
> 
> I've added some Ryzen 3xxx, AMD 500 Chipset, Navi 10 and Kingston ids to
> pcidev. I've taken the description from the Linux PCI device ids
> https://pci-ids.ucw.cz/v2.2/pci.ids
> 
> ok?

Can you show a dmesg?  Many of these don't make sense and I can't
find them publically documented by amd.

> 
> Index: pcidevs
> ===
> RCS file: /cvs/src/sys/dev/pci/pcidevs,v
> retrieving revision 1.1954
> diff -u -p -r1.1954 pcidevs
> --- pcidevs   31 Jan 2021 10:51:53 -  1.1954
> +++ pcidevs   7 Feb 2021 18:48:53 -
> @@ -346,6 +346,7 @@ vendorAMPERE  0x1def  Ampere
>  vendor   SSSTC   0x1e95  SSSTC
>  vendor   TEHUTI  0x1fc9  Tehuti Networks
>  vendor   SUNIX2  0x1fd4  Sunix
> +vendor   KINGSTON0x2646  Kingston
>  vendor   HINT0x3388  Hint
>  vendor   3DLABS  0x3d3d  3D Labs
>  vendor   AVANCE2 0x4005  Avance Logic
> @@ -722,6 +723,14 @@ product AMD 15_3X_PCIE_1 0x1424  15h PCIE
>  product AMD 15_3X_PCIE_2 0x1425  15h PCIE
>  product AMD 15_3X_PCIE_3 0x1426  15h PCIE
>  product AMD 16_PCIE  0x1439  16h PCIE
> +product AMD 17_3X_DEV_1  0x1440  17h/3xh Device 24
> +product AMD 17_3X_DEV_2  0x1441  17h/3xh Device 24
> +product AMD 17_3X_DEV_3  0x1442  17h/3xh Device 24
> +product AMD 17_3X_DEV_4  0x1443  17h/3xh Device 24
> +product AMD 17_3X_DEV_5  0x1444  17h/3xh Device 24
> +product AMD 17_3X_DEV_6  0x1445  17h/3xh Device 24
> +product AMD 17_3X_DEV_7  0x1446  17h/3xh Device 24
> +product AMD 17_3X_DEV_8  0x1447  17h/3xh Device 24

"Device 24"?

I would expect desktop Ryzen 3xxx to be 17h/71h.

>  product AMD 17_6X_DF_0   0x1448  17h/6xh Data Fabric
>  product AMD 17_6X_DF_1   0x1449  17h/6xh Data Fabric
>  product AMD 17_6X_DF_2   0x144a  17h/6xh Data Fabric
> @@ -751,6 +760,10 @@ product AMD 17_CCP_2 0x1468  17h Crypto
>  product AMD 17_PCIE_40x1470  17h PCIE
>  product AMD 17_PCIE_50x1471  17h PCIE
>  product AMD 17_3X_RC 0x1480  17h/3xh Root Complex
> +product AMD 17_3X_IOMMU  0x1481  17h/3xh IOMMU
> +product AMD 17_3X_PCIE_1 0x1482  17h/3xh PCIE
> +product AMD 17_3X_GPP_1  0x1483  17h/3xh GPP
> +product AMD 17_3X_GPP_2  0x1484  17h/3xh GPP
>  product AMD 17_3X_CCP0x1486  17h/3xh Crypto
>  product AMD 17_3X_HDA0x1487  17h/3xh HD Audio
>  product AMD 14_HB0x1510  14h Host
> @@ -861,6 +874,10 @@ product AMD 400SERIES_PCIE_1 0x43c6  400
>  product AMD 400SERIES_PCIE_2 0x43c7  400 Series PCIE
>  product AMD 400SERIES_AHCI   0x43c8  400 Series AHCI
>  product AMD 400SERIES_XHCI   0x43d0  400 Series xHCI
> +product AMD 500SERIES_AHCI   0x43eb  500 Series AHCI
> +product AMD 500SERIES_XHCI   0x43ee  500 Series xHCI
> +product AMD 500SERIES_PCIE_1 0x43e9  500 Series PCI Bridge
> +product AMD 500SERIES_PCIE_2 0x43ea  500 Series PCI Bridge
>  /* http://www.amd.com/products/cpg/athlon/techdocs/pdf/21910.pdf */
>  product AMD SC751_SC 0x7006  751 System
>  product AMD SC751_PPB0x7007  751
> @@ -1150,6 +1167,8 @@ product ATI KAVERI_19   0x1318  Kaveri Rad
>  product ATI KAVERI_200x131b  Kaveri Radeon R4
>  product ATI KAVERI_210x131c  Kaveri Radeon R7
>  product ATI KAVERI_220x131d  Kaveri Radeon R6
> +product ATI NAVI10_9 0x1478  Radeon RX5000
> +product ATI NAVI10_100x1479  Radeon RX5000

Where are these from?  They are not matched in amdgpu.

>  product ATI PICASSO  0x15d8  Picasso
>  product ATI RAVEN_VEGA   0x15dd  Radeon Vega
>  product ATI RAVEN_VEGA_HDA   0x15de  Radeon Vega HD Audio
> @@ -6190,6 +6209,9 @@ product JMICRON SD_20x2391  SD Host Con
>  product JMICRON SDMMC_2  0x2392  SD/MMC
>  product JMICRON MS_2 0x2393  Memory Stick
>  product JMICRON XD_2 0x2394  xD
> +
> +/* KINGSTON */
> +product KINGSTON A2000   0x2263  A2000 NVMe
> 
>  /* KTI */
>  product KTI KTIE 0x3000  KTI
> 
> 
> Best regards,
> Sven
> 
> 



Re: execve -1 errno 12 Cannot allocate memory

2021-01-29 Thread Jonathan Gray
On Fri, Jan 29, 2021 at 09:48:42AM -0500, Philippe Meunier wrote:
> Philippe Meunier wrote:
> >Is there some kind of limitation on the size of an ELF executable that can
> >be executed on i386?  I mean, in addition to the limits in /etc/login.conf?
> 
> When using readelf(1) on the chrome executable from
> chromium-81.0.4044.138.tgz from OpenBSD 6.7-release i386 packages, I get:
> 
> Section Headers:
>   [Nr] Name  TypeAddr OffSize   ES Flg Lk Inf 
> Al
> [...]
>   [15] .text PROGBITS0230d000 230d000 7bda799 00  AX  0 0 
> 64
> 
> 7bda799 is 129869721 which is 123.8 MB.
> 
> On the chrome executable from chromium-85.0.4183.121.tgz from OpenBSD
> 6.8-release i386 packages, I get:
> 
> Section Headers:
>   [Nr] Name  TypeAddr OffSize   ES Flg Lk Inf 
> Al
> [...]
>   [15] .text PROGBITS02412c00 2411c00 83b048b 00  AX  0 0 
> 64
> 
> 83b048b is 138085515 which is 131.7 MB.
> 
> Is there somewhere a 128 MB limit for ELF sections on i386, or something
> along those lines?
> 
> Philippe

MAXTSIZ is 128 MB on i386
see sys/arch/i386/include/vmparam.h



Re: df(1): formatting adjustments and -T support

2021-01-23 Thread Jonathan Gray
On Fri, Jan 22, 2021 at 11:11:27PM -0600, Katherine Rohl wrote:
> I noticed that large disk volumes cause problems with the formatting of
> numerical columns in df(1), particularly when using -i. Here's a patch
> that pads out their width a bit and raises the maximum width of
> numerical columns before fields start running into each other.
> 
> I also added support for the -T argument, which is present in many
> other df(1) implementations and shows the filesystem's type.

The type is already available in the output of mount(8).  Flags being
available elsewhere isn't normally a good reason to add them here.

> 
> POSIX-style -P output is not affected by this since it has a specific
> format. The affected flags don't support -P anyway.
> 
> I believe this follows the KNF style (at least that's what my editor
> says) but if there are any problems please let me know.

Your mail client has line wrapped the patch.  If you can disable that
for future patches it would make them easier to apply.

> 
> diff --git bin/df/df.1 bin/df/df.1
> index 89dd51aac8d..4a9a549c492 100644
> --- bin/df/df.1
> +++ bin/df/df.1
> @@ -100,6 +100,10 @@ with the possibly stale statistics that were
> previously obtained.
>  .It Fl P
>  Print out information in a stricter format designed to be parsed
>  by portable scripts.
> +.It Fl T
> +Include the filesystem type. This option is incompatible with the
> +.Fl P
> +option.
>  .It Fl t Ar type
>  Indicate the actions should only be taken on
>  file systems of the specified
> diff --git bin/df/df.c bin/df/df.c
> index fd51f906f89..427d774e802 100644
> --- bin/df/df.c
> +++ bin/df/df.c
> @@ -63,7 +63,7 @@ extern int   e2fs_df(int, char *, struct statfs
> *);
>  extern intffs_df(int, char *, struct statfs *);
>  static intraw_df(char *, struct statfs *);
>  
> -int  hflag, iflag, kflag, lflag, nflag, Pflag;
> +int  hflag, iflag, kflag, lflag, nflag, Pflag, Tflag;
>  char **typelist = NULL;
>  
>  int
> @@ -79,7 +79,7 @@ main(int argc, char *argv[])
>   if (pledge("stdio rpath", NULL) == -1)
>   err(1, "pledge");
>  
> - while ((ch = getopt(argc, argv, "hiklnPt:")) != -1)
> + while ((ch = getopt(argc, argv, "hiklnPTt:")) != -1)
>   switch (ch) {
>   case 'h':
>   hflag = 1;
> @@ -106,14 +106,17 @@ main(int argc, char *argv[])
>   errx(1, "only one -t option may be
> specified.");
>   maketypelist(optarg);
>   break;
> + case 'T':
> + Tflag = 1;
> + break;
>   default:
>   usage();
>   }
>   argc -= optind;
>   argv += optind;
>  
> - if ((iflag || hflag) && Pflag) {
> - warnx("-h and -i are incompatible with -P");
> + if ((iflag || hflag || Tflag) && Pflag) {
> + warnx("-h, -i, and -T are incompatible with -P");
>   usage();
>   }
>  
> @@ -159,13 +162,17 @@ main(int argc, char *argv[])
>   }
>  
>   if (mntsize) {
> - maxwidth = 11;
> + maxwidth = 13;
>   for (i = 0; i < mntsize; i++) {
>   width = strlen(mntbuf[i].f_mntfromname);
>   if (width > maxwidth)
>   maxwidth = width;
> + if (Tflag) {
> + width =
> strlen(mntbuf[i].f_fstypename);
> + if (width > maxwidth)
> + maxwidth = width;
> + }
>   }
> -
>   if (Pflag)
>   posixprint(mntbuf, mntsize, maxwidth);
>   else
> @@ -189,6 +196,20 @@ getmntpt(char *name)
>   return (0);
>  }
>  
> +char *
> +getfsname(char *name)
> +{
> + long mntsize, i;
> + struct statfs *mntbuf;
> +
> + mntsize = getmntinfo(, MNT_NOWAIT);
> + for (i = 0; i < mntsize; i++) {
> + if (!strcmp(mntbuf[i].f_mntfromname, name))
> + return (mntbuf[i].f_fstypename);
> + }
> + return (0);
> +}
> +
>  static enum { IN_LIST, NOT_IN_LIST } which;
>  
>  static int
> @@ -319,20 +340,23 @@ prtstat(struct statfs *sfsp, int maxwidth, int
> headerlen, int blocksize)
>   if (hflag)
>   prthuman(sfsp, used);
>   else
> - (void)printf(" %*llu %9llu %9lld", headerlen,
> + (void)printf(" %*llu %10llu %10lld", headerlen,
>   fsbtoblk(sfsp->f_blocks, sfsp->f_bsize,
> blocksize),
>   fsbtoblk(used, sfsp->f_bsize, blocksize),
>   fsbtoblk(sfsp->f_bavail, sfsp->f_bsize,
> blocksize));
>   (void)printf(" %5.0f%%",
>   availblks == 0 ? 100.0 : (double)used / (double)availblks
> * 100.0);
> + if (Tflag) {
> + (void)printf("%4s", sfsp->f_fstypename);
> + }
>   if (iflag) {
>   inodes = sfsp->f_files;
> 

Re: drm(4) memory allocation diff

2021-01-01 Thread Jonathan Gray
On Thu, Dec 31, 2020 at 10:09:36PM +0100, Mark Kettenis wrote:
> The diff below changes the emulated Linux memory allocation functions
> a bit such that they only use malloc(9) for allocations smaller than a
> page.  This reduces pressure on the "interrupt safe" map and hopefully
> will avoid the
> 
> uvm_mapent_alloc: out of static map entries
> 
> messages that some people have seen more often in the last few months.
> It also could help with some memory allocation issues seem by
> amdgpu(4) users.
> 
> The downside of this approach is that memory leaks will be harder to
> spot as the larger memory allocations are no longer included in the
> DRM type as reported by vmstat -m.  Another downside is that this no
> longer caps the amount of kernel memory that can be allocated by
> drm(4).  If that turns out to be a problem, we can impose a limit on
> the amount of memory that can be allocated this way.
> 
> The implementation needs to keep track of the size of each allocated
> memory block.  This is done using a red-black tree.  Our kernel uses
> red-black trees in similar situations but I wouldn't call myself an
> expert in the area of data structures so a there may be a better
> approach.
> 
> Some real-life testing would be appreciated.
> 

Thanks for looking into this, I'm interested to hear how people go with
it.  Some comments inline below.

> 
> Index: dev/pci/drm/drm_linux.c
> ===
> RCS file: /cvs/src/sys/dev/pci/drm/drm_linux.c,v
> retrieving revision 1.74
> diff -u -p -r1.74 drm_linux.c
> --- dev/pci/drm/drm_linux.c   31 Dec 2020 06:31:55 -  1.74
> +++ dev/pci/drm/drm_linux.c   31 Dec 2020 20:44:38 -
> @@ -430,6 +430,116 @@ dmi_check_system(const struct dmi_system
>   return (num);
>  }
>  
> +struct vmalloc_entry {
> + const void  *addr;
> + size_t  size;
> + RBT_ENTRY(vmalloc_entry) vmalloc_node;
> +};
> +
> +struct pool vmalloc_pool;
> +RBT_HEAD(vmalloc_tree, vmalloc_entry) vmalloc_tree;
> +
> +RBT_PROTOTYPE(vmalloc_tree, vmalloc_entry, vmalloc_node, vmalloc_compare);
> +
> +static inline int
> +vmalloc_compare(const struct vmalloc_entry *a, const struct vmalloc_entry *b)
> +{
> + vaddr_t va = (vaddr_t)a->addr;
> + vaddr_t vb = (vaddr_t)b->addr;
> +
> + return va < vb ? -1 : va > vb;
> +}
> +
> +RBT_GENERATE(vmalloc_tree, vmalloc_entry, vmalloc_node, vmalloc_compare);
> +
> +bool
> +is_vmalloc_addr(const void *addr)
> +{
> + struct vmalloc_entry key;
> + struct vmalloc_entry *entry;
> +
> + key.addr = addr;
> + entry = RBT_FIND(vmalloc_tree, _tree, );
> + return (entry != NULL);
> +}
> +
> +void *
> +vmalloc(unsigned long size)
> +{
> + struct vmalloc_entry *entry;
> + void *addr;
> +
> + size = roundup(size, PAGE_SIZE);

this could just be round_page(size)

> + addr = km_alloc(size, _any, _dirty, _waitok);
> + if (addr) {
> + entry = pool_get(_pool, PR_WAITOK);
> + entry->addr = addr;
> + entry->size = size;
> + RBT_INSERT(vmalloc_tree, _tree, entry);
> + }
> +
> + return addr;
> +}
> +
> +void *
> +vzalloc(unsigned long size)
> +{
> + struct vmalloc_entry *entry;
> + void *addr;
> +
> + size = roundup(size, PAGE_SIZE);
> + addr = km_alloc(size, _any, _zero, _waitok);
> + if (addr) {
> + entry = pool_get(_pool, PR_WAITOK);
> + entry->addr = addr;
> + entry->size = size;
> + RBT_INSERT(vmalloc_tree, _tree, entry);
> + }
> +
> + return addr;
> +}
> +
> +void
> +vfree(const void *addr)
> +{
> + struct vmalloc_entry key;
> + struct vmalloc_entry *entry;
> +
> + key.addr = addr;
> + entry = RBT_FIND(vmalloc_tree, _tree, );
> + if (entry == NULL)
> + panic("%s: non vmalloced addr %p", __func__, addr);
> +
> + RBT_REMOVE(vmalloc_tree, _tree, entry);
> + km_free((void *)addr, entry->size, _any, _dirty);
> + pool_put(_pool, entry);
> +}
> +
> +void *
> +kvmalloc(size_t size, gfp_t flags)
> +{
> + if (flags != GFP_KERNEL || size < PAGE_SIZE)
> + return malloc(size, M_DRM, flags);
> + return vmalloc(size);
> +}
> +
> +void *
> +kvzalloc(size_t size, gfp_t flags)
> +{
> + if (flags != GFP_KERNEL || size < PAGE_SIZE)
> + return malloc(size, M_DRM, flags | M_ZERO);
> + return vzalloc(size);
> +}

these should be (flags & GFP_KERNEL) != GFP_KERNEL to handle calls like

ttm->pages = kvmalloc_array(ttm->num_pages, sizeof(void*),
GFP_KERNEL | __GFP_ZERO);

> +
> +void
> +kvfree(const void *addr)
> +{
> + if (is_vmalloc_addr(addr))
> + vfree(addr);
> + else
> + free((void *)addr, M_DRM, 0);
> +}
> +
>  struct vm_page *
>  alloc_pages(unsigned int gfp_mask, unsigned int order)
>  {
> @@ -1939,6 +2049,10 @@ drm_linux_init(void)
>  
>   pool_init(_pool, sizeof(struct idr_entry), 0, IPL_TTY, 0,
>   

Re: Poison file names

2020-12-13 Thread Jonathan Gray
On Sun, Dec 13, 2020 at 08:02:53PM -0500, Daniel Dickman wrote:
> On Sun, Dec 13, 2020 at 7:51 PM Jonathan Gray  wrote:
> >
> > On Sun, Dec 13, 2020 at 03:44:54PM -0500, Daniel Dickman wrote:
> > >
> > >
> > > On Sat, 12 Dec 2020, Jonathan Gray wrote:
> > >
> > > > games/battlestar/com1.c
> > > > games/battlestar/com2.c
> > > > games/battlestar/com3.c
> > > > games/battlestar/com4.c
> > > > games/battlestar/com5.c
> > > > games/battlestar/com6.c
> > > > games/battlestar/com7.c
> > > > usr.bin/mail/aux.c
> > >
> > > Diff below syncs with netbsd commits from 2001 to avoid filenames that are
> > > reserved on windows.
> > >
> > > for battlestar, rename comX.c --> commandX.c
> > >
> > > for mail, rename aux.c --> support.c
> > >
> > > ok?
> >
> > I don't think it is worth doing without doing all of it.
> 
> there are 3 different issues here, this is 1 of the issues which I
> think should be a stand-alone commit. (note, I do have one ok so far),
> are you saying you're against this one going in? If so, I won't commit
> it.

No, go ahead.  I think aux.c -> util.c like FreeBSD did is nicer
but it doesn't much difference.



Re: Poison file names

2020-12-13 Thread Jonathan Gray
On Sun, Dec 13, 2020 at 03:44:54PM -0500, Daniel Dickman wrote:
> 
> 
> On Sat, 12 Dec 2020, Jonathan Gray wrote:
> 
> > games/battlestar/com1.c
> > games/battlestar/com2.c
> > games/battlestar/com3.c
> > games/battlestar/com4.c
> > games/battlestar/com5.c
> > games/battlestar/com6.c
> > games/battlestar/com7.c
> > usr.bin/mail/aux.c
> 
> Diff below syncs with netbsd commits from 2001 to avoid filenames that are 
> reserved on windows.
> 
> for battlestar, rename comX.c --> commandX.c
> 
> for mail, rename aux.c --> support.c
> 
> ok?

I don't think it is worth doing without doing all of it.
The pod names and regress parts are less straight foward.

> 
> (the file renames are not shown in the diff below)
> 
> 
> Index: games/battlestar/Makefile
> ===
> RCS file: /cvs/src/games/battlestar/Makefile,v
> retrieving revision 1.10
> diff -u -p -u -r1.10 Makefile
> --- games/battlestar/Makefile 25 Nov 2015 23:18:11 -  1.10
> +++ games/battlestar/Makefile 13 Dec 2020 20:33:50 -
> @@ -1,7 +1,8 @@
>  #$OpenBSD: Makefile,v 1.10 2015/11/25 23:18:11 deraadt Exp $
>  
>  PROG=battlestar
> -SRCS=battlestar.c com1.c com2.c com3.c com4.c com5.c com6.c com7.c \
> +SRCS=battlestar.c command1.c command2.c command3.c command4.c \
> + command5.c command6.c command7.c \
>   init.c cypher.c getcom.c parse.c room.c save.c fly.c misc.c \
>   globals.c dayfile.c nightfile.c dayobjs.c nightobjs.c words.c
>  MAN= battlestar.6
> Index: usr.bin/mail/Makefile
> ===
> RCS file: /cvs/src/usr.bin/mail/Makefile,v
> retrieving revision 1.12
> diff -u -p -u -r1.12 Makefile
> --- usr.bin/mail/Makefile 16 Sep 2018 02:38:57 -  1.12
> +++ usr.bin/mail/Makefile 13 Dec 2020 20:33:50 -
> @@ -1,7 +1,7 @@
>  #$OpenBSD: Makefile,v 1.12 2018/09/16 02:38:57 millert Exp $
>  
>  PROG=mail
> -SRCS=version.c aux.c cmd1.c cmd2.c cmd3.c cmdtab.c collect.c \
> +SRCS=version.c support.c cmd1.c cmd2.c cmd3.c cmdtab.c collect.c \
>   edit.c fio.c head.c v7.local.c lex.c list.c main.c names.c \
>   popen.c quit.c send.c strings.c temp.c tty.c vars.c
>  SFILES=  mail.help mail.tildehelp
> 
> 



  1   2   3   4   5   6   7   8   >