Re: [PATCH 1/2] clk: honor CLK_MUX_ROUND_CLOSEST in generic clk mux

struct clk_rate_request *req); > +int clk_mux_determine_rate_flags(struct clk_hw *hw, > +struct clk_rate_request *req, > + unsigned long flags); > void clk_hw_reparent(str

Re: [PATCH 1/2] clk: honor CLK_MUX_ROUND_CLOSEST in generic clk mux

req); > +int clk_mux_determine_rate_flags(struct clk_hw *hw, > +struct clk_rate_request *req, > + unsigned long flags); > void clk_hw_reparent(struct clk_hw *hw, struct clk_hw *new_parent); > void clk_hw_set_rate_range(struct clk_hw *hw, unsigned long min_rate, >unsigned long max_rate); > -- > 2.14.3 > Reviewed-by: Ezequiel Garcia Thanks! -- Ezequiel García, VanguardiaSur www.vanguardiasur.com.ar

Re: [PATCH 5/6] devfreq: rk3399_dmc: do not print error when get supply and clk defer.

On Mon, 2018-04-23 at 12:44 +0200, Ulf Hansson wrote: > On 19 April 2018 at 12:40, Enric Balletbo i Serra > wrote: > > From: Lin Huang > > > > We just return -EPROBE_DEFER error code to caller and do not > > print error message when try to get

Re: [PATCH 5/6] devfreq: rk3399_dmc: do not print error when get supply and clk defer.

On Mon, 2018-04-23 at 12:44 +0200, Ulf Hansson wrote: > On 19 April 2018 at 12:40, Enric Balletbo i Serra > wrote: > > From: Lin Huang > > > > We just return -EPROBE_DEFER error code to caller and do not > > print error message when try to get center logic regulator > > and DMC clock defer. > >

Re: [PATCH] Input: atmel_mxt_ts - fix reset-gpio for level based irqs

Hi Sebastian, On Fri, 2018-04-20 at 19:24 +0200, Sebastian Reichel wrote: > The current reset-gpio support triggers an interrupt storm on platforms > using the maxtouch with level based interrupt. The Motorola Droid 4, > which I used for some of the tests is not affected, since it uses a level >

Re: [PATCH] Input: atmel_mxt_ts - fix reset-gpio for level based irqs

Hi Sebastian, On Fri, 2018-04-20 at 19:24 +0200, Sebastian Reichel wrote: > The current reset-gpio support triggers an interrupt storm on platforms > using the maxtouch with level based interrupt. The Motorola Droid 4, > which I used for some of the tests is not affected, since it uses a level >

Re: [PATCH] ARM: dts: imx53-ppd: Use IRQ_TYPE_* constants

set-gpio = < 19 GPIO_ACTIVE_HIGH>; > reg = <0x4b>; > interrupt-parent = <>; > - interrupts = <4 0x8>; > + interrupts = <4 IRQ_TYPE_LEVEL_LOW>; > }; > }; > > Looks good to me: Reviewed-b

Re: [PATCH] ARM: dts: imx53-ppd: Use IRQ_TYPE_* constants

; reg = <0x4b>; > interrupt-parent = <>; > - interrupts = <4 0x8>; > + interrupts = <4 IRQ_TYPE_LEVEL_LOW>; > }; > }; > > Looks good to me: Reviewed-by: Ezequiel Garcia And it made me t

Re: [PATCH v6 24/30] drm/rockchip: Disable PSR on input events

On Thu, 2018-04-05 at 11:49 +0200, Enric Balletbo i Serra wrote: > From: "Kristian H. Kristensen" > > To improve PSR exit latency, we speculatively start exiting when we > receive input events. Occasionally, this may lead to false positives, > but most of the time we get a

Re: [PATCH v6 24/30] drm/rockchip: Disable PSR on input events

On Thu, 2018-04-05 at 11:49 +0200, Enric Balletbo i Serra wrote: > From: "Kristian H. Kristensen" > > To improve PSR exit latency, we speculatively start exiting when we > receive input events. Occasionally, this may lead to false positives, > but most of the time we get a head start on coming

Re: [PATCH v8 2/3] mtd: spi-nor: add rockchip serial flash controller driver

Hi Andy, Just a very minor nit. On 8 February 2018 at 09:18, Andy Yan wrote: [..] > + > +static int get_if_type(struct rockchip_sfc *sfc, enum spi_nor_protocol proto) > +{ I understand that this got copy-pasted from some other driver, but please change this function

Re: [PATCH v8 2/3] mtd: spi-nor: add rockchip serial flash controller driver

Hi Andy, Just a very minor nit. On 8 February 2018 at 09:18, Andy Yan wrote: [..] > + > +static int get_if_type(struct rockchip_sfc *sfc, enum spi_nor_protocol proto) > +{ I understand that this got copy-pasted from some other driver, but please change this function name to something like

Re: [PATCHv4 1/1] mtd: nand: pxa3xx: Set FORCE_CSX bit to ARMADA370 variants

On 22 December 2017 at 12:53, Miquel RAYNAL wrote: > Hello Chris, > > On Fri, 22 Dec 2017 12:19:04 +1300 > Chris Packham wrote: > >> From: Kalyan Kinthada >> >> The Armada-370 based SoCs

Re: [PATCHv4 1/1] mtd: nand: pxa3xx: Set FORCE_CSX bit to ARMADA370 variants

On 22 December 2017 at 12:53, Miquel RAYNAL wrote: > Hello Chris, > > On Fri, 22 Dec 2017 12:19:04 +1300 > Chris Packham wrote: > >> From: Kalyan Kinthada >> >> The Armada-370 based SoCs support arbitration between the NAND Flash >> interface and NOR (i.e. devbus) on the same chip select.

Re: pxa3xx_nand times out in 4.14 with JFFS2

On 17 December 2017 at 16:00, Willy Tarreau wrote: > On Sun, Dec 17, 2017 at 07:07:46PM +0100, Boris Brezillon wrote: >> > > This would guarantee that devices with factory bad blocks, >> > > (and no BBT), would be OK with this patch. >> > >> > I see. I'm fine with trying provided I

Re: pxa3xx_nand times out in 4.14 with JFFS2

On 17 December 2017 at 16:00, Willy Tarreau wrote: > On Sun, Dec 17, 2017 at 07:07:46PM +0100, Boris Brezillon wrote: >> > > This would guarantee that devices with factory bad blocks, >> > > (and no BBT), would be OK with this patch. >> > >> > I see. I'm fine with trying provided I have

Re: pxa3xx_nand times out in 4.14 with JFFS2

On 17 December 2017 at 12:00, Willy Tarreau <w...@1wt.eu> wrote: > On Sun, Dec 17, 2017 at 03:53:05PM +0100, Boris Brezillon wrote: >> On Sun, 17 Dec 2017 11:27:51 -0300 >> Ezequiel Garcia <ezequ...@vanguardiasur.com.ar> wrote: >> >> > On 17 December

Re: pxa3xx_nand times out in 4.14 with JFFS2

On 17 December 2017 at 12:00, Willy Tarreau wrote: > On Sun, Dec 17, 2017 at 03:53:05PM +0100, Boris Brezillon wrote: >> On Sun, 17 Dec 2017 11:27:51 -0300 >> Ezequiel Garcia wrote: >> >> > On 17 December 2017 at 09:05, Willy Tarreau wrote: >> > &

Re: pxa3xx_nand times out in 4.14 with JFFS2

On 17 December 2017 at 09:05, Willy Tarreau wrote: > Hello, > > I recently bought a Linksys WRT1900ACS which hosts an Armada 385 and a > NAND flash. While I could get OpenWRT to work flawlessly on it using > kernel 4.4, mainline 4.14.6 fails with a lot of such messages : > >

Re: pxa3xx_nand times out in 4.14 with JFFS2

On 17 December 2017 at 09:05, Willy Tarreau wrote: > Hello, > > I recently bought a Linksys WRT1900ACS which hosts an Armada 385 and a > NAND flash. While I could get OpenWRT to work flawlessly on it using > kernel 4.4, mainline 4.14.6 fails with a lot of such messages : > > pxa3xx-nand

Re: pxa3xx_nand times out in 4.14 with JFFS2

On 17 December 2017 at 10:17, Willy Tarreau wrote: > Hi Boris! > > On Sun, Dec 17, 2017 at 01:33:55PM +0100, Boris Brezillon wrote: >> You should have a look at this thread [1], and in case you don't want >> to read everything, > > I've read it entirely, it was very instructive! > >>

Re: pxa3xx_nand times out in 4.14 with JFFS2

On 17 December 2017 at 10:17, Willy Tarreau wrote: > Hi Boris! > > On Sun, Dec 17, 2017 at 01:33:55PM +0100, Boris Brezillon wrote: >> You should have a look at this thread [1], and in case you don't want >> to read everything, > > I've read it entirely, it was very instructive! > >> you can just

[PATCH] ARM: dts: sun7i: Use axp209.dtsi on A20-OLinuXino-Micro

This commit makes use of the axp209.dtsi file to define the AXP209 PMIC. While here, define the rails that are enabled on this board. Tested checking the regulator voltage varies according to the CPU frequency. Signed-off-by: Ezequiel Garcia <ezequ...@vanguardiasur.com.ar> --- arch/arm/bo

[PATCH] ARM: dts: sun7i: Use axp209.dtsi on A20-OLinuXino-Micro

This commit makes use of the axp209.dtsi file to define the AXP209 PMIC. While here, define the rails that are enabled on this board. Tested checking the regulator voltage varies according to the CPU frequency. Signed-off-by: Ezequiel Garcia --- arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts

Re: [PATCH 17/22] power: supply: add battery driver for AXP20X and AXP22X PMICs

On 2 January 2017 at 13:37, Quentin Schulz wrote: [...] > + > +#define AXP20X_PWR_STATUS_BAT_CHARGING BIT(2) > + > +#define AXP20X_PWR_OP_BATT_PRESENT BIT(5) > +#define AXP20X_PWR_OP_BATT_ACTIVATED BIT(3) > + > +#define AXP209_FG_PERCENT

Re: [PATCH 17/22] power: supply: add battery driver for AXP20X and AXP22X PMICs

On 2 January 2017 at 13:37, Quentin Schulz wrote: [...] > + > +#define AXP20X_PWR_STATUS_BAT_CHARGING BIT(2) > + > +#define AXP20X_PWR_OP_BATT_PRESENT BIT(5) > +#define AXP20X_PWR_OP_BATT_ACTIVATED BIT(3) > + > +#define AXP209_FG_PERCENT GENMASK(6, 0) > +#define AXP22X_FG_VALID

Re: [PATCH] mtd: spi-nor: don't include linux/mtd/cfi.h from header

On 15 September 2016 at 12:41, Arnd Bergmann wrote: > The newly added broadcom qspi driver in drivers/spi produces a build > warning when CONFIG_MTD is disabled: > > include/linux/mtd/cfi.h:76:2: #warning No CONFIG_MTD_CFI_Ix selected. No NOR > chip support can work. [-Werror=cpp]

Re: [PATCH] mtd: spi-nor: don't include linux/mtd/cfi.h from header

On 15 September 2016 at 12:41, Arnd Bergmann wrote: > The newly added broadcom qspi driver in drivers/spi produces a build > warning when CONFIG_MTD is disabled: > > include/linux/mtd/cfi.h:76:2: #warning No CONFIG_MTD_CFI_Ix selected. No NOR > chip support can work. [-Werror=cpp] > > Since

Re: Kernel stability on baytrail machines

er too. Also, do we know which CPUs are affect by this issue? and which are NOT affected :) - would be quite relevant in picking a CPU for a product. [1] https://bugzilla.kernel.org/show_bug.cgi?id=109051 -- Ezequiel Garcia, VanguardiaSur www.vanguardiasur.com.ar

Re: Kernel stability on baytrail machines

er too. Also, do we know which CPUs are affect by this issue? and which are NOT affected :) - would be quite relevant in picking a CPU for a product. [1] https://bugzilla.kernel.org/show_bug.cgi?id=109051 -- Ezequiel Garcia, VanguardiaSur www.vanguardiasur.com.ar

Re: [PATCH] mtd: Replace if and BUG with BUG_ON

Hi Amitoj, Thanks for your patch. On 28 May 2016 at 13:41, Amitoj Kaur Chawla wrote: > Replace if condition and BUG() with a BUG_ON having the conditional > expression of the if statement as argument. > We usually want commit messages that tell us *why* you are doing the

Re: [PATCH] mtd: Replace if and BUG with BUG_ON

Hi Amitoj, Thanks for your patch. On 28 May 2016 at 13:41, Amitoj Kaur Chawla wrote: > Replace if condition and BUG() with a BUG_ON having the conditional > expression of the if statement as argument. > We usually want commit messages that tell us *why* you are doing the change: what are you

Re: [PATCH v3 1/3] leds: triggers: Allow to switch the trigger to "panic" on a kernel panic

On 6 May 2016 at 06:03, Jacek Anaszewski wrote: > On 04/29/2016 09:20 AM, Jacek Anaszewski wrote: >> >> Hi Ezequiel, >> >> Thanks for the update. It's indeed reasonable to have all the >> switching infrastructure in ledtrig-panic.c. >> >> I've noticed two minor issues

Re: [PATCH v3 1/3] leds: triggers: Allow to switch the trigger to "panic" on a kernel panic

On 6 May 2016 at 06:03, Jacek Anaszewski wrote: > On 04/29/2016 09:20 AM, Jacek Anaszewski wrote: >> >> Hi Ezequiel, >> >> Thanks for the update. It's indeed reasonable to have all the >> switching infrastructure in ledtrig-panic.c. >> >> I've noticed two minor issues below. > > > Since the merge

[PATCH v3 2/3] devicetree: leds: Introduce "panic-indicator" optional property

It's desirable to specify which LEDs are to be blinked on a kernel panic. Therefore, introduce a devicetree boolean property to mark which LEDs should be treated this way, if possible. Acked-by: Rob Herring <r...@kernel.org> Signed-off-by: Ezequiel Garcia <ezequ...@vanguardias

[PATCH v3 2/3] devicetree: leds: Introduce "panic-indicator" optional property

It's desirable to specify which LEDs are to be blinked on a kernel panic. Therefore, introduce a devicetree boolean property to mark which LEDs should be treated this way, if possible. Acked-by: Rob Herring Signed-off-by: Ezequiel Garcia --- Documentation/devicetree/bindings/leds/common.txt

[PATCH v3 0/3] Extend the LED panic trigger

the blink_delay_{on, off} when the panic is notified. This results in less changes. * Changed the flag to LED_PANIC_INDICATOR, as requested by Jacek. * Changed the firmware property name to "panic-indicator", as requested by Jacek. Ezequiel Garcia (3): leds: trigger

[PATCH v3 1/3] leds: triggers: Allow to switch the trigger to "panic" on a kernel panic

This commit adds a new led_cdev flag LED_PANIC_INDICATOR, which allows to mark a specific LED to be switched to the "panic" trigger, on a kernel panic. This is useful to allow the user to assign a regular trigger to a given LED, and still blink that LED on a kernel panic. Signed-off-by

[PATCH v3 0/3] Extend the LED panic trigger

the blink_delay_{on, off} when the panic is notified. This results in less changes. * Changed the flag to LED_PANIC_INDICATOR, as requested by Jacek. * Changed the firmware property name to "panic-indicator", as requested by Jacek. Ezequiel Garcia (3): leds: trigger

[PATCH v3 1/3] leds: triggers: Allow to switch the trigger to "panic" on a kernel panic

This commit adds a new led_cdev flag LED_PANIC_INDICATOR, which allows to mark a specific LED to be switched to the "panic" trigger, on a kernel panic. This is useful to allow the user to assign a regular trigger to a given LED, and still blink that LED on a kernel panic. Signed-off-by

[PATCH v3 3/3] leds: gpio: Support the "panic-indicator" firmware property

Calling a GPIO LEDs is quite likely to work even if the kernel has paniced, so they are ideal to blink in this situation. This commit adds support for the new "panic-indicator" firmware property, allowing to mark a given LED to blink on a kernel panic. Signed-off-by: Ezequiel Gar

[PATCH v3 3/3] leds: gpio: Support the "panic-indicator" firmware property

Calling a GPIO LEDs is quite likely to work even if the kernel has paniced, so they are ideal to blink in this situation. This commit adds support for the new "panic-indicator" firmware property, allowing to mark a given LED to blink on a kernel panic. Signed-off-by: Ezequ

Re: [PATCH 1/5] leds: triggers: Allow to switch the trigger to "panic" on a kernel panic

On 26 April 2016 at 04:15, Jacek Anaszewski <j.anaszew...@samsung.com> wrote: > Hi Ezequiel, > > On 04/25/2016 06:27 PM, Ezequiel Garcia wrote: >> >> On 25 April 2016 at 03:56, Jacek Anaszewski <j.anaszew...@samsung.com> >> wrote: >>>

Re: [PATCH 1/5] leds: triggers: Allow to switch the trigger to "panic" on a kernel panic

On 26 April 2016 at 04:15, Jacek Anaszewski wrote: > Hi Ezequiel, > > On 04/25/2016 06:27 PM, Ezequiel Garcia wrote: >> >> On 25 April 2016 at 03:56, Jacek Anaszewski >> wrote: >>> >>> On 04/24/2016 11:29 AM, Pavel Machek wrote: >>>>

Re: [PATCH 1/5] leds: triggers: Allow to switch the trigger to "panic" on a kernel panic

On 25 April 2016 at 03:56, Jacek Anaszewski <j.anaszew...@samsung.com> wrote: > On 04/24/2016 11:29 AM, Pavel Machek wrote: >> >> On Sun 2016-04-24 11:25:51, Pavel Machek wrote: >>> >>> On Mon 2016-04-04 17:22:02, Ezequiel Garcia wrote: >>

Re: [PATCH 1/5] leds: triggers: Allow to switch the trigger to "panic" on a kernel panic

On 25 April 2016 at 03:56, Jacek Anaszewski wrote: > On 04/24/2016 11:29 AM, Pavel Machek wrote: >> >> On Sun 2016-04-24 11:25:51, Pavel Machek wrote: >>> >>> On Mon 2016-04-04 17:22:02, Ezequiel Garcia wrote: >>>> >>>> This commit adds

Re: [PATCH v2 3/3] leds: gpio: Support the "panic-indicator" firmware property

Hi Jacek, On 14 April 2016 at 05:57, Jacek Anaszewski wrote: > Hi Ezequiel, > > It would be good to update also leds-gpio bindings, > of course in a separate patch: > > Documentation/devicetree/bindings/leds/leds-gpio.txt > Yes, you are right. I will send a new series

Re: [PATCH v2 3/3] leds: gpio: Support the "panic-indicator" firmware property

Hi Jacek, On 14 April 2016 at 05:57, Jacek Anaszewski wrote: > Hi Ezequiel, > > It would be good to update also leds-gpio bindings, > of course in a separate patch: > > Documentation/devicetree/bindings/leds/leds-gpio.txt > Yes, you are right. I will send a new series adding this. Thanks, --

[PATCH v2 3/3] leds: gpio: Support the "panic-indicator" firmware property

Calling a GPIO LEDs is quite likely to work even if the kernel has paniced, so they are ideal to blink in this situation. This commit adds support for the new "panic-indicator" firmware property, allowing to mark a given LED to blink on a kernel panic. Signed-off-by: Ezequiel Gar

[PATCH v2 3/3] leds: gpio: Support the "panic-indicator" firmware property

Calling a GPIO LEDs is quite likely to work even if the kernel has paniced, so they are ideal to blink in this situation. This commit adds support for the new "panic-indicator" firmware property, allowing to mark a given LED to blink on a kernel panic. Signed-off-by: Ezequiel Garcia --

[PATCH v2 1/3] leds: triggers: Allow to switch the trigger to "panic" on a kernel panic

This commit adds a new led_cdev flag LED_PANIC_INDICATOR, which allows to mark a specific LED to be switched to the "panic" trigger, on a kernel panic. This is useful to allow the user to assign a regular trigger to a given LED, and still blink that LED on a kernel panic. Signed-off-by

[PATCH v2 2/3] devicetree: leds: Introduce "panic-indicator" optional property

It's desirable to specify which LEDs are to be blinked on a kernel panic. Therefore, introduce a devicetree boolean property to mark which LEDs should be treated this way, if possible. Signed-off-by: Ezequiel Garcia <ezequ...@vanguardiasur.com.ar> --- Documentation/devicetree/binding

[PATCH v2 0/3] Extend the LED panic trigger

d the flag to LED_PANIC_INDICATOR, as requested by Jacek. * Changed the firmware property name to "panic-indicator", as requested by Jacek. Ezequiel Garcia (3): leds: triggers: Allow to switch the trigger to "panic" on a kernel panic devicetree: leds: Introduce "panic-indica

[PATCH v2 1/3] leds: triggers: Allow to switch the trigger to "panic" on a kernel panic

This commit adds a new led_cdev flag LED_PANIC_INDICATOR, which allows to mark a specific LED to be switched to the "panic" trigger, on a kernel panic. This is useful to allow the user to assign a regular trigger to a given LED, and still blink that LED on a kernel panic. Signed-off-by

[PATCH v2 2/3] devicetree: leds: Introduce "panic-indicator" optional property

It's desirable to specify which LEDs are to be blinked on a kernel panic. Therefore, introduce a devicetree boolean property to mark which LEDs should be treated this way, if possible. Signed-off-by: Ezequiel Garcia --- Documentation/devicetree/bindings/leds/common.txt | 3 +++ 1 file changed

[PATCH v2 0/3] Extend the LED panic trigger

d the flag to LED_PANIC_INDICATOR, as requested by Jacek. * Changed the firmware property name to "panic-indicator", as requested by Jacek. Ezequiel Garcia (3): leds: triggers: Allow to switch the trigger to "panic" on a kernel panic devicetree: leds: Introduce "panic-indica

Re: [PATCH 10/12] mtd: nand: pxa3xx: rely on generic DT parsing done in nand_scan_ident()

llon <boris.brezil...@free-electrons.com> Acked-by: Ezequiel Garcia <ezequ...@vanguardiasur.com.ar> Thanks, > --- > drivers/mtd/nand/pxa3xx_nand.c | 28 +++- > 1 file changed, 11 insertions(+), 17 deletions(-) > > diff --git a/drivers/mtd/nand/p

Re: [PATCH 10/12] mtd: nand: pxa3xx: rely on generic DT parsing done in nand_scan_ident()

Brezillon Acked-by: Ezequiel Garcia Thanks, > --- > drivers/mtd/nand/pxa3xx_nand.c | 28 +++- > 1 file changed, 11 insertions(+), 17 deletions(-) > > diff --git a/drivers/mtd/nand/pxa3xx_nand.c b/drivers/mtd/nand/pxa3xx_nand.c > index d650885..38d

Re: [PATCH 4/5] devicetree: leds: Introduce "panic-blink" optional property

On 6 April 2016 at 12:12, Rob Herring <r...@kernel.org> wrote: > On Mon, Apr 4, 2016 at 3:22 PM, Ezequiel Garcia > <ezequ...@vanguardiasur.com.ar> wrote: >> It's desirable to specify which LEDs are to be blinked on a kernel >> panic. Therefore, introduce a devic

Re: [PATCH 4/5] devicetree: leds: Introduce "panic-blink" optional property

On 6 April 2016 at 12:12, Rob Herring wrote: > On Mon, Apr 4, 2016 at 3:22 PM, Ezequiel Garcia > wrote: >> It's desirable to specify which LEDs are to be blinked on a kernel >> panic. Therefore, introduce a devicetree boolean property to mark >> which LEDs sh

Re: [PATCH 4/5] devicetree: leds: Introduce "panic-blink" optional property

On 5 April 2016 at 18:37, Jacek Anaszewski <jacek.anaszew...@gmail.com> wrote: > Hi Ezequiel, > > On 04/04/2016 10:22 PM, Ezequiel Garcia wrote: >> >> It's desirable to specify which LEDs are to be blinked on a kernel >> panic. Therefore, introduce a devicetree

Re: [PATCH 4/5] devicetree: leds: Introduce "panic-blink" optional property

On 5 April 2016 at 18:37, Jacek Anaszewski wrote: > Hi Ezequiel, > > On 04/04/2016 10:22 PM, Ezequiel Garcia wrote: >> >> It's desirable to specify which LEDs are to be blinked on a kernel >> panic. Therefore, introduce a devicetree boolean property to mark >

Re: [PATCH 2/5] leds: triggers: Add a led_trigger_event_nosleep API

On 5 April 2016 at 18:36, Jacek Anaszewski <jacek.anaszew...@gmail.com> wrote: > Hi Ezequiel, > > > On 04/04/2016 10:22 PM, Ezequiel Garcia wrote: >> >> Now that we can mark any LED (even those in use by delayed blink >> triggers) to trigger on a ker

Re: [PATCH 2/5] leds: triggers: Add a led_trigger_event_nosleep API

On 5 April 2016 at 18:36, Jacek Anaszewski wrote: > Hi Ezequiel, > > > On 04/04/2016 10:22 PM, Ezequiel Garcia wrote: >> >> Now that we can mark any LED (even those in use by delayed blink >> triggers) to trigger on a kernel panic, let's introduce a no

[PATCH 2/5] leds: triggers: Add a led_trigger_event_nosleep API

blink trigger. This will be used by the panic LED trigger. Signed-off-by: Ezequiel Garcia <ezequ...@vanguardiasur.com.ar> --- drivers/leds/led-triggers.c | 26 ++ include/linux/leds.h| 4 2 files changed, 26 insertions(+), 4 deletions(-) diff --git a/d

[PATCH 2/5] leds: triggers: Add a led_trigger_event_nosleep API

blink trigger. This will be used by the panic LED trigger. Signed-off-by: Ezequiel Garcia --- drivers/leds/led-triggers.c | 26 ++ include/linux/leds.h| 4 2 files changed, 26 insertions(+), 4 deletions(-) diff --git a/drivers/leds/led-triggers.c b/drivers

[PATCH 1/5] leds: triggers: Allow to switch the trigger to "panic" on a kernel panic

This commit adds a new led_cdev flag LED_BLINK_AT_PANIC, which allows to mark a specific LED to be switched to the "panic" trigger, on a kernel panic. This is useful to allow the user to assign a regular trigger to a given LED, and still blink that LED on a kernel panic. Signed-off-by

[PATCH 1/5] leds: triggers: Allow to switch the trigger to "panic" on a kernel panic

This commit adds a new led_cdev flag LED_BLINK_AT_PANIC, which allows to mark a specific LED to be switched to the "panic" trigger, on a kernel panic. This is useful to allow the user to assign a regular trigger to a given LED, and still blink that LED on a kernel panic. Signed-off-by

[PATCH 5/5] leds: gpio: Support the panic-blink firmware property

GPIO LEDs are relatively cheap, and so are ideal to blink on a kernel panic. This commit adds support for the new "panic-blink" firmware property, allowing to mark a given LED to blink on a kernel panic. Signed-off-by: Ezequiel Garcia <ezequ...@vanguardiasur.com.ar> --- drivers/

[PATCH 0/5] Extend the LED panic trigger

leds-gpio driver. Feedback and other ideas on how to implement this are most welcomed. Ezequiel Garcia (5): leds: triggers: Allow to switch the trigger to "panic" on a kernel panic leds: triggers: Add a led_trigger_event_nosleep API leds: trigger: panic: Use led_trigger_event_

[PATCH 5/5] leds: gpio: Support the panic-blink firmware property

GPIO LEDs are relatively cheap, and so are ideal to blink on a kernel panic. This commit adds support for the new "panic-blink" firmware property, allowing to mark a given LED to blink on a kernel panic. Signed-off-by: Ezequiel Garcia --- drivers/leds/leds-gpio.c | 4 include/li

[PATCH 0/5] Extend the LED panic trigger

leds-gpio driver. Feedback and other ideas on how to implement this are most welcomed. Ezequiel Garcia (5): leds: triggers: Allow to switch the trigger to "panic" on a kernel panic leds: triggers: Add a led_trigger_event_nosleep API leds: trigger: panic: Use led_trigger_event_

[PATCH 3/5] leds: trigger: panic: Use led_trigger_event_nosleep

Calling led_trigger_event may schedule a delayed LED set, if the LED was being used by a delayed blink trigger when the kernel paniced. Therefore, we must use led_trigger_event_nosleep to override this situation, and set the LED unconditionally. Signed-off-by: Ezequiel Garcia <ez

[PATCH 4/5] devicetree: leds: Introduce "panic-blink" optional property

It's desirable to specify which LEDs are to be blinked on a kernel panic. Therefore, introduce a devicetree boolean property to mark which LEDs should be treated this way. Signed-off-by: Ezequiel Garcia <ezequ...@vanguardiasur.com.ar> --- Documentation/devicetree/bindings/leds/common.t

[PATCH 3/5] leds: trigger: panic: Use led_trigger_event_nosleep

Calling led_trigger_event may schedule a delayed LED set, if the LED was being used by a delayed blink trigger when the kernel paniced. Therefore, we must use led_trigger_event_nosleep to override this situation, and set the LED unconditionally. Signed-off-by: Ezequiel Garcia --- drivers/leds

[PATCH 4/5] devicetree: leds: Introduce "panic-blink" optional property

It's desirable to specify which LEDs are to be blinked on a kernel panic. Therefore, introduce a devicetree boolean property to mark which LEDs should be treated this way. Signed-off-by: Ezequiel Garcia --- Documentation/devicetree/bindings/leds/common.txt | 2 ++ 1 file changed, 2 insertions

Re: [PATCH 1/3] leds: trigger: Introduce a kernel panic LED trigger

atic inline int led_get_brightness(struct led_classdev *led_cdev) return led_cdev->brightness; } +void led_trigger_set_at_panic(struct led_classdev *led_cdev, const char *name); void led_init_core(struct led_classdev *led_cdev); void led_stop_software_blink(struct led_classdev *led

Re: [PATCH 1/3] leds: trigger: Introduce a kernel panic LED trigger

atic inline int led_get_brightness(struct led_classdev *led_cdev) return led_cdev->brightness; } +void led_trigger_set_at_panic(struct led_classdev *led_cdev, const char *name); void led_init_core(struct led_classdev *led_cdev); void led_stop_software_blink(struct led_classdev *led

Re: [PATCH 00/11] mtd: nand_bbt: introduce independent nand BBT

Hello, On 13 March 2016 at 23:47, Peter Pan wrote: > Sorry for send the v3 out late. I went through a busy time in the past > two month. > > Currently nand_bbt.c is tied with struct nand_chip, and it makes other > NAND family chips hard to use nand_bbt.c. Maybe it's the

Re: [PATCH 00/11] mtd: nand_bbt: introduce independent nand BBT

Hello, On 13 March 2016 at 23:47, Peter Pan wrote: > Sorry for send the v3 out late. I went through a busy time in the past > two month. > > Currently nand_bbt.c is tied with struct nand_chip, and it makes other > NAND family chips hard to use nand_bbt.c. Maybe it's the reason why > onenand has

Re: [PATCH] clocksource/drivers/pistachio: Correct output format of PTR_ERR()

On 22 Mar 01:42 AM, Vladimir Zapolskiy wrote: > Use signed integer output in the pr_err() string format, here > PTR_ERR() value is negative and it should be reported in human > readable way. > > Signed-off-by: Vladimir Zapolskiy <v...@mleia.com> Acked-by: E

Re: [PATCH] clocksource/drivers/pistachio: Correct output format of PTR_ERR()

On 22 Mar 01:42 AM, Vladimir Zapolskiy wrote: > Use signed integer output in the pr_err() string format, here > PTR_ERR() value is negative and it should be reported in human > readable way. > > Signed-off-by: Vladimir Zapolskiy Acked-by: Ezequiel Garcia Thanks for the fi

Re: [RESEND PATCH v7] mtd: spi-nor: add hisilicon spi-nor flash controller driver

Hi Jiancheng, On 26 February 2016 at 05:11, Jiancheng Xue wrote: [..] > diff --git a/drivers/mtd/spi-nor/Kconfig b/drivers/mtd/spi-nor/Kconfig > index 0dc9275..c86d7cf 100644 > --- a/drivers/mtd/spi-nor/Kconfig > +++ b/drivers/mtd/spi-nor/Kconfig > @@ -37,6 +37,12 @@

Re: [RESEND PATCH v7] mtd: spi-nor: add hisilicon spi-nor flash controller driver

Hi Jiancheng, On 26 February 2016 at 05:11, Jiancheng Xue wrote: [..] > diff --git a/drivers/mtd/spi-nor/Kconfig b/drivers/mtd/spi-nor/Kconfig > index 0dc9275..c86d7cf 100644 > --- a/drivers/mtd/spi-nor/Kconfig > +++ b/drivers/mtd/spi-nor/Kconfig > @@ -37,6 +37,12 @@ config SPI_FSL_QUADSPI >

Re: [PATCH v2 7/8] mtd: spi-nor: add TB (Top/Bottom) protect support

Hi Brian, On 29 January 2016 at 16:25, Brian Norris wrote: > Some flash support a bit in the status register that inverts protection > so that it applies to the bottom of the flash, not the top. This yields > additions to the protection range table, as noted in the

Re: [PATCH v2 7/8] mtd: spi-nor: add TB (Top/Bottom) protect support

Hi Brian, On 29 January 2016 at 16:25, Brian Norris wrote: > Some flash support a bit in the status register that inverts protection > so that it applies to the bottom of the flash, not the top. This yields > additions to the protection range table, as noted in the comments. > > Because this

Re: [PATCH v2 6/8] mtd: spi-nor: add SPI_NOR_HAS_LOCK flag

ike SFDP. So make > a new flag for it. > > Signed-off-by: Brian Norris <computersforpe...@gmail.com> > Reviewed-by: Ezequiel Garcia <ezequ...@vanguardiasur.com.ar> > --- > v2: no change > > drivers/mtd/spi-nor/spi-nor.c | 7 +-- > 1 file changed, 5 insert

Re: [PATCH v2 6/8] mtd: spi-nor: add SPI_NOR_HAS_LOCK flag

for it. > > Signed-off-by: Brian Norris > Reviewed-by: Ezequiel Garcia > --- > v2: no change > > drivers/mtd/spi-nor/spi-nor.c | 7 +-- > 1 file changed, 5 insertions(+), 2 deletions(-) > > diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor

Re: [PATCH] mtd: nand: pxa3xx_nand: fix dmaengine initialization

On 27 February 2016 at 07:45, Robert Jarzmik <robert.jarz...@free.fr> wrote: > Ezequiel Garcia <ezequ...@vanguardiasur.com.ar> writes: > >> On 12 February 2016 at 19:29, Robert Jarzmik <robert.jarz...@free.fr> wrote: >>> When the driver is ini

Re: [PATCH] mtd: nand: pxa3xx_nand: fix dmaengine initialization

On 27 February 2016 at 07:45, Robert Jarzmik wrote: > Ezequiel Garcia writes: > >> On 12 February 2016 at 19:29, Robert Jarzmik wrote: >>> When the driver is initialized in a pure device-tree platform, the >>> driver's probe fails allocating the dma channel :

Re: [PATCH v2 0/8] mtd: spi-nor: locking fixes and updates

pending badly-written shell test script. Requires latest mtd-utils > (flash_lock / flash_unlock). > Thanks for the cool script. I've tested it on Armada XP GP board, which has a n25q128a13 flash. Tests passed, the results are attached. Tested-by: Ezequiel Garcia <ezequ...@vanguardiasur.com.ar&

Re: [PATCH v2 0/8] mtd: spi-nor: locking fixes and updates

pending badly-written shell test script. Requires latest mtd-utils > (flash_lock / flash_unlock). > Thanks for the cool script. I've tested it on Armada XP GP board, which has a n25q128a13 flash. Tests passed, the results are attached. Tested-by: Ezequiel Garcia -- Ezequiel Garcia, VanguardiaSur

Re: [PATCH] mtd: nand: pxa3xx_nand: fix dmaengine initialization

On 12 February 2016 at 19:29, Robert Jarzmik wrote: > When the driver is initialized in a pure device-tree platform, the > driver's probe fails allocating the dma channel : > [ 525.624435] pxa3xx-nand 4310.nand: no resource defined for data DMA > [ 525.632088]

Re: [PATCH] mtd: nand: pxa3xx_nand: fix dmaengine initialization

On 12 February 2016 at 19:29, Robert Jarzmik wrote: > When the driver is initialized in a pure device-tree platform, the > driver's probe fails allocating the dma channel : > [ 525.624435] pxa3xx-nand 4310.nand: no resource defined for data DMA > [ 525.632088] pxa3xx-nand 4310.nand:

Re: [PATCH v6] mtd: spi-nor: add hisilicon spi-nor flash controller driver

On 4 February 2016 at 23:25, Jiancheng Xue wrote: > Add hisilicon spi-nor flash controller driver > > Signed-off-by: Jiancheng Xue > Acked-by: Rob Herring > --- > change log > v6: > Based on v4.5-rc2 > Fixed issues pointed by Ezequiel Garcia. > v5: > Fixed

Re: [PATCH v6] mtd: spi-nor: add hisilicon spi-nor flash controller driver

; Based on v4.5-rc2 > Fixed issues pointed by Ezequiel Garcia. > v5: > Fixed a compile error. > v4: > Rebased to v4.5-rc1 > v3: > Added a compatible string "hisilicon,hi3519-sfc". > v2: > Fixed some compiling warings. > > .../devicetree/bindings/spi

Re: [PATCH v2] mtd: nand: pxa3xx_nand: add register access debug

820, 0x0048) [ 99.910037] pxa3xx-nand f10d.nand: pxa3xx_nand_irq():793 nand_readl(0x0014): 0x2 Maybe it would look clearer with: [ 99.910037] pxa3xx-nand f10d.nand: pxa3xx_nand_irq():793 nand_readl(0x0014) = 0x2 But if you feel it's just bikeshedding then: Acked-by: Ezequiel Garcia -- Ezequiel Garcia, VanguardiaSur www.vanguardiasur.com.ar

Re: [PATCH v5] mtd: spi-nor: add hisilicon spi-nor flash controller driver

; + ret = mtd_device_register(mtd, parts, nr_parts); How about just mtd_device_register(mtd, 0, NULL) ? > + if (ret) > + goto fail; > + > + i++; > + host->num_chip++; > + if (i == HIFMC_MAX_CHIP_NUM) Maybe a warning here to let the user know about this? > + break; > + } > + > + return 0; > + > +fail: > + for (i = 0; i < host->num_chip; i++) > + mtd_device_unregister(>nor[i].mtd); > + > + clk_disable_unprepare(host->clk); > + mutex_destroy(>lock); > + > + return ret; > +} > + > +static int hisi_spi_nor_remove(struct platform_device *pdev) > +{ > + struct hifmc_host *host = platform_get_drvdata(pdev); > + int i; > + > + for (i = 0; i < host->num_chip; i++) > + mtd_device_unregister(>nor[i].mtd); > + > + clk_disable_unprepare(host->clk); > + mutex_destroy(>lock); > + > + return 0; > +} > + > +static const struct of_device_id hisi_spi_nor_dt_ids[] = { > + { .compatible = "hisilicon,hisi-sfc"}, This one is fine. > + { .compatible = "hisilicon,hi3519-sfc"}, This makes no sense. The idea about this generic and specific compatible strings is to leave the door open for future quirks or different implementations for slightly different hardware. So, you currently will use a devicetree like this: flash@addr { compatible = "hisilicon,hi3519-sfc", "hisilicon,hisi-sfc"; }; And the driver currently need only match "hisilicon,hisi-sfc", since you it doesn't currently distinguish between specific SoCs. In the future, let's imagine that you find an errata in some hypothetical SoC hi3520. In that case, you can add a new compatible to your binding so your devicetree will look like: flash@addr { compatible = "hisilicon,hi3520-sfc", "hisilicon,hisi-sfc"; }; And the driver will somehow distinguish betwen the two compatibles and apply a quirk on the new one. Does it make sense? > + { /* sentinel */ } > +}; > +MODULE_DEVICE_TABLE(of, hisi_spi_nor_dt_ids); > + > +static struct platform_driver hisi_spi_nor_driver = { > + .driver = { > + .name = "hisi-sfc", > + .of_match_table = hisi_spi_nor_dt_ids, > + }, > + .probe = hisi_spi_nor_probe, > + .remove = hisi_spi_nor_remove, > +}; > +module_platform_driver(hisi_spi_nor_driver); > + > +MODULE_LICENSE("GPL"); > +MODULE_DESCRIPTION("HiSilicon SPI Nor Flash Controller Driver"); > -- > 1.9.1 > -- Ezequiel Garcia, VanguardiaSur www.vanguardiasur.com.ar

Re: [PATCH 4/8] mtd: spi-nor: disallow further writes to SR if WP# is low

On 28 January 2016 at 16:48, Brian Norris wrote: > On Thu, Jan 28, 2016 at 04:24:50PM -0300, Ezequiel Garcia wrote: >> On 28 January 2016 at 14:59, Brian Norris >> wrote: >> > So, maybe we want to clear SR_SRWD only when we unlock the *entire* >> > flash?

Re: [PATCH v2] mtd: nand: pxa3xx_nand: add register access debug

d: pxa3xx_nand_irq():863 nand_writel(0x820, 0x0048) [ 99.910037] pxa3xx-nand f10d.nand: pxa3xx_nand_irq():793 nand_readl(0x0014): 0x2 Maybe it would look clearer with: [ 99.910037] pxa3xx-nand f10d.nand: pxa3xx_nand_irq():793 nand_readl(0x0014) = 0x2 But if you feel it's just bikeshedding then: Acked-by: Ezequiel Garcia <ezequ...@vanguardiasur.com.ar> -- Ezequiel Garcia, VanguardiaSur www.vanguardiasur.com.ar

<    3   4   5   6   7   8   9   10   11   12   >