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

[Andrew Morton]

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
> CONFIG_RELOCATABLE=y? I.e., something like
> 
> """
> On 64-bit architectures, it cuts the size of the kallsyms address
> table in half, since offsets between kernel symbols can typically be
> expressed in 32 bits. This saves several hundreds of kilobytes of
> permanent .rodata on average. In addition, the kallsyms address table
> is no longer subject to dynamic relocation when CONFIG_RELOCATABLE is
> in effect, so the relocation work done after decompression now doesn't
> have to do relocation updates for all these values. This saves up to
> 24 bytes (i.e., the size of a ELF64 RELA relocation table entry) per
> table entry, which easily adds up to a couple of megabytes of
> uncompressed __init data on ppc64 or arm64. Even if these relocation
> entries typically compress well, the combined size reduction of 2.8 MB
> uncompressed for a ppc64_defconfig build (of which 2.4 MB is __init
> data) results in a ~500 KB space saving in the compressed image.
> """

Yes, that sounds very good.  I'd buy one :)

Can you please send along a complete new changelog sometime?
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

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

[Ard Biesheuvel]

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 grammar, would it make sense to
>> mention that dynamic relocation only occurs under
>> CONFIG_RELOCATABLE=y? I.e., something like
>>
>> """
>> On 64-bit architectures, it cuts the size of the kallsyms address
>> table in half, since offsets between kernel symbols can typically be
>> expressed in 32 bits. This saves several hundreds of kilobytes of
>> permanent .rodata on average. In addition, the kallsyms address table
>> is no longer subject to dynamic relocation when CONFIG_RELOCATABLE is
>> in effect, so the relocation work done after decompression now doesn't
>> have to do relocation updates for all these values. This saves up to
>> 24 bytes (i.e., the size of a ELF64 RELA relocation table entry) per
>> table entry, which easily adds up to a couple of megabytes of
>> uncompressed __init data on ppc64 or arm64. Even if these relocation
>> entries typically compress well, the combined size reduction of 2.8 MB
>> uncompressed for a ppc64_defconfig build (of which 2.4 MB is __init
>> data) results in a ~500 KB space saving in the compressed image.
>> """
>
> Yes, that sounds very good.  I'd buy one :)
>

Did I tell you about the extended warranty?

> Can you please send along a complete new changelog sometime?

Sure:

"""
kallsyms: add support for relative offsets in kallsyms address table

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

On 64-bit architectures, it cuts the size of the kallsyms address table in
half, since offsets between kernel symbols can typically be expressed in 32
bits. This saves several hundreds of kilobytes of permanent .rodata on
average. In addition, the kallsyms address table is no longer subject to
dynamic relocation when CONFIG_RELOCATABLE is in effect, so the relocation
work done after decompression now doesn't have to do relocation updates for
all these values. This saves up to 24 bytes (i.e., the size of a ELF64 RELA
relocation table entry) per value, which easily adds up to a couple of
megabytes of uncompressed __init data on ppc64 or arm64. Even if these
relocation entries typically compress well, the combined size reduction of
2.8 MB uncompressed for a ppc64_defconfig build (of which 2.4 MB is __init
data) results in a ~500 KB space saving in the compressed image.

Since it is useful for some architectures (like x86) to retain the ability
to emit absolute values as well, this patch adds support for both, by
emitting absolute addresses as positive 32-bit values, and addresses
relative to the lowest encountered relative symbol as negative values,
which are subtracted from the runtime address of this base symbol to
produce the actual address.

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.

Acked-by: Heiko Carstens 
Tested-by: Michael Ellerman  # powerpc
Tested-by: Kees Cook  # x86_64
Reviewed-by: Kees Cook 
Signed-off-by: Ard Biesheuvel 
"""

Thanks,
Ard.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

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

[Sebastian Hesselbarth]

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; 
linuxppc-dev@lists.ozlabs.org; da...@davemloft.net; Shaohui Xie
Subject: Re: [PATCH 1/3][v2] net: phy: introduce 1000BASE-KX and 10GBASE-KR

On Tue, Jan 19, 2016 at 05:00:35AM +, Shaohui Xie wrote:

-Original Message-
From: Andrew Lunn [mailto:and...@lunn.ch]
Sent: Monday, January 18, 2016 11:15 PM
To: Shaohui Xie
Cc: Sebastian Hesselbarth; Florian Fainelli; shh@gmail.com;
devicet...@vger.kernel.org; net...@vger.kernel.org; linuxppc-
d...@lists.ozlabs.org; da...@davemloft.net; Shaohui Xie
Subject: Re: [PATCH 1/3][v2] net: phy: introduce 1000BASE-KX and 10GBASE-KR


[S.H] the fsl backplane, e.g. 10GBASE-KR, needs software to handle
link training, It's to train link partner, and trained by link partner

parallel.


But if media type is not copper, e.g. optical module, we won't need this.


So what we actually need to know is copper vs fibre?



Copper is not enough to indicate backplane, since backplane is
always copper, but copper is not always backplane.



O.K, lets try again


[S.H]Seems I did not get your point, Sorry for the inconvenient.


If it is copper backplane you need to perform training.



Looking at the driver probe function, it is either 1000BASE-KX, no
training needed, or else it is 10GBASE-RK and training is needed.



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 this point, yet, because it's based on
autoneg result, only when both sides autoneg-ed to 10G-KR, then to start
the training.


Shaohui,

look, we want you to convince us why to have a generic backplane
property in the phy binding. You had a bad start by adding new
property values to a property that does not relate to your use
case at all. Your job now really is to give strong reasons _why_
and _what_ a phy driver needs to know about the backplane setup.

Your first approach was to add "10gbase-rk" or "40gbase-foo" but
now you tell us about ANEG. Of what use is the information given
by the property when ANEG tells you something different? E.g.
consider the property tells you "10g-something" but ANEG gives
you "40g"; does the property add any value to your training
decision now?


Besides the driver, generally speaking, "copper + speed" is not enough to 
indicate
it's backplane, for ex. "copper + 1000" does not mean it has to be 1000BASE-KX,
it could be SGMII, hence cannot use KX autoneg.


So, is it copper + speed + backplane? or speed + backplane? And out of
the set of required input, is there anything your _cannot_ determine
from other things, e.g. ANEG?

If it is backplane only, would a boolean property ("backplane-mode")
be enough for the training decision?


If putting backplane property to phy.txt is not good, I can put it to fsl 
specific
binding, like the second patch 2/3 did.


You seem to see vendor specific properties as a place to dump all your
waste you don't want to think about. You fail to give good reasons what
is so special about the backplane setup and now you are telling us that
it is even fsl-specific?

Sebastian

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

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

[Ard Biesheuvel]

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, which
>> means a smaller relocation table as well.
>
> Makes sense, thanks.  I altered the changelog
>
> : 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
> : addresses.
> :

Thanks for taking the patch, but the bit below does not make sense anymore:

"""
> : The benefit is that such table entries are no longer subject to dynamic
> : relocation when the build time so the relocation work done after
> : decompression now doesn't have to do relocation updates for all these
> : values, which means a smaller relocation table as well.
> :
> : Also, the runtime offsets of the kernel image are different.  Also, on
> : 64-bit architectures, it essentially cuts the size of the address table
> : 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
CONFIG_RELOCATABLE=y? I.e., something like

"""
On 64-bit architectures, it cuts the size of the kallsyms address
table in half, since offsets between kernel symbols can typically be
expressed in 32 bits. This saves several hundreds of kilobytes of
permanent .rodata on average. In addition, the kallsyms address table
is no longer subject to dynamic relocation when CONFIG_RELOCATABLE is
in effect, so the relocation work done after decompression now doesn't
have to do relocation updates for all these values. This saves up to
24 bytes (i.e., the size of a ELF64 RELA relocation table entry) per
table entry, which easily adds up to a couple of megabytes of
uncompressed __init data on ppc64 or arm64. Even if these relocation
entries typically compress well, the combined size reduction of 2.8 MB
uncompressed for a ppc64_defconfig build (of which 2.4 MB is __init
data) results in a ~500 KB space saving in the compressed image.
"""

Thanks,
Ard.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

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

[Leo Li]

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 

Regards,
Leo
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

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

[Dongsheng Wang]

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 
b/arch/powerpc/platforms/85xx/p1022_ds.c
index 371df82..5c8894c 100644
--- a/arch/powerpc/platforms/85xx/p1022_ds.c
+++ b/arch/powerpc/platforms/85xx/p1022_ds.c
@@ -53,23 +53,6 @@
 #define CLKDVDR_PXCKDLY0x0600
 #define CLKDVDR_PXCLK_MASK 0x00FF
 
-/* Some ngPIXIS register definitions */
-#define PX_CTL 3
-#define PX_BRDCFG0 8
-#define PX_BRDCFG1 9
-
-#define PX_BRDCFG0_ELBC_SPI_MASK   0xc0
-#define PX_BRDCFG0_ELBC_SPI_ELBC   0x00
-#define PX_BRDCFG0_ELBC_SPI_NULL   0xc0
-#define PX_BRDCFG0_ELBC_DIU0x02
-
-#define PX_BRDCFG1_DVIEN   0x80
-#define PX_BRDCFG1_DFPEN   0x40
-#define PX_BRDCFG1_BACKLIGHT   0x20
-#define PX_BRDCFG1_DDCEN   0x10
-
-#define PX_CTL_ALTACC  0x80
-
 /*
  * DIU Area Descriptor
  *
@@ -106,6 +89,28 @@
(c2 << AD_COMP_2_SHIFT) | (c1 << AD_COMP_1_SHIFT) | \
(c0 << AD_COMP_0_SHIFT) | (size << AD_PIXEL_S_SHIFT))
 
+#endif
+
+/* Some ngPIXIS register definitions */
+#define PX_CTL 3
+#define PX_BRDCFG0 8
+#define PX_BRDCFG1 9
+
+#define PX_RST 0x4
+#define PX_RST_PCIE0x8
+
+#define PX_BRDCFG0_ELBC_SPI_MASK   0xc0
+#define PX_BRDCFG0_ELBC_SPI_ELBC   0x00
+#define PX_BRDCFG0_ELBC_SPI_NULL   0xc0
+#define PX_BRDCFG0_ELBC_DIU0x02
+
+#define PX_BRDCFG1_DVIEN   0x80
+#define PX_BRDCFG1_DFPEN   0x40
+#define PX_BRDCFG1_BACKLIGHT   0x20
+#define PX_BRDCFG1_DDCEN   0x10
+
+#define PX_CTL_ALTACC  0x80
+
 struct fsl_law {
u32 lawbar;
u32 reserved1;
@@ -125,6 +130,8 @@ struct fsl_law {
 
 #define BR_BA  0x8000
 
+static int px_ctl_altacc_flag;
+
 /*
  * Map a BRx value to a physical address
  *
@@ -157,48 +164,40 @@ static phys_addr_t lbc_br_to_phys(const void *ecm, 
unsigned int count, u32 br)
 #endif
 }
 
-/**
- * p1022ds_set_monitor_port: switch the output to a different monitor port
- */
-static void p1022ds_set_monitor_port(enum fsl_diu_monitor_port port)
+static u8 __iomem *lbc_lcs0_ba;
+static u8 __iomem *lbc_lcs1_ba;
+
+static inline bool verify_pixis_indirect_access_address(void)
 {
-   struct device_node *guts_node;
-   struct device_node *lbc_node = NULL;
-   struct device_node *law_node = NULL;
-   struct ccsr_guts __iomem *guts;
-   struct fsl_lbc_regs *lbc = NULL;
+   if (lbc_lcs0_ba && lbc_lcs1_ba)
+   return true;
+
+   return false;
+}
+
+static void indirect_access_pixis_probe(void)
+{
+   struct device_node *lbc_node;
+   struct device_node *law_node;
+   struct fsl_lbc_regs *lbc;
void *ecm = NULL;
-   u8 __iomem *lbc_lcs0_ba = NULL;
-   u8 __iomem *lbc_lcs1_ba = NULL;
+
phys_addr_t cs0_addr, cs1_addr;
u32 br0, or0, br1, or1;
const __be32 *iprop;
unsigned int num_laws;
-   u8 b;
-
-   /* Map the global utilities registers. */
-   guts_node = of_find_compatible_node(NULL, NULL, "fsl,p1022-guts");
-   if (!guts_node) {
-   pr_err("p1022ds: missing global utilities device node\n");
-   return;
-   }
-
-   guts = of_iomap(guts_node, 0);
-   if (!guts) {
-   pr_err("p1022ds: could not map global utilities device\n");
-   goto exit;
-   }
 
lbc_node = of_find_compatible_node(NULL, NULL, "fsl,p1022-elbc");
if (!lbc_node) {
pr_err("p1022ds: missing localbus node\n");
-   goto exit;
+   return;
}
 
lbc = of_iomap(lbc_node, 0);
+   of_node_put(lbc_node);
if (!lbc) {
pr_err("p1022ds: could not map localbus node\n");
-   goto exit;
+   return;
}
 
law_node = of_find_compatible_node(NULL, NULL, "fsl,ecm-law");
@@ -282,7 +281,103 @@ static void p1022ds_set_monitor_port(enum 
fsl_diu_monitor_port port)
if (!lbc_lcs1_ba) {
pr_err("p1022ds: could not ioremap CS1 address %llx\n",
   (unsigned long long)cs1_addr);
-   goto exit;
+
+   iounmap(lbc_lcs0_ba);
+   }
+
+exit:
+   if (ecm)
+   iounmap(ecm);
+   if (lbc)
+   iounmap(lbc);
+
+   if (law_node)
+   of_node_put(law_node);
+}
+
+static void indirect_access_pixis_reset_pcie_slot(void)
+{
+   if (!verify_pixis_indirect_access_address()) {
+   WARN_ON(1);
+   return;
+   }
+
+   /* Set FPGA access address */
+   out_8(lbc_lcs0_ba, PX_RST);
+
+   /* power down pcie slot */
+   clrbits8(lbc_lcs1_ba, PX_RST_PCIE);
+
+   /* power up pcie slot */
+   setbits8(lbc_lcs1_ba, 

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

[Shaohui Xie]

>> 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 this point, yet, because it's based 
> on
> autoneg result, only when both sides autoneg-ed to 10G-KR, then to start
> the training.

Shaohui,

look, we want you to convince us why to have a generic backplane
property in the phy binding. You had a bad start by adding new
property values to a property that does not relate to your use
case at all. Your job now really is to give strong reasons _why_
and _what_ a phy driver needs to know about the backplane setup.

[S.H] The PHY driver needs to know what the backplane mode is, 
1000BASE-KX or 10GBASE-KR, the driver parses the property for
"1000base-kx" or "10gbase-kr", the driver does use the property,
I don't understand why the property is not related to my use case?

Your first approach was to add "10gbase-rk" or "40gbase-foo" but
now you tell us about ANEG. Of what use is the information given
by the property when ANEG tells you something different? E.g.
consider the property tells you "10g-something" but ANEG gives
you "40g"; does the property add any value to your training
decision now?

[S.H] The ANEG is not a gerneric AN, it's special to 10G-KR,  KR AN can only
AN to KR if both sides support KR, it cannot give "40g" or anything different, 
drive needs the property to do speicific init.

> Besides the driver, generally speaking, "copper + speed" is not enough to 
> indicate
> it's backplane, for ex. "copper + 1000" does not mean it has to be 
> 1000BASE-KX,
> it could be SGMII, hence cannot use KX autoneg.

So, is it copper + speed + backplane? or speed + backplane? And out of
the set of required input, is there anything your _cannot_ determine
from other things, e.g. ANEG?

[S.H] Backplane is enough, 1000BASE-KX means : copper + 1000 + KX stuff.
The KR AN is to check whether LP is also KR, if yes, do training, otherwise, do 
nothing.

If it is backplane only, would a boolean property ("backplane-mode")
be enough for the training decision?

[S.H] a boolean property is not enough, there are different backplane modes.

> If putting backplane property to phy.txt is not good, I can put it to fsl 
> specific
> binding, like the second patch 2/3 did.

You seem to see vendor specific properties as a place to dump all your
waste you don't want to think about. You fail to give good reasons what
is so special about the backplane setup and now you are telling us that
it is even fsl-specific?

[S.H] I don't think it's waste, I just thought it might be special to fsl.
Agreed I failed to give good reasons, but I tried hard to. :(

Thanks,
Shaohui

Sebastian

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

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

[Frederic Barrat]

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 do this for things the papr HCALL interface mimics.


There are actually very few operations we can do on the adapter with
hcalls. papr defines 'reset', 'read the VPD' and flashing a new image on
the card. So we'll soon run out of APIs to mimic.

I guess it means the usage of cxl_get_phys_dev() should be discouraged,
since it's going to lead to different behaviors between bare-metal and
powerVM guest. Was there another expected use case for a kernel driver
other than accessing the VPD?


It was just for VPD.  I figured it was the easiest way to add it. Maybe
it's worth getting rid of it in favour of VPD only.

If you want to remove it I'd be happy, but you'll need to coordinate
with the cxlflash driver.  You can probably just write the patch for
them and then get their ACK on it.


Ok, then I would also be tempted to remove it. I'll sync with cxlflash 
to do so.

Thanks!

  Fred

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

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

[Denis Kirjanov]

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 ranges)
>> > > mapping
>> > > rtas_rmo_buf from user space is failing. Hence we are not able to make
>> > > RTAS syscall.
>> >
>> > Having said that, why the  is librtas mapping
>> > /dev/mem in
>> > the first place? Unless there is a very good reason, and probably even
>> > if there
>> > is, we should fix that to use a sane API.
>>
>> We use rtas system call. We use /dev/mem interface to map the RTAS memory
>> region
>> (allocated by kernel and information is passed to user space via procfs)
>> so that
>> we can read/write to RTAS memory.
>>
>> I do not have historical information. May be Nathan has more information
>> on this.
>
> Yeah, we need to dig into what it's actually doing and why. I had a quick
> look
> but it wasn't obvious.
>
> We should not need 1) a system call, 2) a proc interface, and 3) a mmap of
> /dev/mem.
>
> If the syscall's not sufficient and we really need to mmap, we should create
> a
> device which can then be mmapped in a more standard way.
>
> Having said that, Nathan's been moving more of the hotplug logic into the
> kernel, so I'm also not clear on how much of the existing API we will need
> in
> the future. So yep hopefully Nathan can chime in.

Yeah, but if we're going to move to only one interface to work with
RTAS we can break existing applications.

>
> cheers
>
> ___
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

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

[Gustavo Romero]

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

Although si->si_code is not historically reliable and hence no
program should trust it for any semantic behavior, the right
si->si_code for a guard page access is 1 (SEGV_MAPERR) and,
besides that, some tests still trust it in specific cases.

On PowerPC/POWER, if the mm tries to expand the stack and
hits a page mapped by the program (say, an anonymous page
with permission ---p) it generates a SIG_SEGV and a si->si_code = 2
(SEGV_ACCERR), the same way it happens on x86. But then, when this
guard page is removed (un-mapped) and the stack grows again reaching
the stack guard (stack ulimit), the mm generates a SIG_SEGV and a
si->si_code = 2 (SEGV_ACCERR) again, contrary to, for example,
what happens on x86 (si->si_code = 1 (SIG_MAPERR)). It means that
on PowerPC/POWER there is no semantic difference between a stack
growth hitting a mapped area the stack has no permission to rd/wr
and reaching the stack limit (stack ulimit), although indeed there
is a difference.

Signed-off-by: Gustavo Romero 
---
 arch/powerpc/mm/fault.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c
index a67c6d7..6954971 100644
--- a/arch/powerpc/mm/fault.c
+++ b/arch/powerpc/mm/fault.c
@@ -431,8 +431,10 @@ good_area:
   */
  fault = handle_mm_fault(mm, vma, address, flags);
  if (unlikely(fault & (VM_FAULT_RETRY|VM_FAULT_ERROR))) {
-  if (fault & VM_FAULT_SIGSEGV)
+  if (fault & VM_FAULT_SIGSEGV) {
+   code = SEGV_MAPERR;
goto bad_area;
+  }
   rc = mm_fault_error(regs, address, fault);
   if (rc >= MM_FAULT_RETURN)
goto bail;

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

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

[Segher Boessenkool]

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 mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

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

[Michael Ellerman]

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. Hence we are not able to make
> > > RTAS syscall.
> > 
> > Having said that, why the  is librtas mapping /dev/mem in
> > the first place? Unless there is a very good reason, and probably even if 
> > there
> > is, we should fix that to use a sane API.
> 
> We use rtas system call. We use /dev/mem interface to map the RTAS memory 
> region
> (allocated by kernel and information is passed to user space via procfs) so 
> that
> we can read/write to RTAS memory.
> 
> I do not have historical information. May be Nathan has more information on 
> this.

Yeah, we need to dig into what it's actually doing and why. I had a quick look
but it wasn't obvious.

We should not need 1) a system call, 2) a proc interface, and 3) a mmap of
/dev/mem.

If the syscall's not sufficient and we really need to mmap, we should create a
device which can then be mmapped in a more standard way.

Having said that, Nathan's been moving more of the hotplug logic into the
kernel, so I'm also not clear on how much of the existing API we will need in
the future. So yep hopefully Nathan can chime in.

cheers

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

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

[Shaohui Xie]

___
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; da...@davemloft.net; Shaohui Xie
Subject: Re: [PATCH 1/3][v2] net: phy: introduce 1000BASE-KX and 10GBASE-KR

On Tue, Jan 19, 2016 at 05:00:35AM +, Shaohui Xie wrote:
> > -Original Message-
> > From: Andrew Lunn [mailto:and...@lunn.ch]
> > Sent: Monday, January 18, 2016 11:15 PM
> > To: Shaohui Xie
> > Cc: Sebastian Hesselbarth; Florian Fainelli; shh@gmail.com;
> > devicet...@vger.kernel.org; net...@vger.kernel.org; linuxppc-
> > d...@lists.ozlabs.org; da...@davemloft.net; Shaohui Xie
> > Subject: Re: [PATCH 1/3][v2] net: phy: introduce 1000BASE-KX and 10GBASE-KR
> >
> > > [S.H] the fsl backplane, e.g. 10GBASE-KR, needs software to handle
> > > link training, It's to train link partner, and trained by link partner
> > parallel.
> > >
> > > But if media type is not copper, e.g. optical module, we won't need this.
> >
> > So what we actually need to know is copper vs fibre?

> Copper is not enough to indicate backplane, since backplane is
> always copper, but copper is not always backplane.

>O.K, lets try again

[S.H]Seems I did not get your point, Sorry for the inconvenient.

>If it is copper backplane you need to perform training.

>Looking at the driver probe function, it is either 1000BASE-KX, no
>training needed, or else it is 10GBASE-RK and training is needed.

>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 this point, yet, because it's based on 
autoneg result, only when both sides autoneg-ed to 10G-KR, then to start
the training.

Besides the driver, generally speaking, "copper + speed" is not enough to 
indicate 
it's backplane, for ex. "copper + 1000" does not mean it has to be 1000BASE-KX, 
it could be SGMII, hence cannot use KX autoneg.

If putting backplane property to phy.txt is not good, I can put it to fsl 
specific
binding, like the second patch 2/3 did.

Thank you!
Shaohui
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

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

[Michael Ellerman]

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 Anton wrote it, so of course it is. ;)

Will try and get some numbers.

cheers

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

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

[Zhiqiang Hou]

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 ID op
according to the datasheets.

Signed-off-by: Hou Zhiqiang 
---
Tested on T1042D4RDB

 arch/powerpc/boot/dts/fsl/b4qds.dtsi   | 2 +-
 arch/powerpc/boot/dts/fsl/bsc9131rdb.dtsi  | 2 +-
 arch/powerpc/boot/dts/fsl/bsc9132qds.dtsi  | 2 +-
 arch/powerpc/boot/dts/fsl/c293pcie.dts | 2 +-
 arch/powerpc/boot/dts/fsl/kmcoge4.dts  | 4 ++--
 arch/powerpc/boot/dts/fsl/mpc8536ds.dtsi   | 8 
 arch/powerpc/boot/dts/fsl/mvme2500.dts | 4 ++--
 arch/powerpc/boot/dts/fsl/p1010rdb.dtsi| 2 +-
 arch/powerpc/boot/dts/fsl/p1020rdb-pc.dtsi | 2 +-
 arch/powerpc/boot/dts/fsl/p1020rdb-pd.dts  | 2 +-
 arch/powerpc/boot/dts/fsl/p1020rdb.dtsi| 2 +-
 arch/powerpc/boot/dts/fsl/p1021mds.dts | 2 +-
 arch/powerpc/boot/dts/fsl/p1021rdb-pc.dtsi | 2 +-
 arch/powerpc/boot/dts/fsl/p1022ds.dtsi | 2 +-
 arch/powerpc/boot/dts/fsl/p1022rdk.dts | 2 +-
 arch/powerpc/boot/dts/fsl/p1024rdb.dtsi| 2 +-
 arch/powerpc/boot/dts/fsl/p1025rdb.dtsi| 2 +-
 arch/powerpc/boot/dts/fsl/p2020rdb-pc.dtsi | 2 +-
 arch/powerpc/boot/dts/fsl/p2020rdb.dts | 2 +-
 arch/powerpc/boot/dts/fsl/p2041rdb.dts | 2 +-
 arch/powerpc/boot/dts/fsl/p3041ds.dts  | 2 +-
 arch/powerpc/boot/dts/fsl/p4080ds.dts  | 2 +-
 arch/powerpc/boot/dts/fsl/p5020ds.dts  | 2 +-
 arch/powerpc/boot/dts/fsl/p5040ds.dts  | 2 +-
 arch/powerpc/boot/dts/fsl/t1023rdb.dts | 2 +-
 arch/powerpc/boot/dts/fsl/t1024qds.dts | 6 +++---
 arch/powerpc/boot/dts/fsl/t1024rdb.dts | 2 +-
 arch/powerpc/boot/dts/fsl/t104xd4rdb.dtsi  | 2 +-
 arch/powerpc/boot/dts/fsl/t104xqds.dtsi| 2 +-
 arch/powerpc/boot/dts/fsl/t104xrdb.dtsi| 2 +-
 arch/powerpc/boot/dts/fsl/t208xqds.dtsi| 6 +++---
 arch/powerpc/boot/dts/fsl/t208xrdb.dtsi| 2 +-
 arch/powerpc/boot/dts/fsl/t4240qds.dts | 2 +-
 arch/powerpc/boot/dts/fsl/t4240rdb.dts | 2 +-
 34 files changed, 43 insertions(+), 43 deletions(-)

diff --git a/arch/powerpc/boot/dts/fsl/b4qds.dtsi 
b/arch/powerpc/boot/dts/fsl/b4qds.dtsi
index 6455774..823824c 100644
--- a/arch/powerpc/boot/dts/fsl/b4qds.dtsi
+++ b/arch/powerpc/boot/dts/fsl/b4qds.dtsi
@@ -135,7 +135,7 @@
flash@0 {
#address-cells = <1>;
#size-cells = <1>;
-   compatible = "sst,sst25wf040";
+   compatible = "sst,sst25wf040", "jedec,spi-nor";
reg = <0>;
spi-max-frequency = <4000>; /* input clock 
*/
};
diff --git a/arch/powerpc/boot/dts/fsl/bsc9131rdb.dtsi 
b/arch/powerpc/boot/dts/fsl/bsc9131rdb.dtsi
index f4d96d2..53f8b95 100644
--- a/arch/powerpc/boot/dts/fsl/bsc9131rdb.dtsi
+++ b/arch/powerpc/boot/dts/fsl/bsc9131rdb.dtsi
@@ -53,7 +53,7 @@
flash@0 {
#address-cells = <1>;
#size-cells = <1>;
-   compatible = "spansion,s25sl12801";
+   compatible = "spansion,s25sl12801", "jedec,spi-nor";
reg = <0>;
spi-max-frequency = <5000>;
 
diff --git a/arch/powerpc/boot/dts/fsl/bsc9132qds.dtsi 
b/arch/powerpc/boot/dts/fsl/bsc9132qds.dtsi
index 7a13bf2..fead484 100644
--- a/arch/powerpc/boot/dts/fsl/bsc9132qds.dtsi
+++ b/arch/powerpc/boot/dts/fsl/bsc9132qds.dtsi
@@ -55,7 +55,7 @@
flash@0 {
#address-cells = <1>;
#size-cells = <1>;
-   compatible = "spansion,s25sl12801";
+   compatible = "spansion,s25sl12801", "jedec,spi-nor";
reg = <0>;
spi-max-frequency = <3000>;
};
diff --git a/arch/powerpc/boot/dts/fsl/c293pcie.dts 
b/arch/powerpc/boot/dts/fsl/c293pcie.dts
index 53ab4db..6670978 100644
--- a/arch/powerpc/boot/dts/fsl/c293pcie.dts
+++ b/arch/powerpc/boot/dts/fsl/c293pcie.dts
@@ -167,7 +167,7 @@
flash@0 {
#address-cells = <1>;
#size-cells = <1>;
-   compatible = "spansion,s25sl12801";
+   compatible = "spansion,s25sl12801", "jedec,spi-nor";
reg = <0>;
spi-max-frequency = <5000>;
 
diff --git a/arch/powerpc/boot/dts/fsl/kmcoge4.dts 
b/arch/powerpc/boot/dts/fsl/kmcoge4.dts
index 6858ec9..2d4b64f 100644
--- a/arch/powerpc/boot/dts/fsl/kmcoge4.dts
+++ b/arch/powerpc/boot/dts/fsl/kmcoge4.dts
@@ -63,7 +63,7 @@
flash@0 {
#address-cells = <1>;
 

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

[Andrew Morton]

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 addresses. The benefit
> is that such table entries are no longer subject to dynamic relocation when
> the build time and runtime offsets of the kernel image are different. Also,
> on 64-bit architectures, it essentially cuts the size of the address table
> in half since offsets can typically be expressed in 32 bits.
> 
> Since it is useful for some architectures (like x86) to retain the ability
> to emit absolute values as well, this patch adds support for both, by
> emitting absolute addresses as positive 32-bit values, and addresses
> relative to the lowest encountered relative symbol as negative values, which
> are subtracted from the runtime address of this base symbol to produce the
> actual address.
> 
> 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':
scripts/kallsyms.c:744: error: 'ULLONG_MAX' undeclared (first use in this 
function)
scripts/kallsyms.c:744: error: (Each undeclared identifier is reported only once
scripts/kallsyms.c:744: error: for each function it appears in.)

That's with (ancient) glibc-headers-2.5-3.  It appears that limits.h's
ULLONG_MAX requires "#ifdef __USE_ISOC99".  I'm not sure what's the
correct way of turning this on.

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

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

[Andrew Morton]

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':
> scripts/kallsyms.c:744: error: 'ULLONG_MAX' undeclared (first use in this 
> function)
> scripts/kallsyms.c:744: error: (Each undeclared identifier is reported only 
> once
> scripts/kallsyms.c:744: error: for each function it appears in.)
> 
> That's with (ancient) glibc-headers-2.5-3.  It appears that limits.h's
> ULLONG_MAX requires "#ifdef __USE_ISOC99".  I'm not sure what's the
> correct way of turning this on.

Actually, how about we replace it with -1ULL and get on with life.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

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

[Alex Williamson]

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 platform.
> 
> This moves iommu_present() call under #ifdef CONFIG_VFIO_NOIOMMU as
> it is done in the rest of the file to re-enable VFIO on powernv.
> 
> Signed-off-by: Alexey Kardashevskiy 
> ---
>  drivers/vfio/vfio.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
> index 82f25cc..3f8060e 100644
> --- a/drivers/vfio/vfio.c
> +++ b/drivers/vfio/vfio.c
> @@ -343,7 +343,6 @@ static struct vfio_group
> *vfio_create_group(struct iommu_group *iommu_group,
>   atomic_set(>opened, 0);
>   group->iommu_group = iommu_group;
>   group->noiommu = !iommu_present;
> -
>   group->nb.notifier_call = vfio_iommu_group_notifier;
>  
>   /*
> @@ -767,7 +766,11 @@ int vfio_add_group_dev(struct device *dev,
>  
>   group = vfio_group_get_from_iommu(iommu_group);
>   if (!group) {
> +#ifdef CONFIG_VFIO_NOIOMMU
>   group = vfio_create_group(iommu_group,
> iommu_present(dev->bus));
> +#else
> + group = vfio_create_group(iommu_group, true);
> +#endif
>   if (IS_ERR(group)) {
>   iommu_group_put(iommu_group);
>   return PTR_ERR(group);


A serious problem indeed, but this isn't the right solution.  I've
copied you on a patch that I think fixes it.  Please verify.  Thanks,

Alex
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

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

[Shaohui Xie]

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 different serdes lane settings, this is done in 
probe() according
to DTS properties.

Regarding the autoneg part, it's not like normal autoneg which can autoneg to 
different
capabilities, when the PHY is 1000BSE-KX, it can only autoneg to 1000BASE-KX 
only if
LP is 1000BASE-KX,  same is true for 10GBASE-KR. The purpose of KR AN is to 
detect whether
LP is also KR, if yes, do training, if not, do nothing, no any other result the 
KR AN can give.

The reason "copper + speed" is not enough for backplane is because they are not 
precise,
and backplane itself explains what it is, for ex. 1000BASE-KX clearly means the 
media is copper,
speed is 1000, and should follow 1000BASE-KX standard in IEEE802.3.

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 
should work in backplane, hardware can deal with different modes, or even no 
any special 
property needed if the hardware is strong enough to handle any connections, I 
cannot assume.
But I know what fsl's hardware needs to support backplane.

Thank you for your time and reviewing!
Shaohui


From: Shaohui Xie
Sent: Friday, January 22, 2016 6:05 PM
To: Sebastian Hesselbarth; Andrew Lunn
Cc: Florian Fainelli; shh@gmail.com; devicet...@vger.kernel.org; 
net...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; da...@davemloft.net; 
Shaohui Xie
Subject: 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 this point, yet, because it's based 
> on
> autoneg result, only when both sides autoneg-ed to 10G-KR, then to start
> the training.

Shaohui,

look, we want you to convince us why to have a generic backplane
property in the phy binding. You had a bad start by adding new
property values to a property that does not relate to your use
case at all. Your job now really is to give strong reasons _why_
and _what_ a phy driver needs to know about the backplane setup.

[S.H] The PHY driver needs to know what the backplane mode is,
1000BASE-KX or 10GBASE-KR, the driver parses the property for
"1000base-kx" or "10gbase-kr", the driver does use the property,
I don't understand why the property is not related to my use case?

Your first approach was to add "10gbase-rk" or "40gbase-foo" but
now you tell us about ANEG. Of what use is the information given
by the property when ANEG tells you something different? E.g.
consider the property tells you "10g-something" but ANEG gives
you "40g"; does the property add any value to your training
decision now?

[S.H] The ANEG is not a gerneric AN, it's special to 10G-KR,  KR AN can only
AN to KR if both sides support KR, it cannot give "40g" or anything different,
drive needs the property to do speicific init.

> Besides the driver, generally speaking, "copper + speed" is not enough to 
> indicate
> it's backplane, for ex. "copper + 1000" does not mean it has to be 
> 1000BASE-KX,
> it could be SGMII, hence cannot use KX autoneg.

So, is it copper + speed + backplane? or speed + backplane? And out of
the set of required input, is there anything your _cannot_ determine
from other things, e.g. ANEG?

[S.H] Backplane is enough, 1000BASE-KX means : copper + 1000 + KX stuff.
The KR AN is to check whether LP is also KR, if yes, do training, otherwise, do 
nothing.

If it is backplane only, would a boolean property ("backplane-mode")
be enough for the training decision?

[S.H] a boolean property is not enough, there are different backplane modes.

> If putting backplane property to phy.txt is not good, I can put it to fsl 
> specific
> binding, like the second patch 2/3 did.

You seem to see vendor specific properties as a place to dump all your
waste you don't want to think about. You fail to give good reasons what
is so special about the backplane setup and now you are telling us that
it is even fsl-specific?

[S.H] I don't think it's waste, I just thought it might be special to fsl.
Agreed I failed to give good reasons, but I tried hard to. :(

Thanks,
Shaohui

Sebastian

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

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

[Andrew Lunn]

> 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 should work in backplane, hardware
> can deal with different modes, or even no any special property
> needed if the hardware is strong enough to handle any connections, I
> cannot assume.  But I know what fsl's hardware needs to support
> backplane.

This is the key point really. We don't really care about the Freescale
PCS. We want a generic solution for 1000BASE-KX and 10GBASE-KR,
independent of who makes it, Marvell, Micrel, Broadcom, or Acme.

So, what generic properties are needed for 1000BASE-KX and 10GBASE-KR?
Properties that most/all manufactures are likely to need?

   Andrew
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev