Re: [PATCH 2/3] powerpc: bpf: flush the entire JIT buffer

[Daniel Borkmann]

On 01/13/2017 06:10 PM, Naveen N. Rao wrote:

With bpf_jit_binary_alloc(), we allocate at a page granularity and fill
the rest of the space with illegal instructions to mitigate BPF spraying
attacks, while having the actual JIT'ed BPF program at a random location
within the allocated space. Under this scenario, it would be better to
flush the entire allocated buffer rather than just the part containing
the actual program. We already flush the buffer from start to the end of
the BPF program. Extend this to include the illegal instructions after
the BPF program.

Signed-off-by: Naveen N. Rao 


Acked-by: Daniel Borkmann 

[PATCH] net: constify mdiobb_ops structures

[Bhumika Goyal]

Declare mdiobb_ops structures as const as they are only stored in the
ops field of mdiobb_ctrl structures. This field is of type const, so
mdiobb_ops structures having this property can be declared const too.
Done using Coccinelle:

@r disable optional_qualifier@
identifier x;
position p;
@@
static struct mdiobb_ops x@p={...};

@ok@
struct bb_info bitbang;
struct ravb_private priv;
struct ax_device ax;
struct mdio_gpio_info bb;
identifier r.x;
position p;
@@
(
bitbang.ctrl.ops=@p
|
priv.mdiobb.ops=@p
|
ax.bb_ctrl.ops=@p
|
bb.ctrl.ops=@p
)

@bad@
position p != {r.p,ok.p};
identifier r.x;
@@
x@p

@depends on !bad disable optional_qualifier@
identifier r.x;
@@
+const
struct mdiobb_ops x;

Before and after size details:

File size before:
   textdata bss dec hex filename
  132931203  16   1451238b0 net/ethernet/8390/ax88796.o
File size after:
   textdata bss dec hex filename
  133571139  16   1451238b0 net/ethernet/8390/ax88796.o

File size before: 
   textdata bss dec hex filename
   1440 100   01540 604 freescale/fs_enet/mii-bitbang.o
File size after: Remains the same

File size before:
   textdata bss dec hex filename
  19000 192  16   192084b08 net/ethernet/renesas/ravb_main.o
File size after: Remains the same

File size before:
   textdata bss dec hex filename
  285011568   8   30077757d net/ethernet/renesas/sh_eth.o
File size after:
   textdata bss dec hex filename
  285651504   8   30077757d net/ethernet/renesas/sh_eth.o

File size before:
   textdata bss dec hex filename
   1859 248   02107 83b drivers/net/phy/mdio-gpio.o
File size after:
   textdata bss dec hex filename
   1915 192   02107 83b drivers/net/phy/mdio-gpio.o

Signed-off-by: Bhumika Goyal 
---
 drivers/net/ethernet/8390/ax88796.c  | 2 +-
 drivers/net/ethernet/freescale/fs_enet/mii-bitbang.c | 2 +-
 drivers/net/ethernet/renesas/ravb_main.c | 2 +-
 drivers/net/ethernet/renesas/sh_eth.c| 2 +-
 drivers/net/phy/mdio-gpio.c  | 2 +-
 5 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/net/ethernet/8390/ax88796.c 
b/drivers/net/ethernet/8390/ax88796.c
index b0a3b85..e977671 100644
--- a/drivers/net/ethernet/8390/ax88796.c
+++ b/drivers/net/ethernet/8390/ax88796.c
@@ -585,7 +585,7 @@ static int ax_bb_get_data(struct mdiobb_ctrl *ctrl)
return reg_memr & AX_MEMR_MDI ? 1 : 0;
 }
 
-static struct mdiobb_ops bb_ops = {
+static const struct mdiobb_ops bb_ops = {
.owner = THIS_MODULE,
.set_mdc = ax_bb_mdc,
.set_mdio_dir = ax_bb_dir,
diff --git a/drivers/net/ethernet/freescale/fs_enet/mii-bitbang.c 
b/drivers/net/ethernet/freescale/fs_enet/mii-bitbang.c
index 1f015ed..c8e5d88 100644
--- a/drivers/net/ethernet/freescale/fs_enet/mii-bitbang.c
+++ b/drivers/net/ethernet/freescale/fs_enet/mii-bitbang.c
@@ -100,7 +100,7 @@ static inline void mdc(struct mdiobb_ctrl *ctrl, int what)
in_be32(bitbang->dat);
 }
 
-static struct mdiobb_ops bb_ops = {
+static const struct mdiobb_ops bb_ops = {
.owner = THIS_MODULE,
.set_mdc = mdc,
.set_mdio_dir = mdio_dir,
diff --git a/drivers/net/ethernet/renesas/ravb_main.c 
b/drivers/net/ethernet/renesas/ravb_main.c
index 92d7692..1b0acd1 100644
--- a/drivers/net/ethernet/renesas/ravb_main.c
+++ b/drivers/net/ethernet/renesas/ravb_main.c
@@ -171,7 +171,7 @@ static int ravb_get_mdio_data(struct mdiobb_ctrl *ctrl)
 }
 
 /* MDIO bus control struct */
-static struct mdiobb_ops bb_ops = {
+static const struct mdiobb_ops bb_ops = {
.owner = THIS_MODULE,
.set_mdc = ravb_set_mdc,
.set_mdio_dir = ravb_set_mdio_dir,
diff --git a/drivers/net/ethernet/renesas/sh_eth.c 
b/drivers/net/ethernet/renesas/sh_eth.c
index 00fafab..6ef5dd8 100644
--- a/drivers/net/ethernet/renesas/sh_eth.c
+++ b/drivers/net/ethernet/renesas/sh_eth.c
@@ -1052,7 +1052,7 @@ static void sh_mdc_ctrl(struct mdiobb_ctrl *ctrl, int bit)
 }
 
 /* mdio bus control struct */
-static struct mdiobb_ops bb_ops = {
+static const struct mdiobb_ops bb_ops = {
.owner = THIS_MODULE,
.set_mdc = sh_mdc_ctrl,
.set_mdio_dir = sh_mmd_ctrl,
diff --git a/drivers/net/phy/mdio-gpio.c b/drivers/net/phy/mdio-gpio.c
index 27ab630..97333d5 100644
--- a/drivers/net/phy/mdio-gpio.c
+++ b/drivers/net/phy/mdio-gpio.c
@@ -122,7 +122,7 @@ static void mdc_set(struct mdiobb_ctrl *ctrl, int what)
gpio_set_value_cansleep(bitbang->mdc, what ^ bitbang->mdc_active_low);
 }
 
-static struct mdiobb_ops mdio_gpio_ops = {
+static const struct mdiobb_ops mdio_gpio_ops = {
.owner = THIS_MODULE,
.set_mdc = mdc_set,
.set_mdio_dir = mdio_dir,
-- 
1.9.1

Re: [PATCH 2/3] powerpc: bpf: flush the entire JIT buffer

[Alexei Starovoitov]

On Fri, Jan 13, 2017 at 10:40:01PM +0530, Naveen N. Rao wrote:
> With bpf_jit_binary_alloc(), we allocate at a page granularity and fill
> the rest of the space with illegal instructions to mitigate BPF spraying
> attacks, while having the actual JIT'ed BPF program at a random location
> within the allocated space. Under this scenario, it would be better to
> flush the entire allocated buffer rather than just the part containing
> the actual program. We already flush the buffer from start to the end of
> the BPF program. Extend this to include the illegal instructions after
> the BPF program.
> 
> Signed-off-by: Naveen N. Rao 

Acked-by: Alexei Starovoitov 

Re: [PATCH 1/3] powerpc: bpf: remove redundant check for non-null image

[Alexei Starovoitov]

On Fri, Jan 13, 2017 at 10:40:00PM +0530, Naveen N. Rao wrote:
> From: Daniel Borkmann 
> 
> We have a check earlier to ensure we don't proceed if image is NULL. As
> such, the redundant check can be removed.
> 
> Signed-off-by: Daniel Borkmann 
> [Added similar changes for classic BPF JIT]
> Signed-off-by: Naveen N. Rao 

Acked-by: Alexei Starovoitov 

Re: [PATCH 16/37] PCI: endpoint: Introduce configfs entry for configuring EP functions

[Christoph Hellwig]

Hi Kishon,

a couple comments on the configfs layout based on my experiments with
your previous drop to implement a NVMe device using it.

I don't think most of these configfs files should be present here, as
they are properties of the implemented PCIe devices.  E.g. for my
NVMe device they will be sort of hardcoded most of the time, as they
would be for other devices that would always have a fixed vendor/device/
class ID, cacheline size, etc.

In the end what we'll to be able to do here is to be able to create
a directory for each function driver, which then can create it's own
attributes inside it.

Re: [PATCH 3/3] powerpc: bpf: implement in-register swap for 64-bit endian operations

['Naveen N. Rao']

On 2017/01/13 05:17PM, David Laight wrote:
> From: Naveen N. Rao
> > Sent: 13 January 2017 17:10
> > Generate instructions to perform the endian conversion using registers,
> > rather than generating two memory accesses.
> > 
> > The "way easier and faster" comment was obviously for the author, not
> > the processor.
> 
> That rather depends on whether the processor has a store to load forwarder
> that will satisfy the read from the store buffer.
> I don't know about ppc, but at least some x86 will do that.

Interesting - good to know that.

However, I don't think powerpc does that and in-register swap is likely 
faster regardless. Note also that gcc prefers this form at higher 
optimization levels.

Thanks,
Naveen

Re: [PATCH 12/37] PCI: dwc: Create a new config symbol to enable pci dwc host

[Joao Pinto]

Hi Kishon,

Às 10:26 AM de 1/12/2017, Kishon Vijay Abraham I escreveu:
> Now that pci designware host has a separate file, create a new
> config symbol to select the host only driver. This is in preparation
> to enable endpoint support to designware driver.
> 
> Signed-off-by: Kishon Vijay Abraham I 
> ---
>  drivers/pci/dwc/Kconfig   |   26 +++---
>  drivers/pci/dwc/Makefile  |3 ++-
>  drivers/pci/dwc/pcie-designware.h |   29 +
>  3 files changed, 42 insertions(+), 16 deletions(-)
> 

You are already working in a base where dwc/ already exists. I know you made a
rename / re-structure patch for pci, but I think it was not yet accepted, right?
I don't see it in any of Bjorn' dev branches.

Thanks.

> diff --git a/drivers/pci/dwc/Kconfig b/drivers/pci/dwc/Kconfig
> index 8b08519..d0bdfb5 100644
> --- a/drivers/pci/dwc/Kconfig
> +++ b/drivers/pci/dwc/Kconfig
> @@ -3,13 +3,17 @@ menu "DesignWare PCI Core Support"
>  
>  config PCIE_DW
>   bool
> +
> +config PCIE_DW_HOST
> +bool
>   depends on PCI_MSI_IRQ_DOMAIN
> +select PCIE_DW
>  
>  config PCI_DRA7XX
>   bool "TI DRA7xx PCIe controller"
>   depends on OF && HAS_IOMEM && TI_PIPE3
>   depends on PCI_MSI_IRQ_DOMAIN
> - select PCIE_DW
> + select PCIE_DW_HOST
>   help
>Enables support for the PCIe controller in the DRA7xx SoC.  There
>are two instances of PCIe controller in DRA7xx.  This controller can
> @@ -18,7 +22,7 @@ config PCI_DRA7XX
>  config PCIE_DW_PLAT
>   bool "Platform bus based DesignWare PCIe Controller"
>   depends on PCI_MSI_IRQ_DOMAIN
> - select PCIE_DW
> + select PCIE_DW_HOST
>   ---help---
>This selects the DesignWare PCIe controller support. Select this if
>you have a PCIe controller on Platform bus.
> @@ -32,21 +36,21 @@ config PCI_EXYNOS
>   depends on SOC_EXYNOS5440 || COMPILE_TEST
>   depends on PCI_MSI_IRQ_DOMAIN
>   select PCIEPORTBUS
> - select PCIE_DW
> + select PCIE_DW_HOST
>  
>  config PCI_IMX6
>   bool "Freescale i.MX6 PCIe controller"
>   depends on SOC_IMX6Q || COMPILE_TEST
>   depends on PCI_MSI_IRQ_DOMAIN
>   select PCIEPORTBUS
> - select PCIE_DW
> + select PCIE_DW_HOST
>  
>  config PCIE_SPEAR13XX
>   bool "STMicroelectronics SPEAr PCIe controller"
>   depends on ARCH_SPEAR13XX || COMPILE_TEST
>   depends on PCI_MSI_IRQ_DOMAIN
>   select PCIEPORTBUS
> - select PCIE_DW
> + select PCIE_DW_HOST
>   help
> Say Y here if you want PCIe support on SPEAr13XX SoCs.
>  
> @@ -55,7 +59,7 @@ config PCI_KEYSTONE
>   depends on ARCH_KEYSTONE || COMPILE_TEST
>   depends on PCI_MSI_IRQ_DOMAIN
>   select PCIEPORTBUS
> - select PCIE_DW
> + select PCIE_DW_HOST
>   help
> Say Y here if you want to enable PCI controller support on Keystone
> SoCs. The PCI controller on Keystone is based on Designware hardware
> @@ -67,7 +71,7 @@ config PCI_LAYERSCAPE
>   depends on OF && (ARM || ARCH_LAYERSCAPE || COMPILE_TEST)
>   depends on PCI_MSI_IRQ_DOMAIN
>   select MFD_SYSCON
> - select PCIE_DW
> + select PCIE_DW_HOST
>   help
> Say Y here if you want PCIe controller support on Layerscape SoCs.
>  
> @@ -76,7 +80,7 @@ config PCI_HISI
>   bool "HiSilicon Hip05 and Hip06 SoCs PCIe controllers"
>   depends on PCI_MSI_IRQ_DOMAIN
>   select PCIEPORTBUS
> - select PCIE_DW
> + select PCIE_DW_HOST
>   help
> Say Y here if you want PCIe controller support on HiSilicon
> Hip05 and Hip06 SoCs
> @@ -86,7 +90,7 @@ config PCIE_QCOM
>   depends on (ARCH_QCOM || COMPILE_TEST) && OF
>   depends on PCI_MSI_IRQ_DOMAIN
>   select PCIEPORTBUS
> - select PCIE_DW
> + select PCIE_DW_HOST
>   help
> Say Y here to enable PCIe controller support on Qualcomm SoCs. The
> PCIe controller uses the Designware core plus Qualcomm-specific
> @@ -97,7 +101,7 @@ config PCIE_ARMADA_8K
>   depends on ARCH_MVEBU || COMPILE_TEST
>   depends on PCI_MSI_IRQ_DOMAIN
>   select PCIEPORTBUS
> - select PCIE_DW
> + select PCIE_DW_HOST
>   help
> Say Y here if you want to enable PCIe controller support on
> Armada-8K SoCs. The PCIe controller on Armada-8K is based on
> @@ -109,7 +113,7 @@ config PCIE_ARTPEC6
>   depends on MACH_ARTPEC6 || COMPILE_TEST
>   depends on PCI_MSI_IRQ_DOMAIN
>   select PCIEPORTBUS
> - select PCIE_DW
> + select PCIE_DW_HOST
>   help
> Say Y here to enable PCIe controller support on Axis ARTPEC-6
> SoCs.  This PCIe controller uses the DesignWare core.
> diff --git a/drivers/pci/dwc/Makefile b/drivers/pci/dwc/Makefile
> index 3b57e55..a2df13c 100644
> --- a/drivers/pci/dwc/Makefile
> +++ b/drivers/pci/dwc/Makefile
> @@ -1,4 +1,5 @@
> -obj-$(CONFIG_PCIE_DW) += pcie-designware.o 

Re: [PATCH 07/37] PCI: dwc: designware: Get device pointer at the start of dw_pcie_host_init

[Joao Pinto]

Hi!

Às 10:25 AM de 1/12/2017, Kishon Vijay Abraham I escreveu:
> No functional change. Get device pointer at the beginning of
> dw_pcie_host_init instead of getting it all over dw_pcie_host_init.
> This is in preparation for splitting struct pcie_port into host and
> core structures (Once split pcie_port will not have device pointer).
> 

I think change should be condense with another patch to reduce the patch-set
number and to give it real meaning. I understand why you are breaking so much
the patch, it is has a lot of changes, but in my opinion is too much fragmented.

Thanks
Joao

Re: [PATCH 09/37] PCI: dwc: designware: Parse *num-lanes* property in dw_pcie_setup_rc

[Joao Pinto]

Hi,

Às 10:25 AM de 1/12/2017, Kishon Vijay Abraham I escreveu:
> *num-lanes* dt property is parsed in dw_pcie_host_init. However
> *num-lanes* property is applicable to both root complex mode and
> endpoint mode. As a first step, move the parsing of this property
> outside dw_pcie_host_init. This is in preparation for splitting
> pcie-designware.c to pcie-designware.c and pcie-designware-host.c
> 
> Signed-off-by: Kishon Vijay Abraham I 
> ---
>  drivers/pci/dwc/pcie-designware.c |   18 +++---
>  drivers/pci/dwc/pcie-designware.h |1 -
>  2 files changed, 11 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/pci/dwc/pcie-designware.c 
> b/drivers/pci/dwc/pcie-designware.c
> index 00a0fdc..89cdb6b 100644
> --- a/drivers/pci/dwc/pcie-designware.c
> +++ b/drivers/pci/dwc/pcie-designware.c
> @@ -551,10 +551,6 @@ int dw_pcie_host_init(struct pcie_port *pp)
>   }
>   }
>  
> - ret = of_property_read_u32(np, "num-lanes", >lanes);
> - if (ret)
> - pci->lanes = 0;
> -
>   ret = of_property_read_u32(np, "num-viewport", >num_viewport);
>   if (ret)
>   pci->num_viewport = 2;
> @@ -751,18 +747,26 @@ static int dw_pcie_wr_conf(struct pci_bus *bus, u32 
> devfn,
>  
>  void dw_pcie_setup_rc(struct pcie_port *pp)
>  {
> + int ret;
> + u32 lanes;
>   u32 val;
>   struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
> + struct device *dev = pci->dev;
> + struct device_node *np = dev->of_node;
>  
>   /* get iATU unroll support */
>   pci->iatu_unroll_enabled = dw_pcie_iatu_unroll_enabled(pci);
>   dev_dbg(pci->dev, "iATU unroll: %s\n",
>   pci->iatu_unroll_enabled ? "enabled" : "disabled");
>  
> + ret = of_property_read_u32(np, "num-lanes", );
> + if (ret)
> + lanes = 0;

You moved from host_init to root complex setup function, which in my opinion did
not improve (in this scope).

I suggest that instead of making so much intermediary patches, which is nice to
understand your development sequence, but hard to review. Wouldn't be better to
condense some of the patches? We would have a cloear vision of the final 
product :)

Joao

> +
>   /* set the number of lanes */
>   val = dw_pcie_readl_dbi(pci, PCIE_PORT_LINK_CONTROL);
>   val &= ~PORT_LINK_MODE_MASK;
> - switch (pci->lanes) {
> + switch (lanes) {
>   case 1:
>   val |= PORT_LINK_MODE_1_LANES;
>   break;
> @@ -776,7 +780,7 @@ void dw_pcie_setup_rc(struct pcie_port *pp)
>   val |= PORT_LINK_MODE_8_LANES;
>   break;
>   default:
> - dev_err(pci->dev, "num-lanes %u: invalid value\n", pci->lanes);
> + dev_err(pci->dev, "num-lanes %u: invalid value\n", lanes);
>   return;
>   }
>   dw_pcie_writel_dbi(pci, PCIE_PORT_LINK_CONTROL, val);
> @@ -784,7 +788,7 @@ void dw_pcie_setup_rc(struct pcie_port *pp)
>   /* set link width speed control register */
>   val = dw_pcie_readl_dbi(pci, PCIE_LINK_WIDTH_SPEED_CONTROL);
>   val &= ~PORT_LOGIC_LINK_WIDTH_MASK;
> - switch (pci->lanes) {
> + switch (lanes) {
>   case 1:
>   val |= PORT_LOGIC_LINK_WIDTH_1_LANES;
>   break;
> diff --git a/drivers/pci/dwc/pcie-designware.h 
> b/drivers/pci/dwc/pcie-designware.h
> index d4b3d43..491fbe3 100644
> --- a/drivers/pci/dwc/pcie-designware.h
> +++ b/drivers/pci/dwc/pcie-designware.h
> @@ -148,7 +148,6 @@ struct dw_pcie_ops {
>  struct dw_pcie {
>   struct device   *dev;
>   void __iomem*dbi_base;
> - u32 lanes;
>   u32 num_viewport;
>   u8  iatu_unroll_enabled;
>   struct pcie_portpp;
> 

Re: [PATCH 36/37] ARM: DRA7: clockdomain: Change the CLKTRCTRL of CM_PCIE_CLKSTCTRL to SW_WKUP

[Tony Lindgren]

* Kishon Vijay Abraham I  [170112 02:35]:
> The PCIe programming sequence in TRM suggests CLKSTCTRL of PCIe should
> be set to SW_WKUP. There are no issues when CLKSTCTRL is set to HW_AUTO
> in RC mode. However in EP mode, the host system is not able to access the
> MEMSPACE and setting the CLKSTCTRL to SW_WKUP fixes it.

I guess ideally in the long run we would set this dynamically based on
the selected mode, right?

Regards,

Tony

> Signed-off-by: Kishon Vijay Abraham I 
> ---
>  arch/arm/mach-omap2/clockdomains7xx_data.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/mach-omap2/clockdomains7xx_data.c 
> b/arch/arm/mach-omap2/clockdomains7xx_data.c
> index 6c67965..67ebff8 100644
> --- a/arch/arm/mach-omap2/clockdomains7xx_data.c
> +++ b/arch/arm/mach-omap2/clockdomains7xx_data.c
> @@ -524,7 +524,7 @@
>   .dep_bit  = DRA7XX_PCIE_STATDEP_SHIFT,
>   .wkdep_srcs   = pcie_wkup_sleep_deps,
>   .sleepdep_srcs= pcie_wkup_sleep_deps,
> - .flags= CLKDM_CAN_HWSUP_SWSUP,
> + .flags= CLKDM_CAN_SWSUP,
>  };
>  
>  static struct clockdomain atl_7xx_clkdm = {
> -- 
> 1.7.9.5
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

RE: [PATCH 3/3] powerpc: bpf: implement in-register swap for 64-bit endian operations

[David Laight]

From: Naveen N. Rao
> Sent: 13 January 2017 17:10
> Generate instructions to perform the endian conversion using registers,
> rather than generating two memory accesses.
> 
> The "way easier and faster" comment was obviously for the author, not
> the processor.

That rather depends on whether the processor has a store to load forwarder
that will satisfy the read from the store buffer.
I don't know about ppc, but at least some x86 will do that.

David

Re: [PATCH 05/37] PCI: dwc: Add platform_set_drvdata

[Joao Pinto]

Hi,

Às 10:25 AM de 1/12/2017, Kishon Vijay Abraham I escreveu:
> Add platform_set_drvdata in all designware based drivers to store the
> private data structure of the driver so that dev_set_drvdata can be
> used to get back private data pointer in add_pcie_port/host_init.
> This is in preparation for splitting struct pcie_port into core and
> host only structures. After the split pcie_port will not be part of
> the driver's private data structure and *container_of* used now
> to get the private data pointer cannot be used.
> 
> Cc: Jingoo Han 
> Cc: Richard Zhu 
> Cc: Lucas Stach 
> Cc: Murali Karicheri 
> Cc: Minghuan Lian 
> Cc: Mingkai Hu 
> Cc: Roy Zang 
> Cc: Thomas Petazzoni 
> Cc: Niklas Cassel 
> Cc: Jesper Nilsson 
> Cc: Joao Pinto 
> Cc: Zhou Wang 
> Cc: Gabriele Paoloni 
> Cc: Stanimir Varbanov 
> Cc: Pratyush Anand 
> Signed-off-by: Kishon Vijay Abraham I 
> ---
>  drivers/pci/dwc/pci-dra7xx.c   |3 ++-
>  drivers/pci/dwc/pci-exynos.c   |3 ++-
>  drivers/pci/dwc/pci-imx6.c |3 ++-
>  drivers/pci/dwc/pci-keystone.c |2 ++
>  drivers/pci/dwc/pci-layerscape.c   |2 ++
>  drivers/pci/dwc/pcie-armada8k.c|2 ++
>  drivers/pci/dwc/pcie-artpec6.c |2 ++
>  drivers/pci/dwc/pcie-designware-plat.c |2 ++
>  drivers/pci/dwc/pcie-hisi.c|2 ++
>  drivers/pci/dwc/pcie-qcom.c|2 ++
>  drivers/pci/dwc/pcie-spear13xx.c   |3 ++-
>  11 files changed, 22 insertions(+), 4 deletions(-)
> 

This is an example of a change that could be merged with another patch that
gives it more meaning, like I wrote in the review of patch 9/37.

Thanks,
Joao

[PATCH 3/3] powerpc: bpf: implement in-register swap for 64-bit endian operations

[Naveen N. Rao]

Generate instructions to perform the endian conversion using registers,
rather than generating two memory accesses.

The "way easier and faster" comment was obviously for the author, not
the processor.

Signed-off-by: Naveen N. Rao 
---
 arch/powerpc/net/bpf_jit_comp64.c | 22 ++
 1 file changed, 14 insertions(+), 8 deletions(-)

diff --git a/arch/powerpc/net/bpf_jit_comp64.c 
b/arch/powerpc/net/bpf_jit_comp64.c
index 1e313db..0413a89 100644
--- a/arch/powerpc/net/bpf_jit_comp64.c
+++ b/arch/powerpc/net/bpf_jit_comp64.c
@@ -599,16 +599,22 @@ static int bpf_jit_build_body(struct bpf_prog *fp, u32 
*image,
break;
case 64:
/*
-* Way easier and faster(?) to store the value
-* into stack and then use ldbrx
+* We'll split it up into two words, swap those
+* independently and then merge them back.
 *
-* ctx->seen will be reliable in pass2, but
-* the instructions generated will remain the
-* same across all passes
+* First up, let's swap the most-significant 
word.
 */
-   PPC_STD(dst_reg, 1, bpf_jit_stack_local(ctx));
-   PPC_ADDI(b2p[TMP_REG_1], 1, 
bpf_jit_stack_local(ctx));
-   PPC_LDBRX(dst_reg, 0, b2p[TMP_REG_1]);
+   PPC_RLDICL(b2p[TMP_REG_1], dst_reg, 32, 32);
+   PPC_RLWINM(b2p[TMP_REG_2], b2p[TMP_REG_1], 8, 
0, 31);
+   PPC_RLWIMI(b2p[TMP_REG_2], b2p[TMP_REG_1], 24, 
0, 7);
+   PPC_RLWIMI(b2p[TMP_REG_2], b2p[TMP_REG_1], 24, 
16, 23);
+   /* Then, the second half */
+   PPC_RLWINM(b2p[TMP_REG_1], dst_reg, 8, 0, 31);
+   PPC_RLWIMI(b2p[TMP_REG_1], dst_reg, 24, 0, 7);
+   PPC_RLWIMI(b2p[TMP_REG_1], dst_reg, 24, 16, 23);
+   /* Merge back */
+   PPC_RLDICR(dst_reg, b2p[TMP_REG_1], 32, 31);
+   PPC_OR(dst_reg, dst_reg, b2p[TMP_REG_2]);
break;
}
break;
-- 
2.10.2

[PATCH 2/3] powerpc: bpf: flush the entire JIT buffer

[Naveen N. Rao]

With bpf_jit_binary_alloc(), we allocate at a page granularity and fill
the rest of the space with illegal instructions to mitigate BPF spraying
attacks, while having the actual JIT'ed BPF program at a random location
within the allocated space. Under this scenario, it would be better to
flush the entire allocated buffer rather than just the part containing
the actual program. We already flush the buffer from start to the end of
the BPF program. Extend this to include the illegal instructions after
the BPF program.

Signed-off-by: Naveen N. Rao 
---
 arch/powerpc/net/bpf_jit_comp64.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/net/bpf_jit_comp64.c 
b/arch/powerpc/net/bpf_jit_comp64.c
index 89b6a86..1e313db 100644
--- a/arch/powerpc/net/bpf_jit_comp64.c
+++ b/arch/powerpc/net/bpf_jit_comp64.c
@@ -1046,8 +1046,6 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *fp)
 */
bpf_jit_dump(flen, proglen, pass, code_base);
 
-   bpf_flush_icache(bpf_hdr, image + alloclen);
-
 #ifdef PPC64_ELF_ABI_v1
/* Function descriptor nastiness: Address + TOC */
((u64 *)image)[0] = (u64)code_base;
@@ -1057,6 +1055,8 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *fp)
fp->bpf_func = (void *)image;
fp->jited = 1;
 
+   bpf_flush_icache(bpf_hdr, (u8 *)bpf_hdr + (bpf_hdr->pages * PAGE_SIZE));
+
 out:
kfree(addrs);
 
-- 
2.10.2

[PATCH 1/3] powerpc: bpf: remove redundant check for non-null image

[Naveen N. Rao]

From: Daniel Borkmann 

We have a check earlier to ensure we don't proceed if image is NULL. As
such, the redundant check can be removed.

Signed-off-by: Daniel Borkmann 
[Added similar changes for classic BPF JIT]
Signed-off-by: Naveen N. Rao 
---
 arch/powerpc/net/bpf_jit_comp.c   | 17 +
 arch/powerpc/net/bpf_jit_comp64.c | 16 
 2 files changed, 17 insertions(+), 16 deletions(-)

diff --git a/arch/powerpc/net/bpf_jit_comp.c b/arch/powerpc/net/bpf_jit_comp.c
index 7e706f3..f9941b3 100644
--- a/arch/powerpc/net/bpf_jit_comp.c
+++ b/arch/powerpc/net/bpf_jit_comp.c
@@ -662,16 +662,17 @@ void bpf_jit_compile(struct bpf_prog *fp)
 */
bpf_jit_dump(flen, proglen, pass, code_base);
 
-   if (image) {
-   bpf_flush_icache(code_base, code_base + (proglen/4));
+   bpf_flush_icache(code_base, code_base + (proglen/4));
+
 #ifdef CONFIG_PPC64
-   /* Function descriptor nastiness: Address + TOC */
-   ((u64 *)image)[0] = (u64)code_base;
-   ((u64 *)image)[1] = local_paca->kernel_toc;
+   /* Function descriptor nastiness: Address + TOC */
+   ((u64 *)image)[0] = (u64)code_base;
+   ((u64 *)image)[1] = local_paca->kernel_toc;
 #endif
-   fp->bpf_func = (void *)image;
-   fp->jited = 1;
-   }
+
+   fp->bpf_func = (void *)image;
+   fp->jited = 1;
+
 out:
kfree(addrs);
return;
diff --git a/arch/powerpc/net/bpf_jit_comp64.c 
b/arch/powerpc/net/bpf_jit_comp64.c
index 0fe98a5..89b6a86 100644
--- a/arch/powerpc/net/bpf_jit_comp64.c
+++ b/arch/powerpc/net/bpf_jit_comp64.c
@@ -1046,16 +1046,16 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog 
*fp)
 */
bpf_jit_dump(flen, proglen, pass, code_base);
 
-   if (image) {
-   bpf_flush_icache(bpf_hdr, image + alloclen);
+   bpf_flush_icache(bpf_hdr, image + alloclen);
+
 #ifdef PPC64_ELF_ABI_v1
-   /* Function descriptor nastiness: Address + TOC */
-   ((u64 *)image)[0] = (u64)code_base;
-   ((u64 *)image)[1] = local_paca->kernel_toc;
+   /* Function descriptor nastiness: Address + TOC */
+   ((u64 *)image)[0] = (u64)code_base;
+   ((u64 *)image)[1] = local_paca->kernel_toc;
 #endif
-   fp->bpf_func = (void *)image;
-   fp->jited = 1;
-   }
+
+   fp->bpf_func = (void *)image;
+   fp->jited = 1;
 
 out:
kfree(addrs);
-- 
2.10.2

Re: [PATCH v3 1/8] arm: put types.h in uapi

[Russell King - ARM Linux]

On Fri, Jan 13, 2017 at 11:46:39AM +0100, Nicolas Dichtel wrote:
> This header file is exported, thus move it to uapi.

I'm taking this patch, but with the following commit log:

  Due to the way kbuild works, this header was unintentionally exported
  back in 2013 when it was created, despite it not being in a uapi/
  directory.  This is very non-intuitive behaviour by Kbuild.

  However, we've had this include exported to userland for almost four
  years, and searching google for "ARM types.h __UINTPTR_TYPE__" gives
  no hint that anyone has complained about it.  So, let's make it
  officially exported in this state.

If anyone has any objections, they better shout sooner rather than
later.

> 
> Signed-off-by: Nicolas Dichtel 
> ---
>  arch/arm/include/asm/types.h  | 40 
> ---
>  arch/arm/include/uapi/asm/types.h | 40 
> +++
>  2 files changed, 40 insertions(+), 40 deletions(-)
>  delete mode 100644 arch/arm/include/asm/types.h
>  create mode 100644 arch/arm/include/uapi/asm/types.h
> 
> diff --git a/arch/arm/include/asm/types.h b/arch/arm/include/asm/types.h
> deleted file mode 100644
> index a53cdb8f068c..
> --- a/arch/arm/include/asm/types.h
> +++ /dev/null
> @@ -1,40 +0,0 @@
> -#ifndef _ASM_TYPES_H
> -#define _ASM_TYPES_H
> -
> -#include 
> -
> -/*
> - * The C99 types uintXX_t that are usually defined in 'stdint.h' are not as
> - * unambiguous on ARM as you would expect. For the types below, there is a
> - * difference on ARM between GCC built for bare metal ARM, GCC built for 
> glibc
> - * and the kernel itself, which results in build errors if you try to build 
> with
> - * -ffreestanding and include 'stdint.h' (such as when you include 
> 'arm_neon.h'
> - * in order to use NEON intrinsics)
> - *
> - * As the typedefs for these types in 'stdint.h' are based on builtin defines
> - * supplied by GCC, we can tweak these to align with the kernel's idea of 
> those
> - * types, so 'linux/types.h' and 'stdint.h' can be safely included from the 
> same
> - * source file (provided that -ffreestanding is used).
> - *
> - *int32_t uint32_t   uintptr_t
> - * bare metal GCC longunsigned long  unsigned int
> - * glibc GCC  int unsigned int   unsigned int
> - * kernel int unsigned int   unsigned long
> - */
> -
> -#ifdef __INT32_TYPE__
> -#undef __INT32_TYPE__
> -#define __INT32_TYPE__   int
> -#endif
> -
> -#ifdef __UINT32_TYPE__
> -#undef __UINT32_TYPE__
> -#define __UINT32_TYPE__  unsigned int
> -#endif
> -
> -#ifdef __UINTPTR_TYPE__
> -#undef __UINTPTR_TYPE__
> -#define __UINTPTR_TYPE__ unsigned long
> -#endif
> -
> -#endif /* _ASM_TYPES_H */
> diff --git a/arch/arm/include/uapi/asm/types.h 
> b/arch/arm/include/uapi/asm/types.h
> new file mode 100644
> index ..9435a42f575e
> --- /dev/null
> +++ b/arch/arm/include/uapi/asm/types.h
> @@ -0,0 +1,40 @@
> +#ifndef _UAPI_ASM_TYPES_H
> +#define _UAPI_ASM_TYPES_H
> +
> +#include 
> +
> +/*
> + * The C99 types uintXX_t that are usually defined in 'stdint.h' are not as
> + * unambiguous on ARM as you would expect. For the types below, there is a
> + * difference on ARM between GCC built for bare metal ARM, GCC built for 
> glibc
> + * and the kernel itself, which results in build errors if you try to build 
> with
> + * -ffreestanding and include 'stdint.h' (such as when you include 
> 'arm_neon.h'
> + * in order to use NEON intrinsics)
> + *
> + * As the typedefs for these types in 'stdint.h' are based on builtin defines
> + * supplied by GCC, we can tweak these to align with the kernel's idea of 
> those
> + * types, so 'linux/types.h' and 'stdint.h' can be safely included from the 
> same
> + * source file (provided that -ffreestanding is used).
> + *
> + *int32_t uint32_t   uintptr_t
> + * bare metal GCC longunsigned long  unsigned int
> + * glibc GCC  int unsigned int   unsigned int
> + * kernel int unsigned int   unsigned long
> + */
> +
> +#ifdef __INT32_TYPE__
> +#undef __INT32_TYPE__
> +#define __INT32_TYPE__   int
> +#endif
> +
> +#ifdef __UINT32_TYPE__
> +#undef __UINT32_TYPE__
> +#define __UINT32_TYPE__  unsigned int
> +#endif
> +
> +#ifdef __UINTPTR_TYPE__
> +#undef __UINTPTR_TYPE__
> +#define __UINTPTR_TYPE__ unsigned long
> +#endif
> +
> +#endif /* _UAPI_ASM_TYPES_H */
> -- 
> 2.8.1
> 

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH 11/37] PCI: dwc: Split pcie-designware.c into host and core files

[Joao Pinto]

Às 10:26 AM de 1/12/2017, Kishon Vijay Abraham I escreveu:
> Split pcie-designware.c into pcie-designware-host.c that contains
> the host specific parts of the driver and pcie-designware.c that
> contains the parts used by both host driver and endpoint driver.
> 
> Signed-off-by: Kishon Vijay Abraham I 
> ---
>  drivers/pci/dwc/Makefile   |2 +-
>  drivers/pci/dwc/pcie-designware-host.c |  619 
> 
>  drivers/pci/dwc/pcie-designware.c  |  613 +--
>  drivers/pci/dwc/pcie-designware.h  |8 +
>  4 files changed, 634 insertions(+), 608 deletions(-)
>  create mode 100644 drivers/pci/dwc/pcie-designware-host.c
> 
> diff --git a/drivers/pci/dwc/Makefile b/drivers/pci/dwc/Makefile
> index 7d27c14..3b57e55 100644
> --- a/drivers/pci/dwc/Makefile
> +++ b/drivers/pci/dwc/Makefile
> @@ -1,4 +1,4 @@

(snip...)

> -static void dw_pcie_prog_outbound_atu(struct dw_pcie *pci, int index,
> -   int type, u64 cpu_addr, u64 pci_addr,
> -   u32 size)
> +void dw_pcie_prog_outbound_atu(struct dw_pcie *pci, int index, int type,
> +u64 cpu_addr, u64 pci_addr, u32 size)
>  {
>   u32 retries, val;
>  
> @@ -186,220 +151,6 @@ static void dw_pcie_prog_outbound_atu(struct dw_pcie 
> *pci, int index,
>   dev_err(pci->dev, "iATU is not being enabled\n");
>  }

Kishon, iATU only makes sense in The Root Complex (host), so it should be inside
the pcie-designware-host.

>  
> -static struct irq_chip dw_msi_irq_chip = {
> - .name = "PCI-MSI",
> - .irq_enable = pci_msi_unmask_irq,
> - .irq_disable = pci_msi_mask_irq,
> - .irq_mask = pci_msi_mask_irq,
> - .irq_unmask = pci_msi_unmask_irq,
> -};
> -

(snip...)

> -
> -static const struct irq_domain_ops msi_domain_ops = {
> - .map = dw_pcie_msi_map,
> -};
> -
>  static u8 dw_pcie_iatu_unroll_enabled(struct dw_pcie *pci)
>  {
>   u32 val;
> @@ -454,303 +192,11 @@ static u8 dw_pcie_iatu_unroll_enabled(struct dw_pcie 
> *pci)
>   return 0;
>  }

Kishon, iATU only makes sense in The Root Complex (host), so it should be inside
the pcie-designware-host.

(snip...)

> diff --git a/drivers/pci/dwc/pcie-designware.h 
> b/drivers/pci/dwc/pcie-designware.h
> index 491fbe3..808d17b 100644
> --- a/drivers/pci/dwc/pcie-designware.h
> +++ b/drivers/pci/dwc/pcie-designware.h
> @@ -14,6 +14,10 @@
>  #ifndef _PCIE_DESIGNWARE_H
>  #define _PCIE_DESIGNWARE_H
>  
> +#include 
> +#include 
> +#include 
> +
>  /* Parameters for the waiting for link up routine */
>  #define LINK_WAIT_MAX_RETRIES10
>  #define LINK_WAIT_USLEEP_MIN 9
> @@ -167,4 +171,8 @@ struct dw_pcie {
>  void dw_pcie_writel_dbi(struct dw_pcie *pci, u32 reg, u32 val);
>  int dw_pcie_link_up(struct dw_pcie *pci);
>  int dw_pcie_wait_for_link(struct dw_pcie *pci);
> +void dw_pcie_prog_outbound_atu(struct dw_pcie *pci, int index,
> +int type, u64 cpu_addr, u64 pci_addr,
> +u32 size);
> +void dw_pcie_setup(struct dw_pcie *pci);


Kishon, iATU only makes sense in The Root Complex (host), so it should be inside
the pcie-designware-host as static.

>  #endif /* _PCIE_DESIGNWARE_H */
> 

Thanks,
Joao

Re: [PATCH v5 5/5] Documentation:powerpc: Add device-tree bindings for power-mgt

[Rob Herring]

On Tue, Jan 10, 2017 at 02:37:04PM +0530, Gautham R. Shenoy wrote:
> From: "Gautham R. Shenoy" 
> 
> Document the device-tree bindings defining the the properties under
> the @power-mgt node in the device tree that describe the idle states
> for Linux running on baremetal POWER servers.
> 

We have "common" idle state bindings. Perhaps some explanation why those 
can't be used.

> Signed-off-by: Gautham R. Shenoy 
> ---
> [v4]-> [v5]: Fixed a couple of typos.
> 
>  .../devicetree/bindings/powerpc/opal/power-mgt.txt | 125 
> +
>  1 file changed, 125 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/powerpc/opal/power-mgt.txt
> 
> diff --git a/Documentation/devicetree/bindings/powerpc/opal/power-mgt.txt 
> b/Documentation/devicetree/bindings/powerpc/opal/power-mgt.txt
> new file mode 100644
> index 000..4967831
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/powerpc/opal/power-mgt.txt
> @@ -0,0 +1,125 @@
> +IBM Power-Management Bindings
> +=
> +
> +Linux running on baremetal POWER machines has access to the processor
> +idle states. The description of these idle states is exposed via the
> +node @power-mgt in the device-tree by the firmware.
> +
> +Definitions:
> +
> +Typically each idle state has the following associated properties:
> +
> +- name: The name of the idle state as defined by the firmware.
> +
> +- flags: indicating some aspects of this idle states such as the
> + extent of state-loss, whether timebase is stopped on this
> + idle states and so on. The flag bits are as follows:
> +
> +- exit-latency: The latency involved in transitioning the state of the
> + CPU from idle to running.
> +
> +- target-residency: The minimum time that the CPU needs to reside in
> + this idle state in order to accrue power-savings
> + benefit.
> +
> +Properties
> +
> +The following properties provide details about the idle states. These
> +properties are optional unless mentioned otherwise below.

-names is optional but everything else seems to require it. It is not 
clear what the binding looks like if -names is not present.

> +
> +- ibm,cpu-idle-state-names:
> + Array of strings containing the names of the idle states.
> +
> +- ibm,cpu-idle-state-flags:
> + Array of unsigned 32-bit values containing the values of the
> + flags associated with the the aforementioned idle-states. This
> + property is required on POWER9 whenever
> + ibm,cpu-idle-state-names is defined and the length of this
> + property array should be the same as
> + ibm,-cpu-idle-state-names.The flag bits are as follows:

s/ibm,-cpu/ibm,cpu/

Needs a space after the period.

> + 0x0001 /* Decrementer would stop */
> + 0x0002 /* Needs timebase restore */
> + 0x1000 /* Restore GPRs like nap */
> + 0x2000 /* Restore hypervisor resource from PACA pointer */
> + 0x4000 /* Program PORE to restore PACA pointer */
> + 0x0001 /* This is a nap state */
> + 0x0002 /* This is a fast-sleep state */
> + 0x0004 /* This is a winkle state */
> + 0x0008 /* This is a fast-sleep state which requires a */
> +/* software workaround for restoring the timebase*/
> + 0x0080 /* This state uses SPR PMICR instruction */
> + 0x0010 /* This is a fast stop state */
> + 0x0020 /* This is a deep-stop state */
> +
> +- ibm,cpu-idle-state-latencies-ns:
> + Array of unsigned 32-bit values containing the values of the
> + exit-latencies (in ns) for the idle states in
> + ibm,cpu-idle-state-names. This property is required whenever
> + ibm,cpu-idle-state-names is defined and the length of this
> + property array should be the same as
> + ibm,-cpu-idle-state-names.

Same typo.

> +
> +- ibm,cpu-idle-state-residency-ns:
> + Array of unsigned 32-bit values containing the values of the
> + target-residency (in ns) for the idle states in
> + ibm,cpu-idle-state-names. On POWER8 this is an optional
> + property. If the property is absent, the target residency for
> + the "Nap", "FastSleep" are defined to 1 and 3
> + respectively. On POWER9 this property must be defined if
> + ibm,cpu-idle-state-names is defined and the length should be
> + same as that of ibm,cpu-idle-state-names.
> +
> +- ibm,cpu-idle-state-psscr:
> + Array of unsigned 64-bit values containing the values for the
> + PSSCR for each of the idle states in ibm,cpu-idle-state-names.
> + This property is required on POWER9 whenever
> + ibm,cpu-idle-state-names is defined and the length of this
> + property array should be the same as
> + ibm,cpu-idle-state-names.
> +
> +- 

Re: [PATCH 06/37] PCI: dwc: Rename cfg_read/cfg_write to read/write

[Joao Pinto]

Hi,

Às 10:25 AM de 1/12/2017, Kishon Vijay Abraham I escreveu:
> No functional change. dw_pcie_cfg_read/dw_pcie_cfg_write doesn't do
> anything specific to access configuration space. It can be just renamed
> to dw_pcie_read/dw_pcie_write and used to read/write data to dbi space.
> This is in preparation for added endpoint support to linux kernel.
> 
> Cc: Jingoo Han 
> Cc: Murali Karicheri 
> Cc: Joao Pinto 
> Cc: Stanimir Varbanov 
> Cc: Pratyush Anand 
> Signed-off-by: Kishon Vijay Abraham I 
> ---
>  drivers/pci/dwc/pci-dra7xx.c  |   16 
>  drivers/pci/dwc/pci-exynos.c  |4 ++--
>  drivers/pci/dwc/pci-keystone-dw.c |4 ++--
>  drivers/pci/dwc/pcie-designware.c |   12 ++--
>  drivers/pci/dwc/pcie-designware.h |4 ++--
>  drivers/pci/dwc/pcie-qcom.c   |2 +-
>  drivers/pci/dwc/pcie-spear13xx.c  |   24 
>  7 files changed, 33 insertions(+), 33 deletions(-)
> 
> diff --git a/drivers/pci/dwc/pci-dra7xx.c b/drivers/pci/dwc/pci-dra7xx.c
> index aeeab74..38b0c9a 100644
> --- a/drivers/pci/dwc/pci-dra7xx.c
> +++ b/drivers/pci/dwc/pci-dra7xx.c
> @@ -114,22 +114,22 @@ static int dra7xx_pcie_establish_link(struct 
> dra7xx_pcie *dra7xx)
>   }
>  
>   if (dra7xx->link_gen == 1) {
> - dw_pcie_cfg_read(pp->dbi_base + exp_cap_off + PCI_EXP_LNKCAP,
> -  4, );
> + dw_pcie_read(pp->dbi_base + exp_cap_off + PCI_EXP_LNKCAP,
> +  4, );
>   if ((reg & PCI_EXP_LNKCAP_SLS) != PCI_EXP_LNKCAP_SLS_2_5GB) {
>   reg &= ~((u32)PCI_EXP_LNKCAP_SLS);
>   reg |= PCI_EXP_LNKCAP_SLS_2_5GB;
> - dw_pcie_cfg_write(pp->dbi_base + exp_cap_off +
> -   PCI_EXP_LNKCAP, 4, reg);
> + dw_pcie_write(pp->dbi_base + exp_cap_off +
> +   PCI_EXP_LNKCAP, 4, reg);
>   }
>  
> - dw_pcie_cfg_read(pp->dbi_base + exp_cap_off + PCI_EXP_LNKCTL2,
> -  2, );
> + dw_pcie_read(pp->dbi_base + exp_cap_off + PCI_EXP_LNKCTL2,
> +  2, );
>   if ((reg & PCI_EXP_LNKCAP_SLS) != PCI_EXP_LNKCAP_SLS_2_5GB) {
>   reg &= ~((u32)PCI_EXP_LNKCAP_SLS);
>   reg |= PCI_EXP_LNKCAP_SLS_2_5GB;
> - dw_pcie_cfg_write(pp->dbi_base + exp_cap_off +
> -   PCI_EXP_LNKCTL2, 2, reg);
> + dw_pcie_write(pp->dbi_base + exp_cap_off +
> +   PCI_EXP_LNKCTL2, 2, reg);
>   }
>   }
>  
> diff --git a/drivers/pci/dwc/pci-exynos.c b/drivers/pci/dwc/pci-exynos.c
> index c179e7a..e3fbff4 100644
> --- a/drivers/pci/dwc/pci-exynos.c
> +++ b/drivers/pci/dwc/pci-exynos.c
> @@ -429,7 +429,7 @@ static int exynos_pcie_rd_own_conf(struct pcie_port *pp, 
> int where, int size,
>   int ret;
>  
>   exynos_pcie_sideband_dbi_r_mode(exynos_pcie, true);
> - ret = dw_pcie_cfg_read(pp->dbi_base + where, size, val);
> + ret = dw_pcie_read(pp->dbi_base + where, size, val);
>   exynos_pcie_sideband_dbi_r_mode(exynos_pcie, false);
>   return ret;
>  }
> @@ -441,7 +441,7 @@ static int exynos_pcie_wr_own_conf(struct pcie_port *pp, 
> int where, int size,
>   int ret;
>  
>   exynos_pcie_sideband_dbi_w_mode(exynos_pcie, true);
> - ret = dw_pcie_cfg_write(pp->dbi_base + where, size, val);
> + ret = dw_pcie_write(pp->dbi_base + where, size, val);
>   exynos_pcie_sideband_dbi_w_mode(exynos_pcie, false);
>   return ret;
>  }
> diff --git a/drivers/pci/dwc/pci-keystone-dw.c 
> b/drivers/pci/dwc/pci-keystone-dw.c
> index 9397c46..4875334 100644
> --- a/drivers/pci/dwc/pci-keystone-dw.c
> +++ b/drivers/pci/dwc/pci-keystone-dw.c
> @@ -444,7 +444,7 @@ int ks_dw_pcie_rd_other_conf(struct pcie_port *pp, struct 
> pci_bus *bus,
>  
>   addr = ks_pcie_cfg_setup(ks_pcie, bus_num, devfn);
>  
> - return dw_pcie_cfg_read(addr + where, size, val);
> + return dw_pcie_read(addr + where, size, val);
>  }
>  
>  int ks_dw_pcie_wr_other_conf(struct pcie_port *pp, struct pci_bus *bus,
> @@ -456,7 +456,7 @@ int ks_dw_pcie_wr_other_conf(struct pcie_port *pp, struct 
> pci_bus *bus,
>  
>   addr = ks_pcie_cfg_setup(ks_pcie, bus_num, devfn);
>  
> - return dw_pcie_cfg_write(addr + where, size, val);
> + return dw_pcie_write(addr + where, size, val);
>  }
>  
>  /**
> diff --git a/drivers/pci/dwc/pcie-designware.c 
> b/drivers/pci/dwc/pcie-designware.c
> index 0b928dc..d0ea310 100644
> --- a/drivers/pci/dwc/pcie-designware.c
> +++ b/drivers/pci/dwc/pcie-designware.c
> @@ -33,7 +33,7 @@
>  
>  static struct pci_ops dw_pcie_ops;
>  
> -int dw_pcie_cfg_read(void __iomem *addr, int size, u32 

Re: [PATCH 10/37] PCI: dwc: designware: Fix style errors in pcie-designware.c

[Joao Pinto]

Às 10:25 AM de 1/12/2017, Kishon Vijay Abraham I escreveu:
> No functional change. Fix all checkpatch warnings and check errors
> in pcie-designware.c
> 
> Signed-off-by: Kishon Vijay Abraham I 
> ---
>  drivers/pci/dwc/pcie-designware.c |   42 
> ++---
>  1 file changed, 21 insertions(+), 21 deletions(-)
> 
> diff --git a/drivers/pci/dwc/pcie-designware.c 
> b/drivers/pci/dwc/pcie-designware.c
> index 89cdb6b..ff04074 100644
> --- a/drivers/pci/dwc/pcie-designware.c
> +++ b/drivers/pci/dwc/pcie-designware.c
> @@ -40,13 +40,13 @@ int dw_pcie_read(void __iomem *addr, int size, u32 *val)
>   return PCIBIOS_BAD_REGISTER_NUMBER;
>   }
>  
> - if (size == 4)
> + if (size == 4) {
>   *val = readl(addr);
> - else if (size == 2)
> + } else if (size == 2) {
>   *val = readw(addr);
> - else if (size == 1)
> + } else if (size == 1) {
>   *val = readb(addr);
> - else {
> + } else {
>   *val = 0;
>   return PCIBIOS_BAD_REGISTER_NUMBER;
>   }
> @@ -203,16 +203,15 @@ irqreturn_t dw_handle_msi_irq(struct pcie_port *pp)
>  
>   for (i = 0; i < MAX_MSI_CTRLS; i++) {
>   dw_pcie_rd_own_conf(pp, PCIE_MSI_INTR0_STATUS + i * 12, 4,
> - (u32 *));
> + (u32 *));
>   if (val) {
>   ret = IRQ_HANDLED;
>   pos = 0;
>   while ((pos = find_next_bit(, 32, pos)) != 32) {
>   irq = irq_find_mapping(pp->irq_domain,
> - i * 32 + pos);
> - dw_pcie_wr_own_conf(pp,
> - PCIE_MSI_INTR0_STATUS + i * 12,
> - 4, 1 << pos);
> +i * 32 + pos);
> + dw_pcie_wr_own_conf(pp, PCIE_MSI_INTR0_STATUS +
> + i * 12, 4, 1 << pos);
>   generic_handle_irq(irq);
>   pos++;
>   }
> @@ -278,8 +277,9 @@ static void dw_pcie_msi_set_irq(struct pcie_port *pp, int 
> irq)
>  static int assign_irq(int no_irqs, struct msi_desc *desc, int *pos)
>  {
>   int irq, pos0, i;
> - struct pcie_port *pp = (struct pcie_port *) 
> msi_desc_to_pci_sysdata(desc);
> + struct pcie_port *pp;
>  
> + pp  = (struct pcie_port *)msi_desc_to_pci_sysdata(desc);
>   pos0 = bitmap_find_free_region(pp->msi_irq_in_use, MAX_MSI_IRQS,
>  order_base_2(no_irqs));
>   if (pos0 < 0)
> @@ -341,7 +341,7 @@ static void dw_msi_setup_msg(struct pcie_port *pp, 
> unsigned int irq, u32 pos)
>  }
>  
>  static int dw_msi_setup_irq(struct msi_controller *chip, struct pci_dev 
> *pdev,
> - struct msi_desc *desc)
> + struct msi_desc *desc)
>  {
>   int irq, pos;
>   struct pcie_port *pp = pdev->bus->sysdata;
> @@ -389,7 +389,7 @@ static void dw_msi_teardown_irq(struct msi_controller 
> *chip, unsigned int irq)
>  {
>   struct irq_data *data = irq_get_irq_data(irq);
>   struct msi_desc *msi = irq_data_get_msi_desc(data);
> - struct pcie_port *pp = (struct pcie_port *) 
> msi_desc_to_pci_sysdata(msi);
> + struct pcie_port *pp = (struct pcie_port *)msi_desc_to_pci_sysdata(msi);
>  
>   clear_irq_range(pp, irq, 1, data->hwirq);
>  }
> @@ -431,7 +431,7 @@ int dw_pcie_link_up(struct dw_pcie *pci)
>  }
>  
>  static int dw_pcie_msi_map(struct irq_domain *domain, unsigned int irq,
> - irq_hw_number_t hwirq)
> +irq_hw_number_t hwirq)
>  {
>   irq_set_chip_and_handler(irq, _msi_irq_chip, handle_simple_irq);
>   irq_set_chip_data(irq, domain->host_data);
> @@ -468,8 +468,8 @@ int dw_pcie_host_init(struct pcie_port *pp)
>  
>   cfg_res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "config");
>   if (cfg_res) {
> - pp->cfg0_size = resource_size(cfg_res)/2;
> - pp->cfg1_size = resource_size(cfg_res)/2;
> + pp->cfg0_size = resource_size(cfg_res) / 2;
> + pp->cfg1_size = resource_size(cfg_res) / 2;
>   pp->cfg0_base = cfg_res->start;
>   pp->cfg1_base = cfg_res->start + pp->cfg0_size;
>   } else if (!pp->va_cfg0_base) {
> @@ -508,8 +508,8 @@ int dw_pcie_host_init(struct pcie_port *pp)
>   break;
>   case 0:
>   pp->cfg = win->res;
> - pp->cfg0_size = resource_size(pp->cfg)/2;
> - pp->cfg1_size = resource_size(pp->cfg)/2;
> + pp->cfg0_size = resource_size(pp->cfg) / 2;
> + pp->cfg1_size = resource_size(pp->cfg) / 2;
>   

Re: [PATCH 02/37] PCI: dwc: designware: Add new *ops* for cpu addr fixup

[Joao Pinto]

Hi Kishon,

Às 10:25 AM de 1/12/2017, Kishon Vijay Abraham I escreveu:
> Some platforms (like dra7xx) require only the least 28 bits of the
> corresponding 32 bit CPU address to be programmed in the address
> translation unit. This modified address is stored in io_base/mem_base/
> cfg0_base/cfg1_base in dra7xx_pcie_host_init. While this is okay for
> host mode where the address range is fixed, device mode requires
> different addresses to be programmed based on the host buffer address.
> Add a new ops to get the least 28 bits of the corresponding 32 bit
> CPU address and invoke it before programming the address translation
> unit.
> 
> Signed-off-by: Kishon Vijay Abraham I 
> ---
>  drivers/pci/dwc/pcie-designware.c |3 +++
>  drivers/pci/dwc/pcie-designware.h |1 +
>  2 files changed, 4 insertions(+)
> 
> diff --git a/drivers/pci/dwc/pcie-designware.c 
> b/drivers/pci/dwc/pcie-designware.c
> index bed1999..d68bc7b 100644
> --- a/drivers/pci/dwc/pcie-designware.c
> +++ b/drivers/pci/dwc/pcie-designware.c
> @@ -195,6 +195,9 @@ static void dw_pcie_prog_outbound_atu(struct pcie_port 
> *pp, int index,
>  {
>   u32 retries, val;
>  
> + if (pp->ops->cpu_addr_fixup)
> + cpu_addr = pp->ops->cpu_addr_fixup(cpu_addr);
> +
>   if (pp->iatu_unroll_enabled) {
>   dw_pcie_writel_unroll(pp, index, PCIE_ATU_UNR_LOWER_BASE,
>   lower_32_bits(cpu_addr));
> diff --git a/drivers/pci/dwc/pcie-designware.h 
> b/drivers/pci/dwc/pcie-designware.h
> index a567ea2..32f4602 100644
> --- a/drivers/pci/dwc/pcie-designware.h
> +++ b/drivers/pci/dwc/pcie-designware.h
> @@ -54,6 +54,7 @@ struct pcie_port {
>  };
>  
>  struct pcie_host_ops {
> + u64 (*cpu_addr_fixup)(u64 cpu_addr);
>   u32 (*readl_rc)(struct pcie_port *pp, u32 reg);
>   void (*writel_rc)(struct pcie_port *pp, u32 reg, u32 val);
>   int (*rd_own_conf)(struct pcie_port *pp, int where, int size, u32 *val);
> 

I think this is an acceptable fixup, I am ok with it.

Reviewed-By: Joao Pinto 

Joao

Re: [PATCH 04/37] PCI: dwc: designware: Move the register defines to designware header file

[Joao Pinto]

Às 10:25 AM de 1/12/2017, Kishon Vijay Abraham I escreveu:
> No functional change. Move the register defines and other macros from
> pcie-designware.c to pcie-designware.h. This is in preparation to
> split the pcie-designware.c file into designware core file and host
> specific file.
> 
> While at that also fix a checkpatch warning.
> 
> Signed-off-by: Kishon Vijay Abraham I 
> ---
>  drivers/pci/dwc/pcie-designware.c |   70 
>  drivers/pci/dwc/pcie-designware.h |   71 
> +
>  2 files changed, 71 insertions(+), 70 deletions(-)
> 
> diff --git a/drivers/pci/dwc/pcie-designware.c 
> b/drivers/pci/dwc/pcie-designware.c
> index d68bc7b..0b928dc 100644
> --- a/drivers/pci/dwc/pcie-designware.c
> +++ b/drivers/pci/dwc/pcie-designware.c
> @@ -25,76 +25,6 @@
>  
>  #include "pcie-designware.h"

Make sense.

Reviewed-By: Joao Pinto 

Re: [PATCH v3 4/8] x86: stop exporting msr-index.h to userland

[Borislav Petkov]

On Fri, Jan 13, 2017 at 05:08:34PM +0100, Nicolas Dichtel wrote:
> Le 13/01/2017 à 16:43, David Howells a écrit :
> >> -header-y += msr-index.h
> > 
> > I see it on my desktop as /usr/include/asm/msr-index.h and it's been there 
> > at
> > least four years - and as such it's part of the UAPI.  I don't think you can
> > remove it unless you can guarantee there are no userspace users.
> I keep it in the v2 of the series, but the maintainer, Borislav Petkov, asks 
> me
> to un-export it.
> 
> I will follow the maintainer decision.

I'm not the maintainer. I simply think that exporting that file was
wrong because it if we change something in it, we will break userspace.
And that should not happen - if userspace needs MSRs, it should do its
own defines.

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

Re: [PATCH v3 1/8] arm: put types.h in uapi

[Russell King - ARM Linux]

On Fri, Jan 13, 2017 at 05:01:01PM +0100, Nicolas Dichtel wrote:
> Please, do not remove the email subject when you reply. I restore it to
> ease the thread follow-up.

I mentioned it to David, and he says it's because the long list of
recipients is breaking his mailer.  I've already posed the question
about whether that's exploitable!

> Le 13/01/2017 à 16:36, David Howells a écrit :
> > Nicolas Dichtel  wrote:
> > 
> >> This header file is exported, thus move it to uapi.
> > 
> > Exported how?
> 
> It is listed in include/uapi/asm-generic/Kbuild.asm, which is included by
> arch/arm/include/uapi/asm/Kbuild.

We really should not be installing non-uapi header files to userland
under _any_ circumstance - this to me sounds like a bug in kbuild.

The assumption is that headers outside of uapi directories are not
part of the user visible API, and so can be freely modified - which
in the presence of this bug is untrue.

However, as it's happening, and this header has been there since 2013
(commit 09096f6a0ee2 - "ARM: 7822/1: add workaround for ambiguous C99
stdint.h types") it's now well and truely part of the user API whether
we intended it to be or not, so your patch looks to me like the correct
thing to do.

I think it needs further evaluation to make sure kbuild isn't going to
do something else silly, like subsitute include/asm-generic/types.h for
the now missing arch/arm/include/asm/types.h

I wonder how many more headers are unintentionally exported.

... what a mess. :(

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH v3 4/8] x86: stop exporting msr-index.h to userland

[Nicolas Dichtel]

Le 13/01/2017 à 16:43, David Howells a écrit :
>> -header-y += msr-index.h
> 
> I see it on my desktop as /usr/include/asm/msr-index.h and it's been there at
> least four years - and as such it's part of the UAPI.  I don't think you can
> remove it unless you can guarantee there are no userspace users.
I keep it in the v2 of the series, but the maintainer, Borislav Petkov, asks me
to un-export it.

I will follow the maintainer decision.


Regards,
Nicolas

Re: [PATCH v3 1/8] arm: put types.h in uapi

[Nicolas Dichtel]

Please, do not remove the email subject when you reply. I restore it to ease the
thread follow-up.

Le 13/01/2017 à 16:36, David Howells a écrit :
> Nicolas Dichtel  wrote:
> 
>> This header file is exported, thus move it to uapi.
> 
> Exported how?
It is listed in include/uapi/asm-generic/Kbuild.asm, which is included by
arch/arm/include/uapi/asm/Kbuild.

You can also have a look at patch #5 to see why it was exported even if it was
not in an uapi directory.

Regards,
Nicolas

[no subject]

[David Howells]

> -header-y += msr-index.h

I see it on my desktop as /usr/include/asm/msr-index.h and it's been there at
least four years - and as such it's part of the UAPI.  I don't think you can
remove it unless you can guarantee there are no userspace users.

David

[no subject]

[David Howells]

Nicolas Dichtel  wrote:

> This header file is exported, thus move it to uapi.

Exported how?

> +#ifdef __INT32_TYPE__
> +#undef __INT32_TYPE__
> +#define __INT32_TYPE__   int
> +#endif
> +
> +#ifdef __UINT32_TYPE__
> +#undef __UINT32_TYPE__
> +#define __UINT32_TYPE__  unsigned int
> +#endif
> +
> +#ifdef __UINTPTR_TYPE__
> +#undef __UINTPTR_TYPE__
> +#define __UINTPTR_TYPE__ unsigned long
> +#endif

These weren't defined by the kernel before, so why do we need to define them
now?

Will defining __UINTPTR_TYPE__ cause problems in compiling libboost by
changing the signature on C++ functions that use uintptr_t?

David

RE: bootx_init.c:88: undefined reference to `__stack_chk_fail_local'

[David Laight]

From: Christophe LEROY
> Sent: 13 January 2017 12:15
...
> > Which leads to TARGET_LIBC_PROVIDES_SSP being undefined (it would normally
> > be true for glibc >= 2.4), and that is all.  Mystery solved.  Thanks!
> >
> 
> Is there a way to know during compilation how the compiler will behave,
> in order to select the correct method ?
> 
> I have drafted a new approach in the kernel that uses -0x7008(r2)
> instead of the global __stack_chk_guard, but how can I select the proper
> approach during kernel compilation in line with the selected GCC ?

Worse, how can you ensure that loadable modules are compiled with the
same option as the rest of the kernel.

David

Re: bootx_init.c:88: undefined reference to `__stack_chk_fail_local'

[Christophe LEROY]

Le 12/01/2017 à 19:07, Segher Boessenkool a écrit :

On Thu, Jan 12, 2017 at 09:20:47AM -0600, Benjamin Herrenschmidt wrote:

On Thu, 2017-01-12 at 15:42 +0100, Christophe LEROY wrote:

The 4.6.3 uses __stack_chk_guard, while the 4.4.4 and 4.8.3 use
-28680(r2)

Is it dependent on the way GCC is built ? Then do we have a way to
know,
when we compile, which method GCC will use ?

See details below for each of the 3 GCC versions.


I think it depends if you built it along with glibc (so it can produce
userspace binaries) or not.


Right.  Tony's compilers are built using a (modified version of) buildall,
and buildall goes out of its way to build without libc whatsoever, even
if the configuration (powerpc64-linux, for example) expects one.

Which leads to TARGET_LIBC_PROVIDES_SSP being undefined (it would normally
be true for glibc >= 2.4), and that is all.  Mystery solved.  Thanks!



Is there a way to know during compilation how the compiler will behave, 
in order to select the correct method ?


I have drafted a new approach in the kernel that uses -0x7008(r2) 
instead of the global __stack_chk_guard, but how can I select the proper 
approach during kernel compilation in line with the selected GCC ?


Christophe

[PATCH 4.9 40/59] powerpc: Fix build warning on 32-bit PPC

[Greg Kroah-Hartman]

4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Larry Finger 

commit 8ae679c4bc2ea2d16d92620da8e3e9332fa4039f upstream.

I am getting the following warning when I build kernel 4.9-git on my
PowerBook G4 with a 32-bit PPC processor:

AS  arch/powerpc/kernel/misc_32.o
  arch/powerpc/kernel/misc_32.S:299:7: warning: "CONFIG_FSL_BOOKE" is not 
defined [-Wundef]

This problem is evident after commit 989cea5c14be ("kbuild: prevent
lib-ksyms.o rebuilds"); however, this change in kbuild only exposes an
error that has been in the code since 2005 when this source file was
created.  That was with commit 9994a33865f4 ("powerpc: Introduce
entry_{32,64}.S, misc_{32,64}.S, systbl.S").

The offending line does not make a lot of sense.  This error does not
seem to cause any errors in the executable, thus I am not recommending
that it be applied to any stable versions.

Thanks to Nicholas Piggin for suggesting this solution.

Fixes: 9994a33865f4 ("powerpc: Introduce entry_{32,64}.S, misc_{32,64}.S, 
systbl.S")
Signed-off-by: Larry Finger 
Cc: Nicholas Piggin 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Michael Ellerman 
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/powerpc/kernel/misc_32.S |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/powerpc/kernel/misc_32.S
+++ b/arch/powerpc/kernel/misc_32.S
@@ -296,7 +296,7 @@ _GLOBAL(flush_instruction_cache)
lis r3, KERNELBASE@h
iccci   0,r3
 #endif
-#elif CONFIG_FSL_BOOKE
+#elif defined(CONFIG_FSL_BOOKE)
 BEGIN_FTR_SECTION
mfspr   r3,SPRN_L1CSR0
ori r3,r3,L1CSR0_CFI|L1CSR0_CLFC

Re: [PATCH v4 4/5] powerpc/fadump: reuse crashkernel parameter for fadump memory reservation

[Mahesh Jagannath Salgaonkar]

On 01/05/2017 11:02 PM, Hari Bathini wrote:
> fadump supports specifying memory to reserve for fadump's crash kernel
> with fadump_reserve_mem kernel parameter. This parameter currently
> supports passing a fixed memory size, like fadump_reserve_mem=
> only. This patch aims to add support for other syntaxes like range-based
> memory size :[,:,:,...]
> which allows using the same parameter to boot the kernel with different
> system RAM sizes.
> 
> As crashkernel parameter already supports the above mentioned syntaxes,
> this patch deprecates fadump_reserve_mem parameter and reuses crashkernel
> parameter instead, to specify memory for fadump's crash kernel memory
> reservation as well. If any offset is provided in crashkernel parameter,
> it will be ignored in case of fadump, as fadump reserves memory at end
> of RAM.
> 
> Advantages using crashkernel parameter instead of fadump_reserve_mem
> parameter are one less kernel parameter overall, code reuse and support
> for multiple syntaxes to specify memory.
> 
> Suggested-by: Dave Young 
> Signed-off-by: Hari Bathini 

Reviewed-by: Mahesh Salgaonkar 

> ---
>  arch/powerpc/kernel/fadump.c |   23 ++-
>  1 file changed, 10 insertions(+), 13 deletions(-)
> 
> diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c
> index db0b339..de7d39a 100644
> --- a/arch/powerpc/kernel/fadump.c
> +++ b/arch/powerpc/kernel/fadump.c
> @@ -210,14 +210,20 @@ static unsigned long init_fadump_mem_struct(struct 
> fadump_mem_struct *fdm,
>   */
>  static inline unsigned long fadump_calculate_reserve_size(void)
>  {
> - unsigned long size;
> + int ret;
> + unsigned long long base, size;
> 
>   /*
> -  * Check if the size is specified through fadump_reserve_mem= cmdline
> -  * option. If yes, then use that.
> +  * Check if the size is specified through crashkernel= cmdline
> +  * option. If yes, then use that but ignore base as fadump
> +  * reserves memory at end of RAM.
>*/
> - if (fw_dump.reserve_bootvar)
> + ret = parse_crashkernel(boot_command_line, memblock_phys_mem_size(),
> + , );
> + if (ret == 0 && size > 0) {
> + fw_dump.reserve_bootvar = (unsigned long)size;
>   return fw_dump.reserve_bootvar;
> + }
> 
>   /* divide by 20 to get 5% of value */
>   size = memblock_end_of_DRAM() / 20;
> @@ -353,15 +359,6 @@ static int __init early_fadump_param(char *p)
>  }
>  early_param("fadump", early_fadump_param);
> 
> -/* Look for fadump_reserve_mem= cmdline option */
> -static int __init early_fadump_reserve_mem(char *p)
> -{
> - if (p)
> - fw_dump.reserve_bootvar = memparse(p, );
> - return 0;
> -}
> -early_param("fadump_reserve_mem", early_fadump_reserve_mem);
> -
>  static void register_fw_dump(struct fadump_mem_struct *fdm)
>  {
>   int rc;
> 

[PATCH 4.4 22/27] powerpc: Fix build warning on 32-bit PPC

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Larry Finger 

commit 8ae679c4bc2ea2d16d92620da8e3e9332fa4039f upstream.

I am getting the following warning when I build kernel 4.9-git on my
PowerBook G4 with a 32-bit PPC processor:

AS  arch/powerpc/kernel/misc_32.o
  arch/powerpc/kernel/misc_32.S:299:7: warning: "CONFIG_FSL_BOOKE" is not 
defined [-Wundef]

This problem is evident after commit 989cea5c14be ("kbuild: prevent
lib-ksyms.o rebuilds"); however, this change in kbuild only exposes an
error that has been in the code since 2005 when this source file was
created.  That was with commit 9994a33865f4 ("powerpc: Introduce
entry_{32,64}.S, misc_{32,64}.S, systbl.S").

The offending line does not make a lot of sense.  This error does not
seem to cause any errors in the executable, thus I am not recommending
that it be applied to any stable versions.

Thanks to Nicholas Piggin for suggesting this solution.

Fixes: 9994a33865f4 ("powerpc: Introduce entry_{32,64}.S, misc_{32,64}.S, 
systbl.S")
Signed-off-by: Larry Finger 
Cc: Nicholas Piggin 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Michael Ellerman 
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/powerpc/kernel/misc_32.S |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/powerpc/kernel/misc_32.S
+++ b/arch/powerpc/kernel/misc_32.S
@@ -313,7 +313,7 @@ _GLOBAL(flush_instruction_cache)
lis r3, KERNELBASE@h
iccci   0,r3
 #endif
-#elif CONFIG_FSL_BOOKE
+#elif defined(CONFIG_FSL_BOOKE)
 BEGIN_FTR_SECTION
mfspr   r3,SPRN_L1CSR0
ori r3,r3,L1CSR0_CFI|L1CSR0_CLFC

Re: [PATCH v4 3/5] powerpc/fadump: remove dependency with CONFIG_KEXEC

[Mahesh Jagannath Salgaonkar]

On 01/05/2017 11:02 PM, Hari Bathini wrote:
> Now that crashkernel parameter parsing and vmcoreinfo related code is
> moved under CONFIG_CRASH_CORE instead of CONFIG_KEXEC_CORE, remove
> dependency with CONFIG_KEXEC for CONFIG_FA_DUMP. While here, get rid
> of definitions of fadump_append_elf_note() & fadump_final_note()
> functions to reuse similar functions compiled under CONFIG_CRASH_CORE.
> 
> Signed-off-by: Hari Bathini 

Reviewed-by: Mahesh Salgaonkar 

> ---
>  arch/powerpc/Kconfig   |   10 ++
>  arch/powerpc/include/asm/fadump.h  |2 ++
>  arch/powerpc/kernel/crash.c|2 --
>  arch/powerpc/kernel/fadump.c   |   34 +++---
>  arch/powerpc/kernel/setup-common.c |5 +
>  5 files changed, 16 insertions(+), 37 deletions(-)
> 
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index a8ee573..b9726be 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -513,21 +513,23 @@ config RELOCATABLE_TEST
> relocation code.
> 
>  config CRASH_DUMP
> - bool "Build a kdump crash kernel"
> + bool "Build a dump capture kernel"
>   depends on PPC64 || 6xx || FSL_BOOKE || (44x && !SMP)
>   select RELOCATABLE if (PPC64 && !COMPILE_TEST) || 44x || FSL_BOOKE
>   help
> -   Build a kernel suitable for use as a kdump capture kernel.
> +   Build a kernel suitable for use as a dump capture kernel.
> The same kernel binary can be used as production kernel and dump
> capture kernel.
> 
>  config FA_DUMP
>   bool "Firmware-assisted dump"
> - depends on PPC64 && PPC_RTAS && CRASH_DUMP && KEXEC_CORE
> + depends on PPC64 && PPC_RTAS
> + select CRASH_CORE
> + select CRASH_DUMP
>   help
> A robust mechanism to get reliable kernel crash dump with
> assistance from firmware. This approach does not use kexec,
> -   instead firmware assists in booting the kdump kernel
> +   instead firmware assists in booting the capture kernel
> while preserving memory contents. Firmware-assisted dump
> is meant to be a kdump replacement offering robustness and
> speed not possible without system firmware assistance.
> diff --git a/arch/powerpc/include/asm/fadump.h 
> b/arch/powerpc/include/asm/fadump.h
> index 0031806..60b9108 100644
> --- a/arch/powerpc/include/asm/fadump.h
> +++ b/arch/powerpc/include/asm/fadump.h
> @@ -73,6 +73,8 @@
>   reg_entry++;\
>  })
> 
> +extern int crashing_cpu;
> +
>  /* Kernel Dump section info */
>  struct fadump_section {
>   __be32  request_flag;
> diff --git a/arch/powerpc/kernel/crash.c b/arch/powerpc/kernel/crash.c
> index 47b63de..cbabb5a 100644
> --- a/arch/powerpc/kernel/crash.c
> +++ b/arch/powerpc/kernel/crash.c
> @@ -43,8 +43,6 @@
>  #define IPI_TIMEOUT  1
>  #define REAL_MODE_TIMEOUT1
> 
> -/* This keeps a track of which one is the crashing cpu. */
> -int crashing_cpu = -1;
>  static int time_to_dump;
> 
>  #define CRASH_HANDLER_MAX 3
> diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c
> index 8f0c7c5..db0b339 100644
> --- a/arch/powerpc/kernel/fadump.c
> +++ b/arch/powerpc/kernel/fadump.c
> @@ -486,34 +486,6 @@ fadump_read_registers(struct fadump_reg_entry 
> *reg_entry, struct pt_regs *regs)
>   return reg_entry;
>  }
> 
> -static u32 *fadump_append_elf_note(u32 *buf, char *name, unsigned type,
> - void *data, size_t data_len)
> -{
> - struct elf_note note;
> -
> - note.n_namesz = strlen(name) + 1;
> - note.n_descsz = data_len;
> - note.n_type   = type;
> - memcpy(buf, , sizeof(note));
> - buf += (sizeof(note) + 3)/4;
> - memcpy(buf, name, note.n_namesz);
> - buf += (note.n_namesz + 3)/4;
> - memcpy(buf, data, note.n_descsz);
> - buf += (note.n_descsz + 3)/4;
> -
> - return buf;
> -}
> -
> -static void fadump_final_note(u32 *buf)
> -{
> - struct elf_note note;
> -
> - note.n_namesz = 0;
> - note.n_descsz = 0;
> - note.n_type   = 0;
> - memcpy(buf, , sizeof(note));
> -}
> -
>  static u32 *fadump_regs_to_elf_notes(u32 *buf, struct pt_regs *regs)
>  {
>   struct elf_prstatus prstatus;
> @@ -524,8 +496,8 @@ static u32 *fadump_regs_to_elf_notes(u32 *buf, struct 
> pt_regs *regs)
>* prstatus.pr_pid = 
>*/
>   elf_core_copy_kernel_regs(_reg, regs);
> - buf = fadump_append_elf_note(buf, KEXEC_CORE_NOTE_NAME, NT_PRSTATUS,
> - , sizeof(prstatus));
> + buf = append_elf_note(buf, CRASH_CORE_NOTE_NAME, NT_PRSTATUS,
> +   , sizeof(prstatus));
>   return buf;
>  }
> 
> @@ -666,7 +638,7 @@ static int __init fadump_build_cpu_notes(const struct 
> fadump_mem_struct *fdm)
>   note_buf = fadump_regs_to_elf_notes(note_buf, );
>   

[PATCH v5 2/2] KVM: PPC: Exit guest upon MCE when FWNMI capability is enabled

[Aravinda Prasad]

Enhance KVM to cause a guest exit with KVM_EXIT_NMI
exit reason upon a machine check exception (MCE) in
the guest address space if the KVM_CAP_PPC_FWNMI
capability is enabled (instead of delivering a 0x200
interrupt to guest). This enables QEMU to build error
log and deliver machine check exception to guest via
guest registered machine check handler.

This approach simplifies the delivery of machine
check exception to guest OS compared to the earlier
approach of KVM directly invoking 0x200 guest interrupt
vector.

This design/approach is based on the feedback for the
QEMU patches to handle machine check exception. Details
of earlier approach of handling machine check exception
in QEMU and related discussions can be found at:

https://lists.nongnu.org/archive/html/qemu-devel/2014-11/msg00813.html

Note:

This patch introduces a hook which is invoked at the time
of guest exit to facilitate the host-side handling of
machine check exception before the exception is passed
on to the guest. Hence, the host-side handling which was
performed earlier via machine_check_fwnmi is removed.

The reasons for this approach is (i) it is not possible
to distinguish whether the exception occurred in the
guest or the host from the pt_regs passed on the
machine_check_exception(). Hence machine_check_exception()
calls panic, instead of passing on the exception to
the guest, if the machine check exception is not
recoverable. (ii) the approach introduced in this
patch gives opportunity to the host kernel to perform
actions in virtual mode before passing on the exception
to the guest. This approach does not require complex
tweaks to machine_check_fwnmi and friends.

Signed-off-by: Aravinda Prasad 
Reviewed-by: David Gibson 
---
 arch/powerpc/kvm/book3s_hv.c|   27 +-
 arch/powerpc/kvm/book3s_hv_rmhandlers.S |   47 ---
 arch/powerpc/platforms/powernv/opal.c   |   10 +++
 3 files changed, 54 insertions(+), 30 deletions(-)

diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
index 3686471..cae4921 100644
--- a/arch/powerpc/kvm/book3s_hv.c
+++ b/arch/powerpc/kvm/book3s_hv.c
@@ -123,6 +123,7 @@ MODULE_PARM_DESC(halt_poll_ns_shrink, "Factor halt poll 
time is shrunk by");
 
 static void kvmppc_end_cede(struct kvm_vcpu *vcpu);
 static int kvmppc_hv_setup_htab_rma(struct kvm_vcpu *vcpu);
+static void kvmppc_machine_check_hook(void);
 
 static inline struct kvm_vcpu *next_runnable_thread(struct kvmppc_vcore *vc,
int *ip)
@@ -954,15 +955,14 @@ static int kvmppc_handle_exit_hv(struct kvm_run *run, 
struct kvm_vcpu *vcpu,
r = RESUME_GUEST;
break;
case BOOK3S_INTERRUPT_MACHINE_CHECK:
+   /* Exit to guest with KVM_EXIT_NMI as exit reason */
+   run->exit_reason = KVM_EXIT_NMI;
+   r = RESUME_HOST;
/*
-* Deliver a machine check interrupt to the guest.
-* We have to do this, even if the host has handled the
-* machine check, because machine checks use SRR0/1 and
-* the interrupt might have trashed guest state in them.
+* Invoke host-kernel handler to perform any host-side
+* handling before exiting the guest.
 */
-   kvmppc_book3s_queue_irqprio(vcpu,
-   BOOK3S_INTERRUPT_MACHINE_CHECK);
-   r = RESUME_GUEST;
+   kvmppc_machine_check_hook();
break;
case BOOK3S_INTERRUPT_PROGRAM:
{
@@ -3491,6 +3491,19 @@ static void kvmppc_irq_bypass_del_producer_hv(struct 
irq_bypass_consumer *cons,
 }
 #endif
 
+/*
+ * Hook to handle machine check exceptions occurred inside a guest.
+ * This hook is invoked from host virtual mode from KVM before exiting
+ * the guest with KVM_EXIT_NMI exit reason. This gives an opportunity
+ * for the host to take action (if any) before passing on the machine
+ * check exception to the guest kernel.
+ */
+static void kvmppc_machine_check_hook(void)
+{
+   if (ppc_md.machine_check_exception)
+   ppc_md.machine_check_exception(NULL);
+}
+
 static long kvm_arch_vm_ioctl_hv(struct file *filp,
 unsigned int ioctl, unsigned long arg)
 {
diff --git a/arch/powerpc/kvm/book3s_hv_rmhandlers.S 
b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
index c3c1d1b..9b41390 100644
--- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
+++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
@@ -134,21 +134,18 @@ END_FTR_SECTION_IFSET(CPU_FTR_ARCH_207S)
stb r0, HSTATE_HWTHREAD_REQ(r13)
 
/*
-* For external and machine check interrupts, we need
-* to call the Linux handler to process the interrupt.
-* We do that by jumping to absolute address 0x500 for
-* external interrupts, or the machine_check_fwnmi label
-* for 

[PATCH v5 1/2] KVM: PPC: Add new capability to control MCE behaviour

[Aravinda Prasad]

This patch introduces a new KVM capability to control
how KVM behaves on machine check exception (MCE).
Without this capability, KVM redirects machine check
exceptions to guest's 0x200 vector, if the address in
error belongs to the guest. With this capability KVM
causes a guest exit with NMI exit reason.

The new capability is required to avoid problems if
a new kernel/KVM is used with an old QEMU for guests
that don't issue "ibm,nmi-register". As old QEMU does
not understand the NMI exit type, it treats it as a
fatal error. However, the guest could have handled
the machine check error if the exception was delivered
to guest's 0x200 interrupt vector instead of NMI exit
in case of old QEMU.

Signed-off-by: Aravinda Prasad 
Reviewed-by: David Gibson 
---
 Documentation/virtual/kvm/api.txt   |   11 +++
 arch/powerpc/include/asm/kvm_host.h |1 +
 arch/powerpc/kernel/asm-offsets.c   |1 +
 arch/powerpc/kvm/powerpc.c  |7 +++
 include/uapi/linux/kvm.h|1 +
 5 files changed, 21 insertions(+)

diff --git a/Documentation/virtual/kvm/api.txt 
b/Documentation/virtual/kvm/api.txt
index 6bbceb9..748f7f7 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -3911,6 +3911,17 @@ to take care of that.
 This capability can be enabled dynamically even if VCPUs were already
 created and are running.
 
+7.9 KVM_CAP_PPC_FWNMI
+
+Architectures: ppc
+Parameters: none
+
+With this capability a machine check exception in the guest address
+space will cause KVM to exit the guest with NMI exit reason. This
+enables QEMU to build error log and branch to guest kernel registered
+machine check handling routine. Without this capability KVM will
+branch to guests' 0x200 interrupt vector.
+
 8. Other capabilities.
 --
 
diff --git a/arch/powerpc/include/asm/kvm_host.h 
b/arch/powerpc/include/asm/kvm_host.h
index 28350a2..018c684 100644
--- a/arch/powerpc/include/asm/kvm_host.h
+++ b/arch/powerpc/include/asm/kvm_host.h
@@ -264,6 +264,7 @@ struct kvm_arch {
int hpt_cma_alloc;
struct dentry *debugfs_dir;
struct dentry *htab_dentry;
+   u8 fwnmi_enabled;
 #endif /* CONFIG_KVM_BOOK3S_HV_POSSIBLE */
 #ifdef CONFIG_KVM_BOOK3S_PR_POSSIBLE
struct mutex hpt_mutex;
diff --git a/arch/powerpc/kernel/asm-offsets.c 
b/arch/powerpc/kernel/asm-offsets.c
index caec7bf..3acd503 100644
--- a/arch/powerpc/kernel/asm-offsets.c
+++ b/arch/powerpc/kernel/asm-offsets.c
@@ -494,6 +494,7 @@ int main(void)
DEFINE(KVM_NEED_FLUSH, offsetof(struct kvm, arch.need_tlb_flush.bits));
DEFINE(KVM_ENABLED_HCALLS, offsetof(struct kvm, arch.enabled_hcalls));
DEFINE(KVM_VRMA_SLB_V, offsetof(struct kvm, arch.vrma_slb_v));
+   DEFINE(KVM_FWNMI, offsetof(struct kvm, arch.fwnmi_enabled));
DEFINE(VCPU_DSISR, offsetof(struct kvm_vcpu, arch.shregs.dsisr));
DEFINE(VCPU_DAR, offsetof(struct kvm_vcpu, arch.shregs.dar));
DEFINE(VCPU_VPA, offsetof(struct kvm_vcpu, arch.vpa.pinned_addr));
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
index 70963c8..a4405a8 100644
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -604,6 +604,9 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
r = cpu_has_feature(CPU_FTR_TM_COMP) &&
is_kvmppc_hv_enabled(kvm);
break;
+   case KVM_CAP_PPC_FWNMI:
+   r = 1;
+   break;
default:
r = 0;
break;
@@ -1204,6 +1207,10 @@ static int kvm_vcpu_ioctl_enable_cap(struct kvm_vcpu 
*vcpu,
break;
}
 #endif /* CONFIG_KVM_XICS */
+   case KVM_CAP_PPC_FWNMI:
+   r = 0;
+   vcpu->kvm->arch.fwnmi_enabled = true;
+   break;
default:
r = -EINVAL;
break;
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index 4ee67cb..3e41c42 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -870,6 +870,7 @@ struct kvm_ppc_smmu_info {
 #define KVM_CAP_S390_USER_INSTR0 130
 #define KVM_CAP_MSI_DEVID 131
 #define KVM_CAP_PPC_HTM 132
+#define KVM_CAP_PPC_FWNMI 133
 
 #ifdef KVM_CAP_IRQ_ROUTING
 

[PATCH v5 0/2] KVM: PPC: Add FWNMI support for KVM guests on POWER

[Aravinda Prasad]

This series of patches add FWNMI support for KVM guests
on POWER.

Memory errors such as bit flips that cannot be corrected
by hardware is passed on to the kernel for handling
by raising machine check exception (an NMI). Upon such
machine check exceptions, if the address in error belongs
to the guest, the error is passed on to the guest
kernel for handling. However, for guest kernels that
have issued "ibm,nmi-register" call, QEMU should build
an error log and pass on the error log to the guest-
kernel registered machine check handler routine.

This patch series adds the functionality to pass on the
machine check exception to the guest kernel by
giving control to QEMU. QEMU builds the error log
and invokes the guest-kernel registered handler.

QEMU part can be found at:
http://lists.nongnu.org/archive/html/qemu-ppc/2015-12/msg00199.html

Change Log v5:
  - Added capability documentation. No functionality/code change.

Change Log v4:
  - Allow host-side handling of the machine check exception before
passing on the exception to the guest.

Change Log v3:
  - Split the patch into 2. First patch introduces the
new capability while the second one enhances KVM to
redirect MCE.
  - Fix access width bug

Change Log v2:
  - Added KVM capability

---

Aravinda Prasad (2):
  KVM: PPC: Add new capability to control MCE behaviour
  KVM: PPC: Exit guest upon MCE when FWNMI capability is enabled


 Documentation/virtual/kvm/api.txt   |   11 +++
 arch/powerpc/include/asm/kvm_host.h |1 +
 arch/powerpc/kernel/asm-offsets.c   |1 +
 arch/powerpc/kvm/book3s_hv.c|   27 +-
 arch/powerpc/kvm/book3s_hv_rmhandlers.S |   47 ---
 arch/powerpc/kvm/powerpc.c  |7 +
 arch/powerpc/platforms/powernv/opal.c   |   10 +++
 include/uapi/linux/kvm.h|1 +
 8 files changed, 75 insertions(+), 30 deletions(-)

--
Aravinda Prasad

Re: [PATCH v3 3/8] nios2: put setup.h in uapi

[Tobias Klauser]

On 2017-01-13 at 11:46:41 +0100, Nicolas Dichtel  
wrote:
> This header file is exported, but from a userland pov, it's just a wrapper
> to asm-generic/setup.h.
> 
> Signed-off-by: Nicolas Dichtel 

Reviewed-by: Tobias Klauser 

[PATCH v3 7/8] uapi: export all headers under uapi directories

[Nicolas Dichtel]

Regularly, when a new header is created in include/uapi/, the developer
forgets to add it in the corresponding Kbuild file. This error is usually
detected after the release is out.

In fact, all headers under uapi directories should be exported, thus it's
useless to have an exhaustive list.

After this patch, the following files, which were not exported, are now
exported (with make headers_install_all):
asm-unicore32/shmparam.h
asm-unicore32/ucontext.h
asm-hexagon/shmparam.h
asm-mips/ucontext.h
asm-mips/hwcap.h
asm-mips/reg.h
drm/vgem_drm.h
drm/armada_drm.h
drm/omap_drm.h
drm/etnaviv_drm.h
asm-tile/shmparam.h
asm-blackfin/shmparam.h
asm-blackfin/ucontext.h
asm-powerpc/perf_regs.h
rdma/qedr-abi.h
asm-parisc/kvm_para.h
asm-openrisc/shmparam.h
.install
asm-nios2/kvm_para.h
asm-nios2/ucontext.h
asm-sh/kvm_para.h
asm-sh/ucontext.h
asm-xtensa/kvm_para.h
asm-avr32/kvm_para.h
asm-m32r/kvm_para.h
asm-h8300/shmparam.h
asm-h8300/ucontext.h
asm-metag/kvm_para.h
asm-metag/shmparam.h
asm-metag/ucontext.h
asm-m68k/kvm_para.h
asm-m68k/shmparam.h
linux/bcache.h
linux/kvm.h
linux/kvm_para.h
linux/kfd_ioctl.h
linux/cryptouser.h
linux/kcm.h
linux/kcov.h
linux/seg6_iptunnel.h
linux/stm.h
linux/genwqe
linux/genwqe/.install
linux/genwqe/genwqe_card.h
linux/genwqe/..install.cmd
linux/seg6.h
linux/cifs
linux/cifs/.install
linux/cifs/cifs_mount.h
linux/cifs/..install.cmd
linux/auto_dev-ioctl.h
linux/userio.h
linux/pr.h
linux/wil6210_uapi.h
linux/a.out.h
linux/nilfs2_ondisk.h
linux/hash_info.h
linux/seg6_genl.h
linux/seg6_hmac.h
linux/batman_adv.h
linux/nsfs.h
linux/qrtr.h
linux/btrfs_tree.h
linux/coresight-stm.h
linux/dma-buf.h
linux/module.h
linux/lightnvm.h
linux/nilfs2_api.h
asm-cris/kvm_para.h
asm-arc/kvm_para.h
asm-arc/ucontext.h
..install.cmd
asm-c6x/shmparam.h
asm-c6x/ucontext.h

Thanks to Julien Floret  for the tip to get all
subdirs with a pure makefile command.

For the record, note that exported files for asm directories are a mix of
files listed by:
 - include/uapi/asm-generic/Kbuild.asm;
 - arch//include/uapi/asm/Kbuild;
 - arch//include/asm/Kbuild.

Signed-off-by: Nicolas Dichtel 
Acked-by: Daniel Vetter 
Acked-by: Russell King 
Acked-by: Mark Salter 
---
 Documentation/kbuild/makefiles.txt  |  55 ++--
 arch/alpha/include/uapi/asm/Kbuild  |  41 ---
 arch/arc/include/uapi/asm/Kbuild|   3 -
 arch/arm/include/uapi/asm/Kbuild|  17 -
 arch/arm64/include/uapi/asm/Kbuild  |  18 --
 arch/avr32/include/uapi/asm/Kbuild  |  20 --
 arch/blackfin/include/uapi/asm/Kbuild   |  17 -
 arch/c6x/include/uapi/asm/Kbuild|   8 -
 arch/cris/include/uapi/arch-v10/arch/Kbuild |   5 -
 arch/cris/include/uapi/arch-v32/arch/Kbuild |   3 -
 arch/cris/include/uapi/asm/Kbuild   |  43 +--
 arch/frv/include/uapi/asm/Kbuild|  33 --
 arch/h8300/include/uapi/asm/Kbuild  |  28 --
 arch/hexagon/include/asm/Kbuild |   3 -
 arch/hexagon/include/uapi/asm/Kbuild|  13 -
 arch/ia64/include/uapi/asm/Kbuild   |  45 ---
 arch/m32r/include/uapi/asm/Kbuild   |  31 --
 arch/m68k/include/uapi/asm/Kbuild   |  24 --
 arch/metag/include/uapi/asm/Kbuild  |   8 -
 arch/microblaze/include/uapi/asm/Kbuild |  32 --
 arch/mips/include/uapi/asm/Kbuild   |  37 ---
 arch/mn10300/include/uapi/asm/Kbuild|  32 --
 arch/nios2/include/uapi/asm/Kbuild  |   3 +-
 arch/openrisc/include/asm/Kbuild|   3 -
 arch/openrisc/include/uapi/asm/Kbuild   |   8 -
 arch/parisc/include/uapi/asm/Kbuild |  28 --
 arch/powerpc/include/uapi/asm/Kbuild|  45 ---
 arch/s390/include/uapi/asm/Kbuild   |  52 ---
 arch/score/include/asm/Kbuild   |   4 -
 arch/score/include/uapi/asm/Kbuild  |  32 --
 arch/sh/include/uapi/asm/Kbuild |  23 --
 arch/sparc/include/uapi/asm/Kbuild  |  48 ---
 arch/tile/include/asm/Kbuild|   3 -
 arch/tile/include/uapi/arch/Kbuild  |  17 -
 arch/tile/include/uapi/asm/Kbuild   |  19 +-
 arch/unicore32/include/uapi/asm/Kbuild  |   6 -
 arch/x86/include/uapi/asm/Kbuild|  58 
 arch/xtensa/include/uapi/asm/Kbuild |  23 --
 include/Kbuild  |   2 -
 include/asm-generic/Kbuild.asm  |   1 -
 include/scsi/fc/Kbuild  |   0
 include/uapi/Kbuild |  15 -
 include/uapi/asm-generic/Kbuild |  36 ---
 include/uapi/asm-generic/Kbuild.asm |  62 ++--
 include/uapi/drm/Kbuild |  22 --
 include/uapi/linux/Kbuild   | 483 
 include/uapi/linux/android/Kbuild   |   2 -
 include/uapi/linux/byteorder/Kbuild |   3 -
 include/uapi/linux/caif/Kbuild  |   3 -
 include/uapi/linux/can/Kbuild 

[PATCH v3 2/8] h8300: put bitsperlong.h in uapi

[Nicolas Dichtel]

This header file is exported, thus move it to uapi.

Signed-off-by: Nicolas Dichtel 
---
 arch/h8300/include/asm/bitsperlong.h  | 14 --
 arch/h8300/include/uapi/asm/bitsperlong.h | 14 ++
 2 files changed, 14 insertions(+), 14 deletions(-)
 delete mode 100644 arch/h8300/include/asm/bitsperlong.h
 create mode 100644 arch/h8300/include/uapi/asm/bitsperlong.h

diff --git a/arch/h8300/include/asm/bitsperlong.h 
b/arch/h8300/include/asm/bitsperlong.h
deleted file mode 100644
index e140e46729ac..
--- a/arch/h8300/include/asm/bitsperlong.h
+++ /dev/null
@@ -1,14 +0,0 @@
-#ifndef __ASM_H8300_BITS_PER_LONG
-#define __ASM_H8300_BITS_PER_LONG
-
-#include 
-
-#if !defined(__ASSEMBLY__)
-/* h8300-unknown-linux required long */
-#define __kernel_size_t __kernel_size_t
-typedef unsigned long  __kernel_size_t;
-typedef long   __kernel_ssize_t;
-typedef long   __kernel_ptrdiff_t;
-#endif
-
-#endif /* __ASM_H8300_BITS_PER_LONG */
diff --git a/arch/h8300/include/uapi/asm/bitsperlong.h 
b/arch/h8300/include/uapi/asm/bitsperlong.h
new file mode 100644
index ..e56cf72369b6
--- /dev/null
+++ b/arch/h8300/include/uapi/asm/bitsperlong.h
@@ -0,0 +1,14 @@
+#ifndef _UAPI_ASM_H8300_BITS_PER_LONG
+#define _UAPI_ASM_H8300_BITS_PER_LONG
+
+#include 
+
+#if !defined(__ASSEMBLY__)
+/* h8300-unknown-linux required long */
+#define __kernel_size_t __kernel_size_t
+typedef unsigned long  __kernel_size_t;
+typedef long   __kernel_ssize_t;
+typedef long   __kernel_ptrdiff_t;
+#endif
+
+#endif /* _UAPI_ASM_H8300_BITS_PER_LONG */
-- 
2.8.1

[PATCH v3 8/8] uapi: export all arch specifics directories

[Nicolas Dichtel]

This patch removes the need of subdir-y. Now all files/directories under
arch//include/uapi/ are exported.

The only change for userland is the layout of the command 'make
headers_install_all': directories asm- are replaced by arch-/.
Those new directories contains all files/directories of the specified arch.

Note that only cris and tile have more directories than only asm:
 - arch-v[10|32] for cris;
 - arch for tile.

Signed-off-by: Nicolas Dichtel 
---
 Documentation/kbuild/makefiles.txt | 15 +--
 Makefile   |  4 ++--
 arch/cris/include/uapi/asm/Kbuild  |  3 ---
 arch/tile/include/uapi/asm/Kbuild  |  2 --
 scripts/Makefile.headersinst   |  3 +--
 5 files changed, 4 insertions(+), 23 deletions(-)

diff --git a/Documentation/kbuild/makefiles.txt 
b/Documentation/kbuild/makefiles.txt
index 51c072049e45..87a3d7d86776 100644
--- a/Documentation/kbuild/makefiles.txt
+++ b/Documentation/kbuild/makefiles.txt
@@ -48,7 +48,6 @@ This document describes the Linux kernel Makefiles.
--- 7.2 genhdr-y
--- 7.3 generic-y
--- 7.4 generated-y
-   --- 7.5 subdir-y
 
=== 8 Kbuild Variables
=== 9 Makefile language
@@ -1264,7 +1263,7 @@ The pre-processing does:
 - drop all sections that are kernel internal (guarded by ifdef __KERNEL__)
 
 All headers under include/uapi/, include/generated/uapi/,
-arch//include/uapi/asm/ and arch//include/generated/uapi/asm/
+arch//include/uapi/ and arch//include/generated/uapi/
 are exported.
 
 A Kbuild file may be defined under arch//include/uapi/asm/ and
@@ -1331,18 +1330,6 @@ See subsequent chapter for the syntax of the Kbuild file.
#arch/x86/include/asm/Kbuild
generated-y += syscalls_32.h
 
-   --- 7.5 subdir-y
-
-   subdir-y may be used to specify a subdirectory to be exported.
-
-   Example:
-   #arch/cris/include/uapi/asm/Kbuild
-   subdir-y += ../arch-v10/arch/
-   subdir-y += ../arch-v32/arch/
-
-   The convention is to list one subdir per line and
-   preferably in alphabetic order.
-
 === 8 Kbuild Variables
 
 The top Makefile exports the following variables:
diff --git a/Makefile b/Makefile
index 5f1a84735ff6..a35098157b69 100644
--- a/Makefile
+++ b/Makefile
@@ -1126,7 +1126,7 @@ firmware_install:
 export INSTALL_HDR_PATH = $(objtree)/usr
 
 # If we do an all arch process set dst to asm-$(hdr-arch)
-hdr-dst = $(if $(KBUILD_HEADERS), dst=include/asm-$(hdr-arch), dst=include/asm)
+hdr-dst = $(if $(KBUILD_HEADERS), dst=include/arch-$(hdr-arch), dst=include)
 
 PHONY += archheaders
 archheaders:
@@ -1147,7 +1147,7 @@ headers_install: __headers
$(if $(wildcard $(srctree)/arch/$(hdr-arch)/include/uapi/asm/Kbuild),, \
  $(error Headers not exportable for the $(SRCARCH) architecture))
$(Q)$(MAKE) $(hdr-inst)=include/uapi
-   $(Q)$(MAKE) $(hdr-inst)=arch/$(hdr-arch)/include/uapi/asm $(hdr-dst)
+   $(Q)$(MAKE) $(hdr-inst)=arch/$(hdr-arch)/include/uapi $(hdr-dst)
 
 PHONY += headers_check_all
 headers_check_all: headers_install_all
diff --git a/arch/cris/include/uapi/asm/Kbuild 
b/arch/cris/include/uapi/asm/Kbuild
index d0c5471856e0..b15bf6bc0e94 100644
--- a/arch/cris/include/uapi/asm/Kbuild
+++ b/arch/cris/include/uapi/asm/Kbuild
@@ -1,5 +1,2 @@
 # UAPI Header export list
 include include/uapi/asm-generic/Kbuild.asm
-
-subdir-y += ../arch-v10/arch/
-subdir-y += ../arch-v32/arch/
diff --git a/arch/tile/include/uapi/asm/Kbuild 
b/arch/tile/include/uapi/asm/Kbuild
index e0a50111e07f..0c74c3c5ebfa 100644
--- a/arch/tile/include/uapi/asm/Kbuild
+++ b/arch/tile/include/uapi/asm/Kbuild
@@ -2,5 +2,3 @@
 include include/uapi/asm-generic/Kbuild.asm
 
 generic-y += ucontext.h
-
-subdir-y += ../arch
diff --git a/scripts/Makefile.headersinst b/scripts/Makefile.headersinst
index 16ac3e71050e..cafaca2d9a23 100644
--- a/scripts/Makefile.headersinst
+++ b/scripts/Makefile.headersinst
@@ -2,7 +2,7 @@
 # Installing headers
 #
 # All headers under include/uapi, include/generated/uapi,
-# arch//include/uapi/asm and arch//include/generated/uapi/asm are
+# arch//include/uapi and arch//include/generated/uapi are
 # exported.
 # They are preprocessed to remove __KERNEL__ section of the file.
 #
@@ -28,7 +28,6 @@ include scripts/Kbuild.include
 installdir:= $(INSTALL_HDR_PATH)/$(subst uapi/,,$(_dst))
 
 subdirs   := $(patsubst $(srctree)/$(obj)/%/.,%,$(wildcard 
$(srctree)/$(obj)/*/.))
-subdirs   += $(subdir-y)
 header-files  := $(notdir $(wildcard $(srctree)/$(obj)/*.h))
 header-files  += $(notdir $(wildcard $(srctree)/$(obj)/*.agh))
 genhdr-files  := $(notdir $(wildcard $(srctree)/$(gen)/*.h))
-- 
2.8.1

[PATCH v3 3/8] nios2: put setup.h in uapi

[Nicolas Dichtel]

This header file is exported, but from a userland pov, it's just a wrapper
to asm-generic/setup.h.

Signed-off-by: Nicolas Dichtel 
---
 arch/nios2/include/uapi/asm/Kbuild | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/nios2/include/uapi/asm/Kbuild 
b/arch/nios2/include/uapi/asm/Kbuild
index e0bb972a50d7..69c965304146 100644
--- a/arch/nios2/include/uapi/asm/Kbuild
+++ b/arch/nios2/include/uapi/asm/Kbuild
@@ -2,4 +2,5 @@ include include/uapi/asm-generic/Kbuild.asm
 
 header-y += elf.h
 
+generic-y += setup.h
 generic-y += ucontext.h
-- 
2.8.1

[PATCH v3 0/8] uapi: export all headers under uapi directories

[Nicolas Dichtel]

Here is the v3 of this series. The first 5 patches are just cleanup: some
exported headers were still under a non-uapi directory or (x86 case) were
wrongly exported.
The patch 6 was spotted by code review: there is no in-tree user of this
functionality.
Patches 7 and 8 remove the need to list explicitly headers. Now all files
under an uapi directory are exported.

This series has been tested with a 'make headers_install' on x86 and a
'make headers_install_all'. I've checked the result of both commands.

This patch is built against linus tree. If I must rebase it against the kbuild
tree, just tell me ;-)

v2 -> v3:
 - patch #1: remove arch/arm/include/asm/types.h
 - patch #2: remove arch/h8300/include/asm/bitsperlong.h
 - patch #3: remove arch/nios2/include/uapi/asm/setup.h
 - patch #4: don't export msr-index.h
 - patch #5: fix a typo: s/unput-files3-name/input-files3-name
 - patch #6: no change
 - patch #7: fix include/uapi/asm-generic/Kbuild.asm by introducing mandatory-y
 - add patch #8

v1 -> v2:
 - add patch #1 to #6
 - patch #7: remove use of header-y

Comments are welcomed,
Nicolas

[PATCH v3 6/8] Makefile.headersinst: remove destination-y option

[Nicolas Dichtel]

This option was added in commit c7bb349e7c25 ("kbuild: introduce destination-y
for exported headers") but never used in-tree.

Signed-off-by: Nicolas Dichtel 
---
 Documentation/kbuild/makefiles.txt | 23 ---
 scripts/Makefile.headersinst   |  2 +-
 2 files changed, 5 insertions(+), 20 deletions(-)

diff --git a/Documentation/kbuild/makefiles.txt 
b/Documentation/kbuild/makefiles.txt
index 9b9c4797fc55..37b525d329ae 100644
--- a/Documentation/kbuild/makefiles.txt
+++ b/Documentation/kbuild/makefiles.txt
@@ -46,9 +46,8 @@ This document describes the Linux kernel Makefiles.
=== 7 Kbuild syntax for exported headers
--- 7.1 header-y
--- 7.2 genhdr-y
-   --- 7.3 destination-y
-   --- 7.4 generic-y
-   --- 7.5 generated-y
+   --- 7.3 generic-y
+   --- 7.4 generated-y
 
=== 8 Kbuild Variables
=== 9 Makefile language
@@ -1295,21 +1294,7 @@ See subsequent chapter for the syntax of the Kbuild file.
#include/linux/Kbuild
genhdr-y += version.h
 
-   --- 7.3 destination-y
-
-   When an architecture has a set of exported headers that needs to be
-   exported to a different directory destination-y is used.
-   destination-y specifies the destination directory for all exported
-   headers in the file where it is present.
-
-   Example:
-   #arch/xtensa/platforms/s6105/include/platform/Kbuild
-   destination-y := include/linux
-
-   In the example above all exported headers in the Kbuild file
-   will be located in the directory "include/linux" when exported.
-
-   --- 7.4 generic-y
+   --- 7.3 generic-y
 
If an architecture uses a verbatim copy of a header from
include/asm-generic then this is listed in the file
@@ -1336,7 +1321,7 @@ See subsequent chapter for the syntax of the Kbuild file.
Example: termios.h
#include 
 
-   --- 7.5 generated-y
+   --- 7.4 generated-y
 
If an architecture generates other header files alongside generic-y
wrappers, and not included in genhdr-y, then generated-y specifies
diff --git a/scripts/Makefile.headersinst b/scripts/Makefile.headersinst
index 3e20d03432d2..876b42cfede4 100644
--- a/scripts/Makefile.headersinst
+++ b/scripts/Makefile.headersinst
@@ -14,7 +14,7 @@ kbuild-file := $(srctree)/$(obj)/Kbuild
 include $(kbuild-file)
 
 # called may set destination dir (when installing to asm/)
-_dst := $(if $(destination-y),$(destination-y),$(if $(dst),$(dst),$(obj)))
+_dst := $(if $(dst),$(dst),$(obj))
 
 old-kbuild-file := $(srctree)/$(subst uapi/,,$(obj))/Kbuild
 ifneq ($(wildcard $(old-kbuild-file)),)
-- 
2.8.1

[PATCH v3 1/8] arm: put types.h in uapi

[Nicolas Dichtel]

This header file is exported, thus move it to uapi.

Signed-off-by: Nicolas Dichtel 
---
 arch/arm/include/asm/types.h  | 40 ---
 arch/arm/include/uapi/asm/types.h | 40 +++
 2 files changed, 40 insertions(+), 40 deletions(-)
 delete mode 100644 arch/arm/include/asm/types.h
 create mode 100644 arch/arm/include/uapi/asm/types.h

diff --git a/arch/arm/include/asm/types.h b/arch/arm/include/asm/types.h
deleted file mode 100644
index a53cdb8f068c..
--- a/arch/arm/include/asm/types.h
+++ /dev/null
@@ -1,40 +0,0 @@
-#ifndef _ASM_TYPES_H
-#define _ASM_TYPES_H
-
-#include 
-
-/*
- * The C99 types uintXX_t that are usually defined in 'stdint.h' are not as
- * unambiguous on ARM as you would expect. For the types below, there is a
- * difference on ARM between GCC built for bare metal ARM, GCC built for glibc
- * and the kernel itself, which results in build errors if you try to build 
with
- * -ffreestanding and include 'stdint.h' (such as when you include 'arm_neon.h'
- * in order to use NEON intrinsics)
- *
- * As the typedefs for these types in 'stdint.h' are based on builtin defines
- * supplied by GCC, we can tweak these to align with the kernel's idea of those
- * types, so 'linux/types.h' and 'stdint.h' can be safely included from the 
same
- * source file (provided that -ffreestanding is used).
- *
- *int32_t uint32_t   uintptr_t
- * bare metal GCC longunsigned long  unsigned int
- * glibc GCC  int unsigned int   unsigned int
- * kernel int unsigned int   unsigned long
- */
-
-#ifdef __INT32_TYPE__
-#undef __INT32_TYPE__
-#define __INT32_TYPE__ int
-#endif
-
-#ifdef __UINT32_TYPE__
-#undef __UINT32_TYPE__
-#define __UINT32_TYPE__unsigned int
-#endif
-
-#ifdef __UINTPTR_TYPE__
-#undef __UINTPTR_TYPE__
-#define __UINTPTR_TYPE__   unsigned long
-#endif
-
-#endif /* _ASM_TYPES_H */
diff --git a/arch/arm/include/uapi/asm/types.h 
b/arch/arm/include/uapi/asm/types.h
new file mode 100644
index ..9435a42f575e
--- /dev/null
+++ b/arch/arm/include/uapi/asm/types.h
@@ -0,0 +1,40 @@
+#ifndef _UAPI_ASM_TYPES_H
+#define _UAPI_ASM_TYPES_H
+
+#include 
+
+/*
+ * The C99 types uintXX_t that are usually defined in 'stdint.h' are not as
+ * unambiguous on ARM as you would expect. For the types below, there is a
+ * difference on ARM between GCC built for bare metal ARM, GCC built for glibc
+ * and the kernel itself, which results in build errors if you try to build 
with
+ * -ffreestanding and include 'stdint.h' (such as when you include 'arm_neon.h'
+ * in order to use NEON intrinsics)
+ *
+ * As the typedefs for these types in 'stdint.h' are based on builtin defines
+ * supplied by GCC, we can tweak these to align with the kernel's idea of those
+ * types, so 'linux/types.h' and 'stdint.h' can be safely included from the 
same
+ * source file (provided that -ffreestanding is used).
+ *
+ *int32_t uint32_t   uintptr_t
+ * bare metal GCC longunsigned long  unsigned int
+ * glibc GCC  int unsigned int   unsigned int
+ * kernel int unsigned int   unsigned long
+ */
+
+#ifdef __INT32_TYPE__
+#undef __INT32_TYPE__
+#define __INT32_TYPE__ int
+#endif
+
+#ifdef __UINT32_TYPE__
+#undef __UINT32_TYPE__
+#define __UINT32_TYPE__unsigned int
+#endif
+
+#ifdef __UINTPTR_TYPE__
+#undef __UINTPTR_TYPE__
+#define __UINTPTR_TYPE__   unsigned long
+#endif
+
+#endif /* _UAPI_ASM_TYPES_H */
-- 
2.8.1

[PATCH v3 5/8] Makefile.headersinst: cleanup input files

[Nicolas Dichtel]

After the last four patches, all exported headers are under uapi/, thus
input-files2 are not needed anymore.
The side effect is that input-files1-name is exactly header-y.

Note also that input-files3-name is genhdr-y.

Signed-off-by: Nicolas Dichtel 
---
 scripts/Makefile.headersinst | 34 +++---
 1 file changed, 11 insertions(+), 23 deletions(-)

diff --git a/scripts/Makefile.headersinst b/scripts/Makefile.headersinst
index 1106d6ca3a38..3e20d03432d2 100644
--- a/scripts/Makefile.headersinst
+++ b/scripts/Makefile.headersinst
@@ -40,31 +40,20 @@ wrapper-files := $(filter $(header-y), $(generic-y))
 srcdir:= $(srctree)/$(obj)
 gendir:= $(objtree)/$(gen)
 
-oldsrcdir := $(srctree)/$(subst /uapi,,$(obj))
-
 # all headers files for this dir
 header-y  := $(filter-out $(generic-y), $(header-y))
 all-files := $(header-y) $(genhdr-y) $(wrapper-files)
 output-files  := $(addprefix $(installdir)/, $(all-files))
 
-input-files1  := $(foreach hdr, $(header-y), \
-  $(if $(wildcard $(srcdir)/$(hdr)), \
-   $(wildcard $(srcdir)/$(hdr))) \
-  )
-input-files1-name := $(notdir $(input-files1))
-input-files2  := $(foreach hdr, $(header-y), \
-  $(if  $(wildcard $(srcdir)/$(hdr)),, \
-   $(if $(wildcard $(oldsrcdir)/$(hdr)), \
-   $(wildcard $(oldsrcdir)/$(hdr)), \
-   $(error Missing UAPI file $(srcdir)/$(hdr))) \
-  ))
-input-files2-name := $(notdir $(input-files2))
-input-files3  := $(foreach hdr, $(genhdr-y), \
-  $(if $(wildcard $(gendir)/$(hdr)), \
-   $(wildcard $(gendir)/$(hdr)), \
-   $(error Missing generated UAPI file $(gendir)/$(hdr)) \
-  ))
-input-files3-name := $(notdir $(input-files3))
+# Check that all expected files exist
+$(foreach hdr, $(header-y), \
+  $(if $(wildcard $(srcdir)/$(hdr)),, \
+   $(error Missing UAPI file $(srcdir)/$(hdr)) \
+   ))
+$(foreach hdr, $(genhdr-y), \
+  $(if $(wildcard $(gendir)/$(hdr)),, \
+   $(error Missing generated UAPI file $(gendir)/$(hdr)) \
+  ))
 
 # Work out what needs to be removed
 oldheaders:= $(patsubst $(installdir)/%,%,$(wildcard $(installdir)/*.h))
@@ -78,9 +67,8 @@ printdir = $(patsubst $(INSTALL_HDR_PATH)/%/,%,$(dir $@))
 quiet_cmd_install = INSTALL $(printdir) ($(words $(all-files))\
 file$(if $(word 2, $(all-files)),s))
   cmd_install = \
-$(CONFIG_SHELL) $< $(installdir) $(srcdir) $(input-files1-name); \
-$(CONFIG_SHELL) $< $(installdir) $(oldsrcdir) $(input-files2-name); \
-$(CONFIG_SHELL) $< $(installdir) $(gendir) $(input-files3-name); \
+$(CONFIG_SHELL) $< $(installdir) $(srcdir) $(header-y); \
+$(CONFIG_SHELL) $< $(installdir) $(gendir) $(genhdr-y); \
 for F in $(wrapper-files); do   \
 echo "\#include " > $(installdir)/$$F;\
 done;   \
-- 
2.8.1

[PATCH v3 4/8] x86: stop exporting msr-index.h to userland

[Nicolas Dichtel]

Suggested-by: Borislav Petkov 
Signed-off-by: Nicolas Dichtel 
---
 arch/x86/include/uapi/asm/Kbuild | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/x86/include/uapi/asm/Kbuild b/arch/x86/include/uapi/asm/Kbuild
index 3dec769cadf7..1c532b3f18ea 100644
--- a/arch/x86/include/uapi/asm/Kbuild
+++ b/arch/x86/include/uapi/asm/Kbuild
@@ -27,7 +27,6 @@ header-y += ldt.h
 header-y += mce.h
 header-y += mman.h
 header-y += msgbuf.h
-header-y += msr-index.h
 header-y += msr.h
 header-y += mtrr.h
 header-y += param.h
-- 
2.8.1

Re: [PATCH] powerpc: Use octal numbers for file permissions

[Balbir Singh]

On Thu, Jan 12, 2017 at 02:54:13PM +1100, Russell Currey wrote:
> Symbolic macros are unintuitive and hard to read, whereas octal constants
> are much easier to interpret.  Replace macros for the basic permission
> flags (user/group/other read/write/execute) with numeric constants
> instead, across the whole powerpc tree.
>

I know Linus said otherwise, but I wonder if the churn is worth it.
At user mode (do man 2 chmod), these constants are used frequently,
even with chmod the command we use chmod a+r equivalents or chmod
u+r. My big concern with numbers is how do you know you did not
turn on the sticky bit for a file? Can you imagine if someone used
0x644 or 0x444 would we catch it?

Not resisting, but thinking if the churn and what follows might be
OK.

Balbir Singh.