Re: stmmac ethernet in kernel 4.9-rc6: coalescing related pauses.

[Lino Sanfilippo]

Hi Pavel,

On 05.12.2016 23:02, Pavel Machek wrote:
> 
> we need spin_lock_bh at minimum, as we are locking user context
> against timer.
> 
> Best regards,
>   Pavel
> 

I was referring to stmmac_tx_clean() which AFAICS is only called from softirq 
context,
(one time in the timer handler and one time in napi poll handler) so a 
spin_lock() should
be sufficient. I cant see how this is called from userspace. If it were, a 
spin_lock_bh() had
to be used, of course.

Regards,
Lino 

Re: stmmac ethernet in kernel 4.9-rc6: coalescing related pauses.

[Lino Sanfilippo]

Hi Pavel,

On 05.12.2016 23:02, Pavel Machek wrote:
> 
> we need spin_lock_bh at minimum, as we are locking user context
> against timer.
> 
> Best regards,
>   Pavel
> 

I was referring to stmmac_tx_clean() which AFAICS is only called from softirq 
context,
(one time in the timer handler and one time in napi poll handler) so a 
spin_lock() should
be sufficient. I cant see how this is called from userspace. If it were, a 
spin_lock_bh() had
to be used, of course.

Regards,
Lino 

Re: [PATCH] ACPI/IORT: Make dma masks set-up IORT specific

[Rafael J. Wysocki]

On Mon, Dec 5, 2016 at 1:26 PM, Lorenzo Pieralisi
 wrote:
> The introduction of acpi_dma_configure() allows to configure DMA
> and related IOMMU for any device that is DMA capable. To achieve
> that goal it ensures DMA masks are set-up to sane default values
> before proceeding with IOMMU and DMA ops configuration.
>
> On x86/ia64 systems, through acpi_bind_one(), acpi_dma_configure() is
> called for every device that has an ACPI companion, in that every device
> is considered DMA capable on x86/ia64 systems (ie acpi_get_dma_attr() API),
> which has the side effect of initializing dma masks also for
> pseudo-devices (eg CPUs and memory nodes) and potentially for devices
> whose dma masks were not set-up before the acpi_dma_configure() API was
> introduced, which may have noxious side effects.
>
> Therefore, in preparation for IORT firmware specific DMA masks set-up,
> wrap the default DMA masks set-up in acpi_dma_configure() inside an IORT
> specific wrapper that reverts to a NOP on x86/ia64 systems, restoring the
> default expected behaviour on x86/ia64 systems and keeping DMA default
> masks set-up on IORT based (ie ARM) arch configurations.
>
> Signed-off-by: Lorenzo Pieralisi 
> Cc: Will Deacon 
> Cc: Hanjun Guo 
> Cc: Bjorn Helgaas 
> Cc: Robin Murphy 
> Cc: Tomasz Nowicki 
> Cc: Joerg Roedel 
> Cc: "Rafael J. Wysocki" 
> Cc: Sricharan R 

Acked -by: Rafael J. Wysocki 

> ---
> Joerg,
>
> pending Rafael's ACK on it, given the 4.10 release timing and that the
> series is queued via the IOMMU tree please consider applying this patch to
> your arm/smmu branch for 4.10, it is not fixing a bug but it is modifying
> the x86/ia64 code path; I prefer preventing any issue related to default
> dma masks on x86/ia64 so I hope it can get merged along with the rest of
> the ACPI IORT SMMU series.
>
> Thanks a lot and apologies,
> Lorenzo
>
>  drivers/acpi/arm64/iort.c | 22 ++
>  drivers/acpi/scan.c   | 14 +-
>  include/linux/acpi_iort.h |  2 ++
>  3 files changed, 25 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> index 47bace8..e0d2e6e 100644
> --- a/drivers/acpi/arm64/iort.c
> +++ b/drivers/acpi/arm64/iort.c
> @@ -547,6 +547,28 @@ static const struct iommu_ops *iort_iommu_xlate(struct 
> device *dev,
>  }
>
>  /**
> + * iort_set_dma_mask - Set-up dma mask for a device.
> + *
> + * @dev: device to configure
> + */
> +void iort_set_dma_mask(struct device *dev)
> +{
> +   /*
> +* Set default coherent_dma_mask to 32 bit.  Drivers are expected to
> +* setup the correct supported mask.
> +*/
> +   if (!dev->coherent_dma_mask)
> +   dev->coherent_dma_mask = DMA_BIT_MASK(32);
> +
> +   /*
> +* Set it to coherent_dma_mask by default if the architecture
> +* code has not set it.
> +*/
> +   if (!dev->dma_mask)
> +   dev->dma_mask = >coherent_dma_mask;
> +}
> +
> +/**
>   * iort_iommu_configure - Set-up IOMMU configuration for a device.
>   *
>   * @dev: device to configure
> diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
> index 80698d3..93b00cf 100644
> --- a/drivers/acpi/scan.c
> +++ b/drivers/acpi/scan.c
> @@ -1380,19 +1380,7 @@ void acpi_dma_configure(struct device *dev, enum 
> dev_dma_attr attr)
>  {
> const struct iommu_ops *iommu;
>
> -   /*
> -* Set default coherent_dma_mask to 32 bit.  Drivers are expected to
> -* setup the correct supported mask.
> -*/
> -   if (!dev->coherent_dma_mask)
> -   dev->coherent_dma_mask = DMA_BIT_MASK(32);
> -
> -   /*
> -* Set it to coherent_dma_mask by default if the architecture
> -* code has not set it.
> -*/
> -   if (!dev->dma_mask)
> -   dev->dma_mask = >coherent_dma_mask;
> +   iort_set_dma_mask(dev);
>
> iommu = iort_iommu_configure(dev);
>
> diff --git a/include/linux/acpi_iort.h b/include/linux/acpi_iort.h
> index dcb2b60..77e0809 100644
> --- a/include/linux/acpi_iort.h
> +++ b/include/linux/acpi_iort.h
> @@ -35,6 +35,7 @@ bool iort_node_match(u8 type);
>  u32 iort_msi_map_rid(struct device *dev, u32 req_id);
>  struct irq_domain *iort_get_device_domain(struct device *dev, u32 req_id);
>  /* IOMMU interface */
> +void iort_set_dma_mask(struct device *dev);
>  const struct iommu_ops *iort_iommu_configure(struct device *dev);
>  #else
>  static inline void acpi_iort_init(void) { }
> @@ -45,6 +46,7 @@ static inline struct irq_domain 
> *iort_get_device_domain(struct device *dev,
> u32 req_id)
>  { return NULL; }
>  /* IOMMU interface */
> +static inline void 

Re: [PATCH] ACPI/IORT: Make dma masks set-up IORT specific

[Rafael J. Wysocki]

On Mon, Dec 5, 2016 at 1:26 PM, Lorenzo Pieralisi
 wrote:
> The introduction of acpi_dma_configure() allows to configure DMA
> and related IOMMU for any device that is DMA capable. To achieve
> that goal it ensures DMA masks are set-up to sane default values
> before proceeding with IOMMU and DMA ops configuration.
>
> On x86/ia64 systems, through acpi_bind_one(), acpi_dma_configure() is
> called for every device that has an ACPI companion, in that every device
> is considered DMA capable on x86/ia64 systems (ie acpi_get_dma_attr() API),
> which has the side effect of initializing dma masks also for
> pseudo-devices (eg CPUs and memory nodes) and potentially for devices
> whose dma masks were not set-up before the acpi_dma_configure() API was
> introduced, which may have noxious side effects.
>
> Therefore, in preparation for IORT firmware specific DMA masks set-up,
> wrap the default DMA masks set-up in acpi_dma_configure() inside an IORT
> specific wrapper that reverts to a NOP on x86/ia64 systems, restoring the
> default expected behaviour on x86/ia64 systems and keeping DMA default
> masks set-up on IORT based (ie ARM) arch configurations.
>
> Signed-off-by: Lorenzo Pieralisi 
> Cc: Will Deacon 
> Cc: Hanjun Guo 
> Cc: Bjorn Helgaas 
> Cc: Robin Murphy 
> Cc: Tomasz Nowicki 
> Cc: Joerg Roedel 
> Cc: "Rafael J. Wysocki" 
> Cc: Sricharan R 

Acked -by: Rafael J. Wysocki 

> ---
> Joerg,
>
> pending Rafael's ACK on it, given the 4.10 release timing and that the
> series is queued via the IOMMU tree please consider applying this patch to
> your arm/smmu branch for 4.10, it is not fixing a bug but it is modifying
> the x86/ia64 code path; I prefer preventing any issue related to default
> dma masks on x86/ia64 so I hope it can get merged along with the rest of
> the ACPI IORT SMMU series.
>
> Thanks a lot and apologies,
> Lorenzo
>
>  drivers/acpi/arm64/iort.c | 22 ++
>  drivers/acpi/scan.c   | 14 +-
>  include/linux/acpi_iort.h |  2 ++
>  3 files changed, 25 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> index 47bace8..e0d2e6e 100644
> --- a/drivers/acpi/arm64/iort.c
> +++ b/drivers/acpi/arm64/iort.c
> @@ -547,6 +547,28 @@ static const struct iommu_ops *iort_iommu_xlate(struct 
> device *dev,
>  }
>
>  /**
> + * iort_set_dma_mask - Set-up dma mask for a device.
> + *
> + * @dev: device to configure
> + */
> +void iort_set_dma_mask(struct device *dev)
> +{
> +   /*
> +* Set default coherent_dma_mask to 32 bit.  Drivers are expected to
> +* setup the correct supported mask.
> +*/
> +   if (!dev->coherent_dma_mask)
> +   dev->coherent_dma_mask = DMA_BIT_MASK(32);
> +
> +   /*
> +* Set it to coherent_dma_mask by default if the architecture
> +* code has not set it.
> +*/
> +   if (!dev->dma_mask)
> +   dev->dma_mask = >coherent_dma_mask;
> +}
> +
> +/**
>   * iort_iommu_configure - Set-up IOMMU configuration for a device.
>   *
>   * @dev: device to configure
> diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
> index 80698d3..93b00cf 100644
> --- a/drivers/acpi/scan.c
> +++ b/drivers/acpi/scan.c
> @@ -1380,19 +1380,7 @@ void acpi_dma_configure(struct device *dev, enum 
> dev_dma_attr attr)
>  {
> const struct iommu_ops *iommu;
>
> -   /*
> -* Set default coherent_dma_mask to 32 bit.  Drivers are expected to
> -* setup the correct supported mask.
> -*/
> -   if (!dev->coherent_dma_mask)
> -   dev->coherent_dma_mask = DMA_BIT_MASK(32);
> -
> -   /*
> -* Set it to coherent_dma_mask by default if the architecture
> -* code has not set it.
> -*/
> -   if (!dev->dma_mask)
> -   dev->dma_mask = >coherent_dma_mask;
> +   iort_set_dma_mask(dev);
>
> iommu = iort_iommu_configure(dev);
>
> diff --git a/include/linux/acpi_iort.h b/include/linux/acpi_iort.h
> index dcb2b60..77e0809 100644
> --- a/include/linux/acpi_iort.h
> +++ b/include/linux/acpi_iort.h
> @@ -35,6 +35,7 @@ bool iort_node_match(u8 type);
>  u32 iort_msi_map_rid(struct device *dev, u32 req_id);
>  struct irq_domain *iort_get_device_domain(struct device *dev, u32 req_id);
>  /* IOMMU interface */
> +void iort_set_dma_mask(struct device *dev);
>  const struct iommu_ops *iort_iommu_configure(struct device *dev);
>  #else
>  static inline void acpi_iort_init(void) { }
> @@ -45,6 +46,7 @@ static inline struct irq_domain 
> *iort_get_device_domain(struct device *dev,
> u32 req_id)
>  { return NULL; }
>  /* IOMMU interface */
> +static inline void iort_set_dma_mask(struct device *dev) { }
>  static inline
>  const struct iommu_ops *iort_iommu_configure(struct device *dev)
>  { return NULL; }
> --
> 2.10.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to 

[PATCH v3 net-next v3 3/4] net: dsa: mv88e6xxx: add a soft reset operation

[Vivien Didelot]

Marvell chips have different way to issue a software reset.

Old chips (such as 88E6060) have a reset bit in an ATU control register.

Newer chips moved this bit in a Global control register. Chips with
controllable PPU should reset the PPU when resetting the switch.

Add a new reset operation to implement these differences and introduce a
mv88e6xxx_software_reset() helper to wrap it conveniently.

Signed-off-by: Vivien Didelot 
---
 drivers/net/dsa/mv88e6xxx/chip.c  |  72 ++--
 drivers/net/dsa/mv88e6xxx/global1.c   | 121 ++
 drivers/net/dsa/mv88e6xxx/global1.h   |   4 ++
 drivers/net/dsa/mv88e6xxx/mv88e6xxx.h |  15 +++--
 4 files changed, 172 insertions(+), 40 deletions(-)

diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index 27dfb5d..5aae5d7 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -545,7 +545,8 @@ static int mv88e6xxx_ppu_disable(struct mv88e6xxx_chip 
*chip)
return err;
 
usleep_range(1000, 2000);
-   if ((val & GLOBAL_STATUS_PPU_MASK) != GLOBAL_STATUS_PPU_POLLING)
+   val &= GLOBAL_STATUS_PPU_STATE_MASK;
+   if (val != GLOBAL_STATUS_PPU_STATE_POLLING)
return 0;
}
 
@@ -572,7 +573,8 @@ static int mv88e6xxx_ppu_enable(struct mv88e6xxx_chip *chip)
return err;
 
usleep_range(1000, 2000);
-   if ((val & GLOBAL_STATUS_PPU_MASK) == GLOBAL_STATUS_PPU_POLLING)
+   val &= GLOBAL_STATUS_PPU_STATE_MASK;
+   if (val == GLOBAL_STATUS_PPU_STATE_POLLING)
return 0;
}
 
@@ -2356,6 +2358,14 @@ static void mv88e6xxx_port_bridge_leave(struct 
dsa_switch *ds, int port)
mutex_unlock(>reg_lock);
 }
 
+static int mv88e6xxx_software_reset(struct mv88e6xxx_chip *chip)
+{
+   if (chip->info->ops->reset)
+   return chip->info->ops->reset(chip);
+
+   return 0;
+}
+
 static void mv88e6xxx_hardware_reset(struct mv88e6xxx_chip *chip)
 {
struct gpio_desc *gpiod = chip->reset;
@@ -2391,10 +2401,6 @@ static int mv88e6xxx_disable_ports(struct mv88e6xxx_chip 
*chip)
 
 static int mv88e6xxx_switch_reset(struct mv88e6xxx_chip *chip)
 {
-   bool ppu_active = mv88e6xxx_has(chip, MV88E6XXX_FLAG_PPU_ACTIVE);
-   u16 is_reset = (ppu_active ? 0x8800 : 0xc800);
-   unsigned long timeout;
-   u16 reg;
int err;
 
err = mv88e6xxx_disable_ports(chip);
@@ -2403,34 +2409,7 @@ static int mv88e6xxx_switch_reset(struct mv88e6xxx_chip 
*chip)
 
mv88e6xxx_hardware_reset(chip);
 
-   /* Reset the switch. Keep the PPU active if requested. The PPU
-* needs to be active to support indirect phy register access
-* through global registers 0x18 and 0x19.
-*/
-   if (ppu_active)
-   err = mv88e6xxx_g1_write(chip, 0x04, 0xc000);
-   else
-   err = mv88e6xxx_g1_write(chip, 0x04, 0xc400);
-   if (err)
-   return err;
-
-   /* Wait up to one second for reset to complete. */
-   timeout = jiffies + 1 * HZ;
-   while (time_before(jiffies, timeout)) {
-   err = mv88e6xxx_g1_read(chip, 0x00, );
-   if (err)
-   return err;
-
-   if ((reg & is_reset) == is_reset)
-   break;
-   usleep_range(1000, 2000);
-   }
-   if (time_after(jiffies, timeout))
-   err = -ETIMEDOUT;
-   else
-   err = 0;
-
-   return err;
+   return mv88e6xxx_software_reset(chip);
 }
 
 static int mv88e6xxx_serdes_power_on(struct mv88e6xxx_chip *chip)
@@ -3244,6 +3223,7 @@ static const struct mv88e6xxx_ops mv88e6085_ops = {
.g1_set_cpu_port = mv88e6095_g1_set_cpu_port,
.g1_set_egress_port = mv88e6095_g1_set_egress_port,
.mgmt_rsvd2cpu = mv88e6095_g2_mgmt_rsvd2cpu,
+   .reset = mv88e6185_g1_reset,
 };
 
 static const struct mv88e6xxx_ops mv88e6095_ops = {
@@ -3261,6 +3241,7 @@ static const struct mv88e6xxx_ops mv88e6095_ops = {
.stats_get_strings = mv88e6095_stats_get_strings,
.stats_get_stats = mv88e6095_stats_get_stats,
.mgmt_rsvd2cpu = mv88e6095_g2_mgmt_rsvd2cpu,
+   .reset = mv88e6185_g1_reset,
 };
 
 static const struct mv88e6xxx_ops mv88e6097_ops = {
@@ -3285,6 +3266,7 @@ static const struct mv88e6xxx_ops mv88e6097_ops = {
.g1_set_cpu_port = mv88e6095_g1_set_cpu_port,
.g1_set_egress_port = mv88e6095_g1_set_egress_port,
.mgmt_rsvd2cpu = mv88e6095_g2_mgmt_rsvd2cpu,
+   .reset = mv88e6352_g1_reset,
 };
 
 static const struct mv88e6xxx_ops mv88e6123_ops = {
@@ -3304,6 +3286,7 @@ static const struct mv88e6xxx_ops mv88e6123_ops = {
.g1_set_cpu_port = mv88e6095_g1_set_cpu_port,
.g1_set_egress_port = mv88e6095_g1_set_egress_port,

[PATCH v3 net-next v3 3/4] net: dsa: mv88e6xxx: add a soft reset operation

[Vivien Didelot]

Marvell chips have different way to issue a software reset.

Old chips (such as 88E6060) have a reset bit in an ATU control register.

Newer chips moved this bit in a Global control register. Chips with
controllable PPU should reset the PPU when resetting the switch.

Add a new reset operation to implement these differences and introduce a
mv88e6xxx_software_reset() helper to wrap it conveniently.

Signed-off-by: Vivien Didelot 
---
 drivers/net/dsa/mv88e6xxx/chip.c  |  72 ++--
 drivers/net/dsa/mv88e6xxx/global1.c   | 121 ++
 drivers/net/dsa/mv88e6xxx/global1.h   |   4 ++
 drivers/net/dsa/mv88e6xxx/mv88e6xxx.h |  15 +++--
 4 files changed, 172 insertions(+), 40 deletions(-)

diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index 27dfb5d..5aae5d7 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -545,7 +545,8 @@ static int mv88e6xxx_ppu_disable(struct mv88e6xxx_chip 
*chip)
return err;
 
usleep_range(1000, 2000);
-   if ((val & GLOBAL_STATUS_PPU_MASK) != GLOBAL_STATUS_PPU_POLLING)
+   val &= GLOBAL_STATUS_PPU_STATE_MASK;
+   if (val != GLOBAL_STATUS_PPU_STATE_POLLING)
return 0;
}
 
@@ -572,7 +573,8 @@ static int mv88e6xxx_ppu_enable(struct mv88e6xxx_chip *chip)
return err;
 
usleep_range(1000, 2000);
-   if ((val & GLOBAL_STATUS_PPU_MASK) == GLOBAL_STATUS_PPU_POLLING)
+   val &= GLOBAL_STATUS_PPU_STATE_MASK;
+   if (val == GLOBAL_STATUS_PPU_STATE_POLLING)
return 0;
}
 
@@ -2356,6 +2358,14 @@ static void mv88e6xxx_port_bridge_leave(struct 
dsa_switch *ds, int port)
mutex_unlock(>reg_lock);
 }
 
+static int mv88e6xxx_software_reset(struct mv88e6xxx_chip *chip)
+{
+   if (chip->info->ops->reset)
+   return chip->info->ops->reset(chip);
+
+   return 0;
+}
+
 static void mv88e6xxx_hardware_reset(struct mv88e6xxx_chip *chip)
 {
struct gpio_desc *gpiod = chip->reset;
@@ -2391,10 +2401,6 @@ static int mv88e6xxx_disable_ports(struct mv88e6xxx_chip 
*chip)
 
 static int mv88e6xxx_switch_reset(struct mv88e6xxx_chip *chip)
 {
-   bool ppu_active = mv88e6xxx_has(chip, MV88E6XXX_FLAG_PPU_ACTIVE);
-   u16 is_reset = (ppu_active ? 0x8800 : 0xc800);
-   unsigned long timeout;
-   u16 reg;
int err;
 
err = mv88e6xxx_disable_ports(chip);
@@ -2403,34 +2409,7 @@ static int mv88e6xxx_switch_reset(struct mv88e6xxx_chip 
*chip)
 
mv88e6xxx_hardware_reset(chip);
 
-   /* Reset the switch. Keep the PPU active if requested. The PPU
-* needs to be active to support indirect phy register access
-* through global registers 0x18 and 0x19.
-*/
-   if (ppu_active)
-   err = mv88e6xxx_g1_write(chip, 0x04, 0xc000);
-   else
-   err = mv88e6xxx_g1_write(chip, 0x04, 0xc400);
-   if (err)
-   return err;
-
-   /* Wait up to one second for reset to complete. */
-   timeout = jiffies + 1 * HZ;
-   while (time_before(jiffies, timeout)) {
-   err = mv88e6xxx_g1_read(chip, 0x00, );
-   if (err)
-   return err;
-
-   if ((reg & is_reset) == is_reset)
-   break;
-   usleep_range(1000, 2000);
-   }
-   if (time_after(jiffies, timeout))
-   err = -ETIMEDOUT;
-   else
-   err = 0;
-
-   return err;
+   return mv88e6xxx_software_reset(chip);
 }
 
 static int mv88e6xxx_serdes_power_on(struct mv88e6xxx_chip *chip)
@@ -3244,6 +3223,7 @@ static const struct mv88e6xxx_ops mv88e6085_ops = {
.g1_set_cpu_port = mv88e6095_g1_set_cpu_port,
.g1_set_egress_port = mv88e6095_g1_set_egress_port,
.mgmt_rsvd2cpu = mv88e6095_g2_mgmt_rsvd2cpu,
+   .reset = mv88e6185_g1_reset,
 };
 
 static const struct mv88e6xxx_ops mv88e6095_ops = {
@@ -3261,6 +3241,7 @@ static const struct mv88e6xxx_ops mv88e6095_ops = {
.stats_get_strings = mv88e6095_stats_get_strings,
.stats_get_stats = mv88e6095_stats_get_stats,
.mgmt_rsvd2cpu = mv88e6095_g2_mgmt_rsvd2cpu,
+   .reset = mv88e6185_g1_reset,
 };
 
 static const struct mv88e6xxx_ops mv88e6097_ops = {
@@ -3285,6 +3266,7 @@ static const struct mv88e6xxx_ops mv88e6097_ops = {
.g1_set_cpu_port = mv88e6095_g1_set_cpu_port,
.g1_set_egress_port = mv88e6095_g1_set_egress_port,
.mgmt_rsvd2cpu = mv88e6095_g2_mgmt_rsvd2cpu,
+   .reset = mv88e6352_g1_reset,
 };
 
 static const struct mv88e6xxx_ops mv88e6123_ops = {
@@ -3304,6 +3286,7 @@ static const struct mv88e6xxx_ops mv88e6123_ops = {
.g1_set_cpu_port = mv88e6095_g1_set_cpu_port,
.g1_set_egress_port = mv88e6095_g1_set_egress_port,
.mgmt_rsvd2cpu = 

[PATCH v3 net-next v3 2/4] net: dsa: mv88e6xxx: add helper to hardware reset

[Vivien Didelot]

Add an helper to toggle the eventual GPIO connected to the reset pin.

Signed-off-by: Vivien Didelot 
Reviewed-by: Andrew Lunn 
---
 drivers/net/dsa/mv88e6xxx/chip.c | 22 ++
 1 file changed, 14 insertions(+), 8 deletions(-)

diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index 1d4d3be..27dfb5d 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -2356,6 +2356,19 @@ static void mv88e6xxx_port_bridge_leave(struct 
dsa_switch *ds, int port)
mutex_unlock(>reg_lock);
 }
 
+static void mv88e6xxx_hardware_reset(struct mv88e6xxx_chip *chip)
+{
+   struct gpio_desc *gpiod = chip->reset;
+
+   /* If there is a GPIO connected to the reset pin, toggle it */
+   if (gpiod) {
+   gpiod_set_value_cansleep(gpiod, 1);
+   usleep_range(1, 2);
+   gpiod_set_value_cansleep(gpiod, 0);
+   usleep_range(1, 2);
+   }
+}
+
 static int mv88e6xxx_disable_ports(struct mv88e6xxx_chip *chip)
 {
int i, err;
@@ -2380,7 +2393,6 @@ static int mv88e6xxx_switch_reset(struct mv88e6xxx_chip 
*chip)
 {
bool ppu_active = mv88e6xxx_has(chip, MV88E6XXX_FLAG_PPU_ACTIVE);
u16 is_reset = (ppu_active ? 0x8800 : 0xc800);
-   struct gpio_desc *gpiod = chip->reset;
unsigned long timeout;
u16 reg;
int err;
@@ -2389,13 +2401,7 @@ static int mv88e6xxx_switch_reset(struct mv88e6xxx_chip 
*chip)
if (err)
return err;
 
-   /* If there is a gpio connected to the reset pin, toggle it */
-   if (gpiod) {
-   gpiod_set_value_cansleep(gpiod, 1);
-   usleep_range(1, 2);
-   gpiod_set_value_cansleep(gpiod, 0);
-   usleep_range(1, 2);
-   }
+   mv88e6xxx_hardware_reset(chip);
 
/* Reset the switch. Keep the PPU active if requested. The PPU
 * needs to be active to support indirect phy register access
-- 
2.10.2

[PATCH v3 net-next v3 4/4] net: dsa: mv88e6xxx: add PPU operations

[Vivien Didelot]

Some Marvell chips can enable/disable the PPU on demand. This is needed
to access the PHY registers when there is no indirection mechanism.

Add two new ppu_enable and ppu_disable ops to describe this and finally
get rid of the MV88E6XXX_FLAG_PPU* flags.

Signed-off-by: Vivien Didelot 
---
 drivers/net/dsa/mv88e6xxx/chip.c  | 76 ---
 drivers/net/dsa/mv88e6xxx/global1.c   | 57 ++
 drivers/net/dsa/mv88e6xxx/global1.h   |  3 ++
 drivers/net/dsa/mv88e6xxx/mv88e6xxx.h | 19 ++---
 4 files changed, 81 insertions(+), 74 deletions(-)

diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index 5aae5d7..731d262 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -527,58 +527,18 @@ int mv88e6xxx_update(struct mv88e6xxx_chip *chip, int 
addr, int reg, u16 update)
 
 static int mv88e6xxx_ppu_disable(struct mv88e6xxx_chip *chip)
 {
-   u16 val;
-   int i, err;
+   if (!chip->info->ops->ppu_disable)
+   return 0;
 
-   err = mv88e6xxx_g1_read(chip, GLOBAL_CONTROL, );
-   if (err)
-   return err;
-
-   err = mv88e6xxx_g1_write(chip, GLOBAL_CONTROL,
-val & ~GLOBAL_CONTROL_PPU_ENABLE);
-   if (err)
-   return err;
-
-   for (i = 0; i < 16; i++) {
-   err = mv88e6xxx_g1_read(chip, GLOBAL_STATUS, );
-   if (err)
-   return err;
-
-   usleep_range(1000, 2000);
-   val &= GLOBAL_STATUS_PPU_STATE_MASK;
-   if (val != GLOBAL_STATUS_PPU_STATE_POLLING)
-   return 0;
-   }
-
-   return -ETIMEDOUT;
+   return chip->info->ops->ppu_disable(chip);
 }
 
 static int mv88e6xxx_ppu_enable(struct mv88e6xxx_chip *chip)
 {
-   u16 val;
-   int i, err;
+   if (!chip->info->ops->ppu_enable)
+   return 0;
 
-   err = mv88e6xxx_g1_read(chip, GLOBAL_CONTROL, );
-   if (err)
-   return err;
-
-   err = mv88e6xxx_g1_write(chip, GLOBAL_CONTROL,
-val | GLOBAL_CONTROL_PPU_ENABLE);
-   if (err)
-   return err;
-
-   for (i = 0; i < 16; i++) {
-   err = mv88e6xxx_g1_read(chip, GLOBAL_STATUS, );
-   if (err)
-   return err;
-
-   usleep_range(1000, 2000);
-   val &= GLOBAL_STATUS_PPU_STATE_MASK;
-   if (val == GLOBAL_STATUS_PPU_STATE_POLLING)
-   return 0;
-   }
-
-   return -ETIMEDOUT;
+   return chip->info->ops->ppu_enable(chip);
 }
 
 static void mv88e6xxx_ppu_reenable_work(struct work_struct *ugly)
@@ -2746,22 +2706,12 @@ static int mv88e6xxx_g1_setup(struct mv88e6xxx_chip 
*chip)
 {
struct dsa_switch *ds = chip->ds;
u32 upstream_port = dsa_upstream_port(ds);
-   u16 reg;
int err;
 
/* Enable the PHY Polling Unit if present, don't discard any packets,
 * and mask all interrupt sources.
 */
-   err = mv88e6xxx_g1_read(chip, GLOBAL_CONTROL, );
-   if (err < 0)
-   return err;
-
-   reg &= ~GLOBAL_CONTROL_PPU_ENABLE;
-   if (mv88e6xxx_has(chip, MV88E6XXX_FLAG_PPU) ||
-   mv88e6xxx_has(chip, MV88E6XXX_FLAG_PPU_ACTIVE))
-   reg |= GLOBAL_CONTROL_PPU_ENABLE;
-
-   err = mv88e6xxx_g1_write(chip, GLOBAL_CONTROL, reg);
+   err = mv88e6xxx_ppu_enable(chip);
if (err)
return err;
 
@@ -3223,6 +3173,8 @@ static const struct mv88e6xxx_ops mv88e6085_ops = {
.g1_set_cpu_port = mv88e6095_g1_set_cpu_port,
.g1_set_egress_port = mv88e6095_g1_set_egress_port,
.mgmt_rsvd2cpu = mv88e6095_g2_mgmt_rsvd2cpu,
+   .ppu_enable = mv88e6185_g1_ppu_enable,
+   .ppu_disable = mv88e6185_g1_ppu_disable,
.reset = mv88e6185_g1_reset,
 };
 
@@ -3241,6 +3193,8 @@ static const struct mv88e6xxx_ops mv88e6095_ops = {
.stats_get_strings = mv88e6095_stats_get_strings,
.stats_get_stats = mv88e6095_stats_get_stats,
.mgmt_rsvd2cpu = mv88e6095_g2_mgmt_rsvd2cpu,
+   .ppu_enable = mv88e6185_g1_ppu_enable,
+   .ppu_disable = mv88e6185_g1_ppu_disable,
.reset = mv88e6185_g1_reset,
 };
 
@@ -3311,6 +3265,8 @@ static const struct mv88e6xxx_ops mv88e6131_ops = {
.g1_set_cpu_port = mv88e6095_g1_set_cpu_port,
.g1_set_egress_port = mv88e6095_g1_set_egress_port,
.mgmt_rsvd2cpu = mv88e6095_g2_mgmt_rsvd2cpu,
+   .ppu_enable = mv88e6185_g1_ppu_enable,
+   .ppu_disable = mv88e6185_g1_ppu_disable,
.reset = mv88e6185_g1_reset,
 };
 
@@ -3483,6 +3439,8 @@ static const struct mv88e6xxx_ops mv88e6185_ops = {
.g1_set_cpu_port = mv88e6095_g1_set_cpu_port,
.g1_set_egress_port = mv88e6095_g1_set_egress_port,
.mgmt_rsvd2cpu = mv88e6095_g2_mgmt_rsvd2cpu,
+   .ppu_enable = 

[PATCH v3 net-next v3 0/4] net: dsa: mv88e6xxx: rework reset and PPU code

[Vivien Didelot]

Old Marvell chips (like 88E6060) don't have a PHY Polling Unit (PPU).

Next chips (like 88E6185) have a PPU, which has exclusive access to the
PHY registers, thus must be disabled before access.

Newer chips (like 88E6352) have an indirect mechanism to access the PHY
registers whenever, thus loose control over the PPU (always enabled).

Here's a summary:

Model | PPU? | Has PPU ctrl?  | PPU state readable? | PHY access
- |  | -- | --- | --
 6060 | no   | no | no  | direct
 6185 | yes  | yes, PPUEn bit | yes, PPUState 2-bit | direct w/ PPU dis.
 6352 | yes  | no | yes, PPUState 1-bit | indirect
 6390 | yes  | no | yes, InitState bit  | indirect

Depending on the PPU control, a switch may have to restart the PPU when
resetting the switch. Once the switch is reset, we must wait for the PPU
state to be active polling again before accessing the registers.

For that purpose, add new operations to the chips to enable/disable the
PPU, and execute software reset. With these new ops in place, rework the
switch reset code and finally get rid of the MV88E6XXX_FLAG_PPU* flags.

Changes in v3:
  - consider 6097 as 6352 (no PPU ops and use mv88e6352_g1_reset).

Changes in v2:
  - wait in ppu/reset ops so that ppu_polling is not needed anymore.

Vivien Didelot (4):
  net: dsa: mv88e6xxx: add helper to disable ports
  net: dsa: mv88e6xxx: add helper to hardware reset
  net: dsa: mv88e6xxx: add a soft reset operation
  net: dsa: mv88e6xxx: add PPU operations

 drivers/net/dsa/mv88e6xxx/chip.c  | 176 +++--
 drivers/net/dsa/mv88e6xxx/global1.c   | 178 ++
 drivers/net/dsa/mv88e6xxx/global1.h   |   7 ++
 drivers/net/dsa/mv88e6xxx/mv88e6xxx.h |  34 +++
 4 files changed, 276 insertions(+), 119 deletions(-)

-- 
2.10.2

[PATCH v3 net-next v3 2/4] net: dsa: mv88e6xxx: add helper to hardware reset

[Vivien Didelot]

Add an helper to toggle the eventual GPIO connected to the reset pin.

Signed-off-by: Vivien Didelot 
Reviewed-by: Andrew Lunn 
---
 drivers/net/dsa/mv88e6xxx/chip.c | 22 ++
 1 file changed, 14 insertions(+), 8 deletions(-)

diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index 1d4d3be..27dfb5d 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -2356,6 +2356,19 @@ static void mv88e6xxx_port_bridge_leave(struct 
dsa_switch *ds, int port)
mutex_unlock(>reg_lock);
 }
 
+static void mv88e6xxx_hardware_reset(struct mv88e6xxx_chip *chip)
+{
+   struct gpio_desc *gpiod = chip->reset;
+
+   /* If there is a GPIO connected to the reset pin, toggle it */
+   if (gpiod) {
+   gpiod_set_value_cansleep(gpiod, 1);
+   usleep_range(1, 2);
+   gpiod_set_value_cansleep(gpiod, 0);
+   usleep_range(1, 2);
+   }
+}
+
 static int mv88e6xxx_disable_ports(struct mv88e6xxx_chip *chip)
 {
int i, err;
@@ -2380,7 +2393,6 @@ static int mv88e6xxx_switch_reset(struct mv88e6xxx_chip 
*chip)
 {
bool ppu_active = mv88e6xxx_has(chip, MV88E6XXX_FLAG_PPU_ACTIVE);
u16 is_reset = (ppu_active ? 0x8800 : 0xc800);
-   struct gpio_desc *gpiod = chip->reset;
unsigned long timeout;
u16 reg;
int err;
@@ -2389,13 +2401,7 @@ static int mv88e6xxx_switch_reset(struct mv88e6xxx_chip 
*chip)
if (err)
return err;
 
-   /* If there is a gpio connected to the reset pin, toggle it */
-   if (gpiod) {
-   gpiod_set_value_cansleep(gpiod, 1);
-   usleep_range(1, 2);
-   gpiod_set_value_cansleep(gpiod, 0);
-   usleep_range(1, 2);
-   }
+   mv88e6xxx_hardware_reset(chip);
 
/* Reset the switch. Keep the PPU active if requested. The PPU
 * needs to be active to support indirect phy register access
-- 
2.10.2

[PATCH v3 net-next v3 4/4] net: dsa: mv88e6xxx: add PPU operations

[Vivien Didelot]

Some Marvell chips can enable/disable the PPU on demand. This is needed
to access the PHY registers when there is no indirection mechanism.

Add two new ppu_enable and ppu_disable ops to describe this and finally
get rid of the MV88E6XXX_FLAG_PPU* flags.

Signed-off-by: Vivien Didelot 
---
 drivers/net/dsa/mv88e6xxx/chip.c  | 76 ---
 drivers/net/dsa/mv88e6xxx/global1.c   | 57 ++
 drivers/net/dsa/mv88e6xxx/global1.h   |  3 ++
 drivers/net/dsa/mv88e6xxx/mv88e6xxx.h | 19 ++---
 4 files changed, 81 insertions(+), 74 deletions(-)

diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index 5aae5d7..731d262 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -527,58 +527,18 @@ int mv88e6xxx_update(struct mv88e6xxx_chip *chip, int 
addr, int reg, u16 update)
 
 static int mv88e6xxx_ppu_disable(struct mv88e6xxx_chip *chip)
 {
-   u16 val;
-   int i, err;
+   if (!chip->info->ops->ppu_disable)
+   return 0;
 
-   err = mv88e6xxx_g1_read(chip, GLOBAL_CONTROL, );
-   if (err)
-   return err;
-
-   err = mv88e6xxx_g1_write(chip, GLOBAL_CONTROL,
-val & ~GLOBAL_CONTROL_PPU_ENABLE);
-   if (err)
-   return err;
-
-   for (i = 0; i < 16; i++) {
-   err = mv88e6xxx_g1_read(chip, GLOBAL_STATUS, );
-   if (err)
-   return err;
-
-   usleep_range(1000, 2000);
-   val &= GLOBAL_STATUS_PPU_STATE_MASK;
-   if (val != GLOBAL_STATUS_PPU_STATE_POLLING)
-   return 0;
-   }
-
-   return -ETIMEDOUT;
+   return chip->info->ops->ppu_disable(chip);
 }
 
 static int mv88e6xxx_ppu_enable(struct mv88e6xxx_chip *chip)
 {
-   u16 val;
-   int i, err;
+   if (!chip->info->ops->ppu_enable)
+   return 0;
 
-   err = mv88e6xxx_g1_read(chip, GLOBAL_CONTROL, );
-   if (err)
-   return err;
-
-   err = mv88e6xxx_g1_write(chip, GLOBAL_CONTROL,
-val | GLOBAL_CONTROL_PPU_ENABLE);
-   if (err)
-   return err;
-
-   for (i = 0; i < 16; i++) {
-   err = mv88e6xxx_g1_read(chip, GLOBAL_STATUS, );
-   if (err)
-   return err;
-
-   usleep_range(1000, 2000);
-   val &= GLOBAL_STATUS_PPU_STATE_MASK;
-   if (val == GLOBAL_STATUS_PPU_STATE_POLLING)
-   return 0;
-   }
-
-   return -ETIMEDOUT;
+   return chip->info->ops->ppu_enable(chip);
 }
 
 static void mv88e6xxx_ppu_reenable_work(struct work_struct *ugly)
@@ -2746,22 +2706,12 @@ static int mv88e6xxx_g1_setup(struct mv88e6xxx_chip 
*chip)
 {
struct dsa_switch *ds = chip->ds;
u32 upstream_port = dsa_upstream_port(ds);
-   u16 reg;
int err;
 
/* Enable the PHY Polling Unit if present, don't discard any packets,
 * and mask all interrupt sources.
 */
-   err = mv88e6xxx_g1_read(chip, GLOBAL_CONTROL, );
-   if (err < 0)
-   return err;
-
-   reg &= ~GLOBAL_CONTROL_PPU_ENABLE;
-   if (mv88e6xxx_has(chip, MV88E6XXX_FLAG_PPU) ||
-   mv88e6xxx_has(chip, MV88E6XXX_FLAG_PPU_ACTIVE))
-   reg |= GLOBAL_CONTROL_PPU_ENABLE;
-
-   err = mv88e6xxx_g1_write(chip, GLOBAL_CONTROL, reg);
+   err = mv88e6xxx_ppu_enable(chip);
if (err)
return err;
 
@@ -3223,6 +3173,8 @@ static const struct mv88e6xxx_ops mv88e6085_ops = {
.g1_set_cpu_port = mv88e6095_g1_set_cpu_port,
.g1_set_egress_port = mv88e6095_g1_set_egress_port,
.mgmt_rsvd2cpu = mv88e6095_g2_mgmt_rsvd2cpu,
+   .ppu_enable = mv88e6185_g1_ppu_enable,
+   .ppu_disable = mv88e6185_g1_ppu_disable,
.reset = mv88e6185_g1_reset,
 };
 
@@ -3241,6 +3193,8 @@ static const struct mv88e6xxx_ops mv88e6095_ops = {
.stats_get_strings = mv88e6095_stats_get_strings,
.stats_get_stats = mv88e6095_stats_get_stats,
.mgmt_rsvd2cpu = mv88e6095_g2_mgmt_rsvd2cpu,
+   .ppu_enable = mv88e6185_g1_ppu_enable,
+   .ppu_disable = mv88e6185_g1_ppu_disable,
.reset = mv88e6185_g1_reset,
 };
 
@@ -3311,6 +3265,8 @@ static const struct mv88e6xxx_ops mv88e6131_ops = {
.g1_set_cpu_port = mv88e6095_g1_set_cpu_port,
.g1_set_egress_port = mv88e6095_g1_set_egress_port,
.mgmt_rsvd2cpu = mv88e6095_g2_mgmt_rsvd2cpu,
+   .ppu_enable = mv88e6185_g1_ppu_enable,
+   .ppu_disable = mv88e6185_g1_ppu_disable,
.reset = mv88e6185_g1_reset,
 };
 
@@ -3483,6 +3439,8 @@ static const struct mv88e6xxx_ops mv88e6185_ops = {
.g1_set_cpu_port = mv88e6095_g1_set_cpu_port,
.g1_set_egress_port = mv88e6095_g1_set_egress_port,
.mgmt_rsvd2cpu = mv88e6095_g2_mgmt_rsvd2cpu,
+   .ppu_enable = mv88e6185_g1_ppu_enable,
+   

[PATCH v3 net-next v3 0/4] net: dsa: mv88e6xxx: rework reset and PPU code

[Vivien Didelot]

Old Marvell chips (like 88E6060) don't have a PHY Polling Unit (PPU).

Next chips (like 88E6185) have a PPU, which has exclusive access to the
PHY registers, thus must be disabled before access.

Newer chips (like 88E6352) have an indirect mechanism to access the PHY
registers whenever, thus loose control over the PPU (always enabled).

Here's a summary:

Model | PPU? | Has PPU ctrl?  | PPU state readable? | PHY access
- |  | -- | --- | --
 6060 | no   | no | no  | direct
 6185 | yes  | yes, PPUEn bit | yes, PPUState 2-bit | direct w/ PPU dis.
 6352 | yes  | no | yes, PPUState 1-bit | indirect
 6390 | yes  | no | yes, InitState bit  | indirect

Depending on the PPU control, a switch may have to restart the PPU when
resetting the switch. Once the switch is reset, we must wait for the PPU
state to be active polling again before accessing the registers.

For that purpose, add new operations to the chips to enable/disable the
PPU, and execute software reset. With these new ops in place, rework the
switch reset code and finally get rid of the MV88E6XXX_FLAG_PPU* flags.

Changes in v3:
  - consider 6097 as 6352 (no PPU ops and use mv88e6352_g1_reset).

Changes in v2:
  - wait in ppu/reset ops so that ppu_polling is not needed anymore.

Vivien Didelot (4):
  net: dsa: mv88e6xxx: add helper to disable ports
  net: dsa: mv88e6xxx: add helper to hardware reset
  net: dsa: mv88e6xxx: add a soft reset operation
  net: dsa: mv88e6xxx: add PPU operations

 drivers/net/dsa/mv88e6xxx/chip.c  | 176 +++--
 drivers/net/dsa/mv88e6xxx/global1.c   | 178 ++
 drivers/net/dsa/mv88e6xxx/global1.h   |   7 ++
 drivers/net/dsa/mv88e6xxx/mv88e6xxx.h |  34 +++
 4 files changed, 276 insertions(+), 119 deletions(-)

-- 
2.10.2

[PATCH v3 net-next v3 1/4] net: dsa: mv88e6xxx: add helper to disable ports

[Vivien Didelot]

Before resetting a switch, the ports should be set to the Disabled state
and the transmit queues should be drained.

Add an helper to explicit that.

Signed-off-by: Vivien Didelot 
Reviewed-by: Andrew Lunn 
---
 drivers/net/dsa/mv88e6xxx/chip.c | 34 +++---
 1 file changed, 23 insertions(+), 11 deletions(-)

diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index ca453f3..1d4d3be 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -2356,6 +2356,26 @@ static void mv88e6xxx_port_bridge_leave(struct 
dsa_switch *ds, int port)
mutex_unlock(>reg_lock);
 }
 
+static int mv88e6xxx_disable_ports(struct mv88e6xxx_chip *chip)
+{
+   int i, err;
+
+   /* Set all ports to the Disabled state */
+   for (i = 0; i < mv88e6xxx_num_ports(chip); i++) {
+   err = mv88e6xxx_port_set_state(chip, i,
+  PORT_CONTROL_STATE_DISABLED);
+   if (err)
+   return err;
+   }
+
+   /* Wait for transmit queues to drain,
+* i.e. 2ms for a maximum frame to be transmitted at 10 Mbps.
+*/
+   usleep_range(2000, 4000);
+
+   return 0;
+}
+
 static int mv88e6xxx_switch_reset(struct mv88e6xxx_chip *chip)
 {
bool ppu_active = mv88e6xxx_has(chip, MV88E6XXX_FLAG_PPU_ACTIVE);
@@ -2364,18 +2384,10 @@ static int mv88e6xxx_switch_reset(struct mv88e6xxx_chip 
*chip)
unsigned long timeout;
u16 reg;
int err;
-   int i;
 
-   /* Set all ports to the disabled state. */
-   for (i = 0; i < mv88e6xxx_num_ports(chip); i++) {
-   err = mv88e6xxx_port_set_state(chip, i,
-  PORT_CONTROL_STATE_DISABLED);
-   if (err)
-   return err;
-   }
-
-   /* Wait for transmit queues to drain. */
-   usleep_range(2000, 4000);
+   err = mv88e6xxx_disable_ports(chip);
+   if (err)
+   return err;
 
/* If there is a gpio connected to the reset pin, toggle it */
if (gpiod) {
-- 
2.10.2

[PATCH v3 net-next v3 1/4] net: dsa: mv88e6xxx: add helper to disable ports

[Vivien Didelot]

Before resetting a switch, the ports should be set to the Disabled state
and the transmit queues should be drained.

Add an helper to explicit that.

Signed-off-by: Vivien Didelot 
Reviewed-by: Andrew Lunn 
---
 drivers/net/dsa/mv88e6xxx/chip.c | 34 +++---
 1 file changed, 23 insertions(+), 11 deletions(-)

diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index ca453f3..1d4d3be 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -2356,6 +2356,26 @@ static void mv88e6xxx_port_bridge_leave(struct 
dsa_switch *ds, int port)
mutex_unlock(>reg_lock);
 }
 
+static int mv88e6xxx_disable_ports(struct mv88e6xxx_chip *chip)
+{
+   int i, err;
+
+   /* Set all ports to the Disabled state */
+   for (i = 0; i < mv88e6xxx_num_ports(chip); i++) {
+   err = mv88e6xxx_port_set_state(chip, i,
+  PORT_CONTROL_STATE_DISABLED);
+   if (err)
+   return err;
+   }
+
+   /* Wait for transmit queues to drain,
+* i.e. 2ms for a maximum frame to be transmitted at 10 Mbps.
+*/
+   usleep_range(2000, 4000);
+
+   return 0;
+}
+
 static int mv88e6xxx_switch_reset(struct mv88e6xxx_chip *chip)
 {
bool ppu_active = mv88e6xxx_has(chip, MV88E6XXX_FLAG_PPU_ACTIVE);
@@ -2364,18 +2384,10 @@ static int mv88e6xxx_switch_reset(struct mv88e6xxx_chip 
*chip)
unsigned long timeout;
u16 reg;
int err;
-   int i;
 
-   /* Set all ports to the disabled state. */
-   for (i = 0; i < mv88e6xxx_num_ports(chip); i++) {
-   err = mv88e6xxx_port_set_state(chip, i,
-  PORT_CONTROL_STATE_DISABLED);
-   if (err)
-   return err;
-   }
-
-   /* Wait for transmit queues to drain. */
-   usleep_range(2000, 4000);
+   err = mv88e6xxx_disable_ports(chip);
+   if (err)
+   return err;
 
/* If there is a gpio connected to the reset pin, toggle it */
if (gpiod) {
-- 
2.10.2

Re: [PATCH 39/39] mtd: nand: denali_dt: add compatible strings for UniPhier SoC variants

[Dinh Nguyen]

On 12/05/2016 03:29 PM, Marek Vasut wrote:
> On 12/05/2016 09:51 PM, Dinh Nguyen wrote:
>> On Sun, Dec 4, 2016 at 10:22 PM, Marek Vasut  wrote:
>>> On 12/05/2016 05:10 AM, Masahiro Yamada wrote:
 Hi Marek,


 2016-12-05 12:44 GMT+09:00 Marek Vasut :
> On 12/05/2016 04:30 AM, Masahiro Yamada wrote:
>> Hi Dinh,
>>
>>
>> 2016-12-04 7:08 GMT+09:00 Dinh Nguyen :
>>> Hi,
>>>
>>> On Fri, Dec 2, 2016 at 8:49 PM, Marek Vasut  
>>> wrote:
 On 12/03/2016 03:41 AM, Masahiro Yamada wrote:
> Hi Rob,

 Hi!

> 2016-12-03 1:26 GMT+09:00 Rob Herring :
>
>>>
>>>
>>> (Plan A)
>>>   "denali,socfpga-nand"   (for Altera SOCFPGA variant)
>>>   "denali,uniphier-nand-v1"   (for old Socionext UniPhier 
>>> family variant)
>>>   "denali,uniphier-nand-v2"   (for new Socionext UniPhier 
>>> family variant)
>>>
>>> (Plan B)
>>>   "altera,denali-nand"(for Altera SOCFPGA variant)
>>>   "socionext,denali-nand-v5a" (for old Socionext UniPhier 
>>> family variant)
>>>   "socionext,denali-nand-v5b" (for new Socionext UniPhier 
>>> family variant)
>
>> Let the Altera folks worry about their stuff. At least for soft IP in
>> FPGA, it's a bit of a special case. The old string can remain as bad
>> as it is.
>
>
> Hmm, I am not sure if this IP would fit in FPGA
> (to use it along with NIOS-II?)
>
> (even if it happened, nothing of this IP would be customizable on 
> users' side.
> When buying the IP, SoC vendors submit a list of desired features.
> Denali (now Cadence) generates the RTL according to the configuration 
> sheet.
> The function is fixed at this point. So, generic compatible would be
> useless anyway.)
>
>
> If we are talking about SOCFPGA,
> SOCFPGA is not only FPGA. Rather "SOC" + "FPGA".
> It consists of two parts:
> [1] SOC part  (Cortex-A9 + various hard-wired peripherals such UART,
> USB, SD, NAND, ...)
> [2] FPGA part (User design logic)
>
> The Denali NAND controller is included in [1].
> So, as far as we talk about the Denali on SOCFPGA,
> it is as hard-wired as Intel, Socionext's ones.

 That's correct, the Denali NAND IP in altera socfpga is a hardware
 block. You can make it available to the fabric too, but by default
 it's used by the ARM part of the chip, so for this discussion, you
 can forget that the FPGA part exists altogether.

 I would be in favor of plan B, since it seems to be the more often
 taken approach. A nice example is ci-hdrc:

 $ git grep compatible drivers/usb/chipidea/

>> I simply would do "socionext,uniphier-v5b-nand" (and v5a).
>> The fact that it is denali is part of the documentation.
>>
>
> Let me think about this.
>
> Socionext bought two version of Denali IP,
> and we are now re-using the newer one (v5b) for several SoCs.
> Socionext has some more product lines other than Uniphier SoC family,
> perhaps wider re-use might happen in the future.
>
> At first, I included "uniphier" in compatible, but I am still 
> wondering
> if such a specific string is good or not.
>
> Also, comments from Altera engineers are appreciated.
>>>
>>> Sorry, it's taken me a while to add comments. My altera email is very 
>>> spotty now
>>> that the Intel merge is completed. Please use dingu...@kernel.org for 
>>> any future
>>> communications.
>>>
>>> Yes, everything that is said so far for the NAND controller on the
>>> SoCFPGA is correct. I added the binding for the controller a while
>>> back, but unfortunately, we never added the NAND interface to the
>>> devkit, so we did not do much in terms of enabling it.
>>>
>>> I think the only SoCFPGA board I know that has the NAND interface 
>>> active is
>>> the TRCom board, but I have never seen that board.
>>>
>>> I don't have any strong opinions on this matter, just as long as the
>>> original binding
>>> "denali,denali-nand-dt" is kept, and I think Rob was ok with keeping
>>> that binding.
>>>
>>
>> I am proposing to add "altera,denali-nand" for Altera.
>> For what, do you need the generic compatible?
>> This IP has no default for it to fallback to.
>
> IMO just for compatibility reasons with old DTs .

 We generally contribute for
 a "working driver" 

Re: [PATCH 39/39] mtd: nand: denali_dt: add compatible strings for UniPhier SoC variants

[Dinh Nguyen]

On 12/05/2016 03:29 PM, Marek Vasut wrote:
> On 12/05/2016 09:51 PM, Dinh Nguyen wrote:
>> On Sun, Dec 4, 2016 at 10:22 PM, Marek Vasut  wrote:
>>> On 12/05/2016 05:10 AM, Masahiro Yamada wrote:
 Hi Marek,


 2016-12-05 12:44 GMT+09:00 Marek Vasut :
> On 12/05/2016 04:30 AM, Masahiro Yamada wrote:
>> Hi Dinh,
>>
>>
>> 2016-12-04 7:08 GMT+09:00 Dinh Nguyen :
>>> Hi,
>>>
>>> On Fri, Dec 2, 2016 at 8:49 PM, Marek Vasut  
>>> wrote:
 On 12/03/2016 03:41 AM, Masahiro Yamada wrote:
> Hi Rob,

 Hi!

> 2016-12-03 1:26 GMT+09:00 Rob Herring :
>
>>>
>>>
>>> (Plan A)
>>>   "denali,socfpga-nand"   (for Altera SOCFPGA variant)
>>>   "denali,uniphier-nand-v1"   (for old Socionext UniPhier 
>>> family variant)
>>>   "denali,uniphier-nand-v2"   (for new Socionext UniPhier 
>>> family variant)
>>>
>>> (Plan B)
>>>   "altera,denali-nand"(for Altera SOCFPGA variant)
>>>   "socionext,denali-nand-v5a" (for old Socionext UniPhier 
>>> family variant)
>>>   "socionext,denali-nand-v5b" (for new Socionext UniPhier 
>>> family variant)
>
>> Let the Altera folks worry about their stuff. At least for soft IP in
>> FPGA, it's a bit of a special case. The old string can remain as bad
>> as it is.
>
>
> Hmm, I am not sure if this IP would fit in FPGA
> (to use it along with NIOS-II?)
>
> (even if it happened, nothing of this IP would be customizable on 
> users' side.
> When buying the IP, SoC vendors submit a list of desired features.
> Denali (now Cadence) generates the RTL according to the configuration 
> sheet.
> The function is fixed at this point. So, generic compatible would be
> useless anyway.)
>
>
> If we are talking about SOCFPGA,
> SOCFPGA is not only FPGA. Rather "SOC" + "FPGA".
> It consists of two parts:
> [1] SOC part  (Cortex-A9 + various hard-wired peripherals such UART,
> USB, SD, NAND, ...)
> [2] FPGA part (User design logic)
>
> The Denali NAND controller is included in [1].
> So, as far as we talk about the Denali on SOCFPGA,
> it is as hard-wired as Intel, Socionext's ones.

 That's correct, the Denali NAND IP in altera socfpga is a hardware
 block. You can make it available to the fabric too, but by default
 it's used by the ARM part of the chip, so for this discussion, you
 can forget that the FPGA part exists altogether.

 I would be in favor of plan B, since it seems to be the more often
 taken approach. A nice example is ci-hdrc:

 $ git grep compatible drivers/usb/chipidea/

>> I simply would do "socionext,uniphier-v5b-nand" (and v5a).
>> The fact that it is denali is part of the documentation.
>>
>
> Let me think about this.
>
> Socionext bought two version of Denali IP,
> and we are now re-using the newer one (v5b) for several SoCs.
> Socionext has some more product lines other than Uniphier SoC family,
> perhaps wider re-use might happen in the future.
>
> At first, I included "uniphier" in compatible, but I am still 
> wondering
> if such a specific string is good or not.
>
> Also, comments from Altera engineers are appreciated.
>>>
>>> Sorry, it's taken me a while to add comments. My altera email is very 
>>> spotty now
>>> that the Intel merge is completed. Please use dingu...@kernel.org for 
>>> any future
>>> communications.
>>>
>>> Yes, everything that is said so far for the NAND controller on the
>>> SoCFPGA is correct. I added the binding for the controller a while
>>> back, but unfortunately, we never added the NAND interface to the
>>> devkit, so we did not do much in terms of enabling it.
>>>
>>> I think the only SoCFPGA board I know that has the NAND interface 
>>> active is
>>> the TRCom board, but I have never seen that board.
>>>
>>> I don't have any strong opinions on this matter, just as long as the
>>> original binding
>>> "denali,denali-nand-dt" is kept, and I think Rob was ok with keeping
>>> that binding.
>>>
>>
>> I am proposing to add "altera,denali-nand" for Altera.
>> For what, do you need the generic compatible?
>> This IP has no default for it to fallback to.
>
> IMO just for compatibility reasons with old DTs .

 We generally contribute for
 a "working driver" (at least, should be functional to some extent)
 and "DT binding" bundled together.

 However, 

Re: [PATCH 1/2 v2] scsi: be2iscsi: set errno on error path

[Martin K. Petersen]

> "Pan" == Pan Bian  writes:

Pan> Variable ret is reset in the loop, and its value will be 0 during
Pan> the after repeat of the loop. Then, if pci_alloc_consistent()
Pan> returns NULL, the return value is 0. 0 means no error, which may
Pan> make it impossible for the callers of beiscsi_create_cqs() to
Pan> detect the memory allocation error. This patch fixes the bug,
Pan> assigning "-ENOMEM" to ret on the path that the call to
Pan> pci_alloc_consistent() fails.

What are the differences between v1 and v2 for these patches? I see no
changelog...

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH 1/4] rtc: mcp795: fix invalid month setting.

[Emil Bartczak]

On Mon, Dec 05, 2016 at 11:15:59PM +0100, Alexandre Belloni wrote:
> On 05/12/2016 at 23:03:52 +0100, Emil Bartczak wrote :
> > > 
> > > >  #define MCP795_WRITE   0x12
> > > >  #define MCP795_UNLOCK  0x14
> > > >  #define MCP795_IDWRITE 0x32
> > > > @@ -39,6 +39,7 @@
> > > >  
> > > >  #define MCP795_ST_BIT  0x80
> > > >  #define MCP795_24_BIT  0x40
> > > > +#define MCP795_LP_BIT  0x20
> > > >  
> > > >  static int mcp795_rtcc_read(struct device *dev, u8 addr, u8 *buf, u8 
> > > > count)
> > > >  {
> > > > @@ -108,7 +109,8 @@ static int mcp795_set_time(struct device *dev, 
> > > > struct rtc_time *tim)
> > > > data[1] = (data[1] & 0x80) | ((tim->tm_min / 10) << 4) | 
> > > > (tim->tm_min % 10);
> > > > data[2] = ((tim->tm_hour / 10) << 4) | (tim->tm_hour % 10);
> > > > data[4] = ((tim->tm_mday / 10) << 4) | ((tim->tm_mday) % 10);
> > > > -   data[5] = (data[5] & 0x10) | (tim->tm_mon / 10) | (tim->tm_mon 
> > > > % 10);
> > > > +   data[5] = (data[5] & MCP795_LP_BIT) |
> > > 
> > > You changed 0x10 in MCP795_LP_BIT which you defined as 0x20, is that
> > > right?
> > Yes, it should be 0x20 (checked in datasheet).
> > 
> > > 
> > > This is also an unrelated change.
> > > 
> > > > +   ((tim->tm_mon / 10) << 4) | (tim->tm_mon % 10);
> > What do you mean exactly? 
> > That above line of code was moved to the new line? Or that I added
> > shift left operation (tim->tm_mon / 10) << 4)?
> > Changing 0x10 to 0x20 and adding shift right operation fixes the problem.
> > 
> 
> I meant that I feel like changing 0x10 to 0x20 is a separate bugfix from
> adding the shift. At least mention that in the commit message.
Ok, I will improve commit message.

> 
> > > >  
> > > > if (tim->tm_year > 100)
> > > > tim->tm_year -= 100;
> > > > @@ -137,11 +139,11 @@ static int mcp795_read_time(struct device *dev, 
> > > > struct rtc_time *tim)
> > > > if (ret)
> > > > return ret;
> > > >  
> > > > -   tim->tm_sec = ((data[0] & 0x70) >> 4) * 10 + 
> > > > (data[0] & 0x0f);
> > > > -   tim->tm_min = ((data[1] & 0x70) >> 4) * 10 + 
> > > > (data[1] & 0x0f);
> > > > +   tim->tm_sec = ((data[0] & 0x70) >> 4) * 10 + (data[0] & 
> > > > 0x0f);
> > > > +   tim->tm_min = ((data[1] & 0x70) >> 4) * 10 + (data[1] & 
> > > > 0x0f);
> > > > tim->tm_hour= ((data[2] & 0x30) >> 4) * 10 + (data[2] & 
> > > > 0x0f);
> > > > tim->tm_mday= ((data[4] & 0x30) >> 4) * 10 + (data[4] & 
> > > > 0x0f);
> > > > -   tim->tm_mon = ((data[5] & 0x10) >> 4) * 10 + 
> > > > (data[5] & 0x0f);
> > > > +   tim->tm_mon = ((data[5] & 0x10) >> 4) * 10 + (data[5] & 
> > > > 0x0f);
> > > 
> > > All those whitespace changes are actually confusing. Please do them in a
> > > separate patch or in your last patch.
> > Ok, I will have a separate patch for them.
> 
> Maybe switching to bcd2bin/bin2bcd first is better as it touches all
> those lines anyway and also solves the shift in mcp795_rtcc_read()
Yes, this is a good idea. I will prepare a new patchset where first patch will 
provide 
switching to bcd2bin/bin2bcd.

> 
> 
> -- 
> Alexandre Belloni, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com

Emil,

Re: [PATCH 1/2 v2] scsi: be2iscsi: set errno on error path

[Martin K. Petersen]

> "Pan" == Pan Bian  writes:

Pan> Variable ret is reset in the loop, and its value will be 0 during
Pan> the after repeat of the loop. Then, if pci_alloc_consistent()
Pan> returns NULL, the return value is 0. 0 means no error, which may
Pan> make it impossible for the callers of beiscsi_create_cqs() to
Pan> detect the memory allocation error. This patch fixes the bug,
Pan> assigning "-ENOMEM" to ret on the path that the call to
Pan> pci_alloc_consistent() fails.

What are the differences between v1 and v2 for these patches? I see no
changelog...

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH 1/4] rtc: mcp795: fix invalid month setting.

[Emil Bartczak]

On Mon, Dec 05, 2016 at 11:15:59PM +0100, Alexandre Belloni wrote:
> On 05/12/2016 at 23:03:52 +0100, Emil Bartczak wrote :
> > > 
> > > >  #define MCP795_WRITE   0x12
> > > >  #define MCP795_UNLOCK  0x14
> > > >  #define MCP795_IDWRITE 0x32
> > > > @@ -39,6 +39,7 @@
> > > >  
> > > >  #define MCP795_ST_BIT  0x80
> > > >  #define MCP795_24_BIT  0x40
> > > > +#define MCP795_LP_BIT  0x20
> > > >  
> > > >  static int mcp795_rtcc_read(struct device *dev, u8 addr, u8 *buf, u8 
> > > > count)
> > > >  {
> > > > @@ -108,7 +109,8 @@ static int mcp795_set_time(struct device *dev, 
> > > > struct rtc_time *tim)
> > > > data[1] = (data[1] & 0x80) | ((tim->tm_min / 10) << 4) | 
> > > > (tim->tm_min % 10);
> > > > data[2] = ((tim->tm_hour / 10) << 4) | (tim->tm_hour % 10);
> > > > data[4] = ((tim->tm_mday / 10) << 4) | ((tim->tm_mday) % 10);
> > > > -   data[5] = (data[5] & 0x10) | (tim->tm_mon / 10) | (tim->tm_mon 
> > > > % 10);
> > > > +   data[5] = (data[5] & MCP795_LP_BIT) |
> > > 
> > > You changed 0x10 in MCP795_LP_BIT which you defined as 0x20, is that
> > > right?
> > Yes, it should be 0x20 (checked in datasheet).
> > 
> > > 
> > > This is also an unrelated change.
> > > 
> > > > +   ((tim->tm_mon / 10) << 4) | (tim->tm_mon % 10);
> > What do you mean exactly? 
> > That above line of code was moved to the new line? Or that I added
> > shift left operation (tim->tm_mon / 10) << 4)?
> > Changing 0x10 to 0x20 and adding shift right operation fixes the problem.
> > 
> 
> I meant that I feel like changing 0x10 to 0x20 is a separate bugfix from
> adding the shift. At least mention that in the commit message.
Ok, I will improve commit message.

> 
> > > >  
> > > > if (tim->tm_year > 100)
> > > > tim->tm_year -= 100;
> > > > @@ -137,11 +139,11 @@ static int mcp795_read_time(struct device *dev, 
> > > > struct rtc_time *tim)
> > > > if (ret)
> > > > return ret;
> > > >  
> > > > -   tim->tm_sec = ((data[0] & 0x70) >> 4) * 10 + 
> > > > (data[0] & 0x0f);
> > > > -   tim->tm_min = ((data[1] & 0x70) >> 4) * 10 + 
> > > > (data[1] & 0x0f);
> > > > +   tim->tm_sec = ((data[0] & 0x70) >> 4) * 10 + (data[0] & 
> > > > 0x0f);
> > > > +   tim->tm_min = ((data[1] & 0x70) >> 4) * 10 + (data[1] & 
> > > > 0x0f);
> > > > tim->tm_hour= ((data[2] & 0x30) >> 4) * 10 + (data[2] & 
> > > > 0x0f);
> > > > tim->tm_mday= ((data[4] & 0x30) >> 4) * 10 + (data[4] & 
> > > > 0x0f);
> > > > -   tim->tm_mon = ((data[5] & 0x10) >> 4) * 10 + 
> > > > (data[5] & 0x0f);
> > > > +   tim->tm_mon = ((data[5] & 0x10) >> 4) * 10 + (data[5] & 
> > > > 0x0f);
> > > 
> > > All those whitespace changes are actually confusing. Please do them in a
> > > separate patch or in your last patch.
> > Ok, I will have a separate patch for them.
> 
> Maybe switching to bcd2bin/bin2bcd first is better as it touches all
> those lines anyway and also solves the shift in mcp795_rtcc_read()
Yes, this is a good idea. I will prepare a new patchset where first patch will 
provide 
switching to bcd2bin/bin2bcd.

> 
> 
> -- 
> Alexandre Belloni, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com

Emil,

Re: [RFC v3 1/6] Track the active utilisation

[luca abeni]

Hi Peter,

On Fri, 18 Nov 2016 15:23:59 +0100
Peter Zijlstra  wrote:
[...]
>   u64 running_bw;
> 
> static void add_running_bw(struct sched_dl_entity *dl_se, struct
> dl_rq *dl_rq) {
>   u64 old = dl_rq->running_bw;
> 
>   dl_rq->running_bw += dl_se->dl_bw;
>   SCHED_WARN_ON(dl_rq->running_bw < old); /* overflow */
> }
> 
> static void sub_running_bw(struct sched_dl_entity *dl_se, struct
> dl_rq *dl_rq) {
>   u64 old = dl_rq->running_bw;
> 
>   dl_rq->running_bw -= dl_se->dl_bw;
>   SCHED_WARN_ON(dl_rq->running_bw > old); /* underflow */
> }

I wanted to change "SCHED_WARN_ON(dl_rq->running_bw > old); /*
underflow */" into "if (SCHED_WARN_ON(...)) dl_rq->running_bw = 0" (to
avoid using nonsensical "running_bw" values), but I see that
"SCHED_WARN_ON()" cannot be used inside an if (this seems to be a
difference respect to "SCHED_WARN()").
This is because of the definition used when CONFIG_SCHED_DEBUG is not
defined (I noticed the issue when testing with random kernel
configurations).

Is this expected? If yes, what should I do in this case? Something like
SCHED_WARN_ON(dl_rq->running_bw > old); /* underflow */
if (dl_rq->running_bw > old)
dl_rq->running_bw = 0;
?
Or something else?


Thanks,
Luca

Re: [RFC v3 1/6] Track the active utilisation

[luca abeni]

Hi Peter,

On Fri, 18 Nov 2016 15:23:59 +0100
Peter Zijlstra  wrote:
[...]
>   u64 running_bw;
> 
> static void add_running_bw(struct sched_dl_entity *dl_se, struct
> dl_rq *dl_rq) {
>   u64 old = dl_rq->running_bw;
> 
>   dl_rq->running_bw += dl_se->dl_bw;
>   SCHED_WARN_ON(dl_rq->running_bw < old); /* overflow */
> }
> 
> static void sub_running_bw(struct sched_dl_entity *dl_se, struct
> dl_rq *dl_rq) {
>   u64 old = dl_rq->running_bw;
> 
>   dl_rq->running_bw -= dl_se->dl_bw;
>   SCHED_WARN_ON(dl_rq->running_bw > old); /* underflow */
> }

I wanted to change "SCHED_WARN_ON(dl_rq->running_bw > old); /*
underflow */" into "if (SCHED_WARN_ON(...)) dl_rq->running_bw = 0" (to
avoid using nonsensical "running_bw" values), but I see that
"SCHED_WARN_ON()" cannot be used inside an if (this seems to be a
difference respect to "SCHED_WARN()").
This is because of the definition used when CONFIG_SCHED_DEBUG is not
defined (I noticed the issue when testing with random kernel
configurations).

Is this expected? If yes, what should I do in this case? Something like
SCHED_WARN_ON(dl_rq->running_bw > old); /* underflow */
if (dl_rq->running_bw > old)
dl_rq->running_bw = 0;
?
Or something else?


Thanks,
Luca

Re: [PATCH 1/2] scsi: be2iscsi: set errno on error path

[Martin K. Petersen]

> "Pan" == Pan Bian  writes:

Pan> Variable ret is reset in the loop, and its value will be 0 during
Pan> the second and after repeat of the loop. If pci_alloc_consistent()
Pan> returns a NULL pointer then, it will leaves with return value 0. 0
Pan> means no error, which is contrary to the fact. This patches fixes
Pan> the bug, explicitly assigning "-ENOMEM" to return variable ret on
Pan> the path that the call to pci_alloc_consistent() fails.

Applied patches 1 and 2 to 4.10/scsi-queue.

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH 1/2] scsi: be2iscsi: set errno on error path

[Martin K. Petersen]

> "Pan" == Pan Bian  writes:

Pan> Variable ret is reset in the loop, and its value will be 0 during
Pan> the second and after repeat of the loop. If pci_alloc_consistent()
Pan> returns a NULL pointer then, it will leaves with return value 0. 0
Pan> means no error, which is contrary to the fact. This patches fixes
Pan> the bug, explicitly assigning "-ENOMEM" to return variable ret on
Pan> the path that the call to pci_alloc_consistent() fails.

Applied patches 1 and 2 to 4.10/scsi-queue.

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH v4 1/9] dt-bindings: clarify compatible property for rockchip timers

[Rob Herring]

On Tue, Nov 29, 2016 at 07:14:44PM +0300, Alexander Kochetkov wrote:
> Make all properties description in form '"rockchip,-timer",
> "rockchip,rk3288-timer"' for all chips found in linux kernel.
> 
> Suggested-by: Heiko Stübner 
> Signed-off-by: Alexander Kochetkov 
> ---
>  .../bindings/timer/rockchip,rk-timer.txt   |   12 +---
>  1 file changed, 9 insertions(+), 3 deletions(-)

Acked-by: Rob Herring 

Re: [PATCH v4 1/9] dt-bindings: clarify compatible property for rockchip timers

[Rob Herring]

On Tue, Nov 29, 2016 at 07:14:44PM +0300, Alexander Kochetkov wrote:
> Make all properties description in form '"rockchip,-timer",
> "rockchip,rk3288-timer"' for all chips found in linux kernel.
> 
> Suggested-by: Heiko Stübner 
> Signed-off-by: Alexander Kochetkov 
> ---
>  .../bindings/timer/rockchip,rk-timer.txt   |   12 +---
>  1 file changed, 9 insertions(+), 3 deletions(-)

Acked-by: Rob Herring 

Re: [PATCH] iommu/intel: disable DMAR for Q35 integrated gfx

[Kees Cook]

On Mon, Dec 5, 2016 at 2:07 PM, David Woodhouse  wrote:
> On Mon, 2016-12-05 at 13:58 -0800, Kees Cook wrote:
>> This blacklists the Q35 integrated graphics so IOMMU can be otherwise
>> enabled. Without this, a Q35 system can only enable IOMMU when booting
>> with "intel_iommu=on,igfx_off" but not "intel_iommu=on".
>
> Hm, is this definitely the same bug? Or is it something different, and
> perhaps a BIOS issue? There are many of those...

Hm, I have no idea. :) What would I look for in the BIOS?

I figured since g4 was busted, surely q35 was too, since it's even older...

-Kees

-- 
Kees Cook
Nexus Security

Re: [PATCH] iommu/intel: disable DMAR for Q35 integrated gfx

[Kees Cook]

On Mon, Dec 5, 2016 at 2:07 PM, David Woodhouse  wrote:
> On Mon, 2016-12-05 at 13:58 -0800, Kees Cook wrote:
>> This blacklists the Q35 integrated graphics so IOMMU can be otherwise
>> enabled. Without this, a Q35 system can only enable IOMMU when booting
>> with "intel_iommu=on,igfx_off" but not "intel_iommu=on".
>
> Hm, is this definitely the same bug? Or is it something different, and
> perhaps a BIOS issue? There are many of those...

Hm, I have no idea. :) What would I look for in the BIOS?

I figured since g4 was busted, surely q35 was too, since it's even older...

-Kees

-- 
Kees Cook
Nexus Security

Re: [PATCH v2 net-next v2 4/4] net: dsa: mv88e6xxx: add PPU operations

[Vivien Didelot]

Stefan Eichenberger  writes:

> Hi Vivien,
>
> On Mon, Dec 05, 2016 at 11:27:03AM -0500, Vivien Didelot wrote:
>> @@ -3266,6 +3220,8 @@ static const struct mv88e6xxx_ops mv88e6097_ops = {
>>  .g1_set_cpu_port = mv88e6095_g1_set_cpu_port,
>>  .g1_set_egress_port = mv88e6095_g1_set_egress_port,
>>  .mgmt_rsvd2cpu = mv88e6095_g2_mgmt_rsvd2cpu,
>> +.ppu_enable = mv88e6185_g1_ppu_enable,
>> +.ppu_disable = mv88e6185_g1_ppu_disable,
>>  .reset = mv88e6185_g1_reset,
>>  };
>
> The mv88e6097 should use the indirect access to the phys, bit 14 in g1
> control is marked as reserved. They write in the datasheet that
> disabling the PPU is still supported but indirect access via g2 should
> be used because disabling the PPU  is no longer recommended.

Ho ok thanks, I respin a v3 right away with this removed and with
mv88e6352_g1_reset instead.

Vivien

Re: [PATCH v2 net-next v2 4/4] net: dsa: mv88e6xxx: add PPU operations

[Vivien Didelot]

Stefan Eichenberger  writes:

> Hi Vivien,
>
> On Mon, Dec 05, 2016 at 11:27:03AM -0500, Vivien Didelot wrote:
>> @@ -3266,6 +3220,8 @@ static const struct mv88e6xxx_ops mv88e6097_ops = {
>>  .g1_set_cpu_port = mv88e6095_g1_set_cpu_port,
>>  .g1_set_egress_port = mv88e6095_g1_set_egress_port,
>>  .mgmt_rsvd2cpu = mv88e6095_g2_mgmt_rsvd2cpu,
>> +.ppu_enable = mv88e6185_g1_ppu_enable,
>> +.ppu_disable = mv88e6185_g1_ppu_disable,
>>  .reset = mv88e6185_g1_reset,
>>  };
>
> The mv88e6097 should use the indirect access to the phys, bit 14 in g1
> control is marked as reserved. They write in the datasheet that
> disabling the PPU is still supported but indirect access via g2 should
> be used because disabling the PPU  is no longer recommended.

Ho ok thanks, I respin a v3 right away with this removed and with
mv88e6352_g1_reset instead.

Vivien

Re: [PATCH 3/4] rtc: mcp795: fix month write resetting date to 1.

[Emil Bartczak]

Hi,

On Mon, Dec 05, 2016 at 04:24:10PM +0100, Alexandre Belloni wrote:
> On 05/12/2016 at 14:11:52 +0100, Emil Bartczak wrote :
> > According to Microchip errata some combinations of date and month
> > values may result in the date being reset to 1, even if the date
> > is also written with the month (for example 31-07 or 31-08).
> > As a workaround avoid writing date and month values within the same
> > Write command. Instead, terminate the Write command after loading
> > the date and begin a new command to write the month. In addition,
> > disable the oscillator before loading the new values. This is done
> > by ensuring both the ST and EXTOSC bits are cleared and waiting for
> > the OSCON bit to clear.
> > ---
> >  drivers/rtc/rtc-mcp795.c | 103 
> > +--
> >  1 file changed, 82 insertions(+), 21 deletions(-)
> > 
> > diff --git a/drivers/rtc/rtc-mcp795.c b/drivers/rtc/rtc-mcp795.c
> > index d15072c..c9ad46c 100644
> > --- a/drivers/rtc/rtc-mcp795.c
> > +++ b/drivers/rtc/rtc-mcp795.c
> > @@ -21,25 +21,34 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  
> >  /* MCP795 Instructions, see datasheet table 3-1 */
> > -#define MCP795_EEREAD  0x03
> > -#define MCP795_EEWRITE 0x02
> > -#define MCP795_EEWRDI  0x04
> > -#define MCP795_EEWREN  0x06
> > -#define MCP795_SRREAD  0x05
> > -#define MCP795_SRWRITE 0x01
> > -#define MCP795_READ0x13
> > -#define MCP795_WRITE   0x12
> > -#define MCP795_UNLOCK  0x14
> > -#define MCP795_IDWRITE 0x32
> > -#define MCP795_IDREAD  0x33
> > -#define MCP795_CLRWDT  0x44
> > -#define MCP795_CLRRAM  0x54
> > -
> > -#define MCP795_ST_BIT  0x80
> > -#define MCP795_24_BIT  0x40
> > -#define MCP795_LP_BIT  0x20
> > +#define MCP795_EEREAD  0x03
> > +#define MCP795_EEWRITE 0x02
> > +#define MCP795_EEWRDI  0x04
> > +#define MCP795_EEWREN  0x06
> > +#define MCP795_SRREAD  0x05
> > +#define MCP795_SRWRITE 0x01
> > +#define MCP795_READ0x13
> > +#define MCP795_WRITE   0x12
> > +#define MCP795_UNLOCK  0x14
> > +#define MCP795_IDWRITE 0x32
> > +#define MCP795_IDREAD  0x33
> > +#define MCP795_CLRWDT  0x44
> > +#define MCP795_CLRRAM  0x54
> > +
> 
> Please don't reindent, they are a separate block anyway.
Ok,

> 
> > +/* MCP795 RTCC registers, see datasheet table 4-1 */
> > +#define MCP795_REG_SECONDS 0x01
> > +#define MCP795_REG_DAY 0x04
> > +#define MCP795_REG_MONTH   0x06
> > +#define MCP795_REG_CONTROL 0x08
> > +
> > +#define MCP795_ST_BIT  0x80
> > +#define MCP795_24_BIT  0x40
> > +#define MCP795_LP_BIT  0x20
> > +#define MCP795_EXTOSC_BIT  0x08
> > +#define MCP795_OSCON_BIT   0x20
> 
> Please use BIT() and that is valid for the first patch too).
Ok, I will fix it in the next patchset.

> 
> >  
> >  static int mcp795_rtcc_read(struct device *dev, u8 addr, u8 *buf, u8 count)
> >  {
> > @@ -94,14 +103,51 @@ static int mcp795_rtcc_set_bits(struct device *dev, u8 
> > addr, u8 mask, u8 state)
> > return ret;
> >  }
> >  
> > +static int mcp795_stop_oscillator(struct device *dev)
> > +{
> > +   int retries = 5;
> > +   int ret;
> > +   u8 data;
> > +
> > +   ret = mcp795_rtcc_set_bits(dev, MCP795_REG_SECONDS, MCP795_ST_BIT, 0);
> > +   if (ret)
> > +   return ret;
> > +   ret = mcp795_rtcc_set_bits(dev, MCP795_REG_CONTROL, MCP795_EXTOSC_BIT, 
> > 0);
> > +   if (ret)
> > +   return ret;
> > +   do {
> > +   usleep_range(700, 800);
> > +   ret = mcp795_rtcc_read(dev, MCP795_REG_DAY,
> > +   , sizeof(data));
> > +   if (ret)
> > +   break;
> > +   if (!(data & MCP795_OSCON_BIT))
> > +   break;
> > +
> > +   } while (--retries);
> > +
> > +   return !retries ? -EIO : ret;
> > +}
> > +
> > +static int mcp795_start_oscillator(struct device *dev)
> > +{
> > +   return mcp795_rtcc_set_bits(dev, MCP795_REG_SECONDS,
> > +   MCP795_ST_BIT, MCP795_ST_BIT);
> 
> You probably want to restore EXTOSC to its previous value here.
I came to the conclusion that it is better to remove clearing of bit EXTOSC in 
function mcp795_stop_oscillator.
Because regarding datasheet, after power up the RTC chip (or reset) that bit 
has value 0.
What do you think?
 
> 
> 
> -- 
> Alexandre Belloni, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com

Emil,

Re: [PATCH 3/4] rtc: mcp795: fix month write resetting date to 1.

[Emil Bartczak]

Hi,

On Mon, Dec 05, 2016 at 04:24:10PM +0100, Alexandre Belloni wrote:
> On 05/12/2016 at 14:11:52 +0100, Emil Bartczak wrote :
> > According to Microchip errata some combinations of date and month
> > values may result in the date being reset to 1, even if the date
> > is also written with the month (for example 31-07 or 31-08).
> > As a workaround avoid writing date and month values within the same
> > Write command. Instead, terminate the Write command after loading
> > the date and begin a new command to write the month. In addition,
> > disable the oscillator before loading the new values. This is done
> > by ensuring both the ST and EXTOSC bits are cleared and waiting for
> > the OSCON bit to clear.
> > ---
> >  drivers/rtc/rtc-mcp795.c | 103 
> > +--
> >  1 file changed, 82 insertions(+), 21 deletions(-)
> > 
> > diff --git a/drivers/rtc/rtc-mcp795.c b/drivers/rtc/rtc-mcp795.c
> > index d15072c..c9ad46c 100644
> > --- a/drivers/rtc/rtc-mcp795.c
> > +++ b/drivers/rtc/rtc-mcp795.c
> > @@ -21,25 +21,34 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  
> >  /* MCP795 Instructions, see datasheet table 3-1 */
> > -#define MCP795_EEREAD  0x03
> > -#define MCP795_EEWRITE 0x02
> > -#define MCP795_EEWRDI  0x04
> > -#define MCP795_EEWREN  0x06
> > -#define MCP795_SRREAD  0x05
> > -#define MCP795_SRWRITE 0x01
> > -#define MCP795_READ0x13
> > -#define MCP795_WRITE   0x12
> > -#define MCP795_UNLOCK  0x14
> > -#define MCP795_IDWRITE 0x32
> > -#define MCP795_IDREAD  0x33
> > -#define MCP795_CLRWDT  0x44
> > -#define MCP795_CLRRAM  0x54
> > -
> > -#define MCP795_ST_BIT  0x80
> > -#define MCP795_24_BIT  0x40
> > -#define MCP795_LP_BIT  0x20
> > +#define MCP795_EEREAD  0x03
> > +#define MCP795_EEWRITE 0x02
> > +#define MCP795_EEWRDI  0x04
> > +#define MCP795_EEWREN  0x06
> > +#define MCP795_SRREAD  0x05
> > +#define MCP795_SRWRITE 0x01
> > +#define MCP795_READ0x13
> > +#define MCP795_WRITE   0x12
> > +#define MCP795_UNLOCK  0x14
> > +#define MCP795_IDWRITE 0x32
> > +#define MCP795_IDREAD  0x33
> > +#define MCP795_CLRWDT  0x44
> > +#define MCP795_CLRRAM  0x54
> > +
> 
> Please don't reindent, they are a separate block anyway.
Ok,

> 
> > +/* MCP795 RTCC registers, see datasheet table 4-1 */
> > +#define MCP795_REG_SECONDS 0x01
> > +#define MCP795_REG_DAY 0x04
> > +#define MCP795_REG_MONTH   0x06
> > +#define MCP795_REG_CONTROL 0x08
> > +
> > +#define MCP795_ST_BIT  0x80
> > +#define MCP795_24_BIT  0x40
> > +#define MCP795_LP_BIT  0x20
> > +#define MCP795_EXTOSC_BIT  0x08
> > +#define MCP795_OSCON_BIT   0x20
> 
> Please use BIT() and that is valid for the first patch too).
Ok, I will fix it in the next patchset.

> 
> >  
> >  static int mcp795_rtcc_read(struct device *dev, u8 addr, u8 *buf, u8 count)
> >  {
> > @@ -94,14 +103,51 @@ static int mcp795_rtcc_set_bits(struct device *dev, u8 
> > addr, u8 mask, u8 state)
> > return ret;
> >  }
> >  
> > +static int mcp795_stop_oscillator(struct device *dev)
> > +{
> > +   int retries = 5;
> > +   int ret;
> > +   u8 data;
> > +
> > +   ret = mcp795_rtcc_set_bits(dev, MCP795_REG_SECONDS, MCP795_ST_BIT, 0);
> > +   if (ret)
> > +   return ret;
> > +   ret = mcp795_rtcc_set_bits(dev, MCP795_REG_CONTROL, MCP795_EXTOSC_BIT, 
> > 0);
> > +   if (ret)
> > +   return ret;
> > +   do {
> > +   usleep_range(700, 800);
> > +   ret = mcp795_rtcc_read(dev, MCP795_REG_DAY,
> > +   , sizeof(data));
> > +   if (ret)
> > +   break;
> > +   if (!(data & MCP795_OSCON_BIT))
> > +   break;
> > +
> > +   } while (--retries);
> > +
> > +   return !retries ? -EIO : ret;
> > +}
> > +
> > +static int mcp795_start_oscillator(struct device *dev)
> > +{
> > +   return mcp795_rtcc_set_bits(dev, MCP795_REG_SECONDS,
> > +   MCP795_ST_BIT, MCP795_ST_BIT);
> 
> You probably want to restore EXTOSC to its previous value here.
I came to the conclusion that it is better to remove clearing of bit EXTOSC in 
function mcp795_stop_oscillator.
Because regarding datasheet, after power up the RTC chip (or reset) that bit 
has value 0.
What do you think?
 
> 
> 
> -- 
> Alexandre Belloni, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com

Emil,

Re: [PATCH 1/4] rtc: mcp795: fix invalid month setting.

[Alexandre Belloni]

On 05/12/2016 at 23:03:52 +0100, Emil Bartczak wrote :
> > 
> > >  #define MCP795_WRITE 0x12
> > >  #define MCP795_UNLOCK0x14
> > >  #define MCP795_IDWRITE   0x32
> > > @@ -39,6 +39,7 @@
> > >  
> > >  #define MCP795_ST_BIT0x80
> > >  #define MCP795_24_BIT0x40
> > > +#define MCP795_LP_BIT0x20
> > >  
> > >  static int mcp795_rtcc_read(struct device *dev, u8 addr, u8 *buf, u8 
> > > count)
> > >  {
> > > @@ -108,7 +109,8 @@ static int mcp795_set_time(struct device *dev, struct 
> > > rtc_time *tim)
> > >   data[1] = (data[1] & 0x80) | ((tim->tm_min / 10) << 4) | (tim->tm_min % 
> > > 10);
> > >   data[2] = ((tim->tm_hour / 10) << 4) | (tim->tm_hour % 10);
> > >   data[4] = ((tim->tm_mday / 10) << 4) | ((tim->tm_mday) % 10);
> > > - data[5] = (data[5] & 0x10) | (tim->tm_mon / 10) | (tim->tm_mon % 10);
> > > + data[5] = (data[5] & MCP795_LP_BIT) |
> > 
> > You changed 0x10 in MCP795_LP_BIT which you defined as 0x20, is that
> > right?
> Yes, it should be 0x20 (checked in datasheet).
> 
> > 
> > This is also an unrelated change.
> > 
> > > + ((tim->tm_mon / 10) << 4) | (tim->tm_mon % 10);
> What do you mean exactly? 
> That above line of code was moved to the new line? Or that I added
> shift left operation (tim->tm_mon / 10) << 4)?
> Changing 0x10 to 0x20 and adding shift right operation fixes the problem.
> 

I meant that I feel like changing 0x10 to 0x20 is a separate bugfix from
adding the shift. At least mention that in the commit message.

> > >  
> > >   if (tim->tm_year > 100)
> > >   tim->tm_year -= 100;
> > > @@ -137,11 +139,11 @@ static int mcp795_read_time(struct device *dev, 
> > > struct rtc_time *tim)
> > >   if (ret)
> > >   return ret;
> > >  
> > > - tim->tm_sec = ((data[0] & 0x70) >> 4) * 10 + (data[0] & 
> > > 0x0f);
> > > - tim->tm_min = ((data[1] & 0x70) >> 4) * 10 + (data[1] & 
> > > 0x0f);
> > > + tim->tm_sec = ((data[0] & 0x70) >> 4) * 10 + (data[0] & 0x0f);
> > > + tim->tm_min = ((data[1] & 0x70) >> 4) * 10 + (data[1] & 0x0f);
> > >   tim->tm_hour= ((data[2] & 0x30) >> 4) * 10 + (data[2] & 0x0f);
> > >   tim->tm_mday= ((data[4] & 0x30) >> 4) * 10 + (data[4] & 0x0f);
> > > - tim->tm_mon = ((data[5] & 0x10) >> 4) * 10 + (data[5] & 
> > > 0x0f);
> > > + tim->tm_mon = ((data[5] & 0x10) >> 4) * 10 + (data[5] & 0x0f);
> > 
> > All those whitespace changes are actually confusing. Please do them in a
> > separate patch or in your last patch.
> Ok, I will have a separate patch for them.

Maybe switching to bcd2bin/bin2bcd first is better as it touches all
those lines anyway and also solves the shift in mcp795_rtcc_read()


-- 
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [PATCH 1/4] rtc: mcp795: fix invalid month setting.

[Alexandre Belloni]

On 05/12/2016 at 23:03:52 +0100, Emil Bartczak wrote :
> > 
> > >  #define MCP795_WRITE 0x12
> > >  #define MCP795_UNLOCK0x14
> > >  #define MCP795_IDWRITE   0x32
> > > @@ -39,6 +39,7 @@
> > >  
> > >  #define MCP795_ST_BIT0x80
> > >  #define MCP795_24_BIT0x40
> > > +#define MCP795_LP_BIT0x20
> > >  
> > >  static int mcp795_rtcc_read(struct device *dev, u8 addr, u8 *buf, u8 
> > > count)
> > >  {
> > > @@ -108,7 +109,8 @@ static int mcp795_set_time(struct device *dev, struct 
> > > rtc_time *tim)
> > >   data[1] = (data[1] & 0x80) | ((tim->tm_min / 10) << 4) | (tim->tm_min % 
> > > 10);
> > >   data[2] = ((tim->tm_hour / 10) << 4) | (tim->tm_hour % 10);
> > >   data[4] = ((tim->tm_mday / 10) << 4) | ((tim->tm_mday) % 10);
> > > - data[5] = (data[5] & 0x10) | (tim->tm_mon / 10) | (tim->tm_mon % 10);
> > > + data[5] = (data[5] & MCP795_LP_BIT) |
> > 
> > You changed 0x10 in MCP795_LP_BIT which you defined as 0x20, is that
> > right?
> Yes, it should be 0x20 (checked in datasheet).
> 
> > 
> > This is also an unrelated change.
> > 
> > > + ((tim->tm_mon / 10) << 4) | (tim->tm_mon % 10);
> What do you mean exactly? 
> That above line of code was moved to the new line? Or that I added
> shift left operation (tim->tm_mon / 10) << 4)?
> Changing 0x10 to 0x20 and adding shift right operation fixes the problem.
> 

I meant that I feel like changing 0x10 to 0x20 is a separate bugfix from
adding the shift. At least mention that in the commit message.

> > >  
> > >   if (tim->tm_year > 100)
> > >   tim->tm_year -= 100;
> > > @@ -137,11 +139,11 @@ static int mcp795_read_time(struct device *dev, 
> > > struct rtc_time *tim)
> > >   if (ret)
> > >   return ret;
> > >  
> > > - tim->tm_sec = ((data[0] & 0x70) >> 4) * 10 + (data[0] & 
> > > 0x0f);
> > > - tim->tm_min = ((data[1] & 0x70) >> 4) * 10 + (data[1] & 
> > > 0x0f);
> > > + tim->tm_sec = ((data[0] & 0x70) >> 4) * 10 + (data[0] & 0x0f);
> > > + tim->tm_min = ((data[1] & 0x70) >> 4) * 10 + (data[1] & 0x0f);
> > >   tim->tm_hour= ((data[2] & 0x30) >> 4) * 10 + (data[2] & 0x0f);
> > >   tim->tm_mday= ((data[4] & 0x30) >> 4) * 10 + (data[4] & 0x0f);
> > > - tim->tm_mon = ((data[5] & 0x10) >> 4) * 10 + (data[5] & 
> > > 0x0f);
> > > + tim->tm_mon = ((data[5] & 0x10) >> 4) * 10 + (data[5] & 0x0f);
> > 
> > All those whitespace changes are actually confusing. Please do them in a
> > separate patch or in your last patch.
> Ok, I will have a separate patch for them.

Maybe switching to bcd2bin/bin2bcd first is better as it touches all
those lines anyway and also solves the shift in mcp795_rtcc_read()


-- 
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: Build error due to commit 8ab2ae655b ("default exported asm symbols to zero")

[Linus Torvalds]

On Mon, Dec 5, 2016 at 1:23 PM, Guenter Roeck  wrote:
>
> commit 8ab2ae655bf ("default exported asm symbols to zero") results
> in the following build error when building alpha:allmodconfig.
>
> arch/alpha/lib/callback_srm.S: Assembler messages:
> arch/alpha/lib/callback_srm.S:97: Warning:
> Tried to .set unrecognized mode `__crc_callback_getenv'
> arch/alpha/lib/callback_srm.S:97: Error:
> junk at end of line, first unrecognized character is `,'

Christ on a stick!

This binutils modversion problem is just _incredibly_ annoying.

I think the problem is that on alpha, ".set" is used for various
random attributes, like "noat" and "noreorder".

Hmm. Looking at what the C __kcrctab_ output is, it looks like this
for me (picking one at random):

  .section___kcrctab+blk_set_runtime_active,"a",@progbits
  .align 8
  .type   __kcrctab_blk_set_runtime_active, @object
  .size   __kcrctab_blk_set_runtime_active, 8
  __kcrctab_blk_set_runtime_active:
  .quad   __crc_blk_set_runtime_active

and I wonder if we should just try to emulate that as closely as possible?

For example, why does the asm code use ".weak" for the kcrctab entry?
None of the other entries do that. Maybe just removing the .weak (and
the .set) would fix things?

Over to Arnd, who presumably knows more than he ever really wanted to
know about those nasty crc entries.. Ideas?

  Linus

Re: Build error due to commit 8ab2ae655b ("default exported asm symbols to zero")

[Linus Torvalds]

On Mon, Dec 5, 2016 at 1:23 PM, Guenter Roeck  wrote:
>
> commit 8ab2ae655bf ("default exported asm symbols to zero") results
> in the following build error when building alpha:allmodconfig.
>
> arch/alpha/lib/callback_srm.S: Assembler messages:
> arch/alpha/lib/callback_srm.S:97: Warning:
> Tried to .set unrecognized mode `__crc_callback_getenv'
> arch/alpha/lib/callback_srm.S:97: Error:
> junk at end of line, first unrecognized character is `,'

Christ on a stick!

This binutils modversion problem is just _incredibly_ annoying.

I think the problem is that on alpha, ".set" is used for various
random attributes, like "noat" and "noreorder".

Hmm. Looking at what the C __kcrctab_ output is, it looks like this
for me (picking one at random):

  .section___kcrctab+blk_set_runtime_active,"a",@progbits
  .align 8
  .type   __kcrctab_blk_set_runtime_active, @object
  .size   __kcrctab_blk_set_runtime_active, 8
  __kcrctab_blk_set_runtime_active:
  .quad   __crc_blk_set_runtime_active

and I wonder if we should just try to emulate that as closely as possible?

For example, why does the asm code use ".weak" for the kcrctab entry?
None of the other entries do that. Maybe just removing the .weak (and
the .set) would fix things?

Over to Arnd, who presumably knows more than he ever really wanted to
know about those nasty crc entries.. Ideas?

  Linus

Re: stmmac ethernet in kernel 4.9-rc6: coalescing related pauses.

[Pavel Machek]

Hi!

> > 
> > Actually, I was wrong. irqlock protection is needed, since
> > stmmac_tx_clean() is called from timer, and that's interrupt context,
> > as you can confirm using BUG_ON(in_interrupt());
> > 
> 
> in_interrupt() can mean both softirq and hardirq context. In this case it
> means softirq. So I guess you were right before, and no irq locking is needed.

Are you absolutely sure? Because my testing seems to indicate
otherwise (but I may have made a mistake).

According to

https://www.kernel.org/pub/linux/kernel/people/rusty/kernel-locking/c214.html

we need spin_lock_bh at minimum, as we are locking user context
against timer.

Best regards,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH v3] PCI/ACPI: xgene: Add ECAM quirk for X-Gene PCIe controller

[Duc Dang]

On Mon, Dec 5, 2016 at 1:53 PM, Bjorn Helgaas  wrote:
> On Thu, Dec 01, 2016 at 06:52:23PM -0800, Duc Dang wrote:
>> On Thu, Dec 1, 2016 at 10:33 AM, Bjorn Helgaas  wrote:
>
>> I made similar changes in v4 patch. The ECAM quirk will be built when
>> ACPI and PCI_QUIRKS are enabled.
>>
>> When building for DT only, the ECAM quirk won't be compiled.
>
> Perfect.
>
>> >>  #define XGENE_PCIE_IP_VER_UNKN   0
>> >>  #define XGENE_PCIE_IP_VER_1  1
>> >> +#define XGENE_PCIE_IP_VER_2  2
>> >
>> > This isn't used anywhere, which makes me wonder whether it's worth
>> > keeping it.
>>
>> V2 controller will use this XGENE_PCIE_IP_VER_2 (port->version =
>> XGENE_PCIE_IP_VER_2). This will be used to indicate that the
>> controller is V2, and to enable configuration request retry status
>> feature (by not disable it like V1 controller).
>
> OK, I see.  You don't actually need XGENE_PCIE_IP_VER_2, you just need
> port->version to be something other than XGENE_PCIE_IP_VER_1.  So this
> is fine as it is.
>
>> >>  static void __iomem *xgene_pcie_get_cfg_base(struct pci_bus *bus)
>> >>  {
>> >> - struct xgene_pcie_port *port = bus->sysdata;
>> >> + struct pci_config_window *cfg;
>> >> + struct xgene_pcie_port *port;
>> >> +
>> >> + if (acpi_disabled)
>> >> + port = bus->sysdata;
>> >> + else {
>> >> + cfg = bus->sysdata;
>> >> + port = cfg->priv;
>> >> + }
>> >
>> > I would really, really like to figure out a way to get rid of these
>> > "if (acpi_disabled)" checks sprinkled through here.  Is there any way
>> > we can set up bus->sysdata to be the same, regardless of whether we're
>> > using this as a platform driver or an ACPI quirk?
>>
>> Right now, I created a inline function to extract xgene_pcie_port from
>> pci_bus. In order to get rid of acpi_disabled, I will need to make
>> sysdata in DT case also point to pci_config_window structure, which
>> means I will need to convert and test the DT driver to use ecam ops.
>> It is a separate patch itself. So I think I should do it at later time
>> (after this ECAM quirk patch). I hope you are ok with this.
>
> OK.  I did the simple-minded version of leaving the DT ops the same
> but making sysdata point to a dummy pci_config_window.  Your proposal
> of using ECAM for DT would be much better.
>
> It's interesting that you actually already use the same accessors
> except that DT uses the 32-bit pci_generic_config_write32() and ACPI
> uses the regular pci_generic_config_write(). I guess that means the
> hardware actually *does* support sub-32 bit writes?

Yes, the hardware does support sub-32 bit writes (and reads). This is
another item in my TODO list for DT (which does not seem quite urgent
now): switch to use pci_generic_config_write for DT. But, well, I will
need to do that for read as well (for both ACPI and DT).

>
>> I need to define the function (xgene_get_csr_resource()) inside
>> pci-xgene.c to duplicate the code of acpi_get_rc_addr. The reason is
>> X-Gene firmware does not have a dedicate PNP0C02 node to declare the
>> resource, and if I use acpi_get_rc_resources() with "PNP0A08", I got
>> error due to acpi_bus_get_device() returns error.
>
> Looks good.
>
>> > All these init functions are almost identical.  Can we factor this out
>> > by having wrappers that do nothing more than pass in the table and
>> > version, and put the kzalloc and ioremap in a shared back-end?
>>
>> I refactor-ed these .init functions. And as a result, there are only 2
>> ecam ops left: xgene_v1_pcie_ecam_ops and xgene_v2_pcie_ecam_ops.
>
> Looks good.
>
> Bjorn
Regards,
Duc Dang.

Re: stmmac ethernet in kernel 4.9-rc6: coalescing related pauses.

[Pavel Machek]

Hi!

> > 
> > Actually, I was wrong. irqlock protection is needed, since
> > stmmac_tx_clean() is called from timer, and that's interrupt context,
> > as you can confirm using BUG_ON(in_interrupt());
> > 
> 
> in_interrupt() can mean both softirq and hardirq context. In this case it
> means softirq. So I guess you were right before, and no irq locking is needed.

Are you absolutely sure? Because my testing seems to indicate
otherwise (but I may have made a mistake).

According to

https://www.kernel.org/pub/linux/kernel/people/rusty/kernel-locking/c214.html

we need spin_lock_bh at minimum, as we are locking user context
against timer.

Best regards,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH v3] PCI/ACPI: xgene: Add ECAM quirk for X-Gene PCIe controller

[Duc Dang]

On Mon, Dec 5, 2016 at 1:53 PM, Bjorn Helgaas  wrote:
> On Thu, Dec 01, 2016 at 06:52:23PM -0800, Duc Dang wrote:
>> On Thu, Dec 1, 2016 at 10:33 AM, Bjorn Helgaas  wrote:
>
>> I made similar changes in v4 patch. The ECAM quirk will be built when
>> ACPI and PCI_QUIRKS are enabled.
>>
>> When building for DT only, the ECAM quirk won't be compiled.
>
> Perfect.
>
>> >>  #define XGENE_PCIE_IP_VER_UNKN   0
>> >>  #define XGENE_PCIE_IP_VER_1  1
>> >> +#define XGENE_PCIE_IP_VER_2  2
>> >
>> > This isn't used anywhere, which makes me wonder whether it's worth
>> > keeping it.
>>
>> V2 controller will use this XGENE_PCIE_IP_VER_2 (port->version =
>> XGENE_PCIE_IP_VER_2). This will be used to indicate that the
>> controller is V2, and to enable configuration request retry status
>> feature (by not disable it like V1 controller).
>
> OK, I see.  You don't actually need XGENE_PCIE_IP_VER_2, you just need
> port->version to be something other than XGENE_PCIE_IP_VER_1.  So this
> is fine as it is.
>
>> >>  static void __iomem *xgene_pcie_get_cfg_base(struct pci_bus *bus)
>> >>  {
>> >> - struct xgene_pcie_port *port = bus->sysdata;
>> >> + struct pci_config_window *cfg;
>> >> + struct xgene_pcie_port *port;
>> >> +
>> >> + if (acpi_disabled)
>> >> + port = bus->sysdata;
>> >> + else {
>> >> + cfg = bus->sysdata;
>> >> + port = cfg->priv;
>> >> + }
>> >
>> > I would really, really like to figure out a way to get rid of these
>> > "if (acpi_disabled)" checks sprinkled through here.  Is there any way
>> > we can set up bus->sysdata to be the same, regardless of whether we're
>> > using this as a platform driver or an ACPI quirk?
>>
>> Right now, I created a inline function to extract xgene_pcie_port from
>> pci_bus. In order to get rid of acpi_disabled, I will need to make
>> sysdata in DT case also point to pci_config_window structure, which
>> means I will need to convert and test the DT driver to use ecam ops.
>> It is a separate patch itself. So I think I should do it at later time
>> (after this ECAM quirk patch). I hope you are ok with this.
>
> OK.  I did the simple-minded version of leaving the DT ops the same
> but making sysdata point to a dummy pci_config_window.  Your proposal
> of using ECAM for DT would be much better.
>
> It's interesting that you actually already use the same accessors
> except that DT uses the 32-bit pci_generic_config_write32() and ACPI
> uses the regular pci_generic_config_write(). I guess that means the
> hardware actually *does* support sub-32 bit writes?

Yes, the hardware does support sub-32 bit writes (and reads). This is
another item in my TODO list for DT (which does not seem quite urgent
now): switch to use pci_generic_config_write for DT. But, well, I will
need to do that for read as well (for both ACPI and DT).

>
>> I need to define the function (xgene_get_csr_resource()) inside
>> pci-xgene.c to duplicate the code of acpi_get_rc_addr. The reason is
>> X-Gene firmware does not have a dedicate PNP0C02 node to declare the
>> resource, and if I use acpi_get_rc_resources() with "PNP0A08", I got
>> error due to acpi_bus_get_device() returns error.
>
> Looks good.
>
>> > All these init functions are almost identical.  Can we factor this out
>> > by having wrappers that do nothing more than pass in the table and
>> > version, and put the kzalloc and ioremap in a shared back-end?
>>
>> I refactor-ed these .init functions. And as a result, there are only 2
>> ecam ops left: xgene_v1_pcie_ecam_ops and xgene_v2_pcie_ecam_ops.
>
> Looks good.
>
> Bjorn
Regards,
Duc Dang.

[PATCH v4 net-next 2/2] MAINTAINERS: add entry for slicoss ethernet driver

[Lino Sanfilippo]

Add myself as maintainer for the slicoss ethernet driver.

Signed-off-by: Lino Sanfilippo 
---
 MAINTAINERS | 5 +
 1 file changed, 5 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 6781a3f..bb9af28 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -562,6 +562,11 @@ T: git git://linuxtv.org/anttip/media_tree.git
 S: Maintained
 F: drivers/media/usb/airspy/
 
+ALACRITECH GIGABIT ETHERNET DRIVER
+M: Lino Sanfilippo 
+S: Maintained
+F: drivers/net/ethernet/alacritech/*
+
 ALCATEL SPEEDTOUCH USB DRIVER
 M: Duncan Sands 
 L: linux-...@vger.kernel.org
-- 
1.9.1

[PATCH v4 net-next 2/2] MAINTAINERS: add entry for slicoss ethernet driver

[Lino Sanfilippo]

Add myself as maintainer for the slicoss ethernet driver.

Signed-off-by: Lino Sanfilippo 
---
 MAINTAINERS | 5 +
 1 file changed, 5 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 6781a3f..bb9af28 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -562,6 +562,11 @@ T: git git://linuxtv.org/anttip/media_tree.git
 S: Maintained
 F: drivers/media/usb/airspy/
 
+ALACRITECH GIGABIT ETHERNET DRIVER
+M: Lino Sanfilippo 
+S: Maintained
+F: drivers/net/ethernet/alacritech/*
+
 ALCATEL SPEEDTOUCH USB DRIVER
 M: Duncan Sands 
 L: linux-...@vger.kernel.org
-- 
1.9.1

Gigabit ethernet driver for Alacritechs SLIC devices (v4)

[Lino Sanfilippo]

Hi,

this is the forth version of the slicoss gigabit ethernet driver (which is a
rework of the driver from Alacritech which can currently be found under
drivers/staging/slicoss). The driver is supposed to support Mojave, Oasis and
Kalahari cards, for both copper and fiber.

If this code is accepted the staging version can be removed.

The driver has been tested on a SEN2104ET adapter (4 Port PCIe copper).

v4:
- fix wrong driver name in Kconfig file (reported by Rami Rosen)
- remove unused variable from driver struct (reported by Rami Rosen)
- return "err" instead of 0 in slic_load_rcvseq_firmware() (reported by Rami 
Rosen)
- Fix typos in constants, comments and error message (reported by Markus Böhme)
- fix various warnings concerning signedness (reported by Markus Böhme)
- improve line formatting (reported by Markus Böhme)
- add comment describing the need for SLIC_MAX_TX_COMPLETIONS (suggested by 
Florian Fainelli)
- do not zero out complete rx descriptor (suggested by Florian Fainelli)
- add missing write barrier (reported by Florian Fainelli)
- remove unneeded assignment of net_device to skb (reported by Florian Fainelli)
- use napi_complete_done() instead of napi_complete (suggested by Florian 
Fainelli)
- use napi_schedule_irqoff() instead of napi_schedule (suggested by Florian 
Fainelli)
- do not map error returned by slic_init() to -ENOMEM
- do proper dma syncs before and after rx descriptor status is set to 0
- if after dma sync for CPU rx descriptor is not used return it to HW by means 
of dma sync for device

v3:
- dont add defines to pci_ids.h but instead put it into the drivers header file
(requested by Greg Kroah-Hartman)

v2:
- remove unusual padding in statistic strings (suggested by Andrew Lunn)
- for mdio register and bit names use defines from mii.h instead of own ones
  (suggested by Andrew Lunn)
- remove unused defines
- ensure PCI flush at two more places
- use mmiowb before lock to prevent mmio writes leaking out of lock
- fix some typos in comments
- add copyright and GPL header

Regards,
Lino 

Gigabit ethernet driver for Alacritechs SLIC devices (v4)

[Lino Sanfilippo]

Hi,

this is the forth version of the slicoss gigabit ethernet driver (which is a
rework of the driver from Alacritech which can currently be found under
drivers/staging/slicoss). The driver is supposed to support Mojave, Oasis and
Kalahari cards, for both copper and fiber.

If this code is accepted the staging version can be removed.

The driver has been tested on a SEN2104ET adapter (4 Port PCIe copper).

v4:
- fix wrong driver name in Kconfig file (reported by Rami Rosen)
- remove unused variable from driver struct (reported by Rami Rosen)
- return "err" instead of 0 in slic_load_rcvseq_firmware() (reported by Rami 
Rosen)
- Fix typos in constants, comments and error message (reported by Markus Böhme)
- fix various warnings concerning signedness (reported by Markus Böhme)
- improve line formatting (reported by Markus Böhme)
- add comment describing the need for SLIC_MAX_TX_COMPLETIONS (suggested by 
Florian Fainelli)
- do not zero out complete rx descriptor (suggested by Florian Fainelli)
- add missing write barrier (reported by Florian Fainelli)
- remove unneeded assignment of net_device to skb (reported by Florian Fainelli)
- use napi_complete_done() instead of napi_complete (suggested by Florian 
Fainelli)
- use napi_schedule_irqoff() instead of napi_schedule (suggested by Florian 
Fainelli)
- do not map error returned by slic_init() to -ENOMEM
- do proper dma syncs before and after rx descriptor status is set to 0
- if after dma sync for CPU rx descriptor is not used return it to HW by means 
of dma sync for device

v3:
- dont add defines to pci_ids.h but instead put it into the drivers header file
(requested by Greg Kroah-Hartman)

v2:
- remove unusual padding in statistic strings (suggested by Andrew Lunn)
- for mdio register and bit names use defines from mii.h instead of own ones
  (suggested by Andrew Lunn)
- remove unused defines
- ensure PCI flush at two more places
- use mmiowb before lock to prevent mmio writes leaking out of lock
- fix some typos in comments
- add copyright and GPL header

Regards,
Lino 

[PATCH v4 net-next 1/2] net: ethernet: slicoss: add slicoss gigabit ethernet driver

[Lino Sanfilippo]

Add driver for Alacritech gigabit ethernet cards with SLIC (session-layer
interface control) technology. The driver provides basic support without
SLIC for the following devices:

- Mojave cards (single port PCI Gigabit) both copper and fiber
- Oasis cards (single and dual port PCI-x Gigabit) copper and fiber
- Kalahari cards (dual and quad port PCI-e Gigabit) copper and fiber

Signed-off-by: Lino Sanfilippo 
---
 drivers/net/ethernet/Kconfig  |1 +
 drivers/net/ethernet/Makefile |1 +
 drivers/net/ethernet/alacritech/Kconfig   |   28 +
 drivers/net/ethernet/alacritech/Makefile  |4 +
 drivers/net/ethernet/alacritech/slic.h|  575 +
 drivers/net/ethernet/alacritech/slicoss.c | 1882 +
 6 files changed, 2491 insertions(+)
 create mode 100644 drivers/net/ethernet/alacritech/Kconfig
 create mode 100644 drivers/net/ethernet/alacritech/Makefile
 create mode 100644 drivers/net/ethernet/alacritech/slic.h
 create mode 100644 drivers/net/ethernet/alacritech/slicoss.c

diff --git a/drivers/net/ethernet/Kconfig b/drivers/net/ethernet/Kconfig
index 2ffd634..a4cc87fe 100644
--- a/drivers/net/ethernet/Kconfig
+++ b/drivers/net/ethernet/Kconfig
@@ -21,6 +21,7 @@ source "drivers/net/ethernet/3com/Kconfig"
 source "drivers/net/ethernet/adaptec/Kconfig"
 source "drivers/net/ethernet/aeroflex/Kconfig"
 source "drivers/net/ethernet/agere/Kconfig"
+source "drivers/net/ethernet/alacritech/Kconfig"
 source "drivers/net/ethernet/allwinner/Kconfig"
 source "drivers/net/ethernet/alteon/Kconfig"
 source "drivers/net/ethernet/altera/Kconfig"
diff --git a/drivers/net/ethernet/Makefile b/drivers/net/ethernet/Makefile
index 1d349e9..b448027 100644
--- a/drivers/net/ethernet/Makefile
+++ b/drivers/net/ethernet/Makefile
@@ -7,6 +7,7 @@ obj-$(CONFIG_NET_VENDOR_8390) += 8390/
 obj-$(CONFIG_NET_VENDOR_ADAPTEC) += adaptec/
 obj-$(CONFIG_GRETH) += aeroflex/
 obj-$(CONFIG_NET_VENDOR_AGERE) += agere/
+obj-$(CONFIG_NET_VENDOR_ALACRITECH) += alacritech/
 obj-$(CONFIG_NET_VENDOR_ALLWINNER) += allwinner/
 obj-$(CONFIG_NET_VENDOR_ALTEON) += alteon/
 obj-$(CONFIG_ALTERA_TSE) += altera/
diff --git a/drivers/net/ethernet/alacritech/Kconfig 
b/drivers/net/ethernet/alacritech/Kconfig
new file mode 100644
index 000..09496e1
--- /dev/null
+++ b/drivers/net/ethernet/alacritech/Kconfig
@@ -0,0 +1,28 @@
+config NET_VENDOR_ALACRITECH
+   bool "Alacritech devices"
+   default y
+   ---help---
+ If you have a network (Ethernet) card belonging to this class, say Y.
+
+ Note that the answer to this question doesn't directly affect the
+ kernel: saying N will just cause the configurator to skip all the
+ questions about Alacritech devices. If you say Y, you will be asked
+ for your specific device in the following questions.
+
+if NET_VENDOR_ALACRITECH
+
+config SLICOSS
+   tristate "Alacritech Slicoss support"
+   depends on PCI
+   select CRC32
+   ---help---
+ This driver supports Gigabit Ethernet adapters based on the
+ Session Layer Interface (SLIC) technology by Alacritech.
+
+ Supported are Mojave (1 port) and Oasis (1, 2 and 4 port) cards,
+ both copper and fiber.
+
+ To compile this driver as a module, choose M here: the module
+ will be called slicoss. This is recommended.
+
+endif # NET_VENDOR_ALACRITECH
diff --git a/drivers/net/ethernet/alacritech/Makefile 
b/drivers/net/ethernet/alacritech/Makefile
new file mode 100644
index 000..8790e9e
--- /dev/null
+++ b/drivers/net/ethernet/alacritech/Makefile
@@ -0,0 +1,4 @@
+#
+# Makefile for the Alacritech Slicoss driver
+#
+obj-$(CONFIG_SLICOSS) += slicoss.o
diff --git a/drivers/net/ethernet/alacritech/slic.h 
b/drivers/net/ethernet/alacritech/slic.h
new file mode 100644
index 000..08931b4
--- /dev/null
+++ b/drivers/net/ethernet/alacritech/slic.h
@@ -0,0 +1,575 @@
+
+#ifndef _SLIC_H
+#define _SLIC_H
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define SLIC_VGBSTAT_XPERR 0x4000
+#define SLIC_VGBSTAT_XERRSHFT  25
+#define SLIC_VGBSTAT_XCSERR0x23
+#define SLIC_VGBSTAT_XUFLOW0x22
+#define SLIC_VGBSTAT_XHLEN 0x20
+#define SLIC_VGBSTAT_NETERR0x0100
+#define SLIC_VGBSTAT_NERRSHFT  16
+#define SLIC_VGBSTAT_NERRMSK   0x1ff
+#define SLIC_VGBSTAT_NCSERR0x103
+#define SLIC_VGBSTAT_NUFLOW0x102
+#define SLIC_VGBSTAT_NHLEN 0x100
+#define SLIC_VGBSTAT_LNKERR0x0080
+#define SLIC_VGBSTAT_LERRMSK   0xff
+#define SLIC_VGBSTAT_LDEARLY   0x86
+#define SLIC_VGBSTAT_LBOFLO0x85
+#define SLIC_VGBSTAT_LCODERR   0x84
+#define SLIC_VGBSTAT_LDBLNBL   0x83
+#define SLIC_VGBSTAT_LCRCERR   0x82
+#define SLIC_VGBSTAT_LOFLO 0x81
+#define SLIC_VGBSTAT_LUFLO 0x80
+

[PATCH v4 net-next 1/2] net: ethernet: slicoss: add slicoss gigabit ethernet driver

[Lino Sanfilippo]

Add driver for Alacritech gigabit ethernet cards with SLIC (session-layer
interface control) technology. The driver provides basic support without
SLIC for the following devices:

- Mojave cards (single port PCI Gigabit) both copper and fiber
- Oasis cards (single and dual port PCI-x Gigabit) copper and fiber
- Kalahari cards (dual and quad port PCI-e Gigabit) copper and fiber

Signed-off-by: Lino Sanfilippo 
---
 drivers/net/ethernet/Kconfig  |1 +
 drivers/net/ethernet/Makefile |1 +
 drivers/net/ethernet/alacritech/Kconfig   |   28 +
 drivers/net/ethernet/alacritech/Makefile  |4 +
 drivers/net/ethernet/alacritech/slic.h|  575 +
 drivers/net/ethernet/alacritech/slicoss.c | 1882 +
 6 files changed, 2491 insertions(+)
 create mode 100644 drivers/net/ethernet/alacritech/Kconfig
 create mode 100644 drivers/net/ethernet/alacritech/Makefile
 create mode 100644 drivers/net/ethernet/alacritech/slic.h
 create mode 100644 drivers/net/ethernet/alacritech/slicoss.c

diff --git a/drivers/net/ethernet/Kconfig b/drivers/net/ethernet/Kconfig
index 2ffd634..a4cc87fe 100644
--- a/drivers/net/ethernet/Kconfig
+++ b/drivers/net/ethernet/Kconfig
@@ -21,6 +21,7 @@ source "drivers/net/ethernet/3com/Kconfig"
 source "drivers/net/ethernet/adaptec/Kconfig"
 source "drivers/net/ethernet/aeroflex/Kconfig"
 source "drivers/net/ethernet/agere/Kconfig"
+source "drivers/net/ethernet/alacritech/Kconfig"
 source "drivers/net/ethernet/allwinner/Kconfig"
 source "drivers/net/ethernet/alteon/Kconfig"
 source "drivers/net/ethernet/altera/Kconfig"
diff --git a/drivers/net/ethernet/Makefile b/drivers/net/ethernet/Makefile
index 1d349e9..b448027 100644
--- a/drivers/net/ethernet/Makefile
+++ b/drivers/net/ethernet/Makefile
@@ -7,6 +7,7 @@ obj-$(CONFIG_NET_VENDOR_8390) += 8390/
 obj-$(CONFIG_NET_VENDOR_ADAPTEC) += adaptec/
 obj-$(CONFIG_GRETH) += aeroflex/
 obj-$(CONFIG_NET_VENDOR_AGERE) += agere/
+obj-$(CONFIG_NET_VENDOR_ALACRITECH) += alacritech/
 obj-$(CONFIG_NET_VENDOR_ALLWINNER) += allwinner/
 obj-$(CONFIG_NET_VENDOR_ALTEON) += alteon/
 obj-$(CONFIG_ALTERA_TSE) += altera/
diff --git a/drivers/net/ethernet/alacritech/Kconfig 
b/drivers/net/ethernet/alacritech/Kconfig
new file mode 100644
index 000..09496e1
--- /dev/null
+++ b/drivers/net/ethernet/alacritech/Kconfig
@@ -0,0 +1,28 @@
+config NET_VENDOR_ALACRITECH
+   bool "Alacritech devices"
+   default y
+   ---help---
+ If you have a network (Ethernet) card belonging to this class, say Y.
+
+ Note that the answer to this question doesn't directly affect the
+ kernel: saying N will just cause the configurator to skip all the
+ questions about Alacritech devices. If you say Y, you will be asked
+ for your specific device in the following questions.
+
+if NET_VENDOR_ALACRITECH
+
+config SLICOSS
+   tristate "Alacritech Slicoss support"
+   depends on PCI
+   select CRC32
+   ---help---
+ This driver supports Gigabit Ethernet adapters based on the
+ Session Layer Interface (SLIC) technology by Alacritech.
+
+ Supported are Mojave (1 port) and Oasis (1, 2 and 4 port) cards,
+ both copper and fiber.
+
+ To compile this driver as a module, choose M here: the module
+ will be called slicoss. This is recommended.
+
+endif # NET_VENDOR_ALACRITECH
diff --git a/drivers/net/ethernet/alacritech/Makefile 
b/drivers/net/ethernet/alacritech/Makefile
new file mode 100644
index 000..8790e9e
--- /dev/null
+++ b/drivers/net/ethernet/alacritech/Makefile
@@ -0,0 +1,4 @@
+#
+# Makefile for the Alacritech Slicoss driver
+#
+obj-$(CONFIG_SLICOSS) += slicoss.o
diff --git a/drivers/net/ethernet/alacritech/slic.h 
b/drivers/net/ethernet/alacritech/slic.h
new file mode 100644
index 000..08931b4
--- /dev/null
+++ b/drivers/net/ethernet/alacritech/slic.h
@@ -0,0 +1,575 @@
+
+#ifndef _SLIC_H
+#define _SLIC_H
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define SLIC_VGBSTAT_XPERR 0x4000
+#define SLIC_VGBSTAT_XERRSHFT  25
+#define SLIC_VGBSTAT_XCSERR0x23
+#define SLIC_VGBSTAT_XUFLOW0x22
+#define SLIC_VGBSTAT_XHLEN 0x20
+#define SLIC_VGBSTAT_NETERR0x0100
+#define SLIC_VGBSTAT_NERRSHFT  16
+#define SLIC_VGBSTAT_NERRMSK   0x1ff
+#define SLIC_VGBSTAT_NCSERR0x103
+#define SLIC_VGBSTAT_NUFLOW0x102
+#define SLIC_VGBSTAT_NHLEN 0x100
+#define SLIC_VGBSTAT_LNKERR0x0080
+#define SLIC_VGBSTAT_LERRMSK   0xff
+#define SLIC_VGBSTAT_LDEARLY   0x86
+#define SLIC_VGBSTAT_LBOFLO0x85
+#define SLIC_VGBSTAT_LCODERR   0x84
+#define SLIC_VGBSTAT_LDBLNBL   0x83
+#define SLIC_VGBSTAT_LCRCERR   0x82
+#define SLIC_VGBSTAT_LOFLO 0x81
+#define SLIC_VGBSTAT_LUFLO 0x80
+
+#define 

Re: [lustre-devel] [PATCH 3/6] staging: lustre: obdclass: Create a header for obdo related functions

[Dan Carpenter]

Sorry, I was unclear.  I have no problem with white space changes on
their own or when they are on the same line as something else you're
changing.

What I meant is that when you're just moving functions around then don't
mix unrelated white space changes into that patch.  I have automated
scripts for reviewing moving code around but slight changes mean that I
have to review it manually line by line to spot the difference.  I can
review a one liner cleanup in about 10 seconds but it's finding the line
which changed that's the problem in this case.

And I'm also fine with this patch since I already reviewed it, but in
the future, please avoid the temptation to do cleanups until after.

regards,
dan carpenter

Re: [PATCH] iommu/intel: disable DMAR for Q35 integrated gfx

[David Woodhouse]

On Mon, 2016-12-05 at 13:58 -0800, Kees Cook wrote:
> This blacklists the Q35 integrated graphics so IOMMU can be otherwise
> enabled. Without this, a Q35 system can only enable IOMMU when booting
> with "intel_iommu=on,igfx_off" but not "intel_iommu=on".

Hm, is this definitely the same bug? Or is it something different, and
perhaps a BIOS issue? There are many of those...

-- 
dwmw2

smime.p7s
Description: S/MIME cryptographic signature

Re: [lustre-devel] [PATCH 3/6] staging: lustre: obdclass: Create a header for obdo related functions

[Dan Carpenter]

Sorry, I was unclear.  I have no problem with white space changes on
their own or when they are on the same line as something else you're
changing.

What I meant is that when you're just moving functions around then don't
mix unrelated white space changes into that patch.  I have automated
scripts for reviewing moving code around but slight changes mean that I
have to review it manually line by line to spot the difference.  I can
review a one liner cleanup in about 10 seconds but it's finding the line
which changed that's the problem in this case.

And I'm also fine with this patch since I already reviewed it, but in
the future, please avoid the temptation to do cleanups until after.

regards,
dan carpenter

Re: [PATCH] iommu/intel: disable DMAR for Q35 integrated gfx

[David Woodhouse]

On Mon, 2016-12-05 at 13:58 -0800, Kees Cook wrote:
> This blacklists the Q35 integrated graphics so IOMMU can be otherwise
> enabled. Without this, a Q35 system can only enable IOMMU when booting
> with "intel_iommu=on,igfx_off" but not "intel_iommu=on".

Hm, is this definitely the same bug? Or is it something different, and
perhaps a BIOS issue? There are many of those...

-- 
dwmw2

smime.p7s
Description: S/MIME cryptographic signature

Re: [PATCH] scsi: hpsa: use %phN for short hex dumps

[Martin K. Petersen]

> "Rasmus" == Rasmus Villemoes  writes:

Rasmus> Passing one instead of 8 or 16 arguments reduces the size of the
Rasmus> generated code somewhat:

Rasmus> add/remove: 2/3 grow/shrink: 1/4 up/down: 1772/-2137 (-365)

Rasmus> There's one more candidate, unique_id_show, but that uses %02X,
Rasmus> and I'm not sure it would be ok to start using lowercase there,
Rasmus> so I've left it alone for now.

Applied to 4.10/scsi-queue.

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH] scsi: hpsa: use %phN for short hex dumps

[Martin K. Petersen]

> "Rasmus" == Rasmus Villemoes  writes:

Rasmus> Passing one instead of 8 or 16 arguments reduces the size of the
Rasmus> generated code somewhat:

Rasmus> add/remove: 2/3 grow/shrink: 1/4 up/down: 1772/-2137 (-365)

Rasmus> There's one more candidate, unique_id_show, but that uses %02X,
Rasmus> and I'm not sure it would be ok to start using lowercase there,
Rasmus> so I've left it alone for now.

Applied to 4.10/scsi-queue.

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH 1/4] rtc: mcp795: fix invalid month setting.

[Emil Bartczak]

Hi,

On Mon, Dec 05, 2016 at 04:09:59PM +0100, Alexandre Belloni wrote:
> Hi,
> 
> On 05/12/2016 at 14:11:50 +0100, Emil Bartczak wrote :
> > The 10 month register was always set to value 0 in the RTC hardware.
> > Due to the bug month November or December became February.
> 
> All your patches are missing your SoB, see Developer's Certificate of
> Origin 1.1 in Documentation/SubmittingPatches
Ok, I will fix it in the next patchset. Sorry for that simple mistakes but 
I'm newbie in sending patches.

> 
> > ---
> >  drivers/rtc/rtc-mcp795.c | 12 +++-
> >  1 file changed, 7 insertions(+), 5 deletions(-)
> > 
> > diff --git a/drivers/rtc/rtc-mcp795.c b/drivers/rtc/rtc-mcp795.c
> > index 4021fd0..266328b 100644
> > --- a/drivers/rtc/rtc-mcp795.c
> > +++ b/drivers/rtc/rtc-mcp795.c
> > @@ -29,7 +29,7 @@
> >  #define MCP795_EEWREN  0x06
> >  #define MCP795_SRREAD  0x05
> >  #define MCP795_SRWRITE 0x01
> > -#define MCP795_READ0x13
> > +#define MCP795_READ0x13
> 
> Unrelated change
Ok, I will remove it from patch.

> 
> >  #define MCP795_WRITE   0x12
> >  #define MCP795_UNLOCK  0x14
> >  #define MCP795_IDWRITE 0x32
> > @@ -39,6 +39,7 @@
> >  
> >  #define MCP795_ST_BIT  0x80
> >  #define MCP795_24_BIT  0x40
> > +#define MCP795_LP_BIT  0x20
> >  
> >  static int mcp795_rtcc_read(struct device *dev, u8 addr, u8 *buf, u8 count)
> >  {
> > @@ -108,7 +109,8 @@ static int mcp795_set_time(struct device *dev, struct 
> > rtc_time *tim)
> > data[1] = (data[1] & 0x80) | ((tim->tm_min / 10) << 4) | (tim->tm_min % 
> > 10);
> > data[2] = ((tim->tm_hour / 10) << 4) | (tim->tm_hour % 10);
> > data[4] = ((tim->tm_mday / 10) << 4) | ((tim->tm_mday) % 10);
> > -   data[5] = (data[5] & 0x10) | (tim->tm_mon / 10) | (tim->tm_mon % 10);
> > +   data[5] = (data[5] & MCP795_LP_BIT) |
> 
> You changed 0x10 in MCP795_LP_BIT which you defined as 0x20, is that
> right?
Yes, it should be 0x20 (checked in datasheet).

> 
> This is also an unrelated change.
> 
> > +   ((tim->tm_mon / 10) << 4) | (tim->tm_mon % 10);
What do you mean exactly? 
That above line of code was moved to the new line? Or that I added
shift left operation (tim->tm_mon / 10) << 4)?
Changing 0x10 to 0x20 and adding shift right operation fixes the problem.

> >  
> > if (tim->tm_year > 100)
> > tim->tm_year -= 100;
> > @@ -137,11 +139,11 @@ static int mcp795_read_time(struct device *dev, 
> > struct rtc_time *tim)
> > if (ret)
> > return ret;
> >  
> > -   tim->tm_sec = ((data[0] & 0x70) >> 4) * 10 + (data[0] & 
> > 0x0f);
> > -   tim->tm_min = ((data[1] & 0x70) >> 4) * 10 + (data[1] & 
> > 0x0f);
> > +   tim->tm_sec = ((data[0] & 0x70) >> 4) * 10 + (data[0] & 0x0f);
> > +   tim->tm_min = ((data[1] & 0x70) >> 4) * 10 + (data[1] & 0x0f);
> > tim->tm_hour= ((data[2] & 0x30) >> 4) * 10 + (data[2] & 0x0f);
> > tim->tm_mday= ((data[4] & 0x30) >> 4) * 10 + (data[4] & 0x0f);
> > -   tim->tm_mon = ((data[5] & 0x10) >> 4) * 10 + (data[5] & 
> > 0x0f);
> > +   tim->tm_mon = ((data[5] & 0x10) >> 4) * 10 + (data[5] & 0x0f);
> 
> All those whitespace changes are actually confusing. Please do them in a
> separate patch or in your last patch.
Ok, I will have a separate patch for them.
> 
> > tim->tm_year= ((data[6] & 0xf0) >> 4) * 10 + (data[6] & 0x0f) + 
> > 100; /* Assume we are in 20xx */
> >  
> > dev_dbg(dev, "Read from mcp795: %04d-%02d-%02d %02d:%02d:%02d\n",
> > -- 
> > 2.7.4
> > 
> 
> -- 
> Alexandre Belloni, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com

Cheers,
Emil

Re: [PATCH 1/4] rtc: mcp795: fix invalid month setting.

[Emil Bartczak]

Hi,

On Mon, Dec 05, 2016 at 04:09:59PM +0100, Alexandre Belloni wrote:
> Hi,
> 
> On 05/12/2016 at 14:11:50 +0100, Emil Bartczak wrote :
> > The 10 month register was always set to value 0 in the RTC hardware.
> > Due to the bug month November or December became February.
> 
> All your patches are missing your SoB, see Developer's Certificate of
> Origin 1.1 in Documentation/SubmittingPatches
Ok, I will fix it in the next patchset. Sorry for that simple mistakes but 
I'm newbie in sending patches.

> 
> > ---
> >  drivers/rtc/rtc-mcp795.c | 12 +++-
> >  1 file changed, 7 insertions(+), 5 deletions(-)
> > 
> > diff --git a/drivers/rtc/rtc-mcp795.c b/drivers/rtc/rtc-mcp795.c
> > index 4021fd0..266328b 100644
> > --- a/drivers/rtc/rtc-mcp795.c
> > +++ b/drivers/rtc/rtc-mcp795.c
> > @@ -29,7 +29,7 @@
> >  #define MCP795_EEWREN  0x06
> >  #define MCP795_SRREAD  0x05
> >  #define MCP795_SRWRITE 0x01
> > -#define MCP795_READ0x13
> > +#define MCP795_READ0x13
> 
> Unrelated change
Ok, I will remove it from patch.

> 
> >  #define MCP795_WRITE   0x12
> >  #define MCP795_UNLOCK  0x14
> >  #define MCP795_IDWRITE 0x32
> > @@ -39,6 +39,7 @@
> >  
> >  #define MCP795_ST_BIT  0x80
> >  #define MCP795_24_BIT  0x40
> > +#define MCP795_LP_BIT  0x20
> >  
> >  static int mcp795_rtcc_read(struct device *dev, u8 addr, u8 *buf, u8 count)
> >  {
> > @@ -108,7 +109,8 @@ static int mcp795_set_time(struct device *dev, struct 
> > rtc_time *tim)
> > data[1] = (data[1] & 0x80) | ((tim->tm_min / 10) << 4) | (tim->tm_min % 
> > 10);
> > data[2] = ((tim->tm_hour / 10) << 4) | (tim->tm_hour % 10);
> > data[4] = ((tim->tm_mday / 10) << 4) | ((tim->tm_mday) % 10);
> > -   data[5] = (data[5] & 0x10) | (tim->tm_mon / 10) | (tim->tm_mon % 10);
> > +   data[5] = (data[5] & MCP795_LP_BIT) |
> 
> You changed 0x10 in MCP795_LP_BIT which you defined as 0x20, is that
> right?
Yes, it should be 0x20 (checked in datasheet).

> 
> This is also an unrelated change.
> 
> > +   ((tim->tm_mon / 10) << 4) | (tim->tm_mon % 10);
What do you mean exactly? 
That above line of code was moved to the new line? Or that I added
shift left operation (tim->tm_mon / 10) << 4)?
Changing 0x10 to 0x20 and adding shift right operation fixes the problem.

> >  
> > if (tim->tm_year > 100)
> > tim->tm_year -= 100;
> > @@ -137,11 +139,11 @@ static int mcp795_read_time(struct device *dev, 
> > struct rtc_time *tim)
> > if (ret)
> > return ret;
> >  
> > -   tim->tm_sec = ((data[0] & 0x70) >> 4) * 10 + (data[0] & 
> > 0x0f);
> > -   tim->tm_min = ((data[1] & 0x70) >> 4) * 10 + (data[1] & 
> > 0x0f);
> > +   tim->tm_sec = ((data[0] & 0x70) >> 4) * 10 + (data[0] & 0x0f);
> > +   tim->tm_min = ((data[1] & 0x70) >> 4) * 10 + (data[1] & 0x0f);
> > tim->tm_hour= ((data[2] & 0x30) >> 4) * 10 + (data[2] & 0x0f);
> > tim->tm_mday= ((data[4] & 0x30) >> 4) * 10 + (data[4] & 0x0f);
> > -   tim->tm_mon = ((data[5] & 0x10) >> 4) * 10 + (data[5] & 
> > 0x0f);
> > +   tim->tm_mon = ((data[5] & 0x10) >> 4) * 10 + (data[5] & 0x0f);
> 
> All those whitespace changes are actually confusing. Please do them in a
> separate patch or in your last patch.
Ok, I will have a separate patch for them.
> 
> > tim->tm_year= ((data[6] & 0xf0) >> 4) * 10 + (data[6] & 0x0f) + 
> > 100; /* Assume we are in 20xx */
> >  
> > dev_dbg(dev, "Read from mcp795: %04d-%02d-%02d %02d:%02d:%02d\n",
> > -- 
> > 2.7.4
> > 
> 
> -- 
> Alexandre Belloni, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com

Cheers,
Emil

[PATCH] iommu/intel: disable DMAR for Q35 integrated gfx

[Kees Cook]

This blacklists the Q35 integrated graphics so IOMMU can be otherwise
enabled. Without this, a Q35 system can only enable IOMMU when booting
with "intel_iommu=on,igfx_off" but not "intel_iommu=on".

00:02.0 0300: 8086:29b2 (rev 02) (prog-if 00 [VGA controller])
Subsystem: 8086:4f4a
Flags: bus master, fast devsel, latency 0, IRQ 32
Memory at e038 (32-bit, non-prefetchable) [size=512K]
I/O ports at 2460 [size=8]
Memory at d000 (32-bit, prefetchable) [size=256M]
Memory at e020 (32-bit, non-prefetchable) [size=1M]
Expansion ROM at  [disabled]
Capabilities: 
Kernel driver in use: i915
Kernel modules: i915

Signed-off-by: Kees Cook 
---
 drivers/iommu/intel-iommu.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index d8376c2d18b3..24e5b06834ae 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -5327,6 +5327,7 @@ static void quirk_iommu_g4x_gfx(struct pci_dev *dev)
dmar_map_gfx = 0;
 }
 
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x29b2, quirk_iommu_g4x_gfx);
 DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2a40, quirk_iommu_g4x_gfx);
 DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e00, quirk_iommu_g4x_gfx);
 DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e10, quirk_iommu_g4x_gfx);
-- 
2.7.4


-- 
Kees Cook
Nexus Security

[PATCH] iommu/intel: disable DMAR for Q35 integrated gfx

[Kees Cook]

This blacklists the Q35 integrated graphics so IOMMU can be otherwise
enabled. Without this, a Q35 system can only enable IOMMU when booting
with "intel_iommu=on,igfx_off" but not "intel_iommu=on".

00:02.0 0300: 8086:29b2 (rev 02) (prog-if 00 [VGA controller])
Subsystem: 8086:4f4a
Flags: bus master, fast devsel, latency 0, IRQ 32
Memory at e038 (32-bit, non-prefetchable) [size=512K]
I/O ports at 2460 [size=8]
Memory at d000 (32-bit, prefetchable) [size=256M]
Memory at e020 (32-bit, non-prefetchable) [size=1M]
Expansion ROM at  [disabled]
Capabilities: 
Kernel driver in use: i915
Kernel modules: i915

Signed-off-by: Kees Cook 
---
 drivers/iommu/intel-iommu.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index d8376c2d18b3..24e5b06834ae 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -5327,6 +5327,7 @@ static void quirk_iommu_g4x_gfx(struct pci_dev *dev)
dmar_map_gfx = 0;
 }
 
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x29b2, quirk_iommu_g4x_gfx);
 DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2a40, quirk_iommu_g4x_gfx);
 DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e00, quirk_iommu_g4x_gfx);
 DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e10, quirk_iommu_g4x_gfx);
-- 
2.7.4


-- 
Kees Cook
Nexus Security

Re: [PATCH] scsi: hisi_sas: fix free'ing in probe and remove

[Martin K. Petersen]

> "John" == John Garry  writes:

John> This patch addresses 4 problems in the module probe/remove:
John> - When hisi_sas_shost_alloc() fails after we alloc shost memory,
John> we should free shost memory before the function returns.
John> - When hisi_sas_probe() fails after we alloc the HBA memories,
John> we should also free the HBA memories.
John> - We should free shost memory at the end of hisi_sas_remove().
John> - sha->core.shost is set twice, so remove extra set.

Applied to 4.10/scsi-queue.

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [lustre-devel] [PATCH 3/6] staging: lustre: obdclass: Create a header for obdo related functions

[Dilger, Andreas]

> On Dec 5, 2016, at 13:50, Dan Carpenter  wrote:
> 
> On Fri, Dec 02, 2016 at 02:40:47PM -0500, James Simmons wrote:
>> -__u32 local_flags = 0;
>> +u32 local_flags = 0;
> 
>> -if (local_flags != 0) {
>> +if (local_flags) {
> 
> Please avoid these unrelated white space changes.

Some projects (e.g. ext4 that I work with most) allow whitespace changes
as part of related changes to the code, since the code is being modified
anyway, and frown upon whitespace-only changes because they cause churn
in the code and otherwise introduce patch merge conflicts for relatively
minor benefits by themselves.

My preference is to allow whitespace cleanups in code being modified as
part of a patch that is making other fixes, since a few whitespace changes
don't typically make it any harder to review the patch.  If it gets so
far as moving blocks of code between files and this doesn't appear cleanly
in the patch then I'd ask for a separate patch.

Cheers, Andreas

Re: [PATCH] scsi: hisi_sas: fix free'ing in probe and remove

[Martin K. Petersen]

> "John" == John Garry  writes:

John> This patch addresses 4 problems in the module probe/remove:
John> - When hisi_sas_shost_alloc() fails after we alloc shost memory,
John> we should free shost memory before the function returns.
John> - When hisi_sas_probe() fails after we alloc the HBA memories,
John> we should also free the HBA memories.
John> - We should free shost memory at the end of hisi_sas_remove().
John> - sha->core.shost is set twice, so remove extra set.

Applied to 4.10/scsi-queue.

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [lustre-devel] [PATCH 3/6] staging: lustre: obdclass: Create a header for obdo related functions

[Dilger, Andreas]

> On Dec 5, 2016, at 13:50, Dan Carpenter  wrote:
> 
> On Fri, Dec 02, 2016 at 02:40:47PM -0500, James Simmons wrote:
>> -__u32 local_flags = 0;
>> +u32 local_flags = 0;
> 
>> -if (local_flags != 0) {
>> +if (local_flags) {
> 
> Please avoid these unrelated white space changes.

Some projects (e.g. ext4 that I work with most) allow whitespace changes
as part of related changes to the code, since the code is being modified
anyway, and frown upon whitespace-only changes because they cause churn
in the code and otherwise introduce patch merge conflicts for relatively
minor benefits by themselves.

My preference is to allow whitespace cleanups in code being modified as
part of a patch that is making other fixes, since a few whitespace changes
don't typically make it any harder to review the patch.  If it gets so
far as moving blocks of code between files and this doesn't appear cleanly
in the patch then I'd ask for a separate patch.

Cheers, Andreas

Re: [PATCH v3] PCI/ACPI: xgene: Add ECAM quirk for X-Gene PCIe controller

[Bjorn Helgaas]

On Thu, Dec 01, 2016 at 06:52:23PM -0800, Duc Dang wrote:
> On Thu, Dec 1, 2016 at 10:33 AM, Bjorn Helgaas  wrote:

> I made similar changes in v4 patch. The ECAM quirk will be built when
> ACPI and PCI_QUIRKS are enabled.
> 
> When building for DT only, the ECAM quirk won't be compiled.

Perfect.

> >>  #define XGENE_PCIE_IP_VER_UNKN   0
> >>  #define XGENE_PCIE_IP_VER_1  1
> >> +#define XGENE_PCIE_IP_VER_2  2
> >
> > This isn't used anywhere, which makes me wonder whether it's worth
> > keeping it.
> 
> V2 controller will use this XGENE_PCIE_IP_VER_2 (port->version =
> XGENE_PCIE_IP_VER_2). This will be used to indicate that the
> controller is V2, and to enable configuration request retry status
> feature (by not disable it like V1 controller).

OK, I see.  You don't actually need XGENE_PCIE_IP_VER_2, you just need
port->version to be something other than XGENE_PCIE_IP_VER_1.  So this
is fine as it is.

> >>  static void __iomem *xgene_pcie_get_cfg_base(struct pci_bus *bus)
> >>  {
> >> - struct xgene_pcie_port *port = bus->sysdata;
> >> + struct pci_config_window *cfg;
> >> + struct xgene_pcie_port *port;
> >> +
> >> + if (acpi_disabled)
> >> + port = bus->sysdata;
> >> + else {
> >> + cfg = bus->sysdata;
> >> + port = cfg->priv;
> >> + }
> >
> > I would really, really like to figure out a way to get rid of these
> > "if (acpi_disabled)" checks sprinkled through here.  Is there any way
> > we can set up bus->sysdata to be the same, regardless of whether we're
> > using this as a platform driver or an ACPI quirk?
> 
> Right now, I created a inline function to extract xgene_pcie_port from
> pci_bus. In order to get rid of acpi_disabled, I will need to make
> sysdata in DT case also point to pci_config_window structure, which
> means I will need to convert and test the DT driver to use ecam ops.
> It is a separate patch itself. So I think I should do it at later time
> (after this ECAM quirk patch). I hope you are ok with this.

OK.  I did the simple-minded version of leaving the DT ops the same
but making sysdata point to a dummy pci_config_window.  Your proposal
of using ECAM for DT would be much better.

It's interesting that you actually already use the same accessors
except that DT uses the 32-bit pci_generic_config_write32() and ACPI
uses the regular pci_generic_config_write(). I guess that means the
hardware actually *does* support sub-32 bit writes?

> I need to define the function (xgene_get_csr_resource()) inside
> pci-xgene.c to duplicate the code of acpi_get_rc_addr. The reason is
> X-Gene firmware does not have a dedicate PNP0C02 node to declare the
> resource, and if I use acpi_get_rc_resources() with "PNP0A08", I got
> error due to acpi_bus_get_device() returns error.

Looks good.

> > All these init functions are almost identical.  Can we factor this out
> > by having wrappers that do nothing more than pass in the table and
> > version, and put the kzalloc and ioremap in a shared back-end?
> 
> I refactor-ed these .init functions. And as a result, there are only 2
> ecam ops left: xgene_v1_pcie_ecam_ops and xgene_v2_pcie_ecam_ops.

Looks good.

Bjorn

Re: [PATCH v3] PCI/ACPI: xgene: Add ECAM quirk for X-Gene PCIe controller

[Bjorn Helgaas]

On Thu, Dec 01, 2016 at 06:52:23PM -0800, Duc Dang wrote:
> On Thu, Dec 1, 2016 at 10:33 AM, Bjorn Helgaas  wrote:

> I made similar changes in v4 patch. The ECAM quirk will be built when
> ACPI and PCI_QUIRKS are enabled.
> 
> When building for DT only, the ECAM quirk won't be compiled.

Perfect.

> >>  #define XGENE_PCIE_IP_VER_UNKN   0
> >>  #define XGENE_PCIE_IP_VER_1  1
> >> +#define XGENE_PCIE_IP_VER_2  2
> >
> > This isn't used anywhere, which makes me wonder whether it's worth
> > keeping it.
> 
> V2 controller will use this XGENE_PCIE_IP_VER_2 (port->version =
> XGENE_PCIE_IP_VER_2). This will be used to indicate that the
> controller is V2, and to enable configuration request retry status
> feature (by not disable it like V1 controller).

OK, I see.  You don't actually need XGENE_PCIE_IP_VER_2, you just need
port->version to be something other than XGENE_PCIE_IP_VER_1.  So this
is fine as it is.

> >>  static void __iomem *xgene_pcie_get_cfg_base(struct pci_bus *bus)
> >>  {
> >> - struct xgene_pcie_port *port = bus->sysdata;
> >> + struct pci_config_window *cfg;
> >> + struct xgene_pcie_port *port;
> >> +
> >> + if (acpi_disabled)
> >> + port = bus->sysdata;
> >> + else {
> >> + cfg = bus->sysdata;
> >> + port = cfg->priv;
> >> + }
> >
> > I would really, really like to figure out a way to get rid of these
> > "if (acpi_disabled)" checks sprinkled through here.  Is there any way
> > we can set up bus->sysdata to be the same, regardless of whether we're
> > using this as a platform driver or an ACPI quirk?
> 
> Right now, I created a inline function to extract xgene_pcie_port from
> pci_bus. In order to get rid of acpi_disabled, I will need to make
> sysdata in DT case also point to pci_config_window structure, which
> means I will need to convert and test the DT driver to use ecam ops.
> It is a separate patch itself. So I think I should do it at later time
> (after this ECAM quirk patch). I hope you are ok with this.

OK.  I did the simple-minded version of leaving the DT ops the same
but making sysdata point to a dummy pci_config_window.  Your proposal
of using ECAM for DT would be much better.

It's interesting that you actually already use the same accessors
except that DT uses the 32-bit pci_generic_config_write32() and ACPI
uses the regular pci_generic_config_write(). I guess that means the
hardware actually *does* support sub-32 bit writes?

> I need to define the function (xgene_get_csr_resource()) inside
> pci-xgene.c to duplicate the code of acpi_get_rc_addr. The reason is
> X-Gene firmware does not have a dedicate PNP0C02 node to declare the
> resource, and if I use acpi_get_rc_resources() with "PNP0A08", I got
> error due to acpi_bus_get_device() returns error.

Looks good.

> > All these init functions are almost identical.  Can we factor this out
> > by having wrappers that do nothing more than pass in the table and
> > version, and put the kzalloc and ioremap in a shared back-end?
> 
> I refactor-ed these .init functions. And as a result, there are only 2
> ecam ops left: xgene_v1_pcie_ecam_ops and xgene_v2_pcie_ecam_ops.

Looks good.

Bjorn

RE: [tpmdd-devel] [PATCH v2 3/3] tpm_crb: request and relinquish locality 0

[Winkler, Tomas]

> 
> CC linux-security-module
> 
> On Sat, Dec 03, 2016 at 07:52:13PM +0200, Jarkko Sakkinen wrote:
> > Request and relinquish locality for the driver use in order to be a
> > better citizen in a multi locality environment like TXT. The locality
> > is requested and relinquished as part of going into and waking up from
> > idle.
> 
This has nothing to do with power management, please note, that this is run via 
runtime_pm handlers, 
which can be disabled  via sysfs and actually on server platforms runtime pm is 
not relevant, 
while you cannot disable locality acquire/relinquish flow.

NACK
> > Signed-off-by: Jarkko Sakkinen 
> > ---
> >  drivers/char/tpm/tpm_crb.c | 36 
> >  1 file changed, 24 insertions(+), 12 deletions(-)
> >
> > diff --git a/drivers/char/tpm/tpm_crb.c b/drivers/char/tpm/tpm_crb.c
> > index f986d02..f6e0beb 100644
> > --- a/drivers/char/tpm/tpm_crb.c
> > +++ b/drivers/char/tpm/tpm_crb.c
> > @@ -34,6 +34,15 @@ enum crb_defaults {
> > CRB_ACPI_START_INDEX = 1,
> >  };
> >
> > +enum crb_loc_ctrl {
> > +   CRB_LOC_CTRL_REQUEST_ACCESS = BIT(0),
> > +   CRB_LOC_CTRL_RELINQUISH = BIT(1),
> > +};
> > +
> > +enum crb_loc_state {
> > +   CRB_LOC_STATE_LOC_ASSIGNED  = BIT(1),
> > +};
> > +
> >  enum crb_ctrl_req {
> > CRB_CTRL_REQ_CMD_READY  = BIT(0),
> > CRB_CTRL_REQ_GO_IDLE= BIT(1),
> > @@ -101,12 +110,8 @@ struct crb_priv {
> >   * @dev:  crb device
> >   * @priv: crb private data
> >   *
> > - * Write CRB_CTRL_REQ_GO_IDLE to TPM_CRB_CTRL_REQ
> > - * The device should respond within TIMEOUT_C by clearing the bit.
> > - * Anyhow, we do not wait here as a consequent CMD_READY request
> > - * will be handled correctly even if idle was not completed.
> > - *
> > - * The function does nothing for devices with ACPI-start method.
> > + * Put device to the idle state and relinquish locality. The function
> > + does
> > + * nothing for devices with the ACPI-start method.
> >   *
> >   * Return: 0 always
> >   */
> > @@ -115,6 +120,7 @@ static int __maybe_unused crb_go_idle(struct device
> *dev, struct crb_priv *priv)
> > if (priv->flags & CRB_FL_ACPI_START)
> > return 0;
> >
> > +   iowrite32(CRB_LOC_CTRL_RELINQUISH, >regs_h->loc_ctrl);
This is misleading this has nothing to do with go idle,  what is the 
> > iowrite32(CRB_CTRL_REQ_GO_IDLE, >regs_t->ctrl_req);
> > /* we don't really care when this settles */
> >
> > @@ -146,11 +152,8 @@ static bool crb_wait_for_reg_32(u32 __iomem *reg,
> u32 mask, u32 value,
> >   * @dev:  crb device
> >   * @priv: crb private data
> >   *
> > - * Write CRB_CTRL_REQ_CMD_READY to TPM_CRB_CTRL_REQ
> > - * and poll till the device acknowledge it by clearing the bit.
> > - * The device should respond within TIMEOUT_C.
> > - *
> > - * The function does nothing for devices with ACPI-start method
> > + * Try to wake up the device and request locality. The function does
> > + nothing
> > + * for devices with the ACPI-start method.
> >   *
> >   * Return: 0 on success -ETIME on timeout;
> >   */
> > @@ -165,7 +168,16 @@ static int __maybe_unused crb_cmd_ready(struct
> device *dev,
> >  CRB_CTRL_REQ_CMD_READY /* mask */,
> >  0, /* value */
> >  TPM2_TIMEOUT_C)) {
> > -   dev_warn(dev, "cmdReady timed out\n");
> > +   dev_warn(dev, "TPM_CRB_CTRL_REQ_x.cmdReady timed
> out\n");
We are always in locality 0 here, right?

> > +   return -ETIME;
> > +   }
> > +
> > +   iowrite32(CRB_LOC_CTRL_REQUEST_ACCESS, >regs_h-
> >loc_ctrl);
> > +   if (!crb_wait_for_reg_32(>regs_h->loc_state,
> > +CRB_LOC_STATE_LOC_ASSIGNED, /* mask */
> > +CRB_LOC_STATE_LOC_ASSIGNED, /* value */
> > +TPM2_TIMEOUT_C)) {
> > +   dev_warn(dev, "TPM_LOC_STATE_x.requestAccess timed
> out\n");


> > return -ETIME;
> > }
 

RE: [tpmdd-devel] [PATCH v2 3/3] tpm_crb: request and relinquish locality 0

[Winkler, Tomas]

> 
> CC linux-security-module
> 
> On Sat, Dec 03, 2016 at 07:52:13PM +0200, Jarkko Sakkinen wrote:
> > Request and relinquish locality for the driver use in order to be a
> > better citizen in a multi locality environment like TXT. The locality
> > is requested and relinquished as part of going into and waking up from
> > idle.
> 
This has nothing to do with power management, please note, that this is run via 
runtime_pm handlers, 
which can be disabled  via sysfs and actually on server platforms runtime pm is 
not relevant, 
while you cannot disable locality acquire/relinquish flow.

NACK
> > Signed-off-by: Jarkko Sakkinen 
> > ---
> >  drivers/char/tpm/tpm_crb.c | 36 
> >  1 file changed, 24 insertions(+), 12 deletions(-)
> >
> > diff --git a/drivers/char/tpm/tpm_crb.c b/drivers/char/tpm/tpm_crb.c
> > index f986d02..f6e0beb 100644
> > --- a/drivers/char/tpm/tpm_crb.c
> > +++ b/drivers/char/tpm/tpm_crb.c
> > @@ -34,6 +34,15 @@ enum crb_defaults {
> > CRB_ACPI_START_INDEX = 1,
> >  };
> >
> > +enum crb_loc_ctrl {
> > +   CRB_LOC_CTRL_REQUEST_ACCESS = BIT(0),
> > +   CRB_LOC_CTRL_RELINQUISH = BIT(1),
> > +};
> > +
> > +enum crb_loc_state {
> > +   CRB_LOC_STATE_LOC_ASSIGNED  = BIT(1),
> > +};
> > +
> >  enum crb_ctrl_req {
> > CRB_CTRL_REQ_CMD_READY  = BIT(0),
> > CRB_CTRL_REQ_GO_IDLE= BIT(1),
> > @@ -101,12 +110,8 @@ struct crb_priv {
> >   * @dev:  crb device
> >   * @priv: crb private data
> >   *
> > - * Write CRB_CTRL_REQ_GO_IDLE to TPM_CRB_CTRL_REQ
> > - * The device should respond within TIMEOUT_C by clearing the bit.
> > - * Anyhow, we do not wait here as a consequent CMD_READY request
> > - * will be handled correctly even if idle was not completed.
> > - *
> > - * The function does nothing for devices with ACPI-start method.
> > + * Put device to the idle state and relinquish locality. The function
> > + does
> > + * nothing for devices with the ACPI-start method.
> >   *
> >   * Return: 0 always
> >   */
> > @@ -115,6 +120,7 @@ static int __maybe_unused crb_go_idle(struct device
> *dev, struct crb_priv *priv)
> > if (priv->flags & CRB_FL_ACPI_START)
> > return 0;
> >
> > +   iowrite32(CRB_LOC_CTRL_RELINQUISH, >regs_h->loc_ctrl);
This is misleading this has nothing to do with go idle,  what is the 
> > iowrite32(CRB_CTRL_REQ_GO_IDLE, >regs_t->ctrl_req);
> > /* we don't really care when this settles */
> >
> > @@ -146,11 +152,8 @@ static bool crb_wait_for_reg_32(u32 __iomem *reg,
> u32 mask, u32 value,
> >   * @dev:  crb device
> >   * @priv: crb private data
> >   *
> > - * Write CRB_CTRL_REQ_CMD_READY to TPM_CRB_CTRL_REQ
> > - * and poll till the device acknowledge it by clearing the bit.
> > - * The device should respond within TIMEOUT_C.
> > - *
> > - * The function does nothing for devices with ACPI-start method
> > + * Try to wake up the device and request locality. The function does
> > + nothing
> > + * for devices with the ACPI-start method.
> >   *
> >   * Return: 0 on success -ETIME on timeout;
> >   */
> > @@ -165,7 +168,16 @@ static int __maybe_unused crb_cmd_ready(struct
> device *dev,
> >  CRB_CTRL_REQ_CMD_READY /* mask */,
> >  0, /* value */
> >  TPM2_TIMEOUT_C)) {
> > -   dev_warn(dev, "cmdReady timed out\n");
> > +   dev_warn(dev, "TPM_CRB_CTRL_REQ_x.cmdReady timed
> out\n");
We are always in locality 0 here, right?

> > +   return -ETIME;
> > +   }
> > +
> > +   iowrite32(CRB_LOC_CTRL_REQUEST_ACCESS, >regs_h-
> >loc_ctrl);
> > +   if (!crb_wait_for_reg_32(>regs_h->loc_state,
> > +CRB_LOC_STATE_LOC_ASSIGNED, /* mask */
> > +CRB_LOC_STATE_LOC_ASSIGNED, /* value */
> > +TPM2_TIMEOUT_C)) {
> > +   dev_warn(dev, "TPM_LOC_STATE_x.requestAccess timed
> out\n");


> > return -ETIME;
> > }
 

Re: [PATCH v3 10/30] perf clang: Add builtin clang support ant test case

[Arnaldo Carvalho de Melo]

Em Mon, Dec 05, 2016 at 07:02:48PM -0200, Arnaldo Carvalho de Melo escreveu:
> Em Mon, Dec 05, 2016 at 08:51:01AM -0800, Alexei Starovoitov escreveu:
> > yeah. it's kinda high. I'm guessing rpm llvm libs are in debug mode.
> > Try llvm-config --build-mode --assertion-mode
> > it should be Release OFF
> 
> Probably this was with 3.9 and built from git, quite a while ago, now I
> removed it from /usr/local/ and installed what is in f25, but I fear it
> will be insufficient, does 3.8 cuts it for what we're testing? Humm, it
> looks like it will:
> 
> [root@jouet ~]# llc --version
> LLVM (http://llvm.org/):
>   LLVM version 3.8.0
> 
> But I'm now running the container based tests to send a pull req, will
> check later, after that.

Not really, Wang, we need to update that feature detection test to state what
is the minimum required LLVM/clang version, one that has those functions,
which, unfortunately, isn't the one in the latest fedora, fedora 25:

[acme@jouet linux]$ rpm -q llvm-devel clang-devel
llvm-devel-3.8.0-1.fc25.x86_64
clang-devel-3.8.0-2.fc25.x86_64
[acme@jouet linux]$ 


  LINK /tmp/build/perf/libperf-gtk.so
  INSTALL  GTK UI
/tmp/build/perf/libperf.a(libperf-in.o): In function 
`perf::createCompilerInvocation(llvm::SmallVector, 
llvm::StringRef&, clang::DiagnosticsEngine&)':
/home/acme/git/linux/tools/perf/util/c++/clang.cpp:56: undefined reference to 
`clang::tooling::newInvocation(clang::DiagnosticsEngine*, 
llvm::SmallVector const&)'
/tmp/build/perf/libperf.a(libperf-in.o): In function 
`perf::getModuleFromSource(llvm::SmallVector, 
llvm::StringRef, llvm::IntrusiveRefCntPtr)':
/home/acme/git/linux/tools/perf/util/c++/clang.cpp:68: undefined reference to 
`clang::CompilerInstance::CompilerInstance(std::shared_ptr,
 bool)'
/home/acme/git/linux/tools/perf/util/c++/clang.cpp:69: undefined reference to 
`clang::CompilerInstance::createDiagnostics(clang::DiagnosticConsumer*, bool)'
/home/acme/git/linux/tools/perf/util/c++/clang.cpp:76: undefined reference to 
`clang::CompilerInstance::setInvocation(clang::CompilerInvocation*)'
/home/acme/git/linux/tools/perf/util/c++/clang.cpp:78: undefined reference to 
`clang::EmitLLVMOnlyAction::EmitLLVMOnlyAction(llvm::LLVMContext*)'
/home/acme/git/linux/tools/perf/util/c++/clang.cpp:79: undefined reference to 
`clang::CompilerInstance::ExecuteAction(clang::FrontendAction&)'
/home/acme/git/linux/tools/perf/util/c++/clang.cpp:82: undefined reference to 
`clang::CodeGenAction::takeModule()'
/home/acme/git/linux/tools/perf/util/c++/clang.cpp:68: undefined reference to 
`clang::CompilerInstance::~CompilerInstance()'
/tmp/build/perf/libperf.a(libperf-in.o): In function 
`perf::getModuleFromSource(llvm::SmallVector, 
llvm::StringRef, llvm::StringRef)':
/home/acme/git/linux/tools/perf/util/c++/clang.cpp:92: undefined reference to 
`clang::vfs::getRealFileSystem()'
/home/acme/git/linux/tools/perf/util/c++/clang.cpp:92: undefined reference to 
`clang::vfs::OverlayFileSystem::OverlayFileSystem(llvm::IntrusiveRefCntPtr)'
/home/acme/git/linux/tools/perf/util/c++/clang.cpp:94: undefined reference to 
`clang::vfs::InMemoryFileSystem::InMemoryFileSystem(bool)'
/home/acme/git/linux/tools/perf/util/c++/clang.cpp:100: undefined reference to 
`clang::vfs::OverlayFileSystem::pushOverlay(llvm::IntrusiveRefCntPtr)'
/home/acme/git/linux/tools/perf/util/c++/clang.cpp:101: undefined reference to 
`clang::vfs::InMemoryFileSystem::addFile(llvm::Twine const&, long, 
std::unique_ptr)'
/tmp/build/perf/libperf.a(libperf-in.o): In function 
`perf::getModuleFromSource(llvm::SmallVector, 
llvm::StringRef)':
/home/acme/git/linux/tools/perf/util/c++/clang.cpp:109: undefined reference to 
`clang::vfs::getRealFileSystem()'
/tmp/build/perf/libperf.a(libperf-in.o): In function 
`clang::CompilerInvocation::~CompilerInvocation()':
/usr/include/clang/Frontend/CompilerInvocation.h:102: undefined reference to 
`clang::CompilerInvocationBase::~CompilerInvocationBase()'
/tmp/build/perf/libperf.a(libperf-in.o): In function `void 
__gnu_cxx::new_allocator::construct(clang::PCHContainerOperations*)':
/usr/include/c++/6.2.1/ext/new_allocator.h:120: undefined reference to 
`clang::PCHContainerOperations::PCHContainerOperations()'
collect2: error: ld returned 1 exit status
Makefile.perf:491: recipe for target '/tmp/build/perf/perf' failed
make[1]: *** [/tmp/build/perf/perf] Error 1
Makefile:108: recipe for target 'install-bin' failed
make: *** [install-bin] Error 2
make: Leaving directory '/home/acme/git/linux/tools/perf'
[acme@jouet linux]$

Re: [PATCH v3 10/30] perf clang: Add builtin clang support ant test case

[Arnaldo Carvalho de Melo]

Em Mon, Dec 05, 2016 at 07:02:48PM -0200, Arnaldo Carvalho de Melo escreveu:
> Em Mon, Dec 05, 2016 at 08:51:01AM -0800, Alexei Starovoitov escreveu:
> > yeah. it's kinda high. I'm guessing rpm llvm libs are in debug mode.
> > Try llvm-config --build-mode --assertion-mode
> > it should be Release OFF
> 
> Probably this was with 3.9 and built from git, quite a while ago, now I
> removed it from /usr/local/ and installed what is in f25, but I fear it
> will be insufficient, does 3.8 cuts it for what we're testing? Humm, it
> looks like it will:
> 
> [root@jouet ~]# llc --version
> LLVM (http://llvm.org/):
>   LLVM version 3.8.0
> 
> But I'm now running the container based tests to send a pull req, will
> check later, after that.

Not really, Wang, we need to update that feature detection test to state what
is the minimum required LLVM/clang version, one that has those functions,
which, unfortunately, isn't the one in the latest fedora, fedora 25:

[acme@jouet linux]$ rpm -q llvm-devel clang-devel
llvm-devel-3.8.0-1.fc25.x86_64
clang-devel-3.8.0-2.fc25.x86_64
[acme@jouet linux]$ 


  LINK /tmp/build/perf/libperf-gtk.so
  INSTALL  GTK UI
/tmp/build/perf/libperf.a(libperf-in.o): In function 
`perf::createCompilerInvocation(llvm::SmallVector, 
llvm::StringRef&, clang::DiagnosticsEngine&)':
/home/acme/git/linux/tools/perf/util/c++/clang.cpp:56: undefined reference to 
`clang::tooling::newInvocation(clang::DiagnosticsEngine*, 
llvm::SmallVector const&)'
/tmp/build/perf/libperf.a(libperf-in.o): In function 
`perf::getModuleFromSource(llvm::SmallVector, 
llvm::StringRef, llvm::IntrusiveRefCntPtr)':
/home/acme/git/linux/tools/perf/util/c++/clang.cpp:68: undefined reference to 
`clang::CompilerInstance::CompilerInstance(std::shared_ptr,
 bool)'
/home/acme/git/linux/tools/perf/util/c++/clang.cpp:69: undefined reference to 
`clang::CompilerInstance::createDiagnostics(clang::DiagnosticConsumer*, bool)'
/home/acme/git/linux/tools/perf/util/c++/clang.cpp:76: undefined reference to 
`clang::CompilerInstance::setInvocation(clang::CompilerInvocation*)'
/home/acme/git/linux/tools/perf/util/c++/clang.cpp:78: undefined reference to 
`clang::EmitLLVMOnlyAction::EmitLLVMOnlyAction(llvm::LLVMContext*)'
/home/acme/git/linux/tools/perf/util/c++/clang.cpp:79: undefined reference to 
`clang::CompilerInstance::ExecuteAction(clang::FrontendAction&)'
/home/acme/git/linux/tools/perf/util/c++/clang.cpp:82: undefined reference to 
`clang::CodeGenAction::takeModule()'
/home/acme/git/linux/tools/perf/util/c++/clang.cpp:68: undefined reference to 
`clang::CompilerInstance::~CompilerInstance()'
/tmp/build/perf/libperf.a(libperf-in.o): In function 
`perf::getModuleFromSource(llvm::SmallVector, 
llvm::StringRef, llvm::StringRef)':
/home/acme/git/linux/tools/perf/util/c++/clang.cpp:92: undefined reference to 
`clang::vfs::getRealFileSystem()'
/home/acme/git/linux/tools/perf/util/c++/clang.cpp:92: undefined reference to 
`clang::vfs::OverlayFileSystem::OverlayFileSystem(llvm::IntrusiveRefCntPtr)'
/home/acme/git/linux/tools/perf/util/c++/clang.cpp:94: undefined reference to 
`clang::vfs::InMemoryFileSystem::InMemoryFileSystem(bool)'
/home/acme/git/linux/tools/perf/util/c++/clang.cpp:100: undefined reference to 
`clang::vfs::OverlayFileSystem::pushOverlay(llvm::IntrusiveRefCntPtr)'
/home/acme/git/linux/tools/perf/util/c++/clang.cpp:101: undefined reference to 
`clang::vfs::InMemoryFileSystem::addFile(llvm::Twine const&, long, 
std::unique_ptr >)'
/tmp/build/perf/libperf.a(libperf-in.o): In function 
`perf::getModuleFromSource(llvm::SmallVector, 
llvm::StringRef)':
/home/acme/git/linux/tools/perf/util/c++/clang.cpp:109: undefined reference to 
`clang::vfs::getRealFileSystem()'
/tmp/build/perf/libperf.a(libperf-in.o): In function 
`clang::CompilerInvocation::~CompilerInvocation()':
/usr/include/clang/Frontend/CompilerInvocation.h:102: undefined reference to 
`clang::CompilerInvocationBase::~CompilerInvocationBase()'
/tmp/build/perf/libperf.a(libperf-in.o): In function `void 
__gnu_cxx::new_allocator::construct(clang::PCHContainerOperations*)':
/usr/include/c++/6.2.1/ext/new_allocator.h:120: undefined reference to 
`clang::PCHContainerOperations::PCHContainerOperations()'
collect2: error: ld returned 1 exit status
Makefile.perf:491: recipe for target '/tmp/build/perf/perf' failed
make[1]: *** [/tmp/build/perf/perf] Error 1
Makefile:108: recipe for target 'install-bin' failed
make: *** [install-bin] Error 2
make: Leaving directory '/home/acme/git/linux/tools/perf'
[acme@jouet linux]$

Re: [PATCH 39/39] mtd: nand: denali_dt: add compatible strings for UniPhier SoC variants

[Marek Vasut]

On 12/05/2016 09:51 PM, Dinh Nguyen wrote:
> On Sun, Dec 4, 2016 at 10:22 PM, Marek Vasut  wrote:
>> On 12/05/2016 05:10 AM, Masahiro Yamada wrote:
>>> Hi Marek,
>>>
>>>
>>> 2016-12-05 12:44 GMT+09:00 Marek Vasut :
 On 12/05/2016 04:30 AM, Masahiro Yamada wrote:
> Hi Dinh,
>
>
> 2016-12-04 7:08 GMT+09:00 Dinh Nguyen :
>> Hi,
>>
>> On Fri, Dec 2, 2016 at 8:49 PM, Marek Vasut  
>> wrote:
>>> On 12/03/2016 03:41 AM, Masahiro Yamada wrote:
 Hi Rob,
>>>
>>> Hi!
>>>
 2016-12-03 1:26 GMT+09:00 Rob Herring :

>>
>>
>> (Plan A)
>>   "denali,socfpga-nand"   (for Altera SOCFPGA variant)
>>   "denali,uniphier-nand-v1"   (for old Socionext UniPhier family 
>> variant)
>>   "denali,uniphier-nand-v2"   (for new Socionext UniPhier family 
>> variant)
>>
>> (Plan B)
>>   "altera,denali-nand"(for Altera SOCFPGA variant)
>>   "socionext,denali-nand-v5a" (for old Socionext UniPhier family 
>> variant)
>>   "socionext,denali-nand-v5b" (for new Socionext UniPhier family 
>> variant)

> Let the Altera folks worry about their stuff. At least for soft IP in
> FPGA, it's a bit of a special case. The old string can remain as bad
> as it is.


 Hmm, I am not sure if this IP would fit in FPGA
 (to use it along with NIOS-II?)

 (even if it happened, nothing of this IP would be customizable on 
 users' side.
 When buying the IP, SoC vendors submit a list of desired features.
 Denali (now Cadence) generates the RTL according to the configuration 
 sheet.
 The function is fixed at this point. So, generic compatible would be
 useless anyway.)


 If we are talking about SOCFPGA,
 SOCFPGA is not only FPGA. Rather "SOC" + "FPGA".
 It consists of two parts:
 [1] SOC part  (Cortex-A9 + various hard-wired peripherals such UART,
 USB, SD, NAND, ...)
 [2] FPGA part (User design logic)

 The Denali NAND controller is included in [1].
 So, as far as we talk about the Denali on SOCFPGA,
 it is as hard-wired as Intel, Socionext's ones.
>>>
>>> That's correct, the Denali NAND IP in altera socfpga is a hardware
>>> block. You can make it available to the fabric too, but by default
>>> it's used by the ARM part of the chip, so for this discussion, you
>>> can forget that the FPGA part exists altogether.
>>>
>>> I would be in favor of plan B, since it seems to be the more often
>>> taken approach. A nice example is ci-hdrc:
>>>
>>> $ git grep compatible drivers/usb/chipidea/
>>>
> I simply would do "socionext,uniphier-v5b-nand" (and v5a).
> The fact that it is denali is part of the documentation.
>

 Let me think about this.

 Socionext bought two version of Denali IP,
 and we are now re-using the newer one (v5b) for several SoCs.
 Socionext has some more product lines other than Uniphier SoC family,
 perhaps wider re-use might happen in the future.

 At first, I included "uniphier" in compatible, but I am still wondering
 if such a specific string is good or not.

 Also, comments from Altera engineers are appreciated.
>>
>> Sorry, it's taken me a while to add comments. My altera email is very 
>> spotty now
>> that the Intel merge is completed. Please use dingu...@kernel.org for 
>> any future
>> communications.
>>
>> Yes, everything that is said so far for the NAND controller on the
>> SoCFPGA is correct. I added the binding for the controller a while
>> back, but unfortunately, we never added the NAND interface to the
>> devkit, so we did not do much in terms of enabling it.
>>
>> I think the only SoCFPGA board I know that has the NAND interface active 
>> is
>> the TRCom board, but I have never seen that board.
>>
>> I don't have any strong opinions on this matter, just as long as the
>> original binding
>> "denali,denali-nand-dt" is kept, and I think Rob was ok with keeping
>> that binding.
>>
>
> I am proposing to add "altera,denali-nand" for Altera.
> For what, do you need the generic compatible?
> This IP has no default for it to fallback to.

 IMO just for compatibility reasons with old DTs .
>>>
>>> We generally contribute for
>>> a "working driver" (at least, should be functional to some extent)
>>> and "DT binding" bundled together.
>>>
>>> However, Altera upstreamed the DT binding first
>>> (then some parts of the DT 

Re: [PATCH 39/39] mtd: nand: denali_dt: add compatible strings for UniPhier SoC variants

[Marek Vasut]

On 12/05/2016 09:51 PM, Dinh Nguyen wrote:
> On Sun, Dec 4, 2016 at 10:22 PM, Marek Vasut  wrote:
>> On 12/05/2016 05:10 AM, Masahiro Yamada wrote:
>>> Hi Marek,
>>>
>>>
>>> 2016-12-05 12:44 GMT+09:00 Marek Vasut :
 On 12/05/2016 04:30 AM, Masahiro Yamada wrote:
> Hi Dinh,
>
>
> 2016-12-04 7:08 GMT+09:00 Dinh Nguyen :
>> Hi,
>>
>> On Fri, Dec 2, 2016 at 8:49 PM, Marek Vasut  
>> wrote:
>>> On 12/03/2016 03:41 AM, Masahiro Yamada wrote:
 Hi Rob,
>>>
>>> Hi!
>>>
 2016-12-03 1:26 GMT+09:00 Rob Herring :

>>
>>
>> (Plan A)
>>   "denali,socfpga-nand"   (for Altera SOCFPGA variant)
>>   "denali,uniphier-nand-v1"   (for old Socionext UniPhier family 
>> variant)
>>   "denali,uniphier-nand-v2"   (for new Socionext UniPhier family 
>> variant)
>>
>> (Plan B)
>>   "altera,denali-nand"(for Altera SOCFPGA variant)
>>   "socionext,denali-nand-v5a" (for old Socionext UniPhier family 
>> variant)
>>   "socionext,denali-nand-v5b" (for new Socionext UniPhier family 
>> variant)

> Let the Altera folks worry about their stuff. At least for soft IP in
> FPGA, it's a bit of a special case. The old string can remain as bad
> as it is.


 Hmm, I am not sure if this IP would fit in FPGA
 (to use it along with NIOS-II?)

 (even if it happened, nothing of this IP would be customizable on 
 users' side.
 When buying the IP, SoC vendors submit a list of desired features.
 Denali (now Cadence) generates the RTL according to the configuration 
 sheet.
 The function is fixed at this point. So, generic compatible would be
 useless anyway.)


 If we are talking about SOCFPGA,
 SOCFPGA is not only FPGA. Rather "SOC" + "FPGA".
 It consists of two parts:
 [1] SOC part  (Cortex-A9 + various hard-wired peripherals such UART,
 USB, SD, NAND, ...)
 [2] FPGA part (User design logic)

 The Denali NAND controller is included in [1].
 So, as far as we talk about the Denali on SOCFPGA,
 it is as hard-wired as Intel, Socionext's ones.
>>>
>>> That's correct, the Denali NAND IP in altera socfpga is a hardware
>>> block. You can make it available to the fabric too, but by default
>>> it's used by the ARM part of the chip, so for this discussion, you
>>> can forget that the FPGA part exists altogether.
>>>
>>> I would be in favor of plan B, since it seems to be the more often
>>> taken approach. A nice example is ci-hdrc:
>>>
>>> $ git grep compatible drivers/usb/chipidea/
>>>
> I simply would do "socionext,uniphier-v5b-nand" (and v5a).
> The fact that it is denali is part of the documentation.
>

 Let me think about this.

 Socionext bought two version of Denali IP,
 and we are now re-using the newer one (v5b) for several SoCs.
 Socionext has some more product lines other than Uniphier SoC family,
 perhaps wider re-use might happen in the future.

 At first, I included "uniphier" in compatible, but I am still wondering
 if such a specific string is good or not.

 Also, comments from Altera engineers are appreciated.
>>
>> Sorry, it's taken me a while to add comments. My altera email is very 
>> spotty now
>> that the Intel merge is completed. Please use dingu...@kernel.org for 
>> any future
>> communications.
>>
>> Yes, everything that is said so far for the NAND controller on the
>> SoCFPGA is correct. I added the binding for the controller a while
>> back, but unfortunately, we never added the NAND interface to the
>> devkit, so we did not do much in terms of enabling it.
>>
>> I think the only SoCFPGA board I know that has the NAND interface active 
>> is
>> the TRCom board, but I have never seen that board.
>>
>> I don't have any strong opinions on this matter, just as long as the
>> original binding
>> "denali,denali-nand-dt" is kept, and I think Rob was ok with keeping
>> that binding.
>>
>
> I am proposing to add "altera,denali-nand" for Altera.
> For what, do you need the generic compatible?
> This IP has no default for it to fallback to.

 IMO just for compatibility reasons with old DTs .
>>>
>>> We generally contribute for
>>> a "working driver" (at least, should be functional to some extent)
>>> and "DT binding" bundled together.
>>>
>>> However, Altera upstreamed the DT binding first
>>> (then some parts of the DT binding turned out wrong),
>>> but they did not upstream needed driver changes in the end.
>>>
>>> So, the 

[PATCH 18/20] perf tools: Cleanup build directory before each test

[Arnaldo Carvalho de Melo]

From: Jiri Olsa 

Cleanup the fixdep tool before every test.

Signed-off-by: Jiri Olsa 
Cc: David Ahern 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/r/1480884178-8072-8-git-send-email-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/tests/make | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/tests/make b/tools/perf/tests/make
index aa49b6600d1f..0784748f1670 100644
--- a/tools/perf/tests/make
+++ b/tools/perf/tests/make
@@ -280,7 +280,7 @@ endif
 
 MAKEFLAGS := --no-print-directory
 
-clean := @(cd $(PERF); $(MAKE_F) -s $(O_OPT) clean >/dev/null)
+clean := @(cd $(PERF); $(MAKE_F) -s $(O_OPT) clean >/dev/null && $(MAKE) -s 
$(O_OPT) -C ../build clean >/dev/null)
 
 $(run):
$(call clean)
-- 
2.9.3

[PATCH 18/20] perf tools: Cleanup build directory before each test

[Arnaldo Carvalho de Melo]

From: Jiri Olsa 

Cleanup the fixdep tool before every test.

Signed-off-by: Jiri Olsa 
Cc: David Ahern 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/r/1480884178-8072-8-git-send-email-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/tests/make | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/tests/make b/tools/perf/tests/make
index aa49b6600d1f..0784748f1670 100644
--- a/tools/perf/tests/make
+++ b/tools/perf/tests/make
@@ -280,7 +280,7 @@ endif
 
 MAKEFLAGS := --no-print-directory
 
-clean := @(cd $(PERF); $(MAKE_F) -s $(O_OPT) clean >/dev/null)
+clean := @(cd $(PERF); $(MAKE_F) -s $(O_OPT) clean >/dev/null && $(MAKE) -s 
$(O_OPT) -C ../build clean >/dev/null)
 
 $(run):
$(call clean)
-- 
2.9.3

[PATCH 19/20] perf tools: Add non config targets

[Arnaldo Carvalho de Melo]

From: Jiri Olsa 

Adding some missing non config targets that were for some reason
omitted.

Signed-off-by: Jiri Olsa 
Cc: David Ahern 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/r/1480884178-8072-7-git-send-email-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/Makefile.perf | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
index 2784b5843aef..10495c9dbe71 100644
--- a/tools/perf/Makefile.perf
+++ b/tools/perf/Makefile.perf
@@ -177,7 +177,7 @@ SUBCMD_DIR  = $(srctree)/tools/lib/subcmd/
 # non-config cases
 config := 1
 
-NON_CONFIG_TARGETS := clean TAGS tags cscope help install-doc
+NON_CONFIG_TARGETS := clean TAGS tags cscope help install-doc install-man 
install-html install-info install-pdf doc man html info pdf
 
 ifdef MAKECMDGOALS
 ifeq ($(filter-out $(NON_CONFIG_TARGETS),$(MAKECMDGOALS)),)
-- 
2.9.3

[PATCH 19/20] perf tools: Add non config targets

[Arnaldo Carvalho de Melo]

From: Jiri Olsa 

Adding some missing non config targets that were for some reason
omitted.

Signed-off-by: Jiri Olsa 
Cc: David Ahern 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/r/1480884178-8072-7-git-send-email-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/Makefile.perf | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
index 2784b5843aef..10495c9dbe71 100644
--- a/tools/perf/Makefile.perf
+++ b/tools/perf/Makefile.perf
@@ -177,7 +177,7 @@ SUBCMD_DIR  = $(srctree)/tools/lib/subcmd/
 # non-config cases
 config := 1
 
-NON_CONFIG_TARGETS := clean TAGS tags cscope help install-doc
+NON_CONFIG_TARGETS := clean TAGS tags cscope help install-doc install-man 
install-html install-info install-pdf doc man html info pdf
 
 ifdef MAKECMDGOALS
 ifeq ($(filter-out $(NON_CONFIG_TARGETS),$(MAKECMDGOALS)),)
-- 
2.9.3

[PATCH 16/20] perf tools: Move install-gtk target into rules area

[Arnaldo Carvalho de Melo]

From: Jiri Olsa 

The upcoming fixdep fix needs all targets at the same area, so they'll
fit under a signal condition block.

Move install-gtk target into the rules section.

Signed-off-by: Jiri Olsa 
Cc: David Ahern 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/r/1480884178-8072-4-git-send-email-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/Makefile.perf | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
index dfb20dd31865..593d765d62ab 100644
--- a/tools/perf/Makefile.perf
+++ b/tools/perf/Makefile.perf
@@ -331,11 +331,6 @@ endif
 ifndef NO_GTK2
   ALL_PROGRAMS += $(OUTPUT)libperf-gtk.so
   GTK_IN := $(OUTPUT)gtk-in.o
-
-install-gtk: $(OUTPUT)libperf-gtk.so
-   $(call QUIET_INSTALL, 'GTK UI') \
-   $(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(libdir_SQ)'; \
-   $(INSTALL) $(OUTPUT)libperf-gtk.so '$(DESTDIR_SQ)$(libdir_SQ)'
 endif
 
 ifdef ASCIIDOC8
@@ -712,7 +707,14 @@ check: $(OUTPUT)common-cmds.h
 
 ### Installation rules
 
+ifndef NO_GTK2
+install-gtk: $(OUTPUT)libperf-gtk.so
+   $(call QUIET_INSTALL, 'GTK UI') \
+   $(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(libdir_SQ)'; \
+   $(INSTALL) $(OUTPUT)libperf-gtk.so '$(DESTDIR_SQ)$(libdir_SQ)'
+else
 install-gtk:
+endif
 
 install-tools: all install-gtk
$(call QUIET_INSTALL, binaries) \
-- 
2.9.3

[PATCH 03/20] perf tools: Pass context to perf hook functions

[Arnaldo Carvalho de Melo]

From: Wang Nan 

Pass a pointer to perf hook functions so they receive context
information during setup.

Signed-off-by: Wang Nan 
Cc: Alexei Starovoitov 
Cc: He Kuang 
Cc: Jiri Olsa 
Cc: Joe Stringer 
Cc: Zefan Li 
Cc: pi3or...@163.com
Link: http://lkml.kernel.org/r/20161126070354.141764-6-wangn...@huawei.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/tests/perf-hooks.c | 14 +-
 tools/perf/util/perf-hooks.c  | 10 +++---
 tools/perf/util/perf-hooks.h  |  6 --
 3 files changed, 20 insertions(+), 10 deletions(-)

diff --git a/tools/perf/tests/perf-hooks.c b/tools/perf/tests/perf-hooks.c
index 9338cb2c25ab..665ecc19671c 100644
--- a/tools/perf/tests/perf-hooks.c
+++ b/tools/perf/tests/perf-hooks.c
@@ -15,13 +15,13 @@ static void sigsegv_handler(int sig __maybe_unused)
exit(-1);
 }
 
-static int hook_flags;
 
-static void the_hook(void)
+static void the_hook(void *_hook_flags)
 {
+   int *hook_flags = _hook_flags;
int *p = NULL;
 
-   hook_flags = 1234;
+   *hook_flags = 1234;
 
/* Generate a segfault, test perf_hooks__recover */
*p = 0;
@@ -29,13 +29,17 @@ static void the_hook(void)
 
 int test__perf_hooks(int subtest __maybe_unused)
 {
+   int hook_flags = 0;
+
signal(SIGSEGV, sigsegv_handler);
-   perf_hooks__set_hook("test", the_hook);
+   perf_hooks__set_hook("test", the_hook, _flags);
perf_hooks__invoke_test();
 
/* hook is triggered? */
-   if (hook_flags != 1234)
+   if (hook_flags != 1234) {
+   pr_debug("Setting failed: %d (%p)\n", hook_flags, _flags);
return TEST_FAIL;
+   }
 
/* the buggy hook is removed? */
if (perf_hooks__get_hook("test"))
diff --git a/tools/perf/util/perf-hooks.c b/tools/perf/util/perf-hooks.c
index 4ce88e37dd63..cb368306b12b 100644
--- a/tools/perf/util/perf-hooks.c
+++ b/tools/perf/util/perf-hooks.c
@@ -27,7 +27,7 @@ void perf_hooks__invoke(const struct perf_hook_desc *desc)
*(current_perf_hook->p_hook_func) = NULL;
} else {
current_perf_hook = desc;
-   (**desc->p_hook_func)();
+   (**desc->p_hook_func)(desc->hook_ctx);
}
current_perf_hook = NULL;
 }
@@ -41,7 +41,9 @@ void perf_hooks__recover(void)
 #define PERF_HOOK(name)\
 perf_hook_func_t __perf_hook_func_##name = NULL;   \
 struct perf_hook_desc __perf_hook_desc_##name =\
-   {.hook_name = #name, .p_hook_func = &__perf_hook_func_##name};
+   {.hook_name = #name,\
+.p_hook_func = &__perf_hook_func_##name,   \
+.hook_ctx = NULL};
 #include "perf-hooks-list.h"
 #undef PERF_HOOK
 
@@ -54,7 +56,8 @@ static struct perf_hook_desc *perf_hooks[] = {
 #undef PERF_HOOK
 
 int perf_hooks__set_hook(const char *hook_name,
-perf_hook_func_t hook_func)
+perf_hook_func_t hook_func,
+void *hook_ctx)
 {
unsigned int i;
 
@@ -65,6 +68,7 @@ int perf_hooks__set_hook(const char *hook_name,
if (*(perf_hooks[i]->p_hook_func))
pr_warning("Overwrite existing hook: %s\n", hook_name);
*(perf_hooks[i]->p_hook_func) = hook_func;
+   perf_hooks[i]->hook_ctx = hook_ctx;
return 0;
}
return -ENOENT;
diff --git a/tools/perf/util/perf-hooks.h b/tools/perf/util/perf-hooks.h
index 1d482b26b4b9..838d5797bc1e 100644
--- a/tools/perf/util/perf-hooks.h
+++ b/tools/perf/util/perf-hooks.h
@@ -5,10 +5,11 @@
 extern "C" {
 #endif
 
-typedef void (*perf_hook_func_t)(void);
+typedef void (*perf_hook_func_t)(void *ctx);
 struct perf_hook_desc {
const char * const hook_name;
perf_hook_func_t * const p_hook_func;
+   void *hook_ctx;
 };
 
 extern void perf_hooks__invoke(const struct perf_hook_desc *);
@@ -26,7 +27,8 @@ static inline void perf_hooks__invoke_##name(void)\
 
 extern int
 perf_hooks__set_hook(const char *hook_name,
-perf_hook_func_t hook_func);
+perf_hook_func_t hook_func,
+void *hook_ctx);
 
 extern perf_hook_func_t
 perf_hooks__get_hook(const char *hook_name);
-- 
2.9.3

[PATCH 16/20] perf tools: Move install-gtk target into rules area

[Arnaldo Carvalho de Melo]

From: Jiri Olsa 

The upcoming fixdep fix needs all targets at the same area, so they'll
fit under a signal condition block.

Move install-gtk target into the rules section.

Signed-off-by: Jiri Olsa 
Cc: David Ahern 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/r/1480884178-8072-4-git-send-email-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/Makefile.perf | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
index dfb20dd31865..593d765d62ab 100644
--- a/tools/perf/Makefile.perf
+++ b/tools/perf/Makefile.perf
@@ -331,11 +331,6 @@ endif
 ifndef NO_GTK2
   ALL_PROGRAMS += $(OUTPUT)libperf-gtk.so
   GTK_IN := $(OUTPUT)gtk-in.o
-
-install-gtk: $(OUTPUT)libperf-gtk.so
-   $(call QUIET_INSTALL, 'GTK UI') \
-   $(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(libdir_SQ)'; \
-   $(INSTALL) $(OUTPUT)libperf-gtk.so '$(DESTDIR_SQ)$(libdir_SQ)'
 endif
 
 ifdef ASCIIDOC8
@@ -712,7 +707,14 @@ check: $(OUTPUT)common-cmds.h
 
 ### Installation rules
 
+ifndef NO_GTK2
+install-gtk: $(OUTPUT)libperf-gtk.so
+   $(call QUIET_INSTALL, 'GTK UI') \
+   $(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(libdir_SQ)'; \
+   $(INSTALL) $(OUTPUT)libperf-gtk.so '$(DESTDIR_SQ)$(libdir_SQ)'
+else
 install-gtk:
+endif
 
 install-tools: all install-gtk
$(call QUIET_INSTALL, binaries) \
-- 
2.9.3

[PATCH 03/20] perf tools: Pass context to perf hook functions

[Arnaldo Carvalho de Melo]

From: Wang Nan 

Pass a pointer to perf hook functions so they receive context
information during setup.

Signed-off-by: Wang Nan 
Cc: Alexei Starovoitov 
Cc: He Kuang 
Cc: Jiri Olsa 
Cc: Joe Stringer 
Cc: Zefan Li 
Cc: pi3or...@163.com
Link: http://lkml.kernel.org/r/20161126070354.141764-6-wangn...@huawei.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/tests/perf-hooks.c | 14 +-
 tools/perf/util/perf-hooks.c  | 10 +++---
 tools/perf/util/perf-hooks.h  |  6 --
 3 files changed, 20 insertions(+), 10 deletions(-)

diff --git a/tools/perf/tests/perf-hooks.c b/tools/perf/tests/perf-hooks.c
index 9338cb2c25ab..665ecc19671c 100644
--- a/tools/perf/tests/perf-hooks.c
+++ b/tools/perf/tests/perf-hooks.c
@@ -15,13 +15,13 @@ static void sigsegv_handler(int sig __maybe_unused)
exit(-1);
 }
 
-static int hook_flags;
 
-static void the_hook(void)
+static void the_hook(void *_hook_flags)
 {
+   int *hook_flags = _hook_flags;
int *p = NULL;
 
-   hook_flags = 1234;
+   *hook_flags = 1234;
 
/* Generate a segfault, test perf_hooks__recover */
*p = 0;
@@ -29,13 +29,17 @@ static void the_hook(void)
 
 int test__perf_hooks(int subtest __maybe_unused)
 {
+   int hook_flags = 0;
+
signal(SIGSEGV, sigsegv_handler);
-   perf_hooks__set_hook("test", the_hook);
+   perf_hooks__set_hook("test", the_hook, _flags);
perf_hooks__invoke_test();
 
/* hook is triggered? */
-   if (hook_flags != 1234)
+   if (hook_flags != 1234) {
+   pr_debug("Setting failed: %d (%p)\n", hook_flags, _flags);
return TEST_FAIL;
+   }
 
/* the buggy hook is removed? */
if (perf_hooks__get_hook("test"))
diff --git a/tools/perf/util/perf-hooks.c b/tools/perf/util/perf-hooks.c
index 4ce88e37dd63..cb368306b12b 100644
--- a/tools/perf/util/perf-hooks.c
+++ b/tools/perf/util/perf-hooks.c
@@ -27,7 +27,7 @@ void perf_hooks__invoke(const struct perf_hook_desc *desc)
*(current_perf_hook->p_hook_func) = NULL;
} else {
current_perf_hook = desc;
-   (**desc->p_hook_func)();
+   (**desc->p_hook_func)(desc->hook_ctx);
}
current_perf_hook = NULL;
 }
@@ -41,7 +41,9 @@ void perf_hooks__recover(void)
 #define PERF_HOOK(name)\
 perf_hook_func_t __perf_hook_func_##name = NULL;   \
 struct perf_hook_desc __perf_hook_desc_##name =\
-   {.hook_name = #name, .p_hook_func = &__perf_hook_func_##name};
+   {.hook_name = #name,\
+.p_hook_func = &__perf_hook_func_##name,   \
+.hook_ctx = NULL};
 #include "perf-hooks-list.h"
 #undef PERF_HOOK
 
@@ -54,7 +56,8 @@ static struct perf_hook_desc *perf_hooks[] = {
 #undef PERF_HOOK
 
 int perf_hooks__set_hook(const char *hook_name,
-perf_hook_func_t hook_func)
+perf_hook_func_t hook_func,
+void *hook_ctx)
 {
unsigned int i;
 
@@ -65,6 +68,7 @@ int perf_hooks__set_hook(const char *hook_name,
if (*(perf_hooks[i]->p_hook_func))
pr_warning("Overwrite existing hook: %s\n", hook_name);
*(perf_hooks[i]->p_hook_func) = hook_func;
+   perf_hooks[i]->hook_ctx = hook_ctx;
return 0;
}
return -ENOENT;
diff --git a/tools/perf/util/perf-hooks.h b/tools/perf/util/perf-hooks.h
index 1d482b26b4b9..838d5797bc1e 100644
--- a/tools/perf/util/perf-hooks.h
+++ b/tools/perf/util/perf-hooks.h
@@ -5,10 +5,11 @@
 extern "C" {
 #endif
 
-typedef void (*perf_hook_func_t)(void);
+typedef void (*perf_hook_func_t)(void *ctx);
 struct perf_hook_desc {
const char * const hook_name;
perf_hook_func_t * const p_hook_func;
+   void *hook_ctx;
 };
 
 extern void perf_hooks__invoke(const struct perf_hook_desc *);
@@ -26,7 +27,8 @@ static inline void perf_hooks__invoke_##name(void)\
 
 extern int
 perf_hooks__set_hook(const char *hook_name,
-perf_hook_func_t hook_func);
+perf_hook_func_t hook_func,
+void *hook_ctx);
 
 extern perf_hook_func_t
 perf_hooks__get_hook(const char *hook_name);
-- 
2.9.3

[PATCH 07/20] perf build: Add clang and llvm compile and linking support

[Arnaldo Carvalho de Melo]

From: Wang Nan 

Add necessary c++ flags and link libraries to support builtin clang and
LLVM. Add all llvm and clang libraries, so don't need to worry about
clang changes its libraries setting. However, linking perf would take
much longer than usual.

Signed-off-by: Wang Nan 
Cc: Alexei Starovoitov 
Cc: He Kuang 
Cc: Jiri Olsa 
Cc: Joe Stringer 
Cc: Zefan Li 
Cc: pi3or...@163.com
Link: http://lkml.kernel.org/r/20161126070354.141764-10-wangn...@huawei.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/Makefile.config | 35 +++
 tools/perf/Makefile.perf   | 23 ++-
 tools/perf/tests/make  |  2 ++
 3 files changed, 59 insertions(+), 1 deletion(-)

diff --git a/tools/perf/Makefile.config b/tools/perf/Makefile.config
index 8a493d46fab9..b7c9c8051a33 100644
--- a/tools/perf/Makefile.config
+++ b/tools/perf/Makefile.config
@@ -136,6 +136,7 @@ endif
 # Treat warnings as errors unless directed not to
 ifneq ($(WERROR),0)
   CFLAGS += -Werror
+  CXXFLAGS += -Werror
 endif
 
 ifndef DEBUG
@@ -182,6 +183,13 @@ CFLAGS += -Wall
 CFLAGS += -Wextra
 CFLAGS += -std=gnu99
 
+CXXFLAGS += -std=gnu++11 -fno-exceptions -fno-rtti
+CXXFLAGS += -Wall
+CXXFLAGS += -fno-omit-frame-pointer
+CXXFLAGS += -ggdb3
+CXXFLAGS += -funwind-tables
+CXXFLAGS += -Wno-strict-aliasing
+
 # Enforce a non-executable stack, as we may regress (again) in the future by
 # adding assembler files missing the .GNU-stack linker note.
 LDFLAGS += -Wl,-z,noexecstack
@@ -783,6 +791,33 @@ ifndef NO_JVMTI
   endif
 endif
 
+USE_CXX = 0
+USE_CLANGLLVM = 0
+ifdef LIBCLANGLLVM
+  $(call feature_check,cxx)
+  ifneq ($(feature-cxx), 1)
+msg := $(warning No g++ found, disable clang and llvm support. Please 
install g++)
+  else
+$(call feature_check,llvm)
+ifneq ($(feature-llvm), 1)
+  msg := $(warning No libLLVM found, disable clang and llvm support. 
Please install llvm-dev)
+else
+  $(call feature_check,clang)
+  ifneq ($(feature-clang), 1)
+msg := $(warning No libclang found, disable clang and llvm support. 
Please install libclang-dev)
+  else
+CFLAGS += -DHAVE_LIBCLANGLLVM_SUPPORT
+CXXFLAGS += -DHAVE_LIBCLANGLLVM_SUPPORT -I$(shell $(LLVM_CONFIG) 
--includedir)
+$(call detected,CONFIG_CXX)
+$(call detected,CONFIG_CLANGLLVM)
+   USE_CXX = 1
+   USE_LLVM = 1
+   USE_CLANG = 1
+  endif
+endif
+  endif
+endif
+
 # Among the variables below, these:
 #   perfexecdir
 #   template_dir
diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
index 3cb1df43ad3e..dfb20dd31865 100644
--- a/tools/perf/Makefile.perf
+++ b/tools/perf/Makefile.perf
@@ -88,6 +88,10 @@ include ../scripts/utilities.mak
 # and bypass the feature detection
 #
 # Define NO_JVMTI if you do not want jvmti agent built
+#
+# Define LIBCLANGLLVM if you DO want builtin clang and llvm support.
+# When selected, pass LLVM_CONFIG=/path/to/llvm-config to `make' if
+# llvm-config is not in $PATH.
 
 # As per kernel Makefile, avoid funny character set dependencies
 unexport LC_ALL
@@ -143,6 +147,7 @@ endef
 $(call allow-override,CC,$(CROSS_COMPILE)gcc)
 $(call allow-override,AR,$(CROSS_COMPILE)ar)
 $(call allow-override,LD,$(CROSS_COMPILE)ld)
+$(call allow-override,CXX,$(CROSS_COMPILE)g++)
 
 LD += $(EXTRA_LDFLAGS)
 
@@ -151,6 +156,7 @@ HOSTLD  ?= ld
 HOSTAR  ?= ar
 
 PKG_CONFIG = $(CROSS_COMPILE)pkg-config
+LLVM_CONFIG ?= llvm-config
 
 RM  = rm -f
 LN  = ln -f
@@ -338,6 +344,21 @@ endif
 
 LIBS = -Wl,--whole-archive $(PERFLIBS) -Wl,--no-whole-archive 
-Wl,--start-group $(EXTLIBS) -Wl,--end-group
 
+ifeq ($(USE_CLANG), 1)
+  CLANGLIBS_LIST = AST Basic CodeGen Driver Frontend Lex Tooling Edit Sema 
Analysis Parse Serialization
+  LIBCLANG = $(foreach l,$(CLANGLIBS_LIST),$(wildcard $(shell $(LLVM_CONFIG) 
--libdir)/libclang$(l).a))
+  LIBS += -Wl,--start-group $(LIBCLANG) -Wl,--end-group
+endif
+
+ifeq ($(USE_LLVM), 1)
+  LIBLLVM = $(shell $(LLVM_CONFIG) --libs all) $(shell $(LLVM_CONFIG) 
--system-libs)
+  LIBS += -L$(shell $(LLVM_CONFIG) --libdir) $(LIBLLVM)
+endif
+
+ifeq ($(USE_CXX), 1)
+  LIBS += -lstdc++
+endif
+
 export INSTALL SHELL_PATH
 
 ### Build rules
@@ -356,7 +377,7 @@ strip: $(PROGRAMS) $(OUTPUT)perf
 
 PERF_IN := $(OUTPUT)perf-in.o
 
-export srctree OUTPUT RM CC LD AR CFLAGS V BISON FLEX AWK
+export srctree OUTPUT RM CC CXX LD AR CFLAGS CXXFLAGS V BISON FLEX AWK
 export HOSTCC HOSTLD HOSTAR
 include $(srctree)/tools/build/Makefile.include
 
diff --git a/tools/perf/tests/make b/tools/perf/tests/make
index 08ed7f12cc37..aa49b6600d1f 100644
--- a/tools/perf/tests/make
+++ b/tools/perf/tests/make
@@ -83,6 +83,7 @@ make_no_libbpf:= NO_LIBBPF=1
 make_no_libcrypto   := NO_LIBCRYPTO=1
 make_with_babeltrace:= LIBBABELTRACE=1
 make_no_sdt:= NO_SDT=1
+make_with_clangllvm := 

[PATCH 07/20] perf build: Add clang and llvm compile and linking support

[Arnaldo Carvalho de Melo]

From: Wang Nan 

Add necessary c++ flags and link libraries to support builtin clang and
LLVM. Add all llvm and clang libraries, so don't need to worry about
clang changes its libraries setting. However, linking perf would take
much longer than usual.

Signed-off-by: Wang Nan 
Cc: Alexei Starovoitov 
Cc: He Kuang 
Cc: Jiri Olsa 
Cc: Joe Stringer 
Cc: Zefan Li 
Cc: pi3or...@163.com
Link: http://lkml.kernel.org/r/20161126070354.141764-10-wangn...@huawei.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/Makefile.config | 35 +++
 tools/perf/Makefile.perf   | 23 ++-
 tools/perf/tests/make  |  2 ++
 3 files changed, 59 insertions(+), 1 deletion(-)

diff --git a/tools/perf/Makefile.config b/tools/perf/Makefile.config
index 8a493d46fab9..b7c9c8051a33 100644
--- a/tools/perf/Makefile.config
+++ b/tools/perf/Makefile.config
@@ -136,6 +136,7 @@ endif
 # Treat warnings as errors unless directed not to
 ifneq ($(WERROR),0)
   CFLAGS += -Werror
+  CXXFLAGS += -Werror
 endif
 
 ifndef DEBUG
@@ -182,6 +183,13 @@ CFLAGS += -Wall
 CFLAGS += -Wextra
 CFLAGS += -std=gnu99
 
+CXXFLAGS += -std=gnu++11 -fno-exceptions -fno-rtti
+CXXFLAGS += -Wall
+CXXFLAGS += -fno-omit-frame-pointer
+CXXFLAGS += -ggdb3
+CXXFLAGS += -funwind-tables
+CXXFLAGS += -Wno-strict-aliasing
+
 # Enforce a non-executable stack, as we may regress (again) in the future by
 # adding assembler files missing the .GNU-stack linker note.
 LDFLAGS += -Wl,-z,noexecstack
@@ -783,6 +791,33 @@ ifndef NO_JVMTI
   endif
 endif
 
+USE_CXX = 0
+USE_CLANGLLVM = 0
+ifdef LIBCLANGLLVM
+  $(call feature_check,cxx)
+  ifneq ($(feature-cxx), 1)
+msg := $(warning No g++ found, disable clang and llvm support. Please 
install g++)
+  else
+$(call feature_check,llvm)
+ifneq ($(feature-llvm), 1)
+  msg := $(warning No libLLVM found, disable clang and llvm support. 
Please install llvm-dev)
+else
+  $(call feature_check,clang)
+  ifneq ($(feature-clang), 1)
+msg := $(warning No libclang found, disable clang and llvm support. 
Please install libclang-dev)
+  else
+CFLAGS += -DHAVE_LIBCLANGLLVM_SUPPORT
+CXXFLAGS += -DHAVE_LIBCLANGLLVM_SUPPORT -I$(shell $(LLVM_CONFIG) 
--includedir)
+$(call detected,CONFIG_CXX)
+$(call detected,CONFIG_CLANGLLVM)
+   USE_CXX = 1
+   USE_LLVM = 1
+   USE_CLANG = 1
+  endif
+endif
+  endif
+endif
+
 # Among the variables below, these:
 #   perfexecdir
 #   template_dir
diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
index 3cb1df43ad3e..dfb20dd31865 100644
--- a/tools/perf/Makefile.perf
+++ b/tools/perf/Makefile.perf
@@ -88,6 +88,10 @@ include ../scripts/utilities.mak
 # and bypass the feature detection
 #
 # Define NO_JVMTI if you do not want jvmti agent built
+#
+# Define LIBCLANGLLVM if you DO want builtin clang and llvm support.
+# When selected, pass LLVM_CONFIG=/path/to/llvm-config to `make' if
+# llvm-config is not in $PATH.
 
 # As per kernel Makefile, avoid funny character set dependencies
 unexport LC_ALL
@@ -143,6 +147,7 @@ endef
 $(call allow-override,CC,$(CROSS_COMPILE)gcc)
 $(call allow-override,AR,$(CROSS_COMPILE)ar)
 $(call allow-override,LD,$(CROSS_COMPILE)ld)
+$(call allow-override,CXX,$(CROSS_COMPILE)g++)
 
 LD += $(EXTRA_LDFLAGS)
 
@@ -151,6 +156,7 @@ HOSTLD  ?= ld
 HOSTAR  ?= ar
 
 PKG_CONFIG = $(CROSS_COMPILE)pkg-config
+LLVM_CONFIG ?= llvm-config
 
 RM  = rm -f
 LN  = ln -f
@@ -338,6 +344,21 @@ endif
 
 LIBS = -Wl,--whole-archive $(PERFLIBS) -Wl,--no-whole-archive 
-Wl,--start-group $(EXTLIBS) -Wl,--end-group
 
+ifeq ($(USE_CLANG), 1)
+  CLANGLIBS_LIST = AST Basic CodeGen Driver Frontend Lex Tooling Edit Sema 
Analysis Parse Serialization
+  LIBCLANG = $(foreach l,$(CLANGLIBS_LIST),$(wildcard $(shell $(LLVM_CONFIG) 
--libdir)/libclang$(l).a))
+  LIBS += -Wl,--start-group $(LIBCLANG) -Wl,--end-group
+endif
+
+ifeq ($(USE_LLVM), 1)
+  LIBLLVM = $(shell $(LLVM_CONFIG) --libs all) $(shell $(LLVM_CONFIG) 
--system-libs)
+  LIBS += -L$(shell $(LLVM_CONFIG) --libdir) $(LIBLLVM)
+endif
+
+ifeq ($(USE_CXX), 1)
+  LIBS += -lstdc++
+endif
+
 export INSTALL SHELL_PATH
 
 ### Build rules
@@ -356,7 +377,7 @@ strip: $(PROGRAMS) $(OUTPUT)perf
 
 PERF_IN := $(OUTPUT)perf-in.o
 
-export srctree OUTPUT RM CC LD AR CFLAGS V BISON FLEX AWK
+export srctree OUTPUT RM CC CXX LD AR CFLAGS CXXFLAGS V BISON FLEX AWK
 export HOSTCC HOSTLD HOSTAR
 include $(srctree)/tools/build/Makefile.include
 
diff --git a/tools/perf/tests/make b/tools/perf/tests/make
index 08ed7f12cc37..aa49b6600d1f 100644
--- a/tools/perf/tests/make
+++ b/tools/perf/tests/make
@@ -83,6 +83,7 @@ make_no_libbpf:= NO_LIBBPF=1
 make_no_libcrypto   := NO_LIBCRYPTO=1
 make_with_babeltrace:= LIBBABELTRACE=1
 make_no_sdt:= NO_SDT=1
+make_with_clangllvm := LIBCLANGLLVM=1
 make_tags   := tags
 make_cscope := cscope
 make_help   := help
@@ -139,6 +140,7 @@ run += 

[PATCH 08/20] perf clang: Add builtin clang support ant test case

[Arnaldo Carvalho de Melo]

From: Wang Nan 

Add basic clang support in clang.cpp and test__clang() testcase. The
first testcase checks if builtin clang is able to generate LLVM IR.

tests/clang.c is a proxy. Real testcase resides in
utils/c++/clang-test.cpp in c++ and exports C interface to perf test
subsystem.

Test result:

   $ perf test -v clang
   51: builtin clang support   :
   51.1: Test builtin clang compile C source to IR  :
   --- start ---
   test child forked, pid 13215
   test child finished with 0
    end 
   Test builtin clang support subtest 0: Ok

Committer note:

Make sure you've enabled CLANG and LLVM builtin support by setting
the LIBCLANGLLVM variable on the make command line, e.g.:

  make LIBCLANGLLVM=1 O=/tmp/build/perf -C tools/perf install-bin

Otherwise you'll get this when trying to do the 'perf test' call above:

  # perf test clang
  51: builtin clang support  : Skip (not compiled in)
  #

Signed-off-by: Wang Nan 
Tested-by: Arnaldo Carvalho de Melo 
Cc: Alexei Starovoitov 
Cc: He Kuang 
Cc: Jiri Olsa 
Cc: Joe Stringer 
Cc: Zefan Li 
Cc: pi3or...@163.com
Link: http://lkml.kernel.org/r/20161126070354.141764-11-wangn...@huawei.com
[ Removed "Test" from descriptions, redundant and already removed from all the 
other entries ]
Signed-off-by: Arnaldo Carvalho de Melo 

Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/tests/Build |  1 +
 tools/perf/tests/builtin-test.c|  9 
 tools/perf/tests/clang.c   | 42 +
 tools/perf/tests/tests.h   |  3 ++
 tools/perf/util/Build  |  2 +
 tools/perf/util/c++/Build  |  2 +
 tools/perf/util/c++/clang-c.h  | 16 +++
 tools/perf/util/c++/clang-test.cpp | 31 
 tools/perf/util/c++/clang.cpp  | 96 ++
 tools/perf/util/c++/clang.h| 16 +++
 10 files changed, 218 insertions(+)
 create mode 100644 tools/perf/tests/clang.c
 create mode 100644 tools/perf/util/c++/Build
 create mode 100644 tools/perf/util/c++/clang-c.h
 create mode 100644 tools/perf/util/c++/clang-test.cpp
 create mode 100644 tools/perf/util/c++/clang.cpp
 create mode 100644 tools/perf/util/c++/clang.h

diff --git a/tools/perf/tests/Build b/tools/perf/tests/Build
index af3ec94869aa..6676c2dd6dcb 100644
--- a/tools/perf/tests/Build
+++ b/tools/perf/tests/Build
@@ -43,6 +43,7 @@ perf-y += sdt.o
 perf-y += is_printable_array.o
 perf-y += bitmap.o
 perf-y += perf-hooks.o
+perf-y += clang.o
 
 $(OUTPUT)tests/llvm-src-base.c: tests/bpf-script-example.c tests/Build
$(call rule_mkdir)
diff --git a/tools/perf/tests/builtin-test.c b/tools/perf/tests/builtin-test.c
index d1bec0444be7..23605202d4a1 100644
--- a/tools/perf/tests/builtin-test.c
+++ b/tools/perf/tests/builtin-test.c
@@ -234,6 +234,15 @@ static struct test generic_tests[] = {
.func = test__perf_hooks,
},
{
+   .desc = "builtin clang support",
+   .func = test__clang,
+   .subtest = {
+   .skip_if_fail   = true,
+   .get_nr = test__clang_subtest_get_nr,
+   .get_desc   = test__clang_subtest_get_desc,
+   }
+   },
+   {
.func = NULL,
},
 };
diff --git a/tools/perf/tests/clang.c b/tools/perf/tests/clang.c
new file mode 100644
index ..636d6d0e9037
--- /dev/null
+++ b/tools/perf/tests/clang.c
@@ -0,0 +1,42 @@
+#include "tests.h"
+#include "debug.h"
+#include "util.h"
+#include "c++/clang-c.h"
+
+static struct {
+   int (*func)(void);
+   const char *desc;
+} clang_testcase_table[] = {
+#ifdef HAVE_LIBCLANGLLVM_SUPPORT
+   {
+   .func = test__clang_to_IR,
+   .desc = "builtin clang compile C source to IR",
+   },
+#endif
+};
+
+int test__clang_subtest_get_nr(void)
+{
+   return (int)ARRAY_SIZE(clang_testcase_table);
+}
+
+const char *test__clang_subtest_get_desc(int i)
+{
+   if (i < 0 || i >= (int)ARRAY_SIZE(clang_testcase_table))
+   return NULL;
+   return clang_testcase_table[i].desc;
+}
+
+#ifndef HAVE_LIBCLANGLLVM_SUPPORT
+int test__clang(int i __maybe_unused)
+{
+   return TEST_SKIP;
+}
+#else
+int test__clang(int i __maybe_unused)
+{
+   if (i < 0 || i >= (int)ARRAY_SIZE(clang_testcase_table))
+   return TEST_FAIL;
+   return clang_testcase_table[i].func();
+}
+#endif
diff --git a/tools/perf/tests/tests.h b/tools/perf/tests/tests.h
index 3a1f98f291ba..0d7b251305af 100644
--- a/tools/perf/tests/tests.h
+++ b/tools/perf/tests/tests.h
@@ -92,6 +92,9 @@ int test__sdt_event(int subtest);
 int test__is_printable_array(int subtest);
 int test__bitmap_print(int subtest);
 int test__perf_hooks(int 

[PATCH 01/20] tools build: Make fixdep parsing wait for last target

[Arnaldo Carvalho de Melo]

From: Jiri Olsa 

The fixdep tool, among other things, replaces the target of the object
in the gcc generated dependency output file.

The parsing code assumes there's only single target in the rule but this
is not always the case as described in here:

  https://gcc.gnu.org/ml/gcc-help/2016-11/msg00099.html

Make the fixdep code smart enough to skip all the possible targets.

Signed-off-by: Jiri Olsa 
Tested-by: Arnaldo Carvalho de Melo 
Acked-by: Peter Foley 
Cc: Wang Nan 
Link: http://lkml.kernel.org/r/20161201130025.GA16430@krava
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/build/fixdep.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/tools/build/fixdep.c b/tools/build/fixdep.c
index 1521d36cef0d..734d1547cbae 100644
--- a/tools/build/fixdep.c
+++ b/tools/build/fixdep.c
@@ -49,7 +49,7 @@ static void parse_dep_file(void *map, size_t len)
char *end = m + len;
char *p;
char s[PATH_MAX];
-   int is_target;
+   int is_target, has_target = 0;
int saw_any_target = 0;
int is_first_dep = 0;
 
@@ -67,7 +67,8 @@ static void parse_dep_file(void *map, size_t len)
if (is_target) {
/* The /next/ file is the first dependency */
is_first_dep = 1;
-   } else {
+   has_target = 1;
+   } else if (has_target) {
/* Save this token/filename */
memcpy(s, m, p-m);
s[p - m] = 0;
-- 
2.9.3

[PATCH 08/20] perf clang: Add builtin clang support ant test case

[Arnaldo Carvalho de Melo]

From: Wang Nan 

Add basic clang support in clang.cpp and test__clang() testcase. The
first testcase checks if builtin clang is able to generate LLVM IR.

tests/clang.c is a proxy. Real testcase resides in
utils/c++/clang-test.cpp in c++ and exports C interface to perf test
subsystem.

Test result:

   $ perf test -v clang
   51: builtin clang support   :
   51.1: Test builtin clang compile C source to IR  :
   --- start ---
   test child forked, pid 13215
   test child finished with 0
    end 
   Test builtin clang support subtest 0: Ok

Committer note:

Make sure you've enabled CLANG and LLVM builtin support by setting
the LIBCLANGLLVM variable on the make command line, e.g.:

  make LIBCLANGLLVM=1 O=/tmp/build/perf -C tools/perf install-bin

Otherwise you'll get this when trying to do the 'perf test' call above:

  # perf test clang
  51: builtin clang support  : Skip (not compiled in)
  #

Signed-off-by: Wang Nan 
Tested-by: Arnaldo Carvalho de Melo 
Cc: Alexei Starovoitov 
Cc: He Kuang 
Cc: Jiri Olsa 
Cc: Joe Stringer 
Cc: Zefan Li 
Cc: pi3or...@163.com
Link: http://lkml.kernel.org/r/20161126070354.141764-11-wangn...@huawei.com
[ Removed "Test" from descriptions, redundant and already removed from all the 
other entries ]
Signed-off-by: Arnaldo Carvalho de Melo 

Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/tests/Build |  1 +
 tools/perf/tests/builtin-test.c|  9 
 tools/perf/tests/clang.c   | 42 +
 tools/perf/tests/tests.h   |  3 ++
 tools/perf/util/Build  |  2 +
 tools/perf/util/c++/Build  |  2 +
 tools/perf/util/c++/clang-c.h  | 16 +++
 tools/perf/util/c++/clang-test.cpp | 31 
 tools/perf/util/c++/clang.cpp  | 96 ++
 tools/perf/util/c++/clang.h| 16 +++
 10 files changed, 218 insertions(+)
 create mode 100644 tools/perf/tests/clang.c
 create mode 100644 tools/perf/util/c++/Build
 create mode 100644 tools/perf/util/c++/clang-c.h
 create mode 100644 tools/perf/util/c++/clang-test.cpp
 create mode 100644 tools/perf/util/c++/clang.cpp
 create mode 100644 tools/perf/util/c++/clang.h

diff --git a/tools/perf/tests/Build b/tools/perf/tests/Build
index af3ec94869aa..6676c2dd6dcb 100644
--- a/tools/perf/tests/Build
+++ b/tools/perf/tests/Build
@@ -43,6 +43,7 @@ perf-y += sdt.o
 perf-y += is_printable_array.o
 perf-y += bitmap.o
 perf-y += perf-hooks.o
+perf-y += clang.o
 
 $(OUTPUT)tests/llvm-src-base.c: tests/bpf-script-example.c tests/Build
$(call rule_mkdir)
diff --git a/tools/perf/tests/builtin-test.c b/tools/perf/tests/builtin-test.c
index d1bec0444be7..23605202d4a1 100644
--- a/tools/perf/tests/builtin-test.c
+++ b/tools/perf/tests/builtin-test.c
@@ -234,6 +234,15 @@ static struct test generic_tests[] = {
.func = test__perf_hooks,
},
{
+   .desc = "builtin clang support",
+   .func = test__clang,
+   .subtest = {
+   .skip_if_fail   = true,
+   .get_nr = test__clang_subtest_get_nr,
+   .get_desc   = test__clang_subtest_get_desc,
+   }
+   },
+   {
.func = NULL,
},
 };
diff --git a/tools/perf/tests/clang.c b/tools/perf/tests/clang.c
new file mode 100644
index ..636d6d0e9037
--- /dev/null
+++ b/tools/perf/tests/clang.c
@@ -0,0 +1,42 @@
+#include "tests.h"
+#include "debug.h"
+#include "util.h"
+#include "c++/clang-c.h"
+
+static struct {
+   int (*func)(void);
+   const char *desc;
+} clang_testcase_table[] = {
+#ifdef HAVE_LIBCLANGLLVM_SUPPORT
+   {
+   .func = test__clang_to_IR,
+   .desc = "builtin clang compile C source to IR",
+   },
+#endif
+};
+
+int test__clang_subtest_get_nr(void)
+{
+   return (int)ARRAY_SIZE(clang_testcase_table);
+}
+
+const char *test__clang_subtest_get_desc(int i)
+{
+   if (i < 0 || i >= (int)ARRAY_SIZE(clang_testcase_table))
+   return NULL;
+   return clang_testcase_table[i].desc;
+}
+
+#ifndef HAVE_LIBCLANGLLVM_SUPPORT
+int test__clang(int i __maybe_unused)
+{
+   return TEST_SKIP;
+}
+#else
+int test__clang(int i __maybe_unused)
+{
+   if (i < 0 || i >= (int)ARRAY_SIZE(clang_testcase_table))
+   return TEST_FAIL;
+   return clang_testcase_table[i].func();
+}
+#endif
diff --git a/tools/perf/tests/tests.h b/tools/perf/tests/tests.h
index 3a1f98f291ba..0d7b251305af 100644
--- a/tools/perf/tests/tests.h
+++ b/tools/perf/tests/tests.h
@@ -92,6 +92,9 @@ int test__sdt_event(int subtest);
 int test__is_printable_array(int subtest);
 int test__bitmap_print(int subtest);
 int test__perf_hooks(int subtest);
+int test__clang(int subtest);
+const char *test__clang_subtest_get_desc(int subtest);
+int test__clang_subtest_get_nr(void);
 
 #if defined(__arm__) || 

[PATCH 01/20] tools build: Make fixdep parsing wait for last target

[Arnaldo Carvalho de Melo]

From: Jiri Olsa 

The fixdep tool, among other things, replaces the target of the object
in the gcc generated dependency output file.

The parsing code assumes there's only single target in the rule but this
is not always the case as described in here:

  https://gcc.gnu.org/ml/gcc-help/2016-11/msg00099.html

Make the fixdep code smart enough to skip all the possible targets.

Signed-off-by: Jiri Olsa 
Tested-by: Arnaldo Carvalho de Melo 
Acked-by: Peter Foley 
Cc: Wang Nan 
Link: http://lkml.kernel.org/r/20161201130025.GA16430@krava
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/build/fixdep.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/tools/build/fixdep.c b/tools/build/fixdep.c
index 1521d36cef0d..734d1547cbae 100644
--- a/tools/build/fixdep.c
+++ b/tools/build/fixdep.c
@@ -49,7 +49,7 @@ static void parse_dep_file(void *map, size_t len)
char *end = m + len;
char *p;
char s[PATH_MAX];
-   int is_target;
+   int is_target, has_target = 0;
int saw_any_target = 0;
int is_first_dep = 0;
 
@@ -67,7 +67,8 @@ static void parse_dep_file(void *map, size_t len)
if (is_target) {
/* The /next/ file is the first dependency */
is_first_dep = 1;
-   } else {
+   has_target = 1;
+   } else if (has_target) {
/* Save this token/filename */
memcpy(s, m, p-m);
s[p - m] = 0;
-- 
2.9.3

[PATCH 06/20] tools build: Add feature detection for clang

[Arnaldo Carvalho de Melo]

From: Wang Nan 

Check if basic clang compiling environment is ready.

Doesn't like 'llvm-config --libs' which can returns llvm libraries in right
order and duplicates some libraries if necessary, there's no correspondence for
clang libraries (-lclangxxx). to avoid extra complexity and to avoid new clang
breaking libraries ordering, use --start-group and --end-group.

In this test case, manually identify required clang libs and hope it to be
stable. Putting all clang libraries here is possible (use make's wildcard), but
then feature checking becomes very slow.

Signed-off-by: Wang Nan 
Cc: Alexei Starovoitov 
Cc: He Kuang 
Cc: Jiri Olsa 
Cc: Joe Stringer 
Cc: Zefan Li 
Cc: pi3or...@163.com
Link: http://lkml.kernel.org/r/20161126070354.141764-9-wangn...@huawei.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/build/feature/Makefile   | 10 ++
 tools/build/feature/test-clang.cpp | 21 +
 2 files changed, 31 insertions(+)
 create mode 100644 tools/build/feature/test-clang.cpp

diff --git a/tools/build/feature/Makefile b/tools/build/feature/Makefile
index c09de59affc9..871d5536951d 100644
--- a/tools/build/feature/Makefile
+++ b/tools/build/feature/Makefile
@@ -237,6 +237,16 @@ $(OUTPUT)test-llvm.bin:
$(shell $(LLVM_CONFIG) --libs Core BPF) \
$(shell $(LLVM_CONFIG) --system-libs)
 
+$(OUTPUT)test-clang.bin:
+   $(BUILDXX) -std=gnu++11 \
+   -I$(shell $(LLVM_CONFIG) --includedir)  \
+   -L$(shell $(LLVM_CONFIG) --libdir)  \
+   -Wl,--start-group -lclangBasic -lclangDriver\
+ -lclangFrontend -lclangEdit -lclangLex\
+ -lclangAST -Wl,--end-group\
+   $(shell $(LLVM_CONFIG) --libs Core option)  \
+   $(shell $(LLVM_CONFIG) --system-libs)
+
 -include $(OUTPUT)*.d
 
 ###
diff --git a/tools/build/feature/test-clang.cpp 
b/tools/build/feature/test-clang.cpp
new file mode 100644
index ..e23c1b1f1b91
--- /dev/null
+++ b/tools/build/feature/test-clang.cpp
@@ -0,0 +1,21 @@
+#include "clang/Basic/VirtualFileSystem.h"
+#include "clang/Driver/Driver.h"
+#include "clang/Frontend/TextDiagnosticPrinter.h"
+#include "llvm/ADT/IntrusiveRefCntPtr.h"
+#include "llvm/Support/ManagedStatic.h"
+#include "llvm/Support/raw_ostream.h"
+
+using namespace clang;
+using namespace clang::driver;
+
+int main()
+{
+   IntrusiveRefCntPtr DiagID(new DiagnosticIDs());
+   IntrusiveRefCntPtr DiagOpts = new 
DiagnosticOptions();
+
+   DiagnosticsEngine Diags(DiagID, &*DiagOpts);
+   Driver TheDriver("test", "bpf-pc-linux", Diags);
+
+   llvm::llvm_shutdown();
+   return 0;
+}
-- 
2.9.3

[PATCH 09/20] perf clang: Use real file system for #include

[Arnaldo Carvalho de Melo]

From: Wang Nan 

Utilize clang's OverlayFileSystem facility, allow CompilerInstance to
access real file system.

With this patch the '#include' directive can be used.

Add a new getModuleFromSource for real file.

Signed-off-by: Wang Nan 
Cc: Alexei Starovoitov 
Cc: He Kuang 
Cc: Jiri Olsa 
Cc: Joe Stringer 
Cc: Zefan Li 
Cc: pi3or...@163.com
Link: http://lkml.kernel.org/r/20161126070354.141764-12-wangn...@huawei.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/c++/clang.cpp | 44 +++
 tools/perf/util/c++/clang.h   |  3 +++
 2 files changed, 35 insertions(+), 12 deletions(-)

diff --git a/tools/perf/util/c++/clang.cpp b/tools/perf/util/c++/clang.cpp
index c17b1176e25d..cf96199b4b6f 100644
--- a/tools/perf/util/c++/clang.cpp
+++ b/tools/perf/util/c++/clang.cpp
@@ -15,6 +15,7 @@
 #include "clang/Tooling/Tooling.h"
 #include "llvm/IR/Module.h"
 #include "llvm/Option/Option.h"
+#include "llvm/Support/FileSystem.h"
 #include "llvm/Support/ManagedStatic.h"
 #include 
 
@@ -27,14 +28,6 @@ static std::unique_ptr LLVMCtx;
 
 using namespace clang;
 
-static vfs::InMemoryFileSystem *
-buildVFS(StringRef& Name, StringRef& Content)
-{
-   vfs::InMemoryFileSystem *VFS = new vfs::InMemoryFileSystem(true);
-   VFS->addFile(Twine(Name), 0, llvm::MemoryBuffer::getMemBuffer(Content));
-   return VFS;
-}
-
 static CompilerInvocation *
 createCompilerInvocation(StringRef& Path, DiagnosticsEngine& Diags)
 {
@@ -60,17 +53,17 @@ createCompilerInvocation(StringRef& Path, 
DiagnosticsEngine& Diags)
return CI;
 }
 
-std::unique_ptr
-getModuleFromSource(StringRef Name, StringRef Content)
+static std::unique_ptr
+getModuleFromSource(StringRef Path,
+   IntrusiveRefCntPtr VFS)
 {
CompilerInstance Clang;
Clang.createDiagnostics();
 
-   IntrusiveRefCntPtr VFS = buildVFS(Name, Content);
Clang.setVirtualFileSystem(&*VFS);
 
IntrusiveRefCntPtr CI =
-   createCompilerInvocation(Name, Clang.getDiagnostics());
+   createCompilerInvocation(Path, Clang.getDiagnostics());
Clang.setInvocation(&*CI);
 
std::unique_ptr Act(new EmitLLVMOnlyAction(&*LLVMCtx));
@@ -80,6 +73,33 @@ getModuleFromSource(StringRef Name, StringRef Content)
return Act->takeModule();
 }
 
+std::unique_ptr
+getModuleFromSource(StringRef Name, StringRef Content)
+{
+   using namespace vfs;
+
+   llvm::IntrusiveRefCntPtr OverlayFS(
+   new OverlayFileSystem(getRealFileSystem()));
+   llvm::IntrusiveRefCntPtr MemFS(
+   new InMemoryFileSystem(true));
+
+   /*
+* pushOverlay helps setting working dir for MemFS. Must call
+* before addFile.
+*/
+   OverlayFS->pushOverlay(MemFS);
+   MemFS->addFile(Twine(Name), 0, 
llvm::MemoryBuffer::getMemBuffer(Content));
+
+   return getModuleFromSource(Name, OverlayFS);
+}
+
+std::unique_ptr
+getModuleFromSource(StringRef Path)
+{
+   IntrusiveRefCntPtr VFS(vfs::getRealFileSystem());
+   return getModuleFromSource(Path, VFS);
+}
+
 }
 
 extern "C" {
diff --git a/tools/perf/util/c++/clang.h b/tools/perf/util/c++/clang.h
index f64483be43d0..90aff0162f1c 100644
--- a/tools/perf/util/c++/clang.h
+++ b/tools/perf/util/c++/clang.h
@@ -12,5 +12,8 @@ using namespace llvm;
 std::unique_ptr
 getModuleFromSource(StringRef Name, StringRef Content);
 
+std::unique_ptr
+getModuleFromSource(StringRef Path);
+
 }
 #endif
-- 
2.9.3

[PATCH 15/20] tools build: Move tabs to spaces where suitable

[Arnaldo Carvalho de Melo]

From: Jiri Olsa 

We've been hit several times by a Makefile bug where line indented by
tab was falsely considered as target command.

We prevent this by always using space indentation for everything except
for the target commands.

Signed-off-by: Jiri Olsa 
Cc: David Ahern 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/r/1480884178-8072-3-git-send-email-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/build/Build.include|  12 ++--
 tools/build/Makefile.feature | 138 +--
 tools/build/feature/Makefile | 102 
 3 files changed, 126 insertions(+), 126 deletions(-)

diff --git a/tools/build/Build.include b/tools/build/Build.include
index 475152c52871..418871d02ebf 100644
--- a/tools/build/Build.include
+++ b/tools/build/Build.include
@@ -72,15 +72,15 @@ dep-cmd = $(if $(wildcard $(fixdep)),
 #   target, or command line has changed and update
 #   dependencies in the cmd file
 if_changed_dep = $(if $(strip $(any-prereq) $(arg-check)), \
-   @set -e;   \
-   $(echo-cmd) $(cmd_$(1)) && $(dep-cmd))
+  @set -e; \
+  $(echo-cmd) $(cmd_$(1)) && $(dep-cmd))
 
 # if_changed  - execute command if any prerequisite is newer than
 #   target, or command line has changed
-if_changed = $(if $(strip $(any-prereq) $(arg-check)), \
-   @set -e;   \
-   $(echo-cmd) $(cmd_$(1));   \
-   printf '%s\n' 'cmd_$@ := $(make-cmd)' > $(dot-target).cmd)
+if_changed = $(if $(strip $(any-prereq) $(arg-check)),   \
+  @set -e;   \
+  $(echo-cmd) $(cmd_$(1));   \
+  printf '%s\n' 'cmd_$@ := $(make-cmd)' > $(dot-target).cmd)
 
 ###
 # C flags to be used in rule definitions, includes:
diff --git a/tools/build/Makefile.feature b/tools/build/Makefile.feature
index ae52e029dd22..e3fb5ecbdcb6 100644
--- a/tools/build/Makefile.feature
+++ b/tools/build/Makefile.feature
@@ -27,58 +27,58 @@ endef
 #   the rule that uses them - an example for that is the 'bionic'
 #   feature check. ]
 #
-FEATURE_TESTS_BASIC := \
-   backtrace   \
-   dwarf   \
-   dwarf_getlocations  \
-   fortify-source  \
-   sync-compare-and-swap   \
-   glibc   \
-   gtk2\
-   gtk2-infobar\
-   libaudit\
-   libbfd  \
-   libelf  \
-   libelf-getphdrnum   \
-   libelf-gelf_getnote \
-   libelf-getshdrstrndx\
-   libelf-mmap \
-   libnuma \
-   numa_num_possible_cpus  \
-   libperl \
-   libpython   \
-   libpython-version   \
-   libslang\
-   libcrypto   \
-   libunwind   \
-   libunwind-x86   \
-   libunwind-x86_64\
-   libunwind-arm   \
-   libunwind-aarch64   \
-   pthread-attr-setaffinity-np \
-   stackprotector-all  \
-   timerfd \
-   libdw-dwarf-unwind  \
-   zlib\
-   lzma\
-   get_cpuid   \
-   bpf \
-   sdt
+FEATURE_TESTS_BASIC :=  \
+backtrace   \
+dwarf   \
+dwarf_getlocations  \
+fortify-source  \
+sync-compare-and-swap   \
+glibc   \
+gtk2\
+gtk2-infobar\
+libaudit\
+libbfd  \
+libelf  \
+libelf-getphdrnum   \
+libelf-gelf_getnote \
+libelf-getshdrstrndx\
+libelf-mmap \
+libnuma \
+numa_num_possible_cpus  \
+libperl \
+libpython   \
+libpython-version   \
+libslang

[PATCH 11/20] perf clang: Update test case to use real BPF script

[Arnaldo Carvalho de Melo]

From: Wang Nan 

Allow C++ code to use util.h and tests/llvm.h. Let 'perf test' compile a
real BPF script.

Signed-off-by: Wang Nan 
Cc: Alexei Starovoitov 
Cc: He Kuang 
Cc: Jiri Olsa 
Cc: Joe Stringer 
Cc: Zefan Li 
Cc: pi3or...@163.com
Link: http://lkml.kernel.org/r/20161126070354.141764-14-wangn...@huawei.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/Makefile.config | 27 +++
 tools/perf/tests/llvm.h|  7 +++
 tools/perf/util/c++/clang-test.cpp | 17 ++---
 tools/perf/util/util-cxx.h | 26 ++
 4 files changed, 62 insertions(+), 15 deletions(-)
 create mode 100644 tools/perf/util/util-cxx.h

diff --git a/tools/perf/Makefile.config b/tools/perf/Makefile.config
index b7c9c8051a33..09c2a9874f2f 100644
--- a/tools/perf/Makefile.config
+++ b/tools/perf/Makefile.config
@@ -212,24 +212,27 @@ ifeq ($(DEBUG),0)
   endif
 endif
 
-CFLAGS += -I$(src-perf)/util/include
-CFLAGS += -I$(src-perf)/arch/$(ARCH)/include
-CFLAGS += -I$(srctree)/tools/include/uapi
-CFLAGS += -I$(srctree)/tools/include/
-CFLAGS += -I$(srctree)/tools/arch/$(ARCH)/include/uapi
-CFLAGS += -I$(srctree)/tools/arch/$(ARCH)/include/
-CFLAGS += -I$(srctree)/tools/arch/$(ARCH)/
+INC_FLAGS += -I$(src-perf)/util/include
+INC_FLAGS += -I$(src-perf)/arch/$(ARCH)/include
+INC_FLAGS += -I$(srctree)/tools/include/uapi
+INC_FLAGS += -I$(srctree)/tools/include/
+INC_FLAGS += -I$(srctree)/tools/arch/$(ARCH)/include/uapi
+INC_FLAGS += -I$(srctree)/tools/arch/$(ARCH)/include/
+INC_FLAGS += -I$(srctree)/tools/arch/$(ARCH)/
 
 # $(obj-perf)  for generated common-cmds.h
 # $(obj-perf)/util for generated bison/flex headers
 ifneq ($(OUTPUT),)
-CFLAGS += -I$(obj-perf)/util
-CFLAGS += -I$(obj-perf)
+INC_FLAGS += -I$(obj-perf)/util
+INC_FLAGS += -I$(obj-perf)
 endif
 
-CFLAGS += -I$(src-perf)/util
-CFLAGS += -I$(src-perf)
-CFLAGS += -I$(srctree)/tools/lib/
+INC_FLAGS += -I$(src-perf)/util
+INC_FLAGS += -I$(src-perf)
+INC_FLAGS += -I$(srctree)/tools/lib/
+
+CFLAGS   += $(INC_FLAGS)
+CXXFLAGS += $(INC_FLAGS)
 
 CFLAGS += -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE
 
diff --git a/tools/perf/tests/llvm.h b/tools/perf/tests/llvm.h
index 0eaa604be99d..b83571758d83 100644
--- a/tools/perf/tests/llvm.h
+++ b/tools/perf/tests/llvm.h
@@ -1,6 +1,10 @@
 #ifndef PERF_TEST_LLVM_H
 #define PERF_TEST_LLVM_H
 
+#ifdef __cplusplus
+extern "C" {
+#endif
+
 #include  /* for size_t */
 #include  /* for bool */
 
@@ -20,4 +24,7 @@ enum test_llvm__testcase {
 int test_llvm__fetch_bpf_obj(void **p_obj_buf, size_t *p_obj_buf_sz,
 enum test_llvm__testcase index, bool force,
 bool *should_load_fail);
+#ifdef __cplusplus
+}
+#endif
 #endif
diff --git a/tools/perf/util/c++/clang-test.cpp 
b/tools/perf/util/c++/clang-test.cpp
index 0f484fbb2b58..d84e760d2aab 100644
--- a/tools/perf/util/c++/clang-test.cpp
+++ b/tools/perf/util/c++/clang-test.cpp
@@ -3,6 +3,10 @@
 #include "llvm/IR/Function.h"
 #include "llvm/IR/LLVMContext.h"
 
+#include 
+#include 
+#include 
+
 class perf_clang_scope {
 public:
explicit perf_clang_scope() {perf_clang__init();}
@@ -14,17 +18,24 @@ extern "C" {
 int test__clang_to_IR(void)
 {
perf_clang_scope _scope;
+   unsigned int kernel_version;
+
+   if (fetch_kernel_version(_version, NULL, 0))
+   return -1;
+
+   std::string cflag_kver("-DLINUX_VERSION_CODE=" +
+   std::to_string(kernel_version));
 
std::unique_ptr M =
-   perf::getModuleFromSource({"-DRESULT=1"},
+   perf::getModuleFromSource({cflag_kver.c_str()},
  "perf-test.c",
- "int myfunc(void) {return RESULT;}");
+ test_llvm__bpf_base_prog);
 
if (!M)
return -1;
 
for (llvm::Function& F : *M)
-   if (F.getName() == "myfunc")
+   if (F.getName() == "bpf_func__SyS_epoll_wait")
return 0;
return -1;
 }
diff --git a/tools/perf/util/util-cxx.h b/tools/perf/util/util-cxx.h
new file mode 100644
index ..0e0e019c9f34
--- /dev/null
+++ b/tools/perf/util/util-cxx.h
@@ -0,0 +1,26 @@
+/*
+ * Support C++ source use utilities defined in util.h
+ */
+
+#ifndef PERF_UTIL_UTIL_CXX_H
+#define PERF_UTIL_UTIL_CXX_H
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+/*
+ * Now 'new' is the only C++ keyword found in util.h:
+ * in tools/include/linux/rbtree.h
+ *
+ * Other keywords, like class and delete, should be
+ * redefined if necessary.
+ */
+#define new _new
+#include "util.h"
+#undef new
+
+#ifdef __cplusplus
+}
+#endif
+#endif
-- 
2.9.3

[PATCH 06/20] tools build: Add feature detection for clang

[Arnaldo Carvalho de Melo]

From: Wang Nan 

Check if basic clang compiling environment is ready.

Doesn't like 'llvm-config --libs' which can returns llvm libraries in right
order and duplicates some libraries if necessary, there's no correspondence for
clang libraries (-lclangxxx). to avoid extra complexity and to avoid new clang
breaking libraries ordering, use --start-group and --end-group.

In this test case, manually identify required clang libs and hope it to be
stable. Putting all clang libraries here is possible (use make's wildcard), but
then feature checking becomes very slow.

Signed-off-by: Wang Nan 
Cc: Alexei Starovoitov 
Cc: He Kuang 
Cc: Jiri Olsa 
Cc: Joe Stringer 
Cc: Zefan Li 
Cc: pi3or...@163.com
Link: http://lkml.kernel.org/r/20161126070354.141764-9-wangn...@huawei.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/build/feature/Makefile   | 10 ++
 tools/build/feature/test-clang.cpp | 21 +
 2 files changed, 31 insertions(+)
 create mode 100644 tools/build/feature/test-clang.cpp

diff --git a/tools/build/feature/Makefile b/tools/build/feature/Makefile
index c09de59affc9..871d5536951d 100644
--- a/tools/build/feature/Makefile
+++ b/tools/build/feature/Makefile
@@ -237,6 +237,16 @@ $(OUTPUT)test-llvm.bin:
$(shell $(LLVM_CONFIG) --libs Core BPF) \
$(shell $(LLVM_CONFIG) --system-libs)
 
+$(OUTPUT)test-clang.bin:
+   $(BUILDXX) -std=gnu++11 \
+   -I$(shell $(LLVM_CONFIG) --includedir)  \
+   -L$(shell $(LLVM_CONFIG) --libdir)  \
+   -Wl,--start-group -lclangBasic -lclangDriver\
+ -lclangFrontend -lclangEdit -lclangLex\
+ -lclangAST -Wl,--end-group\
+   $(shell $(LLVM_CONFIG) --libs Core option)  \
+   $(shell $(LLVM_CONFIG) --system-libs)
+
 -include $(OUTPUT)*.d
 
 ###
diff --git a/tools/build/feature/test-clang.cpp 
b/tools/build/feature/test-clang.cpp
new file mode 100644
index ..e23c1b1f1b91
--- /dev/null
+++ b/tools/build/feature/test-clang.cpp
@@ -0,0 +1,21 @@
+#include "clang/Basic/VirtualFileSystem.h"
+#include "clang/Driver/Driver.h"
+#include "clang/Frontend/TextDiagnosticPrinter.h"
+#include "llvm/ADT/IntrusiveRefCntPtr.h"
+#include "llvm/Support/ManagedStatic.h"
+#include "llvm/Support/raw_ostream.h"
+
+using namespace clang;
+using namespace clang::driver;
+
+int main()
+{
+   IntrusiveRefCntPtr DiagID(new DiagnosticIDs());
+   IntrusiveRefCntPtr DiagOpts = new 
DiagnosticOptions();
+
+   DiagnosticsEngine Diags(DiagID, &*DiagOpts);
+   Driver TheDriver("test", "bpf-pc-linux", Diags);
+
+   llvm::llvm_shutdown();
+   return 0;
+}
-- 
2.9.3

[PATCH 09/20] perf clang: Use real file system for #include

[Arnaldo Carvalho de Melo]

From: Wang Nan 

Utilize clang's OverlayFileSystem facility, allow CompilerInstance to
access real file system.

With this patch the '#include' directive can be used.

Add a new getModuleFromSource for real file.

Signed-off-by: Wang Nan 
Cc: Alexei Starovoitov 
Cc: He Kuang 
Cc: Jiri Olsa 
Cc: Joe Stringer 
Cc: Zefan Li 
Cc: pi3or...@163.com
Link: http://lkml.kernel.org/r/20161126070354.141764-12-wangn...@huawei.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/c++/clang.cpp | 44 +++
 tools/perf/util/c++/clang.h   |  3 +++
 2 files changed, 35 insertions(+), 12 deletions(-)

diff --git a/tools/perf/util/c++/clang.cpp b/tools/perf/util/c++/clang.cpp
index c17b1176e25d..cf96199b4b6f 100644
--- a/tools/perf/util/c++/clang.cpp
+++ b/tools/perf/util/c++/clang.cpp
@@ -15,6 +15,7 @@
 #include "clang/Tooling/Tooling.h"
 #include "llvm/IR/Module.h"
 #include "llvm/Option/Option.h"
+#include "llvm/Support/FileSystem.h"
 #include "llvm/Support/ManagedStatic.h"
 #include 
 
@@ -27,14 +28,6 @@ static std::unique_ptr LLVMCtx;
 
 using namespace clang;
 
-static vfs::InMemoryFileSystem *
-buildVFS(StringRef& Name, StringRef& Content)
-{
-   vfs::InMemoryFileSystem *VFS = new vfs::InMemoryFileSystem(true);
-   VFS->addFile(Twine(Name), 0, llvm::MemoryBuffer::getMemBuffer(Content));
-   return VFS;
-}
-
 static CompilerInvocation *
 createCompilerInvocation(StringRef& Path, DiagnosticsEngine& Diags)
 {
@@ -60,17 +53,17 @@ createCompilerInvocation(StringRef& Path, 
DiagnosticsEngine& Diags)
return CI;
 }
 
-std::unique_ptr
-getModuleFromSource(StringRef Name, StringRef Content)
+static std::unique_ptr
+getModuleFromSource(StringRef Path,
+   IntrusiveRefCntPtr VFS)
 {
CompilerInstance Clang;
Clang.createDiagnostics();
 
-   IntrusiveRefCntPtr VFS = buildVFS(Name, Content);
Clang.setVirtualFileSystem(&*VFS);
 
IntrusiveRefCntPtr CI =
-   createCompilerInvocation(Name, Clang.getDiagnostics());
+   createCompilerInvocation(Path, Clang.getDiagnostics());
Clang.setInvocation(&*CI);
 
std::unique_ptr Act(new EmitLLVMOnlyAction(&*LLVMCtx));
@@ -80,6 +73,33 @@ getModuleFromSource(StringRef Name, StringRef Content)
return Act->takeModule();
 }
 
+std::unique_ptr
+getModuleFromSource(StringRef Name, StringRef Content)
+{
+   using namespace vfs;
+
+   llvm::IntrusiveRefCntPtr OverlayFS(
+   new OverlayFileSystem(getRealFileSystem()));
+   llvm::IntrusiveRefCntPtr MemFS(
+   new InMemoryFileSystem(true));
+
+   /*
+* pushOverlay helps setting working dir for MemFS. Must call
+* before addFile.
+*/
+   OverlayFS->pushOverlay(MemFS);
+   MemFS->addFile(Twine(Name), 0, 
llvm::MemoryBuffer::getMemBuffer(Content));
+
+   return getModuleFromSource(Name, OverlayFS);
+}
+
+std::unique_ptr
+getModuleFromSource(StringRef Path)
+{
+   IntrusiveRefCntPtr VFS(vfs::getRealFileSystem());
+   return getModuleFromSource(Path, VFS);
+}
+
 }
 
 extern "C" {
diff --git a/tools/perf/util/c++/clang.h b/tools/perf/util/c++/clang.h
index f64483be43d0..90aff0162f1c 100644
--- a/tools/perf/util/c++/clang.h
+++ b/tools/perf/util/c++/clang.h
@@ -12,5 +12,8 @@ using namespace llvm;
 std::unique_ptr
 getModuleFromSource(StringRef Name, StringRef Content);
 
+std::unique_ptr
+getModuleFromSource(StringRef Path);
+
 }
 #endif
-- 
2.9.3

[PATCH 15/20] tools build: Move tabs to spaces where suitable

[Arnaldo Carvalho de Melo]

From: Jiri Olsa 

We've been hit several times by a Makefile bug where line indented by
tab was falsely considered as target command.

We prevent this by always using space indentation for everything except
for the target commands.

Signed-off-by: Jiri Olsa 
Cc: David Ahern 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/r/1480884178-8072-3-git-send-email-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/build/Build.include|  12 ++--
 tools/build/Makefile.feature | 138 +--
 tools/build/feature/Makefile | 102 
 3 files changed, 126 insertions(+), 126 deletions(-)

diff --git a/tools/build/Build.include b/tools/build/Build.include
index 475152c52871..418871d02ebf 100644
--- a/tools/build/Build.include
+++ b/tools/build/Build.include
@@ -72,15 +72,15 @@ dep-cmd = $(if $(wildcard $(fixdep)),
 #   target, or command line has changed and update
 #   dependencies in the cmd file
 if_changed_dep = $(if $(strip $(any-prereq) $(arg-check)), \
-   @set -e;   \
-   $(echo-cmd) $(cmd_$(1)) && $(dep-cmd))
+  @set -e; \
+  $(echo-cmd) $(cmd_$(1)) && $(dep-cmd))
 
 # if_changed  - execute command if any prerequisite is newer than
 #   target, or command line has changed
-if_changed = $(if $(strip $(any-prereq) $(arg-check)), \
-   @set -e;   \
-   $(echo-cmd) $(cmd_$(1));   \
-   printf '%s\n' 'cmd_$@ := $(make-cmd)' > $(dot-target).cmd)
+if_changed = $(if $(strip $(any-prereq) $(arg-check)),   \
+  @set -e;   \
+  $(echo-cmd) $(cmd_$(1));   \
+  printf '%s\n' 'cmd_$@ := $(make-cmd)' > $(dot-target).cmd)
 
 ###
 # C flags to be used in rule definitions, includes:
diff --git a/tools/build/Makefile.feature b/tools/build/Makefile.feature
index ae52e029dd22..e3fb5ecbdcb6 100644
--- a/tools/build/Makefile.feature
+++ b/tools/build/Makefile.feature
@@ -27,58 +27,58 @@ endef
 #   the rule that uses them - an example for that is the 'bionic'
 #   feature check. ]
 #
-FEATURE_TESTS_BASIC := \
-   backtrace   \
-   dwarf   \
-   dwarf_getlocations  \
-   fortify-source  \
-   sync-compare-and-swap   \
-   glibc   \
-   gtk2\
-   gtk2-infobar\
-   libaudit\
-   libbfd  \
-   libelf  \
-   libelf-getphdrnum   \
-   libelf-gelf_getnote \
-   libelf-getshdrstrndx\
-   libelf-mmap \
-   libnuma \
-   numa_num_possible_cpus  \
-   libperl \
-   libpython   \
-   libpython-version   \
-   libslang\
-   libcrypto   \
-   libunwind   \
-   libunwind-x86   \
-   libunwind-x86_64\
-   libunwind-arm   \
-   libunwind-aarch64   \
-   pthread-attr-setaffinity-np \
-   stackprotector-all  \
-   timerfd \
-   libdw-dwarf-unwind  \
-   zlib\
-   lzma\
-   get_cpuid   \
-   bpf \
-   sdt
+FEATURE_TESTS_BASIC :=  \
+backtrace   \
+dwarf   \
+dwarf_getlocations  \
+fortify-source  \
+sync-compare-and-swap   \
+glibc   \
+gtk2\
+gtk2-infobar\
+libaudit\
+libbfd  \
+libelf  \
+libelf-getphdrnum   \
+libelf-gelf_getnote \
+libelf-getshdrstrndx\
+libelf-mmap \
+libnuma \
+numa_num_possible_cpus  \
+libperl \
+libpython   \
+libpython-version   \
+libslang\
+libcrypto   \
+libunwind   \
+libunwind-x86   

[PATCH 11/20] perf clang: Update test case to use real BPF script

[Arnaldo Carvalho de Melo]

From: Wang Nan 

Allow C++ code to use util.h and tests/llvm.h. Let 'perf test' compile a
real BPF script.

Signed-off-by: Wang Nan 
Cc: Alexei Starovoitov 
Cc: He Kuang 
Cc: Jiri Olsa 
Cc: Joe Stringer 
Cc: Zefan Li 
Cc: pi3or...@163.com
Link: http://lkml.kernel.org/r/20161126070354.141764-14-wangn...@huawei.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/Makefile.config | 27 +++
 tools/perf/tests/llvm.h|  7 +++
 tools/perf/util/c++/clang-test.cpp | 17 ++---
 tools/perf/util/util-cxx.h | 26 ++
 4 files changed, 62 insertions(+), 15 deletions(-)
 create mode 100644 tools/perf/util/util-cxx.h

diff --git a/tools/perf/Makefile.config b/tools/perf/Makefile.config
index b7c9c8051a33..09c2a9874f2f 100644
--- a/tools/perf/Makefile.config
+++ b/tools/perf/Makefile.config
@@ -212,24 +212,27 @@ ifeq ($(DEBUG),0)
   endif
 endif
 
-CFLAGS += -I$(src-perf)/util/include
-CFLAGS += -I$(src-perf)/arch/$(ARCH)/include
-CFLAGS += -I$(srctree)/tools/include/uapi
-CFLAGS += -I$(srctree)/tools/include/
-CFLAGS += -I$(srctree)/tools/arch/$(ARCH)/include/uapi
-CFLAGS += -I$(srctree)/tools/arch/$(ARCH)/include/
-CFLAGS += -I$(srctree)/tools/arch/$(ARCH)/
+INC_FLAGS += -I$(src-perf)/util/include
+INC_FLAGS += -I$(src-perf)/arch/$(ARCH)/include
+INC_FLAGS += -I$(srctree)/tools/include/uapi
+INC_FLAGS += -I$(srctree)/tools/include/
+INC_FLAGS += -I$(srctree)/tools/arch/$(ARCH)/include/uapi
+INC_FLAGS += -I$(srctree)/tools/arch/$(ARCH)/include/
+INC_FLAGS += -I$(srctree)/tools/arch/$(ARCH)/
 
 # $(obj-perf)  for generated common-cmds.h
 # $(obj-perf)/util for generated bison/flex headers
 ifneq ($(OUTPUT),)
-CFLAGS += -I$(obj-perf)/util
-CFLAGS += -I$(obj-perf)
+INC_FLAGS += -I$(obj-perf)/util
+INC_FLAGS += -I$(obj-perf)
 endif
 
-CFLAGS += -I$(src-perf)/util
-CFLAGS += -I$(src-perf)
-CFLAGS += -I$(srctree)/tools/lib/
+INC_FLAGS += -I$(src-perf)/util
+INC_FLAGS += -I$(src-perf)
+INC_FLAGS += -I$(srctree)/tools/lib/
+
+CFLAGS   += $(INC_FLAGS)
+CXXFLAGS += $(INC_FLAGS)
 
 CFLAGS += -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE
 
diff --git a/tools/perf/tests/llvm.h b/tools/perf/tests/llvm.h
index 0eaa604be99d..b83571758d83 100644
--- a/tools/perf/tests/llvm.h
+++ b/tools/perf/tests/llvm.h
@@ -1,6 +1,10 @@
 #ifndef PERF_TEST_LLVM_H
 #define PERF_TEST_LLVM_H
 
+#ifdef __cplusplus
+extern "C" {
+#endif
+
 #include  /* for size_t */
 #include  /* for bool */
 
@@ -20,4 +24,7 @@ enum test_llvm__testcase {
 int test_llvm__fetch_bpf_obj(void **p_obj_buf, size_t *p_obj_buf_sz,
 enum test_llvm__testcase index, bool force,
 bool *should_load_fail);
+#ifdef __cplusplus
+}
+#endif
 #endif
diff --git a/tools/perf/util/c++/clang-test.cpp 
b/tools/perf/util/c++/clang-test.cpp
index 0f484fbb2b58..d84e760d2aab 100644
--- a/tools/perf/util/c++/clang-test.cpp
+++ b/tools/perf/util/c++/clang-test.cpp
@@ -3,6 +3,10 @@
 #include "llvm/IR/Function.h"
 #include "llvm/IR/LLVMContext.h"
 
+#include 
+#include 
+#include 
+
 class perf_clang_scope {
 public:
explicit perf_clang_scope() {perf_clang__init();}
@@ -14,17 +18,24 @@ extern "C" {
 int test__clang_to_IR(void)
 {
perf_clang_scope _scope;
+   unsigned int kernel_version;
+
+   if (fetch_kernel_version(_version, NULL, 0))
+   return -1;
+
+   std::string cflag_kver("-DLINUX_VERSION_CODE=" +
+   std::to_string(kernel_version));
 
std::unique_ptr M =
-   perf::getModuleFromSource({"-DRESULT=1"},
+   perf::getModuleFromSource({cflag_kver.c_str()},
  "perf-test.c",
- "int myfunc(void) {return RESULT;}");
+ test_llvm__bpf_base_prog);
 
if (!M)
return -1;
 
for (llvm::Function& F : *M)
-   if (F.getName() == "myfunc")
+   if (F.getName() == "bpf_func__SyS_epoll_wait")
return 0;
return -1;
 }
diff --git a/tools/perf/util/util-cxx.h b/tools/perf/util/util-cxx.h
new file mode 100644
index ..0e0e019c9f34
--- /dev/null
+++ b/tools/perf/util/util-cxx.h
@@ -0,0 +1,26 @@
+/*
+ * Support C++ source use utilities defined in util.h
+ */
+
+#ifndef PERF_UTIL_UTIL_CXX_H
+#define PERF_UTIL_UTIL_CXX_H
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+/*
+ * Now 'new' is the only C++ keyword found in util.h:
+ * in tools/include/linux/rbtree.h
+ *
+ * Other keywords, like class and delete, should be
+ * redefined if necessary.
+ */
+#define new _new
+#include "util.h"
+#undef new
+
+#ifdef __cplusplus
+}
+#endif
+#endif
-- 
2.9.3

Re: [PATCH v3] PCI/ACPI: xgene: Add ECAM quirk for X-Gene PCIe controller

[Duc Dang]

On Mon, Dec 5, 2016 at 1:20 PM, Bjorn Helgaas  wrote:
> On Fri, Dec 02, 2016 at 11:06:30PM -0800, Duc Dang wrote:
>> On Fri, Dec 2, 2016 at 3:39 PM, Bjorn Helgaas  wrote:
>
>> > diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
>> > index 8a177a1..a16fc8e 100644
>> > --- a/arch/arm64/kernel/pci.c
>> > +++ b/arch/arm64/kernel/pci.c
>> > @@ -114,6 +114,19 @@ int pcibios_root_bridge_prepare(struct 
>> > pci_host_bridge *bridge)
>> > return 0;
>> >  }
>> >
>> > +static int pci_acpi_root_prepare_resources(struct acpi_pci_root_info *ci)
>> > +{
>> > +   struct resource_entry *entry, *tmp;
>> > +   int status;
>> > +
>> > +   status = acpi_pci_probe_root_resources(ci);
>> > +   resource_list_for_each_entry_safe(entry, tmp, >resources) {
>> > +   if (!(entry->res->flags & IORESOURCE_WINDOW))
>> > +   resource_list_destroy_entry(entry);
>> > +   }
>> > +   return status;
>> > +}
>> > +
>> >  /*
>> >   * Lookup the bus range for the domain in MCFG, and set up config space
>> >   * mapping.
>> > @@ -190,6 +203,7 @@ struct pci_bus *pci_acpi_scan_root(struct 
>> > acpi_pci_root *root)
>> > }
>> >
>> > root_ops->release_info = pci_acpi_generic_release_info;
>> > +   root_ops->prepare_resources = pci_acpi_root_prepare_resources;
>> > root_ops->pci_ops = >cfg->ops->pci_ops;
>> > bus = acpi_pci_root_create(root, root_ops, >common, ri->cfg);
>> > if (!bus)
>>
>> I tried your patch above with my X-Gene ECAM v4 patch on Mustang, here
>> is the kernel boot log and output of 'cat /proc/iomem'. The PCIe core
>> does not print the MMIO space as a window (which is expected per your
>> patch above).
>
> Thanks!
>
>> ACPI: PCI Root Bridge [PCI0] (domain  [bus 00-ff])
>> acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI]
>> acpi PNP0A08:00: _OSC: OS now controls [PCIeHotplug PME AER PCIeCapability]
>> acpi PNP0A08:00: MCFG quirk: ECAM at [mem 0xe0d000-0xe0dfff] for 
>> [bus 00-ff] with xgene_v1_pcie_ecam_ops
>> acpi PNP0A08:00: [Firmware Bug]: ECAM area [mem 0xe0d000-0xe0dfff] 
>> not reserved in ACPI namespace
>> acpi PNP0A08:00: ECAM at [mem 0xe0d000-0xe0dfff] for [bus 00-ff]
>> Remapped I/O 0x00e01000 to [io  0x-0x window]
>> PCI host bridge to bus :00
>> pci_bus :00: root bus resource [io  0x-0x window] (bus address 
>> [0x1000-0x1000])
>> pci_bus :00: root bus resource [mem 0xe04000-0xe07fff window] 
>> (bus address [0x4000-0x7fff])
>> pci_bus :00: root bus resource [mem 0xf0-0xff window]
>> pci_bus :00: root bus resource [bus 00-ff]
>
> Yup, no bridge register space here; that's good.  I assume the bridge
> registers are at [mem 0x1f2b-0x1f2b] as shown in /proc/iomem
> below.

Yes,  the bridge registers are at [mem 0x1f2b-0x1f2b].

>
>> [root@(none) ~]# cat /proc/io mem
>> ...
>> 1900-19007fff : 808622B7:00
>> 1900c100-190f : 808622B7:00
>>   1900c100-190f : 808622B7:00
>> 1980-19807fff : 808622B7:01
>> 1980c100-198f : 808622B7:01
>>   1980c100-198f : 808622B7:01
>> ...
>> 1f28-1f28 : 808622B7:00
>> 1f29-1f29 : 808622B7:01
>
> I'm curious what these "808622B7" devices are.  Per ACPI 6.0, sec
> 6.1.5, that looks like a PCI vendor ID, which I guess is a valid ACPI
> ID.  But these resources don't seem to have any connection with PCI
> (they're not in any of the host bridge apertures).

These are DesignWare USB 3.0 controllers (DWC3). The ACPI ID is
defined in drivers/usb/dwc3/core.c.
>
>> 1f2b-1f2b : PNP0A08:00
>
> Looks like the bridge register space; good.

Yes, it is.

>
>> e04000-e07fff : PCI Bus :00
>>   e04000-e0401f : PCI Bus :01
>> e04000-e0400f : :01:00.0
>>   e04000-e0400f : mlx4_core
>> e04010-e0401f : :01:00.0
>
>> e0d000-e0dfff : PCI ECAM
>
> This region should be described in either a PNP0C02 device or (if we
> decide we can allow "consumer" descriptors) the PNP0A08 device.  I
> assume you'll fix that in a future firmware release.

Yes, future firmware will have PNP0C02 node that describes this ECAM
space (or a new resource in PNP0A08 if we use 'consumer' descriptor).

>
> But I think this reservation from pci_ecam_create() is good enough for
> now.
>
>> f0-ff : PCI Bus :00
>>   f0-f001ff : PCI Bus :01
>> f0-f001ff : :01:00.0
>>   f0-f001ff : mlx4_core
Regards,
Duc Dang.

[PATCH 20/20] perf annotate: Show raw form for jump instruction with indirect target

[Arnaldo Carvalho de Melo]

From: Ravi Bangoria 

For jump instructions that does not include target address as direct operand,
show the original disassembled line for them. This is needed for certain
powerpc jump instructions that use target address in a register (such as bctr,
btar, ...).

Before:
 ld r12,32088(r12)
 mtctr  r12
  v  bctr   ca2c
 stdr2,24(r1)
 addis  r12,r2,-1

After:
 ld r12,32088(r12)
 mtctr  r12
  v  bctr
 stdr2,24(r1)
 addis  r12,r2,-1

Committer notes:

Testing it using a perf.data file and vmlinux for powerpc64,
cross-annotating it on a x86_64 workstation:

Before:

  .__bpf_prog_run  vmlinux.powerpc
 │stdr10,512(r9)  ▒
 │lbzr9,0(r31)▒
 │rldicr r9,r9,3,60   ▒
 │ldxr9,r30,r9▒
 │mtctr  r9   ▒
  100.00 │  ↓ bctr   3fe01510 ▒
 │lwar10,4(r31)   ▒
 │lwzr9,0(r31)▒
  
  Invalid jump offset: 3fe01510

After:

  .__bpf_prog_run  vmlinux.powerpc
 │stdr10,512(r9)  ▒
 │lbzr9,0(r31)▒
 │rldicr r9,r9,3,60   ▒
 │ldxr9,r30,r9▒
 │mtctr  r9   ▒
  100.00 │  ↓ bctr▒
 │lwar10,4(r31)   ▒
 │lwzr9,0(r31)▒
  
  Invalid jump offset: 3fe01510

This, in turn, uncovers another problem with jumps without operands, the
ENTER/-> operation, to jump to the target, still continues using the bogus
target :-)

BTW, this was the file used for the above tests:

  [acme@jouet ravi_bangoria]$ perf report --header-only -i 
perf.data.f22vm.powerdev
  # 
  # captured on: Thu Nov 24 12:40:38 2016
  # hostname : pdev-f22-qemu
  # os release : 4.4.10-200.fc22.ppc64
  # perf version : 4.9.rc1.g6298ce
  # arch : ppc64
  # nrcpus online : 48
  # nrcpus avail : 48
  # cpudesc : POWER7 (architected), altivec supported
  # cpuid : 74,513
  # total memory : 4158976 kB
  # cmdline : /home/ravi/Workspace/linux/tools/perf/perf record -a
  # event : name = cycles:ppp, , size = 112, { sample_period, sample_freq } = 
4000, sample_type = IP|TID|TIME|CPU|PERIOD, disabled = 1, inherit = 1, mmap = 
1, c
  # HEADER_CPU_TOPOLOGY info available, use -I to display
  # HEADER_NUMA_TOPOLOGY info available, use -I to display
  # pmu mappings: cpu = 4, software = 1, tracepoint = 2, breakpoint = 5
  # missing features: HEADER_TRACING_DATA HEADER_BRANCH_STACK HEADER_GROUP_DESC 
HEADER_AUXTRACE HEADER_STAT HEADER_CACHE
  # 
  #
  [acme@jouet ravi_bangoria]$

Suggested-by: Michael Ellerman 
Signed-off-by: Ravi Bangoria 
Tested-by: Arnaldo Carvalho de Melo 
Cc: Alexander Shishkin 
Cc: Chris Riyder 
Cc: Kim Phillips 
Cc: Markus Trippelsdorf 
Cc: Masami Hiramatsu 
Cc: Naveen N. Rao 
Cc: Peter Zijlstra 
Cc: Taeung Song 
Cc: linuxppc-...@lists.ozlabs.org
Link: 
http://lkml.kernel.org/r/1480953407-7605-1-git-send-email-ravi.bango...@linux.vnet.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/annotate.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c
index 4012b1de2813..ea7e0de4b9c1 100644
--- a/tools/perf/util/annotate.c
+++ b/tools/perf/util/annotate.c
@@ -237,6 +237,9 @@ static int jump__parse(struct arch *arch __maybe_unused, 
struct ins_operands *op
 static int jump__scnprintf(struct ins *ins, char *bf, size_t size,
   struct ins_operands *ops)
 {
+   if (!ops->target.addr)
+   return ins__raw_scnprintf(ins, bf, size, ops);
+
return scnprintf(bf, size, "%-6.6s %" PRIx64, ins->name, 
ops->target.offset);
 }
 
-- 
2.9.3

[PATCH 17/20] perf tools: Move python/perf.so target into rules area

[Arnaldo Carvalho de Melo]

From: Jiri Olsa 

Following fixdep fix needs all targets at the same area, so they'll fit
under signal condition block.

Moving python/perf.so target into rules section and intentionally
removing the perl script related comment.

Signed-off-by: Jiri Olsa 
Cc: David Ahern 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/r/1480884178-8072-5-git-send-email-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/Makefile.perf | 19 ---
 1 file changed, 8 insertions(+), 11 deletions(-)

diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
index 593d765d62ab..2784b5843aef 100644
--- a/tools/perf/Makefile.perf
+++ b/tools/perf/Makefile.perf
@@ -268,17 +268,6 @@ python-clean := $(call QUIET_CLEAN, python) $(RM) -r 
$(PYTHON_EXTBUILD) $(OUTPUT
 PYTHON_EXT_SRCS := $(shell grep -v ^\# util/python-ext-sources)
 PYTHON_EXT_DEPS := util/python-ext-sources util/setup.py $(LIBTRACEEVENT) 
$(LIBAPI)
 
-$(OUTPUT)python/perf.so: $(PYTHON_EXT_SRCS) $(PYTHON_EXT_DEPS) 
$(LIBTRACEEVENT_DYNAMIC_LIST)
-   $(QUIET_GEN)LDSHARED="$(CC) -pthread -shared" \
-CFLAGS='$(CFLAGS)' LDFLAGS='$(LDFLAGS) 
$(LIBTRACEEVENT_DYNAMIC_LIST_LDFLAGS)' \
- $(PYTHON_WORD) util/setup.py \
- --quiet build_ext; \
-   mkdir -p $(OUTPUT)python && \
-   cp $(PYTHON_EXTBUILD_LIB)perf.so $(OUTPUT)python/
-#
-# No Perl scripts right now:
-#
-
 SCRIPTS = $(patsubst %.sh,%,$(SCRIPT_SH))
 
 PROGRAMS += $(OUTPUT)perf
@@ -362,6 +351,14 @@ SHELL = $(SHELL_PATH)
 
 all: shell_compatibility_test $(ALL_PROGRAMS) $(LANG_BINDINGS) 
$(OTHER_PROGRAMS)
 
+$(OUTPUT)python/perf.so: $(PYTHON_EXT_SRCS) $(PYTHON_EXT_DEPS) 
$(LIBTRACEEVENT_DYNAMIC_LIST)
+   $(QUIET_GEN)LDSHARED="$(CC) -pthread -shared" \
+CFLAGS='$(CFLAGS)' LDFLAGS='$(LDFLAGS) 
$(LIBTRACEEVENT_DYNAMIC_LIST_LDFLAGS)' \
+ $(PYTHON_WORD) util/setup.py \
+ --quiet build_ext; \
+   mkdir -p $(OUTPUT)python && \
+   cp $(PYTHON_EXTBUILD_LIB)perf.so $(OUTPUT)python/
+
 please_set_SHELL_PATH_to_a_more_modern_shell:
$(Q)$$(:)
 
-- 
2.9.3

[PATCH 20/20] perf annotate: Show raw form for jump instruction with indirect target

[Arnaldo Carvalho de Melo]

From: Ravi Bangoria 

For jump instructions that does not include target address as direct operand,
show the original disassembled line for them. This is needed for certain
powerpc jump instructions that use target address in a register (such as bctr,
btar, ...).

Before:
 ld r12,32088(r12)
 mtctr  r12
  v  bctr   ca2c
 stdr2,24(r1)
 addis  r12,r2,-1

After:
 ld r12,32088(r12)
 mtctr  r12
  v  bctr
 stdr2,24(r1)
 addis  r12,r2,-1

Committer notes:

Testing it using a perf.data file and vmlinux for powerpc64,
cross-annotating it on a x86_64 workstation:

Before:

  .__bpf_prog_run  vmlinux.powerpc
 │stdr10,512(r9)  ▒
 │lbzr9,0(r31)▒
 │rldicr r9,r9,3,60   ▒
 │ldxr9,r30,r9▒
 │mtctr  r9   ▒
  100.00 │  ↓ bctr   3fe01510 ▒
 │lwar10,4(r31)   ▒
 │lwzr9,0(r31)▒
  
  Invalid jump offset: 3fe01510

After:

  .__bpf_prog_run  vmlinux.powerpc
 │stdr10,512(r9)  ▒
 │lbzr9,0(r31)▒
 │rldicr r9,r9,3,60   ▒
 │ldxr9,r30,r9▒
 │mtctr  r9   ▒
  100.00 │  ↓ bctr▒
 │lwar10,4(r31)   ▒
 │lwzr9,0(r31)▒
  
  Invalid jump offset: 3fe01510

This, in turn, uncovers another problem with jumps without operands, the
ENTER/-> operation, to jump to the target, still continues using the bogus
target :-)

BTW, this was the file used for the above tests:

  [acme@jouet ravi_bangoria]$ perf report --header-only -i 
perf.data.f22vm.powerdev
  # 
  # captured on: Thu Nov 24 12:40:38 2016
  # hostname : pdev-f22-qemu
  # os release : 4.4.10-200.fc22.ppc64
  # perf version : 4.9.rc1.g6298ce
  # arch : ppc64
  # nrcpus online : 48
  # nrcpus avail : 48
  # cpudesc : POWER7 (architected), altivec supported
  # cpuid : 74,513
  # total memory : 4158976 kB
  # cmdline : /home/ravi/Workspace/linux/tools/perf/perf record -a
  # event : name = cycles:ppp, , size = 112, { sample_period, sample_freq } = 
4000, sample_type = IP|TID|TIME|CPU|PERIOD, disabled = 1, inherit = 1, mmap = 
1, c
  # HEADER_CPU_TOPOLOGY info available, use -I to display
  # HEADER_NUMA_TOPOLOGY info available, use -I to display
  # pmu mappings: cpu = 4, software = 1, tracepoint = 2, breakpoint = 5
  # missing features: HEADER_TRACING_DATA HEADER_BRANCH_STACK HEADER_GROUP_DESC 
HEADER_AUXTRACE HEADER_STAT HEADER_CACHE
  # 
  #
  [acme@jouet ravi_bangoria]$

Suggested-by: Michael Ellerman 
Signed-off-by: Ravi Bangoria 
Tested-by: Arnaldo Carvalho de Melo 
Cc: Alexander Shishkin 
Cc: Chris Riyder 
Cc: Kim Phillips 
Cc: Markus Trippelsdorf 
Cc: Masami Hiramatsu 
Cc: Naveen N. Rao 
Cc: Peter Zijlstra 
Cc: Taeung Song 
Cc: linuxppc-...@lists.ozlabs.org
Link: 
http://lkml.kernel.org/r/1480953407-7605-1-git-send-email-ravi.bango...@linux.vnet.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/annotate.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c
index 4012b1de2813..ea7e0de4b9c1 100644
--- a/tools/perf/util/annotate.c
+++ b/tools/perf/util/annotate.c
@@ -237,6 +237,9 @@ static int jump__parse(struct arch *arch __maybe_unused, 
struct ins_operands *op
 static int jump__scnprintf(struct ins *ins, char *bf, size_t size,
   struct ins_operands *ops)
 {
+   if (!ops->target.addr)
+   return ins__raw_scnprintf(ins, bf, size, ops);
+
return scnprintf(bf, size, "%-6.6s %" PRIx64, ins->name, 
ops->target.offset);
 }
 
-- 
2.9.3

[PATCH 17/20] perf tools: Move python/perf.so target into rules area

[Arnaldo Carvalho de Melo]

From: Jiri Olsa 

Following fixdep fix needs all targets at the same area, so they'll fit
under signal condition block.

Moving python/perf.so target into rules section and intentionally
removing the perl script related comment.

Signed-off-by: Jiri Olsa 
Cc: David Ahern 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/r/1480884178-8072-5-git-send-email-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/Makefile.perf | 19 ---
 1 file changed, 8 insertions(+), 11 deletions(-)

diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
index 593d765d62ab..2784b5843aef 100644
--- a/tools/perf/Makefile.perf
+++ b/tools/perf/Makefile.perf
@@ -268,17 +268,6 @@ python-clean := $(call QUIET_CLEAN, python) $(RM) -r 
$(PYTHON_EXTBUILD) $(OUTPUT
 PYTHON_EXT_SRCS := $(shell grep -v ^\# util/python-ext-sources)
 PYTHON_EXT_DEPS := util/python-ext-sources util/setup.py $(LIBTRACEEVENT) 
$(LIBAPI)
 
-$(OUTPUT)python/perf.so: $(PYTHON_EXT_SRCS) $(PYTHON_EXT_DEPS) 
$(LIBTRACEEVENT_DYNAMIC_LIST)
-   $(QUIET_GEN)LDSHARED="$(CC) -pthread -shared" \
-CFLAGS='$(CFLAGS)' LDFLAGS='$(LDFLAGS) 
$(LIBTRACEEVENT_DYNAMIC_LIST_LDFLAGS)' \
- $(PYTHON_WORD) util/setup.py \
- --quiet build_ext; \
-   mkdir -p $(OUTPUT)python && \
-   cp $(PYTHON_EXTBUILD_LIB)perf.so $(OUTPUT)python/
-#
-# No Perl scripts right now:
-#
-
 SCRIPTS = $(patsubst %.sh,%,$(SCRIPT_SH))
 
 PROGRAMS += $(OUTPUT)perf
@@ -362,6 +351,14 @@ SHELL = $(SHELL_PATH)
 
 all: shell_compatibility_test $(ALL_PROGRAMS) $(LANG_BINDINGS) 
$(OTHER_PROGRAMS)
 
+$(OUTPUT)python/perf.so: $(PYTHON_EXT_SRCS) $(PYTHON_EXT_DEPS) 
$(LIBTRACEEVENT_DYNAMIC_LIST)
+   $(QUIET_GEN)LDSHARED="$(CC) -pthread -shared" \
+CFLAGS='$(CFLAGS)' LDFLAGS='$(LDFLAGS) 
$(LIBTRACEEVENT_DYNAMIC_LIST_LDFLAGS)' \
+ $(PYTHON_WORD) util/setup.py \
+ --quiet build_ext; \
+   mkdir -p $(OUTPUT)python && \
+   cp $(PYTHON_EXTBUILD_LIB)perf.so $(OUTPUT)python/
+
 please_set_SHELL_PATH_to_a_more_modern_shell:
$(Q)$$(:)
 
-- 
2.9.3

Re: [PATCH v3] PCI/ACPI: xgene: Add ECAM quirk for X-Gene PCIe controller

[Duc Dang]

On Mon, Dec 5, 2016 at 1:20 PM, Bjorn Helgaas  wrote:
> On Fri, Dec 02, 2016 at 11:06:30PM -0800, Duc Dang wrote:
>> On Fri, Dec 2, 2016 at 3:39 PM, Bjorn Helgaas  wrote:
>
>> > diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
>> > index 8a177a1..a16fc8e 100644
>> > --- a/arch/arm64/kernel/pci.c
>> > +++ b/arch/arm64/kernel/pci.c
>> > @@ -114,6 +114,19 @@ int pcibios_root_bridge_prepare(struct 
>> > pci_host_bridge *bridge)
>> > return 0;
>> >  }
>> >
>> > +static int pci_acpi_root_prepare_resources(struct acpi_pci_root_info *ci)
>> > +{
>> > +   struct resource_entry *entry, *tmp;
>> > +   int status;
>> > +
>> > +   status = acpi_pci_probe_root_resources(ci);
>> > +   resource_list_for_each_entry_safe(entry, tmp, >resources) {
>> > +   if (!(entry->res->flags & IORESOURCE_WINDOW))
>> > +   resource_list_destroy_entry(entry);
>> > +   }
>> > +   return status;
>> > +}
>> > +
>> >  /*
>> >   * Lookup the bus range for the domain in MCFG, and set up config space
>> >   * mapping.
>> > @@ -190,6 +203,7 @@ struct pci_bus *pci_acpi_scan_root(struct 
>> > acpi_pci_root *root)
>> > }
>> >
>> > root_ops->release_info = pci_acpi_generic_release_info;
>> > +   root_ops->prepare_resources = pci_acpi_root_prepare_resources;
>> > root_ops->pci_ops = >cfg->ops->pci_ops;
>> > bus = acpi_pci_root_create(root, root_ops, >common, ri->cfg);
>> > if (!bus)
>>
>> I tried your patch above with my X-Gene ECAM v4 patch on Mustang, here
>> is the kernel boot log and output of 'cat /proc/iomem'. The PCIe core
>> does not print the MMIO space as a window (which is expected per your
>> patch above).
>
> Thanks!
>
>> ACPI: PCI Root Bridge [PCI0] (domain  [bus 00-ff])
>> acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI]
>> acpi PNP0A08:00: _OSC: OS now controls [PCIeHotplug PME AER PCIeCapability]
>> acpi PNP0A08:00: MCFG quirk: ECAM at [mem 0xe0d000-0xe0dfff] for 
>> [bus 00-ff] with xgene_v1_pcie_ecam_ops
>> acpi PNP0A08:00: [Firmware Bug]: ECAM area [mem 0xe0d000-0xe0dfff] 
>> not reserved in ACPI namespace
>> acpi PNP0A08:00: ECAM at [mem 0xe0d000-0xe0dfff] for [bus 00-ff]
>> Remapped I/O 0x00e01000 to [io  0x-0x window]
>> PCI host bridge to bus :00
>> pci_bus :00: root bus resource [io  0x-0x window] (bus address 
>> [0x1000-0x1000])
>> pci_bus :00: root bus resource [mem 0xe04000-0xe07fff window] 
>> (bus address [0x4000-0x7fff])
>> pci_bus :00: root bus resource [mem 0xf0-0xff window]
>> pci_bus :00: root bus resource [bus 00-ff]
>
> Yup, no bridge register space here; that's good.  I assume the bridge
> registers are at [mem 0x1f2b-0x1f2b] as shown in /proc/iomem
> below.

Yes,  the bridge registers are at [mem 0x1f2b-0x1f2b].

>
>> [root@(none) ~]# cat /proc/io mem
>> ...
>> 1900-19007fff : 808622B7:00
>> 1900c100-190f : 808622B7:00
>>   1900c100-190f : 808622B7:00
>> 1980-19807fff : 808622B7:01
>> 1980c100-198f : 808622B7:01
>>   1980c100-198f : 808622B7:01
>> ...
>> 1f28-1f28 : 808622B7:00
>> 1f29-1f29 : 808622B7:01
>
> I'm curious what these "808622B7" devices are.  Per ACPI 6.0, sec
> 6.1.5, that looks like a PCI vendor ID, which I guess is a valid ACPI
> ID.  But these resources don't seem to have any connection with PCI
> (they're not in any of the host bridge apertures).

These are DesignWare USB 3.0 controllers (DWC3). The ACPI ID is
defined in drivers/usb/dwc3/core.c.
>
>> 1f2b-1f2b : PNP0A08:00
>
> Looks like the bridge register space; good.

Yes, it is.

>
>> e04000-e07fff : PCI Bus :00
>>   e04000-e0401f : PCI Bus :01
>> e04000-e0400f : :01:00.0
>>   e04000-e0400f : mlx4_core
>> e04010-e0401f : :01:00.0
>
>> e0d000-e0dfff : PCI ECAM
>
> This region should be described in either a PNP0C02 device or (if we
> decide we can allow "consumer" descriptors) the PNP0A08 device.  I
> assume you'll fix that in a future firmware release.

Yes, future firmware will have PNP0C02 node that describes this ECAM
space (or a new resource in PNP0A08 if we use 'consumer' descriptor).

>
> But I think this reservation from pci_ecam_create() is good enough for
> now.
>
>> f0-ff : PCI Bus :00
>>   f0-f001ff : PCI Bus :01
>> f0-f001ff : :01:00.0
>>   f0-f001ff : mlx4_core
Regards,
Duc Dang.

[PATCH 14/20] tools build: Make the .cmd file more readable

[Arnaldo Carvalho de Melo]

From: Jiri Olsa 

Putting extra line between dependencies and cmd_* definition
to make it more readable.

Before:

  $ cat .builtin-top.o.cmd
  ...
  /home/jolsa/kernel/linux-perf/tools/include/linux/stringify.h \
  /home/jolsa/kernel/linux-perf/tools/include/linux/time64.h
  cmd_builtin-top.o := gcc -Wp,-MD,./.builtin-top.o.d -Wp,-MT,builtin-...
  ...

After:

  $ cat .builtin-top.o.cmd
  ...
  /home/jolsa/kernel/linux-perf/tools/include/linux/stringify.h \
  /home/jolsa/kernel/linux-perf/tools/include/linux/time64.h

  cmd_builtin-top.o := gcc -Wp,-MD,./.builtin-top.o.d -Wp,-MT,builtin-...
  ...

Signed-off-by: Jiri Olsa 
Cc: David Ahern 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/r/1480884178-8072-2-git-send-email-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/build/Build.include | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/build/Build.include b/tools/build/Build.include
index 62dcf0c7aac2..475152c52871 100644
--- a/tools/build/Build.include
+++ b/tools/build/Build.include
@@ -65,7 +65,7 @@ dep-cmd = $(if $(wildcard $(fixdep)),
printf '\# cannot find fixdep (%s)\n' $(fixdep) > 
$(dot-target).cmd; \
printf '\# using basic dep data\n\n' >> $(dot-target).cmd;  
 \
cat $(depfile) >> $(dot-target).cmd;
 \
-   printf '%s\n' 'cmd_$@ := $(make-cmd)' >> $(dot-target).cmd)
+   printf '\n%s\n' 'cmd_$@ := $(make-cmd)' >> $(dot-target).cmd)
 
 ###
 # if_changed_dep  - execute command if any prerequisite is newer than
-- 
2.9.3

[PATCH 05/20] tools build: Add feature detection for LLVM

[Arnaldo Carvalho de Melo]

From: Wang Nan 

Check if basic LLVM compiling environment is ready.

Use llvm-config to detect include and library directories. Avoid using
'llvm-config --cxxflags' because its result contain some unwanted flags
like --sysroot (if LLVM is built by yocto).

Use '?=' to set LLVM_CONFIG, so explicitly passing LLVM_CONFIG to make
would override it.

Use 'llvm-config --libs BPF' to check if BPF backend is compiled in.
Since now BPF bytecode is the only required backend, no need to waste
time linking llvm and clang if BPF backend is missing. This also
introduce an implicit requirement that LLVM should be new enough.  Old
LLVM doesn't support BPF backend.

Signed-off-by: Wang Nan 
Cc: Alexei Starovoitov 
Cc: He Kuang 
Cc: Jiri Olsa 
Cc: Joe Stringer 
Cc: Zefan Li 
Cc: pi3or...@163.com
Link: http://lkml.kernel.org/r/20161126070354.141764-8-wangn...@huawei.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/build/feature/Makefile  | 8 
 tools/build/feature/test-llvm.cpp | 8 
 2 files changed, 16 insertions(+)
 create mode 100644 tools/build/feature/test-llvm.cpp

diff --git a/tools/build/feature/Makefile b/tools/build/feature/Makefile
index 8f668bce8996..c09de59affc9 100644
--- a/tools/build/feature/Makefile
+++ b/tools/build/feature/Makefile
@@ -55,6 +55,7 @@ FILES := $(addprefix $(OUTPUT),$(FILES))
 CC := $(CROSS_COMPILE)gcc -MD
 CXX := $(CROSS_COMPILE)g++ -MD
 PKG_CONFIG := $(CROSS_COMPILE)pkg-config
+LLVM_CONFIG ?= llvm-config
 
 all: $(FILES)
 
@@ -229,6 +230,13 @@ $(OUTPUT)test-cxx.bin:
 $(OUTPUT)test-jvmti.bin:
$(BUILD)
 
+$(OUTPUT)test-llvm.bin:
+   $(BUILDXX) -std=gnu++11 \
+   -I$(shell $(LLVM_CONFIG) --includedir)  \
+   -L$(shell $(LLVM_CONFIG) --libdir)  \
+   $(shell $(LLVM_CONFIG) --libs Core BPF) \
+   $(shell $(LLVM_CONFIG) --system-libs)
+
 -include $(OUTPUT)*.d
 
 ###
diff --git a/tools/build/feature/test-llvm.cpp 
b/tools/build/feature/test-llvm.cpp
new file mode 100644
index ..d8d2cee35345
--- /dev/null
+++ b/tools/build/feature/test-llvm.cpp
@@ -0,0 +1,8 @@
+#include "llvm/Support/ManagedStatic.h"
+#include "llvm/Support/raw_ostream.h"
+int main()
+{
+   llvm::errs() << "Hello World!\n";
+   llvm::llvm_shutdown();
+   return 0;
+}
-- 
2.9.3

[PATCH 14/20] tools build: Make the .cmd file more readable

[Arnaldo Carvalho de Melo]

From: Jiri Olsa 

Putting extra line between dependencies and cmd_* definition
to make it more readable.

Before:

  $ cat .builtin-top.o.cmd
  ...
  /home/jolsa/kernel/linux-perf/tools/include/linux/stringify.h \
  /home/jolsa/kernel/linux-perf/tools/include/linux/time64.h
  cmd_builtin-top.o := gcc -Wp,-MD,./.builtin-top.o.d -Wp,-MT,builtin-...
  ...

After:

  $ cat .builtin-top.o.cmd
  ...
  /home/jolsa/kernel/linux-perf/tools/include/linux/stringify.h \
  /home/jolsa/kernel/linux-perf/tools/include/linux/time64.h

  cmd_builtin-top.o := gcc -Wp,-MD,./.builtin-top.o.d -Wp,-MT,builtin-...
  ...

Signed-off-by: Jiri Olsa 
Cc: David Ahern 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/r/1480884178-8072-2-git-send-email-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/build/Build.include | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/build/Build.include b/tools/build/Build.include
index 62dcf0c7aac2..475152c52871 100644
--- a/tools/build/Build.include
+++ b/tools/build/Build.include
@@ -65,7 +65,7 @@ dep-cmd = $(if $(wildcard $(fixdep)),
printf '\# cannot find fixdep (%s)\n' $(fixdep) > 
$(dot-target).cmd; \
printf '\# using basic dep data\n\n' >> $(dot-target).cmd;  
 \
cat $(depfile) >> $(dot-target).cmd;
 \
-   printf '%s\n' 'cmd_$@ := $(make-cmd)' >> $(dot-target).cmd)
+   printf '\n%s\n' 'cmd_$@ := $(make-cmd)' >> $(dot-target).cmd)
 
 ###
 # if_changed_dep  - execute command if any prerequisite is newer than
-- 
2.9.3

[PATCH 05/20] tools build: Add feature detection for LLVM

[Arnaldo Carvalho de Melo]

From: Wang Nan 

Check if basic LLVM compiling environment is ready.

Use llvm-config to detect include and library directories. Avoid using
'llvm-config --cxxflags' because its result contain some unwanted flags
like --sysroot (if LLVM is built by yocto).

Use '?=' to set LLVM_CONFIG, so explicitly passing LLVM_CONFIG to make
would override it.

Use 'llvm-config --libs BPF' to check if BPF backend is compiled in.
Since now BPF bytecode is the only required backend, no need to waste
time linking llvm and clang if BPF backend is missing. This also
introduce an implicit requirement that LLVM should be new enough.  Old
LLVM doesn't support BPF backend.

Signed-off-by: Wang Nan 
Cc: Alexei Starovoitov 
Cc: He Kuang 
Cc: Jiri Olsa 
Cc: Joe Stringer 
Cc: Zefan Li 
Cc: pi3or...@163.com
Link: http://lkml.kernel.org/r/20161126070354.141764-8-wangn...@huawei.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/build/feature/Makefile  | 8 
 tools/build/feature/test-llvm.cpp | 8 
 2 files changed, 16 insertions(+)
 create mode 100644 tools/build/feature/test-llvm.cpp

diff --git a/tools/build/feature/Makefile b/tools/build/feature/Makefile
index 8f668bce8996..c09de59affc9 100644
--- a/tools/build/feature/Makefile
+++ b/tools/build/feature/Makefile
@@ -55,6 +55,7 @@ FILES := $(addprefix $(OUTPUT),$(FILES))
 CC := $(CROSS_COMPILE)gcc -MD
 CXX := $(CROSS_COMPILE)g++ -MD
 PKG_CONFIG := $(CROSS_COMPILE)pkg-config
+LLVM_CONFIG ?= llvm-config
 
 all: $(FILES)
 
@@ -229,6 +230,13 @@ $(OUTPUT)test-cxx.bin:
 $(OUTPUT)test-jvmti.bin:
$(BUILD)
 
+$(OUTPUT)test-llvm.bin:
+   $(BUILDXX) -std=gnu++11 \
+   -I$(shell $(LLVM_CONFIG) --includedir)  \
+   -L$(shell $(LLVM_CONFIG) --libdir)  \
+   $(shell $(LLVM_CONFIG) --libs Core BPF) \
+   $(shell $(LLVM_CONFIG) --system-libs)
+
 -include $(OUTPUT)*.d
 
 ###
diff --git a/tools/build/feature/test-llvm.cpp 
b/tools/build/feature/test-llvm.cpp
new file mode 100644
index ..d8d2cee35345
--- /dev/null
+++ b/tools/build/feature/test-llvm.cpp
@@ -0,0 +1,8 @@
+#include "llvm/Support/ManagedStatic.h"
+#include "llvm/Support/raw_ostream.h"
+int main()
+{
+   llvm::errs() << "Hello World!\n";
+   llvm::llvm_shutdown();
+   return 0;
+}
-- 
2.9.3