lkml.org 
[lkml]   [2023]   [Feb]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [RFC 18/24] dt-bindings: rtc: qcom-pm8xxx: add uefi-variable offset
    On Wed, 1 Feb 2023 at 17:09, Johan Hovold <johan@kernel.org> wrote:
    >
    > [ +CC: Ard ]
    >
    > On Mon, Jan 30, 2023 at 12:49:44PM -0600, Rob Herring wrote:
    > > On Thu, Jan 26, 2023 at 03:20:51PM +0100, Johan Hovold wrote:
    > > > On many Qualcomm platforms the PMIC RTC control and time registers are
    > > > read-only so that the RTC time can not be updated. Instead an offset
    > > > needs be stored in some machine-specific non-volatile memory, which a
    > > > driver can take into account.
    > > >
    > > > Add a 'qcom,uefi-rtc-info' boolean flag which indicates that the RTC
    > > > offset is stored in a Qualcomm specific UEFI variable so that the RTC
    > > > time can be updated on such platforms.
    > > >
    > > > The UEFI variable is
    > > >
    > > > 882f8c2b-9646-435f-8de5-f208ff80c1bd-RTCInfo
    > > >
    > > > and holds a 12-byte structure where the first four bytes is a GPS time
    > > > offset in little-endian byte order.
    > >
    > > Can't you just try to read the UEFI variable and use it if that
    > > succeeds?
    >
    > Generally, yes. The problem here is that this UEFI variable is not used
    > on all devices using these PMICs and I need a way to determine whether
    > to wait for the UEFI variables to become available or not (e.g. when
    > efivars support is built as module, yes, that's a thing now...).
    >

    Could we read this variable at boot and pass it to the kernel in a
    different way? That way, we only have to defer the ability to set the
    RTC, right?

    > > I don't like this in DT because what if lots of devices start storing
    > > lots of things in vendor specific UEFI variables. It doesn't scale.
    >
    > I hope we won't see that even if we already have some devices for x86
    > platforms storing MAC addresses and such in UEFI variables. They
    > currently access the UEFI firmware directly (i.e. not using the efivars
    > abstraction) and simply assume UEFI is always there.
    >
    > With the Google SMI efivars implementation or the new Qualcomm SMC-based
    > one, we need a way to determine whether to wait for efivars to become
    > registered. For drivers where efivars is always needed we can just probe
    > defer, but in this case we should not wait unless the DT indicates that
    > the RTC offset is stored in UEFI on this particular machine.
    >
    > Just as the nvmem-cell property indicates that the offset is stored in
    > some abstract nvmem, it seems reasonable to describe the offset being
    > stored in UEFI when that is the case (even if it is indeed generally
    > possible to probe for the latter).
    >
    > An alternative might be to describe the efivars fw dependency in DT too
    > (e.g. for device links), but I believe you have already expressed some
    > concerns over that:
    >
    > https://lore.kernel.org/lkml/20230130210530.GA3339716-robh@kernel.org/
    >
    > Johan

    \
     
     \ /
      Last update: 2023-03-27 00:16    [W:2.340 / U:0.176 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site