* [PATCHv4 0/4] WX checking for arm64
From: Mark Rutland @ 2016-11-07 15:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161030150307.33vc2m7y5y6wzbqc@localhost>
On Sun, Oct 30, 2016 at 03:03:07PM +0000, Catalin Marinas wrote:
> On Thu, Oct 27, 2016 at 09:27:30AM -0700, Laura Abbott wrote:
> > Laura Abbott (4):
> > arm64: dump: Make ptdump debugfs a separate option
> > arm64: dump: Make the page table dumping seq_file optional
> > arm64: dump: Remove max_addr
> > arm64: dump: Add checking for writable and exectuable pages
>
> Queued for 4.10. Thanks.
Catalin mentioned to me that he saw some KASAN splats when testing; it
looks like need a fixup something like the below.
Apologies for not having spotted this when testing!
Thanks,
Mark.
---->8----
>From 06fef1ad1138d0808eec770e64458a350941bd2d Mon Sep 17 00:00:00 2001
From: Mark Rutland <mark.rutland@arm.com>
Date: Mon, 7 Nov 2016 15:24:40 +0000
Subject: [PATCH] Fix KASAN splats with DEBUG_WX
Booting a kernel built with both CONFIG_KASAN and CONFIG_DEBUG_WX
results in a stream of KASAN splats for stack-out-of-bounds accesses,
e.g.
==================================================================
BUG: KASAN: stack-out-of-bounds in note_page+0xd8/0x650 at addr ffff8009364ebdd0
Read of size 8 by task swapper/0/1
page:ffff7e0024d93ac0 count:0 mapcount:0 mapping: (null) index:0x0
flags: 0x4000000000000000()
page dumped because: kasan: bad access detected
CPU: 2 PID: 1 Comm: swapper/0 Not tainted 4.9.0-rc3-00004-g25f7267 #77
Hardware name: ARM Juno development board (r1) (DT)
Call trace:
[<ffff20000808b2d8>] dump_backtrace+0x0/0x278
[<ffff20000808b564>] show_stack+0x14/0x20
[<ffff2000084e4e4c>] dump_stack+0xa4/0xc8
[<ffff200008256ee0>] kasan_report_error+0x4a8/0x4d0
[<ffff200008257330>] kasan_report+0x40/0x48
[<ffff200008255894>] __asan_load8+0x84/0x98
[<ffff2000080a0928>] note_page+0xd8/0x650
[<ffff2000080a0fb4>] walk_pgd.isra.1+0x114/0x220
[<ffff2000080a1248>] ptdump_check_wx+0xa8/0x118
[<ffff20000809ed40>] mark_rodata_ro+0x90/0xd0
[<ffff200008cafb88>] kernel_init+0x28/0x110
[<ffff200008083680>] ret_from_fork+0x10/0x50
Memory state around the buggy address:
ffff8009364ebc80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffff8009364ebd00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>ffff8009364ebd80: 00 00 00 00 f1 f1 f1 f1 00 00 f4 f4 f2 f2 f2 f2
^
ffff8009364ebe00: 00 00 00 00 00 00 00 00 f3 f3 f3 f3 00 00 00 00
ffff8009364ebe80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
==================================================================
... this happens because note_page assumes that the marker array has at
least two elements (the latter of which may be the terminator), but the
marker array for ptdump_check_wx only contains one element. Thus we
dereference some garbage on the stack when looking at
marker[1].start_address.
Given we don't need the markers for the WX checks, we could modify
note_page to allow for a NULL marker array, but for now it's simpler to
add an entry to the ptdump_check_wx marker array, so let's do that. As
it's somewhat confusing to have two identical entries, we add an initial
entry with a start address of zero.
Reported-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
---
arch/arm64/mm/dump.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/mm/dump.c b/arch/arm64/mm/dump.c
index ef8aca8..ca74a2a 100644
--- a/arch/arm64/mm/dump.c
+++ b/arch/arm64/mm/dump.c
@@ -383,6 +383,7 @@ void ptdump_check_wx(void)
struct pg_state st = {
.seq = NULL,
.marker = (struct addr_marker[]) {
+ { 0, NULL},
{ -1, NULL},
},
.check_wx = true,
--
1.9.1
^ permalink raw reply related
* [PATCH] iommu/arm-smmu: Fix out-of-bounds dereference
From: Robin Murphy @ 2016-11-07 15:39 UTC (permalink / raw)
To: linux-arm-kernel
When we iterate a master's config entries, what we generally care
about is the entry's stream map index, rather than the entry index
itself, so it's nice to have the iterator automatically assign the
former from the latter. Unfortunately, booting with KASAN reveals
the oversight that using a simple comma operator results in the
entry index being dereferenced before being checked for validity,
so we always access one element past the end of the fwspec array.
Flip things around so that the check always happens before the index
may be dereferenced.
Fixes: adfec2e709d2 ("iommu/arm-smmu: Convert to iommu_fwspec")
Reported-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
drivers/iommu/arm-smmu.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index f86683eec446..44ffe3a391d6 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -324,8 +324,10 @@ struct arm_smmu_master_cfg {
#define INVALID_SMENDX -1
#define __fwspec_cfg(fw) ((struct arm_smmu_master_cfg *)fw->iommu_priv)
#define fwspec_smmu(fw) (__fwspec_cfg(fw)->smmu)
-#define for_each_cfg_sme(fw, i, idx) \
- for (i = 0; idx = __fwspec_cfg(fw)->smendx[i], i < fw->num_ids; ++i)
+#define for_each_cfg_sme(fw, i, idx) \
+ for (i = 0; \
+ i < fw->num_ids && (idx = __fwspec_cfg(fw)->smendx[i], true); \
+ ++i)
struct arm_smmu_device {
struct device *dev;
--
2.10.2.dirty
^ permalink raw reply related
* [PATCH] staging: vc04_services: add vchiq_pagelist_info structure
From: Michael Zoran @ 2016-11-07 15:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161107100331.GA19666@kroah.com>
On Mon, 2016-11-07 at 11:03 +0100, Greg KH wrote:
> On Mon, Oct 31, 2016 at 01:10:35AM -0700, Michael Zoran wrote:
> > The current dma_map_sg based implementation for bulk messages
> > computes many offsets into a single allocation multiple times in
> > both the create and free code paths.??This is inefficient,
> > error prone and in fact still has a few lingering issues
> > with arm64.
> >
> > This change replaces a small portion of that inplementation with
> > new code that uses a new struct vchiq_pagelist_info to store the
> > needed information rather then complex offset calculations.
> >
> > This improved implementation should be more efficient and easier
> > to understand and maintain.
> >
> > Tests Run(Both Pass):
> > vchiq_test -p 1
> > vchiq_test -f 10
> >
> > Signed-off-by: Michael Zoran <mzoran@crowfest.net>
> > ---
> > ?.../interface/vchiq_arm/vchiq_2835_arm.c???????????| 223
> > +++++++++++----------
> > ?1 file changed, 113 insertions(+), 110 deletions(-)
>
> This doesn't apply to the tree anymore because of your previous patch
> :(
>
> Can you refresh it and resend?
>
> thanks,
>
> greg k-h
OK, I resubmitted it.
Once this patch gets applied 64-bit should be in decent shape. I'm not
seeing any warnings or errors anymore and functional tests from a 64-
bit OS look good.
The only remaining issue that I know of is that it needs a 32-bit
compatibility layer for the ioctls when running a 32-bit OS(Raspbian)
on top of a 64-bit kernel.
^ permalink raw reply
* [PATCH RFC 1/7] dma: pl08x: Add support for the DMA slave map
From: Sylwester Nawrocki @ 2016-11-07 15:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201611050026.49560.arnd@arndb.de>
On 11/05/2016 12:26 AM, Arnd Bergmann wrote:
> On Friday 04 November 2016, Sylwester Nawrocki wrote:
>> + } else {
>> + pl08x->slave.filter.map = pl08x->pd->slave_map;
>> + pl08x->slave.filter.mapcnt = pl08x->pd->slave_map_len;
>> }
>
> I think you miss the setup of the filter function here.
Oops, indeed, there was little chance it could work without that part.
> Filtering by string in this driver is a bit awkward, so I wonder if we
> might want to go one step further here and pass the actual data (i.e.
> struct pl08x_channel_data) rather than the string here.
Yeah, it didn't look to me terribly elegant too. Then a change as below?
--------------8<-------------------
diff --git a/arch/arm/mach-s3c64xx/pl080.c b/arch/arm/mach-s3c64xx/pl080.c
index 8c88680..556ce74 100644
--- a/arch/arm/mach-s3c64xx/pl080.c
+++ b/arch/arm/mach-s3c64xx/pl080.c
@@ -118,22 +118,22 @@ static void pl08x_put_xfer_signal(const struct
pl08x_channel_data *cd, int ch)
};
static const struct dma_slave_map s3c64xx_dma0_slave_map[] = {
- { "s3c6400-uart.0", "tx", (void *)"uart0_tx" },
- { "s3c6400-uart.0", "rx", (void *)"uart0_rx" },
- { "s3c6400-uart.1", "tx", (void *)"uart1_tx" },
- { "s3c6400-uart.1", "rx", (void *)"uart1_rx" },
- { "s3c6400-uart.2", "tx", (void *)"uart2_tx" },
- { "s3c6400-uart.2", "rx", (void *)"uart2_rx" },
- { "s3c6400-uart.3", "tx", (void *)"uart3_tx" },
- { "s3c6400-uart.3", "rx", (void *)"uart3_rx" },
- { "samsung-pcm.0", "tx", (void *)"pcm0_tx" },
- { "samsung-pcm.0", "rx", (void *)"pcm0_rx" },
- { "samsung-i2s.0", "tx", (void *)"i2s0_tx" },
- { "samsung-i2s.0", "rx", (void *)"i2s0_rx" },
- { "s3c6410-spi.0", "tx", (void *)"spi0_tx" },
- { "s3c6410-spi.0", "rx", (void *)"spi0_rx" },
- { "samsung-i2s.2", "tx", (void *)"i2s2_tx" },
- { "samsung-i2s.2", "rx", (void *)"i2s2_rx" },
+ { "s3c6400-uart.0", "tx", (void *)&s3c64xx_dma0_info[0] },
+ { "s3c6400-uart.0", "rx", (void *)&s3c64xx_dma0_info[1] },
+ { "s3c6400-uart.1", "tx", (void *)&s3c64xx_dma0_info[2] },
+ { "s3c6400-uart.1", "rx", (void *)&s3c64xx_dma0_info[3] },
+ { "s3c6400-uart.2", "tx", (void *)&s3c64xx_dma0_info[4] },
+ { "s3c6400-uart.2", "rx", (void *)&s3c64xx_dma0_info[5] },
+ { "s3c6400-uart.3", "tx", (void *)&s3c64xx_dma0_info[6] },
+ { "s3c6400-uart.3", "rx", (void *)&s3c64xx_dma0_info[7] },
+ { "samsung-pcm.0", "tx", (void *)&s3c64xx_dma0_info[8] },
+ { "samsung-pcm.0", "rx", (void *)&s3c64xx_dma0_info[9] },
+ { "samsung-i2s.0", "tx", (void *)&s3c64xx_dma0_info[10] },
+ { "samsung-i2s.0", "rx", (void *)&s3c64xx_dma0_info[11] },
+ { "s3c6410-spi.0", "tx", (void *)&s3c64xx_dma0_info[12] },
+ { "s3c6410-spi.0", "rx", (void *)&s3c64xx_dma0_info[13] },
+ { "samsung-i2s.2", "tx", (void *)&s3c64xx_dma0_info[14] },
+ { "samsung-i2s.2", "rx", (void *)&s3c64xx_dma0_info[15] },
};
@@ -229,12 +229,12 @@ static AMBA_AHB_DEVICE(s3c64xx_dma0, "dma-pl080s.0", 0,
};
static const struct dma_slave_map s3c64xx_dma1_slave_map[] = {
- { "samsung-pcm.1", "tx", (void *)"pcm1_tx" },
- { "samsung-pcm.1", "rx", (void *)"pcm1_rx" },
- { "samsung-i2s.1", "tx", (void *)"i2s1_tx" },
- { "samsung-i2s.1", "rx", (void *)"i2s1_rx" },
- { "s3c6410-spi.1", "tx", (void *)"spi1_tx" },
- { "s3c6410-spi.1", "rx", (void *)"spi1_rx" },
+ { "samsung-pcm.1", "tx", (void *)&s3c64xx_dma1_info[0] },
+ { "samsung-pcm.1", "rx", (void *)&s3c64xx_dma1_info[1] },
+ { "samsung-i2s.1", "tx", (void *)&s3c64xx_dma1_info[2] },
+ { "samsung-i2s.1", "rx", (void *)&s3c64xx_dma1_info[3] },
+ { "s3c6410-spi.1", "tx", (void *)&s3c64xx_dma1_info[4] },
+ { "s3c6410-spi.1", "rx", (void *)&s3c64xx_dma1_info[5] },
};
diff --git a/drivers/dma/amba-pl08x.c b/drivers/dma/amba-pl08x.c
index d5c75c8..0d1eb2e 100644
--- a/drivers/dma/amba-pl08x.c
+++ b/drivers/dma/amba-pl08x.c
@@ -1793,6 +1793,23 @@ bool pl08x_filter_id(struct dma_chan *chan, void *chan_id)
}
EXPORT_SYMBOL_GPL(pl08x_filter_id);
+static bool pl08x_filter_fn(struct dma_chan *chan, void *chan_id)
+{
+ struct pl08x_dma_chan *plchan;
+
+ /* Reject channels for devices not bound to this driver */
+ if (chan->device->dev->driver != &pl08x_amba_driver.drv)
+ return false;
+
+ plchan = to_pl08x_chan(chan);
+
+ /* Check that the channel is not taken! */
+ if (plchan->cd == chan_id)
+ return true;
+
+ return false;
+}
+
/*
* Just check that the device is there and active
* TODO: turn this bit on/off depending on the number of physical channels
@@ -2310,6 +2327,7 @@ static int pl08x_probe(struct amba_device *adev, const
struct amba_id *id)
} else {
pl08x->slave.filter.map = pl08x->pd->slave_map;
pl08x->slave.filter.mapcnt = pl08x->pd->slave_map_len;
+ pl08x->slave.filter.fn = pl08x_filter_fn;
}
/* By default, AHB1 only. If dualmaster, from platform */
-------------->8-------------------
--
Thanks,
Sylwester
^ permalink raw reply related
* [PATCH] coresight: Add support for ARM Coresight STM-500
From: Mathieu Poirier @ 2016-11-07 15:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478103591-7662-1-git-send-email-suzuki.poulose@arm.com>
On 2 November 2016 at 10:19, Suzuki K Poulose <suzuki.poulose@arm.com> wrote:
> Add the PIDs for STM-500 to the known STM devices list.
>
> Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
> Cc: Chunyan Zhang <zhang.chunyan@linaro.org>
> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> ---
> drivers/hwtracing/coresight/coresight-stm.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/hwtracing/coresight/coresight-stm.c b/drivers/hwtracing/coresight/coresight-stm.c
> index 49e0f1b..3524452 100644
> --- a/drivers/hwtracing/coresight/coresight-stm.c
> +++ b/drivers/hwtracing/coresight/coresight-stm.c
> @@ -920,6 +920,11 @@ static struct amba_id stm_ids[] = {
> .mask = 0x0003ffff,
> .data = "STM32",
> },
> + {
> + .id = 0x0003b963,
> + .mask = 0x0003ffff,
> + .data = "STM500",
> + },
> { 0, 0},
> };
Applied - thanks,
Mathieu
>
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH 0/5] drm/sun4i: Handle TV overscan
From: Russell King - ARM Linux @ 2016-11-07 15:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161107150909.rcte56amjkmd6mhx@lukather>
On Mon, Nov 07, 2016 at 04:09:09PM +0100, Maxime Ripard wrote:
> Hi Russell,
>
> On Thu, Nov 03, 2016 at 09:54:45AM +0000, Russell King - ARM Linux wrote:
> > > Yes. And that is an XBMC only solution, that doesn't work with the
> > > fbdev emulation and is probably doing an additional composition to
> > > scale down and center their frames through OpenGL.
> >
> > Well, it will have to be doing a scaling step anyway. If the video
> > frame is a different size to the active area, scaling is required
> > no matter what. A 576p SD image needs to be scaled up, and a 1080p
> > image would need to be scaled down for a 1080p overscanned display
> > with a reduced active area to counter the overscanning - no matter
> > how you do it.
>
> Yes, except that scaling is not always an option. In my particular
> example, there's no scaler after the CRTC, which essentially prevents
> it from being used in that use case. Which is also why I ended up
> reducing the mode reported to the user.
I think you completely missed my point. Let me try again.
If you expose a reduced mode to the user, you are reporting that (eg)
the 1080p-timings mode does not have 1920 pixels horizontally, and
1080 lines. You are instead reporting that it has (eg) 1800 pixels
horizontally and maybe 1000 lines.
So, when you play back a 1080 video, you are going to have to either:
1. crop the extra 120 pixels horizontally and 80 lines vertically
or
2. scale the image.
However, this is a completely independent issue to how we go about
setting a video mode that is 1800x1000 in the first place.
What you're suggesting is that we add code to the kernel to report that
your non-EDID, analogue output transforms the standard 1920x1080 timings
such that it has a 1800x1000 active area.
I'm suggesting instead that you can do the same thing in userspace by
specifically adding a mode which has the 1920x1080 standard timings,
but with the porches increased and the active area reduced - in exactly
the same way that you'd have to do within the kernel to report your
active-area-reduced 1800x1000 mode.
> > For graphics, userspace could add mode(s) with increased porches and
> > reduced active area itself to achieve an underscanned display on a
> > timing which the display device always overscans - there's no need to
> > do that in the kernel, all the APIs are there to be able to do it
> > already.
> >
> > That means your framebuffer will be smaller, but that's the case
> > anyway.
>
> Yes, that would be a good idea. But it's not always an option for
> applications that would rely on the fbdev emulation (like QT's eglfs),
> which would then have no way to change whatever default there is (and
> the only one able to know how bad it actually is is the user).
I guess this is the problem with DRM people wanting to deprecate fbdev...
too much stuff currently relies upon it, but DRM on x86 has always had
the reduced functionality.
I guess there's two solutions here:
1. Either DRMs fbdev gains increased functionality, or
2. The fbdev-only applications/libraries need to be ported over to
support DRM natively.
This has been a bar for some time to moving over to DRM, and I've heard
very little desire on either side to find some sort of compromise on the
issue, so I guess things are rather stuck where they are.
> > So, I may want my graphics to appear on an overscanned display such
> > that I can see the borders, but I may want the overlaid video to use
> > the full active area (including overscan) to hide some of the broadcast
> > mess at the edges of the screen.
> >
> > > > Yea, that's quite sad, "analog" has become a dirty word, but really
> > > > this has nothing to do with "analog" at all - there are LCD TVs (and
> > > > some monitors) out there which take HDMI signals but refuse to
> > > > disable overscan no matter what you do to them if you provide them
> > > > with a "broadcast" mode - so the analog excuse is very poor.
> > >
> > > I'd agree with you, but I was also told to not turn that into a
> > > generic code and deal with that in my driver.
> >
> > I guess whoever told you that was wrong. I used to have a cheap TV
> > here which took HDMI, and always overscans broadcast modes, and
> > underscans PC modes. No amount of fiddling with various settings
> > (either in the TV or AVI frames) changes that.
> >
> > I've run into that with a _monitor_ that Andrew Hutton has, which has
> > a HDMI input - exactly the same thing - 1080p, 720p etc are all
> > unconditionally overscanned, 1024x768 etc are all unconditionally
> > underscanned and there's nothing that can be done to change it.
> >
> > The problem is that TVs are at liberty to have this behaviour, so
> > the overscaned problem is always going to be there, and each driver
> > should not be dealing with it in their own specific ways.
>
> I agree with you, however, without any directions on how to do this,
> and willingness to merge this, I don't really see why we would work on
> such a generic implementation in the first place.
As I've already said - if you've been told that a generic implementation
is wrong, then I suspect that either those who told you that either
failed to understand the problem, or they failed to appreciate just what
a problem it is.
I guess if DRM folk want to keep throwing up blocks in the way to moving
forward, then we'll end up with lots of hacks in various random trees to
work around the various issues, and everything will end up in a total
mess.
This is _not_ a driver specific problem, it _is_ a _generic_ problem.
I guess DRM folk have nice expensive display devices which don't exhibit
the problem, so they just don't give a damn - which basically means
they're out of touch with the rest of the world. This isn't a problem
that's going to go away just because DRM folk want it to, and it's not
limited to "obsolete analogue" either.
I'd go as far as to say that DRM people are totally wrong to tell you
that a solution to this should not be generic, period. I think I've
made that point several times through the course of this discussion
already.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH] iommu/arm-smmu: Fix out-of-bounds dereference
From: Mark Rutland @ 2016-11-07 15:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <dea89ff1b2bd97b08d72f5c32fcf228bec767142.1478533142.git.robin.murphy@arm.com>
On Mon, Nov 07, 2016 at 03:39:02PM +0000, Robin Murphy wrote:
> When we iterate a master's config entries, what we generally care
> about is the entry's stream map index, rather than the entry index
> itself, so it's nice to have the iterator automatically assign the
> former from the latter. Unfortunately, booting with KASAN reveals
> the oversight that using a simple comma operator results in the
> entry index being dereferenced before being checked for validity,
> so we always access one element past the end of the fwspec array.
>
> Flip things around so that the check always happens before the index
> may be dereferenced.
>
> Fixes: adfec2e709d2 ("iommu/arm-smmu: Convert to iommu_fwspec")
> Reported-by: Mark Rutland <mark.rutland@arm.com>
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
This patch fixes the KASAN splats as I saw (example below).
With this patch applied, my dmesg is free of errors.
So feel free to add:
Tested-by: Mark Rutland <mark.rutland@arm.com>
Thanks,
Mark.
==================================================================
BUG: KASAN: slab-out-of-bounds in arm_smmu_add_device+0x510/0x960 at addr ffff800935c6e72c
Read of size 2 by task swapper/0/1
CPU: 4 PID: 1 Comm: swapper/0 Not tainted 4.9.0-rc3-00005-g8cc374c #79
Hardware name: ARM Juno development board (r1) (DT)
Call trace:
[<ffff20000808b2d8>] dump_backtrace+0x0/0x278
[<ffff20000808b564>] show_stack+0x14/0x20
[<ffff2000084e4e4c>] dump_stack+0xa4/0xc8
[<ffff200008256984>] kasan_object_err+0x24/0x80
[<ffff200008256c40>] kasan_report_error+0x208/0x4d0
[<ffff200008257330>] kasan_report+0x40/0x48
[<ffff200008255624>] __asan_load2+0x84/0x98
[<ffff200008743e80>] arm_smmu_add_device+0x510/0x960
[<ffff20000873acf8>] iommu_bus_notifier+0x120/0x160
[<ffff2000081038e4>] notifier_call_chain+0x6c/0xb8
[<ffff200008103dfc>] __blocking_notifier_call_chain+0x5c/0xa0
[<ffff200008103e54>] blocking_notifier_call_chain+0x14/0x20
[<ffff20000874ef98>] device_add+0x5c8/0x840
[<ffff20000863d574>] amba_device_try_add+0x1cc/0x298
[<ffff20000863d7a8>] amba_device_add+0x20/0x148
[<ffff200008ad4344>] of_platform_bus_create+0x34c/0x428
[<ffff200008ad4554>] of_platform_populate+0x4c/0xb8
[<ffff200009389c9c>] of_platform_default_populate_init+0x78/0x8c
[<ffff200008083a28>] do_one_initcall+0x90/0x1c8
[<ffff200009331038>] kernel_init_freeable+0x280/0x324
[<ffff200008cb5d00>] kernel_init+0x10/0x110
[<ffff200008083680>] ret_from_fork+0x10/0x50
Object at ffff800935c6e700, in cache kmalloc-128 size: 128
Allocated:
PID = 1
[<ffff20000808ac90>] save_stack_trace_tsk+0x0/0x180
[<ffff20000808ae38>] save_stack_trace+0x28/0x38
[<ffff200008255ebc>] kasan_kmalloc+0xdc/0x188
[<ffff200008252780>] __kmalloc+0x148/0x238
[<ffff200008743b38>] arm_smmu_add_device+0x1c8/0x960
[<ffff20000873acf8>] iommu_bus_notifier+0x120/0x160
[<ffff2000081038e4>] notifier_call_chain+0x6c/0xb8
[<ffff200008103dfc>] __blocking_notifier_call_chain+0x5c/0xa0
[<ffff200008103e54>] blocking_notifier_call_chain+0x14/0x20
[<ffff20000874ef98>] device_add+0x5c8/0x840
[<ffff20000863d574>] amba_device_try_add+0x1cc/0x298
[<ffff20000863d7a8>] amba_device_add+0x20/0x148
[<ffff200008ad4344>] of_platform_bus_create+0x34c/0x428
[<ffff200008ad4554>] of_platform_populate+0x4c/0xb8
[<ffff200009389c9c>] of_platform_default_populate_init+0x78/0x8c
[<ffff200008083a28>] do_one_initcall+0x90/0x1c8
[<ffff200009331038>] kernel_init_freeable+0x280/0x324
[<ffff200008cb5d00>] kernel_init+0x10/0x110
[<ffff200008083680>] ret_from_fork+0x10/0x50
Freed:
PID = 0
(stack is not available)
Memory state around the buggy address:
ffff800935c6e600: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff800935c6e680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>ffff800935c6e700: 00 00 00 00 00 04 fc fc fc fc fc fc fc fc fc fc
^
ffff800935c6e780: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff800935c6e800: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
==================================================================
^ permalink raw reply
* [PATCH v2 1/2] regulator: Add coupled regulator
From: Maxime Ripard @ 2016-11-07 15:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160205153258.GW4455@sirena.org.uk>
Hi Mark,
On Fri, Feb 05, 2016 at 03:32:58PM +0000, Mark Brown wrote:
> On Fri, Feb 05, 2016 at 03:33:28PM +0100, Maxime Ripard wrote:
> > On Thu, Jan 21, 2016 at 04:28:02PM +0000, Mark Brown wrote:
> > > On Thu, Jan 21, 2016 at 04:46:49PM +0100, Maxime Ripard wrote:
>
> > > > Anyway, I'm fine with both approaches, just let me know what you
> > > > prefer.
>
> > > Without seeing an implementation of the lists it's hard to say.
>
> > Just to make sure we're on the same page: you want to keep the
> > regulator, but instead of giving the parent through vinX-supplies
> > properties, you want to have a single *-supply property, with a list
> > of regulators, right?
>
> Either that or an explicit regulator describing the merge. Rob wants
> the list I think but I really don't care.
So, I'm reviving this old thread after speaking to you about it at
ELCE and trying to code something up, and getting lost..
To put a bit of context, I'm still trying to tackle the issue of
devices that have two regulators powering them on the same pin for
example when each regulator cannot provide enough current alone to
power the device (all the setups like this one I've seen so far were
for WiFi chips, but it might be different).
I guess we already agreed on the fact that the DT binding should just
be to allow a *-supply property to take multiple regulators, and mark
them as "coupled" (or whatever name we see fit) in such a case.
Since regulator_get returns a struct regulator pointer, it felt
logical to try to add the list of parent regulators to it, especially
as this structure is per-consumer, and different consumers might have
different combinations of regulators.
However, this structure embeds a pointer to a struct regulator_dev,
which seems to model the regulator itself, but will also contain
pointer to the struct regulator, probably to model its parent? I guess
my first question would be do we care about nesting? or having a
regulator with multiple parents?
It also contains the constraints on each regulator, which might or
might not be different for each of the coupled regulators, but I'm
guessing the couple might have contraints of its own too I guess. Is
it something that might happen? Should we care about it?
And finally, my real question is, do we want to aggregate them in
struct regulator, at the consumer level, which might make the more
sense, or do we want to create an intermediate regulator internally?
What is your take on this?
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161107/133eabc8/attachment.sig>
^ permalink raw reply
* [PATCH] ARM: cache-uniphier: include <linux/errno.h> instead of <linux/types.h>
From: Masahiro Yamada @ 2016-11-07 15:58 UTC (permalink / raw)
To: linux-arm-kernel
Nothing in this header file depends on <linux/types.h>.
Rather, <linux/errno.h> should be included for -ENODEV.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---
KernelVersion: 4.9-rc1
arch/arm/include/asm/hardware/cache-uniphier.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/include/asm/hardware/cache-uniphier.h b/arch/arm/include/asm/hardware/cache-uniphier.h
index eaa60da..0ef42ae 100644
--- a/arch/arm/include/asm/hardware/cache-uniphier.h
+++ b/arch/arm/include/asm/hardware/cache-uniphier.h
@@ -16,7 +16,7 @@
#ifndef __CACHE_UNIPHIER_H
#define __CACHE_UNIPHIER_H
-#include <linux/types.h>
+#include <linux/errno.h>
#ifdef CONFIG_CACHE_UNIPHIER
int uniphier_cache_init(void);
--
1.9.1
^ permalink raw reply related
* [PATCH RFC 4/7] ASoC: samsung: i2s: Do not use platform_data for DMA parameters
From: Sylwester Nawrocki @ 2016-11-07 16:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201611050029.18984.arnd@arndb.de>
On 11/05/2016 12:29 AM, Arnd Bergmann wrote:
> On Friday 04 November 2016, Sylwester Nawrocki wrote:
>> > - ret = samsung_asoc_dma_platform_register(&pdev->dev, pri_dai->filter,
>> > + ret = samsung_asoc_dma_platform_register(&pdev->dev, NULL,
>> > NULL, NULL);
>
> If we remove the filter argument from every caller here, maybe we should also
> change the prototype to not expect those three NULL arguments any more.
There is one occurrence where the third argument needs to be not NULL.
I'm planning to modify sound/sound/samsung/i2s.c so there is no need
to create another platform device just for the overlay DAI, afterwards
the above function could be simplified.
--
Thanks,
Sylwester
^ permalink raw reply
* [PATCH] ARM: cache-uniphier: include <linux/errno.h> instead of <linux/types.h>
From: Russell King - ARM Linux @ 2016-11-07 16:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478534334-15562-1-git-send-email-yamada.masahiro@socionext.com>
On Tue, Nov 08, 2016 at 12:58:54AM +0900, Masahiro Yamada wrote:
> Nothing in this header file depends on <linux/types.h>.
> Rather, <linux/errno.h> should be included for -ENODEV.
So how do we end up with a definition for u32?
I think you need both these include files.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCHv4 0/4] WX checking for arm64
From: Laura Abbott @ 2016-11-07 16:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161107153802.GJ19796@leverpostej>
On 11/07/2016 07:38 AM, Mark Rutland wrote:
> On Sun, Oct 30, 2016 at 03:03:07PM +0000, Catalin Marinas wrote:
>> On Thu, Oct 27, 2016 at 09:27:30AM -0700, Laura Abbott wrote:
>>> Laura Abbott (4):
>>> arm64: dump: Make ptdump debugfs a separate option
>>> arm64: dump: Make the page table dumping seq_file optional
>>> arm64: dump: Remove max_addr
>>> arm64: dump: Add checking for writable and exectuable pages
>>
>> Queued for 4.10. Thanks.
>
> Catalin mentioned to me that he saw some KASAN splats when testing; it
> looks like need a fixup something like the below.
>
> Apologies for not having spotted this when testing!
>
> Thanks,
> Mark.
>
> ---->8----
> From 06fef1ad1138d0808eec770e64458a350941bd2d Mon Sep 17 00:00:00 2001
> From: Mark Rutland <mark.rutland@arm.com>
> Date: Mon, 7 Nov 2016 15:24:40 +0000
> Subject: [PATCH] Fix KASAN splats with DEBUG_WX
>
> Booting a kernel built with both CONFIG_KASAN and CONFIG_DEBUG_WX
> results in a stream of KASAN splats for stack-out-of-bounds accesses,
> e.g.
>
> ==================================================================
> BUG: KASAN: stack-out-of-bounds in note_page+0xd8/0x650 at addr ffff8009364ebdd0
> Read of size 8 by task swapper/0/1
> page:ffff7e0024d93ac0 count:0 mapcount:0 mapping: (null) index:0x0
> flags: 0x4000000000000000()
> page dumped because: kasan: bad access detected
> CPU: 2 PID: 1 Comm: swapper/0 Not tainted 4.9.0-rc3-00004-g25f7267 #77
> Hardware name: ARM Juno development board (r1) (DT)
> Call trace:
> [<ffff20000808b2d8>] dump_backtrace+0x0/0x278
> [<ffff20000808b564>] show_stack+0x14/0x20
> [<ffff2000084e4e4c>] dump_stack+0xa4/0xc8
> [<ffff200008256ee0>] kasan_report_error+0x4a8/0x4d0
> [<ffff200008257330>] kasan_report+0x40/0x48
> [<ffff200008255894>] __asan_load8+0x84/0x98
> [<ffff2000080a0928>] note_page+0xd8/0x650
> [<ffff2000080a0fb4>] walk_pgd.isra.1+0x114/0x220
> [<ffff2000080a1248>] ptdump_check_wx+0xa8/0x118
> [<ffff20000809ed40>] mark_rodata_ro+0x90/0xd0
> [<ffff200008cafb88>] kernel_init+0x28/0x110
> [<ffff200008083680>] ret_from_fork+0x10/0x50
> Memory state around the buggy address:
> ffff8009364ebc80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> ffff8009364ebd00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>> ffff8009364ebd80: 00 00 00 00 f1 f1 f1 f1 00 00 f4 f4 f2 f2 f2 f2
> ^
> ffff8009364ebe00: 00 00 00 00 00 00 00 00 f3 f3 f3 f3 00 00 00 00
> ffff8009364ebe80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> ==================================================================
>
> ... this happens because note_page assumes that the marker array has at
> least two elements (the latter of which may be the terminator), but the
> marker array for ptdump_check_wx only contains one element. Thus we
> dereference some garbage on the stack when looking at
> marker[1].start_address.
>
> Given we don't need the markers for the WX checks, we could modify
> note_page to allow for a NULL marker array, but for now it's simpler to
> add an entry to the ptdump_check_wx marker array, so let's do that. As
> it's somewhat confusing to have two identical entries, we add an initial
> entry with a start address of zero.
>
> Reported-by: Catalin Marinas <catalin.marinas@arm.com>
> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> ---
> arch/arm64/mm/dump.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm64/mm/dump.c b/arch/arm64/mm/dump.c
> index ef8aca8..ca74a2a 100644
> --- a/arch/arm64/mm/dump.c
> +++ b/arch/arm64/mm/dump.c
> @@ -383,6 +383,7 @@ void ptdump_check_wx(void)
> struct pg_state st = {
> .seq = NULL,
> .marker = (struct addr_marker[]) {
> + { 0, NULL},
> { -1, NULL},
> },
> .check_wx = true,
>
Acked-by: Laura Abbott <labbott@redhat.com>
^ permalink raw reply
* [PATCH] convert orion5x ls-chl to device tree
From: Gregory CLEMENT @ 2016-11-07 16:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <636b2eb5-a23d-1e87-2bf6-5c1cc1f8332b@gmail.com>
Hi Ash,
On dim., nov. 06 2016, Ash Hughes <sehguh.hsa@gmail.com> wrote:
> Sorry about that, formatting error with tabs being converted to spaces
> in email. This should now apply.
I applied it to mvebu/dt.
Next time could you send it in a separate email?
Also, for device tree the topic should start by "ARM: dts: orion5x:".
And last point in your second version you forgot the commit log, I took
care of it too by using the one from your first version.
Thanks,
Gregory
>
> Ash
> ---
> From 398d2c6e5c834e6887a5e6b5e898455977d0c00b Mon Sep 17 00:00:00 2001
> From: Ashley Hughes <ashley.hughes@blueyonder.co.uk>
> Date: Sun, 9 Oct 2016 17:04:12 +0100
> Subject: [PATCH] convert ls-chl to FDT
>
> Signed-off-by: Ashley Hughes <ashley.hughes@blueyonder.co.uk>
> ---
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/orion5x-lschl.dts | 171 ++++++++++++++++++
> arch/arm/mach-orion5x/Kconfig | 4 +-
> arch/arm/mach-orion5x/Makefile | 1 -
> arch/arm/mach-orion5x/ls-chl-setup.c | 331 -----------------------------------
> 5 files changed, 174 insertions(+), 334 deletions(-)
> create mode 100644 arch/arm/boot/dts/orion5x-lschl.dts
> delete mode 100644 arch/arm/mach-orion5x/ls-chl-setup.c
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index befcd26..4853049 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -597,6 +597,7 @@ dtb-$(CONFIG_ARCH_ORION5X) += \
> orion5x-lacie-ethernet-disk-mini-v2.dtb \
> orion5x-linkstation-lsgl.dtb \
> orion5x-linkstation-lswtgl.dtb \
> + orion5x-lschl.dtb \
> orion5x-lswsgl.dtb \
> orion5x-maxtor-shared-storage-2.dtb \
> orion5x-netgear-wnr854t.dtb \
> diff --git a/arch/arm/boot/dts/orion5x-lschl.dts b/arch/arm/boot/dts/orion5x-lschl.dts
> new file mode 100644
> index 0000000..9474092
> --- /dev/null
> +++ b/arch/arm/boot/dts/orion5x-lschl.dts
> @@ -0,0 +1,171 @@
> +/*
> + * Device Tree file for Buffalo Linkstation LS-CHLv3
> + *
> + * Copyright (C) 2016 Ash Hughes <ashley.hughes@blueyonder.co.uk>
> + * Copyright (C) 2015, 2016
> + * Roger Shimizu <rogershimizu@gmail.com>
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + * a) This file is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of the
> + * License, or (at your option) any later version.
> + *
> + * This file is distributed in the hope that it will be useful
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * Or, alternatively
> + *
> + * b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +/dts-v1/;
> +
> +#include "orion5x-linkstation.dtsi"
> +#include "mvebu-linkstation-gpio-simple.dtsi"
> +#include "mvebu-linkstation-fan.dtsi"
> +#include <dt-bindings/gpio/gpio.h>
> +
> +/ {
> + model = "Buffalo Linkstation Live v3 (LS-CHL)";
> + compatible = "buffalo,lschl", "marvell,orion5x-88f5182", "marvell,orion5x";
> +
> + memory { /* 128 MB */
> + device_type = "memory";
> + reg = <0x00000000 0x8000000>;
> + };
> +
> + gpio_keys {
> + func {
> + label = "Function Button";
> + linux,code = <KEY_OPTION>;
> + gpios = <&gpio0 15 GPIO_ACTIVE_LOW>;
> + };
> +
> + power-on-switch {
> + gpios = <&gpio0 8 GPIO_ACTIVE_LOW>;
> + };
> +
> + power-auto-switch {
> + gpios = <&gpio0 10 GPIO_ACTIVE_LOW>;
> + };
> + };
> +
> + gpio_leds {
> + pinctrl-0 = <&pmx_led_power &pmx_led_alarm &pmx_led_info &pmx_led_func>;
> + blue-power-led {
> + gpios = <&gpio0 0 GPIO_ACTIVE_LOW>;
> + };
> +
> + red-alarm-led {
> + gpios = <&gpio0 2 GPIO_ACTIVE_LOW>;
> + };
> +
> + amber-info-led {
> + gpios = <&gpio0 3 GPIO_ACTIVE_LOW>;
> + };
> +
> + func {
> + label = "lschl:func:blue:top";
> + gpios = <&gpio0 17 GPIO_ACTIVE_LOW>;
> + };
> + };
> +
> + gpio_fan {
> + gpios = <&gpio0 14 GPIO_ACTIVE_LOW
> + &gpio0 16 GPIO_ACTIVE_LOW>;
> +
> + alarm-gpios = <&gpio0 6 GPIO_ACTIVE_HIGH>;
> + };
> +};
> +
> +&pinctrl {
> + pmx_led_power: pmx-leds {
> + marvell,pins = "mpp0";
> + marvell,function = "gpio";
> + };
> +
> + pmx_power_hdd: pmx-power-hdd {
> + marvell,pins = "mpp1";
> + marvell,function = "gpio";
> + };
> +
> + pmx_led_alarm: pmx-leds {
> + marvell,pins = "mpp2";
> + marvell,function = "gpio";
> + };
> +
> + pmx_led_info: pmx-leds {
> + marvell,pins = "mpp3";
> + marvell,function = "gpio";
> + };
> +
> + pmx_fan_lock: pmx-fan-lock {
> + marvell,pins = "mpp6";
> + marvell,function = "gpio";
> + };
> +
> + pmx_power_switch: pmx-power-switch {
> + marvell,pins = "mpp8", "mpp10", "mpp15";
> + marvell,function = "gpio";
> + };
> +
> + pmx_power_usb: pmx-power-usb {
> + marvell,pins = "mpp9";
> + marvell,function = "gpio";
> + };
> +
> + pmx_fan_high: pmx-fan-high {
> + marvell,pins = "mpp14";
> + marvell,function = "gpio";
> + };
> +
> + pmx_fan_low: pmx-fan-low {
> + marvell,pins = "mpp16";
> + marvell,function = "gpio";
> + };
> +
> + pmx_led_func: pmx-leds {
> + marvell,pins = "mpp17";
> + marvell,function = "gpio";
> + };
> +
> + pmx_sw_init: pmx-sw-init {
> + marvell,pins = "mpp7";
> + marvell,function = "gpio";
> + };
> +};
> +
> +&hdd_power {
> + gpios = <&gpio0 1 GPIO_ACTIVE_HIGH>;
> +};
> +
> +&usb_power {
> + gpios = <&gpio0 9 GPIO_ACTIVE_HIGH>;
> +};
> +
> diff --git a/arch/arm/mach-orion5x/Kconfig b/arch/arm/mach-orion5x/Kconfig
> index 89bb0fc..793efa9 100644
> --- a/arch/arm/mach-orion5x/Kconfig
> +++ b/arch/arm/mach-orion5x/Kconfig
> @@ -85,8 +85,8 @@ config MACH_LINKSTATION_PRO
> v2 devices are supported.
>
> config MACH_LINKSTATION_LSCHL
> - bool "Buffalo Linkstation Live v3 (LS-CHL)"
> - select I2C_BOARDINFO if I2C
> + bool "Buffalo Linkstation Live v3 (LS-CHL) (Flattened Device Tree)"
> + select ARCH_ORION5X_DT
> help
> Say 'Y' here if you want your kernel to support the
> Buffalo Linkstation Live v3 (LS-CHL) platform.
> diff --git a/arch/arm/mach-orion5x/Makefile b/arch/arm/mach-orion5x/Makefile
> index 4b2502b..ae91872 100644
> --- a/arch/arm/mach-orion5x/Makefile
> +++ b/arch/arm/mach-orion5x/Makefile
> @@ -18,7 +18,6 @@ obj-$(CONFIG_MACH_WNR854T) += wnr854t-setup.o
> obj-$(CONFIG_MACH_RD88F5181L_GE) += rd88f5181l-ge-setup.o
> obj-$(CONFIG_MACH_RD88F5181L_FXO) += rd88f5181l-fxo-setup.o
> obj-$(CONFIG_MACH_RD88F6183AP_GE) += rd88f6183ap-ge-setup.o
> -obj-$(CONFIG_MACH_LINKSTATION_LSCHL) += ls-chl-setup.o
>
> obj-$(CONFIG_ARCH_ORION5X_DT) += board-dt.o
> obj-$(CONFIG_MACH_D2NET_DT) += board-d2net.o
> diff --git a/arch/arm/mach-orion5x/ls-chl-setup.c b/arch/arm/mach-orion5x/ls-chl-setup.c
> deleted file mode 100644
> index dfdaa8a..0000000
> --- a/arch/arm/mach-orion5x/ls-chl-setup.c
> +++ /dev/null
> @@ -1,331 +0,0 @@
> -/*
> - * arch/arm/mach-orion5x/ls-chl-setup.c
> - *
> - * Maintainer: Ash Hughes <ashley.hughes@blueyonder.co.uk>
> - *
> - * This file is licensed under the terms of the GNU General Public
> - * License version 2. This program is licensed "as is" without any
> - * warranty of any kind, whether express or implied.
> - */
> -
> -#include <linux/kernel.h>
> -#include <linux/init.h>
> -#include <linux/platform_device.h>
> -#include <linux/mtd/physmap.h>
> -#include <linux/mv643xx_eth.h>
> -#include <linux/leds.h>
> -#include <linux/gpio_keys.h>
> -#include <linux/gpio-fan.h>
> -#include <linux/input.h>
> -#include <linux/i2c.h>
> -#include <linux/ata_platform.h>
> -#include <linux/gpio.h>
> -#include <asm/mach-types.h>
> -#include <asm/mach/arch.h>
> -#include "common.h"
> -#include "mpp.h"
> -#include "orion5x.h"
> -
> -/*****************************************************************************
> - * Linkstation LS-CHL Info
> - ****************************************************************************/
> -
> -/*
> - * 256K NOR flash Device bus boot chip select
> - */
> -
> -#define LSCHL_NOR_BOOT_BASE 0xf4000000
> -#define LSCHL_NOR_BOOT_SIZE SZ_256K
> -
> -/*****************************************************************************
> - * 256KB NOR Flash on BOOT Device
> - ****************************************************************************/
> -
> -static struct physmap_flash_data lschl_nor_flash_data = {
> - .width = 1,
> -};
> -
> -static struct resource lschl_nor_flash_resource = {
> - .flags = IORESOURCE_MEM,
> - .start = LSCHL_NOR_BOOT_BASE,
> - .end = LSCHL_NOR_BOOT_BASE + LSCHL_NOR_BOOT_SIZE - 1,
> -};
> -
> -static struct platform_device lschl_nor_flash = {
> - .name = "physmap-flash",
> - .id = 0,
> - .dev = {
> - .platform_data = &lschl_nor_flash_data,
> - },
> - .num_resources = 1,
> - .resource = &lschl_nor_flash_resource,
> -};
> -
> -/*****************************************************************************
> - * Ethernet
> - ****************************************************************************/
> -
> -static struct mv643xx_eth_platform_data lschl_eth_data = {
> - .phy_addr = MV643XX_ETH_PHY_ADDR(8),
> -};
> -
> -/*****************************************************************************
> - * RTC 5C372a on I2C bus
> - ****************************************************************************/
> -
> -static struct i2c_board_info __initdata lschl_i2c_rtc = {
> - I2C_BOARD_INFO("rs5c372a", 0x32),
> -};
> -
> -/*****************************************************************************
> - * LEDs attached to GPIO
> - ****************************************************************************/
> -
> -#define LSCHL_GPIO_LED_ALARM 2
> -#define LSCHL_GPIO_LED_INFO 3
> -#define LSCHL_GPIO_LED_FUNC 17
> -#define LSCHL_GPIO_LED_PWR 0
> -
> -static struct gpio_led lschl_led_pins[] = {
> - {
> - .name = "alarm:red",
> - .gpio = LSCHL_GPIO_LED_ALARM,
> - .active_low = 1,
> - }, {
> - .name = "info:amber",
> - .gpio = LSCHL_GPIO_LED_INFO,
> - .active_low = 1,
> - }, {
> - .name = "func:blue:top",
> - .gpio = LSCHL_GPIO_LED_FUNC,
> - .active_low = 1,
> - }, {
> - .name = "power:blue:bottom",
> - .gpio = LSCHL_GPIO_LED_PWR,
> - },
> -};
> -
> -static struct gpio_led_platform_data lschl_led_data = {
> - .leds = lschl_led_pins,
> - .num_leds = ARRAY_SIZE(lschl_led_pins),
> -};
> -
> -static struct platform_device lschl_leds = {
> - .name = "leds-gpio",
> - .id = -1,
> - .dev = {
> - .platform_data = &lschl_led_data,
> - },
> -};
> -
> -/*****************************************************************************
> - * SATA
> - ****************************************************************************/
> -static struct mv_sata_platform_data lschl_sata_data = {
> - .n_ports = 2,
> -};
> -
> -/*****************************************************************************
> - * LS-CHL specific power off method: reboot
> - ****************************************************************************/
> -/*
> - * On the LS-CHL, the shutdown process is following:
> - * - Userland monitors key events until the power switch goes to off position
> - * - The board reboots
> - * - U-boot starts and goes into an idle mode waiting for the user
> - * to move the switch to ON position
> - *
> - */
> -
> -static void lschl_power_off(void)
> -{
> - orion5x_restart(REBOOT_HARD, NULL);
> -}
> -
> -/*****************************************************************************
> - * General Setup
> - ****************************************************************************/
> -#define LSCHL_GPIO_USB_POWER 9
> -#define LSCHL_GPIO_AUTO_POWER 17
> -#define LSCHL_GPIO_POWER 18
> -
> -/****************************************************************************
> - * GPIO Attached Keys
> - ****************************************************************************/
> -#define LSCHL_GPIO_KEY_FUNC 15
> -#define LSCHL_GPIO_KEY_POWER 8
> -#define LSCHL_GPIO_KEY_AUTOPOWER 10
> -#define LSCHL_SW_POWER 0x00
> -#define LSCHL_SW_AUTOPOWER 0x01
> -#define LSCHL_SW_FUNC 0x02
> -
> -static struct gpio_keys_button lschl_buttons[] = {
> - {
> - .type = EV_SW,
> - .code = LSCHL_SW_POWER,
> - .gpio = LSCHL_GPIO_KEY_POWER,
> - .desc = "Power-on Switch",
> - .active_low = 1,
> - }, {
> - .type = EV_SW,
> - .code = LSCHL_SW_AUTOPOWER,
> - .gpio = LSCHL_GPIO_KEY_AUTOPOWER,
> - .desc = "Power-auto Switch",
> - .active_low = 1,
> - }, {
> - .type = EV_SW,
> - .code = LSCHL_SW_FUNC,
> - .gpio = LSCHL_GPIO_KEY_FUNC,
> - .desc = "Function Switch",
> - .active_low = 1,
> - },
> -};
> -
> -static struct gpio_keys_platform_data lschl_button_data = {
> - .buttons = lschl_buttons,
> - .nbuttons = ARRAY_SIZE(lschl_buttons),
> -};
> -
> -static struct platform_device lschl_button_device = {
> - .name = "gpio-keys",
> - .id = -1,
> - .num_resources = 0,
> - .dev = {
> - .platform_data = &lschl_button_data,
> - },
> -};
> -
> -#define LSCHL_GPIO_HDD_POWER 1
> -
> -/****************************************************************************
> - * GPIO Fan
> - ****************************************************************************/
> -
> -#define LSCHL_GPIO_FAN_LOW 16
> -#define LSCHL_GPIO_FAN_HIGH 14
> -#define LSCHL_GPIO_FAN_LOCK 6
> -
> -static struct gpio_fan_alarm lschl_alarm = {
> - .gpio = LSCHL_GPIO_FAN_LOCK,
> -};
> -
> -static struct gpio_fan_speed lschl_speeds[] = {
> - {
> - .rpm = 0,
> - .ctrl_val = 3,
> - }, {
> - .rpm = 1500,
> - .ctrl_val = 2,
> - }, {
> - .rpm = 3250,
> - .ctrl_val = 1,
> - }, {
> - .rpm = 5000,
> - .ctrl_val = 0,
> - },
> -};
> -
> -static int lschl_gpio_list[] = {
> - LSCHL_GPIO_FAN_HIGH, LSCHL_GPIO_FAN_LOW,
> -};
> -
> -static struct gpio_fan_platform_data lschl_fan_data = {
> - .num_ctrl = ARRAY_SIZE(lschl_gpio_list),
> - .ctrl = lschl_gpio_list,
> - .alarm = &lschl_alarm,
> - .num_speed = ARRAY_SIZE(lschl_speeds),
> - .speed = lschl_speeds,
> -};
> -
> -static struct platform_device lschl_fan_device = {
> - .name = "gpio-fan",
> - .id = -1,
> - .num_resources = 0,
> - .dev = {
> - .platform_data = &lschl_fan_data,
> - },
> -};
> -
> -/****************************************************************************
> - * GPIO Data
> - ****************************************************************************/
> -
> -static unsigned int lschl_mpp_modes[] __initdata = {
> - MPP0_GPIO, /* LED POWER */
> - MPP1_GPIO, /* HDD POWER */
> - MPP2_GPIO, /* LED ALARM */
> - MPP3_GPIO, /* LED INFO */
> - MPP4_UNUSED,
> - MPP5_UNUSED,
> - MPP6_GPIO, /* FAN LOCK */
> - MPP7_GPIO, /* SW INIT */
> - MPP8_GPIO, /* SW POWER */
> - MPP9_GPIO, /* USB POWER */
> - MPP10_GPIO, /* SW AUTO POWER */
> - MPP11_UNUSED,
> - MPP12_UNUSED,
> - MPP13_UNUSED,
> - MPP14_GPIO, /* FAN HIGH */
> - MPP15_GPIO, /* SW FUNC */
> - MPP16_GPIO, /* FAN LOW */
> - MPP17_GPIO, /* LED FUNC */
> - MPP18_UNUSED,
> - MPP19_UNUSED,
> - 0,
> -};
> -
> -static void __init lschl_init(void)
> -{
> - /*
> - * Setup basic Orion functions. Needs to be called early.
> - */
> - orion5x_init();
> -
> - orion5x_mpp_conf(lschl_mpp_modes);
> -
> - /*
> - * Configure peripherals.
> - */
> - orion5x_ehci0_init();
> - orion5x_ehci1_init();
> - orion5x_eth_init(&lschl_eth_data);
> - orion5x_i2c_init();
> - orion5x_sata_init(&lschl_sata_data);
> - orion5x_uart0_init();
> - orion5x_xor_init();
> -
> - mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
> - ORION_MBUS_DEVBUS_BOOT_ATTR,
> - LSCHL_NOR_BOOT_BASE,
> - LSCHL_NOR_BOOT_SIZE);
> - platform_device_register(&lschl_nor_flash);
> -
> - platform_device_register(&lschl_leds);
> -
> - platform_device_register(&lschl_button_device);
> -
> - platform_device_register(&lschl_fan_device);
> -
> - i2c_register_board_info(0, &lschl_i2c_rtc, 1);
> -
> - /* usb power on */
> - gpio_set_value(LSCHL_GPIO_USB_POWER, 1);
> -
> - /* register power-off method */
> - pm_power_off = lschl_power_off;
> -
> - pr_info("%s: finished\n", __func__);
> -}
> -
> -MACHINE_START(LINKSTATION_LSCHL, "Buffalo Linkstation LiveV3 (LS-CHL)")
> - /* Maintainer: Ash Hughes <ashley.hughes@blueyonder.co.uk> */
> - .atag_offset = 0x100,
> - .nr_irqs = ORION5X_NR_IRQS,
> - .init_machine = lschl_init,
> - .map_io = orion5x_map_io,
> - .init_early = orion5x_init_early,
> - .init_irq = orion5x_init_irq,
> - .init_time = orion5x_timer_init,
> - .fixup = tag_fixup_mem32,
> - .restart = orion5x_restart,
> -MACHINE_END
> --
> 2.7.4
>
>
> On 04/11/16 12:44, Gregory CLEMENT wrote:
>> Hi Ash,
>>
>> On mar., oct. 25 2016, Ash Hughes <sehguh.hsa@gmail.com> wrote:
>>
>>> Hi all,
>>>
>>> This patch converts my orion5x ls-chl Linkstation device to device
>>> tree.
>> I was about to apply your patch but it does not apply on mvebu/dt or
>> even on v4.9-rc1.
>>
>> Could you rebase it?
>>
>> Thanks,
>>
>> Gregory
>>
>>> Signed-off-by: Ashley Hughes <ashley.hughes@blueyonder.co.uk>
>>> ---
>>> arch/arm/boot/dts/Makefile | 1 +
>>> arch/arm/boot/dts/orion5x-lschl.dts | 171 ++++++++++++++++++
>>> arch/arm/mach-orion5x/Kconfig | 4 +-
>>> arch/arm/mach-orion5x/Makefile | 1 -
>>> arch/arm/mach-orion5x/ls-chl-setup.c | 331 -----------------------------------
>>> 5 files changed, 174 insertions(+), 334 deletions(-)
>>> create mode 100644 arch/arm/boot/dts/orion5x-lschl.dts
>>> delete mode 100644 arch/arm/mach-orion5x/ls-chl-setup.c
>>>
>>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>>> index befcd26..4853049 100644
>>> --- a/arch/arm/boot/dts/Makefile
>>> +++ b/arch/arm/boot/dts/Makefile
>>> @@ -597,6 +597,7 @@ dtb-$(CONFIG_ARCH_ORION5X) += \
>>> orion5x-lacie-ethernet-disk-mini-v2.dtb \
>>> orion5x-linkstation-lsgl.dtb \
>>> orion5x-linkstation-lswtgl.dtb \
>>> + orion5x-lschl.dtb \
>>> orion5x-lswsgl.dtb \
>>> orion5x-maxtor-shared-storage-2.dtb \
>>> orion5x-netgear-wnr854t.dtb \
>>> diff --git a/arch/arm/boot/dts/orion5x-lschl.dts b/arch/arm/boot/dts/orion5x-lschl.dts
>>> new file mode 100644
>>> index 0000000..9474092
>>> --- /dev/null
>>> +++ b/arch/arm/boot/dts/orion5x-lschl.dts
>>> @@ -0,0 +1,171 @@
>>> +/*
>>> + * Device Tree file for Buffalo Linkstation LS-CHLv3
>>> + *
>>> + * Copyright (C) 2016 Ash Hughes <ashley.hughes@blueyonder.co.uk>
>>> + * Copyright (C) 2015, 2016
>>> + * Roger Shimizu <rogershimizu@gmail.com>
>>> + *
>>> + * This file is dual-licensed: you can use it either under the terms
>>> + * of the GPL or the X11 license, at your option. Note that this dual
>>> + * licensing only applies to this file, and not this project as a
>>> + * whole.
>>> + *
>>> + * a) This file is free software; you can redistribute it and/or
>>> + * modify it under the terms of the GNU General Public License as
>>> + * published by the Free Software Foundation; either version 2 of the
>>> + * License, or (at your option) any later version.
>>> + *
>>> + * This file is distributed in the hope that it will be useful
>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>>> + * GNU General Public License for more details.
>>> + *
>>> + * Or, alternatively
>>> + *
>>> + * b) Permission is hereby granted, free of charge, to any person
>>> + * obtaining a copy of this software and associated documentation
>>> + * files (the "Software"), to deal in the Software without
>>> + * restriction, including without limitation the rights to use
>>> + * copy, modify, merge, publish, distribute, sublicense, and/or
>>> + * sell copies of the Software, and to permit persons to whom the
>>> + * Software is furnished to do so, subject to the following
>>> + * conditions:
>>> + *
>>> + * The above copyright notice and this permission notice shall be
>>> + * included in all copies or substantial portions of the Software.
>>> + *
>>> + * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
>>> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
>>> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
>>> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
>>> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
>>> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
>>> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
>>> + * OTHER DEALINGS IN THE SOFTWARE.
>>> + */
>>> +
>>> +/dts-v1/;
>>> +
>>> +#include "orion5x-linkstation.dtsi"
>>> +#include "mvebu-linkstation-gpio-simple.dtsi"
>>> +#include "mvebu-linkstation-fan.dtsi"
>>> +#include <dt-bindings/gpio/gpio.h>
>>> +
>>> +/ {
>>> + model = "Buffalo Linkstation Live v3 (LS-CHL)";
>>> + compatible = "buffalo,lschl", "marvell,orion5x-88f5182", "marvell,orion5x";
>>> +
>>> + memory { /* 128 MB */
>>> + device_type = "memory";
>>> + reg = <0x00000000 0x8000000>;
>>> + };
>>> +
>>> + gpio_keys {
>>> + func {
>>> + label = "Function Button";
>>> + linux,code = <KEY_OPTION>;
>>> + gpios = <&gpio0 15 GPIO_ACTIVE_LOW>;
>>> + };
>>> +
>>> + power-on-switch {
>>> + gpios = <&gpio0 8 GPIO_ACTIVE_LOW>;
>>> + };
>>> +
>>> + power-auto-switch {
>>> + gpios = <&gpio0 10 GPIO_ACTIVE_LOW>;
>>> + };
>>> + };
>>> +
>>> + gpio_leds {
>>> + pinctrl-0 = <&pmx_led_power &pmx_led_alarm &pmx_led_info &pmx_led_func>;
>>> + blue-power-led {
>>> + gpios = <&gpio0 0 GPIO_ACTIVE_LOW>;
>>> + };
>>> +
>>> + red-alarm-led {
>>> + gpios = <&gpio0 2 GPIO_ACTIVE_LOW>;
>>> + };
>>> +
>>> + amber-info-led {
>>> + gpios = <&gpio0 3 GPIO_ACTIVE_LOW>;
>>> + };
>>> +
>>> + func {
>>> + label = "lschl:func:blue:top";
>>> + gpios = <&gpio0 17 GPIO_ACTIVE_LOW>;
>>> + };
>>> + };
>>> +
>>> + gpio_fan {
>>> + gpios = <&gpio0 14 GPIO_ACTIVE_LOW
>>> + &gpio0 16 GPIO_ACTIVE_LOW>;
>>> +
>>> + alarm-gpios = <&gpio0 6 GPIO_ACTIVE_HIGH>;
>>> + };
>>> +};
>>> +
>>> +&pinctrl {
>>> + pmx_led_power: pmx-leds {
>>> + marvell,pins = "mpp0";
>>> + marvell,function = "gpio";
>>> + };
>>> +
>>> + pmx_power_hdd: pmx-power-hdd {
>>> + marvell,pins = "mpp1";
>>> + marvell,function = "gpio";
>>> + };
>>> +
>>> + pmx_led_alarm: pmx-leds {
>>> + marvell,pins = "mpp2";
>>> + marvell,function = "gpio";
>>> + };
>>> +
>>> + pmx_led_info: pmx-leds {
>>> + marvell,pins = "mpp3";
>>> + marvell,function = "gpio";
>>> + };
>>> +
>>> + pmx_fan_lock: pmx-fan-lock {
>>> + marvell,pins = "mpp6";
>>> + marvell,function = "gpio";
>>> + };
>>> +
>>> + pmx_power_switch: pmx-power-switch {
>>> + marvell,pins = "mpp8", "mpp10", "mpp15";
>>> + marvell,function = "gpio";
>>> + };
>>> +
>>> + pmx_power_usb: pmx-power-usb {
>>> + marvell,pins = "mpp9";
>>> + marvell,function = "gpio";
>>> + };
>>> +
>>> + pmx_fan_high: pmx-fan-high {
>>> + marvell,pins = "mpp14";
>>> + marvell,function = "gpio";
>>> + };
>>> +
>>> + pmx_fan_low: pmx-fan-low {
>>> + marvell,pins = "mpp16";
>>> + marvell,function = "gpio";
>>> + };
>>> +
>>> + pmx_led_func: pmx-leds {
>>> + marvell,pins = "mpp17";
>>> + marvell,function = "gpio";
>>> + };
>>> +
>>> + pmx_sw_init: pmx-sw-init {
>>> + marvell,pins = "mpp7";
>>> + marvell,function = "gpio";
>>> + };
>>> +};
>>> +
>>> +&hdd_power {
>>> + gpios = <&gpio0 1 GPIO_ACTIVE_HIGH>;
>>> +};
>>> +
>>> +&usb_power {
>>> + gpios = <&gpio0 9 GPIO_ACTIVE_HIGH>;
>>> +};
>>> +
>>> diff --git a/arch/arm/mach-orion5x/Kconfig b/arch/arm/mach-orion5x/Kconfig
>>> index 89bb0fc..793efa9 100644
>>> --- a/arch/arm/mach-orion5x/Kconfig
>>> +++ b/arch/arm/mach-orion5x/Kconfig
>>> @@ -85,8 +85,8 @@ config MACH_LINKSTATION_PRO
>>> v2 devices are supported.
>>>
>>> config MACH_LINKSTATION_LSCHL
>>> - bool "Buffalo Linkstation Live v3 (LS-CHL)"
>>> - select I2C_BOARDINFO if I2C
>>> + bool "Buffalo Linkstation Live v3 (LS-CHL) (Flattened Device Tree)"
>>> + select ARCH_ORION5X_DT
>>> help
>>> Say 'Y' here if you want your kernel to support the
>>> Buffalo Linkstation Live v3 (LS-CHL) platform.
>>> diff --git a/arch/arm/mach-orion5x/Makefile b/arch/arm/mach-orion5x/Makefile
>>> index 4b2502b..ae91872 100644
>>> --- a/arch/arm/mach-orion5x/Makefile
>>> +++ b/arch/arm/mach-orion5x/Makefile
>>> @@ -18,7 +18,6 @@ obj-$(CONFIG_MACH_WNR854T) += wnr854t-setup.o
>>> obj-$(CONFIG_MACH_RD88F5181L_GE) += rd88f5181l-ge-setup.o
>>> obj-$(CONFIG_MACH_RD88F5181L_FXO) += rd88f5181l-fxo-setup.o
>>> obj-$(CONFIG_MACH_RD88F6183AP_GE) += rd88f6183ap-ge-setup.o
>>> -obj-$(CONFIG_MACH_LINKSTATION_LSCHL) += ls-chl-setup.o
>>>
>>> obj-$(CONFIG_ARCH_ORION5X_DT) += board-dt.o
>>> obj-$(CONFIG_MACH_D2NET_DT) += board-d2net.o
>>> diff --git a/arch/arm/mach-orion5x/ls-chl-setup.c b/arch/arm/mach-orion5x/ls-chl-setup.c
>>> deleted file mode 100644
>>> index dfdaa8a..0000000
>>> --- a/arch/arm/mach-orion5x/ls-chl-setup.c
>>> +++ /dev/null
>>> @@ -1,331 +0,0 @@
>>> -/*
>>> - * arch/arm/mach-orion5x/ls-chl-setup.c
>>> - *
>>> - * Maintainer: Ash Hughes <ashley.hughes@blueyonder.co.uk>
>>> - *
>>> - * This file is licensed under the terms of the GNU General Public
>>> - * License version 2. This program is licensed "as is" without any
>>> - * warranty of any kind, whether express or implied.
>>> - */
>>> -
>>> -#include <linux/kernel.h>
>>> -#include <linux/init.h>
>>> -#include <linux/platform_device.h>
>>> -#include <linux/mtd/physmap.h>
>>> -#include <linux/mv643xx_eth.h>
>>> -#include <linux/leds.h>
>>> -#include <linux/gpio_keys.h>
>>> -#include <linux/gpio-fan.h>
>>> -#include <linux/input.h>
>>> -#include <linux/i2c.h>
>>> -#include <linux/ata_platform.h>
>>> -#include <linux/gpio.h>
>>> -#include <asm/mach-types.h>
>>> -#include <asm/mach/arch.h>
>>> -#include "common.h"
>>> -#include "mpp.h"
>>> -#include "orion5x.h"
>>> -
>>> -/*****************************************************************************
>>> - * Linkstation LS-CHL Info
>>> - ****************************************************************************/
>>> -
>>> -/*
>>> - * 256K NOR flash Device bus boot chip select
>>> - */
>>> -
>>> -#define LSCHL_NOR_BOOT_BASE 0xf4000000
>>> -#define LSCHL_NOR_BOOT_SIZE SZ_256K
>>> -
>>> -/*****************************************************************************
>>> - * 256KB NOR Flash on BOOT Device
>>> - ****************************************************************************/
>>> -
>>> -static struct physmap_flash_data lschl_nor_flash_data = {
>>> - .width = 1,
>>> -};
>>> -
>>> -static struct resource lschl_nor_flash_resource = {
>>> - .flags = IORESOURCE_MEM,
>>> - .start = LSCHL_NOR_BOOT_BASE,
>>> - .end = LSCHL_NOR_BOOT_BASE + LSCHL_NOR_BOOT_SIZE - 1,
>>> -};
>>> -
>>> -static struct platform_device lschl_nor_flash = {
>>> - .name = "physmap-flash",
>>> - .id = 0,
>>> - .dev = {
>>> - .platform_data = &lschl_nor_flash_data,
>>> - },
>>> - .num_resources = 1,
>>> - .resource = &lschl_nor_flash_resource,
>>> -};
>>> -
>>> -/*****************************************************************************
>>> - * Ethernet
>>> - ****************************************************************************/
>>> -
>>> -static struct mv643xx_eth_platform_data lschl_eth_data = {
>>> - .phy_addr = MV643XX_ETH_PHY_ADDR(8),
>>> -};
>>> -
>>> -/*****************************************************************************
>>> - * RTC 5C372a on I2C bus
>>> - ****************************************************************************/
>>> -
>>> -static struct i2c_board_info __initdata lschl_i2c_rtc = {
>>> - I2C_BOARD_INFO("rs5c372a", 0x32),
>>> -};
>>> -
>>> -/*****************************************************************************
>>> - * LEDs attached to GPIO
>>> - ****************************************************************************/
>>> -
>>> -#define LSCHL_GPIO_LED_ALARM 2
>>> -#define LSCHL_GPIO_LED_INFO 3
>>> -#define LSCHL_GPIO_LED_FUNC 17
>>> -#define LSCHL_GPIO_LED_PWR 0
>>> -
>>> -static struct gpio_led lschl_led_pins[] = {
>>> - {
>>> - .name = "alarm:red",
>>> - .gpio = LSCHL_GPIO_LED_ALARM,
>>> - .active_low = 1,
>>> - }, {
>>> - .name = "info:amber",
>>> - .gpio = LSCHL_GPIO_LED_INFO,
>>> - .active_low = 1,
>>> - }, {
>>> - .name = "func:blue:top",
>>> - .gpio = LSCHL_GPIO_LED_FUNC,
>>> - .active_low = 1,
>>> - }, {
>>> - .name = "power:blue:bottom",
>>> - .gpio = LSCHL_GPIO_LED_PWR,
>>> - },
>>> -};
>>> -
>>> -static struct gpio_led_platform_data lschl_led_data = {
>>> - .leds = lschl_led_pins,
>>> - .num_leds = ARRAY_SIZE(lschl_led_pins),
>>> -};
>>> -
>>> -static struct platform_device lschl_leds = {
>>> - .name = "leds-gpio",
>>> - .id = -1,
>>> - .dev = {
>>> - .platform_data = &lschl_led_data,
>>> - },
>>> -};
>>> -
>>> -/*****************************************************************************
>>> - * SATA
>>> - ****************************************************************************/
>>> -static struct mv_sata_platform_data lschl_sata_data = {
>>> - .n_ports = 2,
>>> -};
>>> -
>>> -/*****************************************************************************
>>> - * LS-CHL specific power off method: reboot
>>> - ****************************************************************************/
>>> -/*
>>> - * On the LS-CHL, the shutdown process is following:
>>> - * - Userland monitors key events until the power switch goes to off position
>>> - * - The board reboots
>>> - * - U-boot starts and goes into an idle mode waiting for the user
>>> - * to move the switch to ON position
>>> - *
>>> - */
>>> -
>>> -static void lschl_power_off(void)
>>> -{
>>> - orion5x_restart(REBOOT_HARD, NULL);
>>> -}
>>> -
>>> -/*****************************************************************************
>>> - * General Setup
>>> - ****************************************************************************/
>>> -#define LSCHL_GPIO_USB_POWER 9
>>> -#define LSCHL_GPIO_AUTO_POWER 17
>>> -#define LSCHL_GPIO_POWER 18
>>> -
>>> -/****************************************************************************
>>> - * GPIO Attached Keys
>>> - ****************************************************************************/
>>> -#define LSCHL_GPIO_KEY_FUNC 15
>>> -#define LSCHL_GPIO_KEY_POWER 8
>>> -#define LSCHL_GPIO_KEY_AUTOPOWER 10
>>> -#define LSCHL_SW_POWER 0x00
>>> -#define LSCHL_SW_AUTOPOWER 0x01
>>> -#define LSCHL_SW_FUNC 0x02
>>> -
>>> -static struct gpio_keys_button lschl_buttons[] = {
>>> - {
>>> - .type = EV_SW,
>>> - .code = LSCHL_SW_POWER,
>>> - .gpio = LSCHL_GPIO_KEY_POWER,
>>> - .desc = "Power-on Switch",
>>> - .active_low = 1,
>>> - }, {
>>> - .type = EV_SW,
>>> - .code = LSCHL_SW_AUTOPOWER,
>>> - .gpio = LSCHL_GPIO_KEY_AUTOPOWER,
>>> - .desc = "Power-auto Switch",
>>> - .active_low = 1,
>>> - }, {
>>> - .type = EV_SW,
>>> - .code = LSCHL_SW_FUNC,
>>> - .gpio = LSCHL_GPIO_KEY_FUNC,
>>> - .desc = "Function Switch",
>>> - .active_low = 1,
>>> - },
>>> -};
>>> -
>>> -static struct gpio_keys_platform_data lschl_button_data = {
>>> - .buttons = lschl_buttons,
>>> - .nbuttons = ARRAY_SIZE(lschl_buttons),
>>> -};
>>> -
>>> -static struct platform_device lschl_button_device = {
>>> - .name = "gpio-keys",
>>> - .id = -1,
>>> - .num_resources = 0,
>>> - .dev = {
>>> - .platform_data = &lschl_button_data,
>>> - },
>>> -};
>>> -
>>> -#define LSCHL_GPIO_HDD_POWER 1
>>> -
>>> -/****************************************************************************
>>> - * GPIO Fan
>>> - ****************************************************************************/
>>> -
>>> -#define LSCHL_GPIO_FAN_LOW 16
>>> -#define LSCHL_GPIO_FAN_HIGH 14
>>> -#define LSCHL_GPIO_FAN_LOCK 6
>>> -
>>> -static struct gpio_fan_alarm lschl_alarm = {
>>> - .gpio = LSCHL_GPIO_FAN_LOCK,
>>> -};
>>> -
>>> -static struct gpio_fan_speed lschl_speeds[] = {
>>> - {
>>> - .rpm = 0,
>>> - .ctrl_val = 3,
>>> - }, {
>>> - .rpm = 1500,
>>> - .ctrl_val = 2,
>>> - }, {
>>> - .rpm = 3250,
>>> - .ctrl_val = 1,
>>> - }, {
>>> - .rpm = 5000,
>>> - .ctrl_val = 0,
>>> - },
>>> -};
>>> -
>>> -static int lschl_gpio_list[] = {
>>> - LSCHL_GPIO_FAN_HIGH, LSCHL_GPIO_FAN_LOW,
>>> -};
>>> -
>>> -static struct gpio_fan_platform_data lschl_fan_data = {
>>> - .num_ctrl = ARRAY_SIZE(lschl_gpio_list),
>>> - .ctrl = lschl_gpio_list,
>>> - .alarm = &lschl_alarm,
>>> - .num_speed = ARRAY_SIZE(lschl_speeds),
>>> - .speed = lschl_speeds,
>>> -};
>>> -
>>> -static struct platform_device lschl_fan_device = {
>>> - .name = "gpio-fan",
>>> - .id = -1,
>>> - .num_resources = 0,
>>> - .dev = {
>>> - .platform_data = &lschl_fan_data,
>>> - },
>>> -};
>>> -
>>> -/****************************************************************************
>>> - * GPIO Data
>>> - ****************************************************************************/
>>> -
>>> -static unsigned int lschl_mpp_modes[] __initdata = {
>>> - MPP0_GPIO, /* LED POWER */
>>> - MPP1_GPIO, /* HDD POWER */
>>> - MPP2_GPIO, /* LED ALARM */
>>> - MPP3_GPIO, /* LED INFO */
>>> - MPP4_UNUSED,
>>> - MPP5_UNUSED,
>>> - MPP6_GPIO, /* FAN LOCK */
>>> - MPP7_GPIO, /* SW INIT */
>>> - MPP8_GPIO, /* SW POWER */
>>> - MPP9_GPIO, /* USB POWER */
>>> - MPP10_GPIO, /* SW AUTO POWER */
>>> - MPP11_UNUSED,
>>> - MPP12_UNUSED,
>>> - MPP13_UNUSED,
>>> - MPP14_GPIO, /* FAN HIGH */
>>> - MPP15_GPIO, /* SW FUNC */
>>> - MPP16_GPIO, /* FAN LOW */
>>> - MPP17_GPIO, /* LED FUNC */
>>> - MPP18_UNUSED,
>>> - MPP19_UNUSED,
>>> - 0,
>>> -};
>>> -
>>> -static void __init lschl_init(void)
>>> -{
>>> - /*
>>> - * Setup basic Orion functions. Needs to be called early.
>>> - */
>>> - orion5x_init();
>>> -
>>> - orion5x_mpp_conf(lschl_mpp_modes);
>>> -
>>> - /*
>>> - * Configure peripherals.
>>> - */
>>> - orion5x_ehci0_init();
>>> - orion5x_ehci1_init();
>>> - orion5x_eth_init(&lschl_eth_data);
>>> - orion5x_i2c_init();
>>> - orion5x_sata_init(&lschl_sata_data);
>>> - orion5x_uart0_init();
>>> - orion5x_xor_init();
>>> -
>>> - mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
>>> - ORION_MBUS_DEVBUS_BOOT_ATTR,
>>> - LSCHL_NOR_BOOT_BASE,
>>> - LSCHL_NOR_BOOT_SIZE);
>>> - platform_device_register(&lschl_nor_flash);
>>> -
>>> - platform_device_register(&lschl_leds);
>>> -
>>> - platform_device_register(&lschl_button_device);
>>> -
>>> - platform_device_register(&lschl_fan_device);
>>> -
>>> - i2c_register_board_info(0, &lschl_i2c_rtc, 1);
>>> -
>>> - /* usb power on */
>>> - gpio_set_value(LSCHL_GPIO_USB_POWER, 1);
>>> -
>>> - /* register power-off method */
>>> - pm_power_off = lschl_power_off;
>>> -
>>> - pr_info("%s: finished\n", __func__);
>>> -}
>>> -
>>> -MACHINE_START(LINKSTATION_LSCHL, "Buffalo Linkstation LiveV3 (LS-CHL)")
>>> - /* Maintainer: Ash Hughes <ashley.hughes@blueyonder.co.uk> */
>>> - .atag_offset = 0x100,
>>> - .nr_irqs = ORION5X_NR_IRQS,
>>> - .init_machine = lschl_init,
>>> - .map_io = orion5x_map_io,
>>> - .init_early = orion5x_init_early,
>>> - .init_irq = orion5x_init_irq,
>>> - .init_time = orion5x_timer_init,
>>> - .fixup = tag_fixup_mem32,
>>> - .restart = orion5x_restart,
>>> -MACHINE_END
>>> -- 2.7.4
>>>
>>>
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH v2] staging: vc04_services: add vchiq_pagelist_info structure
From: Eric Anholt @ 2016-11-07 16:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161107140603.14125-1-mzoran@crowfest.net>
Michael Zoran <mzoran@crowfest.net> writes:
> The current dma_map_sg based implementation for bulk messages
> computes many offsets into a single allocation multiple times in
> both the create and free code paths. This is inefficient,
> error prone and in fact still has a few lingering issues
> with arm64.
>
> This change replaces a small portion of that inplementation with
> new code that uses a new struct vchiq_pagelist_info to store the
> needed information rather then complex offset calculations.
>
> This improved implementation should be more efficient and easier
> to understand and maintain.
>
> Tests Run(Both Pass):
> vchiq_test -p 1
> vchiq_test -f 10
Looks good, and it's a nice cleanup. Thanks!
Reviewed-by: Eric Anholt <eric@anholt.net>
I had one style note, which was that you're using an int and 0/1 for a
boolean value, but we like to use proper bools and true/false instead.
However, you're modifying code that was already using an int for related
booleans, so that can be a separate cleanup.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161107/cd4b1063/attachment.sig>
^ permalink raw reply
* [PATCH 2/3] arm64/setup: Use ID_AA64ISAR0_EL1_.* macros
From: Suzuki K Poulose @ 2016-11-07 16:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1441303972-9480-1-git-send-email-kuleshovmail@gmail.com>
On 03/09/15 19:12, Alexander Kuleshov wrote:
> The 26d75e67c commit (arm64/cpufeature.h: Add macros for a cpu features
> testing) provides set of macros for the testing processor's crypto features.
> Let's use these macros instead of direct calculation.
>
> Signed-off-by: Alexander Kuleshov <kuleshovmail@gmail.com>
> ---
> arch/arm64/kernel/setup.c | 29 +++++++++--------------------
> 1 file changed, 9 insertions(+), 20 deletions(-)
>
> diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
> index 926ae8d..a3faf4f 100644
> --- a/arch/arm64/kernel/setup.c
> +++ b/arch/arm64/kernel/setup.c
This patch doesn't apply on the current mainline tree. Where does this patch apply ?
The elf_hwcap calculation has been moved to a separate function setup_elf_hwcaps()
in arch/arm64/kernel/cpufeature.c, which makes uses of a table of arm64_cpu_capabilities.
Suzuki
> @@ -250,33 +250,22 @@ static void __init setup_processor(void)
>
> /*
> * ID_AA64ISAR0_EL1 contains 4-bit wide signed feature blocks.
> - * The blocks we test below represent incremental functionality
> - * for non-negative values. Negative values are reserved.
> */
> features = read_cpuid(ID_AA64ISAR0_EL1);
> - block = (features >> 4) & 0xf;
> - if (!(block & 0x8)) {
> - switch (block) {
> - default:
> - case 2:
> - elf_hwcap |= HWCAP_PMULL;
> - case 1:
> - elf_hwcap |= HWCAP_AES;
> - case 0:
> - break;
> - }
> - }
>
> - block = (features >> 8) & 0xf;
> - if (block && !(block & 0x8))
> + if (ID_AA64ISAR0_EL1_AES(features))
> + elf_hwcap |= HWCAP_AES;
> +
> + if (ID_AA64ISAR0_EL1_PMULL(features))
> + elf_hwcap |= HWCAP_PMULL;
> +
> + if (ID_AA64ISAR0_EL1_SHA1(features))
> elf_hwcap |= HWCAP_SHA1;
>
> - block = (features >> 12) & 0xf;
> - if (block && !(block & 0x8))
> + if (ID_AA64ISAR0_EL1_SHA2(features))
> elf_hwcap |= HWCAP_SHA2;
>
> - block = (features >> 16) & 0xf;
> - if (block && !(block & 0x8))
> + if (ID_AA64ISAR0_EL1_CRC32(features))
> elf_hwcap |= HWCAP_CRC32;
^ permalink raw reply
* [PATCH 3/3] arm64/fpsimd: Use ID_AA64PFR0_EL1_.* macros
From: Suzuki K Poulose @ 2016-11-07 16:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1441303979-9535-1-git-send-email-kuleshovmail@gmail.com>
On 03/09/15 19:12, Alexander Kuleshov wrote:
> The 26d75e67c commit (arm64/cpufeature.h: Add macros for a cpu features
> testing) provides set of macros for the testing processor's FP and advanced
> SIMD features.
>
> Let's use these macros instead of direct calculation.
>
> Signed-off-by: Alexander Kuleshov <kuleshovmail@gmail.com>
> ---
> arch/arm64/kernel/fpsimd.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
> index 44d6f75..12943a5 100644
> --- a/arch/arm64/kernel/fpsimd.c
> +++ b/arch/arm64/kernel/fpsimd.c
> @@ -27,6 +27,7 @@
>
> #include <asm/fpsimd.h>
> #include <asm/cputype.h>
> +#include <asm/cpufeature.h>
>
> #define FPEXC_IOF (1 << 0)
> #define FPEXC_DZF (1 << 1)
> @@ -333,13 +334,13 @@ static int __init fpsimd_init(void)
> {
> u64 pfr = read_cpuid(ID_AA64PFR0_EL1);
>
> - if (pfr & (0xf << 16)) {
> + if (ID_AA64PFR0_EL1_FP(pfr)) {
> pr_notice("Floating-point is not implemented\n");
> return 0;
> }
> elf_hwcap |= HWCAP_FP;
>
> - if (pfr & (0xf << 20))
> + if (ID_AA64PFR0_EL1_ADV_SIMD(pfr))
> pr_notice("Advanced SIMD is not implemented\n");
> else
> elf_hwcap |= HWCAP_ASIMD;
>
Similar to the previous one, this won't apply anymore.
Suzuki
^ permalink raw reply
* [PATCHv4 0/4] WX checking for arm64
From: Catalin Marinas @ 2016-11-07 16:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <07589590-7b7d-4ba1-67af-b39c40b16939@redhat.com>
On Mon, Nov 07, 2016 at 08:26:34AM -0800, Laura Abbott wrote:
> On 11/07/2016 07:38 AM, Mark Rutland wrote:
> >From 06fef1ad1138d0808eec770e64458a350941bd2d Mon Sep 17 00:00:00 2001
> >From: Mark Rutland <mark.rutland@arm.com>
> >Date: Mon, 7 Nov 2016 15:24:40 +0000
> >Subject: [PATCH] Fix KASAN splats with DEBUG_WX
[...]
> Acked-by: Laura Abbott <labbott@redhat.com>
Thanks. I'll queue the patch on top of the others.
--
Catalin
^ permalink raw reply
* [PATCH v2] staging: vc04_services: setup DMA and coherent mask
From: Eric Anholt @ 2016-11-07 16:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161031210203.2089-1-mzoran@crowfest.net>
Michael Zoran <mzoran@crowfest.net> writes:
> VCHI messages between the CPU and firmware use 32-bit
> bus addresses. Explicitly set the DMA mask and coherent
> on all platforms.
Reviewed-by: Eric Anholt <eric@anholt.net>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161107/14619b5d/attachment.sig>
^ permalink raw reply
* [PATCH 0/3] arm64: dts: hisi: hip06 SAS device tree fixes
From: John Garry @ 2016-11-07 16:44 UTC (permalink / raw)
To: linux-arm-kernel
This patchset resolves some hip06 SAS device tree issues.
John Garry (3):
arm64: dts: hisi: fix hip06 sas am-max-trans quirk
arm64: dts: hisi: disable sas0 and sas2 for d03
arm64: dts: hisi: add refclk node to hip06 dts files for SAS
arch/arm64/boot/dts/hisilicon/hip06-d03.dts | 8 --------
arch/arm64/boot/dts/hisilicon/hip06.dtsi | 11 ++++++++++-
2 files changed, 10 insertions(+), 9 deletions(-)
--
1.9.1
^ permalink raw reply
* [PATCH 1/3] arm64: dts: hisi: fix hip06 sas am-max-trans quirk
From: John Garry @ 2016-11-07 16:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478537065-169286-1-git-send-email-john.garry@huawei.com>
The string for the am max transmissions quirk property
is not correct -> fix it.
Signed-off-by: John Garry <john.garry@huawei.com>
Reviewed-by: Xiang Chen <chenxiang66@hisilicon.com>
---
arch/arm64/boot/dts/hisilicon/hip06.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/hisilicon/hip06.dtsi b/arch/arm64/boot/dts/hisilicon/hip06.dtsi
index b548763..5330abb 100644
--- a/arch/arm64/boot/dts/hisilicon/hip06.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hip06.dtsi
@@ -590,7 +590,7 @@
reg = <0 0xa2000000 0 0x10000>;
sas-addr = [50 01 88 20 16 00 00 00];
hisilicon,sas-syscon = <&pcie_subctl>;
- am-max-trans;
+ hip06-sas-v2-quirk-amt;
ctrl-reset-reg = <0xa18>;
ctrl-reset-sts-reg = <0x5a0c>;
ctrl-clock-ena-reg = <0x318>;
--
1.9.1
^ permalink raw reply related
* [PATCH 2/3] arm64: dts: hisi: disable sas0 and sas2 for d03
From: John Garry @ 2016-11-07 16:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478537065-169286-1-git-send-email-john.garry@huawei.com>
The SAS nodes sas0 and sas2 are not available on d03, so
disable them.
Signed-off-by: John Garry <john.garry@huawei.com>
Acked-by: Xu Wei <xuwei5@hisilicon.com>
---
arch/arm64/boot/dts/hisilicon/hip06-d03.dts | 8 --------
1 file changed, 8 deletions(-)
diff --git a/arch/arm64/boot/dts/hisilicon/hip06-d03.dts b/arch/arm64/boot/dts/hisilicon/hip06-d03.dts
index f54b283..7c4114a 100644
--- a/arch/arm64/boot/dts/hisilicon/hip06-d03.dts
+++ b/arch/arm64/boot/dts/hisilicon/hip06-d03.dts
@@ -41,18 +41,10 @@
status = "ok";
};
-&sas0 {
- status = "ok";
-};
-
&sas1 {
status = "ok";
};
-&sas2 {
- status = "ok";
-};
-
&usb_ohci {
status = "ok";
};
--
1.9.1
^ permalink raw reply related
* [PATCH 3/3] arm64: dts: hisi: add refclk node to hip06 dts files for SAS
From: John Garry @ 2016-11-07 16:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478537065-169286-1-git-send-email-john.garry@huawei.com>
We will only maintain 1 dts for D03 and there are 50MHz
and 66MHz versions of D03: so we expect UEFI to update
refclk rate in the fdt at boot time.
Signed-off-by: John Garry <john.garry@huawei.com>
Reviewed-by: Xiang Chen <chenxiang66@hisilicon.com>
---
arch/arm64/boot/dts/hisilicon/hip06.dtsi | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm64/boot/dts/hisilicon/hip06.dtsi b/arch/arm64/boot/dts/hisilicon/hip06.dtsi
index 5330abb..7b40dce 100644
--- a/arch/arm64/boot/dts/hisilicon/hip06.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hip06.dtsi
@@ -318,6 +318,12 @@
#size-cells = <2>;
ranges;
+ refclk: refclk {
+ compatible = "fixed-clock";
+ clock-frequency = <50000000>;
+ #clock-cells = <0>;
+ };
+
usb_ohci: ohci at a7030000 {
compatible = "generic-ohci";
reg = <0x0 0xa7030000 0x0 0x10000>;
@@ -552,6 +558,7 @@
ctrl-reset-reg = <0xa60>;
ctrl-reset-sts-reg = <0x5a30>;
ctrl-clock-ena-reg = <0x338>;
+ clocks = <&refclk 0>;
queue-count = <16>;
phy-count = <8>;
dma-coherent;
@@ -594,6 +601,7 @@
ctrl-reset-reg = <0xa18>;
ctrl-reset-sts-reg = <0x5a0c>;
ctrl-clock-ena-reg = <0x318>;
+ clocks = <&refclk 0>;
queue-count = <16>;
phy-count = <8>;
dma-coherent;
@@ -635,6 +643,7 @@
ctrl-reset-reg = <0xae0>;
ctrl-reset-sts-reg = <0x5a70>;
ctrl-clock-ena-reg = <0x3a8>;
+ clocks = <&refclk 0>;
queue-count = <16>;
phy-count = <9>;
dma-coherent;
--
1.9.1
^ permalink raw reply related
* [v17 2/2] drm/bridge: Add I2C based driver for ps8640 bridge
From: Matthias Brugger @ 2016-11-07 16:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGS+omDmFdqzuFqcCe9gFGemZc88Yt0_3_o2KwOgW=GN_kCakQ@mail.gmail.com>
On 05/11/16 00:21, Daniel Kurtz wrote:
> On Tue, Oct 25, 2016 at 6:23 AM, Matthias Brugger
> <matthias.bgg@gmail.com> wrote:
>>
>> On 10/18/2016 04:37 PM, Enric Balletbo Serra wrote:
>> [...]
>>>> --- /dev/null
>>>> +++ b/drivers/gpu/drm/bridge/parade-ps8640.c
>> [...]
>>>>
>>>> +
>>>> +/* Firmware */
>>>> +#define PS_FW_NAME "ps864x_fw.bin"
>>>> +
>>>
>>> From where I can download this firmware image?
>>
>> I suppose this FW bits have to be added to linux-firmware repository first, before this patch can be accepted.
>
> All PS8640 devices should already ship with working firmware.
> The firmware update procedure is only used in the unlikely event where
> one wants to update the bridge to a different firmware provided by
> Parade.
>
> Why must the lack of firmware really block landing this driver?
>
> If this is really so, can we just land the functional part of the
> driver first, and add the firmware update in a follow-up patch.
>
After checking other users of request_firmware and check them against
linux-firmware I think we don't need the FW in linux-firmware to get the
driver merged. Especially as there already is a working FW stored on the
device.
Regards,
Matthias
^ permalink raw reply
* [3/4] ARM: EXYNOS: Remove static mapping of SCU SFR
From: Pankaj Dubey @ 2016-11-07 16:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <582007F1.5050803@samsung.com>
Hi Alim,
On 7 November 2016 at 10:19, Alim Akhtar <alim.akhtar@samsung.com> wrote:
>
> Hi Pankaj,
>
>
> On 11/07/2016 08:05 AM, pankaj.dubey wrote:
>>
>> Hi Alim,
>>
>> On Friday 04 November 2016 06:56 PM, Alim Akhtar wrote:
>>>
>>> Hi Pankaj,
>>>
>>> On 11/04/2016 09:09 AM, Pankaj Dubey wrote:
>>>>
>>>> Lets remove static mapping of SCU SFR mainly used in CORTEX-A9 SoC
>>>> based boards.
>>>> Instead use mapping from device tree node of SCU.
>>>>
>>>> Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
>>>> ---
>>>> arch/arm/mach-exynos/exynos.c | 22
>>>> ----------------------
>>>> arch/arm/mach-exynos/include/mach/map.h | 2 --
>>>> arch/arm/mach-exynos/platsmp.c | 18 +++++++++++-------
>>>> arch/arm/mach-exynos/pm.c | 14 +++++++++++---
>>>> arch/arm/mach-exynos/suspend.c | 15 +++++++++++----
>>>> arch/arm/plat-samsung/include/plat/map-s5p.h | 4 ----
>>>> 6 files changed, 33 insertions(+), 42 deletions(-)
>>>>
>>>> diff --git a/arch/arm/mach-exynos/exynos.c
>>>> b/arch/arm/mach-exynos/exynos.c
>>>> index 757fc11..fa08ef9 100644
>>>> --- a/arch/arm/mach-exynos/exynos.c
>>>> +++ b/arch/arm/mach-exynos/exynos.c
>>>> @@ -28,15 +28,6 @@
>>>>
>>>> #include "common.h"
>>>>
>>>> -static struct map_desc exynos4_iodesc[] __initdata = {
>>>> - {
>>>> - .virtual = (unsigned long)S5P_VA_COREPERI_BASE,
>>>> - .pfn = __phys_to_pfn(EXYNOS4_PA_COREPERI),
>>>> - .length = SZ_8K,
>>>> - .type = MT_DEVICE,
>>>> - },
>>>> -};
>>>> -
>>>> static struct platform_device exynos_cpuidle = {
>>>> .name = "exynos_cpuidle",
>>>> #ifdef CONFIG_ARM_EXYNOS_CPUIDLE
>>>> @@ -99,17 +90,6 @@ static int __init exynos_fdt_map_chipid(unsigned
>>>> long node, const char *uname,
>>>> return 1;
>>>> }
>>>>
>>>> -/*
>>>> - * exynos_map_io
>>>> - *
>>>> - * register the standard cpu IO areas
>>>> - */
>>>> -static void __init exynos_map_io(void)
>>>> -{
>>>> - if (soc_is_exynos4())
>>>> - iotable_init(exynos4_iodesc, ARRAY_SIZE(exynos4_iodesc));
>>>> -}
>>>> -
>>>> static void __init exynos_init_io(void)
>>>> {
>>>> debug_ll_io_init();
>>>> @@ -118,8 +98,6 @@ static void __init exynos_init_io(void)
>>>>
>>>> /* detect cpu id and rev. */
>>>> s5p_init_cpu(S5P_VA_CHIPID);
>>>> -
>>>> - exynos_map_io();
>>>> }
>>>>
>>>> /*
>>>> diff --git a/arch/arm/mach-exynos/include/mach/map.h
>>>> b/arch/arm/mach-exynos/include/mach/map.h
>>>> index 5fb0040..0eef407 100644
>>>> --- a/arch/arm/mach-exynos/include/mach/map.h
>>>> +++ b/arch/arm/mach-exynos/include/mach/map.h
>>>> @@ -18,6 +18,4 @@
>>>>
>>>> #define EXYNOS_PA_CHIPID 0x10000000
>>>>
>>>> -#define EXYNOS4_PA_COREPERI 0x10500000
>>>> -
>>>> #endif /* __ASM_ARCH_MAP_H */
>>>> diff --git a/arch/arm/mach-exynos/platsmp.c
>>>> b/arch/arm/mach-exynos/platsmp.c
>>>> index a5d6841..553d0d9 100644
>>>> --- a/arch/arm/mach-exynos/platsmp.c
>>>> +++ b/arch/arm/mach-exynos/platsmp.c
>>>> @@ -224,11 +224,6 @@ static void write_pen_release(int val)
>>>> sync_cache_w(&pen_release);
>>>> }
>>>>
>>>> -static void __iomem *scu_base_addr(void)
>>>> -{
>>>> - return (void __iomem *)(S5P_VA_SCU);
>>>> -}
>>>> -
>>>> static DEFINE_SPINLOCK(boot_lock);
>>>>
>>>> static void exynos_secondary_init(unsigned int cpu)
>>>> @@ -387,14 +382,23 @@ fail:
>>>>
>>>> static void __init exynos_smp_prepare_cpus(unsigned int max_cpus)
>>>> {
>>>> + struct device_node *np;
>>>> + void __iomem *scu_base;
>>>> int i;
>>>>
>>>> exynos_sysram_init();
>>>>
>>>> exynos_set_delayed_reset_assertion(true);
>>>>
>>>> - if (read_cpuid_part() == ARM_CPU_PART_CORTEX_A9)
>>>> - scu_enable(scu_base_addr());
>>>> + if (read_cpuid_part() == ARM_CPU_PART_CORTEX_A9) {
>>>> + np = of_find_compatible_node(NULL, NULL, "arm,cortex-a9-scu");
>>>
>>>
>>> what if of_find_compatible_node() fails? May be add a error check for
>>> the same?
>>
>>
>> Thanks for review.
>>
>> You are right of_find_compatible_node() is bound to fail, but only in
>> case supplied compatible is missing in DT. In our case this piece of
>> code will execute only for Cortex-A9 based SoC (which in case of Exynos
>> SoC is applicable only for Exynos4 series) and we will for sure
>> providing "arm,cortex-a9-scu" in DT, so there is no chance of failure.
>> So I feel extra check on "np" for NULL will add no benefit here.
>>
> Well I am not entirely convenience here, I still feel it better to have those check, lets not assume anything about future, but when I see of_find_compatible_node() uses elsewhere in kernel, both kind of uses are there (with/without error check).
> So, I leave it to you and maintainer to take a call on this, otherwise this patch looks good.
>
> Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com>
>
Well, I further checked details of of_find_compatible_node() and
of_iomap and below is function call chain
of_find_compatible_node //Returns vaild pointer for match, and NULL
for no match
--> __of_device_is_compatible () //Returns 0 for no match, and a
positive integer on match
So in our case lets say for any reason "arm,cortex-a9-scu" compatible
is not present, "np" will be set as NULL.
Next we have following line without check on "np" for NULL,
scu_base = of_iomap(np, 0);
If we see function call sequence of of_iomap we have,
of_iomap(..) //Returns NULL is of_address_to_resource returns non-zero
--> of_address_to_resource(...) // Returns -EINVAL if "addrp" is NULL
--> of_get_address(...) //Returns NULL if "parent" is NULL
--> of_get_parent(...) //Returns np with refcount
incremented if np is NOT NULL else returns NULL
So in our case we will get scu_base as NULL if we pass "np" as NULL,
and on very next line we have check on scu_base, which will prevent us
from de-referencing a NULL pointer. So there won't be any CRASH or
abnormal behavior, due to not checking "np" for NULL.
I think this is the reason in many places in kernel there is no check
for NULL for of_find_compatible_node, surely some places there are
checks, but as per current code flow if someone is calling of_iomap
with np as NULL there won't be any crash and of_iomap will gracefully
returns NULL in that case. Also of_node_put and of_node_get has check
for NULL received device_node and handles it gracefully.
But one thing I missed is that in case scu_base is NULL we are not
suppose to move ahead in function exynos_smp_prepare_cpus(..), This
part I will update and post next version with appropriate change.
Thanks,
Pankaj Dubey
>>
>>
>> Thanks,
>> Pankaj Dubey
>>
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] arm/vdso: introduce vdso_mremap hook
From: Christopher Covington @ 2016-11-07 17:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161101172214.2938-1-dsafonov@virtuozzo.com>
Hi Dmitry,
On 11/01/2016 01:22 PM, Dmitry Safonov wrote:
> Add vdso_mremap hook which will fix context.vdso pointer after mremap()
> on vDSO vma. This is needed for correct landing after syscall execution.
> Primary goal of this is for CRIU on arm - we need to restore vDSO image
> at the exactly same place where the vma was in dumped application. With
> the help of this hook we'll move vDSO at the new position.
> The CRIU code handles situations like when vDSO of dumped application
> was different from vDSO on restoring system. This usally happens when
> some new symbols are being added to vDSO. In these situations CRIU
> inserts jump trampolines from old vDSO blob to new vDSO on restore.
> By that reason even if on restore vDSO blob lies on the same address as
> blob in dumped application - we still need to move it if it differs.
>
> There was previously attempt to add this functionality for arm64 by
> arch_mremap hook [1], while this patch introduces this with minimal
> effort - the same way I've added it to x86:
> commit b059a453b1cf ("x86/vdso: Add mremap hook to vm_special_mapping")
>
> At this moment, vdso restoring code is disabled for arm/arm64 arch
> in CRIU [2], so C/R is only working for !CONFIG_VDSO kernels. This patch
> is aimed to fix that.
> The same hook may be introduced for arm64 kernel, but at this moment
> arm64 vdso code is actively reworked by Kevin, so we can do it on top.
> Separately, I've refactored arch_remap hook out from ppc64 [3].
>
> [1]: https://marc.info/?i=1448455781-26660-1-git-send-email-cov at codeaurora.org
> [2]: https://github.com/xemul/criu/blob/master/Makefile#L39
> [3]: https://marc.info/?i=20161027170948.8279-1-dsafonov at virtuozzo.com
>
> Cc: Kevin Brodsky <kevin.brodsky@arm.com>
> Cc: Christopher Covington <cov@codeaurora.org>
> Cc: Andy Lutomirski <luto@amacapital.net>
> Cc: Oleg Nesterov <oleg@redhat.com>
> Cc: Russell King <linux@armlinux.org.uk>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: linux-mm at kvack.org
> Cc: Cyrill Gorcunov <gorcunov@openvz.org>
> Cc: Pavel Emelyanov <xemul@virtuozzo.com>
> Signed-off-by: Dmitry Safonov <dsafonov@virtuozzo.com>
> ---
> arch/arm/kernel/vdso.c | 21 +++++++++++++++++++++
> 1 file changed, 21 insertions(+)
>
> diff --git a/arch/arm/kernel/vdso.c b/arch/arm/kernel/vdso.c
> index 53cf86cf2d1a..d1001f87c2f6 100644
> --- a/arch/arm/kernel/vdso.c
> +++ b/arch/arm/kernel/vdso.c
> @@ -54,8 +54,11 @@ static const struct vm_special_mapping vdso_data_mapping = {
> .pages = &vdso_data_page,
> };
>
> +static int vdso_mremap(const struct vm_special_mapping *sm,
> + struct vm_area_struct *new_vma);
> static struct vm_special_mapping vdso_text_mapping __ro_after_init = {
> .name = "[vdso]",
> + .mremap = vdso_mremap,
> };
>
> struct elfinfo {
> @@ -254,6 +257,24 @@ void arm_install_vdso(struct mm_struct *mm, unsigned long addr)
> mm->context.vdso = addr;
> }
>
> +static int vdso_mremap(const struct vm_special_mapping *sm,
> + struct vm_area_struct *new_vma)
> +{
> + unsigned long new_size = new_vma->vm_end - new_vma->vm_start;
> + unsigned long vdso_size = (vdso_total_pages - 1) << PAGE_SHIFT;
> +
> + /* Disallow partial vDSO blob remap */
> + if (vdso_size != new_size)
> + return -EINVAL;
> +
> + if (WARN_ON_ONCE(current->mm != new_vma->vm_mm))
> + return -EFAULT;
> +
> + current->mm->context.vdso = new_vma->vm_start;
> +
> + return 0;
> +}
> +
> static void vdso_write_begin(struct vdso_data *vdata)
> {
> ++vdso_data->seq_count;
>
What do you think about putting this code somewhere generic (not under
arch/*), so that powerpc and arm64 can reuse it once the cosmetic changes
to make them compatible are made? My thought was that it could be defined
underneath CONFIG_GENERIC_VDSO, which architectures could select as they
became compatible.
Thanks,
Cov
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code
Aurora Forum, a Linux Foundation Collaborative Project.
^ 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