date:20210325


On 17:37 Thu 25 Mar 2021, Bhaskar Chowdhury wrote:

On 11:47 Thu 25 Mar 2021, Takashi Iwai wrote:

On Thu, 25 Mar 2021 10:56:39 +0100,
Bhaskar Chowdhury wrote:


On 10:37 Thu 25 Mar 2021, Takashi Iwai wrote:
>On Thu, 25 Mar 2021 10:06:09 +0100,
>Bhaskar Chowdhury wrote:
>>
>> s/unconditonally/unconditionally/
>> s/succesful/successful/
>>
>> Signed-off-by: Bhaskar Chowdhury 
>> ---
>>  Changes from V2:
>>  Takashi pointed out that the patch was not applicable due to some unwanted
>>  stuff get into it. Resending it with the new patch creation.
>
>Hrm, still not applicable.  Can you apply the patch from your own post
>via git-am in your side?
>
Here is what I do for this specific case :

✔ ~/git-linux/linux-next [patch L|✔]
15:18 $ sed -i 's/unconditonally/unconditionally/' sound/core/pcm_native.c
✔ ~/git-linux/linux-next [patch L|✚ 1]
15:19 $ sed -i 's/succesful/successful/' sound/core/pcm_native.c
✔ ~/git-linux/linux-next [patch L|✚ 1]
15:19 $ git add .
✔ ~/git-linux/linux-next [patch L|●1]
15:19 $ git ci "Fix some patch error"
[patch 88d5af187dbb] Fix some patch error
1 file changed, 2 insertions(+), 2 deletions(-)

15:21 $ git_fetch_single_file.sh sound/core/pcm_native.c
Looks alright!✔ ~/git-linux/linux-next [patch L|●1]
15:21 $ git add .
✔ ~/git-linux/linux-next [patch L|●1]
15:21 $ git ci "Bring for patch"
[patch 352e1ce8dacf] Bring for patch
1 file changed, 2 insertions(+), 2 deletions(-)
✔ ~/git-linux/linux-next [patch L|✔]
15:22 $ git apply --verbose 0001-Made-patche-for-this.patch
Checking patch sound/core/pcm_native.c...
Applied patch sound/core/pcm_native.c cleanly.


I meant to try to apply the patch from mail fetched from the ML, not
the patch you made from your git tree.




Hmm

bhaskar@debian_16:18:41_Thu Mar 25 :~> mutt
Applying: ALSA: pcm: Fix couple of typos
error: corrupt patch at line 29
Patch failed at 0001 ALSA: pcm: Fix couple of typos
hint: Use 'git am --show-current-patch' to see the failed patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".
Press any key to continue...


Something bugging it 

Takashi


Okay ,I have sent a V4 now and it seems working when I did a "git am from
mutt" and the result is getting reflected on linux-next file.

Takashi, could you please give it another shot

~Bhaskar


signature.asc
Description: PGP signature

Re: [PATCH v2 6/7] cmdline: Gives architectures opportunity to use generically defined boot cmdline manipulation

2021-03-25 Thread Christophe Leroy





Le 03/03/2021 à 18:57, Will Deacon a écrit :

On Tue, Mar 02, 2021 at 05:25:22PM +, Christophe Leroy wrote:

Most architectures have similar boot command line manipulation
options. This patchs adds the definition in init/Kconfig, gated by
CONFIG_HAVE_CMDLINE that the architectures can select to use them.

In order to use this, a few architectures will have to change their
CONFIG options:
- riscv has to replace CMDLINE_FALLBACK by CMDLINE_FROM_BOOTLOADER
- architectures using CONFIG_CMDLINE_OVERRIDE or
CONFIG_CMDLINE_OVERWRITE have to replace them by CONFIG_CMDLINE_FORCE.

Architectures also have to define CONFIG_DEFAULT_CMDLINE.

Signed-off-by: Christophe Leroy 
---
  init/Kconfig | 56 
  1 file changed, 56 insertions(+)

diff --git a/init/Kconfig b/init/Kconfig
index 22946fe5ded9..a0f2ad9467df 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -117,6 +117,62 @@ config INIT_ENV_ARG_LIMIT
  Maximum of each of the number of arguments and environment
  variables passed to init from the kernel command line.
  
+config HAVE_CMDLINE

+   bool
+
+config CMDLINE_BOOL
+   bool "Default bootloader kernel arguments"
+   depends on HAVE_CMDLINE
+   help
+ On some platforms, there is currently no way for the boot loader to
+ pass arguments to the kernel. For these platforms, you can supply
+ some command-line options at build time by entering them here.  In
+ most cases you will need to specify the root device here.


Why is this needed as well as CMDLINE_FROM_BOOTLOADER? IIUC, the latter
will use CONFIG_CMDLINE if it fails to get anything from the bootloader,
which sounds like the same scenario.


+config CMDLINE
+   string "Initial kernel command string"


s/Initial/Default

which is then consistent with the rest of the text here.


+   depends on CMDLINE_BOOL


Ah, so this is a bit different and I don't think lines-up with the
CMDLINE_BOOL help text.


You are right, the help text is duplicated, I will change the text for the 
CMDLINE_BOOL




+   default DEFAULT_CMDLINE
+   help
+ On some platforms, there is currently no way for the boot loader to
+ pass arguments to the kernel. For these platforms, you can supply
+ some command-line options at build time by entering them here.  In
+ most cases you will need to specify the root device here.


(same stale text)


+choice
+   prompt "Kernel command line type" if CMDLINE != ""
+   default CMDLINE_FROM_BOOTLOADER
+   help
+ Selects the way you want to use the default kernel arguments.


How about:

"Determines how the default kernel arguments are combined with any
  arguments passed by the bootloader"


+config CMDLINE_FROM_BOOTLOADER
+   bool "Use bootloader kernel arguments if available"
+   help
+ Uses the command-line options passed by the boot loader. If
+ the boot loader doesn't provide any, the default kernel command
+ string provided in CMDLINE will be used.
+
+config CMDLINE_EXTEND


Can we rename this to CMDLINE_APPEND, please? There is code in the tree
which disagrees about what CMDLINE_EXTEND means, so that will need be
to be updated to be consistent (e.g. the EFI stub parsing order). Having
the generic option with a different name means we won't accidentally end
up with the same inconsistent behaviours.


+   bool "Extend bootloader kernel arguments"


"Append to the bootloader kernel arguments"


+   help
+ The default kernel command string will be appended to the
+ command-line arguments provided during boot.


s/provided during boot/provided by the bootloader/


+
+config CMDLINE_PREPEND
+   bool "Prepend bootloader kernel arguments"


"Prepend to the bootloader kernel arguments"


+   help
+ The default kernel command string will be prepend to the
+ command-line arguments provided during boot.


s/prepend/prepended/
s/provided during boot/provided by the bootloader/


+
+config CMDLINE_FORCE
+   bool "Always use the default kernel command string"
+   help
+ Always use the default kernel command string, even if the boot
+ loader passes other arguments to the kernel.
+ This is useful if you cannot or don't want to change the
+ command-line options your boot loader passes to the kernel.


I find the "This is useful if ..." sentence really confusing, perhaps just
remove it? I'd then tweak it to be:

   "Always use the default kernel command string, ignoring any arguments
provided by the bootloader."



Taken all your suggested text.

Thanks
Christophe

[PATCH V4] ALSA: pcm: Fix couple of typos



s/unconditonally/unconditionally/
s/succesful/successful/

Signed-off-by: Bhaskar Chowdhury 
---
 Changes from V3:
  Yet another try to make it work

 sound/core/pcm_native.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/sound/core/pcm_native.c b/sound/core/pcm_native.c
index 17a85f4815d5..8dbe86cf2e4f 100644
--- a/sound/core/pcm_native.c
+++ b/sound/core/pcm_native.c
@@ -1425,7 +1425,7 @@ static int snd_pcm_do_stop(struct snd_pcm_substream 
*substream,
substream->ops->trigger(substream, SNDRV_PCM_TRIGGER_STOP);
substream->runtime->stop_operating = true;
}
-   return 0; /* unconditonally stop all substreams */
+   return 0; /* unconditionally stop all substreams */
 }

 static void snd_pcm_post_stop(struct snd_pcm_substream *substream,
@@ -1469,7 +1469,7 @@ EXPORT_SYMBOL(snd_pcm_stop);
  * After stopping, the state is changed to SETUP.
  * Unlike snd_pcm_stop(), this affects only the given stream.
  *
- * Return: Zero if succesful, or a negative error code.
+ * Return: Zero if successful, or a negative error code.
  */
 int snd_pcm_drain_done(struct snd_pcm_substream *substream)
 {
--
2.26.2

[PATCH v5 7/9] soundwire: export sdw_compare_devid, sdw_extract_slave_id and sdw_slave_add

Exporting these three functions makes sense as it can be used by
other controllers like Qualcomm during auto-enumeration!

Reported-by: kernel test robot 
Signed-off-by: Srinivas Kandagatla 
---
 drivers/soundwire/bus.c   | 4 +++-
 drivers/soundwire/slave.c | 1 +
 include/linux/soundwire/sdw.h | 2 ++
 3 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/soundwire/bus.c b/drivers/soundwire/bus.c
index 46885429928a..6d7708964735 100644
--- a/drivers/soundwire/bus.c
+++ b/drivers/soundwire/bus.c
@@ -603,7 +603,7 @@ static struct sdw_slave *sdw_get_slave(struct sdw_bus *bus, 
int i)
return NULL;
 }
 
-static int sdw_compare_devid(struct sdw_slave *slave, struct sdw_slave_id id)
+int sdw_compare_devid(struct sdw_slave *slave, struct sdw_slave_id id)
 {
if (slave->id.mfg_id != id.mfg_id ||
slave->id.part_id != id.part_id ||
@@ -614,6 +614,7 @@ static int sdw_compare_devid(struct sdw_slave *slave, 
struct sdw_slave_id id)
 
return 0;
 }
+EXPORT_SYMBOL(sdw_compare_devid);
 
 /* called with bus_lock held */
 static int sdw_get_device_num(struct sdw_slave *slave)
@@ -698,6 +699,7 @@ void sdw_extract_slave_id(struct sdw_bus *bus,
"SDW Slave class_id 0x%02x, mfg_id 0x%04x, part_id 0x%04x, 
unique_id 0x%x, version 0x%x\n",
id->class_id, id->mfg_id, id->part_id, id->unique_id, 
id->sdw_version);
 }
+EXPORT_SYMBOL(sdw_extract_slave_id);
 
 static int sdw_program_device_num(struct sdw_bus *bus)
 {
diff --git a/drivers/soundwire/slave.c b/drivers/soundwire/slave.c
index 180f38bd003b..92850e150d36 100644
--- a/drivers/soundwire/slave.c
+++ b/drivers/soundwire/slave.c
@@ -88,6 +88,7 @@ int sdw_slave_add(struct sdw_bus *bus,
 
return ret;
 }
+EXPORT_SYMBOL(sdw_slave_add);
 
 #if IS_ENABLED(CONFIG_ACPI)
 
diff --git a/include/linux/soundwire/sdw.h b/include/linux/soundwire/sdw.h
index 2f52d6609076..f9003ba056ba 100644
--- a/include/linux/soundwire/sdw.h
+++ b/include/linux/soundwire/sdw.h
@@ -1011,5 +1011,7 @@ int sdw_write_no_pm(struct sdw_slave *slave, u32 addr, u8 
value);
 int sdw_read_no_pm(struct sdw_slave *slave, u32 addr);
 int sdw_nread(struct sdw_slave *slave, u32 addr, size_t count, u8 *val);
 int sdw_nwrite(struct sdw_slave *slave, u32 addr, size_t count, u8 *val);
+int sdw_compare_devid(struct sdw_slave *slave, struct sdw_slave_id id);
+void sdw_extract_slave_id(struct sdw_bus *bus, u64 addr, struct sdw_slave_id 
*id);
 
 #endif /* __SOUNDWIRE_H */
-- 
2.21.0

[PATCH v9 2/3] arm64: dts: ti: k3-j7200-common-proc-board: Disable unused gpio modules

From: Faiz Abbas 

There are 6 gpio instances inside SoC with 2 groups as show below:
Group one: wkup_gpio0, wkup_gpio1
Group two: main_gpio0, main_gpio2, main_gpio4, main_gpio6

Only one instance from each group can be used at a time. So use main_gpio0
and wkup_gpio0 in current linux context and disable the rest of the nodes.

Signed-off-by: Faiz Abbas 
Signed-off-by: Sekhar Nori 
Signed-off-by: Aswath Govindraju 
Reviewed-by: Grygorii Strashko 
---
 .../boot/dts/ti/k3-j7200-common-proc-board.dts   | 16 
 1 file changed, 16 insertions(+)

diff --git a/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts 
b/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts
index 4a7182abccf5..b493f939b09a 100644
--- a/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts
+++ b/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts
@@ -122,6 +122,22 @@
status = "disabled";
 };
 
+&main_gpio2 {
+   status = "disabled";
+};
+
+&main_gpio4 {
+   status = "disabled";
+};
+
+&main_gpio6 {
+   status = "disabled";
+};
+
+&wkup_gpio1 {
+   status = "disabled";
+};
+
 &mcu_cpsw {
pinctrl-names = "default";
pinctrl-0 = <&mcu_cpsw_pins_default &mcu_mdio_pins_default>;
-- 
2.17.1

[PATCH v9 1/3] arm64: dts: ti: k3-j7200: Add gpio nodes

From: Faiz Abbas 

There are 4 instances of gpio modules in main domain:
gpio0, gpio2, gpio4 and gpio6

Groups are created to provide protection between different processor
virtual worlds. Each of these modules I/O pins are muxed within the
group. Exactly one module can be selected to control the corresponding
pin by selecting it in the pad mux configuration registers.

This group in main domain pins out 69 lines (5 banks). Add DT modes for
each module instance in the main domain.

Similar to the gpio groups in main domain, there is one gpio group in
wakeup domain with 2 module instances in it.

The gpio group pins out 72 pins (6 banks) of the first 85 gpio lines. Add
DT nodes for each module instance in the wakeup domain.

Signed-off-by: Faiz Abbas 
Signed-off-by: Sekhar Nori 
Signed-off-by: Aswath Govindraju 
Reviewed-by: Grygorii Strashko 
---
 arch/arm64/boot/dts/ti/k3-j7200-main.dtsi | 72 +++
 .../boot/dts/ti/k3-j7200-mcu-wakeup.dtsi  | 34 +
 2 files changed, 106 insertions(+)

diff --git a/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi 
b/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi
index 17477ab0fd8e..e60650a62b14 100644
--- a/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi
@@ -672,6 +672,78 @@
};
};
 
+   main_gpio0: gpio@60 {
+   compatible = "ti,j721e-gpio", "ti,keystone-gpio";
+   reg = <0x00 0x0060 0x00 0x100>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   interrupt-parent = <&main_gpio_intr>;
+   interrupts = <145>, <146>, <147>, <148>,
+<149>;
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   #address-cells = <0>;
+   ti,ngpio = <69>;
+   ti,davinci-gpio-unbanked = <0>;
+   power-domains = <&k3_pds 105 TI_SCI_PD_EXCLUSIVE>;
+   clocks = <&k3_clks 105 0>;
+   clock-names = "gpio";
+   };
+
+   main_gpio2: gpio@61 {
+   compatible = "ti,j721e-gpio", "ti,keystone-gpio";
+   reg = <0x00 0x0061 0x00 0x100>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   interrupt-parent = <&main_gpio_intr>;
+   interrupts = <154>, <155>, <156>, <157>,
+<158>;
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   #address-cells = <0>;
+   ti,ngpio = <69>;
+   ti,davinci-gpio-unbanked = <0>;
+   power-domains = <&k3_pds 107 TI_SCI_PD_EXCLUSIVE>;
+   clocks = <&k3_clks 107 0>;
+   clock-names = "gpio";
+   };
+
+   main_gpio4: gpio@62 {
+   compatible = "ti,j721e-gpio", "ti,keystone-gpio";
+   reg = <0x00 0x0062 0x00 0x100>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   interrupt-parent = <&main_gpio_intr>;
+   interrupts = <163>, <164>, <165>, <166>,
+<167>;
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   #address-cells = <0>;
+   ti,ngpio = <69>;
+   ti,davinci-gpio-unbanked = <0>;
+   power-domains = <&k3_pds 109 TI_SCI_PD_EXCLUSIVE>;
+   clocks = <&k3_clks 109 0>;
+   clock-names = "gpio";
+   };
+
+   main_gpio6: gpio@63 {
+   compatible = "ti,j721e-gpio", "ti,keystone-gpio";
+   reg = <0x00 0x0063 0x00 0x100>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   interrupt-parent = <&main_gpio_intr>;
+   interrupts = <172>, <173>, <174>, <175>,
+<176>;
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   #address-cells = <0>;
+   ti,ngpio = <69>;
+   ti,davinci-gpio-unbanked = <0>;
+   power-domains = <&k3_pds 111 TI_SCI_PD_EXCLUSIVE>;
+   clocks = <&k3_clks 111 0>;
+   clock-names = "gpio";
+   };
+
main_r5fss0: r5fss@5c0 {
compatible = "ti,j7200-r5fss";
ti,cluster-mode = <1>;
diff --git a/arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi 
b/arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi
index 5408ec815d58..4e4ea7655fe2 100644
--- a/arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi
@@ -107,6 +107,40 @@
ti,interrupt-ranges = <16 960 16>;
};
 
+   wkup_gpio0: gpio@4211 {
+   compatible = "ti,j721e-gpio", "ti,keystone-gpio";
+   reg = <0x00 0x4211 0x00 0x100>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   interrupt-parent = <&wkup_gpio_intr>;
+   interrupts =

[PATCH v5 4/9] soundwire: qcom: start the clock during initialization

Start the clock during initialization, doing this explicitly
will add more clarity when we are adding clock stop feature.

Signed-off-by: Srinivas Kandagatla 
Reviewed-by: Pierre-Louis Bossart 
---
 drivers/soundwire/qcom.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/soundwire/qcom.c b/drivers/soundwire/qcom.c
index 43ec22a5e332..2bcb4362f0e0 100644
--- a/drivers/soundwire/qcom.c
+++ b/drivers/soundwire/qcom.c
@@ -47,6 +47,8 @@
 #define SWRM_MCP_FRAME_CTRL_BANK_ADDR(m)   (0x101C + 0x40 * (m))
 #define SWRM_MCP_FRAME_CTRL_BANK_COL_CTRL_BMSK GENMASK(2, 0)
 #define SWRM_MCP_FRAME_CTRL_BANK_ROW_CTRL_BMSK GENMASK(7, 3)
+#define SWRM_MCP_BUS_CTRL  0x1044
+#define SWRM_MCP_BUS_CLK_START BIT(1)
 #define SWRM_MCP_CFG_ADDR  0x1048
 #define SWRM_MCP_CFG_MAX_NUM_OF_CMD_NO_PINGS_BMSK  GENMASK(21, 17)
 #define SWRM_DEF_CMD_NO_PINGS  0x1f
@@ -343,6 +345,7 @@ static int qcom_swrm_init(struct qcom_swrm_ctrl *ctrl)
u32p_replace_bits(&val, SWRM_DEF_CMD_NO_PINGS, 
SWRM_MCP_CFG_MAX_NUM_OF_CMD_NO_PINGS_BMSK);
ctrl->reg_write(ctrl, SWRM_MCP_CFG_ADDR, val);
 
+   ctrl->reg_write(ctrl, SWRM_MCP_BUS_CTRL, SWRM_MCP_BUS_CLK_START);
/* Configure number of retries of a read/write cmd */
if (ctrl->version > 0x01050001) {
/* Only for versions >= 1.5.1 */
-- 
2.21.0

[PATCH v5 9/9] soundwire: qcom: wait for enumeration to be complete in probe

Signed-off-by: Srinivas Kandagatla 
Reviewed-by: Pierre-Louis Bossart 
---
 drivers/soundwire/qcom.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/soundwire/qcom.c b/drivers/soundwire/qcom.c
index c6c923329b15..706d44200a36 100644
--- a/drivers/soundwire/qcom.c
+++ b/drivers/soundwire/qcom.c
@@ -123,6 +123,7 @@ struct qcom_swrm_ctrl {
struct regmap *regmap;
void __iomem *mmio;
struct completion broadcast;
+   struct completion enumeration;
struct work_struct slave_work;
/* Port alloc/free lock */
struct mutex port_lock;
@@ -417,6 +418,7 @@ static int qcom_swrm_enumerate(struct sdw_bus *bus)
}
}
 
+   complete(&ctrl->enumeration);
return 0;
 }
 
@@ -1155,6 +1157,7 @@ static int qcom_swrm_probe(struct platform_device *pdev)
dev_set_drvdata(&pdev->dev, ctrl);
mutex_init(&ctrl->port_lock);
init_completion(&ctrl->broadcast);
+   init_completion(&ctrl->enumeration);
 
ctrl->bus.ops = &qcom_swrm_ops;
ctrl->bus.port_ops = &qcom_swrm_port_ops;
@@ -1201,6 +1204,8 @@ static int qcom_swrm_probe(struct platform_device *pdev)
}
 
qcom_swrm_init(ctrl);
+   wait_for_completion_timeout(&ctrl->enumeration,
+   msecs_to_jiffies(TIMEOUT_MS));
ret = qcom_swrm_register_dais(ctrl);
if (ret)
goto err_master_add;
-- 
2.21.0

[PATCH v5 6/9] soundwire: qcom: add support to new interrupts

Add support to new interrupts which includes reporting some of the
error interrupts and adding support to SLAVE pending interrupt!

This patch also changes the interrupt handler behaviour on handling
any pending interrupts by checking it before returning out of irq handler.

Signed-off-by: Srinivas Kandagatla 
Reviewed-by: Pierre-Louis Bossart 
---
 drivers/soundwire/qcom.c | 161 ---
 1 file changed, 135 insertions(+), 26 deletions(-)

diff --git a/drivers/soundwire/qcom.c b/drivers/soundwire/qcom.c
index 0cbd611fb8c6..6a563fb52444 100644
--- a/drivers/soundwire/qcom.c
+++ b/drivers/soundwire/qcom.c
@@ -28,10 +28,21 @@
 #define SWRM_COMP_PARAMS_DIN_PORTS_MASK
GENMASK(9, 5)
 #define SWRM_INTERRUPT_STATUS  0x200
 #define SWRM_INTERRUPT_STATUS_RMSK GENMASK(16, 0)
+#define SWRM_INTERRUPT_STATUS_SLAVE_PEND_IRQ   BIT(0)
 #define SWRM_INTERRUPT_STATUS_NEW_SLAVE_ATTACHED   BIT(1)
 #define SWRM_INTERRUPT_STATUS_CHANGE_ENUM_SLAVE_STATUS BIT(2)
+#define SWRM_INTERRUPT_STATUS_MASTER_CLASH_DET BIT(3)
+#define SWRM_INTERRUPT_STATUS_RD_FIFO_OVERFLOW BIT(4)
+#define SWRM_INTERRUPT_STATUS_RD_FIFO_UNDERFLOWBIT(5)
+#define SWRM_INTERRUPT_STATUS_WR_CMD_FIFO_OVERFLOW BIT(6)
 #define SWRM_INTERRUPT_STATUS_CMD_ERRORBIT(7)
+#define SWRM_INTERRUPT_STATUS_DOUT_PORT_COLLISION  BIT(8)
+#define SWRM_INTERRUPT_STATUS_READ_EN_RD_VALID_MISMATCHBIT(9)
 #define SWRM_INTERRUPT_STATUS_SPECIAL_CMD_ID_FINISHED  BIT(10)
+#define SWRM_INTERRUPT_STATUS_BUS_RESET_FINISHED_V2 BIT(13)
+#define SWRM_INTERRUPT_STATUS_CLK_STOP_FINISHED_V2  BIT(14)
+#define SWRM_INTERRUPT_STATUS_EXT_CLK_STOP_WAKEUP   BIT(16)
+#define SWRM_INTERRUPT_MAX 17
 #define SWRM_INTERRUPT_MASK_ADDR   0x204
 #define SWRM_INTERRUPT_CLEAR   0x208
 #define SWRM_INTERRUPT_CPU_EN  0x210
@@ -58,6 +69,7 @@
 #define SWRM_MCP_STATUS_BANK_NUM_MASK  BIT(0)
 #define SWRM_MCP_SLV_STATUS0x1090
 #define SWRM_MCP_SLV_STATUS_MASK   GENMASK(1, 0)
+#define SWRM_MCP_SLV_STATUS_SZ 2
 #define SWRM_DP_PORT_CTRL_BANK(n, m)   (0x1124 + 0x100 * (n - 1) + 0x40 * m)
 #define SWRM_DP_PORT_CTRL_2_BANK(n, m) (0x1128 + 0x100 * (n - 1) + 0x40 * m)
 #define SWRM_DP_BLOCK_CTRL_1(n)(0x112C + 0x100 * (n - 1))
@@ -123,6 +135,7 @@ struct qcom_swrm_ctrl {
int rows_index;
unsigned long dout_port_mask;
unsigned long din_port_mask;
+   u32 intr_mask;
u8 rcmd_id;
u8 wcmd_id;
struct qcom_swrm_port_config pconfig[QCOM_SDW_MAX_PORTS];
@@ -304,6 +317,25 @@ static int qcom_swrm_cmd_fifo_rd_cmd(struct qcom_swrm_ctrl 
*swrm,
return SDW_CMD_IGNORED;
 }
 
+static int qcom_swrm_get_alert_slave_dev_num(struct qcom_swrm_ctrl *ctrl)
+{
+   u32 val, status;
+   int dev_num;
+
+   ctrl->reg_read(ctrl, SWRM_MCP_SLV_STATUS, &val);
+
+   for (dev_num = 0; dev_num < SDW_MAX_DEVICES; dev_num++) {
+   status = (val >> (dev_num * SWRM_MCP_SLV_STATUS_SZ));
+
+   if ((status & SWRM_MCP_SLV_STATUS_MASK) == SDW_SLAVE_ALERT) {
+   ctrl->status[dev_num] = status;
+   return dev_num;
+   }
+   }
+
+   return -EINVAL;
+}
+
 static void qcom_swrm_get_device_status(struct qcom_swrm_ctrl *ctrl)
 {
u32 val;
@@ -322,36 +354,112 @@ static void qcom_swrm_get_device_status(struct 
qcom_swrm_ctrl *ctrl)
 
 static irqreturn_t qcom_swrm_irq_handler(int irq, void *dev_id)
 {
-   struct qcom_swrm_ctrl *ctrl = dev_id;
-   u32 sts, value;
+   struct qcom_swrm_ctrl *swrm = dev_id;
+   u32 value, intr_sts, intr_sts_masked;
+   u32 i;
+   u8 devnum = 0;
+   int ret = IRQ_HANDLED;
 
-   ctrl->reg_read(ctrl, SWRM_INTERRUPT_STATUS, &sts);
+   swrm->reg_read(swrm, SWRM_INTERRUPT_STATUS, &intr_sts);
+   intr_sts_masked = intr_sts & swrm->intr_mask;
 
-   if (sts & SWRM_INTERRUPT_STATUS_CMD_ERROR) {
-   ctrl->reg_read(ctrl, SWRM_CMD_FIFO_STATUS, &value);
-   dev_err_ratelimited(ctrl->dev,
-   "CMD error, fifo status 0x%x\n",
-value);
-   ctrl->reg_write(ctrl, SWRM_CMD_FIFO_CMD, 0x1);
-   }
-
-   if ((sts & SWRM_INTERRUPT_STATUS_NEW_SLAVE_ATTACHED) ||
-   sts & SWRM_INTERRUPT_STATUS_CHANGE_ENUM_SLAVE_STATUS) {
-   qcom_swrm_get_device_status(ctrl);
-   sdw_handle_slave_status(&ctrl->bus, ctrl->status);
-   }
-
-   /**
-* cle

[PATCH v5 8/9] soundwire: qcom: add auto enumeration support

Qualcomm SoundWire controller supports Auto Enumeration of the
devices within the IP. This patch enables support for this feature.

Signed-off-by: Srinivas Kandagatla 
Reviewed-by: Pierre-Louis Bossart 
---
 drivers/soundwire/qcom.c | 86 +---
 1 file changed, 81 insertions(+), 5 deletions(-)

diff --git a/drivers/soundwire/qcom.c b/drivers/soundwire/qcom.c
index 6a563fb52444..c6c923329b15 100644
--- a/drivers/soundwire/qcom.c
+++ b/drivers/soundwire/qcom.c
@@ -57,6 +57,8 @@
 #define SWRM_CMD_FIFO_RD_FIFO_ADDR 0x318
 #define SWRM_RD_FIFO_CMD_ID_MASK   GENMASK(11, 8)
 #define SWRM_ENUMERATOR_CFG_ADDR   0x500
+#define SWRM_ENUMERATOR_SLAVE_DEV_ID_1(m)  (0x530 + 0x8 * (m))
+#define SWRM_ENUMERATOR_SLAVE_DEV_ID_2(m)  (0x534 + 0x8 * (m))
 #define SWRM_MCP_FRAME_CTRL_BANK_ADDR(m)   (0x101C + 0x40 * (m))
 #define SWRM_MCP_FRAME_CTRL_BANK_COL_CTRL_BMSK GENMASK(2, 0)
 #define SWRM_MCP_FRAME_CTRL_BANK_ROW_CTRL_BMSK GENMASK(7, 3)
@@ -143,6 +145,7 @@ struct qcom_swrm_ctrl {
enum sdw_slave_status status[SDW_MAX_DEVICES];
int (*reg_read)(struct qcom_swrm_ctrl *ctrl, int reg, u32 *val);
int (*reg_write)(struct qcom_swrm_ctrl *ctrl, int reg, int val);
+   u32 slave_status;
 };
 
 struct qcom_swrm_data {
@@ -342,6 +345,7 @@ static void qcom_swrm_get_device_status(struct 
qcom_swrm_ctrl *ctrl)
int i;
 
ctrl->reg_read(ctrl, SWRM_MCP_SLV_STATUS, &val);
+   ctrl->slave_status = val;
 
for (i = 0; i < SDW_MAX_DEVICES; i++) {
u32 s;
@@ -352,10 +356,74 @@ static void qcom_swrm_get_device_status(struct 
qcom_swrm_ctrl *ctrl)
}
 }
 
+static void qcom_swrm_set_slave_dev_num(struct sdw_bus *bus,
+   struct sdw_slave *slave, int devnum)
+{
+   struct qcom_swrm_ctrl *ctrl = to_qcom_sdw(bus);
+   u32 status;
+
+   ctrl->reg_read(ctrl, SWRM_MCP_SLV_STATUS, &status);
+   status = (status >> (devnum * SWRM_MCP_SLV_STATUS_SZ));
+   status &= SWRM_MCP_SLV_STATUS_MASK;
+
+   if (status == SDW_SLAVE_ATTACHED) {
+   if (slave)
+   slave->dev_num = devnum;
+   mutex_lock(&bus->bus_lock);
+   set_bit(devnum, bus->assigned);
+   mutex_unlock(&bus->bus_lock);
+   }
+}
+
+static int qcom_swrm_enumerate(struct sdw_bus *bus)
+{
+   struct qcom_swrm_ctrl *ctrl = to_qcom_sdw(bus);
+   struct sdw_slave *slave, *_s;
+   struct sdw_slave_id id;
+   u32 val1, val2;
+   bool found;
+   u64 addr;
+   int i;
+   char *buf1 = (char *)&val1, *buf2 = (char *)&val2;
+
+   for (i = 1; i <= SDW_MAX_DEVICES; i++) {
+   /*SCP_Devid5 - Devid 4*/
+   ctrl->reg_read(ctrl, SWRM_ENUMERATOR_SLAVE_DEV_ID_1(i), &val1);
+
+   /*SCP_Devid3 - DevId 2 Devid 1 Devid 0*/
+   ctrl->reg_read(ctrl, SWRM_ENUMERATOR_SLAVE_DEV_ID_2(i), &val2);
+
+   if (!val1 && !val2)
+   break;
+
+   addr = buf2[1] | (buf2[0] << 8) | (buf1[3] << 16) |
+   ((u64)buf1[2] << 24) | ((u64)buf1[1] << 32) |
+   ((u64)buf1[0] << 40);
+
+   sdw_extract_slave_id(bus, addr, &id);
+   found = false;
+   /* Now compare with entries */
+   list_for_each_entry_safe(slave, _s, &bus->slaves, node) {
+   if (sdw_compare_devid(slave, id) == 0) {
+   qcom_swrm_set_slave_dev_num(bus, slave, i);
+   found = true;
+   break;
+   }
+   }
+
+   if (!found) {
+   qcom_swrm_set_slave_dev_num(bus, NULL, i);
+   sdw_slave_add(bus, &id, NULL);
+   }
+   }
+
+   return 0;
+}
+
 static irqreturn_t qcom_swrm_irq_handler(int irq, void *dev_id)
 {
struct qcom_swrm_ctrl *swrm = dev_id;
-   u32 value, intr_sts, intr_sts_masked;
+   u32 value, intr_sts, intr_sts_masked, slave_status;
u32 i;
u8 devnum = 0;
int ret = IRQ_HANDLED;
@@ -384,8 +452,15 @@ static irqreturn_t qcom_swrm_irq_handler(int irq, void 
*dev_id)
case SWRM_INTERRUPT_STATUS_CHANGE_ENUM_SLAVE_STATUS:
dev_err_ratelimited(swrm->dev, "%s: SWR new 
slave attached\n",
__func__);
-   qcom_swrm_get_device_status(swrm);
-   sdw_handle_slave_status(&swrm->bus, 
swrm->status);
+   swrm->reg_read(swrm, SWRM_MCP_SLV_STATUS, 
&slave_status);
+   if (swrm->slave_status == slave_status) {
+   dev_err(swrm

[PATCH v9 3/3] arm64: dts: ti: k3-j7200: Add support for higher speed modes and update delay select values for MMCSD subsystems

The following speed modes are now supported in J7200 SoC,
- HS200 and HS400 modes at 1.8 V card voltage, in MMCSD0 subsystem [1].
- UHS-I speed modes in MMCSD1 subsystem [1].

Add support for UHS-I modes by adding voltage regulator device tree nodes
and corresponding pinmux details, to power cycle and voltage switch cards.
Set respective tags in sdhci0 and remove no-1-8-v tag from sdhci1
device tree nodes.

Also update the delay values for various speed modes supported, based on
the revised january 2021 J7200 datasheet[2].

[1] - section 12.3.6.1.1 MMCSD Features, in
  https://www.ti.com/lit/ug/spruiu1a/spruiu1a.pdf,
  (SPRUIU1A – JULY 2020 – REVISED JANUARY 2021)

[2] - https://www.ti.com/lit/ds/symlink/dra821u.pdf,
  (SPRSP57B – APRIL 2020 – REVISED JANUARY 2021)

Signed-off-by: Aswath Govindraju 
Reviewed-by: Kishon Vijay Abraham I 
---
 .../dts/ti/k3-j7200-common-proc-board.dts | 78 +++
 arch/arm64/boot/dts/ti/k3-j7200-main.dtsi | 14 +++-
 2 files changed, 90 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts 
b/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts
index b493f939b09a..bedd01b7a32c 100644
--- a/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts
+++ b/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts
@@ -16,6 +16,65 @@
stdout-path = "serial2:115200n8";
bootargs = "console=ttyS2,115200n8 
earlycon=ns16550a,mmio32,0x0280";
};
+
+   evm_12v0: fixedregulator-evm12v0 {
+   /* main supply */
+   compatible = "regulator-fixed";
+   regulator-name = "evm_12v0";
+   regulator-min-microvolt = <1200>;
+   regulator-max-microvolt = <1200>;
+   regulator-always-on;
+   regulator-boot-on;
+   };
+
+   vsys_3v3: fixedregulator-vsys3v3 {
+   /* Output of LM5140 */
+   compatible = "regulator-fixed";
+   regulator-name = "vsys_3v3";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   vin-supply = <&evm_12v0>;
+   regulator-always-on;
+   regulator-boot-on;
+   };
+
+   vsys_5v0: fixedregulator-vsys5v0 {
+   /* Output of LM5140 */
+   compatible = "regulator-fixed";
+   regulator-name = "vsys_5v0";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   vin-supply = <&evm_12v0>;
+   regulator-always-on;
+   regulator-boot-on;
+   };
+
+   vdd_mmc1: fixedregulator-sd {
+   /* Output of TPS22918 */
+   compatible = "regulator-fixed";
+   regulator-name = "vdd_mmc1";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-boot-on;
+   enable-active-high;
+   vin-supply = <&vsys_3v3>;
+   gpio = <&exp2 2 GPIO_ACTIVE_HIGH>;
+   };
+
+   vdd_sd_dv: gpio-regulator-TLV71033 {
+   /* Output of TLV71033 */
+   compatible = "regulator-gpio";
+   regulator-name = "tlv71033";
+   pinctrl-names = "default";
+   pinctrl-0 = <&vdd_sd_dv_pins_default>;
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <330>;
+   regulator-boot-on;
+   vin-supply = <&vsys_5v0>;
+   gpios = <&main_gpio0 55 GPIO_ACTIVE_HIGH>;
+   states = <180 0x0>,
+<330 0x1>;
+   };
 };
 
 &wkup_pmx0 {
@@ -45,6 +104,13 @@
 };
 
 &main_pmx0 {
+   main_i2c0_pins_default: main-i2c0-pins-default {
+   pinctrl-single,pins = <
+   J721E_IOPAD(0xd4, PIN_INPUT_PULLUP, 0) /* (V3) I2C0_SCL 
*/
+   J721E_IOPAD(0xd8, PIN_INPUT_PULLUP, 0) /* (W2) I2C0_SDA 
*/
+   >;
+   };
+
main_i2c1_pins_default: main-i2c1-pins-default {
pinctrl-single,pins = <
J721E_IOPAD(0xdc, PIN_INPUT_PULLUP, 3) /* (U3) 
ECAP0_IN_APWM_OUT.I2C1_SCL */
@@ -70,6 +136,12 @@
J721E_IOPAD(0x120, PIN_OUTPUT, 0) /* (T4) USB0_DRVVBUS 
*/
>;
};
+
+   vdd_sd_dv_pins_default: vdd-sd-dv-pins-default {
+   pinctrl-single,pins = <
+   J721E_IOPAD(0xd0, PIN_OUTPUT, 7) /* (T5) 
SPI0_D1.GPIO0_55 */
+   >;
+   };
 };
 
 &wkup_uart0 {
@@ -157,6 +229,10 @@
 };
 
 &main_i2c0 {
+   pinctrl-names = "default";
+   pinctrl-0 = <&main_i2c0_pins_default>;
+   clock-frequency = <40>;
+
exp1: gpio@20 {
compatible = "ti,tca6416";
reg = <0x20>;
@@ -206,6 +282,8 @@
/* SD card */
pinctrl-0 = <&main_mmc

[PATCH v9 0/3] J7200: Add support for GPIO and higher speed modes in MMCSD subsystems

The following series of patches
- Add support for GPIO subsystem in main and wakeup domains.
- Add voltage regulator device tree nodes and their corresponding pinmux
  to support power cycle and voltage switch required for UHS-I modes
- sets respective tags in sdhci0 node to support higher speeds
- remove no-1-8-v tag from sdhci1 node to support UHS-I modes
- Update delay values for various speed modes supported.


test logs
- eMMC HS400 speed mode
  https://pastebin.ubuntu.com/p/pRzV2ZvSJZ/

- SD SDR104 speed mode
  https://pastebin.ubuntu.com/p/n64PNdDy2v/

- GPIO logs
  https://pastebin.ubuntu.com/p/HDBBMwMcdj/

Changes since v8:
- Fixed minor changes sugested by kishon in patch 3
- Picked up kishon's reviewed-by for patch 3

Changes since v7:
- Added the voltage regulator nodes to indicate the complete
  power flow for MMCSD1 subsystem
- Corrected minor errors in DT nodes
- Reran the tests.
- Rebased the series

Changes since v6:
- Corrected the node name from vdd_sd_dv_pins_default to
  vdd-sd-dv-pins-default

Changes since v5:
- Corrected the link in patch 3 as it broken.
- Added the version number for the references used in patch 3.
- picked up reviewed-by from grygorii for patches 1 and 2.

Changes since v4:
- Added main_i2c0 pinmux required for doing power cycles to MMCSD1
  subsystem
- Updated delay values for various speed modes supported
- Corrected the ti,ngpio property to indicate highest gpio lines that
  can be accessed.
- Reran the performace tests

Changes since v3:
- Removed patch (1 in v3).
- Rebased and included patches that add support for GPIO from series [1].
- Re-ran the performace tests for SD and eMMC.

Changes since v2:
- Added main_gpio0 DT node
- Added voltage regulator device tree nodes required to support UHS-I modes

Changes since v1:
- squashed the two patches into one
- added performance logs for the above mentioned speed modes

Aswath Govindraju (1):
  arm64: dts: ti: k3-j7200: Add support for higher speed modes and
update delay select values for MMCSD subsystems

Faiz Abbas (2):
  arm64: dts: ti: k3-j7200: Add gpio nodes
  arm64: dts: ti: k3-j7200-common-proc-board: Disable unused gpio
modules

 .../dts/ti/k3-j7200-common-proc-board.dts | 94 +++
 arch/arm64/boot/dts/ti/k3-j7200-main.dtsi | 86 -
 .../boot/dts/ti/k3-j7200-mcu-wakeup.dtsi  | 34 +++
 3 files changed, 212 insertions(+), 2 deletions(-)

-- 
2.17.1

[PATCH v5 5/9] soundwire: qcom: update register read/write routine

In the existing code every soundwire register read and register write
are kinda blocked. Each of these are using a special command id that
generates interrupt after it successfully finishes. This is really
overhead, limiting and not really necessary unless we are doing
something special.

We can simply read/write the fifo that should also give exactly
what we need! This will also allow to read/write registers in
interrupt context, which was not possible with the special
command approach.

With previous approach number of interrupts generated
after enumeration are around 130:
$ cat /proc/interrupts  | grep soundwire
 21: 130 0 0 0 0 0 0 0 GICv3 234 Edge  soundwire

after this patch they are just 3 interrupts
$ cat /proc/interrupts  | grep soundwire
 21: 3 0 0 0 0 0 0 0 GICv3 234 Edge  soundwire

This has significantly not only reduced interrupting CPU during enumeration
but also during streaming!

Signed-off-by: Srinivas Kandagatla 
Reviewed-by: Pierre-Louis Bossart 
---
 drivers/soundwire/qcom.c | 178 ++-
 1 file changed, 99 insertions(+), 79 deletions(-)

diff --git a/drivers/soundwire/qcom.c b/drivers/soundwire/qcom.c
index 2bcb4362f0e0..0cbd611fb8c6 100644
--- a/drivers/soundwire/qcom.c
+++ b/drivers/soundwire/qcom.c
@@ -38,11 +38,13 @@
 #define SWRM_CMD_FIFO_WR_CMD   0x300
 #define SWRM_CMD_FIFO_RD_CMD   0x304
 #define SWRM_CMD_FIFO_CMD  0x308
+#define SWRM_CMD_FIFO_FLUSH0x1
 #define SWRM_CMD_FIFO_STATUS   0x30C
 #define SWRM_CMD_FIFO_CFG_ADDR 0x314
 #define SWRM_CONTINUE_EXEC_ON_CMD_IGNORE   BIT(31)
 #define SWRM_RD_WR_CMD_RETRIES 0x7
 #define SWRM_CMD_FIFO_RD_FIFO_ADDR 0x318
+#define SWRM_RD_FIFO_CMD_ID_MASK   GENMASK(11, 8)
 #define SWRM_ENUMERATOR_CFG_ADDR   0x500
 #define SWRM_MCP_FRAME_CTRL_BANK_ADDR(m)   (0x101C + 0x40 * (m))
 #define SWRM_MCP_FRAME_CTRL_BANK_COL_CTRL_BMSK GENMASK(2, 0)
@@ -78,13 +80,16 @@
 #define SWRM_SPECIAL_CMD_ID0xF
 #define MAX_FREQ_NUM   1
 #define TIMEOUT_MS (2 * HZ)
-#define QCOM_SWRM_MAX_RD_LEN   0xf
+#define QCOM_SWRM_MAX_RD_LEN   0x1
 #define QCOM_SDW_MAX_PORTS 14
 #define DEFAULT_CLK_FREQ   960
 #define SWRM_MAX_DAIS  0xF
 #define SWR_INVALID_PARAM 0xFF
 #define SWR_HSTOP_MAX_VAL 0xF
 #define SWR_HSTART_MIN_VAL 0x0
+#define SWR_BROADCAST_CMD_ID0x0F
+#define SWR_MAX_CMD_ID 14
+#define MAX_FIFO_RD_RETRY 3
 
 struct qcom_swrm_port_config {
u8 si;
@@ -103,10 +108,8 @@ struct qcom_swrm_ctrl {
struct device *dev;
struct regmap *regmap;
void __iomem *mmio;
-   struct completion *comp;
+   struct completion broadcast;
struct work_struct slave_work;
-   /* read/write lock */
-   spinlock_t comp_lock;
/* Port alloc/free lock */
struct mutex port_lock;
struct clk *hclk;
@@ -120,6 +123,8 @@ struct qcom_swrm_ctrl {
int rows_index;
unsigned long dout_port_mask;
unsigned long din_port_mask;
+   u8 rcmd_id;
+   u8 wcmd_id;
struct qcom_swrm_port_config pconfig[QCOM_SDW_MAX_PORTS];
struct sdw_stream_runtime *sruntime[SWRM_MAX_DAIS];
enum sdw_slave_status status[SDW_MAX_DEVICES];
@@ -198,77 +203,105 @@ static int qcom_swrm_cpu_reg_write(struct qcom_swrm_ctrl 
*ctrl, int reg,
return SDW_CMD_OK;
 }
 
-static int qcom_swrm_cmd_fifo_wr_cmd(struct qcom_swrm_ctrl *ctrl, u8 cmd_data,
-u8 dev_addr, u16 reg_addr)
+static u32 swrm_get_packed_reg_val(u8 *cmd_id, u8 cmd_data,
+  u8 dev_addr, u16 reg_addr)
 {
-   DECLARE_COMPLETION_ONSTACK(comp);
-   unsigned long flags;
u32 val;
-   int ret;
-
-   spin_lock_irqsave(&ctrl->comp_lock, flags);
-   ctrl->comp = ∁
-   spin_unlock_irqrestore(&ctrl->comp_lock, flags);
-   val = SWRM_REG_VAL_PACK(cmd_data, dev_addr,
-   SWRM_SPECIAL_CMD_ID, reg_addr);
-   ret = ctrl->reg_write(ctrl, SWRM_CMD_FIFO_WR_CMD, val);
-   if (ret)
-   goto err;
-
-   ret = wait_for_completion_timeout(ctrl->comp,
- msecs_to_jiffies(TIMEOUT_MS));
+   u8 id = *cmd_id;
 
-   if (!ret)
-   ret = SDW_CMD_IGNORED;
-   else
-   ret = SDW_CMD_OK;
-err:
-   spin_lock_irqsave(&ctrl->comp_lock, flags);
-   ctrl->comp = NULL;
-   spin_unlock_irqrestore(&ctrl->comp_lock, flags);
+   if (id != SWR_BROADCAST_CMD_ID) {
+   if (id < SWR_MAX_CMD_ID)
+   id += 1;
+   else
+   id = 0;
+   *cmd

[PATCH v5 3/9] soundwire: qcom: set continue execution flag for ignored commands

version 1.5.1 and higher IPs of this controller required to set
continue execution on ignored command flag. This patch sets this flag.

Signed-off-by: Srinivas Kandagatla 
Reviewed-by: Pierre-Louis Bossart 
---
 drivers/soundwire/qcom.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/soundwire/qcom.c b/drivers/soundwire/qcom.c
index d05e41f68658..43ec22a5e332 100644
--- a/drivers/soundwire/qcom.c
+++ b/drivers/soundwire/qcom.c
@@ -40,6 +40,7 @@
 #define SWRM_CMD_FIFO_CMD  0x308
 #define SWRM_CMD_FIFO_STATUS   0x30C
 #define SWRM_CMD_FIFO_CFG_ADDR 0x314
+#define SWRM_CONTINUE_EXEC_ON_CMD_IGNORE   BIT(31)
 #define SWRM_RD_WR_CMD_RETRIES 0x7
 #define SWRM_CMD_FIFO_RD_FIFO_ADDR 0x318
 #define SWRM_ENUMERATOR_CFG_ADDR   0x500
@@ -343,7 +344,15 @@ static int qcom_swrm_init(struct qcom_swrm_ctrl *ctrl)
ctrl->reg_write(ctrl, SWRM_MCP_CFG_ADDR, val);
 
/* Configure number of retries of a read/write cmd */
-   ctrl->reg_write(ctrl, SWRM_CMD_FIFO_CFG_ADDR, SWRM_RD_WR_CMD_RETRIES);
+   if (ctrl->version > 0x01050001) {
+   /* Only for versions >= 1.5.1 */
+   ctrl->reg_write(ctrl, SWRM_CMD_FIFO_CFG_ADDR,
+   SWRM_RD_WR_CMD_RETRIES |
+   SWRM_CONTINUE_EXEC_ON_CMD_IGNORE);
+   } else {
+   ctrl->reg_write(ctrl, SWRM_CMD_FIFO_CFG_ADDR,
+   SWRM_RD_WR_CMD_RETRIES);
+   }
 
/* Set IRQ to PULSE */
ctrl->reg_write(ctrl, SWRM_COMP_CFG_ADDR,
-- 
2.21.0

[PATCH v5 2/9] soundwire: qcom: add support to missing transport params

Some of the transport parameters derived from device tree
are not fully parsed by the driver.

This patch adds support to parse those missing parameters.

Signed-off-by: Srinivas Kandagatla 
Reviewed-by: Pierre-Louis Bossart 
---
 drivers/soundwire/qcom.c | 107 ++-
 1 file changed, 95 insertions(+), 12 deletions(-)

diff --git a/drivers/soundwire/qcom.c b/drivers/soundwire/qcom.c
index 39222b04a2e0..d05e41f68658 100644
--- a/drivers/soundwire/qcom.c
+++ b/drivers/soundwire/qcom.c
@@ -54,7 +54,13 @@
 #define SWRM_MCP_SLV_STATUS0x1090
 #define SWRM_MCP_SLV_STATUS_MASK   GENMASK(1, 0)
 #define SWRM_DP_PORT_CTRL_BANK(n, m)   (0x1124 + 0x100 * (n - 1) + 0x40 * m)
+#define SWRM_DP_PORT_CTRL_2_BANK(n, m) (0x1128 + 0x100 * (n - 1) + 0x40 * m)
+#define SWRM_DP_BLOCK_CTRL_1(n)(0x112C + 0x100 * (n - 1))
+#define SWRM_DP_BLOCK_CTRL2_BANK(n, m) (0x1130 + 0x100 * (n - 1) + 0x40 * m)
+#define SWRM_DP_PORT_HCTRL_BANK(n, m)  (0x1134 + 0x100 * (n - 1) + 0x40 * m)
 #define SWRM_DP_BLOCK_CTRL3_BANK(n, m) (0x1138 + 0x100 * (n - 1) + 0x40 * m)
+#define SWRM_DIN_DPn_PCM_PORT_CTRL(n)  (0x1054 + 0x100 * (n - 1))
+
 #define SWRM_DP_PORT_CTRL_EN_CHAN_SHFT 0x18
 #define SWRM_DP_PORT_CTRL_OFFSET2_SHFT 0x10
 #define SWRM_DP_PORT_CTRL_OFFSET1_SHFT 0x08
@@ -73,12 +79,20 @@
 #define QCOM_SDW_MAX_PORTS 14
 #define DEFAULT_CLK_FREQ   960
 #define SWRM_MAX_DAIS  0xF
+#define SWR_INVALID_PARAM 0xFF
+#define SWR_HSTOP_MAX_VAL 0xF
+#define SWR_HSTART_MIN_VAL 0x0
 
 struct qcom_swrm_port_config {
u8 si;
u8 off1;
u8 off2;
u8 bp_mode;
+   u8 hstart;
+   u8 hstop;
+   u8 word_length;
+   u8 blk_group_count;
+   u8 lane_control;
 };
 
 struct qcom_swrm_ctrl {
@@ -396,8 +410,11 @@ static int qcom_swrm_port_params(struct sdw_bus *bus,
 struct sdw_port_params *p_params,
 unsigned int bank)
 {
-   /* TBD */
-   return 0;
+   struct qcom_swrm_ctrl *ctrl = to_qcom_sdw(bus);
+
+   return ctrl->reg_write(ctrl, SWRM_DP_BLOCK_CTRL_1(p_params->num),
+  p_params->bps - 1);
+
 }
 
 static int qcom_swrm_transport_params(struct sdw_bus *bus,
@@ -405,20 +422,45 @@ static int qcom_swrm_transport_params(struct sdw_bus *bus,
  enum sdw_reg_bank bank)
 {
struct qcom_swrm_ctrl *ctrl = to_qcom_sdw(bus);
+   struct qcom_swrm_port_config *pcfg;
u32 value;
int reg = SWRM_DP_PORT_CTRL_BANK((params->port_num), bank);
int ret;
 
-   value = params->offset1 << SWRM_DP_PORT_CTRL_OFFSET1_SHFT;
-   value |= params->offset2 << SWRM_DP_PORT_CTRL_OFFSET2_SHFT;
-   value |= params->sample_interval - 1;
+   pcfg = &ctrl->pconfig[params->port_num - 1];
+
+   value = pcfg->off1 << SWRM_DP_PORT_CTRL_OFFSET1_SHFT;
+   value |= pcfg->off2 << SWRM_DP_PORT_CTRL_OFFSET2_SHFT;
+   value |= pcfg->si;
 
ret = ctrl->reg_write(ctrl, reg, value);
 
-   if (!ret && params->blk_pkg_mode) {
-   reg = SWRM_DP_BLOCK_CTRL3_BANK(params->port_num, bank);
+   if (pcfg->lane_control != SWR_INVALID_PARAM) {
+   reg = SWRM_DP_PORT_CTRL_2_BANK(params->port_num, bank);
+   value = pcfg->lane_control;
+   ret = ctrl->reg_write(ctrl, reg, value);
+   }
+
+   if (pcfg->blk_group_count != SWR_INVALID_PARAM) {
+   reg = SWRM_DP_BLOCK_CTRL2_BANK(params->port_num, bank);
+   value = pcfg->blk_group_count;
+   ret = ctrl->reg_write(ctrl, reg, value);
+   }
+
+   if (pcfg->hstart != SWR_INVALID_PARAM
+   && pcfg->hstop != SWR_INVALID_PARAM) {
+   reg = SWRM_DP_PORT_HCTRL_BANK(params->port_num, bank);
+   value = (pcfg->hstop << 4) | pcfg->hstart;
+   ret = ctrl->reg_write(ctrl, reg, value);
+   } else {
+   reg = SWRM_DP_PORT_HCTRL_BANK(params->port_num, bank);
+   value = (SWR_HSTOP_MAX_VAL << 4) | SWR_HSTART_MIN_VAL;
+   ret = ctrl->reg_write(ctrl, reg, value);
+   }
 
-   ret = ctrl->reg_write(ctrl, reg, 1);
+   if (pcfg->bp_mode != SWR_INVALID_PARAM) {
+   reg = SWRM_DP_BLOCK_CTRL3_BANK(params->port_num, bank);
+   ret = ctrl->reg_write(ctrl, reg, pcfg->bp_mode);
}
 
return ret;
@@ -468,10 +510,13 @@ static int qcom_swrm_compute_params(struct sdw_bus *bus)
list_for_each_entry(p_rt, &m_rt->port_list, port_node) {
pcfg = &ctrl->pconfig[p_rt->num - 1];
p_rt->transport_params.port_num = p_rt->num;
-   p_rt->transport_params.sample_interval = pcfg->si + 1;
-   p_rt->transport_params.offset1 = pc

[PATCH v5 0/9] soundwire: qcom: various improvements

Thanks for reviewing v4 of this patchset!

During testing SoundWire controller on SM8250 MTP, we found
few issues like all the interrupts are not handled,
all transport parameters are not read from device tree.
Patch to add Auto Enumeration supported by the controller
is also part of this series.

Other major issue was register read/writes which was interrupt based
was an overhead and puts lot of limitation on context it can be used from.

With previous approach number of interrupts generated
after enumeration are around 130:
$ cat /proc/interrupts  | grep soundwire
21: 130 0 0 0 0 0 0 0 GICv3 234 Edge  soundwire

after this patch they are just 3 interrupts
$ cat /proc/interrupts  | grep soundwire
21: 3 0 0 0 0 0 0 0 GICv3 234 Edge  soundwire

So this patchset add various improvements to the existing driver
to address above issues.

Tested it on SM8250 MTP with 2x WSA881x speakers, HeadPhones on
WCD938x via lpass-rx-macro and Analog MICs via lpass-tx-macro.
Also tested on DragonBoard DB845c with 2xWSA881x speakers.

Changes since v4:
- exported sdw_slave_add as kernel test robot reported error

Srinivas Kandagatla (9):
  dt-bindings: soundwire: qcom: clarify data port bus parameters
  soundwire: qcom: add support to missing transport params
  soundwire: qcom: set continue execution flag for ignored commands
  soundwire: qcom: start the clock during initialization
  soundwire: qcom: update register read/write routine
  soundwire: qcom: add support to new interrupts
  soundwire: export sdw_compare_devid, sdw_extract_slave_id and
sdw_slave_add
  soundwire: qcom: add auto enumeration support
  soundwire: qcom: wait for enumeration to be complete in probe

 .../bindings/soundwire/qcom,sdw.txt   |  20 +
 drivers/soundwire/bus.c   |   4 +-
 drivers/soundwire/qcom.c  | 529 ++
 drivers/soundwire/slave.c |   1 +
 include/linux/soundwire/sdw.h |   2 +
 5 files changed, 443 insertions(+), 113 deletions(-)

-- 
2.21.0

[PATCH v5 1/9] dt-bindings: soundwire: qcom: clarify data port bus parameters

Some of the parameters for data ports are not applicable or not implemented
in IP. So mark them as invalid/not applicable in DT so that controller is
aware of this.

Add comment to these bindings to provide more clarity on the values!

Signed-off-by: Srinivas Kandagatla 
Acked-by: Rob Herring 
Reviewed-by: Pierre-Louis Bossart 
---
 .../bindings/soundwire/qcom,sdw.txt   | 20 +++
 1 file changed, 20 insertions(+)

diff --git a/Documentation/devicetree/bindings/soundwire/qcom,sdw.txt 
b/Documentation/devicetree/bindings/soundwire/qcom,sdw.txt
index b104be131235..b93a2b3e029d 100644
--- a/Documentation/devicetree/bindings/soundwire/qcom,sdw.txt
+++ b/Documentation/devicetree/bindings/soundwire/qcom,sdw.txt
@@ -54,6 +54,8 @@ board specific bus parameters.
Value type: 
Definition: should specify payload transport window offset1 of each
data port. Out ports followed by In ports.
+   Value of 0xFF indicates that this option is not implemented
+   or applicable for the respective data port.
More info in MIPI Alliance SoundWire 1.0 Specifications.
 
 - qcom,ports-offset2:
@@ -61,6 +63,8 @@ board specific bus parameters.
Value type: 
Definition: should specify payload transport window offset2 of each
data port. Out ports followed by In ports.
+   Value of 0xFF indicates that this option is not implemented
+   or applicable for the respective data port.
More info in MIPI Alliance SoundWire 1.0 Specifications.
 
 - qcom,ports-sinterval-low:
@@ -69,12 +73,16 @@ board specific bus parameters.
Definition: should be sample interval low of each data port.
Out ports followed by In ports. Used for Sample Interval
calculation.
+   Value of 0xFF indicates that this option is not implemented
+   or applicable for the respective data port.
More info in MIPI Alliance SoundWire 1.0 Specifications.
 
 - qcom,ports-word-length:
Usage: optional
Value type: 
Definition: should be size of payload channel sample.
+   Value of 0xFF indicates that this option is not implemented
+   or applicable for the respective data port.
More info in MIPI Alliance SoundWire 1.0 Specifications.
 
 - qcom,ports-block-pack-mode:
@@ -84,6 +92,8 @@ board specific bus parameters.
0 to indicate Blocks are per Channel
1 to indicate Blocks are per Port.
Out ports followed by In ports.
+   Value of 0xFF indicates that this option is not implemented
+   or applicable for the respective data port.
More info in MIPI Alliance SoundWire 1.0 Specifications.
 
 - qcom,ports-block-group-count:
@@ -92,6 +102,8 @@ board specific bus parameters.
Definition: should be in range 1 to 4 to indicate how many sample
intervals are combined into a payload.
Out ports followed by In ports.
+   Value of 0xFF indicates that this option is not implemented
+   or applicable for the respective data port.
More info in MIPI Alliance SoundWire 1.0 Specifications.
 
 - qcom,ports-lane-control:
@@ -100,6 +112,8 @@ board specific bus parameters.
Definition: should be in range 0 to 7 to identify which data lane
the data port uses.
Out ports followed by In ports.
+   Value of 0xFF indicates that this option is not implemented
+   or applicable for the respective data port.
More info in MIPI Alliance SoundWire 1.0 Specifications.
 
 - qcom,ports-hstart:
@@ -109,6 +123,8 @@ board specific bus parameters.
SoundWire Frame, i.e. left edge of the Transport sub-frame
for each port. Values between 0 and 15 are valid.
Out ports followed by In ports.
+   Value of 0xFF indicates that this option is not implemented
+   or applicable for the respective data port.
More info in MIPI Alliance SoundWire 1.0 Specifications.
 
 - qcom,ports-hstop:
@@ -118,6 +134,8 @@ board specific bus parameters.
SoundWire Frame, i.e. the right edge of the Transport
sub-frame for each port. Values between 0 and 15 are valid.
Out ports followed by In ports.
+   Value of 0xFF indicates that this option is not implemented
+   or applicable for the respective data port.
More info in MIPI Alliance SoundWire 1.0 Specifications.
 
 - qcom,dports-type:
@@ -128,6 +146,8 @@ board specific bus parameters.
1 for simple ports

Re: [PATCH] PCI: ACPI: PM: Fix debug message in acpi_pci_set_power_state()

2021-03-25 Thread Krzysztof Wilczyński

Hi,

[...]
> To address this issue, modify the debug message in question to print
> the current power state of the target PCI device's ACPI companion
> instead of printing the target power state which may not reflect
> the real final power state of the device.
[...]

Thank you!

Reviewed-by: Krzysztof Wilczyński 

Krzysztof

Re: [PATCH 4/4] PCI/sysfs: Allow userspace to query and set device reset mechanism

2021-03-25 Thread Leon Romanovsky

On Thu, Mar 25, 2021 at 11:53:24AM -0600, Alex Williamson wrote:
> On Thu, 25 Mar 2021 18:09:58 +0200
> Leon Romanovsky  wrote:
> 
> > On Thu, Mar 25, 2021 at 08:55:04AM -0600, Alex Williamson wrote:
> > > On Thu, 25 Mar 2021 10:37:54 +0200
> > > Leon Romanovsky  wrote:
> > >   
> > > > On Wed, Mar 24, 2021 at 11:17:29AM -0600, Alex Williamson wrote:  
> > > > > On Wed, 24 Mar 2021 17:13:56 +0200
> > > > > Leon Romanovsky  wrote:
> > > > 
> > > > <...>
> > > >   
> > > > > > Yes, and real testing/debugging almost always requires kernel 
> > > > > > rebuild.
> > > > > > Everything else is waste of time.
> > > > > 
> > > > > Sorry, this is nonsense.  Allowing users to debug issues without a 
> > > > > full
> > > > > kernel rebuild is a good thing.
> > > > 
> > > > It is far from debug, this interface doesn't give you any answers why
> > > > the reset didn't work, it just helps you to find the one that works.
> > > > 
> > > > Unless you believe that this information will be enough to understand
> > > > the root cause, you will need to ask from the user to perform extra
> > > > tests, maybe try some quirk. All of that requires from the users to
> > > > rebuild their kernel.
> > > > 
> > > > So no, it is not debug.  
> > > 
> > > It allows a user to experiment to determine (a) my device doesn't work
> > > in a given scenario with the default configuration, but (b) if I change
> > > the reset to this other thing it does work.  That is a step in
> > > debugging.
> > > 
> > > It's absurd to think that a sysfs attribute could provide root cause,
> > > but it might be enough for someone to further help that user.  It would
> > > be a useful clue for a bug report.  Yes, reaching root cause might
> > > involve building a kernel, but that doesn't invalidate that having a
> > > step towards debugging in the base kernel might be a useful tool.  
> > 
> > Let's agree to do not agree.
> > 
> > >   
> > > > > > > > > For policy preference, I already described how I've 
> > > > > > > > > configured QEMU to
> > > > > > > > > prefer a bus reset rather than a PM reset due to lack of 
> > > > > > > > > specification
> > > > > > > > > regarding the scope of a PM "soft reset".  This interface 
> > > > > > > > > would allow a
> > > > > > > > > system policy to do that same thing.
> > > > > > > > > 
> > > > > > > > > I don't think anyone is suggesting this as a means to avoid 
> > > > > > > > > quirks that
> > > > > > > > > would resolve reset issues and create the best default 
> > > > > > > > > general behavior.
> > > > > > > > > This provides a mechanism to test various reset methods, and 
> > > > > > > > > thereby
> > > > > > > > > identify broken methods, and set a policy.  Sure, that policy 
> > > > > > > > > might be
> > > > > > > > > to avoid a broken reset in the interim before it gets quirked 
> > > > > > > > > and
> > > > > > > > > there's potential for abuse there, but I think the benefits 
> > > > > > > > > outweigh
> > > > > > > > > the risks.
> > > > > > > > 
> > > > > > > > This interface is proposed as first class citizen in the 
> > > > > > > > general sysfs
> > > > > > > > layout. Of course, it will be seen as a way to bypass the 
> > > > > > > > kernel.
> > > > > > > > 
> > > > > > > > At least, put it under CONFIG_EXPERT option, so no distro will 
> > > > > > > > enable it
> > > > > > > > by default.  
> > > > > > > 
> > > > > > > Of course we're proposing it to be accessible, it should also 
> > > > > > > require
> > > > > > > admin privileges to modify, sysfs has lots of such things.  If 
> > > > > > > it's
> > > > > > > relegated to non-default accessibility, it won't be used for 
> > > > > > > testing
> > > > > > > and it won't be available for system policy and it's pointless.   
> > > > > > >
> > > > > > 
> > > > > > We probably have difference in view of what testing is. I expect 
> > > > > > from
> > > > > > the users who experience issues with reset to do extra steps and 
> > > > > > one of
> > > > > > them is to require from them to compile their kernel.
> > > > > 
> > > > > I would define the ability to generate a CI test that can pick a
> > > > > device, unbind it from its driver, and iterate reset methods as a
> > > > > worthwhile improvement in testing.
> > > > 
> > > > Who is going to run this CI? At least all kernel CIs (external and
> > > > internal to HW vendors) that I'm familiar are building kernel 
> > > > themselves.
> > > > 
> > > > Distro kernel is too bloat to be really usable for CI.  
> > > 
> > > At this point I'm suspicious you're trolling.  A distro kernel CI
> > > certainly uses the kernel they intend to ship and support in their
> > > environment. You're concerned about a bloated kernel, but the proposal
> > > here adds 2-bytes per device to track reset methods and a trivial array
> > > in text memory, meanwhile you're proposing multiple per-device memory
> > > allocations to enhance the feature you think is too bloated for CI.  
> > 
> > I don'

[PATCH -next] drivers/soc/litex: remove duplicated include from litex_soc_ctrl.c

Remove duplicated include.

Reported-by: Hulk Robot 
Signed-off-by: Zheng Yongjun 
---
 drivers/soc/litex/litex_soc_ctrl.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/soc/litex/litex_soc_ctrl.c 
b/drivers/soc/litex/litex_soc_ctrl.c
index 6268bfa7f0d6..c3e379a990f2 100644
--- a/drivers/soc/litex/litex_soc_ctrl.c
+++ b/drivers/soc/litex/litex_soc_ctrl.c
@@ -13,7 +13,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include

[PATCH -next] bus: bt1-apb: Remove duplicated include from bt1-apb.c

Remove duplicated include.

Reported-by: Hulk Robot 
Signed-off-by: Zheng Yongjun 
---
 drivers/bus/bt1-apb.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/bus/bt1-apb.c b/drivers/bus/bt1-apb.c
index b25ff941e7c7..74b1b712ef3a 100644
--- a/drivers/bus/bt1-apb.c
+++ b/drivers/bus/bt1-apb.c
@@ -22,7 +22,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 #define APB_EHB_ISR0x00

[PATCH -next] ARM: sa11x0: remove duplicated include from hackkit.c

Remove duplicated include.

Reported-by: Hulk Robot 
Signed-off-by: Zheng Yongjun 
---
 arch/arm/mach-sa1100/hackkit.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/mach-sa1100/hackkit.c b/arch/arm/mach-sa1100/hackkit.c
index 3085f1c2e586..3fe34ee7c0ab 100644
--- a/arch/arm/mach-sa1100/hackkit.c
+++ b/arch/arm/mach-sa1100/hackkit.c
@@ -18,7 +18,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include

[PATCH -next] drivers/soc/litex: remove duplicated include from litex_soc_ctrl.c

Remove duplicated include.

Reported-by: Hulk Robot 
Signed-off-by: Zheng Yongjun 
---
 drivers/soc/litex/litex_soc_ctrl.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/soc/litex/litex_soc_ctrl.c 
b/drivers/soc/litex/litex_soc_ctrl.c
index 6268bfa7f0d6..c3e379a990f2 100644
--- a/drivers/soc/litex/litex_soc_ctrl.c
+++ b/drivers/soc/litex/litex_soc_ctrl.c
@@ -13,7 +13,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include

[PATCH v2] media: venus : hfi: add venus image info into smem

2021-03-25 Thread Dikshita Agarwal

Fill fw version info into smem to be printed as part of
soc info.

Signed-off-by: Dikshita Agarwal 

Changes since v1:
 adressed comments from stephen.
 removed unwanted code.
---
 drivers/media/platform/qcom/venus/hfi_msgs.c | 21 +++--
 1 file changed, 19 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/qcom/venus/hfi_msgs.c 
b/drivers/media/platform/qcom/venus/hfi_msgs.c
index 06a1908..6b6d33c9 100644
--- a/drivers/media/platform/qcom/venus/hfi_msgs.c
+++ b/drivers/media/platform/qcom/venus/hfi_msgs.c
@@ -6,6 +6,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "core.h"
@@ -14,6 +15,10 @@
 #include "hfi_msgs.h"
 #include "hfi_parser.h"
 
+#define SMEM_IMG_VER_TBL 469
+#define VER_STR_SZ 128
+#define SMEM_IMG_INDEX_VENUS 14 * 128
+
 static void event_seq_changed(struct venus_core *core, struct venus_inst *inst,
  struct hfi_msg_event_notify_pkt *pkt)
 {
@@ -239,15 +244,27 @@ static void
 sys_get_prop_image_version(struct device *dev,
   struct hfi_msg_sys_property_info_pkt *pkt)
 {
+   size_t smem_blk_sz = 0;
+   u8 *smem_tbl_ptr;
+   u8 *img_ver;
int req_bytes;
 
req_bytes = pkt->hdr.size - sizeof(*pkt);
 
-   if (req_bytes < 128 || !pkt->data[1] || pkt->num_properties > 1)
+   if (req_bytes < VER_STR_SZ || !pkt->data[1] || pkt->num_properties > 1)
/* bad packet */
return;
 
-   dev_dbg(dev, VDBGL "F/W version: %s\n", (u8 *)&pkt->data[1]);
+   img_ver = (u8 *)&pkt->data[1];
+
+   dev_dbg(dev, VDBGL "F/W version: %s\n", img_ver);
+
+   smem_tbl_ptr = qcom_smem_get(QCOM_SMEM_HOST_ANY,
+  SMEM_IMG_VER_TBL, &smem_blk_sz);
+   if ((SMEM_IMG_INDEX_VENUS + VER_STR_SZ) <= smem_blk_sz &&
+   smem_tbl_ptr)
+   memcpy(smem_tbl_ptr + SMEM_IMG_INDEX_VENUS,
+  img_ver, VER_STR_SZ);
 }
 
 static void hfi_sys_property_info(struct venus_core *core,
-- 
2.7.4

Re: [PATCH] livepatch: klp_send_signal should treat PF_IO_WORKER like PF_KTHREAD

2021-03-25 Thread dongkai (H)


On 2021/3/25 17:26, Miroslav Benes wrote:

On Thu, 25 Mar 2021, Dong Kai wrote:


commit 15b2219facad ("kernel: freezer should treat PF_IO_WORKER like
PF_KTHREAD for freezing") is to fix the freezeing issue of IO threads
by making the freezer not send them fake signals.

Here live patching consistency model call klp_send_signals to wake up
all tasks by send fake signal to all non-kthread which only check the
PF_KTHREAD flag, so it still send signal to io threads which may lead to
freezeing issue of io threads.


I suppose this could happen, but it will also affect the live patching
transition if the io threads do not react to signals.

Are you able to reproduce it easily? I mean, is there a testcase I could
use to take a closer look?
  


Um... I tried but failed to reproduce this on real environment as i'm 
not familiar with the io uring usage.


So i use a tricky way to verify this possibility by the following patch 
which create a fake io thread in module and patch the func which is 
always within thread running stack. Then the stack check will failed 
when transition and trigger the klp_send_signal flow.


This example may not suitable, but you can get my point

Kai

Note: this patch export some symbols just for test via module because if 
i create io thread via sysinit, it will receive SIGKILL signal[set by 
zap_other_threads] when run init process and exit the loop, weird...


diff --git a/fs/exec.c b/fs/exec.c
index 18594f11c31f..a64af6cac43b 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -1229,6 +1229,7 @@ void __set_task_comm(struct task_struct *tsk, 
const char *buf, bool exec)

task_unlock(tsk);
perf_event_comm(tsk, exec);
 }
+EXPORT_SYMBOL_GPL(__set_task_comm);

 /*
  * Calling this is the point of no return. None of the failures will be
diff --git a/kernel/fork.c b/kernel/fork.c
index 54cc905e5fe0..03064fef7bb1 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -2447,6 +2447,7 @@ struct task_struct *create_io_thread(int 
(*fn)(void *), void *arg, int node)

}
return tsk;
 }
+EXPORT_SYMBOL(create_io_thread);

 /*
  *  Ok, this is the main fork-routine.
index 98191218d891..8151d17149a0 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -3856,6 +3856,7 @@ void wake_up_new_task(struct task_struct *p)
 #endif
task_rq_unlock(rq, p, &rf);
 }
+EXPORT_SYMBOL_GPL(wake_up_new_task);

 #ifdef CONFIG_PREEMPT_NOTIFIERS

diff --git a/samples/test/Makefile b/samples/test/Makefile
new file mode 100644
index ..efbf01c6477e
--- /dev/null
+++ b/samples/test/Makefile
@@ -0,0 +1 @@
+obj-m += io_thread.o livepatch-sample.o
diff --git a/samples/test/io_thread.c b/samples/test/io_thread.c
new file mode 100644
index ..e7bdc51a4582
--- /dev/null
+++ b/samples/test/io_thread.c
@@ -0,0 +1,49 @@
+#include 
+#include 
+#include 
+#include 
+
+static __used noinline void func(void)
+{
+   printk("func\n");
+   schedule_timeout(HZ * 5);
+}
+
+static int io_worker(void *data)
+{
+   set_task_comm(current, "io_worker");
+   while (1) {
+   set_current_state(TASK_INTERRUPTIBLE);
+   func();
+
+   if (fatal_signal_pending(current))
+   break;
+   }
+
+   return 0;
+}
+
+static int __init io_thread_init(void)
+{
+   struct task_struct *task = NULL;
+
+   task = create_io_thread(io_worker, NULL, 0);
+   if (task == NULL)
+   return -EINVAL;
+   wake_up_new_task(task);
+
+   /* when insmod exit, io thread got SIGKILL and exit, so... */
+   while (1)
+   schedule_timeout(HZ);
+   return 0;
+}
+
+static void __exit io_thread_exit(void)
+{
+   return;
+}
+
+module_init(io_thread_init);
+module_exit(io_thread_exit);
+
+MODULE_LICENSE("GPL");
diff --git a/samples/test/livepatch-sample.c 
b/samples/test/livepatch-sample.c

new file mode 100644
index ..c35b494f5c5a
--- /dev/null
+++ b/samples/test/livepatch-sample.c
@@ -0,0 +1,43 @@
+#include 
+#include 
+#include 
+
+static void new_func(void)
+{
+   schedule_timeout(HZ * 5);
+   printk("new_func\n");
+}
+
+static struct klp_func funcs[] = {
+   {
+   .old_name = "func",
+   .new_func = new_func,
+   }, { }
+};
+
+static struct klp_object objs[] = {
+   {
+   .name = "io_thread",
+   .funcs = funcs,
+   }, { }
+};
+
+static struct klp_patch patch = {
+   .mod = THIS_MODULE,
+   .objs = objs,
+};
+
+static int livepatch_init(void)
+{
+   return klp_enable_patch(&patch);
+}
+
+static void livepatch_exit(void)
+{
+}
+
+module_init(livepatch_init);
+module_exit(livepatch_exit);
+MODULE_INFO(livepatch, "Y");
+
+MODULE_LICENSE("GPL");
--


Here we take the same fix action by treating PF_IO_WORKERS as PF_KTHREAD
within klp_send_signal function.


Yes, this sounds reasonable.

Miroslav


Signed-off-by: Dong Kai 
---
note:
the io threads freeze issue links:
[1] https://lore.kernel.org/io-uring/yegnip4

Re: [PATCH v2 6/8] block: keyslot-manager: introduce blk_ksm_restrict_dus_to_queue_limits()

Hi Satya,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on block/for-next]
[also build test WARNING on dm/for-next mkp-scsi/for-next scsi/for-next 
linux/master linus/master v5.12-rc4 next-20210325]
[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/Satya-Tangirala/ensure-bios-aren-t-split-in-middle-of-crypto-data-unit/20210326-053016
base:   https://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-block.git 
for-next
config: i386-randconfig-r016-20210325 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce (this is a W=1 build):
# 
https://github.com/0day-ci/linux/commit/9b8b677bfdba70695b8d01ee318ef552fcc0392e
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Satya-Tangirala/ensure-bios-aren-t-split-in-middle-of-crypto-data-unit/20210326-053016
git checkout 9b8b677bfdba70695b8d01ee318ef552fcc0392e
# save the attached .config to linux build tree
make W=1 ARCH=i386 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All warnings (new ones prefixed by >>):

>> block/keyslot-manager.c:457:6: warning: no previous prototype for 
>> 'blk_ksm_restrict_dus_to_queue_limits' [-Wmissing-prototypes]
 457 | void blk_ksm_restrict_dus_to_queue_limits(struct blk_keyslot_manager 
*ksm,
 |  ^~~~


vim +/blk_ksm_restrict_dus_to_queue_limits +457 block/keyslot-manager.c

   452  
   453  /*
   454   * Restrict the supported data unit sizes of the ksm based on the 
request queue
   455   * limits
   456   */
 > 457  void blk_ksm_restrict_dus_to_queue_limits(struct blk_keyslot_manager 
 > *ksm,
   458struct queue_limits *limits)
   459  {
   460  /* The largest possible data unit size we support is PAGE_SIZE. 
*/
   461  unsigned long largest_dus = PAGE_SIZE;
   462  unsigned int dus_allowed_mask;
   463  int i;
   464  bool dus_was_restricted = false;
   465  
   466  /*
   467   * If the queue doesn't support SG gaps, a bio might get split 
in the
   468   * middle of a data unit. So require SG gap support for inline
   469   * encryption for any data unit size larger than a single 
sector.
   470   */
   471  if (limits->virt_boundary_mask)
   472  largest_dus = SECTOR_SIZE;
   473  
   474  /*
   475   * If the queue has chunk_sectors, the bio might be split 
within a data
   476   * unit if the data unit size is larger than a single sector. 
So only
   477   * support a single sector data unit size in this case.
   478   */
   479  if (limits->chunk_sectors)
   480  largest_dus = SECTOR_SIZE;
   481  
   482  /*
   483   * Any bio sent to the queue must be allowed to contain at 
least a
   484   * data_unit_size worth of data. Since each segment in a bio 
contains
   485   * at least a SECTOR_SIZE worth of data, it's sufficient that
   486   * queue_max_segments(q) * SECTOR_SIZE >= data_unit_size. So 
disable
   487   * all data_unit_sizes not satisfiable.
   488   */
   489  largest_dus = min(largest_dus,
   490  1UL << (fls(limits->max_segments) - 1 + 
SECTOR_SHIFT));
   491  
   492  /* Clear all unsupported data unit sizes. */
   493  dus_allowed_mask = (largest_dus << 1) - 1;
   494  for (i = 0; i < ARRAY_SIZE(ksm->crypto_modes_supported); i++) {
   495  if (ksm->crypto_modes_supported[i] & 
(~dus_allowed_mask))
   496  dus_was_restricted = true;
   497  ksm->crypto_modes_supported[i] &= dus_allowed_mask;
   498  }
   499  
   500  if (dus_was_restricted) {
   501  pr_warn("Disallowed use of encryption data unit sizes 
above %lu bytes with inline encryption hardware because of device request queue 
limits.\n",
   502  largest_dus);
   503  }
   504  }
   505  

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org


.config.gz
Description: application/gzip

[PATCH 8/8] iommu/vt-d: fix a couple of spelling mistakes

There are several spelling mistakes, as follows:
guarentees ==> guarantees
resgister ==> register
insufficent ==> insufficient
creats ==> creates
tabke ==> take

Signed-off-by: Zhen Lei 
---
 drivers/iommu/intel/dmar.c  | 6 +++---
 drivers/iommu/intel/iommu.c | 2 +-
 drivers/iommu/intel/irq_remapping.c | 2 +-
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/iommu/intel/dmar.c b/drivers/iommu/intel/dmar.c
index d5c51b5c20aff4b..bb6f0880f6f4db0 100644
--- a/drivers/iommu/intel/dmar.c
+++ b/drivers/iommu/intel/dmar.c
@@ -45,7 +45,7 @@ struct dmar_res_callback {
 
 /*
  * Assumptions:
- * 1) The hotplug framework guarentees that DMAR unit will be hot-added
+ * 1) The hotplug framework guarantees that DMAR unit will be hot-added
  *before IO devices managed by that unit.
  * 2) The hotplug framework guarantees that DMAR unit will be hot-removed
  *after IO devices managed by that unit.
@@ -960,10 +960,10 @@ static void unmap_iommu(struct intel_iommu *iommu)
 /**
  * map_iommu: map the iommu's registers
  * @iommu: the iommu to map
- * @phys_addr: the physical address of the base resgister
+ * @phys_addr: the physical address of the base register
  *
  * Memory map the iommu's registers.  Start w/ a single page, and
- * possibly expand if that turns out to be insufficent.
+ * possibly expand if that turns out to be insufficient.
  */
 static int map_iommu(struct intel_iommu *iommu, u64 phys_addr)
 {
diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
index ee0932307d646bb..f9a2277fba99f9f 100644
--- a/drivers/iommu/intel/iommu.c
+++ b/drivers/iommu/intel/iommu.c
@@ -288,7 +288,7 @@ static inline void context_clear_entry(struct context_entry 
*context)
 
 /*
  * This domain is a statically identity mapping domain.
- * 1. This domain creats a static 1:1 mapping to all usable memory.
+ * 1. This domain creates a static 1:1 mapping to all usable memory.
  * 2. It maps to each iommu if successful.
  * 3. Each iommu mapps to this domain if successful.
  */
diff --git a/drivers/iommu/intel/irq_remapping.c 
b/drivers/iommu/intel/irq_remapping.c
index 611ef5243cb63b9..12e9f2cf84e5101 100644
--- a/drivers/iommu/intel/irq_remapping.c
+++ b/drivers/iommu/intel/irq_remapping.c
@@ -74,7 +74,7 @@ struct intel_ir_data {
  * ->iommu->register_lock
  * Note:
  * intel_irq_remap_ops.{supported,prepare,enable,disable,reenable} are called
- * in single-threaded environment with interrupt disabled, so no need to tabke
+ * in single-threaded environment with interrupt disabled, so no need to take
  * the dmar_global_lock.
  */
 DEFINE_RAW_SPINLOCK(irq_2_ir_lock);
-- 
1.8.3

[PATCH 2/8] iommu/omap: Fix spelling mistake "alignement" -> "alignment"

There is a spelling mistake in a comment, fix it.

Signed-off-by: Zhen Lei 
---
 drivers/iommu/omap-iommu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index 71f29c0927fc710..b2a6ab700ec43d1 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -1754,7 +1754,7 @@ static int __init omap_iommu_init(void)
 {
struct kmem_cache *p;
const slab_flags_t flags = SLAB_HWCACHE_ALIGN;
-   size_t align = 1 << 10; /* L2 pagetable alignement */
+   size_t align = 1 << 10; /* L2 pagetable alignment */
struct device_node *np;
int ret;
 
-- 
1.8.3

[PATCH 6/8] iommu/amd: fix a couple of spelling mistakes

There are several spelling mistakes, as follows:
alignement ==> alignment
programing ==> programming
implemtation ==> implementation
assignement ==> assignment

By the way, both "programing" and "programming" are acceptable, but the
latter seems more formal.

Signed-off-by: Zhen Lei 
---
 drivers/iommu/amd/amd_iommu_types.h | 2 +-
 drivers/iommu/amd/init.c| 4 ++--
 drivers/iommu/amd/iommu.c   | 2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/iommu/amd/amd_iommu_types.h 
b/drivers/iommu/amd/amd_iommu_types.h
index 6937e3674a16e26..dc1814c355cff77 100644
--- a/drivers/iommu/amd/amd_iommu_types.h
+++ b/drivers/iommu/amd/amd_iommu_types.h
@@ -446,7 +446,7 @@ struct irq_remap_table {
 /* Interrupt remapping feature used? */
 extern bool amd_iommu_irq_remap;
 
-/* kmem_cache to get tables with 128 byte alignement */
+/* kmem_cache to get tables with 128 byte alignment */
 extern struct kmem_cache *amd_iommu_irq_cache;
 
 /*
diff --git a/drivers/iommu/amd/init.c b/drivers/iommu/amd/init.c
index 321f5906e6ed3a5..48799002b3571d1 100644
--- a/drivers/iommu/amd/init.c
+++ b/drivers/iommu/amd/init.c
@@ -1734,7 +1734,7 @@ static void __init init_iommu_perf_ctr(struct amd_iommu 
*iommu)
goto pc_false;
 
/*
-* Disable power gating by programing the performance counter
+* Disable power gating by programming the performance counter
 * source to 20 (i.e. counts the reads and writes from/to IOMMU
 * Reserved Register [MMIO Offset 1FF8h] that are ignored.),
 * which never get incremented during this init phase.
@@ -2088,7 +2088,7 @@ static int intcapxt_irqdomain_activate(struct irq_domain 
*domain,
xt.destid_24_31 = cfg->dest_apicid >> 24;
 
/**
-* Current IOMMU implemtation uses the same IRQ for all
+* Current IOMMU implementation uses the same IRQ for all
 * 3 IOMMU interrupts.
 */
writeq(xt.capxt, iommu->mmio_base + MMIO_INTCAPXT_EVT_OFFSET);
diff --git a/drivers/iommu/amd/iommu.c b/drivers/iommu/amd/iommu.c
index a69a8b573e40d00..d14e4698f507b89 100644
--- a/drivers/iommu/amd/iommu.c
+++ b/drivers/iommu/amd/iommu.c
@@ -1865,7 +1865,7 @@ int __init amd_iommu_init_dma_ops(void)
  * The following functions belong to the exported interface of AMD IOMMU
  *
  * This interface allows access to lower level functions of the IOMMU
- * like protection domain handling and assignement of devices to domains
+ * like protection domain handling and assignment of devices to domains
  * which is not possible with the dma_ops interface.
  *
  */
-- 
1.8.3

[PATCH 3/8] iommu/mediatek: Fix spelling mistake "phyiscal" -> "physical"

There is a spelling mistake in a comment, fix it.

Signed-off-by: Zhen Lei 
---
 drivers/iommu/mtk_iommu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 6ecc007f07cd52e..c8c9bf1d70b29dc 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -160,7 +160,7 @@ struct mtk_iommu_domain {
  * The Region 'A'(I/O) can NOT be mapped by M4U; For Region 'B'/'C'/'D', the
  * bit32 of the CPU physical address always is needed to set, and for Region
  * 'E', the CPU physical address keep as is.
- * Additionally, The iommu consumers always use the CPU phyiscal address.
+ * Additionally, The iommu consumers always use the CPU physical address.
  */
 #define MTK_IOMMU_4GB_MODE_REMAP_BASE   0x14000UL
 
-- 
1.8.3

[PATCH 5/8] iommu: fix a couple of spelling mistakes

There are several spelling mistakes, as follows:
funcions ==> functions
distiguish ==> distinguish
detroyed ==> destroyed

Signed-off-by: Zhen Lei 
---
 drivers/iommu/iommu.c | 4 ++--
 drivers/iommu/iova.c  | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index d0b0a15dba8413c..0f4e9a6122ee58f 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -1453,7 +1453,7 @@ struct iommu_group *pci_device_group(struct device *dev)
 
/*
 * Look for existing groups on non-isolated functions on the same
-* slot and aliases of those funcions, if any.  No need to clear
+* slot and aliases of those functions, if any.  No need to clear
 * the search bitmap, the tested devfns are still valid.
 */
group = get_pci_function_alias_group(pdev, (unsigned long *)devfns);
@@ -2267,7 +2267,7 @@ struct iommu_domain *iommu_get_dma_domain(struct device 
*dev)
  * iterating over the devices in a group.  Ideally we'd have a single
  * device which represents the requestor ID of the group, but we also
  * allow IOMMU drivers to create policy defined minimum sets, where
- * the physical hardware may be able to distiguish members, but we
+ * the physical hardware may be able to distinguish members, but we
  * wish to group them at a higher level (ex. untrusted multi-function
  * PCI devices).  Thus we attach each device.
  */
diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c
index e6e2fa85271c3f8..bf710b0a3713e21 100644
--- a/drivers/iommu/iova.c
+++ b/drivers/iommu/iova.c
@@ -524,7 +524,7 @@ static void fq_destroy_all_entries(struct iova_domain 
*iovad)
int cpu;
 
/*
-* This code runs when the iova_domain is being detroyed, so don't
+* This code runs when the iova_domain is being destroyed, so don't
 * bother to free iovas, just call the entry_dtor on all remaining
 * entries.
 */
-- 
1.8.3

[PATCH 7/8] iommu/arm-smmu: Fix spelling mistake "initally" -> "initially"

There is a spelling mistake in a comment, fix it.

Signed-off-by: Zhen Lei 
---
 drivers/iommu/arm/arm-smmu/arm-smmu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.c 
b/drivers/iommu/arm/arm-smmu/arm-smmu.c
index d8c6bfde6a61587..8e4e8fea106b612 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu.c
@@ -1358,7 +1358,7 @@ static struct iommu_device *arm_smmu_probe_device(struct 
device *dev)
ret = arm_smmu_register_legacy_master(dev, &smmu);
 
/*
-* If dev->iommu_fwspec is initally NULL, 
arm_smmu_register_legacy_master()
+* If dev->iommu_fwspec is initially NULL, 
arm_smmu_register_legacy_master()
 * will allocate/initialise a new one. Thus we need to update 
fwspec for
 * later use.
 */
-- 
1.8.3

[PATCH 4/8] iommu/sun50i: Fix spelling mistake "consits" -> "consists"

There is a spelling mistake in a comment, fix it.

Signed-off-by: Zhen Lei 
---
 drivers/iommu/sun50i-iommu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iommu/sun50i-iommu.c b/drivers/iommu/sun50i-iommu.c
index ea6db1341916524..7685b96b2d445a7 100644
--- a/drivers/iommu/sun50i-iommu.c
+++ b/drivers/iommu/sun50i-iommu.c
@@ -149,7 +149,7 @@ static void iommu_write(struct sun50i_iommu *iommu, u32 
offset, u32 value)
  * 4096 4-bytes Directory Table Entries (DTE), each pointing to a Page
  * Table (PT).
  *
- * Each PT consits of 256 4-bytes Page Table Entries (PTE), each
+ * Each PT consists of 256 4-bytes Page Table Entries (PTE), each
  * pointing to a 4kB page of physical memory.
  *
  * The IOMMU supports a single DT, pointed by the IOMMU_TTB_REG
-- 
1.8.3

[PATCH 0/8] iommu: fix a couple of spelling mistakes detected by codespell tool

This detection and correction covers the entire driver/iommu directory.

Zhen Lei (8):
  iommu/pamu: fix a couple of spelling mistakes
  iommu/omap: Fix spelling mistake "alignement" -> "alignment"
  iommu/mediatek: Fix spelling mistake "phyiscal" -> "physical"
  iommu/sun50i: Fix spelling mistake "consits" -> "consists"
  iommu: fix a couple of spelling mistakes
  iommu/amd: fix a couple of spelling mistakes
  iommu/arm-smmu: Fix spelling mistake "initally" -> "initially"
  iommu/vt-d: fix a couple of spelling mistakes

 drivers/iommu/amd/amd_iommu_types.h   | 2 +-
 drivers/iommu/amd/init.c  | 4 ++--
 drivers/iommu/amd/iommu.c | 2 +-
 drivers/iommu/arm/arm-smmu/arm-smmu.c | 2 +-
 drivers/iommu/fsl_pamu.c  | 2 +-
 drivers/iommu/fsl_pamu_domain.c   | 2 +-
 drivers/iommu/fsl_pamu_domain.h   | 2 +-
 drivers/iommu/intel/dmar.c| 6 +++---
 drivers/iommu/intel/iommu.c   | 2 +-
 drivers/iommu/intel/irq_remapping.c   | 2 +-
 drivers/iommu/iommu.c | 4 ++--
 drivers/iommu/iova.c  | 2 +-
 drivers/iommu/mtk_iommu.c | 2 +-
 drivers/iommu/omap-iommu.c| 2 +-
 drivers/iommu/sun50i-iommu.c  | 2 +-
 15 files changed, 19 insertions(+), 19 deletions(-)

-- 
1.8.3

[PATCH 1/8] iommu/pamu: fix a couple of spelling mistakes

There are several spelling mistakes, as follows:
Returs  ==> Returns
defaul ==> default
assocaited ==> associated

Signed-off-by: Zhen Lei 
---
 drivers/iommu/fsl_pamu.c| 2 +-
 drivers/iommu/fsl_pamu_domain.c | 2 +-
 drivers/iommu/fsl_pamu_domain.h | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/iommu/fsl_pamu.c b/drivers/iommu/fsl_pamu.c
index b9a974d9783113d..48ebbf0daa21cf9 100644
--- a/drivers/iommu/fsl_pamu.c
+++ b/drivers/iommu/fsl_pamu.c
@@ -503,7 +503,7 @@ void get_ome_index(u32 *omi_index, struct device *dev)
  * @stash_dest_hint: L1, L2 or L3
  * @vcpu: vpcu target for a particular cache type.
  *
- * Returs stash on success or ~(u32)0 on failure.
+ * Returns stash on success or ~(u32)0 on failure.
  *
  */
 u32 get_stash_id(u32 stash_dest_hint, u32 vcpu)
diff --git a/drivers/iommu/fsl_pamu_domain.c b/drivers/iommu/fsl_pamu_domain.c
index b2110767caf49c8..be664cd18c51970 100644
--- a/drivers/iommu/fsl_pamu_domain.c
+++ b/drivers/iommu/fsl_pamu_domain.c
@@ -418,7 +418,7 @@ static struct iommu_domain *fsl_pamu_domain_alloc(unsigned 
type)
pr_debug("dma_domain allocation failed\n");
return NULL;
}
-   /* defaul geometry 64 GB i.e. maximum system address */
+   /* default geometry 64 GB i.e. maximum system address */
dma_domain->iommu_domain. geometry.aperture_start = 0;
dma_domain->iommu_domain.geometry.aperture_end = (1ULL << 36) - 1;
dma_domain->iommu_domain.geometry.force_aperture = true;
diff --git a/drivers/iommu/fsl_pamu_domain.h b/drivers/iommu/fsl_pamu_domain.h
index 2865d42782e8021..4f508fa041080e3 100644
--- a/drivers/iommu/fsl_pamu_domain.h
+++ b/drivers/iommu/fsl_pamu_domain.h
@@ -24,7 +24,7 @@ struct fsl_dma_domain {
 */
dma_addr_t  geom_size;
/*
-* Number of windows assocaited with this domain.
+* Number of windows associated with this domain.
 * During domain initialization, it is set to the
 * the maximum number of subwindows allowed for a LIODN.
 * Minimum value for this is 1 indicating a single PAMU
-- 
1.8.3

Re: [PATCH] clk: bcm: rpi: Don't register as OF provider if !dev->np

2021-03-25 Thread Marek Szyprowski

On 25.03.2021 19:57, Nicolas Saenz Julienne wrote:
> There are two ways clk-raspberrypi might be registered: through
> device-tree or through an explicit platform device registration. The
> latter happens after firmware/raspberrypi's probe, and it's limited to
> RPi3s, which solely use the ARM clock to scale CPU's frequency. That
> clock is matched with cpu0's device thanks to the ARM clock being
> registered as a clkdev.
>
> In that scenario, don't register the device as an OF clock provider, as
> it makes no sense and will cause trouble.
>
> Fixes: d4b4f1b6b97e ("clk: bcm: rpi: Add DT provider for the clocks")
> Reported-by: Marek Szyprowski 
> Signed-off-by: Nicolas Saenz Julienne 
Tested-by: Marek Szyprowski 
> ---
>   drivers/clk/bcm/clk-raspberrypi.c | 10 ++
>   1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/clk/bcm/clk-raspberrypi.c 
> b/drivers/clk/bcm/clk-raspberrypi.c
> index f89b9cfc4309..27e85687326f 100644
> --- a/drivers/clk/bcm/clk-raspberrypi.c
> +++ b/drivers/clk/bcm/clk-raspberrypi.c
> @@ -337,10 +337,12 @@ static int raspberrypi_clk_probe(struct platform_device 
> *pdev)
>   if (ret)
>   return ret;
>   
> - ret = devm_of_clk_add_hw_provider(dev, of_clk_hw_onecell_get,
> -   clk_data);
> - if (ret)
> - return ret;
> + if (dev->of_node) {
> + ret = devm_of_clk_add_hw_provider(dev, of_clk_hw_onecell_get,
> +   clk_data);
> + if (ret)
> + return ret;
> + }
>   
>   rpi->cpufreq = platform_device_register_data(dev, "raspberrypi-cpufreq",
>-1, NULL, 0);

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland

Re: [RFT PATCH v3 13/27] arm64: Add Apple vendor-specific system registers

2021-03-25 Thread Hector Martin


On 25/03/2021 04.04, Will Deacon wrote:

On Wed, Mar 24, 2021 at 06:59:21PM +, Mark Rutland wrote:

So far we've kept arch/arm64/ largely devoid of IMP-DEF bits, and it
seems a shame to add something with the sole purpose of collating that,
especially given arch code shouldn't need to touch these if FW and
bootloader have done their jobs right.

Can we put the definitions in the relevant drivers? That would sidestep
any pain with MAINTAINERS, too.


If we can genuinely ignore these in arch code, then sure. I just don't know
how long that is going to be the case, and ending up in a situation where
these are scattered randomly throughout the tree sounds horrible to me.


I thought we would need some in KVM code, but given the direction Marc's 
series ended up in, it seems we won't. So I'm happy keeping these in the 
respective drivers; if this ends up being messy in the future it 
shouldn't be a big deal to refactor it all into one file again.


--
Hector Martin (mar...@marcan.st)
Public Key: https://mrcn.st/pub

Re: [Ksummit-discuss] [1/5] reporting-issues: header and TLDR

2021-03-25 Thread Guenter Roeck

On 3/25/21 11:15 PM, Thorsten Leemhuis wrote:
> On 26.03.21 07:13, Thorsten Leemhuis wrote:
>>

> mention if backporting is planed or considered too complex. If backporting was

planned

Re: [RFC] mm: activate access-more-than-once page via NUMA balancing

2021-03-25 Thread Huang, Ying

Mel Gorman  writes:

> On Thu, Mar 25, 2021 at 12:33:45PM +0800, Huang, Ying wrote:
>> > I caution against this patch.
>> >
>> > It's non-deterministic for a number of reasons. As it requires NUMA
>> > balancing to be enabled, the pageout behaviour of a system changes when
>> > NUMA balancing is active. If this led to pages being artificially and
>> > inappropriately preserved, NUMA balancing could be disabled for the
>> > wrong reasons.  It only applies to pages that have no target node so
>> > memory policies affect which pages are activated differently. Similarly,
>> > NUMA balancing does not scan all VMAs and some pages may never trap a
>> > NUMA fault as a result. The timing of when an address space gets scanned
>> > is driven by the locality of pages and so the timing of page activation
>> > potentially becomes linked to whether pages are local or need to migrate
>> > (although not right now for this patch as it only affects pages with a
>> > target nid of NUMA_NO_NODE). In other words, changes in NUMA balancing
>> > that affect migration potentially affect the aging rate.  Similarly,
>> > the activate rate of a process with a single thread and multiple threads
>> > potentially have different activation rates.
>> >
>> > Finally, the NUMA balancing scan algorithm is sub-optimal. It potentially
>> > scans the entire address space even though only a small number of pages
>> > are scanned. This is particularly problematic when a process has a lot
>> > of threads because threads are redundantly scanning the same regions. If
>> > NUMA balancing ever introduced range tracking of faulted pages to limit
>> > how much scanning it has to do, it would inadvertently cause a change in
>> > page activation rate.
>> >
>> > NUMA balancing is about page locality, it should not get conflated with
>> > page aging.
>> 
>> I understand your concerns about binding the NUMA balancing and page
>> reclaiming.  The requirement of the page locality and page aging is
>> different, so the policies need to be different.  This is the wrong part
>> of the patch.
>> 
>> From another point of view, it's still possible to share some underlying
>> mechanisms (and code) between them.  That is, scanning the page tables
>> to make pages unaccessible and capture the page accesses via the page
>> fault. 
>
> Potentially yes but not necessarily recommended for page aging. NUMA
> balancing has to be careful about the rate it scans pages to avoid
> excessive overhead so it's driven by locality. The scanning happens
> within a tasks context so during that time, the task is not executing
> its normal work and it incurs the overhead for faults. Generally, this
> is not too much overhead because pages get migrated locally, the scan
> rate drops and so does the overhead.
>
> However, if you want to drive page aging, that is constant so the rate
> could not be easily adapted in a way that would be deterministic.
>
>> Now these page accessing information is used for the page
>> locality.  Do you think it's a good idea to use these information for
>> the page aging too (but with a different policy as you pointed out)?
>> 
>
> I'm not completely opposed to it but I think the overhead it would
> introduce could be severe. Worse, if a workload fits in memory and there
> is limited to no memory pressure, it's all overhead for no gain. Early
> generations of NUMA balancing had to find a balance to sure the gains
> from locality exceeded the cost of measuring locality and doing the same
> for page aging in some ways is even more challenging.

Yes.  I will think more about it from the overhead vs. gain point of
view.  Thanks a lot for your sharing on that.

>> From yet another point of view :-), in current NUMA balancing
>> implementation, it's assumed that the node private pages can fit in the
>> accessing node.  But this may be not always true.  Is it a valid
>> optimization to migrate the hot private pages first?
>> 
>
> I'm not sure how the hotness of pages could be ranked. At the time of a
> hinting fault, the page is by definition active now because it was been
> accessed. Prioritising what pages to migrate based on the number of faults
> that have been trapped would have to be stored somewhere.

Yes.  We need to store some information about that.  In an old version
of the patchset which uses NUMA balancing to promote hot pages from the
PMEM to DRAM, we have designed a method to measure the hotness of the
pages.  The basic idea is as follows,

- When the page table of a process is scanned, the latest N scanning
  address ranges and scan times are recorded in a ring buffer of
  mm_struct.

- In hint page fault handler, the ring buffer is search with the fault
  address, to get the scan time.

Then the hint page fault latency of the page is defined as,

  hint page fault latency = fault time - scan time

The shorter the hint page fault latency, the hotter the page.

Then we need a way to determine the hot/cold threshold.  We used a rate
limit based thresh

[5/5] reporting-issues: addendum

On 26.03.21 07:13, Thorsten Leemhuis wrote:
> 
> Lo! Since a few months mainline in
> Documentation/admin-guide/reporting-issues.rst contains a text written
> to obsolete the good old reporting-bugs text. For now, the new document
> still contains a warning at the top that basically says "this is WIP".
> But I'd like to remove that warning and delete reporting-bugs.rst in the
> next merge window to make reporting-issues.rst fully official. With this
> mail I want to give everyone a chance to take a look at the text and
> speak up if you don't want me to move ahead for now.
> 
> For easier review I'll post the text of reporting-issues.rst in reply to
> this mail. I'll do that in a few chunks, as if this was a cover letter
> for a patch-set. 

Why some issues won't get any reaction or remain unfixed after being reported

=

When reporting a problem to the Linux developers, be aware only 'issues of high

priority' (regressions, security issues, severe problems) are definitely going

to get resolved. The maintainers or if all else fails Linus Torvalds himself

will make sure of that. They and the other kernel developers will fix a lot of

other issues as well. But be aware that sometimes they can't or won't help; and

sometimes there isn't even anyone to send a report to.

This is best explained with kernel developers that contribute to the Linux

kernel in their spare time. Quite a few of the drivers in the kernel were

written by such programmers, often because they simply wanted to make their

hardware usable on their favorite operating system.

These programmers most of the time will happily fix problems other people

report. But nobody can force them to do, as they are contributing voluntarily.

Then there are situations where such developers really want to fix an issue,

but can't: sometimes they lack hardware programming documentation to do so.

This often happens when the publicly available docs are superficial or the

driver was written with the help of reverse engineering.

Sooner or later spare time developers will also stop caring for the driver.

Maybe their test hardware broke, got replaced by something more fancy, or is so

old that it's something you don't find much outside of computer museums

anymore. Sometimes developer stops caring for their code and Linux at all, as

something different in their life became way more important. In some cases

nobody is willing to take over the job as maintainer – and nobody can be forced

to, as contributing to the Linux kernel is done on a voluntary basis. Abandoned

drivers nevertheless remain in the kernel: they are still useful for people and

removing would be a regression.

The situation is not that different with developers that are paid for their

work on the Linux kernel. Those contribute most changes these days. But their

employers sooner or later also stop caring for their code or make its

programmer focus on other things. Hardware vendors for example earn their money

mainly by selling new hardware; quite a few of them hence are not investing

much time and energy in maintaining a Linux kernel driver for something they

stopped selling years ago. Enterprise Linux distributors often care for a

longer time period, but in new versions often leave support for old and rare

hardware aside to limit the scope. Often spare time contributors take over once

a company orphans some code, but as mentioned above: sooner or later they will

leave the code behind, too.

Priorities are another reason why some issues are not fixed, as maintainers

quite often are forced to set those, as time to work on Linux is limited.

That's true for spare time or the time employers grant their developers to

spend on maintenance work on the upstream kernel. Sometimes maintainers also

get overwhelmed with reports, even if a driver is working nearly perfectly. To

not get completely stuck, the programmer thus might have no other choice than

to prioritize issue reports and reject some of them.

But don't worry too much about all of this, a lot of drivers have active

maintainers who are quite interested in fixing as many issues as possible.

Closing words

=

Compared with other Free/Libre & Open Source Software it's hard to report

issues to the Linux kernel developers: the length and complexity of this

document and the implications between the lines illustrate that. But that's how

it is for now. The main author of this text hopes documenting the state of the

art will lay some groundwork to improve the situation over time.

[4/5] reporting-issues: reference section, stable and longterm sub-processes

On 26.03.21 07:13, Thorsten Leemhuis wrote:
> Lo! Since a few months mainline in
> Documentation/admin-guide/reporting-issues.rst contains a text written
> to obsolete the good old reporting-bugs text. For now, the new document
> still contains a warning at the top that basically says "this is WIP".
> But I'd like to remove that warning and delete reporting-bugs.rst in the
> next merge window to make reporting-issues.rst fully official. With this
> mail I want to give everyone a chance to take a look at the text and
> speak up if you don't want me to move ahead for now.
> 
> For easier review I'll post the text of reporting-issues.rst in reply to
> this mail. I'll do that in a few chunks, as if this was a cover letter
> for a patch-set. 

Reference for "Reporting issues only occurring in older kernel version lines"

-

This subsection provides details for step you need to perform if you face a

regression within a stable and longterm kernel line.

Make sure the particular version line still gets support

*Check if the kernel developers still maintain the Linux kernel version

line you care about: go to the front page of kernel.org and make sure it

mentions the latest release of the particular version line without an

'[EOL]' tag.*

Most kernel version lines only get supported for about three months, as

maintaining them longer is quite a lot of work. Hence, only one per year is

chosen and gets supported for at least two years (often six). That's why you

need to check if the kernel developers still support the version line you care

for.

Note, if kernel.org lists two 'stable' version lines on the front page, you

should consider switching to the newer one and forget about the older one:

support for it is likely to be abandoned soon. Then it will get a "end-of-life"

(EOL) stamp. Version lines that reached that point still get mentioned on the

kernel.org front page for a week or two, but are unsuitable for testing and

reporting.

Search stable mailing list

~~

*Check the archives of the Linux stable mailing list for existing reports.*

Maybe the issue you face is already known and was fixed or is about to. Hence,

`search the archives of the Linux stable mailing list

`_ for reports about an issue like yours. If

you find any matches, consider joining the discussion, unless the fix is

already finished and scheduled to get applied soon.

Reproduce issue with the newest release

~~~

*Install the latest release from the particular version line as a vanilla

kernel. Ensure this kernel is not tainted and still shows the problem, as

the issue might have already been fixed there.*

Before investing any more time in this process you want to check if the issue

was already fixed in the latest release of version line you're interested in.

This kernel needs to be vanilla and shouldn't be tainted before the issue

happens, as detailed outlined already above in the section "Install a fresh

kernel for testing".

Report the regression

~

*Send a short problem report by mail to the people and mailing lists the

:ref:`MAINTAINERS ` file specifies in the section 'STABLE

BRANCH'. Roughly describe the issue and ideally explain how to reproduce

it. Mention the first version that shows the problem and the last version

that's working fine. Then wait for further instructions.*

When reporting a regression that happens within a stable or longterm kernel

line (say when updating from 5.10.4 to 5.10.5) a brief report is enough for

the start to get the issue reported quickly. Hence a rough description is all

it takes.

But note, it helps developers a great deal if you can specify the exact version

that introduced the problem. Hence if possible within a reasonable time frame,

try to find that version using vanilla kernels. Lets assume something broke when

your distributor released a update from Linux kernel 5.10.5 to 5.10.8. Then as

instructed above go and check the latest kernel from that version line, say

5.10.9. If it shows the problem, try a vanilla 5.10.5 to ensure that no patches

the distributor applied interfere. If the issue doesn't manifest itself there,

try 5.10.7 and then (depending on the outcome) 5.10.8 or 5.10.6 to find the

first version where things broke. Mention it in the report and state that 5.10.9

is still broken.

What the previous paragraph outlines is basically a rough manual 'bisection'.

Once your report is out your might get asked to do a proper one, as it allows to

pinpoint the exact change that causes the issue (which then can easily get

reverted to fix the issue quickly). Hence consider to do a proper bisection

right away if time permits. See the secti

[PATCH] pkcs7: Use octal permissions '0444'

2021-03-25 Thread Meng Yu

Fixed following checkpatch warning:
Symbolic permissions 'S_IWUSR | S_IRUGO' are not preferred. Consider
using octal permissions '0644'.

Signed-off-by: Meng Yu 
---
 crypto/asymmetric_keys/pkcs7_key_type.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/crypto/asymmetric_keys/pkcs7_key_type.c 
b/crypto/asymmetric_keys/pkcs7_key_type.c
index b930d3b..55a5be7 100644
--- a/crypto/asymmetric_keys/pkcs7_key_type.c
+++ b/crypto/asymmetric_keys/pkcs7_key_type.c
@@ -18,7 +18,7 @@ MODULE_DESCRIPTION("PKCS#7 testing key type");
 MODULE_AUTHOR("Red Hat, Inc.");
 
 static unsigned pkcs7_usage;
-module_param_named(usage, pkcs7_usage, uint, S_IWUSR | S_IRUGO);
+module_param_named(usage, pkcs7_usage, uint, 0644);
 MODULE_PARM_DESC(pkcs7_usage,
 "Usage to specify when verifying the PKCS#7 message");
 
-- 
2.8.1

Re: [PATCH v2 6/7] cmdline: Gives architectures opportunity to use generically defined boot cmdline manipulation

2021-03-25 Thread Christophe Leroy





Le 25/03/2021 à 20:32, Will Deacon a écrit :

On Thu, Mar 25, 2021 at 12:18:38PM +0100, Christophe Leroy wrote:


- For ARM it means to append the bootloader arguments to the CONFIG_CMDLINE
- For Powerpc it means to append the CONFIG_CMDLINE to the bootloader arguments
- For SH  it means to append the CONFIG_CMDLINE to the bootloader arguments
- For EFI it means to append the bootloader arguments to the CONFIG_CMDLINE
- For OF it means to append the CONFIG_CMDLINE to the bootloader arguments

So what happens on ARM for instance when it selects CONFIG_OF for instance ?


I think ARM gets different behaviour depending on whether it uses ATAGs or
FDT.


As far as I can see, ARM uses either ATAGs only or both ATAGs and FDT. ATAGs is forced to 'y' when 
USE_OF is set. Do I miss something ?





Or should we consider that EXTEND means APPEND or PREPEND, no matter which ?
Because EXTEND is for instance used for:

config INITRAMFS_FORCE
bool "Ignore the initramfs passed by the bootloader"
depends on CMDLINE_EXTEND || CMDLINE_FORCE


Oh man, I didn't spot that one :(

I think I would make the generic options explicit: either APPEND or PREPEND.
Then architectures which choose to define CMDLINE_EXTEND in their Kconfigs
can select the generic option that matches their behaviour.

INITRAMFS_FORCE sounds like it should depend on APPEND (assuming that means
CONFIG_CMDLINE is appended to the bootloader arguments).




Christophe

[3/5] reporting-issues: reference section, main guide

On 26.03.21 07:13, Thorsten Leemhuis wrote:
> 
> Lo! Since a few months mainline in
> Documentation/admin-guide/reporting-issues.rst contains a text written
> to obsolete the good old reporting-bugs text. For now, the new document
> still contains a warning at the top that basically says "this is WIP".
> But I'd like to remove that warning and delete reporting-bugs.rst in the
> next merge window to make reporting-issues.rst fully official. With this
> mail I want to give everyone a chance to take a look at the text and
> speak up if you don't want me to move ahead for now.
> 
> For easier review I'll post the text of reporting-issues.rst in reply to
> this mail. I'll do that in a few chunks, as if this was a cover letter
> for a patch-set. 

Reference section: Reporting issues to the kernel maintainers

=

The detailed guides above outline all the major steps in brief fashion, which

should be enough for most people. But sometimes there are situations where even

experienced users might wonder how to actually do one of those steps. That's

what this section is for, as it will provide a lot more details on each of the

above steps. Consider this as reference documentation: it's possible to read it

from top to bottom. But it's mainly meant to skim over and a place to look up

details how to actually perform those steps.

A few words of general advice before digging into the details:

 * The Linux kernel developers are well aware this process is complicated and

   demands more than other FLOSS projects. We'd love to make it simpler. But

   that would require work in various places as well as some infrastructure,

   which would need constant maintenance; nobody has stepped up to do that

   work, so that's just how things are for now.

 * A warranty or support contract with some vendor doesn't entitle you to

   request fixes from developers in the upstream Linux kernel community: such

   contracts are completely outside the scope of the Linux kernel, its

   development community, and this document. That's why you can't demand

   anything such a contract guarantees in this context, not even if the

   developer handling the issue works for the vendor in question. If you want

   to claim your rights, use the vendor's support channel instead. When doing

   so, you might want to mention you'd like to see the issue fixed in the

   upstream Linux kernel; motivate them by saying it's the only way to ensure

   the fix in the end will get incorporated in all Linux distributions.

 * If you never reported an issue to a FLOSS project before you should consider

   reading `How to Report Bugs Effectively

   `_, `How To Ask

   Questions The Smart Way

   `_, and `How to ask good

   questions `_.

With that off the table, find below the details on how to properly report

issues to the Linux kernel developers.

Make sure you're using the upstream Linux kernel

   *Are you facing an issue with a Linux kernel a hardware or software vendor

   provided? Then in almost all cases you are better off to stop reading this

   document and reporting the issue to your vendor instead, unless you are

   willing to install the latest Linux version yourself. Be aware the latter

   will often be needed anyway to hunt down and fix issues.*

Like most programmers, Linux kernel developers don't like to spend time dealing

with reports for issues that don't even happen with their current code. It's

just a waste everybody's time, especially yours. Unfortunately such situations

easily happen when it comes to the kernel and often leads to frustration on both

sides. That's because almost all Linux-based kernels pre-installed on devices

(Computers, Laptops, Smartphones, Routers, …) and most shipped by Linux

distributors are quite distant from the official Linux kernel as distributed by

kernel.org: these kernels from these vendors are often ancient from the point of

Linux development or heavily modified, often both.

Most of these vendor kernels are quite unsuitable for reporting bugs to the

Linux kernel developers: an issue you face with one of them might have been

fixed by the Linux kernel developers months or years ago already; additionally,

the modifications and enhancements by the vendor might be causing the issue you

face, even if they look small or totally unrelated. That's why you should report

issues with these kernels to the vendor. Its developers should look into the

report and, in case it turns out to be an upstream issue, fix it directly

upstream or forward the report there. In practice that often does not work out

or might not what you want. You thus might want to consider circumventing the

vendor by installing the very latest Linu

[tip:irq/core] BUILD SUCCESS 6e457914935a3161eeb74e319abf9fd511aa1e4d

xtensa   allyesconfig
h8300allyesconfig
arc defconfig
sh   allmodconfig
parisc  defconfig
s390 allyesconfig
s390 allmodconfig
parisc   allyesconfig
s390defconfig
sparcallyesconfig
sparc   defconfig
i386   tinyconfig
i386defconfig
mips allyesconfig
mips allmodconfig
powerpc  allyesconfig
powerpc  allmodconfig
powerpc   allnoconfig
x86_64   randconfig-a002-20210325
x86_64   randconfig-a003-20210325
x86_64   randconfig-a006-20210325
x86_64   randconfig-a001-20210325
x86_64   randconfig-a005-20210325
x86_64   randconfig-a004-20210325
i386 randconfig-a003-20210325
i386 randconfig-a004-20210325
i386 randconfig-a001-20210325
i386 randconfig-a002-20210325
i386 randconfig-a006-20210325
i386 randconfig-a005-20210325
i386 randconfig-a014-20210325
i386 randconfig-a011-20210325
i386 randconfig-a015-20210325
i386 randconfig-a016-20210325
i386 randconfig-a013-20210325
i386 randconfig-a012-20210325
riscvnommu_virt_defconfig
riscv allnoconfig
riscv   defconfig
riscv  rv32_defconfig
um   allmodconfig
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-a012-20210325
x86_64   randconfig-a015-20210325
x86_64   randconfig-a014-20210325
x86_64   randconfig-a013-20210325
x86_64   randconfig-a011-20210325
x86_64   randconfig-a016-20210325

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org

[2/5] reporting-issues: step-by-step-guide: main and two sub-processes for stable/longterm

On 26.03.21 07:13, Thorsten Leemhuis wrote:
> Lo! Since a few months mainline in
> Documentation/admin-guide/reporting-issues.rst contains a text written
> to obsolete the good old reporting-bugs text. For now, the new document
> still contains a warning at the top that basically says "this is WIP".
> But I'd like to remove that warning and delete reporting-bugs.rst in the
> next merge window to make reporting-issues.rst fully official. With this
> mail I want to give everyone a chance to take a look at the text and
> speak up if you don't want me to move ahead for now.
> 
> For easier review I'll post the text of reporting-issues.rst in reply to
> this mail. I'll do that in a few chunks, as if this was a cover letter
> for a patch-set. 

Step-by-step guide how to report issues to the kernel maintainers

=

The above TL;DR outlines roughly how to report issues to the Linux kernel

developers. It might be all that's needed for people already familiar with

reporting issues to Free/Libre & Open Source Software (FLOSS) projects. For

everyone else there is this section. It is more detailed and uses a

step-by-step approach. It still tries to be brief for readability and leaves

out a lot of details; those are described below the step-by-step guide in a

reference section, which explains each of the steps in more detail.

Note: this section covers a few more aspects than the TL;DR and does things in

a slightly different order. That's in your interest, to make sure you notice

early if an issue that looks like a Linux kernel problem is actually caused by

something else. These steps thus help to ensure the time you invest in this

process won't feel wasted in the end:

 * Are you facing an issue with a Linux kernel a hardware or software vendor

   provided? Then in almost all cases you are better off to stop reading this

   document and reporting the issue to your vendor instead, unless you are

   willing to install the latest Linux version yourself. Be aware the latter

   will often be needed anyway to hunt down and fix issues.

 * Perform a rough search for existing reports with your favorite internet

   search engine; additionally, check the archives of the Linux Kernel Mailing

   List (LKML). If you find matching reports, join the discussion instead of

   sending a new one.

 * See if the issue you are dealing with qualifies as regression, security

   issue, or a really severe problem: those are 'issues of high priority' that

   need special handling in some steps that are about to follow.

 * Make sure it's not the kernel's surroundings that are causing the issue

   you face.

 * Create a fresh backup and put system repair and restore tools at hand.

 * Ensure your system does not enhance its kernels by building additional

   kernel modules on-the-fly, which solutions like DKMS might be doing locally

   without your knowledge.

 * Check if your kernel was 'tainted' when the issue occurred, as the event

   that made the kernel set this flag might be causing the issue you face.

 * Write down coarsely how to reproduce the issue. If you deal with multiple

   issues at once, create separate notes for each of them and make sure they

   work independently on a freshly booted system. That's needed, as each issue

   needs to get reported to the kernel developers separately, unless they are

   strongly entangled.

 * If you are facing a regression within a stable or longterm version line

   (say something broke when updating from 5.10.4 to 5.10.5), scroll down to

   'Dealing with regressions within a stable and longterm kernel line'.

 * Locate the driver or kernel subsystem that seems to be causing the issue.

   Find out how and where its developers expect reports. Note: most of the

   time this won't be bugzilla.kernel.org, as issues typically need to be sent

   by mail to a maintainer and a public mailing list.

 * Search the archives of the bug tracker or mailing list in question

   thoroughly for reports that might match your issue. If you find anything,

   join the discussion instead of sending a new report.

After these preparations you'll now enter the main part:

 * Unless you are already running the latest 'mainline' Linux kernel, better

   go and install it for the reporting process. Testing and reporting with

   the latest 'stable' Linux can be an acceptable alternative in some

   situations; during the merge window that actually might be even the best

   approach, but in that development phase it can be an even better idea to

   suspend your efforts for a few days anyway. Whatever version you choose,

   ideally use a 'vanilla' build. Ignoring these advices will dramatically

   increase the risk your report will be rejected or ignored.

 * Ensure the kernel you just installed does not 'taint' itself when

   running.

 * Reproduce the issue with the kernel you just installed

[PATCH] crypto: hisilicon/hpre - rsa key should not be empty

2021-03-25 Thread Meng Yu

We should ensure key is not empty before we set key.

Signed-off-by: Meng Yu 
---
 drivers/crypto/hisilicon/hpre/hpre_crypto.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/crypto/hisilicon/hpre/hpre_crypto.c 
b/drivers/crypto/hisilicon/hpre/hpre_crypto.c
index 53068d2..7cf7d80 100644
--- a/drivers/crypto/hisilicon/hpre/hpre_crypto.c
+++ b/drivers/crypto/hisilicon/hpre/hpre_crypto.c
@@ -1093,6 +1093,9 @@ static int hpre_rsa_setpubkey(struct crypto_akcipher 
*tfm, const void *key,
struct hpre_ctx *ctx = akcipher_tfm_ctx(tfm);
int ret;
 
+   if (!key || !keylen)
+   return -EINVAL;
+
ret = crypto_akcipher_set_pub_key(ctx->rsa.soft_tfm, key, keylen);
if (ret)
return ret;
@@ -1106,6 +1109,9 @@ static int hpre_rsa_setprivkey(struct crypto_akcipher 
*tfm, const void *key,
struct hpre_ctx *ctx = akcipher_tfm_ctx(tfm);
int ret;
 
+   if (!key || !keylen)
+   return -EINVAL;
+
ret = crypto_akcipher_set_priv_key(ctx->rsa.soft_tfm, key, keylen);
if (ret)
return ret;
-- 
2.8.1

[1/5] reporting-issues: header and TLDR

On 26.03.21 07:13, Thorsten Leemhuis wrote:
> 
> Lo! Since a few months mainline in
> Documentation/admin-guide/reporting-issues.rst contains a text written
> to obsolete the good old reporting-bugs text. For now, the new document
> still contains a warning at the top that basically says "this is WIP".
> But I'd like to remove that warning and delete reporting-bugs.rst in the
> next merge window to make reporting-issues.rst fully official. With this
> mail I want to give everyone a chance to take a look at the text and
> speak up if you don't want me to move ahead for now.
> 
> For easier review I'll post the text of reporting-issues.rst in reply to
> this mail. I'll do that in a few chunks, as if this was a cover letter
> for a patch-set. 

Here we go:

.. SPDX-License-Identifier: (GPL-2.0+ OR CC-BY-4.0)

..

   If you want to distribute this text under CC-BY-4.0 only, please use 'The

   Linux kernel developers' for author attribution and link this as source:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/Documentation/admin-guide/reporting-issues.rst

..

   Note: Only the content of this RST file as found in the Linux kernel sources

   is available under CC-BY-4.0, as versions of this text that were processed

   (for example by the kernel's build system) might contain content taken from

   files which use a more restrictive license.

Reporting issues

The short guide (aka TL;DR)

===

If you're facing multiple issues with the Linux kernel at once, report each

separately to its developers. Try your best guess which kernel part might be

causing the issue. Check the :ref:`MAINTAINERS ` file for how its

developers expect to be told about issues. Note, it's rarely

`bugzilla.kernel.org `_, as in almost all cases

the report needs to be sent by email!

Check the destination thoroughly for existing reports; also search the LKML

archives and the web. Join existing discussion if you find matches. If you

don't find any, install `the latest Linux mainline kernel

`_. Make sure it's vanilla, thus is not patched or using

add-on kernel modules. Also ensure the kernel is running in a healthy

environment and is not already tainted before the issue occurs.

If you can reproduce your issue with the mainline kernel, send a report to the

destination you determined earlier. Make sure it includes all relevant

information, which in case of a regression should mention the change that's

causing it which can often can be found with a bisection. Also ensure the

report reaches all people that need to know about it, for example the security

team, the stable maintainers or the developers of the patch that causes a

regression. Once the report is out, answer any questions that might be raised

and help where you can. That includes keeping the ball rolling: every time a

new rc1 mainline kernel is released, check if the issue is still happening

there and attach a status update to your initial report.

If you can not reproduce the issue with the mainline kernel, consider sticking

with it; if you'd like to use an older version line and want to see it fixed

there, first make sure it's still supported. Install its latest release as

vanilla kernel. If you cannot reproduce the issue there, try to find the commit

that fixed it in mainline or any discussion preceding it: those will often

mention if backporting is planed or considered too complex. If backporting was

not discussed, ask if it's in the cards. In case you don't find any commits or

a preceding discussion, see the Linux-stable mailing list archives for existing

reports, as it might be a regression specific to the version line. If it is,

report it like you would report a problem in mainline (including the

bisection).

If you reached this point without a solution, ask for advice one the

subsystem's mailing list.

[PATCH 2/2] powerpc/powernv: remove the nvlink support

2021-03-25 Thread Christoph Hellwig

This code was only used by the vfio-nvlink2 code, which itself had no
proper use.  Drop this huge chunk of code build into every powernv
or generic build.

Signed-off-by: Christoph Hellwig 
Acked-by: Greg Kroah-Hartman 
---
 arch/powerpc/include/asm/opal.h|   3 -
 arch/powerpc/include/asm/pci-bridge.h  |   1 -
 arch/powerpc/include/asm/pci.h |   7 -
 arch/powerpc/platforms/powernv/Makefile|   2 +-
 arch/powerpc/platforms/powernv/npu-dma.c   | 705 -
 arch/powerpc/platforms/powernv/opal-call.c |   2 -
 arch/powerpc/platforms/powernv/pci-ioda.c  | 185 +-
 arch/powerpc/platforms/powernv/pci.c   |  11 -
 arch/powerpc/platforms/powernv/pci.h   |  17 +-
 arch/powerpc/platforms/pseries/pci.c   |  23 -
 10 files changed, 8 insertions(+), 948 deletions(-)
 delete mode 100644 arch/powerpc/platforms/powernv/npu-dma.c

diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index 9986ac34b8e224..06eaa231697344 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -28,9 +28,6 @@ extern struct device_node *opal_node;
 
 /* API functions */
 int64_t opal_invalid_call(void);
-int64_t opal_npu_destroy_context(uint64_t phb_id, uint64_t pid, uint64_t bdf);
-int64_t opal_npu_init_context(uint64_t phb_id, int pasid, uint64_t msr,
-   uint64_t bdf);
 int64_t opal_npu_map_lpar(uint64_t phb_id, uint64_t bdf, uint64_t lparid,
uint64_t lpcr);
 int64_t opal_npu_spa_setup(uint64_t phb_id, uint32_t bdfn,
diff --git a/arch/powerpc/include/asm/pci-bridge.h 
b/arch/powerpc/include/asm/pci-bridge.h
index d2a2a14e56f91e..74424c14515ce0 100644
--- a/arch/powerpc/include/asm/pci-bridge.h
+++ b/arch/powerpc/include/asm/pci-bridge.h
@@ -126,7 +126,6 @@ struct pci_controller {
 #endif /* CONFIG_PPC64 */
 
void *private_data;
-   struct npu *npu;
 };
 
 /* These are used for config access before all the PCI probing
diff --git a/arch/powerpc/include/asm/pci.h b/arch/powerpc/include/asm/pci.h
index 6436f0b41539e3..d1f53260725ca7 100644
--- a/arch/powerpc/include/asm/pci.h
+++ b/arch/powerpc/include/asm/pci.h
@@ -119,11 +119,4 @@ extern void pcibios_scan_phb(struct pci_controller *hose);
 
 #endif /* __KERNEL__ */
 
-extern struct pci_dev *pnv_pci_get_gpu_dev(struct pci_dev *npdev);
-extern struct pci_dev *pnv_pci_get_npu_dev(struct pci_dev *gpdev, int index);
-extern int pnv_npu2_init(struct pci_controller *hose);
-extern int pnv_npu2_map_lpar_dev(struct pci_dev *gpdev, unsigned int lparid,
-   unsigned long msr);
-extern int pnv_npu2_unmap_lpar_dev(struct pci_dev *gpdev);
-
 #endif /* __ASM_POWERPC_PCI_H */
diff --git a/arch/powerpc/platforms/powernv/Makefile 
b/arch/powerpc/platforms/powernv/Makefile
index 2eb6ae150d1fd5..be2546b968165e 100644
--- a/arch/powerpc/platforms/powernv/Makefile
+++ b/arch/powerpc/platforms/powernv/Makefile
@@ -10,7 +10,7 @@ obj-$(CONFIG_SMP) += smp.o subcore.o subcore-asm.o
 obj-$(CONFIG_FA_DUMP)  += opal-fadump.o
 obj-$(CONFIG_PRESERVE_FA_DUMP) += opal-fadump.o
 obj-$(CONFIG_OPAL_CORE)+= opal-core.o
-obj-$(CONFIG_PCI)  += pci.o pci-ioda.o npu-dma.o pci-ioda-tce.o
+obj-$(CONFIG_PCI)  += pci.o pci-ioda.o pci-ioda-tce.o
 obj-$(CONFIG_PCI_IOV)   += pci-sriov.o
 obj-$(CONFIG_CXL_BASE) += pci-cxl.o
 obj-$(CONFIG_EEH)  += eeh-powernv.o
diff --git a/arch/powerpc/platforms/powernv/npu-dma.c 
b/arch/powerpc/platforms/powernv/npu-dma.c
deleted file mode 100644
index b711dc3262a308..00
--- a/arch/powerpc/platforms/powernv/npu-dma.c
+++ /dev/null
@@ -1,705 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-only
-/*
- * This file implements the DMA operations for NVLink devices. The NPU
- * devices all point to the same iommu table as the parent PCI device.
- *
- * Copyright Alistair Popple, IBM Corporation 2015.
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#include 
-#include 
-#include 
-#include 
-
-#include "pci.h"
-
-static struct pci_dev *get_pci_dev(struct device_node *dn)
-{
-   struct pci_dn *pdn = PCI_DN(dn);
-   struct pci_dev *pdev;
-
-   pdev = pci_get_domain_bus_and_slot(pci_domain_nr(pdn->phb->bus),
-  pdn->busno, pdn->devfn);
-
-   /*
-* pci_get_domain_bus_and_slot() increased the reference count of
-* the PCI device, but callers don't need that actually as the PE
-* already holds a reference to the device. Since callers aren't
-* aware of the reference count change, call pci_dev_put() now to
-* avoid leaks.
-*/
-   if (pdev)
-   pci_dev_put(pdev);
-
-   return pdev;
-}
-
-/* Given a NPU device get the associated PCI device. */
-struct pci_dev *pnv_pci_get_gpu_dev(struct pci_dev *npdev)
-{
-   struct device_node *dn;
-   struct pci_dev *gpdev;
-
-   if (WARN_ON(!npdev))
-   return NULL;
-
-   if (WARN_ON(!npdev->dev.of_

[PATCH 1/2] vfio/pci: remove vfio_pci_nvlink2

2021-03-25 Thread Christoph Hellwig

This driver never had any open userspace (which for VFIO would include
VM kernel drivers) that use it, and thus should never have been added
by our normal userspace ABI rules.

Signed-off-by: Christoph Hellwig 
Acked-by: Greg Kroah-Hartman 
---
 drivers/vfio/pci/Kconfig|   6 -
 drivers/vfio/pci/Makefile   |   1 -
 drivers/vfio/pci/vfio_pci.c |  18 -
 drivers/vfio/pci/vfio_pci_nvlink2.c | 490 
 drivers/vfio/pci/vfio_pci_private.h |  14 -
 include/uapi/linux/vfio.h   |  38 +--
 6 files changed, 4 insertions(+), 563 deletions(-)
 delete mode 100644 drivers/vfio/pci/vfio_pci_nvlink2.c

diff --git a/drivers/vfio/pci/Kconfig b/drivers/vfio/pci/Kconfig
index ac3c1dd3edeff1..53ce78d7d07be0 100644
--- a/drivers/vfio/pci/Kconfig
+++ b/drivers/vfio/pci/Kconfig
@@ -39,9 +39,3 @@ config VFIO_PCI_IGD
  and LPC bridge config space.
 
  To enable Intel IGD assignment through vfio-pci, say Y.
-
-config VFIO_PCI_NVLINK2
-   def_bool y
-   depends on VFIO_PCI && PPC_POWERNV
-   help
- VFIO PCI support for P9 Witherspoon machine with NVIDIA V100 GPUs
diff --git a/drivers/vfio/pci/Makefile b/drivers/vfio/pci/Makefile
index eff97a7cd9f139..3ff42093962f6f 100644
--- a/drivers/vfio/pci/Makefile
+++ b/drivers/vfio/pci/Makefile
@@ -2,7 +2,6 @@
 
 vfio-pci-y := vfio_pci.o vfio_pci_intrs.o vfio_pci_rdwr.o vfio_pci_config.o
 vfio-pci-$(CONFIG_VFIO_PCI_IGD) += vfio_pci_igd.o
-vfio-pci-$(CONFIG_VFIO_PCI_NVLINK2) += vfio_pci_nvlink2.o
 vfio-pci-$(CONFIG_S390) += vfio_pci_zdev.o
 
 obj-$(CONFIG_VFIO_PCI) += vfio-pci.o
diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
index 65e7e6b44578c2..d691006b642839 100644
--- a/drivers/vfio/pci/vfio_pci.c
+++ b/drivers/vfio/pci/vfio_pci.c
@@ -389,24 +389,6 @@ static int vfio_pci_enable(struct vfio_pci_device *vdev)
}
}
 
-   if (pdev->vendor == PCI_VENDOR_ID_NVIDIA &&
-   IS_ENABLED(CONFIG_VFIO_PCI_NVLINK2)) {
-   ret = vfio_pci_nvdia_v100_nvlink2_init(vdev);
-   if (ret && ret != -ENODEV) {
-   pci_warn(pdev, "Failed to setup NVIDIA NV2 RAM 
region\n");
-   goto disable_exit;
-   }
-   }
-
-   if (pdev->vendor == PCI_VENDOR_ID_IBM &&
-   IS_ENABLED(CONFIG_VFIO_PCI_NVLINK2)) {
-   ret = vfio_pci_ibm_npu2_init(vdev);
-   if (ret && ret != -ENODEV) {
-   pci_warn(pdev, "Failed to setup NVIDIA NV2 ATSD 
region\n");
-   goto disable_exit;
-   }
-   }
-
vfio_pci_probe_mmaps(vdev);
 
return 0;
diff --git a/drivers/vfio/pci/vfio_pci_nvlink2.c 
b/drivers/vfio/pci/vfio_pci_nvlink2.c
deleted file mode 100644
index 9adcf6a8f88857..00
--- a/drivers/vfio/pci/vfio_pci_nvlink2.c
+++ /dev/null
@@ -1,490 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-only
-/*
- * VFIO PCI NVIDIA Whitherspoon GPU support a.k.a. NVLink2.
- *
- * Copyright (C) 2018 IBM Corp.  All rights reserved.
- * Author: Alexey Kardashevskiy 
- *
- * Register an on-GPU RAM region for cacheable access.
- *
- * Derived from original vfio_pci_igd.c:
- * Copyright (C) 2016 Red Hat, Inc.  All rights reserved.
- * Author: Alex Williamson 
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include "vfio_pci_private.h"
-
-#define CREATE_TRACE_POINTS
-#include "trace.h"
-
-EXPORT_TRACEPOINT_SYMBOL_GPL(vfio_pci_nvgpu_mmap_fault);
-EXPORT_TRACEPOINT_SYMBOL_GPL(vfio_pci_nvgpu_mmap);
-EXPORT_TRACEPOINT_SYMBOL_GPL(vfio_pci_npu2_mmap);
-
-struct vfio_pci_nvgpu_data {
-   unsigned long gpu_hpa; /* GPU RAM physical address */
-   unsigned long gpu_tgt; /* TGT address of corresponding GPU RAM */
-   unsigned long useraddr; /* GPU RAM userspace address */
-   unsigned long size; /* Size of the GPU RAM window (usually 128GB) */
-   struct mm_struct *mm;
-   struct mm_iommu_table_group_mem_t *mem; /* Pre-registered RAM descr. */
-   struct pci_dev *gpdev;
-   struct notifier_block group_notifier;
-};
-
-static size_t vfio_pci_nvgpu_rw(struct vfio_pci_device *vdev,
-   char __user *buf, size_t count, loff_t *ppos, bool iswrite)
-{
-   unsigned int i = VFIO_PCI_OFFSET_TO_INDEX(*ppos) - VFIO_PCI_NUM_REGIONS;
-   struct vfio_pci_nvgpu_data *data = vdev->region[i].data;
-   loff_t pos = *ppos & VFIO_PCI_OFFSET_MASK;
-   loff_t posaligned = pos & PAGE_MASK, posoff = pos & ~PAGE_MASK;
-   size_t sizealigned;
-   void __iomem *ptr;
-
-   if (pos >= vdev->region[i].size)
-   return -EINVAL;
-
-   count = min(count, (size_t)(vdev->region[i].size - pos));
-
-   /*
-* We map only a bit of GPU RAM for a short time instead of mapping it
-* for the guest lifetime as:
-*
-* 1) we do not know GPU RAM size, only aperture which is 4-8 times
-*bigger than actual RAM

[PATCH v3 2/2] leds: rt4505: Add support for Richtek RT4505 flash LED controller

2021-03-25 Thread cy_huang

From: ChiYuan Huang 

Add support for RT4505 flash LED controller. It can support up to 1.5A
flash current with hardware timeout and low input voltage protection.

Signed-off-by: ChiYuan Huang 
Acked-by: Jacek Anaszewski 
---
 drivers/leds/flash/Kconfig   |  11 +
 drivers/leds/flash/Makefile  |   1 +
 drivers/leds/flash/leds-rt4505.c | 430 +++
 3 files changed, 442 insertions(+)
 create mode 100644 drivers/leds/flash/leds-rt4505.c

diff --git a/drivers/leds/flash/Kconfig b/drivers/leds/flash/Kconfig
index b580b41..3f49f3e 100644
--- a/drivers/leds/flash/Kconfig
+++ b/drivers/leds/flash/Kconfig
@@ -2,6 +2,17 @@
 
 if LEDS_CLASS_FLASH
 
+config LEDS_RT4505
+   tristate "LED support for RT4505 flashlight controller"
+   depends on I2C && OF
+   depends on V4L2_FLASH_LED_CLASS || !V4L2_FLASH_LED_CLASS
+   select REGMAP_I2C
+   help
+ This option enables support for the RT4505 flash LED controller.
+ RT4505 includes torch and flash functions with programmable current.
+ And it's commonly used to compensate the illuminance for the camera
+ inside the mobile product like as phones or tablets.
+
 config LEDS_RT8515
tristate "LED support for Richtek RT8515 flash/torch LED"
depends on GPIOLIB
diff --git a/drivers/leds/flash/Makefile b/drivers/leds/flash/Makefile
index e990e25..09aee56 100644
--- a/drivers/leds/flash/Makefile
+++ b/drivers/leds/flash/Makefile
@@ -1,3 +1,4 @@
 # SPDX-License-Identifier: GPL-2.0
 
+obj-$(CONFIG_LEDS_RT4505)  += leds-rt4505.o
 obj-$(CONFIG_LEDS_RT8515)  += leds-rt8515.o
diff --git a/drivers/leds/flash/leds-rt4505.c b/drivers/leds/flash/leds-rt4505.c
new file mode 100644
index ..ee129ab
--- /dev/null
+++ b/drivers/leds/flash/leds-rt4505.c
@@ -0,0 +1,430 @@
+// SPDX-License-Identifier: GPL-2.0-only
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define RT4505_REG_RESET   0x0
+#define RT4505_REG_CONFIG  0x8
+#define RT4505_REG_ILED0x9
+#define RT4505_REG_ENABLE  0xA
+#define RT4505_REG_FLAGS   0xB
+
+#define RT4505_RESET_MASK  BIT(7)
+#define RT4505_FLASHTO_MASKGENMASK(2, 0)
+#define RT4505_ITORCH_MASK GENMASK(7, 5)
+#define RT4505_ITORCH_SHIFT5
+#define RT4505_IFLASH_MASK GENMASK(4, 0)
+#define RT4505_ENABLE_MASK GENMASK(5, 0)
+#define RT4505_TORCH_SET   (BIT(0) | BIT(4))
+#define RT4505_FLASH_SET   (BIT(0) | BIT(1) | BIT(2) | BIT(4))
+#define RT4505_EXT_FLASH_SET   (BIT(0) | BIT(1) | BIT(4) | BIT(5))
+#define RT4505_FLASH_GET   (BIT(0) | BIT(1) | BIT(4))
+#define RT4505_OVP_MASKBIT(3)
+#define RT4505_SHORT_MASK  BIT(2)
+#define RT4505_OTP_MASKBIT(1)
+#define RT4505_TIMEOUT_MASKBIT(0)
+
+#define RT4505_ITORCH_MINUA46000
+#define RT4505_ITORCH_MAXUA375000
+#define RT4505_ITORCH_STPUA47000
+#define RT4505_IFLASH_MINUA93750
+#define RT4505_IFLASH_MAXUA150
+#define RT4505_IFLASH_STPUA93750
+#define RT4505_FLASHTO_MINUS   10
+#define RT4505_FLASHTO_MAXUS   80
+#define RT4505_FLASHTO_STPUS   10
+
+struct rt4505_priv {
+   struct device *dev;
+   struct regmap *regmap;
+   struct mutex lock;
+   struct led_classdev_flash flash;
+   struct v4l2_flash *v4l2_flash;
+};
+
+static int rt4505_torch_brightness_set(struct led_classdev *lcdev,
+  enum led_brightness level)
+{
+   struct rt4505_priv *priv =
+   container_of(lcdev, struct rt4505_priv, flash.led_cdev);
+   u32 val = 0;
+   int ret;
+
+   mutex_lock(&priv->lock);
+
+   if (level != LED_OFF) {
+   ret = regmap_update_bits(priv->regmap,
+RT4505_REG_ILED, RT4505_ITORCH_MASK,
+(level - 1) << RT4505_ITORCH_SHIFT);
+   if (ret)
+   goto unlock;
+
+   val = RT4505_TORCH_SET;
+   }
+
+   ret = regmap_update_bits(priv->regmap, RT4505_REG_ENABLE,
+RT4505_ENABLE_MASK, val);
+
+unlock:
+   mutex_unlock(&priv->lock);
+   return ret;
+}
+
+static enum led_brightness rt4505_torch_brightness_get(
+   struct led_classdev *lcdev)
+{
+   struct rt4505_priv *priv =
+   container_of(lcdev, struct rt4505_priv, flash.led_cdev);
+   u32 val;
+   int ret;
+
+   mutex_lock(&priv->lock);
+
+   ret = regmap_read(priv->regmap, RT4505_REG_ENABLE, &val);
+   if (ret) {
+   dev_err(lcdev->dev, "Failed to get LED enable\n");
+   ret = LED_OFF;
+   goto unlock;
+   }
+
+   if ((val & RT4505_ENABLE_MASK) != RT4505_TORCH_SET) {
+   ret = LED_OFF;
+   goto unlock;
+   }
+
+   ret = regmap_read(priv->regmap, RT4505_REG_ILED, &val);

remove the nvlink2 pci_vfio subdriver v2

2021-03-25 Thread Christoph Hellwig

Hi all,

the nvlink2 vfio subdriver is a weird beast.  It supports a hardware
feature without any open source component - what would normally be
the normal open source userspace that we require for kernel drivers,
although in this particular case user space could of course be a
kernel driver in a VM.  It also happens to be a complete mess that
does not properly bind to PCI IDs, is hacked into the vfio_pci driver
and also pulles in over 1000 lines of code always build into powerpc
kernels that have Power NV support enabled.  Because of all these
issues and the lack of breaking userspace when it is removed I think
the best idea is to simply kill.

Changes since v1:
 - document the removed subtypes as reserved
 - add the ACK from Greg

Diffstat:
 arch/powerpc/platforms/powernv/npu-dma.c |  705 ---
 b/arch/powerpc/include/asm/opal.h|3 
 b/arch/powerpc/include/asm/pci-bridge.h  |1 
 b/arch/powerpc/include/asm/pci.h |7 
 b/arch/powerpc/platforms/powernv/Makefile|2 
 b/arch/powerpc/platforms/powernv/opal-call.c |2 
 b/arch/powerpc/platforms/powernv/pci-ioda.c  |  185 ---
 b/arch/powerpc/platforms/powernv/pci.c   |   11 
 b/arch/powerpc/platforms/powernv/pci.h   |   17 
 b/arch/powerpc/platforms/pseries/pci.c   |   23 
 b/drivers/vfio/pci/Kconfig   |6 
 b/drivers/vfio/pci/Makefile  |1 
 b/drivers/vfio/pci/vfio_pci.c|   18 
 b/drivers/vfio/pci/vfio_pci_private.h|   14 
 b/include/uapi/linux/vfio.h  |   38 -
 drivers/vfio/pci/vfio_pci_nvlink2.c  |  490 --
 16 files changed, 12 insertions(+), 1511 deletions(-)

[PATCH v3 1/2] leds: rt4505: Add DT binding document for Richtek RT4505

2021-03-25 Thread cy_huang

From: ChiYuan Huang 

Add DT binding document for Richtek RT4505 flash LED controller.

Signed-off-by: ChiYuan Huang 
Reviewed-by: Rob Herring 
---
Changes since v3
- Port this patch to led for-next tree.
- Merge Acks in the commit context.
- Reorder the patch series from the docs first.

Changes since v2

- Create flash directory into drvers/leds.
- Coding style fix to meet 80 charactors per line limit.
- Refine the description in the Kconfig help text.
- Change all descriptions for 'led' text to uppercase 'LED'.
---
 .../devicetree/bindings/leds/leds-rt4505.yaml  | 57 ++
 1 file changed, 57 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/leds/leds-rt4505.yaml

diff --git a/Documentation/devicetree/bindings/leds/leds-rt4505.yaml 
b/Documentation/devicetree/bindings/leds/leds-rt4505.yaml
new file mode 100644
index ..5b0c74a
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/leds-rt4505.yaml
@@ -0,0 +1,57 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/leds-rt4505.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Richtek RT4505 Single Channel LED Driver
+
+maintainers:
+  - ChiYuan Huang 
+
+description: |
+  The RT4505 is a flash LED driver that can support up to 375mA and 1.5A for
+  torch and flash mode, respectively.
+
+  The data sheet can be found at:
+https://www.richtek.com/assets/product_file/RT4505/DS4505-02.pdf
+
+properties:
+  compatible:
+const: richtek,rt4505
+
+  reg:
+description: I2C slave address of the controller.
+maxItems: 1
+
+  led:
+type: object
+$ref: common.yaml#
+
+required:
+  - compatible
+  - reg
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+
+i2c0 {
+  #address-cells = <1>;
+  #size-cells = <0>;
+
+  led-controller@63 {
+compatible = "richtek,rt4505";
+reg = <0x63>;
+
+rt4505_flash: led {
+  function = LED_FUNCTION_FLASH;
+  color = ;
+  led-max-microamp = <375000>;
+  flash-max-microamp = <150>;
+  flash-max-timeout-us = <80>;
+};
+  };
+};
-- 
2.7.4

FYI & RFC: obsoleting reporting-bugs and making reporting-issues official

Lo! Since a few months mainline in
Documentation/admin-guide/reporting-issues.rst contains a text written
to obsolete the good old reporting-bugs text. For now, the new document
still contains a warning at the top that basically says "this is WIP".
But I'd like to remove that warning and delete reporting-bugs.rst in the
next merge window to make reporting-issues.rst fully official. With this
mail I want to give everyone a chance to take a look at the text and
speak up if you don't want me to move ahead for now.

For easier review I'll post the text of reporting-issues.rst in reply to
this mail. I'll do that in a few chunks, as if this was a cover letter
for a patch-set. Note, the version I'll send in some areas looks a bit
different from the one currently in mainline. That's because the text
I'll send already incorporates a few patches from docs-next that are
waiting for the next merge window; I also removed the "WIP" box as well
as two remaining "FIXME" notes, as those point to aspects I mention
below already.

@Greg, @Sasha, I'd be especially glad if at least one of you two could
take a look and yell if there is something you really dislike from the
perspective of the stable maintainers.

@Everyone: if you provide feedback, please state if you think something
needs to be fixed before I remove the WIP box. Everything else I might
leave for later depending on how much feedback I get and how much time I
can find to work on it before the next merge window opens.

It's pretty obvious reporting-issues in a lot of way is quite different
from reporting-bugs, so describing the differences would be hard and
likely not worth it. But there are a few things hidden in the details
I'd like to bring attention to, to ensure they are fine for everyone:

- the old text (reporting-bugs.rst) took a totally different approach to
bugzilla.kernel.org, as it mentions it as the place to file issue for
people that don't known how to contact the appropriate people; the new
text (reporting-issues) explains how to decode the MAINTAINERS file and
mentions out bugtracker rarely, because it isn't working that well (but
nevertheless is useful); those places that mentions it explain that it's
often the wrong place to report an issue.

- the new text tells users to always CC LKML on reports

- the new text tells people pretty directly (and early on!) they will
have to install a vanilla mainline kernel along the way (stable is
mentioned as an option, longterm discouraged); but it also states some
maintainers are willing to accept reports from distro kernels as long as
they are quite close to vanilla mainline or stable.

- the text doesn't yet mention the new 'linux-regressions' mailing list
that was basically agreed on a few days ago
(https://lore.kernel.org/lkml/CAHk-=wgiYqqLzsb9-UpfH+=ktk7ra-2fosdc_zj7wf47ws7...@mail.gmail.com/
), as I haven't asked yet for its creation. Will do so soon.

Hope that's okay for everybody. Ohh, and I hope it was okay to CC
ksummit-discuss, as that's afaics the best way to reach all the
important people and maintainers (sometimes I wonder if we should have a
better list for this). And it's IMHO on topic anyway as creating this
text was among the things we discussed on the maintainers summit 2017.

BTW, is anyone wonders how the text looks processed, see
https://www.kernel.org/doc/html/latest/admin-guide/reporting-issues.html
– but remember, in a few areas it looks a bit different as it's missing
the patches already in docs-next.

Ohh, and yes, the text is quite long. But if you dislike that, please
keep in mind that nobody has to read all of it from top to bottom: the
TLDR and the step-by-step guide basically state all the important bits;
the reference section explains each of the steps in more detail for
those that need more details or just want to look something up.

So, let the final(?) review begin!

Ciao, Thorsten

Re: [PATCH] powerpc/iommu/debug: Remove redundant NULL check

Daniel Axtens  writes:

It looks like the kernel test robot also reported this:
"[PATCH] powerpc/iommu/debug: fix ifnullfree.cocci warnings"
Weirdly I don't see it in patchwork.

I'm not sure which one mpe will want to take but either would do.

>> Fix the following coccicheck warnings:
>>
>> ./fs/io_uring.c:5989:4-9: WARNING: NULL check before some freeing
>> functions is not needed.

(Also, while unimportant, that's technically not the error you fix here
as it's for a different file!)

>
> This looks correct to me, and matches the description of debugfs_remove
> in Documentation/filesystems/debugfs.rst.
>
> If you have a number of similar fixes it might be helpful to do them in
> a single bigger patch, but I'm not sure if coccicheck reports much else
> as I don't have coccinelle installed at the moment.
>
> Reviewed-by: Daniel Axtens 
>
> Kind regards,
> Daniel

[PATCH] __scsi_remove_device: fix comments minor error

2021-03-25 Thread dudengke

From: dudengke 

Signed-off-by: dudengke 
---
 drivers/scsi/scsi_sysfs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c
index b6378c8ca783..86e8d0bf821d 100644
--- a/drivers/scsi/scsi_sysfs.c
+++ b/drivers/scsi/scsi_sysfs.c
@@ -1458,7 +1458,7 @@ void __scsi_remove_device(struct scsi_device *sdev)
 
/*
 * Paired with the kref_get() in scsi_sysfs_initialize().  We have
-* remoed sysfs visibility from the device, so make the target
+* removed sysfs visibility from the device, so make the target
 * invisible if this was the last device underneath it.
 */
scsi_target_reap(scsi_target(sdev));
-- 
2.25.1

Re: [PATCH v2 2/2] leds: leds-multi-gpio: Add multiple GPIOs LED driver

On 3/26/21 1:56 PM, Alexander Dahl wrote:
>> +
>> +module_platform_driver(multi_gpio_led_driver);
>> +
>> +MODULE_AUTHOR("Hermes Zhang ");
>> +MODULE_DESCRIPTION("Multiple GPIOs LED driver");
>> +MODULE_LICENSE("GPL v2");
>> +MODULE_ALIAS("platform:leds-multi-gpio");
> I did not review thouroughly, but in my mail the indentation looks
> wrong. Did checkpatch complain?

Sorry, I forgot to check the style before commit, but seems one problem
about extra space:

$ chkernel
ERROR: space prohibited before that ',' (ctx:WxW)
#164: FILE: drivers/leds/simple/leds-multi-gpio.c:76:
++ sizeof(u8) * nr_states , GFP_KERNEL);
   ^

I will fix it in next commit.


Best Regards,

Hermes

[PATCH] kconfig: streamline_config.pl: Couple of typo fixes



s/configuraton/configuration/
s/orignal/original/

Signed-off-by: Bhaskar Chowdhury 
---
 scripts/kconfig/streamline_config.pl | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/scripts/kconfig/streamline_config.pl 
b/scripts/kconfig/streamline_config.pl
index 1c78ba49ca99..911c72a2dbc4 100755
--- a/scripts/kconfig/streamline_config.pl
+++ b/scripts/kconfig/streamline_config.pl
@@ -21,7 +21,7 @@
 #  1. Boot up the kernel that you want to stream line the config on.
 #  2. Change directory to the directory holding the source of the
 #   kernel that you just booted.
-#  3. Copy the configuraton file to this directory as .config
+#  3. Copy the configuration file to this directory as .config
 #  4. Have all your devices that you need modules for connected and
 #  operational (make sure that their corresponding modules are loaded)
 #  5. Run this script redirecting the output to some other file
@@ -481,7 +481,7 @@ sub parse_config_depends
 # The idea is we look at all the configs that select it. If one
 # is already in our list of configs to enable, then there's nothing
 # else to do. If there isn't, we pick the first config that was
-# enabled in the orignal config and use that.
+# enabled in the original config and use that.
 sub parse_config_selects
 {
 my ($config, $p) = @_;
--
2.26.2

Re: [PATCH] crypto: vmx: fix incorrect kernel-doc comment syntax in files

Hi Aditya,

Thanks for your patch!

> The opening comment mark '/**' is used for highlighting the beginning of
> kernel-doc comments.
> There are certain files in drivers/crypto/vmx, which follow this syntax,
> but the content inside does not comply with kernel-doc.
> Such lines were probably not meant for kernel-doc parsing, but are parsed
> due to the presence of kernel-doc like comment syntax(i.e, '/**'), which
> causes unexpected warnings from kernel-doc.
>
> E.g., presence of kernel-doc like comment in the header line for
> drivers/crypto/vmx/vmx.c causes this warning by kernel-doc:
>
> "warning: expecting prototype for Routines supporting VMX instructions on the 
> Power 8(). Prototype was for p8_init() instead"

checkpatch (scripts/checkpatch.pl --strict -g HEAD) complains about this line:
WARNING: Possible unwrapped commit description (prefer a maximum 75 chars per 
line)
but checkpatch should be ignored here, as you did the right thing by not
breaking an error message across multiple lines.

> Similarly for other files too.
>
> Provide a simple fix by replacing such occurrences with general comment
> format, i.e. '/*', to prevent kernel-doc from parsing it.

This makes sense.

Reviewed-by: Daniel Axtens 

Kind regards,
Daniel

>
> Signed-off-by: Aditya Srivastava 
> ---
> * Applies perfectly on next-20210319
>
>  drivers/crypto/vmx/aes.c | 2 +-
>  drivers/crypto/vmx/aes_cbc.c | 2 +-
>  drivers/crypto/vmx/aes_ctr.c | 2 +-
>  drivers/crypto/vmx/aes_xts.c | 2 +-
>  drivers/crypto/vmx/ghash.c   | 2 +-
>  drivers/crypto/vmx/vmx.c | 2 +-
>  6 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/crypto/vmx/aes.c b/drivers/crypto/vmx/aes.c
> index d05c02baebcf..ec06189fbf99 100644
> --- a/drivers/crypto/vmx/aes.c
> +++ b/drivers/crypto/vmx/aes.c
> @@ -1,5 +1,5 @@
>  // SPDX-License-Identifier: GPL-2.0-only
> -/**
> +/*
>   * AES routines supporting VMX instructions on the Power 8
>   *
>   * Copyright (C) 2015 International Business Machines Inc.
> diff --git a/drivers/crypto/vmx/aes_cbc.c b/drivers/crypto/vmx/aes_cbc.c
> index d88084447f1c..ed0debc7acb5 100644
> --- a/drivers/crypto/vmx/aes_cbc.c
> +++ b/drivers/crypto/vmx/aes_cbc.c
> @@ -1,5 +1,5 @@
>  // SPDX-License-Identifier: GPL-2.0-only
> -/**
> +/*
>   * AES CBC routines supporting VMX instructions on the Power 8
>   *
>   * Copyright (C) 2015 International Business Machines Inc.
> diff --git a/drivers/crypto/vmx/aes_ctr.c b/drivers/crypto/vmx/aes_ctr.c
> index 79ba062ee1c1..9a3da8cd62f3 100644
> --- a/drivers/crypto/vmx/aes_ctr.c
> +++ b/drivers/crypto/vmx/aes_ctr.c
> @@ -1,5 +1,5 @@
>  // SPDX-License-Identifier: GPL-2.0-only
> -/**
> +/*
>   * AES CTR routines supporting VMX instructions on the Power 8
>   *
>   * Copyright (C) 2015 International Business Machines Inc.
> diff --git a/drivers/crypto/vmx/aes_xts.c b/drivers/crypto/vmx/aes_xts.c
> index 9fee1b1532a4..dabbccb41550 100644
> --- a/drivers/crypto/vmx/aes_xts.c
> +++ b/drivers/crypto/vmx/aes_xts.c
> @@ -1,5 +1,5 @@
>  // SPDX-License-Identifier: GPL-2.0-only
> -/**
> +/*
>   * AES XTS routines supporting VMX In-core instructions on Power 8
>   *
>   * Copyright (C) 2015 International Business Machines Inc.
> diff --git a/drivers/crypto/vmx/ghash.c b/drivers/crypto/vmx/ghash.c
> index 14807ac2e3b9..5bc5710a6de0 100644
> --- a/drivers/crypto/vmx/ghash.c
> +++ b/drivers/crypto/vmx/ghash.c
> @@ -1,5 +1,5 @@
>  // SPDX-License-Identifier: GPL-2.0
> -/**
> +/*
>   * GHASH routines supporting VMX instructions on the Power 8
>   *
>   * Copyright (C) 2015, 2019 International Business Machines Inc.
> diff --git a/drivers/crypto/vmx/vmx.c b/drivers/crypto/vmx/vmx.c
> index a40d08e75fc0..7eb713cc87c8 100644
> --- a/drivers/crypto/vmx/vmx.c
> +++ b/drivers/crypto/vmx/vmx.c
> @@ -1,5 +1,5 @@
>  // SPDX-License-Identifier: GPL-2.0-only
> -/**
> +/*
>   * Routines supporting VMX instructions on the Power 8
>   *
>   * Copyright (C) 2015 International Business Machines Inc.
> -- 
> 2.17.1

Re: [PATCH v8 3/3] arm64: dts: ti: k3-j7200: Add support for higher speed modes and update delay select values for MMCSD subsystems

Hi Kishon,

On 25/03/21 9:44 pm, Kishon Vijay Abraham I wrote:
> Hi Aswath,
> 
> On 24/03/21 12:07 pm, Aswath Govindraju wrote:
>> The following speed modes are now supported in J7200 SoC,
>> - HS200 and HS400 modes at 1.8 V card voltage, in MMCSD0 subsystem [1].
>> - UHS-I speed modes in MMCSD1 subsystem [1].
>>
>> Add support for UHS-I modes by adding voltage regulator device tree nodes
>> and corresponding pinmux details, to power cycle and voltage switch cards.
>> Set respective tags in sdhci0 and remove no-1-8-v tag from sdhci1
>> device tree nodes.
>>
>> Also update the delay values for various speed modes supported, based on
>> the revised january 2021 J7200 datasheet[2].
>>
>> [1] - section 12.3.6.1.1 MMCSD Features, in
>>   https://www.ti.com/lit/ug/spruiu1a/spruiu1a.pdf,
>>   (SPRUIU1A – JULY 2020 – REVISED JANUARY 2021)
>>
>> [2] - https://www.ti.com/lit/ds/symlink/dra821u.pdf,
>>   (SPRSP57B – APRIL 2020 – REVISED JANUARY 2021)
> minor comments below.. once you fix them, please add
> 
> Reviewed-by: Kishon Vijay Abraham I 
>>

Thank you for your review :).

>> Signed-off-by: Aswath Govindraju 
>> ---
>>  .../dts/ti/k3-j7200-common-proc-board.dts | 78 +++
>>  arch/arm64/boot/dts/ti/k3-j7200-main.dtsi | 14 +++-
>>  2 files changed, 90 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts 
>> b/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts
>> index b493f939b09a..a069787e1783 100644
>> --- a/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts
>> +++ b/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts
>> @@ -16,6 +16,65 @@
>>  stdout-path = "serial2:115200n8";
>>  bootargs = "console=ttyS2,115200n8 
>> earlycon=ns16550a,mmio32,0x0280";
>>  };
>> +
>> +evm_12v0: fixedregulator-evm12v0 {
>> +/* main supply */
>> +compatible = "regulator-fixed";
>> +regulator-name = "evm_12v0";
>> +regulator-min-microvolt = <1200>;
>> +regulator-max-microvolt = <1200>;
>> +regulator-always-on;
>> +regulator-boot-on;
>> +};
>> +
>> +vsys_3v3: fixedregulator-vsys3v3 {
>> +/* Output of LMS140 */
> 
> %s/LMS140/LM5140

Will make this change in respin.

>> +compatible = "regulator-fixed";
>> +regulator-name = "vsys_3v3";
>> +regulator-min-microvolt = <330>;
>> +regulator-max-microvolt = <330>;
>> +vin-supply = <&evm_12v0>;
>> +regulator-always-on;
>> +regulator-boot-on;
>> +};
>> +
>> +vsys_5v0: fixedregulator-vsys5v0 {
>> +/* Output of LM5140 */
>> +compatible = "regulator-fixed";
>> +regulator-name = "vsys_5v0";
>> +regulator-min-microvolt = <500>;
>> +regulator-max-microvolt = <500>;
>> +vin-supply = <&evm_12v0>;
>> +regulator-always-on;
>> +regulator-boot-on;
>> +};
>> +
>> +vdd_mmc1: fixedregulator-sd {
>> +/* Output of TPS22918  */
>> +compatible = "regulator-fixed";
>> +regulator-name = "vdd_mmc1";
>> +regulator-min-microvolt = <330>;
>> +regulator-max-microvolt = <330>;
>> +regulator-boot-on;
>> +enable-active-high;
>> +vin-supply = <&vsys_3v3>;
>> +gpio = <&exp2 2 GPIO_ACTIVE_HIGH>;
>> +};
>> +
>> +vdd_sd_dv: gpio-regulator-vdd-sd-dv {
>> +/* Output of TLV71033 */
> 
> Would have preferred to keep this similar to j721e.
> gpio-regulator-TLV71033 is used in j721e

Will make this change in respin

>> +compatible = "regulator-gpio";
>> +regulator-name = "vdd_sd_dv";
> 
> same comment here..

Will make this change in respin

>> +pinctrl-names = "default";
>> +pinctrl-0 = <&vdd_sd_dv_pins_default>;
>> +regulator-min-microvolt = <180>;
>> +regulator-max-microvolt = <330>;
>> +regulator-boot-on;
>> +vin-supply = <&vsys_5v0>;
>> +gpios = <&main_gpio0 55 GPIO_ACTIVE_HIGH>;
>> +states = <180 0x0>,
>> + <330 0x1>;
>> +};
>>  };
>>  
>>  &wkup_pmx0 {
>> @@ -45,6 +104,13 @@
>>  };
>>  
>>  &main_pmx0 {
>> +main_i2c0_pins_default: main-i2c0-pins-default {
>> +pinctrl-single,pins = <
>> +J721E_IOPAD(0xd4, PIN_INPUT_PULLUP, 0) /* (V3) I2C0_SCL 
>> */
>> +J721E_IOPAD(0xd8, PIN_INPUT_PULLUP, 0) /* (W2) I2C0_SDA 
>> */
>> +>;
>> +};
>> +
>>  main_i2c1_pins_default: main-i2c1-pins-default {
>>  pinctrl-single,pins = <
>>  J721E_IOPAD(0xdc, PIN_INPUT_PULLUP, 3) /* (U3) 
>> ECAP0_IN_APWM_OUT.I2C1_SCL */
>> @@ -70,6 +136,12 @@
>>  J721E_IOPAD(0x120, PIN_OUTPUT, 0) /* (T4)

[PATCH -next] ASoC: cs42l42: Remove unused including

Remove including  that don't need it.

Reported-by: Hulk Robot 
Signed-off-by: Zheng Yongjun 
---
 sound/soc/codecs/cs42l42.c | 1 -
 1 file changed, 1 deletion(-)
diff --git a/sound/soc/codecs/cs42l42.c b/sound/soc/codecs/cs42l42.c
index bf982e145e94..bd043f5d5d90 100644
--- a/sound/soc/codecs/cs42l42.c
+++ b/sound/soc/codecs/cs42l42.c
@@ -11,7 +11,6 @@
 #include 
 #include 
-#include 
 #include 
 #include 
 #include

[PATCH -next] ASoC: cs35l35: Remove unused including

Remove including  that don't need it.

Reported-by: Hulk Robot 
Signed-off-by: Zheng Yongjun 
---
 sound/soc/codecs/cs35l35.c | 1 -
 1 file changed, 1 deletion(-)
diff --git a/sound/soc/codecs/cs35l35.c b/sound/soc/codecs/cs35l35.c
index 55d529aa0011..5d361c74e803 100644
--- a/sound/soc/codecs/cs35l35.c
+++ b/sound/soc/codecs/cs35l35.c
@@ -9,7 +9,6 @@
 #include 
 #include 
-#include 
 #include 
 #include 
 #include

Re: [PATCH v2 2/2] leds: leds-multi-gpio: Add multiple GPIOs LED driver

2021-03-25 Thread Alexander Dahl

Hello Hermes,

great to see your improved series. See below for my remarks.

On Fri, Mar 26, 2021 at 01:28:01PM +0800, Hermes Zhang wrote:
> From: Hermes Zhang 
> 
> Introduce a new multiple GPIOs LED driver. This LED will made of
> multiple GPIOs (up to 8) and will map different brightness to different
> GPIOs states which defined in dts file.
> 
> Signed-off-by: Hermes Zhang 
> ---
>  drivers/leds/Kconfig  |   3 +
>  drivers/leds/Makefile |   3 +
>  drivers/leds/simple/Kconfig   |  23 
>  drivers/leds/simple/Makefile  |   3 +
>  drivers/leds/simple/leds-multi-gpio.c | 144 ++
>  5 files changed, 176 insertions(+)
>  create mode 100644 drivers/leds/simple/Kconfig
>  create mode 100644 drivers/leds/simple/Makefile
>  create mode 100644 drivers/leds/simple/leds-multi-gpio.c
> 
> diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
> index b6742b4231bf..f95217b2fcf1 100644
> --- a/drivers/leds/Kconfig
> +++ b/drivers/leds/Kconfig
> @@ -937,4 +937,7 @@ source "drivers/leds/trigger/Kconfig"
>  comment "LED Blink"
>  source "drivers/leds/blink/Kconfig"
>  
> +comment "LED Simple"
> +source "drivers/leds/simple/Kconfig"
> +
>  endif # NEW_LEDS
> diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
> index 2a698df9da57..26917d93fa03 100644
> --- a/drivers/leds/Makefile
> +++ b/drivers/leds/Makefile
> @@ -111,3 +111,6 @@ obj-$(CONFIG_LEDS_TRIGGERS)   += trigger/
>  
>  # LED Blink
>  obj-$(CONFIG_LEDS_BLINK)+= blink/
> +
> +# LED Blink
> +obj-$(CONFIG_LEDS_SIMPLE)+= simple/

That comment should read "LED Simple", right?

> diff --git a/drivers/leds/simple/Kconfig b/drivers/leds/simple/Kconfig
> new file mode 100644
> index ..7aef82701f86
> --- /dev/null
> +++ b/drivers/leds/simple/Kconfig
> @@ -0,0 +1,23 @@
> +menuconfig LEDS_SIMPLE
> + bool "Simple LED support"
> + depends on LEDS_CLASS
> + help
> +   This option enables simple leds support for the leds class.
> +   If unsure, say Y.
> +
> +if LEDS_SIMPLE
> +
> +config LEDS_MULTI_GPIO
> + tristate "LED Support for multiple GPIOs LED"
> + depends on LEDS_CLASS
> + depends on GPIOLIB
> + depends on OF
> + help
> +   This option enables support for a multiple GPIOs LED. Such LED is made
> +   of multiple GPIOs and could change the brightness by setting different
> +   states of the GPIOs.
> +
> +   To compile this driver as a module, choose M here: the
> +   module will be called leds-multi-gpio.
> +
> +endif # LEDS_SIMPLE

I'm wondering why this is part of this driver? I suppose there's no
such folder yet, although Pavel suggested. Would it make sense to put
that Kconfig menu entry and folder creation to a separate commit?

> diff --git a/drivers/leds/simple/Makefile b/drivers/leds/simple/Makefile
> new file mode 100644
> index ..2ba655fdc175
> --- /dev/null
> +++ b/drivers/leds/simple/Makefile
> @@ -0,0 +1,3 @@
> +# SPDX-License-Identifier: GPL-2.0
> +
> +obj-$(CONFIG_LEDS_MULTI_GPIO)+= leds-multi-gpio.o
> diff --git a/drivers/leds/simple/leds-multi-gpio.c 
> b/drivers/leds/simple/leds-multi-gpio.c
> new file mode 100644
> index ..14fdaa5a2aac
> --- /dev/null
> +++ b/drivers/leds/simple/leds-multi-gpio.c
> @@ -0,0 +1,144 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2021 Axis Communications AB
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +
> +#define MAX_GPIO_NUM  8
> +
> +struct multi_gpio_led_priv {
> + struct led_classdev cdev;
> +
> + struct gpio_descs *gpios;
> +
> + u16 nr_states;
> +
> + u8 states[0];
> +};
> +
> +
> +static void multi_gpio_led_set(struct led_classdev *led_cdev,
> + enum led_brightness value)
> +{
> + struct multi_gpio_led_priv *priv;
> + int idx;
> +
> + DECLARE_BITMAP(values, MAX_GPIO_NUM);
> +
> + priv = container_of(led_cdev, struct multi_gpio_led_priv, cdev);
> +
> + idx = value > led_cdev->max_brightness ? led_cdev->max_brightness : 
> value;
> +
> + values[0] = priv->states[idx];
> +
> + gpiod_set_array_value(priv->gpios->ndescs, priv->gpios->desc,
> + priv->gpios->info, values);
> +}
> +
> +static int multi_gpio_led_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct device_node *node = dev->of_node;
> + struct multi_gpio_led_priv *priv = NULL;
> + int ret;
> + const char *state = NULL;
> + struct led_init_data init_data = {};
> + struct gpio_descs *gpios;
> + u16 nr_states;
> +
> + gpios = devm_gpiod_get_array(dev, "led", GPIOD_OUT_LOW);
> + if (IS_ERR(gpios))
> + return PTR_ERR(gpios);
> +
> + if (gpios->ndescs >= MAX_GPIO_NUM) {
> + dev_err(dev, "Too many GPIOs\n");
> + return -EINVAL;
> + }
> +
> + ret = of_property_count_u8_elems(node, "led-states");
> + if (ret <

[PATCH] scripts: modpost.c: Fix a few typos



s/agorithm/algorithm/
s/criterias/criteria/
s/targetting/targeting/   two different places.

Signed-off-by: Bhaskar Chowdhury 
---
 scripts/mod/modpost.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
index 24725e50c7b4..9b971ec9e58d 100644
--- a/scripts/mod/modpost.c
+++ b/scripts/mod/modpost.c
@@ -202,7 +202,7 @@ struct symbol {

 static struct symbol *symbolhash[SYMBOL_HASH_SIZE];

-/* This is based on the hash agorithm from gdbm, via tdb */
+/* This is based on the hash algorithm from gdbm, via tdb */
 static inline unsigned int tdb_hash(const char *name)
 {
unsigned value; /* Used to compute the hash value.  */
@@ -985,7 +985,7 @@ enum mismatch {
 };

 /**
- * Describe how to match sections on different criterias:
+ * Describe how to match sections on different criteria:
  *
  * @fromsec: Array of sections to be matched.
  *
@@ -993,12 +993,12 @@ enum mismatch {
  * this array is forbidden (black-list).  Can be empty.
  *
  * @good_tosec: Relocations applied to a section in @fromsec must be
- * targetting sections in this array (white-list).  Can be empty.
+ * targeting sections in this array (white-list).  Can be empty.
  *
  * @mismatch: Type of mismatch.
  *
  * @symbol_white_list: Do not match a relocation to a symbol in this list
- * even if it is targetting a section in @bad_to_sec.
+ * even if it is targeting a section in @bad_to_sec.
  *
  * @handler: Specific handler to call when a match is found.  If NULL,
  * default_mismatch_handler() will be called.
--
2.26.2

Re: [PATCH] powerpc/iommu/debug: Remove redundant NULL check

Hi Jiapeng Chong,  writes:

> Fix the following coccicheck warnings:
>
> ./fs/io_uring.c:5989:4-9: WARNING: NULL check before some freeing
> functions is not needed.

This looks correct to me, and matches the description of debugfs_remove
in Documentation/filesystems/debugfs.rst.

If you have a number of similar fixes it might be helpful to do them in
a single bigger patch, but I'm not sure if coccicheck reports much else
as I don't have coccinelle installed at the moment.

Reviewed-by: Daniel Axtens 

Kind regards,
Daniel

[PATCH] drivers: staging: netlogic: fix unmet dependency for PHYLIB

2021-03-25 Thread Julian Braha

When NETLOGIC_XLR_NET is enabled, and NETDEVICES is
disabled, Kbuild gives the following warning:

WARNING: unmet direct dependencies detected for PHYLIB
  Depends on [n]: NETDEVICES [=n]
  Selected by [y]:
  - NETLOGIC_XLR_NET [=y] && STAGING [=y] && CPU_XLR [=y]

This is because NETLOGIC_XLR_NET selects PHYLIB
without selecting or depending on NETDEVICES,
despite PHYLIB depending on NETDEVICES.

Signed-off-by: Julian Braha 
---
 drivers/staging/netlogic/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/staging/netlogic/Kconfig b/drivers/staging/netlogic/Kconfig
index b2a4d4586697..e1712606ee3c 100644
--- a/drivers/staging/netlogic/Kconfig
+++ b/drivers/staging/netlogic/Kconfig
@@ -2,6 +2,7 @@
 config NETLOGIC_XLR_NET
tristate "Netlogic XLR/XLS network device"
depends on CPU_XLR
+   depends on NETDEVICES
select PHYLIB
help
This driver support Netlogic XLR/XLS on chip gigabit
-- 
2.25.1

Re: [PATCH] [v2] tools: testing: Remove duplicate includes

Wan Jiabing  writes:

> sched.h has been included at line 33, so remove the 
> duplicate one at line 36.

> pthread.h has been included at line 17,so remove the 
> duplicate one at line 20.

I can see that both of these are correct from the diff.

> inttypes.h has been included at line 19, so remove the 
> duplicate one at line 23.

For this one I checked the file. Indeed there is another inttypes.h, so
this is also correct.

Again, all the automated checks pass. (although I don't think any of the
automated builds include selftests.)

So:
Reviewed-by: Daniel Axtens 

Kind regards,
Daniel

>
> Signed-off-by: Wan Jiabing 
> ---
>  tools/testing/selftests/powerpc/mm/tlbie_test.c | 1 -
>  tools/testing/selftests/powerpc/tm/tm-poison.c  | 1 -
>  tools/testing/selftests/powerpc/tm/tm-vmx-unavail.c | 1 -
>  3 files changed, 3 deletions(-)
>
> diff --git a/tools/testing/selftests/powerpc/mm/tlbie_test.c 
> b/tools/testing/selftests/powerpc/mm/tlbie_test.c
> index f85a0938ab25..48344a74b212 100644
> --- a/tools/testing/selftests/powerpc/mm/tlbie_test.c
> +++ b/tools/testing/selftests/powerpc/mm/tlbie_test.c
> @@ -33,7 +33,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> diff --git a/tools/testing/selftests/powerpc/tm/tm-poison.c 
> b/tools/testing/selftests/powerpc/tm/tm-poison.c
> index 29e5f26af7b9..27c083a03d1f 100644
> --- a/tools/testing/selftests/powerpc/tm/tm-poison.c
> +++ b/tools/testing/selftests/powerpc/tm/tm-poison.c
> @@ -20,7 +20,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  
>  #include "tm.h"
>  
> diff --git a/tools/testing/selftests/powerpc/tm/tm-vmx-unavail.c 
> b/tools/testing/selftests/powerpc/tm/tm-vmx-unavail.c
> index e2a0c07e8362..9ef37a9836ac 100644
> --- a/tools/testing/selftests/powerpc/tm/tm-vmx-unavail.c
> +++ b/tools/testing/selftests/powerpc/tm/tm-vmx-unavail.c
> @@ -17,7 +17,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  
>  #include "tm.h"
>  #include "utils.h"
> -- 
> 2.25.1

Re: Linux 4.14.227

2021-03-25 Thread Samuel Zou





On 2021/3/24 18:23, Greg Kroah-Hartman wrote:

I'm announcing the release of the 4.14.227 kernel.

All users of the 4.14 kernel series must upgrade.

The updated 4.14.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-4.14.y
and can be browsed at the normal kernel.org git web browser:

https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

thanks,

greg k-h



Tested on x86 for 4.14.227,

Kernel repo:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
Branch: linux-4.14.y
Version: 4.14.227
Commit: 670d6552eda8ff0c5f396d3d6f0174237917c66c
Compiler: gcc version 7.3.0 (GCC)

x86:

Testcase Result Summary:
total: 4667
passed: 4667
failed: 0
timeout: 0


Tested-by: Hulk Robot

Re: [PATCH] [v2] arch: powerpc: Remove duplicate includes

Wan Jiabing  writes:

> mmu-hash.h: asm/bug.h has been included at line 12, so remove 
> the duplicate one at line 21.

Looking at the file I had wondered if this was due to a #ifdef being
removed, but no, the second one was just added in commit 891121e6c02c
("powerpc/mm: Differentiate between hugetlb and THP during page
walk"). How odd!

Anyway, all of these look good to me, and the automated checks at
http://patchwork.ozlabs.org/project/linuxppc-dev/patch/20210323062916.295346-1-wanjiab...@vivo.com/
have all passed.

Reviewed-by: Daniel Axtens 

Kind regards,
Daniel

Re: kinldy see the V2 ..just sent [PATCH] fddi: skfp: Rudimentary spello fixes

On 17:09 Thu 25 Mar 2021, David Miller wrote:

From: Bhaskar Chowdhury 
Date: Thu, 25 Mar 2021 12:38:35 +0530

s/autohorized/authorized/
s/recsource/resource/
s/measuered/measured/
sauthoriziation/authorization/

Signed-off-by: Bhaskar Chowdhury 

Does not apply cleanly to net-next please respin.

Kindly look in ,sending a V2 of this patch, hoping, that works!

Thank you.

[PATCH V2] fddi: skfp: Rudimentary spello fixes



s/autohorized/authorized/
s/recsource/resource/
s/measuered/measured/
s/authoriziation/authorization/

Signed-off-by: Bhaskar Chowdhury 
---
 Changes from V1:
 David said the patch didn't applied cleanly,so recreate it.
 Randy found out a glitch in changelog text, fixed it.

 drivers/net/fddi/skfp/h/smt.h | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/net/fddi/skfp/h/smt.h b/drivers/net/fddi/skfp/h/smt.h
index a0dbc0f57a55..8d104f13e2c3 100644
--- a/drivers/net/fddi/skfp/h/smt.h
+++ b/drivers/net/fddi/skfp/h/smt.h
@@ -411,7 +411,7 @@ struct smt_p_reason {
 #define SMT_RDF_ILLEGAL 0x0005 /* read only (PMF) */
 #define SMT_RDF_NOPARAM0x6 /* parameter not supported 
(PMF) */
 #define SMT_RDF_RANGE  0x8 /* out of range */
-#define SMT_RDF_AUTHOR 0x9 /* not autohorized */
+#define SMT_RDF_AUTHOR 0x9 /* not authorized */
 #define SMT_RDF_LENGTH 0x0a/* length error */
 #define SMT_RDF_TOOLONG0x0b/* length error */
 #define SMT_RDF_SBA0x0d/* SBA denied */
@@ -450,7 +450,7 @@ struct smt_p_version {

 struct smt_p_0015 {
struct smt_para para ;  /* generic parameter header */
-   u_int   res_type ;  /* recsource type */
+   u_int   res_type ;  /* resource type */
 } ;

 #defineSYNC_BW 0x0001L /* Synchronous Bandwidth */
@@ -489,7 +489,7 @@ struct smt_p_0017 {
 struct smt_p_0018 {
struct smt_para para ;  /* generic parameter header */
int sba_ov_req ;/* total sync bandwidth req for 
overhead*/
-} ;/* measuered in bytes per T_Neg */
+} ;/* measured in bytes per T_Neg */

 /*
  * P19 : SBA Allocation Address
@@ -562,7 +562,7 @@ struct smt_p_fsc {
 #define FSC_TYPE2  2   /* Special A/C indicator forwarding */

 /*
- * P00 21 : user defined authoriziation (see pmf.c)
+ * P00 21 : user defined authorization (see pmf.c)
  */
 #define SMT_P_AUTHOR   0x0021

--
2.26.2

[PATCH] arch: mips: fix unmet dependency for MTD_COMPLEX_MAPPINGS

2021-03-25 Thread Julian Braha

When CAVIUM_OCTEON_SOC is enabled, and MTD is disabled,
Kbuild gives the following warning:

WARNING: unmet direct dependencies detected for MTD_COMPLEX_MAPPINGS
  Depends on [n]: MTD [=n] && HAS_IOMEM [=y]
  Selected by [y]:
  - CAVIUM_OCTEON_SOC [=y] && 

This is because CAVIUM_OCTEON_SOC selects MTD_COMPLEX_MAPPINGS,
without selecting or depending on MTD, despite MTD_COMPLEX_MAPPINGS
depending on MTD.

Signed-off-by: Julian Braha 
---
 arch/mips/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index d89efba3d8a4..39b1c8030842 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -998,6 +998,7 @@ config CAVIUM_OCTEON_SOC
select NR_CPUS_DEFAULT_64
select MIPS_NR_CPU_NR_MAP_1024
select BUILTIN_DTB
+   select MTD
select MTD_COMPLEX_MAPPINGS
select SWIOTLB
select SYS_SUPPORTS_RELOCATABLE
-- 
2.25.1

[PATCH v2 2/2] leds: leds-multi-gpio: Add multiple GPIOs LED driver

From: Hermes Zhang 

Introduce a new multiple GPIOs LED driver. This LED will made of
multiple GPIOs (up to 8) and will map different brightness to different
GPIOs states which defined in dts file.

Signed-off-by: Hermes Zhang 
---
 drivers/leds/Kconfig  |   3 +
 drivers/leds/Makefile |   3 +
 drivers/leds/simple/Kconfig   |  23 
 drivers/leds/simple/Makefile  |   3 +
 drivers/leds/simple/leds-multi-gpio.c | 144 ++
 5 files changed, 176 insertions(+)
 create mode 100644 drivers/leds/simple/Kconfig
 create mode 100644 drivers/leds/simple/Makefile
 create mode 100644 drivers/leds/simple/leds-multi-gpio.c

diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index b6742b4231bf..f95217b2fcf1 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -937,4 +937,7 @@ source "drivers/leds/trigger/Kconfig"
 comment "LED Blink"
 source "drivers/leds/blink/Kconfig"
 
+comment "LED Simple"
+source "drivers/leds/simple/Kconfig"
+
 endif # NEW_LEDS
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index 2a698df9da57..26917d93fa03 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -111,3 +111,6 @@ obj-$(CONFIG_LEDS_TRIGGERS) += trigger/
 
 # LED Blink
 obj-$(CONFIG_LEDS_BLINK)+= blink/
+
+# LED Blink
+obj-$(CONFIG_LEDS_SIMPLE)  += simple/
diff --git a/drivers/leds/simple/Kconfig b/drivers/leds/simple/Kconfig
new file mode 100644
index ..7aef82701f86
--- /dev/null
+++ b/drivers/leds/simple/Kconfig
@@ -0,0 +1,23 @@
+menuconfig LEDS_SIMPLE
+   bool "Simple LED support"
+   depends on LEDS_CLASS
+   help
+ This option enables simple leds support for the leds class.
+ If unsure, say Y.
+
+if LEDS_SIMPLE
+
+config LEDS_MULTI_GPIO
+   tristate "LED Support for multiple GPIOs LED"
+   depends on LEDS_CLASS
+   depends on GPIOLIB
+   depends on OF
+   help
+ This option enables support for a multiple GPIOs LED. Such LED is made
+ of multiple GPIOs and could change the brightness by setting different
+ states of the GPIOs.
+
+ To compile this driver as a module, choose M here: the
+ module will be called leds-multi-gpio.
+
+endif # LEDS_SIMPLE
diff --git a/drivers/leds/simple/Makefile b/drivers/leds/simple/Makefile
new file mode 100644
index ..2ba655fdc175
--- /dev/null
+++ b/drivers/leds/simple/Makefile
@@ -0,0 +1,3 @@
+# SPDX-License-Identifier: GPL-2.0
+
+obj-$(CONFIG_LEDS_MULTI_GPIO)  += leds-multi-gpio.o
diff --git a/drivers/leds/simple/leds-multi-gpio.c 
b/drivers/leds/simple/leds-multi-gpio.c
new file mode 100644
index ..14fdaa5a2aac
--- /dev/null
+++ b/drivers/leds/simple/leds-multi-gpio.c
@@ -0,0 +1,144 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2021 Axis Communications AB
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+
+#define MAX_GPIO_NUM  8
+
+struct multi_gpio_led_priv {
+   struct led_classdev cdev;
+
+   struct gpio_descs *gpios;
+
+   u16 nr_states;
+
+   u8 states[0];
+};
+
+
+static void multi_gpio_led_set(struct led_classdev *led_cdev,
+   enum led_brightness value)
+{
+   struct multi_gpio_led_priv *priv;
+   int idx;
+
+   DECLARE_BITMAP(values, MAX_GPIO_NUM);
+
+   priv = container_of(led_cdev, struct multi_gpio_led_priv, cdev);
+
+   idx = value > led_cdev->max_brightness ? led_cdev->max_brightness : 
value;
+
+   values[0] = priv->states[idx];
+
+   gpiod_set_array_value(priv->gpios->ndescs, priv->gpios->desc,
+   priv->gpios->info, values);
+}
+
+static int multi_gpio_led_probe(struct platform_device *pdev)
+{
+   struct device *dev = &pdev->dev;
+   struct device_node *node = dev->of_node;
+   struct multi_gpio_led_priv *priv = NULL;
+   int ret;
+   const char *state = NULL;
+   struct led_init_data init_data = {};
+   struct gpio_descs *gpios;
+   u16 nr_states;
+
+   gpios = devm_gpiod_get_array(dev, "led", GPIOD_OUT_LOW);
+   if (IS_ERR(gpios))
+   return PTR_ERR(gpios);
+
+   if (gpios->ndescs >= MAX_GPIO_NUM) {
+   dev_err(dev, "Too many GPIOs\n");
+   return -EINVAL;
+   }
+
+   ret = of_property_count_u8_elems(node, "led-states");
+   if (ret < 0)
+   return ret;
+
+   if (ret != 1 << gpios->ndescs) {
+   dev_err(dev, "led-states number should equal to 2^led-gpios\n");
+   return -EINVAL;
+   }
+
+   nr_states = ret;
+
+   priv = devm_kzalloc(dev, sizeof(struct multi_gpio_led_priv)
+   + sizeof(u8) * nr_states , GFP_KERNEL);
+   if (!priv)
+   return -ENOMEM;
+
+   ret = of_property_read_u8_array(node, "led-states", priv->states, 
nr_states);
+   if (ret)
+   return ret;
+
+   priv->gpios = gpios;
+   priv->nr_states = nr_states;
+
+

[PATCH v2 1/2] dt-binding: leds: Document leds-multi-gpio bindings

From: Hermes Zhang 

This binding represents LED devices which are controller with
multiple GPIO lines in order to achieve more than two brightness
states.

Signed-off-by: Hermes Zhang 
---
 .../bindings/leds/leds-multi-gpio.yaml| 50 +++
 1 file changed, 50 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/leds/leds-multi-gpio.yaml

diff --git a/Documentation/devicetree/bindings/leds/leds-multi-gpio.yaml 
b/Documentation/devicetree/bindings/leds/leds-multi-gpio.yaml
new file mode 100644
index ..1549f21e8d6e
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/leds-multi-gpio.yaml
@@ -0,0 +1,50 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/leds-multi-gpio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Multiple GPIOs LED driver
+
+maintainers:
+  - Hermes Zhang 
+
+description:
+  This will support some LED made of multiple GPIOs and the brightness of the
+  LED could map to different states of the GPIOs.
+
+properties:
+  compatible:
+const: multi-gpio-led
+
+  led-gpios:
+description: Array of one or more GPIOs pins used to control the LED.
+minItems: 1
+maxItems: 8  # Should be enough
+
+  led-states:
+description: |
+  The array list the supported states here which will map to brightness
+  from 0 to maximum. Each item in the array will present all the GPIOs
+  value by bit.
+$ref: /schemas/types.yaml#/definitions/uint8-array
+minItems: 1
+maxItems: 256 # Should be enough
+
+required:
+  - compatible
+  - led-gpios
+  - led-states
+
+additionalProperties: false
+
+examples:
+  - |
+gpios-led {
+  compatible = "multi-gpio-led";
+
+  led-gpios = <&gpio0 23 0x1>,
+  <&gpio0 24 0x1>;
+  led-states = /bits/ 8 <0x00 0x01 0x02 0x03>;
+};
+...
-- 
2.20.1

[PATCH v2 0/2] New multiple GPIOs LED driver

From: Hermes Zhang 

changes v2:
- use max_brightness(=2^gpio number) instead of LED_FULL
- alloc priv at once
- move driver code to new simple folder
- update commit message for dt-binding commit
- move dt-binding commit before driver code

Hermes Zhang (2):
  dt-binding: leds: Document leds-multi-gpio bindings
  leds: leds-multi-gpio: Add multiple GPIOs LED driver

 .../bindings/leds/leds-multi-gpio.yaml|  50 ++
 drivers/leds/Kconfig  |   3 +
 drivers/leds/Makefile |   3 +
 drivers/leds/simple/Kconfig   |  23 +++
 drivers/leds/simple/Makefile  |   3 +
 drivers/leds/simple/leds-multi-gpio.c | 144 ++
 6 files changed, 226 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/leds/leds-multi-gpio.yaml
 create mode 100644 drivers/leds/simple/Kconfig
 create mode 100644 drivers/leds/simple/Makefile
 create mode 100644 drivers/leds/simple/leds-multi-gpio.c

-- 
2.20.1

Re: [PATCH 2/2] dt-bindings: cpufreq: update cpu type and clock name for MT8173 SoC

2021-03-25 Thread Viresh Kumar

On 26-03-21, 11:12, Seiya Wang wrote:
> Update the cpu type of cpu2 and cpu3 since MT8173 used Cortex-a72.
> 
> Signed-off-by: Seiya Wang 
> ---
>  Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek.txt | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek.txt 
> b/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek.txt
> index ea4994b35207..ef68711716fb 100644
> --- a/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek.txt
> +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek.txt
> @@ -202,11 +202,11 @@ Example 2 (MT8173 SoC):
>  
>   cpu2: cpu@100 {
>   device_type = "cpu";
> - compatible = "arm,cortex-a57";
> + compatible = "arm,cortex-a72";
>   reg = <0x100>;
>   enable-method = "psci";
>   cpu-idle-states = <&CPU_SLEEP_0>;
> - clocks = <&infracfg CLK_INFRA_CA57SEL>,
> + clocks = <&infracfg CLK_INFRA_CA72SEL>,
><&apmixedsys CLK_APMIXED_MAINPLL>;
>   clock-names = "cpu", "intermediate";
>   operating-points-v2 = <&cpu_opp_table_b>;
> @@ -214,11 +214,11 @@ Example 2 (MT8173 SoC):
>  
>   cpu3: cpu@101 {
>   device_type = "cpu";
> - compatible = "arm,cortex-a57";
> + compatible = "arm,cortex-a72";
>   reg = <0x101>;
>   enable-method = "psci";
>   cpu-idle-states = <&CPU_SLEEP_0>;
> - clocks = <&infracfg CLK_INFRA_CA57SEL>,
> + clocks = <&infracfg CLK_INFRA_CA72SEL>,
><&apmixedsys CLK_APMIXED_MAINPLL>;
>   clock-names = "cpu", "intermediate";
>   operating-points-v2 = <&cpu_opp_table_b>;

Acked-by: Viresh Kumar 

-- 
viresh

[PATCH] arch: mips: fix unmet dependency for DEBUG_INFO

2021-03-25 Thread Julian Braha

When SB1XXX_CORELIS is enabled, COMPILE_TEST is disabled,
and DEBUG_KERNEL is disabled, Kbuild gives the
following warning:

WARNING: unmet direct dependencies detected for DEBUG_INFO
  Depends on [n]: DEBUG_KERNEL [=n] && !COMPILE_TEST [=n]
  Selected by [y]:
  - SB1XXX_CORELIS [=y] && SIBYTE_SB1xxx_SOC [=y] && !COMPILE_TEST [=n]

This is because SB1XXX_CORELIS selects DEBUG_INFO without
selecting or depending on DEBUG_KERNEL, despite DEBUG_INFO
depending on DEBUG_KERNEL.

Signed-off-by: Julian Braha 
---
 arch/mips/Kconfig.debug | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/mips/Kconfig.debug b/arch/mips/Kconfig.debug
index 7a8d94cdd493..f5832a49a881 100644
--- a/arch/mips/Kconfig.debug
+++ b/arch/mips/Kconfig.debug
@@ -77,6 +77,7 @@ config CMDLINE_OVERRIDE
 config SB1XXX_CORELIS
bool "Corelis Debugger"
depends on SIBYTE_SB1xxx_SOC
+   select DEBUG_KERNEL if !COMPILE_TEST
select DEBUG_INFO if !COMPILE_TEST
help
  Select compile flags that produce code that can be processed by the
-- 
2.25.1

Re: [PATCH v2] kernel/resource: Fix locking in request_free_mem_region

2021-03-25 Thread Balbir Singh

On Fri, Mar 26, 2021 at 12:20:35PM +1100, Alistair Popple wrote:
> request_free_mem_region() is used to find an empty range of physical
> addresses for hotplugging ZONE_DEVICE memory. It does this by iterating
> over the range of possible addresses using region_intersects() to see if
> the range is free.
> 
> region_intersects() obtains a read lock before walking the resource tree
> to protect against concurrent changes. However it drops the lock prior
> to returning. This means by the time request_mem_region() is called in
> request_free_mem_region() another thread may have already reserved the
> requested region resulting in unexpected failures and a message in the
> kernel log from hitting this condition:
> 
> /*
>  * mm/hmm.c reserves physical addresses which then
>  * become unavailable to other users.  Conflicts are
>  * not expected.  Warn to aid debugging if encountered.
>  */
> if (conflict->desc == IORES_DESC_DEVICE_PRIVATE_MEMORY) {
> pr_warn("Unaddressable device %s %pR conflicts with %pR",
> conflict->name, conflict, res);
> 
> To fix this create versions of region_intersects() and
> request_mem_region() that allow the caller to take the appropriate lock
> such that it may be held over the required calls.
> 
> Instead of creating another version of devm_request_mem_region() that
> doesn't take the lock open-code it to allow the caller to pre-allocate
> the required memory prior to taking the lock.
> 
> Fixes: 0c385190392d8 ("resource: add a not device managed 
> request_free_mem_region variant")
> Fixes: 0092908d16c60 ("mm: factor out a devm_request_free_mem_region helper")
> Fixes: 4ef589dc9b10c ("mm/hmm/devmem: device memory hotplug using 
> ZONE_DEVICE")
> Signed-off-by: Alistair Popple 
> 
> ---
> 
> v2:
>  - Added Fixes tag
> 
> ---
>  kernel/resource.c | 146 +-
>  1 file changed, 94 insertions(+), 52 deletions(-)
> 
> diff --git a/kernel/resource.c b/kernel/resource.c
> index 627e61b0c124..2d4652383dd2 100644
> --- a/kernel/resource.c
> +++ b/kernel/resource.c
> @@ -523,6 +523,34 @@ int __weak page_is_ram(unsigned long pfn)
>  }
>  EXPORT_SYMBOL_GPL(page_is_ram);
>  
> +static int __region_intersects(resource_size_t start, size_t size,
> +unsigned long flags, unsigned long desc)
> +{
> + struct resource res;
> + int type = 0; int other = 0;
> + struct resource *p;
> +
> + res.start = start;
> + res.end = start + size - 1;
> +
> + for (p = iomem_resource.child; p ; p = p->sibling) {
> + bool is_type = (((p->flags & flags) == flags) &&
> + ((desc == IORES_DESC_NONE) ||
> +  (desc == p->desc)));

is_type is a bad name, are we saying "is" as in boolean question?
Or is it short for something like intersection_type? I know you've
just moved the code over :)

> +
> + if (resource_overlaps(p, &res))
> + is_type ? type++ : other++;
> + }
> +
> + if (type == 0)
> + return REGION_DISJOINT;
> +
> + if (other == 0)
> + return REGION_INTERSECTS;
> +
> + return REGION_MIXED;
> +}
> +
>  /**
>   * region_intersects() - determine intersection of region with known 
> resources
>   * @start: region start address
> @@ -546,31 +574,12 @@ EXPORT_SYMBOL_GPL(page_is_ram);
>  int region_intersects(resource_size_t start, size_t size, unsigned long 
> flags,
> unsigned long desc)
>  {
> - struct resource res;
> - int type = 0; int other = 0;
> - struct resource *p;
> -
> - res.start = start;
> - res.end = start + size - 1;
> + int rc;
>  
>   read_lock(&resource_lock);
> - for (p = iomem_resource.child; p ; p = p->sibling) {
> - bool is_type = (((p->flags & flags) == flags) &&
> - ((desc == IORES_DESC_NONE) ||
> -  (desc == p->desc)));
> -
> - if (resource_overlaps(p, &res))
> - is_type ? type++ : other++;
> - }
> + rc = __region_intersects(start, size, flags, desc);
>   read_unlock(&resource_lock);
> -
> - if (type == 0)
> - return REGION_DISJOINT;
> -
> - if (other == 0)
> - return REGION_INTERSECTS;
> -
> - return REGION_MIXED;
> + return rc;
>  }
>  EXPORT_SYMBOL_GPL(region_intersects);
>  
> @@ -1171,31 +1180,17 @@ struct address_space *iomem_get_mapping(void)
>   return smp_load_acquire(&iomem_inode)->i_mapping;
>  }
>  
> -/**
> - * __request_region - create a new busy resource region
> - * @parent: parent resource descriptor
> - * @start: resource start address
> - * @n: resource region size
> - * @name: reserving caller's ID string
> - * @flags: IO resource flags
> - */
> -struct resource * __request_region(struct resource *parent,
> -resource_size_t s

Re: [PATCH -next] powerpc/eeh: Remove unused inline function eeh_dev_phb_init_dynamic()

Hi,

> commit 475028efc708 ("powerpc/eeh: Remove eeh_dev_phb_init_dynamic()")
> left behind this, so can remove it.

I had a look: the inline that you are removing here is for the
!CONFIG_EEH case, which explains why it was missed the first time.

This looks like a good change. Out of interest, what tool are you using
to find these unused inlines? If there are many more, it might make
sense to combine future patches removing them into a single patch, but
I'm not sure.

checkpatch likes this patch, so that's also good :)

Reviewed-by: Daniel Axtens 

Kind regards,
Daniel

Re: [PATCH -next] powerpc/smp: Remove unused inline functions

Hi,

> commit 441c19c8a290 ("powerpc/kvm/book3s_hv: Rework the secondary inhibit 
> code")
> left behind this, so can remove it.
>

Interesting: that commit removed some instances of
(un)inhibit_secondary_onlining, but it seems to have missed the ones for
the uni-processor case, which your patch removes. This seems like a good
change.

Checkpatch does have one small complaint about your commit message:

| WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a 
maximum 75 chars per line)
| #6: 
| commit 441c19c8a290 ("powerpc/kvm/book3s_hv: Rework the secondary inhibit 
code")

I don't think this warrants another revision, I think leaving the commit
name on one line makes sense.

Reviewed-by: Daniel Axtens 

Kind regards,
Daniel

> Signed-off-by: YueHaibing 
> ---
>  arch/powerpc/include/asm/smp.h | 2 --
>  1 file changed, 2 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/smp.h b/arch/powerpc/include/asm/smp.h
> index 7a13bc20f0a0..ad7129a19e8f 100644
> --- a/arch/powerpc/include/asm/smp.h
> +++ b/arch/powerpc/include/asm/smp.h
> @@ -189,8 +189,6 @@ extern void __cpu_die(unsigned int cpu);
>  #define hard_smp_processor_id()  get_hard_smp_processor_id(0)
>  #define smp_setup_cpu_maps()
>  #define thread_group_shares_l2  0
> -static inline void inhibit_secondary_onlining(void) {}
> -static inline void uninhibit_secondary_onlining(void) {}
>  static inline const struct cpumask *cpu_sibling_mask(int cpu)
>  {
>   return cpumask_of(cpu);
> -- 
> 2.17.1

Re: [PATCH v7 5/6] x86/signal: Detect and prevent an alternate signal stack overflow

2021-03-25 Thread Andy Lutomirski

I forgot to mention why I cc'd all you fine Xen folk:

On Thu, Mar 25, 2021 at 11:13 AM Andy Lutomirski  wrote:

>
> > } else if (IS_ENABLED(CONFIG_X86_32) &&
> >!onsigstack &&
> >regs->ss != __USER_DS &&

This bit here seems really dubious on Xen PV.  Honestly it seems
dubious everywhere, but especially on Xen PV.

--Andy

Re: [PATCH v7 5/6] x86/signal: Detect and prevent an alternate signal stack overflow

2021-03-25 Thread Andy Lutomirski

On Thu, Mar 25, 2021 at 11:54 AM Borislav Petkov  wrote:
>
> On Thu, Mar 25, 2021 at 11:13:12AM -0700, Andy Lutomirski wrote:
> > diff --git a/arch/x86/kernel/signal.c b/arch/x86/kernel/signal.c
> > index ea794a083c44..53781324a2d3 100644
> > --- a/arch/x86/kernel/signal.c
> > +++ b/arch/x86/kernel/signal.c
> > @@ -237,7 +237,8 @@ get_sigframe(struct k_sigaction *ka, struct pt_regs 
> > *regs, size_t frame_size,
> >   unsigned long math_size = 0;
> >   unsigned long sp = regs->sp;
> >   unsigned long buf_fx = 0;
> > - int onsigstack = on_sig_stack(sp);
> > + bool already_onsigstack = on_sig_stack(sp);
> > + bool entering_altstack = false;
> >   int ret;
> >
> >   /* redzone */
> > @@ -246,15 +247,25 @@ get_sigframe(struct k_sigaction *ka, struct pt_regs 
> > *regs, size_t frame_size,
> >
> >   /* This is the X/Open sanctioned signal stack switching.  */
> >   if (ka->sa.sa_flags & SA_ONSTACK) {
> > - if (sas_ss_flags(sp) == 0)
> > + /*
> > +  * This checks already_onsigstack via sas_ss_flags().
> > +  * Sensible programs use SS_AUTODISARM, which disables
> > +  * that check, and programs that don't use
> > +  * SS_AUTODISARM get compatible but potentially
> > +  * bizarre behavior.
> > +  */
> > + if (sas_ss_flags(sp) == 0) {
> >   sp = current->sas_ss_sp + current->sas_ss_size;
> > + entering_altstack = true;
> > + }
> >   } else if (IS_ENABLED(CONFIG_X86_32) &&
> > -!onsigstack &&
> > +!already_onsigstack &&
> >  regs->ss != __USER_DS &&
> >  !(ka->sa.sa_flags & SA_RESTORER) &&
> >  ka->sa.sa_restorer) {
> >   /* This is the legacy signal stack switching. */
> >   sp = (unsigned long) ka->sa.sa_restorer;
> > + entering_altstack = true;
> >   }
>
> What a mess this whole signal handling is. I need a course in signal
> handling to understand what's going on here...
>
> >
> >   sp = fpu__alloc_mathframe(sp, IS_ENABLED(CONFIG_X86_32),
> > @@ -267,8 +278,16 @@ get_sigframe(struct k_sigaction *ka, struct pt_regs 
> > *regs, size_t frame_size,
> >* If we are on the alternate signal stack and would overflow it, 
> > don't.
> >* Return an always-bogus address instead so we will die with SIGSEGV.
> >*/
> > - if (onsigstack && !likely(on_sig_stack(sp)))
> > + if (unlikely(entering_altstack &&
> > +  (sp <= current->sas_ss_sp ||
> > +   sp - current->sas_ss_sp > current->sas_ss_size))) {
>
> You could've simply done
>
> if (unlikely(entering_altstack && !on_sig_stack(sp)))
>
> here.

Nope.  on_sig_stack() is a horrible kludge and won't work here.  We
could have something like __on_sig_stack() or sp_is_on_sig_stack() or
something, though.

>
>
> > + if (show_unhandled_signals && printk_ratelimit()) {
> > + pr_info("%s[%d] overflowed sigaltstack",
> > + tsk->comm, task_pid_nr(tsk));
> > + }
>
> Why do you even wanna issue that? It looks like callers will propagate
> an error value up and people don't look at dmesg all the time.

I figure that the people whose programs spontaneously crash should get
a hint why if they look at dmesg.  Maybe the message should say
"overflowed sigaltstack -- try noavx512"?

We really ought to have a SIGSIGFAIL signal that's sent, double-fault
style, when we fail to send a signal.

[rcu:master] BUILD SUCCESS dd44ee94db05b80fef1469155c374caad58d8a2e

nfig
nios2   defconfig
arm axm55xx_defconfig
ia64generic_defconfig
m68kmac_defconfig
mips  bmips_stb_defconfig
m68k amcore_defconfig
arm mv78xx0_defconfig
openrisc simple_smp_defconfig
arm orion5x_defconfig
powerpc tqm8548_defconfig
arm   u8500_defconfig
arm   netwinder_defconfig
powerpc   eiger_defconfig
sh  polaris_defconfig
mips   lemote2f_defconfig
arm   aspeed_g4_defconfig
sh  kfr2r09_defconfig
mips allmodconfig
mips   ip32_defconfig
powerpc tqm8541_defconfig
m68kq40_defconfig
xtensasmp_lx200_defconfig
arm  colibri_pxa270_defconfig
powerpc mpc837x_mds_defconfig
umkunit_defconfig
ia64defconfig
ia64 allyesconfig
m68k allmodconfig
m68k allyesconfig
arc  allyesconfig
nds32   defconfig
nios2allyesconfig
alpha   defconfig
alphaallyesconfig
xtensa   allyesconfig
h8300allyesconfig
arc defconfig
sh   allmodconfig
parisc  defconfig
s390 allyesconfig
s390 allmodconfig
parisc   allyesconfig
s390defconfig
sparcallyesconfig
sparc   defconfig
i386   tinyconfig
i386defconfig
mips allyesconfig
powerpc  allyesconfig
powerpc  allmodconfig
powerpc   allnoconfig
x86_64   randconfig-a002-20210325
x86_64   randconfig-a003-20210325
x86_64   randconfig-a006-20210325
x86_64   randconfig-a001-20210325
x86_64   randconfig-a005-20210325
x86_64   randconfig-a004-20210325
i386 randconfig-a003-20210325
i386 randconfig-a004-20210325
i386 randconfig-a001-20210325
i386 randconfig-a002-20210325
i386 randconfig-a006-20210325
i386 randconfig-a005-20210325
i386 randconfig-a014-20210325
i386 randconfig-a011-20210325
i386 randconfig-a015-20210325
i386 randconfig-a016-20210325
i386 randconfig-a013-20210325
i386 randconfig-a012-20210325
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-a012-20210325
x86_64   randconfig-a015-20210325
x86_64   randconfig-a014-20210325
x86_64   randconfig-a013-20210325
x86_64   randconfig-a011-20210325
x86_64   randconfig-a016-20210325

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org

[rcu:rcu/next] BUILD SUCCESS 1a0dfc099c1e61e22045705265a1323ac294bea6

allyesconfig
arc defconfig
sh   allmodconfig
parisc  defconfig
s390 allyesconfig
s390 allmodconfig
parisc   allyesconfig
s390defconfig
sparcallyesconfig
sparc   defconfig
i386   tinyconfig
i386defconfig
mips allyesconfig
mips allmodconfig
powerpc  allyesconfig
powerpc  allmodconfig
powerpc   allnoconfig
x86_64   randconfig-a002-20210325
x86_64   randconfig-a003-20210325
x86_64   randconfig-a006-20210325
x86_64   randconfig-a001-20210325
x86_64   randconfig-a005-20210325
x86_64   randconfig-a004-20210325
i386 randconfig-a003-20210325
i386 randconfig-a004-20210325
i386 randconfig-a001-20210325
i386 randconfig-a002-20210325
i386 randconfig-a006-20210325
i386 randconfig-a005-20210325
i386 randconfig-a014-20210325
i386 randconfig-a011-20210325
i386 randconfig-a015-20210325
i386 randconfig-a016-20210325
i386 randconfig-a013-20210325
i386 randconfig-a012-20210325
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-a012-20210325
x86_64   randconfig-a015-20210325
x86_64   randconfig-a014-20210325
x86_64   randconfig-a013-20210325
x86_64   randconfig-a011-20210325
x86_64   randconfig-a016-20210325

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org

Re: [PATCH] selftests: powerpc: unmark non-kernel-doc comments

Randy Dunlap  writes:

> Drop the 'beginning of kernel-doc' notation markers (/**)
> in places that are not in kernel-doc format.

This looks good to me. Arguably we don't need the comments at all, but
it doesn't seem to hurt to keep them.

checkpatch is OK with the entire file, so there's nothing else we'd
really want to clean up while you're doing cleanups.

Reviewed-by: Daniel Axtens 

Kind regards,
Daniel

>
> Signed-off-by: Randy Dunlap 
> Cc: Michael Ellerman 
> Cc: linuxppc-...@lists.ozlabs.org
> ---
>  tools/testing/selftests/powerpc/tm/tm-trap.c |4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> --- linux-next-20210323.orig/tools/testing/selftests/powerpc/tm/tm-trap.c
> +++ linux-next-20210323/tools/testing/selftests/powerpc/tm/tm-trap.c
> @@ -66,7 +66,7 @@ void trap_signal_handler(int signo, sigi
>   /* Get thread endianness: extract bit LE from MSR */
>   thread_endianness = MSR_LE & ucp->uc_mcontext.gp_regs[PT_MSR];
>  
> - /***
> + /*
>* Little-Endian Machine
>*/
>  
> @@ -126,7 +126,7 @@ void trap_signal_handler(int signo, sigi
>   }
>   }
>  
> - /***
> + /*
>* Big-Endian Machine
>*/
>

Re: [PATCH bpf] bpf: link: refuse non-zero file_flags in BPF_OBJ_GET

2021-03-25 Thread Andrii Nakryiko

On Thu, Mar 25, 2021 at 8:22 AM Lorenz Bauer  wrote:
>
> Invoking BPF_OBJ_GET on a pinned bpf_link checks the path access
> permissions based on file_flags, but the returned fd ignores flags.
> This means that any user can acquire a "read-write" fd for a pinned
> link with mode 0664 by invoking BPF_OBJ_GET with BPF_F_RDONLY in
> file_flags. The fd can be used to invoke BPF_LINK_DETACH, etc.
>
> Fix this by refusing non-zero flags in BPF_OBJ_GET. Since zero flags
> imply O_RDWR this requires users to have read-write access to the
> pinned file, which matches the behaviour of the link primitive.
>
> libbpf doesn't expose a way to set file_flags for links, so this
> change is unlikely to break users.
>
> Fixes: 70ed506c3bbc ("bpf: Introduce pinnable bpf_link abstraction")
> Signed-off-by: Lorenz Bauer 
> ---

Makes sense, but see below about details.

Also, should we do the same for BPF programs as well? I guess they
don't have a "write operation", once loaded, but still...

>  kernel/bpf/inode.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/bpf/inode.c b/kernel/bpf/inode.c
> index 1576ff331ee4..2f9e8115ad58 100644
> --- a/kernel/bpf/inode.c
> +++ b/kernel/bpf/inode.c
> @@ -547,7 +547,7 @@ int bpf_obj_get_user(const char __user *pathname, int 
> flags)
> else if (type == BPF_TYPE_MAP)
> ret = bpf_map_new_fd(raw, f_flags);
> else if (type == BPF_TYPE_LINK)
> -   ret = bpf_link_new_fd(raw);
> +   ret = (flags) ? -EINVAL : bpf_link_new_fd(raw);

nit: unnecessary ()


I wonder if EACCESS would make more sense here? And check f_flags, not flags:

if (f_flags != O_RDWR)
ret = -EACCESS;
else
ret = bpf_link_new_fd(raw);

?

> else
> return -ENOENT;
>
> --
> 2.27.0
>

Why does glibc use AVX-512?

2021-03-25 Thread Andy Lutomirski

Hi all-

glibc appears to use AVX512F for memcpy by default.  (Unless
Prefer_ERMS is default-on, but I genuinely can't tell if this is the
case.  I did some searching.)  The commit adding it refers to a 2016
email saying that it's 30% on KNL.  Unfortunately, AVX-512 is now
available in normal hardware, and the overhead from switching between
normal and AVX-512 code appears to vary from bad to genuinely
horrible.  And, once anything has used the high parts of YMM and/or
ZMM, those states tend to get stuck with XINUSE=1.

I'm wondering whether glibc should stop using AVX-512 by default.

Meanwhile, some of you may have noticed a little ABI break we have.
On AVX-512 hardware, the size of a signal frame is unreasonably large,
and this is causing problems even for existing software that doesn't
use AVX-512.  Do any of you have any clever ideas for how to fix it?
We have some kernel patches around to try to fail more cleanly, but we
still fail.

I think we should seriously consider solutions in which, for new
tasks, XCR0 has new giant features (e.g. AMX) and possibly even
AVX-512 cleared, and programs need to explicitly request enablement.
This would allow programs to opt into not saving/restoring across
signals or to save/restore in buffers supplied when the feature is
enabled.  This has all kinds of pros and cons, and I'm not sure it's a
great idea.  But, in the absence of some change to the ABI, the
default outcome is that, on AMX-enabled kernels on AMX-enabled
hardware, the signal frame will be more than 8kB, and this will affect
*every* signal regardless of whether AMX is in use.

--Andy

Re: [PATCH v3 09/17] treewide: Change list_sort to use const pointers

On Tue, Mar 23, 2021 at 01:39:38PM -0700, Sami Tolvanen wrote:
> list_sort() internally casts the comparison function passed to it
> to a different type with constant struct list_head pointers, and
> uses this pointer to call the functions, which trips indirect call
> Control-Flow Integrity (CFI) checking.
> 
> Instead of removing the consts, this change defines the
> list_cmp_func_t type and changes the comparison function types of
> all list_sort() callers to use const pointers, thus avoiding type
> mismatches.
> 
> Suggested-by: Nick Desaulniers 
> Signed-off-by: Sami Tolvanen 

Reviewed-by: Kees Cook 

-- 
Kees Cook

Re: [PATCH v3 05/17] workqueue: use WARN_ON_FUNCTION_MISMATCH

On Tue, Mar 23, 2021 at 01:39:34PM -0700, Sami Tolvanen wrote:
> With CONFIG_CFI_CLANG, a callback function passed to
> __queue_delayed_work from a module points to a jump table entry
> defined in the module instead of the one used in the core kernel,
> which breaks function address equality in this check:
> 
>   WARN_ON_ONCE(timer->function != delayed_work_timer_fn);
> 
> Use WARN_ON_FUNCTION_MISMATCH() instead to disable the warning
> when CFI and modules are both enabled.
> 
> Signed-off-by: Sami Tolvanen 

Reviewed-by: Kees Cook 

-- 
Kees Cook

Re: [PATCH v3 06/17] kthread: use WARN_ON_FUNCTION_MISMATCH

On Tue, Mar 23, 2021 at 01:39:35PM -0700, Sami Tolvanen wrote:
> With CONFIG_CFI_CLANG, a callback function passed to
> __kthread_queue_delayed_work from a module points to a jump table
> entry defined in the module instead of the one used in the core
> kernel, which breaks function address equality in this check:
> 
>   WARN_ON_ONCE(timer->function != ktead_delayed_work_timer_fn);
> 
> Use WARN_ON_FUNCTION_MISMATCH() instead to disable the warning
> when CFI and modules are both enabled.
> 
> Signed-off-by: Sami Tolvanen 

Reviewed-by: Kees Cook 

-- 
Kees Cook

Re: [PATCH v3 04/17] module: ensure __cfi_check alignment

On Tue, Mar 23, 2021 at 01:39:33PM -0700, Sami Tolvanen wrote:
> CONFIG_CFI_CLANG_SHADOW assumes the __cfi_check() function is page
> aligned and at the beginning of the .text section. While Clang would
> normally align the function correctly, it fails to do so for modules
> with no executable code.
> 
> This change ensures the correct __cfi_check() location and
> alignment. It also discards the .eh_frame section, which Clang can
> generate with certain sanitizers, such as CFI.
> 
> Link: https://bugs.llvm.org/show_bug.cgi?id=46293
> Signed-off-by: Sami Tolvanen 

Yay macros! :)

Reviewed-by: Kees Cook 

-- 
Kees Cook

Re: [PATCH bpf-next] libbpf: fix bail out from 'ringbuf_process_ring()' on error

2021-03-25 Thread Andrii Nakryiko

On Thu, Mar 25, 2021 at 8:02 AM Pedro Tammela  wrote:
>
> The current code bails out with negative and positive returns.
> If the callback returns a positive return code, 'ring_buffer__consume()'
> and 'ring_buffer__poll()' will return a spurious number of records
> consumed, but mostly important will continue the processing loop.
>
> This patch makes positive returns from the callback a no-op.
>
> Signed-off-by: Pedro Tammela 
> ---
>  tools/lib/bpf/ringbuf.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>

Thanks. Applied to bpf tree and added:

Fixes: bf99c936f947 ("libbpf: Add BPF ring buffer support")


> diff --git a/tools/lib/bpf/ringbuf.c b/tools/lib/bpf/ringbuf.c
> index 8caaafe7e312..e7a8d847161f 100644
> --- a/tools/lib/bpf/ringbuf.c
> +++ b/tools/lib/bpf/ringbuf.c
> @@ -227,7 +227,7 @@ static int ringbuf_process_ring(struct ring* r)
> if ((len & BPF_RINGBUF_DISCARD_BIT) == 0) {
> sample = (void *)len_ptr + BPF_RINGBUF_HDR_SZ;
> err = r->sample_cb(r->ctx, sample, len);
> -   if (err) {
> +   if (err < 0) {
> /* update consumer pos and bail out */
> smp_store_release(r->consumer_pos,
>   cons_pos);
> --
> 2.25.1
>

Re: [PATCH v31 10/12] selftests/landlock: Add user space tests

On Wed, Mar 24, 2021 at 08:15:18PM +0100, Mickaël Salaün wrote:
> From: Mickaël Salaün 
> 
> Test all Landlock system calls, ptrace hooks semantic and filesystem
> access-control with multiple layouts.
> 
> Test coverage for security/landlock/ is 93.6% of lines.  The code not
> covered only deals with internal kernel errors (e.g. memory allocation)
> and race conditions.
> 
> Cc: James Morris 
> Cc: Jann Horn 
> Cc: Kees Cook 
> Cc: Serge E. Hallyn 
> Cc: Shuah Khan 
> Signed-off-by: Mickaël Salaün 

Reviewed-by: Kees Cook 

-- 
Kees Cook

Re: [PATCH v31 12/12] landlock: Add user and kernel documentation

On Wed, Mar 24, 2021 at 08:15:20PM +0100, Mickaël Salaün wrote:
> From: Mickaël Salaün 
> 
> Add a first document describing userspace API: how to define and enforce
> a Landlock security policy.  This is explained with a simple example.
> The Landlock system calls are described with their expected behavior and
> current limitations.
> 
> Another document is dedicated to kernel developers, describing guiding
> principles and some important kernel structures.
> 
> This documentation can be built with the Sphinx framework.
> 
> Cc: James Morris 
> Cc: Jann Horn 
> Cc: Kees Cook 
> Cc: Serge E. Hallyn 
> Signed-off-by: Mickaël Salaün 

Thanks for the changes!

Reviewed-by: Kees Cook 

-- 
Kees Cook

Re: [PATCH][next] scsi: aacraid: Replace one-element array with flexible-array member

2021-03-25 Thread Gustavo A. R. Silva

Hi Martin,


On 3/25/21 22:34, Martin K. Petersen wrote:
> 
> Gustavo,
> 
>> Precisely this sort of confusion is one of the things we want to avoid
>> by using flexible-array members instead of one-element arrays.
> 
> Ah, you're right!
> 
> Now that I look at it again I also don't think that was the issue that
> originally caused concern.
> 
> @@ -4020,7 +4020,8 @@ static int aac_convert_sgraw2(struct aac_raw_io2 *rio2, 
> int pages, int nseg, int
>   }
>   }
>   sge[pos] = rio2->sge[nseg-1];
> - memcpy(&rio2->sge[1], &sge[1], (nseg_new-1)*sizeof(struct 
> sge_ieee1212));
> + memcpy(&rio2->sge[1], &sge[1],
> +flex_array_size(rio2, sge, nseg_new - 1));
>  
>   kfree(sge);
>   rio2->sgeCnt = cpu_to_le32(nseg_new);
> 
> I find it counter-intuitive to use the type of the destination array to
> size the amount of source data to copy. "Are source and destination same

The destination and source arrays are of the same type. :)

drivers/scsi/aacraid/aachba.c:
3999 struct sge_ieee1212 *sge;

> type? Does flex_array_size() do the right thing given the ->sge[1]
> destination offset?". It wasn't immediately obvious. To me, "copy this
> many scatterlist entries" in the original is much more readable.

Yeah; it does the right thing because flex_array_size() doesn't know about
offsets. It just calculates the amount of bytes to be copied based on the
type of the object passed as second argument and a "count" passed as third
argument. So, in this case, the "count" is "nseg_new - 1", which in some
way is already taking care of that sge[1] offset.

--
Gustavo

Re: [PATCH v7 00/38] SCMI vendor protocols and modularization

2021-03-25 Thread Florian Fainelli




On 3/16/2021 5:48 AM, Cristian Marussi wrote:
> Hi all,
> 
> The current SCMI implementation does not provide an interface to easily
> develop and include a custom vendor protocol implementation as prescribed
> by the SCMI standard, also because, there is not currently any custom
> protocol in the upstream to justify the development of a custom interface
> and its maintenance.
> 
> Moreover the current interface exposes protocol operations to the SCMI
> driver users attaching per-protocol operations directly to the handle
> structure, which, in this way, tends to grow indefinitely for each new
> protocol addition.
> 
> Beside this, protocols private data are also exposed via handle *_priv
> pointers, making such private data accessible also to the SCMI drivers
> even if neither really needed nor advisable.
> 
> This series wants to address this by simplifying the SCMI protocols
> interface and reducing it, roughly, to these common generic operations:
> 
>   - handle->devm_protocol_get()
>   - handle->devm_protocol_put()
>   - handle->notify_ops->*
> 
> All protocols' private data pointers are removed from handle too and made
> accessible only to the protocols code through dedicated internal helpers.
> 
> The concept of protocol handle is also introduced in the SCMI protocol code
> to represent a protocol instance initialized against a specific SCMI
> instance (handle), so that all the new protocol code uses such protocol
> handles wherever previously SCMI handle was used: this enable tighter
> control of what is exposed to the protocol code vs the SCMI drivers.
> 
> Moreover protocol initialization is moved away from device probe and now
> happens on demand when the first user shows up (first .protocol_get), while
> de-initialization is performed once the last user of the protocol, even in
> terms of registered notifications callback, is gone, with the SCMI core
> taking care to perform all the needed underlying resource accounting.
> 
> This way any new future standard or custom protocol implementation will
> expose a common unified interface which does not need to be extended
> endlessly: no need to maintain a custom interface only for vendor protos.
> SCMI drivers written on top of standard or custom protocols will use this
> same common interface to access any protocol operations.
> 
> All existent upstream SCMI drivers are converted to this new interface.
> 
> In order to make this migration painless and to avoid the need of a big
> un-mergeable jumbo patch touching all over the protocols and drivers (like
> it was in v2), since v3 the migration process has been heavily split with a
> bit of transient code added along the way (to preserve bisectability) and
> finally removed towards the ends of the series.
> Protocols and SCMI drivers migration to the new interface happens along
> patches 10->30.
> 
> Leveraging this new centralized and common initialization flow we took
> care also to refactor and simplify protocol-events registration and remove
> *notify_priv from the handle interface making it accessible only to the
> notification core.
> 
> Patch 37 builds on top of this new interface and introduces a mechanism to
> define an SCMI protocol as a full blown module (possibly loadable) while
> leaving the core dealing with proper resource accounting.
> Standard protocols are still kept as builtins in this series, though.
> 
> Finally, patch 38 introduces dynamic SCMI devices creation to avoid having
> to update the static module device table in the core each time a new driver
> is added.
> 
> The whole SCMI stack can still be built alternatively as a module, with all
> the standard protocols included in scmi-module.ko in such a case.
> 
> On top of this series an example SCMI Custom protocol 0x99 and related
> SCMI Custom Dummy driver has been built and it is available at [1] as a
> series of DEBUG patches on top this same series.
> 
> The series is currently based on sudeep/for-next/scmi [2] on top of:
> 
> commit 908a4f778dc7 ("Merge branch 'ib-iio-scmi-5.12-rc2-take3' of
>git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into
>for-next/scmi")
> 
> Any feedback welcome.

You copied me on each round and thanks for doing that, I did not have
time to go look at each change, but sensors, clocks and cpufreq still
worked on ARCH_BRCMSTB with both 32-bit and 64-bit kernels, so:

Tested-by: Florian Fainelli 

Thanks!
-- 
Florian

Re: [PATCH] mm: page_alloc: fix memcg accounting leak in speculative cache lookup

2021-03-25 Thread Hugh Dickins

On Fri, 26 Mar 2021, Matthew Wilcox wrote:
> On Thu, Mar 25, 2021 at 06:55:42PM -0700, Hugh Dickins wrote:
> > The first reason occurred to me this morning.  I thought I had been
> > clever to spot the PageHead race which you fix here.  But now I just feel
> > very stupid not to have spotted the very similar memcg_data race.  The
> > speculative racer may call mem_cgroup_uncharge() from __put_single_page(),
> > and the new call to split_page_memcg() do nothing because page_memcg(head)
> > is already NULL.
> > 
> > And is it even safe there, to sprinkle memcg_data through all of those
> > order-0 subpages, when free_the_page() is about to be applied to a
> > series of descending orders?  I could easily be wrong, but I think
> > free_pages_prepare()'s check_free_page() will find that is not
> > page_expected_state().
> 
> So back to something more like my original patch then?
> 
> +++ b/mm/page_alloc.c
> @@ -5081,9 +5081,15 @@ void __free_pages(struct page *page, unsigned int 
> order)
>  {
> if (put_page_testzero(page))
> free_the_page(page, order);
> - else if (!PageHead(page))
> -   while (order-- > 0)
> -   free_the_page(page + (1 << order), order);
> +   else if (!PageHead(page)) {
> +   while (order-- > 0) {
> +   struct page *tail = page + (1 << order);
> +#ifdef CONFIG_MEMCG
> +   tail->memcg_data = page->memcg_data;
> +#endif
> +   free_the_page(tail, order);
> +   }
> +   }
>  }
>  EXPORT_SYMBOL(__free_pages);
> 
> We can cache page->memcg_data before calling put_page_testzero(),
> just like we cache the Head flag in Johannes' patch.

If I still believed in e320d3012d25, yes, that would look right
(but I don't have much faith in my judgement after all this).

I'd fallen in love with split_page_memcg() when you posted that
one, and was put off by your #ifdef, so got my priorities wrong
and went for the split_page_memcg().

> 
> > But, after all that, I'm now thinking that Matthew's original
> > e320d3012d25 ("mm/page_alloc.c: fix freeing non-compound pages")
> > is safer reverted.  The put_page_testzero() in __free_pages() was
> > not introduced for speculative pagecache: it was there in 2.4.0,
> > and atomic_dec_and_test() in 2.2, I don't have older trees to hand.
> 
> I think you're confused in that last assertion.  According to
> linux-fullhistory, the first introduction of __free_pages was 2.3.29pre3
> (September 1999), where it did indeed use put_page_testzero:

Not confused, just pontificating from a misleading subset of the data.
I knew there's an even-more-history-than-tglx git tree somewhere, but
what I usually look back to is 2.4 trees, plus a 2.2.26 tree - but of
course that's a late 2.2, from 2004, around the same time as 2.6.3.
That tree shows a __free_pages() using atomic_dec_and_test().

But we digress...

> 
> +extern inline void __free_pages(struct page *page, unsigned long order)
> +{
> +   if (!put_page_testzero(page))
> +   return;
> +   __free_pages_ok(page, order);
> +}
> 
> Before that, we had only free_pages() and __free_page().
> 
> > So, it has "always" been accepted that multiple references to a
> > high-order non-compound page can be given out and released: maybe
> > they were all released with __free_pages() of the right order, or
> > maybe only the last had to get that right; but as __free_pages()
> > stands today, all but the last caller frees all but the first
> > subpage.  A very rare leak seems much safer.
> > 
> > I don't have the answer (find somewhere in struct page to squirrel
> > away the order, even when it's a non-compound page?), and I think
> > each of us would much rather be thinking about other things at the
> > moment.  But for now it looks to me like NAK to this patch, and
> > revert of e320d3012d25.
> 
> We did discuss that possibility prior to the introduction of
> e320d3012d25.  Here's one such:
> https://lore.kernel.org/linux-mm/20200922031215.gz32...@casper.infradead.org/T/#m0b08c0c3430e09e20fa6648877dc42b04b18e6f3

Thanks for the link. And I'll willingly grant that your experience is
vast compared to mine. But "Drivers don't do that, in my experience"
is not a convincing reason to invalidate a way of working that the
code has gone out of its way to allow for, for over twenty years.

But you make a good point on the "Bad page" reports that would now
be generated: maybe that will change my mind later on.

Hugh

arch/arm64/kvm/perf.c:58:36: error: implicit declaration of function 'perf_num_counters'