Re: [U-Boot] [RFC, PATCH v2 1/4] dm: rename device struct to udevice
On Thu, May 22, 2014 at 12:43:05PM +0200, Heiko Schocher wrote: using UBI and DM together leads in compiler error, as both define a struct device, so rename struct device in include/dm/device.h to struct udevice, as we use linux code (MTD/UBI/UBIFS some USB code,...) and cannot change the linux struct device Signed-off-by: Heiko Schocher h...@denx.de Cc: Simon Glass s...@chromium.org Cc: Marek Vasut ma...@denx.de Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC, PATCH v2 1/4] dm: rename device struct to udevice
Hi Heiko, On 22 May 2014 17:56, Heiko Schocher h...@denx.de wrote: Hello Simon, Am 22.05.2014 22:34, schrieb Simon Glass: +Tom Hi Heiko, On 22 May 2014 00:43, Heiko Schocherh...@denx.de wrote: using UBI and DM together leads in compiler error, as both define a struct device, so rename struct device in include/dm/device.h to struct udevice, as we use linux code (MTD/UBI/UBIFS some USB code,...) and cannot change the linux struct device Signed-off-by: Heiko Schocherh...@denx.de Cc: Simon Glasss...@chromium.org Cc: Marek Vasutma...@denx.de I'm not 100% comfortable with this but if we really want to avoid changing kernel code that moves into U-Boot it is either this or a I vote for this, as we want to sync with newer linux code from time to time, and not changing linux code in U-Boot makes this easier. OK. '#define device ldevice' at the top of the linux code/in a header. I'm not sure which is preferable. Some USB Code (more too?) is also from linux ... Marek? What do you think? I just did not change the current situation, but if we decide to go in this direction, I can try it ... but what, if a source code file uses the U-Boot driver model and linux code? Could we fall into such a case? If Tom decides to apply this, I'd like to request that it be done soon, since it has wide impact on driver model code. Another possibility is, to move driver model specific vars into the linux struct device ... which leads in a bigger struct device for the driver model ... It sounds like Tom is happy with your patch as is, so let's go with that unless some serious issue comes up. Acked-by: Simon Glasss...@chromium.org Regards, Simon bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC,PATCH v2 1/4] dm: rename device struct to udevice
using UBI and DM together leads in compiler error, as
both define a struct device, so rename struct device
in include/dm/device.h to struct udevice, as we use
linux code (MTD/UBI/UBIFS some USB code,...) and cannot
change the linux struct device
Signed-off-by: Heiko Schocher h...@denx.de
Cc: Simon Glass s...@chromium.org
Cc: Marek Vasut ma...@denx.de
---
- changes for v2:
none
arch/sandbox/include/asm/gpio.h | 8
common/cmd_demo.c | 4 ++--
common/cmd_gpio.c | 4 ++--
doc/driver-model/README.txt | 8
drivers/core/device.c | 32
drivers/core/lists.c | 8
drivers/core/root.c | 2 +-
drivers/core/uclass.c | 31 ---
drivers/demo/demo-shape.c | 6 +++---
drivers/demo/demo-simple.c| 4 ++--
drivers/demo/demo-uclass.c| 6 +++---
drivers/gpio/gpio-uclass.c| 28 ++--
drivers/gpio/sandbox.c| 34 +-
include/asm-generic/global_data.h | 2 +-
include/asm-generic/gpio.h| 22 +++---
include/dm-demo.h | 10 +-
include/dm/device-internal.h | 16
include/dm/device.h | 20 ++--
include/dm/lists.h| 4 ++--
include/dm/root.h | 4 ++--
include/dm/test.h | 12 ++--
include/dm/uclass-internal.h | 10 +-
include/dm/uclass.h | 18 +-
test/dm/cmd_dm.c | 10 +-
test/dm/core.c| 32
test/dm/gpio.c| 2 +-
test/dm/test-driver.c | 20 ++--
test/dm/test-fdt.c| 10 +-
test/dm/test-main.c | 2 +-
test/dm/test-uclass.c | 15 ---
30 files changed, 193 insertions(+), 191 deletions(-)
diff --git a/arch/sandbox/include/asm/gpio.h b/arch/sandbox/include/asm/gpio.h
index 95b59da..8317db1 100644
--- a/arch/sandbox/include/asm/gpio.h
+++ b/arch/sandbox/include/asm/gpio.h
@@ -29,7 +29,7 @@
* @param gp GPIO number
* @return -1 on error, 0 if GPIO is low, 0 if high
*/
-int sandbox_gpio_get_value(struct device *dev, unsigned int offset);
+int sandbox_gpio_get_value(struct udevice *dev, unsigned int offset);
/**
* Set the simulated value of a GPIO (used only in sandbox test code)
@@ -38,7 +38,7 @@ int sandbox_gpio_get_value(struct device *dev, unsigned int
offset);
* @param valuevalue to set (0 for low, non-zero for high)
* @return -1 on error, 0 if ok
*/
-int sandbox_gpio_set_value(struct device *dev, unsigned int offset, int value);
+int sandbox_gpio_set_value(struct udevice *dev, unsigned int offset, int
value);
/**
* Return the simulated direction of a GPIO (used only in sandbox test code)
@@ -46,7 +46,7 @@ int sandbox_gpio_set_value(struct device *dev, unsigned int
offset, int value);
* @param gp GPIO number
* @return -1 on error, 0 if GPIO is input, 0 if output
*/
-int sandbox_gpio_get_direction(struct device *dev, unsigned int offset);
+int sandbox_gpio_get_direction(struct udevice *dev, unsigned int offset);
/**
* Set the simulated direction of a GPIO (used only in sandbox test code)
@@ -55,7 +55,7 @@ int sandbox_gpio_get_direction(struct device *dev, unsigned
int offset);
* @param output 0 to set as input, 1 to set as output
* @return -1 on error, 0 if ok
*/
-int sandbox_gpio_set_direction(struct device *dev, unsigned int offset,
+int sandbox_gpio_set_direction(struct udevice *dev, unsigned int offset,
int output);
#endif
diff --git a/common/cmd_demo.c b/common/cmd_demo.c
index a3bba7f..652c61c 100644
--- a/common/cmd_demo.c
+++ b/common/cmd_demo.c
@@ -11,7 +11,7 @@
#include dm-demo.h
#include asm/io.h
-struct device *demo_dev;
+struct udevice *demo_dev;
static int do_demo_hello(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
@@ -41,7 +41,7 @@ static int do_demo_status(cmd_tbl_t *cmdtp, int flag, int
argc,
int do_demo_list(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
{
- struct device *dev;
+ struct udevice *dev;
int i, ret;
puts(Demo uclass entries:\n);
diff --git a/common/cmd_gpio.c b/common/cmd_gpio.c
index aff0445..4634f91 100644
--- a/common/cmd_gpio.c
+++ b/common/cmd_gpio.c
@@ -30,7 +30,7 @@ static const char * const gpio_function[] = {
unknown,
};
-static void show_gpio(struct device *dev, const char *bank_name, int offset)
+static void show_gpio(struct udevice *dev, const char *bank_name, int offset)
{
struct dm_gpio_ops *ops = gpio_get_ops(dev);
char buf[80];
@@ -62,7 +62,7 @@ static void show_gpio(struct device *dev, const char
*bank_name, int offset)
Re: [U-Boot] [RFC, PATCH v2 1/4] dm: rename device struct to udevice
+Tom Hi Heiko, On 22 May 2014 00:43, Heiko Schocher h...@denx.de wrote: using UBI and DM together leads in compiler error, as both define a struct device, so rename struct device in include/dm/device.h to struct udevice, as we use linux code (MTD/UBI/UBIFS some USB code,...) and cannot change the linux struct device Signed-off-by: Heiko Schocher h...@denx.de Cc: Simon Glass s...@chromium.org Cc: Marek Vasut ma...@denx.de I'm not 100% comfortable with this but if we really want to avoid changing kernel code that moves into U-Boot it is either this or a '#define device ldevice' at the top of the linux code/in a header. I'm not sure which is preferable. If Tom decides to apply this, I'd like to request that it be done soon, since it has wide impact on driver model code. Acked-by: Simon Glass s...@chromium.org Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC, PATCH v2 1/4] dm: rename device struct to udevice
Yeah, I was just bitten by this problem as well... FWIW, you might also... Acked-by: Jon Loeliger jon.loeli...@oracle.com Thanks, jdl On Thu, May 22, 2014 at 3:34 PM, Simon Glass s...@chromium.org wrote: +Tom Hi Heiko, On 22 May 2014 00:43, Heiko Schocher h...@denx.de wrote: using UBI and DM together leads in compiler error, as both define a struct device, so rename struct device in include/dm/device.h to struct udevice, as we use linux code (MTD/UBI/UBIFS some USB code,...) and cannot change the linux struct device Signed-off-by: Heiko Schocher h...@denx.de Cc: Simon Glass s...@chromium.org Cc: Marek Vasut ma...@denx.de I'm not 100% comfortable with this but if we really want to avoid changing kernel code that moves into U-Boot it is either this or a '#define device ldevice' at the top of the linux code/in a header. I'm not sure which is preferable. If Tom decides to apply this, I'd like to request that it be done soon, since it has wide impact on driver model code. Acked-by: Simon Glass s...@chromium.org Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC, PATCH v2 1/4] dm: rename device struct to udevice
On Thu, May 22, 2014 at 10:34:33AM -1000, Simon Glass wrote: +Tom Hi Heiko, On 22 May 2014 00:43, Heiko Schocher h...@denx.de wrote: using UBI and DM together leads in compiler error, as both define a struct device, so rename struct device in include/dm/device.h to struct udevice, as we use linux code (MTD/UBI/UBIFS some USB code,...) and cannot change the linux struct device Signed-off-by: Heiko Schocher h...@denx.de Cc: Simon Glass s...@chromium.org Cc: Marek Vasut ma...@denx.de I'm not 100% comfortable with this but if we really want to avoid changing kernel code that moves into U-Boot it is either this or a '#define device ldevice' at the top of the linux code/in a header. I'm not sure which is preferable. If Tom decides to apply this, I'd like to request that it be done soon, since it has wide impact on driver model code. Acked-by: Simon Glass s...@chromium.org I like it, I'm going to grab it Monday and I'm going to kick out -rc2 on Monday as well, which should be a semi-handy branching off point too then. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC, PATCH v2 1/4] dm: rename device struct to udevice
Hi Tom, On 22 May 2014 14:43, Tom Rini tr...@ti.com wrote: On Thu, May 22, 2014 at 10:34:33AM -1000, Simon Glass wrote: +Tom Hi Heiko, On 22 May 2014 00:43, Heiko Schocher h...@denx.de wrote: using UBI and DM together leads in compiler error, as both define a struct device, so rename struct device in include/dm/device.h to struct udevice, as we use linux code (MTD/UBI/UBIFS some USB code,...) and cannot change the linux struct device Signed-off-by: Heiko Schocher h...@denx.de Cc: Simon Glass s...@chromium.org Cc: Marek Vasut ma...@denx.de I'm not 100% comfortable with this but if we really want to avoid changing kernel code that moves into U-Boot it is either this or a '#define device ldevice' at the top of the linux code/in a header. I'm not sure which is preferable. If Tom decides to apply this, I'd like to request that it be done soon, since it has wide impact on driver model code. Acked-by: Simon Glass s...@chromium.org I like it, I'm going to grab it Monday and I'm going to kick out -rc2 on Monday as well, which should be a semi-handy branching off point too then. Thanks, that sounds good. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC, PATCH v2 1/4] dm: rename device struct to udevice
Hello Simon, Am 22.05.2014 22:34, schrieb Simon Glass: +Tom Hi Heiko, On 22 May 2014 00:43, Heiko Schocherh...@denx.de wrote: using UBI and DM together leads in compiler error, as both define a struct device, so rename struct device in include/dm/device.h to struct udevice, as we use linux code (MTD/UBI/UBIFS some USB code,...) and cannot change the linux struct device Signed-off-by: Heiko Schocherh...@denx.de Cc: Simon Glasss...@chromium.org Cc: Marek Vasutma...@denx.de I'm not 100% comfortable with this but if we really want to avoid changing kernel code that moves into U-Boot it is either this or a I vote for this, as we want to sync with newer linux code from time to time, and not changing linux code in U-Boot makes this easier. '#define device ldevice' at the top of the linux code/in a header. I'm not sure which is preferable. Some USB Code (more too?) is also from linux ... Marek? What do you think? I just did not change the current situation, but if we decide to go in this direction, I can try it ... but what, if a source code file uses the U-Boot driver model and linux code? Could we fall into such a case? If Tom decides to apply this, I'd like to request that it be done soon, since it has wide impact on driver model code. Another possibility is, to move driver model specific vars into the linux struct device ... which leads in a bigger struct device for the driver model ... Acked-by: Simon Glasss...@chromium.org Regards, Simon bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
