> I didn't explain well, There is a CFE command 'show devtree' here's the
> relevant bits (I Hope)
This is much simple than I expected.
> [CFE ]CFE> show devtree
> [/]
> | #interrupt-cells val 0x0002
> | #address-cells val 0x0002
> | #size-cells
Use devm_ioremap and devm_hwrng_register instead of ioremap and
hwrng_register. This removes unregistering and error handling code.
This patch is not tested with hardware as I don't have access to it.
Signed-off-by: PrasannaKumar Muralidharan
---
drivers/char/hw_random/pasemi-rng.c
> I will propose to use devm_ioremap_resource() instead for removing this
> hardcoded 0x100, but i cannot find any user of this driver in any dts. (And
> so cannot check that this 0x100 is given in any DT resource node)
>
> Is this normal ?
I wanted to use devm_ioremap_resource but could not fin
drivers to use new macro.
Change since v1:
Add device.h include in miscdevice.h as module_driver macro was not
available from other include files in some architectures.
Signed-off-by: PrasannaKumar Muralidharan
---
arch/arm/common/bL_switcher_dummy_if.c | 14 +-
arch/blackfin/mach-bf561
as a separate patch.
Signed-off-by: PrasannaKumar Muralidharan
---
arch/um/drivers/harddog_kern.c | 25 +
drivers/bluetooth/hci_vhci.c | 16 +---
drivers/char/bfin-otp.c| 40 +---
drivers/lightnvm/core.c| 19
Hi Boris,
On 30 October 2017 at 19:04, PrasannaKumar Muralidharan
wrote:
> Hi Boris,
>
> On 30 October 2017 at 18:33, Boris Brezillon
> wrote:
>>
>> Yep, it makes sense to have that one applied too, but this is pretty
>> much the same problem: it will confli
On 24 October 2017 at 21:14, Jarkko Sakkinen
wrote:
> On Mon, Oct 23, 2017 at 10:31:39AM -0600, Jason Gunthorpe wrote:
>> On Mon, Oct 23, 2017 at 10:07:31AM -0400, Stefan Berger wrote:
>>
>> > >-int tpm_pcr_extend(u32 chip_num, int pcr_idx, const u8 *hash)
>> > >+int tpm_pcr_extend(int pcr_idx, co
Hi Jason,
On 24 October 2017 at 21:25, Jason Gunthorpe
wrote:
> On Tue, Oct 24, 2017 at 09:21:15PM +0530, PrasannaKumar Muralidharan wrote:
>
>> Please check the RFC [1]. It does use chip id. The rfc has issues and
>> has to be fixed but still there could be users of the A
On 24 October 2017 at 21:41, Jason Gunthorpe
wrote:
> On Tue, Oct 24, 2017 at 09:37:33PM +0530, PrasannaKumar Muralidharan wrote:
>> Hi Jason,
>>
>> On 24 October 2017 at 21:25, Jason Gunthorpe
>> wrote:
>> > On Tue, Oct 24, 2017 at 09:21:15PM +05
On 24 October 2017 at 21:53, Jarkko Sakkinen
wrote:
> On Tue, Oct 24, 2017 at 09:21:15PM +0530, PrasannaKumar Muralidharan wrote:
>> On 24 October 2017 at 21:14, Jarkko Sakkinen
>> wrote:
>> > On Mon, Oct 23, 2017 at 10:31:39AM -0600, Jason Gunthorpe wrote:
>> &g
On 24 October 2017 at 23:07, Jason Gunthorpe
wrote:
> On Tue, Oct 24, 2017 at 10:02:00AM -0700, Dmitry Torokhov wrote:
>> tpm-rng is abomination that should be kicked out as soon as possible.
>> It wrecks havoc with the power management (TPM chip drivers may go
>> into suspend state, but tpm_rng d
Hi Jason,
On 24 October 2017 at 23:16, Jason Gunthorpe
wrote:
> On Tue, Oct 24, 2017 at 09:44:30PM +0530, PrasannaKumar Muralidharan wrote:
>
>> I am wondering why it is wrong. Isn't the chip id valid till it is
>> unregistered? If so the rfc is correct. Please explain,
d entropy from the TPM when it is plugged in,
> and allow access to the TPM rng via /dev/hwrng.
>
> Signed-off-by: PrasannaKumar Muralidharan
> Signed-off-by: Jason Gunthorpe
> Reviewed-by: Jason Gunthorpe
> ---
> drivers/char/hw_random/Kconfig | 13 ---
> driv
Hi Jarkko,
On 24 October 2017 at 23:52, Jarkko Sakkinen
wrote:
> On Tue, Oct 24, 2017 at 10:05:20PM +0530, PrasannaKumar Muralidharan wrote:
>> > 1. Every user in the kernel is using TPM_ANY_NUM, which means there are
>> >no other users.
>>
>> Completely
Hi Jarkko,
On 25 October 2017 at 17:25, Jarkko Sakkinen
wrote:
> Device number (the character device index) is not a stable identifier
> for a TPM chip. That is the reason why every call site passes
> TPM_ANY_NUM to tpm_chip_find_get().
>
> This commit changes the API in a way that instead a stru
Hi Jason,
On 25 October 2017 at 20:48, Jason Gunthorpe
wrote:
> On Wed, Oct 25, 2017 at 08:15:09PM +0530, PrasannaKumar Muralidharan
> wrote:
>
>> > +static int tpm_add_hwrng(struct tpm_chip *chip)
>> > +{
>> > + if (!IS_ENABLED(CONFIG_HW_RANDOM
Include linux/device.h instead of declaring struct device.
Signed-off-by: PrasannaKumar Muralidharan
---
include/linux/hw_random.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/include/linux/hw_random.h b/include/linux/hw_random.h
index bee0827..2ec9af7 100644
--- a
);
> + ret = trusted_tpm_send(tb->data, MAX_BUF_SIZE);
> if (ret < 0) {
> pr_info("trusted_key: authhmac failed (%d)\n", ret);
> return ret;
> @@ -748,7 +747,7 @@ static int getoptions(char *c, struct trusted_key_payload
> *pa
get_maintainer.pl shows Herbert as 'odd fixer' and does not show any
maintainer at all. Herbert is maintaining hw_random so mark hw_random
as maintained. This shows a maintainer for hw_random subsystem.
Signed-off-by: PrasannaKumar Muralidharan
---
MAINTAINERS | 2 +-
1 file
On 26 October 2017 at 00:41, Jarkko Sakkinen
wrote:
> On Wed, Oct 25, 2017 at 08:21:16PM +0530, PrasannaKumar Muralidharan wrote:
>> >> > 2. Moving struct tpm_rng to the TPM client is architecturally
>> >> >uacceptable.
>> >>
>> >> As t
On 26 October 2017 at 21:39, Jarkko Sakkinen
wrote:
> On Thu, Oct 26, 2017 at 07:40:49PM +0530, PrasannaKumar Muralidharan wrote:
>> Hi Jarkko,
>>
>> On 26 October 2017 at 19:24, Jarkko Sakkinen
>> wrote:
>> > Device number (the character device index) is no
Did basic check on tpm rng patch, it works fine. As it depends on this
patch this should be working fine too.
Tested-by: PrasannaKumar Muralidharan
Regards,
PrasannaKumar
Hi Jason,
On 9 November 2017 at 21:59, Jason Gunthorpe wrote:
> On Thu, Nov 09, 2017 at 09:49:33PM +0530, PrasannaKumar Muralidharan wrote:
>> Hi Jason,
>>
>> On 7 November 2017 at 21:34, Jason Gunthorpe wrote:
>> > On Tue, Nov 07, 2017 at 08:50:44AM +0530, Pr
From: Lars-Peter Clausen
Avoid sending unnecessary READ commands to the chip.
Signed-off-by: Lars-Peter Clausen
Signed-off-by: PrasannaKumar Muralidharan
---
This patch is taken from git://projects.qi-hardware.com/qi-kernel.git
branch jz-3.16. From [1] and [2] it can be seen that the patch
Hi Boris,
On 30 October 2017 at 14:04, Boris Brezillon
wrote:
> Hi PrasannaKumar,
>
> On Sat, 28 Oct 2017 13:13:51 +0530
> PrasannaKumar Muralidharan wrote:
>
>> From: Lars-Peter Clausen
>>
>> Avoid sending unnecessary READ commands to the chip.
>&g
Hi Herbert,
On 30 October 2017 at 12:22, Herbert Xu wrote:
> On Thu, Oct 26, 2017 at 07:12:08PM +0530, PrasannaKumar Muralidharan wrote:
>> Include linux/device.h instead of declaring struct device.
>>
>> Signed-off-by: PrasannaKumar Muralidharan
>
> Nack. We shoul
Hi Boris,
On 30 October 2017 at 18:33, Boris Brezillon
wrote:
> On Mon, 30 Oct 2017 18:17:50 +0530
> PrasannaKumar Muralidharan wrote:
>
>> Hi Boris,
>>
>> On 30 October 2017 at 14:04, Boris Brezillon
>> wrote:
>> > Hi PrasannaKumar,
&g
Hi Paul,
On 30 December 2017 at 19:21, Paul Cercueil wrote:
> The watchdog driver can restart the system by simply configuring the
> hardware for a timeout of 0 seconds.
>
> Signed-off-by: Paul Cercueil
> Reviewed-by: Guenter Roeck
> ---
> drivers/watchdog/jz4740_wdt.c | 9 +
> 1 file
Hi Paul,
On 30 December 2017 at 19:21, Paul Cercueil wrote:
> When the watchdog was configured for nowayout, and after the
> userspace watchdog daemon closed the dev node without sending the
> magic character, unloading this module stopped the watchdog
> hardware, which was clearly a problem.
>
>
Hi Jarkko,
On 18 January 2018 at 21:50, Jarkko Sakkinen
wrote:
> On Wed, Jan 17, 2018 at 07:43:51PM +0530, PrasannaKumar Muralidharan wrote:
>> Hi Jarkko,
>>
>> On 14 November 2017 at 20:02, Jarkko Sakkinen
>> wrote:
>> > On Sun, Nov 12, 2017 at 10:53:35
On 11 January 2018 at 20:38, Rob Herring wrote:
> On Sat, Jan 6, 2018 at 6:43 AM, PrasannaKumar Muralidharan
> wrote:
>> Hi Rob,
>>
>> On 4 January 2018 at 01:32, Rob Herring wrote:
>>> On Thu, Dec 28, 2017 at 10:29:52PM +0100, Mathieu Malaterre wrote:
>
Hi Guenter,
On 20 January 2018 at 21:20, Guenter Roeck wrote:
> On 01/19/2018 11:41 PM, PrasannaKumar Muralidharan wrote:
>>
>> Hi Paul,
>>
>> On 30 December 2017 at 19:21, Paul Cercueil wrote:
>>>
>>> When the watchdog was configured for nowayout
Hi Guenter,
On 20 January 2018 at 21:15, Guenter Roeck wrote:
> On 01/19/2018 11:31 PM, PrasannaKumar Muralidharan wrote:
>>
>> Hi Paul,
>>
>> On 30 December 2017 at 19:21, Paul Cercueil wrote:
>>>
>>> The watchdog driver can restart the system
t;> wrote:
>> > Hi Mathieu, PrasannaKumar,
>> >
>> > On 27.12.2017 13:27, Mathieu Malaterre wrote:
>> >>
>> >> From: PrasannaKumar Muralidharan > <mailto:prasannatsmku...@gmail.com>>
>> >>
>> >> This
Hi Rob,
On 4 January 2018 at 01:32, Rob Herring wrote:
> On Thu, Dec 28, 2017 at 10:29:52PM +0100, Mathieu Malaterre wrote:
>> From: PrasannaKumar Muralidharan
>>
>> This patch brings support for the JZ4780 efuse. Currently it only expose
>> a read only access to the
Hi Jarkko,
On 17 November 2017 at 19:27, Jarkko Sakkinen
wrote:
> On Fri, Nov 17, 2017 at 03:28:53PM +0200, Jarkko Sakkinen wrote:
>
> At least signed-off-by from PrassanaKumar is missing from the 2nd
> commit. I'll add it.
I had the impression that my signed-off-by will be present in this
chang
Hi Boris,
On 30 October 2017 at 14:04, Boris Brezillon
wrote:
> Hi PrasannaKumar,
>
> On Sat, 28 Oct 2017 13:13:51 +0530
> PrasannaKumar Muralidharan wrote:
>
>> From: Lars-Peter Clausen
>>
>> Avoid sending unnecessary READ commands to the chip.
>&g
Hi Jarkko,
On 14 November 2017 at 20:02, Jarkko Sakkinen
wrote:
> On Sun, Nov 12, 2017 at 10:53:35AM +0530, PrasannaKumar Muralidharan wrote:
>> Did basic check on tpm rng patch, it works fine. As it depends on this
>> patch this should be working fine too.
>>
>&g
Hi Rob,
On 11 January 2018 at 20:38, Rob Herring wrote:
> On Sat, Jan 6, 2018 at 6:43 AM, PrasannaKumar Muralidharan
> wrote:
>> Hi Rob,
>>
>> On 4 January 2018 at 01:32, Rob Herring wrote:
>>> On Thu, Dec 28, 2017 at 10:29:52PM +0100, Mathieu Malaterr
Hi James,
Thanks for reviewing this.
On 6 March 2018 at 05:38, James Hogan wrote:
> On Wed, Sep 27, 2017 at 08:45:26PM +0530, PrasannaKumar Muralidharan wrote:
>> Add initial Ingenic X1000 SoC support. Provide minimum necessary
>> information to boot kernel to an init
Hi James,
On 7 March 2018 at 20:05, James Hogan wrote:
> On Wed, Mar 07, 2018 at 07:14:49PM +0530, PrasannaKumar Muralidharan wrote:
>> > Does X1000 use a different PRID, or is it basically just a JZ4780 core
>> > with different SoC peripherals?
>>
>> Yes X1000
Hi Jiaxun,
On 7 March 2018 at 19:49, Jiaxun Yang wrote:
> 在 2018-03-07三的 19:14 +0530，PrasannaKumar Muralidharan写道：
>>
>> I used to get my code tested from Domink but I could not reach him
>> for
>> quite some time. Before buying the development board myself I would
&
On 7 March 2018 at 20:40, James Hogan wrote:
> On Wed, Mar 07, 2018 at 08:35:00PM +0530, PrasannaKumar Muralidharan wrote:
>> On 7 March 2018 at 20:05, James Hogan wrote:
>> > On Wed, Mar 07, 2018 at 07:14:49PM +0530, PrasannaKumar Muralidharan wrote:
>> >> > Do
On 7 March 2018 at 21:22, Jiaxun Yang wrote:
> 在 2018-03-07三的 20:35 +0530，PrasannaKumar Muralidharan写道：
>> Hi James,
>>
>> Seems Jiaxun is interested in the board and is willing to help.
>>
>> I have been told that Ingenic is focusing on IoT market and X1000
On 6 July 2018 at 03:15, Paul Cercueil wrote:
>
>
>> Paul,
>>
>> On 3 July 2018 at 18:02, Paul Cercueil wrote:
>>>
>>> The register area of the JZ4780 DMA core can be split into different
>>> sections for different purposes:
>>>
>>> * one set of registers is used to perform actions at the DMA
On 5 July 2018 at 23:56, Paul Cercueil wrote:
> Hi PrasannaKumar,
>
>
>> Hi Paul,
>>
>> On 3 July 2018 at 18:02, Paul Cercueil wrote:
>>>
>>> As part of the work to support various other Ingenic JZ47xx SoC
>>> versions,
>>> which don't feature the same number of DMA channels per core, we now
>>
Hi Paul,
On 3 July 2018 at 18:02, Paul Cercueil wrote:
> As part of the work to support various other Ingenic JZ47xx SoC versions,
> which don't feature the same number of DMA channels per core, we now
> deduce the number of DMA channels available from the devicetree
> compatible string.
>
> Sign
Paul,
On 3 July 2018 at 18:02, Paul Cercueil wrote:
> The register area of the JZ4780 DMA core can be split into different
> sections for different purposes:
>
> * one set of registers is used to perform actions at the DMA core level,
> that will generally affect all channels;
>
> * one set of re
> @@ -502,7 +499,7 @@ static void jz4780_dma_begin(struct jz4780_dma_chan
> *jzchan)
>
> /* Enable the channel. */
> jz4780_dma_chn_writel(jzdma, jzchan->id, JZ_DMA_REG_DCS,
> - JZ_DMA_DCS_DES8 | JZ_DMA_DCS_CTE);
> + JZ_DMA_DCS_CTE);
> }
>
> static void jz4780_dma_issue_pending(struct dma_chan *chan)
> --
> 2.18.0
>
>
Patch looks good to me.
Reviewed-by: PrasannaKumar Muralidharan
Regards,
PrasannaKumar
,
> { .compatible = "ingenic,jz4770-dma", .data = (void *)ID_JZ4770 },
> { .compatible = "ingenic,jz4780-dma", .data = (void *)ID_JZ4780 },
> {},
> --
> 2.18.0
>
>
Patch looks good to me.
Reviewed-by: PrasannaKumar Muralidharan /
atible = "ingenic,jz4740-dma", .data = (void *)ID_JZ4740 },
> + { .compatible = "ingenic,jz4725b-dma", .data = (void *)ID_JZ4725B },
> { .compatible = "ingenic,jz4770-dma", .data = (void *)ID_JZ4770 },
> { .compatible = "ingenic,jz4780-dma", .data = (void *)ID_JZ4780 },
> {},
> --
> 2.18.0
>
>
Reviewed-by: PrasannaKumar Muralidharan
SC);
> + jz4780_dma_ctrl_writel(jzdma, JZ_DMA_REG_DMAC, JZ_DMA_DMAC_DMAE |
> + JZ_DMA_DMAC_FAIC | JZ_DMA_DMAC_FMSC);
>
> if (jzdma->version == ID_JZ4780)
> jz4780_dma_ctrl_writel(jzdma, JZ_DMA_REG_DMACP, 0);
> --
> 2.18.0
>
>
Reviewed-by: PrasannaKumar Muralidharan .
Agreed. Is it better to change the man page and document the behaviour?
Regards,
PrasannaKumar
From: PrasannaKumar Muralidharan
As described in bug #112271 (bugzilla.kernel.org/show_bug.cgi?id=112271)
don't set sempid in semctl syscall. Set sempid only when semop is called.
Signed-off-by: PrasannaKumar Muralidharan
---
ipc/sem.c | 1 -
1 file changed, 1 deletion(-)
diff --git
>> The hwrng interface was always meant to be an interface for real
>> hardware random number generators. People rely on that so we
>> should not provide bogus entropy sources through this interface.
>>
>
> Why not adding a KCONFIG HW_RANDOM_ACCEPT_ALSO_PRNG with big warning ?
> Or a HW_PRNG Kconf
>> I narrowed it down to commit 6e9b5e76882c ("hwrng: geode - Migrate to
>> managed API") which seems to introduce this. It looks to me like some issue
>> between devres, the Geode hwrng and AES drivers which both use the same PCI
>> device.
>
> It does
>
>> I'm no expert here, but I curious if
Will be great if someone could review this. Thanks in advance.
> This is all well and good and seems useful, but you have not stated why
> this is even useful in the first place?
Sorry, should have done that already. MXU is the name for SIMD
instructions found in Ingenic SoC. Registers xr0 to xr16 is used by
MXU instructions. I will add info when I submit nex
On 5 July 2016 at 04:00, Maciej W. Rozycki wrote:
> On Sat, 25 Jun 2016, PrasannaKumar Muralidharan wrote:
>
>> diff --git a/arch/mips/include/asm/mxu.h b/arch/mips/include/asm/mxu.h
>> new file mode 100644
>> index 000..cf77cbd
>> --- /dev/null
>> +++ b/ar
On 5 July 2016 at 15:04, Paul Burton wrote:
> Hi PrasannaKumar,
>
> On 25/06/16 13:14, PrasannaKumar Muralidharan wrote:
>>
>> From: PrasannaKumar Muralidharan
>>
>> This patch adds support for context switching Xburst MXU registers. The
>> registers are
> What do you think about those two solutions ?
I prefer the second solution's idea of using two files (/dev/hwrng and
/dev/hwprng). Upon having a quick glance it looks like (based on
current_rng == prng check) that your current implementation allows
only one rng device to be in use at a time. It
>> I have found two solutions:
>
> No we already have algif_rng so let's not confuse things even
> further by making hwrng take PRNGs.
Even if both the solutions could not be adopted I think there must be
a way for applications to use similar API to get true rng or prng.
Given the case that no use
.Have some minor comments. Please feel free to correct if I am wrong.
On 25 March 2017 at 21:56, Krzysztof Kozlowski wrote:
> Replace existing hw_ranndom/exynos-rng driver with a new, reworked one.
> This is a driver for pseudo random number generator block which on
> Exynos4 chipsets must be see
On 26 March 2017 at 21:31, Krzysztof Kozlowski wrote:
> On Sun, Mar 26, 2017 at 08:50:42PM +0530, PrasannaKumar Muralidharan wrote:
>> .Have some minor comments. Please feel free to correct if I am wrong.
>>
>> On 25 March 2017 at 21:56, Krzysztof Kozlowski wrote:
>
> Oh my, if you are right with your first guess, this is a bad DRNG design.
>
> Just out of curiousity: what happens if a caller invokes the seed function
> twice or more times (each time with the sufficient amount of bits)? What is
> your guess here?
Should the second seed use the random data gen
HW RNG core never asks for data less than 4 bytes. The check whether max
is less than 4 bytes is unnecessary. Remove the check.
Signed-off-by: PrasannaKumar Muralidharan
---
drivers/char/hw_random/meson-rng.c | 3 ---
drivers/char/hw_random/st-rng.c| 3 ---
2 files changed, 6 deletions
Hi Darren,
>> I wanted to use devm_ioremap_resource but could not find DT entry
>> required for this driver in any of the .dts files. So did not change
>> that. I could not find any dts/dtsi for this platform. So I assume
>> that the dtb is not present in the kernel, dtb is supplied by the
>> boot
This patch adds support for hardware random number generator present in
JZ4780 SoC.
Signed-off-by: PrasannaKumar Muralidharan
---
.../devicetree/bindings/rng/ingenic,jz4780-rng.txt | 12 +++
MAINTAINERS| 5 +
arch/mips/boot/dts/ingenic/jz4780.dtsi
On 17 August 2016 at 21:31, Daniel Thompson wrote:
> On 17/08/16 16:35, PrasannaKumar Muralidharan wrote:
>>
>> This patch adds support for hardware random number generator present in
>> JZ4780 SoC.
>>
>> Signed-off-by: PrasannaKumar Muralidharan
>> ---
w_random/jz4780-rng.c
>> @@ -0,0 +1,105 @@
>> +/*
>> + * jz4780-rng.c - Random Number Generator driver for J4780
>> + *
>> + * Copyright 2016 (C) PrasannaKumar Muralidharan
>>
>> + *
>> + * This file is licensed under the terms of the GNU General Public
&g
> Please forgive my ignorance Prasanna...
>
> For the JZ4780 I have, there are two registers in play. The first is
> the control register which enables/disables the RNG. The control
> register is named ERNG. The second register is the data register, and
> it produces the random stream. The data reg
> __ARM_FEATURE_UNALIGNED (cf.,
> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0774f/chr1383660321827.html)
> . MIPSEL does not define such a macro.
>
> # MIPS ci20 creator with GCC 4.6
> $ gcc -march=native -dM -E - #define __BIGGEST_ALIGNMENT__ 8
>
> If the MIPS CPU
From: PrasannaKumar Muralidharan
This patch adds support for context switching Xburst MXU registers. The
registers are named xr0 to xr16. xr16 is the control register that can
be used to enable and disable MXU instruction set. Read and write to
these registers can be done without enabling MXU
Hi Sean,
Mostly looks good, have few minor comments.
On 13 April 2017 at 12:35, wrote:
> +static bool mtk_rng_wait_ready(struct hwrng *rng, bool wait)
> +{
> + struct mtk_rng *priv = to_mtk_rng(rng);
> + int ready;
> +
> + ready = readl(priv->base + RNG_CTRL) & RNG_READY;
> +
val : -EIO;" I use can also help handling
> the both cases in one line which i think is elegant enough.
>
> And retval is accumulated with each round if some data's existing in
> hardware, so we don't return the value from mtk_rng_wait_ready().
retval can be 0 only when mkt_rng_wait_ready fails, returning 0 when
wait is true is confusing. Expected return value when 0 bytes is read
from device and wait is true is not clearly documented.
"return retval || !wait ? retval : -EIO;" is also fine.
Overall the code looks good to me. You can add:
Reviewed-by: PrasannaKumar Muralidharan .
Regards,
PrasannaKumar
Hi Rick,
Minor comment below.
On 18 May 2017 at 03:59, Rick Altherr wrote:
> When a hw_random device's quality is non-zero, it will automatically be
> used to fill the kernel's entropy pool. Since timeriomem_rng is used by
> many different devices, the quality needs to be provided by platform
>
Hi Martin,
On 18 July 2017 at 02:46, Martin Kaiser wrote:
> From: Steffen Trumtrar
>
> The driver is ported from Freescales Linux git and can be
> found in the
>
> vendor/freescale/imx_2.6.35_maintain
>
> branch.
>
> According to that code, the RNGC is found on Freescales i.MX3/5 SoCs.
>
latform_device *pdev)
> +{
> + struct mxc_rngc *rngc = platform_get_drvdata(pdev);
> +
> + hwrng_unregister(&rngc->rng);
> +
> + clk_disable_unprepare(rngc->clk);
> +
> + return 0;
> +}
> +
> +#ifdef CONFIG_PM
> +static int mxc_rngc_suspend(struct device *dev)
> +{
> + struct mxc_rngc *rngc = dev_get_drvdata(dev);
> +
> + clk_disable_unprepare(rngc->clk);
> +
> + return 0;
> +}
> +
> +static int mxc_rngc_resume(struct device *dev)
> +{
> + struct mxc_rngc *rngc = dev_get_drvdata(dev);
> +
> + clk_prepare_enable(rngc->clk);
> +
> + return 0;
> +}
> +
> +static const struct dev_pm_ops mxc_rngc_pm_ops = {
> + .suspend= mxc_rngc_suspend,
> + .resume = mxc_rngc_resume,
> +};
> +#endif
> +
> +static const struct of_device_id mxc_rngc_dt_ids[] = {
> + { .compatible = "fsl,imx25-rng", .data = NULL, },
> + { /* sentinel */ }
> +};
> +MODULE_DEVICE_TABLE(of, mxc_rngc_dt_ids);
> +
> +static struct platform_driver mxc_rngc_driver = {
> + .driver = {
> + .name = "mxc_rngc",
> +#ifdef CONFIG_PM
> + .pm = &mxc_rngc_pm_ops,
> +#endif
> + .of_match_table = mxc_rngc_dt_ids,
> + },
> + .remove = __exit_p(mxc_rngc_remove),
> +};
> +
> +module_platform_driver_probe(mxc_rngc_driver, mxc_rngc_probe);
> +
> +MODULE_AUTHOR("Freescale Semiconductor, Inc.");
> +MODULE_DESCRIPTION("H/W RNGC driver for i.MX");
> +MODULE_LICENSE("GPL");
> --
> 2.1.4
>
Regardless of the minor suggestion, code looks good to me as is.
Reviewed-by: PrasannaKumar Muralidharan .
Note: Add my reviewed by tag if you are going for next version.
Regards,
PrasannaKumar
Hi Alexandre,
On 20 December 2017 at 01:39, Alexandre Belloni
wrote:
> Hi,
>
> On 19/12/2017 at 20:27:02 +0530, PrasannaKumar Muralidharan wrote:
>> Given the fact that setup code is very small and most of it is generic
>> code I strongly believe that it is plausible t
Hi Ard,
On 21 December 2017 at 17:52, Ard Biesheuvel wrote:
> On 21 December 2017 at 10:20, Arnd Bergmann wrote:
>> On Wed, Dec 20, 2017 at 10:46 PM, Jakub Jelinek wrote:
>>> On Wed, Dec 20, 2017 at 09:52:05PM +0100, Arnd Bergmann wrote:
diff --git a/crypto/aes_generic.c b/crypto/aes_gener
return 0;
> +}
> +
> +static int __maybe_unused exynos_trng_resume(struct device *dev)
> +{
> + int ret;
> +
> + ret = pm_runtime_get_sync(dev);
> + if (ret < 0) {
> + dev_err(dev, "Could not get runtime PM.\n");
> + pm_runtime_put_noidle(dev);
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static SIMPLE_DEV_PM_OPS(exynos_trng_pm_ops, exynos_trng_suspend,
> +exynos_trng_resume);
> +
> +static const struct of_device_id exynos_trng_dt_match[] = {
> + {
> + .compatible = "samsung,exynos5250-trng",
> + },
> + { },
> +};
> +MODULE_DEVICE_TABLE(of, exynos_rng_dt_match);
> +
> +static struct platform_driver exynos_trng_driver = {
> + .driver = {
> + .name = "exynos-trng",
> + .pm = &exynos_trng_pm_ops,
> + .of_match_table = exynos_trng_dt_match,
> + },
> + .probe = exynos_trng_probe,
> + .remove = exynos_trng_remove,
> +};
> +
> +module_platform_driver(exynos_trng_driver);
> +MODULE_AUTHOR("Łukasz Stelmach");
> +MODULE_DESCRIPTION("H/W TRNG driver for Exynos chips");
> +MODULE_LICENSE("GPL");
> --
> 2.11.0
>
Reviewed-by: PrasannaKumar Muralidharan
Regards,
PrasannaKumar
;simple-mfd",
> "syscon";
> + reg = <0x107 0x1c>;
> +
> + reset {
> + compatible = "mscc,ocelot-chip-reset";
> + mscc,cpucontrol = <&cpu_ctrl>;
> + };
> +
t; +}
> +
> +void __init arch_init_irq(void)
> +{
> + irqchip_init();
> +}
> +
> +const char *get_system_type(void)
> +{
> + return "Microsemi Ocelot";
> +}
> +
> +static void __init ocelot_late_init(void)
> +{
> + ocelot_earlyprintk_init()
y = 192;
> + err = register_restart_handler(&ctx->restart_handler);
> + if (err)
> + dev_err(dev, "can't register restart notifier (err=%d)\n",
> err);
> +
> + return err;
> +}
> +
> +static const struct of_device_id ocelot_reset_of_match[] = {
> + { .compatible = "mscc,ocelot-chip-reset" },
> + {}
> +};
> +
> +static struct platform_driver ocelot_reset_driver = {
> + .probe = ocelot_reset_probe,
> + .driver = {
> + .name = "ocelot-chip-reset",
> + .of_match_table = ocelot_reset_of_match,
> + },
> +};
> +builtin_platform_driver(ocelot_reset_driver);
> --
> 2.15.1
>
>
Looks good to me.
Reviewed-by: PrasannaKumar Muralidharan
Regards,
PrasannaKumar
ut-path = "serial0:115200n8";
> + };
> +
> + memory {
> + device_type = "memory";
> + reg = <0x0 0x0e00>;
> + };
> +};
> +
> +&uart0 {
> + status = "okay";
> +};
> +
> +&uart2 {
> + status = "okay";
> +};
> --
> 2.15.1
>
>
Looks good to me.
Reviewed-by: PrasannaKumar Muralidharan
Regards,
PrasannaKumar
; +
> +void __init device_tree_init(void)
> +{
> + if (!initial_boot_params)
> + return;
> +
> + unflatten_and_copy_device_tree();
> +}
> +
> +static int __init populate_machine(void)
> +{
> + of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
> + return 0;
> +}
> +arch_initcall(populate_machine);
> --
> 2.15.1
>
>
Given the fact that setup code is very small and most of it is generic
code I strongly believe that it is plausible to make use of generic
code completely. Please have a look at [1] and [2].
1. https://patchwork.kernel.org/patch/9655699/
2. https://patchwork.kernel.org/patch/9655697/
PS: My rb tag stays if this could not be done immediately.
Regards,
PrasannaKumar Muralidharan
}
> - *dst++ = ' ';
> - }
> - if (i > 1)
> - --dst;
> -
> - *dst = 0;
> -}
> -
> void __init prom_init(void)
> {
> - jz4740_init_cmdline((int)fw_arg0, (char **)fw_arg1);
> mips_machtype = MACH_INGENIC_JZ4740;
> + fw_init_cmdline();
> }
>
> void __init prom_free_prom_memory(void)
> --
> 2.11.0
>
>
Looks good to me.
Reviewed-by: PrasannaKumar Muralidharan
_INGENIC_JZ4780 3 /* JZ4780 SOC */
>
> extern char *system_type;
> const char *get_system_type(void);
> --
> 2.11.0
>
>
Reviewed-by: PrasannaKumar Muralidharan
Hi Paul,
On 2 January 2018 at 20:38, Paul Cercueil wrote:
> This makes sure that 'mips_machtype' will be initialized to the SoC
> version used on the board.
>
> Signed-off-by: Paul Cercueil
> ---
> arch/mips/Kconfig | 1 +
> arch/mips/jz4740/Makefile | 2 +-
> arch/mips/jz4740/boards.
ud", "module";
> +
> + interrupt-parent = <&intc>;
> + interrupts = <2>;
> +
> + status = "disabled";
> + };
> +
> + uhc: uhc@1343 {
> + compatible = "generic-ohci";
> + reg = <0x1343 0x1000>;
> +
> + clocks = <&cgu JZ4770_CLK_UHC>, <&cgu JZ4770_CLK_UHC_PHY>;
> + assigned-clocks = <&cgu JZ4770_CLK_UHC>;
> + assigned-clock-rates = <4800>;
> +
> + interrupt-parent = <&intc>;
> + interrupts = <20>;
> +
> + status = "disabled";
> + };
> +};
> diff --git a/arch/mips/jz4740/Kconfig b/arch/mips/jz4740/Kconfig
> index 643af2012e14..29a9361a2b77 100644
> --- a/arch/mips/jz4740/Kconfig
> +++ b/arch/mips/jz4740/Kconfig
> @@ -18,6 +18,12 @@ config MACH_JZ4740
> bool
> select SYS_HAS_CPU_MIPS32_R1
>
> +config MACH_JZ4770
> + bool
> + select MIPS_CPU_SCACHE
> + select SYS_HAS_CPU_MIPS32_R2
> + select SYS_SUPPORTS_HIGHMEM
> +
> config MACH_JZ4780
> bool
> select MIPS_CPU_SCACHE
> diff --git a/arch/mips/jz4740/time.c b/arch/mips/jz4740/time.c
> index bb1ad5119da4..2ca9160f642a 100644
> --- a/arch/mips/jz4740/time.c
> +++ b/arch/mips/jz4740/time.c
> @@ -113,7 +113,7 @@ static struct clock_event_device jz4740_clockevent = {
> #ifdef CONFIG_MACH_JZ4740
> .irq = JZ4740_IRQ_TCU0,
> #endif
> -#ifdef CONFIG_MACH_JZ4780
> +#if defined(CONFIG_MACH_JZ4770) || defined(CONFIG_MACH_JZ4780)
> .irq = JZ4780_IRQ_TCU2,
> #endif
> };
> --
> 2.11.0
>
>
Looks good to me.
Reviewed-by: PrasannaKumar Muralidharan
Hi Srinivas,
On 2 January 2018 at 17:31, Srinivas Kandagatla
wrote:
>
>
> On 28/12/17 21:29, Mathieu Malaterre wrote:
>>
>> This patchset bring support for read-only access to the JZ4780 efuse as
>> found
>> on MIPS Creator CI20.
>>
>> To keep the driver as simple as possible, it was not possible
Hi Srini,
On 2 January 2018 at 17:32, Srinivas Kandagatla
wrote:
>
>
> On 28/12/17 21:29, Mathieu Malaterre wrote:
>>
>> From: PrasannaKumar Muralidharan
>>
>> This patch brings support for the JZ4780 efuse. Currently it only expose
>> a read only ac
Hi Paul,
On 30 December 2017 at 19:21, Paul Cercueil wrote:
> Also remove the watchdog platform_device from platform.c, since it
> wasn't used anywhere anyway.
>
> Signed-off-by: Paul Cercueil
> ---
> arch/mips/boot/dts/ingenic/jz4740.dtsi | 8
> arch/mips/jz4740/platform.c
Hi Paul,
On 2 January 2018 at 20:38, Paul Cercueil wrote:
> From: Maarten ter Huurne
>
> We have seen MMC DMA transfers read corrupted data from SDRAM when
> a burst interval ends at physical address 0x1000. To avoid this
> problem, we remove the final page of low memory from the memory map.
Hi Guenter,
On 3 January 2018 at 10:16, Guenter Roeck wrote:
> On 01/02/2018 08:48 AM, Paul Cercueil wrote:
>>
>> Hi PrasannaKumar,
>>
>> Le mar. 2 janv. 2018 à 17:37, PrasannaKumar Muralidharan
>> a écrit :
>>>
>>> Hi Paul,
>>
elot_pcb123.dts
> create mode 100644 arch/mips/configs/mscc_defconfig
> create mode 100644 arch/mips/mscc/Makefile
> create mode 100644 arch/mips/mscc/Platform
> create mode 100644 arch/mips/mscc/setup.c
> create mode 100644 drivers/irqchip/irq-mscc-ocelot.c
> create mode 100644 drivers/pinctrl/pinctrl-ocelot.c
> create mode 100644 drivers/power/reset/ocelot-reset.c
>
> --
> 2.15.1
>
>
Except for irqchip driver and pinctrl driver other parts of the series is
Reviewed-by: PrasannaKumar Muralidharan
Regards,
PrasannaKumar
When there is no overlap between src and dst use optimised memcpy if it
is available.
Signed-off-by: Paul Burton
Signed-off-by: PrasannaKumar Muralidharan
---
This change is a small part of a patch [1] from Paul Burton. I have
added his Signed-off by. I do not know whether it is correct. Please
Hi Mathieu,
On 16 September 2017 at 00:48, Mathieu Malaterre wrote:
> The jz4740-watchdog driver supports both jz4740 & jz4780.
>
> Signed-off-by: Mathieu Malaterre
> ---
> Changes in v2:
> * make the node name generic (Paul Cercueil)
>
> arch/mips/boot/dts/ingenic/jz4780.dtsi | 5 +
> 1 fi
On 26 September 2017 at 18:56, Mathieu Malaterre wrote:
> Hi PrasannaKumar !
>
> On Tue, Sep 26, 2017 at 3:17 PM, PrasannaKumar Muralidharan
> wrote:
>> Hi Mathieu,
>>
>> On 16 September 2017 at 00:48, Mathieu Malaterre wrote:
>>> The jz4740-watchd
Ingenic X1000 SoC has different set of peripherals than JZ4780 and
JZ4740. Add a new device tree binding for the clock.
Signed-off-by: PrasannaKumar Muralidharan
---
include/dt-bindings/clock/x1000-cgu.h | 46 +++
1 file changed, 46 insertions(+)
create mode
1 - 100 of 117 matches
Mail list logo
