* [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
* [PATCH 09/37] PCI: dwc: designware: Parse *num-lanes* property in dw_pcie_setup_rc
From: Joao Pinto @ 2017-01-13 17:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484216786-17292-10-git-send-email-kishon@ti.com>
Hi,
?s 10:25 AM de 1/12/2017, Kishon Vijay Abraham I escreveu:
> *num-lanes* dt property is parsed in dw_pcie_host_init. However
> *num-lanes* property is applicable to both root complex mode and
> endpoint mode. As a first step, move the parsing of this property
> outside dw_pcie_host_init. This is in preparation for splitting
> pcie-designware.c to pcie-designware.c and pcie-designware-host.c
>
> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
> ---
> drivers/pci/dwc/pcie-designware.c | 18 +++++++++++-------
> drivers/pci/dwc/pcie-designware.h | 1 -
> 2 files changed, 11 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/pci/dwc/pcie-designware.c b/drivers/pci/dwc/pcie-designware.c
> index 00a0fdc..89cdb6b 100644
> --- a/drivers/pci/dwc/pcie-designware.c
> +++ b/drivers/pci/dwc/pcie-designware.c
> @@ -551,10 +551,6 @@ int dw_pcie_host_init(struct pcie_port *pp)
> }
> }
>
> - ret = of_property_read_u32(np, "num-lanes", &pci->lanes);
> - if (ret)
> - pci->lanes = 0;
> -
> ret = of_property_read_u32(np, "num-viewport", &pci->num_viewport);
> if (ret)
> pci->num_viewport = 2;
> @@ -751,18 +747,26 @@ static int dw_pcie_wr_conf(struct pci_bus *bus, u32 devfn,
>
> void dw_pcie_setup_rc(struct pcie_port *pp)
> {
> + int ret;
> + u32 lanes;
> u32 val;
> struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
> + struct device *dev = pci->dev;
> + struct device_node *np = dev->of_node;
>
> /* get iATU unroll support */
> pci->iatu_unroll_enabled = dw_pcie_iatu_unroll_enabled(pci);
> dev_dbg(pci->dev, "iATU unroll: %s\n",
> pci->iatu_unroll_enabled ? "enabled" : "disabled");
>
> + ret = of_property_read_u32(np, "num-lanes", &lanes);
> + if (ret)
> + lanes = 0;
You moved from host_init to root complex setup function, which in my opinion did
not improve (in this scope).
I suggest that instead of making so much intermediary patches, which is nice to
understand your development sequence, but hard to review. Wouldn't be better to
condense some of the patches? We would have a cloear vision of the final product :)
Joao
> +
> /* set the number of lanes */
> val = dw_pcie_readl_dbi(pci, PCIE_PORT_LINK_CONTROL);
> val &= ~PORT_LINK_MODE_MASK;
> - switch (pci->lanes) {
> + switch (lanes) {
> case 1:
> val |= PORT_LINK_MODE_1_LANES;
> break;
> @@ -776,7 +780,7 @@ void dw_pcie_setup_rc(struct pcie_port *pp)
> val |= PORT_LINK_MODE_8_LANES;
> break;
> default:
> - dev_err(pci->dev, "num-lanes %u: invalid value\n", pci->lanes);
> + dev_err(pci->dev, "num-lanes %u: invalid value\n", lanes);
> return;
> }
> dw_pcie_writel_dbi(pci, PCIE_PORT_LINK_CONTROL, val);
> @@ -784,7 +788,7 @@ void dw_pcie_setup_rc(struct pcie_port *pp)
> /* set link width speed control register */
> val = dw_pcie_readl_dbi(pci, PCIE_LINK_WIDTH_SPEED_CONTROL);
> val &= ~PORT_LOGIC_LINK_WIDTH_MASK;
> - switch (pci->lanes) {
> + switch (lanes) {
> case 1:
> val |= PORT_LOGIC_LINK_WIDTH_1_LANES;
> break;
> diff --git a/drivers/pci/dwc/pcie-designware.h b/drivers/pci/dwc/pcie-designware.h
> index d4b3d43..491fbe3 100644
> --- a/drivers/pci/dwc/pcie-designware.h
> +++ b/drivers/pci/dwc/pcie-designware.h
> @@ -148,7 +148,6 @@ struct dw_pcie_ops {
> struct dw_pcie {
> struct device *dev;
> void __iomem *dbi_base;
> - u32 lanes;
> u32 num_viewport;
> u8 iatu_unroll_enabled;
> struct pcie_port pp;
>
^ permalink raw reply
* [PATCH 36/37] ARM: DRA7: clockdomain: Change the CLKTRCTRL of CM_PCIE_CLKSTCTRL to SW_WKUP
From: Tony Lindgren @ 2017-01-13 17:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484216786-17292-37-git-send-email-kishon@ti.com>
* Kishon Vijay Abraham I <kishon@ti.com> [170112 02:35]:
> The PCIe programming sequence in TRM suggests CLKSTCTRL of PCIe should
> be set to SW_WKUP. There are no issues when CLKSTCTRL is set to HW_AUTO
> in RC mode. However in EP mode, the host system is not able to access the
> MEMSPACE and setting the CLKSTCTRL to SW_WKUP fixes it.
I guess ideally in the long run we would set this dynamically based on
the selected mode, right?
Regards,
Tony
> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
> ---
> arch/arm/mach-omap2/clockdomains7xx_data.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-omap2/clockdomains7xx_data.c b/arch/arm/mach-omap2/clockdomains7xx_data.c
> index 6c67965..67ebff8 100644
> --- a/arch/arm/mach-omap2/clockdomains7xx_data.c
> +++ b/arch/arm/mach-omap2/clockdomains7xx_data.c
> @@ -524,7 +524,7 @@
> .dep_bit = DRA7XX_PCIE_STATDEP_SHIFT,
> .wkdep_srcs = pcie_wkup_sleep_deps,
> .sleepdep_srcs = pcie_wkup_sleep_deps,
> - .flags = CLKDM_CAN_HWSUP_SWSUP,
> + .flags = CLKDM_CAN_SWSUP,
> };
>
> static struct clockdomain atl_7xx_clkdm = {
> --
> 1.7.9.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [PATCH 05/37] PCI: dwc: Add platform_set_drvdata
From: Joao Pinto @ 2017-01-13 17:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484216786-17292-6-git-send-email-kishon@ti.com>
Hi,
?s 10:25 AM de 1/12/2017, Kishon Vijay Abraham I escreveu:
> Add platform_set_drvdata in all designware based drivers to store the
> private data structure of the driver so that dev_set_drvdata can be
> used to get back private data pointer in add_pcie_port/host_init.
> This is in preparation for splitting struct pcie_port into core and
> host only structures. After the split pcie_port will not be part of
> the driver's private data structure and *container_of* used now
> to get the private data pointer cannot be used.
>
> Cc: Jingoo Han <jingoohan1@gmail.com>
> Cc: Richard Zhu <hongxing.zhu@nxp.com>
> Cc: Lucas Stach <l.stach@pengutronix.de>
> Cc: Murali Karicheri <m-karicheri2@ti.com>
> Cc: Minghuan Lian <minghuan.Lian@freescale.com>
> Cc: Mingkai Hu <mingkai.hu@freescale.com>
> Cc: Roy Zang <tie-fei.zang@freescale.com>
> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> Cc: Niklas Cassel <niklas.cassel@axis.com>
> Cc: Jesper Nilsson <jesper.nilsson@axis.com>
> Cc: Joao Pinto <Joao.Pinto@synopsys.com>
> Cc: Zhou Wang <wangzhou1@hisilicon.com>
> Cc: Gabriele Paoloni <gabriele.paoloni@huawei.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 | 3 ++-
> drivers/pci/dwc/pci-exynos.c | 3 ++-
> drivers/pci/dwc/pci-imx6.c | 3 ++-
> drivers/pci/dwc/pci-keystone.c | 2 ++
> drivers/pci/dwc/pci-layerscape.c | 2 ++
> drivers/pci/dwc/pcie-armada8k.c | 2 ++
> drivers/pci/dwc/pcie-artpec6.c | 2 ++
> drivers/pci/dwc/pcie-designware-plat.c | 2 ++
> drivers/pci/dwc/pcie-hisi.c | 2 ++
> drivers/pci/dwc/pcie-qcom.c | 2 ++
> drivers/pci/dwc/pcie-spear13xx.c | 3 ++-
> 11 files changed, 22 insertions(+), 4 deletions(-)
>
This is an example of a change that could be merged with another patch that
gives it more meaning, like I wrote in the review of patch 9/37.
Thanks,
Joao
^ 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