Re: [PATCH v2 2/2] ARM: EXYNOS: fix double of_node_put() on error path

On 31.07.2015 09:09, Vladimir Zapolskiy wrote: > The change removes the second of_node_put(), if > for_each_compatible_node() body execution is not terminated. This > prevents from object refcounter overflow over zero in OF_DYNAMIC > build. > > Signed-off-by: Vladimir Zapolskiy > --- > Changes fr

Re: [PATCH v2 1/2] ARM: EXYNOS: pd: fix potentian kfree() of ro memory

On 31.07.2015 09:09, Vladimir Zapolskiy wrote: > The change fixes a bug introduced by 2be2a3ff42a5, memory allocated > by kstrdup_const() must be always deallocated with kfree_const(), > otherwise there is a risk of kfree'ing ro memory. > > Signed-off-by: Vladimir Zapolskiy > Cc: > Fixes: 2be2a3

Re: [PATCH v2] drm/exynos: clear channels only when iommu is enabled

On 28.07.2015 17:51, Joonyoung Shim wrote: > This is simplest solution about reported problem[1]. It's no problem to > clear channel only when iommu is enabled, if we consider that we cannot > recognize iommu errors when iommu is disabled and it have been valid > until now. But this cannot be nice

[PATCH v2 0/2] pd: fix resource deallocation on error path

The first change fixes a bug introduced by 2be2a3ff42a5, memory allocated by kstrdup_const() must be always deallocated with kfree_const(), otherwise there is a risk of kfree'ing ro memory. The second change removes double of_node_put(), if for_each_compatible_node() body execution is not terminat

[PATCH v2 2/2] ARM: EXYNOS: fix double of_node_put() on error path

The change removes the second of_node_put(), if for_each_compatible_node() body execution is not terminated. This prevents from object refcounter overflow over zero in OF_DYNAMIC build. Signed-off-by: Vladimir Zapolskiy --- Changes from v1 to v2: * split a single change v1 into two arch/arm/mac

[PATCH v2 1/2] ARM: EXYNOS: pd: fix potentian kfree() of ro memory

The change fixes a bug introduced by 2be2a3ff42a5, memory allocated by kstrdup_const() must be always deallocated with kfree_const(), otherwise there is a risk of kfree'ing ro memory. Signed-off-by: Vladimir Zapolskiy Cc: Fixes: 2be2a3ff42a5 ("ARM: EXYNOS: register power domain driver from core

Re: [PATCH v4] ARM: dts: exynos5422-odroidxu3: Hook up PWM and use it for LEDs

Hi Peter, On 14/05/2015, Peter Chubb wrote: > > PWM output wasn't working because it wasn't hooked up to its pincontrol. > This patch: >- hooks up PWM to its pincontrol, and documents what > the outputs are on the XU3 >- switches the LEDs that are on PWM outputs to use PWM > rat

Re: [PATCH v2 2/7] cpufreq: opp: fix handling of turbo modes

On 07/27/15 20:47, Bartlomiej Zolnierkiewicz wrote: > On Monday, July 27, 2015 05:06:41 PM Viresh Kumar wrote: >> On 27-07-15, 13:14, Bartlomiej Zolnierkiewicz wrote: >>> Sorry but you don't seem to understand the issue. >> >> :) >> >> No, I did. I understand that if someone uses opp bindings today

Re: [RFC PATCH 0/3] clocksource: exynos_mct: allow mct to use 64-bit counter from coprocessor

On 07/29/15 08:29, Doug Anderson wrote: > Hi, > Hi, > On Tue, Jul 28, 2015 at 9:20 AM, Alexey Klimov wrote: >> Hi Doug, >> >> On Tue, Jul 28, 2015 at 6:24 PM, Doug Anderson wrote: >>> Alexey, >>> >>> On Mon, Jul 27, 2015 at 2:28 PM, Alexey Klimov >>> wrote: Hi all, year(s) ago

Re: [PATCH] ARM: dts: Add CPU cooling binding for Exynos3250-based Rinato/Monk board

On 07/29/15 15:35, Chanwoo Choi wrote: > Dear Kukjin, > > Please pick this patch because exynos3250-cpufreq patch-set > was already merged on linux-samsung.git. > Applied, thanks. - Kukjin > Thanks, > Chanwoo Choi > > On 07/08/2015 09:19 AM, Krzysztof Kozlowski wrote: >> On 07.07.2015 23:40, K

Re: [PATCH 08/11] MTD: m25p80: Add option to limit SPI transfer size.

On Thursday, July 30, 2015 at 02:18:09 PM, Michal Suchanek wrote: > On 30 July 2015 at 13:24, Marek Vasut wrote: > > On Monday, July 27, 2015 at 10:43:05 PM, Michal Suchanek wrote: > >> On 27 July 2015 at 19:43, Marek Vasut wrote: > >> > On Monday, July 27, 2015 at 11:46:25 AM, Michal Suchanek wr

Re: [PATCH 08/11] MTD: m25p80: Add option to limit SPI transfer size.

On 30 July 2015 at 13:24, Marek Vasut wrote: > On Monday, July 27, 2015 at 10:43:05 PM, Michal Suchanek wrote: >> On 27 July 2015 at 19:43, Marek Vasut wrote: >> > On Monday, July 27, 2015 at 11:46:25 AM, Michal Suchanek wrote: >> >> On 24 July 2015 at 10:34, Marek Vasut wrote: >> >> > On Thursd

Re: [PATCH 08/11] MTD: m25p80: Add option to limit SPI transfer size.

On Monday, July 27, 2015 at 10:43:05 PM, Michal Suchanek wrote: > On 27 July 2015 at 19:43, Marek Vasut wrote: > > On Monday, July 27, 2015 at 11:46:25 AM, Michal Suchanek wrote: > >> On 24 July 2015 at 10:34, Marek Vasut wrote: > >> > On Thursday, July 23, 2015 at 07:03:47 PM, Michal Suchanek wr

Re: [RFC PATCH 2/2] dt: spi: s3c64xx: add compatible to controller-data

On Thu, Jul 30, 2015 at 10:24:37AM +0200, Michal Suchanek wrote: > So my suggestion is to > 1) search of ofpart subnode in mtd node. If present read address and > reg from it and search partitions as subnodes of the ofpart node. In > this case unknown nodes can cause error. > 2) failing that iss

Re: [RFC PATCH 2/2] dt: spi: s3c64xx: add compatible to controller-data

On Thu, Jul 30, 2015 at 09:50:51AM +0200, Boris Brezillon wrote: > Since you have to patch your DTs anyway, how about putting your > partitions in a subnode and patch the ofpart code to parse this subnode > if it is present (see the following patch). This is the best idea, yes - if we're changing

[PATCH v3 1/4] mfd: max77686: Don't suggest in binding to use a deprecated property

The regulator-compatible property from the regulator DT binding was deprecated. But the max77686 DT binding doc still suggest to use it instead of the regulator node name's which is the correct approach. Signed-off-by: Javier Martinez Canillas Reviewed-by: Krzysztof Kozlowski --- Changes in v3

[PATCH v3 2/4] mfd: max77686: Use a generic name for the PMIC node in the example

The ePAPR standard says that: "the name of a node should be somewhat generic, reflecting the function of the device and not its precise programming model." So, change the max77686 binding document example to use a generic node name instead of using the chip's name. Suggested-by: Sergei Shtylyov

[PATCH v3 3/4] mfd: Add DT binding for Maxim MAX77802 IC

The MAX77802 is a chip that contains regulators, 2 32kHz clocks, a RTC and an I2C interface to program the individual components. The are already DT bindings for the regulators and clocks and these reference to a bindings/mfd/max77802.txt file, that didn't exist, for the details about the PMIC. S

[PATCH v3 4/4] mfd: max77686: Split out regulator part from the DT binding

The Maxim MAX77686 PMIC is a multi-function device with regulators, clocks and a RTC. The DT bindings for the clocks are in a separate file but the bindings for the regulators are inside the mfd part. To make it consistent with the clocks portion of the binding and because is more natural to look

[PATCH v3 0/4] mfd: Improve DT binding docs for max77686 and max77802

Hello Lee, This series contains some improvements for the Device Tree bindings of the Maxim MAX77686 and MAX77802 multi-function devices. This is the third version of the series that addresses issues pointed out by Sergei Shtylyov and you. Patch #1 changes the max77686 binding to not suggest usi

Re: [RFC PATCH 2/2] dt: spi: s3c64xx: add compatible to controller-data

On 29 July 2015 at 20:40, Mark Brown wrote: > On Wed, Jul 29, 2015 at 08:21:34PM +0200, Michal Suchanek wrote: >> On 29 July 2015 at 19:16, Mark Brown wrote: > >> >> It will not break anything. It will just spam dmesg. > >> > I'm confused - if all this change does is to spam dmesg then what's the

Re: [RFC PATCH 2/2] dt: spi: s3c64xx: add compatible to controller-data

Hi Michal, On Wed, 29 Jul 2015 12:19:57 +0200 Michal Suchanek wrote: > The controller-data subnode has no compatible. This can lead to other > drivers getting confused by it. Add a compatible to make devicetreee > unambiguous. > > Signed-off-by: Michal Suchanek > --- > Documentation/devicetre