* [PATCH V2] gpu/drm/exynos/exynos_hdmi - Unmap region obtained by of_iomap
From: Inki Dae @ 2016-10-19 14:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476871456-1098-1-git-send-email-arvind.yadav.cs@gmail.com>
Will pick it up soon.
Thanks,
Inki Dae
2016-10-19 19:04 GMT+09:00 Arvind Yadav <arvind.yadav.cs@gmail.com>:
> Free memory mapping, if hdmi_probe is not successful.
>
> Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
> ---
> drivers/gpu/drm/exynos/exynos_hdmi.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c b/drivers/gpu/drm/exynos/exynos_hdmi.c
> index 2275efe..ba28dec 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> @@ -1901,6 +1901,8 @@ err_disable_pm_runtime:
> err_hdmiphy:
> if (hdata->hdmiphy_port)
> put_device(&hdata->hdmiphy_port->dev);
> + if (hdata->regs_hdmiphy)
> + iounmap(hdata->regs_hdmiphy);
> err_ddc:
> put_device(&hdata->ddc_adpt->dev);
>
> @@ -1923,6 +1925,9 @@ static int hdmi_remove(struct platform_device *pdev)
> if (hdata->hdmiphy_port)
> put_device(&hdata->hdmiphy_port->dev);
>
> + if (hdata->regs_hdmiphy)
> + iounmap(hdata->regs_hdmiphy);
> +
> put_device(&hdata->ddc_adpt->dev);
>
> return 0;
> --
> 1.7.9.5
>
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* [PATCH] exynos-drm: Fix display manager failing to start without IOMMU problem
From: Inki Dae @ 2016-10-19 14:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ce7a035c-f881-82ac-97f6-869442d1ed47@osg.samsung.com>
Hi Shuah,
2016-10-13 8:11 GMT+09:00 Shuah Khan <shuahkh@osg.samsung.com>:
> Hi Inki,
>
> On 08/15/2016 10:40 PM, Inki Dae wrote:
>
>>>
>>> okay the very first commit that added IOMMU support
>>> introduced the code that rejects non-contig gem memory
>>> type without IOMMU.
>>>
>>> commit 0519f9a12d0113caab78980c48a7902d2bd40c2c
>>> Author: Inki Dae <inki.dae@samsung.com>
>>> Date: Sat Oct 20 07:53:42 2012 -0700
>>>
>>> drm/exynos: add iommu support for exynos drm framework
>>>
>
> I haven't given up on this yet. I am still seeing the following failure:
>
> Additional debug messages I added:
> [ 15.287403] exynos_drm_gem_create_ioctl() 1
> [ 15.287419] exynos_drm_gem_create() flags 1
>
> [ 15.311511] [drm:exynos_drm_framebuffer_init] *ERROR* Non-contiguous GEM memory is not supported.
>
> Additional debug message I added:
> [ 15.318981] [drm:exynos_user_fb_create] *ERROR* failed to initialize framebuffer
>
> This is what happens:
>
> 1. exynos_drm_gem_create_ioctl() gets called with EXYNOS_BO_NONCONTIG request
> 2. exynos_drm_gem_create(0 goes ahead and creates the GEM buffers
> 3. exynos_user_fb_create() tries to associate GEM to fb and fails during
> check_fb_gem_memory_type()
>
> At this point, there is no recovery and lightdm fails
>
> xf86-video-armsoc/src/drmmode_exynos/drmmode_exynos.c assumes contiguous
> allocations are not supported in some exynos drm versions: The following
> commit introduced this change:
>
> https://git.linaro.org/arm/xorg/driver/xf86-video-armsoc.git/commitdiff/3be1f6273441fe95dd442f44064387322e16b7e9
>
> excerpts from the diff:- if (create_gem->buf_type == ARMSOC_BO_SCANOUT)
> - create_exynos.flags = EXYNOS_BO_CONTIG;
> - else
> - create_exynos.flags = EXYNOS_BO_NONCONTIG;
> +
> + /* Contiguous allocations are not supported in some exynos drm versions.
> + * When they are supported all allocations are effectively contiguous
> + * anyway, so for simplicity we always request non contiguous buffers.
> + */
> + create_exynos.flags = EXYNOS_BO_NONCONTIG;
>
Above comment, "Contiguous allocations are not supported in some
exynos drm versions.", seems wrong assumption.
The root cause, contiguous allocation is not supported, would be that
they used Linux kernel which didn't have CMA region enough - as
default 16MB, or didn't declare CMA region enough for the DMA device.
So I think they should not force to flag EXYNOS_BO_NONCONTIG and they
should manage the error case if the allocation failed.
> There might have been logic on exynos_drm that forced Contig when it coudn't
> support NONCONTIG. At least, that is what this comment suggests. This assumption
> doesn't appear to be a good one and not sure if this change was made to fix a bug.
>
> After the IOMMU support, this assumption is no longer true. Hence, with IOMMU
> support, latest kernels have a mismatch with the installed xf86-video-armsoc
>
> This is what I am running into. This leads to the following question:
>
> 1. How do we ensure exynos_drm kernel changes don't break user-space
> specifically xf86-video-armsoc
> 2. This seems to have gone undetected for a while. I see a change in
> exynos_drm_gem_dumb_create() that is probably addressing this type
> of breakage. Commit 122beea84bb90236b1ae545f08267af58591c21b adds
> handling for IOMMU NONCONTIG case.
Seems this patch has a problem. This patch forces to flag NONCONTIG if
iommu is enabled. The flag should be depend on the argument from
user-space.
I.e., if user-space requested a gem allocation with CONTIG flag, then
Exynos drm driver should allocate contiguous memory even though iommu
is enabled.
>
> Anyway, I am interested in getting the exynos_drm kernel side code
> and xf86-video-armsoc in sync to resolve the issue.
>
> Could you recommend a going forward plan?
My opinion are,
1. Do not force to flag EXYNOS_BO_NONCONTIG at xf86-video-armsoc
2. Do not force to flag NONCONTIG at Exynos drm driver even though
iommu is enabled and flag allocation type with the argument from
user-space.
I think you could try to post above patches.
Thanks,
Inki Dae
>
> I can submit a patch to xf86-video-armsoc. I am also looking ahead to
> see if we can avoid such breaks in the future by keeping kernel and
> xf86-video-armsoc in sync.
>
> thanks,
> -- Shuah
> --
> 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: imx: gpc: Initialize all power domains
From: Shawn Guo @ 2016-10-19 14:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476208413-11286-1-git-send-email-fabio.estevam@nxp.com>
On Tue, Oct 11, 2016 at 02:53:33PM -0300, Fabio Estevam wrote:
> When booting a kernel built with multi_v7_defconfig the following
> probe error is seen:
>
> imx-gpc: probe of 20dc000.gpc failed with error -22
>
> Later on the kernel crashes like this:
>
> [ 1.723358] Unable to handle kernel NULL pointer dereference at virtual address 00000040
> [ 1.731500] pgd = c0204000
> [ 1.731863] hctosys: unable to open rtc device (rtc0)
> [ 1.739301] [00000040] *pgd=00000000
> [ 1.739310] Internal error: Oops: 5 [#1] SMP ARM
> [ 1.739319] Modules linked in:
> [ 1.739328] CPU: 1 PID: 95 Comm: kworker/1:4 Not tainted 4.8.0-11897-g6b5e09a #1
> [ 1.739331] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
> [ 1.739352] Workqueue: pm genpd_power_off_work_fn
> [ 1.739356] task: ee63d400 task.stack: ee70a000
> [ 1.739365] PC is at mutex_lock+0xc/0x4c
> [ 1.739374] LR is at regulator_disable+0x2c/0x60
> [ 1.739379] pc : [<c0bc0da0>] lr : [<c06e4b10>] psr: 60000013
> [ 1.739379] sp : ee70beb0 ip : 10624dd3 fp : ee6e6280
> [ 1.739382] r10: eefb0900 r9 : 00000000 r8 : c1309918
> [ 1.739385] r7 : 00000000 r6 : 00000040 r5 : 00000000 r4 : 00000040
> [ 1.739390] r3 : 0000004c r2 : 7fffd540 r1 : 000001e4 r0 : 00000040
>
> The gpc probe fails because of_genpd_add_provider_onecell() checks
> if all the domains are initialized via pm_genpd_present() function
> and it returns an error on the multi_v7_defconfig case.
It's not clear to me why this is only with multi_v7_defconfig, not
imx_v6_v7_defconfig. Also, is it a regression or long-standing issue?
Shawn
>
> In order to fix this error, initialize all the imx_gpc_domains, not
> only the imx6q_pu_domain.base one.
>
> Reported-by: Olof's autobooter <build@lixom.net>
> Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
> ---
> arch/arm/mach-imx/gpc.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-imx/gpc.c b/arch/arm/mach-imx/gpc.c
> index 0df062d..d0463e9 100644
> --- a/arch/arm/mach-imx/gpc.c
> +++ b/arch/arm/mach-imx/gpc.c
> @@ -430,7 +430,8 @@ static int imx_gpc_genpd_init(struct device *dev, struct regulator *pu_reg)
> if (!IS_ENABLED(CONFIG_PM_GENERIC_DOMAINS))
> return 0;
>
> - pm_genpd_init(&imx6q_pu_domain.base, NULL, false);
> + for (i = 0; i < ARRAY_SIZE(imx_gpc_domains); i++)
> + pm_genpd_init(imx_gpc_domains[i], NULL, false);
> return of_genpd_add_provider_onecell(dev->of_node,
> &imx_gpc_onecell_data);
>
> --
> 2.7.4
>
>
> _______________________________________________
> 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 0/2] ARM: at91: properly handle LPDDR poweroff
From: Geert Uytterhoeven @ 2016-10-19 14:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161019114420.15213-1-alexandre.belloni@free-electrons.com>
On Wed, Oct 19, 2016 at 1:44 PM, Alexandre Belloni
<alexandre.belloni@free-electrons.com> wrote:
> LPDDR memories can only handle up to 400 uncontrolled power offs in their
> life. The proper power off sequence has to be applied before shutting down the
> SoC.
Interesting. How many boards have been killed during kernelci.org
operation?
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 1/2] arm64: swp emulation: bound LL/SC retries before rescheduling
From: Mark Rutland @ 2016-10-19 14:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476874784-16214-1-git-send-email-will.deacon@arm.com>
On Wed, Oct 19, 2016 at 11:59:43AM +0100, Will Deacon wrote:
> If a CPU does not implement a global monitor for certain memory types,
> then userspace can attempt a kernel DoS by issuing SWP instructions
> targetting the problematic memory (for example, a framebuffer mapped
> with non-cacheable attributes).
>
> The SWP emulation code protects against these sorts of attacks by
> checking for pending signals and potentially rescheduling when the STXR
> instruction fails during the emulation. Whilst this is good for avoiding
> livelock, it harms emulation of legitimate SWP instructions on CPUs
> where forward progress is not guaranteed if there are memory accesses to
> the same reservation granule (up to 2k) between the failing STXR and
> the retry of the LDXR.
>
> This patch solves the problem by retrying the STXR a bounded number of
> times (4) before breaking out of the LL/SC loop and looking for
> something else to do.
>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
Assuming I've followed all the operand numbering correctly, this looks
correct to me per my reading of the requirements in the ARM ARM.
FWIW:
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Thanks,
Mark.
> ---
> arch/arm64/kernel/armv8_deprecated.c | 36 ++++++++++++++++++++++--------------
> 1 file changed, 22 insertions(+), 14 deletions(-)
>
> diff --git a/arch/arm64/kernel/armv8_deprecated.c b/arch/arm64/kernel/armv8_deprecated.c
> index 42ffdb54e162..b0988bb1bf64 100644
> --- a/arch/arm64/kernel/armv8_deprecated.c
> +++ b/arch/arm64/kernel/armv8_deprecated.c
> @@ -280,35 +280,43 @@ static void __init register_insn_emulation_sysctl(struct ctl_table *table)
> /*
> * Error-checking SWP macros implemented using ldxr{b}/stxr{b}
> */
> -#define __user_swpX_asm(data, addr, res, temp, B) \
> +
> +/* Arbitrary constant to ensure forward-progress of the LL/SC loop */
> +#define __SWP_LL_SC_LOOPS 4
> +
> +#define __user_swpX_asm(data, addr, res, temp, temp2, B) \
> __asm__ __volatile__( \
> + " mov %w3, %w7\n" \
> ALTERNATIVE("nop", SET_PSTATE_PAN(0), ARM64_HAS_PAN, \
> CONFIG_ARM64_PAN) \
> - "0: ldxr"B" %w2, [%3]\n" \
> - "1: stxr"B" %w0, %w1, [%3]\n" \
> + "0: ldxr"B" %w2, [%4]\n" \
> + "1: stxr"B" %w0, %w1, [%4]\n" \
> " cbz %w0, 2f\n" \
> - " mov %w0, %w4\n" \
> + " sub %w3, %w3, #1\n" \
> + " cbnz %w3, 0b\n" \
> + " mov %w0, %w5\n" \
> " b 3f\n" \
> "2:\n" \
> " mov %w1, %w2\n" \
> "3:\n" \
> " .pushsection .fixup,\"ax\"\n" \
> " .align 2\n" \
> - "4: mov %w0, %w5\n" \
> + "4: mov %w0, %w6\n" \
> " b 3b\n" \
> " .popsection" \
> _ASM_EXTABLE(0b, 4b) \
> _ASM_EXTABLE(1b, 4b) \
> ALTERNATIVE("nop", SET_PSTATE_PAN(1), ARM64_HAS_PAN, \
> CONFIG_ARM64_PAN) \
> - : "=&r" (res), "+r" (data), "=&r" (temp) \
> - : "r" (addr), "i" (-EAGAIN), "i" (-EFAULT) \
> + : "=&r" (res), "+r" (data), "=&r" (temp), "=&r" (temp2) \
> + : "r" (addr), "i" (-EAGAIN), "i" (-EFAULT), \
> + "i" (__SWP_LL_SC_LOOPS) \
> : "memory")
>
> -#define __user_swp_asm(data, addr, res, temp) \
> - __user_swpX_asm(data, addr, res, temp, "")
> -#define __user_swpb_asm(data, addr, res, temp) \
> - __user_swpX_asm(data, addr, res, temp, "b")
> +#define __user_swp_asm(data, addr, res, temp, temp2) \
> + __user_swpX_asm(data, addr, res, temp, temp2, "")
> +#define __user_swpb_asm(data, addr, res, temp, temp2) \
> + __user_swpX_asm(data, addr, res, temp, temp2, "b")
>
> /*
> * Bit 22 of the instruction encoding distinguishes between
> @@ -328,12 +336,12 @@ static int emulate_swpX(unsigned int address, unsigned int *data,
> }
>
> while (1) {
> - unsigned long temp;
> + unsigned long temp, temp2;
>
> if (type == TYPE_SWPB)
> - __user_swpb_asm(*data, address, res, temp);
> + __user_swpb_asm(*data, address, res, temp, temp2);
> else
> - __user_swp_asm(*data, address, res, temp);
> + __user_swp_asm(*data, address, res, temp, temp2);
>
> if (likely(res != -EAGAIN) || signal_pending(current))
> break;
> --
> 2.1.4
>
>
> _______________________________________________
> 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 1/2] iommu/dma: Implement dma_{map,unmap}_resource()
From: Will Deacon @ 2016-10-19 14:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b6c78e6c18d98069b0fdfa219da51d2aed129aed.1476705500.git.robin.murphy@arm.com>
On Mon, Oct 17, 2016 at 01:05:29PM +0100, Robin Murphy wrote:
> With the new dma_{map,unmap}_resource() functions added to the DMA API
> for the benefit of cases like slave DMA, add suitable implementations to
> the arsenal of our generic layer. Since cache maintenance should not be
> a concern, these can both be standalone versions without the need for
> architecture-specific wrappers.
>
> CC: Joerg Roedel <joro@8bytes.org>
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> ---
>
> Since patch 2 has a build dependency on this one, they should probably
> go together through either the arm64 tree or the iommu tree, but I can't
> make up my mind which one seems more appropriate...
I can take it via the smmu tree, if you like. However, comment below.
> drivers/iommu/dma-iommu.c | 13 +++++++++++++
> include/linux/dma-iommu.h | 4 ++++
> 2 files changed, 17 insertions(+)
>
> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
> index c5ab8667e6f2..50acd71915db 100644
> --- a/drivers/iommu/dma-iommu.c
> +++ b/drivers/iommu/dma-iommu.c
> @@ -624,6 +624,19 @@ void iommu_dma_unmap_sg(struct device *dev, struct scatterlist *sg, int nents,
> __iommu_dma_unmap(iommu_get_domain_for_dev(dev), sg_dma_address(sg));
> }
>
> +dma_addr_t iommu_dma_map_resource(struct device *dev, phys_addr_t phys,
> + size_t size, enum dma_data_direction dir, unsigned long attrs)
> +{
> + return iommu_dma_map_page(dev, phys_to_page(phys), offset_in_page(phys),
> + size, dma_direction_to_prot(dir, false) | IOMMU_MMIO);
> +}
>
> +void iommu_dma_unmap_resource(struct device *dev, dma_addr_t handle,
> + size_t size, enum dma_data_direction dir, unsigned long attrs)
> +{
> + __iommu_dma_unmap(iommu_get_domain_for_dev(dev), handle);
> +}
I think it's better to call iommu_dma_unmap_page instead. That said, are
you sure it's safe to ignore the "size" parameter here? Is it permitted
to unmap part of a region? If not, why does that parameter exist?
Will
^ permalink raw reply
* [PATCH 2/3] arm64: dts: uniphier: add CPU clock and OPP table for LD11 SoC
From: Viresh Kumar @ 2016-10-19 13:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK7LNATc2XxAZf-rvMkRjGn3q_18yB=9aycAE1j9+n0==xzaHQ@mail.gmail.com>
On 19-10-16, 17:33, Masahiro Yamada wrote:
> Hi Viresh,
>
>
> 2016-10-18 20:25 GMT+09:00 Viresh Kumar <viresh.kumar@linaro.org>:
> > On 16-10-16, 23:59, Masahiro Yamada wrote:
> >> + cluster0_opp: opp_table {
> >> + compatible = "operating-points-v2";
> >> + opp-shared;
> >> +
> >> + opp at 245000000 {
> >> + opp-hz = /bits/ 64 <245000000>;
> >> + clock-latency-ns = <300>;
> >> + };
> >> + opp at 250000000 {
> >> + opp-hz = /bits/ 64 <250000000>;
> >> + clock-latency-ns = <300>;
> >> + };
> >> + opp at 490000000 {
> >> + opp-hz = /bits/ 64 <490000000>;
> >> + clock-latency-ns = <300>;
> >> + };
> >> + opp at 500000000 {
> >> + opp-hz = /bits/ 64 <500000000>;
> >> + clock-latency-ns = <300>;
> >> + };
> >> + opp at 653333333 {
> >
> > Why isn't ^^ matching with below values ? Same in next patch as well.
>
>
>
> When I try to update /sys/devices/system/cpu/cpufreq/policy*/scaling_max_freq,
> it did not work as I had expected.
>
>
> scaling_max_freq is specified by kHz unit,
> on the other hand, clock frequency in the clk driver is specified by Hz.
>
>
>
> If the operating point is 653333kHz, the cpufreq requests
> the clk driver to set 653333000, but it is lower than
> the exact clock, 653333333.
> So, the next lower frequency, 500000000 is selected.
> As a result, the operating point 653333kHz is never enabled.
>
>
> So, the operating point must be equal or a little bit bigger.
>
>
> Do you know a better way to solve this distortion?
I am not sure about how to fix that problem but there is no reason to
have the exact frequency in opp@*** name. Just use what you have used
in opp-hz line and you will have the exact same behavior.
Right now, its a bit confusing if we read the DT.
--
viresh
^ permalink raw reply
* [PATCH v2 1/4] cpufreq: pxa: use generic platdev driver for device-tree
From: Viresh Kumar @ 2016-10-19 13:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87r37d4qlw.fsf@belgarion.home>
On 18-10-16, 17:35, Robert Jarzmik wrote:
> Viresh Kumar <viresh.kumar@linaro.org> writes:
>
> > On 15-10-16, 21:57, Robert Jarzmik wrote:
> >> For device-tree based pxa25x and pxa27x platforms, cpufreq-dt driver is
> >> doing the job as well as pxa2xx-cpufreq, so add these platforms to the
> >> compatibility list.
> >>
> >> This won't work for legacy non device-tree platforms where
> >> pxa2xx-cpufreq is still required.
> >>
> >> Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
> >> ---
> >> drivers/cpufreq/cpufreq-dt-platdev.c | 2 ++
> >> 1 file changed, 2 insertions(+)
> >>
> >> diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c b/drivers/cpufreq/cpufreq-dt-platdev.c
> >> index 0bb44d5b5df4..356825b5c9b8 100644
> >> --- a/drivers/cpufreq/cpufreq-dt-platdev.c
> >> +++ b/drivers/cpufreq/cpufreq-dt-platdev.c
> >> @@ -32,6 +32,8 @@ static const struct of_device_id machines[] __initconst = {
> >> { .compatible = "fsl,imx7d", },
> >>
> >> { .compatible = "marvell,berlin", },
> >> + { .compatible = "marvell,pxa250", },
> >> + { .compatible = "marvell,pxa270", },
> >>
> >> { .compatible = "samsung,exynos3250", },
> >> { .compatible = "samsung,exynos4210", },
> >
> > Isn't there a race between cpufreq-dt and the platform driver to
> > register first ?
> Ah, could you be more specific about the race you're talking of ?
>
> My understanding was that cpufreq-dt-platdev does create the device, and
> cpufreq-dt is a driver for it, so there is no race but a direct relationship
> AFAIU.
I mean that both the driver may try to register to the cpufreq core if
they are both compiled in a single image.
--
viresh
^ permalink raw reply
* [PATCH v2 2/4] ARM: dts: pxa: add pxa25x cpu operating points
From: Viresh Kumar @ 2016-10-19 13:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87vawp4qv0.fsf@belgarion.home>
On 18-10-16, 17:30, Robert Jarzmik wrote:
> Viresh Kumar <viresh.kumar@linaro.org> writes:
>
> > On 15-10-16, 21:57, Robert Jarzmik wrote:
> >> Add the relevant data taken from the PXA 25x Electrical, Mechanical, and
> >> Thermal Specfication. This will be input data for cpufreq-dt driver.
> >>
> >> Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
> >> ---
> >> arch/arm/boot/dts/pxa25x.dtsi | 25 +++++++++++++++++++++++++
> >> 1 file changed, 25 insertions(+)
> >>
> >> diff --git a/arch/arm/boot/dts/pxa25x.dtsi b/arch/arm/boot/dts/pxa25x.dtsi
> >> index 0d1e012178c4..16b4e8bad4a5 100644
> >> --- a/arch/arm/boot/dts/pxa25x.dtsi
> >> +++ b/arch/arm/boot/dts/pxa25x.dtsi
> >> @@ -89,4 +89,29 @@
> >> clocks = <&clktimer>;
> >> status = "okay";
> >> };
> >> +
> >> + pxa250_opp_table: opp_table0 {
> >> + compatible = "operating-points-v2";
> >> +
> >> + opp at 99500 {
> >
> > We have been keeping the values in ^^^ same as the values present
> > below. Any specific reason for making it different here ?
> No, that's a good comment, I'll change that.
>
> I wrote this incrementaly, first the node, then the opp-hz. Then I realized that
> the source crystal, at 3.8684 MHz didn't provide a round 99.5 MHz core clock,
> but a 99.5328 MHz clock.
>
> Anyway, I'll change that ... let's say into opp at 99533 in this case ?
Just write the whole value 99532800.
--
viresh
^ permalink raw reply
* [PATCH] ARM: dts: sun8i: Add SPI controller node in H3
From: Milo Kim @ 2016-10-19 13:46 UTC (permalink / raw)
To: linux-arm-kernel
H3 supports two SPI controllers. Four pins (MOSI, MISO, SCLK, SS) are
configured through the pinctrl subsystem. It is almost same as A31 SPI
except buffer size, so those DT properties are reusable.
Cc: Maxime Ripard <maxime.ripard@free-electrons.com>
Cc: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Milo Kim <woogyom.kim@gmail.com>
---
arch/arm/boot/dts/sun8i-h3.dtsi | 46 +++++++++++++++++++++++++++++++++++++++++
1 file changed, 46 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
index 75a8654..c38b028 100644
--- a/arch/arm/boot/dts/sun8i-h3.dtsi
+++ b/arch/arm/boot/dts/sun8i-h3.dtsi
@@ -381,6 +381,20 @@
allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
};
+ spi0_pins: spi0 {
+ allwinner,pins = "PC0", "PC1", "PC2", "PC3";
+ allwinner,function = "spi0";
+ allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+ allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+ };
+
+ spi1_pins: spi1 {
+ allwinner,pins = "PA15", "PA16", "PA14", "PA13";
+ allwinner,function = "spi1";
+ allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+ allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+ };
+
uart0_pins_a: uart0 at 0 {
allwinner,pins = "PA4", "PA5";
allwinner,function = "uart0";
@@ -425,6 +439,38 @@
clocks = <&osc24M>;
};
+ spi0: spi at 01c68000 {
+ compatible = "allwinner,sun8i-h3-spi";
+ reg = <0x01c68000 0x1000>;
+ interrupts = <GIC_SPI 65 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_SPI0>, <&ccu CLK_SPI0>;
+ clock-names = "ahb", "mod";
+ dmas = <&dma 23>, <&dma 23>;
+ dma-names = "rx", "tx";
+ pinctrl-names = "default";
+ pinctrl-0 = <&spi0_pins>;
+ resets = <&ccu RST_BUS_SPI0>;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ spi1: spi at 01c69000 {
+ compatible = "allwinner,sun8i-h3-spi";
+ reg = <0x01c69000 0x1000>;
+ interrupts = <GIC_SPI 66 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_SPI1>, <&ccu CLK_SPI1>;
+ clock-names = "ahb", "mod";
+ dmas = <&dma 24>, <&dma 24>;
+ dma-names = "rx", "tx";
+ pinctrl-names = "default";
+ pinctrl-0 = <&spi1_pins>;
+ resets = <&ccu RST_BUS_SPI1>;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
wdt0: watchdog at 01c20ca0 {
compatible = "allwinner,sun6i-a31-wdt";
reg = <0x01c20ca0 0x20>;
--
2.9.3
^ permalink raw reply related
* [PATCH v2] arm64: Cortex-A53 errata workaround: check for kernel addresses
From: Andre Przywara @ 2016-10-19 13:40 UTC (permalink / raw)
To: linux-arm-kernel
Commit 7dd01aef0557 ("arm64: trap userspace "dc cvau" cache operation on
errata-affected core") adds code to execute cache maintenance instructions
in the kernel on behalf of userland on CPUs with certain ARM CPU errata.
It turns out that the address hasn't been checked to be a valid user
space address, allowing userland to clean cache lines in kernel space.
Fix this by introducing an access_ok() check before executing the
instructions on behalf of userland. We have to take care of tagged
pointers here, since the address is not coming in via a syscall (which
requires the tag to be 0).
Fixes: 7dd01aef0557 ("arm64: trap userspace "dc cvau" cache operation on errata-affected core")
Reported-by: Kristina Martsenko <kristina.martsenko@arm.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
Changelog v1 .. v2:
- use PAGE_SIZE instead of cache_line_size() for access check
- merge extra function into original macro
- replace access_ok_tagged() with untagged_addr() macro
arch/arm64/include/asm/uaccess.h | 8 ++++++++
arch/arm64/kernel/traps.c | 35 +++++++++++++++++++++++------------
2 files changed, 31 insertions(+), 12 deletions(-)
diff --git a/arch/arm64/include/asm/uaccess.h b/arch/arm64/include/asm/uaccess.h
index bcaf6fb..55d0adb 100644
--- a/arch/arm64/include/asm/uaccess.h
+++ b/arch/arm64/include/asm/uaccess.h
@@ -21,6 +21,7 @@
/*
* User space memory access functions
*/
+#include <linux/bitops.h>
#include <linux/kasan-checks.h>
#include <linux/string.h>
#include <linux/thread_info.h>
@@ -102,6 +103,13 @@ static inline void set_fs(mm_segment_t fs)
flag; \
})
+/*
+ * When dealing with data aborts or instruction traps we may end up with
+ * a tagged userland pointer. Clear the tag to get a sane pointer to pass
+ * on to access_ok(), for instance.
+ */
+#define untagged_addr(addr) sign_extend64(addr, 55)
+
#define access_ok(type, addr, size) __range_ok(addr, size)
#define user_addr_max get_fs
diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
index 5ff020f..1e81328 100644
--- a/arch/arm64/kernel/traps.c
+++ b/arch/arm64/kernel/traps.c
@@ -433,19 +433,30 @@ void cpu_enable_cache_maint_trap(void *__unused)
config_sctlr_el1(SCTLR_EL1_UCI, 0);
}
+/*
+ * Technically the access_ok() check should be done on a cache line size
+ * granularity, but it's tedious the get the right one (dcache vs. icache,
+ * per-core vs. system wide). Since permission checks are based on pages
+ * anyway, just use PAGE_SIZE instead.
+ */
#define __user_cache_maint(insn, address, res) \
- asm volatile ( \
- "1: " insn ", %1\n" \
- " mov %w0, #0\n" \
- "2:\n" \
- " .pushsection .fixup,\"ax\"\n" \
- " .align 2\n" \
- "3: mov %w0, %w2\n" \
- " b 2b\n" \
- " .popsection\n" \
- _ASM_EXTABLE(1b, 3b) \
- : "=r" (res) \
- : "r" (address), "i" (-EFAULT) )
+ if (!access_ok(VERIFY_READ, \
+ untagged_addr(address & PAGE_MASK), \
+ PAGE_SIZE)) \
+ res = -EFAULT; \
+ else \
+ asm volatile ( \
+ "1: " insn ", %1\n" \
+ " mov %w0, #0\n" \
+ "2:\n" \
+ " .pushsection .fixup,\"ax\"\n" \
+ " .align 2\n" \
+ "3: mov %w0, %w2\n" \
+ " b 2b\n" \
+ " .popsection\n" \
+ _ASM_EXTABLE(1b, 3b) \
+ : "=r" (res) \
+ : "r" (address), "i" (-EFAULT) )
static void user_cache_maint_handler(unsigned int esr, struct pt_regs *regs)
{
--
2.9.0
^ permalink raw reply related
* Build failure with v4.9-rc1 and GCC trunk -- compiler weirdness
From: Will Deacon @ 2016-10-19 13:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu869PXA_cXaL6+uokRCS4EZ8-q6x2xnj4e5DWO28B5jCw@mail.gmail.com>
Hi Ard,
On Mon, Oct 17, 2016 at 08:43:19PM +0100, Ard Biesheuvel wrote:
> On 17 October 2016 at 19:38, Will Deacon <will.deacon@arm.com> wrote:
> > I'm seeing an arm64 build failure with -rc1 and GCC trunk, although I
> > believe that the new compiler behaviour at the heart of the problem
> > has the potential to affect other architectures and other pieces of
> > kernel code relying on dead-code elimination to remove deliberately
> > undefined functions.
> >
> > The failure looks like:
> >
> > | drivers/built-in.o: In function `armada_3700_add_composite_clk':
> > |
> > | linux/drivers/clk/mvebu/armada-37xx-periph.c:351:
> > | undefined reference to `____ilog2_NaN'
> > |
> > | linux/drivers/clk/mvebu/armada-37xx-periph.c:351:(.text+0xc72e0):
> > | relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol
> > | `____ilog2_NaN'
> > |
> > | make: *** [vmlinux] Error 1
> >
> > and if we look at the source for armada_3700_add_composite_clk, we see
> > that this is caused by:
> >
> > int table_size = 0;
> >
> > rate->reg = reg + (u64)rate->reg;
> > for (clkt = rate->table; clkt->div; clkt++)
> > table_size++;
> > rate->width = order_base_2(table_size);
> >
> > order_base_2 calls ilog2, which has the ____ilog2_NaN call:
> >
> > #define ilog2(n) \
> > ( \
> > __builtin_constant_p(n) ? ( \
> > (n) < 1 ? ____ilog2_NaN() : \
> >
> > This is because we're in a curious case where GCC has emitted a
> > special-cased version of armada_3700_add_composite_clk, with table_size
> > effectively constant-folded as 0. Whilst we shouldn't see this in a
> > non-buggy kernel (hence the deliberate call to the undefined function
> > ____ilog2_NaN), it means that the final link fails because we have a
> > ____ilog2_NaN in the code, with a runtime check on table_size.
> >
>
> This is indeed an unintended side effect, but I would not call it
> weird behaviour at all. The code in its current form does not handle
> the case where it could end up passing 0 into order_base_2(), and we
> simply need to handle that case.
The reasons I think it's weird are:
(1) The optimisation doesn't generate better code in this case --
optimising for the table_size == 0 case is uninformed, particularly
as that *cannot* happen at runtime (GCC probably can't tell, due
to things like container_of, but all the clock data is static).
(2) __builtin_constant_p(n) could be interpreted by a developer as
"this code will execute with a constant n at runtime". With this
issue, GCC could (in theory) generate a specialisation for every
possible value of a variable, and return __builtin_constant_p as
true for all of them, which somewhat undermines the point of the
builtin.
> If order_base_2() is not defined for input 0, it should BUG() in that
> case, and the associated __builtin_unreachable() should prevent the
> special version from being emitted. If order_base_2() is defined for input
> 0, it should not invoke ilog2() with that argument, and the problem should
> go away as well.
I don't necessarily think it should BUG() if it's not defined for input
0; things like __ffs don't do that and we'd be introducing conditional
checks for cases that should not happen. The comment above order_base_2
does suggest that ob2(0) should return 0, but it can actually end up
invoking ilog2(-1), which is obviously wrong.
I could update the comment, but that doesn't fix the build issue.
Will
^ permalink raw reply
* [PATCH V5 00/10] dmaengine: qcom_hidma: add MSI interrupt support
From: Vinod Koul @ 2016-10-19 13:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475817915-11976-1-git-send-email-okaya@codeaurora.org>
On Fri, Oct 07, 2016 at 01:25:05AM -0400, Sinan Kaya wrote:
> The new version of the HW supports MSI interrupts instead of wired
> interrupts. The MSI interrupts are especially useful for the guest machine
> execution. The wired interrupts usually trap to the hypervisor and then are
> relayed to the actual interrupt.
>
> The MSI interrupts can be directly fed into the interrupt controller.
>
> Adding a new OF compat string (qcom,hidma-1.1) and ACPI string (QCOM8062)
> to distinguish newer HW from the older ones.
I was only able to apply 6 patches in this series. Which tree were these
generated against?
Please rebase rest..
--
~Vinod
^ permalink raw reply
* [PATCH v2] mmc: sunxi: Prevent against null dereference for vmmc
From: Maxime Ripard @ 2016-10-19 13:33 UTC (permalink / raw)
To: linux-arm-kernel
VMMC is an optional regulator, which means that mmc_regulator_get_supply
will only return an error in case of a deferred probe, but not when the
regulator is not set in the DT.
However, the sunxi driver assumes that VMMC is always there, and doesn't
check the value of the regulator pointer before using it, which obviously
leads to a (close to) null pointer dereference.
Add proper checks to prevent that.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
Changes from v1:
- remove redundant error message
---
drivers/mmc/host/sunxi-mmc.c | 15 ++++++++++-----
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
index c0a5c676d0e8..b1d1303389a7 100644
--- a/drivers/mmc/host/sunxi-mmc.c
+++ b/drivers/mmc/host/sunxi-mmc.c
@@ -822,10 +822,13 @@ static void sunxi_mmc_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
break;
case MMC_POWER_UP:
- host->ferror = mmc_regulator_set_ocr(mmc, mmc->supply.vmmc,
- ios->vdd);
- if (host->ferror)
- return;
+ if (!IS_ERR(mmc->supply.vmmc)) {
+ host->ferror = mmc_regulator_set_ocr(mmc,
+ mmc->supply.vmmc,
+ ios->vdd);
+ if (host->ferror)
+ return;
+ }
if (!IS_ERR(mmc->supply.vqmmc)) {
host->ferror = regulator_enable(mmc->supply.vqmmc);
@@ -847,7 +850,9 @@ static void sunxi_mmc_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
case MMC_POWER_OFF:
dev_dbg(mmc_dev(mmc), "power off!\n");
sunxi_mmc_reset_host(host);
- mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, 0);
+ if (!IS_ERR(mmc->supply.vmmc))
+ mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, 0);
+
if (!IS_ERR(mmc->supply.vqmmc) && host->vqmmc_enabled)
regulator_disable(mmc->supply.vqmmc);
host->vqmmc_enabled = false;
--
2.9.3
^ permalink raw reply related
* [PATCH 2/3] arm64: hw_breakpoint: Handle inexact watchpoint addresses
From: Pavel Labath @ 2016-10-19 13:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161019120714.GM9193@arm.com>
I've send the test suite update to Pratyush via github yesterday. I
presume he will come with a v2 soon. :)
regards,
pavel
On 19 October 2016 at 13:07, Will Deacon <will.deacon@arm.com> wrote:
> On Fri, Oct 14, 2016 at 08:45:43AM +0530, Pratyush Anand wrote:
>>
>>
>> On Thursday 13 October 2016 10:33 PM, Pavel Labath wrote:
>> >>I think, its easier to go with your implementation. So, I have taken
>> >>> your patch and updated my perf/upstream_arm64_devel branch. May be you
>> >>> can give it a test for your test cases.
>> >I've checked out the new version of your branch, and it works great.
>> >I'll write a patch with additional test cases to go on top of your
>> >branch, as the tests there do not capture the bug I was fixing.
>>
>> That would be great. We can send them all together as V2.
>
> Did you send a v2? I've been holding off reviewing this, but I just want
> to make sure I didn't miss the update.
>
> Cheers,
>
> Will
^ permalink raw reply
* [PATCH] exynos-drm: Fix error messages to print flags and size
From: Inki Dae @ 2016-10-19 13:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57F64D0B.5050506@math.uni-bielefeld.de>
2016-10-06 22:09 GMT+09:00 Tobias Jakobi <tjakobi@math.uni-bielefeld.de>:
> Hello,
>
> I think this patch was never picked up. So just a short 'ping' from my side.
>
Oops. one I missed. Will pick it up soon.
Thanks,
Inki Dae
> With best wishes,
> Tobias
>
>
> Shuah Khan wrote:
>> Fix exynos_drm_gem_create() error messages to include flags and size when
>> flags and size are invalid.
>>
>> Signed-off-by: Shuah Khan <shuahkh@osg.samsung.com>
>> ---
>> drivers/gpu/drm/exynos/exynos_drm_gem.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c b/drivers/gpu/drm/exynos/exynos_drm_gem.c
>> index cdf9f1a..4c4cb0e 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
>> @@ -231,12 +231,12 @@ struct exynos_drm_gem *exynos_drm_gem_create(struct drm_device *dev,
>> int ret;
>>
>> if (flags & ~(EXYNOS_BO_MASK)) {
>> - DRM_ERROR("invalid flags.\n");
>> + DRM_ERROR("invalid GEM buffer flags: %u\n", flags);
>> return ERR_PTR(-EINVAL);
>> }
>>
>> if (!size) {
>> - DRM_ERROR("invalid size.\n");
>> + DRM_ERROR("invalid GEM buffer size: %lu\n", size);
>> return ERR_PTR(-EINVAL);
>> }
>>
>>
>
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* [PATCH] dmaengine: qcom_hidma: cleanup sysfs entries during remove
From: Vinod Koul @ 2016-10-19 13:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475796189-26553-1-git-send-email-okaya@codeaurora.org>
On Thu, Oct 06, 2016 at 07:23:09PM -0400, Sinan Kaya wrote:
> The 4.8-rc8 kernel is printing duplicate file entry warnings while removing
> the HIDMA object. This is caused by stale sysfs entries remaining from the
> previous execution.
>
> _sysfs_warn_dup+0x5c/0x78
> sysfs_add_file_mode_ns+0x13c/0x1c0
> sysfs_create_file_ns+0x2c/0x40
> device_create_file+0x54/0xa0
> hidma_probe+0x7c8/0x808
>
> Create hidma_sysfs_init and hidma_sysfs_uninit functions and call them from
> the probe and remove path. To do proper clean up, adding the attrs object
> to the device data structure to keep it around until remove call is made.
>
> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
> ---
> drivers/dma/qcom/hidma.c | 31 +++++++++++++++++++++++++------
> drivers/dma/qcom/hidma.h | 3 +++
> 2 files changed, 28 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/dma/qcom/hidma.c b/drivers/dma/qcom/hidma.c
> index f4fe4ee..414ea12 100644
> --- a/drivers/dma/qcom/hidma.c
> +++ b/drivers/dma/qcom/hidma.c
> @@ -578,8 +578,17 @@ static ssize_t hidma_show_values(struct device *dev,
> return strlen(buf);
> }
>
> -static int hidma_create_sysfs_entry(struct hidma_dev *dev, char *name,
> - int mode)
> +static int hidma_sysfs_uninit(struct hidma_dev *dev)
> +{
> + if (!dev->chid_attrs)
> + return -ENOMEM;
why is this check required? Probe would fail in init case right.
Second returning error doesnt help as you are calling this from remove and
return is not checked so redundant!
--
~Vinod
^ permalink raw reply
* [PATCH -next] dmaengine: st_fdma: Fix the error return code in st_fdma_probe()
From: Wei Yongjun @ 2016-10-19 13:23 UTC (permalink / raw)
To: linux-arm-kernel
From: Wei Yongjun <weiyongjun1@huawei.com>
In case of error, the function st_slim_rproc_alloc() returns ERR_PTR()
and never returns NULL. The NULL test in the return value check should
be replaced with IS_ERR().
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
---
drivers/dma/st_fdma.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dma/st_fdma.c b/drivers/dma/st_fdma.c
index 515e1d4..a66a57b 100644
--- a/drivers/dma/st_fdma.c
+++ b/drivers/dma/st_fdma.c
@@ -802,7 +802,7 @@ static int st_fdma_probe(struct platform_device *pdev)
}
fdev->slim_rproc = st_slim_rproc_alloc(pdev, fdev->fw_name);
- if (!fdev->slim_rproc) {
+ if (IS_ERR(fdev->slim_rproc)) {
ret = PTR_ERR(fdev->slim_rproc);
dev_err(&pdev->dev, "slim_rproc_alloc failed (%d)\n", ret);
goto err;
^ permalink raw reply related
* [PATCH] dmaengine: qcom_hidma: remove useless debugfs file removal
From: Vinod Koul @ 2016-10-19 13:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475792489-1415-1-git-send-email-okaya@codeaurora.org>
On Thu, Oct 06, 2016 at 06:21:29PM -0400, Sinan Kaya wrote:
> Since 'commit acc29fb8f792 ("debugfs: ->d_parent is never NULL or
> negative")', HIDMA object removal is no longer working. This is due to
> redundant debugfs remove call in hidma_debug_uninit.
>
> debugfs_remove_recursive(dmadev->debugfs);
> debugfs_remove_recursive(dmadev->stats);
>
> The first remove is for the directory. Second remove is for the file under
> the directory. The directory remove makes file remove invalid.
>
> Unable to handle kernel NULL pointer dereference at virtual address
>
> [<ffff00000889f480>] down_write+0x18/0x68
> [<ffff00000831c220>] debugfs_remove_recursive+0x50/0x1c0
> [<ffff00000848e0a8>] hidma_debug_uninit+0x20/0x30
> [<ffff00000848c5d8>] hidma_remove+0x48/0x98
> [<ffff000008511b6c>] platform_drv_remove+0x24/0x68
> [<ffff00000850fac8>] __device_release_driver+0x80/0x118
> [<ffff00000850fb84>] device_release_driver+0x24/0x38
> [<ffff00000850e928>] unbind_store+0xe8/0x110
> [<ffff00000850dd30>] drv_attr_store+0x20/0x30
> [<ffff000008253a48>] sysfs_kf_write+0x48/0x58
> [<ffff000008252dd8>] kernfs_fop_write+0xb0/0x1d8
> [<ffff0000081dab3c>] __vfs_write+0x1c/0x110
> [<ffff0000081db940>] vfs_write+0xa0/0x1b8
> [<ffff0000081dcd34>] SyS_write+0x44/0xa0
> [<ffff000008082ef0>] el0_svc_naked+0x24/0x28
>
> Removing the second line.
Applied, thanks
--
~Vinod
^ permalink raw reply
* [PATCH] mmc: sunxi: Prevent against null dereference for vmmc
From: Ulf Hansson @ 2016-10-19 13:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161019123629.14525-1-maxime.ripard@free-electrons.com>
On 19 October 2016 at 14:36, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> VMMC is an optional regulator, which means that mmc_regulator_get_supply
> will only return an error in case of a deferred probe, but not when the
> regulator is not set in the DT.
>
> However, the sunxi driver assumes that VMMC is always there, and doesn't
> check the value of the regulator pointer before using it, which obviously
> leads to a (close to) null pointer dereference.
>
> Add proper checks to prevent that.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> ---
> drivers/mmc/host/sunxi-mmc.c | 18 +++++++++++++-----
> 1 file changed, 13 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
> index c0a5c676d0e8..45a051e7d650 100644
> --- a/drivers/mmc/host/sunxi-mmc.c
> +++ b/drivers/mmc/host/sunxi-mmc.c
> @@ -822,10 +822,16 @@ static void sunxi_mmc_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
> break;
>
> case MMC_POWER_UP:
> - host->ferror = mmc_regulator_set_ocr(mmc, mmc->supply.vmmc,
> - ios->vdd);
> - if (host->ferror)
> - return;
> + if (!IS_ERR(mmc->supply.vmmc)) {
> + host->ferror = mmc_regulator_set_ocr(mmc,
> + mmc->supply.vmmc,
> + ios->vdd);
> + if (host->ferror) {
> + dev_err(mmc_dev(mmc),
> + "failed to enable vmmc\n");
The print here is already taken care of by mmc_regulator_set_ocr()
> + return;
> + }
> + }
>
> if (!IS_ERR(mmc->supply.vqmmc)) {
> host->ferror = regulator_enable(mmc->supply.vqmmc);
> @@ -847,7 +853,9 @@ static void sunxi_mmc_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
> case MMC_POWER_OFF:
> dev_dbg(mmc_dev(mmc), "power off!\n");
> sunxi_mmc_reset_host(host);
> - mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, 0);
> + if (!IS_ERR(mmc->supply.vmmc))
> + mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, 0);
> +
> if (!IS_ERR(mmc->supply.vqmmc) && host->vqmmc_enabled)
> regulator_disable(mmc->supply.vqmmc);
> host->vqmmc_enabled = false;
> --
> 2.9.3
>
Otherwise this looks good to me!
Kind regards
Uffe
^ permalink raw reply
* [PATCH] dmaengine: st_fdma: fix uninitialized variable access
From: Vinod Koul @ 2016-10-19 13:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161019120927.3251235-1-arnd@arndb.de>
On Wed, Oct 19, 2016 at 02:09:10PM +0200, Arnd Bergmann wrote:
> The newly added st_fdma driver introduces a build warning for
> allmodconfig when we add '-Wmaybe-uninitialized':
>
> drivers/dma/st_fdma.c: In function 'st_fdma_probe':
> drivers/dma/st_fdma.c:777:5: error: 'ret' may be used uninitialized in this function [-Werror=maybe-uninitialized]
>
> The warning is correct, though this can't happen in practice
> as the check is redundant (we don't get to this function if
> the pointer is NULL). Even if the function were called with a
> NULL of_node, the check is not needed because of_property_read_u32
> can deal with a NULL argument by returning an error.
>
> Removing the unnecessary code simplifies the function and avoids
> the condition that we get the warning for.
Applied, thanks
--
~Vinod
^ permalink raw reply
* how to enable suspend to ram for arm-64 bits
From: Mark Rutland @ 2016-10-19 13:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161019094227.GB1461@amd>
On Wed, Oct 19, 2016 at 11:42:27AM +0200, Pavel Machek wrote:
> On Tue 2016-10-18 11:45:39, Mark Rutland wrote:
> Either the lowlevel suspend code is stable and bug free, and then
> having that code is not a problem.
This ignores the cost of maintaining that code. Kernel APIs change over
time, and no code is ever completely stable, even if at one point in
time it happens to be bug-free.
> Or the lowlevel suspend code is complex enough to contain some bugs,
> and in such case it is better to debug and update it with kernel.
It is better for that code to be debuggable and updateable. That is not
the same as being part of the kernel.
> > ARM publishes and maintains the ARM Trusted Firmware [1], which anyone
> > can use and build atop of. It's open source (three-clause BSD with DCO),
> > and accepts board ports. You can have a completely open stack,
> > regardless of whether part of that stack is firmware.
>
> If something is called "Trusted", it is not trustworthy.
Certainly we shouldn't blindly trust anything.
I object to ATF being called "not trustworthy"; the aims of the project
are certainly not dishonest.
> BSD is better than closed source, but it also means that you will not
> get the sources from your hw vendor.
That depends on your hardware vendor, as always. There are a number of
platform ports in the upstream ATF repo.
It's also worth considering that a number of 32-bit arm parts require
closed firmware (as far as I can tell, including the N900).
> Being separate module means it will be never updated.
That's certainly not true as a blanket statement. The Juno FW (including
an open-source UEFI!) is periodically updated, and mechanisms like
UpdateCapsule() should make this easier in future.
> Being separate module means it will be hard to debug, in area where
> debugging is already pretty hard.
It can be harder, yes. There are also benefits, given the same code can
be tested on a variety of platforms.
> Can it do advanced stuff like deep powersaving on N900 idle?
Sorry, I don't know precisely what you're referring to.
It can do things like shutting down entire CPU clusters (and IIRC
associated interconnect) when all relevant CPUs are idle, if that's what
you mean.
Thanks,
Mark.
^ permalink raw reply
* [PATCH v2 5/9] of: Add vendor prefix for Netron DY
From: Rob Herring @ 2016-10-19 13:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161019123927.GE16158@ulmo.ba.sec>
On Wed, Oct 19, 2016 at 7:39 AM, Thierry Reding
<thierry.reding@gmail.com> wrote:
> On Tue, Sep 06, 2016 at 04:46:16PM +0200, Maxime Ripard wrote:
>> Netron DY is a brand of LCD panels found on SBCs and tablets.
>>
>> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
>> ---
>> Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
>> 1 file changed, 1 insertion(+)
>
> Hi Rob,
>
> care to give this your Acked-by?
It helps to send to the DT list.
Acked-by: Rob Herring <robh@kernel.org>
>
> Thanks,
> Thierry
>
>> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
>> index 1992aa97d45a..9c1ab3c1132b 100644
>> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
>> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
>> @@ -176,6 +176,7 @@ nec NEC LCD Technologies, Ltd.
>> neonode Neonode Inc.
>> netgear NETGEAR
>> netlogic Broadcom Corporation (formerly NetLogic Microsystems)
>> +netron-dy Netron DY
>> netxeon Shenzhen Netxeon Technology CO., LTD
>> newhaven Newhaven Display International
>> nintendo Nintendo
>> --
>> 2.9.3
>>
^ permalink raw reply
* [RFC PATCH 1/2] efi: libstub: preserve .debug sections after absolute relocation check
From: Cohen, Eugene @ 2016-10-19 12:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476877232-24308-2-git-send-email-ard.biesheuvel@linaro.org>
I was literally just looking at this. I originally commented out the removal of debug (which I though was really annoying) but ran into the absolute relocations warning for symbols that it need not apply to. Your two-pass solution is a nice one.
> -----Original Message-----
> From: Ard Biesheuvel [mailto:ard.biesheuvel at linaro.org]
> Sent: Wednesday, October 19, 2016 5:41 AM
> To: linux-efi at vger.kernel.org; linux-arm-kernel at lists.infradead.org
> Cc: mark.rutland at arm.com; leif.lindholm at linaro.org; Cohen, Eugene
> <eugene@hp.com>; matt at codeblueprint.co.uk; Ard Biesheuvel
> <ard.biesheuvel@linaro.org>
> Subject: [RFC PATCH 1/2] efi: libstub: preserve .debug sections after absolute
> relocation check
>
> The build commands for the ARM and arm64 EFI stubs strips the .debug
> sections and other sections that my legally contain absolute relocations,
> in order to inspect the remaining sections for the presence of such
> relocations.
>
> This leaves us without debugging symbols in the stub for no good reason,
> given that these sections are omitted from the kernel binary, and that
> these relocations are thus only interpreted by the debugger.
>
> So if the relocation check succeeds, invoke objcopy again, but this time,
> leave the .debug sections in place. Note that these sections may refer
> to ksymtab/kcrctab contents, so leave those in place as well.
>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Eugene Cohen <eugene@hp.com>
> ---
> drivers/firmware/efi/libstub/Makefile | 19 ++++++++++++++-----
> 1 file changed, 14 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/firmware/efi/libstub/Makefile
> b/drivers/firmware/efi/libstub/Makefile
> index c06945160a41..66584f173123 100644
> --- a/drivers/firmware/efi/libstub/Makefile
> +++ b/drivers/firmware/efi/libstub/Makefile
> @@ -60,7 +60,7 @@ CFLAGS_arm64-stub.o := -
> DTEXT_OFFSET=$(TEXT_OFFSET)
> extra-$(CONFIG_EFI_ARMSTUB) := $(lib-y)
> lib-$(CONFIG_EFI_ARMSTUB) := $(patsubst %.o,%.stub.o,$(lib-y))
>
> -STUBCOPY_FLAGS-y := -R .debug* -R *ksymtab* -R *kcrctab*
> +STUBCOPY_RM := -R .debug* -R *ksymtab* -R *kcrctab*
> STUBCOPY_FLAGS-$(CONFIG_ARM64) += --prefix-alloc-sections=.init \
> --prefix-symbols=__efistub_
> STUBCOPY_RELOC-$(CONFIG_ARM64) := R_AARCH64_ABS
> @@ -68,11 +68,20 @@ STUBCOPY_RELOC-$(CONFIG_ARM64) :=
> R_AARCH64_ABS
> $(obj)/%.stub.o: $(obj)/%.o FORCE
> $(call if_changed,stubcopy)
>
> +#
> +# This calls objcopy twice: the first time it includes STUBCOPY_RM, and inspects
> +# the result to ensure that the actual code itself does not contain any absolute
> +# references. If this succeeds, the objcopy is performed a second time, but this
> +# time the .debug and other sections are retained, given that we know that the
> +# absolute relocations they may contain are harmless.
> +#
> quiet_cmd_stubcopy = STUBCPY $@
> - cmd_stubcopy = if $(OBJCOPY) $(STUBCOPY_FLAGS-y) $< $@; then \
> - $(OBJDUMP) -r $@ | grep $(STUBCOPY_RELOC-y) \
> - && (echo >&2 "$@: absolute symbol references not allowed in
> the EFI stub"; \
> - rm -f $@; /bin/false); else /bin/false; fi
> + cmd_stubcopy = if $(OBJCOPY) $(STUBCOPY_FLAGS-y) $(STUBCOPY_RM) $<
> $@; \
> + then if $(OBJDUMP) -r $@ | grep $(STUBCOPY_RELOC-y); \
> + then (echo >&2 "$@: absolute symbol references not allowed
> in the EFI stub"; \
> + rm -f $@; /bin/false); \
> + else $(OBJCOPY) $(STUBCOPY_FLAGS-y) $< $@; fi \
> + else /bin/false; fi
>
> #
> # ARM discards the .data section because it disallows r/w data in the
> --
> 2.7.4
^ permalink raw reply
* [PATCH] dmaengine: st_fdma: fix uninitialized variable access
From: Peter Griffin @ 2016-10-19 12:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161019120927.3251235-1-arnd@arndb.de>
Hi Arnd,
On Wed, 19 Oct 2016, Arnd Bergmann wrote:
> The newly added st_fdma driver introduces a build warning for
> allmodconfig when we add '-Wmaybe-uninitialized':
>
> drivers/dma/st_fdma.c: In function 'st_fdma_probe':
> drivers/dma/st_fdma.c:777:5: error: 'ret' may be used uninitialized in this function [-Werror=maybe-uninitialized]
>
> The warning is correct, though this can't happen in practice
> as the check is redundant (we don't get to this function if
> the pointer is NULL). Even if the function were called with a
> NULL of_node, the check is not needed because of_property_read_u32
> can deal with a NULL argument by returning an error.
>
> Removing the unnecessary code simplifies the function and avoids
> the condition that we get the warning for.
>
> Fixes: 6b4cd727eaf1 ("dmaengine: st_fdma: Add STMicroelectronics FDMA engine driver support")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
Acked-by: Peter Griffin <peter.griffin@linaro.org>
regards,
Peter.
^ 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