On Tue, Feb 19, 2019 at 7:24 AM Vlastimil Babka wrote:
>
> On 2/1/19 6:15 AM, Dan Williams wrote:
> > In preparation for runtime randomization of the zone lists, take all
> > (well, most of) the list_*() functions in the buddy allocator and put
> > them in helper functions. Provide a common contro
> Thanks for the suggestion! So I had a closer look at that driver to try
> and see what could go wrong and it looks like I found a few things
> there.
Hi Paul
Yes, this driver has issues. If i remember correctly, it got merged
while i was on vacation. I pointed out a few issues, but the authors
On Tue, Feb 19, 2019 at 09:05:31AM +0300, Alexey Dobriyan wrote:
> > /proc/kheaders.txz
>
> This is gross.
It is a bit gross, but it solves a long standing problem we have nicely. And
there's also /proc/config.gz.
> > The feature is also buildable as a module just in case the user desires
> > it
On 2/18/19 5:42 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.4.175 release.
There are 143 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.
Responses should be made
On 2/18/19 5:43 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.9.159 release.
There are 58 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.
Responses should be made
On 2/18/19 5:43 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.14.102 release.
There are 62 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.
Responses should be made
On 2/18/19 5:42 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.19.24 release.
There are 85 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.
Responses should be made
Tegra186 does not have master FIFO control register and instead
uses FIFO control register like prior Tegra chipset.
This patch fixes this and prevents crashing during boot when
accessing FIFO control registers.
Acked-by: Thierry Reding
Signed-off-by: Sowjanya Komatineni
---
drivers/i2c/busse
Multi-master support is defeatured on Tegra210 and Tegra186 due to
known bugs.
This patch removes multi-master support for Tegra210 and Tegra186
I2C HW feature.
Acked-by: Thierry Reding
Signed-off-by: Sowjanya Komatineni
---
drivers/i2c/busses/i2c-tegra.c | 4 ++--
1 file changed, 2 insertions
On Tue, 19 Feb 2019, Tony Lindgren wrote:
> Hi,
>
> Adding devicetree list, Julia, Rob and Tomi to Cc.
>
> * Peng Hao [190212 23:11]:
> > of_find_device_by_node() takes a reference to the struct device
> > when it finds a match via get_device.When returning error we should
> > call put_device.
Hi all,
I have been looking at using Linux RT in Dom0. Once the guest is started,
the console is ending to have a lot of warning (see trace below).
After some investigation, this is because the irq handler will now be threaded.
I can reproduce the same error with the vanilla Linux when passing th
On Tue, Feb 19, 2019 at 09:34:56AM -0700, Jason Gunthorpe wrote:
> > - Your real name is formatted incorrectly. It should be like "Yue Haibig"
> > as shown in [1].
> > - If there is no actual regression, this change is useless.
>
> Clarity of the code is a laudible goal - not everything is about
On Tue, 19 Feb 2019, Tony Lindgren wrote:
> Hi,
>
> Adding devicetree list, Julia, Rob and Tomi to Cc.
>
> * Peng Hao [190212 23:11]:
> > of_find_device_by_node() takes a reference to the struct device
> > when it finds a match via get_device.When returning error we should
> > call put_device.
On 02/19, Guenter Roeck wrote:
>
> On Tue, Feb 19, 2019 at 01:37:57PM +0100, Oleg Nesterov wrote:
> >
> > looks unrelated...
> >
>
> Indeed...
>
> The underlying problem is in the error handling code of ace_setup(),
> which calls put_disk() followed by blk_cleanup_queue(). put_disk()
> calls disk_r
On 2/18/19 5:42 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.20.11 release.
There are 92 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.
Responses should be made
> On Feb 19, 2019, at 12:32 PM, Håkon Bugge wrote:
>
>
>
>> On 19 Feb 2019, at 15:58, Chuck Lever wrote:
>>
>> Hey Håkon-
>>
>>> On Feb 18, 2019, at 1:33 PM, Håkon Bugge wrote:
>>>
>>> MAD packet sending/receiving is not properly virtualized in
>>> CX-3. Hence, these are proxied through
Replace Alan Douglas with Tom Joseph as the current PCI
Cadence host/endpoint controller maintainer.
Signed-off-by: Lorenzo Pieralisi
Cc: Bjorn Helgaas
Cc: Tom Joseph
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 32d76a9
On Mon, 18 Feb 2019 19:08:48 +0100
Pierre Morel wrote:
> Libudev relies on having a subsystem link for non-root devices. To
> avoid libudev (and potentially other userspace tools) choking on the
> matrix device let us introduce a vfio_ap bus and with that the vfio_ap
> bus subsytem, and make the
On Tue, Feb 19, 2019 at 05:55:33PM +0100, Vlastimil Babka wrote:
> On 2/14/19 9:38 PM, Andrew Morton wrote:
> > On Thu, 14 Feb 2019 12:45:51 + Peng Fan wrote:
> >
> >> In case cma_init_reserved_mem failed, need to free the memblock allocated
> >> by memblock_reserve or memblock_alloc_range.
>
* Tony Lindgren [190219 17:11]:
> * Lokesh Vutla [190219 16:19]:
> > yes. How different is this from any of the above mentioned drivers using
> > firmware specific ids. Like sci pm domain[1] driver utilizes the same
> > device id for enabling any device in the system. Similarly clock
> > driver[2
* Julia Lawall [190219 17:33]:
> On Tue, 19 Feb 2019, Tony Lindgren wrote:
> > In general, if the device tree node is never used afterwards,
> > should this be just:
> >
> > r = of_platform_populate(node, NULL, NULL, &pdev->dev);
> > of_node_put(dev_node);
> > if (r) {
> >
Le 18/02/2019 à 10:27, Michael Ellerman a écrit :
Christophe Leroy writes:
diff --git a/arch/powerpc/include/asm/ppc_asm.h
b/arch/powerpc/include/asm/ppc_asm.h
index e0637730a8e7..dba2c1038363 100644
--- a/arch/powerpc/include/asm/ppc_asm.h
+++ b/arch/powerpc/include/asm/ppc_asm.h
@@ -251,
On Mon, Feb 18, 2019 at 11:55 PM David Hildenbrand wrote:
>
> On 19.02.19 01:01, Alexander Duyck wrote:
> > On Mon, Feb 18, 2019 at 1:04 PM David Hildenbrand wrote:
> >>
> >> On 18.02.19 21:40, Nitesh Narayan Lal wrote:
> >>> On 2/18/19 3:31 PM, Michael S. Tsirkin wrote:
> On Mon, Feb 18, 20
On 2/18/19 9:26 PM, Hugh Dickins wrote:
I hit the kernel BUG at mm/ksm.c:809! quite easily under KSM swapping
load. That's the BUG_ON(age > 1) in remove_rmap_item_from_tree().
There is a comment above it, but explaining in more detail: KSM saves
effort by not fully maintaining the unstable t
On 19/02/19 16:36, Sean Christopherson wrote:
> On Mon, Feb 18, 2019 at 02:42:00PM +1100, Stephen Rothwell wrote:
>> Hi all,
>
> ...
>
>> Caused by commits
>>
>> 1561fcbc8e16 ("KVM: x86: Explicitly #define the VCPU_REGS_* indices")
>> a46e726511f4 ("KVM: VMX: Move vCPU-run code to a proper as
Clang warns:
drivers/net/wireless/intel/iwlwifi/mvm/ftm-initiator.c:465:2: warning:
comparison of distinct pointer types ('typeof ((rtt_avg)) *' (aka 'long
long *') and 'uint64_t *' (aka 'unsigned long long *'))
[-Wcompare-distinct-pointer-types]
do_div(rtt_avg, );
^~~~
On Mon, 2019-02-18 at 13:57 +, YueHaibing wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> lib/ioremap.c: In function 'ioremap_page_range':
> lib/ioremap.c:203:16: warning:
> variable 'start' set but not used [-Wunused-but-set-variable]
>
> flush_cache_vmap may no need param, so a
From: Lee Duncan
If there is an error queueing an iscsi command in
iscsi_queuecommand(), for example if the transport fails
to take the command in sessuin->tt->xmit_task(), then
the error path can call iscsi_complete_task() without
first aquiring the back_lock as required. This can
lead to things
Dear Friend,
This is a personal e-mail directed to you, and I request that it's
been treated as such. I would like to thank you for giving this
opportunity a chance by welcoming my individual business that i
brought to your way.
And the details should be given to you when confirm the arrival of
t
>>> This essentially just ends up being another trade-off of CPU versus
>>> memory though. Assuming we aren't using THP we are going to take a
>>> penalty in terms of performance but could then free individual pages
>>> less than HUGETLB_PAGE_ORDER, but the CPU utilization is going to be
>>> much h
If there is a error while doing a copy_from_user() for MSM_INFO_SET_NAME
make sure to truncate the object name so that there isn't a chance that
we'll have random data in the string.
This is on top of [1] reported and fixed by Dan Carpenter.
[1] https://patchwork.freedesktop.org/series/56656/
Fi
Whenever a callchain shall be printed search for each address whether
inline information is available and add those symbols to the output
if symbol_conf.inline_name is enabled.
Signed-off-by: Jonas Rabenstein
---
tools/perf/util/evsel_fprintf.c | 46 +
1 file chan
Hi,
sample__fprintf_callchain currently did not use the already available
code to get the symbols of an inlined function if such information is
available in a dso. This patchset adds the required logic to add
appropriate lines.
As I am quite new to the code base of perf I am not sure how to test
t
Split the iteration over the callchain and the actual output of an
link in the callchain into separate functions. This allows to reuse
the output function in a follow up patch to add inline symbols to
the output.
Signed-off-by: Jonas Rabenstein
---
tools/perf/util/evsel_fprintf.c | 111 +
On 12/02/2019 18:02, Catalin Marinas wrote:
> On Mon, Feb 11, 2019 at 12:32:55PM -0800, Evgenii Stepanov wrote:
>> On Mon, Feb 11, 2019 at 9:28 AM Kevin Brodsky wrote:
>>> On 19/12/2018 12:52, Dave Martin wrote:
Really, the kernel should do the expected thing with all "non-weird"
memory.
(Resend since there was a compile error that I forgot to commit before sending)
If there is a error while doing a copy_from_user() for MSM_INFO_SET_NAME
make sure to truncate the object name so that there isn't a chance that
we'll have random data in the string.
This is on top of [1] reported and
On Tue, Feb 19, 2019 at 9:02 AM Arnd Bergmann wrote:
>
> Two saa7146/hexium files contain a construct that causes a warning
> when built with clang:
>
> drivers/media/pci/saa7146/hexium_orion.c:210:12: error: stack frame size of
> 2272 bytes in function 'hexium_probe'
> [-Werror,-Wframe-lar
One of the more common cases of allocation size calculations is finding
the size of a structure that has a zero-sized array at the end, along
with memory for some number of elements for that array. For example:
struct foo {
int stuff;
struct boo entry[];
};
size = sizeof(struct foo) + cou
Am Montag, 18. Februar 2019, 14:34:52 schrieb Sasha Levin:
> On Mon, Feb 18, 2019 at 10:30:44AM -0500, Rik van Riel wrote:
> >On Mon, 2019-02-18 at 14:43 +0100, Greg Kroah-Hartman wrote:
> >> 4.20-stable review patch. If anyone has any objections, please let
> >> me know.
> >>
> >> --
Thanks for the comments, Kan,
>> diff --git a/Documentation/cputopology.txt
>> b/Documentation/cputopology.txt index 287213b4517b..7dd2ae3df233
>> 100644
>> --- a/Documentation/cputopology.txt
>> +++ b/Documentation/cputopology.txt
>> @@ -56,6 +56,16 @@ core_siblings_list:
>> human-readable
On Tue, Feb 19, 2019 at 8:18 AM Steven Rostedt wrote:
>
> > So it would be good to not just say "user or kernel", but actually say
> > what *kind* of kernel access it expects.
>
> Note, kprobes are a different kind of beast. I've used kprobes to probe
> userspace information as well as kernel. Hec
On Mon, Feb 18, 2019 at 06:21:06PM +0100, Martin Schwidefsky wrote:
> On Mon, 18 Feb 2019 18:01:46 +0100
> Martin Schwidefsky wrote:
>
> > On Mon, 18 Feb 2019 07:46:40 -0800
> > Guenter Roeck wrote:
> >
> > > Hi,
> > >
> > > On Thu, Feb 14, 2019 at 03:40:56PM +0100, Martin Schwidefsky wrote:
Hi Cornelia,
On 2/18/19 2:30 PM, Cornelia Huck wrote:
What is your qemu command line ?
Ignoring any additional devices:
s390x-softmmu/qemu-system-s390x -M s390-ccw-virtio,accel=tcg -cpu max -m 1024 -nographic
-device virtio-scsi-ccw,id=scsi0,devno=fe.0.0001 -drive
file=/home/cohuck/vm-ima
Currently the IOMMU code calls pm_runtime_get/put on the GPU or display
device before doing a IOMMU operation. This was because usually the
IOMMU driver didn't do power control of its own and since the hardware
used the same clocks and power as the respective multimedia device it
was a easy way to
On 15/02/2019 23:55, Tony Krowiak wrote:
On 2/14/19 8:51 AM, Pierre Morel wrote:
To be able to use the VFIO interface to facilitate the
mediated device memory pining/unpining we need to register
a notifier for IOMMU.
Signed-off-by: Pierre Morel
---
drivers/s390/crypto/vfio_ap_ops.c | 64
On 2/19/19 4:16 AM, Jonas Gorski wrote:
> BCM63XX (MIPS) does not use device tree, so there cannot be any
> of_device_id, causing the driver to fail on probe:
>
> [0.904564] bcm2835-rng: probe of bcm63xx-rng failed with error -22
>
> Fix this by checking for match data only if we are probing
Hi,
On top of previous pull request.
Best regards,
Krzysztof
The following changes since commit ec33745bccc8f336957c751f4153421cc9ef5a54:
ARM: dts: exynos: Fix pinctrl definition for eMMC RTSN line on Odroid X2/U3
(2019-01-25 20:18:10 +0100)
are available in the Git repository at:
https
On 2/18/19 1:08 PM, Pierre Morel wrote:
Libudev relies on having a subsystem link for non-root devices. To
avoid libudev (and potentially other userspace tools) choking on the
matrix device let us introduce a vfio_ap bus and with that the vfio_ap
bus subsytem, and make the matrix device reside wi
One of the more common cases of allocation size calculations is finding
the size of a structure that has a zero-sized array at the end, along
with memory for some number of elements for that array. For example:
struct foo {
int stuff;
struct boo entry[];
};
size = sizeof(struct foo) + cou
Hi Tetsuo,
On Mon, Feb 18, 2019 at 07:09:23PM +0900, Tetsuo Handa wrote:
> syzbot is hitting use-after-free bug in uinput module [1]. This is because
> kobject_uevent(KOBJ_REMOVE) is called again due to commit 0f4dafc0563c6c49
> ("Kobject: auto-cleanup on final unref") after memory allocation faul
On Mon, Feb 18, 2019 at 02:12:17PM +, Viorel Suman wrote:
> According to RM SPDIF TXCLK_DF mask is 7-bit wide.
>
> Signed-off-by: Viorel Suman
Acked-by: Nicolin Chen
> ---
> sound/soc/fsl/fsl_spdif.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/sound/soc/fsl/f
From: Thor Thayer
Enable the different ECC blocks by default on Cyclone5
and Arria10.
Signed-off-by: Thor Thayer
---
arch/arm/configs/socfpga_defconfig | 36 ++--
1 file changed, 22 insertions(+), 14 deletions(-)
diff --git a/arch/arm/configs/socfpga_defconfig
From: Thor Thayer
Most users want EDAC support so make it the default.
SOCFPGA SDRAM EDAC reporting was enabled by the parent EDAC
config (CONFIG_ALTERA_EDAC) since initial customers always
wanted SDRAM EDAC enabled.
There are cases where the SDRAM needs to be disabled while
the other block EDAC
From: Thor Thayer
The CONFIG_ALTERA_EDAC flag always enables the SDRAM
EDAC. On the newer architectures, there are cases where
the peripheral EDACs are enabled but SDRAM needs to be
disabled.
This change moves SDRAM functions so they can be contained
inside the conditional CONFIG.
Create new CONF
On Mon, Feb 18, 2019 at 07:10:23PM +0900, Tetsuo Handa wrote:
> Thank you for responding.
>
> On 2019/02/18 6:07, Dmitry Torokhov wrote:
> > The commit tries to send final uevent for objects for which "add" uevent
> > has been sent, but not "remove" event. However in uinput (and general
> > input
On Mon, Feb 18, 2019 at 03:25:00PM +, Viorel Suman wrote:
> According to RM SPDIF STC SYSCLK_DF field is 9-bit wide, values
> being in 0..511 range. Use a proper type to handle sysclk_df.
>
> Signed-off-by: Viorel Suman
Acked-by: Nicolin Chen
> ---
> sound/soc/fsl/fsl_spdif.c | 10 ++-
On Tue, Feb 19, 2019 at 9:02 AM Arnd Bergmann wrote:
>
> Clang-9 makes some different inlining decisions compared to gcc, which
> leads to a warning about a possible stack overflow problem when building
> with CONFIG_KASAN, including when setting asan-stack=0, which avoids
> most other frame overf
On 19/02/2019 10:59, Halil Pasic wrote:
On Fri, 15 Feb 2019 17:55:35 -0500
Tony Krowiak wrote:
On 2/14/19 8:51 AM, Pierre Morel wrote:
To be able to use the VFIO interface to facilitate the
mediated device memory pining/unpining we need to register
a notifier for IOMMU.
Signed-off-by: Pierre
On Tue, 19 Feb 2019 10:43:36 -0800
Linus Torvalds wrote:
> On Tue, Feb 19, 2019 at 8:18 AM Steven Rostedt wrote:
> >
> > > So it would be good to not just say "user or kernel", but actually say
> > > what *kind* of kernel access it expects.
> >
> > Note, kprobes are a different kind of beast
On Tue, Feb 19, 2019 at 10:21 AM Nathan Chancellor
wrote:
>
> Clang warns:
>
> drivers/net/wireless/intel/iwlwifi/mvm/ftm-initiator.c:465:2: warning:
> comparison of distinct pointer types ('typeof ((rtt_avg)) *' (aka 'long
> long *') and 'uint64_t *' (aka 'unsigned long long *'))
> [-Wcompare-dis
Hi Marcel,
On Mon, Feb 18, 2019 at 11:48:21AM +0100, Marcel Holtmann wrote:
> Hi Matthias,
>
> > [initial post: https://lore.kernel.org/patchwork/cover/1028184/]
> >
> > On some systems the Bluetooth Device Address (BD_ADDR) isn't stored
> > on the Bluetooth chip itself. One way to configure the
From: Kuppuswamy Sathyanarayanan
Intel IOMMU responds automatically when receiving page-requests from
a PCIe endpoint and the page-request queue is full and it cannot accept
any more page-requests. When it auto-responds to page-requests with a
success to the endpoint, it automatically responds wi
From: Kuppuswamy Sathyanarayanan
In Intel IOMMU, if the Page Request Queue (PRQ) is full, it will
automatically respond to the device with a success message as a keep
alive. And when sending the success message, IOMMU will include PASID in
the Response Message when the Page Request has a PASID in
From: Kuppuswamy Sathyanarayanan
Return the PRG Response PASID Required bit in the Page Request
Status Register.
As per PCIe spec r4.0, sec 10.5.2.3, if this bit is Set, the device
expects a PASID TLP Prefix on PRG Response Messages when the
corresponding Page Requests had a PASID TLP Prefix. If
From: Kuppuswamy Sathyanarayanan
Return the Page Aligned Request bit in the ATS Capability Register.
As per PCIe spec r4.0, sec 10.5.1.2, if the Page Aligned Request bit is
set, it indicates the Untranslated Addresses generated by the device are
always aligned to a 4096 byte boundary.
An IOMMU
From: Kuppuswamy Sathyanarayanan
As per Intel vt-d specification, Rev 3.0 (section 7.5.1.1, title
"Page Request Descriptor"), Intel IOMMU page request descriptor
only uses bits[63:12] of the Page Address. Hence its required to
enforce that the device will only send page request with
page-aligned
From: Kuppuswamy Sathyanarayanan
As per Intel vt-d specification, Rev 3.0 (section 7.5.1.1, title "Page
Request Descriptor"), Intel IOMMU page request descriptor only uses
bits[63:12] of the page address. Hence Intel IOMMU driver would only
permit devices that advertise they would only send Page
It's reasonable to expect that people turn to the "gpio" debugfs file to
first and foremost learn about the direction and value of a gpio, and
second to that about it's pinconf. So reorder the value so each line
reads:
gpioN: direction value ...
This also makes it consistent with the TLMM pinctrl
On Tue, Feb 19, 2019 at 8:02 PM Nick Desaulniers
wrote:
> On Tue, Feb 19, 2019 at 9:02 AM Arnd Bergmann wrote:
> >
> > Clang-9 makes some different inlining decisions compared to gcc, which
> > leads to a warning about a possible stack overflow problem when building
> > with CONFIG_KASAN, includi
On 16/02/2019 00:11, Tony Krowiak wrote:
On 2/14/19 8:51 AM, Pierre Morel wrote:
We register the AP PQAP instruction hook during the open
of the mediated device. And unregister it on release.
In the AP PQAP instruction hook, if we receive a demand to
enable IRQs,
- we retrieve the vfio_ap_queue
>> @@ -461,7 +463,7 @@ static bool match_llc(struct cpuinfo_x86 *c, struct
>> cpuinfo_x86 *o)
>>*/
>> static bool match_die(struct cpuinfo_x86 *c, struct cpuinfo_x86 *o)
>> {
>> -if (c->>phys_proc_id == o->>phys_proc_id)
>> +if (c->>cpu_die_id == o->>cpu_die_id)
>> ret
On 16/02/2019 00:29, Tony Krowiak wrote:
On 2/14/19 8:51 AM, Pierre Morel wrote:
When the device is remove, we must make sure to
clear the interruption and reset the AP device.
We also need to clear the CRYCB of the guest.
Signed-off-by: Pierre Morel
---
drivers/s390/crypto/vfio_ap_drv.c
A previous change allowed I2C client devices to discover new IRQs upon
reprobe by clearing the IRQ in i2c_device_remove. However, if an IRQ was
assigned in i2c_new_device, that information is lost.
For example, the touchscreen and trackpad devices on a Dell Inspiron laptop
are I2C devices whose IR
Apologies.. This should have been marked v2.
On Tue, Feb 19, 2019 at 11:30 AM Jim Broadus wrote:
>
> A previous change allowed I2C client devices to discover new IRQs upon
> reprobe by clearing the IRQ in i2c_device_remove. However, if an IRQ was
> assigned in i2c_new_device, that information is
On 2/19/2019 1:43 PM, Brown, Len wrote:
Thanks for the comments, Kan,
diff --git a/Documentation/cputopology.txt
b/Documentation/cputopology.txt index 287213b4517b..7dd2ae3df233
100644
--- a/Documentation/cputopology.txt
+++ b/Documentation/cputopology.txt
@@ -56,6 +56,16 @@ core_siblings_li
Em Tue, Feb 19, 2019 at 07:38:08PM +0100, Jonas Rabenstein escreveu:
> Hi,
> sample__fprintf_callchain currently did not use the already available
> code to get the symbols of an inlined function if such information is
> available in a dso. This patchset adds the required logic to add
> appropriate
On 16/02/2019 00:36, Tony Krowiak wrote:
On 2/14/19 8:51 AM, Pierre Morel wrote:
When the device is remove, we must make sure to
clear the interruption and reset the AP device.
...snip...
@@ -74,6 +159,13 @@ static void vfio_ap_queue_dev_remove(struct
ap_device *apdev)
struct vfio_ap_
Thanks Boris.
Ard, Will: An arm question came up below. Any thoughts?
On Tue, 2019-02-19 at 13:48 +0100, Borislav Petkov wrote:
> On Mon, Jan 28, 2019 at 04:34:17PM -0800, Rick Edgecombe wrote:
> > This adds a new flags VM_HAS_SPECIAL_PERMS, for enabling vfree operations
>
> s/This adds/add/ - y
On Tue, Feb 19, 2019 at 4:22 AM Lorenzo Pieralisi
wrote:
>
> On Thu, Feb 14, 2019 at 04:59:04PM -0800, Andrey Smirnov wrote:
>
> [...]
>
> > Lorenzo, can you apply the dwc specific patches that are already
> > reviewed by Gustavo Pimentel from this series, to keep things moving
> > while we are wa
On 18/02/2019 23:42, Cornelia Huck wrote:
On Mon, 18 Feb 2019 19:29:10 +0100
Pierre Morel wrote:
On 15/02/2019 23:02, Tony Krowiak wrote:
On 2/14/19 8:51 AM, Pierre Morel wrote:
+/*
+ * handle_pqap: Handling pqap interception
+ * @vcpu: the vcpu having issue the pqap instruction
+ *
+ * Th
On Tue, Feb 19, 2019 at 1:55 PM Gustavo A. R. Silva
wrote:
>
> One of the more common cases of allocation size calculations is finding
> the size of a structure that has a zero-sized array at the end, along
> with memory for some number of elements for that array. For example:
>
> struct foo {
>
On 2/19/19 6:01 PM, Arnd Bergmann wrote:
> Clang-9 makes some different inlining decisions compared to gcc, which
> leads to a warning about a possible stack overflow problem when building
> with CONFIG_KASAN, including when setting asan-stack=0, which avoids
> most other frame overflow warnings:
>
Hi Stefan,
Thanks for your patch!
On Tue, Feb 19, 2019 at 6:02 PM Stefan Popa wrote:
> From: Michael Hennerich
>
> Some devices like the ADIS16460 IMU require a stall period between
> transfers.
This is not just about the period between transfers (which is handled by
delay_usecs), but about th
On Tue, Feb 19, 2019 at 10:06:35AM -0800, Alexander Duyck wrote:
> > I tend to like an asynchronous reporting approach as discussed in this
> > thread, we would have to see if Nitesh could get it implemented.
>
> I agree it would be great if it could work. However I have concerns
> given that work
On 20/02/19 4:14 AM, Gregory CLEMENT wrote:
> Hi Chris,
>
> On lun., févr. 18 2019, Chris Packham
> wrote:
>
>> Kirkwood has always had the ability to retrieve the local-mac-address
>> from the hardware (usually this was configured by the bootloader). This
>> is particularly useful when dea
In preparation for adding WMI support to MODULE_DEVICE_TABLE() move the
definition of struct wmi_device_id to mod_devicetable.h and inline
guid_string in the struct.
Changing guid_string to an inline char array changes the loop conditions
when looping over an array of struct wmi_device_id. Therefo
The kernel provides the macro MODULE_DEVICE_TABLE() which can help
driver authors to generate the appropriate MODULE_ALIAS() output. The
WMI device type is currently not supported by MODULE_DEVICE_TABLE().
While using MODULE_DEVICE_TABLE() does increase the complexity as well
as spreading out the
WMI drivers can if they have specified an array of struct wmi_device_id
use the MODULE_DEVICE_TABLE() macro to automatically generate the
appropriate MODULE_ALIAS() output. Thus avoiding to keep both the array
of struct wmi_device_id and the MODULE_ALIAS() declaration(s) in sync.
Change driver to
WMI drivers can if they have specified an array of struct wmi_device_id
use the MODULE_DEVICE_TABLE() macro to automatically generate the
appropriate MODULE_ALIAS() output. Thus avoiding to keep both the array
of struct wmi_device_id and the MODULE_ALIAS() declaration(s) in sync.
Change driver to
WMI drivers can if they have specified an array of struct wmi_device_id
use the MODULE_DEVICE_TABLE() macro to automatically generate the
appropriate MODULE_ALIAS() output. Thus avoiding to keep both the array
of struct wmi_device_id and the MODULE_ALIAS() declaration(s) in sync.
Change driver to
From: Kan Liang
There are duplicate codes implemented to support different scopes of
counters. Apply the new concept, "domain", for cstate to reduce the
redundancy.
Add struct cstate_pmus to store the PMU related information. Each
available type needs a dedicated cstate_pmus, which is allocated
The kernel provides the macro MODULE_DEVICE_TABLE() where driver authors
can specify their device type and their array of device_ids and thereby
trigger the generation of the appropriate MODULE_ALIAS() output. This is
opposed to having to specify one MODULE_ALIAS() for each device. The WMI
device t
WMI drivers can if they have specified an array of struct wmi_device_id
use the MODULE_DEVICE_TABLE() macro to automatically generate the
appropriate MODULE_ALIAS() output. Thus avoiding to keep both the array
of struct wmi_device_id and the MODULE_ALIAS() declaration(s) in sync.
Change driver to
From: Kan Liang
CLX-AP has the same uncore counters as SKX, but they are die scope.
Add a bool variable to indicate die scope only uncore counters.
Signed-off-by: Kan Liang
---
arch/x86/events/intel/uncore.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/x86/events/in
From: Kan Liang
CLX-AP has the same RAPL counters as SKX, but they are die scope.
Add clx_ap_rapl_init for CLX-AP.
Add new attr_groups for DIE_DOMAIN.
Signed-off-by: Kan Liang
---
arch/x86/events/intel/rapl.c | 27 ++-
1 file changed, 26 insertions(+), 1 deletion(-)
d
From: Kan Liang
CLX-AP has the same PKG Cstate counters as SKX, but they are die scope.
Add clx_ap_cstates for CLX-AP.
Share the package code with die for now.
Signed-off-by: Kan Liang
---
arch/x86/events/intel/cstate.c | 27 ---
1 file changed, 24 insertions(+), 3 del
From: Kan Liang
The RAPL counters are not package scope only anymore. For example, there
will be die scope RAPL counters on CLX-AP.
Apply "domain" for RAPL, and make it easy to be extended later.
Each type of domain needs a dedicated rapl_pmus. The struct rapl_pmus is
modified accordingly.
- Th
From: Kan Liang
It is useful to aggregate counts per processor die.
Introduce a new option "--per-die" to support per-die aggregation.
The global id for each core has been changed to socket + die id + core
id. The global id for each die is socket + die id.
Add die information for per-core aggr
From: Kan Liang
With the new CPUID.1F, a new level type of processor topology, 'die', is
introduced. The 'die' information in cpu topology should be added in
perf header.
To be compatible with old perf.data, the patch checks the section size
before reading the die information. It never reads dat
From: Kan Liang
Perf supports miscellaneous modules, e.g cstate, RAPL and uncore.
The counters of these modules have different scope of effect than core.
So these modules maintain their own scope information independently.
Actually, the scope of counters among these modules are similar.
It's very
501 - 600 of 1032 matches
Mail list logo
