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 X-Spam-Level: X-Spam-Status: No, score=-4.2 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 62A78C6379D for ; Tue, 17 Nov 2020 22:59:49 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 0F7BE2220B for ; Tue, 17 Nov 2020 22:59:49 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="Psm5ELe2" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729498AbgKQW7e (ORCPT ); Tue, 17 Nov 2020 17:59:34 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36652 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728777AbgKQW7e (ORCPT ); Tue, 17 Nov 2020 17:59:34 -0500 Received: from mail-wm1-x342.google.com (mail-wm1-x342.google.com [IPv6:2a00:1450:4864:20::342]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B4E96C0613CF; Tue, 17 Nov 2020 14:59:33 -0800 (PST) Received: by mail-wm1-x342.google.com with SMTP id p22so416764wmg.3; Tue, 17 Nov 2020 14:59:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=zpVUFcKcpazRBQjDWd/8lZHZuRLZ1CRr09w7M6vNLNA=; b=Psm5ELe2/Nk1exiFuNIHfTQ+85NJx62LBsbVdjZoJxGWFVnyl/XJMWLmrnqOHrhAkn JbsDJGwHozno8b/l/AXRMPAqwnkPrC4zyHBOA1tg1J0DdRx62Qgvp7pkxBOKW+vrkAmd Cp8++RKgBBrsbILMks8FEZHTozYH1YKiunqxJ9P5sS7GJqS90zgkMyqj8uJbjoGCde/t QkSRVbm1TysmGSN/LH9e64R26p1oLJg2KyKmiUoioupXCdxRrYG7rfELOxUPO+5gorKc dbR8i49vPRPUgRgpOYJk289IRcpoSNqEqsyszvam84evUPNlyT8kWIqB85v2RElRBDXF Yh1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=zpVUFcKcpazRBQjDWd/8lZHZuRLZ1CRr09w7M6vNLNA=; b=pDd2KsO128c76xFPgcfL0S7wRF8wj88sIUG3WS1knCoAwT3RRnLMUaPHVdOnUZIl0b GtjvYMqFOpImOCohjL9PssZnTa3hraJXMkLfMLJ9sY6QGzSSWtI1x0E0jA+M/bj2r3sB 6ywxyai/oz4WbMoKj3g0/M8bVb7ftP4h6TZgS0FenYU+8KoHNnKvnYPsAavo2o1THhw0 pvdZAhXbNfiHv0B1zA+H/huyx5zHo2BrwX+Yw/3tc/s8RNI/KEXj3Vigtg4vPZOHSXA6 6BR5TzU6oPgDPDoZDmIB+DbGBoaImFkH4OwG39T89tTJ4hmXd8yvsQnz7b2DW6AadlPk gjqg== X-Gm-Message-State: AOAM531o27836TYINEiLYFXKdY+HQNpttAc4Cju/SL4e/dJe9nZpQ/64 68M71wMEV4XILTOhecBOFYeXFQNWNqmUwgOm X-Google-Smtp-Source: ABdhPJy8R7SrSe3icBO5IxNWCHeGer42ab9ytsz99KlGqjpXzr2TveT4+FH32GIzYTTufqQcDw8aEA== X-Received: by 2002:a1c:9ad3:: with SMTP id c202mr1232699wme.43.1605653972486; Tue, 17 Nov 2020 14:59:32 -0800 (PST) Received: from [192.168.1.211] ([2.31.225.98]) by smtp.gmail.com with ESMTPSA id f23sm286747wmb.43.2020.11.17.14.59.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 17 Nov 2020 14:59:31 -0800 (PST) Subject: Re: [RFC PATCH v3 9/9] ipu3-cio2: Add functionality allowing software_node connections to sensors on platforms designed for Windows To: Andy Shevchenko Cc: Laurent Pinchart , Linux Kernel Mailing List , Linux Media Mailing List , Linus Walleij , prabhakar.mahadev-lad.rj@bp.renesas.com, "Krogerus, Heikki" , Dmitry Torokhov , laurent.pinchart+renesas@ideasonboard.com, kieran.bingham+renesas@ideasonboard.com, Jacopo Mondi , Rob Herring , "David S. Miller" , Rasmus Villemoes , Sergey Senozhatsky , Steven Rostedt , Petr Mladek , Mauro Carvalho Chehab , Tian Shu Qiu , Bingbu Cao , Sakari Ailus , Yong Zhi , "Rafael J. Wysocki" , Greg Kroah-Hartman , Tsuchiya Yuto References: <20201029212930.GE15024@pendragon.ideasonboard.com> <20201029222215.GI4077@smile.fi.intel.com> <20201029225124.GI15024@pendragon.ideasonboard.com> <60b36af2-ad57-000b-76e4-379e1b58a3a0@gmail.com> <20201113162231.GO7524@pendragon.ideasonboard.com> <20201116085349.GA6540@pendragon.ideasonboard.com> <20201116141038.GJ6540@pendragon.ideasonboard.com> <3646e11c-a101-74e3-2eb4-7abf29937e9d@gmail.com> <20201116161636.GC4077@smile.fi.intel.com> <3976eac8-2a21-a619-1dba-85212ac4b4b1@gmail.com> From: Dan Scally Message-ID: <6dd605bb-baf7-c0d3-311a-1f4b134be406@gmail.com> Date: Tue, 17 Nov 2020 22:59:30 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org On 17/11/2020 16:42, Andy Shevchenko wrote: > On Tue, Nov 17, 2020 at 2:02 PM Dan Scally wrote: >> On 16/11/2020 16:16, Andy Shevchenko wrote: >>> On Mon, Nov 16, 2020 at 02:15:01PM +0000, Dan Scally wrote: >>>> On 16/11/2020 14:10, Laurent Pinchart wrote: >>>>> I thought we were looking for ACPI devices, not companion devices, in >>>>> order to extract information from the DSDT and store it in a software >>>>> node. I could very well be wrong though. >>>> This is correct - the code to fetch the various resources we're looking >>>> at all uses acpi_device. Whether using Andy's iterator suggestions or >>>> previous bus_for_each_dev(&acpi_bus_type...) I'm just getting the >>>> acpi_device via to_acpi_dev() and using that. >>> If you try to get an I²C ore SPI device out of pure ACPI device (with given >>> APCI _HID) you will fail. So, it's not correct. You are retrieving companion >>> devices, while they are still in the struct acpi_device. >>> >>> And don't ask me, why it's so. I wasn't designed that and didn't affect any >>> decision made there. >> Well, in terms of the actual device we're getting, I don't think we're >> fundamentally doing anything different between the methods...unless I'm >> really mistaken. >> >> >> Originally implementation was like: >> >> >> const char *supported_devices[] = { >> >> "OVTI2680", >> >> }; >> >> >> static int cio2_bridge_connect_supported_devices(void) >> >> { >> >> struct acpi_device *adev; >> >> int i; >> >> for (i = 0; i < ARRAY_SIZE(supported_devices); i++) { >> >> adev = >> acpi_dev_get_first_match_dev(supported_devices[i], NULL, -1); >> >> ... >> >> } >> >> >> and acpi_dev_get_first_match_dev() likewise just returns adev via >> to_acpi_device(dev). >> >> >> So, maybe we don't need to do the iterating over all devices with >> matching _HID at all, in which case it can be dropped, but if we're >> doing it then I can't see that it's different to the original >> implementation in terms of the struct acpi_device we're working with or >> the route taken to get it. >> >> >> Either way; ACPI maintainers asked to be CC'd on the next patchset >> anyway, so they'll see what we're doing and be able to weigh in. > Implementation wise the two approaches are quite similar for now, indeed. > I would rather go with an iterator approach for a simple reason, EFI > code already has something which may utilize iterators rather than > using their home grown solution. Alright - let's stick with that approach and leave the handling multiple sensors of same model in then. That's the current state of the code anyway, and it means it can be used elsewhere too.