systemd clarification

[Matt Spinler]

Hi,

Not sure you will find it useful, but have a regular control app, 
phosphor-regulators, that uses /dev/i2c along with
JSON configuration files to do arbitrary regulator control and 
configuration.  It also does its own sensor monitoring as
the devices can't use hwmon since it already uses /dev/i2c.  It has 
D-Bus interfaces into it to kick things off.

https://github.com/openbmc/phosphor-power/tree/master/phosphor-regulators

Ideally this would all have been done using device drivers, but we were 
resource constrained and also have to deal
with our hardware teams wanting to be able to do last minute 
configuration changes to all sorts of models of
regulators we use.

Also, while this is geared toward regulators, it would work for any 
PMBus/I2C based devices.

On 8/26/2020 8:45 AM, Mike Jones wrote:
> Bruno,
>
> 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?
>
> Mike
>
> Sent from my iPad
>
>> On Aug 26, 2020, at 3:16 AM, Bruno Cornec <Bruno.Cornec at hpe.com> 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 hpe.com> 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      http://www.hpe.com/engage/opensource
>>>> Open Source Profession, WW Linux Community Lead    http://github.com/bcornec
>>>> FLOSS projects:     http://mondorescue.org         http://project-builder.org
>>>> Musique ancienne?   http://www.musique-ancienne.org   http://www.medieval.org
>> -- 
>> HPE WW FLOSS Technology Strategist      http://www.hpe.com/engage/opensource
>> Open Source Profession, WW Linux Community Lead    http://github.com/bcornec
>> FLOSS projects:     http://mondorescue.org        http://project-builder.org
>> Musique ancienne?   http://www.musique-ancienne.org  http://www.medieval.org