From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2607:f8b0:4003:c06::241; helo=mail-oi0-x241.google.com; envelope-from=masahisa.kojima@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-oi0-x241.google.com (mail-oi0-x241.google.com [IPv6:2607:f8b0:4003:c06::241]) (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 CDD132118FF1E for ; Tue, 19 Jun 2018 18:54:26 -0700 (PDT) Received: by mail-oi0-x241.google.com with SMTP id f79-v6so1590524oib.7 for ; Tue, 19 Jun 2018 18:54:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ktTpOKLtEqbWwexh9swnIDoSkFgsICKgGD+S4vyCOyw=; b=D0gkflM402IsnartgtFP8Cg36Js4nhrIaA+JkguSN9YOD7sf57DnwTr3si0bin1uZs J/0I6T9pFQm1geS0CsXfenS8CqA/0mumnSd+W/Gf7LProBohpp1VbUqz4ENNFX0gbcXH 0rZl0Qv0YeEl1yYp/QV76SrjvwdF32ThfiOfo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ktTpOKLtEqbWwexh9swnIDoSkFgsICKgGD+S4vyCOyw=; b=PRrVA9YNd72XUyH5aMSs4m5bYhhXKNSIGkjX15jqg7i3vROytlpCf+ev3yuoBO2XzN 1XieEACh7i44dXDfETlQQ38EXbWWY5yyujTGbbbduovfVWV9Mj47osT7hha3YoFwml/4 QgMYko6lZ42ofau1xDHLWPoyA6v5IYfjrNkG6QxJMe1G6y2eAFFt/zfvZ+SrhxWaNSQe NnFpNnIXOeEKWAuD47iCipSTWrg9upYtL9FkHOb0/hn56RSPuY7o0UfFkPjhajFx63v1 EOWzIz2grm0iDdeyKYcctwRcTivTNMtoV8ZvqJLKvuKwILX4jasZoP9NLSZWrLtNcnKL cBpQ== X-Gm-Message-State: APt69E2+JufKa+82vXZl+iBjAvMnDPLDQQLT1oQ4scD3CEsW7uS+cKZ7 V8vzc8S4gnAcL8J9jY7iD31sHOligAWipmyL3YfhCg== X-Google-Smtp-Source: ADUXVKK5lkWcgId7zx24v1DKLXoFicK4iv8tMveTJJcAsuI7WolkUK8KQJTqElFTmBFQDKwinZmzhKz5oXzXf/oA02w= X-Received: by 2002:aca:bdc1:: with SMTP id n184-v6mr10042041oif.305.1529459665595; Tue, 19 Jun 2018 18:54:25 -0700 (PDT) MIME-Version: 1.0 References: <20180618123155.2141-1-masahisa.kojima@linaro.org> In-Reply-To: From: Masahisa Kojima Date: Wed, 20 Jun 2018 10:54:14 +0900 Message-ID: To: Ard Biesheuvel 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: Wed, 20 Jun 2018 01:54:27 -0000 Content-Type: text/plain; charset="UTF-8" Hi Ard, > 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. Yes, I can boot and set time/date correctly. I will submit v2 patch. Regards, Masahisa On Tue, 19 Jun 2018 at 17:02, Ard Biesheuvel wrote: > > 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.