Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp2160178imm; Tue, 10 Jul 2018 14:28:36 -0700 (PDT) X-Google-Smtp-Source: AAOMgpcyXy7AUkJgt5wg0d80m7QGf/B6m/WCGwsPMmM/FLIDlIL2evObGdtVqNkvHm0bZAwSgRK5 X-Received: by 2002:a17:902:6686:: with SMTP id e6-v6mr26325283plk.35.1531258116421; Tue, 10 Jul 2018 14:28:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1531258116; cv=none; d=google.com; s=arc-20160816; b=c81HmxP2gbJ+4shUeuceEizQs7HZELVhofYvpohCJraHrAo8PVnkSWhSa2oX3TW3jI El4187G0LGMUsMDKFfQfptoey1OXSS87y9yAPeV/hPJUHYmsHLhznnzxF1bf5yvNvVMm UHEJkB5Qt6/topSCETMPoO1DaPnYTryR3Jb59gn+y15xA5hcNLKg1db9LyrTu0JxiTeK gPyjtUbCCeQVLVAPT7yG8/5AMpxI/ZLHV34ZHofEAc1TotjDZvHKdlKqIikAZwCOz+wj gTBOsY2VUH4xqgFVpUi/Y/OQeSWZg3zjWr3EnEWzQc47ocgLHnHe/+/KtWnNEmyIriQc Zw1w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=ujz4uCqvy2C3RwVtFydCQSKJ7JZKcbcdcnhq17P3a0E=; b=H2XZYeF6vqPdTC6RPVZVHlAxjL3DohW7fAENSE1KcjPjKNbVbLgBEzKNQZG62nmO+T /+okwlUDmzfXnTyYqWx72kH77dQN/Q/L68GZM7SkG9i4Q2KWqMUXoSXHFY4bgRynice6 CSOndEHib+9hYOmL9s86MSQxVk1wJG+tSTtvPc9CUtFlv/s+18kXJtTGFDZs/20odiPx MA4C9MthxHGRg/N8oCyM8Wa3mz8tfGs6BGxICvNL4MXS9e2osg7nvxfkhQUZ2EhiNpa8 JwVXfjhJ+GgsjZ4kjwWuVl4qEc3DqZKvdXPlctpawN/IEbloJF7w4giXkwKbbmoPnu2H UC/g== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=ePzXtZgM; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i62-v6si17733726pfc.255.2018.07.10.14.28.21; Tue, 10 Jul 2018 14:28:36 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=ePzXtZgM; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732421AbeGJV2A (ORCPT + 99 others); Tue, 10 Jul 2018 17:28:00 -0400 Received: from mail-lj1-f193.google.com ([209.85.208.193]:45765 "EHLO mail-lj1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732258AbeGJV2A (ORCPT ); Tue, 10 Jul 2018 17:28:00 -0400 Received: by mail-lj1-f193.google.com with SMTP id q5-v6so17832751ljh.12; Tue, 10 Jul 2018 14:27:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=ujz4uCqvy2C3RwVtFydCQSKJ7JZKcbcdcnhq17P3a0E=; b=ePzXtZgMi+JSFYkv/X/deOSMpG7NTa5LYkhrvb461j2jdixS1DYPMNKNmlg0yElgsj NoyuStNN5vKYzg7yS+TXizvAc3a1bvbA/cqAxxnqZNcUGeXoc1reC0Y0XmLhWwKpWxZ/ l7BLS20e23/ESbrHCwqlXy1LVYsnJ3ZPUTAOedXEzVyFH6uK1eDLnZNI3EF1gH5zvaUL vw5PNIEcIa4byqDNtWv6JxVcnewloZBpg33tHHslNG+irhatIB10/3PjuIuZw4VCtQ1V JiA6pPstjUU3HkNwx8x6109Vs7GM34/9yXbiVOJyT3JD3XGo26O8Ix9jDB477SDQKk8a cIYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=ujz4uCqvy2C3RwVtFydCQSKJ7JZKcbcdcnhq17P3a0E=; b=Vi8zJaps3lz3xoZRN1mWOQo3DOc3dnb7CLRvTRZaJzIYFkFJbPBDlxX+SqlDXV3Caf tpfUJimpnohZuc/PRLye5zxGJ4kSCd2vgICEtjRigLQLscoP5M/6c3QPPdeN8bhVLSvW n9pDvLCN82OZtXiTml1aCGNyX9DGyHP7hlQVHj+ihvrOoLEgaggBJSTfSA0YuKL+y21t ejvpwuOjjfTYiKni7KKFiyVTzI2/YoG8a3jqJsc5KJJXK/4Cpp7Zgt+IntOfoNco8IUC da4+xG17vbwIzZS+x3yh9Xmkmtj4JkxhjNNESAAG/GFhJslgV/hOVrTrixe1RymR49gj 8jUw== X-Gm-Message-State: APt69E08O2ywU3MyyRo4N40+c6NH7VeLFZB/SArnU9tCzLIt27rrnzeT keBUf+S0toXGPT0PtGTdIkNQ/YuzEcTsgSluLg8= X-Received: by 2002:a2e:1207:: with SMTP id t7-v6mr16731651lje.129.1531258021307; Tue, 10 Jul 2018 14:27:01 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:41c1:0:0:0:0:0 with HTTP; Tue, 10 Jul 2018 14:27:00 -0700 (PDT) In-Reply-To: <20180710204736.GU20303@art_vandelay> References: <20180618153959.2169325-1-arnd@arndb.de> <20180710204736.GU20303@art_vandelay> From: Arnd Bergmann Date: Tue, 10 Jul 2018 23:27:00 +0200 X-Google-Sender-Auth: nfKAjk8a7L9cIxkLNDRRU2SeE4s Message-ID: Subject: Re: [PATCH] drm/msm: avoid using 'timespec' To: Sean Paul Cc: Rob Clark , David Airlie , y2038 Mailman List , Jordan Crouse , linux-arm-msm@vger.kernel.org, dri-devel , freedreno@lists.freedesktop.org, Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jul 10, 2018 at 10:47 PM, Sean Paul wrote: > On Mon, Jun 18, 2018 at 05:39:42PM +0200, Arnd Bergmann wrote: >> The timespec structure and associated interfaces are deprecated and will >> be removed in the future because of the y2038 overflow. >> >> The use of ktime_to_timespec() in timeout_to_jiffies() does not >> suffer from that overflow, but is easy to avoid by just converting >> the ktime_t into jiffies directly. >> >> Signed-off-by: Arnd Bergmann >> --- >> drivers/gpu/drm/msm/msm_drv.h | 3 +-- >> 1 file changed, 1 insertion(+), 2 deletions(-) >> >> diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h >> index b2da1fbf81e0..cc8977476a41 100644 >> --- a/drivers/gpu/drm/msm/msm_drv.h >> +++ b/drivers/gpu/drm/msm/msm_drv.h >> @@ -353,8 +353,7 @@ static inline unsigned long timeout_to_jiffies(const ktime_t *timeout) >> remaining_jiffies = 0; >> } else { >> ktime_t rem = ktime_sub(*timeout, now); >> - struct timespec ts = ktime_to_timespec(rem); >> - remaining_jiffies = timespec_to_jiffies(&ts); >> + remaining_jiffies = ktime_divns(rem, NSEC_PER_SEC / HZ); > > Do you need to wrap rem in ktime_to_ns() just to be safe? The ktime_t interfaces are still defined to use an opaque type, as previously it was a union that could be a seconds/nanoseconds pair depending on the architecture. These days, ktime_t is just a 64-bit integer, so div_u64() would work just as well as ktime_divns(), but this is the documented way to do it. Arnd