Hi Angus,
What is the status of this patch? Most likely this should go through
Shwan's tree.
I noticed that I have also sent a similar patch to Shawn:
https://www.spinics.net/lists/arm-kernel/msg708424.html
So, lets coordinate and work better on this.
I am now preparing another series where I
On Wed, 20 Feb 2019 14:35:06 +, Anson Huang wrote:
> Add new resources as below according to latest system
> controller firmware for new features:
>
> IMX_SC_R_PERF
> IMX_SC_R_OCRAM
> IMX_SC_R_DMA_5_CH0
> IMX_SC_R_DMA_5_CH1
> IMX_SC_R_DMA_5_CH2
>
From: Vadim Lomovtsev
Date: Wed, 20 Feb 2019 11:02:42 +
> The ThunderX CN88XX NIC Virtual Function driver uses mailbox interface
> to communicate to physical function driver. Each of VF has it's own pair
> of mailbox registers to read from and write to. The mailbox registers
> has no
Em Wed, Jan 09, 2019 at 11:18:35AM +0200, Adrian Hunter escreveu:
> x86 retpoline functions pollute the call graph by showing up everywhere
> there is an indirect branch, but they do not really mean anything. Make
> changes so that the default retpoline functions will no longer appear in
> the
In non-smp configuration, hartid can be higher that NR_CPUS.
riscv_of_processor_hartid should not be compared to hartid to NR_CPUS in
that case. Moreover, this function checks all the DT properties of a
hart node. NR_CPUS comparison seems out of place.
Signed-off-by: Atish Patra
Reviewed-by:
The existing upstream kernel doesn't boot for non-smp configuration.
This patch series address various issues with non-smp configurations.
The patch series is based on 5.0-rc7 + Johan's below mentioned patch
series. Tested on both QEMU and HiFive Unleashed board using both
OpenSBI & BBL.
It is perfectly okay to call riscv_hartid_to_cpuid for a hartid that is
not mapped with an CPU id. It can happen if the calling functions
retrieves the hartid from DT. However, that hartid was never brought
online by the firmware or kernel for any reasons.
No need to BUG() in the above case. A
Currently, logical CPU id to physical hartid mapping is defined for both
smp and non-smp configurations. This is not required as we need this
only for smp configuration. The mapping function can define directly
boot_cpu_hartid for non-smp use case.
The reverse mapping function i.e. hartid to
In SMP path, __cpu_up waits for other CPU to come online indefinitely.
This is wrong as other CPU might be disabled in machine mode and
possible CPU is set to the cpus present in DT.
Introduce a completion variable and waits only for a second.
Signed-off-by: Atish Patra
Reviewed-by: Anup Patel
We should never have a cpuid greater that NR_CPUS. Compare with NR_CPUS
before creating the mapping between logical and physical CPU ids. This
is also mandatory as NR_CPUS check is removed from
riscv_of_processor_hartid.
Signed-off-by: Atish Patra
Reviewed-by: Anup Patel
Reviewed-by: Christoph
Currently, we set hwcap based on first valid hart from DT. This may not
be correct always as that hart might not be current booting cpu or may
have a different capability.
Set hwcap as the capabilities supported by all possible harts with "okay"
status.
Signed-off-by: Atish Patra
---
On Fri, 22 Feb 2019 11:34:58 -0800
Alexei Starovoitov wrote:
> so you're saying you will break existing kprobe scripts?
Yes we may.
> I don't think it's a good idea.
> It's not acceptable to break bpf_probe_read uapi.
Then you may need to add more code to determine if the address is user
From: David Chen
Date: Wed, 20 Feb 2019 13:47:19 +0800
> From: David Chen
>
> RTL8153-BD is used in Dell DA300 type-C dongle.
> Added RTL8153-BD support to activate MAC address pass through on DA300.
> Apply correction on previously submitted patch in net.git tree.
>
> Signed-off-by: David
In order to suspend-resume CPU with Trusted Foundations firmware being
present on Tegra30, the LP1/LP2 boot vectors and CPU caches need to be
set up using the firmware calls and then suspend code shall avoid
re-disabling parts that were disabled by the firmware.
Signed-off-by: Dmitry Osipenko
Thanks for review.
On Fri, Feb 22, 2019 at 6:44 PM Arnaud Pouliquen
wrote:
>
> Hello Xiang,
>
>
>
> On 2/12/19 8:13 AM, Xiang Xiao wrote:
> > From: QianWenfa
> >
> > the two phase handsake make the client could initiate the transfer
> > immediately without the server side send any dummy message
CPU always jumps into reset handler in ARM-mode from the Trusted
Foundations firmware, hence let's make CPU to always jump into kernel
in ARM-mode regardless of the firmware presence. This is required to
make Thumb-2 kernel working with the Trusted Foundations firmware on
Tegra30.
Signed-off-by:
CPU isn't allowed to touch secure registers while running under secure
monitor. Hence skip applying of CPU erratas in the reset handler if
Trusted Foundations firmware presents.
Partially based on work done by Michał Mirosław [1].
[1] https://www.spinics.net/lists/arm-kernel/msg594768.html
Add a helper that provides information about whether Trusted Foundations
firmware operations have been registered.
Signed-off-by: Dmitry Osipenko
---
arch/arm/firmware/trusted_foundations.c| 5 +
arch/arm/include/asm/trusted_foundations.h | 7 +++
2 files changed, 12 insertions(+)
On Tegra30 L2 cache should be initialized using firmware call if CPU
is running in insecure mode. Set up the required outer-cache write_sec()
callback early during boot using the firmware API, it is always a NO-OP
on T114+ and is NO-OP on T20/30 if Trusted Foundations firmware node
isn't present
Implement L2 cache initialization firmware callback that should be
invoked early during boot in order to set up the required outer cache
driver's callbacks.
Partially based on work done by Michał Mirosław [1].
[1] https://www.spinics.net/lists/arm-kernel/msg594765.html
Signed-off-by: Dmitry
The Trusted Foundations firmware call varies depending on the required
suspend-mode. Make the firmware API to take the mode argument in order
to expose all of the modes to firmware user.
Signed-off-by: Dmitry Osipenko
---
arch/arm/firmware/trusted_foundations.c| 29 --
Hello,
This patchset adds support for the Trusted Foundations firmware on
NVIDIA Tegra30. Pretty much all of Tegra30 consumer devices have that
firmware and upstream kernel can't boot on those devices without the
firmware support.
Changelog:
v6: - One patch got messed up accidentally in v5,
On Fri, Feb 22, 2019 at 11:29 AM Srinath Mannam
wrote:
>
> Hi Rob,
>
> Thanks for the review, Please find my comments below in line.
>
> On Fri, Feb 22, 2019 at 10:50 PM Rob Herring wrote:
> >
> > On Wed, Feb 20, 2019 at 04:04:00PM +0530, Srinath Mannam wrote:
> > > Add DT binding document for
On Fri, Feb 22, 2019 at 02:30:26PM -0500, Steven Rostedt wrote:
> On Fri, 22 Feb 2019 11:27:05 -0800
> Alexei Starovoitov wrote:
>
> > On Fri, Feb 22, 2019 at 09:43:14AM -0800, Linus Torvalds wrote:
> > >
> > > Then we should still probably fix up "__probe_kernel_read()" to not
> > > allow user
On Fri, 22 Feb 2019 11:27:05 -0800
Alexei Starovoitov wrote:
> On Fri, Feb 22, 2019 at 09:43:14AM -0800, Linus Torvalds wrote:
> >
> > Then we should still probably fix up "__probe_kernel_read()" to not
> > allow user accesses. The easiest way to do that is actually likely to
> > use the
send_cpu_message() doesn't update the result parameter when an error
occurs in its code. Therefore, callers of send_cpu_message() shouldn't use
the result value when the return code indicates error.
This patch fixes a static checker warning in goya_test_cpu_queue(), where
that function did print
The driver uses the DMA_BUF module which is built only if
DMA_SHARED_BUFFER is selected. DMA_SHARED_BUFFER doesn't have any
dependencies so it is ok to select it (as done by many other components).
Signed-off-by: Oded Gabbay
---
drivers/misc/habanalabs/Kconfig | 1 +
1 file changed, 1
On Fri, Feb 22, 2019 at 09:43:14AM -0800, Linus Torvalds wrote:
>
> Then we should still probably fix up "__probe_kernel_read()" to not
> allow user accesses. The easiest way to do that is actually likely to
> use the "unsafe_get_user()" functions *without* doing a
> uaccess_begin(), which will
Rob,
On Tue, Feb 12, 2019 at 4:57 PM Jagan Teki wrote:
>
> Add vendor prefix for techstar, known as
> Shenzhen Techstar Electronics Co., Ltd. a known producer for LCD modules.
>
> Signed-off-by: Jagan Teki
> ---
> Changes for v2:
> - rebase for master
>
>
On 2/22/19 6:20 AM, Peter Zijlstra wrote:
> On Fri, Feb 22, 2019 at 01:17:01PM +0100, Paolo Bonzini wrote:
>> On 18/02/19 21:40, Peter Zijlstra wrote:
>>> On Mon, Feb 18, 2019 at 09:49:10AM -0800, Linus Torvalds wrote:
On Mon, Feb 18, 2019 at 9:40 AM Peter Zijlstra
wrote:
>
>
On 2/19/19 12:04 PM, jgli...@redhat.com wrote:
From: Jérôme Glisse
CPU page table update can happens for many reasons, not only as a result
s/update/updates
s/happens/happen
of a syscall (munmap(), mprotect(), mremap(), madvise(), ...) but also
as a result of kernel activities (memory
On Thu, Feb 21, 2019 at 12:22 AM Dominique Martinet
wrote:
>
> Tom Herbert wrote on Wed, Feb 20, 2019:
> > > When the client closes the socket, some messages are obviously still "in
> > > flight", and the server will recv a POLLERR notification on the csock at
> > > some point with many messages
On Fri, Feb 22, 2019 at 10:48 AM Keith Busch wrote:
>
> On Wed, Feb 20, 2019 at 11:02:01PM +0100, Rafael J. Wysocki wrote:
> > On Thu, Feb 14, 2019 at 6:10 PM Keith Busch wrote:
> > > config ACPI_HMAT
> > > bool "ACPI Heterogeneous Memory Attribute Table Support"
> > > depends
On 2/14/19 3:49 PM, Atish Patra wrote:
On 2/13/19 4:38 PM, Palmer Dabbelt wrote:
On Wed, 13 Feb 2019 00:44:42 PST (-0800), jo...@kernel.org wrote:
On Tue, Feb 12, 2019 at 11:58:10AM -0800, Atish Patra wrote:
On 2/12/19 3:25 AM, Johan Hovold wrote:
On Tue, Feb 12, 2019 at 03:10:12AM -0800,
On Fri, Feb 22, 2019 at 12:46 PM Alexis Ballier wrote:
>
> This adds basic support for the Orange Pi RK3399 board.
> What works:
> - SD card / emmc.
> - Debug UART
> - Ethernet
> - USB: Type C, internal USB3 for SATA, 4 USB 2.0 ports
> - Sensors: All of them but the Hall sensor.
> - Buttons
> -
On 2/21/19 8:05 PM, Oliver wrote:
> On Fri, Feb 22, 2019 at 5:38 AM wrote:
>> On 2/21/19 1:57 AM, Lukas Wunner wrote:
[snip]
>>> If the quirk is x86-specific, please enclose it in "#ifdef CONFIG_X86"
>>> to reduce kernel footprint on other arches.
>>
>> That's a tricky one. If you look at p. 185
On Fri, Feb 22, 2019 at 08:58:25PM +0300, Andrey Ryabinin wrote:
> In a presence of more than 1 memory cgroup in the system our reclaim
> logic is just suck. When we hit memory limit (global or a limit on
> cgroup with subgroups) we reclaim some memory from all cgroups.
> This is sucks because,
On Fri, Feb 22, 2019 at 10:25:09AM -0800, Eric Dumazet wrote:
>
>
> On 02/22/2019 09:57 AM, Eric Biggers wrote:
>
> > ->setattr() is called under inode_lock(), which __sock_release() also
> > takes. So
> > the uses of sock->sk are serialized. See commit 6d8c50dcb029 ("socket:
> > close
> >
Quoting Anson Huang (2019-02-21 18:32:10)
> On NXP's i.MX SoCs with system controller inside, CPU frequency
> scaling can ONLY be done by system controller firmware, and it
> can ONLY be requested from secure mode, so Linux kernel has to
> call ARM SMC to trap to ARM-Trusted-Firmware to request
On 2/19/19 12:04 PM, jgli...@redhat.com wrote:
From: Jérôme Glisse
Use an unsigned field for flags other than blockable and convert
the blockable field to be one of those flags.
Signed-off-by: Jérôme Glisse
Cc: Christian König
Cc: Joonas Lahtinen
Cc: Jani Nikula
Cc: Rodrigo Vivi
Cc:
Quoting Anson Huang (2019-02-21 18:32:10)
> On NXP's i.MX SoCs with system controller inside, CPU frequency
> scaling can ONLY be done by system controller firmware, and it
> can ONLY be requested from secure mode, so Linux kernel has to
> call ARM SMC to trap to ARM-Trusted-Firmware to request
On Fri, 22 Feb 2019 08:59:42 -0700
shuah wrote:
> On 2/22/19 7:59 AM, Masami Hiramatsu wrote:
> > On Fri, 22 Feb 2019 10:10:21 +0100
> > Juerg Haefliger wrote:
> >
> >> The \e sequence character is not POSIX. Fix that by using \033 instead.
> >>
> >> Signed-off-by: Juerg Haefliger
> >
>
On Fri, 2019-02-22 at 20:43 +0300, Andrey Ryabinin wrote:
> workingset_eviction() doesn't use and never did use the @mapping
> argument.
> Remove it.
>
> Signed-off-by: Andrey Ryabinin
> Cc: Johannes Weiner
> Cc: Michal Hocko
> Cc: Vlastimil Babka
> Cc: Rik van Riel
> Cc: Mel Gorman
On Fri, 2019-02-22 at 20:43 +0300, Andrey Ryabinin wrote:
> too_many_isolated() in mm/compaction.c looks only at node state,
> so it makes more sense to change argument to pgdat instead of zone.
>
> Signed-off-by: Andrey Ryabinin
> Cc: Johannes Weiner
> Cc: Michal Hocko
> Cc: Vlastimil Babka
null_handle_bio() erroneously uses the bio_op macro
which masks respective request flag bits including REQ_FUA
out thus failing the check.
Fix by checking bio->bi_opf directly.
Signed-off-by: Heinz Mauelshagen
---
drivers/block/null_blk_main.c | 2 +-
1 file changed, 1 insertion(+), 1
On 2/19/19 12:04 PM, jgli...@redhat.com wrote:
From: Jérôme Glisse
Use the mmu_notifier_range_blockable() helper function instead of
directly dereferencing the range->blockable field. This is done to
make it easier to change the mmu_notifier range field.
This patch is the outcome of the
On 2/19/19 12:04 PM, jgli...@redhat.com wrote:
From: Jérôme Glisse
Simple helpers to test if range invalidation is blockable. Latter
patches use cocinnelle to convert all direct dereference of range->
blockable to use this function instead so that we can convert the
blockable field to an
On Fri, 2019-02-22 at 20:58 +0300, Andrey Ryabinin wrote:
> In a presence of more than 1 memory cgroup in the system our reclaim
> logic is just suck. When we hit memory limit (global or a limit on
> cgroup with subgroups) we reclaim some memory from all cgroups.
> This is sucks because, the
On 2/22/19 6:01 AM, Jing Xiangfeng wrote:
Thanks, just a couple small changes.
> User can change a node specific hugetlb count. i.e.
> /sys/devices/system/node/node1/hugepages/hugepages-2048kB
Please make that,
/sys/devices/system/node/node1/hugepages/hugepages-2048kB/nr_hugepages
> the
Paolo Bonzini writes:
> On 22/02/19 17:45, Vitaly Kuznetsov wrote:
>> Commit 14c07ad89f4d ("x86/kvm/mmu: introduce guest_mmu") brought one subtle
>> change: previously, when switching back from L2 to L1, we were resetting
>> MMU hooks (like mmu->get_cr3()) in kvm_init_mmu() called from
>>
mmiowb() is no more. It has ceased to be. It is an ex-barrier. So remove
all references to it from comments.
Signed-off-by: Will Deacon
---
drivers/net/ethernet/silan/sc92031.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/ethernet/silan/sc92031.c
All mmiowb() invocations have been removed, so there's no need to keep
banging on about it.
Signed-off-by: Will Deacon
---
drivers/scsi/qla1280.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/drivers/scsi/qla1280.c b/drivers/scsi/qla1280.c
index 93acbc5094f0..327eff67a1ee
Now that no driver code is using mmiowb() directly, we can remove the
dummy definitions from the architectures that don't make use of
asm-generic/io.h
Signed-off-by: Will Deacon
---
arch/alpha/include/asm/io.h| 2 --
arch/hexagon/include/asm/io.h | 2 --
arch/parisc/include/asm/io.h | 2
mmiowb() is now implied by spin_unlock() on architectures that require
it, so there is no reason to call it from driver code. This patch was
generated using coccinelle:
@mmiowb@
@@
- mmiowb();
and invoked as:
$ for d in drivers include/linux/qed sound; do \
spatch
Removing explicit calls to mmiowb() from driver code means that we must
now call into the generic mmiowb_spin_{lock,unlock}() functions from the
core spinlock code. In order to elide barriers following critical
sections without any I/O writes, we also hook into the asm-generic I/O
routines.
ARM includes asm-generic/io.h, which provides a dummy definition of
mmiowb() if one isn't already provided by the architecture.
Remove the useless definition.
Signed-off-by: Will Deacon
---
arch/arm/include/asm/io.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm/include/asm/io.h
mmiowb() is now implicit in spin_unlock(), so there's no reason to call
it from driver code. Redefine i40iw_mmiowb() to do nothing instead.
Signed-off-by: Will Deacon
---
drivers/infiniband/hw/i40iw/i40iw_osdep.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
In preparation for removing mmiowb() from driver code altogether using
coccinelle, remove all trailing comments since they won't be picked up
by spatch later on and will end up being preserved in the code.
Signed-off-by: Will Deacon
---
drivers/infiniband/hw/hfi1/chip.c| 2 +-
The guarantees provided by mmiowb() are now provided implicitly by
spin_unlock(), so we can remove all references from this most confusing
of barriers from our Documentation.
Good riddance.
Signed-off-by: Will Deacon
---
Documentation/driver-api/device-io.rst | 45 --
In a bid to kill off explicit mmiowb() usage in driver code, hook up
the asm-generic mmiowb() tracking code but override all of the functions
so that the existing (flawed) implementation is preserved on Power.
Future work should either use the asm-generic implementation entirely,
or implement a
mmiowb() only makes sense for SMP platforms, so we can remove it
entirely for nds32.
Signed-off-by: Will Deacon
---
arch/nds32/include/asm/io.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/nds32/include/asm/io.h b/arch/nds32/include/asm/io.h
index 71cd226d6863..5ef8ae5ba833 100644
In a bid to kill off explicit mmiowb() usage in driver code, hook up
the asm-generic mmiowb() tracking code for riscv, so that an mmiowb()
is automatically issued from spin_unlock() if an I/O write was performed
in the critical section.
Signed-off-by: Will Deacon
---
arch/riscv/Kconfig
m68k includes asm-generic/io.h, which provides a dummy definition of
mmiowb() if one isn't already provided by the architecture.
Remove the useless definition.
Cc: Geert Uytterhoeven
Signed-off-by: Will Deacon
---
arch/m68k/include/asm/io_mm.h | 2 --
1 file changed, 2 deletions(-)
diff
Hi all,
This series attempts to remove explicit mmiowb() calls from driver code,
instead adding it to spin_unlock() for architectures that require it.
The infamous "PowerPC trick" was found to be flawed, so a correct but probably
slower version is made generic for architectures wishing to use
Hook up asm-generic/mmiowb.h to Kbuild for all architectures so that we
can subsequently include asm/mmiowb.h from core code.
Cc: Masahiro Yamada
Cc: Arnd Bergmann
Signed-off-by: Will Deacon
---
arch/alpha/include/asm/Kbuild | 1 +
arch/arc/include/asm/Kbuild| 1 +
x86 maps mmiowb() to barrier(), but this is superfluous because a
compiler barrier is already implied by spin_unlock(). Since x86 also
includes asm-generic/io.h in its asm/io.h file, we can remove the
definition entirely and pick up the dummy definition from core code.
Signed-off-by: Will Deacon
Paolo Bonzini writes:
> On 22/02/19 17:46, Vitaly Kuznetsov wrote:
>> I noticed that fast_cr3_switch() always fails when we switch back from L2
>> to L1 as it is not able to find a cached root. This is odd: host's CR3
>> usually stays the same, we expect to always follow the fast path. Turns
>>
The mmiowb() macro is horribly difficult to use and drivers will continue
to work most of the time if they omit a call when it is required.
Rather than rely on driver authors getting this right, push mmiowb() into
arch_spin_unlock() for sh. If this is deemed to be a performance issue,
a
The mmiowb() macro is horribly difficult to use and drivers will continue
to work most of the time if they omit a call when it is required.
Rather than rely on driver authors getting this right, push mmiowb() into
arch_spin_unlock() for ia64. If this is deemed to be a performance issue,
a
The mmiowb() macro is horribly difficult to use and drivers will continue
to work most of the time if they omit a call when it is required.
Rather than rely on driver authors getting this right, push mmiowb() into
arch_spin_unlock() for mips. If this is deemed to be a performance issue,
a
arm64 includes asm-generic/io.h, which provides a dummy definition of
mmiowb() if one isn't already provided by the architecture.
Remove the useless definition.
Signed-off-by: Will Deacon
---
arch/arm64/include/asm/io.h | 2 --
1 file changed, 2 deletions(-)
diff --git
In preparation for removing all explicit mmiowb() calls from driver
code, implement a tracking system in asm-generic based on the PowerPC
implementation. This allows architectures with a non-empty mmiowb()
definition to automatically have the barrier inserted in spin_unlock()
following a critical
On Fri, Feb 22, 2019 at 3:32 AM Wolfram Sang wrote:
>
>
> > > > But I still have the feeling that the problem is not solved at the
> > > > right place. In i2c_new_device() we are storing parts of the fields of
> > > > struct i2c_board_info, and when resetting the irq we are losing
> > > >
On Wed, Feb 20, 2019 at 11:02:01PM +0100, Rafael J. Wysocki wrote:
> On Thu, Feb 14, 2019 at 6:10 PM Keith Busch wrote:
> > config ACPI_HMAT
> > bool "ACPI Heterogeneous Memory Attribute Table Support"
> > depends on ACPI_NUMA
> > + select HMEM_REPORTING
>
> If you want to
This adds basic support for the Orange Pi RK3399 board.
What works:
- SD card / emmc.
- Debug UART
- Ethernet
- USB: Type C, internal USB3 for SATA, 4 USB 2.0 ports
- Sensors: All of them but the Hall sensor.
- Buttons
- Wifi, Bluetooth
- HDMI out
Signed-off-by: Alexis Ballier
Cc:
On 21.02.2019 10:51, Maxime Chevallier wrote:
> The Alaska family of 10G PHYs has more abilities than the ones listed in
> PHY_10GBIT_FULL_FEATURES, the exact list depending on the model.
>
> Make use of the newly introduced .get_features call to build this list,
> using
The pull request you sent on Thu, 21 Feb 2019 13:57:21 -0800:
> https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git
> tags/clk-fixes-for-linus
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/a3504f7a38233030def726fcfe692e786ab162df
Thank you!
--
The pull request you sent on Thu, 21 Feb 2019 23:07:20 +:
> git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git tags/for-linus
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/168bd29830e8ebbffcd70d2af50249dca088e1a8
Thank you!
--
Deet-doot-dot, I am a
The pull request you sent on Fri, 22 Feb 2019 10:13:42 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2019-02-22
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/6ee2846cb4e7c6e8acdcb265299ad1c6de42b437
Thank you!
--
Deet-doot-dot, I am a bot.
On Wed, 20 Feb 2019 16:44:37 +0900, Sugaya Taichi wrote:
> Add DT bindings document for Milbeaut serial driver.
>
> Signed-off-by: Sugaya Taichi
> ---
> .../devicetree/bindings/serial/milbeaut-uart.txt| 21
> +
> 1 file changed, 21 insertions(+)
> create mode 100644
On Thu, Feb 21, 2019 at 04:30:51PM -0800, Brian Norris wrote:
> Badly-designed systems might have (for example) active-high wake pins
> that default to high (e.g., because of external pull ups) until they
> have an active firmware which starts driving it low. This can cause an
> interrupt storm in
On Fri, 2019-02-22 at 17:14 +0100, Borislav Petkov wrote:
> On Thu, Feb 21, 2019 at 03:44:31PM -0800, Rick Edgecombe wrote:
> > Changes v2 to v3:
> > - Fix commit messages and comments [Boris]
> > - Rename VM_HAS_SPECIAL_PERMS [Boris]
> > - Remove unnecessary local variables [Boris]
> > -
On Thu, Feb 21, 2019 at 04:34:03PM -0800, Brian Norris wrote:
> Currently, we don't coordinate BT USB activity with our handling of the
> BT out-of-band wake pin, and instead just use gpio-keys. That causes
> problems because we have no way of distinguishing wake activity due to a
> BT device
On Fri, Feb 22, 2019 at 9:48 AM Andy Lutomirski wrote:
>
> > On Feb 22, 2019, at 9:43 AM, Linus Torvalds
> > wrote:
> >
> > Then we should still probably fix up "__probe_kernel_read()" to not
> > allow user accesses. The easiest way to do that is actually likely to
> > use the
When CONFIG_KASAN is selected, defines the
prototypes for kasan_check_{read,write}(), rather than inline stubs.
This is the case even when it is included by files which are not
instrumented by KASAN. Where helpers (e.g. the atomics) are instrumented
with explicit calls to
22.02.2019 20:59, Dmitry Osipenko пишет:
> In order to resume CPU from suspend via trusted Foundations firmware,
> the LP1/LP2 boot vectors and CPU caches need to be set up using the
> firmware calls.
>
> Signed-off-by: Dmitry Osipenko
> ---
> arch/arm/mach-tegra/pm.c| 53
On 22/02/19 16:06, lantianyu1...@gmail.com wrote:
> From: Lan Tianyu
>
> This patchset is to introduce hv ept tlb range list flush function
> support in the KVM MMU component. Flushing ept tlbs of several address
> range can be done via single hypercall and new list flush function is
> used in
From: Haiyang Zhang
Incoming packets may have IP header checksum verified by the host.
They may not have IP header checksum computed after coalescing.
This patch re-compute the checksum when necessary, otherwise the
packets may be dropped, because Linux network stack always checks it.
On 02/22/2019 09:57 AM, Eric Biggers wrote:
> ->setattr() is called under inode_lock(), which __sock_release() also takes.
> So
> the uses of sock->sk are serialized. See commit 6d8c50dcb029 ("socket: close
> race condition between sock_close() and sockfs_setattr()").
Oh right, we added
syzbot has found a reproducer for the following crash on:
HEAD commit:7a25c6c0aac8 rocker: Add missing break for PRE_BRIDGE_FLAGS
git tree: net-next
console output: https://syzkaller.appspot.com/x/log.txt?x=104002d8c0
kernel config:
On 20/02/19 08:06, Yu Zhang wrote:
> Hi Paolo, any comments on this patch? And the other one(kvm: x86: Return
> LA57 feature based on hardware capability )? :-)
Queued both, thanks.
Paolo
> On Fri, Feb 01, 2019 at 12:09:23AM +0800, Yu Zhang wrote:
>> Previously, commit 7dcd57552008
On Fri, Feb 22, 2019 at 08:43:37PM +0300, Andrey Ryabinin wrote:
> shrink_node_memcg() always forcely shrink active anon list.
> This doesn't seem like correct behavior. If system/memcg has no swap, it's
> absolutely pointless to rebalance anon lru lists.
> And in case we did scan the active anon
On Fri, Feb 22, 2019 at 10:09 AM Keith Busch wrote:
>
> On Fri, Feb 22, 2019 at 11:12:38AM +0100, Brice Goglin wrote:
> > Le 14/02/2019 à 18:10, Keith Busch a écrit :
> > > +What:
> > > /sys/devices/system/node/nodeX/memory_side_cache/indexY/size
> > > +Date: December
On Sun, Feb 17, 2019 at 03:45:12PM +0100, Håkon Bugge wrote:
> Using CX-3 virtual functions, either from a bare-metal machine or
> pass-through from a VM, MAD packets are proxied through the PF driver.
>
> Since the VF drivers have separate name spaces for MAD Transaction Ids
> (TIDs), the PF
Hey, Oleg.
On Fri, Feb 22, 2019 at 05:34:42PM +0100, Oleg Nesterov wrote:
> > ptrace support is a lot less important than kill for sure but if at
> > all possible I think it'd be better to have it
>
> Tejun, I agree it would be better. I did not argue with that.
>
> The question is how this can
Assalamu Alaikum Wa Rahmatullahi Wa Barakatuh,
hello dear
I came across your contact during my private search. Mrs Aisha Al-
Qaddafi is my name, the only daughter of late Libyan president, am a
single Mother and a Widow with three Children.I have funds the sum of
$27.5 million USD for,
Quoting Paul Cercueil (2019-01-27 18:09:21)
> The 'div' field does not represent a number of bits used to divide
> (understand: right-shift) the divider, but a number itself used to
> divide the divider.
>
> Signed-off-by: Paul Cercueil
> Signed-off-by: Maarten ter Huurne
> Cc:
> ---
Applied
Quoting Paul Cercueil (2019-01-27 18:09:20)
> Take a parent rate of 180 MHz, and a requested rate of 4.285715 MHz.
> This results in a theorical divider of 41.93 which is then rounded
> up to 42. The .round_rate function would then return (180 MHz / 42) as
> the clock, rounded down, so
On Fri, Feb 22, 2019 at 11:22:12AM +0100, Brice Goglin wrote:
> Le 14/02/2019 à 18:10, Keith Busch a écrit :
> > +What:
> > /sys/devices/system/node/nodeX/memory_side_cache/indexY/associativity
> > +Date: December 2018
> > +Contact: Keith Busch
> > +Description:
> > +
Quoting Jorge Ramirez-Ortiz (2019-01-28 10:32:55)
> When COMMON_CLK_DISABLED_UNUSED is set, in an effort to save power and
> to keep the software model of the clock in line with reality, the
> framework transverses the clock tree and disables those clocks that
> were enabled by the firmware but
301 - 400 of 856 matches
Mail list logo
