Since A31, memory mapping of the IR driver has changed.
Prefer the A31 bindings instead of A13.
Signed-off-by: Clément Péron
Acked-by: Sean Young
---
arch/arm/boot/dts/sun6i-a31.dtsi | 2 +-
arch/arm/boot/dts/sun8i-a83t.dtsi | 2 +-
arch/arm/boot/dts/sun9i-a80.dtsi | 2 +-
3 files changed, 3
From: Igors Makejevs
IR peripheral is completely compatible with A31 one.
Signed-off-by: Igors Makejevs
Signed-off-by: Jernej Skrabec
Signed-off-by: Clément Péron
Acked-by: Sean Young
---
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 18 ++
1 file changed, 18 insertions(+)
Allwiner A31 has a different memory mapping so add the compatible
we will need it later.
Signed-off-by: Clément Péron
Acked-by: Sean Young
Acked-by: Maxime Ripard
---
drivers/media/rc/sunxi-cir.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/media/rc/sunxi-cir.c b/driver
Enable CONFIG_IR_SUNXI option for ARM64, so that Allwinner A64/H6 SoCs
can use their IR receiver controller.
Signed-off-by: Clément Péron
Acked-by: Sean Young
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/d
There are some minor differences between A31 or A64 with H6 IR peripheral.
But A31 IR driver is compatible with H6.
Signed-off-by: Clément Péron
Acked-by: Sean Young
---
Documentation/devicetree/bindings/media/sunxi-ir.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devic
Allwinner H6 IR is similar to A31 and can use same driver.
Add support for it.
Signed-off-by: Clément Péron
Acked-by: Sean Young
---
arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 19 +++
1 file changed, 19 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6.dts
Since A31, memory mapping of the IR driver has changed.
Prefer the A31 bindings instead of A13.
Signed-off-by: Clément Péron
Acked-by: Sean Young
---
arch/arm/boot/dts/sunxi-h3-h5.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/sunxi-h3-h5.dtsi
b/arc
Hi,
A64 IR support series[1] pointed out that an A31 bindings should be
introduced.
This series introduce the A31 compatible bindings, then switch it on
the already existing board.
Finally introduce A64 and H6 support.
I have reenable the other H6 boards IR support as Ondrej solve the issue.
R
Quoting Jeffrey Hugo (2019-06-07 14:31:13)
> On Fri, Jun 7, 2019 at 2:38 PM Stephen Boyd wrote:
> >
> > Quoting Jeffrey Hugo (2019-05-21 07:52:28)
> > > On 5/21/2019 8:44 AM, Jeffrey Hugo wrote:
> > > > The multimedia clock controller (mmcc) is the main clock controller for
> > > > the multimedia
On Fri, Jun 7, 2019 at 1:11 AM Gustavo A. R. Silva
wrote:
> Update the code to use a flexible array member instead of a pointer in
> structure tb10x_pinctrl and use the struct_size() helper:
>
> struct tb10x_pinctrl {
> ...
> struct tb10x_of_pinfunc pinfuncs[];
> };
>
> Also, make
Palmer,
Kevin Hilman writes:
> Enable PRCI clock driver and serial console by default, so the default
> upstream defconfig is bootable to a serial console.
>
> Signed-off-by: Kevin Hilman
If possible, this would be great to have for v5.2-rc so we have a
bootable upstream defconfig ready for ke
On Fri, 7 Jun 2019 20:31:43 +0300, Ilya Maximets wrote:
> +static int xsk_notifier(struct notifier_block *this,
> + unsigned long msg, void *ptr)
> +{
> + struct sock *sk;
> + struct net_device *dev = netdev_notifier_info_to_dev(ptr);
> + struct net *net = dev_net(d
On Wed, May 29, 2019 at 08:36:49PM +, Vineeth Remanan Pillai wrote:
> From: Peter Zijlstra
>
> Instead of only selecting a local task, select a task for all SMT
> siblings for every reschedule on the core (irrespective which logical
> CPU does the reschedule).
>
> NOTE: there is still potent
Hi,
Den fre 7 juni 2019 kl 22:49 skrev Richard Weinberger :
>
> - Ursprüngliche Mail -
> > Von: "Emil Lenngren"
> > An: "richard"
> > CC: "linux-mtd" , "Sebastian Andrzej
> > Siewior" , "linux-kernel"
> > , "Michele Dionisio"
> >
> > Gesendet: Freitag, 7. Juni 2019 22:27:09
> > Betref
Hi Enric,
On Fri, 2019-06-07 at 22:51 +0200, Enric Balletbo Serra wrote:
> Hi,
>
> Missatge de Guenter Roeck del dia dv., 7 de juny
> 2019 a les 22:11:
> > On Fri, Jun 7, 2019 at 12:27 PM Nick Crews wrote:
> > > Hi!
> > >
> > > On Fri, Jun 7, 2019 at 12:03 PM Ezequiel Garcia
> > > wrote:
> >
With architectures allowing the kernel to be placed almost arbitrarily
in memory (e.g.: ARM64), it is possible to have the kernel resides at
physical addresses above 4GB, resulting in neither the default CMA area,
nor the atomic pool from successfully allocating. This does not prevent
specific peri
There are a couple of patches that were mistakenly not included in 4.19.47.
https://lore.kernel.org/stable/20190606131558.GJ29739@sasha-vm/
Sorry for that and thanks for reporting.
Regards,
Nadav
> On Jun 7, 2019, at 4:54 PM, Francesco Ruggeri wrote:
>
> I see the following kernel panic in 4.
I see the following kernel panic in 4.19.47 as soon as I hit a kprobe.
In this case it happened right after
# cd /sys/kernel/debug/tracing/
# echo >trace
# echo 'p rollback_registered_many' >kprobe_events
# echo 1 >events/kprobes/enable
# ip netns add dummy
# ip netns del dummy
but I have also
On Fri, Jun 07, 2019 at 11:25:35AM -0700, Ira Weiny wrote:
> On Fri, Jun 07, 2019 at 01:04:26PM +0200, Jan Kara wrote:
> > On Thu 06-06-19 15:03:30, Ira Weiny wrote:
> > > On Thu, Jun 06, 2019 at 12:42:03PM +0200, Jan Kara wrote:
> > > > On Wed 05-06-19 18:45:33, ira.we...@intel.com wrote:
> > > >
On Thu, 2019-06-06 at 11:33 +0100, James Morse wrote:
> > Disagree. The various drivers don't depend on each other.
> > I think we should keep the drivers separated as they are distinct and
> > independent IP blocks.
>
> But they don't exist in isolation, they both depend on the
> integration-c
--
Dear Friend,
I am Mrs Alice Johnson.am sending you this brief letter to solicit your
partnership to transfer $18.5 million US Dollars.I shall send you more
information and procedures when I receive positive response from you.
please send me a message in my Email box (mrsalicejohns...@gmail.
On Fri, 2019-06-07 at 16:11 +0100, James Morse wrote:
> I'm coming at this from somewhere else. This stuff has to be considered all
> the way
> through the system. Just because each component supports error detection,
> doesn't mean you
> aren't going to get silent corruption. Likewise if another
I am seeing a boot failure on our iMX6D-based embedded platform running
v5.2-rc3. It seems to stall for about 20 seconds after "random: crng
init done" and then panic with a bunch of RCU stall and soft-lockup
errors. It seems like something is hanging up in the iMX6 PCIe driver.
Boot log is below.
--
Hello ?
My name is Daniel Gnon
I sent you this letter a month ago but I'm not sure if you have it, there
is something I would like to discuss with you below is my personal email
for more details
Email danielgno...@gmail.com
Hi Linus,
Please pull the following second Kselftest fixes update for
Linux 5.2 rc4.
This Kselftest second fixes update for Linux 5.2-rc4 consists of a
single fix for vm test build failure regression when it is built by
itself.
I found this while I was sanity checking the first fixes update for
On 06/07/19 at 02:16pm, tip-bot for Baoquan He wrote:
> Commit-ID: 00e5a2bbcc31d5fea853f8daeba0f06c1c88c3ff
> Gitweb:
> https://git.kernel.org/tip/00e5a2bbcc31d5fea853f8daeba0f06c1c88c3ff
> Author: Baoquan He
> AuthorDate: Thu, 23 May 2019 10:57:44 +0800
> Committer: Borislav Petkov
>
Hi Marc,
On 6/5/2019 10:56 PM, Marc Zyngier wrote:
> On 05/06/2019 18:16, Sricharan R wrote:
>> Add initial device tree support for the Qualcomm IPQ6018 SoC and
>> CP01 evaluation board.
>>
>> Signed-off-by: Sricharan R
>> Signed-off-by: Abhishek Sahu
>> ---
>> arch/arm64/boot/dts/qcom/Makefile
Hi Sudeep,
On 6/5/2019 11:04 PM, Sudeep Holla wrote:
> On Wed, Jun 05, 2019 at 10:58:57PM +0530, Sricharan R wrote:
>> Add initial device tree support for the Qualcomm IPQ6018 SoC and
>> CP01 evaluation board.
>>
>> Signed-off-by: Sricharan R
>> Signed-off-by: Abhishek Sahu
>> ---
>> arch/arm64
On 2019/06/08 2:09, Pavel Machek wrote:
> On Tue 2019-05-28 19:15:43, Tetsuo Handa wrote:
>> On 2019/05/28 17:51, Sergey Senozhatsky wrote:
You are trying to omit passing KERN_UNSUPPRESSED by utilizing implicit
printk
context information. But doesn't such attempt resemble
find
On Wed 05 Jun 10:15 PDT 2019, Sricharan R wrote:
> Add initial pinctrl driver to support pin configuration with
> pinctrl framework for ipq6018.
>
> Signed-off-by: Sricharan R
> Signed-off-by: Rajkumar Ayyasamy
> Signed-off-by: speriaka
These should start with the author, then followed by eac
On Wed 05 Jun 10:15 PDT 2019, Sricharan R wrote:
> Signed-off-by: Sricharan R
> Signed-off-by: speriaka
> ---
> Documentation/devicetree/bindings/arm/qcom.yaml | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml
> b/Documentation/devicetr
On Wed 05 Jun 10:15 PDT 2019, Sricharan R wrote:
> This patch adds support for the global clock controller found on
> the ipq6018 based devices.
>
> Signed-off-by: Sricharan R
> Signed-off-by: anusha
> Signed-off-by: Abhishek Sahu
Please fix your s-o-b chain, as described in my reply to 1/8..
On Wed 05 Jun 10:16 PDT 2019, Sricharan R wrote:
> These configs are required for booting kernel in qcom
> ipq6018 boards.
>
> Signed-off-by: Sricharan R
Reviewed-by: Bjorn Andersson
> ---
> arch/arm64/configs/defconfig | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm64/c
On Wed 05 Jun 10:15 PDT 2019, Sricharan R wrote:
> Add the compatible strings and the include file for ipq6018
> gcc clock controller.
>
> Signed-off-by: Sricharan R
> Signed-off-by: anusha
> Signed-off-by: Abhishek Sahu
Please fix your s-o-b chain.
> ---
> .../devicetree/bindings/clock/qco
On Wed 05 Jun 10:16 PDT 2019, Sricharan R wrote:
> Add initial device tree support for the Qualcomm IPQ6018 SoC and
> CP01 evaluation board.
>
> Signed-off-by: Sricharan R
> Signed-off-by: Abhishek Sahu
Please fix the order of these (or add a Co-developed-by).
> ---
> arch/arm64/boot/dts/qco
On Tue 04 Jun 05:29 PDT 2019, Niklas Cassel wrote:
> The current entry-latency-us is too short.
> The proper way to convert between the device tree properties
> from the vendor tree to the upstream PSCI device tree properties is:
>
> entry-latency-us = qcom,time-overhead - qcom,latency-us
>
> wh
On 6/8/2019 4:09 AM, Linus Walleij wrote:
On Thu, Jun 6, 2019 at 11:55 AM Keerthy wrote:
The patch adds k3 am654 compatible, specific properties and
an example.
Signed-off-by: Keerthy
Patch applied with the three others, so now all
GPIO changes are in tree.
Please funnel all the DTS ch
On 5/28/2019 6:57 PM, Mark Brown wrote:
On Tue, May 28, 2019 at 03:23:41PM +0530, Keerthy wrote:
On 22/05/19 9:05 PM, Mark Brown wrote:
On Thu, May 16, 2019 at 10:02:18AM +0530, Keerthy wrote:
Acked-by: Mark Brown
This patch will come via the mfd branch?
I'd expect so, IIRC it had a
On 6/6/2019 4:26 AM, Jose Abreu wrote:
> Convert stmmac driver to phylink.
>
> Signed-off-by: Jose Abreu
> Cc: Joao Pinto
> Cc: David S. Miller
> Cc: Giuseppe Cavallaro
> Cc: Alexandre Torgue
> Cc: Russell King
> Cc: Andrew Lunn
> Cc: Florian Fainelli
> Cc: Heiner Kallweit
> ---
[snip]
On Wed, 24 Apr 2019, Yang Shi wrote:
> The commit 7635d9cbe832 ("mm, thp, proc: report THP eligibility for each
> vma") introduced THPeligible bit for processes' smaps. But, when checking
> the eligibility for shmem vma, __transparent_hugepage_enabled() is
> called to override the result from shme
On Wed 05 Jun 04:42 PDT 2019, Lee Jones wrote:
> When booting MSM based platforms with Device Tree or some ACPI
> implementations, it is possible to provide a list of reserved pins
> via the 'gpio-reserved-ranges' and 'gpios' properties respectively.
> However some ACPI tables are not populated wi
On Fri 07 Jun 16:02 PDT 2019, Linus Walleij wrote:
> On Wed, Jun 5, 2019 at 1:43 PM Lee Jones wrote:
>
> > When booting MSM based platforms with Device Tree or some ACPI
> > implementations, it is possible to provide a list of reserved pins
> > via the 'gpio-reserved-ranges' and 'gpios' properti
> Please try the attached patch. I'm not really pleased with it and I will
> continue to determine why the fallback to a 30-bit mask fails, but at least
> this
> one works for me.
Your patch only makes sense if the device is indeed capable of
addressing 31-bits.
So either the driver is buggy
Hi Ard, Will,
This week we were trying to debug an issue of time consuming in mem_init(),
and leading to this similar solution form Jia He, so I would like to bring this
thread back, please see my detail test result below.
On 2018/9/7 22:44, Will Deacon wrote:
> On Thu, Sep 06, 2018 at 01:24:22PM
This allows finding a device's OPP table (when it has multiple) from a
phandle to the OPP table in DT.
Signed-off-by: Saravana Kannan
---
drivers/opp/of.c | 42 ++
include/linux/pm_opp.h | 7 +++
2 files changed, 41 insertions(+), 8 deletions(-)
Some hardware devices might create multiple children devices to manage
different components of the hardware. In these cases, it might be necessary
for the original hardware device to copy specific OPP tables to a specific
the new child device. Add dev_pm_opp_add_opp_table() to do that.
Signed-off-
Not all devices quantify their performance points in terms of frequency.
Devices like interconnects quantify their performance points in terms of
bandwidth. We need a way to represent these bandwidth levels in OPP. So,
add support for parsing bandwidth OPPs from DT.
Signed-off-by: Saravana Kannan
Add a icc_create_devfreq() and icc_remove_devfreq() to create and remove
devfreq devices for interconnect paths. A driver can create/remove devfreq
devices for the interconnects needed for its device by calling these APIs.
This would allow various devfreq governors to work with interconnect paths
a
Add a function that allows looking up required OPPs given a source OPP
table, destination OPP table and the source OPP.
Signed-off-by: Saravana Kannan
---
drivers/opp/core.c | 50 ++
include/linux/pm_opp.h | 11 ++
2 files changed, 61 insertion
I replied[1] to this patch series[2] and described how I think interconnect
bandwidth voting should be captured in DT and how it should work.
So sending out a patch series implementing that. This patch series does the
following:
- Adds Bandwidth OPP table support (this adds device freq to bandwidt
Interconnects often quantify their performance points in terms of
bandwidth. So, add opp-peak-KBps (required) and opp-avg-KBps (optional) to
allow specifying Bandwidth OPP tables in DT.
opp-peak-KBps is a required property that replace opp-hz for Bandwidth OPP
tables.
opp-avg-KBps is an optional
Interconnect paths can have different performance points. Now that OPP
framework supports bandwidth OPP tables, add OPP table support for
interconnects.
Devices can use the interconnect-opp-table DT property to specify OPP
tables for interconnect paths. And the driver can obtain the OPP table for
The frequency OPP tables have helper functions to search for entries in the
table based on frequency and get the frequency values for a given (or
suspend) OPP entry.
Add similar helper functions for bandwidth OPP tables to search for entries
in the table based on peak bandwidth and to get the peak
Add support for listing bandwidth OPP tables for each interconnect path
listed using the interconnects property.
Signed-off-by: Saravana Kannan
---
.../devicetree/bindings/interconnect/interconnect.txt | 8
1 file changed, 8 insertions(+)
diff --git a/Documentation/devicetree/bindi
Subject/Topic: Targeted Individuals Get Fired from Employment/Jobs
Frequently or All the Time
8th JUNE 2019 Saturday Singapore Time
There are (perhaps) millions of Targeted Individuals in (perhaps)
every country all over the world.
According to accounts and experiences shared by many Targeted
In
Dear friend,
With all due respect, my name is barr. Amboline Hills,personal attorney to late
Engineer J.B. I am contacting you on behalf of my deceased client who is a
national of your country who was assassinated in 2013 with his wife and their
only child.Since the funds was left in open bene
On 2019-06-07 8:08 a.m., Juergen Gross wrote:
On 09.05.19 19:25, Ankur Arora wrote:
HYPERVISOR_shared_info is used for irq/evtchn communication between the
guest and the host. Abstract out the setup/reset in xenhost_t such that
nested configurations can use both xenhosts simultaneously.
I have
Specify the UFS device-reset gpio, so that the controller will issue a
reset of the UFS device.
Reviewed-by: Linus Walleij
Signed-off-by: Bjorn Andersson
---
Changes since v2:
- None
arch/arm64/boot/dts/qcom/sdm845-mtp.dts | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/boot/
This series adds a new ufs vops to allow platform specific methods for
resetting an attached UFS device, then implements this for the Qualcomm driver.
Bjorn Andersson (3):
scsi: ufs: Introduce vops for resetting device
scsi: ufs-qcom: Implement device_reset vops
arm64: dts: qcom: sdm845-mtp:
Some UFS memory devices needs their reset line toggled in order to get
them into a good state for initialization. Provide a new vops to allow
the platform driver to implement this operation.
Signed-off-by: Bjorn Andersson
---
Changes since v2:
- New patch, to allow moving implementation to platf
The UFS_RESET pin on Qualcomm SoCs are controlled by TLMM and exposed
through the GPIO framework. Acquire the device-reset GPIO and use this
to implement the device_reset vops, to allow resetting the attached
memory.
Based on downstream support implemented by Subhash Jadavani
.
Signed-off-by: Bjo
Andreas Christoforou reported:
UBSAN: Undefined behaviour in ipc/mqueue.c:414:49 signed integer overflow:
9 * 2305843009213693951 cannot be represented in type 'long int'
...
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x11b/0x1fe lib/dump_stack.c:113
ubsan_epilogue+0xe/0x8
On 2019-06-07 7:51 a.m., Juergen Gross wrote:
On 09.05.19 19:25, Ankur Arora wrote:
Hi all,
This is an RFC for xenhost support, outlined here by Juergen here:
https://lkml.org/lkml/2019/4/8/67.
First: thanks for all the effort you've put into this series!
The high level idea is to provide a
On Fri 07 Jun 21:43 PDT 2019, Saravana Kannan wrote:
> I replied[1] to this patch series[2] and described how I think interconnect
> bandwidth voting should be captured in DT and how it should work.
>
> So sending out a patch series implementing that. This patch series does the
> following:
> - A
On 2019-06-07 9:21 a.m., Juergen Gross wrote:
On 07.06.19 17:22, Joao Martins wrote:
On 6/7/19 3:51 PM, Juergen Gross wrote:
On 09.05.19 19:25, Ankur Arora wrote:
Hi all,
This is an RFC for xenhost support, outlined here by Juergen here:
https://lkml.org/lkml/2019/4/8/67.
First: thanks for
Two bug fixes, both for fairly serious problems; the UFS one looks like
it could be used to exfiltrate data from the kernel, although probably
only a privileged user has access to the command management interface
and the missing unlock in smartpqi is long standing and probably a
little used error p
Hi Liviu,
Commits
74332e53e41d ("drm/komeda: Add image enhancement support")
108ddcf9238f ("drm/komeda: Add engine clock requirement check for the
downscaling")
e980ebbe5cee ("drm/komeda: Add writeback scaling support")
37bd61525f3a ("drm/komeda: Implement D71 scaler support")
50be7701
On Thu, 30 May 2019 18:29:20 +0900
Masami Hiramatsu wrote:
> > OK, so this series isn't enough to allow kretprobes to use it yet. OK,
> > I plan on still keeping it because it does allow for placing function
> > graph tracer into instances with their own filters.
>
> OK, that will be a "regs"
Hi Linus,
Here's a batch of MIPS fixes for 5.2, nothing particularly scary; please
pull.
Thanks,
Paul
The following changes since commit a188339ca5a396acc588e5851ed7e19f66b0ebd9:
Linux 5.2-rc1 (2019-05-19 15:47:09 -0700)
are available in the Git repository at:
git://git.kernel.org/pu
901 - 969 of 969 matches
Mail list logo
