* [PATCH v2 4/4] ARM64: dts: meson-gxbb: Add SPIFC node
From: Kevin Hilman @ 2016-09-12 17:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473409738-27175-5-git-send-email-jbrunet@baylibre.com>
Jerome Brunet <jbrunet@baylibre.com> writes:
> From: Neil Armstrong <narmstrong@baylibre.com>
>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Applied,
Kevin
^ permalink raw reply
* [PATCH v2 3/4] ARM64: dts: amlogic: add spi nor pins
From: Kevin Hilman @ 2016-09-12 17:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473409738-27175-4-git-send-email-jbrunet@baylibre.com>
Jerome Brunet <jbrunet@baylibre.com> writes:
> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
> ---
> arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 10 ++++++++++
> 1 file changed, 10 insertions(+)
Applied.
Kevin
^ permalink raw reply
* [PATCH v2 1/4] pinctrl: amlogic: gxbb: add spi nor pins
From: Kevin Hilman @ 2016-09-12 17:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473409738-27175-2-git-send-email-jbrunet@baylibre.com>
Jerome Brunet <jbrunet@baylibre.com> writes:
> Add EE domains pins for the SPI flash controller
>
> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Acked-by: Kevin Hilman <khilman@baylibre.com>
^ permalink raw reply
* [PATCH v2 2/2] atomic64: No need for CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
From: Vineet Gupta @ 2016-09-12 17:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473702432-8116-1-git-send-email-vgupta@synopsys.com>
This came to light when implementing native 64-bit atomics for ARCv2.
The atomic64 self-test code uses CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
to check whether atomic64_dec_if_positive() is available.
It seems it was needed when not every arch defined it.
However as of current code the Kconfig option seems needless
- for CONFIG_GENERIC_ATOMIC64 it is auto-enabled in lib/Kconfig and a
generic definition of API is present lib/atomic64.c
- arches with native 64-bit atomics select it in arch/*/Kconfig and
define the API in their headers
So I see no point in keeping the Kconfig option
Compile tested for:
- blackfin (CONFIG_GENERIC_ATOMIC64)
- x86 (!CONFIG_GENERIC_ATOMIC64)
- ia64
Cc: Richard Henderson <rth@twiddle.net>
Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Cc: Matt Turner <mattst88@gmail.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: "James E.J. Bottomley" <jejb@parisc-linux.org>
Cc: Helge Deller <deller@gmx.de>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Chris Metcalf <cmetcalf@mellanox.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: x86 at kernel.org
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Vineet Gupta <vgupta@synopsys.com>
Cc: Zhaoxiu Zeng <zhaoxiu.zeng@gmail.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Matthew Wilcox <willy@linux.intel.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Ming Lin <ming.l@ssi.samsung.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Borislav Petkov <bp@suse.de>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Boqun Feng <boqun.feng@gmail.com>
Cc: linux-alpha at vger.kernel.org
Cc: linux-kernel at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-mips at linux-mips.org
Cc: linux-parisc at vger.kernel.org
Cc: linuxppc-dev at lists.ozlabs.org
Cc: linux-s390 at vger.kernel.org
Cc: sparclinux at vger.kernel.org
Cc: linux-snps-arc at lists.infradead.org
Cc: linux-arch at vger.kernel.org
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
---
arch/alpha/Kconfig | 1 -
arch/arm/Kconfig | 1 -
arch/arm64/Kconfig | 1 -
arch/mips/Kconfig | 1 -
arch/parisc/Kconfig | 1 -
arch/powerpc/Kconfig | 1 -
arch/s390/Kconfig | 2 +-
arch/sparc/Kconfig | 1 -
arch/tile/Kconfig | 2 +-
arch/x86/Kconfig | 2 +-
lib/Kconfig | 3 ---
lib/atomic64_test.c | 4 ----
12 files changed, 3 insertions(+), 17 deletions(-)
diff --git a/arch/alpha/Kconfig b/arch/alpha/Kconfig
index 7f312d80b43b..0e49d39ea74a 100644
--- a/arch/alpha/Kconfig
+++ b/arch/alpha/Kconfig
@@ -15,7 +15,6 @@ config ALPHA
select GENERIC_IRQ_SHOW
select ARCH_WANT_IPC_PARSE_VERSION
select ARCH_HAVE_NMI_SAFE_CMPXCHG
- select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
select AUDIT_ARCH
select GENERIC_CLOCKEVENTS
select GENERIC_SMP_IDLE_THREAD
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index a9c4e48bb7ec..2a50957c7bfb 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1,7 +1,6 @@
config ARM
bool
default y
- select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
select ARCH_HAS_DEVMEM_IS_ALLOWED
select ARCH_HAS_ELF_RANDOMIZE
select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index bc3f00f586f1..3df2ca7efbcc 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -6,7 +6,6 @@ config ARM64
select ACPI_MCFG if ACPI
select ARCH_HAS_DEVMEM_IS_ALLOWED
select ARCH_HAS_ACPI_TABLE_UPGRADE if ACPI
- select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
select ARCH_HAS_ELF_RANDOMIZE
select ARCH_HAS_GCOV_PROFILE_ALL
select ARCH_HAS_KCOV
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 26388562e300..5bbea197c220 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -30,7 +30,6 @@ config MIPS
select HAVE_ARCH_TRANSPARENT_HUGEPAGE if CPU_SUPPORTS_HUGEPAGES && 64BIT
select RTC_LIB if !MACH_LOONGSON64
select GENERIC_ATOMIC64 if !64BIT
- select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
select HAVE_DMA_CONTIGUOUS
select HAVE_DMA_API_DEBUG
select GENERIC_IRQ_PROBE
diff --git a/arch/parisc/Kconfig b/arch/parisc/Kconfig
index af12c2db9bb8..8a96bdcc3807 100644
--- a/arch/parisc/Kconfig
+++ b/arch/parisc/Kconfig
@@ -14,7 +14,6 @@ config PARISC
select BUILDTIME_EXTABLE_SORT
select HAVE_PERF_EVENTS
select GENERIC_ATOMIC64 if !64BIT
- select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
select BROKEN_RODATA
select GENERIC_IRQ_PROBE
select GENERIC_PCI_IOMAP
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 927d2ab2ce08..18d1b42cf545 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -113,7 +113,6 @@ config PPC
select HAVE_DEBUG_KMEMLEAK
select ARCH_HAS_SG_CHAIN
select GENERIC_ATOMIC64 if PPC32
- select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
select HAVE_PERF_EVENTS
select HAVE_PERF_REGS
select HAVE_PERF_USER_STACK_DUMP
diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
index c109f073d454..af52b07efde2 100644
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@ -67,7 +67,7 @@ config DEBUG_RODATA
config S390
def_bool y
- select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
+ select ARCH_HAS_DEBUG_STRICT_USER_COPY_CHECKS
select ARCH_HAS_DEVMEM_IS_ALLOWED
select ARCH_HAS_ELF_RANDOMIZE
select ARCH_HAS_GCOV_PROFILE_ALL
diff --git a/arch/sparc/Kconfig b/arch/sparc/Kconfig
index 59b09600dd32..bfedbe0cb7b2 100644
--- a/arch/sparc/Kconfig
+++ b/arch/sparc/Kconfig
@@ -22,7 +22,6 @@ config SPARC
select HAVE_ARCH_TRACEHOOK
select HAVE_EXIT_THREAD
select SYSCTL_EXCEPTION_TRACE
- select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
select RTC_CLASS
select RTC_DRV_M48T59
select RTC_SYSTOHC
diff --git a/arch/tile/Kconfig b/arch/tile/Kconfig
index 78da75b670bc..12eda5440c93 100644
--- a/arch/tile/Kconfig
+++ b/arch/tile/Kconfig
@@ -3,7 +3,7 @@
config TILE
def_bool y
- select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
+ select ARCH_HAS_DEBUG_STRICT_USER_COPY_CHECKS
select ARCH_HAS_DEVMEM_IS_ALLOWED
select ARCH_HAVE_NMI_SAFE_CMPXCHG
select ARCH_WANT_FRAME_POINTERS
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 2a1f0ce7c59a..0cf609998550 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -23,7 +23,7 @@ config X86
select ARCH_CLOCKSOURCE_DATA
select ARCH_DISCARD_MEMBLOCK
select ARCH_HAS_ACPI_TABLE_UPGRADE if ACPI
- select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
+ select ARCH_HAS_DEBUG_STRICT_USER_COPY_CHECKS
select ARCH_HAS_DEVMEM_IS_ALLOWED
select ARCH_HAS_ELF_RANDOMIZE
select ARCH_HAS_FAST_MULTIPLIER
diff --git a/lib/Kconfig b/lib/Kconfig
index d79909dc01ec..0e74df3c5441 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -457,9 +457,6 @@ config NLATTR
config GENERIC_ATOMIC64
bool
-config ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
- def_bool y if GENERIC_ATOMIC64
-
config LRU_CACHE
tristate
diff --git a/lib/atomic64_test.c b/lib/atomic64_test.c
index dbb369145dda..46042901130f 100644
--- a/lib/atomic64_test.c
+++ b/lib/atomic64_test.c
@@ -213,7 +213,6 @@ static __init void test_atomic64(void)
r += one;
BUG_ON(v.counter != r);
-#ifdef CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
INIT(onestwos);
BUG_ON(atomic64_dec_if_positive(&v) != (onestwos - 1));
r -= one;
@@ -226,9 +225,6 @@ static __init void test_atomic64(void)
INIT(-one);
BUG_ON(atomic64_dec_if_positive(&v) != (-one - one));
BUG_ON(v.counter != r);
-#else
-#warning Please implement atomic64_dec_if_positive for your architecture and select the above Kconfig symbol
-#endif
INIT(onestwos);
BUG_ON(!atomic64_inc_not_zero(&v));
--
2.7.4
^ permalink raw reply related
* [arm-platforms:irq/irqchip-4.9 1/3] drivers/irqchip/irq-gic.c:100:34: error: implicit declaration of function 'raw_spin_lock_irqrestore'
From: kbuild test robot @ 2016-09-12 17:37 UTC (permalink / raw)
To: linux-arm-kernel
tree: https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git irq/irqchip-4.9
head: 7aaa3012a3d487cb852fd9ace4359e3994b05bad
commit: 05189a8d2fbddc41cb8b7b56f781430651ac8dd4 [1/3] irqchip: gic: Make locking a BL_SWITCHER only feature
config: arm-allmodconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 5.4.0-6) 5.4.0 20160609
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 05189a8d2fbddc41cb8b7b56f781430651ac8dd4
# save the attached .config to linux build tree
make.cross ARCH=arm
All error/warnings (new ones prefixed by >>):
drivers/irqchip/irq-gic.c: In function 'gic_set_affinity':
>> drivers/irqchip/irq-gic.c:100:34: error: implicit declaration of function 'raw_spin_lock_irqrestore' [-Werror=implicit-function-declaration]
#define gic_unlock_irqrestore(f) raw_spin_lock_irqrestore(&cpu_map_lock,\
^
>> drivers/irqchip/irq-gic.c:345:2: note: in expansion of macro 'gic_unlock_irqrestore'
gic_unlock_irqrestore(flags);
^
cc1: some warnings being treated as errors
vim +/raw_spin_lock_irqrestore +100 drivers/irqchip/irq-gic.c
94 #ifdef CONFIG_BL_SWITCHER
95
96 static DEFINE_RAW_SPINLOCK(cpu_map_lock);
97
98 #define gic_lock_irqsave(f) raw_spin_lock_irqsave(&cpu_map_lock,\
99 (f))
> 100 #define gic_unlock_irqrestore(f) raw_spin_lock_irqrestore(&cpu_map_lock,\
101 (f))
102
103 #define gic_lock() raw_spin_lock(&cpu_map_lock)
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/octet-stream
Size: 58520 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160913/9ee9aa59/attachment-0001.obj>
^ permalink raw reply
* [PATCH 4/7] phy: meson: add USB2 PHY support for Meson8b and GXBB
From: Kevin Hilman @ 2016-09-12 17:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAFBinCDnMd0rtrvTMX-D_WNXHpVD8F=8Xn35jcK5jTUCre9ebA@mail.gmail.com>
Martin Blumenstingl <martin.blumenstingl@googlemail.com> writes:
> On Fri, Sep 9, 2016 at 10:36 PM, Martin Blumenstingl
> <martin.blumenstingl@googlemail.com> wrote:
>> On Fri, Sep 9, 2016 at 5:33 PM, Kevin Hilman <khilman@baylibre.com> wrote:
>>> Martin Blumenstingl <martin.blumenstingl@googlemail.com> writes:
>>>
>>>> On Thu, Sep 8, 2016 at 10:53 PM, Ben Dooks <ben.dooks@codethink.co.uk> wrote:
>>>>> On 08/09/16 21:42, Kevin Hilman wrote:
>>>>>>
>>>>>> Ben Dooks <ben.dooks@codethink.co.uk> writes:
>>>>>>
>>>>>>> On 08/09/16 20:52, Martin Blumenstingl wrote:
>>>>>>>>
>>>>>>>> On Thu, Sep 8, 2016 at 9:35 PM, Kevin Hilman <khilman@baylibre.com>
>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> + phy = devm_phy_create(&pdev->dev, NULL, &phy_meson_usb2_ops);
>>>>>>>>>> + if (IS_ERR(phy)) {
>>>>>>>>>> + dev_err(&pdev->dev, "failed to create PHY\n");
>>>>>>>>>> + return PTR_ERR(phy);
>>>>>>>>>> + }
>>>>>>>>>> +
>>>>>>>>>> + if (usb_reset_refcnt++ == 0) {
>>>>>>>>>> + ret = device_reset(&pdev->dev);
>>>>>>>>>> + if (ret) {
>>>>>>>>>> + dev_err(&phy->dev, "Failed to reset USB PHY\n");
>>>>>>>>>> + return ret;
>>>>>>>>>> + }
>>>>>>>>>> + }
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The ref count + reset here looks like something that could/should be
>>>>>>>>> handled in a runtime PM callback.
>>>>>>>>
>>>>>>>> Unfortunately that doesn't work (as Jerome found out) because both
>>>>>>>> PHYs are sharing the same reset line.
>>>>>>>> So if the second PHY would call device_reset then it would also reset
>>>>>>>> the first PHY!
>>>>>>>>
>>>>>>>> There's a comment above the declaration of usb_reset_refcnt which
>>>>>>>> tries to explain this:
>>>>>>>> "The PHYs are sharing a common reset line -> we are only allowed to
>>>>>>>> reset once for all PHYs."
>>>>>>>> Maybe I should move this comment to the "if (usb_reset_refcnt++ == 0)
>>>>>>>> {" line to make it easier to see?
>>>>>>>>
>>>>>>>
>>>>>>> pm-runtime has refcounting in it. When one of the nodes turns on,
>>>>>>> the pm-runtime will call your driver to say there is a user when
>>>>>>> this first use turns up.
>>>>>>>
>>>>>>> If all the sub-phys turn off and drop their refcount then the driver
>>>>>>> is called to say there are no more users and you can go to sleep.
>>>>>>
>>>>>>
>>>>>> After a chat w/Martin on IRC, It turns out runtime PM wont help here.
>>>>>>
>>>>>> The reason is because there are physically two PHY devices[1]. Those 2
>>>>>> devices will be treated independely by runtime PM, and have separate
>>>>>> use-counting, which means doing what I proposed would cause a reset to
>>>>>> happen when either device was probed.
>>>>>>
>>>>>> So, I think it's OK as it is.
>>>>>
>>>>>
>>>>> Surely you can do pm_runtime_get/put on the phy's parent platform
>>>>> device and do it that way?
>>>> could you please be more specific with that (do you mean pdev->dev.parent)?
>>>> so we would use pm_runtime_{get_sync,put} with the parent, while we
>>>> would still define the runtime_resume in our driver.
>>>
>>> You'd also need to do get/put on the children, but yes, that's what Ben
>>> is suggesting.
>>>
>>> However, the problem with all of the solutions proposed (runtime PM ones
>>> included) is that we're forcing a board-specific design issue (2 devices
>>> sharing a reset line) into a driver that should not have any
>>> board-specific assumptions in it.
>>>
>>> For example, if this driver is used on another platform where different
>>> PHYs have different reset lines, then one of them (the unlucky one who
>>> is not probed first) will never get reset. So any form of per-device
>>> ref-counting is not a portable solution.
>> indeed, so in simple words we would need something like
>> reset_control_do_once(rstc, RESET/ASSERT/DEASSERT) which would
>> remember internally if any action has already been executed: if not it
>> does a _reset, _assert or _deassert and otherwise it does nothing.
> for now I've implemented something less hacky: I made the reset
> optional and only specified it for phy0.
That's slightly better, but could misbehave if devices are probed/loaded
in different order? But, that shouldn't be a blocker for the driver.
> During Jerome's tests the reset was not needed, while on my board it's
> required to bring both PHYs up.
> Additionally the USB PHY reference driver does not have any reset
> logic for newer SoCs (GXL), so making the reset optional doesn't sound
> that bad to me.
Agreed.
Kevin
^ permalink raw reply
* [RFC PATCH 0/5] arm64: Signal context expansion
From: Dave Martin @ 2016-09-12 17:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57D6DB80.4090105@arm.com>
On Mon, Sep 12, 2016 at 05:44:48PM +0100, Szabolcs Nagy wrote:
> On 12/09/16 16:30, Dave Martin wrote:
> > On Mon, Sep 12, 2016 at 04:01:17PM +0100, Szabolcs Nagy wrote:
> >> On 12/09/16 12:17, Dave Martin wrote:
> >
> > [...]
> >
> >>>> On 09/09/2016 05:21 PM, Dave Martin wrote:
> >
> > [...]
> >
> >>>>> I wonder whether we should make the signal stack size runtime
> >>>>> discoverable through sysconf() instead...
> >>>
> >>> I will likely suggest this for the future, but of course it doesn't help
> >>> for current binaries.
> >>>
> >>>
> >>> Note that MINSIGSTKSZ stared life wrong for arm64, and has since gone
> >>> through a few ABI breaking changes. I don't condone this, but we have
> >>> form in this area :/
> >>>
> >>> sigaltstack() already fails with ENOMEM for software that passes
> >>> ss_size = MINSIGSTKSZ, and is built against glibc<2.22 [1], [2], running
> >>> on linux>=4.3 [3], which is an ABI break in case where sigaltstack() is
> >>> otherwise guaranteed to succeed.
> >>>
> >>
> >> yes, this was abi breaking change.
> >>
> >> if glibc does not care about existing binaries
> >> that use sigaltstack with MINSIGSTKSZ then it can
> >> increase the size, but i think the kernel should
> >> not change the abi (there are other libcs and libc
> >> independent runtime systems on linux for aarch64
> >> with their own sigaltstack setup, not all of them
> >> may care about SVE).
> >>
> >> i assume the kernel can avoid saving SVE regs when
> >> they are not used by the process.
> >
> > I can (and do), in my patches (not posted yet).
> >
> > The real issue here is that a recently updated shared library might be
> > optimised to use SVE, where the program using it is an older, SVE-
> > unaware binary.
> >
> > (think of an optimised math library using some new fancy SVE-based
> > number crunching internally).
> >
>
> this is why sve would be a new abi in an ideal world,
> instead of subtly changing behaviour behind existing
> binaries.
Well, indeed.
In an ideal world, we also like to be able to make use of new features
though.
> >>
> >>>
> >>> The bottom line here is that the sigaltstack() API is broken with regard
> >>> to extensibility, so we cannot extend the amount of signal state without
> >>> breaking something.
> >>>
> >>
> >> extending signal state can break things independently
> >> of sigaltstack.
> >>
> >> binaries with strict guarantees about worst case stack
> >> usage can change behaviour.
> >
> > Indeed, but this is not a new issue. Software must run with enough
> > stack in order to be portable, but there is no portable way to determine
> > how much stack is needed.
> >
>
> why not?
>
> musl libc has stack usage guarantee that can be checked
> by the compiler that built the libc on all supported
> targets. (with some manual checks in a few cases.)
"Requires some specific, nonstandard libc" = "not portable".
I don't say that this isn't a good feature of musl libc, just that this
feature is not generally available.
> however as soon as targets change the signal frame size
> randomly, these worst case guarantees get broken.
> (musl's MINSIGSTKSZ was always 6k on aarch64, even
> before the kernel changed it.)
Unfortunately, that is true. Any component (including libc) that makes
assumptions about the kernel signal stack overhead may break.
(Whether musl should have invented its own magic number for MINSIGSTKSZ
instead of adding its own known overhead to the kernel's MINSIGSTKSZ is
debatable, but in this case it is lucky that it did.)
> >> fortunately glibc PTHREAD_STACK_MIN is huge on aarch64
> >> so applications using it are unlikely to break because
> >> of the increased signal state.
> >> (this also means it's impossible to have threads with
> >> tiny stacks on glibc, so large amount of threads means
> >> large amount of commit charge.)
> >
> > Again, not a new problem.
> >
>
> on musl PTHREAD_STACK_MIN is small, so the sve signal
> state can break existing binaries that use tiny thread
> stack (there is at least one linux distro that supports
> musl+aarch64, although they don't distribute binary
> packages yet).
>
> so even if the glibc abi changes, i think the kernel
> should not do the change, at least not immediately.
>
> (and if the kernel decides to increase MINSIGSTKSZ
> i think it should wait for distros picking up new
> enough glibc with increased MINSIGSTKSZ to avoid
> spuriously failing sigaltstack calls.)
So, increasing MINSIGSTKSZ doesn't look a great idea, partly because it
breaks stuff, and partly because there is no correct value to change it
to -- we may have to make the same break all over again, at some point
in the future, or set it to something ridiculously large.
I think it's clear that this series needs to honor (and refuse to
overrun) the alternate signal stack size down to the "legacy"
MINSIGSTKSZ (5K).
But how to ensure that software that was built "too small" a MINSIGSTKSZ
for all arch extensions known to the running kernel is a separate
problem that needs careful thought and libc involvement.
Cheers
---Dave
^ permalink raw reply
* [PATCH] Revert "Input: bma150 - extend chip detection for bma180"
From: H. Nikolaus Schaller @ 2016-09-12 17:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a156f29f-43db-6811-7f7e-ac2c7682d766@redhat.com>
Hi,
> Am 12.09.2016 um 16:44 schrieb Hans de Goede <hdegoede@redhat.com>:
>
> Hi,
>
> On 12-09-16 16:31, H. Nikolaus Schaller wrote:
>> Hi,
>>
>>> Am 11.09.2016 um 18:43 schrieb Hans de Goede <hdegoede@redhat.com>:
>>>
>>> This reverts commit ef3714fdbc8d ("Input: bma150 - extend chip
>>> detection for bma180").
>>>
>>> The bma180 is not compatible with the bma150 at all, it has 14 bits
>>> resolution instead of 10, and it has quite different control registers.
>>>
>>> Treating the bma180 as a bma150 wrt its data registers will just result
>>> in throwing away the lowest 4 bits, which is not too bad. But the ctrl
>>> registers are a different story.
>>>
>>> It may be that things happen to just work (I don't have a bma180 to
>>> test with) but that certainly does not make this right.
>>
>> Yes, looks as if your observation is right. Thanks for pointing this out!
>>
>> This did need me some research to find an answer...
>>
>> If I remember correctly, the original patch was based on a recommendation
>> from someone I don't remember, who said that the chips are the same in a
>> different package. So we added the chip_id and it worked immediately as
>> expected. It looks as if we did not check the data sheets. So we did not
>> question this recommendation.
>>
>>>
>>> Removing the bma180 id also removes overlap wrt the ids in the iio
>>> bma180 driver which does treat the bma180 properly.
>>
>> Nack.
>>
>> The problem we get is that an iio driver is not an input driver and can't
>> easily replace it.
>
> Actually almost all accelerometer drivers in the Linux kernel are
> iio drivers,
Yes, that is a good move indeed to make them more general.
> the bma150 driver is the odd duck out,
Indeed it seems to be in /misc for some reason.
> that is why
> we've iio-sensor-proxy for apps which want the accelerometer
> to behave as an input device:
>
> https://github.com/hadess/iio-sensor-proxy
Does this provide an input device /dev/input/event?
>From a first look it seems to provide a D-Bus abstraction which is
not the same as an /dev/input/event.
What about latency?
A kernel driver can react on a sensor interrupt, queue results
and sleep.
Isn't a user-space process more resource hungry than a kernel thread?
>
>> An input driver can be used for gesture applications (e.g. detecting
>> the device has been turned upside down) and can report X/Y/Z coordinates
>> to e.g. X11 for games similar to a mouse or joystick (which the iio driver
>> doesn't).
>
> See above.
>
>> So it should remain configurable which of both driver options is loaded,
>> to match user space API needs.
>>
>> BTW: id overlap is only a problem if both drivers are configured in parallel.
>
> Right, so it is "only" a problem to any generic distro which tries to
> support both bma150 and bma250 accelerometers, as both the input
> bma150 as well as the iio bma250 driver claim to be bma180 compatible.
Well, it is only a problem if such a generic distro is really run on a device
which has a bma180 defined in DT. There do not seem to exist many of these.
>
>> Next, I have tried to find out which devices really use the bma150 and bma180.
>>
>> It appears that no in-tree device uses the bma150 while the GTA04 uses
>> the bma180 (in DT), but not in any defconfig (the GTA04 specific config
>> is not upstreamable since omap2plus_defconfig exists).
>>
>> In user-space the GTA04 requires and actively uses this input driver for Replicant.
>>
>> So I would conclude that this revert does not improve/fix any device using a
>> bma150 (if it exists at all), but breaks an existing device.
>>
>> What options do we have?
>>
>> a) add proper register number constants and choose conditionally (where they differ)
>> b) drop bma150 support completely and change registers for bma180
>> c) clone the bma150 input driver into an bma180 input driver and fix registers
>> d) extend the bma180 iio driver to optionally provide an input device
>> e) write a generic input/iio-accel wrapper (which should work with any iio accelerometer)
>>
>> I would favour approach e)
>
> Good, because that solution already exists :) See:
> https://github.com/hadess/iio-sensor-proxy
No, it is yet another option. I would formulate it as:
f) break user-space compatibility for existing systems and write / require
a user-space workaround.
This is something which is the least favorite in my view.
Since we have no control over the user space people have installed and IMHO
a kernel shouldn't break APIs too often or only for really good reasons
(e.g. completely new functions).
And we have no means to force user-space developers to integrate such daemons :(
So we break a device by upgrading to 4.9-kernel but can't give a solution.
>
>> but it has an issue I have no solution for:
>>
>> how to define in DT (or CONFIG?) which iio accelerometer(s) should
>> be wrapped and presented as input device(s).
>
> I believe currently iio-sensor-proxy simply wraps all accelerometers
> it can find, which seems the right thing to do. Usually we're running
> a generic desktop-ish OS / distro which wants these devices
> to be available as input devices;
> for special cases like actual
> robots and stuff running Linux, iio-sensor-proxy can simply be
> disabled; or not installed at all.
Well, the GTA04 we talk about falls into a third category: a mobile device.
Which is not running a desktop-ish OS / distro. It is running Replicant,
QtMoko, SHR, FSO or other user spaces which partially rely on /dev/input/event
without starting a daemon. At least in current releases and we have little
influence to have them use a new daemon.
So I would strongly prefer if we can solve this in the kernel and keep the
user-space API for the bma180 input driver stable.
>
> So all in all I believe that this is a solved problem, since
> solution e. from above is already implemented.
Well it is also solved if we do not revert the patch at all, because it
works in practice (even if not exactly correct) and is compatible to
existing user-space.
In summary I don't like option f) because it creates more problems than
it solves.
If e) is ruled out, IMHO the second best option seems to be d) to add a
CONFIG_BMA180_INPUT_DEVICE and make it present some additional /dev/input/event
in parallel to the iio interface.
I already have a similar approach in my to-be-upstreamed queue for the tsc2007
touch screen driver to provide additional iio channels for raw values, chip
temperature and the auxiliary general purpose ADC (which is used as ambient
light sensor in the GTA04).
So let's develop some patch for drivers/iio/accel/bma180.c before we revert
this bma150 patch and have nothing.
BR,
Nikolaus Schaller
>
> Regards,
>
> Hans
>
>
>
>>
>> Well, it could be as simple as defining a virtual "input-iio-accel" wrapper
>> driver with no real hardware behind and provide a reference to the iio DT node.
>> But I think such virtual devices are against DT style.
>>
>> So I don't know how to implement it in an acceptable way.
>>
>> Ideas?
>>
>> BR and thanks,
>> Nikolaus Schaller
>>
>>>
>>> Cc: Dr. H. Nikolaus Schaller <hns@goldelico.com>
>>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>>> ---
>>> drivers/input/misc/bma150.c | 4 +---
>>> 1 file changed, 1 insertion(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/input/misc/bma150.c b/drivers/input/misc/bma150.c
>>> index b0d4453..cae4832 100644
>>> --- a/drivers/input/misc/bma150.c
>>> +++ b/drivers/input/misc/bma150.c
>>> @@ -70,7 +70,6 @@
>>> #define BMA150_CFG_5_REG 0x11
>>>
>>> #define BMA150_CHIP_ID 2
>>> -#define BMA180_CHIP_ID 3
>>> #define BMA150_CHIP_ID_REG BMA150_DATA_0_REG
>>>
>>> #define BMA150_ACC_X_LSB_REG BMA150_DATA_2_REG
>>> @@ -539,7 +538,7 @@ static int bma150_probe(struct i2c_client *client,
>>> }
>>>
>>> chip_id = i2c_smbus_read_byte_data(client, BMA150_CHIP_ID_REG);
>>> - if (chip_id != BMA150_CHIP_ID && chip_id != BMA180_CHIP_ID) {
>>> + if (chip_id != BMA150_CHIP_ID) {
>>> dev_err(&client->dev, "BMA150 chip id error: %d\n", chip_id);
>>> return -EINVAL;
>>> }
>>> @@ -643,7 +642,6 @@ static UNIVERSAL_DEV_PM_OPS(bma150_pm, bma150_suspend, bma150_resume, NULL);
>>>
>>> static const struct i2c_device_id bma150_id[] = {
>>> { "bma150", 0 },
>>> - { "bma180", 0 },
>>> { "smb380", 0 },
>>> { "bma023", 0 },
>>> { }
>>> --
>>> 2.9.3
>>>
>>
^ permalink raw reply
* [PATCH 2/3] ARM64: dts: amlogic: Add basic support for Amlogic S905X
From: Carlo Caione @ 2016-09-12 17:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7e27e8c0-bb18-40d8-10d6-3928e66815c7@suse.de>
On Mon, Sep 12, 2016 at 6:28 PM, Andreas F?rber <afaerber@suse.de> wrote:
>> +Boards with the Amlogic Meson GXL SoC shall have the following properties:
>> + Required root node property:
>> + compatible: "amlogic,meson-gxl-s905x", "amlogic,meson-gxl";
>
> Can we please use "amlogic,s905x", "amlogic,meson-gxl"? No need to
> complicate the name. Also affects .dtsi and .dts below.
gxl != s905x.
AFAWK to the GXL family belong several different SoCs, like S905X,
S905D, etc... (see patch 3/3)
This is why we use meson-gxl-s905x, meson-gxl-s905d, etc...
We could s/meson-gxl-s905x/meson-s905x/ and
s/meson-gxl-s905d/meson-s905d/ but I honestly prefer this way because
we can clearly see which family the SoC belongs to (the Amlogic naming
convention is already messy enough).
I mean, yes it's longer, but it's for the sake of documentation IMO.
[cut]
>> + compatible = "amlogic,p212", "amlogic,meson-gxl-s905x", "amlogic,meson-gxl";
>> + model = "Amlogic Meson GXL (S905X) P212 Development Board";
>
> Is that its official name? No objection, just wondering whether we need
> both GXL and S905X in the name, and then again the SoC name at all if
> the P212 is unique. Haven't compared the previous Pxxx ones.
P212 is the official name for the S905X Amlogic dev board. It follows
the name we used for the other P20x boards.
[cut]
>> +
>> +/* This UART is brought out to the DB9 connector */
>> +&uart_AO {
>> + status = "okay";
>> +};
>> +
>
> Trailing white line - please watch out for that, git-am will complain.
Right.
[cut]
>> +#include "meson-gxl.dtsi"
>> +
>> +/ {
>> + compatible = "amlogic,meson-gxl", "amlogic,meson-gxl-s905x";
>
> This needs to be reversed.
Agree.
Cheers,
--
Carlo Caione
^ permalink raw reply
* [PATCH v5 02/16] dt/bindings: Update binding for PM domain idle states
From: Sudeep Holla @ 2016-09-12 17:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160912161600.GA21885@linaro.org>
On 12/09/16 17:16, Lina Iyer wrote:
> On Mon, Sep 12 2016 at 09:19 -0600, Brendan Jackman wrote:
>>
>> Hi Lina,
>>
>> Sorry for the delay here, Sudeep and I were both been on holiday last
>> week.
>>
>> On Fri, Sep 02 2016 at 21:16, Lina Iyer wrote:
>>> On Fri, Sep 02 2016 at 07:21 -0700, Sudeep Holla wrote:
>> [...]
>>>> This version is *not very descriptive*. Also the discussion we had
>>>> on v3
>>>> version has not yet concluded IMO. So can I take that we agreed on what
>>>> was proposed there or not ?
>>>>
>>> Sorry, this example is not very descriptive. Pls. check the 8916 dtsi
>>> for the new changes in the following patches. Let me know if that makes
>>> sense.
Please add all possible use-cases in the bindings. Though one can refer
the usage examples, it might not cover all usage descriptions. It helps
preventing people from defining their own when they don't see examples.
Again DT bindings are like specifications, it should be descriptive
especially this kind of generic ones.
>>
>> The not-yet-concluded discussion Sudeep is referring to is at [1].
>>
>> In that thread we initially proposed the idea of, instead of splitting
>> state phandles between cpu-idle-states and domain-idle-states, putting
>> CPUs in their own domains and using domain-idle-states for _all_
>> phandles, deprecating cpu-idle-states. I've brought this up in other
>> threads [2] but discussion keeps petering out, and neither this example
>> nor the 8916 dtsi in this patch series reflect the idea.
>>
> Brendan, while your idea is good and will work for CPUs, I do not expect
> other domains and possibly CPU domains on some architectures to follow
> this model. There is nothing that prevents you from doing this today,
> you can specify domains around CPUs in your devicetree and CPU PM will
> handle the hierarchy. I don't think its fair to force it on all SoCs
> using CPU domains.
I disagree. We are defining DT bindings here and it *should* be same for
all the SoC unless there is a compelling reason not to. I am fine if
those reasons are stated and agreed.
> This patchset does not restrict you from organizing
> the idle states the way you want it. This revision of the series, clubs
> CPU and domain idle states under idle-states umbrella. So part of your
> requirement is also satisfied.
>
I will look at the DTS changes in the series. But we *must* have more
description with more examples in the binding document.
> You can follow up the series with your new additions, I don't see a
> conflict with this change.
>
If we just need additions, then it should be fine.
--
Regards,
Sudeep
^ permalink raw reply
* ARM, SoC: About the use DT-defined properties by 3rd-party drivers
From: Mark Rutland @ 2016-09-12 17:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57D6DC83.8020000@tabi.org>
On Mon, Sep 12, 2016 at 11:49:07AM -0500, Timur Tabi wrote:
> Warner Losh wrote:
> >Do I have more examples
> >where FreeBSD has to deviate because the DT is actually Linux
> >specific and does a poor job of modeling the hardware and instead
> >reflects the Linux driver model? I have plenty of those...
>
> I think it would be a great idea if the FreeBSD and Linux DT
> maintainers collaborated on cleaning up the DT bindings so that this
> problem no longer occurs (or at least, not normally).
Indeed. Theoretically/hopefully, the devicetree.org stuff creates a more
inclusive forum for this.
Thanks,
Mark.
^ permalink raw reply
* [PATCH 6/8 v2] arm: orion5x: Add DT-based support for Netgear WNR854T
From: Rob Herring @ 2016-09-12 17:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473109646-23366-1-git-send-email-jm@lentin.co.uk>
On Mon, Sep 05, 2016 at 10:07:26PM +0100, Jamie Lentin wrote:
> This is a router based on the mv88f5181 chipset.
>
> http://www.netgear.com/support/product/WNR854T.aspx
> http://wiki.openwrt.org/toh/netgear/wnr854t
>
> Signed-off-by: Jamie Lentin <jm@lentin.co.uk>
> ---
> This removes the contentious vendor partitioning scheme and goes back
> to the original partitioning scheme used in non-DT ports to this board.
> Using the same partitioning scheme should mean less surprises for
> someone trying to upgrade their router.
>
> The non-DT PCI setup is still here, as there are other orion5x DT boards
> doing very similar things, and can all be converted at the same time.
If we keep accepting this duplicated, legacy PCI setup, who is going to
be motivated to clean things up. But it's ultimately up to Arnd and
Olof.
> The patchset in it's entirety is available at
> https://github.com/lentinj/linux wnr854t-support-v2
>
> Cheers,
> ---
> .../bindings/arm/marvell/marvell,orion5x.txt | 1 +
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/orion5x-netgear-wnr854t.dts | 197 +++++++++++++++++++++
Acked-by: Rob Herring <robh@kernel.org>
> arch/arm/mach-orion5x/Kconfig | 6 +
> arch/arm/mach-orion5x/Makefile | 1 +
> arch/arm/mach-orion5x/board-wnr854t.c | 78 ++++++++
> 6 files changed, 284 insertions(+)
> create mode 100644 arch/arm/boot/dts/orion5x-netgear-wnr854t.dts
> create mode 100644 arch/arm/mach-orion5x/board-wnr854t.c
^ permalink raw reply
* ARM, SoC: About the use DT-defined properties by 3rd-party drivers
From: Mark Rutland @ 2016-09-12 17:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANCZdfqZEMRaFqgph6kZPdyxBcURBiEV0XoH0vPG28Hhm5+77A@mail.gmail.com>
Hi,
On Mon, Sep 12, 2016 at 10:45:37AM -0600, Warner Losh wrote:
> Do I have more examples where FreeBSD has to deviate because the DT is
> actually Linux specific and does a poor job of modeling the hardware
> and instead reflects the Linux driver model? I have plenty of those...
I guess you don't actually have those written down, but on the
off-chance, would you be able to share any major pain points?
We do try (admittedly far from perfectly) to avoid implementation
details in bindings, but driver mdoel details are fairly difficult to
pin down either way. It would be nice to be more aware.
Thanks,
Mark.
^ permalink raw reply
* ARM, SoC: About the use DT-defined properties by 3rd-party drivers
From: Mark Rutland @ 2016-09-12 16:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57D6D2A9.3010006@laposte.net>
On Mon, Sep 12, 2016 at 06:07:05PM +0200, Sebastian Frias wrote:
> On 09/12/2016 04:01 PM, Mark Rutland wrote:
> > Few devices these says are entirely independent, and most devices can be
> > instantiated multiple times (even if there happens to only be a single
> > instance in practice). For the example of a userspace driver there are
> > very real ABI concerns, such as how the device(s) are discovered, how
> > any related components like regulators and clocks are controlled, etc.
> >
> > There are ramifications here, and it's a dangerous over simplification
> > to say that this doesn't matter because we're not changing kernel code.
> >
> >> Besides, what "makes sense now" may "not make sense tomorrow" depending on
> >> how the HW is modified.
> >
> > That's always the case when a new generation of hardware comes out, so I
> > don't think that's relevant to the topic at hand.
>
> Exactly, that's why to I'm having trouble to understand why there is so much
> insistence on "getting the DT 100% right", since a HW change could imply
> that what made 100% sense yesterday, does not today.
> Since that is a possibility we have to live with, then the "100% right" goal
> is most likely unachievable.
> That's different from "backwards compatibility" for which some technique,
> like alternate descriptions, can be put in place.
I'm not on about "100% right", but more "a reasonable chance of being
good enough". The latter is extremely difficult to judge when you just
get a binding document with little or no additional context.
Backwards compatibility is with regards to new software supporting old
bindings. If new HW comes out, we can create new bindings. Old bindings
should remain supported regardless.
> >> Actually, I think it would encourage more SoC manufacturers to use DT as a way
> >> to document their HW, which is a good thing.
> >
> > Writing and reviewing bindings is a very tricky topic, as it can require
> > fairly intimate knowledge of a piece of hardware. I've repeatedly found
> > that binding descriptions did not match the realities of the hardware,
> > and I've only managed to do so by looking at accompanying driver code.
> >
> > Given that manuals and other information on devices are often not freely
> > available (if they exist at all), the proposal effectively limits myself
> > and others to spot common (anti)patterns, which is far less than ideal,
> > and will result in more mistakes.
> >
> > As it stands, the proposal asks for effort for the community (in terms
> > of review and maintenance of bindings), with no benefit to the kernel
> > community, and a number of pitfalls that we would rather avoid.
>
> Could you be more precise on those two issues? Namely:
> "the effort" and the "lack of benefit for the community"?
As above, reviewing is tricky. One has to spend the time gaining an
understanding of a particular piece of hardware, the class of hardware
it falls in, and also the bigger picture that it fits in. Once you have
that, you have to review the binding in that context, and that takes
time and effort.
As things evolve, perhaps mistakes or inconsistencies are found, or new
ways to generalise things. As that occurs, there is a maintenance burden
for existing bindings.
All of that takes time and effort.
If, at the end of that, a proprietary vendor driver is using a different
version of the binding anyway, because "there's no backward
compatibility to guarantee", then there is no benefit to the document.
Even if that proprietary driver does remain stable, the Linux community
will have done work that only benefits the authors of that driver. We
would prefer that the results of our efforts are open, and benefit all.
> I can understand the effort it takes to review a binding and some
> driver, but if there's no driver, why would it matter if the DT binding is
> 100% right? Hence, why would it take more effort?
> Furthermore, if there's no driver, there's no backward compatibility to
> guarantee. Shouldn't it require less effort?
I don't follow. If there's no compatibility to guarantee, why do you
want a binding?
A binding is a form of contract -- if you describe the HW this way, then
some software will understand it. You can extend a binding over time,
certainly, but if the baseline of that binding is a moving target, that
benefits nobody.
[...]
> >> But if I understood correctly your comment, you are basically saying that
> >> without an example is hard to say.
> >> Since the question seems understood, do you have an example of other SoC's
> >> doing something similar?
> >
> > I do not have an example. I know that others are using DT for data
> > beyond what Linux or another OS requires, but it's my understanding that
> > that is typically in a separate DTB.
>
> I see, although I don't understand how accepting such solution (i.e.: having the
> information in a different DT) benefits the open-source community, since it
> basically means that the open-source community settles for less information.
As with all things, it depends on context. If someone's using a DT to
describe details of the secure world of a platform with trustzone to a
secure OS, then not all of that information is relevant to Linux.
Likewise if configuration details specific to FW are embedded.
If there's information relevant to a general purpose OS, then I would
expect it to be described. By the same token, I would expect a general
purpose OS to actually be making use of the information. In practice,
we've used Linux as the benchmark for that. That needn't necessarily be
the case if another OS can demonstrate that the binding is worthwhile --
ideally we'd have multiple OSs using bindings so as to "keep us honest"
and free from implementation details.
As I mentioned before, an example would help. The theoretical envelope
is very large and likely far beyond what you envisage. We need something
to focus on, or we're arguing about what we conceive differently.
Thanks,
Mark.
^ permalink raw reply
* [PATCH v2 00/17] Make rpmsg a framework
From: Lina Iyer @ 2016-09-12 16:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1472768889-3906-1-git-send-email-bjorn.andersson@linaro.org>
Hi Bjorn,
On Thu, Sep 01 2016 at 16:28 -0600, Bjorn Andersson wrote:
>This series splits the virtio rpmsg bus driver into a rpmsg bus and a virtio
>backend/wireformat.
>
>
>As we discussed the Qualcomm SMD implementation a couple of years back people
>suggested that I should make it "a rpmsg thingie". With the introduction of the
>Qualcomm 8996 platform, we must support a variant of the communication
>mechanism that share many of the characteristics of SMD, but are different
>enough that it can't be done in a single implementation. As such there is
>enough benefit to do the necessary work and being able to make SMD a "rpmsg
>thingie".
>
>On-top of this series I have patches to switch the current smd clients over to
>rpmsg (and by that drop the existing SMD implementation).
>
>All this allows me to implement the new backend and reuse all existing SMD
>drivers with the new mechanism.
>
RPM Communication has to supported even when IRQs are disabled. The most
important use of this communication is to set the wake up time for the
CPU subsystem when all the CPUs are powered off. In addition to that,
"sleep" votes that are sent by the application processor subsystem to
allow system to go into deep sleep modes can only be triggered when the
CPU PM domains are power collapsed, drivers do not have a knowledge of
when that happens. This has to be done by a platform code that registers
for CPU PM domain power_off/on callbacks.
Using rpmsg may be nice for RPM SMD communication, but mutexes need to
go away for this driver to be any useful than bare bones active mode
resource requests for QCOM SoCs. By not doing that now, we lock
ourselves out of using this SMD driver in the near future when CPU PM
domains are available in the kernel with an ability to do system low
power modes.
I hope you would make rpmsg work in IRQ disabled contexts first before
porting the SMD driver.
Thanks,
Lina
>
>Changes from v1:
>- Split up the patch moving core code to rpmsg_core into several commits
>- Dropped the wrapping struct in rpmsg_core and just added the ops to the
> public API (but hid the implementation details)
>- Reordered things to reduce the size of the later patches
>
>Bjorn Andersson (17):
> rpmsg: Enable matching devices with drivers based on DT
> rpmsg: Name rpmsg devices based on channel id
> rpmsg: rpmsg_send() operations takes rpmsg_endpoint
> rpmsg: Make rpmsg_create_ept() take channel_info struct
> rpmsg: Clean up rpmsg device vs channel naming
> rpmsg: Introduce indirection table for rpmsg_device operations
> rpmsg: Move rpmsg_device API to new file
> rpmsg: Indirection table for rpmsg_endpoint operations
> rpmsg: Move endpoint related interface to rpmsg core
> rpmsg: Move helper for finding rpmsg devices to core
> rpmsg: Split off generic tail of create_channel()
> rpmsg: Split rpmsg core and virtio backend
> rpmsg: Hide rpmsg indirection tables
> rpmsg: virtio: Hide vrp pointer from the public API
> rpmsg: Move virtio specifics from public header
> rpmsg: Allow callback to return errors
> rpmsg: Introduce Qualcomm SMD backend
>
> drivers/remoteproc/Kconfig | 4 +-
> drivers/rpmsg/Kconfig | 14 +
> drivers/rpmsg/Makefile | 4 +-
> drivers/rpmsg/qcom_smd.c | 1434 +++++++++++++++++++++++++++++++++++
> drivers/rpmsg/rpmsg_core.c | 498 ++++++++++++
> drivers/rpmsg/rpmsg_internal.h | 82 ++
> drivers/rpmsg/virtio_rpmsg_bus.c | 487 +++++-------
> include/linux/rpmsg.h | 246 +-----
> samples/rpmsg/rpmsg_client_sample.c | 14 +-
> 9 files changed, 2266 insertions(+), 517 deletions(-)
> create mode 100644 drivers/rpmsg/qcom_smd.c
> create mode 100644 drivers/rpmsg/rpmsg_core.c
> create mode 100644 drivers/rpmsg/rpmsg_internal.h
>
>--
>2.5.0
>
>--
>To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
>the body of a message to majordomo at vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCHv6 0/3] pwm: imx: support output polarity inversion
From: Stefan Agner @ 2016-09-12 16:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160912140401.qkezay7sqqavsf4i@pengutronix.de>
Hi,
Thanks for that insight Uwe!
On 2016-09-12 07:04, Uwe Kleine-K?nig wrote:
> Hello,
>
> On Mon, Sep 12, 2016 at 02:45:53PM +0200, Alexandre Belloni wrote:
>> Isn't a properly designed PWM putting a high level on its pin when
>> disabled and configured with inversed polarity ?
>
> it's not well defined. When trying several times over the years to
> properly define and document it, I didn't manage to agree with Thierry
> what is the right thing to define.
>
> IMHO it would be sensible to make it explicitly undefined what happens
> when a PMW is disabled. This would simplify drivers from
>
> pwm_config(mypwm, value, period);
> if (!value)
> pwm_disable(mypwm)
> else
> pwm_enable(led_dat->pwm);
>
> to
>
> pwm_config(mypwm, value, period);
>
> and let the pwm driver disable it's clock (or whatever) when value is 0
> and there are energy saving benefits that don't hurt the expected
> behaviour of the pin. So the hardware specific stuff is handled in the
> hardware specific driver and usage in pwm-consumers is simplified.
> Moreover this also simplifies some pwm drivers because they don't have
> to catch in software the cases where the hardware differs from the
> expectation[1].
That sounds like a sane definition to me and what I would have expected
from the PWM framework. That the pin is not defined after pwm_disable is
totally understandable. It is usually a case which the board designer
anyway needs to take care of (e.g. what is the state right after power
on? If the designer cares about, he will put a pull-up/down in place).
And it seems also Sascha suggested that:
https://lkml.org/lkml/2013/1/4/139
I did not found where Thierry disagreed to that...?
> Looking at drivers/leds/leds-pwm.c it doesn't ensure that each
> pwm_enable is paired by an pwm_disable (e.g. on .remove). Is this a bug?
> With my purposed semantics of .config and .disable this would be much
> easier to fix.
That looks like a bug to me.
>
> Regarding your question: Yeah, maybe all properly designed PWMs behave
> like you expect. But reality isn't only about properly designed
> hardware, so I wouldn't expect all hardware to behave. The inverse
> property might be software emulated and so on pwm_disable the pin might
> become 0.
>
> The obvious downside of my suggestion is that this is a change in what
> most people expect (because it was "safe" to call pwm_enable before),
> but the resulting code is simpler and cleaner.
>
> Today it's a (maybe small) bug, when a pwm consumer calls pwm_config with
> value=0 and doesn't disable it afterwards. IMHO that's a bug in the pwm
> API that pwm_config with value=0 doesn't imply (the wanted effects of)
> pwm_disable.
I don't quite get what you are saying here. What wanted effects of
pwm_disable would you like to move into pwm_config with value=0?
--
Stefan
>
> Best regards
> Uwe
>
> [1] This might even be impossible: Consider a PWM that gets 0 (or
> high-z) on hw-disable independent of configured duty or inversion. The
> driver now sees for an inverted pwm: pwm_config(this, 0, 100);
> pwm_disable(this); The driver cannot know if it should continue to drive
> the pin at 1, or if the pwm consumer stopped caring about the pwm and
> disabling the hardware is OK.
^ permalink raw reply
* ARM, SoC: About the use DT-defined properties by 3rd-party drivers
From: Timur Tabi @ 2016-09-12 16:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANCZdfqZEMRaFqgph6kZPdyxBcURBiEV0XoH0vPG28Hhm5+77A@mail.gmail.com>
Warner Losh wrote:
> Do I have more examples
> where FreeBSD has to deviate because the DT is actually Linux
> specific and does a poor job of modeling the hardware and instead
> reflects the Linux driver model? I have plenty of those...
I think it would be a great idea if the FreeBSD and Linux DT maintainers
collaborated on cleaning up the DT bindings so that this problem no
longer occurs (or at least, not normally).
I would love to see some of those examples.
^ permalink raw reply
* [PATCH v5] i2c: imx: make bus recovery through pinctrl optional
From: Leo Li @ 2016-09-12 16:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160909205926.dbxmvhqvfsqzk6dx@pengutronix.de>
On Fri, Sep 9, 2016 at 3:59 PM, Uwe Kleine-K?nig
<u.kleine-koenig@pengutronix.de> wrote:
> Hello,
>
> On Fri, Sep 09, 2016 at 01:34:31PM -0700, Stefan Agner wrote:
>> Yeah it is a bit a wording thing: In my understanding, pinctrl is
>> required on SoC's witch have a pin controller... It is just that the
>> driver does not need to get the pinctrl by itself because the stack is
>> taking care of it implicitly. And yes, that makes the particular example
>> not a real world example.
>
> At first I thought, too, that it's a fatal problem if getting the
> pinctrl stuff fails. IMHO that shows that the comments (or the code) are
> still not good enough.
Ya. If it has confused more than one people, it is likely to confuse
more. I agree with you that we should make it more clear.
Thanks,
Leo
^ permalink raw reply
* ARM, SoC: About the use DT-defined properties by 3rd-party drivers
From: Warner Losh @ 2016-09-12 16:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57D6D7D2.7030507@laposte.net>
On Mon, Sep 12, 2016 at 10:29 AM, Sebastian Frias <sf84@laposte.net> wrote:
> Hi Warner,
>
> On 09/12/2016 04:26 PM, Warner Losh wrote:
>> On Mon, Sep 12, 2016 at 8:01 AM, Mark Rutland <mark.rutland@arm.com> wrote:
>>>> Since the question seems understood, do you have an example of other SoC's
>>>> doing something similar?
>>>
>>> I do not have an example. I know that others are using DT for data
>>> beyond what Linux or another OS requires, but it's my understanding that
>>> that is typically in a separate DTB.
>>
>> Just to clarify: FreeBSD uses, for the most part, the DTB's that the
>> 'vendor' ships, which is quite often the same ones included in Linux.
>> There's some exceptions where the bindings weren't really hardware
>> independent, or where the abstraction model was really Linux specific
>> (for things like the HDMI stack).
>>
>> However, with the advent of overlays, one would think that a vendor
>> could easily include an overlay with the DTB data for the devices they
>> don't wish to, or cannot for other reasons release. It seems like the
>> perfect mechanism to comply with the rules about inclusion of nodes in
>> the DTS. Vendors are free to document these nodes and don't require
>> the Linux kernel include them in the Documents directory to do so.
>> There have been recent efforts to move this documentation to a third
>> party to maintain.
>
> This is very interesting, do you have a more concrete example of such
> usage?
Using overlays to layer in a proprietary device blob for a proprietary driver?
No. I don't. It just seems like a natural solution. Do I have more examples
where FreeBSD has to deviate because the DT is actually Linux
specific and does a poor job of modeling the hardware and instead
reflects the Linux driver model? I have plenty of those...
Warner
^ permalink raw reply
* [PATCH v4 0/5] arm/arm64: vgic-new: Implement API for vGICv3 live migration
From: Vijay Kilari @ 2016-09-12 16:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57D6AA83.6060208@arm.com>
On Mon, Sep 12, 2016 at 6:45 PM, Marc Zyngier <marc.zyngier@arm.com> wrote:
> On 10/09/16 13:22, vijay.kilari at gmail.com wrote:
>> From: Vijaya Kumar K <Vijaya.Kumar@cavium.com>
>>
>> This patchset adds API for saving and restoring
>> of VGICv3 registers to support live migration with new vgic feature.
>> This API definition is as per version of VGICv3 specification
>> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-July/445611.html
>>
>> Compatible live migration QEMU patches will be sent later.
>
> Could you please point to the QEMU patches as well? I need to be able to
> test the this infrastructure.
I just sent you corresponding QEMU patches.
Thanks
Vijay
>
> Thanks,
>
> M.
> --
> Jazz is not dead. It just smells funny...
^ permalink raw reply
* [RFC PATCH 0/5] arm64: Signal context expansion
From: Szabolcs Nagy @ 2016-09-12 16:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160912153015.GD3958@e103592.cambridge.arm.com>
On 12/09/16 16:30, Dave Martin wrote:
> On Mon, Sep 12, 2016 at 04:01:17PM +0100, Szabolcs Nagy wrote:
>> On 12/09/16 12:17, Dave Martin wrote:
>
> [...]
>
>>>> On 09/09/2016 05:21 PM, Dave Martin wrote:
>
> [...]
>
>>>>> I wonder whether we should make the signal stack size runtime
>>>>> discoverable through sysconf() instead...
>>>
>>> I will likely suggest this for the future, but of course it doesn't help
>>> for current binaries.
>>>
>>>
>>> Note that MINSIGSTKSZ stared life wrong for arm64, and has since gone
>>> through a few ABI breaking changes. I don't condone this, but we have
>>> form in this area :/
>>>
>>> sigaltstack() already fails with ENOMEM for software that passes
>>> ss_size = MINSIGSTKSZ, and is built against glibc<2.22 [1], [2], running
>>> on linux>=4.3 [3], which is an ABI break in case where sigaltstack() is
>>> otherwise guaranteed to succeed.
>>>
>>
>> yes, this was abi breaking change.
>>
>> if glibc does not care about existing binaries
>> that use sigaltstack with MINSIGSTKSZ then it can
>> increase the size, but i think the kernel should
>> not change the abi (there are other libcs and libc
>> independent runtime systems on linux for aarch64
>> with their own sigaltstack setup, not all of them
>> may care about SVE).
>>
>> i assume the kernel can avoid saving SVE regs when
>> they are not used by the process.
>
> I can (and do), in my patches (not posted yet).
>
> The real issue here is that a recently updated shared library might be
> optimised to use SVE, where the program using it is an older, SVE-
> unaware binary.
>
> (think of an optimised math library using some new fancy SVE-based
> number crunching internally).
>
this is why sve would be a new abi in an ideal world,
instead of subtly changing behaviour behind existing
binaries.
>>
>>>
>>> The bottom line here is that the sigaltstack() API is broken with regard
>>> to extensibility, so we cannot extend the amount of signal state without
>>> breaking something.
>>>
>>
>> extending signal state can break things independently
>> of sigaltstack.
>>
>> binaries with strict guarantees about worst case stack
>> usage can change behaviour.
>
> Indeed, but this is not a new issue. Software must run with enough
> stack in order to be portable, but there is no portable way to determine
> how much stack is needed.
>
why not?
musl libc has stack usage guarantee that can be checked
by the compiler that built the libc on all supported
targets. (with some manual checks in a few cases.)
however as soon as targets change the signal frame size
randomly, these worst case guarantees get broken.
(musl's MINSIGSTKSZ was always 6k on aarch64, even
before the kernel changed it.)
>> fortunately glibc PTHREAD_STACK_MIN is huge on aarch64
>> so applications using it are unlikely to break because
>> of the increased signal state.
>> (this also means it's impossible to have threads with
>> tiny stacks on glibc, so large amount of threads means
>> large amount of commit charge.)
>
> Again, not a new problem.
>
on musl PTHREAD_STACK_MIN is small, so the sve signal
state can break existing binaries that use tiny thread
stack (there is at least one linux distro that supports
musl+aarch64, although they don't distribute binary
packages yet).
so even if the glibc abi changes, i think the kernel
should not do the change, at least not immediately.
(and if the kernel decides to increase MINSIGSTKSZ
i think it should wait for distros picking up new
enough glibc with increased MINSIGSTKSZ to avoid
spuriously failing sigaltstack calls.)
> [...]
>
> Cheers
> ---Dave
>
^ permalink raw reply
* [PATCH v5] i2c: imx: make bus recovery through pinctrl optional
From: Leo Li @ 2016-09-12 16:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAChUvXMPDZB7=ZArQ5+6ae42N=Bsgv_OczGXnyhBjEdjt_yvsw@mail.gmail.com>
On Wed, Sep 7, 2016 at 5:07 AM, Tracy Smith <tlsmith3777@gmail.com> wrote:
> Hello, bus recovery is needed generally speaking because of potential
> protocol errors that might cause a failure condition hanging the bus.
>
> It happens frequently during bring-up of new I2C devices because firmware in
> I2C controllers fail to handle properly protocol errors.
>
> Can NXP add bus recovery for the LS1021A and LS1043A in a separate patch--
> unless there is no HW bus recovery mechanism?
>
> The concern is while fixing I.MX, NXP will fail to fix the driver bus
> recovery for the LS1021A and LS1043A and the bus will hang.
>
> If bus recovery is supported on the LS1021A and the LS1043A, a patch should
> be provided or added in this patch instead of simply disabling bus recovery.
> Request NXP to consider the patch if there is HW support for bus recovery.
FYI. http://patchwork.ozlabs.org/patch/573879/ This seem to be the
patch you are asking for. I have asked the original developer to
update the patch according to Wolfram's comment and work together with
the current pinctrl/gpio based recovery. In the meanwhile you can
make use of the patch for now for LS1021A and LS1043A if necessary.
Regards,
Leo
^ permalink raw reply
* [PATCH 2/7] [v2] dt-bindings: i2c: adds two more nxp devices
From: Rob Herring @ 2016-09-12 16:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473069695-33092-3-git-send-email-shh.xie@gmail.com>
On Mon, Sep 05, 2016 at 06:01:30PM +0800, shh.xie at gmail.com wrote:
> From: Shaohui Xie <Shaohui.Xie@nxp.com>
>
> "nxp,pcf2127" and "nxp,pcf2129" are I2c devices, adds them to the list
> of trivial i2c devices.
>
> Signed-off-by: Shaohui Xie <Shaohui.Xie@nxp.com>
> ---
> changes in V2:
> new patch.
>
> Documentation/devicetree/bindings/i2c/trivial-devices.txt | 2 ++
> 1 file changed, 2 insertions(+)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH v10 3/5] Documentation: bindings: add dt documentation for rk3399 dmc
From: Rob Herring @ 2016-09-12 16:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473051971-5500-4-git-send-email-hl@rock-chips.com>
On Mon, Sep 05, 2016 at 01:06:09PM +0800, Lin Huang wrote:
> This patch adds the documentation for rockchip rk3399 dmc driver.
>
> Signed-off-by: Lin Huang <hl@rock-chips.com>
> Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
> ---
> Changes in v10:
And this is the first I see it?
> - add rockchip prefix in property describe
>
> Changes in v9:
> - add ddr timing property to node
>
> Changes in v8:
> - add ddr timing properties
>
> Changes in v7:
> - None
>
> Changes in v6:
> -Add more detail in Documentation
>
> Changes in v5:
> -None
>
> Changes in v4:
> -None
>
> Changes in v3:
> -None
>
> Changes in v2:
> -None
>
> Changes in v1:
> -None
> .../devicetree/bindings/devfreq/rk3399_dmc.txt | 202 +++++++++++++++++++++
> 1 file changed, 202 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt
>
> diff --git a/Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt b/Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt
> new file mode 100644
> index 0000000..84660a3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt
> @@ -0,0 +1,210 @@
> +* Rockchip rk3399 DMC(Dynamic Memory Controller) device
> +
> +Required properties:
> +- compatible: Must be "rockchip,rk3399-dmc".
> +- devfreq-events: Node to get DDR loading, Refer to
> + Documentation/devicetree/bindings/devfreq/
> + rockchip-dfi.txt
> +- interrupts: The interrupt number to the CPU. The interrupt
> + specifier format depends on the interrupt controller.
> + It should be DCF interrupts, when DDR dvfs finish,
> + it will happen.
> +- clocks: Phandles for clock specified in "clock-names" property
> +- clock-names : The name of clock used by the DFI, must be
> + "pclk_ddr_mon";
> +- operating-points-v2: Refer to Documentation/devicetree/bindings/power/opp.txt
> + for details.
> +- center-supply: DMC supply node.
> +- status: Marks the node enabled/disabled.
No need to document this.
> +
> +Following properties are ddr timing:
This is a lot of properties. I would prefer to see SPD data embedded
into DT if there are overlap in what SPD data defines for settings.
> +
> +- rockchip,dram_speed_bin : Value reference include/dt-bindings/clock/ddr.h,
Use '-', not '_' throughout.
> + it select ddr3 cl-trp-trcd type, default value
> + "DDR3_DEFAULT".it must selected according to
> + "Speed Bin" in ddr3 datasheet, DO NOT use
> + smaller "Speed Bin" than ddr3 exactly is.
> +
> +- rockchip,pd_idle : Config the PD_IDLE value, defined the power-down
> + idle period, memories are places into power-down
> + mode if bus is idle for PD_IDLE DFI clocks.
> +
> +- rockchip,sr_idle : Configure the SR_IDLE value, defined the
> + selfrefresh idle period, memories are places
> + into self-refresh mode if bus is idle for
> + SR_IDLE*1024 DFI clocks (DFI clocks freq is
> + half of dram's clocks), defaule value is "0".
> +
> +- rockchip,sr_mc_gate_idle : Defined the self-refresh with memory and
> + controller clock gating idle period, memories
> + are places into self-refresh mode and memory
> + controller clock arg gating if bus is idle for
> + sr_mc_gate_idle*1024 DFI clocks.
> +
> +- rockchip,srpd_lite_idle : Defined the self-refresh power down idle
> + period, memories are places into self-refresh
> + power down mode if bus is idle for
> + srpd_lite_idle*1024 DFI clocks. This parameter
> + is for LPDDR4 only.
> +
> +- rockchip,standby_idle : Defined the standby idle period, memories are
> + places into self-refresh than controller, pi,
> + phy and dram clock will gating if bus is idle
> + for standby_idle * DFI clocks.
> +
> +- rockchip,dram_dll_disb_freq : It's defined the DDR3 dll bypass frequency in
> + MHz, when ddr freq less than DRAM_DLL_DISB_FREQ,
> + ddr3 dll will bypssed note: if dll was bypassed,
> + the odt also stop working.
> +
> +- rockchip,phy_dll_disb_freq : Defined the PHY dll bypass frequency in
> + MHz (Mega Hz), when ddr freq less than
> + DRAM_DLL_DISB_FREQ, phy dll will bypssed.
> + note: phy dll and phy odt are independent.
> +
> +- rockchip,ddr3_odt_disb_freq : When dram type is DDR3, this parameter defined
Please group properties that are required and optional, and also group
by common, DDR3 only, DDR4L only, etc.
> + the odt disable frequency in MHz (Mega Hz),
> + when ddr frequency less then ddr3_odt_disb_freq,
> + the odt on dram side and controller side are
> + both disabled.
> +
> +- rockchip,ddr3_drv : When dram type is DDR3, this parameter define
> + the dram side driver stength in ohm, default
> + value is DDR3_DS_40ohm.
> +
> +- rockchip,ddr3_odt : When dram type is DDR3, this parameter define
> + the dram side ODT stength in ohm, default value
> + is DDR3_ODT_120ohm.
> +
> +- rockchip,phy_ddr3_ca_drv : When dram type is DDR3, this parameter define
> + the phy side CA line(incluing command line,
> + address line and clock line) driver strength.
> + Default value is PHY_DRV_ODT_40.
> +
> +- rockchip,phy_ddr3_dq_drv : When dram type is DDR3, this parameter define
> + the phy side DQ line(incluing DQS/DQ/DM line)
> + driver strength. default value is PHY_DRV_ODT_40.
You have the same properties, but they just vary by DDR type. Make the
property names common.
> +
> +- rockchip,phy_ddr3_odt : When dram type is DDR3, this parameter define the
> + phy side odt strength, default value is
> + PHY_DRV_ODT_240.
> +
> +- rockchip,lpddr3_odt_disb_freq : When dram type is LPDDR3, this parameter defined
> + then odt disable frequency in MHz (Mega Hz),
> + when ddr frequency less then ddr3_odt_disb_freq,
> + the odt on dram side and controller side are
> + both disabled.
> +
> +- rockchip,lpddr3_drv : When dram type is LPDDR3, this parameter define
> + the dram side driver stength in ohm, default
> + value is LP3_DS_34ohm.
> +
> +- rockchip,lpddr3_odt : When dram type is LPDDR3, this parameter define
> + the dram side ODT stength in ohm, default value
> + is LP3_ODT_240ohm.
Is this in ohms or a register value? Please make it in ohms and add a
-ohms suffix.
> +Example:
> + dmc_opp_table: dmc_opp_table {
> + compatible = "operating-points-v2";
> +
> + opp00 {
> + opp-hz = /bits/ 64 <300000000>;
> + opp-microvolt = <900000>;
> + };
> + opp01 {
> + opp-hz = /bits/ 64 <666000000>;
> + opp-microvolt = <900000>;
> + };
> + };
> +
> + dmc: dmc {
> + compatible = "rockchip,rk3399-dmc";
> + devfreq-events = <&dfi>;
> + interrupts = <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&cru SCLK_DDRCLK>;
> + clock-names = "dmc_clk";
> + operating-points-v2 = <&dmc_opp_table>;
> + center-supply = <&ppvar_centerlogic>;
> + upthreshold = <15>;
> + downdifferential = <10>;
> + rockchip,ddr3_speed_bin = <21>;
> + rockchip,pd_idle = <0x40>;
> + rockchip,sr_idle = <0x2>;
> + rockchip,sr_mc_gate_idle = <0x3>;
> + rockchip,srpd_lite_idle = <0x4>;
> + rockchip,standby_idle = <0x2000>;
> + rockchip,dram_dll_dis_freq = <300>;
> + rockchip,phy_dll_dis_freq = <125>;
> + rockchip,auto_pd_dis_freq = <666>;
> + rockchip,ddr3_odt_dis_freq = <333>;
> + rockchip,ddr3_drv = <DDR3_DS_40ohm>;
> + rockchip,ddr3_odt = <DDR3_ODT_120ohm>;
> + rockchip,phy_ddr3_ca_drv = <PHY_DRV_ODT_40>;
> + rockchip,phy_ddr3_dq_drv = <PHY_DRV_ODT_40>;
> + rockchip,phy_ddr3_odt = <PHY_DRV_ODT_240>;
> + rockchip,lpddr3_odt_dis_freq = <333>;
> + rockchip,lpddr3_drv = <LP3_DS_34ohm>;
> + rockchip,lpddr3_odt = <LP3_ODT_240ohm>;
> + rockchip,phy_lpddr3_ca_drv = <PHY_DRV_ODT_40>;
> + rockchip,phy_lpddr3_dq_drv = <PHY_DRV_ODT_40>;
> + rockchip,phy_lpddr3_odt = <PHY_DRV_ODT_240>;
> + rockchip,lpddr4_odt_dis_freq = <333>;
> + rockchip,lpddr4_drv = <LP4_PDDS_60ohm>;
> + rockchip,lpddr4_dq_odt = <LP4_DQ_ODT_40ohm>;
> + rockchip,lpddr4_ca_odt = <LP4_CA_ODT_40ohm>;
> + rockchip,phy_lpddr4_ca_drv = <PHY_DRV_ODT_40>;
> + rockchip,phy_lpddr4_ck_cs_drv = <PHY_DRV_ODT_80>;
> + rockchip,phy_lpddr4_dq_drv = <PHY_DRV_ODT_80>;
> + rockchip,phy_lpddr4_odt = <PHY_DRV_ODT_60>;
You have DDR3, LPDDR3 and LPDDR4 all populated at the same time? It
should be one set at a time.
Rob
^ permalink raw reply
* [PATCH v3] arm64: Improve kprobes test for atomic sequence
From: Masami Hiramatsu @ 2016-09-12 16:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57D60AA7.6010304@linaro.org>
On Sun, 11 Sep 2016 21:53:43 -0400
David Long <dave.long@linaro.org> wrote:
> On 09/10/2016 01:48 AM, Masami Hiramatsu wrote:
> > On Fri, 9 Sep 2016 15:26:09 -0400
> > David Long <dave.long@linaro.org> wrote:
> >
> >> From: "David A. Long" <dave.long@linaro.org>
> >>
> >> Kprobes searches backwards a finite number of instructions to determine if
> >> there is an attempt to probe a load/store exclusive sequence. It stops when
> >> it hits the maximum number of instructions or a load or store exclusive.
> >> However this means it can run up past the beginning of the function and
> >> start looking at literal constants. This has been shown to cause a false
> >> positive and blocks insertion of the probe. To fix this, further limit the
> >> backwards search to stop if it hits a symbol address from kallsyms. The
> >> presumption is that this is the entry point to this code (particularly for
> >> the common case of placing probes at the beginning of functions).
> >>
> >> This also improves efficiency by not searching code that is not part of the
> >> function. There may be some possibility that the label might not denote the
> >> entry path to the probed instruction but the likelihood seems low and this
> >> is just another example of how the kprobes user really needs to be
> >> careful about what they are doing.
> >
> > Of course user should be careful, but also, in such case, kernel can reject
> > to probe it.
> >
>
> I'm not exactly sure what you mean. I'm just saying when everything
> goes right we still cannot promise perfection in detecting a probe
> within an atomic sequence. This patch will reject a probe that is after
> a ldx and has no intervening kallsyms label (and assuming it's within
> the defined maximum count of subsequent instructions).
>
Hmm, what I meant was the below code.
> >> + /*
> >> + * If there's a symbol defined in front of and near enough to
> >> + * the probe address assume it is the entry point to this
> >> + * code and use it to further limit how far back we search
> >> + * when determining if we're in an atomic sequence. If we could
> >> + * not find any symbol skip the atomic test altogether as we
> >> + * could otherwise end up searching irrelevant text/literals.
> >> + * KPROBES depends on KALLSYMS so this last case should never
> >> + * happen.
> >> + */
> >> + if (kallsyms_lookup_size_offset((unsigned long) addr, &size, &offset)) {
> >> + if (offset < (MAX_ATOMIC_CONTEXT_SIZE*sizeof(kprobe_opcode_t)))
> >> + scan_end = addr - (offset / sizeof(kprobe_opcode_t));
> >> + else
> >> + scan_end = addr - MAX_ATOMIC_CONTEXT_SIZE;
> >
> > } else
> > return INSN_REJECTED;
> >
> > that is what I expected...
As you said above,
> >> + * KPROBES depends on KALLSYMS so this last case should never
> >> + * happen.
If it should never happen, it also would be better to reject it because
it is unexpected result.
Thank you,
--
Masami Hiramatsu <mhiramat@kernel.org>
^ 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