cwm: modifier for AltGr

2020-01-31 Thread Artturi Alm
Hi,

the diff below adds support for using AltGr(the right Alt on
some keyboards) as 'm' modifier with bind-key and bind-mouse.
so ie. "bind-key Cm-Return terminal" is available for us w/AltGr
to match default binding. the lack of being able to bind w/AltGr
did hurt my cwm usage with other bindings too, so giving this to
us with such a broken keyboard layout feels only right, imo..:]

just a 'ping', in case i've sent this before.

-Artturi


diff --git a/app/cwm/conf.c b/app/cwm/conf.c
index 29b205364..83af9f7e2 100644
--- a/app/cwm/conf.c
+++ b/app/cwm/conf.c
@@ -201,6 +201,7 @@ static const struct {
{ 'M',  Mod1Mask },
{ '4',  Mod4Mask },
{ 'S',  ShiftMask },
+   { 'm',  Mod5Mask },
 };
 static const struct {
const char  *key;
diff --git a/app/cwm/cwmrc.5 b/app/cwm/cwmrc.5
index fec9008f3..61d9809ab 100644
--- a/app/cwm/cwmrc.5
+++ b/app/cwm/cwmrc.5
@@ -84,6 +84,8 @@ Meta key.
 Shift key.
 .It Ic 4
 Mod4 (windows) key.
+.It Ic m
+Mod5 (AltGr) key.
 .El
 .Pp
 The
@@ -101,18 +103,10 @@ The modifier keys come first, followed by a
 .Sq - ,
 then the button number.
 .Pp
-The following modifiers are recognised:
-.Pp
-.Bl -tag -width Ds -offset indent -compact
-.It Ic C
-Control key.
-.It Ic M
-Meta key.
-.It Ic S
-Shift key.
-.It Ic 4
-Mod4 (windows) key.
-.El
+The same modifiers are recognised as for
+.Ar key
+in
+.Nm bind-key .
 .Pp
 The following buttons are recognised:
 .Pp
diff --git a/app/cwm/xevents.c b/app/cwm/xevents.c
index 9b504bc72..acfd94bc8 100644
--- a/app/cwm/xevents.c
+++ b/app/cwm/xevents.c
@@ -69,7 +69,7 @@ void  (*xev_handlers[LASTEvent])(XEvent *) = {
 };
 
 static KeySym modkeys[] = { XK_Alt_L, XK_Alt_R, XK_Super_L, XK_Super_R,
-   XK_Control_L, XK_Control_R };
+   XK_Control_L, XK_Control_R, XK_ISO_Level3_Shift };
 
 static void
 xev_handle_maprequest(XEvent *ee)



rdate/ntp.c: unused attempts

2020-01-07 Thread Artturi Alm
Hi,

been there unused since import, and counting accepts+rejects has been enough,
so here's a diff for cleaning it away.

-Artturi


diff --git a/usr.sbin/rdate/ntp.c b/usr.sbin/rdate/ntp.c
index d48b6cae19e..92cb4c70fcb 100644
--- a/usr.sbin/rdate/ntp.c
+++ b/usr.sbin/rdate/ntp.c
@@ -177,7 +177,7 @@ ntp_client(const char *hostname, int family, struct timeval 
*new,
 int
 sync_ntp(int fd, const struct sockaddr *peer, double *offset, double *error)
 {
-   int attempts = 0, accepts = 0, rejects = 0;
+   int accepts = 0, rejects = 0;
int delay = MAX_DELAY, ret;
double deadline;
double a, b, x, y;
@@ -193,7 +193,7 @@ sync_ntp(int fd, const struct sockaddr *peer, double 
*offset, double *error)
return (-1);
}
 
-   while (accepts < MAX_QUERIES && attempts < 2 * MAX_QUERIES) {
+   while (accepts < MAX_QUERIES) {
memset(&data, 0, sizeof(data));
 
if (current_time(JAN_1970) > deadline) {



sxisyscon(4): register the regmap also for children + more compatibles

2019-09-17 Thread Artturi Alm
Hi,

i would like to attach sxisyscon(4) on a few more compatibles,
and register the regmap once per child with a phandle.

here is a complete example of the relevant node(s) from sun7i-a20:
Node 0xda8
name: 'system-control'
compatible: 'allwinner,sun7i-a20-system-control' + 
'allwinner,sun4i-a10-system-control'
reg: 01c0.0030
#address-cells: 0001
#size-cells: 0001
ranges: 

Node 0xe58
name: 'sram'
compatible: 'mmio-sram'
reg: .c000
#address-cells: 0001
#size-cells: 0001
ranges: ..c000

Node 0xec8
name: 'sram-section'
compatible: 'allwinner,sun7i-a20-sram-a3-a4' + 
'allwinner,sun4i-a10-sram-a3-a4'
reg: 8000.4000
status: 'disabled'
phandle: 000c

Node 0xf70
name: 'sram'
compatible: 'mmio-sram'
reg: 0001.1000
#address-cells: 0001
#size-cells: 0001
ranges: .0001.1000

Node 0xfe4
name: 'sram-section'
compatible: 'allwinner,sun7i-a20-sram-d' + 
'allwinner,sun4i-a10-sram-d'
reg: .1000
status: 'okay'
phandle: 0018

Node 0x107c
name: 'sram'
compatible: 'mmio-sram'
reg: 01d0.000d
#address-cells: 0001
#size-cells: 0001
ranges: .01d0.000d

Node 0x10f4
name: 'sram-section'
compatible: 'allwinner,sun7i-a20-sram-c1' + 
'allwinner,sun4i-a10-sram-c1'
reg: .0008
phandle: 0013

and an example node using above is like this:
Node 0x215c
name: 'usb'
compatible: 'allwinner,sun4i-a10-musb'
reg: 01c13000.0400
clocks: 0002.001a
interrupts: .0026.0004
interrupt-names: 'mc'
phys: 0017.
phy-names: 'usb'
extcon: 0017.
allwinner,sram: 0018.0001
status: 'okay'
dr_mode: 'otg'


diff below does allow the use of "allwinner,sram"-property to
reach the regmap without teaching "the user"(=driver) of all
the possible compatibles for 'system-control', nor how the
phandle X is useful only for
  regmap_bynode(OF_parent(OF_parent(OF_getnodebyphandle(X to use.

in short; i want to get rid of the need to hardcode OF_parent(OF_parent()).
any comments?

-Artturi


diff --git a/sys/dev/fdt/sxisyscon.c b/sys/dev/fdt/sxisyscon.c
index 30021d9f6aa..7b0da0d77c4 100644
--- a/sys/dev/fdt/sxisyscon.c
+++ b/sys/dev/fdt/sxisyscon.c
@@ -49,7 +49,11 @@ sxisyscon_match(struct device *parent, void *match, void 
*aux)
struct fdt_attach_args *faa = aux;
int node = faa->fa_node;
 
-   if (OF_is_compatible(node, "allwinner,sun8i-h3-system-control") ||
+   if (OF_is_compatible(node, "allwinner,sun4i-a10-system-control") ||
+   OF_is_compatible(node, "allwinner,sun5i-a13-system-control") ||
+   OF_is_compatible(node, "allwinner,sun7i-a20-system-control") ||
+   OF_is_compatible(node, "allwinner,sun8i-a23-system-control") ||
+   OF_is_compatible(node, "allwinner,sun8i-h3-system-control") ||
OF_is_compatible(node, "allwinner,sun50i-a64-system-control") ||
OF_is_compatible(node, "allwinner,sun50i-h5-system-control") ||
OF_is_compatible(node, "allwinner,sun50i-h6-system-control"))
@@ -63,6 +67,7 @@ sxisyscon_attach(struct device *parent, struct device *self, 
void *aux)
 {
struct sxisyscon_softc *sc = (struct sxisyscon_softc *)self;
struct fdt_attach_args *faa = aux;
+   int cnode, pnode;
 
if (faa->fa_nreg < 1) {
printf(": no registers\n");
@@ -76,8 +81,24 @@ sxisyscon_attach(struct device *parent, struct device *self, 
void *aux)
return;
}
 
+   /*
+* Register us, and all our child nodes with a phandle, to allow
+* the use of either regmap_bycompatible() or regmap_byphandle().
+* Other device nodes have "allwinner,sram" property with phandle
+* to these, also they should know the sram-section they want by
+* compatible. Which doesn't really matter as they get the same
+* regmap contents no matter what.. but this gives them both.
+*/
regmap_register(faa->fa_node, sc->sc_iot, sc->sc_ioh,
faa->fa_reg[0].size);
+   for (pnode = OF_child(faa->fa_no

sxiusbphy

2019-09-17 Thread Artturi Alm
Hi,

i got a branch i would like to have this for =]

this works for me as is, and already does more than the current code
in tree, which this diff removes from sys/dev/fdt/ehci_fdt.c.

i took a look at how netbsd does this, but went essentially with what
linux does for these bindings (excluding some otg-only stuff for now).

fwiw., i haven't tested the type>=H3 paths so far(no hw). any comments?

-Artturi


diff --git a/sys/arch/arm64/conf/GENERIC b/sys/arch/arm64/conf/GENERIC
index 57ad904ed22..175074a4651 100644
--- a/sys/arch/arm64/conf/GENERIC
+++ b/sys/arch/arm64/conf/GENERIC
@@ -199,6 +199,7 @@ sxirtc* at fdt? early 1 # Real Time Clock
 sximmc*at fdt? # SD/MMC card controller
 sdmmc* at sximmc?  # SD/MMC bus
 sxisyscon* at fdt? early 1 # System controller
+sxiusbphy* at fdt? early 1 # Allwinner USB PHY
 sxitemp*   at fdt? # Temperature sensor
 sxitwi*at fdt? # I2C controller
 iic*   at sxitwi?  # I2C bus
diff --git a/sys/arch/arm64/conf/RAMDISK b/sys/arch/arm64/conf/RAMDISK
index 2a87cc9a88a..1542743469c 100644
--- a/sys/arch/arm64/conf/RAMDISK
+++ b/sys/arch/arm64/conf/RAMDISK
@@ -185,6 +185,7 @@ sxirtc* at fdt? early 1 # Real Time Clock
 sximmc*at fdt? # SD/MMC card controller
 sdmmc* at sximmc?  # SD/MMC bus
 sxisyscon* at fdt? early 1 # System controller
+sxiusbphy* at fdt? early 1 # Allwinner USB PHY
 sxitwi*at fdt? # I2C controller
 iic*   at sxitwi?  # I2C bus
 dwxe*  at fdt?
diff --git a/sys/arch/armv7/conf/GENERIC b/sys/arch/armv7/conf/GENERIC
index 1fe66198653..f02788df236 100644
--- a/sys/arch/armv7/conf/GENERIC
+++ b/sys/arch/armv7/conf/GENERIC
@@ -115,6 +115,7 @@ usb*at ehci?#flags 0x1
 ohci*  at fdt?
 usb*   at ohci?
 sxisyscon* at fdt? early 1 # System controller
+sxiusbphy* at fdt? early 1 # Allwinner USB PHY
 sxitemp*   at fdt? # Temperature sensor
 sxits* at fdt? # Touchpad controller
 sxitwi*at fdt? # Two-Wire Serial Interface
diff --git a/sys/arch/armv7/conf/RAMDISK b/sys/arch/armv7/conf/RAMDISK
index 05067ae11ea..022cbd2262c 100644
--- a/sys/arch/armv7/conf/RAMDISK
+++ b/sys/arch/armv7/conf/RAMDISK
@@ -106,6 +106,7 @@ usb*at ehci?#flags 0x1
 ohci*  at fdt?
 usb*   at ohci?
 sxisyscon* at fdt? early 1 # System controller
+sxiusbphy* at fdt? early 1 # Allwinner USB PHY
 sxitwi*at fdt? # Two-Wire Serial Interface
 iic*   at sxitwi?  # I2C bus
 
diff --git a/sys/dev/fdt/ehci_fdt.c b/sys/dev/fdt/ehci_fdt.c
index 807fac3d441..6f12c684925 100644
--- a/sys/dev/fdt/ehci_fdt.c
+++ b/sys/dev/fdt/ehci_fdt.c
@@ -28,6 +28,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -109,6 +110,7 @@ ehci_fdt_attach(struct device *parent, struct device *self, 
void *aux)
printf("\n");
 
ehci_init_phys(sc);
+   phy_enable_idx(sc->sc_node, 0);
 
strlcpy(sc->sc.sc_vendor, "Generic", sizeof(sc->sc.sc_vendor));
r = ehci_init(&sc->sc);
@@ -161,20 +163,9 @@ struct ehci_phy {
void (*init)(struct ehci_fdt_softc *, uint32_t *);
 };
 
-void sun4i_phy_init(struct ehci_fdt_softc *, uint32_t *);
 void sun9i_phy_init(struct ehci_fdt_softc *, uint32_t *);
 
 struct ehci_phy ehci_phys[] = {
-   { "allwinner,sun4i-a10-usb-phy", sun4i_phy_init },
-   { "allwinner,sun5i-a13-usb-phy", sun4i_phy_init },
-   { "allwinner,sun6i-a31-usb-phy", sun4i_phy_init },
-   { "allwinner,sun7i-a20-usb-phy", sun4i_phy_init },
-   { "allwinner,sun8i-a23-usb-phy", sun4i_phy_init },
-   { "allwinner,sun8i-a33-usb-phy", sun4i_phy_init },
-   { "allwinner,sun8i-h3-usb-phy", sun4i_phy_init },
-   { "allwinner,sun8i-r40-usb-phy", sun4i_phy_init },
-   { "allwinner,sun8i-v3s-usb-phy", sun4i_phy_init },
-   { "allwinner,sun50i-a64-usb-phy", sun4i_phy_init },
{ "allwinner,sun9i-a80-usb-phy", sun9i_phy_init },
 };
 
@@ -250,60 +241,6 @@ ehci_init_phys(struct ehci_fdt_softc *sc)
 #define  SUNXI_AHB_INCR8   (1 << 10)
 #define  SUNXI_AHB_INCR16  (1 << 11)
 
-void
-sun4i_phy_init(struct ehci_fdt_softc *sc, uint32_t *cells)
-{
-   uint32_t vbus_supply;
-   char name[32];
-   uint32_t val;
-   int node;
-
-   node = OF_getnodebyphandle(cells[0]);
-   if (node == -1)
-   return;
-
-   val = bus_space_read_4(sc->sc.iot, sc->sc.ioh, SUNXI_HCI_ICR);
-   val |= SUNXI_AHB_INCR8 | SUNXI_AHB_INCR4;
-   val |= SUNXI_AHB_INCRX_ALIGN;
-   val |= SUNXI_ULPI_BYPASS;
-   bus_space_write_4(sc->sc.iot, sc->sc.ioh, SUNXI_HCI_ICR, val);
-
-   /*
-* We need to poke an undocumented register to make the PHY
-* wor

Re: expose host capabilities relative to usb isochronous xfers

2019-06-12 Thread Artturi Alm
On Wed, Jun 12, 2019 at 03:55:59PM +0200, Alexandre Ratchov wrote:
> Currenty USB device driver code has no way to obtain how many frames
> can be scheduled on the HC. If it attempts to schedule too many
> frames, usbd_transfer() fails or silently misbehaves.
> 
> For audio this is a big problem because the max frames count
> determines the block size which must be reported to upper layers
> before any transfer starts. This makes impossible to implement uaudio
> properly. Currently there's a temporary hack to workaround this, which
> limits the block size. Now that uaudio is in and works, it's time to
> start removing such hacks.
> 
> Similarly, driver code needs to know the minimum number of frames per
> transfer to get an interrupt (ie the completion callback). Indeed, if
> the transfer frame count is not rounded to it, we silently miss the
> interrupt, the completion call-back is not called and playback
> stutters.
> 
> The diff below adds a new usbd_bus_info() function which reports the
> maximum frames that can be scheduled and the minimum frames per
> transfer to get an interrupt.
> 
> [snip]
> Index: usbdi.c
> ===
> RCS file: /cvs/src/sys/dev/usb/usbdi.c,v
> retrieving revision 1.100
> diff -u -p -u -p -r1.100 usbdi.c
> --- usbdi.c   18 Nov 2018 16:33:26 -  1.100
> +++ usbdi.c   12 Jun 2019 13:33:41 -
> @@ -275,6 +275,12 @@ usbd_close_pipe(struct usbd_pipe *pipe)
>   return (USBD_NORMAL_COMPLETION);
>  }
>  
> +void
> +usbd_bus_info(struct usbd_device *dev, struct usbd_bus_info *info)
> +{
> + dev->bus->methods->info(dev, info);
> +}
> +
>  usbd_status
>  usbd_transfer(struct usbd_xfer *xfer)
>  {
> [snip]

i think above is not good enough with only ehci, ohci, uhci and xhci
being taken care of in [snip]'ed parts of the diff unfortunately:]
just thinking about dwc2.

-Artturi



intro.8: .Xr rcctl 8 -- http://man.openbsd.org/intro.8

2019-05-25 Thread Artturi Alm
Hi,

doesn't look pretty, and is more lines, but in browsers the lack of .Xr
does really stand out, and not in a good way, in my opinion. :]

-Artturi


diff --git a/share/man/man8/intro.8 b/share/man/man8/intro.8
index 17a64368b7b..3bc3fceb5ca 100644
--- a/share/man/man8/intro.8
+++ b/share/man/man8/intro.8
@@ -83,7 +83,9 @@ Thus it is not started by default.
 To enable or disable daemon processes,
 administrators should edit the file
 .Xr rc.conf.local 8
-or use the rcctl(8) utility.
+or use the
+.Xr rcctl 8
+utility.
 The
 .Xr rc.conf.local 8
 file overrides variable assignments in



cu(1)/remote(5): add and document support for escape character capability

2019-03-23 Thread Artturi Alm
Hi,

for completeness, would anything like the diff below be acceptable?

I might begin using /etc/remote soon, and I found the old remote.5[0]
to have had this, and also described as such in remote(5) on
docs.oracle.com, so i chose to reuse "es".

-Artturi

[0]: http://man.openbsd.org/OpenBSD-5.7/remote.5


diff --git a/share/man/man5/remote.5 b/share/man/man5/remote.5
index 2a50ca97d8a..b0d046a266a 100644
--- a/share/man/man5/remote.5
+++ b/share/man/man5/remote.5
@@ -88,6 +88,15 @@ If this file refers to a terminal line,
 .Xr cu 1
 attempts to perform an exclusive open on the device to ensure only
 one user at a time has access to the port.
+.It Sy \&es
+(str)
+The escape character for
+.Xr cu 1 .
+This should be a single character, or
+.Ql ^
+followed by a letter.
+The default is
+.Ql ~ .
 .El
 .Sh FILES
 .Bl -tag -width /etc/remote -compact
diff --git a/usr.bin/cu/cu.1 b/usr.bin/cu/cu.1
index 5daab4bc074..61c723a45e4 100644
--- a/usr.bin/cu/cu.1
+++ b/usr.bin/cu/cu.1
@@ -105,6 +105,7 @@ uses the
 .Xr remote 5
 database to retrieve the
 .Sy dc Pq directly connected ,
+.Sy es Pq escape character ,
 .Sy dv Pq device
 and
 .Sy br Pq baud rate
diff --git a/usr.bin/cu/cu.c b/usr.bin/cu/cu.c
index 697f72d3418..cba4ff1601d 100644
--- a/usr.bin/cu/cu.c
+++ b/usr.bin/cu/cu.c
@@ -41,7 +41,7 @@ FILE  *record_file;
 struct termios  saved_tio;
 struct bufferevent *input_ev;
 struct bufferevent *output_ev;
-int escape_char = '~';
+int escape_char = -1;
 int is_direct = -1;
 int restricted = 0;
 const char *line_path = NULL;
@@ -159,6 +159,8 @@ main(int argc, char **argv)
}
}
 
+   if (escape_char == -1)
+   escape_char = '~';
if (line_path == NULL)
line_path = "/dev/cua00";
if (line_speed == -1)
@@ -402,6 +404,25 @@ try_remote(const char *host, const char *path, const char 
*entry)
if (line_path == NULL && cgetstr(cp, "dv", &s) >= 0)
line_path = s;
 
+   s = NULL;
+   if (escape_char == -1 && cgetustr(cp, "es", &s) >= 0) {
+   switch (strnlen(s, 3)) {
+   case 1:
+   escape_char = (u_char)s[0];
+   break;
+   case 2:
+   if (s[0] == '^' &&
+   (u_char)s[1] >= 64 && (u_char)s[1] < 128) {
+   escape_char = (u_char)s[1] & 31;
+   break;
+   }
+   /* FALLTHROUGH */
+   default:
+   cu_warnx("invalid escape character: %s", s);
+   }
+   free(s);
+   }
+
if (line_speed == -1 && cgetnum(cp, "br", &l) >= 0) {
if (l < 0 || l > INT_MAX)
cu_errx(1, "speed out of range");



Re: sbin/wsconsctl: show more data

2019-03-18 Thread Artturi Alm
On Mon, Mar 18, 2019 at 06:30:15PM +0100, Frederic Cambus wrote:
> On Mon, Jan 07, 2019 at 04:27:46PM -0700, Theo de Raadt wrote:
> > Ted Unangst  wrote:
> > 
> > > Artturi Alm wrote:
> > > > display.width=1920
> > > > display.height=1200
> > > > display.depth=32
> > > > display.emulations=vt100
> > > > display.col_x_row=120x37
> > > > display.font_wxh=16x32
> > > 
> > > now that we've all had a chance to weigh in on the font, why are you 
> > > adding
> > > this weird x format? speaking of ugly... it should print columns and rows 
> > > just
> > > like width and height.
> > 
> > it is a waste of kernel and userland code since another mechanism already 
> > exists
> > 
> > use stty -a
> 
> While I agree it doesn't make sense to add variables for showing
> the number of columns and rows, as the information can be obtained
> using ssty -a, displaying fontwidth and fontheight values would be
> useful. This allows users to know the size of the currently loaded
> font.
> 
> Thinking forward, this would also allow to easily get those values
> in shell scripts, which can be leveraged if we wanted to only embed
> 7-bit ASCII characters in the kernel and load the full font later on,
> or if someone wanted to continue the UTF-8 work [1] started by miod@.
> 
> Revised diff below iterating on what Artturi previously sent, and
> a snippet of wsconsctl output with the diff applied:
> 
>  display.width=1600
>  display.height=900
>  display.depth=32
> +display.fontwidth=12
> +display.fontheight=24
>  display.emulations=vt100
>  display.screentypes=std
>  display.focus=4
> 
> [1] https://undeadly.org/cgi?action=article&sid=20131023125815
> 
> Comments? OK?
> 

While my opinion is irrelevant, it does look good to me, thanks :]

-Artturi

> Index: sbin/wsconsctl/display.c
> ===
> RCS file: /cvs/src/sbin/wsconsctl/display.c,v
> retrieving revision 1.20
> diff -u -p -r1.20 display.c
> --- sbin/wsconsctl/display.c  8 May 2015 19:12:51 -   1.20
> +++ sbin/wsconsctl/display.c  18 Mar 2019 17:11:59 -
> @@ -41,7 +41,7 @@
>  #include "wsconsctl.h"
>  
>  u_int dpytype;
> -u_int width, height, depth;
> +u_int width, height, depth, fontwidth, fontheight;
>  int focus;
>  struct field_pc brightness, contrast, backlight;
>  int burnon, burnoff, vblank, kbdact, msact, outact;
> @@ -54,6 +54,8 @@ struct field display_field_tab[] = {
>  { "width",   &width, FMT_UINT,   FLG_RDONLY },
>  { "height",  &height,FMT_UINT,   FLG_RDONLY },
>  { "depth",   &depth, FMT_UINT,   FLG_RDONLY },
> +{ "fontwidth",   &fontwidth, FMT_UINT,   FLG_RDONLY },
> +{ "fontheight",  &fontheight,FMT_UINT,   FLG_RDONLY },
>  { "emulations",  &emuls, FMT_EMUL,   FLG_RDONLY },
>  { "screentypes", &screens,   FMT_SCREEN, FLG_RDONLY },
>  { "focus",   &focus, FMT_INT,FLG_NORDBACK },
> @@ -84,7 +86,7 @@ display_get_values(int fd)
>   const char *cmd_str;
>   void *ptr;
>   unsigned long cmd;
> - int bon = 0, fbon = 0;
> + int bon = 0, fbon = 0, son = 0;
>  
>   focus = gscr.idx = -1;
>   for (pf = display_field_tab; pf->name; pf++) {
> @@ -102,6 +104,10 @@ display_get_values(int fd)
>   } else if (ptr == &emuls) {
>   fillioctl(WSDISPLAYIO_GETEMULTYPE);
>   emuls.idx=0;
> + } else if (ptr == &fontwidth || ptr == &fontheight) {
> + fillioctl(WSDISPLAYIO_GETSCREENTYPE);
> + ptr = &screens;
> + screens.idx = 0;
>   } else if (ptr == &screens) {
>   fillioctl(WSDISPLAYIO_GETSCREENTYPE);
>   screens.idx=0;
> @@ -168,6 +174,11 @@ display_get_values(int fd)
>   emuls.idx=fd;
>   } else if (ptr == &screens) {
>   screens.idx=fd;
> + if (!son) {
> + fontwidth = screens.fontwidth;
> + fontheight = screens.fontheight;
> + }
> + son++;
>   } else if (ptr == ¶m) {
>   struct field_pc *pc = pf->valp;
>  



Re: Option for alternative escape character with cu(1)

2019-03-16 Thread Artturi Alm
On Fri, Mar 15, 2019 at 09:51:12PM +, Nicholas Marriott wrote:
> On Fri, Mar 15, 2019 at 09:43:56AM -0600, Todd C. Miller wrote:
> > Wouldn't it be less error-prone to make escape_char u_char instead
> > of int?
> 
> Maybe, I don't mind either way.
> 
> However this in stream_read would still need a cast as ptr is signed:
> 
>   if (state_change && (u_char)*ptr == escape_char) {
> 
> Although there is no reason ptr couldn't be u_char * too (in that case
> it would be nice to change line_read as well).

do_command(char c) was why I didn't go for u_char, and kept it int as
it was in ssh.

I've done some builds of cu with -Wpointer-sign etc., but the output
didn't seem anything like i would like to minimally solve, or cause to
anyone else. :]

-Artturi



Re: Option for alternative escape character with cu(1)

2019-03-15 Thread Artturi Alm
On Fri, Mar 15, 2019 at 02:43:04PM +, Nicholas Marriott wrote:
> .
> Another couple of minor changes below, with those it looks good to
> me. Any OK for this?
> 

With joined lines, the cast, and some runtime testing with ~, % and ^[.

-Artturi

diff --git a/usr.bin/cu/command.c b/usr.bin/cu/command.c
index c07fe73aeca..27d80f16dd7 100644
--- a/usr.bin/cu/command.c
+++ b/usr.bin/cu/command.c
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "cu.h"
 
@@ -223,6 +224,8 @@ start_record(void)
 void
 do_command(char c)
 {
+   char esc[4 + 1];
+
if (restricted && strchr("CRX$>", c) != NULL) {
cu_warnx("~%c command is not allowed in restricted mode", c);
return;
@@ -266,20 +269,23 @@ do_command(char c)
sleep(1);
ioctl(line_fd, TIOCCBRK, NULL);
break;
-   case '~':
-   bufferevent_write(line_ev, "~", 1);
+   default:
+   if (c == escape_char)
+   bufferevent_write(line_ev, &c, 1);
break;
case '?':
+   vis(esc, escape_char, VIS_WHITE | VIS_NOSLASH, 0);
printf("\r\n"
-   "~#  send break\r\n"
-   "~$  pipe local command to remote host\r\n"
-   "~>  send file to remote host\r\n"
-   "~C  connect program to remote host\r\n"
-   "~D  de-assert DTR line briefly\r\n"
-   "~R  start recording to file\r\n"
-   "~S  set speed\r\n"
-   "~X  send file with XMODEM\r\n"
-   "~?  get this summary\r\n"
+   "%s#  send break\r\n"
+   "%s$  pipe local command to remote host\r\n"
+   "%s>  send file to remote host\r\n"
+   "%sC  connect program to remote host\r\n"
+   "%sD  de-assert DTR line briefly\r\n"
+   "%sR  start recording to file\r\n"
+   "%sS  set speed\r\n"
+   "%sX  send file with XMODEM\r\n"
+   "%s?  get this summary\r\n",
+   esc, esc, esc, esc, esc, esc, esc, esc, esc
);
break;
}
diff --git a/usr.bin/cu/cu.1 b/usr.bin/cu/cu.1
index 104a6ea7893..3e85488e87c 100644
--- a/usr.bin/cu/cu.1
+++ b/usr.bin/cu/cu.1
@@ -36,6 +36,7 @@
 .Sh SYNOPSIS
 .Nm
 .Op Fl dr
+.Op Fl E Ar escape_char
 .Op Fl l Ar line
 .Op Fl s Ar speed | Fl Ar speed
 .Nm
@@ -55,6 +56,8 @@ The options are as follows:
 Specify that the line is directly connected and
 .Nm
 should not allow the driver to block waiting for a carrier to be detected.
+.It Fl E Ar escape_char
+Specify an escape character to use instead of the default tilde.
 .It Fl l Ar line
 Specify the line to use.
 Either of the forms like
diff --git a/usr.bin/cu/cu.c b/usr.bin/cu/cu.c
index 03a2df4181f..d01c3327042 100644
--- a/usr.bin/cu/cu.c
+++ b/usr.bin/cu/cu.c
@@ -41,6 +41,7 @@ FILE  *record_file;
 struct termios  saved_tio;
 struct bufferevent *input_ev;
 struct bufferevent *output_ev;
+int escape_char = '~';
 int is_direct = -1;
 int restricted = 0;
 const char *line_path = NULL;
@@ -53,7 +54,7 @@ struct event   sighup_ev;
 enum {
STATE_NONE,
STATE_NEWLINE,
-   STATE_TILDE
+   STATE_ESCAPE
 } last_state = STATE_NEWLINE;
 
 __dead voidusage(void);
@@ -67,8 +68,8 @@ void  try_remote(const char *, const char *, const 
char *);
 __dead void
 usage(void)
 {
-   fprintf(stderr, "usage: %s [-dr] [-l line] [-s speed | -speed]\n",
-   __progname);
+   fprintf(stderr, "usage: %s [-dr] [-E escape_char] [-l line] "
+   "[-s speed | -speed]\n", __progname);
fprintf(stderr, "   %s [host]\n", __progname);
exit(1);
 }
@@ -94,14 +95,14 @@ main(int argc, char **argv)
for (i = 1; i < argc; i++) {
if (strcmp("--", argv[i]) == 0)
break;
-   if (argv[i][0] != '-' || !isdigit((unsigned char)argv[i][1]))
+   if (argv[i][0] != '-' || !isdigit((u_char)argv[i][1]))
continue;
 
if (asprintf(&argv[i], "-s%s", &argv[i][1]) == -1)
errx(1, "speed asprintf");
}
 
-   while ((opt = getopt(argc, argv, "drl:s:")) != -1) {
+   while ((opt = getopt(argc, argv, "drE:l:s:")) != -1) {
switch (opt) {
case 'd':
is_direct = 1;
@@ -111,6 +112,15 @@ main(int argc, char **argv)
err(1, "pledge");
restricted = 1;
break;
+   case 'E':
+   if (optarg[0] == '^' && optarg[2] == 0 &&
+   

Re: Option for alternative escape character with cu(1)

2019-03-15 Thread Artturi Alm
On Thu, Mar 14, 2019 at 10:18:57AM +, Nicholas Marriott wrote:
> Thanks, comments inline.
> 

The diff looks much better to me, now with those things fixed based
on your feedback, thanks :]

-Artturi


diff --git a/usr.bin/cu/command.c b/usr.bin/cu/command.c
index c07fe73aeca..27d80f16dd7 100644
--- a/usr.bin/cu/command.c
+++ b/usr.bin/cu/command.c
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "cu.h"
 
@@ -223,6 +224,8 @@ start_record(void)
 void
 do_command(char c)
 {
+   char esc[4 + 1];
+
if (restricted && strchr("CRX$>", c) != NULL) {
cu_warnx("~%c command is not allowed in restricted mode", c);
return;
@@ -266,20 +269,23 @@ do_command(char c)
sleep(1);
ioctl(line_fd, TIOCCBRK, NULL);
break;
-   case '~':
-   bufferevent_write(line_ev, "~", 1);
+   default:
+   if (c == escape_char)
+   bufferevent_write(line_ev, &c, 1);
break;
case '?':
+   vis(esc, escape_char, VIS_WHITE | VIS_NOSLASH, 0);
printf("\r\n"
-   "~#  send break\r\n"
-   "~$  pipe local command to remote host\r\n"
-   "~>  send file to remote host\r\n"
-   "~C  connect program to remote host\r\n"
-   "~D  de-assert DTR line briefly\r\n"
-   "~R  start recording to file\r\n"
-   "~S  set speed\r\n"
-   "~X  send file with XMODEM\r\n"
-   "~?  get this summary\r\n"
+   "%s#  send break\r\n"
+   "%s$  pipe local command to remote host\r\n"
+   "%s>  send file to remote host\r\n"
+   "%sC  connect program to remote host\r\n"
+   "%sD  de-assert DTR line briefly\r\n"
+   "%sR  start recording to file\r\n"
+   "%sS  set speed\r\n"
+   "%sX  send file with XMODEM\r\n"
+   "%s?  get this summary\r\n",
+   esc, esc, esc, esc, esc, esc, esc, esc, esc
);
break;
}
diff --git a/usr.bin/cu/cu.1 b/usr.bin/cu/cu.1
index 104a6ea7893..3e85488e87c 100644
--- a/usr.bin/cu/cu.1
+++ b/usr.bin/cu/cu.1
@@ -36,6 +36,7 @@
 .Sh SYNOPSIS
 .Nm
 .Op Fl dr
+.Op Fl E Ar escape_char
 .Op Fl l Ar line
 .Op Fl s Ar speed | Fl Ar speed
 .Nm
@@ -55,6 +56,8 @@ The options are as follows:
 Specify that the line is directly connected and
 .Nm
 should not allow the driver to block waiting for a carrier to be detected.
+.It Fl E Ar escape_char
+Specify an escape character to use instead of the default tilde.
 .It Fl l Ar line
 Specify the line to use.
 Either of the forms like
diff --git a/usr.bin/cu/cu.c b/usr.bin/cu/cu.c
index 03a2df4181f..8e3ce0b0c0e 100644
--- a/usr.bin/cu/cu.c
+++ b/usr.bin/cu/cu.c
@@ -41,6 +41,7 @@ FILE  *record_file;
 struct termios  saved_tio;
 struct bufferevent *input_ev;
 struct bufferevent *output_ev;
+int escape_char = '~';
 int is_direct = -1;
 int restricted = 0;
 const char *line_path = NULL;
@@ -53,7 +54,7 @@ struct event   sighup_ev;
 enum {
STATE_NONE,
STATE_NEWLINE,
-   STATE_TILDE
+   STATE_ESCAPE
 } last_state = STATE_NEWLINE;
 
 __dead voidusage(void);
@@ -67,8 +68,8 @@ void  try_remote(const char *, const char *, const 
char *);
 __dead void
 usage(void)
 {
-   fprintf(stderr, "usage: %s [-dr] [-l line] [-s speed | -speed]\n",
-   __progname);
+   fprintf(stderr, "usage: %s [-dr] [-E escape_char] [-l line] "
+   "[-s speed | -speed]\n", __progname);
fprintf(stderr, "   %s [host]\n", __progname);
exit(1);
 }
@@ -94,14 +95,14 @@ main(int argc, char **argv)
for (i = 1; i < argc; i++) {
if (strcmp("--", argv[i]) == 0)
break;
-   if (argv[i][0] != '-' || !isdigit((unsigned char)argv[i][1]))
+   if (argv[i][0] != '-' || !isdigit((u_char)argv[i][1]))
continue;
 
if (asprintf(&argv[i], "-s%s", &argv[i][1]) == -1)
errx(1, "speed asprintf");
}
 
-   while ((opt = getopt(argc, argv, "drl:s:")) != -1) {
+   while ((opt = getopt(argc, argv, "drE:l:s:")) != -1) {
switch (opt) {
case 'd':
is_direct = 1;
@@ -111,6 +112,17 @@ main(int argc, char **argv)
err(1, "pledge");
restricted = 1;
break;
+   case 'E':
+   if (optarg[0] == '^' && optarg[2] == 0 &&
+   (u_char)optarg[1] >= 64 &&
+

Re: Option for alternative escape character with cu(1)

2019-03-13 Thread Artturi Alm
On Wed, Mar 13, 2019 at 07:47:08AM -0600, Todd C. Miller wrote:
> On Wed, 13 Mar 2019 14:35:06 +0200, Artturi Alm wrote:
> 
> > i don't have issues with tilde when using locally, but i mostly ssh to
> > reach cu, and too many times i've forgotten to configure ssh/use -e,
> > with this cu(1) becomes safer/easier to use for us with non-english
> > keyboard.
> > ~tilde is certainly annoying when it's three key presses alone,
> > and then you mostly get only one shot at trying..
> 
> The cu from Taylor UUCP uses -E for this (it uses -e to specify
> even parity).  If we are going to support this, I think it makes
> sense to be as compatible as possible with other systems.
> 
>  - todd

Sure, makes sense to me, thanks.


On Wed, Mar 13, 2019 at 02:36:03PM +, Nicholas Marriott wrote:
> Why only % rather than have -e take an argument like ssh?
> 

I'm lazy, and wanted to avoid breaking the "line" in usage().. :]

i had also missed escaping the alternative escape character in
do_command(), diff with these things fixed below.

-Artturi


diff --git a/usr.bin/cu/command.c b/usr.bin/cu/command.c
index c07fe73aeca..e225fb544be 100644
--- a/usr.bin/cu/command.c
+++ b/usr.bin/cu/command.c
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "cu.h"
 
@@ -223,6 +224,8 @@ start_record(void)
 void
 do_command(char c)
 {
+   char esc[4 + 1];
+
if (restricted && strchr("CRX$>", c) != NULL) {
cu_warnx("~%c command is not allowed in restricted mode", c);
return;
@@ -266,20 +269,26 @@ do_command(char c)
sleep(1);
ioctl(line_fd, TIOCCBRK, NULL);
break;
-   case '~':
-   bufferevent_write(line_ev, "~", 1);
+   default:
+   if (c != escape_char)
+   break;
+   esc[0] = escape_char;
+   esc[1] = '\0';
+   bufferevent_write(line_ev, esc, 1);
break;
case '?':
+   vis(esc, escape_char, VIS_WHITE | VIS_NOSLASH, 0);
printf("\r\n"
-   "~#  send break\r\n"
-   "~$  pipe local command to remote host\r\n"
-   "~>  send file to remote host\r\n"
-   "~C  connect program to remote host\r\n"
-   "~D  de-assert DTR line briefly\r\n"
-   "~R  start recording to file\r\n"
-   "~S  set speed\r\n"
-   "~X  send file with XMODEM\r\n"
-   "~?  get this summary\r\n"
+   "%s#  send break\r\n"
+   "%s$  pipe local command to remote host\r\n"
+   "%s>  send file to remote host\r\n"
+   "%sC  connect program to remote host\r\n"
+   "%sD  de-assert DTR line briefly\r\n"
+   "%sR  start recording to file\r\n"
+   "%sS  set speed\r\n"
+   "%sX  send file with XMODEM\r\n"
+   "%s?  get this summary\r\n",
+   esc, esc, esc, esc, esc, esc, esc, esc, esc
);
break;
}
diff --git a/usr.bin/cu/cu.1 b/usr.bin/cu/cu.1
index 104a6ea7893..d52e0b94e5f 100644
--- a/usr.bin/cu/cu.1
+++ b/usr.bin/cu/cu.1
@@ -38,6 +38,7 @@
 .Op Fl dr
 .Op Fl l Ar line
 .Op Fl s Ar speed | Fl Ar speed
+.Op Fl E Ar escape_char
 .Nm
 .Op Ar host
 .Sh DESCRIPTION
@@ -92,6 +93,8 @@ and
 .It Fl s Ar speed | Fl Ar speed
 Set the speed of the connection.
 The default is 9600.
+.It Fl E Ar escape_char
+Specify a escape character to use instead of the default tilde.
 .El
 .Pp
 If
diff --git a/usr.bin/cu/cu.c b/usr.bin/cu/cu.c
index 03a2df4181f..f269f4a74f3 100644
--- a/usr.bin/cu/cu.c
+++ b/usr.bin/cu/cu.c
@@ -41,6 +41,7 @@ FILE  *record_file;
 struct termios  saved_tio;
 struct bufferevent *input_ev;
 struct bufferevent *output_ev;
+int escape_char = -1;
 int is_direct = -1;
 int restricted = 0;
 const char *line_path = NULL;
@@ -53,7 +54,7 @@ struct event   sighup_ev;
 enum {
STATE_NONE,
STATE_NEWLINE,
-   STATE_TILDE
+   STATE_ESCAPE
 } last_state = STATE_NEWLINE;
 
 __dead voidusage(void);
@@ -67,8 +68,8 @@ void  try_remote(const char *, const char *, const 
char *);
 __dead void
 usage(void)
 {
-   fprintf(stderr, "usage: %s [-dr] [-l line] [-s speed | -speed]\n",
-   __progname);
+   fprintf(stder

Option for alternative escape character with cu(1)

2019-03-13 Thread Artturi Alm
Hi,

i don't have issues with tilde when using locally, but i mostly ssh to
reach cu, and too many times i've forgotten to configure ssh/use -e,
with this cu(1) becomes safer/easier to use for us with non-english
keyboard.
~tilde is certainly annoying when it's three key presses alone,
and then you mostly get only one shot at trying..

is this bloat?

-Artturi


diff --git a/usr.bin/cu/command.c b/usr.bin/cu/command.c
index c07fe73aeca..d97db3b56de 100644
--- a/usr.bin/cu/command.c
+++ b/usr.bin/cu/command.c
@@ -223,6 +223,8 @@ start_record(void)
 void
 do_command(char c)
 {
+   char esc = alt_esc ? '%' : '~';
+
if (restricted && strchr("CRX$>", c) != NULL) {
cu_warnx("~%c command is not allowed in restricted mode", c);
return;
@@ -271,15 +273,16 @@ do_command(char c)
break;
case '?':
printf("\r\n"
-   "~#  send break\r\n"
-   "~$  pipe local command to remote host\r\n"
-   "~>  send file to remote host\r\n"
-   "~C  connect program to remote host\r\n"
-   "~D  de-assert DTR line briefly\r\n"
-   "~R  start recording to file\r\n"
-   "~S  set speed\r\n"
-   "~X  send file with XMODEM\r\n"
-   "~?  get this summary\r\n"
+   "%c#  send break\r\n"
+   "%c$  pipe local command to remote host\r\n"
+   "%c>  send file to remote host\r\n"
+   "%cC  connect program to remote host\r\n"
+   "%cD  de-assert DTR line briefly\r\n"
+   "%cR  start recording to file\r\n"
+   "%cS  set speed\r\n"
+   "%cX  send file with XMODEM\r\n"
+   "%c?  get this summary\r\n",
+   esc, esc, esc, esc, esc, esc, esc, esc, esc
);
break;
}
diff --git a/usr.bin/cu/cu.1 b/usr.bin/cu/cu.1
index 104a6ea7893..1d609e14947 100644
--- a/usr.bin/cu/cu.1
+++ b/usr.bin/cu/cu.1
@@ -35,7 +35,7 @@
 .Nd serial terminal emulator
 .Sh SYNOPSIS
 .Nm
-.Op Fl dr
+.Op Fl der
 .Op Fl l Ar line
 .Op Fl s Ar speed | Fl Ar speed
 .Nm
@@ -55,6 +55,10 @@ The options are as follows:
 Specify that the line is directly connected and
 .Nm
 should not allow the driver to block waiting for a carrier to be detected.
+.It Fl e
+Use a percent sign
+.Pq Ql %
+as the escape character instead of tilde.
 .It Fl l Ar line
 Specify the line to use.
 Either of the forms like
diff --git a/usr.bin/cu/cu.c b/usr.bin/cu/cu.c
index 03a2df4181f..b66f4698605 100644
--- a/usr.bin/cu/cu.c
+++ b/usr.bin/cu/cu.c
@@ -41,6 +41,7 @@ FILE  *record_file;
 struct termios  saved_tio;
 struct bufferevent *input_ev;
 struct bufferevent *output_ev;
+int alt_esc = 0;
 int is_direct = -1;
 int restricted = 0;
 const char *line_path = NULL;
@@ -53,7 +54,7 @@ struct event   sighup_ev;
 enum {
STATE_NONE,
STATE_NEWLINE,
-   STATE_TILDE
+   STATE_ESCAPE
 } last_state = STATE_NEWLINE;
 
 __dead voidusage(void);
@@ -67,7 +68,7 @@ void  try_remote(const char *, const char *, const 
char *);
 __dead void
 usage(void)
 {
-   fprintf(stderr, "usage: %s [-dr] [-l line] [-s speed | -speed]\n",
+   fprintf(stderr, "usage: %s [-der] [-l line] [-s speed | -speed]\n",
__progname);
fprintf(stderr, "   %s [host]\n", __progname);
exit(1);
@@ -101,11 +102,14 @@ main(int argc, char **argv)
errx(1, "speed asprintf");
}
 
-   while ((opt = getopt(argc, argv, "drl:s:")) != -1) {
+   while ((opt = getopt(argc, argv, "derl:s:")) != -1) {
switch (opt) {
case 'd':
is_direct = 1;
break;
+   case 'e':
+   alt_esc = 1;
+   break;
case 'r':
if (pledge("stdio rpath wpath tty", NULL) == -1)
err(1, "pledge");
@@ -308,14 +312,14 @@ stream_read(struct bufferevent *bufev, void *data)
last_state = STATE_NEWLINE;
break;
case STATE_NEWLINE:
-   if (state_change && *ptr == '~') {
-   last_state = STATE_TILDE;
+   if (state_change && *ptr == "~%"[alt_esc]) {
+   last_state = STATE_ESCAPE;
continue;
}
if (*ptr != '\r')
last_state = STATE_NONE;
break;
-   case STATE_TILDE:
+   case STATE_ESCAPE:
   

Re: patch axen(4) (WIP)

2019-02-26 Thread Artturi Alm
On Tue, Feb 26, 2019 at 03:00:15PM +0100, Nils Frohberg wrote:
> On Mon, Feb 25, 2019 at 03:50:48PM -0300, Martin Pieuchot wrote:
> > On 25/02/19(Mon) 14:52, Nils Frohberg wrote:
> > > Hi,
> > > 
> > > as mentioned previously, I'm looking into axen(4). While searching
> > > for the cause of a panic (fixed since, thanks mpi@) I started to
> > > rewrite parts of the driver. References were mainly the FreeBSD and
> > > Linux drivers.
> > 
> > Please try to isolate parts of your diff that fixes issues and cosmetic
> > changes.  The simpler it gets the easier it is for us to review it.
> 
> Sure, I'll send separate patches.
> 
> (I cvs up'ed my src forder in order to test compile the individual
> patches and found out that xhci.c,v1.91 breaks my USB devices. I'll
> send a mail to bugs@ later.)
> 
> > > I didn't get around to much testing/debugging lately, therefore I
> > > wanted to share the current state (diff below).
> > > 
> > > The current state works a lot better than previously (for me). I
> > > used to have a huge amount of ierrs (aprrox. 1 ierr per ipkt) and
> > > often no packets would be transferred at all (or stop being transferred
> > > after some time).
> > 
> > Do you know why?  What were the problems?
> 
> I'm not 100% sure, since I did a lot of back and forth. It finally
> got better once I disabled EEE and lowered the watermark levels.
> 

Have you looked at what NetBSD has done with their axen(4)? there has
been 20commits in 2019 so far[0], while some of them are possibly,
idk., useless to us(thinking about hw checksum offloading), there was
some bug fixes that did look relevant to me, but i succesfully
installed&built kernels on nfs over axen(4) a couple of weeks ago,
so the bugs it has didn't feel critical enough for me to make
a branch for them. that was on arm64/dwctwo(4), tbh. i haven't been
happy with axen(4) on amd64/{e,x}hci(4) myself in the past either. :]

I guess i'm trying to say maybe it wouldn't hurt to sync a bit before
deviating as much as atleast your whole WIP diff did. I haven't read
your separate patches yet, but i'll try to get around to also testing
those before weekend:]

-Artturi

[0] https://github.com/NetBSD/src/commits/trunk/sys/dev/usb/if_axen.c



Re: video(1) and modesetting driver

2019-01-25 Thread Artturi Alm
On Fri, Jan 25, 2019 at 11:16:49AM +0100, Raphael Graf wrote:
> Hi Martin, 
> Thanks for your feedback!
> 
> On Wed, Jan 23, 2019 at 12:54:51PM -0200, Martin Pieuchot wrote:
> > Hello Raphael,
> > 
> > On 16/01/19(Wed) 12:41, Raphael Graf wrote:
> > > Here is an attempt to make video(1) work with the modesetting driver.
> > > See https://marc.info/?l=openbsd-bugs&m=152231686416039&w=2
> > > 
> > > The general idea:
> > > If there is no common encoding for input (device) and output (Xv), the
> > > encoding is converted to something supported by the output.
> > > No conversion is done if the output is sent to file (options -o/-O).
> > > 
> > > The option -e is now used as the input format. The output format
> > > is selected automatically (if output goes to Xv).
> > > 
> > > The following encodings are supported: yuy2, yuyv, uyuy, yv12
> > 
> > Did you test all of them?
> 
> Yes, I have tested all encodings with these two devices:
> 
> uvideo0 at uhub0 port 6 configuration 1 interface 0
> "Chicony Electronics Co., Ltd. product 0x480c" rev 2.00/31.34 addr 2
> 
> uvideo0 at uhub1 port 8 configuration 1 interface 0 "SC20A38485AA4629RX
> Integrated Camera" rev 2.00/0.21 addr 4
> 
> > 
> > > yuy2 and yuyv are treated as two different encodings, they share the same
> > > pixelformat, but have different ids. (This behaviour is different from the
> > > current description of '-e' in the manpage)
> > 
> > What about fixing the manpage then? ;)
> 
> The new diff below contains the changes to the manpage.
> 
> > 
> > > I have tested on two lenovo laptops using both drivers (modesetting and 
> > > intel).
> > > 
> > > On my laptop (lenovo X1 Carbon), with modesetting diver:
> > > yuyv is converted to yv12 before sending to Xv.
> > > 
> > > On the same laptop With intel driver:
> > > yuyv is converted to yuy2 (no-op)
> > 
> > Nice work, some comments below.
> > 
> > Make sure the code you're writing follows style(9) :o)
> > 
> > > Index: video.c
> > > ===
> > > RCS file: /cvs/xenocara/app/video/video.c,v
> > > retrieving revision 1.26
> > > diff -u -p -u -p -r1.26 video.c
> > > --- video.c   4 Jan 2019 17:45:00 -   1.26
> > > +++ video.c   16 Jan 2019 11:30:21 -
> > > @@ -38,6 +38,8 @@
> > >  #include 
> > >  #include 
> > > 
> > > +#define V_V4L2_PIX_FMT_YUY2v4l2_fourcc('Y', 'U', 'Y', '2')
> > 
> > Why do we need this define and not the others?  Aren't we missing an
> > include?
> 
> Actually, I don't know why this define is missing in videoio.h.
> This YUY2 format (id:0x32595559) is reported by Xv.
> The uvideo(4) driver reports YUYV which has a define in videoio.h.
> (YUY2 and YUYV are equivalent)
> 
> In the new diff, I have changed the variable names enc_in/enc_out to 
> enc/enc_xv
> as the second 'enc' is only used for Xv output.
> I also fixed the style(9) issues and added a CONV_NONE define.
> 
> Note that I'm not sure if the algorithm used in the yuy2_to_yv12 function is
> correct in respect to color theory..
> (It is a conversion from 16 to 12 bits/pixel)
> 
> Sorry, it is still a big diff, feedback is welcome.
> 
> 

Hi,

got one question below.

-Artturi

[...snip...]

> @@ -1633,6 +1631,34 @@ got_shutdown(int s)
>  }
>  
>  int
> +yuy2_to_yv12(uint8_t *src, uint8_t *dst, int width, int height)
> +{
> + int row, col, c, o;
> + int iy = 0;
> + int iu = width * height;
> + int iv = iu + iu / 4;
> +
> + for (row = 0; row < height * 2; row += 2) {
> + c = row * width;
> + for (col = 0; col < width * 2 ; col += 4) {
> + o = c + col;
> + dst[iy++] = src[o];
> + dst[iy++] = src[o + 2];
> + if ((row & 0x03)  == 0) {
> + o++;
> + dst[iv++] = (src[o] + src[o + width * 2]) / 2;
> + o += 2;
> + dst[iu++] = (src[o] + src[o + width * 2]) / 2;
> + if (o + width * 2 >= iu*2)
> + printf("hello\n");

is that a placeholder for something relevant, or what does hello mean here?

> + }
> + }
> + }
> +
> + return 0;
> +}
> +
> +int
>  stream(struct video *vid)
>  {
>   struct xdsp *x = &vid->xdsp;

[...snip...]



Re: sbin/wsconsctl: show more data

2019-01-07 Thread Artturi Alm
On Sat, Jan 05, 2019 at 10:39:46PM +0200, li...@wrant.com wrote:
> Just need a manual page and a tunable at some point, didn't much before.
> Still needed more text lines on the console and utf8 options previously.
> 
> Got less chars now, so console is a regression in data thus readability.
> Also, mention of direction in change log / commit message would be nice.
> 
> On 27" 2560x1440 panel, usable res was 1920x1200 160x54 and then 160x65.
> Topic: show more data, now 160x45 (spleen 16x32) << 425x110 (misc 6x13).
> 
> 2010-2020, stuck at about 50 lines at 100 PPI is a huge waste of pixels.
> 

if you're going to jsut complain w/o a diff,
you should do it at the source of it[0]; or just patch and move on.

-Artturi

[0]: https://bugzilla.kernel.org/show_bug.cgi?id=172421



Re: sbin/wsconsctl: show more data

2019-01-05 Thread Artturi Alm
On Sat, Jan 05, 2019 at 01:50:22AM +0200, Artturi Alm wrote:
> Hi,
> 
> guessing i'm not the only one wondering about these sizes, as w/current
> snapshot the font does seem too big for me(on 2560x1440 display, for
> which radeondrm(4) has never gotten the size right(giving only 1920x1200)).
> 
> display.part of wsconsctl output w/the diff:
> display.type=radeondrm
> display.width=1920
> display.height=1200
> display.depth=32
> display.emulations=vt100
> display.col_x_row=120x37
> display.font_wxh=16x32
> display.screentypes=std
> display.focus=4
> display.screen_on=250
> display.screen_off=0
> display.vblank=off
> display.kbdact=on
> display.msact=on
> display.outact=on
> 
> lazy(=ugly) not-so-minimal diff below.
> 
> -Artturi
> 

fwiw., what i have w/o spleen:
display.type=radeondrm
display.width=1920
display.height=1200
display.depth=32
display.emulations=vt100
display.col_x_row=160x54
display.font_wxh=12x22
display.screentypes=std

which is usable, and the wrong width/height doesn't matter so much.
i suppose i should have written to bugs@ at this point, with picture
showing the size of gaps around 'i', effectively making "libxxx" read
like "l i bxxx".

-Artturi



sbin/wsconsctl: show more data

2019-01-04 Thread Artturi Alm
Hi,

guessing i'm not the only one wondering about these sizes, as w/current
snapshot the font does seem too big for me(on 2560x1440 display, for
which radeondrm(4) has never gotten the size right(giving only 1920x1200)).

display.part of wsconsctl output w/the diff:
display.type=radeondrm
display.width=1920
display.height=1200
display.depth=32
display.emulations=vt100
display.col_x_row=120x37
display.font_wxh=16x32
display.screentypes=std
display.focus=4
display.screen_on=250
display.screen_off=0
display.vblank=off
display.kbdact=on
display.msact=on
display.outact=on

lazy(=ugly) not-so-minimal diff below.

-Artturi


diff --git a/sbin/wsconsctl/display.c b/sbin/wsconsctl/display.c
index 6f789291142..9927a9d77c5 100644
--- a/sbin/wsconsctl/display.c
+++ b/sbin/wsconsctl/display.c
@@ -42,6 +42,7 @@
 
 u_int dpytype;
 u_int width, height, depth;
+u_int cxr[2], fontwxh[2];
 int focus;
 struct field_pc brightness, contrast, backlight;
 int burnon, burnoff, vblank, kbdact, msact, outact;
@@ -55,6 +56,8 @@ struct field display_field_tab[] = {
 { "height",&height,FMT_UINT,   FLG_RDONLY },
 { "depth", &depth, FMT_UINT,   FLG_RDONLY },
 { "emulations",&emuls, FMT_EMUL,   FLG_RDONLY },
+{ "col_x_row", &cxr,   FMT_UINTX,  FLG_RDONLY },
+{ "font_wxh",  &fontwxh,   FMT_UINTX,  FLG_RDONLY },
 { "screentypes",   &screens,   FMT_SCREEN, FLG_RDONLY },
 { "focus", &focus, FMT_INT,FLG_NORDBACK },
 { "brightness",&brightness,FMT_PC, FLG_MODIFY|FLG_INIT },
@@ -85,6 +88,7 @@ display_get_values(int fd)
void *ptr;
unsigned long cmd;
int bon = 0, fbon = 0;
+   int fson = 0;
 
focus = gscr.idx = -1;
for (pf = display_field_tab; pf->name; pf++) {
@@ -102,6 +106,10 @@ display_get_values(int fd)
} else if (ptr == &emuls) {
fillioctl(WSDISPLAYIO_GETEMULTYPE);
emuls.idx=0;
+   } else if (ptr == &cxr || ptr == &fontwxh) {
+   fillioctl(WSDISPLAYIO_GETSCREENTYPE);
+   ptr = &screens;
+   screens.idx = 0;
} else if (ptr == &screens) {
fillioctl(WSDISPLAYIO_GETSCREENTYPE);
screens.idx=0;
@@ -168,6 +176,13 @@ display_get_values(int fd)
emuls.idx=fd;
} else if (ptr == &screens) {
screens.idx=fd;
+   if (!fson) {
+   cxr[0] = screens.ncols;
+   cxr[1] = screens.nrows;
+   fontwxh[0] = screens.fontwidth;
+   fontwxh[1] = screens.fontheight;
+   }
+   fson++;
} else if (ptr == ¶m) {
struct field_pc *pc = pf->valp;
 
diff --git a/sbin/wsconsctl/util.c b/sbin/wsconsctl/util.c
index b0ac4b3e23f..071baf31f85 100644
--- a/sbin/wsconsctl/util.c
+++ b/sbin/wsconsctl/util.c
@@ -186,6 +186,7 @@ int name2int(char *, const struct nameint *, int);
 void print_kmap(struct wskbd_map_data *);
 void print_emul(struct wsdisplay_emultype *);
 void print_screen(struct wsdisplay_screentype *);
+void print_uintx(u_int *);
 
 struct field *
 field_by_name(struct field *field_tab, char *name)
@@ -316,6 +317,9 @@ pr_field(const char *pre, struct field *f, const char *sep)
case FMT_CFG:
mousecfg_pr_field((struct wsmouse_parameters *) f->valp);
break;
+   case FMT_UINTX:
+   print_uintx((u_int *) f->valp);
+   break;
default:
errx(1, "internal error: pr_field: no format %d", f->format);
break;
@@ -551,3 +555,9 @@ print_screen(struct wsdisplay_screentype *screens)
i = ioctl(fd, WSDISPLAYIO_GETSCREENTYPE, &s);
}
 }
+
+void
+print_uintx(u_int *ux)
+{
+   printf("%ux%u", ux[0], ux[1]);
+}
diff --git a/sbin/wsconsctl/wsconsctl.h b/sbin/wsconsctl/wsconsctl.h
index 3a6e38d67e2..93d42ed600a 100644
--- a/sbin/wsconsctl/wsconsctl.h
+++ b/sbin/wsconsctl/wsconsctl.h
@@ -49,6 +49,7 @@ struct field {
 #define FMT_SCREEN 108 /* wsdisplay screen types */
 #define FMT_STRING 109 /* free string */
 #define FMT_CFG201 /* wsmouse parameters */
+#define FMT_UINTX  202 /* u_int x u_int */
int format;
 #define FLG_RDONLY 0x0001  /* variable cannot be modified */
 #define FLG_WRONLY 0x0002  /* variable cannot be displayed */



dev/fdt/sxi{mmc,twi}.c: better english - err printf()s s/can't to/failed to/

2018-12-04 Thread Artturi Alm
Hi,

spotted these while looking at x_attach() printf()s for something else.

-Artturi


diff --git a/sys/dev/fdt/sximmc.c b/sys/dev/fdt/sximmc.c
index eb5cf7f353e..9fa831d955a 100644
--- a/sys/dev/fdt/sximmc.c
+++ b/sys/dev/fdt/sximmc.c
@@ -418,7 +418,7 @@ sximmc_attach(struct device *parent, struct device *self, 
void *aux)
sc->sc_ih = fdt_intr_establish(faa->fa_node, IPL_BIO,
sximmc_intr, sc, sc->sc_dev.dv_xname);
if (sc->sc_ih == NULL) {
-   printf(": can't to establish interrupt\n");
+   printf(": failed to establish interrupt\n");
return;
}
 
diff --git a/sys/dev/fdt/sxitwi.c b/sys/dev/fdt/sxitwi.c
index 3c261d7cc5b..36d06aa5a15 100644
--- a/sys/dev/fdt/sxitwi.c
+++ b/sys/dev/fdt/sxitwi.c
@@ -278,7 +278,7 @@ sxitwi_attach(struct device *parent, struct device *self, 
void *aux)
sc->sc_ih = fdt_intr_establish(faa->fa_node, IPL_BIO,
sxitwi_intr, sc, sc->sc_dev.dv_xname);
if (sc->sc_ih == NULL) {
-   printf(": can't to establish interrupt\n");
+   printf(": failed to establish interrupt\n");
return;
}
 



distrib/notes/arm64/hardware mention SMP

2018-09-29 Thread Artturi Alm
Hi,

subject is a bit misleading, sorry about that, but another user on IRC
was wondering why there was no option to choose SMP .mp kernel during
installation for another arch when i noticed some of these missing(?).

I don't have a sparc64, nor remember whether the automagics would cover
it too, so i didn't touch it.

-Artturi

ps. (?) above == i'm unsure about the distrib/notes/arm64/features bit.


diff --git distrib/notes/amd64/hardware distrib/notes/amd64/hardware
index 66c632dc998..402ff8375f8 100644
--- distrib/notes/amd64/hardware
+++ distrib/notes/amd64/hardware
@@ -4,7 +4,8 @@ compatible designs.
 
 OpenBSD/MACHINE OSREV supports most SMP (Symmetrical MultiProcessor)
 systems.  To support SMP operation, a separate SMP kernel (bsd.mp)
-is included with the installation file sets.
+is included and installed automatically with the installation file
+sets.
 
 OpenBSD/MACHINE OSREV supports both UEFI/GPT booting and BIOS/MBR
 booting.
diff --git distrib/notes/arm64/features distrib/notes/arm64/features
index 86207425c8d..62fa9bbf01f 100644
--- distrib/notes/arm64/features
+++ distrib/notes/arm64/features
@@ -21,7 +21,7 @@ dnl (i.e. md_consoleinfo is not empty)
 define({:-MDSERCONS-:},)dnl
 dnl
 dnl define if SMP kernels are provided
-define({:-MDSMP-:},)dnl
+define({:-MDSMP-:},1)dnl
 dnl
 dnl define if shared libraries are provided
 define({:-MDSO-:},1)dnl
diff --git distrib/notes/arm64/hardware distrib/notes/arm64/hardware
index a4388daa1c9..f29ba18d97c 100644
--- distrib/notes/arm64/hardware
+++ distrib/notes/arm64/hardware
@@ -20,3 +20,8 @@ The following machines are targeted by OpenBSD/MACHINE:
Theobroma Systems RK3399-Q7
Socionext SC2A11
Socionext SynQuacer-E Developerbox
+
+OpenBSD/MACHINE OSREV supports most SMP (Symmetrical MultiProcessor)
+systems.  To support SMP operation, a separate SMP kernel (bsd.mp)
+is included and installed automatically with the installation file
+sets.
diff --git distrib/notes/i386/hardware distrib/notes/i386/hardware
index ce71e9cac98..1b83947eeb2 100644
--- distrib/notes/i386/hardware
+++ distrib/notes/i386/hardware
@@ -8,7 +8,8 @@ that rely on a custom BIOS to paper over implementation 
differences.
 
 OpenBSD/MACHINE OSREV supports most SMP (Symmetrical MultiProcessor)
 systems.  To support SMP operation, a separate SMP kernel (bsd.mp)
-is included with the installation file sets.
+is included and installed automatically with the installation file
+sets.
 
 The minimal configuration to install the system is 32MB of RAM and
 at least 250MB of disk space to accommodate the `base' set.



Re: urndis(4) fix

2018-09-23 Thread Artturi Alm
On Mon, Sep 24, 2018 at 03:34:59AM +0300, Artturi Alm wrote:
> On Sat, Nov 29, 2014 at 09:42:51PM +0100, Mark Kettenis wrote:
> > Recent Oracle SPARC machines have a USB gadget to talk to the Service
> > Processor (ILOM).  This gadget supports both RNDIS and CDC Ethernet.
> > The RNDIS bits uncovered a bug in urndis(4).  When urndis_ctrl_set()
> > sets up the REMOTE_NDIS_SET_MSG command it sets up msg->rm_infobuflen,
> > it subsequently overwrites its contents.  Apparently many RNDIS
> > devices don't care, but this hardware sends a response back that
> > indicates the command wasn't accepted.  Diff below fixes this problem.
> > It matches what Linux does.
> > 
> > Unfortunately, this isn't enough to make the gadget work in RNDIS mode.
> > 
> > I'd appreciate it if people using urndis(4) could test this diff.
> > 
> 
> Hi,
> 
> just found your mail, i think urndis(4) is not entirely written with
> these in mind:
>   defined(__STRICT_ALIGNMENT) || _BYTE_ORDER != _LITTLE_ENDIAN
> 
> did you ever try with a diff like below?
> 
> -Artturi
> 

sorry for the 'spam', on a second read of your message, i think it might
be just more strict than ie. android, not allowing the _SET_MSG from
urndis_attach(), because it's "out-of-order" with regards to msg sent
by urndis_ctrl_init(). if it's not in the "spec", atleast MS[0] does
show things done differently, == init first before setting data packet
filter.

-Artturi

[0]:
https://docs.microsoft.com/en-us/windows-hardware/drivers/network/example-connectionless--802-3--initialization-sequence



Re: urndis0: urndis_decap invalid buffer len 1 < minimum header 44

2018-09-23 Thread Artturi Alm
On Tue, Sep 18, 2018 at 07:13:15PM +0300, Artturi Alm wrote:
> On Sat, Aug 18, 2018 at 11:05:04PM +0300, Artturi Alm wrote:
> > On Thu, Jan 11, 2018 at 12:41:29AM +0200, Artturi Alm wrote:
> > > On Wed, Sep 13, 2017 at 05:51:27AM +0300, Artturi Alm wrote:
> > > > Hi,
> > > > 
> > > > even after having recently updated the phone to a newer version of 
> > > > android,
> > > > i'm still spammed by urndis w/msg on subject.
> > > > 
> > > > doesn't really matter to me what you do to silence it, but something 
> > > > like
> > > > below does work for me, and thanks in advacne:)
> > > > -Artturi
> > > > 
> > > 
> > > ping?
> > > i was told i don't reason my diffs, so here's sorry attempt:
> > > $ dmesg | wc -l
> > > 1040
> > > $ dmesg | grep urndis_decap | wc -l
> > > 1039
> > > 
> > > either of the diffs below would work for me.
> > > -Artturi
> > > 
> > > 
> > > ... this ...
> > > 
> > > diff --git a/sys/dev/usb/if_urndis.c b/sys/dev/usb/if_urndis.c
> > > index 5d148da4ab5..7dc12573c0d 100644
> > > --- a/sys/dev/usb/if_urndis.c
> > > +++ b/sys/dev/usb/if_urndis.c
> > > @@ -834,11 +834,11 @@ urndis_decap(struct urndis_softc *sc, struct 
> > > urndis_chain *c, u_int32_t len)
> > >   len));
> > >  
> > >   if (len < sizeof(*msg)) {
> > > - printf("%s: urndis_decap invalid buffer len %u < "
> > > + DPRINTF(("%s: urndis_decap invalid buffer len %u < "
> > >   "minimum header %zu\n",
> > >   DEVNAME(sc),
> > >   len,
> > > - sizeof(*msg));
> > > + sizeof(*msg)));
> > >   return;
> > >   }
> > >  
> > > 
> > > 
> > > ... or this ...
> > > 
> > > diff --git a/sys/dev/usb/if_urndis.c b/sys/dev/usb/if_urndis.c
> > > index 5d148da4ab5..4b2c6e89ec9 100644
> > > --- a/sys/dev/usb/if_urndis.c
> > > +++ b/sys/dev/usb/if_urndis.c
> > > @@ -834,6 +834,8 @@ urndis_decap(struct urndis_softc *sc, struct 
> > > urndis_chain *c, u_int32_t len)
> > >   len));
> > >  
> > >   if (len < sizeof(*msg)) {
> > > + if (len == 1)   /* workaround for spamming androids */
> > > + return;
> > >   printf("%s: urndis_decap invalid buffer len %u < "
> > >   "minimum header %zu\n",
> > >   DEVNAME(sc),
> > 
> > Hi,
> > 
> > this should fix the urndis_decap() spam more properly by allowing operation
> > as is needed by the linux(android) gadget/function code for usb rndis too,
> > which is explained there to be 
> > "zlp framing on tx for strict CDC-Ether conformance",
> > and our cdce(4) does have somewhat similar if (total_len <= 1) goto done;.
> > 
> > also, i think the _decap spam is as bad as it is because of those returns,
> > dropping valid packet met before "error", leading to retries likely being
> > the same; triggering the spam loop..
> > 
> 
> pong? the spam and dropping of a valid packet is not correct.
> this is far from making the driver bug-free/following the spec,
> but definately worth fixing as the only user-visible annoyance.
> 
> i don't think i can explain why any better than is done here:
> https://docs.microsoft.com/en-us/windows-hardware/drivers/network/usb-short-packets
> 
> above is specifically about/for rndis, even if the url doesn't hint so,
> and there is a note it'll take two minutes to read..
> 

new diff below, with some other minor fixes to balance my addition to
urndis_decap.

- urndis_ctrl_set_param() is unused, shouldn't end up in kernel binary,
but atleast should balance compile-time wise :]
- in urndis_ctrl_init(), don't htole32(0) (like is not done in other
urndis_ctrl_xxx either), and setting rm_ver_minor to 1 is against the
"spec", while atleast old androids ignore this, so it hasn't possibly
caused many problems in real life.. see rndis.h for _VERSION_ defines.

and rest is the decap fix, for which i added a comment too.

the version in my previous mail was OK'ed off-list by armani@.

-Artturi



diff --git sys/dev/usb/if_urndis.c sys/dev/us

Re: urndis(4) fix

2018-09-23 Thread Artturi Alm
On Sat, Nov 29, 2014 at 09:42:51PM +0100, Mark Kettenis wrote:
> Recent Oracle SPARC machines have a USB gadget to talk to the Service
> Processor (ILOM).  This gadget supports both RNDIS and CDC Ethernet.
> The RNDIS bits uncovered a bug in urndis(4).  When urndis_ctrl_set()
> sets up the REMOTE_NDIS_SET_MSG command it sets up msg->rm_infobuflen,
> it subsequently overwrites its contents.  Apparently many RNDIS
> devices don't care, but this hardware sends a response back that
> indicates the command wasn't accepted.  Diff below fixes this problem.
> It matches what Linux does.
> 
> Unfortunately, this isn't enough to make the gadget work in RNDIS mode.
> 
> I'd appreciate it if people using urndis(4) could test this diff.
> 

Hi,

just found your mail, i think urndis(4) is not entirely written with
these in mind:
defined(__STRICT_ALIGNMENT) || _BYTE_ORDER != _LITTLE_ENDIAN

did you ever try with a diff like below?

-Artturi


diff --git sys/dev/rndis.h sys/dev/rndis.h
index 140793990e9..7036d198d4e 100644
--- sys/dev/rndis.h
+++ sys/dev/rndis.h
@@ -98,7 +98,7 @@
 struct rndis_msghdr {
uint32_trm_type;
uint32_trm_len;
-};
+} __packed;
 
 /*
  * RNDIS data message
@@ -118,7 +118,7 @@ struct rndis_packet_msg {
uint32_trm_pktinfolen;
uint32_trm_vchandle;
uint32_trm_reserved;
-};
+} __packed;
 
 /* Per-packet-info for RNDIS data message */
 struct rndis_pktinfo {
@@ -126,7 +126,7 @@ struct rndis_pktinfo {
uint32_trm_type;/* NDIS_PKTINFO_TYPE_ */
uint32_trm_pktinfooffset;
uint8_t rm_data[0];
-};
+} __packed;
 
 #define NDIS_PKTINFO_TYPE_CSUM 0
 #define NDIS_PKTINFO_TYPE_IPSEC1
@@ -149,7 +149,7 @@ struct rndis_comp_hdr {
uint32_trm_len;
uint32_trm_rid;
uint32_trm_status;
-};
+} __packed;
 
 /* Initialize the device. */
 #define REMOTE_NDIS_INITIALIZE_MSG 0x0002
@@ -162,7 +162,7 @@ struct rndis_init_req {
uint32_trm_ver_major;
uint32_trm_ver_minor;
uint32_trm_max_xfersz;
-};
+} __packed;
 
 struct rndis_init_comp {
uint32_trm_type;
@@ -178,7 +178,7 @@ struct rndis_init_comp {
uint32_trm_align;
uint32_trm_aflistoffset;
uint32_trm_aflistsz;
-};
+} __packed;
 
 /* Halt the device.  No response sent. */
 #define REMOTE_NDIS_HALT_MSG   0x0003
@@ -187,7 +187,7 @@ struct rndis_halt_req {
uint32_trm_type;
uint32_trm_len;
uint32_trm_rid;
-};
+} __packed;
 
 /* Send a query object. */
 #define REMOTE_NDIS_QUERY_MSG  0x0004
@@ -201,7 +201,7 @@ struct rndis_query_req {
uint32_trm_infobuflen;
uint32_trm_infobufoffset;
uint32_trm_devicevchdl;
-};
+} __packed;
 
 struct rndis_query_comp {
uint32_trm_type;
@@ -210,7 +210,7 @@ struct rndis_query_comp {
uint32_trm_status;
uint32_trm_infobuflen;
uint32_trm_infobufoffset;
-};
+} __packed;
 
 /* Send a set object request. */
 #define REMOTE_NDIS_SET_MSG0x0005
@@ -224,14 +224,14 @@ struct rndis_set_req {
uint32_trm_infobuflen;
uint32_trm_infobufoffset;
uint32_trm_devicevchdl;
-};
+} __packed;
 
 struct rndis_set_comp {
uint32_trm_type;
uint32_trm_len;
uint32_trm_rid;
uint32_trm_status;
-};
+} __packed;
 
 /* Parameter used by OID_GEN_RNDIS_CONFIG_PARAMETER. */
 #define REMOTE_NDIS_SET_PARAM_NUMERIC  0x
@@ -243,7 +243,7 @@ struct rndis_set_parameter {
uint32_trm_type;
uint32_trm_valueoffset;
uint32_trm_valuelen;
-};
+} __packed;
 
 /* Perform a soft reset on the device. */
 #define REMOTE_NDIS_RESET_MSG  0x0006
@@ -253,14 +253,14 @@ struct rndis_reset_req {
uint32_trm_type;
uint32_trm_len;
uint32_trm_rid;
-};
+} __packed;
 
 struct rndis_reset_comp {
uint32_trm_type;
uint32_trm_len;
uint32_trm_status;
uint32_trm_adrreset;
-};
+} __packed;
 
 /* 802.3 link-state or undefined message error.  Sent by device. */
 #define REMOTE_NDIS_INDICATE_STATUS_MSG0x0007
@@ -272,7 +272,7 @@ struct rndis_status_msg {
uint32_trm_stbuflen;
uint32_trm_stbufoffset;
/* rndis_diag_info */
-};
+} __packed;
 
 /*
  * Immediately after rndis_status_msg.rm_stbufoffset, if a control
@@ -282,7 +282,7 @@ struct rndis_status_msg {
 struct rndis_diag_info {
uint32_trm_diagstatus;
uint32_trm_erroffset;
-};
+} __packed;
 
 /* Keepalive messsage.  May be sent by device. */
 #define REMOTE_NDIS_KEEPALIVE_MSG  0x000

Re: urndis0: urndis_decap invalid buffer len 1 < minimum header 44

2018-09-18 Thread Artturi Alm
On Sat, Aug 18, 2018 at 11:05:04PM +0300, Artturi Alm wrote:
> On Thu, Jan 11, 2018 at 12:41:29AM +0200, Artturi Alm wrote:
> > On Wed, Sep 13, 2017 at 05:51:27AM +0300, Artturi Alm wrote:
> > > Hi,
> > > 
> > > even after having recently updated the phone to a newer version of 
> > > android,
> > > i'm still spammed by urndis w/msg on subject.
> > > 
> > > doesn't really matter to me what you do to silence it, but something like
> > > below does work for me, and thanks in advacne:)
> > > -Artturi
> > > 
> > 
> > ping?
> > i was told i don't reason my diffs, so here's sorry attempt:
> > $ dmesg | wc -l
> > 1040
> > $ dmesg | grep urndis_decap | wc -l
> > 1039
> > 
> > either of the diffs below would work for me.
> > -Artturi
> > 
> > 
> > ... this ...
> > 
> > diff --git a/sys/dev/usb/if_urndis.c b/sys/dev/usb/if_urndis.c
> > index 5d148da4ab5..7dc12573c0d 100644
> > --- a/sys/dev/usb/if_urndis.c
> > +++ b/sys/dev/usb/if_urndis.c
> > @@ -834,11 +834,11 @@ urndis_decap(struct urndis_softc *sc, struct 
> > urndis_chain *c, u_int32_t len)
> > len));
> >  
> > if (len < sizeof(*msg)) {
> > -   printf("%s: urndis_decap invalid buffer len %u < "
> > +   DPRINTF(("%s: urndis_decap invalid buffer len %u < "
> > "minimum header %zu\n",
> > DEVNAME(sc),
> > len,
> > -   sizeof(*msg));
> > +   sizeof(*msg)));
> > return;
> > }
> >  
> > 
> > 
> > ... or this ...
> > 
> > diff --git a/sys/dev/usb/if_urndis.c b/sys/dev/usb/if_urndis.c
> > index 5d148da4ab5..4b2c6e89ec9 100644
> > --- a/sys/dev/usb/if_urndis.c
> > +++ b/sys/dev/usb/if_urndis.c
> > @@ -834,6 +834,8 @@ urndis_decap(struct urndis_softc *sc, struct 
> > urndis_chain *c, u_int32_t len)
> > len));
> >  
> > if (len < sizeof(*msg)) {
> > +   if (len == 1)   /* workaround for spamming androids */
> > +   return;
> > printf("%s: urndis_decap invalid buffer len %u < "
> > "minimum header %zu\n",
> > DEVNAME(sc),
> 
> Hi,
> 
> this should fix the urndis_decap() spam more properly by allowing operation
> as is needed by the linux(android) gadget/function code for usb rndis too,
> which is explained there to be 
>   "zlp framing on tx for strict CDC-Ether conformance",
> and our cdce(4) does have somewhat similar if (total_len <= 1) goto done;.
> 
> also, i think the _decap spam is as bad as it is because of those returns,
> dropping valid packet met before "error", leading to retries likely being
> the same; triggering the spam loop..
> 

pong? the spam and dropping of a valid packet is not correct.
this is far from making the driver bug-free/following the spec,
but definately worth fixing as the only user-visible annoyance.

i don't think i can explain why any better than is done here:
https://docs.microsoft.com/en-us/windows-hardware/drivers/network/usb-short-packets

above is specifically about/for rndis, even if the url doesn't hint so,
and there is a note it'll take two minutes to read..

> -Artturi
> 
> 
> diff --git sys/dev/usb/if_urndis.c sys/dev/usb/if_urndis.c
> index 5d148da4ab5..136e3e22af8 100644
> --- sys/dev/usb/if_urndis.c
> +++ sys/dev/usb/if_urndis.c
> @@ -820,13 +820,15 @@ urndis_decap(struct urndis_softc *sc, struct 
> urndis_chain *c, u_int32_t len)
>   struct mbuf_list ml = MBUF_LIST_INITIALIZER();
>   struct rndis_packet_msg *msg;
>   struct ifnet*ifp;
> + int  got;
>   int  s;
>   int  offset;
>  
>   ifp = GET_IFP(sc);
> + got = 0;
>   offset = 0;
>  
> - while (len > 0) {
> + while (len > 1) {
>   msg = (struct rndis_packet_msg *)((char*)c->sc_buf + offset);
>   m = c->sc_mbuf;
>  
> @@ -839,7 +841,7 @@ urndis_decap(struct urndis_softc *sc, struct urndis_chain 
> *c, u_int32_t len)
>   DEVNAME(sc),
>   len,
>   sizeof(*msg));
> - return;
> + break;
>

usbd_close_pipe.9: usbd_abort_pipe is void

2018-09-02 Thread Artturi Alm
Hi,

spotted this while removing return value from usbd_close_pipe,
following cleanup by pirofti@[0], which made usbd_abort_pipe void.


-Artturi

[0]:
https://github.com/openbsd/src/commit/1e087f7cf25ce711b6cef28d054ab4a68be213d2


diff --git share/man/man9/usbd_close_pipe.9 share/man/man9/usbd_close_pipe.9
index 650182d5284..3c2027c337e 100644
--- share/man/man9/usbd_close_pipe.9
+++ share/man/man9/usbd_close_pipe.9
@@ -25,7 +25,7 @@
 .In dev/usb/usbdi.h
 .Ft usbd_status
 .Fn usbd_close_pipe "struct usbd_pipe *pipe"
-.Ft usbd_status
+.Ft void
 .Fn usbd_abort_pipe "struct usbd_pipe *pipe"
 .Sh DESCRIPTION
 The



Re: urndis(4) ++ RAMDISKs

2018-08-31 Thread Artturi Alm
On Mon, Aug 20, 2018 at 02:15:55PM +0300, Artturi Alm wrote:
> Hi,
> 
> these have been missing for some reason, but i'm guessing i wouldn't be
> the only user using urndis, rather than messing around with firmwares
> when rushing into reinstall having forgotten about some necessary fw..
> 
> (arm64 RAMDISK has urndis(4) already.)
> 

ping?

> -Artturi
> 
> 
> diff --git sys/arch/amd64/conf/RAMDISK_CD sys/arch/amd64/conf/RAMDISK_CD
> index 6a50c8dd2d3..2b4d2bd7611 100644
> --- sys/arch/amd64/conf/RAMDISK_CD
> +++ sys/arch/amd64/conf/RAMDISK_CD
> @@ -109,6 +109,7 @@ cue*  at uhub?# CATC 
> USB-EL1201A based Ethernet
>  kue* at uhub?# Kawasaki KL5KUSB101B based Ethernet
>  smsc*at uhub?# SMSC LAN95xx Ethernet
>  cdce*at uhub?# CDC Ethernet
> +urndis*  at uhub?# Remote NDIS Ethernet
>  udav*at uhub?# Davicom DM9601 based Ethernet
>  mos* at uhub?# MOSCHIP MCS7730/7830 10/100 Ethernet
>  mue* at uhub?# Microchip LAN75xx/LAN78xx Ethernet
> diff --git sys/arch/armv7/conf/RAMDISK sys/arch/armv7/conf/RAMDISK
> index f1d6c191500..277bf55d011 100644
> --- sys/arch/armv7/conf/RAMDISK
> +++ sys/arch/armv7/conf/RAMDISK
> @@ -235,6 +235,7 @@ cue*  at uhub?# CATC 
> USB-EL1201A based Ethernet
>  kue* at uhub?# Kawasaki KL5KUSB101B based Ethernet
>  smsc*at uhub?# SMSC LAN95xx Ethernet
>  cdce*at uhub?# CDC Ethernet
> +urndis*  at uhub?# Remote NDIS Ethernet
>  udav*at uhub?# Davicom DM9601 based Ethernet
>  mos* at uhub?# MOSCHIP MCS7730/7830 10/100 Ethernet
>  mue* at uhub?# Microchip LAN75xx/LAN78xx Ethernet



urndis(4) ++ RAMDISKs

2018-08-20 Thread Artturi Alm
Hi,

these have been missing for some reason, but i'm guessing i wouldn't be
the only user using urndis, rather than messing around with firmwares
when rushing into reinstall having forgotten about some necessary fw..

(arm64 RAMDISK has urndis(4) already.)

-Artturi


diff --git sys/arch/amd64/conf/RAMDISK_CD sys/arch/amd64/conf/RAMDISK_CD
index 6a50c8dd2d3..2b4d2bd7611 100644
--- sys/arch/amd64/conf/RAMDISK_CD
+++ sys/arch/amd64/conf/RAMDISK_CD
@@ -109,6 +109,7 @@ cue*at uhub?# CATC 
USB-EL1201A based Ethernet
 kue*   at uhub?# Kawasaki KL5KUSB101B based Ethernet
 smsc*  at uhub?# SMSC LAN95xx Ethernet
 cdce*  at uhub?# CDC Ethernet
+urndis*at uhub?# Remote NDIS Ethernet
 udav*  at uhub?# Davicom DM9601 based Ethernet
 mos*   at uhub?# MOSCHIP MCS7730/7830 10/100 Ethernet
 mue*   at uhub?# Microchip LAN75xx/LAN78xx Ethernet
diff --git sys/arch/armv7/conf/RAMDISK sys/arch/armv7/conf/RAMDISK
index f1d6c191500..277bf55d011 100644
--- sys/arch/armv7/conf/RAMDISK
+++ sys/arch/armv7/conf/RAMDISK
@@ -235,6 +235,7 @@ cue*at uhub?# CATC 
USB-EL1201A based Ethernet
 kue*   at uhub?# Kawasaki KL5KUSB101B based Ethernet
 smsc*  at uhub?# SMSC LAN95xx Ethernet
 cdce*  at uhub?# CDC Ethernet
+urndis*at uhub?# Remote NDIS Ethernet
 udav*  at uhub?# Davicom DM9601 based Ethernet
 mos*   at uhub?# MOSCHIP MCS7730/7830 10/100 Ethernet
 mue*   at uhub?# Microchip LAN75xx/LAN78xx Ethernet



Re: urndis0: urndis_decap invalid buffer len 1 < minimum header 44

2018-08-18 Thread Artturi Alm
On Thu, Jan 11, 2018 at 12:41:29AM +0200, Artturi Alm wrote:
> On Wed, Sep 13, 2017 at 05:51:27AM +0300, Artturi Alm wrote:
> > Hi,
> > 
> > even after having recently updated the phone to a newer version of android,
> > i'm still spammed by urndis w/msg on subject.
> > 
> > doesn't really matter to me what you do to silence it, but something like
> > below does work for me, and thanks in advacne:)
> > -Artturi
> > 
> 
> ping?
> i was told i don't reason my diffs, so here's sorry attempt:
> $ dmesg | wc -l
> 1040
> $ dmesg | grep urndis_decap | wc -l
> 1039
> 
> either of the diffs below would work for me.
> -Artturi
> 
> 
> ... this ...
> 
> diff --git a/sys/dev/usb/if_urndis.c b/sys/dev/usb/if_urndis.c
> index 5d148da4ab5..7dc12573c0d 100644
> --- a/sys/dev/usb/if_urndis.c
> +++ b/sys/dev/usb/if_urndis.c
> @@ -834,11 +834,11 @@ urndis_decap(struct urndis_softc *sc, struct 
> urndis_chain *c, u_int32_t len)
>   len));
>  
>   if (len < sizeof(*msg)) {
> - printf("%s: urndis_decap invalid buffer len %u < "
> + DPRINTF(("%s: urndis_decap invalid buffer len %u < "
>   "minimum header %zu\n",
>   DEVNAME(sc),
>   len,
> - sizeof(*msg));
> + sizeof(*msg)));
>   return;
>   }
>  
> 
> 
> ... or this ...
> 
> diff --git a/sys/dev/usb/if_urndis.c b/sys/dev/usb/if_urndis.c
> index 5d148da4ab5..4b2c6e89ec9 100644
> --- a/sys/dev/usb/if_urndis.c
> +++ b/sys/dev/usb/if_urndis.c
> @@ -834,6 +834,8 @@ urndis_decap(struct urndis_softc *sc, struct urndis_chain 
> *c, u_int32_t len)
>   len));
>  
>   if (len < sizeof(*msg)) {
> + if (len == 1)   /* workaround for spamming androids */
> + return;
>   printf("%s: urndis_decap invalid buffer len %u < "
>   "minimum header %zu\n",
>   DEVNAME(sc),

Hi,

this should fix the urndis_decap() spam more properly by allowing operation
as is needed by the linux(android) gadget/function code for usb rndis too,
which is explained there to be 
"zlp framing on tx for strict CDC-Ether conformance",
and our cdce(4) does have somewhat similar if (total_len <= 1) goto done;.

also, i think the _decap spam is as bad as it is because of those returns,
dropping valid packet met before "error", leading to retries likely being
the same; triggering the spam loop..

-Artturi


diff --git sys/dev/usb/if_urndis.c sys/dev/usb/if_urndis.c
index 5d148da4ab5..136e3e22af8 100644
--- sys/dev/usb/if_urndis.c
+++ sys/dev/usb/if_urndis.c
@@ -820,13 +820,15 @@ urndis_decap(struct urndis_softc *sc, struct urndis_chain 
*c, u_int32_t len)
struct mbuf_list ml = MBUF_LIST_INITIALIZER();
struct rndis_packet_msg *msg;
struct ifnet*ifp;
+   int  got;
int  s;
int  offset;
 
ifp = GET_IFP(sc);
+   got = 0;
offset = 0;
 
-   while (len > 0) {
+   while (len > 1) {
msg = (struct rndis_packet_msg *)((char*)c->sc_buf + offset);
m = c->sc_mbuf;
 
@@ -839,7 +841,7 @@ urndis_decap(struct urndis_softc *sc, struct urndis_chain 
*c, u_int32_t len)
DEVNAME(sc),
len,
sizeof(*msg));
-   return;
+   break;
}
 
DPRINTF(("%s: urndis_decap len %u data(off:%u len:%u) "
@@ -859,14 +861,14 @@ urndis_decap(struct urndis_softc *sc, struct urndis_chain 
*c, u_int32_t len)
DEVNAME(sc),
letoh32(msg->rm_type),
REMOTE_NDIS_PACKET_MSG);
-   return;
+   break;
}
if (letoh32(msg->rm_len) < sizeof(*msg)) {
printf("%s: urndis_decap invalid msg len %u < %zu\n",
DEVNAME(sc),
letoh32(msg->rm_len),
sizeof(*msg));
-   return;
+   break;
}
if (letoh32(msg->rm_len) > len) {
printf("%s: urndis_decap invalid msg len %u > buffer "
@@ -874,7 +876,7 @@ urndis_decap(struct urndis_softc *sc, struct urn

net/bpf: +23year old gross hack within ifdef _KERNEL.

2018-07-23 Thread Artturi Alm
On Wed, Jul 18, 2018 at 07:57:57AM +0300, Artturi Alm wrote:
> Hi,
> 
> rather random "i want to clear those XXXs"-moment with morning coffee,
> did seem like this was screaming for __packed from sys/cdefs.h,
> and less MD in sys/net/, if nothing else.
> 
> With a bit of googling i also ran into a different solution,
> which is as ugly as what i'm replacing, imo.., that is:
> #define   SIZEOF_BPF_HDR (sizeof(struct bpf_hdr) <= 20 ? 18 :
> sizeof(struct bpf_hdr)) /* from some apple bpf.h */
> 
> compile-tested diff from was-current-before-hackathon-src-tree.
> 
> -Artturi
> 

now i suppose this doesn't work on some arch i can't test with, but
would anyone care to tell me which arch(s) and/or why not?

the diff i was thinking, without comment/define changes below.

-Artturi

diff --git sys/net/bpf.h sys/net/bpf.h
index 604bdcbab55..095ee283c03 100644
--- sys/net/bpf.h
+++ sys/net/bpf.h
@@ -140,7 +140,7 @@ struct bpf_hdr {
u_int32_t   bh_datalen; /* original length of packet */
u_int16_t   bh_hdrlen;  /* length of bpf header (this struct
   plus alignment padding) */
-};
+} __packed;
 /*
  * Because the structure above is not a multiple of 4 bytes, some compilers
  * will insist on inserting padding; hence, sizeof(struct bpf_hdr) won't work.
@@ -156,6 +156,7 @@ struct bpf_hdr {
 #else
 #define SIZEOF_BPF_HDR sizeof(struct bpf_hdr)
 #endif
+CTASSERT(sizeof(struct bpf_hdr) == 18); /* prove XXXs above !true w/packed */
 #endif
 
 /*




> 
> diff --git a/sys/net/bpf.c b/sys/net/bpf.c
> index a6bcf31d471..151a34e19f2 100644
> --- a/sys/net/bpf.c
> +++ b/sys/net/bpf.c
> @@ -1600,11 +1600,12 @@ bpfsattach(caddr_t *bpfp, const char *name, u_int 
> dlt, u_int hdrlen)
>  
>   /*
>* Compute the length of the bpf header.  This is not necessarily
> -  * equal to SIZEOF_BPF_HDR because we want to insert spacing such
> -  * that the network layer header begins on a longword boundary (for
> -  * performance reasons and to alleviate alignment restrictions).
> +  * equal to sizeof(struct bpf_hdr), because we want to insert spacing
> +  * such that the network layer header begins on a longword boundary
> +  * (for performance reasons and to alleviate alignment restrictions).
>*/
> - bp->bif_hdrlen = BPF_WORDALIGN(hdrlen + SIZEOF_BPF_HDR) - hdrlen;
> + bp->bif_hdrlen =
> + BPF_WORDALIGN(hdrlen + sizeof(struct bpf_hdr)) - hdrlen;
>  
>   return (bp);
>  }
> diff --git a/sys/net/bpf.h b/sys/net/bpf.h
> index 604bdcbab55..80444bc17ad 100644
> --- a/sys/net/bpf.h
> +++ b/sys/net/bpf.h
> @@ -140,22 +140,14 @@ struct bpf_hdr {
>   u_int32_t   bh_datalen; /* original length of packet */
>   u_int16_t   bh_hdrlen;  /* length of bpf header (this struct
>  plus alignment padding) */
> -};
> +} __packed;
> +#ifdef _KERNEL
>  /*
>   * Because the structure above is not a multiple of 4 bytes, some compilers
>   * will insist on inserting padding; hence, sizeof(struct bpf_hdr) won't 
> work.
>   * Only the kernel needs to know about it; applications use bh_hdrlen.
> - * XXX To save a few bytes on 32-bit machines, we avoid end-of-struct
> - * XXX padding by using the size of the header data elements.  This is
> - * XXX fail-safe: on new machines, we just use the 'safe' sizeof.
>   */
> -#ifdef _KERNEL
> -#if defined(__arm__) || defined(__i386__) || defined(__mips__) || \
> -defined(__sparc64__)
> -#define SIZEOF_BPF_HDR 18
> -#else
> -#define SIZEOF_BPF_HDR sizeof(struct bpf_hdr)
> -#endif
> +CTASSERT(sizeof(struct bpf_hdr) == 18);
>  #endif
>  
>  /*



net/bpf: SIZEOF_BPF_HDR vs __packed+CTASSERT; removing 3xXXX.

2018-07-17 Thread Artturi Alm
Hi,

rather random "i want to clear those XXXs"-moment with morning coffee,
did seem like this was screaming for __packed from sys/cdefs.h,
and less MD in sys/net/, if nothing else.

With a bit of googling i also ran into a different solution,
which is as ugly as what i'm replacing, imo.., that is:
#define SIZEOF_BPF_HDR (sizeof(struct bpf_hdr) <= 20 ? 18 :
sizeof(struct bpf_hdr)) /* from some apple bpf.h */

compile-tested diff from was-current-before-hackathon-src-tree.

-Artturi


diff --git a/sys/net/bpf.c b/sys/net/bpf.c
index a6bcf31d471..151a34e19f2 100644
--- a/sys/net/bpf.c
+++ b/sys/net/bpf.c
@@ -1600,11 +1600,12 @@ bpfsattach(caddr_t *bpfp, const char *name, u_int dlt, 
u_int hdrlen)
 
/*
 * Compute the length of the bpf header.  This is not necessarily
-* equal to SIZEOF_BPF_HDR because we want to insert spacing such
-* that the network layer header begins on a longword boundary (for
-* performance reasons and to alleviate alignment restrictions).
+* equal to sizeof(struct bpf_hdr), because we want to insert spacing
+* such that the network layer header begins on a longword boundary
+* (for performance reasons and to alleviate alignment restrictions).
 */
-   bp->bif_hdrlen = BPF_WORDALIGN(hdrlen + SIZEOF_BPF_HDR) - hdrlen;
+   bp->bif_hdrlen =
+   BPF_WORDALIGN(hdrlen + sizeof(struct bpf_hdr)) - hdrlen;
 
return (bp);
 }
diff --git a/sys/net/bpf.h b/sys/net/bpf.h
index 604bdcbab55..80444bc17ad 100644
--- a/sys/net/bpf.h
+++ b/sys/net/bpf.h
@@ -140,22 +140,14 @@ struct bpf_hdr {
u_int32_t   bh_datalen; /* original length of packet */
u_int16_t   bh_hdrlen;  /* length of bpf header (this struct
   plus alignment padding) */
-};
+} __packed;
+#ifdef _KERNEL
 /*
  * Because the structure above is not a multiple of 4 bytes, some compilers
  * will insist on inserting padding; hence, sizeof(struct bpf_hdr) won't work.
  * Only the kernel needs to know about it; applications use bh_hdrlen.
- * XXX To save a few bytes on 32-bit machines, we avoid end-of-struct
- * XXX padding by using the size of the header data elements.  This is
- * XXX fail-safe: on new machines, we just use the 'safe' sizeof.
  */
-#ifdef _KERNEL
-#if defined(__arm__) || defined(__i386__) || defined(__mips__) || \
-defined(__sparc64__)
-#define SIZEOF_BPF_HDR 18
-#else
-#define SIZEOF_BPF_HDR sizeof(struct bpf_hdr)
-#endif
+CTASSERT(sizeof(struct bpf_hdr) == 18);
 #endif
 
 /*



Re: [patch] urtwn(4) hostap mode support for 8188eu

2018-06-21 Thread Artturi Alm
On Wed, Jul 01, 2015 at 09:47:15PM +0300, Mikhail wrote:
> Hello, inlined patch adds support for hostap mode for 8188eu chip.
> 

Hi,

do you have newer version of this? I might have use for this..:)

-Artturi

> One known issue is documented in urtwn(4), I would like to know if
> people with other hw will see it too, or if it's my local issue.
> 
> If you want to help, please test the patch and in case of problems
> provide as much as you can from this list:
> 
>  - commands with which you started the AP
>  - dmesg | grep urtwn
>  - ifconfig 
>  - tcpdump -i urtwn0 -y IEEE802_11 -w test.pcap (command must be run on
>the AP before problem occurs; I assume mailing the file to maillist
>isn't appropriate, so mail it to me directly)
>  - if you can - sniff from the client (or, ideally, from third PC) too,
>since previous command won't give radiotap headers and won't show
>beacons.
> 
> Patch has been tested with tl-wn725n, and mac mini as a client, running
> 802.11g and wpa2, speed is about 3-4 mbits in presence of ~20 ssids.
> Also, usual client mode with 8188eu chip is confirmed to work as before.
> 
> Since the patch touches some bits in STA mode initialization, it would
> be helpful, if people with non-8188eu chip test it too in usual client
> mode.
> 
> Any feedback and advice are appreciated.
> 
> diff --git share/man/man4/urtwn.4 share/man/man4/urtwn.4
> index d2007a7..00928d4 100644
> --- share/man/man4/urtwn.4
> +++ share/man/man4/urtwn.4
> @@ -58,6 +58,8 @@ capture packets from networks which it wouldn't normally 
> have access to,
>  or to scan for access points.
>  .El
>  .Pp
> +The RTL8188EUS chip can also operate in Host AP mode.
> +.Pp
>  The
>  .Nm
>  driver can be configured to use
> @@ -180,3 +182,8 @@ adapters.
>  Additional work is required in
>  .Xr ieee80211 9
>  before those features can be supported.
> +.Pp
> +Beacon transmission, when operating in Host AP mode, is not started
> +immidiatelly, but with timeout of around 40 seconds, it means that if you
> +associate within this time frame, your client card will eventually disconnect
> +you, assuming that you've left range of AP.
> diff --git sys/dev/usb/if_urtwn.c sys/dev/usb/if_urtwn.c
> index db47398..18a4200 100644
> --- sys/dev/usb/if_urtwn.c
> +++ sys/dev/usb/if_urtwn.c
> @@ -216,6 +216,7 @@ void  urtwn_rxeof(struct usbd_xfer *, void *,
>   usbd_status);
>  void urtwn_txeof(struct usbd_xfer *, void *,
>   usbd_status);
> +int  urtwn_txbcn(struct urtwn_softc *, struct ieee80211_node *);
>  int  urtwn_tx(struct urtwn_softc *, struct mbuf *,
>   struct ieee80211_node *);
>  void urtwn_start(struct ifnet *);
> @@ -347,6 +348,11 @@ urtwn_attach(struct device *parent, struct device *self, 
> void *aux)
>   IEEE80211_C_WEP |   /* WEP. */
>   IEEE80211_C_RSN;/* WPA/RSN. */
>  
> +#ifndef IEEE80211_STA_ONLY
> + if (sc->chip & URTWN_CHIP_88E)
> + ic->ic_caps |= IEEE80211_C_HOSTAP; /* HostAp mode supported */
> +#endif
> +
>  #ifndef IEEE80211_NO_HT
>   /* Set HT capabilities. */
>   ic->ic_htcaps =
> @@ -1319,7 +1325,7 @@ urtwn_newstate_cb(struct urtwn_softc *sc, void *arg)
>   struct ieee80211_node *ni;
>   enum ieee80211_state ostate;
>   uint32_t reg;
> - int s;
> + int s, error;
>  
>   s = splnet();
>   ostate = ic->ic_state;
> @@ -1422,22 +1428,62 @@ urtwn_newstate_cb(struct urtwn_softc *sc, void *arg)
>   }
>   ni = ic->ic_bss;
>  
> - /* Set media status to 'Associated'. */
> - reg = urtwn_read_4(sc, R92C_CR);
> - reg = RW(reg, R92C_CR_NETTYPE, R92C_CR_NETTYPE_INFRA);
> - urtwn_write_4(sc, R92C_CR, reg);
> + if (ic->ic_opmode == IEEE80211_M_STA) {
> + /* Set BSSID. */
> + urtwn_write_4(sc, R92C_BSSID + 0, 
> LE_READ_4(&ni->ni_bssid[0]));
> + urtwn_write_4(sc, R92C_BSSID + 4, 
> LE_READ_2(&ni->ni_bssid[4]));
>  
> - /* Set BSSID. */
> - urtwn_write_4(sc, R92C_BSSID + 0, LE_READ_4(&ni->ni_bssid[0]));
> - urtwn_write_4(sc, R92C_BSSID + 4, LE_READ_2(&ni->ni_bssid[4]));
> + if (ic->ic_curmode == IEEE80211_MODE_11B)
> + urtwn_write_1(sc, R92C_INIRTS_RATE_SEL, 0);
> + else/* 802.11b/g */
> + urtwn_write_1(sc, R92C_INIRTS_RATE_SEL, 3);
>  
> - if (ic->ic_curmode == IEEE80211_MODE_11B)
> - urtwn_write_1(sc, R92C_INIRTS_RATE_SEL, 0);
> - else/* 802.11b/g */
> - urtwn_write_1(sc, R92C_INIRTS_RATE_SEL, 3);
> + /* Enable Rx of data frames. */
> + urtwn_write_2(sc, R92C_RXFLTMAP2, 0x);
>  
> - /* Enable Rx of data frames. */
> - urtwn_write_2(sc, 

Re: ofw/fdt: obstacle on pretty dev/fdt/X_fdt.c attachment glue for the common (ie. i2c) drivers

2018-05-04 Thread Artturi Alm
On Fri, May 04, 2018 at 08:08:15PM +0200, Mark Kettenis wrote:
> > Date: Fri, 4 May 2018 20:56:07 +0300
> > From: Artturi Alm 
> > 
> > Hi,
> > 
> > currently, I don't see how it is possible to write generic
> > i2c-parent-controller-independent attachment glue in dev/fdt/,
> > ie. for drivers in dev/i2c. The usual way how they are written with
> > doesn't work as the devices in dev/i2c attach "at i2c" already.
> > 
> > visa@ just commited something in the direction i wish you would
> > continue, and that would be adding "needs-flag" to
> > 
> > dev/ofw/files.ofw:
> > 3: file   dev/ofw/fdt.c   fdt
> > ->
> > 3: file   dev/ofw/fdt.c   fdt needs-flag
> > 
> > which would allow writing cleaner glue with less pollution, imo..
> > 
> > I have some examples, if this isn't totally out of the question,
> > of which i think most wanted might be for maxrtc(4), as many boards
> > come with lacking RTC/battery and maxrtc(4) is a cheap&easy fix for it.
> 
> You completely fail to explain what the problem is.  There are several
> i2c drivers for RTC chips in the tree that work on armv7 and/or arm64
> and they are completely fdt-agnostic.  See for example
> dev/i2c/isl1208.c.

Oh, I have totally missed isl1208.c and the way it does _match(), just
what i was missing, this is great. Thank you, and sorry for the noise:)

-Artturi




ofw/fdt: obstacle on pretty dev/fdt/X_fdt.c attachment glue for the common (ie. i2c) drivers

2018-05-04 Thread Artturi Alm
Hi,


currently, I don't see how it is possible to write generic
i2c-parent-controller-independent attachment glue in dev/fdt/,
ie. for drivers in dev/i2c. The usual way how they are written with
doesn't work as the devices in dev/i2c attach "at i2c" already.

visa@ just commited something in the direction i wish you would
continue, and that would be adding "needs-flag" to

dev/ofw/files.ofw:
3: file   dev/ofw/fdt.c   fdt
->
3: file   dev/ofw/fdt.c   fdt needs-flag

which would allow writing cleaner glue with less pollution, imo..

I have some examples, if this isn't totally out of the question,
of which i think most wanted might be for maxrtc(4), as many boards
come with lacking RTC/battery and maxrtc(4) is a cheap&easy fix for it.

-Artturi



tech@openbsd.org

2018-04-26 Thread Artturi Alm
On Thu, Apr 26, 2018 at 02:05:44PM +0200, Mark Kettenis wrote:
> > Date: Thu, 26 Apr 2018 10:35:45 +0300
> > From: Artturi Alm 
> > 
> > Hi,
> > 
> > wrote simple gpio indicator sensor driver, and spotted this.
> > 
> > decided to keep the /* XXX */ for tech@, so this should be 'safe'
> > for anyone not using gpioctl(8) no matter what :)
> > 
> > i don't really see any risk, only w/o one might need to do this
> > w/ext resistors.
> > 
> > comments?
> 
> Can you please actually describe what the intention of your patches is
> in normal English, preferably with proper punctation and without silly
> abbreviations.  One of the reason your diffs get ignored is because it
> simply takes too much effort to figure out what you actually mean.
> 
> Thanks,
> 
> Mark
> 

Ok. I was actually thinking i should move back to posting only arm@/bugs@,
to save some wasted time of tech@-readers. I've learned to live with
ignorance by now, so it's np., and i do usually carry my own/learn
the answers to questions i don't get answers for :)

Intent is to add support for GPIO_PIN_PULLUP and GPIO_PIN_PULLDOWN in
the gpio framework for sxipio(4), with necessary bits in ofw_gpio.h,
so following this minimal version in other gpio(4)-parents can be done
without ugly hacks.

diff below does miss the obvious dev/files.gpio and arch/x/conf/GENERIC
pieces to keep it shorter, i did also fix the actual part of diff that
was in the first mail to be only +++, for simplicity/easy review :)
the example use case is early in gpioind_attach()/gpioctl pin set with
pu arg.

-Artturi


relevant /etc/rc.securelevel lines:

# Pine64 PI-2-bus pins 15,35,37,38,40 below order in order of attach
gpioctl gpio2 12 set in input_pin0
gpioctl gpio2 attach gpioind 9 1
gpioctl gpio2 16 set in pu input_pin1
gpioctl gpio2 attach gpioind 10 1 64
gpioctl gpio2 attach gpioind 11 1 128


---8<--
clearing /tmp
gpiosht0 at gpio2: DATA[7] pull-up SCK[8] pull-up
pin 12: caps: in out pu pd, flags: -> in
gpioind0 at gpio2: INPUT[9]
pin 16: caps: in out pu pd, flags: -> in pu
gpioind1 at gpio2: INPUT[10] pull-up
gpioind2 at gpio2: INPUT[11] pull-down
kern.securelevel: 0 -> 1
creating runtime link editor directory cache.
preserving editor files.
starting network daemons: sshd smtpd sndiod.
starting package daemons: zabbix_agentd.
starting local daemons: cron.
Thu Mar 15 10:22:06 EET 2018

OpenBSD/arm64 (a64pine.local.domain) (console)

login: aalm
Password:
Last login: Thu Mar 15 10:14:13 on console
OpenBSD 6.3-current (GENERIC.MP) #14: Thu Mar 15 10:01:33 EET 2018

Welcome to OpenBSD: The proactively secure Unix-like operating system.

Please use the sendbug(1) utility to report bugs in the system.
Before reporting a bug, please try to reproduce it with the latest
version of the code.  With bug reports, please try to ensure that
enough information to reproduce the problem is enclosed, and if a
known fix for it exists, include that as well.

You have new mail.
aalm@a64pine:~ $ sysctl hw.sensors
hw.sensors.axppmic0.temp0=38.62 degC
hw.sensors.axppmic0.indicator0=On (ACIN), OK
hw.sensors.axppmic0.indicator1=Off (VBUS)
hw.sensors.gpiosht0.temp0=24.98 degC
hw.sensors.gpiosht0.humidity0=15.00%
hw.sensors.gpioind0.indicator0=Off
hw.sensors.gpioind1.indicator0=On
hw.sensors.gpioind2.indicator0=Off
aalm@a64pine:~ $ dwxe_watchdog
aalm@a64pine:~ $ doas gpioctl gpio2 9
pin 9: state 0
aalm@a64pine:~ $ doas gpioctl gpio2 10
pin 10: state 1
aalm@a64pine:~ $ doas gpioctl gpio2 11 
pin 11: state 0
aalm@a64pine:~ $ doas gpioctl gpio2 input_pin0
pin input_pin0: state 0
aalm@a64pine:~ $ doas gpioctl gpio2 input_pin1 
pin input_pin1: state 1
---8<--


diff --git sys/dev/fdt/sxipio.c sys/dev/fdt/sxipio.c
index fe231d6bfd7..14f9b51c47b 100644
--- sys/dev/fdt/sxipio.c
+++ sys/dev/fdt/sxipio.c
@@ -356,6 +356,10 @@ sxipio_config_pin(void *cookie, uint32_t *cells, int 
config)
mux = (config & GPIO_CONFIG_OUTPUT) ? 1 : 0;
off = (pin & 0x7) << 2;
SXICMS4(sc, SXIPIO_CFG(port, pin), 0x7 << off, mux << off);
+   if (config & GPIO_CONFIG_PULLUP)
+   SXICMS4(sc, SXIPIO_PUL(port, pin), 0x3 << off, 1 << off);
+   else if (config & GPIO_CONFIG_PULLDOWN)
+   SXICMS4(sc, SXIPIO_PUL(port, pin), 0x3 << off, 2 << off);
 }
 
 int
@@ -446,11 +450,23 @@ sxipio_pin_ctl(void *cookie, int pin, int flags)
 {
struct sxipio_gpio *gpio = cookie;
uint32_t cells[3];
+   int config;
 
cells[0] = gpio->port;
cells[1] = pin;
cells[2] = 0;
 
+   if (ISSET(flags, (GPIO_PIN_PULLUP | GPIO_PIN_PULLDOWN))) {
+   config = ISSET(flags, GPIO_PIN_OUTPUT) ?
+   GPIO_CONFIG_OUTPUT : 0;
+   if (ISSET(flags, GPIO_PIN_P

tech@openbsd.org

2018-04-26 Thread Artturi Alm
Hi,

wrote simple gpio indicator sensor driver, and spotted this.

decided to keep the /* XXX */ for tech@, so this should be 'safe'
for anyone not using gpioctl(8) no matter what :)

i don't really see any risk, only w/o one might need to do this
w/ext resistors.

comments?

-Artturi


diff --git sys/dev/fdt/sxipio.c sys/dev/fdt/sxipio.c
index fe231d6bfd7..46f1212dee9 100644
--- sys/dev/fdt/sxipio.c
+++ sys/dev/fdt/sxipio.c
@@ -356,6 +356,11 @@ sxipio_config_pin(void *cookie, uint32_t *cells, int 
config)
mux = (config & GPIO_CONFIG_OUTPUT) ? 1 : 0;
off = (pin & 0x7) << 2;
SXICMS4(sc, SXIPIO_CFG(port, pin), 0x7 << off, mux << off);
+   if (config & GPIO_CONFIG_PULLUP)
+   SXICMS4(sc, SXIPIO_PUL(port, pin), 0x3 << off, 1 << off);
+   else if (config & GPIO_CONFIG_PULLDOWN)
+   SXICMS4(sc, SXIPIO_PUL(port, pin), 0x3 << off, 2 << off);
+   /* XXX should else _PUL 0 << off expl. here? */
 }
 
 int
@@ -446,15 +451,18 @@ sxipio_pin_ctl(void *cookie, int pin, int flags)
 {
struct sxipio_gpio *gpio = cookie;
uint32_t cells[3];
+   int config;
 
cells[0] = gpio->port;
cells[1] = pin;
cells[2] = 0;
 
-   if (ISSET(flags, GPIO_PIN_OUTPUT))
-   sxipio_config_pin(gpio->sc, cells, GPIO_CONFIG_OUTPUT);
-   else
-   sxipio_config_pin(gpio->sc, cells, 0);
+   config = ISSET(flags, GPIO_PIN_OUTPUT) ? GPIO_CONFIG_OUTPUT : 0;
+   if (ISSET(flags, GPIO_PIN_PULLUP))
+   config |= GPIO_CONFIG_PULLDOWN;
+   else if (ISSET(flags, GPIO_PIN_PULLDOWN))
+   config |= GPIO_CONFIG_PULLDOWN;
+   sxipio_config_pin(gpio->sc, cells, config);
 }
 
 void
@@ -503,7 +511,8 @@ sxipio_attach_gpio(struct device *parent)
state = (reg >> pin) & 1;
 
sc->sc_gpio_pins[port][pin].pin_caps =
-   GPIO_PIN_INPUT | GPIO_PIN_OUTPUT;
+   GPIO_PIN_INPUT | GPIO_PIN_OUTPUT |
+   GPIO_PIN_PULLUP | GPIO_PIN_PULLDOWN;
sc->sc_gpio_pins[port][pin].pin_flags = flags;
sc->sc_gpio_pins[port][pin].pin_state = state;
sc->sc_gpio_pins[port][pin].pin_num = pin;
diff --git sys/dev/ofw/ofw_gpio.h sys/dev/ofw/ofw_gpio.h
index 52b2fe08453..0917ace3b67 100644
--- sys/dev/ofw/ofw_gpio.h
+++ sys/dev/ofw/ofw_gpio.h
@@ -37,6 +37,8 @@ void  gpio_controller_register(struct gpio_controller *);
 
 #define GPIO_CONFIG_INPUT  0x
 #define GPIO_CONFIG_OUTPUT 0x0001
+#define GPIO_CONFIG_PULLUP 0x0002
+#define GPIO_CONFIG_PULLDOWN   0x0004
 void   gpio_controller_config_pin(uint32_t *, int);
 
 intgpio_controller_get_pin(uint32_t *);



arm64: GPIO "pin bus" drivers

2018-04-23 Thread Artturi Alm
Hi,

pine64 still being my only arm64-sbc, i won't bother w/
gpio*   at rkgpio?
etc., but i would like to have these enabled for arm64,
as atleast pine64 is equipped w/plenty of headers/pins brought out, and
gpio*   at sxipio?
is there already:)


-Artturi


diff --git sys/arch/arm64/conf/GENERIC sys/arch/arm64/conf/GENERIC
index c5c86db19d6..3990b7122ae 100644
--- sys/arch/arm64/conf/GENERIC
+++ sys/arch/arm64/conf/GENERIC
@@ -288,6 +288,12 @@ uk*at scsibus?
 # I2C devices
 rkpmic*at iic? # RK808 PMIC
 
+# GPIO "pin bus" drivers
+gpioiic*   at gpio?# I2C bus bit-banging
+iic*   at gpioiic?
+gpioow*at gpio?# 1-Wire bus bit-banging
+onewire*   at gpioow?
+
 # 1-Wire devices
 option ONEWIREVERBOSE
 owid*  at onewire? # ID



gpioow: gpio_pin_unmap order around config_detach

2018-04-14 Thread Artturi Alm
Hi,

i'm not suggesting the current order is easy to hit problems with,
but i think diff below would make sense anyway, so the 'owchild'
doesn't get even a remote chance in theory to endure any gpio failures?

-Artturi


diff --git sys/dev/gpio/gpioow.c sys/dev/gpio/gpioow.c
index 64d79ab0cb8..d37dcc60762 100644
--- sys/dev/gpio/gpioow.c
+++ sys/dev/gpio/gpioow.c
@@ -161,11 +161,11 @@ gpioow_detach(struct device *self, int flags)
struct gpioow_softc *sc = (struct gpioow_softc *)self;
int rv = 0;
 
-   gpio_pin_unmap(sc->sc_gpio, &sc->sc_map);
-
if (sc->sc_ow_dev != NULL)
rv = config_detach(sc->sc_ow_dev, flags);
 
+   gpio_pin_unmap(sc->sc_gpio, &sc->sc_map);
+
return (rv);
 }
 



Re: subr_autoconf: allow _attach to fail? w/no void2int churn option

2018-04-11 Thread Artturi Alm
On Tue, Apr 10, 2018 at 02:40:29PM -0600, Theo de Raadt wrote:
> >On Mon, Apr 09, 2018 at 11:11:22AM -0600, Theo de Raadt wrote:
> >> I think this approach is wrong, insane, and fragile.  DVF_ACTIVE
> >> doesn't work precisely that way.
> >
> >Yes, it's a hack, but i don't see it as fragile, nor insane,
> >and i agree something better is great, but it does work exactly
> >as i wanted:
> 
> for 1 driver.

i offered a horse. if it wasn't good enough, why bother with more work;
as i don't see how it would make the horse any better at this point:)

-Artturi



Re: subr_autoconf: allow _attach to fail? w/no void2int churn option

2018-04-10 Thread Artturi Alm
On Mon, Apr 09, 2018 at 11:11:22AM -0600, Theo de Raadt wrote:
> I think this approach is wrong, insane, and fragile.  DVF_ACTIVE
> doesn't work precisely that way.

Yes, it's a hack, but i don't see it as fragile, nor insane,
and i agree something better is great, but it does work exactly
as i wanted:

# gpioctl gpio2 attach gpioow 2 1
gpioow0 at gpio2: DATA[2]
onewire0 at gpioow0
# gpioctl gpio2 attach gpioow 4 5
gpioow1 at gpio2: invalid pin mask
gpioow1 detached
# gpioctl gpio2 attach gpioow 4 1
gpioow1 at gpio2: DATA[4]
onewire1 at gpioow1
# gpioctl gpio2 attach gpioow 3 2
gpioow2 at gpio2: can't map pins
gpioow2 detached
# gpioctl gpio2 attach gpioow 3 1
gpioow2 at gpio2: DATA[3]
onewire2 at gpioow2
# gpioctl gpio2 attach gpioow 2 1
gpioow3 at gpio2: can't map pins
gpioow3 detached

^ is with the DVF_ACTIVE-hack,
which does work because at that point it is 'local' to the config_attach(),
and if it does fail it(dv_flags) doesn't exist to cause issues later,
as nothing changes for those who don't call config_defer_failure(),
they will get their DVF_ACTIVE just like before.

my v2.diff below, in case you want to reconsider something like this while
waiting for the whole-tree work to appear:)

-Artturi


diff --git share/man/man9/config_defer.9 share/man/man9/config_defer.9
index ef45867188b..280501a538a 100644
--- share/man/man9/config_defer.9
+++ share/man/man9/config_defer.9
@@ -33,6 +33,7 @@
 .Os
 .Sh NAME
 .Nm config_defer ,
+.Nm config_defer_failure ,
 .Nm config_mountroot
 .Nd deferred device configuration
 .Sh SYNOPSIS
@@ -41,6 +42,8 @@
 .Ft "void"
 .Fn config_defer "struct device *dev" "void (*func)(struct device *)"
 .Ft "void"
+.Fn config_defer_failure "struct device *dev"
+.Ft "void"
 .Fn config_mountroot "struct device *dev" "void (*func)(struct device *)"
 .Sh DESCRIPTION
 The
@@ -53,6 +56,12 @@ is called with the argument
 .Fa dev .
 .Pp
 The
+.Fn config_defer_failure
+function is called by the device to mark its configuration as having
+failed, so it can be detached by
+.Fn config_attach .
+.Pp
+The
 .Fn config_mountroot
 function is called by a device driver to defer the remainder of its
 configuration until after the root file system is mounted.
@@ -60,3 +69,5 @@ At this point, the function
 .Fa func
 is called with the argument
 .Fa dev .
+.Sh SEE ALSO
+.Xr config_attach 9
diff --git sys/dev/gpio/gpioow.c sys/dev/gpio/gpioow.c
index 64d79ab0cb8..912537b7de7 100644
--- sys/dev/gpio/gpioow.c
+++ sys/dev/gpio/gpioow.c
@@ -101,7 +101,7 @@ gpioow_attach(struct device *parent, struct device *self, 
void *aux)
/* Check that we have enough pins */
if (gpio_npins(ga->ga_mask) != GPIOOW_NPINS) {
printf(": invalid pin mask\n");
-   return;
+   goto fail_nomap;
}
 
/* Map pins */
@@ -110,7 +110,7 @@ gpioow_attach(struct device *parent, struct device *self, 
void *aux)
if (gpio_pin_map(sc->sc_gpio, ga->ga_offset, ga->ga_mask,
&sc->sc_map)) {
printf(": can't map pins\n");
-   return;
+   goto fail_nomap;
}
 
/* Configure data pin */
@@ -153,6 +153,8 @@ gpioow_attach(struct device *parent, struct device *self, 
void *aux)
 
 fail:
gpio_pin_unmap(sc->sc_gpio, &sc->sc_map);
+fail_nomap:
+   config_defer_failure(self);
 }
 
 int
diff --git sys/kern/subr_autoconf.c sys/kern/subr_autoconf.c
index 3fff153e8ad..e4ff9ee7536 100644
--- sys/kern/subr_autoconf.c
+++ sys/kern/subr_autoconf.c
@@ -409,6 +409,12 @@ config_attach(struct device *parent, void *match, void 
*aux, cfprint_t print)
if (--autoconf_attdet == 0)
wakeup(&autoconf_attdet);
mtx_leave(&autoconf_attdet_mtx);
+
+   /* Process deferred failure here by detaching. */
+   if (dev->dv_flags & DVF_FAILED) {
+   if (config_detach(dev, 0) == 0)
+   dev = NULL;
+   }
return (dev);
 }
 
@@ -678,6 +684,18 @@ config_defer(struct device *dev, void (*func)(struct 
device *))
config_pending_incr();
 }
 
+/*
+ * Defer the detachment of the specified device with failure
+ * until the end of its own configuration, see config_attach().
+ * XXX "void2int ca_attach()"-churn workaround
+ */
+void
+config_defer_failure(struct device *dev)
+{
+
+   dev->dv_flags |= DVF_FAILED;
+}
+
 /*
  * Defer the configuration of the specified device until after
  * root file system is mounted.
diff --git sys/sys/device.h sys/sys/device.h
index 00a1f6ad2a6..c1d133594ff 100644
--- sys/sys/device.h
+++ sys/sys/device.h
@@ -82,6 +82,7 @@ struct device {
 
 /* dv_flags */
 #defineDVF_ACTIVE  0x0001  /* device is activated */
+#defineDVF_FAILED  0x0002  /* device failed to attach */
 
 TAILQ_HEAD(devicelist, device);
 
@@ -185,6 +186,7 @@ int config_activate_children(struct device *, int);
 struct device *config_make_softc(struct device *parent,
 struct cfdata *cf);
 void config_defer(struct de

Re: Multiple RTCs

2018-04-10 Thread Artturi Alm
On Sat, Apr 07, 2018 at 08:39:43PM +0200, Mark Kettenis wrote:
> I have an RK3399 system that has two RTCs.  One of those is the RTC
> integrated on the RK808 PMIC that is a companion chip to the RK3399.
> The second one is an ISL1208 I2C chip.  Only the ISL1208 is battery
> powered, so obviously we want to use that one.  But rkpmic(4) attaches
> after islrtc(4) on this board and therefore it wins.  The diff below
> makes sure the RTC of the RK808 PMIC is only enabled if no other RTC
> installed itself.
> 

Off-topic, but related enough i hope.
instead of fixing up RTCVDD(lack of battery) on all my sunxi boards,
i'm going to rather add cheap&separate I2C RTCs for each.

What do you think about kern.timecounter.{choice,hardware}-type solution?

i'm kind of covered, either way, as maxrtc(4) does this in maxrtc_attach():
126 /* register our time handlers */
127 if (todr_handle != NULL) {  
128 printf("%s: overwriting existing rtc handler\n",
129 sc->sc_dev.dv_xname);
130 }
131 /* XXX just overwrite existing rtc handler? */
132 todr_handle = &sc->sc_todr;

-Artturi

> ok?
> 
> 
> Index: dev/fdt/rkpmic.c
> ===
> RCS file: /cvs/src/sys/dev/fdt/rkpmic.c,v
> retrieving revision 1.4
> diff -u -p -r1.4 rkpmic.c
> --- dev/fdt/rkpmic.c  25 Feb 2018 20:43:33 -  1.4
> +++ dev/fdt/rkpmic.c  7 Apr 2018 18:31:41 -
> @@ -127,7 +127,8 @@ rkpmic_attach(struct device *parent, str
>   sc->sc_todr.cookie = sc;
>   sc->sc_todr.todr_gettime = rkpmic_gettime;
>   sc->sc_todr.todr_settime = rkpmic_settime;
> - todr_handle = &sc->sc_todr;
> + if (todr_handle == NULL)
> + todr_handle = &sc->sc_todr;
>  
>   if (OF_is_compatible(node, "rockchip,rk805")) {
>   chip = "RK805";
> 



subr_autoconf: allow _attach to fail? w/no void2int churn option

2018-04-09 Thread Artturi Alm
Hi,

could we allow config_attach() to 'fail' without leaving dead device behind?
ie. with gpioow(4) it's easy to make a load of these while testing stuff,
which does lead to inconsistent unit numbering unless you manually detach
the broken ones before attaching another..

for devices which are found during autoconf, i guess DETACH_QUIET would
be wanted to keep dmesg pretty, as the error messages printed from any
ca->ca_attach() should be enough, and would mean no visible change for
drivers failing out with this:)

for smaller diff i chose to use the DVF_ACTIVE, while i'd actually prefer
adding "DVF_FAILED" or something. untested morning-coffee-qual.diff below.

comments?

-Artturi


diff --git sys/dev/gpio/gpioow.c sys/dev/gpio/gpioow.c
index 64d79ab0cb8..912537b7de7 100644
--- sys/dev/gpio/gpioow.c
+++ sys/dev/gpio/gpioow.c
@@ -101,7 +101,7 @@ gpioow_attach(struct device *parent, struct device *self, 
void *aux)
/* Check that we have enough pins */
if (gpio_npins(ga->ga_mask) != GPIOOW_NPINS) {
printf(": invalid pin mask\n");
-   return;
+   goto fail_nomap;
}
 
/* Map pins */
@@ -110,7 +110,7 @@ gpioow_attach(struct device *parent, struct device *self, 
void *aux)
if (gpio_pin_map(sc->sc_gpio, ga->ga_offset, ga->ga_mask,
&sc->sc_map)) {
printf(": can't map pins\n");
-   return;
+   goto fail_nomap;
}
 
/* Configure data pin */
@@ -153,6 +153,8 @@ gpioow_attach(struct device *parent, struct device *self, 
void *aux)
 
 fail:
gpio_pin_unmap(sc->sc_gpio, &sc->sc_map);
+fail_nomap:
+   config_defer_failure(self);
 }
 
 int
diff --git sys/kern/subr_autoconf.c sys/kern/subr_autoconf.c
index 3fff153e8ad..9a797712510 100644
--- sys/kern/subr_autoconf.c
+++ sys/kern/subr_autoconf.c
@@ -409,6 +409,11 @@ config_attach(struct device *parent, void *match, void 
*aux, cfprint_t print)
if (--autoconf_attdet == 0)
wakeup(&autoconf_attdet);
mtx_leave(&autoconf_attdet_mtx);
+
+   if ((dev->dv_flags & DVF_ACTIVE) == 0) {
+   if (config_detach(dev, 0) == 0)
+   dev = NULL;
+   }
return (dev);
 }
 
@@ -678,6 +683,17 @@ config_defer(struct device *dev, void (*func)(struct 
device *))
config_pending_incr();
 }
 
+/*
+ * Defer the detachment of the specified device until the end
+ * of its own configuration.
+ */
+void
+config_defer_failure(struct device *dev)
+{
+
+   dev->dv_flags &= ~DVF_ACTIVE;
+}
+
 /*
  * Defer the configuration of the specified device until after
  * root file system is mounted.
diff --git sys/sys/device.h sys/sys/device.h
index 00a1f6ad2a6..3820cc6e0f5 100644
--- sys/sys/device.h
+++ sys/sys/device.h
@@ -185,6 +185,7 @@ int config_activate_children(struct device *, int);
 struct device *config_make_softc(struct device *parent,
 struct cfdata *cf);
 void config_defer(struct device *, void (*)(struct device *));
+void config_defer_failure(struct device *);
 void config_pending_incr(void);
 void config_pending_decr(void);
 void config_mountroot(struct device *, void (*)(struct device *));



com.4: -socppc

2018-03-28 Thread Artturi Alm
Hi,

socppc@attic was asking for this.

-Artturi


diff --git share/man/man4/com.4 share/man/man4/com.4
index 6301f04ae60..9c5f0d23230 100644
--- share/man/man4/com.4
+++ share/man/man4/com.4
@@ -91,10 +91,6 @@
 .Cd "com0 at ioc? base 0x00020178"
 .Cd "com1 at ioc? base 0x00020170"
 .Pp
-.Cd "# socppc"
-.Cd "com0 at obio? addr 0x04500 ivec 9"
-.Cd "com1 at obio? addr 0x04600 ivec 10"
-.Pp
 .Cd "# sparc64"
 .Cd "com* at asio?"
 .Cd "com* at ebus?"



fdt: OF_is_ncompatible

2018-03-19 Thread Artturi Alm
Hi,

i was looking at unifying something before "adding on" again, and
was thinking i would like to do something like in the example below:

const char *com_fdt_compat[] = {
"brcm,bcm2835-aux-uart",
"snps,dw-apb-uart",
#ifdef __armv7__
"ti,omap3-uart",
"ti,omap4-uart",
#endif
}

int
com_fdt_match(struct device *parent, void *match, void *aux)
{
int node = ((struct fdt_attach_args *)aux)->fa_node;

return OF_is_ncompatible(node, com_fdt_compat, nitems(com_fdt_compat));
}

similarly, while this is shorter:
if ((node = fdt_find_cons("brcm,bcm2835-aux-uart")) == NULL &&
(node = fdt_find_cons("snps,dw-apb-uart")) == NULL &&
(node = fdt_find_cons("ti,omap3-uart")) == NULL &&
(node = fdt_find_cons("ti,omap4-uart")) == NULL)
return;

i don't think this is much worse:
int i;

for (i = 0; i < nitems(com_fdt_compat); i++) {
node = fdt_find_cons(com_fdt_compat[i]);
if (node != NULL)
break;
}
if (node == NULL)
return;

atleast it would make adding new compatible possibly an
+   "one,liner",

any comments? or why nothing like this?
sry for noise, if i've asked about this before.:)

-Artturi


diff --git sys/dev/ofw/fdt.c sys/dev/ofw/fdt.c
index a45f1066e9e..ee911f61726 100644
--- sys/dev/ofw/fdt.c
+++ sys/dev/ofw/fdt.c
@@ -916,6 +916,18 @@ OF_is_compatible(int handle, const char *name)
return (fdt_is_compatible(node, name));
 }
 
+int
+OF_is_ncompatible(int handle, const char *name, int nelem)
+{
+   void *node = (char *)tree.header + handle;
+   int i;
+
+   for (i = 0; i < nelem; i++)
+   if (fdt_is_compatible(node, name++))
+   return 1;
+   return 0;
+}
+
 int
 OF_getindex(int handle, const char *entry, const char *prop)
 {
diff --git sys/dev/ofw/openfirm.h sys/dev/ofw/openfirm.h
index 45f8086d047..68ceeac8205 100644
--- sys/dev/ofw/openfirm.h
+++ sys/dev/ofw/openfirm.h
@@ -55,6 +55,7 @@ int OF_setprop(int, char *, const void *, int);
 int OF_nextprop(int, char *, void *);
 int OF_finddevice(char *name);
 int OF_is_compatible(int, const char *);
+int OF_is_ncompatible(int, const char *, int);
 int OF_instance_to_path(int ihandle, char *buf, int buflen);
 int OF_package_to_path(int phandle, char *buf, int buflen);
 int OF_call_method_1(char *method, int ihandle, int nargs, ...);



sensorsd: new token for timestamp

2018-03-17 Thread Artturi Alm
Hi,

honestly this is currently just for my lazyness:)
in doubt i did choose the one below i know i want, but was thinking
if maybe the timestamp should be set like this instead however to be more
useful to all:
limit->timestamp = sensor.tv.tv_sec ? sensor.tv.tv_sec : this_check;

-Artturi


diff --git usr.sbin/sensorsd/sensorsd.c usr.sbin/sensorsd/sensorsd.c
index 680bc8af9ad..93a2c3bf5de 100644
--- usr.sbin/sensorsd/sensorsd.c
+++ usr.sbin/sensorsd/sensorsd.c
@@ -57,6 +57,7 @@ struct limits_t {
char*command;   /* failure command */
time_t  astatus_changed;
time_t  ustatus_changed;
+   time_t  timestamp;  /* last value update */
enum sensor_status  astatus;/* last automatic status */
enum sensor_status  astatus2;
enum sensorsd_s_status  ustatus;/* last user-limit status */
@@ -368,6 +369,7 @@ check_sdlim(struct sdlim_t *sdlim, time_t this_check)
limit->astatus2 =
limit->astatus = newastatus;
limit->astatus_changed = this_check;
+   limit->timestamp = sensor.tv.tv_sec;
}
}
}
@@ -393,6 +395,7 @@ check_sdlim(struct sdlim_t *sdlim, time_t this_check)
limit->ustatus2 =
limit->ustatus = newustatus;
limit->ustatus_changed = this_check;
+   limit->timestamp = sensor.tv.tv_sec;
}
}
}
@@ -580,6 +583,10 @@ report_sdlim(struct sdlim_t *sdlim, time_t last_report)
s);
break;
}
+   case 'u':
+   r = snprintf(&buf[n], len - n, "%lld",
+   limit->timestamp);
+   break;
case '2':
r = snprintf(&buf[n], len - n, "%s",
print_sensor(limit->type,
diff --git usr.sbin/sensorsd/sensorsd.conf.5 usr.sbin/sensorsd/sensorsd.conf.5
index 84e4053abcc..9f350a831f4 100644
--- usr.sbin/sensorsd/sensorsd.conf.5
+++ usr.sbin/sensorsd/sensorsd.conf.5
@@ -110,6 +110,8 @@ The sensor status.
 The xname of the device the sensor sits on.
 .It %t
 The type of sensor.
+.It %u
+The timestamp of current value.
 .It %2
 The sensor's current value.
 .It %3



Re: onewire/owtemp: flags for no_detach+timestamp.

2018-03-17 Thread Artturi Alm
On Sun, Mar 18, 2018 at 02:13:14AM +0200, Artturi Alm wrote:
> On Fri, Mar 09, 2018 at 11:51:20AM +0200, Artturi Alm wrote:
> > On Wed, Mar 07, 2018 at 06:26:15AM +0200, Artturi Alm wrote:
> > > Hi,
> > > 
> > > i tested gpioow on beaglebone black a few days ago, and when i was lazy
> > > to fix the 'cables' my sensors were attached to, console was spammed
> > > over night by some of the sensors.
> > > i found the hotplug spam+disappearing sensors annoying.
> > > 
> > > if i read gpioctl(8) correctly, i should be able to pass these flags like
> > > "gpioctl gpio1 attach gpioow 16 0x01 [flags]" ?
> > > 
> > > yet untested diff below showing what i think i'm missing,
> > > and for which any input would be much appreciated by those familiar with
> > > gpioow(4)i/sensors frsmrwork, or anyone w/comments generally :)
> > > 
> > > -Artturi
> > > 
> > 
> > so this does lower the bar for owtemp(4) to be more easily usable/reliable
> > via sysctl(8) alone in some simple script or w/e(sensor will be there,
> > and w/timedelta one can decide whether to use the value or not).
> > 
> > besides the obvious copy-paste-bugs in the previous draft,
> > i missed how gpioow(4) didn't pass the flags to onewire(4) oba_flags.
> > 
> > diff below does work good enough for my use, and i don't care about the
> > inherent 5sec 'lag' on timedelta enough to make the diff any bigger.
> > 
> > rc.securelevel:
> > gpioctl gpio1 attach gpioow 16 1 12
> > 
> > root@av7bbb:~ # sysctl hw.sensors
> > hw.sensors.owtemp0.temp0=30.56 degC (sn 025f07aa)
> > hw.sensors.owtemp0.timedelta0=5.00 secs (LastUpdate)
> > hw.sensors.owtemp1.temp0=30.88 degC (sn 025ecdb5)
> > hw.sensors.owtemp1.timedelta0=5.00 secs (LastUpdate)
> > hw.sensors.owtemp2.temp0=30.50 degC (sn 025f13ad)
> > hw.sensors.owtemp2.timedelta0=5.00 secs (LastUpdate)
> > 
> > -Artturi
> > 
> 
> Hi,
> 
> admittedly my last diff was funny, and hardly worth of any comments:D
> 
> maybe this one would be more acceptable? no fake-sensors/lag involved,
> as sysctl(8) does make use of s->tv.tv_sec, if provided i found out.
> 
> -Artturi
> 
> 

forgot this from the last diff..:

diff --git sys/dev/gpio/gpioow.c sys/dev/gpio/gpioow.c
index 64d79ab0cb8..f7b7eb83e4b 100644
--- sys/dev/gpio/gpioow.c
+++ sys/dev/gpio/gpioow.c
@@ -147,6 +147,7 @@ gpioow_attach(struct device *parent, struct device *self, 
void *aux)
 
bzero(&oba, sizeof(oba));
oba.oba_bus = &sc->sc_ow_bus;
+   oba.oba_flags = ga->ga_flags;
sc->sc_ow_dev = config_found(self, &oba, onewirebus_print);
 
return;



Re: onewire/owtemp: flags for no_detach+timestamp.

2018-03-17 Thread Artturi Alm
On Fri, Mar 09, 2018 at 11:51:20AM +0200, Artturi Alm wrote:
> On Wed, Mar 07, 2018 at 06:26:15AM +0200, Artturi Alm wrote:
> > Hi,
> > 
> > i tested gpioow on beaglebone black a few days ago, and when i was lazy
> > to fix the 'cables' my sensors were attached to, console was spammed
> > over night by some of the sensors.
> > i found the hotplug spam+disappearing sensors annoying.
> > 
> > if i read gpioctl(8) correctly, i should be able to pass these flags like
> > "gpioctl gpio1 attach gpioow 16 0x01 [flags]" ?
> > 
> > yet untested diff below showing what i think i'm missing,
> > and for which any input would be much appreciated by those familiar with
> > gpioow(4)i/sensors frsmrwork, or anyone w/comments generally :)
> > 
> > -Artturi
> > 
> 
> so this does lower the bar for owtemp(4) to be more easily usable/reliable
> via sysctl(8) alone in some simple script or w/e(sensor will be there,
> and w/timedelta one can decide whether to use the value or not).
> 
> besides the obvious copy-paste-bugs in the previous draft,
> i missed how gpioow(4) didn't pass the flags to onewire(4) oba_flags.
> 
> diff below does work good enough for my use, and i don't care about the
> inherent 5sec 'lag' on timedelta enough to make the diff any bigger.
> 
> rc.securelevel:
> gpioctl gpio1 attach gpioow 16 1 12
> 
> root@av7bbb:~ # sysctl hw.sensors
> hw.sensors.owtemp0.temp0=30.56 degC (sn 025f07aa)
> hw.sensors.owtemp0.timedelta0=5.00 secs (LastUpdate)
> hw.sensors.owtemp1.temp0=30.88 degC (sn 025ecdb5)
> hw.sensors.owtemp1.timedelta0=5.00 secs (LastUpdate)
> hw.sensors.owtemp2.temp0=30.50 degC (sn 025f13ad)
> hw.sensors.owtemp2.timedelta0=5.00 secs (LastUpdate)
> 
> -Artturi
> 

Hi,

admittedly my last diff was funny, and hardly worth of any comments:D

maybe this one would be more acceptable? no fake-sensors/lag involved,
as sysctl(8) does make use of s->tv.tv_sec, if provided i found out.

-Artturi


diff --git sys/dev/onewire/onewire.c sys/dev/onewire/onewire.c
index 679bcd90e85..263f65ab674 100644
--- sys/dev/onewire/onewire.c
+++ sys/dev/onewire/onewire.c
@@ -434,8 +434,11 @@ onewire_scan(struct onewire_softc *sc)
 * scanning. This allows to find out later which devices
 * have been disappeared.
 */
-   TAILQ_FOREACH(d, &sc->sc_devs, d_list)
+   TAILQ_FOREACH(d, &sc->sc_devs, d_list) {
+   if (sc->sc_flags & ONEWIRE_NO_DETACH)
+   break;
d->d_present = 0;
+   }
 
/*
 * Reset the bus. If there's no presence pulse don't search
@@ -497,3 +500,11 @@ out:
}
}
 }
+
+int
+onewire_quirks(void *arg)
+{
+   struct onewire_softc *sc = arg;
+
+   return (sc->sc_flags & ONEWIRE_TIMESTAMP);
+}
diff --git sys/dev/onewire/onewirevar.h sys/dev/onewire/onewirevar.h
index ab3776f50bf..673e0d7e7b2 100644
--- sys/dev/onewire/onewirevar.h
+++ sys/dev/onewire/onewirevar.h
@@ -51,6 +51,7 @@ void  onewire_write_block(void *, const void *, int);
 intonewire_triplet(void *, int);
 void   onewire_matchrom(void *, u_int64_t);
 intonewire_search(void *, u_int64_t *, int, u_int64_t);
+intonewire_quirks(void *);
 
 #define ONEWIRE_NOWAIT 0x0001
 
@@ -60,6 +61,8 @@ struct onewirebus_attach_args {
int oba_flags;
 #defineONEWIRE_SCAN_NOW0x0001
 #defineONEWIRE_NO_PERIODIC_SCAN0x0002
+#defineONEWIRE_NO_DETACH   0x0004
+#defineONEWIRE_TIMESTAMP   0x0008
 };
 
 intonewirebus_print(void *, const char *);
diff --git sys/dev/onewire/owtemp.c sys/dev/onewire/owtemp.c
index e883dbb17a9..542a331c508 100644
--- sys/dev/onewire/owtemp.c
+++ sys/dev/onewire/owtemp.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -50,6 +51,7 @@ struct owtemp_softc {
 
void *  sc_onewire;
u_int64_t   sc_rom;
+   int sc_timestamp;
 
struct ksensor  sc_sensor;
struct ksensordev   sc_sensordev;
@@ -104,6 +106,8 @@ owtemp_attach(struct device *parent, struct device *self, 
void *aux)
snprintf(sc->sc_sensor.desc, sizeof(sc->sc_sensor.desc), "sn %012llx",
ONEWIRE_ROM_SN(oa->oa_rom));
 
+   sc->sc_timestamp = onewire_quirks(sc->sc_onewire) & ONEWIRE_TIMESTAMP;
+
sc->sc_sensortask = sensor_task_register(sc, owtemp_update, 5);
if (sc->sc_sensortask == NULL) {
printf(": unable to register update task\n");
@@ -196,6 +200,8 @@ owtemp_update(void *arg)
}
}
sc->sc_sensor.value = 27315 + val;
+   if (sc->sc_timestamp)
+   sc->sc_sensor.tv.tv_sec = time_second;
}
 
 done:



Re: armv7 -pmap_prefer

2018-03-15 Thread Artturi Alm
On Fri, Jul 21, 2017 at 06:49:01AM +0300, Artturi Alm wrote:
> On Thu, Jul 20, 2017 at 11:50:55PM +0300, Artturi Alm wrote:
> > Hi,
> > 
> > one of the removals of mine i never understood why it was there to
> > begin w/, given it's not in our pmap.9, nor really doing anything.
> > 
> > -Artturi
> > 
> 
> Took a better look, and this might actually be considered a bug fix,
> if expected value for armv7 out of PMAP_PREFER_ALIGN() actually is
> 0x1000, as it would be after this diff, but nothing else changes, as
> pmap_alias_dist is always 0.
> 
> I'm not going to learn any more of uvm_map.c, to know if there's any
> actual difference between PMAP_PREFER_ALIGN() returning current 0
> instead of PAGE_SIZE.., so will leave this to those who know more:)
> -Artturi
> 

pong? :)
-Artturi

> 
> > 
> > diff --git a/sys/arch/arm/arm/pmap7.c b/sys/arch/arm/arm/pmap7.c
> > index f99ee582e00..d47d8058736 100644
> > --- a/sys/arch/arm/arm/pmap7.c
> > +++ b/sys/arch/arm/arm/pmap7.c
> > @@ -2872,20 +2872,3 @@ pmap_pte_init_armv7(void)
> > if ((id_mmfr3 & 0x00f0) == 0x0010)
> > pmap_needs_pte_sync = 0;
> >  }
> > -
> > -uint32_t pmap_alias_dist;
> > -uint32_t pmap_alias_bits;
> > -
> > -vaddr_t
> > -pmap_prefer(vaddr_t foff, vaddr_t va)
> > -{
> > -   long d, m;
> > -
> > -   m = pmap_alias_dist;
> > -   if (m == 0) /* m=0 => no cache aliasing */
> > -   return va;
> > -
> > -   d = foff - va;
> > -   d &= (m - 1);
> > -   return va + d;
> > -}
> > diff --git a/sys/arch/arm/include/pmap.h b/sys/arch/arm/include/pmap.h
> > index 83c3395f710..3284418f924 100644
> > --- a/sys/arch/arm/include/pmap.h
> > +++ b/sys/arch/arm/include/pmap.h
> > @@ -619,23 +619,6 @@ l2pte_is_writeable(pt_entry_t pte, struct pmap *pm)
> >  #defineL2_L_MAPPABLE_P(va, pa, size)   
> > \
> > va) | (pa)) & L2_L_OFFSET) == 0 && (size) >= L2_L_SIZE)
> >  
> > -#ifndef _LOCORE
> > -/* pmap_prefer bits for VIPT ARMv7 */
> > -#define PMAP_PREFER(fo, ap)pmap_prefer((fo), (ap))
> > -vaddr_tpmap_prefer(vaddr_t, vaddr_t);
> > -
> > -extern uint32_t pmap_alias_dist;
> > -extern uint32_t pmap_alias_bits;
> > -
> > -/* pmap prefer alias alignment. */
> > -#define PMAP_PREFER_ALIGN()(pmap_alias_dist)
> > -/* pmap prefer offset withing alignment. */
> > -#define PMAP_PREFER_OFFSET(of) 
> > \
> > -(PMAP_PREFER_ALIGN() == 0 ? 0 : ((of) & (PMAP_PREFER_ALIGN() - 1)))
> > -
> > -
> > -#endif /* _LOCORE */
> > -
> >  #endif /* _KERNEL */
> >  
> >  #ifndef _LOCORE



Re: armv7/arm64: just a bit || some tc_counter_mask fixes

2018-03-12 Thread Artturi Alm
On Mon, Mar 12, 2018 at 11:25:09PM +0100, Mark Kettenis wrote:
> > Date: Fri, 9 Mar 2018 19:43:42 +0200
> > From: Artturi Alm 
> > 
> > Hi,
> > 
> > lazy retry[0],
> > to give these timers their (likely) copy-paste-robbed MSB back.
> > 
> > -Artturi
> > 
> > [0] https://marc.info/?l=openbsd-tech&m=150421823512699&w=1
> 
> This doesn't actually fix anything; 31 bits are plenty.  Leaving off
> the top bit protects against signed/unsigned mistakes although there
> shouldn't be any.  So I'm not sure this is worth it.
> 

forgot about the 'protects against..':
iirc. that mask is only ever used in sys/kern/kern_tc.c, so within
these timers it does nothing, so i see no protection from it.
i think it would be known by now if kern_tc.c was unable to get
along w/the 32bit rollover.

-Artturi

> > diff --git sys/arch/arm/cortex/agtimer.c sys/arch/arm/cortex/agtimer.c
> > index 8d622c058a4..160e22e6949 100644
> > --- sys/arch/arm/cortex/agtimer.c
> > +++ sys/arch/arm/cortex/agtimer.c
> > @@ -46,7 +46,7 @@ int32_t agtimer_frequency = TIMER_FREQUENCY;
> >  u_int agtimer_get_timecount(struct timecounter *);
> >  
> >  static struct timecounter agtimer_timecounter = {
> > -   agtimer_get_timecount, NULL, 0x7fff, 0, "agtimer", 0, NULL
> > +   agtimer_get_timecount, NULL, 0x, 0, "agtimer", 0, NULL
> >  };
> >  
> >  #define MAX_ARM_CPUS   8
> > diff --git sys/arch/arm/cortex/amptimer.c sys/arch/arm/cortex/amptimer.c
> > index 81880c1574a..66f0ccfed64 100644
> > --- sys/arch/arm/cortex/amptimer.c
> > +++ sys/arch/arm/cortex/amptimer.c
> > @@ -67,7 +67,7 @@ int32_t amptimer_frequency = TIMER_FREQUENCY;
> >  u_int amptimer_get_timecount(struct timecounter *);
> >  
> >  static struct timecounter amptimer_timecounter = {
> > -   amptimer_get_timecount, NULL, 0x7fff, 0, "amptimer", 0, NULL
> > +   amptimer_get_timecount, NULL, 0x, 0, "amptimer", 0, NULL
> >  };
> >  
> >  #define MAX_ARM_CPUS   8
> > diff --git sys/arch/arm64/dev/agtimer.c sys/arch/arm64/dev/agtimer.c
> > index 0e6e6a3bc6e..7d9557e706f 100644
> > --- sys/arch/arm64/dev/agtimer.c
> > +++ sys/arch/arm64/dev/agtimer.c
> > @@ -43,7 +43,7 @@ int32_t agtimer_frequency = TIMER_FREQUENCY;
> >  u_int agtimer_get_timecount(struct timecounter *);
> >  
> >  static struct timecounter agtimer_timecounter = {
> > -   agtimer_get_timecount, NULL, 0x7fff, 0, "agtimer", 0, NULL
> > +   agtimer_get_timecount, NULL, 0x, 0, "agtimer", 0, NULL
> >  };
> >  
> >  #define MAX_ARM_CPUS   8
> > diff --git sys/arch/armv7/omap/gptimer.c sys/arch/armv7/omap/gptimer.c
> > index e87db41106e..2e6c8cf8d42 100644
> > --- sys/arch/armv7/omap/gptimer.c
> > +++ sys/arch/armv7/omap/gptimer.c
> > @@ -117,7 +117,7 @@ int gptimer_irq = 0;
> >  u_int gptimer_get_timecount(struct timecounter *);
> >  
> >  static struct timecounter gptimer_timecounter = {
> > -   gptimer_get_timecount, NULL, 0x7fff, 0, "gptimer", 0, NULL
> > +   gptimer_get_timecount, NULL, 0x, 0, "gptimer", 0, NULL
> >  };
> >  
> >  volatile u_int32_t nexttickevent;
> > 
> > 



Re: armv7/arm64: just a bit || some tc_counter_mask fixes

2018-03-12 Thread Artturi Alm
On Mon, Mar 12, 2018 at 11:25:09PM +0100, Mark Kettenis wrote:
> > Date: Fri, 9 Mar 2018 19:43:42 +0200
> > From: Artturi Alm 
> > 
> > Hi,
> > 
> > lazy retry[0],
> > to give these timers their (likely) copy-paste-robbed MSB back.
> > 
> > -Artturi
> > 
> > [0] https://marc.info/?l=openbsd-tech&m=150421823512699&w=1
> 
> This doesn't actually fix anything; 31 bits are plenty.  Leaving off
> the top bit protects against signed/unsigned mistakes although there
> shouldn't be any.  So I'm not sure this is worth it.
> 

I still think the current masks are only brought over(by accident) from
some macppc timer actually having had only 31bits in the early 90s.
also, fwiw. all these timers have atleast 32bits in use on other BSDs.

now if focusing only the documentation issue i'm having with these masks
in use, is that either this(comment) should be changed(sys/timetc.h):

 47 timecounter_get_t   *tc_get_timecount;
 48 /*
 49  * This function reads the counter.  It is not required to
 50  * mask any unimplemented bits out, as long as they are
 51  * constant.
 52  */

or the *tc_get_timecount functions of affected timers be changed to mask
out the non-constant bit, which i think would be silly.

tbh., i'm only worried about amptimer w/high default freq(396MHz),
and only because i'm still optimistic we would see the HZ bump[0] in near
future, making the lack of MSB possibly more of an possible issue?

-Artturi

[0] https://marc.info/?l=openbsd-tech&m=150274123011009&w=1



armv7/arm64: just a bit || some tc_counter_mask fixes

2018-03-09 Thread Artturi Alm
Hi,

lazy retry[0],
to give these timers their (likely) copy-paste-robbed MSB back.

-Artturi

[0] https://marc.info/?l=openbsd-tech&m=150421823512699&w=1


diff --git sys/arch/arm/cortex/agtimer.c sys/arch/arm/cortex/agtimer.c
index 8d622c058a4..160e22e6949 100644
--- sys/arch/arm/cortex/agtimer.c
+++ sys/arch/arm/cortex/agtimer.c
@@ -46,7 +46,7 @@ int32_t agtimer_frequency = TIMER_FREQUENCY;
 u_int agtimer_get_timecount(struct timecounter *);
 
 static struct timecounter agtimer_timecounter = {
-   agtimer_get_timecount, NULL, 0x7fff, 0, "agtimer", 0, NULL
+   agtimer_get_timecount, NULL, 0x, 0, "agtimer", 0, NULL
 };
 
 #define MAX_ARM_CPUS   8
diff --git sys/arch/arm/cortex/amptimer.c sys/arch/arm/cortex/amptimer.c
index 81880c1574a..66f0ccfed64 100644
--- sys/arch/arm/cortex/amptimer.c
+++ sys/arch/arm/cortex/amptimer.c
@@ -67,7 +67,7 @@ int32_t amptimer_frequency = TIMER_FREQUENCY;
 u_int amptimer_get_timecount(struct timecounter *);
 
 static struct timecounter amptimer_timecounter = {
-   amptimer_get_timecount, NULL, 0x7fff, 0, "amptimer", 0, NULL
+   amptimer_get_timecount, NULL, 0x, 0, "amptimer", 0, NULL
 };
 
 #define MAX_ARM_CPUS   8
diff --git sys/arch/arm64/dev/agtimer.c sys/arch/arm64/dev/agtimer.c
index 0e6e6a3bc6e..7d9557e706f 100644
--- sys/arch/arm64/dev/agtimer.c
+++ sys/arch/arm64/dev/agtimer.c
@@ -43,7 +43,7 @@ int32_t agtimer_frequency = TIMER_FREQUENCY;
 u_int agtimer_get_timecount(struct timecounter *);
 
 static struct timecounter agtimer_timecounter = {
-   agtimer_get_timecount, NULL, 0x7fff, 0, "agtimer", 0, NULL
+   agtimer_get_timecount, NULL, 0x, 0, "agtimer", 0, NULL
 };
 
 #define MAX_ARM_CPUS   8
diff --git sys/arch/armv7/omap/gptimer.c sys/arch/armv7/omap/gptimer.c
index e87db41106e..2e6c8cf8d42 100644
--- sys/arch/armv7/omap/gptimer.c
+++ sys/arch/armv7/omap/gptimer.c
@@ -117,7 +117,7 @@ int gptimer_irq = 0;
 u_int gptimer_get_timecount(struct timecounter *);
 
 static struct timecounter gptimer_timecounter = {
-   gptimer_get_timecount, NULL, 0x7fff, 0, "gptimer", 0, NULL
+   gptimer_get_timecount, NULL, 0x, 0, "gptimer", 0, NULL
 };
 
 volatile u_int32_t nexttickevent;



Re: arm64: Makefile.arm64 av7 content

2018-03-09 Thread Artturi Alm
On Tue, Mar 06, 2018 at 11:34:23PM +0200, Artturi Alm wrote:
> Hi,
> 
> was 'grepping' for something, and these came up.
> 
> i guess atleast trampoline.S would work w/o including assym.h at all,
> but here is what i'm sure enough of w/o actually compiling yet. :D
> 
> -Artturi
> 
> 
> diff --git sys/arch/arm64/conf/Makefile.arm64 
> sys/arch/arm64/conf/Makefile.arm64
> index bd56f7a1427..f98d82ff0f7 100644
> --- sys/arch/arm64/conf/Makefile.arm64
> +++ sys/arch/arm64/conf/Makefile.arm64
> @@ -143,9 +143,9 @@ cleandir: clean
>  depend obj:
>  
>  locore0.o: ${_archdir}/${_arch}/locore0.S assym.h
> -in_cksum_arm.o fiq_subr.o bcopyinout.o copystr.o sigcode.o copy.o: assym.h
> -cpuswitch.o exception.o bcopy_page.o irq_dispatch.o support.o: assym.h
> -locore.o vectors.o trampoline.o: assym.h
> +copy.o copystr.o.o: assym.h
> +cpuswitch.o exception.o support.o: assym.h
> +locore.o trampoline.o: assym.h
>  
>  hardlink-obsd:
>   [[ ! -f /bsd ]] || cmp -s bsd /bsd || ln -f /bsd /obsd

diff below is what i ended up w/after fixing the extra '.o'-mistake in
above diff. built&tested on pine64.

-Artturi


diff --git sys/arch/arm64/arm64/support.S sys/arch/arm64/arm64/support.S
index ea0212b59ae..cccfd2f51ae 100644
--- sys/arch/arm64/arm64/support.S
+++ sys/arch/arm64/arm64/support.S
@@ -39,8 +39,6 @@ __FBSDID("$FreeBSD: head/sys/arm64/arm64/support.S 297615 
2016-04-06 14:08:10Z a
 #include 
 #include 
 
-#include "assym.h"
-
 #ifdef DDB
 ENTRY(setjmp)
/* Store the stack pointer */
diff --git sys/arch/arm64/arm64/trampoline.S sys/arch/arm64/arm64/trampoline.S
index 4de835ddb5c..2f633918c5c 100644
--- sys/arch/arm64/arm64/trampoline.S
+++ sys/arch/arm64/arm64/trampoline.S
@@ -18,7 +18,6 @@
 
 #include 
 #include 
-#include "assym.h"
 
.text
 
diff --git sys/arch/arm64/conf/Makefile.arm64 sys/arch/arm64/conf/Makefile.arm64
index bd56f7a1427..c56b597ba3c 100644
--- sys/arch/arm64/conf/Makefile.arm64
+++ sys/arch/arm64/conf/Makefile.arm64
@@ -143,9 +143,9 @@ cleandir: clean
 depend obj:
 
 locore0.o: ${_archdir}/${_arch}/locore0.S assym.h
-in_cksum_arm.o fiq_subr.o bcopyinout.o copystr.o sigcode.o copy.o: assym.h
-cpuswitch.o exception.o bcopy_page.o irq_dispatch.o support.o: assym.h
-locore.o vectors.o trampoline.o: assym.h
+copy.o copystr.o: assym.h
+cpuswitch.o exception.o: assym.h
+locore.o: assym.h
 
 hardlink-obsd:
[[ ! -f /bsd ]] || cmp -s bsd /bsd || ln -f /bsd /obsd



Re: onewire/owtemp: flags for no_detach+timestamp.

2018-03-09 Thread Artturi Alm
On Wed, Mar 07, 2018 at 06:26:15AM +0200, Artturi Alm wrote:
> Hi,
> 
> i tested gpioow on beaglebone black a few days ago, and when i was lazy
> to fix the 'cables' my sensors were attached to, console was spammed
> over night by some of the sensors.
> i found the hotplug spam+disappearing sensors annoying.
> 
> if i read gpioctl(8) correctly, i should be able to pass these flags like
> "gpioctl gpio1 attach gpioow 16 0x01 [flags]" ?
> 
> yet untested diff below showing what i think i'm missing,
> and for which any input would be much appreciated by those familiar with
> gpioow(4)i/sensors frsmrwork, or anyone w/comments generally :)
> 
> -Artturi
> 

so this does lower the bar for owtemp(4) to be more easily usable/reliable
via sysctl(8) alone in some simple script or w/e(sensor will be there,
and w/timedelta one can decide whether to use the value or not).

besides the obvious copy-paste-bugs in the previous draft,
i missed how gpioow(4) didn't pass the flags to onewire(4) oba_flags.

diff below does work good enough for my use, and i don't care about the
inherent 5sec 'lag' on timedelta enough to make the diff any bigger.

rc.securelevel:
gpioctl gpio1 attach gpioow 16 1 12

root@av7bbb:~ # sysctl hw.sensors
hw.sensors.owtemp0.temp0=30.56 degC (sn 025f07aa)
hw.sensors.owtemp0.timedelta0=5.00 secs (LastUpdate)
hw.sensors.owtemp1.temp0=30.88 degC (sn 025ecdb5)
hw.sensors.owtemp1.timedelta0=5.00 secs (LastUpdate)
hw.sensors.owtemp2.temp0=30.50 degC (sn 025f13ad)
hw.sensors.owtemp2.timedelta0=5.00 secs (LastUpdate)

-Artturi


diff --git sys/dev/gpio/gpioow.c sys/dev/gpio/gpioow.c
index 64d79ab0cb8..f7b7eb83e4b 100644
--- sys/dev/gpio/gpioow.c
+++ sys/dev/gpio/gpioow.c
@@ -147,6 +147,7 @@ gpioow_attach(struct device *parent, struct device *self, 
void *aux)
 
bzero(&oba, sizeof(oba));
oba.oba_bus = &sc->sc_ow_bus;
+   oba.oba_flags = ga->ga_flags;
sc->sc_ow_dev = config_found(self, &oba, onewirebus_print);
 
return;
diff --git sys/dev/onewire/onewire.c sys/dev/onewire/onewire.c
index 679bcd90e85..263f65ab674 100644
--- sys/dev/onewire/onewire.c
+++ sys/dev/onewire/onewire.c
@@ -434,8 +434,11 @@ onewire_scan(struct onewire_softc *sc)
 * scanning. This allows to find out later which devices
 * have been disappeared.
 */
-   TAILQ_FOREACH(d, &sc->sc_devs, d_list)
+   TAILQ_FOREACH(d, &sc->sc_devs, d_list) {
+   if (sc->sc_flags & ONEWIRE_NO_DETACH)
+   break;
d->d_present = 0;
+   }
 
/*
 * Reset the bus. If there's no presence pulse don't search
@@ -497,3 +500,11 @@ out:
}
}
 }
+
+int
+onewire_quirks(void *arg)
+{
+   struct onewire_softc *sc = arg;
+
+   return (sc->sc_flags & ONEWIRE_TIMESTAMP);
+}
diff --git sys/dev/onewire/onewirevar.h sys/dev/onewire/onewirevar.h
index ab3776f50bf..673e0d7e7b2 100644
--- sys/dev/onewire/onewirevar.h
+++ sys/dev/onewire/onewirevar.h
@@ -51,6 +51,7 @@ void  onewire_write_block(void *, const void *, int);
 intonewire_triplet(void *, int);
 void   onewire_matchrom(void *, u_int64_t);
 intonewire_search(void *, u_int64_t *, int, u_int64_t);
+intonewire_quirks(void *);
 
 #define ONEWIRE_NOWAIT 0x0001
 
@@ -60,6 +61,8 @@ struct onewirebus_attach_args {
int oba_flags;
 #defineONEWIRE_SCAN_NOW0x0001
 #defineONEWIRE_NO_PERIODIC_SCAN0x0002
+#defineONEWIRE_NO_DETACH   0x0004
+#defineONEWIRE_TIMESTAMP   0x0008
 };
 
 intonewirebus_print(void *, const char *);
diff --git sys/dev/onewire/owtemp.c sys/dev/onewire/owtemp.c
index e883dbb17a9..4c7615ab1ef 100644
--- sys/dev/onewire/owtemp.c
+++ sys/dev/onewire/owtemp.c
@@ -24,8 +24,10 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -50,8 +52,10 @@ struct owtemp_softc {
 
void *  sc_onewire;
u_int64_t   sc_rom;
+   time_t  sc_timestamp;
 
struct ksensor  sc_sensor;
+   struct ksensor  *sc_sensor_td;
struct ksensordev   sc_sensordev;
struct sensor_task  *sc_sensortask;
struct rwlock   sc_lock;
@@ -104,12 +108,25 @@ owtemp_attach(struct device *parent, struct device *self, 
void *aux)
snprintf(sc->sc_sensor.desc, sizeof(sc->sc_sensor.desc), "sn %012llx",
ONEWIRE_ROM_SN(oa->oa_rom));
 
+   if (onewire_quirks(sc->sc_onewire) & ONEWIRE_TIMESTAMP) {
+   sc->sc_sensor_td = malloc(sizeof(struct ksensor),
+   M_DEVBUF, M_NOWAIT|M_ZERO);
+   if (sc->sc_

Re: arm64/machdep.c: strncpy+overlap - "boot> boot -s" behaviour

2018-03-08 Thread Artturi Alm
On Thu, Mar 08, 2018 at 08:42:09AM +0200, Artturi Alm wrote:
> Hi,
> 
> another user mentioned on irc about issue w/"boot -s" not working on rpi3.
> diff below fixes secondary the strncpy() w/dst==src, and also adds blank
> line after the function which does the correct strncpy.
> 

i just tested it myself, and i had no issues with "boot bsd -cs" on arm64
before applying the diff below going through both UKC&single-user,
but i still think the diff below should be there,
even if just for the correctness.

-Artturi

> -Artturi
> 
> 
> diff --git sys/arch/arm64/arm64/machdep.c sys/arch/arm64/arm64/machdep.c
> index ac3a9f6344b..db4bd8532eb 100644
> --- sys/arch/arm64/arm64/machdep.c
> +++ sys/arch/arm64/arm64/machdep.c
> @@ -1121,6 +1121,7 @@ collect_kernel_args(char *args)
>   /* Make a local copy of the bootargs */
>   strncpy(bootargs, args, MAX_BOOT_STRING - sizeof(int));
>  }
> +
>  void
>  process_kernel_args(void)
>  {
> @@ -1132,11 +1133,6 @@ process_kernel_args(void)
>   }
>  
>   boothowto = 0;
> -
> - /* Make a local copy of the bootargs */
> - strncpy(bootargs, cp, MAX_BOOT_STRING - sizeof(int));
> -
> - cp = bootargs;
>   boot_file = bootargs;
>  
>   /* Skip the kernel image filename */



arm64/machdep.c: strncpy+overlap - "boot> boot -s" behaviour

2018-03-07 Thread Artturi Alm
Hi,

another user mentioned on irc about issue w/"boot -s" not working on rpi3.
diff below fixes secondary the strncpy() w/dst==src, and also adds blank
line after the function which does the correct strncpy.

-Artturi


diff --git sys/arch/arm64/arm64/machdep.c sys/arch/arm64/arm64/machdep.c
index ac3a9f6344b..db4bd8532eb 100644
--- sys/arch/arm64/arm64/machdep.c
+++ sys/arch/arm64/arm64/machdep.c
@@ -1121,6 +1121,7 @@ collect_kernel_args(char *args)
/* Make a local copy of the bootargs */
strncpy(bootargs, args, MAX_BOOT_STRING - sizeof(int));
 }
+
 void
 process_kernel_args(void)
 {
@@ -1132,11 +1133,6 @@ process_kernel_args(void)
}
 
boothowto = 0;
-
-   /* Make a local copy of the bootargs */
-   strncpy(bootargs, cp, MAX_BOOT_STRING - sizeof(int));
-
-   cp = bootargs;
boot_file = bootargs;
 
/* Skip the kernel image filename */



onewire/owtemp: flags for no_detach+timestamp.

2018-03-06 Thread Artturi Alm
Hi,

i tested gpioow on beaglebone black a few days ago, and when i was lazy
to fix the 'cables' my sensors were attached to, console was spammed
over night by some of the sensors.
i found the hotplug spam+disappearing sensors annoying.

if i read gpioctl(8) correctly, i should be able to pass these flags like
"gpioctl gpio1 attach gpioow 16 0x01 [flags]" ?

yet untested diff below showing what i think i'm missing,
and for which any input would be much appreciated by those familiar with
gpioow(4)i/sensors frsmrwork, or anyone w/comments generally :)

-Artturi


diff --git sys/dev/onewire/onewire.c sys/dev/onewire/onewire.c
index 679bcd90e85..263f65ab674 100644
--- sys/dev/onewire/onewire.c
+++ sys/dev/onewire/onewire.c
@@ -434,8 +434,11 @@ onewire_scan(struct onewire_softc *sc)
 * scanning. This allows to find out later which devices
 * have been disappeared.
 */
-   TAILQ_FOREACH(d, &sc->sc_devs, d_list)
+   TAILQ_FOREACH(d, &sc->sc_devs, d_list) {
+   if (sc->sc_flags & ONEWIRE_NO_DETACH)
+   break;
d->d_present = 0;
+   }
 
/*
 * Reset the bus. If there's no presence pulse don't search
@@ -497,3 +500,11 @@ out:
}
}
 }
+
+int
+onewire_quirks(void *arg)
+{
+   struct onewire_softc *sc = arg;
+
+   return (sc->sc_flags & ONEWIRE_TIMESTAMP);
+}
diff --git sys/dev/onewire/onewirevar.h sys/dev/onewire/onewirevar.h
index ab3776f50bf..673e0d7e7b2 100644
--- sys/dev/onewire/onewirevar.h
+++ sys/dev/onewire/onewirevar.h
@@ -51,6 +51,7 @@ void  onewire_write_block(void *, const void *, int);
 intonewire_triplet(void *, int);
 void   onewire_matchrom(void *, u_int64_t);
 intonewire_search(void *, u_int64_t *, int, u_int64_t);
+intonewire_quirks(void *);
 
 #define ONEWIRE_NOWAIT 0x0001
 
@@ -60,6 +61,8 @@ struct onewirebus_attach_args {
int oba_flags;
 #defineONEWIRE_SCAN_NOW0x0001
 #defineONEWIRE_NO_PERIODIC_SCAN0x0002
+#defineONEWIRE_NO_DETACH   0x0004
+#defineONEWIRE_TIMESTAMP   0x0008
 };
 
 intonewirebus_print(void *, const char *);
diff --git sys/dev/onewire/owtemp.c sys/dev/onewire/owtemp.c
index e883dbb17a9..e21862889e3 100644
--- sys/dev/onewire/owtemp.c
+++ sys/dev/onewire/owtemp.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -50,8 +51,10 @@ struct owtemp_softc {
 
void *  sc_onewire;
u_int64_t   sc_rom;
+   time_t  sc_timestamp;
 
struct ksensor  sc_sensor;
+   struct ksensor  *sc_sensor_td;
struct ksensordev   sc_sensordev;
struct sensor_task  *sc_sensortask;
struct rwlock   sc_lock;
@@ -104,12 +107,25 @@ owtemp_attach(struct device *parent, struct device *self, 
void *aux)
snprintf(sc->sc_sensor.desc, sizeof(sc->sc_sensor.desc), "sn %012llx",
ONEWIRE_ROM_SN(oa->oa_rom));
 
+   if (onewire_quirks(sc->sc_onewire) & ONEWIRE_TIMESTAMP) {
+   sc->sc_sensor_td = malloc(sizeof(struct onewire_device),
+   M_DEVBUF, M_NOWAIT);
+   if (sc->sc_sensor_td) {
+   sc->sc_sensor_td->type = SENSOR_TIMEDELTA;
+   strlcpy(sc->sc_sensor_td->desc, "LastUpdate",
+   sizeof(sc->sc_sensor_td->desc));
+   }
+   }
+   sc_timestamp = 0;
+
sc->sc_sensortask = sensor_task_register(sc, owtemp_update, 5);
if (sc->sc_sensortask == NULL) {
printf(": unable to register update task\n");
return;
}
sensor_attach(&sc->sc_sensordev, &sc->sc_sensor);
+   if (sc->sc_sensor_td)
+   sensor_attach(&sc->sc_sensordev, sc->sc_sensor_td);
sensordev_install(&sc->sc_sensordev);
 
rw_init(&sc->sc_lock, sc->sc_dev.dv_xname);
@@ -146,6 +162,13 @@ owtemp_update(void *arg)
 
rw_enter_write(&sc->sc_lock);
onewire_lock(sc->sc_onewire, 0);
+
+   /* Update timedelta of last successful reading */
+   if (sc->sc_sensor_td != NULL && sc_timestamp != 0) {
+   sc->sc_sensor_td->value = time_second - sc->sc_timestamp;
+   sc->sc_sensor_td->value *= 10LL;
+   }
+
if (onewire_reset(sc->sc_onewire) != 0)
goto done;
onewire_matchrom(sc->sc_onewire, sc->sc_rom);
@@ -196,6 +219,8 @@ owtemp_update(void *arg)
}
}
sc->sc_sensor.value = 27315 + val;
+   if (sc->sc_sensor_td != NULL)
+   sc->sc_timestamp = time_second;
}
 
 done:



armv7: bcopy_page.S XSCALE cleanup+pld preload

2018-03-06 Thread Artturi Alm
Hi,

at worst, for ARMv5TE and above the hint instructions execute as NOPs,
if they are not implemented.

while the Q in link below, does mention Cortex-A8,
i believe the "answer" they provide, does somewhat apply 'upwards' :)

-Artturi


Q: What is the fastest way to copy memory on a Cortex-A8?
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka13544.html



diff --git sys/arch/arm/arm/bcopy_page.S sys/arch/arm/arm/bcopy_page.S
index 3c8f1ae2ce6..e8ee69bd897 100644
--- sys/arch/arm/arm/bcopy_page.S
+++ sys/arch/arm/arm/bcopy_page.S
@@ -44,10 +44,6 @@
 
 #include "assym.h"
 
-#ifndef __XSCALE__
-
-/* #define BIG_LOOPS */
-
 /*
  * bcopy_page(src, dest)
  *
@@ -58,46 +54,24 @@
  *   r1 - dest address
  *
  * Requires:
- *   number of bytes per page (PAGE_SIZE) is a multiple of 512 (BIG_LOOPS), 128
- *   otherwise.
+ *   number of bytes per page (PAGE_SIZE) is a multiple of 512.
  */
 
-#defineCHUNK_SIZE  32
-
-#definePREFETCH_FIRST_CHUNK/* nothing */
-#definePREFETCH_NEXT_CHUNK /* nothing */
-
-#ifndef COPY_CHUNK
 #defineCOPY_CHUNK \
-   PREFETCH_NEXT_CHUNK ; \
+   pld [r0, #0x18] ; \
ldmia   r0!, {r3-r8,ip,lr} ; \
stmia   r1!, {r3-r8,ip,lr}
-#endif /* ! COPY_CHUNK */
-
-#ifndef SAVE_REGS
-#defineSAVE_REGS   stmfd   sp!, {r4-r8, lr}
-#defineRESTORE_REGSldmfd   sp!, {r4-r8, pc}
-#endif
 
 ENTRY(bcopy_page)
-   PREFETCH_FIRST_CHUNK
-   SAVE_REGS
-#ifdef BIG_LOOPS
+   pld [r0]
+   stmfd   sp!, {r4-r8, lr}
mov r2, #(PAGE_SIZE >> 9)
-#else
-   mov r2, #(PAGE_SIZE >> 7)
-#endif
-
 1:
COPY_CHUNK
COPY_CHUNK
COPY_CHUNK
COPY_CHUNK
 
-#ifdef BIG_LOOPS
-   /* There is little point making the loop any larger; unless we are
-  running with the cache off, the load/store overheads will
-  completely dominate this loop.  */
COPY_CHUNK
COPY_CHUNK
COPY_CHUNK
@@ -112,11 +86,14 @@ ENTRY(bcopy_page)
COPY_CHUNK
COPY_CHUNK
COPY_CHUNK
-#endif
+
+   /* There is little point making the loop any larger; unless we are
+  running with the cache off, the load/store overheads will
+  completely dominate this loop.  */
subsr2, r2, #1
bne 1b
 
-   RESTORE_REGS/* ...and return. */
+   ldmfd   sp!, {r4-r8, pc}/* ...and return. */
 
 /*
  * bzero_page(dest)
@@ -127,17 +104,12 @@ ENTRY(bcopy_page)
  *   r0 - dest address
  *
  * Requires:
- *   number of bytes per page (PAGE_SIZE) is a multiple of 512 (BIG_LOOPS), 128
- *   otherwise
+ *   number of bytes per page (PAGE_SIZE) is a multiple of 512.
  */
 
 ENTRY(bzero_page)
stmfd   sp!, {r4-r8, lr}
-#ifdef BIG_LOOPS
mov r2, #(PAGE_SIZE >> 9)
-#else
-   mov r2, #(PAGE_SIZE >> 7)
-#endif
mov r3, #0
mov r4, #0
mov r5, #0
@@ -153,10 +125,6 @@ ENTRY(bzero_page)
stmia   r0!, {r3-r8,ip,lr}
stmia   r0!, {r3-r8,ip,lr}
 
-#ifdef BIG_LOOPS
-   /* There is little point making the loop any larger; unless we are
-  running with the cache off, the load/store overheads will
-  completely dominate this loop.  */
stmia   r0!, {r3-r8,ip,lr}
stmia   r0!, {r3-r8,ip,lr}
stmia   r0!, {r3-r8,ip,lr}
@@ -172,105 +140,7 @@ ENTRY(bzero_page)
stmia   r0!, {r3-r8,ip,lr}
stmia   r0!, {r3-r8,ip,lr}
 
-#endif
-
subsr2, r2, #1
bne 1b
 
ldmfd   sp!, {r4-r8, pc}
-
-#else  /* __XSCALE__ */
-
-/*
- * XSCALE version of bcopy_page
- */
-ENTRY(bcopy_page)
-   pld [r0]
-   stmfd   sp!, {r4, r5}
-   mov ip, #32
-   ldr r2, [r0], #0x04 /* 0x00 */
-   ldr r3, [r0], #0x04 /* 0x04 */
-1: pld [r0, #0x18] /* Prefetch 0x20 */
-   ldr r4, [r0], #0x04 /* 0x08 */
-   ldr r5, [r0], #0x04 /* 0x0c */
-   strdr2, [r1], #0x08
-   ldr r2, [r0], #0x04 /* 0x10 */
-   ldr r3, [r0], #0x04 /* 0x14 */
-   strdr4, [r1], #0x08
-   ldr r4, [r0], #0x04 /* 0x18 */
-   ldr r5, [r0], #0x04 /* 0x1c */
-   strdr2, [r1], #0x08
-   ldr r2, [r0], #0x04 /* 0x20 */
-   ldr r3, [r0], #0x04 /* 0x24 */
-   pld [r0, #0x18] /* Prefetch 0x40 */
-   strdr4, [r1], #0x08
-   ldr r4, [r0], #0x04 /* 0x28 */
-   ldr r5, [r0], #0x04 /* 0x2c */
-   strdr2, [r1], #0x08
-   ldr r2, [r0], #0x04 /* 0x30 */
-   ldr r3, [r0], #0x04 /* 0x34 */
-   strdr4, [r1], #0x08
-   ldr r4, [r0], #0x04 /* 0x38 */
-   ldr r5, [r0], #0x04 /* 0x3c */
-   strdr2, [r1], #0x08
-   ldr r2, [r0], #0x04 /* 0x40 */
-   ldr r3, [r0], #0x04  

arm64: Makefile.arm64 av7 content

2018-03-06 Thread Artturi Alm
Hi,

was 'grepping' for something, and these came up.

i guess atleast trampoline.S would work w/o including assym.h at all,
but here is what i'm sure enough of w/o actually compiling yet. :D

-Artturi


diff --git sys/arch/arm64/conf/Makefile.arm64 sys/arch/arm64/conf/Makefile.arm64
index bd56f7a1427..f98d82ff0f7 100644
--- sys/arch/arm64/conf/Makefile.arm64
+++ sys/arch/arm64/conf/Makefile.arm64
@@ -143,9 +143,9 @@ cleandir: clean
 depend obj:
 
 locore0.o: ${_archdir}/${_arch}/locore0.S assym.h
-in_cksum_arm.o fiq_subr.o bcopyinout.o copystr.o sigcode.o copy.o: assym.h
-cpuswitch.o exception.o bcopy_page.o irq_dispatch.o support.o: assym.h
-locore.o vectors.o trampoline.o: assym.h
+copy.o copystr.o.o: assym.h
+cpuswitch.o exception.o support.o: assym.h
+locore.o trampoline.o: assym.h
 
 hardlink-obsd:
[[ ! -f /bsd ]] || cmp -s bsd /bsd || ln -f /bsd /obsd



armv7: unused/useless residue

2018-03-04 Thread Artturi Alm
Hi,

these should still belong to history.

-Artturi


diff --git sys/arch/arm/arm/bus_dma.c sys/arch/arm/arm/bus_dma.c
index 231951c7262..14f643b7697 100644
--- sys/arch/arm/arm/bus_dma.c
+++ sys/arch/arm/arm/bus_dma.c
@@ -751,8 +751,7 @@ _bus_dmamap_sync(bus_dma_tag_t t, bus_dmamap_t map, 
bus_addr_t offset,
 * vmspace has not been active since the last time a full
 * cache flush was performed, we don't need to do anything.
 */
-   if (__predict_false(map->_dm_proc != NULL &&
-   map->_dm_proc->p_vmspace->vm_map.pmap->pm_cstate.cs_cache_d == 0))
+   if (__predict_false(map->_dm_proc != NULL))
return;
 
switch (map->_dm_buftype) {
diff --git sys/arch/arm/arm/genassym.cf sys/arch/arm/arm/genassym.cf
index 3937b930c39..c6f6d097476 100644
--- sys/arch/arm/arm/genassym.cf
+++ sys/arch/arm/arm/genassym.cf
@@ -61,7 +61,6 @@ define__ARM_FIQ_INDIRECT  1
 endif
 
 export DOMAIN_CLIENT
-export PMAP_DOMAIN_KERNEL
 
 ifdef PMAP_INCLUDE_PTE_SYNC
 define PMAP_INCLUDE_PTE_SYNC   1
@@ -86,8 +85,6 @@ memberpcb_tf
 member pcb_pagedir
 member pcb_pl1vec
 member pcb_l1vec
-member pcb_dacr
-member pcb_cstate
 member pcb_flags
 member PCB_R8  pcb_un.un_32.pcb32_r8
 member PCB_R9  pcb_un.un_32.pcb32_r9
@@ -112,18 +109,6 @@ struct vmspace
 member vm_map
 member VM_PMAP vm_map.pmap
 
-union  pmap_cache_state
-member cs_tlb_id
-member cs_tlb_d
-member cs_tlb
-member cs_cache_id
-member cs_cache_d
-member cs_cache
-member cs_all
-
-struct pmap
-member PMAP_CSTATE pm_cstate
-
 struct uprof
 member pr_base
 member pr_size
diff --git sys/arch/arm/include/pcb.h sys/arch/arm/include/pcb.h
index fc43b1c9a21..ffef2fb59d8 100644
--- sys/arch/arm/include/pcb.h
+++ sys/arch/arm/include/pcb.h
@@ -48,8 +48,6 @@ struct pcb_arm32 {
paddr_t pcb32_pagedir;  /* PT hooks */
pd_entry_t *pcb32_pl1vec;   /* PTR to vector_base L1 entry*/
pd_entry_t pcb32_l1vec; /* Value to stuff on ctx sw */
-   u_int   pcb32_dacr; /* Domain Access Control Reg */
-   void*pcb32_cstate;  /* &pmap->pm_cstate */
/*
 * WARNING!
 * cpuswitch.S relies on pcb32_r8 being quad-aligned in struct pcb
@@ -68,8 +66,6 @@ struct pcb_arm32 {
 #definepcb_pagedir pcb_un.un_32.pcb32_pagedir
 #definepcb_pl1vec  pcb_un.un_32.pcb32_pl1vec
 #definepcb_l1vec   pcb_un.un_32.pcb32_l1vec
-#definepcb_dacrpcb_un.un_32.pcb32_dacr
-#definepcb_cstate  pcb_un.un_32.pcb32_cstate
 
 /*
  * WARNING!
diff --git sys/arch/arm/include/pmap.h sys/arch/arm/include/pmap.h
index 83c3395f710..162f0a45835 100644
--- sys/arch/arm/include/pmap.h
+++ sys/arch/arm/include/pmap.h
@@ -124,55 +124,11 @@
 struct l1_ttable;
 struct l2_dtable;
 
-/*
- * Track cache/tlb occupancy using the following structure
- */
-union pmap_cache_state {
-   struct {
-   union {
-   u_int8_t csu_cache_b[2];
-   u_int16_t csu_cache;
-   } cs_cache_u;
-
-   union {
-   u_int8_t csu_tlb_b[2];
-   u_int16_t csu_tlb;
-   } cs_tlb_u;
-   } cs_s;
-   u_int32_t cs_all;
-};
-#definecs_cache_id cs_s.cs_cache_u.csu_cache_b[0]
-#definecs_cache_d  cs_s.cs_cache_u.csu_cache_b[1]
-#definecs_cachecs_s.cs_cache_u.csu_cache
-#definecs_tlb_id   cs_s.cs_tlb_u.csu_tlb_b[0]
-#definecs_tlb_dcs_s.cs_tlb_u.csu_tlb_b[1]
-#definecs_tlb  cs_s.cs_tlb_u.csu_tlb
-
-/*
- * Assigned to cs_all to force cacheops to work for a particular pmap
- */
-#definePMAP_CACHE_STATE_ALL0xu
-
-/*
- * This structure is used by machine-dependent code to describe
- * static mappings of devices, created at bootstrap time.
- */
-struct pmap_devmap {
-   vaddr_t pd_va;  /* virtual address */
-   paddr_t pd_pa;  /* physical address */
-   psize_t pd_size;/* size of region */
-   vm_prot_t   pd_prot;/* protection code */
-   int pd_cache;   /* cache attributes */
-};
-
 /*
  * The pmap structure itself
  */
 struct pmap {
-   u_int8_tpm_domain;
-   boolean_t   pm_remove_all;
struct l1_ttable*pm_l1;
-   union pmap_cache_state  pm_cstate;
u_int   pm_refs;
struct l2_dtable*pm_l2[L2_SIZE];
struct pmap_statistics  pm_stats;
@@ -274,16 +230,11 @@ void  vector_page_setprot(int);
 /* XXX */
 void pmap_kenter_cache(vaddr_t va, paddr_t pa, vm_prot_t prot, int cacheable);
 
-const struct pmap_devmap *pmap_devmap_find_pa(paddr_t, psize_t);
-const struct pmap_devmap *pmap_devmap_find_va(vaddr_t, vsize_t);
-
 /* Bootstrappin

cwm: window-h|vhalve

2018-01-23 Thread Artturi Alm
Hi,

quite primitive features, but until cwmrc parsing grows to support passing
arguments with binds(i jk:P), these cover some cases for binary minded ppl
partitioning the available pixels for use:)

Comments?
I left out man page bits on purpose, but this works with ie.:
bind-key C4-h window-hhalve
bind-key C4-v window-vhalve

-Artturi


diff --git a/app/cwm/calmwm.h b/app/cwm/calmwm.h
index 300632cdc..1335bce88 100644
--- a/app/cwm/calmwm.h
+++ b/app/cwm/calmwm.h
@@ -64,6 +64,8 @@
 #define CWM_DOWN_RIGHT (CWM_DOWN | CWM_RIGHT)
 #define CWM_DOWN_LEFT  (CWM_DOWN | CWM_LEFT)
 #define DIRECTIONMASK  (CWM_UP | CWM_DOWN | CWM_LEFT | CWM_RIGHT)
+#define CWM_HORIZONTAL 0x0020
+#define CWM_VERTICAL   0x0040
 
 #define CWM_CYCLE_FORWARD  0x0001
 #define CWM_CYCLE_REVERSE  0x0002
@@ -400,6 +402,7 @@ void client_draw_border(struct 
client_ctx *);
 struct client_ctx  *client_find(Window);
 longclient_get_wm_state(struct client_ctx *);
 voidclient_getsizehints(struct client_ctx *);
+voidclient_halve(struct client_ctx *, int);
 voidclient_hide(struct client_ctx *);
 voidclient_htile(struct client_ctx *);
 voidclient_lower(struct client_ctx *);
@@ -497,6 +500,8 @@ void 
kbfunc_client_toggle_fullscreen(void *,
 voidkbfunc_client_toggle_maximize(void *, struct cargs *);
 voidkbfunc_client_toggle_hmaximize(void *, struct cargs *);
 voidkbfunc_client_toggle_vmaximize(void *, struct cargs *);
+voidkbfunc_client_hhalve(void *, struct cargs *);
+voidkbfunc_client_vhalve(void *, struct cargs *);
 voidkbfunc_client_htile(void *, struct cargs *);
 voidkbfunc_client_vtile(void *, struct cargs *);
 voidkbfunc_client_cycle(void *, struct cargs *);
diff --git a/app/cwm/client.c b/app/cwm/client.c
index 11eac06c4..be7d16cd6 100644
--- a/app/cwm/client.c
+++ b/app/cwm/client.c
@@ -966,6 +966,28 @@ client_snapcalc(int n0, int n1, int e0, int e1, int 
snapdist)
return(0);
 }
 
+void
+client_halve(struct client_ctx *cc, int direction)
+{
+
+   if (cc->flags & CLIENT_FREEZE)
+   return;
+
+   switch (direction) {
+   case CWM_HORIZONTAL:
+   cc->geom.w /= 2;
+   break;
+   case CWM_VERTICAL:
+   cc->geom.h /= 2;
+   break;
+   default:
+   return;
+   }
+
+   client_resize(cc, 0);
+   xu_ewmh_set_net_wm_state(cc);
+}
+
 void
 client_htile(struct client_ctx *cc)
 {
diff --git a/app/cwm/conf.c b/app/cwm/conf.c
index 790daa2a0..235b7cc60 100644
--- a/app/cwm/conf.c
+++ b/app/cwm/conf.c
@@ -69,6 +69,8 @@ static const struct {
{ FUNC_CC(window-raise, client_raise, 0) },
{ FUNC_CC(window-hide, client_hide, 0) },
{ FUNC_CC(window-delete, client_delete, 0) },
+   { FUNC_CC(window-hhalve, client_hhalve, 0) },
+   { FUNC_CC(window-vhalve, client_vhalve, 0) },
{ FUNC_CC(window-htile, client_htile, 0) },
{ FUNC_CC(window-vtile, client_vtile, 0) },
{ FUNC_CC(window-stick, client_toggle_sticky, 0) },
diff --git a/app/cwm/kbfunc.c b/app/cwm/kbfunc.c
index 7a205d0ff..d6f0d6e4b 100644
--- a/app/cwm/kbfunc.c
+++ b/app/cwm/kbfunc.c
@@ -395,6 +395,18 @@ kbfunc_client_vtile(void *ctx, struct cargs *cargs)
client_vtile(ctx);
 }
 
+void
+kbfunc_client_hhalve(void *ctx, struct cargs *cargs)
+{
+   client_halve(ctx, CWM_HORIZONTAL);
+}
+
+void
+kbfunc_client_vhalve(void *ctx, struct cargs *cargs)
+{
+   client_halve(ctx, CWM_VERTICAL);
+}
+
 void
 kbfunc_client_cycle(void *ctx, struct cargs *cargs)
 {



Re: MI mutex

2018-01-23 Thread Artturi Alm
On Tue, Jan 23, 2018 at 06:14:31PM +0100, Martin Pieuchot wrote:
> On 23/01/18(Tue) 18:10, Mark Kettenis wrote:
> > > Date: Tue, 23 Jan 2018 14:06:08 +
> > > From: Visa Hankala 
> > > 
> > > On Mon, Jan 22, 2018 at 11:12:13AM +0100, Martin Pieuchot wrote:
> > > > Diff below moves the common mutex implementation to kern/ and enable it 
> > > > for
> > > > alpha, amd64, arm64, i386, mips64, powerpc.
> > > 
> > > Your diff seems to miss the necessary bits in .
> > > In addition, you should put the common mutex code into kern_mutex.c.
> > > Lets keep kern_lock.c for the mplock only.

got me thinking "Why?", but i'm not sure where i've got the impression
that aiming towards GENERIC == GENERIC.MP is/was desirable direction.

> > 
> > Right.  I believe kern_lock.c is only included in NULTIPROCESSOR kernels.
> 
> It is not, however kern_mutex.c is only included in WITNESS kernels.
> 

just noise:)
-Artturi



Re: /etc/rc: fsck -y

2018-01-18 Thread Artturi Alm
On Thu, Jan 18, 2018 at 12:13:54PM +0100, Otto Moerbeek wrote:
> On Thu, Jan 18, 2018 at 12:12:39PM +0200, Artturi Alm wrote:
> 
> > Hi,
> > 
> > i think i've never answered "n" to fsck, so to me the lack of -y does
> > mean unnecessary work/boards/VMs left waiting for the F..
> > 
> > i would use something like this if it was there:
> > 
> > diff --git a/etc/rc b/etc/rc
> > index c88e13ce7ab..e3a269be818 100644
> > --- a/etc/rc
> > +++ b/etc/rc
> > @@ -349,7 +349,11 @@ if [[ -e /fastboot ]]; then
> > echo "Fast boot: skipping disk checks."
> >  elif [[ $1 == autoboot ]]; then
> > echo "Automatic boot in progress: starting file system checks."
> > -   do_fsck
> > +   if [[ -e /failboot ]]; then
> > +   do_fsck
> > +   else
> > +   do_fsck -y
> > +   fi
> >  fi
> >  
> >  # From now on, allow user to interrupt (^C) the boot process.
> > 
> > 
> > but the one below is what i believe should fit&go w/modern sane defaults
> > (think terabytes).
> > no man page diffs, as i guess this won't fly (w/o bikeshedding atleast).
> > -Artturi
> > 
> > 
> > diff --git a/etc/rc b/etc/rc
> > index c88e13ce7ab..e3a269be818 100644
> > --- a/etc/rc
> > +++ b/etc/rc
> > @@ -349,7 +349,11 @@ if [[ -e /fastboot ]]; then
> > echo "Fast boot: skipping disk checks."
> >  elif [[ $1 == autoboot ]]; then
> > echo "Automatic boot in progress: starting file system checks."
> > -   do_fsck
> > +   if [[ -e /failboot ]]; then
> > +   do_fsck
> > +   else
> > +   do_fsck -y
> > +   fi
> >  fi
> >  
> >  # From now on, allow user to interrupt (^C) the boot process.
> 
> This has come up before and is not ok.
> It is dangerous becuase it might make things worse.
> 
> I want to have a chanche to e.g. save an image or chack cabling.
> 
> Again, no.
> 
>   -Otto

Ok, anyway the first diff was supposed to be this:

diff --git a/etc/rc b/etc/rc
index c88e13ce7ab..c8a25da7b42 100644
--- a/etc/rc
+++ b/etc/rc
@@ -349,7 +349,11 @@ if [[ -e /fastboot ]]; then
echo "Fast boot: skipping disk checks."
 elif [[ $1 == autoboot ]]; then
echo "Automatic boot in progress: starting file system checks."
-   do_fsck
+   if [[ -e /forceboot ]]; then
+   do_fsck -y
+   else
+   do_fsck
+   fi
 fi
 
 # From now on, allow user to interrupt (^C) the boot process.


so only giving user the choice of not editing /etc/rc.
fwiw. i heard FreeBSD has variable named "fsck_y_enable",
but i'm useless w/shell scripts, so i chose above..
-Artturi



/etc/rc: fsck -y

2018-01-18 Thread Artturi Alm
Hi,

i think i've never answered "n" to fsck, so to me the lack of -y does
mean unnecessary work/boards/VMs left waiting for the F..

i would use something like this if it was there:

diff --git a/etc/rc b/etc/rc
index c88e13ce7ab..e3a269be818 100644
--- a/etc/rc
+++ b/etc/rc
@@ -349,7 +349,11 @@ if [[ -e /fastboot ]]; then
echo "Fast boot: skipping disk checks."
 elif [[ $1 == autoboot ]]; then
echo "Automatic boot in progress: starting file system checks."
-   do_fsck
+   if [[ -e /failboot ]]; then
+   do_fsck
+   else
+   do_fsck -y
+   fi
 fi
 
 # From now on, allow user to interrupt (^C) the boot process.


but the one below is what i believe should fit&go w/modern sane defaults
(think terabytes).
no man page diffs, as i guess this won't fly (w/o bikeshedding atleast).
-Artturi


diff --git a/etc/rc b/etc/rc
index c88e13ce7ab..e3a269be818 100644
--- a/etc/rc
+++ b/etc/rc
@@ -349,7 +349,11 @@ if [[ -e /fastboot ]]; then
echo "Fast boot: skipping disk checks."
 elif [[ $1 == autoboot ]]; then
echo "Automatic boot in progress: starting file system checks."
-   do_fsck
+   if [[ -e /failboot ]]; then
+   do_fsck
+   else
+   do_fsck -y
+   fi
 fi
 
 # From now on, allow user to interrupt (^C) the boot process.



Re: urndis0: urndis_decap invalid buffer len 1 < minimum header 44

2018-01-10 Thread Artturi Alm
On Wed, Sep 13, 2017 at 05:51:27AM +0300, Artturi Alm wrote:
> Hi,
> 
> even after having recently updated the phone to a newer version of android,
> i'm still spammed by urndis w/msg on subject.
> 
> doesn't really matter to me what you do to silence it, but something like
> below does work for me, and thanks in advacne:)
> -Artturi
> 

ping?
i was told i don't reason my diffs, so here's sorry attempt:
$ dmesg | wc -l
1040
$ dmesg | grep urndis_decap | wc -l
1039

either of the diffs below would work for me.
-Artturi


... this ...

diff --git a/sys/dev/usb/if_urndis.c b/sys/dev/usb/if_urndis.c
index 5d148da4ab5..7dc12573c0d 100644
--- a/sys/dev/usb/if_urndis.c
+++ b/sys/dev/usb/if_urndis.c
@@ -834,11 +834,11 @@ urndis_decap(struct urndis_softc *sc, struct urndis_chain 
*c, u_int32_t len)
len));
 
if (len < sizeof(*msg)) {
-   printf("%s: urndis_decap invalid buffer len %u < "
+   DPRINTF(("%s: urndis_decap invalid buffer len %u < "
"minimum header %zu\n",
DEVNAME(sc),
len,
-   sizeof(*msg));
+   sizeof(*msg)));
return;
}
 


... or this ...

diff --git a/sys/dev/usb/if_urndis.c b/sys/dev/usb/if_urndis.c
index 5d148da4ab5..4b2c6e89ec9 100644
--- a/sys/dev/usb/if_urndis.c
+++ b/sys/dev/usb/if_urndis.c
@@ -834,6 +834,8 @@ urndis_decap(struct urndis_softc *sc, struct urndis_chain 
*c, u_int32_t len)
len));
 
if (len < sizeof(*msg)) {
+   if (len == 1)   /* workaround for spamming androids */
+   return;
printf("%s: urndis_decap invalid buffer len %u < "
"minimum header %zu\n",
DEVNAME(sc),



Re: cu: loop over cua00-09+cuaU0-U9

2018-01-09 Thread Artturi Alm
On Tue, Jan 09, 2018 at 01:44:04PM -0700, Theo de Raadt wrote:
> No way.
> 
> No justification provided for anyone to want this feature.
> 

Np, this is just what i want this for:

ucom0 at uchcom0
ucom1 at uplcom0
ucom2 at uslcom0 portno 0
ucom3 at uftdi0 portno 1
ucom4 at uftdi1 portno 1
ucom5 at uftdi2 portno 1
ucom6 at uftdi3 portno 1
ucom7 at uftdi4 portno 1
ucom8 at umodem0

$ usbdevs   
addr 1: xHCI root hub, NEC
 addr 2: Cypress USB Keyboard / PS2 Mouse, Cypress
 addr 3: Razer Naga Hex, Razer
addr 1: EHCI root hub, NEC
addr 1: OHCI root hub, NEC
 addr 2: USB Hub 2.0, ALCOR
  addr 3: USB Hub 2.0, ALCOR
   addr 4: CH340 serial/parallel, QinHeng Electronics
   addr 5: USB-Serial Controller, Prolific Technology Inc.
   addr 6: CP2104 USB to UART Bridge Controller, Silicon Labs
  addr 7: FT232R USB UART, FTDI
 addr 8: USB Hub 2.0, ALCOR
  addr 9: USB Hub 2.0, ALCOR
   addr 10: FT232R USB UART, FTDI
   addr 11: FT232R USB UART, FTDI
   addr 12: FT232R USB UART, FTDI
  addr 13: FT232R USB UART, FTDI
  addr 14: STM32 STLink, STMicroelectronics


and here's how it looks when working:

$ ./cu -115200
cu: open("/dev/cua00"): Device busy
cu: open("/dev/cua00"): Device busy
cu: open("/dev/cua01"): Device not configured
cu: open("/dev/cua02"): Device not configured
cu: open("/dev/cua03"): Device not configured
cu: open("/dev/cua04"): Device not configured
cu: open("/dev/cua05"): Device not configured
cu: open("/dev/cua06"): Device not configured
cu: open("/dev/cua07"): Device not configured
cu: open("/dev/cua08"): Device not configured
cu: open("/dev/cua09"): Device not configured
cu: open("/dev/cuaU0"): Device busy
Connected to /dev/cuaU1 (speed 115200)

av7bbb#
av7bbb#
[EOT]

 $
 $ ./cu -115200 -l cua00
cu: open("/dev/cua00"): Device busy
 $ cu -115200 -l cuaU2
cu: open("/dev/cuaU2"): Device busy
 $



cu: loop over cua00-09+cuaU0-U9

2018-01-09 Thread Artturi Alm
Hi,

maybe someone else does find this usable :)
will loop to find the first available cua line unless -r or line_path
chosen before open(), so this does not really change the mostly
expected behaviour i can think of; only does make cua00 little less special.

-Artturi


diff --git a/usr.bin/cu/cu.c b/usr.bin/cu/cu.c
index 03a2df4181f..b4b07a924c6 100644
--- a/usr.bin/cu/cu.c
+++ b/usr.bin/cu/cu.c
@@ -44,6 +44,7 @@ struct bufferevent*output_ev;
 int is_direct = -1;
 int restricted = 0;
 const char *line_path = NULL;
+int line_loop = 0;
 int line_speed = -1;
 int line_fd;
 struct termios  line_tio;
@@ -149,8 +150,10 @@ main(int argc, char **argv)
}
}
 
-   if (line_path == NULL)
-   line_path = "/dev/cua00";
+   if (line_path == NULL) {
+   line_path = "cua00";
+   line_loop = restricted ? 0 : 1;
+   }
if (line_speed == -1)
line_speed = 9600;
if (is_direct == -1)
@@ -165,7 +168,18 @@ main(int argc, char **argv)
flags = O_RDWR;
if (is_direct)
flags |= O_NONBLOCK;
-   line_fd = open(line_path, flags);
+   for (;;) {
+   line_fd = open(line_path, flags);
+   if (!(line_fd < 0) || line_loop == 0 || line_loop > 20)
+   break;
+   warn("open(\"%s\")", line_path);
+   free(line_path);
+   if (asprintf(&line_path, "%s%s%d", _PATH_DEV,
+   line_loop < 11 ? "cua0" : "cuaU",
+   line_loop - (line_loop < 11 ? 1 : 11)) == -1)
+   err(1, "asprintf");
+   line_loop++;
+   }
if (line_fd < 0)
err(1, "open(\"%s\")", line_path);
if (restricted && pledge("stdio tty", NULL) == -1)



av7/imx: maybe _SD_

2018-01-07 Thread Artturi Alm
Hi,

unsure about if the _MMC_HIGHSPEED is used at all,
but to keep this ++ i didn't touch it.

because of the bugged fec; i will not test this.
-Artturi


diff --git a/sys/arch/armv7/imx/imxesdhc.c b/sys/arch/armv7/imx/imxesdhc.c
index 8414dedcb37..0e951af6073 100644
--- a/sys/arch/armv7/imx/imxesdhc.c
+++ b/sys/arch/armv7/imx/imxesdhc.c
@@ -432,6 +432,8 @@ imxesdhc_attach(struct device *parent, struct device *self, 
void *aux)

if (caps & SDHC_HOST_CTRL_CAP_HSS)
saa.caps |= SMC_CAPS_MMC_HIGHSPEED;
+   if (caps & SDHC_HOST_CTRL_CAP_HSS)
+   saa.caps |= SMC_CAPS_SD_HIGHSPEED;
 
width = OF_getpropint(sc->sc_node, "bus-width", 1);
if (width >= 8)



Re: /etc/services: two missing ports

2018-01-05 Thread Artturi Alm
On Fri, Jan 05, 2018 at 08:17:42PM -0700, Theo de Raadt wrote:
> We've been avoiding polluting services with absolutely every joke
> of a service.  If we added everything, it would be a disaster that
> we have to manage and we don't want to.
>

Ok, no problem, yet asking again, now with some maintenance included.

> You've hit on one of the two services we've watched over the years
> as markers between "registered" and "not registered".
> 

Then how about under unofficials?

> Have you found an application which does not know to use this
> unregistered?
> 

No, just netstat.

> As for what netstat reports, you big boys can handle that being
> just a number.  That's why it prints numbers instead of blank space.
> 
> 

been over 20years since i first connected to irc, and it was on 6667.
i never knew about port 194, but am very sure it will never listen on udp.
so i think those two should go, even if latter won't get in.

slightly tested diff below; no vax was punished by the growth of services.
-Artturi


diff --git a/etc/services b/etc/services
index ceb2b58c17d..172db3609f3 100644
--- a/etc/services
+++ b/etc/services
@@ -103,8 +103,6 @@ bgp 179/tcp # Border 
Gateway Proto.
 bgp179/udp
 prospero   191/tcp # Cliff Neuman's Prospero
 prospero   191/udp
-irc194/tcp # Internet Relay Chat
-irc194/udp
 smux   199/tcp # SNMP Unix Multiplexer
 smux   199/udp
 at-rtmp201/tcp # AppleTalk routing
@@ -321,6 +319,8 @@ webster 2627/tcp# 
Network dictionary
 conserver  3109/tcp# console server
 canna  5680/tcp# Kana->Kanji server
 sane-port  6566/tcp# SANE Control Port
+irc6667/tcp# Internet Relay Chat
+irc6697/tcp# IRC over SSL
 icb7326/tcp# Internet Citizen's Band
 spamd  8025/tcp# spamd(8)
 spamd-sync 8025/udp# spamd(8) synchronisation



/etc/services: two missing ports

2018-01-05 Thread Artturi Alm
Hi,

i don't know if anyone uses 6667 anymore, but adding it anyway
so the abbreviated one below w/" over SSL" does make more sense.
usually for me 6697 is the only port unrecognized by services(5)
in netstat output under Foreign Address, so this is for consistency,
and i believe these are official.

-Artturi


diff --git a/etc/services b/etc/services
index ceb2b58c17d..146876ce065 100644
--- a/etc/services
+++ b/etc/services
@@ -262,6 +262,8 @@ postgresql  5432/tcp# PostgreSQL
 postgresql 5432/udp# PostgreSQL
 rfb5900/tcpvnc # Remote Framebuffer
 syslog-tls 6514/tcp# syslog over TLS
+irc6667/tcp# Internet Relay Chat
+irc6697/tcp# IRC over SSL
 afs3-fileserver7000/tcp# AFS fileserver
 afs3-fileserver7000/udp# AFS fileserver
 afs3-callback  7001/tcp# AFS callback server



Re: sdhc: support ext dma

2017-12-31 Thread Artturi Alm
On Sun, Dec 31, 2017 at 01:12:42PM +0100, Mark Kettenis wrote:
> > Date: Sun, 31 Dec 2017 13:46:44 +0200
> > From: Artturi Alm 
> > 
> > On Sat, Dec 30, 2017 at 08:39:42PM +0200, Artturi Alm wrote:
> > > Hi,
> > > 
> > > porting sdhc driver(bcm2835_emmc.c) from NetBSD does lack something
> > > like this, among possibly few other (small?) changes, but consider this
> > > as a step towards.
> > > 
> > > Comments? to keep changes minimal/safe/easy to review like below, or to
> > > backport in bigger chunks?
> > > 
> > > -Artturi
> > > 
> > 
> > Hi,
> > 
> > while working out the second step i came to a conclusion,
> > that the diff should work in theory like below,
> > and be easier to review w/o the use of SHF_USE_DMA flag.
> > 
> > any comments?
> 
> Is the BCM2835 hardware really a standard SDHC controller?  If there
> are too many quirks, I tend to prefer a seperate driver instead of a
> bit of SoC-specific glue for shdc(4).
> 
> Otherwise this mostly makes sense to me as infrastructure to use an
> external DMA controller.  I don't think we should at it unless there
> is an actual user though.
> 
> Cheers,
> 
> Mark
>

not counting non-ADMA2 DMA support, to me it seems to be.

+ ofc. the usual access width restrictions, which the diff below does
aim to 'fix', but no register-offset quirks needed or anything ugly like
for freescale e/usdhc.

bcm2835_dmac.c was rather mechanical to port, so the user for ext dma
does exist already, just unpolished/tested (and lacking dev/ofw/ofw_dmac.h,
for standard bindings:).

spent some extra effort to keep this a +++ diff :)

-Artturi


 sys/dev/sdmmc/sdhc.c| 256 
 sys/dev/sdmmc/sdhcvar.h |   1 +
 2 files changed, 257 insertions(+)


diff --git a/sys/dev/sdmmc/sdhc.c b/sys/dev/sdmmc/sdhc.c
index c242a600d4a..b8365581bef 100644
--- a/sys/dev/sdmmc/sdhc.c
+++ b/sys/dev/sdmmc/sdhc.c
@@ -61,6 +61,33 @@ struct sdhc_host {
 /* flag values */
 #define SHF_USE_DMA0x0001
 
+#ifdef SDHC_VARIABLE_BSACW
+static inline uint8_t  hread1(struct sdhc_host *, bus_size_t);
+static inline uint16_t hread2(struct sdhc_host *, bus_size_t);
+static inline void hwrite1(struct sdhc_host *, bus_size_t, uint8_t);
+static inline void hwrite2(struct sdhc_host *, bus_size_t, uint16_t);
+
+#define HREAD1(hp, reg)hread1(hp, reg)
+#define HREAD2(hp, reg)hread2(hp, reg)
+#define HREAD4(hp, reg)
\
+   (bus_space_read_4((hp)->iot, (hp)->ioh, (reg)))
+#define HWRITE1(hp, reg, val)  hwrite1(hp, reg, val)
+#define HWRITE2(hp, reg, val)  hwrite2(hp, reg, val)
+#define HWRITE4(hp, reg, val)  \
+   bus_space_write_4((hp)->iot, (hp)->ioh, (reg), (val))
+#define HCLR1(hp, reg, b)  \
+   do if (b) HWRITE1((hp), (reg), HREAD1((hp), (reg)) & ~(b)); while (0)
+#define HCLR2(hp, reg, b)  \
+   do if (b) HWRITE2((hp), (reg), HREAD2((hp), (reg)) & ~(b)); while (0)
+#define HCLR4(hp, reg, b)  \
+   do if (b) HWRITE4((hp), (reg), HREAD4((hp), (reg)) & ~(b)); while (0)
+#define HSET1(hp, reg, b)  \
+   do if (b) HWRITE1((hp), (reg), HREAD1((hp), (reg)) | (b)); while (0)
+#define HSET2(hp, reg, b)  \
+   do if (b) HWRITE2((hp), (reg), HREAD2((hp), (reg)) | (b)); while (0)
+#define HSET4(hp, reg, b)  \
+   do if (b) HWRITE4((hp), (reg), HREAD4((hp), (reg)) | (b)); while (0)
+#else
 #define HREAD1(hp, reg)
\
(bus_space_read_1((hp)->iot, (hp)->ioh, (reg)))
 #define HREAD2(hp, reg)
\
@@ -77,10 +104,15 @@ struct sdhc_host {
HWRITE1((hp), (reg), HREAD1((hp), (reg)) & ~(bits))
 #define HCLR2(hp, reg, bits)   \
HWRITE2((hp), (reg), HREAD2((hp), (reg)) & ~(bits))
+#define HCLR4(hp, reg, bits)   \
+   HWRITE4((hp), (reg), HREAD4((hp), (reg)) & ~(bits))
 #define HSET1(hp, reg, bits)   \
HWRITE1((hp), (reg), HREAD1((hp), (reg)) | (bits))
 #define HSET2(hp, reg, bits)   \
HWRITE2((hp), (reg), HREAD2((hp), (reg)) | (bits))
+#define HSET4(hp, reg, bits)   \
+   HWRITE4((hp), (reg), HREAD4((hp), (reg)) | (bits))
+#endif /* !SDHC_VARIABLE_BSACW *

Re: sdhc: support ext dma

2017-12-31 Thread Artturi Alm
On Sat, Dec 30, 2017 at 08:39:42PM +0200, Artturi Alm wrote:
> Hi,
> 
> porting sdhc driver(bcm2835_emmc.c) from NetBSD does lack something
> like this, among possibly few other (small?) changes, but consider this
> as a step towards.
> 
> Comments? to keep changes minimal/safe/easy to review like below, or to
> backport in bigger chunks?
> 
> -Artturi
> 

Hi,

while working out the second step i came to a conclusion,
that the diff should work in theory like below,
and be easier to review w/o the use of SHF_USE_DMA flag.

any comments?

-Artturi


diff --git a/sys/dev/sdmmc/sdhc.c b/sys/dev/sdmmc/sdhc.c
index c242a600d4a..f65790ff581 100644
--- a/sys/dev/sdmmc/sdhc.c
+++ b/sys/dev/sdmmc/sdhc.c
@@ -187,6 +187,10 @@ sdhc_host_found(struct sdhc_softc *sc, bus_space_tag_t iot,
/* Use DMA if the host system and the controller support it. */
if (usedma && ISSET(caps, SDHC_ADMA2_SUPP))
SET(hp->flags, SHF_USE_DMA);
+   if (!usedma)
+   sc->sc_extdma_transfer = NULL;
+   else if (sc->sc_extdma_transfer)
+   CLR(hp->flags, SHF_USE_DMA);
 
/*
 * Determine the base clock frequency. (2.2.24)
@@ -302,6 +306,8 @@ sdhc_host_found(struct sdhc_softc *sc, bus_space_tag_t iot,
saa.dmat = sc->sc_dmat;
if (ISSET(hp->flags, SHF_USE_DMA))
saa.caps |= SMC_CAPS_DMA;
+   else if (sc->sc_extdma_transfer)
+   saa.caps |= SMC_CAPS_DMA;
 
if (ISSET(caps, SDHC_HIGH_SPEED_SUPP))
saa.caps |= SMC_CAPS_SD_HIGHSPEED;
@@ -939,6 +945,16 @@ sdhc_transfer_data(struct sdhc_host *hp, struct 
sdmmc_command *cmd)
if (cmd->c_dmamap) {
int status;
 
+   if (sc->sc_extdma_transfer != NULL) {
+   error = sc->sc_extdma_transfer(sc, cmd);
+   if (error == 0 && !sdhc_wait_intr(hp,
+   SDHC_TRANSFER_COMPLETE, SDHC_DMA_TIMEOUT)) {
+   DPRINTF(1,("%s: timeout\n", __func__));
+   error = ETIMEDOUT;
+   }
+   goto done;
+   }
+
error = 0;
for (;;) {
status = sdhc_wait_intr(hp,
diff --git a/sys/dev/sdmmc/sdhcvar.h b/sys/dev/sdmmc/sdhcvar.h
index 9d4d759a2bc..5c0f462cfe6 100644
--- a/sys/dev/sdmmc/sdhcvar.h
+++ b/sys/dev/sdmmc/sdhcvar.h
@@ -22,6 +22,7 @@
 #include 
 
 struct sdhc_host;
+struct sdmmc_command;
 
 struct sdhc_softc {
struct device sc_dev;
@@ -33,6 +34,7 @@ struct sdhc_softc {
 
int (*sc_card_detect)(struct sdhc_softc *);
int (*sc_signal_voltage)(struct sdhc_softc *, int);
+   int (*sc_extdma_transfer)(struct sdhc_softc *, struct sdmmc_command *);
 };
 
 /* Host controller functions called by the attachment driver. */



sdhc: support ext dma

2017-12-30 Thread Artturi Alm
Hi,

porting sdhc driver(bcm2835_emmc.c) from NetBSD does lack something
like this, among possibly few other (small?) changes, but consider this
as a step towards.

Comments? to keep changes minimal/safe/easy to review like below, or to
backport in bigger chunks?

-Artturi


diff --git a/sys/dev/sdmmc/sdhc.c b/sys/dev/sdmmc/sdhc.c
index c242a600d4a..45789ac15b0 100644
--- a/sys/dev/sdmmc/sdhc.c
+++ b/sys/dev/sdmmc/sdhc.c
@@ -187,6 +187,10 @@ sdhc_host_found(struct sdhc_softc *sc, bus_space_tag_t iot,
/* Use DMA if the host system and the controller support it. */
if (usedma && ISSET(caps, SDHC_ADMA2_SUPP))
SET(hp->flags, SHF_USE_DMA);
+   if (!usedma || ISSET(caps, SDHC_ADMA2_SUPP))
+   hp->sc_transfer_dma = NULL;
+   else if (usedma && sc->sc_transfer_dma)
+   SET(hp->flags, SHF_USE_DMA);
 
/*
 * Determine the base clock frequency. (2.2.24)
@@ -250,7 +254,7 @@ sdhc_host_found(struct sdhc_softc *sc, bus_space_tag_t iot,
break;
}
 
-   if (ISSET(hp->flags, SHF_USE_DMA)) {
+   if (ISSET(hp->flags, SHF_USE_DMA) && sc->sc_transfer_dma == NULL) {
int rseg;
 
/* Allocate ADMA2 descriptor memory */
@@ -939,6 +943,16 @@ sdhc_transfer_data(struct sdhc_host *hp, struct 
sdmmc_command *cmd)
if (cmd->c_dmamap) {
int status;
 
+   if (sc->sc_transfer_dma != NULL) {
+   error = sc->sc_transfer_dma(sc, cmd);
+   if (error == 0 && !sdhc_wait_intr(hp,
+   SDHC_TRANSFER_COMPLETE, SDHC_DMA_TIMEOUT)) {
+   DPRINTF(1,("%s: timeout\n", __func__));
+   error = ETIMEDOUT;
+   }
+   goto done;
+   }
+
error = 0;
for (;;) {
status = sdhc_wait_intr(hp,
diff --git a/sys/dev/sdmmc/sdhcvar.h b/sys/dev/sdmmc/sdhcvar.h
index 9d4d759a2bc..aa5977a4c7d 100644
--- a/sys/dev/sdmmc/sdhcvar.h
+++ b/sys/dev/sdmmc/sdhcvar.h
@@ -22,6 +22,7 @@
 #include 
 
 struct sdhc_host;
+struct sdmmc_command;
 
 struct sdhc_softc {
struct device sc_dev;
@@ -33,6 +34,7 @@ struct sdhc_softc {
 
int (*sc_card_detect)(struct sdhc_softc *);
int (*sc_signal_voltage)(struct sdhc_softc *, int);
+   int (*sc_transfer_dma)(struct sdhc_softc *, struct sdmmc_command *);
 };
 
 /* Host controller functions called by the attachment driver. */



arm/sxitwi: dup includes

2017-12-28 Thread Artturi Alm
Hi,

sxitwi got thru lazy review.

-Artturi


diff --git a/sys/dev/fdt/sxitwi.c b/sys/dev/fdt/sxitwi.c
index 099f394823f..9e19812e6bd 100644
--- a/sys/dev/fdt/sxitwi.c
+++ b/sys/dev/fdt/sxitwi.c
@@ -71,10 +71,6 @@
 #include 
 #include 
 
-#include 
-#include 
-#include 
-
 #define_I2C_PRIVATE
 #include 
 



Re: armv7 / A33 clock and pinctrl bindings

2017-12-26 Thread Artturi Alm
On Wed, Dec 27, 2017 at 09:37:12AM +0800, Kevin Lo wrote:
> On Tue, Dec 26, 2017 at 06:20:59PM +0100, Mark Kettenis wrote:
> > 
> > > Date: Tue, 26 Dec 2017 22:51:38 +0800
> > > From: Kevin Lo 
> > > 
> > > > Shouldn't be too difficult to add support for that one to axppmic(4).
> > > > Do you want me to create a diff for you to test?
> > > 
> > > That'd be great, thanks.  Testing is easier than writing code :)
> > 
> > Here's a diff.  Should give you a couple of sensors and working
> > regulators.  That might make the on-board eMMC work.
> > 
> 
> Thanks, but I keep getting these messages:
> 
> axppmic0 at sxirsb0 addr 0x3a3: AXP223
> sxirsb0: RD8 failed for run-time address 0x2d
> sxirsb0: RD8 failed for run-time address 0x2d
> sxirsb0: WR8 failed for run-time address 0x2d
> sxirsb0: RD8 failed for run-time address 0x2d
> sxirsb0: RD8 failed for run-time address 0x2d
> ...
> 

Hi,

did you try adding anything like in the diff below?
the output might help kettenis@ to help you:)

-Artturi


diff --git a/sys/dev/fdt/sxirsb.c b/sys/dev/fdt/sxirsb.c
index 6136e2a4359..8ab54923a4a 100644
--- a/sys/dev/fdt/sxirsb.c
+++ b/sys/dev/fdt/sxirsb.c
@@ -267,8 +267,8 @@ rsb_read_1(void *cookie, uint8_t rta, uint8_t addr)
HWRITE4(sc, RSB_AR, addr);
 
if (sxirsb_do_trans(sc)) {
-   printf("%s: RD8 failed for run-time address 0x%02x\n",
-   sc->sc_dev.dv_xname, rta);
+   printf("%s: RD8 failed for run-time address 0x%02x "
+   "addr 0x%02x\n", sc->sc_dev.dv_xname, rta, addr);
return 0xff;
}
 
@@ -285,8 +285,8 @@ rsb_read_2(void *cookie, uint8_t rta, uint8_t addr)
HWRITE4(sc, RSB_AR, addr);
 
if (sxirsb_do_trans(sc)) {
-   printf("%s: RD16 failed for run-time address 0x%02x\n",
-   sc->sc_dev.dv_xname, rta);
+   printf("%s: RD16 failed for run-time address 0x%02x "
+   "addr 0x%02x\n", sc->sc_dev.dv_xname, rta, addr);
return 0xff;
}
 
@@ -304,8 +304,8 @@ rsb_write_1(void *cookie, uint8_t rta, uint8_t addr, 
uint8_t data)
HWRITE4(sc, RSB_DATA, data);
 
if (sxirsb_do_trans(sc)) {
-   printf("%s: WR8 failed for run-time address 0x%02x\n",
-   sc->sc_dev.dv_xname, rta);
+   printf("%s: WR8 failed for run-time address 0x%02x "
+   "addr 0x%02x\n", sc->sc_dev.dv_xname, rta, addr);
return;
}
 }
@@ -321,8 +321,8 @@ rsb_write_2(void *cookie, uint8_t rta, uint8_t addr, 
uint16_t data)
HWRITE4(sc, RSB_DATA, data);
 
if (sxirsb_do_trans(sc)) {
-   printf("%s: WR16 failed for run-time address 0x%02x\n",
-   sc->sc_dev.dv_xname, rta);
+   printf("%s: WR16 failed for run-time address 0x%02x "
+   "addr 0x%02x\n", sc->sc_dev.dv_xname, rta, addr);
return;
}
 }



ifstated.conf.5 try to cover a use-case w/android phone

2017-12-25 Thread Artturi Alm
Hi,

in my use-case urndis is likely never there at boot, and while i've
been aware of ifstated(8) all the time, the relevant man pages have
felt dry w/regards giving something trivial/!carp, to make me skip
setting this up again for far too long:)

/etc/examples/ifstated.conf also supported my previous view,
that this wasn't the tool i was looking for.

english, and all that + manpage diff, so i'll show everything necessary
for the simple use-case, instead of trying to add bits here and there..

originally i intended to just make it clearer that the "For example:"
under "STATE DEFINITIONS" was not about:
"It is also possible to write multiple nested if blocks.",
and iirc. in my quick testing i found out i actually needed the nesting
below in the auto state, to allow auto->running when starting ifstated
while urndis0 is already set up&working.

-Artturi


diff --git a/usr.sbin/ifstated/ifstated.conf.5 
b/usr.sbin/ifstated/ifstated.conf.5
index 2721871926c..554ea043c5f 100644
--- a/usr.sbin/ifstated/ifstated.conf.5
+++ b/usr.sbin/ifstated/ifstated.conf.5
@@ -136,20 +136,49 @@ blocks.
 .Pp
 For example:
 .Bd -literal -offset indent
-state one {
+urndis_up = "urndis0.link.up"
+_avail_fast = '( "ifconfig urndis0 -debug 2> /dev/null" every 5)'
+_avail_init = '( "ifconfig urndis0 -debug 2> /dev/null" every 15)'
+_avail_slow = '( "ifconfig urndis0 -debug 2> /dev/null" every 30)'
+
+# The ip address below is the address of the android peer
+peer = '( "ping -q -c 1 -w 1 192.168.42.129 > /dev/null" every 5)'
+
+state auto {
+   if $urndis_up
+   set-state running
+
+   if ! $urndis_up
+   if $_avail_init
+   set-state bringup
+}
+
+state absent {
+   if $_avail_fast
+   set-state bringup
+}
+
+state bringup {
init {
-   run "ifconfig carp0 advskew 10"
-   run "ifconfig carp1 advskew 10"
+   run "ksh /etc/netstart urndis0"
+   run "sleep 2"
}
+   if $peer
+   set-state running
+}
 
-   if ! $net
-   set-state two
+state lost {
+   if $urndis_up && $peer
+   set-state running
+   if ! $_avail_fast
+   set-state absent
+}
 
-   if ! $carp_up {
-   run "ifconfig carp0 advskew 254"
-   run "ifconfig carp1 advskew 254"
-   set-state three
-   }
+state running {
+   if ! $urndis_up
+   set-state lost
+   if ! $_avail_slow
+   set-state absent
 }
 .Ed
 .Sh GRAMMAR



Re: arm64: init a var in _bootstrap()

2017-12-23 Thread Artturi Alm
On Sat, Dec 23, 2017 at 03:41:02PM +0200, Artturi Alm wrote:
> Hi,
> 
> spotted this while looking at how deep the hole suggested by mpi@ is.
> memhook is used by mmrw minor case 0, and the diff below fixes that.
> rest of it should be logically solid improvement, but given the state
> of arm64 internals w/all the "// XXXshit", and how sacred these arch-md
> bootstraps are to be above all cleanup, i guess i'll come up w/minimal
> diff later.
> 
> -Artturi
> 

and now with the minimal dirty version to fix this:
a64pine# dmesg | head -1
OpenBSD 6.2-current (GENERIC) #123: Thu Dec 21 14:27:12 MST 2017
a64pine# sysctl ddb.trigger=1
Stopped at  ddb_sysctl+0x118:
ddb> pp memhook
memhook:(unsigned char *)0x0
ddb> c
ddb.trigger: 0 -> 1
a64pine#

return value of pmap_map_stolen() is essentially the vstart used in initarm(),
and it's called only once near the end of pmap_bootstrap(), so this does fit
well w/the obscure spirit of arm bootstrap code w/o cleaning anything :)

-Artturi


diff --git a/sys/arch/arm64/arm64/pmap.c b/sys/arch/arm64/arm64/pmap.c
index 4dd2df4a2e2..4cb59b78d2a 100644
--- a/sys/arch/arm64/arm64/pmap.c
+++ b/sys/arch/arm64/arm64/pmap.c
@@ -1940,6 +1940,9 @@ pmap_map_stolen(vaddr_t kernel_start)
}
}
 
+   va += PAGE_SIZE;
+   memhook = (char *)va;
+
return va + PAGE_SIZE;
 }
 



arm64: init a var in _bootstrap()

2017-12-23 Thread Artturi Alm
Hi,

spotted this while looking at how deep the hole suggested by mpi@ is.
memhook is used by mmrw minor case 0, and the diff below fixes that.
rest of it should be logically solid improvement, but given the state
of arm64 internals w/all the "// XXXshit", and how sacred these arch-md
bootstraps are to be above all cleanup, i guess i'll come up w/minimal
diff later.

-Artturi


diff --git a/sys/arch/arm64/arm64/machdep.c b/sys/arch/arm64/arm64/machdep.c
index d1d5a673849..505fa4e1510 100644
--- a/sys/arch/arm64/arm64/machdep.c
+++ b/sys/arch/arm64/arm64/machdep.c
@@ -833,13 +833,6 @@ initarm(struct arm64_bootparams *abp)
msgbufphys = pmap_steal_avail(round_page(MSGBUFSIZE), PAGE_SIZE, NULL);
vstart += round_page(MSGBUFSIZE);
 
-   zero_page = vstart;
-   vstart += PAGE_SIZE;
-   copy_src_page = vstart;
-   vstart += PAGE_SIZE;
-   copy_dst_page = vstart;
-   vstart += PAGE_SIZE;
-
/* Relocate the FDT to safe memory. */
if (fdt_get_size(config) != 0) {
uint32_t csize, size = round_page(fdt_get_size(config));
diff --git a/sys/arch/arm64/arm64/pmap.c b/sys/arch/arm64/arm64/pmap.c
index 067b1ea2a53..61cfc279a74 100644
--- a/sys/arch/arm64/arm64/pmap.c
+++ b/sys/arch/arm64/arm64/pmap.c
@@ -155,6 +155,11 @@ struct mem_region *pmap_allocated = 
&pmap_allocated_regions[0];
 int pmap_cnt_avail, pmap_cnt_allocated;
 uint64_t pmap_avail_kvo;
 
+/* static free VAs setup during bootstrap */
+char *memhook;
+vaddr_t zero_page;
+vaddr_t copy_src_page;
+vaddr_t copy_dst_page;
 
 /* virtual to physical helpers */
 static inline int
@@ -1201,6 +1206,16 @@ pmap_bootstrap(long kvo, paddr_t lpt1,  long 
kernelstart, long kernelend,
 
printf("all mapped\n");
 
+   /* claim some static KVAs used by mmrw/pmap_zero_page/pmap_copy_page */
+   memhook = (char *)vstart;
+   vstart += PAGE_SIZE;
+   zero_page = vstart;
+   vstart += PAGE_SIZE;
+   copy_src_page = vstart;
+   vstart += PAGE_SIZE;
+   copy_dst_page = vstart;
+   vstart += PAGE_SIZE;
+
return vstart;
 }
 
@@ -1650,11 +1665,6 @@ pmap_update(pmap_t pm)
 {
 }
 
-char *memhook;
-vaddr_t zero_page;
-vaddr_t copy_src_page;
-vaddr_t copy_dst_page;
-
 int
 pmap_is_referenced(struct vm_page *pg)
 {



Re: armv7 a few tc_counter_mask fixes

2017-12-22 Thread Artturi Alm
On Mon, Sep 18, 2017 at 08:53:43PM +0300, Artturi Alm wrote:
> On Mon, Sep 18, 2017 at 03:41:56PM +0300, Artturi Alm wrote:
> > On Mon, Sep 18, 2017 at 11:19:09AM +0100, Stuart Henderson wrote:
> > > On 2017/09/18 04:28, Artturi Alm wrote:
> > > > Do i really need to reference datasheets, or would someone explain to me
> > > > the value of this MSB robbing?
> > > 
> > > I think, if you're proposing a change, you should explain why that
> > > change should be made, rather than asking others to defend the current
> > > situation..
> > > 
> > 
> > guess i wasn't clear enough. of the 3 timers two are 64bit timers, of them
> > agtimer doesn't even support reading just 32bit, nor any of them do just
> > 31bits as claimed by the timercounter mask.
> > so all of them act opposite to what's written in sys/timetc.h, the last bit
> > won't be constant with these.
> > 
> > amptimer's low register does have full 32bits, if it didn't, i doubt this
> > function could exist:
> > /sys/arch/arm/cortex/amptimer.c:
> > 128 uint64_t
> > 129 amptimer_readcnt64(struct amptimer_softc *sc)
> > 130 {
> > 131 uint32_t high0, high1, low;
> > 132 bus_space_tag_t iot = sc->sc_iot;
> > 133 bus_space_handle_t ioh = sc->sc_ioh;
> > 134
> > 135 do {
> > 136 high0 = bus_space_read_4(iot, ioh, GTIMER_CNT_HIGH);
> > 137 low = bus_space_read_4(iot, ioh, GTIMER_CNT_LOW);
> > 138 high1 = bus_space_read_4(iot, ioh, GTIMER_CNT_HIGH);
> > 139 } while (high0 != high1);
> > 140
> > 141 return uint64_t)high1) << 32) | low);
> > 142 }
> > 
> > if you google for "swpu223g" you'll find omap3430 technical reference manual
> > pdf, in it you can find the description of gptimer's TCRR register, at
> > page 2600, also it _will_ count beyond 0x7fff.
> > 
> > you can find reference to gptimer(missed replace) from amptimer.c, i guess
> > amptimer was where agtimer got it from, so maybe just an bad copy-paste.
> > 
> 
> i meant to write "(missed replace?)" above, as i'm not sure,
> but now i think i know who i should have cc'ed initially.
> i'm guessing the chain has gone something like this:
> macppc||socppc->beagle's gptimer->panda's amptimer->agtimer->arm64 agtimer
> 
> drahn@, would you help me out a bit here? do you know/remember about
> these enough, to ok what i've suggested(+same for arm64 agtimer) to anyone
> who could pick this up?
> 
> -Artturi
> 

ping? would you, just for a bit?

-Artturi



Re: armv7/imx: freezing fec

2017-12-22 Thread Artturi Alm
On Sun, Dec 10, 2017 at 07:05:11PM +0100, Mark Kettenis wrote:
> > Date: Sun, 10 Dec 2017 19:03:41 +0200
> > From: Artturi Alm 
> > 
> > On Wed, Nov 29, 2017 at 11:45:51AM +0200, Artturi Alm wrote:
> > > Hi,
> > > 
> > > 
> > > there's more work to be done for fec, but this will allow changing
> > > changing address/ifconfig up&down etc. without the freeze/kernel hangup
> > > preventing ie. autoinstall i've reported to bugs@.
> > > 
> > > i didn't see these while loops being done in nbsd if_enet, where i think
> > > fec originates from.
> > > 
> > > -Artturi
> > > 
> > 
> > Ping? should I minimize the diff i sent earlier, or?
> 
> Does this fix any real problems?  If not, just drop it.
> 

Pong; i dropped imx, and replugged a64pine in it's place, but here's
a lesser version untested of a diff that fixed the bug for me.

-Artturi


diff --git a/sys/arch/armv7/imx/if_fec.c b/sys/arch/armv7/imx/if_fec.c
index 899c1904144..461ab74041d 100644
--- a/sys/arch/armv7/imx/if_fec.c
+++ b/sys/arch/armv7/imx/if_fec.c
@@ -181,6 +181,8 @@
 #define ENET_TXD_INT   (1 << 30)
 #endif
 
+#defineENET_MII_TIMEOUT10  /* 5sec: --loop_cnt { delay(5); 
} */
+
 /*
  * Bus dma allocation structure used by
  * fec_dma_malloc and fec_dma_free.
@@ -339,7 +341,6 @@ fec_attach(struct device *parent, struct device *self, void 
*aux)
 
/* reset the controller */
HSET4(sc, ENET_ECR, ENET_ECR_RESET);
-   while(HREAD4(sc, ENET_ECR) & ENET_ECR_RESET);
 
HWRITE4(sc, ENET_EIMR, 0);
HWRITE4(sc, ENET_EIR, 0x);
@@ -604,7 +605,6 @@ fec_init(struct fec_softc *sc)
 
/* reset the controller */
HSET4(sc, ENET_ECR, ENET_ECR_RESET);
-   while(HREAD4(sc, ENET_ECR) & ENET_ECR_RESET);
 
/* set hw address */
HWRITE4(sc, ENET_PALR,
@@ -616,7 +616,8 @@ fec_init(struct fec_softc *sc)
(sc->sc_ac.ac_enaddr[4] << 24) |
(sc->sc_ac.ac_enaddr[5] << 16));
 
-   /* clear outstanding interrupts */
+   /* mask and clear all (possibly outstanding) interrupts */
+   HWRITE4(sc, ENET_EIMR, 0);
HWRITE4(sc, ENET_EIR, 0x);
 
/* set max receive buffer size, 3-0 bits always zero for alignment */
@@ -692,6 +693,9 @@ fec_stop(struct fec_softc *sc)
 {
struct ifnet *ifp = &sc->sc_ac.ac_if;
 
+   /* stop the controller, will be reset on _init() */
+   HCLR4(sc, ENET_ECR, ENET_ECR_ETHEREN);
+
/*
 * Mark the interface down and cancel the watchdog timer.
 */
@@ -700,10 +704,6 @@ fec_stop(struct fec_softc *sc)
ifq_clr_oactive(&ifp->if_snd);
 
timeout_del(&sc->sc_tick);
-
-   /* reset the controller */
-   HSET4(sc, ENET_ECR, ENET_ECR_RESET);
-   while(HREAD4(sc, ENET_ECR) & ENET_ECR_RESET);
 }
 
 void
@@ -996,6 +996,7 @@ fec_miibus_readreg(struct device *dev, int phy, int reg)
 {
int r = 0;
struct fec_softc *sc = (struct fec_softc *)dev;
+   u_int timo = ENET_MII_TIMEOUT;
 
HSET4(sc, ENET_EIR, ENET_EIR_MII);
 
@@ -1003,7 +1004,8 @@ fec_miibus_readreg(struct device *dev, int phy, int reg)
ENET_MMFR_ST | ENET_MMFR_OP_RD | ENET_MMFR_TA |
phy << ENET_MMFR_PA_SHIFT | reg << ENET_MMFR_RA_SHIFT);
 
-   while(!(HREAD4(sc, ENET_EIR) & ENET_EIR_MII));
+   while (!(HREAD4(sc, ENET_EIR) & ENET_EIR_MII) && --timo)
+   delay(5);
 
r = bus_space_read_4(sc->sc_iot, sc->sc_ioh, ENET_MMFR);
 
@@ -1014,6 +1016,7 @@ void
 fec_miibus_writereg(struct device *dev, int phy, int reg, int val)
 {
struct fec_softc *sc = (struct fec_softc *)dev;
+   u_int timo = ENET_MII_TIMEOUT;
 
HSET4(sc, ENET_EIR, ENET_EIR_MII);
 
@@ -1022,7 +1025,8 @@ fec_miibus_writereg(struct device *dev, int phy, int reg, 
int val)
phy << ENET_MMFR_PA_SHIFT | reg << ENET_MMFR_RA_SHIFT |
(val & 0x));
 
-   while(!(HREAD4(sc, ENET_EIR) & ENET_EIR_MII));
+   while (!(HREAD4(sc, ENET_EIR) & ENET_EIR_MII) && --timo)
+   delay(5);
 
return;
 }



Re: sunxi RSB implementation

2017-12-16 Thread Artturi Alm
On Fri, Dec 15, 2017 at 10:58:22PM +0100, Mark Kettenis wrote:
> Some of the Allwinner SoCs have a so-called Reduces Serial Bus that is
> used to communicate with peripheral chips (mostly power management
> ICs).  The diff below adds a driver for the RSB conntroller, named
> sxirsb(4), and a driver for the RTC component of the X-Powers AC100
> audio codec.  I deliberately cose not to abstract the RSB bus itself
> as that is a unecessary as long as we only have a single RSB
> controller implementation.  But the code is written such that this can
> be easily changed if the need arises.  Shows up in dmesg as:
> 
> sxirsb0 at simplebus0
> "x-powers,axp809" at sxirsb0 addr 0x3a3 not configured
> "x-powers,axp806" at sxirsb0 addr 0x745 not configured
> acrtc0 at sxirsb0 addr 0xe89
> 
> The sxirsb(4) driver attaches early since its children are often used
> for power management.
> 
> ok?
> 

Looks better than what i've had in my branches,
as faking i2c-controller turned out to be messy.
Besides my personal preference not to mention/compare to linux even in
comments , only change i came up w/reading the diff was the obvious typo
in the name Reduces=Reduced.

-Artturi

> 
> Index: arch/armv7/conf/GENERIC
> ===
> RCS file: /cvs/src/sys/arch/armv7/conf/GENERIC,v
> retrieving revision 1.99
> diff -u -p -r1.99 GENERIC
> --- arch/armv7/conf/GENERIC   24 Oct 2017 17:00:34 -  1.99
> +++ arch/armv7/conf/GENERIC   15 Dec 2017 21:53:54 -
> @@ -91,6 +91,8 @@ sxipio* at fdt? early 1 # GPIO pins fo
>  gpio*at sxipio?
>  sxiccmu* at fdt? early 1 # Clock Control Module/Unit
>  sxitimer*at fdt? early 1
> +sxirsb*  at fdt? early 1 # Reduces Serial Bus

typo here ^

> +acrtc*   at sxirsb?
>  sxidog*  at fdt? # watchdog timer
>  sxirtc*  at fdt? # Real Time Clock
>  sxie*at fdt?
> Index: arch/armv7/conf/RAMDISK
> ===
> RCS file: /cvs/src/sys/arch/armv7/conf/RAMDISK,v
> retrieving revision 1.92
> diff -u -p -r1.92 RAMDISK
> --- arch/armv7/conf/RAMDISK   24 Oct 2017 17:00:34 -  1.92
> +++ arch/armv7/conf/RAMDISK   15 Dec 2017 21:53:54 -
> @@ -87,6 +87,8 @@ sxipio* at fdt? early 1 # GPIO pins fo
>  gpio*at sxipio?
>  sxiccmu* at fdt? early 1 # Clock Control Module/Unit
>  sxitimer*at fdt? early 1
> +sxirsb*  at fdt? early 1 # Reduces Serial Bus

typo here ^

> +acrtc*   at sxirsb?
>  sxidog*  at fdt? # watchdog timer
>  sxirtc*  at fdt? # Real Time Clock
>  sxie*at fdt?
> Index: dev/fdt/acrtc.c
> ===
> RCS file: dev/fdt/acrtc.c
> diff -N dev/fdt/acrtc.c
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ dev/fdt/acrtc.c   15 Dec 2017 21:53:55 -
> @@ -0,0 +1,186 @@
> +/*   $OpenBSD$   */
> +/*
> + * Copyright (c) 2017 Mark Kettenis 
> + *
> + * Permission to use, copy, modify, and distribute this software for any
> + * purpose with or without fee is hereby granted, provided that the above
> + * copyright notice and this permission notice appear in all copies.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
> + * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
> + * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
> + * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
> + * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
> + * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
> + * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +#include 
> +#include 
> +
> +#include 
> +
> +#define isleap(y) y) % 4) == 0 && ((y) % 100) != 0) || ((y) % 400) == 0)
> +
> +extern todr_chip_handle_t todr_handle;
> +
> +#define RTC_CTRL 0xc7
> +#define  RTC_CTRL_12H_24H_MODE   (1 << 0)
> +#define RTC_SEC  0xc8
> +#define RTC_MIN  0xc9
> +#define RTC_HOU  0xca
> +#define RTC_WEE  0xcb
> +#define RTC_DAY  0xcc
> +#define RTC_MON  0xcd
> +#define RTC_YEA  0xce
> +#define  RTC_YEA_LEAP_YEAR   (1 << 15)
> +#define RTC_UPD_TRIG 0xcf
> +#define  RTC_UPD_TRIG_UPDATE (1 << 15)
> +
> +struct acrtc_softc {
> + struct device   sc_dev;
> + void*sc_cookie;
> + uint16_tsc_rta;
> +
> + struct todr_chip_handle sc_todr;
> +};
> +
> +int 

Re: Add reset option to boot command of ddb(4)

2017-12-14 Thread Artturi Alm
On Thu, Dec 14, 2017 at 02:05:36PM +0100, Martin Pieuchot wrote:
> On 14/12/17(Thu) 13:37, Florian Riehm wrote:
> > [...]
> > If the command could lead to DMA issues, I agree that we should not
> > introduce it.
> 
> The problem is not only DMA issues.  The problem is that ddb(4) will
> never get fixed.  If we give people a 'reset' button then how long
> until the core dump code is going to rot?
> 

implying the core dump code is not rotting around already?
it won't take long to count the zer0 replies i got[0],
for suggesting it's broken on armv7 at bugs@ :(

> As the kernel grows in complexity, because of MP or anything else,
> ddb(4) has to grow with it.
> 
> > I also agree that we should try to make boot reboot as reliable as possible
> > and it works fine in most situations.
> > Anyway I have seen it hanging in some cases.
> 
> Please send a bug report next time you see such case :)
> 

-Artturi

[0] https://marc.info/?l=openbsd-bugs&m=150125176824983&w=2



Re: armv7/imx: freezing fec

2017-12-10 Thread Artturi Alm
On Sun, Dec 10, 2017 at 07:05:11PM +0100, Mark Kettenis wrote:
> > Date: Sun, 10 Dec 2017 19:03:41 +0200
> > From: Artturi Alm 
> > 
> > On Wed, Nov 29, 2017 at 11:45:51AM +0200, Artturi Alm wrote:
> > > Hi,
> > > 
> > > 
> > > there's more work to be done for fec, but this will allow changing
> > > changing address/ifconfig up&down etc. without the freeze/kernel hangup
> > > preventing ie. autoinstall i've reported to bugs@.
> > > 
> > > i didn't see these while loops being done in nbsd if_enet, where i think
> > > fec originates from.
> > > 
> > > -Artturi
> > > 
> > 
> > Ping? should I minimize the diff i sent earlier, or?
> 
> Does this fix any real problems?  If not, just drop it.
> 

Yes, the problem/hang/bug is very real, and reported[0], it does prevent
normal things from happening.
-Artturi

[0] https://marc.info/?l=openbsd-bugs&m=150762924913018&w=2

> > > diff --git a/sys/arch/armv7/imx/if_fec.c b/sys/arch/armv7/imx/if_fec.c
> > > index 899c1904144..5b494a6c92c 100644
> > > --- a/sys/arch/armv7/imx/if_fec.c
> > > +++ b/sys/arch/armv7/imx/if_fec.c
> > > @@ -181,6 +181,8 @@
> > >  #define ENET_TXD_INT (1 << 30)
> > >  #endif
> > >  
> > > +#define  ENET_MII_TIMEOUT10  /* --loop_cnt { delay(5); } */
> > > +
> > >  /*
> > >   * Bus dma allocation structure used by
> > >   * fec_dma_malloc and fec_dma_free.
> > > @@ -339,7 +341,6 @@ fec_attach(struct device *parent, struct device 
> > > *self, void *aux)
> > >  
> > >   /* reset the controller */
> > >   HSET4(sc, ENET_ECR, ENET_ECR_RESET);
> > > - while(HREAD4(sc, ENET_ECR) & ENET_ECR_RESET);
> > >  
> > >   HWRITE4(sc, ENET_EIMR, 0);
> > >   HWRITE4(sc, ENET_EIR, 0x);
> > > @@ -604,7 +605,6 @@ fec_init(struct fec_softc *sc)
> > >  
> > >   /* reset the controller */
> > >   HSET4(sc, ENET_ECR, ENET_ECR_RESET);
> > > - while(HREAD4(sc, ENET_ECR) & ENET_ECR_RESET);
> > >  
> > >   /* set hw address */
> > >   HWRITE4(sc, ENET_PALR,
> > > @@ -616,7 +616,8 @@ fec_init(struct fec_softc *sc)
> > >   (sc->sc_ac.ac_enaddr[4] << 24) |
> > >   (sc->sc_ac.ac_enaddr[5] << 16));
> > >  
> > > - /* clear outstanding interrupts */
> > > + /* mask and clear all interrupts */
> > > + HWRITE4(sc, ENET_EIMR, 0);
> > >   HWRITE4(sc, ENET_EIR, 0x);
> > >  
> > >   /* set max receive buffer size, 3-0 bits always zero for alignment */
> > > @@ -692,6 +693,8 @@ fec_stop(struct fec_softc *sc)
> > >  {
> > >   struct ifnet *ifp = &sc->sc_ac.ac_if;
> > >  
> > > + HCLR4(sc, ENET_ECR, ENET_ECR_ETHEREN);
> > > +
> > >   /*
> > >* Mark the interface down and cancel the watchdog timer.
> > >*/
> > > @@ -701,9 +704,7 @@ fec_stop(struct fec_softc *sc)
> > >  
> > >   timeout_del(&sc->sc_tick);
> > >  
> > > - /* reset the controller */
> > > - HSET4(sc, ENET_ECR, ENET_ECR_RESET);
> > > - while(HREAD4(sc, ENET_ECR) & ENET_ECR_RESET);
> > > + mii_down(&sc->sc_mii);
> > >  }
> > >  
> > >  void
> > > @@ -996,6 +997,7 @@ fec_miibus_readreg(struct device *dev, int phy, int 
> > > reg)
> > >  {
> > >   int r = 0;
> > >   struct fec_softc *sc = (struct fec_softc *)dev;
> > > + u_int timo = ENET_MII_TIMEOUT;
> > >  
> > >   HSET4(sc, ENET_EIR, ENET_EIR_MII);
> > >  
> > > @@ -1003,10 +1005,16 @@ fec_miibus_readreg(struct device *dev, int phy, 
> > > int reg)
> > >   ENET_MMFR_ST | ENET_MMFR_OP_RD | ENET_MMFR_TA |
> > >   phy << ENET_MMFR_PA_SHIFT | reg << ENET_MMFR_RA_SHIFT);
> > >  
> > > - while(!(HREAD4(sc, ENET_EIR) & ENET_EIR_MII));
> > > + while (!(HREAD4(sc, ENET_EIR) & ENET_EIR_MII) && --timo)
> > > + delay(5);
> > >  
> > >   r = bus_space_read_4(sc->sc_iot, sc->sc_ioh, ENET_MMFR);
> > >  
> > > +#ifdef DIAGNOSTIC
> > > + if (!timo)
> > > + printf("%s: %s timeout\n", sc->sc_dev.dv_xname, __func__);
> > > +#endif
> > > +
> > >   return (r & 0x);
> > >  }
> > >  
> > > @@ -1014,6 +1022,7 @@ void
> > >  fec_miibus_writereg(struct device *dev, int phy, int reg, int val)
> > >  {
> > >   struct fec_softc *sc = (struct fec_softc *)dev;
> > > + u_int timo = ENET_MII_TIMEOUT;
> > >  
> > >   HSET4(sc, ENET_EIR, ENET_EIR_MII);
> > >  
> > > @@ -1022,7 +1031,12 @@ fec_miibus_writereg(struct device *dev, int phy, 
> > > int reg, int val)
> > >   phy << ENET_MMFR_PA_SHIFT | reg << ENET_MMFR_RA_SHIFT |
> > >   (val & 0x));
> > >  
> > > - while(!(HREAD4(sc, ENET_EIR) & ENET_EIR_MII));
> > > + while (!(HREAD4(sc, ENET_EIR) & ENET_EIR_MII) && --timo)
> > > + delay(5);
> > > +#ifdef DIAGNOSTIC
> > > + if (!timo)
> > > + printf("%s: %s timeout\n", sc->sc_dev.dv_xname, __func__);
> > > +#endif
> > >  
> > >   return;
> > >  }
> > 
> > 



Re: armv7/imx: freezing fec

2017-12-10 Thread Artturi Alm
On Wed, Nov 29, 2017 at 11:45:51AM +0200, Artturi Alm wrote:
> Hi,
> 
> 
> there's more work to be done for fec, but this will allow changing
> changing address/ifconfig up&down etc. without the freeze/kernel hangup
> preventing ie. autoinstall i've reported to bugs@.
> 
> i didn't see these while loops being done in nbsd if_enet, where i think
> fec originates from.
> 
> -Artturi
> 

Ping? should I minimize the diff i sent earlier, or?

-Artturi

> 
> diff --git a/sys/arch/armv7/imx/if_fec.c b/sys/arch/armv7/imx/if_fec.c
> index 899c1904144..5b494a6c92c 100644
> --- a/sys/arch/armv7/imx/if_fec.c
> +++ b/sys/arch/armv7/imx/if_fec.c
> @@ -181,6 +181,8 @@
>  #define ENET_TXD_INT (1 << 30)
>  #endif
>  
> +#define  ENET_MII_TIMEOUT10  /* --loop_cnt { delay(5); } */
> +
>  /*
>   * Bus dma allocation structure used by
>   * fec_dma_malloc and fec_dma_free.
> @@ -339,7 +341,6 @@ fec_attach(struct device *parent, struct device *self, 
> void *aux)
>  
>   /* reset the controller */
>   HSET4(sc, ENET_ECR, ENET_ECR_RESET);
> - while(HREAD4(sc, ENET_ECR) & ENET_ECR_RESET);
>  
>   HWRITE4(sc, ENET_EIMR, 0);
>   HWRITE4(sc, ENET_EIR, 0x);
> @@ -604,7 +605,6 @@ fec_init(struct fec_softc *sc)
>  
>   /* reset the controller */
>   HSET4(sc, ENET_ECR, ENET_ECR_RESET);
> - while(HREAD4(sc, ENET_ECR) & ENET_ECR_RESET);
>  
>   /* set hw address */
>   HWRITE4(sc, ENET_PALR,
> @@ -616,7 +616,8 @@ fec_init(struct fec_softc *sc)
>   (sc->sc_ac.ac_enaddr[4] << 24) |
>   (sc->sc_ac.ac_enaddr[5] << 16));
>  
> - /* clear outstanding interrupts */
> + /* mask and clear all interrupts */
> + HWRITE4(sc, ENET_EIMR, 0);
>   HWRITE4(sc, ENET_EIR, 0x);
>  
>   /* set max receive buffer size, 3-0 bits always zero for alignment */
> @@ -692,6 +693,8 @@ fec_stop(struct fec_softc *sc)
>  {
>   struct ifnet *ifp = &sc->sc_ac.ac_if;
>  
> + HCLR4(sc, ENET_ECR, ENET_ECR_ETHEREN);
> +
>   /*
>* Mark the interface down and cancel the watchdog timer.
>*/
> @@ -701,9 +704,7 @@ fec_stop(struct fec_softc *sc)
>  
>   timeout_del(&sc->sc_tick);
>  
> - /* reset the controller */
> - HSET4(sc, ENET_ECR, ENET_ECR_RESET);
> - while(HREAD4(sc, ENET_ECR) & ENET_ECR_RESET);
> + mii_down(&sc->sc_mii);
>  }
>  
>  void
> @@ -996,6 +997,7 @@ fec_miibus_readreg(struct device *dev, int phy, int reg)
>  {
>   int r = 0;
>   struct fec_softc *sc = (struct fec_softc *)dev;
> + u_int timo = ENET_MII_TIMEOUT;
>  
>   HSET4(sc, ENET_EIR, ENET_EIR_MII);
>  
> @@ -1003,10 +1005,16 @@ fec_miibus_readreg(struct device *dev, int phy, int 
> reg)
>   ENET_MMFR_ST | ENET_MMFR_OP_RD | ENET_MMFR_TA |
>   phy << ENET_MMFR_PA_SHIFT | reg << ENET_MMFR_RA_SHIFT);
>  
> - while(!(HREAD4(sc, ENET_EIR) & ENET_EIR_MII));
> + while (!(HREAD4(sc, ENET_EIR) & ENET_EIR_MII) && --timo)
> + delay(5);
>  
>   r = bus_space_read_4(sc->sc_iot, sc->sc_ioh, ENET_MMFR);
>  
> +#ifdef DIAGNOSTIC
> + if (!timo)
> + printf("%s: %s timeout\n", sc->sc_dev.dv_xname, __func__);
> +#endif
> +
>   return (r & 0x);
>  }
>  
> @@ -1014,6 +1022,7 @@ void
>  fec_miibus_writereg(struct device *dev, int phy, int reg, int val)
>  {
>   struct fec_softc *sc = (struct fec_softc *)dev;
> + u_int timo = ENET_MII_TIMEOUT;
>  
>   HSET4(sc, ENET_EIR, ENET_EIR_MII);
>  
> @@ -1022,7 +1031,12 @@ fec_miibus_writereg(struct device *dev, int phy, int 
> reg, int val)
>   phy << ENET_MMFR_PA_SHIFT | reg << ENET_MMFR_RA_SHIFT |
>   (val & 0x));
>  
> - while(!(HREAD4(sc, ENET_EIR) & ENET_EIR_MII));
> + while (!(HREAD4(sc, ENET_EIR) & ENET_EIR_MII) && --timo)
> + delay(5);
> +#ifdef DIAGNOSTIC
> + if (!timo)
> + printf("%s: %s timeout\n", sc->sc_dev.dv_xname, __func__);
> +#endif
>  
>   return;
>  }



Re: armv7/sxie: enable phy-supply

2017-12-03 Thread Artturi Alm
On Sun, Dec 03, 2017 at 10:28:02PM +1100, Jonathan Gray wrote:
> On Wed, Nov 29, 2017 at 11:32:24AM +0200, Artturi Alm wrote:
> > On Wed, Nov 29, 2017 at 12:37:23AM +1100, Jonathan Gray wrote:
> > > On Sun, Nov 26, 2017 at 06:52:42PM +0200, Artturi Alm wrote:
> > > > Hi,
> > > > 
> > > > unless i failed w/grep, only 4 boards with dts in u-boot/linux need 
> > > > this,
> > > > but i've got one of those, so this would be much appreciated:)
> > > > 
> > > > -Artturi
> > > 
> > > This seems reasonable and there is no non-panic error path
> > > there currently to add a regulator_disable() call to.
> > > 
> > > Changing the variable name to phy_supply would match the existing
> > > code in sys/dev/fdt.
> > > 
> > 
> > Like this?
> > 
> > -Artturi
> 
> Yes, but I don't see how this can work with the current dtbs.
> 
> sxie only matches "allwinner,sun4i-a10-emac" so you have one
> of the following?
> 
> sun4i-a10-a1000.dtb "Mele A1000"
> sun4i-a10-hackberry.dtb "Miniand Hackberry"
> sun4i-a10-jesurun-q5.dtb "Jesurun Q5"
> 
> ethernet@1c0b000 {
> compatible = "allwinner,sun4i-a10-emac";
> reg = <0x01c0b000 0x1000>;
> interrupts = <0x0037>;
> clocks = <0x0002 0x002a>;
> allwinner,sram = <0x000b 0x0001>;
> pinctrl-names = "default";
> pinctrl-0 = <0x000c>;
> status = "okay";
> phy = <0x000d>;
> };
> mdio@1c0b080 {
> compatible = "allwinner,sun4i-a10-mdio";
> reg = <0x01c0b080 0x0014>;
> status = "okay";
> #address-cells = <0x0001>;
> #size-cells = <0x>;
> phy-supply = <0x000e>;
> ethernet-phy@0 {
> reg = <0x>;
> linux,phandle = <0x000d>;
> phandle = <0x000d>;
> };
> };
> 
> compared to the a20 gmac dwge(4) use
> 
> ethernet@1c5 {
> compatible = "allwinner,sun7i-a20-gmac";
> reg = <0x01c5 0x0001>;
> interrupts = <0x 0x0055 0x0004>;
> interrupt-names = "macirq";
> clocks = <0x0002 0x0042 0x0026>;
> clock-names = "stmmaceth", "allwinner_gmac_tx";
> snps,pbl = <0x0002>;
> snps,fixed-burst;
> snps,force_sf_dma_mode;
> status = "okay";
> #address-cells = <0x0001>;
> #size-cells = <0x>;
> pinctrl-names = "default";
> pinctrl-0 = <0x0027>;
> phy = <0x0028>;
> phy-mode = "rgmii";
> phy-supply = <0x0029>;
> ethernet-phy@1 {
> reg = <0x0001>;
> linux,phandle = <0x0028>;
> phandle = <0x0028>;
> };
> };
> 
> > 
> > 
> > diff --git a/sys/arch/armv7/sunxi/sxie.c b/sys/arch/armv7/sunxi/sxie.c
> > index 116fda5f8d7..41c378a7ef7 100644
> > --- a/sys/arch/armv7/sunxi/sxie.c
> > +++ b/sys/arch/armv7/sunxi/sxie.c
> > @@ -51,6 +51,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  
> >  /* configuration registers */
> > @@ -212,6 +213,7 @@ sxie_attach(struct device *parent, struct device *self, 
> > void *aux)
> > struct fdt_attach_args *faa = aux;
> > struct mii_data *mii;
> > struct ifnet *ifp;
> > +   int phy_supply;
> > int s;
> >  
> > if (faa->fa_nreg < 1)
> > @@ -230,6 +232,11 @@ sxie_attach(struct device *parent, struct device 
> > *self, void *aux)
> >  
> > clock_enable_all(faa->fa_node);
> >  
> > +   /* Power up PHY. */
> > +   phy_supply = OF_getpropint(faa->fa_node, "phy-supply", 0);
> > +   if (phy_supply)
> > +   regulator_enable(phy_supply);
> > +
> > sxie_socware_init(sc);
> > sc->txf_inuse = 0;
> >  
> > 

diff below for what i essentially went with to get it working.

thanks in advance:)
-Artturi


diff -

Re: armv7/sxie: enable phy-supply

2017-12-03 Thread Artturi Alm
On Sun, Dec 03, 2017 at 10:28:02PM +1100, Jonathan Gray wrote:
> On Wed, Nov 29, 2017 at 11:32:24AM +0200, Artturi Alm wrote:
> > On Wed, Nov 29, 2017 at 12:37:23AM +1100, Jonathan Gray wrote:
> > > On Sun, Nov 26, 2017 at 06:52:42PM +0200, Artturi Alm wrote:
> > > > Hi,
> > > > 
> > > > unless i failed w/grep, only 4 boards with dts in u-boot/linux need 
> > > > this,
> > > > but i've got one of those, so this would be much appreciated:)
> > > > 
> > > > -Artturi
> > > 
> > > This seems reasonable and there is no non-panic error path
> > > there currently to add a regulator_disable() call to.
> > > 
> > > Changing the variable name to phy_supply would match the existing
> > > code in sys/dev/fdt.
> > > 
> > 
> > Like this?
> > 
> > -Artturi
> 
> Yes, but I don't see how this can work with the current dtbs.
> 

right, sorry for posting w/o testing properly..

> sxie only matches "allwinner,sun4i-a10-emac" so you have one
> of the following?
> 

yep, Miniand Hackberry, for which i've used my own x_defconfig, as it
doesn't exist on mainline u-boot for some reason despite .dts being there.
I just fixed my setup to allow turning it back on(did lack uart for console,
and port in switch etc.).. so before, i just tested that it didn't cause
regression on others.

i changed my current branch to have phy lookup before phy powerup,
which has OF_getparent() for the phynode while looking for phy-supply,
will test asap..

-Artturi

> sun4i-a10-a1000.dtb "Mele A1000"
> sun4i-a10-hackberry.dtb "Miniand Hackberry"
> sun4i-a10-jesurun-q5.dtb "Jesurun Q5"
> 
> ethernet@1c0b000 {
> compatible = "allwinner,sun4i-a10-emac";
> reg = <0x01c0b000 0x1000>;
> interrupts = <0x0037>;
> clocks = <0x0002 0x002a>;
> allwinner,sram = <0x000b 0x0001>;
> pinctrl-names = "default";
> pinctrl-0 = <0x000c>;
> status = "okay";
> phy = <0x000d>;
> };
> mdio@1c0b080 {
> compatible = "allwinner,sun4i-a10-mdio";
> reg = <0x01c0b080 0x0014>;
> status = "okay";
> #address-cells = <0x0001>;
> #size-cells = <0x>;
> phy-supply = <0x000e>;
> ethernet-phy@0 {
> reg = <0x>;
> linux,phandle = <0x000d>;
> phandle = <0x000d>;
> };
> };
> 
> compared to the a20 gmac dwge(4) use
> 
> ethernet@1c5 {
> compatible = "allwinner,sun7i-a20-gmac";
> reg = <0x01c5 0x0001>;
> interrupts = <0x 0x0055 0x0004>;
> interrupt-names = "macirq";
> clocks = <0x0002 0x0042 0x0026>;
> clock-names = "stmmaceth", "allwinner_gmac_tx";
> snps,pbl = <0x0002>;
> snps,fixed-burst;
> snps,force_sf_dma_mode;
> status = "okay";
> #address-cells = <0x0001>;
> #size-cells = <0x>;
> pinctrl-names = "default";
> pinctrl-0 = <0x0027>;
> phy = <0x0028>;
> phy-mode = "rgmii";
> phy-supply = <0x0029>;
> ethernet-phy@1 {
> reg = <0x0001>;
> linux,phandle = <0x0028>;
> phandle = <0x0028>;
> };
> };
> 
> > 
> > 
> > diff --git a/sys/arch/armv7/sunxi/sxie.c b/sys/arch/armv7/sunxi/sxie.c
> > index 116fda5f8d7..41c378a7ef7 100644
> > --- a/sys/arch/armv7/sunxi/sxie.c
> > +++ b/sys/arch/armv7/sunxi/sxie.c
> > @@ -51,6 +51,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  
> >  /* configuration registers */
> > @@ -212,6 +213,7 @@ sxie_attach(struct device *parent, struct device *self, 
> > void *aux)
> > struct fdt_attach_args *faa = aux;
> > struct mii_data *mii;
> > struct ifnet *ifp;
> > +   int phy_supply;
> > int s;
> >  
> > if (faa->fa_nreg < 1)
> > @@ -230,6 +232,11 @@ sxie_attach(struct device *parent, struct device 
> > *self, void *aux)
> >  
> > clock_enable_all(faa->fa_node);
> >  
> > +   /* Power up PHY. */
> > +   phy_supply = OF_getpropint(faa->fa_node, "phy-supply", 0);
> > +   if (phy_supply)
> > +   regulator_enable(phy_supply);
> > +
> > sxie_socware_init(sc);
> > sc->txf_inuse = 0;
> >  
> > 



armv7/sxie/if_dwge: get&set "local-mac-address"

2017-11-29 Thread Artturi Alm
Hi,

now as u-boot env is more likely to be found in the FAT by default[0],
i presume there will be more use for this, so that things work
consistently across all ethernet drivers(except if_dwxe) on armv7.

just reading what might be set in the registers already doesn't really
work out consistently, as it might not get set out of the box without
messing with u-boot distro_defaults, since efi payload does get run
before dhcp/pxeboot or whatever; ie. the usual case to get things set
w/o touching individual environment variables is to run the dhcp command
on u-boot prompt.

diff w/intention to be minimal.
-Artturi

[0] https://patchwork.ozlabs.org/cover/842057/


diff --git a/sys/arch/armv7/sunxi/sxie.c b/sys/arch/armv7/sunxi/sxie.c
index 116fda5f8d7..f4c6f8b1ca0 100644
--- a/sys/arch/armv7/sunxi/sxie.c
+++ b/sys/arch/armv7/sunxi/sxie.c
@@ -173,7 +173,7 @@ struct sxie_softc *sxie_sc;
 intsxie_match(struct device *, void *, void *);
 void   sxie_attach(struct device *, struct device *, void *);
 void   sxie_setup_interface(struct sxie_softc *, struct device *);
-void   sxie_socware_init(struct sxie_softc *);
+void   sxie_socware_init(struct sxie_softc *, int);
 intsxie_ioctl(struct ifnet *, u_long, caddr_t);
 void   sxie_start(struct ifnet *);
 void   sxie_watchdog(struct ifnet *);
@@ -230,7 +230,7 @@ sxie_attach(struct device *parent, struct device *self, 
void *aux)
 
clock_enable_all(faa->fa_node);
 
-   sxie_socware_init(sc);
+   sxie_socware_init(sc, faa->fa_node);
sc->txf_inuse = 0;
 
sc->sc_ih = arm_intr_establish_fdt(faa->fa_node, IPL_NET,
@@ -276,8 +276,9 @@ sxie_attach(struct device *parent, struct device *self, 
void *aux)
 }
 
 void
-sxie_socware_init(struct sxie_softc *sc)
+sxie_socware_init(struct sxie_softc *sc, int node)
 {
+   uint8_t *enaddr = &sc->sc_ac.ac_enaddr[0];
int have_mac = 0;
uint32_t reg;
 
@@ -287,12 +288,17 @@ sxie_socware_init(struct sxie_softc *sc)
SXIWRITE4(sc, SXIE_INTCR, SXIE_INTR_DISABLE);
SXISET4(sc, SXIE_INTSR, SXIE_INTR_CLEAR);
 
+   if (OF_getproplen(node, "local-mac-address") == ETHER_ADDR_LEN) {
+   OF_getprop(node, "local-mac-address", enaddr, ETHER_ADDR_LEN);
+   have_mac = 1;
+   }
+
/*
 * If u-boot doesn't set emac, use the Security ID area
 * to generate a consistent MAC address of.
 */
reg = SXIREAD4(sc, SXIE_MACA0);
-   if (reg != 0) {
+   if (!have_mac && reg != 0) {
sc->sc_ac.ac_enaddr[3] = reg >> 16 & 0xff;
sc->sc_ac.ac_enaddr[4] = reg >> 8 & 0xff;
sc->sc_ac.ac_enaddr[5] = reg & 0xff;
diff --git a/sys/dev/fdt/if_dwge_fdt.c b/sys/dev/fdt/if_dwge_fdt.c
index edfe5acb992..bca2cee2f72 100644
--- a/sys/dev/fdt/if_dwge_fdt.c
+++ b/sys/dev/fdt/if_dwge_fdt.c
@@ -87,6 +87,7 @@ dwge_fdt_attach(struct device *parent, struct device *self, 
void *aux)
struct dwge_fdt_softc *fsc = (struct dwge_fdt_softc *)self;
struct dwc_gmac_softc *sc = &fsc->sc_core;
struct fdt_attach_args *faa = aux;
+   uint8_t *enaddr = &sc->sc_ac.ac_enaddr[0];
int phyloc = MII_PHY_ANY;
uint32_t phy_supply;
uint32_t phy;
@@ -145,6 +146,12 @@ dwge_fdt_attach(struct device *parent, struct device 
*self, void *aux)
goto clrpwr;
}
 
+   /* Setup lladdr here, if we have one, to keep fdt out of dwc_gmac */
+   if (OF_getproplen(node, "local-mac-address") == ETHER_ADDR_LEN) {
+   OF_getprop(node, "local-mac-address", enaddr, ETHER_ADDR_LEN);
+   dwc_gmac_write_hwaddr(sc, enaddr);
+   }
+
dwc_gmac_attach(sc, GMAC_MII_CLK_150_250M_DIV102, phyloc);
 
return;
diff --git a/sys/dev/ic/dwc_gmac_var.h b/sys/dev/ic/dwc_gmac_var.h
index c2b3ce97e92..517bae968f7 100644
--- a/sys/dev/ic/dwc_gmac_var.h
+++ b/sys/dev/ic/dwc_gmac_var.h
@@ -94,3 +94,4 @@ struct dwc_gmac_softc {
 
 void dwc_gmac_attach(struct dwc_gmac_softc*, uint32_t, int);
 int dwc_gmac_intr(struct dwc_gmac_softc*);
+void dwc_gmac_write_hwaddr(struct dwc_gmac_softc *, uint8_t *);



armv7/imx: freezing fec

2017-11-29 Thread Artturi Alm
Hi,


there's more work to be done for fec, but this will allow changing
changing address/ifconfig up&down etc. without the freeze/kernel hangup
preventing ie. autoinstall i've reported to bugs@.

i didn't see these while loops being done in nbsd if_enet, where i think
fec originates from.

-Artturi


diff --git a/sys/arch/armv7/imx/if_fec.c b/sys/arch/armv7/imx/if_fec.c
index 899c1904144..5b494a6c92c 100644
--- a/sys/arch/armv7/imx/if_fec.c
+++ b/sys/arch/armv7/imx/if_fec.c
@@ -181,6 +181,8 @@
 #define ENET_TXD_INT   (1 << 30)
 #endif
 
+#defineENET_MII_TIMEOUT10  /* --loop_cnt { delay(5); } */
+
 /*
  * Bus dma allocation structure used by
  * fec_dma_malloc and fec_dma_free.
@@ -339,7 +341,6 @@ fec_attach(struct device *parent, struct device *self, void 
*aux)
 
/* reset the controller */
HSET4(sc, ENET_ECR, ENET_ECR_RESET);
-   while(HREAD4(sc, ENET_ECR) & ENET_ECR_RESET);
 
HWRITE4(sc, ENET_EIMR, 0);
HWRITE4(sc, ENET_EIR, 0x);
@@ -604,7 +605,6 @@ fec_init(struct fec_softc *sc)
 
/* reset the controller */
HSET4(sc, ENET_ECR, ENET_ECR_RESET);
-   while(HREAD4(sc, ENET_ECR) & ENET_ECR_RESET);
 
/* set hw address */
HWRITE4(sc, ENET_PALR,
@@ -616,7 +616,8 @@ fec_init(struct fec_softc *sc)
(sc->sc_ac.ac_enaddr[4] << 24) |
(sc->sc_ac.ac_enaddr[5] << 16));
 
-   /* clear outstanding interrupts */
+   /* mask and clear all interrupts */
+   HWRITE4(sc, ENET_EIMR, 0);
HWRITE4(sc, ENET_EIR, 0x);
 
/* set max receive buffer size, 3-0 bits always zero for alignment */
@@ -692,6 +693,8 @@ fec_stop(struct fec_softc *sc)
 {
struct ifnet *ifp = &sc->sc_ac.ac_if;
 
+   HCLR4(sc, ENET_ECR, ENET_ECR_ETHEREN);
+
/*
 * Mark the interface down and cancel the watchdog timer.
 */
@@ -701,9 +704,7 @@ fec_stop(struct fec_softc *sc)
 
timeout_del(&sc->sc_tick);
 
-   /* reset the controller */
-   HSET4(sc, ENET_ECR, ENET_ECR_RESET);
-   while(HREAD4(sc, ENET_ECR) & ENET_ECR_RESET);
+   mii_down(&sc->sc_mii);
 }
 
 void
@@ -996,6 +997,7 @@ fec_miibus_readreg(struct device *dev, int phy, int reg)
 {
int r = 0;
struct fec_softc *sc = (struct fec_softc *)dev;
+   u_int timo = ENET_MII_TIMEOUT;
 
HSET4(sc, ENET_EIR, ENET_EIR_MII);
 
@@ -1003,10 +1005,16 @@ fec_miibus_readreg(struct device *dev, int phy, int reg)
ENET_MMFR_ST | ENET_MMFR_OP_RD | ENET_MMFR_TA |
phy << ENET_MMFR_PA_SHIFT | reg << ENET_MMFR_RA_SHIFT);
 
-   while(!(HREAD4(sc, ENET_EIR) & ENET_EIR_MII));
+   while (!(HREAD4(sc, ENET_EIR) & ENET_EIR_MII) && --timo)
+   delay(5);
 
r = bus_space_read_4(sc->sc_iot, sc->sc_ioh, ENET_MMFR);
 
+#ifdef DIAGNOSTIC
+   if (!timo)
+   printf("%s: %s timeout\n", sc->sc_dev.dv_xname, __func__);
+#endif
+
return (r & 0x);
 }
 
@@ -1014,6 +1022,7 @@ void
 fec_miibus_writereg(struct device *dev, int phy, int reg, int val)
 {
struct fec_softc *sc = (struct fec_softc *)dev;
+   u_int timo = ENET_MII_TIMEOUT;
 
HSET4(sc, ENET_EIR, ENET_EIR_MII);
 
@@ -1022,7 +1031,12 @@ fec_miibus_writereg(struct device *dev, int phy, int 
reg, int val)
phy << ENET_MMFR_PA_SHIFT | reg << ENET_MMFR_RA_SHIFT |
(val & 0x));
 
-   while(!(HREAD4(sc, ENET_EIR) & ENET_EIR_MII));
+   while (!(HREAD4(sc, ENET_EIR) & ENET_EIR_MII) && --timo)
+   delay(5);
+#ifdef DIAGNOSTIC
+   if (!timo)
+   printf("%s: %s timeout\n", sc->sc_dev.dv_xname, __func__);
+#endif
 
return;
 }



Re: armv7/sxie: enable phy-supply

2017-11-29 Thread Artturi Alm
On Wed, Nov 29, 2017 at 12:37:23AM +1100, Jonathan Gray wrote:
> On Sun, Nov 26, 2017 at 06:52:42PM +0200, Artturi Alm wrote:
> > Hi,
> > 
> > unless i failed w/grep, only 4 boards with dts in u-boot/linux need this,
> > but i've got one of those, so this would be much appreciated:)
> > 
> > -Artturi
> 
> This seems reasonable and there is no non-panic error path
> there currently to add a regulator_disable() call to.
> 
> Changing the variable name to phy_supply would match the existing
> code in sys/dev/fdt.
> 

Like this?

-Artturi


diff --git a/sys/arch/armv7/sunxi/sxie.c b/sys/arch/armv7/sunxi/sxie.c
index 116fda5f8d7..41c378a7ef7 100644
--- a/sys/arch/armv7/sunxi/sxie.c
+++ b/sys/arch/armv7/sunxi/sxie.c
@@ -51,6 +51,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 /* configuration registers */
@@ -212,6 +213,7 @@ sxie_attach(struct device *parent, struct device *self, 
void *aux)
struct fdt_attach_args *faa = aux;
struct mii_data *mii;
struct ifnet *ifp;
+   int phy_supply;
int s;
 
if (faa->fa_nreg < 1)
@@ -230,6 +232,11 @@ sxie_attach(struct device *parent, struct device *self, 
void *aux)
 
clock_enable_all(faa->fa_node);
 
+   /* Power up PHY. */
+   phy_supply = OF_getpropint(faa->fa_node, "phy-supply", 0);
+   if (phy_supply)
+   regulator_enable(phy_supply);
+
sxie_socware_init(sc);
sc->txf_inuse = 0;
 



armv7/sxitimer difference between systat & vmstat -i

2017-11-27 Thread Artturi Alm
Hi,

i had forgotten about this already, but this has existed for a while.
systat does consistently show "66 tick"(around 108 for stattick), while

root@av7marsb:~ # vmstat -i
interrupt   total rate
irq32/sximmc0   35222   19
irq55/sxie0  38602
irq1/com0   172229
irq22/tick 181011   99
irq23/stattick 293512  162
Total  530827  293

how come there is such consistent difference? guessing they must source
time differently, so does either use interface leading to rtc _gettime()
instead of timecounters _get_timecount()?

while trying to fix this(, before remembering about "vmstat -i"), i saw
this sillyness in sxitimer irq handlers, unconditional looping that can
be avoided w/slight reordering, and given how it doesn't support other
clocksources, i think it does make sense to avoid the useless bus_space
branching for TIMER_OSC24M-bit while restarting the timers too.

what i mean with above is, given how there is such _sync "price to pay",
for touching _INTV; timer needs to be stopped, and shouldn't be enabled
until 2*Tcycles has passed. it doesn't make sense to delay disabling
to the end right before it is to be restarted.

-Artturi



diff --git a/sys/arch/armv7/sunxi/sxitimer.c b/sys/arch/armv7/sunxi/sxitimer.c
index 65d455adaeb..8abd2137304 100644
--- a/sys/arch/armv7/sunxi/sxitimer.c
+++ b/sys/arch/armv7/sunxi/sxitimer.c
@@ -71,6 +71,9 @@
 #defineTIMER_CONTINOUS (0 << 7)
 #defineTIMER_SINGLESHOT(1 << 7)
 
+#defineTIMER_RESTART   (TIMER_ENABLE | TIMER_RELOAD | \
+   TIMER_OSC24M | TIMER_SINGLESHOT)
+
 #defineTICKTIMER   0
 #defineSTATTIMER   1
 #defineCNTRTIMER   2
@@ -84,8 +87,8 @@ int   sxitimer_statintr(void *);
 void   sxitimer_cpu_initclocks(void);
 void   sxitimer_setstatclockrate(int);
 uint64_t   sxitimer_readcnt64(void);
-uint32_t   sxitimer_readcnt32(void);
-void   sxitimer_sync(void);
+static inline uint32_t sxitimer_readcnt32(void);
+static inline void sxitimer_sync(uint32_t);
 void   sxitimer_delay(u_int);
 
 u_int sxitimer_get_timecount(struct timecounter *);
@@ -290,7 +293,6 @@ int
 sxitimer_tickintr(void *frame)
 {
uint32_t now, nextevent;
-   uint32_t val;
int rc = 0;
 
splassert(IPL_CLOCK);   
@@ -299,8 +301,11 @@ sxitimer_tickintr(void *frame)
bus_space_write_4(sxitimer_iot, sxitimer_ioh,
TIMER_ISR, TIMER_IRQ(TICKTIMER));
 
-   now = sxitimer_readcnt32();
+   /* stop/disable for sync */
+   bus_space_write_4(sxitimer_iot, sxitimer_ioh,
+   TIMER_CTRL(TICKTIMER), 0);
 
+   now = sxitimer_readcnt32();
while ((int32_t)(now - sxitimer_tick_nextevt) < 0) {
sxitimer_tick_nextevt -= sxitimer_tick_tpi;
sxitimer_ticks_err_sum += sxitimer_ticks_err_cnt;
@@ -328,21 +333,13 @@ sxitimer_tickintr(void *frame)
sxitimer_tick_nextevt = now;
}
 
-   val = bus_space_read_4(sxitimer_iot, sxitimer_ioh,
-   TIMER_CTRL(TICKTIMER));
-   bus_space_write_4(sxitimer_iot, sxitimer_ioh,
-   TIMER_CTRL(TICKTIMER), val & ~TIMER_ENABLE);
-
-   sxitimer_sync();
+   sxitimer_sync(now);
 
bus_space_write_4(sxitimer_iot, sxitimer_ioh,
TIMER_INTV(TICKTIMER), nextevent);
 
-   val = bus_space_read_4(sxitimer_iot, sxitimer_ioh,
-   TIMER_CTRL(TICKTIMER));
bus_space_write_4(sxitimer_iot, sxitimer_ioh,
-   TIMER_CTRL(TICKTIMER),
-   val | TIMER_ENABLE | TIMER_RELOAD | TIMER_SINGLESHOT);
+   TIMER_CTRL(TICKTIMER), TIMER_RESTART);
 
return rc;
 }
@@ -351,7 +348,6 @@ int
 sxitimer_statintr(void *frame)
 {
uint32_t now, nextevent, r;
-   uint32_t val;
int rc = 0;
 
splassert(IPL_STATCLOCK);   
@@ -360,6 +356,10 @@ sxitimer_statintr(void *frame)
bus_space_write_4(sxitimer_iot, sxitimer_ioh,
TIMER_ISR, TIMER_IRQ(STATTIMER));
 
+   /* stop/disable for sync */
+   bus_space_write_4(sxitimer_iot, sxitimer_ioh,
+   TIMER_CTRL(STATTIMER), 0);
+
now = sxitimer_readcnt32();
while ((int32_t)(now - sxitimer_stat_nextevt) < 0) {
do {
@@ -386,21 +386,13 @@ sxitimer_statintr(void *frame)
sxitimer_stat_nextevt = now;
}
 
-   val = bus_space_read_4(sxitimer_iot, sxitimer_ioh,
-   TIMER_CTRL(STATTIMER));
-   bus_space_write_4(sxitimer_iot, sxitimer_ioh,
-   TIMER_CTRL(STATTIMER), val & ~TIMER_ENABLE);
-
-   sxitimer_sync();
+   sxitimer_sync(now);
 
bus_space_write_4(sxitimer_iot, sxitimer_ioh,
TIMER_INTV(STATTIMER), nextevent);
 
-   val = bus_space_read_4(sxitimer_iot, sxitimer_ioh,
-   TIMER_CTRL(STATTIMER));
 

armv7/sxie: enable phy-supply

2017-11-26 Thread Artturi Alm
Hi,

unless i failed w/grep, only 4 boards with dts in u-boot/linux need this,
but i've got one of those, so this would be much appreciated:)

-Artturi


diff --git a/sys/arch/armv7/sunxi/sxie.c b/sys/arch/armv7/sunxi/sxie.c
index 116fda5f8d7..b5edab31a09 100644
--- a/sys/arch/armv7/sunxi/sxie.c
+++ b/sys/arch/armv7/sunxi/sxie.c
@@ -51,6 +51,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 /* configuration registers */
@@ -212,6 +213,7 @@ sxie_attach(struct device *parent, struct device *self, 
void *aux)
struct fdt_attach_args *faa = aux;
struct mii_data *mii;
struct ifnet *ifp;
+   int physupply;
int s;
 
if (faa->fa_nreg < 1)
@@ -233,6 +235,11 @@ sxie_attach(struct device *parent, struct device *self, 
void *aux)
sxie_socware_init(sc);
sc->txf_inuse = 0;
 
+   /* Power up PHY. */
+   physupply = OF_getpropint(faa->fa_node, "phy-supply", 0);
+   if (physupply)
+   regulator_enable(physupply);
+
sc->sc_ih = arm_intr_establish_fdt(faa->fa_node, IPL_NET,
sxie_intr, sc, sc->sc_dev.dv_xname);
 



Re: Regulators as sensors?

2017-11-26 Thread Artturi Alm
On Tue, Nov 21, 2017 at 10:31:47PM +0100, Mark Kettenis wrote:
> The diff below exposes voltage regulators as sensors.  This makes it
> easy to look at the current settings of these regulators.  The
> downside is that these aren't really sensors as the voltages are not
> actually measured.
> 
> The functionality is optional; callers can pass NULL in the
> regulator_register() if the regulators aren't particularly
> interesting.
> 
> This is what it looks like on the rk3399-firefly:
> 
> milhaud$ sysctl hw.sensors
> hw.sensors.rktemp0.temp0=23.89 degC (CPU)
> hw.sensors.rktemp0.temp1=28.75 degC (GPU)
> hw.sensors.rkpmic0.volt0=0.90 VDC (vdd_cpu_l)
> hw.sensors.rkpmic0.volt1=1.80 VDC (vcc1v8_dvp)
> hw.sensors.rkpmic0.volt2=1.80 VDC (vcc1v8_pmu)
> hw.sensors.rkpmic0.volt3=3.00 VDC (vcc_sd)
> hw.sensors.rkpmic0.volt4=1.80 VDC (vcca1v8_codec)
> hw.sensors.rkpmic0.volt5=3.00 VDC (vcc_3v0)
> 
> thoughts?
> 

How about increasing usefulness by skipping those where:
regulator-min == -max && regulator-always-on ?

"eeprom -p" does cover those as is.
-Artturi

> 
> Index: sys/dev/ofw/ofw_regulator.c
> ===
> RCS file: /cvs/src/sys/dev/ofw/ofw_regulator.c,v
> retrieving revision 1.2
> diff -u -p -r1.2 ofw_regulator.c
> --- sys/dev/ofw/ofw_regulator.c   18 Nov 2017 13:48:50 -  1.2
> +++ sys/dev/ofw/ofw_regulator.c   21 Nov 2017 21:19:59 -
> @@ -15,9 +15,10 @@
>   * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
>   */
>  
> -#include 
> +#include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -28,13 +29,24 @@ LIST_HEAD(, regulator_device) regulator_
>   LIST_HEAD_INITIALIZER(regulator_devices);
>  
>  void
> -regulator_register(struct regulator_device *rd)
> +regulator_register(struct regulator_device *rd, struct ksensordev *sensdev)
>  {
>   rd->rd_phandle = OF_getpropint(rd->rd_node, "phandle", 0);
>   if (rd->rd_phandle == 0)
>   return;
>  
>   LIST_INSERT_HEAD(®ulator_devices, rd, rd_list);
> +
> + if (sensdev) {
> + rd->rd_sens = malloc(sizeof(struct ksensor), M_DEVBUF,
> + M_WAITOK | M_ZERO);
> + OF_getprop(rd->rd_node, "regulator-name",
> + rd->rd_sens->desc, sizeof(rd->rd_sens->desc));
> + rd->rd_sens->desc[sizeof(rd->rd_sens->desc) - 1] = 0;
> + rd->rd_sens->type = SENSOR_VOLTS_DC;
> + rd->rd_sens->value = rd->rd_get_voltage(rd->rd_cookie);
> + sensor_attach(sensdev, rd->rd_sens);
> + }
>  }
>  
>  int
> @@ -121,14 +133,20 @@ int
>  regulator_set_voltage(uint32_t phandle, uint32_t voltage)
>  {
>   struct regulator_device *rd;
> + int ret;
>  
>   LIST_FOREACH(rd, ®ulator_devices, rd_list) {
>   if (rd->rd_phandle == phandle)
>   break;
>   }
>  
> - if (rd && rd->rd_set_voltage)
> - return rd->rd_set_voltage(rd->rd_cookie, voltage);
> + if (rd && rd->rd_set_voltage) {
> + ret = rd->rd_set_voltage(rd->rd_cookie, voltage);
> + if (ret == 0 && rd->rd_sens)
> + rd->rd_sens->value = rd->rd_get_voltage(rd->rd_cookie);
> +
> + return ret;
> + }
>  
>   return -1;
>  }
> Index: sys/dev/ofw/ofw_regulator.h
> ===
> RCS file: /cvs/src/sys/dev/ofw/ofw_regulator.h,v
> retrieving revision 1.3
> diff -u -p -r1.3 ofw_regulator.h
> --- sys/dev/ofw/ofw_regulator.h   18 Nov 2017 21:03:23 -  1.3
> +++ sys/dev/ofw/ofw_regulator.h   21 Nov 2017 21:19:59 -
> @@ -18,6 +18,9 @@
>  #ifndef _DEV_OFW_REGULATOR_H_
>  #define _DEV_OFW_REGULATOR_H_
>  
> +struct ksensor;
> +struct ksensordev;
> +
>  struct regulator_device {
>   int rd_node;
>   void*rd_cookie;
> @@ -26,9 +29,11 @@ struct regulator_device {
>  
>   LIST_ENTRY(regulator_device) rd_list;
>   uint32_t rd_phandle;
> +
> + struct ksensor *rd_sens;
>  };
>  
> -void regulator_register(struct regulator_device *);
> +void regulator_register(struct regulator_device *, struct ksensordev *);
>  
>  int  regulator_enable(uint32_t);
>  int  regulator_disable(uint32_t);
> Index: sys/dev/fdt/rkpmic.c
> ===
> RCS file: /cvs/src/sys/dev/fdt/rkpmic.c,v
> retrieving revision 1.3
> diff -u -p -r1.3 rkpmic.c
> --- sys/dev/fdt/rkpmic.c  18 Nov 2017 20:29:51 -  1.3
> +++ sys/dev/fdt/rkpmic.c  21 Nov 2017 21:19:59 -
> @@ -19,6 +19,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -70,6 +71,7 @@ struct rkpmic_softc {
>   i2c_addr_t sc_addr;
>  
>   struct todr_chip_handle sc_todr;
> + struct ksensordev sc_sensordev;
>  };
>  
>  int  rkpmic_match(struct device *, void *, void *);
> @@ -122,6 +124,11 @@ rkpmic_attach(struct device *parent, str
>

armv7/sxie: some fixes

2017-11-25 Thread Artturi Alm
Hi,

kind of embarassing, but i guess i originally went w/what was enough to
get booting/building over eth, and i blindly followed freebsd driver
more than i should of - as it is clearly nothing but copypaste with
even comments included from linux.. yep.

so sxie has these bugs like trying to flush via rx filter control register
etc., just like every other driver(free,net,linux) i've seen for allwinner
emac still do.
mostly fixed in the diff below, that is huge, i know, but anyone is free
to pick what they want, if anything. :)

i used UM10326.pdf by NXP for ie. the _softreset() below, more specifically
"Chapter 14: LPC32x0 Ethernet Media Access Controller (MAC)".
freebsd has driver for it too, but the "scatter gather dma engines" in it
were different enough to what exists for sun4i emac, so i gave up trying to
fit the pieces before getting hands dirty.

-Artturi


diff --git a/sys/arch/armv7/sunxi/sxie.c b/sys/arch/armv7/sunxi/sxie.c
index 116fda5f8d7..e428425d7f8 100644
--- a/sys/arch/armv7/sunxi/sxie.c
+++ b/sys/arch/armv7/sunxi/sxie.c
@@ -51,105 +51,182 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 
-/* configuration registers */
-#defineSXIE_CR 0x
+#if defined(DEBUG) || defined(DIAGNOSTIC)
+#defineSXIE_CD (ifp->if_flags & IFF_DEBUG)
+#defineSXIEDBG(x)  do { if (SXIE_CD) printf((x)); } while (0)
+#else
+#defineSXIE_CD (0)
+#defineSXIEDBG(x)  do { } while (0)
+#endif
+
+/* control registers */
+#defineSXIE_CMDR   0x
 #defineSXIE_TXMODE 0x0004
-#defineSXIE_TXFLOW 0x0008
+#defineSXIE_TXFLOW 0x0008  /* unused */
 #defineSXIE_TXCR0  0x000c
 #defineSXIE_TXCR1  0x0010
 #defineSXIE_TXINS  0x0014
+/*
+ * XXX was wondering, what if these TXPKTLEN registers
+ * are actually part of memory mapped tx 'fake' descriptors,
+ * something like w/DMA but only via register map or something?
+ * should add some dbg and try to figure out:)
+ */
 #defineSXIE_TXPKTLEN0  0x0018
 #defineSXIE_TXPKTLEN1  0x001c
-#defineSXIE_TXSR   0x0020
+#defineSXIE_TXSR   0x0020  /* unused */
 #defineSXIE_TXIO0  0x0024
-#defineSXIE_TXIO1  0x0028
-#defineSXIE_TXTSVL00x002c
-#defineSXIE_TXTSVH00x0030
-#defineSXIE_TXTSVL10x0034
-#defineSXIE_TXTSVH10x0038
-#defineSXIE_RXCR   0x003c
+#defineSXIE_TXIO1  0x0028  /* unused */
+#defineSXIE_TXTSVL00x002c  /* unused */
+#defineSXIE_TXTSVH00x0030  /* unused */
+#defineSXIE_TXTSVL10x0034  /* unused */
+#defineSXIE_TXTSVH10x0038  /* unused */
+
+/* receive filter registers */
+#defineSXIE_RXFILTER_CTRL  0x003c
 #defineSXIE_RXHASH00x0040
 #defineSXIE_RXHASH10x0044
-#defineSXIE_RXSR   0x0048
-#defineSXIE_RXIO   0x004C
+
+/* dunno.. */
+#defineSXIE_RXSR   0x0048  /* unused */
+#defineSXIE_RXIO   0x004c
 #defineSXIE_RXFBC  0x0050
+
+/* module control registers */
 #defineSXIE_INTCR  0x0054
 #defineSXIE_INTSR  0x0058
-#defineSXIE_MACCR0 0x005C
-#defineSXIE_MACCR1 0x0060
-#defineSXIE_MACIPGT0x0064
-#defineSXIE_MACIPGR0x0068
-#defineSXIE_MACCLRT0x006C
-#defineSXIE_MACMFL 0x0070
-#defineSXIE_MACSUPP0x0074
-#defineSXIE_MACTEST0x0078
-#defineSXIE_MACMCFG0x007C
-#defineSXIE_MACMCMD0x0080
-#defineSXIE_MACMADR0x0084
-#defineSXIE_MACMWTD0x0088
-#defineSXIE_MACMRDD0x008C
-#defineSXIE_MACMIND0x0090
-#defineSXIE_MACSSRR0x0094
-#defineSXIE_MACA0  0x0098
-#defineSXIE_MACA1  0x009c
-#defineSXIE_MACA2  0x00a0
+
+/* ethernet MAC registers */
+#defineSXIE_MAC0   0x005c
+#defineSXIE_MAC1   0x0060
+#defineSXIE_MAC_IPGT   0x0064
+#defineSXIE_MAC_IPGR   0x0068
+#defineSXIE_MAC_CLRT   0x006c
+#defineSXIE_MAC_MAXF   0x0070
+#defineSXIE_MAC_SUPP   0x0074
+#defineSXIE_MAC_TEST   0x0078  /* unused */
+#defineSXIE_MAC_MCFG   0x007c
+#defineSXIE_MAC_MCMD   0x0080
+#defineSXIE_MAC_MADR   0x0084
+#defineSXIE_MAC_MWTD   0x0088
+#defineSXIE_MAC_MR

armv7/sxie: gate def for emac

2017-11-19 Thread Artturi Alm
Hi,

i'm about to need this, thanks :)

-Artturi


--- a/sys/dev/fdt/sxiccmu_clocks.h
+++ b/sys/dev/fdt/sxiccmu_clocks.h
@@ -18,6 +18,7 @@
 #define A10_CLK_AHB_MMC1   35
 #define A10_CLK_AHB_MMC2   36
 #define A10_CLK_AHB_MMC3   37
+#define A10_CLK_AHB_EMAC   42
 #define A10_CLK_AHB_SATA   49
 #define A10_CLK_AHB_GMAC   66
 #define A10_CLK_APB0_PIO   74
@@ -49,6 +50,7 @@
[A10_CLK_AHB_MMC1] =   { 0x0060, 9 },
[A10_CLK_AHB_MMC2] =   { 0x0060, 10 },
[A10_CLK_AHB_MMC3] =   { 0x0060, 11 },
+   [A10_CLK_AHB_EMAC] =   { 0x0060, 17 },
[A10_CLK_AHB_SATA] =   { 0x0060, 25 },
[A10_CLK_AHB_GMAC] =   { 0x0064, 17 },
[A10_CLK_APB0_PIO] =   { 0x0068, 5 },



armv7/man4: sxitimer.4 small update

2017-11-17 Thread Artturi Alm
Hi,

variations of this timer "IP" can be found from all sunxis i've seen,
but let's add only the few where this is actually used now, instead of
keeping A20 listed.
Hopefully the addition of agtimer timer to the description makes sense too :)

-Artturi


diff --git a/share/man/man4/man4.armv7/sxitimer.4 
b/share/man/man4/man4.armv7/sxitimer.4
index 4b91d370a9f..2f9706b1203 100644
--- a/share/man/man4/man4.armv7/sxitimer.4
+++ b/share/man/man4/man4.armv7/sxitimer.4
@@ -19,14 +19,16 @@
 .Os
 .Sh NAME
 .Nm sxitimer
-.Nd A1X/A20 timer device
+.Nd A10/A10s/A13 timer device
 .Sh SYNOPSIS
 .Cd "sxitimer* at sunxi?"
 .Sh DESCRIPTION
 The
 .Nm
-driver provides support for the timer devices integrated in Allwinner 
Technology
-A1X/A20 SoCs.
+driver provides support for the timers integrated in Allwinner Technology
+SoCs, without ARM generic timer.
+.Sh SEE ALSO
+.Xr agtimer 4
 .Sh HISTORY
 The
 .Nm



man4/openprom.4: striking ioctl

2017-11-17 Thread Artturi Alm
Hi,

highly visible outside the default output,
ie. here: https://man.openbsd.org/openprom

-Artturi


diff --git a/share/man/man4/man4.macppc/openprom.4 
b/share/man/man4/man4.macppc/openprom.4
index 1f5145c578f..580caaea517 100644
--- a/share/man/man4/man4.macppc/openprom.4
+++ b/share/man/man4/man4.macppc/openprom.4
@@ -88,7 +88,7 @@ The following ioctls are supported:
 .Bl -tag -width OPIOCGETOPTNODE
 .It Dv OPIOCGETOPTNODE
 Takes nothing, and fills in the options node number.
-.It OPIOCGETNEXT
+.It Dv OPIOCGETNEXT
 Takes a node number and returns the number of the following node.
 The node following the last node is number 0;
 the node following number 0 is the first node.
diff --git a/share/man/man4/man4.sparc64/openprom.4 
b/share/man/man4/man4.sparc64/openprom.4
index 78e6b036735..1c6efca94d8 100644
--- a/share/man/man4/man4.sparc64/openprom.4
+++ b/share/man/man4/man4.sparc64/openprom.4
@@ -88,7 +88,7 @@ The following ioctls are supported:
 .Bl -tag -width OPIOCGETOPTNODE
 .It Dv OPIOCGETOPTNODE
 Takes nothing, and fills in the options node number.
-.It OPIOCGETNEXT
+.It Dv OPIOCGETNEXT
 Takes a node number and returns the number of the following node.
 The node following the last node is number 0;
 the node following number 0 is the first node.



Re: Tweak OF_getnodebyname()

2017-11-17 Thread Artturi Alm
On Thu, Nov 16, 2017 at 09:39:20PM +0100, Mark Kettenis wrote:
> The current FDT implementation is fairly useless since it doesn't
> actually look at the child nodes.  The macppc implementation walks the
> entire tree.  But all current use cases of this function only look at
> children of the passed node.  Diff below makes OF_getnodebyname()
> behave like that.
> 
> ok?
> 

Makes sense, but i'd be tempted to rename to OF_getchildbyname().
tested on top of 6.2, and /dev/openprom did work with eeprom -p as always,
with bbb+cubie2+panda+wandboard.
slightly related, as the options thing in openprom was the only user on arm,
should it be "chosen" there instead of "options" ?

while there, maybe this too:

diff --git a/sys/dev/ofw/fdt.c b/sys/dev/ofw/fdt.c
index 54e1e01edbb..e9a717fae8f 100644
--- a/sys/dev/ofw/fdt.c
+++ b/sys/dev/ofw/fdt.c
@@ -336,7 +336,7 @@ fdt_node_property_int(void *node, char *name, int *out)
 }
 
 /*
- * Retrieves next node, skipping all the children nodes of the pointed node
+ * Retrieves the first child of an node.
  */
 void *
 fdt_child_node(void *node)



-Artturi

> 
> Index: ofw/fdt.c
> ===
> RCS file: /cvs/src/sys/dev/ofw/fdt.c,v
> retrieving revision 1.20
> diff -u -p -r1.20 fdt.c
> --- ofw/fdt.c 12 Mar 2017 11:44:42 -  1.20
> +++ ofw/fdt.c 16 Nov 2017 20:28:27 -
> @@ -773,11 +773,9 @@ OF_getnodebyname(int handle, const char 
>   if (handle == 0)
>   node = fdt_find_node("/");
>  
> - while (node) {
> + for (node = fdt_child_node(node); node; node = fdt_next_node(node)) {
>   if (strcmp(name, fdt_node_name(node)) == 0)
>   break;
> -
> - node = fdt_next_node(node);
>   }
>  
>   return node ? ((char *)node - (char *)tree.header) : 0;
> 



Re: armv7/arm64: enable fifo in com_fdt for "snps,dw-apb-uart"

2017-11-14 Thread Artturi Alm
On Mon, Nov 13, 2017 at 10:02:35PM +0100, Mark Kettenis wrote:
> > Date: Fri, 10 Nov 2017 00:16:26 +0200
> > From: Artturi Alm 
> > 
> > Hi,
> > 
> > does also remove ti,omapX-uart compatibles from arm64 com_fdt,
> > as they're never to be found there.
> > iirc. the lenght is based on minimal lenght i found from any datasheet
> > for SoCs w/"snps,dw-apb-uart", and conclusions drawn from gpl-sources.
> 
> As far as I can tell the FIFO functionality is optional for the
> Synopys "IP".  It's just safer to not bother with the FIFO.
> 

Well, we're setting up the busy interrupt handling w/o consulting DT too.
i would be more worried of running into that, than finding this UART w/o
fifo enabled, when even the cheapest cheapshit SoCs got this fifo(=sunxi).
See "snps,uart-16550-compatible" in snps-dw-apb-uart.txt if you care, i don't.

diff below has safer version for enabling the fifo i have ran w/before com_fdt.
-Artturi


diff --git a/sys/arch/arm64/dev/com_fdt.c b/sys/arch/arm64/dev/com_fdt.c
index 9f2a8eb760a..30234188c82 100644
--- a/sys/arch/arm64/dev/com_fdt.c
+++ b/sys/arch/arm64/dev/com_fdt.c
@@ -35,10 +35,15 @@
 #include 
 #include 
 
-#define com_usr 31 /* Synopsys DesignWare UART */
+/* Synopsys DesignWare UART specific registers */
+#definecom_usr 31  /* UART Status Register */
+#definecom_cpr 244 /* UART Component Paramter Register */
+#defineCPR_FIFOSZ(x)   (((x) & 0x00ff) >> 12)
+#definecom_cvr 248 /* UART Component Version Register */
 
 intcom_fdt_match(struct device *, void *, void *);
 void   com_fdt_attach(struct device *, struct device *, void *);
+intcom_fdt_fifo_designware(struct com_softc *);
 intcom_fdt_intr_designware(void *);
 
 struct com_fdt_softc {
@@ -155,6 +160,12 @@ com_fdt_attach(struct device *parent, struct device *self, 
void *aux)
return;
}
 
+   if (OF_is_compatible(faa->fa_node, "snps,dw-apb-uart")) {
+   sc->sc.sc_fifolen = com_fdt_fifo_designware(&sc->sc);
+   if (sc->sc.sc_fifolen > 0)
+   sc->sc.sc_uarttype = COM_UART_16550A;
+   }
+
pinctrl_byname(faa->fa_node, "default");
 
com_attach_subr(&sc->sc);
@@ -163,6 +174,15 @@ com_fdt_attach(struct device *parent, struct device *self, 
void *aux)
sc, sc->sc.sc_dev.dv_xname);
 }
 
+int
+com_fdt_fifo_designware(struct com_softc *sc)
+{
+   if (bus_space_read_4(sc->sc_iot, sc->sc_ioh, com_cvr) == 0)
+   return 0;
+
+   return CPR_FIFOSZ(bus_space_read_4(sc->sc_iot, sc->sc_ioh, com_cpr));
+}
+
 int
 com_fdt_intr_designware(void *cookie)
 {
diff --git a/sys/arch/armv7/dev/com_fdt.c b/sys/arch/armv7/dev/com_fdt.c
index 00504801850..7fe0f2bebdc 100644
--- a/sys/arch/armv7/dev/com_fdt.c
+++ b/sys/arch/armv7/dev/com_fdt.c
@@ -36,10 +36,15 @@
 #include 
 #include 
 
-#define com_usr 31 /* Synopsys DesignWare UART */
+/* Synopsys DesignWare UART specific registers */
+#definecom_usr 31  /* UART Status Register */
+#definecom_cpr 244 /* UART Component Paramter Register */
+#defineCPR_FIFOSZ(x)   (((x) & 0x00ff) >> 12)
+#definecom_cvr 248 /* UART Component Version Register */
 
 intcom_fdt_match(struct device *, void *, void *);
 void   com_fdt_attach(struct device *, struct device *, void *);
+intcom_fdt_fifo_designware(struct com_softc *);
 intcom_fdt_intr_designware(void *);
 
 extern int comcnspeed;
@@ -159,6 +164,12 @@ com_fdt_attach(struct device *parent, struct device *self, 
void *aux)
return;
}
 
+   if (OF_is_compatible(faa->fa_node, "snps,dw-apb-uart")) {
+   sc->sc.sc_fifolen = com_fdt_fifo_designware(&sc->sc);
+   if (sc->sc.sc_fifolen > 0)
+   sc->sc.sc_uarttype = COM_UART_16550A;
+   }
+
pinctrl_byname(faa->fa_node, "default");
 
com_attach_subr(&sc->sc);
@@ -167,6 +178,15 @@ com_fdt_attach(struct device *parent, struct device *self, 
void *aux)
sc, sc->sc.sc_dev.dv_xname);
 }
 
+int
+com_fdt_fifo_designware(struct com_softc *sc)
+{
+   if (bus_space_read_4(sc->sc_iot, sc->sc_ioh, com_cvr) == 0)
+   return 0;
+
+   return CPR_FIFOSZ(bus_space_read_4(sc->sc_iot, sc->sc_ioh, com_cpr));
+}
+
 int
 com_fdt_intr_designware(void *cookie)
 {



Re: ofw_clock: reset_deassert and clock_enable order of use Qs

2017-11-12 Thread Artturi Alm
On Sat, Oct 07, 2017 at 10:16:05AM +0300, Artturi Alm wrote:
> Hi,
> 
> 
> what was the cause of these delays? i just spotted this, so untested on
> likely more affected HW(sunxi A64/H3 and rockchips), but just for discussion
> about the delays/ordering? are they really needed like that?
> 
> i don't remember having read anything about the order of these from
> devicetree-binding .txt's i have read so far from u-boot/linux.
> 
> "Make sure that the reset signal has been released
> before the release of module clock gating;"
> 
> above can be found from under the short CCU "x.3.6 Programming Guidelines"[0].
> maybe this ordering should be verified from somewhere else, as atleast
> for my sorry non-nativeNlazy grammar i could understand wrong, what is being
> meant w/"the release" above.. but even w/above discarded, my intuition does
> favor deasserting reset before gating sclki, hence the diff.
> 
> the diff below booted faster with no observable changes in dmesg on cubie2,
> and otherwise succesfully on panda and wandboard.
> 
> -Artturi
> 

Ping?

i think i've passed by sources in both fbsd&nbsd since email above
suggesting the order should be like in the diff.
does anyone want me to provide more on my findings about this,
or anything else?

-Artturi

> [0] sources:
> A64 User Manual(Revision 1.0):
> "3.3.6.4. Gating and reset" Page 147
> H3 Datasheet(Revision1.2):
> "4.3.6.4. Gating and reset" Page 142
> 
> 
> 
> diff --git a/sys/dev/fdt/ehci_fdt.c b/sys/dev/fdt/ehci_fdt.c
> index 55fe75f1a9c..fae54ac11ee 100644
> --- a/sys/dev/fdt/ehci_fdt.c
> +++ b/sys/dev/fdt/ehci_fdt.c
> @@ -91,9 +91,10 @@ ehci_fdt_attach(struct device *parent, struct device 
> *self, void *aux)
>  
>   pinctrl_byname(sc->sc_node, "default");
>  
> - clock_enable_all(sc->sc_node);
>   reset_deassert_all(sc->sc_node);
>  
> + clock_enable_all(sc->sc_node);
> +
>   /* Disable interrupts, so we don't get any spurious ones. */
>   sc->sc.sc_offs = EREAD1(&sc->sc, EHCI_CAPLENGTH);
>   EOWRITE2(&sc->sc, EHCI_USBINTR, 0);
> diff --git a/sys/dev/fdt/if_dwge_fdt.c b/sys/dev/fdt/if_dwge_fdt.c
> index edfe5acb992..00668980f4a 100644
> --- a/sys/dev/fdt/if_dwge_fdt.c
> +++ b/sys/dev/fdt/if_dwge_fdt.c
> @@ -125,10 +125,10 @@ dwge_fdt_attach(struct device *parent, struct device 
> *self, void *aux)
>   else if (OF_is_compatible(faa->fa_node, "rockchip,rk3399-gmac"))
>   dwge_fdt_attach_rockchip(fsc);
>  
> + reset_deassert(faa->fa_node, "stmmaceth");
> +
>   /* Enable clock. */
>   clock_enable(faa->fa_node, "stmmaceth");
> - reset_deassert(faa->fa_node, "stmmaceth");
> - delay(5000);
>  
>   /* Power up PHY. */
>   phy_supply = OF_getpropint(faa->fa_node, "phy-supply", 0);
> diff --git a/sys/dev/fdt/if_dwxe.c b/sys/dev/fdt/if_dwxe.c
> index 22a383c06ef..6e303745ec3 100644
> --- a/sys/dev/fdt/if_dwxe.c
> +++ b/sys/dev/fdt/if_dwxe.c
> @@ -376,10 +376,10 @@ dwxe_attach(struct device *parent, struct device *self, 
> void *aux)
>  
>   pinctrl_byname(faa->fa_node, "default");
>  
> + reset_deassert(faa->fa_node, "stmmaceth");
> +
>   /* Enable clock. */
>   clock_enable(faa->fa_node, "stmmaceth");
> - reset_deassert(faa->fa_node, "stmmaceth");
> - delay(5000);
>  
>   /* Power up PHY. */
>   phy_supply = OF_getpropint(faa->fa_node, "phy-supply", 0);
> diff --git a/sys/dev/fdt/sximmc.c b/sys/dev/fdt/sximmc.c
> index 7acb8f55d56..9ed2ae09fe4 100644
> --- a/sys/dev/fdt/sximmc.c
> +++ b/sys/dev/fdt/sximmc.c
> @@ -366,11 +366,10 @@ sximmc_attach(struct device *parent, struct device 
> *self, void *aux)
>  
>   pinctrl_byname(faa->fa_node, "default");
>  
> + reset_deassert_all(faa->fa_node);
> +
>   /* enable clock */
>   clock_enable(faa->fa_node, NULL);
> - delay(5000);
> -
> - reset_deassert_all(faa->fa_node);
>  
>   /*
>* The FIFO register is in a different location on the
> diff --git a/sys/dev/fdt/sxitwi.c b/sys/dev/fdt/sxitwi.c
> index f53f2bfd594..c80bdc2ab06 100644
> --- a/sys/dev/fdt/sxitwi.c
> +++ b/sys/dev/fdt/sxitwi.c
> @@ -218,6 +218,8 @@ sxitwi_attach(struct device *parent, struct device *self, 
> void *aux)
>  
>   pinctrl_byname(faa->fa_node, "default");
>  
> + reset_deassert_all(faa->fa_node);
> +
>   /* Enable clock */
>   clock_enable(faa->fa_node, NULL);
>  



armv7/sxie: unused global

2017-11-12 Thread Artturi Alm
Hi,

one less useless leftover.

-Artturi


diff --git a/sys/arch/armv7/sunxi/sxie.c b/sys/arch/armv7/sunxi/sxie.c
index 0e062bac1fb..2ac4dda7c6b 100644
--- a/sys/arch/armv7/sunxi/sxie.c
+++ b/sys/arch/armv7/sunxi/sxie.c
@@ -168,8 +168,6 @@ struct sxie_softc {
uint32_ttxf_inuse;
 };
 
-struct sxie_softc *sxie_sc;
-
 intsxie_match(struct device *, void *, void *);
 void   sxie_attach(struct device *, struct device *, void *);
 void   sxie_setup_interface(struct sxie_softc *, struct device *);
@@ -271,8 +269,6 @@ sxie_attach(struct device *parent, struct device *self, 
void *aux)
if_attach(ifp);
ether_ifattach(ifp);
splx(s);
-
-   sxie_sc = sc;
 }
 
 void



Re: armv7/sxie: less ierror

2017-11-12 Thread Artturi Alm
On Sun, Nov 12, 2017 at 07:07:13PM +0100, Mark Kettenis wrote:
> > Date: Sun, 12 Nov 2017 04:58:23 +0200
> > From: Artturi Alm 
> > 
> > Hi,
> > 
> > i'm likely responsible, for having sent the diff that introduced this.
> > minimal fix taken w/diff -U10, to show the obvious dup++.
> > 
> > -Artturi
> 
> I think it makes more sense to fix it this way:
> 
> ok?
> 

yep, exactly what i had before minimalizing the diff.

-Artturi

> 
> Index: arch/armv7/sunxi/sxie.c
> ===
> RCS file: /cvs/src/sys/arch/armv7/sunxi/sxie.c,v
> retrieving revision 1.25
> diff -u -p -r1.25 sxie.c
> --- arch/armv7/sunxi/sxie.c   22 Jan 2017 10:17:37 -  1.25
> +++ arch/armv7/sunxi/sxie.c   12 Nov 2017 18:05:46 -
> @@ -595,8 +595,8 @@ trynext:
>   SXISET4(sc, SXIE_RXCR, SXIE_RXFLUSH);
>   while (SXIREAD4(sc, SXIE_RXCR) & SXIE_RXFLUSH);
>   SXISET4(sc, SXIE_CR, SXIE_RX_ENABLE);
> -
> - goto err_out;
> + ifp->if_ierrors++;
> + goto done;
>   }
>   
>   reg = SXIREAD4(sc, SXIE_RXIO);
> @@ -621,13 +621,11 @@ trynext:
>   m = m_devget(&rxbuf[0], pktlen, ETHER_ALIGN);
>   if (m == NULL) {
>   ifp->if_ierrors++;
> - goto err_out;
> + goto done;
>   }
>  
>   ml_enqueue(&ml, m);
>   goto trynext;
> -err_out:
> - ifp->if_ierrors++;
>  done:
>   if_input(ifp, &ml);
>  }



Re: armv7: newfs efi-partition in when choosing manual-fdisk mbr

2017-11-11 Thread Artturi Alm
On Sun, Nov 12, 2017 at 03:17:54PM +1100, Jonathan Gray wrote:
> On Fri, Nov 10, 2017 at 10:27:36AM +0200, Artturi Alm wrote:
> > Hi,
> > 
> > currently, just editing the mbr to give more room for u-boot env growth,
> > will result in unbootable system, as the installer will fail to mount it,
> > and naturally things won't work beyond u-boot after reboot either.
> > 
> > i'm not really sure about this diff, but it does seem like it might do,
> > what i think it should? might take a while, before i can test myself, so
> > i thought i'd mail and ask, if there's a reason for how it is atm.? :)
> > 
> > -Artturi
> 
> 0x0C is only used due to the broadcom boot rom not understanding
> EFI System partition (0xEF).  That should not be set outside of arm*.
> 
> As it is the partition is larger than it needs to be as kernels
> are no longer stored there.
> 
> There is no reason to force MBR as both U-Boot and EDK2 should be able
> to cope with GPT.
> 

ok, that explains a lot, so diff withdrawn, thanks.

maybe we could use some of the now-unused EFI-partition size for bigger
default partition offset? (ie. *2 to 4096(2MiB))

-Artturi

> > 
> > 
> > diff --git a/distrib/armv7/ramdisk/install.md 
> > b/distrib/armv7/ramdisk/install.md
> > index 23d574e4e7a..1639e06c221 100644
> > --- a/distrib/armv7/ramdisk/install.md
> > +++ b/distrib/armv7/ramdisk/install.md
> > @@ -141,8 +141,14 @@ partition on the disk.
> >  $(fdisk ${_disk})
> >  __EOT
> > fdisk -e ${_disk}
> > -   disk_has $_disk mbr openbsd && return
> > -   echo No OpenBSD partition in MBR, try again. ;;
> > +   disk_has $_disk mbr efi ||
> > +   { echo No EFI(FAT id 0C) partition in MBR, try 
> > again.; continue; }
> > +   disk_has $_disk mbr efi_bootable ||
> > +   { echo No bootable EFI partition in MBR, try 
> > again.; continue; }
> > +   disk_has $_disk mbr openbsd ||
> > +   { echo No OpenBSD partition in MBR, try again.; 
> > continue; }
> > +   newfs -t ${bootfstype} ${newfs_args} ${_disk}i
> > +   return ;;
> > esac
> > done
> >  }
> > diff --git a/distrib/miniroot/install.sub b/distrib/miniroot/install.sub
> > index ef8c069588d..e204dd49d27 100644
> > --- a/distrib/miniroot/install.sub
> > +++ b/distrib/miniroot/install.sub
> > @@ -368,6 +368,8 @@ disk_has() {
> > local _p_mbr_openbsd='^..: A6 '
> > local _p_mbr_dos='^..: 06 '
> > local _p_mbr_dos_active='^\*.: 06 '
> > +   local _p_mbr_efi='^..: 0C '
> > +   local _p_mbr_efi_bootable='^\*.: 0C '
> > local _p_mbr_linux='^..: 83 '
> > local _p_sr='OPENBSD, SR'
> > local _p_sr_crypto='OPENBSD, SR CRYPTO'
> > 



  1   2   3   >