* [PATCH 02/37] PCI: dwc: designware: Add new *ops* for cpu addr fixup
From: Joao Pinto @ 2017-01-13 16:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484216786-17292-3-git-send-email-kishon@ti.com>
Hi Kishon,
?s 10:25 AM de 1/12/2017, Kishon Vijay Abraham I escreveu:
> Some platforms (like dra7xx) require only the least 28 bits of the
> corresponding 32 bit CPU address to be programmed in the address
> translation unit. This modified address is stored in io_base/mem_base/
> cfg0_base/cfg1_base in dra7xx_pcie_host_init. While this is okay for
> host mode where the address range is fixed, device mode requires
> different addresses to be programmed based on the host buffer address.
> Add a new ops to get the least 28 bits of the corresponding 32 bit
> CPU address and invoke it before programming the address translation
> unit.
>
> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
> ---
> drivers/pci/dwc/pcie-designware.c | 3 +++
> drivers/pci/dwc/pcie-designware.h | 1 +
> 2 files changed, 4 insertions(+)
>
> diff --git a/drivers/pci/dwc/pcie-designware.c b/drivers/pci/dwc/pcie-designware.c
> index bed1999..d68bc7b 100644
> --- a/drivers/pci/dwc/pcie-designware.c
> +++ b/drivers/pci/dwc/pcie-designware.c
> @@ -195,6 +195,9 @@ static void dw_pcie_prog_outbound_atu(struct pcie_port *pp, int index,
> {
> u32 retries, val;
>
> + if (pp->ops->cpu_addr_fixup)
> + cpu_addr = pp->ops->cpu_addr_fixup(cpu_addr);
> +
> if (pp->iatu_unroll_enabled) {
> dw_pcie_writel_unroll(pp, index, PCIE_ATU_UNR_LOWER_BASE,
> lower_32_bits(cpu_addr));
> diff --git a/drivers/pci/dwc/pcie-designware.h b/drivers/pci/dwc/pcie-designware.h
> index a567ea2..32f4602 100644
> --- a/drivers/pci/dwc/pcie-designware.h
> +++ b/drivers/pci/dwc/pcie-designware.h
> @@ -54,6 +54,7 @@ struct pcie_port {
> };
>
> struct pcie_host_ops {
> + u64 (*cpu_addr_fixup)(u64 cpu_addr);
> u32 (*readl_rc)(struct pcie_port *pp, u32 reg);
> void (*writel_rc)(struct pcie_port *pp, u32 reg, u32 val);
> int (*rd_own_conf)(struct pcie_port *pp, int where, int size, u32 *val);
>
I think this is an acceptable fixup, I am ok with it.
Reviewed-By: Joao Pinto <jpinto@synopsys.com>
Joao
^ permalink raw reply
* [PATCH 04/37] PCI: dwc: designware: Move the register defines to designware header file
From: Joao Pinto @ 2017-01-13 16:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484216786-17292-5-git-send-email-kishon@ti.com>
?s 10:25 AM de 1/12/2017, Kishon Vijay Abraham I escreveu:
> No functional change. Move the register defines and other macros from
> pcie-designware.c to pcie-designware.h. This is in preparation to
> split the pcie-designware.c file into designware core file and host
> specific file.
>
> While at that also fix a checkpatch warning.
>
> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
> ---
> drivers/pci/dwc/pcie-designware.c | 70 ------------------------------------
> drivers/pci/dwc/pcie-designware.h | 71 +++++++++++++++++++++++++++++++++++++
> 2 files changed, 71 insertions(+), 70 deletions(-)
>
> diff --git a/drivers/pci/dwc/pcie-designware.c b/drivers/pci/dwc/pcie-designware.c
> index d68bc7b..0b928dc 100644
> --- a/drivers/pci/dwc/pcie-designware.c
> +++ b/drivers/pci/dwc/pcie-designware.c
> @@ -25,76 +25,6 @@
>
> #include "pcie-designware.h"
Make sense.
Reviewed-By: Joao Pinto <jpinto@synopsys.com>
^ permalink raw reply
* [PATCH 06/37] PCI: dwc: Rename cfg_read/cfg_write to read/write
From: Joao Pinto @ 2017-01-13 16:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484216786-17292-7-git-send-email-kishon@ti.com>
Hi,
?s 10:25 AM de 1/12/2017, Kishon Vijay Abraham I escreveu:
> No functional change. dw_pcie_cfg_read/dw_pcie_cfg_write doesn't do
> anything specific to access configuration space. It can be just renamed
> to dw_pcie_read/dw_pcie_write and used to read/write data to dbi space.
> This is in preparation for added endpoint support to linux kernel.
>
> Cc: Jingoo Han <jingoohan1@gmail.com>
> Cc: Murali Karicheri <m-karicheri2@ti.com>
> Cc: Joao Pinto <Joao.Pinto@synopsys.com>
> Cc: Stanimir Varbanov <svarbanov@mm-sol.com>
> Cc: Pratyush Anand <pratyush.anand@gmail.com>
> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
> ---
> drivers/pci/dwc/pci-dra7xx.c | 16 ++++++++--------
> drivers/pci/dwc/pci-exynos.c | 4 ++--
> drivers/pci/dwc/pci-keystone-dw.c | 4 ++--
> drivers/pci/dwc/pcie-designware.c | 12 ++++++------
> drivers/pci/dwc/pcie-designware.h | 4 ++--
> drivers/pci/dwc/pcie-qcom.c | 2 +-
> drivers/pci/dwc/pcie-spear13xx.c | 24 ++++++++++++------------
> 7 files changed, 33 insertions(+), 33 deletions(-)
>
> diff --git a/drivers/pci/dwc/pci-dra7xx.c b/drivers/pci/dwc/pci-dra7xx.c
> index aeeab74..38b0c9a 100644
> --- a/drivers/pci/dwc/pci-dra7xx.c
> +++ b/drivers/pci/dwc/pci-dra7xx.c
> @@ -114,22 +114,22 @@ static int dra7xx_pcie_establish_link(struct dra7xx_pcie *dra7xx)
> }
>
> if (dra7xx->link_gen == 1) {
> - dw_pcie_cfg_read(pp->dbi_base + exp_cap_off + PCI_EXP_LNKCAP,
> - 4, ®);
> + dw_pcie_read(pp->dbi_base + exp_cap_off + PCI_EXP_LNKCAP,
> + 4, ®);
> if ((reg & PCI_EXP_LNKCAP_SLS) != PCI_EXP_LNKCAP_SLS_2_5GB) {
> reg &= ~((u32)PCI_EXP_LNKCAP_SLS);
> reg |= PCI_EXP_LNKCAP_SLS_2_5GB;
> - dw_pcie_cfg_write(pp->dbi_base + exp_cap_off +
> - PCI_EXP_LNKCAP, 4, reg);
> + dw_pcie_write(pp->dbi_base + exp_cap_off +
> + PCI_EXP_LNKCAP, 4, reg);
> }
>
> - dw_pcie_cfg_read(pp->dbi_base + exp_cap_off + PCI_EXP_LNKCTL2,
> - 2, ®);
> + dw_pcie_read(pp->dbi_base + exp_cap_off + PCI_EXP_LNKCTL2,
> + 2, ®);
> if ((reg & PCI_EXP_LNKCAP_SLS) != PCI_EXP_LNKCAP_SLS_2_5GB) {
> reg &= ~((u32)PCI_EXP_LNKCAP_SLS);
> reg |= PCI_EXP_LNKCAP_SLS_2_5GB;
> - dw_pcie_cfg_write(pp->dbi_base + exp_cap_off +
> - PCI_EXP_LNKCTL2, 2, reg);
> + dw_pcie_write(pp->dbi_base + exp_cap_off +
> + PCI_EXP_LNKCTL2, 2, reg);
> }
> }
>
> diff --git a/drivers/pci/dwc/pci-exynos.c b/drivers/pci/dwc/pci-exynos.c
> index c179e7a..e3fbff4 100644
> --- a/drivers/pci/dwc/pci-exynos.c
> +++ b/drivers/pci/dwc/pci-exynos.c
> @@ -429,7 +429,7 @@ static int exynos_pcie_rd_own_conf(struct pcie_port *pp, int where, int size,
> int ret;
>
> exynos_pcie_sideband_dbi_r_mode(exynos_pcie, true);
> - ret = dw_pcie_cfg_read(pp->dbi_base + where, size, val);
> + ret = dw_pcie_read(pp->dbi_base + where, size, val);
> exynos_pcie_sideband_dbi_r_mode(exynos_pcie, false);
> return ret;
> }
> @@ -441,7 +441,7 @@ static int exynos_pcie_wr_own_conf(struct pcie_port *pp, int where, int size,
> int ret;
>
> exynos_pcie_sideband_dbi_w_mode(exynos_pcie, true);
> - ret = dw_pcie_cfg_write(pp->dbi_base + where, size, val);
> + ret = dw_pcie_write(pp->dbi_base + where, size, val);
> exynos_pcie_sideband_dbi_w_mode(exynos_pcie, false);
> return ret;
> }
> diff --git a/drivers/pci/dwc/pci-keystone-dw.c b/drivers/pci/dwc/pci-keystone-dw.c
> index 9397c46..4875334 100644
> --- a/drivers/pci/dwc/pci-keystone-dw.c
> +++ b/drivers/pci/dwc/pci-keystone-dw.c
> @@ -444,7 +444,7 @@ int ks_dw_pcie_rd_other_conf(struct pcie_port *pp, struct pci_bus *bus,
>
> addr = ks_pcie_cfg_setup(ks_pcie, bus_num, devfn);
>
> - return dw_pcie_cfg_read(addr + where, size, val);
> + return dw_pcie_read(addr + where, size, val);
> }
>
> int ks_dw_pcie_wr_other_conf(struct pcie_port *pp, struct pci_bus *bus,
> @@ -456,7 +456,7 @@ int ks_dw_pcie_wr_other_conf(struct pcie_port *pp, struct pci_bus *bus,
>
> addr = ks_pcie_cfg_setup(ks_pcie, bus_num, devfn);
>
> - return dw_pcie_cfg_write(addr + where, size, val);
> + return dw_pcie_write(addr + where, size, val);
> }
>
> /**
> diff --git a/drivers/pci/dwc/pcie-designware.c b/drivers/pci/dwc/pcie-designware.c
> index 0b928dc..d0ea310 100644
> --- a/drivers/pci/dwc/pcie-designware.c
> +++ b/drivers/pci/dwc/pcie-designware.c
> @@ -33,7 +33,7 @@
>
> static struct pci_ops dw_pcie_ops;
>
> -int dw_pcie_cfg_read(void __iomem *addr, int size, u32 *val)
> +int dw_pcie_read(void __iomem *addr, int size, u32 *val)
> {
> if ((uintptr_t)addr & (size - 1)) {
> *val = 0;
> @@ -54,7 +54,7 @@ int dw_pcie_cfg_read(void __iomem *addr, int size, u32 *val)
> return PCIBIOS_SUCCESSFUL;
> }
>
> -int dw_pcie_cfg_write(void __iomem *addr, int size, u32 val)
> +int dw_pcie_write(void __iomem *addr, int size, u32 val)
> {
> if ((uintptr_t)addr & (size - 1))
> return PCIBIOS_BAD_REGISTER_NUMBER;
> @@ -108,7 +108,7 @@ static int dw_pcie_rd_own_conf(struct pcie_port *pp, int where, int size,
> if (pp->ops->rd_own_conf)
> return pp->ops->rd_own_conf(pp, where, size, val);
>
> - return dw_pcie_cfg_read(pp->dbi_base + where, size, val);
> + return dw_pcie_read(pp->dbi_base + where, size, val);
> }
>
> static int dw_pcie_wr_own_conf(struct pcie_port *pp, int where, int size,
> @@ -117,7 +117,7 @@ static int dw_pcie_wr_own_conf(struct pcie_port *pp, int where, int size,
> if (pp->ops->wr_own_conf)
> return pp->ops->wr_own_conf(pp, where, size, val);
>
> - return dw_pcie_cfg_write(pp->dbi_base + where, size, val);
> + return dw_pcie_write(pp->dbi_base + where, size, val);
> }
>
> static void dw_pcie_prog_outbound_atu(struct pcie_port *pp, int index,
> @@ -638,7 +638,7 @@ static int dw_pcie_rd_other_conf(struct pcie_port *pp, struct pci_bus *bus,
> dw_pcie_prog_outbound_atu(pp, PCIE_ATU_REGION_INDEX1,
> type, cpu_addr,
> busdev, cfg_size);
> - ret = dw_pcie_cfg_read(va_cfg_base + where, size, val);
> + ret = dw_pcie_read(va_cfg_base + where, size, val);
> if (pp->num_viewport <= 2)
> dw_pcie_prog_outbound_atu(pp, PCIE_ATU_REGION_INDEX1,
> PCIE_ATU_TYPE_IO, pp->io_base,
> @@ -676,7 +676,7 @@ static int dw_pcie_wr_other_conf(struct pcie_port *pp, struct pci_bus *bus,
> dw_pcie_prog_outbound_atu(pp, PCIE_ATU_REGION_INDEX1,
> type, cpu_addr,
> busdev, cfg_size);
> - ret = dw_pcie_cfg_write(va_cfg_base + where, size, val);
> + ret = dw_pcie_write(va_cfg_base + where, size, val);
> if (pp->num_viewport <= 2)
> dw_pcie_prog_outbound_atu(pp, PCIE_ATU_REGION_INDEX1,
> PCIE_ATU_TYPE_IO, pp->io_base,
> diff --git a/drivers/pci/dwc/pcie-designware.h b/drivers/pci/dwc/pcie-designware.h
> index a6cf9262..b6ddb05 100644
> --- a/drivers/pci/dwc/pcie-designware.h
> +++ b/drivers/pci/dwc/pcie-designware.h
> @@ -146,8 +146,8 @@ struct pcie_host_ops {
>
> u32 dw_pcie_readl_rc(struct pcie_port *pp, u32 reg);
> void dw_pcie_writel_rc(struct pcie_port *pp, u32 reg, u32 val);
> -int dw_pcie_cfg_read(void __iomem *addr, int size, u32 *val);
> -int dw_pcie_cfg_write(void __iomem *addr, int size, u32 val);
> +int dw_pcie_read(void __iomem *addr, int size, u32 *val);
> +int dw_pcie_write(void __iomem *addr, int size, u32 val);
> irqreturn_t dw_handle_msi_irq(struct pcie_port *pp);
> void dw_pcie_msi_init(struct pcie_port *pp);
> int dw_pcie_wait_for_link(struct pcie_port *pp);
> diff --git a/drivers/pci/dwc/pcie-qcom.c b/drivers/pci/dwc/pcie-qcom.c
> index 2c24c45..d75fc02 100644
> --- a/drivers/pci/dwc/pcie-qcom.c
> +++ b/drivers/pci/dwc/pcie-qcom.c
> @@ -630,7 +630,7 @@ static int qcom_pcie_rd_own_conf(struct pcie_port *pp, int where, int size,
> return PCIBIOS_SUCCESSFUL;
> }
>
> - return dw_pcie_cfg_read(pp->dbi_base + where, size, val);
> + return dw_pcie_read(pp->dbi_base + where, size, val);
> }
>
> static struct pcie_host_ops qcom_pcie_dw_ops = {
> diff --git a/drivers/pci/dwc/pcie-spear13xx.c b/drivers/pci/dwc/pcie-spear13xx.c
> index 5970566..7acf91e 100644
> --- a/drivers/pci/dwc/pcie-spear13xx.c
> +++ b/drivers/pci/dwc/pcie-spear13xx.c
> @@ -91,34 +91,34 @@ static int spear13xx_pcie_establish_link(struct spear13xx_pcie *spear13xx_pcie)
> * default value in capability register is 512 bytes. So force
> * it to 128 here.
> */
> - dw_pcie_cfg_read(pp->dbi_base + exp_cap_off + PCI_EXP_DEVCTL, 2, &val);
> + dw_pcie_read(pp->dbi_base + exp_cap_off + PCI_EXP_DEVCTL, 2, &val);
> val &= ~PCI_EXP_DEVCTL_READRQ;
> - dw_pcie_cfg_write(pp->dbi_base + exp_cap_off + PCI_EXP_DEVCTL, 2, val);
> + dw_pcie_write(pp->dbi_base + exp_cap_off + PCI_EXP_DEVCTL, 2, val);
>
> - dw_pcie_cfg_write(pp->dbi_base + PCI_VENDOR_ID, 2, 0x104A);
> - dw_pcie_cfg_write(pp->dbi_base + PCI_DEVICE_ID, 2, 0xCD80);
> + dw_pcie_write(pp->dbi_base + PCI_VENDOR_ID, 2, 0x104A);
> + dw_pcie_write(pp->dbi_base + PCI_DEVICE_ID, 2, 0xCD80);
>
> /*
> * if is_gen1 is set then handle it, so that some buggy card
> * also works
> */
> if (spear13xx_pcie->is_gen1) {
> - dw_pcie_cfg_read(pp->dbi_base + exp_cap_off + PCI_EXP_LNKCAP,
> - 4, &val);
> + dw_pcie_read(pp->dbi_base + exp_cap_off + PCI_EXP_LNKCAP,
> + 4, &val);
> if ((val & PCI_EXP_LNKCAP_SLS) != PCI_EXP_LNKCAP_SLS_2_5GB) {
> val &= ~((u32)PCI_EXP_LNKCAP_SLS);
> val |= PCI_EXP_LNKCAP_SLS_2_5GB;
> - dw_pcie_cfg_write(pp->dbi_base + exp_cap_off +
> - PCI_EXP_LNKCAP, 4, val);
> + dw_pcie_write(pp->dbi_base + exp_cap_off +
> + PCI_EXP_LNKCAP, 4, val);
> }
>
> - dw_pcie_cfg_read(pp->dbi_base + exp_cap_off + PCI_EXP_LNKCTL2,
> - 2, &val);
> + dw_pcie_read(pp->dbi_base + exp_cap_off + PCI_EXP_LNKCTL2,
> + 2, &val);
> if ((val & PCI_EXP_LNKCAP_SLS) != PCI_EXP_LNKCAP_SLS_2_5GB) {
> val &= ~((u32)PCI_EXP_LNKCAP_SLS);
> val |= PCI_EXP_LNKCAP_SLS_2_5GB;
> - dw_pcie_cfg_write(pp->dbi_base + exp_cap_off +
> - PCI_EXP_LNKCTL2, 2, val);
> + dw_pcie_write(pp->dbi_base + exp_cap_off +
> + PCI_EXP_LNKCTL2, 2, val);
> }
> }
>
>
Make sense.
Reviewed-By: Joao Pinto <jpinto@synopsys.com>
^ permalink raw reply
* [PATCH RESEND 1/2] memory: aemif: allow passing device lookup table as platform data
From: Santosh Shilimkar @ 2017-01-13 16:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484301626-30345-2-git-send-email-bgolaszewski@baylibre.com>
Hi Greg,
On 1/13/2017 2:00 AM, Bartosz Golaszewski wrote:
> TI aemif driver creates its own subnodes of the device tree in order
> to guarantee that all child devices are probed after the AEMIF timing
> parameters are configured.
>
> Some devices (e.g. da850) use struct of_dev_auxdata for clock lookup
> but nodes created from within the aemif driver can't access the lookup
> table.
>
> Create a platform data structure that holds a pointer to
> of_dev_auxdata so that we can use it with of_platform_populate().
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> Acked-by: Sekhar Nori <nsekhar@ti.com>
> Acked-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
> ---
Can you please take this one patch via your driver core ?
Regards,
Santosh
^ permalink raw reply
* [PATCH 10/37] PCI: dwc: designware: Fix style errors in pcie-designware.c
From: Joao Pinto @ 2017-01-13 16:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484216786-17292-11-git-send-email-kishon@ti.com>
?s 10:25 AM de 1/12/2017, Kishon Vijay Abraham I escreveu:
> No functional change. Fix all checkpatch warnings and check errors
> in pcie-designware.c
>
> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
> ---
> drivers/pci/dwc/pcie-designware.c | 42 ++++++++++++++++++-------------------
> 1 file changed, 21 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/pci/dwc/pcie-designware.c b/drivers/pci/dwc/pcie-designware.c
> index 89cdb6b..ff04074 100644
> --- a/drivers/pci/dwc/pcie-designware.c
> +++ b/drivers/pci/dwc/pcie-designware.c
> @@ -40,13 +40,13 @@ int dw_pcie_read(void __iomem *addr, int size, u32 *val)
> return PCIBIOS_BAD_REGISTER_NUMBER;
> }
>
> - if (size == 4)
> + if (size == 4) {
> *val = readl(addr);
> - else if (size == 2)
> + } else if (size == 2) {
> *val = readw(addr);
> - else if (size == 1)
> + } else if (size == 1) {
> *val = readb(addr);
> - else {
> + } else {
> *val = 0;
> return PCIBIOS_BAD_REGISTER_NUMBER;
> }
> @@ -203,16 +203,15 @@ irqreturn_t dw_handle_msi_irq(struct pcie_port *pp)
>
> for (i = 0; i < MAX_MSI_CTRLS; i++) {
> dw_pcie_rd_own_conf(pp, PCIE_MSI_INTR0_STATUS + i * 12, 4,
> - (u32 *)&val);
> + (u32 *)&val);
> if (val) {
> ret = IRQ_HANDLED;
> pos = 0;
> while ((pos = find_next_bit(&val, 32, pos)) != 32) {
> irq = irq_find_mapping(pp->irq_domain,
> - i * 32 + pos);
> - dw_pcie_wr_own_conf(pp,
> - PCIE_MSI_INTR0_STATUS + i * 12,
> - 4, 1 << pos);
> + i * 32 + pos);
> + dw_pcie_wr_own_conf(pp, PCIE_MSI_INTR0_STATUS +
> + i * 12, 4, 1 << pos);
> generic_handle_irq(irq);
> pos++;
> }
> @@ -278,8 +277,9 @@ static void dw_pcie_msi_set_irq(struct pcie_port *pp, int irq)
> static int assign_irq(int no_irqs, struct msi_desc *desc, int *pos)
> {
> int irq, pos0, i;
> - struct pcie_port *pp = (struct pcie_port *) msi_desc_to_pci_sysdata(desc);
> + struct pcie_port *pp;
>
> + pp = (struct pcie_port *)msi_desc_to_pci_sysdata(desc);
> pos0 = bitmap_find_free_region(pp->msi_irq_in_use, MAX_MSI_IRQS,
> order_base_2(no_irqs));
> if (pos0 < 0)
> @@ -341,7 +341,7 @@ static void dw_msi_setup_msg(struct pcie_port *pp, unsigned int irq, u32 pos)
> }
>
> static int dw_msi_setup_irq(struct msi_controller *chip, struct pci_dev *pdev,
> - struct msi_desc *desc)
> + struct msi_desc *desc)
> {
> int irq, pos;
> struct pcie_port *pp = pdev->bus->sysdata;
> @@ -389,7 +389,7 @@ static void dw_msi_teardown_irq(struct msi_controller *chip, unsigned int irq)
> {
> struct irq_data *data = irq_get_irq_data(irq);
> struct msi_desc *msi = irq_data_get_msi_desc(data);
> - struct pcie_port *pp = (struct pcie_port *) msi_desc_to_pci_sysdata(msi);
> + struct pcie_port *pp = (struct pcie_port *)msi_desc_to_pci_sysdata(msi);
>
> clear_irq_range(pp, irq, 1, data->hwirq);
> }
> @@ -431,7 +431,7 @@ int dw_pcie_link_up(struct dw_pcie *pci)
> }
>
> static int dw_pcie_msi_map(struct irq_domain *domain, unsigned int irq,
> - irq_hw_number_t hwirq)
> + irq_hw_number_t hwirq)
> {
> irq_set_chip_and_handler(irq, &dw_msi_irq_chip, handle_simple_irq);
> irq_set_chip_data(irq, domain->host_data);
> @@ -468,8 +468,8 @@ int dw_pcie_host_init(struct pcie_port *pp)
>
> cfg_res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "config");
> if (cfg_res) {
> - pp->cfg0_size = resource_size(cfg_res)/2;
> - pp->cfg1_size = resource_size(cfg_res)/2;
> + pp->cfg0_size = resource_size(cfg_res) / 2;
> + pp->cfg1_size = resource_size(cfg_res) / 2;
> pp->cfg0_base = cfg_res->start;
> pp->cfg1_base = cfg_res->start + pp->cfg0_size;
> } else if (!pp->va_cfg0_base) {
> @@ -508,8 +508,8 @@ int dw_pcie_host_init(struct pcie_port *pp)
> break;
> case 0:
> pp->cfg = win->res;
> - pp->cfg0_size = resource_size(pp->cfg)/2;
> - pp->cfg1_size = resource_size(pp->cfg)/2;
> + pp->cfg0_size = resource_size(pp->cfg) / 2;
> + pp->cfg1_size = resource_size(pp->cfg) / 2;
> pp->cfg0_base = pp->cfg->start;
> pp->cfg1_base = pp->cfg->start + pp->cfg0_size;
> break;
> @@ -615,7 +615,7 @@ int dw_pcie_host_init(struct pcie_port *pp)
> }
>
> static int dw_pcie_rd_other_conf(struct pcie_port *pp, struct pci_bus *bus,
> - u32 devfn, int where, int size, u32 *val)
> + u32 devfn, int where, int size, u32 *val)
> {
> int ret, type;
> u32 busdev, cfg_size;
> @@ -654,7 +654,7 @@ static int dw_pcie_rd_other_conf(struct pcie_port *pp, struct pci_bus *bus,
> }
>
> static int dw_pcie_wr_other_conf(struct pcie_port *pp, struct pci_bus *bus,
> - u32 devfn, int where, int size, u32 val)
> + u32 devfn, int where, int size, u32 val)
> {
> int ret, type;
> u32 busdev, cfg_size;
> @@ -711,7 +711,7 @@ static int dw_pcie_valid_device(struct pcie_port *pp, struct pci_bus *bus,
> }
>
> static int dw_pcie_rd_conf(struct pci_bus *bus, u32 devfn, int where,
> - int size, u32 *val)
> + int size, u32 *val)
> {
> struct pcie_port *pp = bus->sysdata;
>
> @@ -727,7 +727,7 @@ static int dw_pcie_rd_conf(struct pci_bus *bus, u32 devfn, int where,
> }
>
> static int dw_pcie_wr_conf(struct pci_bus *bus, u32 devfn,
> - int where, int size, u32 val)
> + int where, int size, u32 val)
> {
> struct pcie_port *pp = bus->sysdata;
>
>
Always good to make clean up! Thanks!
Acked-By: Joao Pinto <jpinto@synopsys.com>
^ permalink raw reply
* [PATCH v3 4/8] x86: stop exporting msr-index.h to userland
From: Borislav Petkov @ 2017-01-13 16:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <dd826bc7-e1ef-be29-e0c3-692afb346036@6wind.com>
On Fri, Jan 13, 2017 at 05:08:34PM +0100, Nicolas Dichtel wrote:
> Le 13/01/2017 ? 16:43, David Howells a ?crit :
> >> -header-y += msr-index.h
> >
> > I see it on my desktop as /usr/include/asm/msr-index.h and it's been there at
> > least four years - and as such it's part of the UAPI. I don't think you can
> > remove it unless you can guarantee there are no userspace users.
> I keep it in the v2 of the series, but the maintainer, Borislav Petkov, asks me
> to un-export it.
>
> I will follow the maintainer decision.
I'm not the maintainer. I simply think that exporting that file was
wrong because it if we change something in it, we will break userspace.
And that should not happen - if userspace needs MSRs, it should do its
own defines.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
^ permalink raw reply
* [PATCH] ARM: mv78xx0: fix possible PCI buffer overflow
From: Gregory CLEMENT @ 2017-01-13 16:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170111134159.3832518-1-arnd@arndb.de>
Hi Arnd,
On mer., janv. 11 2017, Arnd Bergmann <arnd@arndb.de> wrote:
> gcc-7.0 reports a potential array overflow:
>
> arch/arm/mach-mv78xx0/pcie.c: In function 'mv78xx0_pcie_preinit':
> arch/arm/mach-mv78xx0/pcie.c:81:4: error: output may be truncated before the last format character [-Werror=format-truncation=]
>
> I haven't checked if this can actually happen, but making the
> array one 32-bit word longer addresses the warning and makes
> it completely safe.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Applied on mvebu/soc
Thanks,
Gregory
> ---
> arch/arm/mach-mv78xx0/pcie.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-mv78xx0/pcie.c b/arch/arm/mach-mv78xx0/pcie.c
> index 13a7d72ee0c4..81ff4327a962 100644
> --- a/arch/arm/mach-mv78xx0/pcie.c
> +++ b/arch/arm/mach-mv78xx0/pcie.c
> @@ -29,7 +29,7 @@ struct pcie_port {
> u8 root_bus_nr;
> void __iomem *base;
> spinlock_t conf_lock;
> - char mem_space_name[16];
> + char mem_space_name[20];
> struct resource res;
> };
>
> --
> 2.9.0
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [RFC PATCH v2 09/10] drivers/perf: Add support for ARMv8.2 Statistical Profiling Extension
From: Kim Phillips @ 2017-01-13 16:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484323429-15231-10-git-send-email-will.deacon@arm.com>
On Fri, 13 Jan 2017 16:03:48 +0000
Will Deacon <will.deacon@arm.com> wrote:
> +#define DRVNAME "arm_spe_pmu"
PMU is implied. "arm_spe"?
> +static int arm_spe_pmu_event_init(struct perf_event *event)
> +{
> + u64 reg;
> + struct perf_event_attr *attr = &event->attr;
> + struct arm_spe_pmu *spe_pmu = to_spe_pmu(event->pmu);
> +
> + /* This is, of course, deeply driver-specific */
> + if (attr->type != event->pmu->type)
> + return -ENOENT;
> +
> + if (event->cpu >= 0 &&
> + !cpumask_test_cpu(event->cpu, &spe_pmu->supported_cpus))
> + return -ENOENT;
> +
> + if (arm_spe_event_to_pmsevfr(event) & PMSEVFR_EL1_RES0)
> + return -EOPNOTSUPP;
> +
> + if (event->hw.sample_period < spe_pmu->min_period ||
> + event->hw.sample_period & PMSIRR_EL1_IVAL_MASK)
> + return -EOPNOTSUPP;
> +
> + if (attr->exclude_idle)
> + return -EOPNOTSUPP;
> +
> + /*
> + * Feedback-directed frequency throttling doesn't work when we
> + * have a buffer of samples. We'd need to manually count the
> + * samples in the buffer when it fills up and adjust the event
> + * count to reflect that. Instead, force the user to specify a
> + * sample period instead.
> + */
> + if (attr->freq)
> + return -EINVAL;
> +
> + if (is_kernel_in_hyp_mode()) {
> + if (attr->exclude_kernel != attr->exclude_hv)
> + return -EOPNOTSUPP;
> + } else if (!attr->exclude_hv) {
> + return -EOPNOTSUPP;
> + }
> +
> + reg = arm_spe_event_to_pmsfcr(event);
> + if ((reg & BIT(PMSFCR_EL1_FE_SHIFT)) &&
> + !(spe_pmu->features & SPE_PMU_FEAT_FILT_EVT))
> + return -EOPNOTSUPP;
> +
> + if ((reg & BIT(PMSFCR_EL1_FT_SHIFT)) &&
> + !(spe_pmu->features & SPE_PMU_FEAT_FILT_TYP))
> + return -EOPNOTSUPP;
> +
> + if ((reg & BIT(PMSFCR_EL1_FL_SHIFT)) &&
> + !(spe_pmu->features & SPE_PMU_FEAT_FILT_LAT))
> + return -EOPNOTSUPP;
> +
> + return 0;
> +}
Please insert pr_* statements before blindly returning errors before a
better facility becomes available.
Thanks,
Kim
^ permalink raw reply
* [PATCH v4 2/2] dt-bindings: clk: add rockchip,grf property for RK3399
From: Rob Herring @ 2017-01-13 16:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484028930-20305-3-git-send-email-zhengxing@rock-chips.com>
On Tue, Jan 10, 2017 at 02:15:30PM +0800, Xing Zheng wrote:
> Add support for rockchip,grf property which is used for GRF muxes
> on RK3399.
>
> Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>
> ---
>
> Changes in v4:
> - update the decription for rockchip,grf property
>
> Changes in v3: None
> Changes in v2: None
>
> Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt | 6 ++++++
> 1 file changed, 6 insertions(+)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH v1 2/2] arm: dts: mt2701: add nor flash node
From: Marek Vasut @ 2017-01-13 16:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170113172825.75d545a3@bbrezillon>
On 01/13/2017 05:28 PM, Boris Brezillon wrote:
> On Fri, 13 Jan 2017 17:13:55 +0100
> Marek Vasut <marek.vasut@gmail.com> wrote:
>
>> On 01/13/2017 04:12 PM, Matthias Brugger wrote:
>>>
>>>
>>> On 13/01/17 15:17, Boris Brezillon wrote:
>>>> On Fri, 13 Jan 2017 15:13:29 +0800
>>>> Guochun Mao <guochun.mao@mediatek.com> wrote:
>>>>
>>>>> Add Mediatek nor flash node.
>>>>>
>>>>> Signed-off-by: Guochun Mao <guochun.mao@mediatek.com>
>>>>> ---
>>>>> arch/arm/boot/dts/mt2701-evb.dts | 25 +++++++++++++++++++++++++
>>>>> arch/arm/boot/dts/mt2701.dtsi | 12 ++++++++++++
>>>>> 2 files changed, 37 insertions(+)
>>>>>
>>>>> diff --git a/arch/arm/boot/dts/mt2701-evb.dts
>>>>> b/arch/arm/boot/dts/mt2701-evb.dts
>>>>> index 082ca88..85e5ae8 100644
>>>>> --- a/arch/arm/boot/dts/mt2701-evb.dts
>>>>> +++ b/arch/arm/boot/dts/mt2701-evb.dts
>>>>> @@ -24,6 +24,31 @@
>>>>> };
>>>>> };
>>>>>
>>>>> +&nor_flash {
>>>>> + pinctrl-names = "default";
>>>>> + pinctrl-0 = <&nor_pins_default>;
>>>>> + status = "okay";
>>>>> + flash at 0 {
>>>>> + compatible = "jedec,spi-nor";
>>>>> + reg = <0>;
>>>>> + };
>>>>> +};
>>>>> +
>>>>> +&pio {
>>>>> + nor_pins_default: nor {
>>>>> + pins1 {
>>>>> + pinmux = <MT2701_PIN_240_EXT_XCS__FUNC_EXT_XCS>,
>>>>> + <MT2701_PIN_241_EXT_SCK__FUNC_EXT_SCK>,
>>>>> + <MT2701_PIN_239_EXT_SDIO0__FUNC_EXT_SDIO0>,
>>>>> + <MT2701_PIN_238_EXT_SDIO1__FUNC_EXT_SDIO1>,
>>>>> + <MT2701_PIN_237_EXT_SDIO2__FUNC_EXT_SDIO2>,
>>>>> + <MT2701_PIN_236_EXT_SDIO3__FUNC_EXT_SDIO3>;
>>>>> + drive-strength = <MTK_DRIVE_4mA>;
>>>>> + bias-pull-up;
>>>>> + };
>>>>> + };
>>>>> +};
>>>>> +
>>>>> &uart0 {
>>>>> status = "okay";
>>>>> };
>>>>> diff --git a/arch/arm/boot/dts/mt2701.dtsi
>>>>> b/arch/arm/boot/dts/mt2701.dtsi
>>>>> index bdf8954..1eefce4 100644
>>>>> --- a/arch/arm/boot/dts/mt2701.dtsi
>>>>> +++ b/arch/arm/boot/dts/mt2701.dtsi
>>>>> @@ -227,6 +227,18 @@
>>>>> status = "disabled";
>>>>> };
>>>>>
>>>>> + nor_flash: spi at 11014000 {
>>>>> + compatible = "mediatek,mt2701-nor",
>>>>> + "mediatek,mt8173-nor";
>>>>
>>>> Why define both here? Is "mediatek,mt8173-nor" really providing a
>>>> subset of the features supported by "mediatek,mt2701-nor"?
>>>>
>>>
>>> I think even if the ip block is the same, we should provide both
>>> bindings, just in case in the future we find out that mt2701 has some
>>> hidden bug, feature or bug-feature. This way even if we update the
>>> driver, we stay compatible with older device tree blobs in the wild.
>>>
>>> We can drop the mt2701-nor in the bindings definition if you want.
>
> Oh, sorry, I misunderstood. What I meant is that if you want to
> list/support all possible compatibles, maybe you should just put one
> compatible in your DT and patch your driver (+ binding doc) to define
> all of them.
Uh, what ? I lost you here :-)
>> This exactly. We should have a DT compat in the form:
>> compatible = "vendor,<soc>-block", "vendor,<oldest-compat-soc>-block";
>> Then if we find a problem in the future, we can match on the
>> "vendor,<soc>-block" and still support the old DTs.
>
> Not sure it's only in term of whose IP appeared first. My understanding
> is that it's a way to provide inheritance. For example:
>
> "<soc-vendor>,<ip-version>", "<ip-vendor>,<ip-version>";
>
> or
>
> "<soc-vendor>,<full-featured-ip-version>","<soc-vendor>,<basic-feature-ip-version>";
>
> BTW, which one is the oldest between mt8173 and mt2701? :-)
And that's another thing and I agree with you, but I don't think that's
what we're discussing in this thread. But (!), OT, I think we should
codify the rules in Documentation/ . This discussion came up multiple
times recently.
And my question still stands, what do we put into the DT here, IMO
compatible = "mediatek,mt2701-nor", "mediatek,mt8173-nor";
and what goes into the binding document ? I guess both too ?
--
Best regards,
Marek Vasut
^ permalink raw reply
* [PATCH v2 2/2] vring: Force use of DMA API for ARM-based systems
From: Michael S. Tsirkin @ 2017-01-13 16:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170113092522.GB22538@arm.com>
On Fri, Jan 13, 2017 at 09:25:22AM +0000, Will Deacon wrote:
> On Fri, Jan 13, 2017 at 12:12:56AM +0200, Michael S. Tsirkin wrote:
> > On Wed, Jan 11, 2017 at 10:01:39AM +0000, Will Deacon wrote:
> > > On Wed, Jan 11, 2017 at 01:33:31AM +0200, Michael S. Tsirkin wrote:
> > > > On Tue, Jan 10, 2017 at 05:51:18PM +0000, Robin Murphy wrote:
> > > > > From: Will Deacon <will.deacon@arm.com>
> > > > >
> > > > > Booting Linux on an ARM fastmodel containing an SMMU emulation results
> > > > > in an unexpected I/O page fault from the legacy virtio-blk PCI device:
> > > > >
> > > > > [ 1.211721] arm-smmu-v3 2b400000.smmu: event 0x10 received:
> > > > > [ 1.211800] arm-smmu-v3 2b400000.smmu: 0x00000000fffff010
> > > > > [ 1.211880] arm-smmu-v3 2b400000.smmu: 0x0000020800000000
> > > > > [ 1.211959] arm-smmu-v3 2b400000.smmu: 0x00000008fa081002
> > > > > [ 1.212075] arm-smmu-v3 2b400000.smmu: 0x0000000000000000
> > > > > [ 1.212155] arm-smmu-v3 2b400000.smmu: event 0x10 received:
> > > > > [ 1.212234] arm-smmu-v3 2b400000.smmu: 0x00000000fffff010
> > > > > [ 1.212314] arm-smmu-v3 2b400000.smmu: 0x0000020800000000
> > > > > [ 1.212394] arm-smmu-v3 2b400000.smmu: 0x00000008fa081000
> > > > > [ 1.212471] arm-smmu-v3 2b400000.smmu: 0x0000000000000000
> > > > >
> > > > > <system hangs failing to read partition table>
> > > > >
> > > > > This is because the virtio-blk is behind an SMMU, so we have consequently
> > > > > swizzled its DMA ops and configured the SMMU to translate accesses. This
> > > > > then requires the vring code to use the DMA API to establish translations,
> > > > > otherwise all transactions will result in fatal faults and termination.
> > > > >
> > > > > Given that ARM-based systems only see an SMMU if one is really present
> > > > > (the topology is all described by firmware tables such as device-tree or
> > > > > IORT), then we can safely use the DMA API for all virtio devices.
> > > > >
> > > > > Cc: Andy Lutomirski <luto@kernel.org>
> > > > > Cc: Michael S. Tsirkin <mst@redhat.com>
> > > > > Signed-off-by: Will Deacon <will.deacon@arm.com>
> > > >
> > > > I'd like to better understand then need for this one.
> > > > Can't the device in question just set VIRTIO_F_IOMMU_PLATFORM ?
> > > >
> > > > I'd rather we avoided need for more hacks and just
> > > > have everyone switch to that.
> > >
> > > There are a couple of problems with VIRTIO_F_IOMMU_PLATFORM:
> > >
> > > 1. It doesn't exist for legacy devices, which are all we have on the
> > > platform in question.
> > >
> > > 2. It's not documented in the virtio sp^H^HSTOP PRESS. I see you applied
> > > my patch ;). Thanks.
> > >
> > > In which case, for non-legacy devices we should definitely be using
> > > VIRTIO_F_IOMMU_PLATFORM, but since this platform hasn't yet moved to the
> > > world of flying cars, could we unconditionally set the DMA ops on ARM
> > > for legacy devices? The alternative is disabling the SMMU altogether,
> > > but that's less than ideal because there are non-virtio devices on the
> > > same PCI bus.
> > >
> >
> > I'd rather people didn't use SMMU with legacy devices.
>
> I'm afraid we've been doing that for two years and the model already
> exists in a mature state, being actively used for development and
> validation by ARM and our partners. One of the big things its used for
> is to develop SMMU and GIC (our interrupt controller) code with PCI, so
> dropping the SMMU from the picture isn't an option.
Oh so this fixes a regression? This is something I didn't realize.
A "Fixes:" tag can't hurt here. I then wonder
might DMA ops ever use a DMA address which isn't a physical address
from QEMU point of view? If that happens, this hack breaks
because in legacy mode QEMU still uses the GPA.
> > Can't you guys just code up the virtio 1 layout in QEMU?
> > I took a look and it's not a big deal now that two other
> > transports converted, except mmio code in QEMU doesn't
> > use linux header to it's a bit messy.
> > I'll send a patch to clean that up.
>
> If the model ever changes in this area (which isn't planned atm), the
> right thing to do would be to move to modern virtio. However, we're stuck
> with what we have for the forseeable future and it works just fine if we
> use the DMA API. If we don't use it, Linux no longer boots because it
> installs the SMMU-backed DMA ops for the virtio devices and everything
> faults.
>
> I really don't understand why this is controversial.
>
> Will
I agree we need to keep working things working. I just don't yet
understand what change broke things and how did it happen - legacy
devices used to just poke at guest PA from QEMU, what does it matter
that there are changes in DMA ops if neither host nor guest use them for
legacy setups?
I guess that's just me now knowing about how DMA ops work on SMMU
or missing some other basic point about SMMU.
I take your word that it's the right thing to do, but I'd like to figure
it out before merging this. I'll read up in the coming days to make
sure I understand what the patch does, any pointers welcome.
--
MST
^ permalink raw reply
* [PATCH 3/3] rtc: stm32: use 32-bit cast for BIT() macro
From: Arnd Bergmann @ 2017-01-13 16:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <26624cbe-7e71-35a4-b8df-f5ac5d15b1ec@st.com>
On Fri, Jan 13, 2017 at 4:56 PM, Amelie DELAUNAY <amelie.delaunay@st.com> wrote:
> On 01/13/2017 04:32 PM, Arnd Bergmann wrote:
>>
>> Using the ~ operator on a BIT() constant results in a large 'unsigned
>> long'
>> constant that won't fit into an 'unsigned int' function argument on 64-bit
>> architectures, resulting in a harmless build warning in x86 allmodconfig:
>>
>> drivers/rtc/rtc-stm32.c: In function 'stm32_rtc_probe':
>> drivers/rtc/rtc-stm32.c:651:51: error: large integer implicitly truncated
>> to unsigned type [-Werror=overflow]
>> regmap_update_bits(rtc->dbp, PWR_CR, PWR_CR_DBP, ~PWR_CR_DBP);
>
> I thought I would fix this warning by replacing all ~PWR_CR_DBP by 0,
> because the mask PWR_CR_DBP prevents other bits to be cleared.
> In this way, I avoid the ugly cast...
Good idea, much nicer than mine! Can you send that patch?
Arnd
^ permalink raw reply
* [PATCH] coresight: STM: Balance enable/disable
From: Mathieu Poirier @ 2017-01-13 16:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484047315-14407-1-git-send-email-suzuki.poulose@arm.com>
On 10 January 2017 at 04:21, Suzuki K Poulose <suzuki.poulose@arm.com> wrote:
> The stm is automatically enabled when an application sets the policy
> via ->link() call back by using coresight_enable(), which keeps the
> refcount of the current users of the STM. However, the unlink() callback
> issues stm_disable() directly, which leaves the STM turned off, without
> the coresight layer knowing about it. This prevents any further uses
> of the STM hardware as the coresight layer still thinks the STM is
> turned on and doesn't issue an stm_enable(). Even manually enabling
> the STM via sysfs can't really enable the hw.
>
> e.g,
>
> $ echo 1 > $CS_DEVS/$ETR/enable_sink
> $ mkdir -p $CONFIG_FS/stp-policy/$source.0/stm_test/
> $ echo 32768 65535 > $CONFIG_FS/stp-policy/$source.0/stm_test/channels
> $ echo 64 > $CS_DEVS/$source/traceid
> $ ./stm_app
> Sending 64000 byte blocks of pattern 0 at 0us intervals
> Success to map channel(32768~32783) to 0xffffa95fa000
> Sending on channel 32768
> $ dd if=/dev/$ETR of=~/trace.bin.1
> 597+1 records in
> 597+1 records out
> 305920 bytes (306 kB) copied, 0.399952 s, 765 kB/s
> $ ./stm_app
> Sending 64000 byte blocks of pattern 0 at 0us intervals
> Success to map channel(32768~32783) to 0xffff7e9e2000
> Sending on channel 32768
> $ dd if=/dev/$ETR of=~/trace.bin.2
> 0+0 records in
> 0+0 records out
> 0 bytes (0 B) copied, 0.0232083 s, 0.0 kB/s
>
> Note that we don't get any data from the ETR for the second session.
>
> Also dmesg shows :
>
> [ 77.520458] coresight-tmc 20800000.etr: TMC-ETR enabled
> [ 77.537097] coresight-replicator etr_replicator at 20890000: REPLICATOR enabled
> [ 77.558828] coresight-replicator main_replicator at 208a0000: REPLICATOR enabled
> [ 77.581068] coresight-funnel 208c0000.main_funnel: FUNNEL inport 0 enabled
> [ 77.602217] coresight-tmc 20840000.etf: TMC-ETF enabled
> [ 77.618422] coresight-stm 20860000.stm: STM tracing enabled
> [ 139.554252] coresight-stm 20860000.stm: STM tracing disabled
> # End of first tracing session
> [ 146.351135] coresight-tmc 20800000.etr: TMC read start
> [ 146.514486] coresight-tmc 20800000.etr: TMC read end
> # Note that the STM is not turned on via stm_generic_link()->coresight_enable()
> # and hence none of the components are turned on.
> [ 152.479080] coresight-tmc 20800000.etr: TMC read start
> [ 152.542632] coresight-tmc 20800000.etr: TMC read end
>
> This patch balances the unlink operation by using the coresight_disable(),
> keeping the coresight layer in sync with the hardware state.
>
> Fixes: commit 237483aa5cf43 ("coresight: stm: adding driver for CoreSight STM component")
> Cc: Pratik Patel <pratikp@codeaurora.org>
> Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
> Cc: Chunyan Zhang <zhang.chunyan@linaro.org>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: stable at vger.kernel.org # 4.7+
> Reported-by: Robert Walker <robert.walker@arm.com>
> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> ---
> drivers/hwtracing/coresight/coresight-stm.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/hwtracing/coresight/coresight-stm.c b/drivers/hwtracing/coresight/coresight-stm.c
> index 3524452..57b7330 100644
> --- a/drivers/hwtracing/coresight/coresight-stm.c
> +++ b/drivers/hwtracing/coresight/coresight-stm.c
> @@ -356,7 +356,7 @@ static void stm_generic_unlink(struct stm_data *stm_data,
> if (!drvdata || !drvdata->csdev)
> return;
>
> - stm_disable(drvdata->csdev, NULL);
> + coresight_disable(drvdata->csdev);
> }
>
> static phys_addr_t
Applied - thanks,
Mathieu
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH 11/37] PCI: dwc: Split pcie-designware.c into host and core files
From: Joao Pinto @ 2017-01-13 16:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484216786-17292-12-git-send-email-kishon@ti.com>
?s 10:26 AM de 1/12/2017, Kishon Vijay Abraham I escreveu:
> Split pcie-designware.c into pcie-designware-host.c that contains
> the host specific parts of the driver and pcie-designware.c that
> contains the parts used by both host driver and endpoint driver.
>
> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
> ---
> drivers/pci/dwc/Makefile | 2 +-
> drivers/pci/dwc/pcie-designware-host.c | 619 ++++++++++++++++++++++++++++++++
> drivers/pci/dwc/pcie-designware.c | 613 +------------------------------
> drivers/pci/dwc/pcie-designware.h | 8 +
> 4 files changed, 634 insertions(+), 608 deletions(-)
> create mode 100644 drivers/pci/dwc/pcie-designware-host.c
>
> diff --git a/drivers/pci/dwc/Makefile b/drivers/pci/dwc/Makefile
> index 7d27c14..3b57e55 100644
> --- a/drivers/pci/dwc/Makefile
> +++ b/drivers/pci/dwc/Makefile
> @@ -1,4 +1,4 @@
(snip...)
> -static void dw_pcie_prog_outbound_atu(struct dw_pcie *pci, int index,
> - int type, u64 cpu_addr, u64 pci_addr,
> - u32 size)
> +void dw_pcie_prog_outbound_atu(struct dw_pcie *pci, int index, int type,
> + u64 cpu_addr, u64 pci_addr, u32 size)
> {
> u32 retries, val;
>
> @@ -186,220 +151,6 @@ static void dw_pcie_prog_outbound_atu(struct dw_pcie *pci, int index,
> dev_err(pci->dev, "iATU is not being enabled\n");
> }
Kishon, iATU only makes sense in The Root Complex (host), so it should be inside
the pcie-designware-host.
>
> -static struct irq_chip dw_msi_irq_chip = {
> - .name = "PCI-MSI",
> - .irq_enable = pci_msi_unmask_irq,
> - .irq_disable = pci_msi_mask_irq,
> - .irq_mask = pci_msi_mask_irq,
> - .irq_unmask = pci_msi_unmask_irq,
> -};
> -
(snip...)
> -
> -static const struct irq_domain_ops msi_domain_ops = {
> - .map = dw_pcie_msi_map,
> -};
> -
> static u8 dw_pcie_iatu_unroll_enabled(struct dw_pcie *pci)
> {
> u32 val;
> @@ -454,303 +192,11 @@ static u8 dw_pcie_iatu_unroll_enabled(struct dw_pcie *pci)
> return 0;
> }
Kishon, iATU only makes sense in The Root Complex (host), so it should be inside
the pcie-designware-host.
(snip...)
> diff --git a/drivers/pci/dwc/pcie-designware.h b/drivers/pci/dwc/pcie-designware.h
> index 491fbe3..808d17b 100644
> --- a/drivers/pci/dwc/pcie-designware.h
> +++ b/drivers/pci/dwc/pcie-designware.h
> @@ -14,6 +14,10 @@
> #ifndef _PCIE_DESIGNWARE_H
> #define _PCIE_DESIGNWARE_H
>
> +#include <linux/irq.h>
> +#include <linux/msi.h>
> +#include <linux/pci.h>
> +
> /* Parameters for the waiting for link up routine */
> #define LINK_WAIT_MAX_RETRIES 10
> #define LINK_WAIT_USLEEP_MIN 90000
> @@ -167,4 +171,8 @@ struct dw_pcie {
> void dw_pcie_writel_dbi(struct dw_pcie *pci, u32 reg, u32 val);
> int dw_pcie_link_up(struct dw_pcie *pci);
> int dw_pcie_wait_for_link(struct dw_pcie *pci);
> +void dw_pcie_prog_outbound_atu(struct dw_pcie *pci, int index,
> + int type, u64 cpu_addr, u64 pci_addr,
> + u32 size);
> +void dw_pcie_setup(struct dw_pcie *pci);
Kishon, iATU only makes sense in The Root Complex (host), so it should be inside
the pcie-designware-host as static.
> #endif /* _PCIE_DESIGNWARE_H */
>
Thanks,
Joao
^ permalink raw reply
* [PATCH 1/3] rtc: stm32: remove __exit annotation on remove callback
From: Alexandre Belloni @ 2017-01-13 16:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170113153311.2611510-1-arnd@arndb.de>
On 13/01/2017 at 16:32:51 +0100, Arnd Bergmann wrote :
> The remove function can be called at runtime for a manual 'unbind'
> operation and must not be left out from a built-in driver, as kbuild
> complains:
>
> `stm32_rtc_remove' referenced in section `.data.stm32_rtc_driver' of drivers/rtc/rtc-stm32.o: defined in discarded section `.exit.text' of drivers/rtc/rtc-stm32.o
>
> This removes the extraneous annotation.
>
> Fixes: 4e64350f42e2 ("rtc: add STM32 RTC driver")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> drivers/rtc/rtc-stm32.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
Applied, thanks.
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH 2/3] rtc: stm32: fix building without CONFIG_OF
From: Alexandre Belloni @ 2017-01-13 16:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170113153311.2611510-2-arnd@arndb.de>
On 13/01/2017 at 16:32:52 +0100, Arnd Bergmann wrote :
> The new driver has a stray #ifdef in it that causes a build error:
>
> drivers/rtc/rtc-stm32.c:718:21: error: 'stm32_rtc_of_match' undeclared here (not in a function); did you mean 'stm32_rtc_pm_ops'?
>
> As the #ifdef serves no purpose here, let's just remove it.
>
> Fixes: 4e64350f42e2 ("rtc: add STM32 RTC driver")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> drivers/rtc/rtc-stm32.c | 2 --
> 1 file changed, 2 deletions(-)
>
Applied, thanks.
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH v1 2/2] arm: dts: mt2701: add nor flash node
From: Boris Brezillon @ 2017-01-13 16:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <86c997be-f500-eaa1-3ba5-d21cff6223b7@gmail.com>
On Fri, 13 Jan 2017 17:44:12 +0100
Marek Vasut <marek.vasut@gmail.com> wrote:
> On 01/13/2017 05:28 PM, Boris Brezillon wrote:
> > On Fri, 13 Jan 2017 17:13:55 +0100
> > Marek Vasut <marek.vasut@gmail.com> wrote:
> >
> >> On 01/13/2017 04:12 PM, Matthias Brugger wrote:
> >>>
> >>>
> >>> On 13/01/17 15:17, Boris Brezillon wrote:
> >>>> On Fri, 13 Jan 2017 15:13:29 +0800
> >>>> Guochun Mao <guochun.mao@mediatek.com> wrote:
> >>>>
> >>>>> Add Mediatek nor flash node.
> >>>>>
> >>>>> Signed-off-by: Guochun Mao <guochun.mao@mediatek.com>
> >>>>> ---
> >>>>> arch/arm/boot/dts/mt2701-evb.dts | 25 +++++++++++++++++++++++++
> >>>>> arch/arm/boot/dts/mt2701.dtsi | 12 ++++++++++++
> >>>>> 2 files changed, 37 insertions(+)
> >>>>>
> >>>>> diff --git a/arch/arm/boot/dts/mt2701-evb.dts
> >>>>> b/arch/arm/boot/dts/mt2701-evb.dts
> >>>>> index 082ca88..85e5ae8 100644
> >>>>> --- a/arch/arm/boot/dts/mt2701-evb.dts
> >>>>> +++ b/arch/arm/boot/dts/mt2701-evb.dts
> >>>>> @@ -24,6 +24,31 @@
> >>>>> };
> >>>>> };
> >>>>>
> >>>>> +&nor_flash {
> >>>>> + pinctrl-names = "default";
> >>>>> + pinctrl-0 = <&nor_pins_default>;
> >>>>> + status = "okay";
> >>>>> + flash at 0 {
> >>>>> + compatible = "jedec,spi-nor";
> >>>>> + reg = <0>;
> >>>>> + };
> >>>>> +};
> >>>>> +
> >>>>> +&pio {
> >>>>> + nor_pins_default: nor {
> >>>>> + pins1 {
> >>>>> + pinmux = <MT2701_PIN_240_EXT_XCS__FUNC_EXT_XCS>,
> >>>>> + <MT2701_PIN_241_EXT_SCK__FUNC_EXT_SCK>,
> >>>>> + <MT2701_PIN_239_EXT_SDIO0__FUNC_EXT_SDIO0>,
> >>>>> + <MT2701_PIN_238_EXT_SDIO1__FUNC_EXT_SDIO1>,
> >>>>> + <MT2701_PIN_237_EXT_SDIO2__FUNC_EXT_SDIO2>,
> >>>>> + <MT2701_PIN_236_EXT_SDIO3__FUNC_EXT_SDIO3>;
> >>>>> + drive-strength = <MTK_DRIVE_4mA>;
> >>>>> + bias-pull-up;
> >>>>> + };
> >>>>> + };
> >>>>> +};
> >>>>> +
> >>>>> &uart0 {
> >>>>> status = "okay";
> >>>>> };
> >>>>> diff --git a/arch/arm/boot/dts/mt2701.dtsi
> >>>>> b/arch/arm/boot/dts/mt2701.dtsi
> >>>>> index bdf8954..1eefce4 100644
> >>>>> --- a/arch/arm/boot/dts/mt2701.dtsi
> >>>>> +++ b/arch/arm/boot/dts/mt2701.dtsi
> >>>>> @@ -227,6 +227,18 @@
> >>>>> status = "disabled";
> >>>>> };
> >>>>>
> >>>>> + nor_flash: spi at 11014000 {
> >>>>> + compatible = "mediatek,mt2701-nor",
> >>>>> + "mediatek,mt8173-nor";
> >>>>
> >>>> Why define both here? Is "mediatek,mt8173-nor" really providing a
> >>>> subset of the features supported by "mediatek,mt2701-nor"?
> >>>>
> >>>
> >>> I think even if the ip block is the same, we should provide both
> >>> bindings, just in case in the future we find out that mt2701 has some
> >>> hidden bug, feature or bug-feature. This way even if we update the
> >>> driver, we stay compatible with older device tree blobs in the wild.
> >>>
> >>> We can drop the mt2701-nor in the bindings definition if you want.
> >
> > Oh, sorry, I misunderstood. What I meant is that if you want to
> > list/support all possible compatibles, maybe you should just put one
> > compatible in your DT and patch your driver (+ binding doc) to define
> > all of them.
>
> Uh, what ? I lost you here :-)
>
> >> This exactly. We should have a DT compat in the form:
> >> compatible = "vendor,<soc>-block", "vendor,<oldest-compat-soc>-block";
> >> Then if we find a problem in the future, we can match on the
> >> "vendor,<soc>-block" and still support the old DTs.
> >
> > Not sure it's only in term of whose IP appeared first. My understanding
> > is that it's a way to provide inheritance. For example:
> >
> > "<soc-vendor>,<ip-version>", "<ip-vendor>,<ip-version>";
> >
> > or
> >
> > "<soc-vendor>,<full-featured-ip-version>","<soc-vendor>,<basic-feature-ip-version>";
> >
> > BTW, which one is the oldest between mt8173 and mt2701? :-)
>
> And that's another thing and I agree with you, but I don't think that's
> what we're discussing in this thread. But (!), OT, I think we should
> codify the rules in Documentation/ . This discussion came up multiple
> times recently.
>
> And my question still stands, what do we put into the DT here, IMO
> compatible = "mediatek,mt2701-nor", "mediatek,mt8173-nor";
I'd say
compatible = "mediatek,mt8173-nor";
because both compatible are referring to very specific IP version. It's
not the same as
compatible = "mediatek,mt8173-nor", "mediatek,mt81xx-nor";
where you clearly have a generic compatible which is overloaded by a
specific one.
But anyway, I'm not the one taking the decision here, let's wait for DT
maintainers reviews.
> and what goes into the binding document ? I guess both too ?
If both exist, they should be both documented.
^ permalink raw reply
* [RFC PATCH] arm64: defconfig: enable SMMUv3 config
From: Arnd Bergmann @ 2017-01-13 16:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5878F3DA.3090005@hisilicon.com>
On Friday, January 13, 2017 3:35:54 PM CET Wei Xu wrote:
> On 2017/1/12 9:47, Catalin Marinas wrote:
> > On Thu, Jan 12, 2017 at 08:36:12AM +0800, Zhou Wang wrote:
> >> On 2017/1/9 19:50, Zhou Wang wrote:
> >>> Signed-off-by: Zhou Wang <wangzhou1@hisilicon.com>
> >>> ---
> >>> arch/arm64/configs/defconfig | 1 +
> >>> 1 file changed, 1 insertion(+)
> >>>
> >>> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
> >>> index 869dded..3520c50 100644
> >>> --- a/arch/arm64/configs/defconfig
> >>> +++ b/arch/arm64/configs/defconfig
> >>> @@ -440,6 +440,7 @@ CONFIG_PLATFORM_MHU=y
> >>> CONFIG_BCM2835_MBOX=y
> >>> CONFIG_HI6220_MBOX=y
> >>> CONFIG_ARM_SMMU=y
> >>> +CONFIG_ARM_SMMU_V3=y
> >>> CONFIG_RASPBERRYPI_POWER=y
> >>> CONFIG_QCOM_SMEM=y
> >>> CONFIG_QCOM_SMD=y
> >>
> >> I just happened to find there is no SMMUv3 config in arm64 defconfig.
> >>
> >> Maybe we should add it in defconfig or I miss something.
> >
>
> Hi Arnd,
>
> > It looks fine to me but it's usually the arm-soc guys picking the
> > defconfig patches.
> >
>
> It is fine to me.
> Is it OK for me to pick up this or will you directly pick up this?
> Thanks!
Either way works for me. I usually recommend platform maintainers
picking up patches and then sending them on to arm at kernel.org,
as that gets our attention quicker. A patch that gets sent with
me personally on Cc might get lost in the email.
Arnd
^ permalink raw reply
* [PATCH v2 2/2] vring: Force use of DMA API for ARM-based systems
From: Michael S. Tsirkin @ 2017-01-13 16:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CALCETrXYwp4BJbwFo4P1hEvubyDh1mN+W4L-tQVYjh3e7F-Q9A@mail.gmail.com>
On Wed, Jan 11, 2017 at 10:12:36AM -0800, Andy Lutomirski wrote:
> On Wed, Jan 11, 2017 at 2:01 AM, Will Deacon <will.deacon@arm.com> wrote:
> > On Wed, Jan 11, 2017 at 01:33:31AM +0200, Michael S. Tsirkin wrote:
> >> On Tue, Jan 10, 2017 at 05:51:18PM +0000, Robin Murphy wrote:
> >> > From: Will Deacon <will.deacon@arm.com>
> >> >
> >> > Booting Linux on an ARM fastmodel containing an SMMU emulation results
> >> > in an unexpected I/O page fault from the legacy virtio-blk PCI device:
> >> >
> >> > [ 1.211721] arm-smmu-v3 2b400000.smmu: event 0x10 received:
> >> > [ 1.211800] arm-smmu-v3 2b400000.smmu: 0x00000000fffff010
> >> > [ 1.211880] arm-smmu-v3 2b400000.smmu: 0x0000020800000000
> >> > [ 1.211959] arm-smmu-v3 2b400000.smmu: 0x00000008fa081002
> >> > [ 1.212075] arm-smmu-v3 2b400000.smmu: 0x0000000000000000
> >> > [ 1.212155] arm-smmu-v3 2b400000.smmu: event 0x10 received:
> >> > [ 1.212234] arm-smmu-v3 2b400000.smmu: 0x00000000fffff010
> >> > [ 1.212314] arm-smmu-v3 2b400000.smmu: 0x0000020800000000
> >> > [ 1.212394] arm-smmu-v3 2b400000.smmu: 0x00000008fa081000
> >> > [ 1.212471] arm-smmu-v3 2b400000.smmu: 0x0000000000000000
> >> >
> >> > <system hangs failing to read partition table>
> >> >
> >> > This is because the virtio-blk is behind an SMMU, so we have consequently
> >> > swizzled its DMA ops and configured the SMMU to translate accesses. This
> >> > then requires the vring code to use the DMA API to establish translations,
> >> > otherwise all transactions will result in fatal faults and termination.
> >> >
> >> > Given that ARM-based systems only see an SMMU if one is really present
> >> > (the topology is all described by firmware tables such as device-tree or
> >> > IORT), then we can safely use the DMA API for all virtio devices.
> >> >
> >> > Cc: Andy Lutomirski <luto@kernel.org>
> >> > Cc: Michael S. Tsirkin <mst@redhat.com>
> >> > Signed-off-by: Will Deacon <will.deacon@arm.com>
> >>
> >> I'd like to better understand then need for this one.
> >> Can't the device in question just set VIRTIO_F_IOMMU_PLATFORM ?
> >>
> >> I'd rather we avoided need for more hacks and just
> >> have everyone switch to that.
> >
> > There are a couple of problems with VIRTIO_F_IOMMU_PLATFORM:
> >
> > 1. It doesn't exist for legacy devices, which are all we have on the
> > platform in question.
> >
> > 2. It's not documented in the virtio sp^H^HSTOP PRESS. I see you applied
> > my patch ;). Thanks.
> >
> > In which case, for non-legacy devices we should definitely be using
> > VIRTIO_F_IOMMU_PLATFORM, but since this platform hasn't yet moved to the
> > world of flying cars, could we unconditionally set the DMA ops on ARM
> > for legacy devices? The alternative is disabling the SMMU altogether,
> > but that's less than ideal because there are non-virtio devices on the
> > same PCI bus.
>
> Also, on ARM, using the DMA API appears to *always* be the correct
> approach. Why not do it all the time, then? The non-DMA-API path is
> a legacy thing that is needed because a few platforms incorrectly
> enumerate their IOMMUs. ARM gets it right, so I don't see why ARM
> should be subject to the legacy mess.
I didn't realize ARM gets this right. QEMU still pokes at
physical addresses directly in legacy mode so I wonder how could
that be the case. I'll try to find out.
> Even on x86, it should be possible to get the code into a state where
> using DMA ops is always correct.
>
> --Andy
This I could totally get behind. A driver would install some per device
flag to make it figure out IOMMU does not apply, and in a portable way
since at least x86 and PPC need this, maybe more. This would/should
also handle the bug that admin can bind vfio to legacy virtio
devices even without the noiommu mode.
--
MST
^ permalink raw reply
* [PATCH v4 0/4] DMA Engine: switch PL330 driver to non-irq-safe runtime PM
From: Arnd Bergmann @ 2017-01-13 17:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <60596eee-12a9-58f3-387e-145a5bc28aaa@samsung.com>
On Friday, January 13, 2017 3:12:57 PM CET Marek Szyprowski wrote:
> On 2017-01-13 14:59, Ulf Hansson wrote:
> > On 13 January 2017 at 08:26, Marek Szyprowski <m.szyprowski@samsung.com> wrote:
> > I did only a brief review so far, particularly concentrating on the
> > changes for device links and runtime PM. I like it!
> >
> > Perhaps we can get someone like Arnd/Vinod to comment in general idea
> > from a DT and DMA slave channel point of view. I don't know that stuff
> > good enough to give good opinion.
>
> Arnd already said that it looks good:
> http://www.spinics.net/lists/dmaengine/msg12186.html
Rihgt, feel free to add my
Acked-by: Arnd Bergmann <arnd@arndb.de>
Arnd
^ permalink raw reply
* [RFC PATCH v2 09/10] drivers/perf: Add support for ARMv8.2 Statistical Profiling Extension
From: Will Deacon @ 2017-01-13 17:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170113104042.169ceea12820d2b6b74b31f9@arm.com>
On Fri, Jan 13, 2017 at 10:40:42AM -0600, Kim Phillips wrote:
> On Fri, 13 Jan 2017 16:03:48 +0000
> Will Deacon <will.deacon@arm.com> wrote:
>
> > +#define DRVNAME "arm_spe_pmu"
>
> PMU is implied. "arm_spe"?
As stated before, I'm going for consistency here. Is it causing any
real issues on the tooling side?
> > + if (is_kernel_in_hyp_mode()) {
> > + if (attr->exclude_kernel != attr->exclude_hv)
> > + return -EOPNOTSUPP;
> > + } else if (!attr->exclude_hv) {
> > + return -EOPNOTSUPP;
> > + }
> > +
> > + reg = arm_spe_event_to_pmsfcr(event);
> > + if ((reg & BIT(PMSFCR_EL1_FE_SHIFT)) &&
> > + !(spe_pmu->features & SPE_PMU_FEAT_FILT_EVT))
> > + return -EOPNOTSUPP;
> > +
> > + if ((reg & BIT(PMSFCR_EL1_FT_SHIFT)) &&
> > + !(spe_pmu->features & SPE_PMU_FEAT_FILT_TYP))
> > + return -EOPNOTSUPP;
> > +
> > + if ((reg & BIT(PMSFCR_EL1_FL_SHIFT)) &&
> > + !(spe_pmu->features & SPE_PMU_FEAT_FILT_LAT))
> > + return -EOPNOTSUPP;
> > +
> > + return 0;
> > +}
>
> Please insert pr_* statements before blindly returning errors before a
> better facility becomes available.
That was discussed in the thread I linked to last time:
https://lkml.org/lkml/2015/8/26/661
and there are good reasons not to add those prints.
Will
^ permalink raw reply
* [GIT PULL] ARM: mvebu: defconfig64 for v4.11 (#1)
From: Gregory CLEMENT @ 2017-01-13 17:11 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
Here is the first pull request for defconfig64 for mvebu for v4.11.
Gregory
The following changes since commit 7ce7d89f48834cefece7804d38fc5d85382edf77:
Linux 4.10-rc1 (2016-12-25 16:13:08 -0800)
are available in the git repository at:
git://git.infradead.org/linux-mvebu.git tags/mvebu-defconfig64-4.11-1
for you to fetch changes up to 299d2f0238ec75bd13cc8c69a4cd6dbb9e7837be:
arm64: defconfig: enable XORv2 for Marvell Armada 7K/8K (2017-01-03 16:38:51 +0100)
----------------------------------------------------------------
mvebu defconfig64 for 4.11 (part 1)
Update arm64 defconfig by adding XORv2 for Marvell Armada 7K/8K
----------------------------------------------------------------
Thomas Petazzoni (1):
arm64: defconfig: enable XORv2 for Marvell Armada 7K/8K
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
^ permalink raw reply
* [PATCH] coresight: STM: Balance enable/disable
From: Suzuki K Poulose @ 2017-01-13 17:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANLsYkyO-anR4V411tHFkNBPNy0Vk3DCympLScP9ZC=uJ-UX9g@mail.gmail.com>
On 13/01/17 16:48, Mathieu Poirier wrote:
> On 10 January 2017 at 04:21, Suzuki K Poulose <suzuki.poulose@arm.com> wrote:
>> The stm is automatically enabled when an application sets the policy
>> via ->link() call back by using coresight_enable(), which keeps the
>> refcount of the current users of the STM. However, the unlink() callback
>> issues stm_disable() directly, which leaves the STM turned off, without
>> the coresight layer knowing about it. This prevents any further uses
>> of the STM hardware as the coresight layer still thinks the STM is
>> turned on and doesn't issue an stm_enable(). Even manually enabling
>> the STM via sysfs can't really enable the hw.
>>
...
>>
>> This patch balances the unlink operation by using the coresight_disable(),
>> keeping the coresight layer in sync with the hardware state.
>>
>> Fixes: commit 237483aa5cf43 ("coresight: stm: adding driver for CoreSight STM component")
>> Cc: Pratik Patel <pratikp@codeaurora.org>
>> Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
>> Cc: Chunyan Zhang <zhang.chunyan@linaro.org>
>> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>> Cc: stable at vger.kernel.org # 4.7+
>> Reported-by: Robert Walker <robert.walker@arm.com>
>> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
>> ---
>> drivers/hwtracing/coresight/coresight-stm.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/hwtracing/coresight/coresight-stm.c b/drivers/hwtracing/coresight/coresight-stm.c
>> index 3524452..57b7330 100644
>> --- a/drivers/hwtracing/coresight/coresight-stm.c
>> +++ b/drivers/hwtracing/coresight/coresight-stm.c
>> @@ -356,7 +356,7 @@ static void stm_generic_unlink(struct stm_data *stm_data,
>> if (!drvdata || !drvdata->csdev)
>> return;
>>
>> - stm_disable(drvdata->csdev, NULL);
>> + coresight_disable(drvdata->csdev);
>> }
>>
>> static phys_addr_t
>
> Applied - thanks,
Mathieu, Greg,
I think this should go into 4.10 (either way, as fix in this cycle or via stable after the release). I think
it would be easier if it goes in as fix during one of these rc cycle.
Please let me know your thoughts.
Suzuki
> Mathieu
>
>> --
>> 2.7.4
>>
^ permalink raw reply
* [GIT PULL] ARM: mvebu: dt for v4.11 (#1)
From: Gregory CLEMENT @ 2017-01-13 17:11 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
Here is the first pull request for dt for mvebu for v4.11.
Gregory
The following changes since commit 7ce7d89f48834cefece7804d38fc5d85382edf77:
Linux 4.10-rc1 (2016-12-25 16:13:08 -0800)
are available in the git repository at:
git://git.infradead.org/linux-mvebu.git tags/mvebu-dt-4.11-1
for you to fetch changes up to 7b7db5ab33d2292d9b037cda0c41a795b094d940:
ARM: dts: turris-omnia: add support for ethernet switch (2017-01-05 13:59:18 +0100)
----------------------------------------------------------------
mvebu dt for 4.11 (part 1)
- Add support for the ethernet switch on the Turris Omnia board
- Clean up and improvement for ClearFog boards
- Correct license text which was mangled when switching to dual license
----------------------------------------------------------------
Alexandre Belloni (1):
ARM: dts: mvebu: Correct license text
Russell King (14):
ARM: dts: armada388-clearfog: fix SPI flash #size-cells
ARM: dts: armada388-clearfog: move SPI flash into microsom
ARM: dts: armada388-clearfog: move sdhci pinctrl node to microsom
ARM: dts: armada388-clearfog: split clearfog DTS file
ARM: dts: armada388-clearfog: move DSA switch
ARM: dts: armada388-clearfog: move second PCIe port
ARM: dts: armada388-clearfog: move SPI CS1
ARM: dts: armada388-clearfog: move rear button
ARM: dts: armada388-clearfog: add base model DTS file
ARM: dts: armada388-clearfog: add pro model DTS file
ARM: dts: armada388-clearfog: move device specific pinctrl nodes
ARM: dts: armada388-clearfog: move I2C nodes
ARM: dts: armada388-clearfog: move ethernet related nodes
ARM: dts: armada388-clearfog: move uart nodes
Uwe Kleine-K?nig (1):
ARM: dts: turris-omnia: add support for ethernet switch
arch/arm/boot/dts/Makefile | 2 +
arch/arm/boot/dts/armada-370-db.dts | 10 +-
arch/arm/boot/dts/armada-370-dlink-dns327l.dts | 10 +-
arch/arm/boot/dts/armada-370-mirabox.dts | 10 +-
arch/arm/boot/dts/armada-370-netgear-rn102.dts | 10 +-
arch/arm/boot/dts/armada-370-netgear-rn104.dts | 10 +-
arch/arm/boot/dts/armada-370-rd.dts | 10 +-
arch/arm/boot/dts/armada-370-synology-ds213j.dts | 10 +-
arch/arm/boot/dts/armada-370-xp.dtsi | 10 +-
arch/arm/boot/dts/armada-370.dtsi | 10 +-
arch/arm/boot/dts/armada-375-db.dts | 10 +-
arch/arm/boot/dts/armada-375.dtsi | 10 +-
arch/arm/boot/dts/armada-380.dtsi | 10 +-
arch/arm/boot/dts/armada-385-turris-omnia.dts | 58 +++-
arch/arm/boot/dts/armada-385.dtsi | 10 +-
arch/arm/boot/dts/armada-388-clearfog-base.dts | 109 ++++++
arch/arm/boot/dts/armada-388-clearfog-pro.dts | 55 +++
arch/arm/boot/dts/armada-388-clearfog.dts | 374 ++++-----------------
arch/arm/boot/dts/armada-388-clearfog.dtsi | 307 +++++++++++++++++
arch/arm/boot/dts/armada-388-db.dts | 10 +-
arch/arm/boot/dts/armada-388-rd.dts | 10 +-
.../arm/boot/dts/armada-38x-solidrun-microsom.dtsi | 130 ++++---
arch/arm/boot/dts/armada-38x.dtsi | 10 +-
arch/arm/boot/dts/armada-390-db.dts | 10 +-
arch/arm/boot/dts/armada-390.dtsi | 10 +-
arch/arm/boot/dts/armada-395.dtsi | 10 +-
arch/arm/boot/dts/armada-398-db.dts | 10 +-
arch/arm/boot/dts/armada-398.dtsi | 10 +-
arch/arm/boot/dts/armada-39x.dtsi | 10 +-
arch/arm/boot/dts/armada-xp-axpwifiap.dts | 10 +-
arch/arm/boot/dts/armada-xp-db.dts | 10 +-
arch/arm/boot/dts/armada-xp-gp.dts | 10 +-
arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts | 10 +-
arch/arm/boot/dts/armada-xp-matrix.dts | 10 +-
arch/arm/boot/dts/armada-xp-mv78230.dtsi | 10 +-
arch/arm/boot/dts/armada-xp-mv78260.dtsi | 10 +-
arch/arm/boot/dts/armada-xp-mv78460.dtsi | 10 +-
arch/arm/boot/dts/armada-xp-netgear-rn2120.dts | 10 +-
arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts | 10 +-
arch/arm/boot/dts/armada-xp-synology-ds414.dts | 10 +-
arch/arm/boot/dts/armada-xp.dtsi | 10 +-
arch/arm/boot/dts/dove-cm-a510.dtsi | 10 +-
arch/arm/boot/dts/dove-sbc-a510.dts | 10 +-
arch/arm/boot/dts/kirkwood-linkstation-6282.dtsi | 10 +-
.../boot/dts/kirkwood-linkstation-duo-6281.dtsi | 10 +-
arch/arm/boot/dts/kirkwood-linkstation-lsqvl.dts | 10 +-
arch/arm/boot/dts/kirkwood-linkstation-lsvl.dts | 10 +-
arch/arm/boot/dts/kirkwood-linkstation-lswsxl.dts | 10 +-
arch/arm/boot/dts/kirkwood-linkstation-lswvl.dts | 10 +-
arch/arm/boot/dts/kirkwood-linkstation-lswxl.dts | 10 +-
arch/arm/boot/dts/kirkwood-linkstation.dtsi | 10 +-
arch/arm/boot/dts/mvebu-linkstation-fan.dtsi | 10 +-
.../boot/dts/mvebu-linkstation-gpio-simple.dtsi | 10 +-
arch/arm/boot/dts/orion5x-kuroboxpro.dts | 10 +-
arch/arm/boot/dts/orion5x-linkstation-lsgl.dts | 10 +-
arch/arm/boot/dts/orion5x-linkstation-lswtgl.dts | 10 +-
arch/arm/boot/dts/orion5x-linkstation.dtsi | 10 +-
arch/arm/boot/dts/orion5x-lschl.dts | 10 +-
arch/arm/boot/dts/orion5x-lswsgl.dts | 10 +-
59 files changed, 933 insertions(+), 622 deletions(-)
create mode 100644 arch/arm/boot/dts/armada-388-clearfog-base.dts
create mode 100644 arch/arm/boot/dts/armada-388-clearfog-pro.dts
create mode 100644 arch/arm/boot/dts/armada-388-clearfog.dtsi
^ permalink raw reply
* [GIT PULL] ARM: mvebu: dt64 for v4.11 (#1)
From: Gregory CLEMENT @ 2017-01-13 17:12 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
Here is the first pull request for dt64 for mvebu for v4.11.
Gregory
The following changes since commit 7ce7d89f48834cefece7804d38fc5d85382edf77:
Linux 4.10-rc1 (2016-12-25 16:13:08 -0800)
are available in the git repository at:
git://git.infradead.org/linux-mvebu.git tags/mvebu-dt64-4.11-1
for you to fetch changes up to 58a748f7dc29d8a7bb74c6cbba6a82425dbba5cc:
ARM64: dts: marvell: Correct license text (2017-01-03 16:24:34 +0100)
----------------------------------------------------------------
mvebu dt64 for 4.11 (part 1)
- Correct license text which was mangled when switching to dual license
- Add SPI and I2C nodes on Armada 3700(driver support had been already
merged)
- Add support for the ethernet switch on the EspressoBin board (driver
support not yet merged)
----------------------------------------------------------------
Alexandre Belloni (1):
ARM64: dts: marvell: Correct license text
Romain Perier (4):
arm64: dts: marvell: Add ethernet switch definition for the ESPRESSObin
arm64: dts: marvell: Add definition of SPI controller for Armada 3700
arm64: dts: marvell: Enable spi0 on the board Armada-3720-db
arm64: dts: marvell: Add I2C definitions for the Armada 3700
arch/arm64/boot/dts/marvell/armada-371x.dtsi | 10 +--
arch/arm64/boot/dts/marvell/armada-3720-db.dts | 44 +++++++++++--
.../boot/dts/marvell/armada-3720-espressobin.dts | 76 ++++++++++++++++++++--
arch/arm64/boot/dts/marvell/armada-372x.dtsi | 10 +--
arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 39 +++++++++--
5 files changed, 154 insertions(+), 25 deletions(-)
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox