Received: by 2002:ac0:aed5:0:0:0:0:0 with SMTP id t21csp3158092imb; Tue, 5 Mar 2019 02:20:13 -0800 (PST) X-Google-Smtp-Source: APXvYqyIsOwxvuwwINFSToz/Xik1DFk6FMPVUHdmC7Wj1wfqNrJd0PKgOnEMAZKiiKe58jNGhxDf X-Received: by 2002:a63:7909:: with SMTP id u9mr745410pgc.243.1551781212916; Tue, 05 Mar 2019 02:20:12 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1551781212; cv=none; d=google.com; s=arc-20160816; b=DYZDtue28UYqQHUBcbP1sMwzX1U+HB2UfX6pToniTm+AUVlm2HSCJ7Vn+Dm+UG/iy4 9/BFapy9O8kwMdee2yylToVGOgIKp/rHR3rWpdbI9Ogb8X3Ezc6RPeqCYyXj9jwewb3L y0hPatScYdOtrvKqwZxB5TBgrIfFBT9xmF442sbc8/EtJx41YUy5JdoEr0H0HpZias23 rpmCNfTrqQWFuiIF2Rd99TsHz1Z/h8rBqPous1/ITtiUt3QOiYcgwEzRSL759cLlqCRX F3WZG5uTBGVDbLEqrVfNNhgsSJ1AVX4HmntcjOExh20Hxk/pYC68V+Mhsa4XwGfDVkO6 N5CQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:references:message-id :in-reply-to:subject:cc:to:from:date; bh=1yR7dcfUFHv512yI7DejoSYzTaH1lru2DR7VOLq3dJk=; b=isVRYb+7C2ybATNRozJ4wZtyaP+Sjn+SRd8q6mH59PM6C8TI9UqMs+hlL2xqncdyZ6 HrYzcIt+DY8Fo7lps0L0Qw87z3hlsOv4NNaJZR5/TPW8yvJrKQjOA8/HRwylus2Oy+NB XnWEPhIrub/Vf8fUQ/AqCbIJflWP+s8W4wI4E8Fqz9+eBkkpioXPW5Lw2S4JSFWqn2ua lk/IqhM+JRa1RpHgvNNJmYI48ajpg06ZJNW1NYen0mzaOb+avYzzk/1PBHMHqFZYdRC/ gNiaWd/0MVSL17BlJl/S/ogZITqpcypnqZPXqKGbCAFoJfHoXGtBSiji6xsvQsfRTxUu zNQw== ARC-Authentication-Results: i=1; mx.google.com; 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 y10si8006527pll.142.2019.03.05.02.19.57; Tue, 05 Mar 2019 02:20:12 -0800 (PST) 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; 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 S1727123AbfCEJzJ (ORCPT + 99 others); Tue, 5 Mar 2019 04:55:09 -0500 Received: from kvm5.telegraphics.com.au ([98.124.60.144]:49110 "EHLO kvm5.telegraphics.com.au" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726107AbfCEJzJ (ORCPT ); Tue, 5 Mar 2019 04:55:09 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by kvm5.telegraphics.com.au (Postfix) with ESMTP id 4E16729D6F; Tue, 5 Mar 2019 04:55:05 -0500 (EST) Date: Tue, 5 Mar 2019 20:55:21 +1100 (AEDT) From: Finn Thain To: Geert Uytterhoeven cc: Andreas Schwab , Arnd Bergmann , Stephen N Chivers , Thomas Gleixner , Kars de Jong , Daniel Lezcano , Michael Schmitz , John Stultz , Linus Walleij , linux-m68k , Linux Kernel Mailing List Subject: Re: [PATCH v4 00/14] m68k: Drop arch_gettimeoffset and adopt clocksource API In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 5 Mar 2019, Geert Uytterhoeven wrote: > On Tue, Mar 5, 2019 at 7:13 AM Finn Thain wrote: > > On Sat, 1 Dec 2018, Finn Thain wrote: > > > This series removes "select ARCH_USES_GETTIMEOFFSET" from arch/m68k > > > and converts users of arch_gettimeoffset to the clocksource API. > > > Various bugs are fixed along the way. > > > > Are there any plans to merge this series, Geert? > > Has this been tested on all/most platforms? Or do you think is it safe to > apply regardless? > The amiga, atari and mac patches have been tested. The apollo, q40, sun3 and sun3x patches are safe though untested, AFAIK. I confirmed that, in qemu at least, the default jiffies clocksource will work, and the patch is trivial. That leaves bvme6000, hp300, mvme147 and mvme16x. Those have not been tested. Here are some options for those platforms: 1) Apply the patches untested (gaining new clocksources and some API modernization for m68k, while fixing old bugs and potentially introducing new bugs). 2) Do nothing until someone tests the patch series on those 4 platforms. 3) Rewrite patches such that those 4 platforms get the same treatment as apollo, q40, sun3 and sun3x (this plan was already nak'd in the hp300 case). 4) Keep using the gettimeoffset API. Redo the patch series to keep the bug fixes for the 3 platforms that can be readily tested. When the API change becomes unavoidable, remove difficult platforms. Maybe there are other possibilities? -- > Thanks! > > Gr{oetje,eeting}s, > > Geert > >