* Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set additionalProperties to true
From: Krzysztof Kozlowski @ 2024-04-08 5:57 UTC (permalink / raw)
To: Peng Fan, Peng Fan (OSS), Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Sudeep Holla, Cristian Marussi
Cc: devicetree@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <DU0PR04MB9417839C42681F57366003EF88012@DU0PR04MB9417.eurprd04.prod.outlook.com>
On 08/04/2024 01:50, Peng Fan wrote:
>> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set
>> additionalProperties to true
>>
>> On 07/04/2024 12:04, Peng Fan wrote:
>>>> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set
>>>> additionalProperties to true
>>>>
>>>> On 07/04/2024 02:37, Peng Fan wrote:
>>>>>> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set
>>>>>> additionalProperties to true
>>>>>>
>>>>>> On 05/04/2024 14:39, Peng Fan (OSS) wrote:
>>>>>>> From: Peng Fan <peng.fan@nxp.com>
>>>>>>>
>>>>>>> When adding vendor extension protocols, there is dt-schema warning:
>>>>>>> "
>>>>>>> imx,scmi.example.dtb: scmi: 'protocol@81', 'protocol@84' do not
>>>>>>> match any of the regexes: 'pinctrl-[0-9]+'
>>>>>>> "
>>>>>>>
>>>>>>> Set additionalProperties to true to address the issue.
>>>>>>
>>>>>> I do not see anything addressed here, except making the binding
>>>>>> accepting anything anywhere...
>>>>>
>>>>> I not wanna add vendor protocols in arm,scmi.yaml, so will introduce
>>>>> a new yaml imx.scmi.yaml which add i.MX SCMI protocol extension.
>>>>>
>>>>> With additionalProperties set to false, I not know how, please suggest.
>>>>
>>>> First of all, you cannot affect negatively existing devices (their
>>>> bindings) and your patch does exactly that. This should make you
>>>> thing what is the correct approach...
>>>>
>>>> Rob gave you the comment about missing compatible - you still did not
>>>> address that.
>>>
>>> I added the compatible in patch 2/6 in the examples "compatible =
>> "arm,scmi";"
>>
>> So you claim that your vendor extensions are the same or fully compatible
>> with arm,scmi and you add nothing... Are your extensions/protocol valid for
>> arm,scmi?
>
> Yes. They are valid for arm,scmi.
>
> If yes, why is this in separate binding. If no, why you use someone
>> else's compatible?
>
> Per SCMI Spec
> 0x80-0xFF: Reserved for vendor or platform-specific extensions to
> this interface
>
> i.MX use 0x81 for BBM, 0x84 for MISC. But other vendors will use
> the id for their own protocol.
So how are they valid for arm,scmi? I don't understand.
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v9 1/7] dt-bindings: spmi: Add X1E80100 SPMI PMIC ARB schema
From: Abel Vesa @ 2024-04-08 6:04 UTC (permalink / raw)
To: Bjorn Andersson, Krzysztof Kozlowski
Cc: Stephen Boyd, Matthias Brugger, Konrad Dybcio, Dmitry Baryshkov,
Neil Armstrong, AngeloGioacchino Del Regno, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Srini Kandagatla, Johan Hovold,
David Collins, linux-kernel, linux-arm-kernel, linux-arm-msm,
linux-mediatek, devicetree, Krzysztof Kozlowski
In-Reply-To: <fkwugrnak3fhkg5ig47kmy3edm45ut4dprkabntnwemjt3w2mb@7cak5zxwzw4p>
On 24-04-07 19:07:03, Bjorn Andersson wrote:
> On Sun, Apr 07, 2024 at 07:23:21PM +0300, Abel Vesa wrote:
> > Add dedicated schema for X1E80100 PMIC ARB (v7) as it allows multiple
> > buses by declaring them as child nodes.
> >
>
> But is this really a "dedicated schema for X1E80100"? Isn't it "the
> schema for all multi-bus controllers"?
>
> I.e. isn't this a "dedicated schema for all platforms starting with
> SM8450"?
Suggestion was from Krzysztof to add platform specific comaptible (and
therefore schema). Since the first platform that will support in
upstream proper multi bus is the x1e80100, the schema needs to bear the
same name as the compatible. When support for multi bus will be added to
the other platforms (including the SM8450), they will use the fallback
compatible of the x1e80100 and will be documented in this newly added
schema. We did the same thing with some PHYs drivers, IIRC.
>
> Can you please use the commit message to document the actual reason why
> you choose to create a dedicated schema for this? Is it simply to avoid
> having to schema with either pmics or multiple buses as children?
I can re-send the patchset with such a phrase in commit message.
One of the early versions of this patchset was actually submitting a
generic compatible for multi bus, but I remember that there was a
request for following the platform dedicated approach.
Krzysztof, can you please provide here the argument for why that is
preferred?
>
> Regards,
> Bjorn
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set additionalProperties to true
From: Peng Fan @ 2024-04-08 6:08 UTC (permalink / raw)
To: Krzysztof Kozlowski, Peng Fan (OSS), Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Sudeep Holla,
Cristian Marussi
Cc: devicetree@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <ba4c9f20-0391-4ac2-a236-d6930285cd7e@kernel.org>
> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set
> additionalProperties to true
>
> On 08/04/2024 01:50, Peng Fan wrote:
> >> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set
> >> additionalProperties to true
> >>
> >> On 07/04/2024 12:04, Peng Fan wrote:
> >>>> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set
> >>>> additionalProperties to true
> >>>>
> >>>> On 07/04/2024 02:37, Peng Fan wrote:
> >>>>>> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set
> >>>>>> additionalProperties to true
> >>>>>>
> >>>>>> On 05/04/2024 14:39, Peng Fan (OSS) wrote:
> >>>>>>> From: Peng Fan <peng.fan@nxp.com>
> >>>>>>>
> >>>>>>> When adding vendor extension protocols, there is dt-schema
> warning:
> >>>>>>> "
> >>>>>>> imx,scmi.example.dtb: scmi: 'protocol@81', 'protocol@84' do not
> >>>>>>> match any of the regexes: 'pinctrl-[0-9]+'
> >>>>>>> "
> >>>>>>>
> >>>>>>> Set additionalProperties to true to address the issue.
> >>>>>>
> >>>>>> I do not see anything addressed here, except making the binding
> >>>>>> accepting anything anywhere...
> >>>>>
> >>>>> I not wanna add vendor protocols in arm,scmi.yaml, so will
> >>>>> introduce a new yaml imx.scmi.yaml which add i.MX SCMI protocol
> extension.
> >>>>>
> >>>>> With additionalProperties set to false, I not know how, please suggest.
> >>>>
> >>>> First of all, you cannot affect negatively existing devices (their
> >>>> bindings) and your patch does exactly that. This should make you
> >>>> thing what is the correct approach...
> >>>>
> >>>> Rob gave you the comment about missing compatible - you still did
> >>>> not address that.
> >>>
> >>> I added the compatible in patch 2/6 in the examples "compatible =
> >> "arm,scmi";"
> >>
> >> So you claim that your vendor extensions are the same or fully
> >> compatible with arm,scmi and you add nothing... Are your
> >> extensions/protocol valid for arm,scmi?
> >
> > Yes. They are valid for arm,scmi.
> >
> > If yes, why is this in separate binding. If no, why you use someone
> >> else's compatible?
> >
> > Per SCMI Spec
> > 0x80-0xFF: Reserved for vendor or platform-specific extensions to this
> > interface
> >
> > i.MX use 0x81 for BBM, 0x84 for MISC. But other vendors will use the
> > id for their own protocol.
>
> So how are they valid for arm,scmi? I don't understand.
arm,scmi is a firmware compatible string. The protocol node is a sub-node.
I think the arm,scmi is that saying the firmware following
SCMI spec to implement the protocols.
For vendor reserved ID, firmware also follow the SCMI spec to implement
their own usage, so from firmware level, it is ARM SCMI spec compatible.
firmware {
scmi {
compatible = "arm,scmi";
#address-cells = <1>;
#size-cells = <0>;
scmi_devpd: protocol@11 {
reg = <0x11>;
#power-domain-cells = <1>;
};
scmi_sys_power: protocol@12 {
reg = <0x12>;
};
scmi_perf: protocol@13 {
reg = <0x13>;
#clock-cells = <1>;
#power-domain-cells = <1>;
};
Scmi_bbm: protocol@81 {
reg = <0x81>; ->vendor id
vendor,xyz; ---> vendor properties.
}
Thanks,
Peng.
>
>
>
> Best regards,
> Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH V2 0/8] perf tools: Fix test "perf probe of function from different CU"
From: Chaitanya S Prakash @ 2024-04-08 6:22 UTC (permalink / raw)
To: linux-perf-users
Cc: anshuman.khandual, james.clark, Chaitanya S Prakash,
Josh Poimboeuf, Peter Zijlstra, Suzuki K Poulose, Mike Leach,
John Garry, Will Deacon, Leo Yan, Ingo Molnar,
Arnaldo Carvalho de Melo, Namhyung Kim, Mark Rutland,
Alexander Shishkin, Jiri Olsa, Ian Rogers, Adrian Hunter,
Chenyuan Mi, Masami Hiramatsu, Ravi Bangoria,
Ahelenia Ziemiańska, Colin Ian King, Changbin Du, Kan Liang,
Athira Rajeev, Tiezhu Yang, Alexey Dobriyan, Georg Müller,
Liam Howlett, bpf, coresight, linux-arm-kernel, linux-kernel
From: Chaitanya S Prakash <chaitanyas.prakash@arm.com>
Defconfig doesn't provide all the necessary configs required for the
test "perf probe of function from different CU" to run successfully on
all platforms. Therefore the required configs have been added to
config fragments to resolve this issue. On further investigation it was
seen that the Perf treated all files beginning with "/tmp/perf-" as a
map file despite them always ending in ".map", this caused the test to
fail when Perf was built with NO_DWARF=1. As the file was parsed as a
map file, the probe...--funcs command output garbage values instead of
listing the functions in the binary. After fixing the issue an
additional check to test the output of the probe...--funcs command has
been added.
Additionally, various functions within the codebase have been refactored
and restructured. The definition of str_has_suffix() has been adopted
from tools/bpf/bpftool/gen.c and added to tools/lib/string.c in an
attempt to make the function more generic. The implementation has been
retained but the return values have been modified to resemble that of
str_has_prefix(), i.e., return strlen(suffix) on success and 0 on
failure. In light of the new addition, "ends_with()", a locally defined
function used for checking if a string had a given suffix has been
deleted and str_has_suffix() has replaced its usage. A call to
strtailcmp() has also been replaced as str_has_suffix() seemed more
suited for that particular use case.
Finally str_has_prefix() is adopted from the kernel and is added to
tools/lib/string.c, following which strstarts() is deleted and its use
has been replaced with str_has_prefix().
This patch series has been tested on 6.9-rc2 mainline kernel, both on
arm64 and x86 platforms.
Changes in V2:
- Add str_has_suffix() and str_has_prefix() to tools/lib/string.c
- Delete ends_with() and replace its usage with str_has_suffix()
- Replace an instance of strtailcmp() with str_has_suffix()
- Delete strstarts() from tools/include/linux/string.h and replace its
usage with str_has_prefix()
Cc: Josh Poimboeuf <jpoimboe@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: Mike Leach <mike.leach@linaro.org>
Cc: James Clark <james.clark@arm.com>
Cc: John Garry <john.g.garry@oracle.com>
Cc: Will Deacon <will@kernel.org>
Cc: Leo Yan <leo.yan@linaro.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Ian Rogers <irogers@google.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Chenyuan Mi <cymi20@fudan.edu.cn>
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Ravi Bangoria <ravi.bangoria@amd.com>
Cc: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
Cc: Colin Ian King <colin.i.king@gmail.com>
Cc: Changbin Du <changbin.du@huawei.com>
Cc: Kan Liang <kan.liang@linux.intel.com>
Cc: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
Cc: Tiezhu Yang <yangtiezhu@loongson.cn>
Cc: Alexey Dobriyan <adobriyan@gmail.com>
Cc: Georg Müller <georgmueller@gmx.net>
Cc: Liam Howlett <liam.howlett@oracle.com>
Cc: bpf@vger.kernel.org
Cc: coresight@lists.linaro.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-perf-users@vger.kernel.org
Chaitanya S Prakash (8):
tools lib: adopt str_has_suffix() from bpftool/gen.c
perf util: Delete ends_with() and replace its use with
str_has_suffix()
perf util: Replace an instance of strtailcmp() by str_has_suffix()
tools lib: Adopt str_has_prefix() from kernel
tools: Delete strstarts() and replace its usage with str_has_prefix()
perf tools: Enable configs required for
test_uprobe_from_different_cu.sh
perf tools: Only treat files as map files when they have the extension
.map
perf test: Check output of the probe ... --funcs command
tools/include/linux/string.h | 12 ++----
tools/lib/string.c | 42 +++++++++++++++++++
tools/lib/subcmd/help.c | 2 +-
tools/lib/subcmd/parse-options.c | 18 ++++----
tools/objtool/check.c | 2 +-
tools/perf/arch/arm/util/pmu.c | 4 +-
tools/perf/arch/x86/annotate/instructions.c | 14 +++----
tools/perf/arch/x86/util/env.c | 2 +-
tools/perf/builtin-c2c.c | 4 +-
tools/perf/builtin-config.c | 2 +-
tools/perf/builtin-daemon.c | 2 +-
tools/perf/builtin-ftrace.c | 2 +-
tools/perf/builtin-help.c | 6 +--
tools/perf/builtin-kmem.c | 2 +-
tools/perf/builtin-kvm.c | 14 +++----
tools/perf/builtin-kwork.c | 10 ++---
tools/perf/builtin-lock.c | 6 +--
tools/perf/builtin-mem.c | 4 +-
tools/perf/builtin-sched.c | 6 +--
tools/perf/builtin-script.c | 30 ++++---------
tools/perf/builtin-stat.c | 4 +-
tools/perf/builtin-timechart.c | 2 +-
tools/perf/builtin-trace.c | 6 +--
tools/perf/perf.c | 12 +++---
tools/perf/tests/config-fragments/config | 3 ++
.../shell/test_uprobe_from_different_cu.sh | 2 +-
tools/perf/tests/symbols.c | 2 +-
tools/perf/ui/browser.c | 2 +-
tools/perf/ui/browsers/scripts.c | 2 +-
tools/perf/ui/stdio/hist.c | 2 +-
tools/perf/util/amd-sample-raw.c | 4 +-
tools/perf/util/annotate.c | 2 +-
tools/perf/util/callchain.c | 2 +-
tools/perf/util/config.c | 12 +++---
tools/perf/util/map.c | 8 ++--
tools/perf/util/pmus.c | 2 +-
tools/perf/util/probe-event.c | 2 +-
tools/perf/util/sample-raw.c | 2 +-
tools/perf/util/symbol-elf.c | 4 +-
tools/perf/util/symbol.c | 4 +-
40 files changed, 146 insertions(+), 117 deletions(-)
--
2.30.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 4/4] mm: replace set_pte_at_notify() with just set_pte_at()
From: Philippe Mathieu-Daudé @ 2024-04-08 6:28 UTC (permalink / raw)
To: Paolo Bonzini, linux-kernel, kvm
Cc: Marc Zyngier, Oliver Upton, Tianrui Zhao, Bibo Mao,
Thomas Bogendoerfer, Nicholas Piggin, Anup Patel, Atish Patra,
Sean Christopherson, Andrew Morton, David Hildenbrand,
linux-arm-kernel, kvmarm, loongarch, linux-mips, linuxppc-dev,
kvm-riscv, linux-mm, linux-trace-kernel, linux-perf-users
In-Reply-To: <20240405115815.3226315-5-pbonzini@redhat.com>
On 5/4/24 13:58, Paolo Bonzini wrote:
> With the demise of the .change_pte() MMU notifier callback, there is no
> notification happening in set_pte_at_notify(). It is a synonym of
> set_pte_at() and can be replaced with it.
>
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> ---
> include/linux/mmu_notifier.h | 2 --
> kernel/events/uprobes.c | 5 ++---
> mm/ksm.c | 4 ++--
> mm/memory.c | 7 +------
> mm/migrate_device.c | 8 ++------
> 5 files changed, 7 insertions(+), 19 deletions(-)
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v9 1/7] dt-bindings: spmi: Add X1E80100 SPMI PMIC ARB schema
From: Krzysztof Kozlowski @ 2024-04-08 6:30 UTC (permalink / raw)
To: Abel Vesa, Bjorn Andersson, Krzysztof Kozlowski
Cc: Stephen Boyd, Matthias Brugger, Konrad Dybcio, Dmitry Baryshkov,
Neil Armstrong, AngeloGioacchino Del Regno, Rob Herring,
Conor Dooley, Srini Kandagatla, Johan Hovold, David Collins,
linux-kernel, linux-arm-kernel, linux-arm-msm, linux-mediatek,
devicetree
In-Reply-To: <ZhOJB8o9cRr7oQU8@linaro.org>
On 08/04/2024 08:04, Abel Vesa wrote:
> On 24-04-07 19:07:03, Bjorn Andersson wrote:
>> On Sun, Apr 07, 2024 at 07:23:21PM +0300, Abel Vesa wrote:
>>> Add dedicated schema for X1E80100 PMIC ARB (v7) as it allows multiple
>>> buses by declaring them as child nodes.
>>>
>>
>> But is this really a "dedicated schema for X1E80100"? Isn't it "the
>> schema for all multi-bus controllers"?
>>
>> I.e. isn't this a "dedicated schema for all platforms starting with
>> SM8450"?
>
> Suggestion was from Krzysztof to add platform specific comaptible (and
> therefore schema). Since the first platform that will support in
> upstream proper multi bus is the x1e80100, the schema needs to bear the
> same name as the compatible. When support for multi bus will be added to
> the other platforms (including the SM8450), they will use the fallback
> compatible of the x1e80100 and will be documented in this newly added
> schema. We did the same thing with some PHYs drivers, IIRC.
>
>>
>> Can you please use the commit message to document the actual reason why
>> you choose to create a dedicated schema for this? Is it simply to avoid
>> having to schema with either pmics or multiple buses as children?
>
> I can re-send the patchset with such a phrase in commit message.
>
> One of the early versions of this patchset was actually submitting a
> generic compatible for multi bus, but I remember that there was a
> request for following the platform dedicated approach.
>
> Krzysztof, can you please provide here the argument for why that is
> preferred?
I could not find such suggestions from my side in the archives, except:
https://lore.kernel.org/all/dd86117e-0196-499b-b8b3-efe4013cbc07@linaro.org/
where I want SoC specific compatibles to be used, not versions.
Now about this binding, it is not a schema for all platforms starting
with sm8450, but only for x1e. I do not understand why this would be a
problem?
If you ask why this is not a schema for all platforms, then because:
1. maybe no one tested other SoCs?
2. maybe no one cares?
3. maybe other boards need some quirks, so this would be applicable but
not fully?
I don't know... since when do we add "generic schemas"?
However maybe the question is different: why other devices are not
described here, while they should? Then probably Abel can answer what he
wants and what he does not want to describe. There is no requirement to
model all possible hardware in a binding, but instead describe one
hardware, so x1e, fully.
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/4] KVM: remove unused argument of kvm_handle_hva_range()
From: Philippe Mathieu-Daudé @ 2024-04-08 6:31 UTC (permalink / raw)
To: Paolo Bonzini, linux-kernel, kvm
Cc: Marc Zyngier, Oliver Upton, Tianrui Zhao, Bibo Mao,
Thomas Bogendoerfer, Nicholas Piggin, Anup Patel, Atish Patra,
Sean Christopherson, Andrew Morton, David Hildenbrand,
linux-arm-kernel, kvmarm, loongarch, linux-mips, linuxppc-dev,
kvm-riscv, linux-mm, linux-trace-kernel, linux-perf-users
In-Reply-To: <20240405115815.3226315-3-pbonzini@redhat.com>
On 5/4/24 13:58, Paolo Bonzini wrote:
> The only user was kvm_mmu_notifier_change_pte(), which is now gone.
>
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> ---
> virt/kvm/kvm_main.c | 7 +------
> 1 file changed, 1 insertion(+), 6 deletions(-)
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 1/2] dt-bindings: media: imx8-jpeg: Add clocks entries
From: Krzysztof Kozlowski @ 2024-04-08 6:38 UTC (permalink / raw)
To: Mirela Rabulea, shawnguo, robh+dt, krzysztof.kozlowski+dt,
festevam, festevam, alexander.stein, Frank.li, ming.qian
Cc: conor+dt, devicetree, linux-arm-kernel, s.hauer, kernel, mchehab,
hverkuil, linux-media, imx, linux-kernel
In-Reply-To: <20240408030734.1191069-1-mirela.rabulea@nxp.com>
On 08/04/2024 05:07, Mirela Rabulea wrote:
> From: Fabio Estevam <festevam@gmail.com>
>
> The JPEG decoder/encoder present in iMX8QXP and iMX8QM SoCs need
> the PER and IPG clocks to be functional, so add the clock entries.
>
> This also fixes the following schema warning:
>
> imx8qm-apalis-eval.dtb: jpegdec@58400000: 'assigned-clock-rates', 'assigned-clocks', 'clock-names', 'clocks' do not match any of the regexes: 'pinctrl-[0-9]+'
> from schema $id: http://devicetree.org/schemas/media/nxp,imx8-jpeg.yaml#
>
> Signed-off-by: Fabio Estevam <festevam@denx.de>
> Signed-off-by: Mirela Rabulea <mirela.rabulea@nxp.com>
> ---
>
Please correct subject. You already got comments on this.
https://lore.kernel.org/linux-devicetree/2fb8c43c-c079-e04e-f727-3bc1dc29996e@linaro.org/
> Changes since v3:
> - Add items for clocks (per Krzysztof's feddback)
> - Add description for clocks (per Conor's feddback to the other similar patch from Alexander)
> - Add "media:" to the subject
Where? It was there before, so what did you change?
> - Add Mirela's signed-off
> - For the similar patches that were sent for this issue, should Co-developed-by/Signed-off-by be added? Alexander Stein? Frank Li?
>
> Changes since v2:
> - Remove clock-names. (Mirela)
>
> .../devicetree/bindings/media/nxp,imx8-jpeg.yaml | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/media/nxp,imx8-jpeg.yaml b/Documentation/devicetree/bindings/media/nxp,imx8-jpeg.yaml
> index 3d9d1db37040..cc040feb77d7 100644
> --- a/Documentation/devicetree/bindings/media/nxp,imx8-jpeg.yaml
> +++ b/Documentation/devicetree/bindings/media/nxp,imx8-jpeg.yaml
> @@ -31,6 +31,14 @@ properties:
> reg:
> maxItems: 1
>
> + clocks:
> + description:
> + The JPEG decoder/encoder requires two clocks for it's wrapper (AXI and APB),
> + and one clock for it's core engine (AXI, same source as for the wrapper)
Description is now redundant, drop it.
> + items:
> + - description: AXI DMA engine clock for fetching JPEG bitstream from memory (per)
> + - description: IP bus clock for register access (ipg)
> +
> interrupts:
> description: |
> There are 4 slots available in the IP, which the driver may use
> @@ -49,6 +57,7 @@ properties:
> required:
> - compatible
> - reg
> + - clocks
> - interrupts
> - power-domains
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] dt-bindings: net: rockchip-dwmac: use rgmii-id in example
From: Sascha Hauer @ 2024-04-08 6:44 UTC (permalink / raw)
To: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
David Wu
Cc: netdev, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel, Andrew Lunn, Sascha Hauer
The dwmac supports specifying the RGMII clock delays, but it is
recommended to use rgmii-id and to specify the delays in the phy node
instead [1].
Change the example accordingly to no longer promote this undesired
setting.
[1] https://lore.kernel.org/all/1a0de7b4-f0f7-4080-ae48-f5ffa9e76be3@lunn.ch/
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
Documentation/devicetree/bindings/net/rockchip-dwmac.yaml | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml b/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml
index 70bbc4220e2ac..6bbe96e352509 100644
--- a/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml
@@ -137,8 +137,6 @@ examples:
assigned-clock-parents = <&ext_gmac>;
rockchip,grf = <&grf>;
- phy-mode = "rgmii";
+ phy-mode = "rgmii-id";
clock_in_out = "input";
- tx_delay = <0x30>;
- rx_delay = <0x10>;
};
---
base-commit: 39cd87c4eb2b893354f3b850f916353f2658ae6f
change-id: 20240408-rockchip-dwmac-rgmii-id-binding-6166af659845
Best regards,
--
Sascha Hauer <s.hauer@pengutronix.de>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v4 0/5] Pinephone video out fixes (flipping between two frames)
From: Stephen Boyd @ 2024-04-08 6:48 UTC (permalink / raw)
To: Chen-Yu Tsai, Frank Oltmanns, Jernej Skrabec, Maxime Ripard,
Michael Turquette, Samuel Holland
Cc: Guido Günther, Purism Kernel Team, Ondrej Jirman,
Neil Armstrong, Jessica Zhang, Sam Ravnborg, Maarten Lankhorst,
Thomas Zimmermann, David Airlie, Daniel Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-clk, linux-arm-kernel,
linux-sunxi, linux-kernel, dri-devel, devicetree, stable,
Diego Roversi, Erico Nunes
In-Reply-To: <87frw2a2e4.fsf@oltmanns.dev>
Quoting Frank Oltmanns (2024-04-03 08:31:47)
> Dear clk and sunxi-ng maintainers,
>
> Patches 1-4 have been reviewed and there are no pending issues. If there
> is something else you need me to do to get this applied, please let me
> know.
>
I'm assuming sunxi maintainers will pick up the clk patches and send
them to clk tree in a PR.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] clk: mediatek: mt7988-infracfg: fix clocks for 2nd PCIe port
From: Stephen Boyd @ 2024-04-08 6:50 UTC (permalink / raw)
To: AngeloGioacchino Del Regno, Daniel Golle, Frank Wunderlich,
Matthias Brugger, Michael Turquette, Sam Shih, linux-arm-kernel,
linux-clk, linux-kernel, linux-mediatek
In-Reply-To: <f0383126-99c4-4233-b222-597caacf43b9@collabora.com>
Quoting AngeloGioacchino Del Regno (2024-03-14 02:44:59)
> Il 13/03/24 23:05, Daniel Golle ha scritto:
> > Due to what seems to be an undocumented oddity in MediaTek's MT7988
> > SoC design the CLK_INFRA_PCIE_PERI_26M_CK_P2 clock requires
> > CLK_INFRA_PCIE_PERI_26M_CK_P3 to be enabled.
> >
> > This currently leads to PCIe port 2 not working in Linux.
> >
> > Reflect the apparent relationship in the clk driver to make sure PCIe
> > port 2 of the MT7988 SoC works.
> >
> > Fixes: 4b4719437d85f ("clk: mediatek: add drivers for MT7988 SoC")
> > Suggested-by: Sam Shih <sam.shih@mediatek.com>
> > Signed-off-by: Daniel Golle <daniel@makrotopia.org>
>
> That's funny. Anyway:
>
> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Are you picking up mediatek clk patches and fixes this cycle?
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH net v3] net: dsa: mt7530: fix enabling EEE on MT7531 switch on all boards
From: Arınç ÜNAL via B4 Relay @ 2024-04-08 7:08 UTC (permalink / raw)
To: Daniel Golle, DENG Qingfang, Sean Wang, Andrew Lunn,
Florian Fainelli, Vladimir Oltean, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Matthias Brugger,
AngeloGioacchino Del Regno, René van Dorst, Russell King,
SkyLake Huang, Heiner Kallweit
Cc: Bartel Eerdekens, mithat.guner, erkin.bozoglu, netdev,
linux-kernel, linux-arm-kernel, linux-mediatek, Florian Fainelli,
Arınç ÜNAL
From: Arınç ÜNAL <arinc.unal@arinc9.com>
The commit 40b5d2f15c09 ("net: dsa: mt7530: Add support for EEE features")
brought EEE support but did not enable EEE on MT7531 switch MACs. EEE is
enabled on MT7531 switch MACs by pulling the LAN2LED0 pin low on the board
(bootstrapping), unsetting the EEE_DIS bit on the trap register, or setting
the internal EEE switch bit on the CORE_PLL_GROUP4 register. Thanks to
SkyLake Huang (黃啟澤) from MediaTek for providing information on the
internal EEE switch bit.
There are existing boards that were not designed to pull the pin low.
Because of that, the EEE status currently depends on the board design.
The EEE_DIS bit on the trap pertains to the LAN2LED0 pin which is usually
used to control an LED. Once the bit is unset, the pin will be low. That
will make the active low LED turn on. The pin is controlled by the switch
PHY. It seems that the PHY controls the pin in the way that it inverts the
pin state. That means depending on the wiring of the LED connected to
LAN2LED0 on the board, the LED may be on without an active link.
To not cause this unwanted behaviour whilst enabling EEE on all boards, set
the internal EEE switch bit on the CORE_PLL_GROUP4 register.
My testing on MT7531 shows a certain amount of traffic loss when EEE is
enabled. That said, I haven't come across a board that enables EEE. So
enable EEE on the switch MACs but disable EEE advertisement on the switch
PHYs. This way, we don't change the behaviour of the majority of the boards
that have this switch. The mediatek-ge PHY driver already disables EEE
advertisement on the switch PHYs but my testing shows that it is somehow
enabled afterwards. Disabling EEE advertisement before the PHY driver
initialises keeps it off.
With this change, EEE can now be enabled using ethtool.
Fixes: 40b5d2f15c09 ("net: dsa: mt7530: Add support for EEE features")
Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com>
---
Here's some information for the record. EEE could not be enabled on MT7531
on most boards using ethtool before this. On MT7988 SoC switch, EEE is
disabled by default but can be turned on normally using ethtool. EEE is
enabled by default on MT7530 and there's no need to make changes on the DSA
subdriver for it.
---
Changes in v3:
- Remove patch 2, it was revealed that it doesn't fix a bug.
- Patch 1
- Use the internal EEE switch bit provided by SkyLake Huang (黃啟澤). It
is a better method compared to unsetting the EEE_DIS bit of the trap as
the latter method causes unwanted behaviour on the LED connected to the
pin that pertains to the EEE_DIS bit.
- Link to v2: https://lore.kernel.org/r/20240321-for-net-mt7530-fix-eee-for-mt7531-mt7988-v2-0-9af9d5041bfe@arinc9.com
Changes in v2:
- Delegate the patch to the net tree.
- Remove patch 3, it was revealed that it doesn't fix a bug.
- Patch 1
- Disable EEE advertisement on MT7531 by default.
- Link to v1: https://lore.kernel.org/r/20240318-for-net-mt7530-fix-eee-for-mt7531-mt7988-v1-0-3f17226344e8@arinc9.com
---
drivers/net/dsa/mt7530.c | 17 ++++++++++++-----
drivers/net/dsa/mt7530.h | 1 +
2 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c
index 1035820c2377..451ff0620c2e 100644
--- a/drivers/net/dsa/mt7530.c
+++ b/drivers/net/dsa/mt7530.c
@@ -2505,18 +2505,25 @@ mt7531_setup(struct dsa_switch *ds)
mt7530_rmw(priv, MT7531_GPIO_MODE0, MT7531_GPIO0_MASK,
MT7531_GPIO0_INTERRUPT);
- /* Enable PHY core PLL, since phy_device has not yet been created
- * provided for phy_[read,write]_mmd_indirect is called, we provide
- * our own mt7531_ind_mmd_phy_[read,write] to complete this
- * function.
+ /* Enable Energy-Efficient Ethernet (EEE) and PHY core PLL, since
+ * phy_device has not yet been created provided for
+ * phy_[read,write]_mmd_indirect is called, we provide our own
+ * mt7531_ind_mmd_phy_[read,write] to complete this function.
*/
val = mt7531_ind_c45_phy_read(priv, MT753X_CTRL_PHY_ADDR,
MDIO_MMD_VEND2, CORE_PLL_GROUP4);
- val |= MT7531_PHY_PLL_BYPASS_MODE;
+ val |= MT7531_RG_SYSPLL_DMY2 | MT7531_PHY_PLL_BYPASS_MODE;
val &= ~MT7531_PHY_PLL_OFF;
mt7531_ind_c45_phy_write(priv, MT753X_CTRL_PHY_ADDR, MDIO_MMD_VEND2,
CORE_PLL_GROUP4, val);
+ /* Disable EEE advertisement on the switch PHYs. */
+ for (i = MT753X_CTRL_PHY_ADDR;
+ i < MT753X_CTRL_PHY_ADDR + MT7530_NUM_PHYS; i++) {
+ mt7531_ind_c45_phy_write(priv, i, MDIO_MMD_AN, MDIO_AN_EEE_ADV,
+ 0);
+ }
+
mt7531_setup_common(ds);
/* Setup VLAN ID 0 for VLAN-unaware bridges */
diff --git a/drivers/net/dsa/mt7530.h b/drivers/net/dsa/mt7530.h
index d17b318e6ee4..9439db495001 100644
--- a/drivers/net/dsa/mt7530.h
+++ b/drivers/net/dsa/mt7530.h
@@ -616,6 +616,7 @@ enum mt7531_clk_skew {
#define RG_SYSPLL_DDSFBK_EN BIT(12)
#define RG_SYSPLL_BIAS_EN BIT(11)
#define RG_SYSPLL_BIAS_LPF_EN BIT(10)
+#define MT7531_RG_SYSPLL_DMY2 BIT(6)
#define MT7531_PHY_PLL_OFF BIT(5)
#define MT7531_PHY_PLL_BYPASS_MODE BIT(4)
---
base-commit: bccb798e07f8bb8b91212fe8ed1e421685449076
change-id: 20240317-for-net-mt7530-fix-eee-for-mt7531-mt7988-a5c5453cc0e8
Best regards,
--
Arınç ÜNAL <arinc.unal@arinc9.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set additionalProperties to true
From: Krzysztof Kozlowski @ 2024-04-08 7:18 UTC (permalink / raw)
To: Peng Fan, Peng Fan (OSS), Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Sudeep Holla, Cristian Marussi
Cc: devicetree@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <DU0PR04MB94176D02B90528913842B76A88002@DU0PR04MB9417.eurprd04.prod.outlook.com>
On 08/04/2024 08:08, Peng Fan wrote:
>> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set
>> additionalProperties to true
>>
>> On 08/04/2024 01:50, Peng Fan wrote:
>>>> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set
>>>> additionalProperties to true
>>>>
>>>> On 07/04/2024 12:04, Peng Fan wrote:
>>>>>> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set
>>>>>> additionalProperties to true
>>>>>>
>>>>>> On 07/04/2024 02:37, Peng Fan wrote:
>>>>>>>> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set
>>>>>>>> additionalProperties to true
>>>>>>>>
>>>>>>>> On 05/04/2024 14:39, Peng Fan (OSS) wrote:
>>>>>>>>> From: Peng Fan <peng.fan@nxp.com>
>>>>>>>>>
>>>>>>>>> When adding vendor extension protocols, there is dt-schema
>> warning:
>>>>>>>>> "
>>>>>>>>> imx,scmi.example.dtb: scmi: 'protocol@81', 'protocol@84' do not
>>>>>>>>> match any of the regexes: 'pinctrl-[0-9]+'
>>>>>>>>> "
>>>>>>>>>
>>>>>>>>> Set additionalProperties to true to address the issue.
>>>>>>>>
>>>>>>>> I do not see anything addressed here, except making the binding
>>>>>>>> accepting anything anywhere...
>>>>>>>
>>>>>>> I not wanna add vendor protocols in arm,scmi.yaml, so will
>>>>>>> introduce a new yaml imx.scmi.yaml which add i.MX SCMI protocol
>> extension.
>>>>>>>
>>>>>>> With additionalProperties set to false, I not know how, please suggest.
>>>>>>
>>>>>> First of all, you cannot affect negatively existing devices (their
>>>>>> bindings) and your patch does exactly that. This should make you
>>>>>> thing what is the correct approach...
>>>>>>
>>>>>> Rob gave you the comment about missing compatible - you still did
>>>>>> not address that.
>>>>>
>>>>> I added the compatible in patch 2/6 in the examples "compatible =
>>>> "arm,scmi";"
>>>>
>>>> So you claim that your vendor extensions are the same or fully
>>>> compatible with arm,scmi and you add nothing... Are your
>>>> extensions/protocol valid for arm,scmi?
>>>
>>> Yes. They are valid for arm,scmi.
>>>
>>> If yes, why is this in separate binding. If no, why you use someone
>>>> else's compatible?
>>>
>>> Per SCMI Spec
>>> 0x80-0xFF: Reserved for vendor or platform-specific extensions to this
>>> interface
>>>
>>> i.MX use 0x81 for BBM, 0x84 for MISC. But other vendors will use the
>>> id for their own protocol.
>>
>> So how are they valid for arm,scmi? I don't understand.
>
> arm,scmi is a firmware compatible string. The protocol node is a sub-node.
> I think the arm,scmi is that saying the firmware following
> SCMI spec to implement the protocols.
>
> For vendor reserved ID, firmware also follow the SCMI spec to implement
> their own usage, so from firmware level, it is ARM SCMI spec compatible.
That's not the point. It is obvious that your firmware is compatible
with arm,scmi, but what you try to say in this and revised patch is that
every arm,scmi is compatible with your implementation. What you are
saying is that 0x84 is MISC protocol for every firmware, Qualcomm, NXP,
Samsung, TI, Mediatek etc.
I claim it is not true. 0x84 is not MISC for Qualcomm, for example.
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 0/2] Set PHY address of MT7531 switch to 0x1f on MediaTek arm64 boards
From: Arınç ÜNAL @ 2024-04-08 7:22 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: mithat.guner, erkin.bozoglu, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek
In-Reply-To: <ff196055-ecd8-4563-bc01-ff2533a07109@arinc9.com>
On 31.03.2024 12:28, arinc.unal@arinc9.com wrote:
> On 14.03.2024 15:20, Arınç ÜNAL via B4 Relay wrote:
>> Hello.
>>
>> This is a small patch series setting the PHY address of MT7531 to 0x1f on
>> all boards that have the switch.
>>
>> Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com>
>> ---
>> Arınç ÜNAL (2):
>> arm64: dts: mediatek: mt7622: set PHY address of MT7531 switch to 0x1f
>> arm64: dts: mediatek: mt7986: set PHY address of MT7531 switch to 0x1f
>>
>> arch/arm64/boot/dts/mediatek/mt7622-bananapi-bpi-r64.dts | 4 ++--
>> arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts | 4 ++--
>> arch/arm64/boot/dts/mediatek/mt7986a-bananapi-bpi-r3.dts | 4 ++--
>> arch/arm64/boot/dts/mediatek/mt7986a-rfb.dts | 4 ++--
>> arch/arm64/boot/dts/mediatek/mt7986b-rfb.dts | 4 ++--
>> 5 files changed, 10 insertions(+), 10 deletions(-)
>> ---
>> base-commit: ba90af39ba57b3fe3ecfdba0c87a80d20c7b788d
>> change-id: 20240314-for-mediatek-mt7531-phy-address-9d0b4cfeca21
>>
>> Best regards,
>
> Reminder that this patch series is waiting.
Another reminder that this patch series is waiting to be applied.
Arınç
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/4] KVM: delete .change_pte MMU notifier callback
From: maobibo @ 2024-04-08 7:23 UTC (permalink / raw)
To: Paolo Bonzini, linux-kernel, kvm
Cc: Marc Zyngier, Oliver Upton, Tianrui Zhao, Thomas Bogendoerfer,
Nicholas Piggin, Anup Patel, Atish Patra, Sean Christopherson,
Andrew Morton, David Hildenbrand, linux-arm-kernel, kvmarm,
loongarch, linux-mips, linuxppc-dev, kvm-riscv, linux-mm,
linux-trace-kernel, linux-perf-users
In-Reply-To: <20240405115815.3226315-2-pbonzini@redhat.com>
On 2024/4/5 下午7:58, Paolo Bonzini wrote:
> The .change_pte() MMU notifier callback was intended as an
> optimization. The original point of it was that KSM could tell KVM to flip
> its secondary PTE to a new location without having to first zap it. At
> the time there was also an .invalidate_page() callback; both of them were
> *not* bracketed by calls to mmu_notifier_invalidate_range_{start,end}(),
> and .invalidate_page() also doubled as a fallback implementation of
> change_pte().
>
> Later on, however, both callbacks were changed to occur within an
> invalidate_range_start/end() block.
>
> In the case of .change_pte(), commit 6bdb913f0a70 ("mm: wrap calls to
> set_pte_at_notify with invalidate_range_start and invalidate_range_end",
> 2012-10-09) did so to remove the fallback from .invalidate_page() to
> change_pte() and allow sleepable .invalidate_page() hooks.
>
> This however made KVM's usage of the .change_pte() callback completely
> moot, because KVM unmaps the sPTEs during .invalidate_range_start()
> and therefore .change_pte() has no hope of finding a sPTE to change.
> Drop the generic KVM code that dispatches to kvm_set_spte_gfn(), as
> well as all the architecture specific implementations.
>
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> ---
> arch/arm64/kvm/mmu.c | 34 -----------------
> arch/loongarch/include/asm/kvm_host.h | 1 -
> arch/loongarch/kvm/mmu.c | 32 ----------------
> arch/mips/kvm/mmu.c | 30 ---------------
> arch/powerpc/include/asm/kvm_ppc.h | 1 -
> arch/powerpc/kvm/book3s.c | 5 ---
> arch/powerpc/kvm/book3s.h | 1 -
> arch/powerpc/kvm/book3s_64_mmu_hv.c | 12 ------
> arch/powerpc/kvm/book3s_hv.c | 1 -
> arch/powerpc/kvm/book3s_pr.c | 7 ----
> arch/powerpc/kvm/e500_mmu_host.c | 6 ---
> arch/riscv/kvm/mmu.c | 20 ----------
> arch/x86/kvm/mmu/mmu.c | 54 +--------------------------
> arch/x86/kvm/mmu/spte.c | 16 --------
> arch/x86/kvm/mmu/spte.h | 2 -
> arch/x86/kvm/mmu/tdp_mmu.c | 46 -----------------------
> arch/x86/kvm/mmu/tdp_mmu.h | 1 -
> include/linux/kvm_host.h | 2 -
> include/trace/events/kvm.h | 15 --------
> virt/kvm/kvm_main.c | 43 ---------------------
> 20 files changed, 2 insertions(+), 327 deletions(-)
>
> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> index dc04bc767865..ff17849be9f4 100644
> --- a/arch/arm64/kvm/mmu.c
> +++ b/arch/arm64/kvm/mmu.c
> @@ -1768,40 +1768,6 @@ bool kvm_unmap_gfn_range(struct kvm *kvm, struct kvm_gfn_range *range)
> return false;
> }
>
> -bool kvm_set_spte_gfn(struct kvm *kvm, struct kvm_gfn_range *range)
> -{
> - kvm_pfn_t pfn = pte_pfn(range->arg.pte);
> -
> - if (!kvm->arch.mmu.pgt)
> - return false;
> -
> - WARN_ON(range->end - range->start != 1);
> -
> - /*
> - * If the page isn't tagged, defer to user_mem_abort() for sanitising
> - * the MTE tags. The S2 pte should have been unmapped by
> - * mmu_notifier_invalidate_range_end().
> - */
> - if (kvm_has_mte(kvm) && !page_mte_tagged(pfn_to_page(pfn)))
> - return false;
> -
> - /*
> - * We've moved a page around, probably through CoW, so let's treat
> - * it just like a translation fault and the map handler will clean
> - * the cache to the PoC.
> - *
> - * The MMU notifiers will have unmapped a huge PMD before calling
> - * ->change_pte() (which in turn calls kvm_set_spte_gfn()) and
> - * therefore we never need to clear out a huge PMD through this
> - * calling path and a memcache is not required.
> - */
> - kvm_pgtable_stage2_map(kvm->arch.mmu.pgt, range->start << PAGE_SHIFT,
> - PAGE_SIZE, __pfn_to_phys(pfn),
> - KVM_PGTABLE_PROT_R, NULL, 0);
> -
> - return false;
> -}
> -
> bool kvm_age_gfn(struct kvm *kvm, struct kvm_gfn_range *range)
> {
> u64 size = (range->end - range->start) << PAGE_SHIFT;
> diff --git a/arch/loongarch/include/asm/kvm_host.h b/arch/loongarch/include/asm/kvm_host.h
> index 2d62f7b0d377..69305441f40d 100644
> --- a/arch/loongarch/include/asm/kvm_host.h
> +++ b/arch/loongarch/include/asm/kvm_host.h
> @@ -203,7 +203,6 @@ void kvm_flush_tlb_all(void);
> void kvm_flush_tlb_gpa(struct kvm_vcpu *vcpu, unsigned long gpa);
> int kvm_handle_mm_fault(struct kvm_vcpu *vcpu, unsigned long badv, bool write);
>
> -void kvm_set_spte_hva(struct kvm *kvm, unsigned long hva, pte_t pte);
> int kvm_unmap_hva_range(struct kvm *kvm, unsigned long start, unsigned long end, bool blockable);
> int kvm_age_hva(struct kvm *kvm, unsigned long start, unsigned long end);
> int kvm_test_age_hva(struct kvm *kvm, unsigned long hva);
> diff --git a/arch/loongarch/kvm/mmu.c b/arch/loongarch/kvm/mmu.c
> index a556cff35740..98883aa23ab8 100644
> --- a/arch/loongarch/kvm/mmu.c
> +++ b/arch/loongarch/kvm/mmu.c
> @@ -494,38 +494,6 @@ bool kvm_unmap_gfn_range(struct kvm *kvm, struct kvm_gfn_range *range)
> range->end << PAGE_SHIFT, &ctx);
> }
>
> -bool kvm_set_spte_gfn(struct kvm *kvm, struct kvm_gfn_range *range)
> -{
> - unsigned long prot_bits;
> - kvm_pte_t *ptep;
> - kvm_pfn_t pfn = pte_pfn(range->arg.pte);
> - gpa_t gpa = range->start << PAGE_SHIFT;
> -
> - ptep = kvm_populate_gpa(kvm, NULL, gpa, 0);
> - if (!ptep)
> - return false;
> -
> - /* Replacing an absent or old page doesn't need flushes */
> - if (!kvm_pte_present(NULL, ptep) || !kvm_pte_young(*ptep)) {
> - kvm_set_pte(ptep, 0);
> - return false;
> - }
> -
> - /* Fill new pte if write protected or page migrated */
> - prot_bits = _PAGE_PRESENT | __READABLE;
> - prot_bits |= _CACHE_MASK & pte_val(range->arg.pte);
> -
> - /*
> - * Set _PAGE_WRITE or _PAGE_DIRTY iff old and new pte both support
> - * _PAGE_WRITE for map_page_fast if next page write fault
> - * _PAGE_DIRTY since gpa has already recorded as dirty page
> - */
> - prot_bits |= __WRITEABLE & *ptep & pte_val(range->arg.pte);
> - kvm_set_pte(ptep, kvm_pfn_pte(pfn, __pgprot(prot_bits)));
> -
> - return true;
> -}
> -
Thanks for cleanup. And for kvm loongarch:
Reviewed-by: Bibo Mao <maobibo@loongson.cn>
> bool kvm_age_gfn(struct kvm *kvm, struct kvm_gfn_range *range)
> {
> kvm_ptw_ctx ctx;
> diff --git a/arch/mips/kvm/mmu.c b/arch/mips/kvm/mmu.c
> index 467ee6b95ae1..c17157e700c0 100644
> --- a/arch/mips/kvm/mmu.c
> +++ b/arch/mips/kvm/mmu.c
> @@ -444,36 +444,6 @@ bool kvm_unmap_gfn_range(struct kvm *kvm, struct kvm_gfn_range *range)
> return true;
> }
>
> -bool kvm_set_spte_gfn(struct kvm *kvm, struct kvm_gfn_range *range)
> -{
> - gpa_t gpa = range->start << PAGE_SHIFT;
> - pte_t hva_pte = range->arg.pte;
> - pte_t *gpa_pte = kvm_mips_pte_for_gpa(kvm, NULL, gpa);
> - pte_t old_pte;
> -
> - if (!gpa_pte)
> - return false;
> -
> - /* Mapping may need adjusting depending on memslot flags */
> - old_pte = *gpa_pte;
> - if (range->slot->flags & KVM_MEM_LOG_DIRTY_PAGES && !pte_dirty(old_pte))
> - hva_pte = pte_mkclean(hva_pte);
> - else if (range->slot->flags & KVM_MEM_READONLY)
> - hva_pte = pte_wrprotect(hva_pte);
> -
> - set_pte(gpa_pte, hva_pte);
> -
> - /* Replacing an absent or old page doesn't need flushes */
> - if (!pte_present(old_pte) || !pte_young(old_pte))
> - return false;
> -
> - /* Pages swapped, aged, moved, or cleaned require flushes */
> - return !pte_present(hva_pte) ||
> - !pte_young(hva_pte) ||
> - pte_pfn(old_pte) != pte_pfn(hva_pte) ||
> - (pte_dirty(old_pte) && !pte_dirty(hva_pte));
> -}
> -
> bool kvm_age_gfn(struct kvm *kvm, struct kvm_gfn_range *range)
> {
> return kvm_mips_mkold_gpa_pt(kvm, range->start, range->end);
> diff --git a/arch/powerpc/include/asm/kvm_ppc.h b/arch/powerpc/include/asm/kvm_ppc.h
> index 3281215097cc..ca3829d47ab7 100644
> --- a/arch/powerpc/include/asm/kvm_ppc.h
> +++ b/arch/powerpc/include/asm/kvm_ppc.h
> @@ -287,7 +287,6 @@ struct kvmppc_ops {
> bool (*unmap_gfn_range)(struct kvm *kvm, struct kvm_gfn_range *range);
> bool (*age_gfn)(struct kvm *kvm, struct kvm_gfn_range *range);
> bool (*test_age_gfn)(struct kvm *kvm, struct kvm_gfn_range *range);
> - bool (*set_spte_gfn)(struct kvm *kvm, struct kvm_gfn_range *range);
> void (*free_memslot)(struct kvm_memory_slot *slot);
> int (*init_vm)(struct kvm *kvm);
> void (*destroy_vm)(struct kvm *kvm);
> diff --git a/arch/powerpc/kvm/book3s.c b/arch/powerpc/kvm/book3s.c
> index 8acec144120e..0d0624088e6b 100644
> --- a/arch/powerpc/kvm/book3s.c
> +++ b/arch/powerpc/kvm/book3s.c
> @@ -899,11 +899,6 @@ bool kvm_test_age_gfn(struct kvm *kvm, struct kvm_gfn_range *range)
> return kvm->arch.kvm_ops->test_age_gfn(kvm, range);
> }
>
> -bool kvm_set_spte_gfn(struct kvm *kvm, struct kvm_gfn_range *range)
> -{
> - return kvm->arch.kvm_ops->set_spte_gfn(kvm, range);
> -}
> -
> int kvmppc_core_init_vm(struct kvm *kvm)
> {
>
> diff --git a/arch/powerpc/kvm/book3s.h b/arch/powerpc/kvm/book3s.h
> index 58391b4b32ed..4aa2ab89afbc 100644
> --- a/arch/powerpc/kvm/book3s.h
> +++ b/arch/powerpc/kvm/book3s.h
> @@ -12,7 +12,6 @@ extern void kvmppc_core_flush_memslot_hv(struct kvm *kvm,
> extern bool kvm_unmap_gfn_range_hv(struct kvm *kvm, struct kvm_gfn_range *range);
> extern bool kvm_age_gfn_hv(struct kvm *kvm, struct kvm_gfn_range *range);
> extern bool kvm_test_age_gfn_hv(struct kvm *kvm, struct kvm_gfn_range *range);
> -extern bool kvm_set_spte_gfn_hv(struct kvm *kvm, struct kvm_gfn_range *range);
>
> extern int kvmppc_mmu_init_pr(struct kvm_vcpu *vcpu);
> extern void kvmppc_mmu_destroy_pr(struct kvm_vcpu *vcpu);
> diff --git a/arch/powerpc/kvm/book3s_64_mmu_hv.c b/arch/powerpc/kvm/book3s_64_mmu_hv.c
> index 2b1f0cdd8c18..1b51b1c4713b 100644
> --- a/arch/powerpc/kvm/book3s_64_mmu_hv.c
> +++ b/arch/powerpc/kvm/book3s_64_mmu_hv.c
> @@ -1010,18 +1010,6 @@ bool kvm_test_age_gfn_hv(struct kvm *kvm, struct kvm_gfn_range *range)
> return kvm_test_age_rmapp(kvm, range->slot, range->start);
> }
>
> -bool kvm_set_spte_gfn_hv(struct kvm *kvm, struct kvm_gfn_range *range)
> -{
> - WARN_ON(range->start + 1 != range->end);
> -
> - if (kvm_is_radix(kvm))
> - kvm_unmap_radix(kvm, range->slot, range->start);
> - else
> - kvm_unmap_rmapp(kvm, range->slot, range->start);
> -
> - return false;
> -}
> -
> static int vcpus_running(struct kvm *kvm)
> {
> return atomic_read(&kvm->arch.vcpus_running) != 0;
> diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
> index 8e86eb577eb8..35cb014a0c51 100644
> --- a/arch/powerpc/kvm/book3s_hv.c
> +++ b/arch/powerpc/kvm/book3s_hv.c
> @@ -6364,7 +6364,6 @@ static struct kvmppc_ops kvm_ops_hv = {
> .unmap_gfn_range = kvm_unmap_gfn_range_hv,
> .age_gfn = kvm_age_gfn_hv,
> .test_age_gfn = kvm_test_age_gfn_hv,
> - .set_spte_gfn = kvm_set_spte_gfn_hv,
> .free_memslot = kvmppc_core_free_memslot_hv,
> .init_vm = kvmppc_core_init_vm_hv,
> .destroy_vm = kvmppc_core_destroy_vm_hv,
> diff --git a/arch/powerpc/kvm/book3s_pr.c b/arch/powerpc/kvm/book3s_pr.c
> index 5b92619a05fd..a7d7137ea0c8 100644
> --- a/arch/powerpc/kvm/book3s_pr.c
> +++ b/arch/powerpc/kvm/book3s_pr.c
> @@ -461,12 +461,6 @@ static bool kvm_test_age_gfn_pr(struct kvm *kvm, struct kvm_gfn_range *range)
> return false;
> }
>
> -static bool kvm_set_spte_gfn_pr(struct kvm *kvm, struct kvm_gfn_range *range)
> -{
> - /* The page will get remapped properly on its next fault */
> - return do_kvm_unmap_gfn(kvm, range);
> -}
> -
> /*****************************************/
>
> static void kvmppc_set_msr_pr(struct kvm_vcpu *vcpu, u64 msr)
> @@ -2071,7 +2065,6 @@ static struct kvmppc_ops kvm_ops_pr = {
> .unmap_gfn_range = kvm_unmap_gfn_range_pr,
> .age_gfn = kvm_age_gfn_pr,
> .test_age_gfn = kvm_test_age_gfn_pr,
> - .set_spte_gfn = kvm_set_spte_gfn_pr,
> .free_memslot = kvmppc_core_free_memslot_pr,
> .init_vm = kvmppc_core_init_vm_pr,
> .destroy_vm = kvmppc_core_destroy_vm_pr,
> diff --git a/arch/powerpc/kvm/e500_mmu_host.c b/arch/powerpc/kvm/e500_mmu_host.c
> index ccb8f16ffe41..c664fdec75b1 100644
> --- a/arch/powerpc/kvm/e500_mmu_host.c
> +++ b/arch/powerpc/kvm/e500_mmu_host.c
> @@ -747,12 +747,6 @@ bool kvm_test_age_gfn(struct kvm *kvm, struct kvm_gfn_range *range)
> return false;
> }
>
> -bool kvm_set_spte_gfn(struct kvm *kvm, struct kvm_gfn_range *range)
> -{
> - /* The page will get remapped properly on its next fault */
> - return kvm_e500_mmu_unmap_gfn(kvm, range);
> -}
> -
> /*****************************************/
>
> int e500_mmu_host_init(struct kvmppc_vcpu_e500 *vcpu_e500)
> diff --git a/arch/riscv/kvm/mmu.c b/arch/riscv/kvm/mmu.c
> index a9e2fd7245e1..b63650f9b966 100644
> --- a/arch/riscv/kvm/mmu.c
> +++ b/arch/riscv/kvm/mmu.c
> @@ -550,26 +550,6 @@ bool kvm_unmap_gfn_range(struct kvm *kvm, struct kvm_gfn_range *range)
> return false;
> }
>
> -bool kvm_set_spte_gfn(struct kvm *kvm, struct kvm_gfn_range *range)
> -{
> - int ret;
> - kvm_pfn_t pfn = pte_pfn(range->arg.pte);
> -
> - if (!kvm->arch.pgd)
> - return false;
> -
> - WARN_ON(range->end - range->start != 1);
> -
> - ret = gstage_map_page(kvm, NULL, range->start << PAGE_SHIFT,
> - __pfn_to_phys(pfn), PAGE_SIZE, true, true);
> - if (ret) {
> - kvm_debug("Failed to map G-stage page (error %d)\n", ret);
> - return true;
> - }
> -
> - return false;
> -}
> -
> bool kvm_age_gfn(struct kvm *kvm, struct kvm_gfn_range *range)
> {
> pte_t *ptep;
> diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
> index 0049d49aa913..87ba2a9da196 100644
> --- a/arch/x86/kvm/mmu/mmu.c
> +++ b/arch/x86/kvm/mmu/mmu.c
> @@ -432,8 +432,8 @@ static u64 __update_clear_spte_slow(u64 *sptep, u64 spte)
> * The idea using the light way get the spte on x86_32 guest is from
> * gup_get_pte (mm/gup.c).
> *
> - * An spte tlb flush may be pending, because kvm_set_pte_rmap
> - * coalesces them and we are running out of the MMU lock. Therefore
> + * An spte tlb flush may be pending, because they are coalesced and
> + * we are running out of the MMU lock. Therefore
> * we need to protect against in-progress updates of the spte.
> *
> * Reading the spte while an update is in progress may get the old value
> @@ -1454,43 +1454,6 @@ static bool kvm_zap_rmap(struct kvm *kvm, struct kvm_rmap_head *rmap_head,
> return __kvm_zap_rmap(kvm, rmap_head, slot);
> }
>
> -static bool kvm_set_pte_rmap(struct kvm *kvm, struct kvm_rmap_head *rmap_head,
> - struct kvm_memory_slot *slot, gfn_t gfn, int level,
> - pte_t pte)
> -{
> - u64 *sptep;
> - struct rmap_iterator iter;
> - bool need_flush = false;
> - u64 new_spte;
> - kvm_pfn_t new_pfn;
> -
> - WARN_ON_ONCE(pte_huge(pte));
> - new_pfn = pte_pfn(pte);
> -
> -restart:
> - for_each_rmap_spte(rmap_head, &iter, sptep) {
> - need_flush = true;
> -
> - if (pte_write(pte)) {
> - kvm_zap_one_rmap_spte(kvm, rmap_head, sptep);
> - goto restart;
> - } else {
> - new_spte = kvm_mmu_changed_pte_notifier_make_spte(
> - *sptep, new_pfn);
> -
> - mmu_spte_clear_track_bits(kvm, sptep);
> - mmu_spte_set(sptep, new_spte);
> - }
> - }
> -
> - if (need_flush && kvm_available_flush_remote_tlbs_range()) {
> - kvm_flush_remote_tlbs_gfn(kvm, gfn, level);
> - return false;
> - }
> -
> - return need_flush;
> -}
> -
> struct slot_rmap_walk_iterator {
> /* input fields. */
> const struct kvm_memory_slot *slot;
> @@ -1596,19 +1559,6 @@ bool kvm_unmap_gfn_range(struct kvm *kvm, struct kvm_gfn_range *range)
> return flush;
> }
>
> -bool kvm_set_spte_gfn(struct kvm *kvm, struct kvm_gfn_range *range)
> -{
> - bool flush = false;
> -
> - if (kvm_memslots_have_rmaps(kvm))
> - flush = kvm_handle_gfn_range(kvm, range, kvm_set_pte_rmap);
> -
> - if (tdp_mmu_enabled)
> - flush |= kvm_tdp_mmu_set_spte_gfn(kvm, range);
> -
> - return flush;
> -}
> -
> static bool kvm_age_rmap(struct kvm *kvm, struct kvm_rmap_head *rmap_head,
> struct kvm_memory_slot *slot, gfn_t gfn, int level,
> pte_t unused)
> diff --git a/arch/x86/kvm/mmu/spte.c b/arch/x86/kvm/mmu/spte.c
> index 318135daf685..283af5b90016 100644
> --- a/arch/x86/kvm/mmu/spte.c
> +++ b/arch/x86/kvm/mmu/spte.c
> @@ -322,22 +322,6 @@ u64 make_nonleaf_spte(u64 *child_pt, bool ad_disabled)
> return spte;
> }
>
> -u64 kvm_mmu_changed_pte_notifier_make_spte(u64 old_spte, kvm_pfn_t new_pfn)
> -{
> - u64 new_spte;
> -
> - new_spte = old_spte & ~SPTE_BASE_ADDR_MASK;
> - new_spte |= (u64)new_pfn << PAGE_SHIFT;
> -
> - new_spte &= ~PT_WRITABLE_MASK;
> - new_spte &= ~shadow_host_writable_mask;
> - new_spte &= ~shadow_mmu_writable_mask;
> -
> - new_spte = mark_spte_for_access_track(new_spte);
> -
> - return new_spte;
> -}
> -
> u64 mark_spte_for_access_track(u64 spte)
> {
> if (spte_ad_enabled(spte))
> diff --git a/arch/x86/kvm/mmu/spte.h b/arch/x86/kvm/mmu/spte.h
> index 1a163aee9ec6..92da4c419171 100644
> --- a/arch/x86/kvm/mmu/spte.h
> +++ b/arch/x86/kvm/mmu/spte.h
> @@ -511,8 +511,6 @@ static inline u64 restore_acc_track_spte(u64 spte)
> return spte;
> }
>
> -u64 kvm_mmu_changed_pte_notifier_make_spte(u64 old_spte, kvm_pfn_t new_pfn);
> -
> void __init kvm_mmu_spte_module_init(void);
> void kvm_mmu_reset_all_pte_masks(void);
>
> diff --git a/arch/x86/kvm/mmu/tdp_mmu.c b/arch/x86/kvm/mmu/tdp_mmu.c
> index 3627744fcab6..fbb86932b766 100644
> --- a/arch/x86/kvm/mmu/tdp_mmu.c
> +++ b/arch/x86/kvm/mmu/tdp_mmu.c
> @@ -1250,52 +1250,6 @@ bool kvm_tdp_mmu_test_age_gfn(struct kvm *kvm, struct kvm_gfn_range *range)
> return kvm_tdp_mmu_handle_gfn(kvm, range, test_age_gfn);
> }
>
> -static bool set_spte_gfn(struct kvm *kvm, struct tdp_iter *iter,
> - struct kvm_gfn_range *range)
> -{
> - u64 new_spte;
> -
> - /* Huge pages aren't expected to be modified without first being zapped. */
> - WARN_ON_ONCE(pte_huge(range->arg.pte) || range->start + 1 != range->end);
> -
> - if (iter->level != PG_LEVEL_4K ||
> - !is_shadow_present_pte(iter->old_spte))
> - return false;
> -
> - /*
> - * Note, when changing a read-only SPTE, it's not strictly necessary to
> - * zero the SPTE before setting the new PFN, but doing so preserves the
> - * invariant that the PFN of a present * leaf SPTE can never change.
> - * See handle_changed_spte().
> - */
> - tdp_mmu_iter_set_spte(kvm, iter, SHADOW_NONPRESENT_VALUE);
> -
> - if (!pte_write(range->arg.pte)) {
> - new_spte = kvm_mmu_changed_pte_notifier_make_spte(iter->old_spte,
> - pte_pfn(range->arg.pte));
> -
> - tdp_mmu_iter_set_spte(kvm, iter, new_spte);
> - }
> -
> - return true;
> -}
> -
> -/*
> - * Handle the changed_pte MMU notifier for the TDP MMU.
> - * data is a pointer to the new pte_t mapping the HVA specified by the MMU
> - * notifier.
> - * Returns non-zero if a flush is needed before releasing the MMU lock.
> - */
> -bool kvm_tdp_mmu_set_spte_gfn(struct kvm *kvm, struct kvm_gfn_range *range)
> -{
> - /*
> - * No need to handle the remote TLB flush under RCU protection, the
> - * target SPTE _must_ be a leaf SPTE, i.e. cannot result in freeing a
> - * shadow page. See the WARN on pfn_changed in handle_changed_spte().
> - */
> - return kvm_tdp_mmu_handle_gfn(kvm, range, set_spte_gfn);
> -}
> -
> /*
> * Remove write access from all SPTEs at or above min_level that map GFNs
> * [start, end). Returns true if an SPTE has been changed and the TLBs need to
> diff --git a/arch/x86/kvm/mmu/tdp_mmu.h b/arch/x86/kvm/mmu/tdp_mmu.h
> index 6e1ea04ca885..58b55e61bd33 100644
> --- a/arch/x86/kvm/mmu/tdp_mmu.h
> +++ b/arch/x86/kvm/mmu/tdp_mmu.h
> @@ -31,7 +31,6 @@ bool kvm_tdp_mmu_unmap_gfn_range(struct kvm *kvm, struct kvm_gfn_range *range,
> bool flush);
> bool kvm_tdp_mmu_age_gfn_range(struct kvm *kvm, struct kvm_gfn_range *range);
> bool kvm_tdp_mmu_test_age_gfn(struct kvm *kvm, struct kvm_gfn_range *range);
> -bool kvm_tdp_mmu_set_spte_gfn(struct kvm *kvm, struct kvm_gfn_range *range);
>
> bool kvm_tdp_mmu_wrprot_slot(struct kvm *kvm,
> const struct kvm_memory_slot *slot, int min_level);
> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> index ab439706ea2f..8dea11701ab2 100644
> --- a/include/linux/kvm_host.h
> +++ b/include/linux/kvm_host.h
> @@ -259,7 +259,6 @@ int kvm_async_pf_wakeup_all(struct kvm_vcpu *vcpu);
>
> #ifdef CONFIG_KVM_GENERIC_MMU_NOTIFIER
> union kvm_mmu_notifier_arg {
> - pte_t pte;
> unsigned long attributes;
> };
>
> @@ -273,7 +272,6 @@ struct kvm_gfn_range {
> bool kvm_unmap_gfn_range(struct kvm *kvm, struct kvm_gfn_range *range);
> bool kvm_age_gfn(struct kvm *kvm, struct kvm_gfn_range *range);
> bool kvm_test_age_gfn(struct kvm *kvm, struct kvm_gfn_range *range);
> -bool kvm_set_spte_gfn(struct kvm *kvm, struct kvm_gfn_range *range);
> #endif
>
> enum {
> diff --git a/include/trace/events/kvm.h b/include/trace/events/kvm.h
> index 011fba6b5552..74e40d5d4af4 100644
> --- a/include/trace/events/kvm.h
> +++ b/include/trace/events/kvm.h
> @@ -456,21 +456,6 @@ TRACE_EVENT(kvm_unmap_hva_range,
> __entry->start, __entry->end)
> );
>
> -TRACE_EVENT(kvm_set_spte_hva,
> - TP_PROTO(unsigned long hva),
> - TP_ARGS(hva),
> -
> - TP_STRUCT__entry(
> - __field( unsigned long, hva )
> - ),
> -
> - TP_fast_assign(
> - __entry->hva = hva;
> - ),
> -
> - TP_printk("mmu notifier set pte hva: %#016lx", __entry->hva)
> -);
> -
> TRACE_EVENT(kvm_age_hva,
> TP_PROTO(unsigned long start, unsigned long end),
> TP_ARGS(start, end),
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index 4eb8afd0b961..2fcd9979752a 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -717,48 +717,6 @@ static __always_inline int kvm_handle_hva_range_no_flush(struct mmu_notifier *mn
> return __kvm_handle_hva_range(kvm, &range).ret;
> }
>
> -static bool kvm_change_spte_gfn(struct kvm *kvm, struct kvm_gfn_range *range)
> -{
> - /*
> - * Skipping invalid memslots is correct if and only change_pte() is
> - * surrounded by invalidate_range_{start,end}(), which is currently
> - * guaranteed by the primary MMU. If that ever changes, KVM needs to
> - * unmap the memslot instead of skipping the memslot to ensure that KVM
> - * doesn't hold references to the old PFN.
> - */
> - WARN_ON_ONCE(!READ_ONCE(kvm->mn_active_invalidate_count));
> -
> - if (range->slot->flags & KVM_MEMSLOT_INVALID)
> - return false;
> -
> - return kvm_set_spte_gfn(kvm, range);
> -}
> -
> -static void kvm_mmu_notifier_change_pte(struct mmu_notifier *mn,
> - struct mm_struct *mm,
> - unsigned long address,
> - pte_t pte)
> -{
> - struct kvm *kvm = mmu_notifier_to_kvm(mn);
> - const union kvm_mmu_notifier_arg arg = { .pte = pte };
> -
> - trace_kvm_set_spte_hva(address);
> -
> - /*
> - * .change_pte() must be surrounded by .invalidate_range_{start,end}().
> - * If mmu_invalidate_in_progress is zero, then no in-progress
> - * invalidations, including this one, found a relevant memslot at
> - * start(); rechecking memslots here is unnecessary. Note, a false
> - * positive (count elevated by a different invalidation) is sub-optimal
> - * but functionally ok.
> - */
> - WARN_ON_ONCE(!READ_ONCE(kvm->mn_active_invalidate_count));
> - if (!READ_ONCE(kvm->mmu_invalidate_in_progress))
> - return;
> -
> - kvm_handle_hva_range(mn, address, address + 1, arg, kvm_change_spte_gfn);
> -}
> -
> void kvm_mmu_invalidate_begin(struct kvm *kvm)
> {
> lockdep_assert_held_write(&kvm->mmu_lock);
> @@ -976,7 +934,6 @@ static const struct mmu_notifier_ops kvm_mmu_notifier_ops = {
> .clear_flush_young = kvm_mmu_notifier_clear_flush_young,
> .clear_young = kvm_mmu_notifier_clear_young,
> .test_young = kvm_mmu_notifier_test_young,
> - .change_pte = kvm_mmu_notifier_change_pte,
> .release = kvm_mmu_notifier_release,
> };
>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set additionalProperties to true
From: Peng Fan @ 2024-04-08 7:23 UTC (permalink / raw)
To: Krzysztof Kozlowski, Peng Fan (OSS), Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Sudeep Holla,
Cristian Marussi
Cc: devicetree@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <e6333665-8051-43b1-9e98-f76262ddbc35@kernel.org>
> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set
> additionalProperties to true
>
> On 08/04/2024 08:08, Peng Fan wrote:
> >> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set
> >> additionalProperties to true
> >>
> >> On 08/04/2024 01:50, Peng Fan wrote:
> >>>> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set
> >>>> additionalProperties to true
> >>>>
> >>>> On 07/04/2024 12:04, Peng Fan wrote:
> >>>>>> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set
> >>>>>> additionalProperties to true
> >>>>>>
> >>>>>> On 07/04/2024 02:37, Peng Fan wrote:
> >>>>>>>> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi:
> >>>>>>>> set additionalProperties to true
> >>>>>>>>
> >>>>>>>> On 05/04/2024 14:39, Peng Fan (OSS) wrote:
> >>>>>>>>> From: Peng Fan <peng.fan@nxp.com>
> >>>>>>>>>
> >>>>>>>>> When adding vendor extension protocols, there is dt-schema
> >> warning:
> >>>>>>>>> "
> >>>>>>>>> imx,scmi.example.dtb: scmi: 'protocol@81', 'protocol@84' do
> >>>>>>>>> not match any of the regexes: 'pinctrl-[0-9]+'
> >>>>>>>>> "
> >>>>>>>>>
> >>>>>>>>> Set additionalProperties to true to address the issue.
> >>>>>>>>
> >>>>>>>> I do not see anything addressed here, except making the binding
> >>>>>>>> accepting anything anywhere...
> >>>>>>>
> >>>>>>> I not wanna add vendor protocols in arm,scmi.yaml, so will
> >>>>>>> introduce a new yaml imx.scmi.yaml which add i.MX SCMI protocol
> >> extension.
> >>>>>>>
> >>>>>>> With additionalProperties set to false, I not know how, please
> suggest.
> >>>>>>
> >>>>>> First of all, you cannot affect negatively existing devices
> >>>>>> (their
> >>>>>> bindings) and your patch does exactly that. This should make you
> >>>>>> thing what is the correct approach...
> >>>>>>
> >>>>>> Rob gave you the comment about missing compatible - you still did
> >>>>>> not address that.
> >>>>>
> >>>>> I added the compatible in patch 2/6 in the examples "compatible =
> >>>> "arm,scmi";"
> >>>>
> >>>> So you claim that your vendor extensions are the same or fully
> >>>> compatible with arm,scmi and you add nothing... Are your
> >>>> extensions/protocol valid for arm,scmi?
> >>>
> >>> Yes. They are valid for arm,scmi.
> >>>
> >>> If yes, why is this in separate binding. If no, why you use someone
> >>>> else's compatible?
> >>>
> >>> Per SCMI Spec
> >>> 0x80-0xFF: Reserved for vendor or platform-specific extensions to
> >>> this interface
> >>>
> >>> i.MX use 0x81 for BBM, 0x84 for MISC. But other vendors will use the
> >>> id for their own protocol.
> >>
> >> So how are they valid for arm,scmi? I don't understand.
> >
> > arm,scmi is a firmware compatible string. The protocol node is a sub-node.
> > I think the arm,scmi is that saying the firmware following SCMI spec
> > to implement the protocols.
> >
> > For vendor reserved ID, firmware also follow the SCMI spec to
> > implement their own usage, so from firmware level, it is ARM SCMI spec
> compatible.
>
> That's not the point. It is obvious that your firmware is compatible with
> arm,scmi, but what you try to say in this and revised patch is that every
> arm,scmi is compatible with your implementation. What you are saying is
> that 0x84 is MISC protocol for every firmware, Qualcomm, NXP, Samsung, TI,
> Mediatek etc.
>
> I claim it is not true. 0x84 is not MISC for Qualcomm, for example.
You are right. I am lost now on how to add vendor ID support, using
arm,scmi.yaml or adding a new imx,scmi.yaml or else.
Please suggest.
Thanks,
Peng
>
> Best regards,
> Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 0/4] Speed up boot with faster linear map creation
From: Ryan Roberts @ 2024-04-08 7:30 UTC (permalink / raw)
To: Itaru Kitayama
Cc: Catalin Marinas, Will Deacon, Mark Rutland, Ard Biesheuvel,
David Hildenbrand, Donald Dutile, Eric Chanudet, linux-arm-kernel,
linux-kernel
In-Reply-To: <ZhEkif45F0aVvKPx@vm3>
On 06/04/2024 11:31, Itaru Kitayama wrote:
> Hi Ryan,
>
> On Sat, Apr 06, 2024 at 09:32:34AM +0100, Ryan Roberts wrote:
>> Hi Itaru,
>>
>> On 05/04/2024 08:39, Itaru Kitayama wrote:
>>> On Thu, Apr 04, 2024 at 03:33:04PM +0100, Ryan Roberts wrote:
>>>> Hi All,
>>>>
>>>> It turns out that creating the linear map can take a significant proportion of
>>>> the total boot time, especially when rodata=full. And most of the time is spent
>>>> waiting on superfluous tlb invalidation and memory barriers. This series reworks
>>>> the kernel pgtable generation code to significantly reduce the number of those
>>>> TLBIs, ISBs and DSBs. See each patch for details.
>>>>
>>>> The below shows the execution time of map_mem() across a couple of different
>>>> systems with different RAM configurations. We measure after applying each patch
>>>> and show the improvement relative to base (v6.9-rc2):
>>>>
>>>> | Apple M2 VM | Ampere Altra| Ampere Altra| Ampere Altra
>>>> | VM, 16G | VM, 64G | VM, 256G | Metal, 512G
>>>> ---------------|-------------|-------------|-------------|-------------
>>>> | ms (%) | ms (%) | ms (%) | ms (%)
>>>> ---------------|-------------|-------------|-------------|-------------
>>>> base | 153 (0%) | 2227 (0%) | 8798 (0%) | 17442 (0%)
>>>> no-cont-remap | 77 (-49%) | 431 (-81%) | 1727 (-80%) | 3796 (-78%)
>>>> batch-barriers | 13 (-92%) | 162 (-93%) | 655 (-93%) | 1656 (-91%)
>>>> no-alloc-remap | 11 (-93%) | 109 (-95%) | 449 (-95%) | 1257 (-93%)
>>>> lazy-unmap | 6 (-96%) | 61 (-97%) | 257 (-97%) | 838 (-95%)
>>>>
>>>> This series applies on top of v6.9-rc2. All mm selftests pass. I've compile and
>>>> boot tested various PAGE_SIZE and VA size configs.
>>>>
>>>> ---
>>>>
>>>> Changes since v1 [1]
>>>> ====================
>>>>
>>>> - Added Tested-by tags (thanks to Eric and Itaru)
>>>> - Renamed ___set_pte() -> __set_pte_nosync() (per Ard)
>>>> - Reordered patches (biggest impact & least controversial first)
>>>> - Reordered alloc/map/unmap functions in mmu.c to aid reader
>>>> - pte_clear() -> __pte_clear() in clear_fixmap_nosync()
>>>> - Reverted generic p4d_index() which caused x86 build error. Replaced with
>>>> unconditional p4d_index() define under arm64.
>>>>
>>>>
>>>> [1] https://lore.kernel.org/linux-arm-kernel/20240326101448.3453626-1-ryan.roberts@arm.com/
>>>>
>>>> Thanks,
>>>> Ryan
>>>>
>>>>
>>>> Ryan Roberts (4):
>>>> arm64: mm: Don't remap pgtables per-cont(pte|pmd) block
>>>> arm64: mm: Batch dsb and isb when populating pgtables
>>>> arm64: mm: Don't remap pgtables for allocate vs populate
>>>> arm64: mm: Lazily clear pte table mappings from fixmap
>>>>
>>>> arch/arm64/include/asm/fixmap.h | 5 +-
>>>> arch/arm64/include/asm/mmu.h | 8 +
>>>> arch/arm64/include/asm/pgtable.h | 13 +-
>>>> arch/arm64/kernel/cpufeature.c | 10 +-
>>>> arch/arm64/mm/fixmap.c | 11 +
>>>> arch/arm64/mm/mmu.c | 377 +++++++++++++++++++++++--------
>>>> 6 files changed, 319 insertions(+), 105 deletions(-)
>>>>
>>>> --
>>>> 2.25.1
>>>>
>>>
>>> I've build and boot tested the v2 on FVP, base is taken from your
>>> linux-rr repo. Running run_vmtests.sh on v2 left some gup longterm not oks, would you take a look at it? The mm ksefltests used is from your linux-rr repo too.
>>
>> Thanks for taking a look at this.
>>
>> I can't reproduce your issue unfortunately; steps as follows on Apple M2 VM:
>>
>> Config: arm64 defconfig + the following:
>>
>> # Squashfs for snaps, xfs for large file folios.
>> ./scripts/config --enable CONFIG_SQUASHFS_LZ4
>> ./scripts/config --enable CONFIG_SQUASHFS_LZO
>> ./scripts/config --enable CONFIG_SQUASHFS_XZ
>> ./scripts/config --enable CONFIG_SQUASHFS_ZSTD
>> ./scripts/config --enable CONFIG_XFS_FS
>>
>> # For general mm debug.
>> ./scripts/config --enable CONFIG_DEBUG_VM
>> ./scripts/config --enable CONFIG_DEBUG_VM_MAPLE_TREE
>> ./scripts/config --enable CONFIG_DEBUG_VM_RB
>> ./scripts/config --enable CONFIG_DEBUG_VM_PGFLAGS
>> ./scripts/config --enable CONFIG_DEBUG_VM_PGTABLE
>> ./scripts/config --enable CONFIG_PAGE_TABLE_CHECK
>>
>> # For mm selftests.
>> ./scripts/config --enable CONFIG_USERFAULTFD
>> ./scripts/config --enable CONFIG_TEST_VMALLOC
>> ./scripts/config --enable CONFIG_GUP_TEST
>>
>> Running on VM with 12G memory, split across 2 (emulated) NUMA nodes (needed by
>> some mm selftests), with kernel command line to reserve hugetlbs and other
>> features required by some mm selftests:
>>
>> "
>> transparent_hugepage=madvise earlycon root=/dev/vda2 secretmem.enable
>> hugepagesz=1G hugepages=0:2,1:2 hugepagesz=32M hugepages=0:2,1:2
>> default_hugepagesz=2M hugepages=0:64,1:64 hugepagesz=64K hugepages=0:2,1:2
>> "
>>
>> Ubuntu userspace running off XFS rootfs. Build and run mm selftests from same
>> git tree.
>>
>>
>> Although I don't think any of this config should make a difference to gup_longterm.
>>
>> Looks like your errors are all "ftruncate() failed". I've seen this problem on
>> our CI system. There it is due to running the tests from NFS file system. What
>> filesystem are you using? Perhaps you are sharing into the FVP using 9p? That
>> might also be problematic.
>
> That was it. This time I booted up the kernel including your series on
> QEMU on my M1 and executed the gup_longterm program without the ftruncate
> failures. When testing your kernel on FVP, I was executing the script from the FVP's host filesystem using 9p.
I'm not sure exactly what the root cause is. Perhaps there isn't enough space on
the disk? It might be worth enhancing the error log to provide the errno in
tools/testing/selftests/mm/gup_longterm.c.
Thanks,
Ryan
>
> Thanks,
> Itaru.
>
>>
>> Does this problem reproduce with v6.9-rc2, without my patches? I except it
>> probably does?
>>
>> Thanks,
>> Ryan
>>
>>>
>>> Thanks,
>>> Itaru.
>>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 0/3] arm64: dts: hi3798cv200: fix GICR size, add cache info, maintenance irq and GICH, GICV spaces
From: Krzysztof Kozlowski @ 2024-04-08 7:31 UTC (permalink / raw)
To: Wei Xu, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jiancheng Xue, Alex Elder, Peter Griffin, Yang Xiwen
Cc: Krzysztof Kozlowski, linux-arm-kernel, devicetree, linux-kernel,
stable
In-Reply-To: <20240219-cache-v3-0-a33c57534ae9@outlook.com>
On Mon, 19 Feb 2024 23:05:25 +0800, Yang Xiwen wrote:
> The patchset fixes some warnings reported by the kernel during boot.
>
> The cache size info is from Processor_Datasheet_v2XX.pdf [1], Section
> 2.2.1 Master Processor.
>
> The cache line size and the set-associative info are from Cortex-A53
> Documentation [2].
>
> [...]
It's rc3 and almost one month after last ping/talk, so apparently these got
lost. I'll take them, but let me know if this should go via different tree.
Applied, thanks!
[1/3] arm64: dts: hi3798cv200: fix the size of GICR
https://git.kernel.org/krzk/linux-dt/c/428a575dc9038846ad259466d5ba109858c0a023
[2/3] arm64: dts: hi3798cv200: add GICH, GICV register space and irq
https://git.kernel.org/krzk/linux-dt/c/f00a6b9644a5668e25ad9ca5aff53b6de4b0aaf6
[3/3] arm64: dts: hi3798cv200: add cache info
https://git.kernel.org/krzk/linux-dt/c/c7a3ad884d1dc1302dcc3295baa18917180b8bec
Best regards,
--
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 00/14] mips: dts: ralink: mt7621: improve DTS style
From: Arınç ÜNAL @ 2024-04-08 7:35 UTC (permalink / raw)
To: Justin Swartz, Sergio Paracuellos, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Thomas Bogendoerfer,
Matthias Brugger, AngeloGioacchino Del Regno
Cc: linux-mips, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek
In-Reply-To: <20240316045442.31469-1-justin.swartz@risingedge.co.za>
On 16.03.2024 07:54, Justin Swartz wrote:
> This set of patches was created with the intention of cleaning up
> arch/mips/boot/dts/ralink/mt7621.dtsi so that it is aligned with
> the Devicetree Sources (DTS) Coding Style [1] [2] guide.
>
> [1] Documentation/devicetree/bindings/dts-coding-style.rst
>
> [2] https://docs.kernel.org/devicetree/bindings/dts-coding-style.html
>
> Justin Swartz (14):
> mips: dts: ralink: mt7621: reorder cpu node attributes
> mips: dts: ralink: mt7621: reorder cpuintc node attributes
> mips: dts: ralink: mt7621: reorder mmc regulator attributes
> mips: dts: ralink: mt7621: reorder sysc node attributes
> mips: dts: ralink: mt7621: reorder gpio node attributes
> mips: dts: ralink: mt7621: reorder i2c node attributes
> mips: dts: ralink: mt7621: reorder spi0 node attributes
> mips: dts: ralink: mt7621: move pinctrl and sort its children
> mips: dts: ralink: mt7621: reorder mmc node attributes
> mips: dts: ralink: mt7621: reorder gic node attributes
> mips: dts: ralink: mt7621: reorder ethernet node attributes and kids
> mips: dts: ralink: mt7621: reorder pcie node attributes and children
> mips: dts: ralink: mt7621: reorder pci?_phy attributes
> mips: dts: ralink: mt7621: reorder the attributes of the root node
>
> arch/mips/boot/dts/ralink/mt7621.dtsi | 430 ++++++++++++++------------
> 1 file changed, 239 insertions(+), 191 deletions(-)
Thomas, will you apply this patch series as is or should we squash it to
one patch?
Arınç
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 3/4] mmu_notifier: remove the .change_pte() callback
From: David Hildenbrand @ 2024-04-08 7:35 UTC (permalink / raw)
To: Paolo Bonzini, linux-kernel, kvm
Cc: Marc Zyngier, Oliver Upton, Tianrui Zhao, Bibo Mao,
Thomas Bogendoerfer, Nicholas Piggin, Anup Patel, Atish Patra,
Sean Christopherson, Andrew Morton, linux-arm-kernel, kvmarm,
loongarch, linux-mips, linuxppc-dev, kvm-riscv, linux-mm,
linux-trace-kernel, linux-perf-users
In-Reply-To: <20240405115815.3226315-4-pbonzini@redhat.com>
On 05.04.24 13:58, Paolo Bonzini wrote:
> The scope of set_pte_at_notify() has reduced more and more through the
> years. Initially, it was meant for when the change to the PTE was
> not bracketed by mmu_notifier_invalidate_range_{start,end}(). However,
> that has not been so for over ten years. During all this period
> the only implementation of .change_pte() was KVM and it
> had no actual functionality, because it was called after
> mmu_notifier_invalidate_range_start() zapped the secondary PTE.
>
> Now that this (nonfunctional) user of the .change_pte() callback is
> gone, the whole callback can be removed. For now, leave in place
> set_pte_at_notify() even though it is just a synonym for set_pte_at().
>
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> ---
Reviewed-by: David Hildenbrand <david@redhat.com>
--
Cheers,
David / dhildenb
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 4/4] mm: replace set_pte_at_notify() with just set_pte_at()
From: David Hildenbrand @ 2024-04-08 7:36 UTC (permalink / raw)
To: Paolo Bonzini, linux-kernel, kvm
Cc: Marc Zyngier, Oliver Upton, Tianrui Zhao, Bibo Mao,
Thomas Bogendoerfer, Nicholas Piggin, Anup Patel, Atish Patra,
Sean Christopherson, Andrew Morton, linux-arm-kernel, kvmarm,
loongarch, linux-mips, linuxppc-dev, kvm-riscv, linux-mm,
linux-trace-kernel, linux-perf-users
In-Reply-To: <20240405115815.3226315-5-pbonzini@redhat.com>
On 05.04.24 13:58, Paolo Bonzini wrote:
> With the demise of the .change_pte() MMU notifier callback, there is no
> notification happening in set_pte_at_notify(). It is a synonym of
> set_pte_at() and can be replaced with it.
>
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> ---
A real joy seeing that gone
Reviewed-by: David Hildenbrand <david@redhat.com>
--
Cheers,
David / dhildenb
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2] ASoC: dt-bindings: imx-audio-spdif: convert to YAML
From: Shengjiu Wang @ 2024-04-08 7:27 UTC (permalink / raw)
To: lgirdwood, broonie, robh+dt, krzysztof.kozlowski+dt, conor+dt,
shengjiu.wang, linux-sound, devicetree, linux-kernel, shawnguo,
s.hauer, kernel, festevam, imx, linux-arm-kernel
Convert the imx-audio-spdif binding to YAML.
When testing dtbs_check, found below compatible strings
are not listed in document:
fsl,imx-sabreauto-spdif
fsl,imx6sx-sdb-spdif
So add them in yaml file to pass the test.
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
---
changes in v2:
- change file name to imx-spdif.yaml
- remove |
- add anyof for spdif-in and spdif-out requirement
- change example name to sound
.../bindings/sound/imx-audio-spdif.txt | 36 ----------
.../devicetree/bindings/sound/imx-spdif.yaml | 70 +++++++++++++++++++
2 files changed, 70 insertions(+), 36 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/sound/imx-audio-spdif.txt
create mode 100644 Documentation/devicetree/bindings/sound/imx-spdif.yaml
diff --git a/Documentation/devicetree/bindings/sound/imx-audio-spdif.txt b/Documentation/devicetree/bindings/sound/imx-audio-spdif.txt
deleted file mode 100644
index da84a442ccea..000000000000
--- a/Documentation/devicetree/bindings/sound/imx-audio-spdif.txt
+++ /dev/null
@@ -1,36 +0,0 @@
-Freescale i.MX audio complex with S/PDIF transceiver
-
-Required properties:
-
- - compatible : "fsl,imx-audio-spdif"
-
- - model : The user-visible name of this sound complex
-
- - spdif-controller : The phandle of the i.MX S/PDIF controller
-
-
-Optional properties:
-
- - spdif-out : This is a boolean property. If present, the
- transmitting function of S/PDIF will be enabled,
- indicating there's a physical S/PDIF out connector
- or jack on the board or it's connecting to some
- other IP block, such as an HDMI encoder or
- display-controller.
-
- - spdif-in : This is a boolean property. If present, the receiving
- function of S/PDIF will be enabled, indicating there
- is a physical S/PDIF in connector/jack on the board.
-
-* Note: At least one of these two properties should be set in the DT binding.
-
-
-Example:
-
-sound-spdif {
- compatible = "fsl,imx-audio-spdif";
- model = "imx-spdif";
- spdif-controller = <&spdif>;
- spdif-out;
- spdif-in;
-};
diff --git a/Documentation/devicetree/bindings/sound/imx-spdif.yaml b/Documentation/devicetree/bindings/sound/imx-spdif.yaml
new file mode 100644
index 000000000000..beb214b51a50
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/imx-spdif.yaml
@@ -0,0 +1,70 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/imx-spdif.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX audio complex with S/PDIF transceiver
+
+maintainers:
+ - Shengjiu Wang <shengjiu.wang@nxp.com>
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - fsl,imx-audio-spdif
+ - enum:
+ - fsl,imx-sabreauto-spdif
+ - fsl,imx6sx-sdb-spdif
+ - enum:
+ - fsl,imx-audio-spdif
+
+ model:
+ $ref: /schemas/types.yaml#/definitions/string
+ description: User specified audio sound card name
+
+ spdif-controller:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: The phandle of the i.MX S/PDIF controller
+
+ spdif-out:
+ type: boolean
+ description:
+ If present, the transmitting function of S/PDIF will be enabled,
+ indicating there's a physical S/PDIF out connector or jack on the
+ board or it's connecting to some other IP block, such as an HDMI
+ encoder or display-controller.
+
+ spdif-in:
+ type: boolean
+ description:
+ If present, the receiving function of S/PDIF will be enabled,
+ indicating there is a physical S/PDIF in connector/jack on the board.
+
+required:
+ - compatible
+ - model
+ - spdif-controller
+
+anyOf:
+ - required:
+ - spdif-in
+ - required:
+ - spdif-out
+ - required:
+ - spdif-out
+ - spdif-in
+
+additionalProperties: false
+
+examples:
+ - |
+ sound {
+ compatible = "fsl,imx-audio-spdif";
+ model = "imx-spdif";
+ spdif-controller = <&spdif>;
+ spdif-out;
+ spdif-in;
+ };
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH net-next v6 0/5] remove page frag implementation in vhost_net
From: Michael S. Tsirkin @ 2024-04-08 7:48 UTC (permalink / raw)
To: Yunsheng Lin
Cc: davem, kuba, pabeni, netdev, linux-kernel, Matthias Brugger,
AngeloGioacchino Del Regno, Alexei Starovoitov, Daniel Borkmann,
Jesper Dangaard Brouer, John Fastabend, linux-arm-kernel,
linux-mediatek, bpf
In-Reply-To: <20240228093013.8263-1-linyunsheng@huawei.com>
On Wed, Feb 28, 2024 at 05:30:07PM +0800, Yunsheng Lin wrote:
> Currently there are three implementations for page frag:
>
> 1. mm/page_alloc.c: net stack seems to be using it in the
> rx part with 'struct page_frag_cache' and the main API
> being page_frag_alloc_align().
> 2. net/core/sock.c: net stack seems to be using it in the
> tx part with 'struct page_frag' and the main API being
> skb_page_frag_refill().
> 3. drivers/vhost/net.c: vhost seems to be using it to build
> xdp frame, and it's implementation seems to be a mix of
> the above two.
>
> This patchset tries to unfiy the page frag implementation a
> little bit by unifying gfp bit for order 3 page allocation
> and replacing page frag implementation in vhost.c with the
> one in page_alloc.c.
>
> After this patchset, we are not only able to unify the page
> frag implementation a little, but also able to have about
> 0.5% performance boost testing by using the vhost_net_test
> introduced in the last patch.
>
> Before this patchset:
> Performance counter stats for './vhost_net_test' (10 runs):
>
> 305325.78 msec task-clock # 1.738 CPUs utilized ( +- 0.12% )
> 1048668 context-switches # 3.435 K/sec ( +- 0.00% )
> 11 cpu-migrations # 0.036 /sec ( +- 17.64% )
> 33 page-faults # 0.108 /sec ( +- 0.49% )
> 244651819491 cycles # 0.801 GHz ( +- 0.43% ) (64)
> 64714638024 stalled-cycles-frontend # 26.45% frontend cycles idle ( +- 2.19% ) (67)
> 30774313491 stalled-cycles-backend # 12.58% backend cycles idle ( +- 7.68% ) (70)
> 201749748680 instructions # 0.82 insn per cycle
> # 0.32 stalled cycles per insn ( +- 0.41% ) (66.76%)
> 65494787909 branches # 214.508 M/sec ( +- 0.35% ) (64)
> 4284111313 branch-misses # 6.54% of all branches ( +- 0.45% ) (66)
>
> 175.699 +- 0.189 seconds time elapsed ( +- 0.11% )
>
>
> After this patchset:
> Performance counter stats for './vhost_net_test' (10 runs):
>
> 303974.38 msec task-clock # 1.739 CPUs utilized ( +- 0.14% )
> 1048807 context-switches # 3.450 K/sec ( +- 0.00% )
> 14 cpu-migrations # 0.046 /sec ( +- 12.86% )
> 33 page-faults # 0.109 /sec ( +- 0.46% )
> 251289376347 cycles # 0.827 GHz ( +- 0.32% ) (60)
> 67885175415 stalled-cycles-frontend # 27.01% frontend cycles idle ( +- 0.48% ) (63)
> 27809282600 stalled-cycles-backend # 11.07% backend cycles idle ( +- 0.36% ) (71)
> 195543234672 instructions # 0.78 insn per cycle
> # 0.35 stalled cycles per insn ( +- 0.29% ) (69.04%)
> 62423183552 branches # 205.357 M/sec ( +- 0.48% ) (67)
> 4135666632 branch-misses # 6.63% of all branches ( +- 0.63% ) (67)
>
> 174.764 +- 0.214 seconds time elapsed ( +- 0.12% )
The perf diff is in the noise, but the cleanup is nice.
Thanks!
Acked-by: Michael S. Tsirkin <mst@redhat.com>
> Changelog:
> V6: Add timeout for poll() and simplify some logic as suggested
> by Jason.
>
> V5: Address the comment from jason in vhost_net_test.c and the
> comment about leaving out the gfp change for page frag in
> sock.c as suggested by Paolo.
>
> V4: Resend based on latest net-next branch.
>
> V3:
> 1. Add __page_frag_alloc_align() which is passed with the align mask
> the original function expected as suggested by Alexander.
> 2. Drop patch 3 in v2 suggested by Alexander.
> 3. Reorder patch 4 & 5 in v2 suggested by Alexander.
>
> Note that placing this gfp flags handing for order 3 page in an inline
> function is not considered, as we may be able to unify the page_frag
> and page_frag_cache handling.
>
> V2: Change 'xor'd' to 'masked off', add vhost tx testing for
> vhost_net_test.
>
> V1: Fix some typo, drop RFC tag and rebase on latest net-next.
>
> Yunsheng Lin (5):
> mm/page_alloc: modify page_frag_alloc_align() to accept align as an
> argument
> page_frag: unify gfp bits for order 3 page allocation
> net: introduce page_frag_cache_drain()
> vhost/net: remove vhost_net_page_frag_refill()
> tools: virtio: introduce vhost_net_test
>
> drivers/net/ethernet/google/gve/gve_main.c | 11 +-
> drivers/net/ethernet/mediatek/mtk_wed_wo.c | 17 +-
> drivers/nvme/host/tcp.c | 7 +-
> drivers/nvme/target/tcp.c | 4 +-
> drivers/vhost/net.c | 91 ++--
> include/linux/gfp.h | 16 +-
> mm/page_alloc.c | 22 +-
> net/core/skbuff.c | 9 +-
> tools/virtio/.gitignore | 1 +
> tools/virtio/Makefile | 8 +-
> tools/virtio/linux/virtio_config.h | 4 +
> tools/virtio/vhost_net_test.c | 532 +++++++++++++++++++++
> 12 files changed, 609 insertions(+), 113 deletions(-)
> create mode 100644 tools/virtio/vhost_net_test.c
>
> --
> 2.33.0
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: Re: [PATCH v4 1/2] dt-bindings: media: imx8-jpeg: Add clocks entries
From: Mirela Rabulea @ 2024-04-08 7:50 UTC (permalink / raw)
To: Krzysztof Kozlowski, shawnguo, robh+dt, krzysztof.kozlowski+dt,
festevam, festevam, alexander.stein, Frank.li, ming.qian
Cc: conor+dt, devicetree, linux-arm-kernel, s.hauer, kernel, mchehab,
hverkuil, linux-media, imx, linux-kernel
In-Reply-To: <fd1d99fe-943f-4fcc-a736-9d97dba5a80e@linaro.org>
Hi Krzysztof,
On 08.04.2024 09:38, Krzysztof Kozlowski wrote:
> Please correct subject. You already got comments on this.
> https://lore.kernel.org/linux-devicetree/2fb8c43c-c079-e04e-f727-3bc1dc29996e@linaro.org/
Sorry I missed that.
I will update the prefix to "media: dt-bindings: nxp,imx8-jpeg:". as you
suggested in v2.
>> Changes since v3:
>> - Add items for clocks (per Krzysztof's feddback)
>> - Add description for clocks (per Conor's feddback to the other similar patch from Alexander)
>> - Add "media:" to the subject
> Where? It was there before, so what did you change?
I started from v3 here:
https://lore.kernel.org/linux-devicetree/20230912163810.1750488-1-festevam@gmail.com/
The subject was: "[PATCH v3 1/3] dt-bindings: imx8-jpeg: Add clocks
entries", I had just added "media:". Anyways, will update it again.
>> + clocks:
>> + description:
>> + The JPEG decoder/encoder requires two clocks for it's wrapper (AXI and APB),
>> + and one clock for it's core engine (AXI, same source as for the wrapper)
> Description is now redundant, drop it.
Ok, I will do so in v5.
Thanks a lot for feedback,
Mirela
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2] ASoC: dt-bindings: imx-audio-spdif: convert to YAML
From: Krzysztof Kozlowski @ 2024-04-08 7:55 UTC (permalink / raw)
To: Shengjiu Wang, lgirdwood, broonie, robh+dt,
krzysztof.kozlowski+dt, conor+dt, shengjiu.wang, linux-sound,
devicetree, linux-kernel, shawnguo, s.hauer, kernel, festevam,
imx, linux-arm-kernel
In-Reply-To: <1712561233-27250-1-git-send-email-shengjiu.wang@nxp.com>
On 08/04/2024 09:27, Shengjiu Wang wrote:
> Convert the imx-audio-spdif binding to YAML.
>
> When testing dtbs_check, found below compatible strings
> are not listed in document:
>
> fsl,imx-sabreauto-spdif
> fsl,imx6sx-sdb-spdif
>
> So add them in yaml file to pass the test.
>
> Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
> ---
> changes in v2:
> - change file name to imx-spdif.yaml
How does your compatible look like? fsl,imx-audio-spdif, so use that.
> - remove |
> - add anyof for spdif-in and spdif-out requirement
> - change example name to sound
>
> diff --git a/Documentation/devicetree/bindings/sound/imx-spdif.yaml b/Documentation/devicetree/bindings/sound/imx-spdif.yaml
> new file mode 100644
> index 000000000000..beb214b51a50
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sound/imx-spdif.yaml
> @@ -0,0 +1,70 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/sound/imx-spdif.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Freescale i.MX audio complex with S/PDIF transceiver
> +
> +maintainers:
> + - Shengjiu Wang <shengjiu.wang@nxp.com>
> +
> +properties:
> + compatible:
> + oneOf:
> + - items:
> + - enum:
> + - fsl,imx-audio-spdif> + - enum:
> + - fsl,imx-sabreauto-spdif
> + - fsl,imx6sx-sdb-spdif
This does not make much sense. You have mixed fallback with specific
compatible. I suggest you to fix your DTS and submit proper bindings.
> + - enum:
> + - fsl,imx-audio-spdif
> +
> + model:
> + $ref: /schemas/types.yaml#/definitions/string
> + description: User specified audio sound card name
> +
> + spdif-controller:
> + $ref: /schemas/types.yaml#/definitions/phandle
> + description: The phandle of the i.MX S/PDIF controller
> +
> + spdif-out:
> + type: boolean
> + description:
> + If present, the transmitting function of S/PDIF will be enabled,
> + indicating there's a physical S/PDIF out connector or jack on the
> + board or it's connecting to some other IP block, such as an HDMI
> + encoder or display-controller.
> +
> + spdif-in:
> + type: boolean
> + description:
> + If present, the receiving function of S/PDIF will be enabled,
> + indicating there is a physical S/PDIF in connector/jack on the board.
> +
> +required:
> + - compatible
> + - model
> + - spdif-controller
> +
> +anyOf:
> + - required:
> + - spdif-in
> + - required:
> + - spdif-out
> + - required:
> + - spdif-out
> + - spdif-in
Do you need the last required block?
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + sound {
That's a random change...
Instead of sending two patches per day, please carefully address the
feedback.
> + compatible = "fsl,imx-audio-spdif";
> + model = "imx-spdif";
> + spdif-controller = <&spdif>;
> + spdif-out;
> + spdif-in;
> + };
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox