- Linuxarm - mailweb.openeuler.org

[PATCH v2 0/3] Add support for HiSilicon I2C controller
by Yicong Yang 18 Mar '21

18 Mar '21

Add driver and MAINTAINERS for HiSilicon I2C controller on Kunpeng SoC. Also provide the devm_*() variants for adding the I2C adapters. Change since v1: - fix compile test error on 32bit arch, reported by intel lkp robot: 64 bit division without using kernel wrapper in probe function. Link:https://lore.kernel.org/linux-i2c/1615016946-55670-1-git-send-email-ya… Yicong Yang (3): i2c: core: add managed function for adding i2c adapters i2c: add support for HiSilicon I2C controller MAINTAINERS: Add maintainer for HiSilicon I2C driver MAINTAINERS | 7 + drivers/i2c/busses/Kconfig | 10 + drivers/i2c/busses/Makefile | 1 + drivers/i2c/busses/i2c-hisi.c | 525 ++++++++++++++++++++++++++++++++++++++++++ drivers/i2c/i2c-core-base.c | 39 ++++ include/linux/i2c.h | 1 + 6 files changed, 583 insertions(+) create mode 100644 drivers/i2c/busses/i2c-hisi.c -- 2.8.1

2 6

[PATCH v3] iommu: Check dev->iommu in iommu_dev_xxx functions
by Shameer Kolothum 18 Mar '21

18 Mar '21

The device iommu probe/attach might have failed leaving dev->iommu to NULL and device drivers may still invoke these functions resulting in a crash in iommu vendor driver code. Hence make sure we check that. Fixes: a3a195929d40 ("iommu: Add APIs for multiple domains per device") Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi(a)huawei.com> --- v2 --> v3 -Removed iommu_ops from struct dev_iommu. v1 --> v2: -Added iommu_ops to struct dev_iommu based on the discussion with Robin. -Rebased against iommu-tree core branch. --- drivers/iommu/iommu.c | 24 +++++++++++++++--------- 1 file changed, 15 insertions(+), 9 deletions(-) diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c index d0b0a15dba84..e10cfa99057c 100644 --- a/drivers/iommu/iommu.c +++ b/drivers/iommu/iommu.c @@ -2878,10 +2878,12 @@ EXPORT_SYMBOL_GPL(iommu_fwspec_add_ids); */ int iommu_dev_enable_feature(struct device *dev, enum iommu_dev_features feat) { - const struct iommu_ops *ops = dev->bus->iommu_ops; + if (dev->iommu && dev->iommu->iommu_dev) { + const struct iommu_ops *ops = dev->iommu->iommu_dev->ops; - if (ops && ops->dev_enable_feat) - return ops->dev_enable_feat(dev, feat); + if (ops->dev_enable_feat) + return ops->dev_enable_feat(dev, feat); + } return -ENODEV; } @@ -2894,10 +2896,12 @@ EXPORT_SYMBOL_GPL(iommu_dev_enable_feature); */ int iommu_dev_disable_feature(struct device *dev, enum iommu_dev_features feat) { - const struct iommu_ops *ops = dev->bus->iommu_ops; + if (dev->iommu && dev->iommu->iommu_dev) { + const struct iommu_ops *ops = dev->iommu->iommu_dev->ops; - if (ops && ops->dev_disable_feat) - return ops->dev_disable_feat(dev, feat); + if (ops->dev_disable_feat) + return ops->dev_disable_feat(dev, feat); + } return -EBUSY; } @@ -2905,10 +2909,12 @@ EXPORT_SYMBOL_GPL(iommu_dev_disable_feature); bool iommu_dev_feature_enabled(struct device *dev, enum iommu_dev_features feat) { - const struct iommu_ops *ops = dev->bus->iommu_ops; + if (dev->iommu && dev->iommu->iommu_dev) { + const struct iommu_ops *ops = dev->iommu->iommu_dev->ops; - if (ops && ops->dev_feat_enabled) - return ops->dev_feat_enabled(dev, feat); + if (ops->dev_feat_enabled) + return ops->dev_feat_enabled(dev, feat); + } return false; } -- 2.17.1

3 2

[PATCH v2 0/2] EDAC/ghes: Add EDAC device for reporting the CPU cache error count
by Shiju Jose 17 Mar '21

17 Mar '21

CPU cache corrected errors are detected occasionally on few of our ARM64 hardware boards. Though it is rare, the probability of the CPU cache errors frequently occurring can't be avoided. The earlier failure detection by monitoring the cache corrected errors for the frequent occurrences and taking preventive action could prevent more serious hardware faults. On Intel architectures, cache corrected errors are reported and the affected cores are offlined in the architecture specific method. http://www.mcelog.org/cache.html However for the firmware-first error reporting, specifically on ARM64 architecture, there is no provision present for reporting the cache corrected error count to the user-space and taking preventive action such as offline the affected cores. For this purpose, it was suggested to create the CPU EDAC device for the CPU caches for reporting the cache error count for the firmware-first error reporting. User-space application could monitor the recorded corrected error count for the earlier hardware failure detection and could take preventive action, such as offline the corresponding CPU core/s. Changes: RFC V1 -> RFC V2: 1. Fixed feedback by Boris. 1.1. Added reason of this patch. 1.2. Changed CPU errors to CPU cache errors in the drivers/edac/Kconfig 1.3 Changed EDAC cache list to percpu variables. 1.4 Changed configuration depends on ARM64. 1.5. Moved discovery of cacheinfo to ghes_scan_system(). 2. Changes in the descriptions. Shiju Jose (2): EDAC/ghes: Add EDAC device for reporting the CPU cache errors ACPI / APEI: Add reporting ARM64 CPU cache corrected error count Documentation/ABI/testing/sysfs-devices-edac | 15 ++ drivers/acpi/apei/ghes.c | 76 +++++++- drivers/edac/Kconfig | 12 ++ drivers/edac/ghes_edac.c | 186 +++++++++++++++++++ include/acpi/ghes.h | 27 +++ include/linux/cper.h | 4 + 6 files changed, 316 insertions(+), 4 deletions(-) -- 2.17.1

3 5

[PATCH net-next] net: sched: remove unnecessay lock protection for skb_bad_txq/gso_skb
by Yunsheng Lin 17 Mar '21

17 Mar '21

Currently qdisc_lock(q) is taken before enqueuing and dequeuing for lockless qdisc's skb_bad_txq/gso_skb queue, qdisc->seqlock is also taken, which can provide the same protection as qdisc_lock(q). This patch removes the unnecessay qdisc_lock(q) protection for lockless qdisc' skb_bad_txq/gso_skb queue. And dev_reset_queue() takes the qdisc->seqlock for lockless qdisc besides taking the qdisc_lock(q) when doing the qdisc reset, some_qdisc_is_busy() takes both qdisc->seqlock and qdisc_lock(q) when checking qdisc status. It is unnecessary to take both lock while the fast path only take one lock, so this patch also changes it to only take qdisc_lock(q) for locked qdisc, and only take qdisc->seqlock for lockless qdisc. Since qdisc->seqlock is taken for lockless qdisc when calling qdisc_is_running() in some_qdisc_is_busy(), use qdisc->running to decide if the lockless qdisc is running. Signed-off-by: Yunsheng Lin <linyunsheng(a)huawei.com> --- include/net/sch_generic.h | 2 -- net/sched/sch_generic.c | 72 +++++++++++++---------------------------------- 2 files changed, 19 insertions(+), 55 deletions(-) diff --git a/include/net/sch_generic.h b/include/net/sch_generic.h index 2d6eb60..0e497ed 100644 --- a/include/net/sch_generic.h +++ b/include/net/sch_generic.h @@ -139,8 +139,6 @@ static inline struct Qdisc *qdisc_refcount_inc_nz(struct Qdisc *qdisc) static inline bool qdisc_is_running(struct Qdisc *qdisc) { - if (qdisc->flags & TCQ_F_NOLOCK) - return spin_is_locked(&qdisc->seqlock); return (raw_read_seqcount(&qdisc->running) & 1) ? true : false; } diff --git a/net/sched/sch_generic.c b/net/sched/sch_generic.c index 49eae93..a5f1e3c 100644 --- a/net/sched/sch_generic.c +++ b/net/sched/sch_generic.c @@ -38,7 +38,7 @@ EXPORT_SYMBOL(default_qdisc_ops); /* Main transmission queue. */ /* Modifications to data participating in scheduling must be protected with - * qdisc_lock(qdisc) spinlock. + * qdisc_lock(qdisc) or qdisc->seqlock spinlock. * * The idea is the following: * - enqueue, dequeue are serialized via qdisc root lock @@ -51,14 +51,8 @@ EXPORT_SYMBOL(default_qdisc_ops); static inline struct sk_buff *__skb_dequeue_bad_txq(struct Qdisc *q) { const struct netdev_queue *txq = q->dev_queue; - spinlock_t *lock = NULL; struct sk_buff *skb; - if (q->flags & TCQ_F_NOLOCK) { - lock = qdisc_lock(q); - spin_lock(lock); - } - skb = skb_peek(&q->skb_bad_txq); if (skb) { /* check the reason of requeuing without tx lock first */ @@ -77,9 +71,6 @@ static inline struct sk_buff *__skb_dequeue_bad_txq(struct Qdisc *q) } } - if (lock) - spin_unlock(lock); - return skb; } @@ -96,13 +87,6 @@ static inline struct sk_buff *qdisc_dequeue_skb_bad_txq(struct Qdisc *q) static inline void qdisc_enqueue_skb_bad_txq(struct Qdisc *q, struct sk_buff *skb) { - spinlock_t *lock = NULL; - - if (q->flags & TCQ_F_NOLOCK) { - lock = qdisc_lock(q); - spin_lock(lock); - } - __skb_queue_tail(&q->skb_bad_txq, skb); if (qdisc_is_percpu_stats(q)) { @@ -112,20 +96,10 @@ static inline void qdisc_enqueue_skb_bad_txq(struct Qdisc *q, qdisc_qstats_backlog_inc(q, skb); q->q.qlen++; } - - if (lock) - spin_unlock(lock); } static inline void dev_requeue_skb(struct sk_buff *skb, struct Qdisc *q) { - spinlock_t *lock = NULL; - - if (q->flags & TCQ_F_NOLOCK) { - lock = qdisc_lock(q); - spin_lock(lock); - } - while (skb) { struct sk_buff *next = skb->next; @@ -144,8 +118,7 @@ static inline void dev_requeue_skb(struct sk_buff *skb, struct Qdisc *q) skb = next; } - if (lock) - spin_unlock(lock); + __netif_schedule(q); } @@ -207,24 +180,9 @@ static struct sk_buff *dequeue_skb(struct Qdisc *q, bool *validate, *packets = 1; if (unlikely(!skb_queue_empty(&q->gso_skb))) { - spinlock_t *lock = NULL; - - if (q->flags & TCQ_F_NOLOCK) { - lock = qdisc_lock(q); - spin_lock(lock); - } skb = skb_peek(&q->gso_skb); - /* skb may be null if another cpu pulls gso_skb off in between - * empty check and lock. - */ - if (!skb) { - if (lock) - spin_unlock(lock); - goto validate; - } - /* skb in gso_skb were already validated */ *validate = false; if (xfrm_offload(skb)) @@ -243,11 +201,10 @@ static struct sk_buff *dequeue_skb(struct Qdisc *q, bool *validate, } else { skb = NULL; } - if (lock) - spin_unlock(lock); + goto trace; } -validate: + *validate = true; if ((q->flags & TCQ_F_ONETXQUEUE) && @@ -1153,13 +1110,15 @@ static void dev_reset_queue(struct net_device *dev, if (nolock) spin_lock_bh(&qdisc->seqlock); - spin_lock_bh(qdisc_lock(qdisc)); + else + spin_lock_bh(qdisc_lock(qdisc)); qdisc_reset(qdisc); - spin_unlock_bh(qdisc_lock(qdisc)); if (nolock) spin_unlock_bh(&qdisc->seqlock); + else + spin_unlock_bh(qdisc_lock(qdisc)); } static bool some_qdisc_is_busy(struct net_device *dev) @@ -1168,20 +1127,27 @@ static bool some_qdisc_is_busy(struct net_device *dev) for (i = 0; i < dev->num_tx_queues; i++) { struct netdev_queue *dev_queue; - spinlock_t *root_lock; struct Qdisc *q; + bool nolock; int val; dev_queue = netdev_get_tx_queue(dev, i); q = dev_queue->qdisc_sleeping; - root_lock = qdisc_lock(q); - spin_lock_bh(root_lock); + nolock = q->flags & TCQ_F_NOLOCK; + + if (nolock) + spin_lock_bh(&q->seqlock); + else + spin_lock_bh(qdisc_lock(q)); val = (qdisc_is_running(q) || test_bit(__QDISC_STATE_SCHED, &q->state)); - spin_unlock_bh(root_lock); + if (nolock) + spin_unlock_bh(&q->seqlock); + else + spin_unlock_bh(qdisc_lock(q)); if (val) return true; -- 2.7.4

4 8

[RFC PATCH v4 0/3] scheduler: expose the topology of clusters and add cluster scheduler
by Barry Song 16 Mar '21

16 Mar '21

ARM64 server chip Kunpeng 920 has 6 or 8 clusters in each NUMA node, and each cluster has 4 cpus. All clusters share L3 cache data while each cluster has local L3 tag. On the other hand, each cluster will share some internal system bus. This means cache is much more affine inside one cluster than across clusters. +-----------------------------------+ +---------+ | +------+ +------+ +---------------------------+ | | | CPU0 | | cpu1 | | +-----------+ | | | +------+ +------+ | | | | | | +----+ L3 | | | | +------+ +------+ cluster | | tag | | | | | CPU2 | | CPU3 | | | | | | | +------+ +------+ | +-----------+ | | | | | | +-----------------------------------+ | | +-----------------------------------+ | | | +------+ +------+ +--------------------------+ | | | | | | | +-----------+ | | | +------+ +------+ | | | | | | | | L3 | | | | +------+ +------+ +----+ tag | | | | | | | | | | | | | | +------+ +------+ | +-----------+ | | | | | | +-----------------------------------+ | L3 | | data | +-----------------------------------+ | | | +------+ +------+ | +-----------+ | | | | | | | | | | | | | +------+ +------+ +----+ L3 | | | | | | tag | | | | +------+ +------+ | | | | | | | | | | ++ +-----------+ | | | +------+ +------+ |---------------------------+ | +-----------------------------------| | | +-----------------------------------| | | | +------+ +------+ +---------------------------+ | | | | | | | +-----------+ | | | +------+ +------+ | | | | | | +----+ L3 | | | | +------+ +------+ | | tag | | | | | | | | | | | | | | +------+ +------+ | +-----------+ | | | | | | +-----------------------------------+ | | +-----------------------------------+ | | | +------+ +------+ +--------------------------+ | | | | | | | +-----------+ | | | +------+ +------+ | | | | | There is a similar need for clustering in x86. Some x86 cores could share L2 caches that is similar to the cluster in Kupeng 920 (e.g. on Jacobsville there are 6 clusters of 4 Atom cores, each cluster sharing a separate L2, and 24 cores sharing L3). Having a sched_domain for clusters will bring two aspects of improvement: 1. spreading unrelated tasks among clusters, which decreases the contention of resources and improve the throughput. unrelated tasks might be put randomly without cluster sched_domain: +-------------------+ +-----------------+ | +----+ +----+ | | | | |task| |task| | | | | |1 | |2 | | | | | +----+ +----+ | | | | | | | | cluster1 | | cluster2 | +-------------------+ +-----------------+ but with cluster sched_domain, they are likely to spread due to LB: +-------------------+ +-----------------+ | +----+ | | +----+ | | |task| | | |task| | | |1 | | | |2 | | | +----+ | | +----+ | | | | | | cluster1 | | cluster2 | +-------------------+ +-----------------+ 2. gathering related tasks within a cluster, which improves the cache affinity of tasks talking with each other. Without cluster sched_domain, related tasks might be put randomly. In case task1-8 have relationship as below: Task1 wakes up task4 Task2 wakes up task5 Task3 wakes up task6 Task4 wakes up task7 With the tuning of select_idle_cpu() to scan local cluster first, those tasks might get a chance to be gathered like: +---------------------------+ +----------------------+ | +----+ +-----+ | | +----+ +-----+ | | |task| |task | | | |task| |task | | | |1 | | 4 | | | |2 | |5 | | | +----+ +-----+ | | +----+ +-----+ | | | | | | cluster1 | | cluster2 | | | | | | | | | | +-----+ +------+ | | +-----+ +------+ | | |task | | task | | | |task | |task | | | |3 | | 6 | | | |4 | |8 | | | +-----+ +------+ | | +-----+ +------+ | +---------------------------+ +----------------------+ Otherwise, the result might be: +---------------------------+ +----------------------+ | +----+ +-----+ | | +----+ +-----+ | | |task| |task | | | |task| |task | | | |1 | | 2 | | | |5 | |6 | | | +----+ +-----+ | | +----+ +-----+ | | | | | | cluster1 | | cluster2 | | | | | | | | | | +-----+ +------+ | | +-----+ +------+ | | |task | | task | | | |task | |task | | | |3 | | 4 | | | |7 | |8 | | | +-----+ +------+ | | +-----+ +------+ | +---------------------------+ +----------------------+ -v4: * rebased to tip/sched/core with the latest unified code of select_idle_cpu * added Tim's patch for x86 Jacobsville * also added benchmark data of spreading unrelated tasks * avoided the iteration of sched_domain by moving to static_key(addressing Vincent's comment * used acpi_cpu_id for acpi_find_processor_node(addressing Masa's comment) Barry Song (1): scheduler: add scheduler level for clusters Jonathan Cameron (1): topology: Represent clusters of CPUs within a die. Tim Chen (1): scheduler: Add cluster scheduler level for x86 Documentation/admin-guide/cputopology.rst | 26 ++++++++++-- arch/arm64/Kconfig | 7 ++++ arch/arm64/kernel/topology.c | 2 + arch/x86/Kconfig | 8 ++++ arch/x86/include/asm/smp.h | 7 ++++ arch/x86/include/asm/topology.h | 1 + arch/x86/kernel/cpu/cacheinfo.c | 1 + arch/x86/kernel/cpu/common.c | 3 ++ arch/x86/kernel/smpboot.c | 43 +++++++++++++++++++- drivers/acpi/pptt.c | 63 +++++++++++++++++++++++++++++ drivers/base/arch_topology.c | 14 +++++++ drivers/base/topology.c | 10 +++++ include/linux/acpi.h | 5 +++ include/linux/arch_topology.h | 5 +++ include/linux/sched/cluster.h | 19 +++++++++ include/linux/sched/sd_flags.h | 9 +++++ include/linux/sched/topology.h | 7 ++++ include/linux/topology.h | 13 ++++++ kernel/sched/core.c | 18 +++++++++ kernel/sched/fair.c | 66 ++++++++++++++++++++++++------- kernel/sched/sched.h | 1 + kernel/sched/topology.c | 6 +++ 22 files changed, 315 insertions(+), 19 deletions(-) create mode 100644 include/linux/sched/cluster.h -- 1.8.3.1

6 15

[PATCH] Documentation/features: mark BATCHED_UNMAP_TLB_FLUSH doesn't apply to ARM64
by Barry Song 16 Mar '21

16 Mar '21

BATCHED_UNMAP_TLB_FLUSH is used on x86 to do batched tlb shootdown by sending one IPI to TLB flush all entries after unmapping pages rather than sending an IPI to flush each individual entry. On arm64, tlb shootdown is done by hardware. Flush instructions are innershareable. The local flushes are limited to the boot (1 per CPU) and when a task is getting a new ASID. So marking this feature as "TODO" is not proper. ".." isn't good as well. So this patch adds a "N/A" for this kind of features which are not needed on some architectures. Cc: Mel Gorman <mgorman(a)suse.de> Cc: Andy Lutomirski <luto(a)kernel.org> Cc: Catalin Marinas <catalin.marinas(a)arm.com> Cc: Will Deacon <will(a)kernel.org> Signed-off-by: Barry Song <song.bao.hua(a)hisilicon.com> --- Documentation/features/arch-support.txt | 1 + Documentation/features/vm/TLB/arch-support.txt | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/Documentation/features/arch-support.txt b/Documentation/features/arch-support.txt index d22a1095e661..118ae031840b 100644 --- a/Documentation/features/arch-support.txt +++ b/Documentation/features/arch-support.txt @@ -8,4 +8,5 @@ The meaning of entries in the tables is: | ok | # feature supported by the architecture |TODO| # feature not yet supported by the architecture | .. | # feature cannot be supported by the hardware + | N/A| # feature doesn't apply to the architecture diff --git a/Documentation/features/vm/TLB/arch-support.txt b/Documentation/features/vm/TLB/arch-support.txt index 30f75a79ce01..0d070f9f98d8 100644 --- a/Documentation/features/vm/TLB/arch-support.txt +++ b/Documentation/features/vm/TLB/arch-support.txt @@ -9,7 +9,7 @@ | alpha: | TODO | | arc: | TODO | | arm: | TODO | - | arm64: | TODO | + | arm64: | N/A | | c6x: | .. | | csky: | TODO | | h8300: | .. | -- 2.25.1

5 4

Re: [PATCH] lib/logic_pio: Fix overlap check for pio registery
by John Garry 15 Mar '21

15 Mar '21

On 21/12/2020 13:04, Jiahui Cen wrote: >> On 21/12/2020 03:24, Jiahui Cen wrote: >>> Hi John, >>> >>> On 2020/12/18 18:40, John Garry wrote: >>>> On 18/12/2020 06:23, Jiahui Cen wrote: >>>>> Since the [start, end) is a half-open interval, a range with the end equal >>>>> to the start of another range should not be considered as overlapped. >>>>> >>>>> Signed-off-by: Jiahui Cen<cenjiahui(a)huawei.com> >>>>> --- >>>>> lib/logic_pio.c | 2 +- >>>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>>> >>>>> diff --git a/lib/logic_pio.c b/lib/logic_pio.c >>>>> index f32fe481b492..445d611f1dc1 100644 >>>>> --- a/lib/logic_pio.c >>>>> +++ b/lib/logic_pio.c >>>>> @@ -57,7 +57,7 @@ int logic_pio_register_range(struct logic_pio_hwaddr *new_range) >>>>> new_range->flags == LOGIC_PIO_CPU_MMIO) { >>>>> /* for MMIO ranges we need to check for overlap */ >>>>> if (start >= range->hw_start + range->size || >>>>> - end < range->hw_start) { >>>>> + end <= range->hw_start) { >>>> It looks like your change is correct, but should not really have an impact in practice since: >>>> a: BIOSes generally list ascending IO port CPU addresses >>>> b. there is space between IO port CPU address regions >>>> >>>> Have you seen a problem here? >>>> >>> No serious problem. I found it just when I was working on adding support of >>> pci expander bridge for Arm in QEMU. I found the IO window of some extended >>> root bus could not be registered when I inserted the extended buses' _CRS >>> info into DSDT table in the x86 way, which does not sort the buses. >>> >>> Though root buses should be sorted in QEMU, would it be better to accept >>> those non-ascending IO windows? >>> >> ok, so it seems that you have seen a real problem, and this issue is not just detected by code analysis. >> >>> BTW, for b, it seems to be no space between IO windows of different root buses >>> generated by EDK2. Or maybe I missed something obvious. >> I don't know about that. Anyway, your change looks ok. >> >> Reviewed-by: John Garry<john.garry(a)huawei.com> >> >> BTW, for your virt env, will there be requirement to unregister PCI MMIO ranges? Currently we don't see that in non-virt world. >> > Thanks for your review. > > And currently there is no such a requirement in my virt env. > I am not sure what happened to this patch, but I plan on sending some patches in this area soon - do you want me to include this one? Thanks, John

2 2

[PATCH RFC v2 rdma-core 0/6] libhns: Add support for Dynamic Context Attachment
by Weihang Li 15 Mar '21

15 Mar '21

The HIP09 introduces the DCA(Dynamic Context Attachment) feature which supports many RC QPs to share the WQE buffer in a memory pool. If a QP enables DCA feature, the WQE's buffer will not be allocated when creating but when the users start to post WRs. This will reduce the memory consumption when there are too many QPs are inactive. For more detailed information, please refer to the man pages provided by the last patch of this series. This series is associated with the kernel one "RDMA/hns: Add support for Dynamic Context Attachment", you can review it at: https://patchwork.kernel.org/project/linux-rdma/cover/1611394994-50363-1-gi… Changes since v1: - Add direct verbs to set the parameters about size that used to configuring DCA. - Add man pages to explain what is DCA, how does it works and how to use it. - Link: https://patchwork.kernel.org/project/linux-rdma/cover/1612667574-56673-1-gi… Weihang Li (1): Update kernel headers Xi Wang (5): libhns: Introduce DCA for RC QP libhns: Add support for shrinking DCA memory pool libhns: Add support for attaching QP's WQE buffer libhns: Add direct verb to support config DCA memory pool libhns: Add man pages to introduce DCA feature CMakeLists.txt | 1 + debian/ibverbs-providers.install | 1 + debian/ibverbs-providers.lintian-overrides | 4 +- debian/ibverbs-providers.symbols | 5 + debian/libibverbs-dev.install | 6 + kernel-headers/rdma/hns-abi.h | 64 +++++ libibverbs/cmd_qp.c | 3 +- libibverbs/man/ibv_create_qp_ex.3 | 1 + libibverbs/verbs.h | 1 + providers/hns/CMakeLists.txt | 9 +- providers/hns/hns_roce_u.c | 96 +++++++ providers/hns/hns_roce_u.h | 44 ++++ providers/hns/hns_roce_u_abi.h | 1 + providers/hns/hns_roce_u_buf.c | 387 +++++++++++++++++++++++++++++ providers/hns/hns_roce_u_hw_v2.c | 138 +++++++++- providers/hns/hns_roce_u_hw_v2.h | 7 + providers/hns/hns_roce_u_verbs.c | 44 +++- providers/hns/hnsdv.h | 44 ++++ providers/hns/libhns.map | 8 + providers/hns/man/CMakeLists.txt | 6 + providers/hns/man/hns_dca.7.md | 35 +++ providers/hns/man/hnsdv.7.md | 34 +++ providers/hns/man/hnsdv_is_supported.3.md | 39 +++ providers/hns/man/hnsdv_open_device.3.md | 70 ++++++ redhat/rdma-core.spec | 5 + suse/rdma-core.spec | 19 ++ 26 files changed, 1051 insertions(+), 21 deletions(-) create mode 100644 providers/hns/hnsdv.h create mode 100644 providers/hns/libhns.map create mode 100644 providers/hns/man/CMakeLists.txt create mode 100644 providers/hns/man/hns_dca.7.md create mode 100644 providers/hns/man/hnsdv.7.md create mode 100644 providers/hns/man/hnsdv_is_supported.3.md create mode 100644 providers/hns/man/hnsdv_open_device.3.md -- 2.8.1

3 8

[RESEND PATCH v2 0/2] scripts/gdb: clarify the platforms supporting lx_current and add arm64 support
by Barry Song 15 Mar '21

15 Mar '21

lx_current depends on per_cpu current_task variable which exists on x86 only. so it actually works on x86 only. the 1st patch documents this clearly; the 2nd patch adds support for arm64. -resend resending to Andrew as Kieran Bingham explained patches of scripts/gdb usually go through the tree of Andrew Morton; Barry Song (2): scripts/gdb: document lx_current is only supported by x86 scripts/gdb: add lx_current support for arm64 .../dev-tools/gdb-kernel-debugging.rst | 2 +- scripts/gdb/linux/cpus.py | 23 +++++++++++++++++-- 2 files changed, 22 insertions(+), 3 deletions(-) -- 2.25.1

1 2

[PATCH net-next 0/4] net: hns3: support imp-controlled PHYs
by Huazhong Tan 14 Mar '21

14 Mar '21

This series adds support for imp-controlled PHYs in the HNS3 ethernet driver. Guangbin Huang (4): net: hns3: add support for imp-controlled PHYs net: hns3: add get/set pause parameters support for imp-controlled PHYs net: hns3: add ioctl support for imp-controlled PHYs net: hns3: add phy loopback support for imp-controlled PHYs drivers/net/ethernet/hisilicon/hns3/hnae3.h | 4 + drivers/net/ethernet/hisilicon/hns3/hns3_debugfs.c | 2 + drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c | 9 +- .../net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c | 4 + .../net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h | 44 +++- .../ethernet/hisilicon/hns3/hns3pf/hclge_debugfs.c | 20 +- .../ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 241 ++++++++++++++++++--- .../ethernet/hisilicon/hns3/hns3pf/hclge_mdio.c | 39 ++++ .../ethernet/hisilicon/hns3/hns3pf/hclge_mdio.h | 2 + 9 files changed, 321 insertions(+), 44 deletions(-) -- 2.7.4

2 5

2024

2023

2022

2021

2020

Linuxarm