From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2607:f8b0:4001:c0b::242; helo=mail-it0-x242.google.com; envelope-from=ard.biesheuvel@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-it0-x242.google.com (mail-it0-x242.google.com [IPv6:2607:f8b0:4001:c0b::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 4E48A210F3D89 for ; Tue, 19 Jun 2018 01:02:27 -0700 (PDT) Received: by mail-it0-x242.google.com with SMTP id p185-v6so15866289itp.4 for ; Tue, 19 Jun 2018 01:02:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=doxWjafNy5cFwSyI4/k4uldiUmN8KeqWny+hLpyeLvw=; b=cq0d/hadTrKfW05/WKsPzzVyIUdje3waT5t35I8cN0rXJ7uyOGlmbT+D5vRk3FKMqO edWpsQUNuZv56dYkaic7qwOW+3vj0zndnJPodcJPFpdfud/Uyuw7q0gkz4oaA90gxb6i P/315DZsaQhf1fska2WErC+eIRJvkc5PRQlTc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=doxWjafNy5cFwSyI4/k4uldiUmN8KeqWny+hLpyeLvw=; b=ErPeA5IogzmMZhqv/zVOkItsN9rX2olvjvaVjW9Kj2xeiWINwFe1idSdiTHB4rSaEB fdEllQ70/TSmxRFtSxI+BOjoG6BwgtYXZUVzYg3+AcB8es8BTbaWsPdrwOpma4GEFK5u NysGbM5o6sikUBVULPWNeTOVpXtVYT0V0aNd0O5AnORYD7DL0mjrxXRSFBCHjfmsZKC2 t5dtuRXulnWI0uQ7fiytCYqROwfjmL1MT2f/oLr+z30CXyBXFoUCwnYkdUxlXa3tE6er lIBFr/nfE1s2pWE5IvkD2r3grceWTZUlqZJ7HiszOHkmoELC3lxRmp6CSRT7YwBTBNTz vE3A== X-Gm-Message-State: APt69E372HOAFRIrJSo1mxITlh1WLL0bI9GXBP6QICG6tNVwo7a9kz+a aeiDL1xhbg2a4utbkDdHPjR/xvwkH9gAMknAGTLJHQ== X-Google-Smtp-Source: ADUXVKIz08arXGN3KkJWnzUBDkewtYTxMHMeN/nqh2Zr1i0IyXGkPn4HwUj6R/Ziff1i7nmoqWCeY9QDI4hbzi9HX10= X-Received: by 2002:a24:1d0e:: with SMTP id 14-v6mr11947000itj.50.1529395347058; Tue, 19 Jun 2018 01:02:27 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a6b:bbc7:0:0:0:0:0 with HTTP; Tue, 19 Jun 2018 01:02:26 -0700 (PDT) In-Reply-To: References: <20180618123155.2141-1-masahisa.kojima@linaro.org> From: Ard Biesheuvel Date: Tue, 19 Jun 2018 10:02:26 +0200 Message-ID: To: Masahisa Kojima Cc: "edk2-devel@lists.01.org" , Leif Lindholm , Yoshitoyo Osaki Subject: Re: [PATCH] Silicon/NXP/Pcf8563RealTimeClockLib: add rtc device initialization X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 08:02:28 -0000 Content-Type: text/plain; charset="UTF-8" On 19 June 2018 at 03:09, Masahisa Kojima wrote: > Hi Ard, > > This issue can be divided into following two issues. > > 1) Assertion occurs during boot time in DEBUG build, it depends on > the uninitialized RTC device state(~70%) > 2) SetTime() fails if GetTime() fails > > For issue 1), we should update pcf8563 driver, ignore retrieved data > and return error when the VL bit is 1. > Well, if returning an error is preventing us from using the shell command, I'd rather work around it. > For issue 2), it is better to update shell command as your comment. > But situation is a little complicated. > UEFI shell command can only set DATE or TIME separately. > To set DATE, current procedure is like following. > 1) GetTime(retrieve both DATE and TIME) > 2) update only DATE > 3) Write back to RTC both DATE and TIME > So, current uefi shell can not set DATE/TIME without GetTime(). > One possible solution is adding new command to set both DATE and TIME. > But it will change user experience and I'm not sure it is acceptable. > What do you think? > Yes, that makes it a bit complicated. So could we simply return EPOCH_BASE/1/1 0:0:0 in case the VL bit is set? That allows the time/date commands to work right? Then, it is up to the user to set the correct time and data, and the VL bit will remain set until they do so. > On Tue, 19 Jun 2018 at 08:56, Masahisa Kojima > wrote: >> >> On Tue, 19 Jun 2018 at 00:51, Ard Biesheuvel wrote: >> > >> > On 18 June 2018 at 16:29, Masahisa Kojima wrote: >> > > Hi Ard, >> > > >> > > Thank you for comment. >> > > >> > >> Wouldn't it be better to return EFI_DEVICE_ERROR in this case? >> > > >> > > It is first option I come up with to fix this issue. >> > > But edk2/ShellPkg/Library/UefiShellLevel2CommandsLib/TimeDate.c::CheckAndSetTime() >> > > performs GetTime()->update with user specified time->SetTime(), >> > > If GetTime() failes, SetTime() never called and user can not set time. >> > > # It really depends on the RTC device, we failed to set time in 70% devices. >> > > >> > > Another place to perform this dummy time/date setting is inside of >> > > LibRtcInitialize(). >> > > Current error occurs in setting time, and I prefer to add this process >> > > in GetTime(). >> > > >> > >> > I think we should fix the shell command instead. Setting the time >> > should be possible even if getting the time file, precisely for >> > situations like this one. >> >> OK, I agree with you.