April 2021 - Linuxarm - mailweb.openeuler.org

[PATCH v2] iommu/iova: put free_iova_mem() outside of spinlock iova_rbtree_lock
by chenxiang 15 Apr '21

15 Apr '21

From: Xiang Chen <chenxiang66(a)hisilicon.com> It is not necessary to put free_iova_mem() inside of spinlock/unlock iova_rbtree_lock which only leads to more completion for the spinlock. It has a small promote on the performance after the change. And also rename private_free_iova() as remove_iova() because the function will not free iova after that change. Signed-off-by: Xiang Chen <chenxiang66(a)hisilicon.com> --- drivers/iommu/iova.c | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c index b7ecd5b..c10af23 100644 --- a/drivers/iommu/iova.c +++ b/drivers/iommu/iova.c @@ -412,12 +412,11 @@ private_find_iova(struct iova_domain *iovad, unsigned long pfn) return NULL; } -static void private_free_iova(struct iova_domain *iovad, struct iova *iova) +static void remove_iova(struct iova_domain *iovad, struct iova *iova) { assert_spin_locked(&iovad->iova_rbtree_lock); __cached_rbnode_delete_update(iovad, iova); rb_erase(&iova->node, &iovad->rbroot); - free_iova_mem(iova); } /** @@ -452,8 +451,9 @@ __free_iova(struct iova_domain *iovad, struct iova *iova) unsigned long flags; spin_lock_irqsave(&iovad->iova_rbtree_lock, flags); - private_free_iova(iovad, iova); + remove_iova(iovad, iova); spin_unlock_irqrestore(&iovad->iova_rbtree_lock, flags); + free_iova_mem(iova); } EXPORT_SYMBOL_GPL(__free_iova); @@ -473,9 +473,9 @@ free_iova(struct iova_domain *iovad, unsigned long pfn) spin_lock_irqsave(&iovad->iova_rbtree_lock, flags); iova = private_find_iova(iovad, pfn); if (iova) - private_free_iova(iovad, iova); + remove_iova(iovad, iova); spin_unlock_irqrestore(&iovad->iova_rbtree_lock, flags); - + free_iova_mem(iova); } EXPORT_SYMBOL_GPL(free_iova); @@ -825,7 +825,8 @@ iova_magazine_free_pfns(struct iova_magazine *mag, struct iova_domain *iovad) if (WARN_ON(!iova)) continue; - private_free_iova(iovad, iova); + remove_iova(iovad, iova); + free_iova_mem(iova); } spin_unlock_irqrestore(&iovad->iova_rbtree_lock, flags); -- 2.8.1

2 1

FW: Patch "ice: Re-organizes reqstd/avail {R,T}XQ check/code for efficiency+readability" has been added to net-queue tree
by Salil Mehta 15 Apr '21

15 Apr '21

FYI. > From: anthony.l.nguyen(a)intel.com [mailto:anthony.l.nguyen@intel.com] > Sent: Wednesday, April 14, 2021 10:28 PM > To: Salil Mehta <salil.mehta(a)huawei.com> > Subject: Patch "ice: Re-organizes reqstd/avail {R,T}XQ check/code for > efficiency+readability" has been added to net-queue tree > > This is a note to let you know that I applied the following patch to > the dev-queue branch on the net-queue tree. > > http://patchwork.ozlabs.org/patch/1465962/ > > From 2c58268dac5bd0dbfe46614febd22b757e29582c Mon Sep 17 00:00:00 2001 > From: Salil Mehta <salil.mehta(a)huawei.com> > Date: Wed, 14 Apr 2021 12:01:49 -0700 > Subject: [PATCH] ice: Re-organizes reqstd/avail {R,T}XQ check/code for > efficiency+readability > > If user has explicitly requested the number of {R,T}XQs, then it is > unnecessary to get the count of already available {R,T}XQs from the > PF avail_{r,t}xqs bitmap. This value will get overridden by user specified > value in any case. > > This patch does minor re-organization of the code for improving the flow > and readabiltiy. This scope of improvement was found during the review of > the ICE driver code. > > FYI, I could not test this change due to unavailability of the hardware. > It would be helpful if somebody can test this patch and provide Tested-by > Tag. Many thanks! > > Fixes: 87324e747fde ("ice: Implement ethtool ops for channels") > Cc: intel-wired-lan(a)lists.osuosl.org > Cc: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com> > Signed-off-by: Salil Mehta <salil.mehta(a)huawei.com> > --- > > checkpatch.pl reports: > > total: 0 errors, 0 warnings, 0 checks, 32 lines checked > > .apply/V2-net-ice-Re-organizes-reqstd-avail-R-T-XQ-check-code-for-efficienc > y-readability.patch has no obvious style problems and is ready for submission.

1 0

[PATCH net-next 0/2] net: hns3: updates for -next
by Huazhong Tan 15 Apr '21

15 Apr '21

This series adds support for pushing link status to VFs for the HNS3 ethernet driver. Guangbin Huang (2): net: hns3: PF add support for pushing link status to VFs net: hns3: VF not request link status when PF support push link status feature drivers/net/ethernet/hisilicon/hns3/hclge_mbx.h | 3 ++ .../ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 35 +++++++++++++++++++++- .../ethernet/hisilicon/hns3/hns3pf/hclge_main.h | 1 + .../net/ethernet/hisilicon/hns3/hns3pf/hclge_mbx.c | 12 ++++---- .../ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c | 8 +++-- .../ethernet/hisilicon/hns3/hns3vf/hclgevf_main.h | 1 + .../ethernet/hisilicon/hns3/hns3vf/hclgevf_mbx.c | 6 ++++ 7 files changed, 55 insertions(+), 11 deletions(-) -- 2.7.4

2 8

linuxarm@openeuler.org You have [9] qurantined messages in your quarantine portal
by openeuler.org 15 Apr '21

15 Apr '21

1 0

Re: [PATCH] iommu/iova: put free_iova_mem() outside of spinlock iova_rbtree_lock
by Robin Murphy 14 Apr '21

14 Apr '21

On 2021-04-14 07:38, chenxiang wrote: > From: Xiang Chen <chenxiang66(a)hisilicon.com> > > It is not necessary to put free_iova_mem() inside of spinlock/unlock > iova_rbtree_lock which only leads to more completion for the spinlock. > It has a small promote on the performance after the change. This seems not entirely unreasonable, but private_free_iova() really needs to be renamed (maybe something like remove_iova()?) if it's no longer actually freeing anything - otherwise it's just unnecessarily misleading. Robin. > Signed-off-by: Xiang Chen <chenxiang66(a)hisilicon.com> > --- > drivers/iommu/iova.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c > index c669526f..292ed4a 100644 > --- a/drivers/iommu/iova.c > +++ b/drivers/iommu/iova.c > @@ -339,7 +339,6 @@ static void private_free_iova(struct iova_domain *iovad, struct iova *iova) > assert_spin_locked(&iovad->iova_rbtree_lock); > __cached_rbnode_delete_update(iovad, iova); > rb_erase(&iova->node, &iovad->rbroot); > - free_iova_mem(iova); > } > > /** > @@ -376,6 +375,7 @@ __free_iova(struct iova_domain *iovad, struct iova *iova) > spin_lock_irqsave(&iovad->iova_rbtree_lock, flags); > private_free_iova(iovad, iova); > spin_unlock_irqrestore(&iovad->iova_rbtree_lock, flags); > + free_iova_mem(iova); > } > EXPORT_SYMBOL_GPL(__free_iova); > > @@ -397,7 +397,7 @@ free_iova(struct iova_domain *iovad, unsigned long pfn) > if (iova) > private_free_iova(iovad, iova); > spin_unlock_irqrestore(&iovad->iova_rbtree_lock, flags); > - > + free_iova_mem(iova); > } > EXPORT_SYMBOL_GPL(free_iova); > > @@ -746,6 +746,7 @@ iova_magazine_free_pfns(struct iova_magazine *mag, struct iova_domain *iovad) > continue; > > private_free_iova(iovad, iova); > + free_iova_mem(iova); > } > > spin_unlock_irqrestore(&iovad->iova_rbtree_lock, flags); >

1 0

[PATCH] ethdev: add queue state when retrieve queue information
by Lijun Ou 14 Apr '21

14 Apr '21

Currently, upper-layer application could get queue state only through pointers such as dev->data->tx_queue_state[queue_id], this is not the recommended way to access it. So this patch add get queue state when call rte_eth_rx_queue_info_get and rte_eth_tx_queue_info_get API. Note: The hairpin queue is not supported with above rte_eth_*x_queue_info_get, so the queue state could be RTE_ETH_QUEUE_STATE_STARTED or RTE_ETH_QUEUE_STATE_STOPPED. Note: After add queue_state field, the 'struct rte_eth_rxq_info' size remains 128B, and the 'struct rte_eth_txq_info' size remains 64B, so it could be ABI compatible. Signed-off-by: Chengwen Feng <fengchengwen(a)huawei.com> Signed-off-by: Lijun Ou <oulijun(a)huawei.com> --- doc/guides/rel_notes/release_21_05.rst | 6 ++++++ lib/librte_ethdev/rte_ethdev.c | 3 +++ lib/librte_ethdev/rte_ethdev.h | 4 ++++ 3 files changed, 13 insertions(+) diff --git a/doc/guides/rel_notes/release_21_05.rst b/doc/guides/rel_notes/release_21_05.rst index 43063e3..165b5f7 100644 --- a/doc/guides/rel_notes/release_21_05.rst +++ b/doc/guides/rel_notes/release_21_05.rst @@ -156,6 +156,12 @@ ABI Changes * No ABI change that would break compatibility with 20.11. +* Added new field ``queue_state`` to ``rte_eth_rxq_info`` structure + to provide indicated rxq queue state. + +* Added new field ``queue_state`` to ``rte_eth_txq_info`` structure + to provide indicated txq queue state. + Known Issues ------------ diff --git a/lib/librte_ethdev/rte_ethdev.c b/lib/librte_ethdev/rte_ethdev.c index 3059aa5..fbd10b2 100644 --- a/lib/librte_ethdev/rte_ethdev.c +++ b/lib/librte_ethdev/rte_ethdev.c @@ -5042,6 +5042,8 @@ rte_eth_rx_queue_info_get(uint16_t port_id, uint16_t queue_id, memset(qinfo, 0, sizeof(*qinfo)); dev->dev_ops->rxq_info_get(dev, queue_id, qinfo); + qinfo->queue_state = dev->data->rx_queue_state[queue_id]; + return 0; } @@ -5082,6 +5084,7 @@ rte_eth_tx_queue_info_get(uint16_t port_id, uint16_t queue_id, memset(qinfo, 0, sizeof(*qinfo)); dev->dev_ops->txq_info_get(dev, queue_id, qinfo); + qinfo->queue_state = dev->data->tx_queue_state[queue_id]; return 0; } diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h index efda313..3b83c5a 100644 --- a/lib/librte_ethdev/rte_ethdev.h +++ b/lib/librte_ethdev/rte_ethdev.h @@ -1591,6 +1591,8 @@ struct rte_eth_rxq_info { uint8_t scattered_rx; /**< scattered packets RX supported. */ uint16_t nb_desc; /**< configured number of RXDs. */ uint16_t rx_buf_size; /**< hardware receive buffer size. */ + /**< Queues state: STARTED(1) / STOPPED(0). */ + uint8_t queue_state; } __rte_cache_min_aligned; /** @@ -1600,6 +1602,8 @@ struct rte_eth_rxq_info { struct rte_eth_txq_info { struct rte_eth_txconf conf; /**< queue config parameters. */ uint16_t nb_desc; /**< configured number of TXDs. */ + /**< Queues state: STARTED(1) / STOPPED(0). */ + uint8_t queue_state; } __rte_cache_min_aligned; /* Generic Burst mode flag definition, values can be ORed. */ -- 2.7.4

6 18

Re: [PATCH RFC net] net: hns3: fixes+refactors the broken set channel fallback logic
by Salil Mehta 14 Apr '21

14 Apr '21

> From: lipeng (Y) > Sent: Wednesday, April 14, 2021 2:59 AM > > > 在 2021/4/13 21:55, Salil Mehta 写道: > >> From: lipeng (Y) > >> Sent: Tuesday, April 13, 2021 1:38 PM > >> > >> > >> 在 2021/4/13 19:17, Salil Mehta 写道: > >>>> From: lipeng (Y) > >>>> Sent: Tuesday, April 13, 2021 10:30 AM > >>>> To: Salil Mehta <salil.mehta(a)huawei.com>; Linuxarm <linuxarm(a)huawei.com>; > >>>> linuxarm(a)openeuler.org > >>>> Cc: Zhuangyuzeng (Yisen) <yisen.zhuang(a)huawei.com>; huangdaode > >>>> <huangdaode(a)huawei.com>; linyunsheng <linyunsheng(a)huawei.com>; shenjian > (K) > >>>> <shenjian15(a)huawei.com>; moyufeng <moyufeng(a)huawei.com>; zhangjiaran > >>>> <zhangjiaran(a)huawei.com>; huangguangbin (A) <huangguangbin2(a)huawei.com>; > >>>> Jonathan Cameron <jonathan.cameron(a)huawei.com> > >>>> Subject: Re: [PATCH RFC net] net: hns3: fixes+refactors the broken set > channel > >>>> fallback logic > >>>> > >>>> > >>>> 在 2021/4/13 17:12, Salil Mehta 写道: > >>>>> The fallback logic of the set channels when set_channel() fails to configure > >>>>> TX Sched/RSS H/W configuration or for the code which brings down/restores > >>>>> client before/therafter is not handled properly. > >>>>> > >>>>> This patch fixes and refactors that code to improve the readibility. > >>>>> > >>>>> [INTERNAL ONLY] > >>>>> Fixes: <Tag TODO> ("Comment TODO") > >>>>> Signed-off-by: Salil Mehta <salil.mehta(a)huawei.com> > >>>>> --- > >>>>> .../net/ethernet/hisilicon/hns3/hns3_enet.c | 72 > +++++++++++-------- > >>>>> 1 file changed, 43 insertions(+), 29 deletions(-) > >>>>> > >>>>> diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c > >>>> b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c > >>>>> index bf4302a5cf95..41d8bdb34f6e 100644 > >>>>> --- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c > >>>>> +++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c > >>>>> @@ -4692,23 +4692,56 @@ static int hns3_reset_notify(struct hnae3_handle > >>>> *handle, > >>>>> static int hns3_change_channels(struct hnae3_handle *handle, u32 > >>>> new_tqp_num, > >>>>> bool rxfh_configured) > >>>>> { > >>>>> - int ret; > >>>>> + const struct hnae3_ae_ops *ops = handle->ae_algo->ops; > >>>>> + u32 org_tqp_num = handle->kinfo.num_tqps; > >>>>> + struct device *dev = &handle->pdev->dev; > >>>>> + u32 req_tqp_num = new_tqp_num; > >>>>> + bool revert_old_config = false; > >>>>> + int ret, retval = 0; > >>>>> + > >>>>> + /* bring down the client */ > >>>>> + ret = hns3_reset_notify(handle, HNAE3_DOWN_CLIENT); > >>>>> + if (ret) > >>>>> + return ret; > >>>>> > >>>>> - ret = handle->ae_algo->ops->set_channels(handle, new_tqp_num, > >>>>> - rxfh_configured); > >>>>> - if (ret) { > >>>>> - dev_err(&handle->pdev->dev, > >>>>> - "Change tqp num(%u) fail.\n", new_tqp_num); > >>>>> + ret = hns3_reset_notify(handle, HNAE3_UNINIT_CLIENT); > >>>>> + if (ret) > >>>>> return ret; > >>>>> + > >>>>> +revert_old_tpqs_config: > >>>>> + /* update the traffic sched and RSS config in the H/W as per new TPQ > num > >>>> */ > >>>>> + ret = ops->set_channels(handle, req_tqp_num, rxfh_configured); > >>>>> + if (ret) { > >>>>> + dev_err(dev, "failed(=%d) to update TX sched/RSS h/w cfg for %s > >> TPQs\n", > >>>>> + ret, revert_old_config?"old":"new"); > >>>>> + > >>>>> + /* try reverting back h/w config with old TPQ num */ > >>>>> + if (!revert_old_config) { > >>>>> + dev_warn(dev, > >>>>> + "will try to revert TX sched/RSS h/w cfg with old TPQs\n"); > >>>>> + req_tqp_num = org_tqp_num; > >>>>> + revert_old_config = true; > >>>>> + retval = ret; > >>>>> + > >>>>> + goto revert_old_tpqs_config; > >>>>> + } > >>>>> + > >>>>> + /* bad, we could not revert to h/w config with old TQP number */ > >>>>> + goto err_set_chan_fail; > >>>> why you changelike this ? > >>>> > >>>> > >>>> when setting fail, the port should work OK just like setting before. > >>> The port can get into problematic state if the client remains in un-initialized > >>> state after errors are encountered during the process of setting the channels > >>> for new number of TPQs. Port cannot be said to be in sane state. > >>> > >>> Conditions(after desperate attempt to revert to old TPQ config fails): > >>> 1. half un-initialized state of the client or > >>> 2. client un-initialized but not re-initialized or > >>> 3. client re-initialization fails later > >>> > >>> > >>> This condition can only be recovered when you reset or re-load the driver. > >>> > >>> > >> do you have any test case for it ? > > > > We need to simulate the TX Sched/RSS hardware config failure at firmware/IMP. > > For the integration Testing, we can always create one but for system testing > > we need ways in the firmware to be able to simulate these failures. Some > > debugging feature is required in the firmware. Maybe somebody can take this > > task and introduce this feature in the IMP firmware code if it does not exists > > already? I would suggest to expose all these controls using 'devlink' interface > > to the user which can be used by sys test team as well. > > > > > >> when user change channel larger by ethtool command , and the > >> memory not enough, it will fail. > >> > >> we should recovered too. > > All of these should get conveyed by the hnae3 layer when you do set channels > or when > > we do client re-initialization(init+up) > > > This patch will make some test case fail, it is OK before this change. Can you please list down the test case which is failing or will fail?

1 0

[RFC PATCH v3 0/2] scheduler: expose the topology of clusters and add cluster scheduler
by Barry Song 14 Apr '21

14 Apr '21

ARM64 server chip Kunpeng 920 has 6 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 | | | | | | | | | | | | | | +------+ +------+ | +-----------+ | | | | | | +-----------------------------------+ | | +-----------------------------------+ | | | +------+ +------+ +--------------------------+ | | | | | | | +-----------+ | | | +------+ +------+ | | | | | Through the following small program, you can see the performance impact of running it in one cluster and across two clusters: struct foo { int x; int y; } f; void *thread1_fun(void *param) { int s = 0; for (int i = 0; i < 0xfffffff; i++) s += f.x; } void *thread2_fun(void *param) { int s = 0; for (int i = 0; i < 0xfffffff; i++) f.y++; } int main(int argc, char **argv) { pthread_t tid1, tid2; pthread_create(&tid1, NULL, thread1_fun, NULL); pthread_create(&tid2, NULL, thread2_fun, NULL); pthread_join(tid1, NULL); pthread_join(tid2, NULL); } While running this program in one cluster, it takes: $ time taskset -c 0,1 ./a.out real 0m0.832s user 0m1.649s sys 0m0.004s As a contrast, it takes much more time if we run the same program in two clusters: $ time taskset -c 0,4 ./a.out real 0m1.133s user 0m1.960s sys 0m0.000s 0.832/1.133 = 73%, it is a huge difference. Also, hackbench running on 4 cpus in single one cluster and 4 cpus in different clusters also shows a large contrast: * inside a cluster: root@ubuntu:~# taskset -c 0,1,2,3 hackbench -p -T -l 20000 -g 1 Running in threaded mode with 1 groups using 40 file descriptors each (== 40 tasks) Each sender will pass 20000 messages of 100 bytes Time: 4.285 * across clusters: root@ubuntu:~# taskset -c 0,4,8,12 hackbench -p -T -l 20000 -g 1 Running in threaded mode with 1 groups using 40 file descriptors each (== 40 tasks) Each sender will pass 20000 messages of 100 bytes Time: 5.524 The score is 4.285 vs 5.524, shorter time means better performance. All these testing implies that we should let the Linux scheduler use this topology to make better load balancing and WAKE_AFFINE decisions. However, the current scheduler totally has no idea of clusters. This patchset exposed the cluster topology first, then added the sched domain for cluster. While it is named as "cluster", architectures and machines can define the exact meaning of cluster as long as they have some resources sharing under llc and they can leverage the affinity of this resource to achive better scheduling performance. -v3: - rebased againest 5.11-rc2 - with respect to the comments of Valentin Schneider, Peter Zijlstra, Vincent Guittot and Mel Gorman etc. * moved the scheduler changes from arm64 to the common place for all architectures. * added SD_SHARE_CLS_RESOURCES sd_flags specifying the sched_domain where select_idle_cpu() should begin to scan from * removed redundant select_idle_cluster() function since all code is in select_idle_cpu() now. it also avoided scanning cluster cpus twice in v2 code; * redo the hackbench in one numa after the above changes Valentin suggested that select_idle_cpu() could begin to scan from domain with SD_SHARE_PKG_RESOURCES. Changing like this might be too aggressive and limit the spreading of tasks. Thus, this patch lets the architectures and machines to decide where to start by adding a new SD_SHARE_CLS_RESOURCES. Barry Song (1): scheduler: add scheduler level for clusters Jonathan Cameron (1): topology: Represent clusters of CPUs within a die. Documentation/admin-guide/cputopology.rst | 26 +++++++++++--- arch/arm64/Kconfig | 7 ++++ arch/arm64/kernel/topology.c | 2 ++ drivers/acpi/pptt.c | 60 +++++++++++++++++++++++++++++++ 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/sd_flags.h | 9 +++++ include/linux/sched/topology.h | 7 ++++ include/linux/topology.h | 13 +++++++ kernel/sched/fair.c | 27 ++++++++++---- kernel/sched/topology.c | 6 ++++ 13 files changed, 181 insertions(+), 10 deletions(-) -- 2.7.4

7 19

[PATCH RFC net] net: hns3: fixes+refactors the broken set channel fallback logic
by Salil Mehta 13 Apr '21

13 Apr '21

The fallback logic of the set channels when set_channel() fails to configure TX Sched/RSS H/W configuration or for the code which brings down/restores client before/therafter is not handled properly. This patch fixes and refactors that code to improve the readibility. [INTERNAL ONLY] Fixes: <Tag TODO> ("Comment TODO") Signed-off-by: Salil Mehta <salil.mehta(a)huawei.com> --- .../net/ethernet/hisilicon/hns3/hns3_enet.c | 72 +++++++++++-------- 1 file changed, 43 insertions(+), 29 deletions(-) diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c index bf4302a5cf95..41d8bdb34f6e 100644 --- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c +++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c @@ -4692,23 +4692,56 @@ static int hns3_reset_notify(struct hnae3_handle *handle, static int hns3_change_channels(struct hnae3_handle *handle, u32 new_tqp_num, bool rxfh_configured) { - int ret; + const struct hnae3_ae_ops *ops = handle->ae_algo->ops; + u32 org_tqp_num = handle->kinfo.num_tqps; + struct device *dev = &handle->pdev->dev; + u32 req_tqp_num = new_tqp_num; + bool revert_old_config = false; + int ret, retval = 0; + + /* bring down the client */ + ret = hns3_reset_notify(handle, HNAE3_DOWN_CLIENT); + if (ret) + return ret; - ret = handle->ae_algo->ops->set_channels(handle, new_tqp_num, - rxfh_configured); - if (ret) { - dev_err(&handle->pdev->dev, - "Change tqp num(%u) fail.\n", new_tqp_num); + ret = hns3_reset_notify(handle, HNAE3_UNINIT_CLIENT); + if (ret) return ret; + +revert_old_tpqs_config: + /* update the traffic sched and RSS config in the H/W as per new TPQ num */ + ret = ops->set_channels(handle, req_tqp_num, rxfh_configured); + if (ret) { + dev_err(dev, "failed(=%d) to update TX sched/RSS h/w cfg for %s TPQs\n", + ret, revert_old_config?"old":"new"); + + /* try reverting back h/w config with old TPQ num */ + if (!revert_old_config) { + dev_warn(dev, + "will try to revert TX sched/RSS h/w cfg with old TPQs\n"); + req_tqp_num = org_tqp_num; + revert_old_config = true; + retval = ret; + + goto revert_old_tpqs_config; + } + + /* bad, we could not revert to h/w config with old TQP number */ + goto err_set_chan_fail; } + /* restore the client */ ret = hns3_reset_notify(handle, HNAE3_INIT_CLIENT); if (ret) - return ret; + goto err_set_chan_fail; ret = hns3_reset_notify(handle, HNAE3_UP_CLIENT); if (ret) - hns3_reset_notify(handle, HNAE3_UNINIT_CLIENT); + goto err_set_chan_fail; + + return retval; +err_set_chan_fail: + dev_warn(dev, "device could be in insane state. Reset rqd. or reload the driver!\n"); return ret; } @@ -4720,7 +4753,6 @@ int hns3_set_channels(struct net_device *netdev, struct hnae3_knic_private_info *kinfo = &h->kinfo; bool rxfh_configured = netif_is_rxfh_configured(netdev); u32 new_tqp_num = ch->combined_count; - u16 org_tqp_num; int ret; if (hns3_nic_resetting(netdev)) @@ -4750,28 +4782,10 @@ int hns3_set_channels(struct net_device *netdev, "set channels: tqp_num=%u, rxfh=%d\n", new_tqp_num, rxfh_configured); - ret = hns3_reset_notify(h, HNAE3_DOWN_CLIENT); - if (ret) - return ret; - - ret = hns3_reset_notify(h, HNAE3_UNINIT_CLIENT); - if (ret) - return ret; - - org_tqp_num = h->kinfo.num_tqps; ret = hns3_change_channels(h, new_tqp_num, rxfh_configured); if (ret) { - int ret1; - - netdev_warn(netdev, - "Change channels fail, revert to old value\n"); - ret1 = hns3_change_channels(h, org_tqp_num, rxfh_configured); - if (ret1) { - netdev_err(netdev, - "revert to old channel fail\n"); - return ret1; - } - + netdev_err(netdev, "fail(=%d) to set number of channels to %u\n", ret, + new_tqp_num); return ret; } -- 2.17.1

2 4

[PATCH net] ice: Re-organizes reqstd/avail {R,T}XQ check/code for efficiency+readability
by Salil Mehta 13 Apr '21

13 Apr '21

If user has explicitly requested the number of {R,T}XQs, then it is unnecessary to get the count of already available {R,T}XQs from the PF avail_{r,t}xqs bitmap. This value will get overriden by user specified value in any case. This patch does minor re-organization of the code for improving the flow and readabiltiy. This scope of improvement was found during the review of the ICE driver code. FYI, I could not test this change due to unavailability of the hardware. It would helpful if somebody can test this and provide Tested-by Tag. Many thanks! Fixes: 11b7551e096d ("ice: Implement ethtool ops for channels") Signed-off-by: Salil Mehta <salil.mehta(a)huawei.com> --- drivers/net/ethernet/intel/ice/ice_lib.c | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/drivers/net/ethernet/intel/ice/ice_lib.c b/drivers/net/ethernet/intel/ice/ice_lib.c index d13c7fc8fb0a..161e8dfe548c 100644 --- a/drivers/net/ethernet/intel/ice/ice_lib.c +++ b/drivers/net/ethernet/intel/ice/ice_lib.c @@ -161,12 +161,13 @@ static void ice_vsi_set_num_qs(struct ice_vsi *vsi, u16 vf_id) switch (vsi->type) { case ICE_VSI_PF: - vsi->alloc_txq = min3(pf->num_lan_msix, - ice_get_avail_txq_count(pf), - (u16)num_online_cpus()); if (vsi->req_txq) { vsi->alloc_txq = vsi->req_txq; vsi->num_txq = vsi->req_txq; + } else { + vsi->alloc_txq = min3(pf->num_lan_msix, + ice_get_avail_txq_count(pf), + (u16)num_online_cpus()); } pf->num_lan_tx = vsi->alloc_txq; @@ -175,12 +176,13 @@ static void ice_vsi_set_num_qs(struct ice_vsi *vsi, u16 vf_id) if (!test_bit(ICE_FLAG_RSS_ENA, pf->flags)) { vsi->alloc_rxq = 1; } else { - vsi->alloc_rxq = min3(pf->num_lan_msix, - ice_get_avail_rxq_count(pf), - (u16)num_online_cpus()); if (vsi->req_rxq) { vsi->alloc_rxq = vsi->req_rxq; vsi->num_rxq = vsi->req_rxq; + } else { + vsi->alloc_rxq = min3(pf->num_lan_msix, + ice_get_avail_rxq_count(pf), + (u16)num_online_cpus()); } } -- 2.17.1

2 2

[PATCH v1 0/2] scsi: libsas: few clean up patches
by Luo Jiaxing 13 Apr '21

13 Apr '21

Two types of errors are detected by the checkpatch. 1. Alignment between switches and cases 2. Improper use of some spaces Here are the clean up patches. Luo Jiaxing (2): scsi: libsas: make switch and case at the same indent in sas_to_ata_err() scsi: libsas: clean up for white spaces drivers/scsi/libsas/sas_ata.c | 74 ++++++++++++++++++-------------------- drivers/scsi/libsas/sas_discover.c | 2 +- drivers/scsi/libsas/sas_expander.c | 15 ++++---- 3 files changed, 43 insertions(+), 48 deletions(-) -- 2.7.4

3 4

[RFC PATCH v3 0/3] vfio/hisilicon: add acc live migration driver
by Longfang Liu 13 Apr '21

13 Apr '21

The live migration solution relies on the vfio_device_migration_info protocol. The structure vfio_device_migration_info is placed at the 0th offset of the VFIO_REGION_SUBTYPE_MIGRATION region to get and set VFIO device related migration information. Field accesses from this structure are only supported at their native width and alignment. Otherwise, the result is undefined and vendor drivers should return an error. (1).The driver framework is based on vfio_pci_register_dev_region() of vfio-pci, and then a new live migration region is added, and the live migration is realized through the ops of this region. (2).In order to ensure the compatibility of the devices before and after the migration, the device compatibility information check will be performed in the Pre-copy stage. If the check fails, an error will be returned and the source VM will exit the migration function. (3).After the compatibility check is passed, it will enter the Stop-and-copy stage. At this time, all the live migration data will be copied, and then saved to the VF device of the destination, and then the VF device of the destination will be started and the VM of the source will be exited. Longfang Liu (3): vfio/hisilicon: add acc live migration driver vfio/hisilicon: register the driver to vfio vfio/hisilicom: add debugfs for driver drivers/vfio/pci/Kconfig | 9 + drivers/vfio/pci/Makefile | 3 +- drivers/vfio/pci/hisilicon/acc_vf_migration.c | 1357 +++++++++++++++++++++++++ drivers/vfio/pci/hisilicon/acc_vf_migration.h | 172 ++++ drivers/vfio/pci/vfio_pci.c | 11 + drivers/vfio/pci/vfio_pci_private.h | 10 + 6 files changed, 1561 insertions(+), 1 deletion(-) create mode 100644 drivers/vfio/pci/hisilicon/acc_vf_migration.c create mode 100644 drivers/vfio/pci/hisilicon/acc_vf_migration.h -- 2.8.1

2 4

[RFC PATCH v3 0/3] vfio/hisilicon: add acc live migration driver
by Longfang Liu 13 Apr '21

13 Apr '21

The live migration solution relies on the vfio_device_migration_info protocol. The structure vfio_device_migration_info is placed at the 0th offset of the VFIO_REGION_SUBTYPE_MIGRATION region to get and set VFIO device related migration information. Field accesses from this structure are only supported at their native width and alignment. Otherwise, the result is undefined and vendor drivers should return an error. (1).The driver framework is based on vfio_pci_register_dev_region() of vfio-pci, and then a new live migration region is added, and the live migration is realized through the ops of this region. (2).In order to ensure the compatibility of the devices before and after the migration, the device compatibility information check will be performed in the Pre-copy stage. If the check fails, an error will be returned and the source VM will exit the migration function. (3).After the compatibility check is passed, it will enter the Stop-and-copy stage. At this time, all the live migration data will be copied, and then saved to the VF device of the destination, and then the VF device of the destination will be started and the VM of the source will be exited. Longfang Liu (3): vfio/hisilicon: add acc live migration driver vfio/hisilicon: register the driver to vfio vfio/hisilicom: add debugfs for driver drivers/vfio/pci/Kconfig | 9 + drivers/vfio/pci/Makefile | 3 +- drivers/vfio/pci/hisilicon/acc_vf_migration.c | 1357 +++++++++++++++++++++++++ drivers/vfio/pci/hisilicon/acc_vf_migration.h | 172 ++++ drivers/vfio/pci/vfio_pci.c | 11 + drivers/vfio/pci/vfio_pci_private.h | 10 + 6 files changed, 1561 insertions(+), 1 deletion(-) create mode 100644 drivers/vfio/pci/hisilicon/acc_vf_migration.c create mode 100644 drivers/vfio/pci/hisilicon/acc_vf_migration.h -- 2.8.1

2 4

[PATCH 0/3] Fixes for testpmd
by Lijun Ou 12 Apr '21

12 Apr '21

This series add two test bug fixes and a print style. Hongbo Zheng (1): app/testpmd: use of Rx/Tx in testpmd Huisong Li (2): app/testpmd: fix forwarding configuration when DCB test app/testpmd: remove forwarding config from parsing Rx and Tx app/test-pmd/cmdline.c | 106 ++++++++++++++++---------------- app/test-pmd/config.c | 147 +++++++++++++++++++++++++-------------------- app/test-pmd/csumonly.c | 22 +++---- app/test-pmd/icmpecho.c | 2 +- app/test-pmd/ieee1588fwd.c | 18 +++--- app/test-pmd/parameters.c | 50 +++++++-------- app/test-pmd/testpmd.c | 132 ++++++++++++++++++++-------------------- app/test-pmd/testpmd.h | 28 ++++----- app/test-pmd/txonly.c | 2 +- 9 files changed, 263 insertions(+), 244 deletions(-) -- 2.7.4

7 37

[PATCH drivers/iio 0/3] convert sysfs sprintf/snprintf/scnprintf to sysfs_emit
by Tian Tao 12 Apr '21

12 Apr '21

Use the generic sysfs_emit() function to take place of sprintf/snprintf/scnprintf, to avoid buffer overrun. Tian Tao (3): iio:chemical:sps30: Convert sysfs sprintf/snprintf family to sysfs_emit iio: light: Convert sysfs sprintf/snprintf family to sysfs_emit iio: trigger: stm32-timer: Convert sysfs sprintf/snprintf family to sysfs_emit drivers/iio/chemical/sps30.c | 6 +++--- drivers/iio/light/veml6030.c | 2 +- drivers/iio/trigger/stm32-timer-trigger.c | 2 +- 3 files changed, 5 insertions(+), 5 deletions(-) -- 2.7.4

2 4

Re: [PATCH net v3] net: sched: fix packet stuck problem for lockless qdisc
by Yunsheng Lin 12 Apr '21

12 Apr '21

On 2021/4/9 13:31, Juergen Gross wrote: > On 25.03.21 04:13, Yunsheng Lin wrote: >> Lockless qdisc has below concurrent problem: >> cpu0 cpu1 >> . . >> q->enqueue . >> . . >> qdisc_run_begin() . >> . . >> dequeue_skb() . >> . . >> sch_direct_xmit() . >> . . >> . q->enqueue >> . qdisc_run_begin() >> . return and do nothing >> . . >> qdisc_run_end() . >> >> cpu1 enqueue a skb without calling __qdisc_run() because cpu0 >> has not released the lock yet and spin_trylock() return false >> for cpu1 in qdisc_run_begin(), and cpu0 do not see the skb >> enqueued by cpu1 when calling dequeue_skb() because cpu1 may >> enqueue the skb after cpu0 calling dequeue_skb() and before >> cpu0 calling qdisc_run_end(). >> >> Lockless qdisc has below another concurrent problem when >> tx_action is involved: >> >> cpu0(serving tx_action) cpu1 cpu2 >> . . . >> . q->enqueue . >> . qdisc_run_begin() . >> . dequeue_skb() . >> . . q->enqueue >> . . . >> . sch_direct_xmit() . >> . . qdisc_run_begin() >> . . return and do nothing >> . . . >> clear __QDISC_STATE_SCHED . . >> qdisc_run_begin() . . >> return and do nothing . . >> . . . >> . qdisc_run_end() . >> >> This patch fixes the above data race by: >> 1. Get the flag before doing spin_trylock(). >> 2. If the first spin_trylock() return false and the flag is not >> set before the first spin_trylock(), Set the flag and retry >> another spin_trylock() in case other CPU may not see the new >> flag after it releases the lock. >> 3. reschedule if the flags is set after the lock is released >> at the end of qdisc_run_end(). >> >> For tx_action case, the flags is also set when cpu1 is at the >> end if qdisc_run_end(), so tx_action will be rescheduled >> again to dequeue the skb enqueued by cpu2. >> >> Only clear the flag before retrying a dequeuing when dequeuing >> returns NULL in order to reduce the overhead of the above double >> spin_trylock() and __netif_schedule() calling. >> >> The performance impact of this patch, tested using pktgen and >> dummy netdev with pfifo_fast qdisc attached: >> >> threads without+this_patch with+this_patch delta >> 1 2.61Mpps 2.60Mpps -0.3% >> 2 3.97Mpps 3.82Mpps -3.7% >> 4 5.62Mpps 5.59Mpps -0.5% >> 8 2.78Mpps 2.77Mpps -0.3% >> 16 2.22Mpps 2.22Mpps -0.0% >> >> Fixes: 6b3ba9146fe6 ("net: sched: allow qdiscs to handle locking") >> Signed-off-by: Yunsheng Lin <linyunsheng(a)huawei.com> > > I have a setup which is able to reproduce the issue quite reliably: > > In a Xen guest I'm mounting 8 NFS shares and run sysbench fileio on > each of them. The average latency reported by sysbench is well below > 1 msec, but at least once per hour I get latencies in the minute > range. > > With this patch I don't see these high latencies any longer (test > is running for more than 20 hours now). > > So you can add my: > > Tested-by: Juergen Gross <jgross(a)suse.com> Hi, Juergen Thanks for the testing. With the simulated test case suggested by Michal, I still has some potential issue to debug, hopefully will send out new version in this week. Also, is it possible to run your testcase any longer? I think "72 hours" would be enough to testify that it fixes the problem completely:) > > > Juergen

2 1

Re: [PATCH 2/3] app/testpmd: remove forwarding config from parsing Rx and Tx
by oulijun 10 Apr '21

10 Apr '21

在 2021/4/9 15:08, Li, Xiaoyun 写道: > > >> -----Original Message----- >> From: oulijun <oulijun(a)huawei.com> >> Sent: Friday, April 9, 2021 14:10 >> To: linuxarm(a)openeuler.org; dev <dev(a)dpdk.org>; Li, Xiaoyun >> <xiaoyun.li(a)intel.com> >> Subject: Re: [Linuxarm] Re: [PATCH 2/3] app/testpmd: remove forwarding >> config from parsing Rx and Tx >> >> >> >> 在 2021/4/2 10:33, Li, Xiaoyun 写道: >>> >>> >>>> -----Original Message----- >>>> From: oulijun <oulijun(a)huawei.com> >>>> Sent: Friday, April 2, 2021 09:45 >>>> To: Li, Xiaoyun <xiaoyun.li(a)intel.com>; Yigit, Ferruh >>>> <ferruh.yigit(a)intel.com> >>>> Cc: dev(a)dpdk.org; linuxarm(a)openeuler.org >>>> Subject: Re: [PATCH 2/3] app/testpmd: remove forwarding config from >>>> parsing Rx and Tx >>>> >>>> >>>> >>>> 在 2021/3/29 9:53, Li, Xiaoyun 写道: >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: oulijun <oulijun(a)huawei.com> >>>>>> Sent: Thursday, March 25, 2021 11:04 >>>>>> To: Li, Xiaoyun <xiaoyun.li(a)intel.com>; Yigit, Ferruh >>>>>> <ferruh.yigit(a)intel.com> >>>>>> Cc: dev(a)dpdk.org; linuxarm(a)openeuler.org >>>>>> Subject: Re: [PATCH 2/3] app/testpmd: remove forwarding config from >>>>>> parsing Rx and Tx >>>>>> >>>>>> >>>>>> >>>>>> 在 2021/3/24 9:44, Li, Xiaoyun 写道: >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: oulijun <oulijun(a)huawei.com> >>>>>>>> Sent: Wednesday, March 24, 2021 09:01 >>>>>>>> To: Li, Xiaoyun <xiaoyun.li(a)intel.com>; Yigit, Ferruh >>>>>>>> <ferruh.yigit(a)intel.com> >>>>>>>> Cc: dev(a)dpdk.org; linuxarm(a)openeuler.org >>>>>>>> Subject: Re: [PATCH 2/3] app/testpmd: remove forwarding config >>>>>>>> from parsing Rx and Tx >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 在 2021/3/23 15:50, Li, Xiaoyun 写道: >>>>>>>>> Hi >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Lijun Ou <oulijun(a)huawei.com> >>>>>>>>>> Sent: Friday, March 5, 2021 18:22 >>>>>>>>>> To: Yigit, Ferruh <ferruh.yigit(a)intel.com> >>>>>>>>>> Cc: Li, Xiaoyun <xiaoyun.li(a)intel.com>; dev(a)dpdk.org; >>>>>>>>>> linuxarm(a)openeuler.org >>>>>>>>>> Subject: [PATCH 2/3] app/testpmd: remove forwarding config from >>>>>>>>>> parsing Rx and Tx >>>>>>>>>> >>>>>>>>>> From: Huisong Li <lihuisong(a)huawei.com> >>>>>>>>>> >>>>>>>>> >>>>>>>>> The commit message should be more simple and avoids grammar >>>> mistakes. >>>>>>>>> >>>>>>>> All right, I will simply it. >>>>>>>>>> The "fwd_config_setup()" function does release and apply for >>>>>>>>>> memory of forwarding flows, and re-establish these streams when >>>>>>>>>> rxq/txq or rxd/txd is changed. The function is also called by >>>>>>>>>> "start_packet_forwarding()" when user executes "start" cmd. >>>>>>>>>> All changes for rxq/txq or rxd/txd can be updated uniformly >>>>>>>>>> when this command is executed. Therefore, it is a little >>>>>>>>>> redundant in the >>>>>>>> "cmd_config_rx_tx_parsed" >>>>>>>>>> function. >>>>>>>>> >>>>>>>>> It's not redundant. This command may configure number of rxq/txq. >>>>>>>>> So the >>>>>>>> fwd streams map may change. >>>>>>>>> Then it's common to check the fwd streams after this command >>>>>>>>> using "show >>>>>>>> config fwd". >>>>>>>>> If you remove this fwd stream update, users can't get the >>>>>>>>> correct new fwd >>>>>>>> streams until they start the traffic. >>>>>>>>> But they may change a lot of things and want to check if the >>>>>>>>> setting is correct >>>>>>>> before they start the traffic. >>>>>>>>> >>>>>>>> Yes, you are right. It's really unfriendly. >>>>>>>>>> >>>>>>>>>> In addition, the forwarding stream under one TC is configured >>>>>>>>>> based on number of queues allocated to TC. And number of queues >>>>>>>>>> allocated to TC is updated after calling "rte_eth_dev_configure" >>>>>>>>>> again. If the number of queues is reduced after configuring the >>>>>>>>>> DCB, and then, release and apply for stream memory, and >>>>>>>>>> reinitialize the forwarding stream under the DCB mode based on >>>>>>>>>> the old TC >>>>>> information. >>>>>>>>>> As a result, null pointer may be accessed. >>>>>>>>> >>>>>>>>> I think you should add "rte_eth_dev_configure " into >>>>>>>>> dcb_fwd_config_setup() >>>>>>>> before rte_eth_dev_get_dcb_info(). >>>>>>>>> >>>>>>>>> And the commit message should be similar like the following: >>>>>>>>> Segment fault might happen after configuring queue number to >>>>>>>>> less because >>>>>>>> dcb_fwd_config_setup setup dcb based on old dcb info. >>>>>>>>> And dcb info can only update after rte_eth_dev_configure(). >>>>>>>>> So this patch adds rte_eth_dev_configure() before >>>>>>>>> rte_eth_dev_get_dcb_info() >>>>>>>> to get updated dcb info to fix this issue. >>>>>>>>> >>>>>>>> Thank you for your advice. But the above adjustments may still >>>>>>>> not work for some drivers. The mapping between queues and TCs in >>>>>>>> these drivers is updated in the dev_start stage. >>>>>>>> >>>>>>>> I have an idea. We can move fwd_config_setup() to start_port(), >>>>>>>> which is called by main() and after starting ports This not only >>>>>>>> solves the segment fault, but also does not have the problem you >>>>>>>> mentioned above. I >>>>>> test it and it is ok. >>>>>>>> >>>>>>>> What do you think, xiaoyun? >>>>>>> >>>>>>> How can you fix the issue I mentioned? >>>>>>> You still need to start port first to see the updated fwd config. >>>>>> Yes. But it can make sure that users get the correct new fwd >>>>>> streams before executing the 'start' command. >>>>>>> And for those drivers, why does the mapping has to be updated in >>>>>>> dev_start >>>>>> stage? >>>>>>> What does it need? Can't it be moved to dev_configure? >>>>>> The framework does not require that the configuration parameters >>>>>> transferred by the dev_configure API must be updated in the >>>>>> interface of driver. The driver can verify the correctness of >>>>>> these parameters in the interface, and then complete the update in >>>>>> the dev_start stage. It depends on the design and need of the >>>>>> driver. Maybe it's more appropriate to put it in dev_configure, but >>>>>> now we can't ask all these >>>> drivers to modify the operation. >>>>> >>>>> I still think it's driver's responsibility to configure DCB in dev_configure. >>>>> >>>>> Calling fwd_config_setup here is because this command changes queue >>>> number. Users just change queue number so want to check fwd setup. >>>> It's a normal and reasonable behavior. >>>>> Starting port will be called in many situations. I don't think it's >>>>> appropriate to >>>> call fwd_config_setup every time calling port_start. And you can't >>>> expect users know the fwd setup only change after port_start. >>>>> >>>>> These are only my thoughts. If anyone else agrees you, they can give you >> ack. >>>>>>>> >>>> @Ferruh, what do you think? >>>> Currently, both ixgbe and i40e also have this problem. Even if >>>> testpmd can be modified according to Xiaoyun's suggestion, and the >>>> driver is not modified, this problem still exists in some drivers, such as ixgbe >> and hns3. >>> >>> NO. I40e and ixgbe DON'T have the issue. >>> I40e tc mapping is done in dev_configure. >>> ixgbe tc mapping is always fixed due to hw design. It only needs dev_configure >> to get dcb_conf info. No matter you configure dcb or not, the mapping is always >> the same. You can check ixgbe_dev_get_dcb_info(). >>> >>> So for i40e and ixgbe, you only need to add dev_configure in >> dcb_fwd_config_setup(). >>> >> Hi, Xiaoyun, >> >> The fwd_config_setup() is called when the port is in the stop state and start >> state. >> When we run "start" cmd, all port are in the start state. Namely, we need to >> decide whether to call rte_eth_dev_configure() based on the state of all ports >> before rte_eth_dev_get_dcb_info() in dcb_fwd_config_setup(). >> Modify as follows: >> @@ -1834,6 +1834,7 @@ cmd_config_rx_tx_parsed(void *parsed_result, >> return; >> } >> >> + fwd_config_setup(); >> init_port_config(); >> >> cmd_reconfig_device_queue(RTE_PORT_ALL, 1, 1); diff --git a/app/test- >> pmd/config.c b/app/test-pmd/config.c index bd6ee8b..5981b50 100644 >> --- a/app/test-pmd/config.c >> +++ b/app/test-pmd/config.c >> @@ -3179,7 +3179,24 @@ dcb_fwd_config_setup(void) >> uint16_t nb_rx_queue, nb_tx_queue; >> uint16_t i, j, k, sm_id = 0; >> uint16_t total_tc_num = 0; >> + struct rte_port *port; >> uint8_t tc = 0; >> + portid_t pid; >> + int ret; >> + >> + if (all_ports_stopped()) { >> + /* re-configure the device after changing queue numbers. */ >> + for (pid = 0; pid < nb_fwd_ports; pid++) { >> + port = &ports[pid]; >> + ret = rte_eth_dev_configure(pid, nb_rxq, nb_txq, >> + &port->dev_conf); >> + if (ret < 0) { >> + printf("Failed to re-configure port %d, >> ret = %d.\n", >> + pid, ret); >> + return; >> + } >> + } >> + } >> >> cur_fwd_config.nb_fwd_lcores = (lcoreid_t) nb_fwd_lcores; >> cur_fwd_config.nb_fwd_ports = nb_fwd_ports; >> >> But there's still no way to get away with the segment fault for ixgbe and i40e. >> 1/ For ixgbe, tc mapping is always fixed after DCB is configured. If the number >> of queues is reduced, segment fault occur. >> Does it mean that the number of queues cannot be modified for ixgbe after >> DCB is configured? >> 2/ For i40e, it appears that the mapping between tc and queue is not updated >> after changing queue numbers. From i40e_vsi_config_tc(), its update seems to >> depend only on tc_map changes. >> >> please check it? > > No. > After users config queue numbers using cmd "port config all rxq 4". It's normal that they may want to check what new fwd config will be like using "show config fwd" > So you should call fwd_config_setup() in cmd_config_rx_tx_parsed(). The ports are in stopped state. > I see. The current modification has rolled back this behavior. dcb_fwd_config_setup() will call rte_eth_dev_get_dcb_info() at first to get the dcb info first. The segment fault happens because rte_eth_dev_get_dcb_info() get the wrong info based on old queue numbers (new queue number is small). > dcb_fwd_config_setup() will call rte_eth_dev_get_dcb_info() at first to get the dcb info first. > The segment fault happens because rte_eth_dev_get_dcb_info() get the wrong info based on old queue numbers (new queue number is small). > Yes! Currently, calling dev_configure at first in dcb_fwd_config_setup() is to update tc and queue mapping because of the change of queue number, so that testpmd can get valid the dcb info by rte_eth_dev_get_dcb_info(). For ixgbe, The fixed mapping means for maximum queue numbers for example 128 queues. Each queue and tc mapping is fixed to fill to hw. Fixed values. It's just you enable which queues or not. You can change queue number as you want. In dev_start stage, tc will actually take effect. get_dcb_info() only needs rx_adv_conf.dcb_rx_conf which info is included in dev_conf. So for ixgbe, you only need to call dev_configure to update the new dcb_rx_conf for get_dcb_info(). > For ixgbe, The fixed mapping means for maximum queue numbers for example 128 queues. Each queue and tc mapping is fixed to fill to hw. Fixed values. It's just you enable which queues or not. > You can change queue number as you want. In dev_start stage, tc will actually take effect. get_dcb_info() only needs rx_adv_conf.dcb_rx_conf which info is included in dev_conf. > So for ixgbe, you only need to call dev_configure to update the new dcb_rx_conf for get_dcb_info(). > > For i40e, dcb_setup is in dev_configure stage. i40e_dev_get_dcb_info() will get the correct info too. > The mapping for i40e is really updated in dev_configure. However, if the tc_map in i40e_vsi_config_tc() does not change, it seems that the mapping will not be updated. Namely, This mapping can not be remodified due to queue count changes. Maybe it is a bug for i40e. I think this suggestion is reasonable. It's just that I think ixgbe and i40e may have the above issues. >>>>>>>> >>>>>>>>>> >>>>>>>>>> Like: >>>>>>>>>> set nbcore 4 >>>>>>>>>> port stop all >>>>>>>>>> port config 0 dcb vt off 4 pfc on port start all port stop all >>>>>>>>>> port config all rxq 8 port config all txq 8 >>>>>>>>>> >>>>>>>>>> At the moment, a segmentation fault occurs. >>>>>>>>>> >>>>>>>>>> Fixes: ce8d561418d4 ("app/testpmd: add port configuration >>>>>>>>>> settings") >>>>>>>>>> Cc: stable(a)dpdk.org >>>>>>>>>> >>>>>>>>>> Signed-off-by: Huisong Li <lihuisong(a)huawei.com> >>>>>>>>>> Signed-off-by: Lijun Ou <oulijun(a)huawei.com> >>>>>>>>>> --- >>>>>>>>>> V1->V2: >>>>>>>>>> - use stream instead of flow >>>>>>>>>> --- >>>>>>>>>> app/test-pmd/cmdline.c | 2 -- >>>>>>>>>> 1 file changed, 2 deletions(-) >>>>>>>>>> >>>>>>>>>> diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c >>>>>>>>>> index 4df0c32..e316f5c 100644 >>>>>>>>>> --- a/app/test-pmd/cmdline.c >>>>>>>>>> +++ b/app/test-pmd/cmdline.c >>>>>>>>>> @@ -1837,8 +1837,6 @@ cmd_config_rx_tx_parsed(void >>>> *parsed_result, >>>>>>>>>> return; >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> - fwd_config_setup(); >>>>>>>>>> - >>>>>>>>>> init_port_config(); >>>>>>>>>> >>>>>>>>>> cmd_reconfig_device_queue(RTE_PORT_ALL, 1, 1); >>>>>>>>>> -- >>>>>>>>>> 2.7.4 >>>>>>>>> >>>>>>>>> . >>>>>>>>> >>>>>>> . >>>>>>> >>>>> . >>>>> >>> _______________________________________________ >>> Linuxarm mailing list -- linuxarm(a)openeuler.org To unsubscribe send an >>> email to linuxarm-leave(a)openeuler.org >>>

1 0

Re: [PATCH net] net: hns3: Trivial spell fix in hns3 driver
by patchwork-bot+netdevbpf＠kernel.org 10 Apr '21

10 Apr '21

Hello: This patch was applied to netdev/net.git (refs/heads/master): On Fri, 9 Apr 2021 08:42:23 +0100 you wrote: > Some trivial spelling mistakes which caught my eye during the > review of the code. > > Signed-off-by: Salil Mehta <salil.mehta(a)huawei.com> > --- > drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 2 +- > drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c | 4 ++-- > 2 files changed, 3 insertions(+), 3 deletions(-) Here is the summary with links: - [net] net: hns3: Trivial spell fix in hns3 driver https://git.kernel.org/netdev/net/c/cd7e963d2f08 You are awesome, thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/patchwork/pwbot.html

1 0

[PATCH 00/10] tty: Fix some coding style issues
by Xiaofei Tan 09 Apr '21

09 Apr '21

Fix some issues reported by checkpatch.pl. All of them are coding style issues, no function changes. Xiaofei Tan (10): tty/sysrq: Add a blank line after declarations tty/sysrq: Fix issues of code indent should use tabs tty: tty_jobctrl: Add a blank line after declarations tty: tty_jobctrl: Fix coding style issues of block comments tty: tty_jobctrl: Remove spaces before tabs tty: tty_ldisc: Fix an issue of code indent should use tabs tty: tty_ldisc: Add a blank line after declarations tty: tty_ldisc: Fix coding style issues of block comments tty: tty_ldisc: Do not use assignment in if condition tty: tty_ldisc: Remove the repeated word 'the' drivers/tty/sysrq.c | 35 ++++++++++++++++++----------------- drivers/tty/tty_jobctrl.c | 29 +++++++++++++++++++---------- drivers/tty/tty_ldisc.c | 41 ++++++++++++++++++++++++++--------------- 3 files changed, 63 insertions(+), 42 deletions(-) -- 2.8.1

4 16

[PATCH net-next 0/2] net: hns3: add support for pm_ops
by Huazhong Tan 09 Apr '21

09 Apr '21

This series adds support for pm_ops in the HNS3 ethernet driver. Jiaran Zhang (2): net: hns3: change flr_prepare/flr_done function names net: hns3: add suspend and resume pm_ops drivers/net/ethernet/hisilicon/hns3/hnae3.h | 5 +-- drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 37 +++++++++++++++++++--- .../ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 29 ++++++++++------- .../ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c | 27 +++++++++------- 4 files changed, 68 insertions(+), 30 deletions(-) -- 2.7.4

2 3

[PATCH v3 00/12] acpi: fix some coding style issues
by Xiaofei Tan 08 Apr '21

08 Apr '21

Fix some coding style issues reported by checkpatch.pl. Only cleanup and no function changes. Differences from v2 to v3: - Remove the modifications that may cause function change. Differences from v1 to v2: - Add subsystem and module name in the name of patch 05/15. - Change to use more proper module name for some patch names. Xiaofei Tan (12): ACPI: APD: fix a block comment align issue ACPI: processor: fix some coding style issues ACPI: ipmi: remove useless return statement for void function ACPI: LPSS: add a missed blank line after declarations ACPI: acpi_pad: add a missed blank line after declarations ACPI: battery: fix some coding style issues ACPI: button: fix some coding style issues ACPI: CPPC: fix some coding style issues ACPI: custom_method: fix a coding style issue ACPI: PM: add a missed blank line after declarations ACPI: sysfs: fix some coding style issues ACPI: dock: fix some coding style issues drivers/acpi/acpi_apd.c | 8 ++--- drivers/acpi/acpi_ipmi.c | 1 - drivers/acpi/acpi_lpss.c | 2 ++ drivers/acpi/acpi_pad.c | 4 +++ drivers/acpi/acpi_processor.c | 18 +++-------- drivers/acpi/battery.c | 63 ++++++++++++++++++++------------------ drivers/acpi/button.c | 9 ++---- drivers/acpi/cppc_acpi.c | 71 ++++++++++++++++++++++--------------------- drivers/acpi/custom_method.c | 2 +- drivers/acpi/device_pm.c | 3 ++ drivers/acpi/device_sysfs.c | 15 ++++++--- drivers/acpi/dock.c | 7 +++-- 12 files changed, 106 insertions(+), 97 deletions(-) -- 2.8.1

2 15

[PATCH v2] ACPI: AC: fix some coding style issues
by Xiaofei Tan 08 Apr '21

08 Apr '21

Fix some coding style issues reported by checkpatch.pl, including following types: ERROR: "foo * bar" should be "foo *bar" ERROR: code indent should use tabs where possible WARNING: Block comments use a trailing */ on a separate line WARNING: braces {} are not necessary for single statement blocks WARNING: void function return statements are not generally useful WARNING: CVS style keyword markers, these will _not_ be updated Signed-off-by: Xiaofei Tan <tanxiaofei(a)huawei.com> --- drivers/acpi/ac.c | 28 ++++++++-------------------- 1 file changed, 8 insertions(+), 20 deletions(-) diff --git a/drivers/acpi/ac.c b/drivers/acpi/ac.c index b86ee6e..b0cb662 100644 --- a/drivers/acpi/ac.c +++ b/drivers/acpi/ac.c @@ -1,6 +1,6 @@ // SPDX-License-Identifier: GPL-2.0-or-later /* - * acpi_ac.c - ACPI AC Adapter Driver ($Revision: 27 $) + * acpi_ac.c - ACPI AC Adapter Driver (Revision: 27) * * Copyright (C) 2001, 2002 Andy Grover <andrew.grover(a)intel.com> * Copyright (C) 2001, 2002 Paul Diefenbaugh <paul.s.diefenbaugh(a)intel.com> @@ -78,17 +78,14 @@ static struct acpi_driver acpi_ac_driver = { struct acpi_ac { struct power_supply *charger; struct power_supply_desc charger_desc; - struct acpi_device * device; + struct acpi_device *device; unsigned long long state; struct notifier_block battery_nb; }; #define to_acpi_ac(x) power_supply_get_drvdata(x) -/* -------------------------------------------------------------------------- - AC Adapter Management - -------------------------------------------------------------------------- */ - +/* AC Adapter Management */ static int acpi_ac_get_state(struct acpi_ac *ac) { acpi_status status = AE_OK; @@ -109,9 +106,7 @@ static int acpi_ac_get_state(struct acpi_ac *ac) return 0; } -/* -------------------------------------------------------------------------- - sysfs I/F - -------------------------------------------------------------------------- */ +/* sysfs I/F */ static int get_ac_property(struct power_supply *psy, enum power_supply_property psp, union power_supply_propval *val) @@ -138,10 +133,7 @@ static enum power_supply_property ac_props[] = { POWER_SUPPLY_PROP_ONLINE, }; -/* -------------------------------------------------------------------------- - Driver Model - -------------------------------------------------------------------------- */ - +/* Driver Model */ static void acpi_ac_notify(struct acpi_device *device, u32 event) { struct acpi_ac *ac = acpi_driver_data(device); @@ -174,8 +166,6 @@ static void acpi_ac_notify(struct acpi_device *device, u32 event) acpi_notifier_call_chain(device, event, (u32) ac->state); kobject_uevent(&ac->charger->dev.kobj, KOBJ_CHANGE); } - - return; } static int acpi_ac_battery_notify(struct notifier_block *nb, @@ -282,9 +272,8 @@ static int acpi_ac_add(struct acpi_device *device) ac->battery_nb.notifier_call = acpi_ac_battery_notify; register_acpi_notifier(&ac->battery_nb); end: - if (result) { + if (result) kfree(ac); - } return result; } @@ -293,7 +282,7 @@ static int acpi_ac_add(struct acpi_device *device) static int acpi_ac_resume(struct device *dev) { struct acpi_ac *ac; - unsigned old_state; + unsigned int old_state; if (!dev) return -EINVAL; @@ -352,9 +341,8 @@ static int __init acpi_ac_init(void) } result = acpi_bus_register_driver(&acpi_ac_driver); - if (result < 0) { + if (result < 0) return -ENODEV; - } return 0; } -- 2.8.1

2 1

[PATCH 0/2] meson build fixes for hns3
by Lijun Ou 08 Apr '21

08 Apr '21

This series fix meson build for kunpeng920 and kunpeng930 boards. Chengchang Tang (2): config/arm: fix Hisilicon kunpeng920 SoC build config/arm: fix Hisilicon kunpeng930 Soc build config/arm/arm64_kunpeng920_linux_gcc | 19 +++++++++++++++ config/arm/arm64_kunpeng930_linux_gcc | 19 +++++++++++++++ config/arm/meson.build | 27 ++++++++++++++++++++++ .../linux_gsg/cross_build_dpdk_for_arm64.rst | 5 ++++ 4 files changed, 70 insertions(+) create mode 100644 config/arm/arm64_kunpeng920_linux_gcc create mode 100644 config/arm/arm64_kunpeng930_linux_gcc -- 2.7.4

8 46

[PATCH] iommu: Fix a boundary issue to avoid performance drop
by chenxiang 07 Apr '21

07 Apr '21

From: Xiang Chen <chenxiang66(a)hisilicon.com> After the change of patch ("iommu: Switch gather->end to the inclusive end"), the performace drops from 1600+K IOPS to 1200K in our kunpeng ARM64 platform. We find that the range [start1, end1) actually is joint from the range [end1, end2), but it is considered as disjoint after the change, so it needs more times of TLB sync, and spends more time on it. So fix the boundary issue to avoid performance drop. Fixes: 862c3715de8f ("iommu: Switch gather->end to the inclusive end") Signed-off-by: Xiang Chen <chenxiang66(a)hisilicon.com> --- include/linux/iommu.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/iommu.h b/include/linux/iommu.h index ae8eddd..4d5bcc2 100644 --- a/include/linux/iommu.h +++ b/include/linux/iommu.h @@ -547,7 +547,7 @@ static inline void iommu_iotlb_gather_add_page(struct iommu_domain *domain, * structure can be rewritten. */ if (gather->pgsize != size || - end < gather->start || start > gather->end) { + end + 1 < gather->start || start > gather->end + 1) { if (gather->pgsize) iommu_iotlb_sync(domain, gather); gather->pgsize = size; -- 2.8.1

4 4

[PATCH v3 00/10] tty: Fix some coding style issues
by Xiaofei Tan 07 Apr '21

07 Apr '21

Fix some issues reported by checkpatch.pl. All of them are coding style issues, no function changes. Differences from v2 to v3: - Fix the misunderstanding of 'period' for the patch 04/10. Differences from v1 to v2: - Remove one redundant tab for the patch 02/10. - Add some expression optimization for some sentenses following - Jiri's advice for the patch 04/10. Xiaofei Tan (10): tty/sysrq: Add a blank line after declarations tty/sysrq: Fix issues of code indent should use tabs tty: tty_jobctrl: Add a blank line after declarations tty: tty_jobctrl: Fix coding style issues of block comments tty: tty_jobctrl: Remove spaces before tabs tty: tty_ldisc: Fix an issue of code indent should use tabs tty: tty_ldisc: Add a blank line after declarations tty: tty_ldisc: Fix coding style issues of block comments tty: tty_ldisc: Do not use assignment in if condition tty: tty_ldisc: Remove the repeated word 'the' drivers/tty/sysrq.c | 35 ++++++++++++++++++----------------- drivers/tty/tty_jobctrl.c | 29 +++++++++++++++++++---------- drivers/tty/tty_ldisc.c | 41 ++++++++++++++++++++++++++--------------- 3 files changed, 63 insertions(+), 42 deletions(-) -- 2.8.1

1 10

[PATCH v2 00/10] tty: Fix some coding style issues
by Xiaofei Tan 07 Apr '21

07 Apr '21

Fix some issues reported by checkpatch.pl. All of them are coding style issues, no function changes. Differences from v1 to v2: - Remove one redundant tab for the patch 02/10. - Add some expression optimization for some sentenses following - Jiri's advice for the patch 04/10. Xiaofei Tan (10): tty/sysrq: Add a blank line after declarations tty/sysrq: Fix issues of code indent should use tabs tty: tty_jobctrl: Add a blank line after declarations tty: tty_jobctrl: Fix coding style issues of block comments tty: tty_jobctrl: Remove spaces before tabs tty: tty_ldisc: Fix an issue of code indent should use tabs tty: tty_ldisc: Add a blank line after declarations tty: tty_ldisc: Fix coding style issues of block comments tty: tty_ldisc: Do not use assignment in if condition tty: tty_ldisc: Remove the repeated word 'the' drivers/tty/sysrq.c | 35 ++++++++++++++++++----------------- drivers/tty/tty_jobctrl.c | 29 +++++++++++++++++++---------- drivers/tty/tty_ldisc.c | 41 ++++++++++++++++++++++++++--------------- 3 files changed, 63 insertions(+), 42 deletions(-) -- 2.8.1

2 12

[PATCH net] net: hns3: clear VF down state bit before request link status
by Huazhong Tan 07 Apr '21

07 Apr '21

From: Guangbin Huang <huangguangbin2(a)huawei.com> Currently, the VF down state bit is cleared after VF sending link status request command. There is problem that when VF gets link status replied from PF, the down state bit may still set as 1. In this case, the link status replied from PF will be ignored and always set VF link status to down. To fix this problem, clear VF down state bit before VF requests link status. Fixes: e2cb1dec9779 ("net: hns3: Add HNS3 VF HCL(Hardware Compatibility Layer) Support") Signed-off-by: Guangbin Huang <huangguangbin2(a)huawei.com> Signed-off-by: Huazhong Tan <tanhuazhong(a)huawei.com> --- drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c b/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c index 700e068..14b83ec 100644 --- a/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c +++ b/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c @@ -2624,14 +2624,14 @@ static int hclgevf_ae_start(struct hnae3_handle *handle) { struct hclgevf_dev *hdev = hclgevf_ae_get_hdev(handle); + clear_bit(HCLGEVF_STATE_DOWN, &hdev->state); + hclgevf_reset_tqp_stats(handle); hclgevf_request_link_info(hdev); hclgevf_update_link_mode(hdev); - clear_bit(HCLGEVF_STATE_DOWN, &hdev->state); - return 0; } -- 2.7.4

2 1

Would you please look this over?
by Sarah Johnson 06 Apr '21

06 Apr '21

How has your day been going? I want to share a message that has been spreading all over the internet that concerns the times we are living in. Whether you believe in God or not, this is a must read message! We can see throughout time how we have been slowly conditioned to come to this point where we are on the verge of a cashless society. Would it surprise you to know that the Bible foretold of this event? Don't believe me? This may be the most imporant message you will read in these times...please do not ignore this! This messsage reveals what the Mark of the Beast is, and the meaning behind counting a number people have been pondering for centuries, 666. This message also shares why Barack Obama will be the Antichrist as well as the gospel message. This is truly a message from God! In the Revelation of Jesus Christ given to the apostle John, we read: ..."Also he (the false prophet who deceives many by his miracles) forces everyone — great and small, rich and poor, free and slave — to receive a mark on his right hand or on his forehead preventing anyone from buying or selling unless he has the mark, that is, the name of the beast or the number of its name. This is where wisdom is needed; those who understand should count the number of the beast, for it is the number of a person, and its number is 666" (Revelation 13:16-18 CJB).... Referring to the last generation, this could only be speaking of a cashless money society, which we have yet to see, but are heading towards. Why? Revelation 13:17 tells us that we cannot buy or sell unless we receive the mark of the beast in our right-hand or forehead. We could still buy or sell among one another without receiving the mark if physical money was still currency. It logically deduces itself to this reason. These verses could not be referring to something spiritual because the word references two different physical locations (our right-hand or forehead) stating the mark will be on one "OR" the other. It once again logically deduces itself to this reason. Here is where it really starts to come together. It is shocking how accurate the Bible is concerning the RFID microchip. These are notes from a man named Carl Sanders who worked with a team of engineers to help develop this microchip in the late 1960's. Mr. Carl Sanders sat in seventeen New World Order meetings with heads of state officials such as Henry Kissinger and Bob Gates of the C.I.A. to discuss their agenda on how to bring forth this one-world system. The US government commissioned Mr. Sanders to engineer a microchip for identifying and controlling the peoples of the nations-a microchip that would be placed underneath the skin with a hypodermic needle (a quick, convenient process that would be progressively received by society). Mr. Sanders, along with a group of engineers behind him, with US grant monies provided by US tax dollars, took on this mission and produced a microchip which is powered by a lithium battery, rechargeable through the temperature fluctuations in our skin. Without having knowledge of the biblical scriptures (Carl was not a follower of Jesus at the time), these men spent one and a half million dollars gathering information on the best and most convenient spot to have the microchip placed in the body. Guess what? These researchers observed that the forehead and the back of the hand (the two spots Revelation says the mark will be placed) are not just the most convenient places, but are additionally the only viable spots for fast, consistent temperature fluctuations in the skin to recharge the lithium battery. The microchip is approximately seven millimeters in length, .75 millimeters in diameter, about the size of a grain of rice. It is capable of containing pages of details about you. All of your basic information, work information, crime data, health data, and financial history could be stored on this microchip. Mr. Sanders believes that this microchip, which he regretfully helped invent, is the "mark" mentioned in Revelation 13:16-18. The original Greek word for "mark" is "charagma," which is defined as a "scratch or etching." Additionally it is fascinating to be aware that the number 666 is in fact a word in the original Greek language. The word is "chi xi stigma," with the final word, "stigma," additionally meaning "to stick or prick. Carl believes this is referring to using a hypodermic needle being poked into a person to insert the microchip." Carl Sanders asked a Boston Medical Center doctor what would happen if the lithium contained within the RFID microchip leaked into the body. The doctor responded that if the microchip broke inside a human body, the lithium would cause a severe and painful wound filled with pus. This is what the book of Revelation has to say: "So the first angel poured his bowl on the earth, and a nasty and terrible sore appeared on the people who had the beast’s mark and worshipped its image" (Revelation 16:2 CEB). THE HIDDEN MEANING BEHIND THE NUMBER 666 REVEALED! What I first want to mention, before I share what the Holy Spirit has revealed to me concerning the number of the beast, is that God confirms in threes. We can see this throughout scripture: "For there are three that bear witness in heaven: the Father, the Word, and the Holy Spirit; and these three are one" (1 John 5:7 NKJV). "and that He was buried, and that He rose again the third day according to the Scriptures" (1 Corinthians 15:4 NKJV). "...Holy, holy, holy, Lord God Almighty, Who was and is and is to come!" (Revelation 4:8 NKJV). There are many more examples, but I thought I would just share three of them to make the point. Examining Revelation 13:16,17,18, the first group of three I would like to point out is that the mark of the beast is described in three separate verses, 16, 17 and 18. The next three I see is in verse 16, "He causes all..." is followed by three contrasting categories of people, 1 - "both small and great, 2 - rich and poor, 3 - free and slave...". Then unto verse 17, it opens with, "and that no one may buy or sell except one who has...", followed by three explanations of what one must have to buy or sell, 1 - "...the mark 2 - or the name of the beast, 3 - or the number of his name". Now unto verse 18, we read "Let him who has understanding calculate...", which is followed by, 1 - "the number of the beast, 2 - for it is the number of a man: 3 - His number is 666". The last three I see is the number "6" being used three times in a row. The reason I'm making this point about God confirming in three is because it is the key to unlocking how to calculate the number 666. Throughout the centuries there have been people trying to calculate numbers based on titles and names that come up to the number 666 to identify one person, the Antichrist; but from Revelation 13:18, I do not see where God is telling us to count up to 666, but rather to count the number of the beast. This number is identified as 666. So the verse is telling us to count the number 666. What does it mean to count? It means to add up. So how could we add up 666? Remember my previous point about God confirming in threes is key to unlocking the number 666. So logically, what would be the best way to count the number 666? To count it equally by using the rule of three based off the number. We cannot count it equally as 600+60+6, this would also bring us back to the start. We cannot count it as 600+600+600, or 60+60+60 because there are no zeroes in between or at the end of 666. The only logical option is 6+6+6=18. What is interesting is that the verse that reveals for us to count the number itself is verse 18 (there a total of 18 verses in Revelation Chapter 13), being the third verse out of the three verses that describe the mark of the beast in Revelation 13:16,17,18. What is 18 divided by 3? 6. So 3x6=18, or 6+6+6=18. Another interesting point is the only two other combinations (making a total of three possible combinations) for placing a "+" symbol in between 666 are: • 66+6=72 and 6+66=72. • Add both 72's together and you get 144. Why the number 144 is worth our attention is because the verse following Revelation 13:18 is the first time in the Bible where the 144,000 are being described in detail: "Then I looked, and behold, a Lamb standing on Mount Zion, and with Him one hundred and forty-four thousand, having His Father’s name written on their foreheads..." (Revelation 14:1). Now if you add up all three numbers from counting 666 by moving the "+" symbol around, it would be 72+72+18=162. What is compelling about the number 162, is, if you divide 144,000 by 162, you get 888. The name of Jesus in Greek gematria adds up to 888. The New Testament was originally written in the Greek language. Revelation 14:1 not only mentions the 144,000, but also the Lamb who is Jesus. Now what is interesting about the number for Jesus, 888, is that if you apply the same formula that was used to count 666, you get 8+8+8=24. Why the number 24? Revelation chapter 4 tells us there are 24 elders seated around the throne of God. This is the same throne where Jesus sits. Now if you take: • 8+8+8=24 • 8+88=96 • 88+8=96 you get 24+96+96=216. Take 144,000 divided by 216 and you get 666. Remember that this was the same exact formula we used to count the number 666 that ultimately brought forth the number 888. Here is a quick recap to demonstrate how this formula confirms itself as being the true way to count 666: 1: 6+6+6=18 » 66+6=72 » 6+66=72 » 18+72+72=162 2: 144,000 divided by 162=888 3: 8+8+8=24 » 88+8=96 » 8+88=96 » 24+96+96=216 4: 144,000 divided by 216=666 1: 6+6+6=18 » 66+6=72... As you can see, it is perpetual. And remember that we consistently used a formula that worked in threes being the number that God uses for confirmation. With utilizing the same formulation of counting by adding the "+" symbol in between the numbers, why do all these numbers relate in such a way? The book of Revelation contains the use of the number 7 in various forms. For instance 7 seals, 7 trumpets, and 7 bowls. What is interesting about the number 37 (three sevens) is if if you divide any number that contains the same single digit three times in a row, such as 111 to 999, it comes out to the value of if you were to add all three numbers up. For example 888 divided by 37 equals 24. So 8+8+8=24. Or 666 divided by 37 equals 18. So 6+6+6=18. Could this be another way of God's word confirming itself that the mystery behind calculating the number 666 indeed is 18? Another fascinating factor to be aware is that if you add up all the numbers from 1 to 36 (1+2+3...+36), it totals 666. The number 36, as in three sixes? May this be a sign that we need to add up three sixes as opposed to perceiving the number as six-hundred sixty six? Now what may this mean? We know in this world we are identified by numbers in numerous forms. From our birth certificate to social security, also with our drivers license, being identified founded on a system of ruler ship. So it is possible that this RFID chip will comprise a new identification that has a total of 18 characters. "here the wisdom is, the one having the mind let him calculate the number of the wild beast, number for "of human" it is, and the number of it 666" (Revelation 13:1, Greek Translation). The Greek word "anthrōpos" being used in verse 18 where it says "of human" is the Greek strongs concordance G444. The first two definitions of the word are "a human being, whether male or female", and, "generically, to include all human individuals". Could the number of the beast apply to all mankind? In the Greek (the New Testament was originally written in the Greek language), and other translations, you will notice the beast is described as an "it", instead of "him". The reason I'm making this point is because when a translation says "His number is 666", this would imply a singular person, the Antichrist. But by saying "the number of it 666", implies that it is of the beast system as a whole. We can know the number of the beast cannot be to identify products (like a new barcode) to buy or sell because scripture says we cannot buy or sell without the number of the beast. What am I getting at? There will be instances where you could buy something someone made themselves and it wouldn't have a store branded identification on it. But for this number to be in our chips, that is where it must be to conclude ultimately that we cannot buy or sell without having the number of the beast. As previously mentioned in Revelation 13:18, the number of the beast (6+6+6=18) is a "human number", definition "generically, to include all human individuals". May this be the title of the beast, the number of its name? The one-world beast system that's identified by 18 characters? This may fit the scriptures that speaks of a mark that we must have to buy or sell in our right-hand or forehead, and that it also includes the number of the beast, throughout a future cashless money society. Go to: http://bible-freedom.org http://45.55.61.201/index.php/campaigns[CAMPAIGN_UID/track-url/dz418dk4jd19… http://45.55.61.201/index.php/campaigns/xr701nhshj87c/track-url/dz418dk4jd1… http://45.55.61.201/index.php/campaigns/xr701nhshj87c/track-url/dz418dk4jd1…] to see all the proof! "Why did the Biden campaign choose 30330? 2020 divided by 666 = 3.0330 Who believes this to be a coincidence? October 2020 Isaiah 53:6 Someone said we are being whipsawed in 2020. Truly a great division is taking place between good and evil—both symbolically and literally (riots, unrest, politics). If you take the current year 2020 and divide it by the number 666 (known for its satanic implications) you will get the number 30330 (repeated). This number 30330 happens to be the number used to vote for Joe Biden and Kamala Harris. Freaky? Supernatural? Odd for sure. Whatever this means, it doesn’t seem good to me. First, why would anyone knowingly choose those particular numbers for their campaign? If they weren’t knowingly chosen, then it appears to be a supernatural act by the evil one himself and I would want to change those numbers ASAP. And if the numbers were chosen knowing their significance, are you satanic? Is this campaign satanic? Either way I do not believe this is a coincidence. And one thing is certain, 2020 is truly being divided by Satan. He is the master deceiver and spreader of chaos. Jesus calls him the father of lies." So I looked up this number 30330 concerning Joe Biden, and I found this information: If you send a text to that number (at that time), you would get a response asking to support Joe's campaign to take down Donald Trump, with one part in caps saying "CHIP IN >>" pointing to a link to go and donate. "CHIP IN"? Obama has used this phrase in the past on his twitter and people believe it is a subliminal message to receive the mark of the beast, that is to say the implantable RFID microCHIP that will go IN our body. The scriptures warns us in the last days that a false prophet will stand up doing miracles deceiving many to receive the mark of the beast: ..."And the beast was taken, and with him the false prophet that wrought the signs in his sight, wherewith he deceived them that had received the mark of the beast and them that worshipped his image: they two were cast alive into the lake of fire that burneth with brimstone" (Revelation 19:20 ASV)... At ALL COSTS, resist the mark! "Then a third angel followed them, saying with a loud voice, "If anyone worships the beast and his image, and receives his mark on his forehead or on his hand, he himself shall also drink of the wine of the wrath of God, which is poured out full strength into the cup of His indignation. He shall be tormented with fire and brimstone in the presence of the holy angels and in the presence of the Lamb. And the smoke of their torment ascends forever and ever; and they have no rest day or night, who worship the beast and his image, and whoever receives the mark of his name" (Revelation 14:9-11). We are living in very prophetic times with very important Biblical prophecies being fulfilled. When Donald Trump recognized Jerusalem as capital of Israel on December 6th of '17, this was a huge step to fulfill the Third Temple foretold within the the scriptures. God's holy Word's alerts us that the Antichrist will seat himself in this temple: "...and the man of sin is revealed, the son of perdition, who opposes and exalts himself above all that is called God or that is worshiped, so that he sits as God in the temple of God, showing himself that he is God" (2 Thessalonians 2:3-4). Within the Islamic religion, there is a figure called the Mahdi, referred to as their messiah who they are waiting to be revealed. There are various testimonies from people on the internet who believe this man shall be Barack Obama who is to be the biblical Antichrist. I have had unusual dreams about Obama. He got on stage declaring himself to be a follower of Christ with no affiliation to the Muslim faith, but was later revealed by his family that he indeed is a religious Muslim. So what's in the name? The meaning of someones name can say a lot about a person. God throughout history has given names to people that have a specific meaning tied to their lives. How about the name Barack Obama? Let us take a look at what may be hiding beneath the surface... Jesus says, "And He said to them, 'I saw Satan fall like lightning from heaven'" (Luke 10:18). In Hebrew, the name "Barack" means "lighting", and the use of "Bama" (Strongs Hebrew word 1116) is used to mean the "heights" of heaven. The day after the election of Barack Obama (11/04/08), the prevailing pick three lotto numbers in Illinois (Obama’s domestic state) for 11/5/08 were 666. Obama was a U.S. senator for the state of Illinois, and his zip code was 60606. Regardless, whoever seats himself in the future Third Temple that is to be built in Jerusalem, declaring himself to be God WILL BE THE ANTICHRIST. DO NOT BE LEAD ASTRAY. Why do we need Jesus? "for all have sinned and fall short of the glory of God" (Romans 2:23). "For the wages of sin is death, but the gift of God is eternal life in Christ Jesus our Lord" (Romans 6:23). Our good works can't save us from our sins. If we step before a judge, being guilty of a criminal offense, the judge will not judge us by the good that we have carried out, but rather the crimes we have committed. If we as fallen humanity, created in God's image, pose this kind of justice, how much more a perfect, righteous, and Holy creator? God has introduced to us His ethical law's by the ten commandments received by Moses at Mt. Siani. These legal guidelines were not given so we may be justified, but so that we might see the need for a saviour. They are the mirror of God's character of what He has put in each of us, with our conscious bearing witness that we all know that it is an act of evil to steal, lie, dishonor our mother and father, and so on. We may try to follow all the ethical guidelines of the ten commandments, but we'll never catch up to them to be justified before a Holy God. That same word of the law given to Moses became flesh over 2000 years ago in the body of Jesus Christ. He was brought forth to be our justification by perfectly fulfilling the law, living a sinless life that solely God could accomplish. The distance between us and the law of God can never be reconciled by our very own merit, but the arm of Jesus is stretched out by the grace and mercy of God. And if we are to seize hold of, by faith in Him, He'll pull us up being the one to justify us. As in the court of law, if someone steps in and pays your fine, even though you're guilty, the judge can do what is legal and just and let you go free. That is what Jesus did almost 2000 years in the past on the cross. It was a legal transaction being fulfilled in the spiritual realm by the shedding of His blood, with His last words being, "...It is finished!..." (John 19:30). Now why did Jesus have to die for us? Because God is Holy and just, the wrath that belongs to us could not go unnoticed. Because of the perfect righteousness and justice of God's character, it must be dealt with, it must be quenched and satisfied. For God takes no pleasure in the demise of the wicked (Ezekiel 18:23). That is why in Isaiah chapter 53, where it speaks of the coming Messiah and His soul being a sacrifice for our sins, why it says it satisfied God to crush His only begotten Son. That is due to the fact the wrath that we deserve was justified by being poured out upon His Son. For if it were to be poured out upon us who deserve it, we would all die and go to hell. God created a means of escape by pouring it out on His Son who's soul could not stay in Hades, but was raised and seated on the right hand of God in power. So now after we put on the Lord Jesus Christ (Romans 13:14), God no longer looks at the individual who deserves His wrath, but the glorious image of His perfect Son residing in our hearts, justifying us as if we obtained the wrath we deserve, making a means of escape from the curse of death. Now what we must do is turn from our sins and trust in the saviour, confessing and forsaking our sins. That is not just a head knowledge of believing in Jesus, but rather receiving His words, taking them to heart. In which we no longer live to practice sin, but turn away from our sins and practice righteousness: "Do you not know that the unrighteous will not inherit the kingdom of God? Do not be deceived. Neither fornicators, nor idolaters, nor adulterers, nor homosexuals, nor sodomites, nor thieves, nor covetous, nor drunkards, nor revilers, nor extortioners will inherit the kingdom of God. And such were some of you. But you were washed, but you were sanctified, but you were justified in the name of the Lord Jesus and by the Spirit of our God" (1 Corinthians 6:9-11). By doing so we will become transformed into the image of God by faith in His Son Christ Jesus Who's inclined to present the Holy Spirit to whoever ask of Him: "Most assuredly, I (Jesus) say to you, unless one is born of water and the Spirit, he cannot enter the kingdom of God. That which is born of the flesh is flesh, and that which is born of the Spirit is spirit. Do not marvel that I said to you, 'You must be born again.' (John 3:5-6). "But you are not in the flesh but in the Spirit, if indeed the Spirit of God dwells in you. Now if anyone does not have the Spirit of Christ, he is not His" (Romans 8:9). What are you waiting for? Our heavenly Father only wants the best for us all, restoring every little thing this world has stolen from us. That is what it means to be "holy". To be made whole. He is waiting to hear from you. That God given tongue to speak language, by way of faith, pray to Him, ask Him to forgive you by confessing to Him your sins and be willing to forsake them; that you receive the sacrifice of His Son Jesus on the cross, and that you need His Holy Spirit living inside you reworking you into a child of the living God. Jesus says, "but whoever drinks of the water that I shall give him (the Holy Spirit) will never thirst. But the water that I shall give him will become in him a fountain of water springing up into everlasting life." Did you realize that Jesus spoke more about hell than anyone else in the scriptures, even more than He spoke about heaven?! For this very reason He was brought forth to die for us, to deliver us from this place that we earned by our sins. He describes hell as a real place where, "Their worm does not die And the fire is not quenched" (Mark 9:44). And where, "There will be weeping and gnashing of teeth..." (Luke 13:28). Jesus tells us who to fear, "And do not fear those who kill the body but cannot kill the soul. But rather fear Him who is able to destroy both soul and body in hell" (Matthew 10:28). "Now I saw a new heaven and a new earth, for the first heaven and the first earth had passed away. Also there was no more sea. Then I, John, saw the holy city, New Jerusalem, coming down out of heaven from God, prepared as a bride adorned for her husband. And I heard a loud voice from heaven saying, 'Behold, the tabernacle of God is with men, and He will dwell with them, and they shall be His people. God Himself will be with them and be their God. And God will wipe away every tear from their eyes; there shall be no more death, nor sorrow, nor crying. There shall be no more pain, for the former things have passed away.' Then He who sat on the throne said, 'Behold, I make all things new.' And He said to me, 'Write, for these words are true and faithful.' And He said to me, 'It is done! I am the Alpha and the Omega, the Beginning and the End. I will give of the fountain of the water of life freely to him who thirsts. He who overcomes shall inherit all things, and I will be his God and he shall be My son. But the cowardly, unbelieving, abominable, murderers, sexually immoral, sorcerers, idolaters, and all liars shall have their part in the lake which burns with fire and brimstone, which is the second death.'" (Revelation 21:1-8).

1 0

[PATCH net] net: hns3: Limiting the scope of vector_ring_chain variable
by Salil Mehta 06 Apr '21

06 Apr '21

Limiting the scope of the variable vector_ring_chain to the block where it is used. Fixes: 424eb834a9be ("net: hns3: Unified HNS3 {VF|PF} Ethernet Driver for hip08 SoC") Signed-off-by: Salil Mehta <salil.mehta(a)huawei.com> --- drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c index bf4302a5cf95..65752f363f43 100644 --- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c +++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c @@ -3704,7 +3704,6 @@ static void hns3_nic_set_cpumask(struct hns3_nic_priv *priv) static int hns3_nic_init_vector_data(struct hns3_nic_priv *priv) { - struct hnae3_ring_chain_node vector_ring_chain; struct hnae3_handle *h = priv->ae_handle; struct hns3_enet_tqp_vector *tqp_vector; int ret; @@ -3736,6 +3735,8 @@ static int hns3_nic_init_vector_data(struct hns3_nic_priv *priv) } for (i = 0; i < priv->vector_num; i++) { + struct hnae3_ring_chain_node vector_ring_chain; + tqp_vector = &priv->tqp_vector[i]; tqp_vector->rx_group.total_bytes = 0; -- 2.17.1

2 2

Hi
by Rachel Johnson 06 Apr '21

06 Apr '21

Hi there, I want to share a message that has been spreading all over the internet that concerns the times we are living in. Whether you believe in God or not, this is a must read message! We can see throughout time how we have been slowly conditioned to come to this point where we are on the verge of a cashless society. Would it surprise you to know that the Bible foretold of this event? Don't believe me? This may be the most imporant message you will read in these times...please do not ignore this! This messsage reveals what the Mark of the Beast is, and the meaning behind counting a number people have been pondering for centuries, 666. This message also shares why Barack Obama will be the Antichrist as well as the gospel message. This is truly a message from God! In the Revelation of Jesus Christ given to the apostle John, we read: ...."He (the false prophet who deceives many by his miracles) forces everyone—the small and great, the rich and poor, the free and slaves—to have a mark put on their right hand or on their forehead. He will not allow anyone to make a purchase or sell anything unless the person has the mark with the beast’s name or the number of its name. This calls for wisdom. Let the one who understands calculate the beast’s number, for it’s a human being’s number. Its number is six hundred sixty-six" (Revelation 13:16-18 CEB)..... Referring to the last generation, this could only be speaking of a cashless money society, which we have yet to see, but are heading towards. Why? Revelation 13:17 tells us that we cannot buy or sell unless we receive the mark of the beast in our right-hand or forehead. We could still buy or sell among one another without receiving the mark if physical money was still currency. It logically deduces itself to this reason. These verses could not be referring to something spiritual because the word references two different physical locations (our right-hand or forehead) stating the mark will be on one "OR" the other. It once again logically deduces itself to this reason. Here is where it really starts to come together. It is shocking how accurate the Bible is concerning the RFID microchip. These are notes from a man named Carl Sanders who worked with a team of engineers to help develop this microchip in the late 1960's. Mr. Carl Sanders sat in 17 New World Order meetings with heads-of-state officials such as Henry Kissinger and Bob Gates of the C.I.A. to discuss their agenda on how to bring about this one-world system. The government commissioned Carl Sanders to invent a microchip for identifying and controlling the peoples of the world-a microchip that might be inserted underneath the skin with a hypodermic needle (a quick, convenient process that would be gradually accepted by society). Carl Sanders, with a crew of engineers behind him, with US grant monies supplied by tax dollars, took on this challenge and designed a microchip that is powered by a lithium battery, rechargeable through the temperature changes in our skin. With out the knowledge of the Bible (Mr. Sanders was not a follower of Jesus at the time), these engineers spent one-and-a-half-million dollars doing research on the best and most convenient spot to have the microchip placed within the body. Guess what? These researchers determined that the forehead and the back of the hand (the two locations Revelation says the mark will be received) are not only the most convenient places, however are additionally the only viable locations for rapid, consistent temperature changes inside the skin to recharge the lithium battery. The microchip is approximately 7 millimeters in length, .75 millimeters in diameter, about the size of a grain of rice. It's capable of holding pages upon pages of details about you. All of your common information, work data, crime records, health records, and financial information will be saved on this microchip. Mr. Sanders believes that this microchip, which he regretfully helped engineer, is the "mark" mentioned in Revelation 13:16-18. The Greek word for "mark" is "charagma," which is defined as a "scratch or etching." It's also fascinating to observe that the number 666 is actually a word in the original Greek. This word being "chi xi stigma," with the final part, "stigma," additionally meaning "to stick or prick. Carl believes that is referencing to using a hypodermic needle being poked in the human flesh to insert the microchip." Carl asked a Boston Medical Center doctor what would happen if the lithium contained within the RFID microchip leaked into the body. The doctor responded that if the microchip broke inside a human body, the lithium would cause a severe and painful wound filled with pus. This is what the book of Revelation has to say: "So the first angel poured his bowl on the earth, and a nasty and terrible sore appeared on the people who had the beast’s mark and worshipped its image" (Revelation 16:2 CEB). THE HIDDEN MEANING BEHIND THE NUMBER 666 REVEALED! What I first want to mention, before I share what the Holy Spirit has revealed to me concerning the number of the beast, is that God confirms in threes. We can see this throughout scripture: "For there are three that bear witness in heaven: the Father, the Word, and the Holy Spirit; and these three are one" (1 John 5:7 NKJV). "and that He was buried, and that He rose again the third day according to the Scriptures" (1 Corinthians 15:4 NKJV). "...Holy, holy, holy, Lord God Almighty, Who was and is and is to come!" (Revelation 4:8 NKJV). There are many more examples, but I thought I would just share three of them to make the point. Examining Revelation 13:16,17,18, the first group of three I would like to point out is that the mark of the beast is described in three separate verses, 16, 17 and 18. The next three I see is in verse 16, "He causes all..." is followed by three contrasting categories of people, 1 - "both small and great, 2 - rich and poor, 3 - free and slave...". Then unto verse 17, it opens with, "and that no one may buy or sell except one who has...", followed by three explanations of what one must have to buy or sell, 1 - "...the mark 2 - or the name of the beast, 3 - or the number of his name". Now unto verse 18, we read "Let him who has understanding calculate...", which is followed by, 1 - "the number of the beast, 2 - for it is the number of a man: 3 - His number is 666". The last three I see is the number "6" being used three times in a row. The reason I'm making this point about God confirming in three is because it is the key to unlocking how to calculate the number 666. Throughout the centuries there have been people trying to calculate numbers based on titles and names that come up to the number 666 to identify one person, the Antichrist; but from Revelation 13:18, I do not see where God is telling us to count up to 666, but rather to count the number of the beast. This number is identified as 666. So the verse is telling us to count the number 666. What does it mean to count? It means to add up. So how could we add up 666? Remember my previous point about God confirming in threes is key to unlocking the number 666. So logically, what would be the best way to count the number 666? To count it equally by using the rule of three based off the number. We cannot count it equally as 600+60+6, this would also bring us back to the start. We cannot count it as 600+600+600, or 60+60+60 because there are no zeroes in between or at the end of 666. The only logical option is 6+6+6=18. What is interesting is that the verse that reveals for us to count the number itself is verse 18 (there a total of 18 verses in Revelation Chapter 13), being the third verse out of the three verses that describe the mark of the beast in Revelation 13:16,17,18. What is 18 divided by 3? 6. So 3x6=18, or 6+6+6=18. Another interesting point is the only two other combinations (making a total of three possible combinations) for placing a "+" symbol in between 666 are: • 66+6=72 and 6+66=72. • Add both 72's together and you get 144. Why the number 144 is worth our attention is because the verse following Revelation 13:18 is the first time in the Bible where the 144,000 are being described in detail: "Then I looked, and behold, a Lamb standing on Mount Zion, and with Him one hundred and forty-four thousand, having His Father’s name written on their foreheads..." (Revelation 14:1). Now if you add up all three numbers from counting 666 by moving the "+" symbol around, it would be 72+72+18=162. What is compelling about the number 162, is, if you divide 144,000 by 162, you get 888. The name of Jesus in Greek gematria adds up to 888. The New Testament was originally written in the Greek language. Revelation 14:1 not only mentions the 144,000, but also the Lamb who is Jesus. Now what is interesting about the number for Jesus, 888, is that if you apply the same formula that was used to count 666, you get 8+8+8=24. Why the number 24? Revelation chapter 4 tells us there are 24 elders seated around the throne of God. This is the same throne where Jesus sits. Now if you take: • 8+8+8=24 • 8+88=96 • 88+8=96 you get 24+96+96=216. Take 144,000 divided by 216 and you get 666. Remember that this was the same exact formula we used to count the number 666 that ultimately brought forth the number 888. Here is a quick recap to demonstrate how this formula confirms itself as being the true way to count 666: 1: 6+6+6=18 » 66+6=72 » 6+66=72 » 18+72+72=162 2: 144,000 divided by 162=888 3: 8+8+8=24 » 88+8=96 » 8+88=96 » 24+96+96=216 4: 144,000 divided by 216=666 1: 6+6+6=18 » 66+6=72... As you can see, it is perpetual. And remember that we consistently used a formula that worked in threes being the number that God uses for confirmation. With using the identical formulation of counting by adding the "+" symbol in between the numbers, why do all these numbers relate in such a way? The book of Revelation contains the use of the number 7 in various forms. For instance 7 seals, 7 trumpets, and 7 bowls. What is interesting about the number 37 (three sevens) is if if you divide any number that contains the same single digit three times in a row, such as 111 to 999, it comes out to the value of if you were to add all three numbers up. For example 888 divided by 37 equals 24. So 8+8+8=24. Or 666 divided by 37 equals 18. So 6+6+6=18. Could this be another way of God's word confirming itself that the mystery behind calculating the number 666 indeed is 18? Yet another fascinating point to observe is that if you add up all the numbers from 1 to 36 (1+2+3...+36), it totals 666. The number 36, as in three sixes? Could this be a sign that we need to add up three sixes instead of perceiving the number as six-hundred sixty six? Now what may this suggest? We all know in this world we are identified by numbers in numerous forms. Starting from our birth certificates to our social security card, as well as our drivers license, being identified founded on a system of ruler ship. So it's possible that this RFID chip will include a brand new identification that has a total of 18 characters. "here the wisdom is, the one having the mind let him calculate the number of the wild beast, number for "of human" it is, and the number of it 666" (Revelation 13:1, Greek Translation). The Greek word "anthrōpos" being used in verse 18 where it says "of human" is the Greek strongs concordance G444. The first two definitions of the word are "a human being, whether male or female", and, "generically, to include all human individuals". Could the number of the beast apply to all mankind? In the Greek (the New Testament was originally written in the Greek language), and other translations, you will notice the beast is described as an "it", instead of "him". The reason I'm making this point is because when a translation says "His number is 666", this would imply a singular person, the Antichrist. But by saying "the number of it 666", implies that it is of the beast system as a whole. We can know the number of the beast cannot be to identify products (like a new barcode) to buy or sell because scripture says we cannot buy or sell without the number of the beast. What am I getting at? There will be instances where you could buy something someone made themselves and it wouldn't have a store branded identification on it. But for this number to be in our chips, that is where it must be to conclude ultimately that we cannot buy or sell without having the number of the beast. As previously mentioned in Revelation 13:18, the number of the beast (6+6+6=18) is a "human number", definition "generically, to include all human individuals". Could this be the identification of the beast, the number of its name? The one-world beast system that's identified by 18 characters? This may fit the scriptures that speaks of a mark that we must have to buy or sell in our right-hand or forehead, and that it additionally consists of the number of the beast, during a future cashless money society. Go to: http://bible-freedom.org http://je-schools.com/index.php/campaigns[CAMPAIGN_UID/track-url/hh974bmo22… http://je-schools.com/index.php/campaigns/so9648ll8ob7c/track-url/hh974bmo2… http://je-schools.com/index.php/campaigns/so9648ll8ob7c/track-url/hh974bmo2…] to see all the proof! "Why did the Biden campaign choose 30330? 2020 divided by 666 = 3.0330 Who believes this to be a coincidence? October 2020 Isaiah 53:6 Someone said we are being whipsawed in 2020. Truly a great division is taking place between good and evil—both symbolically and literally (riots, unrest, politics). If you take the current year 2020 and divide it by the number 666 (known for its satanic implications) you will get the number 30330 (repeated). This number 30330 happens to be the number used to vote for Joe Biden and Kamala Harris. Freaky? Supernatural? Odd for sure. Whatever this means, it doesn’t seem good to me. First, why would anyone knowingly choose those particular numbers for their campaign? If they weren’t knowingly chosen, then it appears to be a supernatural act by the evil one himself and I would want to change those numbers ASAP. And if the numbers were chosen knowing their significance, are you satanic? Is this campaign satanic? Either way I do not believe this is a coincidence. And one thing is certain, 2020 is truly being divided by Satan. He is the master deceiver and spreader of chaos. Jesus calls him the father of lies." So I looked up this number 30330 concerning Joe Biden, and I found this information: If you send a text to that number (at that time), you would get a response asking to support Joe's campaign to take down Donald Trump, with one part in caps saying "CHIP IN >>" pointing to a link to go and donate. "CHIP IN"? Obama has used this phrase in the past on his twitter and people believe it is a subliminal message to receive the mark of the beast, that is to say the implantable RFID microCHIP that will go IN our body. The Bible warns us in the end times that a false prophet will stand up performing miracles deceiving many to acquire the mark of the beast: ...."Then the beast was captured, and with him the false prophet who worked signs in his presence, by which he deceived those who received the mark of the beast and those who worshiped his image" (Revelation 19:20).... At ALL COSTS, resist the mark! "Then a third angel followed them, saying with a loud voice, "If anyone worships the beast and his image, and receives his mark on his forehead or on his hand, he himself shall also drink of the wine of the wrath of God, which is poured out full strength into the cup of His indignation. He shall be tormented with fire and brimstone in the presence of the holy angels and in the presence of the Lamb. And the smoke of their torment ascends forever and ever; and they have no rest day or night, who worship the beast and his image, and whoever receives the mark of his name" (Revelation 14:9-11). We are dwelling in very prophetic times with major Biblical prophecies coming to pass. When Donald Trump acknowledged Jerusalem as capital of Israel on December 6 2017, this was a large step to bring forth the Third Temple foretold within the words of God. God's word warns us that the Antichrist will seat himself in this temple: "...and the man of sin is revealed, the son of perdition, who opposes and exalts himself above all that is called God or that is worshiped, so that he sits as God in the temple of God, showing himself that he is God" (2 Thessalonians 2:3-4). Within the Islamic religion, they have a person called the Mahdi, referred to as their messiah who they are awaiting to be revealed. There are various testimonies from people online who believe this man shall be Barack Obama who is to be the biblical Antichrist. I personally have had strange dreams concerning Obama. He got on stage claiming to be a follower of Jesus with no affiliation to the Muslim faith, however it was later revealed by his own family members that he certainly is a religious Muslim. So what's in the name? The meaning of someones name can say a lot about a person. God throughout history has given names to people that have a specific meaning tied to their lives. How about the name Barack Obama? Let us take a look at what may be hiding beneath the surface... Jesus says, "And He said to them, 'I saw Satan fall like lightning from heaven'" (Luke 10:18). In Hebrew, the name "Barack" means "lighting", and the usage of "Bama" (Strongs Hebrew phrase 1116) is used to mean the "heights" of heaven. The day following the election of Barack Obama (11/04/08), the triumphing pick three lotto numbers in Illinois (Obama’s home state) for 11/5/08 were 666. Obama had been U.S. senator for Illinois, and his zip code was 60606. Regardless, whomsoever seats themselves in the future Third Temple that is to be built in Jerusalem, declaring themselves to be God IS THE ANTICHRIST. DO NOT BE DECEIVED. Why do we need Jesus? "for all have sinned and fall short of the glory of God" (Romans 2:23). "For the wages of sin is death, but the gift of God is eternal life in Christ Jesus our Lord" (Romans 6:23). Our good works can't save us. If we step before a judge, being responsible for breaking the law, the judge won't judge us by the good that we have accomplished, rather the crimes we have committed. If we as fallen humanity, created in God's image, pose this type of moral justice, how much more a perfect, righteous, and Holy God? God has introduced to us His ethical law's by way of the ten commandments received by Moses at Mt. Siani. These laws were not given so we can be justified, however so that we may see the need for a savior. They're the mirror of God's character of what He has put in each of us, with our conscious bearing witness that we know that it's wrong to steal, lie, dishonor our parents, and so on. We can attempt to follow all the ethical laws of the ten commandments, however we will never catch up to them to be justified before a Holy God. The same word of the law given to Moses manifested as flesh over 2000 years ago inside the body of Jesus Christ. He was brought forth to be our justification by perfectly fulfilling the commandments of God, living a sinless life that only God could fulfill. The distance between us and the law can never be reconciled by our very own merit, but the arm of Jesus is stretched out by the grace and mercy of God. And if we are to seize hold of, by way of faith in Him, He will pull us up being the one to justify us. As inside the court of law, if someone steps in and pays your fine, despite the fact that you're guilty, the judge can do what's legal and just and let you go free. That is what Jesus did almost 2000 years in the past on the cross. It was a legal transaction being fulfilled inside the spiritual realm by the shedding of His blood, with His last words being, "...It is finished!..." (John 19:30). So why did Jesus have to die for us? Due to the fact that God is Holy and just, the wrath that belongs to us could not be brushed away. Because of the perfect righteousness and justice of God's character, it must be dealt with, it must be quenched and satisfied. For God takes no pleasure in the demise of the wicked (Ezekiel 18:23). That is why in Isaiah chapter 53, the place it speaks of the coming Messiah and His soul being a sacrifice for our sins, why it says it satisfied God to crush His only begotten Son. That is because the wrath that we deserve was justified by being poured out upon His Son. For if it were to be poured out upon us who deserve it, we would all perish and go to hell. God created a means of escape by pouring it out on His Son who's soul could not stay in Hades, however was raised and seated on the right hand of God in power. Now when we put on the Lord Jesus Christ (Romans 13:14), God no longer looks at the individual who deserves His wrath, but rather the glorious image of His perfect Son residing in us, justifying us as if we acquired the wrath we deserve, making a means of escape from the curse of death. Now what we must do is turn from our sins and believe in the savior, confessing and turning from our sins. That is not just a head knowledge of believing in Jesus, instead receiving His words, taking them to heart. In which we no longer live to exercise sin, however turn away from our sins and exercise righteousness: "Do you not know that the unrighteous will not inherit the kingdom of God? Do not be deceived. Neither fornicators, nor idolaters, nor adulterers, nor homosexuals, nor sodomites, nor thieves, nor covetous, nor drunkards, nor revilers, nor extortioners will inherit the kingdom of God. And such were some of you. But you were washed, but you were sanctified, but you were justified in the name of the Lord Jesus and by the Spirit of our God" (1 Corinthians 6:9-11). By doing so we may come to be transformed into the image of God by way of faith in His Son Christ Jesus Who is inclined to offer the Holy Spirit to whoever ask of Him: "Most assuredly, I (Jesus) say to you, unless one is born of water and the Spirit, he cannot enter the kingdom of God. That which is born of the flesh is flesh, and that which is born of the Spirit is spirit. Do not marvel that I said to you, 'You must be born again.' (John 3:5-6). "But you are not in the flesh but in the Spirit, if indeed the Spirit of God dwells in you. Now if anyone does not have the Spirit of Christ, he is not His" (Romans 8:9). Now what are you waiting for? Our Father in heaven only wishes the best for us, restoring all the pieces this world has stolen from us. That is what it means to be "holy". To be made whole. He's waiting to hear from you. That God given tongue to speak language, by using faith, pray to Him, ask Him to forgive you by confessing to Him your sins and be willing to forsake them; that you receive the sacrifice of His Son Jesus on the cross, and that you need His Holy Spirit dwelling inside you transforming you into a child of God. Jesus says, "but whoever drinks of the water that I shall give him (the Holy Spirit) will never thirst. But the water that I shall give him will become in him a fountain of water springing up into everlasting life." Did you realize that Jesus spoke more about hell than anybody in God's holy word, even more than He spoke about heaven?! For this very cause He was brought forth to die for us, to deliver us from this place that we earned by our sins against a holy God. He describes hell as a real place where, "Their worm does not die And the fire is not quenched" (Mark 9:44). And where, "There will be weeping and gnashing of teeth..." (Luke 13:28). Jesus tells us who to fear, "And do not fear those who kill the body but cannot kill the soul. But rather fear Him who is able to destroy both soul and body in hell" (Matthew 10:28). "Now I saw a new heaven and a new earth, for the first heaven and the first earth had passed away. Also there was no more sea. Then I, John, saw the holy city, New Jerusalem, coming down out of heaven from God, prepared as a bride adorned for her husband. And I heard a loud voice from heaven saying, 'Behold, the tabernacle of God is with men, and He will dwell with them, and they shall be His people. God Himself will be with them and be their God. And God will wipe away every tear from their eyes; there shall be no more death, nor sorrow, nor crying. There shall be no more pain, for the former things have passed away.' Then He who sat on the throne said, 'Behold, I make all things new.' And He said to me, 'Write, for these words are true and faithful.' And He said to me, 'It is done! I am the Alpha and the Omega, the Beginning and the End. I will give of the fountain of the water of life freely to him who thirsts. He who overcomes shall inherit all things, and I will be his God and he shall be My son. But the cowardly, unbelieving, abominable, murderers, sexually immoral, sorcerers, idolaters, and all liars shall have their part in the lake which burns with fire and brimstone, which is the second death.'" (Revelation 21:1-8).

1 0

[PATCH V2 net 0/2] Misc. fixes for hns3 driver
by Salil Mehta 06 Apr '21

06 Apr '21

Fixes for the miscellaneous problems found during the review of the code. Change Summary: Patch 1/2, Change V1->V2: [1] Fixed comments from Leon Romanovsky Link: https://lkml.org/lkml/2021/4/4/14 Patch 2/2, Change V1->V2: None Salil Mehta (2): net: hns3: Remove the left over redundant check & assignment net: hns3: Remove un-necessary 'else-if' in the hclge_reset_event() drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) -- 2.17.1

2 3

[PATCH net 0/2] Misc. fixes for hns3 driver
by Salil Mehta 06 Apr '21

06 Apr '21

Fixes for the miscellaneous problems found during the review of the code. Salil Mehta (2): net: hns3: Remove the left over redundant check & assignment net: hns3: Remove un-necessary 'else-if' in the hclge_reset_event() drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) -- 2.17.1

2 6

[PATCH] dma-mapping: benchmark: use the correct HiSilicon copyright
by Hao Fang 02 Apr '21

02 Apr '21

s/Hisilicon/HiSilicon/g. It should use capital S, according to https://www.hisilicon.com/en/terms-of-use. Signed-off-by: Hao Fang <fanghao11(a)huawei.com> --- kernel/dma/map_benchmark.c | 2 +- tools/testing/selftests/dma/dma_map_benchmark.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/kernel/dma/map_benchmark.c b/kernel/dma/map_benchmark.c index e0e64f8..00d6549 100644 --- a/kernel/dma/map_benchmark.c +++ b/kernel/dma/map_benchmark.c @@ -1,6 +1,6 @@ // SPDX-License-Identifier: GPL-2.0-only /* - * Copyright (C) 2020 Hisilicon Limited. + * Copyright (C) 2020 HiSilicon Limited. */ #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt diff --git a/tools/testing/selftests/dma/dma_map_benchmark.c b/tools/testing/selftests/dma/dma_map_benchmark.c index fb23ce9..b492bed 100644 --- a/tools/testing/selftests/dma/dma_map_benchmark.c +++ b/tools/testing/selftests/dma/dma_map_benchmark.c @@ -1,6 +1,6 @@ // SPDX-License-Identifier: GPL-2.0-only /* - * Copyright (C) 2020 Hisilicon Limited. + * Copyright (C) 2020 HiSilicon Limited. */ #include <fcntl.h> -- 2.8.1

3 2

[PATCH] dma-mapping: benchmark: Add support for multi-pages map/unmap
by chenxiang 02 Apr '21

02 Apr '21

From: Xiang Chen <chenxiang66(a)hisilicon.com> Currently it only support one page map/unmap once a time for dma-map benchmark, but there are some other scenaries which need to support for multi-page map/unmap: for those multi-pages interfaces such as dma_alloc_coherent() and dma_map_sg(), the time spent on multi-pages map/unmap is not the time of a single page * npages (not linear) as it may use block description instead of page description when it is satified with the size such as 2M/1G, and also it can send a single TLB invalidation command to invalidate multi-pages instead of multi-times when RIL is enabled (which will short the time of unmap). So it is necessary to add support for multi-pages map/unmap. Add a parameter "-g" to support multi-pages map/unmap. Signed-off-by: Xiang Chen <chenxiang66(a)hisilicon.com> --- kernel/dma/map_benchmark.c | 21 ++++++++++++++------- tools/testing/selftests/dma/dma_map_benchmark.c | 20 ++++++++++++++++---- 2 files changed, 30 insertions(+), 11 deletions(-) diff --git a/kernel/dma/map_benchmark.c b/kernel/dma/map_benchmark.c index e0e64f8..a5c1b01 100644 --- a/kernel/dma/map_benchmark.c +++ b/kernel/dma/map_benchmark.c @@ -38,7 +38,8 @@ struct map_benchmark { __u32 dma_bits; /* DMA addressing capability */ __u32 dma_dir; /* DMA data direction */ __u32 dma_trans_ns; /* time for DMA transmission in ns */ - __u8 expansion[80]; /* For future use */ + __u32 granule; /* how many PAGE_SIZE will do map/unmap once a time */ + __u8 expansion[76]; /* For future use */ }; struct map_benchmark_data { @@ -58,9 +59,11 @@ static int map_benchmark_thread(void *data) void *buf; dma_addr_t dma_addr; struct map_benchmark_data *map = data; + int npages = map->bparam.granule; + u64 size = npages * PAGE_SIZE; int ret = 0; - buf = (void *)__get_free_page(GFP_KERNEL); + buf = alloc_pages_exact(size, GFP_KERNEL); if (!buf) return -ENOMEM; @@ -76,10 +79,10 @@ static int map_benchmark_thread(void *data) * 66 means evertything goes well! 66 is lucky. */ if (map->dir != DMA_FROM_DEVICE) - memset(buf, 0x66, PAGE_SIZE); + memset(buf, 0x66, size); map_stime = ktime_get(); - dma_addr = dma_map_single(map->dev, buf, PAGE_SIZE, map->dir); + dma_addr = dma_map_single(map->dev, buf, size, map->dir); if (unlikely(dma_mapping_error(map->dev, dma_addr))) { pr_err("dma_map_single failed on %s\n", dev_name(map->dev)); @@ -93,7 +96,7 @@ static int map_benchmark_thread(void *data) ndelay(map->bparam.dma_trans_ns); unmap_stime = ktime_get(); - dma_unmap_single(map->dev, dma_addr, PAGE_SIZE, map->dir); + dma_unmap_single(map->dev, dma_addr, size, map->dir); unmap_etime = ktime_get(); unmap_delta = ktime_sub(unmap_etime, unmap_stime); @@ -112,7 +115,7 @@ static int map_benchmark_thread(void *data) } out: - free_page((unsigned long)buf); + free_pages_exact(buf, size); return ret; } @@ -203,7 +206,6 @@ static long map_benchmark_ioctl(struct file *file, unsigned int cmd, struct map_benchmark_data *map = file->private_data; void __user *argp = (void __user *)arg; u64 old_dma_mask; - int ret; if (copy_from_user(&map->bparam, argp, sizeof(map->bparam))) @@ -234,6 +236,11 @@ static long map_benchmark_ioctl(struct file *file, unsigned int cmd, return -EINVAL; } + if (map->bparam.granule < 1 || map->bparam.granule > 1024) { + pr_err("invalid granule size\n"); + return -EINVAL; + } + switch (map->bparam.dma_dir) { case DMA_MAP_BIDIRECTIONAL: map->dir = DMA_BIDIRECTIONAL; diff --git a/tools/testing/selftests/dma/dma_map_benchmark.c b/tools/testing/selftests/dma/dma_map_benchmark.c index fb23ce9..6f2caa6 100644 --- a/tools/testing/selftests/dma/dma_map_benchmark.c +++ b/tools/testing/selftests/dma/dma_map_benchmark.c @@ -40,7 +40,8 @@ struct map_benchmark { __u32 dma_bits; /* DMA addressing capability */ __u32 dma_dir; /* DMA data direction */ __u32 dma_trans_ns; /* time for DMA transmission in ns */ - __u8 expansion[80]; /* For future use */ + __u32 granule; /* how many PAGE_SIZE will do map/unmap once a time */ + __u8 expansion[76]; /* For future use */ }; int main(int argc, char **argv) @@ -51,11 +52,13 @@ int main(int argc, char **argv) int threads = 1, seconds = 20, node = -1; /* default dma mask 32bit, bidirectional DMA */ int bits = 32, xdelay = 0, dir = DMA_MAP_BIDIRECTIONAL; + /* default granule 1 PAGESIZE */ + int granule = 1; int cmd = DMA_MAP_BENCHMARK; char *p; - while ((opt = getopt(argc, argv, "t:s:n:b:d:x:")) != -1) { + while ((opt = getopt(argc, argv, "t:s:n:b:d:x:g:")) != -1) { switch (opt) { case 't': threads = atoi(optarg); @@ -75,6 +78,9 @@ int main(int argc, char **argv) case 'x': xdelay = atoi(optarg); break; + case 'g': + granule = atoi(optarg); + break; default: return -1; } @@ -110,6 +116,11 @@ int main(int argc, char **argv) exit(1); } + if (granule < 1 || granule > 1024) { + fprintf(stderr, "invalid granule size\n"); + exit(1); + } + fd = open("/sys/kernel/debug/dma_map_benchmark", O_RDWR); if (fd == -1) { perror("open"); @@ -123,14 +134,15 @@ int main(int argc, char **argv) map.dma_bits = bits; map.dma_dir = dir; map.dma_trans_ns = xdelay; + map.granule = granule; if (ioctl(fd, cmd, &map)) { perror("ioctl"); exit(1); } - printf("dma mapping benchmark: threads:%d seconds:%d node:%d dir:%s\n", - threads, seconds, node, dir[directions]); + printf("dma mapping benchmark: threads:%d seconds:%d node:%d dir:%s granule: %d\n", + threads, seconds, node, dir[directions], granule); printf("average map latency(us):%.1f standard deviation:%.1f\n", map.avg_map_100ns/10.0, map.map_stddev/10.0); printf("average unmap latency(us):%.1f standard deviation:%.1f\n", -- 2.8.1

3 2

[PATCH] tty: pty: Add a blank line after declarations
by Xiaofei Tan 02 Apr '21

02 Apr '21

Add a blank line after declarations, reported by checkpatch.pl. Signed-off-by: Xiaofei Tan <tanxiaofei(a)huawei.com> --- drivers/tty/pty.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/tty/pty.c b/drivers/tty/pty.c index 5e23745..106265a 100644 --- a/drivers/tty/pty.c +++ b/drivers/tty/pty.c @@ -159,6 +159,7 @@ static int pty_chars_in_buffer(struct tty_struct *tty) static int pty_set_lock(struct tty_struct *tty, int __user *arg) { int val; + if (get_user(val, arg)) return -EFAULT; if (val) @@ -171,6 +172,7 @@ static int pty_set_lock(struct tty_struct *tty, int __user *arg) static int pty_get_lock(struct tty_struct *tty, int __user *arg) { int locked = test_bit(TTY_PTY_LOCK, &tty->flags); + return put_user(locked, arg); } @@ -200,6 +202,7 @@ static int pty_set_pktmode(struct tty_struct *tty, int __user *arg) static int pty_get_pktmode(struct tty_struct *tty, int __user *arg) { int pktmode = tty->packet; + return put_user(pktmode, arg); } @@ -463,6 +466,7 @@ static int pty_install(struct tty_driver *driver, struct tty_struct *tty) static void pty_remove(struct tty_driver *driver, struct tty_struct *tty) { struct tty_struct *pair = tty->link; + driver->ttys[tty->index] = NULL; if (pair) pair->driver->ttys[pair->index] = NULL; -- 2.8.1

1 0

[PATCH v2 00/15] acpi: fix some coding style issues
by Xiaofei Tan 02 Apr '21

02 Apr '21

Fix some coding style issues reported by checkpatch.pl. Differences from v1 to v2: - Add subsystem and module name in the name of patch 05/15. - Change to use more proper module name for some patch names. Xiaofei Tan (15): ACPI: APD: fix a block comment align issue ACPI: processor: fix some coding style issues ACPI: debug: fix some coding style issues ACPI: table: replace __attribute__((packed)) by __packed ACPI: ipmi: remove useless return statement for void function ACPI: LPSS: fix some coding style issues ACPI: memhotplug: fix a coding style issue ACPI: acpi_pad: fix a coding style issue ACPI: battery: fix some coding style issues ACPI: button: fix some coding style issues ACPI: CPPC: fix some coding style issues ACPI: custom_method: fix a coding style issue ACPI: PM: fix some coding style issues ACPI: sysfs: fix some coding style issues ACPI: dock: fix some coding style issues drivers/acpi/acpi_apd.c | 8 ++--- drivers/acpi/acpi_dbg.c | 40 +++++++++++------------- drivers/acpi/acpi_fpdt.c | 6 ++-- drivers/acpi/acpi_ipmi.c | 1 - drivers/acpi/acpi_lpss.c | 4 ++- drivers/acpi/acpi_memhotplug.c | 2 +- drivers/acpi/acpi_pad.c | 4 +++ drivers/acpi/acpi_processor.c | 18 +++-------- drivers/acpi/battery.c | 64 +++++++++++++++++++++---------------- drivers/acpi/button.c | 10 +++--- drivers/acpi/cppc_acpi.c | 71 +++++++++++++++++++++--------------------- drivers/acpi/custom_method.c | 2 +- drivers/acpi/device_pm.c | 3 ++ drivers/acpi/device_sysfs.c | 15 ++++++--- drivers/acpi/dock.c | 7 +++-- 15 files changed, 138 insertions(+), 117 deletions(-) -- 2.8.1

7 36