* [Bug] VCHIQ functional test broken
From: Stefan Wahren @ 2017-04-24 19:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170424185931.GQ17774@n2100.armlinux.org.uk>
> Russell King - ARM Linux <linux@armlinux.org.uk> hat am 24. April 2017 um 20:59 geschrieben:
>
>
> On Mon, Apr 24, 2017 at 07:42:27PM +0200, Stefan Wahren wrote:
> > > What I can't see is how changing flush_dcache_page() has possibly broken
> > > this: it seems to imply that you're getting flush_dcache_page() somehow
> > > called inbetween mapping it for DMA, using it for DMA and CPU accesses
> > > occuring. However, the driver doesn't call flush_dcache_page() other
> > > than through get_user_pages() - and since dma_map_sg() is used in that
> > > path, it should be fine.
> > >
> > > So, I don't have much to offer.
> > >
> > > However, flush_dcache_page() is probably still a tad heavy - it currently
> > > flushes to the point of coherency, but it's really about making sure that
> > > the user vs kernel mappings are coherent, not about device coherency.
> > > That's the role of the DMA API.
> >
> > Currently i don't care too much about performance. More important is to
> > fix this regression, because i'm not able to verify the function of this
> > driver efficiently.
>
> This is a driver in staging, and the reason its in staging is because it
> has problems. This is just another example of another problem it has...
> Yes, the regression is regrettable, but I don't think it's something to
> get hung up on.
>
> > I'm thinking about 2 options:
> >
> > 1) add a force parameter to flush_dcache_page() which make it possible
> > to override the new logic
> > 2) create a second version of flush_dcache_page() with the old behavior
>
> Neither, really, because, as I've already explained, flush_dcache_page()
> has nothing what so ever to do with DMA coherence - and if a driver
> breaks because we change its semantic slightly (but still in a compliant
> way) then it's uncovered a latent bug in _that_ driver.
>
> Rather than trying to "fix" flush_dcache_page() to work how this driver
> wants it to (which is a totally crazy thing to propose - we can't go
> shoe-horning driver specific behaviour into these generic flushing
> functions), it would be much better to work out why the driver has
> broken.
I totally agree. I had the hope we could make a workaround within the driver until we found the real issue.
>
> I see the kernel driver has its own logging (using vchiq_log_info() etc?)
> maybe a starting point would be to compare the output from a working
> kernel with a non-working kernel to get more of an idea where the problem
> actually is?
I will try ...
>
> What I'm willing to do is to temporarily drop the offending patch for
> the next merge window to give more time for this driver to be debugged,
> but I will want to re-apply it after that merge window closes.
Since this is already in 4.11, please keep it. At least this makes it easier to reproduce. No need for more confusion and effort.
^ permalink raw reply
* [PATCH 3/3 v2] xen: Implement EFI reset_system callback
From: Stefano Stabellini @ 2017-04-24 19:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170424175839.5262-4-julien.grall@arm.com>
On Mon, 24 Apr 2017, Julien Grall wrote:
> When rebooting DOM0 with ACPI on ARM64, the kernel is crashing with the stack
> trace [1].
>
> This is happening because when EFI runtimes are enabled, the reset code
> (see machine_restart) will first try to use EFI restart method.
>
> However, the EFI restart code is expecting the reset_system callback to
> be always set. This is not the case for Xen and will lead to crash.
>
> The EFI restart helper is used in multiple places and some of them don't
> not have fallback (see machine_power_off). So implement reset_system
> callback as a call to xen_reboot when using EFI Xen.
>
> [ 36.999270] reboot: Restarting system
> [ 37.002921] Internal error: Attempting to execute userspace memory: 86000004 [#1] PREEMPT SMP
> [ 37.011460] Modules linked in:
> [ 37.014598] CPU: 0 PID: 1 Comm: systemd-shutdow Not tainted 4.11.0-rc1-00003-g1e248b60a39b-dirty #506
> [ 37.023903] Hardware name: (null) (DT)
> [ 37.027734] task: ffff800902068000 task.stack: ffff800902064000
> [ 37.033739] PC is at 0x0
> [ 37.036359] LR is at efi_reboot+0x94/0xd0
> [ 37.040438] pc : [<0000000000000000>] lr : [<ffff00000880f2c4>] pstate: 404001c5
> [ 37.047920] sp : ffff800902067cf0
> [ 37.051314] x29: ffff800902067cf0 x28: ffff800902068000
> [ 37.056709] x27: ffff000008992000 x26: 000000000000008e
> [ 37.062104] x25: 0000000000000123 x24: 0000000000000015
> [ 37.067499] x23: 0000000000000000 x22: ffff000008e6e250
> [ 37.072894] x21: ffff000008e6e000 x20: 0000000000000000
> [ 37.078289] x19: ffff000008e5d4c8 x18: 0000000000000010
> [ 37.083684] x17: 0000ffffa7c27470 x16: 00000000deadbeef
> [ 37.089079] x15: 0000000000000006 x14: ffff000088f42bef
> [ 37.094474] x13: ffff000008f42bfd x12: ffff000008e706c0
> [ 37.099870] x11: ffff000008e70000 x10: 0000000005f5e0ff
> [ 37.105265] x9 : ffff800902067a50 x8 : 6974726174736552
> [ 37.110660] x7 : ffff000008cc6fb8 x6 : ffff000008cc6fb0
> [ 37.116055] x5 : ffff000008c97dd8 x4 : 0000000000000000
> [ 37.121453] x3 : 0000000000000000 x2 : 0000000000000000
> [ 37.126845] x1 : 0000000000000000 x0 : 0000000000000000
> [ 37.132239]
> [ 37.133808] Process systemd-shutdow (pid: 1, stack limit = 0xffff800902064000)
> [ 37.141118] Stack: (0xffff800902067cf0 to 0xffff800902068000)
> [ 37.146949] 7ce0: ffff800902067d40 ffff000008085334
> [ 37.154869] 7d00: 0000000000000000 ffff000008f3b000 ffff800902067d40 ffff0000080852e0
> [ 37.162787] 7d20: ffff000008cc6fb0 ffff000008cc6fb8 ffff000008c7f580 ffff000008c97dd8
> [ 37.170706] 7d40: ffff800902067d60 ffff0000080e2c2c 0000000000000000 0000000001234567
> [ 37.178624] 7d60: ffff800902067d80 ffff0000080e2ee8 0000000000000000 ffff0000080e2df4
> [ 37.186544] 7d80: 0000000000000000 ffff0000080830f0 0000000000000000 00008008ff1c1000
> [ 37.194462] 7da0: ffffffffffffffff 0000ffffa7c4b1cc 0000000000000000 0000000000000024
> [ 37.202380] 7dc0: ffff800902067dd0 0000000000000005 0000fffff24743c8 0000000000000004
> [ 37.210299] 7de0: 0000fffff2475f03 0000000000000010 0000fffff2474418 0000000000000005
> [ 37.218218] 7e00: 0000fffff2474578 000000000000000a 0000aaaad6b722c0 0000000000000001
> [ 37.226136] 7e20: 0000000000000123 0000000000000038 ffff800902067e50 ffff0000081e7294
> [ 37.234055] 7e40: ffff800902067e60 ffff0000081e935c ffff800902067e60 ffff0000081e9388
> [ 37.241973] 7e60: ffff800902067eb0 ffff0000081ea388 0000000000000000 00008008ff1c1000
> [ 37.249892] 7e80: ffffffffffffffff 0000ffffa7c4a79c 0000000000000000 ffff000000020000
> [ 37.257810] 7ea0: 0000010000000004 0000000000000000 0000000000000000 ffff0000080830f0
> [ 37.265729] 7ec0: fffffffffee1dead 0000000028121969 0000000001234567 0000000000000000
> [ 37.273651] 7ee0: ffffffffffffffff 8080000000800000 0000800000008080 feffa9a9d4ff2d66
> [ 37.281567] 7f00: 000000000000008e feffa9a9d5b60e0f 7f7fffffffff7f7f 0101010101010101
> [ 37.289485] 7f20: 0000000000000010 0000000000000008 000000000000003a 0000ffffa7ccf588
> [ 37.297404] 7f40: 0000aaaad6b87d00 0000ffffa7c4b1b0 0000fffff2474be0 0000aaaad6b88000
> [ 37.305326] 7f60: 0000fffff2474fb0 0000000001234567 0000000000000000 0000000000000000
> [ 37.313240] 7f80: 0000000000000000 0000000000000001 0000aaaad6b70d4d 0000000000000000
> [ 37.321159] 7fa0: 0000000000000001 0000fffff2474ea0 0000aaaad6b5e2e0 0000fffff2474e80
> [ 37.329078] 7fc0: 0000ffffa7c4b1cc 0000000000000000 fffffffffee1dead 000000000000008e
> [ 37.336997] 7fe0: 0000000000000000 0000000000000000 9ce839cffee77eab fafdbf9f7ed57f2f
> [ 37.344911] Call trace:
> [ 37.347437] Exception stack(0xffff800902067b20 to 0xffff800902067c50)
> [ 37.353970] 7b20: ffff000008e5d4c8 0001000000000000 0000000080f82000 0000000000000000
> [ 37.361883] 7b40: ffff800902067b60 ffff000008e17000 ffff000008f44c68 00000001081081b4
> [ 37.369802] 7b60: ffff800902067bf0 ffff000008108478 0000000000000000 ffff000008c235b0
> [ 37.377721] 7b80: ffff800902067ce0 0000000000000000 0000000000000000 0000000000000015
> [ 37.385643] 7ba0: 0000000000000123 000000000000008e ffff000008992000 ffff800902068000
> [ 37.393557] 7bc0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> [ 37.401477] 7be0: 0000000000000000 ffff000008c97dd8 ffff000008cc6fb0 ffff000008cc6fb8
> [ 37.409396] 7c00: 6974726174736552 ffff800902067a50 0000000005f5e0ff ffff000008e70000
> [ 37.417318] 7c20: ffff000008e706c0 ffff000008f42bfd ffff000088f42bef 0000000000000006
> [ 37.425234] 7c40: 00000000deadbeef 0000ffffa7c27470
> [ 37.430190] [< (null)>] (null)
> [ 37.434982] [<ffff000008085334>] machine_restart+0x6c/0x70
> [ 37.440550] [<ffff0000080e2c2c>] kernel_restart+0x6c/0x78
> [ 37.446030] [<ffff0000080e2ee8>] SyS_reboot+0x130/0x228
> [ 37.451337] [<ffff0000080830f0>] el0_svc_naked+0x24/0x28
> [ 37.456737] Code: bad PC value
> [ 37.459891] ---[ end trace 76e2fc17e050aecd ]---
>
> Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
> --
>
> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> Cc: Juergen Gross <jgross@suse.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: "H. Peter Anvin" <hpa@zytor.com>
> Cc: x86 at kernel.org
>
> The x86 code has theoritically a similar issue, altought EFI does not
> seem to be the preferred method. I have only built test it on x86.
>
> This should also probably be fixed in stable tree.
>
> Changes in v2:
> - Implement xen_efi_reset_system using xen_reboot
> - Move xen_efi_reset_system in drivers/xen/efi.c
> ---
> arch/arm/xen/efi.c | 2 +-
> arch/x86/xen/efi.c | 2 +-
> drivers/xen/efi.c | 18 ++++++++++++++++++
> include/xen/xen-ops.h | 3 +++
> 4 files changed, 23 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/xen/efi.c b/arch/arm/xen/efi.c
> index 16db419f9e90..b4d78959cadf 100644
> --- a/arch/arm/xen/efi.c
> +++ b/arch/arm/xen/efi.c
> @@ -35,6 +35,6 @@ void __init xen_efi_runtime_setup(void)
> efi.update_capsule = xen_efi_update_capsule;
> efi.query_capsule_caps = xen_efi_query_capsule_caps;
> efi.get_next_high_mono_count = xen_efi_get_next_high_mono_count;
> - efi.reset_system = NULL; /* Functionality provided by Xen. */
> + efi.reset_system = xen_efi_reset_system;
> }
> EXPORT_SYMBOL_GPL(xen_efi_runtime_setup);
> diff --git a/arch/x86/xen/efi.c b/arch/x86/xen/efi.c
> index 3be012115853..30bb2e80cfe7 100644
> --- a/arch/x86/xen/efi.c
> +++ b/arch/x86/xen/efi.c
> @@ -81,7 +81,7 @@ static const struct efi efi_xen __initconst = {
> .update_capsule = xen_efi_update_capsule,
> .query_capsule_caps = xen_efi_query_capsule_caps,
> .get_next_high_mono_count = xen_efi_get_next_high_mono_count,
> - .reset_system = NULL, /* Functionality provided by Xen. */
> + .reset_system = xen_efi_reset_system,
> .set_virtual_address_map = NULL, /* Not used under Xen. */
> .flags = 0 /* Initialized later. */
> };
> diff --git a/drivers/xen/efi.c b/drivers/xen/efi.c
> index 22f71ffd3406..9243a9051078 100644
> --- a/drivers/xen/efi.c
> +++ b/drivers/xen/efi.c
> @@ -26,6 +26,7 @@
> #include <xen/interface/xen.h>
> #include <xen/interface/platform.h>
> #include <xen/xen.h>
> +#include <xen/xen-ops.h>
>
> #include <asm/page.h>
>
> @@ -263,3 +264,20 @@ efi_status_t xen_efi_query_capsule_caps(efi_capsule_header_t **capsules,
> return efi_data(op).status;
> }
> EXPORT_SYMBOL_GPL(xen_efi_query_capsule_caps);
> +
> +void xen_efi_reset_system(int reset_type, efi_status_t status,
> + unsigned long data_size, efi_char16_t *data)
> +{
> + switch (reset_type) {
> + case EFI_RESET_COLD:
> + case EFI_RESET_WARM:
> + xen_reboot(SHUTDOWN_reboot);
> + break;
> + case EFI_RESET_SHUTDOWN:
> + xen_reboot(SHUTDOWN_poweroff);
> + break;
> + default:
> + BUG();
> + }
> +}
> +EXPORT_SYMBOL_GPL(xen_efi_reset_system);
> diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
> index fc5ddb472f86..197bb4866327 100644
> --- a/include/xen/xen-ops.h
> +++ b/include/xen/xen-ops.h
> @@ -122,6 +122,9 @@ efi_status_t xen_efi_update_capsule(efi_capsule_header_t **capsules,
> efi_status_t xen_efi_query_capsule_caps(efi_capsule_header_t **capsules,
> unsigned long count, u64 *max_size,
> int *reset_type);
> +void xen_efi_reset_system(int reset_type, efi_status_t status,
> + unsigned long data_size, efi_char16_t *data);
> +
>
> #ifdef CONFIG_PREEMPT
>
> --
> 2.11.0
>
^ permalink raw reply
* [PATCH v2] mmc: sdio: Fix sdio wait busy implement limitation
From: Ulf Hansson @ 2017-04-24 19:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492940307-20785-1-git-send-email-jiajie.hao@mediatek.com>
On 23 April 2017 at 11:38, Jiajie Hao <jiajie.hao@mediatek.com> wrote:
> The host may issue an I/O abort by writing to the CCCR at any time
> during I/O read operation via CMD52. And host may need suspend
> transcation during write busy stage in SDIO suspend/resume scenario.
> From other side, a card may accept CMD52 during data transfer phase.
>
> Previous implement would block issuing above command in busy stage.
> It cause function driver can't implement as proper way and has no
> opportunity to do some coverage in error case via I/O abort etc.
>
> We need bypass some necessary operation during busy check stage.
>
> Signed-off-by: Jiajie Hao <jiajie.hao@mediatek.com>
Thanks, applied for next!
Kind regards
Uffe
> ---
> Changes since v1:(https://lkml.org/lkml/2017/4/17/69)
> * extend orignal interface to cover necessary cases.
> * rename mmc_is_io_op() to sdio_is_op_busy() for matching it's meaning.
>
> ---
> drivers/mmc/core/core.c | 4 +++-
> drivers/mmc/core/sdio_ops.h | 10 ++++++++--
> 2 files changed, 11 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
> index 926e0fd..2ae83a7 100644
> --- a/drivers/mmc/core/core.c
> +++ b/drivers/mmc/core/core.c
> @@ -234,8 +234,10 @@ static void __mmc_start_request(struct mmc_host *host, struct mmc_request *mrq)
> /*
> * For sdio rw commands we must wait for card busy otherwise some
> * sdio devices won't work properly.
> + * And bypass I/O abort, reset and bus suspend operations.
> */
> - if (mmc_is_io_op(mrq->cmd->opcode) && host->ops->card_busy) {
> + if (sdio_is_io_busy(mrq->cmd->opcode, mrq->cmd->arg) &&
> + host->ops->card_busy) {
> int tries = 500; /* Wait aprox 500ms at maximum */
>
> while (host->ops->card_busy(host) && --tries)
> diff --git a/drivers/mmc/core/sdio_ops.h b/drivers/mmc/core/sdio_ops.h
> index bed8a83..ee35cb4 100644
> --- a/drivers/mmc/core/sdio_ops.h
> +++ b/drivers/mmc/core/sdio_ops.h
> @@ -26,9 +26,15 @@ int mmc_io_rw_extended(struct mmc_card *card, int write, unsigned fn,
> int sdio_reset(struct mmc_host *host);
> unsigned int mmc_align_data_size(struct mmc_card *card, unsigned int sz);
>
> -static inline bool mmc_is_io_op(u32 opcode)
> +static inline bool sdio_is_io_busy(u32 opcode, u32 arg)
> {
> - return opcode == SD_IO_RW_DIRECT || opcode == SD_IO_RW_EXTENDED;
> + u32 addr;
> +
> + addr = (arg >> 9) & 0x1FFFF;
> +
> + return (opcode == SD_IO_RW_EXTENDED ||
> + (opcode == SD_IO_RW_DIRECT &&
> + !(addr == SDIO_CCCR_ABORT || addr == SDIO_CCCR_SUSPEND)));
> }
>
> #endif
> --
> 1.7.9.5
>
^ permalink raw reply
* [PATCH V9 1/3] irq: Allow to pass the IRQF_TIMER flag with percpu irq request
From: Daniel Lezcano @ 2017-04-24 19:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <92e2a022-93d4-d4f3-78af-c9b5d51bb867@arm.com>
On Mon, Apr 24, 2017 at 08:14:54PM +0100, Marc Zyngier wrote:
> On 24/04/17 19:59, Daniel Lezcano wrote:
> > On Mon, Apr 24, 2017 at 07:46:43PM +0100, Marc Zyngier wrote:
> >> On 24/04/17 15:01, Daniel Lezcano wrote:
> >>> In the next changes, we track when the interrupts occur in order to
> >>> statistically compute when is supposed to happen the next interrupt.
> >>>
> >>> In all the interruptions, it does not make sense to store the timer interrupt
> >>> occurences and try to predict the next interrupt as when know the expiration
> >>> time.
> >>>
> >>> The request_irq() has a irq flags parameter and the timer drivers use it to
> >>> pass the IRQF_TIMER flag, letting us know the interrupt is coming from a timer.
> >>> Based on this flag, we can discard these interrupts when tracking them.
> >>>
> >>> But, the API request_percpu_irq does not allow to pass a flag, hence specifying
> >>> if the interrupt type is a timer.
> >>>
> >>> Add a function request_percpu_irq_flags() where we can specify the flags. The
> >>> request_percpu_irq() function is changed to be a wrapper to
> >>> request_percpu_irq_flags() passing a zero flag parameter.
> >>>
> >>> Change the timers using request_percpu_irq() to use request_percpu_irq_flags()
> >>> instead with the IRQF_TIMER flag set.
> >>>
> >>> For now, in order to prevent a misusage of this parameter, only the IRQF_TIMER
> >>> flag (or zero) is a valid parameter to be passed to the
> >>> request_percpu_irq_flags() function.
> >>
> >> [...]
> >>
> >>> diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
> >>> index 35d7100..602e0a8 100644
> >>> --- a/virt/kvm/arm/arch_timer.c
> >>> +++ b/virt/kvm/arm/arch_timer.c
> >>> @@ -523,8 +523,9 @@ int kvm_timer_hyp_init(void)
> >>> host_vtimer_irq_flags = IRQF_TRIGGER_LOW;
> >>> }
> >>>
> >>> - err = request_percpu_irq(host_vtimer_irq, kvm_arch_timer_handler,
> >>> - "kvm guest timer", kvm_get_running_vcpus());
> >>> + err = request_percpu_irq_flags(host_vtimer_irq, kvm_arch_timer_handler,
> >>> + IRQF_TIMER, "kvm guest timer",
> >>> + kvm_get_running_vcpus());
> >>> if (err) {
> >>> kvm_err("kvm_arch_timer: can't request interrupt %d (%d)\n",
> >>> host_vtimer_irq, err);
> >>>
> >>
> >> How is that useful? This timer is controlled by the guest OS, and not
> >> the host kernel. Can you explain how you intend to make use of that
> >> information in this case?
> >
> > Isn't it a source of interruption on the host kernel?
>
> Only to cause an exit of the VM, and not under the control of the host.
> This isn't triggering any timer related action on the host code either.
>
> Your patch series seems to assume some kind of predictability of the
> timer interrupt, which can make sense on the host. Here, this interrupt
> is shared among *all* guests running on this system.
>
> Maybe you could explain why you think this interrupt is relevant to what
> you're trying to achieve?
If this interrupt does not happen on the host, we don't care.
The flag IRQF_TIMER is used by the spurious irq handler in the try_one_irq()
function. However the per cpu timer interrupt will be discarded in the function
before because it is per cpu.
IMO, for consistency reason, adding the IRQF_TIMER makes sense. Other than
that, as the interrupt is not happening on the host, this flag won't be used.
Do you want to drop this change?
-- Daniel
--
<http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
^ permalink raw reply
* [PATCH] ARM: dts: Add devicetree for the Raspberry Pi 3, for arm32 (v5)
From: Eric Anholt @ 2017-04-24 20:00 UTC (permalink / raw)
To: linux-arm-kernel
Raspbian and Fedora have decided to support the Pi3 in 32-bit mode for
now, so it's useful to be able to test that mode on an upstream
kernel. It's also been useful for me to use the same board for 32-bit
and 64-bit development.
Signed-off-by: Eric Anholt <eric@anholt.net>
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/bcm2837-rpi-3.b.dts | 1 +
2 files changed, 2 insertions(+)
create mode 100644 arch/arm/boot/dts/bcm2837-rpi-3.b.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 011808490fed..eded842d9978 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -72,6 +72,7 @@ dtb-$(CONFIG_ARCH_BCM2835) += \
bcm2835-rpi-b-plus.dtb \
bcm2835-rpi-a-plus.dtb \
bcm2836-rpi-2-b.dtb \
+ bcm2837-rpi-3-b.dtb \
bcm2835-rpi-zero.dtb
dtb-$(CONFIG_ARCH_BCM_5301X) += \
bcm4708-asus-rt-ac56u.dtb \
diff --git a/arch/arm/boot/dts/bcm2837-rpi-3.b.dts b/arch/arm/boot/dts/bcm2837-rpi-3.b.dts
new file mode 100644
index 000000000000..8c8aa4d1e9b3
--- /dev/null
+++ b/arch/arm/boot/dts/bcm2837-rpi-3.b.dts
@@ -0,0 +1 @@
+#include "arm64/broadcom/bcm2837-rpi-3.b.dts"
--
2.11.0
^ permalink raw reply related
* [PATCH] ARM: dts: Add devicetree for the Raspberry Pi 3, for arm32 (v4)
From: Eric Anholt @ 2017-04-24 20:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOesGMhf-MNh+SPZe2YYefyaPk3qxqhZ5ipr86zzK3r02bE81A@mail.gmail.com>
Olof Johansson <olof@lixom.net> writes:
> Hi,
>
> On Wed, Mar 29, 2017 at 5:26 PM, Eric Anholt <eric@anholt.net> wrote:
>> Raspbian and Fedora have decided to support the Pi3 in 32-bit mode for
>> now, so it's useful to be able to test that mode on an upstream
>> kernel. It's also been useful for me to use the same board for 32-bit
>> and 64-bit development.
>>
>> Signed-off-by: Eric Anholt <eric@anholt.net>
>> ---
>>
>> v1: Gerd's patch that put the ../../../arm64/... link in the Makefile
>> v2: Michael's patch that #included from ../../../arm64/... in a new
>> bcm2837-rpi-3-b.dts.
>> v3: Mine, using symlinks to make sure that we don't break the split DT
>> tree.
>> v4: Rely on the new include/arm64 symlink.
>>
>> Assuming positive review feedback, I assume it would be acceptable to
>> merge the shared/dt-symlinks branch in a PR of my own for the 32-bit
>> DT branch?
>>
>> arch/arm/boot/dts/Makefile | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>> index 011808490fed..27d258cb50f2 100644
>> --- a/arch/arm/boot/dts/Makefile
>> +++ b/arch/arm/boot/dts/Makefile
>> @@ -72,6 +72,7 @@ dtb-$(CONFIG_ARCH_BCM2835) += \
>> bcm2835-rpi-b-plus.dtb \
>> bcm2835-rpi-a-plus.dtb \
>> bcm2836-rpi-2-b.dtb \
>> + include/arm64/broadcom/bcm2837-rpi-3-b.dtb \
>
> Building straight out of (and into) the include dir is a little odd here.
>
> A tiny wrapper *.dtb in this dir, that just includes a shared dts/dtsi
> would be a lot nicer.
OK, just sent a version with a #include.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170424/218c7c6b/attachment.sig>
^ permalink raw reply
* [PATCH V3 2/2] ARM64: dts: hi6220-hikey: Add clock binding for the pmic mfd
From: Daniel Lezcano @ 2017-04-24 20:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170424085944.aa5dsc4g6bwm5rgi@dell>
On Mon, Apr 24, 2017 at 09:59:44AM +0100, Lee Jones wrote:
> On Sat, 22 Apr 2017, Daniel Lezcano wrote:
>
> > On 22/04/2017 04:02, Stephen Boyd wrote:
> > > On 04/17, Daniel Lezcano wrote:
> > >> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
> > >> ---
> > >> Documentation/devicetree/bindings/mfd/hisilicon,hi655x.txt | 6 ++++++
> > >> arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts | 1 +
> > >> 2 files changed, 7 insertions(+)
> > >>
> > >
> > > I take it this goes through arm-soc? Not sure why I'm on To:
> > > line.
> >
> > Probably it should go through Lee's tree.
>
> Unlikely.
>
> The document and the DTS change should really have gone separately,
> but to save you from having to mess around so close to the merge window:
>
> Acked-by: Lee Jones <lee.jones@linaro.org>
So who is supposed to take this patch? Xu? Rob?
--
<http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
^ permalink raw reply
* [PATCH 0/3] Add eSDHC UHS-I/HS200 mode support for ls1012a/ls1046a/ls208xa
From: Ulf Hansson @ 2017-04-24 20:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492746756-12024-1-git-send-email-yangbo.lu@nxp.com>
On 21 April 2017 at 05:52, Yangbo Lu <yangbo.lu@nxp.com> wrote:
> This patch is to add eSDHC UHS-I/HS200 mode support for ls1012a/ls1046a/ls208xa.
> Because eSDHC is not a standard SD controller, the specific speed mode support
> depends on board's peripheral circuit for eSDHC. So, we have to add these speed
> modes support on board dts file.
>
> In additon, these dts patches depends on esdhc driver patches which just had been merged
> on mmc.git. Otherwise, the UHS-I SD card and eMMC HS200 card would fail to be initialized,
> but other cards still could work fine.
> https://patchwork.kernel.org/patch/9689875/
> https://patchwork.kernel.org/patch/9689877/
> https://patchwork.kernel.org/patch/9689879/
> https://patchwork.kernel.org/patch/9689887/
> https://patchwork.kernel.org/patch/9689885/
>
> Yangbo Lu (3):
> arm64: dts: ls1046a: support SD UHS-I and eMMC HS200 on RDB
> arm64: dts: ls208xa: support SD UHS-I on RDB and eMMC HS200 on QDS
> arm64: dts: ls1012a: add eSDHC nodes
>
> arch/arm64/boot/dts/freescale/fsl-ls1012a-qds.dts | 8 +++++++
> arch/arm64/boot/dts/freescale/fsl-ls1012a-rdb.dts | 13 +++++++++++
> arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi | 25 ++++++++++++++++++++++
> arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts | 8 +++++++
> arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 4 ++--
> arch/arm64/boot/dts/freescale/fsl-ls208xa-qds.dtsi | 1 +
> arch/arm64/boot/dts/freescale/fsl-ls208xa-rdb.dtsi | 4 ++++
> arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 2 +-
> 8 files changed, 62 insertions(+), 3 deletions(-)
>
> --
> 2.1.0.27.g96db324
>
By curiosity I tried applying these to my mmc tree, but they don't
apply. So I can pick them, even with acks.
Also it's too difficult for me to host an immutable branch with the
relevant sdhci-esdc changes, because of additional sdhci dependencies.
Perhaps just easier to pick this for 4.13 or 4.12 rc2.
Kind regards
Uffe
^ permalink raw reply
* [PATCH V3 2/2] ARM64: dts: hi6220-hikey: Add clock binding for the pmic mfd
From: Arnd Bergmann @ 2017-04-24 20:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170424201139.GF2137@mai>
On Mon, Apr 24, 2017 at 10:11 PM, Daniel Lezcano
<daniel.lezcano@linaro.org> wrote:
> On Mon, Apr 24, 2017 at 09:59:44AM +0100, Lee Jones wrote:
>> On Sat, 22 Apr 2017, Daniel Lezcano wrote:
>>
>> > On 22/04/2017 04:02, Stephen Boyd wrote:
>> > > On 04/17, Daniel Lezcano wrote:
>> > >> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
>> > >> ---
>> > >> Documentation/devicetree/bindings/mfd/hisilicon,hi655x.txt | 6 ++++++
>> > >> arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts | 1 +
>> > >> 2 files changed, 7 insertions(+)
>> > >>
>> > >
>> > > I take it this goes through arm-soc? Not sure why I'm on To:
>> > > line.
>> >
>> > Probably it should go through Lee's tree.
>>
>> Unlikely.
>>
>> The document and the DTS change should really have gone separately,
>> but to save you from having to mess around so close to the merge window:
>>
>> Acked-by: Lee Jones <lee.jones@linaro.org>
>
> So who is supposed to take this patch? Xu? Rob?
The DTS file changes should normally go through the platform maintainer
and from there to arm-soc, to minimize the risk for patch conflicts.
For binding changes, conflicts are much rarer, so we any of the tree
(arm-soc, driver subsystem, or devicetree) works equally well IMHO.
In this particular case,keeping the two together is best, so please send
it to Wei Xu with the added chagnelog and Acks.
Arnd
^ permalink raw reply
* [PATCH v2 0/4] ARM: dts: keystone: Add support for new K2G evm
From: Franklin S Cooper Jr @ 2017-04-24 20:22 UTC (permalink / raw)
To: linux-arm-kernel
This patchset adds support for new K2G Industrial Communication Engine
evm. For now only a bare minimal dts which will allow ram boot. Additional
peripherals will be added when base K2G SoC patches are upstreamed allowing
peripherals to be enabled.
Version 2 changes:
Make various tweaks to allow unit address to be added to memory node.
Franklin S Cooper Jr (4):
ARM: dts: keystone-k2g: Remove skeleton.dtsi
ARM: dts: k2g-evm: Add unit address to memory node
ARM: keystone: Create new binding for K2G ICE evm
ARM: dts: keystone: Add minimum support for K2G ICE evm
.../devicetree/bindings/arm/keystone/keystone.txt | 3 ++
arch/arm/boot/dts/Makefile | 3 +-
arch/arm/boot/dts/keystone-k2g-evm.dts | 2 +-
arch/arm/boot/dts/keystone-k2g-ice.dts | 35 ++++++++++++++++++++++
arch/arm/boot/dts/keystone-k2g.dtsi | 3 +-
5 files changed, 43 insertions(+), 3 deletions(-)
create mode 100644 arch/arm/boot/dts/keystone-k2g-ice.dts
--
2.10.0
^ permalink raw reply
* [PATCH v2 1/4] ARM: dts: keystone-k2g: Remove skeleton.dtsi
From: Franklin S Cooper Jr @ 2017-04-24 20:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170424202204.24170-1-fcooper@ti.com>
Adding the unit address to the memory node was causing the below error:
Warning (reg_format): "reg" property in /memory has invalid length
(8 bytes) (#address-cells == 2, #size-cells == 2)
Further debugging showed that this was due to the memory node added by
default to skeleton.dtsi which was being included in keystone-k2g.dtsi.
Adding a missing node was all that was needed to remove this deprecated
dtsi file from the SoC dtsi. With skeleton.dtsi removed the dtc compiler
no longer complained about including the unit address for the memory node.
Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
---
arch/arm/boot/dts/keystone-k2g.dtsi | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/keystone-k2g.dtsi b/arch/arm/boot/dts/keystone-k2g.dtsi
index f59567f..a789f75 100644
--- a/arch/arm/boot/dts/keystone-k2g.dtsi
+++ b/arch/arm/boot/dts/keystone-k2g.dtsi
@@ -15,7 +15,6 @@
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/pinctrl/keystone.h>
-#include "skeleton.dtsi"
/ {
compatible = "ti,k2g","ti,keystone";
@@ -24,6 +23,8 @@
#size-cells = <2>;
interrupt-parent = <&gic>;
+ chosen { };
+
aliases {
serial0 = &uart0;
};
--
2.10.0
^ permalink raw reply related
* [PATCH v2 2/4] ARM: dts: k2g-evm: Add unit address to memory node
From: Franklin S Cooper Jr @ 2017-04-24 20:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170424202204.24170-1-fcooper@ti.com>
With the new Keystone 2 Industrial Communication EVM adding the
unit address to the memory node it made sense to add it for this board
also.
Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
---
arch/arm/boot/dts/keystone-k2g-evm.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/keystone-k2g-evm.dts b/arch/arm/boot/dts/keystone-k2g-evm.dts
index 692fcbb..61883cb 100644
--- a/arch/arm/boot/dts/keystone-k2g-evm.dts
+++ b/arch/arm/boot/dts/keystone-k2g-evm.dts
@@ -20,7 +20,7 @@
compatible = "ti,k2g-evm", "ti,k2g", "ti,keystone";
model = "Texas Instruments K2G General Purpose EVM";
- memory {
+ memory at 800000000 {
device_type = "memory";
reg = <0x00000008 0x00000000 0x00000000 0x80000000>;
};
--
2.10.0
^ permalink raw reply related
* [PATCH v2 3/4] ARM: keystone: Create new binding for K2G ICE evm
From: Franklin S Cooper Jr @ 2017-04-24 20:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170424202204.24170-1-fcooper@ti.com>
Add a new binding for the new K2G Industrial Communication Engine evm.
Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
Acked-by: Rob Herring <robh@kernel.org>
---
Documentation/devicetree/bindings/arm/keystone/keystone.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/keystone/keystone.txt b/Documentation/devicetree/bindings/arm/keystone/keystone.txt
index 48f6703..f310bad 100644
--- a/Documentation/devicetree/bindings/arm/keystone/keystone.txt
+++ b/Documentation/devicetree/bindings/arm/keystone/keystone.txt
@@ -37,3 +37,6 @@ Boards:
- K2G EVM
compatible = "ti,k2g-evm", "ti,k2g", "ti-keystone"
+
+- K2G Industrial Communication Engine EVM
+ compatible = "ti,k2g-ice", "ti,k2g", "ti-keystone"
--
2.10.0
^ permalink raw reply related
* [PATCH v2 4/4] ARM: dts: keystone: Add minimum support for K2G ICE evm
From: Franklin S Cooper Jr @ 2017-04-24 20:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170424202204.24170-1-fcooper@ti.com>
Add barebones dts support for TI's K2G Industrial Communication Engine evm.
This dts allows the board to boot using a ram based filesystem.
Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
---
arch/arm/boot/dts/Makefile | 3 ++-
arch/arm/boot/dts/keystone-k2g-ice.dts | 35 ++++++++++++++++++++++++++++++++++
2 files changed, 37 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/keystone-k2g-ice.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 0118084..01a98f1 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -193,7 +193,8 @@ dtb-$(CONFIG_ARCH_KEYSTONE) += \
keystone-k2hk-evm.dtb \
keystone-k2l-evm.dtb \
keystone-k2e-evm.dtb \
- keystone-k2g-evm.dtb
+ keystone-k2g-evm.dtb \
+ keystone-k2g-ice.dtb
dtb-$(CONFIG_MACH_KIRKWOOD) += \
kirkwood-b3.dtb \
kirkwood-blackarmor-nas220.dtb \
diff --git a/arch/arm/boot/dts/keystone-k2g-ice.dts b/arch/arm/boot/dts/keystone-k2g-ice.dts
new file mode 100644
index 0000000..d820d37
--- /dev/null
+++ b/arch/arm/boot/dts/keystone-k2g-ice.dts
@@ -0,0 +1,35 @@
+/*
+ * Device Tree Source for K2G Industrial Communication Engine EVM
+ *
+ * Copyright (C) 2017 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * SPDX-License-Identifier: GPL-2.0
+ */
+/dts-v1/;
+
+#include "keystone-k2g.dtsi"
+
+/ {
+ compatible = "ti,k2g-ice", "ti,k2g", "ti,keystone";
+ model = "Texas Instruments K2G Industrial Communication EVM";
+
+ memory at 800000000 {
+ device_type = "memory";
+ reg = <0x00000008 0x00000000 0x00000000 0x20000000>;
+ };
+};
+
+&k2g_pinctrl {
+ uart0_pins: pinmux_uart0_pins {
+ pinctrl-single,pins = <
+ K2G_CORE_IOPAD(0x11cc) (BUFFER_CLASS_B | PULL_DISABLE | MUX_MODE0) /* uart0_rxd.uart0_rxd */
+ K2G_CORE_IOPAD(0x11d0) (BUFFER_CLASS_B | PIN_PULLDOWN | MUX_MODE0) /* uart0_txd.uart0_txd */
+ >;
+ };
+};
+
+&uart0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart0_pins>;
+ status = "okay";
+};
--
2.10.0
^ permalink raw reply related
* [RFC] minimum gcc version for kernel: raise to gcc-4.3 or 4.6?
From: Arnd Bergmann @ 2017-04-24 20:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.20.1704241908260.32200@eddie.linux-mips.org>
On Mon, Apr 24, 2017 at 8:30 PM, Maciej W. Rozycki <macro@linux-mips.org> wrote:
> On Mon, 24 Apr 2017, Arnd Bergmann wrote:
>
>>
>> So it still fails, but only because of one compiler error that I can avoid by
>> disabling that driver, and you probably use a slightly patched compiler
>> version that doesn't have this particular bug, or it was a regression between
>> gcc-4.1.2 and 4.1.3.
>
> Umm, I didn't build modules, sorry, because I don't usually use them with
> those systems. However I have completed this step now and it also worked
> just fine:
>
> $ ls -la crypto/drbg.o
> -rw-r--r-- 1 macro macro 14096 Apr 24 18:59 crypto/drbg.o
> $ file crypto/drbg.o
> crypto/drbg.o: ELF 32-bit LSB MIPS-I relocatable, MIPS, version 1 (SYSV), not stripped
> $
>
> so you are likely right that either I have a patch applied to my 4.1.2
> build that has somehow fixed the ICE or it is a 4.1.3 regression (or a bad
> patch in your 4.1.3 build).
Ok.
> BTW I do see these `may be used uninitialized' warnings just as Geert
> does and even have a local patch, which I have neglected to submit, for a
> 64-bit configuration (`decstation_defconfig' is 32-bit) where in a single
> place -Werror turns it into a build failure. I do not consider it a big
> issue though, and might even wrap that patch up and submit sometime.
I'd recommend dropping that -Werror from mips and the other few
architectures that have it, or maybe wrapping it in a Kconfig symbol that
is disabled by default. It would also take care of
==> build/mips/bmips_be_defconfig/log <==
cc1: warnings being treated as errors
/git/arm-soc/arch/mips/bmips/setup.c:37: error: integer constant is
too large for 'long' type
As mentioned, we can also turn off the warnings by default and let
Geert turn them on again:
diff --git a/Makefile b/Makefile
index 779302695453..2528f60fb9ab 100644
--- a/Makefile
+++ b/Makefile
@@ -647,8 +647,10 @@ KBUILD_CFLAGS += -O2
endif
endif
-KBUILD_CFLAGS += $(call cc-ifversion, -lt, 0409, \
- $(call
cc-disable-warning,maybe-uninitialized,))
+KBUILD_CFLAGS += $(call cc-ifversion, -lt, 0408, \
+ $(call cc-disable-warning,uninitialized, \
+ $(call cc-ifversion, -lt, 0409, \
+ $(call
cc-disable-warning,maybe-uninitialized,))))
# Tell gcc to never replace conditional load with a non-conditional one
KBUILD_CFLAGS += $(call cc-option,--param=allow-store-data-races=0)
I've built the remaining defconfigs in the meantime (linux-4.11-rc8, gcc-4.1.3,
ARCH=mips) and got 38 builds with warnings and 20 failed builds. There are
at least six different build failures and only one ICE among them (only
in decstation_defconfig). With gcc-4.3 this is only slightly better: 18
failed build, 20 with warnings and 20 without warnings.
With linux-4.3, I saw this failure on 32 defconfigs,
and you fixed that in linux-4.7 with e49d38488515 ("MIPS: MSA: Fix a
link error on `_init_msa_upper' with older GCC"):
arch/mips/built-in.o: In function `enable_restore_fp_context':
traps.c:(.text+0xbefc): undefined reference to `_init_msa_upper'
traps.c:(.text+0xbfc0): undefined reference to `_init_msa_upper'
With gcc-4.9, all mips defconfigs now build without warnings.
For the other architectures in linux-4.11-rc8 can actually build with
sparc-gcc-4.1, afaict this was a bug that impacted all compilers up to
gcc-4.7 and a workaround was added recently. In turn, parisc-gcc-4.1
no longer works on linux-4.11, so we still have only three architectures
that can build their 'defconfig' with the old compiler, plus the majority
of the mips config files.
So while overall I still think that gcc-4.1 is rather broken, it seems that
you have it well under control on both mips and m68k. It's possible
that some other people use patched gcc-4.1 or only build special
configurations on further architectures that I found to be broken
with vanilla toolchains and the regular defconfig.
How about this approach then:
- To keep it simple, we update the README.rst to say that a minimum
gcc-4.3 is required, while recommending gcc-4.9 for all architectures
- Support for gcc-4.0 and earlier gets removed from linux/compiler.h,
and instead we add a summary of what I found, explaining that
gcc-4.1 has active users on a few architectures.
- We make the Makefile show a warning once during compilation for
gcc earlier than 4.3.
Arnd
^ permalink raw reply related
* [PATCH V4] ARM64: dts: hi6220-hikey: Add clock binding for the pmic mfd
From: Daniel Lezcano @ 2017-04-24 20:40 UTC (permalink / raw)
To: linux-arm-kernel
The hi655x PMIC provides the regulators but also a clock. The latter is missing
in the definition and in the DT, thus it is no possible to enable the WiFi which
depends on this clock.
The hi655x's clock has been added and the hi655x multifunction driver has
updated with a clock-cell.
This patch adds the clock-cells for the PMIC in the DT and updates the
documentation.
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Acked-by: Rob Herring <robh@kernel.org>
Acked-by: Lee Jones <lee.jones@linaro.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Stephen Boyd <sboyd@codeaurora.org>
Cc: Michael Turquette <mturquette@baylibre.com>
---
Changelog:
v4:
- Added Acked-by's
- Updated the commit message with a better description
---
Documentation/devicetree/bindings/mfd/hisilicon,hi655x.txt | 6 ++++++
arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts | 1 +
2 files changed, 7 insertions(+)
diff --git a/Documentation/devicetree/bindings/mfd/hisilicon,hi655x.txt b/Documentation/devicetree/bindings/mfd/hisilicon,hi655x.txt
index 0548569..9630ac0 100644
--- a/Documentation/devicetree/bindings/mfd/hisilicon,hi655x.txt
+++ b/Documentation/devicetree/bindings/mfd/hisilicon,hi655x.txt
@@ -16,6 +16,11 @@ Required properties:
- reg: Base address of PMIC on Hi6220 SoC.
- interrupt-controller: Hi655x has internal IRQs (has own IRQ domain).
- pmic-gpios: The GPIO used by PMIC IRQ.
+- #clock-cells: From common clock binding; shall be set to 0
+
+Optional properties:
+- clock-output-names: From common clock binding to override the
+ default output clock name
Example:
pmic: pmic at f8000000 {
@@ -24,4 +29,5 @@ Example:
interrupt-controller;
#interrupt-cells = <2>;
pmic-gpios = <&gpio1 2 GPIO_ACTIVE_HIGH>;
+ #clock-cells = <0>;
}
diff --git a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
index dba3c13..e0496f7 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
+++ b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
@@ -325,6 +325,7 @@
pmic: pmic at f8000000 {
compatible = "hisilicon,hi655x-pmic";
reg = <0x0 0xf8000000 0x0 0x1000>;
+ #clock-cells = <0>;
interrupt-controller;
#interrupt-cells = <2>;
pmic-gpios = <&gpio1 2 GPIO_ACTIVE_HIGH>;
--
1.9.1
^ permalink raw reply related
* [RFC] minimum gcc version for kernel: raise to gcc-4.3 or 4.6?
From: Kees Cook @ 2017-04-24 20:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK8P3a0HQUqtL=9pgPEreQJaA0AksiR06B4oAwvbYnJeA-2i7w@mail.gmail.com>
On Mon, Apr 24, 2017 at 1:30 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> How about this approach then:
>
> - To keep it simple, we update the README.rst to say that a minimum
> gcc-4.3 is required, while recommending gcc-4.9 for all architectures
> - Support for gcc-4.0 and earlier gets removed from linux/compiler.h,
> and instead we add a summary of what I found, explaining that
> gcc-4.1 has active users on a few architectures.
> - We make the Makefile show a warning once during compilation for
> gcc earlier than 4.3.
This sounds good to me!
-Kees
--
Kees Cook
Pixel Security
^ permalink raw reply
* [PATCH] Mangled urls fixed (was... Re: linux-next: manual merge of the pm tree with the arm-soc tree)
From: santosh.shilimkar at oracle.com @ 2017-04-24 21:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK8P3a1mPgM4XmS398DPsSbyCyD=12xQfUrF_HRqyd52_21o7Q@mail.gmail.com>
Hi Arnd,
On 4/21/17 2:44 PM, Arnd Bergmann wrote:
> On Fri, Apr 21, 2017 at 11:02 PM, santosh.shilimkar at oracle.com
[...]
> Ok, good, thanks for checking! They are however the commits that
> contain the silly https://urldefense.proofpoint.com URLs. Can you
> send a follow-up patch to fix these and use the regular https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ti.org&d=DwIBaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=XBn1JQGPwR8CsE7xpP3wPlG6DQU7qw8ym65xieNZ4hY&m=vFHOEb7p2FxbH00YRQq4WnRiu2BKHADn0gl6e6DoNFQ&s=7mfiIp2Ywy9_ppWKjEGlrswiKRndv8_I7zGVF9uyT0w&e=
> URL that is in linux-next?
>
If not late can you please apply the top patch from below head
which fixes the mangled urls. Let me know if you want me to
create tag for the same.
git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux-keystone.git
for_4.12/soc-pmdomain-p2
Regards,
Santosh
^ permalink raw reply
* support autofocus / autogain in libv4l2
From: Pavel Machek @ 2017-04-24 21:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170424103802.00d3b554@vento.lan>
Hi!
> > For focus to be useful, we need autofocus implmented
> > somewhere. Unfortunately, v4l framework does not seem to provide good
> > place where to put autofocus. I believe, long-term, we'll need some
> > kind of "video server" providing this kind of services.
> >
> > Anyway, we probably don't want autofocus in kernel (even through some
> > cameras do it in hardware), and we probably don't want autofocus in
> > each and every user application.
> >
> > So what remains is libv4l2.
>
> IMO, the best place for autofocus is at libv4l2. Putting it on a
> separate "video server" application looks really weird for me.
Well... let me see. libraries are quite limited -- it is hard to open
files, or use threads/have custom main loop. It may be useful to
switch resolutions -- do autofocus/autogain at lower resolution, then
switch to high one for taking picture. It would be good to have that
in "system" code, but I'm not at all sure libv4l2 design will allow
that.
It would be good if application could say "render live camera into
this window" and only care about user interface, then say "give me a
high resolution jpeg". But that would require main loop in the
library...
It would be nice if more than one application could be accessing the
camera at the same time... (I.e. something graphical running preview
then using command line tool to grab a picture.) This one is
definitely not solveable inside a library...
> Btw, libv4l2 already has some autotools for auto gain and auto
> white balance. See the implementation under:
> lib/libv4lconvert/processing
>
> The libv4l internal controls can be seen at:
> lib/libv4lconvert/control/libv4lcontrol.h
>
> The ones implemented by the processing part of the library are:
Thanks for pointer, will take a look.
> > Now, this is in no way clean or complete,
> > and functionality provided by sdl.c and asciicam.c probably _should_
> > be in application, but... I'd like to get the code out there.
> >
> > Oh and yes, I've canibalized decode_tm6000.c application instead of
> > introducing my own. Autotools scare me, sorry.
>
> Why replace decode_tm6000.c by something else? If you want to add another
> test application, just place it on a new file.
Scary scary scary autotools ;-). Yes, I did rather lot of hacks, as
you noted below. I do development on n900, so not everything is easy.
> I added a few notes together with the code, pointing the main things
> I think it require changes, in order for me to do a better review
> at the code. I didn't test nor tried to check the algorithms inside,
> as the code, on its current state, requires rework and code cleanup.
Thanks, I'll take a look.
> Please don't add a new application under lib/. It is fine if you want
> some testing application, if the ones there aren't enough, but please
> place it under contrib/test/.
>
> You should likely take a look at v4l2grab first, as it could have
> almost everything you would need.
Will take a look, thanks for pointer.
> IMHO, it would be better to use aalib. Btw, xawtv3 has a code example
> using it, under:
> console/ttv.c
>
> As it already uses libv4l, prhaps you could use it, instead of adding
> a new ascii app.
No need to duplicate it, then. I was trying to quickly test video
works, this was before SDL.
> > +#include "sdl.c"
> > +
> > +static struct sdl sdl;
> > +
> > +int v4l2_get_index(int fd);
> > +void my_main(void);
> > +
>
> The above looks really odd. Why do you want to make libv4l2 dependent
> on sdl?
I don't, but I had some nasty problems with linker; this should really
go into application but it refused to link. Scary libtool.
> > +static void v4l2_histogram(unsigned char *buf, int cdf[], struct v4l2_format *fmt)
> > +{
> > + for (int y = 0; y < fmt->fmt.pix.height; y+=19)
> > + for (int x = 0; x < fmt->fmt.pix.width; x+=19) {
> > + pixel p = buf_pixel(fmt, buf, x, y);
> > +
> > + int b;
> > + /* HACK: we divide green by 2 to have nice picture, undo it here. */
> > + b = p.r + 2*p.g + p.b;
> > + b = (b * BUCKETS)/(256);
> > + cdf[b]++;
> > + }
> > +}
> > +
> > +static long v4l2_sharpness(unsigned char *buf, struct v4l2_format *fmt)
> > +{
> > + int h = fmt->fmt.pix.height;
> > + int w = fmt->fmt.pix.width;
> > + long r = 0;
> > +
> > + for (int y = h/3; y < h-h/3; y+=h/9)
> > + for (int x = w/3; x < w-w/3; x++) {
> > + pixel p1 = buf_pixel(fmt, buf, x, y);
> > + pixel p2 = buf_pixel(fmt, buf, x+2, y);
> > +
> > + int b1, b2;
> > + /* HACK: we divide green by 2 to have nice picture, undo it here. */
> > + b1 = p1.r + 2*p1.g + p1.b;
> > + b2 = p2.r + 2*p2.g + p2.b;
> > +
> > + int v;
> > + v = (b1-b2)*(b1-b2);
> > + if (v > 36)
> > + r+=v;
> > + }
> > +
> > + return r;
> > +}
>
> IMO, the above belongs to a separate processing module under
> lib/libv4lconvert/processing/
I guess so.
> > +
> > +int v4l2_set_exposure(int fd, int exposure)
> > +{
> > + int index = v4l2_get_index(fd);
> > +
> > + if (index == -1 || devices[index].convert == NULL) {
> > + V4L2_LOG_ERR("v4l2_set_exposure called with invalid fd: %d\n", fd);
> > + errno = EBADF;
> > + return -1;
> > + }
> > +
> > + struct v4l2_control ctrl;
> > + ctrl.id = V4L2_CID_EXPOSURE;
> > + ctrl.value = exposure;
> > + if (ioctl(devices[index].subdev_fds[0], VIDIOC_S_CTRL, &ctrl) < 0) {
> > + printf("Could not set exposure\n");
> > + }
> > + return 0;
> > +}
>
> Shouldn't it be together with lib/libv4lconvert/processing/autogain.c,
> perhaps as an alternative implementation, if what's there is not
> enough?
I'll take a look, thanks.
> > @@ -823,6 +1246,10 @@ int v4l2_close(int fd)
> > {
> > int index, result;
> >
> > + if (fd == -2) {
> > + my_main();
> > + }
> > +
>
> That looks a hack!
That is _the_ hack ;-). Yes, agreed, need to look at
processing/. .. when I get time.
> > +#include <SDL2/SDL.h>
> > +#include <SDL2/SDL_image.h>
>
> If you're adding a SDL-specific application, you'll need to add the
> needed autoconf bits to detect if SDL devel package is installed,
> auto-disabling it if not.
>
> Yet, I don't think that SDL should be part of the library, but,
> instead, part of some application.
Agreed. libtool prevented me from doing the right thing.
> > index 4bffbdd..fda7e3b 100644
> > --- a/utils/decode_tm6000/decode_tm6000.c
> > +++ b/utils/decode_tm6000/decode_tm6000.c
>
> Everything below it is completely wrong!
And most of the stuff above is, too :-). I wanted to get the code out
in case I won't have time...
Thanks,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170424/420fafa1/attachment.sig>
^ permalink raw reply
* [PATCHv2 3/9] dt-bindings: clk: add omap4 clkctrl definitions
From: Tony Lindgren @ 2017-04-24 21:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1489741781-12816-4-git-send-email-t-kristo@ti.com>
Hi Tero,
* Tero Kristo <t-kristo@ti.com> [170317 02:12]:
> Contains offsets for all omap4 clkctrl main and optional clocks.
Can you please sort these by the clock controller instance and
add comments to this file to make easier to read?
This way it will be easy to see how the clocks are grouped
just by looking at this file :)
> --- /dev/null
> +++ b/include/dt-bindings/clock/omap4.h
...
> +#define OMAP4_CLKCTRL_OFFSET 0x20
> +#define OMAP4_CLKCTRL_INDEX(offset) ((offset) - OMAP4_CLKCTRL_OFFSET)
...
Something like below for example:
/* abe clocks */
#define OMAP4_L4_ABE_CLKCTRL OMAP4_CLKCTRL_INDEX(0x20)
> +#define OMAP4_MCPDM_CLKCTRL OMAP4_CLKCTRL_INDEX(0x30)
> +#define OMAP4_DMIC_CLKCTRL OMAP4_CLKCTRL_INDEX(0x38)
> +#define OMAP4_MCASP_CLKCTRL OMAP4_CLKCTRL_INDEX(0x40)
> +#define OMAP4_MCBSP1_CLKCTRL OMAP4_CLKCTRL_INDEX(0x48)
> +#define OMAP4_MCBSP2_CLKCTRL OMAP4_CLKCTRL_INDEX(0x50)
> +#define OMAP4_MCBSP3_CLKCTRL OMAP4_CLKCTRL_INDEX(0x58)
> +#define OMAP4_SLIMBUS1_CLKCTRL OMAP4_CLKCTRL_INDEX(0x60)
> +#define OMAP4_TIMER5_CLKCTRL OMAP4_CLKCTRL_INDEX(0x68)
> +#define OMAP4_TIMER6_CLKCTRL OMAP4_CLKCTRL_INDEX(0x70)
> +#define OMAP4_TIMER7_CLKCTRL OMAP4_CLKCTRL_INDEX(0x78)
> +#define OMAP4_TIMER8_CLKCTRL OMAP4_CLKCTRL_INDEX(0x80)
> +#define OMAP4_WD_TIMER3_CLKCTRL OMAP4_CLKCTRL_INDEX(0x88)
...
/* l3_2 clocks */
> +#define OMAP4_L3_MAIN_2_CLKCTRL OMAP4_CLKCTRL_INDEX(0x20)
> +#define OMAP4_GPMC_CLKCTRL OMAP4_CLKCTRL_INDEX(0x28)
...
Regards,
Tony
^ permalink raw reply
* [PATCH 0/2] net: dsa: b53: BCM11360 support
From: Eric Anholt @ 2017-04-24 21:50 UTC (permalink / raw)
To: linux-arm-kernel
This little patch series follows on from Florian's fixes that he just
sent, and enables the ethernet on the 911360_EP board.
Without Florian's fixes, the controller comes up and forwarding
happens between eth1 and eth2, but the CPU's eth0 packets don't get
forwarded.
Eric Anholt (2):
net: dsa: b53: Add compatible strings for the Cygnus-family BCM11360.
ARM: dts: Add the ethernet and ethernet PHY to the cygnus core DT.
Documentation/devicetree/bindings/net/dsa/b53.txt | 3 ++
arch/arm/boot/dts/bcm-cygnus.dtsi | 60 +++++++++++++++++++++++
arch/arm/boot/dts/bcm911360_entphn.dts | 8 +++
drivers/net/dsa/b53/b53_srab.c | 2 +
4 files changed, 73 insertions(+)
--
2.11.0
^ permalink raw reply
* [PATCH 1/2] net: dsa: b53: Add compatible strings for the Cygnus-family BCM11360.
From: Eric Anholt @ 2017-04-24 21:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170424215022.30382-1-eric@anholt.net>
Cygnus is a small family of SoCs, of which we currently have
devicetree for BCM11360 and BCM58300. The 11360's B53 is mostly the
same as 58xx, just requiring a tiny bit of setup that was previously
missing.
Signed-off-by: Eric Anholt <eric@anholt.net>
---
Documentation/devicetree/bindings/net/dsa/b53.txt | 3 +++
drivers/net/dsa/b53/b53_srab.c | 2 ++
2 files changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/dsa/b53.txt b/Documentation/devicetree/bindings/net/dsa/b53.txt
index d6c6e41648d4..49c93d3c0839 100644
--- a/Documentation/devicetree/bindings/net/dsa/b53.txt
+++ b/Documentation/devicetree/bindings/net/dsa/b53.txt
@@ -29,6 +29,9 @@ Required properties:
"brcm,bcm58625-srab"
"brcm,bcm88312-srab" and the mandatory "brcm,nsp-srab string
+ For the BCM11360 SoC, must be:
+ "brcm,bcm11360-srab" and the mandatory "brcm,cygnus-srab string
+
For the BCM63xx/33xx SoCs with an integrated switch, must be one of:
"brcm,bcm3384-switch"
"brcm,bcm6328-switch"
diff --git a/drivers/net/dsa/b53/b53_srab.c b/drivers/net/dsa/b53/b53_srab.c
index 8a62b6a69703..c37ffd1b6833 100644
--- a/drivers/net/dsa/b53/b53_srab.c
+++ b/drivers/net/dsa/b53/b53_srab.c
@@ -364,6 +364,7 @@ static const struct of_device_id b53_srab_of_match[] = {
{ .compatible = "brcm,bcm53018-srab" },
{ .compatible = "brcm,bcm53019-srab" },
{ .compatible = "brcm,bcm5301x-srab" },
+ { .compatible = "brcm,bcm11360-srab", .data = (void *)BCM58XX_DEVICE_ID },
{ .compatible = "brcm,bcm58522-srab", .data = (void *)BCM58XX_DEVICE_ID },
{ .compatible = "brcm,bcm58525-srab", .data = (void *)BCM58XX_DEVICE_ID },
{ .compatible = "brcm,bcm58535-srab", .data = (void *)BCM58XX_DEVICE_ID },
@@ -371,6 +372,7 @@ static const struct of_device_id b53_srab_of_match[] = {
{ .compatible = "brcm,bcm58623-srab", .data = (void *)BCM58XX_DEVICE_ID },
{ .compatible = "brcm,bcm58625-srab", .data = (void *)BCM58XX_DEVICE_ID },
{ .compatible = "brcm,bcm88312-srab", .data = (void *)BCM58XX_DEVICE_ID },
+ { .compatible = "brcm,cygnus-srab", .data = (void *)BCM58XX_DEVICE_ID },
{ .compatible = "brcm,nsp-srab", .data = (void *)BCM58XX_DEVICE_ID },
{ /* sentinel */ },
};
--
2.11.0
^ permalink raw reply related
* [PATCH 2/2] ARM: dts: Add the ethernet and ethernet PHY to the cygnus core DT.
From: Eric Anholt @ 2017-04-24 21:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170424215022.30382-1-eric@anholt.net>
Cygnus has a single amac controller connected to the B53 switch with 2
PHYs. On the BCM911360_EP platform, those two PHYs are connected to
the external ethernet jacks.
Signed-off-by: Eric Anholt <eric@anholt.net>
---
arch/arm/boot/dts/bcm-cygnus.dtsi | 60 ++++++++++++++++++++++++++++++++++
arch/arm/boot/dts/bcm911360_entphn.dts | 8 +++++
2 files changed, 68 insertions(+)
diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi b/arch/arm/boot/dts/bcm-cygnus.dtsi
index 009f1346b817..318899df9972 100644
--- a/arch/arm/boot/dts/bcm-cygnus.dtsi
+++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
@@ -142,6 +142,56 @@
interrupts = <0>;
};
+ mdio: mdio at 18002000 {
+ compatible = "brcm,iproc-mdio";
+ reg = <0x18002000 0x8>;
+ #size-cells = <1>;
+ #address-cells = <0>;
+
+ gphy0: eth-gphy at 0 {
+ reg = <0>;
+ max-speed = <1000>;
+ };
+
+ gphy1: eth-gphy at 1 {
+ reg = <1>;
+ max-speed = <1000>;
+ };
+ };
+
+ dsa: dsa at 18007000 {
+ compatible = "brcm,bcm11360-srab", "brcm,cygnus-srab";
+ reg = <0x18007000 0x1000>;
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port0 at 0 {
+ reg = <0>;
+ phy-handle = <&gphy0>;
+ phy-mode = "rgmii";
+ };
+
+ port1 at 1 {
+ reg = <1>;
+ phy-handle = <&gphy1>;
+ phy-mode = "rgmii";
+ };
+
+ port8 at 8 {
+ reg = <8>;
+ label = "cpu";
+ ethernet = <ð0>;
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
+ };
+ };
+ };
+
i2c0: i2c at 18008000 {
compatible = "brcm,cygnus-iproc-i2c", "brcm,iproc-i2c";
reg = <0x18008000 0x100>;
@@ -295,6 +345,16 @@
status = "disabled";
};
+ eth0: enet at 18042000 {
+ compatible = "brcm,amac";
+ reg = <0x18042000 0x1000>,
+ <0x18110000 0x1000>;
+ reg-names = "amac_base", "idm_base";
+ interrupts = <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>;
+ max-speed = <1000>;
+ status = "disabled";
+ };
+
nand: nand at 18046000 {
compatible = "brcm,nand-iproc", "brcm,brcmnand-v6.1";
reg = <0x18046000 0x600>, <0xf8105408 0x600>,
diff --git a/arch/arm/boot/dts/bcm911360_entphn.dts b/arch/arm/boot/dts/bcm911360_entphn.dts
index 8b3800f46288..2a1f54ab3574 100644
--- a/arch/arm/boot/dts/bcm911360_entphn.dts
+++ b/arch/arm/boot/dts/bcm911360_entphn.dts
@@ -57,6 +57,14 @@
};
};
+&dsa {
+ status = "okay";
+};
+
+ð0 {
+ status = "okay";
+};
+
&uart3 {
status = "okay";
};
--
2.11.0
^ permalink raw reply related
* [PATCH 1/2] net: dsa: b53: Add compatible strings for the Cygnus-family BCM11360.
From: Florian Fainelli @ 2017-04-24 21:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170424215022.30382-2-eric@anholt.net>
On 04/24/2017 02:50 PM, Eric Anholt wrote:
> Cygnus is a small family of SoCs, of which we currently have
> devicetree for BCM11360 and BCM58300. The 11360's B53 is mostly the
> same as 58xx, just requiring a tiny bit of setup that was previously
> missing.
>
> Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
^ permalink raw reply
* [PATCH 2/2] ARM: dts: Add the ethernet and ethernet PHY to the cygnus core DT.
From: Florian Fainelli @ 2017-04-24 21:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170424215022.30382-3-eric@anholt.net>
On 04/24/2017 02:50 PM, Eric Anholt wrote:
> Cygnus has a single amac controller connected to the B53 switch with 2
> PHYs. On the BCM911360_EP platform, those two PHYs are connected to
> the external ethernet jacks.
>
> Signed-off-by: Eric Anholt <eric@anholt.net>
This looks fine, just a few nits on the label names:
> ---
> arch/arm/boot/dts/bcm-cygnus.dtsi | 60 ++++++++++++++++++++++++++++++++++
> arch/arm/boot/dts/bcm911360_entphn.dts | 8 +++++
> 2 files changed, 68 insertions(+)
>
> diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi b/arch/arm/boot/dts/bcm-cygnus.dtsi
> index 009f1346b817..318899df9972 100644
> --- a/arch/arm/boot/dts/bcm-cygnus.dtsi
> +++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
> @@ -142,6 +142,56 @@
> interrupts = <0>;
> };
>
> + mdio: mdio at 18002000 {
> + compatible = "brcm,iproc-mdio";
> + reg = <0x18002000 0x8>;
> + #size-cells = <1>;
> + #address-cells = <0>;
> +
> + gphy0: eth-gphy at 0 {
> + reg = <0>;
> + max-speed = <1000>;
> + };
> +
> + gphy1: eth-gphy at 1 {
> + reg = <1>;
> + max-speed = <1000>;
> + };
> + };
> +
> + dsa: dsa at 18007000 {
This would be better named switch: switch at 18007000
> + compatible = "brcm,bcm11360-srab", "brcm,cygnus-srab";
> + reg = <0x18007000 0x1000>;
> + status = "disabled";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port0 at 0 {
You can probably just put port at 0
> + reg = <0>;
> + phy-handle = <&gphy0>;
> + phy-mode = "rgmii";
> + };
> +
> + port1 at 1 {
And so on
> + reg = <1>;
> + phy-handle = <&gphy1>;
> + phy-mode = "rgmii";
> + };
> +
> + port8 at 8 {
And so forth
> + reg = <8>;
> + label = "cpu";
> + ethernet = <ð0>;
> + fixed-link {
> + speed = <1000>;
> + full-duplex;
> + };
> + };
> + };
> + };
> +
> i2c0: i2c at 18008000 {
> compatible = "brcm,cygnus-iproc-i2c", "brcm,iproc-i2c";
> reg = <0x18008000 0x100>;
> @@ -295,6 +345,16 @@
> status = "disabled";
> };
>
> + eth0: enet at 18042000 {
> + compatible = "brcm,amac";
> + reg = <0x18042000 0x1000>,
> + <0x18110000 0x1000>;
> + reg-names = "amac_base", "idm_base";
> + interrupts = <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>;
> + max-speed = <1000>;
> + status = "disabled";
> + };
> +
> nand: nand at 18046000 {
> compatible = "brcm,nand-iproc", "brcm,brcmnand-v6.1";
> reg = <0x18046000 0x600>, <0xf8105408 0x600>,
> diff --git a/arch/arm/boot/dts/bcm911360_entphn.dts b/arch/arm/boot/dts/bcm911360_entphn.dts
> index 8b3800f46288..2a1f54ab3574 100644
> --- a/arch/arm/boot/dts/bcm911360_entphn.dts
> +++ b/arch/arm/boot/dts/bcm911360_entphn.dts
> @@ -57,6 +57,14 @@
> };
> };
>
> +&dsa {
> + status = "okay";
> +};
And that would be &switch here then.
With that fixed:
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
> +
> +ð0 {
> + status = "okay";
> +};
> +
> &uart3 {
> status = "okay";
> };
>
--
Florian
^ 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