Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Fri, 30 Jun 2023 20:37:21 +0300
From:   Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To:     "Wu, Wentong" <wentong.wu@intel.com>
Cc:     "Ye, Xiang" <xiang.ye@intel.com>,
        Heikki Krogerus <heikki.krogerus@linux.intel.com>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Lee Jones <lee@kernel.org>, Arnd Bergmann <arnd@arndb.de>,
        Matthias Kaehlcke <mka@chromium.org>,
        Wolfram Sang <wsa@kernel.org>,
        Tyrone Ting <kfting@nuvoton.com>,
        Mark Brown <broonie@kernel.org>,
        Linus Walleij <linus.walleij@linaro.org>,
        Bartosz Golaszewski <brgl@bgdev.pl>,
        "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
        "linux-i2c@vger.kernel.org" <linux-i2c@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linux-spi@vger.kernel.org" <linux-spi@vger.kernel.org>,
        "linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>,
        "Pandruvada, Srinivas" <srinivas.pandruvada@intel.com>,
        "sakari.ailus@linux.intel.com" <sakari.ailus@linux.intel.com>,
        "Wang, Zhifeng" <zhifeng.wang@intel.com>,
        "Zhang, Lixu" <lixu.zhang@intel.com>
Subject: Re: [PATCH v5 1/5] usb: Add support for Intel LJCA device
Message-ID: <ZJ8S0ds4IX4wLF9V@smile.fi.intel.com>
References: <20230312190435.3568212-1-xiang.ye@intel.com>
 <20230312190435.3568212-2-xiang.ye@intel.com>
 <20230313170341.GV9667@google.com>
 <ZBAqTqZEDz/vAwVC@ye-NUC7i7DNHE>
 <ZBAyKQwnQ8fxHRuU@kuha.fi.intel.com>
 <ZBCU5h/A2woJLtvT@ye-NUC7i7DNHE>
 <ZBCYVNmoo2EdDY90@smile.fi.intel.com>
 <ZBGLYXxpkwokgV4R@kuha.fi.intel.com>
 <DM6PR11MB43163C9D76023777B36380B98D2AA@DM6PR11MB4316.namprd11.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <DM6PR11MB43163C9D76023777B36380B98D2AA@DM6PR11MB4316.namprd11.prod.outlook.com>
Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo
Precedence: bulk

On Fri, Jun 30, 2023 at 07:40:48AM +0000, Wu, Wentong wrote:
> > From: Heikki Krogerus <heikki.krogerus@linux.intel.com>
> > 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