Re: [RFC] net: core: devlink: add port_params_ops for devlink port parameters altering
On Fri, 9 Apr 2021 20:01:14 +0300 Vadym Kochan wrote: > On Fri, Apr 09, 2021 at 09:51:13AM -0700, Samudrala, Sridhar wrote: > > On 4/9/2021 9:22 AM, Oleksandr Mazur wrote: > > > I'd like to discuss a possibility of handling devlink port parameters > > > with devlink port pointer supplied. > > > > > > Current design makes it impossible to distinguish which port's parameter > > > should get altered (set) or retrieved (get) whenever there's a single > > > parameter registered within a few ports. > > > > I also noticed this issue recently when trying to add port parameters and > > I have a patch that handles this in a different way. The ops in > > devlink_param > > struct can be updated to include port_index as an argument > > We were thinking on this direction but rather decided to have more strict > cb signature which reflects that we are working with devlink_port only. +1 for passing the actual pointer
Re: [PATCH v2 2/2] drivers: net: dsa: qca8k: add support for multiple cpu port
On Fri, Apr 09, 2021 at 11:15:37AM -0700, Florian Fainelli wrote: > > > On 4/5/2021 10:16 PM, Ansuel Smith wrote: > > On Wed, Apr 07, 2021 at 02:41:02AM +0200, Andrew Lunn wrote: > >> On Tue, Apr 06, 2021 at 06:50:40AM +0200, Ansuel Smith wrote: > >>> qca8k 83xx switch have 2 cpu ports. Rework the driver to support > >>> multiple cpu port. All ports can access both cpu ports by default as > >>> they support the same features. > >> > >> Do you have more information about how this actually works. How does > >> the switch decide which port to use when sending a frame towards the > >> CPU? Is there some sort of load balancing? > >> > >> How does Linux decide which CPU port to use towards the switch? > >> > >> Andrew > > > > I could be very wrong, but in the current dsa code, only the very first > > cpu port is used and linux use only that to send data. > > That is correct, the first CPU port that is detected by the parsing > logic gets used. > > > In theory the switch send the frame to both CPU, I'm currently testing a > > multi-cpu patch for dsa and I can confirm that with the proposed code > > the packets are transmitted correctly and the 2 cpu ports are used. > > (The original code has one cpu dedicated to LAN ports and one cpu > > dedicated to the unique WAN port.) Anyway in the current implementation > > nothing will change. DSA code still supports one cpu and this change > > would only allow packet to be received and trasmitted from the second > > cpu. > > That use case seems to be the most common which makes sense since it > allows for true Gigabit routing between WAN and LAN by utilizing both > CPUs's Ethernet controllers. > > How do you currently assign a port of a switch with a particular CPU > port this is presumably done through a separate patch that you have not > submitted? > -- > Florian I reworked an old patch that added multi-cpu support to dsa. CPUs are assigned in a round-robin way and they can be set with an additional iproute command. (I read some of the comments in that RFC series and I'm planning to introduce some type of function where the switch driver can declare a preferred CPU port). Anyway this series is just to try to upstream the changes that doesn't require major revision, since they can be included even without the multi-cpu patch.
Re: [PATCH v11 3/6] clk: ralink: add clock driver for mt7621 SoC
Hi,
On Fri, Apr 9, 2021 at 8:14 PM Stephen Boyd wrote:
>
> Quoting Sergio Paracuellos (2021-03-08 21:22:23)
> > diff --git a/drivers/clk/ralink/Kconfig b/drivers/clk/ralink/Kconfig
> > new file mode 100644
> > index ..3e3f5cb9ad88
> > --- /dev/null
> > +++ b/drivers/clk/ralink/Kconfig
> > @@ -0,0 +1,15 @@
> > +# SPDX-License-Identifier: GPL-2.0-only
> > +#
> > +# MediaTek Mt7621 Clock Driver
> > +#
> > +menu "Clock driver for Mediatek mt7621 SoC"
> > + depends on SOC_MT7621 || COMPILE_TEST
>
> Do we need a menu and a config that says the same thing? Maybe the menu
> can be dropped?
Ok, I will drop the menu from this Kconfig.
>
> > +
> > +config CLK_MT7621
> > + bool "Clock driver for MediaTek MT7621"
> > + depends on SOC_MT7621 || COMPILE_TEST
> > + default SOC_MT7621
> > + select MFD_SYSCON
> > + help
> > + This driver supports MediaTek MT7621 basic clocks.
> > +endmenu
> > diff --git a/drivers/clk/ralink/Makefile b/drivers/clk/ralink/Makefile
> > new file mode 100644
> > index ..cf6f9216379d
> > --- /dev/null
> > +++ b/drivers/clk/ralink/Makefile
> > @@ -0,0 +1,2 @@
> > +# SPDX-License-Identifier: GPL-2.0
> > +obj-$(CONFIG_CLK_MT7621) += clk-mt7621.o
> > diff --git a/drivers/clk/ralink/clk-mt7621.c
> > b/drivers/clk/ralink/clk-mt7621.c
> > new file mode 100644
> > index ..6aea5accd51c
> > --- /dev/null
> > +++ b/drivers/clk/ralink/clk-mt7621.c
> > @@ -0,0 +1,528 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Mediatek MT7621 Clock Driver
> > + * Author: Sergio Paracuellos
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +/* Configuration registers */
> > +#define SYSC_REG_SYSTEM_CONFIG0 0x10
> > +#define SYSC_REG_SYSTEM_CONFIG1 0x14
> > +#define SYSC_REG_CLKCFG0 0x2c
> > +#define SYSC_REG_CLKCFG1 0x30
> > +#define SYSC_REG_CUR_CLK_STS 0x44
> > +#define MEMC_REG_CPU_PLL 0x648
> > +
> > +#define XTAL_MODE_SEL_MASK GENMASK(8, 6)
> > +#define CPU_CLK_SEL_MASK GENMASK(31, 30)
> > +#define CUR_CPU_FDIV_MASK GENMASK(12, 8)
> > +#define CUR_CPU_FFRAC_MASK GENMASK(4, 0)
> > +#define CPU_PLL_PREDIV_MASKGENMASK(13, 12)
> > +#define CPU_PLL_FBDIV_MASK GENMASK(10, 4)
> > +
> > +struct mt7621_clk_priv {
> > + struct regmap *sysc;
> > + struct regmap *memc;
> > +};
> > +
> > +struct mt7621_clk {
> > + struct clk_hw hw;
> > + struct mt7621_clk_priv *priv;
> > +};
> > +
> > +struct mt7621_fixed_clk {
> > + u8 idx;
> > + const char *name;
> > + const char *parent_name;
> > + unsigned long rate;
> > + struct clk_hw *hw;
> > +};
> > +
> > +struct mt7621_gate {
> > + u8 idx;
> > + const char *name;
> > + const char *parent_name;
> > + struct mt7621_clk_priv *priv;
> > + u32 bit_idx;
> > + struct clk_hw hw;
> > +};
> > +
> > +#define GATE(_id, _name, _pname, _shift) \
> > + { \
> > + .idx= _id, \
> > + .name = _name,\
> > + .parent_name= _pname, \
> > + .bit_idx= _shift\
> > + }
> > +
> > +static struct mt7621_gate mt7621_gates[] = {
> > + GATE(MT7621_CLK_HSDMA, "hsdma", "150m", BIT(5)),
> > + GATE(MT7621_CLK_FE, "fe", "250m", BIT(6)),
> > + GATE(MT7621_CLK_SP_DIVTX, "sp_divtx", "270m", BIT(7)),
> > + GATE(MT7621_CLK_TIMER, "timer", "50m", BIT(8)),
> > + GATE(MT7621_CLK_PCM, "pcm", "270m", BIT(11)),
> > + GATE(MT7621_CLK_PIO, "pio", "50m", BIT(13)),
> > + GATE(MT7621_CLK_GDMA, "gdma", "bus", BIT(14)),
> > + GATE(MT7621_CLK_NAND, "nand", "125m", BIT(15)),
> > + GATE(MT7621_CLK_I2C, "i2c", "50m", BIT(16)),
> > + GATE(MT7621_CLK_I2S, "i2s", "270m", BIT(17)),
> > + GATE(MT7621_CLK_SPI, "spi", "bus", BIT(18)),
> > + GATE(MT7621_CLK_UART1, "uart1", "50m", BIT(19)),
> > + GATE(MT7621_CLK_UART2, "uart2", "50m", BIT(20)),
> > + GATE(MT7621_CLK_UART3, "uart3", "50m", BIT(21)),
> > + GATE(MT7621_CLK_ETH, "eth", "50m", BIT(23)),
> > + GATE(MT7621_CLK_PCIE0, "pcie0", "125m", BIT(24)),
> > + GATE(MT7621_CLK_PCIE1, "pcie1", "125m", BIT(25)),
> > + GATE(MT7621_CLK_PCIE2, "pcie2", "125m", BIT(26)),
> > + GATE(MT7621_CLK_CRYPTO, "crypto", "250m", BIT(29)),
> > + GATE(MT7621_CLK_SHXC, "shxc", "50m", BIT(30))
> > +};
> > +
> > +static inline struct mt7621_gate *to_mt7621_gate(struct clk_hw *hw)
> > +{
> > + return container_of(hw, struct mt7621_gate, hw);
> > +}
> > +
> > +static int mt7621_gate_enable(struct clk_hw *hw)
> > +{
> > + struct mt7621_gate *clk_gate = to_mt7621_gate(hw);
> > + struct regmap
Re: [PATCH 2/3] nvmem: eeprom: at25: add support for FRAM
Hi Jiri,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on char-misc/char-misc-testing]
[also build test WARNING on robh/for-next linux/master linus/master v5.12-rc6
next-20210409]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Jiri-Prchal/nvmem-eeprom-add-support-for-FRAM/20210409-235546
base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git
b195b20b7145bcae22ad261abc52d68336f5e913
config: arm64-randconfig-r033-20210409 (attached as .config)
compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project
dd453a1389b6a7e6d9214b449d3c54981b1a89b6)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install arm64 cross compiling tool for clang build
# apt-get install binutils-aarch64-linux-gnu
#
https://github.com/0day-ci/linux/commit/d335df5f35cd09d8f9d7f14e0bfbad45ab2bc33a
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Jiri-Prchal/nvmem-eeprom-add-support-for-FRAM/20210409-235546
git checkout d335df5f35cd09d8f9d7f14e0bfbad45ab2bc33a
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> drivers/misc/eeprom/at25.c:169:59: warning: format specifies type 'size_t'
>> (aka 'unsigned long') but the argument has type 'int' [-Wformat]
dev_dbg(&at25->spi->dev, "read %zu aux bytes --> %zd\n", len,
status);
~~~ ^~~
%d
include/linux/dev_printk.h:123:39: note: expanded from macro 'dev_dbg'
dynamic_dev_dbg(dev, dev_fmt(fmt), ##__VA_ARGS__)
~~~ ^~~
include/linux/dynamic_debug.h:162:19: note: expanded from macro
'dynamic_dev_dbg'
dev, fmt, ##__VA_ARGS__)
~~~^~~
include/linux/dynamic_debug.h:147:56: note: expanded from macro
'_dynamic_func_call'
__dynamic_func_call(__UNIQUE_ID(ddebug), fmt, func, ##__VA_ARGS__)
^~~
include/linux/dynamic_debug.h:129:15: note: expanded from macro
'__dynamic_func_call'
func(&id, ##__VA_ARGS__); \
^~~
>> drivers/misc/eeprom/at25.c:169:64: warning: format specifies type 'ssize_t'
>> (aka 'long') but the argument has type 'int' [-Wformat]
dev_dbg(&at25->spi->dev, "read %zu aux bytes --> %zd\n", len,
status);
~~~ ^~
%d
include/linux/dev_printk.h:123:39: note: expanded from macro 'dev_dbg'
dynamic_dev_dbg(dev, dev_fmt(fmt), ##__VA_ARGS__)
~~~ ^~~
include/linux/dynamic_debug.h:162:19: note: expanded from macro
'dynamic_dev_dbg'
dev, fmt, ##__VA_ARGS__)
~~~^~~
include/linux/dynamic_debug.h:147:56: note: expanded from macro
'_dynamic_func_call'
__dynamic_func_call(__UNIQUE_ID(ddebug), fmt, func, ##__VA_ARGS__)
^~~
include/linux/dynamic_debug.h:129:15: note: expanded from macro
'__dynamic_func_call'
func(&id, ##__VA_ARGS__); \
^~~
2 warnings generated.
vim +169 drivers/misc/eeprom/at25.c
144
145 /*
146 * read extra registers as ID or serial number
147 */
148 static int fm25_aux_read(struct at25_data *at25, char *buf, uint8_t
command,
149 int len)
150 {
151 int status;
152 struct spi_transfer t[2];
153 struct spi_message m;
154
155 spi_message_init(&m);
156 memset(t, 0, sizeof(t));
157
158 t[0].tx_buf = &command;
159 t[0].len = 1;
160 spi_message_add_tail(&t[0], &m);
161
162 t[1].rx_buf = buf;
163
Re: [PATCH v1 1/2] dt-bindings: i2c: add "dev-name" property to assign specific device name
On Wed, Apr 07, 2021 at 11:50:38AM -0700, Manish Varma wrote: > I2C devices currently are named dynamically using > - convention, unless they are instantiated > through ACPI. > > This means the device name may vary for the same device across different > systems, infact even on the same system if the I2C bus enumeration order > changes, i.e. because of device tree modifications. > > By adding an optional "dev-name" property, it provides a mechanism to > set consistent and easy to recognize names for I2C devices. So? Why do you need 'easy to recognize names'? Why is I2C special? If we wanted this in DT, it wouldn't be I2C specific and we probably would have added it long ago. > Signed-off-by: Manish Varma > --- > Documentation/devicetree/bindings/i2c/i2c.txt | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/Documentation/devicetree/bindings/i2c/i2c.txt > b/Documentation/devicetree/bindings/i2c/i2c.txt > index df41f72afc87..6fb03f464b81 100644 > --- a/Documentation/devicetree/bindings/i2c/i2c.txt > +++ b/Documentation/devicetree/bindings/i2c/i2c.txt > @@ -130,6 +130,11 @@ wants to support one of the below features, it should > adapt these bindings. > - wakeup-source > device can be used as a wakeup source. > > +- dev-name > + Name of the device. > + Overrides the default device name which is in the form of > + -. What's 'busnr'? No such thing in DT. > + > Binding may contain optional "interrupts" property, describing interrupts > used by the device. I2C core will assign "irq" interrupt (or the very first > interrupt if not using interrupt names) as primary interrupt for the slave. > -- > 2.31.1.295.g9ea45b61b8-goog >
[PATCH] block: initialize variable ret with 0
ret variable is not being set if get_capacity returns 0 in very first
try. It should be initialized with 0 for this case.
Addresses-Coverity: ("Uninitialized variable")
Fixes: d3c4a43d92 ("block: refactor blk_drop_partitions")
Signed-off-by: Muhammad Usama Anjum
---
fs/block_dev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/block_dev.c b/fs/block_dev.c
index bb02b4be7f1c..986951bfee85 100644
--- a/fs/block_dev.c
+++ b/fs/block_dev.c
@@ -1240,7 +1240,7 @@ static void __blkdev_put(struct block_device *bdev,
fmode_t mode, int for_part);
int bdev_disk_changed(struct block_device *bdev, bool invalidate)
{
struct gendisk *disk = bdev->bd_disk;
- int ret;
+ int ret = 0;
lockdep_assert_held(&bdev->bd_mutex);
--
2.25.1
Re: [PATCH v11 0/6] MIPS: ralink: add CPU clock detection and clock driver for MT7621
Quoting Sergio Paracuellos (2021-04-09 11:25:24) > Hi Stephen, > > On Fri, Apr 9, 2021 at 8:17 PM Stephen Boyd wrote: > > > > Quoting Sergio Paracuellos (2021-03-23 01:13:22) > > > On Tue, Mar 9, 2021 at 6:22 AM Sergio Paracuellos > > > wrote: > > > > > > > > Changes in v11: > > > > - Collect Rob's Reviewed-by in bindings documentation patch. > > > > - Fix MAINTAINERS patch using file 'mediatek,mt7621-sysc.yaml' > > > >for documentation bindings. > > > > > > Something still missing or something that is needed to be fixed to get > > > this series applied through your tree? > > > > > > Thanks in advance for your time. > > > > > > > Sorry I missed this series. I thought it was going through another tree. > > It can merge through clk tree. Just a few nits on the clk driver patch > > but otherwise I've merged the first two patches. If you resend in the > > next few days it would be great. Thanks. > > I will hopefully do during this weekend. Since you already merge the > first two patches, the remaining four should be sent as v12, right? Yes. I'll push it out to kernel.org shortly.
Re: [RFC PATCH v2 09/18] mm: vmscan: remove noinline_for_stack
On Fri, Apr 09, 2021 at 08:29:50PM +0800, Muchun Song wrote:
> The noinline_for_stack is introduced by commit 666356297ec4 ("vmscan:
> set up pagevec as late as possible in shrink_inactive_list()"), its
> purpose is to delay the allocation of pagevec as late as possible to
> save stack memory. But the commit 2bcf88796381 ("mm: take pagevecs off
> reclaim stack") replace pagevecs by lists of pages_to_free. So we do
> not need noinline_for_stack, just remove it (let the compiler decide
> whether to inline).
>
> Signed-off-by: Muchun Song
Good catch.
Acked-by: Johannes Weiner
Since this patch is somewhat independent of the rest of the series,
you may want to put it in the very beginning, or even submit it
separately, to keep the main series as compact as possible. Reviewers
can be more hesitant to get involved with larger series ;)
Re: [PATCH][V2] clk: uniphier: Fix potential infinite loop
On Fri, Apr 9, 2021 at 6:01 PM Colin King wrote:
>
> From: Colin Ian King
>
> The for-loop iterates with a u8 loop counter i and compares this
> with the loop upper limit of num_parents that is an int type.
> There is a potential infinite loop if num_parents is larger than
> the u8 loop counter. Fix this by making the loop counter the same
> type as num_parents. Also make num_parents an unsigned int to
> match the return type of the call to clk_hw_get_num_parents.
>
> Addresses-Coverity: ("Infinite loop")
> Fixes: 734d82f4a678 ("clk: uniphier: add core support code for UniPhier clock
> driver")
>
> Signed-off-by: Colin Ian King
> ---
>
> V2: Make num_parents an unsigned int to match return type of
> clk_hw_get_num_parents().
Reviewed-by: Masahiro Yamada
> ---
> drivers/clk/uniphier/clk-uniphier-mux.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/clk/uniphier/clk-uniphier-mux.c
> b/drivers/clk/uniphier/clk-uniphier-mux.c
> index 462c84321b2d..1998e9d4cfc0 100644
> --- a/drivers/clk/uniphier/clk-uniphier-mux.c
> +++ b/drivers/clk/uniphier/clk-uniphier-mux.c
> @@ -31,10 +31,10 @@ static int uniphier_clk_mux_set_parent(struct clk_hw *hw,
> u8 index)
> static u8 uniphier_clk_mux_get_parent(struct clk_hw *hw)
> {
> struct uniphier_clk_mux *mux = to_uniphier_clk_mux(hw);
> - int num_parents = clk_hw_get_num_parents(hw);
> + unsigned int num_parents = clk_hw_get_num_parents(hw);
> int ret;
> unsigned int val;
> - u8 i;
> + unsigned int i;
>
> ret = regmap_read(mux->regmap, mux->reg, &val);
> if (ret)
> --
> 2.30.2
>
--
Best Regards
Masahiro Yamada
Re: [PATCH 4/4] ARM: dts: Fix-up EMMC2 controller's frequency
Hi Nicolas, Am 09.04.21 um 12:54 schrieb Nicolas Saenz Julienne: > Hi again, > > On Wed, 2021-04-07 at 16:37 -0400, Alan Cooper wrote: >> Nicolas, >> >> I got a better description of the failure and it looks like the bus >> clock needs to be limited to 300KHz for a 500MHz core clock. >> What's happening is that an internal reset sequence is needed after a >> command timeout and the reset signal needs to be asserted for at least >> 2 ticks of the bus clock. This is done using a 12 bit counter clocked >> by the core clock. That means a 500MHz core clock produces a 122KHz >> reset signal which is too fast for 2 ticks of the 200KHz bus clock >> (100KHz) but is okay for the 300KHz (150Khz) bus clock. > Is there any value in implementing this in a generic way? i don't have any idea which callback could manipulate the reset duration. Limiting the min clk frequency looks like the less invasive solution to me. Touching the DT isn't recommend. Best regards
Re: [PATCH v2 -next 3/3] clk: qcom: apss-ipq-pll: Add missing MODULE_DEVICE_TABLE
Quoting Chen Hui (2021-04-09 01:23:52)
> CONFIG_IPQ_APSS_PLL is tristate option and therefore this driver can
> be compiled as a module. This patch adds missing MODULE_DEVICE_TABLE
> definition which generates correct modalias for automatic loading of
> this driver when it is built as an external module.
>
> Fixes: ecd2bacfbbc4 ("clk: qcom: Add ipq apss pll driver")
> Signed-off-by: Chen Hui
> Reviewed-by: Manivannan Sadhasivam
> ---
Applied to clk-next
Re: [PATCH v2 -next 2/3] clk: qcom: a53-pll: Add missing MODULE_DEVICE_TABLE
Quoting Chen Hui (2021-04-09 01:23:51)
> CONFIG_QCOM_A53PLL is tristate option and therefore this driver can be
> compiled as a module. This patch adds missing MODULE_DEVICE_TABLE
> definition which generates correct modalias for automatic loading of
> this driver when it is built as an external module.
>
> Fixes: 0c6ab1b8f894 ("clk: qcom: Add A53 PLL support")
> Signed-off-by: Chen Hui
> Reviewed-by: Manivannan Sadhasivam
> ---
Applied to clk-next
Re: [PATCH v2 -next 1/3] clk: qcom: a7-pll: Add missing MODULE_DEVICE_TABLE
Quoting Chen Hui (2021-04-09 01:23:50)
> CONFIG_QCOM_A7PLL is tristate option and therefore this driver can be
> compiled as a module. This patch adds missing MODULE_DEVICE_TABLE
> definition which generates correct modalias for automatic loading of
> this driver when it is built as an external module.
>
> Fixes: 5a5223ffd7ef ("clk: qcom: Add A7 PLL support")
> Signed-off-by: Chen Hui
> Reviewed-by: Manivannan Sadhasivam
> ---
Applied to clk-next
Re: [Outreachy kernel][PATCH] staging: media: hantro: Rewrite macro function in lower case
Em sex, 2021-04-09 às 14:42 -0300, Ezequiel Garcia escreveu: > On Fri, 2021-04-09 at 19:25 +0200, Julia Lawall wrote: > > > > > > On Fri, 9 Apr 2021, ascordeiro wrote: > > > > > Em sex, 2021-04-09 às 13:44 -0300, Ezequiel Garcia escreveu: > > > > Hi Aline, > > > > > > Hi Ezequiel, > > > > > > > > On Fri, 2021-04-09 at 10:54 -0300, Aline Santana Cordeiro > > > > wrote: > > > > > Rewrite macros resembling functions #define > > > > > HANTRO_PP_REG_WRITE > > > > > and #define HANTRO_PP_RED_WRITE_S in lower case, according > > > > > with > > > > > code style. > > > > Maybe you can see if these macros can be converted to static inline > > functions. Macros don't provide any type checking. > > > > I'd like to leave these as they are for now, tbh ^_^ > > A more massive refactoring is needed in this driver, > but it needs proper testing and it's a more complex plan. Okay, thank you for your attention :) Aline > > Thanks! > Ezequiel >
Re: [PATCH 4/8] dt-bindings: arm: mediatek: Add new document bindings for APU
On Wed, Apr 07, 2021 at 11:28:02AM +0800, Flora Fu wrote:
> Document the apusys bindings.
>
> Signed-off-by: Flora Fu
> ---
> .../arm/mediatek/mediatek,apusys.yaml | 56 +++
> 1 file changed, 56 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/arm/mediatek/mediatek,apusys.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/arm/mediatek/mediatek,apusys.yaml
> b/Documentation/devicetree/bindings/arm/mediatek/mediatek,apusys.yaml
> new file mode 100644
> index ..dc04a46f1bad
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,apusys.yaml
> @@ -0,0 +1,56 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/arm/mediatek/mediatek,apusys.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: MediaTek APUSYS Controller
> +
> +maintainers:
> + - Flora Fu
> +
> +description:
> + The Mediatek apusys controller provides functional configurations and
> clocks
> + to the system.
> +
> +properties:
> + compatible:
> +items:
> + - enum:
> + - mediatek,mt8192-apu_mbox
> + - mediatek,mt8192-apu_conn
> + - mediatek,mt8192-apu_vcore
s/_/-/
> + - const: syscon
> +
> + reg:
> +maxItems: 1
> +
> + '#clock-cells':
> +const: 1
> +
> +required:
> + - compatible
> + - reg
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +apu_mbox: apu_mbox@1900 {
mailbox@...? Is this a mailbox provider?
> +compatible = "mediatek,mt8192-apu_mbox", "syscon";
> +reg = <0x1900 0x1000>;
> +};
> +
> + - |
> +apu_conn: apu_conn@1902 {
> +compatible = "mediatek,mt8192-apu_conn", "syscon";
> +reg = <0x1902 0x1000>;
> +#clock-cells = <1>;
> +};
> +
> + - |
> +apu_vcore: apu_vcore@19029000 {
> +compatible = "mediatek,mt8192-apu_vcore", "syscon";
> +reg = <0x19029000 0x1000>;
> +#clock-cells = <1>;
> +};
> --
> 2.18.0
>
Re: [PATCH v11 0/6] MIPS: ralink: add CPU clock detection and clock driver for MT7621
Hi Stephen, On Fri, Apr 9, 2021 at 8:17 PM Stephen Boyd wrote: > > Quoting Sergio Paracuellos (2021-03-23 01:13:22) > > On Tue, Mar 9, 2021 at 6:22 AM Sergio Paracuellos > > wrote: > > > > > > Changes in v11: > > > - Collect Rob's Reviewed-by in bindings documentation patch. > > > - Fix MAINTAINERS patch using file 'mediatek,mt7621-sysc.yaml' > > >for documentation bindings. > > > > Something still missing or something that is needed to be fixed to get > > this series applied through your tree? > > > > Thanks in advance for your time. > > > > Sorry I missed this series. I thought it was going through another tree. > It can merge through clk tree. Just a few nits on the clk driver patch > but otherwise I've merged the first two patches. If you resend in the > next few days it would be great. Thanks. I will hopefully do during this weekend. Since you already merge the first two patches, the remaining four should be sent as v12, right?
Re: [PATCH 3/8] dt-bindings: apu: Add MT8192 APU power domain
On Wed, Apr 07, 2021 at 11:28:01AM +0800, Flora Fu wrote: > Create MT8192 APU power domain bindings. > Add top power domain id. > > Signed-off-by: Flora Fu > --- > include/dt-bindings/power/mt8192-apu-power.h | 11 +++ > 1 file changed, 11 insertions(+) > create mode 100644 include/dt-bindings/power/mt8192-apu-power.h > > diff --git a/include/dt-bindings/power/mt8192-apu-power.h > b/include/dt-bindings/power/mt8192-apu-power.h > new file mode 100644 > index ..b821bd4811a6 > --- /dev/null > +++ b/include/dt-bindings/power/mt8192-apu-power.h > @@ -0,0 +1,11 @@ > +/* SPDX-License-Identifier: GPL-2.0 > + * > + * Copyright (c) 2021 MediaTek Inc. > + */ > + > +#ifndef _DT_BINDINGS_POWER_MT8192_APU_POWER_H > +#define _DT_BINDINGS_POWER_MT8192_APU_POWER_H > + > +#define MT8192_POWER_DOMAIN_APUSYS_TOP 0 Really, you don't know what the other power domains are? Please make this as complete as possible. These headers create a merge mess. Rob
Re: [PATCH 1/5] x86/cpufeatures: Define feature bits to support mitigation of PSF
On 4/9/2021 12:41 PM, Borislav Petkov wrote: > On Tue, Apr 06, 2021 at 10:50:00AM -0500, Ramakrishna Saripalli wrote: >> diff --git a/arch/x86/include/asm/cpufeatures.h >> b/arch/x86/include/asm/cpufeatures.h >> index cc96e26d69f7..21e7f8d0d7d9 100644 >> --- a/arch/x86/include/asm/cpufeatures.h >> +++ b/arch/x86/include/asm/cpufeatures.h >> @@ -201,7 +201,7 @@ >> #define X86_FEATURE_INVPCID_SINGLE ( 7*32+ 7) /* Effectively INVPCID && >> CR4.PCIDE=1 */ >> #define X86_FEATURE_HW_PSTATE ( 7*32+ 8) /* AMD HW-PState */ >> #define X86_FEATURE_PROC_FEEDBACK ( 7*32+ 9) /* AMD ProcFeedbackInterface >> */ >> -/* FREE!( 7*32+10) */ >> +#define X86_FEATURE_PSFD( 7*32+10) /* Predictive Store Forward >> Disable */ > > You don't need this one... Boris, I added this bit so we could detect later that PSF is supported. But since PSF is AMD specific for now, I guess I will go along with your suggestions. > >> #define X86_FEATURE_PTI ( 7*32+11) /* Kernel Page Table >> Isolation enabled */ >> #define X86_FEATURE_RETPOLINE ( 7*32+12) /* "" Generic >> Retpoline mitigation for Spectre variant 2 */ >> #define X86_FEATURE_RETPOLINE_AMD ( 7*32+13) /* "" AMD Retpoline >> mitigation for Spectre variant 2 */ >> @@ -309,6 +309,7 @@ >> #define X86_FEATURE_AMD_SSBD(13*32+24) /* "" Speculative >> Store Bypass Disable */ >> #define X86_FEATURE_VIRT_SSBD (13*32+25) /* Virtualized >> Speculative Store Bypass Disable */ >> #define X86_FEATURE_AMD_SSB_NO (13*32+26) /* "" Speculative >> Store Bypass is fixed in hardware. */ >> +#define X86_FEATURE_AMD_PSFD(13*32+28) /* "" Predictive >> Store Forward Disable */ > > ... when you have this one. And this one is AMD-specific so you can just > as well call it X86_FEATURE_PSFD and remove the "". Ok > >> >> /* Thermal and Power Management Leaf, CPUID level 0x0006 (EAX), word 14 >> */ >> #define X86_FEATURE_DTHERM (14*32+ 0) /* Digital Thermal Sensor */ >> @@ -428,5 +429,6 @@ >> #define X86_BUG_TAA X86_BUG(22) /* CPU is affected by TSX >> Async Abort(TAA) */ >> #define X86_BUG_ITLB_MULTIHIT X86_BUG(23) /* CPU may incur >> MCE during certain page attribute changes */ >> #define X86_BUG_SRBDS X86_BUG(24) /* CPU may leak RNG >> bits if not mitigated */ >> +#define X86_BUG_PSF X86_BUG(25) /* CPU is affected by >> Predictive Store Forwarding attack */ > > And I think you don't need this one either if we do a "light" controls > thing but lemme look at the rest first. > Ok. > Thx. >
[PATCH] nvme-pci: don't simple map sgl when sgls are disabled
From: Niklas Cassel
According to the module parameter description for sgl_threshold,
a value of 0 means that SGLs are disabled.
If SGLs are disabled, we should respect that, even for the case
where the request is made up of a single physical segment.
Fixes: 297910571f08 ("nvme-pci: optimize mapping single segment requests using
SGLs")
Signed-off-by: Niklas Cassel
---
drivers/nvme/host/pci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
index d47bb18b976a..b06e685d1250 100644
--- a/drivers/nvme/host/pci.c
+++ b/drivers/nvme/host/pci.c
@@ -854,7 +854,7 @@ static blk_status_t nvme_map_data(struct nvme_dev *dev,
struct request *req,
return nvme_setup_prp_simple(dev, req,
&cmnd->rw, &bv);
- if (iod->nvmeq->qid &&
+ if (iod->nvmeq->qid && sgl_threshold &&
dev->ctrl.sgls & ((1 << 0) | (1 << 1)))
return nvme_setup_sgl_simple(dev, req,
&cmnd->rw, &bv);
--
2.30.2
Re: [PATCH] HID: hid-sensor-custom: remove useless variable
On Fri, 2021-04-09 at 15:15 +0800, Jiapeng Chong wrote:
> Fix the following gcc warning:
>
> drivers/hid/hid-sensor-custom.c:400:7: warning: variable ‘ret’ set
> but
> not used [-Wunused-but-set-variable].
>
> Reported-by: Abaci Robot
> Signed-off-by: Jiapeng Chong
Acked-by: Srinivas Pandruvada ---
> drivers/hid/hid-sensor-custom.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/hid/hid-sensor-custom.c b/drivers/hid/hid-
> sensor-custom.c
> index 2628bc5..e430673 100644
> --- a/drivers/hid/hid-sensor-custom.c
> +++ b/drivers/hid/hid-sensor-custom.c
> @@ -397,15 +397,14 @@ static ssize_t store_value(struct device *dev,
> struct device_attribute *attr,
>
> if (!strncmp(name, "value", strlen("value"))) {
> u32 report_id;
> - int ret;
>
> if (kstrtoint(buf, 0, &value) != 0)
> return -EINVAL;
>
> report_id = sensor_inst->fields[field_index].attribute.
> report_
> id;
> - ret = sensor_hub_set_feature(sensor_inst->hsdev,
> report_id,
> - index, sizeof(value),
> &value);
> + sensor_hub_set_feature(sensor_inst->hsdev, report_id,
> index,
> +sizeof(value), &value);
> } else
> return -EINVAL;
>
Re: [PATCH v2 2/2] drivers: net: dsa: qca8k: add support for multiple cpu port
On 4/5/2021 10:16 PM, Ansuel Smith wrote: > On Wed, Apr 07, 2021 at 02:41:02AM +0200, Andrew Lunn wrote: >> On Tue, Apr 06, 2021 at 06:50:40AM +0200, Ansuel Smith wrote: >>> qca8k 83xx switch have 2 cpu ports. Rework the driver to support >>> multiple cpu port. All ports can access both cpu ports by default as >>> they support the same features. >> >> Do you have more information about how this actually works. How does >> the switch decide which port to use when sending a frame towards the >> CPU? Is there some sort of load balancing? >> >> How does Linux decide which CPU port to use towards the switch? >> >> Andrew > > I could be very wrong, but in the current dsa code, only the very first > cpu port is used and linux use only that to send data. That is correct, the first CPU port that is detected by the parsing logic gets used. > In theory the switch send the frame to both CPU, I'm currently testing a > multi-cpu patch for dsa and I can confirm that with the proposed code > the packets are transmitted correctly and the 2 cpu ports are used. > (The original code has one cpu dedicated to LAN ports and one cpu > dedicated to the unique WAN port.) Anyway in the current implementation > nothing will change. DSA code still supports one cpu and this change > would only allow packet to be received and trasmitted from the second > cpu. That use case seems to be the most common which makes sense since it allows for true Gigabit routing between WAN and LAN by utilizing both CPUs's Ethernet controllers. How do you currently assign a port of a switch with a particular CPU port this is presumably done through a separate patch that you have not submitted? -- Florian
Re: [PATCH v11 2/6] dt: bindings: add mt7621-sysc device tree binding documentation
Quoting Sergio Paracuellos (2021-03-08 21:22:22) > Adds device tree binding documentation for clocks in the > MT7621 SOC. > > Reviewed-by: Rob Herring > Signed-off-by: Sergio Paracuellos > --- Applied to clk-next
Re: [PATCH v11 1/6] dt-bindings: clock: add dt binding header for mt7621 clocks
Quoting Sergio Paracuellos (2021-03-08 21:22:21) > Adds dt binding header for 'mediatek,mt7621-clk' clocks. > > Acked-by: Rob Herring > Signed-off-by: Sergio Paracuellos > --- Applied to clk-next
[RFC PATCH 3/3] net: axienet: Introduce dmaengine support
The axiethernet driver have in-built dma programming. The aim is to remove axiethernet axidma programming and instead use the dmaengine framework to communicate with existing xilinx DMAengine controller(xilinx_dma) driver. This initial version is a proof of concept and validated with ping test. There is an anticipated performance impact due to adoption of dmaengine framework. The plan is to revisit it once all required functional features are implemented. The dmaengine framework was extended for metadata API support during the axidma RFC[1] discussion. However it still need further enhancements to make it well suited for ethernet usecases. The ethernet features i.e ethtool set/get of DMA IP properties, ndo_poll_controller, trigger reset of DMA IP from ethernet are not supported (mentioned in TODO) and it requires follow-up discussion and dma framework enhancement. [1]: https://lore.kernel.org/lkml/1522665546-10035-1-git-send-email-radh...@xilinx.com Signed-off-by: Radhey Shyam Pandey --- drivers/net/ethernet/xilinx/xilinx_axienet.h | 141 +-- drivers/net/ethernet/xilinx/xilinx_axienet_main.c | 1050 - 2 files changed, 185 insertions(+), 1006 deletions(-) diff --git a/drivers/net/ethernet/xilinx/xilinx_axienet.h b/drivers/net/ethernet/xilinx/xilinx_axienet.h index 1e966a39967e..1baa75d07f94 100644 --- a/drivers/net/ethernet/xilinx/xilinx_axienet.h +++ b/drivers/net/ethernet/xilinx/xilinx_axienet.h @@ -70,76 +70,10 @@ XAE_OPTION_RXEN) /* Axi DMA Register definitions */ - -#define XAXIDMA_TX_CR_OFFSET 0x /* Channel control */ -#define XAXIDMA_TX_SR_OFFSET 0x0004 /* Status */ -#define XAXIDMA_TX_CDESC_OFFSET0x0008 /* Current descriptor pointer */ -#define XAXIDMA_TX_TDESC_OFFSET0x0010 /* Tail descriptor pointer */ - -#define XAXIDMA_RX_CR_OFFSET 0x0030 /* Channel control */ -#define XAXIDMA_RX_SR_OFFSET 0x0034 /* Status */ -#define XAXIDMA_RX_CDESC_OFFSET0x0038 /* Current descriptor pointer */ -#define XAXIDMA_RX_TDESC_OFFSET0x0040 /* Tail descriptor pointer */ - -#define XAXIDMA_CR_RUNSTOP_MASK0x0001 /* Start/stop DMA channel */ -#define XAXIDMA_CR_RESET_MASK 0x0004 /* Reset DMA engine */ - -#define XAXIDMA_SR_HALT_MASK 0x0001 /* Indicates DMA channel halted */ - -#define XAXIDMA_BD_NDESC_OFFSET0x00 /* Next descriptor pointer */ -#define XAXIDMA_BD_BUFA_OFFSET 0x08 /* Buffer address */ -#define XAXIDMA_BD_CTRL_LEN_OFFSET 0x18 /* Control/buffer length */ -#define XAXIDMA_BD_STS_OFFSET 0x1C /* Status */ -#define XAXIDMA_BD_USR0_OFFSET 0x20 /* User IP specific word0 */ -#define XAXIDMA_BD_USR1_OFFSET 0x24 /* User IP specific word1 */ -#define XAXIDMA_BD_USR2_OFFSET 0x28 /* User IP specific word2 */ -#define XAXIDMA_BD_USR3_OFFSET 0x2C /* User IP specific word3 */ -#define XAXIDMA_BD_USR4_OFFSET 0x30 /* User IP specific word4 */ -#define XAXIDMA_BD_ID_OFFSET 0x34 /* Sw ID */ -#define XAXIDMA_BD_HAS_STSCNTRL_OFFSET 0x38 /* Whether has stscntrl strm */ -#define XAXIDMA_BD_HAS_DRE_OFFSET 0x3C /* Whether has DRE */ - -#define XAXIDMA_BD_HAS_DRE_SHIFT 8 /* Whether has DRE shift */ -#define XAXIDMA_BD_HAS_DRE_MASK0xF00 /* Whether has DRE mask */ -#define XAXIDMA_BD_WORDLEN_MASK0xFF /* Whether has DRE mask */ - -#define XAXIDMA_BD_CTRL_LENGTH_MASK0x007F /* Requested len */ -#define XAXIDMA_BD_CTRL_TXSOF_MASK 0x0800 /* First tx packet */ -#define XAXIDMA_BD_CTRL_TXEOF_MASK 0x0400 /* Last tx packet */ -#define XAXIDMA_BD_CTRL_ALL_MASK 0x0C00 /* All control bits */ - -#define XAXIDMA_DELAY_MASK 0xFF00 /* Delay timeout counter */ -#define XAXIDMA_COALESCE_MASK 0x00FF /* Coalesce counter */ - -#define XAXIDMA_DELAY_SHIFT24 -#define XAXIDMA_COALESCE_SHIFT 16 - -#define XAXIDMA_IRQ_IOC_MASK 0x1000 /* Completion intr */ -#define XAXIDMA_IRQ_DELAY_MASK 0x2000 /* Delay interrupt */ -#define XAXIDMA_IRQ_ERROR_MASK 0x4000 /* Error interrupt */ -#define XAXIDMA_IRQ_ALL_MASK 0x7000 /* All interrupts */ - -/* Default TX/RX Threshold and waitbound values for SGDMA mode */ -#define XAXIDMA_DFT_TX_THRESHOLD 24 -#define XAXIDMA_DFT_TX_WAITBOUND 254 -#define XAXIDMA_DFT_RX_THRESHOLD 24 -#define XAXIDMA_DFT_RX_WAITBOUND 254 - -#define XAXIDMA_BD_CTRL_TXSOF_MASK 0x0800 /* First tx packet */ -#define XAXIDMA_BD_CTRL_TXEOF_MASK 0x0400 /* Last tx packet */ -#define XAXIDMA_BD_CTRL_ALL_MASK 0x0C00 /* All control bits */ - -#define XAXIDMA_BD_STS_ACTUAL_LEN_MASK 0x007F /* Actual len */ -#define XAXIDMA_BD_STS_COMPLETE_MASK 0x8000 /* Completed */ -#define XAXIDMA_BD_STS_DEC_ERR_MASK0x4000 /* Decode error */ -#define XAXIDMA_BD_STS_SLV_ERR_MASK0x200
Re: [PATCH v11 3/6] clk: ralink: add clock driver for mt7621 SoC
Quoting Sergio Paracuellos (2021-03-08 21:22:23)
> diff --git a/drivers/clk/ralink/Kconfig b/drivers/clk/ralink/Kconfig
> new file mode 100644
> index ..3e3f5cb9ad88
> --- /dev/null
> +++ b/drivers/clk/ralink/Kconfig
> @@ -0,0 +1,15 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +#
> +# MediaTek Mt7621 Clock Driver
> +#
> +menu "Clock driver for Mediatek mt7621 SoC"
> + depends on SOC_MT7621 || COMPILE_TEST
Do we need a menu and a config that says the same thing? Maybe the menu
can be dropped?
> +
> +config CLK_MT7621
> + bool "Clock driver for MediaTek MT7621"
> + depends on SOC_MT7621 || COMPILE_TEST
> + default SOC_MT7621
> + select MFD_SYSCON
> + help
> + This driver supports MediaTek MT7621 basic clocks.
> +endmenu
> diff --git a/drivers/clk/ralink/Makefile b/drivers/clk/ralink/Makefile
> new file mode 100644
> index ..cf6f9216379d
> --- /dev/null
> +++ b/drivers/clk/ralink/Makefile
> @@ -0,0 +1,2 @@
> +# SPDX-License-Identifier: GPL-2.0
> +obj-$(CONFIG_CLK_MT7621) += clk-mt7621.o
> diff --git a/drivers/clk/ralink/clk-mt7621.c b/drivers/clk/ralink/clk-mt7621.c
> new file mode 100644
> index ..6aea5accd51c
> --- /dev/null
> +++ b/drivers/clk/ralink/clk-mt7621.c
> @@ -0,0 +1,528 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Mediatek MT7621 Clock Driver
> + * Author: Sergio Paracuellos
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +/* Configuration registers */
> +#define SYSC_REG_SYSTEM_CONFIG0 0x10
> +#define SYSC_REG_SYSTEM_CONFIG1 0x14
> +#define SYSC_REG_CLKCFG0 0x2c
> +#define SYSC_REG_CLKCFG1 0x30
> +#define SYSC_REG_CUR_CLK_STS 0x44
> +#define MEMC_REG_CPU_PLL 0x648
> +
> +#define XTAL_MODE_SEL_MASK GENMASK(8, 6)
> +#define CPU_CLK_SEL_MASK GENMASK(31, 30)
> +#define CUR_CPU_FDIV_MASK GENMASK(12, 8)
> +#define CUR_CPU_FFRAC_MASK GENMASK(4, 0)
> +#define CPU_PLL_PREDIV_MASKGENMASK(13, 12)
> +#define CPU_PLL_FBDIV_MASK GENMASK(10, 4)
> +
> +struct mt7621_clk_priv {
> + struct regmap *sysc;
> + struct regmap *memc;
> +};
> +
> +struct mt7621_clk {
> + struct clk_hw hw;
> + struct mt7621_clk_priv *priv;
> +};
> +
> +struct mt7621_fixed_clk {
> + u8 idx;
> + const char *name;
> + const char *parent_name;
> + unsigned long rate;
> + struct clk_hw *hw;
> +};
> +
> +struct mt7621_gate {
> + u8 idx;
> + const char *name;
> + const char *parent_name;
> + struct mt7621_clk_priv *priv;
> + u32 bit_idx;
> + struct clk_hw hw;
> +};
> +
> +#define GATE(_id, _name, _pname, _shift) \
> + { \
> + .idx= _id, \
> + .name = _name,\
> + .parent_name= _pname, \
> + .bit_idx= _shift\
> + }
> +
> +static struct mt7621_gate mt7621_gates[] = {
> + GATE(MT7621_CLK_HSDMA, "hsdma", "150m", BIT(5)),
> + GATE(MT7621_CLK_FE, "fe", "250m", BIT(6)),
> + GATE(MT7621_CLK_SP_DIVTX, "sp_divtx", "270m", BIT(7)),
> + GATE(MT7621_CLK_TIMER, "timer", "50m", BIT(8)),
> + GATE(MT7621_CLK_PCM, "pcm", "270m", BIT(11)),
> + GATE(MT7621_CLK_PIO, "pio", "50m", BIT(13)),
> + GATE(MT7621_CLK_GDMA, "gdma", "bus", BIT(14)),
> + GATE(MT7621_CLK_NAND, "nand", "125m", BIT(15)),
> + GATE(MT7621_CLK_I2C, "i2c", "50m", BIT(16)),
> + GATE(MT7621_CLK_I2S, "i2s", "270m", BIT(17)),
> + GATE(MT7621_CLK_SPI, "spi", "bus", BIT(18)),
> + GATE(MT7621_CLK_UART1, "uart1", "50m", BIT(19)),
> + GATE(MT7621_CLK_UART2, "uart2", "50m", BIT(20)),
> + GATE(MT7621_CLK_UART3, "uart3", "50m", BIT(21)),
> + GATE(MT7621_CLK_ETH, "eth", "50m", BIT(23)),
> + GATE(MT7621_CLK_PCIE0, "pcie0", "125m", BIT(24)),
> + GATE(MT7621_CLK_PCIE1, "pcie1", "125m", BIT(25)),
> + GATE(MT7621_CLK_PCIE2, "pcie2", "125m", BIT(26)),
> + GATE(MT7621_CLK_CRYPTO, "crypto", "250m", BIT(29)),
> + GATE(MT7621_CLK_SHXC, "shxc", "50m", BIT(30))
> +};
> +
> +static inline struct mt7621_gate *to_mt7621_gate(struct clk_hw *hw)
> +{
> + return container_of(hw, struct mt7621_gate, hw);
> +}
> +
> +static int mt7621_gate_enable(struct clk_hw *hw)
> +{
> + struct mt7621_gate *clk_gate = to_mt7621_gate(hw);
> + struct regmap *sysc = clk_gate->priv->sysc;
> +
> + return regmap_update_bits(sysc, SYSC_REG_CLKCFG1,
> + clk_gate->bit_idx, clk_gate->bit_idx);
> +}
> +
> +static void mt7621_gate_disable(struct clk_hw *hw)
> +{
> + struct mt7621_gate *clk_gate = to_mt7621_gate(hw);
> + struct regmap *sysc = clk_gate->priv->sysc;
> +
> + regmap_update_bit
[RFC PATCH 2/3] dt-bindings: net: xilinx_axienet: Introduce dmaengine binding support
The axiethernet driver will now use dmaengine framework to communicate with dma controller IP instead of built-in dma programming sequence. To request dma transmit and receive channels the axiethernet driver uses generic dmas, dma-names properties. It deprecates axistream-connected property, remove axidma reg and interrupt properties from the ethernet node. Just to highlight that these DT changes are not backward compatible due to major driver restructuring/cleanup done in adopting the dmaengine framework. Signed-off-by: Radhey Shyam Pandey --- .../devicetree/bindings/net/xilinx_axienet.yaml| 40 +- 1 file changed, 24 insertions(+), 16 deletions(-) diff --git a/Documentation/devicetree/bindings/net/xilinx_axienet.yaml b/Documentation/devicetree/bindings/net/xilinx_axienet.yaml index 6a00e03e8804..0ea3972fefef 100644 --- a/Documentation/devicetree/bindings/net/xilinx_axienet.yaml +++ b/Documentation/devicetree/bindings/net/xilinx_axienet.yaml @@ -14,10 +14,8 @@ description: | offloading TX/RX checksum calculation off the processor. Management configuration is done through the AXI interface, while payload is - sent and received through means of an AXI DMA controller. This driver - includes the DMA driver code, so this driver is incompatible with AXI DMA - driver. - + sent and received through means of an AXI DMA controller using dmaengine + framework. allOf: - $ref: "ethernet-controller.yaml#" @@ -36,19 +34,13 @@ properties: reg: description: - Address and length of the IO space, as well as the address - and length of the AXI DMA controller IO space, unless - axistream-connected is specified, in which case the reg - attribute of the node referenced by it is used. -maxItems: 2 + Address and length of the IO space. +maxItems: 1 interrupts: description: - Can point to at most 3 interrupts. TX DMA, RX DMA, and optionally Ethernet - core. If axistream-connected is specified, the TX/RX DMA interrupts should - be on that node instead, and only the Ethernet core interrupt is optionally - specified here. -maxItems: 3 + Ethernet core interrupt. +maxItems: 1 phy-handle: true @@ -109,15 +101,29 @@ properties: for the AXI DMA controller used by this device. If this is specified, the DMA-related resources from that device (DMA registers and DMA TX/RX interrupts) rather than this one will be used. +deprecated: true mdio: true + dmas: +items: + - description: TX DMA Channel phandle and DMA request line number + - description: RX DMA Channel phandle and DMA request line number + + dma-names: +items: + - const: tx_chan0 + - const: rx_chan0 + + required: - compatible - reg - interrupts - xlnx,rxmem - phy-handle + - dmas + - dma-names additionalProperties: false @@ -127,11 +133,13 @@ examples: compatible = "xlnx,axi-ethernet-1.00.a"; device_type = "network"; interrupt-parent = <µblaze_0_axi_intc>; - interrupts = <2>, <0>, <1>; + interrupts = <1>; clock-names = "s_axi_lite_clk", "axis_clk", "ref_clk", "mgt_clk"; clocks = <&axi_clk>, <&axi_clk>, <&pl_enet_ref_clk>, <&mgt_clk>; phy-mode = "mii"; - reg = <0x40c0 0x4>,<0x50c0 0x4>; + reg = <0x40c0 0x4>; + dmas = <&xilinx_dma 0>, <&xilinx_dma 1>; + dma-names = "tx_chan0", "rx_chan0"; xlnx,rxcsum = <0x2>; xlnx,rxmem = <0x800>; xlnx,txcsum = <0x2>; -- 2.7.4
Re: [syzbot] BUG: spinlock bad magic in erofs_pcpubuf_growsize
Hi,
On Fri, Apr 09, 2021 at 10:59:15AM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:9c54130c Add linux-next specific files for 20210406
> git tree: linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=1654617ed0
> kernel config: https://syzkaller.appspot.com/x/.config?x=d125958c3995ddcd
> dashboard link: https://syzkaller.appspot.com/bug?extid=d6a0e4b80bd39f54c2f6
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=101a5786d0
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1147dd0ed0
>
> The issue was bisected to:
>
> commit 997acaf6b4b59c6a9c259740312a69ea549cc684
> Author: Mark Rutland
> Date: Mon Jan 11 15:37:07 2021 +
>
> lockdep: report broken irq restoration
>
> bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=11d8d7aad0
> final oops: https://syzkaller.appspot.com/x/report.txt?x=13d8d7aad0
> console output: https://syzkaller.appspot.com/x/log.txt?x=15d8d7aad0
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+d6a0e4b80bd39f54c...@syzkaller.appspotmail.com
> Fixes: 997acaf6b4b5 ("lockdep: report broken irq restoration")
>
> loop0: detected capacity change from 0 to 31
> BUG: spinlock bad magic on CPU#1, syz-executor062/8434
> lock: 0x8880b9c31d60, .magic: , .owner: /-1, .owner_cpu: 0
> CPU: 1 PID: 8434 Comm: syz-executor062 Not tainted
> 5.12.0-rc6-next-20210406-syzkaller #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
> __dump_stack lib/dump_stack.c:79 [inline]
> dump_stack+0x141/0x1d7 lib/dump_stack.c:120
> debug_spin_lock_before kernel/locking/spinlock_debug.c:83 [inline]
> do_raw_spin_lock+0x216/0x2b0 kernel/locking/spinlock_debug.c:112
> erofs_pcpubuf_growsize+0x36f/0x620 fs/erofs/pcpubuf.c:83
> z_erofs_load_lz4_config+0x1ef/0x3e0 fs/erofs/decompressor.c:64
> erofs_read_superblock fs/erofs/super.c:331 [inline]
> erofs_fc_fill_super+0xe84/0x1d10 fs/erofs/super.c:499
> get_tree_bdev+0x440/0x760 fs/super.c:1293
> vfs_get_tree+0x89/0x2f0 fs/super.c:1498
> do_new_mount fs/namespace.c:2905 [inline]
> path_mount+0x132a/0x1fa0 fs/namespace.c:3235
> do_mount fs/namespace.c:3248 [inline]
> __do_sys_mount fs/namespace.c:3456 [inline]
> __se_sys_mount fs/namespace.c:3433 [inline]
> __x64_sys_mount+0x27f/0x300 fs/namespace.c:3433
> do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
> entry_SYSCALL_64_after_hwframe+0x44/0xae
> RIP: 0033:0x444f7a
> Code: 83 c4 08 5b 5d c3 66 2e 0f 1f 84 00 00 00 00 00 c3 66 2e 0f 1f 84 00 00
> 00 00 00 0f 1f 44 00 00 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73
> 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48
> RSP: 002b:7ffe1fa3c2a8 EFLAGS: 0286 ORIG_RAX: 00a5
> RAX: ffda RBX: 7ffe1fa3c300 RCX: 00444f7a
> RDX: 2000 RSI: 2100 RDI: 7ffe1fa3c2c0
> RBP: 7ffe1fa3c2c0 R08: 7ffe1fa3c300 R09:
>
Thanks for the report. It's a spinlock uninitialization issue actually
due to the new patchset (bisect was wrong here), I will fix it up soon.
Thanks,
Gao Xiang
[RFC PATCH 1/3] dt-bindings: net: xilinx_axienet: convert bindings document to yaml
Convert the bindings document for Xilinx AXI Ethernet Subsystem
from txt to yaml. No changes to existing binding description.
Signed-off-by: Radhey Shyam Pandey
---
Pending: Fix below remaining dt_binding_check warning:
ethernet@40c0: 'device_type' does not match any of
the regexes: 'pinctrl-[0-9]+
---
.../devicetree/bindings/net/xilinx_axienet.txt | 80 ---
.../devicetree/bindings/net/xilinx_axienet.yaml| 147 +
MAINTAINERS| 1 +
3 files changed, 148 insertions(+), 80 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/net/xilinx_axienet.txt
create mode 100644 Documentation/devicetree/bindings/net/xilinx_axienet.yaml
diff --git a/Documentation/devicetree/bindings/net/xilinx_axienet.txt
b/Documentation/devicetree/bindings/net/xilinx_axienet.txt
deleted file mode 100644
index 2cd452419ed0..
--- a/Documentation/devicetree/bindings/net/xilinx_axienet.txt
+++ /dev/null
@@ -1,80 +0,0 @@
-XILINX AXI ETHERNET Device Tree Bindings
-
-
-Also called AXI 1G/2.5G Ethernet Subsystem, the xilinx axi ethernet IP core
-provides connectivity to an external ethernet PHY supporting different
-interfaces: MII, GMII, RGMII, SGMII, 1000BaseX. It also includes two
-segments of memory for buffering TX and RX, as well as the capability of
-offloading TX/RX checksum calculation off the processor.
-
-Management configuration is done through the AXI interface, while payload is
-sent and received through means of an AXI DMA controller. This driver
-includes the DMA driver code, so this driver is incompatible with AXI DMA
-driver.
-
-For more details about mdio please refer phy.txt file in the same directory.
-
-Required properties:
-- compatible : Must be one of "xlnx,axi-ethernet-1.00.a",
- "xlnx,axi-ethernet-1.01.a", "xlnx,axi-ethernet-2.01.a"
-- reg : Address and length of the IO space, as well as the address
- and length of the AXI DMA controller IO space, unless
- axistream-connected is specified, in which case the reg
- attribute of the node referenced by it is used.
-- interrupts : Should be a list of 2 or 3 interrupts: TX DMA, RX DMA,
- and optionally Ethernet core. If axistream-connected is
- specified, the TX/RX DMA interrupts should be on that node
- instead, and only the Ethernet core interrupt is optionally
- specified here.
-- phy-handle : Should point to the external phy device.
- See ethernet.txt file in the same directory.
-- xlnx,rxmem : Set to allocated memory buffer for Rx/Tx in the hardware
-
-Optional properties:
-- phy-mode : See ethernet.txt
-- xlnx,phy-type: Deprecated, do not use, but still accepted in
preference
- to phy-mode.
-- xlnx,txcsum : 0 or empty for disabling TX checksum offload,
- 1 to enable partial TX checksum offload,
- 2 to enable full TX checksum offload
-- xlnx,rxcsum : Same values as xlnx,txcsum but for RX checksum offload
-- xlnx,switch-x-sgmii : Boolean to indicate the Ethernet core is configured to
- support both 1000BaseX and SGMII modes. If set, the phy-mode
- should be set to match the mode selected on core reset (i.e.
- by the basex_or_sgmii core input line).
-- clocks : AXI bus clock for the device. Refer to common clock bindings.
- Used to calculate MDIO clock divisor. If not specified, it is
- auto-detected from the CPU clock (but only on platforms where
- this is possible). New device trees should specify this - the
- auto detection is only for backward compatibility.
-- axistream-connected: Reference to another node which contains the resources
- for the AXI DMA controller used by this device.
- If this is specified, the DMA-related resources from that
- device (DMA registers and DMA TX/RX interrupts) rather
- than this one will be used.
- - mdio: Child node for MDIO bus. Must be defined if PHY
access is
- required through the core's MDIO interface (i.e. always,
- unless the PHY is accessed through a different bus).
-
-Example:
- axi_ethernet_eth: ethernet@40c0 {
- compatible = "xlnx,axi-ethernet-1.00.a";
- device_type = "network";
- interrupt-parent = <µblaze_0_axi_intc>;
- interrupts = <2 0 1>;
- clocks = <&axi_clk>;
- phy-mode = "mii";
- reg = <0x40c0 0x4 0x50c0 0x4>;
- xlnx,rxcsum = <0x2>;
- xlnx,rxmem = <0x800>;
- xlnx,txcsum = <0x2>;
- phy-handle = <&phy0>;
[RFC PATCH 0/3] net: axienet: Introduce dmaengine support
The axiethernet driver now uses the dmaengine framework to communicate with the xilinx DMAengine driver(AXIDMA, MCDMA). The inspiration behind this dmaengine adoption is to reuse the in-kernel xilinx dma engine driver[1] and remove redundant dma programming sequence[2] from the ethernet driver. This simplifies the ethernet driver and also makes it generic to be hooked to any complaint dma IP i.e AXIDMA, MCDMA without any modification. This initial version is a proof of concept and validated with a ping test on an AXI ethernet subsystem 1G + xilinx AXI DMA design. There is an anticipated performance impact due to the adoption of the dmaengine framework. The plan is to revisit it once all required functional features are implemented. The dmaengine framework was extended for metadata API support during the axidma RFC[3] discussion. However, it still needs further enhancements to make it well suited for ethernet usecases. The ethernet features i.e ethtool set/get of DMA IP properties, ndo_poll_controller, trigger reset of DMA IP from ethernet are not supported (mentioned in TODO) and it requires follow-up discussion and dma framework enhancement. Comments, suggestions, thoughts to implement remaining functional features are very welcome! [1]: https://github.com/torvalds/linux/blob/master/drivers/dma/xilinx/xilinx_dma.c [2]: https://github.com/torvalds/linux/blob/master/drivers/net/ethernet/xilinx/xilinx_axienet_main.c#L238 [3]: http://lkml.iu.edu/hypermail/linux/kernel/1804.0/00367.html This series is based on dmaengine tree commit: #a38fd8748464 Radhey Shyam Pandey (3): dt-bindings: net: xilinx_axienet: convert bindings document to yaml dt-bindings: net: xilinx_axienet: Introduce dmaengine binding support net: axienet: Introduce dmaengine support .../devicetree/bindings/net/xilinx_axienet.txt | 80 -- .../devicetree/bindings/net/xilinx_axienet.yaml| 155 +++ MAINTAINERS|1 + drivers/net/ethernet/xilinx/xilinx_axienet.h | 141 +-- drivers/net/ethernet/xilinx/xilinx_axienet_main.c | 1050 5 files changed, 341 insertions(+), 1086 deletions(-) delete mode 100644 Documentation/devicetree/bindings/net/xilinx_axienet.txt create mode 100644 Documentation/devicetree/bindings/net/xilinx_axienet.yaml -- 2.7.4
RE: [Intel-wired-lan] [PATCH] i40e: The state of phy may not be correct during power-on
>-Original Message- >From: Intel-wired-lan On Behalf Of >xiao33...@qq.com >Sent: piątek, 9 kwietnia 2021 11:18 >To: Brandeburg, Jesse ; Nguyen, Anthony L > >Cc: net...@vger.kernel.org; xiaolinkui ; >linux-kernel@vger.kernel.org; intel-wired-...@lists.osuosl.org; >k...@kernel.org; da...@davemloft.net >Subject: [Intel-wired-lan] [PATCH] i40e: The state of phy may not be correct >during power-on > >From: xiaolinkui > >Sometimes the power on state of the x710 network card indicator is not right, >and the indicator shows orange. At this time, the network card speed is >Gigabit. By "power on state" you mean that it happens after power-up of the server? > >After entering the system, check the network card status through the ethtool >command as follows: > >[root@localhost ~]# ethtool enp132s0f0 >Settings for enp132s0f0: > Supported ports: [ FIBRE ] > Supported link modes: 1000baseX/Full > 1baseSR/Full > Supported pause frame use: Symmetric > Supports auto-negotiation: Yes > Supported FEC modes: Not reported > Advertised link modes: 1000baseX/Full > 1baseSR/Full > Advertised pause frame use: No > Advertised auto-negotiation: Yes > Advertised FEC modes: Not reported > Speed: 1000Mb/s > Duplex: Full > Port: FIBRE > PHYAD: 0 > Transceiver: internal > Auto-negotiation: off > Supports Wake-on: d > Wake-on: d > Current message level: 0x0007 (7) > drv probe link > Link detected: yes > >We can see that the speed is 1000Mb/s. > >If you unplug and plug in the optical cable, it can be restored to 10g. >After this operation, the rate is as follows: > >[root@localhost ~]# ethtool enp132s0f0 >Settings for enp132s0f0: >Supported ports: [ FIBRE ] >Supported link modes: 1000baseX/Full >1baseSR/Full >Supported pause frame use: Symmetric >Supports auto-negotiation: Yes >Supported FEC modes: Not reported >Advertised link modes: 1000baseX/Full >1baseSR/Full >Advertised pause frame use: No >Advertised auto-negotiation: Yes >Advertised FEC modes: Not reported >Speed: 1Mb/s >Duplex: Full >Port: FIBRE >PHYAD: 0 >Transceiver: internal >Auto-negotiation: off >Supports Wake-on: d >Wake-on: d >Current message level: 0x0007 (7) > drv probe link >Link detected: yes > >Calling i40e_aq_set_link_restart_an can also achieve this function. >So we need to do a reset operation for the network card when the network card >status is abnormal. Can't say much about the root cause of the issue right now, but I don't think it is good idea for the fix. This leads to braking existing link each time i40e_aq_get_link_info is called on 1 Gigabit PHY. For example 'ethtool -m ' does that. Have you tried reloading the driver? Thanks! > >Signed-off-by: xiaolinkui >--- > drivers/net/ethernet/intel/i40e/i40e_common.c | 4 > 1 file changed, 4 insertions(+) > >diff --git a/drivers/net/ethernet/intel/i40e/i40e_common.c >b/drivers/net/ethernet/intel/i40e/i40e_common.c >index ec19e18305ec..dde0224776ac 100644 >--- a/drivers/net/ethernet/intel/i40e/i40e_common.c >+++ b/drivers/net/ethernet/intel/i40e/i40e_common.c >@@ -1866,6 +1866,10 @@ i40e_status i40e_aq_get_link_info(struct i40e_hw *hw, > hw_link_info->max_frame_size = le16_to_cpu(resp->max_frame_size); > hw_link_info->pacing = resp->config & I40E_AQ_CONFIG_PACING_MASK; > >+ if (hw_link_info->phy_type == I40E_PHY_TYPE_1000BASE_SX && >+ hw->mac.type == I40E_MAC_XL710) >+ i40e_aq_set_link_restart_an(hw, true, NULL); >+ > /* update fc info */ > tx_pause = !!(resp->an_info & I40E_AQ_LINK_PAUSE_TX); > rx_pause = !!(resp->an_info & I40E_AQ_LINK_PAUSE_RX); >-- >2.17.1 > >___ >Intel-wired-lan mailing list >intel-wired-...@osuosl.org >https://lists.osuosl.org/mailman/listinfo/intel-wired-lan >
[RFC PATCH 2/2] iov_iter: Drop the X argument from iterate_all_kinds() and use B instead
Drop the X argument from iterate_all_kinds() and use the B argument instead
as it's always the same unless the ITER_XARRAY is handled specially.
Signed-off-by: David Howells
---
lib/iov_iter.c | 42 --
1 file changed, 12 insertions(+), 30 deletions(-)
diff --git a/lib/iov_iter.c b/lib/iov_iter.c
index 93e9838c128d..144abdac11db 100644
--- a/lib/iov_iter.c
+++ b/lib/iov_iter.c
@@ -79,8 +79,8 @@
#define iterate_xarray(i, n, __v, skip, STEP) {\
struct page *head = NULL; \
size_t wanted = n, seg, offset; \
- loff_t start = i->xarray_start + skip; \
- pgoff_t index = start >> PAGE_SHIFT;\
+ loff_t xarray_start = i->xarray_start + skip; \
+ pgoff_t index = xarray_start >> PAGE_SHIFT; \
int j; \
\
XA_STATE(xas, i->xarray, index);\
@@ -113,7 +113,7 @@
n = wanted - n; \
}
-#define iterate_all_kinds(i, n, v, I, B, K, X) { \
+#define iterate_all_kinds(i, n, v, I, B, K) { \
if (likely(n)) {\
size_t skip = i->iov_offset;\
if (unlikely(i->type & ITER_BVEC)) {\
@@ -127,7 +127,7 @@
} else if (unlikely(i->type & ITER_DISCARD)) { \
} else if (unlikely(i->type & ITER_XARRAY)) { \
struct bio_vec v; \
- iterate_xarray(i, n, v, skip, (X)); \
+ iterate_xarray(i, n, v, skip, (B)); \
} else {\
const struct iovec *iov;\
struct iovec v; \
@@ -842,9 +842,7 @@ bool _copy_from_iter_full(void *addr, size_t bytes, struct
iov_iter *i)
0;}),
memcpy_from_page((to += v.bv_len) - v.bv_len, v.bv_page,
v.bv_offset, v.bv_len),
- memcpy((to += v.iov_len) - v.iov_len, v.iov_base, v.iov_len),
- memcpy_from_page((to += v.bv_len) - v.bv_len, v.bv_page,
-v.bv_offset, v.bv_len)
+ memcpy((to += v.iov_len) - v.iov_len, v.iov_base, v.iov_len)
)
iov_iter_advance(i, bytes);
@@ -927,9 +925,7 @@ bool _copy_from_iter_full_nocache(void *addr, size_t bytes,
struct iov_iter *i)
0;}),
memcpy_from_page((to += v.bv_len) - v.bv_len, v.bv_page,
v.bv_offset, v.bv_len),
- memcpy((to += v.iov_len) - v.iov_len, v.iov_base, v.iov_len),
- memcpy_from_page((to += v.bv_len) - v.bv_len, v.bv_page,
-v.bv_offset, v.bv_len)
+ memcpy((to += v.iov_len) - v.iov_len, v.iov_base, v.iov_len)
)
iov_iter_advance(i, bytes);
@@ -1058,9 +1054,7 @@ size_t iov_iter_copy_from_user_atomic(struct page *page,
copyin((p += v.iov_len) - v.iov_len, v.iov_base, v.iov_len),
memcpy_from_page((p += v.bv_len) - v.bv_len, v.bv_page,
v.bv_offset, v.bv_len),
- memcpy((p += v.iov_len) - v.iov_len, v.iov_base, v.iov_len),
- memcpy_from_page((p += v.bv_len) - v.bv_len, v.bv_page,
-v.bv_offset, v.bv_len)
+ memcpy((p += v.iov_len) - v.iov_len, v.iov_base, v.iov_len)
)
kunmap_atomic(kaddr);
return bytes;
@@ -1349,8 +1343,7 @@ unsigned long iov_iter_alignment(const struct iov_iter *i)
iterate_all_kinds(i, size, v,
(res |= (unsigned long)v.iov_base | v.iov_len, 0),
res |= v.bv_offset | v.bv_len,
- res |= (unsigned long)v.iov_base | v.iov_len,
- res |= v.bv_offset | v.bv_len
+ res |= (unsigned long)v.iov_base | v.iov_len
)
return res;
}
@@ -1372,9 +1365,7 @@ unsigned long iov_iter_gap_alignment(const struct
iov_iter *i)
(res |= (!res ? 0 : (unsigned long)v.bv_offset) |
(size != v.bv_len ? size : 0)),
(res |= (!res ? 0 : (unsigned long)v.iov_base) |
- (size != v.iov_len ? size : 0)),
- (res |= (!res ? 0 : (unsigned long)v.bv_offset) |
- (size != v.bv_len ? size : 0))
+ (size != v.iov_len ? size : 0))
);
return res;
}
@@ -1530,8 +1521,7 @@ ssize_t iov_iter_get_pages(struct iov_iter *i,
return v.bv_len;
}),({
return -EFAULT;
-
[RFC PATCH 1/2] iov_iter: Remove iov_iter_for_each_range()
Remove iov_iter_for_each_range() as it's no longer used with the removal of
lustre.
Signed-off-by: David Howells
---
include/linux/uio.h |4
lib/iov_iter.c | 27 ---
2 files changed, 31 deletions(-)
diff --git a/include/linux/uio.h b/include/linux/uio.h
index 5f5ffc45d4aa..221c256304d4 100644
--- a/include/linux/uio.h
+++ b/include/linux/uio.h
@@ -295,8 +295,4 @@ ssize_t __import_iovec(int type, const struct iovec __user
*uvec,
int import_single_range(int type, void __user *buf, size_t len,
struct iovec *iov, struct iov_iter *i);
-int iov_iter_for_each_range(struct iov_iter *i, size_t bytes,
- int (*f)(struct kvec *vec, void *context),
- void *context);
-
#endif
diff --git a/lib/iov_iter.c b/lib/iov_iter.c
index f808c625c11e..93e9838c128d 100644
--- a/lib/iov_iter.c
+++ b/lib/iov_iter.c
@@ -2094,30 +2094,3 @@ int import_single_range(int rw, void __user *buf, size_t
len,
return 0;
}
EXPORT_SYMBOL(import_single_range);
-
-int iov_iter_for_each_range(struct iov_iter *i, size_t bytes,
- int (*f)(struct kvec *vec, void *context),
- void *context)
-{
- struct kvec w;
- int err = -EINVAL;
- if (!bytes)
- return 0;
-
- iterate_all_kinds(i, bytes, v, -EINVAL, ({
- w.iov_base = kmap(v.bv_page) + v.bv_offset;
- w.iov_len = v.bv_len;
- err = f(&w, context);
- kunmap(v.bv_page);
- err;}), ({
- w = v;
- err = f(&w, context);}), ({
- w.iov_base = kmap(v.bv_page) + v.bv_offset;
- w.iov_len = v.bv_len;
- err = f(&w, context);
- kunmap(v.bv_page);
- err;})
- )
- return err;
-}
-EXPORT_SYMBOL(iov_iter_for_each_range);
[PATCH v3 2/5] tracing: Add "last_func_repeats" to struct trace_array
The field is used to keep track of the consecutive (on the same CPU) calls
of a single function. This information is needed in order to consolidate
the function tracing record in the cases when a single function is called
number of times.
Signed-off-by: Yordan Karadzhov (VMware)
---
kernel/trace/trace.c | 1 +
kernel/trace/trace.h | 18 ++
2 files changed, 19 insertions(+)
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 507a30bf26e4..82833be07c1e 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -9104,6 +9104,7 @@ static int __remove_instance(struct trace_array *tr)
ftrace_clear_pids(tr);
ftrace_destroy_function_files(tr);
tracefs_remove(tr->dir);
+ free_percpu(tr->last_func_repeats);
free_trace_buffers(tr);
for (i = 0; i < tr->nr_topts; i++) {
diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
index 6a5b4c2a0fa7..1cd4da7ba769 100644
--- a/kernel/trace/trace.h
+++ b/kernel/trace/trace.h
@@ -262,6 +262,17 @@ struct cond_snapshot {
cond_update_fn_tupdate;
};
+/*
+ * struct trace_func_repeats - used to keep track of the consecutive
+ * (on the same CPU) calls of a single function.
+ */
+struct trace_func_repeats {
+ unsigned long ip;
+ unsigned long parent_ip;
+ unsigned long count;
+ u64 ts_last_call;
+};
+
/*
* The trace array - an array of per-CPU trace arrays. This is the
* highest level data structure that individual tracers deal with.
@@ -358,8 +369,15 @@ struct trace_array {
#ifdef CONFIG_TRACER_SNAPSHOT
struct cond_snapshot*cond_snapshot;
#endif
+ struct trace_func_repeats __percpu *last_func_repeats;
};
+static inline struct trace_func_repeats __percpu *
+tracer_alloc_func_repeats(struct trace_array *tr)
+{
+ return tr->last_func_repeats = alloc_percpu(struct trace_func_repeats);
+}
+
enum {
TRACE_ARRAY_FL_GLOBAL = (1 << 0)
};
--
2.25.1
[PATCH v3 3/5] tracing: Add method for recording "func_repeats" events
This patch only provides the implementation of the method.
Later we will used it in a combination with a new option for
function tracing.
Signed-off-by: Yordan Karadzhov (VMware)
---
kernel/trace/trace.c | 26 ++
kernel/trace/trace.h | 4
kernel/trace/trace_entries.h | 6 ++
3 files changed, 36 insertions(+)
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 82833be07c1e..bbc57cf3bda4 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -3117,6 +3117,32 @@ static void ftrace_trace_userstack(struct trace_array
*tr,
#endif /* CONFIG_STACKTRACE */
+void trace_last_func_repeats(struct trace_array *tr,
+struct trace_func_repeats *last_info,
+unsigned int trace_ctx)
+{
+ struct trace_buffer *buffer = tr->array_buffer.buffer;
+ struct func_repeats_entry *entry;
+ struct ring_buffer_event *event;
+ u64 delta;
+
+ event = __trace_buffer_lock_reserve(buffer, TRACE_FUNC_REPEATS,
+ sizeof(*entry), trace_ctx);
+ if (!event)
+ return;
+
+ delta = ring_buffer_event_time_stamp(buffer, event) -
+ last_info->ts_last_call;
+
+ entry = ring_buffer_event_data(event);
+ entry->ip = last_info->ip;
+ entry->parent_ip = last_info->parent_ip;
+ entry->count = last_info->count;
+ FUNC_REPEATS_SET_DELTA_TS(entry, delta)
+
+ __buffer_unlock_commit(buffer, event);
+}
+
/* created for use with alloc_percpu */
struct trace_buffer_struct {
int nesting;
diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
index 1cd4da7ba769..e1f34119c036 100644
--- a/kernel/trace/trace.h
+++ b/kernel/trace/trace.h
@@ -701,6 +701,10 @@ static inline void __trace_stack(struct trace_array *tr,
unsigned int trace_ctx,
}
#endif /* CONFIG_STACKTRACE */
+void trace_last_func_repeats(struct trace_array *tr,
+struct trace_func_repeats *last_info,
+unsigned int trace_ctx);
+
extern u64 ftrace_now(int cpu);
extern void trace_find_cmdline(int pid, char comm[]);
diff --git a/kernel/trace/trace_entries.h b/kernel/trace/trace_entries.h
index fdd022a7aecf..5e9dc56af4b1 100644
--- a/kernel/trace/trace_entries.h
+++ b/kernel/trace/trace_entries.h
@@ -342,6 +342,12 @@ FTRACE_ENTRY(hwlat, hwlat_entry,
#define FUNC_REPEATS_GET_DELTA_TS(entry) \
(((u64)entry->top_delta_ts << 32) | entry->bottom_delta_ts)\
+#define FUNC_REPEATS_SET_DELTA_TS(entry, delta)\
+ do {\
+ entry->bottom_delta_ts = delta & U32_MAX; \
+ entry->top_delta_ts = (delta >> 32);\
+ } while (0);\
+
FTRACE_ENTRY(func_repeats, func_repeats_entry,
TRACE_FUNC_REPEATS,
--
2.25.1
[PATCH v3 1/5] tracing: Define new ftrace event "func_repeats"
The event aims to consolidate the function tracing record in the cases
when a single function is called number of times consecutively.
while (cond)
do_func();
This may happen in various scenarios (busy waiting for example).
The new ftrace event can be used to show repeated function events with
a single event and save space on the ring buffer
Signed-off-by: Yordan Karadzhov (VMware)
---
kernel/trace/trace.h | 3 +++
kernel/trace/trace_entries.h | 22 +
kernel/trace/trace_output.c | 47
3 files changed, 72 insertions(+)
diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
index 5506424eae2a..6a5b4c2a0fa7 100644
--- a/kernel/trace/trace.h
+++ b/kernel/trace/trace.h
@@ -45,6 +45,7 @@ enum trace_type {
TRACE_BPUTS,
TRACE_HWLAT,
TRACE_RAW_DATA,
+ TRACE_FUNC_REPEATS,
__TRACE_LAST_TYPE,
};
@@ -442,6 +443,8 @@ extern void __ftrace_bad_type(void);
TRACE_GRAPH_ENT); \
IF_ASSIGN(var, ent, struct ftrace_graph_ret_entry, \
TRACE_GRAPH_RET); \
+ IF_ASSIGN(var, ent, struct func_repeats_entry, \
+ TRACE_FUNC_REPEATS); \
__ftrace_bad_type();\
} while (0)
diff --git a/kernel/trace/trace_entries.h b/kernel/trace/trace_entries.h
index 4547ac59da61..fdd022a7aecf 100644
--- a/kernel/trace/trace_entries.h
+++ b/kernel/trace/trace_entries.h
@@ -338,3 +338,25 @@ FTRACE_ENTRY(hwlat, hwlat_entry,
__entry->nmi_total_ts,
__entry->nmi_count)
);
+
+#define FUNC_REPEATS_GET_DELTA_TS(entry) \
+(((u64)entry->top_delta_ts << 32) | entry->bottom_delta_ts)\
+
+FTRACE_ENTRY(func_repeats, func_repeats_entry,
+
+ TRACE_FUNC_REPEATS,
+
+ F_STRUCT(
+ __field(unsigned long, ip )
+ __field(unsigned long, parent_ip )
+ __field(u16 , count )
+ __field(u16 , top_delta_ts)
+ __field(u32 , bottom_delta_ts )
+ ),
+
+ F_printk(" %ps <-%ps\t(repeats:%u delta_ts: -%llu)",
+(void *)__entry->ip,
+(void *)__entry->parent_ip,
+__entry->count,
+FUNC_REPEATS_GET_DELTA_TS(__entry))
+);
diff --git a/kernel/trace/trace_output.c b/kernel/trace/trace_output.c
index a0146e1fffdf..55b08e146afc 100644
--- a/kernel/trace/trace_output.c
+++ b/kernel/trace/trace_output.c
@@ -1373,6 +1373,52 @@ static struct trace_event trace_raw_data_event = {
.funcs = &trace_raw_data_funcs,
};
+static enum print_line_t
+trace_func_repeats_raw(struct trace_iterator *iter, int flags,
+struct trace_event *event)
+{
+ struct func_repeats_entry *field;
+ struct trace_seq *s = &iter->seq;
+
+ trace_assign_type(field, iter->ent);
+
+ trace_seq_printf(s, "%lu %lu %u %llu\n",
+field->ip,
+field->parent_ip,
+field->count,
+FUNC_REPEATS_GET_DELTA_TS(field));
+
+ return trace_handle_return(s);
+}
+
+static enum print_line_t
+trace_func_repeats_print(struct trace_iterator *iter, int flags,
+struct trace_event *event)
+{
+ struct func_repeats_entry *field;
+ struct trace_seq *s = &iter->seq;
+
+ trace_assign_type(field, iter->ent);
+
+ seq_print_ip_sym(s, field->ip, flags);
+ trace_seq_puts(s, " <-");
+ seq_print_ip_sym(s, field->parent_ip, flags);
+ trace_seq_printf(s, " (repeats: %u, delta_ts: -%llu)\n",
+field->count,
+FUNC_REPEATS_GET_DELTA_TS(field));
+
+ return trace_handle_return(s);
+}
+
+static struct trace_event_functions trace_func_repeats_funcs = {
+ .trace = trace_func_repeats_print,
+ .raw= trace_func_repeats_raw,
+};
+
+static struct trace_event trace_func_repeats_event = {
+ .type = TRACE_FUNC_REPEATS,
+ .funcs = &trace_func_repeats_funcs,
+};
static struct trace_event *events[] __initdata = {
&trace_fn_event,
@@ -1385,6 +1431,7 @@ static struct trace_event *events[] __initdata = {
&trace_print_event,
&trace_hwlat_event,
&trace_raw_data_event,
+ &trace_func_repeats_event,
NULL
};
--
2.25.1
[PATCH v3 5/5] tracing: Add "func_no_repeats" option for function tracing
If the option is activated the function tracing record gets
consolidated in the cases when a single function is called number
of times consecutively. Instead of having an identical record for
each call of the function we will record only the first call
following by event showing the number of repeats.
Signed-off-by: Yordan Karadzhov (VMware)
---
kernel/trace/trace_functions.c | 161 -
1 file changed, 158 insertions(+), 3 deletions(-)
diff --git a/kernel/trace/trace_functions.c b/kernel/trace/trace_functions.c
index f37f73a9b1b8..9a3cbdbfd1f7 100644
--- a/kernel/trace/trace_functions.c
+++ b/kernel/trace/trace_functions.c
@@ -27,15 +27,27 @@ function_trace_call(unsigned long ip, unsigned long
parent_ip,
static void
function_stack_trace_call(unsigned long ip, unsigned long parent_ip,
struct ftrace_ops *op, struct ftrace_regs *fregs);
+static void
+function_no_repeats_trace_call(unsigned long ip, unsigned long parent_ip,
+ struct ftrace_ops *op, struct ftrace_regs
*fregs);
+static void
+function_stack_no_repeats_trace_call(unsigned long ip, unsigned long parent_ip,
+struct ftrace_ops *op,
+struct ftrace_regs *fregs);
static struct tracer_flags func_flags;
/* Our option */
enum {
- TRACE_FUNC_NO_OPTS = 0x0, /* No flags set. */
- TRACE_FUNC_OPT_STACK= 0x1,
+
+ TRACE_FUNC_NO_OPTS = 0x0, /* No flags set. */
+ TRACE_FUNC_OPT_STACK= 0x1,
+ TRACE_FUNC_OPT_NO_REPEATS = 0x2,
+
+ /* Update this to next highest bit. */
+ TRACE_FUNC_OPT_HIGHEST_BIT = 0x4
};
-#define TRACE_FUNC_OPT_MASK(TRACE_FUNC_OPT_STACK)
+#define TRACE_FUNC_OPT_MASK(TRACE_FUNC_OPT_HIGHEST_BIT - 1)
int ftrace_allocate_ftrace_ops(struct trace_array *tr)
{
@@ -96,11 +108,26 @@ static ftrace_func_t select_trace_function(u32 flags_val)
return function_trace_call;
case TRACE_FUNC_OPT_STACK:
return function_stack_trace_call;
+ case TRACE_FUNC_OPT_NO_REPEATS:
+ return function_no_repeats_trace_call;
+ case TRACE_FUNC_OPT_STACK | TRACE_FUNC_OPT_NO_REPEATS:
+ return function_stack_no_repeats_trace_call;
default:
return NULL;
}
}
+static bool handle_func_repeats(struct trace_array *tr, u32 flags_val)
+{
+ if (!tr->last_func_repeats &&
+ (flags_val & TRACE_FUNC_OPT_NO_REPEATS)) {
+ if (!tracer_alloc_func_repeats(tr))
+ return false;
+ }
+
+ return true;
+}
+
static int function_trace_init(struct trace_array *tr)
{
ftrace_func_t func;
@@ -116,6 +143,9 @@ static int function_trace_init(struct trace_array *tr)
if (!func)
return -EINVAL;
+ if (!handle_func_repeats(tr, func_flags.val))
+ return -ENOMEM;
+
ftrace_init_array_ops(tr, func);
tr->array_buffer.cpu = raw_smp_processor_id();
@@ -217,10 +247,132 @@ function_stack_trace_call(unsigned long ip, unsigned
long parent_ip,
local_irq_restore(flags);
}
+static inline bool is_repeat_check(struct trace_array *tr,
+ struct trace_func_repeats *last_info,
+ unsigned long ip, unsigned long parent_ip)
+{
+ if (last_info->ip == ip &&
+ last_info->parent_ip == parent_ip &&
+ last_info->count < U16_MAX) {
+ last_info->ts_last_call =
+ ring_buffer_time_stamp(tr->array_buffer.buffer);
+ last_info->count++;
+ return true;
+ }
+
+ return false;
+}
+
+static inline void process_repeats(struct trace_array *tr,
+ unsigned long ip, unsigned long parent_ip,
+ struct trace_func_repeats *last_info,
+ unsigned int trace_ctx)
+{
+ if (last_info->count) {
+ trace_last_func_repeats(tr, last_info, trace_ctx);
+ last_info->count = 0;
+ }
+
+ last_info->ip = ip;
+ last_info->parent_ip = parent_ip;
+}
+
+static void
+function_no_repeats_trace_call(unsigned long ip, unsigned long parent_ip,
+ struct ftrace_ops *op,
+ struct ftrace_regs *fregs)
+{
+ struct trace_func_repeats *last_info;
+ struct trace_array *tr = op->private;
+ struct trace_array_cpu *data;
+ unsigned int trace_ctx;
+ unsigned long flags;
+ int bit;
+ int cpu;
+
+ if (unlikely(!tr->function_enabled))
+ return;
+
+ bit = ftrace_test_recursion_trylock(ip, parent_ip);
+ if (bit < 0)
+ return;
+
+ preempt_disable_notrace();
+
+ cpu = smp_processor_id();
+ data = per_cpu_ptr(tr->array_
[PATCH v3 4/5] tracing: Unify the logic for function tracing options
Currently the logic for dealing with the options for function tracing
has two different implementations. One is used when we set the flags
(in "static int func_set_flag()") and another used when we initialize
the tracer (in "static int function_trace_init()"). Those two
implementations are meant to do essentially the same thing and they
are both not very convenient for adding new options. In this patch
we add a helper function that provides a single implementation of
the logic for dealing with the options and we make it such that new
options can be easily added.
Signed-off-by: Yordan Karadzhov (VMware)
---
kernel/trace/trace_functions.c | 65 --
1 file changed, 38 insertions(+), 27 deletions(-)
diff --git a/kernel/trace/trace_functions.c b/kernel/trace/trace_functions.c
index f93723ca66bc..f37f73a9b1b8 100644
--- a/kernel/trace/trace_functions.c
+++ b/kernel/trace/trace_functions.c
@@ -31,9 +31,12 @@ static struct tracer_flags func_flags;
/* Our option */
enum {
+ TRACE_FUNC_NO_OPTS = 0x0, /* No flags set. */
TRACE_FUNC_OPT_STACK= 0x1,
};
+#define TRACE_FUNC_OPT_MASK(TRACE_FUNC_OPT_STACK)
+
int ftrace_allocate_ftrace_ops(struct trace_array *tr)
{
struct ftrace_ops *ops;
@@ -86,6 +89,18 @@ void ftrace_destroy_function_files(struct trace_array *tr)
ftrace_free_ftrace_ops(tr);
}
+static ftrace_func_t select_trace_function(u32 flags_val)
+{
+ switch (flags_val & TRACE_FUNC_OPT_MASK) {
+ case TRACE_FUNC_NO_OPTS:
+ return function_trace_call;
+ case TRACE_FUNC_OPT_STACK:
+ return function_stack_trace_call;
+ default:
+ return NULL;
+ }
+}
+
static int function_trace_init(struct trace_array *tr)
{
ftrace_func_t func;
@@ -97,12 +112,9 @@ static int function_trace_init(struct trace_array *tr)
if (!tr->ops)
return -ENOMEM;
- /* Currently only the global instance can do stack tracing */
- if (tr->flags & TRACE_ARRAY_FL_GLOBAL &&
- func_flags.val & TRACE_FUNC_OPT_STACK)
- func = function_stack_trace_call;
- else
- func = function_trace_call;
+ func = select_trace_function(func_flags.val);
+ if (!func)
+ return -EINVAL;
ftrace_init_array_ops(tr, func);
@@ -213,7 +225,7 @@ static struct tracer_opt func_opts[] = {
};
static struct tracer_flags func_flags = {
- .val = 0, /* By default: all flags disabled */
+ .val = TRACE_FUNC_NO_OPTS, /* By default: all flags disabled */
.opts = func_opts
};
@@ -235,30 +247,29 @@ static struct tracer function_trace;
static int
func_set_flag(struct trace_array *tr, u32 old_flags, u32 bit, int set)
{
- switch (bit) {
- case TRACE_FUNC_OPT_STACK:
- /* do nothing if already set */
- if (!!set == !!(func_flags.val & TRACE_FUNC_OPT_STACK))
- break;
-
- /* We can change this flag when not running. */
- if (tr->current_trace != &function_trace)
- break;
+ ftrace_func_t func;
+ u32 new_flags;
- unregister_ftrace_function(tr->ops);
+ /* Do nothing if already set. */
+ if (!!set == !!(func_flags.val & bit))
+ return 0;
- if (set) {
- tr->ops->func = function_stack_trace_call;
- register_ftrace_function(tr->ops);
- } else {
- tr->ops->func = function_trace_call;
- register_ftrace_function(tr->ops);
- }
+ /* We can change this flag only when not running. */
+ if (tr->current_trace != &function_trace)
+ return 0;
- break;
- default:
+ new_flags = (func_flags.val & ~bit) | (set ? bit : 0);
+ func = select_trace_function(new_flags);
+ if (!func)
return -EINVAL;
- }
+
+ /* Check if there's anything to change. */
+ if (tr->ops->func == func)
+ return 0;
+
+ unregister_ftrace_function(tr->ops);
+ tr->ops->func = func;
+ register_ftrace_function(tr->ops);
return 0;
}
--
2.25.1
[PATCH v3 0/5] Add "func_no_repete" tracing option
The new option for function tracing aims to save space on the ring buffer and to make it more readable in the case when a single function is called number of times consecutively: while (cond) do_func(); Instead of having an identical records for each call of the function we will record only the first call, followed by an event showing the number of repeats. v3 changes: * FUNC_REPEATS_SET_DELTA_TS macro has been optimised. * Fixed bug in func_set_flag(): In the previous version the value of the "new_flags" variable was not properly calculated because I misinterpreted the meaning of the "bit" argument of the function. This bug in v2 had no real effect, because for the moment we have only two "function options" so the value of "new_flags" was correct, although its way of calculating was wrong. v2 changes: * As suggested by Steven in his review, we now record not only the repetition count, but also the time elapsed between the last repetition of the function and the actual generation of the "func_repeats" event. 16 bits are used to record the repetition count. In the case of an overflow of the counter a second pair of "function" and "func_repeats" events will be generated. The time interval gets codded by using up to 48 (32 + 16) bits. Yordan Karadzhov (VMware) (5): tracing: Define new ftrace event "func_repeats" tracing: Add "last_func_repeats" to struct trace_array tracing: Add method for recording "func_repeats" events tracing: Unify the logic for function tracing options tracing: Add "func_no_repeats" option for function tracing kernel/trace/trace.c | 27 kernel/trace/trace.h | 25 kernel/trace/trace_entries.h | 28 + kernel/trace/trace_functions.c | 222 - kernel/trace/trace_output.c| 47 +++ 5 files changed, 321 insertions(+), 28 deletions(-) -- 2.25.1
Re: [PATCH 5.10 00/41] 5.10.29-rc1 review
On 4/9/2021 2:53 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 5.10.29 release. > There are 41 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sun, 11 Apr 2021 09:52:52 +. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.29-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-5.10.y > and the diffstat can be found below. > > thanks, > > greg k-h On ARCH_BRCMSTB, using 32-bit and 64-bit kernels: Tested-by: Florian Fainelli -- Florian
Re: [PATCH 1/8] dt-bindings: clock: Add MT8192 APU clock bindings
On Wed, 07 Apr 2021 11:27:59 +0800, Flora Fu wrote: > Add clock bindings for APU on MT8192. > > Signed-off-by: Flora Fu > --- > include/dt-bindings/clock/mt8192-clk.h | 14 -- > 1 file changed, 12 insertions(+), 2 deletions(-) > Acked-by: Rob Herring
Re: [PATCH v1 2/2] dt-bindings: pwm: add more compatible strings to pwm-rockchip.yaml
On Tue, 06 Apr 2021 17:50:53 +0200, Johan Jonker wrote: > The compatible strings below are already in use in the Rockchip > dtsi files, but were somehow never added to a document, so add > > "rockchip,rk3328-pwm" > > "rockchip,rk3036-pwm", "rockchip,rk2928-pwm" > > "rockchip,rk3368-pwm", "rockchip,rk3288-pwm" > "rockchip,rk3399-pwm", "rockchip,rk3288-pwm" > > "rockchip,px30-pwm", "rockchip,rk3328-pwm" > "rockchip,rk3308-pwm", "rockchip,rk3328-pwm" > > for pwm nodes to pwm-rockchip.yaml. > > Signed-off-by: Johan Jonker > --- > Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml | 11 +++ > 1 file changed, 11 insertions(+) > Reviewed-by: Rob Herring
Re: [PATCH v1 1/2] dt-bindings: pwm: convert pwm-rockchip.txt to YAML
On Tue, Apr 06, 2021 at 09:04:29PM +0200, Johan Jonker wrote: > Hi, > > Question for Heiko: > rv1108.dtsi and rk3328.dtsi have a undocumented "interrupts" property > AFAICT without driver support. > Please advise what to do with it. > > > See build log: > https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20210406155053.29101-1-jbx6...@gmail.com/ > > > > Question for Rob: > It looks like that recent "improvements" with regard to checking for > undocumented compatible strings make it almost impossible to do any > useful dt_checking, let alone for the average user. Maybe reduce the > notification blurb output a bit for things that have nothing to do with > this document. It's off by default for dt_binding_check until the 80 or so warnings are killed. It's on for the PW checks so new ones don't get added. It's also off for dtbs_check if you set DT_SCHEMA_FILES. > Unable to fall back to previous versions for older kernels. Sorry, don't understand this sentence. > > pip3 install git+https://github.com/devicetree-org/dt-schema.git@master > --upgrade > > make ARCH=arm dtbs_check > make ARCH=arm dtbs_check > DT_SCHEMA_FILES=Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml > > make ARCH=arm64 dtbs_check > make ARCH=arm64 dtbs_check > DT_SCHEMA_FILES=Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml
[PATCH net-next 5/7] net: ipa: get rid of empty IPA functions
There are place holder functions in the IPA code that do nothing.
For the most part these are inverse functions, for example, once the
routing or filter tables are set up there is no need to perform any
matching teardown activity at shutdown, or in the case of an error.
These can be safely removed, resulting in some code simplification.
Add comments in these spots making it explicit that there is no
inverse.
Signed-off-by: Alex Elder
---
drivers/net/ipa/ipa_main.c | 29 +
drivers/net/ipa/ipa_mem.c | 9 +++--
drivers/net/ipa/ipa_mem.h | 5 ++---
drivers/net/ipa/ipa_resource.c | 8 +---
drivers/net/ipa/ipa_resource.h | 8 ++--
drivers/net/ipa/ipa_table.c| 26 +++---
drivers/net/ipa/ipa_table.h| 16
7 files changed, 24 insertions(+), 77 deletions(-)
diff --git a/drivers/net/ipa/ipa_main.c b/drivers/net/ipa/ipa_main.c
index a970d10e650ef..bfed151f5d6dc 100644
--- a/drivers/net/ipa/ipa_main.c
+++ b/drivers/net/ipa/ipa_main.c
@@ -147,13 +147,13 @@ int ipa_setup(struct ipa *ipa)
if (ret)
goto err_endpoint_teardown;
- ret = ipa_mem_setup(ipa);
+ ret = ipa_mem_setup(ipa); /* No matching teardown required */
if (ret)
goto err_command_disable;
- ret = ipa_table_setup(ipa);
+ ret = ipa_table_setup(ipa); /* No matching teardown required */
if (ret)
- goto err_mem_teardown;
+ goto err_command_disable;
/* Enable the exception handling endpoint, and tell the hardware
* to use it by default.
@@ -161,7 +161,7 @@ int ipa_setup(struct ipa *ipa)
exception_endpoint = ipa->name_map[IPA_ENDPOINT_AP_LAN_RX];
ret = ipa_endpoint_enable_one(exception_endpoint);
if (ret)
- goto err_table_teardown;
+ goto err_command_disable;
ipa_endpoint_default_route_set(ipa, exception_endpoint->endpoint_id);
@@ -179,10 +179,6 @@ int ipa_setup(struct ipa *ipa)
err_default_route_clear:
ipa_endpoint_default_route_clear(ipa);
ipa_endpoint_disable_one(exception_endpoint);
-err_table_teardown:
- ipa_table_teardown(ipa);
-err_mem_teardown:
- ipa_mem_teardown(ipa);
err_command_disable:
ipa_endpoint_disable_one(command_endpoint);
err_endpoint_teardown:
@@ -211,8 +207,6 @@ static void ipa_teardown(struct ipa *ipa)
ipa_endpoint_default_route_clear(ipa);
exception_endpoint = ipa->name_map[IPA_ENDPOINT_AP_LAN_RX];
ipa_endpoint_disable_one(exception_endpoint);
- ipa_table_teardown(ipa);
- ipa_mem_teardown(ipa);
command_endpoint = ipa->name_map[IPA_ENDPOINT_AP_COMMAND_TX];
ipa_endpoint_disable_one(command_endpoint);
ipa_endpoint_teardown(ipa);
@@ -480,23 +474,20 @@ static int ipa_config(struct ipa *ipa, const struct
ipa_data *data)
if (ret)
goto err_endpoint_deconfig;
- ipa_table_config(ipa);
+ ipa_table_config(ipa); /* No deconfig required */
- /* Assign resource limitation to each group */
+ /* Assign resource limitation to each group; no deconfig required */
ret = ipa_resource_config(ipa, data->resource_data);
if (ret)
- goto err_table_deconfig;
+ goto err_mem_deconfig;
ret = ipa_modem_config(ipa);
if (ret)
- goto err_resource_deconfig;
+ goto err_mem_deconfig;
return 0;
-err_resource_deconfig:
- ipa_resource_deconfig(ipa);
-err_table_deconfig:
- ipa_table_deconfig(ipa);
+err_mem_deconfig:
ipa_mem_deconfig(ipa);
err_endpoint_deconfig:
ipa_endpoint_deconfig(ipa);
@@ -514,8 +505,6 @@ static int ipa_config(struct ipa *ipa, const struct
ipa_data *data)
static void ipa_deconfig(struct ipa *ipa)
{
ipa_modem_deconfig(ipa);
- ipa_resource_deconfig(ipa);
- ipa_table_deconfig(ipa);
ipa_mem_deconfig(ipa);
ipa_endpoint_deconfig(ipa);
ipa_hardware_deconfig(ipa);
diff --git a/drivers/net/ipa/ipa_mem.c b/drivers/net/ipa/ipa_mem.c
index 32907dde5dc6a..c5c3b1b7e67d5 100644
--- a/drivers/net/ipa/ipa_mem.c
+++ b/drivers/net/ipa/ipa_mem.c
@@ -1,7 +1,7 @@
// SPDX-License-Identifier: GPL-2.0
/* Copyright (c) 2012-2018, The Linux Foundation. All rights reserved.
- * Copyright (C) 2019-2020 Linaro Ltd.
+ * Copyright (C) 2019-2021 Linaro Ltd.
*/
#include
@@ -53,6 +53,8 @@ ipa_mem_zero_region_add(struct gsi_trans *trans, const struct
ipa_mem *mem)
* The AP informs the modem where its portions of memory are located
* in a QMI exchange that occurs at modem startup.
*
+ * There is no need for a matching ipa_mem_teardown() function.
+ *
* Return: 0 if successful, or a negative error code
*/
int ipa_mem_setup(struct ipa *ipa)
@@ -97,11 +99,6 @@ int ipa_mem_setup(struct ipa *ipa)
return 0;
}
-void ipa_mem_teardown(st
[PATCH net-next 7/7] net: ipa: three small fixes
Some time ago changes were made to stop referring to clearing the
hardware pipeline as a "tag process." Fix a comment to use the
newer terminology.
Get rid of a pointless double-negation of the Boolean toward_ipa
flag in ipa_endpoint_config().
make ipa_endpoint_exit_one() private; it's only referenced inside
"ipa_endpoint.c".
Signed-off-by: Alex Elder
---
drivers/net/ipa/ipa_endpoint.c | 6 +++---
drivers/net/ipa/ipa_endpoint.h | 2 --
2 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ipa/ipa_endpoint.c b/drivers/net/ipa/ipa_endpoint.c
index dd24179383c1c..72751843b2e48 100644
--- a/drivers/net/ipa/ipa_endpoint.c
+++ b/drivers/net/ipa/ipa_endpoint.c
@@ -397,7 +397,7 @@ int ipa_endpoint_modem_exception_reset_all(struct ipa *ipa)
/* We need one command per modem TX endpoint. We can get an upper
* bound on that by assuming all initialized endpoints are modem->IPA.
* That won't happen, and we could be more precise, but this is fine
-* for now. We need to end the transaction with a "tag process."
+* for now. End the transaction with commands to clear the pipeline.
*/
count = hweight32(initialized) + ipa_cmd_pipeline_clear_count();
trans = ipa_cmd_trans_alloc(ipa, count);
@@ -1755,7 +1755,7 @@ int ipa_endpoint_config(struct ipa *ipa)
/* Make sure it's pointing in the right direction */
endpoint = &ipa->endpoint[endpoint_id];
- if ((endpoint_id < rx_base) != !!endpoint->toward_ipa) {
+ if ((endpoint_id < rx_base) != endpoint->toward_ipa) {
dev_err(dev, "endpoint id %u wrong direction\n",
endpoint_id);
ret = -EINVAL;
@@ -1791,7 +1791,7 @@ static void ipa_endpoint_init_one(struct ipa *ipa, enum
ipa_endpoint_name name,
ipa->initialized |= BIT(endpoint->endpoint_id);
}
-void ipa_endpoint_exit_one(struct ipa_endpoint *endpoint)
+static void ipa_endpoint_exit_one(struct ipa_endpoint *endpoint)
{
endpoint->ipa->initialized &= ~BIT(endpoint->endpoint_id);
diff --git a/drivers/net/ipa/ipa_endpoint.h b/drivers/net/ipa/ipa_endpoint.h
index f034a9e6ef215..0a859d10312dc 100644
--- a/drivers/net/ipa/ipa_endpoint.h
+++ b/drivers/net/ipa/ipa_endpoint.h
@@ -87,8 +87,6 @@ int ipa_endpoint_modem_exception_reset_all(struct ipa *ipa);
int ipa_endpoint_skb_tx(struct ipa_endpoint *endpoint, struct sk_buff *skb);
-void ipa_endpoint_exit_one(struct ipa_endpoint *endpoint);
-
int ipa_endpoint_enable_one(struct ipa_endpoint *endpoint);
void ipa_endpoint_disable_one(struct ipa_endpoint *endpoint);
--
2.27.0
[PATCH net-next 6/7] net: ipa: get rid of empty GSI functions
There are place holder functions in the GSI code that do nothing.
Remove these, knowing we can add something back in their place if
they're really needed someday.
Some of these are inverse functions (such as teardown to match setup).
Explicitly comment that there is no inverse in these cases.
Signed-off-by: Alex Elder
---
drivers/net/ipa/gsi.c | 54 +--
1 file changed, 6 insertions(+), 48 deletions(-)
diff --git a/drivers/net/ipa/gsi.c b/drivers/net/ipa/gsi.c
index 1c835b3e1a437..9f06663cef263 100644
--- a/drivers/net/ipa/gsi.c
+++ b/drivers/net/ipa/gsi.c
@@ -198,7 +198,7 @@ static void gsi_irq_type_disable(struct gsi *gsi, enum
gsi_irq_type_id type_id)
gsi_irq_type_update(gsi, gsi->type_enabled_bitmap & ~BIT(type_id));
}
-/* Turn off all GSI interrupts initially */
+/* Turn off all GSI interrupts initially; there is no gsi_irq_teardown() */
static void gsi_irq_setup(struct gsi *gsi)
{
/* Disable all interrupt types */
@@ -217,12 +217,6 @@ static void gsi_irq_setup(struct gsi *gsi)
iowrite32(0, gsi->virt + GSI_CNTXT_GSI_IRQ_EN_OFFSET);
}
-/* Turn off all GSI interrupts when we're all done */
-static void gsi_irq_teardown(struct gsi *gsi)
-{
- /* Nothing to do */
-}
-
/* Event ring commands are performed one at a time. Their completion
* is signaled by the event ring control GSI interrupt type, which is
* only enabled when we issue an event ring command. Only the event
@@ -786,7 +780,7 @@ static void gsi_channel_trans_quiesce(struct gsi_channel
*channel)
}
}
-/* Program a channel for use */
+/* Program a channel for use; there is no gsi_channel_deprogram() */
static void gsi_channel_program(struct gsi_channel *channel, bool doorbell)
{
size_t size = channel->tre_ring.count * GSI_RING_ELEMENT_SIZE;
@@ -874,11 +868,6 @@ static void gsi_channel_program(struct gsi_channel
*channel, bool doorbell)
/* All done! */
}
-static void gsi_channel_deprogram(struct gsi_channel *channel)
-{
- /* Nothing to do */
-}
-
static int __gsi_channel_start(struct gsi_channel *channel, bool start)
{
struct gsi *gsi = channel->gsi;
@@ -1623,18 +1612,6 @@ static u32 gsi_event_bitmap_init(u32 evt_ring_max)
return event_bitmap;
}
-/* Setup function for event rings */
-static void gsi_evt_ring_setup(struct gsi *gsi)
-{
- /* Nothing to do */
-}
-
-/* Inverse of gsi_evt_ring_setup() */
-static void gsi_evt_ring_teardown(struct gsi *gsi)
-{
- /* Nothing to do */
-}
-
/* Setup function for a single channel */
static int gsi_channel_setup_one(struct gsi *gsi, u32 channel_id)
{
@@ -1684,7 +1661,6 @@ static void gsi_channel_teardown_one(struct gsi *gsi, u32
channel_id)
netif_napi_del(&channel->napi);
- gsi_channel_deprogram(channel);
gsi_channel_de_alloc_command(gsi, channel_id);
gsi_evt_ring_reset_command(gsi, evt_ring_id);
gsi_evt_ring_de_alloc_command(gsi, evt_ring_id);
@@ -1759,7 +1735,6 @@ static int gsi_channel_setup(struct gsi *gsi)
u32 mask;
int ret;
- gsi_evt_ring_setup(gsi);
gsi_irq_enable(gsi);
mutex_lock(&gsi->mutex);
@@ -1819,7 +1794,6 @@ static int gsi_channel_setup(struct gsi *gsi)
mutex_unlock(&gsi->mutex);
gsi_irq_disable(gsi);
- gsi_evt_ring_teardown(gsi);
return ret;
}
@@ -1848,7 +1822,6 @@ static void gsi_channel_teardown(struct gsi *gsi)
mutex_unlock(&gsi->mutex);
gsi_irq_disable(gsi);
- gsi_evt_ring_teardown(gsi);
}
/* Setup function for GSI. GSI firmware must be loaded and initialized */
@@ -1856,7 +1829,6 @@ int gsi_setup(struct gsi *gsi)
{
struct device *dev = gsi->dev;
u32 val;
- int ret;
/* Here is where we first touch the GSI hardware */
val = ioread32(gsi->virt + GSI_GSI_STATUS_OFFSET);
@@ -1865,7 +1837,7 @@ int gsi_setup(struct gsi *gsi)
return -EIO;
}
- gsi_irq_setup(gsi);
+ gsi_irq_setup(gsi); /* No matching teardown required */
val = ioread32(gsi->virt + GSI_GSI_HW_PARAM_2_OFFSET);
@@ -1899,18 +1871,13 @@ int gsi_setup(struct gsi *gsi)
/* Writing 1 indicates IRQ interrupts; 0 would be MSI */
iowrite32(1, gsi->virt + GSI_CNTXT_INTSET_OFFSET);
- ret = gsi_channel_setup(gsi);
- if (ret)
- gsi_irq_teardown(gsi);
-
- return ret;
+ return gsi_channel_setup(gsi);
}
/* Inverse of gsi_setup() */
void gsi_teardown(struct gsi *gsi)
{
gsi_channel_teardown(gsi);
- gsi_irq_teardown(gsi);
}
/* Initialize a channel's event ring */
@@ -1952,7 +1919,7 @@ static void gsi_channel_evt_ring_exit(struct gsi_channel
*channel)
gsi_evt_ring_id_free(gsi, evt_ring_id);
}
-/* Init function for event rings */
+/* Init function for event rings; there is no gsi_evt_ring_exit() */
static void gsi_evt_ring_init(struct gsi *gsi)
{
u32
[PATCH net-next 4/7] net: ipa: ipa_stop() does not return an error
In ipa_modem_stop(), if the modem netdev pointer is non-null we call
ipa_stop(). We check for an error and if one is returned we handle
it. But ipa_stop() never returns an error, so this extra handling
is unnecessary. Simplify the code in ipa_modem_stop() based on the
knowledge no error handling is needed at this spot.
Signed-off-by: Alex Elder
---
drivers/net/ipa/ipa_modem.c | 18 --
1 file changed, 4 insertions(+), 14 deletions(-)
diff --git a/drivers/net/ipa/ipa_modem.c b/drivers/net/ipa/ipa_modem.c
index 8a6ccebde2889..af9aedbde717a 100644
--- a/drivers/net/ipa/ipa_modem.c
+++ b/drivers/net/ipa/ipa_modem.c
@@ -240,7 +240,6 @@ int ipa_modem_stop(struct ipa *ipa)
{
struct net_device *netdev = ipa->modem_netdev;
enum ipa_modem_state state;
- int ret;
/* Only attempt to stop the modem if it's running */
state = atomic_cmpxchg(&ipa->modem_state, IPA_MODEM_STATE_RUNNING,
@@ -257,29 +256,20 @@ int ipa_modem_stop(struct ipa *ipa)
/* Prevent the modem from triggering a call to ipa_setup() */
ipa_smp2p_disable(ipa);
+ /* Stop the queue and disable the endpoints if it's open */
if (netdev) {
- /* Stop the queue and disable the endpoints if it's open */
- ret = ipa_stop(netdev);
- if (ret)
- goto out_set_state;
-
+ (void)ipa_stop(netdev);
ipa->name_map[IPA_ENDPOINT_AP_MODEM_RX]->netdev = NULL;
ipa->name_map[IPA_ENDPOINT_AP_MODEM_TX]->netdev = NULL;
ipa->modem_netdev = NULL;
unregister_netdev(netdev);
free_netdev(netdev);
- } else {
- ret = 0;
}
-out_set_state:
- if (ret)
- atomic_set(&ipa->modem_state, IPA_MODEM_STATE_RUNNING);
- else
- atomic_set(&ipa->modem_state, IPA_MODEM_STATE_STOPPED);
+ atomic_set(&ipa->modem_state, IPA_MODEM_STATE_STOPPED);
smp_mb__after_atomic();
- return ret;
+ return 0;
}
/* Treat a "clean" modem stop the same as a crash */
--
2.27.0
[PATCH net-next 3/7] net: ipa: only set endpoint netdev pointer when in use
In ipa_modem_start(), we set endpoint netdev pointers before the
network device is registered. If registration fails, we don't undo
those assignments. Instead, wait to assign the netdev pointer until
after registration succeeds.
Set these endpoint netdev pointers to NULL in ipa_modem_stop()
before unregistering the network device.
Signed-off-by: Alex Elder
---
drivers/net/ipa/ipa_modem.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ipa/ipa_modem.c b/drivers/net/ipa/ipa_modem.c
index 9b08eb8239846..8a6ccebde2889 100644
--- a/drivers/net/ipa/ipa_modem.c
+++ b/drivers/net/ipa/ipa_modem.c
@@ -1,7 +1,7 @@
// SPDX-License-Identifier: GPL-2.0
/* Copyright (c) 2014-2018, The Linux Foundation. All rights reserved.
- * Copyright (C) 2018-2020 Linaro Ltd.
+ * Copyright (C) 2018-2021 Linaro Ltd.
*/
#include
@@ -213,18 +213,18 @@ int ipa_modem_start(struct ipa *ipa)
goto out_set_state;
}
- ipa->name_map[IPA_ENDPOINT_AP_MODEM_TX]->netdev = netdev;
- ipa->name_map[IPA_ENDPOINT_AP_MODEM_RX]->netdev = netdev;
-
SET_NETDEV_DEV(netdev, &ipa->pdev->dev);
priv = netdev_priv(netdev);
priv->ipa = ipa;
ret = register_netdev(netdev);
- if (ret)
- free_netdev(netdev);
- else
+ if (!ret) {
ipa->modem_netdev = netdev;
+ ipa->name_map[IPA_ENDPOINT_AP_MODEM_TX]->netdev = netdev;
+ ipa->name_map[IPA_ENDPOINT_AP_MODEM_RX]->netdev = netdev;
+ } else {
+ free_netdev(netdev);
+ }
out_set_state:
if (ret)
@@ -263,6 +263,8 @@ int ipa_modem_stop(struct ipa *ipa)
if (ret)
goto out_set_state;
+ ipa->name_map[IPA_ENDPOINT_AP_MODEM_RX]->netdev = NULL;
+ ipa->name_map[IPA_ENDPOINT_AP_MODEM_TX]->netdev = NULL;
ipa->modem_netdev = NULL;
unregister_netdev(netdev);
free_netdev(netdev);
--
2.27.0
[PATCH net-next 2/7] net: ipa: update sequence type for modem TX endpoint
On IPA v3.5.1, the sequencer type for the modem TX endpoint does not
define the replication portion in the same way the downstream code
does. This difference doesn't affect the behavior of the upstream
code, but I'd prefer the two code bases use the same configuration
value here.
Signed-off-by: Alex Elder
---
drivers/net/ipa/ipa_data-v3.5.1.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ipa/ipa_data-v3.5.1.c
b/drivers/net/ipa/ipa_data-v3.5.1.c
index 57703e95a3f9c..ead1a82f32f5c 100644
--- a/drivers/net/ipa/ipa_data-v3.5.1.c
+++ b/drivers/net/ipa/ipa_data-v3.5.1.c
@@ -116,6 +116,7 @@ static const struct ipa_gsi_endpoint_data
ipa_gsi_endpoint_data[] = {
.status_enable = true,
.tx = {
.seq_type = IPA_SEQ_2_PASS_SKIP_LAST_UC,
+ .seq_rep_type = IPA_SEQ_REP_DMA_PARSER,
.status_endpoint =
IPA_ENDPOINT_MODEM_AP_RX,
},
--
2.27.0
[PATCH net-next 1/7] net: ipa: relax pool entry size requirement
I no longer know why a validation check ensured the size of an entry passed to gsi_trans_pool_init() was restricted to be a multiple of 8. For 32-bit builds, this condition doesn't always hold, and for DMA pools, the size is rounded up to a power of 2 anyway. Remove this restriction. Signed-off-by: Alex Elder --- drivers/net/ipa/gsi_trans.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/ipa/gsi_trans.c b/drivers/net/ipa/gsi_trans.c index 70c2b585f98d6..8c795a6a85986 100644 --- a/drivers/net/ipa/gsi_trans.c +++ b/drivers/net/ipa/gsi_trans.c @@ -91,7 +91,7 @@ int gsi_trans_pool_init(struct gsi_trans_pool *pool, size_t size, u32 count, void *virt; #ifdef IPA_VALIDATE - if (!size || size % 8) + if (!size) return -EINVAL; if (count < max_alloc) return -EINVAL; @@ -141,7 +141,7 @@ int gsi_trans_pool_init_dma(struct device *dev, struct gsi_trans_pool *pool, void *virt; #ifdef IPA_VALIDATE - if (!size || size % 8) + if (!size) return -EINVAL; if (count < max_alloc) return -EINVAL; -- 2.27.0
[PATCH net-next 0/7] net: ipa: a few small fixes
This series implements some minor bug fixes or improvements. The first patch removes an apparently unnecessary restriction, which results in an error on a 32-bit ARM build. The second makes a definition used for SDM845 match what is used in the downstream code. The third just ensures two netdev pointers are only non-null when valid. The fourth simplifies a little code, knowing that a called function never returns an error. The fifth and sixth just remove some empty/place holder functions. And the last patch fixes a comment, makes a function private, and removes an unnecessary double-negation of a Boolean variable. This patch produces a warning from checkpatch, indicating that a pair of parentheses is unnecessary. I agree with that advice, but it conflicts with a suggestion from the compiler. I left the "problem" in place to avoid the compiler warning. -Alex Alex Elder (7): net: ipa: relax pool entry size requirement net: ipa: update sequence type for modem TX endpoint net: ipa: only set endpoint netdev pointer when in use net: ipa: ipa_stop() does not return an error net: ipa: get rid of empty IPA functions net: ipa: get rid of empty GSI functions net: ipa: three small fixes drivers/net/ipa/gsi.c | 54 --- drivers/net/ipa/gsi_trans.c | 4 +-- drivers/net/ipa/ipa_data-v3.5.1.c | 1 + drivers/net/ipa/ipa_endpoint.c| 6 ++-- drivers/net/ipa/ipa_endpoint.h| 2 -- drivers/net/ipa/ipa_main.c| 29 ++--- drivers/net/ipa/ipa_mem.c | 9 ++ drivers/net/ipa/ipa_mem.h | 5 ++- drivers/net/ipa/ipa_modem.c | 34 --- drivers/net/ipa/ipa_resource.c| 8 + drivers/net/ipa/ipa_resource.h| 8 ++--- drivers/net/ipa/ipa_table.c | 26 ++- drivers/net/ipa/ipa_table.h | 16 +++-- 13 files changed, 49 insertions(+), 153 deletions(-) -- 2.27.0
[PATCH net-next 2/3] net: use skb_for_each_frag() helper where possible
From: Matteo Croce use the new helper macro skb_for_each_frag() which allows to iterate through all the SKB fragments. The patch was created with Coccinelle, this was the semantic patch: @@ struct sk_buff *skb; identifier i; statement S; iterator name skb_for_each_frag; @@ -for (i = 0; i < skb_shinfo(skb)->nr_frags; \(++i\|i++\)) +skb_for_each_frag(skb, i) S @@ struct skb_shared_info *sinfo; struct sk_buff *skb; identifier i; statement S; iterator name skb_for_each_frag; @@ sinfo = skb_shinfo(skb); ... -for (i = 0; i < sinfo->nr_frags; \(++i\|i++\)) +skb_for_each_frag(skb, i) S @@ struct sk_buff *skb; identifier i, num_frags; statement S; iterator name skb_for_each_frag; @@ num_frags = skb_shinfo(skb)->nr_frags; ... -for (i = 0; i < num_frags; \(++i\|i++\)) +skb_for_each_frag(skb, i) S Tested with an allmodconfig build. Signed-off-by: Matteo Croce --- arch/um/drivers/vector_kern.c | 4 +-- drivers/atm/he.c | 2 +- drivers/hsi/clients/ssi_protocol.c| 2 +- drivers/infiniband/hw/hfi1/ipoib_tx.c | 2 +- drivers/infiniband/hw/hfi1/vnic_sdma.c| 2 +- drivers/infiniband/ulp/ipoib/ipoib_cm.c | 2 +- drivers/infiniband/ulp/ipoib/ipoib_ib.c | 4 +-- drivers/net/ethernet/3com/3c59x.c | 2 +- drivers/net/ethernet/3com/typhoon.c | 2 +- drivers/net/ethernet/adaptec/starfire.c | 2 +- drivers/net/ethernet/aeroflex/greth.c | 6 ++-- drivers/net/ethernet/alteon/acenic.c | 2 +- drivers/net/ethernet/amazon/ena/ena_netdev.c | 2 +- drivers/net/ethernet/amd/xgbe/xgbe-desc.c | 2 +- drivers/net/ethernet/amd/xgbe/xgbe-drv.c | 2 +- .../net/ethernet/apm/xgene/xgene_enet_main.c | 2 +- drivers/net/ethernet/atheros/alx/main.c | 2 +- .../net/ethernet/atheros/atl1c/atl1c_main.c | 2 +- .../net/ethernet/atheros/atl1e/atl1e_main.c | 4 +-- drivers/net/ethernet/atheros/atlx/atl1.c | 4 +-- drivers/net/ethernet/broadcom/bgmac.c | 2 +- drivers/net/ethernet/broadcom/bnx2.c | 2 +- .../net/ethernet/broadcom/bnx2x/bnx2x_cmn.c | 2 +- drivers/net/ethernet/broadcom/bnxt/bnxt.c | 6 ++-- drivers/net/ethernet/broadcom/tg3.c | 2 +- drivers/net/ethernet/cadence/macb_main.c | 4 +-- .../ethernet/cavium/thunder/nicvf_queues.c| 2 +- drivers/net/ethernet/chelsio/cxgb3/sge.c | 4 +-- drivers/net/ethernet/emulex/benet/be_main.c | 2 +- drivers/net/ethernet/faraday/ftgmac100.c | 2 +- .../net/ethernet/freescale/dpaa/dpaa_eth.c| 2 +- drivers/net/ethernet/freescale/gianfar.c | 5 ++-- drivers/net/ethernet/hisilicon/hix5hd2_gmac.c | 4 +-- drivers/net/ethernet/hisilicon/hns/hns_enet.c | 2 +- .../net/ethernet/hisilicon/hns3/hns3_enet.c | 4 +-- drivers/net/ethernet/huawei/hinic/hinic_rx.c | 2 +- drivers/net/ethernet/huawei/hinic/hinic_tx.c | 4 +-- drivers/net/ethernet/ibm/ibmveth.c| 2 +- drivers/net/ethernet/ibm/ibmvnic.c| 2 +- drivers/net/ethernet/intel/e1000/e1000_main.c | 2 +- drivers/net/ethernet/intel/e1000e/netdev.c| 2 +- drivers/net/ethernet/intel/fm10k/fm10k_main.c | 2 +- drivers/net/ethernet/intel/igb/igb_main.c | 2 +- drivers/net/ethernet/intel/igbvf/netdev.c | 2 +- drivers/net/ethernet/intel/igc/igc_main.c | 2 +- drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 2 +- .../net/ethernet/intel/ixgbevf/ixgbevf_main.c | 2 +- drivers/net/ethernet/marvell/mv643xx_eth.c| 2 +- .../net/ethernet/marvell/mvpp2/mvpp2_main.c | 2 +- drivers/net/ethernet/marvell/skge.c | 2 +- drivers/net/ethernet/marvell/sky2.c | 10 +++ drivers/net/ethernet/mediatek/mtk_eth_soc.c | 4 +-- .../net/ethernet/mellanox/mlx5/core/en_tx.c | 2 +- drivers/net/ethernet/mellanox/mlxsw/pci.c | 2 +- drivers/net/ethernet/microchip/lan743x_main.c | 2 +- drivers/net/ethernet/neterion/s2io.c | 2 +- .../net/ethernet/neterion/vxge/vxge-main.c| 6 ++-- drivers/net/ethernet/ni/nixge.c | 2 +- drivers/net/ethernet/pasemi/pasemi_mac.c | 2 +- .../ethernet/qlogic/netxen/netxen_nic_main.c | 2 +- drivers/net/ethernet/qlogic/qed/qed_ll2.c | 2 +- .../net/ethernet/qlogic/qlcnic/qlcnic_io.c| 2 +- drivers/net/ethernet/realtek/8139cp.c | 2 +- drivers/net/ethernet/rocker/rocker_main.c | 2 +- drivers/net/ethernet/sfc/tx.c | 2 +- drivers/net/ethernet/sun/cassini.c| 2 +- drivers/net/ethernet/sun/niu.c| 4 +-- drivers/net/ethernet/sun/sungem.c | 2 +- drivers/net/ethernet/sun/sunhme.c | 2 +- drivers/net/ethernet/sun/sunvnet_common.c | 4 +-- .../net/ethernet/synopsys/dwc-xlgmac-desc.c | 2 +- .../net/ethernet/synopsys/dwc-xlgmac-net.c| 2 +- drivers/net/ethernet/ti/am65-cpsw-nuss.c | 2 +- drivers/net/ethernet/ti/netcp_core.c | 2 +- drivers/net/ethernet/via/
[PATCH net-next 3/3] net: use skb_for_each_frag() in illegal_highdma()
From: Matteo Croce
Coccinelle failed with the following error:
EXN: Failure("no position information") in net/core/dev.c
Apply it by hand as it's trivial.
Signed-off-by: Matteo Croce
---
net/core/dev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 33ff4a944109..98deb4852151 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -3505,7 +3505,7 @@ static int illegal_highdma(struct net_device *dev, struct
sk_buff *skb)
int i;
if (!(dev->features & NETIF_F_HIGHDMA)) {
- for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) {
+ skb_for_each_frag(skb, i) {
skb_frag_t *frag = &skb_shinfo(skb)->frags[i];
if (PageHighMem(skb_frag_page(frag)))
--
2.30.2
[PATCH net-next 1/3] skbuff: add helper to walk over the fraglist
From: Matteo Croce
Add an skb_for_each_frag() macro to iterate on SKB fragments.
Signed-off-by: Matteo Croce
---
include/linux/skbuff.h | 4
1 file changed, 4 insertions(+)
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index dbf820a50a39..a8d4ccacdda5 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -1528,6 +1528,10 @@ static inline void skb_mark_not_on_list(struct sk_buff
*skb)
for ((skb) = (first), (next_skb) = (skb) ? (skb)->next : NULL; (skb); \
(skb) = (next_skb), (next_skb) = (skb) ? (skb)->next : NULL)
+/* Iterate through skb fragments. */
+#define skb_for_each_frag(skb, __i) \
+ for (__i = 0; __i < skb_shinfo(skb)->nr_frags; __i++)
+
static inline void skb_list_del_init(struct sk_buff *skb)
{
__list_del_entry(&skb->list);
--
2.30.2
[PATCH net-next 0/3] introduce skb_for_each_frag()
From: Matteo Croce Introduce skb_for_each_frag, an helper macro to iterate over the SKB frags. First patch introduces the helper, the second one is generated with coccinelle and uses the macro where possible. Last one is a chunk which have to be applied by hand. The second patch raises some checkpatch.pl warnings because part of net/tls/tls_sw.c is indented with spaces. Build tested with an allmodconfig and a test run. Matteo Croce (3): skbuff: add helper to walk over the fraglist net: use skb_for_each_frag() helper where possible net: use skb_for_each_frag() in illegal_highdma() arch/um/drivers/vector_kern.c | 4 +-- drivers/atm/he.c | 2 +- drivers/hsi/clients/ssi_protocol.c| 2 +- drivers/infiniband/hw/hfi1/ipoib_tx.c | 2 +- drivers/infiniband/hw/hfi1/vnic_sdma.c| 2 +- drivers/infiniband/ulp/ipoib/ipoib_cm.c | 2 +- drivers/infiniband/ulp/ipoib/ipoib_ib.c | 4 +-- drivers/net/ethernet/3com/3c59x.c | 2 +- drivers/net/ethernet/3com/typhoon.c | 2 +- drivers/net/ethernet/adaptec/starfire.c | 2 +- drivers/net/ethernet/aeroflex/greth.c | 6 ++-- drivers/net/ethernet/alteon/acenic.c | 2 +- drivers/net/ethernet/amazon/ena/ena_netdev.c | 2 +- drivers/net/ethernet/amd/xgbe/xgbe-desc.c | 2 +- drivers/net/ethernet/amd/xgbe/xgbe-drv.c | 2 +- .../net/ethernet/apm/xgene/xgene_enet_main.c | 2 +- drivers/net/ethernet/atheros/alx/main.c | 2 +- .../net/ethernet/atheros/atl1c/atl1c_main.c | 2 +- .../net/ethernet/atheros/atl1e/atl1e_main.c | 4 +-- drivers/net/ethernet/atheros/atlx/atl1.c | 4 +-- drivers/net/ethernet/broadcom/bgmac.c | 2 +- drivers/net/ethernet/broadcom/bnx2.c | 2 +- .../net/ethernet/broadcom/bnx2x/bnx2x_cmn.c | 2 +- drivers/net/ethernet/broadcom/bnxt/bnxt.c | 6 ++-- drivers/net/ethernet/broadcom/tg3.c | 2 +- drivers/net/ethernet/cadence/macb_main.c | 4 +-- .../ethernet/cavium/thunder/nicvf_queues.c| 2 +- drivers/net/ethernet/chelsio/cxgb3/sge.c | 4 +-- drivers/net/ethernet/emulex/benet/be_main.c | 2 +- drivers/net/ethernet/faraday/ftgmac100.c | 2 +- .../net/ethernet/freescale/dpaa/dpaa_eth.c| 2 +- drivers/net/ethernet/freescale/gianfar.c | 5 ++-- drivers/net/ethernet/hisilicon/hix5hd2_gmac.c | 4 +-- drivers/net/ethernet/hisilicon/hns/hns_enet.c | 2 +- .../net/ethernet/hisilicon/hns3/hns3_enet.c | 4 +-- drivers/net/ethernet/huawei/hinic/hinic_rx.c | 2 +- drivers/net/ethernet/huawei/hinic/hinic_tx.c | 4 +-- drivers/net/ethernet/ibm/ibmveth.c| 2 +- drivers/net/ethernet/ibm/ibmvnic.c| 2 +- drivers/net/ethernet/intel/e1000/e1000_main.c | 2 +- drivers/net/ethernet/intel/e1000e/netdev.c| 2 +- drivers/net/ethernet/intel/fm10k/fm10k_main.c | 2 +- drivers/net/ethernet/intel/igb/igb_main.c | 2 +- drivers/net/ethernet/intel/igbvf/netdev.c | 2 +- drivers/net/ethernet/intel/igc/igc_main.c | 2 +- drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 2 +- .../net/ethernet/intel/ixgbevf/ixgbevf_main.c | 2 +- drivers/net/ethernet/marvell/mv643xx_eth.c| 2 +- .../net/ethernet/marvell/mvpp2/mvpp2_main.c | 2 +- drivers/net/ethernet/marvell/skge.c | 2 +- drivers/net/ethernet/marvell/sky2.c | 10 +++ drivers/net/ethernet/mediatek/mtk_eth_soc.c | 4 +-- .../net/ethernet/mellanox/mlx5/core/en_tx.c | 2 +- drivers/net/ethernet/mellanox/mlxsw/pci.c | 2 +- drivers/net/ethernet/microchip/lan743x_main.c | 2 +- drivers/net/ethernet/neterion/s2io.c | 2 +- .../net/ethernet/neterion/vxge/vxge-main.c| 6 ++-- drivers/net/ethernet/ni/nixge.c | 2 +- drivers/net/ethernet/pasemi/pasemi_mac.c | 2 +- .../ethernet/qlogic/netxen/netxen_nic_main.c | 2 +- drivers/net/ethernet/qlogic/qed/qed_ll2.c | 2 +- .../net/ethernet/qlogic/qlcnic/qlcnic_io.c| 2 +- drivers/net/ethernet/realtek/8139cp.c | 2 +- drivers/net/ethernet/rocker/rocker_main.c | 2 +- drivers/net/ethernet/sfc/tx.c | 2 +- drivers/net/ethernet/sun/cassini.c| 2 +- drivers/net/ethernet/sun/niu.c| 4 +-- drivers/net/ethernet/sun/sungem.c | 2 +- drivers/net/ethernet/sun/sunhme.c | 2 +- drivers/net/ethernet/sun/sunvnet_common.c | 4 +-- .../net/ethernet/synopsys/dwc-xlgmac-desc.c | 2 +- .../net/ethernet/synopsys/dwc-xlgmac-net.c| 2 +- drivers/net/ethernet/ti/am65-cpsw-nuss.c | 2 +- drivers/net/ethernet/ti/netcp_core.c | 2 +- drivers/net/ethernet/via/via-velocity.c | 2 +- drivers/net/ethernet/xilinx/ll_temac_main.c | 2 +- .../net/ethernet/xilinx/xilinx_axienet_main.c | 2 +- drivers/net/usb/usbnet.c | 2 +- drivers/net/vmxnet3/vmxnet3_drv.c | 4 +-- drivers/net/wireless/intel/
Re: [PATCH 2/2] iommu/sva: Remove mm parameter from SVA bind API
Hi Lu,
On Fri, 9 Apr 2021 20:45:22 +0800, Lu Baolu
wrote:
> > -int iommu_sva_alloc_pasid(struct mm_struct *mm, ioasid_t min, ioasid_t
> > max) +int iommu_sva_alloc_pasid(ioasid_t min, ioasid_t max)
> > {
> > int ret = 0;
> > ioasid_t pasid;
> > + struct mm_struct *mm;
> >
> > if (min == INVALID_IOASID || max == INVALID_IOASID ||
> > min == 0 || max < min)
> > return -EINVAL;
> >
> > mutex_lock(&iommu_sva_lock);
> > + mm = get_task_mm(current);
>
> How could we allocate a supervisor PASID through iommu_sva_alloc_pasid()
> if we always use current->mm here?
I don't think you can. But I guess the current callers of this function do
not need supervisor PASID.
In reply to Jean, I suggest we split this function into mm->pasid
assignment and keep using ioasid_alloc() directly, then supervisor PASID is
caller's bind choice.
Thanks,
Jacob
[PATCH] Documentation: kunit: add tips for running KUnit
This is long overdue.
There are several things that aren't nailed down (in-tree
.kunitconfig's), or partially broken (GCOV on UML), but having them
documented, warts and all, is better than having nothing.
This covers a bunch of the more recent features
* kunit_filter_glob
* kunit.py run --kunitconfig
* kunit.py run --alltests
* slightly more detail on building tests as modules
* CONFIG_KUNIT_DEBUGFS
By my count, the only headline features now not mentioned are the KASAN
integration and KernelCI json output support (kunit.py run --json).
And then it also discusses how to get code coverage reports under UML
and non-UML since this is a question people have repeatedly asked.
Non-UML coverage collection is no differnt from normal, but we should
probably explicitly call thsi out.
As for UML, I was able to get it working again with two small hacks.*
E.g. with CONFIG_KUNIT=y && CONFIG_KUNIT_ALL_TESTS=y
Overall coverage rate:
lines..: 15.1% (18294 of 120776 lines)
functions..: 16.8% (1860 of 11050 functions)
*Switching to use gcc/gcov-6 and not using uml_abort().
I've documented these hacks in "Notes" but left TODOs for
brendanhigg...@google.com who tracked down the runtime issue in GCC.
To be clear: these are not issues specific to KUnit, but rather to UML.
Signed-off-by: Daniel Latypov
---
Documentation/dev-tools/kunit/index.rst | 1 +
.../dev-tools/kunit/running_tips.rst | 278 ++
Documentation/dev-tools/kunit/start.rst | 2 +
3 files changed, 281 insertions(+)
create mode 100644 Documentation/dev-tools/kunit/running_tips.rst
diff --git a/Documentation/dev-tools/kunit/index.rst
b/Documentation/dev-tools/kunit/index.rst
index 848478838347..7f7cf8d2ab20 100644
--- a/Documentation/dev-tools/kunit/index.rst
+++ b/Documentation/dev-tools/kunit/index.rst
@@ -14,6 +14,7 @@ KUnit - Unit Testing for the Linux Kernel
style
faq
tips
+ running_tips
What is KUnit?
==
diff --git a/Documentation/dev-tools/kunit/running_tips.rst
b/Documentation/dev-tools/kunit/running_tips.rst
new file mode 100644
index ..d38e665e530f
--- /dev/null
+++ b/Documentation/dev-tools/kunit/running_tips.rst
@@ -0,0 +1,278 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+
+Tips For Running KUnit Tests
+
+
+Using ``kunit.py run`` ("kunit tool")
+=
+
+Running from any directory
+--
+
+It can be handy to create a bash function like:
+
+.. code-block:: bash
+
+ function run_kunit() {
+ ( cd "$(git rev-parse --show-toplevel)" &&
./tools/testing/kunit/kunit.py run $@ )
+ }
+
+.. note::
+ Early versions of ``kunit.py`` (before 5.6) didn't work unless run from
+ the kernel root, hence the use of a subshell and ``cd``.
+
+Running a subset of tests
+-
+
+``kunit.py run`` accepts an optional glob argument to filter tests. Currently
+this only matches against suite names, but this may change in the future.
+
+Say that we wanted to run the sysctl tests, we could do so via:
+
+.. code-block:: bash
+
+ $ echo -e 'CONFIG_KUNIT=y\nCONFIG_KUNIT_ALL_TESTS=y' >
.kunit/.kunitconfig
+ $ ./tools/testing/kunit/kunit.py run 'sysctl*'
+
+We're paying the cost of building more tests than we need this way, but it's
+easier than fiddling with ``.kunitconfig`` files or commenting out
+``kunit_suite``'s.
+
+However, if we wanted to define a set of tests in a less ad hoc way, the next
+tip is useful.
+
+Defining a set of tests
+---
+
+``kunit.py run`` (along with ``build``, and ``config``) supports a
+``--kunitconfig`` flag. So if you have a set of tests that you want to run on a
+regular basis (especially if they have other dependencies), you can create a
+specific ``.kunitconfig`` for them.
+
+E.g. kunit has own for its tests:
+
+.. code-block:: bash
+
+ $ ./tools/testing/kunit/kunit.py run
--kunitconfig=lib/kunit/.kunitconfig
+
+Alternatively, if you're following the convention of naming your
+file ``.kunitconfig``, you can just pass in the dir, e.g.
+
+.. code-block:: bash
+
+ $ ./tools/testing/kunit/kunit.py run --kunitconfig=lib/kunit
+
+.. note::
+ This is a relatively new feature (5.12+) so we don't have any
+ conventions yet about on what files should be checked in versus just
+ kept around locally. But if the tests don't have any dependencies
+ (beyond ``CONFIG_KUNIT``), it's probably not worth writing and
+ maintaining a ``.kunitconfig`` fragment. Running with
+ ``CONFIG_KUNIT_ALL_TESTS=y`` is probably easier.
+
+.. note::
+ Having ``.kunitconfig`` fragments in a parent and child directory is
+ iffy. There's discussion about adding an "import" statement in these
+ files to make it possible to have a top-level config run tests from all
+ child directories. But that would mean ``.
Re: [PATCH 2/2] iommu/sva: Remove mm parameter from SVA bind API
Hi Jean-Philippe,
On Fri, 9 Apr 2021 12:11:47 +0200, Jean-Philippe Brucker
wrote:
> On Thu, Apr 08, 2021 at 10:08:56AM -0700, Jacob Pan wrote:
> > diff --git a/drivers/iommu/iommu-sva-lib.c
> > b/drivers/iommu/iommu-sva-lib.c index bd41405..bd99f6b 100644
> > --- a/drivers/iommu/iommu-sva-lib.c
> > +++ b/drivers/iommu/iommu-sva-lib.c
> > @@ -12,27 +12,33 @@ static DECLARE_IOASID_SET(iommu_sva_pasid);
> >
> > /**
> > * iommu_sva_alloc_pasid - Allocate a PASID for the mm
> > - * @mm: the mm
> > * @min: minimum PASID value (inclusive)
> > * @max: maximum PASID value (inclusive)
> > *
> > - * Try to allocate a PASID for this mm, or take a reference to the
> > existing one
> > - * provided it fits within the [@min, @max] range. On success the
> > PASID is
> > - * available in mm->pasid, and must be released with
> > iommu_sva_free_pasid().
> > + * Try to allocate a PASID for the current mm, or take a reference to
> > the
> > + * existing one provided it fits within the [@min, @max] range. On
> > success
> > + * the PASID is available in the current mm->pasid, and must be
> > released with
> > + * iommu_sva_free_pasid().
> > * @min must be greater than 0, because 0 indicates an unused
> > mm->pasid. *
> > * Returns 0 on success and < 0 on error.
> > */
> > -int iommu_sva_alloc_pasid(struct mm_struct *mm, ioasid_t min, ioasid_t
> > max) +int iommu_sva_alloc_pasid(ioasid_t min, ioasid_t max)
> > {
> > int ret = 0;
> > ioasid_t pasid;
> > + struct mm_struct *mm;
> >
> > if (min == INVALID_IOASID || max == INVALID_IOASID ||
> > min == 0 || max < min)
> > return -EINVAL;
> >
> > mutex_lock(&iommu_sva_lock);
> > + mm = get_task_mm(current);
> > + if (!mm) {
> > + ret = -EINVAL;
> > + goto out_unlock;
> > + }
>
> I still think it would be more elegant to keep the choice of context in
> iommu_sva_bind_device() and pass it down to leaf functions such as
> iommu_sva_alloc_pasid(). The patch is trying to solve two separate
I agree if iommu_sva_alloc_pasid() is a leaf function, but it is a public
function, e.g. called by smmu code:
/* Allocate a PASID for this mm if necessary */
ret = iommu_sva_alloc_pasid(1, (1U << master->ssid_bits) - 1);
If we give mm as parameter, it will give callers the illusion that this
mm doesn't have to be current->mm.
Should we make it into a leaf function by splitting iommu_sva_alloc_pasid()
into two parts?
1. iommu_sva_assign_pasid() //a new leaf helper function does mm->pasid
assignment
2. ioasid_alloc()
in iommu_sva_bind_device(), we do:
1. handle = driver ops->sva_bind(dev, mm, flags);
2. pasid = sva_get_pasid(handle);
3. iommu_sva_assign_pasid(mm, pasid)
In vendor driver sva_bind(), it just use ioasid_alloc directly with custom
range. e.g. arm-smmu-v3-sva.c
- ret = iommu_sva_alloc_pasid(1, (1U << master->ssid_bits) - 1);
+ ret = ioasid_alloc(&iommu_sva_pasid, 1, (1U << master->ssid_bits);
> problems:
>
> * We don't have a use-case for binding the mm of a remote process (and
> it's supposedly difficult for device drivers to do it securely). So OK,
> we remove the mm argument from iommu_sva_bind_device() and use the
> current mm. But the IOMMU driver isn't going to do get_task_mm(current)
> every time it needs the mm being bound, it will take it from
> iommu_sva_bind_device(). Likewise iommu_sva_alloc_pasid() shouldn't need
> to bother with get_task_mm().
>
> * cgroup accounting for IOASIDs needs to be on the current task. Removing
> the mm parameter from iommu_sva_alloc_pasid() doesn't help with that.
> Sure it indicates that iommu_sva_alloc_pasid() needs a specific task
> context but that's only for cgroup purpose, and I'd rather pass the
> cgroup down from iommu_sva_bind_device() anyway (but am fine with
> keeping it within ioasid_alloc() for now). Plus it's an internal helper,
> easy for us to check that the callers are doing the right thing.
>
With the above split, we really just have one allocation function:
ioasid_alloc(), so it can manage current cgroup accounting within. Would
this work?
> > if (mm->pasid) {
> > if (mm->pasid >= min && mm->pasid <= max)
> > ioasid_get(mm->pasid);
> > @@ -45,22 +51,32 @@ int iommu_sva_alloc_pasid(struct mm_struct *mm,
> > ioasid_t min, ioasid_t max) else
> > mm->pasid = pasid;
> > }
> > + mmput(mm);
> > +out_unlock:
> > mutex_unlock(&iommu_sva_lock);
> > return ret;
> > }
> > EXPORT_SYMBOL_GPL(iommu_sva_alloc_pasid);
> >
> > /**
> > - * iommu_sva_free_pasid - Release the mm's PASID
> > + * iommu_sva_free_pasid - Release the current mm's PASID
> > * @mm: the mm
> > *
> > * Drop one reference to a PASID allocated with iommu_sva_alloc_pasid()
> > */
> > -void iommu_sva_free_pasid(struct mm_struct *mm)
> > +void iommu_sva_free_pasid(void)
> > {
> > + struct mm_struct *mm;
> > +
> > mutex_lock(&
Re: [PATCH] sched/fair: Rate limit calls to update_blocked_averages() for NOHZ
On 4/9/21 8:26 AM, Vincent Guittot wrote:
I was expecting idle load balancer to be rate limited to 60 Hz, which
>>>
>>> Why 60Hz ?
>>>
>>
>> My thinking is we will trigger load balance only after rq->next_balance.
>>
>> void trigger_load_balance(struct rq *rq)
>> {
>> /* Don't need to rebalance while attached to NULL domain */
>> if (unlikely(on_null_domain(rq)))
>> return;
>>
>> if (time_after_eq(jiffies, rq->next_balance))
>> raise_softirq(SCHED_SOFTIRQ);
>>
>> nohz_balancer_kick(rq);
>> }
>>
>> And it seems like next_balance is set to be 60 Hz
>>
>> static void rebalance_domains(struct rq *rq, enum cpu_idle_type idle)
>> {
>> int continue_balancing = 1;
>> int cpu = rq->cpu;
>> int busy = idle != CPU_IDLE && !sched_idle_cpu(cpu);
>> unsigned long interval;
>> struct sched_domain *sd;
>> /* Earliest time when we have to do rebalance again */
>> unsigned long next_balance = jiffies + 60*HZ;
>
> This doesn't mean 60 Hz period but 60*HZ with HZ being the number of
> jiffies per second. We init next_balance with now + 60 sec to make
> sure it's far later than the next balance of the sched_domains
>
> Then, update_next_balance() keeps track of 1st balance to happen next time
>
Thanks for pointing out my misread of the code. In this case the
balance frequency should be lower than I thought as balance should be 60 sec
apart in theory.
>> Here's a snapshot of the trace. However I didn't have the current task in my
>> trace.
>> You can tell the frequency that update_blocked_averages is called on
>> cpu 2 by the jiffies value. They are quite close together (1 to 3 jiffies
>> apart).
>> When I have a chance to get on the machine, I'll take another look
>> at the current task and whether we got to trigger_load_balance() from
>> scheduler_tick().
>>
>>
>> 3.505 ( ): probe:update_blocked_averages:(810cf070)
>> cpu=2 jiffies=0x1004fb731
>> 4.505 ( ): probe:update_blocked_averages:(810cf070)
>> cpu=2 jiffies=0x1004fb732
>> 6.484 ( ): probe:newidle_balance:(810d2470)
>> this_rq=0x88fe7f8aae00 next_balance=0x1004fb731 jiffies=0x1004fb733
>> 6.506 ( ): probe:update_blocked_averages:(810cf070)
>> cpu=2 jiffies=0x1004fb734
>> 9.503 ( ): probe:update_blocked_averages:(810cf070)
>> cpu=2 jiffies=0x1004fb737
>> 11.504 ( ): probe:update_blocked_averages:(810cf070)
>> cpu=2 jiffies=0x1004fb739
>> 11.602 ( ): probe:newidle_balance:(810d2470)
>> this_rq=0x88fe7f8aae00 next_balance=0x1004fb76c jiffies=0x1004fb739
>> 11.624 ( ): probe:newidle_balance:(810d2470)
>> this_rq=0x88fe7f8aae00 next_balance=0x1004fb731 jiffies=0x1004fb739
>> 11.642 ( ): probe:newidle_balance:(810d2470)
>> this_rq=0x88fe7f8aae00 next_balance=0x1004fb731 jiffies=0x1004fb739
>> 11.645 ( ): probe:newidle_balance:(810d2470)
>> this_rq=0x88fe7f8aae00 next_balance=0x1004fb731 jiffies=0x1004fb739
>> 11.977 ( ): probe:newidle_balance:(810d2470)
>> this_rq=0x88fe7f8aae00 next_balance=0x1004fb731 jiffies=0x1004fb739
>> 12.003 ( ): probe:newidle_balance:(810d2470)
>> this_rq=0x88fe7f8aae00 next_balance=0x1004fb731 jiffies=0x1004fb739
>> 12.015 ( ): probe:newidle_balance:(810d2470)
>> this_rq=0x88fe7f8aae00 next_balance=0x1004fb731 jiffies=0x1004fb739
>> 12.043 ( ): probe:newidle_balance:(810d2470)
>> this_rq=0x88fe7f8aae00 next_balance=0x1004fb731 jiffies=0x1004fb739
>> 12.567 ( ): probe:update_blocked_averages:(810cf070)
>> cpu=2 jiffies=0x1004fb73a
>> 13.856 ( ): probe:newidle_balance:(810d2470)
>> this_rq=0x88fe7f8aae00 next_balance=0x1004fb76c jiffies=0x1004fb73b
>> 13.910 ( ): probe:newidle_balance:(810d2470)
>> this_rq=0x88fe7f8aae00 next_balance=0x1004fb731 jiffies=0x1004fb73b
>> 14.003 ( ): probe:newidle_balance:(810d2470)
>> this_rq=0x88fe7f8aae00 next_balance=0x1004fb731 jiffies=0x1004fb73b
>> 14.159 ( ): probe:newidle_balance:(810d2470)
>> this_rq=0x88fe7f8aae00 next_balance=0x1004fb731 jiffies=0x1004fb73b
>> 14.203 ( ): probe:newidle_balance:(810d2470)
>> this_rq=0x88fe7f8aae00 next_balance=0x1004fb731 jiffies=0x1004fb73b
>> 14.223 ( ): probe:newidle_balance:(810d2470)
>> this_rq=0x88fe7f8aae00 next_balance=0x1004fb731 jiffies=0x1004fb73b
>> 14.301 ( ): probe:newidle_balance:(810d2470)
>> this_rq=0x88fe7f8aae00 next_balance=0x1004fb731 jiffies=0x1004fb73b
>> 14.504 ( ): probe:update_blocked_averages:(810cf070)
>> cpu=2 jiffies=0x1004fb73c
>> 14.637 ( ): probe:ne
[syzbot] BUG: spinlock bad magic in erofs_pcpubuf_growsize
Hello,
syzbot found the following issue on:
HEAD commit:9c54130c Add linux-next specific files for 20210406
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=1654617ed0
kernel config: https://syzkaller.appspot.com/x/.config?x=d125958c3995ddcd
dashboard link: https://syzkaller.appspot.com/bug?extid=d6a0e4b80bd39f54c2f6
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=101a5786d0
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1147dd0ed0
The issue was bisected to:
commit 997acaf6b4b59c6a9c259740312a69ea549cc684
Author: Mark Rutland
Date: Mon Jan 11 15:37:07 2021 +
lockdep: report broken irq restoration
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=11d8d7aad0
final oops: https://syzkaller.appspot.com/x/report.txt?x=13d8d7aad0
console output: https://syzkaller.appspot.com/x/log.txt?x=15d8d7aad0
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+d6a0e4b80bd39f54c...@syzkaller.appspotmail.com
Fixes: 997acaf6b4b5 ("lockdep: report broken irq restoration")
loop0: detected capacity change from 0 to 31
BUG: spinlock bad magic on CPU#1, syz-executor062/8434
lock: 0x8880b9c31d60, .magic: , .owner: /-1, .owner_cpu: 0
CPU: 1 PID: 8434 Comm: syz-executor062 Not tainted
5.12.0-rc6-next-20210406-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google
01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:79 [inline]
dump_stack+0x141/0x1d7 lib/dump_stack.c:120
debug_spin_lock_before kernel/locking/spinlock_debug.c:83 [inline]
do_raw_spin_lock+0x216/0x2b0 kernel/locking/spinlock_debug.c:112
erofs_pcpubuf_growsize+0x36f/0x620 fs/erofs/pcpubuf.c:83
z_erofs_load_lz4_config+0x1ef/0x3e0 fs/erofs/decompressor.c:64
erofs_read_superblock fs/erofs/super.c:331 [inline]
erofs_fc_fill_super+0xe84/0x1d10 fs/erofs/super.c:499
get_tree_bdev+0x440/0x760 fs/super.c:1293
vfs_get_tree+0x89/0x2f0 fs/super.c:1498
do_new_mount fs/namespace.c:2905 [inline]
path_mount+0x132a/0x1fa0 fs/namespace.c:3235
do_mount fs/namespace.c:3248 [inline]
__do_sys_mount fs/namespace.c:3456 [inline]
__se_sys_mount fs/namespace.c:3433 [inline]
__x64_sys_mount+0x27f/0x300 fs/namespace.c:3433
do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x444f7a
Code: 83 c4 08 5b 5d c3 66 2e 0f 1f 84 00 00 00 00 00 c3 66 2e 0f 1f 84 00 00
00 00 00 0f 1f 44 00 00 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01
c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48
RSP: 002b:7ffe1fa3c2a8 EFLAGS: 0286 ORIG_RAX: 00a5
RAX: ffda RBX: 7ffe1fa3c300 RCX: 00444f7a
RDX: 2000 RSI: 2100 RDI: 7ffe1fa3c2c0
RBP: 7ffe1fa3c2c0 R08: 7ffe1fa3c300 R09:
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkal...@googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
syzbot can test patches for this issue, for details see:
https://goo.gl/tpsmEJ#testing-patches
[syzbot] kernel BUG in llc_sap_action_send_xid_c
Hello, syzbot found the following issue on: HEAD commit:864db232 net: ipv6: check for validity before dereferencin.. git tree: net console output: https://syzkaller.appspot.com/x/log.txt?x=16377d16d0 kernel config: https://syzkaller.appspot.com/x/.config?x=daeff30c2474a60f dashboard link: https://syzkaller.appspot.com/bug?extid=5e5a981ad7cc54c4b2b4 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=154f8e9ad0 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=16fe2fbed0 IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+5e5a981ad7cc54c4b...@syzkaller.appspotmail.com skbuff: skb_over_panic: text:8717de50 len:692 put:3 head:888025f6f000 data:888025f6f00e tail:0x2c2 end:0x2c0 dev:bond0 [ cut here ] kernel BUG at net/core/skbuff.c:109! invalid opcode: [#1] PREEMPT SMP KASAN CPU: 1 PID: 8372 Comm: syz-executor543 Not tainted 5.12.0-rc4-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:skb_panic+0x16c/0x16e net/core/skbuff.c:109 Code: f8 4c 8b 4c 24 10 8b 4b 70 41 56 45 89 e8 4c 89 e2 41 57 48 89 ee 48 c7 c7 40 b2 65 8a ff 74 24 10 ff 74 24 20 e8 e7 c0 c4 ff <0f> 0b e8 d2 e0 75 f8 4c 8b 64 24 18 e8 c8 87 b9 f8 48 c7 c1 80 be RSP: 0018:c9000132f7b8 EFLAGS: 00010282 RAX: 0086 RBX: 888012a91140 RCX: RDX: 888021d6d4c0 RSI: 815c4d75 RDI: f52000265ee9 RBP: 8a65bec0 R08: 0086 R09: R10: 815bdb0e R11: R12: 8717de50 R13: 0003 R14: 88801aa24000 R15: 02c0 FS: 01d53300() GS:8880b9d0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 55acdca69398 CR3: 20a7b000 CR4: 001506e0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: skb_over_panic net/core/skbuff.c:114 [inline] skb_put.cold+0x24/0x24 net/core/skbuff.c:1914 llc_pdu_init_as_xid_cmd include/net/llc_pdu.h:377 [inline] llc_sap_action_send_xid_c+0x240/0x380 net/llc/llc_s_ac.c:84 llc_exec_sap_trans_actions net/llc/llc_sap.c:153 [inline] llc_sap_next_state net/llc/llc_sap.c:182 [inline] llc_sap_state_process+0x22a/0x4f0 net/llc/llc_sap.c:209 llc_ui_sendmsg+0x9ee/0x1040 net/llc/af_llc.c:964 sock_sendmsg_nosec net/socket.c:654 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:674 sys_sendmsg+0x331/0x810 net/socket.c:2350 ___sys_sendmsg+0xf3/0x170 net/socket.c:2404 __sys_sendmmsg+0x195/0x470 net/socket.c:2490 __do_sys_sendmmsg net/socket.c:2519 [inline] __se_sys_sendmmsg net/socket.c:2516 [inline] __x64_sys_sendmmsg+0x99/0x100 net/socket.c:2516 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x43f329 Code: 28 c3 e8 2a 14 00 00 66 2e 0f 1f 84 00 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:7ffc10253fb8 EFLAGS: 0246 ORIG_RAX: 0133 RAX: ffda RBX: 00400488 RCX: 0043f329 RDX: 0006 RSI: 20005bc0 RDI: 0003 RBP: 00403310 R08: 00400488 R09: 00400488 R10: 0400 R11: 0246 R12: 004033a0 R13: R14: 004ad018 R15: 00400488 Modules linked in: ---[ end trace 4d95aeb9a24efeaa ]--- RIP: 0010:skb_panic+0x16c/0x16e net/core/skbuff.c:109 Code: f8 4c 8b 4c 24 10 8b 4b 70 41 56 45 89 e8 4c 89 e2 41 57 48 89 ee 48 c7 c7 40 b2 65 8a ff 74 24 10 ff 74 24 20 e8 e7 c0 c4 ff <0f> 0b e8 d2 e0 75 f8 4c 8b 64 24 18 e8 c8 87 b9 f8 48 c7 c1 80 be RSP: 0018:c9000132f7b8 EFLAGS: 00010282 RAX: 0086 RBX: 888012a91140 RCX: RDX: 888021d6d4c0 RSI: 815c4d75 RDI: f52000265ee9 RBP: 8a65bec0 R08: 0086 R09: R10: 815bdb0e R11: R12: 8717de50 R13: 0003 R14: 88801aa24000 R15: 02c0 FS: 01d53300() GS:8880b9d0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 55acdca69398 CR3: 20a7b000 CR4: 001506e0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 --- This report is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this issue. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot. syzbot can test patches for this issue, for details see: https://goo.gl/tpsmEJ#testing-patches
[RFC v2 PATCH 7/7] dmaengine: xilinx_dma: Program interrupt delay timeout
Program IRQDelay for AXI DMA. The interrupt timeout mechanism causes
the DMA engine to generate an interrupt after the delay time period
has expired. It enables dmaengine to respond in real-time even though
interrupt coalescing is configured. It also remove the placeholder
for delay interrupt and merge it with frame completion interrupt.
Since by default interrupt delay timeout is disabled this feature
addition has no functional impact on VDMA and CDMA IP's.
Signed-off-by: Radhey Shyam Pandey
---
Changes for v2:
- Read irq delay timeout value from DT.
- Merge interrupt processing for frame done and delay interrupt.
---
drivers/dma/xilinx/xilinx_dma.c | 20 +++-
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c
index a2ea2d649332..0c0dc9882a01 100644
--- a/drivers/dma/xilinx/xilinx_dma.c
+++ b/drivers/dma/xilinx/xilinx_dma.c
@@ -173,8 +173,10 @@
#define XILINX_DMA_MAX_TRANS_LEN_MAX 23
#define XILINX_DMA_V2_MAX_TRANS_LEN_MAX26
#define XILINX_DMA_CR_COALESCE_MAX GENMASK(23, 16)
+#define XILINX_DMA_CR_DELAY_MAXGENMASK(31, 24)
#define XILINX_DMA_CR_CYCLIC_BD_EN_MASKBIT(4)
#define XILINX_DMA_CR_COALESCE_SHIFT 16
+#define XILINX_DMA_CR_DELAY_SHIFT 24
#define XILINX_DMA_BD_SOP BIT(27)
#define XILINX_DMA_BD_EOP BIT(26)
#define XILINX_DMA_BD_COMP_MASKBIT(31)
@@ -410,6 +412,7 @@ struct xilinx_dma_tx_descriptor {
* @stop_transfer: Differentiate b/w DMA IP's quiesce
* @tdest: TDEST value for mcdma
* @has_vflip: S2MM vertical flip
+ * @irq_delay: Interrupt delay timeout
*/
struct xilinx_dma_chan {
struct xilinx_dma_device *xdev;
@@ -447,6 +450,7 @@ struct xilinx_dma_chan {
int (*stop_transfer)(struct xilinx_dma_chan *chan);
u16 tdest;
bool has_vflip;
+ u8 irq_delay;
};
/**
@@ -1555,6 +1559,9 @@ static void xilinx_dma_start_transfer(struct
xilinx_dma_chan *chan)
if (chan->has_sg)
xilinx_write(chan, XILINX_DMA_REG_CURDESC,
head_desc->async_tx.phys);
+ reg &= ~XILINX_DMA_CR_DELAY_MAX;
+ reg |= chan->irq_delay << XILINX_DMA_CR_DELAY_SHIFT;
+ dma_ctrl_write(chan, XILINX_DMA_REG_DMACR, reg);
xilinx_dma_start(chan);
@@ -1877,15 +1884,8 @@ static irqreturn_t xilinx_dma_irq_handler(int irq, void
*data)
}
}
- if (status & XILINX_DMA_DMASR_DLY_CNT_IRQ) {
- /*
-* Device takes too long to do the transfer when user requires
-* responsiveness.
-*/
- dev_dbg(chan->dev, "Inter-packet latency too long\n");
- }
-
- if (status & XILINX_DMA_DMASR_FRM_CNT_IRQ) {
+ if (status & (XILINX_DMA_DMASR_FRM_CNT_IRQ |
+ XILINX_DMA_DMASR_DLY_CNT_IRQ)) {
spin_lock(&chan->lock);
xilinx_dma_complete_descriptor(chan);
chan->idle = true;
@@ -2802,6 +2802,8 @@ static int xilinx_dma_chan_probe(struct xilinx_dma_device
*xdev,
/* Retrieve the channel properties from the device tree */
has_dre = of_property_read_bool(node, "xlnx,include-dre");
+ of_property_read_u8(node, "xlnx,irq-delay", &chan->irq_delay);
+
chan->genlock = of_property_read_bool(node, "xlnx,genlock-mode");
err = of_property_read_u32(node, "xlnx,datawidth", &value);
--
2.7.4
[RFC v2 PATCH 6/7] dmaengine: xilinx_dma: Use tasklet_hi_schedule for timing critical usecase
Schedule tasklet with high priority to ensure that callback processing is prioritized. It improves throughput for netdev dma clients. Signed-off-by: Radhey Shyam Pandey -- Changes for v2: - None --- drivers/dma/xilinx/xilinx_dma.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c index f2305a73cb91..a2ea2d649332 100644 --- a/drivers/dma/xilinx/xilinx_dma.c +++ b/drivers/dma/xilinx/xilinx_dma.c @@ -1829,7 +1829,7 @@ static irqreturn_t xilinx_mcdma_irq_handler(int irq, void *data) spin_unlock(&chan->lock); } - tasklet_schedule(&chan->tasklet); + tasklet_hi_schedule(&chan->tasklet); return IRQ_HANDLED; } -- 2.7.4
[RFC v2 PATCH 4/7] dmaengine: xilinx_dma: Increase AXI DMA transaction segment count
Increase AXI DMA transaction segments count to ensure that even in high load we always get a free segment in prepare descriptor for a DMA_SLAVE transaction. Signed-off-by: Radhey Shyam Pandey --- Changes for v2: - None --- drivers/dma/xilinx/xilinx_dma.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c index 14dcfc473e52..890bf46b36e5 100644 --- a/drivers/dma/xilinx/xilinx_dma.c +++ b/drivers/dma/xilinx/xilinx_dma.c @@ -178,7 +178,7 @@ #define XILINX_DMA_BD_SOP BIT(27) #define XILINX_DMA_BD_EOP BIT(26) #define XILINX_DMA_COALESCE_MAX255 -#define XILINX_DMA_NUM_DESCS 255 +#define XILINX_DMA_NUM_DESCS 512 #define XILINX_DMA_NUM_APP_WORDS 5 /* AXI CDMA Specific Registers/Offsets */ -- 2.7.4
[RFC v2 PATCH 5/7] dmaengine: xilinx_dma: Freeup active list based on descriptor completion bit
AXIDMA IP in SG mode sets completion bit to 1 when the transfer is
completed. Read this bit to move descriptor from active list to the
done list. This feature is needed when interrupt delay timeout and
IRQThreshold is enabled i.e Dly_IrqEn is triggered w/o completing
interrupt threshold.
Signed-off-by: Radhey Shyam Pandey
---
- Check BD completion bit only for SG mode.
- Modify the logic to have early return path.
---
drivers/dma/xilinx/xilinx_dma.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c
index 890bf46b36e5..f2305a73cb91 100644
--- a/drivers/dma/xilinx/xilinx_dma.c
+++ b/drivers/dma/xilinx/xilinx_dma.c
@@ -177,6 +177,7 @@
#define XILINX_DMA_CR_COALESCE_SHIFT 16
#define XILINX_DMA_BD_SOP BIT(27)
#define XILINX_DMA_BD_EOP BIT(26)
+#define XILINX_DMA_BD_COMP_MASKBIT(31)
#define XILINX_DMA_COALESCE_MAX255
#define XILINX_DMA_NUM_DESCS 512
#define XILINX_DMA_NUM_APP_WORDS 5
@@ -1683,12 +1684,18 @@ static void xilinx_dma_issue_pending(struct dma_chan
*dchan)
static void xilinx_dma_complete_descriptor(struct xilinx_dma_chan *chan)
{
struct xilinx_dma_tx_descriptor *desc, *next;
+ struct xilinx_axidma_tx_segment *seg;
/* This function was invoked with lock held */
if (list_empty(&chan->active_list))
return;
list_for_each_entry_safe(desc, next, &chan->active_list, node) {
+ /* TODO: remove hardcoding for axidma_tx_segment */
+ seg = list_last_entry(&desc->segments,
+ struct xilinx_axidma_tx_segment, node);
+ if (!(seg->hw.status & XILINX_DMA_BD_COMP_MASK) && chan->has_sg)
+ break;
if (chan->has_sg && chan->xdev->dma_config->dmatype !=
XDMA_TYPE_VDMA)
desc->residue = xilinx_dma_get_residue(chan, desc);
--
2.7.4
Re: [PATCH v3] powerpc/traps: Enhance readability for trap types
On Fri, Apr 09, 2021 at 06:14:19PM +0200, Christophe Leroy wrote: > >+#define INTERRUPT_SYSTEM_RESET0x100 > > INT_SRESET SRESET exists on many PowerPC, it means "soft reset". Not the same thing at all. I think "INT" is not a great prefix fwiw, there are many things you can abbr to "INT". > >+#define INTERRUPT_DATA_SEGMENT0x380 > > INT_DSEG exceptions-64s.S calls this "DSLB" (I remember "DSSI" though -- but neither is a very official name). It probably is a good idea to look at that existing code, not make up even more new names :-) > >+#define INTERRUPT_DOORBELL0xa00 > > INT_DBELL That saves three characters and makes it very not understandable. Segher
[RFC v2 PATCH 3/7] dmaengine: xilinx_dma: Pass AXI4-Stream control words to dma client
Read DT property to check if AXI DMA is connected to streaming IP
i.e axiethernet. If connected pass AXI4-Stream control words to
dma client using metadata_ops dmaengine API.
Signed-off-by: Radhey Shyam Pandey
---
Changes for v2:
- Use descriptor metadata API to pass control words to dma client.
- Rephrased commit description to be inline with implementation.
---
drivers/dma/xilinx/xilinx_dma.c | 37 +
1 file changed, 37 insertions(+)
diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c
index 3aded7861fef..14dcfc473e52 100644
--- a/drivers/dma/xilinx/xilinx_dma.c
+++ b/drivers/dma/xilinx/xilinx_dma.c
@@ -491,6 +491,7 @@ struct xilinx_dma_config {
* @s2mm_chan_id: DMA s2mm channel identifier
* @mm2s_chan_id: DMA mm2s channel identifier
* @max_buffer_len: Max buffer length
+ * @has_axistream_connected: AXI DMA connected to AXI Stream IP
*/
struct xilinx_dma_device {
void __iomem *regs;
@@ -509,6 +510,7 @@ struct xilinx_dma_device {
u32 s2mm_chan_id;
u32 mm2s_chan_id;
u32 max_buffer_len;
+ bool has_axistream_connected;
};
/* Macros */
@@ -621,6 +623,29 @@ static inline void xilinx_aximcdma_buf(struct
xilinx_dma_chan *chan,
}
}
+/**
+ * xilinx_dma_get_metadata_ptr- Populate metadata pointer and payload length
+ * @tx: async transaction descriptor
+ * @payload_len: metadata payload length
+ * @max_len: metadata max length
+ * Return: The app field pointer.
+ */
+static void *xilinx_dma_get_metadata_ptr(struct dma_async_tx_descriptor *tx,
+size_t *payload_len, size_t *max_len)
+{
+ struct xilinx_dma_tx_descriptor *desc = to_dma_tx_descriptor(tx);
+ struct xilinx_axidma_tx_segment *seg;
+
+ *max_len = *payload_len = sizeof(u32) * XILINX_DMA_NUM_APP_WORDS;
+ seg = list_first_entry(&desc->segments,
+ struct xilinx_axidma_tx_segment, node);
+ return seg->hw.app;
+}
+
+static struct dma_descriptor_metadata_ops xilinx_dma_metadata_ops = {
+ .get_ptr = xilinx_dma_get_metadata_ptr,
+};
+
/*
-
* Descriptors and segments alloc and free
*/
@@ -2200,6 +2225,9 @@ static struct dma_async_tx_descriptor
*xilinx_dma_prep_slave_sg(
segment->hw.control |= XILINX_DMA_BD_EOP;
}
+ if (chan->xdev->has_axistream_connected)
+ desc->async_tx.metadata_ops = &xilinx_dma_metadata_ops;
+
return &desc->async_tx;
error:
@@ -3032,6 +3060,11 @@ static int xilinx_dma_probe(struct platform_device *pdev)
}
}
+ if (xdev->dma_config->dmatype == XDMA_TYPE_AXIDMA) {
+ xdev->has_axistream_connected =
+ of_property_read_bool(node, "xlnx,axistream-connected");
+ }
+
if (xdev->dma_config->dmatype == XDMA_TYPE_VDMA) {
err = of_property_read_u32(node, "xlnx,num-fstores",
&num_frames);
@@ -3057,6 +3090,10 @@ static int xilinx_dma_probe(struct platform_device *pdev)
else
xdev->ext_addr = false;
+ /* Set metadata mode */
+ if (xdev->has_axistream_connected)
+ xdev->common.desc_metadata_modes = DESC_METADATA_ENGINE;
+
/* Set the dma mask bits */
dma_set_mask(xdev->dev, DMA_BIT_MASK(addr_width));
--
2.7.4
[RFC v2 PATCH 2/7] dt-bindings: dmaengine: xilinx_dma: Add xlnx,irq-delay property
Add an optional AXI DMA property 'xlnx,irq-delay'. It specifies interrupt timeout value and causes the DMA engine to generate an interrupt after the delay time period has expired. Timer begins counting at the end of a packet and resets with receipt of a new packet or a timeout event occurs. This property is useful when AXI DMA is connected to the streaming IP i.e axiethernet where inter packet latency is critical while still taking the benefit of interrupt coalescing. Signed-off-by: Radhey Shyam Pandey --- Changes for v2: - New patch. Introduce xlnx,irq-delay property for low latency usecases --- Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt b/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt index f5f23a4a4467..96009ced7b29 100644 --- a/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt +++ b/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt @@ -50,7 +50,9 @@ Optional properties for AXI DMA and MCDMA: is missing or invalid then the default value 23 is used. This is the maximum value that is supported by all IP versions. - xlnx,axistream-connected: Tells whether DMA is connected to AXI stream IP. - +- xlnx,irq-delay: Tells the interrupt delay timeout value. Valid range is from + 0-255. Setting this value to zero disables the delay timer interrupt. + 1 timeout interval = 125 * clock period of SG clock. Optional properties for VDMA: - xlnx,flush-fsync: Tells which channel to Flush on Frame sync. It takes following values: -- 2.7.4
RE: [EXTERNAL] [next] ERROR: modpost: "dns_query" [fs/cifs/cifs.ko] undefined
Attached the latest version of the patch. Regards, Shyam -Original Message- From: Naresh Kamboju Sent: Friday, April 9, 2021 11:24 PM To: Shyam Prasad Cc: Linux-Next Mailing List ; open list ; samba-techni...@lists.samba.org; lkft-tri...@lists.linaro.org; Maciek Borzecki ; Wan Jiabing ; Steven French ; pc ; Pavel Shilovskiy ; Steve French Subject: Re: [EXTERNAL] [next] ERROR: modpost: "dns_query" [fs/cifs/cifs.ko] undefined On Fri, 9 Apr 2021 at 23:17, Naresh Kamboju wrote: > > On Fri, 9 Apr 2021 at 21:49, Shyam Prasad wrote: > > > > Hi Naresh, > > > > AFAIK, this has been fixed in an updated patch last evening. Can you please > > check if you're still seeing it? > > Please share the fix commit and subject here. > > FYI, ignore the below statement. our build system did not trigger today tag yet. > This build error is still on today's Linux next tag 20210409. - Naresh 4e456b30f78c429b183db420e23b26cde7e03a78.patch Description: 4e456b30f78c429b183db420e23b26cde7e03a78.patch
[RFC v2 PATCH 1/7] dt-bindings: dmaengine: xilinx_dma: Add xlnx,axistream-connected property
Add an optional DMA property 'xlnx,axistream-connected'. This can be
specified to indicate that DMA is connected to a streaming IP in the
hardware design and dma driver needs to do some additional handling
i.e pass metadata and perform streaming IP specific configuration.
Signed-off-by: Radhey Shyam Pandey
---
Changes for v2:
- Rename xlnx,axieth-connected to xlnx,axistream-connected to
make it generic.
---
Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
b/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
index 325aca52cd43..f5f23a4a4467 100644
--- a/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
+++ b/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
@@ -49,6 +49,8 @@ Optional properties for AXI DMA and MCDMA:
register as configured in h/w. Takes values {8...26}. If the property
is missing or invalid then the default value 23 is used. This is the
maximum value that is supported by all IP versions.
+- xlnx,axistream-connected: Tells whether DMA is connected to AXI stream IP.
+
Optional properties for VDMA:
- xlnx,flush-fsync: Tells which channel to Flush on Frame sync.
It takes following values:
--
2.7.4
[RFC v2 PATCH 0/7] Xilinx DMA enhancements and optimization
Some background about the patch series: Xilinx Axi Ethernet device driver (xilinx_axienet_main.c) currently has axi-dma code inside it. The goal is to refactor axiethernet driver and use existing AXI DMA driver using DMAEngine API. This patchset does feature addition and optimization to support axidma integration with axiethernet network driver. Once axidma version is accepted mcdma specific changes will be added in followup version. This series is based on dmaengine tree commit: #a38fd8748464 Changes for v2: - Use metadata API[1] for passing metadata from dma to netdev client. - Read irq-delay from DT. - Remove desc_callback_valid check. - Addressed RFC v1 comments[2]. - Minor code refactoring. Comments, suggestions are very welcome! [1] https://www.spinics.net/lists/dmaengine/msg16583.html [2] https://www.spinics.net/lists/dmaengine/msg15208.html Radhey Shyam Pandey (7): dt-bindings: dmaengine: xilinx_dma: Add xlnx,axistream-connected property dt-bindings: dmaengine: xilinx_dma: Add xlnx,irq-delay property dmaengine: xilinx_dma: Pass AXI4-Stream control words to dma client dmaengine: xilinx_dma: Increase AXI DMA transaction segment count dmaengine: xilinx_dma: Freeup active list based on descriptor completion bit dmaengine: xilinx_dma: Use tasklet_hi_schedule for timing critical usecase dmaengine: xilinx_dma: Program interrupt delay timeout .../devicetree/bindings/dma/xilinx/xilinx_dma.txt | 4 ++ drivers/dma/xilinx/xilinx_dma.c| 68 ++ 2 files changed, 61 insertions(+), 11 deletions(-) -- 2.7.4
Re: [RFC net-next 1/1] seg6: add counters support for SRv6 Behaviors
On Wed, 7 Apr 2021 16:55:41 -0600
David Ahern wrote:
> On 4/7/21 12:03 PM, Andrea Mayer wrote:
> > diff --git a/include/uapi/linux/seg6_local.h
> > b/include/uapi/linux/seg6_local.h
> > index 3b39ef1dbb46..ae5e3fd12b73 100644
> > --- a/include/uapi/linux/seg6_local.h
> > +++ b/include/uapi/linux/seg6_local.h
> > @@ -27,6 +27,7 @@ enum {
> > SEG6_LOCAL_OIF,
> > SEG6_LOCAL_BPF,
> > SEG6_LOCAL_VRFTABLE,
> > + SEG6_LOCAL_COUNTERS,
> > __SEG6_LOCAL_MAX,
> > };
> > #define SEG6_LOCAL_MAX (__SEG6_LOCAL_MAX - 1)
> > @@ -78,4 +79,11 @@ enum {
> >
> > #define SEG6_LOCAL_BPF_PROG_MAX (__SEG6_LOCAL_BPF_PROG_MAX - 1)
> >
> > +/* SRv6 Behavior counters */
> > +struct seg6_local_counters {
> > + __u64 rx_packets;
> > + __u64 rx_bytes;
> > + __u64 rx_errors;
> > +};
> > +
> > #endif
>
> It's highly likely that more stats would get added over time. It would
> be good to document that here for interested parties and then make sure
> iproute2 can handle different sized stats structs. e.g., commit support
> to your repo, then add a new one (e.g, rx_drops) and verify the
> combinations handle it. e.g., old kernel - new iproute2, new kernel -
> old iproute, old - old and new-new.
>
Hi David,
thanks for your review.
I totally agree with you: we may want to add other counters in the future, even
if they are not considered in RFC8986.
With that in mind, the shared struct seg6_local_counters is not the best way to
go if we want to add other counters (because it will be difficult to manage
different sized structures when considering different kernel/iproute2 versions).
To make it easier adding new counters, instead of sharing the struct
seg6_local_counters, I would use netlink nested attributes to exchange counters
individually. In this way, only recognized (nested) attributes can be processed
by both the kernel and iproute2.
For example:
enum {
SEG6_LOCAL_CNT_UNSPEC,
SEG6_LOCAL_CNT_PAD, /* padding for 64 bits values */
SEG6_LOCAL_CNT_RX_PACKETS,
SEG6_LOCAL_CNT_RX_BYTES,
SEG6_LOCAL_CNT_RX_ERRORS,
__SEG6_LOCAL_CNT_MAX,
};
#define SEG6_LOCAL_CNT_MAX (__SEG6_LOCAL_CNT_MAX - 1)
updating the policy for SEG6_LOCAL_COUNTERS to NLA_NESTED.
Then, I create a new policy for counters which handles each supported
counter separately.
static const struct
nla_policy seg6_local_counters_policy[SEG6_LOCAL_CNT_MAX + 1] = {
[SEG6_LOCAL_CNT_RX_PACKETS] = { .type = NLA_U64 },
[SEG6_LOCAL_CNT_RX_BYTES] = { .type = NLA_U64 },
[SEG6_LOCAL_CNT_RX_ERRORS] = { .type = NLA_U64 },
};
At the end, I update the parse_nla_counters(), put_nla_counters(), etc
according to the changes, i.e:
- nla_parse_nested() in parse_nla_counters();
- nla_nest_{start/end}() and for each supported counter nla_put_u64_64bit()
in put_nla_counters().
On the iproute2 side, we have to update the code to reflect the changes
discussed above.
I plan to issue an RFC v2 in a few days.
Andrea
Re: [PATCH v1 1/2] dt-bindings: pwm: convert pwm-rockchip.txt to YAML
On Tue, Apr 06, 2021 at 05:50:52PM +0200, Johan Jonker wrote:
> Current dts files with 'pwm' nodes are manually verified.
> In order to automate this process pwm-rockchip.txt
> has to be converted to yaml.
>
> Signed-off-by: Johan Jonker
> ---
> .../devicetree/bindings/pwm/pwm-rockchip.txt | 27 -
> .../devicetree/bindings/pwm/pwm-rockchip.yaml | 66
> ++
> 2 files changed, 66 insertions(+), 27 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/pwm/pwm-rockchip.txt
> create mode 100644 Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml
>
> diff --git a/Documentation/devicetree/bindings/pwm/pwm-rockchip.txt
> b/Documentation/devicetree/bindings/pwm/pwm-rockchip.txt
> deleted file mode 100644
> index f70956dea..0
> --- a/Documentation/devicetree/bindings/pwm/pwm-rockchip.txt
> +++ /dev/null
> @@ -1,27 +0,0 @@
> -Rockchip PWM controller
> -
> -Required properties:
> - - compatible: should be "rockchip,-pwm"
> - "rockchip,rk2928-pwm": found on RK29XX,RK3066 and RK3188 SoCs
> - "rockchip,rk3288-pwm": found on RK3288 SOC
> - "rockchip,rv1108-pwm", "rockchip,rk3288-pwm": found on RV1108 SoC
> - "rockchip,vop-pwm": found integrated in VOP on RK3288 SoC
> - - reg: physical base address and length of the controller's registers
> - - clocks: See ../clock/clock-bindings.txt
> - - For older hardware (rk2928, rk3066, rk3188, rk3228, rk3288, rk3399):
> - - There is one clock that's used both to derive the functional clock
> - for the device and as the bus clock.
> - - For newer hardware (rk3328 and future socs): specified by name
> - - "pwm": This is used to derive the functional clock.
> - - "pclk": This is the APB bus clock.
> - - #pwm-cells: must be 2 (rk2928) or 3 (rk3288). See pwm.yaml in this
> directory
> - for a description of the cell format.
> -
> -Example:
> -
> - pwm0: pwm@2003 {
> - compatible = "rockchip,rk2928-pwm";
> - reg = <0x2003 0x10>;
> - clocks = <&cru PCLK_PWM01>;
> - #pwm-cells = <2>;
> - };
> diff --git a/Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml
> b/Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml
> new file mode 100644
> index 0..cfd637d3e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml
> @@ -0,0 +1,66 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/pwm/pwm-rockchip.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Rockchip PWM controller
> +
> +maintainers:
> + - Heiko Stuebner
> +
> +properties:
> + compatible:
> +oneOf:
> + - const: rockchip,rk2928-pwm
> + - const: rockchip,rk3288-pwm
> + - const: rockchip,vop-pwm
> + - items:
> + - enum:
> + - rockchip,rv1108-pwm
> + - const: rockchip,rk3288-pwm
> +
> + reg:
> +maxItems: 1
> +
> + clocks:
> +minItems: 1
> +maxItems: 2
> +description:
> + For older hardware (rk2928, rk3066, rk3188, rk3228, rk3288, rk3399)
> +There is one clock that is used both to derive the functional clock
> +for the device and as the bus clock.
> + For newer hardware (rk3328 and future SoCs) that is also specified
Can you express this with a schema.
> + with clock names.
> +"pwm" is used to derive the functional clock for the device.
> +"pclk" is used as the APB bus clock.
Let's not document the names twice.
> +
> + clock-names:
> +minItems: 1
> +items:
> + - const: pwm
> + - const: pclk
> +
> + "#pwm-cells":
> +enum: [2, 3]
> +description:
> + Must be 2 (rk2928) or 3 (rk3288).
> + See pwm.yaml for a description of the cell format.
> +
> +additionalProperties: false
> +
> +required:
> + - compatible
> + - reg
> + - clocks
> + - "#pwm-cells"
> +
> +examples:
> + - |
> +#include
> +pwm0: pwm@2003 {
> + compatible = "rockchip,rk2928-pwm";
> + reg = <0x2003 0x10>;
> + clocks = <&cru PCLK_PWM01>;
> + #pwm-cells = <2>;
> +};
> --
> 2.11.0
>
Re: [PATCH 0/3] nvmem: eeprom: add support for FRAM
Hi Jiri, I have two Fujitsu different FRAMs running with the stock at25 driver. I set the page size equal to the device size (as FRAMs have no pages). Are you able to run your FRAM with the unmodified driver? I assume that getting the device geometry from the chip is vendor specific (in contrast to flash devices which have standard commands for this). I suppose that there is no much value getting vendor specific information from a chip. If the drivers knows the vendor, it should also know the chip (e.g. from the dt). regards Christian On Friday, 9 April 2021, 17:47:17 CEST, Jiri Prchal wrote: > Adds sopport for Cypress FRAMs. > > Jiri Prchal (3): > nvmem: eeprom: at25: add support for FRAM > nvmem: eeprom: at25: add support for FRAM > nvmem: eeprom: add documentation for FRAM > > .../devicetree/bindings/eeprom/at25.yaml | 12 +- > drivers/misc/eeprom/Kconfig | 5 +- > drivers/misc/eeprom/at25.c| 151 ++ > drivers/nvmem/core.c | 4 + > include/linux/nvmem-provider.h| 1 + > 5 files changed, 139 insertions(+), 34 deletions(-) > >
Re: [EXTERNAL] [next] ERROR: modpost: "dns_query" [fs/cifs/cifs.ko] undefined
On Fri, 9 Apr 2021 at 23:17, Naresh Kamboju wrote: > > On Fri, 9 Apr 2021 at 21:49, Shyam Prasad wrote: > > > > Hi Naresh, > > > > AFAIK, this has been fixed in an updated patch last evening. Can you please > > check if you're still seeing it? > > Please share the fix commit and subject here. > > FYI, ignore the below statement. our build system did not trigger today tag yet. > This build error is still on today's Linux next tag 20210409. - Naresh
Re: [PATCH 4/7] rpmsg: char: Introduce __rpmsg_chrdev_create_eptdev function
On Tue, Mar 23, 2021 at 01:27:34PM +0100, Arnaud Pouliquen wrote:
> Introduce the __rpmsg_chrdev_create_eptdev internal function that returns
> the rpmsg_eptdev context structure.
>
> This patch prepares the introduction of a rpmsg channel device for the
> char device. The rpmsg device will need a reference to the context.
>
> Signed-off-by: Arnaud Pouliquen
>
> ---
> update from [1]
> - propagate parent param in rpmsg_chrdev_create_eptdev,
> - fix changelog.
>
> [1]
> https://patchwork.kernel.org/project/linux-remoteproc/patch/20210219111501.14261-14-arnaud.pouliq...@foss.st.com/
> ---
> drivers/rpmsg/rpmsg_char.c | 21 +
> 1 file changed, 17 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/rpmsg/rpmsg_char.c b/drivers/rpmsg/rpmsg_char.c
> index 5d4a768002ce..7f6d46078179 100644
> --- a/drivers/rpmsg/rpmsg_char.c
> +++ b/drivers/rpmsg/rpmsg_char.c
> @@ -325,7 +325,8 @@ static void rpmsg_eptdev_release_device(struct device
> *dev)
> kfree(eptdev);
> }
>
> -int rpmsg_chrdev_create_eptdev(struct rpmsg_device *rpdev, struct device
> *parent,
> +static struct rpmsg_eptdev *__rpmsg_chrdev_create_eptdev(struct rpmsg_device
> *rpdev,
> + struct device *parent,
> struct rpmsg_channel_info chinfo, struct class
> *rpmsg_class)
Please fix:
static struct rpmsg_eptdev *
__rpmsg_chrdev_create_eptdev(struct rpmsg_device *rpdev, struct device *parent,
struct rpmsg_channel_info chinfo, struct class
*rpmsg_class)
> {
> struct rpmsg_eptdev *eptdev;
> @@ -334,7 +335,7 @@ int rpmsg_chrdev_create_eptdev(struct rpmsg_device
> *rpdev, struct device *parent
>
> eptdev = kzalloc(sizeof(*eptdev), GFP_KERNEL);
> if (!eptdev)
> - return -ENOMEM;
> + return ERR_PTR(-ENOMEM);
>
> dev = &eptdev->dev;
> eptdev->rpdev = rpdev;
> @@ -378,7 +379,7 @@ int rpmsg_chrdev_create_eptdev(struct rpmsg_device
> *rpdev, struct device *parent
> put_device(dev);
> }
>
> - return ret;
> + return eptdev;
>
> free_ept_ida:
> ida_simple_remove(&rpmsg_ept_ida, dev->id);
> @@ -388,7 +389,19 @@ int rpmsg_chrdev_create_eptdev(struct rpmsg_device
> *rpdev, struct device *parent
> put_device(dev);
> kfree(eptdev);
>
> - return ret;
> + return ERR_PTR(ret);
> +}
> +
> +int rpmsg_chrdev_create_eptdev(struct rpmsg_device *rpdev, struct device
> *parent,
> +struct rpmsg_channel_info chinfo, struct class
> *rpmsg_class)
> +{
> + struct rpmsg_eptdev *eptdev;
> +
> + eptdev = __rpmsg_chrdev_create_eptdev(rpdev, parent, chinfo,
> rpmsg_class);
> + if (IS_ERR(eptdev))
> + return PTR_ERR(eptdev);
> +
> + return 0;
> }
> EXPORT_SYMBOL(rpmsg_chrdev_create_eptdev);
>
> --
> 2.17.1
>
[PATCH] xattr: simplify logic at xattr_resolve_name()
The negative case check logic with XOR operation between the
two variables with negated values is really hard to comprehend.
Change it to positive case check with == instead of XOR.
Signed-off-by: Andriy Tkachuk
---
fs/xattr.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/fs/xattr.c b/fs/xattr.c
index b3444e06cd..531562535d 100644
--- a/fs/xattr.c
+++ b/fs/xattr.c
@@ -66,13 +66,13 @@ xattr_resolve_name(struct inode *inode, const char **name)
n = strcmp_prefix(*name, xattr_prefix(handler));
if (n) {
- if (!handler->prefix ^ !*n) {
- if (*n)
- continue;
- return ERR_PTR(-EINVAL);
+ if (!handler->prefix == !*n) {
+ *name = n;
+ return handler;
}
- *name = n;
- return handler;
+ if (*n)
+ continue;
+ return ERR_PTR(-EINVAL);
}
}
return ERR_PTR(-EOPNOTSUPP);
--
2.27.0
Re: [PATCH rdma-next 00/10] Enable relaxed ordering for ULPs
On 4/9/2021 12:27 PM, Haakon Bugge wrote: On 9 Apr 2021, at 17:32, Tom Talpey wrote: On 4/9/2021 10:45 AM, Chuck Lever III wrote: On Apr 9, 2021, at 10:26 AM, Tom Talpey wrote: On 4/6/2021 7:49 AM, Jason Gunthorpe wrote: On Mon, Apr 05, 2021 at 11:42:31PM +, Chuck Lever III wrote: We need to get a better idea what correctness testing has been done, and whether positive correctness testing results can be replicated on a variety of platforms. RO has been rolling out slowly on mlx5 over a few years and storage ULPs are the last to change. eg the mlx5 ethernet driver has had RO turned on for a long time, userspace HPC applications have been using it for a while now too. I'd love to see RO be used more, it was always something the RDMA specs supported and carefully architected for. My only concern is that it's difficult to get right, especially when the platforms have been running strictly-ordered for so long. The ULPs need testing, and a lot of it. We know there are platforms with broken RO implementations (like Haswell) but the kernel is supposed to globally turn off RO on all those cases. I'd be a bit surprised if we discover any more from this series. On the other hand there are platforms that get huge speed ups from turning this on, AMD is one example, there are a bunch in the ARM world too. My belief is that the biggest risk is from situations where completions are batched, and therefore polling is used to detect them without interrupts (which explicitly). The RO pipeline will completely reorder DMA writes, and consumers which infer ordering from memory contents may break. This can even apply within the provider code, which may attempt to poll WR and CQ structures, and be tripped up. You are referring specifically to RPC/RDMA depending on Receive completions to guarantee that previous RDMA Writes have been retired? Or is there a particular implementation practice in the Linux RPC/RDMA code that worries you? Nothing in the RPC/RDMA code, which is IMO correct. The worry, which is hopefully unfounded, is that the RO pipeline might not have flushed when a completion is posted *after* posting an interrupt. Something like this... RDMA Write arrives PCIe RO Write for data PCIe RO Write for data ... RDMA Write arrives PCIe RO Write for data ... RDMA Send arrives PCIe RO Write for receive data PCIe RO Write for receive descriptor Do you mean the Write of the CQE? It has to be Strongly Ordered for a correct implementation. Then it will shure prior written RO date has global visibility when the CQE can be observed. I wasn't aware that a strongly-ordered PCIe Write will ensure that prior relaxed-ordered writes went first. If that's the case, I'm fine with it - as long as the providers are correctly coded!! PCIe interrupt (flushes RO pipeline for all three ops above) Before the interrupt, the HCA will write the EQE (Event Queue Entry). This has to be a Strongly Ordered write to "push" prior written CQEs so that when the EQE is observed, the prior writes of CQEs have global visibility. And the MSI-X write likewise, to avoid spurious interrupts. Ok, and yes agreed the same principle would apply. Is there any implication if a PCIe switch were present on the motherboard? The switch is allowed to do some creative routing if the operation is relaxed, correct? Tom. Thxs, Håkon RPC/RDMA polls CQ Reaps receive completion RDMA Send arrives PCIe RO Write for receive data PCIe RO write for receive descriptor Does *not* interrupt, since CQ not armed RPC/RDMA continues to poll CQ Reaps receive completion PCIe RO writes not yet flushed Processes incomplete in-memory data Bzzzt Hopefully, the adapter performs a PCIe flushing read, or something to avoid this when an interrupt is not generated. Alternatively, I'm overly paranoid. Tom. The Mellanox adapter, itself, historically has strict in-order DMA semantics, and while it's great to relax that, changing it by default for all consumers is something to consider very cautiously. Still, obviously people should test on the platforms they have. Yes, and "test" be taken seriously with focus on ULP data integrity. Speedups will mean nothing if the data is ever damaged. I agree that data integrity comes first. Since I currently don't have facilities to test RO in my lab, the community will have to agree on a set of tests and expected results that specifically exercise the corner cases you are concerned about. -- Chuck Lever
Re: [EXTERNAL] [next] ERROR: modpost: "dns_query" [fs/cifs/cifs.ko] undefined
On Fri, 9 Apr 2021 at 21:49, Shyam Prasad wrote: > > Hi Naresh, > > AFAIK, this has been fixed in an updated patch last evening. Can you please > check if you're still seeing it? Please share the fix commit and subject here. FYI, This build error is still on today's Linux next tag 20210409. - Naresh
Re: [PATCH] mailmap: Update email address for Nicolas Saenz
On Fri, 9 Apr 2021 13:14:53 +0200, Nicolas Saenz Julienne wrote: > Add my kernel.org address for old email address. > > Signed-off-by: Nicolas Saenz Julienne > --- Applied to maintainers/next, thanks! -- Florian
[GIT PULL] SELinux fixes for v5.12 (#2)
Hi Linus, I realize we are getting late in the v5.12-rcX release cycle, but we have three SELinux patches which I believe should be merged before the proper v5.12 release. The patches fix known problems relating to (re)loading SELinux policy or changing the policy booleans, and pass our test suite without problem. As of a few minutes ago, the tag below also merged cleanly into your tree. Please pull for the next v5.12-rcX release, thanks. -Paul -- The following changes since commit ee5de60a08b7d8d255722662da461ea159c15538: selinuxfs: unify policy load error reporting (2021-03-18 23:26:59 -0400) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/selinux.git tags/selinux-pr-20210409 for you to fetch changes up to 9ad6e9cb39c66366bf7b9aece114aca277981a1f: selinux: fix race between old and new sidtab (2021-04-07 20:42:56 -0400) selinux/stable-5.12 PR 20210409 Ondrej Mosnacek (3): selinux: make nslot handling in avtab more robust selinux: fix cond_list corruption when changing booleans selinux: fix race between old and new sidtab security/selinux/ss/avtab.c | 101 security/selinux/ss/avtab.h | 2 +- security/selinux/ss/conditional.c | 12 +-- security/selinux/ss/services.c| 157 +++--- security/selinux/ss/sidtab.c | 21 + security/selinux/ss/sidtab.h | 4 + 6 files changed, 185 insertions(+), 112 deletions(-) -- paul moore www.paul-moore.com
Re: [PATCH rdma-next 00/10] Enable relaxed ordering for ULPs
On 4/9/2021 12:40 PM, Jason Gunthorpe wrote: On Fri, Apr 09, 2021 at 10:26:21AM -0400, Tom Talpey wrote: My belief is that the biggest risk is from situations where completions are batched, and therefore polling is used to detect them without interrupts (which explicitly). We don't do this in the kernel. All kernel ULPs only read data after they observe the CQE. We do not have "last data polling" and our interrupt model does not support some hacky "interrupt means go and use the data" approach. ULPs have to be designed this way to use the DMA API properly. Yep. Totally agree. My concern was about the data being written as relaxed, and the CQE racing it. I'll reply in the other fork. Fencing a DMA before it is completed by the HW will cause IOMMU errors. Userspace is a different story, but that will remain as-is with optional relaxed ordering. Jason
Re: [Outreachy kernel][PATCH] staging: media: hantro: Rewrite macro function in lower case
On Fri, 2021-04-09 at 19:25 +0200, Julia Lawall wrote: > > > On Fri, 9 Apr 2021, ascordeiro wrote: > > > Em sex, 2021-04-09 às 13:44 -0300, Ezequiel Garcia escreveu: > > > Hi Aline, > > > > Hi Ezequiel, > > > > > > On Fri, 2021-04-09 at 10:54 -0300, Aline Santana Cordeiro wrote: > > > > Rewrite macros resembling functions #define HANTRO_PP_REG_WRITE > > > > and #define HANTRO_PP_RED_WRITE_S in lower case, according with > > > > code style. > > Maybe you can see if these macros can be converted to static inline > functions. Macros don't provide any type checking. > I'd like to leave these as they are for now, tbh ^_^ A more massive refactoring is needed in this driver, but it needs proper testing and it's a more complex plan. Thanks! Ezequiel
Re: [PATCH 1/5] x86/cpufeatures: Define feature bits to support mitigation of PSF
On Tue, Apr 06, 2021 at 10:50:00AM -0500, Ramakrishna Saripalli wrote: > diff --git a/arch/x86/include/asm/cpufeatures.h > b/arch/x86/include/asm/cpufeatures.h > index cc96e26d69f7..21e7f8d0d7d9 100644 > --- a/arch/x86/include/asm/cpufeatures.h > +++ b/arch/x86/include/asm/cpufeatures.h > @@ -201,7 +201,7 @@ > #define X86_FEATURE_INVPCID_SINGLE ( 7*32+ 7) /* Effectively INVPCID && > CR4.PCIDE=1 */ > #define X86_FEATURE_HW_PSTATE( 7*32+ 8) /* AMD HW-PState */ > #define X86_FEATURE_PROC_FEEDBACK( 7*32+ 9) /* AMD ProcFeedbackInterface > */ > -/* FREE!( 7*32+10) */ > +#define X86_FEATURE_PSFD ( 7*32+10) /* Predictive Store Forward > Disable */ You don't need this one... > #define X86_FEATURE_PTI ( 7*32+11) /* Kernel Page Table > Isolation enabled */ > #define X86_FEATURE_RETPOLINE( 7*32+12) /* "" Generic > Retpoline mitigation for Spectre variant 2 */ > #define X86_FEATURE_RETPOLINE_AMD( 7*32+13) /* "" AMD Retpoline > mitigation for Spectre variant 2 */ > @@ -309,6 +309,7 @@ > #define X86_FEATURE_AMD_SSBD (13*32+24) /* "" Speculative Store > Bypass Disable */ > #define X86_FEATURE_VIRT_SSBD(13*32+25) /* Virtualized > Speculative Store Bypass Disable */ > #define X86_FEATURE_AMD_SSB_NO (13*32+26) /* "" Speculative > Store Bypass is fixed in hardware. */ > +#define X86_FEATURE_AMD_PSFD (13*32+28) /* "" Predictive Store > Forward Disable */ ... when you have this one. And this one is AMD-specific so you can just as well call it X86_FEATURE_PSFD and remove the "". > > /* Thermal and Power Management Leaf, CPUID level 0x0006 (EAX), word 14 > */ > #define X86_FEATURE_DTHERM (14*32+ 0) /* Digital Thermal Sensor */ > @@ -428,5 +429,6 @@ > #define X86_BUG_TAA X86_BUG(22) /* CPU is affected by TSX > Async Abort(TAA) */ > #define X86_BUG_ITLB_MULTIHITX86_BUG(23) /* CPU may incur > MCE during certain page attribute changes */ > #define X86_BUG_SRBDSX86_BUG(24) /* CPU may leak RNG > bits if not mitigated */ > +#define X86_BUG_PSF X86_BUG(25) /* CPU is affected by > Predictive Store Forwarding attack */ And I think you don't need this one either if we do a "light" controls thing but lemme look at the rest first. Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette
Re: [RFC Part1 PATCH 11/13] x86/kernel: validate rom memory before accessing when SEV-SNP is active
On 4/9/21 11:53 AM, Borislav Petkov wrote:
> On Wed, Mar 24, 2021 at 11:44:22AM -0500, Brijesh Singh wrote:
>> +/*
>> + * The ROM memory is not part of the E820 system RAM and is not
>> prevalidated by the BIOS.
>> + * The kernel page table maps the ROM region as encrypted memory, the
>> SEV-SNP requires
>> + * the all the encrypted memory must be validated before the access.
>> + */
>> +if (sev_snp_active()) {
>> +unsigned long n, paddr;
>> +
>> +n = ((system_rom_resource.end + 1) - video_rom_resource.start)
>> >> PAGE_SHIFT;
>> +paddr = video_rom_resource.start;
>> +early_snp_set_memory_private((unsigned long)__va(paddr), paddr,
>> n);
>> +}
> I don't like this sprinkling of SNP-special stuff that needs to be done,
> around the tree. Instead, pls define a function called
>
> snp_prep_memory(unsigned long pa, unsigned int num_pages, enum
> operation);
>
> or so which does all the manipulation needed and the callsites only
> simply unconditionally call that function so that all detail is
> extracted and optimized away when not config-enabled.
Sure, I will do this in the next rev.
>
> Thx.
>
[gustavoars-linux:testing/xfs-series] BUILD SUCCESS 387b2370698815b609f6e035e28a47980ee9b36d
mvme5100_defconfig cskydefconfig armcerfcube_defconfig mips maltaaprp_defconfig sh urquell_defconfig arc axs103_smp_defconfig powerpc taishan_defconfig sh rts7751r2dplus_defconfig powerpc ppa8548_defconfig mips xway_defconfig powerpc eiger_defconfig mips rbtx49xx_defconfig powerpc ksi8560_defconfig mips ip28_defconfig powerpcadder875_defconfig arm mv78xx0_defconfig arm multi_v4t_defconfig xtensa cadence_csp_defconfig powerpc64 defconfig sh sdk7780_defconfig sh secureedge5410_defconfig arm versatile_defconfig arcnsimosci_defconfig ia64defconfig ia64 allmodconfig m68k allmodconfig m68k allyesconfig arc allyesconfig nds32 allnoconfig nds32 defconfig nios2allyesconfig alpha defconfig alphaallyesconfig arc defconfig xtensa allyesconfig h8300allyesconfig sh allmodconfig parisc defconfig s390 allmodconfig parisc allyesconfig s390 allyesconfig sparcallyesconfig sparc defconfig i386defconfig mips allyesconfig mips allmodconfig powerpc allyesconfig powerpc allnoconfig i386 randconfig-a006-20210409 i386 randconfig-a003-20210409 i386 randconfig-a001-20210409 i386 randconfig-a004-20210409 i386 randconfig-a002-20210409 i386 randconfig-a005-20210409 x86_64 randconfig-a014-20210409 x86_64 randconfig-a015-20210409 x86_64 randconfig-a012-20210409 x86_64 randconfig-a011-20210409 x86_64 randconfig-a013-20210409 x86_64 randconfig-a016-20210409 i386 randconfig-a014-20210409 i386 randconfig-a011-20210409 i386 randconfig-a016-20210409 i386 randconfig-a012-20210409 i386 randconfig-a013-20210409 i386 randconfig-a015-20210409 riscvnommu_virt_defconfig riscv allnoconfig riscv defconfig riscv rv32_defconfig um allmodconfig umallnoconfig um allyesconfig um defconfig x86_64rhel-8.3-kselftests x86_64 defconfig x86_64 rhel-8.3 x86_64 rhel-8.3-kbuiltin x86_64 kexec clang tested configs: x86_64 randconfig-a004-20210409 x86_64 randconfig-a005-20210409 x86_64 randconfig-a003-20210409 x86_64 randconfig-a001-20210409 x86_64 randconfig-a002-20210409 x86_64 randconfig-a006-20210409 --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
Re: [Outreachy kernel] Re: [PATCH 1/2 v2] staging: media: hantro: Align line break to the open parenthesis in file hantro_hw.h
On Thu, 8 Apr 2021, Ezequiel Garcia wrote: > Ola Aline, > > Welcome to the kernel community. Hope you enjoy some of this > Outreachy adventures. > > Normally, when you submit a v2, we want to know what changed > between the first submission and v2. > > If you are subscribed to linux-media, you can read some > of the series with a vN+1 and look how it's done. Examples: > > https://www.spinics.net/lists/linux-media/msg190043.html > > https://www.spinics.net/lists/linux-media/msg189923.html > > I'm sure your Outreachy mentors can tell you more. There is information in the kernelnewbies tutorial about how to resubmit patches. julia > > On Thu, 2021-04-08 at 11:07 -0300, Aline Santana Cordeiro wrote: > > Aligns line break with the remaining function arguments > > to the open parenthesis. Issue found by checkpatch. > > > > Signed-off-by: Aline Santana Cordeiro > > --- > > drivers/staging/media/hantro/hantro_hw.h | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/staging/media/hantro/hantro_hw.h > > b/drivers/staging/media/hantro/hantro_hw.h > > index 34c9e46..a650b9c 100644 > > --- a/drivers/staging/media/hantro/hantro_hw.h > > +++ b/drivers/staging/media/hantro/hantro_hw.h > > @@ -207,7 +207,7 @@ hantro_h264_mv_size(unsigned int width, unsigned int > > height) > > void hantro_g1_mpeg2_dec_run(struct hantro_ctx *ctx); > > void rk3399_vpu_mpeg2_dec_run(struct hantro_ctx *ctx); > > void hantro_mpeg2_dec_copy_qtable(u8 *qtable, > > - const struct v4l2_ctrl_mpeg2_quantization *ctrl); > > + const struct v4l2_ctrl_mpeg2_quantization > > *ctrl); > > int hantro_mpeg2_dec_init(struct hantro_ctx *ctx); > > void hantro_mpeg2_dec_exit(struct hantro_ctx *ctx); > > > > > -- > You received this message because you are subscribed to the Google Groups > "outreachy-kernel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to outreachy-kernel+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/outreachy-kernel/d4000598fddcf45e578462aa04b556c0ca057091.camel%40collabora.com. >
Re: [Outreachy kernel][PATCH] staging: media: hantro: Rewrite macro function in lower case
Em sex, 2021-04-09 às 19:25 +0200, Julia Lawall escreveu:
>
>
> On Fri, 9 Apr 2021, ascordeiro wrote:
>
> > Em sex, 2021-04-09 às 13:44 -0300, Ezequiel Garcia escreveu:
> > > Hi Aline,
> >
> > Hi Ezequiel,
> > >
> > > On Fri, 2021-04-09 at 10:54 -0300, Aline Santana Cordeiro wrote:
> > > > Rewrite macros resembling functions #define HANTRO_PP_REG_WRITE
> > > > and #define HANTRO_PP_RED_WRITE_S in lower case, according with
> > > > code style.
>
> Maybe you can see if these macros can be converted to static inline
> functions. Macros don't provide any type checking.
Okay! I'm going to check this option.
Thank you for the advice!
Aline
>
> julia
>
> > > >
> > >
> > > Where is this written in the Coding Style?
> >
> > I found this in section 12, about Macros, Enums and RTL in both
> > references:
> > https://www.kernel.org/doc/html/latest/process/coding-style.html
> > https://elixir.bootlin.com/linux/latest/source/Documentation/process/coding-style.rst
> > >
> > > Thanks!
> > > Ezequiel
> >
> > Thank you!
> > Aline
> > >
> > > > Signed-off-by: Aline Santana Cordeiro <
> > > > alinesantanacorde...@gmail.com>
> > > > ---
> > > > drivers/staging/media/hantro/hantro_postproc.c | 34
> > > > +-
> > > >
> > > > 1 file changed, 17 insertions(+), 17 deletions(-)
> > > >
> > > > diff --git a/drivers/staging/media/hantro/hantro_postproc.c
> > > > b/drivers/staging/media/hantro/hantro_postproc.c
> > > > index 6d2a8f2a..06279c0 100644
> > > > --- a/drivers/staging/media/hantro/hantro_postproc.c
> > > > +++ b/drivers/staging/media/hantro/hantro_postproc.c
> > > > @@ -12,14 +12,14 @@
> > > > #include "hantro_hw.h"
> > > > #include "hantro_g1_regs.h"
> > > >
> > > > -#define HANTRO_PP_REG_WRITE(vpu, reg_name, val) \
> > > > +#define hantro_pp_reg_write(vpu, reg_name, val) \
> > > > { \
> > > > hantro_reg_write(vpu, \
> > > > &(vpu)->variant->postproc_regs-
> > > > >reg_name,
> > > > \
> > > > val); \
> > > > }
> > > >
> > > > -#define HANTRO_PP_REG_WRITE_S(vpu, reg_name, val) \
> > > > +#define hantro_pp_reg_write_s(vpu, reg_name, val) \
> > > > { \
> > > > hantro_reg_write_s(vpu, \
> > > > &(vpu)->variant->postproc_regs-
> > > > > reg_name, \
> > > > @@ -61,7 +61,7 @@ void hantro_postproc_enable(struct hantro_ctx
> > > > *ctx)
> > > > return;
> > > >
> > > > /* Turn on pipeline mode. Must be done first. */
> > > > - HANTRO_PP_REG_WRITE_S(vpu, pipeline_en, 0x1);
> > > > + hantro_pp_reg_write_s(vpu, pipeline_en, 0x1);
> > > >
> > > > src_pp_fmt = VPU_PP_IN_NV12;
> > > >
> > > > @@ -79,19 +79,19 @@ void hantro_postproc_enable(struct
> > > > hantro_ctx
> > > > *ctx)
> > > > dst_buf = v4l2_m2m_next_dst_buf(ctx->fh.m2m_ctx);
> > > > dst_dma = vb2_dma_contig_plane_dma_addr(&dst_buf-
> > > > >vb2_buf,
> > > > 0);
> > > >
> > > > - HANTRO_PP_REG_WRITE(vpu, clk_gate, 0x1);
> > > > - HANTRO_PP_REG_WRITE(vpu, out_endian, 0x1);
> > > > - HANTRO_PP_REG_WRITE(vpu, out_swap32, 0x1);
> > > > - HANTRO_PP_REG_WRITE(vpu, max_burst, 16);
> > > > - HANTRO_PP_REG_WRITE(vpu, out_luma_base, dst_dma);
> > > > - HANTRO_PP_REG_WRITE(vpu, input_width, MB_WIDTH(ctx-
> > > > > dst_fmt.width));
> > > > - HANTRO_PP_REG_WRITE(vpu, input_height, MB_HEIGHT(ctx-
> > > > > dst_fmt.height));
> > > > - HANTRO_PP_REG_WRITE(vpu, input_fmt, src_pp_fmt);
> > > > - HANTRO_PP_REG_WRITE(vpu, output_fmt, dst_pp_fmt);
> > > > - HANTRO_PP_REG_WRITE(vpu, output_width, ctx-
> > > > >dst_fmt.width);
> > > > - HANTRO_PP_REG_WRITE(vpu, output_height, ctx-
> > > > > dst_fmt.height);
> > > > - HANTRO_PP_REG_WRITE(vpu, orig_width, MB_WIDTH(ctx-
> > > > > dst_fmt.width));
> > > > - HANTRO_PP_REG_WRITE(vpu, display_width, ctx-
> > > > > dst_fmt.width);
> > > > + hantro_pp_reg_write(vpu, clk_gate, 0x1);
> > > > + hantro_pp_reg_write(vpu, out_endian, 0x1);
> > > > + hantro_pp_reg_write(vpu, out_swap32, 0x1);
> > > > + hantro_pp_reg_write(vpu, max_burst, 16);
> > > > + hantro_pp_reg_write(vpu, out_luma_base, dst_dma);
> > > > + hantro_pp_reg_write(vpu, input_width, MB_WIDTH(ctx-
> > > > > dst_fmt.width));
> > > > + hantro_pp_reg_write(vpu, input_height, MB_HEIGHT(ctx-
> > > > > dst_fmt.height));
> > > > + hantro_pp_reg_write(vpu, input_fmt, src_pp_fmt);
> > > > + hantro_pp_reg_write(vpu, output_fmt, dst_pp_fmt);
> > > > + hantro_pp_reg_write(vpu, output_width, ctx-
> > > > >dst_fmt.width);
> > > > + hantro_pp_reg_write(vpu, output_height, ctx-
> > > > > dst_fmt.height);
> > > > + hantro_pp_reg_write(vpu, orig_width, MB_WIDTH(ctx-
> > > > > dst_fmt.width));
> > > > + hantro_pp_reg_write(vpu, display_width, ctx-
> > > > > dst_fmt.width);
> > > > }
> > > >
> > > > void hantro_postproc_free(struct hantro_ctx *ctx)
> > >
Re: [PATCH 2/7] rpmsg: Move the rpmsg control device from rpmsg_char to rpmsg_ctrl
On Tue, Mar 23, 2021 at 01:27:32PM +0100, Arnaud Pouliquen wrote:
> Create the rpmsg_ctrl.c module and move the code related to the
> rpmsg_ctrldev device in this new module.
>
> Add the dependency between rpmsg_char and rpmsg_ctrl in the
> kconfig file.
>
> Signed-off-by: Arnaud Pouliquen
> ---
> update from [1]:
> - keep rpmsg_ctrldev prefix (no more functions and structures renaming),
>
That is much better
> [1]:
> https://patchwork.kernel.org/project/linux-remoteproc/patch/20210219111501.14261-7-arnaud.pouliq...@foss.st.com/
> ---
> drivers/rpmsg/Kconfig | 9 ++
> drivers/rpmsg/Makefile | 1 +
> drivers/rpmsg/rpmsg_char.c | 177 +---
> drivers/rpmsg/rpmsg_ctrl.c | 233 +
> 4 files changed, 244 insertions(+), 176 deletions(-)
> create mode 100644 drivers/rpmsg/rpmsg_ctrl.c
>
> diff --git a/drivers/rpmsg/Kconfig b/drivers/rpmsg/Kconfig
> index 0b4407abdf13..d822ec9ec692 100644
> --- a/drivers/rpmsg/Kconfig
> +++ b/drivers/rpmsg/Kconfig
> @@ -10,11 +10,20 @@ config RPMSG_CHAR
> tristate "RPMSG device interface"
> depends on RPMSG
> depends on NET
> + select RPMSG_CTRL
> help
> Say Y here to export rpmsg endpoints as device files, usually found
> in /dev. They make it possible for user-space programs to send and
> receive rpmsg packets.
>
> +config RPMSG_CTRL
> + tristate "RPMSG control interface"
> + depends on RPMSG
> + help
> + Say Y here to enable the support of the /dev/rpmsg_ctrlX API. This API
> + allows user-space programs to create endpoints with specific service
> name,
> + source and destination addresses.
> +
> config RPMSG_NS
> tristate "RPMSG name service announcement"
> depends on RPMSG
> diff --git a/drivers/rpmsg/Makefile b/drivers/rpmsg/Makefile
> index 8d452656f0ee..58e3b382e316 100644
> --- a/drivers/rpmsg/Makefile
> +++ b/drivers/rpmsg/Makefile
> @@ -1,6 +1,7 @@
> # SPDX-License-Identifier: GPL-2.0
> obj-$(CONFIG_RPMSG) += rpmsg_core.o
> obj-$(CONFIG_RPMSG_CHAR) += rpmsg_char.o
> +obj-$(CONFIG_RPMSG_CTRL) += rpmsg_ctrl.o
> obj-$(CONFIG_RPMSG_NS) += rpmsg_ns.o
> obj-$(CONFIG_RPMSG_MTK_SCP) += mtk_rpmsg.o
> qcom_glink-objs := qcom_glink_native.o qcom_glink_ssr.o
> diff --git a/drivers/rpmsg/rpmsg_char.c b/drivers/rpmsg/rpmsg_char.c
> index b9df8dc4365f..5d4a768002ce 100644
> --- a/drivers/rpmsg/rpmsg_char.c
> +++ b/drivers/rpmsg/rpmsg_char.c
> @@ -29,30 +29,13 @@
> #define RPMSG_DEV_MAX(MINORMASK + 1)
>
That define is also present in rpmsg_ctrl.c. As such I would move it to
rpmsg_char.h.
> static dev_t rpmsg_major;
> -static struct class *rpmsg_class;
>
> -static DEFINE_IDA(rpmsg_ctrl_ida);
> static DEFINE_IDA(rpmsg_ept_ida);
> static DEFINE_IDA(rpmsg_minor_ida);
>
> #define dev_to_eptdev(dev) container_of(dev, struct rpmsg_eptdev, dev)
> #define cdev_to_eptdev(i_cdev) container_of(i_cdev, struct rpmsg_eptdev,
> cdev)
>
> -#define dev_to_ctrldev(dev) container_of(dev, struct rpmsg_ctrldev, dev)
> -#define cdev_to_ctrldev(i_cdev) container_of(i_cdev, struct rpmsg_ctrldev,
> cdev)
> -
> -/**
> - * struct rpmsg_ctrldev - control device for instantiating endpoint devices
> - * @rpdev: underlaying rpmsg device
> - * @cdev:cdev for the ctrl device
> - * @dev: device for the ctrl device
> - */
> -struct rpmsg_ctrldev {
> - struct rpmsg_device *rpdev;
> - struct cdev cdev;
> - struct device dev;
> -};
> -
> /**
> * struct rpmsg_eptdev - endpoint device context
> * @dev: endpoint device
> @@ -409,169 +392,13 @@ int rpmsg_chrdev_create_eptdev(struct rpmsg_device
> *rpdev, struct device *parent
> }
> EXPORT_SYMBOL(rpmsg_chrdev_create_eptdev);
>
> -static int rpmsg_ctrldev_open(struct inode *inode, struct file *filp)
> -{
> - struct rpmsg_ctrldev *ctrldev = cdev_to_ctrldev(inode->i_cdev);
> -
> - get_device(&ctrldev->dev);
> - filp->private_data = ctrldev;
> -
> - return 0;
> -}
> -
> -static int rpmsg_ctrldev_release(struct inode *inode, struct file *filp)
> -{
> - struct rpmsg_ctrldev *ctrldev = cdev_to_ctrldev(inode->i_cdev);
> -
> - put_device(&ctrldev->dev);
> -
> - return 0;
> -}
> -
> -static long rpmsg_ctrldev_ioctl(struct file *fp, unsigned int cmd,
> - unsigned long arg)
> -{
> - struct rpmsg_ctrldev *ctrldev = fp->private_data;
> - void __user *argp = (void __user *)arg;
> - struct rpmsg_endpoint_info eptinfo;
> - struct rpmsg_channel_info chinfo;
> -
> - if (cmd != RPMSG_CREATE_EPT_IOCTL)
> - return -EINVAL;
> -
> - if (copy_from_user(&eptinfo, argp, sizeof(eptinfo)))
> - return -EFAULT;
> -
> - memcpy(chinfo.name, eptinfo.name, RPMSG_NAME_SIZE);
> - chinfo.name[RPMSG_NAME_SIZE-1] = '\0';
> - chinfo.src = eptinfo.src;
> - chinfo.dst = eptinfo.dst;
> -
> - return rpmsg_
Re: [Outreachy kernel][PATCH] staging: media: hantro: Rewrite macro function in lower case
Em sex, 2021-04-09 às 14:15 -0300, Ezequiel Garcia escreveu: > On Fri, 2021-04-09 at 14:00 -0300, ascordeiro wrote: > > Em sex, 2021-04-09 às 13:44 -0300, Ezequiel Garcia escreveu: > > > Hi Aline, > > > > Hi Ezequiel, > > > > > > On Fri, 2021-04-09 at 10:54 -0300, Aline Santana Cordeiro wrote: > > > > Rewrite macros resembling functions #define HANTRO_PP_REG_WRITE > > > > and #define HANTRO_PP_RED_WRITE_S in lower case, according with > > > > code style. > > > > > > > > > > Where is this written in the Coding Style? > > > > I found this in section 12, about Macros, Enums and RTL in both > > references: > > https://www.kernel.org/doc/html/latest/process/coding-style.html > > https://elixir.bootlin.com/linux/latest/source/Documentation/process/coding-style.rst > > It seems this > > """ > CAPITALIZED macro names are appreciated but macros resembling > functions may be named in lower case. > """ > > It's just a suggestion, not a big deal. In general, if checkpatch.pl > is not complaining, it's not worth the trouble. > > So let's skip this fix. Okay! I'm going to check different problems with the checkpatch.pl > > Thanks a lot! > Ezequiel > Thank you! Aline
Re: [PATCH] MAINTAINERS: Update BCM2711/BCM2335 maintainer's mail
On Fri, 9 Apr 2021 12:44:47 +0200, Nicolas Saenz Julienne wrote: > The @kernel.org e-mail address is likely to last longer than the current > one, so use it. > > Signed-off-by: Nicolas Saenz Julienne > --- Applied to maintainers/next, thanks! -- Florian
Re: [PATCH] HSI: core: fix resource leaks in hsi_add_client_from_dt()
On Fri, Apr 09, 2021 at 02:08:17PM +0300, Dan Carpenter wrote:
> If some of the allocations fail between the dev_set_name() and the
> device_register() then the name will not be freed. Fix this by
> moving dev_set_name() directly in front of the call to device_register().
>
> Fixes: a2aa24734d9d ("HSI: Add common DT binding for HSI client devices")
> Signed-off-by: Dan Carpenter
> ---
> Jason, this is the most common type of error I see with device_register().
> Is there a downside to calling dev_set_name() later? Presumably it's
> printed out somewhere, but I feel like just moving the dev_set_name() is
> almost always the best and simplest fix.
It is hard to tell without detailed analysis.. ie a dev_err()/etc call
will use the name. It is why I don't like this design pattern of
avoiding device_initialize() and using device_registrR()
This movement looks OK though
Reviewed-by: Jason Gunthorpe
Jason
Re: [PATCH] HID: i2c-hid: Skip ELAN power-on command after reset
On Tue, 6 Apr 2021 at 23:49, Johnny Chuang wrote:
>
> Previous commit 43b7029f475e ("HID: i2c-hid:
> Send power-on command after reset"), it fixed issue for SIS touchscreen.
>
> For ELAN touchscreen, we found our boot code of IC was not flexible enough
> to receive and handle this command.
> Once the FW main code of our controller is crashed for some reason,
> the controller could not be enumerated successfully to be recognized
> by the system host. therefore, it lost touch functionality.
>
> Add quirk for skip send power-on command after reset.
> It will impact to ELAN touchscreen and touchpad on HID over I2C projects.
>
> Signed-off-by: Johnny Chuang
> ---
> drivers/hid/i2c-hid/i2c-hid-core.c | 10 +-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/hid/i2c-hid/i2c-hid-core.c
> b/drivers/hid/i2c-hid/i2c-hid-core.c
> index 9993133..6b407f7 100644
> --- a/drivers/hid/i2c-hid/i2c-hid-core.c
> +++ b/drivers/hid/i2c-hid/i2c-hid-core.c
> @@ -45,6 +45,7 @@
> #define I2C_HID_QUIRK_BOGUS_IRQBIT(4)
> #define I2C_HID_QUIRK_RESET_ON_RESUME BIT(5)
> #define I2C_HID_QUIRK_BAD_INPUT_SIZE BIT(6)
> +#define I2C_HID_QUIRK_NO_WAKEUP_AFTER_RESETBIT(7)
>
>
> /* flags */
> @@ -157,6 +158,10 @@ struct i2c_hid {
> struct i2chid_ops *ops;
> };
>
> +/*
> + * Sending the wakeup after reset actually break ELAN touchscreen controller
> + * So add I2C_HID_QUIRK_NO_WAKEUP_AFTER_RESET to skip wakeup after reset
> + */
You should put this comment next to the quirk entry itself, since it
doesn't apply to the whole list.
> static const struct i2c_hid_quirks {
> __u16 idVendor;
> __u16 idProduct;
> @@ -178,6 +183,8 @@ static const struct i2c_hid_quirks {
> I2C_HID_QUIRK_RESET_ON_RESUME },
> { USB_VENDOR_ID_ITE, I2C_DEVICE_ID_ITE_LENOVO_LEGION_Y720,
> I2C_HID_QUIRK_BAD_INPUT_SIZE },
(comment should go here)
> + { USB_VENDOR_ID_ELAN, HID_ANY_ID,
> +I2C_HID_QUIRK_NO_WAKEUP_AFTER_RESET },
> { 0, 0 }
> };
>
> @@ -461,7 +468,8 @@ static int i2c_hid_hwreset(struct i2c_client *client)
> }
>
> /* At least some SIS devices need this after reset */
> - ret = i2c_hid_set_power(client, I2C_HID_PWR_ON);
> + if (!(ihid->quirks & I2C_HID_QUIRK_NO_WAKEUP_AFTER_RESET))
> + ret = i2c_hid_set_power(client, I2C_HID_PWR_ON);
>
> out_unlock:
> mutex_unlock(&ihid->reset_lock);
> --
> 2.7.4
>
Re: [PATCH] xfs: fix return of uninitialized value in variable error
On Fri, Apr 09, 2021 at 03:18:34PM +0100, Colin King wrote:
> From: Colin Ian King
>
> A previous commit removed a call to xfs_attr3_leaf_read that
> assigned an error return code to variable error. We now have
> a few early error return paths to label 'out' that return
> error if error is set; however error now is uninitialized
> so potentially garbage is being returned. Fix this by setting
> error to zero to restore the original behaviour where error
> was zero at the label 'restart'.
>
> Addresses-Coverity: ("Uninitialized scalar variable")
> Fixes: 07120f1abdff ("xfs: Add xfs_has_attr and subroutines")
> Signed-off-by: Colin Ian King
Looks correct to me...
Reviewed-by: Darrick J. Wong
--D
> ---
> fs/xfs/libxfs/xfs_attr.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/fs/xfs/libxfs/xfs_attr.c b/fs/xfs/libxfs/xfs_attr.c
> index 472b3039eabb..902e5f7e6642 100644
> --- a/fs/xfs/libxfs/xfs_attr.c
> +++ b/fs/xfs/libxfs/xfs_attr.c
> @@ -928,6 +928,7 @@ xfs_attr_node_addname(
>* Search to see if name already exists, and get back a pointer
>* to where it should go.
>*/
> + error = 0;
> retval = xfs_attr_node_hasname(args, &state);
> if (retval != -ENOATTR && retval != -EEXIST)
> goto out;
> --
> 2.30.2
>
Re: [PATCH v1 01/14] vfio: Create vfio_fs_type with inode per device
On Fri, Apr 09, 2021 at 08:24:00AM -0600, Alex Williamson wrote: > > > #define DRIVER_VERSION "0.3" > > > #define DRIVER_AUTHOR"Alex Williamson " > > > #define DRIVER_DESC "VFIO - User Level meta-driver" > > > > > > +#define VFIO_MAGIC 0x5646494f /* "VFIO" */ > > Move to include/uapi/linux/magic.h ? > > Hmm, yeah, I suppose it probably should go there. Thanks. >From my review we haven't been doing that unless it is actually uapi relavent for some reason (this is not) In particular with CH having a patch series to eliminate all of these cases and drop the constants.. Jason
Re: [Outreachy kernel][PATCH 1/2 v3] staging: media: hantro: Align line break to the open parenthesis in file hantro_hw.h
Em sex, 2021-04-09 às 13:45 -0300, Ezequiel Garcia escreveu: > Hi Aline, Hi Ezequiel, > > On Fri, 2021-04-09 at 09:24 -0300, Aline Santana Cordeiro wrote: > > Aligns line break with the remaining function arguments > > to the open parenthesis. Issue found by checkpatch. > > > > Signed-off-by: Aline Santana Cordeiro < > > alinesantanacorde...@gmail.com> > > --- > > Changes since v2: > > - Rename the commit messages properly > > > > Changes since v1: > > - Send patchset without the cover-letter > > Why did you remove the cover letter? What was wrong with it? I got confused and as I used the same message as commit for the three files - cover-letter, patch 1/2, and patch 2/2 - they were sent in only one e-mail on patch 0/2, and the files modified weren't marked as patch 1/2 and patch 2/2, so I though it was wrong and sent v2 in a wrong way. > Thanks! > Ezequiel > Thank you! Aline
Re: [PATCH v17 1/2] scsi: ufs: Enable power management for wlun
On 9/04/21 8:15 pm, Asutosh Das (asd) wrote:
> On 4/9/2021 3:07 AM, Adrian Hunter wrote:
>> On 9/04/21 5:27 am, Daejun Park wrote:
>>> Hi Asutosh Das,
>>>
During runtime-suspend of ufs host, the scsi devices are
already suspended and so are the queues associated with them.
But the ufs host sends SSU (START_STOP_UNIT) to wlun
during its runtime-suspend.
During the process blk_queue_enter checks if the queue is not in
suspended state. If so, it waits for the queue to resume, and never
comes out of it.
The commit
(d55d15a33: scsi: block: Do not accept any requests while suspended)
adds the check if the queue is in suspended state in blk_queue_enter().
Call trace:
__switch_to+0x174/0x2c4
__schedule+0x478/0x764
schedule+0x9c/0xe0
blk_queue_enter+0x158/0x228
blk_mq_alloc_request+0x40/0xa4
blk_get_request+0x2c/0x70
__scsi_execute+0x60/0x1c4
ufshcd_set_dev_pwr_mode+0x124/0x1e4
ufshcd_suspend+0x208/0x83c
ufshcd_runtime_suspend+0x40/0x154
ufshcd_pltfrm_runtime_suspend+0x14/0x20
pm_generic_runtime_suspend+0x28/0x3c
__rpm_callback+0x80/0x2a4
rpm_suspend+0x308/0x614
rpm_idle+0x158/0x228
pm_runtime_work+0x84/0xac
process_one_work+0x1f0/0x470
worker_thread+0x26c/0x4c8
kthread+0x13c/0x320
ret_from_fork+0x10/0x18
Fix this by registering ufs device wlun as a scsi driver and
registering it for block runtime-pm. Also make this as a
supplier for all other luns. That way, this device wlun
suspends after all the consumers and resumes after
hba resumes.
Co-developed-by: Can Guo
Signed-off-by: Can Guo
Signed-off-by: Asutosh Das
---
drivers/scsi/ufs/cdns-pltfrm.c | 2 +
drivers/scsi/ufs/tc-dwc-g210-pci.c | 2 +
drivers/scsi/ufs/ufs-debugfs.c | 6 +-
drivers/scsi/ufs/ufs-debugfs.h | 2 +-
drivers/scsi/ufs/ufs-exynos.c | 2 +
drivers/scsi/ufs/ufs-hisi.c | 2 +
drivers/scsi/ufs/ufs-mediatek.c | 12 +-
drivers/scsi/ufs/ufs-qcom.c | 2 +
drivers/scsi/ufs/ufs_bsg.c | 6 +-
drivers/scsi/ufs/ufshcd-pci.c | 36 +--
drivers/scsi/ufs/ufshcd.c | 642
++---
drivers/scsi/ufs/ufshcd.h | 6 +
include/trace/events/ufs.h | 20 ++
13 files changed, 509 insertions(+), 231 deletions(-)
>>>
>>> In this patch, you changed pm_runtime_{get, put}_sync to scsi_autopm_{get,
>>> put}_device.
>>> But, scsi_autopm_get_device() calls pm_runtime_put_sync() in case of error
>>> of pm_runtime_get_sync(). So, pm_runtime_put_sync() can be called twice if
>>> scsi_autopm_get_device has error.
>>
>> Also it might be tidy to make wrappers e.g.
>>
>> static inline int ufshcd_rpm_get_sync(struct ufs_hba *hba)
>> {
>> return pm_runtime_get_sync(&hba->sdev_ufs_device->sdev_gendev);
>> }
>> static inline int ufshcd_rpm_put(struct ufs_hba *hba)
>> {
>> return pm_runtime_put(&hba->sdev_ufs_device->sdev_gendev);
>> }
>>
>> static inline int ufshcd_rpm_put_sync(struct ufs_hba *hba)
>> {
>> return pm_runtime_put_sync(&hba->sdev_ufs_device->sdev_gendev);
>> }
>>
>> And also consider matching: e.g.
>>
>> pm_runtime_put(hba->dev) to ufshcd_rpm_put(hba)
>> pm_runtime_put_sync(hba->dev) to ufshcd_rpm_put_sync(hba)
>>
>>
>>
>
> Ok, I'll push the changes shortly.
>
I think I will have some more comments, so you could wait if you want.
Re: [Outreachy kernel] Re: [PATCH 1/2] media: zoran: add spaces around '<<'
On Fri, 9 Apr 2021, Mitali Borkar wrote: > On Fri, Apr 09, 2021 at 09:23:22AM +0200, Hans Verkuil wrote: > > Hi Mitali, > > > > On 08/04/2021 22:38, Mitali Borkar wrote: > > > Added spaces around '<<' operator to improve readability and meet linux > > > kernel coding style. > > > Reported by checkpatch > > > > > > Signed-off-by: Mitali Borkar > > > --- > > > drivers/staging/media/zoran/zr36057.h | 14 +++--- > > > 1 file changed, 7 insertions(+), 7 deletions(-) > > > > > > diff --git a/drivers/staging/media/zoran/zr36057.h > > > b/drivers/staging/media/zoran/zr36057.h > > > index 71b651add35a..a2a75fd9f535 100644 > > > --- a/drivers/staging/media/zoran/zr36057.h > > > +++ b/drivers/staging/media/zoran/zr36057.h > > > @@ -30,13 +30,13 @@ > > > #define ZR36057_VFESPFR_HOR_DCM 14 > > > #define ZR36057_VFESPFR_VER_DCM 8 > > > #define ZR36057_VFESPFR_DISP_MODE6 > > > -#define ZR36057_VFESPFR_YUV422 (0<<3) > > > -#define ZR36057_VFESPFR_RGB888 (1<<3) > > > -#define ZR36057_VFESPFR_RGB565 (2<<3) > > > -#define ZR36057_VFESPFR_RGB555 (3<<3) > > > -#define ZR36057_VFESPFR_ERR_DIF (1<<2) > > > -#define ZR36057_VFESPFR_PACK24 (1<<1) > > > -#define ZR36057_VFESPFR_LITTLE_ENDIAN(1<<0) > > > +#define ZR36057_VFESPFR_YUV422 (0 << 3) > > > +#define ZR36057_VFESPFR_RGB888 (1 << 3) > > > +#define ZR36057_VFESPFR_RGB565 (2 << 3) > > > +#define ZR36057_VFESPFR_RGB555 (3 << 3) > > > +#define ZR36057_VFESPFR_ERR_DIF (1 << 2) > > > +#define ZR36057_VFESPFR_PACK24 (1 << 1) > > > +#define ZR36057_VFESPFR_LITTLE_ENDIAN(1 << 0) > > > > > > #define ZR36057_VDTR0x00c/* Video Display "Top" Register > > > */ > > > > > > > > > > I looked at that header and it is very messy. > > > > Can you make two new patches? The first aligns every nicely, e.g. this: > > > > #define ZR36057_VFEHCR 0x000 /* Video Front End, Horizontal > > Configuration Register */ > > #define ZR36057_VFEHCR_HS_POL BIT(30) > > #define ZR36057_VFEHCR_H_START 10 > > #define ZR36057_VFEHCR_H_END0 > > #define ZR36057_VFEHCR_HMASK0x3ff > > > > should become: > > > > /* Video Front End, Horizontal Configuration Register */ > > #define ZR36057_VFEHCR 0x000 > > #define ZR36057_VFEHCR_HS_POL BIT(30) > > #define ZR36057_VFEHCR_H_START 10 > > #define ZR36057_VFEHCR_H_END0 > > #define ZR36057_VFEHCR_HMASK0x3ff > > > > Same for all the other register blocks. Use tabs to do the alignment > > instead of spaces, as is currently the case. > > > > The second patch can replace the (0<<3) etc. to BIT(0). > > > Then I guess only one new patch would be needed for proper alignment, am > i right? I have to rename it as v2 or should send as a completely new > patch? v2 might reduce confusion. julia > > That would be a nice cleanup of this rather messy header. > > > > Thanks! > > > > Hans > > -- > You received this message because you are subscribed to the Google Groups > "outreachy-kernel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to outreachy-kernel+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/outreachy-kernel/YHCFsNZVGfjjyHDi%40kali. >
Re: [Outreachy kernel][PATCH] staging: media: hantro: Rewrite macro function in lower case
On Fri, 9 Apr 2021, ascordeiro wrote:
> Em sex, 2021-04-09 às 13:44 -0300, Ezequiel Garcia escreveu:
> > Hi Aline,
>
> Hi Ezequiel,
> >
> > On Fri, 2021-04-09 at 10:54 -0300, Aline Santana Cordeiro wrote:
> > > Rewrite macros resembling functions #define HANTRO_PP_REG_WRITE
> > > and #define HANTRO_PP_RED_WRITE_S in lower case, according with
> > > code style.
Maybe you can see if these macros can be converted to static inline
functions. Macros don't provide any type checking.
julia
> > >
> >
> > Where is this written in the Coding Style?
>
> I found this in section 12, about Macros, Enums and RTL in both
> references:
> https://www.kernel.org/doc/html/latest/process/coding-style.html
> https://elixir.bootlin.com/linux/latest/source/Documentation/process/coding-style.rst
> >
> > Thanks!
> > Ezequiel
>
> Thank you!
> Aline
> >
> > > Signed-off-by: Aline Santana Cordeiro <
> > > alinesantanacorde...@gmail.com>
> > > ---
> > > drivers/staging/media/hantro/hantro_postproc.c | 34 +-
> > >
> > > 1 file changed, 17 insertions(+), 17 deletions(-)
> > >
> > > diff --git a/drivers/staging/media/hantro/hantro_postproc.c
> > > b/drivers/staging/media/hantro/hantro_postproc.c
> > > index 6d2a8f2a..06279c0 100644
> > > --- a/drivers/staging/media/hantro/hantro_postproc.c
> > > +++ b/drivers/staging/media/hantro/hantro_postproc.c
> > > @@ -12,14 +12,14 @@
> > > #include "hantro_hw.h"
> > > #include "hantro_g1_regs.h"
> > >
> > > -#define HANTRO_PP_REG_WRITE(vpu, reg_name, val) \
> > > +#define hantro_pp_reg_write(vpu, reg_name, val) \
> > > { \
> > > hantro_reg_write(vpu, \
> > > &(vpu)->variant->postproc_regs->reg_name,
> > > \
> > > val); \
> > > }
> > >
> > > -#define HANTRO_PP_REG_WRITE_S(vpu, reg_name, val) \
> > > +#define hantro_pp_reg_write_s(vpu, reg_name, val) \
> > > { \
> > > hantro_reg_write_s(vpu, \
> > > &(vpu)->variant->postproc_regs-
> > > >reg_name, \
> > > @@ -61,7 +61,7 @@ void hantro_postproc_enable(struct hantro_ctx
> > > *ctx)
> > > return;
> > >
> > > /* Turn on pipeline mode. Must be done first. */
> > > - HANTRO_PP_REG_WRITE_S(vpu, pipeline_en, 0x1);
> > > + hantro_pp_reg_write_s(vpu, pipeline_en, 0x1);
> > >
> > > src_pp_fmt = VPU_PP_IN_NV12;
> > >
> > > @@ -79,19 +79,19 @@ void hantro_postproc_enable(struct hantro_ctx
> > > *ctx)
> > > dst_buf = v4l2_m2m_next_dst_buf(ctx->fh.m2m_ctx);
> > > dst_dma = vb2_dma_contig_plane_dma_addr(&dst_buf->vb2_buf,
> > > 0);
> > >
> > > - HANTRO_PP_REG_WRITE(vpu, clk_gate, 0x1);
> > > - HANTRO_PP_REG_WRITE(vpu, out_endian, 0x1);
> > > - HANTRO_PP_REG_WRITE(vpu, out_swap32, 0x1);
> > > - HANTRO_PP_REG_WRITE(vpu, max_burst, 16);
> > > - HANTRO_PP_REG_WRITE(vpu, out_luma_base, dst_dma);
> > > - HANTRO_PP_REG_WRITE(vpu, input_width, MB_WIDTH(ctx-
> > > >dst_fmt.width));
> > > - HANTRO_PP_REG_WRITE(vpu, input_height, MB_HEIGHT(ctx-
> > > >dst_fmt.height));
> > > - HANTRO_PP_REG_WRITE(vpu, input_fmt, src_pp_fmt);
> > > - HANTRO_PP_REG_WRITE(vpu, output_fmt, dst_pp_fmt);
> > > - HANTRO_PP_REG_WRITE(vpu, output_width, ctx->dst_fmt.width);
> > > - HANTRO_PP_REG_WRITE(vpu, output_height, ctx-
> > > >dst_fmt.height);
> > > - HANTRO_PP_REG_WRITE(vpu, orig_width, MB_WIDTH(ctx-
> > > >dst_fmt.width));
> > > - HANTRO_PP_REG_WRITE(vpu, display_width, ctx-
> > > >dst_fmt.width);
> > > + hantro_pp_reg_write(vpu, clk_gate, 0x1);
> > > + hantro_pp_reg_write(vpu, out_endian, 0x1);
> > > + hantro_pp_reg_write(vpu, out_swap32, 0x1);
> > > + hantro_pp_reg_write(vpu, max_burst, 16);
> > > + hantro_pp_reg_write(vpu, out_luma_base, dst_dma);
> > > + hantro_pp_reg_write(vpu, input_width, MB_WIDTH(ctx-
> > > >dst_fmt.width));
> > > + hantro_pp_reg_write(vpu, input_height, MB_HEIGHT(ctx-
> > > >dst_fmt.height));
> > > + hantro_pp_reg_write(vpu, input_fmt, src_pp_fmt);
> > > + hantro_pp_reg_write(vpu, output_fmt, dst_pp_fmt);
> > > + hantro_pp_reg_write(vpu, output_width, ctx->dst_fmt.width);
> > > + hantro_pp_reg_write(vpu, output_height, ctx-
> > > >dst_fmt.height);
> > > + hantro_pp_reg_write(vpu, orig_width, MB_WIDTH(ctx-
> > > >dst_fmt.width));
> > > + hantro_pp_reg_write(vpu, display_width, ctx-
> > > >dst_fmt.width);
> > > }
> > >
> > > void hantro_postproc_free(struct hantro_ctx *ctx)
> > > @@ -146,5 +146,5 @@ void hantro_postproc_disable(struct hantro_ctx
> > > *ctx)
> > > if (!vpu->variant->postproc_regs)
> > > return;
> > >
> > > - HANTRO_PP_REG_WRITE_S(vpu, pipeline_en, 0x0);
> > > + hantro_pp_reg_write_s(vpu, pipeline_en, 0x0);
> > > }
> >
> >
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "outreachy-kernel" group.
> To unsubscribe from this
RE: [PATCH net v1] Revert "lan743x: trim all 4 bytes of the FCS; not just 2"
From: Sven Van Asbroeck > Sent: 08 April 2021 19:35 ... > - buffer_length = netdev->mtu + ETH_HLEN + 4 + RX_HEAD_PADDING; > + buffer_length = netdev->mtu + ETH_HLEN + ETH_FCS_LEN + > RX_HEAD_PADDING; I'd try to write the lengths in the order they happen, so: buffer_length = RX_HEAD_PADDING + ETH_HLEN + netdev->mtu + ETH_FCS_LEN; The compiler should add all the constants together, so the generated code ought to be the same. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
Re: [Outreachy kernel] [PATCH] staging: rtl8723bs: Change the type and use of a variable
On Fri, 9 Apr 2021, Fabio M. De Francesco wrote: > On Friday, April 9, 2021 4:12:37 PM CEST Greg KH wrote: > > On Thu, Apr 08, 2021 at 01:19:42PM +0200, Fabio M. De Francesco wrote: > > > Change the type of fw_current_in_ps_mode from u8 to bool, because > > > it is used everywhere as a bool and, accordingly, it should be > > > declared as a bool. Shorten the controlling > > > expression of an 'if' statement. > > > > > > Signed-off-by: Fabio M. De Francesco > > > --- > > > > > > drivers/staging/rtl8723bs/hal/hal_intf.c| 2 +- > > > drivers/staging/rtl8723bs/include/rtw_pwrctrl.h | 2 +- > > > 2 files changed, 2 insertions(+), 2 deletions(-) > > > > I now have 3 patches, I think, for this same driver, from you, and I > > have no idea what order they should be applied in. > > > > So I'm going to drop them all. Can you please resend me a patch series, > > with all of the outstanding patches sent to me from you that I have not > > applied yet, so that I know which ones to look at and what order to > > apply them in? > > > I just sent in the series of patches you requested. Hope the work is as you > expected. If you make multiple patches that touch the same files they have to be in a series. julia
