[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200831093109.GA4632@kunai>
Date: Mon, 31 Aug 2020 11:31:09 +0200
From: Wolfram Sang <wsa@...nel.org>
To: Sakari Ailus <sakari.ailus@...ux.intel.com>
Cc: linux-i2c@...r.kernel.org, "Rafael J. Wysocki" <rafael@...nel.org>,
linux-acpi@...r.kernel.org, Bingbu Cao <bingbu.cao@...el.com>,
linux-media@...r.kernel.org,
Chiranjeevi Rapolu <chiranjeevi.rapolu@...el.com>,
Hyungwoo Yang <hyungwoo.yang@...el.com>,
Bartosz Golaszewski <bgolaszewski@...libre.com>,
Arnd Bergmann <arnd@...db.de>, linux-kernel@...r.kernel.org,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
rajmohan.mani@...el.com, Tomasz Figa <tfiga@...omium.org>,
"Qiu, Tian Shu" <tian.shu.qiu@...el.com>
Subject: Re: [PATCH v6 1/6] i2c: Allow an ACPI driver to manage the device's
power state during probe
> This patchset is really about changing the default of ACPI powering up I²C
> devices. On OF the drivers are indeed responsible for that.
So, maybe it makes sense then to move from 'device_property_present()'
to 'acpi_dev_get_property()' or something alike? To clearly tell this
binding is expected to be used with ACPI only. Then, we can skip this
discussion now and postpone it to when someone wants to use it with DT.
Which is hopefully never. Or does this approach have drawbacks?
> My original series had a field in struct device_driver for this purpose but
> Greg K-H suggested moving it to I²C instead:
>
> <URL:https://lore.kernel.org/linux-acpi/20190826084343.GA1095@kroah.com/>
Ok, we can still factor it out in the unlikely case it needs to be done
again.
I still have the question via which tree this should go upstream?
It is probably more I2C than ACPI?
Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
Powered by blists - more mailing lists