On Sat, Sep 5, 2020 at 5:16 AM Randy Dunlap <rdunlap@xxxxxxxxxxxxx> wrote: > > Hi, > > On 9/4/20 8:45 AM, Bartosz Golaszewski wrote: > > From: Bartosz Golaszewski <bgolaszewski@xxxxxxxxxxxx> > > > > There's some documentation for gpio-mockup's debugfs interface in the > > driver's source but it's not much. Add proper documentation for this > > testing module. > > > > Signed-off-by: Bartosz Golaszewski <bgolaszewski@xxxxxxxxxxxx> > > --- > > .../admin-guide/gpio/gpio-mockup.rst | 87 +++++++++++++++++++ > > 1 file changed, 87 insertions(+) > > create mode 100644 Documentation/admin-guide/gpio/gpio-mockup.rst > > > > diff --git a/Documentation/admin-guide/gpio/gpio-mockup.rst b/Documentation/admin-guide/gpio/gpio-mockup.rst > > new file mode 100644 > > index 000000000000..1d452ee55f8d > > --- /dev/null > > +++ b/Documentation/admin-guide/gpio/gpio-mockup.rst > > @@ -0,0 +1,87 @@ > > +.. SPDX-License-Identifier: GPL-2.0-only > > + > > +GPIO Testing Driver > > +=================== > > + > > +The GPIO Testing Driver (gpio-mockup) provides a way to create simulated GPIO > > +chips for testing purposes. There are two ways of configuring the chips exposed > > +by the module. The lines can be accessed using the standard GPIO character > > +device interface as well as manipulated using the dedicated debugfs directory > > +structure. > > Could configfs be used for this instead of debugfs? > debugfs is ad hoc. > > > + > > +Creating simulated chips using debugfs > > +-------------------------------------- > > + > > +When the gpio-mockup module is loaded (or builtin) it creates its own directory > > +in debugfs. Assuming debugfs is mounted at /sys/kernel/debug/, the directory > > +will be located at /sys/kernel/debug/gpio-mockup/. Inside this directory there > > +are two attributes: new_device and delete_device. > > + > > +New chips can be created by writing a single line containing a number of > > +options to "new_device". For example: > > + > > +.. code-block:: sh > > + > > + $ echo "label=my-mockup num_lines=4 named_lines" > /sys/kernel/debug/gpio-mockup/new_device > > + > > +Supported options: > > + > > + num_lines=<num_lines> - number of GPIO lines to expose > > + > > + label=<label> - label of the dummy chip > > + > > + named_lines - defines whether dummy lines should be named, the names are > > + of the form X-Y where X is the chip's label and Y is the > > + line's offset > > + > > +Note: only num_lines is mandatory. > > + > > +Chips can be dynamically removed by writing the chip's label to > > +"delete_device". For example: > > + > > +.. code-block:: sh > > + > > + echo "gpio-mockup.0" > /sys/kernel/debug/gpio-mockup/delete_device > > + > > +Creating simulated chips using module params > > +-------------------------------------------- > > + > > +Note: this is an older, now deprecated method kept for backward compatibility > > +for user-space tools. > > + > > +When loading the gpio-mockup driver a number of parameters can be passed to the > > +module. > > + > > + gpio_mockup_ranges > > + > > + This parameter takes an argument in the form of an array of integer > > + pairs. Each pair defines the base GPIO number (if any) and the number > > + of lines exposed by the chip. If the base GPIO is -1, the gpiolib > > + will assign it automatically. > > + > > + Example: gpio_mockup_ranges=-1,8,-1,16,405,4 > > + > > + The line above creates three chips. The first one will expose 8 lines, > > + the second 16 and the third 4. The base GPIO for the third chip is set > > + to 405 while for two first chips it will be assigned automatically. > > + > > + gpio_named_lines > > + > > + This parameter doesn't take any arguments. It lets the driver know that > > + GPIO lines exposed by it should be named. > > + > > + The name format is: gpio-mockup-X-Y where X is the letter associated > > + with the mockup chip and Y is the line offset. > > Where does this 'X' letter associated with the mockup chip come from? > > > + > > +Manipulating simulated lines > > +---------------------------- > > + > > +Each mockup chip creates its own subdirectory in /sys/kernel/debug/gpio-mockup/. > > +The directory is named after the chip's label. A symlink is also created, named > > +after the chip's name, which points to the label directory. > > + > > +Inside each subdirectory, there's a separate attribute for each GPIO line. The > > +name of the attribute represents the line's offset in the chip. > > + > > +Reading from a line attribute returns the current value. Writing to it (0 or 1) > > +changes its pull. > > What does "pull" mean here? > Yeah I should probably clarify this. "Pull" here means a simulated pull-down/up resistor basically. Bart