This prepares pstore for converting the VFS layer to timespec64.
Cc: Deepa Dinamani
Signed-off-by: Kees Cook
---
fs/pstore/inode.c | 3 ++-
fs/pstore/platform.c | 2 +-
include/linux/pstore.h | 2 +-
3 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/fs/pstore/inode.c b/fs/ps
On Fri, May 11, 2018 at 9:59 PM, Deepa Dinamani wrote:
> diff --git a/fs/pstore/inode.c b/fs/pstore/inode.c
> index 5fcb845b9fec..fb681d302bb3 100644
> --- a/fs/pstore/inode.c
> +++ b/fs/pstore/inode.c
> @@ -392,7 +392,7 @@ int pstore_mkfile(struct dentry *root, struct
> pstore_record *record)
>
Commit-ID: 789ba28013ce23dbf5e9f5f014f4233b35523bf3
Gitweb: https://git.kernel.org/tip/789ba28013ce23dbf5e9f5f014f4233b35523bf3
Author: Mel Gorman
AuthorDate: Wed, 9 May 2018 17:31:15 +0100
Committer: Ingo Molnar
CommitDate: Sat, 12 May 2018 08:37:56 +0200
Revert "sched/numa: Delay ret
Use new return type vm_fault_t for fault handler
in struct vm_operations_struct. For now, this is
just documenting that the function returns a
VM_FAULT value rather than an errno. Once all
instances are converted, vm_fault_t will become
a distinct type.
commit 1c8f422059ae ("mm: change return typ
According to error handling path before and after this one, we should go
to 'out_md_fid' here, instead of 'out_md', if 'obd_connect()' fails.
Signed-off-by: Christophe JAILLET
---
The last goto 'out_lock_cn_cb' looks spurious but is correct.
In case of error, 'd_make_root()' performs a 'iput()',
On Fri, May 11, 2018 at 10:08:24PM -0700, Paul E. McKenney wrote:
> On Fri, May 11, 2018 at 03:41:38PM -0700, Joel Fernandes wrote:
> > On Fri, May 11, 2018 at 09:17:46AM -0700, Paul E. McKenney wrote:
> > > On Fri, May 11, 2018 at 09:57:54PM +0900, Byungchul Park wrote:
> > > > Hello folks,
> > >
On Sat, May 12, 2018 at 11:55 AM, Souptick Joarder wrote:
> On Sat, May 12, 2018 at 11:50 AM, Joe Perches wrote:
>> On Sat, 2018-05-12 at 11:47 +0530, Souptick Joarder wrote:
>>> Use new return type vm_fault_t for fault handler
>>> in struct vm_operations_struct. For now, this is
>>> just documen
On Sat, May 12, 2018 at 11:50 AM, Joe Perches wrote:
> On Sat, 2018-05-12 at 11:47 +0530, Souptick Joarder wrote:
>> Use new return type vm_fault_t for fault handler
>> in struct vm_operations_struct. For now, this is
>> just documenting that the function returns a
>> VM_FAULT value rather than an
On Sat, 2018-05-12 at 11:47 +0530, Souptick Joarder wrote:
> Use new return type vm_fault_t for fault handler
> in struct vm_operations_struct. For now, this is
> just documenting that the function returns a
> VM_FAULT value rather than an errno. Once all
> instances are converted, vm_fault_t will
Use new return type vm_fault_t for fault handler
in struct vm_operations_struct. For now, this is
just documenting that the function returns a
VM_FAULT value rather than an errno. Once all
instances are converted, vm_fault_t will become
a distinct type.
commit 1c8f422059ae ("mm: change return typ
On Sun, Apr 22, 2018 at 08:03:39PM -0700, Paul E. McKenney wrote:
> The rcu_start_this_gp() function had a simple form of funnel locking that
> used only the leaves and root of the rcu_node tree, which is fine for
> systems with only a few hundred CPUs, but sub-optimal for systems having
> thousand
Hi Paul,
On Fri, 11 May 2018 23:29:12 +0200
Paul Cercueil wrote:
> By specifying the properties "mtd-oob-ecc" and "mtd-oob-free", it is
> now possible to specify from devicetree where the ECC data is located
> inside the OOB region.
Why would we want to do that? I mean, ECC/free regions are ECC
On Fri, 2018-05-11 at 17:03 +0200, Matthias Brugger wrote:
>
> On 04/11/2018 10:53 AM, sean.w...@mediatek.com wrote:
> > From: Sean Wang
> >
> > Below two wrong nodes in existing DTS files would cause a fail boot since
> > in fact the address 0 is not the correct place the memory device locates
On Fri, May 11, 2018 at 03:41:38PM -0700, Joel Fernandes wrote:
> On Fri, May 11, 2018 at 09:17:46AM -0700, Paul E. McKenney wrote:
> > On Fri, May 11, 2018 at 09:57:54PM +0900, Byungchul Park wrote:
> > > Hello folks,
> > >
> > > I think I wrote the title in a misleading way.
> > >
> > > Please
Subsequent patches in the series convert inode timestamps
to use struct timespec64 instead of struct timespec as
part of solving the y2038 problem.
Convert these print formats to use long long types to
avoid warnings and errors on conversion.
Signed-off-by: Deepa Dinamani
CC: andreas.dil...@inte
Subsequent patches in the series convert inode timestamps
to use struct timespec64 instead of struct timespec as
part of solving the y2038 problem.
commit fd3cfad374d4 ("udf: Convert udf_disk_stamp_to_time() to use mktime64()")
eliminated the NULL return condition from udf_disk_stamp_to_time().
ud
struct timespec is not y2038 safe. Transition vfs to use
y2038 safe struct timespec64 instead.
The change was made with the help of the following cocinelle
script. This catches about 80% of the changes.
All the header file and logic changes are included in the
first 5 rules. The rest are trivial s
Subsequent patches in the series convert inode timestamps
to use struct timespec64 instead of struct timespec as
part of solving the y2038 problem.
Convert these print formats to use long long types to
avoid warnings and errors on conversion.
Signed-off-by: Deepa Dinamani
Cc: z...@redhat.com
Cc:
As vfs moves to using struct timespec64 to represent times,
update the argument to timespec_truncate() to use
struct timespec64. Also change the name of the function.
The rest of the implementation logic is the same.
Move this to fs/inode.c instead of kernel/time/time.c as all the
users of this ap
Subsequent patches in the series convert inode timestamps
to use struct timespec64 instead of struct timespec as
part of solving the y2038 problem.
This will lead to type mismatch for memcpys.
Use regular assignments instead.
Signed-off-by: Deepa Dinamani
Cc: trond.mykleb...@primarydata.com
---
The series aims to switch vfs timestamps to use
struct timespec64. Currently vfs uses struct timespec,
which is not y2038 safe.
The series involves the following:
1. Add vfs helper functions for supporting struct timepec64 timestamps.
2. Cast prints of vfs timestamps to avoid warnings after the sw
Hi all,
On Wed, 9 May 2018 20:47:27 +1000 Stephen Rothwell
wrote:
>
> On Wed, 9 May 2018 18:03:46 +0900 Mark Brown wrote:
> >
> > On Wed, May 09, 2018 at 10:47:57AM +0200, Daniel Vetter wrote:
> > > On Wed, May 9, 2018 at 10:44 AM, Mark Brown wrote:
> > >
> >
> > > > I think this is
Hi all,
As an outcome of some discussion, I have added a pending-fixes branch
to linux-next. This branch contains Linus' tree merged with branches
containing only fixes pending for the current release. The branch is a
strict subset of linux-next each day (as so rebases like linux-next
does).
It
On Sat, May 12, 2018 at 09:42:21AM +0900, Masami Hiramatsu wrote:
> Hi Greg,
>
> Could you pick this series to stable?
This is not the correct way to submit patches for inclusion in the
stable kernel tree. Please read:
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
Hi Al,
As requested I have added the vfs-fixes tree
(git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git#fixes) to
linux-next from Monday.
Thanks for adding your subsystem tree as a participant of linux-next. As
you may know, this is not a judgement of your code. The purpose of
linux-nex
Hi David,
On Fri, 11 May 2018 10:47:01 +0200 David Sterba wrote:
>
> Please add
>
> git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux.git next-fixes
Added from Monday (as btrfs-fixes).
Thanks for adding your subsystem tree as a participant of linux-next. As
you may know, this is not
Hi all,
Just cc'ing the wireless list at Kalle's suggestion.
On Wed, 9 May 2018 14:56:24 +1000 Stephen Rothwell
wrote:
>
> Hi Johannes,
>
> After merging the mac80211-next tree, today's linux-next build (arm_multi
> v7_defconfig) produced this warning:
>
> drivers/net/wireless/marvell/mwifiex
Hi Kalle,
On Fri, 11 May 2018 15:20:23 +0300 Kalle Valo wrote:
>
> Btw Stephen for mac80211 reports it would be a good idea to also cc
> linux-wireless list, in case Johannes is not around etc.
Thanks for the suggestion. Done.
--
Cheers,
Stephen Rothwell
pgpWmdiByugpz.pgp
Description: OpenP
-- Forwarded message --
From: Kyungtae Kim
Date: Fri, May 11, 2018 at 11:38 AM
Subject: KASAN: use-after-free Write in write_mem
To: a...@arndb.de, gre...@linuxfoundation.org, linux-kernel@vger.kernel.org
Cc: Byoungyoung Lee , DaeLyong Jeong
We report the crash:
"KASAN: use-afte
Hi,
I bet this has come up before, but my search foo didn't find anything.
When (cross) building nios2 allmodconfig, I am seeing this build error:
ERROR: "empty_zero_page" [net/ceph/libceph.ko] undefined!
ERROR: "empty_zero_page" [fs/exofs/exofs.ko] undefined!
ERROR: "empty_zero_page" [fs/crypto
On Fri, May 11, 2018 at 06:29:57PM -0700, Joel Fernandes wrote:
> On Fri, May 11, 2018 at 6:29 PM, Joel Fernandes (Google)
> wrote:
> >
> > As part of the gp_seq clean up, the Startleaf condition doesn't occur
> > anymore. Remove it from the comment in the trace event file.
>
> Sorry, I meant her
On 05/11/2018 07:20 PM, Joel Fernandes (Google) wrote:
> rcu_seq_snap may be tricky for someone looking at it for the first time.
> Lets document how it works with an example to make it easier.
>
> Signed-off-by: Joel Fernandes (Google)
> ---
> v2 changes: Corrections as suggested by Randy.
>
>
On Sat, May 12, 2018 at 12:57 AM, Bjorn Helgaas wrote:
> Andrew wrote:
>> A friend of mine has a brand new LG laptop that has intermittent NVMe
>> failures. They mostly happen during a suspend/resume cycle
>> (apparently during suspend, not resume). Unlike the earlier
>> Dell/Samsung issue, the
This patch series adds a driver and device tree binding documentation for
PMIC regulator control via Resource Power Manager-hardened (RPMh) on some
Qualcomm Technologies, Inc. SoCs such as SDM845. RPMh is a hardware block
which contains several accelerators which are used to manage various
hardwar
Add the QCOM RPMh regulator driver to manage PMIC regulators
which are controlled via RPMh on some Qualcomm Technologies, Inc.
SoCs. RPMh is a hardware block which contains several
accelerators which are used to manage various hardware resources
that are shared between the processors of the SoC.
Introduce bindings for RPMh regulator devices found on some
Qualcomm Technlogies, Inc. SoCs. These devices allow a given
processor within the SoC to make PMIC regulator requests which
are aggregated within the RPMh hardware block along with requests
from other processors in the SoC to determine th
rcu_seq_snap may be tricky for someone looking at it for the first time.
Lets document how it works with an example to make it easier.
Signed-off-by: Joel Fernandes (Google)
---
v2 changes: Corrections as suggested by Randy.
kernel/rcu/rcu.h | 24 +++-
1 file changed, 23 ins
On 05/11/2018 05:33 PM, Joel Fernandes (Google) wrote:
> rcu_seq_snap may be tricky for someone looking at it for the first time.
> Lets document how it works with an example to make it easier.
>
> Signed-off-by: Joel Fernandes (Google)
> ---
> kernel/rcu/rcu.h | 23 ++-
> 1
Add a common device tree property for regulator nodes to support
the specification of allowed operating modes.
Signed-off-by: David Collins
---
Documentation/devicetree/bindings/regulator/regulator.txt | 5 +
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/reg
Add support for configuring the machine constraints
valid_modes_mask element based on a list of allowed modes
specified via a device tree property.
Signed-off-by: David Collins
---
drivers/regulator/of_regulator.c | 29 -
1 file changed, 28 insertions(+), 1 deletion(-
There is currently no accepted way to configure constraints->valid_modes_mask
for regulators defined in device tree. This patch series defines a new
common regulator device tree property, regulator-allowed-modes, which can be
used to specify the set of modes that the regulator is allowed to use.
I
On Fri, May 11, 2018 at 6:29 PM, Joel Fernandes (Google)
wrote:
>
> As part of the gp_seq clean up, the Startleaf condition doesn't occur
> anymore. Remove it from the comment in the trace event file.
Sorry, I meant here Startedleaf. Let me know if you want me to resend the patch.
thanks,
- Joe
As part of the gp_seq clean up, the Startleaf condition doesn't occur
anymore. Remove it from the comment in the trace event file.
Signed-off-by: Joel Fernandes (Google)
---
include/trace/events/rcu.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/trace/events/rcu.h b/include/trace/e
This patch attempts to remove the mcryptd interface and expose the
sha1 multibuffer algorithm as a proper ahash to the inner algorithm.
1. Host the flusher helper in sha1_mb.c instead of mcryptd.c (need to
change the names of these functions)
2. Remove unnecessary mcryptd structure mcryptd_hash_ct
>-Original Message-
>From: Herbert Xu [mailto:herb...@gondor.apana.org.au]
>Sent: Thursday, May 10, 2018 9:46 PM
>To: Dey, Megha
>Cc: linux-kernel@vger.kernel.org; linux-cry...@vger.kernel.org;
>da...@davemloft.net
>Subject: Re: [PATCH V8 1/5] crypto: Multi-buffer encryption infrastructu
On Fri, May 11, 2018 at 10:59:53AM +0200, Dmitry Vyukov wrote:
> On Thu, May 10, 2018 at 1:22 AM, Dave Chinner wrote:
> > On Wed, May 09, 2018 at 10:43:05AM +0200, Dmitry Vyukov wrote:
> >> Does "xfstests fuzzing infrastructure" use coverage-guidance?
> >
> > It's guided manually to fuzz a substan
2018-05-11 23:40 GMT+08:00 Konrad Rzeszutek Wilk :
> On Mon, Apr 16, 2018 at 10:45:59PM -0700, Wanpeng Li wrote:
>> Tim Shearer reported that "There is a guest which is running a packet
>> forwarding app based on the DPDK (dpdk.org). The packet receive routine
>> writes to 0xc070 using glibc's "out
On 2018/5/12 0:58, Santosh Shilimkar wrote:
On 5/11/2018 12:48 AM, Yanjun Zhu wrote:
On 2018/5/11 13:20, DaeRyong Jeong wrote:
We report the crash: KASAN: null-ptr-deref Read in rds_ib_get_mr
Note that this bug is previously reported by syzkaller.
https://syzkaller.appspot.com/bug?id=0bb56
Hi Greg,
Could you pick this series to stable?
Thank you,
On Tue, 8 May 2018 12:25:03 +0100
Russell King - ARM Linux wrote:
> On Fri, May 04, 2018 at 01:14:31PM +0900, Masami Hiramatsu wrote:
> > Hi,
> >
> > This is the 3rd version of bugfix series for kprobes on arm.
> > This series fixes 4
rcu_seq_snap may be tricky for someone looking at it for the first time.
Lets document how it works with an example to make it easier.
Signed-off-by: Joel Fernandes (Google)
---
kernel/rcu/rcu.h | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/kernel/rc
On Fri, May 11, 2018 at 5:10 PM David Miller wrote:
> I guess this is my reward for trying to break the monotony of
> pull requests :-)
I actually went back and checked a few older pull requests to see if this
had been going on for a while and I just hadn't noticed.
It just took me by surprise
From: Linus Torvalds
Date: Fri, 11 May 2018 14:25:59 -0700
> David, is there something you want to tell us?
>
> Drugs are bad, m'kay..
I guess this is my reward for trying to break the monotony of
pull requests :-)
From: Florian Fainelli
Date: Fri, 11 May 2018 16:38:02 -0700
> David, please discard that for now, the IPv4 part is correct, but I am
> not fixing the bug correctly for the IPv6 part. v2 coming some time next
> week. Thank you!
Ok.
The original intent in cacheinfo was that an architecture
specific populate_cache_leaves() would probe the hardware
and then cache_shared_cpu_map_setup() and
cache_override_properties() would provide firmware help to
extend/expand upon what was probed. Arm64 was really
the only architecture that wa
Its helpful to be able to lookup the acpi_processor_id associated
with a logical cpu. Provide an arm64 helper to do this.
Signed-off-by: Jeremy Linton
Tested-by: Ard Biesheuvel
Tested-by: Vijaya Kumar K
Tested-by: Xiongfeng Wang
Tested-by: Tomasz Nowicki
Acked-by: Ard Biesheuvel
---
arch/ar
In preparation for the next patch, and to aid in
review of that patch, lets move cache_setup_of_node
further down in the module without any changes.
Signed-off-by: Jeremy Linton
Tested-by: Ard Biesheuvel
Tested-by: Vijaya Kumar K
Tested-by: Xiongfeng Wang
Tested-by: Tomasz Nowicki
Reviewed-by
ACPI 6.2 adds a new table, which describes how processing units
are related to each other in tree like fashion. Caches are
also sprinkled throughout the tree and describe the properties
of the caches in relation to other caches and processing units.
Add the code to parse the cache hierarchy and re
Call ACPI cache parsing routines from base cacheinfo code if ACPI
is enabled. Also stub out cache_setup_acpi and acpi_find_last_cache_level
so that individual architectures can enable ACPI topology parsing.
Signed-off-by: Jeremy Linton
Tested-by: Ard Biesheuvel
Tested-by: Vijaya Kumar K
Tested-
The cluster concept isn't architecturally defined for arm64.
Lets match the name of the arm64 topology field to the kernel macro
that uses it.
Signed-off-by: Jeremy Linton
Tested-by: Ard Biesheuvel
Tested-by: Vijaya Kumar K
Tested-by: Xiongfeng Wang
Tested-by: Tomasz Nowicki
Acked-by: Sudeep
The /sys cache entries should support ACPI/PPTT generated cache
topology information. For arm64, if ACPI is enabled, determine
the max number of cache levels and populate them using the PPTT
table if one is available.
Signed-off-by: Jeremy Linton
Tested-by: Ard Biesheuvel
Tested-by: Vijaya Kuma
Propagate the topology information from the PPTT tree to the
cpu_topology array. We can get the thread id and core_id by assuming
certain levels of the PPTT tree correspond to those concepts.
The package_id is flagged in the tree and can be found by calling
find_acpi_cpu_topology_package() which te
Add ACPI_SIG_PPTT to the table so initrd's can override the
system topology.
Signed-off-by: Geoffrey Blake
Signed-off-by: Jeremy Linton
Tested-by: Ard Biesheuvel
Tested-by: Vijaya Kumar K
Tested-by: Xiongfeng Wang
Tested-by: Tomasz Nowicki
Acked-by: Ard Biesheuvel
---
drivers/acpi/tables.c
Now that we have a PPTT parser, in preparation for its use
on arm64, lets build it.
Signed-off-by: Jeremy Linton
Tested-by: Ard Biesheuvel
Tested-by: Vijaya Kumar K
Tested-by: Xiongfeng Wang
Tested-by: Tomasz Nowicki
Reviewed-by: Sudeep Holla
Acked-by: Ard Biesheuvel
---
arch/arm64/Kconfig
ACPI 6.2 adds the Processor Properties Topology Table (PPTT), which is
used to describe the processor and cache topology. Ideally it is
used to extend/override information provided by the hardware, but
right now ARM64 is entirely dependent on firmware provided tables.
This patch parses the table f
Now that we have an accurate view of the physical topology
we need to represent it correctly to the scheduler. Generally MC
should equal the LLC in the system, but there are a number of
special cases that need to be dealt with.
In the case of NUMA in socket, we need to assure that the sched
domain
Rename and change the type of of_node to indicate
it is a generic pointer which is generally only used
for comparison purposes. In a later patch we will put
an ACPI/PPTT token pointer in fw_token so that
the code which builds the shared cpu masks can be reused.
Signed-off-by: Jeremy Linton
Tested
On 05/11/2018 04:24 PM, Florian Fainelli wrote:
> When we let the kernel pick up a rule location with RX_CLS_LOC_ANY, we
> would be able to overwrite the last rules because of a number of issues:
>
> - the IPv4 code path would not be checking that rule_index is within
> bounds, the IPv6 code pat
--
Hello
Greetings to you please i have a business proposal for you contact me
for more detailes asap thanks.
Best Regards,
Miss.Zeliha ömer faruk
Esentepe Mahallesi Büyükdere
Caddesi Kristal Kule Binasi
No:215
Sisli - Istanbul, Turkey
On Fri, May 11, 2018 at 10:48:00AM -0300, Arnaldo Carvalho de Melo wrote:
> Em Thu, May 10, 2018 at 12:01:59PM +0800, Leo Yan escreveu:
> > CoreSight doesn't allocate thread structure for unknown_thread in etm
> > auxtrace, so unknown_thread is NULL pointer. If the perf data doesn't
> > contain va
When we let the kernel pick up a rule location with RX_CLS_LOC_ANY, we
would be able to overwrite the last rules because of a number of issues:
- the IPv4 code path would not be checking that rule_index is within
bounds, the IPv6 code path would only be checking the second index and
not the fi
The mm-of-the-moment snapshot 2018-05-11-16-28 has been uploaded to
http://www.ozlabs.org/~akpm/mmotm/
mmotm-readme.txt says
README for mm-of-the-moment:
http://www.ozlabs.org/~akpm/mmotm/
This is a snapshot of my -mm patch queue. Uploaded at random hopefully
more than once a week.
You wi
Wed, May 09, 2018 at 05:33:13PM -0700, Dmitry Torokhov wrote:
> Hi NIck,
>
> On Wed, May 09, 2018 at 05:07:14PM +0300, Nick Simonov wrote:
> > This is a patch to the input.c file that fixes
> > up warning found by checkpatch.pl tool
> >
> > Signed-off-by: Nick Simonov
> > ---
> > drivers/input
On 5/11/2018 4:24 PM, Stephen Bates wrote:
All
Alex (or anyone else) can you point to where IOVA addresses are generated?
A case of RTFM perhaps (though a pointer to the code would still be
appreciated).
https://www.kernel.org/doc/Documentation/Intel-IOMMU.txt
Some exceptions to IOVA
--
On Fri, May 11, 2018 at 09:17:46AM -0700, Paul E. McKenney wrote:
> On Fri, May 11, 2018 at 09:57:54PM +0900, Byungchul Park wrote:
> > Hello folks,
> >
> > I think I wrote the title in a misleading way.
> >
> > Please change the title to something else such as,
> > "rcu: Report a quiescent state
Quoting Girish Mahadevan (2018-05-03 14:34:43)
> diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
> index 9b31351..358d60a 100644
> --- a/drivers/spi/Kconfig
> +++ b/drivers/spi/Kconfig
> @@ -564,6 +564,18 @@ config SPI_QUP
> This driver can also be built as a module. If so, the mo
All
> Alex (or anyone else) can you point to where IOVA addresses are generated?
A case of RTFM perhaps (though a pointer to the code would still be
appreciated).
https://www.kernel.org/doc/Documentation/Intel-IOMMU.txt
Some exceptions to IOVA
---
Interrupt ranges are not a
On 2018-05-10 17:21, Richard Guy Briggs wrote:
> On 2018-05-09 11:13, Paul Moore wrote:
> > On Fri, May 4, 2018 at 4:54 PM, Richard Guy Briggs wrote:
> > > Recognizing that the loginuid is an internal audit value, use an access
> > > function to retrieve the audit loginuid value for the task rathe
checkpatch.pl shows a warning for these unnecessary curly braces.
so just removed those curly braces.
Signed-off-by: Vaibhav Murkute
---
drivers/bluetooth/hci_serdev.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/bluetooth/hci_serdev.c b/drivers/bluetooth/hci_s
Hi Elaine,
Am Freitag, 11. Mai 2018, 05:34:32 CEST schrieb Elaine Zhang:
> According to a description from TRM, add all the power domains.
>
> Signed-off-by: Elaine Zhang
> Signed-off-by: Finley Xiao
that's a bit ambigous, having the Signed-offs like above.
Either you are the author+sender o
On Fri, May 11, 2018 at 06:32:33PM +1000, Dave Chinner wrote:
> Hi Kent,
>
> I haven't really had time to digest this in any real detail,
> but I've noticed a couple of things that worry me...
>
> On Tue, May 08, 2018 at 06:17:59PM -0400, Kent Overstreet wrote:
> > Signed-off-by: Kent Overstreet
We would not be matching the following chip/compatible strings
combinations, which would lead to not setting the warm boot flag
correctly, fix that:
7260A0/B0: brcm,brcmstb-memc-ddr-rev-b.2.1
7255A0: brcm,brcmstb-memc-ddr-rev-b.2.3
7278Bx: brcm,brcmstb-memc-ddr-rev-b.3.1
The B2.1 core
From: Doug Berger
Update the Device Tree binding document and add a matching entry for the
MEMC DDR controller revision B3.0 which is found on chips like 7278A0
and newer.
Signed-off-by: Doug Berger
[florian: tweak commit message, make it apply to upstream kernel]
Signed-off-by: Florian Fainell
Hi all,
This patch series adds support for newer reveisions of the memory controller
which is necessary to make sure we do use the right programming sequence to
enter S2 and S3 suspend/resume modes.
Doug Berger (1):
soc: bcm: brcmstb: pm: Add support for newer rev B3.0 controllers
Florian Fain
Hi Finn,
Am 11.05.2018 um 22:06 schrieb Finn Thain:
>> You would have to be careful not to overwrite a pdev->dev.dma_mask and
>> pdev->dev.dma_coherent_mask that might have been set in a platform
>> device passed via platform_device_register here. Coldfire is the only
>> m68k platform currently
On Tue, May 08, 2018 at 11:22:36AM +1000, NeilBrown wrote:
> On Mon, May 07 2018, James Hogan wrote:
>
> > On Mon, May 07, 2018 at 07:40:49AM +1000, NeilBrown wrote:
> >>
> >> Hi James,
> >> this hasn't appear in linux-next yet, or in any branch
> >> of
> >>git://git.kernel.org/pub/scm/linu
On Wed, Mar 28, 2018 at 05:38:12PM +0200, Paul Cercueil wrote:
> The debug definitions were missing for MACH_JZ4770, resulting in a build
> failure when DEBUG_ZBOOT was set.
>
> Since the UART addresses are the same across all Ingenic SoCs, we just
> use a #ifdef CONFIG_MACH_INGENIC instead of che
On Fri, May 11, 2018 at 01:00:26AM -0400, Mimi Zohar wrote:
> On Thu, 2018-05-10 at 23:26 +, Luis R. Rodriguez wrote:
> > On Wed, May 09, 2018 at 10:00:58PM -0400, Mimi Zohar wrote:
> > > On Wed, 2018-05-09 at 23:48 +, Luis R. Rodriguez wrote:
> > > > On Wed, May 09, 2018 at 06:06:57PM -040
>I find this hard to believe. There's always the possibility that some
>part of the system doesn't support ACS so if the PCI bus addresses and
>IOVA overlap there's a good chance that P2P and ATS won't work at all on
>some hardware.
I tend to agree but this comes down to how IOV
With a possible change to pr_fmt coming, the logging output can
become unbalanced when an initial line has a prefix and subsequent
lines do not when a multiple line pr_ is emitted.
Fix it by emitting a single line.
Miscellanea:
o Convert consecutive tests of total_lost and !total_lost to
Hi Georgi,
On Fri, Mar 9, 2018 at 1:12 PM Georgi Djakov
wrote:
> This patch introduce a new API to get requirements and configure the
> interconnect buses across the entire chipset to fit with the current
> demand.
> The API is using a consumer/provider-based model, where the providers are
> th
On Fri, May 11, 2018 at 10:15:55PM +0100, James Hogan wrote:
> On Fri, May 11, 2018 at 02:14:16PM -0700, Guenter Roeck wrote:
> > On Fri, May 11, 2018 at 09:54:14PM +0100, James Hogan wrote:
> > > On Fri, May 11, 2018 at 01:17:04PM -0300, Paul Cercueil wrote:
> > > > Le 11 mai 2018 11:52, James Hog
On Fri, Mar 9, 2018 at 1:11 PM Georgi Djakov
wrote:
> On some Qualcomm SoCs, there is a remote processor, which controls some of
> the Network-On-Chip interconnect resources. Other CPUs express their needs
> by communicating with this processor. Add a driver to handle comminication
> with this re
Hi Georgi,
On Fri, Mar 9, 2018 at 1:11 PM Georgi Djakov
wrote:
> Add driver for the Qualcomm interconnect buses found in msm8916 based
> platforms.
> Signed-off-by: Georgi Djakov
> ---
>drivers/interconnect/Kconfig| 5 +
>drivers/interconnect/Makefile | 1 +
>driver
On Fri, Mar 9, 2018 at 1:10 PM Georgi Djakov
wrote:
> Currently we support only platform data for specifying the interconnect
> endpoints. As now the endpoints are hard-coded into the consumer driver
> this may leed to complications when a single driver is used by multiple
Nit: s/leed/lead/
-Ev
By specifying the properties "mtd-oob-ecc" and "mtd-oob-free", it is
now possible to specify from devicetree where the ECC data is located
inside the OOB region.
Signed-off-by: Paul Cercueil
---
Documentation/devicetree/bindings/mtd/nand.txt | 7 +
drivers/mtd/nand/raw/nand_base.c
David, is there something you want to tell us?
Drugs are bad, m'kay..
Linus
On Fri, May 11, 2018 at 2:00 PM David Miller wrote:
> "from Kevin Easton", "Thanks to Bhadram Varka", "courtesy of Gustavo A.
> R. Silva", "To Eric Dumazet we are most grateful for this fix", "This
> fi
On Fri, 11 May 2018 12:16:51 +0800 Larry Chen wrote:
> > Nice changelog, but it gives no information about the severity of the
> > bug: how often does it hit and what is the end-user impact.
> >
> > This info is needed so that I and others can decide which kernel
> > version(s) need the patch, so
All Marvell switch families except 88E6390 have direct registers in
Global 1 for IEEE and IP priorities override mapping. The 88E6390 uses
indirect tables instead.
Add .ieee_pri_map and .ip_pri_map ops to distinct that and call them
from a mv88e6xxx_pri_setup helper. Only non-6390 are concerned AT
The mv88e6xxx driver is still writing arbitrary registers at setup time,
e.g. priority override bits. Add ops for them and provide specific setup
functions for priority and stats before getting rid of the erroneous
mv88e6xxx_g1_setup code, as previously done with Global 2.
Vivien Didelot (3):
ne
The Marvell 88E6390 model has its histogram mode bits moved in the
Global 1 Control 2 register. Use the previously introduced
mv88e6xxx_g1_ctl2_mask helper to set them.
At the same time complete the documentation of the said register.
Signed-off-by: Vivien Didelot
---
drivers/net/dsa/mv88e6xxx/
1 - 100 of 683 matches
Mail list logo
