* [PATCH] cgroup_namespaces.7: wfix
From: Benjamin Peterson @ 2020-07-17 4:26 UTC (permalink / raw)
To: mtk.manpages; +Cc: linux-man
Signed-off-by: Benjamin Peterson <benjamin@python.org>
---
man7/cgroup_namespaces.7 | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/man7/cgroup_namespaces.7 b/man7/cgroup_namespaces.7
index 773379aeb..1acb82feb 100644
--- a/man7/cgroup_namespaces.7
+++ b/man7/cgroup_namespaces.7
@@ -235,7 +235,7 @@ In the absence of cgroup namespacing, because the cgroup directory
.IR /cg/1
is owned (and writable) by UID 9000 and process
.I X
-is also owned by user ID 9000, then process
+is also owned by user ID 9000, process
.I X
would be able to modify the contents of cgroups files
(i.e., change cgroup settings) not only in
--
2.25.1
^ permalink raw reply related
* Re: [PATCH v3 06/12] ppc64/kexec_file: restrict memory usage of kdump kernel
From: Hari Bathini @ 2020-07-17 4:17 UTC (permalink / raw)
To: Thiago Jung Bauermann
Cc: Pingfan Liu, Petr Tesarik, Nayna Jain, Kexec-ml,
Mahesh J Salgaonkar, Mimi Zohar, lkml, linuxppc-dev, Sourabh Jain,
Andrew Morton, Dave Young, Vivek Goyal, Eric Biederman
In-Reply-To: <875zance3n.fsf@morokweng.localdomain>
On 17/07/20 3:33 am, Thiago Jung Bauermann wrote:
>
> Hari Bathini <hbathini@linux.ibm.com> writes:
>
>> On 16/07/20 4:22 am, Thiago Jung Bauermann wrote:
>>>
>>> Hari Bathini <hbathini@linux.ibm.com> writes:
>>>
<snip>
>>>> + * each representing a memory range.
>>>> + */
>>>> + ranges = (len >> 2) / (n_mem_addr_cells + n_mem_size_cells);
>>>> +
>>>> + for (i = 0; i < ranges; i++) {
>>>> + base = of_read_number(prop, n_mem_addr_cells);
>>>> + prop += n_mem_addr_cells;
>>>> + end = base + of_read_number(prop, n_mem_size_cells) - 1;
>>
>> prop is not used after the above.
>>
>>> You need to `prop += n_mem_size_cells` here.
>>
>> But yeah, adding it would make it look complete in some sense..
>
> Isn't it used in the next iteration of the loop?
Memory@XXX/reg typically has only one range. I was looking at it
from that perspective which is not right. Will update.
Thanks
Hari
^ permalink raw reply
* Re: [powerpc:next-test 125/127] arch/powerpc/mm/book3s64/pkeys.c:392:7: error: implicit declaration of function 'is_pkey_enabled'; did you mean
From: Aneesh Kumar K.V @ 2020-07-17 4:16 UTC (permalink / raw)
To: kernel test robot; +Cc: linuxppc-dev, kbuild-all
In-Reply-To: <202007170943.BGjGSyKg%lkp@intel.com>
On 7/17/20 7:29 AM, kernel test robot wrote:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next-test
> head: 0fbd1eb4df96e1cbd039e0b95fdf62cf65a7faf9
> commit: ed411c66eea2ccf93a634ae661a1f79c2bc63d88 [125/127] powerpc/book3s64/pkeys: Remove is_pkey_enabled()
> config: powerpc-allmodconfig (attached as .config)
> compiler: powerpc64-linux-gcc (GCC) 9.3.0
> reproduce (this is a W=1 build):
> wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> git checkout ed411c66eea2ccf93a634ae661a1f79c2bc63d88
> # save the attached .config to linux build tree
> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=powerpc
>
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot <lkp@intel.com>
>
> All errors (new ones prefixed by >>):
>
> arch/powerpc/mm/book3s64/pkeys.c: In function 'pkey_access_permitted':
>>> arch/powerpc/mm/book3s64/pkeys.c:392:7: error: implicit declaration of function 'is_pkey_enabled'; did you mean 'arch_pkeys_enabled'? [-Werror=implicit-function-declaration]
> 392 | if (!is_pkey_enabled(pkey))
> | ^~~~~~~~~~~~~~~
> | arch_pkeys_enabled
> cc1: some warnings being treated as errors
>
> vim +392 arch/powerpc/mm/book3s64/pkeys.c
>
We removed that upstream in
19ab500edb5d6020010caba48ce3b4ce4182ab63 powerpc/mm/pkeys: Make pkey
access check work on execute_only_key
next-test need to be rebased?
-aneesh
^ permalink raw reply
* Re: [PATCH v3 00/12] ima: Fix rule parsing bugs and extend KEXEC_CMDLINE rule support
From: Tyler Hicks @ 2020-07-17 4:34 UTC (permalink / raw)
To: Mimi Zohar
Cc: Nayna Jain, Janne Karhunen, Dmitry Kasatkin, Prakhar Srivastava,
kexec, James Morris, linux-kernel, Lakshmi Ramasubramanian,
linux-security-module, Eric Biederman, Casey Schaufler,
linux-integrity, Serge E . Hallyn
In-Reply-To: <1594960293.27397.2.camel@linux.ibm.com>
On 2020-07-17 00:31:33, Mimi Zohar wrote:
> On Thu, 2020-07-09 at 01:18 -0500, Tyler Hicks wrote:
> > This series ultimately extends the supported IMA rule conditionals for
> > the KEXEC_CMDLINE hook function. As of today, there's an imbalance in
> > IMA language conditional support for KEXEC_CMDLINE rules in comparison
> > to KEXEC_KERNEL_CHECK and KEXEC_INITRAMFS_CHECK rules. The KEXEC_CMDLINE
> > rules do not support *any* conditionals so you cannot have a sequence of
> > rules like this:
> >
> > dont_measure func=KEXEC_KERNEL_CHECK obj_type=foo_t
> > dont_measure func=KEXEC_INITRAMFS_CHECK obj_type=foo_t
> > dont_measure func=KEXEC_CMDLINE obj_type=foo_t
> > measure func=KEXEC_KERNEL_CHECK
> > measure func=KEXEC_INITRAMFS_CHECK
> > measure func=KEXEC_CMDLINE
> >
> > Instead, KEXEC_CMDLINE rules can only be measured or not measured and
> > there's no additional flexibility in today's implementation of the
> > KEXEC_CMDLINE hook function.
> >
> > With this series, the above sequence of rules becomes valid and any
> > calls to kexec_file_load() with a kernel and initramfs inode type of
> > foo_t will not be measured (that includes the kernel cmdline buffer)
> > while all other objects given to a kexec_file_load() syscall will be
> > measured. There's obviously not an inode directly associated with the
> > kernel cmdline buffer but this patch series ties the inode based
> > decision making for KEXEC_CMDLINE to the kernel's inode. I think this
> > will be intuitive to policy authors.
> >
> > While reading IMA code and preparing to make this change, I realized
> > that the buffer based hook functions (KEXEC_CMDLINE and KEY_CHECK) are
> > quite special in comparison to longer standing hook functions. These
> > buffer based hook functions can only support measure actions and there
> > are some restrictions on the conditionals that they support. However,
> > the rule parser isn't enforcing any of those restrictions and IMA policy
> > authors wouldn't have any immediate way of knowing that the policy that
> > they wrote is invalid. For example, the sequence of rules above parses
> > successfully in today's kernel but the
> > "dont_measure func=KEXEC_CMDLINE ..." rule is incorrectly handled in
> > ima_match_rules(). The dont_measure rule is *always* considered to be a
> > match so, surprisingly, no KEXEC_CMDLINE measurements are made.
> >
> > While making the rule parser more strict, I realized that the parser
> > does not correctly free all of the allocated memory associated with an
> > ima_rule_entry when going down some error paths. Invalid policy loaded
> > by the policy administrator could result in small memory leaks.
> >
> > I envision patches 1-7 going to stable. The series is ordered in a way
> > that has all the fixes up front, followed by cleanups, followed by the
> > feature patch. The breakdown of patches looks like so:
> >
> > Memory leak fixes: 1-3
> > Parser strictness fixes: 4-7
> > Code cleanups made possible by the fixes: 8-11
> > Extend KEXEC_CMDLINE rule support: 12
>
> Thanks, Tyler. This is a really nice patch set. The patches are now
> in the "next-integrity-testing" branch.
Thank you for all the helpful review comments. You know where to find me
if any bugs pop up during testing. :)
Tyler
>
> Mimi
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply
* Re: [PATCH v3 00/12] ima: Fix rule parsing bugs and extend KEXEC_CMDLINE rule support
From: Tyler Hicks @ 2020-07-17 4:34 UTC (permalink / raw)
To: Mimi Zohar
Cc: Dmitry Kasatkin, James Morris, Serge E . Hallyn,
Lakshmi Ramasubramanian, Prakhar Srivastava, linux-kernel,
linux-integrity, linux-security-module, Janne Karhunen,
Eric Biederman, kexec, Casey Schaufler, Nayna Jain
In-Reply-To: <1594960293.27397.2.camel@linux.ibm.com>
On 2020-07-17 00:31:33, Mimi Zohar wrote:
> On Thu, 2020-07-09 at 01:18 -0500, Tyler Hicks wrote:
> > This series ultimately extends the supported IMA rule conditionals for
> > the KEXEC_CMDLINE hook function. As of today, there's an imbalance in
> > IMA language conditional support for KEXEC_CMDLINE rules in comparison
> > to KEXEC_KERNEL_CHECK and KEXEC_INITRAMFS_CHECK rules. The KEXEC_CMDLINE
> > rules do not support *any* conditionals so you cannot have a sequence of
> > rules like this:
> >
> > dont_measure func=KEXEC_KERNEL_CHECK obj_type=foo_t
> > dont_measure func=KEXEC_INITRAMFS_CHECK obj_type=foo_t
> > dont_measure func=KEXEC_CMDLINE obj_type=foo_t
> > measure func=KEXEC_KERNEL_CHECK
> > measure func=KEXEC_INITRAMFS_CHECK
> > measure func=KEXEC_CMDLINE
> >
> > Instead, KEXEC_CMDLINE rules can only be measured or not measured and
> > there's no additional flexibility in today's implementation of the
> > KEXEC_CMDLINE hook function.
> >
> > With this series, the above sequence of rules becomes valid and any
> > calls to kexec_file_load() with a kernel and initramfs inode type of
> > foo_t will not be measured (that includes the kernel cmdline buffer)
> > while all other objects given to a kexec_file_load() syscall will be
> > measured. There's obviously not an inode directly associated with the
> > kernel cmdline buffer but this patch series ties the inode based
> > decision making for KEXEC_CMDLINE to the kernel's inode. I think this
> > will be intuitive to policy authors.
> >
> > While reading IMA code and preparing to make this change, I realized
> > that the buffer based hook functions (KEXEC_CMDLINE and KEY_CHECK) are
> > quite special in comparison to longer standing hook functions. These
> > buffer based hook functions can only support measure actions and there
> > are some restrictions on the conditionals that they support. However,
> > the rule parser isn't enforcing any of those restrictions and IMA policy
> > authors wouldn't have any immediate way of knowing that the policy that
> > they wrote is invalid. For example, the sequence of rules above parses
> > successfully in today's kernel but the
> > "dont_measure func=KEXEC_CMDLINE ..." rule is incorrectly handled in
> > ima_match_rules(). The dont_measure rule is *always* considered to be a
> > match so, surprisingly, no KEXEC_CMDLINE measurements are made.
> >
> > While making the rule parser more strict, I realized that the parser
> > does not correctly free all of the allocated memory associated with an
> > ima_rule_entry when going down some error paths. Invalid policy loaded
> > by the policy administrator could result in small memory leaks.
> >
> > I envision patches 1-7 going to stable. The series is ordered in a way
> > that has all the fixes up front, followed by cleanups, followed by the
> > feature patch. The breakdown of patches looks like so:
> >
> > Memory leak fixes: 1-3
> > Parser strictness fixes: 4-7
> > Code cleanups made possible by the fixes: 8-11
> > Extend KEXEC_CMDLINE rule support: 12
>
> Thanks, Tyler. This is a really nice patch set. The patches are now
> in the "next-integrity-testing" branch.
Thank you for all the helpful review comments. You know where to find me
if any bugs pop up during testing. :)
Tyler
>
> Mimi
^ permalink raw reply
* Re: [PATCH v3 03/12] powerpc/kexec_file: add helper functions for getting memory ranges
From: Hari Bathini @ 2020-07-17 4:32 UTC (permalink / raw)
To: Thiago Jung Bauermann
Cc: Pingfan Liu, Nayna Jain, Kexec-ml, Mahesh J Salgaonkar,
Mimi Zohar, lkml, linuxppc-dev, Sourabh Jain, Petr Tesarik,
Andrew Morton, Dave Young, Vivek Goyal, Eric Biederman
In-Reply-To: <874kq98xo4.fsf@morokweng.localdomain>
On 15/07/20 5:19 am, Thiago Jung Bauermann wrote:
>
> Hello Hari,
>
> Hari Bathini <hbathini@linux.ibm.com> writes:
>
>> In kexec case, the kernel to be loaded uses the same memory layout as
>> the running kernel. So, passing on the DT of the running kernel would
>> be good enough.
>>
>> But in case of kdump, different memory ranges are needed to manage
>> loading the kdump kernel, booting into it and exporting the elfcore
>> of the crashing kernel. The ranges are exlude memory ranges, usable
>
> s/exlude/exclude/
>
>> memory ranges, reserved memory ranges and crash memory ranges.
>>
>> Exclude memory ranges specify the list of memory ranges to avoid while
>> loading kdump segments. Usable memory ranges list the memory ranges
>> that could be used for booting kdump kernel. Reserved memory ranges
>> list the memory regions for the loading kernel's reserve map. Crash
>> memory ranges list the memory ranges to be exported as the crashing
>> kernel's elfcore.
>>
>> Add helper functions for setting up the above mentioned memory ranges.
>> This helpers facilitate in understanding the subsequent changes better
>> and make it easy to setup the different memory ranges listed above, as
>> and when appropriate.
>>
>> Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
>> Tested-by: Pingfan Liu <piliu@redhat.com>
>
<snip>
>> +/**
>> + * add_reserved_ranges - Adds "/reserved-ranges" regions exported by f/w
>> + * to the given memory ranges list.
>> + * @mem_ranges: Range list to add the memory ranges to.
>> + *
>> + * Returns 0 on success, negative errno on error.
>> + */
>> +int add_reserved_ranges(struct crash_mem **mem_ranges)
>> +{
>> + int i, len, ret = 0;
>> + const __be32 *prop;
>> +
>> + prop = of_get_property(of_root, "reserved-ranges", &len);
>> + if (!prop)
>> + return 0;
>> +
>> + /*
>> + * Each reserved range is an (address,size) pair, 2 cells each,
>> + * totalling 4 cells per range.
>
> Can you assume that, or do you need to check the #address-cells and
> #size-cells properties of the root node?
Taken from early_reserve_mem_dt() which did not seem to care.
Should we be doing any different here?
Thanks
Hari
^ permalink raw reply
* Re: [PATCH v3 03/12] powerpc/kexec_file: add helper functions for getting memory ranges
From: Hari Bathini @ 2020-07-17 4:32 UTC (permalink / raw)
To: Thiago Jung Bauermann
Cc: Pingfan Liu, Petr Tesarik, Nayna Jain, Kexec-ml,
Mahesh J Salgaonkar, Mimi Zohar, lkml, linuxppc-dev, Sourabh Jain,
Andrew Morton, Dave Young, Vivek Goyal, Eric Biederman
In-Reply-To: <874kq98xo4.fsf@morokweng.localdomain>
On 15/07/20 5:19 am, Thiago Jung Bauermann wrote:
>
> Hello Hari,
>
> Hari Bathini <hbathini@linux.ibm.com> writes:
>
>> In kexec case, the kernel to be loaded uses the same memory layout as
>> the running kernel. So, passing on the DT of the running kernel would
>> be good enough.
>>
>> But in case of kdump, different memory ranges are needed to manage
>> loading the kdump kernel, booting into it and exporting the elfcore
>> of the crashing kernel. The ranges are exlude memory ranges, usable
>
> s/exlude/exclude/
>
>> memory ranges, reserved memory ranges and crash memory ranges.
>>
>> Exclude memory ranges specify the list of memory ranges to avoid while
>> loading kdump segments. Usable memory ranges list the memory ranges
>> that could be used for booting kdump kernel. Reserved memory ranges
>> list the memory regions for the loading kernel's reserve map. Crash
>> memory ranges list the memory ranges to be exported as the crashing
>> kernel's elfcore.
>>
>> Add helper functions for setting up the above mentioned memory ranges.
>> This helpers facilitate in understanding the subsequent changes better
>> and make it easy to setup the different memory ranges listed above, as
>> and when appropriate.
>>
>> Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
>> Tested-by: Pingfan Liu <piliu@redhat.com>
>
<snip>
>> +/**
>> + * add_reserved_ranges - Adds "/reserved-ranges" regions exported by f/w
>> + * to the given memory ranges list.
>> + * @mem_ranges: Range list to add the memory ranges to.
>> + *
>> + * Returns 0 on success, negative errno on error.
>> + */
>> +int add_reserved_ranges(struct crash_mem **mem_ranges)
>> +{
>> + int i, len, ret = 0;
>> + const __be32 *prop;
>> +
>> + prop = of_get_property(of_root, "reserved-ranges", &len);
>> + if (!prop)
>> + return 0;
>> +
>> + /*
>> + * Each reserved range is an (address,size) pair, 2 cells each,
>> + * totalling 4 cells per range.
>
> Can you assume that, or do you need to check the #address-cells and
> #size-cells properties of the root node?
Taken from early_reserve_mem_dt() which did not seem to care.
Should we be doing any different here?
Thanks
Hari
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply
* Re: [PATCH v3 00/12] ima: Fix rule parsing bugs and extend KEXEC_CMDLINE rule support
From: Mimi Zohar @ 2020-07-17 4:31 UTC (permalink / raw)
To: Tyler Hicks, Dmitry Kasatkin
Cc: James Morris, Serge E . Hallyn, Lakshmi Ramasubramanian,
Prakhar Srivastava, linux-kernel, linux-integrity,
linux-security-module, Janne Karhunen, Eric Biederman, kexec,
Casey Schaufler, Nayna Jain
In-Reply-To: <20200709061911.954326-1-tyhicks@linux.microsoft.com>
On Thu, 2020-07-09 at 01:18 -0500, Tyler Hicks wrote:
> This series ultimately extends the supported IMA rule conditionals for
> the KEXEC_CMDLINE hook function. As of today, there's an imbalance in
> IMA language conditional support for KEXEC_CMDLINE rules in comparison
> to KEXEC_KERNEL_CHECK and KEXEC_INITRAMFS_CHECK rules. The KEXEC_CMDLINE
> rules do not support *any* conditionals so you cannot have a sequence of
> rules like this:
>
> dont_measure func=KEXEC_KERNEL_CHECK obj_type=foo_t
> dont_measure func=KEXEC_INITRAMFS_CHECK obj_type=foo_t
> dont_measure func=KEXEC_CMDLINE obj_type=foo_t
> measure func=KEXEC_KERNEL_CHECK
> measure func=KEXEC_INITRAMFS_CHECK
> measure func=KEXEC_CMDLINE
>
> Instead, KEXEC_CMDLINE rules can only be measured or not measured and
> there's no additional flexibility in today's implementation of the
> KEXEC_CMDLINE hook function.
>
> With this series, the above sequence of rules becomes valid and any
> calls to kexec_file_load() with a kernel and initramfs inode type of
> foo_t will not be measured (that includes the kernel cmdline buffer)
> while all other objects given to a kexec_file_load() syscall will be
> measured. There's obviously not an inode directly associated with the
> kernel cmdline buffer but this patch series ties the inode based
> decision making for KEXEC_CMDLINE to the kernel's inode. I think this
> will be intuitive to policy authors.
>
> While reading IMA code and preparing to make this change, I realized
> that the buffer based hook functions (KEXEC_CMDLINE and KEY_CHECK) are
> quite special in comparison to longer standing hook functions. These
> buffer based hook functions can only support measure actions and there
> are some restrictions on the conditionals that they support. However,
> the rule parser isn't enforcing any of those restrictions and IMA policy
> authors wouldn't have any immediate way of knowing that the policy that
> they wrote is invalid. For example, the sequence of rules above parses
> successfully in today's kernel but the
> "dont_measure func=KEXEC_CMDLINE ..." rule is incorrectly handled in
> ima_match_rules(). The dont_measure rule is *always* considered to be a
> match so, surprisingly, no KEXEC_CMDLINE measurements are made.
>
> While making the rule parser more strict, I realized that the parser
> does not correctly free all of the allocated memory associated with an
> ima_rule_entry when going down some error paths. Invalid policy loaded
> by the policy administrator could result in small memory leaks.
>
> I envision patches 1-7 going to stable. The series is ordered in a way
> that has all the fixes up front, followed by cleanups, followed by the
> feature patch. The breakdown of patches looks like so:
>
> Memory leak fixes: 1-3
> Parser strictness fixes: 4-7
> Code cleanups made possible by the fixes: 8-11
> Extend KEXEC_CMDLINE rule support: 12
Thanks, Tyler. This is a really nice patch set. The patches are now
in the "next-integrity-testing" branch.
Mimi
^ permalink raw reply
* [PATCH v4 10/10] powerpc/watchpoint: Remove 512 byte boundary
From: Ravi Bangoria @ 2020-07-17 4:09 UTC (permalink / raw)
To: mpe, mikey
Cc: christophe.leroy, ravi.bangoria, apopple, peterz, fweisbec,
miltonm, oleg, npiggin, linux-kernel, paulus, jolsa, jniethe5,
pedromfc, naveen.n.rao, linuxppc-dev, mingo
In-Reply-To: <20200717040958.70561-1-ravi.bangoria@linux.ibm.com>
Power10 has removed 512 bytes boundary from match criteria. i.e. The watch
range can cross 512 bytes boundary.
Signed-off-by: Ravi Bangoria <ravi.bangoria@linux.ibm.com>
---
arch/powerpc/kernel/hw_breakpoint.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/hw_breakpoint.c b/arch/powerpc/kernel/hw_breakpoint.c
index c55e67bab271..1f4a1efa0074 100644
--- a/arch/powerpc/kernel/hw_breakpoint.c
+++ b/arch/powerpc/kernel/hw_breakpoint.c
@@ -418,8 +418,9 @@ static int hw_breakpoint_validate_len(struct arch_hw_breakpoint *hw)
if (dawr_enabled()) {
max_len = DAWR_MAX_LEN;
- /* DAWR region can't cross 512 bytes boundary */
- if (ALIGN_DOWN(start_addr, SZ_512) != ALIGN_DOWN(end_addr - 1, SZ_512))
+ /* DAWR region can't cross 512 bytes boundary on p10 predecessors */
+ if (!cpu_has_feature(CPU_FTR_ARCH_31) &&
+ (ALIGN_DOWN(start_addr, SZ_512) != ALIGN_DOWN(end_addr - 1, SZ_512)))
return -EINVAL;
} else if (IS_ENABLED(CONFIG_PPC_8xx)) {
/* 8xx can setup a range without limitation */
--
2.26.2
^ permalink raw reply related
* Re: [yocto] [meta-dpdk] is there a plan to support newer dpdk?
From: Anuj Mittal @ 2020-07-17 4:30 UTC (permalink / raw)
To: rick.liu@broadcom.com, yocto@lists.yoctoproject.org
In-Reply-To: <l237.1594926681038650358.mYoM@lists.yoctoproject.org>
On Thu, 2020-07-16 at 12:11 -0700, Rick Liu via lists.yoctoproject.org
wrote:
> Hi,
>
> From meta-dpdk.git, the latest dufell branch is using dpdk 19.11.2.
> Is there a plan to support dpdk 20.0x?
> (and maybe using meason/ninja to build?)
Not on the dunfell branch. If you already have the recipe, I can add it
to master branch which I think should build fine with oe-core dunfell
too.
Thanks,
Anuj
^ permalink raw reply
* Re: [PATCH v5 6/6] MAINTAINERS: Add maintainers for MIPS core drivers
From: Daniel Lezcano @ 2020-07-17 4:29 UTC (permalink / raw)
To: Serge Semin, Thomas Gleixner, Rafael J. Wysocki,
Thomas Bogendoerfer, Greg Kroah-Hartman
Cc: Serge Semin, Alexey Malahov, Rob Herring, Arnd Bergmann,
Jason Cooper, Marc Zyngier, James Hogan, linux-mips, devicetree,
linux-kernel
In-Reply-To: <20200714125753.22466-7-Sergey.Semin@baikalelectronics.ru>
On 14/07/2020 14:57, Serge Semin wrote:
> Add Thomas and myself as maintainers of the MIPS CPU and GIC IRQchip, MIPS
> GIC timer and MIPS CPS CPUidle drivers.
>
> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> Acked-by: Marc Zyngier <maz@kernel.org>
Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org>
> ---
>
> Changelog v3:
> - Keep the files list alphabetically ordered.
> - Add Thomas as the co-maintainer of the designated drivers.
> ---
> MAINTAINERS | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 2926327e4976..20532e0287d7 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -11278,6 +11278,17 @@ F: arch/mips/configs/generic/board-boston.config
> F: drivers/clk/imgtec/clk-boston.c
> F: include/dt-bindings/clock/boston-clock.h
>
> +MIPS CORE DRIVERS
> +M: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
> +M: Serge Semin <fancer.lancer@gmail.com>
> +L: linux-mips@vger.kernel.org
> +S: Supported
> +F: drivers/bus/mips_cdmm.c
> +F: drivers/clocksource/mips-gic-timer.c
> +F: drivers/cpuidle/cpuidle-cps.c
> +F: drivers/irqchip/irq-mips-cpu.c
> +F: drivers/irqchip/irq-mips-gic.c
> +
> MIPS GENERIC PLATFORM
> M: Paul Burton <paulburton@kernel.org>
> L: linux-mips@vger.kernel.org
>
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
^ permalink raw reply
* Re: [PATCH v4 00/16] Allwinner A100 Initial support
From: Daniel Lezcano @ 2020-07-17 4:28 UTC (permalink / raw)
To: Frank Lee, robh+dt, mripard, wens, mturquette, sboyd,
gregory.clement, tglx, jason, maz, srinivas.kandagatla,
linus.walleij, anarsoul, tiny.windzz, rui.zhang, amit.kucheria,
lee.jones, p.zabel, clabbe, icenowy, megous, stefan, bage,
devicetree
Cc: linux-pm, linux-kernel, linux-gpio, linux-i2c, linux-clk,
linux-arm-kernel
In-Reply-To: <cover.1594708863.git.frank@allwinnertech.com>
On 14/07/2020 08:55, Frank Lee wrote:
> From: Yangtao Li <frank@allwinnertech.com>
Do you expect me to pick patches 7,8,9 or ack them ?
> v4:
> -drop "dt-bindings: pinctrl: sunxi: make gpio banks supplies required"
> -fix dcdc1 regulator name
> -get rid of underscore in dts node name
> -Some trivial things in yaml files
>
> v3:
> -Add pmu and nmi support
> -Add read data mask for calibration
> -Code style
> -Some trivial things in yaml files
>
> v2:
> -Some naming consistency
> -Repair email address
> -Fix mmc clock
> -Don't export system clock
> -Fix checkpatch warning
> -Drop unneeded pin function, convert to jtag_gpu and i2s_x
>
> Yangtao Li (16):
> dt-bindings: clk: sunxi-ccu: add compatible string for A100 CCU and
> R-CCU
> clk: sunxi-ng: add support for the Allwinner A100 CCU
> dt-bindings: pinctrl: sunxi: Get rid of continual nesting
> dt-bindings: pinctrl: sunxi: Add A100 pinctrl bindings
> pinctrl: sunxi: add support for the Allwinner A100 pin controller
> dt-bindings: nvmem: SID: add binding for A100's SID controller
> dt-bindings: thermal: sun8i: Add binding for A100's THS controller
> thermal: sun8i: add TEMP_CALIB_MASK for calibration data in
> sun50i_h6_ths_calibrate
> thermal: sun8i: Add A100's THS controller support
> mfd: axp20x: Allow the AXP803 to be probed by I2C
> dt-bindings: irq: sun7i-nmi: fix dt-binding for a80 nmi
> dt-bindings: irq: sun7i-nmi: Add binding for A100's NMI controller
> dt-bindings: i2c: mv64xxx: Add compatible for the A100 i2c node.
> arm64: allwinner: A100: add the basical Allwinner A100 DTSI file
> dt-bindings: arm: sunxi: Add Allwinner A100 Perf1 Board bindings
> arm64: allwinner: A100: add support for Allwinner Perf1 board
>
> .../devicetree/bindings/arm/sunxi.yaml | 5 +
> .../clock/allwinner,sun4i-a10-ccu.yaml | 7 +-
> .../bindings/i2c/marvell,mv64xxx-i2c.yaml | 3 +
> .../allwinner,sun7i-a20-sc-nmi.yaml | 5 +-
> .../nvmem/allwinner,sun4i-a10-sid.yaml | 19 +-
> .../pinctrl/allwinner,sun4i-a10-pinctrl.yaml | 139 +-
> .../thermal/allwinner,sun8i-a83t-ths.yaml | 6 +-
> arch/arm64/boot/dts/allwinner/Makefile | 1 +
> .../allwinner/sun50i-a100-allwinner-perf1.dts | 180 +++
> .../arm64/boot/dts/allwinner/sun50i-a100.dtsi | 364 +++++
> drivers/clk/sunxi-ng/Kconfig | 10 +
> drivers/clk/sunxi-ng/Makefile | 2 +
> drivers/clk/sunxi-ng/ccu-sun50i-a100-r.c | 214 +++
> drivers/clk/sunxi-ng/ccu-sun50i-a100-r.h | 21 +
> drivers/clk/sunxi-ng/ccu-sun50i-a100.c | 1276 +++++++++++++++++
> drivers/clk/sunxi-ng/ccu-sun50i-a100.h | 56 +
> drivers/mfd/axp20x-i2c.c | 2 +
> drivers/pinctrl/sunxi/Kconfig | 10 +
> drivers/pinctrl/sunxi/Makefile | 2 +
> drivers/pinctrl/sunxi/pinctrl-sun50i-a100-r.c | 105 ++
> drivers/pinctrl/sunxi/pinctrl-sun50i-a100.c | 708 +++++++++
> drivers/thermal/sun8i_thermal.c | 16 +-
> include/dt-bindings/clock/sun50i-a100-ccu.h | 116 ++
> include/dt-bindings/clock/sun50i-a100-r-ccu.h | 23 +
> include/dt-bindings/reset/sun50i-a100-ccu.h | 68 +
> include/dt-bindings/reset/sun50i-a100-r-ccu.h | 18 +
> 26 files changed, 3308 insertions(+), 68 deletions(-)
> create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a100-allwinner-perf1.dts
> create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi
> create mode 100644 drivers/clk/sunxi-ng/ccu-sun50i-a100-r.c
> create mode 100644 drivers/clk/sunxi-ng/ccu-sun50i-a100-r.h
> create mode 100644 drivers/clk/sunxi-ng/ccu-sun50i-a100.c
> create mode 100644 drivers/clk/sunxi-ng/ccu-sun50i-a100.h
> create mode 100644 drivers/pinctrl/sunxi/pinctrl-sun50i-a100-r.c
> create mode 100644 drivers/pinctrl/sunxi/pinctrl-sun50i-a100.c
> create mode 100644 include/dt-bindings/clock/sun50i-a100-ccu.h
> create mode 100644 include/dt-bindings/clock/sun50i-a100-r-ccu.h
> create mode 100644 include/dt-bindings/reset/sun50i-a100-ccu.h
> create mode 100644 include/dt-bindings/reset/sun50i-a100-r-ccu.h
>
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
_______________________________________________
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] Off-load TLB invalidations to host for !GTSE
From: Bharata B Rao @ 2020-07-17 4:28 UTC (permalink / raw)
To: Nicholas Piggin
Cc: Qian Cai, aneesh.kumar, linux-kernel, linux-next, linuxppc-dev,
mpe, sfr
In-Reply-To: <1594953143.b8px5ir35m.astroid@bobo.none>
On Fri, Jul 17, 2020 at 12:44:00PM +1000, Nicholas Piggin wrote:
> Excerpts from Nicholas Piggin's message of July 17, 2020 12:08 pm:
> > Excerpts from Qian Cai's message of July 17, 2020 3:27 am:
> >> On Fri, Jul 03, 2020 at 11:06:05AM +0530, Bharata B Rao wrote:
> >>> Hypervisor may choose not to enable Guest Translation Shootdown Enable
> >>> (GTSE) option for the guest. When GTSE isn't ON, the guest OS isn't
> >>> permitted to use instructions like tblie and tlbsync directly, but is
> >>> expected to make hypervisor calls to get the TLB flushed.
> >>>
> >>> This series enables the TLB flush routines in the radix code to
> >>> off-load TLB flushing to hypervisor via the newly proposed hcall
> >>> H_RPT_INVALIDATE.
> >>>
> >>> To easily check the availability of GTSE, it is made an MMU feature.
> >>> The OV5 handling and H_REGISTER_PROC_TBL hcall are changed to
> >>> handle GTSE as an optionally available feature and to not assume GTSE
> >>> when radix support is available.
> >>>
> >>> The actual hcall implementation for KVM isn't included in this
> >>> patchset and will be posted separately.
> >>>
> >>> Changes in v3
> >>> =============
> >>> - Fixed a bug in the hcall wrapper code where we were missing setting
> >>> H_RPTI_TYPE_NESTED while retrying the failed flush request with
> >>> a full flush for the nested case.
> >>> - s/psize_to_h_rpti/psize_to_rpti_pgsize
> >>>
> >>> v2: https://lore.kernel.org/linuxppc-dev/20200626131000.5207-1-bharata@linux.ibm.com/T/#t
> >>>
> >>> Bharata B Rao (2):
> >>> powerpc/mm: Enable radix GTSE only if supported.
> >>> powerpc/pseries: H_REGISTER_PROC_TBL should ask for GTSE only if
> >>> enabled
> >>>
> >>> Nicholas Piggin (1):
> >>> powerpc/mm/book3s64/radix: Off-load TLB invalidations to host when
> >>> !GTSE
> >>
> >> Reverting the whole series fixed random memory corruptions during boot on
> >> POWER9 PowerNV systems below.
> >
> > If I s/mmu_has_feature(MMU_FTR_GTSE)/(1)/g in radix_tlb.c, then the .o
> > disasm is the same as reverting my patch.
> >
> > Feature bits not being set right? PowerNV should be pretty simple, seems
> > to do the same as FTR_TYPE_RADIX.
>
> Might need this fix
>
> ---
>
> diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
> index 9cc49f265c86..54c9bcea9d4e 100644
> --- a/arch/powerpc/kernel/prom.c
> +++ b/arch/powerpc/kernel/prom.c
> @@ -163,7 +163,7 @@ static struct ibm_pa_feature {
> { .pabyte = 0, .pabit = 6, .cpu_features = CPU_FTR_NOEXECUTE },
> { .pabyte = 1, .pabit = 2, .mmu_features = MMU_FTR_CI_LARGE_PAGE },
> #ifdef CONFIG_PPC_RADIX_MMU
> - { .pabyte = 40, .pabit = 0, .mmu_features = MMU_FTR_TYPE_RADIX },
> + { .pabyte = 40, .pabit = 0, .mmu_features = (MMU_FTR_TYPE_RADIX | MMU_FTR_GTSE) },
> #endif
> { .pabyte = 1, .pabit = 1, .invert = 1, .cpu_features = CPU_FTR_NODSISRALIGN },
> { .pabyte = 5, .pabit = 0, .cpu_features = CPU_FTR_REAL_LE,
Michael - Let me know if this should be folded into 1/3 and the complete
series resent.
Regards,
Bharata.
^ permalink raw reply
* [PATCH v4 09/10] powerpc/watchpoint: Return available watchpoints dynamically
From: Ravi Bangoria @ 2020-07-17 4:09 UTC (permalink / raw)
To: mpe, mikey
Cc: christophe.leroy, ravi.bangoria, apopple, peterz, fweisbec,
miltonm, oleg, npiggin, linux-kernel, paulus, jolsa, jniethe5,
pedromfc, naveen.n.rao, linuxppc-dev, mingo
In-Reply-To: <20200717040958.70561-1-ravi.bangoria@linux.ibm.com>
So far Book3S Powerpc supported only one watchpoint. Power10 is
introducing 2nd DAWR. Enable 2nd DAWR support for Power10.
Availability of 2nd DAWR will depend on CPU_FTR_DAWR1.
Signed-off-by: Ravi Bangoria <ravi.bangoria@linux.ibm.com>
---
arch/powerpc/include/asm/cputable.h | 4 +++-
arch/powerpc/include/asm/hw_breakpoint.h | 5 +++--
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/include/asm/cputable.h b/arch/powerpc/include/asm/cputable.h
index 3445c86e1f6f..36a0851a7a9b 100644
--- a/arch/powerpc/include/asm/cputable.h
+++ b/arch/powerpc/include/asm/cputable.h
@@ -633,7 +633,9 @@ enum {
* Maximum number of hw breakpoint supported on powerpc. Number of
* breakpoints supported by actual hw might be less than this.
*/
-#define HBP_NUM_MAX 1
+#define HBP_NUM_MAX 2
+#define HBP_NUM_ONE 1
+#define HBP_NUM_TWO 2
#endif /* !__ASSEMBLY__ */
diff --git a/arch/powerpc/include/asm/hw_breakpoint.h b/arch/powerpc/include/asm/hw_breakpoint.h
index cb424799da0d..d4eab1694bcd 100644
--- a/arch/powerpc/include/asm/hw_breakpoint.h
+++ b/arch/powerpc/include/asm/hw_breakpoint.h
@@ -5,10 +5,11 @@
* Copyright 2010, IBM Corporation.
* Author: K.Prasad <prasad@linux.vnet.ibm.com>
*/
-
#ifndef _PPC_BOOK3S_64_HW_BREAKPOINT_H
#define _PPC_BOOK3S_64_HW_BREAKPOINT_H
+#include <asm/cpu_has_feature.h>
+
#ifdef __KERNEL__
struct arch_hw_breakpoint {
unsigned long address;
@@ -46,7 +47,7 @@ struct arch_hw_breakpoint {
static inline int nr_wp_slots(void)
{
- return HBP_NUM_MAX;
+ return cpu_has_feature(CPU_FTR_DAWR1) ? HBP_NUM_TWO : HBP_NUM_ONE;
}
#ifdef CONFIG_HAVE_HW_BREAKPOINT
--
2.26.2
^ permalink raw reply related
* Re: [PATCH v4 00/16] Allwinner A100 Initial support
From: Daniel Lezcano @ 2020-07-17 4:28 UTC (permalink / raw)
To: Frank Lee, robh+dt, mripard, wens, mturquette, sboyd,
gregory.clement, tglx, jason, maz, srinivas.kandagatla,
linus.walleij, anarsoul, tiny.windzz, rui.zhang, amit.kucheria,
lee.jones, p.zabel, clabbe, icenowy, megous, stefan, bage,
devicetree
Cc: linux-arm-kernel, linux-kernel, linux-clk, linux-i2c, linux-gpio,
linux-pm
In-Reply-To: <cover.1594708863.git.frank@allwinnertech.com>
On 14/07/2020 08:55, Frank Lee wrote:
> From: Yangtao Li <frank@allwinnertech.com>
Do you expect me to pick patches 7,8,9 or ack them ?
> v4:
> -drop "dt-bindings: pinctrl: sunxi: make gpio banks supplies required"
> -fix dcdc1 regulator name
> -get rid of underscore in dts node name
> -Some trivial things in yaml files
>
> v3:
> -Add pmu and nmi support
> -Add read data mask for calibration
> -Code style
> -Some trivial things in yaml files
>
> v2:
> -Some naming consistency
> -Repair email address
> -Fix mmc clock
> -Don't export system clock
> -Fix checkpatch warning
> -Drop unneeded pin function, convert to jtag_gpu and i2s_x
>
> Yangtao Li (16):
> dt-bindings: clk: sunxi-ccu: add compatible string for A100 CCU and
> R-CCU
> clk: sunxi-ng: add support for the Allwinner A100 CCU
> dt-bindings: pinctrl: sunxi: Get rid of continual nesting
> dt-bindings: pinctrl: sunxi: Add A100 pinctrl bindings
> pinctrl: sunxi: add support for the Allwinner A100 pin controller
> dt-bindings: nvmem: SID: add binding for A100's SID controller
> dt-bindings: thermal: sun8i: Add binding for A100's THS controller
> thermal: sun8i: add TEMP_CALIB_MASK for calibration data in
> sun50i_h6_ths_calibrate
> thermal: sun8i: Add A100's THS controller support
> mfd: axp20x: Allow the AXP803 to be probed by I2C
> dt-bindings: irq: sun7i-nmi: fix dt-binding for a80 nmi
> dt-bindings: irq: sun7i-nmi: Add binding for A100's NMI controller
> dt-bindings: i2c: mv64xxx: Add compatible for the A100 i2c node.
> arm64: allwinner: A100: add the basical Allwinner A100 DTSI file
> dt-bindings: arm: sunxi: Add Allwinner A100 Perf1 Board bindings
> arm64: allwinner: A100: add support for Allwinner Perf1 board
>
> .../devicetree/bindings/arm/sunxi.yaml | 5 +
> .../clock/allwinner,sun4i-a10-ccu.yaml | 7 +-
> .../bindings/i2c/marvell,mv64xxx-i2c.yaml | 3 +
> .../allwinner,sun7i-a20-sc-nmi.yaml | 5 +-
> .../nvmem/allwinner,sun4i-a10-sid.yaml | 19 +-
> .../pinctrl/allwinner,sun4i-a10-pinctrl.yaml | 139 +-
> .../thermal/allwinner,sun8i-a83t-ths.yaml | 6 +-
> arch/arm64/boot/dts/allwinner/Makefile | 1 +
> .../allwinner/sun50i-a100-allwinner-perf1.dts | 180 +++
> .../arm64/boot/dts/allwinner/sun50i-a100.dtsi | 364 +++++
> drivers/clk/sunxi-ng/Kconfig | 10 +
> drivers/clk/sunxi-ng/Makefile | 2 +
> drivers/clk/sunxi-ng/ccu-sun50i-a100-r.c | 214 +++
> drivers/clk/sunxi-ng/ccu-sun50i-a100-r.h | 21 +
> drivers/clk/sunxi-ng/ccu-sun50i-a100.c | 1276 +++++++++++++++++
> drivers/clk/sunxi-ng/ccu-sun50i-a100.h | 56 +
> drivers/mfd/axp20x-i2c.c | 2 +
> drivers/pinctrl/sunxi/Kconfig | 10 +
> drivers/pinctrl/sunxi/Makefile | 2 +
> drivers/pinctrl/sunxi/pinctrl-sun50i-a100-r.c | 105 ++
> drivers/pinctrl/sunxi/pinctrl-sun50i-a100.c | 708 +++++++++
> drivers/thermal/sun8i_thermal.c | 16 +-
> include/dt-bindings/clock/sun50i-a100-ccu.h | 116 ++
> include/dt-bindings/clock/sun50i-a100-r-ccu.h | 23 +
> include/dt-bindings/reset/sun50i-a100-ccu.h | 68 +
> include/dt-bindings/reset/sun50i-a100-r-ccu.h | 18 +
> 26 files changed, 3308 insertions(+), 68 deletions(-)
> create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a100-allwinner-perf1.dts
> create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi
> create mode 100644 drivers/clk/sunxi-ng/ccu-sun50i-a100-r.c
> create mode 100644 drivers/clk/sunxi-ng/ccu-sun50i-a100-r.h
> create mode 100644 drivers/clk/sunxi-ng/ccu-sun50i-a100.c
> create mode 100644 drivers/clk/sunxi-ng/ccu-sun50i-a100.h
> create mode 100644 drivers/pinctrl/sunxi/pinctrl-sun50i-a100-r.c
> create mode 100644 drivers/pinctrl/sunxi/pinctrl-sun50i-a100.c
> create mode 100644 include/dt-bindings/clock/sun50i-a100-ccu.h
> create mode 100644 include/dt-bindings/clock/sun50i-a100-r-ccu.h
> create mode 100644 include/dt-bindings/reset/sun50i-a100-ccu.h
> create mode 100644 include/dt-bindings/reset/sun50i-a100-r-ccu.h
>
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
^ permalink raw reply
* Re: [PATCH v4 08/16] thermal: sun8i: add TEMP_CALIB_MASK for calibration data in sun50i_h6_ths_calibrate
From: Daniel Lezcano @ 2020-07-17 4:26 UTC (permalink / raw)
To: Frank Lee, anarsoul, tiny.windzz, rui.zhang, amit.kucheria,
mripard, wens, linux-pm
Cc: liyong, huangshuosheng, linux-kernel, linux-arm-kernel
In-Reply-To: <b8761e036b25f20873534e5f8d10b37b5d2ce72c.1594708864.git.frank@allwinnertech.com>
On 14/07/2020 09:13, Frank Lee wrote:
> From: Yangtao Li <frank@allwinnertech.com>
>
> For sun50i_h6_ths_calibrate(), the data read from nvmem needs a round of
> calculation. On the other hand, the newer SOC may store other data in
> the space other than 12bit sensor data. Add mask operation to read data
> to avoid conversion error.
>
> Signed-off-by: Yangtao Li <frank@allwinnertech.com>
> Reviewed-by: Yangtao Li <tiny.windzz@gmail.com>
Can you clarify these SoB ?
Frank Lee==Yangtao Li==frank@allwinnertech.com==tiny.windzz@gmail.com ?
> ---
> drivers/thermal/sun8i_thermal.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/thermal/sun8i_thermal.c b/drivers/thermal/sun8i_thermal.c
> index 74d73be16496..f423d44b9290 100644
> --- a/drivers/thermal/sun8i_thermal.c
> +++ b/drivers/thermal/sun8i_thermal.c
> @@ -244,7 +244,7 @@ static int sun50i_h6_ths_calibrate(struct ths_device *tmdev,
> ft_temp = (caldata[0] & FT_TEMP_MASK) * 100;
>
> for (i = 0; i < tmdev->chip->sensor_num; i++) {
> - int sensor_reg = caldata[i + 1];
> + int sensor_reg = caldata[i + 1] & TEMP_CALIB_MASK;
> int cdata, offset;
> int sensor_temp = tmdev->chip->calc_temp(tmdev, i, sensor_reg);
>
>
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v4 08/10] powerpc/watchpoint: Guest support for 2nd DAWR hcall
From: Ravi Bangoria @ 2020-07-17 4:09 UTC (permalink / raw)
To: mpe, mikey
Cc: christophe.leroy, ravi.bangoria, apopple, peterz, fweisbec,
miltonm, oleg, npiggin, linux-kernel, paulus, jolsa, jniethe5,
pedromfc, naveen.n.rao, linuxppc-dev, mingo
In-Reply-To: <20200717040958.70561-1-ravi.bangoria@linux.ibm.com>
2nd DAWR can be set/unset using H_SET_MODE hcall with resource value 5.
Enable powervm guest support with that. This has no effect on kvm guest
because kvm will return error if guest does hcall with resource value 5.
Signed-off-by: Ravi Bangoria <ravi.bangoria@linux.ibm.com>
---
arch/powerpc/include/asm/hvcall.h | 1 +
arch/powerpc/include/asm/machdep.h | 2 +-
arch/powerpc/include/asm/plpar_wrappers.h | 5 +++++
arch/powerpc/kernel/dawr.c | 2 +-
arch/powerpc/platforms/pseries/setup.c | 7 +++++--
5 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/include/asm/hvcall.h b/arch/powerpc/include/asm/hvcall.h
index b785e9f0071c..33793444144c 100644
--- a/arch/powerpc/include/asm/hvcall.h
+++ b/arch/powerpc/include/asm/hvcall.h
@@ -358,6 +358,7 @@
#define H_SET_MODE_RESOURCE_SET_DAWR0 2
#define H_SET_MODE_RESOURCE_ADDR_TRANS_MODE 3
#define H_SET_MODE_RESOURCE_LE 4
+#define H_SET_MODE_RESOURCE_SET_DAWR1 5
/* Values for argument to H_SIGNAL_SYS_RESET */
#define H_SIGNAL_SYS_RESET_ALL -1
diff --git a/arch/powerpc/include/asm/machdep.h b/arch/powerpc/include/asm/machdep.h
index 7bcb64444a39..a90b892f0bfe 100644
--- a/arch/powerpc/include/asm/machdep.h
+++ b/arch/powerpc/include/asm/machdep.h
@@ -131,7 +131,7 @@ struct machdep_calls {
unsigned long dabrx);
/* Set DAWR for this platform, leave empty for default implementation */
- int (*set_dawr)(unsigned long dawr,
+ int (*set_dawr)(int nr, unsigned long dawr,
unsigned long dawrx);
#ifdef CONFIG_PPC32 /* XXX for now */
diff --git a/arch/powerpc/include/asm/plpar_wrappers.h b/arch/powerpc/include/asm/plpar_wrappers.h
index d12c3680d946..ece84a430701 100644
--- a/arch/powerpc/include/asm/plpar_wrappers.h
+++ b/arch/powerpc/include/asm/plpar_wrappers.h
@@ -315,6 +315,11 @@ static inline long plpar_set_watchpoint0(unsigned long dawr0, unsigned long dawr
return plpar_set_mode(0, H_SET_MODE_RESOURCE_SET_DAWR0, dawr0, dawrx0);
}
+static inline long plpar_set_watchpoint1(unsigned long dawr1, unsigned long dawrx1)
+{
+ return plpar_set_mode(0, H_SET_MODE_RESOURCE_SET_DAWR1, dawr1, dawrx1);
+}
+
static inline long plpar_signal_sys_reset(long cpu)
{
return plpar_hcall_norets(H_SIGNAL_SYS_RESET, cpu);
diff --git a/arch/powerpc/kernel/dawr.c b/arch/powerpc/kernel/dawr.c
index 500f52fa4711..cdc2dccb987d 100644
--- a/arch/powerpc/kernel/dawr.c
+++ b/arch/powerpc/kernel/dawr.c
@@ -37,7 +37,7 @@ int set_dawr(int nr, struct arch_hw_breakpoint *brk)
dawrx |= (mrd & 0x3f) << (63 - 53);
if (ppc_md.set_dawr)
- return ppc_md.set_dawr(dawr, dawrx);
+ return ppc_md.set_dawr(nr, dawr, dawrx);
if (nr == 0) {
mtspr(SPRN_DAWR0, dawr);
diff --git a/arch/powerpc/platforms/pseries/setup.c b/arch/powerpc/platforms/pseries/setup.c
index 2db8469e475f..d516ee8eb7fc 100644
--- a/arch/powerpc/platforms/pseries/setup.c
+++ b/arch/powerpc/platforms/pseries/setup.c
@@ -831,12 +831,15 @@ static int pseries_set_xdabr(unsigned long dabr, unsigned long dabrx)
return plpar_hcall_norets(H_SET_XDABR, dabr, dabrx);
}
-static int pseries_set_dawr(unsigned long dawr, unsigned long dawrx)
+static int pseries_set_dawr(int nr, unsigned long dawr, unsigned long dawrx)
{
/* PAPR says we can't set HYP */
dawrx &= ~DAWRX_HYP;
- return plpar_set_watchpoint0(dawr, dawrx);
+ if (nr == 0)
+ return plpar_set_watchpoint0(dawr, dawrx);
+ else
+ return plpar_set_watchpoint1(dawr, dawrx);
}
#define CMO_CHARACTERISTICS_TOKEN 44
--
2.26.2
^ permalink raw reply related
* Re: [PATCH v4 08/16] thermal: sun8i: add TEMP_CALIB_MASK for calibration data in sun50i_h6_ths_calibrate
From: Daniel Lezcano @ 2020-07-17 4:26 UTC (permalink / raw)
To: Frank Lee, anarsoul, tiny.windzz, rui.zhang, amit.kucheria,
mripard, wens, linux-pm
Cc: linux-arm-kernel, linux-kernel, huangshuosheng, liyong
In-Reply-To: <b8761e036b25f20873534e5f8d10b37b5d2ce72c.1594708864.git.frank@allwinnertech.com>
On 14/07/2020 09:13, Frank Lee wrote:
> From: Yangtao Li <frank@allwinnertech.com>
>
> For sun50i_h6_ths_calibrate(), the data read from nvmem needs a round of
> calculation. On the other hand, the newer SOC may store other data in
> the space other than 12bit sensor data. Add mask operation to read data
> to avoid conversion error.
>
> Signed-off-by: Yangtao Li <frank@allwinnertech.com>
> Reviewed-by: Yangtao Li <tiny.windzz@gmail.com>
Can you clarify these SoB ?
Frank Lee==Yangtao Li==frank@allwinnertech.com==tiny.windzz@gmail.com ?
> ---
> drivers/thermal/sun8i_thermal.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/thermal/sun8i_thermal.c b/drivers/thermal/sun8i_thermal.c
> index 74d73be16496..f423d44b9290 100644
> --- a/drivers/thermal/sun8i_thermal.c
> +++ b/drivers/thermal/sun8i_thermal.c
> @@ -244,7 +244,7 @@ static int sun50i_h6_ths_calibrate(struct ths_device *tmdev,
> ft_temp = (caldata[0] & FT_TEMP_MASK) * 100;
>
> for (i = 0; i < tmdev->chip->sensor_num; i++) {
> - int sensor_reg = caldata[i + 1];
> + int sensor_reg = caldata[i + 1] & TEMP_CALIB_MASK;
> int cdata, offset;
> int sensor_temp = tmdev->chip->calc_temp(tmdev, i, sensor_reg);
>
>
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
^ permalink raw reply
* [PATCH v4 07/10] powerpc/watchpoint: Rename current H_SET_MODE DAWR macro
From: Ravi Bangoria @ 2020-07-17 4:09 UTC (permalink / raw)
To: mpe, mikey
Cc: christophe.leroy, ravi.bangoria, apopple, peterz, fweisbec,
miltonm, oleg, npiggin, linux-kernel, paulus, jolsa, jniethe5,
pedromfc, naveen.n.rao, linuxppc-dev, mingo
In-Reply-To: <20200717040958.70561-1-ravi.bangoria@linux.ibm.com>
Current H_SET_MODE hcall macro name for setting/resetting DAWR0 is
H_SET_MODE_RESOURCE_SET_DAWR. Add suffix 0 to macro name as well.
Signed-off-by: Ravi Bangoria <ravi.bangoria@linux.ibm.com>
---
arch/powerpc/include/asm/hvcall.h | 2 +-
arch/powerpc/include/asm/plpar_wrappers.h | 2 +-
arch/powerpc/kvm/book3s_hv.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/include/asm/hvcall.h b/arch/powerpc/include/asm/hvcall.h
index 43486e773bd6..b785e9f0071c 100644
--- a/arch/powerpc/include/asm/hvcall.h
+++ b/arch/powerpc/include/asm/hvcall.h
@@ -355,7 +355,7 @@
/* Values for 2nd argument to H_SET_MODE */
#define H_SET_MODE_RESOURCE_SET_CIABR 1
-#define H_SET_MODE_RESOURCE_SET_DAWR 2
+#define H_SET_MODE_RESOURCE_SET_DAWR0 2
#define H_SET_MODE_RESOURCE_ADDR_TRANS_MODE 3
#define H_SET_MODE_RESOURCE_LE 4
diff --git a/arch/powerpc/include/asm/plpar_wrappers.h b/arch/powerpc/include/asm/plpar_wrappers.h
index 4293c5d2ddf4..d12c3680d946 100644
--- a/arch/powerpc/include/asm/plpar_wrappers.h
+++ b/arch/powerpc/include/asm/plpar_wrappers.h
@@ -312,7 +312,7 @@ static inline long plpar_set_ciabr(unsigned long ciabr)
static inline long plpar_set_watchpoint0(unsigned long dawr0, unsigned long dawrx0)
{
- return plpar_set_mode(0, H_SET_MODE_RESOURCE_SET_DAWR, dawr0, dawrx0);
+ return plpar_set_mode(0, H_SET_MODE_RESOURCE_SET_DAWR0, dawr0, dawrx0);
}
static inline long plpar_signal_sys_reset(long cpu)
diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
index 6bf66649ab92..7ad692c2d7c7 100644
--- a/arch/powerpc/kvm/book3s_hv.c
+++ b/arch/powerpc/kvm/book3s_hv.c
@@ -764,7 +764,7 @@ static int kvmppc_h_set_mode(struct kvm_vcpu *vcpu, unsigned long mflags,
return H_P3;
vcpu->arch.ciabr = value1;
return H_SUCCESS;
- case H_SET_MODE_RESOURCE_SET_DAWR:
+ case H_SET_MODE_RESOURCE_SET_DAWR0:
if (!kvmppc_power8_compatible(vcpu))
return H_P2;
if (!ppc_breakpoint_available())
--
2.26.2
^ permalink raw reply related
* [PATCH v2 4/4] arm64: dts: imx8mn-evk: add two parameters for picophy tuning
From: Peter Chen @ 2020-07-17 4:22 UTC (permalink / raw)
To: shawnguo, robh+dt
Cc: devicetree, Peter Chen, linux-usb, linux-imx, kernel,
linux-arm-kernel
In-Reply-To: <20200717042226.18495-1-peter.chen@nxp.com>
With these two parameters tuning, it can pass USB eye diagram at evk board.
Signed-off-by: Peter Chen <peter.chen@nxp.com>
---
Changes for v2
- Address Shawn's comment to change subject.
arch/arm64/boot/dts/freescale/imx8mn-evk.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mn-evk.dtsi b/arch/arm64/boot/dts/freescale/imx8mn-evk.dtsi
index 85fc0aa38c4f..a6e9035e6cd5 100644
--- a/arch/arm64/boot/dts/freescale/imx8mn-evk.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mn-evk.dtsi
@@ -132,6 +132,8 @@
srp-disable;
adp-disable;
usb-role-switch;
+ picophy,pre-emp-curr-control = <3>;
+ picophy,dc-vol-level-adjust = <7>;
status = "okay";
port {
--
2.17.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
* [PATCH v2 3/4] arm64: dts: imx8mm-evk: add two parameters for picophy tuning
From: Peter Chen @ 2020-07-17 4:22 UTC (permalink / raw)
To: shawnguo, robh+dt
Cc: devicetree, Peter Chen, linux-usb, linux-imx, kernel,
linux-arm-kernel
In-Reply-To: <20200717042226.18495-1-peter.chen@nxp.com>
With these two parameters tuning, it can pass USB eye diagram at evk board.
Reviewed-by: Jun Li <jun.li@nxp.com>
Signed-off-by: Peter Chen <peter.chen@nxp.com>
---
Changes for v2
- Address Shawn's comment to change subject.
arch/arm64/boot/dts/freescale/imx8mm-evk.dts | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mm-evk.dts b/arch/arm64/boot/dts/freescale/imx8mm-evk.dts
index 0f1d7f8aeac4..c432b628e1ed 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-evk.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mm-evk.dts
@@ -324,6 +324,8 @@
srp-disable;
adp-disable;
usb-role-switch;
+ picophy,pre-emp-curr-control = <3>;
+ picophy,dc-vol-level-adjust = <7>;
status = "okay";
port {
--
2.17.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
* [PATCH v2 1/4] doc: dt-binding: ci-hdrc-usb2: add property for imx picophy
From: Peter Chen @ 2020-07-17 4:22 UTC (permalink / raw)
To: shawnguo, robh+dt
Cc: devicetree, Peter Chen, linux-usb, linux-imx, kernel,
linux-arm-kernel
Add two parameters which are used to tune USB signal for imx picophy,
picophy is used at imx7d, imx8mm, and imx8mn.
Reviewed-by: Jun Li <jun.li@nxp.com>
Signed-off-by: Peter Chen <peter.chen@nxp.com>
---
No changes for v2.
Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt b/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt
index 51376cbe5f3d..e9858dafb08f 100644
--- a/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt
+++ b/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt
@@ -100,6 +100,13 @@ i.mx specific properties
It's recommended to specify the over current polarity.
- power-active-high: power signal polarity is active high
- external-vbus-divider: enables off-chip resistor divider for Vbus
+- picophy,pre-emp-curr-control: HS Transmitter Pre-Emphasis Current
+ Control. This signal controls the amount of current sourced to the
+ USB_OTG*_DP and USB_OTG*_DN pins after a J-to-K or K-to-J transition.
+ Details can refer to TXPREEMPAMPTUNE0 bits of USBNC_n_PHY_CFG1.
+- picophy,dc-vol-level-adjust: HS DC Voltage Level Adjustment.
+ Adjust the high-speed transmitter DC level voltage, details can refer
+ to TXVREFTUNE0 bits of USBNC_n_PHY_CFG1.
Example:
--
2.17.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 v4 04/10] powerpc/watchpoint: Enable watchpoint functionality on power10 guest
From: Jordan Niethe @ 2020-07-17 4:23 UTC (permalink / raw)
To: Ravi Bangoria
Cc: Michael Ellerman, mikey, apopple, Paul Mackerras, Nicholas Piggin,
Christophe Leroy, naveen.n.rao, peterz, jolsa, oleg, fweisbec,
mingo, pedromfc, miltonm, linuxppc-dev, linux-kernel
In-Reply-To: <20200717040958.70561-5-ravi.bangoria@linux.ibm.com>
On Fri, Jul 17, 2020 at 2:10 PM Ravi Bangoria
<ravi.bangoria@linux.ibm.com> wrote:
>
> CPU_FTR_DAWR is by default enabled for host via CPU_FTRS_DT_CPU_BASE
> (controlled by CONFIG_PPC_DT_CPU_FTRS). But cpu-features device-tree
> node is not PAPR compatible and thus not yet used by kvm or pHyp
> guests. Enable watchpoint functionality on power10 guest (both kvm
> and powervm) by adding CPU_FTR_DAWR to CPU_FTRS_POWER10. Note that
> this change does not enable 2nd DAWR support.
>
> Signed-off-by: Ravi Bangoria <ravi.bangoria@linux.ibm.com>
I ran the ptrace-hwbreak selftest successfully within a power10 kvm guest.
Tested-by: Jordan Niethe <jniethe5@gmail.com>
> ---
> arch/powerpc/include/asm/cputable.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/include/asm/cputable.h b/arch/powerpc/include/asm/cputable.h
> index bac2252c839e..e506d429b1af 100644
> --- a/arch/powerpc/include/asm/cputable.h
> +++ b/arch/powerpc/include/asm/cputable.h
> @@ -478,7 +478,7 @@ static inline void cpu_feature_keys_init(void) { }
> CPU_FTR_CFAR | CPU_FTR_HVMODE | CPU_FTR_VMX_COPY | \
> CPU_FTR_DBELL | CPU_FTR_HAS_PPR | CPU_FTR_ARCH_207S | \
> CPU_FTR_TM_COMP | CPU_FTR_ARCH_300 | CPU_FTR_PKEY | \
> - CPU_FTR_ARCH_31)
> + CPU_FTR_ARCH_31 | CPU_FTR_DAWR)
> #define CPU_FTRS_CELL (CPU_FTR_LWSYNC | \
> CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | \
> CPU_FTR_ALTIVEC_COMP | CPU_FTR_MMCRA | CPU_FTR_SMT | \
> --
> 2.26.2
>
^ permalink raw reply
* [PATCH v2 2/4] usb: chipidea: imx: add two picophy parameters tuning implementation
From: Peter Chen @ 2020-07-17 4:22 UTC (permalink / raw)
To: shawnguo, robh+dt
Cc: devicetree, Peter Chen, linux-usb, linux-imx, kernel,
linux-arm-kernel
In-Reply-To: <20200717042226.18495-1-peter.chen@nxp.com>
These two parameters are used to improve USB signal for board level,
in this commit, we read it from the dtb, and write to related register
during the initialization.
Signed-off-by: Peter Chen <peter.chen@nxp.com>
---
No changes for v2.
drivers/usb/chipidea/ci_hdrc_imx.c | 5 +++++
drivers/usb/chipidea/ci_hdrc_imx.h | 2 ++
drivers/usb/chipidea/usbmisc_imx.c | 21 +++++++++++++++++++++
3 files changed, 28 insertions(+)
diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c b/drivers/usb/chipidea/ci_hdrc_imx.c
index 5ae16368a0c7..58de0f3ac0e9 100644
--- a/drivers/usb/chipidea/ci_hdrc_imx.c
+++ b/drivers/usb/chipidea/ci_hdrc_imx.c
@@ -165,6 +165,11 @@ static struct imx_usbmisc_data *usbmisc_get_init_data(struct device *dev)
if (of_usb_get_phy_mode(np) == USBPHY_INTERFACE_MODE_ULPI)
data->ulpi = 1;
+ of_property_read_u32(np, "picophy,pre-emp-curr-control",
+ &data->emp_curr_control);
+ of_property_read_u32(np, "picophy,dc-vol-level-adjust",
+ &data->dc_vol_level_adjust);
+
return data;
}
diff --git a/drivers/usb/chipidea/ci_hdrc_imx.h b/drivers/usb/chipidea/ci_hdrc_imx.h
index 727d02b6dbd3..367bb0d0cb6b 100644
--- a/drivers/usb/chipidea/ci_hdrc_imx.h
+++ b/drivers/usb/chipidea/ci_hdrc_imx.h
@@ -25,6 +25,8 @@ struct imx_usbmisc_data {
unsigned int ext_id:1; /* ID from exteranl event */
unsigned int ext_vbus:1; /* Vbus from exteranl event */
struct usb_phy *usb_phy;
+ int emp_curr_control;
+ int dc_vol_level_adjust;
};
int imx_usbmisc_init(struct imx_usbmisc_data *data);
diff --git a/drivers/usb/chipidea/usbmisc_imx.c b/drivers/usb/chipidea/usbmisc_imx.c
index f136876cb4a3..f9881aed468f 100644
--- a/drivers/usb/chipidea/usbmisc_imx.c
+++ b/drivers/usb/chipidea/usbmisc_imx.c
@@ -128,6 +128,12 @@
#define MX7D_USB_OTG_PHY_STATUS_VBUS_VLD BIT(3)
#define MX7D_USB_OTG_PHY_STATUS_CHRGDET BIT(29)
+#define MX7D_USB_OTG_PHY_CFG1 0x30
+#define TXPREEMPAMPTUNE0_BIT 28
+#define TXPREEMPAMPTUNE0_MASK (3 << 28)
+#define TXVREFTUNE0_BIT 20
+#define TXVREFTUNE0_MASK (0xf << 20)
+
#define MX6_USB_OTG_WAKEUP_BITS (MX6_BM_WAKEUP_ENABLE | MX6_BM_VBUS_WAKEUP | \
MX6_BM_ID_WAKEUP)
@@ -649,6 +655,21 @@ static int usbmisc_imx7d_init(struct imx_usbmisc_data *data)
writel(reg | MX7D_USB_VBUS_WAKEUP_SOURCE_BVALID
| MX7D_USBNC_AUTO_RESUME,
usbmisc->base + MX7D_USBNC_USB_CTRL2);
+ /* PHY tuning for signal quality */
+ reg = readl(usbmisc->base + MX7D_USB_OTG_PHY_CFG1);
+ if (data->emp_curr_control && data->emp_curr_control <=
+ (TXPREEMPAMPTUNE0_MASK >> TXPREEMPAMPTUNE0_BIT)) {
+ reg &= ~TXPREEMPAMPTUNE0_MASK;
+ reg |= (data->emp_curr_control << TXPREEMPAMPTUNE0_BIT);
+ }
+
+ if (data->dc_vol_level_adjust && data->dc_vol_level_adjust <=
+ (TXVREFTUNE0_MASK >> TXVREFTUNE0_BIT)) {
+ reg &= ~TXVREFTUNE0_MASK;
+ reg |= (data->dc_vol_level_adjust << TXVREFTUNE0_BIT);
+ }
+
+ writel(reg, usbmisc->base + MX7D_USB_OTG_PHY_CFG1);
}
spin_unlock_irqrestore(&usbmisc->lock, flags);
--
2.17.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
* [PATCH v4 06/10] powerpc/watchpoint: Set CPU_FTR_DAWR1 based on pa-features bit
From: Ravi Bangoria @ 2020-07-17 4:09 UTC (permalink / raw)
To: mpe, mikey
Cc: christophe.leroy, ravi.bangoria, apopple, peterz, fweisbec,
miltonm, oleg, npiggin, linux-kernel, paulus, jolsa, jniethe5,
pedromfc, naveen.n.rao, linuxppc-dev, mingo
In-Reply-To: <20200717040958.70561-1-ravi.bangoria@linux.ibm.com>
As per the PAPR, bit 0 of byte 64 in pa-features property indicates
availability of 2nd DAWR registers. i.e. If this bit is set, 2nd
DAWR is present, otherwise not. Host generally uses "cpu-features",
which masks "pa-features". But "cpu-features" are still not used for
guests and thus this change is mostly applicable for guests only.
Signed-off-by: Ravi Bangoria <ravi.bangoria@linux.ibm.com>
---
arch/powerpc/kernel/prom.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index 9cc49f265c86..c76c09b97bc8 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -175,6 +175,8 @@ static struct ibm_pa_feature {
*/
{ .pabyte = 22, .pabit = 0, .cpu_features = CPU_FTR_TM_COMP,
.cpu_user_ftrs2 = PPC_FEATURE2_HTM_COMP | PPC_FEATURE2_HTM_NOSC_COMP },
+
+ { .pabyte = 64, .pabit = 0, .cpu_features = CPU_FTR_DAWR1 },
};
static void __init scan_features(unsigned long node, const unsigned char *ftrs,
--
2.26.2
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.