Re: [PATCH 2/2] powerpc/fadump: update about offset where fadump is reserved

Hi Michal, Thanks for the review.. On Monday 22 May 2017 04:25 PM, Michal Suchánek wrote: On Mon, 22 May 2017 15:04:47 +0530 Hari Bathini wrote: With commit f6e6bedb7731 ("powerpc/fadump: Reserve memory at an offset closer to bottom of RAM"), memory for fadump

Re: RFC: better timer interface

On Mon, 22 May 2017, Arnd Bergmann wrote: > On Sun, May 21, 2017 at 8:14 PM, Thomas Gleixner wrote: > > But it's easy enough to provide them. All we need for that is something > > like > > > > unsigned long time_msec; > > > > which gets incremented every tick by the

Re: [PATCH v4 00/20] eeprom: at24: Add OF device ID table

Hi Javier, On Mon, May 22, 2017 at 7:15 PM, Javier Martinez Canillas wrote: >>> I also wonder why this is really needed if AFAIU "renesas,24c02" is >>> compatible with "atmel,24c02". IOW, the driver doesn't need to >>> differentiate between the two since the devices are the

Re: RFC: better timer interface

On Mon, 22 May 2017, Arnd Bergmann wrote: > On Sun, May 21, 2017 at 7:13 PM, Thomas Gleixner wrote: > I agree, one of the above is good enough, if we do the large-scale API > replacement. Having both ms and sec variants would be for convenience > to avoid having lots of

[PATCH v4 00/20] eeprom: at24: Add OF device ID table

Hello Wolfram, This series is a follow-up to patch [0] that added an OF device ID table to the at24 EEPROM driver. As you suggested [1], this version instead of adding entries for every used tuple, only adds a single entry for each chip type using the "atmel" vendor as a generic

[PATCH v4 16/20] powerpc/5200: Add generic compatible string for I2C EEPROM

The at24 driver allows to register I2C EEPROM chips using different vendor and devices, but the I2C subsystem does not take the vendor into account when matching using the I2C table since it only has device entries. But when matching using an OF table, both the vendor and device has to be taken

[PATCH v4 18/20] powerpc/512x: Add generic compatible string for I2C EEPROM

The at24 driver allows to register I2C EEPROM chips using different vendor and devices, but the I2C subsystem does not take the vendor into account when matching using the I2C table since it only has device entries. But when matching using an OF table, both the vendor and device has to be taken

Re: [PATCH v4 00/20] eeprom: at24: Add OF device ID table

Hello Geert and Rob, On Mon, May 22, 2017 at 4:26 PM, Rob Herring wrote: > On Mon, May 22, 2017 at 9:23 AM, Geert Uytterhoeven > wrote: >> Hi Javier, >> >> On Mon, May 22, 2017 at 4:01 PM, Javier Martinez Canillas >> wrote: >>> This

Re: [PATCH 1/1] futex: remove duplicated code

On Mon, 15 May 2017, Will Deacon wrote: > Hi Jiri, > > On Mon, May 15, 2017 at 03:07:42PM +0200, Jiri Slaby wrote: > > There is code duplicated over all architecture's headers for > > futex_atomic_op_inuser. Namely op decoding, access_ok check for uaddr, > > and comparison of the result. > > > >

[PATCH v4 17/20] powerpc/fsl: Add generic compatible string for I2C EEPROM

The at24 driver allows to register I2C EEPROM chips using different vendor and devices, but the I2C subsystem does not take the vendor into account when matching using the I2C table since it only has device entries. But when matching using an OF table, both the vendor and device has to be taken

[PATCH] powerpc/hotplug-mem: Fix aa_index match bug for hotplug

When adding or removing memory, the aa_index (affinity value) for the memblock must also be converted to match the endianness of the rest of the 'ibm,dynamic-memory' property. Otherwise, subsequent retrieval of the attribute will likely lead to non-existent nodes, followed by using the default

[PATCH v4 19/20] powerpc/83xx: Add generic compatible string for I2C EEPROM

The at24 driver allows to register I2C EEPROM chips using different vendor and devices, but the I2C subsystem does not take the vendor into account when matching using the I2C table since it only has device entries. But when matching using an OF table, both the vendor and device has to be taken

[PATCH v4 20/20] powerpc/44x: Add generic compatible string for I2C EEPROM

The at24 driver allows to register I2C EEPROM chips using different vendor and devices, but the I2C subsystem does not take the vendor into account when matching using the I2C table since it only has device entries. But when matching using an OF table, both the vendor and device has to be taken

Re: [PATCH v4 00/20] eeprom: at24: Add OF device ID table

Hello Geert, On Mon, May 22, 2017 at 9:30 PM, Geert Uytterhoeven wrote: > Hi Javier, > > On Mon, May 22, 2017 at 7:15 PM, Javier Martinez Canillas > wrote: I also wonder why this is really needed if AFAIU "renesas,24c02" is compatible with

Re: [PATCH v4 00/20] eeprom: at24: Add OF device ID table

Hello Rob, Thanks a lot for your feedback. On Mon, May 22, 2017 at 6:52 PM, Rob Herring wrote: > On Mon, May 22, 2017 at 9:46 AM, Javier Martinez Canillas > wrote: [snip] | > | > at24@50 { | > - compatible = "at24,24c02";

[PATCH 1/6] powerpc/mm: Wire up hpte_removebolted for powernv

From: Anton Blanchard Adds support for removing bolted (i.e kernel linear mapping) mappings on powernv. This is needed to support memory hot unplug operations which are required for the teardown of DAX/PMEM devices. Reviewed-by: Rashmica Gupta

[PATCH 4/6] powerpc/mm: Add devmap support for ppc64

Add support for the devmap bit on PTEs and PMDs for PPC64 Book3S. This is used to differentiate device backed memory from transparent huge pages since they are handled in more or less the same manner by the core mm code. Cc: Aneesh Kumar K.V Signed-off-by:

[PATCH 3/6] powerpc/vmemmap: Add altmap support

Adds support to powerpc for the altmap feature of ZONE_DEVICE memory. An altmap is a driver provided region that is used to provide the backing storage for the struct pages of ZONE_DEVICE memory. In situations where large amount of ZONE_DEVICE memory is being added to the system the altmap reduces

[PATCH 5/6] mm, x86: Add ARCH_HAS_ZONE_DEVICE

Currently ZONE_DEVICE depends on X86_64. This is fine for now, but it will get unwieldly as new platforms get ZONE_DEVICE support. Moving it to an arch selected Kconfig option to save us some trouble in the future. Cc: x...@kernel.org Signed-off-by: Oliver O'Halloran ---

[PATCH 6/6] powerpc/mm: Enable ZONE_DEVICE on powerpc

Flip the switch. Running around and screaming "IT'S ALIVE" is optional, but recommended. Signed-off-by: Oliver O'Halloran --- arch/powerpc/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index f7c8f9972f61..bf3365c34244

Re: [PATCH 4/6] powerpc/mm: Add devmap support for ppc64

Oliver O'Halloran writes: > Add support for the devmap bit on PTEs and PMDs for PPC64 Book3S. This > is used to differentiate device backed memory from transparent huge > pages since they are handled in more or less the same manner by the core > mm code. > > Cc: Aneesh Kumar

[PATCH 2/6] powerpc/vmemmap: Reshuffle vmemmap_free()

Removes an indentation level and shuffles some code around to make the following patch cleaner. No functional changes. Signed-off-by: Oliver O'Halloran --- v1 -> v2: Remove broken initialiser --- arch/powerpc/mm/init_64.c | 48 --- 1

Re: [PATCH 4/4] arch/powerpc/44x/fsp2: wdt tcr update instead of whole rewrite

Ivan Mikhaylov writes: > > From my point of view it's possible. I've checked docu and on idea > it should be possible cause WP is only affecting watchdog ping time. The question is, is there any chance that leaving those bits set on another platform will cause a problem? ie. on

Re: SPU not working for kernel 4.9, 4.10, 4.11a and 4.12

Hi all, > I'd like to report that SPU not working for kernel > 4.9. The problem > caused by spe_context_run function, when call , it never return back. Looks like this also happens with the simple spu_run test:

Re: [PATCH] powerpc/64: Use tick accounting by default

Le 19/05/2017 à 16:41, Anton Blanchard a écrit : From: Anton Blanchard ppc64 is the only architecture that turns on VIRT_CPU_ACCOUNTING_NATIVE by default. The overhead of this option is extremely high - a context switch microbenchmark using sched_yield() is almost 20%

[PATCH 1/2] powerpc/fadump: add a warning when 'fadump_reserve_mem=' is used

With commit 11550dc0a00b ("powerpc/fadump: reuse crashkernel parameter for fadump memory reservation"), 'fadump_reserve_mem=' parameter is deprecated in favor of 'crashkernel=' parameter. Add a warning if 'fadump_reserve_mem=' is still used. Suggested-by: Prarit Bhargava

SPU not working for kernel 4.9, 4.10, 4.11a and 4.12

Dear Sir, I'd like to report that SPU not working for kernel > 4.9. The problem caused by spe_context_run function, when call , it never return back. Please see my attached file. My current system (working fine) Gentoo kernel 4.4.69 libspe2-2.2.80_p95-r1 gcc-6.3.0 spu-elf-gcc-5.3.0 Bets

Re: [PATCH 2/2] powerpc/fadump: update about offset where fadump is reserved

On Mon, 22 May 2017 15:04:47 +0530 Hari Bathini wrote: > With commit f6e6bedb7731 ("powerpc/fadump: Reserve memory at an offset > closer to bottom of RAM"), memory for fadump is no longer reserved at > the top of RAM. But there are still a few places which say so.

Re: [PATCH] powerpc/sequoia: fix NAND partitions not to overlap

Pavel Machek writes: > Hi! > >> >>> > > Signed-off-by: Pavel Machek >> >>> > >> >>> > Ping? Two partitions at same place are bad news... >> >>> >> >>> Please expand on "bad news"? What are the runtime effects of this >> >>> change? Decisions about which

[PATCH 2/2] powerpc/fadump: update about offset where fadump is reserved

With commit f6e6bedb7731 ("powerpc/fadump: Reserve memory at an offset closer to bottom of RAM"), memory for fadump is no longer reserved at the top of RAM. But there are still a few places which say so. Change them appropriately. Signed-off-by: Hari Bathini ---

Re: [kernel-hardening] [PATCH 1/2] powerpc: Don't fortify prom_init

Daniel Axtens writes: > prom_init is a bit special; in theory it should be able to be > linked separately to the kernel. To keep this from getting too > complex, the symbols that prom_init.c uses are checked. > > Fortification adds symbols, and it gets quite messy as it includes

Re: RFC: better timer interface

On Sun, May 21, 2017 at 8:14 PM, Thomas Gleixner wrote: > On Sun, 21 May 2017, Thomas Gleixner wrote: >> On Tue, 16 May 2017, Arnd Bergmann wrote: >> > On Tue, May 16, 2017 at 5:51 PM, Christoph Hellwig wrote: >> > > Yes, that sounds useful to me as well. As you

Re: RFC: better timer interface

On Sun, May 21, 2017 at 7:13 PM, Thomas Gleixner wrote: > On Tue, 16 May 2017, Arnd Bergmann wrote: >> On Tue, May 16, 2017 at 5:51 PM, Christoph Hellwig wrote: >> > Yes, that sounds useful to me as well. As you said it's an independent >> > but somewhat related

Re: [PATCH v4 00/20] eeprom: at24: Add OF device ID table

Hi Javier, On Mon, May 22, 2017 at 4:01 PM, Javier Martinez Canillas wrote: > This series is a follow-up to patch [0] that added an OF device ID table > to the at24 EEPROM driver. As you suggested [1], this version instead of > adding entries for every used

Re: [PATCH v4 00/20] eeprom: at24: Add OF device ID table

On Mon, May 22, 2017 at 9:23 AM, Geert Uytterhoeven wrote: > Hi Javier, > > On Mon, May 22, 2017 at 4:01 PM, Javier Martinez Canillas > wrote: >> This series is a follow-up to patch [0] that added an OF device ID table >> to the at24 EEPROM driver. As

Re: [PATCH v4 00/20] eeprom: at24: Add OF device ID table

On Mon, May 22, 2017 at 9:46 AM, Javier Martinez Canillas wrote: > Hello Geert and Rob, > > On Mon, May 22, 2017 at 4:26 PM, Rob Herring wrote: >> On Mon, May 22, 2017 at 9:23 AM, Geert Uytterhoeven >> wrote: >>> Hi Javier, >>> >>> On