On 2021/3/2 0:10, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.19.178 release.
There are 247 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made
On 2021/3/2 0:09, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 5.4.102 release.
There are 340 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made
On 2021/3/2 20:31, Greg Kroah-Hartman wrote:
On Tue, Mar 02, 2021 at 02:42:15PM +0800, Hanjun Guo wrote:
Hi Greg,
On 2021/3/2 0:09, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 5.4.102 release.
There are 340 patches in this series, all will be posted
Hi Greg,
On 2021/3/2 0:09, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 5.4.102 release.
There are 340 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses
On 2021/3/2 0:10, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.19.178 release.
There are 247 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made
On 2021/2/26 14:44, Hanjun Guo wrote:
Hi Greg,
On 2021/2/25 17:53, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 5.10.19 release.
There are 23 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being
Hi Nick,
Sorry for taking so long to reply you, we had discussions on how to
corporate with KCIDB, please see my comments inline.
On 2021/2/19 22:45, Nikolai Kondrashov wrote:
Hi Hanjun,
On 2/19/21 10:54 AM, Hanjun Guo wrote:
> In specific, we will start from the testing work, using H
Hi Greg,
On 2021/2/25 17:53, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 5.10.19 release.
There are 23 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses
On 2021/2/25 2:37, Rafael J. Wysocki wrote:
From: Rafael J. Wysocki
Drop "ACPI: " from the pr_noitice() instance in
acpi_processor_cstate_first_run_checks(), because pr_fmt() causes
that prefix to be added to the message already.
Reported-by: Hanjun Guo
Signed-off-by: Rafael
On 2021/2/25 2:06, Rafael J. Wysocki wrote:
On Tue, Feb 23, 2021 at 3:45 PM Rafael J. Wysocki wrote:
On Tue, Feb 23, 2021 at 12:31 PM Hanjun Guo wrote:
On 2021/2/23 2:59, Rafael J. Wysocki wrote:
Index: linux-pm/drivers/acpi/processor_idle.c
for details.
Except patch 1/4, others are looking good to me. some
legacy printk(PRIFIX ...) are still there, but we can
clean up them later.
Feel feel to add my review tag with minor issue addressed.
Reviewed-by: Hanjun Guo
Thanks
Hanjun
On 2021/2/23 2:59, Rafael J. Wysocki wrote:
Index: linux-pm/drivers/acpi/processor_idle.c
===
--- linux-pm.orig/drivers/acpi/processor_idle.c
+++ linux-pm/drivers/acpi/processor_idle.c
In this file, function
On 2021/2/20 17:53, Greg Kroah-Hartman wrote:
On Sat, Feb 20, 2021 at 03:02:54PM +0800, Hanjun Guo wrote:
On 2021/2/19 17:08, Greg Kroah-Hartman wrote:
On Fri, Feb 19, 2021 at 04:54:24PM +0800, Hanjun Guo wrote:
Hi Greg,
On 2021/1/26 15:29, Greg Kroah-Hartman wrote:
[...]
I want to see
to me,
Reviewed-by: Hanjun Guo
Thanks
Hanjun
On 2021/2/19 17:08, Greg Kroah-Hartman wrote:
On Fri, Feb 19, 2021 at 04:54:24PM +0800, Hanjun Guo wrote:
Hi Greg,
On 2021/1/26 15:29, Greg Kroah-Hartman wrote:
[...]
I want to see companies _using_ the kernel, and most importantly,
_updating_ their devices with it, to know if it is worth
Hi Greg,
On 2021/1/26 15:29, Greg Kroah-Hartman wrote:
[...]
I want to see companies _using_ the kernel, and most importantly,
_updating_ their devices with it, to know if it is worth to keep around
for longer than 2 years. I also, hopefully, want to see how those
companies will help me out
changes to fix up white space and
use ACPI_FAILURE() instead of negating ACPI_SUCCESS().
Signed-off-by: Rafael J. Wysocki
Reviewed-by: Hanjun Guo
Thanks
Hanjun
and drop the unneeded
PREFIX sybmbol definition from battery.c. Also adapt the existing
pr_info() calls to the new pr_fmt() definition.
Signed-off-by: Rafael J. Wysocki
Reviewed-by: Hanjun Guo
Thanks
Hanjun
with pr_info(),
add a pr_fmt() definition to ac.c and drop the unneeded PREFIX
symbol definition from there.
Signed-off-by: Rafael J. Wysocki
---
v2 -> v3: Also add a pr_fmt() definition to ac.c and replace direct
printk() with pr_info (no log level change).
Reviewed-by: Hanjun Guo
---
v1 -> v2: Changelog update
Reviewed-by: Hanjun Guo
Thanks
Hanjun
On 2021/2/3 2:18, Rafael J. Wysocki wrote:
[...]
Also make one unrelated janitorial change to fix up white space and
use ACPI_FAILURE() instead of negating ACPI_SUCCESS().
[...]
status = acpi_evaluate_object(video->device->handle, "_DOD", NULL,
);
if (!ACPI_SUCCESS(status))
-by: Hanjun Guo
On 2021/2/3 2:15, Rafael J. Wysocki wrote:
From: Rafael J. Wysocki
Replace the ACPI_DEBUG_PRINT() and ACPI_EXCEPTION() instances
in battery.c with acpi_handle_debug() and acpi_handle_info() calls,
respectively, which among other things causes the excessive log
level of the messages previously
Hi Rafael,
On 2021/2/3 2:14, Rafael J. Wysocki wrote:
From: Rafael J. Wysocki
Replace the ACPI_DEBUG_PRINT() and ACPI_EXCEPTION() instances
in ac.c with acpi_handle_debug() and acpi_handle_info() calls,
respectively, which among other things causes the excessive log
level of the messages
On 2021/1/13 15:30, Qinglang Miao wrote:
A list_add corruption is reported by Hulk Robot like this:
==
list_add corruption.
Call Trace:
link_obj+0xc0/0x1c0
link_group+0x21/0x140
configfs_register_subsystem+0xdb/0x380
acpi_configfs_init+0x25/0x1000 [acpi_configfs]
If the ignore_crat is set to non-zero value, it's no point getting
the CRAT table, so just move the ignore_crat check before we get the
CRAT table.
Signed-off-by: Hanjun Guo
---
drivers/gpu/drm/amd/amdkfd/kfd_crat.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git
used to
get the OEM information, so those two table mappings need to be released
after using it.
Fixes: 174de876d6d0 ("drm/amdkfd: Group up CRAT related functions")
Fixes: 520b8fb755cc ("drm/amdkfd: Add topology support for CPUs")
Signed-off-by: Hanjun Guo
---
driver
On 2020/11/3 16:31, Andy Shevchenko wrote:
On Tue, Nov 3, 2020 at 2:46 AM Hanjun Guo wrote:
On 2020/11/3 5:00, Andy Shevchenko wrote:
Some users may want to use resource library to manage their own resources,
besides existing users that open code union() and intersection()
implementations
-by: Hanjun Guo
Murphy
Cc: Hanjun Guo
Cc: Sudeep Holla
Cc: Anshuman Khandual
Signed-off-by: Ard Biesheuvel
[nsaenz: Rebased, removed documentation change and add declaration in
acpi_iort.h]
Signed-off-by: Nicolas Saenz Julienne
---
Changes since v3:
- Use min_not_zero()
- Check ACPI revision
- Remove
FY_EJECT_REQUEST, false);
+ dock_hotplug_event(dd, ACPI_NOTIFY_EJECT_REQUEST,
+ DOCK_CALL_HANDLER);
list_for_each_entry_reverse(dd, >dependent_devices, list)
acpi_bus_trim(dd->adev);
Reviewed-by: Hanjun Guo
On 2020/10/16 15:27, Hanjun Guo wrote:
The patch only takes the address limit field into account if its value
> 0.
Sorry I missed the if (*->memory_address_limit) check, thanks
for the reminding.
Also, before commit 7fb89e1d44cb6aec ("ACPI/IORT: take _DMA methods
into accoun
Hi Ard,
On 2020/10/16 14:54, Ard Biesheuvel wrote:
On Fri, 16 Oct 2020 at 08:51, Hanjun Guo wrote:
On 2020/10/16 2:03, Catalin Marinas wrote:
On Thu, Oct 15, 2020 at 10:26:18PM +0800, Hanjun Guo wrote:
On 2020/10/15 3:12, Nicolas Saenz Julienne wrote:
From: Ard Biesheuvel
We recently
'size'
description in 'iort_dma_setup'
drivers/acpi/arm64/iort.c:1534: warning: Function parameter or member 'ops' not
described in 'iort_add_platform_device'
Signed-off-by: Shiju Jose
Acked-by: Hanjun Guo
On 2020/10/16 2:03, Catalin Marinas wrote:
On Thu, Oct 15, 2020 at 10:26:18PM +0800, Hanjun Guo wrote:
On 2020/10/15 3:12, Nicolas Saenz Julienne wrote:
From: Ard Biesheuvel
We recently introduced a 1 GB sized ZONE_DMA to cater for platforms
incorporating masters that can address less than
32), but with the
wrong DMA size in IORT, we still have the ZONE_DMA created which
is actually not needed?
Cc: Jeremy Linton
Cc: Lorenzo Pieralisi
Cc: Nicolas Saenz Julienne
Cc: Rob Herring
Cc: Christoph Hellwig
Cc: Robin Murphy
Cc: Hanjun Guo
Cc: Sudeep Holla
Cc: Anshuman Khandual
Sig
/* CONFIG_ACPI_NUMA */
#endif/* __ACP_NUMA_H */
Looks good to me,
Reviewed-by: Hanjun Guo
On 2020/9/2 17:48, Will Deacon wrote:
On Wed, Sep 02, 2020 at 05:17:43PM +0800, Hanjun Guo wrote:
+Cc Will
On 2020/8/18 17:16, Hanjun Guo wrote:
On 2020/8/18 14:36, Zenghui Yu wrote:
* From v1 [1]:
- As pointed out by Hanjun, remove two now unused inline functions.
Compile tested
+Cc Will
On 2020/8/18 17:16, Hanjun Guo wrote:
On 2020/8/18 14:36, Zenghui Yu wrote:
* From v1 [1]:
- As pointed out by Hanjun, remove two now unused inline functions.
Compile tested with CONFIG_IOMMU_API is not selected.
[1] https://lore.kernel.org/r/20200817105946.1511-1-yuzeng
On 2020/8/27 12:28, Felix Kuehling wrote:
Am 2020-08-26 um 4:29 a.m. schrieb Hanjun Guo:
If the ignore_crat is set to non-zero value, it's no point getting
the CRAT table, so just move the ignore_crat check before we get the
CRAT table.
Signed-off-by: Hanjun Guo
---
drivers/gpu/drm/amd
used to
get the OEM information, so those two table mappings need to be released
after using it.
Fixes: 174de876d6d0 ("drm/amdkfd: Group up CRAT related functions")
Fixes: 520b8fb755cc ("drm/amdkfd: Add topology support for CPUs")
Signed-off-by: Hanjun Guo
---
driver
If the ignore_crat is set to non-zero value, it's no point getting
the CRAT table, so just move the ignore_crat check before we get the
CRAT table.
Signed-off-by: Hanjun Guo
---
drivers/gpu/drm/amd/amdkfd/kfd_crat.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git
the unused @ops of iort_add_device_replay()
ACPI/IORT: Remove the unused inline functions
drivers/acpi/arm64/iort.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
Nice cleanup.
Acked-by: Hanjun Guo
On 2020/8/17 18:59, Zenghui Yu wrote:
Since commit d2e1a003af56 ("ACPI/IORT: Don't call iommu_ops->add_device
directly"), we use the IOMMU core API to replace a direct invoke of the
specified callback. The parameter @ops has therefore became unused. Let's
drop it.
Signed-off-by: Zenghui Yu
---
On 2020/7/31 10:41, Felix Kuehling wrote:
Hi Hanjun,
Sorry for the late reply.
Thank you for the patch and the explanation. This seems to have been
broken since the first version of KFD in 2014. See one suggestion inline.
Am 2020-07-22 um 5:48 a.m. schrieb Hanjun Guo:
The acpi_get_table
The acpi_get_table() should be coupled with acpi_put_table() if
the mapped table is not used at runtime to release the table
mapping, put the CSRT table buf after using it.
Signed-off-by: Hanjun Guo
---
drivers/dma/acpi-dma.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git
those table mappings need to be release after
using it.
Signed-off-by: Hanjun Guo
---
drivers/gpu/drm/amd/amdkfd/kfd_crat.c | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_crat.c
b/drivers/gpu/drm/amd/amdkfd/kfd_crat.c
index
-by: Hanjun Guo
---
drivers/mailbox/pcc.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/mailbox/pcc.c b/drivers/mailbox/pcc.c
index 8c7fac3..ef9ecd1 100644
--- a/drivers/mailbox/pcc.c
+++ b/drivers/mailbox/pcc.c
@@ -457,14 +457,17 @@ static int __init
On 2020/6/2 11:34, Xiongfeng Wang wrote:
Hi Viresh,
Sorry to disturb you about another problem as follows.
CPPC use the increment of Desired Performance counter and Reference Performance
counter to get the CPU frequency and show it in sysfs through
'cpuinfo_cur_freq'. But ACPI CPPC doesn't
On 2020/5/22 16:07, Hanjun Guo wrote:
Hi Will,
On 2020/5/21 18:09, Will Deacon wrote:
Hi folks,
I just tried booting the arm64 for-kernelci branch under QEMU (version
4.2.50 (v4.2.0-779-g4354edb6dcc7)) with UBSAN enabled, and I see a couple
of NULL pointer dereferences reported at boot. I
Hi Will,
On 2020/5/21 18:09, Will Deacon wrote:
Hi folks,
I just tried booting the arm64 for-kernelci branch under QEMU (version
4.2.50 (v4.2.0-779-g4354edb6dcc7)) with UBSAN enabled, and I see a couple
of NULL pointer dereferences reported at boot. I think they're both GIC
related (log
pmcg->overflow_gsiv)
+ return -EINVAL;
+
return 0;
default:
return -EINVAL;
With my comments addressed,
Reviewed-by: Hanjun Guo
On 2020/5/9 17:34, Zenghui Yu wrote:
Since commit bc8648d49a95 ("ACPI/IORT: Handle PCI aliases properly for
IOMMUs"), __get_pci_rid() has become actually unused and can be removed.
Signed-off-by: Zenghui Yu
Looks good to me,
Acked-by: Hanjun Guo
any
enhancements there.
Regards,
Thanu
On 06/05/2020, 18:19, "Sudeep Holla" wrote:
+ Thanu, Souvik who work with ASWG
On Wed, May 06, 2020 at 05:36:51PM +0800, Hanjun Guo wrote:
> Hi Sudeep,
>
> On 2020/4/30 17:55, Sudeep Holla wrote:
>
Hi Sudeep,
On 2020/4/30 17:55, Sudeep Holla wrote:
On Thu, Apr 30, 2020 at 02:19:59PM +0800, Xiongfeng Wang wrote:
HiSilicon SoC has a separate System Control Processor(SCP) dedicated for
clock frequency adjustment and has been using the cpufreq driver
'cppc-cpufreq'. New HiSilicon SoC HIP09
On 2019/10/15 0:24, Will Deacon wrote:
> On Sat, Oct 12, 2019 at 03:50:55PM +0100, Russell King - ARM Linux admin
> wrote:
>> On Sat, Oct 12, 2019 at 12:47:45AM +0200, Arnd Bergmann wrote:
>>> On Fri, Oct 11, 2019 at 12:33 PM Russell King - ARM Linux admin
>>> wrote:
32-bit ARM experience
Hi Arnd,
On 2019/10/12 22:05, Arnd Bergmann wrote:
> On Sat, Oct 12, 2019 at 9:33 AM Hanjun Guo wrote:
>>
>> On 2019/10/11 18:27, Will Deacon wrote:
>> [...]
>>>
>>> Does anybody use BIG_ENDIAN? If we're not even building it then maybe we
>>> s
On 2019/10/11 18:27, Will Deacon wrote:
[...]
>
> Does anybody use BIG_ENDIAN? If we're not even building it then maybe we
> should get rid of it altogether on arm64. I don't know of any supported
> userspace that supports it or any CPUs that are unable to run little-endian
> binaries.
FWIW,
Hi John,
On 2019/10/10 21:29, John Garry wrote:
> This series is a backport of the ACPI PPTT 6.3 thread flag feature for
> supporting arm64 systems.
>
> The background is that some arm64 implementations are broken, in that they
> incorrectly advertise that a CPU is mutli-threaded, when it is not
Changes since v2 include:
>
> - Remove the x86 assembly version and enable this code unconditionally
> - Move saturation warnings out-of-line to reduce image bloat
>
> Cheers,
>
> Will
>
> Cc: Kees Cook
> Cc: Ingo Molnar
> Cc: Elena Reshetova
> Cc: Peter
Hi Alex,
On 2019/9/6 22:25, Alex Kogan wrote:
> The new macro should accept the value to be stored into the lock argument
> as another argument. This allows using the same macro in cases where the
> value to be stored when passing the lock is different from 1.
>
> Signed-off-by: Alex Kogan
>
On 2019/9/6 21:43, Will Deacon wrote:
> On Wed, Aug 28, 2019 at 02:03:37PM -0700, Kees Cook wrote:
>> On Wed, Aug 28, 2019 at 03:14:40PM +0100, Will Deacon wrote:
>>> On Wed, Aug 28, 2019 at 09:30:52AM +0200, Peter Zijlstra wrote:
On Tue, Aug 27, 2019 at 05:31:58PM +0100, Will Deacon wrote:
On 2019/7/23 16:33, Mike Rapoport wrote:
> On Tue, Jul 23, 2019 at 01:51:13PM +0800, Hanjun Guo wrote:
>> From: Jia He
>>
>> After skipping some invalid pfns in memmap_init_zone(), there is still
>> some room for improvement.
>>
>> E.g. if pfn and pfn+1
On 2019/7/23 16:30, Mike Rapoport wrote:
> On Tue, Jul 23, 2019 at 01:51:12PM +0800, Hanjun Guo wrote:
>> From: Jia He
>>
>> Commit b92df1de5d28 ("mm: page_alloc: skip over regions of invalid pfns
>> where possible") optimized the loop in memmap_init_zone(). B
el Vacek
Signed-off-by: Jia He
Signed-off-by: Hanjun Guo
---
arch/arm64/Kconfig | 1 +
include/linux/mmzone.h | 9 +
mm/Kconfig | 3 +++
mm/memblock.c | 31 +++
mm/page_alloc.c| 4 +++-
5 files changed, 47 insertions(+),
memory region, skip to next
region directly to speedup the binary search.
Signed-off-by: Jia He
Signed-off-by: Hanjun Guo
---
mm/memblock.c | 37 +++--
1 file changed, 31 insertions(+), 6 deletions(-)
diff --git a/mm/memblock.c b/mm/memblock.c
index d57ba51bb9cd
Here is new version of "[PATCH v11 0/3] remain and optimize
memblock_next_valid_pfn on arm and arm64" from Jia He, which is suggested
by Ard to respin this patch set [1].
In the new version, I squashed patch 1/3 and patch 2/3 in v11 into
one patch, fixed a bug for possible out of bound accessing
bunch of arm64 systems, both bare-metal and in VMs. Boot
> tested on a x86 guest.
This makes the boot log more useful and I can debug some time consuming
issue easier before the arch timer initialization, tested on my ARM64
server, I can see the timestamping from the start [1],
Tested-by: Hanjun
PI: Add new IORT functions to support MSI domain
> handling")
> Link: https://lore.kernel.org/linux-arm-kernel/20190613065410.GB16334@mwanda/
> Reported-by: Dan Carpenter
> Signed-off-by: Lorenzo Pieralisi
> Cc: Dan Carpenter
> Cc: Will Deacon
> Cc: Hanjun Guo
> Cc:
ameter.
>
> Execution was unaffected but it is prone to errors and can lead
> to subtle bugs.
>
> Rename the local variable to prevent any issue.
>
> Reported-by: Will Deacon
> Signed-off-by: Lorenzo Pieralisi
> Cc: Will Deacon
> Cc: Hanjun Guo
> Cc: Sudeep
gt; greatly reduced.
> Tested-by: Jan Glauber
Tested this patchset on Kunpeng920 ARM64 server (96 cores,
4 NUMA nodes), and with the same test case from Jan, I can
see 150%+ boost! (Need to add a patch below [1].)
For the real workload such as Nginx I can see about 10%
performance improvement as wel
ARM64_4K_PAGES || (ARM64_16K_PAGES
> && !ARM64_VA_BITS_36)
> select ARCH_HAS_UBSAN_SANITIZE_ALL
> select ARM_AMBA
> select ARM_ARCH_TIMER
> @@ -901,9 +902,6 @@ config HW_PERF_EVENTS
> config SYS_SUPPORTS_HUGETLBFS
> def_bool y
>
> -co
On 2019/5/26 20:50, Alexandre Ghiti wrote:
> ARCH_WANT_HUGE_PMD_SHARE config was declared in both architectures:
> move this declaration in arch/Kconfig and make those architectures
> select it.
>
> Signed-off-by: Alexandre Ghiti
> Reviewed-by: Palmer Dabbelt
> ---
> arch/Kconfig | 3 +++
A node1 CPU(s): 24-47
NUMA node2 CPU(s): 48-71
NUMA node3 CPU(s): 72-95
Flags: fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp
asimdhp cpuid asimdrdm jscvt fcma dcpop asimddp asimdfhm
Tested-by: Hanjun Guo
For the ACPI code,
Acked-by: Hanjun Guo
Thanks
Hanjun
On 2019/6/27 5:37, Jeremy Linton wrote:
> The ACPI specification implies that the IDENTICAL flag should be
> set on all non leaf nodes where the children are identical.
> This means that we need to be searching for the last node with
> the identical flag set rather than the first one.
>
> Since
if (err) {
> - dev_err(>dev, "Failed to create mbi-gen@%p irqdomain",
> - mgn_chip->base);
> + dev_err(>dev, "Failed to create mbi-gen irqdomain\n");
> return err;
Reviewed-by: Hanjun Guo
On 2019/6/18 11:22, Kefeng Wang wrote:
> After commit ad67b74d2469d9b8 ("printk: hash addresses printed with %p"),
> it will print "ptrval" instead of actual addresses when mbigen
> create domain fails,
>
> Hisilicon MBIGEN-V2 HISI0152:00: Failed to create mbi-gen@(ptrval)
>
rop ARM_SPE_ACPI and just use ARM_SPE_PMU.
Tested on top of 5.2-rc1, I can see in the boot log:
arm_spe_pmu arm,spe-v1: probed for CPUs 0-95 [max_record_sz 128, align 4,
features 0x7]
and I also tested perf record, and works as expected,
Tested-by: Hanjun Guo
Thanks
Hanjun
On 2019/6/12 12:10, Jayachandran Chandrasekharan Nair wrote:
> On Wed, May 22, 2019 at 05:04:17PM +0100, Will Deacon wrote:
>> On Sat, May 18, 2019 at 12:00:34PM +0200, Ard Biesheuvel wrote:
>>> On Sat, 18 May 2019 at 06:25, Jayachandran Chandrasekharan Nair
>>> wrote:
On Mon, May 06,
On 2019/6/12 9:05, Jia He wrote:
>>
>>> So what I would like to see is the patch set being proposed again,
>>> with the new data points added for documentation. Also, the commit
>>> logs need to crystal clear about how the meaning of PFN validity
>>> differs between ARM and other architectures,
Hello Ard,
Thanks for the reply, please see my comments inline.
On 2019/6/10 21:16, Ard Biesheuvel wrote:
> On Sat, 8 Jun 2019 at 06:22, Hanjun Guo wrote:
>>
>> Hi Ard, Will,
>>
>> This week we were trying to debug an issue of time consuming in mem_init(),
>
Hi Ard, Will,
This week we were trying to debug an issue of time consuming in mem_init(),
and leading to this similar solution form Jia He, so I would like to bring this
thread back, please see my detail test result below.
On 2018/9/7 22:44, Will Deacon wrote:
> On Thu, Sep 06, 2018 at
On 2019/5/20 14:57, Christoph Hellwig wrote:
> IOMMU_FWSPEC_PCI_RC_ATS is only defined if CONFIG_IOMMU_API is
> enabled.
>
> Fixes: 5702ee24182f ("ACPI/IORT: Check ATS capability in root complex nodes")
> Signed-off-by: Christoph Hellwig
> ---
> drivers/acpi/arm64/iort.c | 3 ++-
> 1 file
Hi Alex,
On 2019/3/29 23:20, Alex Kogan wrote:
> +
> +static __always_inline void cna_init_node(struct mcs_spinlock *node, int
> cpuid,
> + u32 tail)
> +{
> + if (decode_numa_node(node->node_and_count) == -1)
> + store_numa_node(node,
Hi Jean,
On 2019/1/31 22:55, Jean-Philippe Brucker wrote:
> Hi,
>
> On 31/01/2019 13:52, Zhen Lei wrote:
>> Currently, many peripherals are faster than before. For example, the top
>> speed of the older netcard is 10Gb/s, and now it's more than 25Gb/s. But
>> when iommu page-table mapping
>
> Signed-off-by: Shameer Kolothum
> ---
> drivers/acpi/arm64/iort.c | 16 ++-
> drivers/perf/arm_smmuv3_pmu.c | 48
> ---
> include/linux/acpi_iort.h | 1 +
> 3 files changed, 57 insertions(+), 8 deletions(-)
For this patch,
Reviewed-by: Hanjun Guo
Thanks
Hanjun
On 2019/2/1 17:13, Hanjun Guo wrote:
> On 2019/2/1 13:55, Hanjun Guo wrote:
>> Hi John,
>>
>> On 2019/1/31 17:54, John Garry wrote:
>>> On 30/01/2019 07:01, Hanjun Guo wrote:
>>>> From: Hanjun Guo
>> [...]
>>>>
>>>>
On 2019/2/1 13:55, Hanjun Guo wrote:
> Hi John,
>
> On 2019/1/31 17:54, John Garry wrote:
>> On 30/01/2019 07:01, Hanjun Guo wrote:
>>> From: Hanjun Guo
> [...]
>>>
>>> drivers/usb/core/hcd-pci.c | 4
>>> 1 file changed, 4 insertion
Hi John,
On 2019/1/31 17:54, John Garry wrote:
> On 30/01/2019 07:01, Hanjun Guo wrote:
>> From: Hanjun Guo
[...]
>>
>> drivers/usb/core/hcd-pci.c | 4
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/drivers/usb/core/hcd-pci.c b/drivers/usb/c
Hi Christoph,
On 2019/1/30 15:40, Christoph Hellwig wrote:
> On Wed, Jan 30, 2019 at 03:01:54PM +0800, Hanjun Guo wrote:
>> This is the RFC version, I'm not sure this is the best solution,
>> comments are warmly welcomed.
>>
>> Thanks
>> Hanjun
>>
>&g
From: Hanjun Guo
We met an issue that when we update the IORT table to revision D,
and the kernel update to 4.19, the USB on D06 (ARM64 based server)
will probe fail:
[ 13.495751] CPU: 0 PID: 15 Comm: kworker/0:1 Not tainted
4.19.0-00115-gb2b5200 #5
[ 13.503219] Hardware name: Huawei D06
Hi Marc,
Sorry for ping you...
On 2018/10/26 15:51, Yang Yingliang wrote:
> Now MBIGENs have pins that used to generate SPIs,
> with
> 5052875 ("irqchip/gic-v3: Add support for Message Based Interrupts as an MSI
> controller"),
> we can support MBIGEN to generate message based SPIs by writing
>
return NULL; }
> static inline int iort_add_device_replay(const struct iommu_ops *ops,
>struct device *dev)
Acked-by: Hanjun Guo
Lorenzo, I think this is 4.21-rc1 material if it's OK for you.
Thanks
Hanjun
On 2018/12/18 10:56, Sinan Kaya wrote:
> Remove PCI dependent code out of iort.c when CONFIG_PCI is not defined.
> A quick search reveals the following functions:
> 1. pci_request_acs()
> 2. pci_domain_nr()
> 3. pci_is_root_bus()
> 4. to_pci_dev()
>
> Both pci_domain_nr() and pci_is_root_bus()
Hi Sinan,
On 2018/12/15 9:02, Sinan Kaya wrote:
> Remove PCI dependent code out of iort.c when CONFIG_PCI is not defined.
>
> Signed-off-by: Sinan Kaya
> ---
> drivers/acpi/arm64/iort.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/acpi/arm64/iort.c
tions(-)
Robin and Lorenzo know this better than me, but it's
pretty straight forward to me,
Acked-by: Hanjun Guo
Thanks
Hanjun
On 2018/12/11 21:43, Joerg Roedel wrote:
> From: Joerg Roedel
>
> Replace the iommu-check with a proper and readable function
> call.
>
> Cc: Lorenzo Pieralisi
> Acked-by: Robin Murphy
> Signed-off-by: Joerg Roedel
Acked-by: Hanjun Guo
Thanks
Hanjun
Signed-off-by: Joerg Roedel
> ---
> drivers/acpi/arm64/iort.c | 19 ++-
> 1 file changed, 10 insertions(+), 9 deletions(-)
Acked-by: Hanjun Guo
Thanks
Hanjun
On 2018/10/18 19:56, Marc Zyngier wrote:
> Hi Hanjun,
>
> On 18/10/18 12:20, Hanjun Guo wrote:
>> Hi Marc,
>>
>>>>>>
>>>>> Now, the biggest question of them all: how does it work with ACPI? Last
>>>>> time I checke
On 2018/10/18 19:56, Marc Zyngier wrote:
> Hi Hanjun,
>
> On 18/10/18 12:20, Hanjun Guo wrote:
>> Hi Marc,
>>
>>>>>>
>>>>> Now, the biggest question of them all: how does it work with ACPI? Last
>>>>> time I checke
1 - 100 of 2962 matches
Mail list logo
