* [RFC] minimum gcc version for kernel: raise to gcc-4.3 or 4.6?
From: Suzuki K Poulose @ 2017-04-25 9:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGXu5jLPRYi+HK=07Zndc8szEKD4mZCqaHJFnHmmoYr7tA1xPw@mail.gmail.com>
On 16/04/17 20:52, Kees Cook wrote:
> Was there a conclusion to this discussion? I didn't see anything
> definitive in the thread...
>
> Notes below...
>
> On Fri, Dec 16, 2016 at 3:14 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>> [Fixed linux-arm-kernel mailing list address, sorry for the duplicate,
>> I'm not reposting all the ugly patches though, unless someone really
>> wants them, https://lkml.org/lkml/2016/12/16/174 has a copy]
>>
>> On Friday, December 16, 2016 11:56:21 AM CET Arnd Bergmann wrote:
>>> I had some fun doing build testing with older gcc versions, building
>>> every release from 4.0 through 7.0 and running that on my randconfig
>>> setup to see what comes out.
>>>
>>> First of all, gcc-4.9 and higher is basically warning-free everywhere,
>>> although gcc-7 introduces some interesting new warnings (I have started
>>> doing patches for those as well). gcc-4.8 is probably good, too, and
>>> gcc-4.6 and 4.7 at least don't produce build failures in general, though
>>> the level of false-positive warnings increases (we could decide to turn
>>> those off for older compilers for build test purposes).
>>>
>>> In gcc-4.5 and below, dead code elimination is not as good as later,
>>> causing a couple of link errors, and some of them have no good workaround
>>> (see patch 1). It would be nice to declare that version too old, but
>>> several older distros that are still in wide use ship with compilers
>>> earlier than 4.6:
>>>
>>> RHEL6: gcc-4.4
>
> This appears to have support until July 31, 2018. (Though it's using a
> 2.6 kernel.)
>
>>> Debian 6: gcc-4.4
>
> This went fully unsupported on Feb 29, 2016.
>
>>> Ubuntu 10.04: gcc-4.4
>
> This went fully unsupported on Apr 30, 2015.
>
>>> SLES11: gcc-4.3
>
> General support ends Mar 31 2019, fully unsupported 31 Mar 2022. (And
> like RHEL6 is using a 2.6 kernel.)
fyi, SLES11 upgraded to kernel 3.0, in SP2.
https://www.novell.com/support/kb/doc.php?id=3594951
Cheers
Suzuki
^ permalink raw reply
* [PATCH] usb: chipidea: udc: fix NULL pointer dereference if udc_start failed
From: Peter Chen @ 2017-04-25 9:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170425171134.6a983841@xhacker>
>> > diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
>> > index f88e9157fad0..60a786c87c06 100644
>> > --- a/drivers/usb/chipidea/udc.c
>> > +++ b/drivers/usb/chipidea/udc.c
>> > @@ -1984,6 +1984,7 @@ static void udc_id_switch_for_host(struct
>> > ci_hdrc *ci) int ci_hdrc_gadget_init(struct ci_hdrc *ci) {
>> > struct ci_role_driver *rdrv;
>> > + int ret;
>> >
>> > if (!hw_read(ci, CAP_DCCPARAMS, DCCPARAMS_DC))
>> > return -ENXIO;
>> > @@ -1996,7 +1997,10 @@ int ci_hdrc_gadget_init(struct ci_hdrc *ci)
>> > rdrv->stop = udc_id_switch_for_host;
>> > rdrv->irq = udc_irq;
>> > rdrv->name = "gadget";
>> > - ci->roles[CI_ROLE_GADGET] = rdrv;
>> >
>> > - return udc_start(ci);
>> > + ret = udc_start(ci);
>> > + if (!ret)
>> > + ci->roles[CI_ROLE_GADGET] = rdrv;
>> > +
>> > + return ret;
>> > }
>> > --
>>
>> Thanks for fixing it. In fact, we'd better return failure if ret &&
>> ret != -ENXIO at probe, it stands for initialization for host or
>> gadget has failed.
>>
>
>I got your meaning. I'll cook v2. I don't have preference, since either one can fix the
>issue.
>
Both are needed, you don't need to send this one again. Only a new one, thanks.
Peter
^ permalink raw reply
* [PATCH] usb: chipidea: udc: fix NULL pointer dereference if udc_start failed
From: Jisheng Zhang @ 2017-04-25 9:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170425082948.GB873@b29397-desktop>
Hi Peter,
On Tue, 25 Apr 2017 16:29:48 +0800 Peter Chen wrote:
> On Mon, Apr 24, 2017 at 12:35:51PM +0000, Jisheng Zhang wrote:
> > Fix below NULL pointer dereference. we set ci->roles[CI_ROLE_GADGET]
> > too early in ci_hdrc_gadget_init(), if udc_start() fails due to some
> > reason, the ci->roles[CI_ROLE_GADGET] check in ci_hdrc_gadget_destroy
> > can't protect us.
> >
> > We fix this issue by only setting ci->roles[CI_ROLE_GADGET] if
> > udc_start() succeed.
> >
> > [ 1.398550] Unable to handle kernel NULL pointer dereference at
> > virtual address 00000000
> > ...
> > [ 1.448600] PC is at dma_pool_free+0xb8/0xf0
> > [ 1.453012] LR is at dma_pool_free+0x28/0xf0
> > [ 2.113369] [<ffffff80081817d8>] dma_pool_free+0xb8/0xf0
> > [ 2.118857] [<ffffff800841209c>] destroy_eps+0x4c/0x68
> > [ 2.124165] [<ffffff8008413770>] ci_hdrc_gadget_destroy+0x28/0x50
> > [ 2.130461] [<ffffff800840fa30>] ci_hdrc_probe+0x588/0x7e8
> > [ 2.136129] [<ffffff8008380fb8>] platform_drv_probe+0x50/0xb8
> > [ 2.142066] [<ffffff800837f494>] driver_probe_device+0x1fc/0x2a8
> > [ 2.148270] [<ffffff800837f68c>] __device_attach_driver+0x9c/0xf8
> > [ 2.154563] [<ffffff800837d570>] bus_for_each_drv+0x58/0x98
> > [ 2.160317] [<ffffff800837f174>] __device_attach+0xc4/0x138
> > [ 2.166072] [<ffffff800837f738>] device_initial_probe+0x10/0x18
> > [ 2.172185] [<ffffff800837e58c>] bus_probe_device+0x94/0xa0
> > [ 2.177940] [<ffffff800837c560>] device_add+0x3f0/0x560
> > [ 2.183337] [<ffffff8008380d20>] platform_device_add+0x180/0x240
> > [ 2.189541] [<ffffff800840f0e8>] ci_hdrc_add_device+0x440/0x4f8
> > [ 2.195654] [<ffffff8008414194>] ci_hdrc_usb2_probe+0x13c/0x2d8
> > [ 2.201769] [<ffffff8008380fb8>] platform_drv_probe+0x50/0xb8
> > [ 2.207705] [<ffffff800837f494>] driver_probe_device+0x1fc/0x2a8
> > [ 2.213910] [<ffffff800837f5ec>] __driver_attach+0xac/0xb0
> > [ 2.219575] [<ffffff800837d4b0>] bus_for_each_dev+0x60/0xa0
> > [ 2.225329] [<ffffff800837ec80>] driver_attach+0x20/0x28
> > [ 2.230816] [<ffffff800837e880>] bus_add_driver+0x1d0/0x238
> > [ 2.236571] [<ffffff800837fdb0>] driver_register+0x60/0xf8
> > [ 2.242237] [<ffffff8008380ef4>] __platform_driver_register+0x44/0x50
> > [ 2.248891] [<ffffff80086fd440>] ci_hdrc_usb2_driver_init+0x18/0x20
> > [ 2.255365] [<ffffff8008082950>] do_one_initcall+0x38/0x128
> > [ 2.261121] [<ffffff80086e0d00>] kernel_init_freeable+0x1ac/0x250
> > [ 2.267414] [<ffffff800852f0b8>] kernel_init+0x10/0x100
> > [ 2.272810] [<ffffff8008082680>] ret_from_fork+0x10/0x50
> >
> > Signed-off-by: Jisheng Zhang <jszhang@marvell.com>
> > ---
> > drivers/usb/chipidea/udc.c | 8 ++++++--
> > 1 file changed, 6 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
> > index f88e9157fad0..60a786c87c06 100644
> > --- a/drivers/usb/chipidea/udc.c
> > +++ b/drivers/usb/chipidea/udc.c
> > @@ -1984,6 +1984,7 @@ static void udc_id_switch_for_host(struct ci_hdrc *ci)
> > int ci_hdrc_gadget_init(struct ci_hdrc *ci)
> > {
> > struct ci_role_driver *rdrv;
> > + int ret;
> >
> > if (!hw_read(ci, CAP_DCCPARAMS, DCCPARAMS_DC))
> > return -ENXIO;
> > @@ -1996,7 +1997,10 @@ int ci_hdrc_gadget_init(struct ci_hdrc *ci)
> > rdrv->stop = udc_id_switch_for_host;
> > rdrv->irq = udc_irq;
> > rdrv->name = "gadget";
> > - ci->roles[CI_ROLE_GADGET] = rdrv;
> >
> > - return udc_start(ci);
> > + ret = udc_start(ci);
> > + if (!ret)
> > + ci->roles[CI_ROLE_GADGET] = rdrv;
> > +
> > + return ret;
> > }
> > --
>
> Thanks for fixing it. In fact, we'd better return failure if
> ret && ret != -ENXIO at probe, it stands for initialization
> for host or gadget has failed.
>
I got your meaning. I'll cook v2. I don't have preference, since either
one can fix the issue.
Thanks for your suggestion,
Jisheng
^ permalink raw reply
* [PATCH V9 1/3] irq: Allow to pass the IRQF_TIMER flag with percpu irq request
From: Marc Zyngier @ 2017-04-25 9:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170425083451.GA16888@mai>
On 25/04/17 09:34, Daniel Lezcano wrote:
> On Tue, Apr 25, 2017 at 08:38:56AM +0100, Marc Zyngier wrote:
>> On 24/04/17 20:59, Daniel Lezcano wrote:
>>> On Mon, Apr 24, 2017 at 08:14:54PM +0100, Marc Zyngier wrote:
>>>> On 24/04/17 19:59, Daniel Lezcano wrote:
>>>>> On Mon, Apr 24, 2017 at 07:46:43PM +0100, Marc Zyngier wrote:
>>>>>> On 24/04/17 15:01, Daniel Lezcano wrote:
>>>>>>> In the next changes, we track when the interrupts occur in order to
>>>>>>> statistically compute when is supposed to happen the next interrupt.
>>>>>>>
>>>>>>> In all the interruptions, it does not make sense to store the timer interrupt
>>>>>>> occurences and try to predict the next interrupt as when know the expiration
>>>>>>> time.
>>>>>>>
>>>>>>> The request_irq() has a irq flags parameter and the timer drivers use it to
>>>>>>> pass the IRQF_TIMER flag, letting us know the interrupt is coming from a timer.
>>>>>>> Based on this flag, we can discard these interrupts when tracking them.
>>>>>>>
>>>>>>> But, the API request_percpu_irq does not allow to pass a flag, hence specifying
>>>>>>> if the interrupt type is a timer.
>>>>>>>
>>>>>>> Add a function request_percpu_irq_flags() where we can specify the flags. The
>>>>>>> request_percpu_irq() function is changed to be a wrapper to
>>>>>>> request_percpu_irq_flags() passing a zero flag parameter.
>>>>>>>
>>>>>>> Change the timers using request_percpu_irq() to use request_percpu_irq_flags()
>>>>>>> instead with the IRQF_TIMER flag set.
>>>>>>>
>>>>>>> For now, in order to prevent a misusage of this parameter, only the IRQF_TIMER
>>>>>>> flag (or zero) is a valid parameter to be passed to the
>>>>>>> request_percpu_irq_flags() function.
>>>>>>
>>>>>> [...]
>>>>>>
>>>>>>> diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
>>>>>>> index 35d7100..602e0a8 100644
>>>>>>> --- a/virt/kvm/arm/arch_timer.c
>>>>>>> +++ b/virt/kvm/arm/arch_timer.c
>>>>>>> @@ -523,8 +523,9 @@ int kvm_timer_hyp_init(void)
>>>>>>> host_vtimer_irq_flags = IRQF_TRIGGER_LOW;
>>>>>>> }
>>>>>>>
>>>>>>> - err = request_percpu_irq(host_vtimer_irq, kvm_arch_timer_handler,
>>>>>>> - "kvm guest timer", kvm_get_running_vcpus());
>>>>>>> + err = request_percpu_irq_flags(host_vtimer_irq, kvm_arch_timer_handler,
>>>>>>> + IRQF_TIMER, "kvm guest timer",
>>>>>>> + kvm_get_running_vcpus());
>>>>>>> if (err) {
>>>>>>> kvm_err("kvm_arch_timer: can't request interrupt %d (%d)\n",
>>>>>>> host_vtimer_irq, err);
>>>>>>>
>>>>>>
>>>>>> How is that useful? This timer is controlled by the guest OS, and not
>>>>>> the host kernel. Can you explain how you intend to make use of that
>>>>>> information in this case?
>>>>>
>>>>> Isn't it a source of interruption on the host kernel?
>>>>
>>>> Only to cause an exit of the VM, and not under the control of the host.
>>>> This isn't triggering any timer related action on the host code either.
>>>>
>>>> Your patch series seems to assume some kind of predictability of the
>>>> timer interrupt, which can make sense on the host. Here, this interrupt
>>>> is shared among *all* guests running on this system.
>>>>
>>>> Maybe you could explain why you think this interrupt is relevant to what
>>>> you're trying to achieve?
>>>
>>> If this interrupt does not happen on the host, we don't care.
>>
>> All interrupts happen on the host. There is no such thing as a HW
>> interrupt being directly delivered to a guest (at least so far). The
>> timer is under control of the guest, which uses as it sees fit. When
>> the HW timer expires, the interrupt fires on the host, which re-inject
>> the interrupt in the guest.
>
> Ah, thanks for the clarification. Interesting.
>
> How can the host know which guest to re-inject the interrupt?
The timer can only fire when the vcpu is running. If it is not running,
a software timer is queued, with a pointer to the vcpu struct.
>>> The flag IRQF_TIMER is used by the spurious irq handler in the try_one_irq()
>>> function. However the per cpu timer interrupt will be discarded in the function
>>> before because it is per cpu.
>>
>> Right. That's not because this is a timer, but because it is per-cpu.
>> So why do we need this IRQF_TIMER flag, instead of fixing try_one_irq()?
>
> When a timer is not per cpu, (eg. request_irq), we need this flag, no?
Sure, but in this series, they all seem to be per-cpu.
>>> IMO, for consistency reason, adding the IRQF_TIMER makes sense. Other than
>>> that, as the interrupt is not happening on the host, this flag won't be used.
>>>
>>> Do you want to drop this change?
>>
>> No, I'd like to understand the above. Why isn't the following patch
>> doing the right thing?
>
> Actually, the explanation is in the next patch of the series (2/3)
>
> [ ... ]
>
> +static inline void setup_timings(struct irq_desc *desc, struct irqaction *act)
> +{
> + /*
> + * We don't need the measurement because the idle code already
> + * knows the next expiry event.
> + */
> + if (act->flags & __IRQF_TIMER)
> + return;
And that's where this is really wrong for the KVM guest timer. As I
said, this timer is under complete control of the guest, and the rest of
the system doesn't know about it. KVM itself will only find out when the
vcpu does a VM exit for a reason or another, and will just save/restore
the state in order to be able to give the timer to another guest.
The idle code is very much *not* aware of anything concerning that guest
timer.
> +
> + desc->istate |= IRQS_TIMINGS;
> +}
>
> [ ... ]
>
> +/*
> + * The function record_irq_time is only called in one place in the
> + * interrupts handler. We want this function always inline so the code
> + * inside is embedded in the function and the static key branching
> + * code can act at the higher level. Without the explicit
> + * __always_inline we can end up with a function call and a small
> + * overhead in the hotpath for nothing.
> + */
> +static __always_inline void record_irq_time(struct irq_desc *desc)
> +{
> + if (!static_branch_likely(&irq_timing_enabled))
> + return;
> +
> + if (desc->istate & IRQS_TIMINGS) {
> + struct irq_timings *timings = this_cpu_ptr(&irq_timings);
> +
> + timings->values[timings->count & IRQ_TIMINGS_MASK] =
> + irq_timing_encode(local_clock(),
> + irq_desc_get_irq(desc));
> +
> + timings->count++;
> + }
> +}
>
> [ ... ]
>
> The purpose is to predict the next event interrupts on the system which are
> source of wake up. For now, this patchset is focused on interrupts (discarding
> timer interrupts).
>
> The following article gives more details: https://lwn.net/Articles/673641/
>
> When the interrupt is setup, we tag it except if it is a timer. So with this
> patch there is another usage of the IRQF_TIMER where we will be ignoring
> interrupt coming from a timer.
>
> As the timer interrupt is delivered to the host, we should not measure it as it
> is a timer and set this flag.
>
> The needed information is: "what is the earliest VM timer?". If this
> information is already available then there is nothing more to do, otherwise we
> should add it in the future.
This information is not readily available. You can only find it when it
is too late (timer has already fired) or when it is not relevant anymore
(guest is sleeping and we've queued a SW timer for it).
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH 1/1] ARM: compressed/head.S: fix __nop macro rept number for ARMv7M
From: patrice.chotard at st.com @ 2017-04-25 9:01 UTC (permalink / raw)
To: linux-arm-kernel
From: Patrice Chotard <patrice.chotard@st.com>
In zImage, _magic_sig is located at offset 0x24.
But for ARMv7M architecture which enable CPU_THUMBONLY
and !EFI_STUB kernel flag, _magic_sig is located at offset 0x14
00000000 00 46 00 46 00 46 00 46 00 46 00 46 00 46 0f f2 |.F.F.F.F.F.F.F.?|
00000010 15 0c 60 47 18 28 6f 01 00 00 00 00 28 5c 0e 00 |..`G.(o.....(\..|
00000020 01 02 03 04 0f 46 90 46 00 00 00 00 00 00 00 00 |.....F.F........|
Reproduced with stm32_defconfig with XIP_KERNEL flag disabled.
To restore correct _magic_sig offset at 0x24, we add 8 additional
"mov r0, r0" instruction.
Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
---
arch/arm/boot/compressed/head.S | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
index 9150f97..5d9cda3 100644
--- a/arch/arm/boot/compressed/head.S
+++ b/arch/arm/boot/compressed/head.S
@@ -127,7 +127,8 @@
AR_CLASS( .arm )
start:
.type start,#function
- .rept 7
+ ARM( .rept 7)
+ THUMB( .rept 15)
__nop
.endr
ARM( mov r0, r0 )
--
1.9.1
^ permalink raw reply related
* [PATCH 0/3] Add eSDHC UHS-I/HS200 mode support for ls1012a/ls1046a/ls208xa
From: Y.B. Lu @ 2017-04-25 9:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPDyKFp_TWSj7FH6KagU4gz+A9CR-thwU9b1WaSEgupZMBAyaQ@mail.gmail.com>
> -----Original Message-----
> From: Ulf Hansson [mailto:ulf.hansson at linaro.org]
> Sent: Tuesday, April 25, 2017 4:17 AM
> To: Y.B. Lu
> Cc: linux-arm-kernel at lists.infradead.org; Shawn Guo; Catalin Marinas;
> Xiaobo Xie
> Subject: Re: [PATCH 0/3] Add eSDHC UHS-I/HS200 mode support for
> ls1012a/ls1046a/ls208xa
>
> On 21 April 2017 at 05:52, Yangbo Lu <yangbo.lu@nxp.com> wrote:
> > This patch is to add eSDHC UHS-I/HS200 mode support for
> ls1012a/ls1046a/ls208xa.
> > Because eSDHC is not a standard SD controller, the specific speed mode
> > support depends on board's peripheral circuit for eSDHC. So, we have
> > to add these speed modes support on board dts file.
> >
> > In additon, these dts patches depends on esdhc driver patches which
> > just had been merged on mmc.git. Otherwise, the UHS-I SD card and eMMC
> > HS200 card would fail to be initialized, but other cards still could
> work fine.
> > https://patchwork.kernel.org/patch/9689875/
> > https://patchwork.kernel.org/patch/9689877/
> > https://patchwork.kernel.org/patch/9689879/
> > https://patchwork.kernel.org/patch/9689887/
> > https://patchwork.kernel.org/patch/9689885/
> >
> > Yangbo Lu (3):
> > arm64: dts: ls1046a: support SD UHS-I and eMMC HS200 on RDB
> > arm64: dts: ls208xa: support SD UHS-I on RDB and eMMC HS200 on QDS
> > arm64: dts: ls1012a: add eSDHC nodes
> >
> > arch/arm64/boot/dts/freescale/fsl-ls1012a-qds.dts | 8 +++++++
> > arch/arm64/boot/dts/freescale/fsl-ls1012a-rdb.dts | 13 +++++++++++
> > arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi | 25
> ++++++++++++++++++++++
> > arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts | 8 +++++++
> > arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 4 ++--
> > arch/arm64/boot/dts/freescale/fsl-ls208xa-qds.dtsi | 1 +
> > arch/arm64/boot/dts/freescale/fsl-ls208xa-rdb.dtsi | 4 ++++
> > arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 2 +-
> > 8 files changed, 62 insertions(+), 3 deletions(-)
> >
> > --
> > 2.1.0.27.g96db324
> >
>
> By curiosity I tried applying these to my mmc tree, but they don't apply.
> So I can pick them, even with acks.
> Also it's too difficult for me to host an immutable branch with the
> relevant sdhci-esdc changes, because of additional sdhci dependencies.
>
> Perhaps just easier to pick this for 4.13 or 4.12 rc2.
[Lu Yangbo-B47093] Hi Uffe, I agree.
These patches are based on Shawn's tree which has the latest layerscape board dts.
Actually I'm not sure which git tree I should send these patches to according to MAINTAINERS, but I saw Shawn had merged some layerscape board dts before.
Hi Shawn,
Am I right to send these patches to you for reviewing? Which git tree do you recommend I should send these patches to?
Thanks.
>
> Kind regards
> Uffe
^ permalink raw reply
* [PATCH 2/2] reset: Add a Gemini reset controller
From: Philipp Zabel @ 2017-04-25 8:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170424192802.27430-1-linus.walleij@linaro.org>
Hi Linus,
thank you for the patch. A few comments and questions below:
On Mon, 2017-04-24 at 21:28 +0200, Linus Walleij wrote:
> The Cortina Systems Gemini reset controller is a simple
> 32bit register with self-deasserting reset lines. It is
> accessed using regmap over syscon.
>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> drivers/reset/Kconfig | 7 +++
> drivers/reset/Makefile | 1 +
> drivers/reset/reset-gemini.c | 112 +++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 120 insertions(+)
> create mode 100644 drivers/reset/reset-gemini.c
>
> diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
> index f4cdfe94b9ec..a82e1a78de25 100644
> --- a/drivers/reset/Kconfig
> +++ b/drivers/reset/Kconfig
> @@ -27,6 +27,13 @@ config RESET_BERLIN
> help
> This enables the reset controller driver for Marvell Berlin SoCs.
>
> +config RESET_GEMINI
> + bool "Gemini Reset Driver" if COMPILE_TEST
> + default ARCH_GEMINI
> + select MFD_SYSCON
> + help
> + This enables the reset controller driver for Cortina Systems Gemini.
> +
> config RESET_LPC18XX
> bool "LPC18xx/43xx Reset Driver" if COMPILE_TEST
> default ARCH_LPC18XX
> diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
> index 2cd3f6c45165..99e90ad18545 100644
> --- a/drivers/reset/Makefile
> +++ b/drivers/reset/Makefile
> @@ -4,6 +4,7 @@ obj-$(CONFIG_ARCH_STI) += sti/
> obj-$(CONFIG_ARCH_TEGRA) += tegra/
> obj-$(CONFIG_RESET_ATH79) += reset-ath79.o
> obj-$(CONFIG_RESET_BERLIN) += reset-berlin.o
> +obj-$(CONFIG_RESET_GEMINI) += reset-gemini.o
> obj-$(CONFIG_RESET_LPC18XX) += reset-lpc18xx.o
> obj-$(CONFIG_RESET_MESON) += reset-meson.o
> obj-$(CONFIG_RESET_OXNAS) += reset-oxnas.o
> diff --git a/drivers/reset/reset-gemini.c b/drivers/reset/reset-gemini.c
> new file mode 100644
> index 000000000000..481facbb2709
> --- /dev/null
> +++ b/drivers/reset/reset-gemini.c
> @@ -0,0 +1,112 @@
> +/*
> + * Cortina Gemini Reset controller driver
> + * Copyright (c) 2017 Linus Walleij <linus.walleij@linaro.org>
No license statement, choice or oversight?
> + */
> +
> +#include <linux/err.h>
> +#include <linux/init.h>
> +#include <linux/mfd/syscon.h>
> +#include <linux/regmap.h>
> +#include <linux/of.h>
> +#include <linux/platform_device.h>
> +#include <linux/reset-controller.h>
> +
> +/**
> + * struct gemini_reset - gemini reset controller
> + * @map: regmap to access the containing system controller
> + * @dev: pointer back to device
> + * @rcdev: reset controller device
> + */
> +struct gemini_reset {
> + struct regmap *map;
> + struct device *dev;
dev is unused, can be dropped.
> + struct reset_controller_dev rcdev;
> +};
> +
> +#define GEMINI_GLOBAL_SOFT_RESET 0x0c
> +
> +#define to_gemini_reset(p) \
> + container_of((p), struct gemini_reset, rcdev)
> +
> +/*
> + * This is a self-deasserting reset controller.
> + */
> +static int gemini_reset(struct reset_controller_dev *rcdev,
> + unsigned long id)
> +{
> + struct gemini_reset *gr = to_gemini_reset(rcdev);
> +
> + /* Manual says to always set BIT 30 to 1 */
> + return regmap_write(gr->map,
> + GEMINI_GLOBAL_SOFT_RESET,
> + BIT(30) | BIT(id));
BIT(30) is called CPU1 reset in the DT binding, maybe add a #define?
> +}
> +
> +static int gemini_reset_status(struct reset_controller_dev *rcdev,
> + unsigned long id)
> +{
> + struct gemini_reset *gr = to_gemini_reset(rcdev);
> + u32 val;
> + int ret;
> +
> + ret = regmap_read(gr->map, GEMINI_GLOBAL_SOFT_RESET, &val);
> + if (ret)
> + return ret;
> +
> + return !!(val & BIT(id));
> +}
> +
> +static const struct reset_control_ops gemini_reset_ops = {
> + .reset = gemini_reset,
> + .status = gemini_reset_status,
> +};
> +
> +static int gemini_reset_probe(struct platform_device *pdev)
> +{
> + struct gemini_reset *gr;
> + struct device *dev = &pdev->dev;
> + struct device_node *np = dev->of_node;
> + struct device_node *parent_np = np->parent;
> + int ret;
> +
> + if (!parent_np) {
Is this even possible?
> + dev_err(dev, "missing parent node\n");
> + return -ENODEV;
> + }
>+
> + gr = devm_kzalloc(dev, sizeof(*gr), GFP_KERNEL);
> + if (!gr)
> + return -ENOMEM;
> +
> + gr->dev = dev;
Can be dropped.
> + gr->map = syscon_node_to_regmap(parent_np);
> + if (IS_ERR(gr->map)) {
> + dev_err(dev, "unable to get regmap");
It might be helpful to print the error code here.
> + return PTR_ERR(gr->map);
> + }
> + gr->rcdev.owner = THIS_MODULE;
> + gr->rcdev.nr_resets = 32;
> + gr->rcdev.ops = &gemini_reset_ops;
> + gr->rcdev.of_node = pdev->dev.of_node;
> +
> + ret = devm_reset_controller_register(&pdev->dev, &gr->rcdev);
> + if (ret)
> + return ret;
> +
> + dev_info(dev, "registered Gemini reset controller\n");
This is a bit verbose. I'd remove it and shorten the last part to:
return devm_reset_controller_register(&pdev->dev, &gr->rcdev);
> + return 0;
> +}
> +
> +static const struct of_device_id gemini_reset_dt_ids[] = {
> + { .compatible = "cortina,gemini-reset", },
> + { /* sentinel */ },
> +};
> +
> +static struct platform_driver gemini_reset_driver = {
> + .probe = gemini_reset_probe,
> + .driver = {
> + .name = "gemini-reset",
> + .of_match_table = gemini_reset_dt_ids,
> + },
> +};
> +builtin_platform_driver(gemini_reset_driver);
regards
Philipp
^ permalink raw reply
* [linux-sunxi] Re: [PATCH v4 07/10] mfd: axp20x: add axp20x-regulator cell for AXP803
From: Icenowy Zheng @ 2017-04-25 8:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170425075717.l4x3qektdgt6kaiq@dell>
? 2017?4?25? GMT+08:00 ??3:57:17, Lee Jones <lee.jones@linaro.org> ??:
>On Tue, 25 Apr 2017, Icenowy Zheng wrote:
>
>> As axp20x-regulator now supports AXP803, add a cell for it.
>>
>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
>> Acked-by: Chen-Yu Tsai <wens@csie.org>
>> ---
>> Changes in v4:
>> - Added a trailing comma for new cell, for easier further cell
>addition.
>> Changes in v3:
>> - Make the new cell one-liner.
>>
>> drivers/mfd/axp20x.c | 3 ++-
>> drivers/regulator/axp20x-regulator.c | 6 +++---
>
>These 2 changes are orthogonal, thus there is no reason to send them
>bundled into a single patch. Doing so complicates things greatly.
>Please resubmit the two changes separately, so that they may be
>absorbed by our respective subsystems.
Yes. As Chen-Yu said, I wrongly squashed the regulator renaming patch here...
It should be squashed into the regulator patch.
Sorry for it.
>
>> 2 files changed, 5 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
>> index 1dc6235778eb..917b6ddc4f15 100644
>> --- a/drivers/mfd/axp20x.c
>> +++ b/drivers/mfd/axp20x.c
>> @@ -848,7 +848,8 @@ static struct mfd_cell axp803_cells[] = {
>> .name = "axp20x-pek",
>> .num_resources = ARRAY_SIZE(axp803_pek_resources),
>> .resources = axp803_pek_resources,
>> - }
>> + },
>> + { .name = "axp20x-regulator" },
>> };
>>
>> static struct mfd_cell axp806_cells[] = {
>> diff --git a/drivers/regulator/axp20x-regulator.c
>b/drivers/regulator/axp20x-regulator.c
>> index 9356ec8a9a1f..e2608fe770b9 100644
>> --- a/drivers/regulator/axp20x-regulator.c
>> +++ b/drivers/regulator/axp20x-regulator.c
>> @@ -311,13 +311,13 @@ static const struct regulator_desc
>axp803_regulators[] = {
>> AXP803_FLDO1_V_OUT, 0x0f, AXP22X_PWR_OUT_CTRL3, BIT(2)),
>> AXP_DESC(AXP803, FLDO2, "fldo2", "fldoin", 700, 1450, 50,
>> AXP803_FLDO2_V_OUT, 0x0f, AXP22X_PWR_OUT_CTRL3, BIT(3)),
>> - AXP_DESC_IO(AXP803, LDO_IO0, "ldo_io0", "ips", 700, 3300, 100,
>> + AXP_DESC_IO(AXP803, LDO_IO0, "ldo-io0", "ips", 700, 3300, 100,
>> AXP22X_LDO_IO0_V_OUT, 0x1f, AXP20X_GPIO0_CTRL, 0x07,
>> AXP22X_IO_ENABLED, AXP22X_IO_DISABLED),
>> - AXP_DESC_IO(AXP803, LDO_IO1, "ldo_io1", "ips", 700, 3300, 100,
>> + AXP_DESC_IO(AXP803, LDO_IO1, "ldo-io1", "ips", 700, 3300, 100,
>> AXP22X_LDO_IO1_V_OUT, 0x1f, AXP20X_GPIO1_CTRL, 0x07,
>> AXP22X_IO_ENABLED, AXP22X_IO_DISABLED),
>> - AXP_DESC_FIXED(AXP803, RTC_LDO, "rtc_ldo", "ips", 3000),
>> + AXP_DESC_FIXED(AXP803, RTC_LDO, "rtc-ldo", "ips", 3000),
>> };
>>
>> static const struct regulator_linear_range axp806_dcdca_ranges[] = {
^ permalink raw reply
* [PATCH V9 1/3] irq: Allow to pass the IRQF_TIMER flag with percpu irq request
From: Daniel Lezcano @ 2017-04-25 8:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <16042494-2e67-e1a5-b9f6-af57e349d8a7@arm.com>
On Tue, Apr 25, 2017 at 08:38:56AM +0100, Marc Zyngier wrote:
> On 24/04/17 20:59, Daniel Lezcano wrote:
> > On Mon, Apr 24, 2017 at 08:14:54PM +0100, Marc Zyngier wrote:
> >> On 24/04/17 19:59, Daniel Lezcano wrote:
> >>> On Mon, Apr 24, 2017 at 07:46:43PM +0100, Marc Zyngier wrote:
> >>>> On 24/04/17 15:01, Daniel Lezcano wrote:
> >>>>> In the next changes, we track when the interrupts occur in order to
> >>>>> statistically compute when is supposed to happen the next interrupt.
> >>>>>
> >>>>> In all the interruptions, it does not make sense to store the timer interrupt
> >>>>> occurences and try to predict the next interrupt as when know the expiration
> >>>>> time.
> >>>>>
> >>>>> The request_irq() has a irq flags parameter and the timer drivers use it to
> >>>>> pass the IRQF_TIMER flag, letting us know the interrupt is coming from a timer.
> >>>>> Based on this flag, we can discard these interrupts when tracking them.
> >>>>>
> >>>>> But, the API request_percpu_irq does not allow to pass a flag, hence specifying
> >>>>> if the interrupt type is a timer.
> >>>>>
> >>>>> Add a function request_percpu_irq_flags() where we can specify the flags. The
> >>>>> request_percpu_irq() function is changed to be a wrapper to
> >>>>> request_percpu_irq_flags() passing a zero flag parameter.
> >>>>>
> >>>>> Change the timers using request_percpu_irq() to use request_percpu_irq_flags()
> >>>>> instead with the IRQF_TIMER flag set.
> >>>>>
> >>>>> For now, in order to prevent a misusage of this parameter, only the IRQF_TIMER
> >>>>> flag (or zero) is a valid parameter to be passed to the
> >>>>> request_percpu_irq_flags() function.
> >>>>
> >>>> [...]
> >>>>
> >>>>> diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
> >>>>> index 35d7100..602e0a8 100644
> >>>>> --- a/virt/kvm/arm/arch_timer.c
> >>>>> +++ b/virt/kvm/arm/arch_timer.c
> >>>>> @@ -523,8 +523,9 @@ int kvm_timer_hyp_init(void)
> >>>>> host_vtimer_irq_flags = IRQF_TRIGGER_LOW;
> >>>>> }
> >>>>>
> >>>>> - err = request_percpu_irq(host_vtimer_irq, kvm_arch_timer_handler,
> >>>>> - "kvm guest timer", kvm_get_running_vcpus());
> >>>>> + err = request_percpu_irq_flags(host_vtimer_irq, kvm_arch_timer_handler,
> >>>>> + IRQF_TIMER, "kvm guest timer",
> >>>>> + kvm_get_running_vcpus());
> >>>>> if (err) {
> >>>>> kvm_err("kvm_arch_timer: can't request interrupt %d (%d)\n",
> >>>>> host_vtimer_irq, err);
> >>>>>
> >>>>
> >>>> How is that useful? This timer is controlled by the guest OS, and not
> >>>> the host kernel. Can you explain how you intend to make use of that
> >>>> information in this case?
> >>>
> >>> Isn't it a source of interruption on the host kernel?
> >>
> >> Only to cause an exit of the VM, and not under the control of the host.
> >> This isn't triggering any timer related action on the host code either.
> >>
> >> Your patch series seems to assume some kind of predictability of the
> >> timer interrupt, which can make sense on the host. Here, this interrupt
> >> is shared among *all* guests running on this system.
> >>
> >> Maybe you could explain why you think this interrupt is relevant to what
> >> you're trying to achieve?
> >
> > If this interrupt does not happen on the host, we don't care.
>
> All interrupts happen on the host. There is no such thing as a HW
> interrupt being directly delivered to a guest (at least so far). The
> timer is under control of the guest, which uses as it sees fit. When
> the HW timer expires, the interrupt fires on the host, which re-inject
> the interrupt in the guest.
Ah, thanks for the clarification. Interesting.
How can the host know which guest to re-inject the interrupt?
> > The flag IRQF_TIMER is used by the spurious irq handler in the try_one_irq()
> > function. However the per cpu timer interrupt will be discarded in the function
> > before because it is per cpu.
>
> Right. That's not because this is a timer, but because it is per-cpu.
> So why do we need this IRQF_TIMER flag, instead of fixing try_one_irq()?
When a timer is not per cpu, (eg. request_irq), we need this flag, no?
> > IMO, for consistency reason, adding the IRQF_TIMER makes sense. Other than
> > that, as the interrupt is not happening on the host, this flag won't be used.
> >
> > Do you want to drop this change?
>
> No, I'd like to understand the above. Why isn't the following patch
> doing the right thing?
Actually, the explanation is in the next patch of the series (2/3)
[ ... ]
+static inline void setup_timings(struct irq_desc *desc, struct irqaction *act)
+{
+ /*
+ * We don't need the measurement because the idle code already
+ * knows the next expiry event.
+ */
+ if (act->flags & __IRQF_TIMER)
+ return;
+
+ desc->istate |= IRQS_TIMINGS;
+}
[ ... ]
+/*
+ * The function record_irq_time is only called in one place in the
+ * interrupts handler. We want this function always inline so the code
+ * inside is embedded in the function and the static key branching
+ * code can act at the higher level. Without the explicit
+ * __always_inline we can end up with a function call and a small
+ * overhead in the hotpath for nothing.
+ */
+static __always_inline void record_irq_time(struct irq_desc *desc)
+{
+ if (!static_branch_likely(&irq_timing_enabled))
+ return;
+
+ if (desc->istate & IRQS_TIMINGS) {
+ struct irq_timings *timings = this_cpu_ptr(&irq_timings);
+
+ timings->values[timings->count & IRQ_TIMINGS_MASK] =
+ irq_timing_encode(local_clock(),
+ irq_desc_get_irq(desc));
+
+ timings->count++;
+ }
+}
[ ...?]
The purpose is to predict the next event interrupts on the system which are
source of wake up. For now, this patchset is focused on interrupts (discarding
timer interrupts).
The following article gives more details: https://lwn.net/Articles/673641/
When the interrupt is setup, we tag it except if it is a timer. So with this
patch there is another usage of the IRQF_TIMER where we will be ignoring
interrupt coming from a timer.
As the timer interrupt is delivered to the host, we should not measure it as it
is a timer and set this flag.
The needed information is: "what is the earliest VM timer?". If this
information is already available then there is nothing more to do, otherwise we
should add it in the future.
> diff --git a/kernel/irq/spurious.c b/kernel/irq/spurious.c
> index 061ba7eed4ed..a4a81c6c7602 100644
> --- a/kernel/irq/spurious.c
> +++ b/kernel/irq/spurious.c
> @@ -72,6 +72,7 @@ static int try_one_irq(struct irq_desc *desc, bool force)
> * marked polled are excluded from polling.
> */
> if (irq_settings_is_per_cpu(desc) ||
> + irq_settings_is_per_cpu_devid(desc) ||
> irq_settings_is_nested_thread(desc) ||
> irq_settings_is_polled(desc))
> goto out;
>
> Thanks,
>
> M.
> --
> Jazz is not dead. It just smells funny...
--
<http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
^ permalink raw reply
* [PATCH] usb: chipidea: udc: fix NULL pointer dereference if udc_start failed
From: Peter Chen @ 2017-04-25 8:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170424123551.2465-1-jszhang@marvell.com>
On Mon, Apr 24, 2017 at 12:35:51PM +0000, Jisheng Zhang wrote:
> Fix below NULL pointer dereference. we set ci->roles[CI_ROLE_GADGET]
> too early in ci_hdrc_gadget_init(), if udc_start() fails due to some
> reason, the ci->roles[CI_ROLE_GADGET] check in ci_hdrc_gadget_destroy
> can't protect us.
>
> We fix this issue by only setting ci->roles[CI_ROLE_GADGET] if
> udc_start() succeed.
>
> [ 1.398550] Unable to handle kernel NULL pointer dereference at
> virtual address 00000000
> ...
> [ 1.448600] PC is at dma_pool_free+0xb8/0xf0
> [ 1.453012] LR is at dma_pool_free+0x28/0xf0
> [ 2.113369] [<ffffff80081817d8>] dma_pool_free+0xb8/0xf0
> [ 2.118857] [<ffffff800841209c>] destroy_eps+0x4c/0x68
> [ 2.124165] [<ffffff8008413770>] ci_hdrc_gadget_destroy+0x28/0x50
> [ 2.130461] [<ffffff800840fa30>] ci_hdrc_probe+0x588/0x7e8
> [ 2.136129] [<ffffff8008380fb8>] platform_drv_probe+0x50/0xb8
> [ 2.142066] [<ffffff800837f494>] driver_probe_device+0x1fc/0x2a8
> [ 2.148270] [<ffffff800837f68c>] __device_attach_driver+0x9c/0xf8
> [ 2.154563] [<ffffff800837d570>] bus_for_each_drv+0x58/0x98
> [ 2.160317] [<ffffff800837f174>] __device_attach+0xc4/0x138
> [ 2.166072] [<ffffff800837f738>] device_initial_probe+0x10/0x18
> [ 2.172185] [<ffffff800837e58c>] bus_probe_device+0x94/0xa0
> [ 2.177940] [<ffffff800837c560>] device_add+0x3f0/0x560
> [ 2.183337] [<ffffff8008380d20>] platform_device_add+0x180/0x240
> [ 2.189541] [<ffffff800840f0e8>] ci_hdrc_add_device+0x440/0x4f8
> [ 2.195654] [<ffffff8008414194>] ci_hdrc_usb2_probe+0x13c/0x2d8
> [ 2.201769] [<ffffff8008380fb8>] platform_drv_probe+0x50/0xb8
> [ 2.207705] [<ffffff800837f494>] driver_probe_device+0x1fc/0x2a8
> [ 2.213910] [<ffffff800837f5ec>] __driver_attach+0xac/0xb0
> [ 2.219575] [<ffffff800837d4b0>] bus_for_each_dev+0x60/0xa0
> [ 2.225329] [<ffffff800837ec80>] driver_attach+0x20/0x28
> [ 2.230816] [<ffffff800837e880>] bus_add_driver+0x1d0/0x238
> [ 2.236571] [<ffffff800837fdb0>] driver_register+0x60/0xf8
> [ 2.242237] [<ffffff8008380ef4>] __platform_driver_register+0x44/0x50
> [ 2.248891] [<ffffff80086fd440>] ci_hdrc_usb2_driver_init+0x18/0x20
> [ 2.255365] [<ffffff8008082950>] do_one_initcall+0x38/0x128
> [ 2.261121] [<ffffff80086e0d00>] kernel_init_freeable+0x1ac/0x250
> [ 2.267414] [<ffffff800852f0b8>] kernel_init+0x10/0x100
> [ 2.272810] [<ffffff8008082680>] ret_from_fork+0x10/0x50
>
> Signed-off-by: Jisheng Zhang <jszhang@marvell.com>
> ---
> drivers/usb/chipidea/udc.c | 8 ++++++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
> index f88e9157fad0..60a786c87c06 100644
> --- a/drivers/usb/chipidea/udc.c
> +++ b/drivers/usb/chipidea/udc.c
> @@ -1984,6 +1984,7 @@ static void udc_id_switch_for_host(struct ci_hdrc *ci)
> int ci_hdrc_gadget_init(struct ci_hdrc *ci)
> {
> struct ci_role_driver *rdrv;
> + int ret;
>
> if (!hw_read(ci, CAP_DCCPARAMS, DCCPARAMS_DC))
> return -ENXIO;
> @@ -1996,7 +1997,10 @@ int ci_hdrc_gadget_init(struct ci_hdrc *ci)
> rdrv->stop = udc_id_switch_for_host;
> rdrv->irq = udc_irq;
> rdrv->name = "gadget";
> - ci->roles[CI_ROLE_GADGET] = rdrv;
>
> - return udc_start(ci);
> + ret = udc_start(ci);
> + if (!ret)
> + ci->roles[CI_ROLE_GADGET] = rdrv;
> +
> + return ret;
> }
> --
Thanks for fixing it. In fact, we'd better return failure if
ret && ret != -ENXIO at probe, it stands for initialization
for host or gadget has failed.
--
Best Regards,
Peter Chen
^ permalink raw reply
* support autofocus / autogain in libv4l2
From: Pavel Machek @ 2017-04-25 8:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170424225731.7532e368@vento.lan>
Hi!
> > > Please don't add a new application under lib/. It is fine if you want
> > > some testing application, if the ones there aren't enough, but please
> > > place it under contrib/test/.
> > >
> > > You should likely take a look at v4l2grab first, as it could have
> > > almost everything you would need.
> >
> > I really need some kind of video output. v4l2grab is not useful
> > there. v4l2gl might be, but I don't think I have enough dependencies.
>
> Well, you could use some app to show the snaps that v4l2grab takes.
That would be too slow :-(.
> Yeah, compiling v4l2gl on N9 can indeed be complex. I suspect that it
> shouldn't hard to compile xawtv there (probably disabling some optional
> features).
I do have mplayer working, but that one is not linked against libv4l2
:-(.
> > Umm, and it looks like libv4l can not automatically convert from
> > GRBG10.. and if it could, going through RGB24 would probably be too
> > slow on this device :-(.
>
> I suspect it shouldn't be hard to add support for GRBG10. It already
> supports 8 and 16 bits Bayer formats, at lib/libv4lconvert/bayer.c
> (to both RGB and YUV formats).
Is 16bit bayer a recent development? I can't see it in
commit 374806e868f5a7a48ecffde4c6a1abfcfa5ccd65
Author: Hans Verkuil <hans.verkuil@cisco.com>
Date: Fri Apr 22 09:31:57 2016 +0200
> > Is there an example using autogain/autowhitebalance from
> > libv4lconvert?
>
> Well, if you plug a USB camera without those controls, it should
> automatically expose controls for it, as if the device had such
> controls.
And settings are persistent, so I can enable autogain, then lauch
something like xawtv, and it will automatically get autogain? Ok,
good.
Regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170425/23ad62a6/attachment.sig>
^ permalink raw reply
* [PATCH 4/5 v3] usb: host: fotg2: add Gemini-specific handling
From: Linus Walleij @ 2017-04-25 8:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LNX.2.00.1704241853240.15211@T420s>
On Mon, Apr 24, 2017 at 7:06 PM, Hans Ulli Kroll
<ulli.kroll@googlemail.com> wrote:
> please wait for a while, I'm working on some glue code to support both
> host and device mode on FOTG.
Sure no problem, sorry for being so impatient, it's a character trait.
I sent out bindings and drivers for the Gemini clock controller and reset
controller, so we might want to queue the clock handling at least.
I'm happy if you pick some of these patches and keep them in your
queue BTW.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] arm64: fix the overlap between the kernel image and vmalloc address
From: zhong jiang @ 2017-04-25 8:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu9RuJC9LgsEDSf91x4gV+VoRTLTjA9hGoPAu1ZkFDODmA@mail.gmail.com>
On 2017/4/25 1:56, Ard Biesheuvel wrote:
> On 24 April 2017 at 18:52, Laura Abbott <labbott@redhat.com> wrote:
>> On 04/24/2017 08:51 AM, Mark Rutland wrote:
>>> On Mon, Apr 24, 2017 at 09:28:48PM +0800, zhong jiang wrote:
>>>> On 2017/4/24 18:44, Mark Rutland wrote:
>>>>> So the issue is that we have the callchain below for a kernel image
>>>>> address:
>>>>>
>>>>> read_kcore()
>>>>> ->is_vmalloc_or_module_addr() // returns true
>>>>> ->vread()
>>>>> -->aligned_vread()
>>>>> --->vmalloc_to_page()
>>>>>
>>>>> In is_vmalloc{,or_module}_addr() we just check the addr against
>>>>> VMALLOC_START and VMALLOC_END, so they will return true for a kernel
>>>>> image address.
>>>>>
>>>>> Then, we call vmalloc_to_page(). While this only handles mappings made
>>>>> at page granularity, the kernel image mapping may have used sections. So
>>>>> this tries a bogus walk to the pte level.
>>>>> Should we special-case kernel image handling, e.g. with new
>>>>> is_kernel_image_addr() / kernel_image_to_page() helpers?
>>>> yes , it seems to the best way to implents it without performance back.
>>>> The following patch is the implment. Any thought?
>>>>
>>>> Signed-off-by: zhong jiang <zhongjiang@huawei.com>
>>>>
>>>> diff --git a/include/linux/mm.h b/include/linux/mm.h
>>>> index b84615b..851ac35 100644
>>>> --- a/include/linux/mm.h
>>>> +++ b/include/linux/mm.h
>>>> @@ -475,6 +475,15 @@ static inline bool is_vmalloc_addr(const void *x)
>>>> return false;
>>>> #endif
>>>> }
>>>> +
>>>> +static inline bool is_kernel_image_addr(const void *x)
>>>> +{
>>>> + unsigned long addr = (unsigned long)x;
>>>> +
>>>> + return addr >= (unsigned long)_stext && addr < (unsigned long)_end;
>>>> +
>>>> +}
>>>> +
>>>> #ifdef CONFIG_MMU
>>>> extern int is_vmalloc_or_module_addr(const void *x);
>>>> #else
>>>> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
>>>> index 3ca82d4..9a9ef65 100644
>>>> --- a/mm/vmalloc.c
>>>> +++ b/mm/vmalloc.c
>>>> @@ -229,6 +229,42 @@ int is_vmalloc_or_module_addr(const void *x)
>>>> return is_vmalloc_addr(x);
>>>> }
>>>>
>>>> +static struct page *kernel_image_to_page(const void *kernel_addr, pgd_t *pgd)
>>>> +{
>>>> + unsigned long addr = (unsigned long)kernel_addr;
>>>> + struct page *page = NULL;
>>>> + pud_t *pud;
>>>> + pmd_t *pmd;
>>>> + pte_t *pte;
>>>> +
>>>> + if (pgd_none(*pgd))
>>>> + goto out;
>>>> +
>>>> + pud = pud_offset(pgd, addr);
>>>> + if (pud_none(*pud))
>>>> + goto out;
>>>> +
>>>> + if (pud_sect(*pud))
>>>> + return pud_page(*pud);
>>> The *_sect() helpers are arch-specific, so we cannot use them in generic
>>> code. This would need to be architecture-specific.
>>>
>>> Secondly, this will return head page of the section regardless of which
>>> page in the section the address corresponds to
>>>
>>>> +
>>>> + pmd = pmd_offset(*pmd, addr);
>>>> + if (pmd_none(*pmd))
>>>> + goto out;
>>>> +
>>>> + if (pmd_sect(*pmd))
>>>> + return pmd_page(*pmd);
>>> Likewise on both counts.
>>>
>>>> +
>>>> + pte = pte_offset_kernel(pmd, addr);
>>>> + if (pte_none(*pte))
>>>> + goto out;
>>>> +
>>>> + page = pte_page(*pte);
>>>> +
>>>> +out:
>>>> + return page;
>>>> +
>>>> +}
>>> Given we know what the address should map to, I don't think we need to
>>> walk the page tables here. I think this can be:
>>>
>>> static struct page *kernel_image_to_page(const void *addr)
>>> {
>>> return virt_to_page(lm_alias(vmalloc_addr));
>>> }
>>>
>>>> +
>>>> /*
>>>> * Walk a vmap address to the struct page it maps.
>>>> */
>>>> @@ -244,6 +280,9 @@ struct page *vmalloc_to_page(const void *vmalloc_addr)
>>>> */
>>>> VIRTUAL_BUG_ON(!is_vmalloc_or_module_addr(vmalloc_addr));
>>>>
>>>> + if (is_kernel_image_addr(vmalloc_addr))
>>>> + return kernel_image_to_page(vmalloc_addr, pgd);
>>> It's not clear to me that this is the right place for this to live.
>>>
>>> It might be best to code the kernel image logic directly in kcore (and
>>> kmem), assuming everyone's OK with that approach.
>>>
>> That will fix kcore and kmem but this will show up in other places too.
>> We've gone through and made sure that virt_addr_valid returns
>> true if and only if virt_to_page returns a valid address. I don't know
>> if we can make as strong a claim about is_vmalloc_addr and
>> vmalloc_to_page in all cases but is_vmalloc_addr should not return true
>> for the kernel image. That would at least let kcore fall back to
>> kern_addr_valid which should correctly handle the kernel image.
>> The suggestion to move the kernel image out of VMALLOC_START/VMALLOC_END
>> seems like the best approach although I haven't tried a prototype
>> at all.
>>
> Moving the kernel into the vmalloc region was kind of the point, for
> KASLR. Undoing that means either disabling KASLR, or splitting the
> vmalloc region into a KASLR region only for the kernel, and a vmalloc
> region like we had when vmlinux lived in the linear region.
>
> In general, I think we should be able to deal with different kinds of
> mappings with different granularity in the vmalloc region. If
> necessary, we could introduce a VM_xxx flag for the kernel to
> distinguish such regions from ordinary VM_MAP regions.
> .
>
Hi, Ard
My initial thought is same with you. valloc_to_page is public for any ARCH.
Only arm64 change the mappings granularity. if we need to adjust the function
to any ARCH, it should implement it in each ARCH. or add CONFIG_ARM64 code to
exclude the other ARCH. because the pud_* helper is arch related.
Mark proposed that add kernel_image_is_page helper is more simple.
and I prefer to the Mark opinions. Do you think? or I miss anythings.
Depend on you and other maintainers.
Thanks
zhongjiang
^ permalink raw reply
* [PATCH 1/5 v3] usb: host: add DT bindings for faraday fotg2
From: Linus Walleij @ 2017-04-25 8:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LNX.2.00.1704241846300.15211@T420s>
On Mon, Apr 24, 2017 at 6:53 PM, Hans Ulli Kroll
<ulli.kroll@googlemail.com> wrote:
> Got NAK'ed from Rob on some ealier round due missing "device mode" on this
> IP. I've blatantly overrided this to a host only driver.
>
> These are the needed changes in DT to support both modes
> Note the -dr at the end of fotg210, to reflect this in an dual role device
OK I understood the discussion such that the compatible should
simply be ""faraday,fotg210" as that is the name of the hardware
IP block. This is the name of the hardware name in the Faraday
page:
http://www.faraday-tech.com/html/Product/IPProduct/InterfaceIP/USB2_0.htm
Any other string implies how it is used, so that was what I understood
as the reason to reject it with the "-hcd" (host controller device) suffix.
> +- dr_mode : indicates the working mode for "fotg210-dr" compatible
> + controllers. Can be "host", "peripheral". Default to
> + "host" if not defined for backward compatibility.
This seems right, so it is part of the generic bindings, correct?
> usb at 68000000 {
> - compatible = "cortina,gemini-usb", "faraday,fotg210";
> + compatible = "cortina,gemini-usb", "faraday,fotg210-dr";
But this would be wrong, because the compatible should only
indicate what kind of hardware it is, not how it is going to be used
(whether as host only, slave only or dual-role (OTG).
I hope I didn't get anything wrong here :/
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH RFC 0/5] *** SPI Slave mode support ***
From: Geert Uytterhoeven @ 2017-04-25 8:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <58FF0127.7070703@mentor.com>
Hi Jiada,
On Tue, Apr 25, 2017 at 9:56 AM, Jiada Wang <jiada_wang@mentor.com> wrote:
> On 04/24/2017 06:10 AM, Geert Uytterhoeven wrote:
>> On Mon, Apr 24, 2017 at 2:48 PM, Jiada Wang<jiada_wang@mentor.com> wrote:
>>> On 04/24/2017 03:55 AM, Geert Uytterhoeven wrote:
>>>> On Fri, Apr 14, 2017 at 7:39 AM, Jiada Wang<jiada_wang@mentor.com>
>>>> wrote:
>>>>> Our use case is to use spidev as an interface to communicate with
>>>>> external
>>>>> SPI master devices.
>>>>> meanwhile the SPI bus controller can also act as master device to send
>>>>> data
>>>>> to other
>>>>> SPI slave devices on the board.
>>>>
>>>> That sounds a bit hackish to me. SPI was never meant to be a
>>>> multi-master
>>>> bus.
>>>> While it can be done, you will need external synchronization (signals)
>>>> to
>>>> avoid conflicts between the SPI masters.
>>>
>>> It doesn't need to be a multi-master bus,
>>> for example A is master device for slave device B.
>>> while B has its own slave device C
>>> for each SPI connection A<=> B, and B<=> C, there is only one master
>>> device.
>>>
>>> and I think from use case point of view, it's very normal,
>>> one CPU upon receives command from external SPI master device,
>>> it writes data to its own slave device (EEPROM) connected to it.
>>
>> So "A<=> B" and "B<=> C" are two distinct SPI buses?
>> Or do they share some signals?
>>
>> Your comment seems to suggest otherwise:
>
> the use case of
> "A (master) <=> B (slave)", "B (master) <=> C(slave)", do share MISO and
> MOSI lines,
> but there is no SS line between A and C. so for each SPI slave device, there
> is only one
> master device.
Do you share CLK, too? Then you need a slave select from B to C.
If you use a separate clock, the slave select from B to C can be optional.
> so I think the question becomes whether the above mentioned hardware setup
> is valid or not.
It's a non-conventional SPI bus setup, but it can work, provided you have
some form of synchronization between A and B.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* support autofocus / autogain in libv4l2
From: Pali Rohár @ 2017-04-25 8:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170425080538.GA30380@amd>
On Tuesday 25 April 2017 10:05:38 Pavel Machek wrote:
> > > It would be nice if more than one application could be accessing the
> > > camera at the same time... (I.e. something graphical running preview
> > > then using command line tool to grab a picture.) This one is
> > > definitely not solveable inside a library...
> >
> > Someone once suggested to have something like pulseaudio for V4L.
> > For such usage, a server would be interesting. Yet, I would code it
> > in a way that applications using libv4l will talk with such daemon
> > in a transparent way.
>
> Yes, we need something like pulseaudio for V4L. And yes, we should
> make it transparent for applications using libv4l.
IIRC there is already some effort in writing such "video" server which
would support accessing more application into webcam video, like
pulseaudio server for accessing more applications to microphone input.
--
Pali Roh?r
pali.rohar at gmail.com
^ permalink raw reply
* [PATCH RFC 0/5] *** SPI Slave mode support ***
From: Uwe Kleine-König @ 2017-04-25 8:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <58FF0127.7070703@mentor.com>
Hello Jiada,
On Tue, Apr 25, 2017 at 12:56:23AM -0700, Jiada Wang wrote:
> the use case of
> "A (master) <=> B (slave)", "B (master) <=> C(slave)", do share MISO and
> MOSI lines,
> but there is no SS line between A and C. so for each SPI slave device, there
> is only one
> master device.
So you need a mutex to make A not use the bus while B communicates to C.
Otherwise you have two drivers on MOSI (A and B) and MISO (B and C).
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* support autofocus / autogain in libv4l2
From: Pavel Machek @ 2017-04-25 8:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170424224724.5bb52382@vento.lan>
Hi!
> > > > For focus to be useful, we need autofocus implmented
> > > > somewhere. Unfortunately, v4l framework does not seem to provide good
> > > > place where to put autofocus. I believe, long-term, we'll need some
> > > > kind of "video server" providing this kind of services.
> > > >
> > > > Anyway, we probably don't want autofocus in kernel (even through some
> > > > cameras do it in hardware), and we probably don't want autofocus in
> > > > each and every user application.
> > > >
> > > > So what remains is libv4l2.
> > >
> > > IMO, the best place for autofocus is at libv4l2. Putting it on a
> > > separate "video server" application looks really weird for me.
> >
> > Well... let me see. libraries are quite limited -- it is hard to open
> > files, or use threads/have custom main loop. It may be useful to
> > switch resolutions -- do autofocus/autogain at lower resolution, then
> > switch to high one for taking picture. It would be good to have that
> > in "system" code, but I'm not at all sure libv4l2 design will allow
> > that.
>
> I don't see why it would be hard to open files or have threads inside
> a library. There are several libraries that do that already, specially
> the ones designed to be used on multimidia apps.
Well, fd's are hard, because application can do fork() and now
interesting stuff happens. Threads are tricky, because now you have
locking etc.
libv4l2 is designed to be LD_PRELOADED. That is not really feasible
with "complex" library.
> > It would be good if application could say "render live camera into
> > this window" and only care about user interface, then say "give me a
> > high resolution jpeg". But that would require main loop in the
> > library...
>
> Nothing prevents writing an upper layer on the top of libv4l in
> order to provide such kind of functions.
Agreed.
> > It would be nice if more than one application could be accessing the
> > camera at the same time... (I.e. something graphical running preview
> > then using command line tool to grab a picture.) This one is
> > definitely not solveable inside a library...
>
> Someone once suggested to have something like pulseaudio for V4L.
> For such usage, a server would be interesting. Yet, I would code it
> in a way that applications using libv4l will talk with such daemon
> in a transparent way.
Yes, we need something like pulseaudio for V4L. And yes, we should
make it transparent for applications using libv4l.
Regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170425/576eccb4/attachment.sig>
^ permalink raw reply
* [PATCH 2/2 v5] ARM: dts: Qualcomm APQ8060 DragonBoard ALS sensor
From: Linus Walleij @ 2017-04-25 8:03 UTC (permalink / raw)
To: linux-arm-kernel
This adds the Capella CM3605 ambient light and proximity sensor
to the APQ8060 DragonBoard device tree. Notice that we also set
up pin config for the AOUT line and GPIO lines, and that we set
the default trigger on the infrared LED to associate with the
"cm3605" trigger so the IR LED is controlled by this the CM3605
driver.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ChangeLog v1->v5:
- Switch to the twocell addressing scheme specified in the new
bindings.
- The bindings and IIO driver are both queued for v4.12 in the
IIO tree and pending in linux-next
---
arch/arm/boot/dts/qcom-apq8060-dragonboard.dts | 80 ++++++++++++++++++++++++++
1 file changed, 80 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-apq8060-dragonboard.dts b/arch/arm/boot/dts/qcom-apq8060-dragonboard.dts
index 39d9e6ddefed..355b3b9c31bc 100644
--- a/arch/arm/boot/dts/qcom-apq8060-dragonboard.dts
+++ b/arch/arm/boot/dts/qcom-apq8060-dragonboard.dts
@@ -23,6 +23,7 @@
#include <dt-bindings/input/input.h>
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/pinctrl/qcom,pmic-gpio.h>
+#include <dt-bindings/pinctrl/qcom,pmic-mpp.h>
#include "qcom-msm8660.dtsi"
/ {
@@ -83,6 +84,25 @@
};
};
+ /*
+ * Capella CM3605 light and proximity sensor mounted directly
+ * on the sensor board.
+ */
+ cm3605 {
+ compatible = "capella,cm3605";
+ vdd-supply = <&pm8058_l14>; // 2.85V
+ aset-gpios = <&pm8058_gpio 35 GPIO_ACTIVE_LOW>;
+ capella,aset-resistance-ohms = <100000>;
+ /* GPIO34 has interrupt 225 on the PM8058 */
+ /* Trig on both edges - getting close or far away */
+ interrupts-extended = <&pm8058 225 IRQ_TYPE_EDGE_BOTH>;
+ /* MPP05 analog input to the XOADC */
+ io-channels = <&xoadc 0x00 0x05>;
+ io-channel-names = "aout";
+ pinctrl-names = "default";
+ pinctrl-0 = <&dragon_cm3605_gpios>, <&dragon_cm3605_mpps>;
+ };
+
soc {
pinctrl at 800000 {
/* eMMMC pins, all 8 data lines connected */
@@ -317,6 +337,24 @@
power-source = <PM8058_GPIO_S3>;
};
};
+ dragon_cm3605_gpios: cm3605-gpios {
+ /* Pin 34 connected to the proxy IRQ */
+ pinconf_gpio34 {
+ pins = "gpio34";
+ function = "normal";
+ input-enable;
+ bias-disable;
+ power-source = <PM8058_GPIO_S3>;
+ };
+ /* Pin 35 connected to ASET */
+ pinconf_gpio35 {
+ pins = "gpio35";
+ function = "normal";
+ output-high;
+ bias-disable;
+ power-source = <PM8058_GPIO_S3>;
+ };
+ };
dragon_veth_gpios: veth-gpios {
pinconf {
pins = "gpio40";
@@ -327,6 +365,47 @@
};
};
+ mpps at 50 {
+ dragon_cm3605_mpps: cm3605-mpps {
+ pinconf {
+ pins = "mpp5";
+ function = "analog";
+ input-enable;
+ bias-high-impedance;
+ /* Let's use channel 5 */
+ qcom,amux-route = <PMIC_MPP_AMUX_ROUTE_CH5>;
+ power-source = <PM8058_GPIO_S3>;
+ };
+ };
+ };
+
+ xoadc at 197 {
+ /* Reference voltage 2.2 V */
+ xoadc-ref-supply = <&pm8058_l18>;
+
+ /* Board-specific channels */
+ mpp5 at 05 {
+ /* Connected to AOUT of ALS sensor */
+ reg = <0x00 0x05>;
+ };
+ mpp6 at 06 {
+ /* Connected to test point TP43 */
+ reg = <0x00 0x06>;
+ };
+ mpp7 at 07 {
+ /* Connected to battery thermistor */
+ reg = <0x00 0x07>;
+ };
+ mpp8 at 08 {
+ /* Connected to battery ID detector */
+ reg = <0x00 0x08>;
+ };
+ mpp9 at 09 {
+ /* Connected to XO thermistor */
+ reg = <0x00 0x09>;
+ };
+ };
+
led at 48 {
/*
* The keypad LED @0x48 is routed to
@@ -340,6 +419,7 @@
reg = <0x48>;
label = "pm8058:infrared:proximitysensor";
default-state = "off";
+ linux,default-trigger = "cm3605";
};
led at 131 {
compatible = "qcom,pm8058-led";
--
2.9.3
^ permalink raw reply related
* [PATCH 1/2 v5] ARM: dts: add XOADC and IIO HWMON to MSM8660/APQ8060
From: Linus Walleij @ 2017-04-25 8:03 UTC (permalink / raw)
To: linux-arm-kernel
This adds the PM8058 XOADC node to the PM8058 PMIC node,
defines the 16 channels and further also define an IIO HWMON
node for the channels that are used for housekeeping of
voltages and die temperature for the PMIC chip die.
Tested on the APQ8060 DragonBoard:
cd /sys/class/hwmon/hwmon0
cat in2_input
4773 (DC mains ~5V)
cat in4_input
625 (0.625V reference voltage)
cat in5_input
1250 (1.25V reference voltage)
cat temp1_input
35852 (die temperature)
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ChangeLog v1->v5:
- Switch to the twocell addressing scheme specified in the new
bindings.
- The bindings and IIO driver are both queued for v4.12 in the
IIO tree and pending in linux-next
---
arch/arm/boot/dts/qcom-msm8660.dtsi | 59 +++++++++++++++++++++++++++++++++++++
1 file changed, 59 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-msm8660.dtsi b/arch/arm/boot/dts/qcom-msm8660.dtsi
index 91c9a62ae725..3934a123b182 100644
--- a/arch/arm/boot/dts/qcom-msm8660.dtsi
+++ b/arch/arm/boot/dts/qcom-msm8660.dtsi
@@ -63,6 +63,22 @@
};
};
+ /*
+ * These channels from the ADC are simply hardware monitors.
+ * That is why the ADC is referred to as "HKADC" - HouseKeeping
+ * ADC.
+ */
+ iio-hwmon {
+ compatible = "iio-hwmon";
+ io-channels = <&xoadc 0x00 0x01>, /* Battery */
+ <&xoadc 0x00 0x01>, /* DC in (charger) */
+ <&xoadc 0x00 0x04>, /* VPH the main system voltage */
+ <&xoadc 0x00 0x0b>, /* Die temperature */
+ <&xoadc 0x00 0x0c>, /* Reference voltage 1.25V */
+ <&xoadc 0x00 0x0d>, /* Reference voltage 0.625V */
+ <&xoadc 0x00 0x0e>; /* Reference voltage 0.325V */
+ };
+
soc: soc {
#address-cells = <1>;
#size-cells = <1>;
@@ -267,6 +283,49 @@
row-hold = <91500>;
};
+ xoadc: xoadc at 197 {
+ compatible = "qcom,pm8058-adc";
+ reg = <0x197>;
+ interrupts-extended = <&pm8058 76 IRQ_TYPE_EDGE_RISING>;
+ #address-cells = <2>;
+ #size-cells = <0>;
+ #io-channel-cells = <2>;
+
+ vcoin: adc-channel at 00 {
+ reg = <0x00 0x00>;
+ };
+ vbat: adc-channel at 01 {
+ reg = <0x00 0x01>;
+ };
+ dcin: adc-channel at 02 {
+ reg = <0x00 0x02>;
+ };
+ ichg: adc-channel at 30 {
+ reg = <0x00 0x03>;
+ };
+ vph_pwr: adc-channel at 04 {
+ reg = <0x00 0x04>;
+ };
+ usb_vbus: adc-channel at 0a {
+ reg = <0x00 0x0a>;
+ };
+ die_temp: adc-channel at 0b {
+ reg = <0x00 0x0b>;
+ };
+ ref_625mv: adc-channel at 0c {
+ reg = <0x00 0x0c>;
+ };
+ ref_1250mv: adc-channel at 0d {
+ reg = <0x00 0x0d>;
+ };
+ ref_325mv: adc-channel at 0e {
+ reg = <0x00 0x0e>;
+ };
+ ref_muxoff: adc-channel at 0f {
+ reg = <0x00 0x0f>;
+ };
+ };
+
rtc at 1e8 {
compatible = "qcom,pm8058-rtc";
reg = <0x1e8>;
--
2.9.3
^ permalink raw reply related
* [PATCH v4 07/10] mfd: axp20x: add axp20x-regulator cell for AXP803
From: Lee Jones @ 2017-04-25 7:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170424160103.9447-8-icenowy@aosc.io>
On Tue, 25 Apr 2017, Icenowy Zheng wrote:
> As axp20x-regulator now supports AXP803, add a cell for it.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> Acked-by: Chen-Yu Tsai <wens@csie.org>
> ---
> Changes in v4:
> - Added a trailing comma for new cell, for easier further cell addition.
> Changes in v3:
> - Make the new cell one-liner.
>
> drivers/mfd/axp20x.c | 3 ++-
> drivers/regulator/axp20x-regulator.c | 6 +++---
These 2 changes are orthogonal, thus there is no reason to send them
bundled into a single patch. Doing so complicates things greatly.
Please resubmit the two changes separately, so that they may be
absorbed by our respective subsystems.
> 2 files changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
> index 1dc6235778eb..917b6ddc4f15 100644
> --- a/drivers/mfd/axp20x.c
> +++ b/drivers/mfd/axp20x.c
> @@ -848,7 +848,8 @@ static struct mfd_cell axp803_cells[] = {
> .name = "axp20x-pek",
> .num_resources = ARRAY_SIZE(axp803_pek_resources),
> .resources = axp803_pek_resources,
> - }
> + },
> + { .name = "axp20x-regulator" },
> };
>
> static struct mfd_cell axp806_cells[] = {
> diff --git a/drivers/regulator/axp20x-regulator.c b/drivers/regulator/axp20x-regulator.c
> index 9356ec8a9a1f..e2608fe770b9 100644
> --- a/drivers/regulator/axp20x-regulator.c
> +++ b/drivers/regulator/axp20x-regulator.c
> @@ -311,13 +311,13 @@ static const struct regulator_desc axp803_regulators[] = {
> AXP803_FLDO1_V_OUT, 0x0f, AXP22X_PWR_OUT_CTRL3, BIT(2)),
> AXP_DESC(AXP803, FLDO2, "fldo2", "fldoin", 700, 1450, 50,
> AXP803_FLDO2_V_OUT, 0x0f, AXP22X_PWR_OUT_CTRL3, BIT(3)),
> - AXP_DESC_IO(AXP803, LDO_IO0, "ldo_io0", "ips", 700, 3300, 100,
> + AXP_DESC_IO(AXP803, LDO_IO0, "ldo-io0", "ips", 700, 3300, 100,
> AXP22X_LDO_IO0_V_OUT, 0x1f, AXP20X_GPIO0_CTRL, 0x07,
> AXP22X_IO_ENABLED, AXP22X_IO_DISABLED),
> - AXP_DESC_IO(AXP803, LDO_IO1, "ldo_io1", "ips", 700, 3300, 100,
> + AXP_DESC_IO(AXP803, LDO_IO1, "ldo-io1", "ips", 700, 3300, 100,
> AXP22X_LDO_IO1_V_OUT, 0x1f, AXP20X_GPIO1_CTRL, 0x07,
> AXP22X_IO_ENABLED, AXP22X_IO_DISABLED),
> - AXP_DESC_FIXED(AXP803, RTC_LDO, "rtc_ldo", "ips", 3000),
> + AXP_DESC_FIXED(AXP803, RTC_LDO, "rtc-ldo", "ips", 3000),
> };
>
> static const struct regulator_linear_range axp806_dcdca_ranges[] = {
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH RFC 0/5] *** SPI Slave mode support ***
From: Jiada Wang @ 2017-04-25 7:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdVQS494-BAc-W-XOOLK8Xow85n+Cgih0FG+t4QxCFxhMA@mail.gmail.com>
Hi Geert
On 04/24/2017 06:10 AM, Geert Uytterhoeven wrote:
> Hi Jiada,
>
> On Mon, Apr 24, 2017 at 2:48 PM, Jiada Wang<jiada_wang@mentor.com> wrote:
>> On 04/24/2017 03:55 AM, Geert Uytterhoeven wrote:
>>> On Fri, Apr 14, 2017 at 7:39 AM, Jiada Wang<jiada_wang@mentor.com> wrote:
>>>> On 04/13/2017 12:47 PM, Geert Uytterhoeven wrote:
>>>>> On Thu, Apr 13, 2017 at 2:59 PM, Mark Brown<broonie@kernel.org> wrote:
>>>>>> On Thu, Apr 13, 2017 at 05:13:59AM -0700, jiada_wang at mentor.com wrote:
>>>>>>> From: Jiada Wang<jiada_wang@mentor.com>
>>>>>>>
>>>>>>> v1:
>>>>>>> add Slave mode support in SPI core
>>>>>>> spidev create slave device when SPI controller work in slave mode
>>>>>>> spi-imx support to work in slave mode
>>>>>> Adding Geert who also had a series doing this in progress that was
>>>>>> getting very near to being merged.
>>>>> Thank you!
>>>>>
>>>>> Actually my plan is to fix the last remaining issues and resubmit for
>>>>> v4.13.
>>>> I noticed your patch set for SPI slave support,
>>>> (I am sure you can find out some of the change
>>>> in this patch set is based on your work).
>>>> we have similar requirement to add slave mode support to ecspi IP on imx6
>>>> Soc.
>>>>
>>>> Our use case is to use spidev as an interface to communicate with
>>>> external
>>>> SPI master devices.
>>>> meanwhile the SPI bus controller can also act as master device to send
>>>> data
>>>> to other
>>>> SPI slave devices on the board.
>>> That sounds a bit hackish to me. SPI was never meant to be a multi-master
>>> bus.
>>> While it can be done, you will need external synchronization (signals) to
>>> avoid conflicts between the SPI masters.
>> It doesn't need to be a multi-master bus,
>> for example A is master device for slave device B.
>> while B has its own slave device C
>> for each SPI connection A<=> B, and B<=> C, there is only one master
>> device.
>>
>> and I think from use case point of view, it's very normal,
>> one CPU upon receives command from external SPI master device,
>> it writes data to its own slave device (EEPROM) connected to it.
> So "A<=> B" and "B<=> C" are two distinct SPI buses?
> Or do they share some signals?
>
> Your comment seems to suggest otherwise:
the use case of
"A (master) <=> B (slave)", "B (master) <=> C(slave)", do share MISO and
MOSI lines,
but there is no SS line between A and C. so for each SPI slave device,
there is only one
master device.
so I think the question becomes whether the above mentioned hardware
setup is valid or not.
Thanks,
Jiada
>>>> I found in your implementation, SPI bus controller is limited to either work in master mode or
>>>> slave mode, is there any reasoning to not configure SPI mode based on SPI devices use case?
> If they are distinct, it should work. Then B has two SPI controllers: one slave
> controller controlled by A, and one master controller to control C.
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
^ permalink raw reply
* [PATCH] ARM64: defconfig: enable IR core, decoders and Meson IR device
From: Neil Armstrong @ 2017-04-25 7:39 UTC (permalink / raw)
To: linux-arm-kernel
This patch enables the MEDIA Infrared RC Decoders and Meson Infrared
decoder for ARM64 defconfig.
These drivers are selected as modules by default.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
arch/arm64/configs/defconfig | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index c021aefa..59c400f 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -321,6 +321,11 @@ CONFIG_MEDIA_CAMERA_SUPPORT=y
CONFIG_MEDIA_ANALOG_TV_SUPPORT=y
CONFIG_MEDIA_DIGITAL_TV_SUPPORT=y
CONFIG_MEDIA_CONTROLLER=y
+CONFIG_MEDIA_RC_SUPPORT=y
+CONFIG_RC_CORE=y
+CONFIG_RC_DEVICES=y
+CONFIG_RC_DECODERS=y
+CONFIG_IR_MESON=m
CONFIG_VIDEO_V4L2_SUBDEV_API=y
# CONFIG_DVB_NET is not set
CONFIG_V4L_MEM2MEM_DRIVERS=y
--
1.9.1
^ permalink raw reply related
* [PATCH V9 1/3] irq: Allow to pass the IRQF_TIMER flag with percpu irq request
From: Marc Zyngier @ 2017-04-25 7:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170424195948.GE2137@mai>
On 24/04/17 20:59, Daniel Lezcano wrote:
> On Mon, Apr 24, 2017 at 08:14:54PM +0100, Marc Zyngier wrote:
>> On 24/04/17 19:59, Daniel Lezcano wrote:
>>> On Mon, Apr 24, 2017 at 07:46:43PM +0100, Marc Zyngier wrote:
>>>> On 24/04/17 15:01, Daniel Lezcano wrote:
>>>>> In the next changes, we track when the interrupts occur in order to
>>>>> statistically compute when is supposed to happen the next interrupt.
>>>>>
>>>>> In all the interruptions, it does not make sense to store the timer interrupt
>>>>> occurences and try to predict the next interrupt as when know the expiration
>>>>> time.
>>>>>
>>>>> The request_irq() has a irq flags parameter and the timer drivers use it to
>>>>> pass the IRQF_TIMER flag, letting us know the interrupt is coming from a timer.
>>>>> Based on this flag, we can discard these interrupts when tracking them.
>>>>>
>>>>> But, the API request_percpu_irq does not allow to pass a flag, hence specifying
>>>>> if the interrupt type is a timer.
>>>>>
>>>>> Add a function request_percpu_irq_flags() where we can specify the flags. The
>>>>> request_percpu_irq() function is changed to be a wrapper to
>>>>> request_percpu_irq_flags() passing a zero flag parameter.
>>>>>
>>>>> Change the timers using request_percpu_irq() to use request_percpu_irq_flags()
>>>>> instead with the IRQF_TIMER flag set.
>>>>>
>>>>> For now, in order to prevent a misusage of this parameter, only the IRQF_TIMER
>>>>> flag (or zero) is a valid parameter to be passed to the
>>>>> request_percpu_irq_flags() function.
>>>>
>>>> [...]
>>>>
>>>>> diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
>>>>> index 35d7100..602e0a8 100644
>>>>> --- a/virt/kvm/arm/arch_timer.c
>>>>> +++ b/virt/kvm/arm/arch_timer.c
>>>>> @@ -523,8 +523,9 @@ int kvm_timer_hyp_init(void)
>>>>> host_vtimer_irq_flags = IRQF_TRIGGER_LOW;
>>>>> }
>>>>>
>>>>> - err = request_percpu_irq(host_vtimer_irq, kvm_arch_timer_handler,
>>>>> - "kvm guest timer", kvm_get_running_vcpus());
>>>>> + err = request_percpu_irq_flags(host_vtimer_irq, kvm_arch_timer_handler,
>>>>> + IRQF_TIMER, "kvm guest timer",
>>>>> + kvm_get_running_vcpus());
>>>>> if (err) {
>>>>> kvm_err("kvm_arch_timer: can't request interrupt %d (%d)\n",
>>>>> host_vtimer_irq, err);
>>>>>
>>>>
>>>> How is that useful? This timer is controlled by the guest OS, and not
>>>> the host kernel. Can you explain how you intend to make use of that
>>>> information in this case?
>>>
>>> Isn't it a source of interruption on the host kernel?
>>
>> Only to cause an exit of the VM, and not under the control of the host.
>> This isn't triggering any timer related action on the host code either.
>>
>> Your patch series seems to assume some kind of predictability of the
>> timer interrupt, which can make sense on the host. Here, this interrupt
>> is shared among *all* guests running on this system.
>>
>> Maybe you could explain why you think this interrupt is relevant to what
>> you're trying to achieve?
>
> If this interrupt does not happen on the host, we don't care.
All interrupts happen on the host. There is no such thing as a HW
interrupt being directly delivered to a guest (at least so far). The
timer is under control of the guest, which uses as it sees fit. When
the HW timer expires, the interrupt fires on the host, which re-inject
the interrupt in the guest.
> The flag IRQF_TIMER is used by the spurious irq handler in the try_one_irq()
> function. However the per cpu timer interrupt will be discarded in the function
> before because it is per cpu.
Right. That's not because this is a timer, but because it is per-cpu.
So why do we need this IRQF_TIMER flag, instead of fixing try_one_irq()?
> IMO, for consistency reason, adding the IRQF_TIMER makes sense. Other than
> that, as the interrupt is not happening on the host, this flag won't be used.
>
> Do you want to drop this change?
No, I'd like to understand the above. Why isn't the following patch
doing the right thing?
diff --git a/kernel/irq/spurious.c b/kernel/irq/spurious.c
index 061ba7eed4ed..a4a81c6c7602 100644
--- a/kernel/irq/spurious.c
+++ b/kernel/irq/spurious.c
@@ -72,6 +72,7 @@ static int try_one_irq(struct irq_desc *desc, bool force)
* marked polled are excluded from polling.
*/
if (irq_settings_is_per_cpu(desc) ||
+ irq_settings_is_per_cpu_devid(desc) ||
irq_settings_is_nested_thread(desc) ||
irq_settings_is_polled(desc))
goto out;
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply related
* [PATCH] arm64: dts: exynos: Remove the te-gpios property in the TM2 boards
From: Inki Dae @ 2017-04-25 7:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1493085261-3488-1-git-send-email-hoegeun.kwon@samsung.com>
2017? 04? 25? 10:54? Hoegeun Kwon ?(?) ? ?:
> The decon uses HW-TRIGGER, so TE interrupt is not necessary.
> Therefore, remove the te-gpios property in the TM2 dts.
>
> Signed-off-by: Hoegeun Kwon <hoegeun.kwon@samsung.com>
> ---
> arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
> index 3ff9527..23191eb 100644
> --- a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
> +++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
> @@ -60,7 +60,6 @@
> vci-supply = <&ldo28_reg>;
> reset-gpios = <&gpg0 0 GPIO_ACTIVE_LOW>;
> enable-gpios = <&gpf1 5 GPIO_ACTIVE_HIGH>;
> - te-gpios = <&gpf1 3 GPIO_ACTIVE_HIGH>;
Reviewed-by: Inki Dae <inki.dae@samsung.com>
Thanks,
Inki Dae
> };
> };
>
>
^ permalink raw reply
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