On Fri, 2019-05-24 at 20:51 +0200, Greg KH wrote:
> On Sun, Apr 28, 2019 at 09:50:04AM +0800, zhenwei pi wrote:
> > A bug can be easily reproduced:
> > Host# cat guest-agent.xml
> >
> >
> >> state="connected"/>
> >
> > Host# virsh attach-device instance guest-agent.xml
> > Host# virsh
On Mon, May 20, 2019 at 11:10 PM Ondřej Jirman wrote:
>
> On Mon, May 20, 2019 at 05:06:34PM +0200, verejna wrote:
> > From: Ondrej Jirman
> >
> > This is a re-send of Chen-Yu's A83T CSI patch series with review tags
> > applied and removed address/size cells from csi_in port. Already applied
>
Em Mon, May 27, 2019 at 05:46:26PM -0500, Shawn Landden escreveu:
> On Mon, May 27, 2019 at 5:38 PM Arnaldo Carvalho de Melo
> wrote:
> >
> > From: Shawn Landden
> >
> > This strncat() is safe because the buffer was allocated with zalloc(),
> > however gcc doesn't know that. Since the string
On Tue, May 28, 2019 at 10:15:59AM +0900, Chanwoo Choi wrote:
> Cc: sta...@vger.kernel.org
>
> Dear all,
>
> It missed to send this patch to 'sta...@vger.kernel.org'.
> So, I add it to mailing list.
This is not the correct way to submit patches for inclusion in the
stable kernel tree. Please
Larry Finger writes:
> On 5/28/19 6:55 AM, Kalle Valo wrote:
>> Jia-Ju Bai wrote:
>>
>>> *BUG 1:
>>> In rtl_pci_probe(), when rtlpriv->cfg->ops->init_sw_vars() fails,
>>> rtl_deinit_core() in the error handling code is executed.
>>> rtl_deinit_core() calls rtl_free_entries_from_scan_list(),
On Mon, 20 May 2019 at 20:41, Doug Anderson wrote:
>
> Hi,
>
> On Mon, Apr 29, 2019 at 1:41 PM Douglas Anderson
> wrote:
> >
> > Processing SDIO interrupts while dw_mmc is suspended (or partly
> > suspended) seems like a bad idea. We really don't want to be
> > processing them until we've
On Tue, May 28, 2019 at 10:45:13AM +0200, Linus Walleij wrote:
> On Tue, May 28, 2019 at 10:36 AM Guillaume Tucker
> > Not really, so I've disabled bisections in the linux-gpio tree
> > and a few other maintainers' trees for now. I'll see if we can
> > come up with a more systematic way of
Currently, the upper half of a 4-byte STATS_TYPE_PORT statistic ends
up in bits 47:32 of the return value, instead of bits 31:16 as they
should.
Signed-off-by: Rasmus Villemoes
---
I also noticed that it's a bit inconsistent that we return U64_MAX if
there's a read error in STATS_TYPE_PORT,
On Fri, May 10, 2019 at 05:36:32PM +, Eric Wheeler wrote:
> Hi Lars,
>
> We just tried 4.19.x and this bugs still exists. We applied the patch
> which was originally submitted to this thread and it still applies cleanly
> and seems to work for our use case. You mentioned that you had some
Hi,
On 28-05-19 14:47, Young Xiao wrote:
vbg_misc_device_close doesn't check that filp->private_data is non-NULL
before trying to close_session, where vbg_core_close_session uses pointer
session whithout checking, too. That can cause an oops in certain error
conditions that can occur on open or
This patch series brings together patches [1] and [2] which
introduce mclk0 clock source via DT.
mclk0..3 are the four clock sources options
of SAI's clock MUX.
mclk0 option selects:
- Bus Clock on i.MX8
- MCLK1 on i.MX6/7
Finally we also update the DT binding information for SAI clocks.
In
From: Shengjiu Wang
Audio MCLK source option is selected with a 4:1 MUX
controller using MCLK Select bits in SAI xCR2 register.
On imx6/7 mclk0 and mclk1 always point to the same clock
source. Anyhow, this is no longer true for imx8.
For this reason, we need to add mclk0 and handle it
in a
SAI provide multiple master clock source options selectable
via bit MSEL of TCR2/RCR2.
All possible master clock sources are stored in sai->mclk_clk
array. Current implementation assumes that MCLK0 source is always
busclk, but this is wrong!
For example, on i.MX8QM we have:
00b - Bus Clock
SAI might have up to 4 clock sources selected by an internal
CLK mux.
On imx6/7 mclk0/mclk1 are the same, while on imx8 mclk0 and
mclk1 are coming from different sources.
Signed-off-by: Daniel Baluta
---
Documentation/devicetree/bindings/sound/fsl-sai.txt | 5 +++--
1 file changed, 3
On Tue, May 28, 2019 at 10:58:03AM +0500, Mikhail Gavrilov wrote:
> On Mon, 27 May 2019 at 21:16, Mikhail Gavrilov
> wrote:
> >
> > I am bisected issue. I hope it help understand what is happened on my
> > computer.
> >
>
> Why no one answers?
> Even if the problem is known and already fixed, I
On 5/28/19 2:09 AM, Mans Rullgard wrote:
Add support for the nowayout option in the gpio watchdog driver.
Signed-off-by: Mans Rullgard
Reviewed-by: Guenter Roeck
---
drivers/watchdog/gpio_wdt.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/watchdog/gpio_wdt.c
On Tue, May 28, 2019 at 02:20:15AM +, Andy Duan wrote:
> So on i.MX8MM/8QM/8QXP platforms, we catch the issue that user dump regmap
> registers without
> power cause system hang.
> Maybe revert the patch is more reasonable ?
This is an issue with or without a device - you can have the same
On Tue, May 28, 2019 at 03:23:41PM +0530, Keerthy wrote:
> On 22/05/19 9:05 PM, Mark Brown wrote:
> > On Thu, May 16, 2019 at 10:02:18AM +0530, Keerthy wrote:
> > Acked-by: Mark Brown
> This patch will come via the mfd branch?
I'd expect so, IIRC it had a build dependency on the earlier
On Tue, May 21, 2019 at 02:40:50PM -0700, kan.li...@linux.intel.com wrote:
> +static u64 icl_metric_update_event(struct perf_event *event, u64 val)
> +{
> + struct cpu_hw_events *cpuc = this_cpu_ptr(_hw_events);
> + struct hw_perf_event *hwc = >hw;
> + u64 newval, metric, slots_val =
On Tue, May 28, 2019 at 02:56:15PM +0200, Peter Zijlstra wrote:
> On Tue, May 21, 2019 at 02:40:50PM -0700, kan.li...@linux.intel.com wrote:
>
> > diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c
> > index e9075d57853d..07ecfe75f0e6 100644
> > --- a/arch/x86/events/core.c
> > +++
On 5/28/2019 4:56 AM, Peter Zijlstra wrote:
On Mon, May 27, 2019 at 12:07:55PM -0700, kan.li...@linux.intel.com wrote:
diff --git a/arch/x86/include/uapi/asm/perf_regs.h
b/arch/x86/include/uapi/asm/perf_regs.h
index ac67bbe..3a96971 100644
--- a/arch/x86/include/uapi/asm/perf_regs.h
+++
Fix gcc build error while CONFIG_REGMAP_MMIO is not set
drivers/staging/fieldbus/anybuss/arcx-anybus.o: In function `controller_probe':
arcx-anybus.c:(.text+0x9d6): undefined reference to
`__devm_regmap_init_mmio_clk'
Select REGMAP_MMIO to fix it.
Reported-by: Hulk Robot
Fixes: 2411a336c8ce
On 22.05.2019 16:40, Lucas Stach wrote:
> Am Mittwoch, den 22.05.2019, 13:30 + schrieb Leonard Crestez:
>> On 22.05.2019 16:13, Guido Günther wrote:
>>> Subject: Re: [RFC PATCH] soc: imx: Try harder to get imq8mq SoC revisions
>>> On Wed, May 08, 2019 at 02:40:18PM +0200, Guido Günther wrote:
Hi,
On 24-05-19 18:43, Andy Shevchenko wrote:
On Tue, May 21, 2019 at 9:28 AM Hans de Goede wrote:
Commit 78f3ac76d9e5 ("platform/x86: asus-wmi: Tell the EC the OS will
handle the display off hotkey") causes the backlight to be permanently off
on various EeePC laptop models using the
I confess I've kind of lost the plot on the performance requirements
at this point. Instead of measuring and evaluating potential
solutions, can we try to approach this from the opposite direction and
ask what the requirements are?
What's the maximum number of CPU cycles that we are allowed to
On Tue, May 28, 2019 at 06:18:16PM +0530, Amit Daniel Kachhap wrote:
> Hi Dave,
[...]
> >Were you planning to repost this?
> >
> >Alternatively, I can fix up the diagnostic messages discussed here and
> >post it together with the SVE support. I'll do that locally for now,
> >but let me know
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/usb/host/ohci-st.c: In function st_ohci_platform_probe:
drivers/usb/host/ohci-st.c:135:19: warning: variable ohci set but not used
[-Wunused-but-set-variable]
It's never used, so can be removed.
Signed-off-by: YueHaibing
---
On Mon, May 20, 2019 at 01:09:48PM +0800, Weitao Hou wrote:
> fix acccess to access
>
> Signed-off-by: Weitao Hou
> ---
> include/linux/intel-svm.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Applied, thanks.
Hello YueHaibing,
On Tue, May 28, 2019 at 9:33 AM YueHaibing wrote:
>
> Fix gcc build error while CONFIG_REGMAP_MMIO is not set
>
> drivers/staging/fieldbus/anybuss/arcx-anybus.o: In function
> `controller_probe':
> arcx-anybus.c:(.text+0x9d6): undefined reference to
>
Return NULL instead of null-terminating version char array when fgets fails due
to end-of-file or error.
Signed-off-by: Donald Yandt
---
tools/perf/util/machine.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
index
On Tue 2019-05-28 13:46:19, Sergey Senozhatsky wrote:
> On (05/28/19 13:15), Sergey Senozhatsky wrote:
> > On (05/28/19 01:24), Dmitry Safonov wrote:
> > [..]
> > > While handling sysrq the console_loglevel is bumped to default to print
> > > sysrq headers. It's done to print sysrq messages with
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/usb/host/ohci-s3c2410.c: In function s3c2410_hcd_oc:
drivers/usb/host/ohci-s3c2410.c:296:18: warning: variable hcd set but not used
[-Wunused-but-set-variable]
It is never used, so can be removed.
Signed-off-by: YueHaibing
---
On Tue, May 28, 2019 at 02:58:57PM +0200, Paul Kocialkowski wrote:
> Hi,
>
> On Tue, 2019-05-28 at 09:35 +0300, Priit Laes wrote:
> > Lime2 has battery connector so enable these supplies.
>
> Out of curiosity, what is reported to userspace when no battery is
> attached?
Data from
Syzkaller found that it is possible to provoke a memory leak by
never freeing rx_skb in struct bcsp_struct.
Fix by freeing in bcsp_close()
Signed-off-by: Tomas Bortoli
Reported-by: syzbot+98162c885993b72f1...@syzkaller.appspotmail.com
---
drivers/bluetooth/hci_bcsp.c | 4
1 file changed,
On Tue, May 21, 2019 at 02:40:50PM -0700, kan.li...@linux.intel.com wrote:
> @@ -3287,6 +3304,13 @@ static int core_pmu_hw_config(struct perf_event *event)
> return intel_pmu_bts_config(event);
> }
>
> +#define EVENT_CODE(e)(e->attr.config & INTEL_ARCH_EVENT_MASK)
> +#define
On Tue, May 28, 2019 at 01:17:10PM +, Rasmus Villemoes wrote:
> Currently, the upper half of a 4-byte STATS_TYPE_PORT statistic ends
> up in bits 47:32 of the return value, instead of bits 31:16 as they
> should.
>
> Signed-off-by: Rasmus Villemoes
Hi Rasmus
Please include a Fixes tag, to
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/usb/host/ehci-st.c: In function st_ehci_platform_probe:
drivers/usb/host/ehci-st.c:155:19: warning: variable ehci set but not used
[-Wunused-but-set-variable]
It is never used, so can be removed.
Signed-off-by: YueHaibing
---
In order for things like get_user_pages() to work on ZONE_DEVICE memory,
we need a software PTE bit to identify device-backed PFNs. Hook this up
along with the relevant helpers to join in with ARCH_HAS_PTE_DEVMAP.
Signed-off-by: Robin Murphy
---
Fix to build correctly under all combinations of
In case of errors, predicate_parse() goes to the out_free label
to free memory and to return an error code.
However, predicate_parse() does not free the predicates of the
temporary prog_stack array, thence leaking them.
Signed-off-by: Tomas Bortoli
Reported-by:
On Tue, May 21, 2019 at 02:40:50PM -0700, kan.li...@linux.intel.com wrote:
> diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
> index b980b9e95d2a..0d7081434d1d 100644
> --- a/include/linux/perf_event.h
> +++ b/include/linux/perf_event.h
> @@ -133,6 +133,11 @@ struct
On 28.05.19 14:53, Cornelia Huck wrote:
> On Tue, 28 May 2019 13:00:30 +0200
> Christian Borntraeger wrote:
>
>> Paolo, Radim,
>>
>> would you consider this patch (or the full series) as 5.2 material or 5.3
>> material?
>
> FWIW, I'd consider this patch 5.2 material, as we're currently
On Tue 2019-05-28 19:15:43, Tetsuo Handa wrote:
> On 2019/05/28 17:51, Sergey Senozhatsky wrote:
> >> You are trying to omit passing KERN_UNSUPPRESSED by utilizing implicit
> >> printk
> >> context information. But doesn't such attempt resemble
> >> find_printk_buffer() ?
> >
> > Adding
On Tue, May 21, 2019 at 02:40:51PM -0700, kan.li...@linux.intel.com wrote:
> From: Andi Kleen
>
> The topdown metrics and slots events are mapped to a fixed counter,
> but should have the normal weight for the scheduler.
You forgot the 'why/because' part of that sentence.
> So special case
On Tue, May 21, 2019 at 02:40:53PM -0700, kan.li...@linux.intel.com wrote:
> From: Kan Liang
>
> To get correct PERF_METRICS value, the fixed counter 3 must start from
> 0. It would bring problems when sampling read slots and topdown events.
> For example,
> perf record -e '{slots,
On Thu, 2019-05-23 at 18:43 -0500, Gustavo A. R. Silva wrote:
>
> On 5/23/19 6:32 PM, David Miller wrote:
> > From: "Gustavo A. R. Silva"
> > Date: Thu, 23 May 2019 17:36:00 -0500
> >
> > > Hi Dave,
> > >
> > > I wonder if you can take this patch.
> >
> > The sunrpc/nfs maintainer should
On Mon, May 20, 2019 at 02:28:35PM +0300, Leon Romanovsky wrote:
> On Mon, May 20, 2019 at 01:19:02PM +0200, Michal Kubecek wrote:
> > Commit 25c13324d03d ("IB/mlx5: Add steering SW ICM device memory type")
> > breaks i386 build by introducing three 64-bit divisions. As the divisor
> > is
On Tue, May 28, 2019 at 08:31:29PM +0800, Young Xiao wrote:
> When a kthread calls call_usermodehelper() the steps are:
> 1. allocate current->mm
> 2. load_elf_binary()
> 3. populate current->thread.regs
>
> While doing this, interrupts are not disabled. If there is a perf
> interrupt in
On Tue, May 28, 2019 at 09:33:40AM -0400, Liang, Kan wrote:
> Uncore PMU doesn't support sampling. It will return -EINVAL.
> There is no regs support for counting. The request will be ignored.
>
> I think current check for uncore is good enough.
breakpoints then.. There's also no guarantee you
On Mon, May 27, 2019 at 09:20:01AM +0200, Michal Hocko wrote:
> On Wed 22-05-19 17:42:13, Mark Rutland wrote:
> > On Thu, May 16, 2019 at 01:05:29PM +0200, Michal Hocko wrote:
> > > On Thu 16-05-19 11:23:54, Mark Rutland wrote:
> > > > On Wed, May 15, 2019 at 06:58:47PM +0200, Michal Hocko wrote:
On 2019/5/28 21:41, Sven Van Asbroeck wrote:
> Hello YueHaibing,
>
> On Tue, May 28, 2019 at 9:33 AM YueHaibing wrote:
>>
>> Fix gcc build error while CONFIG_REGMAP_MMIO is not set
>>
>> drivers/staging/fieldbus/anybuss/arcx-anybus.o: In function
>> `controller_probe':
>>
On Tue, 28 May 2019, Peter Zijlstra wrote:
> On Tue, May 28, 2019 at 09:33:40AM -0400, Liang, Kan wrote:
> > Uncore PMU doesn't support sampling. It will return -EINVAL.
> > There is no regs support for counting. The request will be ignored.
> >
> > I think current check for uncore is good
On Tue, May 28, 2019 at 3:08 AM Christian Brauner wrote:
>
> On Mon, May 27, 2019 at 12:27:08PM -0700, Linus Torvalds wrote:
> > On Mon, May 27, 2019 at 3:42 AM Christian Brauner
> > wrote:
> > >
> > > Hm, still pondering whether having one unsigned int argument passed
> > > through registers
On Tue, 28 May 2019, Kalle Valo wrote:
> The correct prefix is "p54:", but I can fix that during commit.
Oh, okay, thanks.
> > Index: usb-devel/drivers/net/wireless/intersil/p54/p54usb.c
> > ===
> > ---
On 2019/05/28 22:42, Petr Mladek wrote:
>> Ahh.. OK, now I sort of remember why I gave up on this idea (see [1]
>> at the bottom, when it comes to uv_nmi_dump_state()) - printk_NMI and
>> printk-safe redirections.
>>
>> NMI
>> loglevel = NEW
>> printk ->
On Tue, 28 May 2019, Oliver Neukum wrote:
> Am Donnerstag, den 23.05.2019, 10:01 -0400 schrieb Alan Stern:
> > On Wed, 22 May 2019, Oliver Neukum wrote:
> >
> > > On Mi, 2019-05-22 at 10:56 -0400, Alan Stern wrote:
> > > > On Wed, 22 May 2019, Oliver Neukum wrote:
> > > >
> > > > > I agree with
With gcc 4.1:
drivers/lightnvm/core.c: In function ‘nvm_remove_tgt’:
drivers/lightnvm/core.c:510: warning: ‘t’ is used uninitialized in this
function
Indeed, if no NVM devices have been registered, t will be an
uninitialized pointer, and may be dereferenced later. A call to
On 5/28/2019 10:05 AM, Peter Zijlstra wrote:
On Tue, May 28, 2019 at 09:33:40AM -0400, Liang, Kan wrote:
Uncore PMU doesn't support sampling. It will return -EINVAL.
There is no regs support for counting. The request will be ignored.
I think current check for uncore is good enough.
Use the available IRQ helper functions, most of the functions have
additional helpful side affects like configuring the trigger type of the
IRQ.
Signed-off-by: Charles Keepax
---
Changes since v2:
- Don't consider zero to be a valid IRQ number
Thanks,
Charles
drivers/i2c/i2c-core-acpi.c |
Only set init_irq during i2c_device_new and only handle client->irq on
the probe/remove paths.
Suggested-by: Benjamin Tissoires
Signed-off-by: Charles Keepax
---
No changes since v2.
Thanks,
Charles
drivers/i2c/i2c-core-base.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff
Bring the ACPI path in sync with the device tree path and handle all the
IRQ fetching at probe time. This leaves the only IRQ handling at device
registration time being that which is passed directly through the board
info as either a resource or an actual IRQ number.
Signed-off-by: Charles Keepax
Remove the static from i2c_dev_irq_from _resources so that other parts
of the core code can use this helper function.
Signed-off-by: Charles Keepax
---
No changes since v2.
Thanks,
Charles
drivers/i2c/i2c-core-base.c | 4 ++--
drivers/i2c/i2c-core.h | 2 ++
2 files changed, 4
It makes sense to contain all the ACPI IRQ handling in a single helper
function.
Signed-off-by: Charles Keepax
---
No changes since v2.
Thanks,
Charles
drivers/i2c/i2c-core-acpi.c | 3 +++
drivers/i2c/i2c-core-base.c | 3 ---
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git
In preparation for future refactoring factor out the fetch of the IRQ
into its own helper function.
Signed-off-by: Charles Keepax
---
Changes since v2:
- Don't consider zero to be a valid IRQ number
Thanks,
Charles
drivers/i2c/i2c-core-acpi.c | 33 +
1 file
Alan Stern writes:
> On Tue, 28 May 2019, Kalle Valo wrote:
>
>> The correct prefix is "p54:", but I can fix that during commit.
>
> Oh, okay, thanks.
>
>> > Index: usb-devel/drivers/net/wireless/intersil/p54/p54usb.c
>> > ===
>> >
On 5/22/19 1:08 PM, Prarit Bhargava wrote:
>
>
> On 5/13/19 10:37 AM, Barret Rhoden wrote:
>> Hi -
>>
>
> Hey Barret, my apologies for not getting back to you earlier. I got caught up
> in something that took me away from this issue.
>
>> On 5/13/19 7:23 AM, Prarit Bhargava wrote:
>>
Fix gcc build error while CONFIG_REGMAP_MMIO is not set
drivers/staging/fieldbus/anybuss/arcx-anybus.o: In function `controller_probe':
arcx-anybus.c: undefined reference to `__devm_regmap_init_mmio_clk'
Select REGMAP_MMIO to fix it.
Reported-by: Hulk Robot
Fixes: 2411a336c8ce ("staging:
On Tue, May 28, 2019 at 10:31 AM YueHaibing wrote:
>
> Fix gcc build error while CONFIG_REGMAP_MMIO is not set
>
checkpatch.pl errors remain:
$ ./scripts/checkpatch.pl < ~/Downloads/YueHaibing.eml
ERROR: DOS line endings
#92: FILE: drivers/staging/fieldbus/anybuss/Kconfig:17:
+^Iselect
Sorry, this is broken, Pls igore this.
On 2019/5/28 22:29, YueHaibing wrote:
> Fix gcc build error while CONFIG_REGMAP_MMIO is not set
>
> drivers/staging/fieldbus/anybuss/arcx-anybus.o: In function
> `controller_probe':
> arcx-anybus.c: undefined reference to `__devm_regmap_init_mmio_clk'
>
>
Hi, Yang,
On 28.05.2019 15:44, Yang Shi wrote:
> Currently THP deferred split shrinker is not memcg aware, this may cause
> premature OOM with some configuration. For example the below test would
> run into premature OOM easily:
>
> $ cgcreate -g memory:thp
> $ echo 4G >
On Wed, May 22, 2019 at 05:03:23PM -0700, Matt Helsley wrote:
> This series cleans up recordmcount and then makes it into
> an objtool subcommand.
>
> The series starts with 8 cleanup patches which make recordmcount
> easier to review and integrate with objtool. The final 5 patches
> show the
On Tue, 28 May 2019 15:46:59 +0200
Tomas Bortoli wrote:
> In case of errors, predicate_parse() goes to the out_free label
> to free memory and to return an error code.
>
> However, predicate_parse() does not free the predicates of the
> temporary prog_stack array, thence leaking them.
>
>
>
On Mon, May 20, 2019 at 02:28:35PM +0300, Leon Romanovsky wrote:
> > On Mon, May 20, 2019 at 01:19:02PM +0200, Michal Kubecek wrote:
> > > Commit 25c13324d03d ("IB/mlx5: Add steering SW ICM device memory
type")
> > > breaks i386 build by introducing three 64-bit divisions. As the
Hi,
On Tue, May 28, 2019 at 6:12 AM Ulf Hansson wrote:
>
> On Mon, 20 May 2019 at 20:41, Doug Anderson wrote:
> >
> > Hi,
> >
> > On Mon, Apr 29, 2019 at 1:41 PM Douglas Anderson
> > wrote:
> > >
> > > Processing SDIO interrupts while dw_mmc is suspended (or partly
> > > suspended) seems like
+++ Prarit Bhargava [28/05/19 10:30 -0400]:
On 5/22/19 1:08 PM, Prarit Bhargava wrote:
On 5/13/19 10:37 AM, Barret Rhoden wrote:
Hi -
Hey Barret, my apologies for not getting back to you earlier. I got caught up
in something that took me away from this issue.
On 5/13/19 7:23 AM,
Based on your explanation, file->private_data can not be NULL before
call vbg_core_close_session method all the time, since
file->private_data is always set.
Am I right?
On Tue, May 28, 2019 at 9:19 PM Hans de Goede wrote:
>
> Hi,
>
> On 28-05-19 14:47, Young Xiao wrote:
> >
On Tue, 28 May 2019 09:43:28 -0500
Josh Poimboeuf wrote:
> Thanks for the patches. This looks like a good step in the right
> direction.
Good to hear.
>
> What's the performance difference between the old recordmcount and the
> new version which relies on elf_open()? It would be useful to
Good day,
On Tue, May 28, 2019 at 01:19:24PM +0800, Leo Yan wrote:
> Hi Suzuki,
>
> On Wed, May 22, 2019 at 11:34:33AM +0100, Suzuki K Poulose wrote:
> > This series adds the support for CoreSight devices on ACPI based
> > platforms. The device connections are encoded as _DSD graph property[0],
Hi,
On 28-05-19 16:49, Yang Xiao wrote:
Based on your explanation, file->private_data can not be NULL before
call vbg_core_close_session method all the time, since
file->private_data is always set.
Am I right?
Yes.
Regards,
Hans
On Tue, May 28, 2019 at 9:19 PM Hans de Goede wrote:
On Wed, May 22, 2019 at 05:03:33PM -0700, Matt Helsley wrote:
> Rather than a standalone executable merge recordmcount as a sub
> command of objtool. This is a small step towards cleaning up
> recordmcount and eventually saving ELF code with objtool.
>
> For the initial step all that's required
On Mon, May 27, 2019 at 03:37:20PM +0100, Catalin Marinas wrote:
> On Mon, May 06, 2019 at 06:30:51PM +0200, Andrey Konovalov wrote:
> > This patch is a part of a series that extends arm64 kernel ABI to allow to
> > pass tagged user pointers (with the top byte set to something else other
> > than
On Tue, May 28, 2019 at 1:42 AM Michal Hocko wrote:
>
> On Tue 28-05-19 11:04:46, Konstantin Khlebnikov wrote:
> > On 28.05.2019 10:38, Michal Hocko wrote:
> [...]
> > > Could you define the exact semantic? Ideally something for the manual
> > > page please?
> > >
> >
> > Like kswapd which works
In order to subsequently add more tests for the arm64 architecture
we compile the tests target for arm64 systematically.
Signed-off-by: Raphael Gault
---
tools/perf/arch/arm64/Build | 2 +-
tools/perf/arch/arm64/tests/Build | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff
The perf user-space tool relies on the PMU to monitor events. It offers an
abstraction layer over the hardware counters since the underlying
implementation is cpu-dependent. We want to allow userspace tools to have
access to the registers storing the hardware counters' values directly.
This
Add a documentation file to describe the access to the pmu hardware
counters from userspace
Signed-off-by: Raphael Gault
---
.../arm64/pmu_counter_user_access.txt | 42 +++
1 file changed, 42 insertions(+)
create mode 100644
This test relies on the fact that the PMU registers are accessible
from userspace. It then uses the perf_event_mmap_page to retrieve
the counter index and access the underlying register.
This test uses sched_setaffinity(2) in order to run on all CPU and thus
check the behaviour of the PMU of all
In order to be able to access the counter directly for userspace,
we need to provide the index of the counter using the userpage.
We thus need to override the event_idx function to retrieve and
convert the perf_event index to armv8 hardware index.
Since the arm_pmu driver can be used by any
In order to prevent the userspace processes which are trying to access
the registers from the pmu registers on a big.LITTLE environment we
introduce a hook to handle undefined instructions.
The goal here is to prevent the process to be interrupted by a signal
when the error is caused by the task
On Tue 2019-05-28 23:21:17, Tetsuo Handa wrote:
> On 2019/05/28 22:42, Petr Mladek wrote:
> >> Ahh.. OK, now I sort of remember why I gave up on this idea (see [1]
> >> at the bottom, when it comes to uv_nmi_dump_state()) - printk_NMI and
> >> printk-safe redirections.
> >>
> >>NMI
> >>
Keep track of event opened with direct access to the hardware counters
and modify permissions while they are open.
The strategy used here is the same which x86 uses: everytime an event
is mapped, the permissions are set if required. The atomic field added
in the mm_context helps keep track of the
Add an extra test to check userspace access to pmu hardware counters.
This test doesn't rely on the seqlock as a synchronisation mechanism but
instead uses the restartable sequences to make sure that the thread is
not interrupted when reading the index of the counter and the associated
pmu
On Sat, May 25, 2019 at 02:51:18PM -0700, Andrew Morton wrote:
> On Fri, 24 May 2019 13:50:45 -0400 Daniel Jordan
> wrote:
>
> > locked_vm accounting is done roughly the same way in five places, so
> > unify them in a helper. Standardize the debug prints, which vary
> > slightly, but include
The patch
ASoC: cx2072x: fix spelling mistake "configued" -> "configured"
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-5.3
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the
The patch
ASoC: cx2072x: remove redundant assignment to pulse_len
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-5.3
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24
The patch
ASoC: cx2072x: fix integer overflow on unsigned int multiply
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-5.3
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the
The patch
regulator: max77620: Support Maxim 77663
has been applied to the regulator tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-5.3
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours)
The patch
ASoC: max98357a: Show KConfig entry
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-5.3
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to
The patch
spi: sh-msiof: Reduce delays in sh_msiof_modify_ctr_wait()
has been applied to the spi tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-5.3
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24
The patch
spi: spi-meson-spifc: update with SPDX Licence identifier
has been applied to the spi tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-5.3
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24
> >> I have been wondering about xmit_more
> >> myself. I don’t think it changes anything for software timestamps,
> >> but it may with hardware timestamps.
> >
> > It arguably makes the software timestamp too early if taken on the
> > first segment, as the NIC is only informed of all the new
Fix two non-critical typos in the documentation of the dl_entity_overflow
function:
- "rather then" --> "rather than";
- "in such way that" --> "in such a way that".
Signed-off-by: Alessio Balsini
---
kernel/sched/deadline.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
501 - 600 of 973 matches
Mail list logo
