Re: Possible bug in lib/libc/gen/exec.c
we had the same issue in bionic when we removed all our alloca()s, modulo
the fact that ours is a VLA rather than alloca(), but same thing:
https://android.googlesource.com/platform/bionic/+/master/libc/bionic/exec.cpp#61
we argued that it doesn't matter in this case though because we'll touch
all the entries, in order, so there's no possibility of jumping off the end
of the stack onto another VMA.
(we have used mmap() instead in more complicated cases though.)
On Thu, Sep 16, 2021 at 1:39 PM Theo de Raadt wrote:
> Alejandro Colomar (man-pages) wrote:
>
> > Hi,
> >
> > I don't know if OpenBSD has a different implementation of alloca(3)
> > than Linux. In Linux, alloca(3) (a.k.a. __builtin_alloca()) can't
> > return NULL, as it can't detect errors.
>
> There are no alloca can return NULL.
>
> > The only way to detect an
> > error is to add a handler for SIGSEGV, AFAIK.
>
> Actually, it is worse than that. Massive alloca have been encountered
> which reach off the stack. For over 20 years we've been on a mission
> to delete alloca in our tree, and these are the last ones that remain,
> because other allocators are very difficult to use in this place.
>
> Maybe we should investigate using mmap. Of the 4 cases, 3 are not
> too difficult, but the 4th case will be very messy, including unwind
> for the 3rd case.
>
> > I found the following code in :
> >
> > argv = alloca((n + 1) * sizeof(*argv));
> > if (argv == NULL) {
> > errno = ENOMEM;
> > return (-1);
> > }
> >
> > But of course, that NULL should never happen, right?
>
> > As a side note, I think you could encapsulate the code calling
> > alloca(3) into a helper macro, to avoid repetition.
>
> I don't see how that would help anything.
>
> > I can prepare a patch if you confirm the bug.
>
> What do you propose to do in your patch?
>
>
>
Re: Possible bug in lib/libc/gen/exec.c
It always returns -1 until the world changes in some subtle way,
then the code is wrong.
The logic is supposed to return what execve returns, not reinvent
the value.
Over decades this kind of assumption can turn into a bug, so I
prefer to do it right.
Alejandro Colomar (man-pages) wrote:
> Hello Theo,
>
> On 9/16/21 10:53 PM, Theo de Raadt wrote:
> > @@ -45,25 +46,31 @@ execl(const char *name, const char *arg,
> > {
> > va_list ap;
> > char **argv;
> > - int n;
> > + size_t maplen;
> > + int save_errno, n, error;
>
> See below.
>
> > va_start(ap, arg);
> > n = 1;
> > while (va_arg(ap, char *) != NULL)
> > n++;
> > va_end(ap);
> > - argv = alloca((n + 1) * sizeof(*argv));
> > - if (argv == NULL) {
> > - errno = ENOMEM;
> > + maplen = (n + 1) * sizeof(*argv);
> > + argv = mmap(NULL, maplen, PROT_WRITE|PROT_READ,
> > + MAP_ANON|MAP_PRIVATE, -1, 0);
> > + if (argv == MAP_FAILED)
> > return (-1);
> > - }
> > va_start(ap, arg);
> > n = 1;
> > argv[0] = (char *)arg;
> > while ((argv[n] = va_arg(ap, char *)) != NULL)
> > n++;
> > va_end(ap);
> > - return (execve(name, argv, environ));
> > +
> > + error = execve(name, argv, environ);
> > + save_errno = errno;
> > + munmap(argv, maplen);
> > + errno = save_errno;
> > + return (error);
>
> This part could be simplified to:
>
> (void) execve(name, argv, environ);
> save_errno = errno;
> munmap(argv, maplen);
> errno = save_errno;
> return -1;
>
> Allowing to remove the error variable. execve(2) always returns -1.
>
> > }
> > DEF_WEAK(execl);
> > @@ -72,18 +79,21 @@ execle(const char *name, const char *arg
> > {
> > va_list ap;
> > char **argv, **envp;
> > - int n;
> > + size_t maplen;
> > + int save_errno, n, error;
>
> Same here.
>
> > @@ -91,7 +101,12 @@ execle(const char *name, const char *arg
> > n++;
> > envp = va_arg(ap, char **);
> > va_end(ap);
> > - return (execve(name, argv, envp));
> > +
> > + error = execve(name, argv, envp);
> > + save_errno = errno;
> > + munmap(argv, maplen);
> > + errno = save_errno;
> > + return error;
>
> Same here
>
> > @@ -99,25 +114,32 @@ execlp(const char *name, const char *arg
> > {
> > va_list ap;
> > char **argv;
> > - int n;
> > + size_t maplen;
> > + int save_errno, n, error;
>
> Same here.
>
>
>
> --
> Alejandro Colomar
> Linux man-pages comaintainer; https://www.kernel.org/doc/man-pages/
> http://www.alejandro-colomar.es/
Re: tls_pending(3)
On Thu, Sep 16, 2021 at 11:00:31PM +0200, Kristaps Dzonsons wrote:
> Hi,
>
> I'm porting a nonblocking, polling OpenSSL system to libtls. However, I'm
> not sure how this is non-hackily possible without SSL_pending(3) to detect
> if less data is read with tls_read() than is buffered.
>
> writer:
> tls_write(40)
>
> reader:
> poll(POLLIN, INFTIM) -> POLLIN /* descriptor has a read */
> tls_read(20) /* 20 bytes read, 20 bytes remain */
> poll(POLLIN, INFTIM) -> 0 /* data was buffered */
>
> This introduces tls_pending(3), which calls through to SSL_pending(3), and
> includes a simple example in tls_read(3).
>
> Beck's tutorial says that "libtls is designed to do the common things you do
> for making TLS connections easy", and I'm not sure my use case meets that
> standard. If it looks reasonable, however, I can also add the regression
> tests.
In general you should call tls_read() until it retruns TLS_WANT_POLL*.
Then you poll again. So you need to adapt the poll loop a bit but in most
cases this is not hard to do.
> Thank you,
>
> Kristaps
> Index: tls.c
> ===
> RCS file: /cvs/src/lib/libtls/tls.c,v
> retrieving revision 1.89
> diff -u -p -r1.89 tls.c
> --- tls.c 1 Feb 2021 15:35:41 - 1.89
> +++ tls.c 16 Sep 2021 20:57:32 -
> @@ -788,6 +788,16 @@ tls_handshake(struct tls *ctx)
> return (rv);
> }
>
> +size_t
> +tls_pending(const struct tls *ctx)
> +{
> +
> + if ((ctx->state & TLS_HANDSHAKE_COMPLETE) != 0)
> + return 0;
> +
> + return (size_t)SSL_pending(ctx->ssl_conn);
> +}
> +
> ssize_t
> tls_read(struct tls *ctx, void *buf, size_t buflen)
> {
> Index: tls.h
> ===
> RCS file: /cvs/src/lib/libtls/tls.h,v
> retrieving revision 1.58
> diff -u -p -r1.58 tls.h
> --- tls.h 22 Jan 2020 06:44:02 - 1.58
> +++ tls.h 16 Sep 2021 20:57:32 -
> @@ -177,6 +177,7 @@ int tls_connect_socket(struct tls *_ctx,
> int tls_connect_cbs(struct tls *_ctx, tls_read_cb _read_cb,
> tls_write_cb _write_cb, void *_cb_arg, const char *_servername);
> int tls_handshake(struct tls *_ctx);
> +size_t tls_pending(const struct tls *_ctx);
> ssize_t tls_read(struct tls *_ctx, void *_buf, size_t _buflen);
> ssize_t tls_write(struct tls *_ctx, const void *_buf, size_t _buflen);
> int tls_close(struct tls *_ctx);
> Index: man/tls_read.3
> ===
> RCS file: /cvs/src/lib/libtls/man/tls_read.3,v
> retrieving revision 1.7
> diff -u -p -r1.7 tls_read.3
> --- man/tls_read.39 Jul 2019 17:58:33 - 1.7
> +++ man/tls_read.316 Sep 2021 20:57:32 -
> @@ -27,6 +27,7 @@
> .Nm tls_handshake ,
> .Nm tls_error ,
> .Nm tls_close ,
> +.Nm tls_pending ,
> .Nm tls_reset
> .Nd use a TLS connection
> .Sh SYNOPSIS
> @@ -51,6 +52,8 @@
> .Fn tls_close "struct tls *ctx"
> .Ft void
> .Fn tls_reset "struct tls *ctx"
> +.Ft size_t
> +.Fn tls_pending "const struct tls *ctx"
> .Sh DESCRIPTION
> .Fn tls_read
> reads
> @@ -58,6 +61,8 @@ reads
> bytes of data from the socket into
> .Fa buf .
> It returns the amount of data read.
> +.Fn tls_pending
> +returns the number of bytes that may be read without blocking.
> .Pp
> .Fn tls_write
> writes
> @@ -99,6 +104,9 @@ and
> .Fn tls_write
> return a size on success or -1 on error.
> .Pp
> +.Fn tls_pending
> +returns a size or zero if no data is buffered for immediate reading.
> +.Pp
> .Fn tls_handshake
> and
> .Fn tls_close
> @@ -198,6 +206,28 @@ while (len > 0) {
> buf += ret;
> len -= ret;
> }
> + }
> +}
> +\&...
> +.Ed
> +.Pp
> +For non-blocking input, the following example demonstrates how to handle
> +buffered data when the descriptor may have none to read:
> +.Bd -literal -offset indent
> +\&...
> +pfd[0].fd = fd;
> +pfd[0].events = POLLIN;
> +for (;;) {
> + int timeo;
> +
> + timeo = tls_pending(tls) ? 0 : INFTIM;
> + if (poll(pfd, 1, timeo) == -1)
> + err(1, "poll");
> + if ((pfd[0].revents & POLLIN) || tls_pending(tls)) {
> + ssize_t ret;
> +
> + ret = tls_read(ctx, buf, len);
> + \&...
> }
> }
> \&...
--
:wq Claudio
Re: tls_pending(3)
Interestingly, there was a long discussion over beer at a hackathon recently, about non-blocking and poll/select/kqueue/etc, in particular when mixed with TLS codepaths. In my view, mixing poll()-style event loops with non-blocking descriptors will -- 99% of the time -- result in people writing broken event processing loops, and when they cannot figure out the breakage, they will double down repeatedly adding more and more hacks, and never solve the problem. We have seen poll loops with nested poll loops. I believe we should not encourage use of non-blocking mode. Actually, we should discourage non-blocking loops, by not providing APIs which encourage busy-loop polling. Non-blocking mode is poisonous. Kristaps Dzonsons wrote: > Hi, > > I'm porting a nonblocking, polling OpenSSL system to libtls. However, > I'm not sure how this is non-hackily possible without SSL_pending(3) > to detect if less data is read with tls_read() than is buffered. > > writer: > tls_write(40) > > reader: > poll(POLLIN, INFTIM) -> POLLIN /* descriptor has a read */ > tls_read(20) /* 20 bytes read, 20 bytes remain */ > poll(POLLIN, INFTIM) -> 0 /* data was buffered */ > > This introduces tls_pending(3), which calls through to SSL_pending(3), > and includes a simple example in tls_read(3). > > Beck's tutorial says that "libtls is designed to do the common things > you do for making TLS connections easy", and I'm not sure my use case > meets that standard. If it looks reasonable, however, I can also add > the regression tests. > > Thank you, > > Kristaps
Re: Possible bug in lib/libc/gen/exec.c
enh wrote: > we had the same issue in bionic when we removed all our alloca()s, modulo the > fact > that ours is a VLA rather than alloca(), but same thing: > https://android.googlesource.com/platform/bionic/+/master/libc/bionic/exec.cpp#61 that cargo culting doesn't fix anything... > we argued that it doesn't matter in this case though because we'll touch all > the > entries, in order, so there's no possibility of jumping off the end of the > stack onto > another VMA. we've always had a sufficient gap beyond the end of our stack, but a few years ago many people freaked out because they didn't. nowadays, that is enforced on a system level, so that door is largely closed, dependent on linear access. > (we have used mmap() instead in more complicated cases though.) yes, that is the solution, but rollback and errno must be handled carefully. If this mmap() fix goes in, the only alloca() remain in our tree are: clang - seems to be in test code only binutils - shocking 1 in gcc configure 1 in perl - non-openbsd cases 1 small one in libcrypto - someone should go fix that
tls_pending(3)
Hi,
I'm porting a nonblocking, polling OpenSSL system to libtls. However,
I'm not sure how this is non-hackily possible without SSL_pending(3) to
detect if less data is read with tls_read() than is buffered.
writer:
tls_write(40)
reader:
poll(POLLIN, INFTIM) -> POLLIN /* descriptor has a read */
tls_read(20) /* 20 bytes read, 20 bytes remain */
poll(POLLIN, INFTIM) -> 0 /* data was buffered */
This introduces tls_pending(3), which calls through to SSL_pending(3),
and includes a simple example in tls_read(3).
Beck's tutorial says that "libtls is designed to do the common things
you do for making TLS connections easy", and I'm not sure my use case
meets that standard. If it looks reasonable, however, I can also add
the regression tests.
Thank you,
Kristaps
Index: tls.c
===
RCS file: /cvs/src/lib/libtls/tls.c,v
retrieving revision 1.89
diff -u -p -r1.89 tls.c
--- tls.c 1 Feb 2021 15:35:41 - 1.89
+++ tls.c 16 Sep 2021 20:57:32 -
@@ -788,6 +788,16 @@ tls_handshake(struct tls *ctx)
return (rv);
}
+size_t
+tls_pending(const struct tls *ctx)
+{
+
+ if ((ctx->state & TLS_HANDSHAKE_COMPLETE) != 0)
+ return 0;
+
+ return (size_t)SSL_pending(ctx->ssl_conn);
+}
+
ssize_t
tls_read(struct tls *ctx, void *buf, size_t buflen)
{
Index: tls.h
===
RCS file: /cvs/src/lib/libtls/tls.h,v
retrieving revision 1.58
diff -u -p -r1.58 tls.h
--- tls.h 22 Jan 2020 06:44:02 - 1.58
+++ tls.h 16 Sep 2021 20:57:32 -
@@ -177,6 +177,7 @@ int tls_connect_socket(struct tls *_ctx,
int tls_connect_cbs(struct tls *_ctx, tls_read_cb _read_cb,
tls_write_cb _write_cb, void *_cb_arg, const char *_servername);
int tls_handshake(struct tls *_ctx);
+size_t tls_pending(const struct tls *_ctx);
ssize_t tls_read(struct tls *_ctx, void *_buf, size_t _buflen);
ssize_t tls_write(struct tls *_ctx, const void *_buf, size_t _buflen);
int tls_close(struct tls *_ctx);
Index: man/tls_read.3
===
RCS file: /cvs/src/lib/libtls/man/tls_read.3,v
retrieving revision 1.7
diff -u -p -r1.7 tls_read.3
--- man/tls_read.3 9 Jul 2019 17:58:33 - 1.7
+++ man/tls_read.3 16 Sep 2021 20:57:32 -
@@ -27,6 +27,7 @@
.Nm tls_handshake ,
.Nm tls_error ,
.Nm tls_close ,
+.Nm tls_pending ,
.Nm tls_reset
.Nd use a TLS connection
.Sh SYNOPSIS
@@ -51,6 +52,8 @@
.Fn tls_close "struct tls *ctx"
.Ft void
.Fn tls_reset "struct tls *ctx"
+.Ft size_t
+.Fn tls_pending "const struct tls *ctx"
.Sh DESCRIPTION
.Fn tls_read
reads
@@ -58,6 +61,8 @@ reads
bytes of data from the socket into
.Fa buf .
It returns the amount of data read.
+.Fn tls_pending
+returns the number of bytes that may be read without blocking.
.Pp
.Fn tls_write
writes
@@ -99,6 +104,9 @@ and
.Fn tls_write
return a size on success or -1 on error.
.Pp
+.Fn tls_pending
+returns a size or zero if no data is buffered for immediate reading.
+.Pp
.Fn tls_handshake
and
.Fn tls_close
@@ -198,6 +206,28 @@ while (len > 0) {
buf += ret;
len -= ret;
}
+ }
+}
+\&...
+.Ed
+.Pp
+For non-blocking input, the following example demonstrates how to handle
+buffered data when the descriptor may have none to read:
+.Bd -literal -offset indent
+\&...
+pfd[0].fd = fd;
+pfd[0].events = POLLIN;
+for (;;) {
+ int timeo;
+
+ timeo = tls_pending(tls) ? 0 : INFTIM;
+ if (poll(pfd, 1, timeo) == -1)
+ err(1, "poll");
+ if ((pfd[0].revents & POLLIN) || tls_pending(tls)) {
+ ssize_t ret;
+
+ ret = tls_read(ctx, buf, len);
+ \&...
}
}
\&...
Re: Possible bug in lib/libc/gen/exec.c
Theo de Raadt wrote:
> Maybe we should investigate using mmap. Of the 4 cases, 3 are not
> too difficult, but the 4th case will be very messy, including unwind
> for the 3rd case.
Here is a version that uses mmap instead of alloca, including rollback
of resource allocations in case of failure. This is similar to the mmap
use in vfprintf which I added many years ago to support positional
arguments without alloca or malloc, so that snprintf family can be
remain maximally reentrant. So I've been here before...
I have done a little testing, but it may still have bugs.
Index: lib/libc/gen/exec.c
===
RCS file: /cvs/src/lib/libc/gen/exec.c,v
retrieving revision 1.23
diff -u -p -u -r1.23 exec.c
--- lib/libc/gen/exec.c 13 Mar 2016 18:34:20 - 1.23
+++ lib/libc/gen/exec.c 16 Sep 2021 20:48:25 -
@@ -30,6 +30,7 @@
#include
#include
+#include
#include
#include
@@ -45,25 +46,31 @@ execl(const char *name, const char *arg,
{
va_list ap;
char **argv;
- int n;
+ size_t maplen;
+ int save_errno, n, error;
va_start(ap, arg);
n = 1;
while (va_arg(ap, char *) != NULL)
n++;
va_end(ap);
- argv = alloca((n + 1) * sizeof(*argv));
- if (argv == NULL) {
- errno = ENOMEM;
+ maplen = (n + 1) * sizeof(*argv);
+ argv = mmap(NULL, maplen, PROT_WRITE|PROT_READ,
+ MAP_ANON|MAP_PRIVATE, -1, 0);
+ if (argv == MAP_FAILED)
return (-1);
- }
va_start(ap, arg);
n = 1;
argv[0] = (char *)arg;
while ((argv[n] = va_arg(ap, char *)) != NULL)
n++;
va_end(ap);
- return (execve(name, argv, environ));
+
+ error = execve(name, argv, environ);
+ save_errno = errno;
+ munmap(argv, maplen);
+ errno = save_errno;
+ return (error);
}
DEF_WEAK(execl);
@@ -72,18 +79,21 @@ execle(const char *name, const char *arg
{
va_list ap;
char **argv, **envp;
- int n;
+ size_t maplen;
+ int save_errno, n, error;
va_start(ap, arg);
n = 1;
while (va_arg(ap, char *) != NULL)
n++;
va_end(ap);
- argv = alloca((n + 1) * sizeof(*argv));
- if (argv == NULL) {
- errno = ENOMEM;
+
+ maplen = (n + 1) * sizeof(*argv);
+ argv = mmap(NULL, maplen, PROT_WRITE|PROT_READ,
+ MAP_ANON|MAP_PRIVATE, -1, 0);
+ if (argv == MAP_FAILED)
return (-1);
- }
+
va_start(ap, arg);
n = 1;
argv[0] = (char *)arg;
@@ -91,7 +101,12 @@ execle(const char *name, const char *arg
n++;
envp = va_arg(ap, char **);
va_end(ap);
- return (execve(name, argv, envp));
+
+ error = execve(name, argv, envp);
+ save_errno = errno;
+ munmap(argv, maplen);
+ errno = save_errno;
+ return error;
}
int
@@ -99,25 +114,32 @@ execlp(const char *name, const char *arg
{
va_list ap;
char **argv;
- int n;
+ size_t maplen;
+ int save_errno, n, error;
va_start(ap, arg);
n = 1;
while (va_arg(ap, char *) != NULL)
n++;
va_end(ap);
- argv = alloca((n + 1) * sizeof(*argv));
- if (argv == NULL) {
- errno = ENOMEM;
+
+ maplen = (n + 1) * sizeof(*argv);
+ argv = mmap(NULL, maplen, PROT_WRITE|PROT_READ,
+ MAP_ANON|MAP_PRIVATE, -1, 0);
+ if (argv == MAP_FAILED)
return (-1);
- }
+
va_start(ap, arg);
n = 1;
argv[0] = (char *)arg;
while ((argv[n] = va_arg(ap, char *)) != NULL)
n++;
va_end(ap);
- return (execvp(name, argv));
+ error = execvp(name, argv);
+ save_errno = errno;
+ munmap(argv, maplen);
+ errno = save_errno;
+ return error;
}
int
@@ -132,10 +154,12 @@ execvpe(const char *name, char *const *a
{
char **memp;
int cnt;
- size_t lp, ln, len;
+ size_t lp, ln, curlen;
char *p;
int eacces = 0;
char *bp, *cur, *path, buf[PATH_MAX];
+ size_t maplen;
+ int save_errno, n;
/*
* Do not allow null name
@@ -156,13 +180,14 @@ execvpe(const char *name, char *const *a
/* Get the path we're searching. */
if (!(path = getenv("PATH")))
path = _PATH_DEFPATH;
- len = strlen(path) + 1;
- cur = alloca(len);
- if (cur == NULL) {
- errno = ENOMEM;
+
+ curlen = strlen(path) + 1;
+ cur = mmap(NULL, curlen, PROT_WRITE|PROT_READ,
+ MAP_ANON|MAP_PRIVATE, -1, 0);
+ if (cur == MAP_FAILED)
return (-1);
- }
- strlcpy(cur, path, len);
+
+ strlcpy(cur, path, curlen);
path = cur;
while ((p = strsep(, ":"))) {
Re: Possible bug in lib/libc/gen/exec.c
Alejandro Colomar (man-pages) wrote:
> Hi,
>
> I don't know if OpenBSD has a different implementation of alloca(3)
> than Linux. In Linux, alloca(3) (a.k.a. __builtin_alloca()) can't
> return NULL, as it can't detect errors.
There are no alloca can return NULL.
> The only way to detect an
> error is to add a handler for SIGSEGV, AFAIK.
Actually, it is worse than that. Massive alloca have been encountered
which reach off the stack. For over 20 years we've been on a mission
to delete alloca in our tree, and these are the last ones that remain,
because other allocators are very difficult to use in this place.
Maybe we should investigate using mmap. Of the 4 cases, 3 are not
too difficult, but the 4th case will be very messy, including unwind
for the 3rd case.
> I found the following code in :
>
> argv = alloca((n + 1) * sizeof(*argv));
> if (argv == NULL) {
> errno = ENOMEM;
> return (-1);
> }
>
> But of course, that NULL should never happen, right?
> As a side note, I think you could encapsulate the code calling
> alloca(3) into a helper macro, to avoid repetition.
I don't see how that would help anything.
> I can prepare a patch if you confirm the bug.
What do you propose to do in your patch?
Possible bug in lib/libc/gen/exec.c
Hi,
I don't know if OpenBSD has a different implementation of alloca(3) than
Linux. In Linux, alloca(3) (a.k.a. __builtin_alloca()) can't return
NULL, as it can't detect errors. The only way to detect an error is to
add a handler for SIGSEGV, AFAIK.
I found the following code in :
argv = alloca((n + 1) * sizeof(*argv));
if (argv == NULL) {
errno = ENOMEM;
return (-1);
}
But of course, that NULL should never happen, right?
As a side note, I think you could encapsulate the code calling alloca(3)
into a helper macro, to avoid repetition.
I can prepare a patch if you confirm the bug.
Cheers,
Alex
--
Alejandro Colomar
Linux man-pages comaintainer; https://www.kernel.org/doc/man-pages/
http://www.alejandro-colomar.es/
Re: new gpioleds driver
> Date: Thu, 16 Sep 2021 06:12:39 + > From: Klemens Nanni > > On 3 September 2021 20:16:33 GMT+05:00, Klemens Nanni > wrote: > >Here is a tiny driver enabling machines such as the Pinebook Pro to > >indicate power, it is intentionally minimal and does not expose anything > >via sysctl(8)/sensorsd(8) or gpioctl(8). > > > >This is helpful for machines where graphics, keyboard and/or serial > >console have problems and people tend to debug things at various > >stages, e.g. a green LED now tells me that we reached the kernel. > > > >Once arm64 has suspend/resume we can indicate that as well. > > > >Feedback? OK? > > Ping. Two small nits below. With those fixed, ok kettenis@ > >diff 3a5fa1afe4fc417b263a9d7363eaa933acbf5f2c refs/heads/master > >blob - b597911b8f43a730799bbe34290843f3429c6958 > >blob + eec643f20e0feae7d4a4930f7d30575cffc25913 > >--- distrib/sets/lists/man/mi > >+++ distrib/sets/lists/man/mi > >@@ -1415,6 +1415,7 @@ > > ./usr/share/man/man4/gpio.4 > > ./usr/share/man/man4/gpiodcf.4 > > ./usr/share/man/man4/gpioiic.4 > >+./usr/share/man/man4/gpioleds.4 > > ./usr/share/man/man4/gpioow.4 > > ./usr/share/man/man4/graphaudio.4 > > ./usr/share/man/man4/gre.4 > >blob - 1541bb05749defd67419b07460def0f4065cbfce > >blob + bb62c44d32f152ecf64aa77d60a1a5a3454d3968 > >--- share/man/man4/Makefile > >+++ share/man/man4/Makefile > >@@ -36,7 +36,7 @@ MAN= aac.4 abcrtc.4 abl.4 ac97.4 acphy.4 acrtc.4 \ > > fanpwr.4 fd.4 fdc.4 fec.4 fido.4 fins.4 fintek.4 fms.4 fusbtc.4 \ > > fuse.4 fxp.4 \ > > gdt.4 gentbi.4 gem.4 gfrtc.4 gif.4 glenv.4 glkgpio.4 gpio.4 gpiodcf.4 \ > >-gpioiic.4 gpioow.4 graphaudio.4 gre.4 gscsio.4 \ > >+gpioiic.4 gpioleds.4 gpioow.4 graphaudio.4 gre.4 gscsio.4 \ > > hds.4 hiclock.4 hidwusb.4 hifn.4 hil.4 hilid.4 hilkbd.4 hilms.4 \ > > hireset.4 hitemp.4 hme.4 hotplug.4 hsq.4 \ > > hvn.4 hvs.4 hyperv.4 \ > >blob - /dev/null > >blob + 5338437382ce25842ac833cfb847d8fe08e90e6d (mode 644) > >--- /dev/null > >+++ share/man/man4/gpioleds.4 > >@@ -0,0 +1,45 @@ > >+.\" $OpenBSD: $ > >+.\" > >+.\" Copyright (c) 2021 Klemens Nanni > >+.\" > >+.\" Permission to use, copy, modify, and distribute this software for any > >+.\" purpose with or without fee is hereby granted, provided that the above > >+.\" copyright notice and this permission notice appear in all copies. > >+.\" > >+.\" THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES > >+.\" WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF > >+.\" MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR > >+.\" ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES > >+.\" WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN > >+.\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF > >+.\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. > >+.\" > >+.Dd $Mdocdate: September 03 2021 $ > >+.Dt GPIOLEDS 4 > >+.Os > >+.Sh NAME > >+.Nm gpioleds > >+.Nd GPIO LEDs > >+.Sh SYNOPSIS > >+.Cd "gpioleds* at fdt?" > >+.Sh DESCRIPTION > >+The > >+.Nm > >+driver provides support for LEDs connected to GPIO pins. > >+.Pp > >+Currently, LEDs are only set to their default state, > >+e.g. to indicate the power status of the system. > >+.Sh SEE ALSO > >+.Xr gpio 4 , > >+.Xr intro 4 > >+.Sh HISTORY > >+The > >+.Nm > >+driver first appeared in > >+.Ox 7.0 . > >+.Sh AUTHORS > >+.An -nosplit > >+The > >+.Nm > >+driver was written by > >+.An Klemens Nanni Aq Mt k...@openbsd.org . > >blob - 3e6591124cad872771cd68599761c26981d185d8 > >blob + d3c3afb621f20013dc2475b4d87bd959e4127c9d > >--- sys/arch/arm64/conf/GENERIC > >+++ sys/arch/arm64/conf/GENERIC > >@@ -131,6 +131,8 @@ amdgpu* at pci? > > drm*at amdgpu? > > wsdisplay* at amdgpu? > > > >+gpioleds* at fdt? > >+ > > # Apple > > apldart*at fdt? > > apldog* at fdt? early 1 > >blob - 3b23523493a12c8b8091f9744561c6bcbb685751 > >blob + f749803b07408179ddc090d484ed4f79bfcb52a7 > >--- sys/dev/fdt/files.fdt > >+++ sys/dev/fdt/files.fdt > >@@ -588,3 +588,7 @@ file dev/fdt/cwfg.c cwfg > > device dapmic > > attach dapmic at i2c > > filedev/fdt/dapmic.cdapmic > >+ > >+device gpioleds > >+attach gpioleds at fdt > >+filedev/fdt/gpioleds.c gpioleds > >blob - /dev/null > >blob + f5ad5e7b6220f3d20b129fe26f8ada2d63eb5909 (mode 644) > >--- /dev/null > >+++ sys/dev/fdt/gpioleds.c > >@@ -0,0 +1,102 @@ > >+/* $OpenBSD: $ */ > >+/* > >+ * Copyright (c) 2021 Klemens Nanni > >+ * > >+ * 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
Re: new gpiocharger driver
> Date: Thu, 16 Sep 2021 06:14:39 + > From: Klemens Nanni > > On 5 September 2021 01:22:53 GMT+05:00, Klemens Nanni > wrote: > >Read a single GPIO pin indicating whether AC is plugged in or not. > > > >This gives me a sensor on my Pinebook Pro. > >cwfg(4) already provides battery information but not the charger bits. > > > >apm(4) integration can follow separately. > > > >Feedback? OK? > > Ping. > The diff applies after the "new gpioleds driver" one. > > >diff 4e7699b4cf65fba4bf837b202fb68ee0f66e6d07 refs/heads/master > >blob - b92b1f60934ba60f92341ce94570d0ae96e78c1d > >blob + 549a8316b874e4e5a6e1ede1640eeefadd9af0d4 > >--- distrib/sets/lists/man/mi > >+++ distrib/sets/lists/man/mi > >@@ -1417,6 +1417,7 @@ > > ./usr/share/man/man4/glenv.4 > > ./usr/share/man/man4/glkgpio.4 > > ./usr/share/man/man4/gpio.4 > >+./usr/share/man/man4/gpiocharger.4 > > ./usr/share/man/man4/gpiodcf.4 > > ./usr/share/man/man4/gpioiic.4 > > ./usr/share/man/man4/gpioleds.4 > >blob - bb62c44d32f152ecf64aa77d60a1a5a3454d3968 > >blob + a40cf91ec22f638f9c030aa7128d10bf75748305 > >--- share/man/man4/Makefile > >+++ share/man/man4/Makefile > >@@ -35,7 +35,8 @@ MAN= aac.4 abcrtc.4 abl.4 ac97.4 acphy.4 acrtc.4 \ > > eso.4 ess.4 et.4 etherip.4 etphy.4 ex.4 exphy.4 exrtc.4 \ > > fanpwr.4 fd.4 fdc.4 fec.4 fido.4 fins.4 fintek.4 fms.4 fusbtc.4 \ > > fuse.4 fxp.4 \ > >-gdt.4 gentbi.4 gem.4 gfrtc.4 gif.4 glenv.4 glkgpio.4 gpio.4 gpiodcf.4 \ > >+gdt.4 gentbi.4 gem.4 gfrtc.4 gif.4 glenv.4 glkgpio.4 gpio.4 \ > >+gpiocharger.4 gpiodcf.4 \ > > gpioiic.4 gpioleds.4 gpioow.4 graphaudio.4 gre.4 gscsio.4 \ > > hds.4 hiclock.4 hidwusb.4 hifn.4 hil.4 hilid.4 hilkbd.4 hilms.4 \ > > hireset.4 hitemp.4 hme.4 hotplug.4 hsq.4 \ > >blob - /dev/null > >blob + 12aa353d9367f57f07a89ae30dc3966c373032f8 (mode 644) > >--- /dev/null > >+++ share/man/man4/gpiocharger.4 > >@@ -0,0 +1,51 @@ > >+.\" $OpenBSD: $ > >+.\" > >+.\" Copyright (c) 2021 Klemens Nanni > >+.\" > >+.\" Permission to use, copy, modify, and distribute this software for any > >+.\" purpose with or without fee is hereby granted, provided that the above > >+.\" copyright notice and this permission notice appear in all copies. > >+.\" > >+.\" THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES > >+.\" WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF > >+.\" MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR > >+.\" ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES > >+.\" WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN > >+.\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF > >+.\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. > >+.\" > >+.Dd $Mdocdate: September 04 2021 $ > >+.Dt GPIOCHARGER 4 > >+.Os > >+.Sh NAME > >+.Nm gpiocharger > >+.Nd GPIO battery charger > >+.Sh SYNOPSIS > >+.Cd "gpiocharger* at fdt?" > >+.Sh DESCRIPTION > >+The > >+.Nm > >+driver provides support for battery chargers connected to GPIO pins. > >+Currently, only power supply status events are supported. > >+.Pp > >+The power supply status (connected or disconnected) is set up as a sensor > >+and can be monitored using > >+.Xr sysctl 8 > >+or > >+.Xr sensorsd 8 . > >+.Sh SEE ALSO > >+.Xr gpio 4 , > >+.Xr intro 4 , > >+.Xr sensorsd 8 , > >+.Xr sysctl 8 > >+.Sh HISTORY > >+The > >+.Nm > >+driver first appeared in > >+.Ox 7.0 . > >+.Sh AUTHORS > >+.An -nosplit > >+The > >+.Nm > >+driver was written by > >+.An Klemens Nanni Aq Mt k...@openbsd.org . > >blob - d3c3afb621f20013dc2475b4d87bd959e4127c9d > >blob + b0702181cd2e510ef5267460dc71b68a8abd508a > >--- sys/arch/arm64/conf/GENERIC > >+++ sys/arch/arm64/conf/GENERIC > >@@ -132,6 +132,7 @@ drm* at amdgpu? > > wsdisplay* at amdgpu? > > > > gpioleds* at fdt? > >+gpiocharger*at fdt? > > > > # Apple > > apldart*at fdt? > >blob - f749803b07408179ddc090d484ed4f79bfcb52a7 > >blob + f91263405dc183dd60e8ddc1fe69c5fbaf38b651 > >--- sys/dev/fdt/files.fdt > >+++ sys/dev/fdt/files.fdt > >@@ -592,3 +592,7 @@ file dev/fdt/dapmic.cdapmic > > device gpioleds > > attach gpioleds at fdt > > filedev/fdt/gpioleds.c gpioleds > >+ > >+device gpiocharger > >+attach gpiocharger at fdt > >+filedev/fdt/gpiocharger.c gpiocharger > >blob - /dev/null > >blob + dbf6bf50a13029438b9b7e969306c34640c5747e (mode 644) > >--- /dev/null > >+++ sys/dev/fdt/gpiocharger.c > >@@ -0,0 +1,116 @@ > >+/* $OpenBSD: $ */ > >+/* > >+ * Copyright (c) 2021 Klemens Nanni > >+ * > >+ * 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
Re: new gpioleds driver
On 3 September 2021 20:16:33 GMT+05:00, Klemens Nanni wrote: >Here is a tiny driver enabling machines such as the Pinebook Pro to >indicate power, it is intentionally minimal and does not expose anything >via sysctl(8)/sensorsd(8) or gpioctl(8). > >This is helpful for machines where graphics, keyboard and/or serial >console have problems and people tend to debug things at various >stages, e.g. a green LED now tells me that we reached the kernel. > >Once arm64 has suspend/resume we can indicate that as well. > >Feedback? OK? Ping. >diff 3a5fa1afe4fc417b263a9d7363eaa933acbf5f2c refs/heads/master >blob - b597911b8f43a730799bbe34290843f3429c6958 >blob + eec643f20e0feae7d4a4930f7d30575cffc25913 >--- distrib/sets/lists/man/mi >+++ distrib/sets/lists/man/mi >@@ -1415,6 +1415,7 @@ > ./usr/share/man/man4/gpio.4 > ./usr/share/man/man4/gpiodcf.4 > ./usr/share/man/man4/gpioiic.4 >+./usr/share/man/man4/gpioleds.4 > ./usr/share/man/man4/gpioow.4 > ./usr/share/man/man4/graphaudio.4 > ./usr/share/man/man4/gre.4 >blob - 1541bb05749defd67419b07460def0f4065cbfce >blob + bb62c44d32f152ecf64aa77d60a1a5a3454d3968 >--- share/man/man4/Makefile >+++ share/man/man4/Makefile >@@ -36,7 +36,7 @@ MAN= aac.4 abcrtc.4 abl.4 ac97.4 acphy.4 acrtc.4 \ > fanpwr.4 fd.4 fdc.4 fec.4 fido.4 fins.4 fintek.4 fms.4 fusbtc.4 \ > fuse.4 fxp.4 \ > gdt.4 gentbi.4 gem.4 gfrtc.4 gif.4 glenv.4 glkgpio.4 gpio.4 gpiodcf.4 \ >- gpioiic.4 gpioow.4 graphaudio.4 gre.4 gscsio.4 \ >+ gpioiic.4 gpioleds.4 gpioow.4 graphaudio.4 gre.4 gscsio.4 \ > hds.4 hiclock.4 hidwusb.4 hifn.4 hil.4 hilid.4 hilkbd.4 hilms.4 \ > hireset.4 hitemp.4 hme.4 hotplug.4 hsq.4 \ > hvn.4 hvs.4 hyperv.4 \ >blob - /dev/null >blob + 5338437382ce25842ac833cfb847d8fe08e90e6d (mode 644) >--- /dev/null >+++ share/man/man4/gpioleds.4 >@@ -0,0 +1,45 @@ >+.\" $OpenBSD: $ >+.\" >+.\" Copyright (c) 2021 Klemens Nanni >+.\" >+.\" Permission to use, copy, modify, and distribute this software for any >+.\" purpose with or without fee is hereby granted, provided that the above >+.\" copyright notice and this permission notice appear in all copies. >+.\" >+.\" THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES >+.\" WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF >+.\" MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR >+.\" ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES >+.\" WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN >+.\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF >+.\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. >+.\" >+.Dd $Mdocdate: September 03 2021 $ >+.Dt GPIOLEDS 4 >+.Os >+.Sh NAME >+.Nm gpioleds >+.Nd GPIO LEDs >+.Sh SYNOPSIS >+.Cd "gpioleds* at fdt?" >+.Sh DESCRIPTION >+The >+.Nm >+driver provides support for LEDs connected to GPIO pins. >+.Pp >+Currently, LEDs are only set to their default state, >+e.g. to indicate the power status of the system. >+.Sh SEE ALSO >+.Xr gpio 4 , >+.Xr intro 4 >+.Sh HISTORY >+The >+.Nm >+driver first appeared in >+.Ox 7.0 . >+.Sh AUTHORS >+.An -nosplit >+The >+.Nm >+driver was written by >+.An Klemens Nanni Aq Mt k...@openbsd.org . >blob - 3e6591124cad872771cd68599761c26981d185d8 >blob + d3c3afb621f20013dc2475b4d87bd959e4127c9d >--- sys/arch/arm64/conf/GENERIC >+++ sys/arch/arm64/conf/GENERIC >@@ -131,6 +131,8 @@ amdgpu*at pci? > drm* at amdgpu? > wsdisplay*at amdgpu? > >+gpioleds* at fdt? >+ > # Apple > apldart* at fdt? > apldog* at fdt? early 1 >blob - 3b23523493a12c8b8091f9744561c6bcbb685751 >blob + f749803b07408179ddc090d484ed4f79bfcb52a7 >--- sys/dev/fdt/files.fdt >+++ sys/dev/fdt/files.fdt >@@ -588,3 +588,7 @@ file dev/fdt/cwfg.c cwfg > devicedapmic > attachdapmic at i2c > file dev/fdt/dapmic.cdapmic >+ >+devicegpioleds >+attachgpioleds at fdt >+file dev/fdt/gpioleds.c gpioleds >blob - /dev/null >blob + f5ad5e7b6220f3d20b129fe26f8ada2d63eb5909 (mode 644) >--- /dev/null >+++ sys/dev/fdt/gpioleds.c >@@ -0,0 +1,102 @@ >+/*$OpenBSD: $ */ >+/* >+ * Copyright (c) 2021 Klemens Nanni >+ * >+ * 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
Re: new gpiocharger driver
On 5 September 2021 01:22:53 GMT+05:00, Klemens Nanni wrote: >Read a single GPIO pin indicating whether AC is plugged in or not. > >This gives me a sensor on my Pinebook Pro. >cwfg(4) already provides battery information but not the charger bits. > >apm(4) integration can follow separately. > >Feedback? OK? Ping. The diff applies after the "new gpioleds driver" one. >diff 4e7699b4cf65fba4bf837b202fb68ee0f66e6d07 refs/heads/master >blob - b92b1f60934ba60f92341ce94570d0ae96e78c1d >blob + 549a8316b874e4e5a6e1ede1640eeefadd9af0d4 >--- distrib/sets/lists/man/mi >+++ distrib/sets/lists/man/mi >@@ -1417,6 +1417,7 @@ > ./usr/share/man/man4/glenv.4 > ./usr/share/man/man4/glkgpio.4 > ./usr/share/man/man4/gpio.4 >+./usr/share/man/man4/gpiocharger.4 > ./usr/share/man/man4/gpiodcf.4 > ./usr/share/man/man4/gpioiic.4 > ./usr/share/man/man4/gpioleds.4 >blob - bb62c44d32f152ecf64aa77d60a1a5a3454d3968 >blob + a40cf91ec22f638f9c030aa7128d10bf75748305 >--- share/man/man4/Makefile >+++ share/man/man4/Makefile >@@ -35,7 +35,8 @@ MAN= aac.4 abcrtc.4 abl.4 ac97.4 acphy.4 acrtc.4 \ > eso.4 ess.4 et.4 etherip.4 etphy.4 ex.4 exphy.4 exrtc.4 \ > fanpwr.4 fd.4 fdc.4 fec.4 fido.4 fins.4 fintek.4 fms.4 fusbtc.4 \ > fuse.4 fxp.4 \ >- gdt.4 gentbi.4 gem.4 gfrtc.4 gif.4 glenv.4 glkgpio.4 gpio.4 gpiodcf.4 \ >+ gdt.4 gentbi.4 gem.4 gfrtc.4 gif.4 glenv.4 glkgpio.4 gpio.4 \ >+ gpiocharger.4 gpiodcf.4 \ > gpioiic.4 gpioleds.4 gpioow.4 graphaudio.4 gre.4 gscsio.4 \ > hds.4 hiclock.4 hidwusb.4 hifn.4 hil.4 hilid.4 hilkbd.4 hilms.4 \ > hireset.4 hitemp.4 hme.4 hotplug.4 hsq.4 \ >blob - /dev/null >blob + 12aa353d9367f57f07a89ae30dc3966c373032f8 (mode 644) >--- /dev/null >+++ share/man/man4/gpiocharger.4 >@@ -0,0 +1,51 @@ >+.\" $OpenBSD: $ >+.\" >+.\" Copyright (c) 2021 Klemens Nanni >+.\" >+.\" Permission to use, copy, modify, and distribute this software for any >+.\" purpose with or without fee is hereby granted, provided that the above >+.\" copyright notice and this permission notice appear in all copies. >+.\" >+.\" THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES >+.\" WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF >+.\" MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR >+.\" ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES >+.\" WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN >+.\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF >+.\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. >+.\" >+.Dd $Mdocdate: September 04 2021 $ >+.Dt GPIOCHARGER 4 >+.Os >+.Sh NAME >+.Nm gpiocharger >+.Nd GPIO battery charger >+.Sh SYNOPSIS >+.Cd "gpiocharger* at fdt?" >+.Sh DESCRIPTION >+The >+.Nm >+driver provides support for battery chargers connected to GPIO pins. >+Currently, only power supply status events are supported. >+.Pp >+The power supply status (connected or disconnected) is set up as a sensor >+and can be monitored using >+.Xr sysctl 8 >+or >+.Xr sensorsd 8 . >+.Sh SEE ALSO >+.Xr gpio 4 , >+.Xr intro 4 , >+.Xr sensorsd 8 , >+.Xr sysctl 8 >+.Sh HISTORY >+The >+.Nm >+driver first appeared in >+.Ox 7.0 . >+.Sh AUTHORS >+.An -nosplit >+The >+.Nm >+driver was written by >+.An Klemens Nanni Aq Mt k...@openbsd.org . >blob - d3c3afb621f20013dc2475b4d87bd959e4127c9d >blob + b0702181cd2e510ef5267460dc71b68a8abd508a >--- sys/arch/arm64/conf/GENERIC >+++ sys/arch/arm64/conf/GENERIC >@@ -132,6 +132,7 @@ drm* at amdgpu? > wsdisplay*at amdgpu? > > gpioleds* at fdt? >+gpiocharger* at fdt? > > # Apple > apldart* at fdt? >blob - f749803b07408179ddc090d484ed4f79bfcb52a7 >blob + f91263405dc183dd60e8ddc1fe69c5fbaf38b651 >--- sys/dev/fdt/files.fdt >+++ sys/dev/fdt/files.fdt >@@ -592,3 +592,7 @@ file dev/fdt/dapmic.cdapmic > devicegpioleds > attachgpioleds at fdt > file dev/fdt/gpioleds.c gpioleds >+ >+devicegpiocharger >+attachgpiocharger at fdt >+file dev/fdt/gpiocharger.c gpiocharger >blob - /dev/null >blob + dbf6bf50a13029438b9b7e969306c34640c5747e (mode 644) >--- /dev/null >+++ sys/dev/fdt/gpiocharger.c >@@ -0,0 +1,116 @@ >+/*$OpenBSD: $ */ >+/* >+ * Copyright (c) 2021 Klemens Nanni >+ * >+ * 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
