[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190826133439.GA13275@kroah.com>
Date: Mon, 26 Aug 2019 15:34:39 +0200
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: Sakari Ailus <sakari.ailus@...ux.intel.com>
Cc: linux-acpi@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/5] ACPI: Enable driver and firmware hints to control
power at probe time
On Mon, Aug 26, 2019 at 01:32:00PM +0300, Sakari Ailus wrote:
> Hi Greg,
>
> On Mon, Aug 26, 2019 at 10:43:43AM +0200, Greg Kroah-Hartman wrote:
>
> ...
>
> > > diff --git a/include/linux/device.h b/include/linux/device.h
> > > index 6717adee33f01..4bc0ea4a3201a 100644
> > > --- a/include/linux/device.h
> > > +++ b/include/linux/device.h
> > > @@ -248,6 +248,12 @@ enum probe_type {
> > > * @owner: The module owner.
> > > * @mod_name: Used for built-in modules.
> > > * @suppress_bind_attrs: Disables bind/unbind via sysfs.
> > > + * @probe_low_power: The driver supports its probe function being called while
> > > + * the device is in a low power state, independently of the
> > > + * expected behaviour on combination of a given bus and
> > > + * firmware interface etc. The driver is responsible for
> > > + * powering the device on using runtime PM in such case.
> > > + * This configuration has no effect if CONFIG_PM is disabled.
> > > * @probe_type: Type of the probe (synchronous or asynchronous) to use.
> > > * @of_match_table: The open firmware table.
> > > * @acpi_match_table: The ACPI match table.
> > > @@ -285,6 +291,7 @@ struct device_driver {
> > > const char *mod_name; /* used for built-in modules */
> > >
> > > bool suppress_bind_attrs; /* disables bind/unbind via sysfs */
> > > + bool probe_low_power;
> >
> > Ick, no, this should be a bus-specific thing to handle such messed up
> > hardware. Why polute this in the driver core?
>
> The alternative could be to make it I²C specific indeed; the vast majority
> of camera sensors are I²C devices these days.
Why is this even needed to be a bus/device attribute at all? You are
checking the firmware property in the probe function, just do the logic
there as you are, what needs to be saved to the bus's logic?
thanks,
greg k-h
Powered by blists - more mailing lists