systemd clarification

Mike Jones proclivis at
Wed Aug 26 23:45:23 AEST 2020


I found an example meta layer that modifies a service and uses gpio to power on/off.

My bigger problem is linux. From studying the regulator driver, the intent is when controlling power to hardware that is auxiliary to the device running the kernel, like ethernet or a RF power amplifier, the driver for that unit makes client driver calls to regulator.

For obmc, reg control for the host is similar. Current designs use gpio. This is limiting for non cpu based designs with complex sequencing, and does not allow for PMBus devices with margin capability in cases where the bmc is part of system testing/diagnostics.

What is missing is dbus access to the PMBus OPERATION command.

You can’t use /dev/i2c because hwmon locks it, amd hwmon is used for sensor monitoring.

I think the solution is to configure the regulator in the devicetree such that suspend and other state like changes don’t enable/disable, the add a regulatorctl driver that dbus can use for control. 

Then we have to chose a user mode interface like ioctl, debugfs, or sysfs. I’m thinking sysfs, so that it is easy to script and we don’t need a compiled user mode application. 

From the point of view of cpu based systems, nobody may care. But I am looking beyond that. I see so many custom bmc designs that could use obmc with some extra infrastructure. My interest is the power control, because that my area of specialty and applications, both for work, and as a PMBus standards committee member.

Anybody have thoughts on how to structure a regulatorctl client driver user mode interface?


Sent from my iPad

> On Aug 26, 2020, at 3:16 AM, Bruno Cornec <Bruno.Cornec at> wrote:
> Sorry Mike, I can't really comment on the OpenBMC side, as I'm more a reader here than a contriutor myself. Someone else more accustomed to that will surely give you an answer.
> Best regards,
> Bruno.
> Mike Jones said on Tue, Aug 25, 2020 at 12:03:23PM -0600:
>> Bruno,
>> A related question.
>> When I look through the services and targets installed when including meta-phosphor, power on/off seems to lead to dead ends, meaning no exe to do the work.
>> So I looked at meta-facebook, and it adds host-poweron.service, which calls exec power-util…
>> So it seems to me that meta-phosphor only puts in the infrastructure, and a particular use/design requires adding services to do the actual work of power on/off. This seems logical wrt factoring out behaviors. Is this correct?
>> This would mean in my cause of use meta-raspberrypi, I need to add the missing pieces if I want power control of my externally connected regulators to get powered on/off.
>> Mike
>>>> On Aug 25, 2020, at 10:52 AM, Bruno Cornec <Bruno.Cornec at> wrote:
>>> Hello,
>>> /etc/systemd is used to override or add locally units which are not delivered as part of the std systemd delivery which is under /lib/systemd (or /usr/lib/systemd depending on Linux distribuions). It's an easy way to modify a std unit file and change say the options used to start the daemon e.g.
>>> So:
>>> Mike Jones said on Tue, Aug 25, 2020 at 10:20:54AM -0600:
>>>> The lib path is not a search path in the systemd documentation, and the etc path has links into the lib path. So I assume services in the lib path are only run if they are linked into the etc path. Is this correct?
>>> No. they are run if they are enabled (systemctl list-units to see that)
>>>> If there is a an After= that lists something found only in the lib path, I assume it will run because After is not strong enough to prevent start. But if it was Requires=, then I assume it cannot start unless it is linked into the etc path so that it is available. Is this correct?
>>> No. No link is necessary.
>>> Best regards,
>>> Bruno.
>>> --
>>> HPE WW FLOSS Technology Strategist
>>> Open Source Profession, WW Linux Community Lead
>>> FLOSS projects:
>>> Musique ancienne?
> -- 
> HPE WW FLOSS Technology Strategist
> Open Source Profession, WW Linux Community Lead
> FLOSS projects:
> Musique ancienne?

More information about the openbmc mailing list