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
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:
> -
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
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
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:
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:
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
> 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
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'
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
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
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
> ---
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
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
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
>
>
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).
> ---
>
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.
> ---
>
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
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
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
>
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
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
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
>> ---
>>
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
>> ---
>>
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 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
--
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
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.
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
--
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
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
>
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:
> > > >
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
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
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
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
> >
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
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 =
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
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,
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
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.
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
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
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
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
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
Beelink GS1, OrangePi H6 boards and Pine H64 have an IR receiver.
Enable it in their device-tree.
Signed-off-by: Clément Péron
---
arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts | 4
arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi.dtsi | 4
We are using RXINT bits definition when looking at RXSTA register.
These bits are equal but it's not really proper.
Introduce the RXSTA bits and use them to have coherency.
Signed-off-by: Clément Péron
---
drivers/media/rc/sunxi-cir.c | 18 --
1 file changed, 12 insertions(+),
From: Jernej Skrabec
OrangePi Win board contains IR receiver. Enable it.
Signed-off-by: Jernej Skrabec
Signed-off-by: Clément Péron
Acked-by: Sean Young
---
arch/arm64/boot/dts/allwinner/sun50i-a64-orangepi-win.dts | 4
1 file changed, 4 insertions(+)
diff --git
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,
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
Allwinner A31 has introduced a new memory mapping and a
reset line.
The difference in memory mapping are :
- In the configure register there is a new sample bit
and Allwinner has introduced the active threshold feature.
- In the status register a new STAT bit is present.
Note: CGPO and
This driver is used in various Allwinner SoC with different configuration.
Introduce a quirks struct to know the fifo size and if a reset is required.
Signed-off-by: Clément Péron
Acked-by: Sean Young
Acked-by: Maxime Ripard
---
drivers/media/rc/sunxi-cir.c | 61
There are some minor differences between A31 and A64 driver.
But A31 IR driver is compatible with A64.
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
On Wed, Jun 5, 2019 at 7:16 PM Sricharan R wrote:
> The IPQ6018 is Qualcomm’s 802.11ax SoC for Routers,
> Gateways and Access Points.
>
> This series adds minimal board boot support for ipq6018-cp01
> board.
>
> Sricharan R (6):
> pinctrl: qcom: Add ipq6018 pinctrl driver
> dt-bindings:
On Fri, Jun 07, 2019 at 07:20:46PM +, Nick Terrell wrote:
> We'd love to get this mainlined as well!
>
> We're using these patches internally as well. We're seeing an improvement on
> an
> Intel Atom N3710, where boot time is reduced by one second over using an xz
> compressed kernel. It
On 6/7/19 5:19 PM, Alex Levin wrote:
When calling kmalloc with GFP_KERNEL in case CONFIG_SLOB is unset,
kmem_cache_alloc_trace is called.
In case CONFIG_TRACING is set, kmem_cache_alloc_trace will ball
slab_alloc, which will call slab_pre_alloc_hook which might_sleep_if.
The context in
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' properties respectively.
> However some ACPI tables are not populated
Neil Armstrong writes:
> This patchset :
> - adds the SDIO controller node using the dram-access-quirk
> - adds SDCard, eMMC & SDIO support to X96
> - Add SDIO support to SEI510
Queued for v5.3,
Thanks,
Kevin
Neil Armstrong writes:
> Locking is not needed for the phy_g12a_usb3_pcie_cr_bus_read/write() and
> currently it causes the following BUG because of the usage of the
> regmap_read_poll_timeout() running in spinlock_irq, configured by regmap
> fast_io.
>
> Simply disable locking in the cr_regmap
Neil Armstrong writes:
> Since locking is handled by regmap, the spin_lock_irqsave() in the
> meson_ao_cec_g12a_read/write() regmap callbacks is not needed.
>
> Fixes: b7778c46683c ("media: platform: meson: Add Amlogic Meson G12A AO CEC
> Controller driver")
> Signed-off-by: Neil Armstrong
Acked-By: Mike Isely
On Wed, 5 Jun 2019, Kefeng Wang wrote:
> The class_ptr will be NULL if pvr2_sysfs_class_create() fails
> in pvr_init(), when call pvr2_sysfs_class_destroy(), it will
> lead to null-ptr-deref, fix it.
>
> Reported-by: Hulk Robot
> Signed-off-by: Kefeng Wang
> ---
>
Commit 8973112aa41b ("ASoC: fsl_esai: ETDR and TX0~5 registers are
non volatile") removed TX data registers from the volatile_reg list
and appended default values for them. However, being data registers
of TX, they should not have been removed from the list because they
should not be cached -- see
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 changes through ARM SoC.
Yours,
Linus
Normally when the MMC core sees an "-EILSEQ" error returned by a host
controller then it will trigger a retuning of the card. This is
generally a good idea.
However, if a command is expected to sometimes cause transfer errors
then these transfer errors shouldn't cause a re-tuning. This
On Thu, Jun 6, 2019 at 9:49 AM Bartosz Golaszewski wrote:
> śr., 5 cze 2019 o 17:12 Keerthy napisał(a):
> > >> static const struct of_device_id davinci_gpio_ids[] = {
> > >> { .compatible = "ti,keystone-gpio", keystone_gpio_get_irq_chip},
> > >> + { .compatible =
There are certain cases, notably when transitioning between sleep and
active state, when Broadcom SDIO WiFi cards will produce errors on the
SDIO bus. This is evident from the source code where you can see that
we try commands in a loop until we either get success or we've tried
too many times.
This reverts commit 29f6589140a10ece8c1d73f58043ea5b3473ab3e.
After that patch landed I find that my kernel log on
rk3288-veyron-minnie and rk3288-veyron-speedy is filled with:
brcmfmac: brcmf_sdio_bus_sleep: error while changing bus sleep state -110
This seems to happen every time the Broadcom
This series attempts to deal better with the expected transmission
errors related to the idle states (handled by the Always-On-Subsystem
or AOS) on the SDIO-based WiFi on rk3288-veyron-minnie,
rk3288-veyron-speedy, and rk3288-veyron-mickey.
Some details about those errors can be found in
We want SDIO drivers to be able to temporarily stop retuning when the
driver knows that the SDIO card is not in a state where retuning will
work (maybe because the card is asleep). We'll move the relevant
functions to a place where drivers can call them.
NOTE: We'll leave the calls with a mmc_
When Broadcom SDIO cards are idled they go to sleep and a whole
separate subsystem takes over their SDIO communication. This is the
Always-On-Subsystem (AOS) and it can't handle tuning requests.
Specifically, as tested on rk3288-veyron-minnie (which reports having
BCM4354/1 in dmesg), if I force
On Wed, Jun 5, 2019 at 10:02 AM Keerthy wrote:
> Add K3 dependencies to enable the driver on K3 platforms.
>
> Signed-off-by: Keerthy
Patch applied.
Yours,
Linus Walleij
On Wed, Jun 5, 2019 at 10:02 AM Keerthy wrote:
> Add new compatible for K3 AM654 SoCs.
>
> Signed-off-by: Keerthy
Patch applied.
Yours,
Linus Walleij
On Wed, Jun 5, 2019 at 10:02 AM Keerthy wrote:
> Fix the compiler warning with ARM64 config enabled
> as the current mask assumes 32 bit by default.
>
> Signed-off-by: Keerthy
Patch applied, I think this and patch 2/3 work fine
together as-is.
Yours,
Linus Walleij
On Mon, May 27, 2019 at 09:45:45PM +0200, Wolfram Sang wrote:
> A mail just bounced back with "user unknown":
>
> 550 5.1.1 User doesn't exist
>
> I also couldn't find a more recent address in git history. So, remove
> this stale entry.
>
> Signed-off-by: Wolfram Sang
Applied to for-current,
On Tue, May 28, 2019 at 09:08:21AM +, Adamski, Krzysztof (Nokia -
PL/Wroclaw) wrote:
> The operation done in the pmbus_update_fan() function is a
> read-modify-write operation but it lacks any kind of lock protection
> which may cause problems if run more than once simultaneously. This
>
On Fri, Jun 7, 2019 at 5:05 PM Geert Uytterhoeven
wrote:
>
> Signed-off-by: Geert Uytterhoeven
Subject line should be s/informaion/information. With that fix,
Acked-by: Souptick Joarder
> ---
> mm/vmalloc.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git
Neil Armstrong writes:
> The SEI510 embeds an AP6398S SDIO module, let's add the
> corresponding SDIO, PWM clock and mmc-pwrseq nodes.
>
> Acked-by: Martin Blumenstingl
> Signed-off-by: Neil Armstrong
Queued for v5.3,
Thanks,
Kevin
Neil Armstrong writes:
> Setting to 2Mbaud/s is the nominal bus speed for common usages.
>
> Signed-off-by: Neil Armstrong
> Acked-by: Martin Blumenstingl
Queued for v5.3,
Thanks,
Kevin
Neil Armstrong writes:
> These patches :
> - adds the 32khz low power clock to the bluetooth node, since this
> clock is needed for the bluetooth part of the module to initialize
> - bumps the bus speed to 2Mbaud/s
Queued for v5.3,
Thanks,
Kevin
> On Jun 7, 2019, at 2:09 PM, Dave Hansen wrote:
>
> On 6/7/19 1:06 PM, Yu-cheng Yu wrote:
>>> Huh, how does glibc know about all possible past and future legacy code
>>> in the application?
>> When dlopen() gets a legacy binary and the policy allows that, it will manage
>> the bitmap:
>>
>>
On Fri, Jun 7, 2019 at 3:19 PM Alex Levin wrote:
>
> When calling kmalloc with GFP_KERNEL in case CONFIG_SLOB is unset,
> kmem_cache_alloc_trace is called.
>
> In case CONFIG_TRACING is set, kmem_cache_alloc_trace will ball
nit: *call
> slab_alloc, which will call slab_pre_alloc_hook which
On Tue, Jun 4, 2019 at 11:42 PM Hongwei Zhang wrote:
> Add SGPM pinmux to ast2500-pinctrl function and group, to prepare for
> supporting SGPIO in AST2500 SoC.
>
> Signed-off-by: Hongwei Zhang
Acked-by: Linus Walleij
Please funnel this part of the patch through the ARM SoC
tree. I guess Joel
1 - 100 of 1000 matches
Mail list logo
