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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6CA56EB64DC for ; Fri, 30 Jun 2023 17:37:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229496AbjF3Rhf (ORCPT ); Fri, 30 Jun 2023 13:37:35 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50440 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231857AbjF3Rhe (ORCPT ); Fri, 30 Jun 2023 13:37:34 -0400 Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1D3DB1FE4; Fri, 30 Jun 2023 10:37:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1688146653; x=1719682653; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=dm6Sl1OEMpFX+zHsfmQ4rudo1iU9mbzP0Adu+TolMaY=; b=AzzEdiWKzJJNkTEf6Dd6CzhhXMAsVItlLhScmWNvrT3QjyjKhN0Tu/7E u/6w7gKM9Rx8XHPrO0nlvIhI/51Qsuc82vr7CGEJt69eUlPY+eIfBUIw8 lr3iZRu8GHigaOnDOk8MFVXTevbNkqGM/rdhWjw/I2LGre+4/yTRnXxZo 0frZH3bHEkEVH6dpGY14qR6guFan5PtWLWnmFRLPvbwz3Lrin4qkw0BGS w0MtrUfbpAHgznV8cwFPrvYauFMPfNDZIFhoNBzFhjR/MHpQegXEzbUfy DlJuHipI1U/WZLoBxk94+g+Bx85OoaOhSYls0OxvcrxFMiBC16knBiCyG A==; X-IronPort-AV: E=McAfee;i="6600,9927,10757"; a="352272354" X-IronPort-AV: E=Sophos;i="6.01,171,1684825200"; d="scan'208";a="352272354" Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Jun 2023 10:37:29 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10757"; a="787789404" X-IronPort-AV: E=Sophos;i="6.01,171,1684825200"; d="scan'208";a="787789404" Received: from smile.fi.intel.com ([10.237.72.54]) by fmsmga004.fm.intel.com with ESMTP; 30 Jun 2023 10:37:23 -0700 Received: from andy by smile.fi.intel.com with local (Exim 4.96) (envelope-from ) id 1qFI3d-001AR3-2g; Fri, 30 Jun 2023 20:37:21 +0300 Date: Fri, 30 Jun 2023 20:37:21 +0300 From: Andy Shevchenko To: "Wu, Wentong" Cc: "Ye, Xiang" , Heikki Krogerus , Greg Kroah-Hartman , Lee Jones , Arnd Bergmann , Matthias Kaehlcke , Wolfram Sang , Tyrone Ting , Mark Brown , Linus Walleij , Bartosz Golaszewski , "linux-usb@vger.kernel.org" , "linux-i2c@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-spi@vger.kernel.org" , "linux-gpio@vger.kernel.org" , "Pandruvada, Srinivas" , "sakari.ailus@linux.intel.com" , "Wang, Zhifeng" , "Zhang, Lixu" Subject: Re: [PATCH v5 1/5] usb: Add support for Intel LJCA device Message-ID: References: <20230312190435.3568212-1-xiang.ye@intel.com> <20230312190435.3568212-2-xiang.ye@intel.com> <20230313170341.GV9667@google.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-spi@vger.kernel.org On Fri, Jun 30, 2023 at 07:40:48AM +0000, Wu, Wentong wrote: > > From: Heikki Krogerus > > Sent: Wednesday, March 15, 2023 5:10 PM > > On Tue, Mar 14, 2023 at 05:52:52PM +0200, Andy Shevchenko wrote: > > > On Tue, Mar 14, 2023 at 11:38:14PM +0800, Ye, Xiang wrote: > > > > On Tue, Mar 14, 2023 at 10:36:57AM +0200, Heikki Krogerus wrote: > > > > > On Tue, Mar 14, 2023 at 04:03:26PM +0800, Ye, Xiang wrote: ... > > > > > You don't really seem to get any benefit from MFD. Perhaps it > > > > > would be more appropriate and clear if you just registered > > > > > auxiliary devices in this driver. Check drivers/base/auxiliary.c. > > > > Yes, it should be a work. I have a question. > > > > MFD provides the ACPI binding for sub-devices through struct > > > > mfd_cell_acpi_match. But I didn't see this in drivers/base/auxiliary.c. > > > > If using auxiliary bus to implement the LJCA sub-devices, we need to > > > > do the sub-devices acpi binding manually in ljca.c. > > > > > > > > Something Like: > > > > adr = LJCA_ACPI_MATCH_GPIO > > > > adev = acpi_find_child_device(parent, adr, false); > > > > ACPI_COMPANION_SET(&pdev->dev, adev ?: parent); > > > > > > > > Is that acceptable? > > This actually doesn't work, look at the acpi_find_child_device(), it compares > the bus address specified by _ADR object, but there is no _ADR object in DSDT > for these three devices because the relationship between the parent and > children isn't bus type listed in ACPI spec, so it always return NULL. If you want to have this on ACPI enabled platform, ACPI table has to have the necessary bits. What you are describing is a BIOS bug _or_ somebody has to provide the SSDT overlay depending on the real connection of the device.. > > Looks ok to me. > > > > > Maybe you can implement this on the level of auxiliary bus. > > > > I would actually prefer that the auxiliary bus itself does not make any > > assumptions regarding the whereabouts of the fwnodes at this stage. Maybe > > later, when(if) there are more users. -- With Best Regards, Andy Shevchenko