/*****************************************************************************
* xenbus.h
*
* Xenbus protocol details.
*
* Copyright (C) 2005 XenSource Ltd.
*/
#ifndef _XEN_PUBLIC_IO_XENBUS_H
#define _XEN_PUBLIC_IO_XENBUS_H
/* The state of either end of the Xenbus, i.e. the current communication
status of initialisation across the bus. States here imply nothing about
the state of the connection between the driver and the kernel's device
layers. */
enum xenbus_state
{
XenbusStateUnknown = 0,
XenbusStateInitialising = 1,
XenbusStateInitWait = 2, /* Finished early
initialisation, but waiting
for information from the peer
or hotplug scripts. */
XenbusStateInitialised = 3, /* Initialised and waiting for a
connection from the peer. */
XenbusStateConnected = 4,
XenbusStateClosing = 5, /* The device is being closed
due to an error or an unplug
event. */
XenbusStateClosed = 6,
/*
* Reconfiguring: The device is being reconfigured.
*/
XenbusStateReconfiguring = 7,
XenbusStateReconfigured = 8
};
#endif /* _XEN_PUBLIC_IO_XENBUS_H */
/*
* Local variables:
* c-file-style: "linux"
* indent-tabs-mode: t
* c-indent-level: 8
* c-basic-offset: 8
* tab-width: 8
* End:
*/
ack
regulator: gpio: properly check return value of of_get_named_gpio
The function of_get_named_gpio() could return -ENOENT, -EPROBE_DEFER
-EINVAL and so on. Currently, for the optional property "enable-gpio",
we only check -EPROBE_DEFER, this is not enough since there may be
misconfigured "enable-gpio" in the DTB, of_get_named_gpio() will return
-EINVAL in this case, we should return immediately here. And for the
optional property "gpios", we didn't check the return value, the driver
will continue to the point where gpio_request_array() is called, it
doesn't make sense to continue if we got -EPROBE_DEFER or -EINVAL here.
This patch tries to address these two issues by properly checking the
return value of of_get_named_gpio.
Signed-off-by: Jisheng Zhang <jszhang@marvell.com>
Signed-off-by: Mark Brown <broonie@kernel.org>