History log of /freebsd/sys/dev/gpio/gpiobus.c (Results 1 – 25 of 139)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 160179ea 02-Jan-2025 John Baldwin <jhb@FreeBSD.org>

Remove now-redundant calls to device_delete_children

Earlier calls to bus_generic_detach now take care of deleting
children.

Differential Revision: https://reviews.freebsd.org/D47962


# e9d38570 02-Jan-2025 John Baldwin <jhb@FreeBSD.org>

Use bus_detach_children instead of bus_generic_detach

These drivers perform additional teardown steps in between detaching
child devices and deleting child devices.

Differential Revision: https://r

Use bus_detach_children instead of bus_generic_detach

These drivers perform additional teardown steps in between detaching
child devices and deleting child devices.

Differential Revision: https://reviews.freebsd.org/D47957

show more ...


# 18250ec6 06-Dec-2024 John Baldwin <jhb@FreeBSD.org>

Replace calls to bus_generic_attach with bus_attach_children

Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D47675


# 723da5d9 06-Dec-2024 John Baldwin <jhb@FreeBSD.org>

Replace calls to bus_generic_probe with bus_identify_children

Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D47674


Revision tags: release/14.2.0
# c9e880c0 01-Nov-2024 John Baldwin <jhb@FreeBSD.org>

gpiobus: Use a bus_child_deleted method to free ivars for children

Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D47369


# bc0d10d0 22-Oct-2024 Colin Percival <cperciva@FreeBSD.org>

gpiobus: Make gpiobus_read_ivar extern

This allows acpi_gpiobus to override the method and fall back to the
generic gpiobus_read_ivar function if needed.

Reviewed by: andrew
MFC after: 1 week
Spons

gpiobus: Make gpiobus_read_ivar extern

This allows acpi_gpiobus to override the method and fall back to the
generic gpiobus_read_ivar function if needed.

Reviewed by: andrew
MFC after: 1 week
Sponsored by: Amazon
Differential Revision: https://reviews.freebsd.org/D47250

show more ...


Revision tags: release/13.4.0
# 92adaa58 08-Jul-2024 Ahmad Khalifa <ahmadkhalifa570@gmail.com>

gpiobus(4): Add an acpi variant of gpiobus

This currently only implements the address space handler and attempts to
configure pins with flags obtained from ACPI.

Reviewed by: wulf
MFC after: 1 mont

gpiobus(4): Add an acpi variant of gpiobus

This currently only implements the address space handler and attempts to
configure pins with flags obtained from ACPI.

Reviewed by: wulf
MFC after: 1 month
Pull Request: https://github.com/freebsd/freebsd-src/pull/1359

show more ...


# 5b56413d 25-Jul-2024 Warner Losh <imp@FreeBSD.org>

newbus: globally replace device_add_child(..., -1) with DEVICE_UNIT_ANY

Sponsored by: Netflix


Revision tags: release/14.1.0, release/13.3.0
# 04eca693 23-Feb-2024 John Baldwin <jhb@FreeBSD.org>

gpiobus: Add missing DEVMETHOD for bus_get_rman

Reported by: andrew
Fixes: 5bda26333a8e gpiobus: Use bus_generic_rman_*


# 5bda2633 14-Feb-2024 John Baldwin <jhb@FreeBSD.org>

gpiobus: Use bus_generic_rman_*

Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D43887


# fdafd315 24-Nov-2023 Warner Losh <imp@FreeBSD.org>

sys: Automated cleanup of cdefs and other formatting

Apply the following automated changes to try to eliminate
no-longer-needed sys/cdefs.h includes as well as now-empty
blank lines in a row.

Remov

sys: Automated cleanup of cdefs and other formatting

Apply the following automated changes to try to eliminate
no-longer-needed sys/cdefs.h includes as well as now-empty
blank lines in a row.

Remove /^#if.*\n#endif.*\n#include\s+<sys/cdefs.h>.*\n/
Remove /\n+#include\s+<sys/cdefs.h>.*\n+#if.*\n#endif.*\n+/
Remove /\n+#if.*\n#endif.*\n+/
Remove /^#if.*\n#endif.*\n/
Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/types.h>/
Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/param.h>/
Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/capsicum.h>/

Sponsored by: Netflix

show more ...


# a19ed349 22-Nov-2023 John Baldwin <jhb@FreeBSD.org>

gpiobus: Use bus_generic_rl_* methods

Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D42715


Revision tags: release/14.0.0
# 685dc743 16-Aug-2023 Warner Losh <imp@FreeBSD.org>

sys: Remove $FreeBSD$: one-line .c pattern

Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/


# 4d846d26 10-May-2023 Warner Losh <imp@FreeBSD.org>

spdx: The BSD-2-Clause-FreeBSD identifier is obsolete, drop -FreeBSD

The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch
up to that fact and revert to their recommended match of

spdx: The BSD-2-Clause-FreeBSD identifier is obsolete, drop -FreeBSD

The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch
up to that fact and revert to their recommended match of BSD-2-Clause.

Discussed with: pfg
MFC After: 3 days
Sponsored by: Netflix

show more ...


Revision tags: release/13.2.0, release/12.4.0, release/13.1.0
# 84c5f982 09-May-2022 John Baldwin <jhb@FreeBSD.org>

gpio: Remove unused devclass arguments to DRIVER_MODULE.


Revision tags: release/12.3.0
# ddfc9c4c 23-Jun-2021 Warner Losh <imp@FreeBSD.org>

newbus: Move from bus_child_{pnpinfo,location}_src to bus_child_{pnpinfo,location} with sbuf

Now that the upper layers all go through a layer to tie into these
information functions that translates

newbus: Move from bus_child_{pnpinfo,location}_src to bus_child_{pnpinfo,location} with sbuf

Now that the upper layers all go through a layer to tie into these
information functions that translates an sbuf into char * and len. The
current interface suffers issues of what to do in cases of truncation,
etc. Instead, migrate all these functions to using struct sbuf and these
issues go away. The caller is also in charge of any memory allocation
and/or expansion that's needed during this process.

Create a bus_generic_child_{pnpinfo,location} and make it default. It
just returns success. This is for those busses that have no information
for these items. Migrate the now-empty routines to using this as
appropriate.

Document these new interfaces with man pages, and oversight from before.

Reviewed by: jhb, bcr
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D29937

show more ...


Revision tags: release/13.0.0
# ff3468ac 12-Dec-2020 Ian Lepore <ian@FreeBSD.org>

Provide userland notification of gpio pin changes ("userland gpio interrupts").

This is an import of the Google Summer of Code 2018 project completed by
Christian Kramer (and, sadly, ignored by us f

Provide userland notification of gpio pin changes ("userland gpio interrupts").

This is an import of the Google Summer of Code 2018 project completed by
Christian Kramer (and, sadly, ignored by us for two years now). The goals
stated for that project were:

FreeBSD already has support for interrupts implemented in the GPIO
controller drivers of several SoCs, but there are no interfaces to take
advantage of them out of user space yet. The goal of this work is to
implement such an interface by providing descriptors which integrate
with the common I/O system calls and multiplexing mechanisms.

The initial imported code supports the following functionality:

- A kernel driver that provides an interface to the user space; the
existing gpioc(4) driver was enhanced with this functionality.
- Implement support for the most common I/O system calls / multiplexing
mechanisms:
- read() Places the pin number on which the interrupt occurred in the
buffer. Blocking and non-blocking behaviour supported.
- poll()/select()
- kqueue()
- signal driven I/O. Posting SIGIO when the O_ASYNC was set.
- Many-to-many relationship between pins and file descriptors.
- A file descriptor can monitor several GPIO pins.
- A GPIO pin can be monitored by multiple file descriptors.
- Integration with gpioctl and libgpio.

I added some fixes (mostly to locking) and feature enhancements on top of
the original gsoc code. The feature ehancements allow the user to choose
between detailed and summary event reporting. Detailed reporting provides
a record describing each pin change event. Summary reporting provides the
time of the first and last change of each pin, and a count of how many times
it changed state since the last read(2) call. Another enhancement allows
the recording of multiple state change events on multiple pins between each
call to read(2) (the original code would track only a single event at a time).

The phabricator review for these changes timed out without approval, but I
cite it below anyway, because the review contains a series of diffs that
show how I evolved the code from its original state in Christian's github
repo for the gsoc project to what is being commited here. (In effect,
the phab review extends the VC history back to the original code.)

Submitted by: Christian Kramer
Obtained from: https://github.com/ckraemer/freebsd/tree/gsoc2018
Differential Revision: https://reviews.freebsd.org/D27398

show more ...


Revision tags: release/12.2.0
# f31030ba 22-Jun-2020 Andriy Gapon <avg@FreeBSD.org>

gpiobus_release_pin: remove incorrect prefix from error messages

It's interesting that similar messages from gpiobus_acquire_pin never
had any prefix while gpiobus_release_pin messages were prefixed

gpiobus_release_pin: remove incorrect prefix from error messages

It's interesting that similar messages from gpiobus_acquire_pin never
had any prefix while gpiobus_release_pin messages were prefixed with
"gpiobus_acquire_pin".
Anyway, the prefix is not that useful and can be deduced from context.

MFC after: 2 weeks

show more ...


Revision tags: release/11.4.0
# 1d89282c 06-Dec-2019 Ian Lepore <ian@FreeBSD.org>

Implement bus_rescan for gpiobus(4). This allows on-the-fly reconfiguration
of gpio devices by using kenv to add hints for a new device and then do
'devctl rescan gpiobus4' to make the new device(s)

Implement bus_rescan for gpiobus(4). This allows on-the-fly reconfiguration
of gpio devices by using kenv to add hints for a new device and then do
'devctl rescan gpiobus4' to make the new device(s) attach.

It's not particularly easy to detect whether the 'at' hint has been deleted
for a child device that's currently attached, so this doesn't handle that.
But the user can use devctl commands to manually detach an existing device.

show more ...


# 2d764957 02-Dec-2019 Ian Lepore <ian@FreeBSD.org>

Do not initialize the flags field in struct gpiobus_pin from the flags in
struct gpio_pin. It turns out these two sets of flags are completely
unrelated to each other.

Also, update the comment for

Do not initialize the flags field in struct gpiobus_pin from the flags in
struct gpio_pin. It turns out these two sets of flags are completely
unrelated to each other.

Also, update the comment for GPIO_ACTIVE_LOW to reflect the fact that it
does get set, somewhat unobviously, by code that parses FDT data. The bits
from the FDT cell containing flags are just copied to gpiobus_pin.flags, so
there's never any obvious reference to the symbol GPIO_ACTIVE_LOW being
stored into the flags field.

show more ...


# 37045806 01-Dec-2019 Ian Lepore <ian@FreeBSD.org>

Move most of the gpio_pin_* functions from ofw_gpiobus.c to gpiobus.c so
that they can be used by drivers on non-FDT-configured systems. Only the
functions related to acquiring pins by parsing FDT d

Move most of the gpio_pin_* functions from ofw_gpiobus.c to gpiobus.c so
that they can be used by drivers on non-FDT-configured systems. Only the
functions related to acquiring pins by parsing FDT data remain in
ofw_gpiobus. Also, add two new functions for acquiring gpio pins based on
child device_t and index, or on the bus device_t and pin number. And
finally, defer reserving pins for gpiobus children until they acquire the
pin, rather than reserving them as soon as the child is added (before it's
even known whether the child will attach).

This will allow drivers configured with hints (or any other mechanism) to
use the same code as drivers configured via FDT data. Until now, a hinted
driver and an FDT driver had to be two completely different sets of code,
because hinted drivers could only use gpiobus calls to manipulate pins,
while fdt-configured drivers could not use that API (due to not always being
children of the bus that owns the pins) and had to use the newer
gpio_pin_xxxx() functions. Now drivers can be written in the more
traditional form, where most of the code is shared and only the resource
acquisition code at attachment time changes.

show more ...


Revision tags: release/12.1.0, release/11.3.0
# 7f49ce7a 28-Jun-2019 Alan Somers <asomers@FreeBSD.org>

MFHead @349476

Sponsored by: The FreeBSD Foundation


# 061b38cd 27-Jun-2019 Andriy Gapon <avg@FreeBSD.org>

gpiobus: provide a new hint, pin_list

"pin_list" allows to specify child pins as a list of pin numbers.
Existing hint "pins" serves the same purpose but with a 32-bit wide bit
mask. One problem wit

gpiobus: provide a new hint, pin_list

"pin_list" allows to specify child pins as a list of pin numbers.
Existing hint "pins" serves the same purpose but with a 32-bit wide bit
mask. One problem with that is that a controller can have more than 32
pins. One example is amdgpio. Also, a list of numbers is a little bit
more human friendly than a matching bit mask. As a side note, it seems
that in FDT pins are typically specified by their numbers as well.

This commit also adds accessors for instance variables (IVARs) that
define the child pins. My primary goal is to allow a child to be
configured programmatically rather than via hints (assuming that FDT is
not supported on a platform). Also, while a child should not care about
specific pin numbers that are allocated to it, it could be interested in
how many were actually assigned to it.

While there, I removed "flags" instance variable. It was unused.

Reviewed by: mizhka
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D20459

show more ...


Revision tags: release/12.0.0, release/11.2.0
# ac2fffa4 21-Jan-2018 Pedro F. Giffuni <pfg@FreeBSD.org>

Revert r327828, r327949, r327953, r328016-r328026, r328041:
Uses of mallocarray(9).

The use of mallocarray(9) has rocketed the required swap to build FreeBSD.
This is likely caused by the allocation

Revert r327828, r327949, r327953, r328016-r328026, r328041:
Uses of mallocarray(9).

The use of mallocarray(9) has rocketed the required swap to build FreeBSD.
This is likely caused by the allocation size attributes which put extra pressure
on the compiler.

Given that most of these checks are superfluous we have to choose better
where to use mallocarray(9). We still have more uses of mallocarray(9) but
hopefully this is enough to bring swap usage to a reasonable level.

Reported by: wosch
PR: 225197

show more ...


# 26c1d774 13-Jan-2018 Pedro F. Giffuni <pfg@FreeBSD.org>

dev: make some use of mallocarray(9).

Focus on code where we are doing multiplications within malloc(9). None of
these is likely to overflow, however the change is still useful as some
static checke

dev: make some use of mallocarray(9).

Focus on code where we are doing multiplications within malloc(9). None of
these is likely to overflow, however the change is still useful as some
static checkers can benefit from the allocation attributes we use for
mallocarray.

This initial sweep only covers malloc(9) calls with M_NOWAIT. No good
reason but I started doing the changes before r327796 and at that time it
was convenient to make sure the sorrounding code could handle NULL values.

show more ...


123456