* [PATCH v4 00/18] net-next: stmmac: add dwmac-sun8i ethernet driver
From: Corentin Labbe @ 2017-04-12 11:13 UTC (permalink / raw)
To: linux-arm-kernel
Hello
This patch series add the driver for dwmac-sun8i which handle the Ethernet MAC
present on Allwinner H3/H5/A83T/A64 SoCs.
This driver is the continuation of the sun8i-emac driver.
During the development, it appeared that in fact the hardware was a modified
version of some dwmac.
So the driver is now written as a glue driver for stmmac.
It supports 10/100/1000 Mbit/s speed with half/full duplex.
It can use an internal PHY (MII 10/100) or an external PHY
via RGMII/RMII.
This patch series enable the driver only for the H3/A64/H5 SoC since A83T
doesn't have the necessary clocks present in mainline.
The driver have been tested on the following boards:
- H3 Orange PI PC, BananaPI-M2+
- A64 Pine64, BananaPi-M64
- A83T BananaPI-M3
The first two patchs are some mandatory changes for letting dwmac-sun8i be used.
The following three patchs add the driver and its documentation.
The remaining are DT patch enabling it.
Regards
Corentin Labbe
Changes since v3:
- Renamed tx-delay/rx-delay to tx-delay-ps/rx-delay-ps
- fix syscon compatible example
- Changed parameter type for setup() function
- Dropped some DT patchs for boards which I could not test further
Changes since v2:
- corrected order of syscon compatible
- added compatible = "ethernet-phy-ieee802.3-c22 to PHY
- added set_mac function
Changes since v1:
- added TX/RX delay units
- splitted syscon documentation in its own patch
- regulator is now disabled after clk_prepare_enable(gmac->tx_clk) error
- Fixed a memory leak on mac_device_info
- Use now generic pin config for all DT stuff
- CONFIG_DWMAC_SUN8I is now set to y in defconfigs
Corentin Labbe (18):
net: stmmac: export stmmac_set_mac_addr/stmmac_get_mac_addr
net: stmmac: add optional setup function
dt-bindings: net: Add DT bindings documentation for Allwinner
dwmac-sun8i
dt-bindings: syscon: Add DT bindings documentation for Allwinner
syscon
net: stmmac: Add dwmac-sun8i
arm: sun8i: sunxi-h3-h5: Add dt node for the syscon control module
arm: sun8i: sunxi-h3-h5: add dwmac-sun8i ethernet driver
arm: sun8i: orangepi-pc: Enable dwmac-sun8i
arm: sun8i: orangepi-2: Enable dwmac-sun8i
arm: sun8i: orangepi-one: Enable dwmac-sun8i
arm: sun8i: orangepi-pc-plus: Set EMAC activity LEDs to active high
arm64: allwinner: sun50i-a64: Add dt node for the syscon control
module
arm64: allwinner: sun50i-a64: add dwmac-sun8i Ethernet driver
arm: allwinner: pine64: Enable dwmac-sun8i
arm: allwinner: pine64-plus: Enable dwmac-sun8i
arm64: allwinner: bananapi-m64: Enable dwmac-sun8i
arm: sunxi: Enable dwmac-sun8i driver on sunxi_defconfig
arm: multi_v7: Enable dwmac-sun8i driver on multi_v7_defconfig
.../devicetree/bindings/misc/allwinner,syscon.txt | 19 +
.../devicetree/bindings/net/dwmac-sun8i.txt | 77 ++
arch/arm/boot/dts/sun8i-h3-orangepi-2.dts | 8 +
arch/arm/boot/dts/sun8i-h3-orangepi-one.dts | 8 +
arch/arm/boot/dts/sun8i-h3-orangepi-pc-plus.dts | 5 +
arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts | 8 +
arch/arm/boot/dts/sunxi-h3-h5.dtsi | 40 +
arch/arm/configs/multi_v7_defconfig | 1 +
arch/arm/configs/sunxi_defconfig | 1 +
.../boot/dts/allwinner/sun50i-a64-bananapi-m64.dts | 15 +
.../boot/dts/allwinner/sun50i-a64-pine64-plus.dts | 17 +-
.../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 16 +
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 43 +
drivers/net/ethernet/stmicro/stmmac/Kconfig | 11 +
drivers/net/ethernet/stmicro/stmmac/Makefile | 1 +
drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 960 +++++++++++++++++++++
drivers/net/ethernet/stmicro/stmmac/dwmac_lib.c | 3 +-
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 29 +-
.../net/ethernet/stmicro/stmmac/stmmac_platform.c | 9 +-
include/linux/stmmac.h | 2 +
20 files changed, 1268 insertions(+), 5 deletions(-)
create mode 100644 Documentation/devicetree/bindings/misc/allwinner,syscon.txt
create mode 100644 Documentation/devicetree/bindings/net/dwmac-sun8i.txt
create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
--
2.10.2
^ permalink raw reply
* linux-next: manual merge of the mvebu tree with the arm-soc tree
From: Stephen Rothwell @ 2017-04-12 10:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87a87mhw5w.fsf@free-electrons.com>
Hi Gregory,
On Wed, 12 Apr 2017 10:23:07 +0200 Gregory CLEMENT <gregory.clement@free-electrons.com> wrote:
>
> How do you want to proceed with this conflict?
>
> Do you want that I merged arm-soc/next/arm64 in my mvebu/defconfig64
> branch before applying my patch ?
>
> Or do you prefer that I continue to base my branch on v4.11-rc1 and then
> you will take care of the conflict when pulling the branch?
The conflict is trivial, I would hope that it will be handled when they
merge your tree.
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* [RFC PATCH 5/7] iommu/arm-smmu-v3: For ACPI based device probing, set relevant options for different SMMUv3 implementations.
From: Linu Cherian @ 2017-04-12 10:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170412084336.GM4906@rric.localdomain>
>> + switch (model) {
>> + case ACPI_IORT_SMMU_V3:
>> + case ACPI_IORT_SMMU_CORELINK_MMU600:
>> + break;
>> + case ACPI_IORT_SMMU_V3_HISILICON:
>> + smmu->options |= ARM_SMMU_OPT_SKIP_PREFETCH;
>> + break;
>> + case ACPI_IORT_SMMU_V3_CAVIUM_CN99XX:
>> + smmu->options |= (ARM_SMMU_OPT_PAGE0_REGS_ONLY |
>> + ARM_SMMU_OPT_USE_SHARED_IRQS);
>> + break;
>> + default:
>> + ret = -ENODEV;
>> + }
>> +
>> + return ret;
>> +}
>> +
>> static int arm_smmu_device_acpi_probe(struct platform_device *pdev,
>> struct arm_smmu_device *smmu)
>> {
>> struct acpi_iort_smmu_v3 *iort_smmu;
>> struct device *dev = smmu->dev;
>> struct acpi_iort_node *node;
>> + int ret;
>>
>> node = *(struct acpi_iort_node **)dev_get_platdata(dev);
>>
>> /* Retrieve SMMUv3 specific data */
>> iort_smmu = (struct acpi_iort_smmu_v3 *)node->node_data;
>>
>> + ret = acpi_smmu_get_options(iort_smmu->model, smmu);
>> + if (ret < 0)
>> + return ret;
>> +
>
> could we add at least:
>
> dev_notice(smmu->dev, "option mask 0x%x\n", smmu->options);
>
> We need a note to see which options have been enabled.
>
Yeah. Will add that.
Thanks.
^ permalink raw reply
* [GIT PULL] arm64: fixes for -rc6
From: Punit Agrawal @ 2017-04-12 10:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170412091445.GB27097@arm.com>
On 12/04/17 10:14, Will Deacon wrote:
> Hi Jon,
>
> On Tue, Apr 11, 2017 at 03:12:57PM -0400, Jon Masters wrote:
>> On 04/07/2017 12:02 PM, Will Deacon wrote:
>>
>>> Please pull these two arm64 fixes for -rc6. We've got a regression fix for
>>> the signal raised when userspace makes an unsupported unaligned access and a
>>> revert of the contiguous (hugepte) support for hugetlb, which has once again
>>> been found to be broken. One day, maybe, we'll get it right.
>>
>> <snip>
>>
>>> - Revert broken support for the contiguous bit in hugetlb (again...)
>>
>> Quick aside: is this being worked on for 4.12? If not, should we ping
>> Linaro and look to get some focus on this? It's right to disable this,
>> but also painful to those wanting to work on various NFV use cases.
>
> I think Punit and Steve (CC'd) are working on this, but the issues run
> beyond the lack of break-before-make. The core GUP code, for example,
> doesn't even support hugeptes. There are also dormant issues with hugeptes
> and swap/migration entries, which would hit if somebody flipped
> CONFIG_ARCH_ENABLE_HUGEPAGE_MIGRATION. Hell, even the pte_huge macro is
> bogus if you're using contiguous ptes (granted, it's seldom used, but if
> the above are fixed maybe it will be).
Steve has a fix for the break-before-make[0].
I've posted some fixes for contiguous hugepages support in preparation
for enabling memory failure handling[1] but as the changes touch
multiple architectures, it may take some time to merge.
I'll take a look at the GUP code next but no promises on a timeframe yet.
Thanks,
Punit
[0]
http://lists.infradead.org/pipermail/linux-arm-kernel/2017-March/497027.html
[1] https://lwn.net/Articles/718974/
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
^ permalink raw reply
* [PATCH v3 04/32] asm-generic: add ioremap_nopost() remap interface
From: Lorenzo Pieralisi @ 2017-04-12 10:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1491952447.7236.24.camel@kernel.crashing.org>
On Wed, Apr 12, 2017 at 09:14:07AM +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2017-04-11 at 15:31 +0100, Lorenzo Pieralisi wrote:
> > > This is a semantic that simply *cannot* be generically provided accross
> > > architectures as a mapping attribute.
> >
> > I agree that a default implementation does not make much sense. The
> > only solution to this, if we want the ioremap_nopost to be made available
> > to generic code (and drivers - ie DT PCI host bridge drivers on ARM/ARM64
> > are not arch code), is to make the ioremap_nopost() call return NULL
> > unless overriden by arch code that can provide its semantics.
>
> That would be a better option.
I think that's what I will implement which basically means I will
replace the default:
static inline void __iomem *ioremap_nopost(phys_addr_t offset, size_t size)
{
return ioremap_nocache(offset, size);
}
with
static inline void __iomem *ioremap_nopost(phys_addr_t offset, size_t size)
{
return NULL;
}
If an arch can override ioremap_nopost() with sensible mapping
attributes (or whatever make it enforceable) it does, if it can't
any ioremap_nopost() usage will result in a mapping failure, if you
see any other viable solution please shout.
Thanks,
Lorenzo
^ permalink raw reply
* [RFC PATCH v0.2] PCI: Add support for tango PCIe host bridge
From: Marc Zyngier @ 2017-04-12 9:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <241b130e-1fb7-ecd4-034e-eb02065ada66@free.fr>
On 12/04/17 10:50, Mason wrote:
> On 12/04/2017 10:08, Marc Zyngier wrote:
>
>> On 11/04/17 18:52, Mason wrote:
>>
>>> so data->irq is the virq (30, 34, 35, 36)
>>> and data->hwirq is the domain hwirq (0, 524288, 524289, 524290)
>>>
>>> Is there a way to map hwirq 524288 to MSI 0, hwirq 524289 to MSI 1, etc?
>>
>> Why would you need to do such a thing?
>> - In MSI domain: IRQ34 -> hwirq 524288
>> - In foo domain: IRQ34 -> hwirq [whatever your driver has allocated]
>>
>> The data is already there, at your fingertips. Just deal with with your
>> "foo" irqchip.
>
> OK, let me take a step back, I may have missed the forest for
> the trees.
>
> In my original code (copied from the Altera driver) I unmasked
> a given MSI in the tango_irq_domain_alloc() function. You said
> this was the wrong place, as it should be done in the irqchip
> unmask callback. Did I understand correctly, so far?
Yes.
> I have registered custom mask/unmask callbacks for both irq_chips.
And that's *wrong*. I've repeatedly said that you only need to deal with
*your* irqchip. End of story. Nowhere else. Please leave the MSI irqchip
alone, it is very unlikely that you have to provide anything at all to it.
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [RFC PATCH v0.2] PCI: Add support for tango PCIe host bridge
From: Mason @ 2017-04-12 9:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <bc5bf8ad-69ef-4f14-f450-e162ddb5af7c@arm.com>
On 12/04/2017 10:08, Marc Zyngier wrote:
> On 11/04/17 18:52, Mason wrote:
>
>> so data->irq is the virq (30, 34, 35, 36)
>> and data->hwirq is the domain hwirq (0, 524288, 524289, 524290)
>>
>> Is there a way to map hwirq 524288 to MSI 0, hwirq 524289 to MSI 1, etc?
>
> Why would you need to do such a thing?
> - In MSI domain: IRQ34 -> hwirq 524288
> - In foo domain: IRQ34 -> hwirq [whatever your driver has allocated]
>
> The data is already there, at your fingertips. Just deal with with your
> "foo" irqchip.
OK, let me take a step back, I may have missed the forest for
the trees.
In my original code (copied from the Altera driver) I unmasked
a given MSI in the tango_irq_domain_alloc() function. You said
this was the wrong place, as it should be done in the irqchip
unmask callback. Did I understand correctly, so far?
I have registered custom mask/unmask callbacks for both irq_chips.
The unmask callback that gets called is the one where hwirqs are
524288 and up. But what I need at that point is the "real" MSI
number, because I need to set bit i in some HW register.
Did I somehow mix up domains in one of the init functions?
Regards.
Current debug code posted below, because natural language is often
too ambiguous.
#define MSI_COUNT 32
struct tango_pcie {
void __iomem *mux;
void __iomem *msi_status;
void __iomem *msi_mask;
phys_addr_t msi_doorbell;
struct mutex lock; /* lock for updating msi_mask */
struct irq_domain *irq_domain;
struct irq_domain *msi_domain;
int irq;
};
static void tango_msi_isr(struct irq_desc *desc)
{
unsigned long status;
unsigned int pos, virq;
struct irq_chip *chip = irq_desc_get_chip(desc);
struct tango_pcie *pcie = irq_desc_get_handler_data(desc);
chained_irq_enter(chip, desc);
status = readl_relaxed(pcie->msi_status);
writel_relaxed(status, pcie->msi_status); /* clear IRQs */
for_each_set_bit(pos, &status, MSI_COUNT) {
virq = irq_find_mapping(pcie->irq_domain, pos);
generic_handle_irq(virq);
}
chained_irq_exit(chip, desc);
}
#define HOP printk("\nENTER %s\n", __func__); dump_stack()
void foo_ack(struct irq_data *data) { HOP; }
void foo_mask(struct irq_data *data) { HOP; pci_msi_mask_irq(data); }
void foo_unmask(struct irq_data *data) { HOP; pci_msi_unmask_irq(data); }
static struct irq_chip tango_msi_irq_chip = {
.name = "MSI_foo",
.irq_ack = foo_ack,
.irq_mask = foo_mask,
.irq_unmask = foo_unmask,
};
static struct msi_domain_info msi_domain_info = {
.flags = MSI_FLAG_PCI_MSIX | MSI_FLAG_USE_DEF_DOM_OPS | MSI_FLAG_USE_DEF_CHIP_OPS,
.chip = &tango_msi_irq_chip,
};
static void tango_compose_msi_msg(struct irq_data *data, struct msi_msg *msg)
{
struct tango_pcie *pcie = irq_data_get_irq_chip_data(data);
msg->address_lo = lower_32_bits(pcie->msi_doorbell);
msg->address_hi = upper_32_bits(pcie->msi_doorbell);
msg->data = data->hwirq;
}
static int tango_set_affinity(struct irq_data *irq_data,
const struct cpumask *mask, bool force)
{
return -EINVAL;
}
void bar_ack(struct irq_data *data) { HOP; }
void bar_mask(struct irq_data *data) { HOP; }
void bar_unmask(struct irq_data *data) { HOP; }
static struct irq_chip tango_msi_chip = {
.name = "MSI_bar",
.irq_compose_msi_msg = tango_compose_msi_msg,
.irq_set_affinity = tango_set_affinity,
.irq_ack = bar_ack,
.irq_mask = bar_mask,
.irq_unmask = bar_unmask,
};
static int find_free_msi(struct irq_domain *dom, unsigned int virq)
{
unsigned int pos;
unsigned long mask;
struct tango_pcie *pcie = dom->host_data;
mask = readl_relaxed(pcie->msi_mask);
pos = find_first_zero_bit(&mask, MSI_COUNT);
if (pos >= MSI_COUNT)
return -ENOSPC;
writel_relaxed(mask | BIT(pos), pcie->msi_mask);
irq_domain_set_info(dom, virq, pos, &tango_msi_chip,
dom->host_data, handle_edge_irq, NULL, NULL);
return 0;
}
static int tango_irq_domain_alloc(struct irq_domain *dom,
unsigned int virq, unsigned int nr_irqs, void *args)
{
int err;
struct tango_pcie *pcie = dom->host_data;
mutex_lock(&pcie->lock);
err = find_free_msi(dom, virq);
mutex_unlock(&pcie->lock);
return err;
}
static void tango_irq_domain_free(struct irq_domain *dom,
unsigned int virq, unsigned int nr_irqs)
{
struct irq_data *d = irq_domain_get_irq_data(dom, virq);
struct tango_pcie *pcie = irq_data_get_irq_chip_data(d);
unsigned int mask, pos = d->hwirq;
mutex_lock(&pcie->lock);
mask = readl_relaxed(pcie->msi_mask);
writel_relaxed(mask & ~BIT(pos), pcie->msi_mask);
mutex_unlock(&pcie->lock);
}
static const struct irq_domain_ops msi_dom_ops = {
.alloc = tango_irq_domain_alloc,
.free = tango_irq_domain_free,
};
static int tango_msi_remove(struct platform_device *pdev)
{
struct tango_pcie *pcie = platform_get_drvdata(pdev);
irq_set_chained_handler_and_data(pcie->irq, NULL, NULL);
irq_domain_remove(pcie->msi_domain);
irq_domain_remove(pcie->irq_domain);
return 0;
}
static int tango_msi_probe(struct platform_device *pdev, struct tango_pcie *pcie)
{
int virq;
struct fwnode_handle *fwnode = of_node_to_fwnode(pdev->dev.of_node);
struct irq_domain *msi_dom, *irq_dom;
mutex_init(&pcie->lock);
writel_relaxed(0, pcie->msi_mask);
irq_dom = irq_domain_create_linear(fwnode, MSI_COUNT, &msi_dom_ops, pcie);
if (!irq_dom) {
pr_err("Failed to create IRQ domain\n");
return -ENOMEM;
}
msi_dom = pci_msi_create_irq_domain(fwnode, &msi_domain_info, irq_dom);
if (!msi_dom) {
pr_err("Failed to create MSI domain\n");
irq_domain_remove(irq_dom);
return -ENOMEM;
}
virq = platform_get_irq(pdev, 1);
if (virq <= 0) {
pr_err("Failed to map IRQ\n");
irq_domain_remove(msi_dom);
irq_domain_remove(irq_dom);
return -ENXIO;
}
pcie->irq_domain = irq_dom;
pcie->msi_domain = msi_dom;
pcie->irq = virq;
irq_set_chained_handler_and_data(virq, tango_msi_isr, pcie);
return 0;
}
^ permalink raw reply
* [PATCH v3 00/32] PCI: fix config and I/O Address space memory mappings
From: Lorenzo Pieralisi @ 2017-04-12 9:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1491952371.7236.22.camel@kernel.crashing.org>
On Wed, Apr 12, 2017 at 09:12:51AM +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2017-04-11 at 15:08 +0100, Lorenzo Pieralisi wrote:
> > On Tue, Apr 11, 2017 at 11:38:26PM +1000, Benjamin Herrenschmidt wrote:
> > > On Tue, 2017-04-11 at 13:28 +0100, Lorenzo Pieralisi wrote:
> > > > This patch series[1] is a v3 of a previous version:
> > > >
> > > > v2: https://lkml.org/lkml/2017/3/27/220
> > >
> > > I am not a fan of this at All.
> > >
> > > That whole concept of "ioremap_nopost" is simply not applicable to the
> > > majority of architectures and certainly not in a way that can apply to
> > > arbitrary mappings.
> > >
> > > It's also very wrong to provide a "default" operation whose semantics
> > > are weaker than what it's supposed to implement. Very wrong actually.
> > > People will use it assuming the non-posted behaviour and things will
> > > break in subtle way when it cannot be provided.
> >
> > Well, what's very wrong for you it is not very wrong for others
> > (it is just v3, that's fine, see thread below).
>
> Maybe, but I don't see in what universe it is ok to have something
> defined for the stronger ordering semantics it provide silently
> fallback to weaker semantics.
I agree :). The drivers I am patching use ioremap() already that's
why falling back to ioremap_nocache() seemed reasonable, but again
I agree with you here.
> > I can easily make ioremap_nopost() mirror ioremap_uc() (ie return
> > NULL unless overriden so that basically you can't use in on an arch
> > that can't provide its semantics) but then that becomes very wrong
> > for other reviewers.
>
> Those reviewers are WRONG :-)
>
> > https://lkml.org/lkml/2017/4/6/396
> >
> > > What exactly are you trying to fix here ?
> >
> > I wrote in the commit logs and cover letter what I am fixing here.
>
> Right right, what *actual bug you have observed* are you trying to fix
> ?
I have not observed any bug and I never claimed that. It started here:
http://lists.infradead.org/pipermail/linux-arm-kernel/2017-January/477353.html
If you prefer I am making ARM/ARM64 PCI host bridge drivers
specifications compliant, given that it is architecturally
required.
> I'm pretty such close to all non-x86 archs had that "problem" since the
> dawn of time and it has never hurt anybody.
Good but I still do not see why I would not make this PCI/ARM architecture
compliant.
> That said, I don't think it makes sense to "solve" it by creating a
> "generic" mapping semantic that is basically impossible to implement on
> most architectures out there (and cannot be emulated).
>
> This is a problem to be solved by the bridge itself. If ARM has a
> mapping attribute to make stores non-posted, keep this an ARM specific
> attribute at this stage I'd say.
I can't. Some PCI host bridge drivers (DT) are shared between ARM/ARM64
and live in drivers (and are also reused on some arches eg microblaze)
and they use ioremap() to map config space.
So the idea behind this series was to add an interface (that is
overriden on ARM/ARM64), it started as a PCI specific interface (v1) and
evolved to ioremap_nopost() (v2).
Thanks,
Lorenzo
> > Anyway:
> >
> > "The PCI specifications (Rev 3.0, 3.2.5 "Transaction Ordering and
> > Posting") mandate non-posted configuration transactions. As further
> > highlighted in the PCIe specifications (4.0 - Rev0.3, "Ordering
> > Considerations for the Enhanced Configuration Access Mechanism"),
> > through ECAM and ECAM-derivative configuration mechanism, the memory
> > mapped transactions from the host CPU into Configuration Requests on the
> > PCI express fabric may create ordering problems for software because
> > writes to memory address are typically posted transactions (unless the
> > architecture can enforce through virtual address mapping non-posted
> > write transactions behaviour) but writes to Configuration Space are not
> > posted on the PCI express fabric."
> >
> > On ARM64:
> >
> > "This rule is reinforced by the ARM v8 architecture reference manual
> > (issue A.k, Early Write Acknowledgment) that explicitly recommends
> > that No Early Write Acknowledgment attribute should be used to map
> > PCI configuration (write) transactions."
> >
> > > If a given PCIe host bridge (architecture specific) require a special
> > > sauce to provide the illusion of non-posting, then implement this in
> > > the actual root complex code.
> > >
> > > BTW. I'm pretty sure we "accidentally" made config writes posted at
> > > least to the PHB on a number of powerpc systems forever and we *never*
> > > had a problem because of it ;)
> >
> > Ok so we should ignore the PCIe specifications and ARM v8 reference
> > manual waiting for a kernel bug to appear ? Is that what you suggest
> > doing ?
> >
> > Lorenzo
> >
> > > > v2 -> v3:
> > > > - Created a default ioremap_nopost() implementation in a
> > > > separate
> > > > ??asm-generic header and patched all arches to make use of it
> > > > - Removed PCI drivers patches from the series to simplify the
> > > > ??review, they will be posted separately once the
> > > > ioremap_nopost()
> > > > ??interface is settled
> > > > - Fixed devm_ioremap_* BUS offset comments and implemented
> > > > ??nopost interface on top of it
> > > > - Added collected tags
> > > >
> > > > v1: https://lkml.org/lkml/2017/2/27/228
> > > >
> > > > v1 -> v2:
> > > > - Changed pci_remap_cfgspace() to more generic ioremap_nopost()
> > > > ??interface
> > > > - Added pgprot_nonposted
> > > > - Fixed build errors on arches not relying on asm-generic
> > > > headers
> > > > - Added PCI versatile host controller driver patch
> > > > - Added missing config space remapping to hisilicon host
> > > > controller
> > > >
> > > > ---------------------
> > > > Original cover letter
> > > > ---------------------
> > > >
> > > > PCI local bus specifications (Rev3.0, 3.2.5 "Transaction Ordering
> > > > and Posting") strictly require PCI configuration and I/O Address
> > > > space
> > > > write transactions to be non-posted.
> > > >
> > > > Current crop of DT/ACPI PCI host controllers drivers relies on
> > > > the ioremap interface to map ECAM and ECAM-derivative PCI config
> > > > regions and pci_remap_iospace() to create a VMA for mapping
> > > > PCI host bridge I/O Address space transactions to CPU virtual address
> > > > space.
> > > >
> > > > On some platforms (ie ARM/ARM64) ioremap fails to comply with the PCI
> > > > configuration non-posted write transactions requirement, because it
> > > > provides a memory mapping that issues "bufferable" or, in PCI terms
> > > > "posted" write transactions. Likewise, the current
> > > > pci_remap_iospace()
> > > > implementation maps the physical address range that the PCI
> > > > translates
> > > > to I/O space cycles to virtual address space through pgprot_device()
> > > > attributes that on eg ARM64 provides a memory mapping issuing
> > > > posted writes transactions, which is not PCI specifications
> > > > compliant.
> > > >
> > > > This patch series[1] addresses both issues in one go:
> > > >
> > > > - It updates the pci_remap_iospace() function to use a page mapping
> > > > ? that guarantees non-posted write transactions for I/O space
> > > > addresses
> > > > - It adds a kernel API to remap PCI config space resources, so that
> > > > ? architecture can override it with a mapping implementation that
> > > > ? guarantees PCI specifications compliancy wrt non-posted write
> > > > ? configuration transactions
> > > > - It updates all PCI host controller implementations (and the generic
> > > > ? ECAM layer) to use the newly introduced mapping interface
> > > >
> > > > Tested on Juno ECAM based interface (DT/ACPI).
> > > >
> > > > Non-ECAM PCI host controller drivers patches need checking to make
> > > > sure that:
> > > >
> > > > - I patched the correct resource region mapping for config space
> > > > - There are not any other ways to ensure posted-write completion
> > > > ? in the respective pci_ops that make the relevant patch unnecessary
> > > >
> > > > [1]
> > > > git://git.kernel.org/pub/scm/linux/kernel/git/lpieralisi/linux.git
> > > > pci/config-io-mappings-fix-v3
> > > >
> > > > Lorenzo Pieralisi (32):
> > > > ? PCI: remove __weak tag from pci_remap_iospace()
> > > > ? asm-generic/pgtable.h: introduce pgprot_nonposted remap attribute
> > > > ? PCI: fix pci_remap_iospace() remap attribute
> > > > ? asm-generic: add ioremap_nopost() remap interface
> > > > ? alpha: include default ioremap_nopost() implementation
> > > > ? avr32: include default ioremap_nopost() implementation
> > > > ? arc: include default ioremap_nopost() implementation
> > > > ? cris: include default ioremap_nopost() implementation
> > > > ? frv: include default ioremap_nopost() implementation
> > > > ? hexagon: include default ioremap_nopost() implementation
> > > > ? ia64: include default ioremap_nopost() implementation
> > > > ? m32r: include default ioremap_nopost() implementation
> > > > ? m68k: include default ioremap_nopost() implementation
> > > > ? metag: include default ioremap_nopost() implementation
> > > > ? microblaze: include default ioremap_nopost() implementation
> > > > ? mips: include default ioremap_nopost() implementation
> > > > ? mn10300: include default ioremap_nopost() implementation
> > > > ? nios2: include default ioremap_nopost() implementation
> > > > ? openrisc: include default ioremap_nopost() implementation
> > > > ? parisc: include default ioremap_nopost() implementation
> > > > ? powerpc: include default ioremap_nopost() implementation
> > > > ? s390: include default ioremap_nopost() implementation
> > > > ? sh: include default ioremap_nopost() implementation
> > > > ? sparc: include default ioremap_nopost() implementation
> > > > ? tile: include default ioremap_nopost() implementation
> > > > ? unicore32: include default ioremap_nopost() implementation
> > > > ? x86: include default ioremap_nopost() implementation
> > > > ? xtensa: include default ioremap_nopost() implementation
> > > > ? arm64: implement ioremap_nopost() interface
> > > > ? arm: implement ioremap_nopost() interface
> > > > ? lib: fix Devres devm_ioremap_* offset parameter kerneldoc
> > > > description
> > > > ? lib: implement Devres ioremap_nopost() interface
> > > >
> > > > ?Documentation/driver-model/devres.txt |??3 ++
> > > > ?arch/alpha/include/asm/io.h???????????|??1 +
> > > > ?arch/arc/include/asm/io.h?????????????|??1 +
> > > > ?arch/arm/include/asm/io.h?????????????|??9 ++++
> > > > ?arch/arm/mm/ioremap.c?????????????????|??7 +++
> > > > ?arch/arm/mm/nommu.c???????????????????|??9 ++++
> > > > ?arch/arm64/include/asm/io.h???????????| 12 +++++
> > > > ?arch/avr32/include/asm/io.h???????????|??1 +
> > > > ?arch/cris/include/asm/io.h????????????|??1 +
> > > > ?arch/frv/include/asm/io.h?????????????|??1 +
> > > > ?arch/hexagon/include/asm/io.h?????????|??2 +
> > > > ?arch/ia64/include/asm/io.h????????????|??1 +
> > > > ?arch/m32r/include/asm/io.h????????????|??1 +
> > > > ?arch/m68k/include/asm/io.h????????????|??1 +
> > > > ?arch/metag/include/asm/io.h???????????|??2 +
> > > > ?arch/microblaze/include/asm/io.h??????|??1 +
> > > > ?arch/mips/include/asm/io.h????????????|??1 +
> > > > ?arch/mn10300/include/asm/io.h?????????|??1 +
> > > > ?arch/nios2/include/asm/io.h???????????|??1 +
> > > > ?arch/openrisc/include/asm/io.h????????|??2 +
> > > > ?arch/parisc/include/asm/io.h??????????|??1 +
> > > > ?arch/powerpc/include/asm/io.h?????????|??1 +
> > > > ?arch/s390/include/asm/io.h????????????|??1 +
> > > > ?arch/sh/include/asm/io.h??????????????|??1 +
> > > > ?arch/sparc/include/asm/io.h???????????|??1 +
> > > > ?arch/tile/include/asm/io.h????????????|??1 +
> > > > ?arch/unicore32/include/asm/io.h???????|??1 +
> > > > ?arch/x86/include/asm/io.h?????????????|??1 +
> > > > ?arch/xtensa/include/asm/io.h??????????|??1 +
> > > > ?drivers/pci/pci.c?????????????????????|??4 +-
> > > > ?include/asm-generic/ioremap-nopost.h??|??9 ++++
> > > > ?include/asm-generic/pgtable.h?????????|??4 ++
> > > > ?include/linux/device.h????????????????|??2 +
> > > > ?include/linux/io.h????????????????????|??2 +
> > > > ?lib/devres.c??????????????????????????| 84
> > > > +++++++++++++++++++++++++++++++++--
> > > > ?35 files changed, 167 insertions(+), 5 deletions(-)
> > > > ?create mode 100644 include/asm-generic/ioremap-nopost.h
> > > >
^ permalink raw reply
* [PATCH] arm64: kernel: restrict /dev/mem read() calls to linear region
From: Ard Biesheuvel @ 2017-04-12 9:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170412092918.GX17774@n2100.armlinux.org.uk>
On 12 April 2017 at 10:29, Russell King - ARM Linux
<linux@armlinux.org.uk> wrote:
> On Wed, Apr 12, 2017 at 10:33:43AM +0200, Domenico Andreoli wrote:
>> On Wed, Apr 12, 2017 at 09:26:06AM +0100, Ard Biesheuvel wrote:
>> > When running lscpu on an AArch64 system that has SMBIOS version 2.0
>> > tables, it will segfault in the following way:
>> >
>> > Unable to handle kernel paging request at virtual address ffff8000bfff0000
>> > pgd = ffff8000f9615000
>> > [ffff8000bfff0000] *pgd=0000000000000000
>> > Internal error: Oops: 96000007 [#1] PREEMPT SMP
>> > Modules linked in:
>> > CPU: 0 PID: 1284 Comm: lscpu Not tainted 4.11.0-rc3+ #103
>> > Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015
>> > task: ffff8000fa78e800 task.stack: ffff8000f9780000
>> > PC is at __arch_copy_to_user+0x90/0x220
>> > LR is at read_mem+0xcc/0x140
>> >
>> > This is caused by the fact that lspci issues a read() on /dev/mem at the
>> > offset where it expects to find the SMBIOS structure array. However, this
>> > region is classified as EFI_RUNTIME_SERVICE_DATA (as per the UEFI spec),
>> > and so it is omitted from the linear mapping.
>> >
>> > So let's restrict /dev/mem read/write access to those areas that are
>> > covered by the linear region.
>> >
>> > Reported-by: Alexander Graf <agraf@suse.de>
>> > Fixes: 4dffbfc48d65 ("arm64/efi: mark UEFI reserved regions as MEMBLOCK_NOMAP")
>> > Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>> > ---
>> > arch/arm64/mm/mmap.c | 9 +++------
>> > 1 file changed, 3 insertions(+), 6 deletions(-)
>> >
>> > diff --git a/arch/arm64/mm/mmap.c b/arch/arm64/mm/mmap.c
>> > index 7b0d55756eb1..2956240d17d7 100644
>> > --- a/arch/arm64/mm/mmap.c
>> > +++ b/arch/arm64/mm/mmap.c
>> > @@ -18,6 +18,7 @@
>> >
>> > #include <linux/elf.h>
>> > #include <linux/fs.h>
>> > +#include <linux/memblock.h>
>> > #include <linux/mm.h>
>> > #include <linux/mman.h>
>> > #include <linux/export.h>
>> > @@ -103,12 +104,8 @@ void arch_pick_mmap_layout(struct mm_struct *mm)
>> > */
>> > int valid_phys_addr_range(phys_addr_t addr, size_t size)
>> > {
>> > - if (addr < PHYS_OFFSET)
>> > - return 0;
>> > - if (addr + size > __pa(high_memory - 1) + 1)
>> > - return 0;
>> > -
>> > - return 1;
>> > + return memblock_is_map_memory(addr) &&
>> > + memblock_is_map_memory(addr + size - 1);
>> > }
>> >
>> > /*
>>
>> Does arch/arm/mm/mmap.c need the same treatment?
>
> high_memory is supposed to be the virtual address of the end of the
> linearly mapped region. ARM conforms to that.
>
Yes, but with UEFI boot, there will be holes in the linear region.
This is due to the fact that those regions may have special
significance to the firmware, and may be mapped with mismatched
attributes.
As it happens, the UEFI spec recommends that SMBIOS tables (which only
have significance to the OS) are covered by a EFI_RUNTIME_SERVICE_DATA
region, which is one of the types we mark MEMBLOCK_NOMAP, and omit
from the linear region.
So when lspcu goes looking for the SMBIOS tables, using the read()
interface to /dev/mem, it will dereference a physical pointer into an
unmapped region. This will undoubtedly produce a similar result to the
above if we don't account for NOMAP regions.
However, we have no DMI/SMBIOS support yet for ARM (nor ACPI support),
so this particular issue does not exist on ARM atm. But read() calls
to /dev/mem may indeed provoke a similar splat when (ab)used in a
similar manner.
--
Ard.
^ permalink raw reply
* [PATCH v2 1/5] dt-bindings: gpu: add bindings for the ARM Mali Midgard GPU
From: Guillaume Tucker @ 2017-04-12 9:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e8ff3ab8-3bf8-d731-a987-3bb8442cfc0a@baylibre.com>
Hi Neil,
On 12/04/17 09:48, Neil Armstrong wrote:
> Hi Guillaume,
>
> On 04/12/2017 10:25 AM, Guillaume Tucker wrote:
>> Hi Heiko,
>>
>> On 11/04/17 21:52, Heiko St?bner wrote:
>>> Hi Guillaume,
>>>
>>> Am Dienstag, 11. April 2017, 18:40:37 CEST schrieb Guillaume Tucker:
>>>> On 03/04/17 09:12, Neil Armstrong wrote:
>>>>> On 04/02/2017 09:59 AM, Guillaume Tucker wrote:
>>>>>> +Optional:
>>>>>> +
>>>>>> +- clocks : Phandle to clock for the Mali Midgard device.
>>>>>> +- clock-names : Shall be "clk_mali".
>>>>>> +- mali-supply : Phandle to regulator for the Mali device. Refer to
>>>>>> + Documentation/devicetree/bindings/regulator/regulator.txt for details.
>>>>>> +- operating-points : Refer to
>>>>>> Documentation/devicetree/bindings/power/opp.txt + for details.
>>>>>
>>>>> Please add :
>>>>> * Must be one of the following:
>>>>> "arm,mali-t820"
>>>>>
>>>>> * And, optionally, one of the vendor specific compatible:
>>>>> "amlogic,meson-gxm-mali"
>>>>>
>>>>> with my Ack for the amlogic platform.
>>>>
>>>> It seems to me that as long as the GPU architecture hasn't been
>>>> modified (I don't think I've ever encountered such a case) then
>>>> it has to be a standard ARM Mali type regardless of the SoC
>>>> vendor. So unless a Mali-T820 in the Amlogic S912 SoC is not the
>>>> same as a T820 in a different SoC, please forgive me but I don't
>>>> understand why a vendor compatible string is needed. My main
>>>> concern is that it's going to be very hard to keep that list
>>>> up-to-date with all existing Midgard SoC variants. If do we need
>>>> to add vendor compatible strings to correctly describe the
>>>> hardware then I'm happy to add the amlogic one in my patch v3; I
>>>> would just like to understand why that's necessary.
>>>
>>> SoC vendors in most cases hook ip blocks into their socs in different
>>> and often strange ways. After all it's not some discrete ic you solder
>>> onto a board, but instead a part of the soc itself.
>>
>> Thanks for your explanation. I see, it's really about special
>> things that are not supported by the standard Midgard kernel
>> driver.
>>
>>> So in most cases you will have some hooks outside the actual gpu iospace
>>> that can be used to tune different things about how the gpu interacts with
>>> the system. Which is probably also the reason the midgard kernel driver
>>> has this ugly "platform" subdirectory for compile-time platform selection.
>>
>> I see the "platform" directory approach as an old and deprecated
>> way of supporting platforms, upstreaming the dt bindings goes in
>> the direction of using solely the device tree to describe the GPU
>> hardware (i.e. CONFIG_MALI_PLATFORM_DEVICETREE). If something
>> quirky is needed in the platform, it should be possible to
>> support it outside the GPU driver (platform devfreq etc...).
>
> If this was so simple...
>
> This is why the "vendor" compatible is optional.
>
> And on another side, the binding were written by ARM, are may not be
> compatible with how the mainline Linux handles these uses-cases.
>
> ARM added some tweaks to handle some weird integration using DT properties,
> but this should definitely go in platform specific code instead.
OK, sorry I was approaching the issue from a completely different
and somewhat more idealistic angle. My impression is that if the
driver was in mainline then it would be maintained in such a way
that vendor compatible strings would not be required, but this is
all hypothetical.
So in practice, I think I now better understand why vendor
compatible strings may still be needed. And they're optional, so
harmless to other platforms, so it's all fine with me :)
>> Back to the original intent of enabling distros to make Mali GPU
>> driver packages, when using the device tree you can have a single
>> kernel driver package for all Midgard platforms. When using the
>> third-party platform sources approach, you need to make an extra
>> package for each one of them.
>
> Well, if the midgard driver was maintained in community-driven way, all vendor
> could actually push their platform code, but it's not the case and somehow
> never will.
>
>>
>> So if there is value in supporting platforms that absolutely
>> require something special due to their hardware GPU integration,
>> then yes I see why vendor dt bindings might be useful. However
>> it seems to me that this should really be an exception and
>> avoided whenever possible.
>
> I understand you would avoid changing the (horrible) way the midgard
> driver handles the DT...
>
> But ultimately, if we consider the eventual integration of the midgard
> driver in mainline kernel (because why not ?), the driver would need
> a complete re-write to conform the actual driver coding structure,
> and so would also need to conform to the DT mainline rules.
Yes, it's hard to have a discussion without a mainline driver to
back things up. So I understand the pragmatic approach here.
>>> On my rk3288 for example we have [0] in the chromeos tree, that handles
>>> the oddities of the midgard on the rk3288 used in a lot of Chromebooks.
>>> There are soc-specific oddities of frequencies, frequency-scaling and
>>> whatnot. And there are also more gpu-specific setting in syscon areas
>>> of the soc (pmu and grf) that can also influence the gpus performance
>>> and might need tweaking at some point.
>>
>> For the rk3288, this is purely a software implementation issue on
>> the chromeos-3.14 branch. With mainline kernel, you can use
>> devfreq and no platform files at all (that's how I tested these
>> dt bindings). So as far as I know, there's no need for a vendor
>> compatible string on rk3288.
>>
>>> That doesn't even take into account that there may even be differences
>>> on how things are synthesized that we don't know about. See all the
>>> variants of the dw_hdmi ip block (imx, rockchip, meson [more?]) .
>>
>> I'm not too familiar with that driver, just had a quick look and
>> it seems to be a different issue as there's a kernel config for
>> each platform to build separate driver modules. And it looks
>> like they are actually needed to cope with variants of the
>> hardware inside the display processor block, unlike with the Mali
>> GPU which in principle should always be the same. I've run this
>> Midgard driver without any platform files and using devfreq at
>> least on rk3288 Firefly, Exynos 5422 ODROID-XU3 and Juno and they
>> all have a vanilla Mali GPU hw block. It's just wired
>> differently in each SoC.
>
> Please, do not consider the "driver" in dt-bindings discussion, the
> way it's implemented is irrelevant here, but the way the IP is
> integrated is crucial.
> And trust me, HW designers and integrators are very very creative
> guys, and we *need* some platform code to handle integration corner
> cases not handled by the "IP" driver.
Sure, I know this happens... I can't help but think that if
something quirky is done in the SoC around the GPU then it
shouldn't need to be fixed in the GPU driver. But that's talking
about the "driver" again, so not relevant.
> In the case of "dw-hdmi", the "driver" acts like a "library" that
> can be used differently among the various platforms.
>
> I can talk about the "meson" Amlogic integration, in this particular
> case Amlogic used their owm PHY and wrapped all the stuff in a way
> we need to handle the PHY+HDMI+Wrapper in a single block and then
> connect it to the Video pipeline.
>
> For the midgard integration made by Amlogic, the vendor platform code
> uses tweaks to start the IP and initialize the clocks.
> And this code is part of the "amlogic,meson-gxm-mali" HW, not the
> "arm,midgard".
Can't this be done in the clock driver or some other early init
stage of the SoC? But again, that code is not in mainline so
it's a non-issue.
>>> So we really want to have the special compatibles in place, to be prepared
>>> for the future per-soc oddities that always appear :-) .
>>
>> How about aiming for the ideal case where vendor-specific things
>> are not needed and add them if and when they really become
>> inevitable and worth the cost?
>
> Trust me, an amlogic compatible is needed ;-)
Fair enough, will add the optional vendor compatible string in my
patch v3 :) Glad this was discussed though, thank you.
Guillaume
>>> [0] https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.14/drivers/gpu/arm/midgard/platform/rk/
^ permalink raw reply
* [PATCH] arm64: kernel: restrict /dev/mem read() calls to linear region
From: Russell King - ARM Linux @ 2017-04-12 9:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170412083342.GA6957@localhost>
On Wed, Apr 12, 2017 at 10:33:43AM +0200, Domenico Andreoli wrote:
> On Wed, Apr 12, 2017 at 09:26:06AM +0100, Ard Biesheuvel wrote:
> > When running lscpu on an AArch64 system that has SMBIOS version 2.0
> > tables, it will segfault in the following way:
> >
> > Unable to handle kernel paging request at virtual address ffff8000bfff0000
> > pgd = ffff8000f9615000
> > [ffff8000bfff0000] *pgd=0000000000000000
> > Internal error: Oops: 96000007 [#1] PREEMPT SMP
> > Modules linked in:
> > CPU: 0 PID: 1284 Comm: lscpu Not tainted 4.11.0-rc3+ #103
> > Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015
> > task: ffff8000fa78e800 task.stack: ffff8000f9780000
> > PC is at __arch_copy_to_user+0x90/0x220
> > LR is at read_mem+0xcc/0x140
> >
> > This is caused by the fact that lspci issues a read() on /dev/mem at the
> > offset where it expects to find the SMBIOS structure array. However, this
> > region is classified as EFI_RUNTIME_SERVICE_DATA (as per the UEFI spec),
> > and so it is omitted from the linear mapping.
> >
> > So let's restrict /dev/mem read/write access to those areas that are
> > covered by the linear region.
> >
> > Reported-by: Alexander Graf <agraf@suse.de>
> > Fixes: 4dffbfc48d65 ("arm64/efi: mark UEFI reserved regions as MEMBLOCK_NOMAP")
> > Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> > ---
> > arch/arm64/mm/mmap.c | 9 +++------
> > 1 file changed, 3 insertions(+), 6 deletions(-)
> >
> > diff --git a/arch/arm64/mm/mmap.c b/arch/arm64/mm/mmap.c
> > index 7b0d55756eb1..2956240d17d7 100644
> > --- a/arch/arm64/mm/mmap.c
> > +++ b/arch/arm64/mm/mmap.c
> > @@ -18,6 +18,7 @@
> >
> > #include <linux/elf.h>
> > #include <linux/fs.h>
> > +#include <linux/memblock.h>
> > #include <linux/mm.h>
> > #include <linux/mman.h>
> > #include <linux/export.h>
> > @@ -103,12 +104,8 @@ void arch_pick_mmap_layout(struct mm_struct *mm)
> > */
> > int valid_phys_addr_range(phys_addr_t addr, size_t size)
> > {
> > - if (addr < PHYS_OFFSET)
> > - return 0;
> > - if (addr + size > __pa(high_memory - 1) + 1)
> > - return 0;
> > -
> > - return 1;
> > + return memblock_is_map_memory(addr) &&
> > + memblock_is_map_memory(addr + size - 1);
> > }
> >
> > /*
>
> Does arch/arm/mm/mmap.c need the same treatment?
high_memory is supposed to be the virtual address of the end of the
linearly mapped region. ARM conforms to that.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [GIT PULL] arm64: fixes for -rc6
From: Will Deacon @ 2017-04-12 9:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3b32cfd3-7675-005b-a737-58a8677f65ac@redhat.com>
Hi Jon,
On Tue, Apr 11, 2017 at 03:12:57PM -0400, Jon Masters wrote:
> On 04/07/2017 12:02 PM, Will Deacon wrote:
>
> > Please pull these two arm64 fixes for -rc6. We've got a regression fix for
> > the signal raised when userspace makes an unsupported unaligned access and a
> > revert of the contiguous (hugepte) support for hugetlb, which has once again
> > been found to be broken. One day, maybe, we'll get it right.
>
> <snip>
>
> > - Revert broken support for the contiguous bit in hugetlb (again...)
>
> Quick aside: is this being worked on for 4.12? If not, should we ping
> Linaro and look to get some focus on this? It's right to disable this,
> but also painful to those wanting to work on various NFV use cases.
I think Punit and Steve (CC'd) are working on this, but the issues run
beyond the lack of break-before-make. The core GUP code, for example,
doesn't even support hugeptes. There are also dormant issues with hugeptes
and swap/migration entries, which would hit if somebody flipped
CONFIG_ARCH_ENABLE_HUGEPAGE_MIGRATION. Hell, even the pte_huge macro is
bogus if you're using contiguous ptes (granted, it's seldom used, but if
the above are fixed maybe it will be).
Will
^ permalink raw reply
* [PATCH v5 0/4] gpio: mvebu: Add PWM fan support
From: Gregory CLEMENT @ 2017-04-12 9:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170409180931.4884-1-ralph.sennhauser@gmail.com>
Hi all,
On dim., avril 09 2017, Ralph Sennhauser <ralph.sennhauser@gmail.com> wrote:
> Hi Therry,
>
> Resending this as v5 with some minor changes since v4. What is missing is
> an ACK from you so Linus can merge the driver and Gregory the dts
> changes. For this driver to make it into 4.12 it would be nice to have
> it in next soon. I hope you can make some room in your schedule to have
> another look at this series.
If the other maintainer agree I can apply the arm-soc related patch (2,
3 and 4) to my mvebu branches. Actually even if the gpio driver is not
merged yet, these patches won't hurt. The only things I would like to
check is that the binding won't change.
Thanks,
Gregory
>
> Thanks
> Ralph
>
> ---
>
> Notes:
>
> About npwm = 1:
> The only way I can think of to achieve that requires reading the
> GPIO line from the device tree. This would prevent a user to
> dynamically choose a line. Which is fine for the fan found on Mamba
> but let's take some development board with freely accessible GPIOs
> and suddenly we limit the use of this driver. Given the above, npwm
> = ngpio with only one usable at a time is a more accurate
> description of the situation. The only downside is some "wasted"
> space.
>
> About the new compatible string:
> Orion was chosen for the SoC variant for the same reason as in
> commit 5f79c651e81e ("arm: mvebu: use global interrupts for GPIOs on
> Armada XP").
> The "pwm" property remains optional for the new compatible string so
> the compatiple string "marvell,armada-370-xp-gpio" can be used by
> all and not just the first two GPIO chips. A property to select "Set
> A" / "Set B" registers could be invented though.
>
> ---
>
> Pending:
> * Needs ACK from Thierry Reding to be merged via linux-gpio tree by Linus
> Walleij. (fine with the general approach, requested changes which
> should have been taken care of now)
>
> ---
>
> Changes v4->v5:
> All
> * add Tested-by: Andrew Lunn <andrew@lunn.ch>, thanks
> Patch 2/4 mvebu: xp: Add PWM properties to .dtsi files
> * keep the old compatible stings, we don't have to drop them,
> therefore keep them (suggested by Gregory CLEMENT)
> * subject starts with ARM: dts: mvebu: (suggested by Gregory CLEMENT)
> Patch 4/4 mvebu: wrt1900ac: Use pwm-fan rather than gpio-fan
> * subject starts with ARM: dts: armada-xp: (suggested by Gregory CLEMENT)
>
> Changes v3->v4:
> Patch 1/4 gpio: mvebu: Add limited PWM support:
> * braces for both branches in if statement if one needs it. (suggested
> by Andrew Lunn)
> * introduce compatible string marvell,armada-370-xp-gpio (suggest by
> Rob Herring)
> * fix mvebu_pwmreg_blink_on_duration -> mvebu_pwmreg_blink_off_duration
> for period callculation in mvebu_pwm_get_state()
> Patch 4/4 mvebu: wrt1900ac: Use pwm-fan rather than gpio-fan
> * Drop flags from pwms for Mamba, as no longer used (suggested by
> Andrew Lunn)
> * Use again #pwm-cell = 2, the second cell is actually the period.
>
> Changes v2->v3:
> Patch 1/4 gpio: mvebu: Add limited PWM support:
> * drop pin from mvebu_pwn, can be infered (suggested by Thierry Reding)
> * rename pwm to mvpwm so pwm can be used for pwm_device as in the API,
> avoids some mental gymnastic.
> * drop id from struct mvebu_gpio_chip, select blink counter in
> mvebu_pwm_probe for all lines instead. We do not care about the
> unused ones. I think a clear improvement in readability.
> Makes coming up with a good comment simple as well.
> * Switch to new atomic PWM API (suggested by Thierry Reding)
> * rename use mvebu_gpioreg_blink_select to
> mvebu_gpioreg_blink_counter_select.
> * mark *_suspend() / *_resume() as __maybe_unused (suggested by Linus
> Walleij)
> * document #pwm-cells = 1 (suggested by Thierry Reding)
> Patch 2/4 mvebu: xp: Add PWM properties to .dtsi files
> * add missing reg-names / #pwm-cell properties to
> armada-xp-mv78260.dtsi gpio1 node
> * set pwm-cells = 1 (suggested by Thierry Reding)
> All:
> * always uppercase GPIO/PWM in prose (suggested by Thierry Reding)
>
> Changes v1 -> v2:
> Patch 1/4 gpio: mvebu: Add limited PWM support:
> * use BIT macro (suggested by Linus Walleij)
> * move id from struct mvebu_pwm to struct mvebu_gpio_chip, implement
> blink select as if else and comment on the chip id for code clarity
> (to accommodate Linus Walleijs request for a code clarification /
> comment. If you can word it better I'm all ears.)
> * Move function comment mvebu_pwm_probe into the function itself.
>
> ---
>
> Andrew Lunn (4):
> gpio: mvebu: Add limited PWM support
> ARM: dts: mvebu: Add PWM properties to .dtsi files
> ARM: mvebu: Enable SENSORS_PWM_FAN in defconfig
> ARM: dts: armada-xp: Use pwm-fan rather than gpio-fan
>
> .../devicetree/bindings/gpio/gpio-mvebu.txt | 32 ++
> MAINTAINERS | 2 +
> arch/arm/boot/dts/armada-370.dtsi | 19 +-
> arch/arm/boot/dts/armada-xp-linksys-mamba.dts | 8 +-
> arch/arm/boot/dts/armada-xp-mv78230.dtsi | 16 +-
> arch/arm/boot/dts/armada-xp-mv78260.dtsi | 19 +-
> arch/arm/boot/dts/armada-xp-mv78460.dtsi | 19 +-
> arch/arm/configs/mvebu_v7_defconfig | 2 +
> drivers/gpio/gpio-mvebu.c | 324 ++++++++++++++++++++-
> 9 files changed, 405 insertions(+), 36 deletions(-)
>
> --
> 2.10.2
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH v6 17/39] platform: add video-multiplexer subdevice driver
From: Sakari Ailus @ 2017-04-12 9:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e7368555-1644-4e8f-f355-6b07dc020f90@gmail.com>
Hi Steve,
On Tue, Apr 11, 2017 at 05:50:58PM -0700, Steve Longerbeam wrote:
>
>
> On 04/04/2017 05:47 AM, Sakari Ailus wrote:
> >Hi Steve, Philipp and Pavel,
> >
> >On Mon, Mar 27, 2017 at 05:40:34PM -0700, Steve Longerbeam wrote:
> >>From: Philipp Zabel <p.zabel@pengutronix.de>
> >>
> >>This driver can handle SoC internal and external video bus multiplexers,
> >>controlled either by register bit fields or by a GPIO. The subdevice
> >>passes through frame interval and mbus configuration of the active input
> >>to the output side.
> >
> >The MUX framework is already in linux-next. Could you use that instead of
> >adding new driver + bindings that are not compliant with the MUX framework?
> >I don't think it'd be much of a change in terms of code, using the MUX
> >framework appears quite simple.
>
> I would prefer to wait on this, and get what we have merged now so I can
> unload all these patches first.
The DT bindings will be different for this one and if you were using a MUX,
won't they? And you can't remove support for the existing bindings either,
you have to continue to support them going forward.
>
> Also this is Philipp's driver, so again I would prefer to get this
> merged as-is and then Philipp can address these issues in a future
> patch. But I will add my comments below...
I bet there will be more issues to handle if you were to do the changes
later than now.
...
> >>+static int vidsw_s_stream(struct v4l2_subdev *sd, int enable)
> >>+{
> >>+ struct vidsw *vidsw = v4l2_subdev_to_vidsw(sd);
> >>+ struct v4l2_subdev *upstream_sd;
> >>+ struct media_pad *pad;
> >>+
> >>+ if (vidsw->active == -1) {
> >>+ dev_err(sd->dev, "Can not start streaming on inactive mux\n");
> >>+ return -EINVAL;
> >>+ }
> >>+
> >>+ pad = media_entity_remote_pad(&sd->entity.pads[vidsw->active]);
> >>+ if (!pad) {
> >>+ dev_err(sd->dev, "Failed to find remote source pad\n");
> >>+ return -ENOLINK;
> >>+ }
> >>+
> >>+ if (!is_media_entity_v4l2_subdev(pad->entity)) {
> >>+ dev_err(sd->dev, "Upstream entity is not a v4l2 subdev\n");
> >>+ return -ENODEV;
> >>+ }
> >>+
> >>+ upstream_sd = media_entity_to_v4l2_subdev(pad->entity);
> >>+
> >>+ return v4l2_subdev_call(upstream_sd, video, s_stream, enable);
> >
> >Now that we'll have more than two drivers involved in the same pipeline it
> >becomes necessary to define the behaviour of s_stream() throughout the
> >pipeline --- i.e. whose responsibility is it to call s_stream() on the
> >sub-devices in the pipeline?
>
> In the case of imx-media, the capture device calls set stream on the
> whole pipeline in the start_streaming() callback. This subdev call is
> actually a NOOP for imx-media, because the upstream entity has already
> started streaming. Again I think this should be removed. It also
> enforces a stream order that some MC drivers may have a problem with.
What I want to say here is that the order in which the different devices in
the pipeline need to be started may not be known in a driver for a
particular part of the pipeline.
In order to avoid trying to have a single point of decision making, the
s_stream() op implemented in sub-device drivers should serve the purpose.
I'll cc you for the documentation patch.
--
Kind regards,
Sakari Ailus
e-mail: sakari.ailus at iki.fi XMPP: sailus at retiisi.org.uk
^ permalink raw reply
* [PATCH v2] ARM: dts: armada-38x: label USB and SATA nodes
From: Gregory CLEMENT @ 2017-04-12 9:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170408101626.14032-1-ralph.sennhauser@gmail.com>
Hi Ralph,
On sam., avril 08 2017, Ralph Sennhauser <ralph.sennhauser@gmail.com> wrote:
> Recently most nodes got labels to make them referenceable. The USB 3.0
> nodes as well as the nodes for the SATA controllers were left out,
> rectify the omission.
>
> The labels "sataX" are already used by some boards for the SATA ports,
> therefore use "ahciX" to label the SATA controller nodes.
>
> To avoid potential confusion by labeling an USB3.0 controller "usb2" use
> usb3_X as labels. This also coincides with the node names themselves
> (usb at xxxxx vs usb3 at xxxxx).
>
> Signed-off-by: Ralph Sennhauser <ralph.sennhauser@gmail.com>
Applied on mvebu/dt
Thanks,
Gregory
> ---
>
> Hi everybody,
>
> Using satacX for controllers with satacXpY for ports might have been a
> possiblity, since ahciX is already used similarly (to avoid a conflict
> with current use of sataX) ahciX seems the better choice. Works well me
> thinks.
>
> The usb3_X labels still seem the best choice even though they aren't
> perfectly consitent, however, I don't see an alternative which would fit
> this requirement either.
>
> Regards
> Ralph
>
> ---
>
> Changes v1 -> v2:
> * use ahciX instead of satacX for the SATA controller nodes (suggested
> by Andrew Lunn)
>
>
> arch/arm/boot/dts/armada-38x.dtsi | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/boot/dts/armada-38x.dtsi b/arch/arm/boot/dts/armada-38x.dtsi
> index ba27ec1..8b165c3 100644
> --- a/arch/arm/boot/dts/armada-38x.dtsi
> +++ b/arch/arm/boot/dts/armada-38x.dtsi
> @@ -530,7 +530,7 @@
> interrupts = <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
> };
>
> - sata at a8000 {
> + ahci0: sata at a8000 {
> compatible = "marvell,armada-380-ahci";
> reg = <0xa8000 0x2000>;
> interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>;
> @@ -546,7 +546,7 @@
> status = "disabled";
> };
>
> - sata at e0000 {
> + ahci1: sata at e0000 {
> compatible = "marvell,armada-380-ahci";
> reg = <0xe0000 0x2000>;
> interrupts = <GIC_SPI 28 IRQ_TYPE_LEVEL_HIGH>;
> @@ -590,7 +590,7 @@
> status = "disabled";
> };
>
> - usb3 at f0000 {
> + usb3_0: usb3 at f0000 {
> compatible = "marvell,armada-380-xhci";
> reg = <0xf0000 0x4000>,<0xf4000 0x4000>;
> interrupts = <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>;
> @@ -598,7 +598,7 @@
> status = "disabled";
> };
>
> - usb3 at f8000 {
> + usb3_1: usb3 at f8000 {
> compatible = "marvell,armada-380-xhci";
> reg = <0xf8000 0x4000>,<0xfc000 0x4000>;
> interrupts = <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>;
> --
> 2.10.2
>
--
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] gpio: Allow hogged gpios to be requested
From: Oleksij Rempel @ 2017-04-12 8:59 UTC (permalink / raw)
To: linux-arm-kernel
Hallo all,
i need to take over the work on this patch set and need to know if it
still upstreamable:
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-August/364227.html
--
Regards,
Oleksij
^ permalink raw reply
* [PATCH 4/7] arm64: marvell: dts: add crypto engine description for 7k/8k
From: Thomas Petazzoni @ 2017-04-12 8:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170329124432.27457-5-antoine.tenart@free-electrons.com>
Hello,
On Wed, 29 Mar 2017 14:44:29 +0200, Antoine Tenart wrote:
> + cpm_crypto: crypto at 800000 {
> + compatible = "inside-secure,safexcel-eip197";
> + reg = <0x800000 0x200000>;
> + interrupts = <GIC_SPI 34 (IRQ_TYPE_EDGE_RISING | IRQ_TYPE_LEVEL_HIGH)>,
Now that I look into this, does it makes sense for an interrupt to be
both an edge interrupt and a level interrupt at the same time? This
looks odd.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH v2 1/5] dt-bindings: gpu: add bindings for the ARM Mali Midgard GPU
From: Neil Armstrong @ 2017-04-12 8:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7a875b2d-f288-8136-de04-11e744f0118b@collabora.com>
Hi Guillaume,
On 04/12/2017 10:25 AM, Guillaume Tucker wrote:
> Hi Heiko,
>
> On 11/04/17 21:52, Heiko St?bner wrote:
>> Hi Guillaume,
>>
>> Am Dienstag, 11. April 2017, 18:40:37 CEST schrieb Guillaume Tucker:
>>> On 03/04/17 09:12, Neil Armstrong wrote:
>>>> On 04/02/2017 09:59 AM, Guillaume Tucker wrote:
>>>>> +Optional:
>>>>> +
>>>>> +- clocks : Phandle to clock for the Mali Midgard device.
>>>>> +- clock-names : Shall be "clk_mali".
>>>>> +- mali-supply : Phandle to regulator for the Mali device. Refer to
>>>>> + Documentation/devicetree/bindings/regulator/regulator.txt for details.
>>>>> +- operating-points : Refer to
>>>>> Documentation/devicetree/bindings/power/opp.txt + for details.
>>>>
>>>> Please add :
>>>> * Must be one of the following:
>>>> "arm,mali-t820"
>>>>
>>>> * And, optionally, one of the vendor specific compatible:
>>>> "amlogic,meson-gxm-mali"
>>>>
>>>> with my Ack for the amlogic platform.
>>>
>>> It seems to me that as long as the GPU architecture hasn't been
>>> modified (I don't think I've ever encountered such a case) then
>>> it has to be a standard ARM Mali type regardless of the SoC
>>> vendor. So unless a Mali-T820 in the Amlogic S912 SoC is not the
>>> same as a T820 in a different SoC, please forgive me but I don't
>>> understand why a vendor compatible string is needed. My main
>>> concern is that it's going to be very hard to keep that list
>>> up-to-date with all existing Midgard SoC variants. If do we need
>>> to add vendor compatible strings to correctly describe the
>>> hardware then I'm happy to add the amlogic one in my patch v3; I
>>> would just like to understand why that's necessary.
>>
>> SoC vendors in most cases hook ip blocks into their socs in different
>> and often strange ways. After all it's not some discrete ic you solder
>> onto a board, but instead a part of the soc itself.
>
> Thanks for your explanation. I see, it's really about special
> things that are not supported by the standard Midgard kernel
> driver.
>
>> So in most cases you will have some hooks outside the actual gpu iospace
>> that can be used to tune different things about how the gpu interacts with
>> the system. Which is probably also the reason the midgard kernel driver
>> has this ugly "platform" subdirectory for compile-time platform selection.
>
> I see the "platform" directory approach as an old and deprecated
> way of supporting platforms, upstreaming the dt bindings goes in
> the direction of using solely the device tree to describe the GPU
> hardware (i.e. CONFIG_MALI_PLATFORM_DEVICETREE). If something
> quirky is needed in the platform, it should be possible to
> support it outside the GPU driver (platform devfreq etc...).
If this was so simple...
This is why the "vendor" compatible is optional.
And on another side, the binding were written by ARM, are may not be
compatible with how the mainline Linux handles these uses-cases.
ARM added some tweaks to handle some weird integration using DT properties,
but this should definitely go in platform specific code instead.
>
> Back to the original intent of enabling distros to make Mali GPU
> driver packages, when using the device tree you can have a single
> kernel driver package for all Midgard platforms. When using the
> third-party platform sources approach, you need to make an extra
> package for each one of them.
Well, if the midgard driver was maintained in community-driven way, all vendor
could actually push their platform code, but it's not the case and somehow
never will.
>
> So if there is value in supporting platforms that absolutely
> require something special due to their hardware GPU integration,
> then yes I see why vendor dt bindings might be useful. However
> it seems to me that this should really be an exception and
> avoided whenever possible.
I understand you would avoid changing the (horrible) way the midgard
driver handles the DT...
But ultimately, if we consider the eventual integration of the midgard
driver in mainline kernel (because why not ?), the driver would need
a complete re-write to conform the actual driver coding structure,
and so would also need to conform to the DT mainline rules.
>
>> On my rk3288 for example we have [0] in the chromeos tree, that handles
>> the oddities of the midgard on the rk3288 used in a lot of Chromebooks.
>> There are soc-specific oddities of frequencies, frequency-scaling and
>> whatnot. And there are also more gpu-specific setting in syscon areas
>> of the soc (pmu and grf) that can also influence the gpus performance
>> and might need tweaking at some point.
>
> For the rk3288, this is purely a software implementation issue on
> the chromeos-3.14 branch. With mainline kernel, you can use
> devfreq and no platform files at all (that's how I tested these
> dt bindings). So as far as I know, there's no need for a vendor
> compatible string on rk3288.
>
>> That doesn't even take into account that there may even be differences
>> on how things are synthesized that we don't know about. See all the
>> variants of the dw_hdmi ip block (imx, rockchip, meson [more?]) .
>
> I'm not too familiar with that driver, just had a quick look and
> it seems to be a different issue as there's a kernel config for
> each platform to build separate driver modules. And it looks
> like they are actually needed to cope with variants of the
> hardware inside the display processor block, unlike with the Mali
> GPU which in principle should always be the same. I've run this
> Midgard driver without any platform files and using devfreq at
> least on rk3288 Firefly, Exynos 5422 ODROID-XU3 and Juno and they
> all have a vanilla Mali GPU hw block. It's just wired
> differently in each SoC.
Please, do not consider the "driver" in dt-bindings discussion, the
way it's implemented is irrelevant here, but the way the IP is
integrated is crucial.
And trust me, HW designers and integrators are very very creative
guys, and we *need* some platform code to handle integration corner
cases not handled by the "IP" driver.
In the case of "dw-hdmi", the "driver" acts like a "library" that
can be used differently among the various platforms.
I can talk about the "meson" Amlogic integration, in this particular
case Amlogic used their owm PHY and wrapped all the stuff in a way
we need to handle the PHY+HDMI+Wrapper in a single block and then
connect it to the Video pipeline.
For the midgard integration made by Amlogic, the vendor platform code
uses tweaks to start the IP and initialize the clocks.
And this code is part of the "amlogic,meson-gxm-mali" HW, not the
"arm,midgard".
>
>> So we really want to have the special compatibles in place, to be prepared
>> for the future per-soc oddities that always appear :-) .
>
> How about aiming for the ideal case where vendor-specific things
> are not needed and add them if and when they really become
> inevitable and worth the cost?
Trust me, an amlogic compatible is needed ;-)
Neil
>
> Thanks,
> Guillaume
>
>> [0] https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.14/drivers/gpu/arm/midgard/platform/rk/
>
^ permalink raw reply
* [GIT PULL] DaVinci SoC updates for v4.12 (part 3)
From: Sekhar Nori @ 2017-04-12 8:44 UTC (permalink / raw)
To: linux-arm-kernel
The following changes since commit 28d4d1d0e49b4ac4d12861a64f45101f36fbfab8:
ARM: davinci: add pata_bk3710 libata driver support (2017-03-30 16:15:29 +0530)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git tags/davinci-for-v4.12/soc-3
for you to fetch changes up to 398dbc776a8f7dfdee7c38ad003e66abd31b3b0a:
ARM: davinci: Add clock for CPPI 4.1 DMA engine (2017-04-11 19:50:53 +0530)
----------------------------------------------------------------
Add clock for CPPI 4.1 DMA engine thats
part of USB OTG subsystem on DA830 and
DA850.
This builds on top of the pull request
sent earlier:
https://www.spinics.net/lists/arm-kernel/msg573985.html
----------------------------------------------------------------
Alexandre Bailon (1):
ARM: davinci: Add clock for CPPI 4.1 DMA engine
arch/arm/mach-davinci/da830.c | 6 ++++++
arch/arm/mach-davinci/da850.c | 6 ++++++
2 files changed, 12 insertions(+)
^ permalink raw reply
* [RFC PATCH 5/7] iommu/arm-smmu-v3: For ACPI based device probing, set relevant options for different SMMUv3 implementations.
From: Robert Richter @ 2017-04-12 8:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1491921765-29475-6-git-send-email-linucherian@gmail.com>
Linu,
On 11.04.17 20:12:43, linucherian at gmail.com wrote:
> From: Linu Cherian <linu.cherian@cavium.com>
>
> Enable SKIP_PREFETCH option for HiSilicon SMMUv3 model.
> Enable PAGE0_REGS_ONLY and USE_SHARED_IRQS options for
> Cavium 99xx SMMUv3 model.
>
> Signed-off-by: Linu Cherian <linu.cherian@cavium.com>
> ---
> drivers/iommu/arm-smmu-v3.c | 27 +++++++++++++++++++++++++++
> 1 file changed, 27 insertions(+)
>
> diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
> index 1475ad8..00b48b4 100644
> --- a/drivers/iommu/arm-smmu-v3.c
> +++ b/drivers/iommu/arm-smmu-v3.c
> @@ -2634,18 +2634,45 @@ static int arm_smmu_device_hw_probe(struct arm_smmu_device *smmu)
> }
>
> #ifdef CONFIG_ACPI
> +static int acpi_smmu_get_options(u32 model, struct arm_smmu_device *smmu)
> +{
> + int ret = 0;
> +
> + switch (model) {
> + case ACPI_IORT_SMMU_V3:
> + case ACPI_IORT_SMMU_CORELINK_MMU600:
> + break;
> + case ACPI_IORT_SMMU_V3_HISILICON:
> + smmu->options |= ARM_SMMU_OPT_SKIP_PREFETCH;
> + break;
> + case ACPI_IORT_SMMU_V3_CAVIUM_CN99XX:
> + smmu->options |= (ARM_SMMU_OPT_PAGE0_REGS_ONLY |
> + ARM_SMMU_OPT_USE_SHARED_IRQS);
> + break;
> + default:
> + ret = -ENODEV;
> + }
> +
> + return ret;
> +}
> +
> static int arm_smmu_device_acpi_probe(struct platform_device *pdev,
> struct arm_smmu_device *smmu)
> {
> struct acpi_iort_smmu_v3 *iort_smmu;
> struct device *dev = smmu->dev;
> struct acpi_iort_node *node;
> + int ret;
>
> node = *(struct acpi_iort_node **)dev_get_platdata(dev);
>
> /* Retrieve SMMUv3 specific data */
> iort_smmu = (struct acpi_iort_smmu_v3 *)node->node_data;
>
> + ret = acpi_smmu_get_options(iort_smmu->model, smmu);
> + if (ret < 0)
> + return ret;
> +
could we add at least:
dev_notice(smmu->dev, "option mask 0x%x\n", smmu->options);
We need a note to see which options have been enabled.
It could be even more fancy and maybe unified with DT code to see the
same messages for DT and ACPI.
Thanks,
-Robert
> if (iort_smmu->flags & ACPI_IORT_SMMU_V3_COHACC_OVERRIDE)
> smmu->features |= ARM_SMMU_FEAT_COHERENCY;
>
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" 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 7/7] arm64: defconfig: enable the Safexcel crypto engine as a module
From: Gregory CLEMENT @ 2017-04-12 8:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170329124432.27457-8-antoine.tenart@free-electrons.com>
Hi Antoine,
On mer., mars 29 2017, Antoine Tenart <antoine.tenart@free-electrons.com> wrote:
> The Safexcel EIP197 cryptographic engine is used on some Marvell SoCs,
> such as Armada 7040 and Armada 8040. Enable this driver as a module in
> the ARM64 defconfig.
>
> Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
Applied on mvebu/defconfig64
Thanks,
Gregory
> ---
> arch/arm64/configs/defconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
> index fece4d3c2095..76308fa2fa7a 100644
> --- a/arch/arm64/configs/defconfig
> +++ b/arch/arm64/configs/defconfig
> @@ -519,6 +519,7 @@ CONFIG_MEMTEST=y
> CONFIG_SECURITY=y
> CONFIG_CRYPTO_ECHAINIV=y
> CONFIG_CRYPTO_ANSI_CPRNG=y
> +CONFIG_CRYPTO_DEV_SAFEXCEL=m
> CONFIG_ARM64_CRYPTO=y
> CONFIG_CRYPTO_SHA1_ARM64_CE=y
> CONFIG_CRYPTO_SHA2_ARM64_CE=y
> --
> 2.11.0
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH 6/7] arm64: marvell: dts: enable the crypto engine on the Armada 8040 DB
From: Gregory CLEMENT @ 2017-04-12 8:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170329124432.27457-7-antoine.tenart@free-electrons.com>
Hi Antoine,
On mer., mars 29 2017, Antoine Tenart <antoine.tenart@free-electrons.com> wrote:
> Enable the cryptographic engine available in the CP110 master on the
> Armada 8040 DB. Do not enable the one in the CP110 salve for now, as we
> do not support multiple cryptographic engines yet.
>
> Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
Applied on mvebu/dt64
Thanks,
Gregory
> ---
> arch/arm64/boot/dts/marvell/armada-8040-db.dts | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/marvell/armada-8040-db.dts b/arch/arm64/boot/dts/marvell/armada-8040-db.dts
> index 80e685e4235d..f6d808bced51 100644
> --- a/arch/arm64/boot/dts/marvell/armada-8040-db.dts
> +++ b/arch/arm64/boot/dts/marvell/armada-8040-db.dts
> @@ -140,6 +140,10 @@
> phy-mode = "rgmii-id";
> };
>
> +&cpm_crypto {
> + status = "okay";
> +};
> +
> /* CON5 on CP1 expansion */
> &cps_pcie2 {
> status = "okay";
> --
> 2.11.0
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH 5/7] arm64: marvell: dts: enable the crypto engine on the Armada 7040 DB
From: Gregory CLEMENT @ 2017-04-12 8:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170329124432.27457-6-antoine.tenart@free-electrons.com>
Hi Antoine,
On mer., mars 29 2017, Antoine Tenart <antoine.tenart@free-electrons.com> wrote:
> Enable the cryptographic engine available in the CP110 master on the
> Armada 7040 DB.
>
> Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
Applied on mvebu/dt64
Thanks,
Gregory
> ---
> arch/arm64/boot/dts/marvell/armada-7040-db.dts | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/marvell/armada-7040-db.dts b/arch/arm64/boot/dts/marvell/armada-7040-db.dts
> index bb0e1e8e7138..7e9a8a4e89a4 100644
> --- a/arch/arm64/boot/dts/marvell/armada-7040-db.dts
> +++ b/arch/arm64/boot/dts/marvell/armada-7040-db.dts
> @@ -171,3 +171,7 @@
> phy = <&phy1>;
> phy-mode = "rgmii-id";
> };
> +
> +&cpm_crypto {
> + status = "okay";
> +};
> --
> 2.11.0
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH 4/7] arm64: marvell: dts: add crypto engine description for 7k/8k
From: Gregory CLEMENT @ 2017-04-12 8:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170329124432.27457-5-antoine.tenart@free-electrons.com>
Hi Antoine,
On mer., mars 29 2017, Antoine Tenart <antoine.tenart@free-electrons.com> wrote:
> Add the description of the crypto engine hardware block for the Marvell
> Armada 7k and Armada 8k processors; for both the CP110 slave and master.
>
> Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
Applied on mvebu/dt64, I fixed a merge conflict with the current
mvebu/dt64 and I took this opportunity to fix the lines over 80
characters for the interrupts.
Thanks,
Gregory
> ---
> arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi | 15 +++++++++++++++
> arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi | 15 +++++++++++++++
> 2 files changed, 30 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi b/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi
> index 9a2ce2ae49cd..7530a1b541c5 100644
> --- a/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi
> +++ b/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi
> @@ -210,6 +210,21 @@
> clocks = <&cpm_syscon0 1 25>;
> status = "okay";
> };
> +
> + cpm_crypto: crypto at 800000 {
> + compatible = "inside-secure,safexcel-eip197";
> + reg = <0x800000 0x200000>;
> + interrupts = <GIC_SPI 34 (IRQ_TYPE_EDGE_RISING | IRQ_TYPE_LEVEL_HIGH)>,
> + <GIC_SPI 54 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 55 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 56 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 58 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-names = "mem", "ring0", "ring1",
> + "ring2", "ring3", "eip";
> + clocks = <&cpm_syscon0 1 26>;
> + status = "disabled";
> + };
> };
>
> cpm_pcie0: pcie at f2600000 {
> diff --git a/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi b/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
> index c9dfa244ebb6..6110d39087a6 100644
> --- a/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
> +++ b/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
> @@ -210,6 +210,21 @@
> clocks = <&cps_syscon0 1 25>;
> status = "okay";
> };
> +
> + cps_crypto: crypto at 800000 {
> + compatible = "inside-secure,safexcel-eip197";
> + reg = <0x800000 0x200000>;
> + interrupts = <GIC_SPI 34 (IRQ_TYPE_EDGE_RISING | IRQ_TYPE_LEVEL_HIGH)>,
> + <GIC_SPI 278 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 279 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 280 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 281 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 282 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-names = "mem", "ring0", "ring1",
> + "ring2", "ring3", "eip";
> + clocks = <&cps_syscon0 1 26>;
> + status = "disabled";
> + };
> };
>
> cps_pcie0: pcie at f4600000 {
> --
> 2.11.0
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH v3 8/8] arm64: exception: check shared writable page in SEI handler
From: Xiongfeng Wang @ 2017-04-12 8:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <58E7B6BD.3000401@arm.com>
Hi James,
On 2017/4/7 23:56, James Morse wrote:
> Hi Xie XiuQi,
>
> On 30/03/17 11:31, Xie XiuQi wrote:
>> From: Wang Xiongfeng <wangxiongfeng2@huawei.com>
>>
>> Since SEI is asynchronous, the error data has been consumed. So we must
>> suppose that all the memory data current process can write are
>> contaminated. If the process doesn't have shared writable pages, the
>> process will be killed, and the system will continue running normally.
>> Otherwise, the system must be terminated, because the error has been
>> propagated to other processes running on other cores, and recursively
>> the error may be propagated to several another processes.
>
> This is pretty complicated. We can't guarantee that another CPU hasn't modified
> the page tables while we do this, (so its racy). We can't guarantee that the
> corrupt data hasn't been sent over the network or written to disk in the mean
> time (so its not enough).
>
> The scenario you have is a write of corrupt data to memory where another CPU
> reading it doesn't know the value is corrupt.
>
> The hardware gives us quite a lot of help containing errors. The RAS
> specification (DDI 0587A) describes your scenario as error propagation in '2.1.2
> Architectural error propagation', and then classifies it in '2.1.3
> Architecturally infected, containable and uncontainable' as uncontained because
> the value is no longer in the general-purpose registers. For uncontained errors
> we should panic().
>
> We shouldn't need to try to track errors after we get a notification as the
> hardware has done this for us.
>
Thanks for your comments. I think what you said is reasonable. We will remove this
patch and use AET fields of ESR_ELx to determine whether we should kill current
process or just panic.
>
> Firmware-first does complicate this if events like this are not delivered using
> a synchronous external abort, as Linux may have PSTATE.A masked preventing
> SError Interrupts from being taken. It looks like PSTATE.A is masked much more
> often than is necessary. I will look into cleaning this up.
>
>
> Thanks,
>
> James
>
> .
>
Thanks,
Wang Xiongfeng
^ 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