svn commit: r360289 - in head/sys/fs: nfs nfsclient nfsserver

[Rick Macklem]

Author: rmacklem
Date: Sat Apr 25 02:18:59 2020
New Revision: 360289
URL: https://svnweb.freebsd.org/changeset/base/360289

Log:
  Remove Mac OS/X macros that did nothing for FreeBSD.
  
  The macros CAST_USER_ADDR_T() and CAST_DOWN() were used for the Mac OS/X
  port. The first of these macros was a no-op for FreeBSD and the second
  is no longer used.
  This patch gets rid of them. It also deletes the "mbuf_t" typedef which
  is no longer used in the FreeBSD code from nfskpiport.h
  
  This patch should not change semantics.

Modified:
  head/sys/fs/nfs/nfs_commonsubs.c
  head/sys/fs/nfs/nfskpiport.h
  head/sys/fs/nfsclient/nfs_clcomsubs.c
  head/sys/fs/nfsserver/nfs_nfsdport.c

Modified: head/sys/fs/nfs/nfs_commonsubs.c
==
--- head/sys/fs/nfs/nfs_commonsubs.cSat Apr 25 00:57:48 2020
(r360288)
+++ head/sys/fs/nfs/nfs_commonsubs.cSat Apr 25 02:18:59 2020
(r360289)
@@ -652,7 +652,7 @@ nfsm_mbufuio(struct nfsrv_descript *nd, struct uio *ui
if (uiop->uio_segflg == UIO_SYSSPACE)
NFSBCOPY(mbufcp, uiocp, xfer);
else
-   copyout(mbufcp, CAST_USER_ADDR_T(uiocp), xfer);
+   copyout(mbufcp, uiocp, xfer);
left -= xfer;
len -= xfer;
mbufcp += xfer;
@@ -3759,8 +3759,7 @@ nfssvc_idname(struct nfsd_idargs *nidp)
}
if (nidp->nid_flag & NFSID_INITIALIZE) {
cp = malloc(nidp->nid_namelen + 1, M_NFSSTRING, M_WAITOK);
-   error = copyin(CAST_USER_ADDR_T(nidp->nid_name), cp,
-   nidp->nid_namelen);
+   error = copyin(nidp->nid_name, cp, nidp->nid_namelen);
if (error != 0) {
free(cp, M_NFSSTRING);
goto out;
@@ -3856,13 +3855,13 @@ nfssvc_idname(struct nfsd_idargs *nidp)
 */
newusrp = malloc(sizeof(struct nfsusrgrp) + nidp->nid_namelen,
M_NFSUSERGROUP, M_WAITOK | M_ZERO);
-   error = copyin(CAST_USER_ADDR_T(nidp->nid_name), newusrp->lug_name,
+   error = copyin(nidp->nid_name, newusrp->lug_name,
nidp->nid_namelen);
if (error == 0 && nidp->nid_ngroup > 0 &&
(nidp->nid_flag & NFSID_ADDUID) != 0) {
grps = malloc(sizeof(gid_t) * nidp->nid_ngroup, M_TEMP,
M_WAITOK);
-   error = copyin(CAST_USER_ADDR_T(nidp->nid_grps), grps,
+   error = copyin(nidp->nid_grps, grps,
sizeof(gid_t) * nidp->nid_ngroup);
if (error == 0) {
/*

Modified: head/sys/fs/nfs/nfskpiport.h
==
--- head/sys/fs/nfs/nfskpiport.hSat Apr 25 00:57:48 2020
(r360288)
+++ head/sys/fs/nfs/nfskpiport.hSat Apr 25 02:18:59 2020
(r360289)
@@ -43,13 +43,9 @@ typedef struct vnode *   vnode_t;
 #definevnode_mount(v)  ((v)->v_mount)
 #definevnode_vtype(v)  ((v)->v_type)
 
-typedef struct mbuf *  mbuf_t;
-
 /*
  * This stuff is needed by Darwin for handling the uio structure.
  */
-#defineCAST_USER_ADDR_T(a) (a)
-#defineCAST_DOWN(c, a) ((c) (a))
 #defineuio_uio_resid(p)((p)->uio_resid)
 #defineuio_uio_resid_add(p, v) ((p)->uio_resid += (v))
 #defineuio_uio_resid_set(p, v) ((p)->uio_resid = (v))

Modified: head/sys/fs/nfsclient/nfs_clcomsubs.c
==
--- head/sys/fs/nfsclient/nfs_clcomsubs.c   Sat Apr 25 00:57:48 2020
(r360288)
+++ head/sys/fs/nfsclient/nfs_clcomsubs.c   Sat Apr 25 02:18:59 2020
(r360289)
@@ -105,8 +105,7 @@ nfsm_uiombuf(struct nfsrv_descript *nd, struct uio *ui
NFSBCOPY(uiocp, mtod(mp, caddr_t) + mp->m_len,
xfer);
else
-   copyin(CAST_USER_ADDR_T(uiocp), mtod(mp, caddr_t)
-   + mp->m_len, xfer);
+   copyin(uiocp, mtod(mp, caddr_t) + mp->m_len, xfer);
mp->m_len += xfer;
left -= xfer;
uiocp += xfer;

Modified: head/sys/fs/nfsserver/nfs_nfsdport.c
==
--- head/sys/fs/nfsserver/nfs_nfsdport.cSat Apr 25 00:57:48 2020
(r360288)
+++ head/sys/fs/nfsserver/nfs_nfsdport.cSat Apr 25 02:18:59 2020
(r360289)
@@ -3712,8 +3712,7 @@ nfssvc_srvcall(struct thread *p, struct nfssvc_args *u
len = sizeof (struct nfsd_dumpclients) * dumplist.ndl_size;
dumpclients = malloc(len, M_TEMP, 

svn commit: r360288 - head/usr.sbin/bluetooth/hccontrol

[Hans Petter Selasky]

Author: hselasky
Date: Sat Apr 25 00:57:48 2020
New Revision: 360288
URL: https://svnweb.freebsd.org/changeset/base/360288

Log:
  Put advertising data in correct place.
  
  Submitted by: Marc Veldman 
  PR:   245848
  MFC after:1 week
  Sponsored by: Mellanox Technologies

Modified:
  head/usr.sbin/bluetooth/hccontrol/le.c

Modified: head/usr.sbin/bluetooth/hccontrol/le.c
==
--- head/usr.sbin/bluetooth/hccontrol/le.c  Sat Apr 25 00:14:17 2020
(r360287)
+++ head/usr.sbin/bluetooth/hccontrol/le.c  Sat Apr 25 00:57:48 2020
(r360288)
@@ -491,6 +491,7 @@ le_set_advertising_data(int s, int argc, char *argv[])
parse_param(argc, argv, buf, );
memset(cp.advertising_data, 0, sizeof(cp.advertising_data));
cp.advertising_data_length = len;
+   memcpy(cp.advertising_data, buf, len);
 
if (hci_request(s, NG_HCI_OPCODE(NG_HCI_OGF_LE,
NG_HCI_OCF_LE_SET_ADVERTISING_DATA), 
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r360287 - head/usr.sbin/freebsd-update

[Kyle Evans]

Author: kevans
Date: Sat Apr 25 00:14:17 2020
New Revision: 360287
URL: https://svnweb.freebsd.org/changeset/base/360287

Log:
  freebsd-update: rehash certs
  
  With the inclusion of caroot bits, we'll need to also rehash on update as we
  do in mergemaster/etcupdate.
  
  If certctl's installed on the system, just unconditionally rehash. This
  isn't an expensive operation, and we can refine it to compare
  INDEX-{OLD,NEW} later if we really want to.
  
  Reviewed by:  emaste, allanjude
  MFC after:3 days
  Differential Revision:https://reviews.freebsd.org/D21805

Modified:
  head/usr.sbin/freebsd-update/freebsd-update.sh

Modified: head/usr.sbin/freebsd-update/freebsd-update.sh
==
--- head/usr.sbin/freebsd-update/freebsd-update.sh  Fri Apr 24 22:17:13 
2020(r360286)
+++ head/usr.sbin/freebsd-update/freebsd-update.sh  Sat Apr 25 00:14:17 
2020(r360287)
@@ -2876,7 +2876,7 @@ install_delete () {
rm newfiles killfiles
 }
 
-# Install new files, delete old files, and update linker.hints
+# Install new files, delete old files, and update generated files
 install_files () {
# If we haven't already dealt with the kernel, deal with it.
if ! [ -f $1/kerneldone ]; then
@@ -2943,6 +2943,11 @@ Kernel updates have been installed.  Please reboot and
grep -vE '^[^|]*/lib/[^|]*\.so\.[0-9]+\|' > INDEX-NEW
install_from_index INDEX-NEW || return 1
install_delete INDEX-OLD INDEX-NEW || return 1
+
+   # Rehash certs if we actually have certctl installed.
+   if which certctl>/dev/null; then
+   env DESTDIR=${BASEDIR} certctl rehash
+   fi
 
# Rebuild generated pwd files.
if [ ${BASEDIR}/etc/master.passwd -nt ${BASEDIR}/etc/spwd.db ] 
||
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r360285 - head/sys/net80211

[John Baldwin]

Author: jhb
Date: Fri Apr 24 22:10:02 2020
New Revision: 360285
URL: https://svnweb.freebsd.org/changeset/base/360285

Log:
  Don't indirect user pointers directly in two 802.11s ioctls.
  
  IEEE80211_MESH_RTCMD_ADD was invoking memcmp() to validate the
  supplied address directly on the user pointer rather than first doing
  a copyin() and validating the copied value.
  
  IEEE80211_MESH_RTCMD_DELETE was passing the user pointer directly to
  ieee80211_mesh_rt_del() rather than copying the user buffer into a
  temporary kernel buffer.
  
  Reviewed by:  brooks, kib
  Obtained from:CheriBSD
  MFC after:2 weeks
  Sponsored by: DARPA
  Differential Revision:https://reviews.freebsd.org/D24562

Modified:
  head/sys/net80211/ieee80211_mesh.c

Modified: head/sys/net80211/ieee80211_mesh.c
==
--- head/sys/net80211/ieee80211_mesh.c  Fri Apr 24 22:04:14 2020
(r360284)
+++ head/sys/net80211/ieee80211_mesh.c  Fri Apr 24 22:10:02 2020
(r360285)
@@ -3575,16 +3575,21 @@ mesh_ioctl_set80211(struct ieee80211vap *vap, struct i
ieee80211_mesh_rt_flush(vap);
break;
case IEEE80211_MESH_RTCMD_ADD:
-   if (IEEE80211_ADDR_EQ(vap->iv_myaddr, ireq->i_data) ||
-   IEEE80211_ADDR_EQ(broadcastaddr, ireq->i_data))
-   return EINVAL;
-   error = copyin(ireq->i_data, ,
+   error = copyin(ireq->i_data, tmpaddr,
IEEE80211_ADDR_LEN);
-   if (error == 0)
-   ieee80211_mesh_discover(vap, tmpaddr, NULL);
+   if (error != 0)
+   break;
+   if (IEEE80211_ADDR_EQ(vap->iv_myaddr, tmpaddr) ||
+   IEEE80211_ADDR_EQ(broadcastaddr, tmpaddr))
+   return EINVAL;
+   ieee80211_mesh_discover(vap, tmpaddr, NULL);
break;
case IEEE80211_MESH_RTCMD_DELETE:
-   ieee80211_mesh_rt_del(vap, ireq->i_data);
+   error = copyin(ireq->i_data, tmpaddr,
+   IEEE80211_ADDR_LEN);
+   if (error != 0)
+   break;
+   ieee80211_mesh_rt_del(vap, tmpaddr);
break;
default:
return ENOSYS;
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r360284 - head/lib/libc/sys

[Mateusz Piotrowski]

Author: 0mp (doc,ports committer)
Date: Fri Apr 24 22:04:14 2020
New Revision: 360284
URL: https://svnweb.freebsd.org/changeset/base/360284

Log:
  Fix a typo
  
  Reported by:  pstef
  MFC after:2 days

Modified:
  head/lib/libc/sys/procctl.2

Modified: head/lib/libc/sys/procctl.2
==
--- head/lib/libc/sys/procctl.2 Fri Apr 24 22:02:22 2020(r360283)
+++ head/lib/libc/sys/procctl.2 Fri Apr 24 22:04:14 2020(r360284)
@@ -29,7 +29,7 @@
 .\"
 .\" $FreeBSD$
 .\"
-.Dd August 31, 2019
+.Dd April 25, 2020
 .Dt PROCCTL 2
 .Os
 .Sh NAME
@@ -674,7 +674,7 @@ or invalid signal number.
 .Xr dtrace 1 ,
 .Xr proccontrol 1 ,
 .Xr protect 1 ,
-.Xr cap_enter 2,
+.Xr cap_enter 2 ,
 .Xr kill 2 ,
 .Xr ktrace 2 ,
 .Xr mmap 2 ,
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r360283 - head/usr.bin/env

[Mateusz Piotrowski]

Author: 0mp (doc,ports committer)
Date: Fri Apr 24 22:02:22 2020
New Revision: 360283
URL: https://svnweb.freebsd.org/changeset/base/360283

Log:
  Fix invalid use of macros and two typos
  
  It turns out that currently mandoc(1) is not handling Fl in Ss
  correctly (maybe it never was). Let's just replace "Fl S \ ..."
  with "-S ...". After all, this subsection title is stylized anyway, so Fl
  is not that helpful.
  
  MFC after:2 weeks

Modified:
  head/usr.bin/env/env.1

Modified: head/usr.bin/env/env.1
==
--- head/usr.bin/env/env.1  Fri Apr 24 21:30:31 2020(r360282)
+++ head/usr.bin/env/env.1  Fri Apr 24 22:02:22 2020(r360283)
@@ -31,7 +31,7 @@
 .\" From FreeBSD: src/usr.bin/printenv/printenv.1,v 1.17 2002/11/26 17:33:35 
ru Exp
 .\" $FreeBSD$
 .\"
-.Dd January 19, 2020
+.Dd April 24, 2020
 .Dt ENV 1
 .Os
 .Sh NAME
@@ -165,7 +165,7 @@ and
 .Ar utility
 may not be specified together.
 .\"
-.Ss Details of Fl S \ (split-string) processing
+.Ss Details of -S (split-string) processing
 The processing of the
 .Fl S
 option will split the given
@@ -292,11 +292,11 @@ processing.
 .Pp
 Also,
 .Fl S
-processing can not reference the value of the special parameters
+processing cannot reference the value of the special parameters
 which are defined by most shells.
 For instance,
 .Fl S
-can not recognize special parameters such as:
+cannot recognize special parameters such as:
 .Ql $* ,
 .Ql $@ ,
 .Ql $# ,
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r360241 - head/sys/dev/ichiic

[John Baldwin]

On 4/24/20 11:48 AM, Andriy Gapon wrote:
> On 24/04/2020 19:23, Justin Hibbits wrote:
>> Can you look at how ofw_iicbus does this?  Everything works just fine
>> with that, and it's compiled into the iicbus module as well.  Perhaps
>> you can pick some ideas from there.
>>
>> One thing I remember doing on the fsl_i2c driver was to just name the
>> driver iichb and everything worked beautifully.  Yes, it was sort of a
>> cop-out vs adding another attachment, but it solved the problem, and
>> does make sense.
> 
> Justin,
> 
> yes, "iichb" is the only name that has special properties because of
> DRIVER_MODULE(iicbus, iichb, ...) in icbus.c.
> That's essentially the same approach that is used for gpio.
> Maybe it's the way.
> But there was something that spooked me about many drivers having the same 
> name,
> but can't recall what.

Drivers can have the same name if they are prepared to handle the same
child devices.  For example, various Host-PCI and PCI-PCI bridge drivers
all use the "pcib" name as they all support having "pci" child devices
and provide the pcib_if methods "pci" bus devices expect their parent
to have, etc.  I suspect in the case of "iichb" the same is true and
that would be fine having all these drivers use the same name and rely
on the description string to differentiate different vendors, etc.

-- 
John Baldwin
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r360281 - head/sys/mips/mips

[Mark Johnston]

Author: markj
Date: Fri Apr 24 21:21:49 2020
New Revision: 360281
URL: https://svnweb.freebsd.org/changeset/base/360281

Log:
  Fix a race in pmap_emulate_modified().
  
  pmap_emulate_modify() was assuming that no changes to the pmap could
  take place between the TLB signaling the fault and
  pmap_emulate_modify()'s acquisition of the pmap lock, but that's clearly
  not even true in the uniprocessor case, nevermind the SMP case.
  
  Submitted by: Nathaniel Filardo 
  Reviewed by:  kib
  MFC after:2 weeks
  Differential Revision:https://reviews.freebsd.org/D24523

Modified:
  head/sys/mips/mips/pmap.c

Modified: head/sys/mips/mips/pmap.c
==
--- head/sys/mips/mips/pmap.c   Fri Apr 24 21:21:23 2020(r360280)
+++ head/sys/mips/mips/pmap.c   Fri Apr 24 21:21:49 2020(r360281)
@@ -3502,28 +3502,71 @@ pmap_emulate_modified(pmap_t pmap, vm_offset_t va)
 
PMAP_LOCK(pmap);
pte = pmap_pte(pmap, va);
-   if (pte == NULL)
-   panic("pmap_emulate_modified: can't find PTE");
-#ifdef SMP
-   /* It is possible that some other CPU changed m-bit */
-   if (!pte_test(pte, PTE_V) || pte_test(pte, PTE_D)) {
+
+   /*
+* It is possible that some other CPU or thread changed the pmap while
+* we weren't looking; in the SMP case, this is readily apparent, but
+* it can even happen in the UP case, because we may have been blocked
+* on PMAP_LOCK(pmap) above while someone changed this out from
+* underneath us.
+*/
+
+   if (pte == NULL) {
+   /*
+* This PTE's PTP (or one of its ancestors) has been reclaimed;
+* trigger a full fault to reconstruct it via pmap_enter.
+*/
+   PMAP_UNLOCK(pmap);
+   return (1);
+   }
+
+   if (!pte_test(pte, PTE_V)) {
+   /*
+* This PTE is no longer valid; the other thread or other
+* processor must have arranged for our TLB to no longer
+* have this entry, possibly by IPI, so no tlb_update is
+* required.  Fall out of the fast path and go take a
+* general fault before retrying the instruction (or taking
+* a signal).
+*/
+   PMAP_UNLOCK(pmap);
+   return (1);
+   }
+
+   if (pte_test(pte, PTE_D)) {
+   /*
+* This PTE is valid and has the PTE_D bit asserted; since
+* this is an increase in permission, we may have been expected
+* to update the TLB lazily.  Do so here and return, on the
+* fast path, to retry the instruction.
+*/
tlb_update(pmap, va, *pte);
PMAP_UNLOCK(pmap);
return (0);
}
-#else
-   if (!pte_test(pte, PTE_V) || pte_test(pte, PTE_D))
-   panic("pmap_emulate_modified: invalid pte");
-#endif
+
if (pte_test(pte, PTE_RO)) {
+   /*
+* This PTE is valid, not dirty, and read-only.  Go take a
+* full fault (most likely to upgrade this part of the address
+* space to writeable).
+*/
PMAP_UNLOCK(pmap);
return (1);
}
-   pte_set(pte, PTE_D);
-   tlb_update(pmap, va, *pte);
+
if (!pte_test(pte, PTE_MANAGED))
panic("pmap_emulate_modified: unmanaged page");
+
+   /*
+* PTE is valid, managed, not dirty, and not read-only.  Set PTE_D
+* and eagerly update the local TLB, returning on the fast path.
+*/
+
+   pte_set(pte, PTE_D);
+   tlb_update(pmap, va, *pte);
PMAP_UNLOCK(pmap);
+
return (0);
 }
 
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r360280 - head/sys/mips/mips

[Mark Johnston]

Author: markj
Date: Fri Apr 24 21:21:23 2020
New Revision: 360280
URL: https://svnweb.freebsd.org/changeset/base/360280

Log:
  Fix a race between _pmap_unwire_ptp() and MipsDoTLBMiss().
  
  MipsDoTLBMiss() will load a segmap entry or pde, check that it isn't
  zero, and then chase that pointer to a physical page. If that page has
  been freed in the interim, it will read garbage and go on to populate
  the TLB with it.
  
  This can happen because pmap_unwire_ptp zeros out the pde and
  vm_page_free_zero()s the ptp (or, recursively, zeros out the segmap
  entry and vm_page_free_zero()s the pdp) without interlocking against
  MipsDoTLBMiss(). The pmap is locked, and pvh_global_lock may or may not
  be held, but this is not enough. Solve this issue by inserting TLB
  shootdowns within _pmap_unwire_ptp(); as MipsDoTLBMiss() runs with IRQs
  deferred, the IPIs involved in TLB shootdown are sufficient to ensure
  that MipsDoTLBMiss() sees either a zero segmap entry / pde or a non-zero
  entry and the pointed-to page still not freed.
  
  Submitted by: Nathaniel Filardo 
  Reviewed by:  kib
  MFC after:2 weeks
  Differential Revision:https://reviews.freebsd.org/D24491

Modified:
  head/sys/mips/mips/pmap.c

Modified: head/sys/mips/mips/pmap.c
==
--- head/sys/mips/mips/pmap.c   Fri Apr 24 19:43:07 2020(r360279)
+++ head/sys/mips/mips/pmap.c   Fri Apr 24 21:21:23 2020(r360280)
@@ -1004,18 +1004,26 @@ static void
 _pmap_unwire_ptp(pmap_t pmap, vm_offset_t va, vm_page_t m)
 {
pd_entry_t *pde;
+   vm_offset_t sva, eva;
 
PMAP_LOCK_ASSERT(pmap, MA_OWNED);
/*
 * unmap the page table page
 */
 #ifdef __mips_n64
-   if (m->pindex < NUPDE)
+   if (m->pindex < NUPDE) {
pde = pmap_pde(pmap, va);
-   else
+   sva = va & ~PDRMASK;
+   eva = sva + NBPDR;
+   } else {
pde = pmap_segmap(pmap, va);
+   sva = va & ~SEGMASK;
+   eva = sva + NBSEG;
+   }
 #else
pde = pmap_pde(pmap, va);
+   sva = va & ~SEGMASK;
+   eva = sva + NBSEG;
 #endif
*pde = 0;
pmap->pm_stats.resident_count--;
@@ -1026,12 +1034,22 @@ _pmap_unwire_ptp(pmap_t pmap, vm_offset_t va, vm_page_
vm_page_t pdpg;
 
/*
-* Recursively decrement next level pagetable refcount
+* Recursively decrement next level pagetable refcount.
+* Either that shoots down a larger range from TLBs (below)
+* or we're to shoot down just the page in question.
 */
pdp = (pd_entry_t *)*pmap_segmap(pmap, va);
pdpg = PHYS_TO_VM_PAGE(MIPS_DIRECT_TO_PHYS(pdp));
-   pmap_unwire_ptp(pmap, va, pdpg);
+   if (!pmap_unwire_ptp(pmap, va, pdpg)) {
+   pmap_invalidate_range(pmap, sva, eva);
+   }
+   } else {
+   /* Segmap entry shootdown */
+   pmap_invalidate_range(pmap, sva, eva);
}
+#else
+   /* Segmap entry shootdown */
+   pmap_invalidate_range(pmap, sva, eva);
 #endif
 
/*
@@ -1485,7 +1503,15 @@ pmap_pv_reclaim(pmap_t locked_pmap)
if (TAILQ_EMPTY(>md.pv_list))
vm_page_aflag_clear(m, PGA_WRITEABLE);
pc->pc_map[field] |= 1UL << bit;
-   pmap_unuse_pt(pmap, va, *pde);
+
+   /*
+* For simplicity, we will unconditionally shoot
+* down TLBs either at the end of this function
+* or at the top of the loop above if we switch
+* to a different pmap.
+*/
+   (void)pmap_unuse_pt(pmap, va, *pde);
+
freed++;
}
}
@@ -1714,6 +1740,23 @@ pmap_try_insert_pv_entry(pmap_t pmap, vm_page_t mpte, 
 
 /*
  * pmap_remove_pte: do the things to unmap a page in a process
+ *
+ * Returns true if this was the last PTE in the PT (and possibly the last PT in
+ * the PD, and possibly the last PD in the segmap), in which case...
+ *
+ *   1) the TLB has been invalidated for the whole PT's span (at least),
+ *   already, to ensure that MipsDoTLBMiss does not attempt to follow a
+ *   dangling pointer into a freed page.  No additional TLB shootdown is
+ *   required.
+ *
+ *   2) if this removal was part of a sweep to remove PTEs, it is safe to jump
+ *   to the PT span boundary and continue.
+ *
+ *   3) The given pde may now point onto a freed page and must not be
+ *   dereferenced
+ *
+ * If the return value is false, the TLB has not been shot down (and the segmap
+ * entry, PD, and PT all 

Re: svn commit: r360241 - head/sys/dev/ichiic

[Andriy Gapon]

On 24/04/2020 19:23, Justin Hibbits wrote:
> Can you look at how ofw_iicbus does this?  Everything works just fine
> with that, and it's compiled into the iicbus module as well.  Perhaps
> you can pick some ideas from there.
> 
> One thing I remember doing on the fsl_i2c driver was to just name the
> driver iichb and everything worked beautifully.  Yes, it was sort of a
> cop-out vs adding another attachment, but it solved the problem, and
> does make sense.

Justin,

yes, "iichb" is the only name that has special properties because of
DRIVER_MODULE(iicbus, iichb, ...) in icbus.c.
That's essentially the same approach that is used for gpio.
Maybe it's the way.
But there was something that spooked me about many drivers having the same name,
but can't recall what.

-- 
Andriy Gapon
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r360276 - in head/sys: amd64/amd64 arm64/arm64 i386/i386 powerpc/powerpc

[Mark Johnston]

Author: markj
Date: Fri Apr 24 18:47:42 2020
New Revision: 360276
URL: https://svnweb.freebsd.org/changeset/base/360276

Log:
  Remove an obsolete TODO comment from several minidump implementations.
  
  The comment referenced a non-existent function, and these minidump
  implementations already buffer discontiguous physical data pages by
  mapping them into a single VA range that gets passed to the dump device,
  so there is no real advantage in batching calls to blk_write().
  
  The RISC-V and MIPS minidump implementations still write a page at a
  time and so would benefit from some form of batching.
  
  MFC after:2 weeks
  Sponsored by: Juniper Networks, Klara Inc.

Modified:
  head/sys/amd64/amd64/minidump_machdep.c
  head/sys/arm64/arm64/minidump_machdep.c
  head/sys/i386/i386/minidump_machdep_base.c
  head/sys/powerpc/powerpc/minidump_machdep.c

Modified: head/sys/amd64/amd64/minidump_machdep.c
==
--- head/sys/amd64/amd64/minidump_machdep.c Fri Apr 24 16:40:42 2020
(r360275)
+++ head/sys/amd64/amd64/minidump_machdep.c Fri Apr 24 18:47:42 2020
(r360276)
@@ -409,7 +409,6 @@ minidumpsys(struct dumperinfo *di)
}
 
/* Dump memory chunks */
-   /* XXX cluster it up and use blk_dump() */
for (i = 0; i < vm_page_dump_size / sizeof(*vm_page_dump); i++) {
bits = vm_page_dump[i];
while (bits) {

Modified: head/sys/arm64/arm64/minidump_machdep.c
==
--- head/sys/arm64/arm64/minidump_machdep.c Fri Apr 24 16:40:42 2020
(r360275)
+++ head/sys/arm64/arm64/minidump_machdep.c Fri Apr 24 18:47:42 2020
(r360276)
@@ -374,7 +374,6 @@ minidumpsys(struct dumperinfo *di)
}
 
/* Dump memory chunks */
-   /* XXX cluster it up and use blk_dump() */
for (i = 0; i < vm_page_dump_size / sizeof(*vm_page_dump); i++) {
bits = vm_page_dump[i];
while (bits) {

Modified: head/sys/i386/i386/minidump_machdep_base.c
==
--- head/sys/i386/i386/minidump_machdep_base.c  Fri Apr 24 16:40:42 2020
(r360275)
+++ head/sys/i386/i386/minidump_machdep_base.c  Fri Apr 24 18:47:42 2020
(r360276)
@@ -321,7 +321,6 @@ minidumpsys(struct dumperinfo *di)
}
 
/* Dump memory chunks */
-   /* XXX cluster it up and use blk_dump() */
for (i = 0; i < vm_page_dump_size / sizeof(*vm_page_dump); i++) {
bits = vm_page_dump[i];
while (bits) {

Modified: head/sys/powerpc/powerpc/minidump_machdep.c
==
--- head/sys/powerpc/powerpc/minidump_machdep.c Fri Apr 24 16:40:42 2020
(r360275)
+++ head/sys/powerpc/powerpc/minidump_machdep.c Fri Apr 24 18:47:42 2020
(r360276)
@@ -381,7 +381,6 @@ retry:
dump_total("pmap", pmapsize);
 
/* Dump memory chunks */
-   /* XXX cluster it up and use blk_dump() */
for (i = 0; i < vm_page_dump_size / sizeof(*vm_page_dump); i++) {
bits = vm_page_dump[i];
/* TODO optimize with bit manipulation instructions */
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r360277 - head/sys/arm64/arm64

[Mark Johnston]

Author: markj
Date: Fri Apr 24 18:47:57 2020
New Revision: 360277
URL: https://svnweb.freebsd.org/changeset/base/360277

Log:
  Fix handling of 1GB mappings in the arm64 minidump code.
  
  For such mappings we need to dump 512 page table pages, not one, and
  they need to be included in the pmap size recorded in the minidump
  header.
  
  MFC after:2 weeks
  Sponsored by: Juniper Networks, Klara Inc.

Modified:
  head/sys/arm64/arm64/minidump_machdep.c

Modified: head/sys/arm64/arm64/minidump_machdep.c
==
--- head/sys/arm64/arm64/minidump_machdep.c Fri Apr 24 18:47:42 2020
(r360276)
+++ head/sys/arm64/arm64/minidump_machdep.c Fri Apr 24 18:47:57 2020
(r360277)
@@ -34,8 +34,6 @@ __FBSDID("$FreeBSD$");
 
 #include "opt_watchdog.h"
 
-#include "opt_watchdog.h"
-
 #include 
 #include 
 #include 
@@ -68,7 +66,7 @@ static size_t fragsz;
 static void *dump_va;
 static size_t counter, progress, dumpsize;
 
-static uint64_t tmpbuffer[PAGE_SIZE / sizeof(uint64_t)];
+static uint64_t tmpbuffer[Ln_ENTRIES];
 
 CTASSERT(sizeof(*vm_page_dump) == 8);
 
@@ -210,16 +208,14 @@ blk_write(struct dumperinfo *di, char *ptr, vm_paddr_t
 int
 minidumpsys(struct dumperinfo *di)
 {
+   struct minidumphdr mdhdr;
pd_entry_t *l0, *l1, *l2;
pt_entry_t *l3;
-   uint32_t pmapsize;
vm_offset_t va;
vm_paddr_t pa;
-   int error;
uint64_t bits;
-   int i, bit;
-   int retry_count;
-   struct minidumphdr mdhdr;
+   uint32_t pmapsize;
+   int bit, error, i, j, retry_count;
 
retry_count = 0;
  retry:
@@ -231,11 +227,15 @@ minidumpsys(struct dumperinfo *di)
if (!pmap_get_tables(pmap_kernel(), va, , , , ))
continue;
 
-   /* We should always be using the l2 table for kvm */
-   if (l2 == NULL)
-   continue;
-
-   if ((*l2 & ATTR_DESCR_MASK) == L2_BLOCK) {
+   if ((*l1 & ATTR_DESCR_MASK) == L1_BLOCK) {
+   pa = *l1 & ~ATTR_MASK;
+   for (i = 0; i < Ln_ENTRIES * Ln_ENTRIES;
+   i++, pa += PAGE_SIZE)
+   if (is_dumpable(pa))
+   dump_add_page(pa);
+   pmapsize += (Ln_ENTRIES - 1) * PAGE_SIZE;
+   va += L1_SIZE - L2_SIZE;
+   } else if ((*l2 & ATTR_DESCR_MASK) == L2_BLOCK) {
pa = *l2 & ~ATTR_MASK;
for (i = 0; i < Ln_ENTRIES; i++, pa += PAGE_SIZE) {
if (is_dumpable(pa))
@@ -327,25 +327,31 @@ minidumpsys(struct dumperinfo *di)
error = blk_flush(di);
if (error)
goto fail;
-   } else if (l2 == NULL) {
+   } else if ((*l1 & ATTR_DESCR_MASK) == L1_BLOCK) {
+   /*
+* Handle a 1GB block mapping: write out 512 fake L2
+* pages.
+*/
pa = (*l1 & ~ATTR_MASK) | (va & L1_OFFSET);
 
-   /* Generate fake l3 entries based upon the l1 entry */
for (i = 0; i < Ln_ENTRIES; i++) {
-   tmpbuffer[i] = pa + (i * PAGE_SIZE) |
-   ATTR_DEFAULT | L3_PAGE;
+   for (j = 0; j < Ln_ENTRIES; j++) {
+   tmpbuffer[j] = pa + i * L2_SIZE +
+   j * PAGE_SIZE | ATTR_DEFAULT |
+   L3_PAGE;
+   }
+   error = blk_write(di, (char *), 0,
+   PAGE_SIZE);
+   if (error)
+   goto fail;
}
-   /* We always write a page, even if it is zero */
-   error = blk_write(di, (char *), 0, PAGE_SIZE);
-   if (error)
-   goto fail;
/* flush, in case we reuse tmpbuffer in the same block*/
error = blk_flush(di);
if (error)
goto fail;
bzero(, sizeof(tmpbuffer));
+   va += L1_SIZE - L2_SIZE;
} else if ((*l2 & ATTR_DESCR_MASK) == L2_BLOCK) {
-   /* TODO: Handle an invalid L2 entry */
pa = (*l2 & ~ATTR_MASK) | (va & L2_OFFSET);
 
/* Generate fake l3 entries based upon the l1 entry */
@@ -353,7 +359,6 @@ minidumpsys(struct dumperinfo *di)
tmpbuffer[i] = pa + (i * PAGE_SIZE) |
   

Re: svn commit: r360241 - head/sys/dev/ichiic

[John Baldwin]

On 4/24/20 9:57 AM, Warner Losh wrote:
> On Fri, Apr 24, 2020 at 10:07 AM Andriy Gapon  wrote:
>> Let's use ig4 as an example.
>> Across its source files we had the following DRIVER_MODULE declarations:
>> DRIVER_MODULE(ig4iic, acpi, ... -- in ig4_acpi.c
>> DRIVER_MODULE(iicbus, ig4iic, ... -- in ig4_iic.c
>> DRIVER_MODULE(acpi_iicbus, ig4iic, ... -- in ig4_iic.c
>> The first one is needed to register ig4iic driver under acpi bus.  Other
>> two are
>> needed to register iicbus and acpi_iicbus drivers under ig4iic bus.
>> The order is not explicitly defined, so the corresponding declaration can
>> be
>> processed in any order when ig4.ko is loaded and so the corresponding
>> devclass_add_driver() can be called in any order.
>>
> 
> It's a bug in newbus if that matters. I'll grant that it does today, but it
> shouldn't. In the past we've worked around this issue in a number of
> different ways (including having 3 different modules with the order encoded
> into those modules). It also indicates, perhaps, bugs in the iic acpi
> enumeration stuff, but that's a harder case to make without more careful
> study since I know that acpi_iic works around the bit of a mismatch between
> newbus' device model and ACPI's.

FWIW, this is a longstanding bug, and it is the reason DRIVER_MODULE_ORDERED
exists[1], precisely so you can get all the child driver module's registered 
first
and have the "top-most" (in the hierarchy) driver register last so that all
the others are ready as new child devices are created.  The _ORDERED solution
is the only one I'm aware of that we have used for a single module containing
multiple drivers.  It may be that we have split up into tiny modules in the
past, but that solution is probably worse as the dependencies are usually
the wrong way around (the "leaf" drivers probably depend on the parent drivers
so they get loaded in the exact wrong order for this case where you want all
the leaf drivers registered before an instance of the parent driver attaches)

1: https://svnweb.freebsd.org/base?view=revision=225079

-- 
John Baldwin
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r360241 - head/sys/dev/ichiic

[Warner Losh]

On Fri, Apr 24, 2020 at 10:07 AM Andriy Gapon  wrote:

> On 24/04/2020 18:11, Warner Losh wrote:
> >
> >
> > On Fri, Apr 24, 2020 at 8:47 AM Andriy Gapon  > > wrote:
> >
> > On 24/04/2020 17:29, Warner Losh wrote:
> > >
> > >
> > > On Fri, Apr 24, 2020 at 1:49 AM Andriy Gapon  > 
> > > >> wrote:
> > >
> > > Author: avg
> > > Date: Fri Apr 24 07:49:21 2020
> > > New Revision: 360241
> > > URL: https://svnweb.freebsd.org/changeset/base/360241
> > >
> > > Log:
> > >   ig4: ensure that drivers always attach in correct order
> > >
> > >   Use DRIVER_MODULE_ORDERED(SI_ORDER_ANY) so that ig4's ACPI
> attachment
> > >   happens after iicbus and acpi_iicbus drivers are registered.
> > >
> > >   I have seen a problem where iicbus attached under ig4
> instead of
> > >   acpi_iicbus when ig4.ko was loaded with kldload.  I believe
> that that
> > >   happened because ig4 driver was a first driver to register,
> it attached
> > >   and created an iicbus child.  Then iicbus driver was
> registered and,
> > >   since it was the only driver that could attach to the iicbus
> child
> > >   device, it did exactly that.  After that acpi_iicbus driver
> was
> > >   registered.  It would be able to attach to the iicbus
> device, but it was
> > >   already attached, so nothing happened.
> > >
> > >
> > > Can you post more details of which devices are affected? From the
> description
> > > and the patch, I don't see how this could fix things.
> >
> > I think I listed them all: ig4iic with acpi attachment, iicbus and
> acpi_iicbus.
> > acpi
> >  \--- ig4iic
> >\ iicbus vs acpi_iicbus
> >
> > I tried to explain the problem and the fix in the commit message.
> If you want
> > to discuss any specifics, let's continue with specifics.  If there
> is anything
> > unclear in my explanation, I can clarify, but I need to understand
> what needs to
> > be clarified.
> >
> >
> > That won't fix the stated problem.
>
> It will.  It does.  You made me write an essay to explain why :)
>

Ah, it's a workaround for a newbus bug. OK. I'll work on fixing the newbus
bug then.


> > If changing the module order fixes something,
> > it's the wrong fix. Which is why I asked to make sure I understood the
> issue (it
> > was unclear if it was at the level indicated, or for the children of the
> iicbus).
> >
> > iicbus returns BUS_PROBE_GENERIC (-100) from its probe routine, while
> > acpi_iicbus returns BUS_PROBE_DEFAULT (-20). This means that acpi_iicbus
> should
> > always win. So something else is going on. We don't specify order on
> other
> > devices except for some weird, special needs drivers (this is not such a
> driver).
>
> This driver, along with all of other I2C controller drivers, has a
> particular
> quirk, so it can be called weird.
>
> It does not matter what the probe routines return if one of the drivers is
> not
> added to "newbus" at all (even if its code is loaded).  Its probe method
> is not
> executed.  And that's what I tried to explain in the commit message.
>
> Now, why this driver as well as all SMBus and I2C controller drivers are
> somewhat weird...  There is a multitude of drivers for SMBus and I2C
> controllers.  Those drivers have different names.  So, using newbus speak,
> smbus
> and iicbus drivers can attach to [newbus] devices under many different
> [newbus]
> buses.  For that reason, the corresponding DRIVER_MODULE declarations are
> not
> consolidated in smbus.c and iicbus.c; instead, they are spread over
> individual
> controller drivers.  So, loading of smbus or iicbus module does not result
> in a
> call to devclass_add_driver() that would register these drivers under some
> bus.
> And that's an unusual thing comparing to the most straightforward drivers.
>
> Let's use ig4 as an example.
> Across its source files we had the following DRIVER_MODULE declarations:
> DRIVER_MODULE(ig4iic, acpi, ... -- in ig4_acpi.c
> DRIVER_MODULE(iicbus, ig4iic, ... -- in ig4_iic.c
> DRIVER_MODULE(acpi_iicbus, ig4iic, ... -- in ig4_iic.c
> The first one is needed to register ig4iic driver under acpi bus.  Other
> two are
> needed to register iicbus and acpi_iicbus drivers under ig4iic bus.
> The order is not explicitly defined, so the corresponding declaration can
> be
> processed in any order when ig4.ko is loaded and so the corresponding
> devclass_add_driver() can be called in any order.
>

It's a bug in newbus if that matters. I'll grant that it does today, but it
shouldn't. In the past we've worked around this issue in a number of
different ways (including having 3 different modules with the order encoded
into those modules). It also indicates, perhaps, bugs in the iic acpi
enumeration stuff, but that's a 

svn commit: r360273 - head/release/arm64

[Emmanuel Vadot]

Author: manu
Date: Fri Apr 24 16:33:07 2020
New Revision: 360273
URL: https://svnweb.freebsd.org/changeset/base/360273

Log:
  Add PINE64 ROCK64 config for generation of release images

Added:
  head/release/arm64/ROCK64.conf   (contents, props changed)

Added: head/release/arm64/ROCK64.conf
==
--- /dev/null   00:00:00 1970   (empty, because file is newly added)
+++ head/release/arm64/ROCK64.conf  Fri Apr 24 16:33:07 2020
(r360273)
@@ -0,0 +1,28 @@
+#!/bin/sh
+#
+# $FreeBSD$
+#
+
+EMBEDDED_TARGET_ARCH="aarch64"
+EMBEDDED_TARGET="arm64"
+EMBEDDEDBUILD=1
+EMBEDDEDPORTS="sysutils/u-boot-rock64"
+FAT_SIZE="50m -b 16m"
+FAT_TYPE="16"
+IMAGE_SIZE="3072M"
+KERNEL="GENERIC"
+MD_ARGS="-x 63 -y 255"
+NODOC=1
+PART_SCHEME="GPT"
+export BOARDNAME="ROCK64"
+
+arm_install_uboot() {
+   UBOOT_DIR="/usr/local/share/u-boot/u-boot-rock64"
+   UBOOT_FILE_1="idbloader.img"
+   UBOOT_FILE_2="u-boot.itb"
+   chroot ${CHROOTDIR} dd if=${UBOOT_DIR}/${UBOOT_FILE_1} \
+   of=/dev/${mddev} bs=512 seek=64 conv=sync
+   chroot ${CHROOTDIR} dd if=${UBOOT_DIR}/${UBOOT_FILE_2} \
+   of=/dev/${mddev} bs=512 seek=16384 conv=sync
+   return 0
+}
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r360272 - head/release/arm64

[Emmanuel Vadot]

Author: manu
Date: Fri Apr 24 16:32:25 2020
New Revision: 360272
URL: https://svnweb.freebsd.org/changeset/base/360272

Log:
  Add PINE64 ROCKPro64 config for generation of release images
  
  Submitted by: Daniel Engberg
  Reviewed by:  imp
  Differential Revision:https://reviews.freebsd.org/D22538

Added:
  head/release/arm64/ROCKPRO64.conf   (contents, props changed)

Added: head/release/arm64/ROCKPRO64.conf
==
--- /dev/null   00:00:00 1970   (empty, because file is newly added)
+++ head/release/arm64/ROCKPRO64.conf   Fri Apr 24 16:32:25 2020
(r360272)
@@ -0,0 +1,28 @@
+#!/bin/sh
+#
+# $FreeBSD$
+#
+
+EMBEDDED_TARGET_ARCH="aarch64"
+EMBEDDED_TARGET="arm64"
+EMBEDDEDBUILD=1
+EMBEDDEDPORTS="sysutils/u-boot-rockpro64"
+FAT_SIZE="50m -b 16m"
+FAT_TYPE="16"
+IMAGE_SIZE="3072M"
+KERNEL="GENERIC"
+MD_ARGS="-x 63 -y 255"
+NODOC=1
+PART_SCHEME="GPT"
+export BOARDNAME="ROCKPRO64"
+
+arm_install_uboot() {
+   UBOOT_DIR="/usr/local/share/u-boot/u-boot-rockpro64"
+   UBOOT_FILE_1="idbloader.img"
+   UBOOT_FILE_2="u-boot.itb"
+   chroot ${CHROOTDIR} dd if=${UBOOT_DIR}/${UBOOT_FILE_1} \
+   of=/dev/${mddev} bs=512 seek=64 conv=sync
+   chroot ${CHROOTDIR} dd if=${UBOOT_DIR}/${UBOOT_FILE_2} \
+   of=/dev/${mddev} bs=512 seek=16384 conv=sync
+   return 0
+}
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r360271 - head/release/tools

[Emmanuel Vadot]

Author: manu
Date: Fri Apr 24 16:31:27 2020
New Revision: 360271
URL: https://svnweb.freebsd.org/changeset/base/360271

Log:
  Add support for generating release images using GPT for ARM
  
  Submitted by: Daniel Engberg (Original version)
  Differential Revision:https://reviews.freebsd.org/D22537

Modified:
  head/release/tools/arm.subr

Modified: head/release/tools/arm.subr
==
--- head/release/tools/arm.subr Fri Apr 24 16:19:03 2020(r360270)
+++ head/release/tools/arm.subr Fri Apr 24 16:31:27 2020(r360271)
@@ -65,13 +65,21 @@ umount_loop() {
 arm_create_disk() {
# Create the target raw file and temporary work directory.
chroot ${CHROOTDIR} gpart create -s ${PART_SCHEME} ${mddev}
-   chroot ${CHROOTDIR} gpart add -t '!12' -a 512k -s ${FAT_SIZE} ${mddev}
-   chroot ${CHROOTDIR} gpart set -a active -i 1 ${mddev}
-   chroot ${CHROOTDIR} newfs_msdos -L msdosboot -F ${FAT_TYPE} 
/dev/${mddev}s1
-   chroot ${CHROOTDIR} gpart add -t freebsd ${mddev}
-   chroot ${CHROOTDIR} gpart create -s bsd ${mddev}s2
-   chroot ${CHROOTDIR} gpart add -t freebsd-ufs -a 64k /dev/${mddev}s2
-   chroot ${CHROOTDIR} newfs -U -L rootfs /dev/${mddev}s2a
+   if [ "${PART_SCHEME}" == "GPT" ]; then
+   chroot ${CHROOTDIR} gpart add -t efi -l efi -a 512k -s 
${FAT_SIZE} ${mddev}
+   chroot ${CHROOTDIR} newfs_msdos -L efi -F ${FAT_TYPE} 
/dev/${mddev}p1
+   chroot ${CHROOTDIR} gpart add -t freebsd-ufs -l rootfs -a 64k 
${mddev}
+   chroot ${CHROOTDIR} newfs -U -L rootfs /dev/${mddev}p2
+   fi
+   if [ "${PART_SCHEME}" == "MBR" ]; then
+   chroot ${CHROOTDIR} gpart add -t '!12' -a 512k -s ${FAT_SIZE} 
${mddev}
+   chroot ${CHROOTDIR} gpart set -a active -i 1 ${mddev}
+   chroot ${CHROOTDIR} newfs_msdos -L msdosboot -F ${FAT_TYPE} 
/dev/${mddev}s1
+   chroot ${CHROOTDIR} gpart add -t freebsd ${mddev}
+   chroot ${CHROOTDIR} gpart create -s bsd ${mddev}s2
+   chroot ${CHROOTDIR} gpart add -t freebsd-ufs -a 64k 
/dev/${mddev}s2
+   chroot ${CHROOTDIR} newfs -U -L rootfs /dev/${mddev}s2a
+   fi
 
return 0
 }
@@ -161,7 +169,12 @@ arm_setup_minimal_loader() {
 }
 
 arm_install_base() {
-   chroot ${CHROOTDIR} mount /dev/${mddev}s2a ${DESTDIR}
+   if [ "${PART_SCHEME}" == "GPT" ]; then
+   chroot ${CHROOTDIR} mount /dev/${mddev}p2 ${DESTDIR}
+   fi
+   if [ "${PART_SCHEME}" == "MBR" ]; then
+   chroot ${CHROOTDIR} mount /dev/${mddev}s2a ${DESTDIR}
+   fi
eval chroot ${CHROOTDIR} make -C ${WORLDDIR} \
TARGET=${EMBEDDED_TARGET} \
TARGET_ARCH=${EMBEDDED_TARGET_ARCH} \
@@ -178,10 +191,18 @@ arm_install_base() {
 
echo '# Custom /etc/fstab for FreeBSD embedded images' \
> ${CHROOTDIR}/${DESTDIR}/etc/fstab
-   echo "/dev/ufs/rootfs   /   ufs rw  1   1" \
-   >> ${CHROOTDIR}/${DESTDIR}/etc/fstab
-   echo "/dev/msdosfs/MSDOSBOOT /boot/msdos msdosfs rw,noatime 0 0" \
-   >> ${CHROOTDIR}/${DESTDIR}/etc/fstab
+   if [ "${PART_SCHEME}" == "GPT" ]; then
+   echo "/dev/ufs/rootfs   /   ufs rw  1   1" \
+   >> ${CHROOTDIR}/${DESTDIR}/etc/fstab
+   echo "/dev/msdosfs/efi /boot/efi msdosfs rw,noatime 0 0" \
+   >> ${CHROOTDIR}/${DESTDIR}/etc/fstab
+   fi
+   if [ "${PART_SCHEME}" == "MBR" ]; then
+   echo "/dev/ufs/rootfs   /   ufs rw  1   1" \
+   >> ${CHROOTDIR}/${DESTDIR}/etc/fstab
+   echo "/dev/msdosfs/MSDOSBOOT /boot/msdos msdosfs rw,noatime 0 
0" \
+   >> ${CHROOTDIR}/${DESTDIR}/etc/fstab
+   fi
echo "tmpfs /tmp tmpfs rw,mode=1777,size=50m 0 0" \
>> ${CHROOTDIR}/${DESTDIR}/etc/fstab
 
@@ -206,8 +227,17 @@ arm_install_boot() {
FATMOUNT="${DESTDIR%${KERNEL}}/fat"
UFSMOUNT="${DESTDIR%${KERNEL}}/ufs"
chroot ${CHROOTDIR} mkdir -p "${FATMOUNT}" "${UFSMOUNT}"
-   chroot ${CHROOTDIR} mount_msdosfs /dev/${mddev}s1 ${FATMOUNT}
-   chroot ${CHROOTDIR} mount /dev/${mddev}s2a ${UFSMOUNT}
+   if [ "${PART_SCHEME}" == "GPT" ]; then
+   dospart="/dev/${mddev}p1"
+   ufspart="/dev/${mddev}p2"
+   fi
+   if [ "${PART_SCHEME}" == "MBR" ]; then
+   dospart="/dev/${mddev}s1"
+   ufspart="/dev/${mddev}s2a"
+   fi
+
+   chroot ${CHROOTDIR} mount_msdosfs ${dospart} ${FATMOUNT}
+   chroot ${CHROOTDIR} mount ${ufspart} ${UFSMOUNT}
 
if [ "${EMBEDDED_TARGET}" == "arm" ]; then
chroot ${CHROOTDIR} cp -p ${UFSMOUNT}/boot/ubldr.bin \
___
svn-src-head@freebsd.org mailing list

Re: svn commit: r360241 - head/sys/dev/ichiic

[Justin Hibbits]

On Fri, 24 Apr 2020 19:07:35 +0300
Andriy Gapon  wrote:

> On 24/04/2020 18:11, Warner Losh wrote:
> > 
> > 
> > On Fri, Apr 24, 2020 at 8:47 AM Andriy Gapon  > > wrote:
> > 
> > On 24/04/2020 17:29, Warner Losh wrote:  
> > >
> > >
> > > On Fri, Apr 24, 2020 at 1:49 AM Andriy Gapon  > >  
> >   
> > > >> wrote:
> > >
> > >     Author: avg
> > >     Date: Fri Apr 24 07:49:21 2020
> > >     New Revision: 360241
> > >     URL: https://svnweb.freebsd.org/changeset/base/360241
> > >
> > >     Log:
> > >       ig4: ensure that drivers always attach in correct order
> > >
> > >       Use DRIVER_MODULE_ORDERED(SI_ORDER_ANY) so that ig4's
> > >ACPI attachment happens after iicbus and acpi_iicbus drivers
> > >are registered.
> > >
> > >       I have seen a problem where iicbus attached under ig4
> > >instead of acpi_iicbus when ig4.ko was loaded with kldload.  I
> > >believe that that happened because ig4 driver was a first
> > >driver to register, it attached and created an iicbus child.
> > >Then iicbus driver was registered and, since it was the only
> > >driver that could attach to the iicbus child device, it did
> > >exactly that.  After that acpi_iicbus driver was registered.
> > >It would be able to attach to the iicbus device, but it was
> > >already attached, so nothing happened.
> > >
> > >
> > > Can you post more details of which devices are affected? From
> > > the description and the patch, I don't see how this could fix
> > > things.  
> > 
> > I think I listed them all: ig4iic with acpi attachment, iicbus
> > and acpi_iicbus. acpi
> >  \--- ig4iic
> >        \ iicbus vs acpi_iicbus
> > 
> > I tried to explain the problem and the fix in the commit
> > message.  If you want to discuss any specifics, let's continue with
> > specifics.  If there is anything unclear in my explanation, I can
> > clarify, but I need to understand what needs to be clarified.
> > 
> > 
> > That won't fix the stated problem.  
> 
> It will.  It does.  You made me write an essay to explain why :)
> 
> > If changing the module order fixes something,
> > it's the wrong fix. Which is why I asked to make sure I understood
> > the issue (it was unclear if it was at the level indicated, or for
> > the children of the iicbus).
> > 
> > iicbus returns BUS_PROBE_GENERIC (-100) from its probe routine,
> > while acpi_iicbus returns BUS_PROBE_DEFAULT (-20). This means that
> > acpi_iicbus should always win. So something else is going on. We
> > don't specify order on other devices except for some weird, special
> > needs drivers (this is not such a driver).  
> 
> This driver, along with all of other I2C controller drivers, has a
> particular quirk, so it can be called weird.
> 
> It does not matter what the probe routines return if one of the
> drivers is not added to "newbus" at all (even if its code is loaded).
>  Its probe method is not executed.  And that's what I tried to
> explain in the commit message.
> 
> Now, why this driver as well as all SMBus and I2C controller drivers
> are somewhat weird...  There is a multitude of drivers for SMBus and
> I2C controllers.  Those drivers have different names.  So, using
> newbus speak, smbus and iicbus drivers can attach to [newbus] devices
> under many different [newbus] buses.  For that reason, the
> corresponding DRIVER_MODULE declarations are not consolidated in
> smbus.c and iicbus.c; instead, they are spread over individual
> controller drivers.  So, loading of smbus or iicbus module does not
> result in a call to devclass_add_driver() that would register these
> drivers under some bus. And that's an unusual thing comparing to the
> most straightforward drivers.
> 
> Let's use ig4 as an example.
> Across its source files we had the following DRIVER_MODULE
> declarations: DRIVER_MODULE(ig4iic, acpi, ... -- in ig4_acpi.c
> DRIVER_MODULE(iicbus, ig4iic, ... -- in ig4_iic.c
> DRIVER_MODULE(acpi_iicbus, ig4iic, ... -- in ig4_iic.c
> The first one is needed to register ig4iic driver under acpi bus.
> Other two are needed to register iicbus and acpi_iicbus drivers under
> ig4iic bus. The order is not explicitly defined, so the corresponding
> declaration can be processed in any order when ig4.ko is loaded and
> so the corresponding devclass_add_driver() can be called in any order.
> 
> So, I observed in practice the scenario where the drivers were added
> in the written order.  First, ig4iic was added under acpi, it found
> the corresponding device, probed and attached to it.  In its attach
> method it added a new device named "iicbus" as a child.  Then, iicbus
> driver was added under ig4iic bus. That driver found the child device
> and attached to it.  Only then acpi_iicbus was added and it was too
> late to the party.
> 
> So, this is 

Re: svn commit: r360241 - head/sys/dev/ichiic

[Andriy Gapon]

On 24/04/2020 18:11, Warner Losh wrote:
> 
> 
> On Fri, Apr 24, 2020 at 8:47 AM Andriy Gapon  > wrote:
> 
> On 24/04/2020 17:29, Warner Losh wrote:
> >
> >
> > On Fri, Apr 24, 2020 at 1:49 AM Andriy Gapon  
> > >> wrote:
> >
> >     Author: avg
> >     Date: Fri Apr 24 07:49:21 2020
> >     New Revision: 360241
> >     URL: https://svnweb.freebsd.org/changeset/base/360241
> >
> >     Log:
> >       ig4: ensure that drivers always attach in correct order
> >
> >       Use DRIVER_MODULE_ORDERED(SI_ORDER_ANY) so that ig4's ACPI 
> attachment
> >       happens after iicbus and acpi_iicbus drivers are registered.
> >
> >       I have seen a problem where iicbus attached under ig4 instead of
> >       acpi_iicbus when ig4.ko was loaded with kldload.  I believe that 
> that
> >       happened because ig4 driver was a first driver to register, it 
> attached
> >       and created an iicbus child.  Then iicbus driver was registered 
> and,
> >       since it was the only driver that could attach to the iicbus child
> >       device, it did exactly that.  After that acpi_iicbus driver was
> >       registered.  It would be able to attach to the iicbus device, but 
> it was
> >       already attached, so nothing happened.
> >
> >
> > Can you post more details of which devices are affected? From the 
> description
> > and the patch, I don't see how this could fix things.
> 
> I think I listed them all: ig4iic with acpi attachment, iicbus and 
> acpi_iicbus.
> acpi
>  \--- ig4iic
>        \ iicbus vs acpi_iicbus
> 
> I tried to explain the problem and the fix in the commit message.  If you 
> want
> to discuss any specifics, let's continue with specifics.  If there is 
> anything
> unclear in my explanation, I can clarify, but I need to understand what 
> needs to
> be clarified.
> 
> 
> That won't fix the stated problem.

It will.  It does.  You made me write an essay to explain why :)

> If changing the module order fixes something,
> it's the wrong fix. Which is why I asked to make sure I understood the issue 
> (it
> was unclear if it was at the level indicated, or for the children of the 
> iicbus).
> 
> iicbus returns BUS_PROBE_GENERIC (-100) from its probe routine, while
> acpi_iicbus returns BUS_PROBE_DEFAULT (-20). This means that acpi_iicbus 
> should
> always win. So something else is going on. We don't specify order on other
> devices except for some weird, special needs drivers (this is not such a 
> driver).

This driver, along with all of other I2C controller drivers, has a particular
quirk, so it can be called weird.

It does not matter what the probe routines return if one of the drivers is not
added to "newbus" at all (even if its code is loaded).  Its probe method is not
executed.  And that's what I tried to explain in the commit message.

Now, why this driver as well as all SMBus and I2C controller drivers are
somewhat weird...  There is a multitude of drivers for SMBus and I2C
controllers.  Those drivers have different names.  So, using newbus speak, smbus
and iicbus drivers can attach to [newbus] devices under many different [newbus]
buses.  For that reason, the corresponding DRIVER_MODULE declarations are not
consolidated in smbus.c and iicbus.c; instead, they are spread over individual
controller drivers.  So, loading of smbus or iicbus module does not result in a
call to devclass_add_driver() that would register these drivers under some bus.
And that's an unusual thing comparing to the most straightforward drivers.

Let's use ig4 as an example.
Across its source files we had the following DRIVER_MODULE declarations:
DRIVER_MODULE(ig4iic, acpi, ... -- in ig4_acpi.c
DRIVER_MODULE(iicbus, ig4iic, ... -- in ig4_iic.c
DRIVER_MODULE(acpi_iicbus, ig4iic, ... -- in ig4_iic.c
The first one is needed to register ig4iic driver under acpi bus.  Other two are
needed to register iicbus and acpi_iicbus drivers under ig4iic bus.
The order is not explicitly defined, so the corresponding declaration can be
processed in any order when ig4.ko is loaded and so the corresponding
devclass_add_driver() can be called in any order.

So, I observed in practice the scenario where the drivers were added in the
written order.  First, ig4iic was added under acpi, it found the corresponding
device, probed and attached to it.  In its attach method it added a new device
named "iicbus" as a child.  Then, iicbus driver was added under ig4iic bus.
That driver found the child device and attached to it.  Only then acpi_iicbus
was added and it was too late to the party.

So, this is really about an order in which DRIVER_MODULE-s (which translate to
sysinit-s) _within a kld_ are processed.  Essentially, about an order of objects
in the corresponding section of a loadable ELF object. 

svn commit: r360269 - head/lib/libpmc/pmu-events/arch/x86

[Alexander Motin]

Author: mav
Date: Fri Apr 24 16:05:35 2020
New Revision: 360269
URL: https://svnweb.freebsd.org/changeset/base/360269

Log:
  Map family 0x5F (Denverton) to goldmont.
  
  According to the 325462-071US document, they should be the same.
  
  MFC after:1 week

Modified:
  head/lib/libpmc/pmu-events/arch/x86/mapfile.csv

Modified: head/lib/libpmc/pmu-events/arch/x86/mapfile.csv
==
--- head/lib/libpmc/pmu-events/arch/x86/mapfile.csv Fri Apr 24 15:27:56 
2020(r360268)
+++ head/lib/libpmc/pmu-events/arch/x86/mapfile.csv Fri Apr 24 16:05:35 
2020(r360269)
@@ -9,6 +9,7 @@ GenuineIntel-6-27,v4,bonnell,core
 GenuineIntel-6-36,v4,bonnell,core
 GenuineIntel-6-35,v4,bonnell,core
 GenuineIntel-6-5C,v8,goldmont,core
+GenuineIntel-6-5F,v8,goldmont,core
 GenuineIntel-6-7A,v1,goldmontplus,core
 GenuineIntel-6-3C,v24,haswell,core
 GenuineIntel-6-45,v24,haswell,core
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r360241 - head/sys/dev/ichiic

[Warner Losh]

On Fri, Apr 24, 2020 at 8:47 AM Andriy Gapon  wrote:

> On 24/04/2020 17:29, Warner Losh wrote:
> >
> >
> > On Fri, Apr 24, 2020 at 1:49 AM Andriy Gapon  > > wrote:
> >
> > Author: avg
> > Date: Fri Apr 24 07:49:21 2020
> > New Revision: 360241
> > URL: https://svnweb.freebsd.org/changeset/base/360241
> >
> > Log:
> >   ig4: ensure that drivers always attach in correct order
> >
> >   Use DRIVER_MODULE_ORDERED(SI_ORDER_ANY) so that ig4's ACPI
> attachment
> >   happens after iicbus and acpi_iicbus drivers are registered.
> >
> >   I have seen a problem where iicbus attached under ig4 instead of
> >   acpi_iicbus when ig4.ko was loaded with kldload.  I believe that
> that
> >   happened because ig4 driver was a first driver to register, it
> attached
> >   and created an iicbus child.  Then iicbus driver was registered
> and,
> >   since it was the only driver that could attach to the iicbus child
> >   device, it did exactly that.  After that acpi_iicbus driver was
> >   registered.  It would be able to attach to the iicbus device, but
> it was
> >   already attached, so nothing happened.
> >
> >
> > Can you post more details of which devices are affected? From the
> description
> > and the patch, I don't see how this could fix things.
>
> I think I listed them all: ig4iic with acpi attachment, iicbus and
> acpi_iicbus.
> acpi
>  \--- ig4iic
>\ iicbus vs acpi_iicbus
>
> I tried to explain the problem and the fix in the commit message.  If you
> want
> to discuss any specifics, let's continue with specifics.  If there is
> anything
> unclear in my explanation, I can clarify, but I need to understand what
> needs to
> be clarified.
>

That won't fix the stated problem. If changing the module order fixes
something, it's the wrong fix. Which is why I asked to make sure I
understood the issue (it was unclear if it was at the level indicated, or
for the children of the iicbus).

iicbus returns BUS_PROBE_GENERIC (-100) from its probe routine, while
acpi_iicbus returns BUS_PROBE_DEFAULT (-20). This means that acpi_iicbus
should always win. So something else is going on. We don't specify order on
other devices except for some weird, special needs drivers (this is not
such a driver).

Unless I'm mistaken, the real problem is that the following line is missing
instead.
MODULE_DEPEND(ig4iic, acpi_iicbus, 1, 1, 1);
which makes the module dependencies explicit. Can you add that to
ig4_acpi.c, revert your change and see if that works? It will ensure that
the acpi_iicbus driver is loaded first. If things break because it isn't,
it sounds like a hard dependency for ig4. Since we're already pulling in
acpi, that doesn't seem unreasonable to me.

Warner


>
> >   MFC after:2 weeks
> >
> > Modified:
> >   head/sys/dev/ichiic/ig4_acpi.c
> >
> > Modified: head/sys/dev/ichiic/ig4_acpi.c
> >
>  
> ==
> > --- head/sys/dev/ichiic/ig4_acpi.c  Fri Apr 24 05:05:58 2020
>
> > (r360240)
> > +++ head/sys/dev/ichiic/ig4_acpi.c  Fri Apr 24 07:49:21 2020
>
> > (r360241)
> > @@ -192,5 +192,6 @@ static driver_t ig4iic_acpi_driver = {
> > sizeof(struct ig4iic_softc),
> >  };
> >
> > -DRIVER_MODULE(ig4iic, acpi, ig4iic_acpi_driver, ig4iic_devclass, 0,
> 0);
> > +DRIVER_MODULE_ORDERED(ig4iic, acpi, ig4iic_acpi_driver,
> ig4iic_devclass, 0, 0,
> > +SI_ORDER_ANY);
> >  MODULE_DEPEND(ig4iic, acpi, 1, 1, 1);
> >
>
>
> --
> Andriy Gapon
>
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r360266 - head/sys/dev/hwpmc

[Alexander Motin]

Author: mav
Date: Fri Apr 24 15:09:30 2020
New Revision: 360266
URL: https://svnweb.freebsd.org/changeset/base/360266

Log:
  Add family 0x5F (Denverton) to PMC_CPU_INTEL_ATOM_GOLDMONT.
  
  According to the 325462-071US document, they should be the same.
  
  MFC after:1 week

Modified:
  head/sys/dev/hwpmc/hwpmc_intel.c

Modified: head/sys/dev/hwpmc/hwpmc_intel.c
==
--- head/sys/dev/hwpmc/hwpmc_intel.cFri Apr 24 15:02:05 2020
(r360265)
+++ head/sys/dev/hwpmc/hwpmc_intel.cFri Apr 24 15:09:30 2020
(r360266)
@@ -204,6 +204,7 @@ pmc_intel_initialize(void)
nclasses = 3;
break;
case 0x5C:  /* Per Intel document 325462-071US 10/2019. */
+   case 0x5F:
cputype = PMC_CPU_INTEL_ATOM_GOLDMONT;
nclasses = 3;
break;
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r360263 - head/usr.sbin/bluetooth/hccontrol

[Hans Petter Selasky]

Author: hselasky
Date: Fri Apr 24 14:53:55 2020
New Revision: 360263
URL: https://svnweb.freebsd.org/changeset/base/360263

Log:
  Rename two commands to match the Bluetooth specification in hccontrol(8).
  Fix some bad spelling while at it.
  
  Submitted by: Marc Veldman 
  PR:   245868
  MFC after:1 week
  Sponsored by: Mellanox Technologies

Modified:
  head/usr.sbin/bluetooth/hccontrol/host_controller_baseband.c

Modified: head/usr.sbin/bluetooth/hccontrol/host_controller_baseband.c
==
--- head/usr.sbin/bluetooth/hccontrol/host_controller_baseband.cFri Apr 
24 14:47:55 2020(r360262)
+++ head/usr.sbin/bluetooth/hccontrol/host_controller_baseband.cFri Apr 
24 14:53:55 2020(r360263)
@@ -1491,7 +1491,7 @@ hci_write_page_scan_mode(int s, int argc, char **argv)
 } /* hci_write_page_scan_mode */
 
 static int
-hci_read_le_host_supported_command(int s, int argc, char **argv) 
+hci_read_le_host_support(int s, int argc, char **argv) 
 {
ng_hci_read_le_host_supported_rp rp;
int n;
@@ -1508,13 +1508,13 @@ hci_read_le_host_supported_command(int s, int argc, ch
}
 
fprintf(stdout, "LE Host support: %#02x\n", rp.le_supported_host);
-   fprintf(stdout, "Simulateneouse LE Host : %#02x\n", 
rp.simultaneous_le_host);
+   fprintf(stdout, "Simultaneous LE Host : %#02x\n", 
rp.simultaneous_le_host);
 
return (OK);

 }
 static int
-hci_write_le_host_supported_command(int s, int argc, char **argv) 
+hci_write_le_host_support(int s, int argc, char **argv) 
 {
ng_hci_write_le_host_supported_cp cp;
ng_hci_write_le_host_supported_rp rp;
@@ -1948,14 +1948,14 @@ struct hci_command  
host_controller_baseband_commands[]
 _write_page_scan_mode
 },
 {
-"read_le_host_supported_command",  \
-"Read if this host is in le supported mode and stimulatenouse le supported 
mode",
-_read_le_host_supported_command,
+"read_le_host_support",\
+"Read if this host is in LE supported mode and simultaneous LE supported mode",
+_read_le_host_support,
 },  
 {
-"write_le_host_supported_command", \
-"write_le_host_supported_command le_host[0|1] stimultajeous_le[0|1]",
-_write_le_host_supported_command,
+"write_le_host_support",   \
+"write_le_host_support le_host[0|1] simultaneous_le[0|1]",
+_write_le_host_support,
 },  
 
 { NULL, }
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r360241 - head/sys/dev/ichiic

[Andriy Gapon]

On 24/04/2020 17:29, Warner Losh wrote:
> 
> 
> On Fri, Apr 24, 2020 at 1:49 AM Andriy Gapon  > wrote:
> 
> Author: avg
> Date: Fri Apr 24 07:49:21 2020
> New Revision: 360241
> URL: https://svnweb.freebsd.org/changeset/base/360241
> 
> Log:
>   ig4: ensure that drivers always attach in correct order
> 
>   Use DRIVER_MODULE_ORDERED(SI_ORDER_ANY) so that ig4's ACPI attachment
>   happens after iicbus and acpi_iicbus drivers are registered.
> 
>   I have seen a problem where iicbus attached under ig4 instead of
>   acpi_iicbus when ig4.ko was loaded with kldload.  I believe that that
>   happened because ig4 driver was a first driver to register, it attached
>   and created an iicbus child.  Then iicbus driver was registered and,
>   since it was the only driver that could attach to the iicbus child
>   device, it did exactly that.  After that acpi_iicbus driver was
>   registered.  It would be able to attach to the iicbus device, but it was
>   already attached, so nothing happened.
> 
> 
> Can you post more details of which devices are affected? From the description
> and the patch, I don't see how this could fix things.

I think I listed them all: ig4iic with acpi attachment, iicbus and acpi_iicbus.
acpi
 \--- ig4iic
   \ iicbus vs acpi_iicbus

I tried to explain the problem and the fix in the commit message.  If you want
to discuss any specifics, let's continue with specifics.  If there is anything
unclear in my explanation, I can clarify, but I need to understand what needs to
be clarified.


>   MFC after:    2 weeks
> 
> Modified:
>   head/sys/dev/ichiic/ig4_acpi.c
> 
> Modified: head/sys/dev/ichiic/ig4_acpi.c
> 
> ==
> --- head/sys/dev/ichiic/ig4_acpi.c      Fri Apr 24 05:05:58 2020       
> (r360240)
> +++ head/sys/dev/ichiic/ig4_acpi.c      Fri Apr 24 07:49:21 2020       
> (r360241)
> @@ -192,5 +192,6 @@ static driver_t ig4iic_acpi_driver = {
>         sizeof(struct ig4iic_softc),
>  };
> 
> -DRIVER_MODULE(ig4iic, acpi, ig4iic_acpi_driver, ig4iic_devclass, 0, 0);
> +DRIVER_MODULE_ORDERED(ig4iic, acpi, ig4iic_acpi_driver, ig4iic_devclass, 
> 0, 0,
> +    SI_ORDER_ANY);
>  MODULE_DEPEND(ig4iic, acpi, 1, 1, 1);
> 


-- 
Andriy Gapon
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r360241 - head/sys/dev/ichiic

[Warner Losh]

On Fri, Apr 24, 2020 at 1:49 AM Andriy Gapon  wrote:

> Author: avg
> Date: Fri Apr 24 07:49:21 2020
> New Revision: 360241
> URL: https://svnweb.freebsd.org/changeset/base/360241
>
> Log:
>   ig4: ensure that drivers always attach in correct order
>
>   Use DRIVER_MODULE_ORDERED(SI_ORDER_ANY) so that ig4's ACPI attachment
>   happens after iicbus and acpi_iicbus drivers are registered.
>
>   I have seen a problem where iicbus attached under ig4 instead of
>   acpi_iicbus when ig4.ko was loaded with kldload.  I believe that that
>   happened because ig4 driver was a first driver to register, it attached
>   and created an iicbus child.  Then iicbus driver was registered and,
>   since it was the only driver that could attach to the iicbus child
>   device, it did exactly that.  After that acpi_iicbus driver was
>   registered.  It would be able to attach to the iicbus device, but it was
>   already attached, so nothing happened.
>

Can you post more details of which devices are affected? From the
description and the patch, I don't see how this could fix things.

Warner


>   MFC after:2 weeks
>
> Modified:
>   head/sys/dev/ichiic/ig4_acpi.c
>
> Modified: head/sys/dev/ichiic/ig4_acpi.c
>
> ==
> --- head/sys/dev/ichiic/ig4_acpi.c  Fri Apr 24 05:05:58 2020
> (r360240)
> +++ head/sys/dev/ichiic/ig4_acpi.c  Fri Apr 24 07:49:21 2020
> (r360241)
> @@ -192,5 +192,6 @@ static driver_t ig4iic_acpi_driver = {
> sizeof(struct ig4iic_softc),
>  };
>
> -DRIVER_MODULE(ig4iic, acpi, ig4iic_acpi_driver, ig4iic_devclass, 0, 0);
> +DRIVER_MODULE_ORDERED(ig4iic, acpi, ig4iic_acpi_driver, ig4iic_devclass,
> 0, 0,
> +SI_ORDER_ANY);
>  MODULE_DEPEND(ig4iic, acpi, 1, 1, 1);
>
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r360260 - in head/stand: efi/loader/arch/amd64 i386/libi386 userboot/userboot

[Mark Johnston]

Author: markj
Date: Fri Apr 24 13:53:40 2020
New Revision: 360260
URL: https://svnweb.freebsd.org/changeset/base/360260

Log:
  Stop setting PG_U in bootstrap mappings.
  
  These mappings are never visible to userspace as they get replaced when
  the amd64 pmap is bootstrapped, but there is no need to set PG_U in the
  first place.
  
  Reviewed by:  alc, kib
  MFC after:1 week
  Sponsored by: The FreeBSD Foundation
  Differential Revision:https://reviews.freebsd.org/D24547

Modified:
  head/stand/efi/loader/arch/amd64/elf64_freebsd.c
  head/stand/i386/libi386/elf64_freebsd.c
  head/stand/userboot/userboot/elf64_freebsd.c

Modified: head/stand/efi/loader/arch/amd64/elf64_freebsd.c
==
--- head/stand/efi/loader/arch/amd64/elf64_freebsd.cFri Apr 24 13:49:51 
2020(r360259)
+++ head/stand/efi/loader/arch/amd64/elf64_freebsd.cFri Apr 24 13:53:40 
2020(r360260)
@@ -172,15 +172,15 @@ elf64_exec(struct preloaded_file *fp)
for (i = 0; i < 512; i++) {
/* Each slot of the L4 pages points to the same L3 page. */
PT4[i] = (pml4_entry_t)PT3;
-   PT4[i] |= PG_V | PG_RW | PG_U;
+   PT4[i] |= PG_V | PG_RW;
 
/* Each slot of the L3 pages points to the same L2 page. */
PT3[i] = (pdp_entry_t)PT2;
-   PT3[i] |= PG_V | PG_RW | PG_U;
+   PT3[i] |= PG_V | PG_RW;
 
/* The L2 page slots are mapped with 2MB pages for 1GB. */
PT2[i] = i * (2 * 1024 * 1024);
-   PT2[i] |= PG_V | PG_RW | PG_PS | PG_U;
+   PT2[i] |= PG_V | PG_RW | PG_PS;
}
 
printf("Start @ 0x%lx ...\n", ehdr->e_entry);

Modified: head/stand/i386/libi386/elf64_freebsd.c
==
--- head/stand/i386/libi386/elf64_freebsd.c Fri Apr 24 13:49:51 2020
(r360259)
+++ head/stand/i386/libi386/elf64_freebsd.c Fri Apr 24 13:53:40 2020
(r360260)
@@ -48,7 +48,6 @@ struct file_format amd64_elf_obj = { elf64_obj_loadfil
 
 #define PG_V   0x001
 #define PG_RW  0x002
-#define PG_U   0x004
 #define PG_PS  0x080
 
 typedef uint64_t p4_entry_t;
@@ -96,15 +95,15 @@ elf64_exec(struct preloaded_file *fp)
 for (i = 0; i < 512; i++) {
/* Each slot of the level 4 pages points to the same level 3 page */
PT4[i] = (p4_entry_t)VTOP((uintptr_t)[0]);
-   PT4[i] |= PG_V | PG_RW | PG_U;
+   PT4[i] |= PG_V | PG_RW;
 
/* Each slot of the level 3 pages points to the same level 2 page */
PT3[i] = (p3_entry_t)VTOP((uintptr_t)[0]);
-   PT3[i] |= PG_V | PG_RW | PG_U;
+   PT3[i] |= PG_V | PG_RW;
 
/* The level 2 page slots are mapped with 2MB pages for 1GB. */
PT2[i] = i * (2 * 1024 * 1024);
-   PT2[i] |= PG_V | PG_RW | PG_PS | PG_U;
+   PT2[i] |= PG_V | PG_RW | PG_PS;
 }
 
 entry_lo = ehdr->e_entry & 0x;

Modified: head/stand/userboot/userboot/elf64_freebsd.c
==
--- head/stand/userboot/userboot/elf64_freebsd.cFri Apr 24 13:49:51 
2020(r360259)
+++ head/stand/userboot/userboot/elf64_freebsd.cFri Apr 24 13:53:40 
2020(r360260)
@@ -60,7 +60,6 @@ struct file_format amd64_elf_obj = { elf64_obj_loadfil
 
 #define PG_V   0x001
 #define PG_RW  0x002
-#define PG_U   0x004
 #define PG_PS  0x080
 
 typedef uint64_t p4_entry_t;
@@ -127,15 +126,15 @@ elf64_exec(struct preloaded_file *fp)
for (i = 0; i < 512; i++) {
/* Each slot of the level 4 pages points to the same level 3 
page */
PT4[i] = (p4_entry_t) 0x3000;
-   PT4[i] |= PG_V | PG_RW | PG_U;
+   PT4[i] |= PG_V | PG_RW;
 
/* Each slot of the level 3 pages points to the same level 2 
page */
PT3[i] = (p3_entry_t) 0x4000;
-   PT3[i] |= PG_V | PG_RW | PG_U;
+   PT3[i] |= PG_V | PG_RW;
 
/* The level 2 page slots are mapped with 2MB pages for 1GB. */
PT2[i] = i * (2 * 1024 * 1024);
-   PT2[i] |= PG_V | PG_RW | PG_PS | PG_U;
+   PT2[i] |= PG_V | PG_RW | PG_PS;
}
 
 #ifdef DEBUG
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r360251 - head

[Kyle Evans]

Author: kevans
Date: Fri Apr 24 12:57:03 2020
New Revision: 360251
URL: https://svnweb.freebsd.org/changeset/base/360251

Log:
  UPDATING: Fix the date of the closefrom(2) entry
  
  Apologies; my internal calendar says it's still February, but that doesn't
  seem to match reality where we've apparently advanced two months.

Modified:
  head/UPDATING

Modified: head/UPDATING
==
--- head/UPDATING   Fri Apr 24 12:54:35 2020(r360250)
+++ head/UPDATING   Fri Apr 24 12:57:03 2020(r360251)
@@ -26,7 +26,7 @@ NOTE TO PEOPLE WHO THINK THAT FreeBSD 13.x IS SLOW:
disable the most expensive debugging functionality run
"ln -s 'abort:false,junk:false' /etc/malloc.conf".)
 
-20200224:
+20200424:
closefrom(2) has been moved under COMPAT12, and replaced in libc with a
stub that calls close_range(2).  If using a custom kernel configuration,
you may want to ensure that the COMPAT_FREEBSD12 option is included, as
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r360250 - head

[Kyle Evans]

Author: kevans
Date: Fri Apr 24 12:54:35 2020
New Revision: 360250
URL: https://svnweb.freebsd.org/changeset/base/360250

Log:
  UPDATING: add a note about closefrom(2) marked COMPAT12
  
  Some of the consumers in-base may make it enticing enough to ensure that
  COMPAT_FREEBSD12, which is notably a fairly light option at the moment, is
  included in custom kernel configs.
  
  Suggested by: netchild
  Casualty: mail jail

Modified:
  head/UPDATING

Modified: head/UPDATING
==
--- head/UPDATING   Fri Apr 24 11:03:15 2020(r360249)
+++ head/UPDATING   Fri Apr 24 12:54:35 2020(r360250)
@@ -26,6 +26,13 @@ NOTE TO PEOPLE WHO THINK THAT FreeBSD 13.x IS SLOW:
disable the most expensive debugging functionality run
"ln -s 'abort:false,junk:false' /etc/malloc.conf".)
 
+20200224:
+   closefrom(2) has been moved under COMPAT12, and replaced in libc with a
+   stub that calls close_range(2).  If using a custom kernel configuration,
+   you may want to ensure that the COMPAT_FREEBSD12 option is included, as
+   a slightly older -CURRENT userland and older FreeBSD userlands may not
+   be functional without closefrom(2).
+
 20200414:
Upstream DTS from Linux 5.6 was merged and they now have the SID
and THS (Secure ID controller and THermal Sensor) node present.
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r360249 - head/sys/dev/pci

[Andrew Turner]

Author: andrew
Date: Fri Apr 24 11:03:15 2020
New Revision: 360249
URL: https://svnweb.freebsd.org/changeset/base/360249

Log:
  Remove PCI_IO_WINDOW_OFFSET from the pci host generic fdt attachment.
  
  It doesn't seem to be needed, and breaks booting under bhyve/arm64.
  
  Discussed with:   br
  MFC after:2 weeks
  Sponsored by: Innovate UK

Modified:
  head/sys/dev/pci/pci_host_generic_fdt.c

Modified: head/sys/dev/pci/pci_host_generic_fdt.c
==
--- head/sys/dev/pci/pci_host_generic_fdt.c Fri Apr 24 10:20:54 2020
(r360248)
+++ head/sys/dev/pci/pci_host_generic_fdt.c Fri Apr 24 11:03:15 2020
(r360249)
@@ -65,8 +65,6 @@ __FBSDID("$FreeBSD$");
 
 #include "pcib_if.h"
 
-#definePCI_IO_WINDOW_OFFSET0x1000
-
 #defineSPACE_CODE_SHIFT24
 #defineSPACE_CODE_MASK 0x3
 #defineSPACE_CODE_IO_SPACE 0x1
@@ -170,8 +168,7 @@ pci_host_generic_attach(device_t dev)
pci_base, pci_base + size - 1);
} else if (sc->base.ranges[tuple].flags & FLAG_IO) {
error = rman_manage_region(>base.io_rman,
-   pci_base + PCI_IO_WINDOW_OFFSET,
-   pci_base + PCI_IO_WINDOW_OFFSET + size - 1);
+   pci_base, pci_base + size - 1);
} else
continue;
if (error) {
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r360248 - head/sys/crypto/ccp

[Andriy Gapon]

Author: avg
Date: Fri Apr 24 10:20:54 2020
New Revision: 360248
URL: https://svnweb.freebsd.org/changeset/base/360248

Log:
  ccp: add a new hardware ID, found on AMD Ryzen 3 3200U
  
  pciconf reports the device as:
  Family 17h (Models 10h-1fh) Platform Security Processor
  
  dmesg:
  ccp0:  mem 0xfe50-0xfe5f,0xfe68c000-0xfe68dfff at device 
0.2 on pci4
  crypto: assign ccp0 driver id 1, flags 0x100
  
  MFC after:1 week

Modified:
  head/sys/crypto/ccp/ccp.c

Modified: head/sys/crypto/ccp/ccp.c
==
--- head/sys/crypto/ccp/ccp.c   Fri Apr 24 10:03:11 2020(r360247)
+++ head/sys/crypto/ccp/ccp.c   Fri Apr 24 10:20:54 2020(r360248)
@@ -78,6 +78,7 @@ static struct pciid {
 } ccp_ids[] = {
{ 0x14561022, "AMD CCP-5a" },
{ 0x14681022, "AMD CCP-5b" },
+   { 0x15df1022, "AMD CCP-5a" },
 };
 
 static struct random_source random_ccp = {
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r360247 - head/stand

[Andrew Turner]

Author: andrew
Date: Fri Apr 24 10:03:11 2020
New Revision: 360247
URL: https://svnweb.freebsd.org/changeset/base/360247

Log:
  Build the arm64 loader with -ffixed-x18
  
  This stops the compiler from using the x18 register. Some UEFI
  implementations assume this will be preserved when calling the Boot
  Services.
  
  MFC after:2 weeks
  Sponsored by: Innovate UK

Modified:
  head/stand/defs.mk

Modified: head/stand/defs.mk
==
--- head/stand/defs.mk  Fri Apr 24 09:32:20 2020(r360246)
+++ head/stand/defs.mk  Fri Apr 24 10:03:11 2020(r360247)
@@ -119,7 +119,7 @@ SSP_CFLAGS=
 # currently has no /boot/loader, but may soon.
 CFLAGS+=   -ffreestanding ${CFLAGS_NO_SIMD}
 .if ${MACHINE_CPUARCH} == "aarch64"
-CFLAGS+=   -mgeneral-regs-only -fPIC
+CFLAGS+=   -mgeneral-regs-only -ffixed-x18 -fPIC
 .elif ${MACHINE_CPUARCH} == "riscv"
 CFLAGS+=   -march=rv64imac -mabi=lp64
 .else
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r360246 - head/sys/dev/acpica

[Andriy Gapon]

Author: avg
Date: Fri Apr 24 09:32:20 2020
New Revision: 360246
URL: https://svnweb.freebsd.org/changeset/base/360246

Log:
  acpi_video: fix a crash in detach with an LCD output
  
  The crash happened because of a video output object was removed from a
  wrong container, crt_units instead of lcd_units.
  
  MFC after:1 week

Modified:
  head/sys/dev/acpica/acpi_video.c

Modified: head/sys/dev/acpica/acpi_video.c
==
--- head/sys/dev/acpica/acpi_video.cFri Apr 24 08:31:31 2020
(r360245)
+++ head/sys/dev/acpica/acpi_video.cFri Apr 24 09:32:20 2020
(r360246)
@@ -642,7 +642,10 @@ acpi_video_vo_destroy(struct acpi_video_output *vo)
 
switch (vo->adr & DOD_DEVID_MASK) {
case DOD_DEVID_MONITOR:
-   voqh = _units;
+   if ((vo->adr & DOD_DEVID_MASK_FULL) == DOD_DEVID_LCD)
+   voqh = _units;
+   else
+   voqh = _units;
break;
case DOD_DEVID_TV:
voqh = _units;
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r360243 - head/usr.sbin/bluetooth/hccontrol

[Hans Petter Selasky]

Author: hselasky
Date: Fri Apr 24 08:07:59 2020
New Revision: 360243
URL: https://svnweb.freebsd.org/changeset/base/360243

Log:
  Add support for LE advertising to hccontrol(8).
  
  Submitted by: Marc Veldman 
  PR:   245848
  MFC after:1 week
  Sponsored by: Mellanox Technologies

Modified:
  head/usr.sbin/bluetooth/hccontrol/hccontrol.8
  head/usr.sbin/bluetooth/hccontrol/le.c

Modified: head/usr.sbin/bluetooth/hccontrol/hccontrol.8
==
--- head/usr.sbin/bluetooth/hccontrol/hccontrol.8   Fri Apr 24 07:55:39 
2020(r360242)
+++ head/usr.sbin/bluetooth/hccontrol/hccontrol.8   Fri Apr 24 08:07:59 
2020(r360243)
@@ -25,7 +25,7 @@
 .\" $Id: hccontrol.8,v 1.6 2003/08/06 21:26:38 max Exp $
 .\" $FreeBSD$
 .\"
-.Dd February 7, 2015
+.Dd April 24, 2020
 .Dt HCCONTROL 8
 .Os
 .Sh NAME
@@ -133,6 +133,8 @@ are:
 .It Cm Write_Page_Scan_Period_Mode
 .It Cm Read_Page_Scan_Mode
 .It Cm Write_Page_Scan_Mode
+.It Cm Read_LE_Host_Support
+.It Cm Write_LE_Host_Support
 .It Cm Read_Local_Version_Information
 .It Cm Read_Local_Supported_Commands
 .It Cm Read_Local_Supported_Features
@@ -143,6 +145,15 @@ are:
 .It Cm Reset_Failed_Contact_Counter
 .It Cm Get_Link_Quality
 .It Cm Read_RSSI
+.It Cm LE_Read_Local_Supported_Features
+.It Cm LE_Set_Advertising_Parameters 
+.It Cm LE_Read_Advertising_Physical_Channel_Tx_Power 
+.It Cm LE_Set_Advertising_Data
+.It Cm LE_Set_Scan_Response_Data
+.It Cm LE_Set_Advertising_Enable
+.It Cm LE_Set_Scan_Parameters
+.It Cm LE_Set_Scan_Enable
+.It Cm LE_Read_Supported_States
 .El
 .Pp
 The currently supported node commands in
@@ -170,6 +181,18 @@ are:
 .It Cm Write_Node_Role_Switch
 .It Cm Read_Node_List
 .El
+.Sh EXAMPLES
+Make the blutooth LE host, ubt0hci, scannable through
+.Xr hccontrol 8 commands:
+.Pp
+.Bd -literal -offset indent
+hccontrol -n ubt0hci le_set_advertising_enable disable
+hccontrol -n ubt0hci le_set_advertising_param
+hccontrol -n ubt0hci le_read_advertising_channel_tx_power
+hccontrol -n ubt0hci le_set_advertising_data
+hccontrol -n ubt0hci le_set_scan_response -n FBSD_Host
+hccontrol -n ubt0hci le_set_advertising_enable enable
+.Ed
 .Sh EXIT STATUS
 .Ex -std
 .Sh SEE ALSO

Modified: head/usr.sbin/bluetooth/hccontrol/le.c
==
--- head/usr.sbin/bluetooth/hccontrol/le.c  Fri Apr 24 07:55:39 2020
(r360242)
+++ head/usr.sbin/bluetooth/hccontrol/le.c  Fri Apr 24 08:07:59 2020
(r360243)
@@ -57,6 +57,9 @@ static int le_read_local_supported_features(int s, int
 static int set_le_event_mask(int s, uint64_t mask);
 static int set_event_mask(int s, uint64_t mask);
 static int le_enable(int s, int argc, char *argv[]);
+static int le_set_advertising_enable(int s, int argc, char *argv[]);
+static int le_set_advertising_param(int s, int argc, char *argv[]);
+static int le_read_advertising_channel_tx_power(int s, int argc, char *argv[]);
 
 static int
 le_set_scan_param(int s, int argc, char *argv[])
@@ -339,6 +342,170 @@ int le_enable(int s, int argc, char *argv[])
return OK;
 }
 
+static int
+le_set_advertising_enable(int s, int argc, char *argv[])
+{
+   ng_hci_le_set_advertise_enable_cp cp;
+   ng_hci_le_set_advertise_enable_rp rp;
+   int n, enable = 0;
+
+   if (argc != 1)
+   return USAGE;
+ 
+   if (strcmp(argv[0], "enable") == 0)
+   enable = 1;
+   else if (strcmp(argv[0], "disable") != 0)
+   return USAGE;
+
+   n = sizeof(rp);
+   cp.advertising_enable = enable;
+   if (hci_request(s, NG_HCI_OPCODE(NG_HCI_OGF_LE,
+   NG_HCI_OCF_LE_SET_ADVERTISE_ENABLE), 
+   (void *), sizeof(cp), (void *), ) == ERROR)
+   return (ERROR);
+   
+   if (rp.status != 0x00) {
+   fprintf(stdout, "Status: %s [%#02x]\n", 
+   hci_status2str(rp.status), rp.status);
+   return (FAILED);
+   }
+fprintf(stdout, "LE Advertising %s\n", (enable ? "enabled" : 
"disabled"));
+
+   return (OK);
+}
+
+static int
+le_set_advertising_param(int s, int argc, char *argv[])
+{
+   ng_hci_le_set_advertising_parameters_cp cp;
+   ng_hci_le_set_advertising_parameters_rp rp;
+
+   int n, ch;
+
+   cp.advertising_interval_min = 0x800;
+   cp.advertising_interval_max = 0x800;
+   cp.advertising_type = 0;
+   cp.own_address_type = 0;
+   cp.direct_address_type = 0;
+
+   cp.advertising_channel_map = 7;
+   cp.advertising_filter_policy = 0;
+
+   optreset = 1;
+   optind = 0;
+   while ((ch = getopt(argc, argv , "m:M:t:o:p:a:c:f:")) != -1) {
+   switch(ch) {
+   case 'm':
+   cp.advertising_interval_min =
+   (uint16_t)(strtod(optarg, NULL)/0.625);
+   break;
+

svn commit: r360242 - head/sys/dev/iicbus

[Andriy Gapon]

Author: avg
Date: Fri Apr 24 07:55:39 2020
New Revision: 360242
URL: https://svnweb.freebsd.org/changeset/base/360242

Log:
  acpi_iicbus: set device description in the probe method
  
  Kernel prints the device announcement before the attach method is
  called, so if the correct description is not set by the probe method,
  then the announcement would have an incorrect one.
  
  MFC after:1 week

Modified:
  head/sys/dev/iicbus/acpi_iicbus.c

Modified: head/sys/dev/iicbus/acpi_iicbus.c
==
--- head/sys/dev/iicbus/acpi_iicbus.c   Fri Apr 24 07:49:21 2020
(r360241)
+++ head/sys/dev/iicbus/acpi_iicbus.c   Fri Apr 24 07:55:39 2020
(r360242)
@@ -573,6 +573,7 @@ acpi_iicbus_probe(device_t dev)
if (handle == NULL)
return (ENXIO);
 
+   device_set_desc(dev, "Philips I2C bus (ACPI-hinted)");
return (BUS_PROBE_DEFAULT);
 }
 
@@ -581,8 +582,6 @@ acpi_iicbus_attach(device_t dev)
 {
struct acpi_iicbus_softc *sc = device_get_softc(dev);
int error;
-
-   device_set_desc(dev, "Philips I2C bus (ACPI-hinted)");
 
if (ACPI_FAILURE(acpi_iicbus_enumerate_children(dev)))
device_printf(dev, "children enumeration failed\n");
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r360241 - head/sys/dev/ichiic

[Andriy Gapon]

Author: avg
Date: Fri Apr 24 07:49:21 2020
New Revision: 360241
URL: https://svnweb.freebsd.org/changeset/base/360241

Log:
  ig4: ensure that drivers always attach in correct order
  
  Use DRIVER_MODULE_ORDERED(SI_ORDER_ANY) so that ig4's ACPI attachment
  happens after iicbus and acpi_iicbus drivers are registered.
  
  I have seen a problem where iicbus attached under ig4 instead of
  acpi_iicbus when ig4.ko was loaded with kldload.  I believe that that
  happened because ig4 driver was a first driver to register, it attached
  and created an iicbus child.  Then iicbus driver was registered and,
  since it was the only driver that could attach to the iicbus child
  device, it did exactly that.  After that acpi_iicbus driver was
  registered.  It would be able to attach to the iicbus device, but it was
  already attached, so nothing happened.
  
  MFC after:2 weeks

Modified:
  head/sys/dev/ichiic/ig4_acpi.c

Modified: head/sys/dev/ichiic/ig4_acpi.c
==
--- head/sys/dev/ichiic/ig4_acpi.c  Fri Apr 24 05:05:58 2020
(r360240)
+++ head/sys/dev/ichiic/ig4_acpi.c  Fri Apr 24 07:49:21 2020
(r360241)
@@ -192,5 +192,6 @@ static driver_t ig4iic_acpi_driver = {
sizeof(struct ig4iic_softc),
 };
 
-DRIVER_MODULE(ig4iic, acpi, ig4iic_acpi_driver, ig4iic_devclass, 0, 0);
+DRIVER_MODULE_ORDERED(ig4iic, acpi, ig4iic_acpi_driver, ig4iic_devclass, 0, 0,
+SI_ORDER_ANY);
 MODULE_DEPEND(ig4iic, acpi, 1, 1, 1);
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r360233 - in head: contrib/jemalloc contrib/jemalloc/doc contrib/jemalloc/include/jemalloc contrib/jemalloc/include/jemalloc/internal contrib/jemalloc/src lib/libc/stdlib/jemalloc

[nonameless]

> Author: vangyzen
> Date: Thu Apr 23 23:57:43 2020
> New Revision: 360233
> URL: https://svnweb.freebsd.org/changeset/base/360233
> 
> Log:
> Update jemalloc to version 5.2.1
> 
> Revert r354606 to restore r data-ukrnet-code="354605">354605.
> 
> Apply one line from jemalloc commit d01b425e5d1e1 in hash_x86_128()
> to fix the build with gcc, which only allows a fallthrough attribute
> to appear before a case or default label.
> 
> Submitted by: jasone in r354605
> Discussed with: jasone
> Reviewed by: bdrewery
> MFC after: never, due to gcc 4.2.1
> Relnotes: yes
> Sponsored by: Dell EMC Isilon
> Differential Revision: https://reviews.freebsd.org/D24522
> 
> ...

Thank you!
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"