Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Expand the rpi_gpio component to support orangepi as well. #19732
Instead of adding a new component for orangepi (which is a raspberry pi clone), let's just extend the existing component to support more than one family of boards.
I have tested this patch on a raspberry pi 3 and an orangepi prime, in both cases with a LED on a GPIO controlled switch. Note that the orangepi GPIO library requires access to /dev/mem, which I have resolved for now by running Home Assistant as root.
I'm holding off on a home-assistant.io pull request to match this until I get a feel for if this approach is acceptable to you.
This code was implemented to support a Home Assistant tutorial running at linux.conf.au 2019 in a couple of weeks, it would be super cool to be able to have this merged by then so that attendees don't need to carry private patches.
Example entry for
@mikalstill, it looks like your link is https://home-assistant.io/developers/cla_sign_start/?pr=home-assistant/home-assistant#19732
The message from the home assistant bot had it (the word here was hyperlinked to that url).
When attempting to inspect the commits of your pull request for CLA signature status among all authors we encountered commit(s) which were not linked to a GitHub account, thus not allowing us to determine their status(es).
The commits that are missing a linked GitHub account are the following:
Unfortunately, we are unable to accept this pull request until this situation is corrected.
Here are your options:
We apologize for this inconvenience, especially since it usually bites new contributors to Home Assistant. We hope you understand the need for us to protect ourselves and the great community we all have built legally. The best thing to come out of this is that you only need to fix this once and it benefits the entire Home Assistant and GitHub community.
Thanks, I look forward to checking this PR again soon!
Totally agreed. That said, its not an as-root requirement, its a with-permissions-for-/dev/mem requirement. That can be done with filesystem permissions if required.
My understanding is that Raspberry Pi deals with this by having a kernel driver which exposes the GPIOs in a more friendly manner. I'm not opposed to doing that for OrangePi, but it will take a little time to do.
added a commit
this pull request
Jan 4, 2019
The Rpi.GPIO library first tries /dev/gpiomem (which is Broadcom specific, and has perms granted via udev), then falls back to /dev/mem (which will require perms).
We can solve the access issue for /dev/mem with some udev rules.
Having said that, after some discussion around the office at Ozlabs, /dev/mem is quite dangerous, any process that can access that can effectively access the memory of any process on the system, including the kernel, and library devs who access that should be admonished^H^H^H^H taken aside and taught how to abstract access via kernel driver.
In this case, we should have access to /sys/class/gpio, which in provided by the pinctrl subsystem on the Orange Pi. This library access GPIO via that: https://pypi.org/project/OPi.GPIO/ It will need a patch to support the Orange Pi Prime, but that seems pretty straightforward.
Ok, so this latest patch does a few things:
I think that resolves all of fabaff's concerns?
Hey @pvizeli, it was suggested I ping you about two things around this PR: