svn commit: r349168 - head/share/man/man4

2019-06-17 Thread Ian Lepore
Author: ian
Date: Tue Jun 18 04:32:19 2019
New Revision: 349168
URL: https://svnweb.freebsd.org/changeset/base/349168

Log:
  Add a pwmc(4) manpage.

Added:
  head/share/man/man4/pwmc.4   (contents, props changed)
Modified:
  head/share/man/man4/Makefile

Modified: head/share/man/man4/Makefile
==
--- head/share/man/man4/MakefileTue Jun 18 02:27:30 2019
(r349167)
+++ head/share/man/man4/MakefileTue Jun 18 04:32:19 2019
(r349168)
@@ -418,6 +418,7 @@ MAN=aac.4 \
pts.4 \
pty.4 \
puc.4 \
+   pwmc.4 \
${_qlxge.4} \
${_qlxgb.4} \
${_qlxgbe.4} \

Added: head/share/man/man4/pwmc.4
==
--- /dev/null   00:00:00 1970   (empty, because file is newly added)
+++ head/share/man/man4/pwmc.4  Tue Jun 18 04:32:19 2019(r349168)
@@ -0,0 +1,212 @@
+.\"
+.\" Copyright (c) 2019 Ian Lepore 
+.\"
+.\" Redistribution and use in source and binary forms, with or without
+.\" modification, are permitted provided that the following conditions
+.\" are met:
+.\"
+.\" 1. Redistributions of source code must retain the above copyright
+.\"notice, this list of conditions and the following disclaimer.
+.\" 2. Redistributions in binary form must reproduce the above copyright
+.\"notice, this list of conditions and the following disclaimer in the
+.\"documentation and/or other materials provided with the distribution.
+.\"
+.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
+.\" IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
+.\" OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
+.\" IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
+.\" INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+.\" NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+.\" DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+.\" THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+.\" (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
+.\" THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+.\"
+.\" $FreeBSD$
+.\"
+.Dd June 17, 2019
+.Dt PWMC 4
+.Os
+.Sh NAME
+.Nm pwmc
+.Nd PWM (Pulse Width Modulation) control device driver
+.Sh SYNOPSIS
+To compile this driver into the kernel,
+place the following lines in your
+kernel configuration file:
+.Bd -ragged -offset indent
+.Cd "device pwmbus"
+.Cd "device pwmc"
+.Ed
+.Pp
+Alternatively, to load the driver as a
+module at boot time, place the following line in
+.Xr loader.conf 5 :
+.Bd -literal -offset indent
+pwmc_load="YES"
+.Ed
+.Sh DESCRIPTION
+The
+.Nm
+driver provides device-control access to a channel of PWM hardware.
+Each instance of a
+.Nm
+device is associated with a single PWM output channel.
+.Pp
+Some PWM hardware is organized with multiple channels sharing a
+common clock or other resources.
+In such cases, a separate
+.Nm
+instance will exist for each channel, but changing the period or
+duty cycle of any one channel may affect other channels within the
+hardware which share the same resources.
+Consult the documentation for the underlying PWM hardware device driver
+for details on channels that share resources.
+.Pp
+An instance of
+.Nm
+creates a character device named
+.Pa /dev/pwm/pwmcX.Y
+where
+.Va X
+is a sequential number assigned to each PWM hardware controller
+as it is discovered by the system, and
+.Va Y
+is the channel number within that hardware controller.
+The driver can be configured to create aliases that point to the
+.Pa pwmcX.Y
+entries, in effect creating named channels.
+.Pp
+The
+.Nm
+driver provides control of a PWM channel with the following
+.Xr ioctl 2
+calls and data structures, defined in
+.In dev/pwm/pwmc.h :
+.Bl -tag -width indent
+.It Dv PWMGETSTATE Pq Vt "struct pwm_state"
+Retrieve the current state of the channel.
+.It Dv PWMSETSTATE Pq Vt "struct pwm_state"
+Set the current state of the channel.
+All parameters are updated on every call.
+To change just one of the values, use
+.Dv PWMGETSTATE
+to get the current state and then submit the same data back with
+just the appropriate value changed.
+.El
+.Pp
+The
+.Va pwm_state
+structure is defined as follows:
+.Bd -literal
+struct pwm_state {
+   u_int   period;
+   u_int   duty;
+   uint32_tflags;
+   boolenable;
+};
+.Ed
+.Pp
+.Bl -tag -width period
+.It Va period
+The duration, in nanoseconds, of one complete on-off cycle.
+.It Va duty
+The duration, in nanoseconds, of the on portion of one cycle.
+.It Va flags
+Flags that affect the output signal can be bitwise-ORed together.
+The following flags are currently defined:
+.Pp
+.Bl -tag -width PWM_POLARITY_INVERTED -compact
+.It Dv PWM_POLARITY_INVERTED
+Invert the 

svn commit: r349167 - head/usr.sbin/pwm

2019-06-17 Thread Ian Lepore
Author: ian
Date: Tue Jun 18 02:27:30 2019
New Revision: 349167
URL: https://svnweb.freebsd.org/changeset/base/349167

Log:
  Oops, it seems I left out the word 'cycle', fix it.
  
  Reported by:  rpokala@

Modified:
  head/usr.sbin/pwm/pwm.8

Modified: head/usr.sbin/pwm/pwm.8
==
--- head/usr.sbin/pwm/pwm.8 Tue Jun 18 01:15:00 2019(r349166)
+++ head/usr.sbin/pwm/pwm.8 Tue Jun 18 02:27:30 2019(r349167)
@@ -74,7 +74,7 @@ Show the configuration of the PWM channel.
 .It Fl D
 Disable the PWM channel.
 .It Fl d Ar duty
-Configure the duty (in nanoseconds or percentage) of the PWM channel.
+Configure the duty cycle (in nanoseconds or percentage) of the PWM channel.
 Duty is the portion of the
 .Ar period
 during which the signal is asserted.
___
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: r349166 - head/usr.sbin/pwm

2019-06-17 Thread Ian Lepore
Author: ian
Date: Tue Jun 18 01:15:00 2019
New Revision: 349166
URL: https://svnweb.freebsd.org/changeset/base/349166

Log:
  Rearrange the argument checking and processing so that enable and disable
  can be combined with configuring the period and duty cycle (the same ioctl
  sets all 3 values at once, so there's no reason to require the user to run
  the program twice to get all 3 things set).

Modified:
  head/usr.sbin/pwm/pwm.8
  head/usr.sbin/pwm/pwm.c

Modified: head/usr.sbin/pwm/pwm.8
==
--- head/usr.sbin/pwm/pwm.8 Tue Jun 18 00:17:10 2019(r349165)
+++ head/usr.sbin/pwm/pwm.8 Tue Jun 18 01:15:00 2019(r349166)
@@ -31,19 +31,12 @@
 .Sh SYNOPSIS
 .Nm
 .Op Fl f Ar device
-.Fl E
-.Nm
-.Op Fl f Ar device
-.Fl D
-.Nm
-.Op Fl f Ar device
 .Fl C
 .Nm
 .Op Fl f Ar device
-.Fl p Ar period
-.Nm
-.Op Fl f Ar device
-.Fl d Ar duty
+.Op Fl D | Fl E
+.Op Fl p Ar period
+.Op Fl d Ar duty
 .Sh DESCRIPTION
 The
 .Nm
@@ -76,19 +69,19 @@ is used.
 If an unqualified name is provided,
 .Pa /dev/pwm
 is automatically prepended.
-.It Fl E
-Enable the PWM channel.
-.It Fl D
-Disable the PWM channel.
 .It Fl C
 Show the configuration of the PWM channel.
-.It Fl p Ar period
-Configure the period (in nanoseconds) of the PWM channel
+.It Fl D
+Disable the PWM channel.
 .It Fl d Ar duty
 Configure the duty (in nanoseconds or percentage) of the PWM channel.
 Duty is the portion of the
 .Ar period
 during which the signal is asserted.
+.It Fl E
+Enable the PWM channel.
+.It Fl p Ar period
+Configure the period (in nanoseconds) of the PWM channel.
 .El
 .Sh EXAMPLES
 .Bl -bullet
@@ -98,9 +91,10 @@ Show the configuration of the PWM channel:
 pwm -f /dev/pwm/pwmc0.1 -C
 .Ed
 .It
-Configure a 5 ns period and a 25000 ns duty cycle:
+Configure a 5 ns period and a 25000 ns duty cycle
+and enable the channel:
 .Bd -literal
-pwm -f pwmc1.1 -p 5 -d 25000
+pwm -f pwmc1.1 -E -p 5 -d 25000
 .Ed
 .It
 Configure a 50% duty cycle on the device and channel which

Modified: head/usr.sbin/pwm/pwm.c
==
--- head/usr.sbin/pwm/pwm.c Tue Jun 18 00:17:10 2019(r349165)
+++ head/usr.sbin/pwm/pwm.c Tue Jun 18 01:15:00 2019(r349166)
@@ -66,11 +66,8 @@ static void
 usage(void)
 {
fprintf(stderr, "Usage:\n");
-   fprintf(stderr, "\tpwm [-f dev] -E\n");
-   fprintf(stderr, "\tpwm [-f dev] -D\n");
fprintf(stderr, "\tpwm [-f dev] -C\n");
-   fprintf(stderr, "\tpwm [-f dev] -p period\n");
-   fprintf(stderr, "\tpwm [-f dev] -d duty\n");
+   fprintf(stderr, "\tpwm [-f dev] [-D | -E] [-p period] [-d duty[%%]]\n");
exit(1);
 }
 
@@ -94,14 +91,14 @@ main(int argc, char *argv[])
while ((ch = getopt(argc, argv, "f:EDCp:d:")) != -1) {
switch (ch) {
case 'E':
-   if (action)
+   if (action & (PWM_DISABLE | PWM_SHOW_CONFIG))
usage();
-   action = PWM_ENABLE;
+   action |= PWM_ENABLE;
break;
case 'D':
-   if (action)
+   if (action & (PWM_ENABLE | PWM_SHOW_CONFIG))
usage();
-   action = PWM_DISABLE;
+   action |= PWM_DISABLE;
break;
case 'C':
if (action)
@@ -109,17 +106,23 @@ main(int argc, char *argv[])
action = PWM_SHOW_CONFIG;
break;
case 'p':
-   if (action & ~(PWM_PERIOD | PWM_DUTY))
+   if (action & PWM_SHOW_CONFIG)
usage();
-   action = PWM_PERIOD;
+   action |= PWM_PERIOD;
period = strtol(optarg, NULL, 10);
break;
case 'd':
-   if (action & ~(PWM_PERIOD | PWM_DUTY))
+   if (action & PWM_SHOW_CONFIG)
usage();
-   action = PWM_DUTY;
+   action |= PWM_DUTY;
duty = strtol(optarg, , 10);
-   if (*percent != '\0' && *percent != '%')
+   if (*percent == '%') {
+   if (duty < 0 || duty > 100) {
+   fprintf(stderr, 
+   "Invalid duty percentage\n");
+   usage();
+   }
+   } else if (*percent != '\0')
usage();
break;
case 'f':
@@ -169,49 +172,31 @@ main(int argc, char *argv[])
goto 

svn commit: r349165 - head/usr.sbin/pwm

2019-06-17 Thread Ian Lepore
Author: ian
Date: Tue Jun 18 00:17:10 2019
New Revision: 349165
URL: https://svnweb.freebsd.org/changeset/base/349165

Log:
  Explain the relationship between PWM hardware channels being controlled and
  pwmc(4) device filenames.  Also, use uppercase PWM when the term is being
  used as an acronym, and expand the acronym where it's first used.

Modified:
  head/usr.sbin/pwm/pwm.8

Modified: head/usr.sbin/pwm/pwm.8
==
--- head/usr.sbin/pwm/pwm.8 Tue Jun 18 00:11:00 2019(r349164)
+++ head/usr.sbin/pwm/pwm.8 Tue Jun 18 00:17:10 2019(r349165)
@@ -27,7 +27,7 @@
 .Os
 .Sh NAME
 .Nm pwm
-.Nd configure pwm controller
+.Nd configure PWM (Pulse Width Modulation) hardware
 .Sh SYNOPSIS
 .Nm
 .Op Fl f Ar device
@@ -47,9 +47,26 @@
 .Sh DESCRIPTION
 The
 .Nm
-utility can be used to configure pwm controllers.
+utility can be used to configure pwm hardware.
+.Nm
+uses a
+.Xr pwmc 4
+device to communicate with the hardware.
+Some PWM hardware supports multiple output channels within a single
+controller block; each
+.Xr pwmc 4
+instance controls a single PWM channel.
 .Pp
-The options are as follow:
+.Xr pwmc 4
+devices are named
+.Pa /dev/pwm/pwmcX.Y ,
+where
+.Va X
+is the controller unit number and
+.Va Y
+is the channel number within that unit.
+.Pp
+The options are as follows:
 .Bl -tag -width "-f device"
 .It Fl f Ar device
 Device to operate on.
@@ -60,15 +77,15 @@ If an unqualified name is provided,
 .Pa /dev/pwm
 is automatically prepended.
 .It Fl E
-Enable the pwm channel.
+Enable the PWM channel.
 .It Fl D
-Disable the pwm channel.
+Disable the PWM channel.
 .It Fl C
-Show the configuration of the pwm channel.
+Show the configuration of the PWM channel.
 .It Fl p Ar period
-Configure the period (in nanoseconds) of the pwm channel
+Configure the period (in nanoseconds) of the PWM channel
 .It Fl d Ar duty
-Configure the duty (in nanoseconds or percentage) of the pwm channel.
+Configure the duty (in nanoseconds or percentage) of the PWM channel.
 Duty is the portion of the
 .Ar period
 during which the signal is asserted.
@@ -76,7 +93,7 @@ during which the signal is asserted.
 .Sh EXAMPLES
 .Bl -bullet
 .It
-Show the configuration of the pwm channel:
+Show the configuration of the PWM channel:
 .Bd -literal
 pwm -f /dev/pwm/pwmc0.1 -C
 .Ed
___
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: r349164 - in head: sys/dev/pwm usr.sbin/pwm

2019-06-17 Thread Ian Lepore
Author: ian
Date: Tue Jun 18 00:11:00 2019
New Revision: 349164
URL: https://svnweb.freebsd.org/changeset/base/349164

Log:
  Remove everything related to channels from the pwmc public interface, now
  that there is a pwmc(4) instance per channel and the channel number is
  maintained as a driver ivar rather than being passed in from userland.

Modified:
  head/sys/dev/pwm/pwmc.c
  head/sys/dev/pwm/pwmc.h
  head/usr.sbin/pwm/pwm.8
  head/usr.sbin/pwm/pwm.c

Modified: head/sys/dev/pwm/pwmc.c
==
--- head/sys/dev/pwm/pwmc.c Tue Jun 18 00:08:02 2019(r349163)
+++ head/sys/dev/pwm/pwmc.c Tue Jun 18 00:11:00 2019(r349164)
@@ -71,18 +71,12 @@ pwm_ioctl(struct cdev *dev, u_long cmd, caddr_t data,
struct pwmc_softc *sc;
struct pwm_state state;
device_t bus;
-   u_int nchannel;
int rv = 0;
 
sc = dev->si_drv1;
bus = device_get_parent(sc->dev);
 
switch (cmd) {
-   case PWMMAXCHANNEL:
-   nchannel = 0;
-   rv = PWMBUS_CHANNEL_COUNT(bus, );
-   bcopy(, data, sizeof(nchannel));
-   break;
case PWMSETSTATE:
bcopy(data, , sizeof(state));
rv = PWMBUS_CHANNEL_CONFIG(bus, sc->chan,

Modified: head/sys/dev/pwm/pwmc.h
==
--- head/sys/dev/pwm/pwmc.h Tue Jun 18 00:08:02 2019(r349163)
+++ head/sys/dev/pwm/pwmc.h Tue Jun 18 00:11:00 2019(r349164)
@@ -34,7 +34,6 @@
 #definePWM_POLARITY_INVERTED   (1 << 0)
 
 struct pwm_state {
-   u_int   channel;
u_int   period;
u_int   duty;
uint32_tflags;
@@ -45,9 +44,8 @@ struct pwm_state {
  * ioctls
  */
 
-#definePWMMAXCHANNEL   _IOWR('G', 0, int)
-#definePWMGETSTATE _IOWR('G', 1, struct pwm_state)
-#definePWMSETSTATE _IOWR('G', 2, struct pwm_state)
+#definePWMGETSTATE _IOWR('G', 0, struct pwm_state)
+#definePWMSETSTATE _IOWR('G', 1, struct pwm_state)
 
 
 #endif /* _PWM_H_ */

Modified: head/usr.sbin/pwm/pwm.8
==
--- head/usr.sbin/pwm/pwm.8 Tue Jun 18 00:08:02 2019(r349163)
+++ head/usr.sbin/pwm/pwm.8 Tue Jun 18 00:11:00 2019(r349164)
@@ -31,23 +31,18 @@
 .Sh SYNOPSIS
 .Nm
 .Op Fl f Ar device
-.Fl c Ar channel
 .Fl E
 .Nm
 .Op Fl f Ar device
-.Fl c Ar channel
 .Fl D
 .Nm
 .Op Fl f Ar device
-.Fl c Ar channel
 .Fl C
 .Nm
 .Op Fl f Ar device
-.Fl c Ar channel
 .Fl p Ar period
 .Nm
 .Op Fl f Ar device
-.Fl c Ar channel
 .Fl d Ar duty
 .Sh DESCRIPTION
 The
@@ -55,9 +50,7 @@ The
 utility can be used to configure pwm controllers.
 .Pp
 The options are as follow:
-.Bl -tag -width "-c channel"
-.It Fl c Ar channel
-Channel number to operate on.
+.Bl -tag -width "-f device"
 .It Fl f Ar device
 Device to operate on.
 If not specified,

Modified: head/usr.sbin/pwm/pwm.c
==
--- head/usr.sbin/pwm/pwm.c Tue Jun 18 00:08:02 2019(r349163)
+++ head/usr.sbin/pwm/pwm.c Tue Jun 18 00:11:00 2019(r349164)
@@ -66,11 +66,11 @@ static void
 usage(void)
 {
fprintf(stderr, "Usage:\n");
-   fprintf(stderr, "\tpwm [-f dev] -c channel -E\n");
-   fprintf(stderr, "\tpwm [-f dev] -c channel -D\n");
-   fprintf(stderr, "\tpwm [-f dev] -c channel -C\n");
-   fprintf(stderr, "\tpwm [-f dev] -c channel -p period\n");
-   fprintf(stderr, "\tpwm [-f dev] -c channel -d duty\n");
+   fprintf(stderr, "\tpwm [-f dev] -E\n");
+   fprintf(stderr, "\tpwm [-f dev] -D\n");
+   fprintf(stderr, "\tpwm [-f dev] -C\n");
+   fprintf(stderr, "\tpwm [-f dev] -p period\n");
+   fprintf(stderr, "\tpwm [-f dev] -d duty\n");
exit(1);
 }
 
@@ -79,21 +79,19 @@ main(int argc, char *argv[])
 {
struct pwm_state state;
int fd;
-   u_int channel, nchannels;
int period, duty;
int action, ch;
cap_rights_t right_ioctl;
-   const unsigned long pwm_ioctls[] = {PWMGETSTATE, PWMSETSTATE, 
PWMMAXCHANNEL};
+   const unsigned long pwm_ioctls[] = {PWMGETSTATE, PWMSETSTATE};
char *percent;
bool setname;
 
action = 0;
setname = false;
fd = -1;
-   channel = -1u;
period = duty = -1;
 
-   while ((ch = getopt(argc, argv, "f:c:EDCp:d:")) != -1) {
+   while ((ch = getopt(argc, argv, "f:EDCp:d:")) != -1) {
switch (ch) {
case 'E':
if (action)
@@ -124,15 +122,13 @@ main(int argc, char *argv[])
if (*percent != '\0' && *percent != '%')
usage();
break;
-   case 'c':
-   if (channel 

svn commit: r349161 - in head/sys: conf dev/usb modules/usb/usb

2019-06-17 Thread Takanori Watanabe
Author: takawata
Date: Mon Jun 17 23:03:30 2019
New Revision: 349161
URL: https://svnweb.freebsd.org/changeset/base/349161

Log:
  Add ACPI support for USB driver.
  This adds ACPI device path on devinfo(8) output and
  show  value of _UPC(usb port capabilities), _PLD (physical location of device)
  when hw.usb.debug >= 1 .
  
  Reviewed by: hselasky
  Differential Revision: https://reviews.freebsd.org/D20630

Added:
  head/sys/dev/usb/usb_hub_acpi.c   (contents, props changed)
  head/sys/dev/usb/usb_hub_private.h   (contents, props changed)
Modified:
  head/sys/conf/files
  head/sys/dev/usb/usb_hub.c
  head/sys/modules/usb/usb/Makefile

Modified: head/sys/conf/files
==
--- head/sys/conf/files Mon Jun 17 22:53:39 2019(r349160)
+++ head/sys/conf/files Mon Jun 17 23:03:30 2019(r349161)
@@ -3234,6 +3234,7 @@ dev/usb/usb_generic.c optional usb
 dev/usb/usb_handle_request.c   optional usb
 dev/usb/usb_hid.c  optional usb
 dev/usb/usb_hub.c  optional usb
+dev/usb/usb_hub_acpi.c optional usb acpi
 dev/usb/usb_if.m   optional usb
 dev/usb/usb_lookup.c   optional usb
 dev/usb/usb_mbuf.c optional usb

Modified: head/sys/dev/usb/usb_hub.c
==
--- head/sys/dev/usb/usb_hub.c  Mon Jun 17 22:53:39 2019(r349160)
+++ head/sys/dev/usb/usb_hub.c  Mon Jun 17 23:03:30 2019(r349161)
@@ -75,15 +75,10 @@
 #include 
 #endif /* USB_GLOBAL_INCLUDE_FILE */
 
-#defineUHUB_INTR_INTERVAL 250  /* ms */
-enum {
-   UHUB_INTR_TRANSFER,
-#if USB_HAVE_TT_SUPPORT
-   UHUB_RESET_TT_TRANSFER,
-#endif
-   UHUB_N_TRANSFER,
-};
 
+#include 
+
+
 #ifdef USB_DEBUG
 static int uhub_debug = 0;
 
@@ -111,30 +106,7 @@ SYSCTL_INT(_hw_usb, OID_AUTO, disable_port_power, CTLF
 _disable_port_power, 0, "Set to disable all USB port power.");
 #endif
 
-struct uhub_current_state {
-   uint16_t port_change;
-   uint16_t port_status;
-};
 
-struct uhub_softc {
-   struct uhub_current_state sc_st;/* current state */
-#if (USB_HAVE_FIXED_PORT != 0)
-   struct usb_hub sc_hub;
-#endif
-   device_t sc_dev;/* base device */
-   struct mtx sc_mtx;  /* our mutex */
-   struct usb_device *sc_udev; /* USB device */
-   struct usb_xfer *sc_xfer[UHUB_N_TRANSFER];  /* interrupt xfer */
-#if USB_HAVE_DISABLE_ENUM
-   int sc_disable_enumeration;
-   int sc_disable_port_power;
-#endif
-   uint8_t sc_usb_port_errors; /* error counter */
-#defineUHUB_USB_PORT_ERRORS_MAX 4
-   uint8_t sc_flags;
-#defineUHUB_FLAG_DID_EXPLORE 0x01
-};
-
 #defineUHUB_PROTO(sc) ((sc)->sc_udev->ddesc.bDeviceProtocol)
 #defineUHUB_IS_HIGH_SPEED(sc) (UHUB_PROTO(sc) != UDPROTO_FSHUB)
 #defineUHUB_IS_SINGLE_TT(sc) (UHUB_PROTO(sc) == UDPROTO_HSHUBSTT)
@@ -143,14 +115,10 @@ struct uhub_softc {
 
 /* prototypes for type checking: */
 
-static device_probe_t uhub_probe;
-static device_attach_t uhub_attach;
-static device_detach_t uhub_detach;
 static device_suspend_t uhub_suspend;
 static device_resume_t uhub_resume;
 
 static bus_driver_added_t uhub_driver_added;
-static bus_child_location_str_t uhub_child_location_string;
 static bus_child_pnpinfo_str_t uhub_child_pnpinfo_string;
 
 static usb_callback_t uhub_intr_callback;
@@ -207,7 +175,7 @@ static device_method_t uhub_methods[] = {
DEVMETHOD_END
 };
 
-static driver_t uhub_driver = {
+driver_t uhub_driver = {
.name = "uhub",
.methods = uhub_methods,
.size = sizeof(struct uhub_softc)
@@ -1138,7 +1106,7 @@ uhub_explore(struct usb_device *udev)
return (USB_ERR_NORMAL_COMPLETION);
 }
 
-static int
+int
 uhub_probe(device_t dev)
 {
struct usb_attach_arg *uaa = device_get_ivars(dev);
@@ -1152,7 +1120,7 @@ uhub_probe(device_t dev)
 */
if (uaa->info.bConfigIndex == 0 &&
uaa->info.bDeviceClass == UDCLASS_HUB)
-   return (0);
+   return (BUS_PROBE_DEFAULT);
 
return (ENXIO);
 }
@@ -1218,7 +1186,7 @@ uhub_query_info(struct usb_device *udev, uint8_t *pnpo
return (err);
 }
 
-static int
+int
 uhub_attach(device_t dev)
 {
struct uhub_softc *sc = device_get_softc(dev);
@@ -1564,7 +1532,7 @@ error:
  * Called from process context when the hub is gone.
  * Detach all devices on active ports.
  */
-static int
+int
 uhub_detach(device_t dev)
 {
struct uhub_softc *sc = device_get_softc(dev);
@@ -1634,13 +1602,7 @@ uhub_driver_added(device_t dev, driver_t *driver)
usb_needs_explore_all();
 }
 
-struct hub_result {
-   struct usb_device *udev;
-   uint8_t portno;
-   uint8_t iface_index;
-};
-
-static void
+void
 uhub_find_iface_index(struct usb_hub *hub, device_t child,
 struct hub_result *res)
 

svn commit: r349160 - in head/release: . tools

2019-06-17 Thread Glen Barber
Author: gjb
Date: Mon Jun 17 22:53:39 2019
New Revision: 349160
URL: https://svnweb.freebsd.org/changeset/base/349160

Log:
  Fix passing ${CONF_FILES} (which contains MAKE_CONF and
  SRC_CONF, __MAKE_CONF and SRCCONF, respectively) through
  to arm_install_base() and chroot_arm_build_release().
  This prevents failures when the target image is intended
  to be build with make.conf(5) and src.conf(5) overrides,
  which are correctly handled for non-embedded image builds.
  
  Reported and tested by:   Daniel Engberg
  PR:   238615
  MFC after:3 days
  Sponsored by: The FreeBSD Foundation

Modified:
  head/release/release.sh
  head/release/tools/arm.subr

Modified: head/release/release.sh
==
--- head/release/release.sh Mon Jun 17 22:13:59 2019(r349159)
+++ head/release/release.sh Mon Jun 17 22:53:39 2019(r349160)
@@ -388,6 +388,7 @@ chroot_arm_build_release() {
[ ! -z "${RELEASECONF}" ] && . "${RELEASECONF}"
export MAKE_FLAGS="${MAKE_FLAGS} TARGET=${EMBEDDED_TARGET}"
export MAKE_FLAGS="${MAKE_FLAGS} TARGET_ARCH=${EMBEDDED_TARGET_ARCH}"
+   export MAKE_FLAGS="${MAKE_FLAGS} ${CONF_FILES}"
eval chroot ${CHROOTDIR} env WITH_UNIFIED_OBJDIR=1 make ${MAKE_FLAGS} 
-C /usr/src/release obj
export WORLDDIR="$(eval chroot ${CHROOTDIR} make ${MAKE_FLAGS} -C 
/usr/src/release -V WORLDDIR)"
export OBJDIR="$(eval chroot ${CHROOTDIR} env WITH_UNIFIED_OBJDIR=1 
make ${MAKE_FLAGS} -C /usr/src/release -V .OBJDIR)"

Modified: head/release/tools/arm.subr
==
--- head/release/tools/arm.subr Mon Jun 17 22:13:59 2019(r349159)
+++ head/release/tools/arm.subr Mon Jun 17 22:53:39 2019(r349160)
@@ -166,7 +166,7 @@ arm_install_base() {
TARGET=${EMBEDDED_TARGET} \
TARGET_ARCH=${EMBEDDED_TARGET_ARCH} \
DESTDIR=${DESTDIR} KERNCONF=${KERNEL} \
-   installworld installkernel distribution
+   ${CONF_FILES} installworld installkernel distribution
chroot ${CHROOTDIR} mkdir -p ${DESTDIR}/boot/msdos
 
arm_create_user
___
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: r349157 - head/share/misc

2019-06-17 Thread Sevan Janiyan
Author: sevan (doc committer)
Date: Mon Jun 17 21:46:13 2019
New Revision: 349157
URL: https://svnweb.freebsd.org/changeset/base/349157

Log:
  Add NetBSD 8.1 & DragonFly BSD 5.6

Modified:
  head/share/misc/bsd-family-tree

Modified: head/share/misc/bsd-family-tree
==
--- head/share/misc/bsd-family-tree Mon Jun 17 21:38:33 2019
(r349156)
+++ head/share/misc/bsd-family-tree Mon Jun 17 21:46:13 2019
(r349157)
@@ -380,6 +380,8 @@ FreeBSD 5.2   |  | |  
  *--FreeBSD   | |  v   |   |
  |   12.0 | |  |   DragonFly 5.4.1
  || | OpenBSD 6.5  |
+ ||  NetBSD|   |
+ ||8.1 |   DragonFly 5.6
  || |  |   |
 FreeBSD 13 -current   | NetBSD -current   OpenBSD -currentDragonFly 
-current
  || |  |   |
@@ -763,6 +765,8 @@ DragonFly 5.4.0 2018-12-03 [DFB]
 FreeBSD 12.0   2018-12-11 [FBD]
 DragonFly 5.4.12018-12-24 [DFB]
 OpenBSD 6.52019-05-01 [OBD]
+NetBSD 8.1 2019-06-04 [NBD]
+DragonFly 5.6  2019-06-17 [DFB]
 
 Bibliography
 
___
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: r349156 - head/share/misc

2019-06-17 Thread Sevan Janiyan
Author: sevan (doc committer)
Date: Mon Jun 17 21:38:33 2019
New Revision: 349156
URL: https://svnweb.freebsd.org/changeset/base/349156

Log:
  Fix tab

Modified:
  head/share/misc/bsd-family-tree

Modified: head/share/misc/bsd-family-tree
==
--- head/share/misc/bsd-family-tree Mon Jun 17 21:31:27 2019
(r349155)
+++ head/share/misc/bsd-family-tree Mon Jun 17 21:38:33 2019
(r349156)
@@ -762,7 +762,7 @@ OpenBSD 6.4 2018-10-18 [OBD]
 DragonFly 5.4.02018-12-03 [DFB]
 FreeBSD 12.0   2018-12-11 [FBD]
 DragonFly 5.4.12018-12-24 [DFB]
-OpenBSD 6.5 2019-05-01 [OBD]
+OpenBSD 6.52019-05-01 [OBD]
 
 Bibliography
 
___
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: r349154 - in head: sys/dev/random tests/sys/devrandom

2019-06-17 Thread Conrad Meyer
Author: cem
Date: Mon Jun 17 20:29:13 2019
New Revision: 349154
URL: https://svnweb.freebsd.org/changeset/base/349154

Log:
  random(4): Fortuna: allow increased concurrency
  
  Add experimental feature to increase concurrency in Fortuna.  As this
  diverges slightly from canonical Fortuna, and due to the security
  sensitivity of random(4), it is off by default.  To enable it, set the
  tunable kern.random.fortuna.concurrent_read="1".  The rest of this commit
  message describes the behavior when enabled.
  
  Readers continue to update shared Fortuna state under global mutex, as they
  do in the status quo implementation of the algorithm, but shift the actual
  PRF generation out from under the global lock.  This massively reduces the
  CPU time readers spend holding the global lock, allowing for increased
  concurrency on SMP systems and less bullying of the harvestq kthread.
  
  It is somewhat of a deviation from FS  I think the primary difference is
  that the specific sequence of AES keys will differ if READ_RANDOM_UIO is
  accessed concurrently (as the 2nd thread to take the mutex will no longer
  receive a key derived from rekeying the first thread).  However, I believe
  the goals of rekeying AES are maintained: trivially, we continue to rekey
  every 1MB for the statistical property; and each consumer gets a
  forward-secret, independent AES key for their PRF.
  
  Since Chacha doesn't need to rekey for sequences of any length, this change
  makes no difference to the sequence of Chacha keys and PRF generated when
  Chacha is used in place of AES.
  
  On a GENERIC 4-thread VM (so, INVARIANTS/WITNESS, numbers not necessarily
  representative), 3x concurrent AES performance jumped from ~55 MiB/s per
  thread to ~197 MB/s per thread.  Concurrent Chacha20 at 3 threads went from
  roughly ~113 MB/s per thread to ~430 MB/s per thread.
  
  Prior to this change, the system was extremely unresponsive with 3-4
  concurrent random readers; each thread had high variance in latency and
  throughput, depending on who got lucky and won the lock.  "rand_harvestq"
  thread CPU use was high (double digits), seemingly due to spinning on the
  global lock.
  
  After the change, concurrent random readers and the system in general are
  much more responsive, and rand_harvestq CPU use dropped to basically zero.
  
  Tests are added to the devrandom suite to ensure the uint128_add64 primitive
  utilized by unlocked read functions to specification.
  
  Reviewed by:  markm
  Approved by:  secteam(delphij)
  Relnotes: yes
  Differential Revision:https://reviews.freebsd.org/D20313

Modified:
  head/sys/dev/random/fortuna.c
  head/sys/dev/random/fortuna.h
  head/sys/dev/random/hash.c
  head/sys/dev/random/hash.h
  head/sys/dev/random/uint128.h
  head/tests/sys/devrandom/uint128_test.c

Modified: head/sys/dev/random/fortuna.c
==
--- head/sys/dev/random/fortuna.c   Mon Jun 17 20:11:02 2019
(r349153)
+++ head/sys/dev/random/fortuna.c   Mon Jun 17 20:29:13 2019
(r349154)
@@ -61,6 +61,7 @@ __FBSDID("$FreeBSD$");
 #include "unit_test.h"
 #endif /* _KERNEL */
 
+#include 
 #include 
 #include 
 
@@ -75,7 +76,10 @@ __FBSDID("$FreeBSD$");
 /* Defined in FS */
 #defineRANDOM_FORTUNA_NPOOLS 32/* The number of 
accumulation pools */
 #defineRANDOM_FORTUNA_DEFPOOLSIZE 64   /* The default pool 
size/length for a (re)seed */
-#defineRANDOM_FORTUNA_MAX_READ (1 << 20)   /* Max bytes in a 
single read */
+#defineRANDOM_FORTUNA_MAX_READ (1 << 20)   /* Max bytes from AES 
before rekeying */
+#defineRANDOM_FORTUNA_BLOCKS_PER_KEY (1 << 16) /* Max blocks from AES 
before rekeying */
+CTASSERT(RANDOM_FORTUNA_BLOCKS_PER_KEY * RANDOM_BLOCKSIZE ==
+RANDOM_FORTUNA_MAX_READ);
 
 /*
  * The allowable range of RANDOM_FORTUNA_DEFPOOLSIZE. The default value is 
above.
@@ -120,6 +124,26 @@ static struct fortuna_state {
mtx_t fs_mtx;
 } fortuna_state;
 
+/*
+ * Experimental concurrent reads feature.  For now, disabled by default.  But
+ * we may enable it in the future.
+ *
+ * The benefit is improved concurrency in Fortuna.  That is reflected in two
+ * related aspects:
+ *
+ * 1. Concurrent devrandom readers can achieve similar throughput to a single
+ *reader thread.
+ *
+ * 2. The rand_harvestq process spends much less time spinning when one or more
+ *readers is processing a large request.  Partially this is due to
+ *rand_harvestq / ra_event_processor design, which only passes one event at
+ *a time to the underlying algorithm.  Each time, Fortuna must take its
+ *global state mutex, potentially blocking on a reader.  Our adaptive
+ *mutexes assume that a lock holder currently on CPU will release the lock
+ *quickly, and spin if the owning thread is currently running.
+ */
+static bool fortuna_concurrent_read __read_frequently 

svn commit: r349153 - in head/libexec/rc: . rc.d

2019-06-17 Thread Cy Schubert
Author: cy
Date: Mon Jun 17 20:11:02 2019
New Revision: 349153
URL: https://svnweb.freebsd.org/changeset/base/349153

Log:
  Allow the hostapd program to be specified. This allows users to use
  hostapd from ports instead of the one in base. The default is the hostapd
  in base.
  
  PR:   238571
  MFC after:1 week

Modified:
  head/libexec/rc/rc.conf
  head/libexec/rc/rc.d/hostapd

Modified: head/libexec/rc/rc.conf
==
--- head/libexec/rc/rc.conf Mon Jun 17 20:10:55 2019(r349152)
+++ head/libexec/rc/rc.conf Mon Jun 17 20:11:02 2019(r349153)
@@ -275,6 +275,7 @@ ppp_user="root" # Which user to run ppp as
 # profile3 uses default ppp_mode and ppp_nat
 
 ### Network daemon (miscellaneous) ###
+hostapd_program="/usr/sbin/hostapd"
 hostapd_enable="NO"# Run hostap daemon.
 syslogd_enable="YES"   # Run syslog daemon (or NO).
 syslogd_program="/usr/sbin/syslogd" # path to syslogd, if you want a different 
one.

Modified: head/libexec/rc/rc.d/hostapd
==
--- head/libexec/rc/rc.d/hostapdMon Jun 17 20:10:55 2019
(r349152)
+++ head/libexec/rc/rc.d/hostapdMon Jun 17 20:11:02 2019
(r349153)
@@ -11,7 +11,7 @@
 
 name="hostapd"
 desc="Authenticator for IEEE 802.11 networks"
-command="/usr/sbin/${name}"
+command=${hostapd_program}
 
 ifn="$2"
 if [ -z "$ifn" ]; then
___
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: r349152 - head/sys/contrib/ipfilter/netinet

2019-06-17 Thread Cy Schubert
Author: cy
Date: Mon Jun 17 20:10:55 2019
New Revision: 349152
URL: https://svnweb.freebsd.org/changeset/base/349152

Log:
  Make ipf_objbytes a constant. ipf_objbytes is a table of internal data
  structures that are saved across reboots by ipfs(8). The table is not
  changed at runtime.
  
  MFC after:3 days

Modified:
  head/sys/contrib/ipfilter/netinet/fil.c

Modified: head/sys/contrib/ipfilter/netinet/fil.c
==
--- head/sys/contrib/ipfilter/netinet/fil.c Mon Jun 17 19:49:08 2019
(r349151)
+++ head/sys/contrib/ipfilter/netinet/fil.c Mon Jun 17 20:10:55 2019
(r349152)
@@ -6254,7 +6254,7 @@ ipf_ioctlswitch(softc, unit, data, cmd, mode, uid, ctx
  * Flags:
  * 1 = minimum size, not absolute size
  */
-static int ipf_objbytes[IPFOBJ_COUNT][3] = {
+static const int   ipf_objbytes[IPFOBJ_COUNT][3] = {
{ 1,sizeof(struct frentry), 501 },  /* 0 */
{ 1,sizeof(struct friostat),501 },
{ 0,sizeof(struct fr_info), 501 },
___
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: r349151 - in head: lib/libufs stand/libsa sys/conf sys/dev/iscsi sys/dev/iscsi_initiator sys/dev/liquidio sys/dev/usb/net sys/fs/ext2fs sys/fs/nandfs sys/geom/part sys/geom/raid sys/ker...

2019-06-17 Thread Xin LI
Author: delphij
Date: Mon Jun 17 19:49:08 2019
New Revision: 349151
URL: https://svnweb.freebsd.org/changeset/base/349151

Log:
  Separate kernel crc32() implementation to its own header (gsb_crc32.h) and
  rename the source to gsb_crc32.c.
  
  This is a prerequisite of unifying kernel zlib instances.
  
  PR:   229763
  Submitted by: Yoshihiro Ota 
  Differential Revision:https://reviews.freebsd.org/D20193

Added:
  head/sys/libkern/gsb_crc32.c
 - copied, changed from r349150, head/sys/libkern/crc32.c
  head/sys/sys/gsb_crc32.h   (contents, props changed)
Deleted:
  head/sys/libkern/crc32.c
Modified:
  head/lib/libufs/Makefile
  head/stand/libsa/crc32_libkern.c
  head/sys/conf/files
  head/sys/dev/iscsi/icl_soft.c
  head/sys/dev/iscsi_initiator/isc_subr.c
  head/sys/dev/liquidio/lio_bsd.h
  head/sys/dev/usb/net/if_cdce.c
  head/sys/fs/ext2fs/ext2_csum.c
  head/sys/fs/nandfs/nandfs_segment.c
  head/sys/fs/nandfs/nandfs_subr.c
  head/sys/fs/nandfs/nandfs_vfsops.c
  head/sys/geom/part/g_part_bsd64.c
  head/sys/geom/part/g_part_gpt.c
  head/sys/geom/raid/md_ddf.c
  head/sys/kern/subr_compressor.c
  head/sys/libkern/x86/crc32_sse42.c
  head/sys/netinet/libalias/alias_sctp.c
  head/sys/netinet/sctp_crc32.c
  head/sys/netpfil/pf/pf.c
  head/sys/sys/libkern.h
  head/sys/sys/param.h
  head/sys/ufs/ffs/ffs_alloc.c
  head/sys/ufs/ffs/ffs_snapshot.c
  head/sys/ufs/ffs/ffs_subr.c
  head/sys/ufs/ffs/ffs_vfsops.c
  head/tests/sys/kern/Makefile
  head/tests/sys/kern/libkern_crc32.c

Modified: head/lib/libufs/Makefile
==
--- head/lib/libufs/MakefileMon Jun 17 17:35:55 2019(r349150)
+++ head/lib/libufs/MakefileMon Jun 17 19:49:08 2019(r349151)
@@ -5,7 +5,8 @@ LIB=ufs
 SHLIBDIR?= /lib
 SHLIB_MAJOR=   7
 
-SRCS=  block.c cgroup.c crc32.c inode.c sblock.c type.c ffs_subr.c ffs_tables.c
+SRCS=  block.c cgroup.c gsb_crc32.c inode.c sblock.c type.c ffs_subr.c
+SRCS+= ffs_tables.c
 INCS=  libufs.h
 
 MAN=   bread.3 cgread.3 getinode.3 libufs.3 sbread.3 ufs_disk_close.3

Modified: head/stand/libsa/crc32_libkern.c
==
--- head/stand/libsa/crc32_libkern.cMon Jun 17 17:35:55 2019
(r349150)
+++ head/stand/libsa/crc32_libkern.cMon Jun 17 19:49:08 2019
(r349151)
@@ -1,3 +1,3 @@
 /* $FreeBSD$ */
 
-#include "../../sys/libkern/crc32.c"
+#include "../../sys/libkern/gsb_crc32.c"

Modified: head/sys/conf/files
==
--- head/sys/conf/files Mon Jun 17 17:35:55 2019(r349150)
+++ head/sys/conf/files Mon Jun 17 19:49:08 2019(r349151)
@@ -3982,9 +3982,9 @@ crypto/chacha20/chacha.c  standard
 libkern/asprintf.c standard
 libkern/bcd.c  standard
 libkern/bsearch.c  standard
-libkern/crc32.cstandard
 libkern/explicit_bzero.c   standard
 libkern/fnmatch.c  standard
+libkern/gsb_crc32.cstandard
 libkern/iconv.coptional libiconv
 libkern/iconv_converter_if.m   optional libiconv
 libkern/iconv_ucs.coptional libiconv

Modified: head/sys/dev/iscsi/icl_soft.c
==
--- head/sys/dev/iscsi/icl_soft.c   Mon Jun 17 17:35:55 2019
(r349150)
+++ head/sys/dev/iscsi/icl_soft.c   Mon Jun 17 19:49:08 2019
(r349151)
@@ -41,6 +41,7 @@ __FBSDID("$FreeBSD$");
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 

Modified: head/sys/dev/iscsi_initiator/isc_subr.c
==
--- head/sys/dev/iscsi_initiator/isc_subr.c Mon Jun 17 17:35:55 2019
(r349150)
+++ head/sys/dev/iscsi_initiator/isc_subr.c Mon Jun 17 19:49:08 2019
(r349151)
@@ -39,6 +39,7 @@ __FBSDID("$FreeBSD$");
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 

Modified: head/sys/dev/liquidio/lio_bsd.h
==
--- head/sys/dev/liquidio/lio_bsd.h Mon Jun 17 17:35:55 2019
(r349150)
+++ head/sys/dev/liquidio/lio_bsd.h Mon Jun 17 19:49:08 2019
(r349151)
@@ -36,6 +36,7 @@
 #define __LIO_BSD_H__
 
 #include 
+#include 
 #include 
 #include 
 #include 

Modified: head/sys/dev/usb/net/if_cdce.c
==
--- head/sys/dev/usb/net/if_cdce.c  Mon Jun 17 17:35:55 2019
(r349150)
+++ head/sys/dev/usb/net/if_cdce.c  Mon Jun 17 19:49:08 2019
(r349151)
@@ -50,7 +50,7 @@
 #include 
 __FBSDID("$FreeBSD$");
 
-#include 
+#include 
 #include 
 #include 
 #include 

Modified: head/sys/fs/ext2fs/ext2_csum.c
==

Re: svn commit: r349146 - head/share/man/man4

2019-06-17 Thread Warner Losh
Especially since there can be multiple PCI registers that can be read in 1
32-bit transaction.

Warner

On Mon, Jun 17, 2019, 10:28 AM Scott Long  wrote:

> It’s customary to refer to PCI configuration registers in the plural
> form.  Would
> you mind changing back from “register” to “registers”?
>
> Thanks,
> Scott
>
>
> > On Jun 17, 2019, at 10:54 AM, Niclas Zeising 
> wrote:
> >
> > Author: zeising (doc,ports committer)
> > Date: Mon Jun 17 16:54:51 2019
> > New Revision: 349146
> > URL: https://svnweb.freebsd.org/changeset/base/349146
> >
> > Log:
> >  pci.4: wordsmith and add missing words
> >
> >  Add missing words after PCI in the description of the PCIOCWRITE and
> >  PCIOCATTACHED ioctls.
> >  Use singular in PCIOCREAD, we only read one register at the time.
> >
> >  Reviewed by: bcr, bjk, rgrimes, cem
> >  MFC after:   2 weeks
> >  X-MFC-with:  r349133
> >  Differential Revision:   https://reviews.freebsd.org/D20671
> >
> > Modified:
> >  head/share/man/man4/pci.4
> >
> > Modified: head/share/man/man4/pci.4
> >
> ==
> > --- head/share/man/man4/pci.4 Mon Jun 17 16:50:58 2019(r349145)
> > +++ head/share/man/man4/pci.4 Mon Jun 17 16:54:51 2019(r349146)
> > @@ -290,7 +290,7 @@ This
> > .Xr ioctl 2
> > reads the
> > .Tn PCI
> > -configuration registers specified by the passed-in
> > +configuration register specified by the passed-in
> > .Va pci_io
> > structure.
> > The
> > @@ -323,7 +323,7 @@ This
> > .Xr ioctl 2
> > allows users to write to the
> > .Tn PCI
> > -specified in the passed-in
> > +configuration register specified in the passed-in
> > .Va pci_io
> > structure.
> > The
> > @@ -338,7 +338,7 @@ This
> > .Xr ioctl 2
> > allows users to query if a driver is attached to the
> > .Tn PCI
> > -specified in the passed-in
> > +device specified in the passed-in
> > .Va pci_io
> > structure.
> > The
> >
>
>
>
___
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: r349146 - head/share/man/man4

2019-06-17 Thread Scott Long


> On Jun 17, 2019, at 11:37 AM, Niclas Zeising  wrote:
> 
> On 2019-06-17 19:27, Scott Long wrote:
>> It’s customary to refer to PCI configuration registers in the plural form.  
>> Would
>> you mind changing back from “register” to “registers”?
> 
> I didn't know that.
> Changed in r349150
> Regards
> — 
> 

Thanks!

Scott


___
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: r349146 - head/share/man/man4

2019-06-17 Thread Niclas Zeising

On 2019-06-17 19:27, Scott Long wrote:

It’s customary to refer to PCI configuration registers in the plural form.  
Would
you mind changing back from “register” to “registers”?



I didn't know that.
Changed in r349150
Regards
--
Niclas
___
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: r349150 - head/share/man/man4

2019-06-17 Thread Niclas Zeising
Author: zeising (doc,ports committer)
Date: Mon Jun 17 17:35:55 2019
New Revision: 349150
URL: https://svnweb.freebsd.org/changeset/base/349150

Log:
  pci.4: Use plural configuration registers
  
  It is customary to use plural when talking about PCI configure registers.
  
  Reported by:  scottl
  MFC after:2 weeks
  X-MFC-with:   r349133

Modified:
  head/share/man/man4/pci.4

Modified: head/share/man/man4/pci.4
==
--- head/share/man/man4/pci.4   Mon Jun 17 17:17:01 2019(r349149)
+++ head/share/man/man4/pci.4   Mon Jun 17 17:35:55 2019(r349150)
@@ -307,7 +307,7 @@ from the ioctl.
 .It pi_reg
 The
 .Tn PCI
-configuration register the user would like to access.
+configuration registers the user would like to access.
 .It pi_width
 The width, in bytes, of the data the user would like to read.
 This value
@@ -323,7 +323,7 @@ This
 .Xr ioctl 2
 allows users to write to the
 .Tn PCI
-configuration register specified in the passed-in
+configuration registers specified in the passed-in
 .Va pci_io
 structure.
 The
___
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: r349146 - head/share/man/man4

2019-06-17 Thread Scott Long
It’s customary to refer to PCI configuration registers in the plural form.  
Would
you mind changing back from “register” to “registers”?

Thanks,
Scott


> On Jun 17, 2019, at 10:54 AM, Niclas Zeising  wrote:
> 
> Author: zeising (doc,ports committer)
> Date: Mon Jun 17 16:54:51 2019
> New Revision: 349146
> URL: https://svnweb.freebsd.org/changeset/base/349146
> 
> Log:
>  pci.4: wordsmith and add missing words
> 
>  Add missing words after PCI in the description of the PCIOCWRITE and
>  PCIOCATTACHED ioctls.
>  Use singular in PCIOCREAD, we only read one register at the time.
> 
>  Reviewed by: bcr, bjk, rgrimes, cem
>  MFC after:   2 weeks
>  X-MFC-with:  r349133
>  Differential Revision:   https://reviews.freebsd.org/D20671
> 
> Modified:
>  head/share/man/man4/pci.4
> 
> Modified: head/share/man/man4/pci.4
> ==
> --- head/share/man/man4/pci.4 Mon Jun 17 16:50:58 2019(r349145)
> +++ head/share/man/man4/pci.4 Mon Jun 17 16:54:51 2019(r349146)
> @@ -290,7 +290,7 @@ This
> .Xr ioctl 2
> reads the
> .Tn PCI
> -configuration registers specified by the passed-in
> +configuration register specified by the passed-in
> .Va pci_io
> structure.
> The
> @@ -323,7 +323,7 @@ This
> .Xr ioctl 2
> allows users to write to the
> .Tn PCI
> -specified in the passed-in
> +configuration register specified in the passed-in
> .Va pci_io
> structure.
> The
> @@ -338,7 +338,7 @@ This
> .Xr ioctl 2
> allows users to query if a driver is attached to the
> .Tn PCI
> -specified in the passed-in
> +device specified in the passed-in
> .Va pci_io
> structure.
> The
> 

___
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: r349148 - head/share/man/man3

2019-06-17 Thread Mark Johnston
Author: markj
Date: Mon Jun 17 16:57:44 2019
New Revision: 349148
URL: https://svnweb.freebsd.org/changeset/base/349148

Log:
  Add some missing MLINKs for tree(3).
  
  MFC after:3 days

Modified:
  head/share/man/man3/Makefile

Modified: head/share/man/man3/Makefile
==
--- head/share/man/man3/MakefileMon Jun 17 16:56:51 2019
(r349147)
+++ head/share/man/man3/MakefileMon Jun 17 16:57:44 2019
(r349148)
@@ -179,8 +179,21 @@ MLINKS+=   tree.3 RB_EMPTY.3 \
tree.3 RB_ENTRY.3 \
tree.3 RB_FIND.3 \
tree.3 RB_FOREACH.3 \
+   tree.3 RB_FOREACH_FROM.3 \
tree.3 RB_FOREACH_REVERSE.3 \
+   tree.3 RB_FOREACH_REVERSE_FROM.3 \
+   tree.3 RB_FOREACH_REVERSE_SAFE.3 \
+   tree.3 RB_FOREACH_SAFE.3 \
tree.3 RB_GENERATE.3 \
+   tree.3 RB_GENERATE_FIND.3 \
+   tree.3 RB_GENERATE_INSERT.3 \
+   tree.3 RB_GENERATE_INSERT_COLOR.3 \
+   tree.3 RB_GENERATE_MINMAX.3 \
+   tree.3 RB_GENERATE_NEXT.3 \
+   tree.3 RB_GENERATE_NFIND.3 \
+   tree.3 RB_GENERATE_PREV.3 \
+   tree.3 RB_GENERATE_REMOVE.3 \
+   tree.3 RB_GENERATE_REMOVE_COLOR.3 \
tree.3 RB_GENERATE_STATIC.3 \
tree.3 RB_HEAD.3 \
tree.3 RB_INIT.3 \
@@ -194,6 +207,15 @@ MLINKS+=   tree.3 RB_EMPTY.3 \
tree.3 RB_PARENT.3 \
tree.3 RB_PREV.3 \
tree.3 RB_PROTOTYPE.3 \
+   tree.3 RB_PROTOTYPE_FIND.3 \
+   tree.3 RB_PROTOTYPE_INSERT.3 \
+   tree.3 RB_PROTOTYPE_INSERT_COLOR.3 \
+   tree.3 RB_PROTOTYPE_MINMAX.3 \
+   tree.3 RB_PROTOTYPE_NEXT.3 \
+   tree.3 RB_PROTOTYPE_NFIND.3 \
+   tree.3 RB_PROTOTYPE_PREV.3 \
+   tree.3 RB_PROTOTYPE_REMOVE.3 \
+   tree.3 RB_PROTOTYPE_REMOVE_COLOR.3 \
tree.3 RB_PROTOTYPE_STATIC.3 \
tree.3 RB_REMOVE.3 \
tree.3 RB_RIGHT.3 \
___
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: r349146 - head/share/man/man4

2019-06-17 Thread Niclas Zeising
Author: zeising (doc,ports committer)
Date: Mon Jun 17 16:54:51 2019
New Revision: 349146
URL: https://svnweb.freebsd.org/changeset/base/349146

Log:
  pci.4: wordsmith and add missing words
  
  Add missing words after PCI in the description of the PCIOCWRITE and
  PCIOCATTACHED ioctls.
  Use singular in PCIOCREAD, we only read one register at the time.
  
  Reviewed by:  bcr, bjk, rgrimes, cem
  MFC after:2 weeks
  X-MFC-with:   r349133
  Differential Revision:https://reviews.freebsd.org/D20671

Modified:
  head/share/man/man4/pci.4

Modified: head/share/man/man4/pci.4
==
--- head/share/man/man4/pci.4   Mon Jun 17 16:50:58 2019(r349145)
+++ head/share/man/man4/pci.4   Mon Jun 17 16:54:51 2019(r349146)
@@ -290,7 +290,7 @@ This
 .Xr ioctl 2
 reads the
 .Tn PCI
-configuration registers specified by the passed-in
+configuration register specified by the passed-in
 .Va pci_io
 structure.
 The
@@ -323,7 +323,7 @@ This
 .Xr ioctl 2
 allows users to write to the
 .Tn PCI
-specified in the passed-in
+configuration register specified in the passed-in
 .Va pci_io
 structure.
 The
@@ -338,7 +338,7 @@ This
 .Xr ioctl 2
 allows users to query if a driver is attached to the
 .Tn PCI
-specified in the passed-in
+device specified in the passed-in
 .Va pci_io
 structure.
 The
___
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: r349145 - head/usr.sbin/pwm

2019-06-17 Thread Ian Lepore
Author: ian
Date: Mon Jun 17 16:50:58 2019
New Revision: 349145
URL: https://svnweb.freebsd.org/changeset/base/349145

Log:
  Put periods at the ends of argument descriptions.  Explain the relationship
  between the period and duty arguments.

Modified:
  head/usr.sbin/pwm/pwm.8

Modified: head/usr.sbin/pwm/pwm.8
==
--- head/usr.sbin/pwm/pwm.8 Mon Jun 17 16:43:33 2019(r349144)
+++ head/usr.sbin/pwm/pwm.8 Mon Jun 17 16:50:58 2019(r349145)
@@ -57,7 +57,7 @@ utility can be used to configure pwm controllers.
 The options are as follow:
 .Bl -tag -width "-c channel"
 .It Fl c Ar channel
-Channel number to operate on
+Channel number to operate on.
 .It Fl f Ar device
 Device to operate on.
 If not specified,
@@ -67,15 +67,18 @@ If an unqualified name is provided,
 .Pa /dev/pwm
 is automatically prepended.
 .It Fl E
-Enable the pwm channel
+Enable the pwm channel.
 .It Fl D
-Disable the pwm channel
+Disable the pwm channel.
 .It Fl C
-Show the configuration of the pwm channel
+Show the configuration of the pwm channel.
 .It Fl p Ar period
 Configure the period (in nanoseconds) of the pwm channel
 .It Fl d Ar duty
-Configure the duty (in nanoseconds or percentage) of the pwm channel
+Configure the duty (in nanoseconds or percentage) of the pwm channel.
+Duty is the portion of the
+.Ar period
+during which the signal is asserted.
 .El
 .Sh EXAMPLES
 .Bl -bullet
___
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: r349144 - head/usr.sbin/pwm

2019-06-17 Thread Ian Lepore
Author: ian
Date: Mon Jun 17 16:43:33 2019
New Revision: 349144
URL: https://svnweb.freebsd.org/changeset/base/349144

Log:
  Follow changes in the pwmc(4) driver in relation to device filenames.
  
  The driver now names its cdev nodes pwmcX.Y where X is unit number and
  Y is the channel within that unit.  Change the default device name from
  pwmc0 to pwmc0.0.  The driver now puts cdev files and label aliases in
  the /dev/pwm directory, so allow the user to provide unqualified names
  with -f and automatically prepend the /dev/pwm part for them.
  
  Update the examples in the manpage to show the new device name format
  and location within /dev/pwm.

Modified:
  head/usr.sbin/pwm/pwm.8
  head/usr.sbin/pwm/pwm.c

Modified: head/usr.sbin/pwm/pwm.8
==
--- head/usr.sbin/pwm/pwm.8 Mon Jun 17 16:26:43 2019(r349143)
+++ head/usr.sbin/pwm/pwm.8 Mon Jun 17 16:43:33 2019(r349144)
@@ -22,7 +22,7 @@
 .\"
 .\" $FreeBSD$
 .\"
-.Dd January 12, 2019
+.Dd June 17, 2019
 .Dt PWM 8
 .Os
 .Sh NAME
@@ -61,8 +61,11 @@ Channel number to operate on
 .It Fl f Ar device
 Device to operate on.
 If not specified,
-.Pa /dev/pwmc0
+.Pa /dev/pwm/pwmc0.0
 is used.
+If an unqualified name is provided,
+.Pa /dev/pwm
+is automatically prepended.
 .It Fl E
 Enable the pwm channel
 .It Fl D
@@ -79,17 +82,21 @@ Configure the duty (in nanoseconds or percentage) of t
 .It
 Show the configuration of the pwm channel:
 .Bd -literal
-pwm -f /dev/pwmc0 -C
+pwm -f /dev/pwm/pwmc0.1 -C
 .Ed
 .It
-Configure a 5 ns period and a 25000 duty cycle:
+Configure a 5 ns period and a 25000 ns duty cycle:
 .Bd -literal
-pwm -f /dev/pwmc0 -p 5 -d 25000
+pwm -f pwmc1.1 -p 5 -d 25000
 .Ed
 .It
-Configure a 50% duty cycle:
+Configure a 50% duty cycle on the device and channel which
+were configured in
+.Xr pwmc 4
+to have the label
+.Pa backlight :
 .Bd -literal
-pwm -f /dev/pwmc0 -d 50%
+pwm -f backlight -d 50%
 .Ed
 .El
 .Sh SEE ALSO

Modified: head/usr.sbin/pwm/pwm.c
==
--- head/usr.sbin/pwm/pwm.c Mon Jun 17 16:26:43 2019(r349143)
+++ head/usr.sbin/pwm/pwm.c Mon Jun 17 16:43:33 2019(r349144)
@@ -37,6 +37,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -49,7 +50,19 @@
 #definePWM_PERIOD  0x0008
 #definePWM_DUTY0x0010
 
+static char device_name[PATH_MAX] = "/dev/pwm/pwmc0.0";
+
 static void
+set_device_name(const char *name)
+{
+
+   if (name[0] == '/')
+   strlcpy(device_name, name, sizeof(device_name));
+   else
+   snprintf(device_name, sizeof(device_name), "/dev/pwm/%s", name);
+}
+
+static void
 usage(void)
 {
fprintf(stderr, "Usage:\n");
@@ -72,8 +85,10 @@ main(int argc, char *argv[])
cap_rights_t right_ioctl;
const unsigned long pwm_ioctls[] = {PWMGETSTATE, PWMSETSTATE, 
PWMMAXCHANNEL};
char *percent;
+   bool setname;
 
action = 0;
+   setname = false;
fd = -1;
channel = -1u;
period = duty = -1;
@@ -115,24 +130,23 @@ main(int argc, char *argv[])
channel = strtoul(optarg, NULL, 10);
break;
case 'f':
-   if ((fd = open(optarg, O_RDWR)) < 0) {
-   fprintf(stderr, "pwm: cannot open %s %s\n",
- optarg, strerror(errno));
-   exit(1);
-   }
+   setname = true;
+   set_device_name(optarg);
+   break;
}
}
 
-   if (fd == -1) {
-   if ((fd = open("/dev/pwmc0", O_RDWR)) < 0) {
-   fprintf(stderr, "pwm: cannot open %s %s\n",
-   optarg, strerror(errno));
+   if (action == 0)
+   usage();
+
+   if ((fd = open(device_name, O_RDWR)) == -1) {
+   fprintf(stderr, "pwm: cannot open %s: %s\n",
+   device_name, strerror(errno));
+   if (setname)
exit(1);
-   }
+   else
+   usage();
}
-
-   if (action == 0 || fd == -1)
-   usage();
 
if (caph_limit_stdio() < 0) {
fprintf(stderr, "can't limit stdio rights");
___
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: r349143 - head/sys/dev/pwm

2019-06-17 Thread Ian Lepore
Author: ian
Date: Mon Jun 17 16:26:43 2019
New Revision: 349143
URL: https://svnweb.freebsd.org/changeset/base/349143

Log:
  Put the pwmc cdev filenames under the pwm directory along with any label
  names.  I.e., everything related to pwm now goes in /dev/pwm.  This will
  make it easier for userland tools to turn an unqualified name into a fully
  qualified pathname, whether it's the base pwmcX.Y name or a label name.

Modified:
  head/sys/dev/pwm/pwmc.c

Modified: head/sys/dev/pwm/pwmc.c
==
--- head/sys/dev/pwm/pwmc.c Mon Jun 17 15:14:26 2019(r349142)
+++ head/sys/dev/pwm/pwmc.c Mon Jun 17 16:26:43 2019(r349143)
@@ -182,7 +182,7 @@ pwmc_attach(device_t dev)
args.mda_gid = GID_OPERATOR;
args.mda_mode = 0660;
args.mda_si_drv1 = sc;
-   error = make_dev_s(, >cdev, "pwmc%d.%d",
+   error = make_dev_s(, >cdev, "pwm/pwmc%d.%d",
device_get_unit(device_get_parent(dev)), sc->chan);
if (error != 0) {
device_printf(dev, "Failed to make PWM device\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"


Re: svn commit: r349133 - head/share/man/man4

2019-06-17 Thread Rodney W. Grimes
> On 2019-06-17 12:27, Niclas Zeising wrote:
> > On 2019-06-17 11:03, Rodney W. Grimes wrote:
> >>> On 2019-06-17 09:56, Benjamin Kaduk wrote:
>  On Sun, Jun 16, 2019 at 10:42 PM Niclas Zeising   > wrote:
> 
>   Author: zeising (doc,ports committer)
>   Date: Mon Jun 17 05:41:47 2019
>   New Revision: 349133
>   URL: https://svnweb.freebsd.org/changeset/base/349133
> 
>   Log:
>  ? ? pci(4): Document PCIOCATTACHED
> 
>  ? ? Document the PCIOCATTACHED ioctl(2) in the pci(4) manual.
>  ? ? PCIOCATTACHED is used to query if a driver has attached to a 
>  PCI.
> 
>  ? ? Reviewed by:? bcr, imp
>  ? ? MFC after:? ? 2 weeks
>  ? ? Differential Revision: https://reviews.freebsd.org/D20652
> 
>   Modified:
>  ? ? head/share/man/man4/pci.4
> 
>   Modified: head/share/man/man4/pci.4
>   
>  ==
>   
> 
>   --- head/share/man/man4/pci.4? ?Mon Jun 17 03:48:44 2019
>   (r349132)
>   +++ head/share/man/man4/pci.4? ?Mon Jun 17 05:41:47 2019
>   (r349133)
>   @@ -24,7 +24,7 @@
>  ? ?.\"
>  ? ?.\" $FreeBSD$
>  ? ?.\"
>   -.Dd June 14, 2018
>   +.Dd June 17, 2019
>  ? ?.Dt PCI 4
>  ? ?.Os
>  ? ?.Sh NAME
>   @@ -333,6 +333,26 @@ The limitations on data width described for
>  ? ?reading registers, above, also apply to writing
>  ? ?.Tn PCI
>  ? ?configuration registers.
>   +.It PCIOCATTACHED
>   +This
>   +.Xr ioctl 2
>   +allows users to query if a driver is attached to the
>   +.Tn PCI
>   +specified in the passed-in
> 
> 
>  Is there a missing word like "device" here?
> >>
> >> Actally I think the missing word, in both cases, is register,
> >> unless I am misreading some part of the manual page and
> >> what a struct pci_io points at.? I guess if the pi_reg is null
> >> then this would be device.? Either way there is defanity a
> >> missing word.
> > 
> > I'll try to fix this.? In the PCIOCWRITE case, perhaps register is best, 
> > however, inthe PCIOCATTACHED case, device is best, I think.
> > I'll create a patch and put it for review, I'll get back to you once 
> > it's done.
> > Regards
> > 
> 
> Here's the review with my proposed change.  Let me know what you think.
> https://reviews.freebsd.org/D20671

This looks good to me, cant login right now to hit accept, but consider the 
rewview accepted by me too.


-- 
Rod Grimes rgri...@freebsd.org
___
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: r349138 - in head: sys/dev/random tests/sys/devrandom

2019-06-17 Thread Conrad Meyer
Author: cem
Date: Mon Jun 17 15:09:12 2019
New Revision: 349138
URL: https://svnweb.freebsd.org/changeset/base/349138

Log:
  random(4): Generalize algorithm-independent APIs
  
  At a basic level, remove assumptions about the underlying algorithm (such as
  output block size and reseeding requirements) from the algorithm-independent
  logic in randomdev.c.  Chacha20 does not have many of the restrictions that
  AES-ICM does as a PRF (Pseudo-Random Function), because it has a cipher
  block size of 512 bits.  The motivation is that by generalizing the API,
  Chacha is not penalized by the limitations of AES.
  
  In READ_RANDOM_UIO, first attempt to NOWAIT allocate a large enough buffer
  for the entire user request, or the maximal input we'll accept between
  signal checking, whichever is smaller.  The idea is that the implementation
  of any randomdev algorithm is then free to divide up large requests in
  whatever fashion it sees fit.
  
  As part of this, two responsibilities from the "algorithm-generic" randomdev
  code are pushed down into the Fortuna ra_read implementation (and any other
  future or out-of-tree ra_read implementations):
  
1. If an algorithm needs to rekey every N bytes, it is responsible for
handling that in ra_read(). (I.e., Fortuna's 1MB rekey interval for AES
block generation.)
  
2. If an algorithm uses a block cipher that doesn't tolerate partial-block
requests (again, e.g., AES), it is also responsible for handling that in
ra_read().
  
  Several APIs are changed from u_int buffer length to the more canonical
  size_t.  Several APIs are changed from taking a blockcount to a bytecount,
  to permit PRFs like Chacha20 to directly generate quantities of output that
  are not multiples of RANDOM_BLOCKSIZE (AES block size).
  
  The Fortuna algorithm is changed to NOT rekey every 1MiB when in Chacha20
  mode (kern.random.use_chacha20_cipher="1").  This is explicitly supported by
  the math in FS §9.4 (Ferguson, Schneier, and Kohno; "Cryptography
  Engineering"), as well as by their conclusion: "If we had a block cipher
  with a 256-bit [or greater] block size, then the collisions would not
  have been an issue at all."
  
  For now, continue to break up reads into PAGE_SIZE chunks, as they were
  before.  So, no functional change, mostly.
  
  Reviewed by:  markm
  Approved by:  secteam(delphij)
  Differential Revision:https://reviews.freebsd.org/D20312

Modified:
  head/sys/dev/random/fortuna.c
  head/sys/dev/random/hash.c
  head/sys/dev/random/hash.h
  head/sys/dev/random/other_algorithm.c
  head/sys/dev/random/randomdev.c
  head/sys/dev/random/randomdev.h
  head/tests/sys/devrandom/uint128_test.c

Modified: head/sys/dev/random/fortuna.c
==
--- head/sys/dev/random/fortuna.c   Mon Jun 17 14:59:45 2019
(r349137)
+++ head/sys/dev/random/fortuna.c   Mon Jun 17 15:09:12 2019
(r349138)
@@ -128,7 +128,7 @@ static uint8_t zero_region[RANDOM_ZERO_BLOCKSIZE];
 #endif
 
 static void random_fortuna_pre_read(void);
-static void random_fortuna_read(uint8_t *, u_int);
+static void random_fortuna_read(uint8_t *, size_t);
 static bool random_fortuna_seeded(void);
 static bool random_fortuna_seeded_internal(void);
 static void random_fortuna_process_event(struct harvest_event *);
@@ -306,49 +306,45 @@ random_fortuna_reseed_internal(uint32_t *entropy_data,
 }
 
 /*-
- * FS - GenerateBlocks()
- * Generate a number of complete blocks of random output.
- */
-static __inline void
-random_fortuna_genblocks(uint8_t *buf, u_int blockcount)
-{
-
-   RANDOM_RESEED_ASSERT_LOCK_OWNED();
-   KASSERT(!uint128_is_zero(fortuna_state.fs_counter), ("FS: C != 0"));
-
-   /*
-* Fills buf with RANDOM_BLOCKSIZE * blockcount bytes of keystream.
-* Increments fs_counter as it goes.
-*/
-   randomdev_keystream(_state.fs_key, _state.fs_counter,
-   buf, blockcount);
-}
-
-/*-
  * FS - PseudoRandomData()
- * This generates no more than 2^20 bytes of data, and cleans up its
- * internal state when finished. It is assumed that a whole number of
- * blocks are available for writing; any excess generated will be
- * ignored.
+ *
+ * If Chacha20 is used, output size is unrestricted.  If AES-CTR is used,
+ * output size MUST be <= 1MB and a multiple of RANDOM_BLOCKSIZE.  The
+ * reasoning for this is discussed in FS 9.4; the significant distinction
+ * between the two ciphers is that AES has a *block* size of 128 bits while
+ * Chacha has a *block* size of 512 bits.
  */
 static __inline void
-random_fortuna_genrandom(uint8_t *buf, u_int bytecount)
+random_fortuna_genrandom(uint8_t *buf, size_t bytecount)
 {
-   uint8_t temp[RANDOM_BLOCKSIZE * RANDOM_KEYS_PER_BLOCK];
-   u_int blockcount;
+   uint8_t newkey[RANDOM_KEYSIZE];
 
RANDOM_RESEED_ASSERT_LOCK_OWNED();
+
/*-
-* FS - assert(n < 2^20 (== 1 MB)
+* FS - 

svn commit: r349137 - in head: etc/mtree sys/dev/random tests/sys tests/sys/devrandom

2019-06-17 Thread Conrad Meyer
Author: cem
Date: Mon Jun 17 14:59:45 2019
New Revision: 349137
URL: https://svnweb.freebsd.org/changeset/base/349137

Log:
  random(4): Add regression tests for uint128 implementation, Chacha CTR
  
  Add some basic regression tests to verify behavior of both uint128
  implementations at typical boundary conditions, to run on all architectures.
  
  Test uint128 increment behavior of Chacha in keystream mode, as used by
  'kern.random.use_chacha20_cipher=1' (r344913) to verify assumptions at edge
  cases.  These assumptions are critical to the safety of using Chacha as a
  PRF in Fortuna (as implemented).
  
  (Chacha's use in arc4random is safe regardless of these tests, as it is
  limited to far less than 4 billion blocks of output in that API.)
  
  Reviewed by:  markm
  Approved by:  secteam(gordon)
  Differential Revision:https://reviews.freebsd.org/D20392

Added:
  head/tests/sys/devrandom/
  head/tests/sys/devrandom/Makefile   (contents, props changed)
  head/tests/sys/devrandom/uint128_test.c   (contents, props changed)
Modified:
  head/etc/mtree/BSD.tests.dist
  head/sys/dev/random/hash.c
  head/sys/dev/random/hash.h
  head/tests/sys/Makefile

Modified: head/etc/mtree/BSD.tests.dist
==
--- head/etc/mtree/BSD.tests.dist   Mon Jun 17 14:42:27 2019
(r349136)
+++ head/etc/mtree/BSD.tests.dist   Mon Jun 17 14:59:45 2019
(r349137)
@@ -722,6 +722,8 @@
 ..
 ..
 ..
+devrandom
+..
 dtrace
 ..
 fifo

Modified: head/sys/dev/random/hash.c
==
--- head/sys/dev/random/hash.c  Mon Jun 17 14:42:27 2019(r349136)
+++ head/sys/dev/random/hash.c  Mon Jun 17 14:59:45 2019(r349137)
@@ -37,12 +37,16 @@ __FBSDID("$FreeBSD$");
 #else /* !_KERNEL */
 #include 
 #include 
+#include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
 #include 
-#include "unit_test.h"
+#define KASSERT(x, y)  assert(x)
+#define CTASSERT(x)_Static_assert(x, "CTASSERT " #x)
 #endif /* _KERNEL */
 
 #define CHACHA_EMBED

Modified: head/sys/dev/random/hash.h
==
--- head/sys/dev/random/hash.h  Mon Jun 17 14:42:27 2019(r349136)
+++ head/sys/dev/random/hash.h  Mon Jun 17 14:59:45 2019(r349137)
@@ -54,7 +54,7 @@ union randomdev_key {
struct chacha_ctx chacha;
 };
 
-extern bool fortuna_chachamode;
+extern bool random_chachamode;
 
 void randomdev_hash_init(struct randomdev_hash *);
 void randomdev_hash_iterate(struct randomdev_hash *, const void *, size_t);

Modified: head/tests/sys/Makefile
==
--- head/tests/sys/Makefile Mon Jun 17 14:42:27 2019(r349136)
+++ head/tests/sys/Makefile Mon Jun 17 14:59:45 2019(r349137)
@@ -10,6 +10,7 @@ TESTS_SUBDIRS+=   ${_audit}
 TESTS_SUBDIRS+=auditpipe
 TESTS_SUBDIRS+=capsicum
 TESTS_SUBDIRS+=${_cddl}
+TESTS_SUBDIRS+=devrandom
 TESTS_SUBDIRS+=fifo
 TESTS_SUBDIRS+=file
 TESTS_SUBDIRS+=fs

Added: head/tests/sys/devrandom/Makefile
==
--- /dev/null   00:00:00 1970   (empty, because file is newly added)
+++ head/tests/sys/devrandom/Makefile   Mon Jun 17 14:59:45 2019
(r349137)
@@ -0,0 +1,26 @@
+# $FreeBSD$
+
+.include 
+
+SDEVRANDOM=${SRCTOP}/sys/dev/random
+.PATH: ${SDEVRANDOM}
+
+TESTSDIR=  ${TESTSBASE}/sys/devrandom
+WARNS?=6
+
+CFLAGS+=   -I${SRCTOP}/sys
+
+ATF_TESTS_C+=  uint128_test
+
+# Test Chacha CTR behavior <-> uint128
+LDADD.uint128_test+=   ${SDEVRANDOM}/hash.c
+LDFLAGS.uint128_test+= -Wno-unused-parameter
+
+# hash.c deps:
+LIBADD.uint128_test+=  md  # SHA256
+LDADD.uint128_test+=   ${SRCTOP}/sys/crypto/rijndael/rijndael-alg-fst.c
+LDADD.uint128_test+=   ${SRCTOP}/sys/crypto/rijndael/rijndael-api-fst.c
+LDFLAGS.uint128_test+= -Wno-cast-align
+
+
+.include 

Added: head/tests/sys/devrandom/uint128_test.c
==
--- /dev/null   00:00:00 1970   (empty, because file is newly added)
+++ head/tests/sys/devrandom/uint128_test.c Mon Jun 17 14:59:45 2019
(r349137)
@@ -0,0 +1,225 @@
+/*-
+ * SPDX-License-Identifier: BSD-2-Clause-FreeBSD
+ *
+ * Copyright (c) 2019 Conrad Meyer 
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. 

Re: svn commit: r349135 - in head: contrib/libarchive/libarchive contrib/libarchive/libarchive/test lib/libarchive/tests

2019-06-17 Thread Cy Schubert
Even this was inappropriate. My apologies.


-- 
Cheers,
Cy Schubert 
FreeBSD UNIX: Web:  http://www.FreeBSD.org

The need of the many outweighs the greed of the few.



In message <201906171407.x5he7en5036...@slippy.cwsent.com>, Cy Schubert 
writes:
> I could say something rhetorical and in bad taste here. This speaks for 
> itself.
>
>
> -- 
> Cheers,
> Cy Schubert 
> FreeBSD UNIX: Web:  http://www.FreeBSD.org
>
>   The need of the many outweighs the greed of the few.
>
>
> In message , Martin 
> Matuska w
> rites:
> > Due to lack of resources we (libarchive) are currently not publishing 
> > CVE information.
> > Most of our security fixes are patches for issues discovered by Google's 
> > OSS-Fuzz project.
> > These issues are made public 30 days after they have been detected as 
> > fixed or 90 days after being discovered.
> >
> > I can provide links to published issues at OSS-Fuzz.
> >
> > Am 17.06.19 um 14:17 schrieb Cy Schubert:
> > > In message <201906171146.x5hbkbcc019...@repo.freebsd.org>, Martin
> > > Matuska write
> > > s:
> > >> Author: mm
> > >> Date: Mon Jun 17 11:46:37 2019
> > >> New Revision: 349135
> > >> URL: https://svnweb.freebsd.org/changeset/base/349135
> > >>
> > >> Log:
> > >>MFV r349134:
> > >>Sync libarchive with vendor.
> > >>
> > >>Relevant vendor changes:
> > >>  PR #1212: RAR5 reader - window_mask was not updated correctly
> > >>(OSS-Fuzz 15278)
> > >>  OSS-Fuzz 15120: RAR reader - extend use after free bugfix
> > > Did our upline document a CVE for this?
> > >
> > >>
> > >>MFC after:1 week (together with r348993)
> > >>
> > >> Added:
> > >>head/contrib/libarchive/libarchive/test/test_read_format_rar5_differe
> nt
> > _win
> > >> dow_size.rar.uu
> > >>   - copied unchanged from r349134, vendor/libarchive/dist/libarchive
> /t
> > est/
> > >> test_read_format_rar5_different_window_size.rar.uu
> > >>head/contrib/libarchive/libarchive/test/test_read_format_rar_ppmd_use
> _a
> > fter
> > >> _free2.rar.uu
> > >>   - copied unchanged from r349134, vendor/libarchive/dist/libarchive
> /t
> > est/
> > >> test_read_format_rar_ppmd_use_after_free2.rar.uu
> > >> Modified:
> > >>head/contrib/libarchive/libarchive/archive_read_support_format_rar.c
> > >>head/contrib/libarchive/libarchive/archive_read_support_format_rar5.c
> > >>head/contrib/libarchive/libarchive/test/test_read_format_rar.c
> > >>head/contrib/libarchive/libarchive/test/test_read_format_rar5.c
> > >>head/lib/libarchive/tests/Makefile
> > >> Directory Properties:
> > >>head/contrib/libarchive/   (props changed)
> > >>
> > > [...]
> > >
> > >
>


___
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: r349135 - in head: contrib/libarchive/libarchive contrib/libarchive/libarchive/test lib/libarchive/tests

2019-06-17 Thread Cy Schubert
I could say something rhetorical and in bad taste here. This speaks for 
itself.


-- 
Cheers,
Cy Schubert 
FreeBSD UNIX: Web:  http://www.FreeBSD.org

The need of the many outweighs the greed of the few.


In message , Martin 
Matuska w
rites:
> Due to lack of resources we (libarchive) are currently not publishing 
> CVE information.
> Most of our security fixes are patches for issues discovered by Google's 
> OSS-Fuzz project.
> These issues are made public 30 days after they have been detected as 
> fixed or 90 days after being discovered.
>
> I can provide links to published issues at OSS-Fuzz.
>
> Am 17.06.19 um 14:17 schrieb Cy Schubert:
> > In message <201906171146.x5hbkbcc019...@repo.freebsd.org>, Martin
> > Matuska write
> > s:
> >> Author: mm
> >> Date: Mon Jun 17 11:46:37 2019
> >> New Revision: 349135
> >> URL: https://svnweb.freebsd.org/changeset/base/349135
> >>
> >> Log:
> >>MFV r349134:
> >>Sync libarchive with vendor.
> >>
> >>Relevant vendor changes:
> >>  PR #1212: RAR5 reader - window_mask was not updated correctly
> >>(OSS-Fuzz 15278)
> >>  OSS-Fuzz 15120: RAR reader - extend use after free bugfix
> > Did our upline document a CVE for this?
> >
> >>
> >>MFC after:  1 week (together with r348993)
> >>
> >> Added:
> >>head/contrib/libarchive/libarchive/test/test_read_format_rar5_different
> _win
> >> dow_size.rar.uu
> >>   - copied unchanged from r349134, vendor/libarchive/dist/libarchive/t
> est/
> >> test_read_format_rar5_different_window_size.rar.uu
> >>head/contrib/libarchive/libarchive/test/test_read_format_rar_ppmd_use_a
> fter
> >> _free2.rar.uu
> >>   - copied unchanged from r349134, vendor/libarchive/dist/libarchive/t
> est/
> >> test_read_format_rar_ppmd_use_after_free2.rar.uu
> >> Modified:
> >>head/contrib/libarchive/libarchive/archive_read_support_format_rar.c
> >>head/contrib/libarchive/libarchive/archive_read_support_format_rar5.c
> >>head/contrib/libarchive/libarchive/test/test_read_format_rar.c
> >>head/contrib/libarchive/libarchive/test/test_read_format_rar5.c
> >>head/lib/libarchive/tests/Makefile
> >> Directory Properties:
> >>head/contrib/libarchive/   (props changed)
> >>
> > [...]
> >
> >


___
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: r349135 - in head: contrib/libarchive/libarchive contrib/libarchive/libarchive/test lib/libarchive/tests

2019-06-17 Thread Martin Matuska
Due to lack of resources we (libarchive) are currently not publishing 
CVE information.
Most of our security fixes are patches for issues discovered by Google's 
OSS-Fuzz project.
These issues are made public 30 days after they have been detected as 
fixed or 90 days after being discovered.


I can provide links to published issues at OSS-Fuzz.

Am 17.06.19 um 14:17 schrieb Cy Schubert:

In message <201906171146.x5hbkbcc019...@repo.freebsd.org>, Martin
Matuska write
s:

Author: mm
Date: Mon Jun 17 11:46:37 2019
New Revision: 349135
URL: https://svnweb.freebsd.org/changeset/base/349135

Log:
   MFV r349134:
   Sync libarchive with vendor.
   
   Relevant vendor changes:

 PR #1212: RAR5 reader - window_mask was not updated correctly
   (OSS-Fuzz 15278)
 OSS-Fuzz 15120: RAR reader - extend use after free bugfix

Did our upline document a CVE for this?

   
   MFC after:	1 week (together with r348993)


Added:
   head/contrib/libarchive/libarchive/test/test_read_format_rar5_different_win
dow_size.rar.uu
  - copied unchanged from r349134, vendor/libarchive/dist/libarchive/test/
test_read_format_rar5_different_window_size.rar.uu
   head/contrib/libarchive/libarchive/test/test_read_format_rar_ppmd_use_after
_free2.rar.uu
  - copied unchanged from r349134, vendor/libarchive/dist/libarchive/test/
test_read_format_rar_ppmd_use_after_free2.rar.uu
Modified:
   head/contrib/libarchive/libarchive/archive_read_support_format_rar.c
   head/contrib/libarchive/libarchive/archive_read_support_format_rar5.c
   head/contrib/libarchive/libarchive/test/test_read_format_rar.c
   head/contrib/libarchive/libarchive/test/test_read_format_rar5.c
   head/lib/libarchive/tests/Makefile
Directory Properties:
   head/contrib/libarchive/   (props changed)


[...]



___
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: r349135 - in head: contrib/libarchive/libarchive contrib/libarchive/libarchive/test lib/libarchive/tests

2019-06-17 Thread Cy Schubert
In message <201906171146.x5hbkbcc019...@repo.freebsd.org>, Martin 
Matuska write
s:
> Author: mm
> Date: Mon Jun 17 11:46:37 2019
> New Revision: 349135
> URL: https://svnweb.freebsd.org/changeset/base/349135
>
> Log:
>   MFV r349134:
>   Sync libarchive with vendor.
>   
>   Relevant vendor changes:
> PR #1212: RAR5 reader - window_mask was not updated correctly
>   (OSS-Fuzz 15278)
> OSS-Fuzz 15120: RAR reader - extend use after free bugfix

Did our upline document a CVE for this?

>   
>   MFC after:  1 week (together with r348993)
>
> Added:
>   head/contrib/libarchive/libarchive/test/test_read_format_rar5_different_win
> dow_size.rar.uu
>  - copied unchanged from r349134, vendor/libarchive/dist/libarchive/test/
> test_read_format_rar5_different_window_size.rar.uu
>   head/contrib/libarchive/libarchive/test/test_read_format_rar_ppmd_use_after
> _free2.rar.uu
>  - copied unchanged from r349134, vendor/libarchive/dist/libarchive/test/
> test_read_format_rar_ppmd_use_after_free2.rar.uu
> Modified:
>   head/contrib/libarchive/libarchive/archive_read_support_format_rar.c
>   head/contrib/libarchive/libarchive/archive_read_support_format_rar5.c
>   head/contrib/libarchive/libarchive/test/test_read_format_rar.c
>   head/contrib/libarchive/libarchive/test/test_read_format_rar5.c
>   head/lib/libarchive/tests/Makefile
> Directory Properties:
>   head/contrib/libarchive/   (props changed)
>
[...]


-- 
Cheers,
Cy Schubert 
FreeBSD UNIX: Web:  http://www.FreeBSD.org

The need of the many outweighs the greed of the few.


___
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: r349135 - in head: contrib/libarchive/libarchive contrib/libarchive/libarchive/test lib/libarchive/tests

2019-06-17 Thread Martin Matuska
Author: mm
Date: Mon Jun 17 11:46:37 2019
New Revision: 349135
URL: https://svnweb.freebsd.org/changeset/base/349135

Log:
  MFV r349134:
  Sync libarchive with vendor.
  
  Relevant vendor changes:
PR #1212: RAR5 reader - window_mask was not updated correctly
  (OSS-Fuzz 15278)
OSS-Fuzz 15120: RAR reader - extend use after free bugfix
  
  MFC after:1 week (together with r348993)

Added:
  
head/contrib/libarchive/libarchive/test/test_read_format_rar5_different_window_size.rar.uu
 - copied unchanged from r349134, 
vendor/libarchive/dist/libarchive/test/test_read_format_rar5_different_window_size.rar.uu
  
head/contrib/libarchive/libarchive/test/test_read_format_rar_ppmd_use_after_free2.rar.uu
 - copied unchanged from r349134, 
vendor/libarchive/dist/libarchive/test/test_read_format_rar_ppmd_use_after_free2.rar.uu
Modified:
  head/contrib/libarchive/libarchive/archive_read_support_format_rar.c
  head/contrib/libarchive/libarchive/archive_read_support_format_rar5.c
  head/contrib/libarchive/libarchive/test/test_read_format_rar.c
  head/contrib/libarchive/libarchive/test/test_read_format_rar5.c
  head/lib/libarchive/tests/Makefile
Directory Properties:
  head/contrib/libarchive/   (props changed)

Modified: head/contrib/libarchive/libarchive/archive_read_support_format_rar.c
==
--- head/contrib/libarchive/libarchive/archive_read_support_format_rar.c
Mon Jun 17 11:29:32 2019(r349134)
+++ head/contrib/libarchive/libarchive/archive_read_support_format_rar.c
Mon Jun 17 11:46:37 2019(r349135)
@@ -1027,6 +1027,7 @@ archive_read_format_rar_read_data(struct archive_read 
 if (ret != ARCHIVE_OK && ret != ARCHIVE_WARN) {
   __archive_ppmd7_functions.Ppmd7_Free(>ppmd7_context);
   rar->start_new_table = 1;
+  rar->ppmd_valid = 0;
 }
 break;
 

Modified: head/contrib/libarchive/libarchive/archive_read_support_format_rar5.c
==
--- head/contrib/libarchive/libarchive/archive_read_support_format_rar5.c   
Mon Jun 17 11:29:32 2019(r349134)
+++ head/contrib/libarchive/libarchive/archive_read_support_format_rar5.c   
Mon Jun 17 11:46:37 2019(r349135)
@@ -1125,6 +1125,13 @@ static void init_header(struct archive_read* a) {
a->archive.archive_format_name = "RAR5";
 }
 
+static void init_window_mask(struct rar5* rar) {
+   if (rar->cstate.window_size)
+   rar->cstate.window_mask = rar->cstate.window_size - 1;
+   else
+   rar->cstate.window_mask = 0;
+}
+
 enum HEADER_FLAGS {
HFL_EXTRA_DATA = 0x0001,
HFL_DATA = 0x0002,
@@ -1672,6 +1679,7 @@ static int process_head_file(struct archive_read* a, s
/* Values up to 64M should fit into ssize_t on every
 * architecture. */
rar->cstate.window_size = (ssize_t) window_size;
+   init_window_mask(rar);
 
rar->file.solid = (compression_info & SOLID) > 0;
rar->file.service = 0;
@@ -2235,10 +2243,7 @@ static int rar5_read_header(struct archive_read *a,
 
 static void init_unpack(struct rar5* rar) {
rar->file.calculated_crc32 = 0;
-   if (rar->cstate.window_size)
-   rar->cstate.window_mask = rar->cstate.window_size - 1;
-   else
-   rar->cstate.window_mask = 0;
+   init_window_mask(rar);
 
free(rar->cstate.window_buf);
free(rar->cstate.filtered_buf);
@@ -2851,7 +2856,7 @@ static int do_uncompress_block(struct archive_read* a,
 * - Values lower than 256 are just bytes. Those codes
 *   can be stored in the output buffer directly.
 *
-* - Code 256 defines a new filter, which is later used to 
+* - Code 256 defines a new filter, which is later used to
 *   ransform the data block accordingly to the filter type.
 *   The data block needs to be fully uncompressed first.
 *
@@ -3906,7 +3911,7 @@ static int rar5_read_data_skip(struct archive_read *a)
/* Turn off "skip mode". */
rar->skip_mode--;
 
-   if(ret < 0) {
+   if(ret < 0 || ret == ARCHIVE_EOF) {
/* Propagate any potential error conditions
 * to the caller. */
return ret;

Modified: head/contrib/libarchive/libarchive/test/test_read_format_rar.c
==
--- head/contrib/libarchive/libarchive/test/test_read_format_rar.c  Mon Jun 
17 11:29:32 2019(r349134)
+++ head/contrib/libarchive/libarchive/test/test_read_format_rar.c  Mon Jun 
17 11:46:37 2019(r349135)
@@ -3776,6 +3776,35 @@ 

Re: svn commit: r349133 - head/share/man/man4

2019-06-17 Thread Niclas Zeising

On 2019-06-17 12:27, Niclas Zeising wrote:

On 2019-06-17 11:03, Rodney W. Grimes wrote:

On 2019-06-17 09:56, Benjamin Kaduk wrote:

On Sun, Jun 16, 2019 at 10:42 PM Niclas Zeising mailto:zeis...@freebsd.org>> wrote:

 Author: zeising (doc,ports committer)
 Date: Mon Jun 17 05:41:47 2019
 New Revision: 349133
 URL: https://svnweb.freebsd.org/changeset/base/349133

 Log:
  ? pci(4): Document PCIOCATTACHED

  ? Document the PCIOCATTACHED ioctl(2) in the pci(4) manual.
  ? PCIOCATTACHED is used to query if a driver has attached to a 
PCI.


  ? Reviewed by:? bcr, imp
  ? MFC after:? ? 2 weeks
  ? Differential Revision: https://reviews.freebsd.org/D20652

 Modified:
  ? head/share/man/man4/pci.4

 Modified: head/share/man/man4/pci.4
 
== 


 --- head/share/man/man4/pci.4? ?Mon Jun 17 03:48:44 2019
 (r349132)
 +++ head/share/man/man4/pci.4? ?Mon Jun 17 05:41:47 2019
 (r349133)
 @@ -24,7 +24,7 @@
  ?.\"
  ?.\" $FreeBSD$
  ?.\"
 -.Dd June 14, 2018
 +.Dd June 17, 2019
  ?.Dt PCI 4
  ?.Os
  ?.Sh NAME
 @@ -333,6 +333,26 @@ The limitations on data width described for
  ?reading registers, above, also apply to writing
  ?.Tn PCI
  ?configuration registers.
 +.It PCIOCATTACHED
 +This
 +.Xr ioctl 2
 +allows users to query if a driver is attached to the
 +.Tn PCI
 +specified in the passed-in


Is there a missing word like "device" here?


Actally I think the missing word, in both cases, is register,
unless I am misreading some part of the manual page and
what a struct pci_io points at.  I guess if the pi_reg is null
then this would be device.  Either way there is defanity a
missing word.


I'll try to fix this.  In the PCIOCWRITE case, perhaps register is best, 
however, inthe PCIOCATTACHED case, device is best, I think.
I'll create a patch and put it for review, I'll get back to you once 
it's done.

Regards



Here's the review with my proposed change.  Let me know what you think.
https://reviews.freebsd.org/D20671

Regards
--
Niclas Zeising
___
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: r349133 - head/share/man/man4

2019-06-17 Thread Niclas Zeising

On 2019-06-17 11:03, Rodney W. Grimes wrote:

On 2019-06-17 09:56, Benjamin Kaduk wrote:

On Sun, Jun 16, 2019 at 10:42 PM Niclas Zeising mailto:zeis...@freebsd.org>> wrote:

 Author: zeising (doc,ports committer)
 Date: Mon Jun 17 05:41:47 2019
 New Revision: 349133
 URL: https://svnweb.freebsd.org/changeset/base/349133

 Log:
  ? pci(4): Document PCIOCATTACHED

  ? Document the PCIOCATTACHED ioctl(2) in the pci(4) manual.
  ? PCIOCATTACHED is used to query if a driver has attached to a PCI.

  ? Reviewed by:? bcr, imp
  ? MFC after:? ? 2 weeks
  ? Differential Revision: https://reviews.freebsd.org/D20652

 Modified:
  ? head/share/man/man4/pci.4

 Modified: head/share/man/man4/pci.4
 
==
 --- head/share/man/man4/pci.4? ?Mon Jun 17 03:48:44 2019
 (r349132)
 +++ head/share/man/man4/pci.4? ?Mon Jun 17 05:41:47 2019
 (r349133)
 @@ -24,7 +24,7 @@
  ?.\"
  ?.\" $FreeBSD$
  ?.\"
 -.Dd June 14, 2018
 +.Dd June 17, 2019
  ?.Dt PCI 4
  ?.Os
  ?.Sh NAME
 @@ -333,6 +333,26 @@ The limitations on data width described for
  ?reading registers, above, also apply to writing
  ?.Tn PCI
  ?configuration registers.
 +.It PCIOCATTACHED
 +This
 +.Xr ioctl 2
 +allows users to query if a driver is attached to the
 +.Tn PCI
 +specified in the passed-in


Is there a missing word like "device" here?


Actally I think the missing word, in both cases, is register,
unless I am misreading some part of the manual page and
what a struct pci_io points at.  I guess if the pi_reg is null
then this would be device.  Either way there is defanity a
missing word.


I'll try to fix this.  In the PCIOCWRITE case, perhaps register is best, 
however, inthe PCIOCATTACHED case, device is best, I think.
I'll create a patch and put it for review, I'll get back to you once 
it's done.

Regards





I just followed the same syntax as for the PCIOCWRITE ioctl in the
paragraph before.


Probably a mistake there too.


I found it a little strange when I read it, but I
kind of assumed there was a reason it said PCI and not PCI device,
perhaps similar to using RAM instead of RAM memory, if you understand
what I mean.


RAM memory == Random Access Memory Memory
PCI == Peripheral Component Interconnect
PCI {Register, Device, Bus} all make valid sense,
PCI alone does not.


Regards
Niclas



 +.Va pci_io
 +structure.
 +The
 +.Va pci_io
 +structure is described above, however, the
 +.Va pi_reg
 +and
 +.Va pi_width
 +fields are not used.
 +The status of the device is stored in the
 +.Va pi_data
 +field.
 +A value of 0 indicates no driver is attached, while a value larger
 than 0
 +indicates that a driver is attached.
  ?.It PCIOCBARMMAP
  ?This
  ?.Xr ioctl 2



--
Niclas Zeising








--
Niclas Zeising
___
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: r349133 - head/share/man/man4

2019-06-17 Thread Rodney W. Grimes
> On 2019-06-17 09:56, Benjamin Kaduk wrote:
> > On Sun, Jun 16, 2019 at 10:42 PM Niclas Zeising  > > wrote:
> > 
> > Author: zeising (doc,ports committer)
> > Date: Mon Jun 17 05:41:47 2019
> > New Revision: 349133
> > URL: https://svnweb.freebsd.org/changeset/base/349133
> > 
> > Log:
> >  ? pci(4): Document PCIOCATTACHED
> > 
> >  ? Document the PCIOCATTACHED ioctl(2) in the pci(4) manual.
> >  ? PCIOCATTACHED is used to query if a driver has attached to a PCI.
> > 
> >  ? Reviewed by:? bcr, imp
> >  ? MFC after:? ? 2 weeks
> >  ? Differential Revision: https://reviews.freebsd.org/D20652
> > 
> > Modified:
> >  ? head/share/man/man4/pci.4
> > 
> > Modified: head/share/man/man4/pci.4
> > 
> > ==
> > --- head/share/man/man4/pci.4? ?Mon Jun 17 03:48:44 2019   
> > (r349132)
> > +++ head/share/man/man4/pci.4? ?Mon Jun 17 05:41:47 2019   
> > (r349133)
> > @@ -24,7 +24,7 @@
> >  ?.\"
> >  ?.\" $FreeBSD$
> >  ?.\"
> > -.Dd June 14, 2018
> > +.Dd June 17, 2019
> >  ?.Dt PCI 4
> >  ?.Os
> >  ?.Sh NAME
> > @@ -333,6 +333,26 @@ The limitations on data width described for
> >  ?reading registers, above, also apply to writing
> >  ?.Tn PCI
> >  ?configuration registers.
> > +.It PCIOCATTACHED
> > +This
> > +.Xr ioctl 2
> > +allows users to query if a driver is attached to the
> > +.Tn PCI
> > +specified in the passed-in
> > 
> > 
> > Is there a missing word like "device" here?

Actally I think the missing word, in both cases, is register,
unless I am misreading some part of the manual page and
what a struct pci_io points at.  I guess if the pi_reg is null
then this would be device.  Either way there is defanity a
missing word.

> 
> I just followed the same syntax as for the PCIOCWRITE ioctl in the 
> paragraph before. 

Probably a mistake there too.

> I found it a little strange when I read it, but I 
> kind of assumed there was a reason it said PCI and not PCI device, 
> perhaps similar to using RAM instead of RAM memory, if you understand 
> what I mean.

RAM memory == Random Access Memory Memory
PCI == Peripheral Component Interconnect
PCI {Register, Device, Bus} all make valid sense,
PCI alone does not.

> Regards
> Niclas
> 
> > 
> > +.Va pci_io
> > +structure.
> > +The
> > +.Va pci_io
> > +structure is described above, however, the
> > +.Va pi_reg
> > +and
> > +.Va pi_width
> > +fields are not used.
> > +The status of the device is stored in the
> > +.Va pi_data
> > +field.
> > +A value of 0 indicates no driver is attached, while a value larger
> > than 0
> > +indicates that a driver is attached.
> >  ?.It PCIOCBARMMAP
> >  ?This
> >  ?.Xr ioctl 2
> 
> 
> -- 
> Niclas Zeising
> 
> 
> 

-- 
Rod Grimes rgri...@freebsd.org
___
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: r349133 - head/share/man/man4

2019-06-17 Thread Niclas Zeising

On 2019-06-17 09:56, Benjamin Kaduk wrote:
On Sun, Jun 16, 2019 at 10:42 PM Niclas Zeising > wrote:


Author: zeising (doc,ports committer)
Date: Mon Jun 17 05:41:47 2019
New Revision: 349133
URL: https://svnweb.freebsd.org/changeset/base/349133

Log:
   pci(4): Document PCIOCATTACHED

   Document the PCIOCATTACHED ioctl(2) in the pci(4) manual.
   PCIOCATTACHED is used to query if a driver has attached to a PCI.

   Reviewed by:  bcr, imp
   MFC after:    2 weeks
   Differential Revision: https://reviews.freebsd.org/D20652

Modified:
   head/share/man/man4/pci.4

Modified: head/share/man/man4/pci.4

==
--- head/share/man/man4/pci.4   Mon Jun 17 03:48:44 2019   
(r349132)
+++ head/share/man/man4/pci.4   Mon Jun 17 05:41:47 2019   
(r349133)

@@ -24,7 +24,7 @@
  .\"
  .\" $FreeBSD$
  .\"
-.Dd June 14, 2018
+.Dd June 17, 2019
  .Dt PCI 4
  .Os
  .Sh NAME
@@ -333,6 +333,26 @@ The limitations on data width described for
  reading registers, above, also apply to writing
  .Tn PCI
  configuration registers.
+.It PCIOCATTACHED
+This
+.Xr ioctl 2
+allows users to query if a driver is attached to the
+.Tn PCI
+specified in the passed-in


Is there a missing word like "device" here?


I just followed the same syntax as for the PCIOCWRITE ioctl in the 
paragraph before.  I found it a little strange when I read it, but I 
kind of assumed there was a reason it said PCI and not PCI device, 
perhaps similar to using RAM instead of RAM memory, if you understand 
what I mean.

Regards
Niclas



+.Va pci_io
+structure.
+The
+.Va pci_io
+structure is described above, however, the
+.Va pi_reg
+and
+.Va pi_width
+fields are not used.
+The status of the device is stored in the
+.Va pi_data
+field.
+A value of 0 indicates no driver is attached, while a value larger
than 0
+indicates that a driver is attached.
  .It PCIOCBARMMAP
  This
  .Xr ioctl 2



--
Niclas Zeising
___
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: r349133 - head/share/man/man4

2019-06-17 Thread Benjamin Kaduk
On Sun, Jun 16, 2019 at 10:42 PM Niclas Zeising  wrote:

> Author: zeising (doc,ports committer)
> Date: Mon Jun 17 05:41:47 2019
> New Revision: 349133
> URL: https://svnweb.freebsd.org/changeset/base/349133
>
> Log:
>   pci(4): Document PCIOCATTACHED
>
>   Document the PCIOCATTACHED ioctl(2) in the pci(4) manual.
>   PCIOCATTACHED is used to query if a driver has attached to a PCI.
>
>   Reviewed by:  bcr, imp
>   MFC after:2 weeks
>   Differential Revision:https://reviews.freebsd.org/D20652
>
> Modified:
>   head/share/man/man4/pci.4
>
> Modified: head/share/man/man4/pci.4
>
> ==
> --- head/share/man/man4/pci.4   Mon Jun 17 03:48:44 2019(r349132)
> +++ head/share/man/man4/pci.4   Mon Jun 17 05:41:47 2019(r349133)
> @@ -24,7 +24,7 @@
>  .\"
>  .\" $FreeBSD$
>  .\"
> -.Dd June 14, 2018
> +.Dd June 17, 2019
>  .Dt PCI 4
>  .Os
>  .Sh NAME
> @@ -333,6 +333,26 @@ The limitations on data width described for
>  reading registers, above, also apply to writing
>  .Tn PCI
>  configuration registers.
> +.It PCIOCATTACHED
> +This
> +.Xr ioctl 2
> +allows users to query if a driver is attached to the
> +.Tn PCI
> +specified in the passed-in
>

Is there a missing word like "device" here?

Thanks,

Ben


> +.Va pci_io
> +structure.
> +The
> +.Va pci_io
> +structure is described above, however, the
> +.Va pi_reg
> +and
> +.Va pi_width
> +fields are not used.
> +The status of the device is stored in the
> +.Va pi_data
> +field.
> +A value of 0 indicates no driver is attached, while a value larger than 0
> +indicates that a driver is attached.
>  .It PCIOCBARMMAP
>  This
>  .Xr ioctl 2
> ___
> svn-src-...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/svn-src-all
> To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
>
___
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"