- Linuxarm - mailweb.openeuler.org

[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

2024

2023

2022

2021

2020

Linuxarm