Re: [U-Boot] [PATCH v2 1/2] at91: video: Support driver-model for the HLCD driver

2017-03-12 Thread Marek Vasut 
On 03/01/2017 10:25 AM, Songjun Wu wrote:
> Add driver-model support to this driver.
> 
> Signed-off-by: Songjun Wu 
> ---
> 
> Changes in v2:
> - Due to the peripheral clock driver improvement, remove
>   the unneccessary clock calling.
> 
>  board/atmel/at91sam9n12ek/at91sam9n12ek.c   |   2 +
>  board/atmel/at91sam9x5ek/at91sam9x5ek.c |   2 +
>  board/atmel/sama5d2_xplained/sama5d2_xplained.c |   2 +
>  board/atmel/sama5d3xek/sama5d3xek.c |   2 +
>  board/atmel/sama5d4_xplained/sama5d4_xplained.c |   2 +
>  board/atmel/sama5d4ek/sama5d4ek.c   |   2 +
>  drivers/video/Kconfig   |   9 +
>  drivers/video/atmel_hlcdfb.c| 314 
> +++-

Split the driver from board changes.

>  include/configs/at91sam9n12ek.h |   4 +
>  include/configs/at91sam9x5ek.h  |   4 +
>  include/configs/ma5d4evk.h  |   4 +
>  include/configs/sama5d2_xplained.h  |   4 +
>  include/configs/sama5d3xek.h|   4 +
>  include/configs/sama5d4_xplained.h  |   4 +
>  include/configs/sama5d4ek.h |   4 +
>  15 files changed, 360 insertions(+), 3 deletions(-)

[...]

> diff --git a/drivers/video/atmel_hlcdfb.c b/drivers/video/atmel_hlcdfb.c
> index 960b474b76..0bcb92b2cf 100644
> --- a/drivers/video/atmel_hlcdfb.c
> +++ b/drivers/video/atmel_hlcdfb.c
> @@ -10,13 +10,24 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
> +#include 
>  #include 
> +#include 
>  #include 
>  
>  #if defined(CONFIG_LCD_LOGO)
>  #include 
>  #endif
>  
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +#define lcdc_readl(reg)  __raw_readl((reg))
> +#define lcdc_writel(reg, val)__raw_writel((val), (reg))

Really ? Do we REALLY need more new accessors ? Just use readl/writel ...

> +#ifndef CONFIG_DM_VIDEO
> +
>  /* configurable parameters */
>  #define ATMEL_LCDC_CVAL_DEFAULT  0xc8
>  #define ATMEL_LCDC_DMA_BURST_LEN 8
> @@ -26,9 +37,6 @@
>  
>  #define ATMEL_LCDC_FIFO_SIZE 512
>  
> -#define lcdc_readl(reg)  __raw_readl((reg))
> -#define lcdc_writel(reg, val)__raw_writel((val), (reg))
> -
>  /*
>   * the CLUT register map as following
>   * RCLUT(24 ~ 16), GCLUT(15 ~ 8), BCLUT(7 ~ 0)
> @@ -218,3 +226,303 @@ void lcd_ctrl_init(void *lcdbase)
>   /* Enable flushing if we enabled dcache */
>   lcd_set_flush_dcache(1);
>  }
> +
> +#else
> +
> +enum {
> + LCD_MAX_WIDTH   = 1024,
> + LCD_MAX_HEIGHT  = 768,
> + LCD_MAX_LOG2_BPP= VIDEO_BPP16,
> +};
> +
> +struct atmel_hlcdc_priv {
> + struct atmel_hlcd_regs *regs;
> + struct display_timing timing;
> + unsigned int vl_bpix;
> + unsigned int guard_time;
> + ulong clk_rate;
> +};
> +
> +static int at91_hlcdc_enable_clk(struct udevice *dev)
> +{
> + struct atmel_hlcdc_priv *priv = dev_get_priv(dev);
> + struct clk clk;
> + ulong clk_rate;
> + int ret;
> +
> + ret = clk_get_by_index(dev, 0, );
> + if (ret)
> + return -EINVAL;
> +
> + ret = clk_enable();
> + if (ret)
> + return ret;
> +
> + clk_rate = clk_get_rate();
> + if (!clk_rate)
> + return -ENODEV;

Clock are still enabled if you fail here ...

> + priv->clk_rate = clk_rate;
> +
> + clk_free();
> +
> + return 0;
> +}
> +
> +static void atmel_hlcdc_init(struct udevice *dev)
> +{
> + struct video_uc_platdata *uc_plat = dev_get_uclass_platdata(dev);
> + struct atmel_hlcdc_priv *priv = dev_get_priv(dev);
> + struct atmel_hlcd_regs *regs = priv->regs;
> + struct display_timing *timing = >timing;
> + struct lcd_dma_desc *desc;
> + unsigned long value, vl_clk_pol;
> +
> + /* Disable DISP signal */
> + lcdc_writel(>lcdc_lcddis, LCDC_LCDDIS_DISPDIS);
> + while ((lcdc_readl(>lcdc_lcdsr) & LCDC_LCDSR_DISPSTS))
> + udelay(1);

wait_for_bit(), fix globally ... and don't use unbounded loops ...

> + /* Disable synchronization */
> + lcdc_writel(>lcdc_lcddis, LCDC_LCDDIS_SYNCDIS);
> + while ((lcdc_readl(>lcdc_lcdsr) & LCDC_LCDSR_LCDSTS))
> + udelay(1);
> + /* Disable pixel clock */
> + lcdc_writel(>lcdc_lcddis, LCDC_LCDDIS_CLKDIS);
> + while ((lcdc_readl(>lcdc_lcdsr) & LCDC_LCDSR_CLKSTS))
> + udelay(1);
> + /* Disable PWM */
> + lcdc_writel(>lcdc_lcddis, LCDC_LCDDIS_PWMDIS);
> + while ((lcdc_readl(>lcdc_lcdsr) & LCDC_LCDSR_PWMSTS))
> + udelay(1);
> +
> + /* Set pixel clock */
> + value = priv->clk_rate / timing->pixelclock.typ;
> + if (priv->clk_rate % timing->pixelclock.typ)
> + value++;
> +
> + vl_clk_pol = 0;
> + if (timing->flags & DISPLAY_FLAGS_PIXDATA_NEGEDGE)
> + vl_clk_pol = LCDC_LCDCFG0_CLKPOL;
> +
> + if (value < 1) {

I guess I'd just introduce a variable and ORR it

Re: [U-Boot] [PATCH 2/2] configs: am43xx_hs_evm: Add USB Host boot mode support

2017-03-12 Thread Lokesh Vutla 


On Saturday 11 March 2017 03:32 AM, Andrew F. Davis wrote:
> Enable SPL_USB_HOST_SUPPORT in the default defconfig to allow
> booting from USB peripherals. Unlike the non-HS boards, we
> already load SPL to a 0x4030_+ address, so no other changes
> are needed.
> 
> Signed-off-by: Andrew F. Davis 

Reviewed-by: Lokesh Vutla 

Thanks and regards,
Lokesh
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] ti_armv7_common: env: Use args_mmc in FIT loading path

2017-03-12 Thread Lokesh Vutla 


On Saturday 11 March 2017 03:23 AM, Andrew F. Davis wrote:
> The env command 'args_fit' does not define a root path, this forces us to
> embed the rootfs into the FIT image. FIT images do not need to contain a
> rootfs, when they do not the kernel will fall-back to the kernel argument
> 'root', if this is not defined the kernel will not boot. It is safe to
> add this as when we do have the rootfs in FIT this argument is ignored.
> As 'loadfit' is only called from the MMC boot path, use 'args_mmc' to
> correctly populate 'bootargs'.
> 
> Signed-off-by: Andrew F. Davis 

Reviewed-by: Lokesh Vutla 

Thanks and regards,
Lokesh
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] configs: am43xx_evm: Merge in usbhost defconfig

2017-03-12 Thread Lokesh Vutla 


On Saturday 11 March 2017 03:32 AM, Andrew F. Davis wrote:
> I was once again going to try to sync the mode specific defconfigs
> with the main AM43xx defconfig when I decided it may make more
> sense to merge in USB host boot support in to the main defconfig.
> 
> The reason we had separate defconfigs before was that SPL needs
> to be placed in OCMC SRAM by the ROM when booting from USB as
> it uses DMA and ARM internal SRAM space is not externally
> accessible. All this means is we need to have our SPL load address
> be greater than 0x4030_ when USB booting. For other cases
> we use 0x402F_, this gives us an extra 64kB of space in addition
> to the 256kB of OCMC RAM, as our SPL is not even half this size
> currently this is not strictly needed.
> 
> Make all boot modes load to 0x4030_+, add SPL USB host
> boot support to the main am43xx defconfig, and then remove

This breaks all the supported peripheral boot modes. Have you tested
UART/ethernet boot with this patch?

I specifically wanted a separate defconfig for usb_host as it is a
special case and rest of the boot modes can be supported using a single
defconfig. If you don't like this approach, please create separate
defconfigs for peripheral and memory boot modes.

Thanks and regards,
Lokesh
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] cmd: nand: Make the NAND options default to NAND_SUNXI

2017-03-12 Thread André Przywara 
On 03/03/17 14:32, Maxime Ripard wrote:
> If we depend on the ARCH_SUNXI configuration option, the boards that do not
> have NAND support enabled (with the associated options) will not compile
> anymore.
> 
> Depend on the NAND driver configuration option to make sure that is not the
> case.


> Reported-by: Chen-Yu Tsai 
> Signed-off-by: Maxime Ripard 

As I came up with an identical patch today to fix sunxi/master:

Reviewed-by: Andre Przywara 


So this situation is a bit unfortunate: The sunxi/master branch was
updated apparently before even compile-testing it for more than one
sunxi board (it is broken for every sunxi board except Chip Pro at the
moment: buildman says 105/106). And even after reports and the
corresponding fixes appeared (thanks Chen-Yu and Maxime!) the branch is
_still_ broken as of today (10 days after the fix was posted).

So can we please have both
a) a better quality assurance before merging patches into this custodian
branch and
b) quicker merging of fixes?
To my understanding u-boot-sunxi should be always a good and working
candidate for anyone interested in Allwinner boards.

For a) it would already help to just simply build test sunxi:
$ tools/buildman/buildman sunxi
but probably extend this to cover at least all ARM boards.

Cheers,
Andre

> ---
>  cmd/Kconfig | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/cmd/Kconfig b/cmd/Kconfig
> index 585a00c31f4e..91e3d6a46769 100644
> --- a/cmd/Kconfig
> +++ b/cmd/Kconfig
> @@ -438,7 +438,7 @@ config CMD_MMC
>  
>  config CMD_NAND
>   bool "nand"
> - default y if ARCH_SUNXI
> + default y if NAND_SUNXI
>   help
> NAND support.
>  
> @@ -847,7 +847,7 @@ config CMD_UBI
>   tristate "Enable UBI - Unsorted block images commands"
>   select CRC32
>   select MTD_UBI
> - default y if ARCH_SUNXI
> + default y if NAND_SUNXI
>   help
> UBI is a software layer above MTD layer which admits use of LVM-like
> logical volumes on top of MTD devices, hides some complexities of
> @@ -862,7 +862,7 @@ config CMD_UBIFS
>   select CRC32
>   select RBTREE if ARCH_SUNXI
>   select LZO if ARCH_SUNXI
> - default y if ARCH_SUNXI
> + default y if NAND_SUNXI
>   help
> UBIFS is a file system for flash devices which works on top of UBI.
>  
> 

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v1] x86: Remove unused option

2017-03-12 Thread Simon Glass 
On 6 March 2017 at 04:51, Andy Shevchenko
 wrote:
> There is option which is not used:
> CONFIG_ZBOOT_32
>
> Remove it from default x86 config and from whitelist.
>
> Signed-off-by: Andy Shevchenko 
> ---
>  include/configs/x86-common.h | 1 -
>  scripts/config_whitelist.txt | 1 -
>  2 files changed, 2 deletions(-)

Reviewed-by: Simon Glass 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v1 2/2] misc: Introduce minimal PMU driver for Intel MID platforms

2017-03-12 Thread Simon Glass 
Hi Andy,

On 5 March 2017 at 12:17, Andy Shevchenko
 wrote:
> This simple PMU driver enables access to MMC controllers during probe
> so tangier_sdhci can probe and be useful.
>
> In the future it might be expanded to cover other Intel MID platforms,
> that's why it's called intel_mid_pmu.c.
>
> Signed-off-by: Felipe Balbi 
> Signed-off-by: Andy Shevchenko 

Please consider my comments on the previous driver to apply to this one also.

One more thing - you cannot call device_probe() from the bind
function. That is breaking the rules.

Instead, it should be found by the first user, perhaps using syscon or
perhaps with a device_get_...() function, and that will automatically
probe it.

Regards,
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v1] env_mmc: configure environment offsets via device tree

2017-03-12 Thread Simon Glass 
Hi Igor,

On 5 March 2017 at 01:39, Igor Grinberg  wrote:
> Hi Simon,
>
> On 03/03/17 06:53, Simon Glass wrote:
>> Hi Igor,
>>
>> On 22 February 2017 at 00:35, Igor Grinberg  wrote:
>>> Hi Philipp, Simon,
>>>
>>> On 02/22/17 05:59, Simon Glass wrote:
 Hi,

 On 20 February 2017 at 02:18, Dr. Philipp Tomsich
  wrote:
>
> On 20 Feb 2017, at 08:22, Igor Grinberg  wrote:
>
> That sounds too odd...
> DT's purpose is to describe the h/w... and that does not look so...
> We also, have a dt file name in the environment, so this creates will 
> create
> a chicken and an egg problem…
>
>
> I don’t really follow… as far as I knew the DT name would have to come
> from some other source anyway, as the device containing the env might
> only be described through the device tree (e.g. mmc0).
>
>
> Why? U-Boot can live pretty well w/o DT.
>
>
> If U-Boot runs without DT, then nothing will/should change about how the
> setting
> is retrieved from CONFIG_ENV_OFFSET.
>>>
>>> ok.
>>>
>
> The platform that motivated this change is ARCH_SUNXI, which does not use
> per-board defines but aims to have one generic bootloader per-SoC.
>>>
>>> Well, after a ten year experience with boars and different SoC vendors,
>>> I don't think it is possible...
>>> Unless all boards are copies of their respective reference design...
>>>
>
> I really don't think we should go that direction. DT is not meant to 
> provide
> a solution to all your problems...
>
>
> I don’t see how this is different from other entries in chosen and config 
> as
> of today:
> common/autoboot.c allows an override through /config/bootdelay
> common/board_r.c uses /config/load-environment
> common/cli.c can pull in /config/bootcmd
> drivers/serial/serial-uclass.c uses /chosen/stdout-path
>
> In fact, it is the absence of this mechanism that is causing problems 
> today:
> CONFIG_ENV_OFFSET is not configurable through Kconfig, so we would
> need board-specific defines (e.g. CONFIG_SUNXI_BOARD_LYNX) and
> matching #ifdef primitives in a shared header (sunxi-common.h in our 
> case).
>
>
> Right. Exactly, I think we should move the CONFIG_ENV_OFFSET to Kconfig.
> And that will solve the problem.
>
>
> Doing this would still get into the way of architectures that want to 
> build
> a single
> ‘universal’ bootloader for their SoC: the ENV_OFFSET may not be the same
> across all board and vendor configurations. This can easily be handled 
> with
> the
> (optional) prop in the DT, but not with the compile-time ENV_OFFSET.
>>>
>>> I think Kconfig would be enough for this, but please try your approach.
>>> The 'universal' thing will probably work if you don't have too many boards 
>>> and
>>> they don't differ too much from each other...
>>>
>
> If we decide to this, I’d at least like to introduce the function call to
> (the weak
> function) mmc_get_env_addr(…), so we can override this in the board code.
>>>
>>> That is how it works today:
>>> include/environment.h:185:extern int mmc_get_env_addr(struct mmc *mmc, int 
>>> copy, u32 *env_addr);
>>>
>
> So putting this in the DT is the best (and least intrusive) option
> available.
>
>
> Ok. I see your point now. Yet I think we should keep the DT to its 
> purpose -
> which
> is to describe the h/w (and not the s/w placement layout).

 Well actually we put things like flash map in there and the
 environment position seems like a very good thing to have there.
>>>
>>> Well, I thought so too... But I had a discussion with kernel people
>>> some time ago and they discourage this approach and would not like to
>>> have the flash mapping in the DT.
>>
>> I'm sorry to hear that, but it doesn't change the fact that it is very
>> useful for dealing with hardware-specific differences between models.
>
> According to kernel guys, these are not h/w specific, but rather device
> specific... and it actually makes sense - on the same h/w design different
> applications can use different flash mapping - just like the block devices.

Really? That sounds like a pretty esoteric case to me.

In my experience the flash mapping is normally fixed at production
time and there may be parts that are write-protected, e.g. with a
hardware switch. The flash map generally needs to be understood by
both firmware and kernel. It is as much a feature of the hardware as
which serial console to use.

>
>>
>> Building the same software multiple times with different #ifdefs is
>> often painful. Using a DT to handle these minor differences reduces
>> the number of build combinations and simplifies testing.
>
> Well, partially...
> I agree that building

Re: [U-Boot] [PATCH v1 1/2] misc: Add SCU IPC driver for Intel MID platforms

2017-03-12 Thread Simon Glass 
.Hi Andy,

On 5 March 2017 at 12:17, Andy Shevchenko
 wrote:
> From: Felipe Balbi 
>
> Intel MID platforms have few microcontrollers inside SoC, one of them is
> so called System Controller Unit (SCU).
>
> Here is the driver to communicate with microcontroller.
>
> Signed-off-by: Vincent Tinelli 
> Signed-off-by: Felipe Balbi 
> Signed-off-by: Andy Shevchenko 
> ---
>  arch/x86/Kconfig |   1 +
>  drivers/misc/Kconfig |   6 ++
>  drivers/misc/Makefile|   1 +
>  drivers/misc/intel_scu_ipc.c | 199 
> +++
>  include/intel_scu_ipc.h  |  57 +
>  5 files changed, 264 insertions(+)
>  create mode 100644 drivers/misc/intel_scu_ipc.c
>  create mode 100644 include/intel_scu_ipc.h
>
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index dfdd7564ea..6a747c332e 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -83,6 +83,7 @@ endchoice
>  # subarchitectures-specific options below
>  config INTEL_MID
> bool "Intel MID platform support"
> +   select INTEL_SCU
> help
>   Select to build a U-Boot capable of supporting Intel MID
>   (Mobile Internet Device) platform systems which do not have
> diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
> index 1aae4bcd07..8d81f9c51c 100644
> --- a/drivers/misc/Kconfig
> +++ b/drivers/misc/Kconfig
> @@ -167,4 +167,10 @@ config I2C_EEPROM
> depends on MISC
> help
>   Enable a generic driver for EEPROMs attached via I2C.
> +
> +config INTEL_SCU
> +   bool "Enable support for SCU on Intel MID platforms"
> +   depends on INTEL_MID
> +   default y

Please add help explaining what SCU is and stands for, and perhaps MID also.

> +
>  endmenu
> diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
> index e3151ea097..47551e44d6 100644
> --- a/drivers/misc/Makefile
> +++ b/drivers/misc/Makefile
> @@ -51,3 +51,4 @@ obj-$(CONFIG_PCA9551_LED) += pca9551_led.o
>  obj-$(CONFIG_FSL_DEVICE_DISABLE) += fsl_devdis.o
>  obj-$(CONFIG_WINBOND_W83627) += winbond_w83627.o
>  obj-$(CONFIG_QFW) += qfw.o
> +obj-$(CONFIG_INTEL_SCU) += intel_scu_ipc.o
> diff --git a/drivers/misc/intel_scu_ipc.c b/drivers/misc/intel_scu_ipc.c
> new file mode 100644
> index 00..19a99b0b68
> --- /dev/null
> +++ b/drivers/misc/intel_scu_ipc.c
> @@ -0,0 +1,199 @@
> +/*
> + * Copyright (c) 2017 Intel Corporation
> + *
> + * SPDX-License-Identifier:GPL-2.0+
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 

This should go after dm.h. (see http://www.denx.de/wiki/U-Boot/CodingStyle )

> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define IPC_STATUS_ADDR 0x04
> +#define IPC_SPTR_ADDR   0x08
> +#define IPC_DPTR_ADDR   0x0C
> +#define IPC_READ_BUFFER 0x90
> +#define IPC_WRITE_BUFFER0x80
> +#define IPC_IOCBIT(8)

If these offsets don't change can we use a C struct to access the registers?

> +
> +struct intel_scu {
> +   void __iomem *base;
> +};
> +
> +/* Only one for now */
> +static struct intel_scu *the_scu;

OK, but we cannot do this with driver model. It can be found using
syscon_get_regmap_by_driver_data() perhaps?

> +
> +static void scu_writel(void __iomem *base, unsigned int offset, unsigned int 
> val)
> +{
> +   writel(val, base + offset);
> +}
> +
> +static unsigned int scu_readl(void __iomem *base, unsigned int offset)
> +{
> +   return readl(base + offset);
> +}
> +
> +/*
> + * Command Register (Write Only):
> + * A write to this register results in an interrupt to the SCU core processor
> + * Format:
> + * |rfu2(8) | size(8) | command id(4) | rfu1(3) | ioc(1) | command(8)|

Please can you use the standard function header format, something like:

/*
 * intel_scu_ipc_send_command() - send a command to the SCU
 *
 * @scu: Pointer to SCU
 * @cmd: Command to send (defined by ..?)
 */

If there is a return value, the last line would be something like:

@return torque propounder coefficient in mm

> + */
> +static void intel_scu_ipc_send_command(struct intel_scu *scu, u32 cmd)
> +{
> +   scu_writel(scu->base, 0x00, cmd | IPC_IOC);
> +}
> +
> +/*
> + * IPC Write Buffer (Write Only):
> + * 16-byte buffer for sending data associated with IPC command to
> + * SCU. Size of the data is specified in the IPC_COMMAND_REG register
> + */
> +static void ipc_data_writel(struct intel_scu *scu, u32 data, u32 offset)
> +{
> +   scu_writel(scu->base, IPC_WRITE_BUFFER + offset, data);
> +}
> +
> +/*
> + * Status Register (Read Only):
> + * Driver will read this register to get the ready/busy status of the IPC
> + * block and error status of the IPC command that was just processed by SCU
> + * Format:
> + * |rfu3(8)|error code(8)|initiator id(8)|cmd id(4)|rfu1(2)|error(1)|busy(1)|
> + */

Re: [U-Boot] [PATCH v2 2/6] dm: core: Allow multiple drivers to bind for a single node

2017-03-12 Thread Simon Glass 
Hi,

On 3 March 2017 at 03:52, Dr. Philipp Tomsich
 wrote:
> Hi Simon,
>
> On 03 Mar 2017, at 05:52, Simon Glass  wrote:
>
> Hi Philipp,
>
> On 22 February 2017 at 13:47, Philipp Tomsich
>  wrote:
>
> Currently, driver binding stops once it encounters the first
> compatible driver that doesn't refuse to bind. However, there are
> cases where a single node will need to be handled by multiple driver
> classes. For those cases we provide a configurable option to continue
> to bind after the first driver has been found.
>
> The first use cases for this are from the DM conversion of the sunxi
> (Allwinner) architecture:
> * pinctrl (UCLASS_PINCTRL) and gpio (UCLASS_GPIO) drivers need to
>   bind against a single node
> * clock (UCLASS_CLK) and reset (UCLASS_RESET) drivers also need to
>   bind against a single node
>
>
> Does linux work this way? Another approach would be to have a separate
> MISC driver with two children, one pinctrl, one clk.
>
>
> The linux CLK driver creates and registers a reset-controller; the PINCTRL
> driver
> does the same with the gpio-controller. Similar code to do this is easily
> possible in
> U-Boot … see sunxi_pctrl_bind_gpio(…) in [PATCH v2 1/6] of this series.
>
> However, binding multiple times makes for much simpler code and allows to
> keep
> driver data in separate drivers.

My question was more whether Linux registers multiple drivers with one
device node. It's just not something I expected.

I'm not really convinced on this. It will break the current one-to-one
relationship, and functions like device_get_child_by_of_offset(). I
think it would be better to have a MISC driver with two children.

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v3 01/11] armv8: Add global variable resv_ram

2017-03-12 Thread Simon Glass 
Hi York,

On 3 March 2017 at 09:38, york sun  wrote:
>
> On 03/02/2017 08:53 PM, Simon Glass wrote:
> > Hi York,
> >
> > On 1 March 2017 at 12:32, York Sun  wrote:
> >> Use gd->arch.resv_ram to track reserved memory allocation.
> >>
> >> Signed-off-by: York Sun 
> >> ---
> >>
> >> Changes in v3: None
> >> Changes in v2: None
> >>
> >>  arch/arm/cpu/armv8/fsl-layerscape/Kconfig | 6 ++
> >>  arch/arm/include/asm/global_data.h| 3 +++
> >>  cmd/bdinfo.c  | 4 
> >>  3 files changed, 13 insertions(+)
> >>
> >> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig 
> >> b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
> >> index adccdf1..a40556f 100644
> >> --- a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
> >> +++ b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
> >> @@ -273,6 +273,12 @@ config SYS_FSL_SDHC_CLK_DIV
> >>   clock, in another word SDHC_clk = Platform_clk / this_divider.
> >>  endmenu
> >>
> >> +config RESV_RAM_TOP
> >> +   bool
> >> +   help
> >> + Reserve memory from the top, tracked by gd->arch.resv_ram. It's 
> >> up
> >> + to implementation to allow access to this reserved memory or not.
> >
> > This is not sufficiently descriptive IMO. What is it used for? What do
> > you mean by 'from the top'? What is the top?
>
> Simon,
>
> How about renaming it to RESV_RAM?
>
> config RESV_RAM
>  bool
> help
>   Reserve memory from the RAM, tracked by gd->arch.resv_ram.
>This reserved RAM can be used by special driver that resides
>in memory after U-Boot exits. It's up to the implementation
>to allocate and allow access to this reserved memory. For
>example, the reserved RAM can be at the high end of physical
>memory. The reserved RAM may be excluded from the memory
>bank(s) passed to OS, or marked as reserved.

OK, or perhaps RESERVED_RAM.

In the description you say 'can be' and 'may me'. What determines
whether it is or not?

>
> >
> >> +
> >>  config SYS_FSL_ERRATUM_A008336
> >> bool
> >>
> >> diff --git a/arch/arm/include/asm/global_data.h 
> >> b/arch/arm/include/asm/global_data.h
> >> index aee87cd..b1fc410 100644
> >> --- a/arch/arm/include/asm/global_data.h
> >> +++ b/arch/arm/include/asm/global_data.h
> >> @@ -59,6 +59,9 @@ struct arch_global_data {
> >> phys_addr_t secure_ram;
> >> unsigned long tlb_allocated;
> >>  #endif
> >> +#ifdef CONFIG_RESV_RAM_TOP
> >> +   phys_addr_t resv_ram;
> >
> > Please add a comment here explaining what it is for, or referencing 
> > something.
>
> I will add a comment as
> /*
>   * Reserved RAM for memory resident eg. Management Complex (MC) driver
>   * which continues to run after U-Boot exits.
>   */
>
> >
> >> +#endif
> >>
> >>  #ifdef CONFIG_ARCH_OMAP2
> >> u32 omap_boot_device;
> >> diff --git a/cmd/bdinfo.c b/cmd/bdinfo.c
> >> index ae3027a..0c5fa56 100644
> >> --- a/cmd/bdinfo.c
> >> +++ b/cmd/bdinfo.c
> >> @@ -392,6 +392,10 @@ static int do_bdinfo(cmd_tbl_t *cmdtp, int flag, int 
> >> argc,
> >>   gd->arch.secure_ram & 
> >> MEM_RESERVE_SECURE_ADDR_MASK);
> >> }
> >>  #endif
> >> +#ifdef CONFIG_RESV_RAM_TOP
> >> +   if (gd->arch.resv_ram)
> >> +   print_num("Reserved ram", gd->arch.resv_ram);
> >> +#endif
> >>  #if defined(CONFIG_CMD_NET) && !defined(CONFIG_DM_ETH)
> >> print_eths();
> >>  #endif
> >> --
>
> This patch set includes the effort to rewrite the reservation code we
> discussed a year ago
>
> https://lists.denx.de/pipermail/u-boot/2015-December/236974.html
> https://lists.denx.de/pipermail/u-boot/2015-December/236979.html
> https://lists.denx.de/pipermail/u-boot/2015-December/236996.html
>
> York

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] .gitignore: Ignore the generated top-level "sandbox/" directory

2017-03-12 Thread Robert P. J. Day 

Signed-off-by: Robert P. J. Day 

---

  am i safe in assuming that the top-level sandbox/ directory only
ever exists as the result of a build?

diff --git a/.gitignore b/.gitignore
index 7fac5b3..32a8d5b 100644
--- a/.gitignore
+++ b/.gitignore
@@ -48,6 +48,7 @@
 /LOG
 /spl/
 /tpl/
+/sandbox/
 /defconfig

 #

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v2 2/3] ARM: dts: uniphier: fix no unit name warnings

2017-03-12 Thread Masahiro Yamada 
Fix warnings reported when built with W=1, by DTC 1.4.2 or later:
  Node /memory has a reg or ranges property, but no unit name

Signed-off-by: Masahiro Yamada 
---

Changes in v2:
  - Adjust comments to the recent change of build system

 arch/arm/dts/uniphier-ld11-ref.dts  | 10 +-
 arch/arm/dts/uniphier-ld11.dtsi |  2 +-
 arch/arm/dts/uniphier-ld20-ref.dts  | 10 +-
 arch/arm/dts/uniphier-ld20.dtsi |  2 +-
 arch/arm/dts/uniphier-ld4-ref.dts   |  2 +-
 arch/arm/dts/uniphier-ld6b-ref.dts  |  2 +-
 arch/arm/dts/uniphier-pro4-ace.dts  |  2 +-
 arch/arm/dts/uniphier-pro4-ref.dts  |  2 +-
 arch/arm/dts/uniphier-pro4-sanji.dts|  2 +-
 arch/arm/dts/uniphier-pxs2-gentil.dts   |  2 +-
 arch/arm/dts/uniphier-pxs2-vodka.dts|  2 +-
 arch/arm/dts/uniphier-pxs3-ref.dts  | 10 +-
 arch/arm/dts/uniphier-pxs3.dtsi |  2 +-
 arch/arm/dts/uniphier-sld3-ref.dts  |  2 +-
 arch/arm/dts/uniphier-sld8-ref.dts  |  2 +-
 arch/arm/dts/uniphier-support-card.dtsi |  2 +-
 16 files changed, 28 insertions(+), 28 deletions(-)

diff --git a/arch/arm/dts/uniphier-ld11-ref.dts 
b/arch/arm/dts/uniphier-ld11-ref.dts
index 7693bf2..1b5f2d8 100644
--- a/arch/arm/dts/uniphier-ld11-ref.dts
+++ b/arch/arm/dts/uniphier-ld11-ref.dts
@@ -16,6 +16,10 @@
model = "UniPhier LD11 Reference Board";
compatible = "socionext,uniphier-ld11-ref", "socionext,uniphier-ld11";
 
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+
aliases {
serial0 = 
serial1 = 
@@ -29,14 +33,10 @@
i2c5 = 
};
 
-   memory {
+   memory@8000 {
device_type = "memory";
reg = <0 0x8000 0 0x4000>;
};
-
-   chosen {
-   stdout-path = "serial0:115200n8";
-   };
 };
 
  {
diff --git a/arch/arm/dts/uniphier-ld11.dtsi b/arch/arm/dts/uniphier-ld11.dtsi
index 38dc1ec..8488984 100644
--- a/arch/arm/dts/uniphier-ld11.dtsi
+++ b/arch/arm/dts/uniphier-ld11.dtsi
@@ -104,7 +104,7 @@
 <1 10 4>;
};
 
-   soc {
+   soc@0 {
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
diff --git a/arch/arm/dts/uniphier-ld20-ref.dts 
b/arch/arm/dts/uniphier-ld20-ref.dts
index 41ee07e..9cbd1f2 100644
--- a/arch/arm/dts/uniphier-ld20-ref.dts
+++ b/arch/arm/dts/uniphier-ld20-ref.dts
@@ -16,6 +16,10 @@
model = "UniPhier LD20 Reference Board";
compatible = "socionext,uniphier-ld20-ref", "socionext,uniphier-ld20";
 
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+
aliases {
serial0 = 
serial1 = 
@@ -29,14 +33,10 @@
i2c5 = 
};
 
-   memory {
+   memory@8000 {
device_type = "memory";
reg = <0 0x8000 0 0xc000>;
};
-
-   chosen {
-   stdout-path = "serial0:115200n8";
-   };
 };
 
  {
diff --git a/arch/arm/dts/uniphier-ld20.dtsi b/arch/arm/dts/uniphier-ld20.dtsi
index 7176757..d853526 100644
--- a/arch/arm/dts/uniphier-ld20.dtsi
+++ b/arch/arm/dts/uniphier-ld20.dtsi
@@ -173,7 +173,7 @@
 <1 10 4>;
};
 
-   soc {
+   soc@0 {
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
diff --git a/arch/arm/dts/uniphier-ld4-ref.dts 
b/arch/arm/dts/uniphier-ld4-ref.dts
index f397a4c..d3177e9 100644
--- a/arch/arm/dts/uniphier-ld4-ref.dts
+++ b/arch/arm/dts/uniphier-ld4-ref.dts
@@ -31,7 +31,7 @@
i2c3 = 
};
 
-   memory {
+   memory@8000 {
device_type = "memory";
reg = <0x8000 0x2000>;
};
diff --git a/arch/arm/dts/uniphier-ld6b-ref.dts 
b/arch/arm/dts/uniphier-ld6b-ref.dts
index fdfb533..7cdc923 100644
--- a/arch/arm/dts/uniphier-ld6b-ref.dts
+++ b/arch/arm/dts/uniphier-ld6b-ref.dts
@@ -33,7 +33,7 @@
i2c6 = 
};
 
-   memory {
+   memory@8000 {
device_type = "memory";
reg = <0x8000 0x8000>;
};
diff --git a/arch/arm/dts/uniphier-pro4-ace.dts 
b/arch/arm/dts/uniphier-pro4-ace.dts
index b9d4315..0183df0 100644
--- a/arch/arm/dts/uniphier-pro4-ace.dts
+++ b/arch/arm/dts/uniphier-pro4-ace.dts
@@ -30,7 +30,7 @@
i2c6 = 
};
 
-   memory {
+   memory@8000 {
device_type = "memory";
reg = <0x8000 0x4000>;
};
diff --git a/arch/arm/dts/uniphier-pro4-ref.dts 
b/arch/arm/dts/uniphier-pro4-ref.dts
index 920fd54..a1fbbdc 100644
--- a/arch/arm/dts/uniphier-pro4-ref.dts
+++ b/arch/arm/dts/uniphier-pro4-ref.dts
@@ -34,7 +34,7 @@
usb0 = 
};
 
-   memory {
+   memory@8000 {

[U-Boot] [PATCH v2 3/3] ARM: dts: uniphier: more re-sync DT with Linux

2017-03-12 Thread Masahiro Yamada 
For better maintainability.

Signed-off-by: Masahiro Yamada 
---

Changes in v2:
  - Newly added

 arch/arm/dts/uniphier-ld11.dtsi |  2 +-
 arch/arm/dts/uniphier-pxs2.dtsi | 22 --
 arch/arm/dts/uniphier-sld3.dtsi |  7 +--
 3 files changed, 14 insertions(+), 17 deletions(-)

diff --git a/arch/arm/dts/uniphier-ld11.dtsi b/arch/arm/dts/uniphier-ld11.dtsi
index 8488984..2843adb 100644
--- a/arch/arm/dts/uniphier-ld11.dtsi
+++ b/arch/arm/dts/uniphier-ld11.dtsi
@@ -318,7 +318,7 @@
};
 
mioctrl@5b3e {
-   compatible = "socionext,uniphier-mioctrl",
+   compatible = "socionext,uniphier-ld11-mioctrl",
 "simple-mfd", "syscon";
reg = <0x5b3e 0x800>;
 
diff --git a/arch/arm/dts/uniphier-pxs2.dtsi b/arch/arm/dts/uniphier-pxs2.dtsi
index 904320c..b0f6f94 100644
--- a/arch/arm/dts/uniphier-pxs2.dtsi
+++ b/arch/arm/dts/uniphier-pxs2.dtsi
@@ -112,12 +112,6 @@
compatible = "fixed-clock";
clock-frequency = <5000>;
};
-
-   i2c_clk: i2c_clk {
-   #clock-cells = <0>;
-   compatible = "fixed-clock";
-   clock-frequency = <5000>;
-   };
};
 
soc {
@@ -389,7 +383,7 @@
interrupts = <0 41 4>;
pinctrl-names = "default";
pinctrl-0 = <_i2c0>;
-   clocks = <_clk>;
+   clocks = <_clk 4>;
clock-frequency = <10>;
};
 
@@ -402,7 +396,7 @@
interrupts = <0 42 4>;
pinctrl-names = "default";
pinctrl-0 = <_i2c1>;
-   clocks = <_clk>;
+   clocks = <_clk 5>;
clock-frequency = <10>;
};
 
@@ -415,7 +409,7 @@
interrupts = <0 43 4>;
pinctrl-names = "default";
pinctrl-0 = <_i2c2>;
-   clocks = <_clk>;
+   clocks = <_clk 6>;
clock-frequency = <10>;
};
 
@@ -428,7 +422,7 @@
interrupts = <0 44 4>;
pinctrl-names = "default";
pinctrl-0 = <_i2c3>;
-   clocks = <_clk>;
+   clocks = <_clk 7>;
clock-frequency = <10>;
};
 
@@ -439,7 +433,7 @@
#address-cells = <1>;
#size-cells = <0>;
interrupts = <0 45 4>;
-   clocks = <_clk>;
+   clocks = <_clk 8>;
clock-frequency = <40>;
};
 
@@ -450,7 +444,7 @@
#address-cells = <1>;
#size-cells = <0>;
interrupts = <0 25 4>;
-   clocks = <_clk>;
+   clocks = <_clk 9>;
clock-frequency = <40>;
};
 
@@ -461,7 +455,7 @@
#address-cells = <1>;
#size-cells = <0>;
interrupts = <0 26 4>;
-   clocks = <_clk>;
+   clocks = <_clk 10>;
clock-frequency = <40>;
};
 
@@ -590,7 +584,7 @@
sysctrl@6184 {
compatible = "socionext,uniphier-pxs2-sysctrl",
 "simple-mfd", "syscon";
-   reg = <0x6184 0x4000>;
+   reg = <0x6184 0x1>;
 
sys_clk: clock {
compatible = "socionext,uniphier-pxs2-clock";
diff --git a/arch/arm/dts/uniphier-sld3.dtsi b/arch/arm/dts/uniphier-sld3.dtsi
index 7578920..9e458d3 100644
--- a/arch/arm/dts/uniphier-sld3.dtsi
+++ b/arch/arm/dts/uniphier-sld3.dtsi
@@ -101,6 +101,7 @@
interrupts = <0 33 4>;
pinctrl-names = "default";
pinctrl-0 = <_uart0>;
+   clocks = <_clk 0>;
clock-frequency = <36864000>;
};
 
@@ -111,6 +112,7 @@
interrupts = <0 35 4>;
pinctrl-names = "default";
pinctrl-0 = <_uart1>;
+   clocks = <_clk 0>;
clock-frequency = <36864000>;
};
 
@@ -121,6 +123,7 @@
interrupts = <0 37 4>;
pinctrl-names = "default";
pinctrl-0 = <_uart2>;
+   clocks = <_clk 0>;

[U-Boot] [PATCH v2 1/3] ARM: dts: uniphier: remove skeleton.dtsi inclusion

2017-03-12 Thread Masahiro Yamada 
Linux Commit 9c0da3cc61f1 ("ARM: dts: explicitly mark skeleton.dtsi
as deprecated") declared that skeleton.dtsi was deprecated.

Move the memory node below to suppress warnings of FDTGREP.

Signed-off-by: Masahiro Yamada 
---

Changes in v2:
  - Fix FDTGREP warnings

 arch/arm/dts/uniphier-ld4-ref.dts | 10 +-
 arch/arm/dts/uniphier-ld4.dtsi|  4 ++--
 arch/arm/dts/uniphier-ld6b-ref.dts| 10 +-
 arch/arm/dts/uniphier-pro4-ace.dts| 10 +-
 arch/arm/dts/uniphier-pro4-ref.dts| 10 +-
 arch/arm/dts/uniphier-pro4-sanji.dts  | 10 +-
 arch/arm/dts/uniphier-pro4.dtsi   |  4 ++--
 arch/arm/dts/uniphier-pro5-4kbox.dts  | 10 +-
 arch/arm/dts/uniphier-pro5.dtsi   |  4 ++--
 arch/arm/dts/uniphier-pxs2-gentil.dts | 10 +-
 arch/arm/dts/uniphier-pxs2-vodka.dts  | 10 +-
 arch/arm/dts/uniphier-pxs2.dtsi   |  4 ++--
 arch/arm/dts/uniphier-sld3-ref.dts| 12 ++--
 arch/arm/dts/uniphier-sld3.dtsi   |  4 ++--
 arch/arm/dts/uniphier-sld8-ref.dts| 10 +-
 arch/arm/dts/uniphier-sld8.dtsi   |  4 ++--
 16 files changed, 63 insertions(+), 63 deletions(-)

diff --git a/arch/arm/dts/uniphier-ld4-ref.dts 
b/arch/arm/dts/uniphier-ld4-ref.dts
index 0f4bd9b..f397a4c 100644
--- a/arch/arm/dts/uniphier-ld4-ref.dts
+++ b/arch/arm/dts/uniphier-ld4-ref.dts
@@ -16,11 +16,6 @@
model = "UniPhier LD4 Reference Board";
compatible = "socionext,uniphier-ld4-ref", "socionext,uniphier-ld4";
 
-   memory {
-   device_type = "memory";
-   reg = <0x8000 0x2000>;
-   };
-
chosen {
stdout-path = "serial0:115200n8";
};
@@ -35,6 +30,11 @@
i2c2 = 
i2c3 = 
};
+
+   memory {
+   device_type = "memory";
+   reg = <0x8000 0x2000>;
+   };
 };
 
  {
diff --git a/arch/arm/dts/uniphier-ld4.dtsi b/arch/arm/dts/uniphier-ld4.dtsi
index bbfa164..0d3d963 100644
--- a/arch/arm/dts/uniphier-ld4.dtsi
+++ b/arch/arm/dts/uniphier-ld4.dtsi
@@ -7,10 +7,10 @@
  * SPDX-License-Identifier:GPL-2.0+X11
  */
 
-/include/ "skeleton.dtsi"
-
 / {
compatible = "socionext,uniphier-ld4";
+   #address-cells = <1>;
+   #size-cells = <1>;
 
cpus {
#address-cells = <1>;
diff --git a/arch/arm/dts/uniphier-ld6b-ref.dts 
b/arch/arm/dts/uniphier-ld6b-ref.dts
index 4da3c63..fdfb533 100644
--- a/arch/arm/dts/uniphier-ld6b-ref.dts
+++ b/arch/arm/dts/uniphier-ld6b-ref.dts
@@ -16,11 +16,6 @@
model = "UniPhier LD6b Reference Board";
compatible = "socionext,uniphier-ld6b-ref", "socionext,uniphier-ld6b";
 
-   memory {
-   device_type = "memory";
-   reg = <0x8000 0x8000>;
-   };
-
chosen {
stdout-path = "serial0:115200n8";
};
@@ -37,6 +32,11 @@
i2c5 = 
i2c6 = 
};
+
+   memory {
+   device_type = "memory";
+   reg = <0x8000 0x8000>;
+   };
 };
 
  {
diff --git a/arch/arm/dts/uniphier-pro4-ace.dts 
b/arch/arm/dts/uniphier-pro4-ace.dts
index f70bc82..b9d4315 100644
--- a/arch/arm/dts/uniphier-pro4-ace.dts
+++ b/arch/arm/dts/uniphier-pro4-ace.dts
@@ -14,11 +14,6 @@
model = "UniPhier Pro4 Ace Board";
compatible = "socionext,uniphier-pro4-ace", "socionext,uniphier-pro4";
 
-   memory {
-   device_type = "memory";
-   reg = <0x8000 0x4000>;
-   };
-
chosen {
stdout-path = "serial0:115200n8";
};
@@ -34,6 +29,11 @@
i2c5 = 
i2c6 = 
};
+
+   memory {
+   device_type = "memory";
+   reg = <0x8000 0x4000>;
+   };
 };
 
  {
diff --git a/arch/arm/dts/uniphier-pro4-ref.dts 
b/arch/arm/dts/uniphier-pro4-ref.dts
index 9714fb0..920fd54 100644
--- a/arch/arm/dts/uniphier-pro4-ref.dts
+++ b/arch/arm/dts/uniphier-pro4-ref.dts
@@ -16,11 +16,6 @@
model = "UniPhier Pro4 Reference Board";
compatible = "socionext,uniphier-pro4-ref", "socionext,uniphier-pro4";
 
-   memory {
-   device_type = "memory";
-   reg = <0x8000 0x4000>;
-   };
-
chosen {
stdout-path = "serial0:115200n8";
};
@@ -38,6 +33,11 @@
i2c6 = 
usb0 = 
};
+
+   memory {
+   device_type = "memory";
+   reg = <0x8000 0x4000>;
+   };
 };
 
  {
diff --git a/arch/arm/dts/uniphier-pro4-sanji.dts 
b/arch/arm/dts/uniphier-pro4-sanji.dts
index d43f725..b103ba5 100644
--- a/arch/arm/dts/uniphier-pro4-sanji.dts
+++ b/arch/arm/dts/uniphier-pro4-sanji.dts
@@ -14,11 +14,6 @@
model = "UniPhier Pro4 Sanji Board";
compatible = "socionext,uniphier-pro4-sanji", "socionext,uniphier-pro4";
 
-   memory {
-

[U-Boot] [PATCH 2/2] efi_loader: check CreateEvent() parameters

2017-03-12 Thread Jonathan Gray 
Add some of the invalid parameter checks described in the UEFI
specification for CreateEvent().  This does not include checking
the validity of the type and tpl parameters.

Signed-off-by: Jonathan Gray 
---
 lib/efi_loader/efi_boottime.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index eb5946a959..7172b690a5 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -189,6 +189,16 @@ static efi_status_t EFIAPI efi_create_event(
return EFI_EXIT(EFI_OUT_OF_RESOURCES);
}
 
+   if (event == NULL)
+   return EFI_EXIT(EFI_INVALID_PARAMETER);
+
+   if ((type & EVT_NOTIFY_SIGNAL) && (type & EVT_NOTIFY_WAIT))
+   return EFI_EXIT(EFI_INVALID_PARAMETER);
+
+   if ((type & (EVT_NOTIFY_SIGNAL|EVT_NOTIFY_WAIT)) &&
+notify_function == NULL)
+   return EFI_EXIT(EFI_INVALID_PARAMETER);
+
efi_event.type = type;
efi_event.notify_tpl = notify_tpl;
efi_event.notify_function = notify_function;
-- 
2.12.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 1/2] efi_loader: run CreateEvent() notify function based on flags

2017-03-12 Thread Jonathan Gray 
The UEFI specification states that the tpl, function and context
arguments are to be ignored if neither EVT_NOTIFY_WAIT or
EVT_NOTIFY_SIGNAL are specified.  This matches observed behaviour with
an AMI EDK2 based UEFI implementation.

Skip calling the notify function if neither flag is present.

Signed-off-by: Jonathan Gray 
---
 include/efi_api.h | 3 +++
 lib/efi_loader/efi_boottime.c | 4 +++-
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/include/efi_api.h b/include/efi_api.h
index 5c3836a51b..f071b36b53 100644
--- a/include/efi_api.h
+++ b/include/efi_api.h
@@ -28,6 +28,9 @@ enum efi_event_type {
EFI_TIMER_RELATIVE = 2
 };
 
+#define EVT_NOTIFY_WAIT0x0100
+#define EVT_NOTIFY_SIGNAL  0x0200
+
 /* EFI Boot Services table */
 struct efi_boot_services {
struct efi_table_hdr hdr;
diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index 51080cbeed..eb5946a959 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -210,7 +210,9 @@ void efi_timer_check(void)
/* Triggering! */
if (efi_event.trigger_type == EFI_TIMER_PERIODIC)
efi_event.trigger_next += efi_event.trigger_time / 10;
-   efi_event.notify_function(_event, efi_event.notify_context);
+   if (efi_event.type & (EVT_NOTIFY_WAIT | EVT_NOTIFY_SIGNAL))
+   efi_event.notify_function(_event,
+ efi_event.notify_context);
}
 
WATCHDOG_RESET();
-- 
2.12.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot