Searched hist:c924dc68 (Results 1 – 6 of 6) sorted by relevance
| /openbmc/linux/sound/soc/codecs/ |
| H A D | ssm2602-i2c.c | c924dc68 Mon Feb 17 06:16:53 CST 2014 Lars-Peter Clausen <lars@metafoo.de> ASoC: ssm2602: Split SPI and I2C code into different modules
There are a few known (minor) problems with having the support code for both I2C
and SPI in the same module:
* We need to be extra careful to make sure to not build the driver into the
kernel if one of the subsystems is build as a module (Currently only I2C
can be build as a module).
* The module init path error handling is rather ugly. E.g. what should be
done if either the SPI or the I2C driver fails to register? Most drivers
that implement SPI and I2C in the same module currently fallback to
undefined behavior in that case. Splitting the the driver into two
modules, one for each bus allows the registration of the other bus driver
to continue without problems if one of them fails.
This patch splits the ssm2602 driver into 3 modules. One core module that
implements the device logic, but is independent of the bus method used. And one
module for SPI and I2C each that registers the drivers and sets up the regmap
struct for the bus.
While we are at it also cleanup the include section of the ssm2602 driver and
remove unneeded includes.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@linaro.org>
c924dc68 Mon Feb 17 06:16:53 CST 2014 Lars-Peter Clausen <lars@metafoo.de> ASoC: ssm2602: Split SPI and I2C code into different modules
There are a few known (minor) problems with having the support code for both I2C
and SPI in the same module:
* We need to be extra careful to make sure to not build the driver into the
kernel if one of the subsystems is build as a module (Currently only I2C
can be build as a module).
* The module init path error handling is rather ugly. E.g. what should be
done if either the SPI or the I2C driver fails to register? Most drivers
that implement SPI and I2C in the same module currently fallback to
undefined behavior in that case. Splitting the the driver into two
modules, one for each bus allows the registration of the other bus driver
to continue without problems if one of them fails.
This patch splits the ssm2602 driver into 3 modules. One core module that
implements the device logic, but is independent of the bus method used. And one
module for SPI and I2C each that registers the drivers and sets up the regmap
struct for the bus.
While we are at it also cleanup the include section of the ssm2602 driver and
remove unneeded includes.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@linaro.org>
|
| H A D | ssm2602-spi.c | c924dc68 Mon Feb 17 06:16:53 CST 2014 Lars-Peter Clausen <lars@metafoo.de> ASoC: ssm2602: Split SPI and I2C code into different modules
There are a few known (minor) problems with having the support code for both I2C
and SPI in the same module:
* We need to be extra careful to make sure to not build the driver into the
kernel if one of the subsystems is build as a module (Currently only I2C
can be build as a module).
* The module init path error handling is rather ugly. E.g. what should be
done if either the SPI or the I2C driver fails to register? Most drivers
that implement SPI and I2C in the same module currently fallback to
undefined behavior in that case. Splitting the the driver into two
modules, one for each bus allows the registration of the other bus driver
to continue without problems if one of them fails.
This patch splits the ssm2602 driver into 3 modules. One core module that
implements the device logic, but is independent of the bus method used. And one
module for SPI and I2C each that registers the drivers and sets up the regmap
struct for the bus.
While we are at it also cleanup the include section of the ssm2602 driver and
remove unneeded includes.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@linaro.org>
c924dc68 Mon Feb 17 06:16:53 CST 2014 Lars-Peter Clausen <lars@metafoo.de> ASoC: ssm2602: Split SPI and I2C code into different modules
There are a few known (minor) problems with having the support code for both I2C
and SPI in the same module:
* We need to be extra careful to make sure to not build the driver into the
kernel if one of the subsystems is build as a module (Currently only I2C
can be build as a module).
* The module init path error handling is rather ugly. E.g. what should be
done if either the SPI or the I2C driver fails to register? Most drivers
that implement SPI and I2C in the same module currently fallback to
undefined behavior in that case. Splitting the the driver into two
modules, one for each bus allows the registration of the other bus driver
to continue without problems if one of them fails.
This patch splits the ssm2602 driver into 3 modules. One core module that
implements the device logic, but is independent of the bus method used. And one
module for SPI and I2C each that registers the drivers and sets up the regmap
struct for the bus.
While we are at it also cleanup the include section of the ssm2602 driver and
remove unneeded includes.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@linaro.org>
|
| H A D | ssm2602.h | c924dc68 Mon Feb 17 06:16:53 CST 2014 Lars-Peter Clausen <lars@metafoo.de> ASoC: ssm2602: Split SPI and I2C code into different modules
There are a few known (minor) problems with having the support code for both I2C
and SPI in the same module:
* We need to be extra careful to make sure to not build the driver into the
kernel if one of the subsystems is build as a module (Currently only I2C
can be build as a module).
* The module init path error handling is rather ugly. E.g. what should be
done if either the SPI or the I2C driver fails to register? Most drivers
that implement SPI and I2C in the same module currently fallback to
undefined behavior in that case. Splitting the the driver into two
modules, one for each bus allows the registration of the other bus driver
to continue without problems if one of them fails.
This patch splits the ssm2602 driver into 3 modules. One core module that
implements the device logic, but is independent of the bus method used. And one
module for SPI and I2C each that registers the drivers and sets up the regmap
struct for the bus.
While we are at it also cleanup the include section of the ssm2602 driver and
remove unneeded includes.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@linaro.org>
c924dc68 Mon Feb 17 06:16:53 CST 2014 Lars-Peter Clausen <lars@metafoo.de> ASoC: ssm2602: Split SPI and I2C code into different modules
There are a few known (minor) problems with having the support code for both I2C
and SPI in the same module:
* We need to be extra careful to make sure to not build the driver into the
kernel if one of the subsystems is build as a module (Currently only I2C
can be build as a module).
* The module init path error handling is rather ugly. E.g. what should be
done if either the SPI or the I2C driver fails to register? Most drivers
that implement SPI and I2C in the same module currently fallback to
undefined behavior in that case. Splitting the the driver into two
modules, one for each bus allows the registration of the other bus driver
to continue without problems if one of them fails.
This patch splits the ssm2602 driver into 3 modules. One core module that
implements the device logic, but is independent of the bus method used. And one
module for SPI and I2C each that registers the drivers and sets up the regmap
struct for the bus.
While we are at it also cleanup the include section of the ssm2602 driver and
remove unneeded includes.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@linaro.org>
|
| H A D | ssm2602.c | c924dc68 Mon Feb 17 06:16:53 CST 2014 Lars-Peter Clausen <lars@metafoo.de> ASoC: ssm2602: Split SPI and I2C code into different modules
There are a few known (minor) problems with having the support code for both I2C
and SPI in the same module:
* We need to be extra careful to make sure to not build the driver into the
kernel if one of the subsystems is build as a module (Currently only I2C
can be build as a module).
* The module init path error handling is rather ugly. E.g. what should be
done if either the SPI or the I2C driver fails to register? Most drivers
that implement SPI and I2C in the same module currently fallback to
undefined behavior in that case. Splitting the the driver into two
modules, one for each bus allows the registration of the other bus driver
to continue without problems if one of them fails.
This patch splits the ssm2602 driver into 3 modules. One core module that
implements the device logic, but is independent of the bus method used. And one
module for SPI and I2C each that registers the drivers and sets up the regmap
struct for the bus.
While we are at it also cleanup the include section of the ssm2602 driver and
remove unneeded includes.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@linaro.org>
c924dc68 Mon Feb 17 06:16:53 CST 2014 Lars-Peter Clausen <lars@metafoo.de> ASoC: ssm2602: Split SPI and I2C code into different modules
There are a few known (minor) problems with having the support code for both I2C
and SPI in the same module:
* We need to be extra careful to make sure to not build the driver into the
kernel if one of the subsystems is build as a module (Currently only I2C
can be build as a module).
* The module init path error handling is rather ugly. E.g. what should be
done if either the SPI or the I2C driver fails to register? Most drivers
that implement SPI and I2C in the same module currently fallback to
undefined behavior in that case. Splitting the the driver into two
modules, one for each bus allows the registration of the other bus driver
to continue without problems if one of them fails.
This patch splits the ssm2602 driver into 3 modules. One core module that
implements the device logic, but is independent of the bus method used. And one
module for SPI and I2C each that registers the drivers and sets up the regmap
struct for the bus.
While we are at it also cleanup the include section of the ssm2602 driver and
remove unneeded includes.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@linaro.org>
|
| H A D | Makefile | c924dc68 Mon Feb 17 06:16:53 CST 2014 Lars-Peter Clausen <lars@metafoo.de> ASoC: ssm2602: Split SPI and I2C code into different modules
There are a few known (minor) problems with having the support code for both I2C
and SPI in the same module:
* We need to be extra careful to make sure to not build the driver into the
kernel if one of the subsystems is build as a module (Currently only I2C
can be build as a module).
* The module init path error handling is rather ugly. E.g. what should be
done if either the SPI or the I2C driver fails to register? Most drivers
that implement SPI and I2C in the same module currently fallback to
undefined behavior in that case. Splitting the the driver into two
modules, one for each bus allows the registration of the other bus driver
to continue without problems if one of them fails.
This patch splits the ssm2602 driver into 3 modules. One core module that
implements the device logic, but is independent of the bus method used. And one
module for SPI and I2C each that registers the drivers and sets up the regmap
struct for the bus.
While we are at it also cleanup the include section of the ssm2602 driver and
remove unneeded includes.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@linaro.org>
c924dc68 Mon Feb 17 06:16:53 CST 2014 Lars-Peter Clausen <lars@metafoo.de> ASoC: ssm2602: Split SPI and I2C code into different modules
There are a few known (minor) problems with having the support code for both I2C
and SPI in the same module:
* We need to be extra careful to make sure to not build the driver into the
kernel if one of the subsystems is build as a module (Currently only I2C
can be build as a module).
* The module init path error handling is rather ugly. E.g. what should be
done if either the SPI or the I2C driver fails to register? Most drivers
that implement SPI and I2C in the same module currently fallback to
undefined behavior in that case. Splitting the the driver into two
modules, one for each bus allows the registration of the other bus driver
to continue without problems if one of them fails.
This patch splits the ssm2602 driver into 3 modules. One core module that
implements the device logic, but is independent of the bus method used. And one
module for SPI and I2C each that registers the drivers and sets up the regmap
struct for the bus.
While we are at it also cleanup the include section of the ssm2602 driver and
remove unneeded includes.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@linaro.org>
|
| H A D | Kconfig | c924dc68 Mon Feb 17 06:16:53 CST 2014 Lars-Peter Clausen <lars@metafoo.de> ASoC: ssm2602: Split SPI and I2C code into different modules
There are a few known (minor) problems with having the support code for both I2C
and SPI in the same module:
* We need to be extra careful to make sure to not build the driver into the
kernel if one of the subsystems is build as a module (Currently only I2C
can be build as a module).
* The module init path error handling is rather ugly. E.g. what should be
done if either the SPI or the I2C driver fails to register? Most drivers
that implement SPI and I2C in the same module currently fallback to
undefined behavior in that case. Splitting the the driver into two
modules, one for each bus allows the registration of the other bus driver
to continue without problems if one of them fails.
This patch splits the ssm2602 driver into 3 modules. One core module that
implements the device logic, but is independent of the bus method used. And one
module for SPI and I2C each that registers the drivers and sets up the regmap
struct for the bus.
While we are at it also cleanup the include section of the ssm2602 driver and
remove unneeded includes.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@linaro.org>
c924dc68 Mon Feb 17 06:16:53 CST 2014 Lars-Peter Clausen <lars@metafoo.de> ASoC: ssm2602: Split SPI and I2C code into different modules
There are a few known (minor) problems with having the support code for both I2C
and SPI in the same module:
* We need to be extra careful to make sure to not build the driver into the
kernel if one of the subsystems is build as a module (Currently only I2C
can be build as a module).
* The module init path error handling is rather ugly. E.g. what should be
done if either the SPI or the I2C driver fails to register? Most drivers
that implement SPI and I2C in the same module currently fallback to
undefined behavior in that case. Splitting the the driver into two
modules, one for each bus allows the registration of the other bus driver
to continue without problems if one of them fails.
This patch splits the ssm2602 driver into 3 modules. One core module that
implements the device logic, but is independent of the bus method used. And one
module for SPI and I2C each that registers the drivers and sets up the regmap
struct for the bus.
While we are at it also cleanup the include section of the ssm2602 driver and
remove unneeded includes.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@linaro.org>
|