On Tue, Feb 12, 2019 at 04:40:10PM +0800, Baolin Wang wrote:
> On Fri, 1 Feb 2019 at 21:05, Mark Brown wrote:
> > You can just list all the individual device names in the of_match_table
> > for the MFD and then it can bind to any of them. You can always map
> > them onto the same behaviour in
TI AM654 SoC has two ADC instances in the MCU domain. Add DT nodes for
the same.
Signed-off-by: Vignesh R
---
Tero,
Could you also pick up DT bindings here:
https://patchwork.kernel.org/patch/10751429/
All the Acks are in place.
arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi | 30
From: Anson Huang
Add i.MX8MQ cpufreq support, current version of
EVK board does NOT support voltage scale, but next
version will add this support, so this driver only
supports cpu frequency scale, voltage scale will
be added later once new board available.
A53 CPU clock normally is from
From: Anson Huang
Register cpu-freq platform driver for i.MX8.
i.MX8MQ has different parts like consumer, industrial and auto etc.,
different parts have different cpufreq set-points, this patch adds
fuse check to select correct cpufreq set-points for each part. The
default dtb has all set-points
On 1/4/19 8:04 PM, Cao jin wrote:
> No real code modification, just cleanup:
> 1. remove redundant comments which have already appeared above
> 2. comments improvement:
> "aligned to a 2M boundary"
> -->
> "aligned up to CONFIG_PHYSICAL_ALIGN boundary"
Finally I see why I have
On Mon, Feb 11, 2019 at 11:30:06AM -0800, ndesaulni...@google.com wrote:
> For arm64:
> 0.34% size improvement with lld -O2 over lld for vmlinux.
> 3.3% size improvement with lld -O2 over lld for Image.lz4-dtb.
The Changelog is utterly failing to explain what it does.
> Link:
Em Mon, Feb 11, 2019 at 11:17:14PM +0300, Alexey Budankov escreveu:
> This is the rebase to the tip of Arnaldo's perf/core repository.
> The patch set implements runtime trace compression for record mode and
> trace file decompression for report mode. Zstandard API [1] is used for
>
On Tue, Feb 12, 2019 at 08:45:35AM +0100, Jan Kara wrote:
> On Mon 11-02-19 09:56:53, Matthew Wilcox wrote:
> > On Mon, Feb 11, 2019 at 06:48:46PM +0100, Jan Kara wrote:
> > > On Mon 11-02-19 13:59:24, Linux Upstream wrote:
> > > > >
> > > > >> Signed-off-by: Chintan Pandya
> > > > >
> > > > >
wt., 12 lut 2019 o 12:14 Lee Jones napisał(a):
>
> On Tue, 12 Feb 2019, Bartosz Golaszewski wrote:
>
> > wt., 12 lut 2019 o 11:18 Lee Jones napisał(a):
> > >
> > > On Tue, 12 Feb 2019, Bartosz Golaszewski wrote:
> > >
> > > > wt., 12 lut 2019 o 10:55 Lee Jones napisał(a):
> > > > >
> > > > > *
Hi Abel,
we really don't want another platform specific cpufreq driver in
mainline. The CPU clock change dance should be abstracted in the
imx8mq-clk driver, just like we do on i.MX5 and i.MX7. This would allow
us to reuse the cpufreq-dt driver, like we do on those platforms.
Regards,
Lucas
Am
Gentle ping...
Best Regards!
Anson Huang
> -Original Message-
> From: Anson Huang
> Sent: 2019年1月23日 16:01
> To: robh...@kernel.org; mark.rutl...@arm.com; shawn...@kernel.org;
> s.ha...@pengutronix.de; ker...@pengutronix.de; feste...@gmail.com;
> Aisheng Dong ; ulf.hans...@linaro.org;
During noirq suspend phase, mailbox MU irq will be masked
but many drivers still need to communicate with system
controller firmware via mailbox, if MU irq is masked, it
will cause RPC timeout as below:
[ 23.372103] imx-scu scu: RPC send msg timeout
Setting MU irq to be wakeup source is NOT
On 19-02-12 10:14:55, Fabio Estevam wrote:
> Hi Abel,
>
> On Tue, Feb 12, 2019 at 10:13 AM Abel Vesa wrote:
> >
> > From: Anson Huang
> >
> > Add i.MX8MQ cpu OPP table info for cpu-freq driver.
>
> Has the imx8m cpufreq driver already been submitted?
I just sent the cpufreq driver along with
On 11 February 2019 at 08:38AM, Christoph Hellwig wrote:
On Sun, Feb 10, 2019 at 01:00:20PM +0100, Christian Zigotzky wrote:
I tested the whole series today. The kernels boot and the P.A. Semi
Ethernet works! :-) Thanks a lot!
I also tested it in a virtual e5500 QEMU machine today.
On Mon, Feb 11, 2019 at 10:30:43AM +0200, Mika Westerberg wrote:
> On Sun, Feb 10, 2019 at 01:13:53PM +0100, Lukas Wunner wrote:
> > If there are two Macs at the ends of the daisy-chain with Thunderbolt
> > devices in-between, the other Mac may already have established tunnels
> > to some of the
On 01. 02. 19 23:08, Jolly Shah wrote:
> The zynqmp power domain driver communicates the usage requirements
> for logical power domains / devices to the platform FW.
> FW is responsible for choosing appropriate power states,
> taking Linux' usage information into account.
>
> v4:
> - Added
On 19-02-12 13:36:39, Lucas Stach wrote:
> Hi Abel,
>
> we really don't want another platform specific cpufreq driver in
> mainline. The CPU clock change dance should be abstracted in the
> imx8mq-clk driver, just like we do on i.MX5 and i.MX7. This would allow
> us to reuse the cpufreq-dt
On 29. 01. 19 21:38, Jolly Shah wrote:
> Add ZynqMP PM driver. PM driver provides power management
> support for ZynqMP.
>
> v6:
> - Rebased on top of
> https://github.com/Xilinx/linux-xlnx/commits/zynqmp/soc
> v5:
> - Added Reviewed tag for dt bindings
>
> v4:
> - Minor fixes to
Hi Abel,
Am Dienstag, den 12.02.2019, 12:21 + schrieb Abel Vesa:
> From: Anson Huang
>
> Register cpu-freq platform driver for i.MX8.
> i.MX8MQ has different parts like consumer, industrial and auto etc.,
> different parts have different cpufreq set-points, this patch adds
> fuse check to
On Mon, Feb 11, 2019 at 11:01:12AM -0800, egran...@chromium.org wrote:
> From: Enrico Granata
>
> ACPI 5 added support for GpioInt resources as a way to provide
> information about interrupts mediated via a GPIO controller.
>
> Several device buses (e.g. SPI, I2C) have support for retrieving
>
On Mon, Feb 11, 2019 at 04:48:17PM -0300, Ezequiel Garcia wrote:
> On Mon, 2019-02-11 at 15:39 +0100, Maxime Ripard wrote:
> > Introduce some basic H264 decoding support in cedrus. So far, only the
> > baseline profile videos have been tested, and some more advanced features
> > used in higher
On Tue, 22 Jan 2019 11:37:04 +0100
Oscar Salvador wrote:
> Hi,
>
> this is the v2 of the first RFC I sent back then in October [1].
> In this new version I tried to reduce the complexity as much as possible,
> plus some clean ups.
>
> [Testing]
>
> I have tested it on "x86_64" (small/big
Hi Maxime,
On Mon, Feb 11, 2019 at 11:39 PM Maxime Ripard
wrote:
>
> Hi,
>
> Here is a new version of the H264 decoding support in the cedrus
> driver.
Thanks for working on this. Please see my comments below.
>
> As you might already know, the cedrus driver relies on the Request
> API, and is
On Tue, Feb 12, 2019 at 01:43:33PM +0100, Lukas Wunner wrote:
> On Mon, Feb 11, 2019 at 10:30:43AM +0200, Mika Westerberg wrote:
> > On Sun, Feb 10, 2019 at 01:13:53PM +0100, Lukas Wunner wrote:
> > > If there are two Macs at the ends of the daisy-chain with Thunderbolt
> > > devices in-between,
We have two enteries (one for M-mode and another for S-mode) in the
interrupts-extended DT property of PLIC DT node for each HART. It is
expected that firmware/bootloader will set M-mode HWIRQ line of each
HART to 0x (i.e. -1) in interrupts-extended DT property
because Linux runs in S-mode
Currently on SMP host, all CPUs take external interrupts routed via
PLIC. All CPUs will try to claim a given external interrupt but only
one of them will succeed while other CPUs would simply resume whatever
they were doing before. This means if we have N CPUs then for every
external interrupt N-1
This patchset primarily adds IRQ affinity support in PLIC driver and
other improvements.
It gives mechanism for explicitly route external interrupts to particular
CPUs using smp_affinity attribute of each Linux IRQs. Also, we can now
use IRQ balancer from kernel-space or user-space.
The patchset
This patch does following optimizations:
1. Pre-compute hart base for each context handler
2. Pre-compute enable base for each context handler
3. Have enable lock for each context handler instead
of global plic_toggle_lock
Signed-off-by: Anup Patel
Reviewed-by: Christoph Hellwig
---
We explicitly differentiate between PLIC handler and context because
PLIC context is for given mode of HART whereas PLIC handler is per-CPU
software construct meant for handling interrupts from a particular
PLIC context.
To achieve this differentiation, we rename "nr_handlers" to "nr_contexts"
On Mon, Feb 11, 2019 at 10:45:58AM +0200, Mika Westerberg wrote:
> On Sun, Feb 10, 2019 at 04:33:28PM +0100, Lukas Wunner wrote:
> > at the bottom of this page there's
> > a figure showing a PCI tunnel between non-adjacent switches (blue line):
> >
> >
On Tue, 12 Feb 2019 at 17:41, Ard Biesheuvel wrote:
>
> On Tue, 12 Feb 2019 at 13:09, Sumit Garg wrote:
> >
> > On Tue, 12 Feb 2019 at 16:35, Ard Biesheuvel
> > wrote:
> > >
> > > On Tue, 29 Jan 2019 at 06:50, Sumit Garg wrote:
> > > >
> > > > This series introduces a generic TEE bus driver
On Tue, Feb 12, 2019 at 02:51:25PM +0200, Mika Westerberg wrote:
> On Tue, Feb 12, 2019 at 01:43:33PM +0100, Lukas Wunner wrote:
> > On Mon, Feb 11, 2019 at 10:30:43AM +0200, Mika Westerberg wrote:
> > > On Sun, Feb 10, 2019 at 01:13:53PM +0100, Lukas Wunner wrote:
> > > > If there are two Macs at
On Fri 2019-02-08 09:11:17, Joe Perches wrote:
> On Fri, 2019-02-08 at 16:23 +0100, Petr Mladek wrote:
> > Move the code from the long pointer() function. We are going to improve
> > error handling that will make it more complicated.
> >
> > This patch does not change the existing behavior.
>
>
On Tue, Feb 12, 2019 at 01:59:27PM +0100, Lukas Wunner wrote:
> On Tue, Feb 12, 2019 at 02:51:25PM +0200, Mika Westerberg wrote:
> > On Tue, Feb 12, 2019 at 01:43:33PM +0100, Lukas Wunner wrote:
> > > On Mon, Feb 11, 2019 at 10:30:43AM +0200, Mika Westerberg wrote:
> > > > On Sun, Feb 10, 2019 at
On Mon, Feb 11, 2019 at 6:29 PM Will Deacon wrote:
> + __iomem pointers obtained with non-default attributes (e.g. those
> returned
> + by ioremap_wc()) are unlikely to provide many of these guarantees. If
> + ordering is required for such mappings, then the mandatory barriers
>
On Tue, 12 Feb 2019, Aubrey Li wrote:
arch/x86/kernel/fpu/xstate.c:1252:6: warning: no previous prototype for
‘avx512_status’ [-Wmissing-prototypes]
void avx512_status(struct seq_file *m, struct task_struct *task)
^
arch/x86/kernel/fpu/xstate.c: In function ‘avx512_status’:
Hi,
Currently pre-caculated set vectors are provided by driver for
allocating & spread vectors. This way only works when drivers passes
same 'max_vecs' and 'min_vecs' to pci_alloc_irq_vectors_affinity(),
also requires driver to retry the allocating & spread.
As Bjorn and Keith mentioned, the
Currently pre-caculated set vectors are provided by driver for
allocating & spread vectors. This way only works when drivers passes
same 'max_vecs' and 'min_vecs' to pci_alloc_irq_vectors_affinity(),
also requires driver to retry the allocating & spread.
As Bjorn and Keith mentioned, the current
Currently the array of irq set vectors is provided by driver.
irq_create_affinity_masks() can be simplied a bit by treating the
non-irq-set case as single irq set.
So move this array into 'struct irq_affinity', and pre-define the max
set number as 4, which should be enough for normal cases.
Now NVMe has implemented the .calc_sets callback for caculating each
set's vectors.
For other cases of multiple irq sets, it isn't a good way to pre-caculate
each set's vectors before allocating IRQ vectors because NVMe's same issue
exists too.
Document .calc_sets as required explicitly for
Hi,
On Mon, Feb 11, 2019 at 04:21:47PM +0100, Hans Verkuil wrote:
> > I think the API should be designed with 4k video in mind. So if some of
> > these constants would be too small when dealing with 4k (even if the
> > current HW doesn't support this yet), then these constants would have to
> >
Currently pre-caculate each set vectors, and this way requires same
'max_vecs' and 'min_vecs' passed to pci_alloc_irq_vectors_affinity(),
then nvme_setup_irqs() has to retry in case of allocation failure.
This usage & interface is a bit awkward because the retry should have
been avoided by
On Mon, Feb 11, 2019 at 11:22:38PM +0300, Alexey Budankov wrote:
SNIP
> +static int perf_mmap__aio_mmap_blocks(struct perf_mmap *map);
> +
> static int perf_mmap__aio_mmap(struct perf_mmap *map, struct mmap_params *mp)
> {
> - int delta_max, i, prio, ret;
> + int i, ret = 0,
On Mon, Feb 11, 2019 at 11:22:38PM +0300, Alexey Budankov wrote:
SNIP
> static int process_synthesized_event(struct perf_tool *tool,
>union perf_event *event,
>struct perf_sample *sample __maybe_unused,
> @@ -543,7 +574,8
On Mon, Feb 11, 2019 at 11:22:38PM +0300, Alexey Budankov wrote:
SNIP
> - if (rec->opts.nr_cblocks > nr_cblocks_max)
> - rec->opts.nr_cblocks = nr_cblocks_max;
> - if (verbose > 0)
> - pr_info("nr_cblocks: %d\n", rec->opts.nr_cblocks);
> + if
On Mon, Feb 11, 2019 at 11:23:40PM +0300, Alexey Budankov wrote:
SNIP
> diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c
> index 18fb9c8cbf9c..5d406eebd058 100644
> --- a/tools/perf/util/session.c
> +++ b/tools/perf/util/session.c
> @@ -29,6 +29,112 @@
> #include "stat.h"
>
On Mon, Feb 11, 2019 at 11:25:00PM +0300, Alexey Budankov wrote:
SNIP
> size_t perf_session__zstd_copy(void *to __maybe_unused,
> @@ -533,6 +646,8 @@ void perf_tool__fill_defaults(struct perf_tool *tool)
> tool->time_conv = process_event_op2_stub;
> if (tool->feature ==
On Mon, Feb 11, 2019 at 11:23:40PM +0300, Alexey Budankov wrote:
SNIP
> @@ -774,6 +775,8 @@ static int record__mmap_read_evlist(struct record *rec,
> struct perf_evlist *evli
> struct perf_mmap *maps;
> int trace_fd = rec->data.file.fd;
> off_t off;
> + struct perf_session
On Tue, Feb 12, 2019 at 10:42:38AM +0800, Jin, Yao wrote:
> > diff --git a/kernel/events/ring_buffer.c b/kernel/events/ring_buffer.c
> > index 4a9937076331..309ef5a64af5 100644
> > --- a/kernel/events/ring_buffer.c
> > +++ b/kernel/events/ring_buffer.c
> > @@ -734,6 +734,9 @@ struct ring_buffer
On Mon, Feb 11, 2019 at 11:22:38PM +0300, Alexey Budankov wrote:
SNIP
> static void record__init_features(struct record *rec)
> @@ -838,6 +881,9 @@ static void record__init_features(struct record *rec)
> if (!(rec->opts.use_clockid && rec->opts.clockid_res_ns))
>
On Mon, Feb 11, 2019 at 11:22:38PM +0300, Alexey Budankov wrote:
SNIP
> diff --git a/tools/perf/util/session.h b/tools/perf/util/session.h
> index d96eccd7d27f..0e14884f28b2 100644
> --- a/tools/perf/util/session.h
> +++ b/tools/perf/util/session.h
> @@ -35,6 +35,8 @@ struct perf_session {
>
On Tue, 12 Feb 2019, Michal Hocko wrote:
> I would go with patch 1 for 5.1. Patches 2 still sounds controversial or
> incomplete to me.
Is it because of the disagreement what 'non-blocking' really means, or do
you see something else missing?
Merging patch just patch 1 withouth patch 2 is
On Mon, Feb 11, 2019 at 11:23:40PM +0300, Alexey Budankov wrote:
SNIP
> + compress_fn = (record__comp_enabled(rec) ?
> + perf_session__zstd_compress : perf_session__zstd_copy);
> +
> if (record__aio_enabled(rec))
> off = record__aio_get_pos(trace_fd);
>
> @@
On Mon, Feb 11, 2019 at 11:25:00PM +0300, Alexey Budankov wrote:
SNIP
> @@ -1932,6 +2059,38 @@ fetch_mmaped_event(struct perf_session *session,
> return event;
> }
>
> +static int __perf_session__process_decomp_events(struct perf_session
> *session)
> +{
> + s64 skip;
> + u64
On Mon, Feb 11, 2019 at 11:22:38PM +0300, Alexey Budankov wrote:
>
> Implement -z,--compression_level= and --mmap-flush=
> options as well as a special PERF_RECORD_COMPRESSED record that contains
> compressed parts of kernel data buffer.
>
> Because compression requires auxilary memory to
On Mon, Feb 11, 2019 at 11:23:40PM +0300, Alexey Budankov wrote:
SNIP
> diff --git a/tools/perf/util/mmap.c b/tools/perf/util/mmap.c
> index 239e9a13c2b7..980784b77fe2 100644
> --- a/tools/perf/util/mmap.c
> +++ b/tools/perf/util/mmap.c
> @@ -156,6 +156,86 @@ void __weak
On Mon, Feb 11, 2019 at 11:23:40PM +0300, Alexey Budankov wrote:
SNIP
> diff --git a/tools/perf/util/mmap.c b/tools/perf/util/mmap.c
> index 239e9a13c2b7..980784b77fe2 100644
> --- a/tools/perf/util/mmap.c
> +++ b/tools/perf/util/mmap.c
> @@ -156,6 +156,86 @@ void __weak
On Mon, Feb 11, 2019 at 11:25:00PM +0300, Alexey Budankov wrote:
>
> PERF_RECORD_COMPRESSED records are decompressed from trace file into
> a linked list of mmaped memory regions using streaming Zstandard API.
> After that the regions are loaded fetching uncompressed events. When
> dumping raw
On Mon, Feb 11, 2019 at 11:25:00PM +0300, Alexey Budankov wrote:
SNIP
> +static int perf_session__process_compressed_event(struct perf_session
> *session,
> + union perf_event *event, u64
> file_offset)
> +{
> + void *src;
> + size_t decomp_size,
On Mon, Feb 11, 2019 at 11:22:38PM +0300, Alexey Budankov wrote:
SNIP
> +static int process_compressed(struct feat_fd *ff,
> + void *data __maybe_unused)
> +{
> + u64 compression_info;
> +
> + if (do_read_u64(ff, _info))
> + return -1;
> +
> +
On Mon, Feb 11, 2019 at 11:23:40PM +0300, Alexey Budankov wrote:
>
> Compression is implemented using simple Zstd API and employs AIO data
> buffer as the memory to operate on. If the API call fails for some
> reason compression falls back to memcpy().
>
> Data chunks are split and packed into
On Mon, Feb 11, 2019 at 11:22:38PM +0300, Alexey Budankov wrote:
SNIP
> @@ -1147,6 +1193,10 @@ static int __cmd_record(struct record *rec, int argc,
> const char **argv)
> fd = perf_data__fd(data);
> rec->session = session;
>
> + rec->opts.comp_level = 0;
> +
On Mon, 11 Feb 2019 at 20:09, Greg Kroah-Hartman
wrote:
>
> This is the start of the stable review cycle for the 4.19.21 release.
> There are 313 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
>
On Tue, Feb 12, 2019 at 12:28 AM Alistair Strachan wrote:
>
> On Mon, Feb 11, 2019 at 9:22 AM Todd Kjos wrote:
> >
> > +Alistair Strachan
> >
> > On Mon, Feb 11, 2019 at 9:11 AM Greg KH wrote:
> > >
> > > On Mon, Feb 11, 2019 at 10:15:18PM +0530, Souptick Joarder wrote:
> > > > On Mon, Feb 11,
Hi Greg,
Please find the pull request for 5.1 merge window below.
It adds two new Armada PHY drivers to support COMPHY and UTMI PHY and a
PHY driver to support Cadence D-PHY. It also extends existing omap-usb2 PHY
driver, qcom-qmp PHY driver and qcom-qusb2 PHY driver to support PHYs in
newer
On Mon, Feb 11, 2019 at 11:09:52AM -0800, Florian Fainelli wrote:
> Hi all,
>
> This patch series finishes by the removal of switchdev_ops. To get there
> we convert the existing switchdev_port_attr_{set,get} switchdev_ops to
> use a blocking notifier, thus making it consistent with how the
From: Bartosz Golaszewski
We already support set_multiple(). Implement get_multiple() as well.
Signed-off-by: Bartosz Golaszewski
---
drivers/gpio/gpio-mockup.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/gpio/gpio-mockup.c b/drivers/gpio/gpio-mockup.c
index
From: Bartosz Golaszewski
User-space tests no longer use it and we're breaking the interface
anyway.
Signed-off-by: Bartosz Golaszewski
---
drivers/gpio/gpio-mockup.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/gpio/gpio-mockup.c
From: Bartosz Golaszewski
This field can never be negative.
Signed-off-by: Bartosz Golaszewski
---
drivers/gpio/gpio-mockup.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpio/gpio-mockup.c b/drivers/gpio/gpio-mockup.c
index 0317917a3678..433adb3b4617 100644
---
From: Bartosz Golaszewski
The unlocked variants only get called from places where we already have
the pointer to the underlying gpio_mockup_chip structure, so take it
as parameter instead of struct gpio_chip.
Signed-off-by: Bartosz Golaszewski
---
drivers/gpio/gpio-mockup.c | 19
From: Bartosz Golaszewski
While no user reported any race condition problems with gpio-mockup,
let's be on the safe side and use a mutex when performing any changes
on the dummy chip structures.
Suggested-by: Uwe Kleine-König
Signed-off-by: Bartosz Golaszewski
---
drivers/gpio/gpio-mockup.c
From: Bartosz Golaszewski
Modify the way the debugfs interface works in gpio-mockup. Introduce
the concept of dummy pull config which will keep the mockup lines in
known state. The pull values can be modified by writing to the debugfs
files corresponding to lines. Lines in input mode always
From: Bartosz Golaszewski
Hi Marc,
this is a trimmed down version of the previous series. All irq_sim patches
from the previous implementation were dropped. The only change in irq_sim now
is addition of the irq_sim_get_type() helper. We store the irq type in the
irq_set_type() callback and
From: Bartosz Golaszewski
Provide a helper that allows users to retrieve the current irq type
of dummy interrupts.
Internally: store the type in the line context when the irq_set_type()
callback is called.
This is required by the gpio-mockup module which wants to track the
state of GPIO lines
Hi Marc,
On 2019/2/10 13:24, Zenghui Yu wrote:
In current logic, its_parse_indirect_baser() will be invoked twice
when allocating Device tables. Add a *break* to omit the unnecessary
and annoying (might be ...) invoking.
Forgot to add:
Fixes: 32bd44dc19de ("irqchip/gic-v3-its: Fix the
Hi João,
First bad commit (maybe != root cause):
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: f17b5f06cb92ef2250513a1e154c47b78df07d40
commit: 78f3ac76d9e5219589718b9e4733bee21627b3f5 platform/x86: asus-wmi: Tell
the EC the OS will handle the
On Tue, 12 Feb 2019, Bartosz Golaszewski wrote:
> wt., 12 lut 2019 o 12:14 Lee Jones napisał(a):
> >
> > On Tue, 12 Feb 2019, Bartosz Golaszewski wrote:
> >
> > > wt., 12 lut 2019 o 11:18 Lee Jones napisał(a):
> > > >
> > > > On Tue, 12 Feb 2019, Bartosz Golaszewski wrote:
> > > >
> > > > >
On 2019/2/12 21:03, Thomas Gleixner wrote:
> On Tue, 12 Feb 2019, Aubrey Li wrote:
>
> arch/x86/kernel/fpu/xstate.c:1252:6: warning: no previous prototype for
> ‘avx512_status’ [-Wmissing-prototypes]
> void avx512_status(struct seq_file *m, struct task_struct *task)
> ^
Sorry
> -Original Message-
> From: Jonathan Cameron
> Sent: 12 February 2019 12:47
> To: Oscar Salvador
> Cc: linux...@kvack.org; mho...@suse.com; dan.j.willi...@intel.com;
> pavel.tatas...@microsoft.com; da...@redhat.com;
> linux-kernel@vger.kernel.org; dave.han...@intel.com; Shameerali
Le 01/02/2019 à 12:51, Christophe Leroy a écrit :
Le 01/02/2019 à 12:10, Michael Ellerman a écrit :
Christophe Leroy writes:
By delaying the setting of MSR_RI, a 1% improvment is optained on
null_syscall selftest on an mpc8321.
Without this patch:
root@vgoippro:~# ./null_syscall
On Mon, Feb 11, 2019 at 02:31:26PM -0500, Waiman Long wrote:
> Modify __down_read_trylock() to make it generate slightly better code
> (smaller and maybe a tiny bit faster).
>
> Before this patch, down_read_trylock:
>
>0x <+0>: callq 0x5
>0x0005 <+5>:
On Tue, 12 Feb 2019, Li, Aubrey wrote:
> On 2019/2/12 21:03, Thomas Gleixner wrote:
> I didn't include the first patch, because I saw it's already in tip
> tree. Did you use tip tree?
Yes, that's my bad, forgot to switch branches. That still does not solve:
> > arch/x86/kernel/fpu/xstate.c: At
On Tue, Feb 12, 2019 at 02:24:04PM +0100, Peter Zijlstra wrote:
> On Mon, Feb 11, 2019 at 02:31:26PM -0500, Waiman Long wrote:
> > Modify __down_read_trylock() to make it generate slightly better code
> > (smaller and maybe a tiny bit faster).
> >
> > Before this patch, down_read_trylock:
> >
>
On Tue, Feb 12, 2019 at 3:43 AM Qian Cai wrote:
>
>
>
> On 2/11/19 4:59 PM, Andrey Konovalov wrote:
> > CONFIG_SLAB_FREELIST_HARDENED hashes freelist pointer with the address
> > of the object where the pointer gets stored. With tag based KASAN we don't
> > account for that when building
On Tue, 12 Feb 2019, Thomas Gleixner wrote:
> On Tue, 12 Feb 2019, Li, Aubrey wrote:
>
> > On 2019/2/12 21:03, Thomas Gleixner wrote:
> > I didn't include the first patch, because I saw it's already in tip
> > tree. Did you use tip tree?
>
> Yes, that's my bad, forgot to switch branches. That
wt., 12 lut 2019 o 12:54 Pavel Machek napisał(a):
>
> Hi!
>
> > diff --git
> > a/Documentation/devicetree/bindings/power/supply/max77650-charger.txt
> > b/Documentation/devicetree/bindings/power/supply/max77650-charger.txt
> > new file mode 100644
> > index ..f3e00d41e299
> > ---
From: Colin Ian King
There are a couple of statements that are indented too deeply, fix
this by removing tabs. Also add a space after a comma to clean up
a cppcheck warning.
Signed-off-by: Colin Ian King
---
drivers/video/fbdev/vesafb.c | 4 ++--
1 file changed, 2 insertions(+), 2
wt., 12 lut 2019 o 13:17 Pavel Machek napisał(a):
>
> Hi!
>
> > + error = device_property_read_string(dev,
> > + "maxim,onkey-mode", _prop);
> > + if (error)
> > + mode_prop = "push";
> > +
> > + if (strcmp(mode_prop, "push") == 0)
>
wt., 12 lut 2019 o 13:07 Pavel Machek napisał(a):
>
> Hi!
>
> > +#define MAX77650_CHARGER_ENABLED BIT(0)
> > +#define MAX77650_CHARGER_DISABLED0x00
> > +#define MAX77650_CHARGER_CHG_EN_MASK BIT(0)
> > +
> > +#define MAX77650_CHARGER_CHG_DTLS_MASK
From: Colin Ian King
The indentation in the if statement is not indented correctly, fix
this with extra level of indentation.
Signed-off-by: Colin Ian King
---
drivers/video/fbdev/savage/savagefb_driver.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git
On Fri 2019-02-08 19:25:18, Andy Shevchenko wrote:
> On Fri, Feb 08, 2019 at 04:23:08PM +0100, Petr Mladek wrote:
> > There are few printk formats that make sense only with two or more
> > specifiers. Also some specifiers make sense only when a kernel feature
> > is enabled.
> >
> > The handling
On Tue, 12 Feb 2019, Ming Lei wrote:
> Currently the array of irq set vectors is provided by driver.
>
> irq_create_affinity_masks() can be simplied a bit by treating the
> non-irq-set case as single irq set.
>
> So move this array into 'struct irq_affinity', and pre-define the max
> set number
On Tue, 12 Feb 2019, Ming Lei wrote:
> Currently pre-caculated set vectors are provided by driver for
> allocating & spread vectors. This way only works when drivers passes
> same 'max_vecs' and 'min_vecs' to pci_alloc_irq_vectors_affinity(),
> also requires driver to retry the allocating &
On Mon, Feb 11, 2019 at 11:16:43AM -0800, Fenghua Yu wrote:
> 4. The feature can be disabled by kernel option
> "clearcpuid=split_lock_detection" during early boot time.
IFF clearcpuid lives, it should also employ CPUID faulting and clear it
for userspace too.
Hi Wen,
On 2/12/19 2:04 PM, Wen Yang wrote:
> Hi Hans, thank you for your comments.
> I will use my company's mailbox and submit a v2 patch to fix these problems
> tomorrow.
I made a bunch of patches fixing this yesterday. It's available here:
> > My other thought is that perhaps sb_start_write() should invoke
> > s_ops->start_write() so that overlay can do the freeze protection on
> > the upper early.
>
> So my understanding of overlayfs is pretty basic so I'm sorry if I miss
> something. If I'm right, we have three superblocks here:
On Tue, Feb 12, 2019 at 3:20 PM kbuild test robot wrote:
>
> Hi João,
>
> First bad commit (maybe != root cause):
Yeah, I barely see how the error below related to the mentioned patch.
>
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> master
> head:
On Tue, 12 Feb 2019, Ming Lei wrote:
> Hi,
>
> Currently pre-caculated set vectors are provided by driver for
> allocating & spread vectors. This way only works when drivers passes
> same 'max_vecs' and 'min_vecs' to pci_alloc_irq_vectors_affinity(),
> also requires driver to retry the
On 2/12/19 8:26 AM, Andrey Konovalov wrote:
> Hm, did you apply all 6 patches (the one that you sent and these five)
Yes.
On Tue, Feb 12, 2019 at 09:33:29AM +0100, Michal Hocko wrote:
> >
> > if (PageHuge(page)) {
> > struct page *head = compound_head(page);
> > - pfn = page_to_pfn(head) + (1< > if (compound_order(head) > PFN_SECTION_SHIFT) {
> >
301 - 400 of 1653 matches
Mail list logo
