Hi Masahiro, On 22 April 2018 at 22:56, Masahiro Yamada <yamada.masah...@socionext.com> wrote: > Hi Simon, > > > 2018-04-23 5:10 GMT+09:00 Simon Glass <s...@chromium.org>: >> Hi Masahiro, >> >> On 17 April 2018 at 20:38, Masahiro Yamada <yamada.masah...@socionext.com > >> wrote: >>> Currently, regmap_init_mem() takes udevice. This requires the node >>> has already been associated with a device. It prevents syscon/regmap >>> from behaving like those in Linux. >>> >>> Change the first argumenet to take the device node. >>> >>> Signed-off-by: Masahiro Yamada <yamada.masah...@socionext.com> >>> --- >>> >>> arch/arm/mach-aspeed/ast2500/sdram_ast2500.c | 2 +- >>> drivers/core/regmap.c | 11 +++++------ >>> drivers/core/syscon-uclass.c | 2 +- >>> drivers/phy/meson-gxl-usb2.c | 2 +- >>> drivers/phy/meson-gxl-usb3.c | 2 +- >>> drivers/ram/rockchip/dmc-rk3368.c | 2 +- >>> drivers/ram/rockchip/sdram_rk3188.c | 2 +- >>> drivers/ram/rockchip/sdram_rk322x.c | 2 +- >>> drivers/ram/rockchip/sdram_rk3288.c | 2 +- >>> drivers/ram/rockchip/sdram_rk3399.c | 2 +- >>> drivers/ram/stm32mp1/stm32mp1_ram.c | 2 +- >>> drivers/reset/reset-meson.c | 2 +- >>> include/regmap.h | 4 ++-- >>> 13 files changed, 18 insertions(+), 19 deletions(-) >> >> Can you please add a simple test for regmap on sandbox? >> > > No. > > Please stop this boiler-plate response. > > Simple tests for regmap already exist in test/dm/regmap.c > > regmap_init_mem() is not a new function, and it is tested > through other function tests.
Can you please point to that? I don't see anything for sandbox. > > You block patches several times before > by making the contributors say "Sorry, I am busy". > > > I am really busy, but I need to fix the misimplementation > of syscon for Socionext drivers. > > Why should I be annoyed by additional work > to fix the problem? Because otherwise I have no idea if the code works, no one will be able to change it later without potentially breaking it, etc. If people get into the habit of writing a little test at the same time, it takes very little extra effort. I have pour an ENORMOUS amount of time into making testing in U-Boot better, as has Stephen Warren. We need to continue the effort. I'm sorry that this adds a little more time to the patch submission process, but we gain a lot of benefits. Look at all the times we have tried to fix address translation in U-Boot, or FIT behaviour, when we don't have tests or even a clear definition of the correct behaviour. So please try to understand my point of view here. This is not just about your patch, it is about the future of U-Boot for future users and contributors. Regards, Simon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot