Re: [PATCH 2/2] dt-binding: leds: Document leds-multi-gpio bindings

GPIO lines controlling the brightness so that needs a bit more effort in order to test that out. At some point of time I could also revive the PWM stuff if no one else beats me to it -- but probably the GPIO variant is easier to get done as binary states are easier. Thanks, Vesa Jääskeläinen

Re: [PATCH 2/2] dt-binding: leds: Document leds-multi-gpio bindings

... see below }; }; # And then single GPIO with intensity GPIOs: led@2 { compatible = "gpio-leds"; gpios = < 23 0x1>, < 24 0x1>; gpios-brightness-levels = <0 1 2 3> }; I changed 'led-states' to 'gpios-brightness-levels' as it describe more that this is about brightness and not some other state information. How would this sound? Thanks, Vesa Jääskeläinen

Re: [PATCH v4] tee: add support for application-based session login methods

E, "app=%s", + app_id); + kfree(app_id_data); + break; Thanks, Vesa Jääskeläinen

Re: [PATCH] tee: fix crypto select

ned-off-by: Arnd Bergmann --- The regression was introduced in the soc tree, I'd pick this patch up directly into that unless someone sees a problem Thanks for taking care of this, please go ahead. Cheers, Jens I am also OK for the change. Sorry that we did not notice this during the review. Feel fr

[PATCH v2 0/3] tee: add support for session's client UUID generation

UUID. Vesa Jääskeläinen (3): tee: add support for session's client UUID generation tee: optee: Add support for session login client UUID generation [RFC] tee: add support for app id for client UUID generation drivers/tee/Kconfig | 1 + drivers/tee/optee/call.c | 6 +- drivers/tee

[PATCH v2 2/3] tee: optee: Add support for session login client UUID generation

Adds support for client UUID generation for OP-TEE. For group based session logins membership is verified. Signed-off-by: Vesa Jääskeläinen --- drivers/tee/optee/call.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/tee/optee/call.c b/drivers/tee/optee/call.c

[PATCH v2 3/3] [RFC] tee: add support for app id for client UUID generation

to handle custom App ID sources Android has own App ID so does Tizen. Should there be place holder for this where to make local patch? Signed-off-by: Vesa Jääskeläinen --- drivers/tee/tee_core.c | 58 ++ 1 file changed, 58 insertions(+) diff --git a/drivers

[PATCH v2 1/3] tee: add support for session's client UUID generation

UUID. UUIDv5 form is used encode variable amount of information needed for different login types. Signed-off-by: Vesa Jääskeläinen --- drivers/tee/Kconfig | 1 + drivers/tee/tee_core.c | 153 include/linux/tee_drv.h | 16 + 3 files changed, 170

Re: [RFC PATCH] leds: multicolor: Add sysfs interface definition

Hi All, On 08/02/2019 6.55, Vesa Jääskeläinen wrote: Hi All, On 31/01/2019 0.35, Pavel Machek wrote: On Wed 2019-01-30 12:30:05, Dan Murphy wrote: Add a documentation of LED Multicolor LED class specific sysfs attributes. No, sorry. This does not most of the requirements

Re: [RFC PATCH] leds: multicolor: Add sysfs interface definition

to provide usage example also for Dan's proposal. Feel free to correct me if I made a mistake. I believe it is a good to create summary page as there seems to many aspects to be though out. What do you feel on this approach? Thanks, Vesa Jääskeläinen

Re: [PATCH v2 2/2] leds: lp50xx: Add the LP50XX family of the RGB LED driver

Hi Dan, On 21/01/2019 15.27, Dan Murphy wrote: Vesa On 1/19/19 1:11 PM, Vesa Jääskeläinen wrote: Hi Jacek et al, On 17/01/2019 23.08, Jacek Anaszewski wrote: On 1/16/19 11:55 AM, Pavel Machek wrote: Hi! On 1/15/19 4:22 PM, Pavel Machek wrote: Hi! +The 24-bit RGB value passed

Re: [PATCH v2 2/2] leds: lp50xx: Add the LP50XX family of the RGB LED driver

either values 0 or 255 for brightness when controlling. To fix the issue I believe trigger mechanism should be adjusted to allowing one to control ON brightness level. I would recommend fixing this trigger problem with future patches for it. Thanks, Vesa Jääskeläinen

Re: [PATCH v2 2/2] leds: lp50xx: Add the LP50XX family of the RGB LED driver

complex things :) As an example in our case we can do with "red", "green", and "red", "green", "blue" combos fill all our current requirements we have. Perhaps white could be added as one thing in future (white is currently used only in lcd module's background). Latest proposal I have for the interface now lets you do all of those things so it should be easy enough for most cases and still flexes to more complex cases while keeping kernel space simple. Thanks, Vesa Jääskeläinen

Re: [PATCH v2 2/2] leds: lp50xx: Add the LP50XX family of the RGB LED driver

"ramp-levels" or such. Used pwm-backlights terminology in this example. [1] https://www.kernel.org/doc/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.txt [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/video/backlight/pwm_bl.c?h=v5.0-rc2#n253 Thanks, Vesa Jääskeläinen

Re: [PATCH v2 2/2] leds: lp50xx: Add the LP50XX family of the RGB LED driver

}; element-blue { pwms = < 1 10 0>; }; }; }; What do you think is this something we agree and could go forward? If it is it would be a good idea to get feedback from Dan on how easy it is to use and other possible issues if he takes common commits and tries it out with his lp50xx driver. Thanks, Vesa Jääskeläinen

Re: Generic RGB LED support was Re: [PATCH 2/2] leds: lp5024: Add the LP5024/18 RGB LED driver

et in github) my tests to use color array model and color_names already and can play with brightness_model thing if this is something that is good path? What do you think? Thanks, Vesa Jääskeläinen

Re: [PATCH 2/2] leds: lp5024: Add the LP5024/18 RGB LED driver

Hi Jacek, On 07/01/2019 23.13, Jacek Anaszewski wrote: Hi Vesa, On 1/5/19 1:39 AM, Vesa Jääskeläinen wrote: Hi Jacek, On 04/01/2019 23.37, Jacek Anaszewski wrote: But, aside from that hypothetic issue, we need a solution for LEDn_BRIGHTNESS feature of lp5024, i.e. setting color intensity

Re: [PATCH 2/2] leds: lp5024: Add the LP5024/18 RGB LED driver

Hi Dan, On 07/01/2019 21.34, Dan Murphy wrote: Vesa On 1/4/19 6:39 PM, Vesa Jääskeläinen wrote: Hi Jacek, On 04/01/2019 23.37, Jacek Anaszewski wrote: But, aside from that hypothetic issue, we need a solution for LEDn_BRIGHTNESS feature of lp5024, i.e. setting color intensity via a single

Re: [PATCH 2/2] leds: lp5024: Add the LP5024/18 RGB LED driver

model = "hsl" This would then pick red, green and blue elements for hsl calculations and others color elements for linear. LED specific hardware brightness would then be either 0 or 0xFF depending if all of LED color elements are zero or not. Would that kind of model work? Thanks, Vesa Jääskeläinen

Re: [PATCH 2/2] leds: lp5024: Add the LP5024/18 RGB LED driver

can be configured). Only problem I suppose is color transition from A to B state and after that the blinking would work nicely as target color would already be known by driver. If we could figure out acceptable solution for color transition problem then I suppose all parties would be happy? Thanks, Vesa Jääskeläinen

Re: [PATCH 2/2] leds: lp5024: Add the LP5024/18 RGB LED driver

Hi Jacek, Comments below. On 04/01/2019 0.05, Jacek Anaszewski wrote: Hi Vesa, Thank you for sharing your ideas. Please find my comment below. On 1/1/19 2:45 PM, Vesa Jääskeläinen wrote: Hi All, On 20/12/2018 14.40, Vesa Jääskeläinen wrote: Idea was to define preset colors in device tree

Re: [PATCH 2/2] leds: lp5024: Add the LP5024/18 RGB LED driver

Hi All, On 20/12/2018 14.40, Vesa Jääskeläinen wrote: Idea was to define preset colors in device tree as an example when you are dealing with multi-color LEDs without PWM. In that case you only have GPIOs to control and then have a problem what does those GPIO's mean. With preset definitions

Re: [PATCH 2/2] leds: lp5024: Add the LP5024/18 RGB LED driver

Hi All, On 19/12/2018 23.50, Dan Murphy wrote: On 12/19/2018 03:36 PM, Jacek Anaszewski wrote: Hi Dan and Pavel, Some time ago we had discussion with Vesa Jääskeläinen about possible approaches to RGB LEDs [0]. What seemed to be the most suitable variation of the discussed out-of-tree approach

Re: [PATCH 04/24] dt-bindings: leds: Add function and color properties

d without actual led driver and directly use PWM interface) Even in when reduced intensivity we want the color to be set to specified value even thou it would not be as bright as full intensivity would be. What do you think? Thanks, Vesa Jääskeläinen

Re: [PATCH 04/24] dt-bindings: leds: Add function and color properties

d without actual led driver and directly use PWM interface) Even in when reduced intensivity we want the color to be set to specified value even thou it would not be as bright as full intensivity would be. What do you think? Thanks, Vesa Jääskeläinen

Re: [PATCH 03/24] leds: dt-bindings: Add LED_FUNCTION definitions

implemented for label too if seen as a good thing) Thanks, Vesa Jääskeläinen

Re: [PATCH 03/24] leds: dt-bindings: Add LED_FUNCTION definitions

implemented for label too if seen as a good thing) Thanks, Vesa Jääskeläinen

Re: [PATCH 02/24] leds: core: Add support for composing LED class device names

n of the old LED naming from Documentation/leds/leds-class.txt was too drastic move. I'll keep it next to the new one, and only add a note that it is kept only for backwards compatibility. With above proposal for naming it should match more or less everyone's needs? Simple naming for embedded device makers and more advanced for server system makers. No need to say that something is legacy or backwards compatibility feature. Thanks, Vesa Jääskeläinen

Re: [PATCH 02/24] leds: core: Add support for composing LED class device names

n of the old LED naming from Documentation/leds/leds-class.txt was too drastic move. I'll keep it next to the new one, and only add a note that it is kept only for backwards compatibility. With above proposal for naming it should match more or less everyone's needs? Simple naming for embedded device makers and more advanced for server system makers. No need to say that something is legacy or backwards compatibility feature. Thanks, Vesa Jääskeläinen

Re: [PATCH 04/24] dt-bindings: leds: Add function and color properties

Hi Jacek, On 09/11/2018 22.42, Jacek Anaszewski wrote: Hi Vesa, On 11/09/2018 09:32 AM, Vesa Jääskeläinen wrote: On 07/11/2018 0.07, Jacek Anaszewski wrote: Introduce dedicated properties for conveying information about LED function and color. Mark old "label" property as deprecate

Re: [PATCH 04/24] dt-bindings: leds: Add function and color properties

Hi Jacek, On 09/11/2018 22.42, Jacek Anaszewski wrote: Hi Vesa, On 11/09/2018 09:32 AM, Vesa Jääskeläinen wrote: On 07/11/2018 0.07, Jacek Anaszewski wrote: Introduce dedicated properties for conveying information about LED function and color. Mark old "label" property as deprecate

Re: [PATCH 04/24] dt-bindings: leds: Add function and color properties

= "keep"; color-red { pin-mask = <0x01>; }; color-green { pin-mask = <0x02>; }; color-orange { pin-mask = <0x03>; }; }; }; Thanks, Vesa Jääskeläinen

Re: [PATCH 04/24] dt-bindings: leds: Add function and color properties

= "keep"; color-red { pin-mask = <0x01>; }; color-green { pin-mask = <0x02>; }; color-orange { pin-mask = <0x03>; }; }; }; Thanks, Vesa Jääskeläinen

Re: [PATCH v2 3/3] reset: reset-zynqmp: Adding support for Xilinx zynqmp reset controller.

(ZYNQMP_PM_RESET_END - ZYNQMP_PM_RESET_START) +#define ZYNQMP_RESET_ID (ZYNQMP_PM_RESET_START + 1) If you move start forward then you don't need +1 here. Or you can get rid of the define altogether and just use ZYNQMP_PM_RESET_START in it's place.. Thanks, Vesa Jääskeläinen

Re: [PATCH v2 3/3] reset: reset-zynqmp: Adding support for Xilinx zynqmp reset controller.

(ZYNQMP_PM_RESET_END - ZYNQMP_PM_RESET_START) +#define ZYNQMP_RESET_ID (ZYNQMP_PM_RESET_START + 1) If you move start forward then you don't need +1 here. Or you can get rid of the define altogether and just use ZYNQMP_PM_RESET_START in it's place.. Thanks, Vesa Jääskeläinen

Re: [PATCH v2 1/3] firmware: xilinx: Add reset API's

, + ZYNQMP_PM_RESET_GPO3_PL_14, + ZYNQMP_PM_RESET_GPO3_PL_15, + ZYNQMP_PM_RESET_GPO3_PL_16, + ZYNQMP_PM_RESET_GPO3_PL_17, + ZYNQMP_PM_RESET_GPO3_PL_18, + ZYNQMP_PM_RESET_GPO3_PL_19, + ZNQMP_PM_RESET_GPO3_PL_20, Typo here. Missing Y. Thanks, Vesa Jääskeläinen

Re: [PATCH v2 1/3] firmware: xilinx: Add reset API's

, + ZYNQMP_PM_RESET_GPO3_PL_14, + ZYNQMP_PM_RESET_GPO3_PL_15, + ZYNQMP_PM_RESET_GPO3_PL_16, + ZYNQMP_PM_RESET_GPO3_PL_17, + ZYNQMP_PM_RESET_GPO3_PL_18, + ZYNQMP_PM_RESET_GPO3_PL_19, + ZNQMP_PM_RESET_GPO3_PL_20, Typo here. Missing Y. Thanks, Vesa Jääskeläinen

[RFC PATCH 1/2] Documentation: devicetree: root node board-revision property documentation

storage. It is expected that bootloader will analyse board revision information and pass it in device tree to kernel. Signed-off-by: Vesa Jääskeläinen <vesa.jaaskelai...@vaisala.com> --- Documentation/devicetree/booting-without-of.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documen

[RFC PATCH 0/2] device tree support for board revision

s information as it might be that bootloader can only access the information (in case of multipurpose pin in chip). And the standard way for user space to access this information. Thanks, Vesa Jääskeläinen Vesa Jääskeläinen (2): Documentation: devicetree: root node board-revision property

[RFC PATCH 1/2] Documentation: devicetree: root node board-revision property documentation

storage. It is expected that bootloader will analyse board revision information and pass it in device tree to kernel. Signed-off-by: Vesa Jääskeläinen --- Documentation/devicetree/booting-without-of.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/booting-without

[RFC PATCH 0/2] device tree support for board revision

s information as it might be that bootloader can only access the information (in case of multipurpose pin in chip). And the standard way for user space to access this information. Thanks, Vesa Jääskeläinen Vesa Jääskeläinen (2): Documentation: devicetree: root node board-revision property

[RFC PATCH 2/2] arm: setup: Show the board revision from devicetree in cpuinfo

as previously. Signed-off-by: Vesa Jääskeläinen <vesa.jaaskelai...@vaisala.com> --- arch/arm/kernel/setup.c | 12 +++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c index 4e80bf7..325604e 100644 --- a/arch/arm/kernel/setup.c

[RFC PATCH 2/2] arm: setup: Show the board revision from devicetree in cpuinfo

as previously. Signed-off-by: Vesa Jääskeläinen --- arch/arm/kernel/setup.c | 12 +++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c index 4e80bf7..325604e 100644 --- a/arch/arm/kernel/setup.c +++ b/arch/arm/kernel/setup.c

Re: [PATCH v3] gpio: Added zynq specific check for special pins on bank zero

On 23/09/2016 14.26, Nava kishore Manne wrote: From: Nava kishore Manne This patch adds zynq specific check for bank 0 pins 7 and 8 are special and cannot be used as inputs Signed-off-by: Nava kishore Manne Reported-by: Jonas Karlsson

Re: [PATCH v3] gpio: Added zynq specific check for special pins on bank zero

On 23/09/2016 14.26, Nava kishore Manne wrote: From: Nava kishore Manne This patch adds zynq specific check for bank 0 pins 7 and 8 are special and cannot be used as inputs Signed-off-by: Nava kishore Manne Reported-by: Jonas Karlsson Acked-by: Sören Brinkmann Acked-by: Michal Simek ---