Re: [PATCH/RFC 1/2] simple SPI framework

[Pavel Machek <pavel@ucw.cz>]

Hi!

> >+#ifdef	CONFIG_PM
> >+
> >+/* Suspend/resume in "struct device_driver" don't really need that
> >+ * strange third parameter, so we just make it a constant and expect
> >+ * SPI drivers to ignore it just like most platform drivers do.
> >+ *
> >
> So you just ignored my letter on that subject :(
> The fact that you don't need it doesn't mean that other people won't.
> The fact that there's no clean way to suspend USB doesn't mean that 
> there shouldn't be one for SPI.

The third parameter really must die. Just because you *can* use it
does not mean you should.

> >+ * NOTE:  the suspend() method for an spi_master controller driver
> >+ * should verify that all its child devices are marked as suspended;
> >+ * suspend requests delivered through sysfs power/state files don't
> >+ * enforce such constraints.
> >+ */
> >+static int spi_suspend(struct device *dev, pm_message_t message)
> >+{
> >+	int	value;
> >+
> >+	if (!dev->driver || !dev->driver->suspend)
> >+		return 0;
> >+
> >+	/* suspend will stop irqs and dma; no more i/o */
> >+	value = dev->driver->suspend(dev, message, SUSPEND_POWER_DOWN);
> > 
> >
> So driver->suspend is going to be called 3 timer with SUSPEND_POWER_DOWN 
> parameter, right?
> I'm afraid that won't work :(

No, it is going to be called once. You perhaps should not pass it
"SUSPEND_POWER_DOWN" but something else; but drivers should really
ignore it. [You are calling it for normal suspend, right? Not just
before power down.]

> Especially in our case, where we *do need* preparation steps that are 
> taken in *normal* suspend sequence - i. e. we need to set up the wakeup 
> credentials for the *SPI* since the wakeup's gonna happen from a call 
> incoming through the network module residing on the SPI bus!

You should not need more than one phase.
								Pavel
-- 
if you have sharp zaurus hardware you don't need... you know my address
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/