On 17/01/18 03:37, ernest.zhang wrote:
> when eMMC used as boot device, the eMMC signaling voltage is tied to 1.8v
> fixed output voltage, bios can set o2 sd host controller PCI configuration
> register 0x308 bit4 to 1 to let host controller skip try 3.3.v signaling
> voltage and direct use 1.8v si
On 17/01/18 03:38, ernest.zhang wrote:
> O2 sd host controllers have a hardware tuning function. In software
> tuning mode CPU should send multiple command to host controller but in
> hardware tuning mode, CPU need send only one tuning command to sd host
> controller. It can improve the speed linux
On Fri, Jan 5, 2018 at 4:56 PM, Mario Limonciello
wrote:
> The class/select were mistakingly put into octal notation but
mistakenly
> intended to be in decimal notation.
>
> Suggest-by: Pali Rohar
Suggested-by:
> Signed-off-by: Mario Limonciello
I have fixed above and pushed to my review an
Hi Christophe,
On jeu., janv. 25 2018, Christophe JAILLET
wrote:
> If the optional "axi" clk is deferred, we still need to undo some
> initialisation. Espacially 'master' must be released. It will be
Especially
> reallocated the next time 'orion_spi_probe()' is called.
>
>
On Fri, Jan 26, 2018 at 7:04 AM, Andi Shyti wrote:
> The mms114 binding [1] specifies that the 'x' and 'y' should be
> called respectively 'touchscreen-size-x' and 'touchscreen-size-y'
> in coherence with the touchscreen [2] binding.
>
> Update the mms114 node for trats2 and trats dts according to
On Fri, Jan 26, 2018 at 11:00:41AM +0800, Yong wrote:
> Hi Maxime,
>
> On Fri, 26 Jan 2018 09:46:58 +0800
> Yong wrote:
>
> > Hi Maxime,
> >
> > Do you have any experience in solving this problem?
> > It seems the PHYS_OFFSET maybe undeclared when the ARCH is not arm.
>
> Got it.
> Should I ad
On 18/01/18 10:05, Vijay Viswanath wrote:
> During probe check whether the vdd-io regulator of sdhc platform device
> can support 1.8V and 3V and store this information as a capability of
> platform device.
>
> Signed-off-by: Vijay Viswanath
Not sure why this is RFC, but for sdhci:
Acked-by: Ad
On 18/01/18 10:05, Vijay Viswanath wrote:
> From: Krishna Konda
>
> The PADs for sdhc controller are dual-voltage that support 3v/1.8v.
> Those PADs have a control signal (io_pad_pwr_switch/mode18 ) that
> indicates whether the PAD works in 3v or 1.8v.
>
> SDHC core on msm platforms should have
After checking all possible call chains to he_open() here,
my tool finds that he_open() is never called in atomic context.
And this function is assigned to a function pointer "dev->ops->open",
which is only called by __vcc_connect() (net/atm/common.c)
through dev->ops->send(), and __vcc_connect() i
On 1/26/2018 1:24 AM, Frank Rowand wrote:
On 01/25/18 02:14, Chintan Pandya wrote:
of_find_node_by_phandle() takes a lot of time finding
right node when your intended device is too right-side
in the fdt. Reason is, we search each device serially
from the fdt, starting from left-most to right-m
The address space taken by the UART8 on the i.MX6UL is used for the
ESAI interface on i.MX6ULL.
Since the ESAI unit on i.MX6ULL has two more bits in the TFCR register
(TFIN, TAENB) it deserves to get its own compatible string, though the
bits are currently not used by the driver.
Signed-off-by: L
This patchset addresses some differences between i.MX6UL and i.MX6ULL
which have slipped through the cracks so far.
- UART8 is not on SPBA but on AIPS-3
- i.MX6ULL has an ESAI interface in the address range of the UART8 on i.MX6UL
- i.MX6ULL does not have a CAAM unit nor SIM interfaces
On 01/23/2018 07:40 PM, Florian Fainelli wrote:
[...]
>
> Florian Fainelli (2):
> MIPS: Allow including mach-generic/dma-coherence.h
> MIPS: Update dma-coherence.h files
>
I have tested these on our Octeon III platforms with PCIe and saw
no issues. Thanks.
Steve
Tested-by: Steven J. Hill
On 01/23/2018 07:47 PM, Florian Fainelli wrote:
[...]
>
> Florian Fainelli (6):
> MIPS: Allow board to override TLB initialization
> MIPS: Allow platforms to override mapping/unmapping coherent
> MIPS: BMIPS: Avoid referencing CKSEG1
> MIPS: Prepare for supporting eXtended KSEG0/1
> MI
On 26/01/2018 03:16, Alexei Starovoitov wrote:
> On Fri, Jan 26, 2018 at 01:39:30AM +0100, Mickaël Salaün wrote:
>> Do not build lib/bpf/bpf.o with this Makefile but use the one from the
>> library directory. This avoid making a buggy bpf.o file (e.g. missing
>> symbols).
>
> could you provide a
of_find_node_by_phandle() takes a lot of time (1ms per
call) to find right node when your intended device is
too deeper in the fdt. Reason is, we search for each
device serially in the fdt. See this,
struct device_node *__of_find_all_nodes(struct device_node *prev)
{
struct device_node *np
Hi,
Recently I am testing crash tool with structure layout randomized
kernel, and crash failed to work with it.
When using "gdb vmlinux"to examine both the randomized and
non-randomized vmlinux's debuginfo, take struct uts_namespace for
example, the output of "ptype struct uts_namespace" is iden
After checking all possible call chains to genpd_dev_pm_detach() and
genpd_dev_pm_attach() here,
my tool finds that these functions are never called in atomic context,
namely never in an interrupt handler or holding a spinlock.
Thus mdelay can be replaced with msleep to avoid busy wait.
This is fo
On Thu, Jan 25, 2018 at 6:18 AM, Paul E. McKenney
wrote:
> On Tue, Jan 23, 2018 at 03:59:31PM +0800, liangli...@huawei.com wrote:
>> From: Lihao Liang
>>
>> Signed-off-by: Lihao Liang
>> ---
>> kernel/rcu/rcuperf.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/kern
On Thu, 2018-01-25 at 12:02 +, Robin Murphy wrote:
> On 25/01/18 11:14, Yong Wu wrote:
> > In the commit 05f80300dc8b, the iommu framework has supposed all the
> > iommu drivers have their owner iommu-group, it get rid of the FIXME
> > workarounds while the group is NULL. But the flow of Mediat
On Fri, 26 Jan 2018 00:34:51 +0100, Nicolas Dichtel wrote:
> Why meaningful? The user knows that the answer is like if if was done in
> another
> netns. It enables to have only one netlink socket instead of one per netns.
> But
> the code using it will be the same.
Because you can't use it to
imx6ull-14x14-evk.dts currently includes the imx6ul.dtsi file for an
i.MX6ULL SoC which is plain wrong.
Rename the current imx6ul-14x14-evk.dts to .dtsi and include it from
imx6ul-14x14-evk.dts and imx6ull-14x14-evk.dts, so that both can
include the appropriate SoC specific (imx6ul.dtsi/imx6ull.dt
Hi Alexandre,
I remember it was discussed that the work after the V4L2 jobs API would
continue from the existing request API patches. I see that at least the
rather important support for events is missing in this version. Why was it
left out?
I also see that variable size IOCTL argument support i
The i.MX6ULL doesn't have the CAAM engine nor any SIM interface.
These are currently not implemented for i.MX6UL but it cannot hurt to
delete the corresponding nodes from the i.MX6ULL DTB anyway.
Signed-off-by: Lothar Waßmann
---
arch/arm/boot/dts/imx6ull.dtsi | 6 ++
1 file changed, 6 inser
UART8 on i.MX6ULL is not located on the SPBA bus like on i.MX6UL but
on the (otherwise unused) AIPS-3 bus.
Create the appropriate AIPS-3 bus configuration and move the uart8
definition where it belongs.
Signed-off-by: Lothar Waßmann
---
arch/arm/boot/dts/imx6ull.dtsi | 29 +++
After checking all possible call chains to
dev_pm_opp_init_cpufreq_table() here,
my tool finds that this function is never called in atomic context,
namely never in an interrupt handler or holding a spinlock.
And dev_pm_opp_init_cpufreq_table() calls dev_pm_opp_get_opp_count(),
which calls mutex
On Thu, Jan 25, 2018 at 6:20 AM, Paul E. McKenney
wrote:
> On Tue, Jan 23, 2018 at 03:59:32PM +0800, liangli...@huawei.com wrote:
>> From: Lihao Liang
>>
>> This is PRCU's counterpart of RCU's call_rcu() API.
>>
>> Reviewed-by: Heng Zhang
>> Signed-off-by: Lihao Liang
>> ---
>> include/linux/p
On Thu, 2018-01-25 at 18:11 -0800, Liran Alon wrote:
>
> P.S:
> It seems to me that all these issues could be resolved completely at
> hardware in future CPUs if BTB/BHB/RSB entries were tagged with
> prediction-mode (or similar metadata). It will be nice if Intel/AMD
> could share if that is the
imx6ull-14x14-evk.dts currently includes the imx6ul.dtsi file for an
i.MX6ULL SoC which is plain wrong.
Rename the current imx6ul-14x14-evk.dts to .dtsi and include it from
imx6ul-14x14-evk.dts and imx6ull-14x14-evk.dts, so that both can
include the appropriate SoC specific (imx6ul.dtsi/imx6ull.dt
Hi Lothar,
On Fri, Jan 26, 2018 at 4:25 PM, Lothar Waßmann
wrote:
> imx6ull-14x14-evk.dts currently includes the imx6ul.dtsi file for an
> i.MX6ULL SoC which is plain wrong.
>
> Rename the current imx6ul-14x14-evk.dts to .dtsi and include it from
> imx6ul-14x14-evk.dts and imx6ull-14x14-evk.dts,
On Fri, Jan 26, 2018 at 09:23:50AM +0100, Lothar Waßmann wrote:
> UART8 on i.MX6ULL is not located on the SPBA bus like on i.MX6UL but
> on the (otherwise unused) AIPS-3 bus.
> Create the appropriate AIPS-3 bus configuration and move the uart8
> definition where it belongs.
>
> Signed-off-by: Loth
On Fri, Jan 26, 2018 at 3:39 AM, Rob Landley wrote:
> The problem with 1 second timestamps was you honestly could confuse
> "make" about which file was newer once an exec() could complete in the
> same second having done real work. That was the motivating issue causing
> the change, going to nano
On Fri, Jan 26, 2018 at 09:23:51AM +0100, Lothar Waßmann wrote:
> The address space taken by the UART8 on the i.MX6UL is used for the
> ESAI interface on i.MX6ULL.
>
> Since the ESAI unit on i.MX6ULL has two more bits in the TFCR register
> (TFIN, TAENB) it deserves to get its own compatible strin
On Fri, Jan 26, 2018 at 09:23:52AM +0100, Lothar Waßmann wrote:
> The i.MX6ULL doesn't have the CAAM engine nor any SIM interface.
> These are currently not implemented for i.MX6UL but it cannot hurt to
> delete the corresponding nodes from the i.MX6ULL DTB anyway.
>
> Signed-off-by: Lothar Waßman
On Wed, Jan 24, 2018 at 10:22:13AM +, Will Deacon wrote:
> On Wed, Jan 24, 2018 at 12:05:16PM +0300, Yury Norov wrote:
> > This series adds API for 128-bit memory IO access and enables it for ARM64.
> > The original motivation for 128-bit API came from new Cavium network device
> > driver. The
From: yuzhoujian
Introduce two new options for perf stat and update perf-stat documentation
accordingly.
The interval-count option can be used to print counts for fixed number of
times, and it should be used specifically with "-I" option.
Show below is the output of the interval-count option fo
From: yuzhoujian
Introduce a new option to print counts after N milliseconds
and update perf-stat documentation accordingly.
Show below is the output of the new option for perf stat.
$ perf stat --time 2000 -e cycles -a
Performance counter stats for 'system wide':
From: yuzhoujian
Introduce a new option to print counts for fixed number of times
and update perf-stat documentation accordingly.
Show below is the output of the new option for perf stat.
$ perf stat -I 1000 --interval-count 2 -e cycles -a
# time counts uni
After checking all possible call chains to bcma_pmu_resources_init() here,
my tool finds that this function is never called in atomic context,
namely never in an interrupt handler or holding a spinlock.
Thus mdelay can be replaced with usleep_range to avoid busy wait.
This is found by a static ana
On Thu 2018-01-25 23:27:57, Jason Baron wrote:
> On 01/25/2018 11:02 AM, Petr Mladek wrote:
> > From: Jason Baron
> > A better solution would be to create cumulative patch and say that
> > it replaces all older ones.
> >
> > Signed-off-by: Jason Baron
> > [pmla...@suse.com: Split, reuse existing
On Thu, 2018-01-25 at 18:23 -0800, Dave Hansen wrote:
> On 01/25/2018 06:11 PM, Liran Alon wrote:
> >
> > It is true that attacker cannot speculate to a kernel-address, but it
> > doesn't mean it cannot use the leaked kernel-address together with
> > another unrelated vulnerability to build a reli
This reverts commit 4aea7a5c5e940c1723add439f4088844cd26196d.
We keep the fix for the first part of the problem (1) described in the log
of that commit however we use the implementation of e1000_msix_other() from
before commit 16ecba59bc33 ("e1000e: Do not read ICR in Other interrupt").
We remove
This reverts commit 16ecba59bc333d6282ee057fb02339f77a880beb.
It was reported that emulated e1000e devices in vmware esxi 6.5 Build
7526125 do not link up after commit 4aea7a5c5e94 ("e1000e: Avoid receiver
overrun interrupt bursts"). Some tracing shows that after
e1000e_trigger_lsc() is called, IC
This reverts commit 19110cfbb34d4af0cdfe14cd243f3b09dc95b013.
This reverts commit 4110e02eb45ea447ec6f5459c9934de0a273fb91.
... because they cause an extra 2s delay for the link to come up when
autoneg is off.
After reverting, the race condition described in the log of commit
19110cfbb34d ("e1000
As discussed in the thread "[RFC PATCH] e1000e: Remove Other from EIAC.",
https://www.spinics.net/lists/netdev/msg479311.html
The following list of commits was considered:
4d432f67ff00 e1000e: Remove unreachable code (v4.5-rc1)
16ecba59bc33 e1000e: Do not read ICR in Other interrupt (v4.5-rc1)
a61
Add a tracepoint in nvme_complete_rq() for completions of NVMe commands. An
expmale output of the trace-point is as follows:
-0 [001] d.h. 3.505266: nvme_complete_rq: cmdid=989, qid=1,
res=0, retries=0, flags=0x0, status=0
Signed-off-by: Johannes Thumshirn
Reviewed-by: Hannes Reinecke
Add tracepoints for nvme_setup_cmd() for tracing admin and/or nvm commands.
Examples of the two tracepoints are as follows for trace_nvme_setup_admin_cmd():
kworker/u8:0-5 [003] 2.998792: nvme_setup_admin_cmd: cmdid=14,
flags=0x0, meta=0x0, cmd=(nvme_admin_create_cq cqid=1, qsize=102
Add tracepoints for nvme command submission and completion. The tracepoints
are modeled after SCSI's trace_scsi_dispatch_cmd_start() and
trace_scsi_dispatch_cmd_done() tracepoints and fulfil a similar purpose,
namely a fast way to check which command is going to be queued into the HW or
Fabric driv
+Rasmus
On Fri, 2018-01-26 at 15:39 +0800, Yang Shunyong wrote:
> Before crng is ready, output of "%p" composes of "(ptrval)" and
> left padding spaces for alignment as no random address can be
> generated. This seems a little strange sometimes.
> For example, when irq domain names are built with
Still gives lots of warnings:
make -j4 C=2 SUBDIRS=drivers/nvme 2>err.log
drivers/nvme/host/./trace.h:78:1: warning: cast to restricted __le64
drivers/nvme/host/./trace.h:78:1: warning: cast to restricted __le64
drivers/nvme/host/./trace.h:78:1: warning: restricted __le64 degrades to integer
drive
On Thu, 2018-01-25 at 17:13 -0800, Stephen Boyd wrote:
> Some qcom platforms make some GPIOs or pins unavailable for use
> by non-secure operating systems, and thus reading or writing the
> registers for those pins will cause access control issues.
> Introduce a DT property to describe the set of G
On Fri, Jan 26, 2018 at 4:03 AM, Baolin Wang wrote:
> The kdb code will print the monotonic time by ktime_get_ts(), but
> the ktime_get_ts() will be protected by a sequence lock, that will
> introduce one deadlock risk if the lock was already held in the
> context from which we entered the debugge
Add i.MX7 temperature monitor support.
Signed-off-by: Anson Huang
Acked-by: Dong Aisheng
---
no changes since V1.
.../devicetree/bindings/thermal/imx-thermal.txt | 5 +++--
arch/arm/boot/dts/imx7s.dtsi | 20
2 files changed, 23 insertions(+), 2
On Fri, Jan 26, 2018 at 6:06 AM, Baolin Wang wrote:
> If we convert one large time values to rtc_time, in the original formula
> 'days * 86400' can be overflowed in 'unsigned int' type to make the formula
> get one incorrect remain seconds value. Thus we can use div_s64_rem()
> function to avoid t
Bin,
I looked to my local git and code does not have this latest line "goto
finish". It was tested without it and everything worked. Right now I
can not get access to that hardware to check with and without. But
only can confirm that without "goto finish" function works with bunch
of drivers (usb
From: yinbo.zhu
Add "configure-gfladj" boolean property to USB3 node. This property
is used to determine whether frame length adjustent is required
or not
Signed-off-by: Ramneek Mehresh
Signed-off-by: Honghua Yin
Signed-off-by: yinbo zhu
---
Change in v2:
Remove the automatic
This patch adds i.MX7 thermal sensor support, most
of the i.MX7 thermal sensor functions are same with
i.MX6 except the registers offset/layout, so we move
those registers offset/layout definitions to soc data
structure.
i.MX7 uses single calibration data @25C, the calibration
data is located at O
On Thu, Jan 25, 2018 at 02:09:40PM -0800, Nadav Amit wrote:
> The PoC apparently does not work with 3GB of memory or more on 32-bit. Does
> you setup has more? Can you try the attack while setting max_addr=1G ?
No, I tested on:
Pentium M (Dothan): 1.5 GB RAM, PAE for NX, 2GB/2GB split
CONFIG_NOH
Le 26/01/2018 à 09:36, Jiri Benc a écrit :
> On Fri, 26 Jan 2018 00:34:51 +0100, Nicolas Dichtel wrote:
>> Why meaningful? The user knows that the answer is like if if was done in
>> another
>> netns. It enables to have only one netlink socket instead of one per netns.
>> But
>> the code using it
* Andy Lutomirski wrote:
> What I'd really like to see is an entirely different API. Maybe:
>
> typedef struct {
> opaque, but probably includes:
> int depth; /* 0 is root */
> void *table;
> } ptbl_ptr;
>
> ptbl_ptr root_table = mm_root_ptbl(mm);
>
> set_ptbl_entry(root_table, pa, pro
Hi Jianchao,
On Fri, Jan 19, 2018 at 11:05:35AM +0800, jianchao.wang wrote:
> Hi ming
>
> Sorry for delayed report this.
>
> On 01/17/2018 05:57 PM, Ming Lei wrote:
> > 2) hctx->next_cpu can become offline from online before
> > __blk_mq_run_hw_queue
> > is run, there isn't warning, but once th
After checking all possible call chains to aoenet_rcv(),
my tool finds that aoenet_rcv() is never called in atomic context,
namely never in an interrupt handler or holding a spinlock.
Thus GFP_ATOMIC is not necessary, and it can be replaced with GFP_KERNEL.
This is found by a static analysis tool
On Thu, Jan 25, 2018 at 11:37:40AM -0700, Shuah Khan wrote:
> As I started backporting security fixes, I found a deadlock bug that was
> fixed in a later release. This patch series contains backports for all
> these problems.
All now queued up, thanks for the backports.
greg k-h
The efer_reload is never used since
commit 26bb0981b3ff ("KVM: VMX: Use shared msr infrastructure"),
so remove it.
Signed-off-by: Longpeng(Mike)
---
arch/x86/include/asm/kvm_host.h | 1 -
arch/x86/kvm/x86.c | 1 -
2 files changed, 2 deletions(-)
diff --git a/arch/x86/include/asm/kv
On Thu, Jan 25, 2018 at 11:35:11AM -0500, Paolo Bonzini wrote:
>
> > > Just wanted stable maintainers to note that Jim, Paolo & myself decided
> > > eventually to revert this commit along with commit ae1f57670703 on
> > > upstream KVM. However, it is true that this commit makes commit
> > > ae1f57
On Thu, 2018-01-25 at 17:13 -0800, Stephen Boyd wrote:
> Some qcom platforms make some GPIOs or pins unavailable for use
> by non-secure operating systems, and thus reading or writing the
> registers for those pins will cause access control issues. Add
> support for a DT property to describe the s
From: Colin Ian King
Trivial fix to spelling mistakes in pr_debug message text.
Signed-off-by: Colin Ian King
---
tools/perf/util/bpf-loader.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/perf/util/bpf-loader.c b/tools/perf/util/bpf-loader.c
index 72c107fcbc5a..806
* David Woodhouse wrote:
> On Thu, 2018-01-25 at 12:34 +0100, Thomas Gleixner wrote:
> >
> > This stuff is really a master piece of trainwreck engineering.
> >
> > So yeah, whatever we do we end up with a proper mess. Lets go for a
> > blacklist and hope that we'll have something which holds a
On 26 January 2018 at 10:17, Andy Shevchenko
wrote:
> +Rasmus
Thanks.
> On Fri, 2018-01-26 at 15:39 +0800, Yang Shunyong wrote:
>> Before crng is ready, output of "%p" composes of "(ptrval)" and
>> left padding spaces for alignment as no random address can be
>> generated. This seems a little st
Hi Robin,
Thanks for your reply.
On 01/24/2018 09:49 PM, Robin Murphy wrote:
+Optional properties:
+- clocks : A list of master clocks requires for the IOMMU to be
accessible
s/requires/required/
ok
+ by the host CPU. The number of clocks depends on the master
+ block
On martedì 23 gennaio 2018 16:18:24 CET Marco Martin wrote:
> Some laptops such as Dell Inspiron 7000 series have the
> tablet mode switch implemented in Intel ACPI,
> the events to enter and exit the tablet mode are 0xCC and 0xCD
>
> CC: platform-driver-...@vger.kernel.org
> CC: Matthew Garrett
On Wed, 24 Jan 2018, Meghana Madhyastha wrote:
> Add of_find_backlight, a helper function which is a generic version
> of tinydrm_of_find_backlight that can be used by other drivers to avoid
> repetition of code and simplify things.
>
> Acked-by: Daniel Thompson
> Reviewed-by: Noralf Trønnes
>
On Fri, Jan 19, 2018 at 10:58 AM, Rajneesh Bhardwaj
wrote:
> From: Srinivas Pandruvada
>
> Export lpit_read_residency_count_address(), so that it can be used from
> drivers built as module. With the recent changes, the builtin_pci
> functionality of the intel_pmc_core driver is removed and now it
On Tue, 2018-01-23 at 16:25 +0100, Peter Zijlstra wrote:
>
> + if (insn->type != INSN_JUMP_DYNAMIC &&
> + insn->type != INSN_CALL_DYNAMIC) {
> + WARN_FUNC("retpoline_safe hint not a indirect
> jump/call",
> + in
Hi Brian,
And a big thanks for your Tested-by
On 01/25/2018 11:47 PM, Brian Norris wrote:
> On Thu, Jan 25, 2018 at 7:55 AM, Philippe Cornu wrote:
>> The "adjusted_mode" clock value (ie the real pixel clock) is more
>> accurate than "mode" clock value (ie the panel/bridge requested
>> clock value
On Thu, 2018-01-25 at 12:35 +0100, Peter Zijlstra wrote:
> On Thu, Jan 25, 2018 at 10:52:53AM +, David Woodhouse wrote:
> >
> > OK, my brain hurts a bit but I'm happy now. Thank you.
> OK, I've updated the Changelog thusly. Is this satisfactory?
>
> ---
> Subject: x86/paravirt: Annotate indir
On Thu, Jan 25, 2018 at 05:56:02PM +, Suzuki K Poulose wrote:
> On 25/01/18 17:33, Dave Martin wrote:
> >On Tue, Jan 23, 2018 at 12:27:57PM +, Suzuki K Poulose wrote:
> >>We use arm64_cpu_capabilities to represent CPU ELF HWCAPs exposed
> >>to the userspace and the CPU hwcaps used by the ke
On Thu 25-01-18 15:27:29, David Rientjes wrote:
> On Thu, 25 Jan 2018, Michal Hocko wrote:
>
> > > As a result, this would remove patch 3/4 from the series. Do you have
> > > any
> > > other feedback regarding the remainder of this patch series before I
> > > rebase it?
> >
> > Yes, and I hav
On Fri 26-01-18 12:12:00, Tetsuo Handa wrote:
> Would you answer to Michal's questions
>
> Is this a permanent state or does the holder eventually releases the lock?
>
> Do you remember the last good kernel?
>
> and my guess
>
> Since commit 0bcac06f27d75285 was not backported to 4.14-sta
On Tue, Jan 23, 2018 at 12:27:58PM +, Suzuki K Poulose wrote:
> Add two different flags to indicate if the conflict of a capability
> on a late CPU with the current system state
>
> 1) Can a CPU have a capability when the system doesn't have it ?
>
> Most arm64 features could have this s
Hello Dmitry,
Le Tue, 23 Jan 2018 09:58:29 -0800,
Dmitry Torokhov a écrit :
> On Tue, Jan 23, 2018 at 10:10:55AM +0100, Mylene Josserand wrote:
> > Hello Dimitry,
> >
> > Thank you for the review!
> >
> > Le Mon, 22 Jan 2018 09:42:08 -0800,
> > Dmitry Torokhov a écrit :
> >
> > > Hi Mylène
On Tue, 2018-01-23 at 16:25 +0100, Peter Zijlstra wrote:
> Annotate the indirect calls/jumps in the CALL_NOSPEC/JUMP_NOSPEC
> alternatives.
>
>
> Signed-off-by: Peter Zijlstra (Intel)
Reviewed-by: David Woodhouse
However...
> /*
> + * This should be used immediately before an indirect jump
After checking all possible call chains to DAC960_DetectController(),
my tool finds that this function is never called in atomic context,
namely never in an interrupt handler or holding a spinlock.
And DAC960_DetectController() calls pci_enable_device that can sleep,
so it indicates that DAC960_
After checking all possible call chains to
DAC960_CreateAuxiliaryStructures(),
my tool finds that this function is never called in atomic context,
namely never in an interrupt handler or holding a spinlock.
And DAC960_CreateAuxiliaryStructures() calls
pci_pool_create() and pci_pool_destroy() that
Add tracepoints for nvme command submission and completion. The tracepoints
are modeled after SCSI's trace_scsi_dispatch_cmd_start() and
trace_scsi_dispatch_cmd_done() tracepoints and fulfil a similar purpose,
namely a fast way to check which command is going to be queued into the HW or
Fabric driv
Add a tracepoint in nvme_complete_rq() for completions of NVMe commands. An
expmale output of the trace-point is as follows:
-0 [001] d.h. 3.505266: nvme_complete_rq: cmdid=989, qid=1,
res=0, retries=0, flags=0x0, status=0
Signed-off-by: Johannes Thumshirn
Reviewed-by: Hannes Reinecke
Add tracepoints for nvme_setup_cmd() for tracing admin and/or nvm commands.
Examples of the two tracepoints are as follows for trace_nvme_setup_admin_cmd():
kworker/u8:0-5 [003] 2.998792: nvme_setup_admin_cmd: cmdid=14,
flags=0x0, meta=0x0, cmd=(nvme_admin_create_cq cqid=1, qsize=102
On Fri 2018-01-19 16:10:42, Jason Baron wrote:
>
>
> On 01/19/2018 02:20 PM, Evgenii Shatokhin wrote:
> > On 12.01.2018 22:55, Jason Baron wrote:
> > There is one more thing that might need attention here. In my
> > experiments with this patch series, I saw that unpatch callbacks are not
> > call
On Tue, 2018-01-23 at 16:25 +0100, Peter Zijlstra wrote:
> The objtool retpoline validation found this indirect jump. Seeing how
> its on CPU bringup before we run userspace it should be safe, annotate
http://angryflower.com/itsits.gif
> it.
>
> Signed-off-by: Peter Zijlstra (Intel)
Reviewed-b
On Fri 2018-01-26 16:38:19, Jia-Ju Bai wrote:
> After checking all possible call chains to genpd_dev_pm_detach() and
> genpd_dev_pm_attach() here,
> my tool finds that these functions are never called in atomic context,
> namely never in an interrupt handler or holding a spinlock.
> Thus mdelay can
On 2018/1/26 18:26, Pavel Machek wrote:
On Fri 2018-01-26 16:38:19, Jia-Ju Bai wrote:
After checking all possible call chains to genpd_dev_pm_detach() and
genpd_dev_pm_attach() here,
my tool finds that these functions are never called in atomic context,
namely never in an interrupt handler or
On Thu, 25 Jan 2018, Rob Landley wrote:
> That said, I don't think -h newcx should emit (or recognize) the
> "TRAILER!!!1!" entry. That's kinda silly in-band signaling for 2018:
> files have a length, pipes provide EOF, and each cpiox entry starts with
> 6 bytes of c_magic anyway. (I stopped toybox
On 25.01.2018 19:02, Petr Mladek wrote:
From: Jason Baron
Sometimes we would like to revert a particular fix. Currently, this
is not easy because we want to keep all other fixes active and we
could revert only the last applied patch.
One solution would be to apply new patch that implemented al
When kernel do early microcode update, code printing only
new microcode version. But in this case we no have chance
to check which version was in cpu from BIOS vendor.
Patch add this info into output message.
Signed-off-by: Petr Oros
---
arch/x86/kernel/cpu/microcode/intel.c | 27 ++
On Tue, 2018-01-23 at 16:25 +0100, Peter Zijlstra wrote:
> This is boot code, we run this _way_ before userspace comes along to
> poison our branch predictor.
Hm, objtool knows about sections, doesn't it? Why it is whining about
indirect jumps in inittext anyway?
In fact, why are we even *doing*
On Fri, Jan 26, 2018 at 11:34:50AM +0100, Petr Oros wrote:
> When kernel do early microcode update, code printing only
> new microcode version. But in this case we no have chance
> to check which version was in cpu from BIOS vendor.
And we need that because?
--
Regards/Gruss,
Boris.
G
On Tue, 2018-01-23 at 16:25 +0100, Peter Zijlstra wrote:
> Implement a jump_label assertion that asserts that the code location
> is indeed only reachable through a static_branch. Because if GCC is
> absolutely retaded it could generate code like:
>
> xor rax,rax
> NOP/JMP 1f
>
From: Harini Katakam
Handle HRESP error by doing a SW reset of RX and TX and
re-initializing the descriptors, RX and TX queue pointers.
Signed-off-by: Harini Katakam
Signed-off-by: Michal Simek
---
v2:
Rebased on top of latest net-next and reinitialized
all rx queues.
drivers/net/ethernet/ca
On Friday 26 January 2018 10:45:55 Marco Martin wrote:
> On martedì 23 gennaio 2018 16:18:24 CET Marco Martin wrote:
> > Some laptops such as Dell Inspiron 7000 series have the
> > tablet mode switch implemented in Intel ACPI,
> > the events to enter and exit the tablet mode are 0xCC and 0xCD
> >
On 2018-01-26 09:31, Chintan Pandya wrote:
> Implement, device-phandle relation in hash-table so
> that look up can be faster, irrespective of where my
> device is defined in the DT.
>
> There are ~6.7k calls to of_find_node_by_phandle() and
> total improvement observed during boot is 400ms.
I'm
1 - 100 of 727 matches
Mail list logo
