Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp1103213ybb; Wed, 25 Mar 2020 15:58:03 -0700 (PDT) X-Google-Smtp-Source: ADFU+vsPi1YnTgV6XNrjYv0W0+00I2aEsBc16Z0JjQOG5izgwWpv3j2A90lLbQ/UGcr5GFlfStac X-Received: by 2002:aca:4e08:: with SMTP id c8mr4251437oib.143.1585177083443; Wed, 25 Mar 2020 15:58:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1585177083; cv=none; d=google.com; s=arc-20160816; b=oKrR9C3JQ/898rg4u5noqu1ugtc3byAVQ6kAE15V96twJcHtPy4dL4jKXzYVhOqoek n16wf12+snV9WzuC1rmH8/Jes24he93n1KLXS1mr67hDJcdU8iwVlmS2zTHhmWq6PU4A LtQIOyYawMhKEEgKnZdNgMmvYweiDwRPHcMWzZxo5QrDah413ZekpKq0uEaqvUyyd95U Kl5qEMTP6gZCd8cS+LEiRCKDX3h9xVojEzMH5rJqUYdPPnATjZ+V8F725B9ip1fuLXAL N1eB1bD5PA/nlodbhf7HuHgBDqIs0+HtF37VAdGO6tC0T/ar6hfJvbyYnpbEtBocvq1f 0kGA== 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 :in-reply-to:references:mime-version:dkim-signature; bh=9jk+TK7FwkOPEaur7O1L8OS9jETz+MSJg1VV7n1BSs4=; b=F9x2sxOMrzUlMTRbXkZy0h+kNYeTEKU31YadsYDUVEeMad9bKdVuzN8pvrWh9dcfus kux6+n11qoUSz7HBi9UacPdwCXWXdEmqsroxHZLxkLtb0NVAhT/lANP2ZQCpAuvpYbuG QfInZPJgkcB8Y9hpnBsgSsl6fgjGr3sIAUPCVnarADdhdo90lSYuzmk5MV/N8p3bwyVm B36W87nKhPfVRFmJOLfLKfhdQFc2/WDBlkIYz9MyZNur26eWWWjLM5zFntiZHTOGPRBE 33VcprrlsK2UWm3C/JzCDFjOTGRpUS1dQQLCMmwN46IO6ph/a36KmhRGU10w/4T0kSL5 FQsA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=GxwBWqTF; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id o5si200871oig.147.2020.03.25.15.57.51; Wed, 25 Mar 2020 15:58:03 -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=pass header.i=@google.com header.s=20161025 header.b=GxwBWqTF; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727456AbgCYW5g (ORCPT + 99 others); Wed, 25 Mar 2020 18:57:36 -0400 Received: from mail-oi1-f194.google.com ([209.85.167.194]:38695 "EHLO mail-oi1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727389AbgCYW5f (ORCPT ); Wed, 25 Mar 2020 18:57:35 -0400 Received: by mail-oi1-f194.google.com with SMTP id w2so3807757oic.5 for ; Wed, 25 Mar 2020 15:57:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9jk+TK7FwkOPEaur7O1L8OS9jETz+MSJg1VV7n1BSs4=; b=GxwBWqTFlxG98S9ZgY1fMAL0tAsYuZ0m+aPOljO3Xfs1s1k4IM4Z6rhrMk6Ql7XSUT 4mWApBCFTrfKp6drIjCeBZ22t4OkenZwoP1FZahVthaLuTjjCewBRL8aIev2Piwxo6C+ FHZxYBo9uKWkC4O6tYuCA1ZkX528etgAPF6vNu/Ddp4VMdv7e6BS77PDAiIiXSPpKoiL Cax5k/ZorEWQg+IbDRPMrYRocxX/yUcB0Zs31hlqT5atlkJmA6MnjPjtppi9UDN7fGdj xPMWWHj0TJTqYinpZxUGm+KtY+jLE4ETwlGGBh5xV1Wh9z8hvhHiMtJO6b6NX1wEMpOO RLnA== 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=9jk+TK7FwkOPEaur7O1L8OS9jETz+MSJg1VV7n1BSs4=; b=QJVjWiErwufRI/FfCmY+PWAMlmAAWDadxhXp2Hf2LuERNqFVls7KBblZGTaSOXr+8d sT+4fvZUw5+z+qOG49kEUpsDgzpD14eeJyQfZUAZaJFCzy8nogB/H6Fsl67jd1nPeaKq m6w6YUmMfWKCsx1q7AmieoRPntXllMJoXpc2uU/SY60t3ZTLmvjsJWCEcq0zEGvPnGxA nxmbuVFpOBCBwF8XQ3PknKyHv8YSc5Yk08FhDuNyAUTQ8LYYMhaLTNnzptNb3OZRFJ2O P10QR3aCPVnknzsoWf8rOIIkmq7nEeUmSL44SMLNKBOT/xTOLm95Ch9CjbjxxiCc4PzS sy6g== X-Gm-Message-State: ANhLgQ2KGJiFY1JMbX8iCZ4sy2WHfVGf88IKYENUouaIuhczm2fsX/IG QGP/wE2GdcUZuee9QFVaf5jdUuEI4im+WO77kktbzg== X-Received: by 2002:aca:682:: with SMTP id 124mr4297113oig.69.1585177053451; Wed, 25 Mar 2020 15:57:33 -0700 (PDT) MIME-Version: 1.0 References: <20200111052125.238212-1-saravanak@google.com> <158460766637.28353.11325960928759668587.tip-bot2@tip-bot2> <20200324175955.GA16972@arm.com> <87lfnoxg2a.fsf@nanos.tec.linutronix.de> In-Reply-To: <87lfnoxg2a.fsf@nanos.tec.linutronix.de> From: Saravana Kannan Date: Wed, 25 Mar 2020 15:56:56 -0700 Message-ID: Subject: Re: [tip: timers/core] clocksource/drivers/timer-probe: Avoid creating dead devices To: Thomas Gleixner Cc: Ionela Voinescu , LKML , Daniel Lezcano , linux-tip-commits@vger.kernel.org, x86 , liviu.dudau@arm.com, sudeep.holla@arm.com, Lorenzo Pieralisi , Jon Hunter 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 Wed, Mar 25, 2020 at 2:47 PM Thomas Gleixner wrote: > > Saravana Kannan writes: > > On Tue, Mar 24, 2020 at 11:34 AM Saravana Kannan wrote: > > I took a closer look. So two different drivers [1] [2] are saying they > > know how to handle "arm,vexpress-sysreg" and are expecting to run at > > the same time. That seems a bit unusual to me. I wonder if this is a > > violation of the device-driver model because this expectation would > > never be allowed if these device drivers were actual drivers > > registered with driver-core. But that's a discussion for another time. > > > > To fix this issue you are facing, this patch should work: > > https://lore.kernel.org/lkml/20200324195302.203115-1-saravanak@google.com/T/#u > > Sorry, that's not a fix. That's a crude hack. If device nodes are being handled by drivers without binding a driver to struct devices, then not setting OF_POPULATED is wrong. So the original patch sets it. There are also very valid reasons for allowing OF_POPULATED to be cleared by a driver as discussed here [1]. The approach of the original patch (setting the flag and letting the driver sometimes clear it) is also followed by many other frameworks like irq, clk, i2c, etc. Even ingenic-timer.c already does it for the exact same reason. So, why is the vexpress fix a crude hack? > As this is also causing trouble on tegra30-cardhu-a04 the only sane > solution is to revert it and start over with a proper solution for the > vexpress problem and a root cause analysis for the tegra. If someone can tell me which of the timer drivers are relevant for tegra30-cardhu-a04, I can help fix it. If you want to revert the original patch first before waiting for a tegra fix, that's okay by me. However, for vexpress, what do you propose I do? The driver itself is doing weird stuff with two drivers handling the exact same device. I can't just go edit the DT files because technically I don't know their hardware. Looks to me like they should have a separate and proper device for the timer and not have two drivers handle the same device. If you don't like my vexpress fix, then don't take it but ask the vexpress maintainer to fix their DT and driver maybe? But that might break the kernel compatibility with existing DT binaries on devices (yes, vexpress seems like a virtual platform, so updating DT blobs might not be hard). My vexpress fix doesn't break backwards compatibility. So, can you please accept my vexpress fix or tell us what you think is a "proper solution"? -Saravana