Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
In-Reply-To: <YRhQJ4kdyu1Xs1Rb@piout.net>
From:   "Milton Miller II" <miltonm@us.ibm.com>
To:     "Alexandre Belloni" <alexandre.belloni@bootlin.com>
Cc:     "Paul Fertser" <fercerpav@gmail.com>,
        "Ivan Mikhaylov" <i.mikhaylov@yadro.com>,
        "Alessandro Zummo" <a.zummo@towertech.it>,
        openbmc@lists.ozlabs.org, linux-kernel@vger.kernel.org
Date:   Tue, 17 Aug 2021 18:04:09 +0000
Message-ID: <OFBF96A764.75CCED3A-ON00258734.0062B30C-00258734.00634222@ibm.com>
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
MIME-Version: 1.0
Sensitivity: 
Importance: Normal
References: <YRhQJ4kdyu1Xs1Rb@piout.net>,<20210810154436.125678-1-i.mikhaylov@yadro.com>
 <20210814224215.GX15173@home.paul.comp>
Subject: RE: [PATCH 0/2] rtc: pch-rtc: add Intel Series PCH built-in read-only RTC
Precedence: bulk


On Aug 16, 2021, Alexandre Belloni wrote:
>On 15/08/2021 01:42:15+0300, Paul Fertser wrote:
>> On Tue, Aug 10, 2021 at 06:44:34PM +0300, Ivan Mikhaylov wrote:
>> > Add RTC driver with dt binding tree document. Also this driver
>adds one sysfs
>> > attribute for host power control which I think is odd for RTC
>driver.
>> > Need I cut it off and use I2C=5FSLAVE=5FFORCE? I2C=5FSLAVE=5FFORCE is =
not
>good
>> > way too from my point of view. Is there any better approach?
>>=20
>> Reading the C620 datasheet I see this interface also allows other
>> commands (wake up, watchdog feeding, reboot etc.) and reading
>statuses
>> (e.g Intruder Detect, POWER=5FOK=5FBAD).
>>=20
>> I think if there's any plan to use anything other but RTC via this
>> interface then the driver should be registered as an MFD.
>>=20
>
>This is not the current thinking, if everything is integrated, then
>there is no issue registering a watchdog from the RTC driver. I'll
>let
>you check with Lee...

I think the current statement is "if they are truly disjoint=20
hardware controls" then an MFD might suffice, but if they require=20
software cordination the new auxillary bus seems to be desired.

>>However, I'm not sure what is the correct interface for
>poweroff/reboot
>control.

While there is a gpio interface to a simple regulator switch,
the project to date has been asserting direct or indirect=20
gpios etc to control the host.   If these are events to=20
trigger a change in state and not a direct state change
that some controller trys to follow, maybe a message delivery=20
model?   (this is not to reboot or cycle the bmc).

milton