On Qualcomm Technologies, Inc. platforms, an OPP node needs
to describe an additional level/corner value that is then communicated
to a remote microprocessor by the CPU, which then takes some
actions (like adjusting voltage values across various rails)
based on the value passed.
Describe these bin
The Power domains for corners just pass the performance state set by the
consumers to the RPM (Remote Power manager) which then takes care
of setting the appropriate voltage on the corresponding rails to
meet the performance needs.
We add all Power domain data needed on msm8996 here. This driver c
Add DT bindings to describe the rpm/rpmh power domains found on Qualcomm
Technologies, Inc. SoCs. These power domains communicate a performance
state to RPM/RPMh, which then translates it into corresponding voltage on a
PMIC rail.
Signed-off-by: Rajendra Nayak
Signed-off-by: Viresh Kumar
Reviewe
On Mon, Jun 25, 2018 at 6:23 PM Li Zhijian wrote:
>
> On 6/25/2018 11:40 PM, Andy Lutomirski wrote:
> > On Mon, Jun 25, 2018 at 1:41 AM Li Zhijian wrote:
> >> Hi
> >>
> >> Intel 0Day noticed that test_syscall_vdso_32 failed since
> >> 8bb2610bc4967f19672444a7b0407367f1540028(x86/entry/64/compat:
The sigreturn_64 selftest has always failed on AMD CPUs. Fix it and
clean it up a bit.
Andy Lutomirski (2):
selftests/x86/sigreturn/64: Fix spurious failures on AMD CPUs
selftests/x86/sigreturn: Minor cleanups
tools/testing/selftests/x86/sigreturn.c | 59 +++--
1 file ch
We have short names for the requested and resulting register values.
Use them instead of spelling out the whole register entry for each
case.
Signed-off-by: Andy Lutomirski
---
tools/testing/selftests/x86/sigreturn.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git
When I wrote the sigreturn test, I didn't realize that AMD's busted
IRET behavior was different from Intel's busted IRET behavior. On
AMD CPUs, the CPU leaks the high 32 bits of the kernel stack pointer
to certain userspace contexts. Gee, thanks. There's very little
the kernel can do about it.
Hi Linus,
please pull the following patches to your tree.
Thanks,
Michal
The following changes since commit f0dc7f9c6dd99891611fca5849cbc4c6965b690e:
Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
(2018-06-10 19:25:23 -0700)
are available in the git repository at:
git://g
From: Sean Wang
Add MT7622 Bluetooth firmware files, along with the corresponding MediaTek
license file.
Signed-off-by: Sean Wang
---
LICENCE.mediatek| 9 +
WHENCE | 9 +
mediatek/mt7622pr2h.bin | Bin 0 -> 78158 bytes
3 files changed, 18 insertions
From: Sean Wang
In order to open up the required power gate before any operation can be
effectively performed over the serial bus between CPU and serdev, it's
clearly essential to add common attach functions for PM domains to serdev
at the probe phase.
Similarly, the relevant dettach function fo
From: Sean Wang
Add a new quirk HCI_QUIRK_NON_PERSISTENT_SETUP allowing that a quirk that
runs setup() after every open() and not just after the first open().
Signed-off-by: Sean Wang
---
include/net/bluetooth/hci.h | 9 +
net/bluetooth/hci_core.c| 3 ++-
2 files changed, 11 insert
From: Sean Wang
Add binding document for a SoC built-in device using MediaTek protocol.
Which could be found on MT7622 SoC or other similar MediaTek SoCs.
Signed-off-by: Sean Wang
Reviewed-by: Rob Herring
---
.../devicetree/bindings/net/mediatek-bluetooth.txt | 35 ++
1 fi
From: Sean Wang
This adds a driver to run on the top of btuart driver for the MediaTek
serial protocol based on running H:4, which can enable the built-in
Bluetooth device inside MT7622 SoC.
Signed-off-by: Sean Wang
---
drivers/bluetooth/Kconfig | 12 ++
drivers/bluetooth/Makefile|
From: Sean Wang
v4 and changes since v3:
- refine patch 2 based on commit 919b7308fcc4 to allow that
dev_pm_domain_attach() will return better error codes.
v3 and changes since v2
* all changes happen on patch 6
- fix up SPDX license style for btmtkuart.h.
- change firmware download from
From: Marcel Holtmann
This is a from scratch written driver to run H:4 on serdev based system
with a Bluetooth controller attached via an UART. It is currently tested
on RPi3 and it has Broadcom integration. It is DT only and is missing
GPIO and runtime power management integration. Also Apple or
From: Sean Wang
Adding an independent btuart.h header allows these essential definitions
can be reused in vendor driver. Also, struct btuart_vnd is extended with
additional callbacks such as .init initializing vendor data, .shtudown,
.recv and .send supporting SoC specific framing for that btuart
From: Sean Wang
Add an entry for the MediaTek Bluetooth driver.
Signed-off-by: Sean Wang
---
MAINTAINERS | 8
1 file changed, 8 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 9d5eeff..b06e38d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8987,6 +8987,14 @@ F: inclu
Commit 8bb2610bc496 ("x86/entry/64/compat: Preserve r8-r11 in int
$0x80") was busted. My original patch had a minor conflict with
some of the nospec changes. git apply is very clever and silently
accepted the patch by making the same changes to a different
function in the same file. There was ob
From: Alan Chiang
In at24.c, it uses 8-bit addressing by default. In this patch,
add a property address-width that provides a flexible method to
pass the information to the driver.
Alan Chiang (2):
dt-bindings: at24: Add address-width property
eeprom: at24: Add support for address-width prop
From: Alan Chiang
The AT24 series chips use 8-bit address by default. If some
chips would like to support more than 8 bits, the at24 driver
should be added the compatible field for specfic chips.
Provide a flexible way to determine the addressing bits through
address-width in this patch.
Signed
From: Alan Chiang
Provide a flexible way to determine the addressing bits of eeprom.
Pass the addressing bits to driver through address-width property.
Signed-off-by: Alan Chiang
Signed-off-by: Andy Yeh
---
since v1
-- Add a warn message for 8-bit addressing.
since v2
-- Modify the warning me
On Wed, Jun 27, 2018 at 10:07:26AM +1000, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the rdma tree got a conflict in:
>
> drivers/infiniband/core/uverbs_cmd.c
>
> between commit:
>
> 940efcc8889f ("RDMA/uverbs: Protect from attempts to create flows on
> unsupported QP")
On Tue, Jun 26, 2018 at 11:05 PM, Shakeel Butt wrote:
> On Tue, Jun 26, 2018 at 12:03 PM Johannes Weiner wrote:
>>
>> On Mon, Jun 25, 2018 at 04:06:58PM -0700, Shakeel Butt wrote:
>> > @@ -140,8 +141,9 @@ struct fanotify_event_info
>> > *fanotify_alloc_event(struct fsnotify_group *group,
>> >
2018-06-18 13:55 GMT+09:00 NeilBrown :
> When building an object to be included in mod.a we
> cannot know the name of the module. So don't define
> KBUILD_MODNAME. This will ensure attempt to use
> that macro when the module name isn't know will
> trigger an error.
Honestly, I hate KBUILD_MODNAM
Hi Rik,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.18-rc2 next-20180626]
[cannot apply to tip/x86/core]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https
Hi Saravanan,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on clk/clk-next]
[also build test WARNING on v4.18-rc2 next-20180626]
[cannot apply to robh/for-next]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system
Hi Saravanan,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on clk/clk-next]
[also build test WARNING on v4.18-rc2 next-20180626]
[cannot apply to robh/for-next]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system
Hi sorry I'm not sure I understand; I based the change on linux-next
master, let me know if I should be using something else. The change is
not dependent on https://patchwork.kernel.org/patch/10453893/
On Wed, Jun 27, 2018 at 1:28 PM, Louis Collard
wrote:
> Hi sorry I'm not sure I understand; I b
Hi Dennis,
On mar., juin 05 2018, Dennis Gilmore wrote:
> The helios4 is a Armada388 based nas board designed by SolidRun and
> based on their SOM. It is sold by kobol.io the dts file came from
> https://raw.githubusercontent.com/armbian/build/master/patch/kernel/mvebu-default/95-helios4-devic
Thanks for all the replies, let me add some background around the
motivation for this change.
On some systems we have seen large delays in boot time, due to
blocking on a call to getrandom() before the entropy pool has been
initialized. On these systems the usual sources of entropy are not
suffici
Hi Georgi
On Wed, 20 Jun 2018 at 14:11, Georgi Djakov wrote:
[snip]
> +
> +static struct icc_path *path_allocate(struct icc_node *dst, ssize_t
> num_nodes)
> +{
> + struct icc_node *node = dst;
> + struct icc_path *path;
> + size_t i;
> +
> + path = kzalloc(sizeof(*path
Hi Ethan,
On mar., juin 19 2018, Ethan Tuttle wrote:
> With CONFIG_FORTIFY_SOURCE, memcpy uses the declared size of operands to
> detect buffer overflows. If src or dest is declared as a char, attempts to
> copy more than byte will result in a fortify_panic().
>
> Address this problem in mveb
an for the user to make a
bonehead stupid move and lose all his treasured disk archives. Doing otherwise
is very poor form.
{o.o} Joanne "Said enough, she has" Dow
On 20180626 18:07, Michael Schmitz wrote:
Joanne,
As far as I have been able to test, the change is backwards compat
On Tue, Jun 26, 2018 at 02:03:38PM +0800, Ye Xiaolong wrote:
> Hi,
>
> On 06/22, Christoph Hellwig wrote:
> >Hi Xiaolong,
> >
> >can you retest this workload on the following branch:
> >
> >git://git.infradead.org/users/hch/vfs.git remove-get-poll-head
> >
> >Gitweb:
> >
> >
> > http://git
Al, can you pick up this fix from Chunyu?
On Tue, Jun 26, 2018 at 08:20:52AM -0400, Chunyu Hu wrote:
>
>
> - Original Message -
> > From: "Christoph Hellwig"
> > To: "Chunyu Hu"
> > Cc: v...@zeniv.linux.org.uk, h...@lst.de, linux-fsde...@vger.kernel.org,
> > linux-kernel@vger.kernel.o
701 - 735 of 735 matches
Mail list logo
