Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp5145999pxj; Wed, 9 Jun 2021 10:09:10 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxvIhYDxvaSw2WZLyWCzm2TpDD/0zhCiRQRp33BQXtYQGIa3jD6di9lDYgNuXntR8Vr6qv+ X-Received: by 2002:a17:907:2150:: with SMTP id rk16mr899886ejb.166.1623258550351; Wed, 09 Jun 2021 10:09:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1623258550; cv=none; d=google.com; s=arc-20160816; b=RcM+8Q2xV5toQN3yjQYn+N6Q8zu0KQLGYCENFCRJfk7b5HW218b5/GdhF4nUjq8jte lCUjtIe2XE5MwQrWUsFwJgCIGJezhpOOd9q4c3gaAB3TkVjo0+a6hlEPMj9uepdtkalu TfcU5Kac8GTZpWuwBPo3nL2vIf62RM61ESs9R6oVMX+HhLLIScGG2TxiVjgZ6WLiPmD6 D7c1YQpENl0/DaqUKblHqVCFBH/perC2GpjDPnHbjaaNPAnM0rk6lYceymZ4WwbfMP5N jw6G6JViiz++Lwaikvn7jA1i0Bp90uj6LLFojgM/YHDSt6Q7jHWmmNWrN7Ovi1q7K5j+ xFqA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=147bH+C1NIC6iSRGKsUj1KC3TdY+EtaU21buZLteEB8=; b=dsObTA8R95RzMGGE6sXNtqeLz6MUlv4EGSzvICrw7JT/MePLc8hsPJ8u3J1k2Bhs4L besE/kd116LLc74z5TEMxSflYsAKecIe3tl4RWRNjTwjKEpwyLe1KNNqvWqbogQHa7FI LmERIsCjNPLn4mUP77s3iILiBNWitOWpuYh1CCZpXzh2+N0OEtoyJbkGSp7M+0xVrq2u kz2iRPd2b/SJe0lPbj9OL9lnEh5xvpc/nwGggJaAOUhfWcIAf6nrGcqWgLFwxgDdxLL4 eQUjgX8ybDz33LkqDtNbRPgiGoheK2weaOQcAsHRDFACetVK9CFqK2SGCl23+og1Jlqx L+Ew== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id c25si249530ejj.528.2021.06.09.10.08.46; Wed, 09 Jun 2021 10:09:10 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236563AbhFIHAp (ORCPT + 99 others); Wed, 9 Jun 2021 03:00:45 -0400 Received: from muru.com ([72.249.23.125]:39812 "EHLO muru.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236430AbhFIHAm (ORCPT ); Wed, 9 Jun 2021 03:00:42 -0400 Received: from atomide.com (localhost [127.0.0.1]) by muru.com (Postfix) with ESMTPS id 291FF80F5; Wed, 9 Jun 2021 06:58:56 +0000 (UTC) Date: Wed, 9 Jun 2021 09:58:44 +0300 From: Tony Lindgren To: Greg KH Cc: stable@vger.kernel.org, linux-kernel@vger.kernel.org, linux-omap@vger.kernel.org, Daniel Lezcano , Keerthy , Tero Kristo Subject: Re: [Backport for linux-5.4.y PATCH 2/4] ARM: OMAP2+: Prepare timer code to backport dra7 timer wrap errata i940 Message-ID: References: <20210602104625.6079-1-tony@atomide.com> <20210602104625.6079-2-tony@atomide.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Greg KH [210609 06:22]: > On Wed, Jun 09, 2021 at 09:13:53AM +0300, Tony Lindgren wrote: > > How about the following for the description: > > > > Upstream commit 52762fbd1c4778ac9b173624ca0faacd22ef4724 usage of > > struct dmtimer_clockevent backported to the platform timer code > > still used in linux-5.4.y stable kernel. Needed to backport upstream > > commit 3efe7a878a11c13b5297057bfc1e5639ce1241ce and commit > > 25de4ce5ed02994aea8bc111d133308f6fd62566. Earlier kernels use > > mach-omap2/timer instead of drivers/clocksource as these kernels still > > depend on legacy platform code for booting. > > Why are you combining 2 commits into one here? OK so still too confusing, how about let's just have: Upstream commit 52762fbd1c4778ac9b173624ca0faacd22ef4724 usage of struct dmtimer_clockevent backported to the platform timer code still used in linux-5.4.y stable kernel. > I do not understand what this commit really is at all still, sorry. It allows upstream fixes for drivers/clocksource/timer-ti-dm-systimer.c to be backported to the legacy platform timer code in linux-5.4.y in arch/arm/mach-omap2/timer.c. We assume a single dmtimer clockevent instance only in linux-5.4.y kernels, while for the dra7 hardware errata workaround we now need extra percpu timers configured and need struct dmtimer_clockevent. Backporting drivers/clocksource/timer-ti-dm-systimer.c directly seems risky to me as linux-5.4.y still depends on legacy platform code for booting and timers, including also the timer instances not used for clocksource and clockevent. And it would be intrusive also for the other SoCs not affected by the timer errata. Of course the best option for folks using the stable kernels is to move to the current long term kernel that already has the fixes for drivers/clocksource/timer-ti-dm-systimer.c :) > How about just providing backports for the individual commits, do not > combine them as that just is a mess. OK > > Hmm so what's the correct way to prevent automatically applying these > > into the earlier stable kernels? > > What would cause them to be automatically applied? You need to let us > know what kernel(s) they should go to. OK thanks, good to hear. Regards, Tony