* [PATCH v4 00/10] AXP803 PMIC support for Pine64
From: Icenowy Zheng @ 2017-04-24 16:00 UTC (permalink / raw)
To: linux-arm-kernel
The Pine64 (including Pine64+) boards have an AXP803 PMIC, which is a PMIC
similar to AXP288, but tweaked to use with Allwinner SoCs rather than Intel
tablets (with DCIN and Vbus re-splitted like other AXP PMICs, and RSB bus
support added).
This patchset adds support for it and enabled it in Pine64 device tree.
The basical part of AXP803 MFD driver is already applied, according to Lee.
Thus this patchset is now still two parts, but a bit different to older
revisions:
- Part1: from PATCH 1/10 to PATCH 5/10, which focus on enabling AXP803 in
the device tree: the RSB bus, the R_INTC interrupt controller (for the
NMI line, which is connected to AXP803 on Pine64), and finally the basical
AXP803 node.
- Part2: from PATCH 5/10 to PATCH 10/10, which are enabling the regulator
function of the AXP803 PMIC. Finally Wi-Fi function is added
as a usage of regulators function.
PATCH 1 adds RSB device nodes, which is used for the communication between
A64 and AXP803.
PATCH 2 adds device tree binding of A64 R_INTC.
PATCH 3 really adds support for A64 R_INTC in NMI driver.
PATCH 4 adds R_INTC node in A64 device tree.
PATCH 5 adds AXP803 node to the Pine64 device tree by using already
applied drivers/bindings.
PATCH 6 adds support for AXP803 regulators in AXP20x regulatoe driver.
(The binding is already applied)
PATCH 7 enables the AXP803 regulator cell in MFD driver.
PATCH 8 adds a DTSI file for AXP803, like other older AXP PMICs.
PATCH 9 enables AXP803 regulators in Pine64 device tree.
PATCH 10 enables Wi-Fi for Pine64.
Icenowy Zheng (10):
arm64: allwinner: a64: enable RSB on A64
irqchip/sunxi-nmi: add A64 R_INTC to the binding doc
irqchip/sunxi-nmi: add support for the NMI in A64 R_INTC
arm64: allwinner: a64: add NMI (R_INTC) controller on A64
arm64: allwinner: a64: add AXP803 node to Pine64 device tree
regulator: axp20x-regulator: add support for AXP803
mfd: axp20x: add axp20x-regulator cell for AXP803
arm64: allwinner: a64: add DTSI file for AXP803 PMIC
arm64: allwinner: a64: enable AXP803 regulators for Pine64
arm64: allwinner: a64: enable Wi-Fi for Pine64
.../interrupt-controller/allwinner,sunxi-nmi.txt | 7 +-
arch/arm64/boot/dts/allwinner/axp803.dtsi | 150 ++++++++++++++++++++
.../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 136 ++++++++++++++++++
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 27 ++++
drivers/irqchip/irq-sunxi-nmi.c | 13 ++
drivers/mfd/axp20x.c | 3 +-
drivers/regulator/axp20x-regulator.c | 153 ++++++++++++++++++---
include/linux/mfd/axp20x.h | 37 +++++
8 files changed, 501 insertions(+), 25 deletions(-)
create mode 100644 arch/arm64/boot/dts/allwinner/axp803.dtsi
--
2.12.2
^ permalink raw reply
* [PATCH] iommu/arm-smmu: Return IOVA in iova_to_phys when SMMU is bypassed
From: Will Deacon @ 2017-04-24 16:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CA+sq2Cc3cjjPcw0F1D_BOu0j3x+MUNO27MeRguj6BpQ+t11_HQ@mail.gmail.com>
On Mon, Apr 24, 2017 at 09:23:16PM +0530, Sunil Kovvuri wrote:
> On Mon, Apr 24, 2017 at 8:14 PM, Will Deacon <will.deacon@arm.com> wrote:
> > On Mon, Apr 17, 2017 at 05:27:26PM +0530, sunil.kovvuri at gmail.com wrote:
> >> From: Sunil Goutham <sgoutham@cavium.com>
> >>
> >> For software initiated address translation, when domain type is
> >> IOMMU_DOMAIN_IDENTITY i.e SMMU is bypassed, mimic HW behavior
> >> i.e return the same IOVA as translated address.
> >>
> >> This patch is an extension to Will Deacon's patchset
> >> "Implement SMMU passthrough using the default domain".
> >
> > Are you actually seeing an issue here? If so, why isn't SMMUv3 affected too?
> Yes and SMMUv3 should also be effected but as of now I don't see any use case.
> If needed, i can re-submit the patch with changes in SMMUv3 as well.
Yes, please.
> >> Signed-off-by: Sunil Goutham <sgoutham@cavium.com>
> >> ---
> >> drivers/iommu/arm-smmu.c | 3 +++
> >> 1 file changed, 3 insertions(+)
> >>
> >> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> >> index 41afb07..2f4a130 100644
> >> --- a/drivers/iommu/arm-smmu.c
> >> +++ b/drivers/iommu/arm-smmu.c
> >> @@ -1405,6 +1405,9 @@ static phys_addr_t arm_smmu_iova_to_phys(struct iommu_domain *domain,
> >> struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
> >> struct io_pgtable_ops *ops= smmu_domain->pgtbl_ops;
> >>
> >> + if (domain->type == IOMMU_DOMAIN_IDENTITY)
> >> + return iova;
> >> +
> >> if (!ops)
> >> return 0;
> >
> > I'd have thought ops would be NULL, since arm_smmu_init_domain_context
> > doesn't allocate them for an identity domain.
> Yes ops is set to NULL.
Argh, sorry, I completely overlooked that we return 0 in that case, rather
than the iova.
> > I don't understand this patch. Please can you explain the problem more
> > clearly?
> AFAIK for any driver outside IOMMU there is only one way to identify
> if device is attached to
> IOMMU or not and that is by checking iommu_domain. And I don't think
> it would be appropriate
> for the driver to check domain->type before calling 'iommu_iova_to_phys()' API.
>
> The difference between IOMMU disabled and IOMMU being in passthrough
> mode is that, in the
> later case device is still attached to default domain but in former's
> case it's NULL. So there is no
> way to differentiate for the external driver whether IOMMU is in
> passthrough mode or DMA mode.
>
> And since ops is NULL in passthrough mode, 'iommu_iova_to_phys()' will
> return zero.
>
> Use case for your reference
> https://lkml.org/lkml/2017/3/7/299
> This driver is for a NIC interface on platform which supports SMMUv2.
Blimey, that driver is horrible, but I take your point on the API. Please
repost, fixing SMMUv3 at the same time.
Will
^ permalink raw reply
* [PATCH] fs: Preventing READ_IMPLIES_EXEC Propagation
From: Catalin Marinas @ 2017-04-24 15:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170424154023.GM12323@arm.com>
On Mon, Apr 24, 2017 at 04:40:23PM +0100, Will Deacon wrote:
> On Wed, Apr 19, 2017 at 11:33:14AM +0100, Catalin Marinas wrote:
> > On Tue, Apr 18, 2017 at 09:01:52PM +0100, Peter Maydell wrote:
> > > On 18 April 2017 at 18:01, Catalin Marinas <catalin.marinas@arm.com> wrote:
> > > > On Thu, Apr 13, 2017 at 08:33:52PM +0800, dongbo (E) wrote:
> > > >> From: Dong Bo <dongbo4@huawei.com>
> > > >>
> > > >> In load_elf_binary(), once the READ_IMPLIES_EXEC flag is set,
> > > >> the flag is propagated to its child processes, even the elf
> > > >> files are marked as not requiring executable stack. It may
> > > >> cause superfluous operations on some arch, e.g.
> > > >> __sync_icache_dcache on aarch64 due to a PROT_READ mmap is
> > > >> also marked as PROT_EXEC.
> > >
> > > > That's affecting most architectures with a risk of ABI breakage. We
> > > > could do it on arm64 only, though I'm not yet clear on the ABI
> > > > implications (at a first look, there shouldn't be any).
> > >
> > > Is there a reason why it isn't just straightforwardly a bug
> > > (which we could fix) to make READ_IMPLIES_EXEC propagate to
> > > child processes?
> >
> > While I agree that it looks like a bug, if there are user programs
> > relying on such bug we call it "ABI". On arm64, I don't think there is
> > anything relying on inheriting READ_IMPLIES_EXEC but I wouldn't change
> > the compat task handling without the corresponding change in arch/arm.
> >
> > > AFAICT this should be per-process: just because
> > > init happens not to have been (re)compiled to permit non-executable
> > > stacks doesn't mean every process on the system needs to have
> > > an executable stack.
> >
> > I think this also affects the heap if brk(2) is used (via
> > VM_DATA_DEFAULT_FLAGS though I guess malloc mostly uses mmap these
> > days).
>
> I think it also affects mprotect, which is more worrying imo, particularly
> for things like JIT code that is ported from 32-bit (although a quick look
> at v8, ionmonkey and art suggests they all pass PROT_EXEC when needed).
As Peter said, the default behaviour is READ_IMPLIES_EXEC off, so JIT
code must already pass PROT_EXEC if it wants executable permission. The
question is whether any user code relies on READ_IMPLIES_EXEC being
passed down to child processes. I don't think so but I would be
reluctant to make an such cross-arch change (happy to do it for arm64
though).
Since linux-arch was cc'ed in the middle of this thread, I doubt people
would reply. I suggest that the original patch is re-posted to
linux-arch directly.
--
Catalin
^ permalink raw reply
* [PATCH] iommu: arm-smmu: correct sid to mask
From: Will Deacon @ 2017-04-24 15:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492765416-30835-1-git-send-email-peng.fan@nxp.com>
On Fri, Apr 21, 2017 at 05:03:36PM +0800, Peng Fan wrote:
> From code "SMR mask 0x%x out of range for SMMU",
> so, we need to use mask, not sid.
>
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Robin Murphy <robin.murphy@arm.com>
> ---
> drivers/iommu/arm-smmu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> index b493c99..5a06de2 100644
> --- a/drivers/iommu/arm-smmu.c
> +++ b/drivers/iommu/arm-smmu.c
> @@ -1467,7 +1467,7 @@ static int arm_smmu_add_device(struct device *dev)
> }
> if (mask & ~smmu->smr_mask_mask) {
> dev_err(dev, "SMR mask 0x%x out of range for SMMU (0x%x)\n",
> - sid, smmu->smr_mask_mask);
> + mask, smmu->smr_mask_mask);
> goto out_free;
Looks like a copy-paste error to me:
Acked-by: Will Deacon <will.deacon@arm.com>
Joerg: do you mind picking this one up, please?
Thanks,
Will
^ permalink raw reply
* [PATCH] iommu/arm-smmu: Return IOVA in iova_to_phys when SMMU is bypassed
From: Sunil Kovvuri @ 2017-04-24 15:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170424144429.GI12323@arm.com>
On Mon, Apr 24, 2017 at 8:14 PM, Will Deacon <will.deacon@arm.com> wrote:
> On Mon, Apr 17, 2017 at 05:27:26PM +0530, sunil.kovvuri at gmail.com wrote:
>> From: Sunil Goutham <sgoutham@cavium.com>
>>
>> For software initiated address translation, when domain type is
>> IOMMU_DOMAIN_IDENTITY i.e SMMU is bypassed, mimic HW behavior
>> i.e return the same IOVA as translated address.
>>
>> This patch is an extension to Will Deacon's patchset
>> "Implement SMMU passthrough using the default domain".
>
> Are you actually seeing an issue here? If so, why isn't SMMUv3 affected too?
Yes and SMMUv3 should also be effected but as of now I don't see any use case.
If needed, i can re-submit the patch with changes in SMMUv3 as well.
>
>> Signed-off-by: Sunil Goutham <sgoutham@cavium.com>
>> ---
>> drivers/iommu/arm-smmu.c | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
>> index 41afb07..2f4a130 100644
>> --- a/drivers/iommu/arm-smmu.c
>> +++ b/drivers/iommu/arm-smmu.c
>> @@ -1405,6 +1405,9 @@ static phys_addr_t arm_smmu_iova_to_phys(struct iommu_domain *domain,
>> struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
>> struct io_pgtable_ops *ops= smmu_domain->pgtbl_ops;
>>
>> + if (domain->type == IOMMU_DOMAIN_IDENTITY)
>> + return iova;
>> +
>> if (!ops)
>> return 0;
>
> I'd have thought ops would be NULL, since arm_smmu_init_domain_context
> doesn't allocate them for an identity domain.
Yes ops is set to NULL.
>
> I don't understand this patch. Please can you explain the problem more
> clearly?
AFAIK for any driver outside IOMMU there is only one way to identify
if device is attached to
IOMMU or not and that is by checking iommu_domain. And I don't think
it would be appropriate
for the driver to check domain->type before calling 'iommu_iova_to_phys()' API.
The difference between IOMMU disabled and IOMMU being in passthrough
mode is that, in the
later case device is still attached to default domain but in former's
case it's NULL. So there is no
way to differentiate for the external driver whether IOMMU is in
passthrough mode or DMA mode.
And since ops is NULL in passthrough mode, 'iommu_iova_to_phys()' will
return zero.
Use case for your reference
https://lkml.org/lkml/2017/3/7/299
This driver is for a NIC interface on platform which supports SMMUv2.
Let me know if any more details are needed.
Thanks,
Sunil.
>
> Will
^ permalink raw reply
* [PATCH] arm64: fix the overlap between the kernel image and vmalloc address
From: Mark Rutland @ 2017-04-24 15:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <58FDFD90.8050300@huawei.com>
On Mon, Apr 24, 2017 at 09:28:48PM +0800, zhong jiang wrote:
> On 2017/4/24 18:44, Mark Rutland wrote:
> > So the issue is that we have the callchain below for a kernel image
> > address:
> >
> > read_kcore()
> > ->is_vmalloc_or_module_addr() // returns true
> > ->vread()
> > -->aligned_vread()
> > --->vmalloc_to_page()
> >
> > In is_vmalloc{,or_module}_addr() we just check the addr against
> > VMALLOC_START and VMALLOC_END, so they will return true for a kernel
> > image address.
> >
> > Then, we call vmalloc_to_page(). While this only handles mappings made
> > at page granularity, the kernel image mapping may have used sections. So
> > this tries a bogus walk to the pte level.
> > Should we special-case kernel image handling, e.g. with new
> > is_kernel_image_addr() / kernel_image_to_page() helpers?
> yes , it seems to the best way to implents it without performance back.
> The following patch is the implment. Any thought?
>
> Signed-off-by: zhong jiang <zhongjiang@huawei.com>
>
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index b84615b..851ac35 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -475,6 +475,15 @@ static inline bool is_vmalloc_addr(const void *x)
> return false;
> #endif
> }
> +
> +static inline bool is_kernel_image_addr(const void *x)
> +{
> + unsigned long addr = (unsigned long)x;
> +
> + return addr >= (unsigned long)_stext && addr < (unsigned long)_end;
> +
> +}
> +
> #ifdef CONFIG_MMU
> extern int is_vmalloc_or_module_addr(const void *x);
> #else
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index 3ca82d4..9a9ef65 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -229,6 +229,42 @@ int is_vmalloc_or_module_addr(const void *x)
> return is_vmalloc_addr(x);
> }
>
> +static struct page *kernel_image_to_page(const void *kernel_addr, pgd_t *pgd)
> +{
> + unsigned long addr = (unsigned long)kernel_addr;
> + struct page *page = NULL;
> + pud_t *pud;
> + pmd_t *pmd;
> + pte_t *pte;
> +
> + if (pgd_none(*pgd))
> + goto out;
> +
> + pud = pud_offset(pgd, addr);
> + if (pud_none(*pud))
> + goto out;
> +
> + if (pud_sect(*pud))
> + return pud_page(*pud);
The *_sect() helpers are arch-specific, so we cannot use them in generic
code. This would need to be architecture-specific.
Secondly, this will return head page of the section regardless of which
page in the section the address corresponds to
> +
> + pmd = pmd_offset(*pmd, addr);
> + if (pmd_none(*pmd))
> + goto out;
> +
> + if (pmd_sect(*pmd))
> + return pmd_page(*pmd);
Likewise on both counts.
> +
> + pte = pte_offset_kernel(pmd, addr);
> + if (pte_none(*pte))
> + goto out;
> +
> + page = pte_page(*pte);
> +
> +out:
> + return page;
> +
> +}
Given we know what the address should map to, I don't think we need to
walk the page tables here. I think this can be:
static struct page *kernel_image_to_page(const void *addr)
{
return virt_to_page(lm_alias(vmalloc_addr));
}
> +
> /*
> * Walk a vmap address to the struct page it maps.
> */
> @@ -244,6 +280,9 @@ struct page *vmalloc_to_page(const void *vmalloc_addr)
> */
> VIRTUAL_BUG_ON(!is_vmalloc_or_module_addr(vmalloc_addr));
>
> + if (is_kernel_image_addr(vmalloc_addr))
> + return kernel_image_to_page(vmalloc_addr, pgd);
It's not clear to me that this is the right place for this to live.
It might be best to code the kernel image logic directly in kcore (and
kmem), assuming everyone's OK with that approach.
Thanks,
Mark.
^ permalink raw reply
* [PATCH v2] arm64: perf: Use only exclude_kernel attribute when kernel is running in HYP
From: Will Deacon @ 2017-04-24 15:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAFpQJXVSsg8CX28vEo2LzmOi3pknHiH233spMD6ip4LZO4vw=Q@mail.gmail.com>
On Thu, Apr 20, 2017 at 02:56:50PM +0530, Ganapatrao Kulkarni wrote:
> On Thu, Apr 20, 2017 at 2:19 PM, Mark Rutland <mark.rutland@arm.com> wrote:
> > On Wed, Apr 19, 2017 at 11:14:06PM +0530, Ganapatrao Kulkarni wrote:
> >> commit d98ecda (arm64: perf: Count EL2 events if the kernel is running in HYP)
> >> is returning error for perf syscall with mixed attribute set for exclude_kernel
> >> and exclude_hv. This change is breaking some applications (observed with hhvm)
> >> when ran on VHE enabled platforms.
> >>
> >> Adding fix to consider only exclude_kernel attribute when kernel is
> >> running in HYP. Also adding sysfs file to notify the bhehaviour
> >> of attribute exclude_hv.
> >>
> >> Signed-off-by: Ganapatrao Kulkarni <ganapatrao.kulkarni@cavium.com>
> >> ---
> >>
> >> Changelog:
> >>
> >> V2:
> >> - Changes as per Will Deacon's suggestion.
> >>
> >> V1: Initial patch
> >>
> >> arch/arm64/kernel/perf_event.c | 28 ++++++++++++++++++++++++----
> >> include/linux/perf/arm_pmu.h | 1 +
> >> 2 files changed, 25 insertions(+), 4 deletions(-)
> >>
> >> @@ -871,14 +890,13 @@ static int armv8pmu_set_event_filter(struct hw_perf_event *event,
> >>
> >> if (attr->exclude_idle)
> >> return -EPERM;
> >> - if (is_kernel_in_hyp_mode() &&
> >> - attr->exclude_kernel != attr->exclude_hv)
> >> - return -EINVAL;
> >> + if (is_kernel_in_hyp_mode() && !attr->exclude_kernel)
> >> + config_base |= ARMV8_PMU_INCLUDE_EL2;
> >> if (attr->exclude_user)
> >> config_base |= ARMV8_PMU_EXCLUDE_EL0;
> >> if (!is_kernel_in_hyp_mode() && attr->exclude_kernel)
> >> config_base |= ARMV8_PMU_EXCLUDE_EL1;
> >> - if (!attr->exclude_hv)
> >> + if (!is_kernel_in_hyp_mode() && !attr->exclude_hv)
> >> config_base |= ARMV8_PMU_INCLUDE_EL2;
> >
> > This isn't quite what Will suggested.
> >
> > The idea was that userspace would read sysfs, then use that to determine
> > the correct exclusion parameters [1,2]. This logic was not expected to
> > change; it correctly validates whether we can provide what the user
> > requests.
>
> OK, if you are ok with sysfs part, i can send next version with that
> change only?.
I think the sysfs part is still a little dodgy, since you still expose the
"exclude_hv" file with a value of 0 when not running at EL2, which would
imply that exclude_hv is forced to zero. I don't think that's correct.
Will
^ permalink raw reply
* [PATCH] fs: Preventing READ_IMPLIES_EXEC Propagation
From: Will Deacon @ 2017-04-24 15:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170419103313.GA3238@e104818-lin.cambridge.arm.com>
On Wed, Apr 19, 2017 at 11:33:14AM +0100, Catalin Marinas wrote:
> On Tue, Apr 18, 2017 at 09:01:52PM +0100, Peter Maydell wrote:
> > On 18 April 2017 at 18:01, Catalin Marinas <catalin.marinas@arm.com> wrote:
> > > On Thu, Apr 13, 2017 at 08:33:52PM +0800, dongbo (E) wrote:
> > >> From: Dong Bo <dongbo4@huawei.com>
> > >>
> > >> In load_elf_binary(), once the READ_IMPLIES_EXEC flag is set,
> > >> the flag is propagated to its child processes, even the elf
> > >> files are marked as not requiring executable stack. It may
> > >> cause superfluous operations on some arch, e.g.
> > >> __sync_icache_dcache on aarch64 due to a PROT_READ mmap is
> > >> also marked as PROT_EXEC.
> >
> > > That's affecting most architectures with a risk of ABI breakage. We
> > > could do it on arm64 only, though I'm not yet clear on the ABI
> > > implications (at a first look, there shouldn't be any).
> >
> > Is there a reason why it isn't just straightforwardly a bug
> > (which we could fix) to make READ_IMPLIES_EXEC propagate to
> > child processes?
>
> While I agree that it looks like a bug, if there are user programs
> relying on such bug we call it "ABI". On arm64, I don't think there is
> anything relying on inheriting READ_IMPLIES_EXEC but I wouldn't change
> the compat task handling without the corresponding change in arch/arm.
>
> > AFAICT this should be per-process: just because
> > init happens not to have been (re)compiled to permit non-executable
> > stacks doesn't mean every process on the system needs to have
> > an executable stack.
>
> I think this also affects the heap if brk(2) is used (via
> VM_DATA_DEFAULT_FLAGS though I guess malloc mostly uses mmap these
> days).
I think it also affects mprotect, which is more worrying imo, particularly
for things like JIT code that is ported from 32-bit (although a quick look
at v8, ionmonkey and art suggests they all pass PROT_EXEC when needed).
Will
^ permalink raw reply
* [PATCH 1/2] arm64:vdso: Rewrite gettimeofday into C.
From: Catalin Marinas @ 2017-04-24 15:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492991221-5156-1-git-send-email-apinski@cavium.com>
On Sun, Apr 23, 2017 at 04:47:00PM -0700, Andrew Pinski wrote:
> This allows the compiler to optimize the divide by 1000.
> And remove the other divide.
>
> On ThunderX, gettimeofday improves by 32%. On ThunderX 2,
> gettimeofday improves by 18%.
Is this with or without the second patch (removing the ISB)?
--
Catalin
^ permalink raw reply
* [PATCH net-next 1/4] ixgbe: sparc: rename the ARCH_WANT_RELAX_ORDER to IXGBE_ALLOW_RELAXED_ORDER
From: Will Deacon @ 2017-04-24 14:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <EE11001F9E5DDD47B7634E2F8A612F2E2053543C@FRAEML521-MBX.china.huawei.com>
On Wed, Apr 19, 2017 at 02:46:19PM +0000, Gabriele Paoloni wrote:
> > From: Amir Ancel [mailto:amira at mellanox.com]
> > Sent: 18 April 2017 21:18
> > To: David Laight; Gabriele Paoloni; davem at davemloft.net
> > Cc: Catalin Marinas; Will Deacon; Mark Rutland; Robin Murphy;
> > jeffrey.t.kirsher at intel.com; alexander.duyck at gmail.com; linux-arm-
> > kernel at lists.infradead.org; netdev at vger.kernel.org; Dingtianhong;
> > Linuxarm
> > Subject: Re: Re: [PATCH net-next 1/4] ixgbe: sparc: rename the
> > ARCH_WANT_RELAX_ORDER to IXGBE_ALLOW_RELAXED_ORDER
> >
> > Hi,
> > mlx5 driver is planned to have RO support this year.
> > I believe drivers should be able to query whether the arch support it
>
> I guess that here when you say query you mean having a config symbol
> that is set accordingly to the host architecture, right?
>
> As already said I have looked around a bit and other drivers do not seem
> to enable/disable RO for their EP on the basis of the host architecture.
> So why should mlx5 do it according to the host?
>
> Also my understating is that some architectures (like ARM64 for example)
> can have different PCI host controller implementations depending on the
> vendor...therefore maybe it is not appropriate there to have a Kconfig
> symbol selected by the architecture...
Indeed. We're not able to determine whether or not RO is supported at
compile time, so we'd have to detect this dynamically if we want to support
it for arm64 with a single kernel Image. That means either passing something
through firmware, having the PCI host controller opt-in or something coarse
like a command-line option.
Will
^ permalink raw reply
* [PATCH v2] arm: imx6: zii: Add i210 PCIe interface to the device tree
From: Lucas Stach @ 2017-04-24 14:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170424141012.GA12780@lunn.ch>
Hi Andrew,
Am Montag, den 24.04.2017, 16:10 +0200 schrieb Andrew Lunn:
> On Mon, Apr 24, 2017 at 10:47:22AM +0200, Lucas Stach wrote:
> > Am Samstag, den 15.04.2017, 22:45 -0700 schrieb Chris Healy:
> > > The board has an Intel i210 Ethernet controller on its PCIe bus. Add a
> > > device tree node for this.
> >
> > I wold prefer a better description on why we need this node, as PCIe is
> > an enumerable bus. Do you need this node to attach a MAC address or
> > something?
>
> Hi Lucas
>
> We need to attach an Ethernet switch, using the DSA binding. Please
> take a look at Documentation/binding/net/dsa.txt. We need a phandle to
> the i210 Ethernet MAC.
Sure, this rationale seems fine. Please make sure to include it in the
patch description on the next submission.
Regards,
Lucas
^ permalink raw reply
* [PATCH] iommu/arm-smmu: Return IOVA in iova_to_phys when SMMU is bypassed
From: Will Deacon @ 2017-04-24 14:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492430246-17267-1-git-send-email-sunil.kovvuri@gmail.com>
On Mon, Apr 17, 2017 at 05:27:26PM +0530, sunil.kovvuri at gmail.com wrote:
> From: Sunil Goutham <sgoutham@cavium.com>
>
> For software initiated address translation, when domain type is
> IOMMU_DOMAIN_IDENTITY i.e SMMU is bypassed, mimic HW behavior
> i.e return the same IOVA as translated address.
>
> This patch is an extension to Will Deacon's patchset
> "Implement SMMU passthrough using the default domain".
Are you actually seeing an issue here? If so, why isn't SMMUv3 affected too?
> Signed-off-by: Sunil Goutham <sgoutham@cavium.com>
> ---
> drivers/iommu/arm-smmu.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> index 41afb07..2f4a130 100644
> --- a/drivers/iommu/arm-smmu.c
> +++ b/drivers/iommu/arm-smmu.c
> @@ -1405,6 +1405,9 @@ static phys_addr_t arm_smmu_iova_to_phys(struct iommu_domain *domain,
> struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
> struct io_pgtable_ops *ops= smmu_domain->pgtbl_ops;
>
> + if (domain->type == IOMMU_DOMAIN_IDENTITY)
> + return iova;
> +
> if (!ops)
> return 0;
I'd have thought ops would be NULL, since arm_smmu_init_domain_context
doesn't allocate them for an identity domain.
I don't understand this patch. Please can you explain the problem more
clearly?
Will
^ permalink raw reply
* [RFC PATH] of/pci/dma: fix DMA configruation for PCI masters
From: Rob Herring @ 2017-04-24 14:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492848487-11768-1-git-send-email-oza.oza@broadcom.com>
On Sat, Apr 22, 2017 at 3:08 AM, Oza Pawandeep <oza.oza@broadcom.com> wrote:
> current device frmework and of framework integration assumes dma-ranges
> in a way where memory-mapped devices define their dma-ranges.
> dma-ranges: (child-bus-address, parent-bus-address, length).
>
> but iproc based SOCs and other SOCs(suc as rcar) have PCI world dma-ranges.
> dma-ranges = <0x43000000 0x00 0x00 0x00 0x00 0x80 0x00>;
>
> of_dma_configure is specifically witten to take care of memory mapped devices.
> but no implementation exists for pci to take care of pcie based memory ranges.
> in fact pci world doesnt seem to define standard dma-ranges
>
> this patch served following purposes
>
> 1) exposes intrface to the pci host driver for thir inbound memory ranges
>
> 2) provide an interface to callers such as of_dma_get_ranges.
> so then the returned size get best possible (largest) dma_mask.
> for e.g.
> dma-ranges = <0x43000000 0x00 0x00 0x00 0x00 0x80 0x00>;
> we should get dev->coherent_dma_mask=0x7fffffffff.
>
> 3) this patch handles multiple inbound windows and dma-ranges.
> it is left to the caller, how it wants to use them.
> the new function returns the resources in a standard and unform way
>
> 4) this way the callers of of_dma_get_ranges does not need to change.
> and
>
> 5) leaves scope of adding PCI flag handling for inbound memory
> by the new function.
>
> Signed-off-by: Oza Pawandeep <oza.oza@broadcom.com>
>
> diff --git a/drivers/of/address.c b/drivers/of/address.c
> index 02b2903..ec21191 100644
> --- a/drivers/of/address.c
> +++ b/drivers/of/address.c
> @@ -6,6 +6,7 @@
> #include <linux/ioport.h>
> #include <linux/module.h>
> #include <linux/of_address.h>
> +#include <linux/of_pci.h>
> #include <linux/pci.h>
> #include <linux/pci_regs.h>
> #include <linux/sizes.h>
> @@ -829,10 +830,30 @@ int of_dma_get_range(struct device_node *np, u64 *dma_addr, u64 *paddr, u64 *siz
> int len, naddr, nsize, pna;
> int ret = 0;
> u64 dmaaddr;
> + struct resource_entry *window;
> + LIST_HEAD(res);
>
> if (!node)
> return -EINVAL;
>
> + if (strcmp(np->name, "pci")) {
Using the name is not reliable though I did recently add a dtc check
for this. Of course, 'pcie' is valid too (and probably should be used
for what you are testing). type is what you want to use here. We
already have bus matching function and bus specific handlers in
address.c. Whatever solution you come up with should be integrated
with the existing bus specific handlers.
Rob
^ permalink raw reply
* [PATCH 9/9] crypto: ccp - Use IPAD/OPAD constant
From: Corentin Labbe @ 2017-04-24 14:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170424141629.27155-1-clabbe.montjoie@gmail.com>
This patch simply replace all occurrence of HMAC IPAD/OPAD value by their
define.
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
drivers/crypto/ccp/ccp-crypto-sha.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/ccp/ccp-crypto-sha.c b/drivers/crypto/ccp/ccp-crypto-sha.c
index 6b46eea..3834366 100644
--- a/drivers/crypto/ccp/ccp-crypto-sha.c
+++ b/drivers/crypto/ccp/ccp-crypto-sha.c
@@ -308,8 +308,8 @@ static int ccp_sha_setkey(struct crypto_ahash *tfm, const u8 *key,
}
for (i = 0; i < block_size; i++) {
- ctx->u.sha.ipad[i] = ctx->u.sha.key[i] ^ 0x36;
- ctx->u.sha.opad[i] = ctx->u.sha.key[i] ^ 0x5c;
+ ctx->u.sha.ipad[i] = ctx->u.sha.key[i] ^ HMAC_IPAD_VALUE;
+ ctx->u.sha.opad[i] = ctx->u.sha.key[i] ^ HMAC_OPAD_VALUE;
}
sg_init_one(&ctx->u.sha.opad_sg, ctx->u.sha.opad, block_size);
--
2.10.2
^ permalink raw reply related
* [PATCH 8/9] crypto: mediatek - Use IPAD/OPAD constant
From: Corentin Labbe @ 2017-04-24 14:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170424141629.27155-1-clabbe.montjoie@gmail.com>
This patch simply replace all occurrence of HMAC IPAD/OPAD value by their
define.
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
drivers/crypto/mediatek/mtk-sha.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/mediatek/mtk-sha.c b/drivers/crypto/mediatek/mtk-sha.c
index 2226f12..cbcb522 100644
--- a/drivers/crypto/mediatek/mtk-sha.c
+++ b/drivers/crypto/mediatek/mtk-sha.c
@@ -825,8 +825,8 @@ static int mtk_sha_setkey(struct crypto_ahash *tfm, const u8 *key,
memcpy(bctx->opad, bctx->ipad, bs);
for (i = 0; i < bs; i++) {
- bctx->ipad[i] ^= 0x36;
- bctx->opad[i] ^= 0x5c;
+ bctx->ipad[i] ^= HMAC_IPAD_VALUE;
+ bctx->opad[i] ^= HMAC_OPAD_VALUE;
}
return 0;
--
2.10.2
^ permalink raw reply related
* [PATCH 7/9] crypto: qat - Use IPAD/OPAD constant
From: Corentin Labbe @ 2017-04-24 14:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170424141629.27155-1-clabbe.montjoie@gmail.com>
This patch simply replace all occurrence of HMAC IPAD/OPAD value by their
define.
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
drivers/crypto/qat/qat_common/qat_algs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/qat/qat_common/qat_algs.c b/drivers/crypto/qat/qat_common/qat_algs.c
index 20f35df..6843fe2 100644
--- a/drivers/crypto/qat/qat_common/qat_algs.c
+++ b/drivers/crypto/qat/qat_common/qat_algs.c
@@ -178,8 +178,8 @@ static int qat_alg_do_precomputes(struct icp_qat_hw_auth_algo_blk *hash,
for (i = 0; i < block_size; i++) {
char *ipad_ptr = ipad + i;
char *opad_ptr = opad + i;
- *ipad_ptr ^= 0x36;
- *opad_ptr ^= 0x5C;
+ *ipad_ptr ^= HMAC_IPAD_VALUE;
+ *opad_ptr ^= HMAC_OPAD_VALUE;
}
if (crypto_shash_init(shash))
--
2.10.2
^ permalink raw reply related
* [PATCH 6/9] crypto: omap-sham - Use IPAD/OPAD constant
From: Corentin Labbe @ 2017-04-24 14:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170424141629.27155-1-clabbe.montjoie@gmail.com>
This patch simply replace all occurrence of HMAC IPAD/OPAD value by their
define.
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
drivers/crypto/omap-sham.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/omap-sham.c b/drivers/crypto/omap-sham.c
index d0b16e5..11e11a6 100644
--- a/drivers/crypto/omap-sham.c
+++ b/drivers/crypto/omap-sham.c
@@ -1326,8 +1326,8 @@ static int omap_sham_setkey(struct crypto_ahash *tfm, const u8 *key,
memcpy(bctx->opad, bctx->ipad, bs);
for (i = 0; i < bs; i++) {
- bctx->ipad[i] ^= 0x36;
- bctx->opad[i] ^= 0x5c;
+ bctx->ipad[i] ^= HMAC_IPAD_VALUE;
+ bctx->opad[i] ^= HMAC_OPAD_VALUE;
}
}
--
2.10.2
^ permalink raw reply related
* [PATCH 5/9] crypto: mv_cesa - Use IPAD/OPAD constant
From: Corentin Labbe @ 2017-04-24 14:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170424141629.27155-1-clabbe.montjoie@gmail.com>
This patch simply replace all occurrence of HMAC IPAD/OPAD value by their
define.
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
drivers/crypto/mv_cesa.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/mv_cesa.c b/drivers/crypto/mv_cesa.c
index 451fa18..41ae190 100644
--- a/drivers/crypto/mv_cesa.c
+++ b/drivers/crypto/mv_cesa.c
@@ -822,8 +822,8 @@ static int mv_hash_setkey(struct crypto_ahash *tfm, const u8 * key,
memcpy(opad, ipad, bs);
for (i = 0; i < bs; i++) {
- ipad[i] ^= 0x36;
- opad[i] ^= 0x5c;
+ ipad[i] ^= HMAC_IPAD_VALUE;
+ opad[i] ^= HMAC_OPAD_VALUE;
}
rc = crypto_shash_init(shash) ? :
--
2.10.2
^ permalink raw reply related
* [PATCH 4/9] crypto: marvell - Use IPAD/OPAD constant
From: Corentin Labbe @ 2017-04-24 14:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170424141629.27155-1-clabbe.montjoie@gmail.com>
This patch simply replace all occurrence of HMAC IPAD/OPAD value by their
define.
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
drivers/crypto/marvell/hash.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/marvell/hash.c b/drivers/crypto/marvell/hash.c
index 77c0fb9..a6df61f 100644
--- a/drivers/crypto/marvell/hash.c
+++ b/drivers/crypto/marvell/hash.c
@@ -1164,8 +1164,8 @@ static int mv_cesa_ahmac_pad_init(struct ahash_request *req,
memcpy(opad, ipad, blocksize);
for (i = 0; i < blocksize; i++) {
- ipad[i] ^= 0x36;
- opad[i] ^= 0x5c;
+ ipad[i] ^= HMAC_IPAD_VALUE;
+ opad[i] ^= HMAC_OPAD_VALUE;
}
return 0;
--
2.10.2
^ permalink raw reply related
* [PATCH 3/9] crypto: ixp4xx - Use IPAD/OPAD constant
From: Corentin Labbe @ 2017-04-24 14:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170424141629.27155-1-clabbe.montjoie@gmail.com>
This patch simply replace all occurrence of HMAC IPAD/OPAD value by their
define.
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
drivers/crypto/ixp4xx_crypto.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/crypto/ixp4xx_crypto.c b/drivers/crypto/ixp4xx_crypto.c
index 771dd26..3b7680c 100644
--- a/drivers/crypto/ixp4xx_crypto.c
+++ b/drivers/crypto/ixp4xx_crypto.c
@@ -90,8 +90,6 @@
#define CTL_FLAG_PERFORM_AEAD 0x0008
#define CTL_FLAG_MASK 0x000f
-#define HMAC_IPAD_VALUE 0x36
-#define HMAC_OPAD_VALUE 0x5C
#define HMAC_PAD_BLOCKLEN SHA1_BLOCK_SIZE
#define MD5_DIGEST_SIZE 16
--
2.10.2
^ permalink raw reply related
* [PATCH 2/9] crypto: brcm - Use IPAD/OPAD constant
From: Corentin Labbe @ 2017-04-24 14:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170424141629.27155-1-clabbe.montjoie@gmail.com>
This patch simply replace all occurrence of HMAC IPAD/OPAD value by their
define.
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
drivers/crypto/bcm/cipher.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/bcm/cipher.c b/drivers/crypto/bcm/cipher.c
index cc0d5b9..304c7ed 100644
--- a/drivers/crypto/bcm/cipher.c
+++ b/drivers/crypto/bcm/cipher.c
@@ -2510,8 +2510,8 @@ static int ahash_hmac_setkey(struct crypto_ahash *ahash, const u8 *key,
memcpy(ctx->opad, ctx->ipad, blocksize);
for (index = 0; index < blocksize; index++) {
- ctx->ipad[index] ^= 0x36;
- ctx->opad[index] ^= 0x5c;
+ ctx->ipad[index] ^= HMAC_IPAD_VALUE;
+ ctx->opad[index] ^= HMAC_OPAD_VALUE;
}
flow_dump(" ipad: ", ctx->ipad, blocksize);
--
2.10.2
^ permalink raw reply related
* [PATCH 1/9] crypto: add hmac IPAD/OPAD constant
From: Corentin Labbe @ 2017-04-24 14:16 UTC (permalink / raw)
To: linux-arm-kernel
Many HMAC users directly use directly 0x36/0x5c values.
It's better with crypto to use a name instead of directly some crypto
constant.
This patch simply add HMAC_IPAD_VALUE/HMAC_OPAD_VALUE defines.
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
crypto/hmac.c | 4 ++--
include/crypto/hash.h | 3 +++
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/crypto/hmac.c b/crypto/hmac.c
index 72e38c0..4a997ce 100644
--- a/crypto/hmac.c
+++ b/crypto/hmac.c
@@ -74,8 +74,8 @@ static int hmac_setkey(struct crypto_shash *parent,
memcpy(opad, ipad, bs);
for (i = 0; i < bs; i++) {
- ipad[i] ^= 0x36;
- opad[i] ^= 0x5c;
+ ipad[i] ^= HMAC_IPAD_VALUE;
+ opad[i] ^= HMAC_OPAD_VALUE;
}
return crypto_shash_init(shash) ?:
diff --git a/include/crypto/hash.h b/include/crypto/hash.h
index b5727bc..0f51ff1 100644
--- a/include/crypto/hash.h
+++ b/include/crypto/hash.h
@@ -922,4 +922,7 @@ static inline void shash_desc_zero(struct shash_desc *desc)
sizeof(*desc) + crypto_shash_descsize(desc->tfm));
}
+#define HMAC_IPAD_VALUE 0x36
+#define HMAC_OPAD_VALUE 0x5c
+
#endif /* _CRYPTO_HASH_H */
--
2.10.2
^ permalink raw reply related
* [RFC] minimum gcc version for kernel: raise to gcc-4.3 or 4.6?
From: Arnd Bergmann @ 2017-04-24 14:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdUOv-sn9vDei0qPaRe19faYJGZ1zo1X==JDyFWJW3x5=A@mail.gmail.com>
On Mon, Apr 24, 2017 at 12:17 PM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> On Mon, Apr 24, 2017 at 11:44 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>> On Sun, Apr 23, 2017 at 10:13 PM, Geert Uytterhoeven
>> <geert@linux-m68k.org> wrote:
>>> On Sat, Apr 22, 2017 at 5:30 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>>> My main motivation for keep on using gcc-4.1 is that it gives many warnings
>>> that were disabled in later gcc versions. I do look at all new warnings, and
>>> send patches when they are real bugs, or are trivial to silence.
>>
>> What kind of warnings do you see that disappeared with later versions?
>> Do you know what caused them to disappear in later versions (different
>> optimization decisions, warning getting disabled by default but still available
>> for turning on manually, ...)? Do you know if the disabled warnings are
>> still there in gcc-4.3 (I can try it out if you give me examples)?
>
> Mostly the "may be used uninitialized" warnings. I believe they were disabled
> in gcc-4.3 (4.2?) and later due to too many false positives, which is not an
> issue for me, as I look at differences.
> They were re-enabled lately (with much less false-positives), that's why you
> see them, and fix them.
Linus added -Wno-maybe-uninitialized a while ago, and I think only gcc-4.8
and higher were affected by that, as earlier versions only understand
-Wuninitialized (meaning both "definitely uninitialized" and "might be
uninitialized". The latest state is that gcc-4.9 enables all uninitialized
warnings and I try to fix them for all known compilers, gcc-4.8
disables -Wmaybe-uninitialized unless you build with "make W=2".
On gcc-4.9 and higher, we also don't enable -Wmaybe-unintialized when
certain configuration options are set that cause extra false positives,
but it's still enabled with W=2.
I actually think it would be a good idea to also disable -Wuninitialized
for gcc-4.7 and earlier unless you ask for W2. That would get us
much closer to a clean build, but still give you the chance to see the
warnings if you really want to.
> For example, do you see the warning fixed by commit 1b8c1012142d8322
> ("drivers: net: xgene: Simplify xgene_enet_setup_mss() to kill warning")
> with gcc-4.3? Yes, that was a false positive.
I see this one until gcc-4.8 if I build with W=2 to turn the warning back on.
> Or see commit cc4a7ffe02c95f53 ("spi: fsl-lpspi: Pre-initialize ret in
> fsl_lpspi_transfer_one_msg()"). That one was a real bug.
>
> I don't see that in any of the kisskb build logs, and they use gcc-4.2.4 for
> avr32. So having gcc-4.2 or gcc-4.3 in a farm won't help.
Also here: I see the warning on ARM with all versions from gcc-4.1 through
4.8 (with W=1), but not any higher versions including 7.0.1. If I mark
fsl_lpspi_transfer_one as 'noinline', I see it on all versions, which is a bit
odd. It might be worth opening a gcc bug report for that. I tried the
'noinline' as I suspected gcc might be smart enough to figure out that
the list is never empty, but I later noticed that it has no way of knowing
that even without the 'noinline' flag.
> And as long as I find real bugs this way, I'd like to continue doing it.
I've tested all the architectures I mentioned earlier that were around 10
years ago (aside from ia64, I could not build gcc successfully) with
linux-4.3 (arbitrarily picked, this was the version in which x86 and mips
no longer built with gcc-4.1), and built a defconfig with both gcc-4.9
(which I had around from earlier testing) and with gcc-4.1/4.3:
gcc-4.1 gcc-4.3 gcc-4.9
alpha failed success success
arm failed success success
cris failed success success
frv failed failed success
m32r success success success
m68k success success success
mips failed failed success
parisc success success success
powerpc failed failed success
s390 failed failed success
sh failed success success
x86 failed success success
I'd conclude that nobody aside from you sends bugfixes for 4.1,
or has done so in a while. I have the logs available if you want,
but there isn't really much surprising: we get the same link error
as on mips and x86 on some additional architectures, powerpc
and s390 use features that weren't available and frv hits an ICE.
We could define the minimum compiler to be gcc-4.3 on all architectures
except m68k (and possibly parisc, certainly nobody cares about
m32r enough), where it would be gcc-4.1, to reflect what is actually
already the case.
Arnd
^ permalink raw reply
* [PATCH v2] arm: imx6: zii: Add i210 PCIe interface to the device tree
From: Andrew Lunn @ 2017-04-24 14:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1493023642.2891.2.camel@pengutronix.de>
On Mon, Apr 24, 2017 at 10:47:22AM +0200, Lucas Stach wrote:
> Am Samstag, den 15.04.2017, 22:45 -0700 schrieb Chris Healy:
> > The board has an Intel i210 Ethernet controller on its PCIe bus. Add a
> > device tree node for this.
>
> I wold prefer a better description on why we need this node, as PCIe is
> an enumerable bus. Do you need this node to attach a MAC address or
> something?
Hi Lucas
We need to attach an Ethernet switch, using the DSA binding. Please
take a look at Documentation/binding/net/dsa.txt. We need a phandle to
the i210 Ethernet MAC.
Andrew
^ permalink raw reply
* [PATCH] arm64: pmuv3: Support v8.1 PMUv3 extension
From: Mark Rutland @ 2017-04-24 14:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170424133929.GA4952@localhost>
On Mon, Apr 24, 2017 at 01:39:30PM +0000, Jayachandran C wrote:
> The v8.1 supplement is quite clear on the field definition:
>
> PMUVer, bits [11:8]
> ....
> Defined values are:
> 0000 Performance Monitors extension System registers not implemented.
> 0001 Performance Monitors extension System registers implemented, PMUv3.
> 0100 Performance Monitors extension System registers implemented, PMUv3, with a 16-bit
> evtCount field, and if EL2 is implemented, the addition of the MDCR_EL2.HPMD bit.
> 1111 IMPLEMENTATION DEFINED form of performance monitors supported, PMUv3 not
> supported.
> All other values are reserved.
> In ARMv8-A the permitted values are 0b0000, 0b0001 and 0b1111.
> In ARMv8.1 the permitted values are 0b0000, 0b0100 and 0b1111.
>
> I changed the code to strictly do this. We have to exclude 0xf, since that is not PMUv3.
> And we cannot predict what the reserved values will represent, so it is best to skip them
> until they are defined to be PMUv3 compatible.
My understanding is that ID_AA64DFR0.PMUVer is intended to be covered by
the usual ID register principles, and thus at least 0x2-0x7 are reserved
for architected backwards compatible extensions to PMUv3.
See ARM DDI 0487B.a, D7.1.4, "Principles of the ID scheme for fields in
ID registers". It is explicitly stated that the scheme applies to
ID_AA64DFR0.
Per those rules, we should check >= the minimum PMUv3 implemented value,
i.e. val >= 1. Due to both 0x0 and 0xF meaning PMUv3 isn't implemented,
it's not clear if the fields should be treated as if it were signed or
unsigned, and I'm awaiting clarification on this.
Either way, I believe that 0x1-0x7 must all be compatible with baseline
PMUv3 per the ID scheme principles.
Thanks,
Mark.
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
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