Documentation of the features of the Software Guard eXtensions used
by the Linux kernel and basic design choices for the core and driver
and functionality.
Signed-off-by: Jarkko Sakkinen
Co-developed-by: Sean Christopherson
Signed-off-by: Sean Christopherson
---
Documentation/index.rst
On Thu, Nov 15, 2018 at 10:38:44AM +0200, Jani Nikula wrote:
>
> Cc: linux-doc
>
> On Wed, 14 Nov 2018, Dan Williams wrote:
> > As presented at the 2018 Linux Plumbers conference [1], the Subsystem
> > Profile is proposed as a way to reduce friction between committers and
> > maintainers and per
On Mon, 29 Oct 2018, Paul Lawrence wrote:
>
> > The snapshot target could be hacked so that it remembers space trimmed
> > with REQ_OP_DISCARD and won't reallocate these blocks.
> >
> > But I suspect that running discard over the whole device would degrade
> > performance more than copying so
On Thu, 15 Nov 2018 23:16:23 +0100
Fernando Ramos wrote:
> This patch unifies the naming of DRM functions for reference counting as
> requested on Documentation/gpu/todo.rst
>
> Signed-off-by: Fernando Ramos
> ---
> drivers/gpu/drm/arc/arcpgu_drv.c | 4 ++--
> drivers/gpu/drm/atmel
Hi,
On 10/25/2018 06:59 AM, Kulkarni, Ganapatrao wrote:
This patch adds a perf driver for the PMU UNCORE devices DDR4 Memory
Controller(DMC) and Level 3 Cache(L3C). Each PMU supports up to 4
counters. All counters lack overflow interrupt and are
sampled periodically.
The patch looks OK overall
On Thu, Nov 15, 2018 at 11:17 PM Fernando Ramos wrote:
> One of the things in the DRM TODO list ("Documentation/gpu/todo.rst") was to
> "switch from reference/unreference to get/put". That's what this patch series
> is
> about.
The series:
Reviewed-by: Linus Walleij
Yours,
Linus Walleij
There are no more places where this (deprecated) function is being used
from, thus it can now be removed.
Signed-off-by: Fernando Ramos
---
include/drm/drm_framebuffer.h | 24
1 file changed, 24 deletions(-)
diff --git a/include/drm/drm_framebuffer.h b/include/drm/drm_f
This entry asked to rename all drm core "*_reference/_unrefence"
functions to "*_get/_put".
Now that this task is complete, we can remove this entry from the TODO
list.
Signed-off-by: Fernando Ramos
---
Documentation/gpu/todo.rst | 17 -
1 file changed, 17 deletions(-)
diff --g
The coccinelle script was used to rename some (deprecated) functions
which no longer exist now.
Signed-off-by: Fernando Ramos
---
scripts/coccinelle/api/drm-get-put.cocci | 78
1 file changed, 78 deletions(-)
delete mode 100644 scripts/coccinelle/api/drm-get-put.cocci
This patch unifies the naming of DRM functions for reference counting as
requested on Documentation/gpu/todo.rst
Signed-off-by: Fernando Ramos
---
drivers/gpu/drm/arc/arcpgu_drv.c | 4 ++--
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 4 ++--
drivers/gpu/drm/etnaviv/etnaviv_drv.c
This patch unifies the naming of DRM functions for reference counting as
requested on Documentation/gpu/todo.rst
Signed-off-by: Fernando Ramos
---
drivers/gpu/drm/bridge/tc358764.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/tc358764.c
b/drivers/gp
There are no more places where this (deprecated) function is being
used from, thus it can now be removed.
Signed-off-by: Fernando Ramos
---
include/drm/drm_connector.h | 24
1 file changed, 24 deletions(-)
diff --git a/include/drm/drm_connector.h b/include/drm/drm_conne
This patch unifies the naming of DRM functions for reference counting as
requested on Documentation/gpu/todo.rst
Signed-off-by: Fernando Ramos
---
drivers/gpu/drm/bochs/bochs_mm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bochs/bochs_mm.c b/drivers/g
There are no more places where this (deprecated) function is being used
from, thus it can now be removed.
Signed-off-by: Fernando Ramos
---
drivers/gpu/drm/drm_drv.c | 13 -
include/drm/drm_drv.h | 1 -
2 files changed, 14 deletions(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/d
Hi all,
One of the things in the DRM TODO list ("Documentation/gpu/todo.rst") was to
"switch from reference/unreference to get/put". That's what this patch series is
about.
In the past year or so most of the functions had already been renamed and only a
few remained, which are the ones I fix here
There are no more places where these (deprecated) functions are being
used from, thus they can now be removed.
Signed-off-by: Fernando Ramos
---
include/drm/drm_gem.h | 50 ---
1 file changed, 50 deletions(-)
diff --git a/include/drm/drm_gem.h b/include/d
On Tue, 13 Nov 2018 14:09:50 +
Vitor Soares wrote:
> This patch series is a proposal for the I3C master driver for Synopsys IP.
> This patch is to be applied on top of I3C subsystem RFC V10 submitted by
> Boris Brezillon.
>
> Supported features:
> Regular CCC commands.
> I3C private tran
On Thu, Nov 15, 2018 at 01:57:31PM +0100, Boris Brezillon wrote:
> What we could do though, is expose I3C devices that do not have a
> driver in kernel space, like spidev does.
Yes, this is much safer and more robust especially if the bus has
enumeration requirements like you're saying it does.
On Thu, 15 Nov 2018 15:25:11 +
vitor wrote:
> Hi Arnd,
>
> On 15/11/18 14:25, Arnd Bergmann wrote:
> > I agree about better not exposing the bus as a /dev/i3c* node, and that we
> > probably do need to expose individual devices in some form to allow
> > writing complete user space drivers th
On Thu, 15 Nov 2018 18:03:47 +
vitor wrote:
> Hi Boris,
>
>
> On 15/11/18 15:28, Boris Brezillon wrote:
> > On Thu, 15 Nov 2018 16:01:37 +0100
> > Wolfram Sang wrote:
> >
> >> Hi Boris,
> >>
> >>> What we could do though, is expose I3C devices that do not have a
> >>> driver in kernel
> -Original Message-
> From: Jani Nikula on Thursday, November 15, 2018 12:39 AM
>
> Cc: linux-doc
>
> On Wed, 14 Nov 2018, Dan Williams wrote:
> > As presented at the 2018 Linux Plumbers conference [1], the Subsystem
> > Profile is proposed as a way to reduce friction between committ
Hi Boris,
On 15/11/18 15:28, Boris Brezillon wrote:
On Thu, 15 Nov 2018 16:01:37 +0100
Wolfram Sang wrote:
Hi Boris,
What we could do though, is expose I3C devices that do not have a
driver in kernel space, like spidev does.
...
Mark, Wolfram, Arnd, Greg, any opinion?
Is there a benefi
On Thu, Nov 15, 2018 at 01:01:17PM +0100, David Hildenbrand wrote:
> Just saying that "I'm not the first to do it, don't hit me with a stick" :)
:-)
> Indeed. And we still have without makedumpfile. I think you are aware of
> this, but I'll explain it just for consistency: PG_hwpoison
No, I appr
> Am 15.11.2018 um 16:47 schrieb Will Deacon :
>
>> On Tue, Nov 13, 2018 at 04:29:06PM +0100, Alexander Graf wrote:
>> I've already stumbled over 2 cases where people got confused about how to
>> disable kpti on AArch64. In both cases, they used existing x86_64 options
>> and just applied that
On 11/15/18 4:54 AM, Angelo Ruocco wrote:
> Hi Jens,
>
> I have rebased the patchset against the for-4.21/block branch, but I
> can't test them properly because the compiling process has an error on
> a different file. In particular:
>
> include/net/xfrm.h:1465:3 error: unknown type 'spruct'
> in
On Tue, Nov 13, 2018 at 04:29:06PM +0100, Alexander Graf wrote:
> I've already stumbled over 2 cases where people got confused about how to
> disable kpti on AArch64. In both cases, they used existing x86_64 options
> and just applied that to an AArch64 system, expecting it to work.
>
> I think it
Hi.
On 15.11.2018 16:33, Angelo Ruocco wrote:
I have realized that I didn't clearly explain my actions. I did do a
rebase, but that is not the cause of the problem I reported. I mean,
this is enough to trigger the issue:
git add remote block [1]
git fetch block
git checkout for-4.21/block
make
On Thu, Nov 15, 2018 at 11:18 PM Maxime Ripard
wrote:
>
> Hi!
>
> On Wed, Nov 14, 2018 at 04:20:33PM +0800, hao_zhang wrote:
> > Initial Allwinner T3 support.
> >
> > Allwinner T3 (sun8i) SoC features a Quad-Core Cortex-A7 ARM CPU, and a
> > Mali400 MP2 GPU from ARM. It is a not-pin-compatible qua
On Thu, 15 Nov 2018 16:01:37 +0100
Wolfram Sang wrote:
> Hi Boris,
>
> > What we could do though, is expose I3C devices that do not have a
> > driver in kernel space, like spidev does.
>
> ...
>
> > Mark, Wolfram, Arnd, Greg, any opinion?
>
> Is there a benefit for having drivers in users
Hi Arnd,
On 15/11/18 14:25, Arnd Bergmann wrote:
I agree about better not exposing the bus as a /dev/i3c* node, and that we
probably do need to expose individual devices in some form to allow
writing complete user space drivers that can do everything a kernel driver
can do.
Can you describe wha
Hi!
On Wed, Nov 14, 2018 at 04:20:33PM +0800, hao_zhang wrote:
> Initial Allwinner T3 support.
>
> Allwinner T3 (sun8i) SoC features a Quad-Core Cortex-A7 ARM CPU, and a
> Mali400 MP2 GPU from ARM. It is a not-pin-compatible quad core sucessor
> of the A20). It's also known as the Allwinner R40 f
Hi,
On 15/11/18 12:57, Boris Brezillon wrote:
+Mark Brown for the question about /dev/spidev
Hi Vitor,
On Thu, 15 Nov 2018 12:14:37 +
vitor wrote:
Hi Boris,
Given the current state of the subsystem I think it might worth start to
think how to expose the devices under /dev.
Thanks for
On Thu, Nov 15, 2018 at 7:01 AM Wolfram Sang wrote:
> > What we could do though, is expose I3C devices that do not have a
> > driver in kernel space, like spidev does.
>
> ...
>
> > Mark, Wolfram, Arnd, Greg, any opinion?
>
> Is there a benefit for having drivers in userspace? My gut feeling is to
Hi Boris,
> What we could do though, is expose I3C devices that do not have a
> driver in kernel space, like spidev does.
...
> Mark, Wolfram, Arnd, Greg, any opinion?
Is there a benefit for having drivers in userspace? My gut feeling is to
encourage people to write kernel drivers. If this is,
On Thu, Nov 15, 2018 at 04:51:09PM +0800, Kenneth Lee wrote:
> On Wed, Nov 14, 2018 at 06:00:17PM +0200, Leon Romanovsky wrote:
> > Date: Wed, 14 Nov 2018 18:00:17 +0200
> > From: Leon Romanovsky
> > To: Kenneth Lee
> > CC: Tim Sell , linux-doc@vger.kernel.org,
> > Alexander Shishkin , Zaibo Xu
On Thu, Nov 15, 2018 at 4:58 AM Boris Brezillon
wrote:
> +Mark Brown for the question about /dev/spidev
> On Thu, 15 Nov 2018 12:14:37 +
> vitor wrote:
> > My initial thoughts are to do the same think as for i2c, expose the
> > buses or the i3c_devices and use ioctl for private transfers.
>
>
On Thu, Nov 15, 2018 at 01:11:02PM +0100, Michal Hocko wrote:
> I am not familiar with kexec to judge this particular patch but we
> cannot simply define any range for these pages (same as for hwpoison
> ones) because they can be almost anywhere in the available memory range.
> Then there can be co
On Wed, Nov 14, 2018 at 8:23 PM, Andrey Konovalov wrote:
> On Wed, Nov 7, 2018 at 5:52 PM, Mark Rutland wrote:
>>> /*
>>> @@ -232,7 +241,7 @@ static inline unsigned long kaslr_offset(void)
>>> #define __is_lm_address(addr)(!!((addr) & BIT(VA_BITS - 1)))
>>>
>>> #define __lm_to_phys(add
On Wed, Nov 14, 2018 at 9:17 PM, Mark Rutland wrote:
> On Wed, Nov 14, 2018 at 09:06:23PM +0100, Andrey Konovalov wrote:
>> On Tue, Nov 13, 2018 at 11:07 PM, Mark Rutland wrote:
>> > On Tue, Nov 13, 2018 at 04:01:27PM +0100, Andrey Konovalov wrote:
>> >> On Thu, Nov 8, 2018 at 1:22 PM, Mark Rutla
+Mark Brown for the question about /dev/spidev
Hi Vitor,
On Thu, 15 Nov 2018 12:14:37 +
vitor wrote:
> Hi Boris,
>
> Given the current state of the subsystem I think it might worth start to
> think how to expose the devices under /dev.
Thanks for starting this discussion. I'm not against
On 15.11.18 13:23, Michal Hocko wrote:
> On Wed 14-11-18 22:17:04, David Hildenbrand wrote:
> [...]
>> diff --git a/kernel/power/snapshot.c b/kernel/power/snapshot.c
>> index b0308a2c6000..01db1d13481a 100644
>> --- a/kernel/power/snapshot.c
>> +++ b/kernel/power/snapshot.c
>> @@ -1222,7 +1222,7 @@
On Wed 14-11-18 22:17:04, David Hildenbrand wrote:
[...]
> diff --git a/kernel/power/snapshot.c b/kernel/power/snapshot.c
> index b0308a2c6000..01db1d13481a 100644
> --- a/kernel/power/snapshot.c
> +++ b/kernel/power/snapshot.c
> @@ -1222,7 +1222,7 @@ static struct page *saveable_highmem_page(struc
[Cc Konstantin - the patch is
http://lkml.kernel.org/r/20181114211704.6381-3-da...@redhat.com]
On Thu 15-11-18 10:21:13, David Hildenbrand wrote:
> On 15.11.18 03:07, Mike Rapoport wrote:
> > On Wed, Nov 14, 2018 at 11:49:15PM +0100, David Hildenbrand wrote:
> >> On 14.11.18 23:23, Matthew Wilcox
Hi Boris,
Given the current state of the subsystem I think it might worth start to
think how to expose the devices under /dev.
My initial thoughts are to do the same think as for i2c, expose the
buses or the i3c_devices and use ioctl for private transfers. Some
direct CCC commands can be sent
On Thu 15-11-18 12:52:13, Borislav Petkov wrote:
> On Thu, Nov 15, 2018 at 12:20:40PM +0100, David Hildenbrand wrote:
> > Sorry to say, but that is the current practice without which
> > makedumpfile would not be able to work at all. (exclude user pages,
> > exclude page cache, exclude buddy pages)
On 15.11.18 12:52, Borislav Petkov wrote:
> On Thu, Nov 15, 2018 at 12:20:40PM +0100, David Hildenbrand wrote:
>> Sorry to say, but that is the current practice without which
>> makedumpfile would not be able to work at all. (exclude user pages,
>> exclude page cache, exclude buddy pages). Let's no
Hi Jens,
I have rebased the patchset against the for-4.21/block branch, but I
can't test them properly because the compiling process has an error on
a different file. In particular:
include/net/xfrm.h:1465:3 error: unknown type 'spruct'
include/net/xfrm.h:1465:30 error: expected ':', ',', ';', '}
On Thu, Nov 15, 2018 at 12:20:40PM +0100, David Hildenbrand wrote:
> Sorry to say, but that is the current practice without which
> makedumpfile would not be able to work at all. (exclude user pages,
> exclude page cache, exclude buddy pages). Let's not reinvent the wheel
> here. This is how dumpin
On 15.11.18 12:10, Borislav Petkov wrote:
> On Thu, Nov 15, 2018 at 02:19:23PM +0800, Dave Young wrote:
>> It would be good to copy some background info from cover letter to the
>> patch description so that we can get better understanding why this is
>> needed now.
>>
>> BTW, Lianbo is working on a
On Thu, Nov 15, 2018 at 02:19:23PM +0800, Dave Young wrote:
> It would be good to copy some background info from cover letter to the
> patch description so that we can get better understanding why this is
> needed now.
>
> BTW, Lianbo is working on a documentation of the vmcoreinfo exported
> fiel
On 15.11.18 10:41, Christoph Hellwig wrote:
> On Tue, Nov 13, 2018 at 04:20:46PM +0100, Alexander Graf wrote:
>> I've already stumbled over 2 cases where people got confused about how to
>> disable kpti on AArch64. In both cases, they used existing x86_64 options
>> and just applied that to an A
On Tue, Nov 13, 2018 at 04:20:46PM +0100, Alexander Graf wrote:
> I've already stumbled over 2 cases where people got confused about how to
> disable kpti on AArch64. In both cases, they used existing x86_64 options
> and just applied that to an AArch64 system, expecting it to work.
>
> I think it
On 15.11.18 07:19, Dave Young wrote:
> Hi David,
>
> On 11/14/18 at 10:17pm, David Hildenbrand wrote:
>> Let's export PG_offline via PAGE_OFFLINE_MAPCOUNT_VALUE, so
>> makedumpfile can directly skip pages that are logically offline and the
>> content therefore stale.
>
> It would be good to copy
On 15.11.18 03:07, Mike Rapoport wrote:
> On Wed, Nov 14, 2018 at 11:49:15PM +0100, David Hildenbrand wrote:
>> On 14.11.18 23:23, Matthew Wilcox wrote:
>>> On Wed, Nov 14, 2018 at 10:17:00PM +0100, David Hildenbrand wrote:
Rename PG_balloon to PG_offline. This is an indicator that the page is
FYI, we really should kill ARCH_SG_CHAIN in its current form.
See my series here, which could use a review or two:
https://lkml.org/lkml/2018/11/9/958
On Tue, 13 Nov 2018, Jani Nikula wrote:
> On Tue, 06 Nov 2018, Jonathan Corbet wrote:
>> On Mon, 5 Nov 2018 09:48:33 +0100
>> Christoph Niedermaier wrote:
>>
>>> A problem was found when EDID data sets for displays other than the
>>> provided samples were generated. The patch series has no effec
On Wed, Nov 14, 2018 at 06:00:17PM +0200, Leon Romanovsky wrote:
> Date: Wed, 14 Nov 2018 18:00:17 +0200
> From: Leon Romanovsky
> To: Kenneth Lee
> CC: Tim Sell , linux-doc@vger.kernel.org,
> Alexander Shishkin , Zaibo Xu
> , zhangfei@foxmail.com, linux...@huawei.com,
> haojian.zhu...@lin
Cc: linux-doc
On Wed, 14 Nov 2018, Dan Williams wrote:
> As presented at the 2018 Linux Plumbers conference [1], the Subsystem
> Profile is proposed as a way to reduce friction between committers and
> maintainers and perhaps encourage conversations amongst maintainers
> about best practice pol
Hi Jon,
On Tue, Nov 6, 2018, Jonathan Corbet wrote:
> This seems reasonable, I guess; I've applied both. It seems to me, though,
> that this stuff is in the wrong place. Perhaps we should go one step
> further and move it to tools/ ?
I spoke to Carsten and his intention apparently was to merely
59 matches
Mail list logo
