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=-3.6 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,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED 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 DDFAEC63697 for ; Fri, 13 Nov 2020 19:45:21 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 8C2C022245 for ; Fri, 13 Nov 2020 19:45:21 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="Rz2XI7G1" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726286AbgKMTpT (ORCPT ); Fri, 13 Nov 2020 14:45:19 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52514 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726087AbgKMTpS (ORCPT ); Fri, 13 Nov 2020 14:45:18 -0500 Received: from mail-pf1-x442.google.com (mail-pf1-x442.google.com [IPv6:2607:f8b0:4864:20::442]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3552EC0613D1; Fri, 13 Nov 2020 11:45:17 -0800 (PST) Received: by mail-pf1-x442.google.com with SMTP id 10so8502367pfp.5; Fri, 13 Nov 2020 11:45:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hkEByu5NaYXbpu/E/2DlifVZ1EfrvqJGLXUDnNk39PE=; b=Rz2XI7G1+m0ld1eHrQzMuvdwM7JVktfgJBRZssdlP431IvCpwop0fPtidv4cA16zG1 YW8m70eOTbY+DnBRInp5zDhMcPh78P6fjTVUXz/oktLPqDuRRs9FGhmwPyGVf68HiLgi PQN3dSIQ4IkboU607MzK7nyKEi26RJCB1p2Fp0Ye4Ai3AgI3kqYVlYNEfDh5hbIYXTHH 2CCCaRW9ch9IAubYq5WMe29Lw8AFt3/QNQz75EvL2WQD+a8JyPahW/0DwNL0nktJsc+t aQ2MdflYcYDCWAVPa6o/N0SmaBRPo4L+L8K/kwQBCiI6/RmnK5BQasNCO3ELEhwNUhCX fKXg== 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=hkEByu5NaYXbpu/E/2DlifVZ1EfrvqJGLXUDnNk39PE=; b=Hjc5CYtLUr8nLc6s5UEjR4wyLrKKLT7MvVyB5buku5wH3I/tOnQhxUI93SaO5nSFQN B5+vbuBkJ8gxv4TrNh3ocs63oQfFliXgQTl3E/qtjfNvQH/q7Egydjw6pkBN2Ky0bnH5 uTOkgfooz8/IwokDqvL2wuU7WwIR4ASNYS1Y8cRfi/X3OW+5kaZrJ2IExkJLGXliGNIa AyHmfeqstyDOBDFPMW4vvD4tlrcVV210cPhA2Q3Hd2Cz3dY/5p/0OgeHfqJNson2ZY52 VsgRgve6l+5tgtsymCZFYOcNSmOeDe4LSSBXXOaT7vWSw1X6R1boPXTKcWJlUX8mnQyq KnOA== X-Gm-Message-State: AOAM530+mG69lSxDphjpLZF1kcIm2Hzr52FdDYY76FBX0Tp6CRyj/6wK pZTOdZqpH2JCctwEo1PjprgBA8PgaeIcSEEqXgk= X-Google-Smtp-Source: ABdhPJxJMB475AzgJKmkxrj9hbti9Hm2ImgxJYxsQnBlDjERd6f7NR4NyARgrTSN+GjQAPKiOlye2zfCxR0Tb6QHJB4= X-Received: by 2002:a63:3e05:: with SMTP id l5mr3160904pga.74.1605296716678; Fri, 13 Nov 2020 11:45:16 -0800 (PST) MIME-Version: 1.0 References: <20201024012411.GT5979@pendragon.ideasonboard.com> <20201024093702.GA3939@pendragon.ideasonboard.com> <20201026161050.GQ4077@smile.fi.intel.com> <20201029201918.GD15024@pendragon.ideasonboard.com> <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> In-Reply-To: <20201113162231.GO7524@pendragon.ideasonboard.com> From: Andy Shevchenko Date: Fri, 13 Nov 2020 21:45:00 +0200 Message-ID: Subject: Re: [RFC PATCH v3 9/9] ipu3-cio2: Add functionality allowing software_node connections to sensors on platforms designed for Windows To: Laurent Pinchart Cc: Dan Scally , 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 Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org On Fri, Nov 13, 2020 at 6:22 PM Laurent Pinchart wrote: > On Fri, Nov 13, 2020 at 10:02:30AM +0000, Dan Scally wrote: > > On 29/10/2020 22:51, Laurent Pinchart wrote: > > > On Fri, Oct 30, 2020 at 12:22:15AM +0200, Andy Shevchenko wrote: > > >> On Thu, Oct 29, 2020 at 11:29:30PM +0200, Laurent Pinchart wrote: ... > > >> In this case we probably need something like > > >> > > >> struct acpi_device * > > >> acpi_dev_get_next_match_dev(struct acpi_device *adev, > > >> const char *hid, const char *uid, s64 hrv) > > >> { > > >> struct device *start = adev ? &adev->dev : NULL; > > >> ... > > >> dev = bus_find_device(&acpi_bus_type, start, &match, acpi_dev_match_cb); > > >> ... > > >> } > > >> > > >> in drivers/acpi/utils.c and > > >> > > >> static inline struct acpi_device * > > >> acpi_dev_get_first_match_dev(const char *hid, const char *uid, s64 hrv) > > >> { > > >> return acpi_dev_get_next_match_dev(NULL, hid, uid, hrv); > > >> } > > >> > > >> in include/linux/acpi.h. > > >> > > >> Then we may add > > >> > > >> #define for_each_acpi_dev_match(adev, hid, uid, hrv) \ > > >> for (adev = acpi_dev_get_first_match_dev(hid, uid, hrv); \ > > >> adev; \ > > >> adev = acpi_dev_get_next_match_dev(adev, hid, uid, hrv)) > > > > > > What the cio2-bridge code needs is indeed > > > > > > for each hid in supported hids: > > > for each acpi device that is compatible with hid: > > > ... > > > > > > which could also be expressed as > > > > > > for each acpi device: > > > if acpi device hid is in supported hids: > > > ... > > > > > > I don't mind either option, I'll happily follow the preference of the > > > ACPI maintainers. > > > > Does this need raising elsewhere then? The original idea of just > > bus_for_each_dev(&acpi_bus_type...) I have now tested and it works fine, > > but it does mean that I need to export acpi_bus_type (currently that > > symbol's not available)...that seems much simpler to me but I'm not sure > > whether that's something to avoid, and if so whether Andy's approach is > > better. > > > > Thoughts? > > I like simple options :-) A patch to export acpi_bus_type, with enough > context in the commit message (and in the cover latter of the series), > should be enough to provide all the information the ACPI maintainers > need to decide which option is best. With a bit of luck that patch will > be considered the best option and no extra work will be needed. The problem with ACPI bus is that it is not as simple as other buses, i.e. it may have purely ACPI devices along with *companion* devices, which are usually represented by platform bus. On top of that for several ACPI devices there can be one physical node and it will be not so clear what you are exactly looking for by traversing acpi_bus_type. I believe it's hidden on purpose. -- With Best Regards, Andy Shevchenko