From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 3C242C072A2 for ; Sun, 19 Nov 2023 14:34:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To: Content-Transfer-Encoding:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=wbAOew7EQhvdTMrxu7VzSwL0APRrGG2LAuJjAHyG3Ic=; b=3QHg2C/H+1NYwo2vpPC85Clogy IR+L9Oerf4BSKpCSrzo67Wg1ZiNA2mg6be19GPXj0pYiJE/StCShRVkkXs6OI56NXuLvylz/gdWDk qsu32pWL8bLN7QMIApTO+rq2ZgIXZxOZh/z+W/OJDuVSgtFMBsBqt4QAsv1Yc1/pWI09hBLl+R0GL kdGoPKrN+VDhfuvTelRJUGVYMwT3648PkVTbBvSwr5RBcz0z70qdzAsS0ZUrc7i9Dc3NrFrT8qLQp PWOEv12D8Rc3w2tvUiaZ/n6plawRBsxxq/pQc4GDnLr2wsA9EmQ5VejODdmRNyBINuRuaE2qDP3Ug /KSdw+Pw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1r4isv-00AI7O-2o; Sun, 19 Nov 2023 14:34:53 +0000 Received: from mail-oo1-f52.google.com ([209.85.161.52]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1r4isr-00AI6r-0u; Sun, 19 Nov 2023 14:34:52 +0000 Received: by mail-oo1-f52.google.com with SMTP id 006d021491bc7-5875e24c749so1995028eaf.1; Sun, 19 Nov 2023 06:34:47 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700404487; x=1701009287; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=wbAOew7EQhvdTMrxu7VzSwL0APRrGG2LAuJjAHyG3Ic=; b=OWxWeM/Xmdh8zjBX6LafI03bUWboe/0+JN+I/XFHbXTptmjXzBBbO0iiSrO9KOUKNm bf3TCwcBEYotIl2AN3eEefxTKfGOYL/PtwSJ9FLIP+qu7gBDlru1cangprqwSB5FQ6+A aiOhrvkOf24aicU5phVzLKuiPa82mkyUAAe35gPwYoq9ZcsBC+5LK0LMrrCAAbPbqmml jQ8vQFszWQfxjFfkw7C7Ha9gkRvmtu58F0e2IeAzplqpHtQQKeBeGCF4ZyWoS/pktlbf jBuSi8ytVUFPfB/wLY4Ayr/tyDZ4EfCLPbz025IeKTHR7IA0NBpycPzCz92G0SrVKN6A +Hxg== X-Gm-Message-State: AOJu0Yw+f7eBwf8fTFjC9WfZjjm7TWTPxfYr2XPXwvT8HjTmR3Di46p1 vA+Z9SVJdr0o596CzzweiA== X-Google-Smtp-Source: AGHT+IFb+T9RykUaRT49skiYcMHAWrA0Yrdg/vQdhUJcpftXjvADNdhiMeRf/RUyq/2tEoqOp1kpfg== X-Received: by 2002:a05:6820:2290:b0:57b:3b48:6f11 with SMTP id ck16-20020a056820229000b0057b3b486f11mr5163096oob.4.1700404486826; Sun, 19 Nov 2023 06:34:46 -0800 (PST) Received: from herring.priv ([2607:fb90:45e3:889f:15b4:1348:6d64:224b]) by smtp.gmail.com with ESMTPSA id w18-20020a4ae4d2000000b00581fc1af0a7sm1055669oov.28.2023.11.19.06.34.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 19 Nov 2023 06:34:45 -0800 (PST) Received: (nullmailer pid 173773 invoked by uid 1000); Sun, 19 Nov 2023 14:34:41 -0000 Date: Sun, 19 Nov 2023 08:34:41 -0600 From: Rob Herring To: Doug Anderson Cc: AngeloGioacchino Del Regno , Chen-Yu Tsai , Frank Rowand , Krzysztof Kozlowski , Conor Dooley , Matthias Brugger , Hsin-Yi Wang , Dmitry Torokhov , andriy.shevchenko@linux.intel.com, Jiri Kosina , linus.walleij@linaro.org, broonie@kernel.org, gregkh@linuxfoundation.org, hdegoede@redhat.com, james.clark@arm.com, james@equiv.tech, keescook@chromium.org, petr.tesarik.ext@huawei.com, rafael@kernel.org, tglx@linutronix.de, Jeff LaBundy , linux-input@vger.kernel.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, linux-kernel@vger.kernel.org, Johan Hovold Subject: Re: [RFC PATCH v2 0/7] of: Introduce hardware prober driver Message-ID: <20231119143441.GA157654-robh@kernel.org> References: <20231109100606.1245545-1-wenst@chromium.org> <859ac058-c50a-4eb8-99b6-3011ef4e7529@collabora.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20231119_063449_346108_5FD33E33 X-CRM114-Status: GOOD ( 47.46 ) X-BeenThere: linux-mediatek@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "Linux-mediatek" Errors-To: linux-mediatek-bounces+linux-mediatek=archiver.kernel.org@lists.infradead.org On Wed, Nov 15, 2023 at 05:13:50PM -0500, Doug Anderson wrote: > Hi, > > On Wed, Nov 15, 2023 at 4:35 PM Rob Herring wrote: > > > > On Wed, Nov 15, 2023 at 2:45 PM Doug Anderson wrote: > > > > > > Hi, > > > > > > On Wed, Nov 15, 2023 at 2:28 PM Rob Herring wrote: > > > > > > > > > So if we're searching the whole device tree for "failed-needs-probe" > > > > > then we need to figure out which devices are related to each other. If > > > > > a given board has second sources for MIPI panels, touchscreens, and > > > > > trackpads then we need to know which of the "failed-needs-probe" > > > > > devices are trackpads, which are touchscreens, and which are MIPI > > > > > panels. Do you have any suggestions for how we should do that? Maybe > > > > > it was in some other thread that I missed? I guess we could have a > > > > > board-specific table mapping (compatible + node name + reg) to a > > > > > class, but that feels awkward. > > > > > > > > Node name is supposed to correspond to device class, so why not use > > > > that (no path or unit-address.) and nothing else (well, besides > > > > "status")? > > > > > > One problem is that I could imagine having two second source trackpads > > > that both have the same i2c address. That would give them the same > > > name, right? I guess you could maybe come up with some sort of suffix > > > rule? Like > > > > > > trackpad-1@10 { > > > compatible = "elan,blah"; > > > ret = <0x10>; > > > status = "failed-needs-probe"; > > > ... > > > } > > > trackpad-2@10 { > > > compatible = "goodix,gt7375p"; > > > ret = <0x10>; > > > status = "failed-needs-probe"; > > > ... > > > } > > > > > > Then I guess the class would be "trackpad"? > > > > That issue is somewhat orthogonal because it is not following the spec. > > I'm not sure why you say it's orthogonal. The whole reason why we get > into the situation above is that we could have two devices, only one > of which is present (hence the status of "failed-needs-probe"), that > are the same type and have the same "reg" address. I just mean that defining a node name for 2 devices of the same class and at same address is separate problem from selecting which one to enable. > > Essentially the whole "failed-needs-probe" is extending the spec, > right? While extending the spec, we also need to talk about what to do > if some of the devices that we need to probe have the same class and > the same "reg". > > > > I'm not sure mixing the 2 styles of node names is a good idea. While > > not used too much, matching by node name does ignore the unit-address, > > but I'm not sure we could ignore a '-N'. > > > > I think our options are either add something to the unit-address or > > use i2c-mux binding. Adding to the unit-address is not unprecedented. > > I did that for some of the register bit level bindings where you have > > a node for different bits at the same address. The downside is > > unit-address is bus specific, so we'd have to add that for multiple > > buses. For the i2c-mux, it's perhaps a bit complex and I'm not sure > > what if anything you'd have to do to manage the mux that's not really > > there. > > Somehow it feels weird to use an i2c-mux because there's no real mux > present, right? ...so this would be a virtual (bogus) device that > doesn't really exist in hardware. Yes, shrug... > ...though I guess if the "mux" type binding is OK then maybe we just > use that as the HW prober, at least for i2c devices... Except for any other case where it's different addresses or different buses. Maybe different addresses could still use the same thing. I suppose the same class of device is unlikely to be on a different bus. An extension to the unit-address would be the simpler solution, so we should explore that first I think. Rob