Re: [PATCH 01/14] dmaengine: dma-jz4780: Avoid hardcoding number of channels

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 >>

Re: [PATCH 02/14] dmaengine: dma-jz4780: Separate chan/ctrl registers

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

Re: [PATCH 07/14] dmaengine: dma-jz4780: Enable Fast DMA to the AIC

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 .

Re: [PATCH 06/14] dmaengine: dma-jz4780: Add support for the JZ4725B SoC

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

Re: [PATCH 05/14] dmaengine: dma-jz4780: Add support for the JZ4740 SoC

, > { .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 /

Re: [PATCH 03/14] dmaengine: dma-jz4780: Use 4-word descriptors

> @@ -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

Re: [PATCH 02/14] dmaengine: dma-jz4780: Separate chan/ctrl registers

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

Re: [PATCH 01/14] dmaengine: dma-jz4780: Avoid hardcoding number of channels

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

Re: [RFC 3/4] MIPS: Ingenic: Initial X1000 SoC support

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

Re: [RFC 3/4] MIPS: Ingenic: Initial X1000 SoC support

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

Re: [RFC 3/4] MIPS: Ingenic: Initial X1000 SoC support

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 &

Re: [RFC 3/4] MIPS: Ingenic: Initial X1000 SoC support

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

Re: [RFC 3/4] MIPS: Ingenic: Initial X1000 SoC support

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

Re: [RFC] NAND: Optimize NAND_ECC_HW_OOB_FIRST read

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

Re: [PATCH v2] tpm: Move Linux RNG connection to hwrng

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

Re: [PATCH v2 3/8] watchdog: JZ4740: Register a restart handler

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

Re: [PATCH v2 4/8] watchdog: JZ4740: Drop module remove function

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

Re: [PATCH v2 1/2] nvmem: add driver for JZ4780 efuse

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: >

Re: [PATCH v3] tpm: use struct tpm_chip for tpm_chip_find_get()

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

Re: [PATCH v2 4/8] watchdog: JZ4740: Drop module remove function

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. > >

Re: [PATCH v2 3/8] watchdog: JZ4740: Register a restart handler

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

Re: [PATCH v2 1/2] nvmem: add driver for JZ4780 efuse

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

Re: [PATCH v3] tpm: use struct tpm_chip for tpm_chip_find_get()

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

Re: [PATCH v2 1/2] nvmem: add driver for JZ4780 efuse

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

Re: [PATCH 1/2] nvmem: add driver for JZ4780 efuse

t;> wrote: >> > Hi Mathieu, PrasannaKumar, >> > >> > On 27.12.2017 13:27, Mathieu Malaterre wrote: >> >> >> >> From: PrasannaKumar Muralidharan > <mailto:prasannatsmku...@gmail.com>> >> >> >> >> This

Re: [PATCH v2 5/8] MIPS: jz4740: dts: Add bindings for the jz4740-wdt driver

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, >>

Re: [PATCH v5 13/15] MIPS: JZ4770: Workaround for corrupted DMA transfers

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.

Re: [PATCH v2 5/8] MIPS: jz4740: dts: Add bindings for the jz4740-wdt driver

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

Re: [PATCH v2 1/2] nvmem: add driver for JZ4780 efuse

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

Re: [PATCH v2 0/2] Add efuse driver for Ingenic JZ4780 SoC

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

Re: [PATCH v5 11/15] MIPS: ingenic: Initial JZ4770 support

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

Re: [PATCH v5 10/15] MIPS: ingenic: Add machine info for supported boards

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.

Re: [PATCH v5 09/15] MIPS: platform: add machtype IDs for more Ingenic SoCs

_INGENIC_JZ4780 3 /* JZ4780 SOC */ > > extern char *system_type; > const char *get_system_type(void); > -- > 2.11.0 > > Reviewed-by: PrasannaKumar Muralidharan

Re: [PATCH v5 08/15] MIPS: ingenic: Use common cmdline handling code

} > - *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

Re: [PATCH] [RFT] crypto: aes-generic - turn off -ftree-pre and -ftree-sra

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

Re: [PATCH v2 09/13] MIPS: mscc: Add initial support for Microsemi MIPS SoCs

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

Re: [PATCH v2 09/13] MIPS: mscc: Add initial support for Microsemi MIPS SoCs

; + > +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

Re: [PATCH v2 11/13] MIPS: mscc: add ocelot PCB123 device tree

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

Re: [PATCH v2 08/13] power: reset: Add a driver for the Microsemi Ocelot reset

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

Re: [PATCH v2 10/13] MIPS: mscc: add ocelot dtsi

;simple-mfd", > "syscon"; > + reg = <0x107 0x1c>; > + > + reset { > + compatible = "mscc,ocelot-chip-reset"; > + mscc,cpucontrol = <&cpu_ctrl>; > + }; > +

Re: [PATCH v2 09/13] MIPS: mscc: Add initial support for Microsemi MIPS SoCs

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()

Re: [PATCH v2 00/13] MIPS: add support for the Microsemi MIPS SoCs

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

Re: [PATCH v2 2/3] hwrng: exynos - add Samsung Exynos True RNG driver

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

Re: [PATCH] lib: memmove: Use optimised memcpy if possible

plit his patch into two and send with my modifications. > On Sat, Nov 25, 2017 at 10:52:04PM +0530, PrasannaKumar Muralidharan wrote: >> Hi, >> >> On 4 October 2017 at 22:26, PrasannaKumar Muralidharan >> wrote: >> > When there is no overlap between src an

Re: [PATCH] lib: memmove: Use optimised memcpy if possible

Hi, On 4 October 2017 at 22:26, PrasannaKumar Muralidharan wrote: > 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

Re: [PATCH 2/3] hwrng: exynos - add Samsung Exynos True RNG driver

On 24 November 2017 at 20:55, PrasannaKumar Muralidharan wrote: > Hi Lukasz, > > Some minor comments below. > > On 23 November 2017 at 20:39, Łukasz Stelmach wrote: >> Add support for True Random Number Generator found in Samsung Exynos >> 5250+ SoCs. >>

Re: [PATCH 2/3] hwrng: exynos - add Samsung Exynos True RNG driver

Hi Lukasz, Some minor comments below. On 23 November 2017 at 20:39, Łukasz Stelmach wrote: > Add support for True Random Number Generator found in Samsung Exynos > 5250+ SoCs. > > Signed-off-by: Łukasz Stelmach > --- > MAINTAINERS | 7 + > drivers/char/hw_random/Kcon

Re: [PATCH] crypto: hifn_795x - Fix a memory leak in the error handling path of 'hifn_probe()'

579,7 @@ static int hifn_probe(struct pci_dev *pdev, const > struct pci_device_id *id) > for (i = 0; i < 3; ++i) > if (dev->bar[i]) > iounmap(dev->bar[i]); > + kfree(dev); > > err_out_free_regions: > pci_release_regions(pdev); > -- > 2.14.1 > Nice catch. Reviewed-by: PrasannaKumar Muralidharan Regards, PrasannaKumar

Re: [PATCH v2] tpm: Move Linux RNG connection to hwrng

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

Re: [PATCH v3] tpm: use struct tpm_chip for tpm_chip_find_get()

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

Re: [PATCH v2] tpm: Move Linux RNG connection to hwrng

Hi Jason, On 7 November 2017 at 21:34, Jason Gunthorpe wrote: > On Tue, Nov 07, 2017 at 08:50:44AM +0530, PrasannaKumar Muralidharan wrote: > >> I am assuming you are talking about the following patches - using >> struct tpm_chip instead of chip number and this patch. >

Re: [PATCH v2] tpm: Move Linux RNG connection to hwrng

Hi Jason, On 6 November 2017 at 07:57, Jason Gunthorpe wrote: > On Sun, Nov 05, 2017 at 01:05:06PM +0200, Jarkko Sakkinen wrote: > >> I asked to create a series for a reason. Now this doesn't apply because I >> don't have an ancestor in my git history. > > It would be unusual for me to put your p

Re: [RFC] NAND: Optimize NAND_ECC_HW_OOB_FIRST read

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

Re: [RFC] NAND: Optimize NAND_ECC_HW_OOB_FIRST read

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

Re: [PATCH] hw_random: Include device.h instead of declaring struct device

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

Re: [RFC] NAND: Optimize NAND_ECC_HW_OOB_FIRST read

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

[RFC] NAND: Optimize NAND_ECC_HW_OOB_FIRST read

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

Re: [PATCH v3] tpm: use struct tpm_chip for tpm_chip_find_get()

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

Re: [tpmdd-devel] [PATCH] tpm: remove chip_num parameter from in-kernel API

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

[PATCH] MAINTAINERS: Mark hw_random as being maintained

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

Re: [PATCH v3] tpm: use struct tpm_chip for tpm_chip_find_get()

); > + 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

[PATCH] hw_random: Include device.h instead of declaring struct device

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

Re: [PATCH] tpm: Move Linux RNG connection to hwrng

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

Re: [PATCH v2] tpm: use struct tpm_chip for tpm_chip_find_get()

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

Re: [tpmdd-devel] [PATCH] tpm: remove chip_num parameter from in-kernel API

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

Re: [PATCH] tpm: Move Linux RNG connection to hwrng

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

Re: [tpmdd-devel] [PATCH] tpm: remove chip_num parameter from in-kernel API

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,

Re: [tpmdd-devel] [PATCH] tpm: remove chip_num parameter from in-kernel API

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

Re: [tpmdd-devel] [PATCH] tpm: remove chip_num parameter from in-kernel API

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

Re: [tpmdd-devel] [PATCH] tpm: remove chip_num parameter from in-kernel API

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

Re: [tpmdd-devel] [PATCH] tpm: remove chip_num parameter from in-kernel API

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

Re: [tpmdd-devel] [PATCH] tpm: remove chip_num parameter from in-kernel API

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

Re: [PATCH] lib: memmove: Use optimised memcpy if possible

On 4 October 2017 at 22:26, PrasannaKumar Muralidharan wrote: > 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

Re: [RFC PATCH] crypto: make the seed() function optional

Hi Herbert, On 7 October 2017 at 09:03, Herbert Xu wrote: > Mathieu Malaterre wrote: >> This makes it simplier for driver author to not provide the seed() function >> in case of a pseudo RNG where the seed operation is a no-op. >> >> Document that the seed() function pointer is optional in heade

[PATCH] lib: memmove: Use optimised memcpy if possible

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

[RFC 0/4] Add Ingenic X1000 SoC Support

ce anymore so could not test the fix. Marking this patch series as RFC as this needs to be tested. Test and feedback appreciated. This series enables uart, timer and interrupt controller. As this is very minimal a static elf binary should be used as init and should be available in initramfs. Pra

[RFC 2/4] clk: Add Ingenic X1000 CGU driver

Add support for the clocks provided by CGU in Ingenic X1000 SoC. Signed-off-by: PrasannaKumar Muralidharan --- drivers/clk/ingenic/Makefile| 1 + drivers/clk/ingenic/x1000-cgu.c | 203 2 files changed, 204 insertions(+) create mode 100644 drivers

[RFC 4/4] MIPS: Ingenic: Add Halley2 development board support

Halley2 is a development board from Ingenic using X1000 SoC. It comes with either 32MB or 64MB of RAM. Add support for halley2 development board. Signed-off-by: PrasannaKumar Muralidharan --- arch/mips/boot/dts/ingenic/Makefile| 1 + arch/mips/boot/dts/ingenic/halley2.dts | 46

[RFC 3/4] MIPS: Ingenic: Initial X1000 SoC support

Add initial Ingenic X1000 SoC support. Provide minimum necessary information to boot kernel to an initramfs userspace. Signed-off-by: PrasannaKumar Muralidharan --- arch/mips/boot/dts/ingenic/x1000.dtsi | 93 +++ arch/mips/jz4740/Kconfig | 6

[RFC 1/4] dt-bindings: Add Ingenic X1000 SoC clock define

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

Re: [PATCH v2 3/5] MIPS: jz4780: DTS: Probe the jz4740-watchdog driver from devicetree

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

Re: [PATCH v2 3/5] MIPS: jz4780: DTS: Probe the jz4740-watchdog driver from devicetree

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

Re: [PATCH v4 3/3] hwrng: mxc-fsl - add support for Freescale RNGC

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

Re: [PATCH 3/3] hwrng: mxc-fsl - add support for Freescale RNGC

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. >

Re: [PATCH v1 2/2] hw_random: timeriomem_rng: Allow setting RNG quality from platform data

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 >

Re: [PATCH 2/2] hwrng: mtk: Add driver for hardware random generator on MT7623 SoC

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

Re: [PATCH 2/2] hwrng: mtk: Add driver for hardware random generator on MT7623 SoC

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; > +

Re: [PATCH v3 1/3] crypto: hw_random - Add new Exynos RNG driver

> 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

Re: [PATCH v3 1/3] crypto: hw_random - Add new Exynos RNG driver

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: >

Re: [PATCH v3 1/3] crypto: hw_random - Add new Exynos RNG driver

.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

Re: Geode LX AES/RNG driver triggers warning

>> 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

Re: [PATCH v2] crypto: sun4i-ss: support the Security System PRNG

>> 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

Re: [PATCH v2] crypto: sun4i-ss: support the Security System PRNG

> 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

Re: [PATCH v2] crypto: sun4i-ss: support the Security System PRNG

>> 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

Re: [PATCH] crypto: sun4i-ss: support the Security System PRNG

Hi Corentin, I have a few minor comments. On 18 October 2016 at 18:04, Corentin Labbe wrote: > From: LABBE Corentin > > The Security System have a PRNG. > This patch add support for it as an hwrng. > > Signed-off-by: Corentin Labbe > --- > drivers/crypto/Kconfig | 8 >

Re: hwrng: pasemi_rng.c: Migrate to managed API

> 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

Re: hwrng: pasemi_rng.c: Migrate to managed API

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

[PATCH] hw_random: Remove check for max less than 4 bytes

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

[PATCH v2 2/2] miscdevice: Use module_misc_device() macro

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

[PATCH v2 1/2] miscdevice: Add helper macro for misc device boilerplate

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

  1   2   >