* Re: [PATCH v5 2/4] arm64: KVM: add accessors to track guest/host only counters
From: Suzuki K Poulose @ 2018-12-06 18:51 UTC (permalink / raw)
To: Andrew Murray, Christoffer Dall, Marc Zyngier, Catalin Marinas,
Will Deacon, Mark Rutland
Cc: kvmarm, linux-arm-kernel, Julien Thierry
In-Reply-To: <97301473-69d0-9a0b-b957-5568a43a6551@arm.com>
On 06/12/2018 17:21, Suzuki K Poulose wrote:
> Hi Andrew,
>
> On 05/12/2018 15:30, Andrew Murray wrote:
>> In order to effeciently enable/disable guest/host only perf counters
>> at guest entry/exit we add bitfields to kvm_cpu_context for guest and
>> host events as well as accessors for updating them.
>>
>> Signed-off-by: Andrew Murray <andrew.murray@arm.com>
>> ---
>> arch/arm64/include/asm/kvm_host.h | 24 ++++++++++++++++++++++++
>> 1 file changed, 24 insertions(+)
>>
>> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
>> index 1550192..800c87b 100644
>> --- a/arch/arm64/include/asm/kvm_host.h
>> +++ b/arch/arm64/include/asm/kvm_host.h
>> @@ -203,6 +203,8 @@ struct kvm_cpu_context {
>> };
>>
>> struct kvm_vcpu *__hyp_running_vcpu;
>> + u32 events_host;
>> + u32 events_guest;
>> };
>>
>> typedef struct kvm_cpu_context kvm_cpu_context_t;
>> @@ -467,11 +469,33 @@ void kvm_arch_vcpu_load_fp(struct kvm_vcpu *vcpu);
>> void kvm_arch_vcpu_ctxsync_fp(struct kvm_vcpu *vcpu);
>> void kvm_arch_vcpu_put_fp(struct kvm_vcpu *vcpu);
>>
>> +#define KVM_PMU_EVENTS_HOST 1
>> +#define KVM_PMU_EVENTS_GUEST 2
>> +
>> #ifdef CONFIG_KVM /* Avoid conflicts with core headers if CONFIG_KVM=n */
>> static inline int kvm_arch_vcpu_run_pid_change(struct kvm_vcpu *vcpu)
>> {
>> return kvm_arch_vcpu_run_map_fp(vcpu);
>> }
>> +static inline void kvm_set_pmu_events(u32 set, int flags)
>> +{
>> + kvm_cpu_context_t *ctx = this_cpu_ptr(&kvm_host_cpu_state);
>> +
>> + if (flags & KVM_PMU_EVENTS_HOST)
>> + ctx->events_host |= set;
>> + if (flags & KVM_PMU_EVENTS_GUEST)
>> + ctx->events_guest |= set;
>
> You seem to be passing a single flag at a time ever, in the next patch.
> Either we can batch the calls in the next patch, or make this a real number and
> not a flag. g.g, enum { HOST, GUEST } or even a bool.
>
> I think the former sounds better.
Having another look at patch-3, we can never club set() calls for host & guest
events, we should go for the latter.
Suzuki
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v5 3/4] arm64: arm_pmu: Add support for exclude_host/exclude_guest attributes
From: Suzuki K Poulose @ 2018-12-06 18:49 UTC (permalink / raw)
To: Andrew Murray, Christoffer Dall, Marc Zyngier, Catalin Marinas,
Will Deacon, Mark Rutland
Cc: kvmarm, linux-arm-kernel, Julien Thierry
In-Reply-To: <1544023815-16958-4-git-send-email-andrew.murray@arm.com>
On 05/12/2018 15:30, Andrew Murray wrote:
> Add support for the :G and :H attributes in perf by handling the
> exclude_host/exclude_guest event attributes.
>
> We notify KVM of counters that we wish to be enabled or disabled on
> guest entry/exit and thus defer from starting or stopping :G events
> as per the events exclude_host attribute.
>
> With both VHE and non-VHE we switch the counters between host/guest
> at EL2. We are able to eliminate counters counting host events on
> the boundaries of guest entry/exit when using :G by filtering out
> EL2 for exclude_host. However when using :H unless exclude_hv is set
> on non-VHE then there is a small blackout window at the guest
> entry/exit where host events are not captured.
>
> Signed-off-by: Andrew Murray <andrew.murray@arm.com>
> ---
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v3 4/9] drm/rockchip/rockchip_drm_gem.c: Convert to use vm_insert_range
From: Souptick Joarder @ 2018-12-06 18:42 UTC (permalink / raw)
To: akpm, willy, mhocko, hjc, heiko, airlied
Cc: linux-mm, dri-devel, linux-kernel, linux-arm-kernel,
linux-rockchip
Convert to use vm_insert_range() to map range of kernel
memory to user vma.
Signed-off-by: Souptick Joarder <jrdr.linux@gmail.com>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Acked-by: Heiko Stuebner <heiko@sntech.de>
---
drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 20 ++------------------
1 file changed, 2 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
index a8db758..2cb83bb 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
@@ -221,26 +221,10 @@ static int rockchip_drm_gem_object_mmap_iommu(struct drm_gem_object *obj,
struct vm_area_struct *vma)
{
struct rockchip_gem_object *rk_obj = to_rockchip_obj(obj);
- unsigned int i, count = obj->size >> PAGE_SHIFT;
unsigned long user_count = vma_pages(vma);
- unsigned long uaddr = vma->vm_start;
- unsigned long offset = vma->vm_pgoff;
- unsigned long end = user_count + offset;
- int ret;
-
- if (user_count == 0)
- return -ENXIO;
- if (end > count)
- return -ENXIO;
- for (i = offset; i < end; i++) {
- ret = vm_insert_page(vma, uaddr, rk_obj->pages[i]);
- if (ret)
- return ret;
- uaddr += PAGE_SIZE;
- }
-
- return 0;
+ return vm_insert_range(vma, vma->vm_start, rk_obj->pages,
+ user_count);
}
static int rockchip_drm_gem_object_mmap_dma(struct drm_gem_object *obj,
--
1.9.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v3 3/9] drivers/firewire/core-iso.c: Convert to use vm_insert_range
From: Souptick Joarder @ 2018-12-06 18:41 UTC (permalink / raw)
To: akpm, willy, mhocko, stefanr
Cc: linux-mm, linux1394-devel, linux-kernel, linux-arm-kernel
Convert to use vm_insert_range to map range of kernel memory
to user vma.
Signed-off-by: Souptick Joarder <jrdr.linux@gmail.com>
Reviewed-by: Matthew Wilcox <willy@infradead.org>
---
drivers/firewire/core-iso.c | 15 ++-------------
1 file changed, 2 insertions(+), 13 deletions(-)
diff --git a/drivers/firewire/core-iso.c b/drivers/firewire/core-iso.c
index 35e784c..7bf28bb 100644
--- a/drivers/firewire/core-iso.c
+++ b/drivers/firewire/core-iso.c
@@ -107,19 +107,8 @@ int fw_iso_buffer_init(struct fw_iso_buffer *buffer, struct fw_card *card,
int fw_iso_buffer_map_vma(struct fw_iso_buffer *buffer,
struct vm_area_struct *vma)
{
- unsigned long uaddr;
- int i, err;
-
- uaddr = vma->vm_start;
- for (i = 0; i < buffer->page_count; i++) {
- err = vm_insert_page(vma, uaddr, buffer->pages[i]);
- if (err)
- return err;
-
- uaddr += PAGE_SIZE;
- }
-
- return 0;
+ return vm_insert_range(vma, vma->vm_start, buffer->pages,
+ buffer->page_count);
}
void fw_iso_buffer_destroy(struct fw_iso_buffer *buffer,
--
1.9.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v3 2/9] arch/arm/mm/dma-mapping.c: Convert to use vm_insert_range
From: Souptick Joarder @ 2018-12-06 18:41 UTC (permalink / raw)
To: akpm, willy, mhocko, linux, robin.murphy, iamjoonsoo.kim, treding,
keescook, m.szyprowski
Cc: linux-mm, linux-kernel, linux-arm-kernel
Convert to use vm_insert_range() to map range of kernel
memory to user vma.
Signed-off-by: Souptick Joarder <jrdr.linux@gmail.com>
---
arch/arm/mm/dma-mapping.c | 21 +++++++--------------
1 file changed, 7 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index 661fe48..4eec323 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -1582,31 +1582,24 @@ static int __arm_iommu_mmap_attrs(struct device *dev, struct vm_area_struct *vma
void *cpu_addr, dma_addr_t dma_addr, size_t size,
unsigned long attrs)
{
- unsigned long uaddr = vma->vm_start;
- unsigned long usize = vma->vm_end - vma->vm_start;
+ unsigned long page_count = vma_pages(vma);
struct page **pages = __iommu_get_pages(cpu_addr, attrs);
unsigned long nr_pages = PAGE_ALIGN(size) >> PAGE_SHIFT;
unsigned long off = vma->vm_pgoff;
+ int err;
if (!pages)
return -ENXIO;
- if (off >= nr_pages || (usize >> PAGE_SHIFT) > nr_pages - off)
+ if (off >= nr_pages || page_count > nr_pages - off)
return -ENXIO;
pages += off;
+ err = vm_insert_range(vma, vma->vm_start, pages, page_count);
+ if (err)
+ pr_err("Remapping memory failed: %d\n", err);
- do {
- int ret = vm_insert_page(vma, uaddr, *pages++);
- if (ret) {
- pr_err("Remapping memory failed: %d\n", ret);
- return ret;
- }
- uaddr += PAGE_SIZE;
- usize -= PAGE_SIZE;
- } while (usize > 0);
-
- return 0;
+ return err;
}
static int arm_iommu_mmap_attrs(struct device *dev,
struct vm_area_struct *vma, void *cpu_addr,
--
1.9.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v3 1/9] mm: Introduce new vm_insert_range API
From: Souptick Joarder @ 2018-12-06 18:39 UTC (permalink / raw)
To: akpm, willy, mhocko, kirill.shutemov, vbabka, riel, sfr, rppt,
peterz, linux, robin.murphy, iamjoonsoo.kim, treding, keescook,
m.szyprowski, stefanr, hjc, heiko, airlied,
oleksandr_andrushchenko, joro, pawel, kyungmin.park, mchehab,
boris.ostrovsky, jgross
Cc: linux-rockchip, linux-kernel, dri-devel, xen-devel, linux-mm,
iommu, linux1394-devel, linux-arm-kernel, linux-media
Previouly drivers have their own way of mapping range of
kernel pages/memory into user vma and this was done by
invoking vm_insert_page() within a loop.
As this pattern is common across different drivers, it can
be generalized by creating a new function and use it across
the drivers.
vm_insert_range is the new API which will be used to map a
range of kernel memory/pages to user vma.
This API is tested by Heiko for Rockchip drm driver, on rk3188,
rk3288, rk3328 and rk3399 with graphics.
Signed-off-by: Souptick Joarder <jrdr.linux@gmail.com>
Reviewed-by: Matthew Wilcox <willy@infradead.org>
Reviewed-by: Mike Rapoport <rppt@linux.ibm.com>
Tested-by: Heiko Stuebner <heiko@sntech.de>
---
include/linux/mm.h | 2 ++
mm/memory.c | 38 ++++++++++++++++++++++++++++++++++++++
mm/nommu.c | 7 +++++++
3 files changed, 47 insertions(+)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index fcf9cc9..2bc399f 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -2506,6 +2506,8 @@ unsigned long change_prot_numa(struct vm_area_struct *vma,
int remap_pfn_range(struct vm_area_struct *, unsigned long addr,
unsigned long pfn, unsigned long size, pgprot_t);
int vm_insert_page(struct vm_area_struct *, unsigned long addr, struct page *);
+int vm_insert_range(struct vm_area_struct *vma, unsigned long addr,
+ struct page **pages, unsigned long page_count);
vm_fault_t vmf_insert_pfn(struct vm_area_struct *vma, unsigned long addr,
unsigned long pfn);
vm_fault_t vmf_insert_pfn_prot(struct vm_area_struct *vma, unsigned long addr,
diff --git a/mm/memory.c b/mm/memory.c
index 15c417e..84ea46c 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -1478,6 +1478,44 @@ static int insert_page(struct vm_area_struct *vma, unsigned long addr,
}
/**
+ * vm_insert_range - insert range of kernel pages into user vma
+ * @vma: user vma to map to
+ * @addr: target user address of this page
+ * @pages: pointer to array of source kernel pages
+ * @page_count: number of pages need to insert into user vma
+ *
+ * This allows drivers to insert range of kernel pages they've allocated
+ * into a user vma. This is a generic function which drivers can use
+ * rather than using their own way of mapping range of kernel pages into
+ * user vma.
+ *
+ * If we fail to insert any page into the vma, the function will return
+ * immediately leaving any previously-inserted pages present. Callers
+ * from the mmap handler may immediately return the error as their caller
+ * will destroy the vma, removing any successfully-inserted pages. Other
+ * callers should make their own arrangements for calling unmap_region().
+ *
+ * Context: Process context. Called by mmap handlers.
+ * Return: 0 on success and error code otherwise
+ */
+int vm_insert_range(struct vm_area_struct *vma, unsigned long addr,
+ struct page **pages, unsigned long page_count)
+{
+ unsigned long uaddr = addr;
+ int ret = 0, i;
+
+ for (i = 0; i < page_count; i++) {
+ ret = vm_insert_page(vma, uaddr, pages[i]);
+ if (ret < 0)
+ return ret;
+ uaddr += PAGE_SIZE;
+ }
+
+ return ret;
+}
+EXPORT_SYMBOL(vm_insert_range);
+
+/**
* vm_insert_page - insert single page into user vma
* @vma: user vma to map to
* @addr: target user address of this page
diff --git a/mm/nommu.c b/mm/nommu.c
index 749276b..d6ef5c7 100644
--- a/mm/nommu.c
+++ b/mm/nommu.c
@@ -473,6 +473,13 @@ int vm_insert_page(struct vm_area_struct *vma, unsigned long addr,
}
EXPORT_SYMBOL(vm_insert_page);
+int vm_insert_range(struct vm_area_struct *vma, unsigned long addr,
+ struct page **pages, unsigned long page_count)
+{
+ return -EINVAL;
+}
+EXPORT_SYMBOL(vm_insert_range);
+
/*
* sys_brk() for the most part doesn't need the global kernel
* lock, except when an application is doing something nasty
--
1.9.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v2 1/3] arm64: dts: qcom: msm8998: correct xo clock name
From: Stephen Boyd @ 2018-12-06 18:34 UTC (permalink / raw)
To: Andy Gross, Bjorn Andersson, Jeffrey Hugo
Cc: MSM, Georgi Djakov, Linux ARM, Marc Gonzalez
In-Reply-To: <cdeb3962-81a2-48dc-9b75-d97a817a0da9@codeaurora.org>
Quoting Jeffrey Hugo (2018-12-05 15:04:01)
> On 12/5/2018 2:42 PM, Stephen Boyd wrote:
> > Quoting Jeffrey Hugo (2018-12-05 13:20:07)
> >> On 12/5/2018 2:04 PM, Stephen Boyd wrote:
> >>> Quoting Jeffrey Hugo (2018-12-05 09:03:54)
> >>>
> >>> I don't quite understand the patch in general. The xo_board clk should
> >>> always exist in DT and the fixed factor clk in GCC is there until the
> >>> rpm clk driver can control the XO clk state vote for the kernel.
> >>
> >> Sorry, this wasn't apparent. It doesn't seem like this "requirement" is
> >> captured anywhere.
> >
> > Agreed!
> >
> >>
> >> As far as the SD clocks are concerned, they are defined in GCC, and
> >> eventually have a root parent called "xo". "xo" isn't defined anywhere,
> >> so the SD clocks can't really be used, and the hardware doesn't come up.
> >> This patch "fixed" that, but I missed the link to the rpm driver that
> >> Marc pointed out.
> >
> > Hmm ok. The SD DT node should just point to the xo_board clk for now and
> > later on it can be changed to use the rpm clk when the rpm node is
> > created.
> >
> >>
> >>
> >>>
> >>> If anything, change the DT node to be named xo-board instead of xo_board
> >>> because that matches DT naming schemes and then add a clock-output-names
> >>> = "xo_board" property to it so that we keep the underscore.
> >>
> >> I see this now, and I agree with it, but then SD goes back to a broken
> >> state because there is "xo" clock for GCC. Its not quite clear to me
> >> how to make GCC (and thus SD) happy again with this change reverted/fixed.
> >>
> >> Bjorn mentioned offline he is going to take a look, but he has a few
> >> other things on his plate first.
> >>
> >
> > There is an XO clk created in drivers/clk/qcom/gcc-msm8996.c, we should
> > do the same here until rpm can handle this. I'll pack this patch up and
> > merge it to clk-next soon.
>
> Thanks. I pulled in the below change into my tree, and fixed up the DT
> based on the discussion we had. SD works, and things look sane to me
> per clk_summary in debugfs.
>
> Feel free to throw my tested-by on if you want.
Thanks. I did so and merged it up to clk-next.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v3 0/9] Use vm_insert_range
From: Souptick Joarder @ 2018-12-06 18:37 UTC (permalink / raw)
To: akpm, willy, mhocko, kirill.shutemov, vbabka, riel, sfr, rppt,
peterz, linux, robin.murphy, iamjoonsoo.kim, treding, keescook,
m.szyprowski, stefanr, hjc, heiko, airlied,
oleksandr_andrushchenko, joro, pawel, kyungmin.park, mchehab,
boris.ostrovsky, jgross
Cc: linux-rockchip, linux-kernel, dri-devel, xen-devel, linux-mm,
iommu, linux1394-devel, linux-arm-kernel, linux-media
Previouly drivers have their own way of mapping range of
kernel pages/memory into user vma and this was done by
invoking vm_insert_page() within a loop.
As this pattern is common across different drivers, it can
be generalized by creating a new function and use it across
the drivers.
vm_insert_range is the new API which will be used to map a
range of kernel memory/pages to user vma.
All the applicable places are converted to use new vm_insert_range
in this patch series.
v1 -> v2:
Address review comment on mm/memory.c. Add EXPORT_SYMBOL
for vm_insert_range and corrected the documentation part
for this API.
In drivers/gpu/drm/xen/xen_drm_front_gem.c, replace err
with ret as suggested.
In drivers/iommu/dma-iommu.c, handle the scenario of partial
mmap() of large buffer by passing *pages + vma->vm_pgoff* to
vm_insert_range().
v2 -> v3:
Declaration of vm_insert_range() moved to include/linux/mm.h
Souptick Joarder (9):
mm: Introduce new vm_insert_range API
arch/arm/mm/dma-mapping.c: Convert to use vm_insert_range
drivers/firewire/core-iso.c: Convert to use vm_insert_range
drm/rockchip/rockchip_drm_gem.c: Convert to use vm_insert_range
drm/xen/xen_drm_front_gem.c: Convert to use vm_insert_range
iommu/dma-iommu.c: Convert to use vm_insert_range
videobuf2/videobuf2-dma-sg.c: Convert to use vm_insert_range
xen/gntdev.c: Convert to use vm_insert_range
xen/privcmd-buf.c: Convert to use vm_insert_range
arch/arm/mm/dma-mapping.c | 21 +++++--------
drivers/firewire/core-iso.c | 15 ++-------
drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 20 ++----------
drivers/gpu/drm/xen/xen_drm_front_gem.c | 20 ++++--------
drivers/iommu/dma-iommu.c | 13 ++------
drivers/media/common/videobuf2/videobuf2-dma-sg.c | 23 +++++---------
drivers/xen/gntdev.c | 11 +++----
drivers/xen/privcmd-buf.c | 8 ++---
include/linux/mm.h | 2 ++
mm/memory.c | 38 +++++++++++++++++++++++
mm/nommu.c | 7 +++++
11 files changed, 80 insertions(+), 98 deletions(-)
--
1.9.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 1/1] stackleak: Register the 'stackleak_cleanup' pass before the '*free_cfg' pass
From: Kees Cook @ 2018-12-06 18:25 UTC (permalink / raw)
To: Alexander Popov
Cc: Mark Rutland, Kernel Hardening, Peter Zijlstra, Richard Sandiford,
Dave Hansen, Will Deacon, Alexei Starovoitov, H. Peter Anvin,
Ingo Molnar, Tycho Andersen, Emese Revfy, Laura Abbott,
Segher Boessenkool, Jann Horn, amonakov, Steven Rostedt,
Borislav Petkov, Andy Lutomirski, Thomas Gleixner,
linux-arm-kernel, Florian Weimer, gcc, Ard Biesheuvel, LKML,
David S. Miller, Masami Hiramatsu, Thomas Garnier
In-Reply-To: <1544109187-13805-1-git-send-email-alex.popov@linux.com>
On Thu, Dec 6, 2018 at 7:13 AM Alexander Popov <alex.popov@linux.com> wrote:
>
> Currently the 'stackleak_cleanup' pass deleting a CALL insn is executed
> after the 'reload' pass. That allows gcc to do some weird optimization in
> function prologues and epilogues, which are generated later [1].
>
> Let's avoid that by registering the 'stackleak_cleanup' pass before
> the '*free_cfg' pass. It's the moment when the stack frame size is
> already final, function prologues and epilogues are generated, and the
> machine-dependent code transformations are not done.
>
> [1] https://www.openwall.com/lists/kernel-hardening/2018/11/23/2
>
> Reported-by: kbuild test robot <lkp@intel.com>
> Signed-off-by: Alexander Popov <alex.popov@linux.com>
Thanks! I've applied this to me tree and I'll send a pull request soon.
-Kees
> ---
> scripts/gcc-plugins/stackleak_plugin.c | 8 +++++---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/scripts/gcc-plugins/stackleak_plugin.c b/scripts/gcc-plugins/stackleak_plugin.c
> index 2f48da9..dbd3746 100644
> --- a/scripts/gcc-plugins/stackleak_plugin.c
> +++ b/scripts/gcc-plugins/stackleak_plugin.c
> @@ -363,10 +363,12 @@ __visible int plugin_init(struct plugin_name_args *plugin_info,
> PASS_POS_INSERT_BEFORE);
>
> /*
> - * The stackleak_cleanup pass should be executed after the
> - * "reload" pass, when the stack frame size is final.
> + * The stackleak_cleanup pass should be executed before the "*free_cfg"
> + * pass. It's the moment when the stack frame size is already final,
> + * function prologues and epilogues are generated, and the
> + * machine-dependent code transformations are not done.
> */
> - PASS_INFO(stackleak_cleanup, "reload", 1, PASS_POS_INSERT_AFTER);
> + PASS_INFO(stackleak_cleanup, "*free_cfg", 1, PASS_POS_INSERT_BEFORE);
>
> if (!plugin_default_version_check(version, &gcc_version)) {
> error(G_("incompatible gcc/plugin versions"));
> --
> 2.7.4
>
--
Kees Cook
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 10/10] staging: bcm2835-camera: Add hint about possible faulty config
From: Stefan Wahren @ 2018-12-06 18:29 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: devel, Stefan Wahren, Takashi Iwai, Eric Anholt, linux-arm-kernel,
Dave Stevenson, Nicolas Saenz Julienne
In-Reply-To: <1544120940-13716-1-git-send-email-stefan.wahren@i2se.com>
As per default the GPU memory config of the Raspberry Pi isn't sufficient
for the camera usage. Even worse the bcm2835 camera driver doesn't provide a
helpful error message in this case. So let's add a hint to point the user
to the likely cause.
Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
Reviewed-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
---
drivers/staging/vc04_services/bcm2835-camera/mmal-vchiq.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/vc04_services/bcm2835-camera/mmal-vchiq.c b/drivers/staging/vc04_services/bcm2835-camera/mmal-vchiq.c
index cc2d993..bffd75d 100644
--- a/drivers/staging/vc04_services/bcm2835-camera/mmal-vchiq.c
+++ b/drivers/staging/vc04_services/bcm2835-camera/mmal-vchiq.c
@@ -1623,8 +1623,11 @@ int vchiq_mmal_component_init(struct vchiq_mmal_instance *instance,
component = &instance->component[instance->component_idx];
ret = create_component(instance, component, name);
- if (ret < 0)
+ if (ret < 0) {
+ pr_err("%s: failed to create component %d (Not enough GPU mem?)\n",
+ __func__, ret);
goto unlock;
+ }
/* ports info needs gathering */
component->control.type = MMAL_PORT_TYPE_CONTROL;
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 00/10] staging: vc04_services: Improve driver load/unload
From: Stefan Wahren @ 2018-12-06 18:28 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: devel, Stefan Wahren, Takashi Iwai, Eric Anholt, linux-arm-kernel,
Dave Stevenson, Nicolas Saenz Julienne
This patch series improves the load/unload of bcm2835 camera and audio
drivers.
Changes since RFC:
- rebase on current staging-next
- add Nicolas' reviewed-by
- address Dan Carpenter's comments about error handling of device registration
Stefan Wahren (10):
staging: bcm2835-camera: Abort probe if there is no camera
staging: bcm2835-camera: fix module autoloading
staging: bcm2835-camera: Move module info to the end
staging: vchiq_arm: Fix camera device registration
staging: vchiq_arm: Register a platform device for audio
staging: bcm2835-audio: Enable compile test
staging: bcm2835-audio: use module_platform_driver() macro
staging: bcm2835-audio: Drop DT dependency
staging: bcm2835-camera: Provide more specific probe error messages
staging: bcm2835-camera: Add hint about possible faulty config
.../staging/vc04_services/bcm2835-audio/Kconfig | 2 +-
.../staging/vc04_services/bcm2835-audio/bcm2835.c | 51 +++-----------
.../vc04_services/bcm2835-camera/bcm2835-camera.c | 78 +++++++++++++++-------
.../vc04_services/bcm2835-camera/mmal-vchiq.c | 5 +-
.../vc04_services/interface/vchiq_arm/vchiq_arm.c | 29 +++++++-
5 files changed, 95 insertions(+), 70 deletions(-)
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 03/10] staging: bcm2835-camera: Move module info to the end
From: Stefan Wahren @ 2018-12-06 18:28 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: devel, Stefan Wahren, Takashi Iwai, Eric Anholt, linux-arm-kernel,
Dave Stevenson, Nicolas Saenz Julienne
In-Reply-To: <1544120940-13716-1-git-send-email-stefan.wahren@i2se.com>
In order to have this more consistent between the vc04 services move
the module information to the end of the file.
Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
Reviewed-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
---
.../staging/vc04_services/bcm2835-camera/bcm2835-camera.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.c b/drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.c
index 7d3222c..cd773eb 100644
--- a/drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.c
+++ b/drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.c
@@ -43,12 +43,6 @@
#define MAX_BCM2835_CAMERAS 2
-MODULE_DESCRIPTION("Broadcom 2835 MMAL video capture");
-MODULE_AUTHOR("Vincent Sanders");
-MODULE_LICENSE("GPL");
-MODULE_VERSION(BM2835_MMAL_VERSION);
-MODULE_ALIAS("platform:bcm2835-camera");
-
int bcm2835_v4l2_debug;
module_param_named(debug, bcm2835_v4l2_debug, int, 0644);
MODULE_PARM_DESC(bcm2835_v4l2_debug, "Debug level 0-2");
@@ -1976,3 +1970,9 @@ static struct platform_driver bcm2835_camera_driver = {
};
module_platform_driver(bcm2835_camera_driver)
+
+MODULE_DESCRIPTION("Broadcom 2835 MMAL video capture");
+MODULE_AUTHOR("Vincent Sanders");
+MODULE_LICENSE("GPL");
+MODULE_VERSION(BM2835_MMAL_VERSION);
+MODULE_ALIAS("platform:bcm2835-camera");
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 09/10] staging: bcm2835-camera: Provide more specific probe error messages
From: Stefan Wahren @ 2018-12-06 18:28 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: devel, Stefan Wahren, Takashi Iwai, Eric Anholt, linux-arm-kernel,
Dave Stevenson, Nicolas Saenz Julienne
In-Reply-To: <1544120940-13716-1-git-send-email-stefan.wahren@i2se.com>
Currently there is only a catch-all info message which print the
relevant error code without any context. So add more specific error
messages in order to narrow down possible issues.
Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
Reviewed-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
---
.../vc04_services/bcm2835-camera/bcm2835-camera.c | 58 +++++++++++++++-------
1 file changed, 39 insertions(+), 19 deletions(-)
diff --git a/drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.c b/drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.c
index cd773eb..611a6ee 100644
--- a/drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.c
+++ b/drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.c
@@ -1539,8 +1539,11 @@ static int mmal_init(struct bm2835_mmal_dev *dev)
struct vchiq_mmal_component *camera;
ret = vchiq_mmal_init(&dev->instance);
- if (ret < 0)
+ if (ret < 0) {
+ v4l2_err(&dev->v4l2_dev, "%s: vchiq mmal init failed %d\n",
+ __func__, ret);
return ret;
+ }
/* get the camera component ready */
ret = vchiq_mmal_component_init(dev->instance, "ril.camera",
@@ -1549,7 +1552,9 @@ static int mmal_init(struct bm2835_mmal_dev *dev)
goto unreg_mmal;
camera = dev->component[MMAL_COMPONENT_CAMERA];
- if (camera->outputs < MMAL_CAMERA_PORT_COUNT) {
+ if (camera->outputs < MMAL_CAMERA_PORT_COUNT) {
+ v4l2_err(&dev->v4l2_dev, "%s: too few camera outputs %d needed %d\n",
+ __func__, camera->outputs, MMAL_CAMERA_PORT_COUNT);
ret = -EINVAL;
goto unreg_camera;
}
@@ -1557,8 +1562,11 @@ static int mmal_init(struct bm2835_mmal_dev *dev)
ret = set_camera_parameters(dev->instance,
camera,
dev);
- if (ret < 0)
+ if (ret < 0) {
+ v4l2_err(&dev->v4l2_dev, "%s: unable to set camera parameters: %d\n",
+ __func__, ret);
goto unreg_camera;
+ }
/* There was an error in the firmware that meant the camera component
* produced BGR instead of RGB.
@@ -1647,8 +1655,8 @@ static int mmal_init(struct bm2835_mmal_dev *dev)
if (dev->component[MMAL_COMPONENT_PREVIEW]->inputs < 1) {
ret = -EINVAL;
- pr_debug("too few input ports %d needed %d\n",
- dev->component[MMAL_COMPONENT_PREVIEW]->inputs, 1);
+ v4l2_err(&dev->v4l2_dev, "%s: too few input ports %d needed %d\n",
+ __func__, dev->component[MMAL_COMPONENT_PREVIEW]->inputs, 1);
goto unreg_preview;
}
@@ -1661,8 +1669,8 @@ static int mmal_init(struct bm2835_mmal_dev *dev)
if (dev->component[MMAL_COMPONENT_IMAGE_ENCODE]->inputs < 1) {
ret = -EINVAL;
- v4l2_err(&dev->v4l2_dev, "too few input ports %d needed %d\n",
- dev->component[MMAL_COMPONENT_IMAGE_ENCODE]->inputs,
+ v4l2_err(&dev->v4l2_dev, "%s: too few input ports %d needed %d\n",
+ __func__, dev->component[MMAL_COMPONENT_IMAGE_ENCODE]->inputs,
1);
goto unreg_image_encoder;
}
@@ -1676,8 +1684,8 @@ static int mmal_init(struct bm2835_mmal_dev *dev)
if (dev->component[MMAL_COMPONENT_VIDEO_ENCODE]->inputs < 1) {
ret = -EINVAL;
- v4l2_err(&dev->v4l2_dev, "too few input ports %d needed %d\n",
- dev->component[MMAL_COMPONENT_VIDEO_ENCODE]->inputs,
+ v4l2_err(&dev->v4l2_dev, "%s: too few input ports %d needed %d\n",
+ __func__, dev->component[MMAL_COMPONENT_VIDEO_ENCODE]->inputs,
1);
goto unreg_vid_encoder;
}
@@ -1706,8 +1714,11 @@ static int mmal_init(struct bm2835_mmal_dev *dev)
sizeof(enable));
}
ret = bm2835_mmal_set_all_camera_controls(dev);
- if (ret < 0)
+ if (ret < 0) {
+ v4l2_err(&dev->v4l2_dev, "%s: failed to set all camera controls: %d\n",
+ __func__, ret);
goto unreg_vid_encoder;
+ }
return 0;
@@ -1873,21 +1884,29 @@ static int bcm2835_mmal_probe(struct platform_device *pdev)
snprintf(dev->v4l2_dev.name, sizeof(dev->v4l2_dev.name),
"%s", BM2835_MMAL_MODULE_NAME);
ret = v4l2_device_register(NULL, &dev->v4l2_dev);
- if (ret)
+ if (ret) {
+ dev_err(&pdev->dev, "%s: could not register V4L2 device: %d\n",
+ __func__, ret);
goto free_dev;
+ }
/* setup v4l controls */
ret = bm2835_mmal_init_controls(dev, &dev->ctrl_handler);
- if (ret < 0)
+ if (ret < 0) {
+ v4l2_err(&dev->v4l2_dev, "%s: could not init controls: %d\n",
+ __func__, ret);
goto unreg_dev;
+ }
dev->v4l2_dev.ctrl_handler = &dev->ctrl_handler;
/* mmal init */
dev->instance = instance;
ret = mmal_init(dev);
- if (ret < 0)
+ if (ret < 0) {
+ v4l2_err(&dev->v4l2_dev, "%s: mmal init failed: %d\n",
+ __func__, ret);
goto unreg_dev;
-
+ }
/* initialize queue */
q = &dev->capture.vb_vidq;
memset(q, 0, sizeof(*q));
@@ -1905,16 +1924,19 @@ static int bcm2835_mmal_probe(struct platform_device *pdev)
/* initialise video devices */
ret = bm2835_mmal_init_device(dev, &dev->vdev);
- if (ret < 0)
+ if (ret < 0) {
+ v4l2_err(&dev->v4l2_dev, "%s: could not init device: %d\n",
+ __func__, ret);
goto unreg_dev;
+ }
/* Really want to call vidioc_s_fmt_vid_cap with the default
* format, but currently the APIs don't join up.
*/
ret = mmal_setup_components(dev, &default_v4l2_format);
if (ret < 0) {
- v4l2_err(&dev->v4l2_dev,
- "%s: could not setup components\n", __func__);
+ v4l2_err(&dev->v4l2_dev, "%s: could not setup components: %d\n",
+ __func__, ret);
goto unreg_dev;
}
@@ -1938,8 +1960,6 @@ static int bcm2835_mmal_probe(struct platform_device *pdev)
bcm2835_cleanup_instance(gdev[i]);
gdev[i] = NULL;
}
- pr_info("%s: error %d while loading driver\n",
- BM2835_MMAL_MODULE_NAME, ret);
cleanup_mmal:
vchiq_mmal_finalise(instance);
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 06/10] staging: bcm2835-audio: Enable compile test
From: Stefan Wahren @ 2018-12-06 18:28 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: devel, Stefan Wahren, Takashi Iwai, Eric Anholt, linux-arm-kernel,
Dave Stevenson, Nicolas Saenz Julienne
In-Reply-To: <1544120940-13716-1-git-send-email-stefan.wahren@i2se.com>
Enable the compilation test for bcm2835-audio to gain more build coverage.
Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
Reviewed-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
---
drivers/staging/vc04_services/bcm2835-audio/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/vc04_services/bcm2835-audio/Kconfig b/drivers/staging/vc04_services/bcm2835-audio/Kconfig
index 9f53653..62c1c8b 100644
--- a/drivers/staging/vc04_services/bcm2835-audio/Kconfig
+++ b/drivers/staging/vc04_services/bcm2835-audio/Kconfig
@@ -1,6 +1,6 @@
config SND_BCM2835
tristate "BCM2835 Audio"
- depends on ARCH_BCM2835 && SND
+ depends on (ARCH_BCM2835 || COMPILE_TEST) && SND
select SND_PCM
select BCM2835_VCHIQ
help
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 05/10] staging: vchiq_arm: Register a platform device for audio
From: Stefan Wahren @ 2018-12-06 18:28 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: devel, Stefan Wahren, Takashi Iwai, Eric Anholt, linux-arm-kernel,
Dave Stevenson, Nicolas Saenz Julienne
In-Reply-To: <1544120940-13716-1-git-send-email-stefan.wahren@i2se.com>
Following Eric's commit 37b7b3087a2f ("staging/vc04_services: Register a
platform device for the camera driver.") this register the audio driver as
a platform device, too.
Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
---
drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
index f2c1dcd..b6cd0ed 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
@@ -167,6 +167,7 @@ static VCHIQ_STATE_T g_state;
static struct class *vchiq_class;
static DEFINE_SPINLOCK(msg_queue_spinlock);
static struct platform_device *bcm2835_camera;
+static struct platform_device *bcm2835_audio;
static struct vchiq_drvdata bcm2835_drvdata = {
.cache_line_size = 32,
@@ -3553,6 +3554,7 @@ static int vchiq_probe(struct platform_device *pdev)
MAJOR(vchiq_devid), MINOR(vchiq_devid));
bcm2835_camera = vchiq_register_child(pdev, "bcm2835-camera");
+ bcm2835_audio = vchiq_register_child(pdev, "bcm2835_audio");
return 0;
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 08/10] staging: bcm2835-audio: Drop DT dependency
From: Stefan Wahren @ 2018-12-06 18:28 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: devel, Stefan Wahren, Takashi Iwai, Eric Anholt, linux-arm-kernel,
Dave Stevenson, Nicolas Saenz Julienne
In-Reply-To: <1544120940-13716-1-git-send-email-stefan.wahren@i2se.com>
Just like the bcm2835-video make this a platform driver which is probed
by vchiq. In order to change the number of channels use a module
parameter instead, but use the maximum as default.
Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
Reviewed-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
---
.../staging/vc04_services/bcm2835-audio/bcm2835.c | 31 +++++++---------------
1 file changed, 9 insertions(+), 22 deletions(-)
diff --git a/drivers/staging/vc04_services/bcm2835-audio/bcm2835.c b/drivers/staging/vc04_services/bcm2835-audio/bcm2835.c
index 86b9210..cf5f80f 100644
--- a/drivers/staging/vc04_services/bcm2835-audio/bcm2835.c
+++ b/drivers/staging/vc04_services/bcm2835-audio/bcm2835.c
@@ -6,13 +6,13 @@
#include <linux/init.h>
#include <linux/slab.h>
#include <linux/module.h>
-#include <linux/of.h>
#include "bcm2835.h"
static bool enable_hdmi;
static bool enable_headphones;
static bool enable_compat_alsa = true;
+static int num_channels = MAX_SUBSTREAMS;
module_param(enable_hdmi, bool, 0444);
MODULE_PARM_DESC(enable_hdmi, "Enables HDMI virtual audio device");
@@ -21,6 +21,8 @@ MODULE_PARM_DESC(enable_headphones, "Enables Headphones virtual audio device");
module_param(enable_compat_alsa, bool, 0444);
MODULE_PARM_DESC(enable_compat_alsa,
"Enables ALSA compatibility virtual audio device");
+module_param(num_channels, int, 0644);
+MODULE_PARM_DESC(num_channels, "Number of audio channels (default: 8)");
static void bcm2835_devm_free_vchi_ctx(struct device *dev, void *res)
{
@@ -294,28 +296,19 @@ static int snd_add_child_devices(struct device *device, u32 numchans)
static int snd_bcm2835_alsa_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
- u32 numchans;
int err;
- err = of_property_read_u32(dev->of_node, "brcm,pwm-channels",
- &numchans);
- if (err) {
- dev_err(dev, "Failed to get DT property 'brcm,pwm-channels'");
- return err;
- }
-
- if (numchans == 0 || numchans > MAX_SUBSTREAMS) {
- numchans = MAX_SUBSTREAMS;
- dev_warn(dev,
- "Illegal 'brcm,pwm-channels' value, will use %u\n",
- numchans);
+ if (num_channels <= 0 || num_channels > MAX_SUBSTREAMS) {
+ num_channels = MAX_SUBSTREAMS;
+ dev_warn(dev, "Illegal num_channels value, will use %u\n",
+ num_channels);
}
err = bcm2835_devm_add_vchi_ctx(dev);
if (err)
return err;
- err = snd_add_child_devices(dev, numchans);
+ err = snd_add_child_devices(dev, num_channels);
if (err)
return err;
@@ -337,12 +330,6 @@ static int snd_bcm2835_alsa_resume(struct platform_device *pdev)
#endif
-static const struct of_device_id snd_bcm2835_of_match_table[] = {
- { .compatible = "brcm,bcm2835-audio",},
- {},
-};
-MODULE_DEVICE_TABLE(of, snd_bcm2835_of_match_table);
-
static struct platform_driver bcm2835_alsa_driver = {
.probe = snd_bcm2835_alsa_probe,
#ifdef CONFIG_PM
@@ -351,7 +338,6 @@ static struct platform_driver bcm2835_alsa_driver = {
#endif
.driver = {
.name = "bcm2835_audio",
- .of_match_table = snd_bcm2835_of_match_table,
},
};
module_platform_driver(bcm2835_alsa_driver);
@@ -359,3 +345,4 @@ module_platform_driver(bcm2835_alsa_driver);
MODULE_AUTHOR("Dom Cobley");
MODULE_DESCRIPTION("Alsa driver for BCM2835 chip");
MODULE_LICENSE("GPL");
+MODULE_ALIAS("platform:bcm2835_audio");
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 02/10] staging: bcm2835-camera: fix module autoloading
From: Stefan Wahren @ 2018-12-06 18:28 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: devel, Stefan Wahren, Takashi Iwai, Eric Anholt, linux-arm-kernel,
Dave Stevenson, Nicolas Saenz Julienne
In-Reply-To: <1544120940-13716-1-git-send-email-stefan.wahren@i2se.com>
In order to make the module bcm2835-camera load automatically, we need to
add a module alias.
Fixes: 4bebb0312ea9 ("staging/bcm2835-camera: Set ourselves up as a platform driver.")
Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
Reviewed-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
---
drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.c b/drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.c
index d6fbef7..7d3222c 100644
--- a/drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.c
+++ b/drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.c
@@ -47,6 +47,7 @@ MODULE_DESCRIPTION("Broadcom 2835 MMAL video capture");
MODULE_AUTHOR("Vincent Sanders");
MODULE_LICENSE("GPL");
MODULE_VERSION(BM2835_MMAL_VERSION);
+MODULE_ALIAS("platform:bcm2835-camera");
int bcm2835_v4l2_debug;
module_param_named(debug, bcm2835_v4l2_debug, int, 0644);
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 04/10] staging: vchiq_arm: Fix camera device registration
From: Stefan Wahren @ 2018-12-06 18:28 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: devel, Stefan Wahren, Takashi Iwai, Eric Anholt, linux-arm-kernel,
Dave Stevenson, Nicolas Saenz Julienne
In-Reply-To: <1544120940-13716-1-git-send-email-stefan.wahren@i2se.com>
Since the camera driver isn't probed via DT, we need to properly setup DMA.
Fixes: 37b7b3087a2f ("staging/vc04_services: Register a platform device for the camera driver.")
Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
---
.../vc04_services/interface/vchiq_arm/vchiq_arm.c | 27 +++++++++++++++++++---
1 file changed, 24 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
index 0caee2d..f2c1dcd 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
@@ -49,6 +49,7 @@
#include <linux/of.h>
#include <linux/platform_device.h>
#include <linux/compat.h>
+#include <linux/dma-mapping.h>
#include <soc/bcm2835/raspberrypi-firmware.h>
#include "vchiq_core.h"
@@ -3479,6 +3480,28 @@ static const struct of_device_id vchiq_of_match[] = {
};
MODULE_DEVICE_TABLE(of, vchiq_of_match);
+static struct platform_device *
+vchiq_register_child(struct platform_device *pdev, const char *name)
+{
+ struct platform_device_info pdevinfo;
+ struct platform_device *child;
+
+ memset(&pdevinfo, 0, sizeof(pdevinfo));
+
+ pdevinfo.parent = &pdev->dev;
+ pdevinfo.name = name;
+ pdevinfo.id = PLATFORM_DEVID_NONE;
+ pdevinfo.dma_mask = DMA_BIT_MASK(32);
+
+ child = platform_device_register_full(&pdevinfo);
+ if (IS_ERR(child)) {
+ dev_warn(&pdev->dev, "%s not registered\n", name);
+ child = NULL;
+ }
+
+ return child;
+}
+
static int vchiq_probe(struct platform_device *pdev)
{
struct device_node *fw_node;
@@ -3529,9 +3552,7 @@ static int vchiq_probe(struct platform_device *pdev)
VCHIQ_VERSION, VCHIQ_VERSION_MIN,
MAJOR(vchiq_devid), MINOR(vchiq_devid));
- bcm2835_camera = platform_device_register_data(&pdev->dev,
- "bcm2835-camera", -1,
- NULL, 0);
+ bcm2835_camera = vchiq_register_child(pdev, "bcm2835-camera");
return 0;
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 01/10] staging: bcm2835-camera: Abort probe if there is no camera
From: Stefan Wahren @ 2018-12-06 18:28 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: devel, Stefan Wahren, Takashi Iwai, Eric Anholt, linux-arm-kernel,
Dave Stevenson, Nicolas Saenz Julienne
In-Reply-To: <1544120940-13716-1-git-send-email-stefan.wahren@i2se.com>
Abort the probing of the camera driver in case there isn't a camera
actually connected to the Raspberry Pi. This solution also avoids a
NULL ptr dereference of mmal instance on driver unload.
Fixes: 7b3ad5abf027 ("staging: Import the BCM2835 MMAL-based V4L2 camera driver.")
Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
Reviewed-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
---
drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.c b/drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.c
index c04bdf0..d6fbef7 100644
--- a/drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.c
+++ b/drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.c
@@ -1841,6 +1841,12 @@ static int bcm2835_mmal_probe(struct platform_device *pdev)
num_cameras = get_num_cameras(instance,
resolutions,
MAX_BCM2835_CAMERAS);
+
+ if (num_cameras < 1) {
+ ret = -ENODEV;
+ goto cleanup_mmal;
+ }
+
if (num_cameras > MAX_BCM2835_CAMERAS)
num_cameras = MAX_BCM2835_CAMERAS;
@@ -1940,6 +1946,9 @@ static int bcm2835_mmal_probe(struct platform_device *pdev)
pr_info("%s: error %d while loading driver\n",
BM2835_MMAL_MODULE_NAME, ret);
+cleanup_mmal:
+ vchiq_mmal_finalise(instance);
+
return ret;
}
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 07/10] staging: bcm2835-audio: use module_platform_driver() macro
From: Stefan Wahren @ 2018-12-06 18:28 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: devel, Stefan Wahren, Takashi Iwai, Eric Anholt, linux-arm-kernel,
Dave Stevenson, Nicolas Saenz Julienne
In-Reply-To: <1544120940-13716-1-git-send-email-stefan.wahren@i2se.com>
There is not much value behind this boilerplate, so use
module_platform_driver() instead.
Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
Reviewed-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
---
.../staging/vc04_services/bcm2835-audio/bcm2835.c | 20 +-------------------
1 file changed, 1 insertion(+), 19 deletions(-)
diff --git a/drivers/staging/vc04_services/bcm2835-audio/bcm2835.c b/drivers/staging/vc04_services/bcm2835-audio/bcm2835.c
index e14b7c5..86b9210 100644
--- a/drivers/staging/vc04_services/bcm2835-audio/bcm2835.c
+++ b/drivers/staging/vc04_services/bcm2835-audio/bcm2835.c
@@ -354,25 +354,7 @@ static struct platform_driver bcm2835_alsa_driver = {
.of_match_table = snd_bcm2835_of_match_table,
},
};
-
-static int bcm2835_alsa_device_init(void)
-{
- int retval;
-
- retval = platform_driver_register(&bcm2835_alsa_driver);
- if (retval)
- pr_err("Error registering bcm2835_audio driver %d .\n", retval);
-
- return retval;
-}
-
-static void bcm2835_alsa_device_exit(void)
-{
- platform_driver_unregister(&bcm2835_alsa_driver);
-}
-
-late_initcall(bcm2835_alsa_device_init);
-module_exit(bcm2835_alsa_device_exit);
+module_platform_driver(bcm2835_alsa_driver);
MODULE_AUTHOR("Dom Cobley");
MODULE_DESCRIPTION("Alsa driver for BCM2835 chip");
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v2 2/2] arm64: uaccess: Implement unsafe accessors
From: Catalin Marinas @ 2018-12-06 18:25 UTC (permalink / raw)
To: Julien Thierry
Cc: peterz, will.deacon, linux-kernel, mingo, james.morse, hpa,
linux-arm-kernel
In-Reply-To: <1543845318-24543-3-git-send-email-julien.thierry@arm.com>
On Mon, Dec 03, 2018 at 01:55:18PM +0000, Julien Thierry wrote:
> diff --git a/arch/arm64/include/asm/uaccess.h b/arch/arm64/include/asm/uaccess.h
> index 07c3408..cabfcae 100644
> --- a/arch/arm64/include/asm/uaccess.h
> +++ b/arch/arm64/include/asm/uaccess.h
> @@ -233,6 +233,23 @@ static inline void uaccess_enable_not_uao(void)
> __uaccess_enable(ARM64_ALT_PAN_NOT_UAO);
> }
>
> +#define unsafe_user_region_active uaccess_region_active
> +static inline bool uaccess_region_active(void)
> +{
> + if (system_uses_ttbr0_pan()) {
> + u64 ttbr;
> +
> + ttbr = read_sysreg(ttbr1_el1);
> + return ttbr & TTBR_ASID_MASK;
Nitpick: could write this in 1-2 lines.
> + } else if (cpus_have_const_cap(ARM64_ALT_PAN_NOT_UAO)) {
> + return (read_sysreg(sctlr_el1) & SCTLR_EL1_SPAN) ?
> + false :
> + !read_sysreg_s(SYS_PSTATE_PAN);
> + }
ARM64_ALT_PAN_NOT_UAO implies ARM64_HAS_PAN which implies SCTLR_EL1.SPAN
is 0 at run-time. Is this to cope with the case of being called prior to
cpu_enable_pan()?
--
Catalin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 5/6] arch: simplify several early memory allocations
From: Sam Ravnborg @ 2018-12-06 18:08 UTC (permalink / raw)
To: Mike Rapoport
Cc: Michal Hocko, linux-sh, Benjamin Herrenschmidt, linux-mm,
Rich Felker, Paul Mackerras, sparclinux, Vincent Chen, Jonas Bonn,
linux-c6x-dev, Yoshinori Sato, Michael Ellerman, Russell King,
Mark Salter, Arnd Bergmann, Stefan Kristiansson, openrisc,
Greentime Hu, Stafford Horne, Guan Xuetao, linux-arm-kernel,
Michal Simek, linux-kernel, Andrew Morton, linuxppc-dev,
David S. Miller
In-Reply-To: <20181203164920.GB26700@rapoport-lnx>
On Mon, Dec 03, 2018 at 06:49:21PM +0200, Mike Rapoport wrote:
> On Mon, Dec 03, 2018 at 05:29:08PM +0100, Sam Ravnborg wrote:
> > Hi Mike.
> >
> > > index c37955d..2a17665 100644
> > > --- a/arch/sparc/kernel/prom_64.c
> > > +++ b/arch/sparc/kernel/prom_64.c
> > > @@ -34,16 +34,13 @@
> > >
> > > void * __init prom_early_alloc(unsigned long size)
> > > {
> > > - unsigned long paddr = memblock_phys_alloc(size, SMP_CACHE_BYTES);
> > > - void *ret;
> > > + void *ret = memblock_alloc(size, SMP_CACHE_BYTES);
> > >
> > > - if (!paddr) {
> > > + if (!ret) {
> > > prom_printf("prom_early_alloc(%lu) failed\n", size);
> > > prom_halt();
> > > }
> > >
> > > - ret = __va(paddr);
> > > - memset(ret, 0, size);
> > > prom_early_allocated += size;
> > >
> > > return ret;
> >
> > memblock_alloc() calls memblock_alloc_try_nid().
> > And if allocation fails then memblock_alloc_try_nid() calls panic().
> > So will we ever hit the prom_halt() code?
>
> memblock_phys_alloc_try_nid() also calls panic if an allocation fails. So
> in either case we never reach prom_halt() code.
So we have code here we never reach - not nice.
If the idea is to avoid relying on the panic inside memblock_alloc() then
maybe replace it with a variant that do not call panic?
To make it clear what happens.
Sam
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: OMAP4430 SDP with KS8851: very slow networking
From: Russell King - ARM Linux @ 2018-12-06 18:08 UTC (permalink / raw)
To: Tony Lindgren; +Cc: netdev, linux-omap, linux-arm-kernel
In-Reply-To: <20181206163154.GK6707@atomide.com>
On Thu, Dec 06, 2018 at 08:31:54AM -0800, Tony Lindgren wrote:
> Hi,
>
> * Russell King - ARM Linux <linux@armlinux.org.uk> [181206 13:23]:
> > It looks very much like a receive problem - in that the board is not
> > always aware of a packet having been received until it attempts to
> > transmit (eg, in the case of TFTP, when it re-sends the ACK after a
> > receive timeout, it _then_ notices that there's a packet waiting.)
> >
> > I'm not quite sure when this cropped up as I no longer regularly
> > update and run my nightly boot tests, but I think 4.18 was fine.
>
> Sounds like it's some gpio or PM related issue. If it's not caused
> by commit b764a5863fd8 ("gpio: omap: Remove custom PM calls and
> use cpu_pm instead"), then maybe the changes to probe devices
> with ti-sysc interconnect target module driver caused it. Below
> is a revert for mcspi that would help in that case.
In the interests of keeping the mailing list record up to date, with
the following:
850d434ea37b ("gpio: omap: Remove set but not used variable 'dev'")
c4791bc6e3a6 ("gpio: omap: drop omap_gpio_list")
467480738d0b ("gpio: omap: get rid of the conditional PM runtime calls")
5284521a290e ("gpio: omap: Get rid of pm_runtime_irq_safe()")
b764a5863fd8 ("gpio: omap: Remove custom PM calls and use cpu_pm instead")
reverted, the problem is still there. Revert:
ec0daae685b2 ("gpio: omap: Add level wakeup handling for omap4 based SoCs")
on top, and networking returns to normal. So it appears to be this
last commit causing the issue.
With that and b764a5863fd8 applied, it still misbehaves. Then, poking
at the OMAP4_GPIO_IRQWAKEN0 register, changing it from 0 to 4 with
devmem2 restores normal behaviour - ping times are normal and NFS is
happy.
# devmem2 0x48055044 w 4
(slightly more complex for me as its via NFS and needs different C
libraries from the ones on the rootfs.)
Given that this GPIO device is not runtime suspended, and is
permanently active (which is what I think we expect, given that it
has an IRQ claimed against it) does the hardware still attempt to
idle the GPIO block - if so, could that be why we need to program
the wakeup register, so the GPIO block signals that it's active?
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/2] mips/kgdb: prepare arch_kgdb_ops for constness
From: Paul Burton @ 2018-12-06 18:05 UTC (permalink / raw)
To: Daniel Thompson
Cc: Rich Felker, Gustavo A. R. Silva, Benjamin Herrenschmidt,
Will Deacon, linux-kernel@vger.kernel.org, Paul Mackerras,
sparclinux@vger.kernel.org, linux-hexagon@vger.kernel.org,
Yoshinori Sato, linux-sh@vger.kernel.org, Michael Ellerman,
x86@kernel.org, Russell King, Ingo Molnar, Catalin Marinas,
James Hogan, linux-snps-arc@lists.infradead.org,
uclinux-h8-devel@lists.sourceforge.jp, linux-mips@vger.kernel.org,
Borislav Petkov, nios2-dev@lists.rocketboards.org,
Thomas Gleixner, linux-arm-kernel@lists.infradead.org,
Christophe Leroy, Michal Simek, Vineet Gupta, Randy Dunlap,
Douglas Anderson, Ralf Baechle, Richard Kuo, Jason Wessel,
kgdb-bugreport@lists.sourceforge.net, Ley Foon Tan,
linuxppc-dev@lists.ozlabs.org, David S. Miller
In-Reply-To: <20181206140902.ea6jlwqrbcwyxp5r@holly.lan>
Hi Christophe & Daniel,
On Thu, Dec 06, 2018 at 02:09:02PM +0000, Daniel Thompson wrote:
> On Wed, Dec 05, 2018 at 04:41:09AM +0000, Christophe Leroy wrote:
> > MIPS is the only architecture modifying arch_kgdb_ops during init.
> > This patch makes the init static, so that it can be changed to
> > const in following patch, as recommended by checkpatch.pl
> >
> > Suggested-by: Paul Burton <paul.burton@mips.com>
> > Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
>
> From my side this is
> Acked-by: Daniel Thompson <daniel.thompson@linaro.org>
>
> Since this is a dependency for the next patch I'd be happy to take via
> my tree... but would need an ack from the MIPS guys to do that.
For both patches in this series:
Acked-by: Paul Burton <paul.burton@mips.com>
Thanks,
Paul
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/2] mm/sparse: add common helper to mark all memblocks present
From: Logan Gunthorpe @ 2018-12-06 17:40 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-arch, Albert Ou, Arnd Bergmann, linux-sh, Palmer Dabbelt,
linux-kernel, Stephen Bates, linux-mm, Michal Hocko,
Vlastimil Babka, linux-riscv, Christoph Hellwig, linux-arm-kernel,
Oscar Salvador
In-Reply-To: <20181107121207.62cb37cf58484b7cc80a8fd8@linux-foundation.org>
Hey Andrew,
On 2018-11-07 1:12 p.m., Andrew Morton wrote:
> Acked-by: Andrew Morton <akpm@linux-foundation.org>
>
> I can grab both patches and shall sneak them into 4.20-rcX, but feel
> free to merge them into some git tree if you'd prefer. If I see them
> turn up in linux-next I shall drop my copy.
Just wanted to check if you are still planning to get these patches into
4.20-rcX. It would really help us if you can do this seeing we then
won't have to delay a cycle and can target the riscv sparsemem code for
4.21.
Thanks,
Logan
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ 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