* [PATCH] arm64: dts: exynos: Remove the te-gpios property in the TM2 boards
From: Inki Dae @ 2017-04-25 7:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1493085261-3488-1-git-send-email-hoegeun.kwon@samsung.com>
2017? 04? 25? 10:54? Hoegeun Kwon ?(?) ? ?:
> The decon uses HW-TRIGGER, so TE interrupt is not necessary.
> Therefore, remove the te-gpios property in the TM2 dts.
>
> Signed-off-by: Hoegeun Kwon <hoegeun.kwon@samsung.com>
> ---
> arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
> index 3ff9527..23191eb 100644
> --- a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
> +++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
> @@ -60,7 +60,6 @@
> vci-supply = <&ldo28_reg>;
> reset-gpios = <&gpg0 0 GPIO_ACTIVE_LOW>;
> enable-gpios = <&gpf1 5 GPIO_ACTIVE_HIGH>;
> - te-gpios = <&gpf1 3 GPIO_ACTIVE_HIGH>;
Reviewed-by: Inki Dae <inki.dae@samsung.com>
Thanks,
Inki Dae
> };
> };
>
>
^ permalink raw reply
* [RFC] minimum gcc version for kernel: raise to gcc-4.3 or 4.6?
From: Geert Uytterhoeven @ 2017-04-25 7:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGXu5jKCSFVhGSD5mGLiAo6-G+k24g2Y=9p8Kr2-SffAY=uEBQ@mail.gmail.com>
On Mon, Apr 24, 2017 at 10:52 PM, Kees Cook <keescook@chromium.org> wrote:
> On Mon, Apr 24, 2017 at 1:30 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> How about this approach then:
>>
>> - To keep it simple, we update the README.rst to say that a minimum
>> gcc-4.3 is required, while recommending gcc-4.9 for all architectures
>> - Support for gcc-4.0 and earlier gets removed from linux/compiler.h,
>> and instead we add a summary of what I found, explaining that
>> gcc-4.1 has active users on a few architectures.
>> - We make the Makefile show a warning once during compilation for
>> gcc earlier than 4.3.
>
> This sounds good to me!
+1
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH] fs: Preventing READ_IMPLIES_EXEC Propagation
From: dongbo (E) @ 2017-04-25 7:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170424155841.GH25449@e104818-lin.cambridge.arm.com>
On 2017/4/24 23:58, Catalin Marinas wrote:
> On Mon, Apr 24, 2017 at 04:40:23PM +0100, Will Deacon wrote:
>> On Wed, Apr 19, 2017 at 11:33:14AM +0100, Catalin Marinas wrote:
>>> On Tue, Apr 18, 2017 at 09:01:52PM +0100, Peter Maydell wrote:
>>>> On 18 April 2017 at 18:01, Catalin Marinas <catalin.marinas@arm.com> wrote:
>>>>> On Thu, Apr 13, 2017 at 08:33:52PM +0800, dongbo (E) wrote:
>>>>>> From: Dong Bo <dongbo4@huawei.com>
>>>>>>
>>>>>> In load_elf_binary(), once the READ_IMPLIES_EXEC flag is set,
>>>>>> the flag is propagated to its child processes, even the elf
>>>>>> files are marked as not requiring executable stack. It may
>>>>>> cause superfluous operations on some arch, e.g.
>>>>>> __sync_icache_dcache on aarch64 due to a PROT_READ mmap is
>>>>>> also marked as PROT_EXEC.
>>>>
>>>>> That's affecting most architectures with a risk of ABI breakage. We
>>>>> could do it on arm64 only, though I'm not yet clear on the ABI
>>>>> implications (at a first look, there shouldn't be any).
>>>>
>>>> Is there a reason why it isn't just straightforwardly a bug
>>>> (which we could fix) to make READ_IMPLIES_EXEC propagate to
>>>> child processes?
>>>
>>> While I agree that it looks like a bug, if there are user programs
>>> relying on such bug we call it "ABI". On arm64, I don't think there is
>>> anything relying on inheriting READ_IMPLIES_EXEC but I wouldn't change
>>> the compat task handling without the corresponding change in arch/arm.
>>>
>>>> AFAICT this should be per-process: just because
>>>> init happens not to have been (re)compiled to permit non-executable
>>>> stacks doesn't mean every process on the system needs to have
>>>> an executable stack.
>>>
>>> I think this also affects the heap if brk(2) is used (via
>>> VM_DATA_DEFAULT_FLAGS though I guess malloc mostly uses mmap these
>>> days).
>>
>> I think it also affects mprotect, which is more worrying imo, particularly
>> for things like JIT code that is ported from 32-bit (although a quick look
>> at v8, ionmonkey and art suggests they all pass PROT_EXEC when needed).
>
> As Peter said, the default behaviour is READ_IMPLIES_EXEC off, so JIT
> code must already pass PROT_EXEC if it wants executable permission. The
> question is whether any user code relies on READ_IMPLIES_EXEC being
> passed down to child processes. I don't think so but I would be
> reluctant to make an such cross-arch change (happy to do it for arm64
> though).
>
OK, I have re-built a patch for arm64 as you suggested. Thanks.
> Since linux-arch was cc'ed in the middle of this thread, I doubt people
> would reply. I suggest that the original patch is re-posted to
> linux-arch directly.
>
Re-posted.
Bo Dong
.
^ permalink raw reply
* [PATCH REPOST] fs: Preventing READ_IMPLIES_EXEC Propagation
From: dongbo (E) @ 2017-04-25 6:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2414e3b3-03f6-bd6c-5aa4-ad58c66b5aa5@huawei.com>
From: Dong Bo <dongbo4@huawei.com>
In load_elf_binary(), once the READ_IMPLIES_EXEC flag is set,
the flag is propagated to its child processes, even the elf
files are marked as not requiring executable stack. It may
cause superfluous operations on some arch, e.g.
__sync_icache_dcache on aarch64 due to a PROT_READ mmap is
also marked as PROT_EXEC.
This patch was originally posted and discussed here:
https://patchwork.kernel.org/patch/9685891/
Signed-off-by: Dong Bo <dongbo4@huawei.com>
---
fs/binfmt_elf.c | 2 ++
fs/binfmt_elf_fdpic.c | 2 ++
2 files changed, 4 insertions(+)
diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index 5075fd5..c52e670 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -863,6 +863,8 @@ static int load_elf_binary(struct linux_binprm *bprm)
SET_PERSONALITY2(loc->elf_ex, &arch_state);
if (elf_read_implies_exec(loc->elf_ex, executable_stack))
current->personality |= READ_IMPLIES_EXEC;
+ else
+ current->personality &= ~READ_IMPLIES_EXEC;
if (!(current->personality & ADDR_NO_RANDOMIZE) && randomize_va_space)
current->flags |= PF_RANDOMIZE;
diff --git a/fs/binfmt_elf_fdpic.c b/fs/binfmt_elf_fdpic.c
index cf93a4f..c4bc4d0 100644
--- a/fs/binfmt_elf_fdpic.c
+++ b/fs/binfmt_elf_fdpic.c
@@ -354,6 +354,8 @@ static int load_elf_fdpic_binary(struct linux_binprm *bprm)
set_personality(PER_LINUX);
if (elf_read_implies_exec(&exec_params.hdr, executable_stack))
current->personality |= READ_IMPLIES_EXEC;
+ else
+ current->personality &= ~READ_IMPLIES_EXEC;
setup_new_exec(bprm);
-- 1.9.1
.
^ permalink raw reply related
* [PATCH v3 2/3] crypto: inside-secure: add SafeXcel EIP197 crypto engine driver
From: Antoine Tenart @ 2017-04-25 6:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2475079.gcOV5qCq7E@tauon.chronox.de>
Hi Stephan,
On Mon, Apr 24, 2017 at 02:59:05PM +0200, Stephan M?ller wrote:
> Am Montag, 24. April 2017, 09:54:06 CEST schrieb Antoine Tenart:
>
> > +struct safexcel_cipher_ctx {
> > + struct safexcel_context base;
> > + struct safexcel_crypto_priv *priv;
> > +
> > + enum safexcel_cipher_direction direction;
> > + u32 mode;
> > +
> > + __le32 key[8];
>
> Can you please help me find the location where this memory is zeroized when
> released?
It's not, I'll fix this.
> > +static void safexcel_cipher_token(struct safexcel_cipher_ctx *ctx,
> > + struct crypto_async_request *async,
> > + struct safexcel_command_desc *cdesc,
> > + u32 length)
> > +{
> > + struct ablkcipher_request *req = ablkcipher_request_cast(async);
> > + struct safexcel_token *token;
> > + unsigned offset = 0;
> > +
> > + if (ctx->mode == CONTEXT_CONTROL_CRYPTO_MODE_CBC) {
> > + offset = AES_BLOCK_SIZE / sizeof(u32);
> > + memcpy(cdesc->control_data.token, req->info, AES_BLOCK_SIZE);
> > +
> > + cdesc->control_data.options |= EIP197_OPTION_4_TOKEN_IV_CMD;
> > + }
> > +
> > + token = (struct safexcel_token *)(cdesc->control_data.token + offset);
> > +
> > + token[0].opcode = EIP197_TOKEN_OPCODE_DIRECTION;
> > + token[0].packet_length = length;
> > + token[0].stat = EIP197_TOKEN_STAT_LAST_PACKET;
> > + token[0].instructions = EIP197_TOKEN_INS_LAST |
> > + EIP197_TOKEN_INS_TYPE_CRYTO |
> > + EIP197_TOKEN_INS_TYPE_OUTPUT;
> > +}
> > +
> > +static int safexcel_aes_setkey(struct crypto_ablkcipher *ctfm, const u8
> > *key, + unsigned int len)
> > +{
>
> You still use ablkcipher. I thought that it is on its way out in favor of the
> skcipher API. Why do you stick to ablkcipher?
>
> Note, a change could be as simple as s/ablkcipher/skcipher/g
Because I wasn't aware of this :) I'll update.
> > + struct crypto_tfm *tfm = crypto_ablkcipher_tfm(ctfm);
> > + struct safexcel_cipher_ctx *ctx = crypto_tfm_ctx(tfm);
> > + struct crypto_aes_ctx aes;
> > + int ret, i;
> > +
> > + ret = crypto_aes_expand_key(&aes, key, len);
> > + if (ret) {
> > + crypto_ablkcipher_set_flags(ctfm, CRYPTO_TFM_RES_BAD_KEY_LEN);
> > + return ret;
> > + }
> > +
> > + for (i = 0; i < len / sizeof(u32); i++) {
> > + if (ctx->key[i] != cpu_to_le32(aes.key_enc[i])) {
> > + ctx->base.needs_inv = true;
> > + break;
> > + }
> > + }
> > +
> > + for (i = 0; i < len / sizeof(u32); i++)
> > + ctx->key[i] = cpu_to_le32(aes.key_enc[i]);
> > +
> > + ctx->key_len = len;
>
> memzero_explicit(aes)?
OK, I'll update.
> > +static int safexcel_aes_send(struct crypto_async_request *async,
> > + int ring, struct safexcel_request *request,
> > + int *commands, int *results)
> > +{
> > + struct ablkcipher_request *req = ablkcipher_request_cast(async);
> > + struct safexcel_cipher_ctx *ctx = crypto_tfm_ctx(req->base.tfm);
> > + struct safexcel_crypto_priv *priv = ctx->priv;
> > + struct safexcel_command_desc *cdesc;
> > + struct safexcel_result_desc *rdesc;
> > + struct scatterlist *sg;
> > + int nr_src, nr_dst, n_cdesc = 0, n_rdesc = 0, queued = req->nbytes;
> > + int i, ret = 0;
> > +
> > + request->req = &req->base;
> > +
> > + if (req->src == req->dst) {
> > + nr_src = dma_map_sg(priv->dev, req->src,
> > + sg_nents_for_len(req->src, req->nbytes),
> > + DMA_BIDIRECTIONAL);
> > + nr_dst = nr_src;
> > + if (!nr_src)
> > + return -EINVAL;
> > + } else {
> > + nr_src = dma_map_sg(priv->dev, req->src,
> > + sg_nents_for_len(req->src, req->nbytes),
> > + DMA_TO_DEVICE);
> > + if (!nr_src)
> > + return -EINVAL;
> > +
> > + nr_dst = dma_map_sg(priv->dev, req->dst,
> > + sg_nents_for_len(req->dst, req->nbytes),
> > + DMA_FROM_DEVICE);
> > + if (!nr_dst) {
> > + dma_unmap_sg(priv->dev, req->src,
> > + sg_nents_for_len(req->src, req->nbytes),
> > + DMA_TO_DEVICE);
> > + return -EINVAL;
> > + }
> > + }
> > +
> > + memcpy(ctx->base.ctxr->data, ctx->key, ctx->key_len);
>
> Is ctxr->data properly zeroized?
No, I'll update.
Thanks for the review!
Antoine
--
Antoine T?nart, 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/20170425/4970b066/attachment-0001.sig>
^ permalink raw reply
* [PATCH v3 1/3] mtd: nand: Cleanup/rework the atmel_nand driver
From: Boris Brezillon @ 2017-04-25 6:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170425010930.GA120971@google.com>
On Mon, 24 Apr 2017 18:09:30 -0700
Brian Norris <computersforpeace@gmail.com> wrote:
> On Thu, Mar 16, 2017 at 09:02:40AM +0100, Boris Brezillon wrote:
>
> > diff --git a/drivers/mtd/nand/atmel/nand-controller.c b/drivers/mtd/nand/atmel/nand-controller.c
> > new file mode 100644
> > index 000000000000..f71b9e5d7d9d
> > --- /dev/null
> > +++ b/drivers/mtd/nand/atmel/nand-controller.c
> > @@ -0,0 +1,2198 @@
> [...]
>
> > +static int
> > +atmel_hsmc_nand_controller_legacy_init(struct atmel_hsmc_nand_controller *nc)
> > +{
> > + struct regmap_config regmap_conf = {
> > + .reg_bits = 32,
> > + .val_bits = 32,
> > + .reg_stride = 4,
> > + .val_bits = 32,
>
> You assigned val_bits twice. Is that just a harmless mistake, or did you
> mean to set something else?
Nope, I didn't mean to set another field to 32. I'll just apply the fix
you provided.
Thanks,
Boris
^ permalink raw reply
* [PATCH] Revert "arm64: Increase the max granular size"
From: Ding Tianhong @ 2017-04-25 6:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CA+sq2Cc8tqpGcUKkLh22e7_TZqu5jmrV9XKddVnxGfDsoSBf3A@mail.gmail.com>
On 2017/4/19 21:11, Sunil Kovvuri wrote:
> On Wed, Apr 19, 2017 at 5:31 PM, Catalin Marinas
> <catalin.marinas@arm.com> wrote:
>> On Tue, Apr 18, 2017 at 10:35:02PM +0530, Sunil Kovvuri wrote:
>>> On Tue, Apr 18, 2017 at 8:18 PM, Catalin Marinas
>>> <catalin.marinas@arm.com> wrote:
>>>> On Mon, Apr 17, 2017 at 04:08:52PM +0530, Sunil Kovvuri wrote:
>>>>>>> >> Do you have an explanation on the performance variation when
>>>>>>> >> L1_CACHE_BYTES is changed? We'd need to understand how the network stack
>>>>>>> >> is affected by L1_CACHE_BYTES, in which context it uses it (is it for
>>>>>>> >> non-coherent DMA?).
>>>>>>> >
>>>>>>> > network stack use SKB_DATA_ALIGN to align.
>>>>>>> > ---
>>>>>>> > #define SKB_DATA_ALIGN(X) (((X) + (SMP_CACHE_BYTES - 1)) & \
>>>>>>> > ~(SMP_CACHE_BYTES - 1))
>>>>>>> >
>>>>>>> > #define SMP_CACHE_BYTES L1_CACHE_BYTES
>>>>>>> > ---
>>>>>>> > I think this is the reason of performance regression.
>>>>>>> >
>>>>>>>
>>>>>>> Yes this is the reason for performance regression. Due to increases L1 cache alignment the
>>>>>>> object is coming from next kmalloc slab and skb->truesize is changing from 2304 bytes to
>>>>>>> 4352 bytes. This in turn increases sk_wmem_alloc which causes queuing of less send buffers.
>>>>>
>>>>> With what traffic did you check 'skb->truesize' ? Increase from
>>>>> 2304 to 4352 bytes doesn't seem to be real. I checked with ICMP
>>>>> pkts with maximum size possible with 1500byte MTU and I don't see
>>>>> such a bump. If the bump is observed with Iperf sending TCP packets
>>>>> then I suggest to check if TSO is playing a part over here.
>>>>
>>>> I haven't checked truesize but I added some printks to __alloc_skb() (on
>>>> a Juno platform) and the size argument to this function is 1720 on many
>>>> occasions. With sizeof(struct skb_shared_info) of 320, the actual data
>>>> allocation is exactly 2048 when using 64 byte L1_CACHE_SIZE. With a
>>>> 128 byte cache size, it goes slightly over 2K, hence the 4K slab
>>>> allocation.
>>>
>>> Understood but still in my opinion this '4K slab allocation' cannot be
>>> considered as an issue with cache line size, there are many network
>>> drivers out there which do receive buffer or page recycling to
>>> minimize (sometimes almost to zero) the cost of buffer allocation.
>>
>> The slab allocation shouldn't make much difference (unless you are
>> running on a memory constrained system) but I don't understand how
>> skb->truesize (which is almost half unused) affects the sk_wmem_alloc
>> and its interaction with other bits in the network stack (e.g.
>> tcp_limit_output_bytes).
>>
>> However, I do think it's worth investigating further to fully understand
>> the issue.
>
> Absolutely.
>
>>
>>>> The 1720 figure surprised me a bit as well since I was
>>>> expecting something close to 1500.
>>>>
>>>> The thing that worries me is that skb->data may be used as a buffer to
>>>> DMA into. If that's the case, skb_shared_info is wrongly aligned based
>>>> on SMP_CACHE_BYTES only and can lead to corruption on a non-DMA-coherent
>>>> platform. It should really be ARCH_DMA_MINALIGN.
>>>
>>> I didn't get this, if you see __alloc_skb()
>>>
>>> 229 size = SKB_DATA_ALIGN(size);
>>> 230 size += SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
>>>
>>> both DMA buffer and skb_shared_info are aligned to a cacheline separately,
>>> considering 128byte alignment guarantees 64byte alignment as well, how
>>> will this lead to corruption ?
>>
>> It's the other way around: you align only to 64 byte while running on a
>> platform with 128 byte cache lines and non-coherent DMA.
>
> Okay, I mistook your statement. This is indeed a valid statement.
>
>>> And if platform is non-DMA-coherent then again it's the driver which
>>> should take of coherency by using appropriate map/unmap APIs and
>>> should avoid any cacheline sharing btw DMA buffer and skb_shared_info.
>>
>> The problem is that the streaming DMA API can only work correctly on
>> cacheline-aligned buffers (because of the cache invalidation it performs
>> for DMA ops; even with clean&invalidate, the operation isn't always safe
>> if a cacheline is shared between DMA and CPU buffers). In the skb case,
>> we could have the data potentially sharing the last addresses of a DMA
>> buffer with struct skb_shared_info.
>>
>> We may be able to get away with SKB_DATA_ALIGN not using
>> ARCH_DMA_MINALIGN *if* skb_shared_info is *not* written before or during
>> an inbound DMA transfer (though such tricks are arch specific).
>>
>>>> IIUC, the Cavium platform has coherent DMA, so it shouldn't be an issue
>>>> if we go back to 64 byte cache lines.
>>>
>>> Yes, Cavium platform is DMA coherent and there is no issue with reverting back
>>> to 64byte cachelines. But do we want to do this because some platform has a
>>> performance issue and this is an easy way to solve it. IMHO there seems
>>> to be many ways to solve performance degradation within the driver itself, and
>>> if those doesn't work then probably it makes sense to revert this.
>>
>> My initial thought was to revert the change because it was causing a
>> significant performance regression on certain SoC. But given that it
>> took over a year for people to follow up, it doesn't seem too urgent, so
>> we should rather try to understand the issue and potential side effects
>> of moving back to a 64 byte cache line.
>
> Yes.
>
> Thanks,
> Sunil.
>
Hi, continue this discussion, I have test this patch on hisilicon D05 board,
the lmbench looks much better after applying this patch, my kernel version is 4.1:
Lmbench? 128B/1core 128B/4core 128B/16core 128B/32core 64B/1core 64B/4core 64B/16core 64B/32core
rd 9393.81 9118.1 23693.96 42026.32 8433.26 8635.96 11563.52 20142.34
frd 7748.18 7003.02 23336.95 42271.16 7269.42 7091.55 11211.67 19188.03
wr 7880.8 7403.61 12471.28 22545.83 7453.13 7066.01 11140.08 19625.04
fwr 8783.97 8911.85 25318.05 46540 8953.55 8894.28 19094.92 30646.38
bzero 8848.33 8873.43 25416.46 46620.68 8998.88 8877.64 19092.39 32537.9
rdwr 5854.37 5759.17 12346.27 22928.25 5601.26 5517.21 6608.84 11717.91
cp 5251.07 5118.19 8324.99 15616.85 4997.66 4964.38 5833.04 9600.68
fcp 6883.94 5446.19 11588.7 21534.58 6766.76 6625.98 8757.97 15844.67
bcopy 6561.41 6402.99 9070.05 17076.24 6839.07 6959.03 8900.73 15868.25
you could see that when use the 32 cores, the 128B L1 cache line is much better than the 64B, up 200%.
I think the performance would be shown difference on different chip, so I suggest not to revert this patch and test more about it.
Some details about the hisilicon D05 board chip:
L1/L2: 64B
L3: 128B
Thanks
Ding
>>
>> --
>> Catalin
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
> .
>
^ permalink raw reply
* [PATCH V2 2/2] clk: rockchip: fix the incorrect ids
From: Eddie Cai @ 2017-04-25 6:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1493102470-22965-1-git-send-email-eddie.cai.linux@gmail.com>
the ids of clk_testout1 and clk_testout2 is incorrect now. let's correct it
Signed-off-by: Eddie Cai <eddie.cai.linux@gmail.com>
---
drivers/clk/rockchip/clk-rk3399.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/rockchip/clk-rk3399.c b/drivers/clk/rockchip/clk-rk3399.c
index 73121b14..f3656ba 100644
--- a/drivers/clk/rockchip/clk-rk3399.c
+++ b/drivers/clk/rockchip/clk-rk3399.c
@@ -1066,13 +1066,13 @@ enum rk3399_pmu_plls {
/* cif_testout */
MUX(0, "clk_testout1_pll_src", mux_pll_src_cpll_gpll_npll_p, 0,
RK3399_CLKSEL_CON(38), 6, 2, MFLAGS),
- COMPOSITE(0, "clk_testout1", mux_clk_testout1_p, 0,
+ COMPOSITE(SCLK_TESTCLKOUT1, "clk_testout1", mux_clk_testout1_p, 0,
RK3399_CLKSEL_CON(38), 5, 1, MFLAGS, 0, 5, DFLAGS,
RK3399_CLKGATE_CON(13), 14, GFLAGS),
MUX(0, "clk_testout2_pll_src", mux_pll_src_cpll_gpll_npll_p, 0,
RK3399_CLKSEL_CON(38), 14, 2, MFLAGS),
- COMPOSITE(0, "clk_testout2", mux_clk_testout2_p, 0,
+ COMPOSITE(SCLK_TESTCLKOUT2, "clk_testout2", mux_clk_testout2_p, 0,
RK3399_CLKSEL_CON(38), 13, 1, MFLAGS, 8, 5, DFLAGS,
RK3399_CLKGATE_CON(13), 15, GFLAGS),
--
1.9.1
^ permalink raw reply related
* [PATCH V2 1/2] clk: rockchip: add ids for camera
From: Eddie Cai @ 2017-04-25 6:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1493102470-22965-1-git-send-email-eddie.cai.linux@gmail.com>
we use SCLK_TESTCLKOUT1 and SCLK_TESTCLKOUT2 for camera, so add those ids.
Signed-off-by: Eddie Cai <eddie.cai.linux@gmail.com>
---
include/dt-bindings/clock/rk3399-cru.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/dt-bindings/clock/rk3399-cru.h b/include/dt-bindings/clock/rk3399-cru.h
index 220a60f..22cb1df 100644
--- a/include/dt-bindings/clock/rk3399-cru.h
+++ b/include/dt-bindings/clock/rk3399-cru.h
@@ -132,6 +132,8 @@
#define SCLK_RMII_SRC 166
#define SCLK_PCIEPHY_REF100M 167
#define SCLK_DDRC 168
+#define SCLK_TESTCLKOUT1 169
+#define SCLK_TESTCLKOUT2 170
#define DCLK_VOP0 180
#define DCLK_VOP1 181
--
1.9.1
^ permalink raw reply related
* [PATCH V2 0/2] correct ids for clk_testout
From: Eddie Cai @ 2017-04-25 6:41 UTC (permalink / raw)
To: linux-arm-kernel
we use clk_testout1 and clk_testout2 for camera. e.g. mipi 24M mclk. the ids of
clk_testout1 and clk_testout2 is wrong. it's time to correct it.
Eddie Cai (2):
clk: rockchip: add ids for camera
clk: rockchip: fix the incorrect ids
drivers/clk/rockchip/clk-rk3399.c | 4 ++--
include/dt-bindings/clock/rk3399-cru.h | 2 ++
2 files changed, 4 insertions(+), 2 deletions(-)
--
1.9.1
^ permalink raw reply
* [PATCH v4 00/21] PCI: fix config space memory mappings
From: Jon Masters @ 2017-04-25 6:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170419164913.19674-1-lorenzo.pieralisi@arm.com>
On 04/19/2017 12:48 PM, Lorenzo Pieralisi wrote:
> On some platforms (ie ARM/ARM64) ioremap fails to comply with the PCI
> configuration non-posted write transactions requirement, because it
> provides a memory mapping that issues "bufferable" or, in PCI terms
> "posted" write transactions. Likewise, the current pci_remap_iospace()
> implementation maps the physical address range that the PCI translates
> to I/O space cycles to virtual address space through pgprot_device()
> attributes that on eg ARM64 provides a memory mapping issuing
> posted writes transactions, which is not PCI specifications compliant.
Side note that I've pinged all of the ARM server vendors and asked them
to verify this patch series on their platforms.
Jon.
^ permalink raw reply
* [PATCH v7 1/4] syscalls: Restore address limit after a syscall
From: Ingo Molnar @ 2017-04-25 6:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170410164420.64003-1-thgarnie@google.com>
* Thomas Garnier <thgarnie@google.com> wrote:
> This patch ensures a syscall does not return to user-mode with a kernel
> address limit. If that happened, a process can corrupt kernel-mode
> memory and elevate privileges.
Don't start changelogs with 'This patch' - it's obvious that we are talking about
this patch. Writing:
Ensure that a syscall does not return to user-mode with a kernel address limit.
If that happens, a process can corrupt kernel-mode memory and elevate
privileges.
also note the spelling fix I did. (There's another spelling error elsewhere in
this changelog as well.)
Please read changelogs!
> For example, it would mitigation this bug:
>
> - https://bugs.chromium.org/p/project-zero/issues/detail?id=990
>
> The CONFIG_ARCH_NO_SYSCALL_VERIFY_PRE_USERMODE_STATE option is also
> added so each architecture can optimize this change.
As I pointed it out in my previous reply this Kconfig name is awfully long - but
it should have been obvious when this changelog was written ...
> Signed-off-by: Thomas Garnier <thgarnie@google.com>
> Tested-by: Kees Cook <keescook@chromium.org>
> ---
> Based on next-20170410
> ---
> arch/s390/Kconfig | 1 +
> include/linux/syscalls.h | 26 +++++++++++++++++++++++++-
> init/Kconfig | 6 ++++++
> kernel/sys.c | 13 +++++++++++++
> 4 files changed, 45 insertions(+), 1 deletion(-)
>
> diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
> index d25435d94b6e..489a0cc6e46b 100644
> --- a/arch/s390/Kconfig
> +++ b/arch/s390/Kconfig
> @@ -103,6 +103,7 @@ config S390
> select ARCH_INLINE_WRITE_UNLOCK_BH
> select ARCH_INLINE_WRITE_UNLOCK_IRQ
> select ARCH_INLINE_WRITE_UNLOCK_IRQRESTORE
> + select ARCH_NO_SYSCALL_VERIFY_PRE_USERMODE_STATE
> select ARCH_SAVE_PAGE_KEYS if HIBERNATION
> select ARCH_SUPPORTS_ATOMIC_RMW
> select ARCH_SUPPORTS_DEFERRED_STRUCT_PAGE_INIT
> diff --git a/include/linux/syscalls.h b/include/linux/syscalls.h
> index 980c3c9b06f8..801a7a74fe28 100644
> --- a/include/linux/syscalls.h
> +++ b/include/linux/syscalls.h
> @@ -191,6 +191,27 @@ extern struct trace_event_functions exit_syscall_print_funcs;
> SYSCALL_METADATA(sname, x, __VA_ARGS__) \
> __SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
>
> +
> +/*
> + * Called before coming back to user-mode. Returning to user-mode with an
> + * address limit different than USER_DS can allow to overwrite kernel memory.
> + */
> +static inline void verify_pre_usermode_state(void) {
> + BUG_ON(!segment_eq(get_fs(), USER_DS));
> +}
Non-standard coding style.
> +
> +#ifndef CONFIG_ARCH_NO_SYSCALL_VERIFY_PRE_USERMODE_STATE
> +#define __CHECK_USER_CALLER() \
> + bool user_caller = segment_eq(get_fs(), USER_DS)
> +#define __VERIFY_PRE_USERMODE_STATE() \
> + if (user_caller) verify_pre_usermode_state()
> +#else
> +#define __CHECK_USER_CALLER()
> +#define __VERIFY_PRE_USERMODE_STATE()
> +asmlinkage void address_limit_check_failed(void);
> +#endif
> +
> +
> #define __PROTECT(...) asmlinkage_protect(__VA_ARGS__)
> #define __SYSCALL_DEFINEx(x, name, ...) \
> asmlinkage long sys##name(__MAP(x,__SC_DECL,__VA_ARGS__)) \
> @@ -199,7 +220,10 @@ extern struct trace_event_functions exit_syscall_print_funcs;
> asmlinkage long SyS##name(__MAP(x,__SC_LONG,__VA_ARGS__)); \
> asmlinkage long SyS##name(__MAP(x,__SC_LONG,__VA_ARGS__)) \
> { \
> - long ret = SYSC##name(__MAP(x,__SC_CAST,__VA_ARGS__)); \
> + long ret; \
> + __CHECK_USER_CALLER(); \
> + ret = SYSC##name(__MAP(x,__SC_CAST,__VA_ARGS__)); \
> + __VERIFY_PRE_USERMODE_STATE(); \
> __MAP(x,__SC_TEST,__VA_ARGS__); \
> __PROTECT(x, ret,__MAP(x,__SC_ARGS,__VA_ARGS__)); \
> return ret; \
BTW., the '__VERIFY_PRE_USERMODE_STATE()' name is highly misleading: the 'pre'
prefix suggests that this is done before a system call - while it's done
afterwards.
The solution is to not try to specify the exact call placement in the name, just
describe the functionality (and harmonize along the common prefix).
> +config ARCH_NO_SYSCALL_VERIFY_PRE_USERMODE_STATE
> + bool
> + help
> + Disable the generic pre-usermode state verification. Allow each
> + architecture to optimize how and when the verification is done.
> +
Please name the Kconfig symbols something like this:
CONFIG_ADDR_LIMIT_CHECK
CONFIG_ADDR_LIMIT_CHECK_ARCH
or so, which tells us whether the check is done by the architecture code, without
breaking the col80 limit with a single Kconfig name.
BTW:
> +#ifdef CONFIG_ARCH_NO_SYSCALL_VERIFY_PRE_USERMODE_STATE
> +/*
> + * This function is called when an architecture specific implementation detected
> + * an invalid address limit. The generic user-mode state checker will finish on
> + * the appropriate BUG_ON.
> + */
> +asmlinkage void address_limit_check_failed(void)
> +{
> + verify_pre_usermode_state();
> + panic("address_limit_check_failed called with a valid user-mode state");
It's very unconstructive to unconditionally panic the system, just because some
kernel code leaked the address limit! Do a warn-once printout and kill the current
task (i.e. don't continue execution), but don't crash everything else!
Thanks,
Ingo
^ permalink raw reply
* [PATCH v7 1/4] syscalls: Restore address limit after a syscall
From: Ingo Molnar @ 2017-04-25 6:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGXu5j+J67zC9tcncacHTDvXKMF3HZuPCivk-Uz4J6h-cEv-qQ@mail.gmail.com>
* Kees Cook <keescook@chromium.org> wrote:
> On Mon, Apr 10, 2017 at 9:44 AM, Thomas Garnier <thgarnie@google.com> wrote:
> > This patch ensures a syscall does not return to user-mode with a kernel
> > address limit. If that happened, a process can corrupt kernel-mode
> > memory and elevate privileges.
> >
> > For example, it would mitigation this bug:
> >
> > - https://bugs.chromium.org/p/project-zero/issues/detail?id=990
> >
> > The CONFIG_ARCH_NO_SYSCALL_VERIFY_PRE_USERMODE_STATE option is also
> > added so each architecture can optimize this change.
> >
> > Signed-off-by: Thomas Garnier <thgarnie@google.com>
> > Tested-by: Kees Cook <keescook@chromium.org>
>
> Ingo, I think this series is ready. Can you pull it? (And if not, what
> should next steps be?)
I have some feedback for other patches in this series, plus for this one as well:
> > +/*
> > + * Called before coming back to user-mode. Returning to user-mode with an
> > + * address limit different than USER_DS can allow to overwrite kernel memory.
> > + */
> > +static inline void verify_pre_usermode_state(void) {
> > + BUG_ON(!segment_eq(get_fs(), USER_DS));
> > +}
That's not standard kernel coding style.
Also, patch titles should start with a verb - 75% of the series doesn't.
> > +#ifndef CONFIG_ARCH_NO_SYSCALL_VERIFY_PRE_USERMODE_STATE
> > +#define __CHECK_USER_CALLER() \
> > + bool user_caller = segment_eq(get_fs(), USER_DS)
> > +#define __VERIFY_PRE_USERMODE_STATE() \
> > + if (user_caller) verify_pre_usermode_state()
> > +#else
> > +#define __CHECK_USER_CALLER()
> > +#define __VERIFY_PRE_USERMODE_STATE()
> > +asmlinkage void address_limit_check_failed(void);
> > +#endif
> > +#ifdef CONFIG_ARCH_NO_SYSCALL_VERIFY_PRE_USERMODE_STATE
That Kconfig name is way too long.
Plus please don't put logical operations into Kconfig names.
> > +/*
> > + * This function is called when an architecture specific implementation detected
> > + * an invalid address limit. The generic user-mode state checker will finish on
> > + * the appropriate BUG_ON.
> > + */
> > +asmlinkage void address_limit_check_failed(void)
> > +{
> > + verify_pre_usermode_state();
> > + panic("address_limit_check_failed called with a valid user-mode state");
> > +}
> > +#endif
Awful naming all around:
verify_pre_usermode_state()
address_limit_check_failed()
Both names start with very common names that makes one read these again and again.
(And yes, there's lots of bad names in the kernel, but we should not follow bad
examples.)
Best practice for such functionality is to use a common prefix that is both easy
to recognize and easy to skip. For example we could use 'addr_limit_check' as the
prefix:
addr_limit_check_failed()
addr_limit_check_syscall()
No need to over-specify it that it's a "pre" check - it's obvious from existing
implementation and should be documented in the function itself for new
implementations.
Harmonize the Kconfig namespace to the common prefix as well, i.e. use something
like:
CONFIG_ADDR_LIMIT_CHECK
No need to add 'ARCH' I think - an architecture that enables this should get it
unconditionally.
etc.
It's all cobbled together I'm afraid and will need more iterations.
Thanks,
Ingo
^ permalink raw reply
* [PATCH] ARM: dts: Add devicetree for the Raspberry Pi 3, for arm32 (v5)
From: Stefan Wahren @ 2017-04-25 6:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170424200037.25615-1-eric@anholt.net>
Am 24.04.2017 um 22:00 schrieb Eric Anholt:
> Raspbian and Fedora have decided to support the Pi3 in 32-bit mode for
> now, so it's useful to be able to test that mode on an upstream
> kernel. It's also been useful for me to use the same board for 32-bit
> and 64-bit development.
>
> Signed-off-by: Eric Anholt <eric@anholt.net>
> ---
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/bcm2837-rpi-3.b.dts | 1 +
> 2 files changed, 2 insertions(+)
> create mode 100644 arch/arm/boot/dts/bcm2837-rpi-3.b.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 011808490fed..eded842d9978 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -72,6 +72,7 @@ dtb-$(CONFIG_ARCH_BCM2835) += \
> bcm2835-rpi-b-plus.dtb \
> bcm2835-rpi-a-plus.dtb \
> bcm2836-rpi-2-b.dtb \
> + bcm2837-rpi-3-b.dtb \
> bcm2835-rpi-zero.dtb
> dtb-$(CONFIG_ARCH_BCM_5301X) += \
> bcm4708-asus-rt-ac56u.dtb \
> diff --git a/arch/arm/boot/dts/bcm2837-rpi-3.b.dts b/arch/arm/boot/dts/bcm2837-rpi-3.b.dts
> new file mode 100644
> index 000000000000..8c8aa4d1e9b3
> --- /dev/null
> +++ b/arch/arm/boot/dts/bcm2837-rpi-3.b.dts
> @@ -0,0 +1 @@
> +#include "arm64/broadcom/bcm2837-rpi-3.b.dts"
Looks like a typo in the dts filename and in the include ( dot instead
of dash ).
^ permalink raw reply
* [PATCH] arm64: Preventing READ_IMPLIES_EXEC propagation
From: dongbo (E) @ 2017-04-25 6:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1493102296-229934-1-git-send-email-zhangshaokun@hisilicon.com>
From: Dong Bo <dongbo4@huawei.com>
Once the READ_IMPLIES_EXEC flag is set on arm64, the flag is
propagated to its child processes, even the ELF files are
marked as not requiring executable stack.
Signed-off-by: Dong Bo <dongbo4@huawei.com>
---
arch/arm64/include/asm/elf.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/include/asm/elf.h b/arch/arm64/include/asm/elf.h
index 5d17004..5941e7f 100644
--- a/arch/arm64/include/asm/elf.h
+++ b/arch/arm64/include/asm/elf.h
@@ -142,6 +142,7 @@
({ \
clear_bit(TIF_32BIT, ¤t->mm->context.flags); \
clear_thread_flag(TIF_32BIT); \
+ current->personality &= ~READ_IMPLIES_EXEC; \
})
/* update AT_VECTOR_SIZE_ARCH if the number of NEW_AUX_ENT entries changes */
--
1.9.1
.
^ permalink raw reply related
* [PATCH] PCI: imx6: fix spelling mistake: "contol" -> "control"
From: Richard Zhu @ 2017-04-25 6:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170421070230.16582-1-colin.king@canonical.com>
> -----Original Message-----
> From: Colin King [mailto:colin.king at canonical.com]
> Sent: Friday, April 21, 2017 3:03 PM
> To: Richard Zhu <hongxing.zhu@nxp.com>; Lucas Stach
> <l.stach@pengutronix.de>; Bjorn Helgaas <bhelgaas@google.com>; linux-
> pci at vger.kernel.org; linux-arm-kernel at lists.infradead.org
> Cc: linux-kernel at vger.kernel.org
> Subject: [PATCH] PCI: imx6: fix spelling mistake: "contol" -> "control"
>
> From: Colin Ian King <colin.king@canonical.com>
>
> trivial fix to spelling mistake in dev_err message
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Acked-by: Richard Zhu <hongxing.Zhu@nxp.com>
Best Regards
hongxing zhu
Email: hongxing.zhu at nxp.com
> ---
> drivers/pci/dwc/pci-imx6.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pci/dwc/pci-imx6.c b/drivers/pci/dwc/pci-imx6.c index
> 102edcf1e261..129717ae5022 100644
> --- a/drivers/pci/dwc/pci-imx6.c
> +++ b/drivers/pci/dwc/pci-imx6.c
> @@ -726,13 +726,13 @@ static int imx6_pcie_probe(struct platform_device
> *pdev)
> imx6_pcie->pciephy_reset = devm_reset_control_get(dev,
> "pciephy");
> if (IS_ERR(imx6_pcie->pciephy_reset)) {
> - dev_err(dev, "Failed to get PCIEPHY reset contol\n");
> + dev_err(dev, "Failed to get PCIEPHY reset control\n");
> return PTR_ERR(imx6_pcie->pciephy_reset);
> }
>
> imx6_pcie->apps_reset = devm_reset_control_get(dev,
> "apps");
> if (IS_ERR(imx6_pcie->apps_reset)) {
> - dev_err(dev, "Failed to get PCIE APPS reset
> contol\n");
> + dev_err(dev, "Failed to get PCIE APPS reset
> control\n");
> return PTR_ERR(imx6_pcie->apps_reset);
> }
> break;
> --
> 2.11.0
^ permalink raw reply
* [linux-sunxi] [PATCH v4 07/10] mfd: axp20x: add axp20x-regulator cell for AXP803
From: icenowy at aosc.io @ 2017-04-25 5:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v673CL6TaZxkNR9SZDiG5G3cMqU1-=XeMj5gyDbQq4YzVA@mail.gmail.com>
? 2017-04-25 10:17?Chen-Yu Tsai ???
> On Tue, Apr 25, 2017 at 12:01 AM, Icenowy Zheng <icenowy@aosc.io>
> wrote:
>> As axp20x-regulator now supports AXP803, add a cell for it.
>>
>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
>> Acked-by: Chen-Yu Tsai <wens@csie.org>
>> ---
>> Changes in v4:
>> - Added a trailing comma for new cell, for easier further cell
>> addition.
>> Changes in v3:
>> - Make the new cell one-liner.
>>
>> drivers/mfd/axp20x.c | 3 ++-
>> drivers/regulator/axp20x-regulator.c | 6 +++---
>
> Squashed in wrong patch?
Oh seems so...
>
> ChenYu
^ permalink raw reply
* Touchscreen failure with CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND
From: Viresh Kumar @ 2017-04-25 5:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5AkTKjU5kw0gszLVdVOc_Sb_sWhr65heE==kyw=5rcN-g@mail.gmail.com>
On 24-04-17, 08:51, Fabio Estevam wrote:
> On Mon, Apr 24, 2017 at 8:43 AM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
>
> > 110 ms is your sampling rate right now. Looks too high.
> >
> > Try doing this:
> >
> > echo 10000 > /sys/devices/system/cpu/cpufreq/ondemand/sampling_rate
> >
> > and retry your tests.
>
> Tried 10ms and also 1ms, but touchscreen also failed in both cases.
Honestly, I don't have a clue on how can we fix it for you now :)
@Rafael: Any idea apart from running at max all the time?
what touchscreen driver are you using btw? Just curious to see if there is any
bug in there. Handling touchscreen events shouldn't require us to run at max
freq.
@shawn: Saw something similar ever ?
--
viresh
^ permalink raw reply
* [PATCH] ARM: dts: Add devicetree for the Raspberry Pi 3, for arm32 (v5)
From: Florian Fainelli @ 2017-04-25 4:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170424200037.25615-1-eric@anholt.net>
On 04/24/2017 01:00 PM, Eric Anholt wrote:
> Raspbian and Fedora have decided to support the Pi3 in 32-bit mode for
> now, so it's useful to be able to test that mode on an upstream
> kernel. It's also been useful for me to use the same board for 32-bit
> and 64-bit development.
>
> Signed-off-by: Eric Anholt <eric@anholt.net>
> ---
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/bcm2837-rpi-3.b.dts | 1 +
> 2 files changed, 2 insertions(+)
> create mode 100644 arch/arm/boot/dts/bcm2837-rpi-3.b.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 011808490fed..eded842d9978 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -72,6 +72,7 @@ dtb-$(CONFIG_ARCH_BCM2835) += \
> bcm2835-rpi-b-plus.dtb \
> bcm2835-rpi-a-plus.dtb \
> bcm2836-rpi-2-b.dtb \
> + bcm2837-rpi-3-b.dtb \
> bcm2835-rpi-zero.dtb
> dtb-$(CONFIG_ARCH_BCM_5301X) += \
> bcm4708-asus-rt-ac56u.dtb \
> diff --git a/arch/arm/boot/dts/bcm2837-rpi-3.b.dts b/arch/arm/boot/dts/bcm2837-rpi-3.b.dts
> new file mode 100644
> index 000000000000..8c8aa4d1e9b3
> --- /dev/null
> +++ b/arch/arm/boot/dts/bcm2837-rpi-3.b.dts
> @@ -0,0 +1 @@
> +#include "arm64/broadcom/bcm2837-rpi-3.b.dts"
Sounds like this should be
../arm64/boot/dts/broadcom/bcm2837-rpi-3.b.dts are reported by the
kbuild test robot?
--
Florian
^ permalink raw reply
* [PATCH 1/3 v2] xen: Export xen_reboot
From: Juergen Gross @ 2017-04-25 4:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <41fd4caf-7554-7d54-6332-d227228a13ea@oracle.com>
On 24/04/17 20:21, Boris Ostrovsky wrote:
> On 04/24/2017 01:58 PM, Julien Grall wrote:
>> The helper xen_reboot will be called by the EFI code in a later patch.
>>
>> Note that the ARM version does not yet exist and will be added in a
>> later patch too.
>>
>> Signed-off-by: Julien Grall <julien.grall@arm.com>
>
> I don't think these changes are worth a whole patch. They can be folded
> into the third patch.
No, the 2nd patch needs this, too.
So:
Reviewed-by: Juergen Gross <jgross@suse.com>
Thanks, Juergen
^ permalink raw reply
* [PATCH] ARM: dts: Add devicetree for the Raspberry Pi 3, for arm32 (v5)
From: kbuild test robot @ 2017-04-25 3:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170424200037.25615-1-eric@anholt.net>
Hi Eric,
[auto build test ERROR on robh/for-next]
[also build test ERROR on v4.11-rc8 next-20170424]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Eric-Anholt/ARM-dts-Add-devicetree-for-the-Raspberry-Pi-3-for-arm32-v5/20170425-063618
base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
config: arm-at91_dt_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm
All errors (new ones prefixed by >>):
>> arch/arm/boot/dts/bcm2837-rpi-3.b.dts:1:46: fatal error: arm64/broadcom/bcm2837-rpi-3.b.dts: No such file or directory
#include "arm64/broadcom/bcm2837-rpi-3.b.dts"
^
compilation terminated.
vim +1 arch/arm/boot/dts/bcm2837-rpi-3.b.dts
> 1 #include "arm64/broadcom/bcm2837-rpi-3.b.dts"
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 22403 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170425/f816bce5/attachment-0001.gz>
^ permalink raw reply
* [PATCH v2] arm64: perf: Use only exclude_kernel attribute when kernel is running in HYP
From: Ganapatrao Kulkarni @ 2017-04-25 3:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170424154530.GO12323@arm.com>
On Mon, Apr 24, 2017 at 9:15 PM, Will Deacon <will.deacon@arm.com> wrote:
> On Thu, Apr 20, 2017 at 02:56:50PM +0530, Ganapatrao Kulkarni wrote:
>> On Thu, Apr 20, 2017 at 2:19 PM, Mark Rutland <mark.rutland@arm.com> wrote:
>> > On Wed, Apr 19, 2017 at 11:14:06PM +0530, Ganapatrao Kulkarni wrote:
>> >> commit d98ecda (arm64: perf: Count EL2 events if the kernel is running in HYP)
>> >> is returning error for perf syscall with mixed attribute set for exclude_kernel
>> >> and exclude_hv. This change is breaking some applications (observed with hhvm)
>> >> when ran on VHE enabled platforms.
>> >>
>> >> Adding fix to consider only exclude_kernel attribute when kernel is
>> >> running in HYP. Also adding sysfs file to notify the bhehaviour
>> >> of attribute exclude_hv.
>> >>
>> >> Signed-off-by: Ganapatrao Kulkarni <ganapatrao.kulkarni@cavium.com>
>> >> ---
>> >>
>> >> Changelog:
>> >>
>> >> V2:
>> >> - Changes as per Will Deacon's suggestion.
>> >>
>> >> V1: Initial patch
>> >>
>> >> arch/arm64/kernel/perf_event.c | 28 ++++++++++++++++++++++++----
>> >> include/linux/perf/arm_pmu.h | 1 +
>> >> 2 files changed, 25 insertions(+), 4 deletions(-)
>> >>
>> >> @@ -871,14 +890,13 @@ static int armv8pmu_set_event_filter(struct hw_perf_event *event,
>> >>
>> >> if (attr->exclude_idle)
>> >> return -EPERM;
>> >> - if (is_kernel_in_hyp_mode() &&
>> >> - attr->exclude_kernel != attr->exclude_hv)
>> >> - return -EINVAL;
>> >> + if (is_kernel_in_hyp_mode() && !attr->exclude_kernel)
>> >> + config_base |= ARMV8_PMU_INCLUDE_EL2;
>> >> if (attr->exclude_user)
>> >> config_base |= ARMV8_PMU_EXCLUDE_EL0;
>> >> if (!is_kernel_in_hyp_mode() && attr->exclude_kernel)
>> >> config_base |= ARMV8_PMU_EXCLUDE_EL1;
>> >> - if (!attr->exclude_hv)
>> >> + if (!is_kernel_in_hyp_mode() && !attr->exclude_hv)
>> >> config_base |= ARMV8_PMU_INCLUDE_EL2;
>> >
>> > This isn't quite what Will suggested.
>> >
>> > The idea was that userspace would read sysfs, then use that to determine
>> > the correct exclusion parameters [1,2]. This logic was not expected to
>> > change; it correctly validates whether we can provide what the user
>> > requests.
>>
>> OK, if you are ok with sysfs part, i can send next version with that
>> change only?.
>
> I think the sysfs part is still a little dodgy, since you still expose the
> "exclude_hv" file with a value of 0 when not running at EL2, which would
> imply that exclude_hv is forced to zero. I don't think that's correct.
okay, i can make exclude_hv visible only when kernel booted in EL2.
is it ok to have empty directory "attr" when kernel booted to EL1?
attr can be place holder for any other miscellaneous attributes, that
can be added in future.
>
> Will
thanks
Ganapat
^ permalink raw reply
* [PATCH -next] drm/rockchip: cdn-dp: fix return value check in cdn_dp_probe()
From: Wei Yongjun @ 2017-04-25 3:16 UTC (permalink / raw)
To: linux-arm-kernel
From: Wei Yongjun <weiyongjun1@huawei.com>
Fix the retrn value check which testing the wrong variable
in cdn_dp_probe().
Fixes: 1a0f7ed3abe2 ("drm/rockchip: cdn-dp: add cdn DP support for rk3399")
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
---
drivers/gpu/drm/rockchip/cdn-dp-core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c b/drivers/gpu/drm/rockchip/cdn-dp-core.c
index 9ab67a6..6a4a113 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-core.c
+++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
@@ -1198,7 +1198,7 @@ static int cdn_dp_probe(struct platform_device *pdev)
continue;
port = devm_kzalloc(dev, sizeof(*port), GFP_KERNEL);
- if (!dp)
+ if (!port)
return -ENOMEM;
port->extcon = extcon;
^ permalink raw reply related
* [linux-sunxi] [PATCH v4 07/10] mfd: axp20x: add axp20x-regulator cell for AXP803
From: Chen-Yu Tsai @ 2017-04-25 2:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170424160103.9447-8-icenowy@aosc.io>
On Tue, Apr 25, 2017 at 12:01 AM, Icenowy Zheng <icenowy@aosc.io> wrote:
> As axp20x-regulator now supports AXP803, add a cell for it.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> Acked-by: Chen-Yu Tsai <wens@csie.org>
> ---
> Changes in v4:
> - Added a trailing comma for new cell, for easier further cell addition.
> Changes in v3:
> - Make the new cell one-liner.
>
> drivers/mfd/axp20x.c | 3 ++-
> drivers/regulator/axp20x-regulator.c | 6 +++---
Squashed in wrong patch?
ChenYu
^ permalink raw reply
* [PATCH] irqchip/mbigen: Fix the clear register offset
From: Majun @ 2017-04-25 2:16 UTC (permalink / raw)
To: linux-arm-kernel
From: MaJun <majun258@huawei.com>
Don't minus reserved interrupts (64) when get the clear register offset,because
the clear register space includes the space of these 64 interrupts.
Signed-off-by: MaJun <majun258@huawei.com>
---
drivers/irqchip/irq-mbigen.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/irqchip/irq-mbigen.c b/drivers/irqchip/irq-mbigen.c
index 061cdb8..75818a5 100644
--- a/drivers/irqchip/irq-mbigen.c
+++ b/drivers/irqchip/irq-mbigen.c
@@ -108,7 +108,6 @@ static inline void get_mbigen_clear_reg(irq_hw_number_t hwirq,
{
unsigned int ofst;
- hwirq -= RESERVED_IRQ_PER_MBIGEN_CHIP;
ofst = hwirq / 32 * 4;
*mask = 1 << (hwirq % 32);
--
1.7.12.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox