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.8 required=3.0 tests=BAYES_00, 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 06FC7C433E9 for ; Thu, 21 Jan 2021 10:51:51 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A5C3A23602 for ; Thu, 21 Jan 2021 10:51:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729867AbhAUKvi (ORCPT ); Thu, 21 Jan 2021 05:51:38 -0500 Received: from mga12.intel.com ([192.55.52.136]:47845 "EHLO mga12.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729800AbhAUKv2 (ORCPT ); Thu, 21 Jan 2021 05:51:28 -0500 IronPort-SDR: LX5cH+jqCv7lJ255IediMs20JFOIv0AJM2zREfSZfsZZ5Debv8mFAT4s+0Xdu9xMQjqhudN2Th BTNdhyTpDjOA== X-IronPort-AV: E=McAfee;i="6000,8403,9870"; a="158430067" X-IronPort-AV: E=Sophos;i="5.79,363,1602572400"; d="scan'208";a="158430067" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Jan 2021 02:49:41 -0800 IronPort-SDR: ytMdTu6t6jXggkalWWS/ai6nveuZOIW76KCY5D+jBagvuZvS7Ro/IHCNSzdRDFkHw0H3Gl1Bsp oPOgvSNikulg== X-IronPort-AV: E=Sophos;i="5.79,363,1602572400"; d="scan'208";a="356419120" Received: from lahna.fi.intel.com (HELO lahna) ([10.237.72.163]) by fmsmga008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Jan 2021 02:49:38 -0800 Received: by lahna (sSMTP sendmail emulation); Thu, 21 Jan 2021 12:49:34 +0200 Date: Thu, 21 Jan 2021 12:49:34 +0200 From: Mika Westerberg To: Kai-Heng Feng Cc: Greg Kroah-Hartman , Andy Shevchenko , "Rafael J. Wysocki" , AceLan Kao , "Rafael J. Wysocki" , Len Brown , "open list:ACPI" , open list Subject: Re: [PATCH] ACPI / device_sysfs: Use OF_MODALIAS for "compatible" modalias Message-ID: <20210121104934.GS1988617@lahna.fi.intel.com> References: <20210119081513.300938-1-kai.heng.feng@canonical.com> <20210119094159.GQ4077@smile.fi.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org On Thu, Jan 21, 2021 at 02:22:43PM +0800, Kai-Heng Feng wrote: > On Tue, Jan 19, 2021 at 6:34 PM Greg Kroah-Hartman > wrote: > > > > On Tue, Jan 19, 2021 at 11:41:59AM +0200, Andy Shevchenko wrote: > > > On Tue, Jan 19, 2021 at 04:41:48PM +0800, Kai-Heng Feng wrote: > > > > On Tue, Jan 19, 2021 at 4:27 PM Greg Kroah-Hartman > > > > wrote: > > > > > On Tue, Jan 19, 2021 at 04:15:13PM +0800, Kai-Heng Feng wrote: > > > > > > ... > > > > > > > > Who will use OF_MODALIAS and where have you documented it? > > > > > > > > After this lands in mainline, I'll modify the pull request for systemd > > > > to add a new rule for OF_MODALIAS. > > > > I'll modify the comment on the function to document the change. > > > > > > I'm wondering why to have two fixes in two places instead of fixing udev to > > > understand multiple MODALIAS= events? > > > > It's not a matter of multiple events, it's a single event with a > > key/value pair with duplicate keys and different values. > > > > What is this event with different values supposed to be doing in > > userspace? Do you want multiple invocations of `modprobe` or something > > else? > > > > Usually a "device" only has a single "signature" that modprobe uses to > > look up the correct module for. Modules can support any number of > > device signatures, but traditionally it is odd to think that a device > > itself can be supported by multiple modules, which is what you are > > saying is happening here. > > > > So what should userspace do with this, and why does a device need to > > have multiple module alias signatures? > > >From the original use case [1], I think the "compatible" modalias > should be enough. > Andy and Mika, what do you think? Can we remove the ACPI modalias for this case? Yes, I think that should work. After all we want the match to happen through the DT compatible string if the property is present, not through ACPI IDs.