* [PATCH 0/5] provide the XTAL clock via OF on Meson8/8b/8m2
From: Martin Blumenstingl @ 2019-09-21 15:12 UTC (permalink / raw)
To: narmstrong, jbrunet, robh+dt, mark.rutland, linux-amlogic,
devicetree, khilman
Cc: Martin Blumenstingl, linux-kernel, linux-arm-kernel, linux-clk
So far the HHI clock controller has been providing the XTAL clock on
Amlogic Meson8/Meson8b/Meson8m2 SoCs.
This is not correct because the XTAL is actually a crystal on the
boards and the SoC has a dedicated input for it.
This updates the dt-bindings of the HHI clock controller and defines
a fixed-clock in meson.dtsi (along with switching everything over to
use this clock).
The clock driver needs three updates to use this:
- patch #2 uses clk_hw_set_parent in the CPU clock notifier. This drops
the explicit reference to CLKID_XTAL while at the same time making
the code much easier (thanks to Neil for providing this new method
as part of the G12A CPU clock bringup!)
- patch #3 ensures that the clock driver doesn't rely on it's internal
XTAL clock while not losing support for older .dtbs that don't have
the XTAL clock input yet
- with patch #4 the clock controller's own XTAL clock is not registered
anymore when a clock input is provided via OF
This series is a functional no-op. It's main goal is to better represent
how the actual hardware looks like.
Martin Blumenstingl (5):
dt-bindings: clock: meson8b: add the clock inputs
clk: meson: meson8b: use clk_hw_set_parent in the CPU clock notifier
clk: meson: meson8b: change references to the XTAL clock to use the
name
clk: meson: meson8b: don't register the XTAL clock when provided via
OF
ARM: dts: meson: provide the XTAL clock using a fixed-clock
.../bindings/clock/amlogic,meson8b-clkc.txt | 5 +
arch/arm/boot/dts/meson.dtsi | 7 ++
arch/arm/boot/dts/meson6.dtsi | 7 --
arch/arm/boot/dts/meson8.dtsi | 15 +--
arch/arm/boot/dts/meson8b-ec100.dts | 2 +-
arch/arm/boot/dts/meson8b-mxq.dts | 2 +-
arch/arm/boot/dts/meson8b-odroidc1.dts | 2 +-
arch/arm/boot/dts/meson8b.dtsi | 15 +--
drivers/clk/meson/meson8b.c | 106 +++++++++---------
9 files changed, 87 insertions(+), 74 deletions(-)
--
2.23.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 1/1] clk: meson: gxbb: let sar_adc_clk_div set the parent clock rate
From: Martin Blumenstingl @ 2019-09-21 15:04 UTC (permalink / raw)
To: narmstrong, jbrunet, linux-amlogic
Cc: Martin Blumenstingl, linux-kernel, linux-arm-kernel, linux-clk
The meson-saradc driver manually sets the input clock for
sar_adc_clk_sel. Update the GXBB clock driver (which is used on GXBB,
GXL and GXM) so the rate settings on sar_adc_clk_div are propagated up
to sar_adc_clk_sel which will let the common clock framework select the
best matching parent clock if we want that.
This makes sar_adc_clk_div consistent with the axg-aoclk and g12a-aoclk
drivers, which both also specify CLK_SET_RATE_PARENT.
Fixes: 33d0fcdfe0e870 ("clk: gxbb: add the SAR ADC clocks and expose them")
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
---
This is a small consistency fix which I found while debugging an
unrelated problem.
drivers/clk/meson/gxbb.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/clk/meson/gxbb.c b/drivers/clk/meson/gxbb.c
index 7cfb998eeb3e..1f9c056e684c 100644
--- a/drivers/clk/meson/gxbb.c
+++ b/drivers/clk/meson/gxbb.c
@@ -935,6 +935,7 @@ static struct clk_regmap gxbb_sar_adc_clk_div = {
&gxbb_sar_adc_clk_sel.hw
},
.num_parents = 1,
+ .flags = CLK_SET_RATE_PARENT,
},
};
--
2.23.0
_______________________________________________
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: Re: [PATCH 0/9] added helper macros to remove duplicate code from probe functions of the platform drivers
From: Satendra Singh Thakur @ 2019-09-21 14:57 UTC (permalink / raw)
To: dan.j.williams, vkoul, jun.nie, shawnguo, agross, sean.wang,
matthias.bgg, maxime.ripard, wens, lars, afaerber,
manivannan.sadhasivam
Cc: linux-kernel, linux-mediatek, satendrasingh.thakur, dmaengine,
Satendra Singh Thakur, linux-arm-kernel
In-Reply-To: <20190918102715.GO4392@vkoul-mobl>
On Wed, Sep 18, 2019 at 3:57 PM, Vinod Koul wrote:
> On 15-09-19, 12:30, Satendra Singh Thakur wrote:
> > 1. For most of the platform drivers's probe include following steps
> >
> > -memory allocation for driver's private structure
> > -getting io resources
> > -io remapping resources
> > -getting irq number
> > -registering irq
> > -setting driver's private data
> > -getting clock
> > -preparing and enabling clock
>
> And we have perfect set of APIs for these tasks!
Hi Vinod,
Thanks for the comments.
You are right, we already have set of APIs for these tasks.
The proposed macros combine the very same APIs to remove
duplicate/redundant code.
A new driver author can use these macros to easily write probe
function without having to worry about signatures of internal APIs.
In the past, people have combined some of them e.g.
a) clk_prepare_enable combines clk_prepare and clk_enable
b) devm_platform_ioremap_resource combines
platform_get_resource (for type IORESOURCE_MEM)
and devm_ioremap_resource
c) module_platform_driver macro encompasses module_init/exit
and driver_register/unregister functions.
The basic idea is to simplyfy coding.
> > 2. We have defined a set of macros to combine some or all of
> > the above mentioned steps. This will remove redundant/duplicate
> > code in drivers' probe functions of platform drivers.
>
> Why, how does it help and you do realize it also introduces bugs
This will make probe function shorter by removing repeated code.
This will also reduce bugs caused due to improper handling
of failure cases because of these reasons:
a) If the developer calls each API individualy one might miss
proper handling of the failure for some API; Whereas the macro
properly handles failure of each API.
b) Macros are devres compatible which leaves less room for
memory leaks.
Yes, the macros which enable clock and request irqs
might cause bugs if they are not used carefully.
For instance, enabling the clock or requesting the irq
earlier than actually required. So, the macros with _clk
and _irq, _all suffix should be used carefully.
Please let me know if I miss any specific type of bug
here.
>
> > devm_platform_probe_helper(pdev, priv, clk_name);
> > devm_platform_probe_helper_clk(pdev, priv, clk_name);
> > devm_platform_probe_helper_irq(pdev, priv, clk_name,
> > irq_hndlr, irq_flags, irq_name, irq_devid);
> > devm_platform_probe_helper_all(pdev, priv, clk_name,
> > irq_hndlr, irq_flags, irq_name, irq_devid);
> > devm_platform_probe_helper_all_data(pdev, priv, clk_name,
> > irq_hndlr, irq_flags, irq_name, irq_devid);
> >
> > 3. Code is made devres compatible (wherever required)
> > The functions: clk_get, request_irq, kzalloc, platform_get_resource
> > are replaced with their devm_* counterparts.
>
> We already have devres APIs for people to use!
Yes, we have devres APIs and many drivers do use them.
But still there are many which don't use them.
The proposed macros provides just another way to use devres APIs.
> >
> > 4. Few bugs are also fixed.
>
> Which ones..?
The bug is that the failure of request_irq
is not handled properly in mtk-hsdma.c. This is fixed in patch [5/9].
https://lkml.org/lkml/2019/9/15/35
Please let me know if I am missing something here.
Thanks
-Satendra
_______________________________________________
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] arm: export memblock_reserve()d regions via /proc/iomem
From: Russell King - ARM Linux admin @ 2019-09-21 14:51 UTC (permalink / raw)
To: Yu Chen; +Cc: yu.chen3, linux-kernel, linux-arm-kernel
In-Reply-To: <1569070969-5168-1-git-send-email-33988979@163.com>
On Sat, Sep 21, 2019 at 09:02:49PM +0800, Yu Chen wrote:
> From: Yu Chen <yu.chen3@zte.com.cn>
>
> memblock reserved regions are not reported via /proc/iomem on ARM, kexec's
> user-space doesn't know about memblock_reserve()d regions and thus
> possible for kexec to overwrite with the new kernel or initrd.
Many reserved regions come from the kernel allocating memory during
boot. We don't want to prevent kexec re-using those regions.
> [ 0.000000] Booting Linux on physical CPU 0xf00
> [ 0.000000] Linux version 4.9.115-rt93-dirty (yuchen@localhost.localdomain) (gcc version 6.2.0 (ZTE Embsys-TSP V3.07.2
> 0) ) #62 SMP PREEMPT Fri Sep 20 10:39:29 CST 2019
> [ 0.000000] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=30c5387d
> [ 0.000000] CPU: div instructions available: patching division code
> [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
> [ 0.000000] OF: fdt:Machine model: LS1021A TWR Board
> [ 0.000000] INITRD: 0x80f7f000+0x03695e40 overlaps in-use memory region - disabling initrd
Is the overlapping region one that is marked as reserved in DT?
Where is the reserved region that overlaps the initrd coming from?
Thanks.
--
RMK's Patch system: https://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/1] sched/eas: introduce system-wide overutil indicator
From: kbuild test robot @ 2019-09-21 14:44 UTC (permalink / raw)
To: YT Chang
Cc: wsd_upstream, Peter Zijlstra, linux-kernel, YT Chang,
linux-mediatek, kbuild-all, Matthias Brugger, linux-arm-kernel
In-Reply-To: <1568877622-28073-1-git-send-email-yt.chang@mediatek.com>
[-- Attachment #1: Type: text/plain, Size: 5636 bytes --]
Hi YT,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[cannot apply to v5.3 next-20190918]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url: https://github.com/0day-ci/linux/commits/YT-Chang/sched-eas-introduce-system-wide-overutil-indicator/20190919-152213
config: x86_64-randconfig-s1-201937 (attached as .config)
compiler: gcc-6 (Debian 6.3.0-18+deb9u1) 6.3.0 20170516
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
:::::: branch date: 2 hours ago
:::::: commit date: 2 hours ago
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
kernel/sched/fair.c: In function 'update_system_overutilized':
>> kernel/sched/fair.c:5234:20: error: 'capacity_margin' undeclared (first use in this function)
group_util * capacity_margin)) {
^~~~~~~~~~~~~~~
kernel/sched/fair.c:5234:20: note: each undeclared identifier is reported only once for each function it appears in
# https://github.com/0day-ci/linux/commit/58f2ed2a11501d4de287fafc0a7b3385d54f8238
git remote add linux-review https://github.com/0day-ci/linux
git remote update linux-review
git checkout 58f2ed2a11501d4de287fafc0a7b3385d54f8238
vim +/capacity_margin +5234 kernel/sched/fair.c
58f2ed2a11501d YT Chang 2019-09-19 5195
58f2ed2a11501d YT Chang 2019-09-19 5196 static
58f2ed2a11501d YT Chang 2019-09-19 5197 void update_system_overutilized(struct sched_domain *sd, struct cpumask *cpus)
58f2ed2a11501d YT Chang 2019-09-19 5198 {
58f2ed2a11501d YT Chang 2019-09-19 5199 unsigned long group_util;
58f2ed2a11501d YT Chang 2019-09-19 5200 bool intra_overutil = false;
58f2ed2a11501d YT Chang 2019-09-19 5201 unsigned long max_capacity;
58f2ed2a11501d YT Chang 2019-09-19 5202 struct sched_group *group = sd->groups;
58f2ed2a11501d YT Chang 2019-09-19 5203 struct root_domain *rd;
58f2ed2a11501d YT Chang 2019-09-19 5204 int this_cpu;
58f2ed2a11501d YT Chang 2019-09-19 5205 bool overutilized;
58f2ed2a11501d YT Chang 2019-09-19 5206 int i;
58f2ed2a11501d YT Chang 2019-09-19 5207
58f2ed2a11501d YT Chang 2019-09-19 5208 this_cpu = smp_processor_id();
58f2ed2a11501d YT Chang 2019-09-19 5209 rd = cpu_rq(this_cpu)->rd;
58f2ed2a11501d YT Chang 2019-09-19 5210 overutilized = READ_ONCE(rd->overutilized);
58f2ed2a11501d YT Chang 2019-09-19 5211 max_capacity = rd->max_cpu_capacity;
58f2ed2a11501d YT Chang 2019-09-19 5212
58f2ed2a11501d YT Chang 2019-09-19 5213 do {
58f2ed2a11501d YT Chang 2019-09-19 5214 group_util = 0;
58f2ed2a11501d YT Chang 2019-09-19 5215 for_each_cpu_and(i, sched_group_span(group), cpus) {
58f2ed2a11501d YT Chang 2019-09-19 5216 group_util += cpu_util(i);
58f2ed2a11501d YT Chang 2019-09-19 5217 if (cpu_overutilized(i)) {
58f2ed2a11501d YT Chang 2019-09-19 5218 if (capacity_orig_of(i) < max_capacity) {
58f2ed2a11501d YT Chang 2019-09-19 5219 intra_overutil = true;
58f2ed2a11501d YT Chang 2019-09-19 5220 break;
58f2ed2a11501d YT Chang 2019-09-19 5221 }
58f2ed2a11501d YT Chang 2019-09-19 5222 }
58f2ed2a11501d YT Chang 2019-09-19 5223 }
58f2ed2a11501d YT Chang 2019-09-19 5224
58f2ed2a11501d YT Chang 2019-09-19 5225 /*
58f2ed2a11501d YT Chang 2019-09-19 5226 * A capacity base hint for over-utilization.
58f2ed2a11501d YT Chang 2019-09-19 5227 * Not to trigger system overutiled if heavy tasks
58f2ed2a11501d YT Chang 2019-09-19 5228 * in Big.cluster, so
58f2ed2a11501d YT Chang 2019-09-19 5229 * add the free room(20%) of Big.cluster is impacted which means
58f2ed2a11501d YT Chang 2019-09-19 5230 * system-wide over-utilization,
58f2ed2a11501d YT Chang 2019-09-19 5231 * that considers whole cluster not single cpu
58f2ed2a11501d YT Chang 2019-09-19 5232 */
58f2ed2a11501d YT Chang 2019-09-19 5233 if (group->group_weight > 1 && (group->sgc->capacity * 1024 <
58f2ed2a11501d YT Chang 2019-09-19 @5234 group_util * capacity_margin)) {
58f2ed2a11501d YT Chang 2019-09-19 5235 intra_overutil = true;
58f2ed2a11501d YT Chang 2019-09-19 5236 break;
58f2ed2a11501d YT Chang 2019-09-19 5237 }
58f2ed2a11501d YT Chang 2019-09-19 5238
58f2ed2a11501d YT Chang 2019-09-19 5239 group = group->next;
58f2ed2a11501d YT Chang 2019-09-19 5240
58f2ed2a11501d YT Chang 2019-09-19 5241 } while (group != sd->groups && !intra_overutil);
58f2ed2a11501d YT Chang 2019-09-19 5242
58f2ed2a11501d YT Chang 2019-09-19 5243 if (overutilized != intra_overutil) {
58f2ed2a11501d YT Chang 2019-09-19 5244 if (intra_overutil == true) {
58f2ed2a11501d YT Chang 2019-09-19 5245 WRITE_ONCE(rd->overutilized, SG_OVERUTILIZED);
58f2ed2a11501d YT Chang 2019-09-19 5246 trace_sched_overutilized_tp(rd, SG_OVERUTILIZED);
58f2ed2a11501d YT Chang 2019-09-19 5247 } else {
58f2ed2a11501d YT Chang 2019-09-19 5248 WRITE_ONCE(rd->overutilized, 0);
58f2ed2a11501d YT Chang 2019-09-19 5249 trace_sched_overutilized_tp(rd, 0);
58f2ed2a11501d YT Chang 2019-09-19 5250 }
58f2ed2a11501d YT Chang 2019-09-19 5251 }
58f2ed2a11501d YT Chang 2019-09-19 5252 }
58f2ed2a11501d YT Chang 2019-09-19 5253
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 34240 bytes --]
[-- Attachment #3: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v8 3/3] mm: fix double page fault on arm64 if PTE_AF is cleared
From: Jia He @ 2019-09-21 13:50 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Mark Rutland, James Morse,
Marc Zyngier, Matthew Wilcox, Kirill A. Shutemov,
linux-arm-kernel, linux-kernel, linux-mm, Suzuki Poulose
Cc: Ralph Campbell, Jia He, Anshuman Khandual, Alex Van Brunt,
Kaly Xin, Jérôme Glisse, Punit Agrawal, hejianet,
Andrew Morton, nd, Robin Murphy, Thomas Gleixner
In-Reply-To: <20190921135054.142360-1-justin.he@arm.com>
When we tested pmdk unit test [1] vmmalloc_fork TEST1 in arm64 guest, there
will be a double page fault in __copy_from_user_inatomic of cow_user_page.
Below call trace is from arm64 do_page_fault for debugging purpose
[ 110.016195] Call trace:
[ 110.016826] do_page_fault+0x5a4/0x690
[ 110.017812] do_mem_abort+0x50/0xb0
[ 110.018726] el1_da+0x20/0xc4
[ 110.019492] __arch_copy_from_user+0x180/0x280
[ 110.020646] do_wp_page+0xb0/0x860
[ 110.021517] __handle_mm_fault+0x994/0x1338
[ 110.022606] handle_mm_fault+0xe8/0x180
[ 110.023584] do_page_fault+0x240/0x690
[ 110.024535] do_mem_abort+0x50/0xb0
[ 110.025423] el0_da+0x20/0x24
The pte info before __copy_from_user_inatomic is (PTE_AF is cleared):
[ffff9b007000] pgd=000000023d4f8003, pud=000000023da9b003, pmd=000000023d4b3003, pte=360000298607bd3
As told by Catalin: "On arm64 without hardware Access Flag, copying from
user will fail because the pte is old and cannot be marked young. So we
always end up with zeroed page after fork() + CoW for pfn mappings. we
don't always have a hardware-managed access flag on arm64."
This patch fix it by calling pte_mkyoung. Also, the parameter is
changed because vmf should be passed to cow_user_page()
Add a WARN_ON_ONCE when __copy_from_user_inatomic() returns error
in case there can be some obscure use-case.(by Kirill)
[1] https://github.com/pmem/pmdk/tree/master/src/test/vmmalloc_fork
Reported-by: Yibo Cai <Yibo.Cai@arm.com>
Signed-off-by: Jia He <justin.he@arm.com>
---
mm/memory.c | 67 ++++++++++++++++++++++++++++++++++++++++++++++++-----
1 file changed, 61 insertions(+), 6 deletions(-)
diff --git a/mm/memory.c b/mm/memory.c
index e2bb51b6242e..ae09b070b04d 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -118,6 +118,13 @@ int randomize_va_space __read_mostly =
2;
#endif
+#ifndef arch_faults_on_old_pte
+static inline bool arch_faults_on_old_pte(void)
+{
+ return false;
+}
+#endif
+
static int __init disable_randmaps(char *s)
{
randomize_va_space = 0;
@@ -2140,8 +2147,13 @@ static inline int pte_unmap_same(struct mm_struct *mm, pmd_t *pmd,
return same;
}
-static inline void cow_user_page(struct page *dst, struct page *src, unsigned long va, struct vm_area_struct *vma)
+static inline bool cow_user_page(struct page *dst, struct page *src,
+ struct vm_fault *vmf)
{
+ struct vm_area_struct *vma = vmf->vma;
+ struct mm_struct *mm = vma->vm_mm;
+ unsigned long addr = vmf->address;
+
debug_dma_assert_idle(src);
/*
@@ -2151,21 +2163,53 @@ static inline void cow_user_page(struct page *dst, struct page *src, unsigned lo
* fails, we just zero-fill it. Live with it.
*/
if (unlikely(!src)) {
- void *kaddr = kmap_atomic(dst);
- void __user *uaddr = (void __user *)(va & PAGE_MASK);
+ void *kaddr;
+ pte_t entry;
+ void __user *uaddr = (void __user *)(addr & PAGE_MASK);
+ /* On architectures with software "accessed" bits, we would
+ * take a double page fault, so mark it accessed here.
+ */
+ if (arch_faults_on_old_pte() && !pte_young(vmf->orig_pte)) {
+ vmf->pte = pte_offset_map_lock(mm, vmf->pmd, addr,
+ &vmf->ptl);
+ if (likely(pte_same(*vmf->pte, vmf->orig_pte))) {
+ entry = pte_mkyoung(vmf->orig_pte);
+ if (ptep_set_access_flags(vma, addr,
+ vmf->pte, entry, 0))
+ update_mmu_cache(vma, addr, vmf->pte);
+ } else {
+ /* Other thread has already handled the fault
+ * and we don't need to do anything. If it's
+ * not the case, the fault will be triggered
+ * again on the same address.
+ */
+ pte_unmap_unlock(vmf->pte, vmf->ptl);
+ return false;
+ }
+ pte_unmap_unlock(vmf->pte, vmf->ptl);
+ }
+
+ kaddr = kmap_atomic(dst);
/*
* This really shouldn't fail, because the page is there
* in the page tables. But it might just be unreadable,
* in which case we just give up and fill the result with
* zeroes.
*/
- if (__copy_from_user_inatomic(kaddr, uaddr, PAGE_SIZE))
+ if (__copy_from_user_inatomic(kaddr, uaddr, PAGE_SIZE)) {
+ /* Give a warn in case there can be some obscure
+ * use-case
+ */
+ WARN_ON_ONCE(1);
clear_page(kaddr);
+ }
kunmap_atomic(kaddr);
flush_dcache_page(dst);
} else
- copy_user_highpage(dst, src, va, vma);
+ copy_user_highpage(dst, src, addr, vma);
+
+ return true;
}
static gfp_t __get_fault_gfp_mask(struct vm_area_struct *vma)
@@ -2318,7 +2362,18 @@ static vm_fault_t wp_page_copy(struct vm_fault *vmf)
vmf->address);
if (!new_page)
goto oom;
- cow_user_page(new_page, old_page, vmf->address, vma);
+
+ if (!cow_user_page(new_page, old_page, vmf)) {
+ /* COW failed, if the fault was solved by other,
+ * it's fine. If not, userspace would re-fault on
+ * the same address and we will handle the fault
+ * from the second attempt.
+ */
+ put_page(new_page);
+ if (old_page)
+ put_page(old_page);
+ return 0;
+ }
}
if (mem_cgroup_try_charge_delay(new_page, mm, GFP_KERNEL, &memcg, false))
--
2.17.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 v8 2/3] arm64: mm: implement arch_faults_on_old_pte() on arm64
From: Jia He @ 2019-09-21 13:50 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Mark Rutland, James Morse,
Marc Zyngier, Matthew Wilcox, Kirill A. Shutemov,
linux-arm-kernel, linux-kernel, linux-mm, Suzuki Poulose
Cc: Ralph Campbell, Jia He, Anshuman Khandual, Alex Van Brunt,
Kaly Xin, Jérôme Glisse, Punit Agrawal, hejianet,
Andrew Morton, nd, Robin Murphy, Thomas Gleixner
In-Reply-To: <20190921135054.142360-1-justin.he@arm.com>
On arm64 without hardware Access Flag, copying fromuser will fail because
the pte is old and cannot be marked young. So we always end up with zeroed
page after fork() + CoW for pfn mappings. we don't always have a
hardware-managed access flag on arm64.
Hence implement arch_faults_on_old_pte on arm64 to indicate that it might
cause page fault when accessing old pte.
Signed-off-by: Jia He <justin.he@arm.com>
---
arch/arm64/include/asm/pgtable.h | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index e09760ece844..4a9939615e41 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -868,6 +868,18 @@ static inline void update_mmu_cache(struct vm_area_struct *vma,
#define phys_to_ttbr(addr) (addr)
#endif
+/*
+ * On arm64 without hardware Access Flag, copying fromuser will fail because
+ * the pte is old and cannot be marked young. So we always end up with zeroed
+ * page after fork() + CoW for pfn mappings. we don't always have a
+ * hardware-managed access flag on arm64.
+ */
+static inline bool arch_faults_on_old_pte(void)
+{
+ return !cpu_has_hw_af();
+}
+#define arch_faults_on_old_pte arch_faults_on_old_pte
+
#endif /* !__ASSEMBLY__ */
#endif /* __ASM_PGTABLE_H */
--
2.17.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 v8 1/3] arm64: cpufeature: introduce helper cpu_has_hw_af()
From: Jia He @ 2019-09-21 13:50 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Mark Rutland, James Morse,
Marc Zyngier, Matthew Wilcox, Kirill A. Shutemov,
linux-arm-kernel, linux-kernel, linux-mm, Suzuki Poulose
Cc: Ralph Campbell, Jia He, Anshuman Khandual, Alex Van Brunt,
Kaly Xin, Jérôme Glisse, Punit Agrawal, hejianet,
Andrew Morton, nd, Robin Murphy, Thomas Gleixner
In-Reply-To: <20190921135054.142360-1-justin.he@arm.com>
We unconditionally set the HW_AFDBM capability and only enable it on
CPUs which really have the feature. But sometimes we need to know
whether this cpu has the capability of HW AF. So decouple AF from
DBM by new helper cpu_has_hw_af().
Reported-by: kbuild test robot <lkp@intel.com>
Suggested-by: Suzuki Poulose <Suzuki.Poulose@arm.com>
Signed-off-by: Jia He <justin.he@arm.com>
---
arch/arm64/include/asm/cpufeature.h | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
index c96ffa4722d3..46caf934ba4e 100644
--- a/arch/arm64/include/asm/cpufeature.h
+++ b/arch/arm64/include/asm/cpufeature.h
@@ -667,6 +667,16 @@ static inline u32 id_aa64mmfr0_parange_to_phys_shift(int parange)
default: return CONFIG_ARM64_PA_BITS;
}
}
+
+/* Decouple AF from AFDBM. */
+static inline bool cpu_has_hw_af(void)
+{
+ if (IS_ENABLED(CONFIG_ARM64_HW_AFDBM))
+ return read_cpuid(ID_AA64MMFR1_EL1) & 0xf;
+
+ return false;
+}
+
#endif /* __ASSEMBLY__ */
#endif
--
2.17.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 v8 0/3] fix double page fault on arm64
From: Jia He @ 2019-09-21 13:50 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Mark Rutland, James Morse,
Marc Zyngier, Matthew Wilcox, Kirill A. Shutemov,
linux-arm-kernel, linux-kernel, linux-mm, Suzuki Poulose
Cc: Ralph Campbell, Jia He, Anshuman Khandual, Alex Van Brunt,
Kaly Xin, Jérôme Glisse, Punit Agrawal, hejianet,
Andrew Morton, nd, Robin Murphy, Thomas Gleixner
When we tested pmdk unit test vmmalloc_fork TEST1 in arm64 guest, there
will be a double page fault in __copy_from_user_inatomic of cow_user_page.
As told by Catalin: "On arm64 without hardware Access Flag, copying from
user will fail because the pte is old and cannot be marked young. So we
always end up with zeroed page after fork() + CoW for pfn mappings. we
don't always have a hardware-managed access flag on arm64."
Changes
v8: change cow_user_page's return type (Matthew)
v7: s/pte_spinlock/pte_offset_map_lock (Kirill)
v6: fix error case of returning with spinlock taken (Catalin)
move kmap_atomic to avoid handling kunmap_atomic
v5: handle the case correctly when !pte_same
fix kbuild test failed
v4: introduce cpu_has_hw_af (Suzuki)
bail out if !pte_same (Kirill)
v3: add vmf->ptl lock/unlock (Kirill A. Shutemov)
add arch_faults_on_old_pte (Matthew, Catalin)
v2: remove FAULT_FLAG_WRITE when setting pte access flag (Catalin)
Jia He (3):
arm64: cpufeature: introduce helper cpu_has_hw_af()
arm64: mm: implement arch_faults_on_old_pte() on arm64
mm: fix double page fault on arm64 if PTE_AF is cleared
arch/arm64/include/asm/cpufeature.h | 10 +++++
arch/arm64/include/asm/pgtable.h | 12 ++++++
mm/memory.c | 67 ++++++++++++++++++++++++++---
3 files changed, 83 insertions(+), 6 deletions(-)
--
2.17.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 v7 3/3] mm: fix double page fault on arm64 if PTE_AF is cleared
From: Jia He @ 2019-09-21 13:19 UTC (permalink / raw)
To: Matthew Wilcox, Jia He
Cc: Mark Rutland, Kaly Xin, Ralph Campbell, Andrew Morton,
Suzuki Poulose, Catalin Marinas, Anshuman Khandual, linux-kernel,
linux-mm, Jérôme Glisse, James Morse, linux-arm-kernel,
Punit Agrawal, Marc Zyngier, Thomas Gleixner, nd, Will Deacon,
Alex Van Brunt, Kirill A. Shutemov, Robin Murphy
In-Reply-To: <20190920155300.GC15392@bombadil.infradead.org>
[On behalf of justin.he@arm.com]
Hi Matthew
On 2019/9/20 23:53, Matthew Wilcox wrote:
> On Fri, Sep 20, 2019 at 09:54:37PM +0800, Jia He wrote:
>> -static inline void cow_user_page(struct page *dst, struct page *src, unsigned long va, struct vm_area_struct *vma)
>> +static inline int cow_user_page(struct page *dst, struct page *src,
>> + struct vm_fault *vmf)
>> {
> Can we talk about the return type here?
>
>> + } else {
>> + /* Other thread has already handled the fault
>> + * and we don't need to do anything. If it's
>> + * not the case, the fault will be triggered
>> + * again on the same address.
>> + */
>> + pte_unmap_unlock(vmf->pte, vmf->ptl);
>> + return -1;
> ...
>> + return 0;
>> }
> So -1 for "try again" and 0 for "succeeded".
>
>> + if (cow_user_page(new_page, old_page, vmf)) {
> Then we use it like a bool. But it's kind of backwards from a bool because
> false is success.
>
>> + /* COW failed, if the fault was solved by other,
>> + * it's fine. If not, userspace would re-fault on
>> + * the same address and we will handle the fault
>> + * from the second attempt.
>> + */
>> + put_page(new_page);
>> + if (old_page)
>> + put_page(old_page);
>> + return 0;
> And we don't use the return value; in fact we invert it.
>
> Would this make more sense:
>
> static inline bool cow_user_page(struct page *dst, struct page *src,
> struct vm_fault *vmf)
> ...
> pte_unmap_unlock(vmf->pte, vmf->ptl);
> return false;
> ...
> return true;
> ...
> if (!cow_user_page(new_page, old_page, vmf)) {
>
> That reads more sensibly for me. We could also go with returning a
> vm_fault_t, but that would be more complex than needed today, I think.
Ok, will change the return type to bool as you suggested.
Thanks
---
Cheers,
Justin (Jia He)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] spi: mediatek: Use devm_platform_ioremap_resource() in mtk_spi_slave_probe()
From: Markus Elfring @ 2019-09-21 13:19 UTC (permalink / raw)
To: linux-spi, linux-mediatek, linux-arm-kernel, Leilk Liu,
Mark Brown, Matthias Brugger
Cc: kernel-janitors, LKML
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Sat, 21 Sep 2019 15:12:33 +0200
Simplify this function implementation by using a known wrapper function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
drivers/spi/spi-slave-mt27xx.c | 12 +-----------
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/drivers/spi/spi-slave-mt27xx.c b/drivers/spi/spi-slave-mt27xx.c
index 61bc43b0fe57..44edaa360405 100644
--- a/drivers/spi/spi-slave-mt27xx.c
+++ b/drivers/spi/spi-slave-mt27xx.c
@@ -368,7 +368,6 @@ static int mtk_spi_slave_probe(struct platform_device *pdev)
{
struct spi_controller *ctlr;
struct mtk_spi_slave *mdata;
- struct resource *res;
int irq, ret;
ctlr = spi_alloc_slave(&pdev->dev, sizeof(*mdata));
@@ -392,17 +391,8 @@ static int mtk_spi_slave_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, ctlr);
init_completion(&mdata->xfer_done);
-
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!res) {
- ret = -ENODEV;
- dev_err(&pdev->dev, "failed to determine base address\n");
- goto err_put_ctlr;
- }
-
mdata->dev = &pdev->dev;
-
- mdata->base = devm_ioremap_resource(&pdev->dev, res);
+ mdata->base = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(mdata->base)) {
ret = PTR_ERR(mdata->base);
goto err_put_ctlr;
--
2.23.0
_______________________________________________
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] arm64: dts: rockchip: fix Rockpro64 RK808 interrupt line
From: Hugh Cole-Baker @ 2019-09-21 13:14 UTC (permalink / raw)
To: devicetree
Cc: Mark Rutland, Heiko Stuebner, Akash Gajjar, linux-kernel,
linux-rockchip, Rob Herring, Hugh Cole-Baker, linux-arm-kernel
Fix the pinctrl and interrupt specifier for RK808 to use GPIO3_B2. On the
Rockpro64 schematic [1] page 16, it shows GPIO3_B2 used for the interrupt
line PMIC_INT_L from the RK808, and there's a note which translates as:
"PMU termination GPIO1_C5 changed to this".
Tested by setting an RTC wakealarm and checking /proc/interrupts counters.
Without this patch, neither the rockchip_gpio_irq counter for the RK808,
nor the RTC alarm counter increment when the alarm time is reached.
With this patch, both interrupt counters increment by 1 as expected.
[1] http://files.pine64.org/doc/rockpro64/rockpro64_v21-SCH.pdf
Fixes: e4f3fb4 ("arm64: dts: rockchip: add initial dts support for Rockpro64")
Signed-off-by: Hugh Cole-Baker <sigmaris@gmail.com>
---
arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dts | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dts b/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dts
index 0401d4ec1f45..c27d8a6ae1c5 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dts
@@ -247,8 +247,8 @@
rk808: pmic@1b {
compatible = "rockchip,rk808";
reg = <0x1b>;
- interrupt-parent = <&gpio1>;
- interrupts = <21 IRQ_TYPE_LEVEL_LOW>;
+ interrupt-parent = <&gpio3>;
+ interrupts = <10 IRQ_TYPE_LEVEL_LOW>;
#clock-cells = <1>;
clock-output-names = "xin32k", "rk808-clkout2";
pinctrl-names = "default";
@@ -574,7 +574,7 @@
pmic {
pmic_int_l: pmic-int-l {
- rockchip,pins = <1 RK_PC5 RK_FUNC_GPIO &pcfg_pull_up>;
+ rockchip,pins = <3 RK_PB2 RK_FUNC_GPIO &pcfg_pull_up>;
};
vsel1_gpio: vsel1-gpio {
--
2.17.2 (Apple Git-113)
_______________________________________________
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] arm: export memblock_reserve()d regions via /proc/iomem
From: Yu Chen @ 2019-09-21 13:02 UTC (permalink / raw)
To: rmk+kernel, linux; +Cc: yu.chen3, linux-kernel, linux-arm-kernel
From: Yu Chen <yu.chen3@zte.com.cn>
memblock reserved regions are not reported via /proc/iomem on ARM, kexec's
user-space doesn't know about memblock_reserve()d regions and thus
possible for kexec to overwrite with the new kernel or initrd.
[ 0.000000] Booting Linux on physical CPU 0xf00
[ 0.000000] Linux version 4.9.115-rt93-dirty (yuchen@localhost.localdomain) (gcc version 6.2.0 (ZTE Embsys-TSP V3.07.2
0) ) #62 SMP PREEMPT Fri Sep 20 10:39:29 CST 2019
[ 0.000000] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=30c5387d
[ 0.000000] CPU: div instructions available: patching division code
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[ 0.000000] OF: fdt:Machine model: LS1021A TWR Board
[ 0.000000] INITRD: 0x80f7f000+0x03695e40 overlaps in-use memory region - disabling initrd
Signed-off-by: Yu Chen <yu.chen3@zte.com.cn>
Reviewed-by: Junhua Huang <huang.junhua@zte.com.cn>
---
arch/arm/kernel/setup.c | 28 ++++++++++++++++++++++++++++
1 file changed, 28 insertions(+)
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index d0a464e..606d1ac 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -911,6 +911,34 @@ static void __init request_standard_resources(const struct machine_desc *mdesc)
request_resource(&ioport_resource, &lp2);
}
+static int __init reserve_memblock_reserved_regions(void)
+{
+ u64 i, j;
+
+ for (i = 0; i < num_standard_resources; ++i) {
+ struct resource *mem = &standard_resources[i];
+ phys_addr_t r_start, r_end, mem_size = resource_size(mem);
+
+ if (!memblock_is_region_reserved(mem->start, mem_size))
+ continue;
+
+ for_each_reserved_mem_region(j, &r_start, &r_end) {
+ resource_size_t start, end;
+
+ start = max(PFN_PHYS(PFN_DOWN(r_start)), mem->start);
+ end = min(PFN_PHYS(PFN_UP(r_end)) - 1, mem->end);
+
+ if (start > mem->end || end < mem->start)
+ continue;
+
+ reserve_region_with_split(mem, start, end, "reserved");
+ }
+ }
+
+ return 0;
+}
+arch_initcall(reserve_memblock_reserved_regions);
+
#if defined(CONFIG_VGA_CONSOLE) || defined(CONFIG_DUMMY_CONSOLE) || \
defined(CONFIG_EFI)
struct screen_info screen_info = {
--
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] spi: mediatek: Use devm_platform_ioremap_resource() in mtk_spi_probe()
From: Markus Elfring @ 2019-09-21 12:52 UTC (permalink / raw)
To: linux-spi, linux-mediatek, linux-arm-kernel, Leilk Liu,
Mark Brown, Matthias Brugger
Cc: kernel-janitors, LKML
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Sat, 21 Sep 2019 14:45:40 +0200
Simplify this function implementation by using a known wrapper function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
drivers/spi/spi-mt65xx.c | 11 +----------
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/drivers/spi/spi-mt65xx.c b/drivers/spi/spi-mt65xx.c
index 6888a4dcff6d..25fe149a8d9a 100644
--- a/drivers/spi/spi-mt65xx.c
+++ b/drivers/spi/spi-mt65xx.c
@@ -619,7 +619,6 @@ static int mtk_spi_probe(struct platform_device *pdev)
struct spi_master *master;
struct mtk_spi *mdata;
const struct of_device_id *of_id;
- struct resource *res;
int i, irq, ret, addr_bits;
master = spi_alloc_master(&pdev->dev, sizeof(*mdata));
@@ -682,15 +681,7 @@ static int mtk_spi_probe(struct platform_device *pdev)
}
platform_set_drvdata(pdev, master);
-
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!res) {
- ret = -ENODEV;
- dev_err(&pdev->dev, "failed to determine base address\n");
- goto err_put_master;
- }
-
- mdata->base = devm_ioremap_resource(&pdev->dev, res);
+ mdata->base = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(mdata->base)) {
ret = PTR_ERR(mdata->base);
goto err_put_master;
--
2.23.0
_______________________________________________
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] ARM: dts: imx6qdl-wandboard: add ethernet PHY description
From: Anatolij Gustschin @ 2019-09-21 12:07 UTC (permalink / raw)
To: Shawn Guo; +Cc: Fabio Estevam, linux-arm-kernel
Wandboard devicetrees lack the ethernet PHY description, add it.
Signed-off-by: Anatolij Gustschin <agust@denx.de>
---
arch/arm/boot/dts/imx6qdl-wandboard.dtsi | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/imx6qdl-wandboard.dtsi b/arch/arm/boot/dts/imx6qdl-wandboard.dtsi
index 2cfb4112a467..c070893c509e 100644
--- a/arch/arm/boot/dts/imx6qdl-wandboard.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-wandboard.dtsi
@@ -279,8 +279,18 @@
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_enet>;
phy-mode = "rgmii-id";
+ phy-handle = <ðphy>;
phy-reset-gpios = <&gpio3 29 GPIO_ACTIVE_LOW>;
status = "okay";
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethphy: ethernet-phy@1 {
+ reg = <1>;
+ };
+ };
};
&mipi_csi {
--
2.21.0
_______________________________________________
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 V2] arm64: psci: Reduce waiting time of cpu_psci_cpu_kill()
From: Yunfeng Ye @ 2019-09-21 11:21 UTC (permalink / raw)
To: David Laight, catalin.marinas@arm.com, will@kernel.org,
kstewart@linuxfoundation.org, gregkh@linuxfoundation.org,
ard.biesheuvel@linaro.org, tglx@linutronix.de
Cc: wuyun.wu@huawei.com, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
If psci_ops.affinity_info() fails, it will sleep 10ms, which will not
take so long in the right case. Use usleep_range() instead of msleep(),
reduce the waiting time, and give a chance to busy wait before sleep.
Signed-off-by: Yunfeng Ye <yeyunfeng@huawei.com>
---
V1->V2:
- use usleep_range() instead of udelay() after waiting for a while
arch/arm64/kernel/psci.c | 17 +++++++++++++----
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/kernel/psci.c b/arch/arm64/kernel/psci.c
index c9f72b2..99b3122 100644
--- a/arch/arm64/kernel/psci.c
+++ b/arch/arm64/kernel/psci.c
@@ -82,6 +82,7 @@ static void cpu_psci_cpu_die(unsigned int cpu)
static int cpu_psci_cpu_kill(unsigned int cpu)
{
int err, i;
+ unsigned long timeout;
if (!psci_ops.affinity_info)
return 0;
@@ -91,16 +92,24 @@ static int cpu_psci_cpu_kill(unsigned int cpu)
* while it is dying. So, try again a few times.
*/
- for (i = 0; i < 10; i++) {
+ i = 0;
+ timeout = jiffies + msecs_to_jiffies(100);
+ do {
err = psci_ops.affinity_info(cpu_logical_map(cpu), 0);
if (err == PSCI_0_2_AFFINITY_LEVEL_OFF) {
pr_info("CPU%d killed.\n", cpu);
return 0;
}
- msleep(10);
- pr_info("Retrying again to check for CPU kill\n");
- }
+ /* busy-wait max 1ms */
+ if (i++ < 100) {
+ cond_resched();
+ udelay(10);
+ continue;
+ }
+
+ usleep_range(100, 1000);
+ } while (time_before(jiffies, timeout));
pr_warn("CPU%d may not have shut down cleanly (AFFINITY_INFO reports %d)\n",
cpu, err);
--
2.7.4.huawei.3
_______________________________________________
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: [RFCv4 0/7] interconnect: Add imx support via devfreq
From: Martin Kepplinger @ 2019-09-21 6:06 UTC (permalink / raw)
To: Leonard Crestez, Georgi Djakov, Rob Herring,
Artur Świgoń, Chanwoo Choi
Cc: Mark Rutland, Dong Aisheng, devicetree, Saravana Kannan, linux-pm,
Stephen Boyd, Viresh Kumar, Michael Turquette,
Krzysztof Kozlowski, Kyungmin Park, MyungJoo Ham,
Alexandre Bailon, kernel, Fabio Estevam, Shawn Guo,
linux-arm-kernel, linux-imx
In-Reply-To: <cover.1566570260.git.leonard.crestez@nxp.com>
On 23.08.19 16:36, Leonard Crestez wrote:
> This series add imx support for interconnect via devfreq: the ICC
> framework is used to aggregate requests from devices and then those are
> converted to DEV_PM_QOS_MIN_FREQUENCY requests for devfreq.
>
> The devfreq parts are posted separately, this series only intersects in
> devicetree: https://patchwork.kernel.org/cover/11104113/
>
> Since there is no single devicetree node that can represent the "interconnect"
> new API is added to allow individual devfreq nodes to act as parsing proxies
> all mapping to a single soc-level icc provider. This is still RFC
> because this
>
> The rest of the changes are small and deal with review comments.
>
hi Leonard,
When I run https://github.com/cdleonard/linux/tree/next_imx_busfreq and
https://github.com/cdleonard/arm-trusted-firmware/tree/imx_2.0.y_busfreq
on imx8mq, probe() fails:
[ 1.082847] imx-ddrc-devfreq 3d400000.dram-controller: failed to init
firmware freq info: -19
[ 1.091434] imx-ddrc-devfreq: probe of 3d400000.dram-controller
rejects match -19
in imx_ddrc_init_freq_info()'s check:
if (priv->freq_count <= 0 || priv->freq_count > IMX_DDRC_MAX_FREQ_COUNT)
That would indicate that I'm missing something in ATF? I'm pretty sure
I'm running your tree though.
Does anything come to your mind what I might be doing wrong? Am I
running your "correct" linux tree? Remember I'm on imx8mq, so I don't
exactly test this RFC of yours.
Also, how are your plans to rebase / update your ATF tree?
And since there's a lot in there: what additions are necessary for this
devfreq to work?
Lastly, how do you test? Is /sys/class/devfreq supposted to get populated?
thanks for your work!
martin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC, v3, 1/4] dt-binding: mt8183: Add Mediatek MDP3 dt-bindings
From: Laurent Pinchart @ 2019-09-20 23:30 UTC (permalink / raw)
To: Bibby Hsieh
Cc: laurent.pinchart+renesas, Rynn.Wu, Jerry-ch.Chen, jungo.lin,
hans.verkuil, Ping-Hsun Wu, frederic.chen, linux-media,
devicetree, Daoyuan.Huang, holmes.chiou, sj.huang, yuzhao,
linux-mediatek, matthias.bgg, mchehab, linux-arm-kernel,
Sean.Cheng, srv_heupstream, tfiga, christie.yu, zwisler
In-Reply-To: <20190911093406.5688-2-bibby.hsieh@mediatek.com>
Hi Bibby,
Thank you for the patch.
On Wed, Sep 11, 2019 at 05:34:03PM +0800, Bibby Hsieh wrote:
> From: daoyuan huang <daoyuan.huang@mediatek.com>
>
> This patch adds DT binding document for Media Data Path 3 (MDP3)
> a unit in multimedia system used for scaling and color format convert.
>
> Signed-off-by: Ping-Hsun Wu <ping-hsun.wu@mediatek.com>
> Signed-off-by: daoyuan huang <daoyuan.huang@mediatek.com>
> ---
> .../bindings/media/mediatek,mt8183-mdp3.txt | 201 ++++++++++++++++++
> 1 file changed, 201 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/mediatek,mt8183-mdp3.txt
>
> diff --git a/Documentation/devicetree/bindings/media/mediatek,mt8183-mdp3.txt b/Documentation/devicetree/bindings/media/mediatek,mt8183-mdp3.txt
> new file mode 100644
> index 000000000000..0d15326d12c1
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/mediatek,mt8183-mdp3.txt
> @@ -0,0 +1,201 @@
> +* Mediatek Media Data Path 3
> +
> +Media Data Path 3 (MDP3) is used for scaling and color space conversion.
> +
> +Required properties (controller node):
> +- compatible: "mediatek,mt8183-mdp"
This compatible string isn't used in the example below nor in any other
patch within this series. Did you mean "mediatek,mt8183-mdp3" ?
> +- mediatek,scp: the node of system control processor (SCP), using the
> + remoteproc & rpmsg framework, see
> + Documentation/devicetree/bindings/remoteproc/mtk,scp.txt for details.
> +- mediatek,mmsys: the node of mux(multiplexer) controller for HW connections.
> +- mediatek,mm-mutex: the node of sof(start of frame) signal controller.
> +- mediatek,mailbox-gce: the node of global command engine (GCE), used to
> + read/write registers with critical time limitation, see
> + Documentation/devicetree/bindings/mailbox/mtk-gce.txt for details.
> +- mboxes: mailbox number used to communicate with GCE.
> +- gce-subsys: sub-system id corresponding to the register address.
> +- gce-event-names: in use event name list, used to correspond to event IDs.
> +- gce-events: in use event IDs list, all IDs are defined in
> + 'dt-bindings/gce/mt8183-gce.h'.
> +
> +Required properties (all function blocks, child node):
> +- compatible: Should be one of
> + "mediatek,mt8183-mdp-rdma" - read DMA
> + "mediatek,mt8183-mdp-rsz" - resizer
> + "mediatek,mt8183-mdp-wdma" - write DMA
> + "mediatek,mt8183-mdp-wrot" - write DMA with rotation
> + "mediatek,mt8183-mdp-ccorr" - color correction with 3X3 matrix
> +- reg: Physical base address and length of the function block register space
> +- clocks: device clocks, see
> + Documentation/devicetree/bindings/clock/clock-bindings.txt for details.
> +- power-domains: a phandle to the power domain, see
> + Documentation/devicetree/bindings/power/power_domain.txt for details.
> +- mediatek,mdp-id: HW index to distinguish same functionality modules.
> +
> +Required properties (DMA function blocks, child node):
> +- compatible: Should be one of
> + "mediatek,mt8183-mdp-rdma"
> + "mediatek,mt8183-mdp-wdma"
> + "mediatek,mt8183-mdp-wrot"
> +- iommus: should point to the respective IOMMU block with master port as
> + argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
> + for details.
> +- mediatek,larb: must contain the local arbiters in the current Socs, see
> + Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
> + for details.
> +
> +Required properties (input path selection node):
> +- compatible:
> + "mediatek,mt8183-mdp-dl" - MDP direct link input source selection
> +- reg: Physical base address and length of the function block register space
> +- clocks: device clocks, see
> + Documentation/devicetree/bindings/clock/clock-bindings.txt for details.
> +- mediatek,mdp-id: HW index to distinguish same functionality modules.
> +
> +Required properties (ISP PASS2 (DIP) module path selection node):
> +- compatible:
> + "mediatek,mt8183-mdp-imgi" - input DMA of ISP PASS2 (DIP) module for raw image input
> +- reg: Physical base address and length of the function block register space
> +- mediatek,mdp-id: HW index to distinguish same functionality modules.
> +
> +Required properties (SW node):
> +- compatible: Should be one of
> + "mediatek,mt8183-mdp-exto" - output DMA of ISP PASS2 (DIP) module for yuv image output
> + "mediatek,mt8183-mdp-path" - MDP output path selection
> +- mediatek,mdp-id: HW index to distinguish same functionality modules.
Do all these nodes really describe separate IP cores ? This looks
extremely complicated to model something as simple as a scaler and color
space converter. It feels like you're trying to model in DT the
individual sub-blocks from the MDP3, while a single DT node to model the
MDP3 as a whole could be enough.
> +
> +Example:
> + mdp_camin@14000000 {
> + compatible = "mediatek,mt8183-mdp-dl";
> + mediatek,mdp-id = <0>;
> + reg = <0 0x14000000 0 0x1000>;
> + mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0 0x1000>;
> + clocks = <&mmsys CLK_MM_MDP_DL_TXCK>,
> + <&mmsys CLK_MM_MDP_DL_RX>;
> + };
> +
> + mdp_camin2@14000000 {
> + compatible = "mediatek,mt8183-mdp-dl";
> + mediatek,mdp-id = <1>;
> + reg = <0 0x14000000 0 0x1000>;
> + mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0 0x1000>;
> + clocks = <&mmsys CLK_MM_IPU_DL_TXCK>,
> + <&mmsys CLK_MM_IPU_DL_RX>;
> + };
> +
> + mdp_rdma0: mdp_rdma0@14001000 {
> + compatible = "mediatek,mt8183-mdp-rdma",
> + "mediatek,mt8183-mdp3";
> + mediatek,scp = <&scp>;
> + mediatek,mdp-id = <0>;
> + reg = <0 0x14001000 0 0x1000>;
> + mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0x1000 0x1000>;
> + power-domains = <&scpsys MT8183_POWER_DOMAIN_DISP>;
> + clocks = <&mmsys CLK_MM_MDP_RDMA0>,
> + <&mmsys CLK_MM_MDP_RSZ1>;
> + iommus = <&iommu M4U_PORT_MDP_RDMA0>;
> + mediatek,larb = <&larb0>;
> + mediatek,mmsys = <&mmsys>;
> + mediatek,mm-mutex = <&mutex>;
> + mediatek,mailbox-gce = <&gce>;
> + mboxes = <&gce 20 CMDQ_THR_PRIO_LOWEST 0>,
> + <&gce 21 CMDQ_THR_PRIO_LOWEST 0>,
> + <&gce 22 CMDQ_THR_PRIO_LOWEST 0>,
> + <&gce 23 CMDQ_THR_PRIO_LOWEST 0>;
> + gce-subsys = <&gce 0x14000000 SUBSYS_1400XXXX>,
> + <&gce 0x14010000 SUBSYS_1401XXXX>,
> + <&gce 0x14020000 SUBSYS_1402XXXX>,
> + <&gce 0x15020000 SUBSYS_1502XXXX>;
> + mediatek,gce-events = <CMDQ_EVENT_MDP_RDMA0_SOF>,
> + <CMDQ_EVENT_MDP_RDMA0_EOF>,
> + <CMDQ_EVENT_MDP_RSZ0_SOF>,
> + <CMDQ_EVENT_MDP_RSZ1_SOF>,
> + <CMDQ_EVENT_MDP_TDSHP_SOF>,
> + <CMDQ_EVENT_MDP_WROT0_SOF>,
> + <CMDQ_EVENT_MDP_WROT0_EOF>,
> + <CMDQ_EVENT_MDP_WDMA0_SOF>,
> + <CMDQ_EVENT_MDP_WDMA0_EOF>,
> + <CMDQ_EVENT_ISP_FRAME_DONE_P2_0>,
> + <CMDQ_EVENT_ISP_FRAME_DONE_P2_1>,
> + <CMDQ_EVENT_ISP_FRAME_DONE_P2_2>,
> + <CMDQ_EVENT_ISP_FRAME_DONE_P2_3>,
> + <CMDQ_EVENT_ISP_FRAME_DONE_P2_4>,
> + <CMDQ_EVENT_ISP_FRAME_DONE_P2_5>,
> + <CMDQ_EVENT_ISP_FRAME_DONE_P2_6>,
> + <CMDQ_EVENT_ISP_FRAME_DONE_P2_7>,
> + <CMDQ_EVENT_ISP_FRAME_DONE_P2_8>,
> + <CMDQ_EVENT_ISP_FRAME_DONE_P2_9>,
> + <CMDQ_EVENT_ISP_FRAME_DONE_P2_10>,
> + <CMDQ_EVENT_ISP_FRAME_DONE_P2_11>,
> + <CMDQ_EVENT_ISP_FRAME_DONE_P2_12>,
> + <CMDQ_EVENT_ISP_FRAME_DONE_P2_13>,
> + <CMDQ_EVENT_ISP_FRAME_DONE_P2_14>,
> + <CMDQ_EVENT_WPE_A_DONE>,
> + <CMDQ_EVENT_SPE_B_DONE>;
> + };
> +
> + mdp_imgi@15020000 {
> + compatible = "mediatek,mt8183-mdp-imgi";
> + mediatek,mdp-id = <0>;
> + reg = <0 0x15020000 0 0x1000>;
> + mediatek,gce-client-reg = <&gce SUBSYS_1502XXXX 0 0x1000>;
> + };
> +
> + mdp_img2o@15020000 {
> + compatible = "mediatek,mt8183-mdp-exto";
> + mediatek,mdp-id = <1>;
> + };
> +
> + mdp_rsz0: mdp_rsz0@14003000 {
> + compatible = "mediatek,mt8183-mdp-rsz";
> + mediatek,mdp-id = <0>;
> + reg = <0 0x14003000 0 0x1000>;
> + mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0x3000 0x1000>;
> + clocks = <&mmsys CLK_MM_MDP_RSZ0>;
> + };
> +
> + mdp_rsz1: mdp_rsz1@14004000 {
> + compatible = "mediatek,mt8183-mdp-rsz";
> + mediatek,mdp-id = <1>;
> + reg = <0 0x14004000 0 0x1000>;
> + mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0x4000 0x1000>;
> + clocks = <&mmsys CLK_MM_MDP_RSZ1>;
> + };
> +
> + mdp_wrot0: mdp_wrot0@14005000 {
> + compatible = "mediatek,mt8183-mdp-wrot";
> + mediatek,mdp-id = <0>;
> + reg = <0 0x14005000 0 0x1000>;
> + mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0x5000 0x1000>;
> + clocks = <&mmsys CLK_MM_MDP_WROT0>;
> + iommus = <&iommu M4U_PORT_MDP_WROT0>;
> + mediatek,larb = <&larb0>;
> + };
> +
> + mdp_path0_sout@14005000 {
> + compatible = "mediatek,mt8183-mdp-path";
> + mediatek,mdp-id = <0>;
> + };
> +
> + mdp_wdma: mdp_wdma@14006000 {
> + compatible = "mediatek,mt8183-mdp-wdma";
> + mediatek,mdp-id = <0>;
> + reg = <0 0x14006000 0 0x1000>;
> + mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0x6000 0x1000>;
> + clocks = <&mmsys CLK_MM_MDP_WDMA0>;
> + iommus = <&iommu M4U_PORT_MDP_WDMA0>;
> + mediatek,larb = <&larb0>;
> + };
> +
> + mdp_path1_sout@14006000 {
> + compatible = "mediatek,mt8183-mdp-path";
> + mediatek,mdp-id = <1>;
> + };
> +
> + mdp_ccorr: mdp_ccorr@1401c000 {
> + compatible = "mediatek,mt8183-mdp-ccorr";
> + mediatek,mdp-id = <0>;
> + reg = <0 0x1401c000 0 0x1000>;
> + mediatek,gce-client-reg = <&gce SUBSYS_1401XXXX 0xc000 0x1000>;
> + clocks = <&mmsys CLK_MM_MDP_CCORR>;
> + };
--
Regards,
Laurent Pinchart
_______________________________________________
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] Revert "ARM: bcm283x: Switch V3D over to using the PM driver instead of firmware."
From: Stefan Wahren @ 2019-09-20 22:55 UTC (permalink / raw)
To: Florian Fainelli, Eric Anholt, Ray Jui, Scott Branden,
Paul Kocialkowski, boris.brezillon
Cc: stable, bcm-kernel-feedback-list, dri-devel, linux-arm-kernel
In-Reply-To: <09f15af6-a849-a5eb-ac39-f4cdb07ebfb9@gmail.com>
Hi Florian,
Am 20.09.19 um 19:52 schrieb Florian Fainelli:
> On 9/8/19 8:44 AM, Stefan Wahren wrote:
>> Since release of the new BCM2835 PM driver there has been several reports
>> of V3D probing issues. This is caused by timeouts during powering-up the
>> GRAFX PM domain:
>>
>> bcm2835-power: Timeout waiting for grafx power OK
>>
>> I was able to reproduce this reliable on my Raspberry Pi 3B+ after setting
>> force_turbo=1 in the firmware configuration. Since there are no issues
>> using the firmware PM driver with the same setup, there must be an issue
>> in the BCM2835 PM driver.
>>
>> Unfortunately there hasn't been much progress in identifying the root cause
>> since June (mostly in the lack of documentation), so i decided to switch
>> back until the issue in the BCM2835 PM driver is fixed.
>>
>> Link: https://github.com/raspberrypi/linux/issues/3046
>> Fixes: e1dc2b2e1bef (" ARM: bcm283x: Switch V3D over to using the PM driver instead of firmware.")
>> Cc: stable@vger.kernel.org
>> Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
> Do you want me to pick up this change directly, or would you want to
> issue a pull request for 5.4-rcX with other fixes?
there aren't any other fixes, please pick up this directly.
Thanks
Stefan
_______________________________________________
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 3/4] arm64: Kconfig: Fix VEXPRESS driver dependencies
From: Amit Kucheria @ 2019-09-20 20:12 UTC (permalink / raw)
To: Sudeep Holla
Cc: Lorenzo Pieralisi, Liam Girdwood, Stephen Boyd, Catalin Marinas,
Linus Walleij, linux-clk, Linux Kernel Mailing List,
Kishon Vijay Abraham I, Bartosz Golaszewski, arm-soc, Mark Brown,
Sebastian Reichel, Will Deacon, Michael Turquette, Lists LAKML
In-Reply-To: <20190913101239.GB2559@bogus>
On Fri, Sep 13, 2019 at 3:12 AM Sudeep Holla <sudeep.holla@arm.com> wrote:
>
> On Thu, Sep 12, 2019 at 03:48:47AM +0530, Amit Kucheria wrote:
> > Push various VEXPRESS drivers behind ARCH_VEXPRESS dependency so that it
> > doesn't get enabled by default on other platforms.
> >
>
> I couldn't understand the motivation for these changes from the cover letter.
Yes, the cover letter for this series needs to be a lot better. Sorry.
In summary, I found a bunch of drivers in defconfig that were getting
called in early_initcall and core_initcall even when the platform or
COMPILE_TEST was not enabled. So I was just trying to ring fence some
of those drivers as a proof of concept to see if these changes were
acceptable upstream.
Let me try again with a better cover letter and using the pattern Arnd
suggested elsewhere.
> > Signed-off-by: Amit Kucheria <amit.kucheria@linaro.org>
> > ---
> > drivers/bus/Kconfig | 2 +-
> > drivers/clk/versatile/Kconfig | 4 ++--
> > 2 files changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig
> > index d80e8d70bf10..b2b1beee9953 100644
> > --- a/drivers/bus/Kconfig
> > +++ b/drivers/bus/Kconfig
> > @@ -166,7 +166,7 @@ config UNIPHIER_SYSTEM_BUS
> >
> > config VEXPRESS_CONFIG
> > bool "Versatile Express configuration bus"
> > - default y if ARCH_VEXPRESS
> > + depends on ARCH_VEXPRESS
> > depends on ARM || ARM64
> > depends on OF
> > select REGMAP
> > diff --git a/drivers/clk/versatile/Kconfig b/drivers/clk/versatile/Kconfig
> > index ac766855ba16..826750292c1e 100644
> > --- a/drivers/clk/versatile/Kconfig
> > +++ b/drivers/clk/versatile/Kconfig
> > @@ -5,8 +5,8 @@ config ICST
> > config COMMON_CLK_VERSATILE
> > bool "Clock driver for ARM Reference designs"
> > depends on ARCH_INTEGRATOR || ARCH_REALVIEW || \
> > - ARCH_VERSATILE || ARCH_VEXPRESS || ARM64 || \
> > - COMPILE_TEST
> > + ARCH_VERSATILE || ARCH_VEXPRESS || COMPILE_TEST
> > + depends on ARM64
>
> This will break 32-bit platforms.
>
> --
> Regards,
> Sudeep
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCHv5 00/10] soc: ti: add OMAP PRM driver (for reset)
From: santosh.shilimkar @ 2019-09-20 19:19 UTC (permalink / raw)
To: Tony Lindgren, Tero Kristo
Cc: devicetree, linux-omap, robh+dt, p.zabel, ssantosh,
linux-arm-kernel
In-Reply-To: <20190920142849.GS5610@atomide.com>
On 9/20/19 7:28 AM, Tony Lindgren wrote:
> * Tero Kristo <t-kristo@ti.com> [190912 04:39]:
>> Hi,
>>
>> V5 of the series, re-sent the whole series as one patch was dropped.
>> Changes compared to v3/v4:
>>
>> - removed dependency towards clock driver (patch #5 was completely
>> dropped compared to v3/v4)
>> - dropped clocks property from dt binding
>> - re-added the pdata patch which was accidentally dropped out (it has
>> dependency towards this series.)
>>
>> The new implementation (without clock driver dependency) relies on the
>> bus driver to sequence events properly, otherwise some timeouts will
>> occur either at clock driver or reset driver end.
>
> With the two updated patches seems like we're done with this
> series?
>
> If so, I suggest either Santosh or me sets up an immutable
> branch against v5.3 or v5.4-rc1 that we all can merge in.
> I will need it for the related dts changes at least.
>
I will pick this up Tony and apply it once v5.4-rc1 is out.
Regards,
Santosh
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [GIT PULL] arm64: Fixes for -rc1
From: pr-tracker-bot @ 2019-09-20 19:10 UTC (permalink / raw)
To: Will Deacon
Cc: catalin.marinas, ndesaulniers, torvalds, linux-kernel,
linux-arm-kernel
In-Reply-To: <20190920133703.zor3t4dvwam6uyqj@willie-the-truck>
The pull request you sent on Fri, 20 Sep 2019 14:37:04 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git tags/arm64-fixes
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/8c2b418c3f95a488f5226870eee68574d323f0f8
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker
_______________________________________________
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] mt7601u: phy: simplify zero check on val
From: Jakub Kicinski @ 2019-09-20 18:45 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: kernel-janitors, netdev, linux-wireless, linux-kernel,
linux-mediatek, linux-arm-kernel, Matthias Brugger, Colin King,
David S . Miller, Kalle Valo
In-Reply-To: <20190920135817.GC6456@localhost.localdomain>
On Fri, 20 Sep 2019 15:58:17 +0200, Lorenzo Bianconi wrote:
> I think this is not correct since (not considering the cast) we should break
> from the loop if val != 0 and val != 0xff, so the right approach I guess is:
>
> diff --git a/drivers/net/wireless/mediatek/mt7601u/phy.c b/drivers/net/wireless/mediatek/mt7601u/phy.c
> index 06f5702ab4bd..d863ab4a66c9 100644
> --- a/drivers/net/wireless/mediatek/mt7601u/phy.c
> +++ b/drivers/net/wireless/mediatek/mt7601u/phy.c
> @@ -213,7 +213,7 @@ int mt7601u_wait_bbp_ready(struct mt7601u_dev *dev)
>
> do {
> val = mt7601u_bbp_rr(dev, MT_BBP_REG_VERSION);
> - if (val && ~val)
> + if (val && val != 0xff)
> break;
> } while (--i);
Yup, feel free to add my ack if you post this, Lorenzo.
_______________________________________________
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] Revert "ARM: bcm283x: Switch V3D over to using the PM driver instead of firmware."
From: Florian Fainelli @ 2019-09-20 17:52 UTC (permalink / raw)
To: Stefan Wahren, Eric Anholt, Florian Fainelli, Ray Jui,
Scott Branden, Paul Kocialkowski, boris.brezillon
Cc: stable, bcm-kernel-feedback-list, dri-devel, linux-arm-kernel
In-Reply-To: <1567957493-4567-1-git-send-email-wahrenst@gmx.net>
On 9/8/19 8:44 AM, Stefan Wahren wrote:
> Since release of the new BCM2835 PM driver there has been several reports
> of V3D probing issues. This is caused by timeouts during powering-up the
> GRAFX PM domain:
>
> bcm2835-power: Timeout waiting for grafx power OK
>
> I was able to reproduce this reliable on my Raspberry Pi 3B+ after setting
> force_turbo=1 in the firmware configuration. Since there are no issues
> using the firmware PM driver with the same setup, there must be an issue
> in the BCM2835 PM driver.
>
> Unfortunately there hasn't been much progress in identifying the root cause
> since June (mostly in the lack of documentation), so i decided to switch
> back until the issue in the BCM2835 PM driver is fixed.
>
> Link: https://github.com/raspberrypi/linux/issues/3046
> Fixes: e1dc2b2e1bef (" ARM: bcm283x: Switch V3D over to using the PM driver instead of firmware.")
> Cc: stable@vger.kernel.org
> Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
Do you want me to pick up this change directly, or would you want to
issue a pull request for 5.4-rcX with other fixes?
--
Florian
_______________________________________________
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] serial: bcm2835: Use devm_platform_ioremap_resource() in bcm2835aux_serial_probe()
From: Florian Fainelli @ 2019-09-20 17:51 UTC (permalink / raw)
To: Markus Elfring, linux-serial, linux-rpi-kernel, linux-arm-kernel,
bcm-kernel-feedback-list, Eric Anholt, Florian Fainelli,
Greg Kroah-Hartman, Jiri Slaby, Martin Sperl, Ray Jui,
Scott Branden, Stefan Wahren, Stephen Boyd
Cc: Bartosz Golaszewski, kernel-janitors, LKML, Himanshu Jha
In-Reply-To: <fcb34c72-89c7-9993-fc0a-ba3a61708bec@web.de>
On 9/18/19 1:12 PM, Markus Elfring wrote:
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Wed, 18 Sep 2019 22:00:14 +0200
>
> Simplify this function implementation by using a known wrapper function.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
_______________________________________________
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