[PATCH linux 2/6] hwmon: occ: Add sysfs interface

Andrew Jeffery andrew at aj.id.au
Wed Jan 4 12:53:07 AEDT 2017


On Wed, 2017-01-04 at 10:55 +1030, Andrew Jeffery wrote:
> On Tue, 2017-01-03 at 19:13 -0500, Brad Bishop wrote:
> > > > > On Jan 3, 2017, at 7:06 PM, Joel Stanley <joel at jms.id.au>
> > > > > wrote:
> > > 
> > > On Wed, Jan 4, 2017 at 10:49 AM, Brad Bishop
> > > > > <bradleyb at fuzziesquirrel.com> wrote:
> > > > 
> > > > What if the driver is built into the kernel?  Is there such a
> > > > thing as module only drivers?
> > > 
> > > Our kernel is build with module loading disabled at present.
> > > 
> > > modprobing the driver when userspace is ready is a neat hack that
> > > we
> > > could use for now. However, the driver will need a mechanism that
> > 
> > Do you happen to know if ‘a mechanism’ is something that needs to
> > be invented or 
> > if Linux already has something?
> 
> I spoke with Rusty about this and by his response there's no existing
> "event-bus" mechanism. His suggestions for the problem were:
> 
> 1. As userspace is coordinating the host power-on, do the modprobe in
> userspace

After some discussion between Jeremy, Joel, Alistair and myself it was
decided that managing the problem from userspace was the way to go.

The rough approach is to describe the devices in the devicetree, but
mark them as 'status = "disabled";' so they are not bound to drivers on
boot. It is then userspace's job to trigger the binding as necessary,
but exactly how it should be done is unknown.

Eddie: Can you investigate what we might need to do to make this work?

Andrew

> 
> 2. Push the power-on logic into the kernel so it can trigger hotplug
> events to probe the drivers, and expose a power-{on,off}/{soft,hard}-
> reboot interface to userspace.
> 
> Andrew
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: This is a digitally signed message part
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20170104/7a6f1808/attachment.sig>


More information about the openbmc mailing list