Hi!
Dne četrtek, 12. september 2019 ob 22:26:47 CEST je Maxime Ripard napisal(a):
> Hi,
>
> On Thu, Sep 12, 2019 at 07:51:31PM +0200, Jernej Skrabec wrote:
> > + dev->regmap = devm_regmap_init_mmio(dev->dev, dev->base,
> > +
&deinterlace_regmap_config);
>
> -Original Message-
> From: Gustavo Pimentel
> Sent: 2019年9月12日 19:24
> To: Andrew Murray ; Xiaowei Bao
>
> Cc: robh...@kernel.org; mark.rutl...@arm.com; shawn...@kernel.org; Leo
> Li ; kis...@ti.com; lorenzo.pieral...@arm.com; M.h.
> Lian ; Mingkai Hu ; Roy
> Zang ; jingooh...@gmail.c
> Replace call to kmalloc followed by memcpy with a direct call
> to kmemdup to achieve same functionality.
I suggest to take another look at a similar patch.
fs/omfs: make use of kmemdup
https://lore.kernel.org/r/20190721112326.GA5927@hari-Inspiron-1545/
https://lore.kernel.org/patchwork/patch/1
On 2019/09/10 20:00, Tetsuo Handa wrote:
> On 2019/09/09 22:04, Michal Hocko wrote:
>> On Mon 09-09-19 21:40:24, Tetsuo Handa wrote:
>>> On 2019/09/09 20:36, Michal Hocko wrote:
This is not an improvement. It detaches the oom report and tasks_dump
for an arbitrary amount of time because t
On Sat, Sep 14, 2019 at 02:54:11AM +0200, Stefan Lippers-Hollmann wrote:
> Hi
>
> On 2019-09-13, Greg Kroah-Hartman wrote:
> > From: Michael S. Tsirkin
> >
> > commit a89db445fbd7f1f8457b03759aa7343fa530ef6b upstream.
> >
> > iovec addresses coming from vhost are assumed to be
> > pre-validated,
First, printk is NMI context safe now since the safe printk has been
implemented. The safe printk will help us to do such work in its irqwork.
Second, the NMI irqwork actually does not work if a NMI handler causes
watchdog timeout panic. The NMI irqwork have no chance to run in such
case, while th
-
kernel: 4.4.193-rc1
git repo: https://git.linaro.org/lkft/arm64-stable-rc.git
git branch: 4.4.193-rc1-hikey-20190913-557
git commit: e289b20abbc0882c0710519376b654c0df71b784
git describe: 4.4.193-rc1-hikey-20190913-557
Test details:
https://qa-reports.lin
On Fri, 13 Sep 2019 at 09:21, Greg Kroah-Hartman
wrote:
>
> This is the start of the stable review cycle for the 5.2.15 release.
> There are 37 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Resp
On Fri, 13 Sep 2019 at 09:11, Greg Kroah-Hartman
wrote:
>
> This is the start of the stable review cycle for the 4.19.73 release.
> There are 190 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Re
> -Original Message-
> From: Andrew Murray
> Sent: 2019年9月12日 21:02
> To: Xiaowei Bao
> Cc: robh...@kernel.org; mark.rutl...@arm.com; shawn...@kernel.org; Leo
> Li ; kis...@ti.com; lorenzo.pieral...@arm.com; M.h.
> Lian ; Mingkai Hu ; Roy
> Zang ; jingooh...@gmail.com;
> gustavo.pimen..
> -Original Message-
> From: Andrew Murray
> Sent: 2019年9月12日 21:00
> To: Xiaowei Bao ; helg...@kernel.org
> Cc: robh...@kernel.org; mark.rutl...@arm.com; shawn...@kernel.org; Leo
> Li ; kis...@ti.com; lorenzo.pieral...@arm.com; M.h.
> Lian ; Mingkai Hu ; Roy
> Zang ; jingooh...@gmail.co
> -Original Message-
> From: Andrew Murray
> Sent: 2019年9月12日 20:50
> To: Xiaowei Bao
> Cc: robh...@kernel.org; mark.rutl...@arm.com; shawn...@kernel.org; Leo
> Li ; kis...@ti.com; lorenzo.pieral...@arm.com; M.h.
> Lian ; Mingkai Hu ; Roy
> Zang ; jingooh...@gmail.com;
> gustavo.pimen..
On Fri, 2019-09-13 at 13:47 -0700, Palmer Dabbelt wrote:
> On Mon, 09 Sep 2019 23:00:10 PDT (-0700), Christoph Hellwig wrote:
> > On Fri, Sep 06, 2019 at 11:27:57PM +, Atish Patra wrote:
> > > > Agreed. May be something like this ?
> > > >
> > > > Let's say f/d is enabled in kernel but cpu doe
On Fri, 13 Sep 2019 at 09:11, Greg Kroah-Hartman
wrote:
>
> This is the start of the stable review cycle for the 4.14.144 release.
> There are 21 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Re
On Fri, 2019-09-13 at 20:08 -0700, Paul Walmsley wrote:
> Part of the intention during the definition of the RISC-V kernel
> image
> header was to lay the groundwork for a future merge with the ARM64
> image header. One error during my original review was not noticing
> that the RISC-V header's "m
On Fri, 13 Sep 2019 at 09:09, Greg Kroah-Hartman
wrote:
>
> This is the start of the stable review cycle for the 4.9.193 release.
> There are 14 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Res
Remove excess semicolon after closing parenthesis.
Signed-off-by: Saiyam Doshi
---
sound/soc/qcom/sdm845.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/qcom/sdm845.c b/sound/soc/qcom/sdm845.c
index 882f52ed8231..28f3cef696e6 100644
--- a/sound/soc/qcom/sdm845.c
+
Part of the intention during the definition of the RISC-V kernel image
header was to lay the groundwork for a future merge with the ARM64
image header. One error during my original review was not noticing
that the RISC-V header's "magic" field was at a different size and
position than the ARM64'
usemem will read memory again after access the memory with this option.
It can help test the speed that load page from swap to memory.
Signed-off-by: Hui Zhu
---
usemem.c | 46 --
1 file changed, 40 insertions(+), 6 deletions(-)
diff --git a/usemem.c
From: Frank Hartung
From: Frank Hartung
Meson G12B SoCs (S922X and A311D) are a big-little design where not all CPUs
are equal; the A53s cores are weaker than the A72s.
Include capacity-dmips-mhz properties to tell the OS there is a difference
in processing capacity. The dmips values are based
On Tue, Aug 27, 2019 at 01:18:16PM +, Philippe Schenker wrote:
>
> This patchset holds some common changes that were never upstreamed.
> With latest downstream kernel upgrade, I took the aproach to select
> mainline devicetrees and atomically add missing stuff for downstream.
>
> These patche
* Mathieu Desnoyers:
> I'm unsure whether there are changes I need to do in my rseq patchset, or
> if this is a separate issue that will be fixed separately before glibc 2.31
> is out, which would then update the rseq bits accordingly ?
Someone else (perhaps me) has to fix __libc_multiple_libcs.
Greetings From Mrs. Hilda Kickett Hancock.
May this day bring you peace, happiness, prosperity, good health and every
blessings from above, may all of your wishes and dreams come true!
I was touched to send this message to you after I have carefully gone
through your profile that speaks good of y
On Mon, 2019-08-12 at 00:59 -0500, Wenwen Wang wrote:
> In e1000_set_ringparam(), 'tx_old' and 'rx_old' are not deallocated if
> e1000_up() fails, leading to memory leaks. Refactor the code to fix this
> issue.
>
> Signed-off-by: Wenwen Wang
> ---
> drivers/net/ethernet/intel/e1000/e1000_ethtool
On Thu, 2019-08-22 at 14:33 -0400, Lyude Paul wrote:
> Fatal read errors are worth warning about, unless of course the device
> was just unplugged from the machine - something that's a rather normal
> occurence when the igb/igc adapter is located on a Thunderbolt dock. So,
> let's only WARN() if th
On 9/3/19 7:26 AM, Jarkko Sakkinen wrote:
> Not having LSM hooks does not cause any risk to other parts of the
> kernel as the device can still be controlled by using DAC permissions.
> The hooks just provide more granularity than DAC in access decisions.
Could we translate the security-speak to e
Hi
On 2019-09-13, Greg Kroah-Hartman wrote:
> From: Michael S. Tsirkin
>
> commit a89db445fbd7f1f8457b03759aa7343fa530ef6b upstream.
>
> iovec addresses coming from vhost are assumed to be
> pre-validated, but in fact can be speculated to a value
> out of range.
>
> Userspace address are later va
> On Sep 13, 2019, at 4:28 PM, Sami Tolvanen wrote:
>
>> On Fri, Sep 13, 2019 at 3:46 PM Andy Lutomirski wrote:
>> Didn't you just fix the type of sys_ni_syscall? What am I missing here?
>
> The other patch fixes indirect call type mismatches when the function
> is called through the syscal
> On Sep 13, 2019, at 4:26 PM, Sami Tolvanen wrote:
>
>> On Fri, Sep 13, 2019 at 3:45 PM Andy Lutomirski wrote:
>> Should this be SYSCALL_DEFINE0?
>
> It can be, and that would also fix the issue. However, it does result
> in unnecessary error injection to be hooked up here, which is why
> a
> From: David Hildenbrand
> Sent: Friday, September 13, 2019 2:44 PM
>
> > On recent Windows Server 2019+ hosts, the toolstacks on the hosts
> > guarantees that Dynamic Memory and Memory Resizing can not be enabled
> > if the virtual ACPI S4 state is enabled, and vice versa. Please refer to the
>
If we are already under list_lock, don't call kmalloc(). Otherwise we
will run into deadlock because kmalloc() also tries to grab the same
lock.
Fixing the problem by using a static bitmap instead.
WARNING: possible recursive locking detected
mou
The function doesn't need to return any value, and the check can be
done in one pass.
There is a behavior change: before the patch, we stop at the first
invalid free object; after the patch, we stop at the first invalid
object, free or in use. This shouldn't matter because the original
behavior is
In rsi_send_beacon, if rsi_prepare_beacon fails the allocated skb should
be released.
Signed-off-by: Navid Emamdoost
---
drivers/net/wireless/rsi/rsi_91x_mgmt.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/wireless/rsi/rsi_91x_mgmt.c
b/drivers/net/wireless/rsi/rsi_91x_mgmt.c
On Mon, Jul 08, 2019 at 04:27:40PM +0800, Wei Yang wrote:
>Since ptent will not be changed after previous assignment of entry, it
>is not necessary to do the assignment again.
>
Sounds this one is lost in the time line :-)
>Signed-off-by: Wei Yang
>---
> mm/memory.c | 1 -
> 1 file changed, 1 del
In af9005_identify_state when returning -EIO the allocated buffer should
be released.
Signed-off-by: Navid Emamdoost
---
drivers/media/usb/dvb-usb/af9005.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/media/usb/dvb-usb/af9005.c
b/drivers/media/usb/dvb-usb/af900
On Fri, Sep 13, 2019 at 3:44 PM Andy Lutomirski wrote:
> Shouldn't these be COMPAT_SYSCALL_DEFINE0?
Sure, that would work too.
> I think you should pick this patch up and add it to your series:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/commit/?h=x86/syscalls&id=07daeef08
On Fri, Sep 13, 2019 at 3:46 PM Andy Lutomirski wrote:
> Didn't you just fix the type of sys_ni_syscall? What am I missing here?
The other patch fixes indirect call type mismatches when the function
is called through the syscall table. However, cond_syscall creates an
alias to the actual sys_ni_
On Fri, Sep 13, 2019 at 3:45 PM Andy Lutomirski wrote:
> Should this be SYSCALL_DEFINE0?
It can be, and that would also fix the issue. However, it does result
in unnecessary error injection to be hooked up here, which is why
arm64 preferred to avoid the macro when I fixed it there. S390 uses
SYSC
BCM7211 has a number of similarities with BCM2836, except the register
offsets are different and the bank bits are also different, account for
all of these differences.
Signed-off-by: Florian Fainelli
---
drivers/irqchip/irq-bcm2835.c | 86 +--
1 file changed, 72
Both irq-bcm2835.c and irq-bcm2836.c are currently used with
ARCH_BCM2835 but are soon going to be used with ARCH_BRCMSTB, introduce
a Kconfig symbol to make that those drivers selected/built by other
platforms.
Signed-off-by: Florian Fainelli
---
drivers/irqchip/Kconfig | 5 +
drivers/irqc
With many different kind of interrupt controllers available and used on
7211, add prints to help determine which ones are registered.
Signed-off-by: Florian Fainelli
---
drivers/irqchip/irq-bcm2835.c | 9 +
drivers/irqchip/irq-bcm2836.c | 2 ++
2 files changed, 11 insertions(+)
diff --g
The root interrupt controller on 7211 is about identical to the one
existing on BCM2836, except that the SMP cross call are done through the
standard ARM GIC-400 interrupt controller. This interrupt controller is
used for side band wake-up signals though.
Signed-off-by: Florian Fainelli
---
driv
Now that irq-bcm2835.c and irq-bcm2836.c have been updated to support
BCM7211 which is under ARCH_BRCMSTB, build both drivers for
ARCH_BRCMSTB.
Signed-off-by: Florian Fainelli
---
drivers/irqchip/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/irqchip/Kconfig
BCM7211 features a second level interrupt controller similar in nature
to BCM2836, with a few modifications to the register offsets, document
that specific compatible string.
Signed-off-by: Florian Fainelli
---
.../interrupt-controller/brcm,bcm2835-armctrl-ic.txt| 6 --
1 file change
BCM7211 uses a very similar root interrupt controller than what exists on
BCM2836, define a specific compatible string to key off specific
behavior.
Signed-off-by: Florian Fainelli
---
.../bindings/interrupt-controller/brcm,bcm2836-l1-intc.txt| 4 +++-
1 file changed, 3 insertions(+), 1 dele
Hi Marc, Jason, Thomas,
This patch series updates the BCM2835 and BCM2836 interrupt controller
drivers to support BCM7211 which can make use of those drivers in some
configurations where the ARM GIC is muxed out and the legacy ARM
interrupt controller is used instead.
Thank you!
Florian Fainelli
Hi Alex,
> -Original Message-
> From: Alex Williamson
> Sent: Friday, September 13, 2019 4:33 PM
> To: Parav Pandit
> Cc: Jiri Pirko ; kwankh...@nvidia.com;
> coh...@redhat.com; da...@davemloft.net; k...@vger.kernel.org; linux-
> ker...@vger.kernel.org; net...@vger.kernel.org
> Subject:
On Fri, Sep 13, 2019 at 11:21:17AM -0400, Alan Stern wrote:
> On Thu, 12 Sep 2019, Paul E. McKenney wrote:
> > On Fri, Sep 06, 2019 at 02:11:29PM -0400, Alan Stern wrote:
> > > Folks:
> > >
> > > I have spent some time writing up a section for
> > > tools/memory-model/Documentation/explanation.tx
From: Fenglin Wu
Currently, PWM core driver provides interfaces for configuring PWM
period and duty length in nanoseconds with an integer data type, so
the max period can be only set to ~2.147 seconds. Add interfaces which
can set PWM period and duty with u64 data type to remove this
limitation.
From: Fenglin Wu
Normally, PWM channel has fixed output until software request to change
its settings. There are some PWM devices which their outputs could be
changed autonomously according to a predefined pattern programmed in
hardware. Add pwm_output_type enum type to identify these two differe
On 9/12/19 6:46 PM, Kees Cook wrote:
> On Thu, Sep 12, 2019 at 05:16:02PM -0700, Kees Cook wrote:
>> On Thu, Sep 12, 2019 at 02:40:19PM -0700, Randy Dunlap wrote:
>>> This is 32-bit kernel, just happens to be running on a 64-bit laptop.
>>> I added the debug printk in __phys_addr() just before "[cu
The MDIO device reset line is optional and now that gpiod_get_optional()
returns proper value when GPIO support is compiled out, there is no
reason to use fwnode_get_named_gpiod() that I plan to hide away.
Let's switch to using more standard gpiod_get_optional() and
gpiod_set_consumer_name() to ke
On Mon, 2019-09-09 at 04:42 +0200, Giovanni Gherdovich wrote:
...
> +
> +/*
> + * APERF/MPERF frequency ratio computation.
> + *
> + * The scheduler wants to do frequency invariant accounting and
> needs a <1
> + * ratio to account for the 'current' frequency, corresponding to
> + * freq_curr / f
Dexuan,
> When we're in storvsc_suspend(), we're sure the SCSI layer has
> quiesced the scsi device by scsi_bus_suspend() -> ... ->
> scsi_device_quiesce(), so the low level SCSI adapter driver only needs
> to suspend/resume its own state.
Acked-by: Martin K. Petersen
--
Martin K. Petersen
On Fri, Sep 13, 2019 at 2:00 PM Sami Tolvanen wrote:
>
> Define a weak function in COND_SYSCALL instead of a weak alias to
> sys_ni_syscall, which has an incompatible type. This fixes indirect
> call mismatches with Control-Flow Integrity (CFI) checking.
>
Didn't you just fix the type of sys_ni_s
On Fri, Sep 13, 2019 at 2:00 PM Sami Tolvanen wrote:
>
> Use the correct function type for sys_ni_syscall in system
> call tables to fix indirect call mismatches with Control-Flow
> Integrity (CFI) checking.
Should this be SYSCALL_DEFINE0?
On Fri, Sep 13, 2019 at 2:00 PM Sami Tolvanen wrote:
>
> Use the correct function type to avoid tripping Control-Flow
> Integrity (CFI) checking.
>
> Signed-off-by: Sami Tolvanen
> ---
> arch/x86/ia32/ia32_signal.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch
The following commit has been merged into the sched/core branch of tip:
Commit-ID: eb92692b2544d3f415887dbbc98499843dfe568b
Gitweb:
https://git.kernel.org/tip/eb92692b2544d3f415887dbbc98499843dfe568b
Author:Quentin Perret
AuthorDate:Thu, 12 Sep 2019 11:44:04 +02:00
Committ
The following commit has been merged into the sched/core branch of tip:
Commit-ID: 4adcdcea717cb2d8436bef00dd689aa5bc76f11b
Gitweb:
https://git.kernel.org/tip/4adcdcea717cb2d8436bef00dd689aa5bc76f11b
Author:Miles Chen
AuthorDate:Thu, 12 Sep 2019 18:34:52 +08:00
Committer:
On Fri, Sep 13, 2019 at 09:45:31PM +, Yonghong Song wrote:
On 9/10/19 11:38 AM, Ivan Khoronzhuk wrote:
Basically it only enables that was added by previous couple fixes.
For sure, just make tools/include to be included after sysroot
headers.
export ARCH=arm
export CROSS_COMPILE=arm-linux-
On Fri, Sep 13, 2019 at 2:00 PM Sami Tolvanen wrote:
>
> Although a syscall defined using SYSCALL_DEFINE0 doesn't accept
> parameters, use the correct function type to avoid type mismatches
> with Control-Flow Integrity (CFI) checking.
Acked-by: Andy Lutomirski
On Fri, Sep 13, 2019 at 09:43:22PM +, Yonghong Song wrote:
On 9/10/19 11:38 AM, Ivan Khoronzhuk wrote:
In case of LDFLAGS and EXTRA_CC/CXX flags there is no way to pass them
correctly to build command, for instance when --sysroot is used or
external libraries are used, like -lelf, wich can
On Fri, Sep 13, 2019 at 09:41:25PM +, Yonghong Song wrote:
On 9/10/19 11:38 AM, Ivan Khoronzhuk wrote:
The main reason for that - HOSTCC and CC have different aims.
It was tested for arm cross compilation, based on linaro toolchain,
but should work for others.
In order to split cross comp
Similar to possible_clones, we don't actually use possible_crtcs until
the driver is registered with userspace. So, fix the documentation to
indicate this.
Signed-off-by: Lyude Paul
---
include/drm/drm_encoder.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/drm/drm_
On Fri, Sep 13, 2019 at 09:33:58PM +, Yonghong Song wrote:
On 9/10/19 11:38 AM, Ivan Khoronzhuk wrote:
The makefile.prog is added only, will be used in sample/bpf/Makefile
later in order to switch cross-compiling on CC from HOSTCC.
The HOSTCC is supposed to build binaries and tools runnin
On 13/09/19 04:46, Sean Christopherson wrote:
> Restore the fast invalidate flow for zapping shadow pages and use it
> whenever vCPUs can be active in the VM. This fixes (in theory, not yet
> confirmed) a regression reported by James Harvey where KVM can livelock
> in kvm_mmu_zap_all() when it's i
On Thu, 12 Sep 2019 18:32:04 -0700
Megha Dey wrote:
> This patch adds support for the creation of a new IMS irq domain. It
> creates a new irq_chip associated with the IMS domain and adds the
> necessary domain operations to it.
>
> Cc: Jacob Pan
> Signed-off-by: Sanjay Kumar
> Signed-off-by:
Hi Bart,
> On 9/11/19 5:40 PM, Martin K. Petersen wrote:
>> * Do not use custom To: and Cc: for individual patches. We want to see the
>> whole series, even patches that potentially need to go through a different
>> subsystem tree.
>
> Thanks for having written this summary. This is very hel
The USB interface may get detected before the platform/EC one, so let's
note the state of the base (if we receive event) and use it to correctly
initialize the tablet mode switch state.
Also let's start the HID interface immediately when probing, this will
ensure that we correctly process "base fo
When we receive "keyboard position" event from Whiskers we can
conclude that the base is attached, even if we did not get EC event
for that. We may miss EC event because there are some units which
have a lot of leakage on the ADC pins that the EC uses to determine
whether or not a base is attached.
Currently, the tablet mode switch that takes two signals as its input:
base attached switch from the EC and some GMR signal from whiskers when
it's folded over. This tablet mode switch is then sent to Chrome, which
changes the UI.
However, there are some units which have a lot of leakage on the AD
On Wed, 11 Sep 2019 16:39:47 +0100, Colin King wrote:
> From: Colin Ian King
>
> There is a spelling mistake on the documentation. Fix it.
>
> Signed-off-by: Colin Ian King
> ---
> Documentation/devicetree/bindings/bus/qcom,ebi2.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
A
Add PDC interrupt controller device bindings for SDM845.
Signed-off-by: Lina Iyer
---
arch/arm64/boot/dts/qcom/sdm845.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index be0022e..41455b8 100644
--
Some interrupt controllers in a SoC, are always powered on and have a
select interrupts routed to them, so that they can wakeup the SoC from
suspend. Add wakeup-parent DT property to refer to these interrupt
controllers.
Cc: devicet...@vger.kernel.org
Signed-off-by: Lina Iyer
Reviewed-by: Rob Her
Introduce a new domain for wakeup capable GPIOs. The domain can be
requested using the bus token DOMAIN_BUS_WAKEUP. In the following
patches, we will specify PDC as the wakeup-parent for the TLMM GPIO
irqchip. Requesting a wakeup GPIO will setup the GPIO and the
corresponding PDC interrupt as its p
From: Maulik Shah
Add irqchip calls to set/get interrupt state from the parent interrupt
controller. When GPIOs are renabled as interrupt lines, it is desirable
to clear the interrupt state at the GIC. This avoids any unwanted
interrupt as a result of stale pending state recorded when the line wa
Enable PDC interrupt controller for SDM845 devices. The interrupt
controller can detect wakeup capable interrupts when the SoC is in a low
power state.
Signed-off-by: Lina Iyer
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arc
PDC always-on interrupt controller can detect certain GPIOs even when
the TLMM interrupt controller is powered off. Link the PDC as TLMM's
wakeup parent.
Signed-off-by: Lina Iyer
---
arch/arm64/boot/dts/qcom/sdm845.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/qcom
Some GPIOs are marked as wakeup capable and are routed to another
interrupt controller that is an always-domain and can detect interrupts
even most of the SoC is powered off. The wakeup interrupt controller
wakes up the GIC and replays the interrupt at the GIC.
Setup the TLMM irqchip in hierarchy
From: Maulik Shah
On certain QTI chipsets some GPIOs are direct-connect interrupts to the
GIC to be used as regular interrupt lines. When the GPIOs are not used
for interrupt generation the interrupt line is disabled. But disabling
the interrupt at GIC does not prevent the interrupt to be reporte
Add interrupt parents for wakeup capable GPIOs for Qualcomm SDM845 SoC.
Signed-off-by: Lina Iyer
---
Changes in RFC v2:
- Rearranged GPIO wakeup parent map
---
drivers/pinctrl/qcom/pinctrl-sdm845.c | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git
GPIOs that can be configured as wakeup are routed to the PDC wakeup
interrupt controller and from there to the GIC interrupt controller. On
some QCOM SoCs, the interface to the GIC for wakeup capable GPIOs have
additional hardware registers that need to be configured as well to
match the trigger ty
Newer SoCs have increased the number of interrupts routed to the PDC
interrupt controller. Update the definition of max PDC interrupts.
Signed-off-by: Lina Iyer
---
drivers/irqchip/qcom-pdc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/irqchip/qcom-pdc.c b/dri
Thanks for all the helpful reviews. Here is the next revision addressing the
comments.
Changes in RFC v2:
- Address review comments #3, #4, #6, #7, #8, #9, #10
- Rebased on top of linux-next GPIO latest patches [1],[3],[4]
- Increase PDC max irqs in #2 (avoid merge conflict
A single controller can handle normal interrupts and wake-up interrupts
independently, with a different numbering space. It is thus crucial to
allow the driver for such a controller discriminate between the two.
A simple way to do so is to tag the wake-up irqdomain with a "bus token"
that indicate
When an interrupt is to be serviced, the convention is to mask the
interrupt at the chip and unmask after servicing the interrupt. Enabling
and disabling the interrupt at the PDC irqchip causes an interrupt storm
due to the way dual edge interrupts are handled in hardware.
Skip configuring the PDC
In addition to configuring the PDC, additional registers that interface
the GIC have to be configured to match the GPIO type. The registers on
some QCOM SoCs are access restricted, while on other SoCs are not. They
SoCs with access restriction to these SPI registers need to be written
from the firm
On Thu, Sep 12, 2019 at 03:47:16PM +0200, Christoph Hellwig wrote:
> On Thu, Sep 12, 2019 at 11:44:12PM +1000, Stephen Rothwell wrote:
> > Hi all,
> >
> > Today's linux-next merge of the configfs tree got a conflict in:
> >
> > fs/configfs/symlink.c
> >
> > between commit:
> >
> > e272d4fb7
On Sat, 24 Aug 2019 15:28:46 +0200, =?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=
wrote:
> Referencing device tree nodes from a property allows to pass arguments.
> This is for example used for referencing gpios. This looks as follows:
>
> gpio_ctrl: gpio-controller {
> #gpio-c
On Wed, Sep 4, 2019 at 9:03 AM Niklas Cassel wrote:
>
> find_next_bit() takes a parameter of size long, and performs arithmetic
> that assumes that the argument is of size long.
>
> Therefore we cannot pass a u32, since this will cause find_next_bit()
> to read outside the stack buffer and will pr
On Fri, 2019-09-13 at 16:13 -0500, Rob Herring wrote:
> DT bindings are moving to using a json-schema based schema format
> instead of freeform text. Add a checkpatch.pl check to encourage using
> the schema for new bindings. It's not yet a requirement, but is
> progressively being required by some
On Fri, 13 Sep 2019 17:26:07 +0530, Gokul Sriram Palanisamy wrote:
> Add mailbox support required in IPQ8074 SoCs.
>
> Signed-off-by: Gokul Sriram Palanisamy
> Signed-off-by: Sricharan R
> ---
> Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.txt | 1 +
> 1 file changed, 1 inser
On Fri, 13 Sep 2019 17:26:09 +0530, Gokul Sriram Palanisamy wrote:
> Add compatible for IPQ8074 support.
> This does not need clocks for scm calls.
>
> Signed-off-by: Gokul Sriram Palanisamy
> Signed-off-by: Sricharan R
> ---
> Documentation/devicetree/bindings/firmware/qcom,scm.txt | 1 +
> 1
On Fri, 13 Sep 2019 17:26:05 +0530, Gokul Sriram Palanisamy wrote:
> Add binding for WCSSAON reset required for Q6v5 reset on IPQ8074 SoC.
>
> Signed-off-by: Gokul Sriram Palanisamy
> Signed-off-by: Sricharan R
> Signed-off-by: Nikhil Prakash V
> ---
> include/dt-bindings/clock/qcom,gcc-ipq807
On 9/9/19 8:00 AM, Filipe Laíns wrote:
On Sat, 2019-08-31 at 13:56 -0400, Pedro Vanzella wrote:
+static int hidpp20_battery_map_status_voltage(u8 data[3], int
*voltage)
+{
+ int status;
+
+ switch (data[2]) {
+ case 0x00: /* discharging */
+ status = POWER_SUPPLY_
On 9/10/19 11:38 AM, Ivan Khoronzhuk wrote:
> Basically it only enables that was added by previous couple fixes.
> For sure, just make tools/include to be included after sysroot
> headers.
>
> export ARCH=arm
> export CROSS_COMPILE=arm-linux-gnueabihf-
> make samples/bpf/ SYSROOT="path/to/sysroo
Jens,
> Additionally, it would seem saner to standardize rules around when
> code is expected to hit the maintainers hands for kernel
> releases. Both yours and Martins deals with that, there really
> shouldn't be the need to have this specified in detail per sub-system.
Yeah. There is basicall
On 9/10/19 11:38 AM, Ivan Khoronzhuk wrote:
> In case of LDFLAGS and EXTRA_CC/CXX flags there is no way to pass them
> correctly to build command, for instance when --sysroot is used or
> external libraries are used, like -lelf, wich can be absent in
> toolchain. This is used for samples/bpf cros
On 13.09.19 22:54, Dexuan Cui wrote:
>> From: David Hildenbrand
>> Sent: Friday, September 13, 2019 12:46 AM
>>
>> On 12.09.19 21:18, Dexuan Cui wrote:
>>> 3. Hibernation can be especially useful when we pass through a PCIe device,
>>> e.g. a NIC, a NVMe controller or a GPU, to the VM, as usually
On 9/10/19 11:38 AM, Ivan Khoronzhuk wrote:
> The main reason for that - HOSTCC and CC have different aims.
> It was tested for arm cross compilation, based on linaro toolchain,
> but should work for others.
>
> In order to split cross compilation (CC) with host build (HOSTCC),
> lets base bpf s
1 - 100 of 959 matches
Mail list logo
