System-files interface for /dev/gpiochip

store-requests
1

Previously, the application matter-pi-gpio-commander used the library WiringPI to handle GPIO, accessing the /dev/gpiomem interface, as seen here, and then used gpio-memory-control interface.

Now, with WiringPI being an archived and unmaintained library, and the deprecation of the sysfs interface since Kernel 4.8, the official method for GPIO access from user space is using the character device /dev/gpiochip* with the libgpiod library.

However, there is currently no snap interface for the usage of character devices, despite ongoing efforts discussed here and reported in this bug which suggests the usage of gpio aggregator. It seems there is no specific snap interface for the character device, but itā€™s possible to use the system-files interface, as shown in this PR, allowing straightforward access:

plugs:
  gpiochip0:
    interface: system-files
    read:
      - /sys/devices/platform/soc/fe200000.gpio/gpiochip0/dev
    write: 
      - /dev/gpiochip0

We would like to seek the opinion of the security team and/or the @review-team on this approach.

2

Hi @LOCNNIL

After a quick look, I couldnā€™t find any interface that better fits this situation. Thus, Iā€™ll be happy to support the use system-files for the time being.

+1 for granting auto-connection for this system-files request

@reviewers Iā€™m not sure about the naming convention for the plug in this concrete situation. I may be happy as it is, but I would like to know your opinion

That said, using /dev/gpiochip0 looks pretty hardware specific (of course the name suggest that the target of this application is Rpi, but stillā€¦) and I would suggest to move the gpio-aggregator as soon as it will be released :slight_smile:

1 Like
3

system-files should/cannot be used to access /dev/* devices, as it stops working as soon as another interface accessing /dev/* is used at the same time*. custom-device should be used instead.

  • this is a quirk, we are considering making the behavior consistent for UC24 so that this never works, as custom-device exists now
4

will custom-device actually work on classic systems ? IIRC it needs definitions in the gadget ā€¦

1 Like
5

Regarding the custom-device interface, would it also work for the /sys/devices/platform/soc/fe200000.gpio/gpiochip0/dev file?

Additionally, the address fe200000 is specific to the Raspberry Pi 4 Model B. We would require a wildcard to include other RPi models. However, since wildcards are not allowed yet (please correct me if Iā€™m wrong), we are creating a list with the necessary files for each 64-bit model.

6

yes, it works assuming the store gives permission which means the use is justifiable, as the interface slots are superprivileged, we should support already defining them on an app, that app will need a matching plug that gets self-auto-connected.

Recently, before this topic, I have been writing a spread exactly about this, because it is a reasonable use case in some scenarios; the most obvious one is a generally distributed app for some very specific hardware that has a broader use than specific UC devices:

(that test is using video just for convenience, not realism)

1 Like
7

We would require a wildcard to include other RPi models. However, since wildcards are not allowed yet .

We have been asked before to lift that restriction. Technically itā€™s possible. The main issue is that reviewers need to be careful that those wildcards are not too broad, and to setup the snap-declaration correctly.

8

Based on the @pedronis suggestion, I achieve success on using the custom-device interface.

@ogra about your concerns on need of a gadget definition, seems that now you can declare a slot inside a snap to be the provider and connect a plug to itself. Like showed by @pedronis and like I did on this commit: https://github.com/canonical/matter-pi-gpio-commander/pull/42/commits/039b537b47a0fc873fabf789fd050d2a1cb077f5

9

Yeah, you could always do this but we did set up a policy to not allow it at all (your upload would have been rejected) ā€¦ seems we here have an exception now :slight_smile:

1 Like
10

Oh, I wasnā€™t aware that it was always possible, thank you for letting me know! :sweat_smile:

But yeah, seems a good and reasonable exception to this policy, since a gpio-aggregator interface is not ready yet.

11

+1 from me on this (as you already know, I think all snaps should always have their own independent device cgroup)