There is no need to include "plat/map-base.h" in ipp driver. Remove
this and enable this driver for multi-platform.
However gsc driver is not multiplatform compliant yet, so make the
compilation conditional upon !ARCH_MULTIPLATFORM.
Signed-off-by: Tushar Behera
---
Changes for V2:
* Made compila
In a multi-platform scenario, the hard-coded major/minor numbers in
serial drivers may conflict with each other. A typical scenario is
observed with amba-pl011 and samsung-uart drivers, both of these
drivers use same set of major/minor numbers. If both of these drivers
are enabled, probe of samsung
On 16 January 2014 10:33, Sachin Kamat wrote:
> Hi Tushar,
>
> On 15 January 2014 17:27, Tushar Behera wrote:
>> There is no need to include "plat/map-base.h" in ipp driver. Remove
>> this and enable this driver for multi-platform.
>>
>> Signed-off-by: Tushar Behera
>
> drivers/gpu/drm/exynos/ex
Hi Tushar,
On 15 January 2014 17:27, Tushar Behera wrote:
> There is no need to include "plat/map-base.h" in ipp driver. Remove
> this and enable this driver for multi-platform.
>
> Signed-off-by: Tushar Behera
drivers/gpu/drm/exynos/exynos_drm_gsc.c also has this header file included.
If this
Am Montag, 30. Dezember 2013, 16:10:08 schrieb Sachin Kamat:
> plat/rtc-core.h is only referenced from mach-s3c24xx. Hence
> move it there to de-populate the plat directory. While at it
> also do some cleanup of the header file.
>
> Signed-off-by: Sachin Kamat
> Cc: Heiko Stuebner
late, but as
Hi,
On Tuesday 14 January 2014 08:08 PM, Heikki Krogerus wrote:
> On Tue, Jan 07, 2014 at 06:31:52PM +0530, Kishon Vijay Abraham I wrote:
>>> In any case, having two device names to deal with does not add any
>>> more risk. These associations should always be made in the place where
>>> the phy de
Hi Heikki,
On Tuesday 14 January 2014 07:53 PM, Heikki Krogerus wrote:
> Hi Kishon,
>
> And happy new year..
Happy new year :-)
>
> On Tue, Jan 07, 2014 at 07:10:36PM +0530, Kishon Vijay Abraham I wrote:
> /**
> - * phy_get() - lookup and obtain a reference to a phy.
> + * phy_get_
On Wednesday 15 January 2014, Linus Walleij wrote:
> When I look at it, the issue also exist in e.g.
> drivers/gpio/gpio-samsung.c which can be compiled
> (like for allyesconfig) when PLAT_SAMSUNG is set.
>
> And it is also set to y for ARCH_EXYNOS... which
> doesn't have any custom GPIO header. S
CONFIG_ARCH_S3C64XX
>> > -#include
>> > -#endif
>> > +#include
>>
>> This inclusion should be protected by a check for CONFIG_ARCH_S3C24XX
>> || CONFIG_ARCH_S3C64XX. Currently generating build errors for
>> s5p64x0_defconfig, s5pc100_defconfig and s
efconfig, s5pc100_defconfig and s5pv210_defconfig on
>> next-20140115.
>
> I noticed the same problem, but I think a better solution would
> be to do the same change for s5p that Linus has done for s3c,
> which is to move the nonstandard contents of mach/gpio.h to
> mach/gpio-s
On Wed, Jan 15, 2014 at 10:01 AM, Sachin Kamat wrote:
> gpio-samsung.h header file introduced by commit 93177be0910c
> ("ARM: S3C[24|64]xx: move includes back under scope")
> is required only by S3C[24|64]xx machines. Include them conditionally
> to avoid the following build errors for other mac
There is no need to include "plat/map-base.h" in ipp driver. Remove
this and enable this driver for multi-platform.
Signed-off-by: Tushar Behera
---
drivers/gpu/drm/exynos/Kconfig |2 +-
drivers/gpu/drm/exynos/exynos_drm_ipp.c |1 -
2 files changed, 1 insertion(+), 2 deletions(-
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I meet the usb problem in Linux 3.13-rc8, in my board, the HSIC in SoC
is connect to usb4640, I have using a litter driver to reset usb4640
after boot.
In the old time, when it doesn't use common phy framework, it was work.
In board, the otg is brike(m
On 15 January 2014 15:13, zhangfei wrote:
>
>
> On 01/15/2014 05:39 PM, Sachin Kamat wrote:
>>>
>>> Thanks for the patch
>>> I just submitted one patch to fix the issue, in case you missed it.
>>
>>
>> Yes I did as I am not subscribed to mmc list.
>>
>>> Also spin_lock is required for atomic acces
d be protected by a check for CONFIG_ARCH_S3C24XX
> || CONFIG_ARCH_S3C64XX. Currently generating build errors for
> s5p64x0_defconfig, s5pc100_defconfig and s5pv210_defconfig on
> next-20140115.
>
I noticed the same problem, but I think a better solution would
be to do the same change fo
On 01/15/2014 05:39 PM, Sachin Kamat wrote:
Thanks for the patch
I just submitted one patch to fix the issue, in case you missed it.
Yes I did as I am not subscribed to mmc list.
Also spin_lock is required for atomic accessing DW_MMC_CARD_PRESENT.
Otherwise sd detect may be failed sometimes
Hi Zhangfei,
On 15 January 2014 14:11, zhangfei wrote:
> Hi, Sachin
>
>
>
>
> On 01/15/2014 04:31 PM, Sachin Kamat wrote:
>>
>> mmc_gpio_get_cd returns a negative error value upon failure.
>> However gpio_cd was initialised with the negated return value
>> of the above function. This negation res
This patch set adds use of clk_prepare/clk_unprepare as
required by generic clock framework.
Signed-off-by: Naveen Krishna Chatradhi
Reviewed-by: Tomasz Figa
---
Changes since v3:
None
drivers/crypto/s5p-sss.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers
This patch adds gating clock for SSS(Security SubSystem)
module on Exynos5250/5420.
Signed-off-by: Naveen Krishna Chatradhi
TO:
TO: Tomasz Figa
CC: Kukjin Kim
CC:
---
Changes since v3:
1. Rebased on to
https://git.kernel.org/pub/scm/linux/kernel/git/tfiga/samsung-clk.git
2. Added new ID for
This patch adds the device tree node for SSS module
found on Exynos5420 and Exynos5250
Signed-off-by: Naveen Krishna Chatradhi
Reviewed-by: Tomasz Figa
TO:
CC: Kukjin Kim
CC:
---
Changes since v3:
1. Modified the SSS clock ID as per dt-bindings for Exynos5250 in
samsung-clk.git tree.
arc
From: Naveen Krishna Ch
This patch modifies Kconfig such that ARCH_EXYNOS SoCs
which includes (Exynos4210, Exynos5250 and Exynos5420)
can also select Samsung SSS(Security SubSystem) driver.
Signed-off-by: Naveen Krishna Ch
CC: Herbert Xu
CC: David S. Miller
CC: Vladimir Zapolskiy
TO:
CC:
-
This patch adds code to validate "iv" buffer before trying to
memcpy the contents
Signed-off-by: Naveen Krishna Chatradhi
---
Changes since v3:
None
drivers/crypto/s5p-sss.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/crypto/s5p-sss.c b/drivers/crypto/s5p-ss
This patch adds new compatible and variant struct to support the SSS
module on Exynos4 (Exynos4210), Exynos5 (Exynos5420 and Exynos5250)
for which
1. AES register are at an offset of 0x200 and
2. hash interrupt is not available
Signed-off-by: Naveen Krishna Ch
CC: Herbert Xu
CC: David S. Miller
From: Naveen Krishna Ch
This patch uses the platform_get_irq() instead of the
platform_get_irq_byname(). Making feeder control interrupt
as resource "0" and hash interrupt as "1".
reasons for this change.
1. Cannot find any Arch which is currently using this driver
2. Samsung Exynos4 and 5 SoCs
This patch adds device tree support to the s5p-sss.c crypto driver.
Also, Documentation under devicetree/bindings added.
Signed-off-by: Naveen Krishna Ch
CC: Herbert Xu
CC: David S. Miller
CC: Vladimir Zapolskiy
TO:
CC:
---
Changes since v3:
None
.../devicetree/bindings/crypto/samsung-sss
ould be protected by a check for CONFIG_ARCH_S3C24XX
|| CONFIG_ARCH_S3C64XX. Currently generating build errors for
s5p64x0_defconfig, s5pc100_defconfig and s5pv210_defconfig on
next-20140115.
--
Tushar Behera
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc&quo
gpio-samsung.h header file introduced by commit 93177be0910c
("ARM: S3C[24|64]xx: move includes back under scope")
is required only by S3C[24|64]xx machines. Include them conditionally
to avoid the following build errors for other machine configurations.
drivers/gpio/gpio-samsung.c:35:31: fatal er
Hello Tomasz,
On 10 January 2014 21:28, Tomasz Figa wrote:
> Hi Naveen,
>
>
> On 10.01.2014 12:43, Naveen Krishna Chatradhi wrote:
>>
>> This patch adds gating clock for SSS(Security SubSystem)
>> module on Exynos5250.
>>
>> Signed-off-by: Naveen Krishna Chatradhi
>> ---
>> Changes since v2:
>>
Hi, Sachin
On 01/15/2014 04:31 PM, Sachin Kamat wrote:
mmc_gpio_get_cd returns a negative error value upon failure.
However gpio_cd was initialised with the negated return value
of the above function. This negation resulted in losing of the
error value thereby triggering the code to take a wro
mmc_gpio_get_cd returns a negative error value upon failure.
However gpio_cd was initialised with the negated return value
of the above function. This negation resulted in losing of the
error value thereby triggering the code to take a wrong path as
IS_ERR_VALUE(gpio_cd) now returned 0 even when mm
30 matches
Mail list logo