Allow the default user to access the new gpio character device #2289

gohai · 2017-11-26T17:55:46Z

I want to switch Processing from using the legacy sysfs interface to the new character device interface (/dev/gpiochip*). To make this possible, those devices should be owned by the gpio group.

The following line, added to 99-com.rules achieves this:

SUBSYSTEM=="gpio", GROUP="gpio", MODE="0660"

Could this be added for upcoming Raspbian releases? Thanks!

The text was updated successfully, but these errors were encountered:

pelwell · 2017-11-27T13:20:32Z

I'm in favour - an efficient user-space GPIO API has been long overdue.

@XECDesign Can we insert this as line 6 of /etc/udev/rules.d/99-com.rules? At some point we should also add the new kernel-supplied tools (lsgpio, gpio-hammer and gpio-event-mon) to the distro, but the current output isn't pretty - all the pins are marked as unused, with no helpful labels(*).

(*) Minor correction - on 4.14 the brcmvirt-gpio driver shows "led0" for line 0, but that's all.

gohai · 2017-11-27T13:37:33Z

I remember a discussion with the gpio maintainer Linus Walleij on the Raspberry Kernel mailing list, where the issue of labels came up. Some, me included, pushed back against using the physical header pin numbers, as we seem to have finally settled on GPIO numbers - and reverting this might only add to confusion. Linus solicited feedback, but I don’t know what became with the patch ultimately. My prime motivation for wanting to try out this API is that I *believe* it will allow us to set and clear pull-ups. Currently board seems to come up with the pull-ups set to defaults as per datasheet, which seems pretty random.

…

On Mon 27. Nov 2017 at 14:22, Phil Elwell ***@***.***> wrote: I'm in favour - an efficient user-space GPIO API has been long overdue. @XECDesign <https://github.com/xecdesign> Can we insert this as line 6 of /etc/udev/rules.d/99-com.rules? At some point we should also add the new kernel-supplied tools (lsgpio, gpio-hammer and gpio-event-mon) to the distro, but the current output isn't pretty - all the pins are marked as unused, with no helpful labels(*). (*) Minor correction - on 4.14 the brcmvirt-gpio driver shows "led0" for line 0, but that's all. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#2289 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEt2K59dlEvmsl-Uzi558xqUWuMETdmhks5s6rcwgaJpZM4Qq2_y> .

pelwell · 2017-11-27T13:46:48Z

I want to see BRCM GPIO/"pin" numbering everywhere - it's used exclusively by the firmware and the kernel, and it's guaranteed to make sense on any arbitrary hardware design (how would you use 40-pin header values on a Compute Module?).

If you have any feedback for us in terms of how to make the new GPIO interface more usable, or warnings about problems you have encountered, then please let us know.

XECDesign · 2017-11-27T14:05:51Z

Added: RPi-Distro/raspberrypi-sys-mods@bd5a201
It should show up in apt in a week or two.

I'll need to create a package for lsgpio and the others, but I'll save that for later.

gohai · 2017-11-27T14:08:27Z

Thank you!

…

On Mon 27. Nov 2017 at 15:07, XECDesign ***@***.***> wrote: Added: ***@***.*** <RPi-Distro/raspberrypi-sys-mods@bd5a201> It should show up in apt in a week or two. I'll need to create a package for lsgpio and the others, but I'll save that for later. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#2289 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEt2K9HmPV90rVy58KmmxjLTJrmBGCFhks5s6sHTgaJpZM4Qq2_y> .

lategoodbye · 2017-11-30T19:21:14Z

As a reference here is the lsgpio output of a Raspberry Pi 1 B with upstream 4.14:

GPIO chip: gpiochip0, "pinctrl-bcm2835", 54 GPIO lines
        line  0: "SDA0" unused
        line  1: "SCL0" unused
        line  2: "SDA1" unused
        line  3: "SCL1" unused
        line  4: "GPIO_GCLK" unused
        line  5: "CAM_GPIO1" unused [output]
        line  6: "LAN_RUN" unused [output]
        line  7: "SPI_CE1_N" unused
        line  8: "SPI_CE0_N" unused
        line  9: "SPI_MISO" unused
        line 10: "SPI_MOSI" unused
        line 11: "SPI_SCLK" unused
        line 12: "NC" unused
        line 13: "NC" unused
        line 14: "TXD0" unused
        line 15: "RXD0" unused
        line 16: "STATUS_LED_N" "ACT" [kernel output active-low]
        line 17: "GPIO17" unused
        line 18: "GPIO18" unused
        line 19: "NC" unused
        line 20: "NC" unused
        line 21: "GPIO21" unused
        line 22: "GPIO22" unused
        line 23: "GPIO23" unused
        line 24: "GPIO24" unused
        line 25: "GPIO25" unused
        line 26: "NC" unused
        line 27: "CAM_GPIO0" unused [output]
        line 28: "CONFIG0" unused
        line 29: "CONFIG1" unused
        line 30: "CONFIG2" unused
        line 31: "CONFIG3" unused
        line 32: "NC" unused
        line 33: "NC" unused
        line 34: "NC" unused
        line 35: "NC" unused
        line 36: "NC" unused
        line 37: "NC" unused
        line 38: "NC" unused
        line 39: "NC" unused
        line 40: "PWM0_OUT" unused
        line 41: "NC" unused
        line 42: "NC" unused
        line 43: "NC" unused
        line 44: "NC" unused
        line 45: "PWM1_OUT" unused
        line 46: "HDMI_HPD_P" unused
        line 47: "SD_CARD_DET" unused
        line 48: "SD_CLK_R" unused
        line 49: "SD_CMD_R" unused
        line 50: "SD_DATA0_R" unused
        line 51: "SD_DATA1_R" unused
        line 52: "SD_DATA2_R" unused
        line 53: "SD_DATA3_R" unused

JamesH65 · 2017-12-04T17:58:33Z

@XECDesign Can be closed?

XECDesign · 2017-12-04T18:07:23Z

@JamesH65 The updated raspberrypi-sys-mods package is in the repo, so I would say yes. However, nothing has been done to add lsgpio and other binaries or change how they display data.

gohai · 2017-12-04T18:11:14Z

Wanted to correct what I posted above: I realized that currently the new API does not allow the setting and clearing of pull-up/down resistors. I confused them with setting open source / open drain, but these things seem to be orthogonal really.

lategoodbye · 2017-12-04T19:31:15Z

From my point of view it should be easier to add a pull-up/down IOCTL instead of extending the sysfs.

pelwell · 2017-12-04T19:58:37Z

I'm happy for us to be supporting the new interface, whether or not it supports the setting of pulls yet. Let's keep this open until we've added the new utilities.

gohai · 2017-12-05T08:17:58Z

@lategoodbye Agree. The new (IOCTL) interface already has an extensible flags field, which is used e.g. for indicating whether the line should be an input or output. This should be sufficient for implementing the most basic pull-up/down configuration at least.

JamesH65 · 2018-04-20T15:12:25Z

Anyone have any progress to report on this one? Would be nice to know what stage we are at.

JamesH65 · 2018-06-27T11:27:47Z

@pelwell Anything to report?

pelwell · 2018-06-27T11:30:21Z

Last we heard we were waiting for lsgpio and family to make it into Raspbian.

JamesH65 · 2018-06-27T11:41:48Z

@XECDesign @spl237 Is this now in your court?

lategoodbye · 2018-06-27T11:44:22Z

I think this is related to @gohai intension, starting with 4.18 the pinctrl driver would be generic.

XECDesign · 2018-06-27T12:56:11Z

I don't feel a sense of urgency to add the gpio-utils package. Very few distros include them and there are many other binaries we don't include. The original issue is resolved. The new package would be for bonus points.

lategoodbye · 2018-06-27T18:19:48Z

Sure there is no urgency, but the sysfs-gpio is obsolete since 2016.

Edit: I know you don't care about mainline, but CONFIG_GPIO_SYSFS has been disabled in multi_v7_defconfig and arm64/defconfig since 2016-11-30 (Linux 4.10).

JamesH65 · 2019-07-30T16:51:20Z

This issue will be closed within 30 days unless further interactions are posted. If you wish this issue to remain open, please add a comment. A closed issue may be reopened if requested.

XECDesign · 2019-07-30T16:57:10Z

Bumping it since it's probably time to package up gpio-utils.

XECDesign · 2019-08-08T11:41:22Z

gpio-utils added to buster and should show up in the repo within about an hour.

pelwell · 2019-08-08T11:43:14Z

Nice.

[ Upstream commit 2a9de42 ] ====================================================== WARNING: possible circular locking dependency detected 6.5.0-kfd-yangp #2289 Not tainted ------------------------------------------------------ kworker/0:2/996 is trying to acquire lock: (srcu){.+.+}-{0:0}, at: __synchronize_srcu+0x5/0x1a0 but task is already holding lock: ((work_completion)(&svms->deferred_list_work)){+.+.}-{0:0}, at: process_one_work+0x211/0x560 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #3 ((work_completion)(&svms->deferred_list_work)){+.+.}-{0:0}: __flush_work+0x88/0x4f0 svm_range_list_lock_and_flush_work+0x3d/0x110 [amdgpu] svm_range_set_attr+0xd6/0x14c0 [amdgpu] kfd_ioctl+0x1d1/0x630 [amdgpu] __x64_sys_ioctl+0x88/0xc0 -> #2 (&info->lock#2){+.+.}-{3:3}: __mutex_lock+0x99/0xc70 amdgpu_amdkfd_gpuvm_restore_process_bos+0x54/0x740 [amdgpu] restore_process_helper+0x22/0x80 [amdgpu] restore_process_worker+0x2d/0xa0 [amdgpu] process_one_work+0x29b/0x560 worker_thread+0x3d/0x3d0 -> #1 ((work_completion)(&(&process->restore_work)->work)){+.+.}-{0:0}: __flush_work+0x88/0x4f0 __cancel_work_timer+0x12c/0x1c0 kfd_process_notifier_release_internal+0x37/0x1f0 [amdgpu] __mmu_notifier_release+0xad/0x240 exit_mmap+0x6a/0x3a0 mmput+0x6a/0x120 do_exit+0x322/0xb90 do_group_exit+0x37/0xa0 __x64_sys_exit_group+0x18/0x20 do_syscall_64+0x38/0x80 -> #0 (srcu){.+.+}-{0:0}: __lock_acquire+0x1521/0x2510 lock_sync+0x5f/0x90 __synchronize_srcu+0x4f/0x1a0 __mmu_notifier_release+0x128/0x240 exit_mmap+0x6a/0x3a0 mmput+0x6a/0x120 svm_range_deferred_list_work+0x19f/0x350 [amdgpu] process_one_work+0x29b/0x560 worker_thread+0x3d/0x3d0 other info that might help us debug this: Chain exists of: srcu --> &info->lock#2 --> (work_completion)(&svms->deferred_list_work) Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock((work_completion)(&svms->deferred_list_work)); lock(&info->lock#2); lock((work_completion)(&svms->deferred_list_work)); sync(srcu); Signed-off-by: Philip Yang <[email protected]> Reviewed-by: Felix Kuehling <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>

JamesH65 added Waiting for external input Waiting for a comment from the originator of the issue, or a collaborator. Waiting for internal comment Waiting for comment from a member of the Raspberry Pi engineering team labels Apr 20, 2018

mcdeoliveira mentioned this issue Apr 25, 2018

Creating a library and making mutex visible StrawsonDesign/rc_mpu#2

Merged

golemparts mentioned this issue Dec 21, 2018

Gpio::new() PermissionDenied golemparts/rppal#15

Closed

XECDesign self-assigned this Jul 30, 2019

Allow the default user to access the new gpio character device #2289

Allow the default user to access the new gpio character device #2289

Comments

gohai commented Nov 26, 2017

pelwell commented Nov 27, 2017

Uh oh!

gohai commented Nov 27, 2017 via email

Uh oh!

pelwell commented Nov 27, 2017

Uh oh!

XECDesign commented Nov 27, 2017

Uh oh!

gohai commented Nov 27, 2017 via email

Uh oh!

lategoodbye commented Nov 30, 2017

Uh oh!

JamesH65 commented Dec 4, 2017

Uh oh!

XECDesign commented Dec 4, 2017

Uh oh!

gohai commented Dec 4, 2017

Uh oh!

lategoodbye commented Dec 4, 2017

Uh oh!

pelwell commented Dec 4, 2017

Uh oh!

gohai commented Dec 5, 2017

Uh oh!

JamesH65 commented Apr 20, 2018

Uh oh!

JamesH65 commented Jun 27, 2018

Uh oh!

pelwell commented Jun 27, 2018

Uh oh!

JamesH65 commented Jun 27, 2018

Uh oh!

lategoodbye commented Jun 27, 2018

Uh oh!

XECDesign commented Jun 27, 2018

Uh oh!

lategoodbye commented Jun 27, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

JamesH65 commented Jul 30, 2019

Uh oh!

XECDesign commented Jul 30, 2019

Uh oh!

XECDesign commented Aug 8, 2019

Uh oh!

pelwell commented Aug 8, 2019

Uh oh!

lategoodbye commented Jun 27, 2018 •

edited

Loading