* next-20161205 build: 3 failures 4 warnings (next-20161205)
From: Bjorn Andersson @ 2016-12-06 18:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7b3daf13-dbab-5acf-cd5f-2414141500b3@arm.com>
On Mon 05 Dec 07:44 PST 2016, Marc Zyngier wrote:
> On 05/12/16 11:20, Mark Brown wrote:
> > On Mon, Dec 05, 2016 at 07:56:06AM +0000, Build bot for Mark Brown wrote:
> >
> > Today's -next fails to build an arm64 allnodconfig and allmodconfig
> > with:
> >
> >> arm64-allnoconfig
> >> ../arch/arm64/lib/clear_user.S:33: Error: bad or irreducible absolute expression
> >> ../arch/arm64/lib/clear_user.S:53: Error: bad or irreducible absolute expression
> >> ../arch/arm64/lib/clear_user.S:33: Error: attempt to move .org backwards
> >> ../arch/arm64/lib/clear_user.S:53: Error: attempt to move .org backwards
> >> ../arch/arm64/lib/copy_from_user.S:67: Error: bad or irreducible absolute expression
> >> ../arch/arm64/lib/copy_from_user.S:70: Error: bad or irreducible absolute expression
> >> ../arch/arm64/lib/copy_from_user.S:67: Error: attempt to move .org backwards
> >> ../arch/arm64/lib/copy_from_user.S:70: Error: attempt to move .org backwards
> >> ../arch/arm64/lib/copy_in_user.S:68: Error: bad or irreducible absolute expression
> >> ../arch/arm64/lib/copy_in_user.S:71: Error: bad or irreducible absolute expression
> >> ../arch/arm64/lib/copy_in_user.S:68: Error: attempt to move .org backwards
> >> ../arch/arm64/lib/copy_in_user.S:71: Error: attempt to move .org backwards
> >> ../arch/arm64/lib/copy_to_user.S:66: Error: bad or irreducible absolute expression
> >> ../arch/arm64/lib/copy_to_user.S:69: Error: bad or irreducible absolute expression
> >> ../arch/arm64/lib/copy_to_user.S:66: Error: attempt to move .org backwards
> >> ../arch/arm64/lib/copy_to_user.S:69: Error: attempt to move .org backwards
> >
> > This was triggered somehow by bca8f17f57bd7 (arm64: Get rid of
> > asm/opcodes.h) though I didn't figure out how.
>
> Old and broken gas. I have a workaround stashed there:
>
> http://git.kernel.org/cgit/linux/kernel/git/maz/arm-platforms.git/commit/?h=arm64/standalone.h&id=559f97365362ed9e96f594200020379df46630d8
>
> At least binutils 2.24 and 2.25 are affected, while 2.27 is not.
>
Made me realize that the Ubuntu 15.10 release I'm on is deprecated.
If I read the release notes for Ubuntu correctly the 14.04 LTS release
is supported until April 2019, with binutils 2.24. So I would be
surprised if this won't bite quite a bunch of people down the road.
Regards,
Bjorn
^ permalink raw reply
* [PATCH 1/2] arm: kernel: Add SMC structure parameter
From: Andy Gross @ 2016-12-06 18:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161206115507.GD2498@arm.com>
On Tue, Dec 06, 2016 at 11:55:08AM +0000, Will Deacon wrote:
> Hi Andy,
>
> On Tue, Nov 29, 2016 at 01:44:22AM -0600, Andy Gross wrote:
> > This patch adds a quirk parameter to the arm_smccc_smc call. The quirk
> > structure allows for specialized SMC operations due to SoC specific
> > requirements.
> >
> > This patch also fixes up all the current users of the arm_smccc_smc API.
> >
> > This patch and partial implementation was suggested by Will Deacon.
> >
> > Signed-off-by: Andy Gross <andy.gross@linaro.org>
> > ---
> > arch/arm/kernel/smccc-call.S | 3 ++-
> > arch/arm/mach-artpec/board-artpec6.c | 2 +-
> > arch/arm64/kernel/asm-offsets.c | 7 +++++--
> > arch/arm64/kernel/smccc-call.S | 3 ++-
> > drivers/clk/rockchip/clk-ddr.c | 6 +++---
> > drivers/devfreq/rk3399_dmc.c | 6 +++---
> > drivers/firmware/meson/meson_sm.c | 2 +-
> > drivers/firmware/psci.c | 2 +-
> > drivers/firmware/qcom_scm-64.c | 4 ++--
> > drivers/gpu/drm/mediatek/mtk_hdmi.c | 2 +-
> > include/linux/arm-smccc.h | 18 ++++++++++++++++--
> > 11 files changed, 37 insertions(+), 18 deletions(-)
>
> Thanks for respinning this; I'd forgotten about it!
>
> > diff --git a/arch/arm/kernel/smccc-call.S b/arch/arm/kernel/smccc-call.S
> > index 37669e7..e77950a 100644
> > --- a/arch/arm/kernel/smccc-call.S
> > +++ b/arch/arm/kernel/smccc-call.S
> > @@ -47,7 +47,8 @@ UNWIND( .fnend)
> > /*
> > * void smccc_smc(unsigned long a0, unsigned long a1, unsigned long a2,
> > * unsigned long a3, unsigned long a4, unsigned long a5,
> > - * unsigned long a6, unsigned long a7, struct arm_smccc_res *res)
> > + * unsigned long a6, unsigned long a7, struct arm_smccc_res *res,
> > + * struct arm_smccc_quirk *quirk)
>
> I'd not thought of doing it like this -- I envisaged embedding the quirk
> structure into arm_smccc_res, but this works too. I wonder if we could avoid
> having to pass NULL everywhere if we renamed arm_smccc_{hvc.smc} and added
> a default wrapper around them?
>
> For example, rename arm_smccc_smc to __arm_smccc_smc, add a macro called
> arm_smccc_smc that passes a NULL argument for the quirk, then finally add
> a macro arm_smccc_smc_quirk that takes the additional parameter?
This would work pretty well. I'll send another version with this
implementation.
Regards,
Andy
^ permalink raw reply
* [PATCH v11 7/7] arm: pmu: Add PMU definitions for cores not initially online
From: Jeremy Linton @ 2016-12-06 17:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161206152118.GK2498@arm.com>
Hi,
On 12/06/2016 09:21 AM, Will Deacon wrote:
> On Fri, Dec 02, 2016 at 12:56:01PM -0600, Jeremy Linton wrote:
>> ACPI CPUs aren't associated with a PMU until they have been put
>> online. This means that we potentially have to update a PMU
>> definition the first time a CPU is hot added to the machine.
>>
>> Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
>> ---
>> drivers/perf/arm_pmu.c | 38 ++++++++++++++++++++++++++++++++++++--
>> include/linux/perf/arm_pmu.h | 4 ++++
>> 2 files changed, 40 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/perf/arm_pmu.c b/drivers/perf/arm_pmu.c
>> index fa40294..4abb2fe 100644
>> --- a/drivers/perf/arm_pmu.c
>> +++ b/drivers/perf/arm_pmu.c
>> @@ -711,6 +711,30 @@ static int cpu_pmu_request_irq(struct arm_pmu *cpu_pmu, irq_handler_t handler)
>> return 0;
>> }
>>
>> +static DEFINE_SPINLOCK(arm_pmu_resource_lock);
>
> Why do you need this spinlock? The hotplug notifiers are serialised afaik,
> and you don't take it anywhere else.
Well, I assumed they were serialized, but then I went looking for a
guarantee and couldn't find one specific to the notifiers, even though
the previous lock was removed. Admittedly, I didn't spend too long
looking, but there is a piece missing...
Which is the sync between the hotplug notification and perf start/stop.
By itself that extends this lock into the consumers of the resource
structure. Which might not be the right choice because even without
these ACPI specific bits, simply running a few cpus online/offline while
simultaneously doing something like `perf stat -e cache-misses ls &` in
a loop causes deadlocks/crashes.
That problem doesn't appear to be specific to the ACPI/PMU so I've
stayed away from it in this patch set, although potentially a larger fix
might cover this as well.
^ permalink raw reply
* [PATCHv4 08/10] mm/kasan: Switch to using __pa_symbol and lm_alias
From: Mark Rutland @ 2016-12-06 17:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480445729-27130-9-git-send-email-labbott@redhat.com>
On Tue, Nov 29, 2016 at 10:55:27AM -0800, Laura Abbott wrote:
> __pa_symbol is the correct API to find the physical address of symbols.
> Switch to it to allow for debugging APIs to work correctly. Other
> functions such as p*d_populate may call __pa internally. Ensure that the
> address passed is in the linear region by calling lm_alias.
I've given this a go on Juno with CONFIG_KASAN_INLINE enabled, and
everything seems happy.
We'll need an include of <linux/mm.h> as that appears to be missing. I
guess we're getting lucky with transitive includes. Otherwise this looks
good to me.
With that fixed up:
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Tested-by: Mark Rutland <mark.rutland@arm.com>
Thanks,
Mark.
> Signed-off-by: Laura Abbott <labbott@redhat.com>
> ---
> Pointed out during review/testing of v3.
> ---
> mm/kasan/kasan_init.c | 12 ++++++------
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/mm/kasan/kasan_init.c b/mm/kasan/kasan_init.c
> index 3f9a41c..ff04721 100644
> --- a/mm/kasan/kasan_init.c
> +++ b/mm/kasan/kasan_init.c
> @@ -49,7 +49,7 @@ static void __init zero_pte_populate(pmd_t *pmd, unsigned long addr,
> pte_t *pte = pte_offset_kernel(pmd, addr);
> pte_t zero_pte;
>
> - zero_pte = pfn_pte(PFN_DOWN(__pa(kasan_zero_page)), PAGE_KERNEL);
> + zero_pte = pfn_pte(PFN_DOWN(__pa_symbol(kasan_zero_page)), PAGE_KERNEL);
> zero_pte = pte_wrprotect(zero_pte);
>
> while (addr + PAGE_SIZE <= end) {
> @@ -69,7 +69,7 @@ static void __init zero_pmd_populate(pud_t *pud, unsigned long addr,
> next = pmd_addr_end(addr, end);
>
> if (IS_ALIGNED(addr, PMD_SIZE) && end - addr >= PMD_SIZE) {
> - pmd_populate_kernel(&init_mm, pmd, kasan_zero_pte);
> + pmd_populate_kernel(&init_mm, pmd, lm_alias(kasan_zero_pte));
> continue;
> }
>
> @@ -94,7 +94,7 @@ static void __init zero_pud_populate(pgd_t *pgd, unsigned long addr,
>
> pud_populate(&init_mm, pud, kasan_zero_pmd);
> pmd = pmd_offset(pud, addr);
> - pmd_populate_kernel(&init_mm, pmd, kasan_zero_pte);
> + pmd_populate_kernel(&init_mm, pmd, lm_alias(kasan_zero_pte));
> continue;
> }
>
> @@ -135,11 +135,11 @@ void __init kasan_populate_zero_shadow(const void *shadow_start,
> * puds,pmds, so pgd_populate(), pud_populate()
> * is noops.
> */
> - pgd_populate(&init_mm, pgd, kasan_zero_pud);
> + pgd_populate(&init_mm, pgd, lm_alias(kasan_zero_pud));
> pud = pud_offset(pgd, addr);
> - pud_populate(&init_mm, pud, kasan_zero_pmd);
> + pud_populate(&init_mm, pud, lm_alias(kasan_zero_pmd));
> pmd = pmd_offset(pud, addr);
> - pmd_populate_kernel(&init_mm, pmd, kasan_zero_pte);
> + pmd_populate_kernel(&init_mm, pmd, lm_alias(kasan_zero_pte));
> continue;
> }
>
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH v2 2/2] arm64: Work around broken .inst when defective gas is detected
From: Dave Martin @ 2016-12-06 17:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161206162826.GW1574@e103592.cambridge.arm.com>
On Tue, Dec 06, 2016 at 04:28:26PM +0000, Dave Martin wrote:
> On Tue, Dec 06, 2016 at 03:27:45PM +0000, Marc Zyngier wrote:
> > .inst being largely broken with older binutils, it'd be better not
> > to emit it altogether when detecting such configuration (as it
> > leads to all kind of horrors when using alternatives).
>
> GAS seems to provide few guarantees about the constantness of anything
> other than an expression composed purely of literal constants. So,
> this may rather be lack of a useful feature rather than a bug per se.
>
> > Generalize the __emit_inst macro and use it extensively in
> > asm/sysreg.h, and make it generate a .long when a broken gas is
> > detected. The disassembly will be crap, but at least we can write
> > semi-sane code.
>
> Don't know how much this helps, but if we want decent disassembly then
> one option is to use macros instead of symbols, so that the argument to
> .inst involves only literals after macro expansion.
[...]
It seems that this doesn't solve your problem though ... oh well.
Cheers
---Dave
^ permalink raw reply
* [PATCH 0/2] Hibernate fixes for 'Fix memmap to be initialized for the entire section'
From: Will Deacon @ 2016-12-06 17:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu9AVVPp+UM5pCeYCt4HE-Azijp0iUf0QZv6YKFgAuckYw@mail.gmail.com>
On Mon, Dec 05, 2016 at 03:42:14PM +0000, Ard Biesheuvel wrote:
> On 2 December 2016 at 14:49, James Morse <james.morse@arm.com> wrote:
> > Patch "arm64: mm: Fix memmap to be initialized for the entire section"
> > changes pfn_valid() in a way that breaks hibernate. These patches fix
> > hibernate, and provided struct page's are allocated for nomap pages,
> > can be applied before [0].
> >
> > Hibernate core code belives 'valid' to mean "I can access this". It
> > uses pfn_valid() to test the page if the page is 'valid'.
> >
> > pfn_valid() needs to be changed so that all struct pages in a numa
> > node have the same node-id. Currently 'nomap' pages are skipped, and
> > retain their pre-numa node-ids, which leads to a later BUG_ON().
> >
> > These patches make hibernate's savable_page() take its escape route
> > via 'if (PageReserved(page) && pfn_is_nosave(pfn))'.
> >
>
> This makes me feel slightly uneasy. Robert makes a convincing point,
> but I wonder if we can expect more fallout from the ambiguity of
> pfn_valid(). Now we are not only forced to assign non-existing (as far
> as the OS is concerned) pages to the correct NUMA node, we also need
> to set certain page flags.
Yes, I really don't know how to proceed here. Playing whack-a-mole with
pfn_valid() users doesn't sounds like an improvement on the current
situation to me.
Robert -- if we leave pfn_valid() as it is, would a point-hack to
memmap_init_zone help, or do you anticipate other problems?
Will
^ permalink raw reply
* [PATCH 2/5] ARM: BCM5301X: Specify USB controllers in DT
From: Ray Jui @ 2016-12-06 17:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACna6rw4iY_xhEUyWkGrchs0SOn3nLBKYMuA7qa0UHAbxpGN0A@mail.gmail.com>
On 12/6/2016 9:31 AM, Rafa? Mi?ecki wrote:
> On 6 December 2016 at 18:28, Ray Jui <ray.jui@broadcom.com> wrote:
>> On 12/6/2016 9:17 AM, Rafa? Mi?ecki wrote:
>>> From: Rafa? Mi?ecki <rafal@milecki.pl>
>>>
>>> There are 3 separated controllers, one per USB /standard/. With PHY
>>> drivers in place they can be simply supported with generic drivers.
>>>
>>> Signed-off-by: Rafa? Mi?ecki <rafal@milecki.pl>
>>> ---
>>> arch/arm/boot/dts/bcm5301x.dtsi | 33 ++++++++++++++++++++++++++++++++-
>>> 1 file changed, 32 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm/boot/dts/bcm5301x.dtsi b/arch/arm/boot/dts/bcm5301x.dtsi
>>> index f09a2bb..bfc98d19 100644
>>> --- a/arch/arm/boot/dts/bcm5301x.dtsi
>>> +++ b/arch/arm/boot/dts/bcm5301x.dtsi
>>> @@ -248,8 +248,26 @@
>>>
>>> #address-cells = <1>;
>>> #size-cells = <1>;
>>> + ranges;
>>>
>>> - phys = <&usb2_phy>;
>>> + interrupt-parent = <&gic>;
>>> +
>>> + ohci: ohci at 21000 {
>>> + #usb-cells = <0>;
>>> +
>>> + compatible = "generic-ohci";
>>> + reg = <0x00022000 0x1000>;
>>
>> Your label ohci at 21000 does not match the 'reg' at 0x22000.
>>
>>> + interrupts = <GIC_SPI 79 IRQ_TYPE_LEVEL_HIGH>;
>>> + };
>>> +
>>> + ehci: ehci at 22000 {
>>> + #usb-cells = <0>;
>>> +
>>> + compatible = "generic-ehci";
>>> + reg = <0x00021000 0x1000>;
>>
>> Looks like you got the label of ohci and ehci reversed?
>
> Nice catch, thanks! I'll fix it in V2 (just let me wait a day to see
> if there will be other comments).
>
In V2, please remember to put the nodes in ascending order based on the
base address of the registers, i.e., ehci at 21000, and then followed by
ohci at 22000.
Thanks,
Ray
^ permalink raw reply
* [RFC v3 05/10] iommu: Do not map reserved regions
From: Robin Murphy @ 2016-12-06 17:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479215363-2898-6-git-send-email-eric.auger@redhat.com>
On 15/11/16 13:09, Eric Auger wrote:
> As we introduced IOMMU_RESV_NOMAP and IOMMU_RESV_MSI regions,
> let's prevent those new regions from being mapped.
>
> Signed-off-by: Eric Auger <eric.auger@redhat.com>
> ---
> drivers/iommu/iommu.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> index 6ee529f..a4530ad 100644
> --- a/drivers/iommu/iommu.c
> +++ b/drivers/iommu/iommu.c
> @@ -343,6 +343,9 @@ static int iommu_group_create_direct_mappings(struct iommu_group *group,
> start = ALIGN(entry->start, pg_size);
> end = ALIGN(entry->start + entry->length, pg_size);
>
> + if (entry->prot & IOMMU_RESV_MASK)
This seems to be the only place that this mask is used, and frankly I
think it's less clear than simply "(IOMMU_RESV_NOMAP | IOMMU_RESV_MSI)"
would be, at which point we may as well drop the mask and special value
trickery altogether. Plus, per my previous comment, if it were to be "if
(entry->type != <direct mapped type>)" instead, that's about as obvious
as it can get.
Robin.
> + continue;
> +
> for (addr = start; addr < end; addr += pg_size) {
> phys_addr_t phys_addr;
>
>
^ permalink raw reply
* [PATCH 2/5] ARM: BCM5301X: Specify USB controllers in DT
From: Rafał Miłecki @ 2016-12-06 17:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c721c71c-117f-185d-0544-954981dbcf04@broadcom.com>
On 6 December 2016 at 18:28, Ray Jui <ray.jui@broadcom.com> wrote:
> On 12/6/2016 9:17 AM, Rafa? Mi?ecki wrote:
>> From: Rafa? Mi?ecki <rafal@milecki.pl>
>>
>> There are 3 separated controllers, one per USB /standard/. With PHY
>> drivers in place they can be simply supported with generic drivers.
>>
>> Signed-off-by: Rafa? Mi?ecki <rafal@milecki.pl>
>> ---
>> arch/arm/boot/dts/bcm5301x.dtsi | 33 ++++++++++++++++++++++++++++++++-
>> 1 file changed, 32 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/boot/dts/bcm5301x.dtsi b/arch/arm/boot/dts/bcm5301x.dtsi
>> index f09a2bb..bfc98d19 100644
>> --- a/arch/arm/boot/dts/bcm5301x.dtsi
>> +++ b/arch/arm/boot/dts/bcm5301x.dtsi
>> @@ -248,8 +248,26 @@
>>
>> #address-cells = <1>;
>> #size-cells = <1>;
>> + ranges;
>>
>> - phys = <&usb2_phy>;
>> + interrupt-parent = <&gic>;
>> +
>> + ohci: ohci at 21000 {
>> + #usb-cells = <0>;
>> +
>> + compatible = "generic-ohci";
>> + reg = <0x00022000 0x1000>;
>
> Your label ohci at 21000 does not match the 'reg' at 0x22000.
>
>> + interrupts = <GIC_SPI 79 IRQ_TYPE_LEVEL_HIGH>;
>> + };
>> +
>> + ehci: ehci at 22000 {
>> + #usb-cells = <0>;
>> +
>> + compatible = "generic-ehci";
>> + reg = <0x00021000 0x1000>;
>
> Looks like you got the label of ohci and ehci reversed?
Nice catch, thanks! I'll fix it in V2 (just let me wait a day to see
if there will be other comments).
--
Rafa?
^ permalink raw reply
* [PATCH V6 6/6] iommu/arm-smmu: Set privileged attribute to 'default' instead of 'unprivileged'
From: Will Deacon @ 2016-12-06 17:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480690509-13490-7-git-send-email-sricharan@codeaurora.org>
On Fri, Dec 02, 2016 at 08:25:09PM +0530, Sricharan R wrote:
> Currently the driver sets all the device transactions privileges
> to UNPRIVILEGED, but there are cases where the iommu masters wants
> to isolate privileged supervisor and unprivileged user.
> So don't override the privileged setting to unprivileged, instead
> set it to default as incoming and let it be controlled by the pagetable
> settings.
>
> Signed-off-by: Sricharan R <sricharan@codeaurora.org>
Acked-by: Will Deacon <will.deacon@arm.com>
I'll let you and Robin sort out what you want to do with this series :)
Will
^ permalink raw reply
* [RFC v3 04/10] iommu: iommu_alloc_resv_region
From: Robin Murphy @ 2016-12-06 17:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479215363-2898-5-git-send-email-eric.auger@redhat.com>
On 15/11/16 13:09, Eric Auger wrote:
> Introduce a new helper serving the purpose to allocate a reserved
> region. This will be used in iommu driver implementing reserved
> region callbacks.
>
> Signed-off-by: Eric Auger <eric.auger@redhat.com>
> ---
> drivers/iommu/iommu.c | 16 ++++++++++++++++
> include/linux/iommu.h | 8 ++++++++
> 2 files changed, 24 insertions(+)
>
> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> index c7ed334..6ee529f 100644
> --- a/drivers/iommu/iommu.c
> +++ b/drivers/iommu/iommu.c
> @@ -1562,6 +1562,22 @@ void iommu_put_resv_regions(struct device *dev, struct list_head *list)
> ops->put_resv_regions(dev, list);
> }
>
> +struct iommu_resv_region *iommu_alloc_resv_region(phys_addr_t start,
> + size_t length,
> + unsigned int prot)
> +{
> + struct iommu_resv_region *region;
> +
> + region = kzalloc(sizeof(*region), GFP_KERNEL);
> + if (!region)
> + return NULL;
> +
> + region->start = start;
> + region->length = length;
> + region->prot = prot;
> + return region;
> +}
I think you need an INIT_LIST_HEAD() in here as well, or
CONFIG_DEBUG_LIST might get unhappy about using an uninitialised head later.
Robin.
> +
> /* Request that a device is direct mapped by the IOMMU */
> int iommu_request_dm_for_dev(struct device *dev)
> {
> diff --git a/include/linux/iommu.h b/include/linux/iommu.h
> index 02cf565..0aea877 100644
> --- a/include/linux/iommu.h
> +++ b/include/linux/iommu.h
> @@ -241,6 +241,8 @@ extern void iommu_set_fault_handler(struct iommu_domain *domain,
> extern void iommu_get_resv_regions(struct device *dev, struct list_head *list);
> extern void iommu_put_resv_regions(struct device *dev, struct list_head *list);
> extern int iommu_request_dm_for_dev(struct device *dev);
> +extern struct iommu_resv_region *
> +iommu_alloc_resv_region(phys_addr_t start, size_t length, unsigned int prot);
>
> extern int iommu_attach_group(struct iommu_domain *domain,
> struct iommu_group *group);
> @@ -454,6 +456,12 @@ static inline void iommu_put_resv_regions(struct device *dev,
> {
> }
>
> +static inline struct iommu_resv_region *
> +iommu_alloc_resv_region(phys_addr_t start, size_t length, unsigned int prot)
> +{
> + return NULL;
> +}
> +
> static inline int iommu_request_dm_for_dev(struct device *dev)
> {
> return -ENODEV;
>
^ permalink raw reply
* [RFC v3 02/10] iommu: Rename iommu_dm_regions into iommu_resv_regions
From: Robin Murphy @ 2016-12-06 17:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479215363-2898-3-git-send-email-eric.auger@redhat.com>
On 15/11/16 13:09, Eric Auger wrote:
> We want to extend the callbacks used for dm regions and
> use them for reserved regions. Reserved regions can be
> - directly mapped regions
> - regions that cannot be iommu mapped (PCI host bridge windows, ...)
> - MSI regions (because they belong to another address space or because
> they are not translated by the IOMMU and need special handling)
>
> So let's rename the struct and also the callbacks.
Acked-by: Robin Murphy <robin.murphy@arm.com>
> Signed-off-by: Eric Auger <eric.auger@redhat.com>
> ---
> drivers/iommu/amd_iommu.c | 20 ++++++++++----------
> drivers/iommu/iommu.c | 22 +++++++++++-----------
> include/linux/iommu.h | 29 +++++++++++++++--------------
> 3 files changed, 36 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
> index 754595e..a6c351d 100644
> --- a/drivers/iommu/amd_iommu.c
> +++ b/drivers/iommu/amd_iommu.c
> @@ -3159,8 +3159,8 @@ static bool amd_iommu_capable(enum iommu_cap cap)
> return false;
> }
>
> -static void amd_iommu_get_dm_regions(struct device *dev,
> - struct list_head *head)
> +static void amd_iommu_get_resv_regions(struct device *dev,
> + struct list_head *head)
> {
> struct unity_map_entry *entry;
> int devid;
> @@ -3170,7 +3170,7 @@ static void amd_iommu_get_dm_regions(struct device *dev,
> return;
>
> list_for_each_entry(entry, &amd_iommu_unity_map, list) {
> - struct iommu_dm_region *region;
> + struct iommu_resv_region *region;
>
> if (devid < entry->devid_start || devid > entry->devid_end)
> continue;
> @@ -3193,18 +3193,18 @@ static void amd_iommu_get_dm_regions(struct device *dev,
> }
> }
>
> -static void amd_iommu_put_dm_regions(struct device *dev,
> +static void amd_iommu_put_resv_regions(struct device *dev,
> struct list_head *head)
> {
> - struct iommu_dm_region *entry, *next;
> + struct iommu_resv_region *entry, *next;
>
> list_for_each_entry_safe(entry, next, head, list)
> kfree(entry);
> }
>
> -static void amd_iommu_apply_dm_region(struct device *dev,
> +static void amd_iommu_apply_resv_region(struct device *dev,
> struct iommu_domain *domain,
> - struct iommu_dm_region *region)
> + struct iommu_resv_region *region)
> {
> struct dma_ops_domain *dma_dom = to_dma_ops_domain(to_pdomain(domain));
> unsigned long start, end;
> @@ -3228,9 +3228,9 @@ static void amd_iommu_apply_dm_region(struct device *dev,
> .add_device = amd_iommu_add_device,
> .remove_device = amd_iommu_remove_device,
> .device_group = amd_iommu_device_group,
> - .get_dm_regions = amd_iommu_get_dm_regions,
> - .put_dm_regions = amd_iommu_put_dm_regions,
> - .apply_dm_region = amd_iommu_apply_dm_region,
> + .get_resv_regions = amd_iommu_get_resv_regions,
> + .put_resv_regions = amd_iommu_put_resv_regions,
> + .apply_resv_region = amd_iommu_apply_resv_region,
> .pgsize_bitmap = AMD_IOMMU_PGSIZES,
> };
>
> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> index 9a2f196..c7ed334 100644
> --- a/drivers/iommu/iommu.c
> +++ b/drivers/iommu/iommu.c
> @@ -318,7 +318,7 @@ static int iommu_group_create_direct_mappings(struct iommu_group *group,
> struct device *dev)
> {
> struct iommu_domain *domain = group->default_domain;
> - struct iommu_dm_region *entry;
> + struct iommu_resv_region *entry;
> struct list_head mappings;
> unsigned long pg_size;
> int ret = 0;
> @@ -331,14 +331,14 @@ static int iommu_group_create_direct_mappings(struct iommu_group *group,
> pg_size = 1UL << __ffs(domain->pgsize_bitmap);
> INIT_LIST_HEAD(&mappings);
>
> - iommu_get_dm_regions(dev, &mappings);
> + iommu_get_resv_regions(dev, &mappings);
>
> /* We need to consider overlapping regions for different devices */
> list_for_each_entry(entry, &mappings, list) {
> dma_addr_t start, end, addr;
>
> - if (domain->ops->apply_dm_region)
> - domain->ops->apply_dm_region(dev, domain, entry);
> + if (domain->ops->apply_resv_region)
> + domain->ops->apply_resv_region(dev, domain, entry);
>
> start = ALIGN(entry->start, pg_size);
> end = ALIGN(entry->start + entry->length, pg_size);
> @@ -358,7 +358,7 @@ static int iommu_group_create_direct_mappings(struct iommu_group *group,
> }
>
> out:
> - iommu_put_dm_regions(dev, &mappings);
> + iommu_put_resv_regions(dev, &mappings);
>
> return ret;
> }
> @@ -1546,20 +1546,20 @@ int iommu_domain_set_attr(struct iommu_domain *domain,
> }
> EXPORT_SYMBOL_GPL(iommu_domain_set_attr);
>
> -void iommu_get_dm_regions(struct device *dev, struct list_head *list)
> +void iommu_get_resv_regions(struct device *dev, struct list_head *list)
> {
> const struct iommu_ops *ops = dev->bus->iommu_ops;
>
> - if (ops && ops->get_dm_regions)
> - ops->get_dm_regions(dev, list);
> + if (ops && ops->get_resv_regions)
> + ops->get_resv_regions(dev, list);
> }
>
> -void iommu_put_dm_regions(struct device *dev, struct list_head *list)
> +void iommu_put_resv_regions(struct device *dev, struct list_head *list)
> {
> const struct iommu_ops *ops = dev->bus->iommu_ops;
>
> - if (ops && ops->put_dm_regions)
> - ops->put_dm_regions(dev, list);
> + if (ops && ops->put_resv_regions)
> + ops->put_resv_regions(dev, list);
> }
>
> /* Request that a device is direct mapped by the IOMMU */
> diff --git a/include/linux/iommu.h b/include/linux/iommu.h
> index 436dc21..7f6ebd0 100644
> --- a/include/linux/iommu.h
> +++ b/include/linux/iommu.h
> @@ -118,13 +118,13 @@ enum iommu_attr {
> };
>
> /**
> - * struct iommu_dm_region - descriptor for a direct mapped memory region
> + * struct iommu_resv_region - descriptor for a reserved memory region
> * @list: Linked list pointers
> * @start: System physical start address of the region
> * @length: Length of the region in bytes
> * @prot: IOMMU Protection flags (READ/WRITE/...)
> */
> -struct iommu_dm_region {
> +struct iommu_resv_region {
> struct list_head list;
> phys_addr_t start;
> size_t length;
> @@ -150,9 +150,9 @@ struct iommu_dm_region {
> * @device_group: find iommu group for a particular device
> * @domain_get_attr: Query domain attributes
> * @domain_set_attr: Change domain attributes
> - * @get_dm_regions: Request list of direct mapping requirements for a device
> - * @put_dm_regions: Free list of direct mapping requirements for a device
> - * @apply_dm_region: Temporary helper call-back for iova reserved ranges
> + * @get_resv_regions: Request list of reserved regions for a device
> + * @put_resv_regions: Free list of reserved regions for a device
> + * @apply_resv_region: Temporary helper call-back for iova reserved ranges
> * @domain_window_enable: Configure and enable a particular window for a domain
> * @domain_window_disable: Disable a particular window for a domain
> * @domain_set_windows: Set the number of windows for a domain
> @@ -184,11 +184,12 @@ struct iommu_ops {
> int (*domain_set_attr)(struct iommu_domain *domain,
> enum iommu_attr attr, void *data);
>
> - /* Request/Free a list of direct mapping requirements for a device */
> - void (*get_dm_regions)(struct device *dev, struct list_head *list);
> - void (*put_dm_regions)(struct device *dev, struct list_head *list);
> - void (*apply_dm_region)(struct device *dev, struct iommu_domain *domain,
> - struct iommu_dm_region *region);
> + /* Request/Free a list of reserved regions for a device */
> + void (*get_resv_regions)(struct device *dev, struct list_head *list);
> + void (*put_resv_regions)(struct device *dev, struct list_head *list);
> + void (*apply_resv_region)(struct device *dev,
> + struct iommu_domain *domain,
> + struct iommu_resv_region *region);
>
> /* Window handling functions */
> int (*domain_window_enable)(struct iommu_domain *domain, u32 wnd_nr,
> @@ -233,8 +234,8 @@ extern size_t default_iommu_map_sg(struct iommu_domain *domain, unsigned long io
> extern void iommu_set_fault_handler(struct iommu_domain *domain,
> iommu_fault_handler_t handler, void *token);
>
> -extern void iommu_get_dm_regions(struct device *dev, struct list_head *list);
> -extern void iommu_put_dm_regions(struct device *dev, struct list_head *list);
> +extern void iommu_get_resv_regions(struct device *dev, struct list_head *list);
> +extern void iommu_put_resv_regions(struct device *dev, struct list_head *list);
> extern int iommu_request_dm_for_dev(struct device *dev);
>
> extern int iommu_attach_group(struct iommu_domain *domain,
> @@ -439,12 +440,12 @@ static inline void iommu_set_fault_handler(struct iommu_domain *domain,
> {
> }
>
> -static inline void iommu_get_dm_regions(struct device *dev,
> +static inline void iommu_get_resv_regions(struct device *dev,
> struct list_head *list)
> {
> }
>
> -static inline void iommu_put_dm_regions(struct device *dev,
> +static inline void iommu_put_resv_regions(struct device *dev,
> struct list_head *list)
> {
> }
>
^ permalink raw reply
* [PATCH RFC] drm/sun4i: rgb: Add 5% tolerance to dot clock frequency check
From: Maxime Ripard @ 2016-12-06 17:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161124112231.4297-1-wens@csie.org>
On Thu, Nov 24, 2016 at 07:22:31PM +0800, Chen-Yu Tsai wrote:
> The panels shipped with Allwinner devices are very "generic", i.e.
> they do not have model numbers or reliable sources of information
> for the timings (that we know of) other than the fex files shipped
> on them. The dot clock frequency provided in the fex files have all
> been rounded to the nearest MHz, as that is the unit used in them.
>
> We were using the simple panel "urt,umsh-8596md-t" as a substitute
> for the A13 Q8 tablets in the absence of a specific model for what
> may be many different but otherwise timing compatible panels. This
> was usable without any visual artifacts or side effects, until the
> dot clock rate check was added in commit bb43d40d7c83 ("drm/sun4i:
> rgb: Validate the clock rate").
>
> The reason this check fails is because the dotclock frequency for
> this model is 33.26 MHz, which is not achievable with our dot clock
> hardware, and the rate returned by clk_round_rate deviates slightly,
> causing the driver to reject the display mode.
>
> The LCD panels have some tolerance on the dot clock frequency, even
> if it's not specified in their datasheets.
>
> This patch adds a 5% tolerence to the dot clock check.
As we discussed already, I really believe this is just as arbitrary as
the current behaviour.
Some panels require an exact frequency, some have a minimal frequency
but no maximum, some have a maximum frequency but no minimal, and I
guess most of them deviates by how much exactly they can take (and
possibly can take more easily a higher frequency, but are less
tolerant if you take a frequency lower than the nominal.
And we cannot remove that check entirely, since some bridges will
report out of range frequencies for higher modes that we know we
cannot reach.
We could just try to see if the screen pixel clock frequency is out of
the pixel clock range we can generate, but then we will loop back on
how much out of range is it exactly, and is it within the screen
tolerancy.
We have an API to deal with the panel tolerancies in the DRM panel
framework, we can (and should) use it.
I'm not sure how others usually deal with this though. I think I
remember Eric telling me that for the RPi they just adjusted the
timings a bit, but they only really had a single panel to deal with.
Daniel, Eric, Laurent, Sean? Any ideas?
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161206/ca91b559/attachment.sig>
^ permalink raw reply
* [PATCH 2/5] ARM: BCM5301X: Specify USB controllers in DT
From: Ray Jui @ 2016-12-06 17:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161206171714.22738-2-zajec5@gmail.com>
On 12/6/2016 9:17 AM, Rafa? Mi?ecki wrote:
> From: Rafa? Mi?ecki <rafal@milecki.pl>
>
> There are 3 separated controllers, one per USB /standard/. With PHY
> drivers in place they can be simply supported with generic drivers.
>
> Signed-off-by: Rafa? Mi?ecki <rafal@milecki.pl>
> ---
> arch/arm/boot/dts/bcm5301x.dtsi | 33 ++++++++++++++++++++++++++++++++-
> 1 file changed, 32 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/bcm5301x.dtsi b/arch/arm/boot/dts/bcm5301x.dtsi
> index f09a2bb..bfc98d19 100644
> --- a/arch/arm/boot/dts/bcm5301x.dtsi
> +++ b/arch/arm/boot/dts/bcm5301x.dtsi
> @@ -248,8 +248,26 @@
>
> #address-cells = <1>;
> #size-cells = <1>;
> + ranges;
>
> - phys = <&usb2_phy>;
> + interrupt-parent = <&gic>;
> +
> + ohci: ohci at 21000 {
> + #usb-cells = <0>;
> +
> + compatible = "generic-ohci";
> + reg = <0x00022000 0x1000>;
Your label ohci at 21000 does not match the 'reg' at 0x22000.
> + interrupts = <GIC_SPI 79 IRQ_TYPE_LEVEL_HIGH>;
> + };
> +
> + ehci: ehci at 22000 {
> + #usb-cells = <0>;
> +
> + compatible = "generic-ehci";
> + reg = <0x00021000 0x1000>;
Looks like you got the label of ohci and ehci reversed?
> + interrupts = <GIC_SPI 79 IRQ_TYPE_LEVEL_HIGH>;
> + phys = <&usb2_phy>;
> + };
> };
>
> usb3: usb3 at 23000 {
> @@ -257,6 +275,19 @@
>
> #address-cells = <1>;
> #size-cells = <1>;
> + ranges;
> +
> + interrupt-parent = <&gic>;
> +
> + xhci: xhci at 23000 {
> + #usb-cells = <0>;
> +
> + compatible = "generic-xhci";
> + reg = <0x00023000 0x1000>;
> + interrupts = <GIC_SPI 80 IRQ_TYPE_LEVEL_HIGH>;
> + phys = <&usb3_phy>;
> + phy-names = "usb";
> + };
> };
>
> spi at 29000 {
>
^ permalink raw reply
* [RFC v3 03/10] iommu: Add new reserved IOMMU attributes
From: Robin Murphy @ 2016-12-06 17:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479215363-2898-4-git-send-email-eric.auger@redhat.com>
On 15/11/16 13:09, Eric Auger wrote:
> IOMMU_RESV_NOMAP is used to tag reserved IOVAs that are not
> supposed to be IOMMU mapped. IOMMU_RESV_MSI tags IOVAs
> corresponding to MSIs that need to be IOMMU mapped.
>
> IOMMU_RESV_MASK allows to check if the IOVA is reserved.
>
> Signed-off-by: Eric Auger <eric.auger@redhat.com>
> ---
> include/linux/iommu.h | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/include/linux/iommu.h b/include/linux/iommu.h
> index 7f6ebd0..02cf565 100644
> --- a/include/linux/iommu.h
> +++ b/include/linux/iommu.h
> @@ -32,6 +32,10 @@
> #define IOMMU_NOEXEC (1 << 3)
> #define IOMMU_MMIO (1 << 4) /* e.g. things like MSI doorbells */
>
> +#define IOMMU_RESV_MASK 0x300 /* Reserved IOVA mask */
> +#define IOMMU_RESV_NOMAP (1 << 8) /* IOVA that cannot be mapped */
> +#define IOMMU_RESV_MSI (1 << 9) /* MSI region transparently mapped */
It feels a bit grotty encoding these in prot - NOMAP sort of fits, but
MSI really is something else entirely. On reflection I think a separate
iommu_resv_region::type field would be better, particularly as it's
something we might potentially want to expose via the sysfs entry.
Robin.
> +
> struct iommu_ops;
> struct iommu_group;
> struct bus_type;
>
^ permalink raw reply
* [PATCHv4 08/10] mm/kasan: Switch to using __pa_symbol and lm_alias
From: Mark Rutland @ 2016-12-06 17:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2f3ac043-c4cc-5c5a-8ac7-1396b6bb193f@virtuozzo.com>
On Thu, Dec 01, 2016 at 02:36:05PM +0300, Andrey Ryabinin wrote:
> On 11/29/2016 09:55 PM, Laura Abbott wrote:
> > __pa_symbol is the correct API to find the physical address of symbols.
> > Switch to it to allow for debugging APIs to work correctly.
>
> But __pa() is correct for symbols. I see how __pa_symbol() might be a little
> faster than __pa(), but there is nothing wrong in using __pa() on symbols.
While it's true today that __pa() works on symbols, this is for
pragmatic reasons (allowing existing code to work until it is all
cleaned up), and __pa_symbol() is the correct API to use.
Relying on this means that __pa() can't be optimised for the (vastly
common) case of translating linear map addresses.
Consistent use of __pa_symbol() will allow for subsequent optimisation
of __pa() in the common case, in adition to being necessary for arm64's
DEBUG_VIRTUAL.
> > Other functions such as p*d_populate may call __pa internally.
> > Ensure that the address passed is in the linear region by calling
> > lm_alias.
>
> Why it should be linear mapping address? __pa() translates kernel
> image address just fine.
As above, while that's true today, but is something that we wish to
change.
> Generated code is probably worse too.
Even if that is the case, given this is code run once at boot on a debug
build, I think it's outweighed by the gain from DEBUG_VIRTUAL, and as a
step towards optimising __pa().
Thanks,
Mark.
^ permalink raw reply
* [PATCH v2] arm64: KVM: pmu: Reset PMSELR_EL0.SEL to a sane value before entering the guest
From: Marc Zyngier @ 2016-12-06 17:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161206162918.GE4816@cbox>
On 06/12/16 16:29, Christoffer Dall wrote:
> On Tue, Dec 06, 2016 at 02:56:50PM +0000, Marc Zyngier wrote:
>> The ARMv8 architecture allows the cycle counter to be configured
>> by setting PMSELR_EL0.SEL==0x1f and then accessing PMXEVTYPER_EL0,
>> hence accessing PMCCFILTR_EL0. But it disallows the use of
>> PMSELR_EL0.SEL==0x1f to access the cycle counter itself through
>> PMXEVCNTR_EL0.
>>
>> Linux itself doesn't violate this rule, but we may end up with
>> PMSELR_EL0.SEL being set to 0x1f when we enter a guest. If that
>> guest accesses PMXEVCNTR_EL0, the access may UNDEF at EL1,
>> despite the guest not having done anything wrong.
>>
>> In order to avoid this unfortunate course of events (haha!), let's
>
> I actually did find this funny.
>
>> sanitize PMSELR_EL0 on guest entry. This ensures that the guest
>> won't explode unexpectedly.
>>
>> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
>> ---
>> This is another approach to fix this issue, this time nuking PMSELR_EL0
>> on guest entry instead of relying on perf not to clobber the register.
>>
>> Tested on v4.9-rc8 with a Rev A3 X-Gene.
>>
>> arch/arm64/kvm/hyp/switch.c | 8 +++++++-
>> 1 file changed, 7 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/kvm/hyp/switch.c b/arch/arm64/kvm/hyp/switch.c
>> index 83037cd..3b7cfbd 100644
>> --- a/arch/arm64/kvm/hyp/switch.c
>> +++ b/arch/arm64/kvm/hyp/switch.c
>> @@ -85,7 +85,13 @@ static void __hyp_text __activate_traps(struct kvm_vcpu *vcpu)
>> write_sysreg(val, hcr_el2);
>> /* Trap on AArch32 cp15 c15 accesses (EL1 or EL0) */
>> write_sysreg(1 << 15, hstr_el2);
>> - /* Make sure we trap PMU access from EL0 to EL2 */
>> + /*
>> + * Make sure we trap PMU access from EL0 to EL2. Also sanitize
>> + * PMSELR_EL0 to make sure it never contains the cycle
>> + * counter, which could make a PMXEVCNTR_EL0 access UNDEF.
>> + */
>> + if (vcpu->arch.mdcr_el2 & MDCR_EL2_HPMN_MASK)
>> + write_sysreg(0, pmselr_el0);
>
> I'm a bit confused about how we use the HPMN field. This value is
> always set to the full number of counters available on the system and
> never modified by the guest, right? So this is in essence a check that
> says 'do you have any performance counters, then make sure accesses
> don't undef to el1 instead of trapping to el2', but then my question is,
> why not just set pmselr_el0 to zero unconditionally, because in the case
> where (vcpu->arch.mdcr_el2 & MDCR_EL2_HPMN_MASK) == 0, it means we have
> no counters, which we'll have exposed to the guest anyhow, and we should
> undef at el1 in the guest, or did I get this completely wrong (like
> everything else today)?
Yeah, that's probably the best course of action. If the guest does
something silly, tough. I'll drop the test and repost the thing.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH 5/5] ARM: BCM53573: Specify USB ports of on-SoC controllers
From: Rafał Miłecki @ 2016-12-06 17:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161206171714.22738-1-zajec5@gmail.com>
From: Rafa? Mi?ecki <rafal@milecki.pl>
Broadcom OHCI and EHCI controllers always have 2 ports each on the root
hub. Describe them in DT to allow specifying extra info or referencing
port nodes.
Signed-off-by: Rafa? Mi?ecki <rafal@milecki.pl>
---
arch/arm/boot/dts/bcm53573.dtsi | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
diff --git a/arch/arm/boot/dts/bcm53573.dtsi b/arch/arm/boot/dts/bcm53573.dtsi
index e2c496a..2da04d0 100644
--- a/arch/arm/boot/dts/bcm53573.dtsi
+++ b/arch/arm/boot/dts/bcm53573.dtsi
@@ -124,6 +124,17 @@
reg = <0x4000 0x1000>;
interrupt-parent = <&gic>;
interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ehci_port1: port at 1 {
+ reg = <1>;
+ };
+
+ ehci_port2: port at 2 {
+ reg = <2>;
+ };
};
ohci: ohci at d000 {
@@ -133,6 +144,17 @@
reg = <0xd000 0x1000>;
interrupt-parent = <&gic>;
interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ohci_port1: port at 1 {
+ reg = <1>;
+ };
+
+ ohci_port2: port at 2 {
+ reg = <2>;
+ };
};
};
--
2.10.1
^ permalink raw reply related
* [PATCH 4/5] ARM: BCM5301X: Specify all RAM by including extra block
From: Rafał Miłecki @ 2016-12-06 17:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161206171714.22738-1-zajec5@gmail.com>
From: Rafa? Mi?ecki <rafal@milecki.pl>
So far we were specifying only the first block which is always limited
up to 128 MiB. There are many devices with 256 MiB and few with 512 MiB.
Signed-off-by: Rafa? Mi?ecki <rafal@milecki.pl>
---
arch/arm/boot/dts/bcm4708-asus-rt-ac56u.dts | 3 ++-
arch/arm/boot/dts/bcm4708-asus-rt-ac68u.dts | 3 ++-
arch/arm/boot/dts/bcm4708-buffalo-wzr-1750dhp.dts | 3 ++-
arch/arm/boot/dts/bcm4708-netgear-r6250.dts | 3 ++-
arch/arm/boot/dts/bcm4708-netgear-r6300-v2.dts | 3 ++-
arch/arm/boot/dts/bcm4708-smartrg-sr400ac.dts | 3 ++-
arch/arm/boot/dts/bcm47081-asus-rt-n18u.dts | 3 ++-
arch/arm/boot/dts/bcm47081-buffalo-wzr-600dhp2.dts | 3 ++-
arch/arm/boot/dts/bcm47081-buffalo-wzr-900dhp.dts | 3 ++-
arch/arm/boot/dts/bcm4709-asus-rt-ac87u.dts | 3 ++-
arch/arm/boot/dts/bcm4709-buffalo-wxr-1900dhp.dts | 3 ++-
arch/arm/boot/dts/bcm4709-netgear-r7000.dts | 3 ++-
arch/arm/boot/dts/bcm4709-netgear-r8000.dts | 3 ++-
arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts | 3 ++-
arch/arm/boot/dts/bcm47094-netgear-r8500.dts | 3 ++-
15 files changed, 30 insertions(+), 15 deletions(-)
diff --git a/arch/arm/boot/dts/bcm4708-asus-rt-ac56u.dts b/arch/arm/boot/dts/bcm4708-asus-rt-ac56u.dts
index 112a5a8..d241cee 100644
--- a/arch/arm/boot/dts/bcm4708-asus-rt-ac56u.dts
+++ b/arch/arm/boot/dts/bcm4708-asus-rt-ac56u.dts
@@ -21,7 +21,8 @@
};
memory {
- reg = <0x00000000 0x08000000>;
+ reg = <0x00000000 0x08000000
+ 0x88000000 0x08000000>;
};
leds {
diff --git a/arch/arm/boot/dts/bcm4708-asus-rt-ac68u.dts b/arch/arm/boot/dts/bcm4708-asus-rt-ac68u.dts
index 3600f56..b0e6204 100644
--- a/arch/arm/boot/dts/bcm4708-asus-rt-ac68u.dts
+++ b/arch/arm/boot/dts/bcm4708-asus-rt-ac68u.dts
@@ -21,7 +21,8 @@
};
memory {
- reg = <0x00000000 0x08000000>;
+ reg = <0x00000000 0x08000000
+ 0x88000000 0x08000000>;
};
leds {
diff --git a/arch/arm/boot/dts/bcm4708-buffalo-wzr-1750dhp.dts b/arch/arm/boot/dts/bcm4708-buffalo-wzr-1750dhp.dts
index d49afec0..c9ba6b9 100644
--- a/arch/arm/boot/dts/bcm4708-buffalo-wzr-1750dhp.dts
+++ b/arch/arm/boot/dts/bcm4708-buffalo-wzr-1750dhp.dts
@@ -21,7 +21,8 @@
};
memory {
- reg = <0x00000000 0x08000000>;
+ reg = <0x00000000 0x08000000
+ 0x88000000 0x18000000>;
};
spi {
diff --git a/arch/arm/boot/dts/bcm4708-netgear-r6250.dts b/arch/arm/boot/dts/bcm4708-netgear-r6250.dts
index 8519548..b9f66c0 100644
--- a/arch/arm/boot/dts/bcm4708-netgear-r6250.dts
+++ b/arch/arm/boot/dts/bcm4708-netgear-r6250.dts
@@ -21,7 +21,8 @@
};
memory {
- reg = <0x00000000 0x08000000>;
+ reg = <0x00000000 0x08000000
+ 0x88000000 0x08000000>;
};
leds {
diff --git a/arch/arm/boot/dts/bcm4708-netgear-r6300-v2.dts b/arch/arm/boot/dts/bcm4708-netgear-r6300-v2.dts
index 6229ef2..ae0199f 100644
--- a/arch/arm/boot/dts/bcm4708-netgear-r6300-v2.dts
+++ b/arch/arm/boot/dts/bcm4708-netgear-r6300-v2.dts
@@ -21,7 +21,8 @@
};
memory {
- reg = <0x00000000 0x08000000>;
+ reg = <0x00000000 0x08000000
+ 0x88000000 0x08000000>;
};
leds {
diff --git a/arch/arm/boot/dts/bcm4708-smartrg-sr400ac.dts b/arch/arm/boot/dts/bcm4708-smartrg-sr400ac.dts
index 74cfcd3..36b628b1 100644
--- a/arch/arm/boot/dts/bcm4708-smartrg-sr400ac.dts
+++ b/arch/arm/boot/dts/bcm4708-smartrg-sr400ac.dts
@@ -21,7 +21,8 @@
};
memory {
- reg = <0x00000000 0x08000000>;
+ reg = <0x00000000 0x08000000
+ 0x88000000 0x08000000>;
};
leds {
diff --git a/arch/arm/boot/dts/bcm47081-asus-rt-n18u.dts b/arch/arm/boot/dts/bcm47081-asus-rt-n18u.dts
index 71b98cf..db8608b 100644
--- a/arch/arm/boot/dts/bcm47081-asus-rt-n18u.dts
+++ b/arch/arm/boot/dts/bcm47081-asus-rt-n18u.dts
@@ -21,7 +21,8 @@
};
memory {
- reg = <0x00000000 0x08000000>;
+ reg = <0x00000000 0x08000000
+ 0x88000000 0x08000000>;
};
leds {
diff --git a/arch/arm/boot/dts/bcm47081-buffalo-wzr-600dhp2.dts b/arch/arm/boot/dts/bcm47081-buffalo-wzr-600dhp2.dts
index 2922536..d51586d 100644
--- a/arch/arm/boot/dts/bcm47081-buffalo-wzr-600dhp2.dts
+++ b/arch/arm/boot/dts/bcm47081-buffalo-wzr-600dhp2.dts
@@ -21,7 +21,8 @@
};
memory {
- reg = <0x00000000 0x08000000>;
+ reg = <0x00000000 0x08000000
+ 0x88000000 0x08000000>;
};
spi {
diff --git a/arch/arm/boot/dts/bcm47081-buffalo-wzr-900dhp.dts b/arch/arm/boot/dts/bcm47081-buffalo-wzr-900dhp.dts
index 184fd92..de041b8 100644
--- a/arch/arm/boot/dts/bcm47081-buffalo-wzr-900dhp.dts
+++ b/arch/arm/boot/dts/bcm47081-buffalo-wzr-900dhp.dts
@@ -21,7 +21,8 @@
};
memory {
- reg = <0x00000000 0x08000000>;
+ reg = <0x00000000 0x08000000
+ 0x88000000 0x08000000>;
};
gpio-keys {
diff --git a/arch/arm/boot/dts/bcm4709-asus-rt-ac87u.dts b/arch/arm/boot/dts/bcm4709-asus-rt-ac87u.dts
index eac0f52..eaca687 100644
--- a/arch/arm/boot/dts/bcm4709-asus-rt-ac87u.dts
+++ b/arch/arm/boot/dts/bcm4709-asus-rt-ac87u.dts
@@ -21,7 +21,8 @@
};
memory {
- reg = <0x00000000 0x08000000>;
+ reg = <0x00000000 0x08000000
+ 0x88000000 0x08000000>;
};
leds {
diff --git a/arch/arm/boot/dts/bcm4709-buffalo-wxr-1900dhp.dts b/arch/arm/boot/dts/bcm4709-buffalo-wxr-1900dhp.dts
index aab39c9..b32957c 100644
--- a/arch/arm/boot/dts/bcm4709-buffalo-wxr-1900dhp.dts
+++ b/arch/arm/boot/dts/bcm4709-buffalo-wxr-1900dhp.dts
@@ -21,7 +21,8 @@
};
memory {
- reg = <0x00000000 0x08000000>;
+ reg = <0x00000000 0x08000000
+ 0x88000000 0x18000000>;
};
leds {
diff --git a/arch/arm/boot/dts/bcm4709-netgear-r7000.dts b/arch/arm/boot/dts/bcm4709-netgear-r7000.dts
index 7ab1176..f459a98 100644
--- a/arch/arm/boot/dts/bcm4709-netgear-r7000.dts
+++ b/arch/arm/boot/dts/bcm4709-netgear-r7000.dts
@@ -21,7 +21,8 @@
};
memory {
- reg = <0x00000000 0x08000000>;
+ reg = <0x00000000 0x08000000
+ 0x88000000 0x08000000>;
};
leds {
diff --git a/arch/arm/boot/dts/bcm4709-netgear-r8000.dts b/arch/arm/boot/dts/bcm4709-netgear-r8000.dts
index 56d38a3..cd13534 100644
--- a/arch/arm/boot/dts/bcm4709-netgear-r8000.dts
+++ b/arch/arm/boot/dts/bcm4709-netgear-r8000.dts
@@ -21,7 +21,8 @@
};
memory {
- reg = <0x00000000 0x08000000>;
+ reg = <0x00000000 0x08000000
+ 0x88000000 0x08000000>;
};
leds {
diff --git a/arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts b/arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts
index 7fb9270..64ded76 100644
--- a/arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts
+++ b/arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts
@@ -21,7 +21,8 @@
};
memory {
- reg = <0x00000000 0x08000000>;
+ reg = <0x00000000 0x08000000
+ 0x88000000 0x08000000>;
};
nand: nand at 18028000 {
diff --git a/arch/arm/boot/dts/bcm47094-netgear-r8500.dts b/arch/arm/boot/dts/bcm47094-netgear-r8500.dts
index 7ecd57c..600795e 100644
--- a/arch/arm/boot/dts/bcm47094-netgear-r8500.dts
+++ b/arch/arm/boot/dts/bcm47094-netgear-r8500.dts
@@ -18,7 +18,8 @@
};
memory {
- reg = <0x00000000 0x08000000>;
+ reg = <0x00000000 0x08000000
+ 0x88000000 0x18000000>;
};
leds {
--
2.10.1
^ permalink raw reply related
* [PATCH 3/5] ARM: BCM5301X: Set GPIO enabling USB power on Netgear R7000
From: Rafał Miłecki @ 2016-12-06 17:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161206171714.22738-1-zajec5@gmail.com>
There is one GPIO controlling power for both USB ports.
Signed-off-by: Rafa? Mi?ecki <zajec5@gmail.com>
Signed-off-by: Rafa? Mi?ecki <rafal@milecki.pl>
---
arch/arm/boot/dts/bcm4709-netgear-r7000.dts | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/bcm4709-netgear-r7000.dts b/arch/arm/boot/dts/bcm4709-netgear-r7000.dts
index 0225d82..7ab1176 100644
--- a/arch/arm/boot/dts/bcm4709-netgear-r7000.dts
+++ b/arch/arm/boot/dts/bcm4709-netgear-r7000.dts
@@ -100,3 +100,11 @@
};
};
};
+
+&usb2 {
+ vcc-gpio = <&chipcommon 0 GPIO_ACTIVE_HIGH>;
+};
+
+&usb3 {
+ vcc-gpio = <&chipcommon 0 GPIO_ACTIVE_HIGH>;
+};
--
2.10.1
^ permalink raw reply related
* [PATCH 2/5] ARM: BCM5301X: Specify USB controllers in DT
From: Rafał Miłecki @ 2016-12-06 17:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161206171714.22738-1-zajec5@gmail.com>
From: Rafa? Mi?ecki <rafal@milecki.pl>
There are 3 separated controllers, one per USB /standard/. With PHY
drivers in place they can be simply supported with generic drivers.
Signed-off-by: Rafa? Mi?ecki <rafal@milecki.pl>
---
arch/arm/boot/dts/bcm5301x.dtsi | 33 ++++++++++++++++++++++++++++++++-
1 file changed, 32 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/bcm5301x.dtsi b/arch/arm/boot/dts/bcm5301x.dtsi
index f09a2bb..bfc98d19 100644
--- a/arch/arm/boot/dts/bcm5301x.dtsi
+++ b/arch/arm/boot/dts/bcm5301x.dtsi
@@ -248,8 +248,26 @@
#address-cells = <1>;
#size-cells = <1>;
+ ranges;
- phys = <&usb2_phy>;
+ interrupt-parent = <&gic>;
+
+ ohci: ohci at 21000 {
+ #usb-cells = <0>;
+
+ compatible = "generic-ohci";
+ reg = <0x00022000 0x1000>;
+ interrupts = <GIC_SPI 79 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
+ ehci: ehci at 22000 {
+ #usb-cells = <0>;
+
+ compatible = "generic-ehci";
+ reg = <0x00021000 0x1000>;
+ interrupts = <GIC_SPI 79 IRQ_TYPE_LEVEL_HIGH>;
+ phys = <&usb2_phy>;
+ };
};
usb3: usb3 at 23000 {
@@ -257,6 +275,19 @@
#address-cells = <1>;
#size-cells = <1>;
+ ranges;
+
+ interrupt-parent = <&gic>;
+
+ xhci: xhci at 23000 {
+ #usb-cells = <0>;
+
+ compatible = "generic-xhci";
+ reg = <0x00023000 0x1000>;
+ interrupts = <GIC_SPI 80 IRQ_TYPE_LEVEL_HIGH>;
+ phys = <&usb3_phy>;
+ phy-names = "usb";
+ };
};
spi at 29000 {
--
2.10.1
^ permalink raw reply related
* [PATCH 1/5] ARM: BCM5301X: Fix LAN LED labels for Luxul XWR-3100
From: Rafał Miłecki @ 2016-12-06 17:17 UTC (permalink / raw)
To: linux-arm-kernel
From: Rafa? Mi?ecki <rafal@milecki.pl>
They were named incorrectly most likely due to copy & paste mistake.
Signed-off-by: Rafa? Mi?ecki <rafal@milecki.pl>
---
arch/arm/boot/dts/bcm47094-luxul-xwr-3100.dts | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/bcm47094-luxul-xwr-3100.dts b/arch/arm/boot/dts/bcm47094-luxul-xwr-3100.dts
index 2f4a651..93cc91d 100644
--- a/arch/arm/boot/dts/bcm47094-luxul-xwr-3100.dts
+++ b/arch/arm/boot/dts/bcm47094-luxul-xwr-3100.dts
@@ -31,13 +31,13 @@
};
lan3 {
- label = "bcm53xx:green:lan1";
+ label = "bcm53xx:green:lan3";
gpios = <&chipcommon 1 GPIO_ACTIVE_LOW>;
linux,default-trigger = "default-off";
};
lan4 {
- label = "bcm53xx:green:lan0";
+ label = "bcm53xx:green:lan4";
gpios = <&chipcommon 2 GPIO_ACTIVE_LOW>;
linux,default-trigger = "default-off";
};
@@ -49,7 +49,7 @@
};
lan1 {
- label = "bcm53xx:green:lan3";
+ label = "bcm53xx:green:lan1";
gpios = <&chipcommon 4 GPIO_ACTIVE_LOW>;
linux,default-trigger = "default-off";
};
--
2.10.1
^ permalink raw reply related
* [PATCH v3] mach-omap2: fixing wrong strcat for Non-NULL terminated string
From: Tony Lindgren @ 2016-12-06 17:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480915633-16284-1-git-send-email-maninder1.s@samsung.com>
* Maninder Singh <maninder1.s@samsung.com> [161204 21:32]:
> Issue caught with static analysis tool:
> "Dangerous usage of 'name' (strncpy doesn't always 0-terminate it)"
>
> Use strlcpy _includes_ the NUL terminator, and strlcat() which ensures
> that it won't overflow the buffer.
>
> Reported-by: Maninder Singh <maninder1.s@samsung.com>
> Signed-off-by: Vaneet Narang <v.narang@samsung.com>
> Signed-off-by: Russell King <linux@armlinux.org.uk>
I think the above should have been just:
Cc: Russell King <linux@armlinux.org.uk>
Can you please check and resend with Russell in Cc?
Regards,
Tony
> ---
> v1 -> v2: changed strncpy to strlcpy
> v2 -> v3: use of strlcat as suggested by Russell to
> make change clearer and simpler.
>
> arch/arm/mach-omap2/omap_hwmod.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
> index 759e1d4..e8b9887 100644
> --- a/arch/arm/mach-omap2/omap_hwmod.c
> +++ b/arch/arm/mach-omap2/omap_hwmod.c
> @@ -741,14 +741,14 @@ static int _init_main_clk(struct omap_hwmod *oh)
> int ret = 0;
> char name[MOD_CLK_MAX_NAME_LEN];
> struct clk *clk;
> + static const char modck[] = "_mod_ck";
>
> - /* +7 magic comes from '_mod_ck' suffix */
> - if (strlen(oh->name) + 7 > MOD_CLK_MAX_NAME_LEN)
> + if (strlen(oh->name) >= MOD_CLK_MAX_NAME_LEN - strlen(modck))
> pr_warn("%s: warning: cropping name for %s\n", __func__,
> oh->name);
>
> - strncpy(name, oh->name, MOD_CLK_MAX_NAME_LEN - 7);
> - strcat(name, "_mod_ck");
> + strlcpy(name, oh->name, MOD_CLK_MAX_NAME_LEN - strlen(modck));
> + strlcat(name, modck, MOD_CLK_MAX_NAME_LEN);
>
> clk = clk_get(NULL, name);
> if (!IS_ERR(clk)) {
> --
> 1.9.1
>
^ permalink raw reply
* [PATCH 7/7] arm: Add livepatch necessary arch selects into Kconfig
From: Abel Vesa @ 2016-12-06 17:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481043967-15602-1-git-send-email-abelvesa@linux.com>
This adds HAVE_LIVEPATCH, MODULES_USE_ELF_RELA and HAVE_LIVEPATCH
to arm Kconfig.
Signed-off-by: Abel Vesa <abelvesa@linux.com>
---
arch/arm/Kconfig | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 186c4c2..f4e9ace 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -50,6 +50,7 @@ config ARM
select HAVE_DMA_API_DEBUG
select HAVE_DMA_CONTIGUOUS if MMU
select HAVE_DYNAMIC_FTRACE if (!XIP_KERNEL) && !CPU_ENDIAN_BE32 && MMU
+ select HAVE_DYNAMIC_FTRACE_WITH_REGS
select HAVE_EFFICIENT_UNALIGNED_ACCESS if (CPU_V6 || CPU_V6K || CPU_V7) && MMU
select HAVE_EXIT_THREAD
select HAVE_FTRACE_MCOUNT_RECORD if (!XIP_KERNEL)
@@ -67,6 +68,7 @@ config ARM
select HAVE_KERNEL_XZ
select HAVE_KPROBES if !XIP_KERNEL && !CPU_ENDIAN_BE32 && !CPU_V7M
select HAVE_KRETPROBES if (HAVE_KPROBES)
+ select HAVE_LIVEPATCH
select HAVE_MEMBLOCK
select HAVE_MOD_ARCH_SPECIFIC
select HAVE_NMI
@@ -82,6 +84,7 @@ config ARM
select HAVE_VIRT_CPU_ACCOUNTING_GEN
select IRQ_FORCED_THREADING
select MODULES_USE_ELF_REL
+ select MODULES_USE_ELF_RELA
select NO_BOOTMEM
select OF_EARLY_FLATTREE if OF
select OF_RESERVED_MEM if OF
@@ -1841,6 +1844,7 @@ config XEN
help
Say Y if you want to run Linux in a Virtual Machine on Xen on ARM.
+source "kernel/livepatch/Kconfig"
endmenu
menu "Boot options"
--
2.7.4
^ permalink raw reply related
* [PATCH 6/7] arm: Add livepatch to build if CONFIG_LIVEPATCH
From: Abel Vesa @ 2016-12-06 17:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481043967-15602-1-git-send-email-abelvesa@linux.com>
Necessary livepatch file added to makefile.
Signed-off-by: Abel Vesa <abelvesa@linux.com>
---
arch/arm/kernel/Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/kernel/Makefile b/arch/arm/kernel/Makefile
index ad325a8..9e70220 100644
--- a/arch/arm/kernel/Makefile
+++ b/arch/arm/kernel/Makefile
@@ -48,6 +48,7 @@ obj-$(CONFIG_HAVE_ARM_TWD) += smp_twd.o
obj-$(CONFIG_ARM_ARCH_TIMER) += arch_timer.o
obj-$(CONFIG_FUNCTION_TRACER) += entry-ftrace.o
obj-$(CONFIG_DYNAMIC_FTRACE) += ftrace.o insn.o
+obj-$(CONFIG_LIVEPATCH) += livepatch.o
obj-$(CONFIG_FUNCTION_GRAPH_TRACER) += ftrace.o insn.o
obj-$(CONFIG_JUMP_LABEL) += jump_label.o insn.o patch.o
obj-$(CONFIG_KEXEC) += machine_kexec.o relocate_kernel.o
--
2.7.4
^ permalink raw reply related
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