Em Sun, 16 Jun 2019 18:04:01 +0200
Markus Heiser escreveu:
> Am 14.06.19 um 16:15 schrieb Jonathan Corbet:
> > On Fri, 14 Jun 2019 16:10:31 +0200
> > Markus Heiser wrote:
> >
> >> I agree with Jani. No matter how the decision ends, since I can't help
> >> here, I'd
> >> rather not show up in
Em Sun, 16 Jun 2019 17:43:50 +0200
Markus Heiser escreveu:
> Am 14.06.19 um 18:25 schrieb Mauro Carvalho Chehab:
> > Em Fri, 14 Jun 2019 18:18:37 +0200
> > Greg Kroah-Hartman escreveu:
> >
> >> On Thu, Jun 13, 2019 at 11:04:20PM -0300, Mauro Carvalho Chehab wrote:
> >>> The parser breaks wi
* Dave Martin:
> On Tue, Jun 11, 2019 at 12:31:34PM -0700, Yu-cheng Yu wrote:
>> On Tue, 2019-06-11 at 12:41 +0100, Dave Martin wrote:
>> > On Mon, Jun 10, 2019 at 07:24:43PM +0200, Florian Weimer wrote:
>> > > * Yu-cheng Yu:
>> > >
>> > > > To me, looking at PT_GNU_PROPERTY and not trying to sup
On Mon, 17 Jun 2019, Florian Weimer wrote:
> * Dave Martin:
> > On Tue, Jun 11, 2019 at 12:31:34PM -0700, Yu-cheng Yu wrote:
> >> We can probably check PT_GNU_PROPERTY first, and fallback (based on
> >> ld-linux
> >> version?) to PT_NOTE scanning?
> >
> > For arm64, we can check for PT_GNU_PROPERT
On Fri, 14 Jun 2019, Mauro Carvalho Chehab wrote:
> Em Fri, 14 Jun 2019 16:06:03 +0200
> Greg Kroah-Hartman escreveu:
>
>> On Fri, Jun 14, 2019 at 04:42:20PM +0300, Jani Nikula wrote:
>> > 2) Have the python extension read the ABI files directly, without an
>> >extra pipeline.
>>
>> He who
On Mon, Jun 17, 2019 at 03:36:17PM +0300, Jani Nikula wrote:
> On Fri, 14 Jun 2019, Mauro Carvalho Chehab wrote:
> > Em Fri, 14 Jun 2019 16:06:03 +0200
> > Greg Kroah-Hartman escreveu:
> >
> >> On Fri, Jun 14, 2019 at 04:42:20PM +0300, Jani Nikula wrote:
> >> > 2) Have the python extension read t
On Fri, Jun 14, 2019 at 02:52:17PM -0300, Mauro Carvalho Chehab wrote:
> Add a script to parse the Documentation/ABI files and produce
> an output with all entries inside an ABI (sub)directory.
>
> Right now, it outputs its contents on ReST format. It shouldn't
> be hard to make it produce other k
On Thu 2019-06-13 07:23:15, Mauro Carvalho Chehab wrote:
> There's a typo there:
> ti_lmu.txt -> ti-lmu.txt
>
> Signed-off-by: Mauro Carvalho Chehab
Acked-by: Pavel Machek
> @@ -6,7 +6,7 @@ up to 29V total output voltage. The 11-bit LED current is
> programmable via
> the I2C bus and/
On 6/17/19 8:12 AM, Pavel Machek wrote:
On Thu 2019-06-13 07:23:15, Mauro Carvalho Chehab wrote:
There's a typo there:
ti_lmu.txt -> ti-lmu.txt
Signed-off-by: Mauro Carvalho Chehab
Acked-by: Pavel Machek
Acked-by: Dan Murphy
@@ -6,7 +6,7 @@ up to 29V total output voltage. The
On Mon, 17 Jun 2019, Greg Kroah-Hartman wrote:
> On Mon, Jun 17, 2019 at 03:36:17PM +0300, Jani Nikula wrote:
>> On Fri, 14 Jun 2019, Mauro Carvalho Chehab
>> wrote:
>> > Em Fri, 14 Jun 2019 16:06:03 +0200
>> > Greg Kroah-Hartman escreveu:
>> >
>> >> On Fri, Jun 14, 2019 at 04:42:20PM +0300, Ja
On Mon, 17 Jun 2019 14:54:38 +0200
Greg Kroah-Hartman wrote:
> > I think it's just sad to see the documentation system slowly drift
> > further away from the ideals we had, and towards the old ways we worked
> > so hard to fix.
>
> What are those ideals?
>
> I thought the goal was to be able
Em Mon, 17 Jun 2019 15:36:17 +0300
Jani Nikula escreveu:
> On Fri, 14 Jun 2019, Mauro Carvalho Chehab wrote:
> > Em Fri, 14 Jun 2019 16:06:03 +0200
> > Greg Kroah-Hartman escreveu:
> >
> >> On Fri, Jun 14, 2019 at 04:42:20PM +0300, Jani Nikula wrote:
> >> > 2) Have the python extension read
On Mon, 17 Jun 2019 06:16:59 -0300
Mauro Carvalho Chehab wrote:
> > No need to change, the emacs notation is also OK, see your link
> >
> >"""or (using formats recognized by popular editors):"""
> >
> >https://www.python.org/dev/peps/pep-0263/#defining-the-encoding
> >
> > I prefer ema
All 3 patches have now been Acked and Reviewed. Which tree should this land in?
Since this is related to KASAN, would this belong into the MM tree?
Many thanks,
-- Marco
On Thu, 13 Jun 2019 at 15:00, Marco Elver wrote:
>
> Previous version:
> http://lkml.kernel.org/r/20190613123028.179447-1-
"git diff" says:
\ No newline at end of file
after modifying the file.
Signed-off-by: Geert Uytterhoeven
---
Documentation/docutils.conf | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/docutils.conf b/Documentation/docutils.conf
index 2830772264c877ca..f1a
From: Takao Indoh
mm_cpumask was deleted by the commit 38d96287504a ("arm64: mm: kill
mm_cpumask usage") because it was not used at that time. Now this is needed
to find appropriate CPUs for TLB flush, so this patch reverts this commit.
Signed-off-by: QI Fuli
Signed-off-by: Takao Indoh
---
ar
From: Takao Indoh
I found a performance issue related on the implementation of Linux's TLB
flush for arm64.
When I run a single-threaded test program on moderate environment, it
usually takes 39ms to finish its work. However, when I put a small
apprication, which just calls mprotest() continuous
From: Takao Indoh
This patch adds new boot parameter 'disable_tlbflush_is' to disable TLB
flush within the same inner shareable domain for performance tuning.
In the case of flush_tlb_mm() *without* this parameter, TLB entry is
invalidated by __tlbi(aside1is, asid). By this instruction, all CPUs
Em Mon, 17 Jun 2019 07:56:08 -0600
Jonathan Corbet escreveu:
> On Mon, 17 Jun 2019 06:16:59 -0300
> Mauro Carvalho Chehab wrote:
>
> > > No need to change, the emacs notation is also OK, see your link
> > >
> > >"""or (using formats recognized by popular editors):"""
> > >
> > >https:
Am 17.06.19 um 11:11 schrieb Mauro Carvalho Chehab:
Em Sun, 16 Jun 2019 18:04:01 +0200
Markus Heiser escreveu:
Am 14.06.19 um 16:15 schrieb Jonathan Corbet:
On Fri, 14 Jun 2019 16:10:31 +0200
Markus Heiser wrote:
I agree with Jani. No matter how the decision ends, since I can't help h
Hi Takao,
[+Peter Z]
On Mon, Jun 17, 2019 at 11:32:53PM +0900, Takao Indoh wrote:
> From: Takao Indoh
>
> I found a performance issue related on the implementation of Linux's TLB
> flush for arm64.
>
> When I run a single-threaded test program on moderate environment, it
> usually takes 39ms t
The Documentation/features contains a set of parseable files.
It is not worth converting them to ReST format, as they're
useful the way it is. It is, however, interesting to parse
them and produce output on different formats:
1) Output the contents of a feature in ReST format;
2) Output what feat
On Mon, Jun 17, 2019 at 03:05:07PM -0300, Mauro Carvalho Chehab wrote:
> The Documentation/features contains a set of parseable files.
> It is not worth converting them to ReST format, as they're
> useful the way it is. It is, however, interesting to parse
> them and produce output on different for
The Documentation/features contains a set of parseable files.
It is not worth converting them to ReST format, as they're
useful the way it is. It is, however, interesting to parse
them and produce output on different formats:
1) Output the contents of a feature in ReST format;
2) Output what feat
Add a feature list matrix at the admin-guide and a x86-specific
feature list to the respective Kernel books.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/admin-guide/features.rst | 3 +
Documentation/admin-guide/index.rst| 1 +
Documentation/conf.py | 2 +-
D
The status ".." Means that the feature can't be implemented
on a given architecture.
The problem is that this doesn't show anything at the
output, so replace it by "---", with is a markup for a long
hyphen.
Signed-off-by: Mauro Carvalho Chehab
---
In time: this patch fixes an small issue with t
Em Mon, 17 Jun 2019 20:11:16 +0200
Greg Kroah-Hartman escreveu:
> On Mon, Jun 17, 2019 at 03:05:07PM -0300, Mauro Carvalho Chehab wrote:
> > The Documentation/features contains a set of parseable files.
> > It is not worth converting them to ReST format, as they're
> > useful the way it is. It is
From: Anson Huang
NXP i.MX8QXP is an ARMv8 SoC with a Cortex-M4 core inside as
system controller, the system controller is in charge of system
power, clock and thermal sensors etc. management, Linux kernel
has to communicate with system controller via MU (message unit)
IPC to get temperature from
From: Anson Huang
This patch adds new API thermal_zone_of_get_sensor_id() to
provide the feature of getting sensor ID from DT thermal
zone's node. It's useful for thermal driver to register the
specific thermal zone devices from DT in a common way.
Signed-off-by: Anson Huang
Reviewed-by: Dong A
From: Anson Huang
Add i.MX8QXP CPU thermal zone support.
Signed-off-by: Anson Huang
---
No change.
---
arch/arm64/boot/dts/freescale/imx8qxp.dtsi | 37 ++
1 file changed, 37 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
b/arch/arm64/boot/dt
From: Anson Huang
This patch enables CONFIG_IMX_SC_THERMAL as module.
Signed-off-by: Anson Huang
---
No change.
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index c40ec41..29f7768 100644
--- a/a
From: Anson Huang
i.MX8QXP is an ARMv8 SoC which has a Cortex-M4 system controller
inside, the system controller is in charge of controlling power,
clock and thermal sensors etc..
This patch adds i.MX system controller thermal driver support,
Linux kernel has to communicate with system controlle
On Tue, Jun 18, 2019 at 11:02:27AM +0530, Puranjay Mohan wrote:
> This converts the plain text documentation to reStructuredText format.
> No essential content change.
>
> Signed-off-by: Puranjay Mohan
> ---
> Documentation/platform/x86-laptop-drivers.rst | 23 +++
> Documentatio
33 matches
Mail list logo
