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
> 
> 



Re: Poison file names

2020-12-11 Thread Jonathan Gray
On Fri, Dec 11, 2020 at 11:58:10AM -0700, jo...@armadilloaerospace.com wrote:
> I would like to be able to clone the github mirror on windows.  I do
> wind up
> using 7z on the tar file as a workaround, but it would be nice if github
> "just worked".  The com files is what the clone fails on, and those
> seemed
> easy enough to address, but if it is actually a deep rat hole, I
> certainly
> understand.

Besides the names windows objects to there would also be problems with
case collisions.

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
usr.sbin/pkg_add/pod/OpenBSD::Getopt.pod
usr.sbin/pkg_add/pod/OpenBSD::IdCache.pod
usr.sbin/pkg_add/pod/OpenBSD::Intro.pod
usr.sbin/pkg_add/pod/OpenBSD::Mtree.pod
usr.sbin/pkg_add/pod/OpenBSD::PackageName.pod
usr.sbin/pkg_add/pod/OpenBSD::PackingElement.pod
usr.sbin/pkg_add/pod/OpenBSD::PackingList.pod
usr.sbin/pkg_add/pod/OpenBSD::PkgCfl.pod
usr.sbin/pkg_add/pod/OpenBSD::PkgSpec.pod
usr.sbin/pkg_add/pod/OpenBSD::RequiredBy.pod
usr.sbin/pkg_add/pod/OpenBSD::Search.pod
usr.sbin/pkg_add/pod/OpenBSD::State.pod
usr.sbin/pkg_add/pod/OpenBSD::Ustar.pod
usr.sbin/pkg_add/pod/OpenBSD::Vstat.pod
usr.sbin/pkg_add/pod/OpenBSD::md5.pod
usr.sbin/pkg_add/pod/OpenBSD::style.pod

regress/usr.bin/jot/regress.wDn.out
regress/usr.bin/jot/regress.wdn.out
regress/usr.bin/jot/regress.wO.out
regress/usr.bin/jot/regress.wo.out
regress/usr.bin/jot/regress.wU.out
regress/usr.bin/jot/regress.wu.out
regress/usr.bin/mandoc/roff/esc/O.in
regress/usr.bin/mandoc/roff/esc/o.in
regress/usr.bin/mandoc/roff/esc/O.out_ascii
regress/usr.bin/mandoc/roff/esc/o.out_ascii
regress/usr.bin/rcs/rcs-Aflag.out
regress/usr.bin/rcs/rcs-aflag.out
usr.bin/yacc/PSD.doc/ssA
usr.bin/yacc/PSD.doc/ssa
usr.bin/yacc/PSD.doc/ssB
usr.bin/yacc/PSD.doc/ssb



Re: Poison file names

2020-12-09 Thread Jonathan Gray
On Tue, Dec 08, 2020 at 11:36:37PM -0700, jo...@armadilloaerospace.com wrote:
> The game battlestar has source files names com1.c through com7.c, which
> are illegal on windows due to ancient dos com port rules.
> 
> I understand there might not be much sympathy for that, but being able
> to have the full source tree on a windows system can be convenient, and
> it should be a painless change.
> 
> Any chance someone could do that rename in the repository and change
> the Makefile?

NetBSD renamed them all to command for that reason.

https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-file

usr.sbin/pkg_add/pod/OpenBSD::*.pod would also be a problem due to colons



Re: amdgpu(4): use DRM_INFO instead of printf for printing compute unit info

2020-11-30 Thread Jonathan Gray
On Mon, Nov 30, 2020 at 12:02:15AM -0600, Charlie Burnett wrote:
> Doesn’t DRM_INFO output even if DRMDEBUG is enabled? I thought DRM_DEBUG
> only output when debug’s enabled while DRM_INFO is pretty much just a
> wrapper for printk?

Currently DRM_INFO will call into printk which returns early for
KERN_INFO messages if DRMDEBUG is not set, see printk in drm_linux.c.

> 
> Either way, I found the call writing to the GPU register it doesn’t like
> earlier this weekend, but haven’t figured out what exactly it’s having
> issues with. Have a busy week or two but I’ll try to come back to it then!
> Just wanted to send something in case anyone else had a similar issue.

Including the error message you saw would be helpful.

> 
> On Sun, Nov 29, 2020 at 11:25 PM Jonathan Gray  wrote:
> 
> > On Sun, Nov 29, 2020 at 10:17:22PM -0600, Charlie Burnett wrote:
> > > Howdy all,
> > > For reasons that are beyond me, when printf is called in amdgpu_device.c
> > to
> > > print the CU info, it gives me a psp firmware load failure on a Radeon
> > VII
> > > (Vega 20) gpu. Switching the printf statement to a DRM_INFO statement as
> > > used in the rest of amdgpu seems to fix it though.
> >
> > Find what is sensitive to the delay.
> >
> > Hiding this printf under DRMDEBUG makes no sense.  You should be able to
> > load kernels with and without DRMDEBUG.
> >
> > >
> > > ok?
> > >
> > > diff --git sys/dev/pci/drm/amd/amdgpu/amdgpu_device.c
> > > sys/dev/pci/drm/amd/amdgpu/amdgpu_device.c
> > > index 45eff483e86..fba5a7caf23 100644
> > > --- sys/dev/pci/drm/amd/amdgpu/amdgpu_device.c
> > > +++ sys/dev/pci/drm/amd/amdgpu/amdgpu_device.c
> > > @@ -3210,7 +3210,7 @@ fence_driver_init:
> > >   default:
> > >   chip_name = amdgpu_asic_name[adev->asic_type];
> > >   }
> > > - printf("%s: %s %d CU rev 0x%02x\n", adev->self.dv_xname,
> > > + DRM_INFO( "%s: %s %d CU rev 0x%02x\n", adev->self.dv_xname,
> > >  chip_name, adev->gfx.cu_info.number, adev->rev_id);
> > >  }
> > >  #endif
> > >
> >
> >
> 



Re: amdgpu(4): use DRM_INFO instead of printf for printing compute unit info

2020-11-29 Thread Jonathan Gray
On Sun, Nov 29, 2020 at 10:17:22PM -0600, Charlie Burnett wrote:
> Howdy all,
> For reasons that are beyond me, when printf is called in amdgpu_device.c to
> print the CU info, it gives me a psp firmware load failure on a Radeon VII
> (Vega 20) gpu. Switching the printf statement to a DRM_INFO statement as
> used in the rest of amdgpu seems to fix it though.

Find what is sensitive to the delay.

Hiding this printf under DRMDEBUG makes no sense.  You should be able to
load kernels with and without DRMDEBUG.

> 
> ok?
> 
> diff --git sys/dev/pci/drm/amd/amdgpu/amdgpu_device.c
> sys/dev/pci/drm/amd/amdgpu/amdgpu_device.c
> index 45eff483e86..fba5a7caf23 100644
> --- sys/dev/pci/drm/amd/amdgpu/amdgpu_device.c
> +++ sys/dev/pci/drm/amd/amdgpu/amdgpu_device.c
> @@ -3210,7 +3210,7 @@ fence_driver_init:
>   default:
>   chip_name = amdgpu_asic_name[adev->asic_type];
>   }
> - printf("%s: %s %d CU rev 0x%02x\n", adev->self.dv_xname,
> + DRM_INFO( "%s: %s %d CU rev 0x%02x\n", adev->self.dv_xname,
>  chip_name, adev->gfx.cu_info.number, adev->rev_id);
>  }
>  #endif
> 



Re: an(4): tsleep(9) -> tsleep_nsec(9)

2020-11-26 Thread Jonathan Gray
On Tue, Nov 24, 2020 at 07:20:46PM -0600, Scott Cheloha wrote:
> Hi,
> 
> Both kettenis@ and mpi@ have mentioned in private that my proposed
> changes to tsleep_nsec(9) etc. would be nicer if we could just get rid
> of tsleep(9) etc. entirely.
> 
> This is difficult, but I'll try.
> 
> Worst case, we thin out the remaining callers.  There are not many
> left.
> 
> --
> 
> So, an(4) is one such caller.
> 
> In an_wait() we spin for (3 * hz) ticks waiting for CSR_WRITE_2 to
> return the AN_EV_CMD flag.  There is no code handling a case where
> this fails to happen.
> 
> What we do in practice is very nearly equivalent to spinning for 3
> seconds waiting for CSR_WRITE_2 to return the AN_EV_CMD flag, so I
> have converted it to use tsleep_nsec(9).
> 
> This compiles on amd64 but I can't test it.
> 
> Thoughts?  ok?

I don't see why the upper bound would have to be so precise.

Why not just

for (i = 0; i < 3000; i += 100) {
if (CSR_READ_2(sc, AN_EVENT_STAT) & AN_EV_CMD)
break;
tsleep_nsec(sc, PWAIT, "anatch", MSEC_TO_NSEC(100));
}

> 
> Index: an.c
> ===
> RCS file: /cvs/src/sys/dev/ic/an.c,v
> retrieving revision 1.76
> diff -u -p -r1.76 an.c
> --- an.c  10 Jul 2020 13:26:37 -  1.76
> +++ an.c  25 Nov 2020 01:19:16 -
> @@ -678,13 +678,18 @@ an_linkstat_intr(struct an_softc *sc)
>  void
>  an_wait(struct an_softc *sc)
>  {
> - int i;
> + struct timespec now, end;
> +
> + nanouptime();
> + end = now;
> + end.tv_sec += 3;/* spin for at most three seconds */
>  
>   CSR_WRITE_2(sc, AN_COMMAND, AN_CMD_NOOP2);
> - for (i = 0; i < 3*hz; i++) {
> - if (CSR_READ_2(sc, AN_EVENT_STAT) & AN_EV_CMD)
> + while ((CSR_READ_2(sc, AN_EVENT_STAT) & AN_EV_CMD) == 0) {
> + nanouptime();
> + if (timespeccmp(, , <=))
>   break;
> - (void)tsleep(sc, PWAIT, "anatch", 1);
> + tsleep_nsec(sc, PWAIT, "anatch", MSEC_TO_NSEC(10));
>   }
>   CSR_WRITE_2(sc, AN_EVENT_ACK, AN_EV_CMD);
>  }
> 
> 



Re: nm(1): fix error message typo

2020-11-22 Thread Jonathan Gray
On Fri, Nov 20, 2020 at 12:08:55PM -0500, Kris Katterjohn wrote:
> I spotted a little typo in an nm(1) error message.
> 
> Kris Katterjohn
> 

thanks, committed

> 
> Index: elf.c
> ===
> RCS file: /cvs/src/usr.bin/nm/elf.c,v
> retrieving revision 1.37
> diff -u -p -r1.37 elf.c
> --- elf.c 14 Dec 2018 19:56:02 -  1.37
> +++ elf.c 20 Nov 2020 16:55:30 -
> @@ -518,7 +518,7 @@ elf_symload(const char *name, FILE *fp, 
>   }
>  
>   if ((shstr = malloc(shstrsize)) == NULL) {
> - warn("%s: malloc shsrt", name);
> + warn("%s: malloc shstr", name);
>   return (1);
>   }
>  
> 
> 



Re: Screen flickering on ThinkPad X270

2020-11-17 Thread Jonathan Gray
On Wed, Nov 18, 2020 at 01:51:39AM +, Sine Astris wrote:
> Hi,
> 
> I was suffering from a subtle (yet annoying once noticed) problem with
> screen flickering whilst using xenocara on my ThinkPad X270.
> 
> It was only distinctly apparent with certain colours/images being
> displayed, generally a darker (but not black) static background with
> small bright regions changing. For example I could see a subtle
> flicker/brightening of the entire background on each character typed in
> an xterm. It also occasionally manifested (apparently randomly) as a
> subtle flicker which looked like a quick change of brightness.
> 
> After excluding any possible xorg.conf device options, a bit of googling
> turned up some people experiencing a similar issue on windows and linux,
> and they pointed to a feature of newer Intel GPUs called "PSR" / "Panel
> Self Refresh". These issues were resolved via the settings application
> on windows, and on linux machines by setting a linux kernel parameter:
> i915.enable_psr=0
> 
> OpenBSD doesn't appear to expose a mechanism for setting i915
> parameters, so I changed the value from use hardware default to
> disabled within: sys/dev/pci/drm/i915/i915_params.h.
> 
> This resolved the problem completely (which is a great relief, as it's
> frequently apparent once you've noticed it), and doesn't appear to have
> resulted in any other issues.
> 
> Below are a diff to i915_params.h, my xorg.conf, and dmesg. When I get
> time I may see if I'm able to make the required changes to expose this 
> as a flag.

Why have you opted into the intel xorg driver instead of using
the modesetting driver which should be the default for this hardware?
Do you see the same behaviour with the modesetting driver?

The params aren't something we'd make controllable from userspace.
Ideally the problem with PSR would be tracked down so people do not have
to change anything.

> 
> 
> --- /usr/src/sys/dev/pci/drm/i915/i915_params.h   Tue Nov 17 09:50:23 2020
> +++ /usr/src/sys/dev/pci/drm/i915/i915_params.h.new Tue Nov 17 09:30:24 2020
> @@ -52,7 +52,7 @@
>   param(int, vbt_sdvo_panel_type, -1, 0400) \
>   param(int, enable_dc, -1, 0400) \
>   param(int, enable_fbc, -1, 0600) \
> - param(int, enable_psr, -1, 0600) \
> + param(int, enable_psr, 0, 0600) \
>   param(int, disable_power_well, -1, 0400) \
>   param(int, enable_ips, 1, 0600) \
>   param(int, invert_brightness, 0, 0600) \
> 
> 
> [61.711] (WW) checkDevMem: failed to open /dev/xf86 and /dev/mem
>   (Operation not permitted)
>   Check that you have set 'machdep.allowaperture=1'
>   in /etc/sysctl.conf and reboot your machine
>   refer to xf86(4) for details
> [61.711]  linear framebuffer access unavailable
> [61.732] (--) Using wscons driver on /dev/ttyC4
> [61.739] 
> X.Org X Server 1.20.8
> X Protocol Version 11, Revision 0
> [61.739] Build Operating System: OpenBSD 6.8 amd64 
> [61.739] Current Operating System: OpenBSD heliospan.home 6.8 
> GENERIC.MP#1 amd64
> [61.739] Build Date: 17 November 2020  08:48:50PM
> [61.739]  
> [61.739] Current version of pixman: 0.38.4
> [61.739]  Before reporting problems, check http://wiki.x.org
>   to make sure that you have the latest version.
> [61.739] Markers: (--) probed, (**) from config file, (==) default 
> setting,
>   (++) from command line, (!!) notice, (II) informational,
>   (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
> [61.739] (==) Log file: "/var/log/Xorg.0.log", Time: Tue Nov 17 22:33:05 
> 2020
> [61.741] (==) Using config directory: "/etc/X11/xorg.conf.d"
> [61.741] (==) Using system config directory 
> "/usr/X11R6/share/X11/xorg.conf.d"
> [61.743] (==) No Layout section.  Using the first Screen section.
> [61.743] (==) No screen section available. Using defaults.
> [61.743] (**) |-->Screen "Default Screen Section" (0)
> [61.743] (**) |   |-->Monitor ""
> [61.744] (==) No device specified for screen "Default Screen Section".
>   Using the first device section listed.
> [61.744] (**) |   |-->Device "drm"
> [61.744] (==) No monitor specified for screen "Default Screen Section".
>   Using a default monitor configuration.
> [61.744] (==) Automatically adding devices
> [61.744] (==) Automatically enabling devices
> [61.744] (==) Not automatically adding GPU devices
> [61.745] (==) Max clients allowed: 256, resource mask: 0x1f
> [61.751] (==) FontPath set to:
>   /usr/X11R6/lib/X11/fonts/misc/,
>   /usr/X11R6/lib/X11/fonts/TTF/,
>   /usr/X11R6/lib/X11/fonts/OTF/,
>   /usr/X11R6/lib/X11/fonts/Type1/,
>   /usr/X11R6/lib/X11/fonts/100dpi/,
>   /usr/X11R6/lib/X11/fonts/75dpi/
> [61.751] (==) ModulePath set to "/usr/X11R6/lib/modules"
> [61.751] (II) The server relies on wscons to provide the list of input 
> devices.
>   If no devices become available, reconfigure wscons or 

Re: Unable to adjust beep volume on ThinkPad X270

2020-11-17 Thread Jonathan Gray
On Wed, Nov 18, 2020 at 01:41:49AM +, Sine Astris wrote:
> Hi,
> 
> I wasn't able to adjust the volume of the keyboard bell via
> wsconsctl(8), or the volume of /dev/speaker on my ThinkPad X270.
> 
> Additionally, the default spkr_source (mix3) doesn't output the beep.
> Changing to mix2, sounds the beep and my existing audio seems fine.
> 
> # mixerctl outputs.spkr_source=mix2
> 
> I applied the AZ_QRK_WID_BEEP_1D quirk to the Realtek ALC298 codec for
> my devices vendor/product ID, and this seems to have resolved the issue.
> Keyboard bell and /dev/speaker volume adjusts via wsconsctl(8) /
> mixerctl(8)'s inputs.mix_beep=x,x
> 
> Below are diff to azalia_codec.c, pcidump for my audio device, final 
> mixerctl output, and dmesg.

There is no cd audio input so I don't see a need for that quirk.

I see no reason to limit enabling beep as it will be in the same
place for everything with that codec.  Perhaps we should just
enable it for all Realtek codecs.

Index: azalia_codec.c
===
RCS file: /cvs/src/sys/dev/pci/azalia_codec.c,v
retrieving revision 1.182
diff -u -p -r1.182 azalia_codec.c
--- azalia_codec.c  25 Oct 2020 02:54:38 -  1.182
+++ azalia_codec.c  18 Nov 2020 03:43:10 -
@@ -208,6 +208,7 @@ azalia_codec_init_vtbl(codec_t *this)
this->name = "Realtek ALC295";
break;
case 0x10ec0298:
+   this->qrks |= AZ_QRK_WID_BEEP_1D;
this->name = "Realtek ALC298";
if (this->subid == 0x320019e5 ||
this->subid == 0x320119e5)  /* Huawei Matebook X */



Re: Add PCI ids for Intel 2.5Gb adapters

2020-11-15 Thread Jonathan Gray
On Mon, Nov 16, 2020 at 01:44:37PM +0800, Kevin Lo wrote:
> ok?
> 
> Index: sys/dev/pci/pcidevs
> ===
> RCS file: /cvs/src/sys/dev/pci/pcidevs,v
> retrieving revision 1.1942
> diff -u -p -u -p -r1.1942 pcidevs
> --- sys/dev/pci/pcidevs   28 Oct 2020 18:49:03 -  1.1942
> +++ sys/dev/pci/pcidevs   16 Nov 2020 05:41:27 -
> @@ -3485,6 +3485,7 @@ product INTEL I219_LM10 0x0d4e  I219-LM
>  product INTEL I219_V10   0x0d4f  I219-V
>  product INTEL I219_LM12  0x0d53  I219-LM
>  product INTEL I219_V12   0x0d55  I219-V
> +product INTEL I225_IT0x0d9f  I225_IT

string should be I225-IT

>  product INTEL E5V2_HB0x0e00  E5 v2 Host
>  product INTEL E5V2_PCIE_10x0e01  E5 v2 PCIE
>  product INTEL E5V2_PCIE_20x0e02  E5 v2 PCIE
> @@ -3773,6 +3774,11 @@ product INTEL 82441FX  0x1237  82441FX
>  product INTEL 82380AB0x123c  82380AB Mobile ISA
>  product INTEL 82380FB0x124b  82380FB Mobile
>  product INTEL 82439HX0x1250  82439HX
> +product INTEL I226_LM0x125b  I226-LM
> +product INTEL I226_V 0x125c  I226-V
> +product INTEL I226_IT0x125d  I226-IT
> +product INTEL I221_V 0x125e  I221-V
> +product INTEL I226_BLANK_NVM 0x125f  I226
>  product INTEL 82806AA0x1360  82806AA
>  product INTEL 82870P2_PPB0x1460  82870P2 PCIX-PCIX
>  product INTEL 82870P2_IOXAPIC0x1461  82870P2 IOxAPIC
> @@ -3885,11 +3891,16 @@ product INTEL I219_V9 0x15e2  I219-V
>  product INTEL I219_LM5   0x15e3  I219-LM
>  product INTEL X550EM_A_1G_T  0x15e4  X553 SGMII
>  product INTEL X550EM_A_1G_T_L0x15e5  X553 SGMII
> +product INTEL I225_LM0x15f2  I225-LM
> +product INTEL I225_V 0x15f3  I225-V
>  product INTEL I219_LM15  0x15f4  I219-LM
> +product INTEL I220_V 0x15f7  I220-V
> +product INTEL I225_I 0x15f8  I225-I
>  product INTEL I219_LM14  0x15f9  I219-LM
>  product INTEL I219_V14   0x15fa  I219-V
>  product INTEL I219_LM13  0x15fb  I219-LM
>  product INTEL I219_V13   0x15fc  I219-V
> +product INTEL I225_BLANK_NVM 0x15fd  I225
>  product INTEL CORE5G_H_PCIE_X16  0x1601  Core 5G PCIE
>  product INTEL CORE5G_M_GT1_1 0x1602  HD Graphics
>  product INTEL CORE5G_THERM   0x1603  Core 5G Thermal
> @@ -4723,6 +4734,8 @@ product INTEL E5V3_SAD_10x2ffc  E5 v3 SA
>  product INTEL E5V3_SAD_2 0x2ffd  E5 v3 SAD
>  product INTEL E5V3_SAD_3 0x2ffe  E5 v3 SAD
>  product INTEL RCU32  0x3092  RCU32 I2O RAID
> +product INTEL I225_K 0x3100  I225-K
> +product INTEL I225_K20x3101  I225-K2
>  product INTEL 3124   0x3124  3124 SATA
>  product INTEL WL_3165_1  0x3165  Dual Band Wireless AC 3165
>  product INTEL WL_3165_2  0x3166  Dual Band Wireless AC 3165
> @@ -5177,6 +5190,7 @@ product INTEL EP80579_LAN_3 0x5048  EP80
>  product INTEL EP80579_LAN_6  0x5049  EP80579 LAN
>  product INTEL 80960RD0x5200  i960 RD
>  product INTEL PRO_100_SERVER 0x5201  PRO 100 Server
> +product INTEL I225_LMVP  0x5502  I225_LMVP

string should be I225-LMvP
(case from https://downloadmirror.intel.com/29742/eng/readme.txt)

ok jsg@ with those changes

>  product INTEL QEMU_NVME  0x5845  QEMU NVM Express Controller
>  product INTEL CORE7G_S_GT1   0x5902  HD Graphics 610
>  product INTEL CORE7G_U_HB0x5904  Core 7G Host
> 
> 



Re: fix off by one in amdgpu_vm_handle_fault

2020-11-12 Thread Jonathan Gray
On Thu, Nov 12, 2020 at 01:48:05PM +0100, Benjamin Baier wrote:
> Hi
> 
> this fixes the VM_L2_PROTECTION_FAULT_STATUS I was getting.
> (and maybe also some of the bug reports, reporting L2 protection faults)
> It was reproduceable by running
> piglit run quick -t "spec@glsl-1.30@execution@texelfetch fs sampler2d 
> 1x281-501x281" out

Are you sure you see this without that change?  There were changes to
the ttm page fault handling in October which resolved it here.

> 
> > drm:pid57901:gmc_v9_0_process_interrupt *ERROR* [gfxhub0] no-retry page 
> > fault (src_id:0 ring:136 vmid:3 pasid:32820, for process  pid 0 thread 
> > texelFetch pid 12232)
> > drm:pid57901:gmc_v9_0_process_interrupt *ERROR*   in page starting at 
> > address 0x80011138a000 from client 27
> > drm:pid57901:gmc_v9_0_process_interrupt *ERROR* 
> > VM_L2_PROTECTION_FAULT_STATUS:0x003C0111
> > drm:pid57901:gmc_v9_0_process_interrupt *ERROR*  MORE_FAULTS: 0x1
> > drm:pid57901:gmc_v9_0_process_interrupt *ERROR*  WALKER_ERROR: 0x0
> > drm:pid57901:gmc_v9_0_process_interrupt *ERROR*  PERMISSION_FAULTS: 0x1
> > drm:pid57901:gmc_v9_0_process_interrupt *ERROR*  MAPPING_ERROR: 0x1
> > drm:pid57901:gmc_v9_0_process_interrupt *ERROR*  RW: 0x1
> > drm:pid15167:gmc_v9_0_process_interrupt *ERROR* [gfxhub0] retry page fault 
> > (src_id:0 ring:0 vmid:3 pasid:32820, for process  pid 0 thread texelFetch 
> > pid 12232)
> > drm:pid15167:gmc_v9_0_process_interrupt *ERROR*   in page starting at 
> > address 0x80011138 from client 27
> > drm:pid15167:gmc_v9_0_process_interrupt *ERROR* 
> > VM_L2_PROTECTION_FAULT_STATUS:0x003C0071
> > drm:pid15167:gmc_v9_0_process_interrupt *ERROR*  MORE_FAULTS: 0x1
> > drm:pid15167:gmc_v9_0_process_interrupt *ERROR*  WALKER_ERROR: 0x0
> > drm:pid15167:gmc_v9_0_process_interrupt *ERROR*  PERMISSION_FAULTS: 0x7
> > drm:pid15167:gmc_v9_0_process_interrupt *ERROR*  MAPPING_ERROR: 0x0
> > drm:pid15167:gmc_v9_0_process_interrupt *ERROR*  RW: 0x1
> > drm:pid15167:gmc_v9_0_process_interrupt *ERROR* [gfxhub0] no-retry page 
> > fault (src_id:0 ring:152 vmid:3 pasid:32820, for process  pid 0 thread 
> > texelFetch pid 12232)
> > drm:pid15167:gmc_v9_0_process_interrupt *ERROR*   in page starting at 
> > address 0x800111384000 from client 27
> 
> jsg@, kettenis@ an me had some private mails about this a while back
> and I finally found a cure here: 
> https://cgit.freedesktop.org/~agd5f/linux/commit/?h=amd-drm-next-5.11-2020-11-05=19201c075d2ca6a58421aa1f22281977e84ae17f
> 
> Greetings Ben
> 
> Index: amdgpu_vm.c
> ===
> RCS file: /var/cvs/src/sys/dev/pci/drm/amd/amdgpu/amdgpu_vm.c,v
> retrieving revision 1.9
> diff -u -p -r1.9 amdgpu_vm.c
> --- amdgpu_vm.c   13 Jul 2020 06:25:17 -  1.9
> +++ amdgpu_vm.c   11 Nov 2020 16:51:37 -
> @@ -3434,7 +3434,7 @@ bool amdgpu_vm_handle_fault(struct amdgp
>   value = 0;
>   }
>  
> - r = amdgpu_vm_bo_update_mapping(adev, vm, true, NULL, addr, addr + 1,
> + r = amdgpu_vm_bo_update_mapping(adev, vm, true, NULL, addr, addr,
>   flags, value, NULL, NULL);
>   if (r)
>   goto error_unlock;
> 
> 
> ---
> 
> OpenBSD 6.8-current (GENERIC.MP) #11: Wed Nov 11 22:26:53 CET 2020
> b...@fox.netzbasis.de:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 17078054912 (16286MB)
> avail mem = 16545169408 (15778MB)
> random: good seed from bootblocks
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 3.2 @ 0x8f19e000 (94 entries)
> bios0: vendor American Megatrends Inc. version "2002" date 06/18/2020
> bios0: ASUSTeK COMPUTER INC. ROG STRIX B360-G GAMING
> acpi0 at bios0: ACPI 6.1
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP APIC FPDT FIDT MCFG WSMT SSDT SSDT SSDT HPET SSDT 
> SSDT UEFI LPIT SSDT SSDT DBGP DBG2 SSDT BGRT
> acpi0: wakeup devices PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) PEG2(S4) PEGP(S4) 
> SIO1(S3) UAR1(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) 
> RP04(S4) PXSX(S4) [...]
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Core(TM) i3-9100 CPU @ 3.60GHz, 3593.43 MHz, 06-9e-0b
> cpu0: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
> cpu0: 256KB 64b/line 8-way L2 cache
> cpu0: smt 0, core 0, package 0
> mtrr: Pentium Pro MTRR support, 10 var 

Re: add support for AMD 17h/3xh HD Audio

2020-10-22 Thread Jonathan Gray
On Thu, Oct 22, 2020 at 04:34:11PM +0200, Robert Nagy wrote:
> The diff below makes azalia(4) work on my new shiny chromium build box:

You have a 17-31-00 epyc or threadripper?

This id also shows up on
B550, Ryzen 9 3900X 17-71-00
X570, Ryzen 5 3600 17-71-00

The other two 17h/3xh ids also show up on 17-71-00 machines.

It seems they are shared between 17-3x epyc/threadripper and
17-7x ryzen.  I am not aware of any public documents from AMD which
list these devices.

It is surprising your diff would change anything more than dmesg
text.

> 
> Index: dev/pci/azalia_codec.c
> ===
> RCS file: /cvs/src/sys/dev/pci/azalia_codec.c,v
> retrieving revision 1.178
> diff -u -p -u -r1.178 azalia_codec.c
> --- dev/pci/azalia_codec.c  14 Oct 2019 02:04:35 -  1.178
> +++ dev/pci/azalia_codec.c  22 Oct 2020 14:32:55 -
> @@ -222,6 +222,10 @@ azalia_codec_init_vtbl(codec_t *this)
> this->subid == 0x00a0106b)
> this->qrks |= AZ_QRK_WID_OVREF50;
> break;
> +   case 0x10ec0887:
> +   this->name = "Realtek ALC887";
> +   this->qrks |= AZ_QRK_WID_CDIN_1C | AZ_QRK_WID_BEEP_1D;
> +   break;
> case 0x10ec0888:
> this->name = "Realtek ALC888";
> this->qrks |= AZ_QRK_WID_CDIN_1C | AZ_QRK_WID_BEEP_1D;
> Index: dev/pci/pcidevs
> ===
> RCS file: /cvs/src/sys/dev/pci/pcidevs,v
> retrieving revision 1.1939
> diff -u -p -u -r1.1939 pcidevs
> --- dev/pci/pcidevs 7 Oct 2020 11:14:59 -   1.1939
> +++ dev/pci/pcidevs 22 Oct 2020 14:32:56 -
> @@ -751,6 +751,7 @@ 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 14_HB  0x1510  14h Host
>  product AMD 14_PCIE_1  0x1512  14h PCIE
>  product AMD 14_PCIE_2  0x1513  14h PCIE
> Index: dev/pci/pcidevs.h
> ===
> RCS file: /cvs/src/sys/dev/pci/pcidevs.h,v
> retrieving revision 1.1932
> diff -u -p -u -r1.1932 pcidevs.h
> --- dev/pci/pcidevs.h   7 Oct 2020 11:15:31 -   1.1932
> +++ dev/pci/pcidevs.h   22 Oct 2020 14:32:58 -
> @@ -756,6 +756,7 @@
>  #definePCI_PRODUCT_AMD_17_PCIE_5   0x1471  /* 17h PCIE */
>  #definePCI_PRODUCT_AMD_17_3X_RC0x1480  /* 17h/3xh 
> Root Complex */
>  #definePCI_PRODUCT_AMD_17_3X_CCP   0x1486  /* 17h/3xh 
> Crypto */
> +#definePCI_PRODUCT_AMD_17_3X_HDA   0x1487  /* 17h/3xh HD 
> Audio */
>  #definePCI_PRODUCT_AMD_14_HB   0x1510  /* 14h Host */
>  #definePCI_PRODUCT_AMD_14_PCIE_1   0x1512  /* 14h PCIE */
>  #definePCI_PRODUCT_AMD_14_PCIE_2   0x1513  /* 14h PCIE */
> Index: dev/pci/pcidevs_data.h
> ===
> RCS file: /cvs/src/sys/dev/pci/pcidevs_data.h,v
> retrieving revision 1.1927
> diff -u -p -u -r1.1927 pcidevs_data.h
> --- dev/pci/pcidevs_data.h  7 Oct 2020 11:15:31 -   1.1927
> +++ dev/pci/pcidevs_data.h  22 Oct 2020 14:32:59 -
> @@ -1328,6 +1328,10 @@ static const struct pci_known_product pc
> "17h/3xh Crypto",
> },
> {
> +   PCI_VENDOR_AMD, PCI_PRODUCT_AMD_17_3X_HDA,
> +   "17h/3xh HD Audio",
> +   },
> +   {
> PCI_VENDOR_AMD, PCI_PRODUCT_AMD_14_HB,
> "14h Host",
> },
> 
> 



Re: [Patch] Make Azalia recognize audio chipset for Thinkpad T14s

2020-10-21 Thread Jonathan Gray
On Wed, Oct 21, 2020 at 07:32:46PM -0400, Ashton Fagg wrote:
> Jonathan Gray  writes:
> 
> > pcidevs.h is a generated file.  After pcidevs is modified 'make' is run
> > in sys/dev/pci then pcidevs.h and pcidevs_data.h are created based on
> > that.  In this case it is already there though so you don't need to
> > change it.
> 
> Thanks for the review. Updated patch attached. I've rebuilt and tested
> it to ensure it works.
> 

0x1637 / 'Renoir HD Audio' is what would be used for HDMI
audio if that were handled.  audio(4) only attaches to the azalia
device with a product id of 0x15e3 / '17h/1xh HD Audio'

> azalia0 at pci6 dev 0 function 1 "ATI Renoir HD Audio" rev 0x00: msi
> azalia0: no supported codecs

> azalia1 at pci6 dev 0 function 6 "AMD 17h/1xh HD Audio" rev 0x00: apic 33 int 
> 12
> azalia1: codecs: Realtek ALC257
> audio0 at azalia1

I'd go with the below adding the beep quirk if it makes an audible
difference hitting backspace in a vt.

Index: sys/dev/pci/azalia.c
===
RCS file: /cvs/src/sys/dev/pci/azalia.c,v
retrieving revision 1.257
diff -u -p -r1.257 azalia.c
--- sys/dev/pci/azalia.c9 Jun 2020 03:36:05 -   1.257
+++ sys/dev/pci/azalia.c22 Oct 2020 02:05:39 -
@@ -386,6 +386,9 @@ azalia_configure_pci(azalia_t *az)
switch (PCI_PRODUCT(az->pciid)) {
case PCI_PRODUCT_ATI_SB450_HDA:
case PCI_PRODUCT_ATI_SBX00_HDA:
+   case PCI_PRODUCT_AMD_15_6X_AUDIO:
+   case PCI_PRODUCT_AMD_17_HDA:
+   case PCI_PRODUCT_AMD_17_1X_HDA:
case PCI_PRODUCT_AMD_HUDSON2_HDA:
reg = azalia_pci_read(az->pc, az->tag, ATI_PCIE_SNOOP_REG);
reg &= ATI_PCIE_SNOOP_MASK;
Index: sys/dev/pci/azalia_codec.c
===
RCS file: /cvs/src/sys/dev/pci/azalia_codec.c,v
retrieving revision 1.178
diff -u -p -r1.178 azalia_codec.c
--- sys/dev/pci/azalia_codec.c  14 Oct 2019 02:04:35 -  1.178
+++ sys/dev/pci/azalia_codec.c  18 Oct 2020 08:00:10 -
@@ -83,6 +83,9 @@ azalia_codec_init_vtbl(codec_t *this)
this->name = "Realtek ALC221";
this->qrks |= AZ_QRK_WID_CDIN_1C | AZ_QRK_WID_BEEP_1D;
break;
+   case 0x10ec0257:
+   this->name = "Realtek ALC257";
+   break;
case 0x10ec0260:
this->name = "Realtek ALC260";
if (this->subid == 0x008f1025)



Re: [Patch] Make Azalia recognize audio chipset for Thinkpad T14s

2020-10-21 Thread Jonathan Gray
On Wed, Oct 21, 2020 at 06:27:15PM -0400, Ashton Fagg wrote:
> Ashton Fagg  writes:
> 
> > (My first OpenBSD patch - sorry if it's terrible)
> >
> > Attached is a patch to make the audio chipset (Realtek ALC257) in a
> > Thinkpad T14s get recognized by Azalia. It also sets the usual bits
> > that get set for most other devices.
> >
> > Additionally, this also enabled pci-e snooping for the Renoir HDA
> > (definition included in pcidevs.h). I am not sure if this is entirely
> > necessary, I am merely following along with what other patches for
> > similar things have done. Guidance on that would be appreciated.
> >
> > Tested locally, dmesg attached. azalia correctly registers device as
> > "Realtek ALC257".
> 
> 
> Someone was kind enough to point out that I had neglected to KNF the
> patch. Apologies, see attached for a KNF'ed version.

pcidevs.h is a generated file.  After pcidevs is modified 'make' is run
in sys/dev/pci then pcidevs.h and pcidevs_data.h are created based on
that.  In this case it is already there though so you don't need to
change it.

> 

> diff --git a/sys/dev/pci/azalia.c b/sys/dev/pci/azalia.c
> index 36e8ae36d27..9c8d8665b7d 100644
> --- a/sys/dev/pci/azalia.c
> +++ b/sys/dev/pci/azalia.c
> @@ -387,6 +387,7 @@ azalia_configure_pci(azalia_t *az)
>   case PCI_PRODUCT_ATI_SB450_HDA:
>   case PCI_PRODUCT_ATI_SBX00_HDA:
>   case PCI_PRODUCT_AMD_HUDSON2_HDA:
> + case PCI_PRODUCT_AMD_RENOIR_HDA:
>   reg = azalia_pci_read(az->pc, az->tag, ATI_PCIE_SNOOP_REG);
>   reg &= ATI_PCIE_SNOOP_MASK;
>   reg |= ATI_PCIE_SNOOP_ENABLE;
> diff --git a/sys/dev/pci/azalia_codec.c b/sys/dev/pci/azalia_codec.c
> index 33833d2f8ea..9a1e000e5f3 100644
> --- a/sys/dev/pci/azalia_codec.c
> +++ b/sys/dev/pci/azalia_codec.c
> @@ -83,6 +83,10 @@ azalia_codec_init_vtbl(codec_t *this)
>   this->name = "Realtek ALC221";
>   this->qrks |= AZ_QRK_WID_CDIN_1C | AZ_QRK_WID_BEEP_1D;
>   break;
> + case 0x10ec0257:
> + this->name = "Realtek ALC257";
> + this->qrks |= AZ_QRK_WID_CDIN_1C | AZ_QRK_WID_BEEP_1D;
> + break;
>   case 0x10ec0260:
>   this->name = "Realtek ALC260";
>   if (this->subid == 0x008f1025)
> diff --git a/sys/dev/pci/pcidevs.h b/sys/dev/pci/pcidevs.h
> index e5f74e84555..c09b1a6e521 100644
> --- a/sys/dev/pci/pcidevs.h
> +++ b/sys/dev/pci/pcidevs.h
> @@ -946,6 +946,7 @@
>  #define  PCI_PRODUCT_AMD_RS780_PCIE_70x9608  /* RS780 PCIE */
>  #define  PCI_PRODUCT_AMD_RS780_PCIE_80x9609  /* RS780 PCIE */
>  #define  PCI_PRODUCT_AMD_RS780_PCIE_90x960b  /* RS780 PCIE */
> +#define PCI_PRODUCT_AMD_RENOIR_HDA   0x1637  /* Renoir HD Audio */
>  
>  /* AMI */
>  #define  PCI_PRODUCT_AMI_MEGARAID0x1960  /* MegaRAID */



Re: sys/kernel.h: delete dead externs

2020-10-15 Thread Jonathan Gray
On Thu, Oct 15, 2020 at 03:17:22AM -0500, Scott Cheloha wrote:
> Several of the externs in sys/kernel.h are for variables that don't
> exist.  I can't find global declarations for tickfix, tickfixinterval,
> tickdelta, or timedelta.
> 
> ok to delete these?

These went away in 'unifdef -D __HAVE_TIMECOUNTER' from miod in 2012.

ok jsg@

> 
> Index: sys/kernel.h
> ===
> RCS file: /cvs/src/sys/sys/kernel.h,v
> retrieving revision 1.23
> diff -u -p -r1.23 kernel.h
> --- sys/kernel.h  20 May 2020 17:24:17 -  1.23
> +++ sys/kernel.h  15 Oct 2020 08:09:11 -
> @@ -51,13 +51,9 @@ extern int utc_offset; /* seconds east 
>  
>  extern int tick; /* usec per tick (100 / hz) */
>  extern int tick_nsec;/* nsec per tick */
> -extern int tickfix;  /* periodic tick adj. tick not integral */
> -extern int tickfixinterval;  /* interval at which to apply adjustment */
>  extern int tickadj;  /* "standard" clock skew, us./tick */
>  extern int ticks;/* # of hardclock ticks */
>  extern int hz;   /* system clock's frequency */
>  extern int stathz;   /* statistics clock's frequency */
>  extern int profhz;   /* profiling clock's frequency */
>  extern int lbolt;/* once a second sleep address */
> -extern int tickdelta;
> -extern long timedelta;
> 
> 



match on more ure(4) devices

2020-10-03 Thread Jonathan Gray
match on additional device ids from lenovo windows driver
https://download.lenovo.com/consumer/options/thinkpad_usb-c_dock_gen2_drivers_v1.0.3.03241.exe
and linux driver

Index: usbdevs
===
RCS file: /cvs/src/sys/dev/usb/usbdevs,v
retrieving revision 1.720
diff -u -p -r1.720 usbdevs
--- usbdevs 3 Aug 2020 14:25:44 -   1.720
+++ usbdevs 4 Oct 2020 04:47:48 -
@@ -80,6 +80,7 @@ vendor FUJITSUCOMP0x0430  Fujitsu Compon
 vendor TAUGA   0x0436  Taugagreining HF
 vendor AMD 0x0438  Advanced Micro Devices
 vendor LEXMARK 0x043d  Lexmark International
+vendor LG  0x043e  LG USA
 vendor NANAO   0x0440  NANAO
 vendor ALPS0x044e  Alps Electric
 vendor THRUST  0x044f  Thrustmaster
@@ -367,6 +368,7 @@ vendor TOSHIBA  0x0930  Toshiba Corp
 vendor INTREPIDCS  0x093c  Intrepid
 vendor YANO0x094f  Yano
 vendor KINGSTON0x0951  Kingston Technology
+vendor NVIDIA  0x0955  NVIDIA
 vendor BLUEWATER   0x0956  BlueWater Systems
 vendor AGILENT 0x0957  Agilent Technologies
 vendor GUDE0x0959  Gude ADS
@@ -465,6 +467,7 @@ vendor ITEGNO   0x0eba  iTegno
 vendor NORITAKE0x0eda  Noritake itron Corp
 vendor EGALAX  0x0eef  eGalax
 vendor XIRING  0x0f14  XIRING
+vendor IOI 0x0f21  IOI
 vendor AIRPRIME0x0f3d  Airprime
 vendor VTECH   0x0f88  VTech
 vendor FALCOM  0x0f94  Falcom Wireless Communications
@@ -476,6 +479,7 @@ vendor UNKNOWN4 0x0fe6  Unknown Vendor
 vendor DVICO   0x0fe9  DViCO
 vendor QUALCOMM2   0x1004  Qualcomm
 vendor MOTOROLA4   0x100d  Motorola
+vendor TTL 0x1025  Technology Testing Lab
 vendor HP3 0x103c  Hewlett Packard
 vendor THURLBY 0x103e  Thurlby Thandar Instruments
 vendor GIGABYTE0x1044  GIGABYTE
@@ -540,6 +544,7 @@ vendor STARTECH 0x14b0  StarTech.com
 vendor CONCEPTRONIC2   0x14b2  Conceptronic
 vendor SUPERTOP0x14cd  SuperTop
 vendor PLANEX3 0x14ea  Planex Communications
+vendor TWINHEAD0x14ff  Twinhead
 vendor SILICONPORTALS  0x1527  Silicon Portals
 vendor UBLOX   0x1546  U-blox
 vendor OWEN0x1555  Owen
@@ -620,6 +625,7 @@ vendor VERTEX   0x1fe7  Vertex Wireless Co
 vendor DLINK   0x2001  D-Link
 vendor PLANEX2 0x2019  Planex Communications
 vendor ENCORE  0x203d  Encore
+vendor LUXSHARE0x208e  Luxshare
 vendor PARA0x20b8  PARA Industrial
 vendor TRENDNET0x20f4  TRENDnet
 vendor RTSYSTEMS   0x2100  RT Systems
@@ -635,7 +641,11 @@ vendor XIAOMI  0x2717  Xiaomi
 vendor NHJ 0x2770  NHJ
 vendor THINGM  0x27b8  ThingM
 vendor ASUSTEK 0x2821  ASUSTeK Computer
+vendor PIONEERDJ   0x2b73  Pioneer DJ
 vendor PLANEX  0x2c02  Planex Communications
+vendor CLUB3D  0x2d1c  Club 3D
+vendor CLEVO   0x30da  CLEVO
+vendor DYNABOOK0x30f3  Dynabook
 vendor LINKINSTRUMENTS 0x3195  Link Instruments
 vendor AEI 0x3334  AEI
 vendor PQI 0x3538  PQI
@@ -1056,6 +1066,7 @@ product ASUS RTL8192CU0x17ab  RTL8192CU
 product ASUS USBN660x17ad  USB-N66
 product ASUS RTL8192CU_2   0x17ba  RTL8192CU
 product ASUS RTL8192CU_3   0x17c0  RTL8192CU
+product ASUS RTL8156   0x18d1  RTL8156
 product ASUS MYPAL_A7300x4202  MyPal A730
 product ASUS2 USBN11   0x0b05  USB-N11
 
@@ -1194,6 +1205,8 @@ product BELKIN F5U234 0x0234  F5U234 USB
 product BELKIN F5U237  0x0237  F5U237 USB 2.0 7-Port Hub
 product BELKIN F5U257  0x0257  F5U257 Serial
 product BELKIN F6H375  0x0375  F6H375 UPS
+product BELKIN RTL8152B0x047a  RTL8152B
+product BELKIN RTL8153 0x048a  RTL8153
 product BELKIN F5U409  0x0409  F5U409 Serial
 product BELKIN F6C550AVR   0x0551  F6C550-AVR UPS
 product BELKIN F6C1250EITWRK   0x0750  F6C1250EITW-RK UPS
@@ -1336,9 +1349,13 @@ product CISCOLINKSYS WUSBF54G0x0024  WUS
 product CISCOLINKSYS WUSB200   0x0028  WUSB200
 product CISCOLINKSYS AE10000x002f  AE1000
 product CISCOLINKSYS AM10  0x0031  AM10
+product CISCOLINKSYS USB3GIGV1 0x0041  USB3GIGV1
 product CISCOLINKSYS2 RT3070   0x4001  RT3070
 product CISCOLINKSYS3 RT3070   0x0101  RT3070
 
+/* CLEVO products */
+product CLEVO RTL8153B 0x5101  RTL8153B
+
 /* Clipsal products */
 product CLIPSAL 560884 0x0101  560884 C-Bus Switch
 product CLIPSAL 5500PACA   0x0201  5500PACA C-Bus Controller
@@ -1348,6 +1365,9 @@ product CLIPSAL 5000CT2   0x0304  5000CT2 
 product CLIPSAL C5000CT2   0x0305  C5000CT2 C-Bus Touch Screen
 product CLIPSAL L51XX  0x0401  L51xx C-Bus 

Re: [PATCH] Add common PCIE capability list

2020-09-01 Thread Jonathan Gray
On Tue, Sep 01, 2020 at 11:44:03PM -0500, Jordan Hargrave wrote:
> This patch adds a common function for scanning PCIE Express Capability list
> The PCIE Capability list starts at 0x100 in extended PCI configuration space.

This seems to only handle extended capabilities?
Something like pcie_get_ext_capability() would be a better name.

It is 'PCI Express' not 'PCIExpress'

'ofs & 3' test doesn't make sense when PCI_PCIE_ECAP_NEXT() always
masks those bits.

> 
> ---
>  sys/dev/pci/pci.c| 28 
>  sys/dev/pci/pcivar.h |  2 ++
>  2 files changed, 30 insertions(+)
> 
> diff --git a/sys/dev/pci/pci.c b/sys/dev/pci/pci.c
> index bf75f875e..8f9a5ef7a 100644
> --- a/sys/dev/pci/pci.c
> +++ b/sys/dev/pci/pci.c
> @@ -677,6 +677,34 @@ pci_get_ht_capability(pci_chipset_tag_t pc, pcitag_t 
> tag, int capid,
>   return (0);
>  }
>  
> +int
> +pcie_get_capability(pci_chipset_tag_t pc, pcitag_t tag, int capid,
> +int *offset, pcireg_t *value)
> +{
> + pcireg_t reg;
> + unsigned int ofs;
> +
> + /* Make sure we support PCIExpress device */
> + if (pci_get_capability(pc, tag, PCI_CAP_PCIEXPRESS, NULL, NULL) == 0)
> + return (0);
> + /* Scan PCIExpress capabilities */
> + ofs = PCI_PCIE_ECAP;
> + while (ofs != 0) {
> + if ((ofs & 3) || (ofs < PCI_PCIE_ECAP))
> + return (0);
> + reg = pci_conf_read(pc, tag, ofs);
> + if (PCI_PCIE_ECAP_ID(reg) == capid) {
> + if (offset)
> + *offset = ofs;
> + if (value)
> + *value = reg;
> + return (1);
> + }
> + ofs = PCI_PCIE_ECAP_NEXT(reg);
> + }
> + return (0);
> +}
> +
>  uint16_t
>  pci_requester_id(pci_chipset_tag_t pc, pcitag_t tag)
>  {
> diff --git a/sys/dev/pci/pcivar.h b/sys/dev/pci/pcivar.h
> index bdfe0404f..0376ba992 100644
> --- a/sys/dev/pci/pcivar.h
> +++ b/sys/dev/pci/pcivar.h
> @@ -233,6 +233,8 @@ int   pci_io_find(pci_chipset_tag_t, pcitag_t, int, 
> bus_addr_t *,
>  int  pci_mem_find(pci_chipset_tag_t, pcitag_t, int, bus_addr_t *,
>   bus_size_t *, int *);
>  
> +int  pcie_get_capability(pci_chipset_tag_t, pcitag_t, int,
> + int *, pcireg_t *);
>  int  pci_get_capability(pci_chipset_tag_t, pcitag_t, int,
>   int *, pcireg_t *);
>  int  pci_get_ht_capability(pci_chipset_tag_t, pcitag_t, int,
> -- 
> 2.26.2
> 
> 



Re: Enable arm64 PAN feature

2020-08-17 Thread Jonathan Gray
On Sat, Aug 15, 2020 at 01:54:34PM +0200, Mark Kettenis wrote:
> > Date: Sat, 15 Aug 2020 20:21:09 +1000
> > From: Jonathan Gray 
> > 
> > On Fri, Aug 14, 2020 at 11:06:59PM +0200, Mark Kettenis wrote:
> > > > Date: Fri, 14 Aug 2020 14:40:23 +0200 (CEST)
> > > > From: Mark Kettenis 
> > > > 
> > > > I suppose a way to test this properly is to pick a system call and
> > > > replace a copyin() with a direct access?  That will succeed without
> > > > PAN but should fail with PAN enabled right?
> > > 
> > > So that does indeed work.  However, the result is a hard hang.  So
> > > here as an additional diff that makes sure we panic instead.  The idea
> > > is that all user-space access from the kernel should be done by the
> > > special unprivileged load/store instructions.
> > 
> > Would disabling PSTATE.PAN in copyin/copyout along the lines of how
> > stac/clac is done for SMAP avoid having to test the instruction type
> > entirely?
> 
> No.  The problem is that we meed to catch permission faults caused by
> PAN.  But since the faulting address may be valid in the sense that
> UVM has a mapping for them that allows the requested access.  In that
> case we end up looping since uvm_fault() returns 0 and we retry the
> faulting instruction.
> 
> > Is it faulting on valid copyin/copyout the way you have it at the
> > moment?  I don't quite follow what is going on.
> 
> The copyin/copyout functions use the unpriviliged load/store
> instructions (LDTR/STTR) which bypass PAN.  But we may still fault
> because the memory hasn't been faulted in or because the memory has
> been marked read-only for CoW or for MOD/REF emulation.  And some of
> those faults manifest themselves as permission faults as well.
> 
> Currently (without the diff quoted below) those faults will be handled
> just fine.  The diff below needs to make sure this continues to be the
> case.  The easiest way to do that is to check the instruction.
> 
> Note that this check is in the "slow path".  In most cases the address
> touched by copyin/copyout will already be in the page tables since
> userland touched it already.
> 
> Does that clarfify things?

Yes, thanks.  I'm fine with both of these diffs going in but still think
you should change the mask.

> 
> 
> > > Index: arch/arm64/arm64/trap.c
> > > ===
> > > RCS file: /cvs/src/sys/arch/arm64/arm64/trap.c,v
> > > retrieving revision 1.27
> > > diff -u -p -r1.27 trap.c
> > > --- arch/arm64/arm64/trap.c   6 Jan 2020 12:37:30 -   1.27
> > > +++ arch/arm64/arm64/trap.c   14 Aug 2020 21:05:54 -
> > > @@ -65,6 +65,14 @@ void do_el0_error(struct trapframe *);
> > >  
> > >  void dumpregs(struct trapframe*);
> > >  
> > > +/* Check whether we're executing an unprivileged load/store instruction. 
> > > */
> > > +static inline int
> > > +is_unpriv_ldst(uint64_t elr)
> > > +{
> > > + uint32_t insn = *(uint32_t *)elr;
> > > + return ((insn & 0x3f200c00) == 0x38000800);
> > 
> > The value of op1 (bit 26) is not used according to the table in the Arm
> > ARM.  The mask would be better as 0x3b200c00
> > 
> > 
> > > +}
> > > +
> > >  static void
> > >  data_abort(struct trapframe *frame, uint64_t esr, uint64_t far,
> > >  int lower, int exe)
> > > @@ -104,8 +112,18 @@ data_abort(struct trapframe *frame, uint
> > >   /* The top bit tells us which range to use */
> > >   if ((far >> 63) == 1)
> > >   map = kernel_map;
> > > - else
> > > + else {
> > > + /*
> > > +  * Only allow user-space access using
> > > +  * unprivileged load/store instructions.
> > > +  */
> > > + if (!is_unpriv_ldst(frame->tf_elr)) {
> > > + panic("attempt to access user address"
> > > +   " 0x%llx from EL1", far);
> > > + }
> > > +
> > >   map = >p_vmspace->vm_map;
> > > + }
> > >   }
> > >  
> > >   if (exe)
> > > 
> > > 
> > 
> 
> 



Re: radeondrm(4) timing issue

2020-08-16 Thread Jonathan Gray
On Fri, Aug 14, 2020 at 03:00:57PM +0200, Marcus Glocker wrote:
> Hi,
> 
> Recently I took over the old iMac11,2 of my son, and what else to do
> with it other than installing OpenBSD and see what happens.  The first
> thing which happened after the installation was that the screen
> remained dark after the radeondrm(4) KMS initialization.
> 
> After some painful debugging, and exchanging forth and back with jsg@,
> I've noticed that when enabling DRMDEBUG, radeondrm(4) just works fine!
> Smells like a timing issue.
> 
> After doing some more investigations I've figured out that when
> removing a specific debug printf in drm_dp_helper.c, just before an
> usleep_range() statement, it fails again:
> 
>   case DP_AUX_NATIVE_REPLY_DEFER:
> ->  DRM_DEBUG_KMS("native defer\n");
> /*
>  * We could check for I2C bit rate capabilities and if
>  * available adjust this interval. We could also be
>  * more careful with DP-to-legacy adapters where a
>  * long legacy cable may force very low I2C bit rates.
>  *
>  * For now just defer for long enough to hopefully be
>  * safe for all use-cases.
>  */
>  usleep_range(AUX_RETRY_INTERVAL, AUX_RETRY_INTERVAL + 100);
>  continue;
> 
> This usleep_range() expands to usleep_range(500, 600), and we wrap it in
> this function on OpenBSD:
> 
>   static inline void
>   usleep_range(unsigned long min, unsigned long max)
>   {
>   DELAY(min);
>   }
> 
> In my case the 500us was too short, while the 600us works fine.
> 
> Based on that jsg@ told me that there is an discussion on-going to
> change usleep_range() to calculate (min + max) / 2, which would change
> this specific usleep_range() line to 550us, which is enough in my case
> to make radeondrm(4) work fine on my iMac.
> 
> We would like to understand if this diff has any negative impact on
> other devices.  Can you please give it a spin therefore?

While we could increase AUX_RETRY_INTERVAL I prefer this change as linux
in practice seems to always add some about of delay on the minimum.

ok jsg@

> 
> 
> Index: dev/pci/drm/include/linux/delay.h
> ===
> RCS file: /cvs/src/sys/dev/pci/drm/include/linux/delay.h,v
> retrieving revision 1.2
> diff -u -p -u -p -r1.2 delay.h
> --- dev/pci/drm/include/linux/delay.h 8 Jun 2020 04:48:14 -   1.2
> +++ dev/pci/drm/include/linux/delay.h 14 Aug 2020 11:44:43 -
> @@ -20,7 +20,7 @@ ndelay(unsigned long nsecs)
>  static inline void
>  usleep_range(unsigned long min, unsigned long max)
>  {
> - DELAY(min);
> + DELAY((min + max) / 2);
>  }
>  
>  static inline void
> 
> 



Re: Enable arm64 PAN feature

2020-08-15 Thread Jonathan Gray
On Fri, Aug 14, 2020 at 11:06:59PM +0200, Mark Kettenis wrote:
> > Date: Fri, 14 Aug 2020 14:40:23 +0200 (CEST)
> > From: Mark Kettenis 
> > 
> > I suppose a way to test this properly is to pick a system call and
> > replace a copyin() with a direct access?  That will succeed without
> > PAN but should fail with PAN enabled right?
> 
> So that does indeed work.  However, the result is a hard hang.  So
> here as an additional diff that makes sure we panic instead.  The idea
> is that all user-space access from the kernel should be done by the
> special unprivileged load/store instructions.

Would disabling PSTATE.PAN in copyin/copyout along the lines of how
stac/clac is done for SMAP avoid having to test the instruction type
entirely?

Is it faulting on valid copyin/copyout the way you have it at the
moment?  I don't quite follow what is going on.

> 
> Index: arch/arm64/arm64/trap.c
> ===
> RCS file: /cvs/src/sys/arch/arm64/arm64/trap.c,v
> retrieving revision 1.27
> diff -u -p -r1.27 trap.c
> --- arch/arm64/arm64/trap.c   6 Jan 2020 12:37:30 -   1.27
> +++ arch/arm64/arm64/trap.c   14 Aug 2020 21:05:54 -
> @@ -65,6 +65,14 @@ void do_el0_error(struct trapframe *);
>  
>  void dumpregs(struct trapframe*);
>  
> +/* Check whether we're executing an unprivileged load/store instruction. */
> +static inline int
> +is_unpriv_ldst(uint64_t elr)
> +{
> + uint32_t insn = *(uint32_t *)elr;
> + return ((insn & 0x3f200c00) == 0x38000800);

The value of op1 (bit 26) is not used according to the table in the Arm
ARM.  The mask would be better as 0x3b200c00


> +}
> +
>  static void
>  data_abort(struct trapframe *frame, uint64_t esr, uint64_t far,
>  int lower, int exe)
> @@ -104,8 +112,18 @@ data_abort(struct trapframe *frame, uint
>   /* The top bit tells us which range to use */
>   if ((far >> 63) == 1)
>   map = kernel_map;
> - else
> + else {
> + /*
> +  * Only allow user-space access using
> +  * unprivileged load/store instructions.
> +  */
> + if (!is_unpriv_ldst(frame->tf_elr)) {
> + panic("attempt to access user address"
> +   " 0x%llx from EL1", far);
> + }
> +
>   map = >p_vmspace->vm_map;
> + }
>   }
>  
>   if (exe)
> 
> 



Re: Enable arm64 PAN feature

2020-08-13 Thread Jonathan Gray
On Thu, Aug 13, 2020 at 09:17:41PM +0200, Mark Kettenis wrote:
> ARMv8.1 introduced PAN (Priviliged Access Never) which prevents the
> kernel from accessing userland data.  This can be bypassed by using
> special instructions which we already use in copyin(9) and friends.
> So we can simply turn this feature on if the CPU supports it.
> 
> Tested on an Odroid-C4 which has Cortex-A55 cores that have PAN
> support.
> 
> ok?

This should be changing PSTATE.PAN as well.  Can you force an
acess of this type to be sure the permission fault occurs?

>From the Arm ARM:

"When the value of PSTATE.PAN is 1, any privileged data access from
EL1, or EL2 when HCR_EL2.E2H is 1, to a virtual memory address that
is accessible at EL0, generates a Permission fault.

When the value of PSTATE.PAN is 0, the translation system is the
same as in Armv8.0.

When ARMv8.1-PAN is implemented, the SPSR_EL1.PAN, SPSR_EL2.PAN, and
SPSR_EL3.PAN bits are used for exception returns, and the DSPSR_EL0
register is used for entry to or exit from Debug state.

When ARMv8.1-PAN is implemented, the SCTLR_EL1.SPAN and SCTLR_EL2.SPAN
bits are used to control whether the PAN bit is set on an exception
to EL1 or EL2."

> 
> 
> Index: arch/arm64/arm64/cpu.c
> ===
> RCS file: /cvs/src/sys/arch/arm64/arm64/cpu.c,v
> retrieving revision 1.38
> diff -u -p -r1.38 cpu.c
> --- arch/arm64/arm64/cpu.c4 Jun 2020 21:18:16 -   1.38
> +++ arch/arm64/arm64/cpu.c13 Aug 2020 19:12:30 -
> @@ -321,6 +321,7 @@ cpu_attach(struct device *parent, struct
>   struct fdt_attach_args *faa = aux;
>   struct cpu_info *ci;
>   uint64_t mpidr = READ_SPECIALREG(mpidr_el1);
> + uint64_t id_aa64mmfr1, sctlr;
>   uint32_t opp;
>  
>   KASSERT(faa->fa_nreg > 0);
> @@ -393,6 +394,14 @@ cpu_attach(struct device *parent, struct
>   cpu_cpuspeed = cpu_clockspeed;
>   }
>  
> + /* Enable PAN. */
> + id_aa64mmfr1 = READ_SPECIALREG(id_aa64mmfr1_el1);
> + if (ID_AA64MMFR1_PAN(id_aa64mmfr1) != ID_AA64MMFR1_PAN_NONE) {
> + sctlr = READ_SPECIALREG(sctlr_el1);
> + sctlr &= ~SCTLR_SPAN;
> + WRITE_SPECIALREG(sctlr_el1, sctlr);
> + }
> +
>   /* Initialize debug registers. */
>   WRITE_SPECIALREG(mdscr_el1, DBG_MDSCR_TDCC);
>   WRITE_SPECIALREG(oslar_el1, 0);
> @@ -522,6 +531,7 @@ cpu_boot_secondary(struct cpu_info *ci)
>  void
>  cpu_start_secondary(struct cpu_info *ci)
>  {
> + uint64_t id_aa64mmfr1, sctlr;
>   uint64_t tcr;
>   int s;
>  
> @@ -543,6 +553,14 @@ cpu_start_secondary(struct cpu_info *ci)
>   tcr |= TCR_T0SZ(64 - USER_SPACE_BITS);
>   tcr |= TCR_A1;
>   WRITE_SPECIALREG(tcr_el1, tcr);
> +
> + /* Enable PAN. */
> + id_aa64mmfr1 = READ_SPECIALREG(id_aa64mmfr1_el1);
> + if (ID_AA64MMFR1_PAN(id_aa64mmfr1) != ID_AA64MMFR1_PAN_NONE) {
> + sctlr = READ_SPECIALREG(sctlr_el1);
> + sctlr &= ~SCTLR_SPAN;
> + WRITE_SPECIALREG(sctlr_el1, sctlr);
> + }
>  
>   /* Initialize debug registers. */
>   WRITE_SPECIALREG(mdscr_el1, DBG_MDSCR_TDCC);
> Index: arch/arm64/include/armreg.h
> ===
> RCS file: /cvs/src/sys/arch/arm64/include/armreg.h,v
> retrieving revision 1.11
> diff -u -p -r1.11 armreg.h
> --- arch/arm64/include/armreg.h   5 Jun 2020 22:14:25 -   1.11
> +++ arch/arm64/include/armreg.h   13 Aug 2020 19:12:30 -
> @@ -451,6 +451,7 @@
>  #define  SCTLR_nTWI  0x0001
>  #define  SCTLR_nTWE  0x0004
>  #define  SCTLR_WXN   0x0008
> +#define  SCTLR_SPAN  0x0080
>  #define  SCTLR_EOE   0x0100
>  #define  SCTLR_EE0x0200
>  #define  SCTLR_UCI   0x0400
> @@ -478,6 +479,7 @@
>  #define  PSR_D   0x0200
>  #define  PSR_IL  0x0010
>  #define  PSR_SS  0x0020
> +#define  PSR_PAN 0x0040
>  #define  PSR_V   0x1000
>  #define  PSR_C   0x2000
>  #define  PSR_Z   0x4000
> 
> 



Re: PATCH: better error return for exFAT filesystem

2020-08-09 Thread Jonathan Gray
On Sat, Aug 08, 2020 at 01:13:20PM +1000, Jonathan Gray wrote:
> On Fri, Aug 07, 2020 at 12:59:00PM -0700, jo...@armadilloaerospace.com wrote:
> > Perform an explicit check for the unsupported exFAT MSDOS filesystem
> > instead of letting it fail mysteriously when it gets cluster sizes
> > of 0 from the normal fields.
> > 
> > This causes mount_msdos to report:
> > mount_msdos: /dev/sd1i on /root/mnt: filesystem not supported by kernel
> > 
> > Instead of the more obscure:
> > mount_msdos: /dev/sd1i on /root/mnt: Inapropriate file type or format
> > 
> > Index: msdosfs_vfsops.c
> > ===
> > RCS file: /cvs/src/sys/msdosfs/msdosfs_vfsops.c,v
> > retrieving revision 1.93
> > diff -u -p -r1.93 msdosfs_vfsops.c
> > --- msdosfs_vfsops.c24 Jan 2020 03:49:34 -  1.93
> > +++ msdosfs_vfsops.c7 Aug 2020 19:52:04 -
> > @@ -298,6 +298,12 @@ msdosfs_mountfs(struct vnode *devvp, str
> > b50 = (struct byte_bpb50 *)bsp->bs50.bsBPB;
> > b710 = (struct byte_bpb710 *)bsp->bs710.bsBPB;
> >  
> > +   /* No support for exFAT filesystems */
> > +   if (!strncmp("EXFAT", bsp->bs33.bsOemName, 5)) {
> > +   error = EOPNOTSUPP;
> > +   goto error_exit;
> > +   }
> > +
> > pmp = malloc(sizeof *pmp, M_MSDOSFSMNT, M_WAITOK | M_ZERO);
> > pmp->pm_mountp = mp;
> 
> The microsoft specification states it is EXFAT followed by three spaces
> 
>   if (!memcmp("EXFAT   ", bsp->bs33.bsOemName, 8)) {
> 
> may be more suitable here.

Thinking about this some more the problem is really the choice of errno.
It used to be EINVAL but was changed to EFTYPE in


revision 1.7
date: 1997/06/20 14:04:30;  author: kstailey;  state: Exp;  lines: +7 -7;
Change errno cause by mounting invalid filesystems from EINVAL to EFTYPE.


mount_msdos(8) knows about EINVAL and will print "not an MSDOS filesystem"

On reading mount(2) EOPNOTSUPP would be suitable for when the kernel
did not have msdos support built in not when the blocks found are not
msdos.

So either mount_msdos gains a EFTYPE case or we go back to EINVAL.

Index: sys/msdosfs/msdosfs_vfsops.c
===
RCS file: /cvs/src/sys/msdosfs/msdosfs_vfsops.c,v
retrieving revision 1.93
diff -u -p -r1.93 msdosfs_vfsops.c
--- sys/msdosfs/msdosfs_vfsops.c24 Jan 2020 03:49:34 -  1.93
+++ sys/msdosfs/msdosfs_vfsops.c9 Aug 2020 09:22:31 -
@@ -321,7 +321,7 @@ msdosfs_mountfs(struct vnode *devvp, str
pmp->pm_BlkPerSec = pmp->pm_BytesPerSec / DEV_BSIZE;
 
if (!pmp->pm_BytesPerSec || !SecPerClust) {
-   error = EFTYPE;
+   error = EINVAL;
goto error_exit;
}
 
@@ -451,7 +451,7 @@ msdosfs_mountfs(struct vnode *devvp, str
 * must be a power of 2
 */
if (pmp->pm_bpcluster ^ (1 << pmp->pm_cnshift)) {
-   error = EFTYPE;
+   error = EINVAL;
goto error_exit;
}
 
Index: sys/ufs/ffs/ffs_vfsops.c
===
RCS file: /cvs/src/sys/ufs/ffs/ffs_vfsops.c,v
retrieving revision 1.185
diff -u -p -r1.185 ffs_vfsops.c
--- sys/ufs/ffs/ffs_vfsops.c24 Jun 2020 22:03:45 -  1.185
+++ sys/ufs/ffs/ffs_vfsops.c9 Aug 2020 09:24:58 -
@@ -754,14 +754,6 @@ ffs_mountfs(struct vnode *devvp, struct 
fs = (struct fs *) bp->b_data;
sbloc = sbtry[i];
 
-#if 0
-   if (fs->fs_magic == FS_UFS2_MAGIC) {
-   printf("ffs_mountfs(): Sorry, no UFS2 support (yet)\n");
-   error = EFTYPE;
-   goto out;
-   }
-#endif
-
/*
 * Do not look for an FFS1 file system at SBLOCK_UFS2. Doing so
 * will find the wrong super-block for file systems with 64k
@@ -813,7 +805,7 @@ ffs_mountfs(struct vnode *devvp, struct 
printf("ffs_mountfs(): obsolete rotational table format, "
"please use fsck_ffs(8) -c 1\n");
 #endif
-   error = EFTYPE;
+   error = EINVAL;
goto out;
}
 



Re: PATCH: better error return for exFAT filesystem

2020-08-07 Thread Jonathan Gray
On Fri, Aug 07, 2020 at 12:59:00PM -0700, jo...@armadilloaerospace.com wrote:
> Perform an explicit check for the unsupported exFAT MSDOS filesystem
> instead of letting it fail mysteriously when it gets cluster sizes
> of 0 from the normal fields.
> 
> This causes mount_msdos to report:
> mount_msdos: /dev/sd1i on /root/mnt: filesystem not supported by kernel
> 
> Instead of the more obscure:
> mount_msdos: /dev/sd1i on /root/mnt: Inapropriate file type or format
> 
> Index: msdosfs_vfsops.c
> ===
> RCS file: /cvs/src/sys/msdosfs/msdosfs_vfsops.c,v
> retrieving revision 1.93
> diff -u -p -r1.93 msdosfs_vfsops.c
> --- msdosfs_vfsops.c  24 Jan 2020 03:49:34 -  1.93
> +++ msdosfs_vfsops.c  7 Aug 2020 19:52:04 -
> @@ -298,6 +298,12 @@ msdosfs_mountfs(struct vnode *devvp, str
>   b50 = (struct byte_bpb50 *)bsp->bs50.bsBPB;
>   b710 = (struct byte_bpb710 *)bsp->bs710.bsBPB;
>  
> + /* No support for exFAT filesystems */
> + if (!strncmp("EXFAT", bsp->bs33.bsOemName, 5)) {
> + error = EOPNOTSUPP;
> + goto error_exit;
> + }
> +
>   pmp = malloc(sizeof *pmp, M_MSDOSFSMNT, M_WAITOK | M_ZERO);
>   pmp->pm_mountp = mp;

The microsoft specification states it is EXFAT followed by three spaces

if (!memcmp("EXFAT   ", bsp->bs33.bsOemName, 8)) {

may be more suitable here.

fsck_msdos(8) likely needs a change to bail early if exFAT is found as
well.



use runtime clock for ktime in drm

2020-08-03 Thread Jonathan Gray
Scott mentioned that ktime should be using a runtime clock which stops
during suspend.  The exception to this is ktime_get_bootime() which does
not stop when suspended.

This is described in
https://www.kernel.org/doc/html/latest/core-api/timekeeping.html

There was perhaps some confusion as CLOCK_MONOTONIC does not count
time suspended on linux but does for us.

Index: include/linux/ktime.h
===
RCS file: /cvs/src/sys/dev/pci/drm/include/linux/ktime.h,v
retrieving revision 1.5
diff -u -p -r1.5 ktime.h
--- include/linux/ktime.h   29 Jul 2020 09:52:21 -  1.5
+++ include/linux/ktime.h   3 Aug 2020 08:26:55 -
@@ -28,7 +28,7 @@ static inline ktime_t
 ktime_get(void)
 {
struct timespec ts;
-   nanouptime();
+   nanoruntime();
return TIMESPEC_TO_NSEC();
 }
 
@@ -36,7 +36,7 @@ static inline ktime_t
 ktime_get_raw(void)
 {
struct timespec ts;
-   nanouptime();
+   nanoruntime();
return TIMESPEC_TO_NSEC();
 }
 
Index: include/linux/timekeeping.h
===
RCS file: /cvs/src/sys/dev/pci/drm/include/linux/timekeeping.h,v
retrieving revision 1.8
diff -u -p -r1.8 timekeeping.h
--- include/linux/timekeeping.h 29 Jul 2020 09:52:21 -  1.8
+++ include/linux/timekeeping.h 3 Aug 2020 08:28:30 -
@@ -3,7 +3,6 @@
 #ifndef _LINUX_TIMEKEEPING_H
 #define _LINUX_TIMEKEEPING_H
 
-#define ktime_get_boottime()   ktime_get()
 #define get_seconds()  gettime()
 
 static inline time_t
@@ -24,6 +23,14 @@ static inline uint64_t
 ktime_get_ns(void)
 {
return ktime_get();
+}
+
+static inline ktime_t
+ktime_get_boottime(void)
+{
+   struct timespec ts;
+   nanouptime();
+   return TIMESPEC_TO_NSEC();
 }
 
 #endif



Re: change ktime to nanoseconds in drm

2020-07-24 Thread Jonathan Gray
On Tue, Jul 21, 2020 at 05:10:02PM -0500, Scott Cheloha wrote:
> On Tue, Jul 21, 2020 at 07:33:21PM +1000, Jonathan Gray wrote:
> > Change from using timevals for ktime to 64 bit count of nanoseconds
> > to closer match linux.  From a discussion with cheloha@
> > 
> > 
> > 
> > @@ -67,70 +65,66 @@ ktime_get_raw_ns(void)
> >  }
> >  
> >  static inline struct timespec64
> > -ktime_to_timespec64(struct timeval tv)
> > +ktime_to_timespec64(ktime_t k)
> >  {
> > struct timespec64 ts;
> > -   ts.tv_sec = tv.tv_sec;
> > -   ts.tv_nsec = tv.tv_usec * NSEC_PER_USEC;
> > +   ts.tv_sec = k / NSEC_PER_SEC;
> > +   ts.tv_nsec = k % NSEC_PER_SEC;
> 
> This isn't quite right.  You need to handle negative values of k, too.
> 
>   ts.tv_sec = k / NSEC_PER_SEC;
>   ts.tv_nsec = k % NSEC_PER_SEC;
>   if (ts.tv_nsec < 0) {
>   ts.tv_sec--;
>   ts.tv_nsec += NSEC_PER_SEC;
>   }
> 
> 

ah right, tv_nsec should not be negative in that case

Index: drm_vblank.c
===
RCS file: /cvs/src/sys/dev/pci/drm/drm_vblank.c,v
retrieving revision 1.5
diff -u -p -r1.5 drm_vblank.c
--- drm_vblank.c8 Jun 2020 04:47:58 -   1.5
+++ drm_vblank.c24 Jul 2020 05:44:19 -
@@ -184,7 +184,7 @@ static void drm_reset_vblank_timestamp(s
 * interrupt and assign 0 for now, to mark the vblanktimestamp as 
invalid.
 */
if (!rc)
-   t_vblank = (struct timeval) {0, 0};
+   t_vblank = 0;
 
/*
 * +1 to make sure user will never see the same
@@ -293,7 +293,7 @@ static void drm_update_vblank_count(stru
 * for now, to mark the vblanktimestamp as invalid.
 */
if (!rc && !in_vblank_irq)
-   t_vblank = (struct timeval) {0, 0};
+   t_vblank = 0;
 
store_vblank(dev, pipe, diff, t_vblank, cur_vblank);
 }
@@ -871,7 +871,7 @@ static u64 drm_vblank_count_and_time(str
unsigned int seq;
 
if (WARN_ON(pipe >= dev->num_crtcs)) {
-   *vblanktime = (struct timeval) {0, 0};
+   *vblanktime = 0;
return 0;
}
 
Index: include/linux/ktime.h
===
RCS file: /cvs/src/sys/dev/pci/drm/include/linux/ktime.h,v
retrieving revision 1.4
diff -u -p -r1.4 ktime.h
--- include/linux/ktime.h   7 Jul 2020 04:05:25 -   1.4
+++ include/linux/ktime.h   24 Jul 2020 05:45:35 -
@@ -22,42 +22,40 @@
 #include 
 #include 
 
-typedef struct timeval ktime_t;
+typedef int64_t ktime_t;
 
-static inline struct timeval
+static inline ktime_t
 ktime_get(void)
 {
-   struct timeval tv;
-   
-   microuptime();
-   return tv;
+   struct timespec ts;
+   nanouptime();
+   return TIMESPEC_TO_NSEC();
 }
 
-static inline struct timeval
+static inline ktime_t
 ktime_get_raw(void)
 {
-   struct timeval tv;
-   
-   microuptime();
-   return tv;
+   struct timespec ts;
+   nanouptime();
+   return TIMESPEC_TO_NSEC();
 }
 
 static inline int64_t
-ktime_to_ms(struct timeval tv)
+ktime_to_ms(ktime_t k)
 {
-   return timeval_to_ms();
+   return k / NSEC_PER_MSEC;
 }
 
 static inline int64_t
-ktime_to_us(struct timeval tv)
+ktime_to_us(ktime_t k)
 {
-   return timeval_to_us();
+   return k / NSEC_PER_USEC;
 }
 
 static inline int64_t
-ktime_to_ns(struct timeval tv)
+ktime_to_ns(ktime_t k)
 {
-   return timeval_to_ns();
+   return k;
 }
 
 static inline int64_t
@@ -67,70 +65,70 @@ ktime_get_raw_ns(void)
 }
 
 static inline struct timespec64
-ktime_to_timespec64(struct timeval tv)
+ktime_to_timespec64(ktime_t k)
 {
struct timespec64 ts;
-   ts.tv_sec = tv.tv_sec;
-   ts.tv_nsec = tv.tv_usec * NSEC_PER_USEC;
+   ts.tv_sec = k / NSEC_PER_SEC;
+   ts.tv_nsec = k % NSEC_PER_SEC;
+   if (ts.tv_nsec < 0) {
+   ts.tv_sec--;
+   ts.tv_nsec += NSEC_PER_SEC;
+   }
return ts;
 }
 
-static inline struct timeval
-ktime_sub(struct timeval a, struct timeval b)
+static inline ktime_t
+ktime_sub(ktime_t a, ktime_t b)
 {
-   struct timeval res;
-   timersub(, , );
-   return res;
+   return a - b;
 }
 
-static inline struct timeval
-ktime_add(struct timeval a, struct timeval b)
+static inline ktime_t
+ktime_add(ktime_t a, ktime_t b)
 {
-   struct timeval res;
-   timeradd(, , );
-   return res;
+   return a + b;
 }
 
-static inline struct timeval
-ktime_add_us(struct timeval tv, int64_t us)
+static inline ktime_t
+ktime_add_us(ktime_t k, uint64_t us)
 {
-   return ns_to_timeval(timeval_to_ns() + (us * NSEC_PER_USEC));
+   return k + (us * NSEC_PER_USEC);
 }
 
-static inline struct timeval
-ktime_add_ns(struct ti

change ktime to nanoseconds in drm

2020-07-21 Thread Jonathan Gray
Change from using timevals for ktime to 64 bit count of nanoseconds
to closer match linux.  From a discussion with cheloha@

Index: sys/dev/pci/drm/drm_vblank.c
===
RCS file: /cvs/src/sys/dev/pci/drm/drm_vblank.c,v
retrieving revision 1.5
diff -u -p -r1.5 drm_vblank.c
--- sys/dev/pci/drm/drm_vblank.c8 Jun 2020 04:47:58 -   1.5
+++ sys/dev/pci/drm/drm_vblank.c21 Jul 2020 07:00:48 -
@@ -184,7 +184,7 @@ static void drm_reset_vblank_timestamp(s
 * interrupt and assign 0 for now, to mark the vblanktimestamp as 
invalid.
 */
if (!rc)
-   t_vblank = (struct timeval) {0, 0};
+   t_vblank = 0;
 
/*
 * +1 to make sure user will never see the same
@@ -293,7 +293,7 @@ static void drm_update_vblank_count(stru
 * for now, to mark the vblanktimestamp as invalid.
 */
if (!rc && !in_vblank_irq)
-   t_vblank = (struct timeval) {0, 0};
+   t_vblank = 0;
 
store_vblank(dev, pipe, diff, t_vblank, cur_vblank);
 }
@@ -871,7 +871,7 @@ static u64 drm_vblank_count_and_time(str
unsigned int seq;
 
if (WARN_ON(pipe >= dev->num_crtcs)) {
-   *vblanktime = (struct timeval) {0, 0};
+   *vblanktime = 0;
return 0;
}
 
Index: sys/dev/pci/drm/include/linux/ktime.h
===
RCS file: /cvs/src/sys/dev/pci/drm/include/linux/ktime.h,v
retrieving revision 1.4
diff -u -p -r1.4 ktime.h
--- sys/dev/pci/drm/include/linux/ktime.h   7 Jul 2020 04:05:25 -   
1.4
+++ sys/dev/pci/drm/include/linux/ktime.h   21 Jul 2020 07:00:48 -
@@ -22,42 +22,40 @@
 #include 
 #include 
 
-typedef struct timeval ktime_t;
+typedef int64_t ktime_t;
 
-static inline struct timeval
+static inline ktime_t
 ktime_get(void)
 {
-   struct timeval tv;
-   
-   microuptime();
-   return tv;
+   struct timespec ts;
+   nanouptime();
+   return TIMESPEC_TO_NSEC();
 }
 
-static inline struct timeval
+static inline ktime_t
 ktime_get_raw(void)
 {
-   struct timeval tv;
-   
-   microuptime();
-   return tv;
+   struct timespec ts;
+   nanouptime();
+   return TIMESPEC_TO_NSEC();
 }
 
 static inline int64_t
-ktime_to_ms(struct timeval tv)
+ktime_to_ms(ktime_t k)
 {
-   return timeval_to_ms();
+   return k / NSEC_PER_MSEC;
 }
 
 static inline int64_t
-ktime_to_us(struct timeval tv)
+ktime_to_us(ktime_t k)
 {
-   return timeval_to_us();
+   return k / NSEC_PER_USEC;
 }
 
 static inline int64_t
-ktime_to_ns(struct timeval tv)
+ktime_to_ns(ktime_t k)
 {
-   return timeval_to_ns();
+   return k;
 }
 
 static inline int64_t
@@ -67,70 +65,66 @@ ktime_get_raw_ns(void)
 }
 
 static inline struct timespec64
-ktime_to_timespec64(struct timeval tv)
+ktime_to_timespec64(ktime_t k)
 {
struct timespec64 ts;
-   ts.tv_sec = tv.tv_sec;
-   ts.tv_nsec = tv.tv_usec * NSEC_PER_USEC;
+   ts.tv_sec = k / NSEC_PER_SEC;
+   ts.tv_nsec = k % NSEC_PER_SEC;
return ts;
 }
 
-static inline struct timeval
-ktime_sub(struct timeval a, struct timeval b)
+static inline ktime_t
+ktime_sub(ktime_t a, ktime_t b)
 {
-   struct timeval res;
-   timersub(, , );
-   return res;
+   return a - b;
 }
 
-static inline struct timeval
-ktime_add(struct timeval a, struct timeval b)
+static inline ktime_t
+ktime_add(ktime_t a, ktime_t b)
 {
-   struct timeval res;
-   timeradd(, , );
-   return res;
+   return a + b;
 }
 
-static inline struct timeval
-ktime_add_us(struct timeval tv, int64_t us)
+static inline ktime_t
+ktime_add_us(ktime_t k, uint64_t us)
 {
-   return ns_to_timeval(timeval_to_ns() + (us * NSEC_PER_USEC));
+   return k + (us * NSEC_PER_USEC);
 }
 
-static inline struct timeval
-ktime_add_ns(struct timeval tv, int64_t ns)
+static inline ktime_t
+ktime_add_ns(ktime_t k, int64_t ns)
 {
-   return ns_to_timeval(timeval_to_ns() + ns);
+   return k + ns;
 }
 
-static inline struct timeval
-ktime_sub_ns(struct timeval tv, int64_t ns)
+static inline ktime_t
+ktime_sub_ns(ktime_t k, int64_t ns)
 {
-   return ns_to_timeval(timeval_to_ns() - ns);
+   return k - ns;
 }
 
 static inline int64_t
-ktime_us_delta(struct timeval a, struct timeval b)
+ktime_us_delta(ktime_t a, ktime_t b)
 {
return ktime_to_us(ktime_sub(a, b));
 }
 
 static inline int64_t
-ktime_ms_delta(struct timeval a, struct timeval b)
+ktime_ms_delta(ktime_t a, ktime_t b)
 {
return ktime_to_ms(ktime_sub(a, b));
 }
 
 static inline bool
-ktime_after(const struct timeval a, const struct timeval b)
+ktime_after(ktime_t a, ktime_t b)
 {
-   return timercmp(, , >);
+   return a > b;
 }
 
-static inline struct timeval
+static inline ktime_t
 ns_to_ktime(uint64_t ns)
 {
-   return ns_to_timeval(ns);
+   return ns;
 }
 
 

change some drm locks from IPL_TTY to IPL_NONE

2020-07-10 Thread Jonathan Gray
In drm linux spinlocks are mapped to mutex(9).

Locks without calls to spin_lock_irqsave(), spin_lock_irq() and the like
(which block interrupts) can be changed to IPL_NONE.

Index: sys/dev/pci/drm/drm_legacy_misc.c
===
RCS file: /cvs/src/sys/dev/pci/drm/drm_legacy_misc.c,v
retrieving revision 1.1
diff -u -p -r1.1 drm_legacy_misc.c
--- sys/dev/pci/drm/drm_legacy_misc.c   8 Jun 2020 04:47:58 -   1.1
+++ sys/dev/pci/drm/drm_legacy_misc.c   11 Jul 2020 02:49:18 -
@@ -47,7 +47,7 @@ void drm_legacy_init_members(struct drm_
INIT_LIST_HEAD(>ctxlist);
INIT_LIST_HEAD(>vmalist);
INIT_LIST_HEAD(>maplist);
-   mtx_init(>buf_lock, IPL_TTY);
+   mtx_init(>buf_lock, IPL_NONE);
rw_init(>ctxlist_mutex, "drmoctx");
 }
 
Index: sys/dev/pci/drm/amd/amdgpu/amdgpu_device.c
===
RCS file: /cvs/src/sys/dev/pci/drm/amd/amdgpu/amdgpu_device.c,v
retrieving revision 1.10
diff -u -p -r1.10 amdgpu_device.c
--- sys/dev/pci/drm/amd/amdgpu/amdgpu_device.c  9 Jul 2020 10:25:28 -   
1.10
+++ sys/dev/pci/drm/amd/amdgpu/amdgpu_device.c  10 Jul 2020 16:40:38 -
@@ -2987,13 +2987,13 @@ int amdgpu_device_init(struct amdgpu_dev
mtx_init(>gc_cac_idx_lock, IPL_TTY);
mtx_init(>se_cac_idx_lock, IPL_TTY);
mtx_init(>audio_endpt_idx_lock, IPL_TTY);
-   mtx_init(>mm_stats.lock, IPL_TTY);
+   mtx_init(>mm_stats.lock, IPL_NONE);
 
INIT_LIST_HEAD(>shadow_list);
rw_init(>shadow_list_lock, "sdwlst");
 
INIT_LIST_HEAD(>ring_lru_list);
-   mtx_init(>ring_lru_list_lock, IPL_TTY);
+   mtx_init(>ring_lru_list_lock, IPL_NONE);
 
INIT_DELAYED_WORK(>delayed_init_work,
  amdgpu_device_delayed_init_work_handler);
Index: sys/dev/pci/drm/amd/amdgpu/amdgpu_gtt_mgr.c
===
RCS file: /cvs/src/sys/dev/pci/drm/amd/amdgpu/amdgpu_gtt_mgr.c,v
retrieving revision 1.2
diff -u -p -r1.2 amdgpu_gtt_mgr.c
--- sys/dev/pci/drm/amd/amdgpu/amdgpu_gtt_mgr.c 8 Jun 2020 04:47:59 -   
1.2
+++ sys/dev/pci/drm/amd/amdgpu/amdgpu_gtt_mgr.c 10 Jul 2020 16:43:28 -
@@ -99,7 +99,7 @@ static int amdgpu_gtt_mgr_init(struct tt
start = AMDGPU_GTT_MAX_TRANSFER_SIZE * AMDGPU_GTT_NUM_TRANSFER_WINDOWS;
size = (adev->gmc.gart_size >> PAGE_SHIFT) - start;
drm_mm_init(>mm, start, size);
-   mtx_init(>lock, IPL_TTY);
+   mtx_init(>lock, IPL_NONE);
atomic64_set(>available, p_size);
man->priv = mgr;
 
Index: sys/dev/pci/drm/amd/amdgpu/amdgpu_vm.c
===
RCS file: /cvs/src/sys/dev/pci/drm/amd/amdgpu/amdgpu_vm.c,v
retrieving revision 1.8
diff -u -p -r1.8 amdgpu_vm.c
--- sys/dev/pci/drm/amd/amdgpu/amdgpu_vm.c  22 Jun 2020 10:11:55 -  
1.8
+++ sys/dev/pci/drm/amd/amdgpu/amdgpu_vm.c  10 Jul 2020 16:44:17 -
@@ -2867,7 +2867,7 @@ int amdgpu_vm_init(struct amdgpu_device 
INIT_LIST_HEAD(>moved);
INIT_LIST_HEAD(>idle);
INIT_LIST_HEAD(>invalidated);
-   mtx_init(>invalidated_lock, IPL_TTY);
+   mtx_init(>invalidated_lock, IPL_NONE);
INIT_LIST_HEAD(>freed);
 
 
Index: sys/dev/pci/drm/amd/amdgpu/amdgpu_vram_mgr.c
===
RCS file: /cvs/src/sys/dev/pci/drm/amd/amdgpu/amdgpu_vram_mgr.c,v
retrieving revision 1.2
diff -u -p -r1.2 amdgpu_vram_mgr.c
--- sys/dev/pci/drm/amd/amdgpu/amdgpu_vram_mgr.c8 Jun 2020 04:47:59 
-   1.2
+++ sys/dev/pci/drm/amd/amdgpu/amdgpu_vram_mgr.c10 Jul 2020 16:45:44 
-
@@ -168,7 +168,7 @@ static int amdgpu_vram_mgr_init(struct t
return -ENOMEM;
 
drm_mm_init(>mm, 0, p_size);
-   mtx_init(>lock, IPL_TTY);
+   mtx_init(>lock, IPL_NONE);
man->priv = mgr;
 
/* Add the two VRAM-related sysfs files */
Index: sys/dev/pci/drm/amd/amdgpu/gmc_v10_0.c
===
RCS file: /cvs/src/sys/dev/pci/drm/amd/amdgpu/gmc_v10_0.c,v
retrieving revision 1.1
diff -u -p -r1.1 gmc_v10_0.c
--- sys/dev/pci/drm/amd/amdgpu/gmc_v10_0.c  8 Jun 2020 04:47:59 -   
1.1
+++ sys/dev/pci/drm/amd/amdgpu/gmc_v10_0.c  10 Jul 2020 16:46:43 -
@@ -767,7 +767,7 @@ static int gmc_v10_0_sw_init(void *handl
gfxhub_v2_0_init(adev);
mmhub_v2_0_init(adev);
 
-   mtx_init(>gmc.invalidate_lock, IPL_TTY);
+   mtx_init(>gmc.invalidate_lock, IPL_NONE);
 
r = amdgpu_atomfirmware_get_vram_info(adev,
_width, _type, _vendor);
Index: sys/dev/pci/drm/amd/amdgpu/gmc_v9_0.c
===
RCS file: /cvs/src/sys/dev/pci/drm/amd/amdgpu/gmc_v9_0.c,v
retrieving revision 1.7
diff -u -p -r1.7 gmc_v9_0.c
--- sys/dev/pci/drm/amd/amdgpu/gmc_v9_0.c 

Re: panic on inteldrm attach in braswell device

2020-07-10 Thread Jonathan Gray
On Fri, Jul 10, 2020 at 08:31:29AM +0100, Ricardo Mestre wrote:
> Hi,
> 
> Since my edgerouter decided to commit seppuku, then to replace it, the cheap
> bastard in me bought a crappy braswell based device which after 2 months
> finally arrived, but of course it had to have at least one problem.
> 
> As soon as inteldrm attach I get the below panic, but with inteldrm disabled
> I'm able to boot and use the system without issues:
> 
> wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation), using wskbd0
> wsdisplay0: screen 1-5 added (std, vt100 emulation)
> kernel: protection fault trap, code=0
> Stopped atpool_do_put+0xd0movq0x8(%rcx),%rcx
> 
> This is the trace without function params, typed manually since this box
> doesn't have serial console, but link [0] has them. Any clues about this
> or should I just dump it in the fire?
> 
> [0] https://imgur.com/a/O5PFQpz
> 
> ddb{1}> trace
> pool_do_put() at pool_do_put+0xd0
> pool_put() at pool_put+0x5a
> uvm_unmap_detach() at uvm_unmap_detach+0x90
> uvm_map() at uvm_map+0x7fb
> km_alloc() at km_alloc+0x162
> pool_multi_alloc_ni at pool_multi_alloc_ni+0xa6
> pool_p_alloc() at pool_p_alloc+0x5a
> pool_do_get() at pool_do_get+0xd3
> pool_get() at pool_get+0x8f
> ufsdirhash_build at ufsdirhash_build+0x314
> ufs_lookup() at ufs_lookup+0x18a
> VOP_LOOKUP() at VOP_LOOKUP+0x46
> vfs_lookup() at vfs_lookup+0x3d2
> namei() at namei+0x3a5
> start_init() at start_init+0xaa
> end trace frame: 0x0, count: -15

reports like this should go to bugs@ not tech

Most of the pool use in drm is quite mechanical conversions of
kmem_cache*.  The only suspect thing I can spot is in a detach path,
which isn't involved if a wsdisplay is being attached.

I can't reproduce this here on a braswell system with the same
kernel from snapshots or a locally built kernel.



Re: Use VGA text mode palette RGB values in rasops(9)

2020-07-07 Thread Jonathan Gray
On Tue, Jul 07, 2020 at 05:55:32PM +0200, Frederic Cambus wrote:
> On Wed, Jul 08, 2020 at 12:06:27AM +1000, Jonathan Gray wrote:
> > On Tue, Jul 07, 2020 at 03:16:33PM +0200, Frederic Cambus wrote:
> > > Hi tech@,
> > > 
> > > The recent spike of interest around framebuffer consoles has prompted
> > > me to revisit a proposal I sent back in early 2017 [1].
> > > 
> > > Aesthetics considerations aside, kettenis@ raised the concern that colors
> > > from the original rasops palette carefully matched what OpenFirmware
> > > uses for the console on sparc64.
> > > 
> > > Therefore, I propose to default on using the proper VGA text mode palette
> > > RGB values, and to keep the original rasops color palette on sparc64.
> > > 
> > > The differences between the two palettes can be seen here [2].
> > > 
> > > Comments? OK?
> > 
> > Why is it important to match VGA colours?
> > We don't try to match video modes or fonts.
> 
> In case it wasn't obvious by comparing the two palettes, the main problem
> with the rasops palette it that the NORMAL_RED, NORMAL_GREEN, NORMAL_BLUE,
> NORMAL_MAGENTA and NORMAL_CYAN colors are too dark.
> 
> NORMAL_BLUE is especially problematic as it's very difficult to read on
> a black background.
> 
> It is used as the default color for comments in vim. It's also (I know I'm
> not going to make any friends here) the color used to "highlight" (ahem)
> directories in colorls.
> 
> One can test in frame buffer consoles by doing:
> 
> export TERM=wsvt25
> 
> And run either vim or colorls -G.

Thanks for the explanation.  The proposal makes more sense from the
point of view of the existing colours being darker for openboot black
on white.

#if WS_DEFAULT_BG == WSCOL_WHITE

old

#else

new

#endif

would have made that a bit more readable.

It is interesting that the choice of blue comes up as being problematic
in xterm as well when reading XTerm-col.ad

For us though it really comes down to white on black (!sparc64), black
on white (sparc64) and white on blue for the kernel.

I agree with the sentiment that people should be using X and leave
rasops/wscons as simple as possible.



Re: Use VGA text mode palette RGB values in rasops(9)

2020-07-07 Thread Jonathan Gray
On Tue, Jul 07, 2020 at 03:16:33PM +0200, Frederic Cambus wrote:
> Hi tech@,
> 
> The recent spike of interest around framebuffer consoles has prompted
> me to revisit a proposal I sent back in early 2017 [1].
> 
> Aesthetics considerations aside, kettenis@ raised the concern that colors
> from the original rasops palette carefully matched what OpenFirmware
> uses for the console on sparc64.
> 
> Therefore, I propose to default on using the proper VGA text mode palette
> RGB values, and to keep the original rasops color palette on sparc64.
> 
> The differences between the two palettes can be seen here [2].
> 
> Comments? OK?

Why is it important to match VGA colours?
We don't try to match video modes or fonts.

> 
> [1] https://marc.info/?l=openbsd-tech=148374502927423=2
> [2] 
> https://www.cambus.net/openbsd-framebuffer-console-and-custom-color-palettes/
> 
> Index: sys/dev/rasops/rasops.c
> ===
> RCS file: /cvs/src/sys/dev/rasops/rasops.c,v
> retrieving revision 1.62
> diff -u -p -r1.62 rasops.c
> --- sys/dev/rasops/rasops.c   16 Jun 2020 21:49:30 -  1.62
> +++ sys/dev/rasops/rasops.c   7 Jul 2020 09:10:08 -
> @@ -47,7 +47,26 @@
>  
>  /* ANSI colormap (R,G,B) */
>  
> -#define  NORMAL_BLACK0x00
> +#ifndef __sparc64__
> +#define  NORMAL_BLACK0x00/* VGA text mode palette */
> +#define  NORMAL_RED  0xaa
> +#define  NORMAL_GREEN0x00aa00
> +#define  NORMAL_BROWN0xaa5500
> +#define  NORMAL_BLUE 0xaa
> +#define  NORMAL_MAGENTA  0xaa00aa
> +#define  NORMAL_CYAN 0x00
> +#define  NORMAL_WHITE0xaa
> +
> +#define  HILITE_BLACK0x55
> +#define  HILITE_RED  0xff
> +#define  HILITE_GREEN0x55ff55
> +#define  HILITE_BROWN0x55
> +#define  HILITE_BLUE 0xff
> +#define  HILITE_MAGENTA  0xff55ff
> +#define  HILITE_CYAN 0x55
> +#define  HILITE_WHITE0xff
> +#else
> +#define  NORMAL_BLACK0x00/* Rasops palette */
>  #define  NORMAL_RED  0x7f
>  #define  NORMAL_GREEN0x007f00
>  #define  NORMAL_BROWN0x7f7f00
> @@ -64,6 +83,7 @@
>  #define  HILITE_MAGENTA  0xff00ff
>  #define  HILITE_CYAN 0x00
>  #define  HILITE_WHITE0xff
> +#endif
>  
>  const u_char rasops_cmap[256 * 3] = {
>  #define  _C(x)   ((x) & 0xff) >> 16, ((x) & 0x00ff00) >> 8, ((x) & 
> 0xff)
> 
> 



Re: urtwn(4): Add support for D-Link DWA-121 rev B1

2020-07-06 Thread Jonathan Gray
On Mon, Jul 06, 2020 at 10:15:14AM +0100, Miguel Landaeta wrote:
> Hi,
> 
> The patch at the end should add support for USB wifi dongle
> DWA-121 from D-Link [1].
> 
> The USB id of such device is 2001:331b.
> 
> lykke$ usbdevs
> Controller /dev/usb0:
> addr 01: : Generic, EHCI root hub
> Controller /dev/usb1:
> addr 01: : Generic, EHCI root hub
> addr 02: 05e3:0608 Genesys Logic, USB2.0 Hub
> addr 03: 0c45:6321 Sonix Technology Co., Ltd., USB Camera
> Controller /dev/usb2:
> addr 01: : Generic, xHCI root hub
> Controller /dev/usb3:
> addr 01: : Generic, xHCI root hub
> addr 02: 2001:331b Realtek\r,
> Controller /dev/usb4:
> addr 01: : Generic, OHCI root hub
> addr 02: 258a:001e HAILUCK CO.,LTD, USB KEYBOARD
> Controller /dev/usb5:
> addr 01: : Generic, OHCI root hub
> 
> Relevant dmesg message (full dmesg is attached):
> 
> urtwn0 at uhub3 port 1 configuration 1 interface 0 "Realtek " rev 2.00/0.00 
> addr 2
> urtwn0: MAC/BB RTL8188EU, RF 6052 1T1R, address 60:63:4c:xx:xx:xx
> 
> Thanks,
> Miguel.
> 
> 1. https://eu.dlink.com/uk/en/products/dwa-121-wireless-n-150-pico-usb-adapter

Thanks, committed with if_urtwn.c changed to be in sorted order.

If you run 'fw_update bwfm' bwfm firmware will be installed and builtin
802.11 should work.

> 
> 
> Index: sys/dev/usb/if_urtwn.c
> ===
> RCS file: /cvs/src/sys/dev/usb/if_urtwn.c,v
> retrieving revision 1.90
> diff -u -p -r1.90 if_urtwn.c
> --- sys/dev/usb/if_urtwn.c11 Jun 2020 00:56:12 -  1.90
> +++ sys/dev/usb/if_urtwn.c6 Jul 2020 08:26:30 -
> @@ -328,6 +328,7 @@ static const struct urtwn_type {
>   URTWN_DEV_8188EU(REALTEK,   RTL8188ETV),
>   URTWN_DEV_8188EU(REALTEK,   RTL8188EU),
>   URTWN_DEV_8188EU(TPLINK,RTL8188EUS),
> + URTWN_DEV_8188EU(DLINK, DWA121B1),
>   /* URTWN_RTL8192EU */
>   URTWN_DEV_8192EU(DLINK, DWA131E1),
>   URTWN_DEV_8192EU(REALTEK,   RTL8192EU),
> Index: sys/dev/usb/usbdevs
> ===
> RCS file: /cvs/src/sys/dev/usb/usbdevs,v
> retrieving revision 1.717
> diff -u -p -r1.717 usbdevs
> --- sys/dev/usb/usbdevs   22 Jun 2020 15:49:37 -  1.717
> +++ sys/dev/usb/usbdevs   6 Jul 2020 08:26:30 -
> @@ -1565,6 +1565,7 @@ product DLINK DWA125D1  0x330f  DWA-125 r
>  product DLINK DWA123D1   0x3310  DWA-123 rev D1
>  product DLINK DWA137A1   0x3317  DWA-137 rev A1
>  product DLINK DWA131E1   0x3319  DWA-131 rev E1
> +product DLINK DWA121B1   0x331b  DWA-121 rev B1
>  product DLINK DWA182D1   0x331c  DWA-182 rev D1
>  product DLINK DWA171C1   0x331d  DWA-171 rev C1
>  product DLINK DWL122 0x3700  DWL-122
> Index: sys/dev/usb/usbdevs.h
> ===
> RCS file: /cvs/src/sys/dev/usb/usbdevs.h,v
> retrieving revision 1.729
> diff -u -p -r1.729 usbdevs.h
> --- sys/dev/usb/usbdevs.h 22 Jun 2020 15:52:39 -  1.729
> +++ sys/dev/usb/usbdevs.h 6 Jul 2020 08:26:30 -
> @@ -1570,6 +1570,7 @@
>  #define  USB_PRODUCT_DLINK_DWA131B   0x330d  /* DWA-131 rev 
> B */
>  #define  USB_PRODUCT_DLINK_DWA125D1  0x330f  /* DWA-125 rev 
> D1 */
>  #define  USB_PRODUCT_DLINK_DWA123D1  0x3310  /* DWA-123 rev 
> D1 */
> +#define  USB_PRODUCT_DLINK_DWA121B1  0x331b  /* DWA-121 rev 
> B1 */
>  #define  USB_PRODUCT_DLINK_DWA137A1  0x3317  /* DWA-137 rev 
> A1 */
>  #define  USB_PRODUCT_DLINK_DWA131E1  0x3319  /* DWA-131 rev 
> E1 */
>  #define  USB_PRODUCT_DLINK_DWA182D1  0x331c  /* DWA-182 rev 
> D1 */
> Index: sys/dev/usb/usbdevs_data.h
> ===
> RCS file: /cvs/src/sys/dev/usb/usbdevs_data.h,v
> retrieving revision 1.723
> diff -u -p -r1.723 usbdevs_data.h
> --- sys/dev/usb/usbdevs_data.h22 Jun 2020 15:52:39 -  1.723
> +++ sys/dev/usb/usbdevs_data.h6 Jul 2020 08:26:31 -
> @@ -2618,6 +2618,10 @@ const struct usb_known_product usb_known
>   "DWA-123 rev D1",
>   },
>   {
> + USB_VENDOR_DLINK, USB_PRODUCT_DLINK_DWA121B1,
> + "DWA-121 rev B1",
> + },
> + {
>   USB_VENDOR_DLINK, USB_PRODUCT_DLINK_DWA137A1,
>   "DWA-137 rev A1",
>   },
> 
> 
> -- 
> Miguel Landaeta, nomadium at debian.org
> secure email with PGP 0x6E608B637D8967E9 available at http://miguel.cc/key.
> "Faith means not wanting to know what is true." -- Nietzsche

> OpenBSD 6.7-current (CUSTOM) #0: Fri Jul  3 14:18:45 IST 2020
> mig...@lykke.nomadium.net:/sys/arch/arm64/compile/CUSTOM
> real mem  = 4092612608 (3903MB)
> avail mem = 3891392512 (3711MB)
> random: good seed from bootblocks
> mainbus0 at root: Pine64 Pinebook Pro
> 

Re: [patch] remove NPCDISPLAY from AMD64

2020-06-16 Thread Jonathan Gray
On Tue, Jun 16, 2020 at 07:15:24PM -0700, jo...@armadilloaerospace.com wrote:
> You can't put an ISA CGA/EGA/MGA in an AMD64 system, so these can
> go away.

While it is incredibly unlikely someone would try, amd64 capable
"industrial" motherboards with ISA exist.  We don't build
pcdisplay(4) on amd64 by default however.

> 
> Does anyone know if there is an ordering reason that the coreboot
> efifb_cb_cnattach console is after the VGA attach? Things could be
> cleaned up a bit if the efifb entry points just checked for both
> efi and coreboot framebuffers in the same function.

https://marc.info/?l=openbsd-tech=146609528005661=2

"The cnattach path still has to be different to allow vga to
try to attach before doing the coreboot version"

It seems the coreboot framebuffer support was intended to be a last
resort if vga and efi gop were not available going by the initial mail
when it was proposed as a different driver:

https://marc.info/?l=openbsd-tech=14655876693=2

> 
> 
> Index: wscons_machdep.c
> ===
> RCS file: /cvs/src/sys/arch/amd64/amd64/wscons_machdep.c,v
> retrieving revision 1.14
> diff -u -p -r1.14 wscons_machdep.c
> --- wscons_machdep.c  14 Oct 2017 04:44:43 -  1.14
> +++ wscons_machdep.c  17 Jun 2020 02:05:34 -
> @@ -35,18 +35,12 @@
>  #include 
>  
>  #include "vga.h"
> -#include "pcdisplay.h"
> -#if (NVGA > 0) || (NPCDISPLAY > 0)
> +#if (NVGA > 0)
>  #include 
>  #include 
> -#if (NVGA > 0)
>  #include 
>  #include 
>  #endif
> -#if (NPCDISPLAY > 0)
> -#include 
> -#endif
> -#endif
>  
>  #include "wsdisplay.h"
>  #if NWSDISPLAY > 0
> @@ -146,10 +140,6 @@ wscn_video_init(void)
>  #endif
>  #if (NEFIFB > 0)
>   if (efifb_cb_cnattach() == 0)
> - return (0);
> -#endif
> -#if (NPCDISPLAY > 0)
> - if (pcdisplay_cnattach(X86_BUS_SPACE_IO, X86_BUS_SPACE_MEM) == 0)
>   return (0);
>  #endif
>   return (-1);
> 
> 
> 



Re: code style questions

2020-06-10 Thread Jonathan Gray
On Wed, Jun 10, 2020 at 09:19:47AM +0200, Martin Pieuchot wrote:
> On 09/06/20(Tue) 20:19, jo...@armadilloaerospace.com wrote:
> > Looking for some guidance to avoid proposing any unpopular diffs.
> > 
> > Style(9) says not to use static on file-local functions in the
> > kernel, because it interferes with the debugger.  They still show up
> > on some functions today; is this still an issue?
> 
> I don't know if it's an issue, but not using 'static' is still a
> convention.

It is.  Backtraces in drm code aren't as useful as they could be as
static is extensively used.



Re: [patch] azalia: Intel 300 Series HD Audio

2020-06-08 Thread Jonathan Gray
On Mon, Jun 08, 2020 at 09:14:36PM -0600, bobby wrote:
> On Sun, May 31, 2020 at 12:38:55PM +0200, Bruno Flueckiger wrote:
> > On 31.05., Benjamin Baier wrote:
> > > On Fri, 29 May 2020 11:25:44 +0200
> > > Bruno Flueckiger  wrote:
> > >
> > > > Hi,
> > > >
> > > > My brand new laptop HP EliteBook 850 G6 comes with an Intel 300 Series
> > > > HD Audio device rev 0x11. The device shows up as not configured in the
> > > > dmesg. The PCI config space of the device identifies its subclass as
> > > > PCI_SUBCLASS_MULTIMEDIA_AUDIO instead of PCI_SUBCLASS_MULTIMEDIA_HDAUDIO
> > > >
> > > > The patch below makes the device work just fine on my laptop.
> > > >
> > > > Cheers,
> > > > Bruno
> > > >
> > > > Index: sys/dev/pci/azalia.c
> > > > ===
> > > > RCS file: /cvs/src/sys/dev/pci/azalia.c,v
> > > > retrieving revision 1.255
> > > > diff -u -p -r1.255 azalia.c
> > > > --- sys/dev/pci/azalia.c18 Apr 2020 21:55:56 -  1.255
> > > > +++ sys/dev/pci/azalia.c28 May 2020 13:48:10 -
> > > > @@ -481,7 +481,8 @@ azalia_pci_match(struct device *parent,
> > > >
> > > > pa = aux;
> > > > if (PCI_CLASS(pa->pa_class) == PCI_CLASS_MULTIMEDIA
> > > > -   && PCI_SUBCLASS(pa->pa_class) == 
> > > > PCI_SUBCLASS_MULTIMEDIA_HDAUDIO)
> > > > +   && (PCI_SUBCLASS(pa->pa_class) == 
> > > > PCI_SUBCLASS_MULTIMEDIA_HDAUDIO
> > > > +   || PCI_SUBCLASS(pa->pa_class) == 
> > > > PCI_SUBCLASS_MULTIMEDIA_AUDIO))
> > > > return 1;
> > > > return 0;
> > > >  }
> > > >
> > >
> > > Hi.
> > >
> > > Does your Laptop run with the latest BIOS? There was one released on May 
> > > 11th.
> > > https://support.hp.com/de-de/drivers/selfservice/swdetails/hp-elitebook-850-g6-notebook-pc/26609805/swItemId/ob-251060-1
> > > The release notes state: Fixes an issue where the audio on the system 
> > > stops functioning after the Intel Active Management Technology (AMT) 
> > > option is disabled.
> > >
> > > The azalia patch is in but I would prefer HP to fix their BIOS instead.
> > >
> > > Greetings Ben
> > >
> > 
> > Hi Ben,
> > 
> > I've upgraded the firmware to the latest available release, but the
> > audio device still reports with the wrong subclass in its PCI config
> > space.
> > 
> > I agree that HP should rather fix their firmware. I still try to find
> > out how to report this problem to HP in a way that doesn't get ignored.
> > 
> > Cheers,
> > Bruno
> > 
> 
> My laptop, Lenovo C930, needs the same matching to attach azalia, I have the 
> newest bios fyi.  Patch and pcidump below.

thanks, committed with order sorted

> 
> 
> Index: sys/dev/pci/azalia.c
> ===
> RCS file: /cvs/src/sys/dev/pci/azalia.c,v
> retrieving revision 1.256
> diff -u -p -u -p -r1.256 azalia.c
> --- sys/dev/pci/azalia.c  31 May 2020 04:58:38 -  1.256
> +++ sys/dev/pci/azalia.c  9 Jun 2020 02:59:36 -
> @@ -475,7 +475,8 @@ azalia_configure_pci(azalia_t *az)
>  }
>  
>  const struct pci_matchid azalia_pci_devices[] = {
> - { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_300SERIES_U_HDA }
> + { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_300SERIES_U_HDA },
> + { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_200SERIES_U_HDA }
>  };
>  
>  int
> 
> 
> 
> Domain /dev/pci0:
>  0:0:0: Intel Core 8G Host
>   0x: Vendor ID: 8086, Product ID: 5914
>   0x0004: Command: 0006, Status: 2090
>   0x0008: Class: 06 Bridge, Subclass: 00 Host,
>   Interface: 00, Revision: 08
>   0x000c: BIST: 00, Header Type: 00, Latency Timer: 00,
>   Cache Line Size: 00
>   0x0010: BAR empty ()
>   0x0014: BAR empty ()
>   0x0018: BAR empty ()
>   0x001c: BAR empty ()
>   0x0020: BAR empty ()
>   0x0024: BAR empty ()
>   0x0028: Cardbus CIS: 
>   0x002c: Subsystem Vendor ID: 17aa Product ID: 3821
>   0x0030: Expansion ROM Base Address: 
>   0x0038: 
>   0x003c: Interrupt Pin: 00 Line: 00 Min Gnt: 00 Max Lat: 00
>   0x00e0: Capability 0x09: Vendor Specific
>  0:2:0: Intel UHD Graphics 620
>   0x: Vendor ID: 8086, Product ID: 5917
>   0x0004: Command: 0007, Status: 0010
>   0x0008: Class: 03 Display, Subclass: 00 VGA,
>   Interface: 00, Revision: 07
>   0x000c: BIST: 00, Header Type: 00, Latency Timer: 00,
>   Cache Line Size: 10
>   0x0010: BAR mem 64bit addr: 0x002ffa00/0x0100
>   0x0018: BAR mem prefetchable 64bit addr: 0x002fa000/0x1000
>   0x0020: BAR io addr: 0x3000/0x0040
>   0x0024: BAR empty ()
>   0x0028: Cardbus CIS: 
>   0x002c: Subsystem Vendor ID: 17aa Product ID: 3803
>   0x0030: Expansion ROM Base Address: 
>   0x0038: 
>   0x003c: Interrupt Pin: 01 Line: ff Min Gnt: 00 Max Lat: 00

Re: [patch] azalia: Intel 300 Series HD Audio

2020-05-29 Thread Jonathan Gray
On Fri, May 29, 2020 at 11:25:44AM +0200, Bruno Flueckiger wrote:
> Hi,
> 
> My brand new laptop HP EliteBook 850 G6 comes with an Intel 300 Series
> HD Audio device rev 0x11. The device shows up as not configured in the
> dmesg. The PCI config space of the device identifies its subclass as
> PCI_SUBCLASS_MULTIMEDIA_AUDIO instead of PCI_SUBCLASS_MULTIMEDIA_HDAUDIO
> 
> The patch below makes the device work just fine on my laptop.
> 
> Cheers,
> Bruno

I think it would be better to match on the id in that case as non-azalia
devices use the audio class.

Index: azalia.c
===
RCS file: /cvs/src/sys/dev/pci/azalia.c,v
retrieving revision 1.255
diff -u -p -r1.255 azalia.c
--- azalia.c18 Apr 2020 21:55:56 -  1.255
+++ azalia.c29 May 2020 09:51:06 -
@@ -474,6 +474,10 @@ azalia_configure_pci(azalia_t *az)
}
 }
 
+const struct pci_matchid azalia_pci_devices[] = {
+   { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_300SERIES_U_HDA }
+};
+
 int
 azalia_pci_match(struct device *parent, void *match, void *aux)
 {
@@ -483,7 +487,8 @@ azalia_pci_match(struct device *parent, 
if (PCI_CLASS(pa->pa_class) == PCI_CLASS_MULTIMEDIA
&& PCI_SUBCLASS(pa->pa_class) == PCI_SUBCLASS_MULTIMEDIA_HDAUDIO)
return 1;
-   return 0;
+   return pci_matchbyid((struct pci_attach_args *)aux, azalia_pci_devices,
+   nitems(azalia_pci_devices));
 }
 
 void



Re: clear margins when remapping efifb

2020-05-28 Thread Jonathan Gray
On Thu, May 28, 2020 at 12:23:26PM +0200, Frederic Cambus wrote:
> On Wed, May 27, 2020 at 12:25:00PM +0200, Mark Kettenis wrote:
> > > Date: Wed, 27 May 2020 19:39:07 +1000
> > > From: Jonathan Gray 
> > > 
> > > When testing the row and column increase for efifb on a 1920x1080
> > > display I noticed the top part of the screen continues to contain part
> > > of a white on blue line from earlier in the dmesg even after the machine
> > > has finished booting.
> > > 
> > > RI_CENTER changes the ri_bits offset, doing RI_CLEARMARGINS in cnremap
> > > clears the fragment of a line caused by using RI_CENTER.
> > 
> > ok kettenis@
> 
> I had a different fix for this issue, which prevents the margins to
> appear in the first place.
> 
> This is why the margins appear:
> 
> In rasops(9), if 'ri_emuwidth' is larger than 'ri_width', it is set to
> 'ri_width', and similarly for 'ri_emuheight' relative to 'ri_height'.
> 
> In efifb_cnattach_common(), we call rasops_init() with EFIFB_HEIGHT
> and EFIFB_WIDTH as parameters, so on smaller screens or with larger
> fonts, or when increasing the EFIFB_HEIGHT and EFIFB_WIDTH values,
> 'ri_emu{width,height}' becomes equals to 'ri_{width,height}' and no
> centering happens.
> 
> Then in efifb_cnremap() and efifb_attach(), efifb_std_descr.nrows and
> efifb_std_descr.ncols are used instead, and in this case 'ri_emuwidth'
> and 'ri_emuheight' can now be a few pixels smaller than 'ri_width' and
> 'ri_height' and the text area is centered where it previously wasn't,
> causing the content previously displayed in what are now margins to
> remain there.
> 
> Here is a rebased version of the diff:
> 
> Index: sys/arch/amd64/amd64/efifb.c
> ===
> RCS file: /cvs/src/sys/arch/amd64/amd64/efifb.c,v
> retrieving revision 1.31
> diff -u -p -r1.31 efifb.c
> --- sys/arch/amd64/amd64/efifb.c  27 May 2020 07:48:02 -  1.31
> +++ sys/arch/amd64/amd64/efifb.c  28 May 2020 07:17:49 -
> @@ -222,7 +222,7 @@ efifb_attach(struct device *parent, stru
>   ri->ri_flg &= ~RI_CLEAR;
>   ri->ri_flg |= RI_VCONS | RI_WRONLY;
>  
> - rasops_init(ri, efifb_std_descr.nrows, efifb_std_descr.ncols);
> + rasops_init(ri, EFIFB_HEIGHT, EFIFB_WIDTH);
>  
>   ri->ri_ops.pack_attr(ri->ri_active, 0, 0, 0, );
>   wsdisplay_cnattach(_std_descr, ri->ri_active, ccol, crow,
> @@ -480,7 +480,7 @@ efifb_cnremap(void)
>   ri->ri_flg &= ~RI_CLEAR;
>   ri->ri_flg |= RI_CENTER | RI_WRONLY;
>  
> - rasops_init(ri, efifb_std_descr.nrows, efifb_std_descr.ncols);
> + rasops_init(ri, EFIFB_HEIGHT, EFIFB_WIDTH);
>  
>   efifb_early_cleanup();
>  }
> 
> Because the efifb resolution doesn't change, this ensures 'ri_emuwidth'
> and 'ri_emuheight' will always get the same value when we remap and
> later when we attach, so the text area is always displayed at the same
> position.
> 
> I verified it still works, and it solves the issue for me on a 1920x1080
> screen.
> 
> It was commited [1] and reverted [2] at the time we tried to increase
> EFIFB_HEIGHT / EFIFB_WIDTH. I reverted it to be on the safe side as we
> were nearing a release and it wasn't useful on its own after reverting
> the other changes.
> 
> [1] 
> https://cvsweb.openbsd.org/src/sys/arch/amd64/amd64/efifb.c?rev=1.20=text/x-cvsweb-markup
> [2] 
> https://cvsweb.openbsd.org/src/sys/arch/amd64/amd64/efifb.c?rev=1.23=text/x-cvsweb-markup

Thanks I missed that commit in the log.

The result of your diff is the area the text starts at is higher on the
panel matching amdgpu and there are no glitches when booting via efi
with amdgpu disabled.

ok jsg@



Re: diff: init efifb even if VGA is probed.

2020-05-28 Thread Jonathan Gray
On Thu, May 28, 2020 at 02:06:28PM +0200, Mark Kettenis wrote:
> > Date: Thu, 28 May 2020 20:49:18 +0900 (JST)
> > From: YASUOKA Masahiko 
> > 
> > On Thu, 28 May 2020 12:31:31 +0200 (CEST)
> > Mark Kettenis  wrote:
> > >> Date: Thu, 28 May 2020 17:01:48 +0900 (JST)
> > >> From: YASUOKA Masahiko 
> > >> 
> > >> Hi,
> > >> 
> > >> I'd like to conclude this issue.
> > >> 
> > >> On Fri, 21 Feb 2020 14:09:07 +0900 (JST)
> > >> YASUOKA Masahiko  wrote:
> > >> > I am testing a new hardware, HPE DL20 Gen10.
> > >> > 
> > >> > When efiboot starts the kernel, the video display becomes distorted
> > >> > and never recovered until CPU reset.
> > >> > 
> > >> > Our kernel tries to initialized console twice, first trial is done
> > >> > before getting boot info and second trial is done after getting boot
> > >> > info.  Since EFI framebuffer needs "boot info", it is initialized on
> > >> > second trial.
> > >> > 
> > >> > On HPE DL20 Gen10, probing vga is succeeded on first trial, the kernel
> > >> > selects vga for the console, but actually it is broken.  On usual
> > >> > machines which boot with EFI, the problem doesn't happen since they
> > >> > have no vga.
> > >> 
> > >> If we have a way to detect whether the machine has VGA.  ACPI
> > >> FADT_NO_VGA was a candidate.  But that bit is cleard both on my "HPE
> > >> DL20 Gen10" and Andrew Daugherity's Dell PowerEdge R230.  Also the
> > >> problem newly posted at misc@ (*) might be the same problem.
> > >> 
> > >>  (*) https://marc.info/?l=openbsd-misc=159064773219779=2
> > >> 
> > >> I think having the diff folowing is the best for this momemnt.
> > >> The diff does:
> > >> 
> > >>   - move cninit() after parsing bootinfo
> > >>   - give up the debug message which can be enabled if BOOTINFO_DEBUG is 
> > >> defined
> > >> 
> > >> ok?
> > > 
> > > I suspect we have to accept that there is too much broken hardware out
> > > there.
> > 
> > Finally we might have no way other than having a configuration in
> > boot.conf...
> > 
> > > There is no real reason to drop the debug messages.
> > 
> > OK, the debug messages are reverted.
> > 
> > > I'd prefer to call cninit() directly from init_x86_64, so I'd just
> > > move the call immediately after the block that calls getbootinfo().
> > > And emove the call from getbootinfo() of course.
> > 
> > I think the last diff already satisfied these things.
> > 
> > >> @@ -1395,11 +1395,6 @@ init_x86_64(paddr_t first_avail)
> > >>  i8254_startclock();
> > >>  
> > >>  /*
> > >> - * Attach the glass console early in case we need to display a 
> > >> panic.
> > >> - */
> > >> -cninit();
> > >> -
> > >> -/*
> > >>   * Initialize PAGE_SIZE-dependent variables.
> > >>   */
> > >>  uvm_setpagesize();
> > >> @@ -1421,6 +1416,8 @@ init_x86_64(paddr_t first_avail)
> > >>  } else
> > >>  panic("invalid /boot");
> > >>  
> > >> +cninit();
> > >> +
> > >>  /*
> > >>   * Memory on the AMD64 port is described by three different things.
> > >>   *
> > 
> > A hidden line which calls getbootinfo() is at just before second
> > chunk.  The updated diff was created with "-U 4" to clarify this.
> > 
> > Alternatively, are you suggesting
> > 
> > getbootinfo(bootinfo, bootinfo_size);
> > +   cninit();
> > } else
> > panic("invalid /boot");
> > 
> > ?
> > 
> > Both is OK for me.
> > 
> > How about this?
> 
> The attached diff looks good to me.
> 
> ok kettenis@

ok jsg@ on this one as well

> 
> > Index: sys/arch/amd64/amd64/machdep.c
> > ===
> > RCS file: /cvs/src/sys/arch/amd64/amd64/machdep.c,v
> > retrieving revision 1.264
> > diff -u -p -U4 -r1.264 machdep.c
> > --- sys/arch/amd64/amd64/machdep.c  16 May 2020 14:44:44 -  1.264
> > +++ sys/arch/amd64/amd64/machdep.c  28 May 2020 11:34:39 -
> > @@ -1394,13 +1394,8 @@ init_x86_64(paddr_t first_avail)
> >  
> > i8254_startclock();
> >  
> > /*
> > -* Attach the glass console early in case we need to display a panic.
> > -*/
> > -   cninit();
> > -
> > -   /*
> >  * Initialize PAGE_SIZE-dependent variables.
> >  */
> > uvm_setpagesize();
> >  
> > @@ -1420,8 +1415,10 @@ init_x86_64(paddr_t first_avail)
> > getbootinfo(bootinfo, bootinfo_size);
> > } else
> > panic("invalid /boot");
> >  
> > +   cninit();
> > +
> >  /*
> >   * Memory on the AMD64 port is described by three different things.
> >   *
> >   * 1. biosbasemem - This is outdated, and should really only be used to
> > @@ -1926,10 +1923,8 @@ getbootinfo(char *bootinfo, int bootinfo
> > bootarg32_t *q;
> > bios_ddb_t *bios_ddb;
> > bios_bootduid_t *bios_bootduid;
> > bios_bootsr_t *bios_bootsr;
> > -   int docninit = 0;
> > -
> >  #undef BOOTINFO_DEBUG
> >  #ifdef BOOTINFO_DEBUG
> > printf("bootargv:");
> >  #endif
> > @@ -1982,11 +1977,8 @@ getbootinfo(char 

Re: diff: init efifb even if VGA is probed.

2020-05-28 Thread Jonathan Gray
On Thu, May 28, 2020 at 05:19:19PM +0900, YASUOKA Masahiko wrote:
> On Thu, 28 May 2020 17:01:48 +0900 (JST)
> YASUOKA Masahiko  wrote:
> > Hi,
> > 
> > I'd like to conclude this issue.
> > 
> > On Fri, 21 Feb 2020 14:09:07 +0900 (JST)
> > YASUOKA Masahiko  wrote:
> >> I am testing a new hardware, HPE DL20 Gen10.
> >> 
> >> When efiboot starts the kernel, the video display becomes distorted
> >> and never recovered until CPU reset.
> >> 
> >> Our kernel tries to initialized console twice, first trial is done
> >> before getting boot info and second trial is done after getting boot
> >> info.  Since EFI framebuffer needs "boot info", it is initialized on
> >> second trial.
> >> 
> >> On HPE DL20 Gen10, probing vga is succeeded on first trial, the kernel
> >> selects vga for the console, but actually it is broken.  On usual
> >> machines which boot with EFI, the problem doesn't happen since they
> >> have no vga.
> > 
> > If we have a way to detect whether the machine has VGA.  ACPI
> > FADT_NO_VGA was a candidate.  But that bit is cleard both on my "HPE
> > DL20 Gen10" and Andrew Daugherity's Dell PowerEdge R230.  Also the
> > problem newly posted at misc@ (*) might be the same problem.
> 
> Above paragraph may be unclear.  Let me update it by the following
> paragraph.
> 
> If we have a way to detect whether the machine has VGA, we thought we
> can select VGA or EFI framebuffer safely.  ACPI FADT_NO_VGA was a
> candidate.  But the bit is cleared both on my "HPE DL20 Gen10" and
> Andrew Daugherity's Dell PowerEdge R230.  Also the problem newly
> posted at misc@ (*) might be the same problem.

I agree this approach of waiting for bootargs before probing for a
console is the best way to handle this at the moment unless someone
can come up with a way to stop vga matching.

I have tested this without problems on
bios boot serial console
bios boot vga/inteldrm console
efi boot efifb/amdgpu console

ok jsg@

> 
> >  (*) https://marc.info/?l=openbsd-misc=159064773219779=2
> > 
> > I think having the diff folowing is the best for this momemnt.
> > The diff does:
> > 
> >   - move cninit() after parsing bootinfo
> >   - give up the debug message which can be enabled if BOOTINFO_DEBUG is 
> > defined
> > 
> > ok?
> > 
> > Index: sys/arch/amd64/amd64/machdep.c
> > ===
> > RCS file: /disk/cvs/openbsd/src/sys/arch/amd64/amd64/machdep.c,v
> > retrieving revision 1.264
> > diff -u -p -r1.264 machdep.c
> > --- sys/arch/amd64/amd64/machdep.c  16 May 2020 14:44:44 -  1.264
> > +++ sys/arch/amd64/amd64/machdep.c  28 May 2020 07:40:14 -
> > @@ -1395,11 +1395,6 @@ init_x86_64(paddr_t first_avail)
> > i8254_startclock();
> >  
> > /*
> > -* Attach the glass console early in case we need to display a panic.
> > -*/
> > -   cninit();
> > -
> > -   /*
> >  * Initialize PAGE_SIZE-dependent variables.
> >  */
> > uvm_setpagesize();
> > @@ -1421,6 +1416,8 @@ init_x86_64(paddr_t first_avail)
> > } else
> > panic("invalid /boot");
> >  
> > +   cninit();
> > +
> >  /*
> >   * Memory on the AMD64 port is described by three different things.
> >   *
> > @@ -1927,12 +1924,6 @@ getbootinfo(char *bootinfo, int bootinfo
> > bios_ddb_t *bios_ddb;
> > bios_bootduid_t *bios_bootduid;
> > bios_bootsr_t *bios_bootsr;
> > -   int docninit = 0;
> > -
> > -#undef BOOTINFO_DEBUG
> > -#ifdef BOOTINFO_DEBUG
> > -   printf("bootargv:");
> > -#endif
> >  
> > for (q = (bootarg32_t *)bootinfo;
> > (q->ba_type != BOOTARG_END) &&
> > @@ -1942,24 +1933,15 @@ getbootinfo(char *bootinfo, int bootinfo
> > switch (q->ba_type) {
> > case BOOTARG_MEMMAP:
> > bios_memmap = (bios_memmap_t *)q->ba_arg;
> > -#ifdef BOOTINFO_DEBUG
> > -   printf(" memmap %p", bios_memmap);
> > -#endif
> > break;
> > case BOOTARG_DISKINFO:
> > bios_diskinfo = (bios_diskinfo_t *)q->ba_arg;
> > -#ifdef BOOTINFO_DEBUG
> > -   printf(" diskinfo %p", bios_diskinfo);
> > -#endif
> > break;
> > case BOOTARG_APMINFO:
> > /* generated by i386 boot loader */
> > break;
> > case BOOTARG_CKSUMLEN:
> > bios_cksumlen = *(u_int32_t *)q->ba_arg;
> > -#ifdef BOOTINFO_DEBUG
> > -   printf(" cksumlen %d", bios_cksumlen);
> > -#endif
> > break;
> > case BOOTARG_PCIINFO:
> > /* generated by i386 boot loader */
> > @@ -1983,15 +1965,8 @@ getbootinfo(char *bootinfo, int bootinfo
> > comconsaddr = consaddr;
> > comconsrate = cdp->conspeed;
> > comconsiot = X86_BUS_SPACE_IO;
> > -
> > -   /* Probe the serial port this time. */
> > -   

clear margins when remapping efifb

2020-05-27 Thread Jonathan Gray
When testing the row and column increase for efifb on a 1920x1080
display I noticed the top part of the screen continues to contain part
of a white on blue line from earlier in the dmesg even after the machine
has finished booting.

RI_CENTER changes the ri_bits offset, doing RI_CLEARMARGINS in cnremap
clears the fragment of a line caused by using RI_CENTER.

Index: efifb.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/efifb.c,v
retrieving revision 1.31
diff -u -p -r1.31 efifb.c
--- efifb.c 27 May 2020 07:48:02 -  1.31
+++ efifb.c 27 May 2020 09:27:50 -
@@ -219,7 +219,7 @@ efifb_attach(struct device *parent, stru
crow = ri->ri_crow;
 
efifb_rasops_preinit(fb);
-   ri->ri_flg &= ~RI_CLEAR;
+   ri->ri_flg &= ~(RI_CLEAR | RI_CLEARMARGINS);
ri->ri_flg |= RI_VCONS | RI_WRONLY;
 
rasops_init(ri, efifb_std_descr.nrows, efifb_std_descr.ncols);
@@ -478,7 +478,7 @@ efifb_cnremap(void)
 
efifb_rasops_preinit(fb);
ri->ri_flg &= ~RI_CLEAR;
-   ri->ri_flg |= RI_CENTER | RI_WRONLY;
+   ri->ri_flg |= RI_CENTER | RI_WRONLY | RI_CLEARMARGINS;
 
rasops_init(ri, efifb_std_descr.nrows, efifb_std_descr.ncols);
 



Re: TP-Link TL-WN822N-EU v5 USB ID

2020-05-26 Thread Jonathan Gray
On Mon, May 25, 2020 at 11:27:27PM +0300, Tero Koskinen wrote:
> Hi,
> 
> I have TP-Link TL-WN822N-EU v5 USB adapter[1] with
> USB VID/PID 2357:0108:
> 
> $ usbdevs
> Controller /dev/usb0:
> addr 01: 1022: AMD, xHCI root hub
> addr 02: 2357:0108 Realtek, 802.11n NIC
> Controller /dev/usb1:
> addr 01: 1022: AMD, EHCI root hub
> addr 02: 0438:7900 Advanced Micro Devices, Hub
> $
> 
> Patch at the end adds it to the usbdevs. I hope I got it right
> as I added it between existing 0x0107 and 0x0109 IDs.
> 
> Relevant dmesg bits with the patch:
> urtwn0 at uhub0 port 3 configuration 1 interface 0 "Realtek 802.11n NIC" rev 
> 2.10/2.00 addr 2
> urtwn0: MAC/BB RTL8192EU, RF 6052 2T2R, address 50:3e:aa:24:32:9e
> uhub2 at uhub1 port 1 configuration 1 interface 0 "Advanced Micro Devices 
> Hub" rev 2.00/0.18 addr 2
> 
> Full dmesg at https://tkoskine.me/dmesg.tplink-TL-WN822N.txt
> 
> Yours,
>  Tero

thanks, committed



Re: [PATCH} efifb support for wsmoused + smaller fonts

2020-05-25 Thread Jonathan Gray
On Mon, May 25, 2020 at 08:49:23AM -0500, Lucas Raab wrote:
> On Mon, May 25, 2020 at 09:13:43PM +1000, Jonathan Gray wrote:
> > On Sun, May 24, 2020 at 05:01:16PM -0700, jo...@armadilloaerospace.com 
> > wrote:
> > > The efifb driver behaves almost identically to the inteldrm driver
> > > for wscons, but did not implement the getchar() accessops, so
> > > wsmoused would fail at startup.
> > 
> > This seems reasonable, though your mail client has line wrapped the
> > patch so it won't apply.  In this case it is simple enough to apply by
> > hand.
> > 
> > > Separately, I increased the maximum screen dimensions to 160x50 to
> > > allow the 12x24 font to be used on an 1920 monitor, which looks great!
> > 
> > Something similiar was done and reverted as it somehow broke inteldrm
> > taking the fb over from efifb on a 4k display.  Perhaps someone with a
> > 4k display can confirm if this is still a problem.
> > 
> > https://marc.info/?l=openbsd-bugs=155337866226121=2
> > 
> > That was back before we deferred most of inteldrm to when the root fs is
> > mounted and interrupts are available.  And just before the last big drm
> > update by the look of it.
> 
> I tried out the patch twice, once with John's value for EFIFB_HEIGHT of
> 50 and once with the original original value of 160. The behavior of
> the bug report I submitted doesn't reappear so it looks everything is
> working as intended. This is with the same monitor as in the bug report

Thanks for testing.  I've committed the wsmoused part on it's own, so
how about we try rev 1.21 again?

Index: efifb.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/efifb.c,v
retrieving revision 1.30
diff -u -p -r1.30 efifb.c
--- efifb.c 25 May 2020 14:12:04 -  1.30
+++ efifb.c 25 May 2020 14:20:25 -
@@ -115,8 +115,8 @@ const struct cfattach efifb_ca = {
sizeof(struct efifb_softc), efifb_match, efifb_attach, NULL
 };
 
-#defineEFIFB_WIDTH 100
-#defineEFIFB_HEIGHT31
+#defineEFIFB_WIDTH 160
+#defineEFIFB_HEIGHT160
 
 struct wsscreen_descr efifb_std_descr = { "std" };
 



Re: [PATCH} efifb support for wsmoused + smaller fonts

2020-05-25 Thread Jonathan Gray
On Sun, May 24, 2020 at 05:01:16PM -0700, jo...@armadilloaerospace.com wrote:
> The efifb driver behaves almost identically to the inteldrm driver
> for wscons, but did not implement the getchar() accessops, so
> wsmoused would fail at startup.

This seems reasonable, though your mail client has line wrapped the
patch so it won't apply.  In this case it is simple enough to apply by
hand.

> Separately, I increased the maximum screen dimensions to 160x50 to
> allow the 12x24 font to be used on an 1920 monitor, which looks great!

Something similiar was done and reverted as it somehow broke inteldrm
taking the fb over from efifb on a 4k display.  Perhaps someone with a
4k display can confirm if this is still a problem.

https://marc.info/?l=openbsd-bugs=155337866226121=2

That was back before we deferred most of inteldrm to when the root fs is
mounted and interrupts are available.  And just before the last big drm
update by the look of it.


revision 1.22
date: 2019/03/25 14:17:58;  author: fcambus;  state: Exp;  lines: +3 -3;  
commitid: hL9P1vyWGBp5FHhE;
Revert back to using previous values for EFIFB_WIDTH and EFIFB_HEIGHT,
as raising them expose an issue which breaks inteldrm on large screen
resolutions.

Reported by chris@, and by Lucas Raab on bugs@. Thanks!

revision 1.21
date: 2019/03/16 13:16:49;  author: fcambus;  state: Exp;  lines: +3 -3;  
commitid: wsqjyS7rXDKbqGS3;
Now that efifb(4) supports remapping the framebuffer in write combining
mode, it's fast enough to raise the maximum size of the EFI framebuffer
console.

Set it to 160 columns and 160 rows, to match inteldrm and radeondrm.

OK jcs@, kettenis@


> 
> Unlike the intel driver, efifb has a static buffer of that size,
> which is a non-trivial amount of memory.  Not setting the backing
> store to save the memory results in an ultra-slow console until the
> driver gets fully initialized, because it is doing scrolls by reading
> from write combined memory instead of the redrawing all the
> characters.
> 
> I plan on changing that to a dynamic allocation once I am more
> comfortable with the reinitialization that goes on when autoconf
> gets around to the console display device, so feel free to punt on
> that if you want to wait.

Drivers which can act as a console have a cnattach function for very
early init and then later probe again and run attach.  In the case of
efifb there is also efifb_cnremap() which is called when mainbus
attaches.  The drm drivers call efifb_detach() to stop autoconf from
doing the normal probe/attach when taking over the console.



Re: Code changes for clarity

2020-05-21 Thread Jonathan Gray
On Mon, May 18, 2020 at 07:49:11AM -, Miod Vallat wrote:
> 
> > For instance, in the wsdisplay_emulops structure, there are:
> >
> > int (*alloc_attr)(void *c, int fg, int bg, int flags, long *attrp);
> > void(*unpack_attr)(void *c, long attr, int *fg, int *bg, int *ul);
> >
> > And at the end of the structure is this comment, showing that at
> > least someone (other than me) was confused by it:
> > /* XXX need a free_attr() ??? */
> 
> `alloc_attr' was named that way because there was a theoretical
> possibility that drivers would actually need to allocate storage for
> attribute-related information (which is why attributes are longs rather
> than uint32_t). A `free_attr' routine would then make sense, except that
> there is no clear lifetime for attributes (e.g. the kernel messages
> attribute has to survive free_screen).
> 
> Since in practice, no driver actually allocates anything and all
> attributes fit in either 8 bits (vga text mode) or 32 bits (rasops), it
> would make sense to rename this function to `compute_attr' or
> `pack_attr' and narrow the attribute type from `long' to `uint32_t'.
> 
> $.02
> 
> Miod

here is a type change diff against a tree with the pack_attr rename

builds on amd64, i386 and sparc64

diff --git sys/arch/alpha/tc/cfb.c sys/arch/alpha/tc/cfb.c
index 64b1f3f32f9..9b623b19dd6 100644
--- sys/arch/alpha/tc/cfb.c
+++ sys/arch/alpha/tc/cfb.c
@@ -101,7 +101,7 @@ paddr_t cfbmmap(void *, off_t, int);
 
 intcfbintr(void *);
 static int  cfb_alloc_screen(void *, const struct wsscreen_descr *,
-   void **, int *, int *, long *);
+   void **, int *, int *, uint32_t *);
 static void cfb_free_screen(void *, void *);
 static int  cfb_show_screen(void *, void *, int,
void (*) (void *, int, int), void *);
@@ -330,10 +330,10 @@ cfb_alloc_screen(v, type, cookiep, curxp, curyp, attrp)
const struct wsscreen_descr *type;
void **cookiep;
int *curxp, *curyp;
-   long *attrp;
+   uint32_t *attrp;
 {
struct cfb_softc *sc = v;
-   long defattr;
+   uint32_t defattr;
 
if (sc->nscreens > 0)
return (ENOMEM);
@@ -377,7 +377,7 @@ cfb_cnattach(addr)
tc_addr_t addr;
 {
struct cfb_devconfig *dc = _console_dc;
-   long defattr;
+   uint32_t defattr;
 
cfb_getdevconfig(addr, dcp);
 
diff --git sys/arch/alpha/tc/sfb.c sys/arch/alpha/tc/sfb.c
index b491b03d30f..08f8779aea2 100644
--- sys/arch/alpha/tc/sfb.c
+++ sys/arch/alpha/tc/sfb.c
@@ -99,7 +99,7 @@ int   sfbioctl(void *, u_long, caddr_t, int, struct proc *);
 paddr_tsfbmmap(void *, off_t, int);
 
 static int  sfb_alloc_screen(void *, const struct wsscreen_descr *,
-   void **, int *, int *, long *);
+   void **, int *, int *, uint32_t *);
 static void sfb_free_screen(void *, void *);
 static int  sfb_show_screen(void *, void *, int,
void (*) (void *, int, int), void *);
@@ -363,10 +363,10 @@ sfb_alloc_screen(v, type, cookiep, curxp, curyp, attrp)
 const struct wsscreen_descr *type;
 void **cookiep;
 int *curxp, *curyp;
-   long *attrp;
+   uint32_t *attrp;
 {
 struct sfb_softc *sc = v;
-   long defattr;
+   uint32_t defattr;
 
 if (sc->nscreens > 0)
 return (ENOMEM);
@@ -411,7 +411,7 @@ sfb_cnattach(addr)
 tc_addr_t addr;
 {
 struct sfb_devconfig *dcp = _console_dc;
-   long defattr;
+   uint32_t defattr;
 
 sfb_getdevconfig(addr, dcp);

diff --git sys/arch/amd64/amd64/efifb.c sys/arch/amd64/amd64/efifb.c
index eb62ae07137..2dca5e0205d 100644
--- sys/arch/amd64/amd64/efifb.c
+++ sys/arch/amd64/amd64/efifb.c
@@ -96,7 +96,7 @@ void   efifb_rasops_preinit(struct efifb *);
 int efifb_ioctl(void *, u_long, caddr_t, int, struct proc *);
 paddr_t efifb_mmap(void *, off_t, int);
 int efifb_alloc_screen(void *, const struct wsscreen_descr *, void **,
-   int *, int *, long *);
+   int *, int *, uint32_t *);
 voidefifb_free_screen(void *, void *);
 int efifb_show_screen(void *, void *, int, void (*cb) (void *, int, int),
void *);
@@ -211,7 +211,7 @@ efifb_attach(struct device *parent, struct device *self, 
void *aux)
printf(": %dx%d, %dbpp\n", ri->ri_width, ri->ri_height, ri->ri_depth);
 
if (console) {
-   long defattr = 0;
+   uint32_t defattr = 0;
 
ccol = ri->ri_ccol;
crow = ri->ri_crow;
@@ -346,7 +346,7 @@ efifb_mmap(void *v, off_t off, int prot)
 
 int
 efifb_alloc_screen(void *v, const struct wsscreen_descr *descr,
-void **cookiep, int *curxp, int *curyp, long *attrp)
+void **cookiep, int *curxp, int *curyp, uint32_t *attrp)
 {
struct efifb_softc  *sc = v;
struct rasops_info  *ri = >sc_fb->rinfo;
@@ -430,7 +430,7 @@ 

Re: Code changes for clarity

2020-05-18 Thread Jonathan Gray
On Sun, May 17, 2020 at 02:20:08PM +1000, Jonathan Gray wrote:
> On Sat, May 16, 2020 at 12:13:37PM -0700, jo...@armadilloaerospace.com wrote:
> > (Not sure if this belongs in tech@ or misc@)
> 
> I think tech@ is fine for discussion of code.
> 
> > 
> > What is the thinking around non-functional code changes that just
> > improve clarity without functionality changes?  I can imagine bad
> > experiences with that, but there is certainly room for improvement.
> 
> Split out from any functional changes I don't see a problem.
> 
> > 
> > For instance, in the wsdisplay_emulops structure, there are:
> > 
> > int (*alloc_attr)(void *c, int fg, int bg, int flags, long *attrp);
> > void(*unpack_attr)(void *c, long attr, int *fg, int *bg, int *ul);
> > 
> > And at the end of the structure is this comment, showing that at
> > least someone (other than me) was confused by it:
> > /* XXX need a free_attr() ??? */
> > 
> > I would suggest that alloc_attr should be renamed to pack_attr, but
> > there are 84 matches on alloc_attr across 39 unique files.
> 
> While alloc_attr() predates unpack_attr() I agree that pack_attr()
> would be a better name.  And yes it seems quite a few drivers
> across multiple architectures would need to be changed.

here is a rename diff

It is clear that alpha tc fbs are not built as we don't have
dev/rcons/raster.h etc in the tree.

diff --git sys/arch/alpha/tc/cfb.c sys/arch/alpha/tc/cfb.c
index e2b9e7bff7a..64b1f3f32f9 100644
--- sys/arch/alpha/tc/cfb.c
+++ sys/arch/alpha/tc/cfb.c
@@ -77,7 +77,7 @@ struct wsdisplay_emulops cfb_emulfuncs = {
rcons_erasecols,
rcons_copyrows,
rcons_eraserows,
-   rcons_alloc_attr
+   rcons_pack_attr
 };
 
 struct wsscreen_descr cfb_stdscreen = {
@@ -341,7 +341,7 @@ cfb_alloc_screen(v, type, cookiep, curxp, curyp, attrp)
*cookiep = >sc_dc->dc_rcons; /* one and only for now */
*curxp = 0;
*curyp = 0;
-   rcons_alloc_attr(>sc_dc->dc_rcons, 0, 0, 0, );
+   rcons_pack_attr(>sc_dc->dc_rcons, 0, 0, 0, );
*attrp = defattr;
sc->nscreens++;
return(0);
@@ -381,7 +381,7 @@ cfb_cnattach(addr)
 
cfb_getdevconfig(addr, dcp);
 
-   rcons_alloc_attr(>dc_rcons, 0, 0, 0, );
+   rcons_pack_attr(>dc_rcons, 0, 0, 0, );

wsdisplay_cnattach(_stdscreen, >dc_rcons,
0,0, defattr;);
diff --git sys/arch/alpha/tc/sfb.c sys/arch/alpha/tc/sfb.c
index 81b80e09ee8..b491b03d30f 100644
--- sys/arch/alpha/tc/sfb.c
+++ sys/arch/alpha/tc/sfb.c
@@ -77,7 +77,7 @@ struct wsdisplay_emulops sfb_emulfuncs = {
 rcons_erasecols,
 rcons_copyrows,
 rcons_eraserows,
-rcons_alloc_attr
+rcons_pack_attr
 };
 
 struct wsscreen_descr sfb_stdscreen = {
@@ -374,7 +374,7 @@ sfb_alloc_screen(v, type, cookiep, curxp, curyp, attrp)
 *cookiep = >sc_dc->dc_rcons; /* one and only for now */
 *curxp = 0;
 *curyp = 0;
-   rcons_alloc_attr(>sc_dc->dc_rcons, 0, 0, 0, );
+   rcons_pack_attr(>sc_dc->dc_rcons, 0, 0, 0, );
*attrp = defattr;
sc->nscreens++;
 return (0);
@@ -415,7 +415,7 @@ sfb_cnattach(addr)
 
 sfb_getdevconfig(addr, dcp);

-   rcons_alloc_attr(>dc_rcons, 0, 0, 0, );
+   rcons_pack_attr(>dc_rcons, 0, 0, 0, );
 
 wsdisplay_cnattach(_stdscreen, >dc_rcons,
0, 0, defattr);
diff --git sys/arch/amd64/amd64/efifb.c sys/arch/amd64/amd64/efifb.c
index 69d6a01bad4..eb62ae07137 100644
--- sys/arch/amd64/amd64/efifb.c
+++ sys/arch/amd64/amd64/efifb.c
@@ -222,7 +222,7 @@ efifb_attach(struct device *parent, struct device *self, 
void *aux)
 
rasops_init(ri, efifb_std_descr.nrows, efifb_std_descr.ncols);
 
-   ri->ri_ops.alloc_attr(ri->ri_active, 0, 0, 0, );
+   ri->ri_ops.pack_attr(ri->ri_active, 0, 0, 0, );
wsdisplay_cnattach(_std_descr, ri->ri_active, ccol, crow,
defattr);
}
@@ -445,7 +445,7 @@ efifb_cnattach_common(void)
efifb_std_descr.fontheight = ri->ri_font->fontheight;
efifb_std_descr.capabilities = ri->ri_caps;
 
-   ri->ri_ops.alloc_attr(ri, 0, 0, 0, );
+   ri->ri_ops.pack_attr(ri, 0, 0, 0, );
wsdisplay_cnattach(_std_descr, ri, 0, 0, defattr);
 }
 
diff --git sys/arch/armv7/exynos/exdisplay.c sys/arch/armv7/exynos/exdisplay.c
index a80171fcc2b..41390aeb864 100644
--- sys/arch/armv7/exynos/exdisplay.c
+++ sys/arch/armv7/exynos/exdisplay.c
@@ -152,7 +152,7 @@ exdisplay_attach(struct device *parent, struct device 
*self, void *args)
ri->ri_bits = (u_char *)sc->sc_fbioh;
exdisplay_setup_rasops(ri, _stdscreen);
 
-   ri->

don't limit clflush to Intel

2020-05-17 Thread Jonathan Gray
Don't limit clflush to Intel processors.

This change will result in pmap_flush_cache() on AMD processors
changing from wbinvd to a clflush loop with mfence.

agp_flush_cache_range() uses pmap_flush_cache() but has no callers
agp_flush_cache() uses wbinvd
pmap_flush_cache() is used by drm_clflush_* which is used by ttm
(radeondrm and amdgpu) and inteldrm.

Index: amd64/amd64/identcpu.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/identcpu.c,v
retrieving revision 1.114
diff -u -p -r1.114 identcpu.c
--- amd64/amd64/identcpu.c  17 Mar 2020 03:09:04 -  1.114
+++ amd64/amd64/identcpu.c  18 May 2020 04:26:20 -
@@ -716,8 +716,8 @@ identifycpu(struct cpu_info *ci)
if (ci->ci_feature_sefflags_ebx & SEFF0EBX_SMAP)
replacesmap();
}
-#ifndef SMALL_KERNEL
-   if (!strncmp(mycpu_model, "Intel", 5)) {
+
+   if (ci->ci_feature_flags & CPUID_CFLUSH) {
u_int32_t cflushsz;
 
CPUID(0x01, dummy, cflushsz, dummy, dummy);
@@ -725,6 +725,7 @@ identifycpu(struct cpu_info *ci)
ci->ci_cflushsz = ((cflushsz >> 8) & 0xff) * 8;
}
 
+#ifndef SMALL_KERNEL
if (CPU_IS_PRIMARY(ci) && (ci->ci_feature_tpmflags & TPM_SENSOR)) {
strlcpy(ci->ci_sensordev.xname, ci->ci_dev->dv_xname,
sizeof(ci->ci_sensordev.xname));
Index: i386/i386/machdep.c
===
RCS file: /cvs/src/sys/arch/i386/i386/machdep.c,v
retrieving revision 1.633
diff -u -p -r1.633 machdep.c
--- i386/i386/machdep.c 16 May 2020 14:44:44 -  1.633
+++ i386/i386/machdep.c 18 May 2020 04:25:07 -
@@ -1847,6 +1847,17 @@ identifycpu(struct cpu_info *ci)
}
}
 
+   if (ci->ci_feature_flags & CPUID_CFLUSH) {
+   u_int regs[4];
+
+   /* to get the cacheline size you must do cpuid
+* with eax 0x01
+*/
+
+   cpuid(0x01, regs); 
+   ci->ci_cflushsz = ((regs[1] >> 8) & 0xff) * 8;
+   }
+
if (vendor == CPUVENDOR_INTEL) {
u_int regs[4];
/*
@@ -1859,15 +1870,6 @@ identifycpu(struct cpu_info *ci)
 */
if (ci->ci_family == 6 && ci->ci_model < 15)
ci->ci_feature_flags &= ~CPUID_PAT;
-
-   if (ci->ci_feature_flags & CPUID_CFLUSH) {
-   /* to get the cacheline size you must do cpuid
-* with eax 0x01
-*/
-
-   cpuid(0x01, regs); 
-   ci->ci_cflushsz = ((regs[1] >> 8) & 0xff) * 8;
-   }
 
if (cpuid_level >= 0x1) {
cpuid(0x8000, regs);



Re: Fix comment typo in if_bnx.c

2020-05-17 Thread Jonathan Gray
On Sat, May 16, 2020 at 11:26:26PM -0700, Delyan Raychev wrote:
> Pardon the triviality of this diff.  I'd like to use this to say Hi,
> learn the flow, and grow in contributions from here!
> 
> Thanks!

Thanks, committed.

This did not apply as your mail client stripped tabs.  Something to keep
in mind for future patches.

> 
> Index: sys/dev/pci/if_bnx.c
> ===
> RCS file: /cvs/src/sys/dev/pci/if_bnx.c,v
> retrieving revision 1.126
> diff -u -p -u -p -r1.126 if_bnx.c
> --- sys/dev/pci/if_bnx.c6 Dec 2019 01:58:47 -1.126
> +++ sys/dev/pci/if_bnx.c17 May 2020 06:17:06 -
> @@ -676,7 +676,7 @@ bnx_attach(struct device *parent, struct
>  BNX_PCICFG_MISC_CONFIG_REG_WINDOW_ENA |
>  BNX_PCICFG_MISC_CONFIG_TARGET_MB_WORD_SWAP);
> 
> -/* Save ASIC revsion info. */
> +/* Save ASIC revision info. */
>  sc->bnx_chipid =  REG_RD(sc, BNX_MISC_ID);
> 
>  /*
> 
> 



Re: Code changes for clarity

2020-05-16 Thread Jonathan Gray
On Sat, May 16, 2020 at 12:13:37PM -0700, jo...@armadilloaerospace.com wrote:
> (Not sure if this belongs in tech@ or misc@)

I think tech@ is fine for discussion of code.

> 
> What is the thinking around non-functional code changes that just
> improve clarity without functionality changes?  I can imagine bad
> experiences with that, but there is certainly room for improvement.

Split out from any functional changes I don't see a problem.

> 
> For instance, in the wsdisplay_emulops structure, there are:
> 
> int   (*alloc_attr)(void *c, int fg, int bg, int flags, long *attrp);
> void  (*unpack_attr)(void *c, long attr, int *fg, int *bg, int *ul);
> 
> And at the end of the structure is this comment, showing that at
> least someone (other than me) was confused by it:
>   /* XXX need a free_attr() ??? */
> 
> I would suggest that alloc_attr should be renamed to pack_attr, but
> there are 84 matches on alloc_attr across 39 unique files.

While alloc_attr() predates unpack_attr() I agree that pack_attr()
would be a better name.  And yes it seems quite a few drivers
across multiple architectures would need to be changed.

> 
> Similarly, I am taking notes as I read the code, and adding a few
> comments in various files and functions could help other people get
> up to speed much faster in the future, but I am hesitant to submit
> patches. I am hoping to write a decent article about my explorations,
> but inline comments are more durable documentation.

Comments here sound like a good thing.  wscons originated in NetBSD and
many of the people who have hacked on it in OpenBSD over the years are
no longer around.



update libelf from elftoolchain r3717 to r3833

2020-05-11 Thread Jonathan Gray
update libelf from elftoolchain r3717 to r3833
no need for a crank according to src/lib/check_sym


r3833 | jkoshy | 2020-03-02 18:19:04 +1100 (Mon, 02 Mar 2020) | 4 lines

Minor: add comments.

Ticket: [#584]


r3764 | emaste | 2019-06-29 07:44:46 +1000 (Sat, 29 Jun 2019) | 3 lines

libelf: add config for RISC-V ISA

Obtained from FreeBSD r294664 by br.

r3763 | emaste | 2019-06-29 07:43:27 +1000 (Sat, 29 Jun 2019) | 5 lines

libelf: assert that msz is non-zero

Reported by FreeBSD Coverity, CID 976023

Obtained from FreeBSD r316685 by emaste.

r3743 | jkoshy | 2019-06-13 05:36:30 +1000 (Thu, 13 Jun 2019) | 3 lines

Incorporate manual page fixes from OpenBSD.

Submitted by:   Sunil Nimmagadda

r3740 | jkoshy | 2019-05-06 15:18:34 +1000 (Mon, 06 May 2019) | 2 lines

Verify that only one of the LIBELF_F_RAWFILE_{MALLOC,MMAP}
flags is set on an ELF descriptor.

r3739 | jkoshy | 2019-05-06 15:18:15 +1000 (Mon, 06 May 2019) | 3 lines

Bug fix: use integer literals of the correct size.

Found by:   Coverity Scan

r3738 | jkoshy | 2019-05-06 07:49:06 +1000 (Mon, 06 May 2019) | 3 lines

Improve an internal API: a return type of 'void'
would be a better fit for an internal function that
never returns a usable value.

r3737 | jkoshy | 2019-05-06 00:49:50 +1000 (Mon, 06 May 2019) | 3 lines

Eliminate an always true sub-expression.

Pointed out by: Sunil Nimmagadda

r3736 | jkoshy | 2019-05-05 23:22:07 +1000 (Sun, 05 May 2019) | 3 lines

Add a few assertions.

Submitted by:   Sunil Nimmagadda

r3734 | jkoshy | 2019-04-23 00:10:49 +1000 (Tue, 23 Apr 2019) | 2 lines

Document the additional errors possible for the APIs
updated by revision r3732.

r3732 | jkoshy | 2019-04-22 21:08:38 +1000 (Mon, 22 Apr 2019) | 4 lines

Handle error returns from the _libelf_msize() helper
function consistently.

Pointed out by: Sunil Nimmagadda on -developers


Index: _libelf.h
===
RCS file: /cvs/src/lib/libelf/_libelf.h,v
retrieving revision 1.2
diff -u -p -r1.2 _libelf.h
--- _libelf.h   19 Mar 2019 02:31:35 -  1.2
+++ _libelf.h   11 May 2020 06:10:12 -
@@ -226,7 +226,7 @@ size_t  _libelf_msize(Elf_Type _t, int _e
 void   *_libelf_newphdr(Elf *_e, int _elfclass, size_t _count);
 Elf*_libelf_open_object(int _fd, Elf_Cmd _c, int _reporterror);
 struct _Libelf_Data *_libelf_release_data(struct _Libelf_Data *_d);
-Elf*_libelf_release_elf(Elf *_e);
+void   _libelf_release_elf(Elf *_e);
 Elf_Scn*_libelf_release_scn(Elf_Scn *_s);
 int_libelf_setphnum(Elf *_e, void *_eh, int _elfclass, size_t _phnum);
 int_libelf_setshnum(Elf *_e, void *_eh, int _elfclass, size_t _shnum);
Index: _libelf_config.h
===
RCS file: /cvs/src/lib/libelf/_libelf_config.h,v
retrieving revision 1.1
diff -u -p -r1.1 _libelf_config.h
--- _libelf_config.h1 Feb 2019 05:27:37 -   1.1
+++ _libelf_config.h11 May 2020 06:10:12 -
@@ -103,6 +103,12 @@
 #defineLIBELF_BYTEORDERELFDATA2LSB
 #defineLIBELF_CLASSELFCLASS64
 
+#elif  defined(__riscv64)
+
+#defineLIBELF_ARCH EM_RISCV
+#defineLIBELF_BYTEORDERELFDATA2LSB
+#defineLIBELF_CLASSELFCLASS64
+
 #elif  defined(__sparc__)
 
 #defineLIBELF_ARCH EM_SPARCV9
Index: elf.3
===
RCS file: /cvs/src/lib/libelf/elf.3,v
retrieving revision 1.4
diff -u -p -r1.4 elf.3
--- elf.3   11 Jun 2019 18:38:46 -  1.4
+++ elf.3   11 May 2020 06:10:12 -
@@ -23,7 +23,7 @@
 .\"
 .\" $Id: elf.3,v 1.4 2019/06/11 18:38:46 schwarze Exp $
 .\"
-.Dd February 5, 2019
+.Dd June 12, 2019
 .Dt ELF 3
 .Os
 .Sh NAME
Index: elf_data.c
===
RCS file: /cvs/src/lib/libelf/elf_data.c,v
retrieving revision 1.2
diff -u -p -r1.2 elf_data.c
--- elf_data.c  19 Mar 2019 02:31:35 -  1.2
+++ elf_data.c  11 May 2020 06:10:12 -
@@ -118,7 +118,8 @@ elf_getdata(Elf_Scn *s, 

Re: drm(4) kqfilter & EVFILT_READ

2020-04-27 Thread Jonathan Gray
On Mon, Apr 27, 2020 at 04:52:33PM +0200, Martin Pieuchot wrote:
> Diff below extends the existing drmkqfilter() to support EVFILT_READ.
> This makes drm(4)'s kqueue support in pair with poll().
> 
> The event list queried in the filt_drmread() should be protected by the
> `event_lock' mutex.  This could be done by using the `kdev' backpointer
> as shown in comment.  However this would require some plumbing to make
> use of `minor'.  The side effect of this approach would be to reduce the
> diff with Linux.

You seem to be confusing kdev and dev in the drm_minor struct.
at least in linux kdev is 'struct device *' and dev is
'struct drm_device *' (which has the event lock).
I have a tree which uses the drm_minor struct but it is part of a much
larger diff.

Could you explain what prompted this diff?

> 
> I'd be interested to hear if somebody sees a different approach.
> 
> That said, as long as the KERNEL_LOCK() is taken in all these code paths
> it should be safe to commit the filter as it is.
> 
> Comments, Oks?
> 
> Index: sys/conf.h
> ===
> RCS file: /cvs/src/sys/sys/conf.h,v
> retrieving revision 1.150
> diff -u -p -r1.150 conf.h
> --- sys/conf.h21 Apr 2020 08:29:27 -  1.150
> +++ sys/conf.h27 Apr 2020 14:43:48 -
> @@ -439,7 +439,7 @@ extern struct cdevsw cdevsw[];
>   (dev_type_stop((*))) enodev, 0, selfalse, \
>   (dev_type_mmap((*))) enodev }
>  
> -/* open, close, read, ioctl, poll, mmap, nokqfilter */
> +/* open, close, read, ioctl, poll, mmap, kqfilter */
>  #define  cdev_drm_init(c,n){ \
>   dev_init(c,n,open), dev_init(c,n,close), dev_init(c, n, read), \
>   (dev_type_write((*))) enodev, dev_init(c,n,ioctl), \
> Index: dev/pci/drm/drm_drv.c
> ===
> RCS file: /cvs/src/sys/dev/pci/drm/drm_drv.c,v
> retrieving revision 1.174
> diff -u -p -r1.174 drm_drv.c
> --- dev/pci/drm/drm_drv.c 7 Apr 2020 13:27:51 -   1.174
> +++ dev/pci/drm/drm_drv.c 27 Apr 2020 14:43:48 -
> @@ -484,6 +484,30 @@ filt_drmkms(struct knote *kn, long hint)
>   return (kn->kn_fflags != 0);
>  }
>  
> +void
> +filt_drmreaddetach(struct knote *kn)
> +{
> + struct drm_file *file_priv = kn->kn_hook;
> + int s;
> +
> + s = spltty();
> + klist_remove(_priv->rsel.si_note, kn);
> + splx(s);
> +}
> +
> +int
> +filt_drmread(struct knote *kn, long hint)
> +{
> + struct drm_file *file_priv = kn->kn_hook;
> + int  val = 0;
> +
> + //mtx_enter(_priv->minor->kdev->event_lock);
> + val = !list_empty(_priv->event_list);
> + //mtx_leave(_priv->minor->kdev->event_lock);
> +
> + return (val);
> +}
> +
>  const struct filterops drm_filtops = {
>   .f_flags= FILTEROP_ISFD,
>   .f_attach   = NULL,
> @@ -491,30 +515,51 @@ const struct filterops drm_filtops = {
>   .f_event= filt_drmkms,
>  };
>  
> +const struct filterops drmread_filtops = {
> + .f_flags= FILTEROP_ISFD,
> + .f_attach   = NULL,
> + .f_detach   = filt_drmreaddetach,
> + .f_event= filt_drmread,
> +};
> +
>  int
>  drmkqfilter(dev_t kdev, struct knote *kn)
>  {
>   struct drm_device   *dev = NULL;
> - int s;
> + struct drm_file *file_priv = NULL;
> + int  s;
>  
>   dev = drm_get_device_from_kdev(kdev);
>   if (dev == NULL || dev->dev_private == NULL)
>   return (ENXIO);
>  
>   switch (kn->kn_filter) {
> + case EVFILT_READ:
> + mutex_lock(>struct_mutex);
> + file_priv = drm_find_file_by_minor(dev, minor(kdev));
> + mutex_unlock(>struct_mutex);
> + if (file_priv == NULL)
> + return (ENXIO);
> +
> + kn->kn_fop = _filtops;
> + kn->kn_hook = file_priv;
> +
> + s = spltty();
> + klist_insert(_priv->rsel.si_note, kn);
> + splx(s);
> + break;
>   case EVFILT_DEVICE:
>   kn->kn_fop = _filtops;
> + kn->kn_hook = dev;
> +
> + s = spltty();
> + klist_insert(>note, kn);
> + splx(s);
>   break;
>   default:
>   return (EINVAL);
>   }
>  
> - kn->kn_hook = dev;
> -
> - s = spltty();
> - klist_insert(>note, kn);
> - splx(s);
> -
>   return (0);
>  }
>  
> @@ -772,7 +817,6 @@ out:
>   return (gotone);
>  }
>  
> -/* XXX kqfilter ... */
>  int
>  drmpoll(dev_t kdev, int events, struct proc *p)
>  {
> 
> 



Re: Kill cdev_mousewr_init()

2020-04-03 Thread Jonathan Gray
On Fri, Apr 03, 2020 at 10:56:32AM +0200, Martin Pieuchot wrote:
> Unused macro, found while auditing d_poll() functions, ok?

ok jsg@

> 
> Index: sys/conf.h
> ===
> RCS file: /cvs/src/sys/sys/conf.h,v
> retrieving revision 1.148
> diff -u -p -r1.148 conf.h
> --- sys/conf.h22 Jan 2020 23:06:05 -  1.148
> +++ sys/conf.h2 Apr 2020 15:29:59 -
> @@ -196,13 +196,6 @@ extern struct cdevsw cdevsw[];
>   (dev_type_stop((*))) enodev, 0, dev_init(c,n,poll), \
>   (dev_type_mmap((*))) enodev , 0, 0, dev_init(c,n,kqfilter) }
>  
> -/* open, close, read, write, ioctl, poll, nokqfilter */
> -#define  cdev_mousewr_init(c,n) { \
> - dev_init(c,n,open), dev_init(c,n,close), dev_init(c,n,read), \
> - dev_init(c,n,write), dev_init(c,n,ioctl), \
> - (dev_type_stop((*))) enodev, 0, dev_init(c,n,poll), \
> - (dev_type_mmap((*))) enodev }
> -
>  #define  cdev_notdef() { \
>   (dev_type_open((*))) enodev, (dev_type_close((*))) enodev, \
>   (dev_type_read((*))) enodev, (dev_type_write((*))) enodev, \
> 
> 



Re: usb(4): use cacheable buffers for data transfers (massive speedup)

2020-03-31 Thread Jonathan Gray
On Wed, Apr 01, 2020 at 12:58:23PM +1100, Jonathan Gray wrote:
> On Wed, Mar 18, 2020 at 01:41:06PM +0100, Patrick Wildt wrote:
> > On Wed, Mar 18, 2020 at 11:22:40AM +0100, Patrick Wildt wrote:
> > > Hi,
> > > 
> > > I've spent a few days investigating why USB ethernet adapters are so
> > > horribly slow on my ARMs.  Using dt(4) I realized that it was spending
> > > most of its time in memcpy.  But, why?  As it turns out, all USB data
> > > buffers are mapped COHERENT, which on some/most ARMs means uncached.
> > > Using cached data buffers makes the performance rise from 20 mbit/s to
> > > 200 mbit/s.  Quite a difference.
> > > 
> > > sys/dev/usb/usb_mem.c:
> > >   error = bus_dmamem_map(tag, p->segs, p->nsegs, p->size,
> > >  >kaddr, BUS_DMA_NOWAIT|BUS_DMA_COHERENT);
> > > 
> > > On x86, COHERENT is essentially a no-op.  On ARM, it depends on the SoC.
> > > Some SoCs have cache-coherent USB controllers, some don't.  Mine does
> > > not, so mapping it COHERENT means uncached and thus slow.
> > > 
> > > Why do we do that?  Well, when the code was imported in 99, it was
> > > already there.  Since then we have gained infrastructure for DMA
> > > syncs in the USB stack, which I think are proper.
> > > 
> > > sys/dev/usb/usbdi.c - usbd_transfer() (before transfer)
> > > 
> > >   if (!usbd_xfer_isread(xfer)) {
> > >   if ((xfer->flags & USBD_NO_COPY) == 0)
> > >   memcpy(KERNADDR(>dmabuf, 0), xfer->buffer,
> > >   xfer->length);
> > >   usb_syncmem(>dmabuf, 0, xfer->length,
> > >   BUS_DMASYNC_PREWRITE);
> > >   } else
> > >   usb_syncmem(>dmabuf, 0, xfer->length,
> > >   BUS_DMASYNC_PREREAD);
> > >   err = pipe->methods->transfer(xfer);
> > > 
> > > sys/dev/usb/usbdi.c - usb_transfer_complete() (after transfer)
> > > 
> > >   if (xfer->actlen != 0) {
> > >   if (usbd_xfer_isread(xfer)) {
> > >   usb_syncmem(>dmabuf, 0, xfer->actlen,
> > >   BUS_DMASYNC_POSTREAD);
> > >   if (!(xfer->flags & USBD_NO_COPY))
> > >   memcpy(xfer->buffer, KERNADDR(>dmabuf, 0),
> > >   xfer->actlen);
> > >   } else
> > >   usb_syncmem(>dmabuf, 0, xfer->actlen,
> > >   BUS_DMASYNC_POSTWRITE);
> > >   }
> > > 
> > > We cannot just remove COHERENT, since some drivers, like ehci(4), use
> > > the same backend to allocate their rings.  And I can't vouch for those
> > > drivers' sanity.
> > > 
> > > As a first step, I would like to go ahead with another solution, which
> > > is based on a diff from Marius Strobl, who added those syncs in the
> > > first place.  Essentially it splits the memory handling into cacheable
> > > and non-cacheable blocks.  The USB data transfers and everyone who uses
> > > usbd_alloc_buffer() then use cacheable buffers, while code like ehci(4)
> > > still don't.  This is a bit of a safer approach imho, since we don't
> > > hurt the controller drivers, but speed up the data buffers.
> > > 
> > > Once we have verified that there are no regressions, we can adjust
> > > ehci(4) and the like, add proper syncs, make sure they still work as
> > > well as before, and maybe then back this out again.
> > > 
> > > Keep note that this is all a no-op on X86, but all the other archs will
> > > profit from this.
> > > 
> > > ok?
> > > 
> > > Patrick
> > 
> > Update diff with inverted logic.  kettenis@ argues that we should
> > invert the logic, and those who need COHERENT memory should ask
> > for that explicitly, since for bus_dmamem_map() it also needs to
> > be passed explicitly.  This also points out all those users that
> > use usb_allocmem() internally, where we might want to have a look
> > if COHERENT is actually needed or not, or if it can be refactored
> > in another way.
> 
> These commits broke usb on imx.6 with cubox:
> 
> imxehci0 at simplebus3
> usb0 at imxehci0: USB revision 2.0
> usb0: root hub problem
> imxehci1 at simplebus3
> usb1 at imxehci1: USB revision 2.0
> usb1: root hub problem
> "usbmisc" at simplebus3 not configured

pandaboard with omap4 (another cortex a9) also has broken usb with
the latest snapshot:

omehci0 at simplebus0
usb0 at omehci0: USB revision 2.0
usb0: root hub problem



Re: usb(4): use cacheable buffers for data transfers (massive speedup)

2020-03-31 Thread Jonathan Gray
On Wed, Mar 18, 2020 at 01:41:06PM +0100, Patrick Wildt wrote:
> On Wed, Mar 18, 2020 at 11:22:40AM +0100, Patrick Wildt wrote:
> > Hi,
> > 
> > I've spent a few days investigating why USB ethernet adapters are so
> > horribly slow on my ARMs.  Using dt(4) I realized that it was spending
> > most of its time in memcpy.  But, why?  As it turns out, all USB data
> > buffers are mapped COHERENT, which on some/most ARMs means uncached.
> > Using cached data buffers makes the performance rise from 20 mbit/s to
> > 200 mbit/s.  Quite a difference.
> > 
> > sys/dev/usb/usb_mem.c:
> > error = bus_dmamem_map(tag, p->segs, p->nsegs, p->size,
> >>kaddr, BUS_DMA_NOWAIT|BUS_DMA_COHERENT);
> > 
> > On x86, COHERENT is essentially a no-op.  On ARM, it depends on the SoC.
> > Some SoCs have cache-coherent USB controllers, some don't.  Mine does
> > not, so mapping it COHERENT means uncached and thus slow.
> > 
> > Why do we do that?  Well, when the code was imported in 99, it was
> > already there.  Since then we have gained infrastructure for DMA
> > syncs in the USB stack, which I think are proper.
> > 
> > sys/dev/usb/usbdi.c - usbd_transfer() (before transfer)
> > 
> > if (!usbd_xfer_isread(xfer)) {
> > if ((xfer->flags & USBD_NO_COPY) == 0)
> > memcpy(KERNADDR(>dmabuf, 0), xfer->buffer,
> > xfer->length);
> > usb_syncmem(>dmabuf, 0, xfer->length,
> > BUS_DMASYNC_PREWRITE);
> > } else
> > usb_syncmem(>dmabuf, 0, xfer->length,
> > BUS_DMASYNC_PREREAD);
> > err = pipe->methods->transfer(xfer);
> > 
> > sys/dev/usb/usbdi.c - usb_transfer_complete() (after transfer)
> > 
> > if (xfer->actlen != 0) {
> > if (usbd_xfer_isread(xfer)) {
> > usb_syncmem(>dmabuf, 0, xfer->actlen,
> > BUS_DMASYNC_POSTREAD);
> > if (!(xfer->flags & USBD_NO_COPY))
> > memcpy(xfer->buffer, KERNADDR(>dmabuf, 0),
> > xfer->actlen);
> > } else
> > usb_syncmem(>dmabuf, 0, xfer->actlen,
> > BUS_DMASYNC_POSTWRITE);
> > }
> > 
> > We cannot just remove COHERENT, since some drivers, like ehci(4), use
> > the same backend to allocate their rings.  And I can't vouch for those
> > drivers' sanity.
> > 
> > As a first step, I would like to go ahead with another solution, which
> > is based on a diff from Marius Strobl, who added those syncs in the
> > first place.  Essentially it splits the memory handling into cacheable
> > and non-cacheable blocks.  The USB data transfers and everyone who uses
> > usbd_alloc_buffer() then use cacheable buffers, while code like ehci(4)
> > still don't.  This is a bit of a safer approach imho, since we don't
> > hurt the controller drivers, but speed up the data buffers.
> > 
> > Once we have verified that there are no regressions, we can adjust
> > ehci(4) and the like, add proper syncs, make sure they still work as
> > well as before, and maybe then back this out again.
> > 
> > Keep note that this is all a no-op on X86, but all the other archs will
> > profit from this.
> > 
> > ok?
> > 
> > Patrick
> 
> Update diff with inverted logic.  kettenis@ argues that we should
> invert the logic, and those who need COHERENT memory should ask
> for that explicitly, since for bus_dmamem_map() it also needs to
> be passed explicitly.  This also points out all those users that
> use usb_allocmem() internally, where we might want to have a look
> if COHERENT is actually needed or not, or if it can be refactored
> in another way.

These commits broke usb on imx.6 with cubox:

imxehci0 at simplebus3
usb0 at imxehci0: USB revision 2.0
usb0: root hub problem
imxehci1 at simplebus3
usb1 at imxehci1: USB revision 2.0
usb1: root hub problem
"usbmisc" at simplebus3 not configured

After reverting them I can use filesystems on usb again.

diff --git sys/dev/usb/dwc2/dwc2.c sys/dev/usb/dwc2/dwc2.c
index 6ca3cc658e5..6f035467213 100644
--- sys/dev/usb/dwc2/dwc2.c
+++ sys/dev/usb/dwc2/dwc2.c
@@ -1,4 +1,4 @@
-/* $OpenBSD: dwc2.c,v 1.51 2020/03/21 12:08:31 patrick Exp $   */
+/* $OpenBSD: dwc2.c,v 1.49 2019/11/27 11:16:59 mpi Exp $   */
 /* $NetBSD: dwc2.c,v 1.32 2014/09/02 23:26:20 macallan Exp $   */
 
 /*-
@@ -474,7 +474,7 @@ dwc2_open(struct usbd_pipe *pipe)
case UE_CONTROL:
pipe->methods = _device_ctrl_methods;
err = usb_allocmem(>sc_bus, sizeof(usb_device_request_t),
-   0, USB_DMA_COHERENT, >req_dma);
+   0, >req_dma);
if (err)
return err;
break;
diff --git sys/dev/usb/dwc2/dwc2_hcd.c sys/dev/usb/dwc2/dwc2_hcd.c
index ab76de7d766..7e5c91481d5 100644
--- sys/dev/usb/dwc2/dwc2_hcd.c
+++ sys/dev/usb/dwc2/dwc2_hcd.c
@@ -1,4 +1,4 @@
-/* $OpenBSD: 

Re: arm64 rpi3b install method

2020-03-06 Thread Jonathan Gray
On Fri, Mar 06, 2020 at 11:29:57PM +, Stuart Henderson wrote:
> I've finally managed to get openbsd installed on an rpi3b (need
> something to run signify/pkg_sign and this is what I have). Thought I'd
> write up the install method because there are no useful docs at the
> moment and it's a bit fiddly. (Note that only rpi3b works - 3b+ has no
> network/usb, the 32-bit ones are unsupported, 4 is unsupported).
> 
> - boot linux, set the otp bit to permanently enable booting from usb (set
> "program_usb_boot_mode=1" in /boot/config.txt and reboot)

You don't need to boot linux for that.  Just boot with rpi firmware.
3b+ can boot off usb by default.

And if you don't want to blow the fuse the sd card can be left in and
boot_targets set in the U-Boot environment as mentioned on arm64.html.

> 
> - write miniroot64.fs to an SD card (I tried 6.3 up to 6.6 and -current,
> that's the only one where I get any console output)

Are you using pins 8 (tx) and 10 (rx)?

With the Ethernet port facing towards you numbering is

1  2
3  4
5  6
7  8
9 10

After 6.6 the uart is now the more capable pl011 by default.

> 
> - write whatever version miniroot to a USB stick (I have a -current one)

Above you said the 6.4 miniroot, which is it?

> 
> - ttl cable on standard pins on the pinout.xyz connector 115200
> 
> - boot it. if you just leave it to itself you get
> 
> ## Starting EFI application at 0008 ...
> >> OpenBSD/arm64 BOOTAA64 0.13
> boot>
> kcannot open sd0a:/etc/random.seed: No such file or directory
> booting sd0a:/bsd: 2696864+410652+8951776+739752=0xf3e4c8
> "Synchronous Abort" handler, esr 0x0200
> 
> instead you have to do "machine exit" (thanks aalm for the tip)
> and then it boots the installer.

U-Boot packages on build machines are infrequently updated and going by
your dmesg it is still 2019.10.  Does anything change if you take the
rpi3 u-boot.bin from u-boot-aarch64 2020.01 and replace it?

> 
> ## Starting EFI application at 0008 ...
> >> OpenBSD/arm64 BOOTAA64 0.13
> boot> machine exit
> ## Application terminated, r = 0
> EFI LOAD FAILED: continuing...
> 
> Device 0: Vendor: SanDisk Rev: 1.00 Prod: Ultra Fit
> Type: Removable Hard Disk
> Capacity: 29340.0 MB = 28.6 GB (60088320 x 512)
> ... is now current device
> Scanning usb 0:1...
> Found EFI removable media binary efi/boot/bootaa64.efi
> FDT memrsv map 0: Failed to add to map
> 168758 bytes read in 112 ms (1.4 MiB/s)
> FDT memrsv map 0: Failed to add to map
> ## Starting EFI application at 0008 ...
> disks: sd0* sd1
> >> OpenBSD/arm64 BOOTAA64 0.20
> boot>
> cannot open sd0a:/etc/random.seed: No such file or directory
> booting sd0a:/bsd: 2258968+636456+8767192+739512 
> [182308+109+529152+204440]=0xff0d80
> type 0x0 pa 0x0 va 0x0 pages 0x1 attr 0x8
> type 0x7 pa 0x1000 va 0x0 pages 0x1ff attr 0x8
> [...]
> 
> after it has installed, remove the SD and just leave the USB drive,
> cross fingers, and hopefully it will boot automatically.
> 
> dmesg currently looks like:
> 
> OpenBSD 6.6-current (GENERIC.MP) #486: Thu Mar  5 23:22:04 MST 2020
> dera...@arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP
> real mem  = 958996480 (914MB)
> avail mem = 899473408 (857MB)
> mainbus0 at root: Raspberry Pi 3 Model B Rev 1.2
> cpu0 at mainbus0 mpidr 0: ARM Cortex-A53 r0p4
> cpu0: 32KB 64b/line 2-way L1 VIPT I-cache, 32KB 64b/line 4-way L1 D-cache
> cpu0: 512KB 64b/line 16-way L2 cache
> efi0 at mainbus0: UEFI 2.8
> efi0: Das U-Boot rev 0x20191000
> apm0 at mainbus0
> simplefb0 at mainbus0: 656x416, 32bpp
> wsdisplay0 at simplefb0 mux 1
> wsdisplay0: screen 0-5 added (std, vt100 emulation)
> "system" at mainbus0 not configured
> "axi" at mainbus0 not configured
> "thermal-zones" at mainbus0 not configured
> simplebus0 at mainbus0: "soc"
> "dma" at simplebus0 not configured
> bcmdog0 at simplebus0
> "cprman" at simplebus0 not configured
> bcmrng0 at simplebus0
> "mailbox" at simplebus0 not configured
> "gpio" at simplebus0 not configured
> pluart0 at simplebus0: console
> "mmc" at simplebus0 not configured
> "dsi" at simplebus0 not configured
> bcmaux0 at simplebus0
> dwctwo0 at simplebus0
> bcmintc0 at simplebus0
> bcmtemp0 at simplebus0
> "local_intc" at simplebus0 not configured
> "mmcnr" at simplebus0 not configured
> simplebus1 at simplebus0: "firmware"
> "expgpio" at simplebus1 not configured
> "power" at simplebus0 not configured
> "mailbox" at simplebus0 not configured
> "gpiomem" at simplebus0 not configured
> "fb" at simplebus0 not configured
> "vcsm" at simplebus0 not configured
> "virtgpio" at simplebus0 not configured
> simplebus2 at mainbus0: "clocks"
> "clock" at simplebus2 not configured
> "clock" at simplebus2 not configured
> "phy" at mainbus0 not configured
> "arm-pmu" at mainbus0 not configured
> agtimer0 at mainbus0: tick rate 19200 KHz
> "__overrides__" at mainbus0 not configured
> "leds" at mainbus0 not configured
> "fixedregulator_3v3" at mainbus0 not configured
> "fixedregulator_5v0" 

Re: usbdevs: small addition

2020-02-23 Thread Jonathan Gray
On Sun, Feb 23, 2020 at 11:14:37AM +0100, Jasper Lievisse Adriaanse wrote:
> On Sun, Feb 23, 2020 at 11:52:10AM +1100, Jonathan Gray wrote:
> > On Sat, Feb 22, 2020 at 04:22:25PM +0100, Jasper Lievisse Adriaanse wrote:
> > > Hi,
> > > 
> > > - add an AMD product found on the APU2
> > 
> > I would not consider 0x7900 a root hub as it attaches to another hub
> > 
> > uhub2 at uhub1 port 1 configuration 1 interface 0 "Advanced Micro Devices 
> > product 0x7900" rev 2.00/0.18 addr 2
> I'll change it to 'Hub' then.
> 
> > > - add vendor id for "Synaptics, Inc.
> > 
> > I'd just go with "Synaptics"
> Okey.
> 
> > > - add synaptics fingerprint reader found on recent thinkpads; I couldn't 
> > > find a proper
> > >   name for this device in the Linux usb.ids repository so I went with the 
> > > generic
> > >   'Fingerprint Reader" that's also used elsewhere in this file.
> > 
> > does it not supply a string itself?
> How would I get the device to do this?

If the device has a string it won't show as "product 0x00bd" in dmesg.
Going by a dmesg I found it doesn't have a string so adding it is fine.

> 
> > the lenovo windows driver matches on 0x06cb:0x00bd and 0x06cb:0x00c2
> > and calls itself "Synaptics UWP WBDI" which isn't very helpful.
> I've added the 0x00c2 to the diff below, re-using the original description 
> for now.

ok jsg@

> 
> 
> Index: usbdevs
> ===
> RCS file: /cvs/src/sys/dev/usb/usbdevs,v
> retrieving revision 1.710
> diff -u -p -r1.710 usbdevs
> --- usbdevs   27 Jan 2020 15:41:42 -  1.710
> +++ usbdevs   23 Feb 2020 10:12:02 -
> @@ -262,6 +262,7 @@ vendor AGFA   0x06bd  AGFA-Gevaert
>  vendor ASIAMD0x06be  Asia Microelectronic Development
>  vendor PHIDGETS  0x06c2  Phidgets
>  vendor BIZLINK   0x06c4  Bizlink International
> +vendor SYNAPTICS 0x06cb  Synaptics
>  vendor KEYSPAN   0x06cd  Keyspan
>  vendor AASHIMA   0x06d6  Aashima Technology
>  vendor LIEBERT   0x06da  Liebert
> @@ -888,6 +889,9 @@ product ALTI2 NEPTUNE30x6001  Neptune 3
>  product AMBIT WLAN   0x0302  WLAN
>  product AMBIT NTL_2500x6098  NTL 250 cable modem
>  
> +/* Advanced Micro Devices products */
> +product AMD HUB  0x7900  Hub
> +
>  /* Amigo Technology products */
>  product AMIGO RT2870_1   0x9031  RT2870
>  product AMIGO RT2870_2   0x9041  RT2870
> @@ -4167,6 +4171,10 @@ product SWEEX2 LW153   0x0153  LW153
>  product SWEEX2 LW154 0x0154  LW154
>  product SWEEX2 LW303 0x0302  LW303
>  product SWEEX2 LW313 0x0313  LW313
> +
> +/* Synaptics products */
> +product SYNAPTICS FPRINT 0x00bd  Fingerprint Reader
> +product SYNAPTICS FPRINT_2   0x00c2  Fingerprint Reader
>  
>  /* Syntech Information products */
>  product SYNTECH SERIAL   0x0001  Serial
> 
> -- 
> jasper
> 
> 



Re: diff: init efifb even if VGA is probed.

2020-02-23 Thread Jonathan Gray
On Sun, Feb 23, 2020 at 07:06:50PM +0900, YASUOKA Masahiko wrote:
> On Sun, 23 Feb 2020 18:50:54 +0900 (JST)
> YASUOKA Masahiko  wrote:
> > On Sat, 22 Feb 2020 13:02:48 +1100
> > Jonathan Gray  wrote:
> >> On Fri, Feb 21, 2020 at 02:09:07PM +0900, YASUOKA Masahiko wrote:
> >>> When efiboot starts the kernel, the video display becomes distorted
> >>> and never recovered until CPU reset.
> >>> 
> >>> Our kernel tries to initialized console twice, first trial is done
> >>> before getting boot info and second trial is done after getting boot
> >>> info.  Since EFI framebuffer needs "boot info", it is initialized on
> >>> second trial.
> >>> 
> >>> On HPE DL20 Gen10, probing vga is succeeded on first trial, the kernel
> >>> selects vga for the console, but actually it is broken.  On usual
> >>> machines which boot with EFI, the problem doesn't happen since they
> >>> have no vga.
> >>> 
> >>> The diff following fixes the problem by initializing efifb console
> >>> even if the VGA is probed.
> >>> 
> >>> # Also, HP DL20 Gen10 has "UEFI optimized boot" setting on BIOS and
> >>> # disabling the setting avoids the problem happening.  But since the
> >>> # setting seems to be for old Windows, I think we should fix our
> >>> # kernel.
> >>> 
> >>> comment? ok?
> >> 
> >> Is there a way to detect efi or bios before boot info is set?
> >> Ideally vga_cnattach() would never be called when booting via efi.
> > 
> > Yes.  I've tried to find such the way, I found 2 ways.
> > 
> > 1) ACPI has FADT_NO_VGA flag which indicate the system has VGA, but
> > reading ACPI table at early of kernel boot is not good and difficult
> > 
> > 2) Pass a flag from efiboot.  A diff for this is attached.
> > 
> >> Should the cninit() before the boot args are parsed be removed and just
> >> have cninit() unconditionally after?  This would make the debug printfs
> >> in boot arg passing useless, but they already wouldn't work when booting
> >> via efi.
> > 
> > I think this is a straight way and no downside for efi.  For a system
> > booting via BIOS, there is a downside that panic or debug string isn't
> > shown at very early part of kernel boot.
> 
> A diff for this is attached.
> 
> 1st diff
> - initialize efifb even if vga is probed
> 
> 2nd diff
> - pass a flag from efiboot, then initialize vga/efifb properly with it
> 
> 3rd diff
> - parse bootarg first, then initialize vga/efifb properly
> 
> 
> I think 3rd diff is the best.  Because it makes the code simple and
> the downside doesn't seem so serious.
> 
> 
> Index: sys/arch/amd64/amd64/machdep.c
> ===
> RCS file: /disk/cvs/openbsd/src/sys/arch/amd64/amd64/machdep.c,v
> retrieving revision 1.261
> diff -u -p -r1.261 machdep.c
> --- sys/arch/amd64/amd64/machdep.c24 Jan 2020 05:27:31 -  1.261
> +++ sys/arch/amd64/amd64/machdep.c23 Feb 2020 09:46:54 -
> @@ -1394,16 +1394,6 @@ init_x86_64(paddr_t first_avail)
>   i8254_startclock();
>  
>   /*
> -  * Attach the glass console early in case we need to display a panic.
> -  */
> - cninit();
> -
> - /*
> -  * Initialize PAGE_SIZE-dependent variables.
> -  */
> - uvm_setpagesize();

why move uvm_setpagesize?

> -
> - /*
>* Boot arguments are in a single page specified by /boot.
>*
>* We require the "new" vector form, as well as memory ranges
> @@ -1420,6 +1410,16 @@ init_x86_64(paddr_t first_avail)
>   } else
>   panic("invalid /boot");
>  
> + /*
> +  * Attach the glass console early in case we need to display a panic.
> +  */
> + cninit();

as cninit() is done here docninit and the cninit() call in getbootinfo()
could be removed.

> +
> + /*
> +  * Initialize PAGE_SIZE-dependent variables.
> +  */
> + uvm_setpagesize();
> +
>  /*
>   * Memory on the AMD64 port is described by three different things.
>   *
> @@ -1928,11 +1928,6 @@ getbootinfo(char *bootinfo, int bootinfo
>   bios_bootsr_t *bios_bootsr;
>   int docninit = 0;
>  
> -#undef BOOTINFO_DEBUG
> -#ifdef BOOTINFO_DEBUG
> - printf("bootargv:");
> -#endif
> -
>   for (q = (bootarg32_t *)bootinfo;
>   (q->ba_type != BOOTARG_END) &&
>   char *)q) - bootinfo) < bootinfo_size)

Re: usbdevs: small addition

2020-02-22 Thread Jonathan Gray
On Sat, Feb 22, 2020 at 04:22:25PM +0100, Jasper Lievisse Adriaanse wrote:
> Hi,
> 
> - add an AMD product found on the APU2

I would not consider 0x7900 a root hub as it attaches to another hub

uhub2 at uhub1 port 1 configuration 1 interface 0 "Advanced Micro Devices 
product 0x7900" rev 2.00/0.18 addr 2

> - add vendor id for "Synaptics, Inc.

I'd just go with "Synaptics"

> - add synaptics fingerprint reader found on recent thinkpads; I couldn't find 
> a proper
>   name for this device in the Linux usb.ids repository so I went with the 
> generic
>   'Fingerprint Reader" that's also used elsewhere in this file.

does it not supply a string itself?

the lenovo windows driver matches on 0x06cb:0x00bd and 0x06cb:0x00c2
and calls itself "Synaptics UWP WBDI" which isn't very helpful.

> 
> OK?
> 
> Index: usbdevs
> ===
> RCS file: /cvs/src/sys/dev/usb/usbdevs,v
> retrieving revision 1.710
> diff -u -p -r1.710 usbdevs
> --- usbdevs   27 Jan 2020 15:41:42 -  1.710
> +++ usbdevs   22 Feb 2020 15:21:41 -
> @@ -262,6 +262,7 @@ vendor AGFA   0x06bd  AGFA-Gevaert
>  vendor ASIAMD0x06be  Asia Microelectronic Development
>  vendor PHIDGETS  0x06c2  Phidgets
>  vendor BIZLINK   0x06c4  Bizlink International
> +vendor SYNAPTICS 0x06cb  Synaptics, Inc.
>  vendor KEYSPAN   0x06cd  Keyspan
>  vendor AASHIMA   0x06d6  Aashima Technology
>  vendor LIEBERT   0x06da  Liebert
> @@ -888,6 +889,9 @@ product ALTI2 NEPTUNE30x6001  Neptune 3
>  product AMBIT WLAN   0x0302  WLAN
>  product AMBIT NTL_2500x6098  NTL 250 cable modem
>  
> +/* Advanced Micro Devices products */
> +product AMD HUB  0x7900  Root Hub
> +
>  /* Amigo Technology products */
>  product AMIGO RT2870_1   0x9031  RT2870
>  product AMIGO RT2870_2   0x9041  RT2870
> @@ -4167,6 +4171,9 @@ product SWEEX2 LW1530x0153  LW153
>  product SWEEX2 LW154 0x0154  LW154
>  product SWEEX2 LW303 0x0302  LW303
>  product SWEEX2 LW313 0x0313  LW313
> +
> +/* Synaptics, Inc. products */
> +product SYNAPTICS FPRINT 0x00bd  Fingerprint Reader
>  
>  /* Syntech Information products */
>  product SYNTECH SERIAL   0x0001  Serial
> 
> 



Re: diff: init efifb even if VGA is probed.

2020-02-21 Thread Jonathan Gray
On Fri, Feb 21, 2020 at 02:09:07PM +0900, YASUOKA Masahiko wrote:
> Hello,
> 
> I am testing a new hardware, HPE DL20 Gen10.
> 
> When efiboot starts the kernel, the video display becomes distorted
> and never recovered until CPU reset.
> 
> Our kernel tries to initialized console twice, first trial is done
> before getting boot info and second trial is done after getting boot
> info.  Since EFI framebuffer needs "boot info", it is initialized on
> second trial.
> 
> On HPE DL20 Gen10, probing vga is succeeded on first trial, the kernel
> selects vga for the console, but actually it is broken.  On usual
> machines which boot with EFI, the problem doesn't happen since they
> have no vga.
> 
> The diff following fixes the problem by initializing efifb console
> even if the VGA is probed.
> 
> # Also, HP DL20 Gen10 has "UEFI optimized boot" setting on BIOS and
> # disabling the setting avoids the problem happening.  But since the
> # setting seems to be for old Windows, I think we should fix our
> # kernel.
> 
> comment? ok?

Is there a way to detect efi or bios before boot info is set?
Ideally vga_cnattach() would never be called when booting via efi.

Should the cninit() before the boot args are parsed be removed and just
have cninit() unconditionally after?  This would make the debug printfs
in boot arg passing useless, but they already wouldn't work when booting
via efi.

> 
> Initialize efifb as a console even if the VGA is probed.
> 
> Index: sys/arch/amd64/amd64/wscons_machdep.c
> ===
> RCS file: /var/cvs/openbsd/src/sys/arch/amd64/amd64/wscons_machdep.c,v
> retrieving revision 1.14
> diff -u -p -r1.14 wscons_machdep.c
> --- sys/arch/amd64/amd64/wscons_machdep.c 14 Oct 2017 04:44:43 -  
> 1.14
> +++ sys/arch/amd64/amd64/wscons_machdep.c 21 Feb 2020 04:42:38 -
> @@ -73,7 +73,7 @@
>  #include 
>  #endif
>  
> -int  wscn_video_init(void);
> +int  wscn_video_init(int);
>  void wscn_input_init(int);
>  
>  cons_decl(ws);
> @@ -103,10 +103,12 @@ wscninit(struct consdev *cp)
>  {
>   static int initted = 0;
>  
> - if (initted)
> + if (initted) {
> + wscn_video_init(1);
>   return;
> + }
>  
> - if (wscn_video_init() == 0) {
> + if (wscn_video_init(0) == 0) {
>   initted = 1;
>   wscn_input_init(0);
>   }
> @@ -134,11 +136,17 @@ wscnpollc(dev_t dev, int on)
>   * Configure the display part of the console.
>   */
>  int
> -wscn_video_init(void)
> +wscn_video_init(int pass)
>  {
>  #if (NEFIFB > 0)
> - if (efifb_cnattach() == 0)
> - return (0);
> + extern int vgaconsole;
> + if (pass > 0) {
> + if (efifb_cnattach() == 0) {
> + vgaconsole = 0;
> + return (0);
> + }
> + return (-1);
> + }
>  #endif
>  #if (NVGA > 0)
>   if (vga_cnattach(X86_BUS_SPACE_IO, X86_BUS_SPACE_MEM, -1, 1) == 0)
> 
> 



Re: [PATCH] Fixing an uninitialized variable that can lead to #GP.

2020-02-09 Thread Jonathan Gray
On Sun, Feb 09, 2020 at 06:17:47PM -0800, Anthony Steinhauser wrote:
> In the current implementation of the TAA mitigation if the cpuid_level
> is 6 and it's an Intel CPU, the sefflags_edx variable is used without
> being initialized. If the SEFF0EDX_ARCH_CAP bit is accidentally flipped
> in it, the rdmsr on the unimplemented MSR_ARCH_CAPABILITIES index leads
> to a #GP fault.
> 
> This change initializes the sefflags_edx variable to 0 which is
> consistent with the MSR_ARCH_CAPABILITIES being unavailable.

Thanks for the report.  Committed a different fix:

Index: i386/i386/cpu.c
===
RCS file: /cvs/src/sys/arch/i386/i386/cpu.c,v
retrieving revision 1.98
diff -u -p -r1.98 cpu.c
--- i386/i386/cpu.c 20 Dec 2019 07:55:30 -  1.98
+++ i386/i386/cpu.c 10 Feb 2020 03:04:02 -
@@ -476,8 +476,10 @@ cpu_tsx_disable(struct cpu_info *ci)
uint32_t dummy, sefflags_edx;
 
/* this runs before identifycpu() populates ci_feature_sefflags_edx */
-   if (cpuid_level >= 0x07)
-   CPUID_LEAF(0x7, 0, dummy, dummy, dummy, sefflags_edx);
+   if (cpuid_level < 0x07)
+   return;
+   CPUID_LEAF(0x7, 0, dummy, dummy, dummy, sefflags_edx);
+
if (strcmp(cpu_vendor, "GenuineIntel") == 0 &&
(sefflags_edx & SEFF0EDX_ARCH_CAP)) {
msr = rdmsr(MSR_ARCH_CAPABILITIES);
Index: amd64/amd64/cpu.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/cpu.c,v
retrieving revision 1.143
diff -u -p -r1.143 cpu.c
--- amd64/amd64/cpu.c   20 Dec 2019 07:49:31 -  1.143
+++ amd64/amd64/cpu.c   10 Feb 2020 03:03:51 -
@@ -1167,8 +1167,10 @@ cpu_tsx_disable(struct cpu_info *ci)
uint32_t dummy, sefflags_edx;
 
/* this runs before identifycpu() populates ci_feature_sefflags_edx */
-   if (cpuid_level >= 0x07)
-   CPUID_LEAF(0x7, 0, dummy, dummy, dummy, sefflags_edx);
+   if (cpuid_level < 0x07)
+   return;
+   CPUID_LEAF(0x7, 0, dummy, dummy, dummy, sefflags_edx);
+
if (strcmp(cpu_vendor, "GenuineIntel") == 0 &&
(sefflags_edx & SEFF0EDX_ARCH_CAP)) {
msr = rdmsr(MSR_ARCH_CAPABILITIES);



Re: Teach du(1) the -m flag, disk usage in megabytes

2020-01-27 Thread Jonathan Gray
On Mon, Jan 27, 2020 at 10:34:56PM +0100, Sebastian Benoit wrote:
> Florian Obser(flor...@openbsd.org) on 2020.01.27 19:57:41 +0100:
> > On Mon, Jan 27, 2020 at 10:33:49AM -0700, Todd C. Miller wrote:
> > > On Mon, 27 Jan 2020 10:05:41 +1100, Jonathan Gray wrote:
> > > 
> > > > On Sun, Jan 26, 2020 at 11:59:33AM -0500, David Goerger wrote:
> > > > > This diff teaches du(1) the -m flag, report disk usage in megabytes. 
> > > > > This brings us in line with implementations in the other BSDs, Linux, 
> > > > > and Illumos.
> > > >
> > > > Why is it needed?  -k is required by POSIX, adding arguments for
> > > > megabytes, gigabytes, terabytes, petabytes etc seems silly when
> > > > there is already 512 byte blocks, kilobytes and -h output.
> > > 
> > > It is useful in conjunction with sort.  For example, I often do:
> > > 
> > > du -sk * | sort -rn | head
> > > 
> > > to see the largest disk users.
> > 
> > Me, too. Given its wide spread adoption I think we should implement it.
> > OK florian@
> > 
> > > 
> > > However, output in kilobytes is less useful than it used to be due
> > > to larger files now being common.  Using the BLOCKSIZE env var is
> > > more flexible but is cumbersome to use and not portable.
> > > 
> > >  - todd
> 
> Every time my laptop disk gets full i use a horrible awk construct
> to make things readable. I would certainly like to see this.
> 
> Do we need -B for that? I dont think so...
> 
> I'm happy to commit this if nobody complains ;)

There are several commands which have a -k flag for scaling to
kilobytes.

For example:
df
du
ls
pstat
quot
swapctl

Going down the list of unit names kmgtpezy some of these flags are
already used.  So it would be hard to consistently use -m where -k is
used.  Adding a flag to take a scalling factor, even if just using an
additional char like 'm' to index into a table of scaling factors would
use less flags.

Though not all of these combinations and uses make sense, and commands
could be left inconsistent and not use additional scaling factors other
commands use.



Re: Teach du(1) the -m flag, disk usage in megabytes

2020-01-26 Thread Jonathan Gray
On Sun, Jan 26, 2020 at 11:59:33AM -0500, David Goerger wrote:
> This diff teaches du(1) the -m flag, report disk usage in megabytes. 
> This brings us in line with implementations in the other BSDs, Linux, 
> and Illumos.

Why is it needed?  -k is required by POSIX, adding arguments for
megabytes, gigabytes, terabytes, petabytes etc seems silly when
there is already 512 byte blocks, kilobytes and -h output.

> 
> Other base utilities where this flag might be useful include df(1)
> and quot(8), although it doesn't appear to be universally adopted
> among the other implementations. That said I can definitely cook
> up a diff if others would find the flag useful elsewhere. In
> particular I think the flag would be useful in quot(8), but that
> tool has an unfortunate legacy, discouraged option "-h" which
> conflicts with -k/-m/-h semantics elsewhere in base, such that
> adding "-m" to quot(8) might only invite confusion.
> 
> Many thanks to florian@ for a first-pass review on bsd.network, and
> for encouraging me to check out what the other BSDs and utilities in
> base do, so that we maintain consistency across the ecosystem.
> 
> This is my first patch submission---any pointers for improvement would 
> be greatly appreciated! Thanks!
> 
> (diff below and also attached as "du-megabytes.diff" in case my mail
> client mangles formatting; hopefully I got this right!)
> 
> ---
> 
> Index: du.1
> ===
> RCS file: /cvs/src/usr.bin/du/du.1,v
> retrieving revision 1.35
> diff -u -p -r1.35 du.1
> --- du.1  2 Sep 2019 21:18:41 -   1.35
> +++ du.1  25 Jan 2020 20:52:11 -
> @@ -38,7 +38,7 @@
>  .Nd display disk usage statistics
>  .Sh SYNOPSIS
>  .Nm du
> -.Op Fl achkrsx
> +.Op Fl achkmrsx
>  .Op Fl H | L | P
>  .Op Fl d Ar depth
>  .Op Ar
> @@ -86,6 +86,10 @@ By default, all sizes are reported in 51
>  The
>  .Fl k
>  option causes the numbers to be reported in kilobyte counts.
> +.It Fl m
> +Similar to
> +.Fl k ,
> +but report disk usage in megabytes.
>  .It Fl L
>  All symbolic links are followed.
>  .It Fl P
> Index: du.c
> ===
> RCS file: /cvs/src/usr.bin/du/du.c,v
> retrieving revision 1.32
> diff -u -p -r1.32 du.c
> --- du.c  24 Aug 2016 03:13:45 -  1.32
> +++ du.c  25 Jan 2020 20:52:31 -
> @@ -61,7 +61,7 @@ main(int argc, char *argv[])
>   long blocksize;
>   int64_t totalblocks;
>   int ftsoptions, listfiles, maxdepth;
> - int Hflag, Lflag, cflag, hflag, kflag;
> + int Hflag, Lflag, cflag, hflag, kflag, mflag;
>   int ch, notused, rval;
>   char **save;
>   const char *errstr;
> @@ -70,11 +70,11 @@ main(int argc, char *argv[])
>   err(1, "pledge");
> 
>   save = argv;
> - Hflag = Lflag = cflag = hflag = kflag = listfiles = 0;
> + Hflag = Lflag = cflag = hflag = kflag = listfiles = mflag = 0;
>   totalblocks = 0;
>   ftsoptions = FTS_PHYSICAL;
>   maxdepth = -1;
> - while ((ch = getopt(argc, argv, "HLPacd:hkrsx")) != -1)
> + while ((ch = getopt(argc, argv, "HLPacd:hkmrsx")) != -1)
>   switch (ch) {
>   case 'H':
>   Hflag = 1;
> @@ -103,10 +103,17 @@ main(int argc, char *argv[])
>   case 'h':
>   hflag = 1;
>   kflag = 0;
> + mflag = 0;
>   break;
>   case 'k':
>   kflag = 1;
>   hflag = 0;
> + mflag = 0;
> + break;
> + case 'm':
> + kflag = 0;
> + hflag = 0;
> + mflag = 1;
>   break;
>   case 's':
>   maxdepth = 0;
> @@ -155,6 +162,8 @@ main(int argc, char *argv[])
>   blocksize = 512;
>   else if (kflag)
>   blocksize = 1024;
> + else if (mflag)
> + blocksize = 1048576;
>   else
>   (void)getbsize(, );
>   blocksize /= 512;
> @@ -320,6 +329,6 @@ usage(void)
>  {
> 
>   (void)fprintf(stderr,
> - "usage: du [-achkrsx] [-H | -L | -P] [-d depth] [file ...]\n");
> + "usage: du [-achkmrsx] [-H | -L | -P] [-d depth] [file ...]\n");
>   exit(1);
>  }

> Index: du.1
> ===
> RCS file: /cvs/src/usr.bin/du/du.1,v
> retrieving revision 1.35
> diff -u -p -r1.35 du.1
> --- du.1  2 Sep 2019 21:18:41 -   1.35
> +++ du.1  25 Jan 2020 20:52:11 -
> @@ -38,7 +38,7 @@
>  .Nd display disk usage statistics
>  .Sh SYNOPSIS
>  .Nm du
> -.Op Fl achkrsx
> +.Op Fl achkmrsx
>  .Op Fl H | L | P
>  .Op Fl d Ar depth
>  .Op Ar
> @@ -86,6 +86,10 @@ By default, all sizes are reported in 51
>  The
>  .Fl k
>  option causes the numbers to be reported in kilobyte counts.
> +.It Fl m
> +Similar 

Re: [Patch]: Integrate VA-API into xenocara

2020-01-24 Thread Jonathan Gray
On Fri, Jan 24, 2020 at 04:45:07PM +1100, Jonathan Gray wrote:
> On Thu, Jan 23, 2020 at 12:39:29PM +1100, Jonathan Gray wrote:
> > On Wed, Dec 18, 2019 at 03:28:48PM -0600, Brad DeMorrow wrote:
> > > This is a rather large patch that moves my previously submitted
> > > VA-API ports into xenocara. For your convenience, I've inlined
> > > a diff that shows you all of the changes I made to existing files
> > > that you can easily read in your MUA.  The attached patch also
> > > contains these changes and should be the only xenocara patch
> > > you need to apply.
> > > 
> > > Summary of Changes:
> > >  - libva added to xenocara/lib/libva
> > >  - vainfo added to xenocara/app/vainfo
> > >  - intel-vaapi-driver added to xenocara/driver/intel-vaapi-driver
> > >  - Mesa Makefile.bsd-wrapper updated to build with --enable-va flag
> > >  - 3RDPARTY file updated to include libva, libva-utils, and 
> > > intel-vaapi-driver
> > >  - BSD.x11.dist updated to include /usr/X11R6/include/va/ (separate patch)
> > 
> > It is difficult to see where you have made changes, can you send patches
> > against source from particular tarballs?
> 
> I built libva-2.6.1 but it does not work with non-intel drivers at
> runtime due to a Mesa bug:
> 
> https://bugs.freedesktop.org/show_bug.cgi?id=109929
> 
> libva info: VA-API version 1.6.0
> libva info: Trying to open /usr/X11R6/lib/dri/radeonsi_drv_video.so
> vainfo:/usr/X11R6/lib/dri/radeonsi_drv_video.so: undefined symbol 
> 'gl_nir_lower_samplers_as_deref'
> vainfo:/usr/X11R6/lib/dri/radeonsi_drv_video.so: undefined symbol 
> 'gl_nir_lower_samplers'
> libva error: dlopen of /usr/X11R6/lib/dri/radeonsi_drv_video.so failed: 
> Cannot load specified object
> libva info: va_openDriver() returns -1
> vaInitialize failed with error code -1 (unknown libva error),exit

If I backport the following commits to 19.2 vainfo no longer errors on
amdgpu.

libva info: VA-API version 1.6.0
libva info: Trying to open /usr/X11R6/lib/dri/radeonsi_drv_video.so
libva info: Found init function __vaDriverInit_1_6
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.6 (libva 2.6.1)
vainfo: Driver version: Mesa Gallium driver 19.2.8 for AMD RAVEN (DRM 3.27.0, 
6.6, LLVM 8.0.1)
vainfo: Supported profile and entrypoints
  VAProfileMPEG2Simple: VAEntrypointVLD
  VAProfileMPEG2Main  : VAEntrypointVLD
  VAProfileVC1Simple  : VAEntrypointVLD
  VAProfileVC1Main: VAEntrypointVLD
  VAProfileVC1Advanced: VAEntrypointVLD
  VAProfileH264ConstrainedBaseline: VAEntrypointVLD
  VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
  VAProfileH264Main   : VAEntrypointVLD
  VAProfileH264Main   : VAEntrypointEncSlice
  VAProfileH264High   : VAEntrypointVLD
  VAProfileH264High   : VAEntrypointEncSlice
  VAProfileHEVCMain   : VAEntrypointVLD
  VAProfileHEVCMain   : VAEntrypointEncSlice
  VAProfileHEVCMain10 : VAEntrypointVLD
  VAProfileJPEGBaseline   : VAEntrypointVLD
  VAProfileVP9Profile0: VAEntrypointVLD
  VAProfileVP9Profile2: VAEntrypointVLD
  VAProfileNone   : VAEntrypointVideoProc

commit 3debd0ef157ed614522d20c1735c38af42fcce30
Author: Timur Kristóf 
AuthorDate: Wed Sep 4 16:56:09 2019 +0300
Commit: Timur Kristóf 
CommitDate: Fri Sep 6 12:20:53 2019 +0300

tgsi_to_nir: Remove dependency on libglsl.

This commit removes the GLSL dependency in TTN by manually recording
the textures used and calling nir_lower_samplers
instead of its GL counterpart.

Signed-off-by: Timur Kristóf 
Reviewed-by: Connor Abbott 

commit 610cc3089ccf1bce3ad025f308b6f408e8e90920
Author: Timur Kristóf 
AuthorDate: Wed Aug 28 22:34:14 2019 +0200
Commit: Timur Kristóf 
CommitDate: Fri Sep 6 12:20:20 2019 +0300

nir: Carve out nir_lower_samplers from GLSL code.

Lowering samplers is needed to produce NIR that can actually be
consumed by some gallium drivers, so it doesn't make sense to
to keep it only in the GLSL code.

This commit introduces nir_lower_samplers to compiler/nir,
while maintains the GL-specific function too.

Signed-off-by: Timur Kristóf 
Reviewed-by: Connor Abbott 

Index: Makefile.bsd-wrapper
===
RCS file: /cvs/xenocara/lib/mesa/Makefile.bsd-wrapper,v
retrieving revision 1.29
diff -u -p -r1.29 Makefile.bsd-wrapper
--- Makefile.bsd-wrapper22 Jan 2020 02:49:17 -  1.29
+++ Makefile.bsd-wrapper25 Jan 2020 02:29:19 -
@@ -44,6 +44,7 @@ CONFIGURE_AR

Re: [Patch]: Integrate VA-API into xenocara

2020-01-23 Thread Jonathan Gray
On Fri, Jan 24, 2020 at 04:45:07PM +1100, Jonathan Gray wrote:
> On Thu, Jan 23, 2020 at 12:39:29PM +1100, Jonathan Gray wrote:
> > On Wed, Dec 18, 2019 at 03:28:48PM -0600, Brad DeMorrow wrote:
> > > This is a rather large patch that moves my previously submitted
> > > VA-API ports into xenocara. For your convenience, I've inlined
> > > a diff that shows you all of the changes I made to existing files
> > > that you can easily read in your MUA.  The attached patch also
> > > contains these changes and should be the only xenocara patch
> > > you need to apply.
> > > 
> > > Summary of Changes:
> > >  - libva added to xenocara/lib/libva
> > >  - vainfo added to xenocara/app/vainfo
> > >  - intel-vaapi-driver added to xenocara/driver/intel-vaapi-driver
> > >  - Mesa Makefile.bsd-wrapper updated to build with --enable-va flag
> > >  - 3RDPARTY file updated to include libva, libva-utils, and 
> > > intel-vaapi-driver
> > >  - BSD.x11.dist updated to include /usr/X11R6/include/va/ (separate patch)
> > 
> > It is difficult to see where you have made changes, can you send patches
> > against source from particular tarballs?
> 
> I built libva-2.6.1 but it does not work with non-intel drivers at
> runtime due to a Mesa bug:
> 
> https://bugs.freedesktop.org/show_bug.cgi?id=109929
> 
> libva info: VA-API version 1.6.0
> libva info: Trying to open /usr/X11R6/lib/dri/radeonsi_drv_video.so
> vainfo:/usr/X11R6/lib/dri/radeonsi_drv_video.so: undefined symbol 
> 'gl_nir_lower_samplers_as_deref'
> vainfo:/usr/X11R6/lib/dri/radeonsi_drv_video.so: undefined symbol 
> 'gl_nir_lower_samplers'
> libva error: dlopen of /usr/X11R6/lib/dri/radeonsi_drv_video.so failed: 
> Cannot load specified object
> libva info: va_openDriver() returns -1
> vaInitialize failed with error code -1 (unknown libva error),exit
> 
> Here is the diff for libva-2.6.1 from memory the horrible ifdef part
> came from FreeBSD via your port.

patch below for va-utils it installs quite a few binaries

/usr/X11R6/bin/avcenc
/usr/X11R6/bin/avcstreamoutdemo
/usr/X11R6/bin/h264encode
/usr/X11R6/bin/hevcencode
/usr/X11R6/bin/jpegenc
/usr/X11R6/bin/loadjpeg
/usr/X11R6/bin/mpeg2vaenc
/usr/X11R6/bin/mpeg2vldemo
/usr/X11R6/bin/putsurface
/usr/X11R6/bin/sfcsample
/usr/X11R6/bin/vainfo
/usr/X11R6/bin/vavpp
/usr/X11R6/bin/vp8enc
/usr/X11R6/bin/vp9enc
/usr/X11R6/bin/vppblending
/usr/X11R6/bin/vppchromasitting
/usr/X11R6/bin/vppdenoise
/usr/X11R6/bin/vppscaling_csc
/usr/X11R6/bin/vppscaling_n_

--- /dev/null   Fri Jan 24 16:43:41 2020
+++ libva-utils-2.6.0/Makefile.bsd-wrapper  Fri Jan 24 14:02:34 2020
@@ -0,0 +1,3 @@
+# $OpenBSD$
+
+.include 
diff -upr -x *.m4 -x Makefile.in libva-utils-2.6.0.orig/encode/jpegenc_utils.h 
libva-utils-2.6.0/encode/jpegenc_utils.h
--- libva-utils-2.6.0.orig/encode/jpegenc_utils.h   Wed Dec 26 21:29:26 2018
+++ libva-utils-2.6.0/encode/jpegenc_utils.hFri Jan 24 14:06:25 2020
@@ -50,7 +50,7 @@ struct __bitstream {
 typedef struct __bitstream bitstream;
 
 static unsigned int 
-swap32(unsigned int val)
+va_swap32(unsigned int val)
 {
 unsigned char *pval = (unsigned char *)
 
@@ -77,7 +77,7 @@ bitstream_end(bitstream *bs)
 int bit_left = 32 - bit_offset;
 
 if (bit_offset) {
-bs->buffer[pos] = swap32((bs->buffer[pos] << bit_left));
+bs->buffer[pos] = va_swap32((bs->buffer[pos] << bit_left));
 }
 }
  
@@ -101,7 +101,7 @@ bitstream_put_ui(bitstream *bs, unsigned int val, int 
 } else {
 size_in_bits -= bit_left;
 bs->buffer[pos] = (bs->buffer[pos] << bit_left) | (val >> 
size_in_bits);
-bs->buffer[pos] = swap32(bs->buffer[pos]);
+bs->buffer[pos] = va_swap32(bs->buffer[pos]);
 
 if (pos + 1 == bs->max_size_in_dword) {
 bs->max_size_in_dword += BITSTREAM_ALLOCATE_STEPPING;
diff -upr -x *.m4 -x Makefile.in libva-utils-2.6.0.orig/encode/mpeg2vaenc.c 
libva-utils-2.6.0/encode/mpeg2vaenc.c
--- libva-utils-2.6.0.orig/encode/mpeg2vaenc.c  Wed Dec 26 21:29:26 2018
+++ libva-utils-2.6.0/encode/mpeg2vaenc.c   Fri Jan 24 14:05:48 2020
@@ -163,7 +163,7 @@ struct __bitstream {
 typedef struct __bitstream bitstream;
 
 static unsigned int 
-swap32(unsigned int val)
+va_swap32(unsigned int val)
 {
 unsigned char *pval = (unsigned char *)
 
@@ -190,7 +190,7 @@ bitstream_end(bitstream *bs)
 int bit_left = 32 - bit_offset;
 
 if (bit_offset) {
-bs->buffer[pos] = swap32((bs->buffer[pos] << bit_left));
+bs->buffer[pos] = va_swap32((bs->buffer[pos] << bit_left));
 }
 }
  
@@ -214,7 +214,7 @@ bitstream_put_ui(bitstream *bs, unsigned int val, int 
 } else {
 size_in_bits -= bit_left;
 bs->buffer[pos] = (bs->

Re: [Patch]: Integrate VA-API into xenocara

2020-01-23 Thread Jonathan Gray
On Thu, Jan 23, 2020 at 12:39:29PM +1100, Jonathan Gray wrote:
> On Wed, Dec 18, 2019 at 03:28:48PM -0600, Brad DeMorrow wrote:
> > This is a rather large patch that moves my previously submitted
> > VA-API ports into xenocara. For your convenience, I've inlined
> > a diff that shows you all of the changes I made to existing files
> > that you can easily read in your MUA.  The attached patch also
> > contains these changes and should be the only xenocara patch
> > you need to apply.
> > 
> > Summary of Changes:
> >  - libva added to xenocara/lib/libva
> >  - vainfo added to xenocara/app/vainfo
> >  - intel-vaapi-driver added to xenocara/driver/intel-vaapi-driver
> >  - Mesa Makefile.bsd-wrapper updated to build with --enable-va flag
> >  - 3RDPARTY file updated to include libva, libva-utils, and 
> > intel-vaapi-driver
> >  - BSD.x11.dist updated to include /usr/X11R6/include/va/ (separate patch)
> 
> It is difficult to see where you have made changes, can you send patches
> against source from particular tarballs?

I built libva-2.6.1 but it does not work with non-intel drivers at
runtime due to a Mesa bug:

https://bugs.freedesktop.org/show_bug.cgi?id=109929

libva info: VA-API version 1.6.0
libva info: Trying to open /usr/X11R6/lib/dri/radeonsi_drv_video.so
vainfo:/usr/X11R6/lib/dri/radeonsi_drv_video.so: undefined symbol 
'gl_nir_lower_samplers_as_deref'
vainfo:/usr/X11R6/lib/dri/radeonsi_drv_video.so: undefined symbol 
'gl_nir_lower_samplers'
libva error: dlopen of /usr/X11R6/lib/dri/radeonsi_drv_video.so failed: Cannot 
load specified object
libva info: va_openDriver() returns -1
vaInitialize failed with error code -1 (unknown libva error),exit

Here is the diff for libva-2.6.1 from memory the horrible ifdef part
came from FreeBSD via your port.

--- /dev/null   Fri Jan 24 16:36:40 2020
+++ libva-2.6.1/Makefile.bsd-wrapperFri Jan 24 13:56:21 2020
@@ -0,0 +1,5 @@
+# $OpenBSD$
+
+SHARED_LIBS=   va 0.0 va_drm 0.0 va_glx 0.0 va_x11 0.0
+
+.include 
diff -upr -x *.m4 -x Makefile.in libva-2.6.1.orig/va/Makefile.am 
libva-2.6.1/va/Makefile.am
--- libva-2.6.1.orig/va/Makefile.am Wed Dec 18 00:46:07 2019
+++ libva-2.6.1/va/Makefile.am  Fri Jan 24 13:55:21 2020
@@ -91,7 +91,7 @@ libva_la_SOURCES  = $(libva_source_c)
 libva_la_CFLAGS= $(libva_cflags)
 libva_la_LDFLAGS   = $(libva_ldflags)
 libva_la_DEPENDENCIES  = libva.syms
-libva_la_LIBADD= $(LIBVA_LIBS) -ldl
+libva_la_LIBADD= $(LIBVA_LIBS) $(DLOPEN_LIBS)
 
 if USE_DRM
 SUBDIRS+= drm
@@ -101,7 +101,7 @@ libva_drm_la_CFLAGS = $(libva_cflags)
 libva_drm_la_LDFLAGS   = $(LDADD)
 libva_drm_la_DEPENDENCIES  = libva.la drm/libva_drm.la
 libva_drm_la_LIBADD= libva.la drm/libva_drm.la \
-   $(LIBVA_LIBS) $(DRM_LIBS) -ldl
+   $(LIBVA_LIBS) $(DRM_LIBS) $(DLOPEN_LIBS)
 endif
 
 if USE_X11
@@ -113,7 +113,7 @@ libva_x11_la_CFLAGS = $(libva_cflags)
 libva_x11_la_LDFLAGS   = $(LDADD)
 libva_x11_la_DEPENDENCIES  = libva.la x11/libva_x11.la
 libva_x11_la_LIBADD= libva.la x11/libva_x11.la \
-   $(LIBVA_LIBS) $(X11_LIBS) $(XEXT_LIBS) $(XFIXES_LIBS) $(DRM_LIBS) -ldl
+   $(LIBVA_LIBS) $(X11_LIBS) $(XEXT_LIBS) $(XFIXES_LIBS) $(DRM_LIBS) 
$(DLOPEN_LIBS)
 endif
 
 if USE_GLX
@@ -124,7 +124,7 @@ libva_glx_la_CFLAGS = $(libva_cflags)
 libva_glx_la_LDFLAGS   = $(LDADD)
 libva_glx_la_DEPENDENCIES  = libva.la glx/libva_glx.la libva-x11.la
 libva_glx_la_LIBADD= libva.la glx/libva_glx.la libva-x11.la \
-   $(GLX_LIBS) -ldl
+   $(GLX_LIBS) $(DLOPEN_LIBS)
 endif
 
 if USE_WAYLAND
@@ -135,7 +135,7 @@ libva_wayland_la_CFLAGS = $(libva_cflags)
 libva_wayland_la_LDFLAGS   = $(LDADD)
 libva_wayland_la_DEPENDENCIES  = libva.la wayland/libva_wayland.la
 libva_wayland_la_LIBADD= libva.la wayland/libva_wayland.la \
-   $(WAYLAND_LIBS) $(DRM_LIBS) -ldl
+   $(WAYLAND_LIBS) $(DRM_LIBS) $(DLOPEN_LIBS)
 endif
 
 DIST_SUBDIRS = x11 glx drm wayland
Only in libva-2.6.1/va: Makefile.am.orig
diff -upr -x *.m4 -x Makefile.in libva-2.6.1.orig/va/va.c libva-2.6.1/va/va.c
--- libva-2.6.1.orig/va/va.cFri Jan 17 22:11:32 2020
+++ libva-2.6.1/va/va.c Fri Jan 24 13:55:21 2020
@@ -451,7 +451,7 @@ static VAStatus va_openDriver(VADisplay dpy, char *dri
 }
 
 va_infoMessage(dpy, "Trying to open %s\n", driver_path);
-#ifndef ANDROID
+#if defined(RTLD_NODELETE)
 handle = dlopen( driver_path, RTLD_NOW | RTLD_GLOBAL | RTLD_NODELETE );
 #else
 handle = dlopen( driver_path, RTLD_NOW| RTLD_GLOBAL);
Only in libva-2.6.1/va: va.c.orig
diff -upr -x *.m4 -x Makefile.in libva-2.6.1.orig/va/va_trace.c 
libva-2.6.1/va/va_trace.c
--- libva-2.6.1.orig/va/va_trace.c  Wed Dec 18 00:46:07 2

Re: [Patch]: Integrate VA-API into xenocara

2020-01-22 Thread Jonathan Gray
On Wed, Dec 18, 2019 at 03:28:48PM -0600, Brad DeMorrow wrote:
> This is a rather large patch that moves my previously submitted
> VA-API ports into xenocara. For your convenience, I've inlined
> a diff that shows you all of the changes I made to existing files
> that you can easily read in your MUA.  The attached patch also
> contains these changes and should be the only xenocara patch
> you need to apply.
> 
> Summary of Changes:
>  - libva added to xenocara/lib/libva
>  - vainfo added to xenocara/app/vainfo
>  - intel-vaapi-driver added to xenocara/driver/intel-vaapi-driver
>  - Mesa Makefile.bsd-wrapper updated to build with --enable-va flag
>  - 3RDPARTY file updated to include libva, libva-utils, and intel-vaapi-driver
>  - BSD.x11.dist updated to include /usr/X11R6/include/va/ (separate patch)

It is difficult to see where you have made changes, can you send patches
against source from particular tarballs?



Re: 'struct ipoption' & signed char

2020-01-16 Thread Jonathan Gray
On Thu, Jan 16, 2020 at 10:52:06AM +0100, Martin Pieuchot wrote:
> Found while compiling sgi kernel:
> 
> /sys/netinet/igmp.c:140:22: error: implicit conversion from 'int' to 'int8_t'
>   (aka 'signed char') changes value from 148 to -108
>   [-Werror,-Wconstant-conversion]
> ra->ipopt_list[0] = IPOPT_RA;
>   ~ ^~~~
> /sys/netinet/ip.h:153:19: note: expanded from macro 'IPOPT_RA'
> 
> Use an unsigned type in this case:

People argued against some of these types of changes previously.
That is why kernels built with clang use -Wno-constant-conversion.

patrick proposed this change in 2017 but it didn't happen
https://marc.info/?l=openbsd-tech=148490401504785=2

> 
> Index: netinet/ip_var.h
> ===
> RCS file: /cvs/src/sys/netinet/ip_var.h,v
> retrieving revision 1.86
> diff -u -p -r1.86 ip_var.h
> --- netinet/ip_var.h  8 Dec 2019 11:08:22 -   1.86
> +++ netinet/ip_var.h  16 Jan 2020 09:48:41 -
> @@ -92,7 +92,7 @@ struct  ipstat {
>  
>  struct ipoption {
>   struct  in_addr ipopt_dst;  /* first-hop dst if source routed */
> - int8_t  ipopt_list[MAX_IPOPTLEN];   /* options proper */
> + uint8_t ipopt_list[MAX_IPOPTLEN];   /* options proper */
>  };
>  
>  #ifdef _KERNEL
> 
> 



Re: Towards splitting SCHED_LOCK()

2020-01-14 Thread Jonathan Gray
On Mon, Jan 13, 2020 at 05:02:12PM +0100, Martin Pieuchot wrote:
> I'm facing a lock ordering issue while profiling the scheduler which
> cannot be solved without using a different lock for the global sleepqueue
> and the runqueues.
> 
> The SCHED_LOCK() currently protects both data structures as well as the
> related fields in 'struct proc'.  One of this fields is `p_wchan' which
> is obviously related to the global sleepqueue.
> 
> The cleaning diff below introduces a new function, awake(), that unify
> the multiple uses of the following idiom:
> 
>   if (p->p_stat == SSLEEP)
>   setrunnable(p);
>   else
>   unsleep(p);
> 
> This is generally done after checking if the thread `p' is on the
> sleepqueue.

Why not name it wakeup_proc() instead or something like endsleep()?

awake() does not describe the action that is being done and
if (awake()) reads like it could be
if (p->p_stat != SSLEEP && p->p_stat != SSTOP)

> 
> This diff introduces a change in behavior in the Linux compat:
> wake_up_process() will now return 1 if the thread was stopped and not
> sleeping.  This should be fine since the only place this value is
> checked is with the combination of task_asleep().
> 
> While here I removed two unnecessary `p_wchan' check before unsleep().
> 
> ok?
> 
> Index: dev/pci/drm/drm_linux.c
> ===
> RCS file: /cvs/src/sys/dev/pci/drm/drm_linux.c,v
> retrieving revision 1.55
> diff -u -p -r1.55 drm_linux.c
> --- dev/pci/drm/drm_linux.c   5 Jan 2020 13:46:02 -   1.55
> +++ dev/pci/drm/drm_linux.c   13 Jan 2020 15:34:44 -
> @@ -115,20 +115,8 @@ schedule_timeout(long timeout)
>  int
>  wake_up_process(struct proc *p)
>  {
> - int s, r = 0;
> -
> - SCHED_LOCK(s);
>   atomic_cas_ptr(_proc, p, NULL);
> - if (p->p_wchan) {
> - if (p->p_stat == SSLEEP) {
> - setrunnable(p);
> - r = 1;
> - } else
> - unsleep(p);
> - }
> - SCHED_UNLOCK(s);
> -
> - return r;
> + return awake(p, NULL);
>  }
>  
>  void
> Index: kern/sys_generic.c
> ===
> RCS file: /cvs/src/sys/kern/sys_generic.c,v
> retrieving revision 1.127
> diff -u -p -r1.127 sys_generic.c
> --- kern/sys_generic.c8 Jan 2020 16:27:41 -   1.127
> +++ kern/sys_generic.c13 Jan 2020 15:35:22 -
> @@ -767,7 +767,6 @@ void
>  selwakeup(struct selinfo *sip)
>  {
>   struct proc *p;
> - int s;
>  
>   KNOTE(>si_note, NOTE_SUBMIT);
>   if (sip->si_seltid == 0)
> @@ -780,15 +779,10 @@ selwakeup(struct selinfo *sip)
>   p = tfind(sip->si_seltid);
>   sip->si_seltid = 0;
>   if (p != NULL) {
> - SCHED_LOCK(s);
> - if (p->p_wchan == (caddr_t)) {
> - if (p->p_stat == SSLEEP)
> - setrunnable(p);
> - else
> - unsleep(p);
> + if (awake(p, )) {
> + /* nothing else to do */
>   } else if (p->p_flag & P_SELECT)
>   atomic_clearbits_int(>p_flag, P_SELECT);
> - SCHED_UNLOCK(s);
>   }
>  }
>  
> Index: kern/kern_synch.c
> ===
> RCS file: /cvs/src/sys/kern/kern_synch.c,v
> retrieving revision 1.156
> diff -u -p -r1.156 kern_synch.c
> --- kern/kern_synch.c 12 Jan 2020 00:01:12 -  1.156
> +++ kern/kern_synch.c 13 Jan 2020 15:41:00 -
> @@ -469,8 +469,7 @@ sleep_setup_signal(struct sleep_state *s
>*/
>   atomic_setbits_int(>p_flag, P_SINTR);
>   if (p->p_p->ps_single != NULL || (sls->sls_sig = CURSIG(p)) != 0) {
> - if (p->p_wchan)
> - unsleep(p);
> + unsleep(p);
>   p->p_stat = SONPROC;
>   sls->sls_do_sleep = 0;
>   } else if (p->p_wchan == 0) {
> @@ -505,6 +504,25 @@ sleep_finish_signal(struct sleep_state *
>   return (error);
>  }
>  
> +int
> +awake(struct proc *p, const volatile void *chan)
> +{
> + int s, awakened = 0;
> +
> + SCHED_LOCK(s);
> + if (p->p_wchan != NULL &&
> +((chan == NULL) || (p->p_wchan == chan))) {
> + awakened = 1;
> + if (p->p_stat == SSLEEP)
> + setrunnable(p);
> + else
> + unsleep(p);
> + }
> + SCHED_UNLOCK(s);
> +
> + return awakened;
> +}
> +
>  /*
>   * Implement timeout for tsleep.
>   * If process hasn't been awakened (wchan non-zero),
> @@ -515,17 +533,9 @@ void
>  endtsleep(void *arg)
>  {
>   struct proc *p = arg;
> - int s;
>  
> - SCHED_LOCK(s);
> - if (p->p_wchan) {
> - if (p->p_stat == SSLEEP)
> - setrunnable(p);
> - else
> - unsleep(p);
> + if (awake(p, NULL))
>

Re: xlights(4): timeout_add(9) -> timeout_add_msec(9)

2020-01-09 Thread Jonathan Gray
On Wed, Dec 18, 2019 at 08:47:54PM -0600, Scott Cheloha wrote:
> 250 ticks at macppc's 100hz is 2500 milliseconds.
> 
> ok?

ok jsg@

> 
> Index: xlights.c
> ===
> RCS file: /cvs/src/sys/arch/macppc/dev/xlights.c,v
> retrieving revision 1.9
> diff -u -p -r1.9 xlights.c
> --- xlights.c 8 Oct 2019 13:21:38 -   1.9
> +++ xlights.c 19 Dec 2019 02:45:33 -
> @@ -282,7 +282,7 @@ xlights_startdma(struct xlights_softc *s
>   dbdma_command_t *cmdp = sc->sc_dmacmd;
>  
>   sc->sc_dmasts = 1;
> - timeout_add(>sc_tmo, 250);
> + timeout_add_msec(>sc_tmo, 2500);
>  
>   DBDMA_BUILD(cmdp, DBDMA_CMD_OUT_LAST, 0,
>   sc->sc_bufmap->dm_segs[0].ds_len,
> 
> 



Re: pluart(4): timeout_add(9) -> timeout_add_sec(9)

2020-01-09 Thread Jonathan Gray
On Sun, Dec 22, 2019 at 03:35:09PM -0600, Scott Cheloha wrote:
> ok?
> 
> Index: pluart.c
> ===
> RCS file: /cvs/src/sys/dev/ic/pluart.c,v
> retrieving revision 1.4
> diff -u -p -r1.4 pluart.c
> --- pluart.c  11 Aug 2019 10:03:32 -  1.4
> +++ pluart.c  22 Dec 2019 21:32:50 -
> @@ -225,7 +225,7 @@ pluart_intr(void *arg)
>   if (p >= sc->sc_ibufend) {
>   sc->sc_floods++;
>   if (sc->sc_errors++ == 0)
> - timeout_add(>sc_diag_tmo, 60 * hz);
> + timeout_add_sec(>sc_diag_tmo, 60);
>   } else {
>   *p++ = c;
>   if (p == sc->sc_ibufhigh && ISSET(tp->t_cflag, 
> CRTSCTS)) {
> @@ -428,7 +428,7 @@ pluart_softint(void *arg)
>   if (ISSET(c, IMXUART_RX_OVERRUN)) {
>   sc->sc_overflows++;
>   if (sc->sc_errors++ == 0)
> - timeout_add(>sc_diag_tmo, 60 * hz);
> + timeout_add_sec(>sc_diag_tmo, 60);
>   }
>   */
>   /* This is ugly, but fast. */
> @@ -605,7 +605,7 @@ pluartclose(dev_t dev, int flag, int mod
>   /* tty device is waiting for carrier; drop dtr then re-raise */
>   //CLR(sc->sc_ucr3, IMXUART_CR3_DSR);
>   //bus_space_write_4(iot, ioh, IMXUART_UCR3, sc->sc_ucr3);
> - timeout_add(>sc_dtr_tmo, hz * 2);
> + timeout_add_sec(>sc_dtr_tmo, 2);
>   } else {
>   /* no one else waiting; turn off the uart */
>   pluart_pwroff(sc);
> 
> 

ok jsg@

same diff for exuart

Index: exuart.c
===
RCS file: /cvs/src/sys/arch/armv7/exynos/exuart.c,v
retrieving revision 1.16
diff -u -p -r1.16 exuart.c
--- exuart.c19 Jul 2019 00:17:15 -  1.16
+++ exuart.c10 Jan 2020 03:52:57 -
@@ -283,7 +283,7 @@ exuart_intr(void *arg)
if (p >= sc->sc_ibufend) {
sc->sc_floods++;
if (sc->sc_errors++ == 0)
-   timeout_add(>sc_diag_tmo, 60 * hz);
+   timeout_add_sec(>sc_diag_tmo, 60);
} else {
*p++ = c;
if (p == sc->sc_ibufhigh && ISSET(tp->t_cflag, CRTSCTS))
@@ -710,7 +710,7 @@ exuartclose(dev_t dev, int flag, int mod
/* tty device is waiting for carrier; drop dtr then re-raise */
//CLR(sc->sc_ucr3, EXUART_CR3_DSR);
//bus_space_write_2(iot, ioh, EXUART_UCR3, sc->sc_ucr3);
-   timeout_add(>sc_dtr_tmo, hz * 2);
+   timeout_add_sec(>sc_dtr_tmo, 2);
} else {
/* no one else waiting; turn off the uart */
exuart_pwroff(sc);



Re: pcidevs and usbdevs in Dell r7515

2020-01-08 Thread Jonathan Gray
On Wed, Jan 08, 2020 at 06:51:26PM +0100, Hrvoje Popovski wrote:
> Hi all,
> 
> in attachment you can find diff with some new AMD devices found in Dell
> R7515.
> 
> pcidevs are from
> https://raw.githubusercontent.com/pciutils/pciids/master/pci.ids
> 
> and usbdevs are from
> https://usb-ids.gowdy.us/read/UD/1604/10c0
> https://certification.ubuntu.com/catalog/component/1604:10c0
> 
> names for amd devices from 0x1490 to 0x1497 are little to general :)

Every pci device has a function, what class do they have?
see pcidump -v

> dmesg with this diff

> "AMD 17h/3xh PCIE" rev 0x00 at pci2 dev 0 function 0 not configured
> "AMD 17h/3xh PCIE" rev 0x00 at pci9 dev 0 function 0 not configured
> "AMD 17h/3xh PCIE" rev 0x00 at pci16 dev 0 function 0 not configured
> "AMD 17h/3xh PCIE" rev 0x00 at pci28 dev 0 function 0 not configured

whatever this id is looks to be wrong

> Index: pci/pcidevs
> ===
> RCS file: /home/cvs/src/sys/dev/pci/pcidevs,v
> retrieving revision 1.1911
> diff -u -p -r1.1911 pcidevs
> --- pci/pcidevs   5 Jan 2020 12:54:21 -   1.1911
> +++ pci/pcidevs   8 Jan 2020 17:17:22 -
> @@ -272,6 +272,7 @@ vendorTOPIC   0x151f  Topic/SmartLink
>  vendor   ENE 0x1524  ENE
>  vendor   ARALION 0x1538  Aralion
>  vendor   TERRATEC0x153b  TerraTec
> +vendor   PLDA0x1556  PLDA
>  vendor   PERLE   0x155f  Perle
>  vendor   SYMBOL  0x1562  Symbol
>  vendor   SYBA0x1592  Syba
> @@ -736,7 +737,23 @@ 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_IOMM   0x1481  17h/3xh IOMMU

might as well have IOMMU in the define

> +product AMD 17_3X_PCIE_1 0x1482  17h/3xh PCIE
> +product AMD 17_3X_PCIE_2 0x1483  17h/3xh PCIE
> +product AMD 17_3X_PCIE_3 0x1484  17h/3xh PCIE
> +product AMD 17_3X_SPP0x1485  17h/3xh Reserved SPP

17h/3xh SPP

>  product AMD 17_3X_CCP0x1486  17h/3xh Crypto
> +product AMD 17_3X_PCIE_4 0x148a  17h/3xh PCIE
> +product AMD 17_3X_XHCI_1 0x148c  17h/3xh xHCI
> +product AMD 17_3X_F_10x1490  17h/3xh Function
> +product AMD 17_3X_F_20x1491  17h/3xh Function
> +product AMD 17_3X_F_30x1492  17h/3xh Function
> +product AMD 17_3X_F_40x1493  17h/3xh Function
> +product AMD 17_3X_F_50x1494  17h/3xh Function
> +product AMD 17_3X_F_60x1495  17h/3xh Function
> +product AMD 17_3X_F_70x1496  17h/3xh Function
> +product AMD 17_3X_F_80x1497  17h/3xh Function
> +product AMD 17_3X_PTDMA  0x1498  17h/3xh Passthrough DMA Engine

17h/3xh DMA

>  product AMD 14_HB0x1510  14h Host
>  product AMD 14_PCIE_10x1512  14h PCIE
>  product AMD 14_PCIE_20x1513  14h PCIE
> @@ -5866,6 +5883,7 @@ product MATROX G200EV   0x0530  MGA G200eV
>  product MATROX G200EW0x0532  MGA G200eW
>  product MATROX G200EH0x0533  MGA G200eH
>  product MATROX G200ER0x0534  MGA G200eR
> +product MATROX G200EW3   0x0536  MGA G200eW3
>  product MATROX IMPRESSION0x0d10  MGA Impression
>  product MATROX PRODUCTIVA_PCI0x1000  MGA G100 PCI
>  product MATROX PRODUCTIVA_AGP0x1001  MGA G100 AGP
> @@ -6830,6 +6848,9 @@ product PLANEX FNW_3800_TX  0xab07  FNW-38
>  
>  /* Platform */
>  product PLATFORM ES1849  0x0100  ES1849
> +
> +/* PLDA */
> +product  PLDA PCIE   0xbe00  PCI Express Bridge  

whitespace is wrong, string could be shorter

product PLDA PPB0xbe00  PCIE

>  
>  /* PLX products */
>  product PLX 1076 0x1076  I/O 1076

> Index: usb/usbdevs
> ===
> RCS file: /home/cvs/src/sys/dev/usb/usbdevs,v
> retrieving revision 1.707
> diff -u -p -r1.707 usbdevs
> --- usb/usbdevs   5 Jan 2020 10:13:14 -   1.707
> +++ usb/usbdevs   8 Jan 2020 14:08:31 -
> @@ -548,6 +548,7 @@ vendor OLIMEX 0x15ba  Olimex
>  vendor AMIT2 0x15c5  AMIT
>  vendor TRUST 0x15d9  Trust
>  vendor SOHOWARE  0x15e8  SOHOware
> +vendor TASCAM0x1604  Tascam

usb.org has 0x1604/5636 as "Kyokko Seiko"

https://www.usb.org/sites/default/files/vendor_ids082119_0.pdf

>  vendor UMAX  0x1606  UMAX Data Systems
>  vendor INSIDEOUT 0x1608  Inside Out Networks
>  vendor GOODWAY   0x1631  Good Way Technology
> @@ -4178,6 +4179,9 @@ product TANGTOP USBPS2  0x0001  USBPS2
>  
>  /* Tapwave products */
>  product TAPWAVE ZODIAC   0x0100  Zodiac

Re: Fwd: Patch to pcidevs for a SSD drive ADATA product.

2020-01-07 Thread Jonathan Gray
On Tue, Jan 07, 2020 at 08:12:05PM -0700, Todd C. Miller wrote:
> The Adata XPG SX8200 and SX8200 Pro are different products so I
> think the "Pro" should be present in the description.
> 
>  - todd
> 
> 

The non-pro product supposedly is 126f:2262 going by
https://bugzilla.kernel.org/attachment.cgi?id=280237=diff

Index: pcidevs
===
RCS file: /cvs/src/sys/dev/pci/pcidevs,v
retrieving revision 1.1911
diff -u -p -r1.1911 pcidevs
--- pcidevs 5 Jan 2020 12:54:21 -   1.1911
+++ pcidevs 8 Jan 2020 03:25:10 -
@@ -336,6 +336,7 @@ vendor  ETRON   0x1b6f  Etron
 vendor FRESCO  0x1b73  Fresco Logic
 vendor WCH20x1c00  Nanjing QinHeng Electronics
 vendor SYMPHONY2   0x1c1c  Symphony Labs
+vendor ADATA   0x1cc1  ADATA Technology
 vendor UMIS0x1cc4  Union Memory
 vendor ROCKCHIP0x1d87  Rockchip
 vendor TEKRAM2 0x1de1  Tekram
@@ -505,6 +506,9 @@ product ACER M1435  0x1435  M1435 VL-PCI
 product AD SP21535 0x1535  ADSP 21535 DSP
 product AD 18890x1889  AD1889 Audio
 product AD SP2141  0x2f44  SafeNet ADSP 2141
+
+/* ADATA products */
+product ADATA SX8200PRO0x8201  SX8200 Pro
 
 /* Addtron products */
 product ADDTRON RHINEII0x1320  RhineII



Re: Fwd: Patch to pcidevs for a SSD drive ADATA product.

2020-01-07 Thread Jonathan Gray
On Tue, Jan 07, 2020 at 06:42:08PM +0100, Dariusz Sendkowski wrote:
> Hi,
> 
> I've bought a new SSD drive by ADATA recently and its vendor and product
> IDs are missing in pcidevs. Here is a patch to add it to the pcidevs.
> 
> Vendor and product info is taken from:
> https://devicehunt.com/view/type/pci/vendor/1CC1/device/8201
> 

The official place for vendor ids is
https://pcisig.com/membership/member-companies?combine=1cc1

> 
> Index: pcidevs
> ===
> RCS file: /cvs/src/sys/dev/pci/pcidevs,v
> retrieving revision 1.1911
> diff -u -p -u -p -r1.1911 pcidevs
> --- pcidevs 5 Jan 2020 12:54:21 - 1.1911
> +++ pcidevs 7 Jan 2020 17:23:14 -
> @@ -336,6 +336,7 @@ vendor ETRON 0x1b6f Etron
>  vendor FRESCO 0x1b73 Fresco Logic
>  vendor WCH2 0x1c00 Nanjing QinHeng Electronics
>  vendor SYMPHONY2 0x1c1c Symphony Labs
> +vendor ADATA 0x1cc1 ADATA Technology
>  vendor UMIS 0x1cc4 Union Memory
>  vendor ROCKCHIP 0x1d87 Rockchip
>  vendor TEKRAM2 0x1de1 Tekram
> @@ -7834,6 +7835,9 @@ product UMC UM9017F 0x9017 UM9017F
>  product UMC UM8886E_OR_WHAT 0xe886 ISA
>  product UMC UM8886N 0xe88a UM8886N
>  product UMC UM8891N 0xe891 UM8891N
> +
> +/* ADATA products */
> +product ADATA SX8200_NVME 0x8201 XPG SX8200 Pro PCIe Gen3x4 SSD

Your patch mangles whitespace and does not correctly order the ADATA
products.

Index: pcidevs
===
RCS file: /cvs/src/sys/dev/pci/pcidevs,v
retrieving revision 1.1911
diff -u -p -r1.1911 pcidevs
--- pcidevs 5 Jan 2020 12:54:21 -   1.1911
+++ pcidevs 7 Jan 2020 23:53:51 -
@@ -336,6 +336,7 @@ vendor  ETRON   0x1b6f  Etron
 vendor FRESCO  0x1b73  Fresco Logic
 vendor WCH20x1c00  Nanjing QinHeng Electronics
 vendor SYMPHONY2   0x1c1c  Symphony Labs
+vendor ADATA   0x1cc1  ADATA Technology
 vendor UMIS0x1cc4  Union Memory
 vendor ROCKCHIP0x1d87  Rockchip
 vendor TEKRAM2 0x1de1  Tekram
@@ -505,6 +506,9 @@ product ACER M1435  0x1435  M1435 VL-PCI
 product AD SP21535 0x1535  ADSP 21535 DSP
 product AD 18890x1889  AD1889 Audio
 product AD SP2141  0x2f44  SafeNet ADSP 2141
+
+/* ADATA products */
+product ADATA SX8200   0x8201  SX8200
 
 /* Addtron products */
 product ADDTRON RHINEII0x1320  RhineII



uppercase usbdevs product defines

2020-01-03 Thread Jonathan Gray
Consistently uppercase usb product defines.

Index: if_urtwn.c
===
RCS file: /cvs/src/sys/dev/usb/if_urtwn.c,v
retrieving revision 1.85
diff -u -p -r1.85 if_urtwn.c
--- if_urtwn.c  16 Nov 2019 14:08:31 -  1.85
+++ if_urtwn.c  4 Jan 2020 04:22:37 -
@@ -283,7 +283,7 @@ static const struct urtwn_type {
URTWN_DEV_8192CU(IODATA,RTL8192CU),
URTWN_DEV_8192CU(NETGEAR,   N300MA),
URTWN_DEV_8192CU(NETGEAR,   WNA1000M),
-   URTWN_DEV_8192CU(NETGEAR,   WNA1000Mv2),
+   URTWN_DEV_8192CU(NETGEAR,   WNA1000MV2),
URTWN_DEV_8192CU(NETGEAR,   RTL8192CU),
URTWN_DEV_8192CU(NETGEAR4,  RTL8188CU),
URTWN_DEV_8192CU(NETWEEN,   RTL8192CU),
Index: umsm.c
===
RCS file: /cvs/src/sys/dev/usb/umsm.c,v
retrieving revision 1.114
diff -u -p -r1.114 umsm.c
--- umsm.c  15 Aug 2018 14:13:07 -  1.114
+++ umsm.c  4 Jan 2020 04:22:00 -
@@ -139,7 +139,7 @@ static const struct umsm_type umsm_devs[
{{ USB_VENDOR_HUAWEI,   USB_PRODUCT_HUAWEI_E618 }, DEV_HUAWEI},
{{ USB_VENDOR_HUAWEI,   USB_PRODUCT_HUAWEI_E392_INIT }, DEV_UMASS5},
{{ USB_VENDOR_HUAWEI,   USB_PRODUCT_HUAWEI_EM770W }, 0},
-   {{ USB_VENDOR_HUAWEI,   USB_PRODUCT_HUAWEI_Mobile }, DEV_HUAWEI},
+   {{ USB_VENDOR_HUAWEI,   USB_PRODUCT_HUAWEI_MOBILE }, DEV_HUAWEI},
{{ USB_VENDOR_HUAWEI,   USB_PRODUCT_HUAWEI_K3765_INIT }, DEV_UMASS5},
{{ USB_VENDOR_HUAWEI,   USB_PRODUCT_HUAWEI_K3765 }, 0},
{{ USB_VENDOR_HUAWEI,   USB_PRODUCT_HUAWEI_K3772_INIT }, DEV_UMASS5},
Index: usb_quirks.c
===
RCS file: /cvs/src/sys/dev/usb/usb_quirks.c,v
retrieving revision 1.75
diff -u -p -r1.75 usb_quirks.c
--- usb_quirks.c10 Jul 2018 09:46:18 -  1.75
+++ usb_quirks.c4 Jan 2020 04:22:22 -
@@ -86,7 +86,7 @@ const struct usbd_quirk_entry {
ANY, { UQ_ASSUME_CM_OVER_DATA }},
  { USB_VENDOR_CMOTECH, USB_PRODUCT_CMOTECH_CCU550,
ANY, { UQ_ASSUME_CM_OVER_DATA }},
- { USB_VENDOR_CMOTECH, USB_PRODUCT_CMOTECH_CNU550pro,
+ { USB_VENDOR_CMOTECH, USB_PRODUCT_CMOTECH_CNU550PRO,
ANY, { UQ_ASSUME_CM_OVER_DATA }},
  { USB_VENDOR_SIEMENS2, USB_PRODUCT_SIEMENS2_ES75,
ANY, { UQ_ASSUME_CM_OVER_DATA }},
@@ -126,8 +126,8 @@ const struct usbd_quirk_entry {
  { USB_VENDOR_CYPRESS, USB_PRODUCT_CYPRESS_SISPM_OLD,  ANY,{ UQ_BAD_HID }},
  { USB_VENDOR_CYPRESS, USB_PRODUCT_CYPRESS_SISPM,  ANY,{ UQ_BAD_HID }},
  { USB_VENDOR_CYPRESS, USB_PRODUCT_CYPRESS_SISPM_FLASH,ANY,{ 
UQ_BAD_HID }},
- { USB_VENDOR_MICROCHIP, USB_PRODUCT_MICROCHIP_USBLCD20x2, ANY,{ 
UQ_BAD_HID }},
- { USB_VENDOR_MICROCHIP, USB_PRODUCT_MICROCHIP_USBLCD256x64,   ANY,{ 
UQ_BAD_HID }},
+ { USB_VENDOR_MICROCHIP, USB_PRODUCT_MICROCHIP_USBLCD20X2, ANY,{ 
UQ_BAD_HID }},
+ { USB_VENDOR_MICROCHIP, USB_PRODUCT_MICROCHIP_USBLCD256X64,   ANY,{ 
UQ_BAD_HID }},
  { USB_VENDOR_MECANIQUE, USB_PRODUCT_MECANIQUE_WISPY,  ANY,{ UQ_BAD_HID }},
  { USB_VENDOR_METAGEEK, USB_PRODUCT_METAGEEK_WISPY24I, ANY,{ UQ_BAD_HID }},
  { USB_VENDOR_MUSTEK2, USB_PRODUCT_MUSTEK2_PM800,  ANY,{ UQ_BAD_HID }},
Index: usbdevs
===
RCS file: /cvs/src/sys/dev/usb/usbdevs,v
retrieving revision 1.702
diff -u -p -r1.702 usbdevs
--- usbdevs 7 Dec 2019 08:45:28 -   1.702
+++ usbdevs 4 Jan 2020 04:20:20 -
@@ -1344,7 +1344,7 @@ product CLIPSAL 5800PC0x0301  5800PC C-
 product CLIPSAL 5500PCU0x0303  5500PCU C-Bus
 product CLIPSAL 5000CT20x0304  5000CT2 C-Bus Touch Screen
 product CLIPSAL C5000CT2   0x0305  C5000CT2 C-Bus Touch Screen
-product CLIPSAL L51xx  0x0401  L51xx C-Bus Dimmer
+product CLIPSAL L51XX  0x0401  L51xx C-Bus Dimmer
 
 /* Compaq products */
 product COMPAQ IPAQPOCKETPC0x0003  iPAQ PocketPC
@@ -1362,7 +1362,7 @@ product CTC CW66220x6622  CW6622
 product CMOTECH CNU510 0x5141  CDMA Technologies USB modem
 product CMOTECH CM5100P0x5523  CM-5100P EVDO
 product CMOTECH CCU550 0x5533  CCU-550 EVDO
-product CMOTECH CNU550pro  0x5543  CNU-550pro EVDO
+product CMOTECH CNU550PRO  0x5543  CNU-550pro EVDO
 product CMOTECH CGU628 0x6006  CGU-628
 product CMOTECH CNU680 0x6803  CNU-680
 product CMOTECH CGU628_DISK0xf000  CGU-628 disk mode
@@ -2163,7 +2163,7 @@ product HP KBDHUB 0x010c  Multimedia Key
 product HP HN210W  0x011c  HN210W
 product HP HPX9GP  0x0121  HP-x9G+
 product HP 6200C   0x0201  ScanJet 6200C
-product HP S20b0x0202  PhotoSmart S20
+product HP S20B0x0202  PhotoSmart S20
 product HP 815C

uppercase pcidevs product defines

2020-01-03 Thread Jonathan Gray
Consistently uppercase pci product defines.

does not address IBM oddities like
product IBM 0x0002  0x0002  MCA

minor changes to avoid duplicate defines or unclear names
(IIi -> 2I instead of III).

Index: arch/i386/pci/geodesc.c
===
RCS file: /cvs/src/sys/arch/i386/pci/geodesc.c,v
retrieving revision 1.13
diff -u -p -r1.13 geodesc.c
--- arch/i386/pci/geodesc.c 10 Dec 2014 12:27:56 -  1.13
+++ arch/i386/pci/geodesc.c 4 Jan 2020 03:50:20 -
@@ -75,7 +75,7 @@ geodesc_match(struct device *parent, voi
 
if (PCI_VENDOR(pa->pa_id) == PCI_VENDOR_NS &&
(PCI_PRODUCT(pa->pa_id) == PCI_PRODUCT_NS_SC1100_XBUS ||
-PCI_PRODUCT(pa->pa_id) == PCI_PRODUCT_NS_SCx200_XBUS))
+PCI_PRODUCT(pa->pa_id) == PCI_PRODUCT_NS_SCX200_XBUS))
return (1);
return (0);
 }
Index: dev/cardbus/if_fxp_cardbus.c
===
RCS file: /cvs/src/sys/dev/cardbus/if_fxp_cardbus.c,v
retrieving revision 1.36
diff -u -p -r1.36 if_fxp_cardbus.c
--- dev/cardbus/if_fxp_cardbus.c24 Nov 2015 17:11:39 -  1.36
+++ dev/cardbus/if_fxp_cardbus.c4 Jan 2020 03:50:22 -
@@ -93,7 +93,7 @@ struct cfattach fxp_cardbus_ca = {
 };
 
 const struct pci_matchid fxp_cardbus_devices[] = {
-   { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_8255x },
+   { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_8255X },
 };
 
 #ifdef CBB_DEBUG
Index: dev/pci/ciss_pci.c
===
RCS file: /cvs/src/sys/dev/pci/ciss_pci.c,v
retrieving revision 1.20
diff -u -p -r1.20 ciss_pci.c
--- dev/pci/ciss_pci.c  20 Oct 2014 19:19:20 -  1.20
+++ dev/pci/ciss_pci.c  4 Jan 2020 03:50:22 -
@@ -51,9 +51,9 @@ const struct pci_matchid ciss_pci_device
{ PCI_VENDOR_COMPAQ,PCI_PRODUCT_COMPAQ_CSA5300 },
{ PCI_VENDOR_COMPAQ,PCI_PRODUCT_COMPAQ_CSA5300_2 },
{ PCI_VENDOR_COMPAQ,PCI_PRODUCT_COMPAQ_CSA5312 },
-   { PCI_VENDOR_COMPAQ,PCI_PRODUCT_COMPAQ_CSA5i },
-   { PCI_VENDOR_COMPAQ,PCI_PRODUCT_COMPAQ_CSA5i_2 },
-   { PCI_VENDOR_COMPAQ,PCI_PRODUCT_COMPAQ_CSA6i },
+   { PCI_VENDOR_COMPAQ,PCI_PRODUCT_COMPAQ_CSA5I },
+   { PCI_VENDOR_COMPAQ,PCI_PRODUCT_COMPAQ_CSA5I_2 },
+   { PCI_VENDOR_COMPAQ,PCI_PRODUCT_COMPAQ_CSA6I },
{ PCI_VENDOR_COMPAQ,PCI_PRODUCT_COMPAQ_CSA641 },
{ PCI_VENDOR_COMPAQ,PCI_PRODUCT_COMPAQ_CSA642 },
{ PCI_VENDOR_COMPAQ,PCI_PRODUCT_COMPAQ_CSA6400 },
@@ -152,7 +152,7 @@ ciss_pci_attach(struct device *parent, s
sc->iem = CISS_READYENA;
reg = pci_conf_read(pa->pa_pc, pa->pa_tag, PCI_SUBSYS_ID_REG);
if (PCI_VENDOR(reg) == PCI_VENDOR_COMPAQ &&
-   (PCI_PRODUCT(reg) == PCI_PRODUCT_COMPAQ_CSA5i ||
+   (PCI_PRODUCT(reg) == PCI_PRODUCT_COMPAQ_CSA5I ||
 PCI_PRODUCT(reg) == PCI_PRODUCT_COMPAQ_CSA532 ||
 PCI_PRODUCT(reg) == PCI_PRODUCT_COMPAQ_CSA5312))
sc->iem = CISS_READYENAB;
Index: dev/pci/envy.c
===
RCS file: /cvs/src/sys/dev/pci/envy.c,v
retrieving revision 1.80
diff -u -p -r1.80 envy.c
--- dev/pci/envy.c  23 Nov 2019 17:22:10 -  1.80
+++ dev/pci/envy.c  4 Jan 2020 03:50:22 -
@@ -217,7 +217,7 @@ struct midi_hw_if envy_midi_hw_if = {
 
 struct pci_matchid envy_matchids[] = {
{ PCI_VENDOR_ICENSEMBLE, PCI_PRODUCT_ICENSEMBLE_ICE1712 },
-   { PCI_VENDOR_ICENSEMBLE, PCI_PRODUCT_ICENSEMBLE_VT172x }
+   { PCI_VENDOR_ICENSEMBLE, PCI_PRODUCT_ICENSEMBLE_VT172X }
 };
 
 /*
@@ -1723,7 +1723,7 @@ envyattach(struct device *parent, struct
sc->ibuf.addr = sc->obuf.addr = NULL;
sc->ccs_iosz = 0;
sc->mt_iosz = 0;
-   sc->isht = (PCI_PRODUCT(pa->pa_id) == PCI_PRODUCT_ICENSEMBLE_VT172x);
+   sc->isht = (PCI_PRODUCT(pa->pa_id) == PCI_PRODUCT_ICENSEMBLE_VT172X);
 
if (pci_mapreg_map(pa, ENVY_CTL_BAR, PCI_MAPREG_TYPE_IO, 0,
>ccs_iot, >ccs_ioh, NULL, >ccs_iosz, 0)) {
Index: dev/pci/gdt_pci.c
===
RCS file: /cvs/src/sys/dev/pci/gdt_pci.c,v
retrieving revision 1.25
diff -u -p -r1.25 gdt_pci.c
--- dev/pci/gdt_pci.c   14 Mar 2015 03:38:48 -  1.25
+++ dev/pci/gdt_pci.c   4 Jan 2020 03:50:22 -
@@ -191,52 +191,52 @@ gdt_pci_attach(struct device *parent, st
if (PCI_VENDOR(pa->pa_id) == PCI_VENDOR_VORTEX) {
prod = PCI_PRODUCT(pa->pa_id);
switch (prod) {
-   case PCI_PRODUCT_VORTEX_GDT_60x0:
+   case PCI_PRODUCT_VORTEX_GDT_60X0:
case PCI_PRODUCT_VORTEX_GDT_6000B:
sc->sc_class = GDT_PCI;
break;
 
-   case PCI_PRODUCT_VORTEX_GDT_6x10:
-   case PCI_PRODUCT_VORTEX_GDT_6x20:
+   

drop AMD64 strings in pcidevs

2020-01-03 Thread Jonathan Gray
ie "AMD AMD64 17h Root Complex" -> "AMD 17h Root Complex"

Index: arch/amd64/pci/pchb.c
===
RCS file: /cvs/src/sys/arch/amd64/pci/pchb.c,v
retrieving revision 1.43
diff -u -p -r1.43 pchb.c
--- arch/amd64/pci/pchb.c   28 Apr 2018 15:44:59 -  1.43
+++ arch/amd64/pci/pchb.c   3 Jan 2020 00:31:08 -
@@ -159,8 +159,8 @@ pchbattach(struct device *parent, struct
case PCI_VENDOR_AMD:
printf("\n");
switch (PCI_PRODUCT(pa->pa_id)) {
-   case PCI_PRODUCT_AMD_AMD64_0F_HT:
-   case PCI_PRODUCT_AMD_AMD64_10_HT:
+   case PCI_PRODUCT_AMD_0F_HT:
+   case PCI_PRODUCT_AMD_10_HT:
for (i = 0; i < AMD64HT_NUM_LDT; i++)
pchb_amd64ht_attach(self, pa, i);
break;
Index: arch/i386/pci/pchb.c
===
RCS file: /cvs/src/sys/arch/i386/pci/pchb.c,v
retrieving revision 1.90
diff -u -p -r1.90 pchb.c
--- arch/i386/pci/pchb.c28 Apr 2018 15:44:59 -  1.90
+++ arch/i386/pci/pchb.c3 Jan 2020 00:31:19 -
@@ -185,8 +185,8 @@ pchbattach(struct device *parent, struct
case PCI_VENDOR_AMD:
printf("\n");
switch (PCI_PRODUCT(pa->pa_id)) {
-   case PCI_PRODUCT_AMD_AMD64_0F_HT:
-   case PCI_PRODUCT_AMD_AMD64_10_HT:
+   case PCI_PRODUCT_AMD_0F_HT:
+   case PCI_PRODUCT_AMD_10_HT:
for (i = 0; i < AMD64HT_NUM_LDT; i++)
pchb_amd64ht_attach(self, pa, i);
break;
Index: dev/pci/amas.c
===
RCS file: /cvs/src/sys/dev/pci/amas.c,v
retrieving revision 1.5
diff -u -p -r1.5 amas.c
--- dev/pci/amas.c  15 Jun 2014 11:43:24 -  1.5
+++ dev/pci/amas.c  3 Jan 2020 00:28:12 -
@@ -132,9 +132,9 @@ struct cfdriver amas_cd = {
 };
 
 const struct pci_matchid amas_devices[] = {
-   { PCI_VENDOR_AMD, PCI_PRODUCT_AMD_AMD64_0F_ADDR },
-   { PCI_VENDOR_AMD, PCI_PRODUCT_AMD_AMD64_10_ADDR },
-   { PCI_VENDOR_AMD, PCI_PRODUCT_AMD_AMD64_11_ADDR },
+   { PCI_VENDOR_AMD, PCI_PRODUCT_AMD_0F_ADDR },
+   { PCI_VENDOR_AMD, PCI_PRODUCT_AMD_10_ADDR },
+   { PCI_VENDOR_AMD, PCI_PRODUCT_AMD_11_ADDR },
 };
 
 int
@@ -161,13 +161,13 @@ amas_attach(struct device *parent, struc
amas->pa_pc = pa->pa_pc;
 
switch (PCI_PRODUCT(pa->pa_id)) {
-   case PCI_PRODUCT_AMD_AMD64_0F_ADDR:
+   case PCI_PRODUCT_AMD_0F_ADDR:
amas->family = AMAS_FAM_0Fh;
break;
-   case PCI_PRODUCT_AMD_AMD64_10_ADDR:
+   case PCI_PRODUCT_AMD_10_ADDR:
amas->family = AMAS_FAM_10h;
break;
-   case PCI_PRODUCT_AMD_AMD64_11_ADDR:
+   case PCI_PRODUCT_AMD_11_ADDR:
amas->family = AMAS_FAM_11h;
break;
}
Index: dev/pci/azalia.c
===
RCS file: /cvs/src/sys/dev/pci/azalia.c,v
retrieving revision 1.253
diff -u -p -r1.253 azalia.c
--- dev/pci/azalia.c14 Oct 2019 01:59:14 -  1.253
+++ dev/pci/azalia.c3 Jan 2020 00:28:35 -
@@ -528,8 +528,8 @@ azalia_pci_attach(struct device *parent,
/* disable MSI for AMD Summit Ridge/Raven Ridge HD Audio */
if (PCI_VENDOR(sc->pciid) == PCI_VENDOR_AMD) {
switch (PCI_PRODUCT(sc->pciid)) {
-   case PCI_PRODUCT_AMD_AMD64_17_HDA:
-   case PCI_PRODUCT_AMD_AMD64_17_1X_HDA:
+   case PCI_PRODUCT_AMD_17_HDA:
+   case PCI_PRODUCT_AMD_17_1X_HDA:
pa->pa_flags &= ~PCI_FLAGS_MSI_ENABLED;
}
}
Index: dev/pci/ccp_pci.c
===
RCS file: /cvs/src/sys/dev/pci/ccp_pci.c,v
retrieving revision 1.4
diff -u -p -r1.4 ccp_pci.c
--- dev/pci/ccp_pci.c   2 Jan 2020 22:34:41 -   1.4
+++ dev/pci/ccp_pci.c   3 Jan 2020 00:28:51 -
@@ -43,11 +43,11 @@ struct cfattach ccp_pci_ca = {
 };
 
 static const struct pci_matchid ccp_pci_devices[] = {
-   { PCI_VENDOR_AMD,   PCI_PRODUCT_AMD_AMD64_16_CCP },
-   { PCI_VENDOR_AMD,   PCI_PRODUCT_AMD_AMD64_17_CCP_1 },
-   { PCI_VENDOR_AMD,   PCI_PRODUCT_AMD_AMD64_17_CCP_2 },
-   { PCI_VENDOR_AMD,   PCI_PRODUCT_AMD_AMD64_17_1X_CCP },
-   { PCI_VENDOR_AMD,   PCI_PRODUCT_AMD_AMD64_17_3X_CCP },
+   { PCI_VENDOR_AMD,   PCI_PRODUCT_AMD_16_CCP },
+   { PCI_VENDOR_AMD,   PCI_PRODUCT_AMD_17_CCP_1 },
+   { PCI_VENDOR_AMD,   PCI_PRODUCT_AMD_17_CCP_2 },
+   { PCI_VENDOR_AMD,   PCI_PRODUCT_AMD_17_1X_CCP },
+   { PCI_VENDOR_AMD,   PCI_PRODUCT_AMD_17_3X_CCP },
 };
 
 int
Index: dev/pci/kate.c

Re: Add pcidev for Ryzen 3x ccp

2020-01-01 Thread Jonathan Gray
On Wed, Jan 01, 2020 at 09:25:16PM -0500, Todd Mortimer wrote:
> On Thu, Jan 02, 2020 at 09:33:59AM +1000, Jonathan Matthew wrote:
> > On Thu, Jan 02, 2020 at 10:20:52AM +1100, Jonathan Gray wrote:
> > > On Wed, Jan 01, 2020 at 11:21:45AM -0500, Todd Mortimer wrote:
> > > > On Thu, Jan 02, 2020 at 02:41:11AM +1100, Jonathan Gray wrote:
> > > > > On Wed, Jan 01, 2020 at 09:53:39AM -0500, Todd Mortimer wrote:
> > > > > > My CPU has a CCP that isn't in the known list, so add it and tell 
> > > > > > ccp
> > > > > > about it.
> > > > > > 
> > > > > > Tested on Ryzen 3900x.
> > > > > > 
> > > > > > ok? 
> > > > > > 
> > > > > > Will commit a pcidevs regen immediately after.
> > > > > 
> > > > > Are your cpu lines in dmesg 17-3* or 17-7*?
> > > > > Ryzen 3900x should be model 7X.
> > > > 
> > > > 17-71-00.
> > > > 
> > > > cpu0: AMD Ryzen 9 3900X 12-Core Processor, 3792.88 MHz, 17-71-00
> > > > 
> > > > I assume then change the constant bits to 17_7X and 17h/7xh ?
> > > 
> > > Yes, unless that device id is also known to appear on earlier
> > > models as well, in which case the first appearance is used.
> > 
> > Also found here:
> > 
> > cpu3: AMD EPYC 7502P 32-Core Processor, 2495.32 MHz, 17-31-00
> > 
> > vendor "AMD", unknown product 0x1486 (class crypto subclass miscellaneous, 
> > rev 0x00) at pci8 dev 0 function 1 not configured
> > 
> 
> In that case, the original 17/3x labelling would be correct, which also
> agrees with some of the other pcidev ids in the same numeric range.
> 
> I have to admit, I would be just as happy to just label everything 17h
> and drop the /[123..]x parts, but I don't really mind one way or the
> other.
> 
> ok for the original diff then?

yes

I also agree that it would be cleaner to just have something like

product AMD CCP_1   0x1456  Crypto
product AMD CCP_2   0x1468  Crypto
product AMD CCP_3   0x1486  Crypto
product AMD CCP_4   0x1537  Crypto
product AMD CCP_5   0x15df  Crypto

And in other devices we could drop the "AMD64" as well.



Re: Add pcidev for Ryzen 3x ccp

2020-01-01 Thread Jonathan Gray
On Wed, Jan 01, 2020 at 11:21:45AM -0500, Todd Mortimer wrote:
> On Thu, Jan 02, 2020 at 02:41:11AM +1100, Jonathan Gray wrote:
> > On Wed, Jan 01, 2020 at 09:53:39AM -0500, Todd Mortimer wrote:
> > > My CPU has a CCP that isn't in the known list, so add it and tell ccp
> > > about it.
> > > 
> > > Tested on Ryzen 3900x.
> > > 
> > > ok? 
> > > 
> > > Will commit a pcidevs regen immediately after.
> > 
> > Are your cpu lines in dmesg 17-3* or 17-7*?
> > Ryzen 3900x should be model 7X.
> 
> 17-71-00.
> 
> cpu0: AMD Ryzen 9 3900X 12-Core Processor, 3792.88 MHz, 17-71-00
> 
> I assume then change the constant bits to 17_7X and 17h/7xh ?

Yes, unless that device id is also known to appear on earlier
models as well, in which case the first appearance is used.

> 
> > 
> > > 
> > > 
> > > diff --git a/sys/dev/pci/ccp_pci.c b/sys/dev/pci/ccp_pci.c
> > > index 2259594644b..c8dcc8750fc 100644
> > > --- a/sys/dev/pci/ccp_pci.c
> > > +++ b/sys/dev/pci/ccp_pci.c
> > > @@ -47,6 +47,7 @@ static const struct pci_matchid ccp_pci_devices[] = {
> > >   { PCI_VENDOR_AMD,   PCI_PRODUCT_AMD_AMD64_17_CCP_1 },
> > >   { PCI_VENDOR_AMD,   PCI_PRODUCT_AMD_AMD64_17_CCP_2 },
> > >   { PCI_VENDOR_AMD,   PCI_PRODUCT_AMD_AMD64_17_1X_CCP },
> > > + { PCI_VENDOR_AMD,   PCI_PRODUCT_AMD_AMD64_17_3X_CCP },
> > >  };
> > >  
> > >  int
> > > diff --git a/sys/dev/pci/pcidevs b/sys/dev/pci/pcidevs
> > > index d0a021b89bc..fb918e8de5d 100644
> > > --- a/sys/dev/pci/pcidevs
> > > +++ b/sys/dev/pci/pcidevs
> > > @@ -754,6 +754,7 @@ product AMD AMD64_17_CCP_20x1468  AMD64 17h Crypto
> > >  product AMD AMD64_17_PCIE_4  0x1470  AMD64 17h PCIE
> > >  product AMD AMD64_17_PCIE_5  0x1471  AMD64 17h PCIE
> > >  product AMD AMD64_17_3X_RC   0x1480  AMD64 17h/3xh Root Complex
> > > +product AMD AMD64_17_3X_CCP  0x1486  AMD64 17h/3xh Crypto
> > >  product AMD AMD64_14_HB  0x1510  AMD64 14h Host
> > >  product AMD AMD64_14_PCIE_1  0x1512  AMD64 14h PCIE
> > >  product AMD AMD64_14_PCIE_2  0x1513  AMD64 14h PCIE
> > > 
> > > 
> 
> 



Re: Add pcidev for Ryzen 3x ccp

2020-01-01 Thread Jonathan Gray
On Wed, Jan 01, 2020 at 09:53:39AM -0500, Todd Mortimer wrote:
> My CPU has a CCP that isn't in the known list, so add it and tell ccp
> about it.
> 
> Tested on Ryzen 3900x.
> 
> ok? 
> 
> Will commit a pcidevs regen immediately after.

Are your cpu lines in dmesg 17-3* or 17-7*?
Ryzen 3900x should be model 7X.

> 
> 
> diff --git a/sys/dev/pci/ccp_pci.c b/sys/dev/pci/ccp_pci.c
> index 2259594644b..c8dcc8750fc 100644
> --- a/sys/dev/pci/ccp_pci.c
> +++ b/sys/dev/pci/ccp_pci.c
> @@ -47,6 +47,7 @@ static const struct pci_matchid ccp_pci_devices[] = {
>   { PCI_VENDOR_AMD,   PCI_PRODUCT_AMD_AMD64_17_CCP_1 },
>   { PCI_VENDOR_AMD,   PCI_PRODUCT_AMD_AMD64_17_CCP_2 },
>   { PCI_VENDOR_AMD,   PCI_PRODUCT_AMD_AMD64_17_1X_CCP },
> + { PCI_VENDOR_AMD,   PCI_PRODUCT_AMD_AMD64_17_3X_CCP },
>  };
>  
>  int
> diff --git a/sys/dev/pci/pcidevs b/sys/dev/pci/pcidevs
> index d0a021b89bc..fb918e8de5d 100644
> --- a/sys/dev/pci/pcidevs
> +++ b/sys/dev/pci/pcidevs
> @@ -754,6 +754,7 @@ product AMD AMD64_17_CCP_20x1468  AMD64 17h Crypto
>  product AMD AMD64_17_PCIE_4  0x1470  AMD64 17h PCIE
>  product AMD AMD64_17_PCIE_5  0x1471  AMD64 17h PCIE
>  product AMD AMD64_17_3X_RC   0x1480  AMD64 17h/3xh Root Complex
> +product AMD AMD64_17_3X_CCP  0x1486  AMD64 17h/3xh Crypto
>  product AMD AMD64_14_HB  0x1510  AMD64 14h Host
>  product AMD AMD64_14_PCIE_1  0x1512  AMD64 14h PCIE
>  product AMD AMD64_14_PCIE_2  0x1513  AMD64 14h PCIE
> 
> 



Re: Remaining infinite sleeps in sys/dev

2019-12-30 Thread Jonathan Gray
On Mon, Dec 30, 2019 at 05:06:53PM +0100, Martin Pieuchot wrote:
> Convert the remaining infinite sleeps that my grep-foo found to
> {t,m}sleep_nsec(9), ok?

more in dev spanning multiple lines

diff --git sys/dev/ic/qla.c sys/dev/ic/qla.c
index 9ab8a2f4603..d9e14705c2a 100644
--- sys/dev/ic/qla.c
+++ sys/dev/ic/qla.c
@@ -1148,8 +1148,8 @@ qla_mbox(struct qla_softc *sc, int maskin)
mtx_enter(>sc_mbox_mtx);
sc->sc_mbox_pending = 1;
while (sc->sc_mbox_pending == 1) {
-   msleep(sc->sc_mbox, >sc_mbox_mtx, PRIBIO,
-   "qlambox", 0);
+   msleep_nsec(sc->sc_mbox, >sc_mbox_mtx, PRIBIO,
+   "qlambox", INFSLP);
}
result = sc->sc_mbox[0];
sc->sc_mbox_pending = 0;
diff --git sys/dev/pci/qle.c sys/dev/pci/qle.c
index fe9475fc334..4570ca5baed 100644
--- sys/dev/pci/qle.c
+++ sys/dev/pci/qle.c
@@ -1496,8 +1496,8 @@ qle_mbox(struct qle_softc *sc, int maskin)
mtx_enter(>sc_mbox_mtx);
sc->sc_mbox_pending = 1;
while (sc->sc_mbox_pending == 1) {
-   msleep(sc->sc_mbox, >sc_mbox_mtx, PRIBIO,
-   "qlembox", 0);
+   msleep_nsec(sc->sc_mbox, >sc_mbox_mtx, PRIBIO,
+   "qlembox", INFSLP);
}
result = sc->sc_mbox[0];
sc->sc_mbox_pending = 0;
diff --git sys/dev/vscsi.c sys/dev/vscsi.c
index df5ddbe827c..c5794474c29 100644
--- sys/dev/vscsi.c
+++ sys/dev/vscsi.c
@@ -646,8 +646,8 @@ vscsiclose(dev_t dev, int flags, int mode, struct proc *p)
 
mtx_enter(>sc_state_mtx);
while (sc->sc_ref_count > 0) {
-   msleep(>sc_ref_count, >sc_state_mtx,
-   PRIBIO, "vscsiref", 0);
+   msleep_nsec(>sc_ref_count, >sc_state_mtx,
+   PRIBIO, "vscsiref", INFSLP);
}
mtx_leave(>sc_state_mtx);
 



Re: mpii: attach Flash Accelerator F80 800G eMLC

2019-12-27 Thread Jonathan Gray
On Sat, Dec 28, 2019 at 02:35:39AM +0100, Klemens Nanni wrote:
> On Sat, Dec 28, 2019 at 11:10:28AM +1000, Jonathan Matthew wrote:
> > It'd be better to use the LSI chip name for this, which is SSS6200.  There 
> > are
> > other devices with different flash configurations using the same 
> > vendor/product
> > ID.  Searching ebay for 'lsi nytro' or 'lsi sss6200' will find a few 
> > different
> > varieties.
> That makes sense.  FWIW, FreeBSD also calls it by the chip name:
> 
> #define MPI2_MFGPAGE_DEVID_SSS6200  (0x007E)
> 
> OK?

drop the _PCIE and just have

product SYMBIOS SSS6200

> 
> 
> Index: mpii.c
> ===
> RCS file: /cvs/src/sys/dev/pci/mpii.c,v
> retrieving revision 1.121
> diff -u -p -r1.121 mpii.c
> --- mpii.c12 Sep 2019 22:22:53 -  1.121
> +++ mpii.c28 Dec 2019 01:32:41 -
> @@ -413,6 +413,7 @@ mpii_dvatosge(struct mpii_sge *sge, u_in
>  static const struct pci_matchid mpii_devices[] = {
>   { PCI_VENDOR_SYMBIOS,   PCI_PRODUCT_SYMBIOS_SAS2004 },
>   { PCI_VENDOR_SYMBIOS,   PCI_PRODUCT_SYMBIOS_SAS2008 },
> + { PCI_VENDOR_SYMBIOS,   PCI_PRODUCT_SYMBIOS_SSS6200_PCIE },
>   { PCI_VENDOR_SYMBIOS,   PCI_PRODUCT_SYMBIOS_SAS2108_3 },
>   { PCI_VENDOR_SYMBIOS,   PCI_PRODUCT_SYMBIOS_SAS2108_4 },
>   { PCI_VENDOR_SYMBIOS,   PCI_PRODUCT_SYMBIOS_SAS2108_5 },
> Index: pcidevs
> ===
> RCS file: /cvs/src/sys/dev/pci/pcidevs,v
> retrieving revision 1.1902
> diff -u -p -r1.1902 pcidevs
> --- pcidevs   20 Nov 2019 16:33:00 -  1.1902
> +++ pcidevs   28 Dec 2019 01:32:21 -
> @@ -6195,6 +6195,7 @@ product SYMBIOS SAS2108_5   0x0077  SAS2108
>  product SYMBIOS SAS2108_10x0078  MegaRAID SAS2108 CRYPTO GEN2
>  product SYMBIOS SAS2108_20x0079  MegaRAID SAS2108 GEN2
>  product SYMBIOS SAS1078DE0x007c  SAS1078DE
> +product SYMBIOS SSS6200_PCIE 0x007e  SSS6200
>  product SYMBIOS SAS2208_10x0080  SAS2208
>  product SYMBIOS SAS2208_20x0081  SAS2208
>  product SYMBIOS SAS2208_30x0082  SAS2208
> 
> 



Re: amd gpio controller

2019-12-21 Thread Jonathan Gray
On Sat, Dec 21, 2019 at 10:35:28AM +0100, Mark Kettenis wrote:
> > From: James Hastings 
> > Date: Sat, 21 Dec 2019 03:52:43 -0500 (EST)
> > 
> > Hi,
> > 
> > New driver for AMD GPIO controller.
> > 
> > Datasheet is BKDG for AMD family 16h models 30h-3Fh processors.
> > 
> > Testing and feedback appreciated.
> 
> Looks good to me.  Maybe somebody with an x395 or x495 can give this a
> quick test before I commit this?

A X470 machine with Ryzen 5 2600X 17-08-02 still boots with this

@@ -141,7 +141,7 @@ acpipci0 at acpi0 PCI0: 0x0010 0x0011 0x00
 acpicmos0 at acpi0
 "PNP0C14" at acpi0 not configured
 acpibtn0 at acpi0: PWRB
-"AMDI0030" at acpi0 not configured
+amdgpio0 at acpi0: GPIO uid 0 addr 0xfed81500/0x400 irq 7, 184 pins
 "AMDIF030" at acpi0 not configured
 "PNP0C14" at acpi0 not configured
 cpu0: 3593 MHz: speeds: 3600 3200 2200 MHz

AMDI0030/AMD0030 which this driver covers is for "KERNCZ" / "KernCZ"
AMDIF030/AMDF030 is "AMD Promontory GPIO"

> 
> > Index: share/man/man4/Makefile
> > ===
> > RCS file: /cvs/src/share/man/man4/Makefile,v
> > retrieving revision 1.746
> > diff -u -p -u -r1.746 Makefile
> > --- share/man/man4/Makefile 17 Dec 2019 23:05:45 -  1.746
> > +++ share/man/man4/Makefile 21 Dec 2019 08:03:32 -
> > @@ -10,7 +10,7 @@ MAN=  aac.4 abcrtc.4 ac97.4 acphy.4 acrtc
> > admtm.4 admtmp.4 admtt.4 adt.4 adtfsm.4 adv.4 age.4 alc.4 ale.4 \
> > aggr.4 agp.4 \
> > ahc.4 ahci.4 ahd.4 aibs.4 aic.4 \
> > -   akbd.4 alipm.4 amas.4 amdiic.4 amdpm.4 ami.4 \
> > +   akbd.4 alipm.4 amas.4 amdgpio.4 amdiic.4 amdpm.4 ami.4 \
> > amlclock.4 amldwusb.4 amliic.4 amlmmc.4 amlpciephy.4 amlpinctrl.4 \
> > amlpwm.4 amlreset.4 amlrng.4 amluart.4 amlusbphy.4 \
> > amphy.4 ams.4 an.4 andl.4 aplgpio.4 aps.4 arc.4 arcofi.4 \
> > Index: share/man/man4/acpi.4
> > ===
> > RCS file: /cvs/src/share/man/man4/acpi.4,v
> > retrieving revision 1.59
> > diff -u -p -u -r1.59 acpi.4
> > --- share/man/man4/acpi.4   24 Jun 2019 21:33:27 -  1.59
> > +++ share/man/man4/acpi.4   21 Dec 2019 08:03:32 -
> > @@ -90,6 +90,8 @@ ACPI video
> >  ACPI video output
> >  .It Xr aibs 4
> >  ASUSTeK AI Booster ACPI ATK0110 temperature, voltage, and fan sensor
> > +.It Xr amdgpio 4
> > +AMD GPIO controller
> >  .It Xr aplgpio 4
> >  Intel Apollo Lake GPIO controller
> >  .It Xr bytgpio 4
> > Index: share/man/man4/amdgpio.4
> > ===
> > RCS file: share/man/man4/amdgpio.4
> > diff -N share/man/man4/amdgpio.4
> > --- /dev/null   1 Jan 1970 00:00:00 -
> > +++ share/man/man4/amdgpio.421 Dec 2019 08:03:32 -
> > @@ -0,0 +1,49 @@
> > +.\"$OpenBSD$
> > +.\"
> > +.\" Copyright (c) 2019 James Hastings
> > +.\"
> > +.\" Permission to use, copy, modify, and distribute this software for any
> > +.\" purpose with or without fee is hereby granted, provided that the above
> > +.\" copyright notice and this permission notice appear in all copies.
> > +.\"
> > +.\" THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL 
> > WARRANTIES
> > +.\" WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
> > +.\" MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
> > +.\" ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
> > +.\" WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
> > +.\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
> > +.\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
> > +.\"
> > +.Dd $Mdocdate$
> > +.Dt AMDGPIO 4
> > +.Os
> > +.Sh NAME
> > +.Nm amdgpio
> > +.Nd AMD GPIO controller
> > +.Sh SYNOPSIS
> > +.Cd "amdgpio* at acpi?"
> > +.Sh DESCRIPTION
> > +The
> > +.Nm
> > +driver provides support for the GPIO controller found on AMD chipsets. 
> > +It does not provide direct device driver entry points but makes its
> > +functions available to
> > +.Xr acpi 4 .
> > +.Sh SEE ALSO
> > +.Xr acpi 4 ,
> > +.Xr intro 4
> > +.Sh HISTORY
> > +The
> > +.Nm
> > +driver first appeared in
> > +.Ox 6.7 .
> > +.Sh AUTHORS
> > +.An -nosplit
> > +The
> > +.Nm
> > +driver was written by
> > +.An James Hastings
> > +based on the
> > +.Xr bytgpio 4
> > +driver by
> > +.An Mark Kettenis Aq Mt kette...@openbsd.org .
> > Index: sys/arch/amd64/conf/GENERIC
> > ===
> > RCS file: /cvs/src/sys/arch/amd64/conf/GENERIC,v
> > retrieving revision 1.483
> > diff -u -p -u -r1.483 GENERIC
> > --- sys/arch/amd64/conf/GENERIC 17 Dec 2019 13:08:54 -  1.483
> > +++ sys/arch/amd64/conf/GENERIC 21 Dec 2019 08:03:33 -
> > @@ -60,6 +60,7 @@ acpivideo*at acpi?
> >  acpivout*  at acpivideo?
> >  acpipwrres*at acpi?
> >  aibs*  at acpi?
> > +amdgpio*   at acpi?
> >  aplgpio*   at acpi?
> > 

Re: ublink(4), led(4) and ledctl(1)

2019-12-13 Thread Jonathan Gray
On Fri, Dec 13, 2019 at 10:34:59PM +0100, Patrick Wildt wrote:
> Hi,
> 
> I have a ThingM blink(1) USB RGB device that shows up as uhid(4).
> The tooling is "interesting", especially with all those libusb and
> HID libraries doing the abstraction.  This introduces ublink(4), a
> dedicated kernel driver for that device.  There are two LEDs on the
> device, which can be modified seperately.  The firmware is impress-
> ive and provides features like playing sequences and adjusting how
> long it should take to fade from one colour to another.  Obviously
> this also increases the complexity of the tools involved to toggle
> those RGB LEDs.  Thus, the driver is kept simple (for now).
> 
> In addition to providing a way to set RGB LEDs, we can also use it
> as a watchdog.  If we don't "tickle" it in a specific timeframe it
> will play a (unless otherwise programmed) random sequence, which for
> instance can be used to see that the machine has paniced.  This has
> been quite useful while debugging the USB stack, because once the
> magic sequence started you know that you're in deep trouble.  All
> other features are unimplemented.  Gamma correction would be nice
> to have.
> 
> Since there is no abstraction layer for LEDs yet, this also intro-
> duces led(4), which attaches to ublink(4), and provides /dev/ledX.

There is the machdep.led_blink sysctl CPU_LED_BLINK implemented by
multiple architectures to blink based on load average.

See
man4.hppa/lcd.4:.Ar machdep.led_blink
man4.sparc64/auxio.4:.Ar machdep.led_blink
man4.sparc64/clkbrd.4:.Ar machdep.led_blink
man4.sparc64/fhc.4:.Ar machdep.led_blink
man4.sparc64/led.4:.Ar machdep.led_blink
man4.sparc64/ppm.4:.Ar machdep.led_blink

sys/arch/alpha/include/cpu.h:   { "led_blink", CTLTYPE_INT } \
sys/arch/hppa/include/cpu.h:{ "led_blink", CTLTYPE_INT }, \
sys/arch/landisk/include/cpu.h: { "led_blink",  CTLTYPE_INT }   
\
sys/arch/sparc64/include/cpu.h: { "led_blink", CTLTYPE_INT },   \



C11 visibility in libc++

2019-12-06 Thread Jonathan Gray
While we don't have C11's quick_exit() we do have timespec_get() and
struct timespec/aligned_alloc().

Index: include/__config
===
RCS file: /cvs/src/lib/libcxx/include/__config,v
retrieving revision 1.6
diff -u -p -r1.6 __config
--- include/__config17 Jun 2019 22:28:51 -  1.6
+++ include/__config7 Dec 2019 03:10:51 -
@@ -341,6 +341,9 @@
 #  if defined(__FreeBSD__)
 #define _LIBCPP_HAS_QUICK_EXIT
 #define _LIBCPP_HAS_C11_FEATURES
+#  elif defined(__OpenBSD__)
+#define _LIBCPP_HAS_TIMESPEC_GET
+#define _LIBCPP_HAS_C11_FEATURES
 #  elif defined(__Fuchsia__)
 #define _LIBCPP_HAS_QUICK_EXIT
 #define _LIBCPP_HAS_TIMESPEC_GET



Re: drmbackoff

2019-11-28 Thread Jonathan Gray
On Wed, Nov 27, 2019 at 05:18:32PM +0100, Mark Kettenis wrote:
> The inteldrm(4) driver keeps a cache of graphics objects, allegedly to
> make things faster by avoiding cache flushes.  But those graphics
> objects consume memory that we want to free if we need it for
> something else.
> 
> The diff below hooks up the "shrinker" code in inteldrm(4) and calls
> it from the pagedeamon if it thinks it needs to free up memory.
> 
> The diff still has some debug printfs such that we can tell that the
> code is actually called.
> 
> Please test if you have inteldrm(4), esepcially on machines with
> limited amounts of physical memory.

unregister_shrinker() coming as well?

Here is an additional ttm diff for radeondrm/amdgpu.

Index: dev/pci/drm/ttm/ttm_page_alloc.c
===
RCS file: /cvs/src/sys/dev/pci/drm/ttm/ttm_page_alloc.c,v
retrieving revision 1.16
diff -u -p -r1.16 ttm_page_alloc.c
--- dev/pci/drm/ttm/ttm_page_alloc.c27 Apr 2019 08:10:32 -  1.16
+++ dev/pci/drm/ttm/ttm_page_alloc.c28 Nov 2019 10:37:09 -
@@ -107,9 +107,7 @@ struct ttm_pool_opts {
  **/
 struct ttm_pool_manager {
struct kobject  kobj;
-#ifdef notyet
struct shrinker mm_shrink;
-#endif
struct ttm_pool_optsoptions;
 
union {
@@ -388,7 +386,6 @@ out:
  *
  * This code is crying out for a shrinker per pool
  */
-#ifdef notyet
 static unsigned long
 ttm_pool_shrink_scan(struct shrinker *shrink, struct shrink_control *sc)
 {
@@ -441,17 +438,13 @@ ttm_pool_shrink_count(struct shrinker *s
 
return count;
 }
-#endif
 
 static int ttm_pool_mm_shrink_init(struct ttm_pool_manager *manager)
 {
-#ifdef notyet
manager->mm_shrink.count_objects = ttm_pool_shrink_count;
manager->mm_shrink.scan_objects = ttm_pool_shrink_scan;
manager->mm_shrink.seeks = 1;
return register_shrinker(>mm_shrink);
-#endif
-   return 0;
 }
 
 static void ttm_pool_mm_shrink_fini(struct ttm_pool_manager *manager)



Re: un-boolean_t ANSIfy ddb(4) for hppa & sparc64

2019-11-20 Thread Jonathan Gray
On Wed, Nov 20, 2019 at 10:25:59AM -0700, Theo de Raadt wrote:
> Todd C. Miller  wrote:
> 
> > On Wed, 20 Nov 2019 10:17:09 -0700, "Theo de Raadt" wrote:
> > 
> > > Todd C. Miller  wrote:
> > >
> > > > On Wed, 20 Nov 2019 07:38:46 -0700, "Theo de Raadt" wrote:
> > > > 
> > > > > Kernel environment cannot use userland includes.
> > > > 
> > > > Some other systems have sys/stdbool.h, we could as well if we wanted
> > > > to.  The simplest approach is to move include/stdbool.h ->
> > > > sys/sys/stdbool.h and make /usr/include/stdbool.h a link to
> > > > sys/stdbool.h as we do for stdarg.h and stdint.h.
> > >
> > > But is it really neccessary?  Has int really caused everyone that
> > > much harm?
> > 
> > From a readability standpoint, it is nice to be able to use true
> > and false.  You can use those with int as well as with bool.
> 
> I don't think the type of readability stdbool.h brings results in 1
> fewer bug in the resulting code, also I think adding it to a body of
> code late risks introducing bugs.
> 
> More to the point, whenever I see codebases which mixes true/false,
> 0/-1, and 0/1, I don't pick up a vibe of "better readability".
> 
> And it gets even worse when one see that stdbool.h has 3 variations
> internally which are not 100.0% compatible.
> 
> I don't see any value bringing it to the kernel.

bool in the kernel is covered by /sys/sys/types.h not stdbool.h but is
really only for drm

revision 1.35
date: 2013/01/09 12:17:38;  author: jsg;  state: Exp;  lines: +28 -1;
add support for using c99 bool in the kernel based on our stdbool.h
ok deraadt@ millert@ espie@



use pluart(4) as console on rpi

2019-10-22 Thread Jonathan Gray
Use the pl011 as console uart instead of the 'mini uart' a quirky
8250 alike.  By default the pl011 is used for bluetooth.

When com(4) takes over the console with the mini uart on rpi3 I see
a bunch of noise before output resumes and can't interact with the
console after it has booted.  With pluart(4) as console everything is
fine.

Quoting https://www.raspberrypi.org/documentation/configuration/uart.md

"Relevant differences between PL011 and mini UART
The mini UART has smaller FIFOs. Combined with the lack of flow
control, this makes it more prone to losing characters at higher
baudrates. It is also generally less capable than the PL011, mainly
due to its baud rate link to the VPU clock speed.

The particular deficiencies of the mini UART compared to the PL011 are:

- No break detection
- No framing errors detection
- No parity bit
- No receive timeout interrupt
- No DCD, DSR, DTR or RI signals"

One of the differences of the mini uart to 8250 is noted in
http://lists.infradead.org/pipermail/linux-rpi-kernel/2017-June/006619.html

I've built a release with this diff and installed the result on rpi3b.

Index: ramdisk/Makefile
===
RCS file: /cvs/src/distrib/arm64/ramdisk/Makefile,v
retrieving revision 1.16
diff -u -p -r1.16 Makefile
--- ramdisk/Makefile3 Oct 2019 10:26:38 -   1.16
+++ ramdisk/Makefile22 Oct 2019 10:22:57 -
@@ -36,6 +36,9 @@ PIFILES=\
bcm2710-rpi-3-b-plus.dtb \
bcm2710-rpi-cm3.dtb
 
+PIDTBO=\
+   disable-bt.dtbo
+
 all: ${FS}
 
 ${FS}: bsd.rd
@@ -49,11 +52,15 @@ ${FS}: bsd.rd
 .for FILE in ${PIFILES}
cp ${PRPI}/${FILE} ${MOUNT_POINT}/
 .endfor
+   mkdir -p ${MOUNT_POINT}/overlays
+.for FILE in ${PIDTBO}
+   cp ${PRPI}/overlays/${FILE} ${MOUNT_POINT}/overlays/
+.endfor
cp ${PUBOOT}/rpi_3/u-boot.bin ${MOUNT_POINT}/
mkdir -p ${MOUNT_POINT}/efi/boot
cp /usr/mdec/BOOTAA64.EFI ${MOUNT_POINT}/efi/boot/bootaa64.efi
echo bootaa64.efi > ${MOUNT_POINT}/efi/boot/startup.nsh
-   echo 'arm_64bit=1\nenable_uart=1\nkernel=u-boot.bin' > 
${MOUNT_POINT}/config.txt
+   echo 
'arm_64bit=1\nenable_uart=1\ndtoverlay=disable-bt\nkernel=u-boot.bin' > 
${MOUNT_POINT}/config.txt
dd if=${PUBOOT}/pine64_plus/u-boot-sunxi-with-spl.bin \
of=/dev/r`cat vnd`c bs=1024 seek=8
umount ${MOUNT_POINT}
Index: ramdisk/install.md
===
RCS file: /cvs/src/distrib/arm64/ramdisk/install.md,v
retrieving revision 1.13
diff -u -p -r1.13 install.md
--- ramdisk/install.md  3 Oct 2019 10:26:38 -   1.13
+++ ramdisk/install.md  22 Oct 2019 10:22:57 -
@@ -60,9 +60,12 @@ md_installboot() {
rpi)
cp $_mdec/{bootcode.bin,start.elf,fixup.dat,*.dtb} /mnt/mnt/
cp $_mdec/u-boot.bin /mnt/mnt/
+   mkdir -p /mnt/mnt/overlays
+   cp $_mdec/disable-bt.dtbo /mnt/mnt/overlays
cat > /mnt/mnt/config.txt<<-__EOT
arm_64bit=1
enable_uart=1
+   dtoverlay=disable-bt
kernel=u-boot.bin
__EOT
;;
Index: ramdisk/list
===
RCS file: /cvs/src/distrib/arm64/ramdisk/list,v
retrieving revision 1.11
diff -u -p -r1.11 list
--- ramdisk/list7 Jun 2019 14:39:56 -   1.11
+++ ramdisk/list22 Oct 2019 10:22:57 -
@@ -97,6 +97,7 @@ COPY  /usr/local/share/raspberrypi-firmwa
 COPY   /usr/local/share/raspberrypi-firmware/boot/bootcode.bin 
usr/mdec/rpi/bootcode.bin
 COPY   /usr/local/share/raspberrypi-firmware/boot/start.elf 
usr/mdec/rpi/start.elf
 COPY   /usr/local/share/raspberrypi-firmware/boot/fixup.dat 
usr/mdec/rpi/fixup.dat
+COPY   /usr/local/share/raspberrypi-firmware/boot/overlays/disable-bt.dtbo 
usr/mdec/rpi/disable-bt.dtbo
 COPY   /usr/local/share/u-boot/rpi_3/u-boot.bin usr/mdec/rpi/u-boot.bin
 
 COPY   /usr/local/share/u-boot/pine64_plus/u-boot-sunxi-with-spl.bin 
usr/mdec/pine64/u-boot-sunxi-with-spl.bin



Re: Amdgpu card support

2019-10-17 Thread Jonathan Gray
On Thu, Oct 17, 2019 at 04:42:02PM +0100, Peter Kay wrote:
> First of all, thanks for including this, but should a diff be submitted
> to the man page that states it supports everything between SI and Vega?
> If I'm reading the documentation and past posts correctly, amdgpu uses
> Xorg's Glamor and Mesa to output anything. Mesa is at 19.0.8, so it
> should support Vega, but not Navi (Navi support seems to arrive in 19.2).
> I've just bought a Vega56 on the grounds it would shortly be supported in
> OpenBSD (didn't expect it this fast!), is supported in Free/NetBSD, has
> open source drivers, and at least isn't actively blocking PCI
> passthrough. 
> (I didn't choose the Vega64 as the 56 seems to be able to be made quieter
> and retain most of the performance. The RX 5700 cards appear to still be
> bedding in)
> PK

Support for parts covered by radeondrm (SI, CIK) is not compiled into
the amdgpu kernel driver.  There is no support for Navi in the
linux 4.19 based code and Vega 20/Radeon VII support is prelimary and
disabled.

There are still problems with amdgpu compared to other drm drivers,
it was enabled as people considered the current situation an improvement
over not having it.

I'd rather leave the xf86-video-amdgpu man page as is.



Re: system boot hang due to inteldrm(4)

2019-10-03 Thread Jonathan Gray
On Thu, Oct 03, 2019 at 04:22:47PM +1000, Jonathan Gray wrote:
> On Wed, Oct 02, 2019 at 03:48:27PM +0200, Jan Klemkow wrote:
> > On Tue, Oct 01, 2019 at 11:34:09AM +1000, Jonathan Gray wrote:
> > > On Tue, Oct 01, 2019 at 12:27:48AM +0200, Jan Klemkow wrote:
> > > > After updating my router to current, the systems hangs during the boot.
> > > > Maybe its caused by the "invalid EDID"?!  The System boots up normaly
> > > > and doesn't hang, if I disable inteldrm(4) in UKC.
> > > > 
> > > > Is this issue known?  Or, witch additional debug information should I
> > > > provide to help fixing this bug?
> > 
> > Hi Jonathan,
> > 
> > > Building a kernel with 'option DRMDEBUG' will give more information.
> > 
> > See the log below:
> 
> Thanks, I don't see anything obvious in that.
> 
> Can you break into ddb with a break over serial when it hangs and get
> a trace?

This also occurs with a bay trail/valleyview machine I have here.

comintr(80349000) at comintr+0x2af
intr_handler(80001fbbaa60,80348680) at intr_handler+0x6e
Xintr_ioapic_edge4_untramp(0,1d40,7b29,0,230,1d43) at 
Xintr_ioapic_edge4_untramp+0x19f
i82489_readreg(390) at i82489_readreg+0x1a
lapic_delay(500) at lapic_delay+0x82
gmbus_wait(800e2000,800,1) at gmbus_wait+0x330
gmbus_xfer_read(800e2000,80001fbbadc0,4,400) at 
gmbus_xfer_read+0x1e8
do_gmbus_xfer(800e41e8,80001fbbadb0,2,0) at do_gmbus_xfer+0x296
gmbus_xfer(800e41e8,80001fbbadb0,2) at gmbus_xfer+0x7c
drm_do_probe_ddc_edid(800e41e8,80001fbbae5f,0,1) at 
drm_do_probe_ddc_edid+0xb5
drm_get_edid(8074a800,800e41e8) at drm_get_edid+0x51
intel_hdmi_set_edid(8074a800) at intel_hdmi_set_edid+0x64
intel_hdmi_detect(8074a800,0) at intel_hdmi_detect+0x77
drm_helper_probe_detect(8074a800,0,0) at drm_helper_probe_detect+0x108
drm_helper_hpd_irq_event(800e2078) at drm_helper_hpd_irq_event+0x90
i915_hpd_poll_init_work(800e4f10) at i915_hpd_poll_init_work+0x101
taskq_thread(800dd540) at taskq_thread+0x4d
end trace frame: 0x0, count: -18

Turns out a intel_hpd_poll_init() call is missing for valleyview/cherrytrail.

Index: intel_runtime_pm.c
===
RCS file: /cvs/src/sys/dev/pci/drm/i915/intel_runtime_pm.c,v
retrieving revision 1.3
diff -u -p -r1.3 intel_runtime_pm.c
--- intel_runtime_pm.c  14 Apr 2019 10:14:52 -  1.3
+++ intel_runtime_pm.c  4 Oct 2019 04:36:27 -
@@ -1040,8 +1040,8 @@ static void vlv_display_power_well_deini
 #ifdef notyet
/* Prevent us from re-enabling polling on accident in late suspend */
if (!dev_priv->drm.dev->power.is_suspended)
-   intel_hpd_poll_init(dev_priv);
 #endif
+   intel_hpd_poll_init(dev_priv);
 }
 
 static void vlv_display_power_well_enable(struct drm_i915_private *dev_priv,



Re: system boot hang due to inteldrm(4)

2019-10-03 Thread Jonathan Gray
On Wed, Oct 02, 2019 at 03:48:27PM +0200, Jan Klemkow wrote:
> On Tue, Oct 01, 2019 at 11:34:09AM +1000, Jonathan Gray wrote:
> > On Tue, Oct 01, 2019 at 12:27:48AM +0200, Jan Klemkow wrote:
> > > After updating my router to current, the systems hangs during the boot.
> > > Maybe its caused by the "invalid EDID"?!  The System boots up normaly
> > > and doesn't hang, if I disable inteldrm(4) in UKC.
> > > 
> > > Is this issue known?  Or, witch additional debug information should I
> > > provide to help fixing this bug?
> 
> Hi Jonathan,
> 
> > Building a kernel with 'option DRMDEBUG' will give more information.
> 
> See the log below:

Thanks, I don't see anything obvious in that.

Can you break into ddb with a break over serial when it hangs and get
a trace?

Otherwise figuring out what is happening may involve of a lot of printf
calls...

> 
> > Is the machine hooked up to a kvm or monitor?
> 
> No KVM and no monitor.  Just serial access.
> 
> > What Lanner model is this?  "gbXSo" doesn't help.
> 
> Lanner LEC-7233
> 
> Thanks,
> Jan
> 
> Kernel boot messages with DRMDEBUG enabled:
> The last part seems to repeat endlessly?!
> 
> [ using 2760504 bytes of bsd ELF symbol table ]
> Copyright (c) 1982, 1986, 1989, 1991, 1993
>   The Regents of the University of California.  All rights reserved.
> Copyright (c) 1995-2019 OpenBSD. All rights reserved.  https://www.OpenBSD.org
> 
> OpenBSD 6.6-beta (GENERIC.MP) #102: Wed Oct  2 09:10:14 CEST 2019
> you...@fabien.klemkow.net:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 2024398848 (1930MB)
> avail mem = 1950064640 (1859MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xeca50 (49 entries)
> bios0: vendor American Megatrends Inc. version "5.6.5" date 01/05/2017
> bios0: Lanner Electronics gbXSo
> acpi0 at bios0: ACPI 5.0
> acpi0: sleep states S0 S4 S5
> acpi0: tables DSDT FACP APIC FPDT LPIT MCFG HPET SSDT SSDT SSDT UEFI
> acpi0: wakeup devices EHC1(S4) PXSX(S4) PXSX(S4) PXSX(S4) PXSX(S4) PWRB(S0) 
> BRCM(S0)
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Celeron(R) CPU N2807 @ 1.58GHz, 1583.69 MHz, 06-37-08
> cpu0: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN
> cpu0: 1MB 64b/line 16-way L2 cache
> tsc_timecounter_init: TSC skew=0 observed drift=0
> cpu0: smt 0, core 0, package 0
> mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
> cpu0: apic clock running at 83MHz
> cpu0: mwait min=64, max=64, C-substates=0.2.0.0.0.0.3.3, IBE
> cpu1 at mainbus0: apid 2 (application processor)
> TSC skew=0
> cpu1: Intel(R) Celeron(R) CPU N2807 @ 1.58GHz, 1583.34 MHz, 06-37-08
> cpu1: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN
> cpu1: 1MB 64b/line 16-way L2 cache
> tsc_timecounter_init: TSC skew=0 observed drift=0
> cpu1: smt 0, core 1, package 0
> ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 87 pins
> acpimcfg0 at acpi0
> acpimcfg0: addr 0xe000, bus 0-255
> acpihpet0 at acpi0: 14318179 Hz
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpiprt1 at acpi0: bus 2 (RP02)
> acpiprt2 at acpi0: bus 3 (RP03)
> acpiprt3 at acpi0: bus 4 (RP04)
> acpiprt4 at acpi0: bus 1 (RP01)
> acpiec0 at acpi0: not present
> acpicpu0 at acpi0: C3(10@1500 mwait.1@0x52), C2(10@500 mwait.1@0x51), 
> C1(1000@1 mwait.1), PSS
> acpicpu1 at acpi0: C3(10@1500 mwait.1@0x52), C2(10@500 mwait.1@0x51), 
> C1(1000@1 mwait.1), PSS
> acpipwrres0 at acpi0: PLPE
> acpipwrres1 at acpi0: PLPE
> acpipwrres2 at acpi0: USBC, resource for EHC1, OTG1
> acpipwrres3 at acpi0: CLK0, resource for CAM1
> acpipwrres4 at acpi0: CLK1, resource for CAM0, CAM2
> acpipwrres5 at acpi0: FN00, resource for FAN0
> acpitz0 at acpi0: critical temperature is 90 degC
> "INT3396" at acpi0 not configured
> acpicmos0 at acpi0
> acpipci0 at acpi0 PCI0: 0x0004 0x0011 0x0001
> "DMA0F28" at acpi0 not configured
> acpibtn0 at acpi0: PWRB
> acpibtn1 at acpi0: SLPB
> "BCM2E1A" at a

Re: system boot hang due to inteldrm(4)

2019-09-30 Thread Jonathan Gray
On Tue, Oct 01, 2019 at 12:27:48AM +0200, Jan Klemkow wrote:
> Hi,
> 
> After updating my router to current, the systems hangs during the boot.
> Maybe its caused by the "invalid EDID"?!  The System boots up normaly
> and doesn't hang, if I disable inteldrm(4) in UKC.
> 
> Is this issue known?  Or, witch additional debug information should I
> provide to help fixing this bug?

Building a kernel with 'option DRMDEBUG' will give more information.

Is the machine hooked up to a kvm or monitor?

What Lanner model is this?  "gbXSo" doesn't help.

> 
> Thanks,
> Jan
> 
> [ using 2744944 bytes of bsd ELF symbol table ]
> Copyright (c) 1982, 1986, 1989, 1991, 1993
>   The Regents of the University of California.  All rights reserved.
> Copyright (c) 1995-2019 OpenBSD. All rights reserved.  https://www.OpenBSD.org
> 
> OpenBSD 6.6-beta (GENERIC.MP) #328: Thu Sep 26 21:37:06 MDT 2019
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 2024398848 (1930MB)
> avail mem = 1950400512 (1860MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xeca50 (49 entries)
> bios0: vendor American Megatrends Inc. version "5.6.5" date 01/05/2017
> bios0: Lanner Electronics gbXSo
> acpi0 at bios0: ACPI 5.0
> acpi0: sleep states S0 S4 S5
> acpi0: tables DSDT FACP APIC FPDT LPIT MCFG HPET SSDT SSDT SSDT UEFI
> acpi0: wakeup devices EHC1(S4) PXSX(S4) PXSX(S4) PXSX(S4) PXSX(S4) PWRB(S0) 
> BRCM(S0)
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Celeron(R) CPU N2807 @ 1.58GHz, 1583.59 MHz, 06-37-08
> cpu0: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN
> cpu0: 1MB 64b/line 16-way L2 cache
> tsc_timecounter_init: TSC skew=0 observed drift=0
> cpu0: smt 0, core 0, package 0
> mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
> cpu0: apic clock running at 83MHz
> cpu0: mwait min=64, max=64, C-substates=0.2.0.0.0.0.3.3, IBE
> cpu1 at mainbus0: apid 2 (application processor)
> TSC skew=0
> cpu1: Intel(R) Celeron(R) CPU N2807 @ 1.58GHz, 1583.34 MHz, 06-37-08
> cpu1: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN
> cpu1: 1MB 64b/line 16-way L2 cache
> tsc_timecounter_init: TSC skew=0 observed drift=0
> cpu1: smt 0, core 1, package 0
> ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 87 pins
> acpimcfg0 at acpi0
> acpimcfg0: addr 0xe000, bus 0-255
> acpihpet0 at acpi0: 14318179 Hz
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpiprt1 at acpi0: bus 2 (RP02)
> acpiprt2 at acpi0: bus 3 (RP03)
> acpiprt3 at acpi0: bus 4 (RP04)
> acpiprt4 at acpi0: bus 1 (RP01)
> acpiec0 at acpi0: not present
> acpicpu0 at acpi0: C3(10@1500 mwait.1@0x52), C2(10@500 mwait.1@0x51), 
> C1(1000@1 mwait.1), PSS
> acpicpu1 at acpi0: C3(10@1500 mwait.1@0x52), C2(10@500 mwait.1@0x51), 
> C1(1000@1 mwait.1), PSS
> acpipwrres0 at acpi0: PLPE
> acpipwrres1 at acpi0: PLPE
> acpipwrres2 at acpi0: USBC, resource for EHC1, OTG1
> acpipwrres3 at acpi0: CLK0, resource for CAM1
> acpipwrres4 at acpi0: CLK1, resource for CAM0, CAM2
> acpipwrres5 at acpi0: FN00, resource for FAN0
> acpitz0 at acpi0: critical temperature is 90 degC
> "INT3396" at acpi0 not configured
> acpicmos0 at acpi0
> acpipci0 at acpi0 PCI0: 0x0004 0x0011 0x0001
> "DMA0F28" at acpi0 not configured
> acpibtn0 at acpi0: PWRB
> acpibtn1 at acpi0: SLPB
> "BCM2E1A" at acpi0 not configured
> "BCM4752" at acpi0 not configured
> "AUTH2750" at acpi0 not configured
> "INTCF0B" at acpi0 not configured
> "INTCF1A" at acpi0 not configured
> "INTCF1C" at acpi0 not configured
> "SMO91D0" at acpi0 not configured
> "MSFT0002" at acpi0 not configured
> "INT33BD" at acpi0 not configured
> "PNP0C0B" at acpi0 not configured
> acpivideo0 at acpi0: GFX0
> acpivout0 at acpivideo0: DD1F
> cpu0: using VERW MDS workaround
> cpu0: Enhanced SpeedStep 1583 MHz: speeds: 1577, 1494, 1411, 1328, 1245, 
> 1162, 1079, 996, 913, 830, 747, 664, 581, 498 MHz
> pci0 at mainbus0 bus 0
> pchb0 at pci0 dev 0 function 0 "Intel Bay Trail Host" rev 0x0e
> inteldrm0 at pci0 dev 2 function 0 "Intel Bay Trail Video" rev 0x0e
> drm0 at inteldrm0
> inteldrm0: msi
> ahci0 at pci0 dev 19 function 0 "Intel Bay Trail AHCI" rev 0x0e: msi, AHCI 1.3
> ahci0: port 0: 3.0Gb/s
> scsibus1 at ahci0: 32 targets
> sd0 at scsibus1 targ 0 lun 0:  
> naa.524693f2ca20f959
> sd0: 7641MB, 512 

Re: recognize eMMC/SDXC Intel 100 Series found in Tuxedo InfinityBook 14 v2

2019-08-22 Thread Jonathan Gray
On Thu, Aug 22, 2019 at 08:23:05PM +0200, Felix Kronlage-Dammers wrote:
> Hi,
> 
> couple devices found in the Tuxedo InfinityBook 14 v2.
> 
> felix

thanks, committed

> 
> 
> Index: sys/dev/pci/pcidevs
> ===
> RCS file: /cvs/src/sys/dev/pci/pcidevs,v
> retrieving revision 1.1894
> diff -u -p -u -r1.1894 pcidevs
> --- sys/dev/pci/pcidevs   13 Aug 2019 03:17:11 -  1.1894
> +++ sys/dev/pci/pcidevs   22 Aug 2019 18:17:44 -
> @@ -5343,6 +5343,8 @@ product INTEL 100SERIES_LP_UART_1   0x9d27
>  product INTEL 100SERIES_LP_UART_20x9d28  100 Series UART
>  product INTEL 100SERIES_LP_SPI_2 0x9d29  100 Series SPI
>  product INTEL 100SERIES_LP_SPI_3 0x9d2a  100 Series SPI
> +product INTEL 100SERIES_LP_EMMC  0x9d2b  100 Series eMMC
> +product INTEL 100SERIES_LP_SDXC  0x9d2d  100 Series SDXC
>  product INTEL 100SERIES_LP_XHCI  0x9d2f  100 Series xHCI
>  product INTEL 100SERIES_LP_THERM 0x9d31  100 Series Thermal
>  product INTEL 100SERIES_LP_ISH   0x9d35  100 Series ISH
> 
> -- 
> GPG/PGP:   7A0B612C /  5F4D 9B06 C240 3250 35BF  66ED 1AD3 A9B8 7A0B 612C
> https://hazardous.org/  -  fe...@kronlage.de  -  fkr@irc - @felixkronlage
> 



Backport Comet Lake support for Mesa

2019-08-22 Thread Jonathan Gray
Backport Comet Lake support for Mesa.

commit 82f6a746e8b47fb6e3f96d7f5f69973f50eec9ca
Author: Anuj Phogat 
Date:   Fri Mar 29 13:13:01 2019 -0700

intel: Add support for Comet Lake

Signed-off-by: Anuj Phogat 
Reviewed-by: Jordan Justen 

Index: include/pci_ids/i965_pci_ids.h
===
RCS file: /cvs/xenocara/lib/mesa/include/pci_ids/i965_pci_ids.h,v
retrieving revision 1.7
diff -u -p -r1.7 i965_pci_ids.h
--- include/pci_ids/i965_pci_ids.h  19 Feb 2019 04:24:00 -  1.7
+++ include/pci_ids/i965_pci_ids.h  22 Aug 2019 05:44:48 -
@@ -189,6 +189,24 @@ CHIPSET(0x3EA4, cfl_gt1, "Intel(R) HD Gr
 CHIPSET(0x3EA0, cfl_gt2, "Intel(R) HD Graphics (Whiskey Lake 3x8 GT2)")
 CHIPSET(0x3EA3, cfl_gt2, "Intel(R) HD Graphics (Whiskey Lake 3x8 GT2)")
 CHIPSET(0x3EA2, cfl_gt3, "Intel(R) HD Graphics (Whiskey Lake 3x8 GT3)")
+CHIPSET(0x9B21, cfl_gt1, "Intel(R) HD Graphics (Comet Lake 2x6 GT1)")
+CHIPSET(0x9BA0, cfl_gt1, "Intel(R) HD Graphics (Comet Lake 2x6 GT1)")
+CHIPSET(0x9BA2, cfl_gt1, "Intel(R) HD Graphics (Comet Lake 2x6 GT1)")
+CHIPSET(0x9BA4, cfl_gt1, "Intel(R) HD Graphics (Comet Lake 2x6 GT1)")
+CHIPSET(0x9BA5, cfl_gt1, "Intel(R) HD Graphics (Comet Lake 2x6 GT1)")
+CHIPSET(0x9BA8, cfl_gt1, "Intel(R) HD Graphics (Comet Lake 2x6 GT1)")
+CHIPSET(0x9BAA, cfl_gt1, "Intel(R) HD Graphics (Comet Lake 2x6 GT1)")
+CHIPSET(0x9BAB, cfl_gt1, "Intel(R) HD Graphics (Comet Lake 2x6 GT1)")
+CHIPSET(0x9BAC, cfl_gt1, "Intel(R) HD Graphics (Comet Lake 2x6 GT1)")
+CHIPSET(0x9B41, cfl_gt2, "Intel(R) HD Graphics (Comet Lake 3x8 GT2)")
+CHIPSET(0x9BC0, cfl_gt2, "Intel(R) HD Graphics (Comet Lake 3x8 GT2)")
+CHIPSET(0x9BC2, cfl_gt2, "Intel(R) HD Graphics (Comet Lake 3x8 GT2)")
+CHIPSET(0x9BC4, cfl_gt2, "Intel(R) HD Graphics (Comet Lake 3x8 GT2)")
+CHIPSET(0x9BC5, cfl_gt2, "Intel(R) HD Graphics (Comet Lake 3x8 GT2)")
+CHIPSET(0x9BC8, cfl_gt2, "Intel(R) HD Graphics (Comet Lake 3x8 GT2)")
+CHIPSET(0x9BCA, cfl_gt2, "Intel(R) HD Graphics (Comet Lake 3x8 GT2)")
+CHIPSET(0x9BCB, cfl_gt2, "Intel(R) HD Graphics (Comet Lake 3x8 GT2)")
+CHIPSET(0x9BCC, cfl_gt2, "Intel(R) HD Graphics (Comet Lake 3x8 GT2)")
 CHIPSET(0x5A49, cnl_2x8, "Intel(R) HD Graphics (Cannonlake 2x8 GT0.5)")
 CHIPSET(0x5A4A, cnl_2x8, "Intel(R) HD Graphics (Cannonlake 2x8 GT0.5)")
 CHIPSET(0x5A41, cnl_3x8, "Intel(R) HD Graphics (Cannonlake 3x8 GT1)")
Index: src/intel/dev/gen_device_info.c
===
RCS file: /cvs/xenocara/lib/mesa/src/intel/dev/gen_device_info.c,v
retrieving revision 1.1.1.3
diff -u -p -r1.1.1.3 gen_device_info.c
--- src/intel/dev/gen_device_info.c 23 May 2019 04:44:09 -  1.1.1.3
+++ src/intel/dev/gen_device_info.c 22 Aug 2019 05:44:48 -
@@ -61,6 +61,7 @@ gen_device_name_to_pci_device_id(const c
   { "glk", 0x3185 },
   { "cfl", 0x3E9B },
   { "whl", 0x3EA1 },
+  { "cml", 0x9b41 },
   { "cnl", 0x5a52 },
   { "icl", 0x8a52 },
};



Backport Comet Lake support for inteldrm from mainline linux

2019-08-22 Thread Jonathan Gray
Backport Comet Lake support for inteldrm from mainline linux.

commit a7b4deeb02b978bc59808cb13c93ba84f01023a4
Author: Anusha Srivatsa 
Date:   Mon Mar 18 13:01:32 2019 -0700

drm/i915/cml: Add CML PCI IDS

Comet Lake is a Intel Processor containing Gen9
Intel HD Graphics. This patch adds the initial set of
PCI IDs. Comet Lake comes off of Coffee Lake - adding
the IDs to Coffee Lake ID list.

More support and features will be in the patches that follow.

v2: Split IDs according to GT. (Rodrigo)

v3: Update IDs.

Cc: Rodrigo Vivi 
Cc: Lucas De Marchi 
Signed-off-by: Anusha Srivatsa 
Reviewed-by: Rodrigo Vivi 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20190318200133.9666-1-anusha.sriva...@intel.com

commit 729ae330a0f2e270db2ca70c06a83d0aa2776288
Author: Anusha Srivatsa 
Date:   Mon Mar 18 13:01:33 2019 -0700

drm/i915/cml: Introduce Comet Lake PCH

Comet Lake PCH is based off of Cannon Point(CNP).
Add PCI ID for Comet Lake PCH.

v2: Code cleanup (DK)

v3: Comment cleanup (Jani)

Cc: Jani Nikula 
Cc: Dhinakaran Pandiyan 
Cc: Rodrigo Vivi 
Signed-off-by: Anusha Srivatsa 
Reviewed-by: Rodrigo Vivi 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20190318200133.9666-2-anusha.sriva...@intel.com

diff --git sys/dev/pci/drm/i915/i915_devlist.h 
sys/dev/pci/drm/i915/i915_devlist.h
index 5388608848d..8dc87d6fdc0 100644
--- sys/dev/pci/drm/i915/i915_devlist.h
+++ sys/dev/pci/drm/i915/i915_devlist.h
@@ -212,6 +212,24 @@ static const struct pci_matchid i915_devices[] = {
{ 0x8086, 0x3ea3 },
{ 0x8086, 0x87ca },
{ 0x8086, 0x3ea2 },
+   { 0x8086, 0x9b21 },
+   { 0x8086, 0x9baa },
+   { 0x8086, 0x9bab },
+   { 0x8086, 0x9bac },
+   { 0x8086, 0x9ba0 },
+   { 0x8086, 0x9ba5 },
+   { 0x8086, 0x9ba8 },
+   { 0x8086, 0x9ba4 },
+   { 0x8086, 0x9ba2 },
+   { 0x8086, 0x9b41 },
+   { 0x8086, 0x9bca },
+   { 0x8086, 0x9bcb },
+   { 0x8086, 0x9bcc },
+   { 0x8086, 0x9bc0 },
+   { 0x8086, 0x9bc5 },
+   { 0x8086, 0x9bc8 },
+   { 0x8086, 0x9bc4 },
+   { 0x8086, 0x9bc2 },
{ 0x8086, 0x5a51 },
{ 0x8086, 0x5a59 },
{ 0x8086, 0x5a41 },
diff --git sys/dev/pci/drm/i915/i915_drv.c sys/dev/pci/drm/i915/i915_drv.c
index f0cdd46a147..c41308b3e33 100644
--- sys/dev/pci/drm/i915/i915_drv.c
+++ sys/dev/pci/drm/i915/i915_drv.c
@@ -195,6 +195,11 @@ intel_pch_type(const struct drm_i915_private *dev_priv, 
unsigned short id)
DRM_DEBUG_KMS("Found Cannon Lake LP PCH (CNP-LP)\n");
WARN_ON(!IS_CANNONLAKE(dev_priv) && !IS_COFFEELAKE(dev_priv));
return PCH_CNP;
+   case INTEL_PCH_CMP_DEVICE_ID_TYPE:
+   DRM_DEBUG_KMS("Found Comet Lake PCH (CMP)\n");
+   WARN_ON(!IS_COFFEELAKE(dev_priv));
+   /* CometPoint is CNP Compatible */
+   return PCH_CNP;
case INTEL_PCH_ICP_DEVICE_ID_TYPE:
DRM_DEBUG_KMS("Found Ice Lake PCH\n");
WARN_ON(!IS_ICELAKE(dev_priv));
diff --git sys/dev/pci/drm/i915/i915_drv.h sys/dev/pci/drm/i915/i915_drv.h
index 9c8ba12b5fa..5d1fd179a4b 100644
--- sys/dev/pci/drm/i915/i915_drv.h
+++ sys/dev/pci/drm/i915/i915_drv.h
@@ -735,7 +735,7 @@ enum intel_pch {
PCH_LPT,/* Lynxpoint/Wildcatpoint PCH */
PCH_SPT,/* Sunrisepoint PCH */
PCH_KBP,/* Kaby Lake PCH */
-   PCH_CNP,/* Cannon Lake PCH */
+   PCH_CNP,/* Cannon/Comet Lake PCH */
PCH_ICP,/* Ice Lake PCH */
PCH_NOP,/* PCH without south display */
 };
@@ -2788,6 +2788,7 @@ intel_info(const struct drm_i915_private *dev_priv)
 #define INTEL_PCH_KBP_DEVICE_ID_TYPE   0xA280
 #define INTEL_PCH_CNP_DEVICE_ID_TYPE   0xA300
 #define INTEL_PCH_CNP_LP_DEVICE_ID_TYPE0x9D80
+#define INTEL_PCH_CMP_DEVICE_ID_TYPE   0x0280
 #define INTEL_PCH_ICP_DEVICE_ID_TYPE   0x3480
 #define INTEL_PCH_P2X_DEVICE_ID_TYPE   0x7100
 #define INTEL_PCH_P3X_DEVICE_ID_TYPE   0x7000
diff --git sys/dev/pci/drm/i915/i915_pci.c sys/dev/pci/drm/i915/i915_pci.c
index 879c4932028..7bad4686dfb 100644
--- sys/dev/pci/drm/i915/i915_pci.c
+++ sys/dev/pci/drm/i915/i915_pci.c
@@ -667,6 +667,8 @@ const struct drm_pcidev pciidlist[] = {
INTEL_WHL_U_GT2_IDS(_coffeelake_gt2_info),
INTEL_AML_CFL_GT2_IDS(_coffeelake_gt2_info),
INTEL_WHL_U_GT3_IDS(_coffeelake_gt3_info),
+   INTEL_CML_GT1_IDS(_coffeelake_gt1_info),
+   INTEL_CML_GT2_IDS(_coffeelake_gt2_info),
INTEL_CNL_IDS(_cannonlake_info),
INTEL_ICL_11_IDS(_icelake_11_info),
{0, 0, 0}
diff --git sys/dev/pci/drm/include/drm/i915_pciids.h 
sys/dev/pci/drm/include/drm/i915_pciids.h
index d2fad7b0fcf..ecbde04a68e 100644
--- sys/dev/pci/drm/include/drm/i915_pciids.h
+++ 

Re: amr64 acpipci(4)

2019-08-20 Thread Jonathan Gray
On Tue, Aug 20, 2019 at 08:49:19PM +0200, Mark Kettenis wrote:
> The Ampere/Lenvo HR330A firmware doesn't set the _TTP bit on the IO
> window of its host bridges.  It really should since these bridges
> translate memory transactions into io transactions.  But it isn't the
> only one that doesn't get this aspect right.  So it is probably best
> to ignore _TTP and just assume it converts memory transactions into io
> transactions.
> 
> ok?

ok jsg@

> 
> 
> Index: arch/arm64/dev/acpipci.c
> ===
> RCS file: /cvs/src/sys/arch/arm64/dev/acpipci.c,v
> retrieving revision 1.12
> diff -u -p -r1.12 acpipci.c
> --- arch/arm64/dev/acpipci.c  30 Jul 2019 21:44:15 -  1.12
> +++ arch/arm64/dev/acpipci.c  20 Aug 2019 18:43:15 -
> @@ -253,8 +253,10 @@ acpipci_parse_resources(int crsidx, unio
>   sc->sc_mem_trans = at;
>   break;
>   case LR_TYPE_IO:
> - if ((tflags & LR_IO_TTP) == 0)
> - return 0;
> + /*
> +  * Don't check _TTP as various firmwares don't set it,
> +  * even though they should!!
> +  */
>   extent_free(sc->sc_ioex, min, len, EX_WAITOK);
>   at = malloc(sizeof(struct acpipci_trans), M_DEVBUF, M_WAITOK);
>   at->at_iot = sc->sc_iot;
> 



update to tradcpp 0.5.3

2019-08-20 Thread Jonathan Gray
Update tradcpp to 0.5.3.  We already had the fixed mdoc.

release 0.5.3 (20190121)
   - Fix markup typo in the man page.
   - Abort on line numbering or column numbering overflow. Line
 numbers are limited to values that fit in "unsigned int". Also
 reject input lines longer than 2^32-1 characters. It seems
 reasonable to presume that any input that violates these
 constraints is someone screwing around and not a serious attempt
 to compile or preprocess anything useful. Done in response to
 n2129, but without getting into any of the silliness found there.
   - Recognize __ia64__ for IA64 builds.
   - Recognize __aarch64__ for 64-bit ARM builds, as sent in by
 various people.
   - Recognize __riscv__ and __riscv64__ for risc-v builds.

Index: config.h
===
RCS file: /cvs/src/libexec/tradcpp/config.h,v
retrieving revision 1.1
diff -u -p -r1.1 config.h
--- config.h30 Jul 2014 16:33:11 -  1.1
+++ config.h21 Aug 2019 04:02:28 -
@@ -124,6 +124,22 @@
 #define CONFIG_CPU "__ppc64__"
 #elif defined(__ARM__)
 #define CONFIG_CPU "__ARM__"
+#elif defined(__AARCH64__)
+#define CONFIG_CPU "__AARCH64__"
+#elif defined(__aarch64__)
+#define CONFIG_CPU "__aarch64__"
+#elif defined(__RISCV__)
+#define CONFIG_CPU "__RISCV__"
+#elif defined(__riscv__)
+#define CONFIG_CPU "__riscv__"
+#elif defined(__RISCV64__)
+#define CONFIG_CPU "__RISCV64__"
+#elif defined(__riscv64__)
+#define CONFIG_CPU "__riscv64__"
+#elif defined(__riscv64)
+#define CONFIG_CPU "__riscv64"
+#elif defined(__ia64__)
+#define CONFIG_CPU "__ia64__"
 #else
 /* let it go */
 #endif
Index: directive.c
===
RCS file: /cvs/src/libexec/tradcpp/directive.c,v
retrieving revision 1.2
diff -u -p -r1.2 directive.c
--- directive.c 2 Sep 2018 08:28:05 -   1.2
+++ directive.c 21 Aug 2019 04:02:28 -
@@ -114,7 +114,7 @@ oneword(const char *what, struct place *
 
pos = strcspn(line, ws);
if (line[pos] != '\0') {
-   p2->column += pos;
+   place_addcolumns(p2, pos);
complain(p2, "Garbage after %s argument", what);
complain_fail();
line[pos] = '\0';
@@ -348,13 +348,13 @@ d_define(struct lineplace *lp, struct pl
argpos = pos;
pos = pos + strcspn(line+pos, "()");
if (line[pos] == '(') {
-   p2->column += pos;
+   place_addcolumns(p2, pos);
complain(p2, "Left parenthesis in macro parameters");
complain_fail();
return;
}
if (line[pos] != ')') {
-   p2->column += pos;
+   place_addcolumns(p2, pos);
complain(p2, "Unclosed macro parameter list");
complain_fail();
return;
@@ -378,10 +378,10 @@ d_define(struct lineplace *lp, struct pl
pos += strspn(line+pos, ws);
 
p3 = *p2;
-   p3.column += argpos;
+   place_addcolumns(, argpos);
 
p4 = *p2;
-   p4.column += pos;
+   place_addcolumns(, pos);
 
if (argpos) {
debuglog(>current, "Defining %s()", line);
@@ -490,7 +490,8 @@ d_line(struct lineplace *lp, struct plac
errno = 0;
val = strtoul(text, , 10);
if (errno) {
-   complain(>current, "No line number in #line directive");
+   complain(>current,
+"Invalid line number in #line directive");
goto fail;
}
 #if UINT_MAX < ULONG_MAX
@@ -502,7 +503,7 @@ d_line(struct lineplace *lp, struct plac
 #endif
moretext += strspn(moretext, ws);
moretextlen = strlen(moretext);
-   lp->current.column += (moretext - text);
+   place_addcolumns(>current, moretext - text);
 
if (moretextlen > 2 &&
moretext[0] == '"' && moretext[moretextlen-1] == '"') {
@@ -610,7 +611,7 @@ directive_gotdirective(struct lineplace 
return;
}
skip = len + strspn(line+len, ws);
-   p2.column += skip;
+   place_addcolumns(, skip);
line += skip;
 
len = strlen(line);
@@ -667,10 +668,10 @@ directive_scancomments(const struct line
pos++;
}
if (line[pos] == '\n') {
-   p2.line++;
+   place_addlines(, 1);
p2.column = 0;
} else {
-   p2.column++;
+   place_addcolumns(, 1);
}
}
 
@@ -692,13 +693,13 @@ directive_gotline(struct lineplace *lp, 
if (len > 0 && line[0] == '#') {
skip = 1 + 

Re: drm acpi diff

2019-08-16 Thread Jonathan Gray
On Fri, Aug 16, 2019 at 10:21:33PM +0200, Mark Kettenis wrote:
> The diff below provides a minimal implementation of some of the Linux
> ACPI iterfaces.  Enough to allow us to compile the ACPI code for
> radeon(4) and amdgpu(4).  With this diff the brightness keys on my HP
> laptop with:
>=20
> cpu0: AMD A4-4355M APU with Radeon(tm) HD Graphics, 1897.56 MHz, 15-10-01
> ...
> radeondrm0 at pci0 dev 1 function 0 "ATI Radeon HD 7400G" rev 0x00
>=20
> now work.  I'd like to see some more tests, especially on laptops with
> amdgpu(4).  Diff has some debug printing enabled.  Feel free to share
> the dmesg output with me.

In linux these files are only built with CONFIG_ACPI
so we should probably modify them to put that in the files themselves

=2E/amd/amdgpu/Makefile:amdgpu-$(CONFIG_ACPI) +=3D amdgpu_acpi.o
=2E/i915/Makefile:i915-$(CONFIG_ACPI) +=3D intel_acpi.o intel_o=
pregion.o
=2E/radeon/Makefile:radeon-$(CONFIG_ACPI) +=3D radeon_acpi.o

This diff doesn't build on at least arm64 and sparc64

cc -g -Werror -Wall -Wimplicit-function-declaration  -Wno-uninitialized -Wn=
o-pointer-sign  -Wno-constant-conversion -Wno-address-of-packed-member  -Wf=
rame-larger-than=3D2047 -march=3Darmv8-a+nofp+nosimd  -fno-omit-frame-point=
er -mno-omit-leaf-frame-pointer  -ffixed-x18 -ffreestanding -fno-pie -O2 -p=
ipe -nostdinc -I/usr/src/sys -I/sys/arch/arm64/compile/GENERIC.MP/obj -I/us=
r/src/sys/arch  -I/usr/src/sys/dev/pci/drm/include  -I/usr/src/sys/dev/pci/=
drm/include/uapi -DDDB -DDIAGNOSTIC -DKTRACE -DACCOUNTING -DKMEMSTATS -DPTR=
ACE -DPOOL_DEBUG -DCRYPTO -DSYSVMSG -DSYSVSEM -DSYSVSHM -DUVM_SWAP_ENCRYPT =
-DFFS -DFFS2 -DFFS_SOFTUPDATES -DUFS_DIRHASH -DQUOTA -DEXT2FS -DMFS -DNFSCL=
IENT -DNFSSERVER -DCD9660 -DUDF -DMSDOSFS -DFIFO -DFUSE -DSOCKET_SPLICE -DT=
CP_ECN -DTCP_SIGNATURE -DINET6 -DIPSEC -DPPP_BSDCOMP -DPPP_DEFLATE -DPIPEX =
-DMROUTING -DMPLS -DBOOT_CONFIG -DTIMEZONE=3D"0" -DDST=3D"0" -DPCIVERBOSE -=
DUSER_PCICONF -DUSBVERBOSE -DWSDISPLAY_COMPAT_USL -DWSDISPLAY_COMPAT_RAWKBD=
 -DWSDISPLAY_DEFAULTSCREENS=3D"6" -DONEWIREVERBOSE -DMULTIPROCESSOR -DMAXUS=
ERS=3D80 -D_KERNEL -D__arm64__ -MD -MP  -c /usr/src/sys/dev/pci/drm/radeon/=
radeon_bios.c
/usr/src/sys/dev/pci/drm/radeon/radeon_bios.c:331:17: error: implicit decla=
ration of function
  'pci_get_class' is invalid in C99 [-Werror,-Wimplicit-function-declar=
ation]
while ((pdev =3D pci_get_class(PCI_CLASS_DISPLAY_VGA << 8, pdev)) !=
=3D NULL) {
   ^
/usr/src/sys/dev/pci/drm/radeon/radeon_bios.c:331:31: error: use of undecla=
red identifier
  'PCI_CLASS_DISPLAY_VGA'
while ((pdev =3D pci_get_class(PCI_CLASS_DISPLAY_VGA << 8, pdev)) !=
=3D NULL) {
 ^
/usr/src/sys/dev/pci/drm/radeon/radeon_bios.c:344:32: error: use of undecla=
red identifier
  'PCI_CLASS_DISPLAY_OTHER'
while ((pdev =3D pci_get_class(PCI_CLASS_DISPLAY_OTHER << 8=
, pdev)) !=3D NULL) {
 ^
3 errors generated.
*** Error 1 in /sys/arch/arm64/compile/GENERIC.MP (Makefile:863 'radeon_bio=
s.o')

cc -g -Werror -Wall -Wimplicit-function-declaration  -Wno-uninitialized -Wn=
o-pointer-sign  -Wframe-larger-than=3D2047 -Wa,-Av9b, -mno-fpu -ffreestandi=
ng -fno-pie -O2 -pipe -nostdinc -I/sys -I/sys/arch/sparc64/compile/GENERIC/=
obj -I/sys/arch  -I/sys/dev/pci/drm/include  -I/sys/dev/pci/drm/include/uap=
i -DDDB -DDIAGNOSTIC -DKTRACE -DACCOUNTING -DKMEMSTATS -DPTRACE -DPOOL_DEBU=
G -DCRYPTO -DSYSVMSG -DSYSVSEM -DSYSVSHM -DUVM_SWAP_ENCRYPT -DFFS -DFFS2 -D=
FFS_SOFTUPDATES -DUFS_DIRHASH -DQUOTA -DEXT2FS -DMFS -DNFSCLIENT -DNFSSERVE=
R -DCD9660 -DUDF -DMSDOSFS -DFIFO -DFUSE -DSOCKET_SPLICE -DTCP_ECN -DTCP_SI=
GNATURE -DINET6 -DIPSEC -DPPP_BSDCOMP -DPPP_DEFLATE -DPIPEX -DMROUTING -DMP=
LS -DBOOT_CONFIG -DSUN4US -DSUN4V -DPCIVERBOSE -DUSER_PCICONF -DAPERTURE -D=
USBVERBOSE -DWSEMUL_SUN -DWSEMUL_NO_VT100 -DWSEMUL_DUMB -DWSDISPLAY_COMPAT_=
RAWKBD -DONEWIREVERBOSE -DMAXUSERS=3D64 -D_KERNEL -MD -MP  -c /sys/dev/pci/=
drm/radeon/radeon_acpi.c
cc1: warnings being treated as errors
In file included from /sys/arch/sparc64/compile/GENERIC/obj/machine/bus.h:3=
38,
 from /sys/dev/pci/pcivar.h:48,
 from /sys/dev/pci/drm/include/linux/pci.h:23,
 from /sys/dev/pci/drm/radeon/radeon_acpi.c:25:
/sys/arch/sparc64/sparc64/busop.h: In function 'bus_space_read_2':
/sys/arch/sparc64/sparc64/busop.h:72: warning: implicit declaration of func=
tion 'lduha'
/sys/arch/sparc64/sparc64/busop.h: In function 'bus_space_write_2':
/sys/arch/sparc64/sparc64/busop.h:93: warning: implicit declaration of func=
tion 'stha'
/sys/arch/sparc64/sparc64/busop.h: In function 'bus_space_read_4':
/sys/arch/sparc64/sparc64/busop.h:135: warning: implicit declaration of fun=
ction 'lduwa'
/sys/arch/sparc64/sparc64/busop.h: In function 'bus_space_write_4':
/sys/arch/sparc64/sparc64/busop.h:156: warning: implicit declaration of fun=
ction 'stwa'

Re: fix: NULL dereference in bios(4)

2019-07-23 Thread Jonathan Gray
On Mon, Jul 22, 2019 at 10:03:38AM +0200, Jan Klemkow wrote:
> On Sat, Jul 20, 2019 at 07:16:05PM +1000, Jonathan Gray wrote:
> > On Fri, Jul 19, 2019 at 02:15:03PM +0200, Jan Klemkow wrote:
> > > On Fri, Jul 19, 2019 at 09:13:38PM +1000, Jonathan Gray wrote:
> > > > On Fri, Jul 19, 2019 at 01:07:34PM +0200, Jan Klemkow wrote:
> > > > > fixstring() can return NULL and it does on one of my machines.
> > > > > Here is s fix that checks for NULL and return an empty string.
> > > > > 
> > > > > ok?
> > > > 
> > > > If it returns NULL shouldn't the strlcpy and printf both be skipped?
> > > 
> > > I was unsure about this.
> > > 
> > > > You've also not included the i386 portion of this.
> > > 
> > > I missed that.
> > > 
> > > The diff below addresses all issues.
> > > 
> > > ok?
> > 
> > What argument does fixstring have in this case?
> 
> Ten spaces (10x 0x20).
> 
> > Does you dmesg not include a date in the 'bios0' line?
> 
> no.
> 
> > I was considering making this a pointer/dynamically allocated so it can
> > be NULL.  If there is no valid date it should probably be NULL.

how about this?

Index: amd64/amd64/bios.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/bios.c,v
retrieving revision 1.38
diff -u -p -r1.38 bios.c
--- amd64/amd64/bios.c  15 Jul 2019 00:35:10 -  1.38
+++ amd64/amd64/bios.c  23 Jul 2019 12:00:27 -
@@ -92,6 +92,7 @@ bios_attach(struct device *parent, struc
u_int8_t *p;
int smbiosrev = 0;
struct smbhdr *hdr = NULL;
+   char *sminfop;
 
if (bios_efiinfo != NULL && bios_efiinfo->config_smbios != 0)
hdr = smbios_find(PMAP_DIRECT_MAP(
@@ -144,9 +145,13 @@ bios_attach(struct device *parent, struc
fixstring(scratch));
if ((smbios_get_string(, sb->release,
scratch, sizeof(scratch))) != NULL) {
-   strlcpy(smbios_bios_date, fixstring(scratch),
-   sizeof(smbios_bios_date));
-   printf(" date %s", fixstring(scratch));
+   sminfop = fixstring(scratch);
+   if (sminfop != NULL) {
+   strlcpy(smbios_bios_date,
+   sminfop,
+   sizeof(smbios_bios_date));
+   printf(" date %s", sminfop);
+   }
}
}
 
Index: i386/i386/bios.c
===
RCS file: /cvs/src/sys/arch/i386/i386/bios.c,v
retrieving revision 1.121
diff -u -p -r1.121 bios.c
--- i386/i386/bios.c15 Jul 2019 00:35:10 -  1.121
+++ i386/i386/bios.c23 Jul 2019 12:00:51 -
@@ -245,6 +245,7 @@ biosattach(struct device *parent, struct
for (va = ISA_HOLE_VADDR(SMBIOS_START);
va < (u_int8_t *)ISA_HOLE_VADDR(SMBIOS_END); va+= 16) {
struct smbhdr *sh = (struct smbhdr *)va;
+   char *sminfop;
u_int8_t chksum;
vaddr_t eva;
paddr_t pa, end;
@@ -308,10 +309,13 @@ biosattach(struct device *parent, struct
fixstring(scratch));
if ((smbios_get_string(, sb->release,
scratch, sizeof(scratch))) != NULL) {
-   strlcpy(smbios_bios_date,
-   fixstring(scratch),
-   sizeof(smbios_bios_date));
-   printf(" date %s", fixstring(scratch));
+   sminfop = fixstring(scratch);
+   if (sminfop != NULL) {
+   strlcpy(smbios_bios_date,
+   sminfop,
+   sizeof(smbios_bios_date));
+   printf(" date %s", sminfop);
+   }
}
}
smbios_info(sc->sc_dev.dv_xname);



Re: fix: NULL dereference in bios(4)

2019-07-20 Thread Jonathan Gray
On Fri, Jul 19, 2019 at 02:15:03PM +0200, Jan Klemkow wrote:
> On Fri, Jul 19, 2019 at 09:13:38PM +1000, Jonathan Gray wrote:
> > On Fri, Jul 19, 2019 at 01:07:34PM +0200, Jan Klemkow wrote:
> > > Hi,
> > > 
> > > fixstring() can return NULL and it does on one of my machines.
> > > Here is s fix that checks for NULL and return an empty string.
> > > 
> > > ok?
> > 
> > If it returns NULL shouldn't the strlcpy and printf both be skipped?
> 
> I was unsure about this.
> 
> > You've also not included the i386 portion of this.
> 
> I missed that.
> 
> The diff below addresses all issues.
> 
> ok?

What argument does fixstring have in this case?

Does you dmesg not include a date in the 'bios0' line?

I was considering making this a pointer/dynamically allocated so it can
be NULL.  If there is no valid date it should probably be NULL.

> 
> Thanks,
> Jan
> 
> Index: arch/amd64/amd64/bios.c
> ===
> RCS file: /cvs/src/sys/arch/amd64/amd64/bios.c,v
> retrieving revision 1.38
> diff -u -p -r1.38 bios.c
> --- arch/amd64/amd64/bios.c   15 Jul 2019 00:35:10 -  1.38
> +++ arch/amd64/amd64/bios.c   19 Jul 2019 11:45:11 -
> @@ -144,9 +144,11 @@ bios_attach(struct device *parent, struc
>   fixstring(scratch));
>   if ((smbios_get_string(, sb->release,
>   scratch, sizeof(scratch))) != NULL) {
> - strlcpy(smbios_bios_date, fixstring(scratch),
> + char *s = fixstring(scratch) == NULL ? "" :
> + fixstring(scratch);
> + strlcpy(smbios_bios_date, s,
>   sizeof(smbios_bios_date));
> - printf(" date %s", fixstring(scratch));
> + printf(" date %s", s);
>   }
>   }
>  
> Index: arch/i386/i386/bios.c
> ===
> RCS file: /cvs/src/sys/arch/i386/i386/bios.c,v
> retrieving revision 1.121
> diff -u -p -r1.121 bios.c
> --- arch/i386/i386/bios.c 15 Jul 2019 00:35:10 -  1.121
> +++ arch/i386/i386/bios.c 19 Jul 2019 11:58:57 -
> @@ -308,10 +308,11 @@ biosattach(struct device *parent, struct
>   fixstring(scratch));
>   if ((smbios_get_string(, sb->release,
>   scratch, sizeof(scratch))) != NULL) {
> - strlcpy(smbios_bios_date,
> - fixstring(scratch),
> + char *s = fixstring(scratch) == NULL ?
> + "" : fixstring(scratch);
> + strlcpy(smbios_bios_date, s,
>   sizeof(smbios_bios_date));
> - printf(" date %s", fixstring(scratch));
> + printf(" date %s", s);
>   }
>   }
>   smbios_info(sc->sc_dev.dv_xname);
> 



  1   2   3   4   5   6   7   >