Re: [PATCH v3] kallsyms: add support for relative offsets in kallsyms address table

On Fri, 22 Jan 2016 09:20:41 +0100 Ard Biesheuvel wrote: > > : in half since offsets can typically be expressed in 32 bits. > > : > """ > > In addition to fixing the broken grammar, would it make sense to > mention that dynamic relocation only occurs under >

Re: [PATCH v3] kallsyms: add support for relative offsets in kallsyms address table

On 22 January 2016 at 22:07, Andrew Morton wrote: > On Fri, 22 Jan 2016 09:20:41 +0100 Ard Biesheuvel > wrote: > >> > : in half since offsets can typically be expressed in 32 bits. >> > : >> """ >> >> In addition to fixing the broken

Re: [PATCH 1/3][v2] net: phy: introduce 1000BASE-KX and 10GBASE-KR

On 22.01.2016 09:15, Shaohui Xie wrote: ___ From: Andrew Lunn Sent: Friday, January 22, 2016 5:12 AM To: Shaohui Xie Cc: Sebastian Hesselbarth; Florian Fainelli; shh@gmail.com; devicet...@vger.kernel.org; net...@vger.kernel.org;

Re: [PATCH v3] kallsyms: add support for relative offsets in kallsyms address table

On 22 January 2016 at 00:20, Andrew Morton wrote: > On Thu, 21 Jan 2016 14:55:00 -0800 Kees Cook wrote: > >> IIUC, this means that the relocation work done after decompression now >> doesn't have to do relocation updates for all these values,

Re: [PATCH] qe_ic: fix a buffer overflow error and add check elsewhere

On Thu, Jan 21, 2016 at 9:06 AM, Zhao Qiang wrote: > 127 is the theoretical up boundary of QEIC number, > in fact there only be 44 qe_ic_info now. > add check to overflow for qe_ic_info > > Signed-off-by: Zhao Qiang Acked-by: Li Yang

[PATCH] powerpc: p1022: add two functions for reset pci slot

From: Wang Dongsheng When the DIU enable, only through the way of indirect access to read/write pixis register. So add direct and indirect for pci slot reset. Signed-off-by: Wang Dongsheng diff --git a/arch/powerpc/platforms/85xx/p1022_ds.c

Re: [PATCH 1/3][v2] net: phy: introduce 1000BASE-KX and 10GBASE-KR

>> Looking at fsl_backplane_config_aneg() you expect phydev->speed to be >> set, and from the speed you then kick of either KR autoneg or KX >> autoneg. Could you also start the training at this point? Use the >> speed to indicate if training is needed? > > [S.H]The training cannot be started at

Re: [PATCH] cxl: Add cxl_read_adapter_vpd() to the kernel API

Le 22/01/2016 01:38, Michael Neuling a écrit : On Thu, 2016-01-21 at 19:48 +0100, Frederic Barrat wrote: Le 20/01/2016 03:20, Michael Neuling a écrit : The only thing I'm a bit concerned about is are we going to end up duplicating a lot of the linux PCI API, but I guess we are only going to

Re: [PATCH] powerpc/mm: Allow user space to map rtas_rmo_buf

On 1/22/16, Michael Ellerman wrote: > On Fri, 2016-01-22 at 11:58 +0530, Vasant Hegde wrote: >> On 01/22/2016 10:59 AM, Michael Ellerman wrote: >> > On Thu, 2016-01-21 at 21:45 +0530, Vasant Hegde wrote: >> > >> > > With commit 90a545e9 (restrict /dev/mem to idle io memory

[RFC] Fix si->si_code for guard page access on PowerPC

Fix si->si_code for guard page access on PowerPC Currently, the mm code on PowerPC/POWER returns a si->si_code = 2 (SEGV_ACCERR) when the stack tries to grow beyond the stack guard (stack ulimit). On other architectures, notably x86, the si->si_code returned when a guard page access occurs is 1

Re: [PATCH] powerpc: Enable VMX copy on PPC970 (G5)

On Thu, Jan 21, 2016 at 11:25:27AM +1100, Michael Ellerman wrote: > There's no reason I'm aware of that the VMX copy loop shouldn't work on > PPC970. And in fact it seems to boot and generally be happy. But is it faster? Segher ___ Linuxppc-dev

Re: [PATCH] powerpc/mm: Allow user space to map rtas_rmo_buf

On Fri, 2016-01-22 at 11:58 +0530, Vasant Hegde wrote: > On 01/22/2016 10:59 AM, Michael Ellerman wrote: > > On Thu, 2016-01-21 at 21:45 +0530, Vasant Hegde wrote: > > > > > With commit 90a545e9 (restrict /dev/mem to idle io memory ranges) mapping > > > rtas_rmo_buf from user space is failing.

Re: [PATCH 1/3][v2] net: phy: introduce 1000BASE-KX and 10GBASE-KR

___ From: Andrew Lunn Sent: Friday, January 22, 2016 5:12 AM To: Shaohui Xie Cc: Sebastian Hesselbarth; Florian Fainelli; shh@gmail.com; devicet...@vger.kernel.org; net...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;

Re: [PATCH] powerpc: Enable VMX copy on PPC970 (G5)

On Fri, 2016-01-22 at 02:08 -0600, Segher Boessenkool wrote: > On Thu, Jan 21, 2016 at 11:25:27AM +1100, Michael Ellerman wrote: > > There's no reason I'm aware of that the VMX copy loop shouldn't work on > > PPC970. And in fact it seems to boot and generally be happy. > > But is it faster? Well

[PATCH] dts/fsl/powerpc: add "jedec, spi-nor" flash compatible binding

From: Hou Zhiqiang Starting with commit <8947e396a829> ("Documentation: dt: mtd: replace "nor-jedec" binding with "jedec, spi-nor"") we have "jedec,spi-nor" binding indicating support for JEDEC identification. Use it for all flashes that are supposed to support READ

Re: [PATCH v3] kallsyms: add support for relative offsets in kallsyms address table

On Thu, 21 Jan 2016 18:19:43 +0100 Ard Biesheuvel wrote: > Similar to how relative extables are implemented, it is possible to emit > the kallsyms table in such a way that it contains offsets relative to some > anchor point in the kernel image rather than absolute

Re: [PATCH v3] kallsyms: add support for relative offsets in kallsyms address table

On Fri, 22 Jan 2016 15:34:28 -0800 Andrew Morton wrote: > > Support for the above is enabled by default for all architectures except > > IA-64, whose symbols are too far apart to capture in this manner. > > scripts/kallsyms.c: In function 'record_relative_base': >

Re: [PATCH kernel] vfio: Only check for bus IOMMU when NOIOMMU is selected

On Fri, 2016-01-22 at 17:34 +1100, Alexey Kardashevskiy wrote: > Recent change 03a76b60 "vfio: Include No-IOMMU mode" disabled VFIO > on systems which do not implement iommu_ops for the PCI bus even > though > there is an VFIO IOMMU driver for it such as SPAPR TCE driver for > PPC64/powernv

Re: [PATCH 1/3][v2] net: phy: introduce 1000BASE-KX and 10GBASE-KR

Hi, I'm not sure I explained myself clearly in previous reply, so I guess it's worth to rephrase it. 1000BASE-KX and 10GBASE-KR are backplane modes supported by Freescale's PCS PHY, but different modes need different hardware settings, not just different PHY init routines, this also needs

Re: [PATCH 1/3][v2] net: phy: introduce 1000BASE-KX and 10GBASE-KR

> The reason I mentioned maybe I should put the backplane property in > fsl's binding is because the backplane implementation is really > vendor specific, it's heavily relay how hardware implements the > feature, maybe another vendor's hardware only needs a boolean > property for driver to tell it