Re: [Patch] mg(1) tutorial: no columns :(

2018-05-27 Thread Florian Obser
On Fri, May 25, 2018 at 02:42:07PM -0400, Brian Callahan wrote:
> 
> 
> On 05/25/18 10:25, Leonid Bobrov wrote:
> > Mentioning would be nice.
> > 
> > display.c's 1.39 revision log says "off by default
> > to not kill slow serial lines" -_-
> > 
> 
> Then why not write that diff?
> Something like the below, maybe? I'm not totally sold that we need it, but am 
> not unsold either. I could go either way, depending on what others think.
> 
> ~Brian
> 
> Index: tutorial
> ===
> RCS file: /cvs/src/usr.bin/mg/tutorial,v
> retrieving revision 1.17
> diff -u -p -r1.17 tutorial
> --- tutorial    30 May 2017 07:11:40 -    1.17
> +++ tutorial    25 May 2018 18:34:32 -
> @@ -218,10 +218,11 @@ you're editing a file named "tutorial".
>  saved it, it should have a "**" to the left of those words. If this file is
>  read-only, you should see a "%%" to the left of those words.
> 
> -To the right of the status line, you should see L followed by digits and C
> -followed by some more digits. These indicate the line number and column 
> number
> -of the file that your cursor is currently on. If you move the cursor around,
> -you should see the line and column number change.
> +To the right of the status line, you should see L followed by digits and, if
> +column-number-mode is enabled, C followed by some more digits. These indicate
> +the line number and column number of the file that your cursor is currently
> +on. If you move the cursor around, you should see the line and column number
> +change.
> 
>  In the middle of the screen, you should see the word "(fundamental)" which
>  indicates that the current editing mode is "fundamental-mode". The mg editor
> 

I think we should mention how to enable column-number-mode like Leonid
pointed out, but I don't think we need to move this whole block all
the way to the end. It's ok that M-x is not yet explained in my opinion.

This one is OK florian@ if you want to commit it.

diff --git tutorial tutorial
index f015d10cd60..6897b1c9102 100644
--- tutorial
+++ tutorial
@@ -218,10 +218,12 @@ you're editing a file named "tutorial". If you've edited 
this file and not
 saved it, it should have a "**" to the left of those words. If this file is 
 read-only, you should see a "%%" to the left of those words. 
 
-To the right of the status line, you should see L followed by digits and C
-followed by some more digits. These indicate the line number and column number
-of the file that your cursor is currently on. If you move the cursor around,
-you should see the line and column number change.
+To the right of the status line, you should see L followed by digits
+and, if column-number-mode is enabled, C followed by some more digits.
+Type M-x column-number-mode Enter to enable it if it is disabled (the
+default). These indicate the line number and column number of the file
+that your cursor is currently on. If you move the cursor around, you
+should see the line and column number change.
 
 In the middle of the screen, you should see the word "(fundamental)" which 
 indicates that the current editing mode is "fundamental-mode". The mg editor
@@ -346,7 +348,7 @@ Author Info
 ---
 
 Original Author of this document: Mayukh Bose, 
-Date last updated: 2015-12-21
+Date last updated: 2018-05-27
 
 Copyright
 -


-- 
I'm not entirely sure you are real.



Re: add clock_nanosleep(2)

2018-05-27 Thread Martin Pieuchot
On 26/05/18(Sat) 17:49, Scott Cheloha wrote:
> Index: sys/kern/kern_synch.c
> ===
> RCS file: /cvs/src/sys/kern/kern_synch.c,v
> retrieving revision 1.144
> diff -u -p -r1.144 kern_synch.c
> --- sys/kern/kern_synch.c 24 Apr 2018 16:28:42 -  1.144
> +++ sys/kern/kern_synch.c 26 May 2018 22:42:21 -
> @@ -236,31 +236,32 @@ msleep(const volatile void *ident, struc
>   * entered the sleep queue we drop the it. After sleeping we re-lock.
>   */
>  int
> -rwsleep(const volatile void *ident, struct rwlock *wl, int priority,
> +rwsleep(const volatile void *ident, struct rwlock *rwl, int priority,
>  const char *wmesg, int timo)
>  {
>   struct sleep_state sls;
> - int error, error1;
> + int error, error1, status;
>   WITNESS_SAVE_DECL(lock_fl);
>  
>   KASSERT((priority & ~(PRIMASK | PCATCH | PNORELOCK)) == 0);
> - rw_assert_wrlock(wl);
> + rw_assert_anylock(rwl);
> + status = rw_status(rwl);
>  
>   sleep_setup(&sls, ident, priority, wmesg);
>   sleep_setup_timeout(&sls, timo);
>   sleep_setup_signal(&sls, priority);
>  
> - WITNESS_SAVE(&wl->rwl_lock_obj, lock_fl);
> + WITNESS_SAVE(&rwl->rwl_lock_obj, lock_fl);
>  
> - rw_exit_write(wl);
> + rw_exit(rwl);
>  
>   sleep_finish(&sls, 1);
>   error1 = sleep_finish_timeout(&sls);
>   error = sleep_finish_signal(&sls);
>  
>   if ((priority & PNORELOCK) == 0) {
> - rw_enter_write(wl);
> - WITNESS_RESTORE(&wl->rwl_lock_obj, lock_fl);
> + rw_enter(rwl, status);
> + WITNESS_RESTORE(&rwl->rwl_lock_obj, lock_fl);
>   }
>  
>   /* Signal errors are higher priority than timeouts. */

The rwsleep() and corresponding man page changes are ok with me and can
already be committed.



vfs_cache.9: sync with

2018-05-27 Thread Klemens Nanni
Spotted and reported on IRC by Georg Bege ,
vfs_cache(9) lacks way behind beck's "Namecache revamp" from 2009.

This diff syncs the manual with sys/sys/namei.h and sys/kern/vfs_cache.c:
I went through it and checked the APIs, this seems fine to me for now
but since I'm not all too familiar with VFS yet, feedback is welcome.

Maybe we want to sync descriptions in the manual a bit more with code
comments to reduce differences in two places describing the same thing?

Index: vfs_cache.9
===
RCS file: /cvs/src/share/man/man9/vfs_cache.9,v
retrieving revision 1.3
diff -u -p -r1.3 vfs_cache.9
--- vfs_cache.9 31 May 2007 19:20:01 -  1.3
+++ vfs_cache.9 27 May 2018 14:04:18 -
@@ -37,15 +37,16 @@ recently looked-up file name translation
 Entries in this cache have the following definition:
 .Bd -literal
 struct namecache {
-   LIST_ENTRY(namecache) nc_hash;  /* hash chain */
-   LIST_ENTRY(namecache) nc_vhash; /* (reverse) dir hash chain */
-   TAILQ_ENTRY(namecache) nc_lru;  /* LRU chain */
+   TAILQ_ENTRY(namecache) nc_lru;  /* Regular Entry LRU chain */
+   TAILQ_ENTRY(namecache) nc_neg;  /* Negative Entry LRU chain */
+   RBT_ENTRY(namecache) n_rbcache; /* Namecache rb tree from vnode */
+   TAILQ_ENTRY(namecache) nc_me;   /* ncp's referring to me */
struct  vnode *nc_dvp;  /* vnode of parent of name */
u_long  nc_dvpid;   /* capability number of nc_dvp */
struct  vnode *nc_vp;   /* vnode the name refers to */
u_long  nc_vpid;/* capability number of nc_vp */
charnc_nlen;/* length of name */
-   charnc_name[NCHNAMLEN]; /* segment name */
+   charnc_name[NAMECACHE_MAXLEN];  /* segment name */
 };
 .Ed
 .Pp
@@ -55,7 +56,7 @@ Negative caching is also performed so th
 names of files that do not exist do not result in expensive lookups.
 .Pp
 File names with length longer than
-.Dv NCHNAMLEN
+.Dv NAMECACHE_MAXLEN
 are not cached to simplify lookups and to save space.
 Such names are rare and are generally not worth caching.
 .Pp
@@ -169,7 +170,8 @@ API is implemented in the file
 .Xr vmstat 8 ,
 .Xr namei 9 ,
 .Xr vfs 9 ,
-.Xr vnode 9
+.Xr vnode 9 ,
+.Xr VOP_LOOKUP 9
 .Sh HISTORY
 The
 .Nm



sximmc(4) SDIO support

2018-05-27 Thread Mark Kettenis
Diff below makes sximmc(4) play nice with our SDIO code.  The
Cubieboard4 (Allwinner A80) isn't entirely happy with this in
combination with bwfm(4).  But as long as you don't bring the
interface that doesn't cause any problems.  There is a power
sequencing glitch that prevents bwfm(4) from attaching anyway.

It seems to work fine on the Banana Pi M2 Berry (Allwinner R40).

The changes are:

- Add SDIO interrupt handling.

- Set a bit to let the CPU access the FIFO.  We inherited this bit
  from U-Boot on the SD/MMC controllers that it brings up, but U-Boot
  doesn't touch the SDIO controllers.

- Fix PIO transfers that are not a multiple of 4 bytes.

- Handle vqmmc-supply.

ok?


Index: dev/fdt/sximmc.c
===
RCS file: /cvs/src/sys/dev/fdt/sximmc.c,v
retrieving revision 1.3
diff -u -p -r1.3 sximmc.c
--- dev/fdt/sximmc.c13 Aug 2017 00:13:07 -  1.3
+++ dev/fdt/sximmc.c27 May 2018 15:00:06 -
@@ -219,6 +219,8 @@ int sximmc_bus_power(sdmmc_chipset_handl
 intsximmc_bus_clock(sdmmc_chipset_handle_t, int, int);
 intsximmc_bus_width(sdmmc_chipset_handle_t, int);
 void   sximmc_exec_command(sdmmc_chipset_handle_t, struct sdmmc_command *);
+void   sximmc_card_intr_mask(sdmmc_chipset_handle_t, int);
+void   sximmc_card_intr_ack(sdmmc_chipset_handle_t);
 
 void   sximmc_pwrseq_pre(uint32_t);
 void   sximmc_pwrseq_post(uint32_t);
@@ -232,6 +234,8 @@ struct sdmmc_chip_functions sximmc_chip_
.bus_clock = sximmc_bus_clock,
.bus_width = sximmc_bus_width,
.exec_command = sximmc_exec_command,
+   .card_intr_mask = sximmc_card_intr_mask,
+   .card_intr_ack = sximmc_card_intr_ack,
 };
 
 struct sximmc_softc {
@@ -265,6 +269,7 @@ struct sximmc_softc {
 
uint32_t sc_gpio[4];
uint32_t sc_vmmc;
+   uint32_t sc_vqmmc;
uint32_t sc_pwrseq;
uint32_t sc_vdd;
 };
@@ -407,6 +412,7 @@ sximmc_attach(struct device *parent, str
gpio_controller_config_pin(sc->sc_gpio, GPIO_CONFIG_INPUT);
 
sc->sc_vmmc = OF_getpropint(sc->sc_node, "vmmc-supply", 0);
+   sc->sc_vqmmc = OF_getpropint(sc->sc_node, "vqmmc-supply", 0);
sc->sc_pwrseq = OF_getpropint(sc->sc_node, "mmc-pwrseq", 0);
 
sc->sc_ih = arm_intr_establish_fdt(faa->fa_node, IPL_BIO,
@@ -489,11 +495,46 @@ sximmc_intr(void *priv)
if (rint) {
sc->sc_intr_rint |= rint;
wakeup(&sc->sc_intr_rint);
+
+   if (rint & SXIMMC_INT_SDIO_INT) {
+   uint32_t imask;
+
+   imask = MMC_READ(sc, SXIMMC_IMASK);
+   imask &= ~SXIMMC_INT_SDIO_INT;
+   MMC_WRITE(sc, SXIMMC_IMASK, imask);
+   sdmmc_card_intr(sc->sc_sdmmc_dev);
+   }
}
 
return 1;
 }
 
+void
+sximmc_card_intr_mask(sdmmc_chipset_handle_t sch, int enable)
+{
+   struct sximmc_softc *sc = sch;
+   uint32_t imask;
+
+   imask = MMC_READ(sc, SXIMMC_IMASK);
+   if (enable)
+   imask |= SXIMMC_INT_SDIO_INT;
+   else
+   imask &= ~SXIMMC_INT_SDIO_INT;
+   MMC_WRITE(sc, SXIMMC_IMASK, imask);
+}
+
+void
+sximmc_card_intr_ack(sdmmc_chipset_handle_t sch)
+{
+   struct sximmc_softc *sc = sch;
+   uint32_t imask;
+
+   MMC_WRITE(sc, SXIMMC_RINT, SXIMMC_INT_SDIO_INT);
+   imask = MMC_READ(sc, SXIMMC_IMASK);
+   imask |= SXIMMC_INT_SDIO_INT;
+   MMC_WRITE(sc, SXIMMC_IMASK, imask);
+}
+
 int
 sximmc_wait_rint(struct sximmc_softc *sc, uint32_t mask, int timeout)
 {
@@ -562,6 +603,10 @@ sximmc_host_reset(sdmmc_chipset_handle_t
printf("%s: host reset succeeded\n", sc->sc_dev.dv_xname);
 #endif
 
+   /* Allow access to the FIFO by the CPU. */
+   MMC_WRITE(sc, SXIMMC_GCTRL,
+   MMC_READ(sc, SXIMMC_GCTRL) | SXIMMC_GCTRL_ACCESS_BY_AHB);
+
MMC_WRITE(sc, SXIMMC_TIMEOUT, 0x);
 
MMC_WRITE(sc, SXIMMC_IMASK,
@@ -625,6 +670,11 @@ sximmc_bus_power(sdmmc_chipset_handle_t 
if (sc->sc_vmmc && vdd > 0)
regulator_enable(sc->sc_vmmc);
 
+   if (sc->sc_vqmmc && vdd > 0)
+   regulator_enable(sc->sc_vqmmc);
+
+   delay(1);
+
if (sc->sc_vdd == 0 && vdd > 0)
sximmc_pwrseq_post(sc->sc_pwrseq);
 
@@ -655,7 +705,7 @@ sximmc_update_clock(struct sximmc_softc 
 
if (retry == 0) {
printf("%s: timeout updating clock\n", sc->sc_dev.dv_xname);
-#ifdef SXIMMC_DEBUG
+#ifndef SXIMMC_DEBUG
printf("GCTRL: 0x%08x\n", MMC_READ(sc, SXIMMC_GCTRL));
printf("CLKCR: 0x%08x\n", MMC_READ(sc, SXIMMC_CLKCR));
printf("TIMEOUT: 0x%08x\n", MMC_READ(sc, SXIMMC_TIMEOUT));
@@ -749,17 +799,34 @@ sximmc_pio_wait(struct sximmc_softc *sc,
 int
 sximmc_pio_transfer(struct sximmc_softc *sc, struct sdmmc_command *cmd)
 {
-   uint32_t *datap = (uint32_t *)cmd->c_data;
-   int i;
+   u_c

Re: errors in usage.c - libusbhid

2018-05-27 Thread Jason McIntyre
On Mon, May 21, 2018 at 11:12:37PM +0200, David Bern wrote:
> First diff "solves" point 1 & 2. Second diff is on the parts of the manual
> that does not match the usbhid.h
> 

i've committed the man part - i have to leave the rest for someone else
to hopefully pick up.

jmc

> Index: usage.c
> ===
> RCS file: /cvs/src/lib/libusbhid/usage.c,v
> retrieving revision 1.16
> diff -u -p -r1.16 usage.c
> --- usage.c 8 Oct 2014 04:49:36 -   1.16
> +++ usage.c 21 May 2018 21:06:24 -
> @@ -224,6 +224,7 @@ hid_usage_in_page(unsigned int u)
>  {
> int i = HID_USAGE(u), j, k, us;
> int page = HID_PAGE(u);
> +   char usage_name[100];
> static char b[100];
> 
> for (k = 0; k < npages; k++)
> @@ -234,12 +235,18 @@ hid_usage_in_page(unsigned int u)
> for (j = 0; j < pages[k].pagesize; j++) {
> us = pages[k].page_contents[j].usage;
> if (us == -1) {
> -   snprintf(b, sizeof b,
> +   snprintf(usage_name, sizeof usage_name,
> pages[k].page_contents[j].name, i);
> +   snprintf(b, sizeof b,
> +   "%s:%s", pages[k].name, usage_name);
> +   return b;
> +   }
> +   if (us == i) {
> +   snprintf(b, sizeof b,
> +   "%s:%s", pages[k].name,
> +   pages[k].page_contents[j].name);
> return b;
> }
> -   if (us == i)
> -   return pages[k].page_contents[j].name;
> }
>   bad:
> snprintf(b, sizeof b, "0x%04x", i);
> @@ -265,8 +272,9 @@ int
>  hid_parse_usage_in_page(const char *name)
>  {
> const char *sep;
> +   const char *usage_sep;
> unsigned int l;
> -   int k, j;
> +   int k, j, us, parsed_usage;
> 
> sep = strchr(name, ':');
> if (sep == NULL)
> @@ -277,10 +285,20 @@ hid_parse_usage_in_page(const char *name
> goto found;
> return -1;
>   found:
> +   usage_sep = strchr(sep, '_');
> sep++;
> -   for (j = 0; j < pages[k].pagesize; j++)
> +   for (j = 0; j < pages[k].pagesize; j++) {
> +   us = pages[k].page_contents[j].usage;
> +   if (us == -1) {
> +   if (usage_sep == NULL)
> +   return -1;
> +   if (sscanf(usage_sep, "_%d", &parsed_usage))
> +   return (pages[k].usage << 16 |
> +   parsed_usage);
> +   }
> if (strcmp(pages[k].page_contents[j].name, sep) == 0)
> return (pages[k].usage << 16) |
> pages[k].page_contents[j].usage;
> +   }
> return -1;
>  }
> 
> Index: usbhid.3
> ===
> RCS file: /cvs/src/lib/libusbhid/usbhid.3,v
> retrieving revision 1.17
> diff -u -p -r1.17 usbhid.3
> --- usbhid.313 May 2014 14:05:02 -  1.17
> +++ usbhid.321 May 2018 21:02:21 -
> @@ -65,22 +65,22 @@
>  .Fn hid_report_size "report_desc_t d" "hid_kind_t k" "int id"
>  .Ft int
>  .Fn hid_locate "report_desc_t d" "u_int usage" "hid_kind_t k" "hid_item_t
> *h" "int id"
> -.Ft char *
> +.Ft const char *
>  .Fn hid_usage_page "int i"
> -.Ft char *
> +.Ft const char *
>  .Fn hid_usage_in_page "u_int u"
>  .Ft int
>  .Fn hid_parse_usage_page "const char *"
> -.Ft char *
> +.Ft int
>  .Fn hid_parse_usage_in_page "const char *"
>  .Ft void
>  .Fn hid_init "char *file"
>  .Ft int
>  .Fn hid_start "char *file"
> -.Ft int
> +.Ft int32_t
>  .Fn hid_get_data "void *data" "hid_item_t *h"
>  .Ft void
> -.Fn hid_set_data "void *data" "hid_item_t *h" "u_int data"
> +.Fn hid_set_data "void *data" "hid_item_t *h" "int32_t data"
>  .Sh DESCRIPTION
>  The
>  .Nm
> 
> 
> 
> 2018-05-21 12:07 GMT+02:00 Martin Pieuchot :
> 
> > On 18/05/18(Fri) 10:01, David Bern wrote:
> > > Hello!
> > >
> > > Have been using libusbhid and discovered a couple of discrepancies in
> > > the man-page (libusbhid.3) and the source of usage.c
> > >
> > > Some are just factual misses, but I also got (what I think is) 2 errors.
> > > I will try to explain them;
> > >
> > > 1. (This is the I think is an error but not sure). The man-page tells me
> > > that hid_usage_in_page and hid_parse_usage_in_page are each
> > > others inverse.
> > > If I haven't misunderstood the practical meaning of inverse in this
> > > case then this should be true:
> > > x == hid_parse_usage_in_page(hid_usage_in_page(x)).
> > >
> > > My observation:
> > > The main reason to why this isnt true, is that hid_usage_in_page()
> > > returns the data of pages[k].page_contents[j].name
> > > while hid_parse_usage_in_page() expects the data to
> > > c

local-mac-address

2018-05-27 Thread Mark Kettenis
Looks like u-boot was finally fixed and now assigns a
local-mac-address property to device nodes even if u-boot itself isn't
configured with a network driver.  This is helpful since this means we
can have a static MAC address even if y-boot doesn't touch the
hardware.

Diff below adds the necessary code to dwge(4) to take advantage of this.

ok?


Index: dev/fdt/if_dwxe.c
===
RCS file: /cvs/src/sys/dev/fdt/if_dwxe.c,v
retrieving revision 1.8
diff -u -p -r1.8 if_dwxe.c
--- dev/fdt/if_dwxe.c   27 May 2018 16:19:25 -  1.8
+++ dev/fdt/if_dwxe.c   27 May 2018 19:09:04 -
@@ -411,7 +411,9 @@ dwxe_attach(struct device *parent, struc
else
sc->sc_clk = DWXE_MDIO_CMD_MDC_DIV_RATIO_M_16;
 
-   dwxe_lladdr_read(sc, sc->sc_lladdr);
+   if (OF_getprop(faa->fa_node, "local-mac-address",
+   &sc->sc_lladdr, ETHER_ADDR_LEN) != ETHER_ADDR_LEN)
+   dwxe_lladdr_read(sc, sc->sc_lladdr);
printf(": address %s\n", ether_sprintf(sc->sc_lladdr));
 
/* Do hardware specific initializations. */



Re: [PATCH] Define IMSG_DATA_SIZE() in imsg.h

2018-05-27 Thread Klemens Nanni
On Sun, May 27, 2018 at 01:12:21AM +0300, Consus wrote:
> +++ b/usr.sbin/httpd/httpd.h
> @@ -195,7 +195,6 @@ struct imsgev {
>   if (IMSG_DATA_SIZE(imsg) < sizeof(*p))  \
>   fatalx("bad length imsg received"); \
>  } while (0)
> -#define IMSG_DATA_SIZE(imsg) ((imsg)->hdr.len - IMSG_HEADER_SIZE)
>  #define MAX_IMSG_DATA_SIZE   (MAX_IMSGSIZE - IMSG_HEADER_SIZE)
What about moving MAX_IMSG_DATA_SIZE into imsg.h as well then?

Note that this is the only usage of it in base.