* [PATCH 0/2] Replace /include/ (dtc) with #include
From: Catalin Marinas @ 2014-01-27 16:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52E63DD8.9070909@samsung.com>
On Mon, Jan 27, 2014 at 11:07:04AM +0000, Pankaj Dubey wrote:
> On 01/10/2014 07:16 PM, Pankaj Dubey wrote:
> > Replace /include/ (dtc) with #include (C pre-processor) for all ARM64
> > based SoC dts files.
> >
> > Pankaj Dubey (2):
> > arm64: dts: use #include for all AppliedMicro device tree files
> > arm64: dts: use #include for all ARM fast model device tree file
> >
> > arch/arm64/boot/dts/apm-mustang.dts | 2 +-
> > arch/arm64/boot/dts/rtsm_ve-aemv8a.dts | 2 +-
> > 2 files changed, 2 insertions(+), 2 deletions(-)
> >
> Gentle ping.
It would be good to include some rationale behind this change and I'm
waiting for the DT guys to ack it.
--
Catalin
^ permalink raw reply
* [alsa-devel] [PATCH RFC v3 0/8] Beaglebone-Black HDMI audio
From: Lars-Peter Clausen @ 2014-01-27 16:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52E686B2.9060806@ti.com>
On 01/27/2014 05:17 PM, Jyri Sarha wrote:
> On 01/27/2014 05:51 PM, Lars-Peter Clausen wrote:
>> Hi,
>>
>> I think you should try to get this in sync with the work Jean-Francois is
>> currently doing[1]. Having the HDMI transmitter register a CODEC device is
>> definitely the right approach, compared to the rather 'interesting'
>> constraints stuff you do in patch 4.
>>
>
> Oh, Jean-Francois's patches are now out. I'll take those into use, but I am
> afraid it still does not save me from the constraint stuff.
>
> The most complex piece of code comes from limited sample-rate availability,
> which is coming Beaglebone-Black desing (available i2s master clock), not
> from the HDMI encoder itself. It does not help with the stereo only
> limitation either, because it comes from the one wire only audio data
> connection on BBB.
>
> Support for S16_LE could maybe be added if the tda998x specific codec would
> fiddle with CTS_N predivider-setting (K select) according to the used sample
> width. But it appears Cobox plays all the sample formats fine without this
> change, so the question is if playing around with CTS_N predivider would
> break already working support there (something to be tested).
The ASoC core will set the constraints for the audio format/rate to the
intersection of what is supported by the CODEC and the CPU DAI. So if the
limitation comes from the CPU DAI the constraints should be applied there
and not in the machine driver. Similar if the tda998x only supports 32 bit
samples it should advertise this and the compound card will only support 32
bit samples.
- Lars
^ permalink raw reply
* [BUG] reproducable ubifs reboot assert and corruption
From: Andrew Ruder @ 2014-01-27 16:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAFLxGvwmzftdQKSjjjwpFLS8g3EJqMrQ2gU2scBsh2MvG7Wyyw@mail.gmail.com>
On Sat, Jan 25, 2014 at 04:02:15PM +0100, Richard Weinberger wrote:
> So ubifs_bgt0_0 stops and the fun begins.
> Can you trigger the issue also by unmounting /mnt?
> I.e umount -l /mnt
> The background thread should only stop after all io is done...
Did some experiments last week to see if I could trigger the bug with
full debug messages enabled. Biggest problem is that I don't have
non-volatile memory available, serial logging slows it down too much to
trigger the bug, and the reboot tends to shut down any attempt to
offload the log to capture the relevant messages.
That being said, I was able to trigger the bug with the following:
[root at buildroot ~]# (sleep 5 ; while ! mount -o remount,ro /mnt ; do true ; done ; echo remount > /dev/kmsg ; sleep 5 ; echo reboot > /dev/kmsg ; reboot ) &
[2] 564
[root at buildroot ~]# fsstress -p 10 -n 10 -X -d /mnt/fsstress -l 0
In my log I can see the "remount" message and 100ms later I can see the
first ubifs assert. I've attached the relevant portion of the logs
below from the first time I see LEB 44 mentioned through the asserts.
I've put the logs on the web due to concerns of flooding the mailing
list with 100's of kB in attachments.
https://gist.github.com/aeruder/8651928
ubi_corruption.txt is the kernel log
afterwards.txt is the console log with the ensuing issue with ubifs
I also have logs of the recovery process in the Linux kernel later on,
(still takes 2 mounts), an image of the MTD device, and would be happy
to try anything or enable any additional debug messages.
> Can you also please find out whether fssstress is still running when
> reboot takes action?
Thanks for taking a look. I'm reading everything I can find about ubifs
to see if I can make some headway into understanding what is going on
but filesytems are definitely not my forte :).
Cheers,
Andrew Ruder
^ permalink raw reply
* imx6: usbhc2/3 and HSIC
From: Christian Gmeiner @ 2014-01-27 16:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390815772.4847.9.camel@weser.hi.pengutronix.de>
Hi Lucas
2014-01-27 Lucas Stach <l.stach@pengutronix.de>:
> Hi Christian,
>
> Am Montag, den 27.01.2014, 10:22 +0100 schrieb Christian Gmeiner:
>> Hi all...
>>
>> does anyone used the usbhc2 or usbhc3 in HSIC mode? I am trying my
>> luck but I do not
>> get it to work. Is there anything special I need to take care of?
>>
> I remember we had this working on a board back in the 3.10 days. The
> only thing I remember which is specific to HSIC is in the attached
> patch. This isn't really clean and should be done in a better way for
> mainline, but maybe it provides some pointers for you.
>
Thanks for the small patch... I got it almost working - the HSIC
device seems to have some problems.
I hope to find some time soon to get this stuff into mainline.
greets
--
Christian Gmeiner, MSc
^ permalink raw reply
* [Q] L1_CACHE_BYTES on flush_pfn_alias function.
From: Catalin Marinas @ 2014-01-27 16:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <003c01cf1a55$623979f0$26ac6dd0$@samsung.com>
Please do not top-post.
On Sun, Jan 26, 2014 at 05:13:43AM +0000, Jungseung Lee wrote:
> Not to flush some more bytes. In the scenario, they can *omit* to flush last 32 bytes.
>
> L1_CACHE_BYTES = 64 (ARM v7, CA9)
>
> asm( "mcrr p15, 0, %1, %0, c14\n"
> " mcr p15, 0, %2, c7, c10, 4"
> :
> : "r" (to), "r" (to + PAGE_SIZE - L1_CACHE_BYTES), "r" (zero)
> : "cc");
Ah, I got it now. I think this should be (to + PAGE_SIZE - 1). My
reading of the ARM ARM is that the bottom bits of the address are
ignored by mcrr.
--
Catalin
^ permalink raw reply
* [PATCH v2] ARM: mm: Fix stage-2 device memory attributes
From: Catalin Marinas @ 2014-01-27 16:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52E64029.6000201@arm.com>
On Mon, Jan 27, 2014 at 11:16:57AM +0000, Marc Zyngier wrote:
> On 24/01/14 23:37, Christoffer Dall wrote:
> > On Sat, Jan 04, 2014 at 08:27:23AM -0800, Christoffer Dall wrote:
> >> --- a/arch/arm/include/asm/pgtable-3level.h
> >> +++ b/arch/arm/include/asm/pgtable-3level.h
> >> @@ -120,13 +120,19 @@
> >> /*
> >> * 2nd stage PTE definitions for LPAE.
> >> */
> >> -#define L_PTE_S2_MT_UNCACHED (_AT(pteval_t, 0x5) << 2) /* MemAttr[3:0] */
> >> -#define L_PTE_S2_MT_WRITETHROUGH (_AT(pteval_t, 0xa) << 2) /* MemAttr[3:0] */
> >> -#define L_PTE_S2_MT_WRITEBACK (_AT(pteval_t, 0xf) << 2) /* MemAttr[3:0] */
> >> -#define L_PTE_S2_RDONLY (_AT(pteval_t, 1) << 6) /* HAP[1] */
> >> -#define L_PTE_S2_RDWR (_AT(pteval_t, 3) << 6) /* HAP[2:1] */
> >> -
> >> -#define L_PMD_S2_RDWR (_AT(pmdval_t, 3) << 6) /* HAP[2:1] */
> >> +#define L_PTE_S2_MT_UNCACHED (_AT(pteval_t, 0x0) << 2) /* strongly ordered */
> >> +#define L_PTE_S2_MT_WRITETHROUGH (_AT(pteval_t, 0xa) << 2) /* normal inner write-through */
> >> +#define L_PTE_S2_MT_WRITEBACK (_AT(pteval_t, 0xf) << 2) /* normal inner write-back */
> >> +#define L_PTE_S2_MT_DEV_SHARED (_AT(pteval_t, 0x1) << 2) /* device */
> >> +#define L_PTE_S2_MT_DEV_NONSHARED (_AT(pteval_t, 0x1) << 2) /* device */
> >> +#define L_PTE_S2_MT_DEV_WC (_AT(pteval_t, 0x5) << 2) /* normal non-cacheable */
> >> +#define L_PTE_S2_MT_DEV_CACHED (_AT(pteval_t, 0xf) << 2) /* normal inner write-back */
> >> +#define L_PTE_S2_MT_MASK (_AT(pteval_t, 0xf) << 2)
> >> +
> >> +#define L_PTE_S2_RDONLY (_AT(pteval_t, 1) << 6) /* HAP[1] */
> >> +#define L_PTE_S2_RDWR (_AT(pteval_t, 3) << 6) /* HAP[2:1] */
> >> +
> >> +#define L_PMD_S2_RDWR (_AT(pmdval_t, 3) << 6) /* HAP[2:1] */
> >>
> >> /*
> >> * Hyp-mode PL2 PTE definitions for LPAE.
>
> The change makes sense to me. arm64 uses a slightly different approach,
> by using a PTE_S2_MEMATTR macro, but I'm not sure that would work for ARM.
>
> Russell, Catalin: could you please have a look at this?
Do we actually need more than Normal Cacheable and Device for stage 2?
--
Catalin
^ permalink raw reply
* [PATCH v2] ARM: mm: Fix stage-2 device memory attributes
From: Marc Zyngier @ 2014-01-27 17:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140127165730.GC8358@arm.com>
On 27/01/14 16:57, Catalin Marinas wrote:
> On Mon, Jan 27, 2014 at 11:16:57AM +0000, Marc Zyngier wrote:
>> On 24/01/14 23:37, Christoffer Dall wrote:
>>> On Sat, Jan 04, 2014 at 08:27:23AM -0800, Christoffer Dall wrote:
>>>> --- a/arch/arm/include/asm/pgtable-3level.h
>>>> +++ b/arch/arm/include/asm/pgtable-3level.h
>>>> @@ -120,13 +120,19 @@
>>>> /*
>>>> * 2nd stage PTE definitions for LPAE.
>>>> */
>>>> -#define L_PTE_S2_MT_UNCACHED (_AT(pteval_t, 0x5) << 2) /* MemAttr[3:0] */
>>>> -#define L_PTE_S2_MT_WRITETHROUGH (_AT(pteval_t, 0xa) << 2) /* MemAttr[3:0] */
>>>> -#define L_PTE_S2_MT_WRITEBACK (_AT(pteval_t, 0xf) << 2) /* MemAttr[3:0] */
>>>> -#define L_PTE_S2_RDONLY (_AT(pteval_t, 1) << 6) /* HAP[1] */
>>>> -#define L_PTE_S2_RDWR (_AT(pteval_t, 3) << 6) /* HAP[2:1] */
>>>> -
>>>> -#define L_PMD_S2_RDWR (_AT(pmdval_t, 3) << 6) /* HAP[2:1] */
>>>> +#define L_PTE_S2_MT_UNCACHED (_AT(pteval_t, 0x0) << 2) /* strongly ordered */
>>>> +#define L_PTE_S2_MT_WRITETHROUGH (_AT(pteval_t, 0xa) << 2) /* normal inner write-through */
>>>> +#define L_PTE_S2_MT_WRITEBACK (_AT(pteval_t, 0xf) << 2) /* normal inner write-back */
>>>> +#define L_PTE_S2_MT_DEV_SHARED (_AT(pteval_t, 0x1) << 2) /* device */
>>>> +#define L_PTE_S2_MT_DEV_NONSHARED (_AT(pteval_t, 0x1) << 2) /* device */
>>>> +#define L_PTE_S2_MT_DEV_WC (_AT(pteval_t, 0x5) << 2) /* normal non-cacheable */
>>>> +#define L_PTE_S2_MT_DEV_CACHED (_AT(pteval_t, 0xf) << 2) /* normal inner write-back */
>>>> +#define L_PTE_S2_MT_MASK (_AT(pteval_t, 0xf) << 2)
>>>> +
>>>> +#define L_PTE_S2_RDONLY (_AT(pteval_t, 1) << 6) /* HAP[1] */
>>>> +#define L_PTE_S2_RDWR (_AT(pteval_t, 3) << 6) /* HAP[2:1] */
>>>> +
>>>> +#define L_PMD_S2_RDWR (_AT(pmdval_t, 3) << 6) /* HAP[2:1] */
>>>>
>>>> /*
>>>> * Hyp-mode PL2 PTE definitions for LPAE.
>>
>> The change makes sense to me. arm64 uses a slightly different approach,
>> by using a PTE_S2_MEMATTR macro, but I'm not sure that would work for ARM.
>>
>> Russell, Catalin: could you please have a look at this?
>
> Do we actually need more than Normal Cacheable and Device for stage 2?
Not so far. As long as these two memory types are enforced as a minimum,
we're quite happy to let the guest use whatever it decides.
I suppose Christoffer introduces them all here as a matter of
completeness, but I don't see them as being useful anytime soon.
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [Q] block / zynq: DMA bouncing
From: Russell King - ARM Linux @ 2014-01-27 17:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <Pine.LNX.4.64.1401271549280.23931@axis700.grange>
On Mon, Jan 27, 2014 at 04:13:56PM +0100, Guennadi Liakhovetski wrote:
> I'm working on an MMC driver with a DMA capability. All has been working
> well, until at some point I've got a bus error, when the mmc driver had
> been handed in a buffer at 0x3000 physical RAM address. The reason is,
> that on Zynq arch bus masters cannot access RAM below 0x80000. Therefore
> my question: how shall I configure this in software?
You're going to run into all sorts of problems here. Normally, the
DMA-able memory is limited to the first N bytes of memory, not "you must
avoid the first N bytes of memory".
Linux has it hard-coded into the memory subsystems that the DMA zone
is from the start of memory to N, the normal zone is from N to H, and
high memory is from H upwards - and allocations for high can fall back
to normal, which can fall back to DMA but not the other way around.
Short of permanently reserving the first 0x80000 bytes of memory, I'm
not sure that there's much which can be done. You may wish to talk to
the MM gurus to see whether there's a modern alternative.
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
^ permalink raw reply
* [PATCH 1/9] ARM: get rid of arch_cpu_idle_prepare()
From: Daniel Lezcano @ 2014-01-27 17:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140127160736.GP15937@n2100.arm.linux.org.uk>
On 01/27/2014 05:07 PM, Russell King - ARM Linux wrote:
> On Mon, Jan 27, 2014 at 09:22:55AM +0100, Daniel Lezcano wrote:
>> On 01/27/2014 07:08 AM, Nicolas Pitre wrote:
>>> ARM and ARM64 are the only two architectures implementing
>>> arch_cpu_idle_prepare() simply to call local_fiq_enable().
>>>
>>> We have secondary_start_kernel() already calling local_fiq_enable() and
>>> this is done a second time in arch_cpu_idle_prepare() in that case. And
>>> enabling FIQs has nothing to do with idling the CPU to start with.
>>>
>>> So let's introduce init_fiq_boot_cpu() to take care of FIQs on the boot
>>> CPU and remove arch_cpu_idle_prepare(). This is now done a bit earlier
>>> at late_initcall time but this shouldn't make a difference in practice
>>> i.e. when FIQs are actually used.
>>>
>>> Signed-off-by: Nicolas Pitre <nico@linaro.org>
>>
>> Reviewed-by: Daniel Lezcano <daniel.lezcano@linaro.org>
>
> What kind of review did you do when giving that attributation?
I did the review to the best of my knowledge and with good will.
I read your comment on this patch and I learnt one more thing.
Today, I am smarter than yesterday and dumber than tomorrow :)
-- 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 1/9] ARM: get rid of arch_cpu_idle_prepare()
From: Russell King - ARM Linux @ 2014-01-27 17:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52E69395.9020004@linaro.org>
On Mon, Jan 27, 2014 at 06:12:53PM +0100, Daniel Lezcano wrote:
> On 01/27/2014 05:07 PM, Russell King - ARM Linux wrote:
>> On Mon, Jan 27, 2014 at 09:22:55AM +0100, Daniel Lezcano wrote:
>>> On 01/27/2014 07:08 AM, Nicolas Pitre wrote:
>>>> ARM and ARM64 are the only two architectures implementing
>>>> arch_cpu_idle_prepare() simply to call local_fiq_enable().
>>>>
>>>> We have secondary_start_kernel() already calling local_fiq_enable() and
>>>> this is done a second time in arch_cpu_idle_prepare() in that case. And
>>>> enabling FIQs has nothing to do with idling the CPU to start with.
>>>>
>>>> So let's introduce init_fiq_boot_cpu() to take care of FIQs on the boot
>>>> CPU and remove arch_cpu_idle_prepare(). This is now done a bit earlier
>>>> at late_initcall time but this shouldn't make a difference in practice
>>>> i.e. when FIQs are actually used.
>>>>
>>>> Signed-off-by: Nicolas Pitre <nico@linaro.org>
>>>
>>> Reviewed-by: Daniel Lezcano <daniel.lezcano@linaro.org>
>>
>> What kind of review did you do when giving that attributation?
>
> I did the review to the best of my knowledge and with good will.
>
> I read your comment on this patch and I learnt one more thing.
>
> Today, I am smarter than yesterday and dumber than tomorrow :)
Just be aware that putting a comment along with the reviewed-by tag
is always a good idea. I know that's a little more work, but this has
been raised a number of times by various people over the years.
A reviewed-by tag on its own doesn't mean much, as it could mean that
you've just glanced over the code and decided "yea, it looks okay", or
it could mean that you've spent all day verifying that the code change
is indeed correct.
Consequently, some will ignore emails which just contain a reviewed-by
attributation.
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
^ permalink raw reply
* [PATCH v2] ARM: mm: Fix stage-2 device memory attributes
From: Catalin Marinas @ 2014-01-27 17:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52E69121.8050500@arm.com>
On Mon, Jan 27, 2014 at 05:02:25PM +0000, Marc Zyngier wrote:
> On 27/01/14 16:57, Catalin Marinas wrote:
> > On Mon, Jan 27, 2014 at 11:16:57AM +0000, Marc Zyngier wrote:
> >> On 24/01/14 23:37, Christoffer Dall wrote:
> >>> On Sat, Jan 04, 2014 at 08:27:23AM -0800, Christoffer Dall wrote:
> >>>> --- a/arch/arm/include/asm/pgtable-3level.h
> >>>> +++ b/arch/arm/include/asm/pgtable-3level.h
> >>>> @@ -120,13 +120,19 @@
> >>>> /*
> >>>> * 2nd stage PTE definitions for LPAE.
> >>>> */
> >>>> -#define L_PTE_S2_MT_UNCACHED (_AT(pteval_t, 0x5) << 2) /* MemAttr[3:0] */
> >>>> -#define L_PTE_S2_MT_WRITETHROUGH (_AT(pteval_t, 0xa) << 2) /* MemAttr[3:0] */
> >>>> -#define L_PTE_S2_MT_WRITEBACK (_AT(pteval_t, 0xf) << 2) /* MemAttr[3:0] */
> >>>> -#define L_PTE_S2_RDONLY (_AT(pteval_t, 1) << 6) /* HAP[1] */
> >>>> -#define L_PTE_S2_RDWR (_AT(pteval_t, 3) << 6) /* HAP[2:1] */
> >>>> -
> >>>> -#define L_PMD_S2_RDWR (_AT(pmdval_t, 3) << 6) /* HAP[2:1] */
> >>>> +#define L_PTE_S2_MT_UNCACHED (_AT(pteval_t, 0x0) << 2) /* strongly ordered */
> >>>> +#define L_PTE_S2_MT_WRITETHROUGH (_AT(pteval_t, 0xa) << 2) /* normal inner write-through */
> >>>> +#define L_PTE_S2_MT_WRITEBACK (_AT(pteval_t, 0xf) << 2) /* normal inner write-back */
> >>>> +#define L_PTE_S2_MT_DEV_SHARED (_AT(pteval_t, 0x1) << 2) /* device */
> >>>> +#define L_PTE_S2_MT_DEV_NONSHARED (_AT(pteval_t, 0x1) << 2) /* device */
> >>>> +#define L_PTE_S2_MT_DEV_WC (_AT(pteval_t, 0x5) << 2) /* normal non-cacheable */
> >>>> +#define L_PTE_S2_MT_DEV_CACHED (_AT(pteval_t, 0xf) << 2) /* normal inner write-back */
> >>>> +#define L_PTE_S2_MT_MASK (_AT(pteval_t, 0xf) << 2)
> >>>> +
> >>>> +#define L_PTE_S2_RDONLY (_AT(pteval_t, 1) << 6) /* HAP[1] */
> >>>> +#define L_PTE_S2_RDWR (_AT(pteval_t, 3) << 6) /* HAP[2:1] */
> >>>> +
> >>>> +#define L_PMD_S2_RDWR (_AT(pmdval_t, 3) << 6) /* HAP[2:1] */
> >>>>
> >>>> /*
> >>>> * Hyp-mode PL2 PTE definitions for LPAE.
> >>
> >> The change makes sense to me. arm64 uses a slightly different approach,
> >> by using a PTE_S2_MEMATTR macro, but I'm not sure that would work for ARM.
> >>
> >> Russell, Catalin: could you please have a look at this?
> >
> > Do we actually need more than Normal Cacheable and Device for stage 2?
>
> Not so far. As long as these two memory types are enforced as a minimum,
> we're quite happy to let the guest use whatever it decides.
>
> I suppose Christoffer introduces them all here as a matter of
> completeness, but I don't see them as being useful anytime soon.
That would be useful on arm if you want cachepolicy= argument to force
the cacheability of guest Normal memory type.
On arm64, the stage 1 memory type is decided via MAIR and that's how we
handle cachepolicy for Normal memory. But for stage 2 this won't work,
the type is explicitly set in the MemAttr encoding. But I don't think we
need host cachepolicy enforced onto guest.
--
Catalin
^ permalink raw reply
* [PATCH 1/9] ARM: get rid of arch_cpu_idle_prepare()
From: Daniel Lezcano @ 2014-01-27 17:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140127172110.GR15937@n2100.arm.linux.org.uk>
On 01/27/2014 06:21 PM, Russell King - ARM Linux wrote:
> On Mon, Jan 27, 2014 at 06:12:53PM +0100, Daniel Lezcano wrote:
>> On 01/27/2014 05:07 PM, Russell King - ARM Linux wrote:
>>> On Mon, Jan 27, 2014 at 09:22:55AM +0100, Daniel Lezcano wrote:
>>>> On 01/27/2014 07:08 AM, Nicolas Pitre wrote:
>>>>> ARM and ARM64 are the only two architectures implementing
>>>>> arch_cpu_idle_prepare() simply to call local_fiq_enable().
>>>>>
>>>>> We have secondary_start_kernel() already calling local_fiq_enable() and
>>>>> this is done a second time in arch_cpu_idle_prepare() in that case. And
>>>>> enabling FIQs has nothing to do with idling the CPU to start with.
>>>>>
>>>>> So let's introduce init_fiq_boot_cpu() to take care of FIQs on the boot
>>>>> CPU and remove arch_cpu_idle_prepare(). This is now done a bit earlier
>>>>> at late_initcall time but this shouldn't make a difference in practice
>>>>> i.e. when FIQs are actually used.
>>>>>
>>>>> Signed-off-by: Nicolas Pitre <nico@linaro.org>
>>>>
>>>> Reviewed-by: Daniel Lezcano <daniel.lezcano@linaro.org>
>>>
>>> What kind of review did you do when giving that attributation?
>>
>> I did the review to the best of my knowledge and with good will.
>>
>> I read your comment on this patch and I learnt one more thing.
>>
>> Today, I am smarter than yesterday and dumber than tomorrow :)
>
> Just be aware that putting a comment along with the reviewed-by tag
> is always a good idea. I know that's a little more work, but this has
> been raised a number of times by various people over the years.
>
> A reviewed-by tag on its own doesn't mean much, as it could mean that
> you've just glanced over the code and decided "yea, it looks okay", or
> it could mean that you've spent all day verifying that the code change
> is indeed correct.
>
> Consequently, some will ignore emails which just contain a reviewed-by
> attributation.
Thanks for the clarification. I will take care of giving a comment next
time.
-- 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 1/9] ARM: get rid of arch_cpu_idle_prepare()
From: Peter Zijlstra @ 2014-01-27 17:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140127172110.GR15937@n2100.arm.linux.org.uk>
On Mon, Jan 27, 2014 at 05:21:10PM +0000, Russell King - ARM Linux wrote:
> A reviewed-by tag on its own doesn't mean much, as it could mean that
> you've just glanced over the code and decided "yea, it looks okay", or
> it could mean that you've spent all day verifying that the code change
> is indeed correct.
One should use Acked-by for the 'yea, it looks okay' thing.
^ permalink raw reply
* [PATCH v5 14/20] watchdog: orion: Add support for Armada 370 and Armada XP SoC
From: Russell King - ARM Linux @ 2014-01-27 17:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390836440-12744-15-git-send-email-ezequiel.garcia@free-electrons.com>
On Mon, Jan 27, 2014 at 12:27:14PM -0300, Ezequiel Garcia wrote:
> +static int armada370_wdt_clock_init(struct platform_device *pdev,
> + struct orion_watchdog *dev)
> +{
> + int ret;
> +
> + dev->clk = devm_clk_get(&pdev->dev, NULL);
> + if (IS_ERR(dev->clk))
> + return PTR_ERR(dev->clk);
> + ret = clk_prepare_enable(dev->clk);
> + if (ret)
> + return ret;
> +
> + /* Setup watchdog input clock */
> + atomic_io_modify(dev->reg + TIMER_CTRL,
> + WDT_A370_RATIO_MASK(WDT_A370_RATIO_SHIFT),
> + WDT_A370_RATIO_MASK(WDT_A370_RATIO_SHIFT));
> +
> + dev->clk_rate = clk_get_rate(dev->clk) / WDT_A370_RATIO;
> + return 0;
> +}
> +
> +static int armadaxp_wdt_clock_init(struct platform_device *pdev,
> + struct orion_watchdog *dev)
> +{
> + int ret;
> +
> + dev->clk = of_clk_get_by_name(pdev->dev.of_node, "fixed");
> + if (IS_ERR(dev->clk))
> + return PTR_ERR(dev->clk);
> + ret = clk_prepare_enable(dev->clk);
> + if (ret)
> + return ret;
> +
> + /* Enable the fixed watchdog clock input */
> + atomic_io_modify(dev->reg + TIMER_CTRL,
> + WDT_AXP_FIXED_ENABLE_BIT,
> + WDT_AXP_FIXED_ENABLE_BIT);
> +
> + dev->clk_rate = clk_get_rate(dev->clk);
> + return 0;
> +}
Doesn't this result in dev->clk being leaked? Or at least a difference
in the way dev->clk needs to be cleaned up between these two functions?
I think it would be better in this case to use the standard clk_get() in
the first function and always use clk_put()... until there is a devm_*
version of the of_clk_get* functions.
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
^ permalink raw reply
* [PATCH 1/9] ARM: get rid of arch_cpu_idle_prepare()
From: Nicolas Pitre @ 2014-01-27 17:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140127160654.GO15937@n2100.arm.linux.org.uk>
On Mon, 27 Jan 2014, Russell King - ARM Linux wrote:
> On Mon, Jan 27, 2014 at 10:45:59AM -0500, Nicolas Pitre wrote:
> > On Mon, 27 Jan 2014, Russell King - ARM Linux wrote:
> >
> > > On Mon, Jan 27, 2014 at 01:08:16AM -0500, Nicolas Pitre wrote:
> > > > ARM and ARM64 are the only two architectures implementing
> > > > arch_cpu_idle_prepare() simply to call local_fiq_enable().
> > > >
> > > > We have secondary_start_kernel() already calling local_fiq_enable() and
> > > > this is done a second time in arch_cpu_idle_prepare() in that case. And
> > > > enabling FIQs has nothing to do with idling the CPU to start with.
> > > >
> > > > So let's introduce init_fiq_boot_cpu() to take care of FIQs on the boot
> > > > CPU and remove arch_cpu_idle_prepare(). This is now done a bit earlier
> > > > at late_initcall time but this shouldn't make a difference in practice
> > > > i.e. when FIQs are actually used.
> > > >
> > > > Signed-off-by: Nicolas Pitre <nico@linaro.org>
> > > > ---
> > > > arch/arm/kernel/process.c | 5 -----
> > > > arch/arm/kernel/setup.c | 7 +++++++
> > > > 2 files changed, 7 insertions(+), 5 deletions(-)
> > > >
> > > > diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c
> > > > index 92f7b15dd2..725b8c95e0 100644
> > > > --- a/arch/arm/kernel/process.c
> > > > +++ b/arch/arm/kernel/process.c
> > > > @@ -142,11 +142,6 @@ static void default_idle(void)
> > > > local_irq_enable();
> > > > }
> > > >
> > > > -void arch_cpu_idle_prepare(void)
> > > > -{
> > > > - local_fiq_enable();
> > > > -}
> > > > -
> > > > void arch_cpu_idle_enter(void)
> > > > {
> > > > ledtrig_cpu(CPU_LED_IDLE_START);
> > > > diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> > > > index 987a7f5bce..d027b1a6fe 100644
> > > > --- a/arch/arm/kernel/setup.c
> > > > +++ b/arch/arm/kernel/setup.c
> > > > @@ -789,6 +789,13 @@ static int __init init_machine_late(void)
> > > > }
> > > > late_initcall(init_machine_late);
> > > >
> > > > +static int __init init_fiq_boot_cpu(void)
> > > > +{
> > > > + local_fiq_enable();
> > > > + return 0;
> > > > +}
> > > > +late_initcall(init_fiq_boot_cpu);
> > >
> > > arch_cpu_idle_prepare() gets called from the swapper thread, and changes
> > > the swapper thread's CPSR. init_fiq_boot_cpu() gets called from PID1, the
> > > init thread, and changes the init thread's CPSR, which will already have
> > > FIQs enabled by way of how kernel threads are created.
> > >
> > > Hence, the above code fragment has no effect what so ever, and those
> > > platforms using FIQs will not have FIQs delivered if they're idle
> > > (because the swapper will have FIQs masked at the CPU.)
> >
> > You're right.
> >
> > What about moving local_fiq_enable() to trap_init() then?
>
> That's potentially unsafe, as we haven't touched any of the IRQ
> controllers at that point - we can't guarantee what state they'd be
> in. Given that the default FIQ is to just return, a FIQ being raised
> at that point will end up with an infinite loop re-entering the FIQ
> handler.
Okay... I don't see any obvious way to work around that besides adding
another explicit hook, which arch_cpu_idle_prepare() incidentally
already is. So, unless you have a better idea, I'll drop this patch and
leave ARM as the only user of arch_cpu_idle_prepare().
Nicolas
^ permalink raw reply
* [Q] block / zynq: DMA bouncing
From: Michal Simek @ 2014-01-27 17:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140127170230.GQ15937@n2100.arm.linux.org.uk>
On 01/27/2014 06:02 PM, Russell King - ARM Linux wrote:
> On Mon, Jan 27, 2014 at 04:13:56PM +0100, Guennadi Liakhovetski wrote:
>> I'm working on an MMC driver with a DMA capability. All has been working
>> well, until at some point I've got a bus error, when the mmc driver had
>> been handed in a buffer at 0x3000 physical RAM address. The reason is,
>> that on Zynq arch bus masters cannot access RAM below 0x80000. Therefore
>> my question: how shall I configure this in software?
>
> You're going to run into all sorts of problems here. Normally, the
> DMA-able memory is limited to the first N bytes of memory, not "you must
> avoid the first N bytes of memory".
>
> Linux has it hard-coded into the memory subsystems that the DMA zone
> is from the start of memory to N, the normal zone is from N to H, and
> high memory is from H upwards - and allocations for high can fall back
> to normal, which can fall back to DMA but not the other way around.
>
> Short of permanently reserving the first 0x80000 bytes of memory, I'm
> not sure that there's much which can be done. You may wish to talk to
> the MM gurus to see whether there's a modern alternative.
We use memblock_reserve for allocation of this space in .reserse phase.
Look at git.xilinx.com - linux repo arch/arm/mach-zynq/common.c
/**
* zynq_memory_init() - Initialize special memory
*
* We need to stop things allocating the low memory as DMA can't work in
* the 1st 512K of memory. Using reserve vs remove is not totally clear yet.
*/
static void __init zynq_memory_init(void)
{
/*
* Reserve the 0-0x4000 addresses (before page tables and kernel)
* which can't be used for DMA
*/
if (!__pa(PAGE_OFFSET))
memblock_reserve(0, 0x4000);
}
DT_MACHINE_START(XILINX_EP107, "Xilinx Zynq Platform")
...
.reserve = zynq_memory_init,
...
MACHINE_END
I have checked why we are reserving just 0 - 0x4000 when kernel starts from 0x8000
and maybe Russell can help me with this better.
I got answer that using memblock_reserve was recommended in past for that.
Why 0x4000? IRC Linux for ARM is using space for any purpose.
Russell knows this much better than I.
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140127/dfd95526/attachment.sig>
^ permalink raw reply
* [PATCH 0/9] ARM: dts: imx: remove the use of pingrp macros
From: Olof Johansson @ 2014-01-27 17:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390668191-20289-1-git-send-email-shawn.guo@linaro.org>
Shawn,
On Sat, Jan 25, 2014 at 8:43 AM, Shawn Guo <shawn.guo@linaro.org> wrote:
> Hi Rob,
>
> In order to solve a pinctrl data efficiency problem, we introduced
> pingrp macros [1] in this development cycle as the base of board dts
> support. The whole imx-dt-3.14 pull request has been held by Olof for
> a few weeks because he wants to get a general approval from DT folks
> on this change. But unfortunately it appears that you are not fond of
> this change.
>
> I just spent the day to create a patch series against imx-dt-3.14 to
> remove these pingrp macros. May I get your nod on this quick
> turn-around, so that we do not miss the merge window?
>
> Hi Olof,
>
> I guess we do not have to shut the door for imx-dt-3.14 if you and DT
> folks are happy with this patch series, which is a quite straight
> forward search&replace change?
The merge window is halfway over already, the time for us to pick up
large branches like these are long past.
Please rebase (since this is a partial revert of some of the earlier
patches in your dt branch, I think?), and resend after -rc1 for 3.15
inclusion.
Thanks,
-Olof
^ permalink raw reply
* [Q] block / zynq: DMA bouncing
From: Russell King - ARM Linux @ 2014-01-27 17:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52E69B4E.5010604@monstr.eu>
On Mon, Jan 27, 2014 at 06:45:50PM +0100, Michal Simek wrote:
> Why 0x4000? IRC Linux for ARM is using space for any purpose.
> Russell knows this much better than I.
Probably because as the kernel is loaded at 0x8000, it will place the
swapper page table at 0x4000, thus covering from 0x4000 upwards.
Thus, the majority of your un-DMA-able memory will be kernel text or
swapper page tables.
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
^ permalink raw reply
* [PATCH] arm64: Add pdev_archdata for dmamask
From: Laura Abbott @ 2014-01-27 17:52 UTC (permalink / raw)
To: linux-arm-kernel
The dma_mask for a device structure is a pointer. This pointer
needs to be set up before the dma mask can actually be set. Most
frameworks in the kernel take care of setting this up properly but
platform devices that don't follow a regular bus structure may not
ever have this set. As a result, checks such as dma_capable will
always return false on a raw platform device and dma_set_mask will
always return -EIO. Fix this by adding a dma_mask in the
platform_device archdata and setting it to be the dma_mask. Devices
used in other frameworks can change this as needed.
Cc: Will Deacon <will.deacon@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Suggested-by: Kumar Gala <galak@codeaurora.org>
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
---
arch/arm64/include/asm/device.h | 1 +
arch/arm64/kernel/setup.c | 7 +++++++
2 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/arch/arm64/include/asm/device.h b/arch/arm64/include/asm/device.h
index cf98b36..209d40c 100644
--- a/arch/arm64/include/asm/device.h
+++ b/arch/arm64/include/asm/device.h
@@ -24,6 +24,7 @@ struct dev_archdata {
};
struct pdev_archdata {
+ u64 dma_mask;
};
#endif
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index bd9bbd0..f164347 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -41,6 +41,7 @@
#include <linux/memblock.h>
#include <linux/of_fdt.h>
#include <linux/of_platform.h>
+#include <linux/dma-mapping.h>
#include <asm/cputype.h>
#include <asm/elf.h>
@@ -337,3 +338,9 @@ const struct seq_operations cpuinfo_op = {
.stop = c_stop,
.show = c_show
};
+
+void arch_setup_pdev_archdata(struct platform_device *pdev)
+{
+ pdev->archdata.dma_mask = DMA_BIT_MASK(32);
+ pdev->dev.dma_mask = &pdev->archdata.dma_mask;
+}
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply related
* [Q] block / zynq: DMA bouncing
From: Michal Simek @ 2014-01-27 17:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140127175231.GU15937@n2100.arm.linux.org.uk>
On 01/27/2014 06:52 PM, Russell King - ARM Linux wrote:
> On Mon, Jan 27, 2014 at 06:45:50PM +0100, Michal Simek wrote:
>> Why 0x4000? IRC Linux for ARM is using space for any purpose.
>> Russell knows this much better than I.
>
> Probably because as the kernel is loaded at 0x8000, it will place the
> swapper page table at 0x4000, thus covering from 0x4000 upwards.
Ah yeah swapper.
>
> Thus, the majority of your un-DMA-able memory will be kernel text or
> swapper page tables.
Yes, exactly.
0x0 - 0x4000 - reserving not to be used by DMA
0x4000 - 0x8000 swapper page table
0x8000 - 0x80000 kernel text + up
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140127/f6b2b00c/attachment.sig>
^ permalink raw reply
* [PATCHv2] arm64: Add CONFIG_CC_STACKPROTECTOR
From: Laura Abbott @ 2014-01-27 17:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140127095958.GA6547@mudshark.cambridge.arm.com>
On 1/27/2014 1:59 AM, Will Deacon wrote:
> Hi Laura,
>
> On Fri, Jan 24, 2014 at 11:09:15PM +0000, Laura Abbott wrote:
>> arm64 currently lacks support for -fstack-protector. Add
>> similar functionality to arm to detect stack corruption.
>
> [...]
>
>> +/*
>> + * Initialize the stackprotector canary value.
>> + *
>> + * NOTE: this must only be called from functions that never return,
>> + * and it must always be inlined.
>> + */
>> +static __always_inline void boot_init_stack_canary(void)
>> +{
>> + unsigned long canary;
>> +
>> + /* Try to get a semi random initial value. */
>> + get_random_bytes(&canary, sizeof(canary));
>> + canary ^= LINUX_VERSION_CODE;
>> +
>> + current->stack_canary = canary;
>
> Do we actually need this line now?
>
Probably not but it seems strange to not have anything there for the
stack canary. Not sure if 'nothing' is better or worse than a possibly
incorrect stack canary that gets automatically created in fork.
Laura
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply
* [alsa-devel] [PATCH RFC v3 0/8] Beaglebone-Black HDMI audio
From: Jean-Francois Moine @ 2014-01-27 18:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52E686B2.9060806@ti.com>
On Mon, 27 Jan 2014 18:17:54 +0200
Jyri Sarha <jsarha@ti.com> wrote:
> Support for S16_LE could maybe be added if the tda998x specific codec
> would fiddle with CTS_N predivider-setting (K select) according to the
> used sample width. But it appears Cobox plays all the sample formats
> fine without this change, so the question is if playing around with
> CTS_N predivider would break already working support there (something to
> be tested).
Jyri,
Setting
cts_n = CTS_N_M(3) | CTS_N_K(1);
instead of K(3) in the I2S sequence of tda998x_configure_audio() in the
tda998x driver works fine for me with S16_LE and S24_LE.
Does this solve your problem?
Russell, do you see any problem about this change?
--
Ken ar c'henta? | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
^ permalink raw reply
* [PATCH RFC v2 1/2] Documentation: arm: add cache DT bindings
From: Lorenzo Pieralisi @ 2014-01-27 18:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140127125839.GL15937@n2100.arm.linux.org.uk>
On Mon, Jan 27, 2014 at 12:58:39PM +0000, Russell King - ARM Linux wrote:
> On Tue, Jan 21, 2014 at 11:49:01AM +0000, Dave Martin wrote:
> > I do have a worry that because the kernel won't normally use this
> > information, by default it will get pasted between .dts files, won't get
> > tested and will be wrong rather often. It also violates the DT principle
> > that probeable information should not be present in the DT -- ePAPR
> > obviously envisages systems where cache geometry information is not
> > probeable, but that's not the case for architected caches on ARM, except
> > in rare cases where the CLIDR is wrong.
>
> That statement is wrong. There are caches on ARM CPUs where there is no
> CLIDR register. I suggest reading the earlier DDI0100 revisions.
You are right, Dave was referring to the cache geometry properties in the
ePAPRv1.1, and the question on whether to ignore them for ARM. True, some
earlier ARM processors would need DT properties to define cache geometry owing
to the lack of cache type/id registers, but I guess we can work around that
and safely rule cache geometry properties out for ARM (better that than
having people rely on dts files containing wrong copy'n'pasted cache
geometry properties, that's the reasoning). The only reason we are defining
these bindings is to make sure we are able to detect which CPUs share what
caches, we can work around the lack of cache type/id registers to probe
geometry in earlier processors in the kernel.
Thanks,
Lorenzo
^ permalink raw reply
* [PATCH RFC v3 2/8] ASoC: davinci-evm: Add named clock reference to DT bindings
From: Mark Brown @ 2014-01-27 18:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a16e2a877740942c1742ac0da403013c72ae3727.1390836773.git.jsarha@ti.com>
On Mon, Jan 27, 2014 at 05:37:51PM +0200, Jyri Sarha wrote:
> The referenced clock is used to get codec clock rate and the clock is
> disabled and enabled in startup and shutdown snd_soc_ops call
> backs. The change is also documented in DT bindigs document.
Applied, thanks.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140127/e1f5b58d/attachment.sig>
^ permalink raw reply
* [PATCH 0/2] Replace /include/ (dtc) with #include
From: Rob Herring @ 2014-01-27 18:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140127163111.GA8358@arm.com>
On Mon, Jan 27, 2014 at 10:31 AM, Catalin Marinas
<catalin.marinas@arm.com> wrote:
> On Mon, Jan 27, 2014 at 11:07:04AM +0000, Pankaj Dubey wrote:
>> On 01/10/2014 07:16 PM, Pankaj Dubey wrote:
>> > Replace /include/ (dtc) with #include (C pre-processor) for all ARM64
>> > based SoC dts files.
>> >
>> > Pankaj Dubey (2):
>> > arm64: dts: use #include for all AppliedMicro device tree files
>> > arm64: dts: use #include for all ARM fast model device tree file
>> >
>> > arch/arm64/boot/dts/apm-mustang.dts | 2 +-
>> > arch/arm64/boot/dts/rtsm_ve-aemv8a.dts | 2 +-
>> > 2 files changed, 2 insertions(+), 2 deletions(-)
>> >
>> Gentle ping.
>
> It would be good to include some rationale behind this change and I'm
> waiting for the DT guys to ack it.
Change this when you actually need it.
Rob
^ 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