linux-kernel - Re: [PATCH v5 1/6] spmi: Linux driver framework for SPMI

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20140218185623.GF31116@joshc.qualcomm.com>
Date:	Tue, 18 Feb 2014 12:56:23 -0600
From:	Josh Cartwright <joshc@...eaurora.org>
To:	Felipe Balbi <balbi@...com>
Cc:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	linux-arm-msm@...r.kernel.org,
	Sagar Dharia <sdharia@...eaurora.org>,
	Gilad Avidov <gavidov@...eaurora.org>,
	Michael Bohan <mbohan@...eaurora.org>,
	Kenneth Heitke <kheitke@...eaurora.org>,
	Rob Herring <robh+dt@...nel.org>,
	Pawel Moll <pawel.moll@....com>,
	Mark Rutland <mark.rutland@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Kumar Gala <galak@...eaurora.org>, devicetree@...r.kernel.org
Subject: Re: [PATCH v5 1/6] spmi: Linux driver framework for SPMI

On Sat, Feb 15, 2014 at 05:47:48PM -0600, Felipe Balbi wrote:
> On Mon, Feb 03, 2014 at 05:05:33PM -0600, Josh Cartwright wrote:
> > +#ifdef CONFIG_PM_RUNTIME
> > +static int spmi_runtime_suspend(struct device *dev)
> > +{
> > +	struct spmi_device *sdev = to_spmi_device(dev);
> > +	int err;
> > +
> > +	err = pm_generic_runtime_suspend(dev);
> > +	if (err)
> > +		return err;
> > +
> > +	return spmi_command_sleep(sdev);
> 
> shouldn't this too calls be swapped ? I mean, some pm_runtime
> implementations could be gating clocks at the driver's
> ->runtime_suspend() callback.

Perhaps.  I had added the explicit SLEEP/WAKEUP commands to
suspend()/resume(), but now I'm thinking issuing these commands should
not be the responsibility of the core, since the semantics of the
SLEEP/ACTIVE state aren't well defined in general (each
implementation/slave defines what, if anything, these states mean).

Fortunately, there are no users yet, so this is a painless change. :)

Thanks for taking a look.

  Josh

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/